You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Brent Daniel <br...@gmail.com> on 2010/07/09 15:41:52 UTC
Intent resolution and POL_4001
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. 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 only check the
reference side during wire matching, so an unsatisfied intent on a
service is never flagged as an error.
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?
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">
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? 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?
3) If no, should we be checking for this later (when we wire the endpoints?)
4) Should we be providing additional policy sets for intents required
by the spec that allow for external attachment?
Brent
Re: Intent resolution and POL_4001
Posted by Simon Laws <si...@googlemail.com>.
On Tue, Jul 13, 2010 at 7:46 PM, Brent Daniel <br...@gmail.com> wrote:
> On Tue, Jul 13, 2010 at 10:00 AM, Simon Laws <si...@googlemail.com> wrote:
>> On Tue, Jul 13, 2010 at 5:38 PM, Brent Daniel <br...@gmail.com> wrote:
>>> On Tue, Jul 13, 2010 at 4:58 AM, Simon Laws <si...@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.
>>
>> Can you point me at where the comment is in the code?
>>
>
> It's in ComponentPolicyBuilderImpl around line 522:
>
> if (!intentMatched){
> // Raise a warning as we have an intent that doesn't
> have a matching
> // policy set at this start.
> // TODO - this could be because the intent is provided
> by and extension
> // and hence there is no explicit policy set.
> Need and extra piece
> // of processing to walk through the extension models.
>
> // warning(context.getMonitor(),
> "IntentNotSatisfiedAtBuild", subject, intent.getName(),
> subject.toString());
> error(context.getMonitor(),
> "IntentNotSatisfiedAtBuild", subject, intent.getName(),
> subject.toString());
> }
>
>>>
>>> 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.
>>
>> Y, I agree. I think the spec allows you to provided one or the other
>> but we happen to provide both. We should show examples of both in our
>> samples and tests. When it comes to actual applications it's going to
>> be up to the users themselves which approach they choose to take in
>> each situation.
>>
>>>
>>> Brent
>>>
>>
>> Simon
>>
>> --
>> Apache Tuscany committer: tuscany.apache.org
>> Co-author of a book about Tuscany and SCA: tuscanyinaction.com
>>
>
Ok, thanks for the pointer Brent I see it now. As you say it would
seem sufficient to check the extension in question to see if it
"provides" the intent. The question here is which extension are we
talking about. This code in the ComponentPolicyBuilderImpl is
provided with a policy subject which in this case is either an
Endpoint or and EndpointReference. So the extension in question will,
I believe, be the binding that these refer to. There is still an issue
here though. That is that the EndpointReference may not have a matched
binding until runtime so we need to make sure that the build
processing doesn't bail out with unresolved intents in this case.
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: Intent resolution and POL_4001
Posted by Brent Daniel <br...@gmail.com>.
On Tue, Jul 13, 2010 at 10:00 AM, Simon Laws <si...@googlemail.com> wrote:
> On Tue, Jul 13, 2010 at 5:38 PM, Brent Daniel <br...@gmail.com> wrote:
>> On Tue, Jul 13, 2010 at 4:58 AM, Simon Laws <si...@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.
>
> Can you point me at where the comment is in the code?
>
It's in ComponentPolicyBuilderImpl around line 522:
if (!intentMatched){
// Raise a warning as we have an intent that doesn't
have a matching
// policy set at this start.
// TODO - this could be because the intent is provided
by and extension
// and hence there is no explicit policy set.
Need and extra piece
// of processing to walk through the extension models.
// warning(context.getMonitor(),
"IntentNotSatisfiedAtBuild", subject, intent.getName(),
subject.toString());
error(context.getMonitor(),
"IntentNotSatisfiedAtBuild", subject, intent.getName(),
subject.toString());
}
>>
>> 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.
>
> Y, I agree. I think the spec allows you to provided one or the other
> but we happen to provide both. We should show examples of both in our
> samples and tests. When it comes to actual applications it's going to
> be up to the users themselves which approach they choose to take in
> each situation.
>
>>
>> Brent
>>
>
> Simon
>
> --
> Apache Tuscany committer: tuscany.apache.org
> Co-author of a book about Tuscany and SCA: tuscanyinaction.com
>
Re: Intent resolution and POL_4001
Posted by Simon Laws <si...@googlemail.com>.
On Tue, Jul 13, 2010 at 5:38 PM, Brent Daniel <br...@gmail.com> wrote:
> On Tue, Jul 13, 2010 at 4:58 AM, Simon Laws <si...@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.
Can you point me at where the comment is in the code?
>
> 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.
Y, I agree. I think the spec allows you to provided one or the other
but we happen to provide both. We should show examples of both in our
samples and tests. When it comes to actual applications it's going to
be up to the users themselves which approach they choose to take in
each situation.
>
> Brent
>
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: Intent resolution and POL_4001
Posted by Brent Daniel <br...@gmail.com>.
On Tue, Jul 13, 2010 at 4:58 AM, Simon Laws <si...@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.
Brent
Re: Intent resolution and POL_4001
Posted by Simon Laws <si...@googlemail.com>.
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.
Simon
On Fri, Jul 9, 2010 at 2:41 PM, Brent Daniel <br...@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?
Yes
> 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