何时使用Java和Message Broker？

Question

我是我办公室的开发人员，在那里SOA开发达到顶峰。我们使用IBM MQ，IBM Message Broker和Java / J2EE Technologies。

我目前已投入使用Message Broker开发中间件的项目，该中间件在两个应用程序之间进行交互。我不太确定Message Broker是否适合这种类型的项目，因为Java可以以一种非常有效的方式完成相同的工作，这使我在搜索Internet时获得了使用这两者的优势。

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

-RDJ

Answer 1

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

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

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

Answer 2

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

Answer 3

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

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

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

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

Answer 4

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

Answer 5

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

Answer 6

首先要了解的是，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计算节点。