axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eran Chinthaka <chinth...@opensource.lk>
Subject Re: Fwd:[Axis2] State of WS-Policy?
Date Wed, 15 Feb 2006 18:43:33 GMT
Good explanation. Can we have this on wiki ?

Sanka Samaranayake wrote:

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

Mime
View raw message