Re: Transaction intents
Hi Greg and Venkat, Answers to spec questions inline.. Dave - Original Message - From: "Venkata Krishnan" <[EMAIL PROTECTED]> To: 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]
Re: Transaction intents
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 >
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. > > 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 >
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
