An enterprise application provider is likely to choose a messaging API over a tightly coupled API, such as remote procedure call (RPC), under the following circumstances.
The provider wants the components not to depend on information about other components’ interfaces, so that components can be easily replaced.
The provider wants the application to run whether or not all components are up and running simultaneously.
The application business model allows a component to send information to another and to continue to operate without receiving an immediate response.
For example, components of an enterprise application for an automobile manufacturer can use the JMS API in situations like these:
The inventory component can send a message to the factory component when the inventory level for a product goes below a certain level so that the factory can make more cars.
The factory component can send a message to the parts components so that the factory can assemble the parts it needs.
The parts components in turn can send messages to their own inventory and order components to update their inventories and to order new parts from suppliers.
Both the factory and the parts components can send messages to the accounting component to update their budget numbers.
The business can publish updated catalog items to its sales force.
Using messaging for these tasks allows the various components to interact with one another efficiently, without tying up network or other resources. Figure 31–1 illustrates how this simple example might work.
Manufacturing is only one example of how an enterprise can use the JMS API. Retail applications, financial services applications, health services applications, and many others can make use of messaging.