何时使用 Java 和 Message Broker？
我是一名开发人员，我所在的办公室是 SOA 开发的巅峰时期。我们使用 IBM MQ、IBM Message Broker 和 Java/J2EE 技术。
我目前参与的项目中使用 Message Broker 来开发在两个应用程序之间交互的中间件。我不太确定 Message Broker 是否是此类项目的正确选择，因为 Java 可以以非常有效的方式完成相同的工作，这导致我在 Internet 上搜索使用这两者的优势。
我在不同的网站上读到消息代理用于转换、路由和增强消息，这可以很好地使用 java 有效地完成。所以这让我想到了这个问题“什么时候使用Java，什么时候使用Message Broker进行开发？”如果有人可以帮助我了解使用两者的优点，那就太好了。
-RDJ
I am a developer at my office where SOA development is at its peaks. We use IBM MQ, IBM Message Broker and Java/J2EE Technologies.
I have been currently put into project where Message Broker is used to develop a middleware which interacts between two applications. I am not quite sure if Message Broker is the right option for such kind of a project since Java can do the same piece of work in a much efficient way, which led me to search Internet for advantages in using the two.
I read in different sites that Message Broker is used to transform,route and enhance messages, this can very well be done using java efficiently. So this led me to this question "When to use Java and When to use Message Broker for development?" It would be great if someone can help me with the advantages of using the two.
-RDJ
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
消息代理使操作人员能够在一处监控所有集成。此外，如果数据格式发生变化，确定哪些集成受到变化的影响可能很简单。
每个单独的集成可能都可以用 Java（或任何其他语言）来实现，但最终会得到一堆点对点集成，这是消息代理试图解决的问题之一。
如果您要使用 Java 设计通用转换/路由解决方案，那么您将设计一个消息代理 :) 这会很有趣，但并不是真正必要，因为已经有大量的商业和开源消息代理可用。
Message brokers enable e.g. operations people to monitor all integrations in one place. Also, if a data format changes it can be trivial to determine which integrations are affected by the change.
Each individual integration could probably be implemented in Java (or any other language, for that matter), but you'd end up but with a bunch of point-to-point integrations, which is one of the problems message brokers try to solve.
If you were to design a generalized transformation/routing solution in Java, you would be designing a message broker :) Which would be interesting, but not really necessary, seeing as plenty of commercial and open source message brokers are already available.
据我了解，您正在尝试，例如，在核心 java 中实现功能，而不是使用现成的消息代理和类似的 SOA 相关技术。
我的建议是——不要重新发明轮子。关键是，即使您尝试这样做，最终您也会面临相同的技术问题并导致类似的解决方案。为什么不专注于业务逻辑，而不是尝试开发一个已经存在的、可能经过更多测试和信任的等价物。
As I understand you are trying to, for example, implement the functionality in core java instead of going with a ready Message Broker and similar SOA related technologies.
My suggestion is - do not reinvent the wheel. The point is, even if you try to do so, eventually you will face the same technical issues and lead to a similar solution. Why not focus on business logic instead of trying to develop an equivalent of something which is already there which is probably more tested and trusted.
从更实际的角度来看，WebSphere 消息代理提供了一种集成非 Java 应用程序（C、COBOL、PHP、VB ...）的方法，这通常很难用 Java 来完成。
而且，Java 并不是特别适合处理 XML。 ESQL 和 XSLT 都是比 Java 更好的 xml 转换工具。
Webshpere 消息代理还能够处理 JMS 限制之外的消息传递（它也可以处理 JMS）。
您可能会看看 Websphere ESB，它有点像消息代理的 Java 实现。该产品期望外部非java应用程序能够适应Java世界，因此它的集成能力较差，但我认为java人员会觉得使用起来很舒服。
From a more practical standpoint, websphere message broker offers a way to integrate non-java applications (C, COBOL, PHP, VB ...) which is often difficult to accomplish with java.
Also, Java is not particularly well suited to process XML. Both ESQL and XSLT are much better vehicles for xml transformation that Java.
Webshpere message broker is also able to deal with messaging outside the limitations of JMS (it can do JMS as well).
You might look at Websphere ESB which is kind of like a Java implementation of message broker. This product expect external non-java applications to adapt themselves to the Java world, so it has less integration capability, but I think java people will find it comfortable to work with.
Websphere Message Broker 是一种 ESB，而 Java 则是一种编程语言。
有些 ESB 使用 Java 作为其实现语言，如 Axis、Fuse，但它们是否足够强大来解析 XML、编排服务、与大型机系统集成。Message Broker 中的 Web 服务设计和开发非常简单且用户友好。正如正确指出的那样，ESQL Message Broker 中使用的实现语言具有强大的 XML 转换和处理能力。同样，与 MQ、HTTP、文件节点的集成在 MB 中是无缝且高效的。
Websphere Message Broker is an ESB whereas Java on the other hand is a programming language .
There are ESBs which use Java as their implementation language like Axis , Fuse but are they powerful enough to parse XMLs , orchestrate services , integrate with mainframe systems .Webservice design and development in Message Broker is easy and user -friendly .ESQL as correctly pointed out is powerful for XML transformation and processing is the implementaion language used in Message Broker . Again , integration with MQ , HTTP , File nodes is seamless and efficent in 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 计算节点。
First thing to understand is that the Java-API for Broker sits on top of the C-API and does not give you full access to all the available functionality.
Secondly its Ugly, I would not use it for simple mapping transformations, and of course these days there is the visual mapper as well.
That said its still useful in special circumstances. One example where I used it was to match merge some message content. Basically the scenario was receive Msg1 containing 2000+ elements and then get a corresponding message Msg2 containing 2000+ elements that provided additional detail.
So in ESQL you are reduced to starting with Msg1.element[1] and then scanning Msg2 for a match, to optimise you can delete elements from Msg2 as they get used up. Still it was horrendously expensive in terms of CPU especially once things started to scale up from 2000+ to 5000+. And it took a long time, over 5 minutes for really large messages.
The alternative was to use the Java compute node and load the content of the second message into a Java Tree object, this reduced the processing time to about 3 seconds.
So if you are just doing transformation steer clear of the Java compute node. If however you are doing something more complex and/or CPU intensive then certainly give the Java compute node a try.