0

我正在开展一个项目，该项目依赖于与 SMS/MMS 消息聚合器公司的集成，以便将应用程序部署到手机以及通过 SMS 执行移动支付。这种架构中的许多概念与企业集成和 SOA 世界中的消息传递模式密切相关。我目前正在评估不同的 SMS 消息传递供应商，并想知道架构师在消息传递体系结构中是否有一些特殊标准需要关注。

我的方法是使用架构“ilities”（性能、可用​​性、可扩展性、安全性等）来为每个供应商的系统建立一个评分模型。但是，在与此类架构集成时，是否有人推荐其他方法或标准来寻找？

谢谢一堆。

4

3 回答 3

3

完全披露：我为最大的 SMS/MMS 经纪人之一工作，所以我可能有点偏见。

我认为对你来说重要的事情很难从经纪人那里得到可靠的（即非销售的）数字。我们在我工作的经纪人处关注的事情是：

  1. 可扩展性：我们选择了水平可扩展性）在大多数事情上使用商品硬件

  2. 吞吐量：代理维护每个运营商的实时/回退连接数

  3. 故障转移方法：代理是否连接到每个可用的运营商上的冗余 SMSC/MMSC？

  4. 连接方法：代理是通过 SMPP/MM4|7 直接连接还是直接使用 SS7 骨干网，即它们有一个点代码。

  5. 排队容量：在操作员中断的情况下，聚合器在消息丢失之前可以将消息排队多长时间？

  6. 直接与对等连接：您的潜在交付 MNO 中有多少直接连接到代理，有多少通过对等连接？

  7. 端到端运输时间

  8. 服务质量

于 2009-07-15T06:12:13.640 回答
1

您是否真的打算评估架构，即。聚合器的内部结构？如果我这样做，我会对诸如分解成组件、它们的内聚程度和它们的相对解耦等因素非常感兴趣。出于多种原因，这些将很重要，尤其是产品的未来灵活性。

产品内部结构变得有趣的另一个地方是可扩展性和可用性领域。如果针对此类“ilities”提出索赔，我非常想知道“架构如何实现这一目标？”

我认为您采取外部观点的方法，将您的非功能性需求与产品“ilities”堆叠起来，可能是最务实的方法。我也对供应商本身的“ilities”感兴趣 - 安装基础是什么，我们是否相信产品的持续支持，产品支持的水平，它是否在您的时区本地等。

于 2009-07-15T05:59:26.287 回答
0

要正确评分“疾病”，您应该考虑要求是什么。

您可以尝试尽可能客观地对所有“疾病”进行评分，然后根据要求对每个分数进行加权。

PS不应该花费（€）也是等式的一部分。当然对于用户和提供商！

于 2009-07-14T23:00:06.440 回答