Axis 2 Engine Wiki

Requirements

Wish List

Sub components

  1. Handler frame work and Message Invocation .
  2. Engine Registry (Engine Configuration).
  3. Phased Handler resolver .
  4. Management/Admin API.
  5. Providers and transport senders.
  6. Sync and Async Message flows.

Execution, Concepts

The Exaction Model or the Engine in Axis terminology, addresses how the components of Apache Axis2 are executed or how control is passed from one component to another. The Axis Execution Model does not assume any specific “Message Exchange Patterns” or “synchronous, Asynchronous behavior” in its execution.

The Axis Engine is built on top of two flows, they are called in-flow and out-flow respectively (in addition to that there is a flow called fault flow which is used when the engine gets processing errors). Each flow encompasses a set of components, namely “Handlers”, “Transport Senders”, “Transport Receivers”, “Receivers”, “Senders” and “Providers”.

Handlers

The “Handlers” are the extension mechanism for Axis and represents an “atomic unit of execution logic” which can be configured with the deployment. Each handler is executed in the order specified by the configuration at the time of deployment.

Transport Senders/Recivers

The “Transport senders” and “Transport Receivers” handle the sending and receiving of a SOAP message via specific transport.

Senders/Recivers

The “Senders” and “Receivers” control the Message Exchange patterns and Synchronous and Asynchronous behavior.

Provider

The “Provider” takes care of the real “java implementation” invocation of the Web Service (this does not refer to the java object, but refers to the implementation of the web service in the form of java, that can be a java class, XSLT engine ETC...).

The Axis2 Execution Model is not aware of the Message Exchange patterns or the Synchronous or Asynchronous Behavior. All it does is to construct an inflow or out flow or both, by picking the right components using WSDL or Deployment information and executing them.

Execution, Implementation

Implmentation of the above logical flow is achieved using a architecture that consists of “Handlers”, “Pahses” and ExecutionChain.

Phases

The Phases are Mechanism to specify the order of the handlers without knowing the *absolute position* of each handler in the HandlerChain. The Phase is a defined area (place holder for the handlers) in the Execution Chain. For an example say the handler Developer wants (RM), the Handler to run after the "Encryption” and before the "Transaction". But as the Handler is A can be used in different Web Services the developer do not know the absolute position the Handler at the Execution Chain. Phases will handle this by following declaration. <handler name="A" ..... before="Transaction" after="Encryption" ../> Then the Axis will make sure the rules are met, but please note the support for the before and after is not implemented in M1. As far as the implementation is concerned a Pahse is a ordered collection of Handlers that are arranged according to the Phase rules. This can be viewed as a “improved” HandlerChain from Axis 1.x.

Module

Module is a logical collection of Handlers that act together but expected to have little bit more than being just “Package”. One such possibility is WSDL “Code Generation” extensions. For an example the users would like to have ability to have Service refance a module and have it enabled as the j2ee does.

<service name="foo">
<module ref="Authentication"/>
</service>

Then the service foo has the authentication enabled, but those things are not in the lines of M1 relsase.

Engine Registry

The Engine registry is the runtime registry of the current state of the Axis engine. It contains the real objects like Handlers etc. By changing them at runtime the user can change the engine configuration. The deployment provides the implementation of Engine Registry out of the Deployment Discrypters and keep the Engine Registry in sync with the Deployment configuration repository. In this way the Engine does not aware about the deployment mechanisum and all the Engine knows in that there is a Engine Regsitry that is maintianed. Deafult Engine Registry implementation is synchronized , and this is necessary for the support the hot deployment. It is possible to have not synchronized Engine give that the hot deployment feature is not disabled.

Context

The Axis2 has three Contexts, Global context, Session Contexts and the MessageContext and they are the placeholders for the information in the Axis2. They follow the mediator pattern and all the components interact and share the information with each other though the three contexts. The contexts enable the Axis to be build on loosely coupled Components.

Most components of the Axis2 are stateless across the two invocations of the component. (The Engine Registry is part of the Global Context.) . The developer should store all states in the in one of the context and the All the context are accessible across the Message context which would be pass through the Handlers in the Execution Chain.

FrontPage/Architecture/Engine (last edited 2009-09-20 22:48:38 by localhost)