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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Thanks,
Deepal
................................................................
~Future is Open~
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
