Re: Neethi/C implementation

[Manjula Peiris <ma...@wso2.com>]

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: axis-c-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: axis-c-dev-help@ws.apache.org
> > >
> > >
> > 
> > 
> > -- 
> > Samisa Abeysinghe : http://www.wso2.org/ (WSO2 Oxygen Tank - Web Services Developers' Portal)
> > 
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-c-dev-help@ws.apache.org
> > 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>