Java Tutorial - Java Scipt :

Enterprise Issues Addressed by JMS

There are many situations that benefit from JMS. Proper application of a messaging solution can improve availability, load balancing, and scalability. We’ll examine some real-world examples where these factors are improved through the addition of JMS. JMS is great at pushing out cache invalidations. Enterprise applications often rely on data from other components in an enterprise system. These components are quite often very expensive to communicate with in terms of latency and resource consumption. Across-JVM invocation might incur serialization and network transfer costs. Performance can be greatly improved by relying on the age-old tradition of local caching to minimize expensive communications. However, the problem with caching is that the data being cached may become outdated. Agreat pattern for tackling this is to have the owner of the cached data use a JMS topic to push out cache invalidations to any components that may be caching its data locally. Cache invalidation is an example of using JMS to publish events. Now, let’s take a look at how JMS can be used to communicate data efficiently to increase scalability and response time. The Web is built around HTTP, which is a request/response protocol. In practical terms, this means the logic must finish running before a page can be displayed. You may have seen this problem yourself in some Web sites: you’ll click on a link to purchase an item, and the user interface becomes blocked until the order is processed. Messaging can be used to solve this problem. Often, a sale is composed of several logical steps:

1. Checking availability

2. Processing payment information

3. Generating a sales notification

4. Generating a confirmation

5. Adding the order to a sales data warehouse

In this case, Steps 3 through 5 are not necessary to complete the transaction and can require lengthy processing. You can use messaging to defer the processing until after the user interface is handled. This is a server-side analog to the classic multithreaded GUI. The proper use of messaging improves application responsiveness and, more importantly, the user experience. Atask such as transferring funds can depend on multiple remote databases or integration with legacy systems. It might be infeasible to wait until the status of the transaction is known. In such a case, messaging can be used to kick off the processing while the user is informed that the result is pending. That way the user can continue to interact with the system. If tasks within a single method call can be done in parallel, then messaging can improve scalability and responsiveness. Let’s say the requirements state that we need to update information in our database, as well as in the databases of our partners. By using messaging you can simultaneously push out the updates rather than doing them sequentially, as would be required with a session EJB. Taking the same scenario, you can use reduce coupling by taking advantage of pub/sub, which makes it easy for a new business-to-business (B2B) partner to listen in to updates from our application. It is also easy for a partner to drop

out and be removed as a listener. By abstracting the knowledge of consumers out of our logic code, our application gains flexibility and robustness. Moves, adds, and changes of B2B partners won’t break things and won’t require code changes. All the listener needs to know is the name of the topic. As you can see, JMS addresses a number of enterprise issues. Often a problem can be solved very elegantly if it is reframed in terms of messaging.