This is my first blog so I should say a little about myself before I get into things. My name is Maxim, or Max for short, and I’ve been working on the WebContainer since 2003 in various capacities. In Version 7 of WebSphere Application Server (WAS), I acted as the WebContainer architect and the Servlet Expert Group (EG) member representing IBM.
If you have been following the latest in Servlet technology, you would know that the expert group has finally decided to try to standardize asynchronous servlet support for Servlet 3.0. This came as somewhat of a surprise because I had already been working with my colleague Erinn Koonce on a related feature for WAS version 7 called the Asynchronous Request Dispatcher (ARD). Naturally, as options are discussed in the Servlet EG, I compare them to ARD and think about why you’d want to adopt one over the other.
ARD came about as a result of another feature we put in WAS Version 6.1 called the Remote Request Dispatcher (RRD). RRD was a requirement from WebSphere Portal to help them support Web Services for Remote Portlets (WSRP). The problem that WSRP tries to solve is that in some Portal environments one problem web module can bring down the entire application server and its applications. The natural response is to just add more resources to the deployment. However, this may be overkill for the web modules that are well behaved. Since many applications consist of multiple web modules that interact with one another through request dispatcher includes, each web module had to reside on the same server.
RRD provided the mechanism to separate up these applications into other servers or clusters without having to rewrite the interaction logic between web modules. However, there was a major drawback resulting from the cost of packaging and sending of the metadata across the network that each remote request dispatch required. To help alleviate this, Portal wanted a mechanism to execute these remote request dispatches asynchronously. Thus, ARD was born.
The Asynchronous Request Dispatcher does the following:
- Allows request dispatch includes to execute asynchronously and concurrently
- Maintains proper ordering of response output
- Propagates request and thread context
- Allows decoupling of the dispatching of the request with the position where the content should be inserted
- Allows for client side aggregation of results
In my next blog, I will discuss the differences between the two proposals.
