找不到这个问题的答案，所以想发起这个：
Tibco EMS与MSMQ与MQ。
这 3 种技术如何比较？哪一个更好，在哪些场景下？具体来说，我认为在 SOA 环境（.NET + WCF）中使用其中之一，该场景将随着时间的推移而成熟。
我对表演还有一个特别的兴趣，这一点很重要。因此，如果有选择，性能是重中之重。
我希望有一个比较表以获得清晰的图片。
谢谢！
编辑：
我专注于两个参数：性能和可扩展性。 可扩展性——这些技术在支持的并发用户数方面如何比较？哪个可以支持更多用户？场景无关紧要，让我们选择它们都支持的场景 - 例如简单的队列。 性能——在完全相同的场景下，哪个性能更快？
如果你想使用 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 被使用了一段时间，常见的用例应该可以工作——如果你不乐意遇到回归错误的话。
对于一个简单的集成场景 - 即 2 个应用程序以点对点方式交互，不会有任何区别。您最好检查应用程序中每种技术的支持情况。在这种情况下，您不应该担心性能，因为消息传递时间不应该是主要问题。另一方面，真正的选择将基于整合整个企业的目标模型。例如， - 您是否正在执行任何中介功能 - 例如：数据转换、协议映射......等等 - 您是否会以点对点的方式集成系统，或者您可能会考虑使用 Hub / ESB？- 您是否会涵盖集成场景中的安全方面（授权、身份验证、审计、加密、证书交换...... 等）最终拥有这样的愿景将更好地理解您对设计的真正限制。就个人而言，只有当我不期待复杂的集成场景并且我不愿意在解决方案上花钱时，我才会选择 WCF。如果我正在为 SOA 建立基础，我会选择 IBM。如果我计划在定义范围内进行基于 Java 的集成，我会去 Tibco。
同样，它是昂贵的商业解决方案，更适合涉及大型机的企业场景
不知道你为什么提到大型机。许多 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 具有无限的可扩展性。即使没有调整，性能也非常好。
只有当您需要与大量大型机集成时，MQ 才是最好的。Pub/Sub 的实现很差，许多 API 都“使用起来很奇怪”。
如果您的所有应用程序都是 Windows，MSMQ 可能是一个不错的选择，但很难桥接到 Unix 或 Java 世界。
整个 Java 社区都在 JMS 上进行了标准化，因此如果您想连接非 Windows 应用程序，TIBCO EMS 是一个不错的选择。