Version 0.94
Feedback: axis-dev@ws.apache.orgAny architecture is a result of what that architecture should yield. The success of an architecture should be evaluated based on the requirements expected to be met by that architecture. Let us start our journey into Axis2 by looking at the requirements.
In the SOAP terminology, a participant who is taking part in a Web Service interaction is known as a SOAP Node. Delivery of a single SOAP Message is defined based on two participants, SOAP Sender and SOAP Receiver. Each SOAP Message is sent by SOAP Sender and received by SOAP Receiver. A single SOAP delivery is the most basic unit that builds the Web Service interaction.
Each SOAP Node may be written in specific programming language, may it be Java, C++, .NET or Perl, the Web Services allow them to inter operate. This is possible because on the wire each Web Service interaction is done via SOAP, which is common to every SOAP Node.
Web Service middleware handles the complexity in SOAP messaging and lets the users work with the programming language they are accustomed to. Axis2 allows java users to invoke Web Services using java representations, and handles the SOAP messaging behind the curtain.
Axis2 handles SOAP processing along with numerous other tasks. This makes the life of the Web Service developer a whole lot easier. Following are the identified requirements:
Ability to deploy a Web Services (with or without WSDL)
Ability to configure Axis2 and it's components via deployment.
Apart from the above functionalities, performance in terms of memory and speed is a major consideration for Axis2. Axis2 Core Architecture is built on three specifications- WSDL, SOAP and WS-Addressing. Other specifications like JAX-RP, SAAJ & WS-Policy are layered on top of the Core Architecture.
Axis2 architecture separates the logic and the states. Code that does the processing is stateless inside Axis2. This allows code to be executed freely by parallel threads.
Axis2 architecture is modular. Therefore Axis2 Framework is built up of core modules which collectively make up the core architecture of Axis2, and non-core modules that are layered on top of this core modules/architecture.
Core Modules:
XML processing Model- Handling the SOAP Message is the most important and most complex task. The efficiency of this is the single most important factor that decides the performance. It makes sense to delegate this task to a separate module allowing that module(AXIOM) to provide a simple API for SOAP and XML info-set while hiding the complexities of the efficient XML processing within the implementation.
Deployment Model- Axis2 deployment model allows the user to deploy services, configure the transports, extend the SOAP Processing model per system, service or operation basis.
Transports- Axis2 define a transport framework that enables the user to use different transports. The transports fit into specific places in the SOAP processing model. The implementation provides a few common transports and the user may write new ones if and when it is needed.
Data Binding- The basic client API of Axis2 lets the users process SOAP at the infoset level where as data binding extends it to make it more convenient to the users by encapsulating the infoset layer and providing a programming language specific interface.
Information Model has two main hierarchies-Contexts and Descriptions. This model is described in UML notations below.
( A ----<> B says, B has 1 or more objects of A. A------>B says, the given relationship holds between A and B.)
The two hierarchies are connected as shown in the above figure. The Description hierarchy represents the static data. This data may be loaded from a configuration file that exists throughout the lifetime of Axis2. For example, deployed Web Services, operations, etc. On the other hand, the context hierarchy holds more dynamic information about the things that have more than one instances (e.g.Message Context).
These two hierarchies creates a model that provides the ability to search for key value pairs. When the values are searched at a given level, they are searched while moving up the hierarchy until a match is found. In the resulting model the lower levels override the values in the upper levels. For example, when a value is looked up in the Message Context and is not found, it would be looked up in the Operation Context etc, up the hierarchy. The Search is first done up the hierarchy, and if starting point is a Context then it is search in the Description hierarchy as well.
This allows the user to declare and override values. Result being a very flexible configuration model. The flexibility could be the Achilles heel for the system as the search is expensive, specially for something that does not exist. Yet in the final analysis developers believe that the flexibility would serve better in this instant.
Configuration Context |
Holds the run time status. A deep copy of this would essentially make a copy of Axis2. |
Axis Configuration |
Holds all global configurations. Transports, global modules, parameters and Services etc. |
Service Group Context |
Holds information about a particular usage of the respective service group. The life of a Service Group Context starts when a user starts interacting with a service that belong to this service group. This can be used to share information between services (within the same service group) in a single interaction. |
AxisServiceGroup |
Holds deployment time information about a particular service group. |
Service Context |
This context is available throughout the usage of the respective service. This can be used to share information between several MEPs of the same service, within a single interaction. |
AxisService |
Hold the Operations and the service level configurations |
Operation Context |
Holds the information about the current MEP instance, maintain the Messages in the current MEP etc. |
AxisOperation |
Holds the operation level configurations |
Message Context |
Holds all the information about the Message currently being executed. |
AxisMessage |
Do not hold any information as yet, but can be used as a future extension point. |
Please refer to the OM Tutorial
The architecture identified two basic actions a SOAP processor should perform, sending and receiving SOAP messages. The architecture provides two Pipes ('Flows'), to perform these two basic actions. Axis Engine or the driver of Axis2 defines two methods send() and receive() to implement these two Pipes. The two pipes are named In Pipe and Out Pipe, and the complex Message Exchange Patterns (MEPs) are constructed by combining these two pipes.
Extensibility of the SOAP processing model is provided through handlers. When a SOAP message is being processed the handlers that are registered would be executed. The handlers can be registered in global, service, or operation scopes and the final handler chain is calculated combining the handlers from all the scopes.
The handlers act as interceptors and they process parts of the SOAP message and provide add-on services. Usually handlers work on the SOAP headers yet they may access or change the SOAP Body as well.
When a SOAP message is being sent through the Client API, an Out Pipe would begin, the Out Pipe invokes the handlers and end with a Transport Sender that sends the SOAP message to the target endpoint. The SOAP message is received by a Transport Receiver at the target endpoint, which reads the SOAP message and starts the In Pipe. The In Pipe consists of handlers and ends with the
Message Receiver, which consumes the SOAP message.Above explained processing happens for each and every SOAP message exchanged. After processing one message Axis2 may decide to create other SOAP messages, in which case more complex message patterns emerge. However Axis2 always view the SOAP message in terms of processing a single message. The combination of the messages are layered on top of that basic framework.
The two pipes does not differentiate between the Server and the Client. The SOAP Processing Model handles the complexity and provides two abstract pipes to the user. The different areas or the stages of the pipes are given names, and according to the Axis2 slang those are named 'phases'. A Handler always runs inside a phase, and the phase provides a mechanism to specify the ordering of handlers. Both Pipes have built in phases, and both define the areas for 'User Phases' which can be defined by the user.
Following figure shows the two pipes with their pre-defined phases & user-defined phases. User-defined phases fit in to the User Phases.
Axis2 has some inbuilt handlers that run in inbuilt phases and they create the default configuration for the Axis2. We will be looking more in to how to extend the default processing Model in the next section.
There are four special handlers defined in Axis2.Transport Sender - Send the SOAP message to the SOAP endpoint the message is destined to. Always runs on the
Incoming SOAP Message is always received by a Transport Receiver waiting for the SOAP Messages. Once the SOAP Message arrives the transport Headers are parsed and a
Message Context is created for the incoming SOAP Message. Then the In Pipe is executed with the Message Context.Let us see what happens at each phase of the execution. This process may happen either in the server or in the Client. There is a special case of using the Two-Way transport where the first four phases of the In-Phase most likely does nothing.
There may be other handlers in any of these phases. Users may use custom handlers to override the mechanics in each of these phases.
Out Pipe is simpler because the service and operation to dispatch is known by the time the pipe is executed. The Out Pipe may be initiated by the
Message Receiver or the Client API implementation.Phases of the Out Pipe are described below:Above we discussed the default processing model of Axis2. Now lets discuss the extension mechanism for the SOAP processing model. After all, the whole effort of making this SOAP engine/processing model was focused much on making it extendable.
Idea behind introducing step wise processing of the SOAP message in terms of handlers & phases is to allow easier modification of the processing order. The notion of phases makes it easier to place handlers in between other handlers enabling this modification on the default processing behavior. SOAP Processing Model can be extended with handler or Modules.
Axis2 defines an entity called a 'module' that can introduce handlers and web service operations. A Module in terms of Axis2 usually acts as a convenient packaging that include a set of handlers and an associated descriptor which includes the phase rules. Modules have the concept of being 'available' and 'engaged'. 'Availability' means the module is present in the system, but has not been activated, i.e., the handlers included inside the module have not been used in the processing mechanism. When a module is 'engaged' it becomes active and the handlers get placed in the proper phases. The handlers will act in the same way as explained in the previous section. Usually a module will be used to implement a WS-* functionality such as WS-Addressing.
Apart from the extension mechanism based on the handlers the WS-* specifications suggest a requirement for adding new operations. For example, once a user add a Reliable Messaging capability to a Service the "Create Sequence" operation needs to be available to the service end point. This can be implemented by letting the modules define the operations, and once the module is engaged to a service, the necessary operations will be added to that service.
A service, operations or the system may engage a module. Once the module is engaged the handlers and the operations defined in the module are added to the entity that engage them.
Modules can not be added while the Axis2 engine is running, but they will be available once the system is restarted.
The Deployment Model provides a concrete mechanism to configure Axis2. This model has three entities that provide the configuration.
This file holds the global configuration for the client and server, and provide following information:
Service archive must have a META-INF/services.xml file and may contain the dependent classes. The services.xml file has following information.
Module archive must have a META-INF/module.xml file and dependent classes. The module.xml file has Module parameters and the Operations defined in the module.
When the system is starting up Axis2 ask the deployment model to create a Axis Configuration. Deployment Model first finds the axis2.xml file and build the global configuration. Then it checks for the module archives and then for the service archives. After which the corresponding services and modules are added to the Axis Configuration. System will build Contexts on top of the Axis Configurations and then Axis2 is ready to send or receive the SOAP Message. Hot deployment is only allowed for the service, in which case a thread will check the repository repeatedly, and then add the service corresponding to the new found service archives to the repository.
There are three parameters that decide the nature of the Web Service interaction.
Variations of the three parameters can result in indefinite number of scenarios, even though Axis2 is built on a core that support any messaging interaction, the developers were compelled to support only two most widely used Message Exchange Patterns (MEPs).
Two supported transports are One-Way and the Request-Response scenarios in
the Client API. The implementation is based on a class called
ServiceClient
and there are extensions for each MEP that Axis2
Client API supports.
The One-Way support is provided by the fireAndForget
which
provide by ServiceClient
that provides a much simpler interface
for the user. The Axis2 supports HTTP/SMTP and TCP transports. In the case of
the HTTP transport the return channel is not used and the HTTP 202 OK is
returned in the return Channel.
The Request-Response support is provided by the sendReceive()
method in ServiceClient ,that provides a much simpler interface for the user.
The Client API has four ways to configure a given Message Exchange
sendReceive()
or sendReceiveNonBlocking()
methodsDepending on the values of the above four parameter, Axis2 behave differently.
Axis2 has two basic constructs for transports, transport In Configuration and transport Out Configuration. These are accessed via the messages context.
The incoming transport is the transport via which the server side receives the message and the outgoing transport is decided based on the addressing information (wsa:ReplyTo and wsa:FaultTo). If addressing information is not available then the out going transport will be the same as the incoming one.
At the client side the user is free to specify the transport to be used.
Transport In Configuration and the transport Out Configuration contains following information.
Each and every transport Out Configuration defines a transport tender. Transport sender sends the SOAP Message over its transport.
Transport receiver waits for the SOAP Messages and for each SOAP Message that arrives, it uses the In Pipe to process the SOAP Message.
Axis2 Presently support the following transports:
Although the basic objective of the code generation tool has not changed, the code generation module of Axis2 has taken a different approach to generate code. Primarily the change is in the use of templates, namely XSL templates which gives the code generator the flexibility to generate code in multiple languages.
The basic approach is to set the code generator to generate an XML and parse it with a template to generate the code file. The following figure describes how this shows up in the architecture of the tool.
The fact here is that it is the same information that is extracted from the WSDL no matter what code is generated. Code generator uses the WOM (WSDL Object Model) internally to manipulate the WSDL and passes that information to the emitter which emits an XML. The XML is then parsed with the relevant XSL to generate the code. No matter what the language, the process is the same except for the template that is being used
Axis2 M2 was released with code generation support but without data binding. The version 0.9 was shipped with data binding support with complete schema support. Such claim is made possible because of the fact that the data binding tool, xml-beans, has the full schema support. The original architecture of the code generation framework did not undergo significant changes because of the way that the code generation framework was originally designed. Data binding was incorporated as a pluggable extension to the code generation engine. Axis2 version 0.91 does not support SOAP encoding. It only supports RPC literal or document literal massages.
AXIOM is based on a StAX (Streaming API for XML) API. Xml-beans supports StAX API. Data binding in Axis2 is achieved through interfacing the AXIOM with the Xml-beans using the StAX API which is supported by both parties. At the time of the code generation there will be supporter classes for each WSDL operation that will have the utility methods that can de-serialize the from AXIOM to data bound object and serialize from data bound object to AXIOM. For example if the WSDL has an operation called "echoString", once the code is generated there will be an echoStringDatabindingSupporter.java class generated that will have methods that will look like the following.
public static
org.apache.axis2.om.OMElementtoOM(org.soapinterop.xsd.EchoStringParamDocument
param)
// This method will handle the serialization.
public static org.apache.xmlbeans.XmlObject
fromOM(org.apache.axis2.om.OMElement param, java.lang.Class type) //This
method will handle the de-serialization.
public static org.apache.xmlbeans.XmlObject
getTestObject(java.lang.Class type) /*This will be a utility method that can
be used to create sample objects of the given data bound object.*/