+1 from me. On 11/23/05, Eran Chinthaka <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> > Reply-To: [email protected] > To: [email protected] > > 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/
