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