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).

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.