何时使用 Java 和 Message Broker？答案

【问题标题】：When to use Java and Message Broker?何时使用 Java 和 Message Broker？
【发布时间】：2011-03-26 21:03:16
【问题描述】：

我是我办公室的一名开发人员，那里的 SOA 开发正处于高峰期。我们使用 IBM MQ、IBM Message Broker 和 Java/J2EE 技术。

我目前被投入到使用 Message Broker 开发在两个应用程序之间进行交互的中间件的项目中。我不太确定 Message Broker 是否是此类项目的正确选择，因为 Java 可以以非常有效的方式完成相同的工作，这导致我在 Internet 上搜索使用这两者的优势。

我在不同的站点中读到 Message Broker 用于转换、路由和增强消息，这可以很好地使用 java 有效地完成。所以这让我想到了这个问题“何时使用 Java 以及何时使用 Message Broker 进行开发？”如果有人可以帮助我了解使用两者的优势，那就太好了。

-RDJ

【问题讨论】：

您是说 JMS 还是 IBM Message Broker ？
@YoK : 我指的不只是 JMS，我指的是 Java 支持的 SOA 的整个概念

标签： java soa messagebroker

【解决方案1】：

据我了解，例如，您正在尝试在核心 java 中实现功能，而不是使用现成的 Message Broker 和类似的 SOA 相关技术。我的建议是——不要重新发明轮子。关键是，即使您尝试这样做，最终您也会面临相同的技术问题并导致类似的解决方案。为什么不专注于业务逻辑，而不是尝试开发一个已经存在的、可能经过更多测试和信任的东西的等价物。

【讨论】：

非常感谢 Gopi :) 请在下面查看我的 cmets 以了解 mwittrock..“是否存在应该使用 Message Broker 而不是 Java WS 的情况？”

【解决方案2】：

消息代理启用例如操作人员在一个地方监控所有集成。此外，如果数据格式发生更改，确定哪些集成受到更改影响也很容易。

每个单独的集成可能都可以用 Java（或任何其他语言，就此而言）实现，但您最终会得到一堆点对点集成，这是消息代理尝试的问题之一解决。

如果您要在 Java 中设计一个通用的转换/路由解决方案，那么您将设计一个消息代理 :) 这会很有趣，但并不是真正必要的，因为已经有大量的商业和开源消息代理可用。

【讨论】：

感谢 mwittrock 提供的信息 :) 仍然让我感到困惑的是，我们可以使用一些路由和转换 java 位来创建一个 Web 服务，以使同样的事情以更短的响应时间工作。有没有应该使用 MB 而不是 java 的场景？
在大多数情况下，您已经决定是否将所有集成都基于某种中间件组件。
@Richie 我认为 mwittrock 的主要观点是您可以自己编写，这取决于您所拥有的复杂性和维护成本与开发速度之间的权衡。与内部 Java 应用程序相比，像代理这样成熟的 ESB 有很多优势，如果您要使用它的功能，如果不使用它，那么它可能会代价高昂。您是否有高技能的程序员为您编写 Java？您是否需要监控数据流、分析支持、审计、流程管理、运营控制的能力？您想花钱请人支持还是自己提供？

【解决方案3】：

从更实际的角度来看，websphere 消息代理提供了一种集成非 java 应用程序（C、COBOL、PHP、VB ...）的方法，这通常很难用 java 完成。

此外，Java 也不是特别适合处理 XML。 ESQL 和 XSLT 都是比 Java 更好的 xml 转换工具。

Webshpere 消息代理还能够处理超出 JMS 限制的消息传递（它也可以处理 JMS）。

您可能会看到 Websphere ESB，它有点像消息代理的 Java 实现。该产品期望外部非 Java 应用程序自己适应 Java 世界，因此它的集成能力较差，但我认为 Java 人会觉得使用它很舒服。

【讨论】：

【解决方案4】：

Websphere Message Broker 是一种 ESB，而另一方面，Java 是一种编程语言。有些 ESB 使用 Java 作为其实现语言，如 Axis、Fuse，但它们是否足够强大以解析 XML、编排服务、与大型机系统集成。Message Broker 中的 Web 服务设计和开发简单且用户友好。正确指出的 ESQL强大的 XML 转换和处理是 Message Broker 中使用的实现语言。同样，与 MQ、HTTP、文件节点的集成在 MB 中是无缝且高效的。

【讨论】：

【解决方案5】：

首先要了解的是，Broker 的 Java-API 位于 C-API 之上，不能让您完全访问所有可用功能。

其次它很丑，我不会将它用于简单的映射转换，当然现在还有可视化映射器。

也就是说，它在特殊情况下仍然有用。我使用它的一个例子是匹配合并一些消息内容。基本上，该场景是接收包含 2000 多个元素的 Msg1，然后获取包含 2000 多个元素的相应消息 Msg2，提供更多详细信息。

因此，在 ESQL 中，您只能从 Msg1.element[1] 开始，然后扫描 Msg2 以进行匹配，为了优化，您可以在 Msg2 用完时删除元素。就 CPU 而言，它仍然非常昂贵，尤其是当事情开始从 2000+ 扩展到 5000+ 时。非常大的消息需要很长时间，超过 5 分钟。

替代方法是使用 Java 计算节点并将第二条消息的内容加载到 Java Tree 对象中，这将处理时间减少到大约 3 秒。

因此，如果您只是进行转换，请避开 Java 计算节点。但是，如果您正在做一些更复杂和/或 CPU 密集型的事情，那么一定要试试 Java 计算节点。

【讨论】：