Welcome!

Java Authors: Liz McMillan, Walter H. Pinson, III, Maureen O'Gara, Yakov Werde, Tony Bishop

Related Topics: .NET, Java

.NET: Article

Java & .NET: SOAP Over JMS Interoperability

Exposing a Java Web Service via JMS using Apache Axis 1.4 and consuming it from both Java and .NET clients

client-config.wsdd
The client-config.wsdd is used by the Axis client engine to specify the handler responsible for sending the message to the ultimate receiver. The following deployment descriptor replaces the default HTTPSender handler with the JMSSender handler that uses JMS to transport SOAP messages.

<?xml version="1.0" encoding="UTF-8"?>
<deployment
xmlns=HYPERLINK "http://xml.apache.org/axis/wsdd/"http://xml.apache.org/axis/wsdd/
xmlns:java="http://xml.apache.org/axis/wsdd/providers/java">
<handler name="JMSSender"
type="java:org.apache.axis.transport.jms.JMSSender" />
<transport name="JMSTransport" pivot="JMSSender"/>
</deployment>

URL-based JMS Transport
The JMS URL syntax provides a vendor-neutral way of specifying JMS specific details like Topic and Queue destinations.

The query part of the service provider endpoint URL (the part after the question mark) is treated by Axis as key/value pairs and they are provided to the JMS vendor adapter factory to instantiate a specific adapter. The default JMS adapter in Apache Axis is JNDI, so if the vendor=JNDI isn't specified in the URL then the default org.apache.axis.components.jms.JNDIVendorAdapter will be used to locate the JMS connection factory and destinations. You can write your own adapter, just make sure it's available in the CLASSPATH and specified by the vendor property like vendor=com.momentumsi.jms.adapters.MyOwnAdapter.

If your JMS provider happens to be Tibco's EMS then a sample URL may look like this:

jms://tibjms/queue?java.naming.provider.url=tcp://localhost:7222&java.naming.factory.initial
=com.tibco.timjms.naming.TibjmsInitialContextFactory&ConnectionFactoryJNDIName
=QueueConnectionFactory&Destination=queue.test

Before making the actual call, the Consumer must change the service provider endpoint to the JMS one as shown in the example below:

...
String jmsUrl = "jms://...";
shippingService._setProperty(javax.xml.rpc.Stub.ENDPOINT_ADDRESS_PROPERTY, jmsUrl);
...
GetDistanceResponse response = shippingService.getDistance(request);

Axis JMS Sender
The JMSSender handler is provided by Axis. It takes the properties from the message context that were parsed and prepared by the JMSTransport and does the actual work:

Create JMS connection
Create temporary JMS response destination
Send the location of the temporary JMS destination together with the actual SOAP request to the specified JMS request destination
Receive the SOAP response from the temporary JMS response destination
Provide the SOAP response to the Axis Client Engine to be delivered to the consumer

Service Consumer Summary
We were able to reuse the unchanged code that was generated by WSDL2Java. We registered a transport implementation that handles jms:// URLs and we changed the endpoint URL to jms:// where we specified JNDI properties like JMS connection factory and destination. We provided a custom client-config.wsdd to the Axis Client Engine, where we specified an Axis-provided JMS handler that does the actual send and receive of SOAP requests and responses.

MOM (Message-Oriented Middleware)
As described above, the MOM layer increases interoperability, portability, and flexibility. It has no knowledge of the consumers or message provider and just does what it does best: serve as a backbone for an Event Driven Architecture.

MOM could be any available JMS provider like ActiveMQ, JBoss Messaging, Open JMS, Oracle AQ, Tibco EMS, WebSphere MQ, or for advanced processing, any available ESB provider like Apache ServiceMix, Tibco BusinessWorks, Sonic ESB, or OpenESB.

Service Provider Side
Service Provider JMSReceiver
Although Axis provides a simple org.apache.axis.transport.jms.SimpleJMSListener receiver, it's not intended for production. It's for testing and debugging purposes. So we have to write our own.

Our ShippingJMSReceiver is a standard JMS listener that extends javax.jms.MessageListener. Its basic purpose is to listen asynchronously for messages and then pass them off to our MessageProcessor. It can be deployed as a MDB (Message Driven Bean) to any application server, or even configured via Jencks to deploy inside Spring and provide a Message-Driven POJO.

public class ShippingJMSReceiver implements MessageListener
{
    public void onMessage(javax.jms.Message message)
    {
       BytesMessage bytesMessage = (BytesMessage) message;
       MessageProcessor msgProcessor = new MessageProcessor();
       msgProcessor.processMessageAsSoapRequest(getAxisEngine(), bytesMessage);
    }

    private AxisEngine getAxisEngine() throws Exception
    {
       FileProvider fileProvider = new FileProvider("deploy-shipping.wsdd");
       return new AxisServer(fileProvider);
    }
}


More Stories By Stanimir Stanev

Stanimir Stanev is a senior consultant at MomentumSI's Enterprise Architecture Solutions practice. He has many years of experience focusing on providing enterprise architecture and strategy expertise to companies looking to migrate to or maximize the advantages of SOA principles.

More Stories By Rob Bartlett

Rob Bartlett is a senior consultant at MomentumSI's Software Development Solutions practice. He has over a decade of experience in technical roles, guiding major corporations in the design, implementation, and integration of business solutions.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.