You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@axis.apache.org by Manjula Peiris <ma...@wso2.com> on 2007/05/17 17:46:40 UTC
Neethi/C implementation
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.
But currently for testing purposes I have implemented security policy
builders inside neethi. So if we now integrate the scratch with trunk
Rampart will have problems to load configurations. So until we implement
module(eg:- Rampart) independent policy builder picking mechanism we
should not integrate Neethi stuff to Rampart.
Any thoughts??
Thanks
-Manjula.
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
Re: Neethi/C implementation
Posted by Manjula Peiris <ma...@wso2.com>.
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 <ma...@wso2.com> 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: 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
Re: Neethi/C implementation
Posted by 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
Re: Neethi/C implementation
Posted by 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
>
Re: Neethi/C implementation
Posted by Manjula Peiris <ma...@wso2.com>.
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
Re: Neethi/C implementation
Posted by Samisa Abeysinghe <sa...@wso2.com>.
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.
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
Re: Neethi/C implementation
Posted by Kaushalye Kapuruge <ka...@wso2.com>.
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.
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
Re: Neethi/C implementation
Posted by Samisa Abeysinghe <sa...@wso2.com>.
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...
--
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
Re: Neethi/C implementation
Posted by Kaushalye Kapuruge <ka...@wso2.com>.
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?
2. Is it costly to build policy models for all the modules at the startup?
3. How the description hierarchy supports policy models?
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?
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 <ma...@wso2.com> 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: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
Re: Neethi/C implementation
Posted by Dinesh Premalal <xy...@gmail.com>.
Hi Manjula,
Please find my comments inline.
Manjula Peiris <ma...@wso2.com> 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
--
Dinesh Premalal
dinesh@wso2.com
WSO2, Inc.; http://www.wso2.com/
GPG Key ID : A255955C
GPG Key Finger Print : C481 E5D4 C27E DC34 9257 0229 4F44 266E A255 955C
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
Re: Neethi/C implementation
Posted by Samisa Abeysinghe <sa...@wso2.com>.
Manjula Peiris wrote:
> 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.
>
Ideally, adhering to clean design principles, the domain specific stuff
should be implemented by those domain and not the core Neethi engine.
However, IMHO, we can do that as we go along. Given that we have
something working, it would be ideal to merge that working code to the
main svn head, before we get more regression issues in our way. It is
not only the Neethi engine that needs to be merged, but also some core
structs such as the description hierarchy - given that, I would rather
merge it sooner than later. However that is my opinion, it would be
ideal if the module guys (such as Rampart and Sandesha), can voice their
concerns as well.
Samisa...
--
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