Develop a SOAP/JMS JAX-WS Web services application with WebSphere Application Server V7 and Rational Application Developer V7.5

IBM® WebSphere® Application Server V7 provides support for SOAP over Java™ Message Service (JMS) with JAX-WS Web service applications. SOAP over JMS can be used as an alternative to SOAP over HTTP for transmitting SOAP request and response messages. This tutorial shows you how to use IBM Rational® Application Developer V7.5 to develop and deploy a JAX-WS Web service application that uses SOAP over JMS.

Phil Adams (phil_adams@us.ibm.com), Senior Software Engineer, IBM

Phil Adams is a senior software engineer in the IBM Software Group. For the last 9 of his 23 years with IBM, he has been a part of the WebSphere development team. For the past 6 years he has focused on web services, starting with the JAX-RPC web services engine. Phil was responsible for the design and implementation of the SOAP/JMS support introduced in the WebSphere® Application Server 5.0.2 release, and has been involved in designing and implementing various enhancements to the SOAP/JMS support since then. Phil is now a member of the W3C SOAP/JMS Working Group, whose mission is to produce a SOAP/JMS interoperability specification



Zina Mostafia (zina@ca.ibm.com), Advisory Software Engineer, IBM

Zina Mostafia is an Advisory Software Engineer in the IBM Software Group. Zina has been part of the WebSphere Web Services Tools team in the Rational Application Developer (RAD) group for over 7 years. She is also an inventor of an IBM Web Services patent disclosure, and she has presented the Web Services Tools in Rational Application Developer in conferences such as the IBM WebSphere Technical Conference (WSTC) and CASCON. One of Zina's main interests is to enable simpler scenarios within RAD to create Web Services based on EJBs. She designed and created the scenarios for EJB-Based Web Services for both JAX-WS and JAX-RPC runtimes. These scenarios support SOAP/JMS and SOAP/HTTP bindings. She is also an active participant in the open source community. She has also been involved with Web services security and interoperability.



18 March 2009

Also available in Chinese

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.

Figure 1. Overview of Web service run time components
Figure 1. Overview of Web service run time components

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.

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)


Building the web service application

The major steps required to build your EJB-based JAX-WS Web services application are:

  1. Import initial contents of Rational Application Developer project
  2. Create JMS resources
  3. Create the enterprise bean Web service
  4. Test the Web service

The next sections describe the details involved in each of these major steps, followed by variations you can apply to your SOAP over JMS implementation to further leverage capabilities of SOAP/JMS and WebSphere Application Server V7.


Import initial contents of Rational Application Developer project

Before you begin to build the Web service application, you should first import the soapjms_tutorial_pif.zip download file (included with this tutorial) to create the intitial project in Rational Application Developer. This file contains two files:

  • Echo.wsdl: The WSDL document from which you will build your Enterprise JavaBean™ Web service. This file is the same as the Echo.wsdl file contained in the JAX-WS Web services sample application that ships with the application server, except that the endpoint location URL for EchoServicePort has been changed to "jms:REPLACE_WITH_ACTUAL_URL" to indicate that this port should be accessed via the JMS transport, rather than HTTP.
  • create_jms_resources.py: An administrative script that can be used to create the JMS-related resources required by the application.

To import the file:

  1. Download the soapjms_tutorial_pif.zip file to your local disk.
  2. In Rational Application Developer V7.5, select File => Import... In the Import dialog, select Project Interchange and click Next (Figure 2).
    Figure 2. Import dialog
    Figure 2. Import dialog
  3. In the Import Project Interchange Contents dialog, select the .zip file that you downloaded above. Select the SOAPJMS_Tutorial project name to import (Figure 3) then click Finish.
    Figure 3. Import Project Interchange Contents
    Figure 3. Import Project Interchange Contents
  4. After the project is imported, go to the Enterprise Explorer view, expand the SOAPJMS_Tutorial project and you should see something similar to Figure 4.
    Figure 4. Enterprise Explorer view after importing the SOAPJMS_Tutorial project
    Figure 4. Enterprise Explorer view after importing the SOAPJMS_Tutorial project

Create JMS resources

Before you build the enterprise bean for your Web service, you must decide which JMS resources you will need for your application. In general, an application that uses SOAP over JMS will need:

  • A service integration (SI) bus.
  • A queue for receiving request messages.
  • A connection factory to connect to the messaging engine.
  • An activation specification that associates your server-side message listener component with a specific request queue.

These are the resources that you will use with this application:

  • SI bus: SJT_Bus (JNDI name: jms/SJT_Bus)
  • Queue: SJT_Request_Q (JNDI name: jms/SJT_Request_Q)
  • Connection factory: SJT_CF (JNDI name: jms/SJT_CF)
  • Activation specification: SJT_ActivationSpec (JNDI name: eis/SJT_ActivationSpec)

To create the JMS resources, simply run the create_jms_resources.py administrative script. You can do this by running the wsadmin command from a shell command-line environment, but you can also run it directly from Rational Application Developer, so let's try that approach.

  1. The application server must be running before you can run the script from Rational Application Developer, so start the application server now if it isn't already running.
  2. Within the Enterprise Explorer view, right-click on the create_jms_resource.py file (Figure 4), select Run As, then Administrative Script (Figure 5).
    Figure 5. Run administrative script
    Figure 5. Run administrative script
  3. You will then see a dialog in which you can edit the launch configuration. Select WebSphere Application Server v7.0 for the Scripting runtime prompt, and then select the appropriate profile name, depending on your application server configuration. In Figure 6, for example, the profile was the default AppSrv01 profile.
    Figure 6. Edit launch configuration
    Figure 6. Edit launch configuration
  4. Click Run and the script will start executing. When the script finishes, you should see output similar to that shown in Figure 7.
    Figure 7. Script output in console view
    Figure 7. Script output in console view

At this point, the JMS resources listed above have been created. Next, you will create the enterprise bean that will serve as the implementation class for your Web service.


Create the enterprise bean Web service

Next, you will build the enterprise bean for your Web service:

  1. From the Enterprise Explorer view in Rational Application Developer, right-click on the Echo.wsdl file and then select Web Services => Generate Java Bean Skeleton.

  2. In the Web Services Wizard (Figure 8), select Top down EJB Web Service for the Web service type. Make sure that Server is set to WebSphere Application Server v7.0 and Web service runtime is set to IBM WebSphere JAX-WS. If you need to modify these settings, simply click on the links to change the value.
    Figure 8. Web Services Wizard
    Figure 8. Web Services Wizard
  3. Next, change the name of your EJB project. Click on the Service project link. You should see a dialog similar to Figure 9. Change the Service project value to SJT_Project then click OK to return to the main Web Services page.
    Figure 9. Specify Service Project Settings
    Figure 9. Specify Service Project Settings
  4. Next, you want Rational Application Developer to generate a test client for you. Move the Client slider bar all the way to the top to choose Test Client. Click on the Client project link and change the Client project value to SJT_Client (Figure 10). The value of Client project type should be set to Dynamic Web Project, since you will use a JSP to test the Web service that you're building.
    Figure 10. Specify Client Project Settings
    Figure 10. Specify Client Project Settings
  5. Click Next to go to the WebSphere JAX-WS Top Down EJB Web Service Configuration page. Notice that the WSDL bindings value is set to JMS. This is because the EchoServicePort port within your WSDL document has an endpoint location URL that starts with "jms:". This page should look similar to Figure 11. Click Next.
    Figure 11. WebSphere JAX-WS Top Down EJB Web Service Configuration
    Figure 11. WebSphere JAX-WS Top Down EJB Web Service Configuration
  6. On the JMS Binding Configuration dialog (Figure 12), enter the names of the various JMS resources that you created above. Set the Destination JNDI name to jms/SJT_Request_Q, and the JMS connection factory to jms/SJT_CF (Figure 12). Click Next.
    Figure 12. WebSphere JAX-WS JMS Binding Configuration
    Figure 12. WebSphere JAX-WS JMS Binding Configuration
  7. On the WebSphere JAX-WS Router Project Configuration dialog, set the value for ActivationSpec JNDI name to eis/SJT_ActivationSpec (the name of the activation specification created above). The dialog should look like Figure 13. Click Next.
    Figure 13. WebSphere JAX-WS Router Project Configuration
    Figure 13. WebSphere JAX-WS Router Project Configuration
  8. The Test Web Service dialog (Figure 14) enables you to test the Web service using the Web Service Explorer, but since you have chosen to use SOAP over JMS, and since the Web Service Explorer uses only SOAP over HTTP, you cannot use it to test your application. Click Next.
    Figure 14. Test Web Service
    Figure 14. Test Web Service
  9. You can accept all the defaults on the Websphere JAX-WS Web Service Client Configuration dialog (Figure 15). Click Next to go to the next panel. You'll notice that Rational Application Developer generates your test client and publishes it to the application server.
    Figure 15. WebSphere JAX-WS Web Service Client Configuration
    Figure 15. WebSphere JAX-WS Web Service Client Configuration
  10. Next, you'll see the Web Service Client Test dialog. For the Test facility value, choose JAX-WS JSPs. You can accept the defaults for the remaining prompts. Click Finish to end the Web Services wizard. You'll notice that the client application is being updated in the application server to add the Web Service Client test JSPs.

  11. After the wizard finishes, you'll notice that Rational Application Developer has opened up an edit window that enables you to edit the Web service implementation class that was generated earlier. The file name should be "EchoSOAPImpl.java." Click on the tab titled EchoSOAPImpl.java to start editing the file. You'll see that the generated echoOperation method simply returns null, so you'll need to add some business logic to complete the method. Cut and paste the code below into the method:
    public EchoStringResponse echoOperation(EchoStringInput parameter) {
        // Print a debug message to show that we entered the class.
        System.out.println(">> JAX-WS EchoService: Request received.");
    
        // Create the response object that we will return.
        EchoStringResponse response = new ObjectFactory()
                .createEchoStringResponse();
    
        // Set up our default response in case there was no input.
        String inputString = "FAILED!";
    
        // If we properly received an input, then retrieve the string.
        if (parameter != null) {
            try {
                inputString = parameter.getEchoInput();
                System.out.println(">> JAX-WS EchoService input string: '"
                        + inputString + "'");
            } catch (Exception e) {
                e.printStackTrace();
            }
        }
    
        // Set our response string in the response object
        response.setEchoResponse("JAX-WS Echo Service says: " + inputString);
    
        // Return the response object.
        return response;
        }
  12. When you're done, save the file. This will cause the application to be re-published to the application server.

Test the Web service

To test the Web service application you built in the previous section:

  1. When you finish the Web Services wizard, you'll also notice that Rational Application Developer has created a new window that contains the Web Services Test Client JSP. Click on the tab titled Web Services Test Client, and you should see a panel similar to Figure 16.
    Figure 16. Web Services Test Client JSP
    Figure 16. Web Services Test Client JSP
  2. Click on echoOperation in the Methods pane, then enter a value for the echoInput prompt in the echoOperation pane on the right (Figure 17).
    Figure 17. Web Services Test Client JSP
    Figure 17. Web Services Test Client JSP
  3. Click on the Invoke button and you should see the response in the Result window pane (Figure 18).
    Figure 18. Web Services Test Client JSP with result
    Figure 18. Web Services Test Client JSP with result

Congratulations! You have successfully deployed and tested your application with SOAP/JMS using the basic features supported by WebSphere Application Server V7. In the next sections, you can explore some more advanced techiques for developing, running, and debugging your applications with SOAP/JMS.


Advanced techniques for using SOAP over JMS

The next sections describe some advanced techniques you can apply to your SOAP over JMS implementation to leverage additional features and capabilitoes of both SOAP/JMS and WebSphere Application Server V7. Continue on to explore:

  1. Permanent reply queue
  2. Asynchronous JAX-WS Web service invocations with SOAP over JMS
  3. Diagnostic trace of SOAP/JMS components

Permanent reply queue

By default, the Web services SOAP/JMS component within the client runtime will create a temporary reply queue prior to sending out a synchronous two-way request to the request queue (see Figure 1 for a diagram of the various components). This reply queue serves as the destination for the SOAP response message, and the client runtime receives the response message by listening on the reply queue. Because of the additional overhead associated with creating a temporary reply queue for each two-way request that is invoked, you might want to create your own permanent reply queue and specify its JNDI name to the client runtime prior to invoking the two-way request.

Creating the permanent reply queue is similar to creating the request queue. In this tutorial, you created a queue called "SJT_Request_Q." The create_jms_resource.py file also created a queue named "SJT_Reply_Q," even though it wasn't used in the tutorial. You can use this queue as a permanent reply queue if you configure the Web service client runtime to use it. There are three ways to do this:

  • Specify the replyToName property in the endpoint URL associated with the invocation.
  • Specify the JNDI name of the reply queue programmatically by setting a property on the RequestContext object (JAX-WS), or the stub or call object (JAX-RPC).
  • Set a JVM system property to be the JNDI name of the reply queue.

See Resources for more details related to using a permanent reply queue with SOAP over JMS.

For the purpose of this tutorial, use the first method: Specify the replyToName property in the JMS endpoint location URL that is used to invoke the Web service. Within the Web Services Test Client panel, you'll see a Quality of Service pane, which has an entry field called "Endpoint." Simply add the string &replyToName=jms/SJT_Reply_Q to the end of the endpoint location URL in the Endpoint entry field, then click Update. Next, type in a string in the echoInput entry field above, and click Invoke. (Figure 19)

Figure 19. Updating the endpoint location URL in the test client JSP window
Figure 19. Updating the endpoint location URL in the test client JSP window

Asynchronous JAX-WS Web service invocations with SOAP over JMS

The JAX-RPC programming model provides only a synchronous API, with no support for performing asynchronous Web service invocations. For this reason, when using SOAP over JMS with JAX-RPC Web service applications, you are limited to performing synchronous invocations even though the enterprise messaging paradigm is an inherently asynchronous model.

The JAX-WS programming model, on the other hand, includes an API for performing asynchronous Web service invocations. Since the enterprise messaging paradigm is asynchronous in nature, developers who use both JAX-WS and SOAP over JMS with their Web service applications might find that the asynchronous API of JAX-WS is the preferred approach for implementing their Web service client applications.

The SOAP/JMS support inside WebSphere Application Server's JAX-WS Web services runtime enables you to take advantage of the asynchronous nature of JMS. For JAX-WS Web service clients, you can configure a single reply queue per JVM process (application server, application client environment, and so on) that will serve as the destination for asynchronous response messages. When a client invokes a Web service two-way operation using the JAX-WS asynchronous API, control is returned to the client as soon as the request message is delivered to the request queue. When the operation finishes, the response message is sent to the configured asynchronous response queue. From there, the Web service runtime receives the response message, then correlates it to the original request. If the client application used the callback model, then the registered callback is invoked at that time. Otherwise, if the client used the polling model, the client can detect that the response is available, and can initiate its response processing.

See Resources for information on how to configure the asynchronous response queue for a JVM process.


Diagnostic trace of SOAP/JMS components

When things are not working as they should, it is often useful to capture a diagnostic trace to get a detailed view of what is happening "under the covers." To trace the SOAP/JMS components within the JAX-WS Web services runtime, you can use a trace string of com.ibm.ws.websvcs.transport.jms.*. For example, if you enable this trace string when running the application created in this tutorial, then you would get trace output similar to that which is contained in the included trace.log file.

When tracing the SOAP/JMS components, a few key trace messages will help determine what's happening with the processing of your Web service invocations:

  • When the client-side runtime first starts processing your request, you'll see a trace message like this:
    [10/1/08 15:11:41:281 CDT] 00000021 JMSSender     3   targetAddress: jms:jndi:jms/SJT
    _Request_Q?jndiConnectionFactoryName=jms/SJT_CF&targetService=EchoServicePortType
    &replyToName=jms/SJT_Reply_Q
  • When the request message is about to be sent to the destination request queue, you'll see a message like this:
    [10/1/08 15:11:41:296 CDT] 00000021 SOAPOverJMSSe 3   About to send message:
    
      JMSMessage class: jms_bytes
      JMSType:          null
      JMSDeliveryMode:  2
      JMSExpiration:    0
      JMSPriority:      4
      JMSMessageID:     null
      JMSTimestamp:     -1
      JMSCorrelationID: null
      JMSDestination:   null
      JMSReplyTo:       queue://SJT_SIB_Reply_Q
      JMSRedelivered:   false
        JMS_IBM_MsgType: 1
        SOAPJMS_contentType: text/xml; charset=UTF-8
        SOAPJMS_targetService: EchoServicePortType
        SOAPJMS_requestIRI: jms:jndi:jms/SJT_Request_Q?jndiConnectionFactoryName=jms/SJT
    _CF&targetService=EchoServicePortType&replyToName=jms/SJT_Reply_Q
        SOAPJMS_soapAction: echoOperation
        SOAPJMS_bindingVersion: 1.0
    3c736f6170656e763a456e76656c6f706520786d6c6e733a736f6170656e763d22687474703a2f2f
    736368656d61732e786d6c736f61702e6f72672f736f61702f656e76656c6f70652f223e3c736f61
    70656e763a426f64793e3c6e73323a6563686f537472696e67496e70757420786d6c6e733a6e7332
    3d22687474703a2f2f636f6d2f69626d2f7761732f777373616d706c652f7365692f6563686f2f22
    3e3c6563686f496e7075743e68656c6c6f20776f726c64213c2f6563686f496e7075743e3c2f6e73
    323a6563686f537472696e67496e7075743e3c2f736f6170656e763a426f64793e3c2f736f617065
    6e763a456e76656c6f70653e
    
    Message send options:
    deliveryMode=1, priority=4, timeToLive=300000
  • When the server-side runtime receives the request message from the queue, you'll see a message like this:
    [10/1/08 15:11:41:296 CDT] 00000025 JMSListenerMD 3   Received JMS Message: 
      JMSMessage class: jms_bytes
      JMSType:          null
      JMSDeliveryMode:  1
      JMSExpiration:    1222892201296
      JMSPriority:      4
      JMSMessageID:     ID:a363493f47d9981ef659c3fc110a134f0000000000000001
      JMSTimestamp:     1222891901296
      JMSCorrelationID: null
      JMSDestination:   queue://SJT_SIB_Request_Q
      JMSReplyTo:       queue://SJT_SIB_Reply_Q?busName=SJT_Bus
      JMSRedelivered:   false
        JMS_IBM_MsgType: 1
        JMSXDeliveryCount: 1
        JMSXAppID: Service Integration Bus
        SOAPJMS_contentType: text/xml; charset=UTF-8
        SOAPJMS_targetService: EchoServicePortType
        SOAPJMS_requestIRI: jms:jndi:jms/SJT_Request_Q?jndiConnectionFactoryName=jms/SJT
    _CF&targetService=EchoServicePortType&replyToName=jms/SJT_Reply_Q
        SOAPJMS_soapAction: echoOperation
        JMS_IBM_System_MessageID: 8F27F66FFE26F917_1000013
        SOAPJMS_bindingVersion: 1.0
        JMSXUserID: 
    3c736f6170656e763a456e76656c6f706520786d6c6e733a736f6170656e763d22687474703a2f2f
    736368656d61732e786d6c736f61702e6f72672f736f61702f656e76656c6f70652f223e3c736f61
    70656e763a426f64793e3c6e73323a6563686f537472696e67496e70757420786d6c6e733a6e7332
    3d22687474703a2f2f636f6d2f69626d2f7761732f777373616d706c652f7365692f6563686f2f22
    3e3c6563686f496e7075743e68656c6c6f20776f726c64213c2f6563686f496e7075743e3c2f6e73
    323a6563686f537472696e67496e7075743e3c2f736f6170656e763a426f64793e3c2f736f617065
    6e763a456e76656c6f70653e
  • In your sample application, the echoOperation() method that is part of your Web service implementation bean prints out two messages:
    [10/1/08 15:11:41:312 CDT] 00000025 SystemOut     O   >> JAX-WS EchoService: 
    Request received.
    [10/1/08 15:11:41:312 CDT] 00000025 SystemOut     O   >> JAX-WS EchoService 
    input string: 'hello world!'
  • When the server-side runtime is about to send a reply message back to the client, you'll see a message like this:
    [10/1/08 15:11:41:312 CDT] 00000025 JMSSender     3   About to send reply message:
    
      JMSMessage class: jms_bytes
      JMSType:          null
      JMSDeliveryMode:  2
      JMSExpiration:    0
      JMSPriority:      4
      JMSMessageID:     null
      JMSTimestamp:     -1
      JMSCorrelationID: ID:a363493f47d9981ef659c3fc110a134f0000000000000001
      JMSDestination:   null
      JMSReplyTo:       null
      JMSRedelivered:   false
        SOAPJMS_contentType: text/xml; charset=UTF-8
        SOAPJMS_bindingVersion: 1.0
    3c3f786d6c2076657273696f6e3d22312e302220656e636f64696e673d225554462d38223f3e3c73
    6f6170656e763a456e76656c6f706520786d6c6e733a736f6170656e763d22687474703a2f2f7363
    68656d61732e786d6c736f61702e6f72672f736f61702f656e76656c6f70652f223e3c736f617065
    6e763a426f64793e3c6e73323a6563686f537472696e67526573706f6e736520786d6c6e733a6e73
    323d22687474703a2f2f636f6d2f69626d2f7761732f777373616d706c652f7365692f6563686f2f
    223e3c6563686f526573706f6e73653e4a41582d5753204563686f20536572766963652073617973
    3a2068656c6c6f20776f726c64213c2f6563686f526573706f6e73653e3c2f6e73323a6563686f53
    7472696e67526573706f6e73653e3c2f736f6170656e763a426f64793e3c2f736f6170656e763a45
    6e76656c6f70653e
    
    Message send options:
    deliveryMode=1, priority=4, timeToLive=300000
  • Finally, when the client-side runtime receives a reply message, you'll see a message like this:
    [10/1/08 15:11:41:359 CDT] 00000021 SOAPOverJMSSe 3   Received JMS response message:
    
      JMSMessage class: jms_bytes
      JMSType:          null
      JMSDeliveryMode:  1
      JMSExpiration:    1222892201312
      JMSPriority:      4
      JMSMessageID:     ID:648da846da39062aecbd734d110a134f0000000000000001
      JMSTimestamp:     1222891901312
      JMSCorrelationID: ID:a363493f47d9981ef659c3fc110a134f0000000000000001
      JMSDestination:   queue://SJT_SIB_Reply_Q?busName=SJT_Bus
      JMSReplyTo:       null
      JMSRedelivered:   false
        JMSXDeliveryCount: 1
        JMSXAppID: Service Integration Bus
        SOAPJMS_contentType: text/xml; charset=UTF-8
        JMS_IBM_System_MessageID: 8F27F66FFE26F917_1000014
        SOAPJMS_bindingVersion: 1.0
        JMSXUserID: 
    3c3f786d6c2076657273696f6e3d22312e302220656e636f64696e673d225554462d38223f3e3c73
    6f6170656e763a456e76656c6f706520786d6c6e733a736f6170656e763d22687474703a2f2f7363
    68656d61732e786d6c736f61702e6f72672f736f61702f656e76656c6f70652f223e3c736f617065
    6e763a426f64793e3c6e73323a6563686f537472696e67526573706f6e736520786d6c6e733a6e73
    323d22687474703a2f2f636f6d2f69626d2f7761732f777373616d706c652f7365692f6563686f2f
    223e3c6563686f526573706f6e73653e4a41582d5753204563686f20536572766963652073617973
    3a2068656c6c6f20776f726c64213c2f6563686f526573706f6e73653e3c2f6e73323a6563686f53
    7472696e67526573706f6e73653e3c2f736f6170656e763a426f64793e3c2f736f6170656e763a45
    6e76656c6f70653e

Summary

This tutorial showed you how to use Rational Application Developer to create a top-down EJB-based Web service that uses SOAP over JMS as the transport instead of SOAP over HTTP. You also successfully tested the Web service with a JSP that was generated by Rational Application Developer.

Acknowledgements

The authors would like to thank Dan Sedov for his help in producing this article. The administrative script used to create the JMS resources in the tutorial is based on Dan's work.


Download

DescriptionNameSize
Code samplesoapjms_tutorial_downloads.zip6 KB

Resources

Learn

Get products and technologies

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into WebSphere on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere
ArticleID=372657
ArticleTitle=Develop a SOAP/JMS JAX-WS Web services application with WebSphere Application Server V7 and Rational Application Developer V7.5
publish-date=03182009