You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Greg Dritschler <gr...@gmail.com> on 2008/01/24 16:51:30 UTC
Transaction intents
I have been looking at the SCA Transaction spec and I have noticed some
difficulties reconciling the transaction intent descriptions with the
capabilities of the policy framework.
1) The SCA Transaction spec has several sets of mutually-exclusive
intents: managedTransaction and noManagedTransaction, propagatesTransaction
and suspendsTransaction, transactedOneWay and immediateOneWay. In the
policy framework all intents are additive and there is no concept of
exclusive intents. I know this problem was discussed in the OSOA Policy
working group but it was left unresolved in the published specs. I think
there needs to be some extension to the policy framework implementation to
handle exclusive intents.
2) The transactedOneWay and immediateOneWay intents are unique in that
they apply to services and references but are classified as implementation
intents (rather than interaction intents). What this means is that the
intents specified at each end of the wire having no bearing on each other.
A reference might use transactedOneWay while the service uses
immediateOneWay or vice versa. This conflicts with the following statement
in section 1.4.10 of the SCA Policy Framework:
"If the element is a binding instance and its parent element
(service, reference or callback) is wired, the required intents of the other
side of the wire may be added to the intent set when they are available.
This may simplify, or eliminate, the policy matching step later described in
step C."
I think this statement needs to be clarified to say that only interaction
intents are to be copied. It also means there needs to be some extension to
the intent definition that indicates whether an intent is an interaction
intent or not.
I also found a minor problem in the Tuscany implementation of the policy
framework. In the process of trying to find a policy set that matches the
required intents, the code removes intents from the intent attach point that
it finds in a bindingType or implementationType mayProvide list. I'm not
sure how the binding or implementation can provide the intent if it has been
removed. I think the code needs to be changed to preserve these intents in
the intent attach point and just skip over them when looking for matching
policy sets.
Greg Dritschler
Re: Transaction intents
Posted by scabooz <sc...@gmail.com>.
Hi Greg and Venkat,
Answers to spec questions inline..
Dave
----- Original Message -----
From: "Venkata Krishnan" <fo...@gmail.com>
To: <tu...@ws.apache.org>
Sent: Thursday, January 24, 2008 11:05 AM
Subject: Re: Transaction intents
> Hi Greg,
>
> With respect to your last point on 'code removing intents', this has now
> been modified to leave the computed intents in the binding and
> implemenation
> instances. So now, bindings and implementations should be able to run
> thro
> the intents and act on things that they 'mayProvide'. I had already
> posted
> about this change yesterday in response to another mail you had posted on
> this subject.
>
> With respect to the other points, I'm keen to hear the perspectives of
> some
> SPECS folks to understand further.
>
> Thanks.
>
> - Venkat
>
> On Jan 24, 2008 9:21 PM, Greg Dritschler <gr...@gmail.com>
> wrote:
>
>> I have been looking at the SCA Transaction spec and I have noticed some
>> difficulties reconciling the transaction intent descriptions with the
>> capabilities of the policy framework.
>>
>> 1) The SCA Transaction spec has several sets of mutually-exclusive
>> intents: managedTransaction and noManagedTransaction,
>> propagatesTransaction
>> and suspendsTransaction, transactedOneWay and immediateOneWay. In the
>> policy framework all intents are additive and there is no concept of
>> exclusive intents. I know this problem was discussed in the OSOA Policy
>> working group but it was left unresolved in the published specs. I think
>> there needs to be some extension to the policy framework implementation
>> to
>> handle exclusive intents.
Yes, the spec draft was intentionally published with a disconnect in the
intent
FW. We are now resolving the MUX functionality in the FW itself.
>>
>> 2) The transactedOneWay and immediateOneWay intents are unique in that
>> they apply to services and references but are classified as
>> implementation
>> intents (rather than interaction intents). What this means is that the
>> intents specified at each end of the wire having no bearing on each
>> other.
>> A reference might use transactedOneWay while the service uses
>> immediateOneWay or vice versa. This conflicts with the following
>> statement
>> in section 1.4.10 of the SCA Policy Framework:
>>
>> "If the element is a binding instance and its parent element
>> (service, reference or callback) is wired, the required intents of the
>> other
>> side of the wire may be added to the intent set when they are available.
>> This may simplify, or eliminate, the policy matching step later described
>> in
>> step C."
>>
>> I think this statement needs to be clarified to say that only interaction
>> intents are to be copied. It also means there needs to be some extension
>> to
>> the intent definition that indicates whether an intent is an interaction
>> intent or not.
Correct on all points.
>>
>> I also found a minor problem in the Tuscany implementation of the policy
>> framework. In the process of trying to find a policy set that matches
>> the
>> required intents, the code removes intents from the intent attach point
>> that
>> it finds in a bindingType or implementationType mayProvide list. I'm not
>> sure how the binding or implementation can provide the intent if it has
>> been
>> removed. I think the code needs to be changed to preserve these intents
>> in
>> the intent attach point and just skip over them when looking for matching
>> policy sets.
Right. From a spec perspective, the point is that the mayProvides intents
don't need to be included in the policySet search.
>>
>> Greg Dritschler
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Transaction intents
Posted by Venkata Krishnan <fo...@gmail.com>.
Hi Greg,
With respect to your last point on 'code removing intents', this has now
been modified to leave the computed intents in the binding and implemenation
instances. So now, bindings and implementations should be able to run thro
the intents and act on things that they 'mayProvide'. I had already posted
about this change yesterday in response to another mail you had posted on
this subject.
With respect to the other points, I'm keen to hear the perspectives of some
SPECS folks to understand further.
Thanks.
- Venkat
On Jan 24, 2008 9:21 PM, Greg Dritschler <gr...@gmail.com> wrote:
> I have been looking at the SCA Transaction spec and I have noticed some
> difficulties reconciling the transaction intent descriptions with the
> capabilities of the policy framework.
>
> 1) The SCA Transaction spec has several sets of mutually-exclusive
> intents: managedTransaction and noManagedTransaction,
> propagatesTransaction
> and suspendsTransaction, transactedOneWay and immediateOneWay. In the
> policy framework all intents are additive and there is no concept of
> exclusive intents. I know this problem was discussed in the OSOA Policy
> working group but it was left unresolved in the published specs. I think
> there needs to be some extension to the policy framework implementation to
> handle exclusive intents.
>
> 2) The transactedOneWay and immediateOneWay intents are unique in that
> they apply to services and references but are classified as implementation
> intents (rather than interaction intents). What this means is that the
> intents specified at each end of the wire having no bearing on each other.
> A reference might use transactedOneWay while the service uses
> immediateOneWay or vice versa. This conflicts with the following
> statement
> in section 1.4.10 of the SCA Policy Framework:
>
> "If the element is a binding instance and its parent element
> (service, reference or callback) is wired, the required intents of the
> other
> side of the wire may be added to the intent set when they are available.
> This may simplify, or eliminate, the policy matching step later described
> in
> step C."
>
> I think this statement needs to be clarified to say that only interaction
> intents are to be copied. It also means there needs to be some extension
> to
> the intent definition that indicates whether an intent is an interaction
> intent or not.
>
> I also found a minor problem in the Tuscany implementation of the policy
> framework. In the process of trying to find a policy set that matches the
> required intents, the code removes intents from the intent attach point
> that
> it finds in a bindingType or implementationType mayProvide list. I'm not
> sure how the binding or implementation can provide the intent if it has
> been
> removed. I think the code needs to be changed to preserve these intents
> in
> the intent attach point and just skip over them when looking for matching
> policy sets.
>
> Greg Dritschler
>
Re: Transaction intents
Posted by Venkata Krishnan <fo...@gmail.com>.
Hi,
For the issue related to intents of services being copied over to the
references, I had assumed that bindings and implementation extensions would
never have to look at intents and they'd simply go about rolling out the
policysets. To resolve to the applicable policysets I had done this
addition and left it at that because of this assumption. Now that it seems
like the bindings and implemenation extensions will need the intents, I
shall go an fix the code to fill back the specified intents for a reference
after the policysets have been computed.
Thanks
- Venkat
On Jan 24, 2008 9:21 PM, Greg Dritschler <gr...@gmail.com> wrote:
> I have been looking at the SCA Transaction spec and I have noticed some
> difficulties reconciling the transaction intent descriptions with the
> capabilities of the policy framework.
>
> 1) The SCA Transaction spec has several sets of mutually-exclusive
> intents: managedTransaction and noManagedTransaction,
> propagatesTransaction
> and suspendsTransaction, transactedOneWay and immediateOneWay. In the
> policy framework all intents are additive and there is no concept of
> exclusive intents. I know this problem was discussed in the OSOA Policy
> working group but it was left unresolved in the published specs. I think
> there needs to be some extension to the policy framework implementation to
> handle exclusive intents.
>
> 2) The transactedOneWay and immediateOneWay intents are unique in that
> they apply to services and references but are classified as implementation
> intents (rather than interaction intents). What this means is that the
> intents specified at each end of the wire having no bearing on each other.
> A reference might use transactedOneWay while the service uses
> immediateOneWay or vice versa. This conflicts with the following
> statement
> in section 1.4.10 of the SCA Policy Framework:
>
> "If the element is a binding instance and its parent element
> (service, reference or callback) is wired, the required intents of the
> other
> side of the wire may be added to the intent set when they are available.
> This may simplify, or eliminate, the policy matching step later described
> in
> step C."
>
> I think this statement needs to be clarified to say that only interaction
> intents are to be copied. It also means there needs to be some extension
> to
> the intent definition that indicates whether an intent is an interaction
> intent or not.
>
> I also found a minor problem in the Tuscany implementation of the policy
> framework. In the process of trying to find a policy set that matches the
> required intents, the code removes intents from the intent attach point
> that
> it finds in a bindingType or implementationType mayProvide list. I'm not
> sure how the binding or implementation can provide the intent if it has
> been
> removed. I think the code needs to be changed to preserve these intents
> in
> the intent attach point and just skip over them when looking for matching
> policy sets.
>
> Greg Dritschler
>