Enable a WSIF client to invoke a web service through JMS
The ways in which the Web Services Invocation Framework (WSIF) interacts with the Java Message Service (JMS), and the steps to take to enable a service to be invoked through JMS by a WSIF client application.
This topic assumes that we chose and configured a JMS provider when we installed WebSphere Application Server (either the default messaging provider, or another provider such as the IBM MQ messaging provider). If not, do so now as described in Choose a messaging provider.
Here are the ways in which WSIF interacts with JMS:
- WSIF only supports input JMS properties.
- 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. We 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.
To enable a service to be invoked through JMS by a WSIF client application:
Tasks
- Use the administrative console to create and configure a queue connection factory and a queue destination for our chosen messaging provider.
See Configure resources for the default messaging provider, Configure JMS resources for the IBM messaging provider or Manage messaging with a third-party messaging provider.
In IBM MQ and some other JMS implementations, messages are persistent by default. The WSIF replyTo temporary queue is of type temporary dynamic by default, which means that your JMS provider cannot write a persistent response message to this queue. If we are using the IBM MQ messaging provider, create a temporary model queue that is of type permanent dynamic, then pass this model as the tempmodel of your queue connection factory. This ensures that persistent messages are written to a temporary replyTo queue that is of type permanent dynamic.
- Use the administrative console to add the new queue destination to the list of JMS destination names for the application server. 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 Web Services Description Language (WSDL) file.
- Optional: If our client is running on an application server that has been migrated from WAS v5, we might get basic authentication errors and therefore have to modify our security settings. For more information see Web Services Invocation Framework troubleshooting tips.
Subtopics
- Configure resources for the default messaging provider
Use the following tasks to configure JMS connection factories, activation specifications, and destinations for the default messaging provider.- Configure JMS resources for the IBM messaging provider
Use the WAS administrative console to configure activation specifications, connection factories and destinations for the IBM MQ JMS provider.- Manage messaging with a third-party messaging provider
For messaging between application servers, most requirements are best met by either the default messaging provider or the IBM MQ messaging provider. However, we can instead use a third-party messaging provider (that is, use another company's product as the provider). We might want to do this, for example, if we have existing investments.
Related:
WSIF and WSDL Writing the WSDL extension that lets the WSIF service access a SOAP over JMS service Writing the WSDL extensions that let the WSIF service access a service at a JMS destination Administer WSIF WSIFOperation - Asynchronous interactions reference WSIFOperation - Synchronous and asynchronous timeouts reference