In Axis2 there are three kinds of configuration files to configure the system. First one configuration file is to configure whole system, second one is to configure a service and the third one is to configure a module.
All the configuration that requires starting axis2 is obtained from axis2.xml. The way of specifying them is very simple and easy. The document is all about the proper way of specifying the configurations in axis2.xml. There are six top level elements that can be seen in the configuration file and those can be listed as follows;
Parameter
In axis2 a parameter is nothing but name value pair, each and every top level
parameter available in the axis2.xml (direct sub elements of root element)
will be transformed into properties in AxisConfiguration. Therefore the top
level parameters in configuration document can be accessed via
AxisConfiguration in the running system. The correct way of defining a
parameter looks like what is shown below;
<parameter name="name of the parameter" >parameter value </parameter>
Transport Receiver
Depending on the underline transport that axis going to be run , need to have
different transport receivers so the way of adding them to the system can be
done as follows;
<transportReceiver name="http" class="org.apache.axis2.transport.http.SimpleHTTPServer"> <parameter name="port" >6060</parameter> </transportReceiver>
Transport Senders
As same as transport receivers it is possible to register transport senders
in the system, and latter at the run time those senders can be used to send
the messages. As an example consider Axis2 running under tomcat, then axis
can use TCP transport senders to send message rather than HTTP. The way of
specifying transport senders is as follows:
<transportSender name="http" class="org.apache.axis2.transport.http.CommonsHTTPTransportSender"> <parameter name="PROTOCOL" locked="xsd:false">HTTP/1.0</parameter> </transportSender>
Phase Order
The specifying order of phases in execution chain has to be done using phase
order element and it will be look like below;
<phaseOrder type="inflow"> <phase name="TransportIn"/> . . </phaseOrder>
<phaseOrder type="inflow""> <!-- System pre defined phases --"> <phase name="TransportIn"/"> <phase name="PreDispatch"/"> <phase name="Dispatch" class="org.apache.axis2.engine.DispatchPhase"> <handler name="AddressingBasedDispatcher" class="org.apache.axis2.engine.AddressingBasedDispatcher""> <order phase="Dispatch"/"> </handler"> <handler name="RequestURIBasedDispatcher" class="org.apache.axis2.engine.RequestURIBasedDispatcher""> <order phase="Dispatch"/"> </handler"> <handler name="SOAPActionBasedDispatcher" class="org.apache.axis2.engine.SOAPActionBasedDispatcher""> <order phase="Dispatch"/"> </handler"> <handler name="SOAPMessageBodyBasedDispatcher" class="org.apache.axis2.engine.SOAPMessageBodyBasedDispatcher""> <order phase="Dispatch"/"> </handler"> <handler name="InstanceDispatcher" class="org.apache.axis2.engine.InstanceDispatcher""> <order phase="Dispatch"/"> </handler"> </phase"> <!-- Sysem pre defined phases --"> <!-- After Postdispatch phase module author or or service author can add any phase he want --"> <phase name="userphase1"/"> </phaseOrder"> <phaseOrder type="outflow""> <!-- user can add his own phases to this area --"> <phase name="userphase1"/"> <!--system predefined phase--"> <!--these phase will run irrespective of the service--"> <phase name="PolicyDetermination"/"> <phase name="MessageOut"/"> </phaseOrder"> <phaseOrder type="INfaultflow""> <!-- user can add his own phases to this area --"> <phase name="userphase1"/"> </phaseOrder"> <phaseOrder type="Outfaultflow""> <!-- user can add his own phases to this area --"> <phase name="userphase1"/"> <phase name="PolicyDetermination"/"> <phase name="MessageOut"/"> </phaseOrder">
In addition to that only child element allowed inside pahseOrder is phase element, which represents available phases in the execution chain. The way of specifying phase inside phaseOrder has to be done as follows;
<phase name="TransportIn"/>
Module References
If you want to engage a module system wide you can do it by adding top level
module element in axis2.xml. It should be look like following:
<module ref="addressing"/>
<listener class="org.apache.axis2.ObserverIMPL"> <parameter name="RSS_URL" >http://127.0.0.1/rss</parameter> </listener>
The description of service is specified using services.xml, each
service archive file need to have services.xml in order to be a valid
service. And which has to be available in META-INF directory of the archive
file.
A very simple services.xml is shown below:
<service > <description> The description of the service </description> <parameter name="ServiceClass" locked="xsd:false">org.apache.axis2.sample.echo.EchoImpl</parameter> <operation name="echoString"> <module ref=" a module name "/> <messageReceiver class="org.apache.axis2.receivers.RawXMLINOutMessageReceiver"/> </operation> </service>
Parameter:
services.xml can have any number of top level parameters and all the
specified parameters will be transformed into service properties in
corresponding ServiceDescrption. There is a compulsory parameter in a
services.xml called ServiceClass which specify the java class which really
does the job and the class will be loaded by MessageReceiver.
Handler
Handler element consists of compulsory and optional attribute and the way of
defining a handler will be look like follows;
<handler name="handler1" class="handlerClass "> <order phase="userphase1" /> </handler>
Operations
All the operations you are going to exposeby the service has to be indicated
in the services.xml and the correct way of specifying that should be as
follows:
<operation name="echoString"> <module ref=" a module name "/> <messageReceiver class="org.apache.axis2.receivers.RawXMLINOutMessageReceiver"/> </operation>
The description of module is specified using module.xml, each module
archive file need to have module.xml in order to be a valid module. And which
has to be available in META-INF directory of the archive file.
A very simple module.xml is shown below:
<module name="module1" class="org.apache.module.Module1Impl"> <inflow> . . </inflow> <outflow> . . </outflow> <Outfaultflow> . . </Outfaultflow> <INfaultflow> . . </INfaultflow> <operation name="creatSeq" mep="MEP_URI_IN_OUT"> <messageReceiver class="org.apache.axis2.receivers.RawXMLINOutMessageReceiver"/> <parameter name="para1" locked="xsd:true">10</parameter> </operation> </module>
parameter: Module can contains any number of parameters and all the listed parameters in the module.xml will be transformed into corresponding ModuleDescription of the module.
Flow :
It is possible to add handlers into a flow directly form services.xml rather
than engaging a modules and the way of doing that is through flow elements.
It is possible to add any number of handlers into a flow and those handlers
will be available in corresponding operations flows in the service (inflow
consist of two parts, one part is up to post dispatch phase and other part is
consisting of operation handlers)
There are four types of valid flows that can be available in services.xml,
and the adding the handles into them can be done by following the above
procedure.
Valid flows:
operations If a module wants to add an operation when it is engaged into a service it can be done by adding operation tag in module.xml and the way of specifying the operation is same as operation in services.xml.