Using Axis2 for SOA development, part 1th: Understanding AXIS2 Fundamentals

using Axis2 for SOA development, part 1th: Understanding Axis2 Fundamentals Next Generation SOAP processing framework

Document Options send this page as an e-mail message

Level: Intermediate

Deepal Jayasinghe (deepal@apache.org), Senior software engineer, WSO2

December 28, 2006 Apache Axis2 is a successor to the Apache Axis SOAP project. This project is an important improvement in the core engine of Web services, with the goal of becoming a next-generation platform for Web services and service-oriented architectures (service-oriented Architecture,soa). As a clean and extensible open source Web service platform, it is getting a wide range of attention. The AXIS2 architecture is highly flexible and supports many additional features, such as reliable messaging and security.

Introduction

WEB services have a very long history and have undergone multiple iterations during their development. The first generation of WEB services is highly controlled interaction and can be considered only a test of feasibility. Apache soap is one of the notable soap engines of the first generation and is primarily used as a "proof of concept" without considering performance at all. The whole purpose of the first generation SOAP engine is to make people realize that WEB services are an ideal option.

Soon, the first generation of the SOAP engine paid off. More and more companies are starting to get interested, and the concept of SOA is forming. This phase can be called a second-generation WEB service, which requires a better and faster SOAP engine. Areas such as discovery and definition have been standardized and require a SOAP engine to support these standards. Axis is one of these second-generation SOAP engines.

Now, the era of second-generation WEB services is nearing its end. Web services are now very demanding and there are a lot of participants in the Web services domain. The content involved in controlling the different aspects of WEB service interactions has been standardized. Third-generation WEB services require a faster, more reliable SOAP engine-the existing Axis is not enough to meet this requirement. Axis2 came into being and filled this void.

Back to top of page

AXIS2 Architecture

The AXIS2 has a modular architecture consisting of core modules and non-core modules. It is said that the AXIS2 core is a pure SOAP processing engine and does not contain the JAVA™API for xml-based RPC (JAX-RPCs) concept as part of its core. At the same time, the AXIS2 architecture is designed with the following principles in mind: logic and state separation to provide a stateless processing mechanism, because WEB services are stateless. All information is located in an information model that allows the system to be suspended and resumed. Ability to extend functionality without changing the core architecture to directly support new WEB service specifications with minimal or no core changes.

AXIS2 Core architecture includes the following core and non-core components: Core component XML Object Model (AXIOM) SOAP processing Model: Handler framework Information Processing Model: Context and description Other components deployment model transfer Client API core build model

You can see these components in Figure 1.
Figure 1. AXIS2 Architecture Diagram

Back to top of page

Axis2 Main Features

Axis2 is not just a new WEB services framework for Apache. It also embodies the experience gained from the Axis 1.x series and the recent two years of development in the field of Web services. One of the main reasons for introducing Axis2 is to get better performance from both speed and memory--but also to add some new features and functionality. Most of the new features are designed to improve the ease of use of Axis2, while preserving the space to extend functionality in a variety of ways. The main areas where most of the new features are added are as follows: New XML object Model (AXIOM) messaging-based core improved deployment model pluggable data binding new client API information processing model

Back to top of page

New XML object Model: AXIOM

As mentioned above, Axis2 is built on a completely new architecture compared to Axis 1.x. One of the main reasons for introducing AXIS2 is to obtain the appropriate XML processing model. Axis 1.x uses the DOM as its XML representation mechanism, but the disadvantage of using the DOM is that it needs to hold the complete object hierarchy in memory (corresponding to the incoming message). For small messages, this will not be a problem, but for large messages it is a problem. To overcome this problem, Axis2 introduces a new XML representation as its base.

The Axis2 object model (AXIS2 objects Model,axiom) is the basis of AXIS2, and any SOAP message is represented as Axis2 in AXIOM. The advantage of AXIOM with respect to other XML representations is that it is based on pull parser technology, while most others are based on the push parser technology. The main difference between pull and push is that the caller has full control of the parser in the pulling technique and can request the next event, and for push, it triggers the event until the end of the document is reached when the parser continues to process.

Because AXIOM is based on the pull parser technology, it has an on demand build feature that builds the object model only when required, and, if needed, accesses and uses the underlying pull parser directly from the AXIOM without building the object model, OM).

Back to top of page

The core of message-based delivery

The Axis2 core is a pure SOAP processing engine that does not understand data binding, transport, WSDl, and so on. The primary function of the AXIS2 core is to process the transmission of messages and deliver them to the target application. Like Axis 1.x, Axis2 also has a handler concept for extending its primary functionality.

Stage and stage rules A stage is a logical collection of one or more handlers, and sometimes the stage itself acts as a handler. Axis2 introduces a phase concept to facilitate the expansion of core functions. In Axis 1.x, if you want to add handlers to the handler chain, you need to change the global configuration file, but for Axis2, you do not need to do this because the stage and stage rules resolve the issue. A stage rule is used to specify how a given handler assembly is ordered within a stage. Figure 2 illustrates how the phase makes up the flow.

Axis 1.x does not have the concept of an asynchronous Web service invocation, it is fully bound to a request-response invocation, but in Axis2 it is a different picture. The AXIS2 architecture enables asynchronous calls to be supported both on the client and the server side. Also, AXIS2 supports request-response style calls, but this is done in two asynchronous invocations. In Axis2, messages entering the system may or may not be responding, and it should be noted that AIXS2 supports all eight message exchange patterns defined in WSDL 2.0 (Messages Exchange PATTERNS,MEP).

Axis2 has the concept of a flow, which is a collection of stages, and a stage is a collection of handlers. The number of streams associated with the MEP that is called by a given method may vary. If only the incoming MEP correspondence method has only one stream, it is called inflow, and for incoming-outgoing, there are two streams--inflow and outflow. In most cases, inflow begins with the transport listener, ends at the message receiver, and outflow can start in a different way, and in most cases ends at the transmitting sender.

Message Receiving Party If the message passes through the chain without a problem, the engine forwards the message to the message receiver for the business logic call, after which the service is invoked by the message receiver and the response is sent if necessary. Figure 3 illustrates how the message receiver fits the execution chain.

Figure 2: Stages in a stream


Figure 3. Inflow and message Receivers

Back to top of page

New deployment model

The previous version of Axis did not handle the user-friendliness involved in the deployment of the Web service, so the Axis 1.x was developed for the purpose of proving the concept of Web services. Therefore, in Axis 1.x, the user must manually invoke the management client, update the server classpath, and then restart the server to apply the changes. This somewhat cumbersome deployment model is certainly an obstacle for novices. Axis2 is designed to overcome this shortcoming and provides a flexible, user-friendly, and easy-to-configure deployment model.

AXIS2 deployment introduces a concept similar to the java™2 Platform Enterprise Edition (EE) deployment mechanism where developers can package all class files, library files, resource files, and configuration files together as archive files. and place it at the specified location in the file system.

The concept of hot deployment and hot update is not a new technology term (especially for people familiar with the Web services platform), but for Apache Axis is a feature. Therefore, AXIS2 has been developed to provide space for "hot" deployment.

Hot deployment: The ability to deploy services when the system is up and running. System availability is important in real-time systems or business environments. If the system is down (even for a short time), the loss can be significant and may affect the lifetime of the business. However, adding a new service to the system at the same time would be a significant improvement if it could be done without shutting down the server. As a result, AXIS2 has addressed this issue, providing a Web service hot deployment feature that allows you to deploy a new Web service without shutting down the system. What you need to do is put the required Web service archive into the repository's services directory. The deployment model will then automatically deploy the service and provide it.

Hot UPDATE: the ability to make changes to an existing WEB service without shutting down the system. This is an important feature that is required in a test environment. However, it is not advisable to use hot updates in real-time systems because hot updates can cause the system to enter an unknown state. In addition, you may lose existing service data for the service. To prevent this from happening, the AXIS2 hot update parameter is set to False by default.

Back to top of page

Module architecture

As mentioned above, Axis2 also has a concept of handlers, but there are some changes in the way you specify and deploy handlers compared to Axis 1.x. In Axis 1.x, to add handlers, you need to change the global configuration file first, then you need to restart the system, and there is no dynamic way to change the handler chain at run time.

To overcome this problem and add new features, AXIS2 introduces the concept of WEB service extensions or modules, where the main work of the module is to extend the core functionality. In Axis 1.x, this goal can be achieved by adding handlers to the handler chain. The advantage of using modules over the Axis 1.x handler chain is that you can add new modules without changing the global configuration file at all. At the same time, the module is a self-contained container, which can contain handlers, third-party libraries, module-related resources, and module configuration files.

Status of the module The module has two states: available and engaged. When a module is placed in a repository, the module is in the available state, and its handlers are not in the handler chain. The module can participate in the system at any time. Participation is the addition of its handlers to the handler chain (or stream), so that once the module participates in the system, it is in the engaged state.

You can deploy the module as an archive file, Axis2 the module with a new extension file name. Mar. The most important file in the module archive file is the module configuration file or Module.xml. The module is an error module unless it has a module.xml file. The module configuration file is primarily used to specify handlers and their stage rules, so that after the module participates in the system, the handlers are placed on different streams--inflow or outflow, depending on the stage rules.

This idea is very simple. Perhaps you need to support ws-addressing or ws-security. You must then download the corresponding module and place it in the modules directory of the AXIS2 repository. You can participate in the system at deployment time by adding the following entry to the Axis2.xml (Axis2 global Profile), or by using various methods at run time (such as using the AXIS2 WEB Management Console or handlerfor exsample) to involve the module in the system: < Module ref= "ModuleName" >

Back to top of page

New Client API

Asynchronous or non-blocking Web service invocation is a major requirement in the current Web service. At the same time, there are several ways to invoke WEB services in a non-blocking manner. The first is the client programming model, in which the client can invoke the service in a non-blocking manner without blocking its application. The second method is a transport-level nonblocking call, where the call occurs between two transport protocols. It can be a two-way transport protocol such as SMTP, or a two-way transport protocol such as two HTTP. The AXIS2 client API supports both of the two non-blocking invocation scenarios described above.

Axis2 introduces a very handy client API for invoking the service, which contains two classes, named serviceclient and operationclient, respectively. The ServiceClient API is designed for ordinary users who only need to send and receive XML, while Operationclient is intended for advanced users wishing to handle SOAP headers and other advanced tasks. By using ServiceClient, you can only access the SOAP principal or payload. Of course, the SOAP header can be added, but the SOAP header cannot be retrieved from the service client. In order to do this, you will need to use operationclient.

The serviceclient has the following api:sendrobust Fireandforget sendreceive sendreceivenonblocking for invoking the service

Sendrobust: The idea of this API is to send an XML block to a WEB service regardless of its response. However, if an error occurs, you will also need to know the situation. Therefore, this API is used to invoke a service that does not return a value but may throw an exception.

Fireandforget: This API is used only to send XML blocks, but does not consider responses or exceptions, so this is called only the incoming MEP.

SendReceive: Invokes a service with a return value. This is one of the most common APIs that can be used to invoke an incoming-outgoing MEP.

Sendreceivenonblocking: Calls the service in a non-blocking manner. This method can be used when the service has a return value. In order to use this method, you must pass a callback object that invokes the callback object immediately after the call completes.

As mentioned earlier, Operationclient is for advanced users, and using operationclient requires you to have a good understanding of AXIS2. In ServiceClient, you do not need to know any information about the SOAP envelope or message context, but for operationclient, you must create it yourself before invoking the service. Using Operationclient to create and invoke a service involves the following steps: Creating a service client and then creating a SOAP envelope using the created service client creates a message context adds a SOAP envelope to the message context adds the action context to the operation client call operation client Gets the response message context from the action client if there is a response

Back to top of page

Summarize

Axis2 will not validate the concept of WEB services, but will provide a better SOAP processing model, and its speed and content performance can be significantly improved compared to Axis 1.x and other existing Web service engines. In addition, it provides users with a convenient API for deploying services, extending core functionality, and new client programming models. Now it has entered the Axis2 era.

Resources for information about XML pull parsing.

Read "Promoting XML processing with AXIOM" (developerworks,2005 October) for an overview of using this method for XML processing.

Visit the Apache software Foundation for information about Apache Axis2.

Visit the latest SOAP version.

Visit the SOA and Web Services zone on IBM DeveloperWorks to get hundreds of articles on how to develop WEB services applications, as well as entry-level, intermediate, and advanced tutorials that you will see.

The "service-oriented Architecture and Web services:concepts, Technologies, and Tools" on the Sun Developer Network describes the use of Web services and S Some of the tools and techniques of OA.

About the author

		Deepal Jayasinghe is an Apache PMC member and Apache Committer, currently engaged in Apache Axis2 and Apache Synapse Architecture design and development work. He has served as the core architect and core developer of the Apache Axis2 project from the outset. He specializes in sub-