Introduction to SOAP and Axis

What is SOAP?

At the heart of Web services today is SOAP and WSDL, so it is important that one has a good understanding of it is before we go into any more details. SOAP was originally an acronym for Simple Object Access Protocol (Now it's just a name). SOAP is the standard messaging protocol used by almost all types of Web services. SOAP's primary application is Application-to-Application (A2A) communication. Specifically, it is used in Business-to-Business (B2B) and Enterprise Application Integration (EAI). Well, both are essentially the same thing and instead of using hi-def acronyms, let me clarify the issue a little by saying that SOAP is the medium of choice for integrating software and sharing data. Unlike earlier B2B and EAI technologies, such as CORBA and EDI, SOAP is platform independent, flexible and based on standard, ubiquitous technologies. It enjoys widespread use and has been endorsed by most enterprise software vendors and major standards organizations.

So, the earlier paragraph was just to attract your attention with the usage of long-winded sentences and multi-syllable words. Here is where the real meat of the matter lies. SOAP is just another XML markup language accompanied by rules that dictate its use. SOAP has a clear purpose – exchanging data over networks. In a nutshell, SOAP is a network application protocol.

A SOAP document, which is generally called as a SOAP message, is usually carried as a payload on the HTTP protocol (or less commonly over other network transfer protocols like SMTP and FTP). Depending on the type of Web services, SOAP messages can be either One-Way Messages or Request/Response Messages (figures 1 and 2).

SOAP defines how messages can be structured (figure 3) and processed by software in a way that is independent of any programming language or platform, and thus facilitates interoperability between applications written in different programming languages and running on different operating systems. Of course, this is nothing new! CORBA IIOP and RPC also focused on cross-platform interoperability. These legacy protocols were never embraced by the software industry as a whole, however, so they never became pervasive technologies. SOAP, on the other hand, has enjoyed adoption by virtually all the players in distributed computing, including Microsoft, IBM, CA, Sun Microsystems, BEA, HP, Oracle and SAP. Open standards-based approach and its grounding on XML might explain SOAP’s pervasive adoption. Another advantage of SOAP would be its explicit binding to HTTP enabling HTTP tunneling, which is allowed by most corporate firewalls.

Fig 3: Structure of a SOAP message

Every XML document must have a root element, and in SOAP it's the Envelope element. Envelope may contain an optional Header element, but must contain a Body element. If you use a Header element, it must be the immediate child of the Envelope element and precede the Body element. The Body element contains, in XML format, the actual application data being exchanged between applications.

Now that we know what SOAP is, let us go on to tackle the next monster, JAX-RPC.

What is JAX-RPC?

The fundamental purpose of Java API for XML-based RPC (JAX-RPC) is to facilitate easier communication between Java and non-Java platforms. This is implemented in two steps – first by using standards based Web service technologies like XML and SOAP, and secondly by providing a simple object-oriented API that Java developers can use to communicate using those technologies. It works as follows:

1. A Java program invokes a method on a stub (local object representing the remote service);
2. The stub invokes routines in the JAX-RPC Runtime System (RS);
3. RS converts the remote method invocation into a SOAP message; and
4. The RS transmits the message as an HTTP request.

The advantage of such a method is that it allows the Web Service to be implemented on the server-side as a Servlet or EJB container. Thus, Servlet or EJB applications are made available through Web Services.



When developing a Web service as a stateless session bean, the endpoint interface is defined first. This along with deployment descriptors generates a common interface document called WSDL (will be explained in a later episode of this series). On the client side, SOAP messages can be generated using this document.

Message handlers are an important extension of JAX-RPC. They allow you to manipulate SOAP header blocks as they flow in and out of JAX-RPC endpoint and client applications. To better understand what these message handlers are and how they are useful, let us enter the world of Axis where handlers form the core implementation strategy.

What is Axis?

Axis is essentially a SOAP engine – a framework for constructing SOAP processors such as clients, servers, gateways, etc. In case you are wondering what Axis stands for, it is Apache EXtensible Interaction System - a fancy way of implying it is a very configurable SOAP engine. Axis is available in both Java and C++, albeit the Java implementation is much more popular. Axis delivers the following key features: 
· Speed: Axis uses SAX (event-based) parsing to achieve greater performance in timing benchmarks;
· Flexibility: The Axis architecture gives the developer complete freedom to insert extensions into the engine for custom header processing, system management or anything else you can imagine;
· Stability: Axis defines a set of published interfaces which change relatively slowly compared to the rest of Axis;
· Component-oriented deployment: One can easily define reusable networks of Handlers to implement common patterns of processing for applications, or to distribute to partners; and
· Transport framework: There is a clean and simple abstraction for designing transports (i.e. senders and listeners for SOAP over various protocols such as SMTP, FTP, message-oriented middleware, etc.), and the core of the engine is completely transport-independent.
And best of all, Axis is an Open Source effort; the URL to be noted is: http://www.ws.apache.org/axis/.

How does Axis Work?

Axis is all about processing messages. When the central Axis processing logic runs, a series of Handlers are each invoked in order. The particular order is determined by two factors – deployment configuration and whether the engine is a client or server.

Message Path on the Server

The server side message path is shown in the following diagram (figure 5). The small cylinders represent Handlers and the larger, enclosing cylinders represent Chains (ordered collections of Handlers).

A message arrives (in some protocol-specific manner) at a Transport Listener. In this case, let's assume the Listener is a HTTP Servlet. It is the Listener's job to package the protocol-specific data into a Message object (org.apache.axis.Message) and put the Message into a MessageContext. The MessageContext is also loaded with various properties by the Listener and passed on to the next component in line. The Axis Engine's first job is to look up the transport by name. The transport is an object that contains a request Chain, a response Chain, or perhaps both. A Chain is a Handler consisting of a sequence of Handlers that are invoked in turn. If a transport request Chain exists, it will be invoked, passing the MessageContext into the invoke() method. This will result in calling all the Handlers specified in the request Chain configuration. After the transport request Handler, the engine locates a global request Chain, if configured, and then invokes any Handlers specified therein.

Message Path on the Client

The Message Path on the client side is similar to the one on the server side, except that the order of scope is reversed, as shown in figure 6.



Handlers and Chains

Handlers are invoked in sequence to process messages. At some point in the sequence, a Handler may send a request and receive a response or else process a request and produce a response. Such a Handler is known as the pivot point of the sequence. As described above, Handlers are transport-specific, service-specific, or global. Handlers of each of these three different kinds are combined together into Chains. So the overall sequence of Handlers comprises three Chains – transport, global and service. Figure 7 shows two sequences of handlers – the client-side sequence on the left and the server-side sequence on the right. A Chain is a composite Handler, i.e. it aggregates a collection of Handlers



Now that we understand what Axis does and how it does, in the next episode of this series of articles we will make a sample Web service in Axis and consume it through a sample client.

We will also investigate the brave new world of SOA (Service Oriented Architecture) and what it means to a developer.