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: [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]
