The Axis2 Information Model, Page 2
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
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
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.
<serviceGroup> <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> </operation> </service> <service name="XYZ"> ..... </service> </serviceGroup>
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:
- Exposed transports
- Engaged modules
- Exposed transports
- Description about the service
- Message Receivers