2

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

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

是否有一个矩阵可以告诉我在哪里使用这些技术中的一种与另一种。诸如性能，可靠性等之类的东西会有所帮助。

4

3 回答 3

7

如果您有纯 .NET 到 .NET 应用程序，请选择 WCF。当涉及到 TCP/IP 时，它将使您的生活变得简单，但为您的消息传递保留一层很好的面向对象设计。它还使对消息传递代码进行单元测试变得异常容易，我认为这是最大的好处。

WCF 将在本地机器上执行 TCP/IP、管道，它还支持许多基于 HTTP 的解决方案。您还可以免费获得大部分安全性，并且代码在通信层为您做了很多错误处理。

如果您需要 MQ 解决方案，那就玩得开心。支持 MSMQ，但它也是 MSMQ。

使用其他解决方案将受益于更多功能，但功能带来了复杂性和风险。我亲自将一个 .Net 应用程序与 websphere MQ 集成，我对该解决方案的成本和收益不以为然。更不用说 MQ 在非 P 系列硬件上的性能至少可以说是缺乏的。

于 2009-06-04T02:22:20.477 回答
6

排队还是不排队？

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

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

If you like WCF then you going to get a lot for free from it. But basically there are two modes of doing messaging: queued and non-queued. WCF offers a huge matrix of interchangeable channels, bindings, formats, protocols and authentication methods that can be switched in and out at a simple change of the .config file. But they're all for the non queued mode. If your solution is OK with a coupled communication channel then probably there's nothing better than WCF at the moment for CLR applications. If your requirements impose a queued based solution then you'll loose all the cool interchangeable binding toys and you'll leverage from WCF the serialization and maybe the activation model of your service.

And last but not least 90% of the messages sent in any messaging solutions end up in a database and quite a few also originate from a database. If you want a tight integration with SQL Server databases that offers performance while guaranteeing reliable delivery, there is a solution for that in SSB.

于 2009-06-04T03:30:04.397 回答
2

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

  • SOAP - 包括 WS-*
  • REST - XML、JSON、其他
  • 插座
  • 管道
  • 二进制格式
  • Tibco 房车
  • IBM MQ
  • MSMQ
  • 树液
  • 更多

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

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

于 2009-06-04T02:58:55.147 回答