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 <[EMAIL PROTECTED]> > >Date: Feb 13, 2006 5:29 PM > >Subject: State of WS-Policy? > >To: "[email protected]" <[email protected]> > > > >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 > > >
signature.asc
Description: OpenPGP digital signature
