If you want to use WCF than non of them really matters. You will get most of them only when you use their direct API.
MSMQ - MS technology installed with every Windows installation. It is only transport technology with support for queues.
Tibco EMS - Tibco technology supporting both queues and topics (publish/subscribe). It is expensive and more suitable for enterprise scenarios. You will most probably need other Tibco tools and technologies as well to implement full SOA solution (Tibco ActiveMatrix product suite). .NET and WCF will be only apps connected to this infrastructure which is more designed for Java world. It runs on non Windows platforms as well and together with Tibco Business Works it offers connectors (adapters) to many LOB applications. I like APIs for Tibco products but I really don't like UIs of their tools.
IBM MQ - IBM technology supporting queues and it also somehow emulates topics (publish/subscribe). Again it is expensive commercial solution more suitable for enterprise scenarios where mainframes are involved - that is biggest MQ advantage - it runs "everywhere". But that is end of advantages. APIs for both Java and .NET are terrible. .NET API is full of bugs and it doesn't work as expected. IBM doesn't understand .NET libraries versioning which leads to terrible problems when moving your client application to machines with different MQ clients installed, etc.
Edit:
There were several question / comments about what problems MQ has? As few examples you can check my MQ questions. Not every question is actually an issue but you will find few of them pointing directly to bugs. Those issues can already be fixed in new MQ client versions but that doesn't mean there are no other. Generally I found MQ .NET API the most frustrating library I have ever used - it even beaten hated SharePoint.
On the other hand if you just need to send and receive some message and don't plan to do anything special or use low level features you should be OK. At the end the API is used for a while and common use cases should work - if you are not happy enough to hit regression bugs.
For a simple integration scenario - i.e. 2 applications interacting in a Point to point manner , no difference will be there. You would better check the support of each technology within your applications. And in that type of scenarios, you shouldn't be worried about performance as the messaging time shouldn't be the main issue. On the other hand, the real selection would be based on the target model for integrating your whole enterprise. For example, - Are you doing any mediation functions - e.g: data transformation, protocol mapping ...etc - Will you integrate systems in a point to point manner or you may consider having a Hub / ESB? - Will you cover security aspects in your integration scenario (Authorization, authentication, auditing, encryption, certificate exchange ...etc) Finally having such vision will give better understanding of what real constraints you've for your design. Personally, I would go for WCF only if I'm not expecting complex integration scenarios and I'm not willing to spend money on the solution. And I would go for IBM if I'm building a foundation for SOA. And will go to Tibco if I'm planning a Java based integration with a defined scope.
发布评论
评论（4）
如果您想使用 WCF，那么它们都不重要。只有当您使用他们的直接 API 时，您才能获得其中的大部分。
MSMQ - 每次安装 Windows 时都会安装 MS 技术。它是唯一支持队列的传输技术。
Tibco EMS - 支持队列和主题（发布/订阅）的 Tibco 技术。价格昂贵，更适合企业场景。您很可能还需要其他 Tibco 工具和技术来实施完整的 SOA 解决方案（Tibco ActiveMatrix 产品套件）。 .NET 和 WCF 将是唯一连接到该基础设施的应用程序，该基础设施更多地是为 Java 世界设计的。它也可以在非 Windows 平台上运行，并与 Tibco Business Works 一起为许多 LOB 应用程序提供连接器（适配器）。我喜欢 Tibco 产品的 API，但我真的不喜欢他们工具的 UI。
IBM MQ - 支持队列的 IBM 技术，它还以某种方式模拟主题（发布/订阅）。同样，它是昂贵的商业解决方案，更适合涉及大型机的企业场景 - 这是最大的 MQ 优势 - 它“无处不在”运行。但这就是优势了。 Java 和.NET 的 API 都很糟糕。 .NET API 充满了错误，并且无法按预期工作。 IBM 不理解 .NET 库版本控制，这会在将客户端应用程序移动到安装了不同 MQ 客户端的计算机等时导致可怕的问题。
编辑：
有几个关于 MQ 有哪些问题的问题/评论？作为几个示例，您可以查看我的 MQ 问题。并非每个问题实际上都是问题，但您会发现其中很少有问题直接指向错误。这些问题已经可以在新的 MQ 客户端版本中得到解决，但这并不意味着没有其他问题。总的来说，我发现 MQ .NET API 是我用过的最令人沮丧的库 - 它甚至击败了令人讨厌的 SharePoint。
另一方面，如果您只需要发送和接收一些消息并且不打算做任何特殊的事情或使用低级功能，那么您应该没问题。最后，API 使用了一段时间，常见的用例应该可以工作 - 如果您不愿意遇到回归错误。
If you want to use WCF than non of them really matters. You will get most of them only when you use their direct API.
MSMQ - MS technology installed with every Windows installation. It is only transport technology with support for queues.
Tibco EMS - Tibco technology supporting both queues and topics (publish/subscribe). It is expensive and more suitable for enterprise scenarios. You will most probably need other Tibco tools and technologies as well to implement full SOA solution (Tibco ActiveMatrix product suite). .NET and WCF will be only apps connected to this infrastructure which is more designed for Java world. It runs on non Windows platforms as well and together with Tibco Business Works it offers connectors (adapters) to many LOB applications. I like APIs for Tibco products but I really don't like UIs of their tools.
IBM MQ - IBM technology supporting queues and it also somehow emulates topics (publish/subscribe). Again it is expensive commercial solution more suitable for enterprise scenarios where mainframes are involved - that is biggest MQ advantage - it runs "everywhere". But that is end of advantages. APIs for both Java and .NET are terrible. .NET API is full of bugs and it doesn't work as expected. IBM doesn't understand .NET libraries versioning which leads to terrible problems when moving your client application to machines with different MQ clients installed, etc.
Edit:
There were several question / comments about what problems MQ has? As few examples you can check my MQ questions. Not every question is actually an issue but you will find few of them pointing directly to bugs. Those issues can already be fixed in new MQ client versions but that doesn't mean there are no other. Generally I found MQ .NET API the most frustrating library I have ever used - it even beaten hated SharePoint.
On the other hand if you just need to send and receive some message and don't plan to do anything special or use low level features you should be OK. At the end the API is used for a while and common use cases should work - if you are not happy enough to hit regression bugs.
对于简单的集成场景 - 即 2 个应用程序以点对点方式交互，不会有任何差异。您最好检查应用程序中每种技术的支持情况。在这种类型的场景中，您不应该担心性能，因为消息传递时间不应该是主要问题。另一方面，真正的选择将基于集成整个企业的目标模型。例如，
- 您是否在执行任何中介功能 - 例如：数据转换、协议映射...等
- 您会以点对点的方式集成系统吗？或者您可能会考虑拥有 Hub / ESB？
- 您是否会涵盖集成场景中的安全方面（授权、身份验证、审核、加密、证书交换等）
最后，拥有这样的愿景将使您更好地理解您的设计所面临的真正限制。就我个人而言，只有当我不期望复杂的集成场景并且我不愿意在解决方案上花钱时，我才会选择 WCF。如果我要为 SOA 打下基础，我会选择 IBM。如果我计划在定义的范围内进行基于 Java 的集成，我会选择 Tibco。
For a simple integration scenario - i.e. 2 applications interacting in a Point to point manner , no difference will be there. You would better check the support of each technology within your applications. And in that type of scenarios, you shouldn't be worried about performance as the messaging time shouldn't be the main issue. On the other hand, the real selection would be based on the target model for integrating your whole enterprise. For example,
- Are you doing any mediation functions - e.g: data transformation, protocol mapping ...etc
- Will you integrate systems in a point to point manner or you may consider having a Hub / ESB?
- Will you cover security aspects in your integration scenario (Authorization, authentication, auditing, encryption, certificate exchange ...etc)
Finally having such vision will give better understanding of what real constraints you've for your design. Personally, I would go for WCF only if I'm not expecting complex integration scenarios and I'm not willing to spend money on the solution. And I would go for IBM if I'm building a foundation for SOA. And will go to Tibco if I'm planning a Java based integration with a defined scope.
不确定您为什么提到大型机。许多 MQ 企业客户没有它们。
MQ v7.0.0（2008 年发布）及更高版本支持发布/订阅主题作为本机功能，不涉及模拟。
Java 和 JMS 的 MQ 类已经发展了 10 多年，并被数千家企业大量使用。
.Net API 已经在 MQ 的几个主要版本中存在了 7 年多了。我想现在那些明显的错误应该已经被消除了。
MQ具有无限的可扩展性。即使没有调整，性能也非常好。
Not sure why you mentioned mainframes. Many MQ enterprise customers don't have them.
MQ v7.0.0 (released 2008) and onwards supports pub/sub topics as a native feature, there is no emulation involved.
The MQ Classes for Java and JMS have evolved over 10+ years and are used heavily by thousands of enterprises.
The .Net API has been around for 7+ years over a few major releases of MQ. I would imagine that the obvious bugs would have been shaken out by now.
MQ has unlimited scalability. Performance is very good even with no tuning.
仅当您需要与大量大型机集成时，MQ 才是最佳选择。 Pub/Sub 的实现很差，并且许多 API “用起来很奇怪”。
如果您的所有应用程序都是 Windows，MSMQ 可能是一个不错的选择，但很难桥接到 Unix 或 Java 世界。
整个 Java 社区都在 JMS 上进行了标准化，因此如果您想要连接非 Windows 应用程序，TIBCO EMS 是一个不错的选择。
MQ is best only if you need to integrate with lots of mainframes. Pub/Sub is implemented poorly and the many APIs are 'strange to use'.
If all your applications are Windows, MSMQ might be a good choice, but it will be difficult to bridge into Unix or Java worlds.
The whole Java community standardized on JMS so TIBCO EMS is a good choice if you ever want to connect non-Windows applications.