You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by de...@apache.org on 2006/03/09 06:40:37 UTC
svn commit: r384437 -
/webservices/axis2/trunk/java/xdocs/latest/axis2config.html
Author: deepal
Date: Wed Mar 8 21:40:36 2006
New Revision: 384437
URL: http://svn.apache.org/viewcvs?rev=384437&view=rev
Log:
- docs update
Modified:
webservices/axis2/trunk/java/xdocs/latest/axis2config.html
Modified: webservices/axis2/trunk/java/xdocs/latest/axis2config.html
URL: http://svn.apache.org/viewcvs/webservices/axis2/trunk/java/xdocs/latest/axis2config.html?rev=384437&r1=384436&r2=384437&view=diff
==============================================================================
--- webservices/axis2/trunk/java/xdocs/latest/axis2config.html (original)
+++ webservices/axis2/trunk/java/xdocs/latest/axis2config.html Wed Mar 8 21:40:36 2006
@@ -18,8 +18,7 @@
(module.xml)</a></li>
</ul>
-<a name="Global_Configuration"/>
-<h2>Global Configuration</h2>
+<h2><a name="Global_Configuration">Global Configuration</a></h2>
<ul>
<li>Writing axis2.xml</li>
</ul>
@@ -38,22 +37,20 @@
<li>Listeners (Observers)</li>
</ul>
-<p><b>Parameter </b> <br/>
+<p><b>Parameter </b> <br>
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;</p>
-<source>
-<pre>
+<source><pre>
<parameter name="name of the parameter" >parameter value </parameter></pre>
</source>
-
-<p><b>Transport Receiver</b><br/>
+<p><b>Transport Receiver</b><br>
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; <p><source>
+done as follows;</p>
<pre>
<transportReceiver name="http" class="org.apache.axis2.transport.http.SimpleHTTPServer">
<parameter name="port" >6060</parameter>
@@ -69,12 +66,14 @@
any, then those parameters can be accessed via the corresponding transport
receiver.
-<p><b>Transport Senders</b><br/>
+<p><b>Transport Senders</b><br>
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: <p><source>
+specifying transport senders is as follows:</p>
+
+<p><source></p>
<pre>
<transportSender name="http" class="org.apache.axis2.transport.http.CommonsHTTPTransportSender">
<parameter name="PROTOCOL" locked="xsd:false">HTTP/1.0</parameter>
@@ -86,9 +85,11 @@
more parameters, and if there is any then it can be accessed via
corresponding transport sender.
-<p><b>Phase Order</b><br/>
+<p><b>Phase Order</b><br>
The specifying order of phases in execution chain has to be done using phase
-order element and it will be look like below; <p><source>
+order element and it will be look like below;</p>
+
+<p><source></p>
<pre><phaseOrder type="inflow">
<phase name="TransportIn"/>
.
@@ -128,11 +129,11 @@
</phase">
<!-- Sysem pre defined phases --">
<!-- After Postdispatch phase module author or or service author can add any phase he want --">
- <phase name="userphase1"/">
+ <phase name="OperationInPhase"/">
</phaseOrder">
<phaseOrder type="outflow"">
<!-- user can add his own phases to this area --">
- <phase name="userphase1"/">
+ <phase name="OperationOutPhase"/">
<!--system predefined phase--">
<!--these phase will run irrespective of the service--">
<phase name="PolicyDetermination"/">
@@ -140,11 +141,11 @@
</phaseOrder">
<phaseOrder type="INfaultflow"">
<!-- user can add his own phases to this area --">
- <phase name="userphase1"/">
+ <phase name="OperationInFaultPhase"/">
</phaseOrder">
<phaseOrder type="Outfaultflow"">
<!-- user can add his own phases to this area --">
- <phase name="userphase1"/">
+ <phase name="OperationOutFaultPhase"/">
<phase name="PolicyDetermination"/">
<phase name="MessageOut"/">
</phaseOrder"></pre>
@@ -159,9 +160,11 @@
<p>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; <p><source>
+specifying phase inside phaseOrder has to be done as follows;</p>
+
+<p><source></p>
<pre> <phase name="TransportIn"/></pre>
-</source>name: Name of the phase. <br/>
+</source>name: Name of the phase. <br>
There are number of things that one has to keep in mind when changing
pahseOrder,
<ul>
@@ -174,19 +177,26 @@
<ol>
If you closely look at the default axis2.xml can clearly identify that.</ol>
-<p><b>Module References</b><br/>
+<p><b>Module References</b><br>
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: <p><source>
+module element in axis2.xml. It should be look like following:</p>
+
+<p><source></p>
<pre><module ref="addressing"/> </pre>
</source>ref: the module name which is going to be engage, system wide.
-Listeners (Observers) In Axis2 AxisConfiguration is observable so that one
-can register observers into that, and they will be automatically informed
-whenever a change occurs in AxisConfiuration. In the current implementation
-the observers are informed of the following events
+
+<p><strong>Listeners (Observers)</strong></p>
+
+<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 AxisConfiuration. 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>Changing 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
@@ -196,9 +206,9 @@
</listener></pre>
</source>class: Represent an Implementation class of observer, and it should
be note that the implementation class should implement AxisObserver
-interface, and the class has to be available in the classpath.
+interface, and the class has to be available in the classpath. <a
+name="Service_Configuration"></a>
-<a name="Service_Configuration"/>
<h2><font>Service Configuration</font></h2>
<ul>
<li><font>Writing services.xml</font></li>
@@ -207,75 +217,80 @@
<p><font>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. <br/>
-A very simple services.xml is shown below: </font>
- </p>
- <source>
-<pre><font><service >
- <description> The description of the service </description>
-
- <parameter name="ServiceClass" locked="xsd:false">org.apache.axis2.sample.echo.EchoImpl</parameter>
+file. <br>
+A very simple services.xml is shown below:</font></p>
+<source><pre><font><service name="name of the service" scope="name of the scope" targetNamespace="target namespase for the service">
+ <description> The description of the service </description>
+
+ <transports>
+ <transport>HTTP</transport>
+ </transports>
- <operation name="echoString">
+ <schema schemaNamespace="schema namespace"/>
+
+ <messageReceivers>
+ <messageReceiver mep="http://www.w3.org/2004/08/wsdl/in-out"
+ class="org.apache.axis2.rpc.receivers.RPCMessageReceiver"/>
+ </messageReceivers>
+
+ <parameter name="ServiceClass" locked="xsd:false">org.apache.axis2.sample.echo.EchoImpl</parameter>
+
+ <operation name="echoString" mep="operation MEP">
+ <actionMapping>Mapping to action</actionMapping>
<module ref=" a module name "/>
<messageReceiver class="org.apache.axis2.receivers.RawXMLINOutMessageReceiver"/>
</operation>
- </service>
-</font></pre></source>
-
-<font>service name: the service name will be the name of the archive file.
-<br/>
-description: 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>
+ </service></font></pre>
+</source><font><em><strong>name</strong></em>: the service name will be the
+name of the archive file if the .aar file contains only one service else name
+of the service will be the name given by the name attribute</font>
+
+<p><em><strong>scope</strong></em> : Scope that the service need to be
+deployed and scope can be one of
+"Application","SOAPSession","TransportSession","Request";</p>
+
+<p><em><strong>targetNamespace</strong></em> : Targtet name space of the
+service , and this value will be used when generation wsdl</p>
+
+<p></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 , this is an optional element . If the transports element is not
+present then the service will be exposed in every transports available in the
+system. The transport child element is to specify the transport prefix (the
+name of the transport specified in axis2.xml)</p>
-<p><b>Parameter:</b><br/>
+<p><b>Parameter:</b><br>
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.</p>
-
-<p><b>Handler</b><br/>
-Handler element consists of compulsory and optional attribute and the way of
-defining a handler will be look like follows; <p><source>
-<pre><handler name="handler1" class="handlerClass ">
- <order phase="userphase1" />
- </handler>
-</pre></source>
-<b><i>Compulsory attributes</i></b> <br/>
-name: name of the handler<br/>
-nlass: handler implementation class<br/>
-phase: name of the phase that the handler should stay in the execution chain
-<br/>
-<br/>
-<i><b>Optional attributes :</b></i><br/>
-phaseLast: to indicate the handler is last handler of the phase<br/>
-phaseFirst: to indicate the handler is first handler of the phase.<br/>
-before : the handler should be invoked before the handler specified by before
-handler<br/>
-after: the handler should be invoked after the handler specified by after
-handler<br/>
-
-
-<p><b>Operations</b><br/>
-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: <p><source>
+corresponding AxisService. 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.</p>
+
+<p><b>Operations</b><br>
+If the service impl class is java then all the public methods in that service
+will be exposed and if user wnats to override then he has to add operation
+tag and override that . In the case of Non-Java case or if you does no thave
+service class then all the operations user wants to expose by the service has
+to be indicated in the services.xml and the correct way of specifying that
+should be as follows:</p>
<pre> <operation name="echoString">
<module ref=" a module name "/>
<messageReceiver class="org.apache.axis2.receivers.RawXMLINOutMessageReceiver"/>
- </operation>
-</pre></source>
-Only compulsory attribute here is name, which represent the operation name
-that is going to be exposed. Any operation can contains module references,
-any number of parameters. The most interesting is that one can register
-custom message receiver 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/>
+ </operation></pre>
+</source>Only compulsory attribute here is name, which represent the
+operation name that is going to be exposed. Any operation can contains module
+references, any number of parameters. The most interesting is that one can
+register custom message receiver 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>
-<a name="Module_Configuration"/>
<h2>Module Configuration</h2>
<ul>
<li>Writing module.xml</li>
@@ -283,9 +298,11 @@
<p>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. <br/>
-A very simple module.xml is shown below: <p><source>
-<pre><module name="module1" class="org.apache.module.Module1Impl">
+has to be available in META-INF directory of the archive file. <br>
+A very simple module.xml is shown below:</p>
+
+<p><source></p>
+<pre><module class="org.apache.module.Module1Impl">
<inflow>
.
.
@@ -310,30 +327,26 @@
<parameter name="para1" locked="xsd:true">10</parameter>
</operation>
</module>
-</pre></source>
-name: This is a compulsory attribute and which indicates the name of the
-module <br/>
-class: This is an optional attribute which indicate module implementation
-class, a module may or may not contain 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
-inteface where at the deployment time its init(); method will be called.
+</pre>
+</source>class: This is an optional attribute which indicate module
+implementation class, a module may or may not contain 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 inteface where at the deployment time its
+init(); method will be called.
<p><b>parameter:</b> 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.</p>
+AxisModule of the module.</p>
-<p><b>Flow :</b><br/>
-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) <br/>
-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. <br/>
-Valid flows:</p>
+<p><b>Flow :</b></p>
+
+<p>Defining of handlers in a module has to 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
+engaged .</p>
<ul>
<li>Inflow</li>
<li>outflow</li>
@@ -344,6 +357,32 @@
<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 operation tag in module.xml and the
way of specifying the operation is same as operation in services.xml.</p>
-<br/>
+
+<p><b>Handler</b><br>
+Handler element consists of compulsory and optional attribute and the way of
+defining a handler will be look like follows;</p>
+
+<p><source></p>
+<pre><handler name="handler1" class="handlerClass ">
+ <order phase="userphase1" />
+ </handler></pre>
+</source>
+<p><b><i>Compulsory attributes</i></b> <br>
+name: name of the handler<br>
+nlass: handler implementation class<br>
+phase: name of the phase that the handler should stay in the execution chain
+<br>
+<br>
+<i><b>Optional attributes :</b></i><br>
+phaseLast: to indicate the handler is last handler of the phase<br>
+phaseFirst: to indicate the handler is first handler of the phase.<br>
+before : the handler should be invoked before the handler specified by before
+handler<br>
+after: the handler should be invoked after the handler specified by after
+handler<br>
+</p>
+
+<p><br>
+</p>
</body>
</html>