Return-Path: Delivered-To: apmail-ws-axis-dev-archive@www.apache.org Received: (qmail 79074 invoked from network); 9 Mar 2006 05:41:01 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 9 Mar 2006 05:41:01 -0000 Received: (qmail 87598 invoked by uid 500); 9 Mar 2006 05:41:00 -0000 Delivered-To: apmail-ws-axis-dev-archive@ws.apache.org Received: (qmail 87362 invoked by uid 500); 9 Mar 2006 05:40:59 -0000 Mailing-List: contact axis-cvs-help@ws.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list axis-cvs@ws.apache.org Received: (qmail 87351 invoked by uid 500); 9 Mar 2006 05:40:59 -0000 Delivered-To: apmail-ws-axis2-cvs@ws.apache.org Received: (qmail 87348 invoked by uid 99); 9 Mar 2006 05:40:59 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 08 Mar 2006 21:40:59 -0800 X-ASF-Spam-Status: No, hits=-9.4 required=10.0 tests=ALL_TRUSTED,NO_REAL_NAME X-Spam-Check-By: apache.org Received: from [209.237.227.194] (HELO minotaur.apache.org) (209.237.227.194) by apache.org (qpsmtpd/0.29) with SMTP; Wed, 08 Mar 2006 21:40:58 -0800 Received: (qmail 78799 invoked by uid 65534); 9 Mar 2006 05:40:37 -0000 Message-ID: <20060309054037.78797.qmail@minotaur.apache.org> Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: svn commit: r384437 - /webservices/axis2/trunk/java/xdocs/latest/axis2config.html Date: Thu, 09 Mar 2006 05:40:37 -0000 To: axis2-cvs@ws.apache.org From: deepal@apache.org X-Mailer: svnmailer-1.0.7 X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N 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) - -

Global Configuration

Writing axis2.xml

@@ -38,22 +37,20 @@

Listeners (Observers)

Parameter
+

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

+
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; 

+done as follows;
  
 <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.
 
-Transport Senders

+
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: 

+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>
@@ -86,9 +85,11 @@
 more parameters, and if there is any then it can be accessed via
 corresponding transport sender.
 
-Phase Order

+
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; 

+order element and it will be look like below;
+
+
 <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">
@@ -159,9 +160,11 @@
 
 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; 

+specifying phase inside phaseOrder has to be done as follows;
+
+
  <phase name="TransportIn"/>
-name: Name of the phase. 

+name: Name of the phase. 

 There are number of things that one has to keep in mind when changing
 pahseOrder,
 
@@ -174,19 +177,26 @@
 
   If you closely look at the default axis2.xml can clearly identify that.
 
-Module References

+
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 element in axis2.xml.  It should be look like following:
+
+
 <module ref="addressing"/>  
 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
+
+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
 
   Deploying a Service
   Removing a service
-  Changing a service
+  Activate/Inactivate Service
+  Module deploy
+  Module remove
 
 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>
 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. 
 
-
 Service Configuration
 
   Writing services.xml
@@ -207,75 +217,80 @@
 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>
+file. 

+A very simple services.xml is shown below:
+<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>
-
-
-service name: the service name will be the name of the archive file.
-

-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.
+  </service>
+name: 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
+
+scope : Scope that the service need to be
+deployed and scope can be one of
+"Application","SOAPSession","TransportSession","Request";
+
+targetNamespace : Targtet name space of the
+service , and this value will be used when generation wsdl
+
+
+
+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.
+
+transports : 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)
 
-Parameter:

+
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>
-
-Compulsory attributes 

-name: name of the handler

-nlass: handler implementation class

-phase: name of the phase that the handler should stay in the execution chain
-

-

-Optional attributes :

-phaseLast: to indicate the handler is last handler of the phase

-phaseFirst: to indicate the handler is first handler of the phase.

-before : the handler should be invoked before the handler specified by before
-handler

-after:  the handler should be invoked after the handler specified by after
-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: 

+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.
+
+Operations

+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:
     <operation name="echoString">
         <module ref=" a module name "/>
         <messageReceiver class="org.apache.axis2.receivers.RawXMLINOutMessageReceiver"/>
-    </operation>
-
-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. 

+    </operation>

+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. 

+
 
-
 Module Configuration
 
   Writing module.xml
@@ -283,9 +298,11 @@
 
 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">
+has to be available in META-INF directory of the archive file. 

+A very simple module.xml is shown below:
+
+
+<module class="org.apache.module.Module1Impl">
     <inflow>
         .
         .
@@ -310,30 +327,26 @@
         <parameter name="para1" locked="xsd:true">10</parameter>
     </operation>
 </module>
-
-name: This is a compulsory attribute and which indicates the name of the
-module 

-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.
+
+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.
 
 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.
+AxisModule 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:
+Flow :
+
+Defining of handlers in a module has to done inside Flows , and there are
+four types of flows as listed below.
+
+ 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 .
 
   Inflow
   outflow
@@ -344,6 +357,32 @@
 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.
-

+
+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>
+
+Compulsory attributes 

+name: name of the handler

+nlass: handler implementation class

+phase: name of the phase that the handler should stay in the execution chain
+

+

+Optional attributes :

+phaseLast: to indicate the handler is last handler of the phase

+phaseFirst: to indicate the handler is first handler of the phase.

+before : the handler should be invoked before the handler specified by before
+handler

+after:  the handler should be invoked after the handler specified by after
+handler

+
+
+

+