[Version 5.0.2 and later]Using the Java Message Service API to transport Web services requests

WebSphere Application Server supports the use of the Java Message Service (JMS) API to transport Web services requests, as an alternative to using HTTP. By using the JMS transport, your Web service clients and servers can communicate through JMS queues and topics instead of HTTP connections. One-way and synchronous two-way requests are supported.

Before you begin

A Web service must be implemented as an enterprise bean to be accessed through the JMS transport.

Review the Javadoc for a complete list of API's. You can also review several articles about the development of Web services at Web services: Resources for learning.

Why and when to perform this task

The benefits of using JMS include:

Perform this task after you have developed or implemented a Web service. This task explains how to configure the Web service to use JMS to transport the requests.

To configure a Web service to use JMS as a transport:

Steps for this task

  1. Add a JMS binding and a SOAP address to the Web Services Description Language (WSDL) file.

    The WSDL file of a Web service must include a JMS binding and a SOAP address, which specifies a JMS endpoint URL string, to be accessible on the JMS transport. A JMS binding is a wsdl:binding element that contains a wsdlsoap:binding element whose transport attribute ends in soap/jms, rather than the typical soap/http value.

    In addition to the JMS binding, a wsdl:port element referencing the JMS binding must be included in the wsdl:service element within the WSDL file. The wsdl:port element contains a wsdlsoap:address element with a location attribute that specifies a JMS endpoint URL string.

  2. Decide on the names and the types of JMS objects that your application uses.

    Before your application can be installed, you need to:

    1. Decide whether your Web service receives requests from a queue or a topic.
    2. Decide whether to use a secure destination, like a queue or topic, or a nonsecure destination.
    3. Decide on the names for your destination, connection factory and listener port.

      The following list provides examples of the names that might be used for a Web service called StockQuote:

      • Queue: StockQuote_Q (Java Naming and Directory Interface (JNDI) name: jms/StockQuote_Q)
      • Connection factory: StockQuote_CF (JNDI name: jms/StockQuote_CF)
      • Listener port: StockQuoteEJB_ListenerPort

  3. Define the JMS administered objects.

    After you decide on the names and types of the JMS objects, use the administrative console or the wsadmin scripting interface to define the JMS objects.

  4. Add the JMS endpoints to your enterprise archive (EAR) file using the endptEnabler command.
    You must run the endptEnabler command to add a JMS endpoint or a router module for each Web service-enabled enterprise JavaBean (EJB) Java archive (JAR) file that is contained in the EAR file. By default, the endptEnabler command adds only HTTP endpoints, but the -transport jms command option can be used to request the addition of JMS endpoints.
  5. Configure security for the JMS connection.

    For a secure JMS connection, add the basicAuth assembly property to the ibm-webservicesclient-bnd.xmi deployment descriptor file. Set the user ID and password attributes.

    If the basicAuth property is not provided in the ibm-webservicesclient-bnd.xmi deployment descriptor file, the JMS connection can be rejected, depending on the security configuration of the JMS provider.

  6. Deploy the Web services application.

    During the installation process you are prompted for two types of information for each Web service-enabled EJB JAR contained in your EAR file:

    • The JNDI name of the connection factory for the EJB JAR file message-driven bean (MDB) listener to use for sending reply messages.

      If your Web service contains two-way operations, the MDB listener that is defined inside the JMS endpoint added by endptEnabler command, needs to access a queue connection factory to add a reply message to the reply queue.

      The MDB listener uses a resource environment reference of java:comp/env/jms/WebServicesReplyQCF. Therefore, during the application installation process, you must provide the actual JNDI name of the queue connection factory for the MDB listener to use for that Web service. You might want to use the same connection factory that you defined for use by clients in step 2.

    • The name of the listener port for the MDB listener to use.

      A listener port is an object that is used to associate a JMS connection factory with a JMS destination (queue or topic). When deployed, an MDB is configured with the correct listener port so that messages from the queue or topic are properly delivered to the MDB. During deployment, you can modify the name of the listener port that is associated with each MDB listener. The listener port name contained in the input EAR file is displayed as a default value. If you specify the correct listener port name to the endptEnabler command, you can accept the default value. Otherwise, enter the correct listener port name.

      Hint: By default, the endptEnabler command produces listener port names of the form <ejb-jar-name>_ListenerPort. To simplify this step, define the listener ports that follow this naming convention during step 2.

Results

You have a Web service that is configured to use JMS to transport the requests.

What to do next

Publish the WSDL file.

Related tasks
Implementing Web services based on Web Services for J2EE
Enabling a Web services-enabled EAR file
Publishing WSDL files
Related reference
endptEnabler command
Java Messaging Service endpoint URL syntax
ibm-webservicesclient-bnd.xmi assembly properties



Searchable topic ID:   twbs_jmstransport
Last updated: Jun 21, 2007 8:07:48 PM CDT    WebSphere Business Integration Server Foundation, Version 5.0.2
http://publib.boulder.ibm.com/infocenter/wasinfo/index.jsp?topic=/com.ibm.wasee.doc/info/ee/ae/twbs_jmstransport.html

Library | Support | Terms of Use | Feedback