【问题标题】:Tibco EMS vs. MSMQ vs. MQ [closed]Tibco EMS vs. MSMQ vs. MQ [关闭]
【发布时间】:2011-12-09 03:19:32
【问题描述】:

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

Tibco EMS vs. MSMQ vs. MQ

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

我对表演还有一个特别的兴趣,这一点很重要。因此,如果有选择,性能是重中之重。

如果有一张比较表,我会很感激。

谢谢!

编辑

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

【问题讨论】:

    标签: wcf msmq tibco mq ems


    【解决方案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 有哪些问题,有几个问题/cmets?作为几个例子,您可以查看my MQ questions。并非每个问题实际上都是一个问题,但您会发现其中很少有人直接指向错误。这些问题已经可以在新的 MQ 客户端版本中得到解决,但这并不意味着没有其他问题。一般来说,我发现 MQ .NET API 是我用过的最令人沮丧的库 - 它甚至击败了讨厌的 SharePoint。

    另一方面,如果您只需要发送和接收一些消息并且不打算做任何特殊的事情或使用低级功能,那么您应该没问题。最后,API 使用了一段时间,常见的用例应该可以工作 - 如果您不乐意遇到回归错误。

    【讨论】:

    • 谢谢拉迪斯拉夫,有趣的回答。我想提一下,该解决方案将在企业世界中实施。此外,公司已经拥有EMS许可证,因此我只需要明确选择“选择什么”和“为什么”使用它。虽然不是很清楚地了解性能和可扩展性的差异。
    • 如果您拥有 EMS 许可证,则无需考虑 IBM 解决方案。使用EMS,直接通过Tibco.EMS.dll库使用。 EMS 有 WCF 绑定,但该库更易于使用。
    • EMS 和 MSMQ 怎么样呢?在这种情况下,EMS 会更好吗?
    • 您是想只构建 .NET 到 .NET/WinAPI 的解决方案,还是需要与 Java 世界或某些大型机进行企业级集成? MSMQ 是唯一的 MS 技术。该选择很大程度上取决于您的应用。要求以及贵公司的 IT 文化/政策。在企业中已经使用类似 (EMS) 的情况下引入新技术 (MSMQ) 通常是不受欢迎的。
    • @raffian:我编辑了我的答案并添加了一些我以前遇到的问题的链接示例。
    【解决方案2】:

    对于简单的集成场景 - 即 2 个应用程序以点对点方式交互,不会有任何区别。您最好检查应用程序中每种技术的支持情况。在这种情况下,您不应该担心性能,因为消息传递时间不应该是主要问题。另一方面,真正的选择将基于整合整个企业的目标模型。例如, - 您是否在做任何中介功能 - 例如:数据转换、协议映射...等 - 您是否会以点对点的方式集成系统,或者您可能会考虑拥有一个集线器/ESB? - 您是否会涵盖集成方案中的安全方面(授权、身份验证、审计、加密、证书交换......等) 最终拥有这样的愿景将使您更好地了解您对设计的真正限制。就个人而言,只有当我不期待复杂的集成场景并且我不愿意在解决方案上花钱时,我才会选择 WCF。如果我正在为 SOA 建立基础,我会选择 IBM。如果我正在计划基于 Java 的具有定义范围的集成,我会去 Tibco。

    【讨论】:

      【解决方案3】:

      再次是昂贵的商业解决方案,更适合企业场景 涉及大型机的地方

      不知道您为什么提到大型机。许多 MQ 企业客户没有。

      IBM MQ - IBM 技术支持队列,它还以某种方式模拟 主题(发布/订阅)

      MQ v7.0.0(2008 年发布)及更高版本支持将发布/订阅主题作为本机功能,不涉及模拟。

      Java 和 .NET 的 API 都很糟糕。

      Java 和 JMS 的 MQ 类已经发展了 10 多年,并被数千家企业大量使用。

      .NET API 漏洞百出,无法按预期工作。

      .Net API 在 MQ 的几个主要版本中已经存在了 7 年多。我想现在明显的错误应该已经被消除了。

      我专注于两个参数:性能和可扩展性。

      MQ 具有无限的可扩展性。即使没有调整,性能也非常好。

      【讨论】:

      • 看起来您在为 IBM 工作...... API 发展了多长时间并不重要。它根本不是 Java 或 .NET API,而是重写了 C 代码,负责 .NET API 开发的团队间接向我证实了这一点,他们还证实了 .NET API 中的一些回归(或者可能完全未经测试)的错误特性。我遇到的几乎每一个 .NET/Java 开发人员都提到了 IBM API 和一些服务器以及他们不想再次使用的东西,这也是事实。
      【解决方案4】:

      只有当您需要与大量大型机集成时,MQ 才是最佳选择。 Pub/Sub 的实现很差,许多 API 都“用起来很奇怪”。

      如果您的所有应用程序都是 Windows,MSMQ 可能是一个不错的选择,但很难桥接到 Unix 或 Java 世界。

      整个 Java 社区都在 JMS 上进行了标准化,因此如果您想连接非 Windows 应用程序,TIBCO EMS 是一个不错的选择。

      【讨论】:

      • “Pub/Sub 的实现很差,而且许多 API '用起来很奇怪'。”请您扩展此评论吗?
      • 嗯,在 TIBCO EMS 中,Pub/Sub 从一开始就存在。但是在 WebSphere MQ 中,发布/订阅是在队列之上实现的。所以基础架构是队列,而不是主题。这意味着您有 EMS 不需要的额外读写操作。
      猜你喜欢
      • 2014-11-24
      • 2023-03-30
      • 2016-10-21
      • 2010-12-11
      • 2011-04-03
      • 2011-04-03
      • 2015-04-26
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多