Operating Systems: i5/OS
             Personalize the table of contents and search results

 

Use the Java Message Service API to transport JAX-RPC Web services requests

 

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

A JAX-RPC Web service must be implemented as an enterprise bean for accessibility through the JMS transport.

Review the API documentation 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.

 

Overview

The benefits of using JMS include:

To configure a Web service client application to send one-way requests transactionally, see Invoking one-way JAX-RPC Web service requests transactionally using the JMS transport.

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:

 

Procedure

  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, for accessibility 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.

    The specification of the actual JMS endpoint URL string can be deferred until you configure endpoint URL information for JMS bindings. As you develop Web services, a placeholder such as file:/unspecified_location can be used for the endpoint URL string.

  2. Decide the names and the types of the 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 the names for your destination, connection factory and listener port. The following list provides examples of the names that can be used for the StockQuote Web service:

  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 tool to define the JMS objects. There are various ways to administer JMS resources depending on what type of JMS provider is being used. See Using JMS resources of a generic provider for more information.

  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 enterprise bean Java archive (JAR) file that is enabled for Web services and 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 enterprise bean JAR file that is enabled for Web services and is contained in your EAR file:

  7. Configure endpoint URL information for JMS bindings.

    The WSDL publisher uses this partial URL string to produce the actual JMS URL for each port component that is defined in the enterprise bean JAR file. The published WSDL file can be used by clients that need to invoke the Web service.

 

Results

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

 

What to do next

Publish the WSDL file.


}
Java Message Service endpoint URL syntax

Configuring a permanent replyTo queue for JAX-RPC Web services using SOAP over JMS

Invoking one-way JAX-RPC Web service requests transactionally using the JMS transport

 

Related tasks


Configuring endpoint URL information for JMS bindings
Task overview: Implementing Web services applications
Enabling an EAR file for Web services
Making deployed Web services application available to clients

 

Related Reference


endptEnabler command

 

Related information


Web services SOAP/JMS protocol