axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kaushalye Kapuruge <>
Subject Re: Neethi/C implementation
Date Fri, 18 May 2007 05:54:32 GMT
Hi Samisa,
Thanks for the input.
Seeing that, this kind of a behavior model came to my mind.
1. Neethi/C builds a generic policy struct by inspecting the policy 
assertions defined in a descriptor files. In future we can extend this 
to pick policies from the WSDL file.
2. Axis2/C configuration module get information from that generic policy 
struct and define it's behavior.
3. Each and every module MUST have it's own configuration module and 
they also have the access to the generic policy struct, which is the 
source of populating configurations. For example Rampart builds Security 
Policy Struct depending on the Generic Policy struct.
4. No operation of a module(e.g. Rampart, Sandesha) directly read the 
generic policy struct, but define behavior in it's own configuration 
module. This makes "No crossed wires between modules and Neethi/C".
5. Other platforms can also build the Generic policy struct by reading a 
policy file (or in other platform specific way)

Any comments???

Samisa Abeysinghe wrote:
> Kaushalye Kapuruge wrote:
>> Hi Manjula and Others,
>> In future we are going to have Axis2/C and it's modules(e.g. Rampart, 
>> Sandesha) to be dependent on WS-Policy. Right now only Rampart/C has 
>> implemented the security related policies, which can be considered as 
>> a sub set of WS-Policy. So the security related logic is already in 
>> Rampart/C.
>> Even though it's more logical to have domain specific stuff in their 
>> domains, here we have to be more careful in deciding what the Axis2/C 
>> user is comfortable with. Since Neethi/C is more or less can be 
>> considered as the configuration module of Axis2/C, it directly 
>> involve with the end user experience. So the questions that can be 
>> raised are...
>> 1.Are we going to have a single policy file to configure Axis2/C and 
>> it's modules? Or to have different domain specific policy files for 
>> different modules?
> I think the model is that policies would be in either axis2.xml or any 
> services.xml. At the moment, AFAIK, we have supported placing policies 
> only in services.xml file. So irrespective of whether it is a security 
> policy or an RM policy, it would be placed in services.xml file at 
> different levels such as service, operation or message level.
> There is another model that we also have to take into consideration, 
> but which is out of scope right now. That is picking policies form the 
> WSDL file. At some point, we would have to support the model, where 
> both the client and service would be able to pick policies from the 
> WSDL. Now in a WSDL, there would be various kinds of policies, 
> belonging to different domains - it is in sync with this model that at 
> the moment we place policies in the services.xml file.
>> 2. Is it costly to build policy models for all the modules at the 
>> startup?
> I think no.
>> 3. How the description hierarchy supports policy models?
> The description hierarchy treats any policy using a generic struct 
> named neethi_policy_t. Description hierarchy does not need to know any 
> domain specific stuff, it just needs to know that it is a policy and 
> that is all. Domain specific stuff would have to be handled by the 
> respective modules.
>> 4. Can other platforms(e.g. PHP) adhere to a similar behavior as 
>> Axis2/C?
> No idea :(
> Samisa...

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message