Page 2 of 7   « previous page   next page »

We build layers and layers, and as they help isolate different components, they impact performance and require additional managing. We can imagine a world of services after years of development, where to reach the very back end of business logic, a message flies through so many hubs that becomes impossible to attain reasonable SLAs anymore.

Why don't we eliminate the extra hubs when we can? How about if we reach the services directly through JMS? True, this may not be very appropriate for services exposed on the Internet, but it's probably more likely and preferable to do it in an organization where architectures like EDA (Event Driven Architecture) are implemented to help the production, detection, consumption of, and reaction to events.

We're going to show how to expose a Java Web Service via JMS using Apache Axis 1.4 and consume it from both Java and .NET clients by reusing the generated stubs and proxies and just changing the transport.

Java Service Consumer + MOM + Java Service Provider
As shown in Figure 1, our service consumer side consists of components that are both written by us (represented by the blue boxes) and those that are provided by Axis (represented by the white boxes). The picture on the service provider side is similar. In the middle, we have MOM (Message-Oriented Middleware), which increases the interoperability, portability, and flexibility of an application by letting it be distributed over multiple heterogeneous platforms. MOM reduces the complexity of developing applications that span multiple operating systems and network protocols by insulating developers from the details of the various operating systems and network interfaces.

Sample Service
Our sample Shipping Service has a GetDistance operation that accepts two ZIP codes and returns the distance between the two locations in miles.

To understand the roles and functionality of each component better, let's go through them.

Service Consumer Side
Consumer
The consumer is code we write. It uses generated-by-WSDL2Java stubs and proxies to instantiate the service request, populate it with request values, and provide it to the Axis client engine for transportation to the service endpoint.

The default transportation mechanism that Axis uses is the commonly accepted HTTP one and obviously it works with service endpoints that are specified by their http locations like HYPERLINK "http://momentumsi.com/service/shipping".

In our case, we want Axis to use JMS as a transport of our payload. We're looking for a way to reuse the generated-by-WSDL2Java code and just instruct Axis to deliver the payload via JMS instead of HTTP.

Fortunately, Axis provides a way to register different transports that should be used for the service endpoint URLs of the specified protocol. For example, we can register the provided-by-Axis org.apache.axis.transport.jms.JMSTransport to serve endpoint URLs that are specified by jms:// protocol like this:

import org.apache.axis.client.Call;
import org.apache.axis.transport.jms.JMSTransport;
...
Call.setTransportForProtocol("jms", JMSTransport.class);

The JMSTransport is responsible for parsing the transport-specific properties provided in the endpoint URL and setting them up in the message context. Later we'll explain how JMSSender handler takes those properties and does the actual JMS work.

Generated Proxy
The Generated Proxy is generated by the provided-by-Axis WSDL2Java utility. This component is used by the consumers to do both SOAP-over-HTTP and JMS calls. Even better, the component can be reused from any other registered transport implementation that we can come up in our architecture.

Axis Client Engine
The Axis Client Engine is provided by Axis. It can be configured with WSDD files that are written by us and provided to the engine via the generated proxy.

What is a WSDD file? A Web Service is deployed into Axis using an XML-based deployment descriptor file known as a Web Service Deployment Descriptor (WSDD). WSDD describes how the various components installed in Axis are to be chained together to process incoming and outgoing messages to the service. The WSDD can be used both on the client and server sides.

For our shipping service, here's an example of how to provide the client WSDD to the Axis client engine and then just invoke the GetDistance service operation:

import org.apache.axis.configuration.FileProvider;
...
EngineConfiguration engineConfig = new FileProvider("client-config.wsdd");
ShippingServiceLocator shippingServiceLocator = new ShippingServiceLocator(engineConfig);
ShippingSoapBindingStub shippingService = (ShippingSoapBindingStub)shippingServiceLocator.getShipping();
...
GetDistanceResponse response = shippingService.getDistance(request);

Notice that in this example the name and location of client-config.wsdd is hard-coded in the source code, but for production, you should change it so it's externalized and provided as a property, injected via the Spring framework or other mechanism.

Page 2 of 7   « previous page   next page »