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 2006/09/24 12:23:52 UTC
svn commit: r449385 - in /webservices/axis2/trunk/java/xdocs/1_1:
Axis2-rpc-support.html index.html
Author: chatra
Date: Sun Sep 24 03:23:48 2006
New Revision: 449385
URL: http://svn.apache.org/viewvc?view=rev&rev=449385
Log:
completed final review of Axis2-rpc-support.html
Modified:
webservices/axis2/trunk/java/xdocs/1_1/Axis2-rpc-support.html
webservices/axis2/trunk/java/xdocs/1_1/index.html
Modified: webservices/axis2/trunk/java/xdocs/1_1/Axis2-rpc-support.html
URL: http://svn.apache.org/viewvc/webservices/axis2/trunk/java/xdocs/1_1/Axis2-rpc-support.html?view=diff&rev=449385&r1=449384&r2=449385
==============================================================================
--- webservices/axis2/trunk/java/xdocs/1_1/Axis2-rpc-support.html (original)
+++ webservices/axis2/trunk/java/xdocs/1_1/Axis2-rpc-support.html Sun Sep 24 03:23:48 2006
@@ -10,27 +10,27 @@
<body>
<h1>Axis2 RPC Support</h1>
-<p>This documents talks about the Axis2's Remote Procedure Calls support in
-easy to understand implementation steps. </p>
+<p>This documents talks about the Axis2's Remote Procedure Calls support in a
+set of easy to understand implementation steps.</p>
<h2>Introduction</h2>
<p>Axis2 Remote Procedure Calls (RPC) support may seem somewhat tricky and
-confusing at the first glance. However Axis2 RPC strategy is based on a well
+confusing at first glance. However, Axis2 RPC strategy is based on a well
defined set of rules and once the details are in place, it becomes clear as
day. This document aims to drill down to the details of this strategy and
fills up most of the fairly unknown bits and pieces. Note that Axis2
currently does not support the rpc/encoded style fully. It's main support is
for the rpc/lit style.</p>
-<p>We will discuss the Axis2 RPC strategy in steps</p>
+<p>We will discuss the Axis2 RPC strategy in the following steps</p>
-<h2>Step 1 - Converting RPC style WSDL's into Doc/Lit style WSDL</h2>
+<h2>Step 1 - Converting RPC Style WSDL's into Doc/Lit Style WSDL</h2>
-<p>This is probably the most confusing part of rpc strategy. Since the Axis2
-code generator is based on pure doc/lit style , the first step of the code
-generation process is to generate a wrapper schema. This wrapper generation
-can be easily explained by using an example.</p>
+<p>This is probably the most confusing part of the rpc strategy. Since the
+Axis2 code generator is based on pure doc/lit style, the first step of the
+code generation process is to generate a wrapper schema. This wrapper
+generation can be easily explained by using an example.</p>
<p>Take the following piece of WSDL</p>
<pre> .....
@@ -65,31 +65,31 @@
need wrapping in the following order.</p>
<ol>
<li>The first element needs to have the operation name as the local name
- and the operation namespace ( which happens to be the namespace of the
+ and the operation namespace (which happens to be the namespace of the
porttype - in this case the targetnamespace of the WSDL)</li>
<li>The children of this element are non namespace qualified elements with
- the part names as local names (refered to as <strong>part
+ the part names as local names (referred to as <strong>part
element</strong>)</li>
<li>In case the part refers to a standard type like the example WSDL, the
content of the part element would be of that type. If the part refers to
- a complex type defined in the schema the content of the part element
+ a complex type defined in the schema, the content of the part element
becomes of that type. Having an element reference in the part when the
binding is rpc is invalid.</li>
</ol>
<p>For example the input wire message for the echo operation mentioned in the
-above WSDL fragment would look like this</p>
+above WSDL fragment would look like this:</p>
<pre> <op:<strong>echo</strong> xmlns:op="porttype namespace">
<<strong>part1</strong>>Hello World</part1>
<<strong>part2</strong>>123</part2>
</op:echo></pre>
-<p>Note the element names in bold. The first one is the operation name, the
-second and third are part names. It can be seen that it is quite possible to
-generate a schema, representing this structure and then treat the whole
-service as pure doc/lit service. In this case following is the piece of
-schema generated to make this rpc to doc conversion. Note that in this case
-the wire message stays unchanged. It is only a different WSDL authoring
+<p>Note that the element name is in bold. The first one is the operation
+name, the second and third are part names. It can be seen that it is quite
+possible to generate a schema, representing this structure and then treat the
+whole service as pure doc/lit service. In this case, following is the piece
+of schema generated to make this rpc to doc conversion. Note that in this
+case the wire message stays unchanged. It is only a different WSDL authoring
style</p>
<pre> <xs:element name="echo">
<xs:complexType>
@@ -102,7 +102,7 @@
<p>What the Axis2 code generator does is exactly this. By looking at the
binding style, it generates a wrapper schema in places required before
-handing over the Axis* hierarchy to the code generator engine.In every case
+handing over the Axis* hierarchy to the code generator engine. In every case
(even when the schema needs to be unwrapped) this wrapping part will take
place!</p>
@@ -113,13 +113,13 @@
is a mapping table!</p>
<ol>
<li>When the schema is unwrapped where would that unwrapping information
- stay ?
+ stay?
<p>Good question - It needs to be a store that keeps the information
- seperated. Hmm.. What can we use here ? Why, the Axis * hierarchy! it has
- nicely seperated information holders and a parameter store that can hold
- a information bean</p>
+ seperated. Hmm.. What can we use here ? Why of course, the Axis *
+ hierarchy! It has nicely separated information holders and a parameter
+ store that can hold a information bean.</p>
</li>
- <li>How do we maintain uniqueness among message part names ?
+ <li>How do we maintain uniqueness among message part names?
<p>Another Good question - part names are only unique across a message
and not globally. But due to the fact that we have a global mapping table
we need a way to differentiate between parts of different messages. The
@@ -131,7 +131,7 @@
<p>Given these solutions the first step in unwrapping is to walk the schema
and figure out the unwrappable items. The key player of the unwrapping
process is the unwrapping extension. What it does is to walk a given schema
-andfigure out the unwrappable parts if there are any.</p>
+and figure out the unwrappable parts if there are any.</p>
<p>The current unwrapper looks for the following patterns and fails if it is
not found!</p>
@@ -147,17 +147,17 @@
<p>Once this pattern is detected the unwrapper details will be added to the
relevant AxisMessage component</p>
-<h2>Step 3 - Populate type information</h2>
+<h2>Step 3 - Populate type Information</h2>
<p>The next step is to populate the type information for the parts. This has
-to be explicitly done by the data binding extensions and currently the ADB
-and XMLbeans extensions populate the relavant AxisMessage by looking up their
+to be explicitly done by the data binding extensions, and currently the ADB
+and XMLbeans extensions populate the relevant AxisMessage by looking up their
generated type systems. This type information goes into the AxisMessage
inside a MessagePartInformationHolder instance.</p>
-<p>The following code fragement from the ADB extension shows how the
+<p>The following code fragment from the ADB extension shows how the
AxisMessages get populated with the relevant type information. The code is
-almost the same for the XMLBeans extension.Note the items in bold</p>
+almost the same for the XMLBeans extension. Note the items in bold.</p>
<pre> if (message.getParameter(Constants.UNWRAPPED_KEY) != null) {
XmlSchemaType schemaType = message.getSchemaElement().getSchemaType();
if (schemaType instanceof XmlSchemaComplexType) {
@@ -210,16 +210,16 @@
}
}</pre>
-<h2>Step 4 - Generate code with unwrapped parameters</h2>
+<h2>Step 4 - Generate Code with Unwrapped Parameters</h2>
<p>The next step is generating the actual code. The
AxisServiceBasedMultiLanguageEmitter has a method that generates the XML
model for the input parameters and that method includes the relevant part
-parameters inside the relavant top level input parameter element</p>
+parameters inside the relavant top level input parameter element.</p>
<p>The relevant part of the XML model looks like this. Note that this
intermediate XML model is the one that is parsed against the Stylesheets to
-generate the code</p>
+generate the code.</p>
<pre><input>
<param name="param4" type="com.example.www.ServiceNameStub.Echo" shorttype="Echo" value="null" location="body" opname="echo">
<param name="param5" type="java.lang.String" shorttype="String" value="null" location="body" opname="echo" partname="Part1"
@@ -228,18 +228,18 @@
</param>
</input></pre>
-<p>The next part is upto the template to handle. Basically the template looks
-after the generation of multiple parameters into the method signatures and
-the then the generating of the relavant serialization and deserialization
-code for the parameters!</p>
+<p>The next part is upto the template to handle. Basically, the template
+looks after the generation of multiple parameters into the method signatures
+and then the generating of the relevant serialization and deserialization
+code for the parameters.</p>
<h2>Bringing the Parameters Together and Exploding Them</h2>
-<p>This is a somewhat contraversial area. The current Axis2 code generator
-does the wapping and unwrapping at the object level and not the XML level. In
-short the exploded parameters are only a conveneince and the that explosion
-does not run down to the XML level. The following example of generated source
-code makes this clear</p>
+<p>This is a somewhat controversial area. The current Axis2 code generator
+does the wrapping and unwrapping at the object level and not the XML level. In
+short the exploded parameters are only a convenience and the explosion does
+not run down to the XML level. The following example of generated source code
+makes this clear:</p>
<pre> private org.apache.axiom.soap.SOAPEnvelope toEnvelope(
org.apache.axiom.soap.SOAPFactory factory, java.lang.String param1,
int param2, boolean optimizeContent) {
@@ -254,13 +254,13 @@
}</pre>
<p>Note the lines in bold. The wrapped class will anyway be instantiated and
-used at the end but what the user sees is different. Exploding the parameters
-happens in a similar way!</p>
+used at the end, but what the user sees is different. Exploding the
+parameters happens in a similar way!</p>
<h2>Conclusion</h2>
-<p>Axis2 RPC support is a sort of misty area but it is based on a well
-defined set of rules. It is not <em>that</em> misty after all</p>
+<p>Axis2 RPC support is a sort of misty area, but it is based on a well
+defined set of rules which makes it not <em>that</em> misty after all!</p>
<hr />
</body>
</html>
Modified: webservices/axis2/trunk/java/xdocs/1_1/index.html
URL: http://svn.apache.org/viewvc/webservices/axis2/trunk/java/xdocs/1_1/index.html?view=diff&rev=449385&r1=449384&r2=449385
==============================================================================
--- webservices/axis2/trunk/java/xdocs/1_1/index.html (original)
+++ webservices/axis2/trunk/java/xdocs/1_1/index.html Sun Sep 24 03:23:48 2006
@@ -110,7 +110,7 @@
<tr>
<td><a href="Axis2-rpc-support.html">Axis2 RPC Support</a></td>
<td>This documents talks about the Axis2's Remote Procedure Calls
- support in easy to understand implementation steps</td>
+ support in a set of easy to understand implementation steps</td>
</tr>
<tr>
<td><a href="mtom-guide.html">MTOM Guide -Sending Binary Data with
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-cvs-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-cvs-help@ws.apache.org