axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dee...@apache.org
Subject svn commit: r366141 - in /webservices/axis2/trunk/java/xdocs: Axis2ArchitectureGuide.html images/archi-guide/phases.png
Date Thu, 05 Jan 2006 09:49:48 GMT
Author: deepal
Date: Thu Jan  5 01:49:38 2006
New Revision: 366141

URL: http://svn.apache.org/viewcvs?rev=366141&view=rev
Log:
-applying Chathras' patch
- modified archi-guide to cope with ServiceClient 

Modified:
    webservices/axis2/trunk/java/xdocs/Axis2ArchitectureGuide.html
    webservices/axis2/trunk/java/xdocs/images/archi-guide/phases.png

Modified: webservices/axis2/trunk/java/xdocs/Axis2ArchitectureGuide.html
URL: http://svn.apache.org/viewcvs/webservices/axis2/trunk/java/xdocs/Axis2ArchitectureGuide.html?rev=366141&r1=366140&r2=366141&view=diff
==============================================================================
--- webservices/axis2/trunk/java/xdocs/Axis2ArchitectureGuide.html (original)
+++ webservices/axis2/trunk/java/xdocs/Axis2ArchitectureGuide.html Thu Jan  5 01:49:38 2006
@@ -3,54 +3,92 @@
 <head>
   <meta http-equiv="content-type" content="text/html; charset=windows-1252">
   <title>Axis2 Architecture Guide</title>
-  <meta name="CREATED" content="20050916;22455288">
+  <meta content="20050916;22455288">
   <meta name="CHANGEDBY" content="Chamikara Jayalath">
   <meta name="CHANGED" content="20050918;22493797">
 </head>
 
 <body lang="en-US" dir="ltr">
-<h1>Axis2 Architecture Guide</h1>
+<h1 align="center">Axis2 Architecture Guide</h1>
+
+<p><i>Version 0.94</i></p>
+<i>Feedback: <a
+href="mailto:axis-dev@ws.apache.org">axis-dev@ws.apache.org</a></i>
 
 <h2>Contents</h2>
 <ul>
-  <li><p><a href="#bmBP">The Big Picture</a></p>
-  </li>
-  <li><p><a href="#bmInfoMod">Information Model</a></p>
-  </li>
-  <li><p><a href="#bmXML">XML Processing Model</a></p>
-  </li>
-  <li><p><a href="#bmSOAPPM">SOAP Processing Model</a></p>
-  </li>
-  <li><p><a href="#bmDeployment">Deployment</a></p>
-  </li>
-  <li><p><a href="#bmWSDL">WSDL and code generation</a></p>
+  <li><a href="#bmBP">The Big Picture</a></li>
+  <li><p><a href="#requirements">Requirement of Axis2</a></p>
   </li>
-  <li><p><a href="#bmDB">Data Binding</a></p>
-  </li>
-  <li><p><a href="#bmClientAPI">Client API</a></p>
-  </li>
-  <li><p><a href="#bmTransports">Transports</a></p>
+  <li><a href="#thearchi">Axis2, The Architecture</a>
+    <ul>
+      <li><p><a href="#bmInfoMod">Information Model</a></p>
+      </li>
+      <li><a href="#bmXML">XML Processing Model</a></li>
+      <li><p><a href="#bmSOAPPM">SOAP Processing Model</a></p>
+        <ul>
+          <li><a href="#default">Axis2 Default Processing Model</a></li>
+          <li><p><a href="#incomingsoap">Processing an Incoming SOAP
+            Message</a></p>
+          </li>
+          <li><a></a><a href="#outgoing">Processing of the Outgoing
+            Message</a></li>
+          <li><p><a href="#extending">Extending SOAP Processing Model</a></p>
+            <ul>
+              <li><a href="#extendingwithhandlers">Extending the SOAP
+                Processing Model with Handlers</a></li>
+              <li><p><a href="#extendingwithmodules">Extending the SOAP
+                Processing Model with Modules</a></p>
+              </li>
+            </ul>
+          </li>
+        </ul>
+      </li>
+      <li><a href="#bmDeployment">Deployment</a>
+        <ul>
+          <li><a href="#xmlfile">The <em>axis2.xml</em> file</a></li>
+          <li><p><a href="#servicearchive">Service Archive</a></p>
+          </li>
+          <li><a href="#modulearchive">Module Archive</a></li>
+        </ul>
+      </li>
+      <li><p><a href="#bmClientAPI">Client API</a></p>
+        <ul>
+          <li><a href="#oneway">One Way Messaging Support</a></li>
+          <li><p><a href="#requestresponse">Request Response Messaging
+            Support</a></p>
+          </li>
+        </ul>
+      </li>
+      <li><a href="#bmTransports">Transports</a></li>
+      <li><p><a href="#bmWSDL">Code generation</a></p>
+      </li>
+      <li><a href="#bmDB">Data Binding</a>
+        <ul>
+          <li><a href="#inegration">Integration with the code generation
+            engine</a></li>
+          <li><p><a href="#serial">Serialization and De-Serialization</a></p>
+          </li>
+        </ul>
+      </li>
+    </ul>
   </li>
 </ul>
 
-<p><br>
-<br>
-</p>
-
 <h2><a name="bmBP"></a>The Big Picture</h2>
 
-<p>Any architecture is a result of what that architecture should yield, the
-success of an architecture should be evaluated based on the requirements the
-architecture should meet. Let us start our journey into Axis2 looking at the
-requirements that are expected from Axis2.</p>
+<p>Any architecture is a result of what that architecture should yield. The
+success of an architecture should be evaluated based on the requirements
+expected to be met by that architecture. Let us start our journey into Axis2
+by looking at the requirements.</p>
 
-<h3>Requirement of Axis2</h3>
+<h2><a name="requirements">Requirement of Axis2</a></h2>
 
 <p>In the SOAP terminology, a participant who is taking part in a Web Service
 interaction is known as a SOAP Node. Delivery of a single SOAP Message is
 defined based on two participants, SOAP Sender and SOAP Receiver. Each SOAP
-Message is sent by SOAP Sender and received by SOAP Receiver, and single SOAP
-delivery is the most basic unit that builds the Web Service interactions.</p>
+Message is sent by SOAP Sender and received by SOAP Receiver. A single SOAP
+delivery is the most basic unit that builds the Web Service interaction.</p>
 
 <p>Each SOAP Node may be written in specific programming language, may it be
 Java, C++, .NET or Perl, the Web Services allow them to inter operate. This
@@ -60,158 +98,156 @@
 <p><img src="images/archi-guide/soap.gif" name="Graphic1" align="bottom"
 width="691" height="319" border="0"></p>
 
-<p>Web Service middleware handles the complexity in SOAP messaging and lets the
-users work with the programming language they are accustomed to. Axis2
-allows java users to invoke Web Services using java representations,
-and handles the SOAP messaging behind the curtain.</p>
+<p>Web Service middleware handles the complexity in SOAP messaging and lets
+the users work with the programming language they are accustomed to. Axis2
+allows java users to invoke Web Services using java representations, and
+handles the SOAP messaging behind the curtain.</p>
 
-<p>Axis2 handles SOAP processing along with numerous other tasks,
-this makes the life of the Web Service developer a whole lot easier. Following are the
+<p>Axis2 handles SOAP processing along with numerous other tasks. This makes
+the life of the Web Service developer a whole lot easier. Following are the
 identified requirements:</p>
 <ol>
-  <li>
-    <p style="margin-bottom: 0in">Provide a framework to process the SOAP
+  <li><style="margin-bottom: 0in">Provide a framework to process the SOAP
     messages. The framework should be extensible and the users should be able
-    to extend the SOAP processing per service or per operation basis. Furthermore
-    it should be able to model different Message Exchange Patterns (MEP) using the
-    processing framework.</p>
-  </li>
-  <li>Ability to deploy a Web Services (with
-  or without WSDL)</li>
-  <li>Provide a Client API that can be used to
-    invoke Web Services. This API should support both the Synchronous and
-  Asynchronous programming models.</li>
-  <li>Ability to configure Axis2 and it's
-  components via deployment.</li>
+    to extend the SOAP processing per service or per operation basis.
+    Furthermore it should be able to model different Message Exchange
+    Patterns (MEPs) using the processing framework.</li>
+  <li><p>Ability to deploy a Web Services (with or without WSDL)</p>
+  </li>
+  <li>Provide a Client API that can be used to invoke Web Services. This API
+    should support both the Synchronous and Asynchronous programming
+  models.</li>
+  <li><p>Ability to configure Axis2 and it's components via deployment.</p>
+  </li>
   <li>Ability to send and receive SOAP messages with different
   transports.</li>
 </ol>
 
-<p>Apart from the above functionalities, performance in terms of
-memory and speed is a major consideration for Axis2. Axis2 Core Architecture
-is built on three specifications, WSDL, SOAP and WS-Addressing. Other
-specifications like JAX-RPC and SAAJ are layered on top of the Core
-Architecture. The WS-Policy might join the core specifications in the near
-future.</p>
-
-<h3>Axis2, the Architecture</h3>
+<p>Apart from the above functionalities, performance in terms of memory and
+speed is a major consideration for Axis2. Axis2 Core Architecture is built on
+three specifications- WSDL, SOAP and WS-Addressing. Other specifications like
+JAX-RP, SAAJ &amp; WS-Policy are layered on top of the Core Architecture.</p>
+
+<h2><a name="thearchi">Axis2, The Architecture</a></h2>
+Axis2 architecture lays out some principals to preserve the uniformity. They
+are as follows:
+<ul>
+  <li><p><style="margin-bottom: 0in">Axis2 architecture separates the logic
+    and the states. Code that does the processing is stateless inside Axis2.
+    This allows code to be executed freely by parallel threads.</p>
+  </li>
+  <li>All the information is kept in one information model allowing system to
+    be suspended and resumed.</li>
+</ul>
 
-<p>Now that we have looked at the requirements of the Axis2 we can direct our
-attention to the Architecture.</p>
+<p>Axis2 architecture is modular. Therefore Axis2 Framework is built up of
+core modules which collectively make up the core architecture of Axis2, and
+non-core modules that are layered on top of this core
+modules/architecture.</p>
 
-<p>Axis2 architecture lays out some principals to preserve the uniformity of
-the architecture. They are as follows.</p>
+<p>Core Modules:</p>
 <ul>
-  <li><p style="margin-bottom: 0in">Axis2 architecture separates the logic
-    and the states. The code that does the processing is stateless inside Axis2.
-    This allows the code to be executed freely by parallel threads.</p>
+  <li><style="margin-bottom: 0in"><a href="#bmInfoMod">Information Model</a>-
+    Axis2 defines a model to handle information and all states are kept in
+    this model. The model has a hierarchy for the information. The system
+    manages the life cycle of the objects in this hierarchy.</li>
+  <li><p><a href="#bmXML">XML processing Model</a>- Handling the SOAP Message
+    is the most important and most complex task. The efficiency of this is
+    the single most important factor that decides the performance. It makes
+    sense to delegate this task to a separate module allowing that
+    module(AXIOM) to provide a simple API for SOAP and XML info-set while
+    hiding the complexities of the efficient XML processing within the
+    implementation.</p>
+  </li>
+  <li><a href="#bmSOAPPM">SOAP Processing Model</a>- This controls the
+    execution of the processing. The model defines different phases the
+    execution would walk through, and the user can extend the Processing
+    Model at some specific places.</li>
+  <li><p><a href="#bmDeployment">Deployment Model</a>- Axis2 deployment model
+    allows the user to deploy services, configure the transports, extend the
+    SOAP Processing model per system, service or operation basis.</p>
+  </li>
+  <li><a href="#bmClientAPI">Client API</a>- This provides a convenient API
+    for users to communicate with web services using Axis2. There are set of
+    classes to interact with IN-OUT and IN-Only style Message Exchange
+    Patterns (MEPs) where those can be used to construct any other MEP.</li>
+  <li><p><a href="#bmTransports">Transports</a>- Axis2 define a transport
+    framework that enables the user to use different transports. The
+    transports fit into specific places in the SOAP processing model. The
+    implementation provides a few common transports and the user may write
+    new ones if and when it is needed.</p>
   </li>
-  <li>All the information is kept in one information model, this allows
-  the system to be suspended and resumed.</li>
 </ul>
-
-<p>Axis2 architecture is modular and is broken down into
-seven modules.</p>
-<ol>
-  <li><p style="margin-bottom: 0in">Information Model</p>
+Non-core Modules:
+<ul>
+  <li><a href="#bmWSDL">Code Generation</a>- Axis2 provides a code generation
+    tool that will generate server side and client side code along with a
+    test case. The generated code would simplify the service deployment and
+    the service invocation. This would increase usability of Axis2.</li>
+  <li><p><a href="#bmDB">Data Binding</a>- The basic client API of Axis2 lets
+    the users process SOAP at the infoset level where as data binding extends
+    it to make it more convenient to the users by encapsulating the infoset
+    layer and providing a programming language specific interface.</p>
   </li>
-  <li>XML processing Model</li>
-  <li>SOAP Processing Model</li>
-  <li>Deployment</li>
-  <li>WSDL and Code Generation</li>
-  <li>Client API</li>
-  <li>Transports</li>
-</ol>
-
-<p><img src="images/archi-guide/all.png" name="Graphic2"
-width="426" height="189" border="0" align="bottom" usemap="#Graphic2Map">
-  <map name="Graphic2Map">
-    <area shape="rect" coords="123,31,222,97" href="#bmInfoMod">
-    <area shape="rect" coords="239,62,319,134" href="#bmXML">
-    <area shape="rect" coords="127,112,218,177" href="#bmSOAPPM">
-    <area shape="rect" coords="12,39,89,95" href="#bmDeployment">
-    <area shape="rect" coords="0,108,94,156" href="#bmWSDL">
-    <area shape="rect" coords="350,31,426,86" href="#bmClientAPI">
-    <area shape="rect" coords="350,114,421,164" href="#bmTransports">
-  </map>
-</p>
-
-<p>Let us look in to the rationale behind each Module, and what each does.</p>
-
-<p>Axis2 defines a model to handle the information and all the states are
-kept in this model. The model has a hierarchy for the information and the
-system manages the life cycle of the objects in this hierarchy.</p>
-
-<p>Handling the SOAP Message is the most important and the most complex task,
-the efficiency of this is the single most important factor that decides the
-performance. It makes sense to delegate this task to a separate module, and
-that module(AXIOM) provides a simple API for SOAP and XML info-set  while
-hiding the complexities of the efficient XML processing within the
-implementation.</p>
+</ul>
+<map name="Graphic2Map">
+  <area shape="rect" coords="123,31,222,97" href="#bmInfoMod">
+  <area shape="rect" coords="239,62,319,134" href="#bmXML">
+  <area shape="rect" coords="127,112,218,177" href="#bmSOAPPM">
+  <area shape="rect" coords="12,39,89,95" href="#bmDeployment">
+  <area shape="rect" coords="0,108,94,156" href="#bmWSDL">
+  <area shape="rect" coords="350,31,426,86" href="#bmClientAPI">
+  <area shape="rect" coords="350,114,421,164" href="#bmTransports">
+</map>
 
-<p>SOAP Processing Model controls the execution of the processing, the model
-defines different phases the execution would walk through, and the user can
-extend the Processing Model at some specific places.</p>
-
-<p>Axis2 define a transport framework that enables the user to use different
-transports. The transports fit into specific places in the SOAP
-processing model. The implementation provides a few common transports and the user
-may write new ones if and when it is needed.</p>
-
-<p>Axis2 deployment model allows the user to deploy services, configure the
-transports, extend the SOAP Processing model per system basis, per service
-basis, and per operation basis.</p>
-
-<p>Finally Axis2 provides a code generation tool that will generate server
-side and client side code along with a test case. The generated code would
-simplify the service deployment and the service invocation. This would make
-the Axis2 easier to use.</p>
+<p><img src="images/archi-guide/all.png" name="Graphic2" width="426"
+height="189" border="0" align="bottom" usemap="#Graphic2Map"></p>
 
 <h2><a name="bmInfoMod"></a>Information Model</h2>
 
-<p>Information Model has two main hierarchies, the Contexts and
-Descriptions.</p>
+<p>Information Model has two main hierarchies-Contexts and Descriptions. This
+model is described in UML notations below.</p>
 
 <p><img src="images/archi-guide/contexts.png" name="Graphic3" align="bottom"
 width="400" height="443" border="0"></p>
 
-<p>This uses UML notations ( A ----&lt;&gt; B means B has 1 or more objects
-of A. A------&gt;B means the given relationship holds between A and B.)</p>
+<p>( A ----&lt;&gt; B says, B has 1 or more objects of A. A------&gt;B says,
+the given relationship holds between A and B.)</p>
 
 <p>The two hierarchies are connected as shown in the above figure. The
-Description hierarchy represents the static data. This data may be loaded from
-a configuration file that exists throughout the lifetime of
-Axis2. Examples for such data would be deployed Web Services, operations,
-etc. On the other hand, the context hierarchy holds more dynamic information
-about the things that have more than one instances (e.g.Message Context).</p>
+Description hierarchy represents the static data. This data may be loaded
+from a configuration file that exists throughout the lifetime of Axis2. For
+example, deployed Web Services, operations, etc. On the other hand, the
+context hierarchy holds more dynamic information about the things that have
+more than one instances (e.g.Message Context).</p>
 
 <p>These two hierarchies creates a model that provides the ability to search
 for key value pairs. When the values are searched at a given level, they are
 searched while moving up the hierarchy until a match is found. In the
-resulting model the lower levels overrides the values in the upper levels.
-For an example when a value is looked up at the Message Context and it is
-not found, it would be looked up at the Operation Context etc, up the
-hierarchy. The Search is first done up the hierarchy, and if starting point
-is a Context then it is search in the Description hierarchy as well.</p>
-
-<p>This allows the user to declare and override values, result being a very
-flexible configuration model. The flexibility could be the Achilles heel for
-the system, as the search, specially for something that does not exist is
-expensive, yet in the final analysis developers believe that the flexibility
-would serve better in this instant.</p>
+resulting model the lower levels override the values in the upper levels. For
+example, when a value is looked up in the Message Context and is not found,
+it would be looked up in the Operation Context etc, up the hierarchy. The
+Search is first done up the hierarchy, and if starting point is a Context
+then it is search in the Description hierarchy as well.</p>
+
+<p>This allows the user to declare and override values. Result being a very
+flexible configuration model. The flexibility could be the <em>Achilles</em>
+heel for the system as the search is expensive, specially for something that
+does not exist. Yet in the final analysis developers believe that the
+flexibility would serve better in this instant.</p>
 
 <table width="955" border="1" cellpadding="2" cellspacing="3">
   <col width="112"><col width="371"><col width="103"><col width="336"><tbody>
     <tr>
       <td width="112"><p>Configuration Context</p>
       </td>
-      <td width="371"><p>Holds the current state of execution. A deep copy of
+      <td width="371"><p>Holds the run time status. A deep copy of
         this would essentially make a copy of Axis2.</p>
       </td>
       <td width="103"><p>Axis Configuration</p>
       </td>
       <td width="336"><p>Holds all global configurations. Transports, global
-        modules, parameters and Services.</p>
+        modules, parameters and Services etc.</p>
       </td>
     </tr>
     <tr>
@@ -220,10 +256,10 @@
       <td width="371"><p>Holds information about a particular usage of the
         respective service group. The life of a Service Group Context starts
         when a user starts interacting with a service that belong to this
-        service group. This can be used to share information between services(in
-        the same service group) in a single interaction.</p>
+        service group. This can be used to share information between services
+        (within the same service group) in a single interaction.</p>
       </td>
-      <td width="103"><p>ServiceGroup Description</p>
+      <td width="103"><p>AxisServiceGroup</p>
       </td>
       <td width="336"><p>Holds deployment time information about a particular
         service group.</p>
@@ -232,12 +268,11 @@
     <tr>
       <td width="112"><p>Service Context</p>
       </td>
-      <td width="371"><p>This context is available throughout the usage of the
-        respective service. This can be used to share information between
-        several MEPs that belong to the same service, within a single
-        interaction.</p>
+      <td width="371"><p>This context is available throughout the usage of
+        the respective service. This can be used to share information between
+        several MEPs of the same service, within a single interaction.</p>
       </td>
-      <td width="103"><p>Service Description</p>
+      <td width="103"><p>AxisService</p>
       </td>
       <td width="336"><p>Hold the Operations and the service level
         configurations</p>
@@ -249,7 +284,7 @@
       <td width="371"><p>Holds the information about the current MEP
         instance, maintain the Messages in the current MEP etc.</p>
       </td>
-      <td width="103"><p>Operation Description</p>
+      <td width="103"><p>AxisOperation</p>
       </td>
       <td width="336"><p>Holds the operation level configurations</p>
       </td>
@@ -260,7 +295,7 @@
       <td width="371"><p>Holds all the information about the Message
         currently being executed.</p>
       </td>
-      <td width="103"><p>Message Description</p>
+      <td width="103"><p>AxisMessage</p>
       </td>
       <td width="336"><p>Do not hold any information as yet, but can be used
         as a future extension point.</p>
@@ -280,66 +315,65 @@
 
 <p>The architecture identified two basic actions a SOAP processor should
 perform, sending and receiving SOAP messages. The architecture provides two
-Pipes (also named 'Flows'), to perform these two basic actions. Axis Engine
-or the driver of Axis2 defines two methods send() and receive() to implement
-these two Pipes. The two pipes are named <i>In Pipe</i> and <i>Out Pipe</i>,
-and the complex Message Exchange Patterns are constructed by combining these two
-pipes.</p>
-
-<p>Extensibility of the SOAP processing model is provided through 
-Handlers. When a SOAP message is being processed the Handlers that are
-registered would be executed. The Handlers can be registered in global,
-service, or operation scopes and the final handler chain is calculated
-combining the Handlers from all the scopes.</p>
+Pipes ('Flows'), to perform these two basic actions. Axis Engine or the
+driver of Axis2 defines two methods send() and receive() to implement these
+two Pipes. The two pipes are named <i>In Pipe</i> and <i>Out Pipe</i>, and
+the complex Message Exchange Patterns (MEPs) are constructed by combining
+these two pipes.</p>
+
+<p>Extensibility of the SOAP processing model is provided through handlers.
+When a SOAP message is being processed the handlers that are registered would
+be executed. The handlers can be registered in global, service, or operation
+scopes and the final handler chain is calculated combining the handlers from
+all the scopes.</p>
 
-<p>The Handlers act as interceptors and they process parts of the SOAP
-message and provide add on services. Usually Handlers work on the SOAP
+<p>The handlers act as interceptors and they process parts of the SOAP
+message and provide add-on services. Usually handlers work on the SOAP
 headers yet they may access or change the SOAP Body as well.</p>
 
-<p>When a SOAP message is being sent through the Client API, an <i>Out Pipe</i> would
-begin, the <i>Out Pipe</i> invokes the Handlers and end with a Transport
-Sender that sends the SOAP message to the target endpoint. The SOAP message
-is received by a Transport Receiver at the target endpoint, which reads the
-SOAP message and starts the <i>In Pipe</i>. The In Pipe consists of handlers and 
-ends with the <a href="#mr">Message Receiver</a>, which consumes the SOAP
-message.</p>
+<p>When a SOAP message is being sent through the Client API, an <i>Out
+Pipe</i> would begin, the <i>Out Pipe</i> invokes the handlers and end with a
+Transport Sender that sends the SOAP message to the target endpoint. The SOAP
+message is received by a Transport Receiver at the target endpoint, which
+reads the SOAP message and starts the <i>In Pipe</i>. The <em>In Pipe</em>
+consists of handlers and ends with the <a href="#mr">Message Receiver</a>,
+which consumes the SOAP message.</p>
 
 <p>Above explained processing happens for each and every SOAP message
-exchanged. After processing one message Axis2 may decide to create other
-SOAP messages, in which case more complex message patterns emerge. However Axis2
-always view the SOAP message in terms of processing of a single message. 
-The combination of the messages are layered on top of that basic framework.</p>
-
-<p>The two pipes does not differentiate between the Server and the Client,
-the SOAP Processing Model handles the complexity and provides two abstract
-pipes to the user. The different areas or the stages of the
-pipes are given names, and according to the Axis2 slang those are named
-'Phases'. A Handler always runs inside a Phase, and the Phase provides a
-mechanism to specify the ordering of Handlers. Both Pipes have built in
-Phases, and both define the areas for 'User Phases' which can be defined by
-the user.</p>
+exchanged. After processing one message Axis2 may decide to create other SOAP
+messages, in which case more complex message patterns emerge. However Axis2
+always view the SOAP message in terms of processing a single message. The
+combination of the messages are layered on top of that basic framework.</p>
+
+<p>The two pipes does not differentiate between the Server and the Client.
+The SOAP Processing Model handles the complexity and provides two abstract
+pipes to the user. The different areas or the stages of the pipes are given
+names, and according to the Axis2 slang those are named 'phases'. A Handler
+always runs inside a phase, and the phase provides a mechanism to specify the
+ordering of handlers. Both Pipes have built in phases, and both define the
+areas for 'User Phases' which can be defined by the user.</p>
 
-<p>Following figure shows the two pipes with their predefined Phases, the
-user defined Phases would fit in to the User Phases.</p>
+<p>Following figure shows the two pipes with their pre-defined phases &amp;
+user-defined phases. User-defined phases fit in to the User Phases.</p>
 
 <p><img src="images/archi-guide/phases.png" name="Graphic5" align="bottom"
 width="525" height="226" border="0"></p>
 
-<h3>Axis2 Default Processing Model</h3>
+<h3><a name="default">Axis2 Default Processing Model</a></h3>
 
-<p>Axis2 has the, some inbuilt Handlers that run in inbuilt Phases and they
-create the default configuration for the Axis2, we will be looking more in to
-how to extend the default processing Model in the next section.</p>
-
-<p>There are four special handlers defined in Axis2.</p>
-<ol>
-  <li>
-    <p style="margin-bottom: 0in">Dispatchers - Finds the service and the operation the SOAP
-    message is directed to, always run on the In-Pipe and inside the Dispatch
-    Phase. The in-built dispatchers dispatches to a particular operation depending on various conditions like WS-Addressing information, URI information, SOAP action information, etc., </p>
-  </li>
+<p>Axis2 has some inbuilt handlers that run in inbuilt phases and they create
+the default configuration for the Axis2. We will be looking more in to how to
+extend the default processing Model in the next section.</p>
+There are four special handlers defined in Axis2.
+<ol>
+  <li><style="margin-bottom: 0in">Dispatchers - Finds the service and the
+    operation the SOAP message is directed to. Dispatchers always run on the
+    <em>In-Pipe</em> and inside the Dispatch phase. The in-built dispatchers
+    dispatch to a particular operation depending on various conditions like
+    WS-Addressing information, URI information, SOAP action information,
+  etc.,</li>
   <li><p style="margin-bottom: 0in"><a name="mr"></a>Message Receiver -
-    Consume the SOAP Message and run on the Message Processing Phase in the
+    Consume the SOAP Message and run on the Message Processing phase in the
     inflow</p>
   </li>
   <li><p>Transport Sender - Send the SOAP message to the SOAP endpoint the
@@ -347,356 +381,357 @@
   </li>
 </ol>
 
-<h3>Processing an Incoming SOAP Message</h3>
+<h3><a name="incomingsoap">Processing an Incoming SOAP Message</a></h3>
 
 <p>Incoming SOAP Message is always received by a Transport Receiver waiting
-for the SOAP Messages, once the SOAP Message is arrived the transport Headers
+for the SOAP Messages. Once the SOAP Message arrives the transport Headers
 are parsed and a <a href="#messageContext">Message Context</a> is created for
-the incoming SOAP Message. The the <i>In Pipe</i> is executed with the
-Message Context. Let us see what would happen at the each Phase of the
-execution, this process my happen in either in the server or the Client,
-there is a special case of using the two way transport where the first four
-phases in the In-Phase most likely to do nothing.</p>
-<ol>
-  <li><p style="margin-bottom: 0in">Transport Phase - The Handlers in the
-    transport Phase are taken from the transport configuration associated,
-    they are executed according to the Phase rules.</p>
-  </li>
-  <li><p style="margin-bottom: 0in">Pre-Dispatch Phase- The Handlers that
-    goes there must be engaged globally (for all services) as the Service
-    does not known at this point. The best example for them would be,
-    Addressing Handlers and may be security Handlers if the Addressing
-    Headers are encrypted.</p>
-  </li>
-  <li><p style="margin-bottom: 0in">Dispatch Phase - The Dispatchers are run
-    in this Phases and find the Service if the service is not found
-    already.</p>
-  </li>
-  <li><p style="margin-bottom: 0in">Post-Dispatch Phase - This phase check
-    weather the service is found, if the service has not found by this point
-    the execution will halt and send a "service not found error". Policy
-    Determination Phase - This Phase does nothing for the time being, this is
-    placed for the implementing the Policy</p>
+the incoming SOAP Message. Then the <i>In Pipe</i> is executed with the
+Message Context.</p>
+
+<p>Let us see what happens at each phase of the execution. This process may
+happen either in the server or in the Client. There is a special case of
+using the Two-Way transport where the first four phases of the In-Phase most
+likely does nothing.</p>
+<ol>
+  <li><p style="margin-bottom: 0in">Transport Phase - The handlers in the
+    transport phase are taken from the transport configuration associated and
+    executed according to the phase rules.</p>
+  </li>
+  <li><p style="margin-bottom: 0in">Pre-Dispatch Phase- handlers in this
+    phase will be engaged globally since the service is not found yet. 
+   </p>
+  </li>
+  <li><p style="margin-bottom: 0in">Dispatch Phase - The Dispatchers run in
+    this phase and find the Service if the service is not found already.
+    <br> The psot condition of the dispatch phase work as follows;
+       That checks weather the service is found or not. If the service has not been found by
+    this point the execution will halt and send a "service not found
+    error".</p>
+    </p>
   </li>
-  <li><p style="margin-bottom: 0in">User Defined Phases - User defined Phases
-    are executed here.</p>
+  <li><p style="margin-bottom: 0in">User Defined Phases - Users are allowed
+    to engage their custom handlers here.</p>
   </li>
   <li><p style="margin-bottom: 0in">Message Validation Phase - Once the user
-    level execution is taken place, this Phase will validates has the SOAP
-    Message Processing has taken place correctly. For an example the must
-    understand processing would happen here.</p>
+    level execution has taken place this phase validates whether SOAP Message
+    Processing has taken place correctly.</p>
   </li>
-  <li><p>Message Processing Phase - The Business logic of the SOAP message,
-    executed here, the a <a href="#mr">Message Receiver</a> is registered
-    with a each Operation. The Message receiver associated with the each
-    operation would be executed as the last Handler of this Phase.</p>
+  <li><p>Message Processing Phase - The Business logic of the SOAP message is
+    executed here. A <a href="#mr">Message Receiver</a> is registered with
+    each Operation. This Message receiver (associated to the particular
+    operation) will executed as the last Handler of this phase.</p>
   </li>
 </ol>
 
-<p>There may be other handlers in the any of the these Phases, users may
-employ custom Handlers to override the mechanics in the each of these Phases.
-If there is a response message, that would be initiated by the <a
-href="#mr">Message Receiver</a>, yet the architecture is not aware of the
-response message and merely invoke the <a href="#mr">Message Receiver</a>.</p>
+<p><em>There may be other handlers in any of these phases. Users may use
+custom handlers to override the mechanics in the each of these phases.
+</em><em>.</em></p>
 
-<h3>Processing of the Outgoing Message</h3>
+<h3><a name="outgoing">Processing of the Outgoing Message</a></h3>
 
-<p>Out pipe is simpler because the Service and the Operation to dispatch is
-known by the time the pipe is executed. The Out pipe may be initiated by the
-<a href="#mr">Message Receiver</a> or the Client API implementation.</p>
+<p><em>Out Pipe</em> is simpler because the service and operation to dispatch
+is known by the time the pipe is executed. The <em>Out Pipe</em> may be
+initiated by the <a href="#mr">Message Receiver</a> or the Client API
+implementation.</p>
+Phases of the <em>Out Pipe</em> are described below:
 <ol>
-  <li><p style="margin-bottom: 0in">Message Initialize Phase - Fist Phase of
-    the out pipe, this serves as the placeholder for the custom Handlers</p>
-  </li>
-  <li><p style="margin-bottom: 0in">Policy Determination Phase - Just like in
-    the in-pipe this is not implemented and suppose to serve as a extension
-    point</p>
+  <li><p style="margin-bottom: 0in">Message Initialize Phase - Fist phase of
+    the <em>Out Pipe</em>. Serves as the placeholder for the custom
+    handlers</p>
   </li>
-  <li><p style="margin-bottom: 0in">User Phases - This executes Handlers in
-    user define Phases</p>
+  <li><p style="margin-bottom: 0in">User Phases - This executes handlers in
+    user defined phases</p>
   </li>
-  <li><p>Transports Phase - Execute any transport Handlers taken from the
-    associated transport configuration and the last handler would be a
-    transport Sender which would send the SOAP message to the target end
-    point</p>
+  <li><p>Transports Phase - Execute any transport handlers taken from the
+    associated transport configuration. The last handler would be a transport
+    Sender which would send the SOAP message to the target end point.</p>
   </li>
 </ol>
 
-<h3>Extending SOAP Processing Model</h3>
-
-<p>We discussed the default processing model of the Axis2, ability to extend
-the model has been the whole point of spending the energy on the SOAP
-processing model. We shall discuss the extension mechanism for the SOAP
-processing model now.</p>
+<h3><a name="extending">Extending SOAP Processing Model</a></h3>
 
-<p>Idea behind making each step of the SOAP processing in terms of Handlers
-(inbuilt ones we discuss earlier) and placing them in the Phases is to allow
-Handlers to be placed between those Handlers and to override or affect the
-default mechanics. There are two ways the to extend the SOAP Processing
-Model.</p>
+<p>Above we discussed the default processing model of Axis2. Now lets discuss
+the extension mechanism for the SOAP processing model. After all, the whole
+effort of making this SOAP engine/processing model was focused much on making
+it extendable.</p>
 
-<h4>Extending the SOAP Processing Model with Handlers</h4>
+<p>Idea behind introducing step wise processing of the SOAP message in terms
+of handlers &amp; phases is to allow easier modification of the processing
+order. The notion of phases makes it easier to place handlers in between
+other handlers enabling this modification on the default processing behavior.
+SOAP Processing Model can be extended with handler or Modules.</p>
 
-<p>The Handlers can specify the Phase they need to be run, further more they
-can specify the there location inside a phase via the following
-information.</p>
+<h4><a name="extendingwithhandlers">Extending the SOAP Processing Model with
+Handlers</a></h4>
+The handlers can specify the phase they need to be placed in. Furthermore
+they can specify their location inside a phase by providing phase rules.
+Phase rules will place a handler
 <ol>
-  <li><p style="margin-bottom: 0in">Handler should run as the first in the
-    phases</p>
-  </li>
-  <li><p style="margin-bottom: 0in">Handler should run as the last in the
-    Phases</p>
+  <li><style="margin-bottom: 0in">as the first handler in a phase.</li>
+  <li><p style="margin-bottom: 0in">or as the last handler in a phase.</p>
   </li>
-  <li><p style="margin-bottom: 0in">Handler should run before a given
-    Handlers</p>
+  <li><p style="margin-bottom: 0in">or before a given handler</p>
   </li>
-  <li><p>Handler should run after a Given Handler</p>
+  <li><p style="margin-bottom: 0in">or after a given handler</p>
   </li>
 </ol>
 
-<h4>Extending the SOAP Processing Model with Modules</h4>
+<h4><a name="extendingwithmodules">Extending the SOAP Processing Model with
+Modules</a></h4>
 
-<p>SOAP processing Model defines a logical entity called a module that
-encapsulates two entities, Handlers and Web Service Operations. The Handlers
-will act in the same way as explained in the first method.</p>
+<p>Axis2 defines an entity called a 'module' that can introduce handlers and
+web service operations. A Module in terms of Axis2 usually acts as a
+convenient packaging that include a set of handlers and an associated
+descriptor which includes the phase rules. Modules have the concept of being
+'available' and 'engaged'. 'Availability' means the module is present in the
+system, but has not been activated, i.e., the handlers included inside the
+module have not been used in the processing mechanism. When a module is
+'engaged' it becomes active and the handlers get placed in the proper phases.
+The handlers will act in the same way as explained in the previous section.
+Usually a module will be used to implement a WS-* functionality such as
+WS-Addressing.</p>
 
-<p>Apart from the extension mechanism based on the Handlers, the WS-*
-specifications suggest a requirement for add new Operations using modules.
-For an example once a user add a Reliable Messaging capability to a Service,
-the "Create Sequence" operation needs to be available to the service end
-point. This can be implemented by letting the Modules define the operations
-and once the module is engaged to a service the operations will be added to
+<p>Apart from the extension mechanism based on the handlers the WS-*
+specifications suggest a requirement for adding new operations. For example,
+once a user add a Reliable Messaging capability to a Service the "Create
+Sequence" operation needs to be available to the service end point. This can
+be implemented by letting the modules define the operations, and once the
+module is engaged to a service, the necessary operations will be added to
 that service.</p>
 
-<p>A service, operations or the system may engage a module, once the module
+<p>A service, operations or the system may engage a module. Once the module
 is engaged the handlers and the operations defined in the module are added to
-the entity that engages them. Modules can not be added while the Axis2 is
-running but later they will be available once the system is restarted.</p>
+the entity that engage them.</p>
+
+<p>Modules can not be added while the Axis2 engine is running, but they will
+be available once the system is restarted.</p>
 
-<h2><a name="bmDeployment"></a>Deployment</h2>
+<h2><a name="bmDeployment"></a>Deployment.</h2>
 
-<p>There deployment Model provides a concrete mechanism to configure Axis2.
-Deployment Model has four entities that provide the configuration.</p>
+<p>The Deployment Model provides a concrete mechanism to configure Axis2.
+This model has three entities that provide the configuration.</p>
 
-<h3>The <em>axis2.xml</em> file</h3>
+<h3><a name="xmlfile">The <em>axis2.xml</em> file</a></h3>
 
 <p>This file holds the global configuration for the client and server, and
-provide following information.</p>
+provide following information:</p>
 <ol>
   <li><p style="margin-bottom: 0in">The global parameters</p>
   </li>
   <li><p style="margin-bottom: 0in">Registered transports in and transport
     outs</p>
   </li>
-  <li><p style="margin-bottom: 0in">User defined Phase names</p>
+  <li><p style="margin-bottom: 0in">User defined phase names</p>
   </li>
-  <li><p style="margin-bottom: 0in">Modules that are engaged globally</p>
+  <li><p style="margin-bottom: 0in">Modules that are engaged globally (to all
+    services)</p>
   </li>
-  <li><p>Globally defines <a href="#mr">Message Receiver</a>s</p>
+  <li><p>Globally defined <a href="#mr">Message Receivers</a></p>
   </li>
 </ol>
 
-<h3>Service Archive</h3>
+<h3><a name="servicearchive">Service Archive</a></h3>
 
 <p>Service archive must have a <em>META-INF/services.xml</em> file and may
-contain the dependent classes. the <em>services.xml</em> file has following
+contain the dependent classes. The <em>services.xml</em> file has following
 information.</p>
 <ol>
   <li><p style="margin-bottom: 0in">Service level parameters</p>
   </li>
   <li><p style="margin-bottom: 0in">Modules that are engaged Service level</p>
   </li>
+  <li><p>Service Specific Message Receivers<a href="#mr">Message Receivers</a></p>
+  </li>
   <li><p>Operations inside the Service</p>
   </li>
 </ol>
 
-<h3>Module Archive</h3>
+<h3><a name="modulearchive">Module Archive</a></h3>
 
 <p>Module archive must have a <em>META-INF/module.xml</em> file and dependent
-classes the <em>module.xml</em> file has Module parameters and the Operations
-defined in the module.</p>
-
-<p>When the system started up the Axis2 ask the deployment model to create a
-Axis Configuration, the Deployment Model first find a <em>axis2.xml</em> file
-and build the global configuration. Then the Deployment check for the Module
-archives and then for the service archives, the corresponding services and
-Modules are added to the Axis Configuration. System will build Contexts on
-top of the Axis Configurations and the Axis2 is ready to send or receive the
-SOAP Message. The Hot deployment is allowed only for the Service and in that
-case a thread will check the repository repeatedly, and add the Service
-corresponds to the new found Service archives to the repository.</p>
-
-<h2><a name="bmWSDL"></a>WSDL and code generation</h2>
-
-<p>Although the basic objective of the code generation tool has not changed,
-the Code generation module of Axis2 has taken a different approach to
-generate code. Primarily the change is in the use of templates, namely XSL
-templates which gives the code generator the flexibility to generate code in
-multiple languages.</p>
-
-<p>The basic approach is to set the code generator to generate an XML and
-parse it with a template to generate the code file. The following figure
-shows how this shows up in the architecture of the tool.</p>
-
-<p><img src="images/archi-guide/CodegenArchitecture.jpg" name="Graphic6"
-align="bottom" width="478" height="218" border="0"></p>
-
-<p>The fact here is that it is the same information that is extracted from
-the WSDL no matter what code is generated. Code generator uses the WOM (WSDL
-Object Model) internally to manipulate the WSDL and passes that information
-to the emitter which emits an XML. the XML is then parsed with the relevant
-XSL to generate the code. No matter what the language, the process is the
-same except for the template that is being used</p>
-
-<h2><a name="bmDB"></a>Data Binding</h2>
+classes. The <em>module.xml</em> file has Module parameters and the
+Operations defined in the module.</p>
 
-<h3>Integration with the code generation engine</h3>
-
-<p>Axis2 M2 was released with code generation support but without data
-binding. The version 0.9 was shipped with data binding support with complete
-schema support. Such claim is made possible because of the fact that the data
-binding tool, xml-beans, has the full schema support. The original
-architecture of the code generation framework did not undergo significant
-changes because of the way that the code generation framework was originally
-designed. Data binding was incorporated as a pluggable extension to the code
-generation engine. Version 0.91 did not does not support SOAP encoding. It
-only supports RPC literal or document literal massages.</p>
-
-<p><img src="images/codegen.gif" name="Graphic7" align="bottom" width="406"
-height="467" border="0"></p>
-
-<h3>Serialization and De-Serialization</h3>
-
-<p>Xml-beans supports StAX API and AXIOM is based on a StAX API. Data binding
-in Axis2 is achieved through interfacing the AXIOM with the Xml-beans using
-the StAX API which is supported by both parties. At the time of the code
-generation there will be supporter classes for each WSDL operation that will
-have the utility methods that can de-serialize the from AXIOM to data bound
-object and serialize from data bound object to AXIOM. For example if the WSDL
-has an operation called "echoString", once the code is generated there will
-be an echoStringDatabindingSupporter.java class generated that will have
-methods that will look like the following.</p>
-
-<p>public static org.apache.axis2.om.OMElement
-toOM(org.soapinterop.xsd.EchoStringParamDocument param) : This method will
-handle the serialization.</p>
-
-<p>public static org.apache.xmlbeans.XmlObject
-fromOM(org.apache.axis2.om.OMElement param, java.lang.Class type) : This
-method will handle the de-serialization.</p>
-
-<p>public static org.apache.xmlbeans.XmlObject getTestObject(java.lang.Class
-type) : This will be a utility method that can be used to create sample
-objects of the given data bound object.</p>
+<p>When the system is starting up Axis2 ask the deployment model to create a
+Axis Configuration. Deployment Model first finds the <em>axis2.xml</em> file
+and build the global configuration. Then it checks for the module archives
+and then for the service archives. After which the corresponding services and
+modules are added to the Axis Configuration. System will build Contexts on
+top of the Axis Configurations and then Axis2 is ready to send or receive the
+SOAP Message. Hot deployment is only allowed for the service, in which case a
+thread will check the repository repeatedly, and then add the service
+corresponding to the new found service archives to the repository.</p>
 
 <h2><a name="bmClientAPI"></a>Client API</h2>
 
 <p>There are three parameters that decide the nature of the Web Service
 interaction.</p>
 <ol>
-  <li><p style="margin-bottom: 0in">Message Exchange Pattern</p>
+  <li><p style="margin-bottom: 0in">Message Exchange Pattern (MEP)</p>
   </li>
-  <li><p style="margin-bottom: 0in">The Behavior of the transport. Does it
-    act one-way or two way</p>
+  <li><p style="margin-bottom: 0in">The Behavior of the transport, whether
+    it's One-Way or Two-Way</p>
   </li>
-  <li><p>Synchronous/ Asynchronous behavior of the Client API</p>
+  <li><p style="margin-bottom: 0in">Synchronous/ Asynchronous behavior of the
+    Client API</p>
   </li>
 </ol>
 
 <p>Variations of the three parameters can result in indefinite number of
 scenarios, even though Axis2 is built on a core that support any messaging
 interaction, the developers were compelled to support only two most widely
-used Message Exchange Patterns.</p>
+used Message Exchange Patterns (MEPs).</p>
 
 <p>Two supported transports are One-Way and the Request-Response scenarios in
-the Client API, the implementation is based on a class called
-<code>MEPClient</code> and there are extensions for each Message Exchange
-Pattern that Axis2 Client API supports.</p>
-
-<h3>One Way Messaging Support</h3>
-
-<p>The One-Way support is provided by the <code>InOnlyMEPClient</code> and
-Axis2 provides a class called <code>MessageSender</code> that provides a much simpler
-interface for the user. The Axis2 supports HTTP/SMTP and TCP transports, in
-the case of the HTTP transport the return channel is not used and the HTTP
-202 OK is returned in the return Channel.</p>
+the Client API. The implementation is based on a class called
+<code>ServiceClient</code> and there are extensions for each MEP that Axis2
+Client API supports.</p>
+
+<h3><a name="oneway">One Way Messaging Support</a></h3>
+
+<p>The One-Way support is provided by the <code>fireAndForget</code> which provide by
+ <code>ServiceClient</code> that provides a much simpler interface for the user. 
+The Axis2 supports HTTP/SMTP and TCP transports. In the case of the HTTP transport
+ the return channel is not used and the HTTP 202 OK is returned in the return Channel.</p>
 
-<h3>Request Response Messaging Support</h3>
+<h3><a name="requestresponse">Request Response Messaging Support</a></h3>
 
 <p>The Request-Response support is provided by the
-<code>InOutMEPClient</code> and Axis2 provides a class called
-<code>Call</code> that provides a much simpler interface for the
-user. The Client API has four ways to configure a given Message Exchange</p>
+<code>sendReceive()</code> method in ServiceClient ,that provides a much simpler interface for the user. The
+Client API has four ways to configure a given Message Exchange</p>
 <ol>
   <li><p style="margin-bottom: 0in">Blocking or Non-Blocking nature - this
-    can be decided by using <code>invokeBlocking()</code> or
-    <code>invokeNonBlocking()</code> methods</p>
+    can be decided by using <code>sendReceive()</code> or
+    <code>sendReceiveNonBlocking()</code> methods</p>
   </li>
-  <li><p style="margin-bottom: 0in">Sender transport - transport use to send
+  <li><p style="margin-bottom: 0in">Sender transport - transport used to send
     the SOAP Message</p>
   </li>
   <li><p style="margin-bottom: 0in">Listener transport - transport the
     Response is received</p>
   </li>
-  <li><p>Use Separate Channel - does the response is send over a separate
-    transport connection or not, this can be false only when sender an
-    listener transport is same and is a two way transport.</p>
+  <li><p>Use Separate Channel - determines whether the response is send over
+    a separate transport connection or not. This can be false only when
+    sender and listener transport is same and is a Two-Way transport.</p>
   </li>
 </ol>
 
-<p>Depend on the values for the above four parameter, Axis2 behave
-differently</p>
+<p>Depending on the values of the above four parameter, Axis2 behave
+differently.</p>
 
-<h2><a name="bmTransports"></a>Transports</h2>
+<h2><a name="bmTransports"><em></em></a>Transports</h2>
 
-<p>Axis2 has two basic constructs for transports, named as Transport In
-Configuration and Transport Out Configuration. The <a
-href="#messageContext">Message Context</a> has two fields to put the input
-and the out put transport to be used. Axis behaves according to the transport
-that is specified in each of the fields.</p>
+<p>Axis2 has two basic constructs for transports, transport In Configuration
+and transport Out Configuration. These are accessed via the messages
+context.</p>
 
-<p>SOAP Message is arrived at the Server side, the incoming transport is
-decided by the Transport Listener that accepts the incoming SOAP Message. The
-transports for the subsequent SOAP Messages that are related to the first
-message, are decided based on the addressing parameters.</p>
+<p>The incoming transport is the transport via which the server side receives
+the message and the outgoing transport is decided based on the addressing
+information (wsa:ReplyTo and wsa:FaultTo). If addressing information is not
+available then the out going transport will be the same as the incoming
+one.</p>
 
-<p>At the Client Side the user is free to specify the transport to be used,
-as in the Server side the transport for the subsequent SOAP Messages are
-decided by the addressing.</p>
+<p>At the client side the user is free to specify the transport to be
+used.</p>
 
-<p>There Transport In Configuration and the Transport Out Configuration
-contains following information.</p>
+<p>Transport In Configuration and the transport Out Configuration contains
+following information.</p>
 <ol>
-  <li><p style="margin-bottom: 0in">Transport Sender in Out Configuration,
-    Transport Listener in the TransportIn Configuration</p>
+  <li><style="margin-bottom: 0in">Transport Sender for Out Configuration</li>
+  <li><p style="margin-bottom: 0in">Transport Listener for In
+    Configuration</p>
   </li>
   <li><p style="margin-bottom: 0in">Parameters of the transport</p>
   </li>
-  <li><p>Transport Handlers</p>
+  <li><p>Transport handlers</p>
   </li>
 </ol>
 
-<p>Transport Sender send the SOAP Message over a given transport, each and
-every transport Out Configuration should define a transport Sender that send
-the transport.</p>
+<p>Each and every transport Out Configuration defines a transport tender.
+Transport sender sends the SOAP Message over its transport.</p>
 
-<p>Transport Receiver waits for the SOAP Messages and for each SOAP Message
-that arrives, uses the <i>In Pipe</i> to process the SOAP Message.</p>
+<p>Transport receiver waits for the SOAP Messages and for each SOAP Message
+that arrives, it uses the <i>In Pipe</i> to process the SOAP Message.</p>
 
-<p>Axis2 Presently support the following transports</p>
+<p>Axis2 Presently support the following transports:</p>
 <ol>
-  <li><p style="margin-bottom: 0in">HTTP - The HTTP transport, the transport
-    Listener is a Servlet or a Simple HTTP server provided by Axis2. The
-    transport Sender uses sockets to connect and send the SOAP Message.
-    Currently we have the commons-HTTP-client based HTTP Transport sender as
-    the default transport</p>
-  </li>
+  <li><style="margin-bottom: 0in">HTTP - In HTTP transport the transport
+    listener is a servlet or org.apache.axis2.transport.http.SimpleHTTPServer
+    provided by Axis2. The transport sender uses commons-httpclient to
+    connect and send the SOAP Message.</li>
   <li><p style="margin-bottom: 0in">TCP - This is the most simplest
-    transport, but needed the addressing support to be functional.</p>
+    transport, but needs the WS - Addressing support to be functional.</p>
   </li>
-  <li><p>SMTP - This work off a single email account, Transport Receiver is a
-    tread that checks for emails in fixed time intervals.</p>
+  <li><p style="margin-bottom: 0in">SMTP - This works off a single email
+    account. Transport receiver is a thread that checks for emails in fixed
+    time intervals.</p>
   </li>
 </ol>
+
+<h2><a name="bmWSDL" id="bmWSDL"></a>Code generation</h2>
+
+<p>Although the basic objective of the code generation tool has not changed,
+the code generation module of Axis2 has taken a different approach to
+generate code. Primarily the change is in the use of templates, namely XSL
+templates which gives the code generator the flexibility to generate code in
+multiple languages.</p>
+
+<p>The basic approach is to set the code generator to generate an XML and
+parse it with a template to generate the code file. The following figure
+describes how this shows up in the architecture of the tool.</p>
+
+<p><img src="images/archi-guide/CodegenArchitecture.jpg" name="Graphic6"
+align="bottom" width="478" height="218" border="0"></p>
+
+<p>The fact here is that it is the same information that is extracted from
+the WSDL no matter what code is generated. Code generator uses the WOM (WSDL
+Object Model) internally to manipulate the WSDL and passes that information
+to the emitter which emits an XML. The XML is then parsed with the relevant
+XSL to generate the code. No matter what the language, the process is the
+same except for the template that is being used</p>
+
+<h2><a name="bmDB" id="bmDB"></a>Data Binding</h2>
+
+<h3><a name="inegration">Integration with the code generation engine</a></h3>
+
+<p>Axis2 M2 was released with code generation support but without data
+binding. The version 0.9 was shipped with data binding support with complete
+schema support. Such claim is made possible because of the fact that the data
+binding tool, xml-beans, has the full schema support. The original
+architecture of the code generation framework did not undergo significant
+changes because of the way that the code generation framework was originally
+designed. Data binding was incorporated as a pluggable extension to the code
+generation engine. Axis2 version 0.91 does not support SOAP encoding. It only
+supports RPC literal or document literal massages.</p>
+
+<p><img src="images/codegen.gif" name="Graphic7" align="bottom" width="406"
+height="467" border="0"></p>
+
+<h3><a name="serial">Serialization and De-Serialization</a></h3>
+
+<p>AXIOM is based on a StAX (Streaming API for XML) API. Xml-beans supports
+StAX API. Data binding in Axis2 is achieved through interfacing the AXIOM
+with the Xml-beans using the StAX API which is supported by both parties. At
+the time of the code generation there will be supporter classes for each WSDL
+operation that will have the utility methods that can de-serialize the from
+AXIOM to data bound object and serialize from data bound object to AXIOM. For
+example if the WSDL has an operation called "echoString", once the code is
+generated there will be an echoStringDatabindingSupporter.java class
+generated that will have methods that will look like the following.</p>
+
+<p><code>public static
+org.apache.axis2.om.OMElementtoOM(org.soapinterop.xsd.EchoStringParamDocument
+param)</code><code>// This method will handle the serialization.</code></p>
+
+<p><code>public static org.apache.xmlbeans.XmlObject
+fromOM(org.apache.axis2.om.OMElement param, java.lang.Class type) //This
+method will handle the de-serialization.</code></p>
+
+<p><code>public static org.apache.xmlbeans.XmlObject
+getTestObject(java.lang.Class type) /*This will be a utility method that can
+be used to create sample objects of the given data bound object.*/</code></p>
+
+<p></p>
 </body>
 </html>

Modified: webservices/axis2/trunk/java/xdocs/images/archi-guide/phases.png
URL: http://svn.apache.org/viewcvs/webservices/axis2/trunk/java/xdocs/images/archi-guide/phases.png?rev=366141&r1=366140&r2=366141&view=diff
==============================================================================
Binary files - no diff available.



Mime
View raw message