Axis2 architecture: The component view
Figure 1. The component view
AXIs Object Model (AXIOM) is the XML object model for Apache Axis2. The kernel layer on top of Axiom consists of the engine, the module, and the deployment frameworks. There are no Java™-specific concepts inside the core parts of Axis2. All other components are layered on top of the kernel. The various transports (for example, HTTP and SMTP) and data binding (converting XML to and from Java code) are not in the core and because they are pluggable, they provide a lot of flexibility. All other relevant technologies, such as Java API for XML Web Services (JAX-WS), are layered on top of Axis2.
We'll now examine the following components of Axis2:
- AXIOM (the new XML Infoset representation)
- Extensible messaging engine
- Pluggable module architecture
- Improved deployment model
- New client API
- Pluggable data binding
- Representational State Transfer (REST) support
AXIs Object Model (AXIOM) is an XML object model designed to improve both memory use and performance during XML processing and is based on pull parsing. By using the Streaming API for XML (StAX) pull parser, AXIOM (also referred to as OM) can control the parsing process to provide deferred building support. Deferred building is the ability of AXIOM to partially build the object model while the rest of the model is built based the user's needs. The following example illustrates the concept:
Suppose a user needs to get the value of
<Location> element of the first person from an XML input stream, AXIOM builds the object model up to the end of <Location> element and leaves the rest in the stream:Listing 1. AXIOM partial build of object model
<Persons>
<Person>
<Name>Dihini Himahansi</Name>
<Sex>Female</Sex>
<Location>Colombo, Sri Lanka</Location>
<--- Object model is being built only up to this point
</Person>
<Person>
<Name>Thushari Damayanthi</Name>
<Sex>Female</Sex>
<Location>Elpitiya, Sri Lanka</Location>
</Person>
</Persons>
|
The advantage here is that the memory is used only to satisfy user needs as much as possible. If a user wants to access first couple of bytes or kilo bytes in a larger document, then the deferred building capability will enhance the memory requirement of that application.
You can get StAX events from any element, regardless of whether the object model is fully built or not. There are some cases in which this feature becomes handy inside Axis2. For example, when Axis2 is mediating messages, and if it needs to read only the headers of the SOAP messages, AXIOM prevents it from reading the whole SOAP message, making it highly memory efficient. Another example would be when a web service implementation can consume StAX events directly, because of AXIOM, the memory requirements are very low for that web service.
In addition, AXIOM has built-in support for Message Transfer Optimization Mechanism (MTOM). With the AXIOM architecture, you can execute your own object model by implementing AXIOM interfaces and plugging them into Axis2.
Because AXIOM initially started as the object model for Axis2, AXIOM comes with SOAP interfaces built on top of base AXIOM APIs. This allows you to look at SOAP using convenience methods like
envelope.getHeaders and envelope.getBody.AXIOM has proven to be fast and efficient compared to other widely used object models. See Resources for some performance tests done with AXIOM.
Extensible messaging engine
As we mentioned earlier, the Axis2 engine is a pure SOAP processor and doesn't depend on any Java-specific specification. For example, JAX-WS will be implemented as a layer on top of Axis2 and won't leak into the core.
Figure 2. Extensible messaging engine
Once a message is received by the engine through a transport, the engine calls the preregistered set of interceptors called handlers. Handlers normally process the information inside the SOAP headers, although they have no limitations on processing other parts of the message as well. The message is then handed to a message receiver -- the ultimate recipient of the message. The message receiver also is responsible for dealing with the message accordingly, and most of the time will hand this message to a service implementation class for processing.
Piping model of Axis2
Axis2's core message processing parts can be modeled using a set of pipes. An incoming message to the Axis2 engine goes through the "in" pipe. All outgoing messages go through the "out" pipe.
Figure 3. Piping model of Axis2
The combination of the variable number of in and out pipes enables Axis2 to handle any MEP. For example, one in pipe and one out pipe can be used to enable an in-out interaction. One in pipe can be used to enable in-only interaction. The connecting of these pipes is done by the message receiver.
Axis2 can handle most MEPs defined in the Web Services Description Language (WSDL) 2.0 specification and can be extended to support any custom MEP.
Phases
The inside of every Axis2 pipe is divided logically into areas called phases. (Phases are a logical set of handlers in a pipe.) These phases are named to represent what happens to a message during that phase. For example, the first phase of the in pipe is the
TransportIn phase and all of the handlers which does transport information processing can be there. Handlers in the Dispatch phase will identify to which service and operation this message is destined. These phases come in handy, especially when trying to deploy new handlers, since we can specify in which phase the handler needs to be executed.
Context hierarchy
The Axis2 environment needs to keep information in different levels. For example, information that is common to the whole engine should be maintained at the system level, while the message-level information should be kept at the message level. Some information is dynamic and some is static. To address those various requirements, Axis2 has a context hierarchy to maintain information at different levels.
Figure 4. Context hierarchy
The left-hand side of the hierarchy contains all the dynamic information, while the right-hand side of the hierarchy contains static information that is mostly read from files.
MessageContext contains information relevant to the message that is being processed, and OperationContext has the information relevant to the particular MEP this message belongs to. ConfigurationContext contains system-wide dynamic information, while AxisConfiguration contains system-wide static information mostly read from axis2.xml.Dispatching
Every message that comes into the Axis2 engine is destined for a particular service and operation. Identifying this service/operation combination is called dispatching, and the Axis2 engine provides four basic ways to do that:
- Dispatching based on request URI: Sometimes you can identify the service the message is destined for by looking at the request URI. For example, the request URI "http://myip/axis2/service/StockQuoteService/getQuote" can be used to identify that the message is destined for the
getQuoteoperation ofStockQuoteService. - Transport information: The
SOAPActionHTTP header can be used to determine the service and operation. - WS-Addressing headers: If the incoming message contains WS-Addressing headers, they also can be used for dispatching.
- The QName of the first child of the SOAP body also can be used if the name was defined using RPC rules.
Pluggable module architecture
Modules provide an extension mechanism to the server. Each module in Axis2 contains a set of related handlers. For example, a WS-Addressing module will contain a set of handlers for WS-Addressing support for the Axis2 engine. An Axis2 administrator can add WS-Addressing support to an Axis2 engine by downloading a WS-Addressing module and deploying it in the Axis2 engine. The module.xml file contains rules to designate which pipe and phase the handlers should go in.
Figure 5. Pluggable module architecture
The module is useful because if you need support for a WS-*, the proper module can be downloaded and deployed without worrying about where the handlers should go. Modules have the .mar extension to denote module archive. Following are several modules supporting WS-* specifications that have already been built:
- Sandesha2 module: Provides WS-Reliable Messaging support
- WS-Addressing module: Provides WS-Addressing support for Axis2
- Rampart and Rahas modules: Provide WS-SX (security-related specifications) support
- Kandula module: Provides WS-AT support
- Savan module: Provides WS-Eventing support
Once a module is deployed in the Axis2 engine, it is "available" and can be engaged. Engagement of a module can be done at the following levels, depending on the requirement:
- System level: The module will affect the entire system and the handlers in this module will work on all messages that come into the system.
- Service level: Handlers in this module will work on messages that are destined for a particular service. These handlers should always be deployed after the dispatch phase.
- Operation level: Handlers in this module will work on messages that are destined for a particular operation. These handlers should always be deployed after the dispatch phase.
Improved deployment model
Axis2 now supports hot deployment of services into the Axis2 engine. This enables users to deploy services without restarting the server. Services should be archived ZIP files with a .aar (Axis2 archive) extension in the file name. Service archives contain the following:
- Service implementation class
- Services.xml file, which describes the message receiver it uses, any module that is required, and operations that are available
- Optional dependency libraries packed inside the lib folder
New client API
Axis2 can invoke a web service in two ways. The
ServiceClient API is the easiest to use but gives the user less control. The OperationClient API provides a great deal of control during an invocation. Both APIs have built-in support for basic in-out and in-only MEPs.Axis2 now supports both blocking and nonblocking invocation models. Nonblocking invocations are useful in designing user interfaces and when service invocations take a lot of time.
Users can now select different transports for different paths of the invocation. For example, with an in-out invocation, the user can do the following:
- Send a message using HTTP and receive the response using the same HTTP channel (use of one dual-channel transport)
- Send a message using HTTP and receive the response using a different HTTP channel (two dual-channel transports)
- Send a message using SMTP and receive the response using SMTP (two different transports)
No comments:
Post a Comment