axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Manjula Peiris <>
Subject Re: Neethi/C implementation
Date Fri, 18 May 2007 05:28:01 GMT
please see my comments inline.

On Fri, 2007-05-18 at 10:08 +0530, 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?
No we don't need to have different domain specific policy files for
different modules. Normaly what we are doing is attaching a policy
element in the services.xml and that policy element contains all types
of policy assertions (eg: Security, Rm, ect). The Axis2/C engine parses
the services.xmls and attaches these policy objects in their services.
The policies can be specified in operation level as well as message
level. So inside modules (eg:- Rampart) the relevent policies can be
extracted by going through this policy object.
By the way we should be able specify policies in axis2.xml. Because if a
particular user wants all his services to have the same policy this
would be useful.

> 2. Is it costly to build policy models for all the modules at the startup?
This will depend on what are the policies applied for services. 
> 3. How the description hierarchy supports policy models?
Description hierarchy can keep policies in all levels. (service,
operation and message)

> 4. Can other platforms(e.g. PHP) adhere to a similar behavior as Axis2/C?
> Answers to this kind of questions would be trivial to make the decision 
> that you need to take. :)
> There is one more thing. Even though Rampart/C configuration module is 
> dependent on WS-Security Policy, there are certain assertions that 
> Rampart/C has defined. For example to specify the Certificate/Key files. 
> Assertions like this has nothing to do with Axis2/C or other modules. So 
> do we have to make this kind of assertions be part of WS-Policy?
These assertions are also inside the policy element. There is no problem
keeping these types of assertions as a part of WS-policy.

> I'm sorry if I made this more complicated than it was. But as Samisa 
> said I'd say that let's give it a run. Give time to other modules like 
> Sandesha/C to adapt their configuration modules with Nethi/C. And later 
> see which parts of the code resides where. :)
> Cheers,
> Kaushalye
> Dinesh Premalal wrote:
> > Hi Manjula,
> >           Please find my comments inline.
> > Manjula Peiris <> writes:
> >
> >   
> >> Hi devs,
> >>
> >> Most of the implementaion for Neethi/C (WS -Policy framework for
> >> Axis2/c) has being completed. The implementation is at the folllowing
> >> url.
> >>
> >>
> >> But before merging with the trunk We have to consider some issues.
> >>
> >> 1. whether we are going to keep domain specific policy implementations
> >> inside Neethi or in those domain implementations(Eg :-Security
> >> policy)
> >>
> >> -I think those policy implementations should be in their domain
> >> implementations.
> >>     
> >  Do you see any advantage on keeping those policy implementations in
> >  domain implementations over keeping them inside Neethi/C? I think we
> >  need to weigh pros and cons of both approaches before make a
> >  decision. Here are some[1] as I see. Please feel free to make
> >  corrections if I caught them wrong.
> >
> > thanks,
> > Dinesh
> >
> > 1.
> >
> >
> >   
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message