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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
