sca-assembly message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [ASSEMBLY-88] Proposal discussion
- From: Mike Edwards <mike_edwards@uk.ibm.com>
- To: "OASIS Assembly" <sca-assembly@lists.oasis-open.org>
- Date: Wed, 19 Nov 2008 09:54:58 +0000
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]