Introduction

The Java Message Service (JMS) is a portable, standard messaging API that enables Java programs to communicate by exchanging messages. JMS is a component of the Java Platform, Enterprise Edition (Java EE) specification.

Why would you want to use JMS? Web services applications typically use HTTP as the transport for transmitting SOAP request and response messages. However, if you are interested in a more reliable transport, or would like to use a more asynchronous messaging paradigm, an enterprise messaging system that implements the JMS API might be preferable.

The use of JMS in conjunction with Web services applications was introduced in IBM WebSphere Application Server V5.0.2, back in 2003. Since there was no standard for SOAP over JMS interoperability at that time, the Web services runtime within the application server employed an IBM proprietary protocol for exchanging SOAP request and response messages within an enterprise messaging system. More recently, an effort was initiated to establish an interoperability standard for SOAP over JMS. The SOAP-JMS W3C Working Group was formed in 2008 to produce an approved specification for SOAP-JMS interoperability. Achievement of a W3C recommendation is tentatively targetted for April 2009.

Support for the emerging SOAP over JMS binding specification has been added to WebSphere Application Server V7. (Because this specification has not yet been approved, we will continue to track the progress of the standardization effort.) Prior to Version 7.0, the SOAP over JMS support in WebSphere Application Server was restricted to JAX-RPC Web services and clients. In Version 7.0, however, the SOAP over JMS capabilities have been expanded to include JAX-WS Web services and clients.

How does SOAP over JMS work?

Figure 1 shows the relationship between the Web service run time components and the underlying messaging provider.

At a high level, these are the steps involved with processing a Web services request that uses SOAP over JMS:

1. The JAX-WS client application uses the JAX-WS programming model to invoke a Web service operation.
2. The message sender component of the WebSphere Application Server Web services client runtime processes the request by sending a SOAP request message to the request queue identified by the endpoint location URI associated with the invocation (for example, jms:jndi:jms/MyQueue&jndiConnectionFactoryName=jms/MyCF&targetService=Port1). The message sender component uses the standard JMS API layer provided by the underlying messaging provider (for example, IBM WebSphere MQ) to send the request message.
3. The SOAP request message is delivered to the request queue by the messaging provider.
4. The message receiving component of the Web services server runtime uses the JMS API to receive the SOAP request message.
5. The Web services server runtime uses the EJB container (a component of the WebSphere Application Server environment) to dispatch the request to the Web service implementation class, named "MyServiceImpl" in Figure 1.
6. After the Web service operation finishes, the Web services server runtime uses the JMS API to send the SOAP response message to the reply queue.
7. The Web services client runtime then uses the JMS API to receive the reply message. The client then processes the reply to finish the invocation, and returns control back to the client application.

Back to top

Before you begin

In this tutorial, you will implement an EJB-based JAX-WS Web service that is similar to the JAX-WS Web services sample application delivered with WebSphere Application Server V7. You will implement your Web service using a top-down approach, starting with a WSDL document that is similar to the one supplied with the sample application.

Objectives

By following the exercises in this tutorial, you will learn how to use IBM Rational Application Developer to develop a JAX-WS Web services application that uses SOAP over JMS, how to configure the various JMS-related objects (queue, connection factory, and so on), and how to test the application using the test client generated by Rational Application Developer.

Prerequisites

This tutorial is for application developers and system administrators who have experience with WebSphere Application Server, Web services, and the JAX-WS programming model. You should have some familiarity with a messaging provider, along with its administrative functions. The examples throughout this tutorial will use the default messaging provider included in WebSphere Application Server.

System requirements

To run the examples in this tutorial, you will need IBM WebSphere Application Server V7.0 and IBM Rational Application Developer V7.5 installed and operational.

Duration

1.5 hours (time approximate)

1 of 14 | Next

Comments

Back to top

Table of contents

• Introduction
• Building the web service application
• Import initial contents of Rational Application Developer project
• Create JMS resources
• Create the enterprise bean Web service
• Test the Web service
• Advanced techniques for using SOAP over JMS
• Permanent reply queue
• Asynchronous JAX-WS Web service invocations with SOAP over JMS
• Diagnostic trace of SOAP/JMS components
• Summary
• Download
• Resources
• About the authors

---

1 of 14 | Next

Next steps from IBM

• Try: Rational Application Developer for WebSphere Software
• Buy: Rational Application Developer for WebSphere Software

Dig deeper into WebSphere on developerWorks

Try IBM PureSystems. No charge.

Experience today!

---

Get started with the cloud-based trial and pattern development kit.