Messaging

Sending E-mail Through JMS
To use JMS for sending e-mail, we need to have JMS components configured (e.g., JMS server, JMS queue, and connection factory). We also need to write a Message Driven Bean (MDB) to perform the actual sending of our letters. When we want to send an e-mail from within our code, we create a JMS message that contains the properties and content of our letter. After that, we send it to our processing queue.

That's a lot of work! Fortunately, BEA WebLogic JMS provides us with all we need to create a framework for decoupling almost any process.

A Framework for Asynchronous Execution
It's time to roll up our sleeves and look at some code. We will create a framework that will enable the execution of any piece of code asynchronously on either one server or all servers in a cluster. The implementation does require some effort, but, once the framework is in place, asynchronous execution is as easy as pie.

The idea is to write classes that contain one public method with runnable code and another for initializing parameters - possibly a constructor. Encapsulated within JMS object messages, instances of these prewritten classes (command messages) will be sent to JMS queues configured on your servers. At that point, consumers will pick them up and execute them asynchronously (see Figure 1).

Let's look at all the pieces of this framework one by one:

1. JMS queues: A JMS queue for receiving command messages should be configured on every server. Error queues should also be configured for storing repeatedly failing messages.
2. JMS connection factories: To allow runtime selection of transactional behavior, two connection factories should be configured: one with XA enabled and another without.
3. Command object interface (CommandMessage): This is a simple Java interface that all command objects need to implement. It extends the java.io.Serializable interface, which is required for our commands to be embeddable in JMS object messages. Now, because we want to run our commands without actually knowing their exact types, we also implement the java.lang.Runnable interface and later simply convert them to Runnable objects and execute their run methods. We run the code without knowing exactly what we are running. It's polymorphism at its best!
4. Command executor (CommandExecutionManager): We will use an MDB for command processing. Instance pooling circumvents recurring JMS initialization, which makes MDBs very powerful message listeners and perfectly suited for this task. Writing the bean class doesn't require much effort; we only need to write a couple of lines in the onMessage method (see Listing 1).

This casts the received message to an ObjectMessage, retrieves the embedded command object, and executes its run method. You can configure a retry count by setting the redelivery limit of your queues to a value greater than zero in your config.xml file. Redelivery is triggered by throwing a runtime exception from your command object. Moreover, by configuring a redelivery delay, you can control the retry frequency as well.

A Helper Class for Sending Messages (TaskDistributor)
Technically, this part is not completely necessary; it is possible to do the JMS queuing manually every time. However, that would be tedious at best, and the helper is actually what makes this framework so practical. The helper is a regular Java class with static methods for queuing command messages. You can write separate methods for handling different scenarios, but for conciseness, I chose to write a single method that can handle most situations:

static void execute(CommandMessage cm, long delay, boolean runEverywhere, boolean persisted, boolean
enableXA, int priority)

This static method has several parameters for precise execution control. Let's go through these individually:

• CommandMessage cm: A command message instance.
• long delay: Represents the time at which to deliver the property, which is set with the weblogic.jms.extensions.WLMessageProducer class. This way, a command could be executed during the night or at some other convenient time. Accepting a Date object instead could also make sense.
• boolean runEverywhere: Decides whether the message will be sent for execution to a single, randomly selected server or to all servers in the cluster.
• boolean persisted: Will choose the delivery mode of the message by using the setDeliveryMode method of the queue sender. Business-critical messages should always be persisted so they aren't lost in case of a server crash. However, persistence always entails a performance penalty, which should be taken into account.
• boolean enableXA: Will choose whether the method will use an XA-enabled JMS connection factory. When set to true, the queuing will take part in an underlying transaction (if one exists), and the message won't be queued before the transaction is committed.
• int priority: Decides the JMS priority of the message. The setJMSPriority method of the javax.jms.Message class will be called with the given value prior to sending. The valid range is 0-9. Assigning different priorities to command messages may seem like overkill for most applications, but I've included the option here for completeness.

The implementation of the TaskDistributor helper class should be tailored to your specific execution needs. An example would be too long to include in this article, but you can download it from the source code that appears with this article. Several additional parameters could be added to control the execution with even more precision, but, on the other hand, you might be content with fewer options.

Hello Asynchronous Execution!
Once the framework is in place, we can start to implement our command messages. Let's look at a simple example. First, we need to create a class that represents our command message (see Listing 2). To invoke the execution, we use our TaskDistributor class (see Listing 3).

When the execute method in the example is called, an ObjectMessage (with JMS priority set to 4) containing an instance of the DistributedLogger class will be delivered after a one-second delay to all servers in the cluster. Consequently, the logger will print a string to stdout on all servers. With the framework in place, asynchronous execution becomes remarkably accessible and hassle free. Node-to-node communication is easier than ever before.

Container-Managed Task Distribution
We could create an analogous service by using pooled threads and virtual in-memory queues to process asynchronous requests. However, it is strongly recommended to let the application server take care of all thread management.

Furthermore, because JMS provides us with a very elegant and flexible solution, there is no reason not to let our server handle the intricacies of the process. In fact, we could call this methodology Container-Managed Task Distribution.

What About Performance Issues?
BEA WebLogic can handle a heavy message load, and performance is usually not an issue. Nevertheless, when producing a very large number of commands for processing, the use of nonpersistent messages and pipelining is strongly recommended. In addition, message flow control can provide alleviation for situations in which temporary peaks in service utilization rates cause message processing to consume too many resources.

Parallel Processing
A tremendous benefit of using MDBs is that they do parallel processing of messages automatically. You can fine-tune the amount of expended processing resources by limiting the amount of pooled consumer beans.

WebLogic offers numerous valuable JMS extensions and configuration options-many of which can be used in different implementations of task distribution. Great care should be taken when choosing and optimizing JMS parameters for paging, redelivery, persistence, and throttling (flow control).

JMS is a very sophisticated service and careful study of its features is likely to pay off. For more information on improving performance, see the WebLogic JMS performance guide.

Summary
We have discussed decoupling and asynchronous messaging. As a rule of thumb, we can say that a server processing asynchronous requests is performing more efficiently than one exclusively processing synchronous requests. Although decoupling may not always be easy, or even feasible, it can be a very powerful mechanism when implemented thoughtfully. Not only do we get several performance-related benefits, we are also able to design our applications with more flexibility.

BEA WebLogic JMS is far more than simply a service for asynchronous data transfer. In addition to being remarkably configurable, it offers many useful features, such as automated redelivery, persistence of messages, schedulability, XA support, throttling, transient paging, and redirection of recurrently failing messages. By taking advantage of this enormous versatility, we can create a powerful and extensible framework to handle almost any situation in which asynchronous processing is needed.

References

Gamma, Erich; Helm, Richard; Johnson, Ralph; and Vlissides, John. (1994). Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley.

Hohpe, G. and Woolf, B. (2004). Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions. Addison-Wesley.

Yochem, Angela; Carlson, David; and Stephens, Tad. (2004). J2EE Applications and BEA WebLogic Server. Prentice-Hall.

BEA WebLogic JMS Performance Guide: http://dev2dev.bea.com/productswlserver/whitepapers/WL_JMS_Perform_GD.jsp

Programming WebLogic 8.1 JMS: http://e-docs.bea.com/wls/docs81/jms/index.html

Add Your Feedback

In order to post a comment you need to be registered and logged in.

Register | Log in

Please wait while we process your request...