tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brent Daniel <brenthdan...@gmail.com>
Subject Re: Intent resolution and POL_4001
Date Tue, 13 Jul 2010 16:38:42 GMT
On Tue, Jul 13, 2010 at 4:58 AM, Simon Laws <simonslaws@googlemail.com> wrote:

>> 1) Should we be raising an error at build time when intents aren't
>> satisfied by some policy set?
> Yes

OK. I've been working with these changes locally and will commit them soon.

>> 2) If yes, how do we make sure extensions are considered?
> Not sure what this means. Do you mean when an extension provides an
> intent by default. If so this should be taken account of when the
> unsatisfied intents are calculated. There is some code for this but I
> can't say if it's actually working properly.

Yes.. basically we need to check if the intent is in the
alwaysProvides or mayProvide attribute for the implementation type or
binding type. My confusion here is that there's a comment in the code
that says we need to walk through all extensions, but it seems like
all we would need to check is the extensionType on the PolicySubject.

At the moment this is only affecting POL_3019 which uses the SOAP intent.

>> 3) If no, should we be checking for this later (when we wire the endpoints?)
> We need to check here also as the service binding might "provide" a
> reference intent.

We're handling the reference side checking there already, so we should be ok.

>> 4) Should we be providing additional policy sets for intents required
>> by the spec that allow for external attachment?
> No. Not for the purposed of passing the otests at least. We will of
> course want to provide policy sets for the spec defined intents for
> normal operation.

We don't necessarily need to do this for the otests, as currently all
test cases that use spec defined intents either expect an exception
(9015,9016,9017,9018) or define a policy set that satisfies it
(9022,9023.) If we don't implement an externalAttachment version of
propagatesTransaction, then we will be checking for a failure to
resolve the intent rather than testing the intended function. That's
probably OK from an otest perspective, but not ideal.

I was thinking more generally, though, that this is something we
should be providing. It doesn't seem right to mandate that users have
to use one flavor of attachment when our runtime supports both.


View raw message