axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brian Hulse" <hulse.br...@googlemail.com>
Subject Re: [Axis2] Adding two new methods to the Module interface
Date Mon, 26 Jun 2006 11:11:33 GMT
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.

Thoughts?

Brian.



On 6/21/06, Deepal Jayasinghe <deepal@opensource.lk> wrote:
>
> Hi all;
>
> Well , I dont think its a good idea to add new methods into module
> interface class after we have done 1.0 , any way I think changing Module
> interface wont affect that much. Since implementing Module interface is
> optional for a module so please go ahead and change , I know this is
> valid use case and this is the only way to do that.
>
>
> Sanka Samaranayake wrote:
>
> >
> > Hi,
> >
> > I would like to suggest that we add the following two methods to the
> > Module interface.
> >
> > (1) public boolean validate(Policy policy) -- this methods will
> > validate a specified policy and it will remove any policy alternatives
> > which module can't support. This method is useful in the case we need
> > to choose a valid policy alternative for the entire system. Here the
> > objective is to remove any policy alternative that the module
> > *understand* and *can't support*.
> >
> > (2) public void applyPolicy(Policy policy, AxisDescription
> > axisDescription) throws AxisFault -- the module should treat the
> > specified policy as the policy for the specified AxisDescrition which
> > can be a AxisConfiguration or a AxisService or a .. etc. The module
> > should derive its configuration based on the specified policy and used
> > them when it deals with the
> > %specified AxisDescription.
> >
> > Thoughts?
> >
> > Sanka
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
>
>
> --
> Thanks,
> Deepal
> ................................................................
> ~Future is Open~
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>

Mime
View raw message