[Axis2] WS Policy, Axis2 Core and Modules

[Eran Chinthaka <ch...@opensource.lk>]

Forwarding with correct Prefix

-------- Original Message --------
Subject: 	WS Policy, Axis2 Core and Modules
Date: 	Wed, 23 Nov 2005 03:04:38 -0600
From: 	Sanka Samaranayake <ss...@gmail.com>
Reply-To: 	axis-dev@ws.apache.org
To: 	axis-dev@ws.apache.org



Dear Axis2 Developers,

A policy might contain few policy alternatives. A policy alternative is
essentially another policy where all its assertions should be met.
IMO if we are to add support for WS Policy in Axis2 framework there
should be a way to select a proper policy alternative from a policy.
There are atleast two levels of policy processing before a single policy
alternative can be selected.

Module level processing

A policy alternative might contain zero or more assertions where all
those assertions should be satisfied. And those assertions can be
processed only by modules with desired domain knowledge. (eg. The set of
security assertions of a policy alternative can only be processed by the
security module which is aware of WS Security Policies)

Given a policy alternative, a module can arrive at following conclusions

(a) There are no assertions in the policy alternative that the module
has knowledge to process them. (eg. If there are no RM assertions in the
policy alternative, the RM module cant do any processing and arraive at
a conclusion)

(b) There are some assertions in the policy alternative that the module
has knowledge to process them. After some processing it concludes that
it can't support those assertions.

(c) There are some assertions in the policy alternative that the module
has knowledge to process them. Upon the completion of further
processing, it concludes that it can support those assertions.

Therefore I suggest the following method should be added to Module
Interface.


public org.apache.policy.Policy
selectAlternative(org.apache.policy.Policy p)

This method should return a policy with policy alternatives whose
assertions can either be supported or do not concern the module at all.
(After the managerial level of policy processing it is safe to assume
that for any assertion in a policy alternative there is a module that
can process that assertion. Every assertion will be processed by a
module at some point along the path. Therefore a module should only
eliminate policy alternatives which contain atleast one assertion that
it can process but cant be supported)


Managerial level processing

Axis2 framework (core) should maintain knowledge of all modules
available and type of assertions that they can process. For instance it
should know that the security module is available and all security
asseritons should be fed into it.

In this way some policy alternatives that has assertions which non of
its modules can process can be eliminated before passing it to module
for further processing. (i.e. if a policy alternative contains security
assertions and if the security module is not present that alternative
should be eliminated since there is no way we can support those security
assertions).

To make the process of selecting a policy alternative possible, I
suggest following method should also be added to Module Interface.

public String[] getPolicyNamespace()
Returns an array of strings of policy namespaces which the module is
interested. This is required for Managerial level policy processing to
decide, given an assertion whether there is a module that can process
that assertion.

Thoughts ?

Best,
Sanka.

Re: [Axis2] WS Policy, Axis2 Core and Modules

[Davanum Srinivas <da...@gmail.com>]

+1 from me.

On 11/23/05, Eran Chinthaka <ch...@opensource.lk> wrote:
>      Forwarding with correct Prefix
>
>  -------- Original Message --------
>        Subject:        WS Policy, Axis2 Core and Modules
>        Date:        Wed, 23 Nov 2005 03:04:38 -0600
>        From:        Sanka Samaranayake <ss...@gmail.com>
>        Reply-To:        axis-dev@ws.apache.org
>        To:        axis-dev@ws.apache.org
>
>  Dear Axis2 Developers,
>
> A policy might contain few policy alternatives. A policy alternative is
> essentially another policy where all its assertions should be met.
> IMO if we are to add support for WS Policy in Axis2 framework there
> should be a way to select a proper policy alternative from a policy.
> There are atleast two levels of policy processing before a single policy
> alternative can be selected.
>
> Module level processing
>
> A policy alternative might contain zero or more assertions where all
> those assertions should be satisfied. And those assertions can be
> processed only by modules with desired domain knowledge. (eg. The set of
> security assertions of a policy alternative can only be processed by the
> security module which is aware of WS Security Policies)
>
> Given a policy alternative, a module can arrive at following conclusions
>
> (a) There are no assertions in the policy alternative that the module
> has knowledge to process them. (eg. If there are no RM assertions in the
> policy alternative, the RM module cant do any processing and arraive at
> a conclusion)
>
> (b) There are some assertions in the policy alternative that the module
> has knowledge to process them. After some processing it concludes that
> it can't support those assertions.
>
> (c) There are some assertions in the policy alternative that the module
> has knowledge to process them. Upon the completion of further
> processing, it concludes that it can support those assertions.
>
> Therefore I suggest the following method should be added to Module
> Interface.
>
>
> public org.apache.policy.Policy
> selectAlternative(org.apache.policy.Policy p)
>
> This method should return a policy with policy alternatives whose
> assertions can either be supported or do not concern the module at all.
> (After the managerial level of policy processing it is safe to assume
> that for any assertion in a policy alternative there is a module that
> can process that assertion. Every assertion will be processed by a
> module at some point along the path. Therefore a module should only
> eliminate policy alternatives which contain atleast one assertion that
> it can process but cant be supported)
>
>
> Managerial level processing
>
> Axis2 framework (core) should maintain knowledge of all modules
> available and type of assertions that they can process. For instance it
> should know that the security module is available and all security
> asseritons should be fed into it.
>
> In this way some policy alternatives that has assertions which non of
> its modules can process can be eliminated before passing it to module
> for further processing. (i.e. if a policy alternative contains security
> assertions and if the security module is not present that alternative
> should be eliminated since there is no way we can support those security
> assertions).
>
> To make the process of selecting a policy alternative possible, I
> suggest following method should also be added to Module Interface.
>
> public String[] getPolicyNamespace()
> Returns an array of strings of policy namespaces which the module is
> interested. This is required for Managerial level policy processing to
> decide, given an assertion whether there is a module that can process
> that assertion.
>
> Thoughts ?
>
> Best,
> Sanka.
>
>
>



--
Davanum Srinivas : http://wso2.com/blogs/