Return-Path: Delivered-To: apmail-ws-axis-dev-archive@www.apache.org Received: (qmail 74816 invoked from network); 27 Jun 2006 06:05:55 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 27 Jun 2006 06:05:55 -0000 Received: (qmail 21908 invoked by uid 500); 27 Jun 2006 06:05:54 -0000 Delivered-To: apmail-ws-axis-dev-archive@ws.apache.org Received: (qmail 21245 invoked by uid 500); 27 Jun 2006 06:05:52 -0000 Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm Precedence: bulk Reply-To: axis-dev@ws.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list axis-dev@ws.apache.org Received: (qmail 21234 invoked by uid 99); 27 Jun 2006 06:05:52 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 26 Jun 2006 23:05:52 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (asf.osuosl.org: local policy) Received: from [209.68.5.15] (HELO relay01.pair.com) (209.68.5.15) by apache.org (qpsmtpd/0.29) with SMTP; Mon, 26 Jun 2006 23:05:51 -0700 Received: (qmail 55857 invoked from network); 27 Jun 2006 06:05:27 -0000 Received: from unknown (HELO ?10.254.130.20?) (unknown) by unknown with SMTP; 27 Jun 2006 06:05:27 -0000 X-pair-Authenticated: 213.94.222.225 Subject: Re: [Axis2] Adding two new methods to the Module interface From: Sanjiva Weerawarana To: axis-dev@ws.apache.org In-Reply-To: <117dffba0606260411r65f8aa4x4cbfc278dc820f1e@mail.gmail.com> References: <4497D3B2.3060206@apache.org> <4498CB2F.8030009@opensource.lk> <117dffba0606260411r65f8aa4x4cbfc278dc820f1e@mail.gmail.com> Content-Type: text/plain Organization: Lanka Software Foundation Date: Tue, 27 Jun 2006 11:35:07 +0530 Message-Id: <1151388308.8000.16.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N On Mon, 2006-06-26 at 12:11 +0100, Brian Hulse wrote: > I'm all in favour of this "validation" phase, although I'm not that > convinced about the implementation. Firstly, there's the naming ... > what you propose is a method called "validate", but then intend to > remove unsupported Alternatives. If we must have this model (I propose > a different one below), it should be called something like > calculateSupportedPolicy(), or some such. +1. > However, there's still a problem with this model, which exists in the > way that Neethi is used in Axis2 too. What we are assuming with your > proposed model is that each domain (module) is in charge of all the > facts to make a decision ... they are not. Certainly, in the examples > of Policies I have seen in the examples used so far, the problem is > not revealed, but it exists nonetheless. Consider a Policy with mixed > domain choice: > > > > > > > > Suppose domain A decides it can't do A1, but can do A2, so goes for > the second option. However, domain B can only do B3 so it goes for the > third choice ... so we have A2 and B3 ... not an option ... we've > broken the Policy. The point is, the selection of a Policy Alternative > must be made at a higher level, and that choice communicated to the > modules (domains). With this in mind, it would be a much better model > if the modules declared which Assertions were supported and let Neethi > make the decision based on the information ... feeding the correct > Alternative to all interested parties. I disagree. If domain A decides it can't do A1 not A2 or A3, then the first option is the only viable path from A's perspective .. so its going to throw out the other two alternatives. When the new policy comes to B, it'll only see B2 and say "nope, can't do" and the right decision is made: there's no policy that both domains A & B can live with. In general, just declaring the assertion QNames that a module can handle isn't enough to decide that a module can handle the actual value of the assertion. We do have a way for the modules to define what policy assertions it handles, but you still must ask the modules whether it can handle the specific assertion because the value (e.g., the specific signature algorithm) may not be acceptable. So you have to go down to each module and ask it whether there's an acceptable alternative in the policy alternatives that are listed in the policy that Neethi has computed. Sanjiva. --------------------------------------------------------------------- To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org For additional commands, e-mail: axis-dev-help@ws.apache.org