After the message is received, in the code above, the logic instantiates the standard AxisEngine, passes the deploy-shipping.wsdd to it, and invokes the MessageProcessor. Again, the name and location of the hard-coded deploy-shipping.wsdd file should be externalized to allow changes without code recompilation and redeployment.

The MessageProcessor works with a single SOAP request. It uses the AxisEngine to invoke the appropriate service operation. The beauty of this approach is that it reuses the AxisEngine that handles the SOAP messages without knowing how they were delivered. It's transport-independent.

...
Message soapMessage = new Message(bytesMessageReader);
MessageContext msgContext = new MessageContext(axisEngine);
msgContext.setRequestMessage(soapMessage);
axisEngine.invoke(msgContext);
soapMessage = msgContext.getResponseMessage();
...

The SOAP response is sent back to the JMS destination provided by the JMSSender from the consumer side.

...
Destination responseDestination = bytesMessage.getJMSReplyTo();
if (responseDestination != null)
{
    ByteArrayOutputStream out = new ByteArrayOutputStream();
    soapMessage.writeTo(out);
    JMSUtil.sendJmsMessage(responseDestination, out.toByteArray());
}
...

For simplicity's sake, we don't show any reasonable exception handlers or provide the code available in JMSUtil that contains the standard Java to-send JMS message to the specified destination.

Axis Server Engine
The Axis Server Engine is provided by Axis. As we mentioned, it has no knowledge of how the SOAP message was delivered. It just takes it and processes it, which will actually result in an invocation of the actual GetDistance operation of our ShippingService.

So how does AxisEngine find the ShippingService? Well, the deploy-shipping.wsdd provided to the AxisEngine is a standard Axis deployment descriptor. It describes handlers, services, operations, mappings, classes, and everything that Axis needs to find and invoke the operation as a regular Java method.

Shipping Service
We write the shipping service. It contains the actual business logic of the exposed service operations.

public class ShippingWebService
{
    public GetDistanceResponse getDistance(GetDistanceRequest request)
throws Exception
    {
       ...
    }
}

As a regular Axis Web Service, the shipping Web Service requires the deploy-shipping.wsdd that we use to deploy the service under Axis. To learn more about how to write WSDD files, see the Apache Axis documentation.

Service Provider Summary
The only component that we've added to handle SOAP messages is the JMSReceiver. It's plugged into the architecture to handle messages delivered through JMS. The rest of the components are exactly the same since they expose standard SOAP over HTTP services. That's why this architecture can handle requests delivered by both JMS and HTTP at the same time. Besides these two, by implementing appropriate receivers, the service provider can be extended to handle messages delivered by any transport.

The .NET Consumer of JMS
SOAP over HTTP is easy to consume from a .NET application. Visual Studio 2005 or WSDL.exe will automatically generate proxies based on a wsdl, so developers can get down to the business logic rather than worry about the plumbing. That's not to say it's as easy as pie. Not all SOAP is created equal, but addressing the issues around SOAP compatibilities would warrant an entire article (or several). Here we're focused on how to use the .NET infrastructure to consume Java SOAP services over JMS. Our examples were created for .NET 2.0 using Visual Studio 2005 and they assume a general understanding of how to generate HTTP Web Service proxies. (Figure 2)