-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eran Chinthaka wrote: > Good explanation. Can we have this on wiki ?
yes .. I'll do Sanka > > 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 >> >> >> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD9Emt/Hd0ETKdgNIRAt8pAKCHUEYuEBFVQm3oKpcyoBEsZegmLwCeNIPY ZG7faGkTIQGtew3WZyzwmkc= =kdgQ -----END PGP SIGNATURE-----
