axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brian Hulse" <>
Subject Re: [Axis2] Adding two new methods to the Module interface
Date Tue, 27 Jun 2006 08:00:55 GMT
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?


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:
> >
> > <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.
> Sanjiva.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

View raw message