JMS Transport

Apache AXIS2 support a JMS transport layer in addition to the existing HTTP transport. This allows Web service clients and servers to communicate via JMS queues and topics instead of HTTP connections. Both one-way and synchronous two-way requests are supported. 

The benefits of using JMS as an alternative to HTTP include the following:

• Request and response messages are sent by way of reliable messaging.
• One-way requests allow client and server to be more loosely-coupled (the server does not have to be active when the client sends the one-way request).
• One-way requests can be sent to multiple servers simultaneously through the use of a topic.

If a web service is to be accessible on the JMS transport, then the corresponding WSDL document should include a JMS binding and a SOAP address which specifies a JMS endpoint URL string. A JMS binding is simply a wsdl:binding element which contains a wsdlsoap:binding element whose transport attribute ends in soap/jms, rather than the normal soap/http value. In addition to the JMS binding, a wsdl:port element which references the JMS binding should be included in the wsdl:service element within the WSDL document. This wsdl:port element should contain a wsdlsoap:address element whose location attribute specifies a JMS endpoint URL string.

You also need to decide on the names and types of JMS objects that your application will use. For example, you must decide whether your web service will receive its requests from a queue or a topic. You also must decide whether to use a secure destination (queue or topic). Finally, you will need to decide on the names for your destination, connection factory, and listener port.   The following list provides an example of the names that might be used for the sample MessageReceiveService web service:

Axi2 Configurations

axi2.xml file, which configures the axis2 server on which above service is hosted, should be enabled with JMS transport.