可能涉及使用 JMS 集成多个 IT 系统的业务场景？
谁能给我一些关于可以实现 Java 消息服务 (JMS) 的业务场景的建议。消息可以通过队列（点对点）或主题（常规/持久订阅）发送。
我将使用 JMS（通过 TIBCO Enterprise Messaging Services 启用）。
业务场景至少涉及3个IT系统/应用。
Can anyone give me some suggestions of a business scenarios where I can implement Java Messaging Services (JMS). The message can be sent either by queue(point-to-point) or topic (regular/durable subscription).
I will be using JMS (enabled through TIBCO Enterprise Messaging Services).
The business scenarios must involve atleast 3 IT systems/applications.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
经典用例是使用 JMS 作为可用传输之一的企业服务总线。在这种情况下，任意数量的 IT 系统都可以通过将消息放入众所周知的队列来请求服务调用。侦听该队列的服务提供者根据 JMS 消息的 Reply-To 字段动态确定回复。典型服务的一个例子是查询或更新客户人口统计信息。出于查询的目的，这绝对满足您涉及至少 3 个 IT 系统的要求，因为几乎所有与客户打交道的事情都需要请求此服务。
另一个具有广泛应用的例子是日志记录。我有几个客户使用 JMS 消息从网络中捕获日志记录并将其转发到中央服务器中心。因为它是 JMS，所以中央集线器可以通过使用冗余服务器来实现高可用性，并且可以水平扩展以吸收季节性负载。
对于 pub/sub，我非常喜欢的一个例子来自一家保险公司。他们发布有关在各个呼叫中心、内部新闻行情和业务合作伙伴订阅的主题的活动。在几年前的飓风期间，这些事件包括登陆预测的更新，然后在风暴过去后，更新包括移动理赔员和其他支持服务的位置。 Pub/Sub 是协调大规模人员动员并与总部地面支持进行沟通的好方法。
具有广泛适用性的更普通的发布/订阅用例是系统管理。仪表化应用程序可以发布其状态，感兴趣的各方可以接收这些通知。如果生产中出现异常情况，管理员可以动态启用对诊断流的订阅。通常，如果没有订户，则不会生成诊断信息。但是，在运行系统不会出现任何中断的情况下，只需订阅，即可按需生成来自应用程序的诊断消息。
实际上很难找到不应使用 JMS 消息传递的示例。最常见的禁忌是真正的同步消息传递和严格顺序处理消息的要求。我所知道的所有 JMS 提供商都在不同程度上考虑了这些要求，并且我知道许多系统部署都具有这些要求。然而，JMS 消息传递的理想用例是真正的异步或伪同步通信以及原子消息（也就是说，消息彼此之间或与特定代理实例没有依赖性）。
The classic use case is that of an Enterprise Service Bus with JMS as one of the available transports. In this case any number of IT systems can request a service invocation by placing a message on a well-known queue. The service provider listening on that queue dynamically determines the reply based on the JMS message's Reply-To fields. An example of a typical service is to inquire on or update customer demographic information. For purposes of inquiry, this definitely meets your requirement of involving at least 3 IT systems since pretty much everything dealing with customers would need to request this service.
Another example with broad application is logging. I have several customers using JMS messages to capture log records from across the network and forward them to a hub of central servers. Because it is JMS, the central hub can be highly available by using redundant servers and can scale horizontally to absorb seasonal loads.
For pub/sub an example I really liked is from an insurance company. They publish events on topics that are subscribed in various call centers, internal news tickers and to business partners. During a hurricane a few years back, these events included updates on landfall predictions and then after the storm passed the updates included locations of mobile claims adjusters and other support services. Pub/Sub was a great way to coordinate this massive mobilization of personnel and communicate back to ground support back at headquarters.
A more mundane pub/sub use case with broad applicability is systems management. Instrumented applications can publish their status and interested parties can receive those notifications. If something is acting weird in Production, the administrator can dynamically enable a subscription to a stream of diagnostics. Ordinarily with no subscribers, the diagnostics are not produced. However, without any interruption in the running system, simply by subscribing, diagnostic messages from the app are produced on demand.
It's actually harder to find examples where JMS messaging should not be used. The most common contraindications are truly synchronous messaging and a requirement to process messages in strict sequence. All JMS providers I'm aware of make allowances for these requirements to varying degrees and I'm aware of many deployments of systems with these requirements. However the ideal use cases for JMS messaging are truly asynchronous or pseudo-synchronous communication and messages that are atomic (that is to say messages have no dependencies on each other or to specific broker instances).
以下是我们（食品零售商）使用消息传递的一些场景： -
远程位置之间的连接系统，在我们的示例中，商店中的 POS 和库存管理系统以及中央 ERP 和预测系统：主数据更改作为 XML 消息从中央 ERP 系统到商店系统。商店系统将库存、订单和销售的变化发送到中央系统。这完全基于 PTP，因为每个商店的主数据都是唯一的。
-用作中央消息传递主干，直接用于能够进行消息传递的系统，或通过数据库、文件、SAP 系统或 HTTP 的某些适配器功能。这里消息系统为我们的 ESB 构建了基础。
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.