Hi Greg and Venkat,
Answers to spec questions inline..
Dave
----- Original Message -----
From: "Venkata Krishnan" <[EMAIL PROTECTED]>
To: <tuscany-dev@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 <[EMAIL PROTECTED]>
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
