Distributing Tasks in a Clustered Application Using JMS Much more than asynchronous data transfer

Decoupling and delaying processing in a request-driven environment is one of the key strategies in creating a robust and scalable distributed application. Many services rely on clustering alone to ensure scalability, but they frequently run into trouble when newfound requirements keep application complexity growing.

Although server clustering is an essential technology that facilitates scalability, it can be rather inefficient when all processing is done synchronously. Throughput can be increased, but responsiveness is a tougher nut to crack.

In this article, I discuss asynchronous processing and illustrate how clever task management can increase the performance, availability, scalability, and manageability of your application. We will create a generic task distribution framework that can send any task to either one or every server in your cluster, in a highly configurable fashion. Our framework will implement the well-known Command pattern by using polymorphism and the Java Message Service (JMS).

What Does Decoupling Mean in Practice?
When a server receives a client request, it usually needs to perform several individual tasks before a response can be returned. Decoupling means that instead of performing all tasks at once, some are instead queued and processed asynchronously. Because queuing is normally a low-cost operation, the synchronous request will finish quicker.

And the Benefits?
Processing tasks sequentially and in parallel is generally more efficient than processing them randomly (whenever clients happen to make requests). The positive impact is greater than what is immediately apparent. In theory, decoupling can increase performance in the following areas:

• Robustness: Increases because requests will rely on fewer processes that can fail
• Responsiveness: Partial post processing of requests decreases the time between receiving a request and returning a response
• Scalability: All decoupled processes can grow in complexity without the threat of decreased responsiveness
• Availability: Failures can be handled without the client ever knowing that something went wrong

Automatic retries are easily configured for situations where subsystems are unavailable.

Naturally, the difference between theory and practice will vary from application to application. However, it is clear that almost every implementation will have at least some of the aforementioned benefits.

Sounds Great, But Are There Any Pitfalls?
As with most good things, there are some caveats. One of the most severe is that you might actually find yourself decreasing availability if you don't ensure that you have enough hardware to clear busy processing queues. Queues grow very rapidly if more asynchronous requests come in than your system is able to process. Care has to be taken in the design, and automated monitoring of queues is certainly advisable. Another obvious problem is that most processes in request-driven environments aren't very good candidates for decoupling. In fact, most of the processing might be required to return a response. Sometimes it will require some out-of-the-box thinking and maybe even a change in the way you serve your clients.

Which Processes Can We Decouple?
From a purely technical perspective, nearly all processes can be decoupled. For instance, you can decouple an ordering transaction by queuing a list of purchased items together with customer details - the asynchronous process will take care of the rest. The downside is that you can't include any processing details in the response. Thus, meticulous prevalidation of data is important to ensure that nothing will go wrong.

An increasingly popular implementation is to queue requests immediately and then keep polling the server to know when a response can be retrieved. Although this approach is actually synchronous in nature and won't improve request processing times, it has the psychological benefit that a progress bar can be displayed during polling.

In addition to decoupling integral business logic (which can be a formidable challenge), less central processes such as logging and sending e-mail are very good candidates to consider. There is no reason to have a client wait for such tasks to complete when performance is of the essence. E-mail in particular is a very good candidate for decoupling. Let's have a closer look.

Case Study: Asynchronous E-mail
Sending e-mail the traditional way (as part of a synchronous request) poses some problems. First of all, connecting to an e-mail server requires a network round-trip and it might be slow, especially if the server is very busy. An overloaded e-mail server can even make a service that relies on e-mail temporarily unavailable.

XA Transaction Support
Another easily overlooked issue is that e-mail servers are commonly nontransactional by nature. This can cause inconsistent notifications when transactions are rolled back - a message can't be cancelled after it has been queued. Fortunately, JMS supports transactions and can fix this problem by delaying the delivery of a message until its underlying transaction is committed.

Take into account that when accessing the database and transaction-aware JMS, you will need to use XA and two-phase commit (2PC) transactions. It is possible to emulate XA with non-XA resources, but you might end up with inconsistent data. Enabling XA is a configuration issue and usually requires no changes in code. See the WebLogic documentation for details.