Before you begin
This topic assumes that you installed a Java Message Service (JMS)
provider when you installed WebSphere Application Server (either the JMS provider
that is embedded in WebSphere Application Server, or another provider such
as WebSphere MQ). If not, install one now as described in
Installing and configuring a JMS provider.
Why and when to perform this task
To enable a service to be invoked through JMS by a Web Services
Invocation Framework (WSIF) client application, complete the following steps:
- Use the administrative console to create and configure a queue connection
factory and a queue destination as described in Configuring JMS provider resources.
- Use the administrative
console to add the new queue destination to the list of JMS Server destination
names for your application server as described in Managing JMS servers on Application Server (not part of a deployment
manager cell) or Managing JMS
servers in a deployment manager cell. Ensure that the Initial State
is started.
- Put the JNDI names of the queue destination and queue connection factory,
as well as your JNDI configuration, in the WSDL file.
You should also understand the specific ways in which WSIF interacts
with JMS:
- Only input JMS properties are supported.
- WSIF needs two queues when invoking an operation: one for the request
message and one for the reply. The replyTo queue is by default a temporary
queue, which WSIF creates on behalf of the application. You can specify a
permanent queue by setting the JMSReplyTo property to the JNDI name of a queue.
- WSIF uses the default values for properties set by the JMS implementation.
However in MQSeries and in some other JMS implementations, messages are persistent
by default, and the default temporary queue is of type temporary dynamic and
cannot have persistent messages written to it. Therefore your JMS listener
can fail to write a persistent response message to the temporary replyTo queue.
Note: If you are using MQSeries, you need to create a temporary model
queue that is of type permanent dynamic, then pass this model
as the tempmodel of your queue connection factory. This will
ensure that persistent messages are written to a temporary replyTo queue that
is of type permanent dynamic.