我是我办公室的一名开发人员，那里的 SOA 开发正处于顶峰。我们使用 IBM MQ、IBM Message Broker 和 Java/J2EE 技术。
我目前被投入到使用 Message Broker 开发在两个应用程序之间进行交互的中间件的项目中。我不太确定 Message Broker 是否是此类项目的正确选择，因为 Java 可以以非常有效的方式完成相同的工作，这导致我在 Internet 上搜索使用这两者的优势。
我在不同的站点中读到 Message Broker 用于转换、路由和增强消息，这可以很好地使用 java 有效地完成。所以这让我想到了这个问题“何时使用 Java 以及何时使用 Message Broker 进行开发？” 如果有人可以帮助我利用两者的优势，那就太好了。
-RDJ
消息代理使例如操作人员能够在一个地方监控所有集成。此外，如果数据格式发生更改，确定哪些集成受更改影响可能很简单。
每个单独的集成可能都可以用 Java（或任何其他语言，就此而言）实现，但您最终会得到一堆点对点集成，这是消息代理试图解决的问题之一。
如果您要在 Java 中设计一个通用的转换/路由解决方案，您将设计一个消息代理 :) 这会很有趣，但并不是真正必要的，因为已经有大量的商业和开源消息代理可用。
据我了解，您正在尝试例如在核心 java 中实现功能，而不是使用现成的 Message Broker 和类似的 SOA 相关技术。我的建议是——不要重新发明轮子。关键是，即使您尝试这样做，最终您也会面临相同的技术问题并导致类似的解决方案。为什么不专注于业务逻辑，而不是尝试开发一个已经存在的、可能经过更多测试和信任的东西的等价物。
从更实用的角度来看，websphere 消息代理提供了一种集成非 java 应用程序（C、COBOL、PHP、VB ...）的方法，这通常很难用 java 完成。
此外，Java 并不是特别适合处理 XML。ESQL 和 XSLT 都是比 Java 更好的 xml 转换工具。
Webshpere 消息代理还能够处理 JMS 限制之外的消息传递（它也可以处理 JMS）。
您可能会看到 Websphere ESB，它有点像消息代理的 Java 实现。该产品期望外部非 Java 应用程序能够适应 Java 世界，因此它的集成能力较低，但我认为 Java 人会觉得使用它很舒服。
Websphere Message Broker 是一种 ESB，而另一方面，Java 是一种编程语言。有些 ESB 使用 Java 作为其实现语言，如 Axis、Fuse，但它们是否足够强大以解析 XML、编排服务、与大型机系统集成。Message Broker 中的 Web 服务设计和开发简单且用户友好。正确指出的 ESQL强大的 XML 转换和处理是 Message Broker 中使用的实现语言。同样，与 MQ、HTTP、文件节点的集成在 MB 中是无缝且高效的。
首先要了解的是，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 计算节点。