May 28, 2020
Hot Topics:

Axis2 Execution Framework

  • By Deepal Jayasinghe
  • Send Email »
  • More Articles »

Web services have become highly demanding and a large number of players have entered the Web service arena. Axis2 is the latest solution by Apache solutions to the Web service stack, which addresses some of the drawbacks of the Axis 1.x family and introduces some new concepts into the Web service stack. Axis2 is a highly flexible, easily configurable, highly reliable SOAP processing engine. One of the main advantages gained from Axis2 is the dynamic handler chain; although the notion of handler chain remains as in Axis 1.x, the underlying architecture is quite different.


Axis2 is shaped by the experience from the Axis 1.x family and the advancements in the Web service stack during the last few years. Axis2 developers take conscious effort to make sure that Axis2 performs better in terms of speed and memory despite the fact that new features and functionalities are added. Among all those features and functionalities, the dynamic nature of the handler chain (Execution chain) is considerably important. The article published by Web service experts in Indiana University (Beytullah Yiliz, Shrideep Pallickara, and Geoffery Fox) on the topic of "Deployment Problems in Axis and Suggestions" has suggested that the requirement of dynamically configurable handler chain in Axis is as follows:

"In Axis, handlers are currently statically configured—the configuration being made when a service is being deployed. A handler cannot be added or removed from a service. Currently, Axis architecture allows cloning the handler chain. The cloned chain can replace a current one after required changes are applied. But this is not sufficient. Dynamic configuration of handler chains will be very useful. A deployment may have lots of handlers, but a user/handler should be able to select a group of handlers that a message would need to go through."

In Axis2, the handler chain is easily configurable and has the ability of changing dynamically, the capability achieved through so-called phases, phase rules, and module engagement.


If you have ever used any version of Axis, you should be familiar with the term "Handler," the Apache terminology given for the "message interceptors" in any messaging system. Interceptor has its factual meaning in the context of messaging too, which intercepts the messaging flow and does whatever task it is assigned to do. In fact, an interceptor is the smallest execution unit in a messaging system so that, as the interceptor in Axis, handler does the same thing.

Handlers in Axis are stateless, meaning they keep their pass execution states in memory. A handler can be considered as a logic invoker with the input for the logic evaluation taken only from the MessageContext (MC). Handler has both read and writes access to MC.

Note: MessageContext can be seen as a property bag that keeps incoming or outgoing messages and other (maybe both) required parameters and properties to carry the message through the execution chain. On the other hand, via the MC one can access the whole system, such as global parameters, properties, and so forth.

Most of the time ( 99% of the time) handlers only touch the header block part of the SOAP message, which will either read a header (or headers), add a header(s) or remove a header(s). In the reading, if a header is targeted to a handler and if it cannot execute properly (message might be faulty) then it should throw an exception, and next chain driver (in Axis2 it is engine) would take necessary action depending on the flow, and phase.

Any handler in a chain has the capability to pause the message execution, meaning that the handler can stop the message flow if it cannot continue. Reliable messaging (RM) is a good example or the use case for that scenario that needs to pause the flow depending on some pre- and post conditions. In the case of RM, it works on the message sequence. If a service invocation consists of more than one message, and if the second one comes before the first, the RM handler will stop (rather pause) the execution of message invocation corresponding to the second message until it gets the first message. And, when it gets the first message, it will invoke that, and then, after, that will invoke the second message.

Writing a simple handler

Writing a handler in Axis is very simple. The only compulsory factor is that it has to extend from AbstractHandler. A simple handler is as follows:

public class SimpleHandler extends AbstractHandler {
   private String message;
   private QName name;
   public SimpleHandler() {
      this.message = "I am Simple Handler ";
   public QName getName() {
      return name;
   public void invoke(MessageContext msgContext) throws AxisFault {
      // write invocation logic here
   public void setName(QName name) {
      this.name = name;

Among all the methods in the above implementation, invoke(msgContext) is the most important to discuss. When a message is received to the Axis engine, it will call invoke methods of each handler by passing an argument as a corresponding message context, so that inside the invoke method all the processing logic should be implemented. Inside the invoke method handler, the author has full access to the SOAP message and all the required properties to process the message via the message context. In addition to that, if handler finds some pre-condition and is not satisfied with the invocation, the invocation can be paused as mentioned earlier. It should be noted that the Axis2 engine provides a facility to store and retrieve message context, so a handler can use those features to store and retrieve message context.

Page 1 of 4

This article was originally published on August 23, 2005

Enterprise Development Update

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

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