WEB Services and AXIS2 architecture

Web Services and AXIS2 architecture

Document Options send this page as an e-mail message

Level: Intermediate

Eran Chinthaka (chinthaka@apache.org), Senior software engineer, Lanka software Foundation

February 26, 2007 discuss the various components of Apache Axis2 and learn why it is becoming a next-generation WEB services platform with modular and extensible features.

Introduction

The launch of the Apache Axis2 1.0 in May 2006 is a major milestone. Launched in November 2006, AXIS2 1.1 offers a number of new features, most of which were originally made by its users, and a number of bug fixes that made it more stable. : From the initial Apache Axis and Apache SOAP to the current AXIS2, there has been a great development. It is not only more efficient, modular, XML-based, but also flexible and scalable, enabling enterprise functions such as security and reliability. Apache Axis2 's ease-of-use and functionality make it a next-generation WEB services platform. In this article, you will learn what features are currently implemented. You'll see a proven product that supports next-generation interoperable standards such as ws-security, Ws-reliable Messaging, and ws-addressing.

AXIS2 Architecture: Component View
Figure 1. Component View

The Axis object model (axis objects Model,axiom) is an Apache Axis2 XML object model. The kernel layer above the AXIOM contains the engine, module, and deployment Framework. There is no Java™-specific concept in the core part of Axis2. All other components are in a layer above the kernel. Various transport protocols (such as HTTP and SMTP) and data binding (converting between XML and Java code) are not in the core, because they are pluggable and therefore offer great flexibility. All other related technologies, such as Java API for XML Web Services (JAX-WS), are in the hierarchy above Axis2.

We will now analyze the following components of Axis2: AXIOM (new XML information set representation) Extensible Messaging Engine pluggable module architecture improved deployment model new client API pluggable data binding representational state transfer (representational Nsfer,rest) Support

AXIOM

The AXIs object Model (AXIOM) is an XML object model designed to improve memory usage and performance during XML processing, based on pull parsing. By using the streaming API for XML (StAX) Pull parser, AXIOM (also known as OM) can control the parsing process to provide deferred build support. Deferred build refers to the AXIOM not fully building the object model, and the rest of the model is built on the user's needs. This concept is described in the following example:

Assuming that a user needs to get the first person's <Location> element value from the XML input stream, the AXIOM built object model will always contain the content to the end of the <Location> element, leaving the other content in the stream:
Listing 1: AXIOM partial build of the object model

<Persons> <Person> <name>dihini himahansi</name> <sex>female</sex > <location>colombo, Sri lanka</location> <---Object model is being built the </Person> <Person> <name>thushari damayanthi</name> <sex>female </Sex> <location>elpitiya, Sri lanka</location> </Person> </persons >

The advantage here is to use as little memory as possible to meet the needs of the user. If a user wants to access the first few bytes or thousands of bytes in a larger document, the deferred build feature will improve the memory requirements of the application.

StAX events can be obtained from any element, regardless of whether the object model is completely built. In some cases, this feature in Axis 2 is useful. For example, when AXIS2 is passed as a mediator, if it is necessary to read only the header,axiom of the SOAP message, it will prevent it from reading the entire SOAP message, making it highly memory efficient. Another example is when the WEB service implementation is able to use the StAX event directly, because the memory required to take the Axiom,web service is very small.

In addition, the AXIOM has built-in message transfer optimization mechanism (MSG Transfer optimization mechanism,mtom) support. For the AXIOM architecture, you can execute your own object model by implementing the AXIOM interface and inserting it into AXIS2.

Since AXIOM was originally developed as an object model for AXIS2, AXIOM provides a SOAP interface built on top of the underlying AXIOM API. This allows you to view SOAP using a convenient method such as Envelope.getheaders and Envelope.getbody.

Compared to other widely used object models, AXIOM has proven to be faster and more efficient. For information on some of the performance tests performed on AXIOM, see Resources.

Back to top of page

Extensible Messaging Engine

As mentioned earlier, Axis2 is a pure SOAP processor and does not depend on any Java-specific specifications. For example, Jax-WS will be implemented as a layer on the Axis2 without going into the core section.
Figure 2. Extensible Messaging Engine

After the engine receives the message through the transport protocol, it invokes a series of interceptors (called handlers) that were previously registered. Handlers typically process information within the SOAP Header, but do not restrict the processing of other parts of the message at the same time. The message is then delivered to the recipient of the message-the final receiver of the message. The message receiver is also responsible for processing the message, and most of the time this message is passed to the service implementation class for processing.

piping model of Axis2

You can use a set of relationships to model the core message processing parts of AXIS2. Incoming messages from the AXIS2 engine pass through the "in" pipeline. All outgoing messages will pass through the "out" pipeline.
Figure 3. Piping model of Axis2

Message Exchange Mode (MSG Exchange PATTERN,MEP) Let's look at the message exchange between the client and the server. If the client needs to obtain a stock quote from the server, a request message is sent to the server and the server then sends a response message to the client. From the server's perspective, it will receive an "in" message, sending an "out" message. This is the pattern for the request-response scenario, called In-out MEP. Similarly, a client can send a IN-ONLY message to the server to make a request, such as subscribing to a mailing list. For more information about the message exchange pattern, see the Web site.

By combining different quantities of in and out pipes, AXIS2 can process any MEP. For example, you can use an in pipeline and an out pipe to support in-out interaction. You can use an in pipeline to support in-only interactions. The connections between these pipelines are made by the message recipient.

Axis2 can handle most of the MEP defined in the Web Service Description Language (Web Services Description LANGUAGE,WSDL) 2.0 specification and can be extended to support any custom MEP.

Stage

Each AXIS2 pipeline is logically divided into areas called stages (Phase). (A stage is a handler logical set in a pipeline.) These stages are named in a specific way to indicate how messages are handled at that stage. For example, the first stage in the pipeline is the transportin phase, where all handlers for the transport information processing can be located. The handler in the Dispatch phase identifies the target service and operation for this message.

These phases will be useful, especially when trying to deploy a new handler, because we can specify the stage in which the handler needs to execute.

Context Hierarchy

The AXIS2 environment requires information to be saved at different levels. For example, information that is common throughout the engine should be maintained at the system level, and message level information should be kept at the message level. Some of the information is dynamic, while some information is static. To address these different requirements, AXIS2 provides a context hierarchy to maintain information at different levels.
Figure 4. Context Hierarchy

The left side of the hierarchy contains all the dynamic information, while the right side contains static information (most of which is read from the file).

The messagecontext contains information related to the message being processed, and OperationContext contains information about the specific MEP to which this message belongs. Configurationcontext contains system-level dynamic information, while Axisconfiguration contains system-level static information (most of which are read from Axis2.xml).

Scheduling

Each message passed into the AXIS2 engine targets specific services and operations. The process of identifying this service/operation combination is called scheduling, and the Axis2 engine provides four basic ways to do this: dispatch based on request URI: Sometimes you can determine the target service of a message by looking at the request URI. For example, by requesting the URI "Http://myip/axis2/service/StockQuoteService/getQuote" You can determine that the destination of the message is StockQuoteService getquote operation. Transfer information: You can use the SOAPAction HTTP Header to determine services and operations. ws-addressing Header: If the incoming message contains a ws-addressing header, it can also be used for scheduling. This name can also be used if the QName of the first subkey of the SOAP body is defined using RPC rules.

These are some of the basic features of the AXIS2 engine. We will now understand how the module provides an extensibility mechanism for AXIS2.

Back to top of page

Pluggable Module Architecture

The module provides an extension mechanism for the server. Each module in the AXIS2 contains a set of related handlers. For example, the Ws-addressing module will contain a set of handlers that provide ws-addressing support for the AXIS2 engine. The AXIS2 administrator can download the Ws-addressing module and deploy it to the AXIS2 engine to add ws-addressing support for the AXIS2 engine. The Module.xml file contains rules that specify which pipeline and stage the handler should belong to.
Figure 5: Pluggable Module Architecture

Modules are useful because, if you need to support a WS-* specification, you can download and deploy the appropriate module without worrying about where the handler should fall into. The module has a. Mar extension, which indicates that it is a module archive (modules archive). The following are several modules that support the built-in WS-* specification: SANDESHA2 module : Provides ws-reliable Messaging support ws-addressing module: Axis2 for Ws-address ING supports Rampart and Rahas modules: provides WS-SX (security related specification) Support Kandula module : Ws-at support Savan module : provides ws-eventing support

module availability and participation

When the module is deployed to the AXIS2 engine, it is "available" and can participate in the system. Module participation can be done at the following levels, depending on the specific requirements: system level: the module will affect the entire system, and the handlers in this module will be applied to all messages passed into the system. Service level: The Handlers in this module will be applied to messages that target a specific service. These handlers should always be deployed after the dispatch phase. operation level: the Handlers in this module will be applied to messages that target specific actions. These handlers should always be deployed after the dispatch phase.

After you deploy the service, you can involve the module in the service by adding a smaller entry in the descriptor.

Back to top of page

An improved deployment model

AXIS2 now supports the deployment of service hot to the AXIS2 engine. This allows the user to deploy the service without restarting the server. The service should be archived as a ZIP file, and the. AAR (Axis2 archive, Axis2 Archive) is used as the extension in the file name. The service archive contains the following information: The Service implementation Class Services.xml file describes the message recipients that it uses, any modules that are required, and the available actions optional dependent libraries are packaged in the Lib folder

These service archive files can be copied to the Axis2 repository, which contains all the services and modules, or updated by the management console to which the Axis2 belongs.

Back to top of page

New Client API

Axis2 can invoke Web services in two ways. The ServiceClient API is the simplest approach, but less control is provided to the user. The Operationclient API provides a lot of control during the call. These two APIs have a built-in basic in-out and in-only MEP.

Axis2 now supports both the blocking and non-blocking invocation models. Non-blocking calls are useful when designing the user interface and when the service invocation is very time-consuming.

Users can now select different transport methods for different paths to the call. For example, for a in-out call, a user can handle a message using HTTP and receiving a response using the same HTTP channel (using a bidirectional channel transfer method) to send a message using HTTP, but receiving a response using a different HTTP channel (using two bidirectional channel transfer methods Send a message using SMTP and receive the response using SMTP (two different transport methods)

This feature provides maximum control for the user when selecting the appropriate transfer of the interaction.

Back to top of page

Pluggable Data binding

Working at the pure SOAP level is sometimes cumbersome, so most users prefer to use Java code and have the framework handle transformations between XML and Java code. This is called data binding. There are many data binding frameworks available, and users will prefer to use a framework for a variety of different reasons. AXIS2 supports most of the data-binding frameworks currently available, without any limitations. For example, AXIS2 has built-in support for XMLBeans, JAXB, and JiBX, and users can choose to use either of them. Any other data binding framework can be easily inserted.

AXIS2 also provides its own simple data binding framework, known as the Axis2 (ADB). This allows the user to download the AXIS2 and use it without much consideration of the data binding framework. Because of the tight integration between ADB and AXIS2 internal elements, it is foreseeable that the performance of this framework and the maintenance of generated code will be more advantageous than other frameworks. The ADB has been extensively tested in the recent WS-interoperability workshop (see Resources).

Back to top of page

REST Support

With the introduction of WEB 2.0, representational state transfer (REpresentational STate Transfer,rest) has been recognized. For some time, the REST camp and the SOAP camp have been hotly debated on which specification to use. We tried to support both in Axis2, using the work of combining REST with Web services in WSDL 2.0.

In Axis2, users can invoke all WEB services deployed in the AXIS2 engine with REST, but are constrained by the constraints defined in the WSDL 2.0 HTTP Bindings specification.

Back to top of page

Other notable improvements in Axis2 WSDL 2.0 support: AXIS2 now supports WSDL 2.0. We successfully conducted initial interoperability testing in our recent interoperability workshops. Tool Support: complex operations always require tools to simplify work. The Axis2 comes with the Wsdl2java and JAVA2WSDL tools, while providing an Eclipse plugin that works with Axis2. By deploying the management console in a Web container, you can more easily manage the AXIS2 engine remotely. various transport protocols support: AXIS2 supports HTTP, SMTP, TCP, and JMS. Spring Support: Axis2 has built-in Spring service support. You can write Spring beans and then conveniently use AXIS2 to expose them as WEB services. Ws-policy Integration: Axis2 fully supports Ws-policy, which is integrated into the core of the engine.

Reference Learning
You can refer to the original English text on the DeveloperWorks global site in this article.

The Axis2 community provides users and developers with the support they need via mailing lists. For more information, please visit Apache Web Services Project.

Learn about WSDL 2.0 interoperability activities.

Learn about the latest news about DeveloperWorks technology events and webcasts.

The IBM SOA Web site provides an overview of SOA and explains how IBM can help you achieve this goal.

For more information about SOA, please visit the DeveloperWorks SOA and WEB Services zone.

The Apache AXIS2 Project website provides information about all aspects of the project.

Please visit the Apache Axiom project website.

Please refer to the AXIOM performance test results.

The Introduction to StAX article provides an introductory introduction to the StAX API and its use.
access to products and technologies
Download Apache Axis2.


discussion
Participate in the DeveloperWorks blog to join the DeveloperWorks community.

Collaborate with the architect and developer community in the SOA and Web Services discussion forum.

About the author

		Eran Chinthaka is the architect of the Apache Axis 2 project and is a software engineer for Lanka software Foundation. He has implemented visual modeling tools for Axis 2, AXIOM, ws-addressing, SOAP 1.1 and 1.2, and BPEL4WS. In addition, he has worked as an architect for WEB services, business process automation, mobile development, and telecom network management projects.