HI Sanka; Thanks verymuch for detailed explanation!
I will have a look at the code, and get back. I am really worrid about the ServiceClient level. For an example when I provide a WSDL with policy to the Service Client, It should be configure itself. >From your explanation I think it is easy thing to do. Is there a work done on that aspect? Thanks Srinath On 2/15/06, Eran Chinthaka <[EMAIL PROTECTED]> wrote: > 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 > > > > > > > > > -- ============================ Srinath Perera: http://www.cs.indiana.edu/~hperera/ http://www.bloglines.com/blog/hemapani
