何时使用 Java 和 Message Broker？

When to use Java and Message Broker?

提问by Richie

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.

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

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.

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

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.

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

-RDJ

-RDJ

回答by mwittrock

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.

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

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 中设计一个通用的转换/路由解决方案，您将设计一个消息代理 :) 这会很有趣，但并不是真正必要的，因为已经有大量的商业和开源消息代理可用。

回答by Gopi

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.

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

回答by steve vaughn

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.

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

Also, Java is not particularly well suited to process XML. Both ESQL and XSLT are much better vehicles for xml transformation that Java.

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

Webshpere message broker is also able to deal with messaging outside the limitations of JMS (it can do JMS as well).

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

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 ESB，它有点像消息代理的 Java 实现。该产品希望外部的非ja​​va应用程序能够适应Java世界，所以它的集成能力较差，但我认为java人会觉得用起来很舒服。

回答by A. Parvini

Messaging is usually used when you have Heterogeneous application integration and may be used as a replacement for RPC specially when it is Asynchronous. It is also used to loosen the coupling between applications and as the backbone of an event-driven architecture. Using message to improve application scalability is very common. In some cases it is used for the systems which are not always available but guarantee to fulfill the request when they become available. Also it is used for systems which have more than one consumer per request.

消息传递通常在您具有异构应用程序集成时使用，并且特别是在异步时可以用作 RPC 的替代品。它还用于放松应用程序之间的耦合并作为事件驱动架构的支柱。使用消息来提高应用程序的可伸缩性非常普遍。在某些情况下，它用于并非始终可用但保证在可用时满足请求的系统。它还用于每个请求具有多个消费者的系统。

回答by sRiRaJ mISHrA

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 .

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

回答by TJA

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.

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

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.

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

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.

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

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.

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

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.

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