jms - 可能涉及使用 JMS 集成多个 IT 系统的业务场景？

Question

谁能给我一些关于我可以实现 Java 消息服务 (JMS) 的业务场景的建议。消息可以通过队列（点对点）或主题（定期/持久订阅）发送。

我将使用 JMS（通过 TIBCO Enterprise Messaging Services 启用）。

业务场景必须涉及至少 3 个 IT 系统/应用程序。

Answer 1

经典用例是将 JMS 作为可用传输之一的企业服务总线。在这种情况下，任何数量的 IT 系统都可以通过将消息放置在众所周知的队列中来请求服务调用。侦听该队列的服务提供者根据 JMS 消息的回复字段动态确定回复。典型服务的一个示例是查询或更新客户人口统计信息。出于查询的目的，这绝对满足您涉及至少 3 个 IT 系统的要求，因为与客户打交道的几乎所有事情都需要请求此服务。

另一个应用广泛的例子是日志记录。我有几个客户使用 JMS 消息从网络中捕获日志记录并将它们转发到中央服务器集线器。因为它是 JMS，所以中央集线器可以通过使用冗余服务器实现高可用性，并且可以水平扩展以吸收季节性负载。

对于 pub/sub，我真正喜欢的一个例子来自一家保险公司。他们发布有关在各种呼叫中心、内部新闻行情和业务合作伙伴中订阅的主题的事件。在几年前的飓风期间，这些事件包括登陆预测的更新，然后在风暴过去后，更新包括移动索赔理算员和其他支持服务的位置。Pub/Sub 是一种很好的方式来协调这种大规模的人员动员并与总部的地面支持进行沟通。

具有广泛适用性的更普通的发布/订阅用例是系统管理。仪表化的应用程序可以发布它们的状态并且相关方可以接收这些通知。如果生产中出现异常情况，管理员可以动态启用对诊断流的订阅。通常没有订阅者，不会产生诊断。但是，在运行系统没有任何中断的情况下，只需订阅即可按需生成来自应用程序的诊断消息。

实际上很难找到不应该使用 JMS 消息传递的示例。最常见的禁忌症是真正的同步消息传递和以严格顺序处理消息的要求。我知道的所有 JMS 提供商都在不同程度上考虑到这些要求，并且我知道许多具有这些要求的系统部署。然而，JMS 消息传递的理想用例是真正的异步或伪同步通信和原子消息（也就是说，消息彼此之间或特定代理实例之间没有依赖关系）。

Answer 2

Here are some of the scenarios where we (food retailer) use messaging:

-connection systems between remote locations, in our case POS and inventory management systems in stores, and central ERP and forecast systems: master data changes are sent as XML messages from the central ERP system to the store systems. the store systems send changes in inventory, orders and sales to the central systems. This is completely PTP based, as the master data is unique for each store.

-usage as a central messaging backbone, either directly for systems that are capable to do messaging, or via some adapter functionality for databases, files, SAP systems or HTTP. Here the messaging system builds the base for our ESB.