JMS clients responding to the workflow

The JMS client that responds to the workflow is almost the same as the one described in the earlier WebLogic Server section. The only difference is that the client now responds back to the response queue using a bytes message instead of an object message. The client converts the
SimpleMatrix object into a byte array to pass it on the response queue. The reason for this is that the Message Broker channel associated with the event generator that is tied to the response queue can only listen to a stream of data, which is either a String, an XML Bean, or a byte array. The associated code has been designed to respond to both a WebLogic Integration request message and an ordinary WebLogic Server request message.

The workflow to receive a completed unit of work is show in Figure 3:

Figure 3. Workflow for the receiver

The important activity here is the
perform node that converts a byte array into an
Object and calls the
print() and
store() methods.

The use of WebLogic Integration workflows

You've seen that the use of workflows, Java controls, and Message Broker channels provides a more sophisticated way to distribute work to underutilized computers. Simply by adding more activity nodes into the process flows, you can make the processing as comprehensive as desired. For example, the workflow could have an auditing control to audit all requests to an internal log file before placing them on a queue. The workflow could redirect requests to other JMS queues simply by changing the JMS control's property values. You can even have the remote Web service start multiple instances of the workflow for scalability. Finally, the Timer control can have a more granular interval based on a business calendar.

Another advantage of using Message Broker channels and event generators is that the event generators can be monitored by the WebLogic Integration Administration Console for the number of response messages for further control. The event generator and channels can be suspended and resumed via the console to respond to production events.

This flexibility makes using WebLogic Integration workflows a compelling methodology.

Download

You can download the source code used in this article: JMSClientApp.zip.

Conclusion

The benefit of utilizing remote JMS clients to offload work is that it effectively utilizes network machines for certain types of batch processing work, while placing less of a burden on the original servers. A well-known example of this approach is the Search for Extraterrestrial Intelligence (SETI@home) system, which utilizes the world's PCs for performing units of work. This article sought to generalize this approach using a framework of JMS clients and also offered a discussion on how to deploy such a solution for scalability. The article discussed multiple approaches of distributing work to remote clients and offered a service-oriented approach as the preferred methodology.