SOAP is transport-independent and can be bound to any protocol; SOAP over JMS is an alternative messaging mechanism to the standard SOAP over HTTP messaging. SOAP over JMS is proven to be more reliable and scalable than SOAP over HTTP. Its reliability and scalability reflect the reliability and scalability of WebSphere MQ, the messaging engine used as the JMS provider in our case. It is reliable because message delivery is guaranteed, and scalable because it can support high-volume connections.
SOAP over JMS also allows a Web service client to asynchronously invoke a service without waiting for the response. Although asynchronous invocation style can be implemented by both synchronous and asynchronous transport protocols, JMS makes the implementation of asynchronous invocation easier for both the service requestor and service provider.
This article shows how a Web service client can invoke a Web service by putting a JMS message into a WebSphere MQ queue (Input queue) and then receive the response as a JMS message from another queue (the Response queue). It illustrates how to configure a sample Web service deployed on IBM WebSphere Application Server V6.1 to use MQ queues as its input and response queues. For testing purposes, we will use RFH2Util (a widely used WebSphere MQ testing utility) as the Web service client. Figure 1 shows the topology of our scenario:
Figure 1. Topology used in the article
The Web service will need a number of JMS resources or managed objects to be defined in the application server. Let's look at what these are:
- JMS Listener Port: Used by the Web service to collect the SOAP/JMS request messages from the request queue. The listener port is used by WebSphere Application Server runtime to pull the request queue to collect SOAP/JMS messages and pass it to activate the Web service.
- JMS Request Queue Connection Factory: Used by the listener port to connect to the MQ queue manager that hosts the request MQ queue.
- JMS Request Queue: The JMS managed object that represents the request MQ queue. It is used by the Web service to collect SOAP/JMS messages from the request queue.
- JMS Reply Queue Connection Factory: Used by the Web service to connect to the MQ queue manager that hosts the reply MQ queue.
These prerequisites should be installed in order for this sample to work smoothly:
- WebSphere MQ should be already installed on the system, with a queue manager, a request queue, and a reply queue. (V6 is used in this article, but the same steps work fine with V5 and V7.)
- WebSphere Application Server should be installed and configured.
- Some development environment should be installed; this could be IBM Rational® Solution Architect or IBM WebSphere Integration Developer.
With all the prerequisites installed and configured, you are ready to begin configuration on WebSphere Application Server. We first configure the Queue Connection Factories for both the request and response queues.
- Start WebSphere Application Server.
- Run the Administrative console on WebSphere Application Server.
- In the next few steps, we will set up the Queue connection factories for the request queue and then create the reply queue connection factory.
- Click on Queue connection factories as shown in Figure 2.
Figure 2. Queue Connection Factories
- Choose the required scope and click New.
Figure 3. Queue Connection Factories
- Choose WebSphere MQ messaging provider.
Figure 4. Queue Connection Factory Message Provider
- Fill in the following, and then click Save.
- For the name, choose an appropriate name.
- For the JNDI name, type jms/ReqQCF.
- Insert the queue manager name, host, and port. (This information comes from the pre-installed WebSphere MQ.)
- For Transport, choose Client.
Figure 5. Queue Connection Factory Properties
Repeat the same steps for the reply Queue connection factory but with the Web services name being WebServicesReplyQCF and the JNDI name being jms/WebServicesReplyQCF.
In the next few steps, we will create the request queue, where messages will be placed in the order that the Web service is consumed.
- Click Queues.
- Choose the required scope and click New.
Figure 6. Create New Queue
- Fill in the following values:
- For the name, choose an appropriate name.
- For the JNDI name, type jms/ReqQ.
- Insert the queue manager name, host, and port.
- Fill in the base Queue name that is hosted on MQ.
- Click OK and then Save.
Figure 7. Queue Properties
- Now we need to create a listener in order to detect that a message is placed in the queue, which in turn will be consumed by the service.
- From the Application Server administrative console, select
Servers. Your application server will most likely be
server1. Under "Communications," expand "Messaging" and
select Message Listener Service.
Figure 8. Message Ports
- Click Listener Ports:
Figure 9. Listener Ports
- Click New.
- Fill in the following Values:
- For the name, type MQListener.
- For the connection factory, type jms/ReqQCF.
- For the queue, type jms/ReqQ.
- Click OK and then Save.
Figure 10. Listener Ports Properties
- Restart WebSphere Application Server, and you are now ready to deploy and run a SOAP/JMS Web service.
Importing and deploying the Web service
After the previous server configurations, the Web service is ready to be deployed and tested. Now we need to import, build the project interchange, and deploy it on the server.
- In Project Explorer, click File > Import:
Figure 11. Project Explorer
- Select Project Interchange and click Next:
Figure 12. Select Project Interchange
- Browse to the location of the downloaded Project Interchange file
called "DeveloperWorksService.zip" (see the
Downloads section of this article). Choose all
files and then click Finish.
Figure 13. Browse Project Interchange
- Clean and build the workspace by going to the Project menu and clicking Clean.
- Add the Project to the server:
Figure 14. Add Project to server
- Restart the application server, and now you are ready to test the Web service.
Basic testing will ensure that the Web service is configured and functioning correctly. There are several different methods of testing an asynchronous Web service. If you choose the method described below, you need a JMS client with the ability to insert messages on an MQ queue.
The method below uses a tool that is shipped with the Message broker called rfutil. This tool facilitates the insertion and retrieval of messages on MQ queues. It also gives you the option to alter message JMS header properties as required for the Web service to function.
If you download the RFHUtil sample file as described here, be aware that you need to alter the Queue Manager, Queue Name, and the JMS replyTo according to the MQ configurations on your local environment.
The steps below test whether the Web service is listening on the Destination queues, where the request message is inserted. It also tests whether the Web service uses the JMS Reply To header to send the response.
- Open RFHUtil.
- Click File > Open. Choose the file
SampleRFHUtil, which you can download below (see
Downloads).
Figure 15. Open Sample RFHUtil text file
- Change the following attributes to match to your local environment:
- Queue Manager Name
- Queue Name
- Under the MQMD tab, Reply to Queue Manager name and Reply Queue
- Under the jms tab, Reply To and Destination name
- Under the Main tab, click Write Q:
Figure 16. Write Input to Queue
- Change the Queue name to the response queue (which should be the same value as the Reply To in the JMS Header) and click Read Q.
- Switch to the Data tab and observe the response Data.
| Description | Name | Size | Download method |
|---|---|---|---|
| Sample JMS Web Service | DeveloperWorksService.zip | 9KB | HTTP |
| Sample RFHUtil input | SampleRFHUtil.zip | 1KB | HTTP |
Information about download methods
Learn
-
"
Web services with SOAP over JMS in IBM WebSphere
Process Server or IBM WebSphere Enterprise Service
Bus"
(developerWorks, May 2008) is a two-part article series on using SOAP over
Java Message Service (JMS) in IBM WebSphere Process Server and IBM
WebSphere Enterprise Service Bus.
- The
SOA and Web services zone
on IBM developerWorks hosts hundreds of informative articles and
introductory, intermediate, and advanced tutorials on how to develop Web
services applications.
- Play in the
IBM SOA Sandbox!
Increase your SOA skills through practical, hands-on experience with the
IBM SOA entry points.
- The
IBM SOA Web site
offers an overview of SOA and how IBM can help you get there.
- Check out a quick
Web services on demand demo.
- Browse the
technology bookstore
for books on technical topics.
Get products and technologies
- Download
IBM product evaluation versions
and get your hands on application development tools and middleware
products from DB2®, Lotus®, Rational®, Tivoli®,
and WebSphere®.
Discuss
- Participate in the discussion forum.
- Check out
developerWorks blogs
and get involved in the
developerWorks community.
Mohab El-Hilaly works as a Software Engineer at IBM Cairo Technology Development Center, Egypt, where he develops and designs custom solutions using Websphere Enterprise Service Bus technology for various customers. Prior to that he developed custom solutions using various Microsoft Technologies, mainly ASP.NET. He obtained a bachelors degree in Computer Science from the American University in Cairo. In his spare time he enjoys watching soccer and playing console games
Islam Hussein Azaz is an Advisory IT Architect and has worked for IBM since 2003. He is currently working as a BPM Consultant for IBM Software Services for WebSphere (ISSW). Islam is a Sun Certified Enterprise Architect (SCEA) for JavaEE5.
Alaa Youssef works as an IT Architect at IBM Cairo Technology Development Center, Egypt, where he helps IBM's customers in devising SOA solutions. From 1998 till mid 2005, he worked as a Research Staff Member at IBM T.J. Watson Research Center, New York. He received the PhD degree in computer science in 1998 from Old Dominion University, Virginia, USA. He received the BS and MS degrees in computer science from Alexandria University, Egypt, in 1991 and 1994, respectively. He has authored several papers, and patents.




