可能涉及使用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

以下是我们(食品零售商)使用消息传递的一些场景：

远程位置之间的-connection系统，在本例中是商店中的POS机和库存管理系统，以及中央-connection和预测系统:主数据更改作为XML消息从中央ERP系统发送到商店系统。商店系统将库存、订单和销售的变化发送到中央系统。这完全是基于PTP的，因为每个商店的主数据都是唯一的。

-usage作为中央消息传递骨干，或者直接用于能够进行消息传递的系统，或者通过一些用于数据库、文件、SAP系统或超文本传输协议的适配器功能。在这里，消息传递系统为我们的ESB构建基础。