© Copyright International Business Machines Corporation 2002. All rights reserved.

Introduction

Asynchronous messaging patterns are an important part of the J2EE applications programming model. These patterns provide for "loose coupling" between applications and are useful for process flows, parallel processing, time-independent processing, and event-driven processing. This paper describes the limitations of current Java™ messaging APIs, then introduces a new set of technologies called Extended Messaging (EM) that IBM is introducing in WebSphere#xae Enterprise V5. EM combines a number of development and run-time enhancements to make the delivery of messaging programs faster and more efficient in a WebSphere environment.

The Java Messaging Service (JMS) is a set of Java APIs that provides a framework for Java programs to make portable calls into asynchronous messaging systems. The JMS standard was developed by several vendors and is described in detail at the JMS home page .

However, JMS is a relatively low-level API and requires you to write code for object lookups, message formats, data mapping, transactions around messaging patterns, and caching of administration objects for better performance. The EJB 2.0 specification introduces Message Driven Beans (MDB), which provide container support for event-driven message retrieval. But they still do not handle a number of messaging patterns, such as:

1. Sending messages with or without a response
2. Application-callable receiver beans -- messages need to be retrieved during application flow as opposed to using an MDB, with which messages are processed as soon as they arrive at a destination.
3. Late responses in send and receive.
4. Mapping and reformatting data in JMS messages -- lets the programmer set the details of the JMSMessage as parameters of a message, instead of having to build and parse the message data
5. Sending messages to multiple destinations

This paper assumes you have a working knowledge of both messaging patterns and EJB 2.0 terminology.

Back to top

Other attempts to encapsulate the JMS API

In 2001, Ryan Cox and I published JMSCommand Part 1 and JMSCommand Part 2 , which introduced an abstraction to the JMS API to simplify JMS programming called the JMSCommand bean. It is a simplified model and provides JNDI settings via a property file, caching of thread-safe JMS objects, and a simple command pattern for sending and receiving JMS messages.

Although the JMSCommand bean enabled Java developers to quickly build JMS applications, it did not run within a J2EE container, and thus was limited in scope and functionality. Additionally, there were no tools provided. Other attempts to simplify the JMS programming model include an open source JMS abstraction from the Apache Software Foundation called Messenger . But neither JMSCommand nor Messenger deliver both an excellent run time and the advanced tools to generate the plumbing necessary to handle common messaging patterns.

Back to top

Extended Messaging features

The next generation of messaging tools and run-time support is here -- it's called Extended Messaging (EM) and is delivered with WebSphere V5. EM tools are included in WebSphere Studio Application Developer Integration Edition V5 (hereafter called Application Developer IE), while run-time and configuration support are part of WebSphere Application Server Enterprise Edition V5. Messaging patterns supported by EM include:

1. Send -- fire and forget
2. Send with a sync response (optional timeout)
3. Optionally deal with late responses
4. Receive a request and send no reply
5. Receive a request and send a synchronous reply
6. Receive a request and send an asynchronous reply

In addition, EM provides:

1. Simplified programming model
2. Data mapping of message parts
3. MDB style as well as application-callable receiving of messages
4. Container support for threading and clustering
5. sending messages to multiple destinations
6. Advanced tools

For details on how to build and configure Extended Messaging beans, see below.

Back to top

Code simplification

As discussed above, one of the problems with JMS coding is the amount of code and J2EE constructs you have to write just to send a message. A traditional JMS application will look like this:

// Initialize the JNDI context InitialContext ctx =
new InitialContext();

// Look up the QueueConnectionFactory in JNDI Object o
= ctx.lookup("jms/myQCF"); qcf =
(QueueConnectionFactory)PortableRemoteObject.narrow(o,QueueConnectionFactory.class);

// Create a QueueConnection QueueConnection conn =
qcf.createQueueConnection();

//Create a QueueSession QueueSession session =
conn.createQueueSession(false,Session.AUTO_ACKNOWLEDGE);

// Look up the Queue in JNDI Object o =
ctx.lookup("jms/myQ"); q = (Queue)
PortableRemoteObject.narrow(o,Queue.class);

// Create a QueueSender QueueSender sender =
session.createSender(q);

// Create a message Message message =
session.createTextMessage();
message.setJMSType("LogMessage");
message.setText("Hello World");

// Send the message sender.send(message);
			

Wow, that's a lot of code just to send a message! And as mentioned earlier, there is no container support for caching of connection factories, queues, senders, and so on -- all that has to be done by hand as well. EM enables you to do all this and more using wizards provided with Application Developer IE.

Back to top

Tools support

EM combines tools with run-time support. Let's look at using Application Developer IE to create a simple scenario -- a "sender and receiver" bean. The sender bean sends a string to a queue and then waits for a reply on a reply queue. Then an MDB reads that message from the request queue, calls a session bean that adds a timestamp to the message text, and sends the message back to the sender bean via the reply queue. This scenario is detailed in Figure 1:

Here are the steps used to create this scenario in Application Developer IE:

1. Using wizards, build a stateless session bean called DoSomething.
2. Add a method called addDateToInput(String) and promote this method to the local interface.
3. Use the EM wizards in Application Developer IE to create the sender and receiver beans.

To start the EMS wizards, select an EJB project and right-click:

When the wizards have finished and deployed code is generated, you will see the following beans created:

Remember, MySender is a stateless session bean that sends the message to the request queue. MyReceiver is a MDB that listens on the request queue, pulls the message off, makes a call to the addDateToInput() method of the DoSomething bean, and then posts the updated message on the reply queue. Finally, MySender retrieves the message from the reply queue, making a complete round trip. MyReceiver has neither a local nor a remote interface, because MDBs are callable only by the container, and do not have callable interfaces.

As stated above, all of the code for this messaging example is generated by the wizards in Application Developer IE. For the MySender session EJB, a method is added to send a supplied message, and then block for a timeout on the reply. The method is detailed in the listing below. The input parameter "message" is built during the creation of the sender bean using the wizards in Application Developer IE. You can include as many parts in the message as you want. Each part will get mapped to a parameter in the sendWithResponse() method. This example has one message part of type java.lang.String to handle the input message, which means you don't have to build a complex message for sending and then parse it in the corresponding MDB. The CMMFormatter does this automatically by adding parameters to the "formatter" object, and then calling getMessage() to return the combined message. EM then uses the CMMParser object to parse the response message.

/** * Generated - maps to a JMS message and sends
with response */ public java.lang.String
sendWithResponse(long timeout, java.lang.String
message) throws CMMException { // Create sender based
on the defined output port CMMSender sender =
CMMFactory.createSender("ems/MyOutputPort"); try { //
Create message factory MessageFactory factory =
sender.getMessageFactory(); // Create formatter
CMMFormatter formatter =
CMMFactory.createCMMFormatter(factory); // Add
parameters to the message
formatter.addStringParameter(message); // Get the
message Object request = formatter.getMessage(); // Set
message type
sender.setRequestMessageType("MyMessageFormat"); //
Send request receive response Object response =
sender.sendRequestReceiveResponse(request, timeout); //
Create parser CMMParser parser =
CMMFactory.createCMMParser(response);

// Process exception if (parser.containsException()){
try{ throw parser.getException(); } catch(CMMException
exc){ throw exc;} catch(Exception exc){ throw new
CMMException("Unexpected Exception", exc);} }

// Extract response and return return
parser.getStringParameter(); } finally {
sender.close(); } }
			

After the message is sent by the sendWithResponse() method of the MySender bean, the message will be sent to the destination (queue) defined in the output port. The message will then be picked up by the MDB (MyReceiverBean), parsed, updated by a call to the addDateToInput() method of the DoSomething bean, and then put back on the reply destination. Again, this code (shown below) is generated by the Application Developer IE wizards:

public void onMessage(javax.jms.Message msg) { try
{ //Select based on the message type If
("MyMessageFormat".equals(msg.getJMSType())){ try { //
Create reply sender CMMReplySender replySender =
CMMFactory.createReplySender(msg); MessageFactory
factory = replySender.getMessageFactory(); // Create
formatter CMMFormatter formatter =
CMMFactory.createCMMFormatter(factory); try { // Create
parser to extract parameters from the message CMMParser
parser = CMMFactory.createCMMParser(msg); // Extract
parameters java.lang.String param0 =
parser.getStringParameter(); // Create EJB
javax.naming.Context initialContext = new
javax.naming.InitialContext();

DoSomethingLocalHome home =
(DoSomethingLocalHome)initialContext.lookup("java:comp/env/ejb/DoSomething");

DoSomethingLocal obj = home.create();
// Invoke target method String reply =
obj.addDateToInput(param0);

// Set reply formatter.addStringParameter(reply); }
catch(Exception exc) { // Set exception
formatter.setException(exc); } Object reply =
formatter.getMessage(); // Send reply
replySender.sendReply(reply); return; } catch(Exception
exc) { // Handle exception
CMMFactory.handleException(msg, exc); return; } } }
catch (JMSException exc){ // Failed to get message type
}

CMMFactory.handleMessage(msg); }
			

During the creation of the MDB using the wizards, you can have the MDB call a method on a session bean. This option is what creates the code to call the addDateToInput(param0) method shown in the listing above. This lets you partition the business logic of the process from the message flow while still using the wizards to create the receiver bean, as shown in Figure 4:

After you build the sender and receiver beans using Application Developer IE, you can deploy and run them either in the Application Developer IE WebSphere Enterprise Test Environment, or in WebSphere Application Server Enterprise Edition.

Back to top

Run-time configuration

After completing the send and receive messaging pattern using Application Developer IE, you need to configure the corresponding messaging components using the WebSphere V5 administration console. These components include:

1. QueueConnectionFactory
2. Request and Reply queues
3. EMS input and output ports
4. MessageListnerPort

The use of input and output ports as an abstraction for the destination and connection factory provide for added deployment-time configuration. A port can abstract more then one destination, thus letting a sender automatically send messages to multiple destinations. For details on setting up the run-time configuration, see the Application Developer IE online help.

Back to top

Conclusion

JMS and MDBs provide a platform-independent implementation to add messaging to your J2EE applications, but they fail to address many aspects of asynchronous messaging patterns. The EM support Application Developer IE provides both tools and run-time extensions to the J2EE 1.3 infrastructure provided by WebSphere Application Server V5, thus enabling you to build robust asynchronous applications with little or no coding. EM also promotes the separation of business logic from messaging plumbing by having the receiver or MDBs call methods on session beans for message processing.

Back to top

Related information

For a comprehensive, two-part tutorial about WebSphere V5 Extended Messaging support, see WebSphere Application Server Enterprise Version 5 -- Extended Messaging Tutorial . It shows you how to use the Extended Messaging tools in WebSphere Studio Application Developer Integration Edition Version 5 to create a sample application that uses sender and receiver beans, which are session EJBs containing methods that send or receive JMS messages.

Top of page

About the author

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction
• Other attempts to encapsulate the JMS API
• Extended Messaging features
• Code simplification
• Tools support
• Run-time configuration
• Conclusion
• Related information
• About the author
• Comments

Next steps from IBM

Rational Application Developer features provide the comprehensive Integrated Development Environment (IDE) used to develop J2EE applications requiring Servlets and JavaServer Pages (JSPs).

---

• Try: Try the free Rational Application Developer, which helps developers quickly design, develop, test, analyze, and deploy high-quality Java, Javaserver pages, and J2EE applications.
• Article: Learn how you can deliver accurate, higher-quality J2EE apps with Rational Application Developer, open source JUnit and JUnitEE test frameworks.
• Tutorial: Build a Facebook application using PHP, the Spring framework, and J2EE.
• Buy: Rational Application Developer

My developerWorks community

Dig deeper into WebSphere on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers