axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sanka Samaranayake <>
Subject Re: Fwd:[Axis2] State of WS-Policy?
Date Thu, 16 Feb 2006 09:41:41 GMT
Hash: SHA1

Hi Srinath, All,

Srinath Perera wrote:
> 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?

At this moment it is not supported at ServiceClient level.  It'll be
really cool if the ServiceClient gets auto configured based on the
policy information it gets via a WSDL. If you like to work on that I'll
be happy to help you as/if needed.

BTW, for anyone who is a newcomer to WS Policy, there is an introductory
article I worte on WS Policy. You can find it at:

Please feel free to send any feedback


> Thanks
> Srinath
> On 2/15/06, Eran Chinthaka <> 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 which means any primitive assertion which
>>>has this namespace will be processed by this module.
>>>e.g. <mns:MyAssertion xmlns:mns="">
>>>    ...
>>>     </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/>
>>>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.
>>>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
>>>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 !!
>>>Srinath Perera wrote:
>>>>Oops forget to put the prefix, seems I have been too far away
>>>>---------- Forwarded message ----------
>>>>From: Srinath Perera <>
>>>>Date: Feb 13, 2006 5:29 PM
>>>>Subject: State of WS-Policy?
>>>>To: "" <>
>>>>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
>>>>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.
>>>>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
>>>>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
>>>>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
>>>>                                   </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:
> --
> ============================
> Srinath Perera:

Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird -


View raw message