Date: 2005-02-14T23:50:38
Editor: SrinathPerera
Wiki: Apache Web Services Wiki
Page: FrontPage/Architecture/Engine
URL: http://wiki.apache.org/ws/FrontPage/Architecture/Engine
no comment
Change Log:
------------------------------------------------------------------------------
@@ -22,72 +22,55 @@
1. Providers and transport senders.
1. Sync and Async Message flows.
-== Handler frame work and Message Invocation ==
-Handler framework consists of Handler ,Phases and the ExecutionChain
+== 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.
-=== Handler Interface ===
+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�.
-{{{
-package org.apache.axis.handler;
-public interface Handler {
- public void init();
- public void destroy();
- public void invoke()throws Exception;
- public void revoke()throws Exception;
- //plus other methods that were there already
-}
-
-}}}
+=== 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.
-== Engine Registry (Engine Configuration) ==
- Engine registry is the runtime registry of the current state of the Axis
engine. It contains the real objects like Handlers ..ect.
- By changing them on the runtime the user can change the engine
configuration. The deployment provides the implementation of this interface.
-
- When the engine initializes the Engine Registry will be loaded with values
given in the configurations.
- The engine registry will create an object structure as given below.
-
- http://ws.apache.org/~hemapani/images/er.png
+=== Transport Senders/Recivers ===
+The �Transport senders� and �Transport Receivers� handle the sending and
receiving of a SOAP message via specific transport.
-The Object Model consists of Handlers,
- TypeMapping, Flow (collection of Handlers), Module (Collection of TypeMapping
and Handlers). The common executers aggregate the above components. To build up
the Object model XXIncludes are used. XXInclude provide the methods to
access/edit a collection of XX objects. It is true since java does not support
the multiple inheritances we can not implement this object model by just
extending. But that will be leads to better design since this Object Model can
be implements using delegation. (Keeping an instance inside rather that
extending).
+=== Senders/Recivers ===
+The �Senders� and �Receivers� control the Message Exchange patterns and
Synchronous and Asynchronous behavior.
-
- The specialty in the created object structure is that it doesn�t simply hold
information about CommonExecutors, but it will hold the executable
CommonExecutors it self as well. For example, you have ability to directly
call the receive() or send() methods of the Service components , which are in
the EngineRegistry object structure.
+=== 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...).
-There might be common methods and variables for the entities given in the
above object structure. For example, each and every one of them will hold a
HashMap to keep its own parameters, and we can make the HashMap access methods
common for all the entities.
+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.
-There for its prudent to extend each and every entity of the above diagram,
from a common entity. This common entity will be termed as �RegistryElement�.
+== Execution, Implementation ==
-http://ws.apache.org/~hemapani/images/er_elment.gif
+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 ===
-== Phased Chains (ref=deployment for the DD info) ==
-TODO
-
-== Sync and Async Message flows ==
-
-sync and the Async Message flow can be implemented on top of the send(),
receive() methods.
+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.
{{{
-package org.apache.axis.engine;
-import org.apache.axis.AxisFault;
-public class AxisEngine {
- public void send(MessageContext context)throws AxisFault{
- //call the Transport -> Globel -> Service -> Operation
- //and call the the TransportSender
- }
- public void receive(MessageContext context)throws AxisFault{
- //call the Transport -> Globel -> Service -> Operation
- //and call the Provider/ what ever do the Deserialization
- //and the rest
- }
-}
+<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.
-== Phased Handler resolver ==
-== Management/Admin API ==
-== Providers and transport senders ==
+== 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.
