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/03/10 11:39:34 UTC
svn commit: r384760 -
/webservices/axis2/trunk/java/xdocs/latest/WS_policy.html
Author: chatra
Date: Fri Mar 10 02:39:33 2006
New Revision: 384760
URL: http://svn.apache.org/viewcvs?rev=384760&view=rev
Log:
policy document complete for 0.95 release
Modified:
webservices/axis2/trunk/java/xdocs/latest/WS_policy.html
Modified: webservices/axis2/trunk/java/xdocs/latest/WS_policy.html
URL: http://svn.apache.org/viewcvs/webservices/axis2/trunk/java/xdocs/latest/WS_policy.html?rev=384760&r1=384759&r2=384760&view=diff
==============================================================================
--- webservices/axis2/trunk/java/xdocs/latest/WS_policy.html (original)
+++ webservices/axis2/trunk/java/xdocs/latest/WS_policy.html Fri Mar 10 02:39:33 2006
@@ -34,7 +34,7 @@
those requirements without requiring the service author to write even single
line of code.</p>
-<h2>Client Side WS-Policy Supprt</h2>
+<h2>Client Side WS-Policy Support</h2>
<p>This release <strong>fully supports WS Policy at client-side</strong>. It
means that when you codegen a stub against a WSLD which contains policies,
@@ -46,102 +46,80 @@
<h3>How it works:</h3>
-<h4>Phase1: At PolicyEvaluator</h4>
+<h4>Phase 1: At PolicyEvaluator</h4>
<p>Codegen engine runs few of its registered extensions before it generates
the stub. When PolicyEvalutor (which is a registered Codegen extension) is
initialized, it populates a registry of namespaces of supported policies to
PolicyExtensions.</p>
-<p>For instance module foo might have a mapping of namespace
+<p>For instance, module foo might have a mapping of namespace
http://test.com/foo which means any primitive assertion which has this
-namespace will be processed by this module. That module might implements the
-ModulePolicyExtension interface via PolicyExtension object can be
+namespace will be processed by this module. Foo module might implement the
+ModulePolicyExtension interface through which PolicyExtension object can be
obtained.</p>
-<p>A PolicyExtension is the access point for a module to add any other
-methods to the stub. For instance Reliable Messaging module can add
+<p>A <strong>PolicyExtension</strong> is the access point for a module to add
+any other methods to the stub. For instance Reliable Messaging module can add
createSequence() and endSequence() methods to the stub, that the user must
-call to start a RM sequence and ends a sequence.</p>
+call to start and end an RM sequence.</p>
<p>Then at the engagement of PolicyEvaluator, effective policy of each
operation is calculated based on policy information declared in the WSDL
-document. Here we assumes that effective policy of an operation contains a
-single alternative (Multiple policy alternatives are not supported). Then we
-split that policy into few other policies such that each policy will contains
-primitive assertions belonging to only one namespace</p>
-<pre> <wsp:Policy> <wsp:Policy> <wsp:Policy>
- <wsp:Policy>
- <a:Foo/> <a:Foo/> <b:Foo/> <c:Bar/>
- <a:Bar/> => <a:Bar/> </wsp:Policy>
- </wsp:Policy>
- <b:Foo/> </wsp:Policy>
- <c:Bar/>
+document. Here we assume that effective policy of an operation contains a
+single alternative (<strong>Multiple policy alternatives are not
+supported</strong>). Then we split that policy as follows into few other
+policies such that, each policy will contain primitive assertions belonging
+to only one namespace.</p>
+<pre> <wsp:Policy> <wsp:Policy> <wsp:Policy> <wsp:Policy>
+ <a:Foo/> <a:Foo/> <b:Foo/> <c:Bar/>
+ <a:Bar/> => <a:Bar/> </wsp:Policy> </wsp:Policy>
+ <b:Foo/> </wsp:Policy>
+ <c:Bar/>
</wsp:Policy></pre>
-<p>Then each policy is given to the appropriate PolicyExtension with an</p>
-
-<p>org.w3c.Element type object to which the module can append any other
-elements/attributes it wishes. Those attributes/elements should resolved to
+<p>Then each policy is given to the appropriate PolicyExtension with an
+org.w3c.Element type object to which the module can append any other
+elements/attributes it wishes. Those attributes/elements should resolve to
meaningful stub functions via PolicyExtensionTemplate.xsl at latter point of
time.</p>
<p>For instance depending on the policy, Security module can append
<username>, <passwd> elements to the given element as children,
which are later resolved into setUsername(..), setPasswd(..), functions of
-the stub. This way a module can add additional methods to the stub which can
-be used get specific parameters to the module. Those methods store any user
-input in the ServiceClient properties</p>
-
-<p>(ServiceClient.getOptions().putProperty(...)) which can later be access by
+the stub. This way a module can include additional methods to the stub which
+can be used to get specific parameters to the module. These methods store any
+user input in the ServiceClient properties
+(ServiceClient.getOptions().putProperty(...)) which can later be accessed by
the module.</p>
-<h4>Phase2: At MultiLanguageClientEmitter</h4>
+<h4>Phase 2: At MultiLanguageClientEmitter</h4>
-<p>Further, effective policies (based on the WSDL) at appropriate levels</p>
-
-<p>(service level, operation level) are stored as policy strings in the stub.
+<p>Further, effective policies (based on the WSDL) at appropriate levels
+(service level, operation level) are stored as policy strings in the stub.
Few more generic methods are also added to the stub which are used to
-evaluate/processing policies at runtime.</p>
-
-<h4>Phase3: Runtime</h4>
+evaluate/process policies at runtime.</p>
-<p>When a new stub object is created, the policy strings in the stub are</p>
+<h4>Phase 3: Runtime</h4>
-<p>converted into policy objects and merge together to get the effective</p>
-
-<p>policies of each operation. That policy information is stored in the</p>
-
-<p>AxisOperation object which a module can access at later point of time.</p>
-
-<p></p>
+<p>When a new stub object is created, the policy strings in the stub are
+converted into policy objects and merged together to get the effective
+policies of each operation. These effective policies are stored in
+appropriate AxisOperation objects which a module can access at later point of
+time.</p>
<p>Then based on its policy each AxisOperation is engaged to a set of
modules.</p>
-<p></p>
-
-<p>And when the stub method is invoked, those modules which are engaged to</p>
-
-<p>that AxisOperation, access the policy information for that operation
-via</p>
-
-<p>AxisOperation object. It can get other information needed from the</p>
-
-<p>MessageContext which are get stored by stub methods which the module
-has</p>
-
-<p>added to the stub earlier. The modules are required to loads their
-configurations according to that policy information and properties they get
-via MessageContext.</p>
-
-<p></p>
-
-<p></p>
-
-<p>Server side:</p>
+<p>When the stub method is invoked, those modules which are engaged to that
+AxisOperation, access the effective policy for that operation via
+AxisOperation object. It can get other information needed from the
+MessageContext which get stored by stub methods which the module has added to
+the stub earlier. The modules are required to loads their configurations
+according to the effective policy which is set in AxisOperation and
+properties they get via MessageContext.</p>
-<h2>What's in this release?</h2>
+<h2>Server Side WS-Policy Support</h2>
<p>In this current release Axis2 framework uses ws-commons/policy as an
object model to manipulate policy documents. All its description builders