tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Laws <simonsl...@googlemail.com>
Subject Re: Intent resolution and POL_4001
Date Tue, 13 Jul 2010 11:58:14 GMT
Hi Brent

First pass comments in-line. I'll have a run through the actual tests
in question and make some more sensible comments shortly.


On Fri, Jul 9, 2010 at 2:41 PM, Brent Daniel <brenthdaniel@gmail.com> wrote:
> Hi,
>  I've been taking a look at POL_4001 and have a few questions. The
> intention of the test is to verify that directly attached policy sets
> are ignored when externally attached policy sets are present. As far
> as I can tell, the Tuscany runtime doesn't attempt to handle this at
> the moment.

Very probably. Is it the case that all directly attached policy sets
are ignored if there are any externally attache policy sets.

> It seems that the easiest way to handle this would be to
> remove any directly attached policy sets from a PolicySubject during
> the build phase if there is also an externally attached PolicySet.
> This seems to achieve the goal, but there are a host of connected
> issues.
> For this particular test, removing the directly attached policy set
> results in an intent that is not satisfied by any policy set. It
> expects an exception to be thrown in this case, but we are only
> producing a warning ( this happens at the end of
> ComponentPolicyBuilderImpl.checkIntentsResolved() .)

We could upgrade this to an error

>We only check the
> reference side during wire matching, so an unsatisfied intent on a
> service is never flagged as an error.

We can't tell until wire matching whether reference intents are
resolved or not as we may not know until resolution time what binding
the reference has. Hence we don't know what policy sets might apply.

> Changing this code to raise an error fixes the problem for this test,
> but results in problems in other tests that use spec-defined intents
> like propagatesTransaction and SOAP.  The comments in the code mention
> that we need to walk through the extension models here, but I'm not
> sure exactly what needs to happen here. Do we really need to look at
> all extensions, or are we only concerned with the specific binding or
> implementation type associated with the subject?

Not sure. What were the other problems that you saw?
> One other related issue is that the tests that specify the
> spec-defined intents seem to be assuming external attachment. For
> example, POL_9015 has:
>  <service name="Service1" requires="propagatesTransaction">

Right because the spec doesn't actually define policy sets for these
intents so the otests can't assume that they exist.

> However, the policy sets we define in policy-transaction only support
> direct attachment since there is no attachTo attribute. Adding
> something like:  attachTo="IntentRefs('sca:propagatesTransaction')"
> resolves the above issue with the propagatesTransaction intent not
> being resolved, as the policy set would be applied and the intent
> would be resolved when we check it at build time. The spec doesn't
> seem to say anything about whether policy sets that satisfy
> spec-required intents should be capable of being externally attached
> or not. Should we be providing both?

I don't think that the otests should depend on the Tuscany provided
transaction policy sets.

 That seems like it would be the
> only way to allow spec-defined intents to be used in conjunction with
> other intents. For example, with 'requires="propagatesTransaction
> myIntent"', if we require the ManagedTransactonPolicySet to be
> directly attached, the policy set that satisfies myIntent would also
> have to be directly attached, or propagatesTransaction would be
> ignored. If we required it to be externally attached, the policy set
> for myIntent would also need to be externally attached or it would be
> ignored.
> To summarize, what I'd like to know is:
> 1) Should we be raising an error at build time when intents aren't
> satisfied by some policy set?


> 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.

> 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.

> 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.

> Brent

Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com

View raw message