Axis2

AXIS2/C
Presented By:
Muktesh Mukul

Flow of Discussion…
Introduction
Features
Architecture
Module Development
Usefulness
Conclusion

Introduction:
Apache Axis2/C is a Web services engine implemented in the C programming language.
Apache Axis2/C can be used to provide and consume Web Services. It has been implemented with portability and ability to embed in mind, hence could be used as a Web services enabler in other software.
The extensible design allows it to support the full WS-* stack with the concept of modules.
Apache Axis2/C is the Web services engine that supports the most number of WS-* specification implementations in C, with guaranteed interoperability.

Features:
Support for one-way messaging (In-Only) and request response messaging (In-Out).
Client APIs: Easy to use service client API and more advanced operation client API.
Module architecture, mechanism to extend the SOAP processing model.
WS-Addressing support, both the submission (2004/08) and final (2005/08) versions, implemented as a module,
MTOM/XOP support.
XPathsupport for Axiom XML Object model.
AXIOM, an XML object model optimized for SOAP 1.1/1.2 messages; This has complete XML infosetsupport.

Transport proxy support.
REST support (more POX like) using both HTTP POST and GET .
WS-Policy implementation called Neethi/C, with WS-SecurityPolicyextension.
TCP Transport, for both client and server side .
Transports supported: HTTP Inbuilt HTTP server called simple axis server
Apache2 httpd module called mod_axis2 for server side
IIS module for server side. Supports IIS 5.1, 6 and 7
Client transport with ability to enable SSL support
Basic HTTP Authentication
AMQP Transport based on Apache Qpid (Experimental)
libcurl based client transport
CGI interface

Architecture:
The Big Picture…
Each SOAP Node may be written in specific programming language, may it be Java, C++, .NET or Perl, but the Web services allow them to interoperate. This is possible because on the wire each Web service interaction is done via SOAP, which is common to every SOAP Node.

Axis2 architecture lays out some principals to preserve the uniformity. They are as follows:
Axis2 architecture separates the logic and the states. Code that does the processing does not have a state inside Axis2. This allows code to be executed freely by parallel threads.
All the information is kept in one information model, allowing the system to be suspended and resumed.

Core Modules:
Information Model:
Axis2 defines a model to handle information and all states are kept in this model. The model consists of a hierarchy of information. The system manages the life cycle of the objects in this hierarchy.
Information Model has two main hierarchies-Contexts and Descriptions. These two hierarchies create a model that provides the ability to search for key value pairs.

XML Processing Model:
AXIOM(Axis Object Model) –
AXIOM is a lightweight, differed built XML infoset representation based on StAX API derived from JSR 173, which is the standard streaming pull parser API.
FEATURES:
Lightweight
Pull - Based

SOAP Processing Model:
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. The 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.

Axis2 Default Processing Model:
Axis2 has some inbuilt handlers that run in inbuilt phases and they create the default configuration for Axis2. We will be looking more in to how to extend the default processing Model in the next section.
There are three special handlers defined in Axis2.
Dispatchers - Finds the service and the operation the SOAP message is directed to. Dispatchers always run on the In-Pipe and inside the Dispatch phase. The in-built dispatchers dispatch to a particular operation depending on various conditions like WS-Addressing information, URI information, SOAP action information, etc. ( See more information on Dispatching)
Message Receiver - Consumes the SOAP message and hands it over to the application. The message receiver is the last handler of the in-pipe
Transport Sender - Sends the SOAP message to the SOAP endpoint the message is destined to. Always runs as the last handler in the out-pipe

Processing an Incoming SOAP Message:
An 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 from the incoming SOAP message. This message context encapsulates all the information, including the SOAP message itself, transport headers, etc., inside it. Then the In Pipe is executed with the Message Context.

Let us see what happens at each phase of the execution. This process can happen in the server or in the client.
Transport Phase - The handlers are in the phase that processes transport specific information such as validating incoming messages by looking at various transport headers, adding data into message context, etc.
Pre-Dispatch Phase- The main functionality of the handlers in this phase is to populate message context to do the dispatching. For example, processing of addressing headers of the SOAP message, if any, happens in this phase. Addressing handlers extract information and put them in to the message context.
Dispatch Phase - The Dispatchers run in this phase and try to find the correct service and operation this particular message is destined for.The post condition of the dispatch phase (any phase can contain a post condition) checks whether a service and an operation were found by the dispatchers. If not, the execution will halt and give a "service not found' error.
User Defined Phases - Users can engage their custom handlers here.
Message Validation Phase - Once the user level execution has taken place, this phase validates whether SOAP Message Processing has taken place correctly.
Message Processing Phase - The Business logic of the SOAP message is executed here. A Message Receiver is registered with each Operation. This message receiver (associated to the particular operation) will be executed as the last handler of this phase.

Processing of the Outgoing Message:
The Out Pipe is simpler because the service and the operation to dispatch are 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:
Message Initialize Phase - First phase of the Out Pipe. Serves as the placeholder for the custom handlers.
User Phases - Executes handlers in user-defined phases.
Transports Phase - Executes any transport handlers taken from the associated transport configuration. The last handler would be a transport sender which will send the SOAP message to the target endpoint.

Extending the SOAP Processing Model with Handlers:
The handlers in a module can specify the phase they need to be placed in. Furthermore, they can specify their location inside a phase by providing phase rules. Phase rules will place a handler,
as the first handler in a phase,
as the last handler in a phase,
before a given handler,
or after a given handler.

Extending the SOAP Processing Model with 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 includes:
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, 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.

Deployment Model:
The Deployment Model provides a concrete mechanism to configure Axis2. This model has three entities that provide the configuration.
The axis2.xml file
Service Archive
Module Archive

Client API
There are three parameters that decide the nature of the Web service interaction.
Message Exchange Pattern (MEP)
The behavior of the transport, whether it's One-Way or Two-Way
Synchronous/ Asynchronous behavior of the Client API.

Message Exchange pattern(MEP)
The two supported MEPs are One-Way and the In-Out (Request-Response) scenarios in the Client API.
One Way Messaging Support:
The One-Way support is provided by the fireAndForget method of ServiceClient. For one way invocations, one can use 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.
In-Out (Request Response) Messaging Support:
The In-Out support is provided by the sendReceive() method in ServiceClient. This provides a simpler interface for the user. The Client API has four ways to configure a given message exchange.
Blocking or Non-Blocking nature
Sender transport
Listener transport
Use Separate Channel

Transports
Axis2 has two basic constructs for transports, namely: Transport Senders and Transport Receivers.
Axis2 presently supports the following transports:
HTTP - In HTTP transport, the transport listener is a servlet or org.apache.axis2.transport.http.SimpleHTTPServer provided by Axis2. The transport sender uses commons-httpclient to connect and send the SOAP message.
TCP - This is the simplest transport, but needs the WS - Addressing support to be functional.
SMTP - This works off a single email account. Transport receiver is a thread that checks for emails in fixed time intervals.
JMS

Code Generation:

Data Binding:

The following databinding extensions are available:
ADB - ADB (Axis Data Binding ) is a simple framework that allows simple schemas to be compiled. It is lightweight and simple, works off StAX and fairly performant. However, it does not support the complete set of schema constructs and is likely to complain for certain schemas!
XMLBeans - XMLbeans claims that it supports the complete schema specification, and it is preferred if full schema support is needed!
JAX-Me - JaxMe support has been added in a similar manner to XMLbeans and serves as another option for the user
JibX - This is the most recent addition to the family of databinding extensions, and it is also another option the users have for data binding.

Axis2

by Muktesh Mukul

Accessibility

Categories

Upload Details

Usage Rights

Statistics

Axis2 Presentation Transcript