October 27, 2016
Hot Topics:

The Axis2 Information Model

  • December 19, 2008
  • By Deepal Jayasinghe
  • Send Email »
  • More Articles »


As you can see from the preceding code, the axis2.xml file has parameters that can be defined in different levels as well. Here, you have parameters at the top level as well as inside transports. Parameters mainly are used to configure the system and to provide configuration data that may be needed at runtime. For example, if you need to log some request to a particular location, that location can be provided by using a parameter. Parameters are designed to store primitive data types (string, int, double, and so forth), OMelements, and the like, but NOT any type of objects. Even though storing object types inside a parameter is not invalid, it is not the correct method to follow.

Each parameter has an optional attribute called "locked", as shown below.

<parameter name="name" locked="true/false"> value </parameter>
Note: The idea of the locked attribute is to provide a control mechanism to make sure that any child node will not override that parameter.

MessageFormatters and MessageBuilders

You know that the content-type header is used to specify the type of data in the message body, and depending on the content type, the wire format varies. Therefore, you need to have a mechanism to format the message depending on content type. In Axis2, any kind of message is represented using Axiom and, when you serialize the message, it needs to be formatted based on content type. MessageFormatters serialize the Axiom object according to the content type. You can specify MessageFormatters along with the content type in axis2.xml. On the other hand, a message coming into Axis2 may or may not be XML, but for it to go though Axis2, an Axiom element needs to be created. Therefore, MessageBuilders are employed to construct the message depending on the content type.

TransportReceiver and TransportSender

One of the interesting features that you can see in Axis2 is its transport independent nature. That allows you to talk to Axis2 using any given transport. Axis2 comes a with default set of transports (HTTP, SMTP, JMS, and the like) and one can implement a new transport and use that in Axis2. When implementing a new transport, you need to implement two things: TransportSender and TransportReceiver. Transport sender's job is to serialize and handle the message exchanges depending on the underlying protocol, whereas the Transport Receiver's job is to de-serialize an input stream into Axiom and respond to the client according to the protocol.

Flows and PhaseOrder

In the Axis2 Execution framework article, I talked about the use of Flows and Phase. Axis2 comes with a default configuration and most of the time you will not need to make changes. However, if it is necessary to change the configurations, please refer to the earlier article.


In simple terms, an AxisModule is a runtime representation of a module.xml. So, whatever configuration data are found in the module.xml are in AxisModule. A typical module configuration file or module.xml contains the following data.

  • Module name
  • Module description
  • Handlers and Phase rules
  • End point and Operations
  • WS-Policy
  • Parameters

At the time of deployment, an AxisModule is populated using the data from module.xml. At runtime, any of these data can be retrieved via the same AxisModule. The parent description of the AxisModule is AxisConfiguration.

Service Description Hierarchy

As you can see in Figure 1, in the middle is an object hierarchy called the service hierarchy. This particular hierarchy is created using a services.xml file or the service descriptor, and the hierarchy contains four types of descriptions. When you deploy a service into Axis2, an object hierarchy will be created and added to AxisConfiguration. Therefore, unless you have services deployed in Axis2, you do not have the service objects hierarchy in the AxisConfiguration.

   <parameter name="name">value</parameter>
   <service name="Foo">
      <parameter name="name">value</parameter>
      <operation name="bar">
         <parameter name="name">value</parameter>
         <message label="in"></message>
   <service name="XYZ">


AxisServiceGroup is the top component of the service description hierarchy and is the child of AxisConfiguration. AxisServiceGroup can be considered the parent of a set of AxisServices that are defined in services.xml. Once you define a parameter in AxisServiceGroup, that parameter can be accessed from any AxisService or AxisOperation or AxisMessage lower in the hierarchy. In addition to parameters, an AxisServiceGroup may contain collections of modules engaged to this particular AxisServiceGroup.


An AxisServiceGroup should contain one or more AxisServices as children. Therefore, any configurations (such as parameters) defined in AxisServiceGroup or AxisConfiguration are accessible inside an AxisService. Axis2Service consists of the following kind of data:

  • AxisOperations
  • Parameters
  • Exposed transports
  • Engaged modules
  • Namespaces
  • Exposed transports
  • Description about the service
  • Message Receivers
  • WS-Policy

Page 2 of 3

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