axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sanjiva Weerawarana <>
Subject Re: [Axis2] Adding two new methods to the Module interface
Date Tue, 27 Jun 2006 06:05:07 GMT
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. 


> 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:
> <ExactlyOne>
> <All><A1 /> <B1 /> </All>
> <All><A2 /> <B2 /> </All>
> <All><A3 /> <B3 /> </All>
> </ExactlyOne>
> 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.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message