On Fri, 2007-05-18 at 11:42 +0600, Samisa Abeysinghe wrote: > Kaushalye Kapuruge wrote: > > 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. > I am not sure how this is done in current implementation. Manjula needs > to comment on that. Other than that, the rest of the stuff sounds OK to me.
I think this is ok. In Current implementation rampart populate its security policy object by inspecting the generic policy object.Please see the following two files for more explanation. https://svn.apache.org/repos/asf/webservices/axis2/scratch/c/neethi/axis2c/neethi/src/secpolicy/builder/secpolicy_builder.c https://svn.apache.org/repos/asf/webservices/axis2/scratch/c/neethi/rampart/src/util/rampart_neethi.c -Manjula. > > Samisa... > > 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??? > > Cheers, > > Kaushalye > > > > > > 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: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > Samisa Abeysinghe : http://www.wso2.org/ (WSO2 Oxygen Tank - Web Services > Developers' Portal) > > > --------------------------------------------------------------------- > 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]
