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 <[EMAIL PROTECTED]> 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. > >> http://svn.apache.org/repos/asf/webservices/axis2/scratch/c/neethi/ > >> > >> 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. http://wiki.apache.org/ws/FrontPage/Axis2C/Neethi#preview > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
