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.
Before you begin
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.
About this task
The benefits of using JMS include:
- Reliable messaging for request and response messages.
- Flexible one-way requests for clients and servers. For example, the server
does not have to be active when the client sends the one-way request.
- Simultaneous one-way requests can be sent to multiple servers through
the use of a topic.
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
- 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.
- Decide the names and the types of the JMS objects that your application
uses.
Before your application can be installed, you need to:
- Decide whether your Web service receives requests from a queue
or a topic.
- Decide whether to use a secure destination, like a queue or
topic, or a nonsecure destination.
- 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:
- 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
- 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 Choosing a messaging provider for
more information.
- 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.
- 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.
- 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:
- The JNDI name of the connection factory for the enterprise bean 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. Configuring a permanent
replyTo queue for Web services using SOAP over JMS on the client can
be beneficial to prevent the client from having to set the JMS message's replyTo property
each time a Web service request is made.
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.
- 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.