Axis2 Pillars : [ flows, phases, handlers, and modules ]

Flows

Flow is the collection of phases in the Axis2 architecture. There are two flows Axis2 engine has two flows based on the message invocation patterns, 

1. In-Flow - which is invoked when the engine receives a message
2. Out-Flow - which is invoked on engine sends the message. 

These flows are not in object or structure on real implementations.  The order in which the phases should be put together to form a flow can be configured in axis2.xml configuration.

Phases

Axis2 engine invokes in the phases which they are placed in flow. 

Axis2 have predefined phases . They also configured in the configuration file axis2.xml

PREDEFINED PHASES

The Phases are deined on the <phaseOrder> element in axis2.xml

	<phaseOrder type="inflow">
	<phase name="Transport"/>
	<phase name="PreDispatch"/>
	<phase name="Dispatch"/>
	<phase name="PostDispatch"/>
	</phaseOrder>
	<phaseOrder type="outflow">
	<phase name="MessageOut"/>
	</phaseOrder>

view raw axis2.xml hosted with ❤ by GitHub

User also can add user defined pahses on axis2.xml , but it should be after the post dispatch phase. The example user defined configuration is as follows,

	<phaseOrder type="inflow">
	<phase name="Transport"/>
	<phase name="PreDispatch"/>
	<phase name="Dispatch"/>
	<phase name="PostDispatch"/>
	<phase name="userPhase1"/>
	<phase name="userPhase2"/>
	</phaseOrder>
	<phaseOrder type="outflow">
	<phase name="userPhase3"/>
	<phase name="MessageOut"/>
	<phase name="userPhase4"/>
	</phaseOrder>

view raw axis2.xml hosted with ❤ by GitHub

Phase Rules

The main idea of phase rules is to correctly locate a handler relatively to one another inside a phase.

Characterizing a phase rule can be based on one more of the following properties that will be discussed below:

• Phase name: Name of the phase that the handler must place
• Phase first (phaseFirst): The first handler of the phase
• Phase Last (phaseLast): The last handler of the phase
• Before (before): Should be positioned before a given handler
• After (after): Should be positioned after a given handler
• Before and after: Should placed between given two handlers

	<handler name="simple_Handler "
	class="org.apache.axis.handlers.SimpleHandler ">
	<order phase="userphase1" phaseFirst="true"/>
	</handler>
	<handler name="simple_Handler2 "
	class="org.apache.axis.handlers.SimpleHandler2 ">
	<order phase="userphase1" befoer=" simple_Handler "/>
	</handler>
	<handler name="simple_Handler3 "
	class="org.apache.axis.handlers.SimpleHandler3 ">
	<order phase="userphase1" after=" simple_Handler2"/>
	</handler>
	<handler name="simple_Handler4"
	class="org.apache.axis.handlers.SimpleHandler4">
	<order phase="userphase1"
	after=" simple_Handler1"
	before=" simple_Handler2"/>
	</handler>
	<!-- Validator -->
	<handler name="simple_HandlerError "
	class="org.apache.axis.handlers.SimpleHandlerError ">
	<order phase="userphase1"
	before=" simple_Handler" phaseFirst="true"/>
	</handler>

view raw phase_rules.xml hosted with ❤ by GitHub

Handlers

They are small unit invocations , when the phases is invoked. Each handlers within the phase will be invoked. 

An example for handler is :

AddressingInHandler is places in the predispatch phase in in-flow - it deals with the incoming addressing headers in request. 

AddressingOutHeader is places in the message out phase in out-flow and it prepare out going response message headers and addresses.

Module

Collection of handlers with its configurations are so called modules. Modules enable the user of Axis2 to adding new handlers and phases on their desire. 

when configuring the module user add the module to the pedefined phase of Axis2 Engine. 

First for the all handlers axis2_handler interface needs to be implemented. This means the following signature need to be implemented.

	axis2_status_t (AXIS2_CALL *
	invoke)(axis2_handler_t *handler,
	const axis2_env_t *env,
	struct axis2_msg_ctx *msg_ctx);

view raw axis2_interface_method.java hosted with ❤ by GitHub

Once the handler is implemented, the module need to implement to API calls as follows

	int axis2_get_instance(axis2_module_t **inst, const axis2_env_t *env);
	int axis2_remove_instance(axis2_module_t *inst, const axis2_env_t *env);

view raw axis2_api_cals.java hosted with ❤ by GitHub

engine looking the above implemented functions when loading and unloading the module. Once the above works are ready then they are compiled with the shared library. In order to use the module configuration file is also required. The following is the sample configuration file WS-Addressing scenario.

	<module name="addressing" class="axis2_mod_addr">
	<inflow>
	<handler name="AddressingInHandler" class="axis2_mod_addr">
	<order phase="PreDispatch"/>
	</handler>
	</inflow>
	<outflow>
	<handler name="AddressingOutHandler" class="axis2_mod_addr">
	<order phase="MessageOut"/>
	</handler>
	</outflow>
	</module>

view raw axis2_module.xml hosted with ❤ by GitHub