Return-Path: Delivered-To: apmail-ws-axis-dev-archive@www.apache.org Received: (qmail 9425 invoked from network); 27 Jun 2006 08:01:23 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 27 Jun 2006 08:01:23 -0000 Received: (qmail 70130 invoked by uid 500); 27 Jun 2006 08:01:18 -0000 Delivered-To: apmail-ws-axis-dev-archive@ws.apache.org Received: (qmail 70096 invoked by uid 500); 27 Jun 2006 08:01:17 -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 70084 invoked by uid 99); 27 Jun 2006 08:01:17 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 27 Jun 2006 01:01:17 -0700 X-ASF-Spam-Status: No, hits=0.9 required=10.0 tests=HTML_10_20,HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of hulse.brian@googlemail.com designates 64.233.162.193 as permitted sender) Received: from [64.233.162.193] (HELO nz-out-0102.google.com) (64.233.162.193) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 27 Jun 2006 01:01:16 -0700 Received: by nz-out-0102.google.com with SMTP id s1so1656461nze for ; Tue, 27 Jun 2006 01:00:55 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=googlemail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=hx5G7YnPdnZ5XFvfg5Adi7VjpXKfiKDRQ0RIsNraO8Uc9nmd77qnYVzOWf6BomLbmZ0mMVOFSgtu7/UAUl2hV8ahKUwlcpZPdsxocnXoHPzzRb0DfKgzYBvOqQICYEcvs9HEMOLZZVEo+usQlkoQ+ylBmVAtprnANsv0OADnCmE= Received: by 10.65.224.13 with SMTP id b13mr7155566qbr; Tue, 27 Jun 2006 01:00:55 -0700 (PDT) Received: by 10.65.160.8 with HTTP; Tue, 27 Jun 2006 01:00:55 -0700 (PDT) Message-ID: <117dffba0606270100p2a6913b5ge4df3ac04396ec9a@mail.gmail.com> Date: Tue, 27 Jun 2006 09:00:55 +0100 From: "Brian Hulse" To: axis-dev@ws.apache.org Subject: Re: [Axis2] Adding two new methods to the Module interface In-Reply-To: <1151388308.8000.16.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_35114_14871273.1151395255794" References: <4497D3B2.3060206@apache.org> <4498CB2F.8030009@opensource.lk> <117dffba0606260411r65f8aa4x4cbfc278dc820f1e@mail.gmail.com> <1151388308.8000.16.camel@localhost.localdomain> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N ------=_Part_35114_14871273.1151395255794 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I understand what you're saying, but there's a processing overhead here. In your model, each module will winnow out the alternatives it cannot support and pass on the result to the next. The problem with this is that each will have to do an exhaustive search throughout the whole policy tree, including, as you say, a complete match on what could be very complex WS-SecurityPolicy assertions. This isn't necessary, we only want a single supported alternative, we don't need to process everything to get this. In addition, I was being circumspect when I stated registration of QNames ... this is a first stage pass of the winnow process, which is high level and easy to do. After that, a higher level processing unit (higher than the modules) would need to examine each alternative and ask each module about its support statement on the assertions in its domain. This two stage approach is what our code does and in doing so, stops when a suitable alternative is found, rather than the exhaustive approach you suggest. I understand that in small policies, with no or simple choice, there is very little difference, but in the larger, more complex cases, this will matter. It should also be stated that there is still the possibility with your model of a bad choice. If the model you choose is that domain A just removes all alternatives it cannot support, and it leaves 2 alternatives ... which does it use? It could select one that some other domain could not support ... when in fact there is an alternative which could pass everyone's tests. In this respect, you have to have some central point of control, a Policy Decision Point, and it can't be farmed out to the domains. Am I just confusing the issue? Brian. On 6/27/06, Sanjiva Weerawarana wrote: > > 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 > > ------=_Part_35114_14871273.1151395255794 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
I understand what you're saying, but there's a processing overhead her= e. In your model, each module will winnow out the alternatives it cannot su= pport and pass on the result to the next. The problem with this is that eac= h will have to do an exhaustive search throughout the whole policy tree, in= cluding, as you say, a complete match on what could be very complex WS-Secu= rityPolicy assertions. This isn't necessary, we only want a single supporte= d alternative, we don't need to process everything to get this. In addition= , I was being circumspect when I stated registration of QNames ... this is = a first stage pass of the winnow process, which is high level and easy to d= o. After that, a higher level processing unit (higher than the modules) wou= ld need to examine each alternative and ask each module about its support s= tatement on the assertions in its domain. This two stage approach is what o= ur code does and in doing so, stops when a suitable alternative is found, r= ather than the exhaustive approach you suggest. I understand that in small = policies, with no or simple choice, there is very little difference, but in= the larger, more complex cases, this will matter.
 
It should also be stated that there is still the possibility with your= model of a bad choice. If the model you choose is that domain A just remov= es all alternatives it cannot support, and it leaves 2 alternatives ... whi= ch does it use? It could select one that some other domain could not suppor= t ... when in fact there is an alternative which could pass everyone's test= s. In this respect, you have to have some central point of control, a Polic= y Decision Point, and it can't be farmed out to the domains. Am I just conf= using the issue?
 
Brian.

 
On 6/27/06, = Sanjiva Weerawarana <sanjiv= a@opensource.lk> wrote:
On Mon, 2006-06-26 at 12:11 +010= 0, Brian Hulse wrote:
> I'm all in favour of this "validation&qu= ot; phase, although I'm not that
> convinced about the implementation. Firstly, there's the naming ..= .
> what you propose is a method called "validate", but the= n intend to
> remove unsupported Alternatives. If we must have this m= odel (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 th= at Neethi is used in Axis2 too. What we are assuming with your
> proposed model is that each domain (module) is in charge of all th= e
> facts to make a decision ... they are not. Certainly, in the exam= ples
> of Policies I have seen in the examples used so far, the probl= em is
> not revealed, but it exists nonetheless. Consider a Policy with mi= xed
> domain choice:
>
> <ExactlyOne>
> <A= ll><A1 /> <B1 /> </All>
> <All><A2 />= ; <B2 /> </All>
> <All><A3 /> <B3 /> </All>
> </Exa= ctlyOne>
>
> Suppose domain A decides it can't do A1, but ca= n 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<= br>> broken the Policy. The point is, the selection of a Policy Alternat= ive
> 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 mo= del
> 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.

I= f 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
on= ly 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 handleisn't enough to decide that a module can handle the actual value of theassertion. We do have a way for the modules to define what policy
asser= tions 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 t= o each module and ask it whether there's an
acceptable alternative in th= e policy alternatives that are listed in the
policy that Neethi has computed.

Sanjiva.




---= ------------------------------------------------------------------
To un= subscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: = axis-dev-help@ws.apache.org<= /a>


------=_Part_35114_14871273.1151395255794--