Weblogic Authors: Yeshim Deniz, Elizabeth White, Michael Meiner, Michael Bushong, Avi Rosenthal

Related Topics: Weblogic

Weblogic: Article

Distributing Tasks in a Clustered Application Using JMS

Much more than asynchronous data transfer

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.

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.


  • 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
  • More Stories By John-Axel Stråhlman

    John-Axel Stråhlman is the founder and CEO of Sanda Interactive Ltd (www.stc-interactive.com), a software consulting company based in Espoo, Finland. He is a distributed systems specialist and has been working as a consultant for his clients' projects for more than five years.

    Comments (8) View Comments

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.

    Most Recent Comments
    John-Axel Strahlman 09/10/05 01:59:30 PM EDT

    The source code for this article has been updated. You can access it by clicking on the source code link below the article.


    mark sisson 08/30/05 12:43:57 PM EDT

    I'm trying to find a download of sample code for this article but only found a SMALL link at the bottom of the article that is a link to a little snipet of code.

    Is there a full blown example that accompanies this article? It is exactly what I've been looking for !!!

    Thanks in advance.

    Charles Steinberg 05/24/05 03:26:05 PM EDT

    A question related to the configuration database for WLI 8.1: I am looking for documentation on the sizing of the WLI Database, vs. the Application database. Do you have any information to help establish a baseline?

    John-Axel Strahlman 03/28/05 01:52:08 PM EST


    You need to configure JMS queues and write an MDB that does the asynchronous processing. The framework will only work on an application running on WebLogic Server 6.1 or newer. Drop me an email if you need more specific instructions.

    The link to the performance guide is missing a slash between products and wlserver, sorry about that.


    meir 03/24/05 04:02:49 PM EST

    1.try to press on:

    and no response !!!

    2.what kind of weblogic software needed to install?

    3.how do i use this code:

    Listing 3: Framework sample usage

    DistributedLogger logger =
    new DistributedLogger();

    String text =
    "Hello asynchronous execution!"

    logger, //Command instance
    1000, //delay
    true, //runEverywhere
    false, //persisted
    false, //enableXA
    4); //delay.

    i mean from a "main" program that includes "weblogic" classes?

    Patricia Thomas 03/14/05 04:38:23 PM EST

    We're also using JMS for several asynchronous tasks, but never thought of using a generic command processor like this. Until now, we have used dedicated queues and MDBs for each task, but this is clearly a better and more manageable solution! Thanks!

    John-Axel Strahlman 03/01/05 03:33:24 AM EST

    Yes, all your CommandMessage classes need to be in the classpath of the server (or servers) that does the execution.

    Steve Rogers 02/28/05 02:50:21 PM EST

    I assume each new type of CommandMessage, like the DistributedLogger, have to be in the Classpath of the Server. Otherwise, can the serialized objects method be executed?

    IoT & Smart Cities Stories
    SYS-CON Events announced today that Silicon India has been named “Media Sponsor” of SYS-CON's 21st International Cloud Expo, which will take place on Oct 31 – Nov 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA. Published in Silicon Valley, Silicon India magazine is the premiere platform for CIOs to discuss their innovative enterprise solutions and allows IT vendors to learn about new solutions that can help grow their business.
    SYS-CON Events announced today that CrowdReviews.com has been named “Media Sponsor” of SYS-CON's 22nd International Cloud Expo, which will take place on June 5–7, 2018, at the Javits Center in New York City, NY. CrowdReviews.com is a transparent online platform for determining which products and services are the best based on the opinion of the crowd. The crowd consists of Internet users that have experienced products and services first-hand and have an interest in letting other potential buye...
    In his general session at 19th Cloud Expo, Manish Dixit, VP of Product and Engineering at Dice, discussed how Dice leverages data insights and tools to help both tech professionals and recruiters better understand how skills relate to each other and which skills are in high demand using interactive visualizations and salary indicator tools to maximize earning potential. Manish Dixit is VP of Product and Engineering at Dice. As the leader of the Product, Engineering and Data Sciences team at D...
    We are seeing a major migration of enterprises applications to the cloud. As cloud and business use of real time applications accelerate, legacy networks are no longer able to architecturally support cloud adoption and deliver the performance and security required by highly distributed enterprises. These outdated solutions have become more costly and complicated to implement, install, manage, and maintain.SD-WAN offers unlimited capabilities for accessing the benefits of the cloud and Internet. ...
    "IBM is really all in on blockchain. We take a look at sort of the history of blockchain ledger technologies. It started out with bitcoin, Ethereum, and IBM evaluated these particular blockchain technologies and found they were anonymous and permissionless and that many companies were looking for permissioned blockchain," stated René Bostic, Technical VP of the IBM Cloud Unit in North America, in this SYS-CON.tv interview at 21st Cloud Expo, held Oct 31 – Nov 2, 2017, at the Santa Clara Conventi...
    René Bostic is the Technical VP of the IBM Cloud Unit in North America. Enjoying her career with IBM during the modern millennial technological era, she is an expert in cloud computing, DevOps and emerging cloud technologies such as Blockchain. Her strengths and core competencies include a proven record of accomplishments in consensus building at all levels to assess, plan, and implement enterprise and cloud computing solutions. René is a member of the Society of Women Engineers (SWE) and a m...
    DXWordEXPO New York 2018, colocated with CloudEXPO New York 2018 will be held November 11-13, 2018, in New York City and will bring together Cloud Computing, FinTech and Blockchain, Digital Transformation, Big Data, Internet of Things, DevOps, AI, Machine Learning and WebRTC to one location.
    In an era of historic innovation fueled by unprecedented access to data and technology, the low cost and risk of entering new markets has leveled the playing field for business. Today, any ambitious innovator can easily introduce a new application or product that can reinvent business models and transform the client experience. In their Day 2 Keynote at 19th Cloud Expo, Mercer Rowe, IBM Vice President of Strategic Alliances, and Raejeanne Skillern, Intel Vice President of Data Center Group and G...
    DXWorldEXPO LLC announced today that All in Mobile, a mobile app development company from Poland, will exhibit at the 22nd International CloudEXPO | DXWorldEXPO. All In Mobile is a mobile app development company from Poland. Since 2014, they maintain passion for developing mobile applications for enterprises and startups worldwide.
    Founded in 2000, Chetu Inc. is a global provider of customized software development solutions and IT staff augmentation services for software technology providers. By providing clients with unparalleled niche technology expertise and industry experience, Chetu has become the premiere long-term, back-end software development partner for start-ups, SMBs, and Fortune 500 companies. Chetu is headquartered in Plantation, Florida, with thirteen offices throughout the U.S. and abroad.