[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-policy] Revised Proposal for Issue 93
I appreciate the time you took to adjust the proposal. There are other adjustments that would also need to be made, but I'll refrain because I'm still stuck on a larger issue. I can hopefully summarize it as the conflation of intents and policy in a way that undermines the conceptual differences between intents and policy sets. I'm trying to keep an open mind, so in the hopes of furthering the discussion, I'll re-iterate the points I made (or was trying to make) on the telecon. 1) Intents are abstract expressions of a requirement that is embodied within an instance of an SCA component or composition. In their role as requirements, they appropriately constrain the environment in which they execute. 2) PolicySets contain concrete policy expressions. In some cases, a policySet can be used to further refine or clarify an intent. We use the word "provides" to indicate that a policySet is a specific concrete realization of the abstract requirement embodied in an intent. We indicate the same relationship between bindingTypes and intents where we recognize that executable code can also represent a concrete expression of an abstract requirement. The means of attaching intents to SCA composites/components is insignificant. We could devise all sorts of way of associating intents with applications. As such, it is NOT the external attachment aspect of your proposal that causes me concern, it is the implications of the use cases that you use to justify the feature. My objection comes from the following: 1) What does it mean to change the requirements of an application? The dynamicity argument you use essentially boils down to this question. I'll confess to not understanding how the intents/constraints of an application can be changed without changing (or at least re-testing) the application. On the other hand, changing the policySet which fulfills a particular realization of an already known requirement should be possible. 2) What does it mean to specify a constraint if some other part of the development lifecycle can undo the constraint? We designed the intent FW precisely to honor this notion of a constraint which is explicitly not a point of variability in the app. The concrete realization of the constraint is the point of variability. I'll stop there and invite some email discussion. Dave Booz STSM, BPM and SCA Architecture Co-Chair OASIS SCA-Policy TC and SCA-J TC "Distributed objects first, then world hunger" Poughkeepsie, NY (845)-435-6093 or 8-295-6093 e-mail:booz@us.ibm.com |------------> | From: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |ashok malhotra <ashok.malhotra@ORACLE.COM> | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | To: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |oasis Policy <sca-policy@lists.oasis-open.org> | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Date: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |01/20/2010 08:56 AM | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Subject: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |[sca-policy] Revised Proposal for Issue 93 | >--------------------------------------------------------------------------------------------------------------------------------------------------| At the end of Monday's call Mike Edwards suggested a change to the model that would allow intents to be attached both directly and externally and the set of intents required to be satisfied would be the union of the intents attached in these two ways. This suggestion does simplify the model and reduces optionality and is. therefore attractive. I have revised the proposal for Issue 93 to reflect this. The change required merely the removal of the paragraph spelling out the optionality in section 4.1. Please take a look. The proposal for issue 93 that I sent out last week had eternal attachment for intents paralleling external attachment for policySets. If we agree to the simplified model for intents as discussed above we should also consider simplifying the attachment mechanisms for policySets. Let's discuss on Monday and I can open an issue if need be. -- All the best, Ashok [attachment "SCA Policy Framework CD02-Rev6-Issue93A.doc" deleted by David Booz/Poughkeepsie/IBM] [attachment "SCA Policy Framework CD02-Rev6-Issue93A.pdf" deleted by David Booz/Poughkeepsie/IBM] --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]