Hi, Neethi/C is merged to the trunk. https://svn.apache.org/repos/asf/webservices/axis2/trunk/c/neethi
Rampart/C is also changed so that it will depend on neethi. https://svn.apache.org/repos/asf/webservices/rampart/trunk/c Rampart samples also chnaged. https://svn.apache.org/repos/asf/webservices/rampart/trunk/c/samples/secpolicy Have a try! Thanks -Manjula On Fri, 2007-05-18 at 13:34 +0530, Manjula Peiris wrote: > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
