Using axis2 for SOA development: Understanding axis2 Basics

Apache axis2 is a successor to the Apache axis soap project. This project is an important improvement of the core web service engine. It aims to become the next-generation platform for web services and service-oriented Architecture (SOA. As a clean and scalable open-source Web service platform, it is gaining more and more attention. The architecture of axis2 is highly flexible and supports many additional features, such as reliable message transmission and security.

　　Introduction

Web services have a long history and have undergone many iterations during their development. The first generation of web services is highly controlled interaction and can be considered as only a test of feasibility. Apache SOAP is one of the noteworthy soap engines in the first generation. It is mainly used for "conceptual Verification" 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 was rewarded. More and more companies are beginning to become interested in this, and the concept of SOA is gradually becoming more and more popular. This stage can be called the Second Generation Web Service, which requires a better and faster SOAP engine. The discovery and definition aspects have been standardized, and the SOAP engine is required to support these standards. Axis is one of these second-generation soap engines.

Now, the era of the second generation of Web Services is coming to an end. Currently, Web services have very high requirements, and there are also a large number of participants in the Web service field. Content related to different aspects used to control web service interaction has been standardized. Third-generation Web services require faster and more reliable soap engines-the existing axis is no longer enough to meet this requirement. The emergence of axis2 fills this gap.

　　Axis2 Architecture

Axis2 has a modular architecture consisting of core modules and non-core modules. Axis2 is said to be a pure soap processing engine and does not contain the Java API for XML-based RPC (JAX-RPC) concept as part of its core. At the same time, the design of the axis2 architecture fully considers the following principles:

• The logic and status are separated to provide a stateless processing mechanism, because Web services are stateless.
• All information is stored in an information model and can be suspended or restored.
• The ability to scale features without changing the core architecture and support new web service specifications with minimal or no core changes.

The core architecture of axis2 includes the following core and non-core components:

• Core Components
  • XML Object Model (axiom)
  • Soap processing model: Processing Program Framework
  • Information Processing Model: context and description
• Other components
  • Deployment model
  • Transmission
  • Client API
  • Core generation model

You can see these components in Figure 1.

Figure 1. Architecture diagram of axis2

　　Axis2 Main Features

Axis2 is not only the new web service framework of Apache. It also demonstrates the experience gained from the axis 1.x series and the development in the Web service field in the last two years. One of the main reasons for introducing axis2 is to get better performance in terms of speed and memory-but some new features and features have been added. Most of the new features are designed to improve the ease of use of axis2, while retaining the space for extended functions in various ways. Most of the new functions are added to the following main areas:

• New XML Object Model (axiom)
• Message-based core
• Improved deployment model
• Insert Data Binding
• New client API
• Information Processing Model

　　New XML Object Model: Axiom

As mentioned above, axis2 is built on a brand new architecture than axis 1.x. One of the main reasons for introducing axis2 is to obtain an appropriate XML processing model. Axis 1.x uses dom as its XML representation mechanism, but the disadvantage of Dom is that the complete object hierarchy needs to be saved in the memory (corresponding to the incoming message ). This is not a problem for small messages, but it is a problem for large messages. To overcome this problem, axis2 introduces a new XML representation as its basis.

Axis2 Object Model (axis2 object model, axiom) is the basis of axis2. Any SOAP message is expressed as axiom in axis2. The advantage of Axiom over other XML forms is that it is based on the pull parser technology, while most others are based on the push parser technology. The main difference between pull and push is that in Pull Technology, callers have full control over the parser and can require the next event. For push, when the parser is required to continue processing, it will trigger the event until the end of the document is reached.

Because axiom is based on the pull parser technology, it has the "On-Demand build" function. It builds an object model only when required, you can directly access and use the basic pull parser from Axiom without building an object model (OM ).

Message-based core

The core of axis2 is the pure soap processing engine, which does not know data binding, transmission, and WSDL. The core function of axis2 is to process and deliver messages to the target application. Like axis 1.x, axis2 also has the concept of a handler that extends its main functions.

Axis 1.x does not have the concept of asynchronous web service calling. It is completely bound to request-response calling, but it is another scene in axis2. The axis2 architecture supports both client and server support asynchronous calls. At the same time, axis2 also supports request-response style calls, but this will be done in two asynchronous calls. In axis2, messages that enter the system may or may not respond. You should note that aixs2 supports all eight message exchange patterns (MEP) defined in WSDL 2.0 ).

Axis2 has the concept of stream. A stream is a collection of stages, and a stage is a collection of processing programs. The number of associated streams of the MEP called Based on the given method may change. If only the imported MEP method has only one stream, it is called inflow. For the incoming-outgoing method, there are two streams: inflow and outflow. In most cases, inflow starts from the Transport listener and ends at the message receiver, while outflow starts in different ways and ends at the transmission sender in most cases.

Figure 2. Stages in the stream

Figure 3. Inflow and Message Receiver

　　New deployment model

The previous versions of axis did not handle the user-friendly factors involved in Web Service deployment. Therefore, axis 1.xwas developed to demonstrate the concept of Web Services. Therefore, in axis 1.x, you must manually call the management client, update the server class path, and restart the server to apply the changes. This troublesome deployment model is definitely an obstacle for beginners. Axis2 has been well designed to overcome this disadvantage and provides flexible, user-friendly, and easy-to-configure deployment models.

Axis2 deployment introduces a concept similar to the Java 2 Platform Enterprise Edition (J2EE) deployment mechanism, developers can package all class files, library files, resource files, and configuration files together as archive files and place them in the specified location in the file system.

The concept of hot deployment and hot Update Is Not A New Technology term (especially for those familiar with Web service platforms), but Apache axis is a new feature. Therefore, axis2 is developed to provide space for "hot" deployment.

Hot deployment: deploy the service function when the system starts and runs. System availability is very important in real-time systems or business environments. If the system is down (even for a short period of time), the loss will be very high and may affect the service survival. However, a new service needs to be added to the system at the same time. If the service can be completed without shutting down the server, it is a great improvement. Therefore, axis2 handles this problem and provides the Web service hot deployment function to deploy new web services without shutting down the system. All you need to do is to put the necessary web service archives into the Services Directory of the repository. Then, the deployment model will automatically deploy the service and provide it.

Hot update: the ability to change existing web services without shutting down the system. This is an important feature and a function required in the testing environment. However, it is unwise to use hot updates in real-time systems because hot updates may cause the system to enter an unknown state. In addition, the existing service data of the service may be lost. To prevent this, the hot update parameter of axis2 is set to false by default.

　　Module Architecture

As mentioned above, axis2 also has the concept of a handler, but there are some changes in the way you specify and deploy the handler compared to axis 1.x. In axis 1.x, to add a handler, you must first change the global configuration file and then restart the system without changing the dynamic method of the handler chain at runtime.

To overcome this problem and add new features, axis2 introduces the concept of Web Service extension or module. The main task of the module is to expand the core functions. In axis 1.x, you can add a handler to the handler chain to achieve this goal. Compared with the axis 1.x handler chain, the advantage of using modules is that you can add new modules without changing the global configuration file. At the same time, the module is a self-container that can contain processing programs, third-party libraries, module-related resources, and module configuration files.

The module can be deployed as an archive file, and axis2 uses a new extension file name. Mar for the module. The most important file in the module archive file is the module configuration file or module. xml. This module is an error module unless it has a module. xml file. The module configuration file is mainly used to specify the handler and its stage rules. Therefore, after the module participates in the system, the handler will be placed on different streams-inflow or outflow.

This idea is very simple. You may need to support WS-Addressing or WS-Security. Then you must download the corresponding module and place it in the modules directory of the axis2 repository. You can add the following entries to the axis2.xml (axis2 global configuration file) during deployment so that the module participates in the system, you can also use various methods (such as using the axis2 web management console or handlerfor exsample) to add a module to the system during running:

　　New client API

Asynchronous or non-blocking web service calls are currently a major requirement of Web Services. At the same time, there are some methods to call Web Services in non-blocking mode. The first is the client programming model. In this model, the client can call the service in non-blocking mode without blocking its applications. The second method is transmission-level non-blocking call, where the call occurs between two transport protocols. It can be two one-way transmission protocols such as SMTP or two-way transmission protocols such as HTTP. The axis2 client API also supports the preceding two non-blocking call schemes.

Axis2 introduces a very convenient client API for calling services. This API contains two classes: serviceclient and operationclient. The serviceclient API is intended for common users who only need to send and receive XML, while the operationclient is intended for advanced users who want to process SOAP Headers and other advanced tasks. By using serviceclient, you can only access the soap subject or server load. Of course, you can add a SOAP header, but you cannot retrieve the SOAP header from the service client. To achieve this, you need to use operationclient.

Serviceclient has the following APIs for calling services:

• Sendrobust
• Fireandforget
• Sendreceive
• Sendreceivenonblocking

Sendrobust: the idea of this API is to send the XML block to the Web service without considering its response. However, if an error occurs, you also need to know the situation. Therefore, this API is used to call services that do not return values but may cause exceptions.

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

Sendreceive: Call a service with a returned value. This is one of the most commonly used APIs and can be used to call incoming-outgoing MEP.

Sendreceivenonblocking: Call the Service in non-blocking mode. This method can be used when a service has a return value. To use this method, you must pass a callback object and call the callback object immediately after the call is completed.

As mentioned above, operationclient is used for advanced users. 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 calling the service. To use operationclient to create and call a service, perform the following steps:

　　Create a service client

• Use the created service client to create an operation client.
• Create a SOAP envelope
• Create message Context
• Add a SOAP envelope to the Message Context
• Add the operation context to the operation Client
• Call operation Client
• If a response is received, the Response Message context is obtained from the Operation client.

　　Summary

Axis2 will not validate the Web service concept, but will provide a better soap processing model, compared with Axis 1.x and other existing web service engines, its speed and content performance have been greatly improved. In addition, it provides convenient APIs for users to deploy services, expand core functions, and create new client programming models. Now we have entered the axis2 era.