Conspiracy Revealed!!!
So far in this blog I have been discussing about fundamental principles, protocols and languages involved in Web services. So now it's high time we focus a bit on the practical aspects of Web services, with the support of the framework we have built so far from the theoretical stuff I have discussed in my previous blog entries. If you can recall the 'Ultra-Mobile' example I have mentioned in my immediate past blog entry, I have discussed things like how to publish Web services, how clients can properly identify an invoke a Web service and how clients can find out about existing Web services. But if you look closely you will notice that I have neatly skipped a fundamental aspect regarding Web services there. I have said that 'Ultra-Mobile' has got a Web service up and running but I haven't mentioned how they have made it up and running. (“oh yeah..I'm good..Am I not?”) Well actually that was done intentionally because otherwise that blog entry would have been way too complicated and long. (“one step at a time...just applying the divide and conquer algorithm, you know”)
So now I'm going to discuss a bit on how we can actually deploy a Web service for clients to invoke and use. (“wait a second...you are trying to skip a piece of the puzzle again...you have not said how we develop a Web service yet...”) I will be discussing on how to develop Web services probably in my next blog entry. (“Happy now?”)
There are various tools and technologies out there that can be used to deploy Web services. So I'm going to narrow my discussion to a certain family of technologies, namely the Apache Axis and Apache Axis2 technologies. They are probably the most popular technologies that are being used to deploy Web services. Consider them as powerful software tool kits and Web services engines available for playing around with SOAP.
Spinning Around the Axis
Formally Axis is defined as an open source, XML based (“oh brother give me a break!”) Web services framework. The name 'Axis' stands for Apache Extensible Interaction System. It mainly consists of the SOAP server (implemented either in Java or C++) and various other utilities and APIs for generating and deploying Web services. The Apache SOAP was initially developed by IBM and donated to the Apache Software Foundation. Axis is more or less like the second version of Apache SOAP but it is a from-the-scratch implementation with many additional features and bug fixes compared to Apache SOAP. With Apache Axis we can easily and quickly deploy Web services. Axis can be executed as a simple standalone server but the best practice is to use a different servlet container like Apache Tomcat along with Axis. It is pretty easy to get Axis to work with a servlet container. The servlet container will be the entity to receive all the Web service requests from the clients and it will delegate them to Axis which will pick the relevant service to process the request.
Since Axis deals with Web services it has to do a lot of business with XML. In a way it is not wrong to say that dealing with Web services is all about dealing with XML (“you can say that again…”). Therefore any Web services engine must have a solid methodology to handle XML and in the case of Axis, it uses DOM for this purpose.
Getting Dum with DOM
DOM stands for Document Object Model and it is a language independent standard platform for representing, parsing and manipulating XML or HTML documents. With DOM an XML document can be navigated in any direction and can be modified arbitrarily. DOM treats an XML document as a collection of nodes (DOM doesn’t leave anything behind in this case). The document itself is a document node. Every XML tag is an element node. The text contained within XML tags are mapped to text nodes and the XML attributes are mapped to attribute nodes. Even XML comments are mapped to comment nodes. All the nodes combine to form one big hierarchical tree of nodes. What we actually achieve by letting DOM do so is that we can easily represent the nodes as objects of a computer program (in fact this is what is expected from DOM – to provide an programming interface to handle XML documents). So with DOM we can convert an XML document in plain text into a collection of objects residing in the computer memory. Once they are in the memory as objects we can call any valid method on any node to do some useful task (like changing the text value of a text node). So clearly with DOM, XML manipulation becomes an elementary task for the application that uses DOM (like Axis)
However there are some pitfalls associated with DOM. Applications based on DOM must always load the whole document to memory before doing anything with it. But in most situations the applications are interested only in a small portion of the XML document. In that case having to load the entire document just to read couple of lines off it could be a huge performance bottleneck. But nevertheless even today DOM is being extensively used in many applications. DOM is heavily used in the world of JavaScript.
New Kid in Town...
With the rapid growth and adaption of Web services technologies, a new Web services engine with more features and performance became and absolute necessity. As a result the Apache Software Foundation initiated the Apache Axis2 project as a follow on to the Axis project. The initial versions of Axis2 went public in early 2005 but some major revisions have been made afterwards. Axis2 is much better than Axis in terms of performance, features, flexibility and ease of use. Also Axis2 is based on a new XML infoset representation. Therefore Axis2 does not suffer the drawbacks caused by DOM. Axis2 supports some of the latest additions to the collection of Web services specifications like WS-Addressing and WS-Reliable Messaging.
AXIOM (Axis Over the Moon???)
No...AXIOM stands for Axis Object Model. It is the new XML infoset representation being used in Axis2. It is a totally different approach to efficient handling of SOAP messages. AXIOM is built around a pull parser interface called StAX. Therefore the application can parse only a selected portion of an XML document if needed which was not a feature present in DOM. AXIOM uses a "builder" that will build the XML object model in memory, according to the events pulled from the underlying StAX parser, but will not create the entire object hierarchy at once. Instead, it only builds when the relevant information is absolutely required. The builder comes into the picture when you are building an object model from an existing resource. If you build the object model programmatically, then you don't have to use builders. AXIOM also has better support for XOP (XML-Binary Optimized Packaging) and MTOM (SOAP Message Transmission Optimization Mechanism).
OK...So now we know that Axis2 uses AXIOM as the primary means of representing and manipulating XML. All the SOAP messages (which are just XML messages) arriving at Axis2 engine are converted to a set of objects using AXIOM. Afterwards these objects must pass through a sequence of phases forming a pipeline of SOAP messages being processed. At each phase some processing is done on the message. How the processing is done is primarily decided by the handlers present in each phase.
The most critical thing Axis2 must handle is dispatching Web service requests. It has to delegate the requests to the appropriate service (service dispatching) and then it has to invoke the appropriate operation on the service (operation dispatching). Dispatching is done based on some information available on the SOAP request itself (HTTP request URL, SOAPAction etc.). Axis2 has four dispatchers to look at the relevant information and perform the dispatching accordingly.
