orporations encounter various scenarios in which they need parallel processing to achieve high throughput and better response times. For example, various financial institutions perform reconciliation as batch jobs at the end of each day. In these cases, a company may need to process millions of units of work to reconcile its portfolio. These units of work typically are processed in parallel. This article demonstrates how to accomplish parallel processing within a J2EE container.
The J2EE design revolves around the request/response paradigm. For a login request, a user typically provides a user name and password to the server and waits for a response to get access to the site. A J2EE container can serve multiple users at the same time (in parallel) by managing a pool of threads, but for various reasons opening independent threads within a single J2EE container is not recommended. Some containers' security managers will not allow user programs to open threads. Moreover, if some containers allowed opening threads, then they would not manage those threads and therefore no container-managed services would be available for the threads. That would leave you to implement these services manually, which is tedious and liable to add complexity to your code.
Until recently, performing parallel processing directly within a managed environment (J2EE container) was not advisable. Thankfully, IBM and BEA came up with a joint specification that resolves this problem. This JSR is named "JSR-237: Work Manager for Application Servers". JSR-237 specifies the Work Manager API, which provides abstraction from the lower-level APIs that enable an application to access a container-managed thread. Work Manager API also provides a mechanism to join various concurrent work items, so an application can programmatically add the dependency of work completion as a condition for starting other tasks. This can be useful for implementing workflow types of application. These features were difficult to implement prior to Work Manager.
This article discusses this specification and its design, and presents some code snippets for implementing a concurrent application for a managed environment. First, it discusses the design of the Work Manager API and it's key interfaces.
Work Manager Design
The Work Manager API defines Work as a unit of work, which you want to execute asynchronously. Work is an abstraction of the lower-level java.lang.Runnable interface. Implementation of the Work interface requires you to define a
method and implement business logic for performing tasks/work in this method. The Work Manager API has six key interfaces for implementation:
shows a class diagram for these interfaces.
J2EE container providers such as BEA and IBM must implement the WorkManager interface, and server administrators can create WorkManager by defining it in their J2EE container configurations. Most leading J2EE containers provide user interface (UI) tools for defining WorkManager. WorkManager encapsulates a pool of threads. By invoking the
schedule(Work work) method of the WorkManager interface, a client can schedule work for asynchronous execution. Behind the scenes, the Work Manager implementation gets a container-managed thread for executing the Work object. So work is executed in parallel with the current thread. A previously mentioned, the Work interface implements a run method of the java.lang.Runnable interface, so a thread can execute an object of type Work.