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 ch...@apache.org on 2007/06/26 08:40:55 UTC
svn commit: r550710 - /webservices/axis2/site/1_2/Axis2ArchitectureGuide.html
Author: chatra
Date: Mon Jun 25 23:40:54 2007
New Revision: 550710
URL: http://svn.apache.org/viewvc?view=rev&rev=550710
Log:
fixed JIRA https://issues.apache.org/jira/browse/AXIS2-2846
Modified:
webservices/axis2/site/1_2/Axis2ArchitectureGuide.html
Modified: webservices/axis2/site/1_2/Axis2ArchitectureGuide.html
URL: http://svn.apache.org/viewvc/webservices/axis2/site/1_2/Axis2ArchitectureGuide.html?view=diff&rev=550710&r1=550709&r2=550710
==============================================================================
--- webservices/axis2/site/1_2/Axis2ArchitectureGuide.html (original)
+++ webservices/axis2/site/1_2/Axis2ArchitectureGuide.html Mon Jun 25 23:40:54 2007
@@ -1,36 +1,162 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html><head><title>Axis2/Java - Axis2 Architecture Guide</title><style type="text/css" media="all">
+<?xml version="1.0" encoding="iso-8859-1"?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html>
+<head>
+ <title>Axis2/Java - Axis2 Architecture Guide</title>
+ <style type="text/css" media="all">
@import url("../style/maven-base.css");
- @import url("../style/maven-theme.css");</style><link rel="stylesheet" href="../style/print.css" type="text/css" media="print"></link><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"></meta></head><body class="composite"><div id="banner"><a href="http://www.apache.org/" id="organizationLogo"><img alt="Apache Software Foundation" src="http://www.apache.org/images/asf-logo.gif"></img></a><a href="http://ws.apache.org/axis2/" id="projectLogo"><img alt="Apache Axis2" src="http://ws.apache.org/axis2/images/axis.jpg"></img></a><div class="clear"><hr></hr></div></div><div id="breadcrumbs"><div class="xleft">
- Last published: 04 May 2007
- | Doc for 1.2</div><div class="xright">
-
- <a href="../index.html">Axis2/Java</a>
-
-
-
- <span class="separator">|</span>
-
-
- <a href="http://ws.apache.org/axis2/c" class="externalLink" title="External Link">Axis2/C</a>
-
-
-
- <span class="separator">|</span>
-
-
- <a href="http://ws.apache.org" class="externalLink" title="External Link">Apache WS</a>
-
-
-
- <span class="separator">|</span>
-
-
- <a href="http://www.apache.org" class="externalLink" title="External Link">Apache </a>
- </div><div class="clear"><hr></hr></div></div><div id="leftColumn"><div id="navcolumn"><div id="menuAxis2_Java"><h5>Axis2/Java</h5><ul><li class="none"><a href="../index.html">Home</a></li></ul></div><div id="menuDownloads"><h5>Downloads</h5><ul><li class="none"><a href="../download.cgi">Releases</a></li><li class="none"><a href="../modules/index.html">Modules</a></li><li class="none"><a href="../tools/index.html">Tools</a></li></ul></div><div id="menuDocumentation"><h5>Documentation</h5><ul><li class="expanded"><a href="../1_2/contents.html">Version 1.2</a><ul><li class="none"><a href="../1_2/toc.html">Table of Contents</a></li><li class="none"><a href="../1_2/installationguide.html">Installation Guide</a></li><li class="none"><a href="../1_2/quickstartguide.html">QuickStart Guide</a></li><li class="none"><a href="../1_2/userguide.html">User Guide</a></li><li class="none"><a href="../1_2/pojoguide.html">POJO Guide</a></li><li class="none"><a href="../1_2/spring.html">
Spring Guide</a></li><li class="none"><a href="../1_2/webadminguide.html">Web Administrator's Guide</a></li><li class="none"><a href="../1_2/migration.html">Migration Guide (from Axis1)</a></li></ul></li><li class="none"><a href="../1_1_1/contents.html">Version 1.1.1</a></li><li class="none"><a href="../1_1/contents.html">Version 1.1</a></li><li class="none"><a href="../1_0/index.html">Version 1.0</a></li><li class="none"><a href="../0_95/index.html">Version 0.95</a></li><li class="none"><a href="../0_94/index.html">Version 0.94</a></li><li class="none"><a href="../0_93/index.html">Version 0.93</a></li></ul></div><div id="menuResources"><h5>Resources</h5><ul><li class="none"><a href="../faq.html">FAQ</a></li><li class="none"><a href="../articles.html">Articles</a></li><li class="none"><a href="http://wiki.apache.org/ws/FrontPage/Axis2/" class="externalLink" title="External Link">Wiki</a></li><li class="none"><a href="../refLib.html">Reference Library</a></li><li class="none"
><a href="http://ws.apache.org/axis2/1_2/api/index.html" class="externalLink" title="External Link">Online Java Docs</a></li></ul></div><div id="menuGet_Involved"><h5>Get Involved</h5><ul><li class="none"><a href="../overview.html">Overview</a></li><li class="none"><a href="../svn.html">Checkout the Source</a></li><li class="none"><a href="../mail-lists.html">Mailing Lists</a></li><li class="none"><a href="../guidelines.html">Developer Guidelines</a></li><li class="none"><a href="../siteHowTo.html">Build the Site</a></li></ul></div><div id="menuProject_Information"><h5>Project Information</h5><ul><li class="none"><a href="../team-list.html">Project Team</a></li><li class="none"><a href="../issue-tracking.html">Issue Tracking</a></li><li class="none"><a href="http://svn.apache.org/viewcvs.cgi/webservices/axis2/trunk/?root=Apache-SVN" class="externalLink" title="External Link">Source Code</a></li><li class="none"><a href="../thanks.html">Acknowledgements</a></li><li class="non
e"><a href="http://www.apache.org/licenses/LICENSE-2.0.html" class="externalLink" title="External Link">License</a></li></ul></div><a href="http://maven.apache.org/" title="Built by Maven" id="poweredBy"><img alt="Built by Maven" src="../images/logos/maven-button-1.png"></img></a></div></div><div id="bodyColumn"><div class="contentBox"><div class="section"><a name="eApache_Axis2_Architecture_Guide"></a><h2>eApache Axis2 Architecture Guide</h2><p>This document gives an introduction to Axis2's modular architecture with
-explanations on every module.</p><p><i>Send your feedback to: <a href="mailto:axis-dev@ws.apache.org?subject=[Axis2]">axis-dev@ws.apache.org</a></i>.
-(Subscription details are available on the <a href="http://ws.apache.org/axis2/mail-lists.html" class="externalLink" title="External Link">Axis2 site</a>.) Kindly
-prefix subject with [Axis2].</p><div class="subsection"><a name="Contents"></a><h3>Contents</h3><ul>
+ @import url("../style/maven-theme.css");</style>
+ <link rel="stylesheet" href="../style/print.css" type="text/css"
+ media="print" />
+ <meta http-equiv="content-type" content="text/html; charset=iso-8859-1" />
+</head>
+
+<body class="composite">
+
+<div id="banner">
+<a href="http://www.apache.org/" id="organizationLogo"><img
+alt="Apache Software Foundation"
+src="http://www.apache.org/images/asf-logo.gif" /></a><a
+href="http://ws.apache.org/axis2/" id="projectLogo"><img alt="Apache Axis2"
+src="http://ws.apache.org/axis2/images/axis.jpg" /></a>
+
+<div class="clear">
+<hr />
+</div>
+</div>
+
+<div id="breadcrumbs">
+
+<div class="xleft">
+Last published: 04 May 2007 | Doc for 1.2</div>
+
+<div class="xright">
+<a href="../index.html">Axis2/Java</a> <span class="separator">|</span> <a
+href="http://ws.apache.org/axis2/c" class="externalLink"
+title="External Link">Axis2/C</a> <span class="separator">|</span> <a
+href="http://ws.apache.org" class="externalLink" title="External Link">Apache
+WS</a> <span class="separator">|</span> <a href="http://www.apache.org"
+class="externalLink" title="External Link">Apache</a></div>
+
+<div class="clear">
+<hr />
+</div>
+</div>
+
+<div id="leftColumn">
+
+<div id="navcolumn">
+
+<div id="menuAxis2_Java">
+<h5>Axis2/Java</h5>
+<ul>
+ <li class="none"><a href="../index.html">Home</a></li>
+</ul>
+</div>
+
+<div id="menuDownloads">
+<h5>Downloads</h5>
+<ul>
+ <li class="none"><a href="../download.cgi">Releases</a></li>
+ <li class="none"><a href="../modules/index.html">Modules</a></li>
+ <li class="none"><a href="../tools/index.html">Tools</a></li>
+</ul>
+</div>
+
+<div id="menuDocumentation">
+<h5>Documentation</h5>
+<ul>
+ <li class="expanded"><a href="../1_2/contents.html">Version 1.2</a>
+ <ul>
+ <li class="none"><a href="../1_2/toc.html">Table of Contents</a></li>
+ <li class="none"><a href="../1_2/installationguide.html">Installation
+ Guide</a></li>
+ <li class="none"><a href="../1_2/quickstartguide.html">QuickStart
+ Guide</a></li>
+ <li class="none"><a href="../1_2/userguide.html">User Guide</a></li>
+ <li class="none"><a href="../1_2/pojoguide.html">POJO Guide</a></li>
+ <li class="none"><a href="../1_2/spring.html">Spring Guide</a></li>
+ <li class="none"><a href="../1_2/webadminguide.html">Web
+ Administrator's Guide</a></li>
+ <li class="none"><a href="../1_2/migration.html">Migration Guide (from
+ Axis1)</a></li>
+ </ul>
+ </li>
+ <li class="none"><a href="../1_1_1/contents.html">Version 1.1.1</a></li>
+ <li class="none"><a href="../1_1/contents.html">Version 1.1</a></li>
+ <li class="none"><a href="../1_0/index.html">Version 1.0</a></li>
+ <li class="none"><a href="../0_95/index.html">Version 0.95</a></li>
+ <li class="none"><a href="../0_94/index.html">Version 0.94</a></li>
+ <li class="none"><a href="../0_93/index.html">Version 0.93</a></li>
+</ul>
+</div>
+
+<div id="menuResources">
+<h5>Resources</h5>
+<ul>
+ <li class="none"><a href="../faq.html">FAQ</a></li>
+ <li class="none"><a href="../articles.html">Articles</a></li>
+ <li class="none"><a href="http://wiki.apache.org/ws/FrontPage/Axis2/"
+ class="externalLink" title="External Link">Wiki</a></li>
+ <li class="none"><a href="../refLib.html">Reference Library</a></li>
+ <li class="none"><a href="http://ws.apache.org/axis2/1_2/api/index.html"
+ class="externalLink" title="External Link">Online Java Docs</a></li>
+</ul>
+</div>
+
+<div id="menuGet_Involved">
+<h5>Get Involved</h5>
+<ul>
+ <li class="none"><a href="../overview.html">Overview</a></li>
+ <li class="none"><a href="../svn.html">Checkout the Source</a></li>
+ <li class="none"><a href="../mail-lists.html">Mailing Lists</a></li>
+ <li class="none"><a href="../guidelines.html">Developer Guidelines</a></li>
+ <li class="none"><a href="../siteHowTo.html">Build the Site</a></li>
+</ul>
+</div>
+
+<div id="menuProject_Information">
+<h5>Project Information</h5>
+<ul>
+ <li class="none"><a href="../team-list.html">Project Team</a></li>
+ <li class="none"><a href="../issue-tracking.html">Issue Tracking</a></li>
+ <li class="none"><a
+ href="http://svn.apache.org/viewcvs.cgi/webservices/axis2/trunk/?root=Apache-SVN"
+ class="externalLink" title="External Link">Source Code</a></li>
+ <li class="none"><a href="../thanks.html">Acknowledgements</a></li>
+ <li class="none"><a href="http://www.apache.org/licenses/LICENSE-2.0.html"
+ class="externalLink" title="External Link">License</a></li>
+</ul>
+</div>
+<a href="http://maven.apache.org/" title="Built by Maven" id="poweredBy"><img
+alt="Built by Maven" src="../images/logos/maven-button-1.png" /></a></div>
+</div>
+
+<div id="bodyColumn">
+
+<div class="contentBox">
+
+<div class="section">
+<a name="eApache_Axis2_Architecture_Guide"></a>
+
+<h2>Apache Axis2 Architecture Guide</h2>
+
+<p>This document gives an introduction to Axis2's modular architecture with
+explanations on every module.</p>
+
+<p><i>Send your feedback to: <a
+href="mailto:axis-dev@ws.apache.org?subject=[Axis2]">axis-dev@ws.apache.org</a></i>.
+(Subscription details are available on the <a
+href="http://ws.apache.org/axis2/mail-lists.html" class="externalLink"
+title="External Link">Axis2 site</a>.) Kindly prefix subject with [Axis2].</p>
+
+<div class="subsection">
+<a name="Contents"></a>
+
+<h3>Contents</h3>
+<ul>
<li><a href="#bmBP">The Big Picture</a></li>
<li><p><a href="#requirements">Requirement of Axis2</a></p>
</li>
@@ -91,27 +217,61 @@
</li>
</ul>
</li>
-</ul><p><a name="bmBP"></a></p></div><div class="subsection"><a name="The_Big_Picture"></a><h3>The Big Picture</h3><p>A new architecture for Axis was introduced during the August 2004 Summit
+</ul>
+
+<p><a name="bmBP"></a></p>
+</div>
+
+<div class="subsection">
+<a name="The_Big_Picture"></a>
+
+<h3>The Big Picture</h3>
+
+<p>A new architecture for Axis was introduced during the August 2004 Summit
in Colombo, Sri Lanka. This new architecture on which Axis2 is based is more
-flexible, efficient, and configurable in comparison to <a href="http://ws.apache.org/axis/java/architecture-guide.html" class="externalLink" title="External Link">Axis1.x
-architecture</a>. Some well established concepts from Axis 1.x, like handlers
-etc., have been preserved in this new architecture.</p><p>Any architecture is a result of what that architecture should yield. The
+flexible, efficient, and configurable in comparison to <a
+href="http://ws.apache.org/axis/java/architecture-guide.html"
+class="externalLink" title="External Link">Axis1.x architecture</a>. Some
+well established concepts from Axis 1.x, like handlers etc., have been
+preserved in this new architecture.</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><p><a name="requirements"></a></p></div><div class="subsection"><a name="Requirement_of_Axis2"></a><h3>Requirement of Axis2</h3><p>In SOAP terminology, a participant who is taking part in a Web service
+by looking at the requirements.</p>
+
+<p><a name="requirements"></a></p>
+</div>
+
+<div class="subsection">
+<a name="Requirement_of_Axis2"></a>
+
+<h3>Requirement of Axis2</h3>
+
+<p>In 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 a SOAP Sender and received by a 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
+interaction.</p>
+
+<p>Each SOAP Node may be written in specific programming language, may it be
Java, C++, .NET or Perl, but the Web services allow them to interoperate.
This is possible because on the wire each Web service interaction is done via
-SOAP, which is common to every SOAP Node.</p><p><img alt="" src="images/archi-guide/soap.gif" name="Graphic1" align="bottom" width="691" height="319" border="0"></img></p><p>Web service middleware handles the complexity in SOAP messaging and lets
+SOAP, which is common to every SOAP Node.</p>
+
+<p><img alt="" 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>Axis2 handles SOAP processing along with numerous other tasks. This makes
+handles the SOAP messaging behind the curtain.</p>
+
+<p>Axis2 handles SOAP processing along with numerous other tasks. This makes
life of a Web service developer a whole lot easier. Following are the
-identified requirements:</p><ol>
+identified requirements:</p>
+<ol>
<li>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
@@ -124,24 +284,54 @@
<li>Ability to configure Axis2 and its components through deployment.</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
+</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- <a href="http://www.w3.org/TR/wsdl" class="externalLink" title="External Link">WSDL</a>, <a href="http://www.w3.org/TR/soap/" class="externalLink" title="External Link">SOAP</a> and <a href="http://www.w3.org/Submission/ws-addressing/" class="externalLink" title="External Link">WS-Addressing</a>. Other
-specifications like JAX-RPC, <a href="http://java.sun.com/webservices/saaj/index.jsp" class="externalLink" title="External Link"> SAAJ</a> and <a href="http://www.w3.org/Submission/WS-Policy/" class="externalLink" title="External Link">WS-Policy</a> are layered on
-top of the Core Architecture.</p><p><a name="thearchi"></a></p></div><div class="subsection"><a name="Axis2_Architecture"></a><h3>Axis2 Architecture</h3><p>
-Axis2 architecture lays out some principals to preserve the uniformity. They
-are as follows:
-<ul>
+three specifications- <a href="http://www.w3.org/TR/wsdl"
+class="externalLink" title="External Link">WSDL</a>, <a
+href="http://www.w3.org/TR/soap/" class="externalLink"
+title="External Link">SOAP</a> and <a
+href="http://www.w3.org/Submission/ws-addressing/" class="externalLink"
+title="External Link">WS-Addressing</a>. Other specifications like JAX-RPC,
+<a href="http://java.sun.com/webservices/saaj/index.jsp" class="externalLink"
+title="External Link">SAAJ</a> and <a
+href="http://www.w3.org/Submission/WS-Policy/" class="externalLink"
+title="External Link">WS-Policy</a> are layered on top of the Core
+Architecture.</p>
+
+<p><a name="thearchi"></a></p>
+</div>
+
+<div class="subsection">
+<a name="Axis2_Architecture"></a>
+
+<h3>Axis2 Architecture</h3>
+
+<p>Axis2 architecture lays out some principals to preserve the uniformity.
+They are as follows: <ul>
<li><p>Axis2 architecture separates the logic and the states. Code that
does the processing does not have a state 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 the
system to be suspended and resumed.</li>
-</ul></p><p>Axis2 architecture is modular. Therefore, Axis2 Framework is built up of
+</ul>
+</p>
+
+<p>Axis2 architecture is modular. Therefore, Axis2 Framework is built up of
core modules that collectively make up the core architecture of Axis2.
Non-core/other modules are layered on top of this core
-modules/architecture.</p><p><a name="bmcore"></a></p></div><div class="subsection"><a name="Core_Modules:"></a><h3>Core Modules:</h3><ul>
+modules/architecture.</p>
+
+<p><a name="bmcore"></a></p>
+</div>
+
+<div class="subsection">
+<a name="Core_Modules:"></a>
+
+<h3>Core Modules:</h3>
+<ul>
<li><a href="#bmInfoMod">Information Model</a> - Axis2 defines a model to
handle information and all states are kept in this model. The model
consists of a hierarchy of information. The system manages the life cycle
@@ -150,10 +340,11 @@
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 sub-project under the Web
- services project, allowing that sub-project (<a href="http://ws.apache.org/commons/axiom/index.html" class="externalLink" title="External Link">AXIOM</a> or AXis
- Object Model) to provide a simple API for SOAP and XML info-set. It will
- hide the complexities of the efficient XML processing within the
- implementation.</p>
+ services project, allowing that sub-project (<a
+ href="http://ws.apache.org/commons/axiom/index.html" class="externalLink"
+ title="External Link">AXIOM</a> or AXis Object Model) to provide a simple
+ API for SOAP and XML info-set. It will hide 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
@@ -166,18 +357,28 @@
</li>
<li><a href="#bmClientAPI">Client API</a> - This provides a convenient API
for users to communicate with Web services using Axis2. There are a set
- of classes to interact with IN-OUT and IN-Only style <a href="http://www.w3.org/2002/ws/cg/2/07/meps.html" class="externalLink" title="External Link">Message Exchange
- Patterns (MEPs)</a>, where they can be used to construct any other MEP.
- (Please note that even if the client API has in-built support for the
- above named MEPs, it does not by any means limit Axis2's flexibility to
- support custom MEPs.)</li>
+ of classes to interact with IN-OUT and IN-Only style <a
+ href="http://www.w3.org/2002/ws/cg/2/07/meps.html" class="externalLink"
+ title="External Link">Message Exchange Patterns (MEPs)</a>, where they
+ can be used to construct any other MEP. (Please note that even if the
+ client API has in-built support for the above named MEPs, it does not by
+ any means limit Axis2's flexibility to support custom MEPs.)</li>
<li><p><a href="#bmTransports">Transports</a> - Axis2 defines a transport
framework that enables the user to use multiple different transports. The
transports fit into specific places in the SOAP processing model. The
implementation provides a few common transports and the user can write or
plug-in new ones if and when it is needed.</p>
</li>
-</ul><p><a name="bmother"></a></p></div><div class="subsection"><a name="Other_Modules:"></a><h3>Other Modules:</h3><ul>
+</ul>
+
+<p><a name="bmother"></a></p>
+</div>
+
+<div class="subsection">
+<a name="Other_Modules:"></a>
+
+<h3>Other Modules:</h3>
+<ul>
<li><a href="#bmWSDL">Code Generation</a> - Axis2 provides a code
generation tool that generates server side and client side code along
with descriptors and a test case. The generated code would simplify the
@@ -188,119 +389,227 @@
extends it to make it more convenient to the users by encapsulating the
infoset layer and providing a programming language specific interface.</p>
</li>
-</ul><map name="Graphic2Map" id="g2m">
- <area shape="rect" coords="123,31,222,97" href="#bmInfoMod" alt=""></area>
- <area shape="rect" coords="239,62,319,134" href="#bmXML" alt=""></area>
- <area shape="rect" coords="127,112,218,177" href="#bmSOAPPM" alt=""></area>
- <area shape="rect" coords="12,39,89,95" href="#bmDeployment" alt=""></area>
- <area shape="rect" coords="0,108,94,156" href="#bmWSDL" alt=""></area>
- <area shape="rect" coords="350,31,426,86" href="#bmClientAPI" alt=""></area>
- <area shape="rect" coords="350,114,421,164" href="#bmTransports" alt=""></area>
-</map><p><img src="images/archi-guide/all.png" name="Graphic2" width="426" alt="" height="189" border="0" align="bottom" usemap="#Graphic2Map"></img></p><p><a name="bmInfoMod"></a></p></div><div class="subsection"><a name="Information_Model"></a><h3>Information Model</h3><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" alt="" width="400" height="443" border="0"></img></p><p>( A ----<> B says, B has 1 or more objects of A. A------>B says,
-the given relationship holds between A and B.)</p><p>The two hierarchies are connected as shown in the above figure. The
+</ul>
+<map name="Graphic2Map" id="g2m">
+ <area shape="rect" coords="123,31,222,97" href="#bmInfoMod" alt="" />
+ <area shape="rect" coords="239,62,319,134" href="#bmXML" alt="" />
+ <area shape="rect" coords="127,112,218,177" href="#bmSOAPPM" alt="" />
+ <area shape="rect" coords="12,39,89,95" href="#bmDeployment" alt="" />
+ <area shape="rect" coords="0,108,94,156" href="#bmWSDL" alt="" />
+ <area shape="rect" coords="350,31,426,86" href="#bmClientAPI" alt="" />
+ <area shape="rect" coords="350,114,421,164" href="#bmTransports" alt="" />
+</map>
+
+<p><img src="images/archi-guide/all.png" name="Graphic2" width="426" alt=""
+height="189" border="0" align="bottom" usemap="#Graphic2Map" /></p>
+
+<p><a name="bmInfoMod"></a></p>
+</div>
+
+<div class="subsection">
+<a name="Information_Model"></a>
+
+<h3>Information Model</h3>
+
+<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"
+alt="" width="400" height="443" border="0" /></p>
+
+<p>( A ----<> B says, B has 1 or more objects of A. A------>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. 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 instance (e.g.Message Context).</p><p>These two hierarchies create a model that provides the ability to search
+more than one instance (e.g.Message Context).</p>
+
+<p>These two hierarchies create 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 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 the starting point is a
-Context then it searches in the Description hierarchy as well.</p><p>This allows the user to declare and override values, with the result being
+Context then it searches in the Description hierarchy as well.</p>
+
+<p>This allows the user to declare and override values, with the 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 class="bodyTable"><col width="112"></col><col width="371"></col><col width="103"></col><col width="336"></col><tbody>
- <tr class="b"><td><strong>Context</strong></td><td><strong>Description</strong></td><td><strong>Configuration</strong></td><td><strong>Description</strong></td></tr>
- <tr class="a"><td width="112"><p>Configuration Context</p>
- </td><td width="371"><p>Holds the Axis2's run time status. A deep copy of
+believe that the flexibility would serve better in this instant.</p>
+
+<table class="bodyTable">
+ <col width="112" /><col width="371" /><col width="103" /><col width="336"
+ /><tbody>
+ <tr class="b">
+ <td><strong>Context</strong></td>
+ <td><strong>Description</strong></td>
+ <td><strong>Configuration</strong></td>
+ <td><strong>Description</strong></td>
+ </tr>
+ <tr class="a">
+ <td width="112"><p>Configuration Context</p>
+ </td>
+ <td width="371"><p>Holds the Axis2's 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
+ </td>
+ <td width="103"><p>Axis Configuration</p>
+ </td>
+ <td width="336"><p>Holds all global configurations. Transports, global
modules, parameters, and services etc.</p>
- </td></tr>
- <tr class="b"><td width="112"><p>Service Group Context</p>
- </td><td width="371"><p>Holds information about a particular usage of the
+ </td>
+ </tr>
+ <tr class="b">
+ <td width="112"><p>Service Group Context</p>
+ </td>
+ <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
(within the same service group) in a single interaction.</p>
- </td><td width="103"><p>AxisServiceGroup</p>
- </td><td width="336"><p>Holds deployment time information about a particular
+ </td>
+ <td width="103"><p>AxisServiceGroup</p>
+ </td>
+ <td width="336"><p>Holds deployment time information about a particular
service group.</p>
- </td></tr>
- <tr class="a"><td width="112"><p>Service Context</p>
- </td><td width="371"><p>This context is available throughout the usage of
+ </td>
+ </tr>
+ <tr class="a">
+ <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 of the same service, within a single interaction. The
life cycle depends on the scope of the service.</p>
- </td><td width="103"><p>AxisService</p>
- </td><td width="336"><p>Holds the Operations and the service level
+ </td>
+ <td width="103"><p>AxisService</p>
+ </td>
+ <td width="336"><p>Holds the Operations and the service level
configurations</p>
- </td></tr>
- <tr class="b"><td width="112"><p>Operation Context</p>
- </td><td width="371"><p>Holds the information about the current MEP
+ </td>
+ </tr>
+ <tr class="b">
+ <td width="112"><p>Operation Context</p>
+ </td>
+ <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>AxisOperation</p>
- </td><td width="336"><p>Holds the operation level configurations</p>
- </td></tr>
- <tr class="a"><td width="112"><a name="messageContext"></a>
+ </td>
+ <td width="103"><p>AxisOperation</p>
+ </td>
+ <td width="336"><p>Holds the operation level configurations</p>
+ </td>
+ </tr>
+ <tr class="a">
+ <td width="112"><a name="messageContext"></a>
<p>Message Context</p>
- </td><td width="371"><p>Holds all the information about the Message
+ </td>
+ <td width="371"><p>Holds all the information about the Message
currently being executed.</p>
- </td><td width="103"><p>AxisMessage</p>
- </td><td width="336"><p>Holds message level static information like the
+ </td>
+ <td width="103"><p>AxisMessage</p>
+ </td>
+ <td width="336"><p>Holds message level static information like the
schema of the particular message.</p>
- </td></tr>
- </tbody></table><p><a name="bmXML"></a></p></div><div class="subsection"><a name="XML_Processing_Model"></a><h3>XML Processing Model</h3><p>As we mentioned above, the XML processing model of Axis2 has become a
-separate sub-project, called <a href="http://ws.apache.org/commons/axiom/index.html" class="externalLink" title="External Link">Apache Axiom</a>, in the
-Apache Web services project. Please refer to the <a href="OMTutorial.html">OM
-Tutorial</a> for more information.</p><p><a name="bmSOAPPM"></a></p></div><div class="subsection"><a name="SOAP_Processing_Model"></a><h3>SOAP Processing Model</h3><p><img src="images/archi-guide/soap-processing.gif" name="Graphic4" alt="" align="bottom" width="755" height="348" border="0"></img></p><p>The architecture identified two basic actions a SOAP processor should
+ </td>
+ </tr>
+ </tbody>
+</table>
+
+<p><a name="bmXML"></a></p>
+</div>
+
+<div class="subsection">
+<a name="XML_Processing_Model"></a>
+
+<h3>XML Processing Model</h3>
+
+<p>As we mentioned above, the XML processing model of Axis2 has become a
+separate sub-project, called <a
+href="http://ws.apache.org/commons/axiom/index.html" class="externalLink"
+title="External Link">Apache Axiom</a>, in the Apache Web services project.
+Please refer to the <a href="OMTutorial.html">OM Tutorial</a> for more
+information.</p>
+
+<p><a name="bmSOAPPM"></a></p>
+</div>
+
+<div class="subsection">
+<a name="SOAP_Processing_Model"></a>
+
+<h3>SOAP Processing Model</h3>
+
+<p><img src="images/archi-guide/soap-processing.gif" name="Graphic4" alt=""
+align="bottom" width="755" height="348" border="0" /></p>
+
+<p>The architecture identified two basic actions a SOAP processor should
perform, sending and receiving SOAP messages. The architecture provides two
Pipes ('Flows'), to perform these two basic actions. The Axis Engine or the
driver of Axis2 defines two methods send() and receive() to implement these
two Pipes. The two pipes are named <i><b>In</b> Pipe</i> and <i><b>Out</b>
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.
+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 will
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
+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
-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
+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 <em>In Pipe</em>
consists of handlers and ends with the <a href="#mr">Message Receiver</a>,
-which consumes the SOAP message.</p><p>The processing explained above happens for each and every SOAP message
+which consumes the SOAP message.</p>
+
+<p>The processing explained above happens for each and every SOAP message
that is exchanged. After processing one message, Axis2 may decide to create
other SOAP messages, in which case more complex message patterns emerge.
However, Axis2 always views 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.
+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 Axis2 slang, they 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><a name="default"></a></p></div><div class="subsection"><a name="Axis2_Default_Processing_Model"></a><h3>Axis2 Default Processing Model</h3><p>Axis2 has some inbuilt handlers that run in inbuilt phases and they create
+areas for 'User Phases' which can be defined by the user.</p>
+
+<p><a name="default"></a></p>
+</div>
+
+<div class="subsection">
+<a name="Axis2_Default_Processing_Model"></a>
+
+<h3>Axis2 Default Processing Model</h3>
+
+<p>Axis2 has some inbuilt handlers that run in inbuilt phases and they create
the default configuration for Axis2. We will be looking more in to how to
-extend the default processing Model in the next section.</p><p>
-There are three special handlers defined in Axis2.
-<ol>
+extend the default processing Model in the next section.</p>
+
+<p>There are three special handlers defined in Axis2. <ol>
<li>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. ( See more information on
- <a href="http://www.wso2.net/tutorials/axis2/java/2006/06/18/operation-service-message-is-destined-to" class="externalLink" title="External Link">Dispatching</a>)</li>
-</ol><ul>
+ <a
+ href="http://www.wso2.net/tutorials/axis2/java/2006/06/18/operation-service-message-is-destined-to"
+ class="externalLink" title="External Link">Dispatching</a>)</li>
+</ol>
+<ul>
<li><a name="mr"></a>Message Receiver - Consumes the SOAP message and hands
it over to the application. The message receiver is the last handler of
the in-pipe</li>
@@ -308,13 +617,25 @@
message is destined to. Always runs as the last handler in the
out-pipe</p>
</li>
-</ul><a name="incomingsoap"></a></p></div><div class="subsection"><a name="Processing_an_Incoming_SOAP_Message"></a><h3>Processing an Incoming SOAP Message</h3><p>An incoming SOAP message is always received by a Transport Receiver
+</ul>
+<a name="incomingsoap"></a></p>
+</div>
+
+<div class="subsection">
+<a name="Processing_an_Incoming_SOAP_Message"></a>
+
+<h3>Processing an Incoming SOAP Message</h3>
+
+<p>An incoming SOAP message is always received by a Transport Receiver
waiting for the SOAP messages. Once the SOAP message arrives, the transport
Headers are parsed and a <a href="#messageContext">Message Context</a> is
created from the incoming SOAP message. This message context encapsulates all
the information, including the SOAP message itself, transport headers, etc.,
-inside it. 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 can
-happen in the server or in the client.</p><ol>
+inside it. 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 can
+happen in the server or in the client.</p>
+<ol>
<li><strong>Transport Phase</strong> - The handlers are in the phase that
processes transport specific information such as validating incoming
messages by looking at various transport headers, adding data into
@@ -326,7 +647,7 @@
information and put them in to the message context.</li>
<li><strong>Dispatch Phase</strong> - The Dispatchers run in this phase and
try to find the correct service and operation this particular message is
- destined for.<br></br>
+ destined for.<br />
The post condition of the dispatch phase (any phase can contain a post
condition) checks whether a service and an operation were found by the
dispatchers. If not, the execution will halt and give a "service not
@@ -341,12 +662,25 @@
registered with each Operation. This message receiver (associated to the
particular operation) will be executed as the last handler of this
phase.</li>
-</ol><p>There may be other handlers in any of these phases. Users may use custom
-handlers to override the mechanics in each of these phases.</p><p><a name="outgoing"></a></p></div><div class="subsection"><a name="Processing_of_the_Outgoing_Message"></a><h3>Processing of the Outgoing Message</h3><p>The<em> Out Pipe</em> is simpler because the service and the operation to
+</ol>
+
+<p>There may be other handlers in any of these phases. Users may use custom
+handlers to override the mechanics in each of these phases.</p>
+
+<p><a name="outgoing"></a></p>
+</div>
+
+<div class="subsection">
+<a name="Processing_of_the_Outgoing_Message"></a>
+
+<h3>Processing of the Outgoing Message</h3>
+
+<p>The<em>Out Pipe</em> is simpler because the service and the operation to
dispatch are known by the time the pipe is executed. The <em>Out Pipe</em>
-may be initiated by the</p><p><a href="#mr">Message Receiver</a> or the Client API implementation. Phases
-of the <em>Out Pipe</em> are described below:
-<ol>
+may be initiated by the</p>
+
+<p><a href="#mr">Message Receiver</a> or the Client API implementation.
+Phases of the <em>Out Pipe</em> are described below: <ol>
<li><strong>Message Initialize Phase</strong> - First phase of the <em>Out
Pipe</em>. Serves as the placeholder for the custom handlers.</li>
<li><strong>User Phases</strong> - Executes handlers in user-defined
@@ -355,81 +689,204 @@
taken from the associated transport configuration. The last handler would
be a transport sender which will send the SOAP message to the target
endpoint.</li>
-</ol><a name="extending"></a></p></div><div class="subsection"><a name="Extending_the_SOAP_Processing_Model"></a><h3>Extending the SOAP Processing Model</h3><p>Above, we discussed the default processing model of Axis2. Now let us
+</ol>
+<a name="extending"></a></p>
+</div>
+
+<div class="subsection">
+<a name="Extending_the_SOAP_Processing_Model"></a>
+
+<h3>Extending the SOAP Processing Model</h3>
+
+<p>Above, we discussed the default processing model of Axis2. Now let us
discuss the extension mechanism for the SOAP processing model. After all, the
whole effort of making this SOAP engine/processing model was focused on
-making it extendable.</p><p>The idea behind introducing step-wise processing of the SOAP message in
+making it extendable.</p>
+
+<p>The idea behind introducing step-wise processing of the SOAP message in
terms of handlers and phases is to allow easier modification of the
processing order. The notion of phases makes it easier to place handlers in
between other handlers. This enables modification of the default processing
-behavior. The SOAP Processing Model can be extended with <a href="#extendingwithhandlers">handlers</a> or <a href="#extendingwithmodules">modules</a>.</p></div><div class="subsection"><a name="Extending_the_SOAP_Processing_Model_with_Handlers"></a><h3>Extending the SOAP Processing Model with Handlers</h3><p>The handlers in a module can specify the phase they need to be placed in.
+behavior. The SOAP Processing Model can be extended with <a
+href="#extendingwithhandlers">handlers</a> or <a
+href="#extendingwithmodules">modules</a>.</p>
+</div>
+
+<div class="subsection">
+<a name="Extending_the_SOAP_Processing_Model_with_Handlers"></a>
+
+<h3>Extending the SOAP Processing Model with Handlers</h3>
+
+<p>The handlers in a module 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,</p><ol>
+phase rules. Phase rules will place a handler,</p>
+<ol>
<li>as the first handler in a phase,</li>
<li>as the last handler in a phase,</li>
<li>before a given handler,</li>
<li>or after a given handler.</li>
-</ol><p><a name="extendingwithmodules"></a></p></div><div class="subsection"><a name="Extending_the_SOAP_Processing_Model_with_Modules"></a><h3>Extending the SOAP Processing Model with Modules</h3><p>Axis2 defines an entity called a 'module' that can introduce handlers and
+</ol>
+
+<p><a name="extendingwithmodules"></a></p>
+</div>
+
+<div class="subsection">
+<a name="Extending_the_SOAP_Processing_Model_with_Modules"></a>
+
+<h3>Extending the SOAP Processing Model with Modules</h3>
+
+<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 includes:</p><ul>
+convenient packaging that includes:</p>
+<ul>
<li>A set of handlers and</li>
<li>An associated descriptor which includes the phase rules</li>
-</ul><p>Modules have the concept of being 'available' and 'engaged'.
+</ul>
+
+<p>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-*
+to implement a WS-* functionality such as WS-Addressing.</p>
+
+<p>Apart from the extension mechanism based on the handlers, the WS-*
specifications may suggest a requirement for adding new operations. For
example, once a user adds Reliable Messaging capability to a service, the
"Create Sequence" operation needs to be available to the service endpoint.
This can be implemented by letting the modules define the operations. Once
the module is engaged to a service, the necessary operations will be added to
-that service.</p><p>A service, operation, or the system may engage a module. Once the module
+that service.</p>
+
+<p>A service, operation, 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 engaged them.</p><p>Modules cannot be added (no hot deployment) while the Axis2 engine is
-running, but they will be available once the system is restarted.</p><p><a name="bmDeployment"></a></p></div><div class="subsection"><a name="Deployment"></a><h3>Deployment</h3><p>The Deployment Model provides a concrete mechanism to configure Axis2.
-This model has three entities that provide the configuration.</p><p><a name="xmlfile"></a></p></div><div class="subsection"><a name="The_axis2_xml_file"></a><h3>The axis2.xml file</h3><p>This file holds the global configuration for the client and server, and
-provides the following information:</p><ol>
+to the entity that engaged them.</p>
+
+<p>Modules cannot be added (no hot deployment) while the Axis2 engine is
+running, but they will be available once the system is restarted.</p>
+
+<p><a name="bmDeployment"></a></p>
+</div>
+
+<div class="subsection">
+<a name="Deployment"></a>
+
+<h3>Deployment</h3>
+
+<p>The Deployment Model provides a concrete mechanism to configure Axis2.
+This model has three entities that provide the configuration.</p>
+
+<p><a name="xmlfile"></a></p>
+</div>
+
+<div class="subsection">
+<a name="The_axis2_xml_file"></a>
+
+<h3>The axis2.xml file</h3>
+
+<p>This file holds the global configuration for the client and server, and
+provides the following information:</p>
+<ol>
<li>The global parameters</li>
<li>Registered transport-in and transport-outs</li>
<li>User-defined phase names</li>
<li>Modules that are engaged globally (to all services)</li>
<li>Globally defined <a href="#mr">Message Receivers</a></li>
-</ol><p><a name="servicearchive"></a></p></div><div class="subsection"><a name="Service_Archive"></a><h3>Service Archive</h3><p>The Service archive must have a <em>META-INF/<a href="resources/schemas/services.xsd">services.xml</a></em> file and may
+</ol>
+
+<p><a name="servicearchive"></a></p>
+</div>
+
+<div class="subsection">
+<a name="Service_Archive"></a>
+
+<h3>Service Archive</h3>
+
+<p>The Service archive must have a <em>META-INF/<a
+href="resources/schemas/services.xsd">services.xml</a></em> file and may
contain the dependent classes. The <em>services.xml</em> file has the
-following information.</p><ol>
+following information.</p>
+<ol>
<li>Service level parameters</li>
<li>Modules that are engaged at service level</li>
<li>Service Specific <a href="#mr">Message Receivers</a></li>
<li>Operations inside the service</li>
-</ol><p><a name="modulearchive"></a></p></div><div class="subsection"><a name="Module_Archive"></a><h3>Module Archive</h3><p>Module archive must have a META-INF/<a href="resources/schemas/module.xsd">module.xml</a> file and dependent
+</ol>
+
+<p><a name="modulearchive"></a></p>
+</div>
+
+<div class="subsection">
+<a name="Module_Archive"></a>
+
+<h3>Module Archive</h3>
+
+<p>Module archive must have a META-INF/<a
+href="resources/schemas/module.xsd">module.xml</a> 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 starts up, Axis2 prompts the deployment model to create an
+Operations defined in the module.</p>
+
+<p>When the system starts up, Axis2 prompts the deployment model to create an
Axis Configuration. The deployment model first finds the axis2.xml file and
builds the global configuration. Then it checks for the module archives and
then for the service archives. After that, the corresponding services and
modules are added to the Axis Configuration. The system will build contexts
on top of the Axis Configuration. After this, Axis2 is ready to send or
-receive SOAP messages. Hot deployment is only allowed for services.</p><p><a name="bmClientAPI"></a></p></div><div class="subsection"><a name="Client_API"></a><h3>Client API</h3><p>There are three parameters that decide the nature of the Web service
-interaction.</p><ol>
+receive SOAP messages. Hot deployment is only allowed for services.</p>
+
+<p><a name="bmClientAPI"></a></p>
+</div>
+
+<div class="subsection">
+<a name="Client_API"></a>
+
+<h3>Client API</h3>
+
+<p>There are three parameters that decide the nature of the Web service
+interaction.</p>
+<ol>
<li>Message Exchange Pattern (MEP)</li>
<li>The behavior of the transport, whether it's One-Way or Two-Way</li>
<li>Synchronous/ Asynchronous behavior of the Client API</li>
-</ol><p>Variations of the three parameters can result in an indefinite number of
+</ol>
+
+<p>Variations of the three parameters can result in an indefinite number of
scenarios. Even though Axis2 is built on a core that supports any messaging
interaction, the developers were compelled to provide in-built support for
-only two most widely used Message Exchange Patterns (MEPs).</p><p>The two supported MEPs are One-Way and the In-Out (Request-Response)
+only two most widely used Message Exchange Patterns (MEPs).</p>
+
+<p>The two supported MEPs are One-Way and the In-Out (Request-Response)
scenarios in 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><p><a name="oneway"></a></p></div><div class="subsection"><a name="One_Way_Messaging_Support"></a><h3>One Way Messaging Support</h3><p>The One-Way support is provided by the <code>fireAndForget</code> method
+Client API supports.</p>
+
+<p><a name="oneway"></a></p>
+</div>
+
+<div class="subsection">
+<a name="One_Way_Messaging_Support"></a>
+
+<h3>One Way Messaging Support</h3>
+
+<p>The One-Way support is provided by the <code>fireAndForget</code> method
of <code>ServiceClient</code>. For one way invocations, one can use 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><p><a name="requestresponse"></a></p></div><div class="subsection"><a name="In-Out__Request_Response__Messaging_Support"></a><h3>In-Out (Request Response) Messaging Support</h3><p>The In-Out support is provided by the <code>sendReceive()</code> method in
+channel.</p>
+
+<p><a name="requestresponse"></a></p>
+</div>
+
+<div class="subsection">
+<a name="In-Out__Request_Response__Messaging_Support"></a>
+
+<h3>In-Out (Request Response) Messaging Support</h3>
+
+<p>The In-Out support is provided by the <code>sendReceive()</code> method in
ServiceClient. This provides a simpler interface for the user. The Client API
-has four ways to configure a given message exchange</p><ol>
+has four ways to configure a given message exchange</p>
+<ol>
<li>Blocking or Non-Blocking nature - this can be decided by using
<code>sendReceive()</code> or <code>sendReceiveNonBlocking()</code>
methods</li>
@@ -438,23 +895,49 @@
<li>Use Separate Channel - determines whether the response is sent over a
separate transport connection or not. This can be false only when the
sender and listener transport is same and is a Two-Way transport.</li>
-</ol><p>Depending on the values of the above four parameters, Axis2 behaves
-differently.</p><p><a name="bmTransports"></a></p></div><div class="subsection"><a name="Transports"></a><h3>Transports</h3><p>Axis2 has two basic constructs for transports, namely: Transport Senders
-and Transport Receivers. These are accessed via the AxisConfiguration.</p><p>The incoming transport is the transport via which the AxisEngine receives
+</ol>
+
+<p>Depending on the values of the above four parameters, Axis2 behaves
+differently.</p>
+
+<p><a name="bmTransports"></a></p>
+</div>
+
+<div class="subsection">
+<a name="Transports"></a>
+
+<h3>Transports</h3>
+
+<p>Axis2 has two basic constructs for transports, namely: Transport Senders
+and Transport Receivers. These are accessed via the AxisConfiguration.</p>
+
+<p>The incoming transport is the transport via which the AxisEngine receives
the message. The outgoing transport is decided based on the addressing
information (wsa:ReplyTo and wsa:FaultTo). If addressing information is not
available and if the server is trying to respond, then the out going
transport will be the outputstream of the incoming transport (if it is
-two-way transport).</p><p>At the client side, the user is free to specify the transport to be
-used.</p><p>Transport Senders and Transport Receivers contain the following
-information.</p><ol>
+two-way transport).</p>
+
+<p>At the client side, the user is free to specify the transport to be
+used.</p>
+
+<p>Transport Senders and Transport Receivers contain the following
+information.</p>
+<ol>
<li>Transport Sender for Out Configuration</li>
<li>Transport Listener for In Configuration</li>
<li>Parameters of the transport</li>
-</ol><p>Each and every transport out configuration defines a transport sender. The
-transport sender sends the SOAP message depending on its configuration.</p><p>The transport receiver waits for the SOAP messages, and for each SOAP
+</ol>
+
+<p>Each and every transport out configuration defines a transport sender. The
+transport sender sends the SOAP message depending on its configuration.</p>
+
+<p>The 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 supports the following transports:</p><ol>
+message.</p>
+
+<p>Axis2 presently supports the following transports:</p>
+<ol>
<li>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
@@ -464,25 +947,66 @@
<li>SMTP - This works off a single email account. Transport receiver is a
thread that checks for emails in fixed time intervals.</li>
<li>JMS</li>
-</ol><p><a name="bmWSDL" id="bmWSDL"></a></p></div><div class="subsection"><a name="Code_Generation"></a><h3>Code Generation</h3><p>Although the basic objective of the code generation tools has not changed,
+</ol>
+
+<p><a name="bmWSDL" id="bmWSDL"></a></p>
+</div>
+
+<div class="subsection">
+<a name="Code_Generation"></a>
+
+<h3>Code Generation</h3>
+
+<p>Although the basic objective of the code generation tools 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
+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-new.gif" name="Graphic6" alt="" align="bottom" border="0"></img></p><p>The fact here is that it is the same information that is extracted from
+describes how this shows up in the architecture of the tool.</p>
+
+<p><img src="images/archi-guide/CodegenArchitecture-new.gif" name="Graphic6"
+alt="" align="bottom" 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. First, an AxisService is populated
from a WSDL. Then the code generator extracts information from the
AxisService and creates an XML, which is language independent. This emitted
XML is then parsed with the relevant XSL to generate code for the relevant
language. No matter what the output language is, the process is the same
-except for the template that is being used.</p><p><a name="bmDB" id="bmDB"></a></p></div><div class="subsection"><a name="Data_Binding"></a><h3>Data Binding</h3></div><div class="subsection"><a name="Integration_with_the_Code_Generation_Engine"></a><h3>Integration with the Code Generation Engine</h3><p>Databinding for Axis2 is implemented in an interesting manner. Databinding
+except for the template that is being used.</p>
+
+<p><a name="bmDB" id="bmDB"></a></p>
+</div>
+
+<div class="subsection">
+<a name="Data_Binding"></a>
+
+<h3>Data Binding</h3>
+</div>
+
+<div class="subsection">
+<a name="Integration_with_the_Code_Generation_Engine"></a>
+
+<h3>Integration with the Code Generation Engine</h3>
+
+<p>Databinding for Axis2 is implemented in an interesting manner. Databinding
has not been included in the core deliberately, and hence the code generation
allows different data binding frameworks to be plugged in. This is done
through an extension mechanism where the codegen engine first calls the
extensions and then executes the core emitter. The extensions populate a map
of QNames vs. class names that is passed to the code generator on which the
-emitter operates on.</p><p><strong>The following diagram shows the structure:</strong></p><p><img src="images/codegen.gif" name="Graphic7" align="bottom" border="0" alt=""></img></p><p><strong>The following databinding extensions are available:</strong></p><ol>
+emitter operates on.</p>
+
+<p><strong>The following diagram shows the structure:</strong></p>
+
+<p><img src="images/codegen.gif" name="Graphic7" align="bottom" border="0"
+alt="" /></p>
+
+<p><strong>The following databinding extensions are available:</strong></p>
+<ol>
<li><strong>ADB</strong> - ADB (Axis Data Binding ) is a simple framework
that allows simple schemas to be compiled. It is lightweight and simple,
works off StAX and fairly performant. However, it does not support the
@@ -496,7 +1020,17 @@
<li><strong>JibX</strong> - This is the most recent addition to the family
of databinding extensions, and it is also another option the users have
for data binding.</li>
-</ol><p><a name="serial" id="serial"></a></p></div><div class="subsection"><a name="Serialization_and_De-Serialization_of_Data_bound_classes"></a><h3>Serialization and De-Serialization of Data bound classes</h3><p>AXIOM is based on a StAX API (Streaming API for XML). Xml-beans supports
+</ol>
+
+<p><a name="serial" id="serial"></a></p>
+</div>
+
+<div class="subsection">
+<a name="Serialization_and_De-Serialization_of_Data_bound_classes"></a>
+
+<h3>Serialization and De-Serialization of Data bound classes</h3>
+
+<p>AXIOM is based on a StAX API (Streaming API for XML). 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 code generation, there will be utility methods generated inside
@@ -504,14 +1038,34 @@
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,
the following methods will be generated inside the relevant classes.</p>
- <div class="source"><pre>public static
+
+<div class="source">
+<pre>public static
org.apache.axiom.om.OMElement toOM(org.soapinterop.xsd.EchoStringParamDocument
param)// This method will handle the serialization.
public static org.apache.xmlbeans.XmlObject
fromOM(org.apache.axis2.om.OMElement param, java.lang.Class type) //This
method will handle the de-serialization.
+</pre>
+</div>
+</div>
+</div>
+</div>
+</div>
+
+<div class="clear">
+<hr />
+</div>
+
+<div id="footer">
+<div class="xright">
+© 2004-2007, Apache Software Foundation</div>
-</pre></div>
- </div></div></div></div><div class="clear"><hr></hr></div><div id="footer"><div class="xright">© 2004-2007, Apache Software Foundation</div><div class="clear"><hr></hr></div></div></body></html>
\ No newline at end of file
+<div class="clear">
+<hr />
+</div>
+</div>
+</body>
+</html>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-cvs-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-cvs-help@ws.apache.org