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

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-assembly message

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


Subject: Re: [ASSEMBLY-88] Proposal discussion



Folks,

I was somewhat surprised by some of the reaction to the proposal made below to resolve issue 88 in the TC call yesterday.

I take the view that the proposal gives the functionality required by a designer at minimal cost and
is in fact considerably simpler than the current design involving a separate data structure in a separate file.

My view is that the functionality that is required here is that the assembler - the creator of composites in a top-down scenario -
can restrict what a developer ("implementation creator") is able to do, so that a particular composition "does what it says on
the tin" - and no more.

It seems to me that the simple marking I propose does exactly this - and with minimal effort.

A point was made that by having a separate file contain the data structure used for constraining, that this could be reused, seems
far from the reality of the development experience for the assembler and is not a feature that is likely to get much use.  Frankly,
it is much easier to copy the configuration of a component from one place to another, if that is required, than it is to point each
component to a shared file.  And I note that in the case where a shared file is used, it is STILL necessary to lay out the contents
of the component structure in order to perform the actual configuration of that component - so there is still real duplication that
just gets in the way of the assembler.

So I argue that a separate "constrainingType" file is actually an unnecessary overhead of little benefit.  The proposal below
gives the assembler all the real control that is necessary - and at minimum cost.


If true sharing IS required, then it is more obvious to use the <include/> capability and reuse the complete definition of a
component which is structured for reuse (eg - all services declared, references declared but left unwired).  This is more
meaningful than sharing some constrainingType file.


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



From: Mike Edwards/UK/IBM@IBMGB
To: "OASIS Assembly" <sca-assembly@lists.oasis-open.org>
Date: 18/11/2008 15:10
Subject: [sca-assembly] [ASSEMBLY-88] Possible duplicate functionality offered by constrainingType and component - proposed resolution






This is a proposal to resolve Issue 88.


Summary:

- remove constrainingType from the specification

- add an attribute to <component/> called @constrained which is a boolean value with a default of "false"


- a <component/> with constrained=false is just like a component today - no changes

- a <component/> with constrained=true requires its implementation to follow rules similar to those for
 constrainingType - namely:


"When the component using an implementation has @constrained=true the implementation's component type
MUST contain all the services, references and properties explicitly declared by the component. The component’s
references and services can have interfaces specified and can have intents specified - the implementation's

service interfaces must be the same or a superset and its reference interfaces must the the same or a subset, while

any intents present in the componentType must match those declared by the component.. An implementation MAY
contain additional services, additional optional references (multiplicity 0..1 or 0..n) and additional optional properties

beyond those declared by the component, but MUST NOT contain additional non-optional references
(multiplicity 1..1 or 1..n) or additional non-optional properties (a property with mustSupply=true). (and any such references

will not be wired and any such properties will not be configured by the component). Any services in the componentType

which are not also declared by the component cannot be wired or promoted"


I believe that this allows a component to control what its implementations MUST look like, which is the idea behind

constrainingType.


Detailed changes:




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]