axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sanka Samaranayake <ssa...@gmail.com>
Subject Re: Fwd:[Axis2] State of WS-Policy?
Date Wed, 15 Feb 2006 18:16:53 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Hi Srinath, all,

At this point, Axis2 Codegen does support WS Policies at client-side.

Let me briefly explain how it happens..

Phase1: (At PolicyEvaluator)

Codegen engine runs few of its registered extension 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 module. 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.

e.g. <mns:MyAssertion xmlns:mns="http:tests.org/foo">
	...
     </mns:MyAssertion>

In other words the above assertion in a policy will be processed by the
module 'foo'. Those modules are located using the repository-path which
is given as an argument.

Then at the engagement, 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

<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>

Then each policy is given to the appropriate module with an
org.w3c.Element type object to which the module can append any
other elements/attributes it wishes. Those attributes/elements should
resolved to meaningful stub functions via PolicyExtensionTemplate.xsl at
latter point of time.

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
(ServiceClient.getOptions().putProperty(...)) which can later be access
by the module.

Phase2: (At MultiLanguageClientEmitter)

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.

Runtime:

When a new stub object is created, the policy strings in the stub are
converted into policy objects and merge together to get the effective
policies of each operation. That policy information is stored in the
AxisOperation object which a module can access at later point of time.

Then based on its policy each AxisOperation is engaged to a set of modules.

And when the stub method is invoked, those modules which are engaged to
that AxisOperation, access the policy information for that operation via
AxisOperation object. It can get other information needed from the
MessageContext which are get stored by stub methods which the module has
added to the stub earlier. The modules are required to loads their
configurations according to that policy information and properties they
get via MessageContext.

Hope this'll help !!

Best,
Sanka


Srinath Perera wrote:
> Oops forget to put the prefix, seems I have been too far away
> 
> ---------- Forwarded message ----------
> From: Srinath Perera <hemapani@gmail.com>
> Date: Feb 13, 2006 5:29 PM
> Subject: State of WS-Policy?
> To: "axis-dev@ws.apache.org" <axis-dev@ws.apache.org>
> 
> 
> Hi All;
> 
> I want to ask the state of our policy implementation, and how much the
> policy descriptions are bound to modules?
> 
> I saw from the code, if there are modules engaged, they are printed
> out in WSDL as policy, do we support other side, engaging and
> configure the
> modules according to the WS-Policy information given in Axis2 configuration.
> 
> I am more interested in having the policy support in the client side,
> and I believe it should be WSDL based. Have we done any work on it? If
> not I would like to try to do something on the enabling them on the
> dynamic client interface (give a wsdl and configure the
> ServiceCleint/OperationClient) as a start
> 
> I wrote few thoughts and a possible implementation down, I think most
> of it is already done. I want to tie the loose threads and use it and
> to fix what ever I can.  Please comment.
> 
> Thanks
> Srinath
> 
> 
> WS-Policy and Axis2 Modules are kind of parallel, I would view them as
> one is abstract representation and other is implementation of the
> representation. To build a policy model for Axis2 we need to describe
> two scenarios
> 
> 1) Build a Service, engage Modules and then create a WSDL description.
> This is the most natural scenario for the Server side
> 2) Given a WSDL, extract the Policy and create a Service with modules engaged
> 
> The main work we have to do is
> 1) Provide a mapping from a given type of policy to a specific module,
> then hand over handling that policy to module
> 2) Define the parameter conversion to and from the Policy, we have two options
>         a) We can define a mapping from policy to the our parameters
> in the modules
>         b) We can use policy segments inside the service.xml file, for
> an example for security module
> 
> 
> Possible Implementation
> =======================
>         1) Every module register a name space of the policy it can handle
>         2) If we start from Axis2 configuration Modules at engagement receive
> the policy directly or via the service. The Policy could be Axis2
> parameters or Policy xml segment.  Following is example of policy
> segment in engagement.
> 
>         <service name="SecureService">
>                 <engage name="">
>                         <wsp:Policy>
>                                 ...............
>                                  <sp:SignedSupportingTokens>
>                                     <wsp:Policy>
>                                         <sp:UsernameToken
> sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/Once"
> />
>                                     </wsp:Policy>
>                                  </sp:SignedSupportingTokens>
>         ..........
>                          </wsp:Policy>
>                 </enagege>
>        </service>
>     3) When  a WSDL is found with policy included, a module is called
> based on the #1 mapping, and module is able to process the policy and
> configure and engage himself
> 
> 
> --
> ============================
> Srinath Perera:
>    http://www.cs.indiana.edu/~hperera/
>    http://www.bloglines.com/blog/hemapani
> 


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFD83AV/Hd0ETKdgNIRAraeAKCK/QViWW6OHewDn1ArOywLZv9AMACfWFHG
F0NGxWnHdbQcslwIyQXEVzA=
=DTcg
-----END PGP SIGNATURE-----

Mime
View raw message