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