The benefits of using JMS as an alternative to HTTP include the following:
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 StockQuote Web service:
After creating your web service, you can run the Create Router Modules wizard to add a JMS endpoint (router module) for each web service-enabled EJB .jar contained in the EAR file. If you create the web service using the web services wizard, this is done for you automatically.