axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dee...@apache.org
Subject svn commit: r474202 - /webservices/axis2/branches/java/1_1/xdocs/1_1/axis2config.html
Date Mon, 13 Nov 2006 09:13:27 GMT
Author: deepal
Date: Mon Nov 13 01:13:27 2006
New Revision: 474202

URL: http://svn.apache.org/viewvc?view=rev&rev=474202
Log:
update the axis2config.html file with new structure of services.xml

Modified:
    webservices/axis2/branches/java/1_1/xdocs/1_1/axis2config.html

Modified: webservices/axis2/branches/java/1_1/xdocs/1_1/axis2config.html
URL: http://svn.apache.org/viewvc/webservices/axis2/branches/java/1_1/xdocs/1_1/axis2config.html?view=diff&rev=474202&r1=474201&r2=474202
==============================================================================
--- webservices/axis2/branches/java/1_1/xdocs/1_1/axis2config.html (original)
+++ webservices/axis2/branches/java/1_1/xdocs/1_1/axis2config.html Mon Nov 13 01:13:27 2006
@@ -1,446 +1,451 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<html>
-<head>
-  <meta http-equiv="content-type" content="">
-  <title>Axis2 Configuration Documents</title>
-  <link href="../css/axis-docs.css" rel="stylesheet" type="text/css" media="all" />
-</head>
-<body lang="en">
-
-<h1>Axis2 Configuration Guide</h1>
-
-<p>In Axis2 there are three kinds of configuration files to configure the
-system. First one is to configure whole system (global configuration), second
-one is to configure a service (service configuration) and the third one is to
-configure a module (module configuration). This document will explain in
-detail the above configurations.</p>
-
-<h2>Content</h2>
-<ul>
-  <li><a href="#Global_Configuration">Global Configuration
-  (axis2.xml)</a></li>
-  <li><a href="#Service_Configuration">Service Configuration
-    (services.xml)</a></li>
-  <li><a href="#Module_Configuration">Module Configuration
-  (module.xml)</a></li>
-</ul>
-
-<a name="Global_Configuration"></a>
-<h2>Global Configuration</h2>
-<ul>
-  <li>Writing axis2.xml</li>
-</ul>
-
-<p>All the configurations that require starting Axis2 are obtained from the
-axis2.xml. The way of specifying them is extremely 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 can be listed as follows:</p>
-<ul>
-  <li><a href="#Parameter">Parameter</a></li>
-  <li><a href="#Receiver">Transport Receiver</a></li>
-  <li><a href="#Sender">Transport Sender</a></li>
-  <li><a href="#Phase_Order">Phase Order</a></li>
-  <li><a href="#References">Module References</a></li>
-  <li><a href="#Listeners">Listeners (Observers)</a></li>
-</ul>
-<a name="Parameter"></a>
-<h3>Parameter</h3>
-
-<p>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 the configuration document can be accessed via
-AxisConfiguration in the running system. The correct way of defining a
-parameter is shown below:</p>
-<source><pre> 
-  &lt;parameter name="name of the parameter" &gt;parameter value &lt;/parameter&gt;</pre>
-</source>
-<a name="Receiver"></a>
-
-<h3>Transport Receiver</h3>
-
-<p>Depending on the underlying transport that Axis2 is going to run on, you
-need to have different transport receivers. The way of adding them to the
-system is as follows:</p>
-<pre> 
-&lt;transportReceiver name="http" class="org.apache.axis2.transport.http.SimpleHTTPServer"&gt;
-        &lt;parameter name="port" &gt;6060&lt;/parameter&gt;
- &lt;/transportReceiver&gt; 
- </pre>
-</source>The above elements show the way of defining transport receivers in
-axis2.xml. Here the name attribute of the 'transportReceiver' element is the
-name of transport receiver. It can be http, tcp, smtp, commonshttp etc, and
-when the system starts up or when you set the transport at the client side,
-one can use these transport names to load the appropriate transport. Class
-attribute is to specify actual java classes which implements required
-interfaces for the transport. Any transport can have zero or more parameters,
-and if there are any, then those parameters can be accessed via the
-corresponding transport receiver. 
-
-<a name="Sender"></a>
-
-<h3>Transport Sender</h3>
-
-<p>As same as transport receivers, it is possible to register transport
-senders in the system, and later at the run time, those senders can be used
-to send the messages. As an example, consider Axis2 running under Apache
-Tomcat. Then Axis2 can use TCP transport senders to send messages rather than
-HTTP. The way of specifying transport senders is as follows:</p>
-<pre> 
-&lt;transportSender name="http" class="org.apache.axis2.transport.http.CommonsHTTPTransportSender"&gt;
-        &lt;parameter name="PROTOCOL" locked="xsd:false"&gt;HTTP/1.0&lt;/parameter&gt;
- &lt;/transportSender&gt; 
- </pre>
-</source><strong>name:</strong> Name of the transport (it is possible to
have
-http and http1 as transport name)
-
-<p><strong>class:</strong> Implementation class of the corresponding
-transport. As same as transport receivers, transport senders can have zero or
-more parameters, and if there are any then it can be accessed via
-corresponding transport sender.</p>
-<a name="Phase_Order"></a>
-<h3>Phase Order</h3>
-
-<p>The specifying order of phases in execution chain has to be done using
-phase order element and it will look like below:</p>
-<pre>&lt;phaseOrder type="InFlow"&gt;
-         &lt;phase name="TransportIn"/&gt;
-         .
-         .
-&lt;/phaseOrder&gt;   </pre>
-</source>
-<p>The most interesting thing is that you can add handlers here as well. If
-you want to add a handler which should go into that phase, you can directly
-do that by adding a handler element into it. In addition to that, there is no
-hard coding work for the handler chain anywhere in Axis2 (at any Axis*). So
-all those configurations are also done in the phase order element. The
-complete configurations will look as follows: <source></p>
-<pre>&lt;phaseOrder type="InFlow"&gt;
-        &lt;!--   Global phases    --&gt;
-         &lt;phase name="Transport"&gt;
-            &lt;handler name="RequestURIBasedDispatcher"
-                     class="org.apache.axis2.engine.RequestURIBasedDispatcher"&gt;
-                &lt;order phase="Transport"/&gt;
-            &lt;/handler&gt;
-
-            &lt;handler name="SOAPActionBasedDispatcher"
-                     class="org.apache.axis2.engine.SOAPActionBasedDispatcher"&gt;
-                &lt;order phase="Transport"/&gt;
-            &lt;/handler&gt;
-        &lt;/phase&gt;
-        &lt;phase name="Security"/&gt;
-        &lt;phase name="PreDispatch"/&gt;
-        &lt;phase name="Dispatch" class="org.apache.axis2.engine.DispatchPhase"&gt;
-            &lt;handler name="AddressingBasedDispatcher"
-                     class="org.apache.axis2.engine.AddressingBasedDispatcher"&gt;
-                &lt;order phase="Dispatch"/&gt;
-            &lt;/handler&gt;
-
-            &lt;handler name="SOAPMessageBodyBasedDispatcher"
-                     class="org.apache.axis2.engine.SOAPMessageBodyBasedDispatcher"&gt;
-                &lt;order phase="Dispatch"/&gt;
-            &lt;/handler&gt;
-
-            &lt;handler name="InstanceDispatcher"
-                     class="org.apache.axis2.engine.InstanceDispatcher"&gt;
-                &lt;order phase="Dispatch"/&gt;
-            &lt;/handler&gt;
-        &lt;/phase&gt;
-        &lt;!--   Global phases   --&gt;
-        &lt;!--   After the Dispatch phase module author or service author can add any
phase he wants    --&gt;
-        &lt;phase name="OperationInPhase"/&gt;
-    &lt;/phaseOrder&gt;
-    &lt;phaseOrder type="OutFlow"&gt;
-        &lt;!--   user can add his own phases to this area  --&gt;
-        &lt;phase name="OperationOutPhase"/&gt;
-        &lt;!--  Global phases  --&gt;
-        &lt;!--  these phases will run irrespective of the service  --&gt;
-        &lt;phase name="MessageOut"/&gt;
-        &lt;phase name="PolicyDetermination"/&gt;
-    &lt;/phaseOrder&gt;
-    &lt;phaseOrder type="InFaultFlow"&gt;
-        &lt;phase name="PreDispatch"/&gt;
-        &lt;phase name="Dispatch" class="org.apache.axis2.engine.DispatchPhase"&gt;
-            &lt;handler name="RequestURIBasedDispatcher"
-                     class="org.apache.axis2.engine.RequestURIBasedDispatcher"&gt;
-                &lt;order phase="Dispatch"/&gt;
-            &lt;/handler&gt;
-
-            &lt;handler name="SOAPActionBasedDispatcher"
-                     class="org.apache.axis2.engine.SOAPActionBasedDispatcher"&gt;
-                &lt;order phase="Dispatch"/&gt;
-            &lt;/handler&gt;
-
-            &lt;handler name="AddressingBasedDispatcher"
-                     class="org.apache.axis2.engine.AddressingBasedDispatcher"&gt;
-                &lt;order phase="Dispatch"/&gt;
-            &lt;/handler&gt;
-
-            &lt;handler name="SOAPMessageBodyBasedDispatcher"
-                     class="org.apache.axis2.engine.SOAPMessageBodyBasedDispatcher"&gt;
-                &lt;order phase="Dispatch"/&gt;
-            &lt;/handler&gt;
-            &lt;handler name="InstanceDispatcher"
-                     class="org.apache.axis2.engine.InstanceDispatcher"&gt;
-                &lt;order phase="Dispatch"/&gt;
-            &lt;/handler&gt;
-        &lt;/phase&gt;
-        &lt;!--      user can add his own phases to this area  --&gt;
-        &lt;phase name="OperationInFaultPhase"/&gt;
-    &lt;/phaseOrder&gt;
-    &lt;phaseOrder type="OutFaultFlow"&gt;
-        &lt;!--      user can add his own phases to this area  --&gt;
-        &lt;phase name="OperationOutFaultPhase"/&gt;
-        &lt;phase name="PolicyDetermination"/&gt;
-        &lt;phase name="MessageOut"/&gt;
-    &lt;/phaseOrder&gt;</pre>
-</source>
-<p><strong>type:</strong> the attribute represents the type of the flow
and
-can only be one of the following:</p>
-<ul>
-  <li>InFlow</li>
-  <li>OutFlow</li>
-  <li>InFaultFlow</li>
-  <li>OutFaultFlow</li>
-</ul>
-
-<p>In addition to that, the only child element that is allowed inside "phaseOrder"
-is "phase" element which represents available phases in the execution chain.
-The way of specifying phases inside "phaseOrder" is as follows:</p>
-<pre> &lt;phase name="Transport"/&gt;</pre>
-</source>
-<p><strong>name:</strong> Name of the phase. <br>
-</p>
-
-<p>There are a number of things that one has to keep in mind when changing a
-phaseOrder:</p>
-
-<p>For the phaseOrder types <strong>"InFlow"</strong> and
-<strong>"InFaultFlow"</strong></p>
-<ul>
-  <li>All the phases which are above the "Dispatch" phase including the
-    "Dispatch" phase are known as "Global phases" and one can add any number
-    of new phases here and these will be considered global.</li>
-  <li>In these two phaseOrder types the phases added after the "Dispatch"
-    phase are known as "Operation phases".</li>
-</ul>
-
-<p>For the phaseOrder types <strong>"OutFlow"</strong> and
-<strong>"OutFaultFlow"</strong></p>
-<ul>
-  <li>All the phases which are below the "MessageOut" phase, including the
-    "MessageOut" phase are known as "Global phases", and you can add new
-    phases according to your requirement.</li>
-  <li>The phases added before the "MessageOut" phase are known as "Operation
-    phases".</li>
-
-  <p><strong>Note :</strong> If you closely look at the default axis2.xml
you
-  will be able to clearly identify that.</p>
-</ul>
-<a name="References"></a>
-<h3>Module References</h3>
-
-<p>If you want to engage a module, system wide, you can do it by adding top
-level module element in axis2.xml. It should look like following:</p>
-<pre>&lt;module ref="addressing"/&gt;  </pre>
-</source>
-<p><strong>ref:</strong> the module name which is going to be engage, system
-wide.</p>
-<a name="Listeners"></a>
-<h3><strong>Listeners (Observers)</strong></h3>
-
-<p>In Axis2, AxisConfiguration is observable so that one can register
-observers into that, and they will be automatically informed whenever a
-change occurs in AxisConfiguration. In the current implementation, the
-observers are informed of the following events:</p>
-<ul>
-  <li>Deploying a Service</li>
-  <li>Removing a service</li>
-  <li>Activate/Inactivate Service</li>
-  <li>Module deploy</li>
-  <li>Module remove</li>
-</ul>
-Registering Observers is very useful for additional features such as RSS feed
-generation which will provide service information to subscribers. The correct
-way of registering observers should be like below:
-<pre>&lt;listener class="org.apache.axis2.ObserverIMPL"&gt;
-    &lt;parameter name="RSS_URL" &gt;http://127.0.0.1/rss&lt;/parameter&gt;
-  &lt;/listener&gt;</pre>
-</source>
-<p><strong>class:</strong> Represents an Implementation class of observer,
-and it should be noted that the implementation class should implement
-AxisObserver interface, and the class has to be available in the classpath.
-<a name="Service_Configuration"></a>
-</p>
-<h2><font>Service Configuration</font></h2>
-<ul>
-  <li><font>Writing services.xml</font></li>
-</ul>
-
-<p><font>The description of services are specified using services.xml. Each
-service archive file needs to have a services.xml in order to be a valid
-service and it should be available in the META-INF directory of the archive
-file. A very simple services.xml is shown below:</font></p>
-<source><pre><font>&lt;service name="name of the service" scope="name
of the scope" targetNamespace="target namespase for the service"&gt;
-    &lt;description&gt; The description of the service  &lt;/description&gt;
 
-
-    &lt;transports&gt; 
-       &lt;transport&gt;HTTP&lt;/transport&gt;
-    &lt;/transports&gt;
-    
-    &lt;schema schemaNamespace="schema namespace"/&gt; 
-     
-    &lt;messageReceivers&gt;
-            &lt;messageReceiver mep="http://www.w3.org/2004/08/wsdl/in-out"
-                             class="org.apache.axis2.rpc.receivers.RPCMessageReceiver"/&gt;
-    &lt;/messageReceivers&gt;
-     
-     &lt;parameter name="ServiceClass" locked="xsd:false"&gt;org.apache.axis2.sample.echo.EchoImpl&lt;/parameter&gt;
-    
-    &lt;operation name="echoString" mep="operation MEP"&gt; 
-        &lt;actionMapping&gt;Mapping to action&lt;/actionMapping&gt;
-        &lt;module ref=" a module name "/&gt;
-        &lt;messageReceiver class="org.apache.axis2.receivers.RawXMLINOutMessageReceiver"/&gt;
-    &lt;/operation&gt;
-  &lt;/service&gt;</font></pre>
-</source>
-<p><font><strong>name</strong>: The service name will be the name
of the
-archive file, if the .aar file contains only one service, or else the name of
-the service will be the name given by the name attribute.</font></p>
-
-<p><strong>scope</strong>: The time period in which runtime information
of
-deployed services will be available. Scope is of several types-
-"Application", "SOAPSession", "TransportSession", "Request"</p>
-
-<p><strong>targetNamespace</strong>: Target name space of the service,
and
-this value will be used when generating the wsdl</p>
-
-<p><font><strong>description</strong>: This is an optional element
if you
-want to display any description about the service via Axis2 web-admin module,
-then the description can be specified here.</font></p>
-
-<p><strong>transports</strong> : The transports that the service is going
to
-be exposed to. This is an optional element. If the transport element is not
-present then the service will be exposed in all the transports available in
-the system. The transport child element is there to specify the transport
-prefix (the name of the transport specified in axis2.xml).</p>
-
-<p><b>parameters:</b> A services.xml can have any number of top level
-parameters and all the specified parameters will be transformed into service
-properties in the corresponding AxisService. There is a compulsory parameter
-in a services.xml called ServiceClass which specifies the java class which
-really does the job and the class will be loaded by the MessageReceiver.</p>
-
-<p><b>operations :</b> If the service impl class is java, then all the
public
-methods in that service will be exposed and if the user wants to override it
-then he has to add the "operation" tag and override it. In the case of
-non-Java or if you do not have a service class, then all the operations the
-user wants to expose by the service has to be indicated in the services.xml
-and the correct way of specifying is as follows:</p>
-<pre>    &lt;operation name="echoString"&gt;
-        &lt;module ref=" a module name "/&gt;
-        &lt;messageReceiver class="org.apache.axis2.receivers.RawXMLINOutMessageReceiver"/&gt;
-    &lt;/operation&gt;</pre>
-</source>
-<p>The only compulsory attribute here is "name", which represents the
-operation name that is going to be exposed. Any operation can contain module
-references as well as any number of parameters. The most interesting thing is
-that one can register custom message receivers per operation, then the
-registered message receiver will be the message receiver for the
-corresponding operation. If one does not specify the message receiver, then
-the default message receiver will do the job. <br>
-<a name="Module_Configuration"></a></p>
-
-<h2>Module Configuration</h2>
-<ul>
-  <li>Writing module.xml</li>
-</ul>
-
-<p>The description of the module is specified using the module.xml. Each
-module archive file needs to have a module.xml in order to be a valid module,
-and it should be available in the META-INF directory of the archive file. <br>
-</p>
-
-<p>A very simple module.xml is shown below:</p>
-<pre>&lt;module class="org.apache.module.Module1Impl"&gt;
-    &lt;InFlow&gt;
-        .
-        .
-    &lt;/InFlow&gt;
-    &lt;OutFlow&gt;
-        .
-        .
-    &lt;/OutFlow&gt;
-
-    &lt;OutFaultFlow&gt;
-        .   
-        .
-    &lt;/OutFaultFlow&gt;
-
-    &lt;InFaultFlow&gt;
-        .         
-        .
-    &lt;/InFaultFlow&gt;
-
-    &lt;operation name="creatSeq" mep="MEP_URI_IN_OUT"&gt;
-        &lt;messageReceiver class="org.apache.axis2.receivers.RawXMLINOutMessageReceiver"/&gt;
-        &lt;parameter name="para1" locked="xsd:true"&gt;10&lt;/parameter&gt;
-    &lt;/operation&gt;
-&lt;/module&gt;</pre>
-</source>
-<p><strong>class:</strong> This is an optional attribute which indicates
the
-module implementation class. A module may or may not contain a module
-implementation class since the module can also be a collection of handlers.
-If a module contains an implementation class which implements the
-org.apache.axis2.modules.Module interface where at the deployment time its
-<code>init();</code> method will be called.</p>
-
-<p><b>parameter:</b> A module can contain any number of parameters and
all
-the listed parameters in the module.xml will be transformed into
-corresponding AxisModule of the module.</p>
-
-<p><b>flow: </b>Defining of handlers in a module has to be done inside
flows,
-and there are four types of flows as listed below.</p>
-
-<p>It is possible to add any number of handlers into a flow and those
-handlers will be available in corresponding chains at the runtime when they
-are engaged .</p>
-<ul>
-  <li>InFlow</li>
-  <li>OutFlow</li>
-  <li>InFaultFlow</li>
-  <li>OutFaultFlow</li>
-</ul>
-
-<p><b>operations: </b> If a module wants to add an operation when it is
-engaged into a service it can be done by adding an operation tag in
-module.xml and the way of specifying the operation is the same as operation
-in services.xml.</p>
-
-<p><b>handler:</b> The Handler element consists of compulsory and optional
-attributes and the way of defining a handler will look as follows:</p>
-<pre>&lt;handler name="handler1" class="handlerClass "&gt;
-            &lt;order phase="userphase1" /&gt;
- &lt;/handler&gt;</pre>
-</source>
-<p><b><i>Compulsory Attributes</i></b> <br>
-<b>name:</b> name of the handler<br>
-<b>class:</b> handler implementation class<br>
-<b>phase:</b> name of the phase that the handler should stay in the execution
-chain <br>
-<br>
-<i><b>Optional Attributes :</b></i><br>
-<b>phaseLast:</b> to indicate the handler is last handler of the phase<br>
-<b>phaseFirst:</b> to indicate the handler is first handler of the phase.<br>
-<b>before :</b> the handler should be invoked before the handler specified by
-the before handler<br>
-<b>after:</b> the handler should be invoked after the handler specified by
-the after handler<br>
-</p>
-
-<p><br>
-</p>
-
-</body>
-</html>
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+<html>
+<head>
+  <meta http-equiv="content-type" content="">
+  <title>Axis2 Configuration Documents</title>
+  <link href="../css/axis-docs.css" rel="stylesheet" type="text/css" media="all" />
+</head>
+<body lang="en">
+
+<h1>Axis2 Configuration Guide</h1>
+
+<p>In Axis2 there are three kinds of configuration files to configure the
+system. First one is to configure whole system (global configuration), second
+one is to configure a service (service configuration) and the third one is to
+configure a module (module configuration). This document will explain in
+detail the above configurations.</p>
+
+<h2>Content</h2>
+<ul>
+  <li><a href="#Global_Configuration">Global Configuration
+  (axis2.xml)</a></li>
+  <li><a href="#Service_Configuration">Service Configuration
+    (services.xml)</a></li>
+  <li><a href="#Module_Configuration">Module Configuration
+  (module.xml)</a></li>
+</ul>
+
+<a name="Global_Configuration"></a>
+<h2>Global Configuration</h2>
+<ul>
+  <li>Writing axis2.xml</li>
+</ul>
+
+<p>All the configurations that require starting Axis2 are obtained from the
+axis2.xml. The way of specifying them is extremely 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 can be listed as follows:</p>
+<ul>
+  <li><a href="#Parameter">Parameter</a></li>
+  <li><a href="#Receiver">Transport Receiver</a></li>
+  <li><a href="#Sender">Transport Sender</a></li>
+  <li><a href="#Phase_Order">Phase Order</a></li>
+  <li><a href="#References">Module References</a></li>
+  <li><a href="#Listeners">Listeners (Observers)</a></li>
+</ul>
+<a name="Parameter"></a>
+<h3>Parameter</h3>
+
+<p>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 the configuration document can be accessed via
+AxisConfiguration in the running system. The correct way of defining a
+parameter is shown below:</p>
+<source><pre> 
+  &lt;parameter name="name of the parameter" &gt;parameter value &lt;/parameter&gt;</pre>
+</source>
+<a name="Receiver"></a>
+
+<h3>Transport Receiver</h3>
+
+<p>Depending on the underlying transport that Axis2 is going to run on, you
+need to have different transport receivers. The way of adding them to the
+system is as follows:</p>
+<pre> 
+&lt;transportReceiver name="http" class="org.apache.axis2.transport.http.SimpleHTTPServer"&gt;
+        &lt;parameter name="port" &gt;6060&lt;/parameter&gt;
+ &lt;/transportReceiver&gt; 
+ </pre>
+</source>The above elements show the way of defining transport receivers in
+axis2.xml. Here the name attribute of the 'transportReceiver' element is the
+name of transport receiver. It can be http, tcp, smtp, commonshttp etc, and
+when the system starts up or when you set the transport at the client side,
+one can use these transport names to load the appropriate transport. Class
+attribute is to specify actual java classes which implements required
+interfaces for the transport. Any transport can have zero or more parameters,
+and if there are any, then those parameters can be accessed via the
+corresponding transport receiver. 
+
+<a name="Sender"></a>
+
+<h3>Transport Sender</h3>
+
+<p>As same as transport receivers, it is possible to register transport
+senders in the system, and later at the run time, those senders can be used
+to send the messages. As an example, consider Axis2 running under Apache
+Tomcat. Then Axis2 can use TCP transport senders to send messages rather than
+HTTP. The way of specifying transport senders is as follows:</p>
+<pre> 
+&lt;transportSender name="http" class="org.apache.axis2.transport.http.CommonsHTTPTransportSender"&gt;
+        &lt;parameter name="PROTOCOL" locked="xsd:false"&gt;HTTP/1.0&lt;/parameter&gt;
+ &lt;/transportSender&gt; 
+ </pre>
+</source><strong>name:</strong> Name of the transport (it is possible to
have
+http and http1 as transport name)
+
+<p><strong>class:</strong> Implementation class of the corresponding
+transport. As same as transport receivers, transport senders can have zero or
+more parameters, and if there are any then it can be accessed via
+corresponding transport sender.</p>
+<a name="Phase_Order"></a>
+<h3>Phase Order</h3>
+
+<p>The specifying order of phases in execution chain has to be done using
+phase order element and it will look like below:</p>
+<pre>&lt;phaseOrder type="InFlow"&gt;
+         &lt;phase name="TransportIn"/&gt;
+         .
+         .
+&lt;/phaseOrder&gt;   </pre>
+</source>
+<p>The most interesting thing is that you can add handlers here as well. If
+you want to add a handler which should go into that phase, you can directly
+do that by adding a handler element into it. In addition to that, there is no
+hard coding work for the handler chain anywhere in Axis2 (at any Axis*). So
+all those configurations are also done in the phase order element. The
+complete configurations will look as follows: <source></p>
+<pre>&lt;phaseOrder type="InFlow"&gt;
+        &lt;!--   Global phases    --&gt;
+         &lt;phase name="Transport"&gt;
+            &lt;handler name="RequestURIBasedDispatcher"
+                     class="org.apache.axis2.engine.RequestURIBasedDispatcher"&gt;
+                &lt;order phase="Transport"/&gt;
+            &lt;/handler&gt;
+
+            &lt;handler name="SOAPActionBasedDispatcher"
+                     class="org.apache.axis2.engine.SOAPActionBasedDispatcher"&gt;
+                &lt;order phase="Transport"/&gt;
+            &lt;/handler&gt;
+        &lt;/phase&gt;
+        &lt;phase name="Security"/&gt;
+        &lt;phase name="PreDispatch"/&gt;
+        &lt;phase name="Dispatch" class="org.apache.axis2.engine.DispatchPhase"&gt;
+            &lt;handler name="AddressingBasedDispatcher"
+                     class="org.apache.axis2.engine.AddressingBasedDispatcher"&gt;
+                &lt;order phase="Dispatch"/&gt;
+            &lt;/handler&gt;
+
+            &lt;handler name="SOAPMessageBodyBasedDispatcher"
+                     class="org.apache.axis2.engine.SOAPMessageBodyBasedDispatcher"&gt;
+                &lt;order phase="Dispatch"/&gt;
+            &lt;/handler&gt;
+
+            &lt;handler name="InstanceDispatcher"
+                     class="org.apache.axis2.engine.InstanceDispatcher"&gt;
+                &lt;order phase="Dispatch"/&gt;
+            &lt;/handler&gt;
+        &lt;/phase&gt;
+        &lt;!--   Global phases   --&gt;
+        &lt;!--   After the Dispatch phase module author or service author can add any
phase he wants    --&gt;
+        &lt;phase name="OperationInPhase"/&gt;
+    &lt;/phaseOrder&gt;
+    &lt;phaseOrder type="OutFlow"&gt;
+        &lt;!--   user can add his own phases to this area  --&gt;
+        &lt;phase name="OperationOutPhase"/&gt;
+        &lt;!--  Global phases  --&gt;
+        &lt;!--  these phases will run irrespective of the service  --&gt;
+        &lt;phase name="MessageOut"/&gt;
+        &lt;phase name="PolicyDetermination"/&gt;
+    &lt;/phaseOrder&gt;
+    &lt;phaseOrder type="InFaultFlow"&gt;
+        &lt;phase name="PreDispatch"/&gt;
+        &lt;phase name="Dispatch" class="org.apache.axis2.engine.DispatchPhase"&gt;
+            &lt;handler name="RequestURIBasedDispatcher"
+                     class="org.apache.axis2.engine.RequestURIBasedDispatcher"&gt;
+                &lt;order phase="Dispatch"/&gt;
+            &lt;/handler&gt;
+
+            &lt;handler name="SOAPActionBasedDispatcher"
+                     class="org.apache.axis2.engine.SOAPActionBasedDispatcher"&gt;
+                &lt;order phase="Dispatch"/&gt;
+            &lt;/handler&gt;
+
+            &lt;handler name="AddressingBasedDispatcher"
+                     class="org.apache.axis2.engine.AddressingBasedDispatcher"&gt;
+                &lt;order phase="Dispatch"/&gt;
+            &lt;/handler&gt;
+
+            &lt;handler name="SOAPMessageBodyBasedDispatcher"
+                     class="org.apache.axis2.engine.SOAPMessageBodyBasedDispatcher"&gt;
+                &lt;order phase="Dispatch"/&gt;
+            &lt;/handler&gt;
+            &lt;handler name="InstanceDispatcher"
+                     class="org.apache.axis2.engine.InstanceDispatcher"&gt;
+                &lt;order phase="Dispatch"/&gt;
+            &lt;/handler&gt;
+        &lt;/phase&gt;
+        &lt;!--      user can add his own phases to this area  --&gt;
+        &lt;phase name="OperationInFaultPhase"/&gt;
+    &lt;/phaseOrder&gt;
+    &lt;phaseOrder type="OutFaultFlow"&gt;
+        &lt;!--      user can add his own phases to this area  --&gt;
+        &lt;phase name="OperationOutFaultPhase"/&gt;
+        &lt;phase name="PolicyDetermination"/&gt;
+        &lt;phase name="MessageOut"/&gt;
+    &lt;/phaseOrder&gt;</pre>
+</source>
+<p><strong>type:</strong> the attribute represents the type of the flow
and
+can only be one of the following:</p>
+<ul>
+  <li>InFlow</li>
+  <li>OutFlow</li>
+  <li>InFaultFlow</li>
+  <li>OutFaultFlow</li>
+</ul>
+
+<p>In addition to that, the only child element that is allowed inside "phaseOrder"
+is "phase" element which represents available phases in the execution chain.
+The way of specifying phases inside "phaseOrder" is as follows:</p>
+<pre> &lt;phase name="Transport"/&gt;</pre>
+</source>
+<p><strong>name:</strong> Name of the phase. <br>
+</p>
+
+<p>There are a number of things that one has to keep in mind when changing a
+phaseOrder:</p>
+
+<p>For the phaseOrder types <strong>"InFlow"</strong> and
+<strong>"InFaultFlow"</strong></p>
+<ul>
+  <li>All the phases which are above the "Dispatch" phase including the
+    "Dispatch" phase are known as "Global phases" and one can add any number
+    of new phases here and these will be considered global.</li>
+  <li>In these two phaseOrder types the phases added after the "Dispatch"
+    phase are known as "Operation phases".</li>
+</ul>
+
+<p>For the phaseOrder types <strong>"OutFlow"</strong> and
+<strong>"OutFaultFlow"</strong></p>
+<ul>
+  <li>All the phases which are below the "MessageOut" phase, including the
+    "MessageOut" phase are known as "Global phases", and you can add new
+    phases according to your requirement.</li>
+  <li>The phases added before the "MessageOut" phase are known as "Operation
+    phases".</li>
+
+  <p><strong>Note :</strong> If you closely look at the default axis2.xml
you
+  will be able to clearly identify that.</p>
+</ul>
+<a name="References"></a>
+<h3>Module References</h3>
+
+<p>If you want to engage a module, system wide, you can do it by adding top
+level module element in axis2.xml. It should look like following:</p>
+<pre>&lt;module ref="addressing"/&gt;  </pre>
+</source>
+<p><strong>ref:</strong> the module name which is going to be engage, system
+wide.</p>
+<a name="Listeners"></a>
+<h3><strong>Listeners (Observers)</strong></h3>
+
+<p>In Axis2, AxisConfiguration is observable so that one can register
+observers into that, and they will be automatically informed whenever a
+change occurs in AxisConfiguration. In the current implementation, the
+observers are informed of the following events:</p>
+<ul>
+  <li>Deploying a Service</li>
+  <li>Removing a service</li>
+  <li>Activate/Inactivate Service</li>
+  <li>Module deploy</li>
+  <li>Module remove</li>
+</ul>
+Registering Observers is very useful for additional features such as RSS feed
+generation which will provide service information to subscribers. The correct
+way of registering observers should be like below:
+<pre>&lt;listener class="org.apache.axis2.ObserverIMPL"&gt;
+    &lt;parameter name="RSS_URL" &gt;http://127.0.0.1/rss&lt;/parameter&gt;
+  &lt;/listener&gt;</pre>
+</source>
+<p><strong>class:</strong> Represents an Implementation class of observer,
+and it should be noted that the implementation class should implement
+AxisObserver interface, and the class has to be available in the classpath.
+<a name="Service_Configuration"></a>
+</p>
+<h2><font>Service Configuration</font></h2>
+<ul>
+  <li><font>Writing services.xml</font></li>
+</ul>
+
+<p><font>The description of services are specified using services.xml. Each
+service archive file needs to have a services.xml in order to be a valid
+service and it should be available in the META-INF directory of the archive
+file. A very simple services.xml is shown below:</font></p>
+<source><pre><font>&lt;service name="name of the service" scope="name
of the scope" class="full qualifide name the service lifecycle class"   targetNamespace="target
namespase for the service"&gt;
+    &lt;description&gt; The description of the service  &lt;/description&gt;
 
+
+    &lt;transports&gt; 
+       &lt;transport&gt;HTTP&lt;/transport&gt;
+    &lt;/transports&gt;
+    
+    &lt;schema schemaNamespace="schema namespace"/&gt; 
+     
+    &lt;messageReceivers&gt;
+            &lt;messageReceiver mep="http://www.w3.org/2004/08/wsdl/in-out"
+                             class="org.apache.axis2.rpc.receivers.RPCMessageReceiver"/&gt;
+    &lt;/messageReceivers&gt;
+     
+     &lt;parameter name="ServiceClass" locked="xsd:false"&gt;org.apache.axis2.sample.echo.EchoImpl&lt;/parameter&gt;
+    
+    &lt;operation name="echoString" mep="operation MEP"&gt; 
+        &lt;actionMapping&gt;Mapping to action&lt;/actionMapping&gt;
+        &lt;module ref=" a module name "/&gt;
+        &lt;messageReceiver class="org.apache.axis2.receivers.RawXMLINOutMessageReceiver"/&gt;
+    &lt;/operation&gt;
+  &lt;/service&gt;</font></pre>
+</source>
+<p><font><strong>name</strong>: The service name will be the name
of the
+archive file, if the .aar file contains only one service, or else the name of
+the service will be the name given by the name attribute.</font></p>
+
+<p><strong>scope</strong>: (Optional Attribute) The time period in which
runtime information of
+deployed services will be available. Scope is of several types-
+"Application", "SOAPSession", "TransportSession", "Request". The default value (if you dont
put any value) will be "Request"</p>
+
+<p><strong>class</strong>: (Optional attribute) To specify the full qualified
name of the service lifecycle implementation class.
+ ServiceLifeCycle class is usefull when you want to do some tasks when the system start and
when it shutdowns.
+
+</p> 
+
+<p><strong>targetNamespace</strong>: (Optional Attribute) Target name space
of the service, and
+this value will be used when generating the wsdl , if you do not specify this value , then
the value will be calculated from the package name of the service impl class</p>
+
+<p><font><strong>description</strong>: This is an optional element
if you
+want to display any description about the service via Axis2 web-admin module,
+then the description can be specified here.</font></p>
+
+<p><strong>transports</strong> : The transports that the service is going
to
+be exposed to. This is an optional element. If the transport element is not
+present then the service will be exposed in all the transports available in
+the system. The transport child element is there to specify the transport
+prefix (the name of the transport specified in axis2.xml).</p>
+
+<p><b>parameters:</b> A services.xml can have any number of top level
+parameters and all the specified parameters will be transformed into service
+properties in the corresponding AxisService. There is a compulsory parameter
+in a services.xml called ServiceClass which specifies the java class which
+really does the job and the class will be loaded by the MessageReceiver.</p>
+
+<p><b>operations :</b> If the service impl class is java, then all the
public
+methods in that service will be exposed and if the user wants to override it
+then he has to add the "operation" tag and override it. In the case of
+non-Java or if you do not have a service class, then all the operations the
+user wants to expose by the service has to be indicated in the services.xml
+and the correct way of specifying is as follows:</p>
+<pre>    &lt;operation name="echoString"&gt;
+        &lt;module ref=" a module name "/&gt;
+        &lt;messageReceiver class="org.apache.axis2.receivers.RawXMLINOutMessageReceiver"/&gt;
+    &lt;/operation&gt;</pre>
+</source>
+<p>The only compulsory attribute here is "name", which represents the
+operation name that is going to be exposed. Any operation can contain module
+references as well as any number of parameters. The most interesting thing is
+that one can register custom message receivers per operation, then the
+registered message receiver will be the message receiver for the
+corresponding operation. If one does not specify the message receiver, then
+the default message receiver will do the job. <br>
+<a name="Module_Configuration"></a></p>
+
+<h2>Module Configuration</h2>
+<ul>
+  <li>Writing module.xml</li>
+</ul>
+
+<p>The description of the module is specified using the module.xml. Each
+module archive file needs to have a module.xml in order to be a valid module,
+and it should be available in the META-INF directory of the archive file. <br>
+</p>
+
+<p>A very simple module.xml is shown below:</p>
+<pre>&lt;module class="org.apache.module.Module1Impl"&gt;
+    &lt;InFlow&gt;
+        .
+        .
+    &lt;/InFlow&gt;
+    &lt;OutFlow&gt;
+        .
+        .
+    &lt;/OutFlow&gt;
+
+    &lt;OutFaultFlow&gt;
+        .   
+        .
+    &lt;/OutFaultFlow&gt;
+
+    &lt;InFaultFlow&gt;
+        .         
+        .
+    &lt;/InFaultFlow&gt;
+
+    &lt;operation name="creatSeq" mep="MEP_URI_IN_OUT"&gt;
+        &lt;messageReceiver class="org.apache.axis2.receivers.RawXMLINOutMessageReceiver"/&gt;
+        &lt;parameter name="para1" locked="xsd:true"&gt;10&lt;/parameter&gt;
+    &lt;/operation&gt;
+&lt;/module&gt;</pre>
+</source>
+<p><strong>class:</strong> This is an optional attribute which indicates
the
+module implementation class. A module may or may not contain a module
+implementation class since the module can also be a collection of handlers.
+If a module contains an implementation class which implements the
+org.apache.axis2.modules.Module interface where at the deployment time its
+<code>init();</code> method will be called.</p>
+
+<p><b>parameter:</b> A module can contain any number of parameters and
all
+the listed parameters in the module.xml will be transformed into
+corresponding AxisModule of the module.</p>
+
+<p><b>flow: </b>Defining of handlers in a module has to be done inside
flows,
+and there are four types of flows as listed below.</p>
+
+<p>It is possible to add any number of handlers into a flow and those
+handlers will be available in corresponding chains at the runtime when they
+are engaged .</p>
+<ul>
+  <li>InFlow</li>
+  <li>OutFlow</li>
+  <li>InFaultFlow</li>
+  <li>OutFaultFlow</li>
+</ul>
+
+<p><b>operations: </b> If a module wants to add an operation when it is
+engaged into a service it can be done by adding an operation tag in
+module.xml and the way of specifying the operation is the same as operation
+in services.xml.</p>
+
+<p><b>handler:</b> The Handler element consists of compulsory and optional
+attributes and the way of defining a handler will look as follows:</p>
+<pre>&lt;handler name="handler1" class="handlerClass "&gt;
+            &lt;order phase="userphase1" /&gt;
+ &lt;/handler&gt;</pre>
+</source>
+<p><b><i>Compulsory Attributes</i></b> <br>
+<b>name:</b> name of the handler<br>
+<b>class:</b> handler implementation class<br>
+<b>phase:</b> name of the phase that the handler should stay in the execution
+chain <br>
+<br>
+<i><b>Optional Attributes :</b></i><br>
+<b>phaseLast:</b> to indicate the handler is last handler of the phase<br>
+<b>phaseFirst:</b> to indicate the handler is first handler of the phase.<br>
+<b>before :</b> the handler should be invoked before the handler specified by
+the before handler<br>
+<b>after:</b> the handler should be invoked after the handler specified by
+the after handler<br>
+</p>
+
+<p><br>
+</p>
+
+</body>
+</html>



---------------------------------------------------------------------
To unsubscribe, e-mail: axis-cvs-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-cvs-help@ws.apache.org


Mime
View raw message