The history of Web services has gone through several iterations during its evolution. The first-generation Web services were highly controlled interactions and can be considered as mere tests of feasibility. Apache SOAP was one of the notable SOAP engines in the first generation, and it was mainly meant to be "proof of concept" and not at all concerned about performance. The whole idea of the first-generation SOAP engines was to convince the world that Web services are a desirable option.
Soon these first-generation SOAP engines paid off. More companies started showing interest and the concept of SOA started taking shape. This stage can be called the second generation of Web services and it required better and faster SOAP engines. Aspects such as discovery and definition were already standardized and SOAP engines also needed to support these standards. Axis was born as one of these second-generation SOAP engines.
Now the second generation of Web services is coming to an end. Web services are now in high demand and a large number of players have entered the Web service arena. Aspects governing different facets of Web service interactions have been standardized. The third generation of Web services requires faster, and more robust, SOAP engines -- and the existing Axis is not enough for this. Axis2 was made to fill this gap.
Axis2 has modular architecture and consists of core modules as well as a few non-core modules. Axis2 core is said to be a pure SOAP processing engine without Java™ API for XML-based RPC (JAX-RPC) concept as part of its core. In the meantime the Axis2 architecture has been designed with the following principles in mind:
- Logic and state separated to provide stateless processing mechanism because Web services are said to be stateless
- All the information in one information model to enable system to be suspended and resumed
- Ability to extended the functionality without changing the core architecture, simply to support newWeb service specifications with minimum or no changes to core
Axis2 core architecture consists of the following core and non-core components:
- Core components
- XML Object Model (AXIOM)
- SOAP processing model : handler framework
- Information processing model: contexts and descriptions
- Other components
- Deployment model
- Transports
- Client API
- Code generation model
You can see these components in Figure 1.
Figure 1. Axis2 architecture diagram
Axis2 is not just the new Web service framework of Apache. It is also shaped by experiences from the Axis 1.x family and the advancements in the Web service stack during the last two years. One of the main reasons for introducing Axis2 was to perform better in terms of speed and memory -- despite the fact that new features and functionalities are added. Most of the new features are to make the Axis2 easier to use, while keeping room for extending functionality in various ways. The key areas where most of the new features are added listed below:
- New XML Object Model (AXIOM)
- Messaging-based core
- Improved deployment Model
- Pluggable data binding
- New Client API
- Information Processing model
As mentioned above, Axis2 is built on a completely new architecture as compared with Axis 1.x. One of the main reasons of introducing Axis2 was to have a proper XML processing model. Axis 1.x used DOM as its XML representation mechanism, but the drawback with DOM is the need to keep the complete objects hierarchy (corresponding to incoming message) in memory. For a message of small size this will not be a problem, but when it comes to a large message this becomes an issue. It is to overcome this problem that Axis2 introduced a new XML representation for it base.
AXIOM (AXIs2 Object Model) is the base for Axis2, where any incoming SOAP message is represented as AXIOM inside Axis2. The advantage of AXIOM over other XML representations is that it is based on a pull parser technique, while most others are based on a push parser technique. The main difference of pull over push is that in the pull technique the invoker has the full control on the parser and he can ask for the next event, where as in the case of push, when we ask the parser to proceed it will fire the events until it reaches the end of the document.
Since AXIOM is based on a pull parser technique it has so called "on-demand-building" capability where an object model will be built only if it is asked to do so, and, also if required one can directly access underline PULL parser from AXIOM and use that rather than building Object Model (OM).
Axis2 core is a pure SOAP processing engine and does not understand data bindings, transports, WSDL and the like. The main functionality of Axis2 core is to process an incoming message and deliver it to the destined application. As in Axis 1.x, Axis2 also has the concept of handlers to extend its main functionalities.
Axis 1.x does not have the concept of asynchronous Web service invocation and it is completely bound to request-response invocations, but in Axis2 it is the other way round. The Axis2 architecture is capable of supporting asynchronous invocation both in the client side and in the server side. In the meantime, Axis2 does support request-response type innovation as well, but it takes place as two asynchronous innovations. In Axis2 world a message coming into the system may or may not have response and it should note that Aixs2 supports all the eight Message Exchange Patterns (MEP) defined in WSDL 2.0.
Axis2 has the concept of flow, where flow is a collection of phases, and phase is a collection of handlers. Depending on the MEP for a given method invocation the number of flows associated with it may vary. If an in-only MEP corresponding method has only one flow it is called the inflow) and the in-out case has two flows --inflow and outflow. In most cases inflow starts from a transport listener and ends with MessageReceiver, while outflow could start in a different manner and will most of the time end with transport sender.
Figure 2. Phases in a flow
Figure 3. Inflow and the message receiver
Previous versions of Axis failed to address the user friendliness factor involved in the deployment of a Web service, and for this reason Axis 1.x was developed, mainly to prove the Web service concepts. Therefore in Axis 1.x, the user has to invoke the admin client manually and update the server classpath, and then restart the server to apply the changes. This burdensome deployment model was a definite barrier for beginners. Axis2 is engineered to overcome this drawback and provide a flexible, user-friendly, easily configurable deployment model
Axis2 deployment introduced the notion of a Java™ 2 Platform, Enterprise Edition (J2EE)-like deployment mechanism, where a developer can bundle all the class files, library files, resources files, and configuration files together as an archive file, and drop it to specified location in the file system.
The concept of hot deployment and hot update is not a new technical term (particularly for those versed in the concepts of a Web services platform), but for Apache Axis it is a new feature. Therefore Axis2 was developed by keeping room for "hot" deployment features.
Hot deployment:The capability of deploying service while system is up and running. System availability is very important in a realtime system or business environment. If the system is down even for a moment, the loss might be substantial and it may affect the lifetime of the business. However, in the meantime it is required to add new services to the system and if this can be done without shutting down the servers, that would be a great achievement. So Axis2 addresses that and provides web service hot deployment ability, where you do not need to shut down the system to deploy a new Web service. What needs to be done is to drop the required web service archive into the services directory in the repository. Then the deployment model will automatically deploy the service and make it available to you.
Hot update:The ability of making changes to an existing web service without shutting down the system. This is an important feature and required in a testing environment. However, it is not advisable to use hot update in real time system, because hot update could result in the system leading into an unknown state. Additionally, there is the possibility of loosening the existing service data of that service. To prevent this, Axis2 comes with the hot update parameter set to false by default.
As mentioned above, Axis2 also has the concept of handler but when compared to Axis 1.x there are few changes in the way you specify and deploy handlers. In Axis 1.x adding a handler is required to change global configuration file and then requires restarting the system, and there was no dynamic way of changing handler chain at the runtime.
To overcome this problem , and to add new features, Axis2 introduces the concept of Web service extensions or a module, where the main job of a module is to extend core functionality. In Axis 1.x you achieved this by adding the handler to handler chain. The advantage with module over Axis 1.x handler chain is that you can add a new module without changing any global configuration files at all. In the meantime, module is a self container where it contains handlers, third-party libraries, module related resources and the module configuration file.
A module can be deployed as an archive file, and Axis2 came up with a new file extension for module called .mar. The most important file in a module archive file is the module configuration file or module.xml. A module will be a faulty module unless it has a module.xml file. A module configuration file functions mainly to specify handlers and their phase rules, so once you engage a module, depending on the phase rule, handlers will be placed on different flows -- inflow or outflow.
The idea is very simple. Perhaps you need to support WS-Addressing or WS-Security. Then what you have to do is download the corresponding module and drop that into the modules directory in the Axis2 repository. You can engage the module at the deployment time by adding the following entry to axis2.xml (Axis2 global configuration file), or you can engage the module at the run time using various ways, such as using Axis2 web admin, or by a handlerfor exsample:
<module ref="ModuleName">
Asynchronous or non-blocking Web service invocation is a key requirement in Web services nowadays. In the meantime there are a few ways of invoking a Web service in a non-blocking manner. The first is the client programming model, where a client invokes the service in a non-blocking manner without blocking his application. The second way is the transport level non-blocking invocation, where invocation happens in two transports. It could be two one-way transports like SMTP, or two two-way transports like HTTP. Axis2 client API support both the above non-blocking invocation scenarios.
Axis2 introduced a very convenient client API for invoking service, and the API consisting of two classes called ServiceClient and OperationClient. ServiceClient API is especially for average users where they just need to send and receive XML, while operation client is meant tofor advanced users who want to work with SOAP headers and some other advanced tasks. With service clients you can only access SOAP body or the pay load. Of course you can add SOAP headers but you do not have a way to retrieve SOAP header from service client. For that you will need to use an operation client.
The Service client has the following API for invoking a service:
- sendRobust
- fireAndForget
- sendReceive
- sendReceiveNonBlocking
sendRobust: The whole idea of this is to send XML junk to a Web service and not care about the response. However, if something goes wrong, you would need to know that too. So this API is to invoke a service where that does not have a return value but that could throw an exception.
fireAndForget: This API is just to send XML junk and not care about either response or the exception, so this is to invoke in-only MEP.
sendReceive: To invoke a service which has a return value. This is one of the most commonly used API , and can be used to invoke in-out MEP.
sendReceiveNonBlocking: To invoke a service in a non-blocking manner. When the service has a return value this method can be used. In order to use this method you have to pass a callback object and once the invocation is completed, the callback object will be called.
As mentioned above, the operation client is for an advanced user, and working with operation client requires you to know Axis2 well. In service client you do not need to know anything about SOAP envelope or message context, but when it comes to operation client you have too create it yourself before invoking a service. Creating and invoking a service using operation client involves following steps:
- Create a service client
- Then create operation client using the created service client
- Create SOAP envelop
- Create Message context
- Add the SOAP envelope to message context
- Add the message context to operation client
- Invoke the operation client
- If there is a response, then get the response message context from operation client
Axis2 will not proof web services concepts but will provide a better SOAP processing model, with considerable increase in performance of both speed and memory with respect to Axis 1.x and other existing web service engines. In addition it provides the user with a convenient API for deployment service, extending core functionality and new client programming model. Now it's time to play with Axis2.
- Learn about
XML Pull parsing.
- Read "Get the most out of XML processing with AXIOM" (developerWorks, September, 2005) for an overview of this approach to XML processing.
-
Read about Apache Axis2 at the Apache Software Foundation.
- Check out the Latest SOAP versions at W3C.
-
The SOA and Web services zone on IBM developerWorks hosts hundreds of informative articles and introductory, intermediate, and advanced tutorials on how to develop Web services applications.
-
"Service-Oriented Architecture and Web Services: Concepts, Technologies, and Tools" at the Sun Developer Network describes some tools and technologies for Web services and SOA.
Deepal Jayasinghe, an Apache PMC member and Apache committer, is currently architecting and developing Apache Axis2 and Apache synapse. He has been a core architect and core developer of the Apache Axis2 project since its inception. His expertise is in distributed computing, fault tolerance systems, and Web services-related technologies.
Comments (Undergoing maintenance)
Table of contents
Next steps from IBM
Rational Tester for SOA Quality is an automated web services testing and SOA testing tool that supports Web services SOAP, HTTP(S), JMS, WS-Security, UDDI, and RESTful standards.
- Try: The no-charge Rational Service Tester for SOA Quality helps quality assurance professionals validate web service based SOA application..
- Article: See the whats new with Rational Service Tester for SOA Quality, and its Generic Service Client, which provides a single client to interact with any SOA service type.
- Tutorial: Get hands-on experience with this Transport for SOAP feature tutorial using Rational Tester for SOA Quality.
- Buy: Rational Service Tester for SOA Quality
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
