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