选择消息传递解决方案

Question

所以我正在构建一个客户端服务器应用程序,我必须选择他们将如何相互交谈.我可以:

1. 在客户端和服务器之间建立TCP连接
2. 通过REST或SOAP发送消息
3. 使用Tibco RV,EMS或IBM MQ..

什么地方有一个矩阵可以告诉我在哪里使用这些技术之一.性能,可靠性等等都会有所帮助.

Answer 1

如果您有纯.NET到.NET应用程序,请转到WCF.在执行TCP/IP时,它会让您的生活变得简单,但为您的消息传递保留了一层很好的面向对象设计.它还使得对您的消息传递代码进行单元测试非常容易,这是我认为最大的好处.

WCF将在本地计算机上执行TCP/IP管道,并且它还支持许多基于HTTP的解决方案.您还可以免费获得大部分安全性,并且代码会在通信层中为您执行大量错误处理.

如果您需要MQ解决方案,那么请尽情享受.支持MSMQ,但同样它也是MSMQ.

使用其他解决方案将受益于更多功能,但功能带来复杂性和风险.我个人将.Net应用程序与websphere MQ集成在一起,我对解决方案的成本和收益并不感兴趣.更不用说MQ在非P系列硬件上的性能至少是缺乏的.

Answer 2

排队还是不排队？

您的消息传递解决方案需要什么？

1. 互操作性？您是否需要能够将您的解决方案暴露给其他应用程序？然后你需要使用其中支持的格式和协议之一,99%的情况意味着REST或SOAP
2. 可用性？即使服务器关闭,不可用或正在进行维护,您的客户端是否需要能够发送消息,那么您肯定需要排队的解决方案(MSMQ,MQ,SSB)
3. 安全吗？客户端和服务器是否需要跨信任域进行身份验证？然后,您需要确保您的解决方案具有用于身份验证的非基于域的故事(例如证书).
4. 可靠性？如果客户端崩溃,是否需要恢复发送待处理消息？同样,只有排队的解决方案才有助于此.
5. 相关性？您是否需要按顺序处理相关消息,是否需要对相关消息进行独占访问,是否需要发回回复？并非所有解决方案都提供会话语义.
6. 可扩展性？你需要支持一个客户还是一百万？同样,只有排队的解决方案才能在一定规模后运行.
7. 尖刺？您的流量是否有任何峰值,例如某些时间或天数会飙升？必须计划一个耦合的解决方案,以接受它可能遇到的最高峰值,或者它将毫不客气地拒绝客户端.如果您的硬件无法应对常规峰值,那么您将不得不使用排队解决方案.

如果您喜欢WCF,那么您可以免费获得它.但基本上有两种消息传递模式:排队和非排队.WCF提供了一个巨大的可互换通道,绑定,格式,协议和身份验证方法矩阵,可以通过简单更改.config文件来切换.但他们都是非排队模式.如果你的解决方案没有一个耦合的通信通道,那么对于CLR应用程序来说,目前可能没有比WCF更好的了.如果您的要求强加了基于排队的解决方案,那么您将放弃所有酷的可互换绑定玩具,并且您将利用WCF的序列化和服务的激活模型.

最后但并非最不重要的是,在任何消息传递解决方案中发送的消息中有90%最终存在于数据库中,而且很多消息也来自数据库.如果您希望与SQL Server数据库紧密集成,在保证可靠交付的同时提供性能,那么SSB中就有了解决方案.