converted to 1.6 markup
|Deletions are marked like this.||Additions are marked like this.|
|Line 3:||Line 3:|
|* [wiki:/Phase_Handlers Phase Handlers]||* [[/Phase_Handlers|Phase Handlers]]|
Axis 2 Engine Wiki
lay down the EngineRegistry (the runtime representation of the Axis configuration) interface, and provide a simple a implementation.
- Define the invocation flow of the in/out flow of the engine and provide a implementation. This include implementing the following.
- Phased Handler resolver.
- Providers and transport sender.
- Provides a Management API. - Not supported in M1
- Providing full Sync, Async support. - partially supported in M1
- Giving the engine ability to stop and restart the execution later.
- Handler frame work and Message Invocation .
- Engine Registry (Engine Configuration).
- Phased Handler resolver .
- Management/Admin API.
- Providers and transport senders.
- Sync and Async Message flows.
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.
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.
The Transport senders and Transport Receivers handle the sending and receiving of a SOAP message via specific transport.
The Senders and Receivers control the Message Exchange patterns and Synchronous and Asynchronous behavior.
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.
Implmentation of the above logical flow is achieved using a architecture that consists of Handlers, Pahses and ExecutionChain.
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 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.
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.
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.