OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-policy message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [sca-policy] ISSUE 43: Use of intents from component types in policySet algorithm


 

The actual text for the proposal is the following.  In section 4.10, change the beginning of the algorithm to the following (the bold text in step 4 is new):

 

 

For each element in the composite definition document that is a subtype of the abstract XSD elements <sca:binding> or <sca:implementation>, including any <sca:binding.sca> elements that are implied by the lack of other service or reference bindings:

 

A. Calculate the required intent set that applies to the target element as follows:

1.    Start with the list of intents specified in the element's @requires attribute.

2.    Add intents found in any related interface definition.

3.    Add intents found in the @requires attribute of each ancestor element.

4.    Add any required intents from the corresponding element of the component type.  The element may not be present, but implied.  Steps A1 to A3 should also be run on the component type to determine the required intents to use for that element.

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

6.    Remove any intents that do not include the target element's type in their @constrains attribute.

7.    If the set of intents includes both a qualified version of an intent and an unqualified version of the same intent, remove the unqualified version from the set.

 

Since step 4 is new, the subsequent steps have been renumbered.

 

Note that the sentence before step A was somehow dropped between version 1.0 and CD01.  I believe its removal was just a simple mistake.  Obviously, without that sentence the rest of the algorithm is meaningless, since that sentence defines what the “target element” is which is referred to by the rest of the algorithm.  It just needs to be added back in.

 

Michael

 


From: Joshi, Kaanu [mailto:Kaanu.Joshi@patni.com]
Sent: Thursday, December 20, 2007 3:22 AM
To: sca-policy@lists.oasis-open.org
Cc: Michael Rowley
Subject: RE: [sca-policy] ISSUE 43: Use of intents from component types in policySet algorithm

 

Hi,

 

A new issue has been created in the SC Policy JIRA. The URL to this issue is: http://www.osoa.org/jira/browse/POLICY-43

 

Regards,

Kaanu Joshi

 


From: Michael Rowley [mailto:mrowley@bea.com]
Sent: Tuesday, December 18, 2007 10:44 PM
To: sca-policy@lists.oasis-open.org
Subject: [sca-policy] NEW ISSUE: Use of intents from component types in policySet algorithm

 

 

RAISER: Michael Rowley

 

TARGET: Policy Framework Specification, Guided Selection of PolicySets section

 

DESCRIPTION:

The current policySet selection algorithm does not take into account any of the required policy intents defined in the component type of a component.  The assembly specification states the policy intents specified in the component type cannot be overridden by a component that uses that type.  The implication is that all of the required policy intents for a component type also apply to any component that uses that type.  This needs to be figured into the policySet selection algorithm.

 

 

PROPOSAL:

 

Add a step in the algorithm after step A.3 which adds in the required intents from the component type’s corresponding service, reference, or component type definition.

 

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]