Use JMS Clients to Utilize Free Computer Resources

Abstract

In an enterprise, many computers are often either being underutilized due to the nature of the work performed on them or not being used at all because it is after business hours. In many of these institutions, application servers are grinding away taxing CPUs, especially if they are performing CPU-intensive mathematical work, while other machines on the network sit idle. This article proposes a framework for placing Java Messaging Service (JMS) clients on these underutilized machines to offload the work normally performed on a server. The client can listen on a request queue for a unit of work to perform, and respond on a reply queue. In addition, the article presents a BEA WebLogic Integration 8.1 architecture example that reliably distributes units of work to JMS request queues using a workflow with associated Java controls as an alternative framework to distributing work to remote clients.

Introduction

This article proposes a J2EE framework for addressing the challenge of distributing work to underutilized computer resources. In particular, JMS clients can be placed on these underutilized machines to offload the work normally being performed on a server. The client can listen on a request queue for a unit of work to perform, and respond on a reply queue. A set of message-driven beans can pick up the response messages on the reply queue for further processing. Furthermore, you can use a servlet implementation to administratively start the whole sub-process for creating the units of work to be sent to JMS clients, and also use it to terminate the same sub-process.

I use an ordinary BEA WebLogic Server for one example to distribute discrete units of work to distributed JMS clients. In another more sophisticated example, a BEA WebLogic Integration (WLI) workflow performs similar distribution tasks in a manner that allows for greater elegance in terms of flexibility, reuse of Java controls, and scalability through monitoring of request queues.

Examples for Usage

In the industry, quite a few examples demonstrate how you can use a JMS framework to exploit underused computers for parallel processing.

• A banking application could take mortgage loan applications and perform several types of interest calculations at different rates, years, etc. to provide the loan officer with data on each applicant that may influence the type of loan that should be given. All the different calculations could be shipped per applicant to the available computers to perform the work with the results being sent back to the application server for storage.
• A billing system may read records from a database and then recalculate the figures in the records for accuracy. For each record, it may need to connect to the business user's home system for auxiliary data, which may take a few seconds. This approach would not only be slow if performed sequentially, when thousands of records are involved, but it may further tie down server threads waiting for responses from different sites. By offloading the work to JMS clients, the process will not only be done in parallel, but it will also conserve sever threads.
• A weather forecast system or linear optimization system may need to manipulate and perform matrix multiplication. As the size and number of matrices increase, more load is placed on the server CPU(s). If this is a regular occurrence, by offloading the matrix manipulation and multiplication to JMS clients on other machines, the server's CPU(s) can be conserved for other work.

Using a Regular WebLogic Server to Distribute Units of Work

With the last example in mind, I'll build a simple example that performs matrix multiplication to illustrate how you can use a JMS framework to offload computing to the computer resources of an enterprise. The JMS client will receive a unit of work instance, after which it will call its doWork() method. In this simple example, the doWork() method will multiply two 3x3 matrices and store the results in a results matrix.

The JMS client will then respond to a reply queue with a copy of the unit of work instance that had the work performed on it. A message-driven bean will accept the completed work. Figure 1 shows the various components I'll discuss:

Figure 1. Components in this plain WebLogic Server implementation

This approach makes regular use of the JMS system. In the following sections I'll look at some code, and consider several scaling issues.

The Unit of Work class

Each class placed on the JMS request queue will implement a UnitOfWork interface that has one method of particular interest, doWork():

public interface UnitOfWork extends java.io.Serializable {


  // This method executes itself on the client machine

                        
 public void doWork();

  // This method prints the current contents of performed work

  public void print();

  // This method stores the instance into a backing store

  public void store();

}

In our concise, albeit illustrative, example, I have a class called SimpleMatrix that implements the UnitOfWork interface:

public class SimpleMatrix implements UnitOfWork {


 private Integer m1[][];

 private Integer m2[][];

 private Integer result[][];

 private Integer rows = new Integer(3);

 private Integer cols = new Integer(3);

 // May initialize m1 and m2 by locating records from a database

 public SimpleMatrix() {

 }

 // This method actually multiplies m1 x m2 and stores in result

 public void doWork() {

 }

 // This method stores result into a backing store

 public void store() {

 }

 // This method prints the current contents of result

 public void print() {

 }

}

The implementation of the methods is rather self-evident and, for the sake of brevity, will not be described here. See the accompanying code example for a full implementation. The point here is that this SimpleMatrix instance is passed to a JMS client, which will simply call doWork() to utilize its CPU to perform the work. For this example I won't actually retrieve or store matrices into a database, but that is what would be expected in a real scenario.

Servlet work creator

A servlet can be used to create these UnitOfWork instances. Although a WebLogic Server startup class can perform the same functions, for administrative purposes it is easier to send messages to a servlet from a secure Web browser. (An alternative implementation would be to utilize a Web service.) If security is placed on the servlet, an authenticated user can pass it commands in the query string to start and stop delivering units of work to the JMS request queue. I'll show you a skeletal example of the servlet for its methods of interest:

public class WorkServlet extends HttpServlet {


 ...

 private QueueSender qsender;

 private ObjectMessage msg;

 private int numMessages = 5;

 ...

 

 // This places the unit of work on the request queue

 public synchronized boolean sendMessages(int numberOfMessages, 

                                                 PrintWriter o) {

   for(int i=0; i<numberOfMessages; i++) {

     SimpleMatrix simple = new SimpleMatrix();

     // Send message to the request queue

     try {

       msg.setObject(simple);

       msg.setJMSReplyTo(QueueResponder);

       qsender.send(msg);

       if (o != null)

         o.println("Sent a Message to queue.");

     } catch (Exception e) {

       System.out.println("WorkServlet:sendMessages:Cannot" +

          "send message, exception raised");

       e.printStackTrace();

       return false;

     }      

   }

   return true;

 }



 // This may place a few units of work onto the queue on startup

 public void init(ServletConfig config) throws ServletException {

 ...

 }



 // Responds to a Query String action with keywords

 // Action = SEND : place unit of work object onto queue

 // Action = CONNECT : connect to JMS server

 // Action = DISCONNECT : disconnect from JMS server



 public void doGet(HttpServletRequest request, 

                   HttpServletResponse response)

                           throws ServletException, IOException {

   doPost( request, response );

 }

 

 public void doPost(HttpServletRequest request, 

                    HttpServletResponse response) 

                            throws ServletException, IOException {

  ...

  if (request.getParameter("Action").equals("SEND")           

    sendMessages(numberMessages, response.getWriter());

 }



}

The JMS client class's job is simply to accept a message on the request queue, call the doWork() method on the object to perform the work on this machine, and send the results back to the reply queue, where a message-driven bean picks up the results for further processing and storage. You can check to see if this is the text message to allow a control message to be sent to the client by telling it to exit processing. Of course, in a real situation, the message may include the name of the client so that not all clients stop processing.

The beauty of using the UnitOfWork interface is that the JMS client, once written, will work for any future classes that implement the interface. This makes the JMS client generic enough to be used in many different scenarios without modification. All that is needed is that the compiled UnitOfWork interface and all its implementing classes be in the client's classpath.

In this simplistic model, the client waits for a message to start processing. In a real situation, the client's onMessage() method may wait depending on the time of day such as after 5 p.m. or if the CPU load on the machine is less than a threshold. This logic would need to be added to the client to make it more in tune with a machine's schedule for usage.