我正在开发一个项目，该项目依赖于与SMS / MMS消息传递聚合公司的集成，以便将应用程序部署到手机以及通过SMS执行移动支付。此类体系结构中的许多概念与企业集成和SOA世界中的消息传递密切相关。我目前正在评估不同的SMS消息传递供应商，并想知道架构师在消息传递体系结构中是否存在一些应该引起关注的特殊标准。
我的方法是使用架构“功能”（性能，可用性，可伸缩性，安全性等）来为每个供应商的系统提供一个评分模型。但是，有没有人建议在与这种架构集成时寻找其他方法或标准？
非常感谢。
答案 0 :(得分：3)
完全披露：我为一家最大的短信/彩信经纪人工作，所以我可能有点偏颇。
我认为对您来说重要的事情很难从经纪人那里获得可靠的（即非销售额）数字。我们在我工作的经纪人那里关注的事情是：
可扩展性：我们选择使用商用硬件进行大多数事情的水平可扩展性
吞吐量：代理维护实时/后备的每个运营商的连接数
故障转移方法：是代理连接到每个可用的运营商上的冗余SMSC / MMSC吗？
连接方法：是直接通过SMPP / MM4 | 7连接的代理，还是直接使用SS7骨干网，即它们有点代码。
排队容量：在邮件丢失之前，如果操作员中断，聚合器可以将邮件排队多长时间？
直接与同行关系：您的潜在交付MNO中有多少直接连接到经纪商以及通过同行达到了多少？
端到端的运输时间
QOS
答案 1 :(得分：1)
你真的打算评估架构，即。聚合器的内部结构？如果我这样做，我会对诸如分解成分，它们的凝聚程度和它们的相对脱离等因素非常感兴趣。出于多种原因，这些都很重要，尤其是产品的未来灵活性。
产品内部结构变得有趣的另一个地方是可扩展性和可用性。如果对这些“能力”提出索赔，我非常想知道“架构如何实现这一目标？”
我认为您采用外部视图，将非功能性需求与产品“功能”相叠加的方法可能是最实用的方法。我也对供应商自身的“能力”感兴趣 - 安装基础是什么，我们是否相信产品的持续支持，产品支持的水平，是时间区域的本地化等。
答案 2 :(得分：0)
要正确评分“疾病”，你应该考虑要求是什么。
您可以尝试尽可能客观地对所有“疾病”进行评分，然后根据要求对每个评分进行加权。
P.S。不应该花费成本（欧元）。对于用户和提供商当然！