选择消息传递解决方案

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. 的尖峰？您的流量是否有任何峰值，例如某些时间或天数会飙升？必须计划一个耦合的解决方案，以接受它可能遇到的最高峰值，或者它将毫不客气地拒绝客户端。如果您的硬件无法应对常规峰值，那么您将不得不使用排队解决方案。

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

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

Answer 3

在.NET上构建通信应用程序时，答案几乎总是WCF。 WCF确实

• SOAP - 包括WS - *
• REST - XML，JSON，其他
• 插座
• 管
• 二进制格式
• Tibco RV
• IBM MQ
• MSMQ
• SAP
• 更多

WCF背后的理念是：它是一个通用的通信框架，可以映射到您希望使用的任何通信基板上。这意味着编程模型是一致的，概念是一致的，并且操作/管理是一致的。如果您选择WCF并且想要记录，则无论您选择何种基材，它都以相同的方式工作。并且，如果选择WCF，则可以在各方为本地时使用命名管道，并在分发时切换到TCP。它不需要更改代码，只需更改配置。这可能很好。

至于选择基材 - 嗯，这取决于你。取决于您需要的功能和要求。