You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by he...@apache.org on 2005/06/06 12:10:12 UTC
svn commit: r180285 - in /webservices/axis/trunk/java: maven.xml
modules/samples/maven.xml xdocs/Axis2ArchitectureGuide.html
xdocs/images/archi-guide/CodegenArchitecture.JPG
Author: hemapani
Date: Mon Jun 6 03:10:08 2005
New Revision: 180285
URL: http://svn.apache.org/viewcvs?rev=180285&view=rev
Log:
add the echo sample to war
Added:
webservices/axis/trunk/java/xdocs/images/archi-guide/CodegenArchitecture.JPG (with props)
Modified:
webservices/axis/trunk/java/maven.xml
webservices/axis/trunk/java/modules/samples/maven.xml
webservices/axis/trunk/java/xdocs/Axis2ArchitectureGuide.html
Modified: webservices/axis/trunk/java/maven.xml
URL: http://svn.apache.org/viewcvs/webservices/axis/trunk/java/maven.xml?rev=180285&r1=180284&r2=180285&view=diff
==============================================================================
--- webservices/axis/trunk/java/maven.xml (original)
+++ webservices/axis/trunk/java/maven.xml Mon Jun 6 03:10:08 2005
@@ -133,25 +133,10 @@
</ant:lib>
<ant:classes dir="modules/core/conf">
<ant:include name="*.properties"/>
- </ant:classes>
+ </ant:classes>
+ <ant:webinf dir="modules/samples/target/toWar/"/>
</ant:war>
</goal>
-<!--
- <goal name="war-withsamples" prereqs="multiproject:install,init,create-lib">
- <ant:mkdir dir="target"/>
- <ant:war destfile="target/axis2.war" webxml="modules/core/conf/web.xml">
- <ant:fileset dir="modules/core/html"/>
- <ant:fileset dir="modules/samples/jsp"/>
- <ant:webinf dir="modules/samples/target/test-resources/samples"/>
- <ant:lib dir="target/lib">
- <ant:include name="*.jar"/>
- </ant:lib>
- <ant:classes dir="modules/core/conf">
- <ant:include name="*.properties"/>
- </ant:classes>
- </ant:war>
- </goal>
--->
<!-- to transforme htmls to xdocs -->
<preGoal name="xdoc:jelly-transform">
<attainGoal name="html2xdoc"/>
Modified: webservices/axis/trunk/java/modules/samples/maven.xml
URL: http://svn.apache.org/viewcvs/webservices/axis/trunk/java/modules/samples/maven.xml?rev=180285&r1=180284&r2=180285&view=diff
==============================================================================
--- webservices/axis/trunk/java/modules/samples/maven.xml (original)
+++ webservices/axis/trunk/java/modules/samples/maven.xml Mon Jun 6 03:10:08 2005
@@ -15,9 +15,9 @@
tofile="target/test-resources/samples/modules/addressing.mar"/>
<copy file="../addressing/target/addressing.mar"
tofile="target/test-resources/repository-client/modules/addressing.mar"/>
- <mkdir dir="target/echo"/>
+ <mkdir dir="target/toWar/services/"/>
<copy file="../core/target/echo/echo.aar"
- tofile="target/echo/echo.aar"/>
+ tofile="target/toWar/services/echo.aar"/>
</postGoal>
<postGoal name="test:test">
Modified: webservices/axis/trunk/java/xdocs/Axis2ArchitectureGuide.html
URL: http://svn.apache.org/viewcvs/webservices/axis/trunk/java/xdocs/Axis2ArchitectureGuide.html?rev=180285&r1=180284&r2=180285&view=diff
==============================================================================
--- webservices/axis/trunk/java/xdocs/Axis2ArchitectureGuide.html (original)
+++ webservices/axis/trunk/java/xdocs/Axis2ArchitectureGuide.html Mon Jun 6 03:10:08 2005
@@ -72,7 +72,7 @@
Description hierarchy represents more static data, that would exists
though out the lifetime of the Axis2, e.g. service, and operations.
They are the information goes on the WSDL interface and are abstract.
-On the other hand, the Context hold more dynamic information about this
+On the other hand, the Context hierarchy hold more dynamic information about this
instance, e.g. Message Context.</p>
<p>This two hierarchies created a model that provide ability to search
@@ -83,9 +83,10 @@
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. This allows user to
-declare and override values, and result in very flexible configuration
-model. The flexibility could be the Achilles heel for the system, as
+it is search in the Description hierarchy as well.</p>
+
+ <p>This allows user to declare and override values, and result in very
+ flexible configuration model. The flexibility could be the Achilles heel for the system, as
the search, specially for something that does not exists is expensive,
yet the in the final analysis developers believe that the flexibility
would serve better in this instants and opt for the flexibility. </p>
@@ -126,30 +127,32 @@
<p>Please refer to the <a href="OMTutorial.html">OM Tutorial</a></p>
<h2>SOAP Processing Model</h2>
-<p>Axis2 SOAP processing Model is based on two basic operation a SOAP Message can be undergone, sending and receiving. </p>
+<p>Axis2 SOAP processing Model is based on two basic operation a SOAP Message can be undergone, sending and receiving.</p>
<IMG src="images/archi-guide/soap-processing.gif" width="755" height="348" border="0">
-<p>The Architecture identified two basic actions a SOAP Processor should perform, sending and receiving SOAP Messages. The Architecture provides two Pipes (also named as Flows), to do this basic actions, Axis Engine or the Driver of Axis2 define two methods send() and receive() to implement these two Pipes. The two pipes are named as <i>In Pipe</i> and <i>Out Pipe</i>, the complex Message Exchange Patterns are constructed by combining these two Pipes.</p>
+<p>The Architecture identified two basic actions a SOAP Processor should perform, sending and receiving SOAP Messages. The Architecture provides two Pipes (also named as Flows), to do these two basic actions. Axis Engine or the Driver of Axis2 define two methods send() and receive() to implement these two Pipes. The two pipes are named as <i>In Pipe</i> and <i>Out Pipe</i>, the complex Message Exchange Patterns are constructed by combining these two Pipes.</p>
+<p>Extensibility of the SOAP processing Model is provided though the Handlers, when a SOAP Message is being processed the Handlers that are registered would be executed. The Hanlders 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 the parts of the SOAP Message and provide add on Services.
+Usually Handlers work on the SOAP Headers yet they may accsess or change the SOAP Body as well.</p>
-<p>When a SOAP Message is send from the Client API, a <i>Out Pipe</i> would begun, the out pipe invoke the Handlers and ends with a Transport Sender that send the SOAP Message to the target endpoint. The SOAP Message is received by a Transport Receiver at the target endpoint, which read the SOAP Message and start the <i>In Pipe</i>. The In pipe consists of Handler and end with a Message Receiver, which consumed the Message.</p>
-<p>The Processing take place for each and every SOAP Message exchanged. Processing that follows the such SOAP Message exchange may decide to give birth for the other SOAP Message in which case the more complex Patterns emerge. But Axis2 always view the SOAP Message in terms of processing of a Single Message where as the combination of the Messages are layered on top of that base.</p>
+<p>When a SOAP Message is send from the Client API, a <i>Out Pipe</i> would begun, the <i>Out Pipe</i> invoke the Handlers and ends with a Transport Sender that send the SOAP Message to the target endpoint. The SOAP Message is received by a Transport Receiver at the target endpoint, which read the SOAP Message and start the <i>In Pipe</i>. The In pipe consists of Handler and end with a Message Receiver, which consumed the Message.</p>
-<p>The two Pipes does not differentiate between the Server and the Client, the SOAP Processing Model Handles the Complexity and provide two abstract pipes to the User. Each pipes is set of Handlers, the different areas of the Pipes are given names, and according to the Axis2 slang those are named Phases. The Handler is always run inside a Phase, and the Phase provide mechanisum to state the ordering of the Handler. Both Pipes has built in Phases, and both define the areas for User Phases which can be defined by the User.</p>
+<p>Above explans processing happens for each and every SOAP Message exchanged. Processing that follows may decide to give birth for the other SOAP Message, in which case the more complex Patterns emerge. But Axis2 always view the SOAP Message in terms of processing of a Single Message where as 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 provide two abstract pipes to the User. Each pipes is set of Handlers, the different areas of the Pipes are given names, and according to the Axis2 slang those are named Phases. The Handler always runs inside a Phase, and the Phase provide a mechanisum to specify the ordering of Handlers. Both Pipes has built in Phases, and both define the areas for User Phases which can be defined by the User.</p>
<p>Following Picture shows the the two Pipes with their pre-defined Phases, the user defined Phases would be fit in to the User Phases.</p>
<IMG src="images/archi-guide/phases.png" width="525" height="226" border="0">
<h3>Axis2 Default Processing Model</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 in the next section. </p>
+<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>Dispatchers - Find the Service the SOAP message is directed to, always run on the In-Pipe and inside the Dispatch Phase. There is a inbuilt Dispatcher, that run in any case and user may override it by placing the dispatchers before the inbuilt Dispatcher.</li>
<li>Message Receiver - Consume the SOAP Message and run on the Message Processing Phase in the inflow</li>
<li>Transport Sender - Send the SOAP message to the SOAP endpoint the message is destined to. Always runs on the</li>
-<li>Transport Phase of the out pipe. There are two other flows, the fault-in flow and the fault out flow, inflow and the out flow phases are used on there places.
-</li>
</ol>
<h3>Processing an Incoming SOAP Message</h3>
@@ -158,13 +161,13 @@
<ol>
<li>Transport Phase - The Handlers in the transport Phase are taken from the transport configuration associated, they are executed according to the Phase rules. </li>
<li>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.</li>
-<li>Dispatch Phase â The Dispatchers are run in this Phases and find the Service if the service is not found already.
-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â.
+<li>Dispatch Phase â The Dispatchers are run in this Phases and find the Service if the service is not found already.</li>
+<li>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</li>
<li>User Defined Phases â User defined Phases are executed here.</li>
<li>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.
</li>
-<li>Message Processing Phase â The Business logic of the SOAP message, executed here, the a Message Receiver is registered with a each Operation. The Message receiver associated with the each operation would be executed at last Handler of this Phase.
+<li>Message Processing Phase â The Business logic of the SOAP message, executed here, the a Message Receiver is registered with a each Operation. The Message receiver associated with the each operation would be executed as the last Handler of this Phase.
</li>
</ol>
@@ -174,45 +177,46 @@
<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 Message Receiver or the Client API implementation. </p>
-<ol><li>Message Initialize â Fist Phase of the out pipe, this serves as the placeholder for the custom Handlers</li>
-<li>Policy Determination â Just like in the in-pipe this is not implemented and suppose to serve as a extension point. </li>
+<ol><li>Message Initialize Phaseâ Fist Phase of the out pipe, this serves as the placeholder for the custom Handlers</li>
+<li>Policy Determination Phaseâ Just like in the in-pipe this is not implemented and suppose to serve as a extension point. </li>
<li>User Phases â This executed the Handlers in user define Phases</li>
-<li>Transports â 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. </li>
+<li>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. </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 mechanisum for the SOAP Processing Model now.</p>
- <p>Idea behind making the each step of the SOAP processing in to Handlers (inbuilt ones we discuss eariler) and placing them in the Phases is to allow Handlers to be placed between those Handlers and to override or affect the default mechanics.</p>
- <p>There is a two ways the to extend the SOAP Processing Model, first is to add the the Handlers to the SOAP Processing Model. The Handlers can specify the the Phase they need to be run, further more they can specify the there location inside a phase via the following information.</p>
+ <p>Idea behind making the each step of the SOAP processing in to Handlers (inbuilt ones we discuss eariler) 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 is a two ways the to extend the SOAP Processing Model.</p>
+
+ <h4>Extending the SOAP Processing Model with Handlers</h4>
+ <p>Handlers to the SOAP Processing Model. The Handlers can specify the the Phase they need to be run, further more they can specify the there location inside a phase via the following information.</p>
<ol>
<li>Handler should run as the first in the phases</li>
<li>Handler should run as the last in the Phases</li>
<li>Handler should run before a given Handlers</li>
<li>Handler should run after a Given Handler </li>
</ol>
- <p>Second is to use Modules, the SOAP processing Model defines a
-logical entity called a module to extend the SOAP Processing Model.
-Modules encapsulat two entities, Handlers and Web Service Operations.
-Apart from the extension mechanism based on the Handlers, the WS-*
-specifications suggest new extension mechanism. For an example once a
+<h4>Extending the SOAP Processing Model with Modules</h4>
+ <p>SOAP processing Model defines a
+logical entity called a module that encapsulate two entities, Handlers and Web Service Operations.
+The Handlers will act in the same way as explained in the first method.</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 is implemented by letting the Modules define the operations and
-once the module is engaged to a service the operation will be added to
+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
that service. </p>
<p>The service, operations and system may engaged
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, each module is
-available once the system comes up. System, service or an operation may
-engage a module, and all entities in the module would be added to one
-who engaged the module.</p>
+available once the system comes up.</p>
<h2>Deployment</h2>
-<p>There deployment Model provides a concrete mechanisum to configuration Axis2 to run. Deployment Model has four entities that provide the configuration. </p>
+<p>There deployment Model provides a concrete mechanisum to configure Axis2. Deployment Model has four entities that provide the configuration. </p>
<h3>The <em>server.xml</em> file and <em>client.xml</em> files </h3>
@@ -227,40 +231,50 @@
<h3>Service Archive</h3>
-<p>Service archive must have a <em>META-INF/service.xm</em>l file may contains the dependent classes. the <em>service.xml</em> file has following information.</p>
+<p>Service archive must have a <em>META-INF/service.xml</em> file and may contains the dependent classes. the <em>service.xml</em> file has following information.</p>
<ol><li>Service level parameters</li>
<li>Modules that are engaged Service level</li>
<li>Operations inside the Service</li></ol>
<h3>Module Archive</h3>
-<p>Module archive must have a <em>META-INF/module.xml</em> file and the <em>module.xml</em> file has Module parameters and the Operations defined in the module.</p>
+<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 server.xml or a client.xml file and build the global configuration. Then the Model check for the Module archives and then for the service archives, the corresponding services and Modules are added to the Axis Configuration. System will built a 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>WSDL and code generation</h2>
-<p>Axis2 uses the XSLT transforms for the code generation, first the
-parsing code would read the WSDL using the WSDL Object Model and
-generate an XML file that has the necessary information to generate the
-Stubs and Skeletons. Currently Axis2 does not come with the full data
-binding support, the generated code supports the eight primitive data
-types and all the complex types are treated as OMElements. </p>
+
+<p>Although the basic objective of the codegen 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 border="0" src="images/archi-guide/CodegenArchitecture.JPG" width="478" height="218"></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.h</p>
+
<h2>Client API</h2>
- <p>There are three parameters that decide a nature of the Web Service interaction the Client API of a Web Service Middle ware should supports.</p>
+ <p>There are three parameters that decides the nature of the Web Service interaction.</p>
<ol>
<li>Message Exchange Pattern</li>
-<li>The Behavior of the transport. does it acting like a one-way or two way transport</li>
+<li>The Behavior of the transport. does it acting like a one-way or two way transport?</li>
<li>Synchronous/ Asynchronous behavior of the Client API</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. But Axis2 client API
-supports all the scenarios that arise from those two Message Exchange
-Patterns.</p>
+any messaging interaction, the developers were compelled to support only
+two most widely used Message Exchange Patterns.</p>
<p>Two supported transports are One-Way and the Request-Response Senarios in the
Client API, the implementation is based on a class called <code>MEPClient</code> and there are extentions for each Message Exchange Pattern that Axis2 Client API supports.</p>
Added: webservices/axis/trunk/java/xdocs/images/archi-guide/CodegenArchitecture.JPG
URL: http://svn.apache.org/viewcvs/webservices/axis/trunk/java/xdocs/images/archi-guide/CodegenArchitecture.JPG?rev=180285&view=auto
==============================================================================
Binary file - no diff available.
Propchange: webservices/axis/trunk/java/xdocs/images/archi-guide/CodegenArchitecture.JPG
------------------------------------------------------------------------------
svn:mime-type = application/octet-stream