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: NEW ISSUE: Improve description of the overides available to the two different hierarchies in SCA


RAISER: Michael Rowley

 

TARGET: Policy Framework Specification

 

DESCRIPTION:

 

There are two different hierarchies that can potentially override intents or policy sets in SCA.  One hierarchy is the hierarchy of XML elements above the service (the "XML hierarchy"). An intent may be specified on any element. The meaning of such a declaration is just that it provides default intents for any descendent <binding> or <implementation> elements. Here is an example of a composite (C1) with one component (X), which is promoted as composite-level service (C1/S).
 
<composite name="C1" requires="i1">
   <service name="S" promotes="X/S">
      <binding.ws requires="i2">
   </service>
   <component name="X">
       <implementation.java class="foo"/>
       <service name="S" requires="i3">
   </component>
</composite>
 
 
This composite has 3 intents: i1, i2 and i3. Assume they are all mutually exclusive.
 
The i1 intent is specified on the root element and becomes the default for any element below it that does not override it. In this case, _both_ the composite-level service (C1/S) and the component service (X/S) specify different intents, so i1 is overridden twice.
 
The "implementation hierarchy" of overriding (going up) goes from component service to composite service (promoted) to component service (implementation.composite) to composite service (promoted) etc.
 
Showing this requires a second composite. The following has a composite (C2) with one component (Y) implemented using composite (X) and providing the composite-level service (C2/S).
 
<composite name="C2" requires="i4">
   <service name="S" promotes="Y/S">
      <binding.ws requires="i5">
   </service>
   <component name="Y">
       <implementation.composite name="X"/>
       <service name="S" requires="i6">
   </component>
</composite>
 
Here we define 3 more intents: i4, i5 and i6.
 
The implementation hierarchy (from bottom to top) looks like this:
   X/S
      C1/S
         Y/S
            C2/S
 
In this hierarchy, there is no overriding of intent. Any intent that is required at one level, must not be explicitly contradicted at a level above. In other words, C1/S _cannot_ require "i2" if it is mutually exclusive to "i1", which is defined on X/S.
 
The fact that this direction of hierarchy is not overridable is mentioned on line 451 of the assembly spec WD1 (and possibly other places).
 
The semantics for overriding intents in the XML hierarchy is captured in the policy algorithm in section 1.4.10 of the policy spec.

 

This distinction need to be made clearer in the policy framework spec.

 

PROPOSAL:

Possibly use some of the text from the description above.

 



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