无法在这个问题上找到答案，所以想发起这个：
Tibco EMS 与 MSMQ 与 MQ 。
这3项技术如何比较？ 哪一个更好，哪种情况？ 具体来说，我认为在SOA环境（.NET + WCF）中使用其中一个，其中场景将随着时间的推移而成熟。
我对表演有一个额外的特殊兴趣，这一点很重要。因此，如果给予选择，性能是至关重要的。
我希望有一张清晰图片的比较表。
谢谢！
修改：
我专注于两个参数：性能和可伸缩性。 可扩展性 - 这些技术如何在支持的并发用户数量方面进行比较？哪个可以支持更多用户？场景无关紧要，让我们选择所有场景支持的场景 - 例如简单的队列。 性能 - 在完全相同的情况下，执行速度更快？
答案 0 :(得分：10)
如果你想使用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有什么问题，有几个问题/评论？您可以查看my MQ questions的示例。并非每个问题都是一个问题，但你会发现很少有人直接指向错误。这些问题已经可以在新的MQ客户端版本中修复，但这并不意味着没有其他问题。一般来说，我发现MQ .NET API是我曾经使用过的最令人沮丧的库 - 它甚至憎恨恶意的SharePoint。
另一方面，如果您只需要发送和接收某些消息，并且不打算做任何特殊的事情或使用低级功能，那么您应该没问题。最后，API会被使用一段时间，并且常见的用例应该起作用 - 如果你不满足于回归错误。
答案 1 :(得分：1)
对于简单的集成场景 - 即2个以点对点方式交互的应用程序，没有区别。您最好检查应用程序中每种技术的支持。在这种情况下，您不应该担心性能，因为消息传递时间不应该是主要问题。另一方面，真正的选择将基于整合整个企业的目标模型。例如， - 你在做任何调解功能 - 例如：数据转换，协议映射等等 - 您是否会以点对点的方式集成系统，或者您可能考虑使用Hub / ESB？ - 您是否会介绍集成方案中的安全方面（授权，身份验证，审核，加密，证书交换......等） 最后，拥有这样的愿景将更好地理解您对设计的真正限制。就个人而言，只有当我不期待复杂的集成场景并且我不愿意在解决方案上花钱时，我才会选择WCF。如果我正在为SOA构建基础，我会选择IBM。如果我计划在定义的范围内进行基于Java的集成，那么将会转到Tibco。
答案 2 :(得分：0)
同样，昂贵的商业解决方案更适合企业场景 涉及大型机的地方
不确定为什么提到大型机。许多MQ企业客户没有它们。
IBM MQ - IBM技术支持队列，它也以某种方式模拟 主题（发布/订阅）
MQ v7.0.0（2008年发布）及以后版本支持pub / sub主题作为本机功能，不涉及仿真。
Java和.NET的API都很糟糕。
Java和JMS的MQ类已经发展了10多年，并被成千上万的企业大量使用。
.NET API充满了错误，并且没有按预期工作。
.Net API在MQ的几个主要版本上已经存在了7年多。我想，现在已经动摇了明显的错误。
我专注于两个参数：性能和可伸缩性。
MQ具有无限的可扩展性。即使没有调整，性能也非常好。
答案 3 :(得分：0)
只有在需要与大量大型机集成时，MQ才是最佳选择。 Pub / Sub实现得很差，许多API“使用起来很奇怪”。
如果您的所有应用程序都是Windows，那么MSMQ可能是一个不错的选择，但很难跨接到Unix或Java世界。
整个Java社区在JMS上标准化，因此如果您想要连接非Windows应用程序，TIBCO EMS是一个不错的选择。