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 38 - Improve description of the overides available to the two different hierarchies in SCA: Proposal, Updated


 

I’m concerned about this new rule 3:

 

Rule 3: For a composite used as an implementation by a higher-level component, if the higher level component applies implementation intents to the composite, those intents act as if they are attached to the <composite/> element and are applied to components contained within the composite as defined by Rule 1 for the structural hierarchy.

 

I believe that you may end up having intents that were meant to be defaults looping back and turning into strict requirements.

 

I hope the following example will illustrate.  I’ll start with the higher composite in the implementation hierarchy (I removed some things that don’t apply to my case):

 

<composite name="C2" requires="i4" xmlns:foo=”http://foo”>
   <component name="Y">
       <implementation.composite name="foo:C1"/>
       <service name="S" requires="i6">
   </component>
</composite>

 

Imagine that i4 and i6 are mutually exclusive.  According to the structural hierarchy, this should be OK, and i6 will override i4.

 

However, i4 will also be pushed down into the “foo:C1” composite, as if it had written:

 

<composite name="C1" requires="i4" targetNamespace=”http://foo”>

   <service name="S" promotes="X/S">

      <binding.ws>

   </service>

   <component name="X">

       <implementation.java class="foo"/>

       <service name="S">

   </component>

</composite>

 

The structural inheritance will then push that i4 down to the service, as if it had said:

 

   <service name="S" promotes="X/S" requires=”i4”>

 

This means that the implied component type of C1 will have a service with @requires=”i4”.

 

Finally, due to Rule 2, the @requires=”i4” of the C1’s component type will conflict with the service line in C2:

       <service name="S" requires="i6">   -- conflicts with the “i4” that came up from the component type

Do you see the problem?

 

Michael

 


From: Mike Edwards [mailto:mike_edwards@uk.ibm.com]
Sent: Tuesday, February 12, 2008 6:30 AM
To: OASIS Policy
Subject: [sca-policy] ISSUE 38 - Improve description of the overides available to the two different hierarchies in SCA: Proposal, Updated

 


Folks,

Here is an updated version of the proposal for Issue 38:




Comments welcome.


Yours,  Mike.

Strategist - Emerging Technologies, SCA & SDO.
Co Chair OASIS SCA Assembly TC.
IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
Phone & FAX: +44-1962-818014    Mobile: +44-7802-467431  
Email:  mike_edwards@uk.ibm.com



 

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU







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