Axis2 Execution Framework
The main idea of phase rules is to correctly locate a handler relatively to one another inside a phase. In addition to that, direct or indirect phase rules help to implement pre conditions and post conditions of a handler. Say, for instance, you do not have phase rules; in that case, to create a handler chain at deployment time, you have to have some way of specifying them. It might be a configuration file, but with that you cannot provide a dynamic nature into a handler chain. In another case, service authors might not be aware of WS-module and their handlers, so there should be a proper way of adding module related handlers into the chain as well. Therefore, the idea of phase and phase rules has been introduced to sustain the dynamic nature of a handler or an execution chain.
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
Phase name"phase" is a compulsory attribute for any phase rule; it tells the phase in which the handler must fit in. The rule to be a valid phase name is that it should to known to the system that must be either a system pre-defined phase or a user-defined phase.
As the name implies, if someone wants a handler to be invoked as the first handler in a given phase irrespective of other handler in the phase, he has to set phaseFirst attribute to "true." A phase rule only with phaseFirst and phase will be as follows:
<handler name="simple_Handler " class="org.apache.axis.handlers.SimpleHandler "> <order phase="userphase1" phaseFirst="true"/> </handler>
As in phaseFirst, if someone wants his handler to be run last in a given phase irrespective of other handlers, he has to set phaseLast to "true."
There may be situations when a handler should always run before some other handler no matter what the exact location is. Real-time use case can be that a security handler wants to run before the RM handler. The logic has to be written as below and the value of before attribute is the referred handler name:
<handler name="simple_Handler2 " class="org.apache.axis.handlers.SimpleHandler2 "> <order phase="userphase1" befoer=" simple_Handler "/> </handler>
Note: Axis2 phase rule processing logic has to be implemented in such a way that if the handler referred by before the attribute is not available in the phase at the time rule is been processed, then it just ignores the rule and will place the handler immediately after phsaeFirts handler (if it is available, or else will be placed in the first location).
As before, if a handler always runs after some other handler, the phase rule can be written by using the after attribute. It should look like the example given below, and the value of after attribute is the referred handler name:
<handler name="simple_Handler3 " class="org.apache.axis.handlers.SimpleHandler3 "> <order phase="userphase1" after=" simple_Handler2"/> </handler>
after and before
If a handler needs to be run between two different handlers, the phase rule can be written by using the before and after attribute. The values of both before and after attributes are the names of referred handlers. The correct way of writing a phase rule will be as follows:
<handler name="simple_Handler4" class="org.apache.axis.handlers.SimpleHandler4"> <order phase="userphase1" after=" simple_Handler1" before=" simple_Handler2"/> </handler>
Note: If there is a phase rule with both phaseFirst and phaseLast set to true, that phase cannot have any more handlers. The phase has only one handler.
Page 3 of 4