axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dee...@apache.org
Subject svn commit: r154785 - in webservices/axis/trunk/java/xdocs: Axis2ArchitectureGuide.html images/TotalArch.png
Date Tue, 22 Feb 2005 04:27:33 GMT
Author: deepal
Date: Mon Feb 21 20:27:31 2005
New Revision: 154785

URL: http://svn.apache.org/viewcvs?view=rev&rev=154785
Log:
Formatting and added a total architecture digram

Added:
    webservices/axis/trunk/java/xdocs/images/TotalArch.png   (with props)
Modified:
    webservices/axis/trunk/java/xdocs/Axis2ArchitectureGuide.html

Modified: webservices/axis/trunk/java/xdocs/Axis2ArchitectureGuide.html
URL: http://svn.apache.org/viewcvs/webservices/axis/trunk/java/xdocs/Axis2ArchitectureGuide.html?view=diff&r1=154784&r2=154785
==============================================================================
--- webservices/axis/trunk/java/xdocs/Axis2ArchitectureGuide.html (original)
+++ webservices/axis/trunk/java/xdocs/Axis2ArchitectureGuide.html Mon Feb 21 20:27:31 2005
@@ -15,12 +15,13 @@
 <li>Core, (Engine, Engine Registry, Context,Handler Framework and Phase rules).</li>
 <li>Deployment.</li>
 <li>Axis Object Model (AXIOM).</li>
+<li>Handler Frame work and Phase Rules</li>
 <li>WSDL Object model.</li>
 <li>Client API.</li>
 </ol>
+<img alt="TotalArch (17K)" src="images/TotalArch.png" height="461" width="621" />
 
-
-<h2>Core of the Apache Axis2</h2>
+<h2>1. Core of the Apache Axis2</h2>
 <h3>The Big Picture</h3> 
 <p>Just like Axis 1.x family Axis2 is all about Message processing. It is important
to note that Axis2 is not just about encoding of the messages from Java to XML and vise versa.
Axis is a framework for the Web Service stack. All other components WS-Security, WS-RM ect
of the Web Service stack fits in to Axis via the extension mechanism of the the Apache Axis.
Apache Axis is a framework for Web Service Stack.Axis SOAP Message processing with always
start by running the information holder called MessageContext through the extension mechanism
of the Axis. This make the Axis and generic framework for All the Web Service add on services.</p>
 
@@ -96,11 +97,11 @@
 
 Most components of the Axis2 are stateless across the two invocations of the component. (The
Engine Registry is part of the Global Context.) . The developer should store all states in
the in one of the context while all contexts are accessible across the Message context which
would be passed through the Handlers in the Execution Chain. </li>
 </ul>
-<h2><a name=_Toc96747274>5 Deployment</a></h2>
+<h2><a name=_Toc96747274>2. Deployment</a></h2>
 <p>There are two types of deployment in Axis2, namely, Service Deployment and Module
Deployment. </p>
-<h2><a name=_Toc96747275>5.1 Module Deployment:</a></h2>
+<h3><a name=_Toc96747275>2.1 Module Deployment:</a></h3>
 <p>Axis2 provides a J2EE like deployment (an axis archive file has to be created and
dropped into the correct directory) for both modules and services. A user can deploy a module
or a service as an .aar file (module1.aar, service1.aar). Module hot deployment will not be
supported in M1, but will be supported in later releases. When the axis engine is started
all the .aar files in the WEB-INF/Repository/modules will get deployed. But if someone wants
to add a new module or service, a restarting of the engine is required after putting the new
.aar file in the above-mentioned folder.</p>
-<h2><a name=_Toc96747276>5.2 Service Deployment</a> </h2>
+<h3><a name=_Toc96747276>2.2 Service Deployment</a> </h3>
 <p>One of the key improvements introduced with Axis2 is the capability to hot deploy
web services. And in this M1 release only a J2EE like deployment is supported. That is, a
user has to create an axis archive file that includes all the files that he/she wants, and
drop that archive file into the WEB-INF/Repository/services directory. The following three
features are associated with service deployment; </p>
 <p> Hot Deployment </p>
 <p> Hot Un-Deployment </p>
@@ -135,11 +136,11 @@
 <p>5. The Repository updates the toDeploy and toUn-Deploy list </p>
 <p>6. The Repository informs the Listener to update the system </p>
 <p>7. The Listener informs the Deployment Engine to do the update (both deploy and
un-deploy) </p>
-<h2><a name=_Toc96747277>5.3 Scheduler</a></h2>
+<h3><a name=_Toc96747277>2.3 Scheduler</a></h3>
 <p>This component itself is a thread that performs a specific task forever in a given
time interval. In this case it periodically asks the Listener to listen to the file system
events. Here the file system is not the entire file system, it is only the sub directories
of WEB_INF/Repository where the modules and services reside.</p>
-<h2><a name=_Toc96747278>5.4 Listener</a></h2>
+<h3><a name=_Toc96747278>2.4 Listener</a></h3>
 <p><a name=head-37ea46b5942beaeb21bb4e06a14e4f7232d></a>As mentioned above
the Listener listens for file system events. In order to do this it checks both the modules
and services directories. Then it lists all the archive files in those two directories and
compares those against the repository to check if a new service(s) has been added or if any
service(s) has been modified. Then it informs DeploymentEngine to execute the required methods.
</p>
-<h2><a name=_Toc96747279>5.5 Repository</a> </h2>
+<h3><a name=_Toc96747279>2.5 Repository</a> </h3>
 <p>The Repository stores data about modules and services that have already been deployed.
At the initialization process this loads data about all the modules and services into the
module and service directories. It then deploys all those loaded modules and services. The
repository stores the name of the archive file and its last modified date. It is possible
to perform the following operations to the Repository; </p>
 <ul>
 <li>Add a new entry to the Repository 
@@ -149,13 +150,13 @@
 <p>In the add operation it checks whether the entry which is going to be added already
exists in the Repository. If so it ignores the operation else it will add the entry to the
Repository and add an entry to a list maintained in the DeploymentEngine (toDeploy list).
</p>
 <p>In the remove operation it directly removes the entry from the repository and adds
an entry to a list maintained in the DeploymentEngine (toUnDeploy list) </p>
 <p>In the modify operation it adds entries to both lists in the DeploymentEngine. </p>
-<h2><a name=_Toc96747280>5.6 DeploymentEngine</a><a name=head-c22edd7a305a0a97447ce349e4733cfa6d5></a></h2>
+<h3><a name=_Toc96747280>2.6 DeploymentEngine</a><a name=head-c22edd7a305a0a97447ce349e4733cfa6d5></a></h3>
 <p>The DeploymentEngine is the main component of the deployment sub component. It interacts
with the axis engine and the engine registry by updating the engine registry when a new service
is added or an existing service is removed. The deployment procedure is as follows;</p>
 <ul>
 <li>Check the toUnDeploy list. If it is not empty then remove the corresponding web
service from the engine registry. 
 <li>Check the toDeploy list. If it is not empty then add the corresponding web service
to the engine registry. 
 <li>For each and every item in the list that is passed to the DeploymentParser, create
a corresponding axis service object and add it to the engine registry. </li></ul>
-<h2><a name=_Toc96747281>5.7 DeploymentParser</a></h2>
+<h3><a name=_Toc96747281>2.7 DeploymentParser</a></h3>
 <p>The following three types of xml document are parsed by the DeploymentParser. Its
underlying parser is StAX.</p>
 <ul>
 <li>server.xml 
@@ -166,7 +167,7 @@
 <p>Parsing of service.xml is done as follows;</p>
 <p>The DeploymentEngine will create an AxisService object and pass that to the DeploymentParser.
Then it will be updated according to service.xml.</p>
 <p>Parsing module.xml is the same as above except for it been passed an AxisModule
object instead of an AxisService object. </p>
-<h2><a name=_Toc96747282>5.8 DeploymentEngine Initialization</a></h2>
+<h3><a name=_Toc96747282>2.8 DeploymentEngine Initialization</a></h3>
 <p>The Initialization process of the DeploymentEngine consists of the following steps:</p>
 <ul>
 <li>Checks whether server.xml is located in the repository directory. If it exists,
then it is loaded and parsed. If not then a default server.xml is created and placed in the
repository. 
@@ -178,7 +179,7 @@
 <li>If those modules are valid, the GlobalChains are built by the PhaseResolver (GlobalInChain
, GlobalOutChain , and GlobalFaultChain) using phase rules. </li></ul>
 <li>All the available services and modules will be added to the engineRegistry. 
 <li>The engineRegistry is returned. </li></ul>
-<h2><a name=_Toc96747283>5.9 Adding a new web service</a></h2>
+<h3><a name=_Toc96747283>2.9 Adding a new web service</a></h3>
 <p>Adding a new web service consists of the following steps;</p>
 <p>1. Unzip the .aar file and take its service.xml and parse it using the DeploymentParser.
</p>
 <p>2. While processing the service.xml an AxisService object gets created and that
object will be updated.</p>
@@ -186,8 +187,10 @@
 <p>4. Using the DeploymentEngine the service classLoader and the provider class will
be added to the AxisService object.</p>
 <p>5. The Handler chain will be built by resolving the phase rules.<br>(It should
be noted here that the Handler Chain consists of the HandlerMetadata which has all the phase
rules data and the actual executable handler )</p>
 <p>6. The created object will be added to the EngineRegistry. </p><br>
-<p><a name=_Toc96747284>6 AXIOM  AXIs Object Model</a></p>
-<h2><a name=_Toc96747285>6.1 Introduction</a></h2>
+<p>
+<h2><a name=_Toc96747284>3. AXIOM  AXIs Object Model</a>
+</h2></p>
+<h3><a name=_Toc96747285>3.1 Introduction</a></h3>
 <p>AXIOM (also know as OM <strong>O</strong>bject <strong>M</strong>odel)
is used to refer to the new and efficient XML info set model that has been developed for Axis2.
Most of the XML object models used today are based on two major methods, namely;</p>
 <ol>
 <li>DOM based  where the whole document is parsed and held in the memory 
@@ -198,7 +201,7 @@
 <p>AXIOM interacts with the outside world using the StAX API, that means it serializes
and de-serializes using the StAX writer and StAX reader interfaces.</p>
 <p><img height=217 src="images/archi005.jpg" width=552 border=0 DESIGNTIMEURL="images/archi005.jpg"></p>
 <p>Since most of the data binding tools support SAX based interfaces, AXIOM comes with
an adapter to be used between StAX and SAX.</p>
-<h2><a name=_Toc96747286></a><a name=_Toc94950521>6.2 High Level
Architecture</a></h2>
+<h3><a name=_Toc96747286></a><a name=_Toc94950521>3.2 High Level
Architecture</a></h3>
 <table align=left>
 <tbody>
 <tr>
@@ -223,8 +226,8 @@
 <td></td>
 <td><img height=246 src="images/archi007.jpg" width=420 DESIGNTIMEURL="images/archi007.jpg"></td></tr></tbody></table><br>Therefore
one can find a factory to create OM objects, which will help to switch between different implementations
of the object model. 
 <p></p>
-<p><a name=_Toc96747287>7 Handler Frame work and Phase Rules</a> </p>
-<h2><a name=_Toc96747288>7.1 Phase</a></h2>
+<p><h2><a name=_Toc96747287>4. Handler Frame work and Phase Rules</a>
</h2></p>
+<h3><a name=_Toc96747288>4.1 Phase</a></h3>
 <p>Phase is a logically ordered collection of handlers. The handler inside a phase
is ordered by phase rules. By using phase rules a user can specify where the handler should
be logically placed. Some of the valid attributes associated with phase rules are listed in
the following table :</p>
 <table border=1>
 <tbody>
@@ -262,7 +265,7 @@
 <p>** - valid phase is a phase that is listed in the server.xml. If the phase name
is not there then the phase name is not a valid phase.</p>
 <p>*** - If both the PhaseFirst and PhaseLast attributes of some handler are true,
then the case phase only has one handler. </p>
 <p>N:B : If the user is going to use handlers and attributes as before, then there
is no need to use PhaseFirst and PhaseLast because those are ignored by the rule engine.</p>
-<h2><a name=_Toc96747289>7.2 Handler chain</a></h2>
+<h3><a name=_Toc96747289>4.2 Handler chain</a></h3>
 <p>The Handler chain is a collection of phases and handlers. The order of phases in
the chain is described in server.xml. One service can have three handler chains;</p>
 <ol>
 <li>Inflow 
@@ -274,30 +277,30 @@
 <li>Corresponding flow of service.xml 
 <li>If there are any references to modules then the handlers from correspondence flow.

 <li>Operation specific handlers corresponding flow </li></ul></ol>
-<h1><a name=_Toc96747290>8 WSDL Object model</a></h1>
+<h2><a name=_Toc96747290>5 WSDL Object model</a></h2>
 <p>WSDL Module of Axis2 was architected with both WSDL version 1.1 and version 2.0
Component model in mind. The entire architecture of the aforesaid Module is built around an
Object Model called WSDL Object Model which will be referred to as WOM here fourth. </p>
-<h2><a name=_Toc96747291>8.1 Overview of the Axis2 WSDL Module</a> </h2>
+<h3><a name=_Toc96747291>5.1 Overview of the Axis2 WSDL Module</a> </h3>
 <p>WSDL Module can be mainly broken down into two major functionalities: </p>
 <ul>
 <li>Service Description Functionality. 
 <li>WSDL Processing functionality(e.g. WSDL2Java, WSDL24J, Java2WSDL) </li></ul>
 <p>Service Description will provide an API to the Axis2 Engine that will expose the
sufficient statistics about the web service that has been described in the WSDL file. WSDL
Processing basically involves WSDL2Java, WSDL24J, and Java2WSDL. Following sections will give
a further overview of each of the above functionalities. <br><br><img height=339
src="images/archi008.gif" width=579 border=0 DESIGNTIMEURL="images/archi008.gif"></p>
-<h2><a name=_Toc96747292>8.2 WOM</a></h2>
-<p>WOM is engineered based on WSDL 2.0 component model, but it does not restrict its
functionality to prior WSDL versions. Rather both WSDL 1.1 and WSDL 2.0 versions will be supported
on top of the WOM. WOM consists of components such as Description, Interface, Service, etc,
as shown in the following diagram. All those Components extend from one super interface called
org.apache.wsdl.Component which will prove to be very useful in the implementation of the
Service Desc. <br><br></p>
-<p><img height=577 src="images/archi009.jpg" width=703 border=0 DESIGNTIMEURL="images/archi009.jpg"><br><br>WOM
is a runtime representation of the WSDL file and it will provide the web service description
functionality. As the following diagram illustrate the WOM will be the common Object model
that will be used in bothWSDL2Java and Java2WSDL functionality. This intermediary object model
ease the discussion since the WSDL processing can be broken down into the following four sub
modules. </p>
+<h3><a name=_Toc96747292>5.2 WOM</a></h3>
+<p>WOM is engineered based on WSDL 2.0 component model, but it does not restrict its
functionality to prior WSDL versions. Rather both WSDL 1.1 and WSDL 2.0 versions will be supported
on top of the WOM. WOM consists of components such as Description, Interface, Service, etc.
All those Components extend from one super interface called org.apache.wsdl.Component which
will prove to be very useful in the implementation of the Service Desc. <br><br></p>
+<p><br><br>WOM is a runtime representation of the WSDL file and it will
provide the web service description functionality. As the following diagram illustrate the
WOM will be the common Object model that will be used in bothWSDL2Java and Java2WSDL functionality.
This intermediary object model ease the discussion since the WSDL processing can be broken
down into the following four sub modules. </p>
 <ul>
 <li>WOM Builder. 
 <li>WSDL Emitter. 
 <li>Code Generator. 
 <li>Code Parser. </li></ul>
-<h2><a name=_Toc96747293>8.3 Service Description</a></h2>
+<h3><a name=_Toc96747293>5.3 Service Description</a></h3>
 <p>Service Description (also known as Service Desc) is an API by which the necessary
statistics will be made available to the Axis2 Engine at the runtime. </p>
 <p>The functionality of the WOM is very much similar to the functionality expected
from that of the Service Desc. Both behave as runtime description of the web service. Difference
is that WOM is a clean component model that is not dependent on Axis2 or any other SOAP Engine
and Service Desc is the Axis2 specific description of the web service. Thus it was necessary
that the Axis Service Desc to extend the WOM to incorporate the additional Axis specific deployment
information such as handlers, modules, providers, etc. The actual implementation of such extensions
has been achieved using the extension capability provided by the WOM itself. </p>
 <p>As mentioned above all the Components in the WOM extend from a super interface org.apache.wsdl.Component.
Service Desc makes use of the functionality provided by org.apache.wsdl.Component to interface
the WOM to behave as a Service Desc. org.apache.wsdl.Component has the following class diagram.
</p>
 <p><img height=121 src="images/archi010.jpg" width=487 border=0 DESIGNTIMEURL="images/archi010.jpg"><br><img
height=32 src="images/archi011.gif" width=32 border=0 DESIGNTIMEURL="images/archi011.gif"></p>
 <p>As the diagram illustrate the Component class provides the functionality of storing
properties. Since all the WSDL Components extend from this class directly or indirectly, this
functionality get inherited to all the WSDL Components. The Service Desc makes use of this
functionality to store Axis2 specific properties using the WOM. In that sense the Axis2 Service
Desc is a wrapper to the WOM. </p>
 <p>Following is the Class diagram of the top level component of the description Component
org.apache.axis.description.impl.AxisService. <br><br><img height=391 src="images/archi012.jpg"
width=292 border=0 DESIGNTIMEURL="images/archi012.jpg"><br><br>org.apache.axis.description.impl.AxisService
extends from the org.apache.wsdl.WSDLService and thus inherits the functionality of the org.apache.wsdl.WSDLService.
The Axis2 specific properties like provider, ServiceClass are stored using the org.apache.wsdl.Component
class which org.apache.wsdl.WSDLService extends from. The deployment Module will pick up the
deployed service and it will build the Service Desc and deploy in the Engine Registry. There
will be an underlying WOM for each Service Desc deployed in the Engine Registry. <br><img
height=350 src="images/archi013.gif" width=576 border=0 DESIGNTIMEURL="images/archi013.gif"><br><img
height=32 src="images/archi011.gif" width=32 border=0 DESIGNTIMEURL="images/archi011.gif"></p>
-<h2><a name=_Toc96747294>8.4 WSDL Processing</a></h2>
+<h3><a name=_Toc96747294>5.4 WSDL Processing</a></h3>
 <p>WSDL Processing can be identified as of operations performed on or performed using
the WOM. Such definition is made possible because of the intermediary object model i.e. WOM
always acts as an intermediary state. For example if WSDL2Java is considered: </p>
 <p>WSDL2Java = WSDL--&gt;WOM (WSDL2WOMBuilder), WOM--&gt;Java (Code Generation
Module). </p>
 <p>The point to note is that the above allows the WSDL--&gt;WOM (WSDL2WOMBuilder)
to be identified as an independent module, not tied to the WSDL2Java operation. There are
four such modules identified in the WSDL Processing Module of Axis2. </p>
@@ -306,9 +309,9 @@
 <li>WSDL Emitter. 
 <li>Code Generator. 
 <li>Code Parser. </li></ul>
-<h2><a name=_Toc96747295>8.5 WOM Builder Module</a></h2>
+<h3><a name=_Toc96747295>5.5 WOM Builder Module</a></h3>
 <p>WOM has an external building mechanism and it gets built by an external builder.
Since WOM is both WSDL 1.1 and WSDL 2.0 compliant it can get built from an either of the WSDL
versions. Currently WSDL1ToWOMBuilder uses the WSDL4J for the WSDL Parsing. In that implementation
the WOM gets populated from a WSDL4J object structure. Following is the class diagram of the
WOM build mechanism. <br><br><img height=240 src="images/archi014.jpg" width=633
border=0 DESIGNTIMEURL="images/archi014.jpg"><br><br>The WSDL2ToWOMBuilder
is to be implemented and the WSDL24J is going to be part of this implementation</p>
-<p><a name=_Toc96747296>9 Client API</a></p>
+<p><h2><a name=_Toc96747296>6. Client API</a></h2></p>
 <p>Types of Client programming models that Axis2 support: </p>
 <ol>
 <li>Synchronous Invocation 
@@ -319,24 +322,24 @@
 <p><strong><em>Call Class consist of following methods (Call API)</em></strong></p>
 <p><img height=200 src="images/archi016.jpg" width=582 border=0 DESIGNTIMEURL="images/archi016.jpg"></p><pre><strong><em>Callback
Interface</em></strong></pre><pre></pre><pre><img height=56
src="images/archi017.jpg" width=499 border=0 DESIGNTIMEURL="images/archi017.jpg"></pre><pre></pre><pre><strong><em>AsyncResult
</em></strong></pre><pre></pre><pre><img height=48
src="images/archi018.jpg" width=430 border=0 DESIGNTIMEURL="images/archi018.jpg"></pre><pre></pre><pre><strong><em>Correlator</em></strong></pre><pre></pre>
 <p><img height=73 src="images/archi019.jpg" width=539 border=0 DESIGNTIMEURL="images/archi019.jpg"></p>
-<h2><a name=_Toc96747297>9.1 sendAsync Invocation</a> </h2>
+<h3><a name=_Toc96747297>6.1 sendAsync Invocation</a> </h3>
 <p>This invocation is similar to fire and forget where a request is sent and an acknowledgement
is not expected. An invocation will consist of the following steps : </p>
 <p><img height=53 src="images/archi020.jpg" width=318 border=0 DESIGNTIMEURL="images/archi020.jpg"></p>
 <p><em>Code Snippet: </em></p><pre><img height=59 src="images/archi021.jpg"
width=318 border=0 DESIGNTIMEURL="images/archi021.jpg"></pre><pre></pre><pre><em>Sequence
diagram</em></pre><pre></pre><pre><img height=147 src="images/archi022.jpg"
width=434 border=0 DESIGNTIMEURL="images/archi022.jpg"></pre><pre></pre><pre></pre>
-<h2><a name=_Toc96747298>9.2 send Invocation</a></h2>
+<h3><a name=_Toc96747298>6.2 send Invocation</a></h3>
 <p>The service invocation is a void invocation. There is no return value, but there
is a wait for an acknowledgment or a SOAP Fault, It consists of the following steps :</p><pre>a
-&gt; call.send(SOAPEnvelope)</pre><pre>b -&gt; engine.send( ..)</pre><pre>c
-&gt; Send the SOAP message</pre>
 <p><em>Code Snippet: </em></p><pre>call.setTargetURL(URL)</pre><pre>call.setAction(String)</pre><pre>call.send(SOAPEnvelope)</pre><pre></pre>
 <p><em>Sequence diagram</em></p>
 <p><img height=149 src="images/archi023.jpg" width=416 border=0 DESIGNTIMEURL="images/archi023.jpg"></p>
-<h2><a name=_Toc96747299>9.3 sendReceive Invocation</a></h2>
+<h3><a name=_Toc96747299>6.3 sendReceive Invocation</a></h3>
 <p>The service method has a response and the communication happens synchronously using
a bi-directional protocol. The Client hangs until the response (or fault) is returned. </p><pre>a
-&gt; call.sendReceive(SOAPEnvelope)</pre><pre>b- &gt; engine.send (..)</pre><pre>c
-&gt; Send the SOAP message</pre><pre>d -&gt; Receive the response over
the synchronous transport</pre><pre>w -&gt; ProviderX will be called as the
last step in engine.receive(..) </pre><pre>e -&gt; provider returns </pre><pre>f
-&gt; Call hand over the response to the client</pre><pre></pre>
 <p><em>Code Snippet: </em></p><pre>call.setTargetURL(URL)</pre><pre>call.setAction(String)</pre><pre>SOAPEnvelope
env=call.sendReceive(SOAPEnvelope)</pre>
 <p><em>Sequence diagram</em></p>
 <p><img height=199 src="images/archi024.jpg" width=439 border=0 DESIGNTIMEURL="images/archi024.jpg"></p>
-<h2><a name=_Toc96747300>9.4 sendReceiveAsync Invocation</a></h2>
+<h3><a name=_Toc96747300>6.4 sendReceiveAsync Invocation</a></h3>
 <p>The service method has a response and the communication happens synchronously using
a bi-directional protocol. Client DOES NOT hangs until the response (or fault) is returned.
The Client uses a callback mechanism to retrieve the response. The Call API uses threads from
a thread pool for each invocation. </p><pre>a -&gt; call.sendReceiveAsync
(SOAPEnvelope, callbackObj)</pre><pre>p -&gt; correlator.addCorrelationInfor(msgID,allbackObjRef)</pre><pre>b-
&gt; engine.send (..)</pre><pre>c -&gt; Send the SOAP message</pre><pre>d
-&gt; Receive the response over the synchronous transport</pre><pre>w -&gt;
ProviderX will be called as the last step in engine.receive(..) </pre><pre>q -&gt;
correlator.getCorrelationInfo(msgID)</pre><pre>g -&gt; callbackObj.onComplete()</pre>
 <p><em>Code Snippet: </em></p><pre>call.setTargetURL(URL)</pre><pre>call.setAction(String)</pre><pre>call.setListenerTransport(http,
true) </pre><pre>call.sendReceiveAsync (SOAPEnvelope, Callback)</pre><pre></pre><pre><em>Sequence
diagram </em></pre><pre></pre><pre><img height=225 src="images/archi025.jpg"
width=648 border=0 DESIGNTIMEURL="images/archi025.jpg"></pre>
-<h2><a name=_Toc96747301></a><a name=head-6b6f0ac54f2e98ce920bf68485a695e1d2b></a>9.5
sendReceiveAsync Invocation with One way transport</h2>
+<h3><a name=_Toc96747301></a><a name=head-6b6f0ac54f2e98ce920bf68485a695e1d2b></a>6.5
sendReceiveAsync Invocation with One way transport</h3>
 <p>The service method has a response and the communication happens asynchronously using
a uni-directional protocol. The Client DOES NOT hang until the response (or fault) is returned.
The Client uses a callback mechanism to retrieve the response. The Call API uses threads from
a thread pool for each invocation. </p><pre>a -&gt; call.sendReceiveAsync
(SOAPEnvelope, callbackObj)</pre><pre>p -&gt; correlator.addCorrelationInfor(msgID,allbackObjRef)</pre><pre>b-
&gt; engine.send (..)</pre><pre>c -&gt; Send the SOAP message</pre><pre>r
-&gt; Receive the response by the listener</pre><pre>s -&gt; engine.receive(..)</pre><pre>w
-&gt; ProviderX will be called as the last step in engine.receive(..) </pre><pre>q
-&gt; correlator.getCorrelationInfo(msgID)</pre><pre>g -&gt; callbackObj.onComplete()</pre>
 <p><em>Code Snippet: </em></p><pre>call.setTargetURL(URL)</pre><pre>call.setAction(String)</pre><pre>call.setListenerTransport(http,
false)</pre><pre>call.sendReceiveAsync(SOAPEnvelope, Callback)</pre>
 <p><em>Sequence diagram </em></p>

Added: webservices/axis/trunk/java/xdocs/images/TotalArch.png
URL: http://svn.apache.org/viewcvs/webservices/axis/trunk/java/xdocs/images/TotalArch.png?view=auto&rev=154785
==============================================================================
Binary file - no diff available.

Propchange: webservices/axis/trunk/java/xdocs/images/TotalArch.png
------------------------------------------------------------------------------
    svn:mime-type = application/octet-stream



Mime
View raw message