Developing Web services through AXIS2, part 1th: Deploying and using simple Web services through the AXIS2 runtime

This article supporting source code

Introduction

Axis2 is the next generation of Apache Axis. Although supported by the Axis 1.x handler model, AXIS2 is more flexible and scalable to the new architecture. Axis2 is newly written based on the new architecture and does not use the Axis 1.x common code. The motivation to support development Axis2 is to explore more modular, more flexible, and more efficient architectures that can easily be plugged into implementations of other relevant WEB service standards and protocols such as Ws-security, ws-reliablemessaging, and so on.

The features of AXIS2 include:

New core XML processing model named AXIOM (AXIs object Model,axis object model)

Support for in-only and In-out message exchange modes (MEP)

Blocking and Non-blocking client APIs (application programming Interface)

Support for built-in WEB service Addressing (ws-addressing)

Support for XMLBeans data binding

New deployment model

Supports transfer protocols such as Hypertext Transfer Protocol (HTTP), Simple Mail Transfer Protocol (SMTP), and Transmission Control Protocol (TCP)

This series of articles is based on the Axis2 0.92 version. You can get the latest version of Axis2 on the Apache website.

Axis Architecture Overview

Figure 1. AXIS2 Architecture

The AXIS2 architecture separates logic from state; This allows logic to be performed in parallel threads. The static state and dynamic state of the service and the invocation are stored separately in the Description and context classes. The AXIS2 architecture is implemented using 7 separate modules.

Information Model: This module manages the state of the SOAP engine. The model defines a set of classes for storing states, while the engine manages the lifecycle of these information objects. The information model contains two classes for storing states. The Description class stores data that is inherently static and exists throughout the lifecycle of an Axis engine instance (such as transport, service, and Operation configuration). The context class holds dynamic information such as the current request and response SOAP messages, from addresses, to addresses, and other elements that are valid in the invocation contexts.

XML processing Model: AXIS2 introduces a new model called AXIOM, which is used to process SOAP messages. AXIOM uses StAX (streaming API for XML) to parse XML. StAX is a standard flow-Pull parser Java™api. AXIOM is very sophisticated and does not slow down the construction of XML information sets-in other words, objects are created only when absolutely necessary. Overall, AXIOM and Axis2 occupy less memory than Axis 1.

SOAP processing Model: The AXIS2 architecture defines two pipelines (or streams), respectively called Inpipe (inflow) and outpipe (outflow), for processing server-side request messages and response messages. On the client side, the two pipes are reversed-in other words, the SOAP request messages flow through the outpipe, and the response messages flow through the inpipe. A pipe or stream contains a series of stages-separated handlers. The phases are executed in a predefined order, as shown in Figure 1 above. In addition to predefined stages and processing assemblies, users can configure user stages and related handlers at the action level, service level, or global level. The handler acts as an interceptor for the SOAP message and can handle the Header or body of the SOAP message. Inpipe is configured through the following stages:

Transportin

Predispatch

Dispatch

Postdispatch

Policydetermination

User Phases

Message validation

We will describe each of these phases in detail in part 2nd of this series of articles. The request message arrives at Messagereceiver after all the stages configured through Inpipe, and then the actual service implementation is invoked by Messagereceiver. The outpipe of the server contains the following phases:

Message initialization

Policy determination

User Phases

Messageout