wcf - Tibco EMS 与 MSMQ 与 MQ

Question

关闭。这个问题需要更多focused .它目前不接受答案。












想改善这个问题吗？更新问题，使其仅关注一个问题 editing this post .

6年前关闭。




Improve this question




找不到这个问题的答案，所以想发起这个:

Tibco EMS 对比 MSMQ 对比 MQ .

这三种技术如何比较？
哪个更好，在哪些场景下使用？
具体来说，我认为在 SOA 环境 (.NET + WCF) 中使用其中之一，随着时间的推移，该场景将逐渐成熟。

我对表演还有一个特别的兴趣，值得一提。因此，如果有选择，性能是至关重要的优先事项。

我希望有一张清晰的图片对比表。

谢谢!

编辑 :

我专注于两个参数:性能和可扩展性。
可扩展性 - 这些技术在支持的并发用户数方面如何比较？哪个可以支持更多的用户？场景无关紧要，让我们选择所有人都支持的场景 - 例如简单的队列。
性能 - 在完全相同的场景中，哪个执行得更快？

Answer 1

如果您想使用 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 使用了一段时间，常见的用例应该可以工作 - 如果您不高兴来解决回归错误。