October 24, 2016
Hot Topics:

Axis2 Execution Framework

  • August 23, 2005
  • By Deepal Jayasinghe
  • Send Email »
  • More Articles »

Invalid phase rules

Validity of a phase rule is an important factor in Axis2. There can be many ways to get the same handler order by using different kinds of phase rules. But, when writing a phase rule, it is required to check to see whether the rule is a valid rule. There may be many ways in which a phase rule becomes an invalid rule. Some of them are:

  • If there is a phase rule of a handler with either phaseFirst or phaseLast attribute set to true, it cannot have before or after appearing in the phase rule. If they do, then the rule is invalid.
  • If there is a phase rule of a handler with both phaseFirst and phaseLast set to true, that particular phase cannot have more than one handler. If someone tries to write a phase rule that inserts a handler into the same phase, the second phase rule is invalid.
  • There cannot be two handlers in one phase with their phaseFirst attribute set to true.
  • There cannot be two handlers in one phase with their phaseLast attribute set to true.
  • If the rule is such that before attribute is referred to phaseFirst handler, the rule is invalid.
  • If the rule is such that after attribute is referred to phaseLast handler, the rule is invalid.
<handler name="simple_HandlerError "
         class="org.apache.axis.handlers.SimpleHandlerError ">
   <order phase="userphase1"
             before=" simple_Handler" phaseFirst="true"/>
Note: Phase rules are defined per handler basic, and any handler in the system must fit in to a phase in the system.


Flow is simply a collection of phases, and the order of phases inside a flow is defined in server.xml. Because phase is a logical collection and which is in fact a virtual concept, a flow can be assumed as a handler chain (collection of handlers). There are four types of flows in Axis2:

  • InFlow
  • OutFlow
  • InFaultFlow
  • OutFaultFlow

InFlow: When a message comes in (request message), the message has to go via the InFlow. All the handlers in the InFlow will be invoked. In*Flows are somewhat different from Out*Flows. The flow consist of two parts. The first part is from the beginning to Dispatcher (up to and including postdispatch phase). The second part will be there only if a corresponding service is found at the end of dispatch phase. Therefore, the second part of the flow is InFlow of the corresponding operation for the incoming message. So, the InFlow consists of global part and operation part.

InFaultFlow: This flow will be invoked if any fault occurs while processing the incoming request. If a fault occurs before dispatching takes place, the global part of the flow will be executed, or else complete flow (including operation fault flow) will be executed.

OutFlow: When a message is going out from the server (say response) the OutFlow will be invoked, as a result of response or the out going message is always bound to an operation, and there is nothing similar to dispatching in the out path. Therefore, unlike InFlow, OutFlow does not consist of two parts. Therefore, there is no concept of global phases in the out flow.

OutFaultFlow: If something goes wrong in the out path, the out fault flow will be invoked.

Note: There can be many services deployed in the system. Each service can have more than one operation.

Dynamic handler chain through module engagement

In Axis2, a module can be considered as a collection of handlers, so by engaging a module either globally to a service or to an operation, module handlers will be placed in the corresponding phases. If a module is engaged globally, that will affect all the services in the system, and there is a probability of changing both global and operations flows (each operation in all the services). If a module is engaged to a service, flows belonging to all the operations in that particular service will be changed. If a module is engaged to an operation, each flow in that operation may be changed.

The only way of changing a flow is adding a handler(s) to a phase in the flow. Therefore, module engagement will cause the handler chain dynamically. A module can be engaged dynamically or statically. If someone wants to engaged a module statically he/she has to specify them in description files (if it is to a service or to an operation then in service.xml, if it is to be globally, then server.xml).

Note: The real-time scenario of runtime module engagement is by WS-Policy, where WS-Policy handlers can engage a module at the runtime by considering message headers.


Axis2 is fair enough to provide Web service interaction with dynamic and flexible execution framework. Flexibility is achieved using the concept of phases and phase rules, and the dynamic nature of the execution chain has been achieved by runtime module engagement.

Page 4 of 4

Comment and Contribute


(Maximum characters: 1200). You have characters left.



Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Sitemap | Contact Us

Thanks for your registration, follow us on our social networks to keep up-to-date
Rocket Fuel