sca-assembly-comment message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: A few comments from Jacques Durand
- From: "Jacques R. Durand" <JDurand@us.fujitsu.com>
- To: <sca-assembly-comment@lists.oasis-open.org>
- Date: Fri, 5 Jun 2009 18:34:04 -0700
[Comment 1] General Comments:
A nice overall model, that appears able to assemble
across platforms and across
implementation technologies. Of course being at
such a general level, there are
references to mechanisms and concepts that need to
be detailed in other specification
or profiles. It would be nice to warn the reader
up-front (Introduction) that the goal
of this specification is to define primarily a
model and its representation, and that
many other concepts needed to make it work are
expected to be covered elsewhere
(either other SCA specifications, or others).
A short summary of how the other SCA specs
complement this one, would be helpful.
[Comment 2] Component Type identifier:
- It appears that a component Type - unlike
Component - has no identifier (e.g. no name).
How can we trace and identify which COmponent Type
a Component has been derived from?
I still find it odd that a Component does not
explicitly refer to its ComponentType,
and that we apparently need to look into the
implementation to make that link.
Won't that cause a problem during the design
process and in tools?
What if I need to version a component Type?
etc.
- At the very least, if the Implementation is the
only way to determine which Component Type
a Component is derived from , then a well-defined
identity scheme should be described for Implementations.
[Comment 3] Relationship between ComponentType,
Implementation :
- L700: ...service. The @name attribute of a
service element of a <component/> MUST be unique
amongst the service elements of that
<component/> [ASM50002] The @name attribute of a
service element of a <component/> MUST match
the @name attribute of a service element of
the componentType of the <implementation/>
child element of the component. "
- The expression "the componentType of the
<implementation/>..." does suggest that
an implementation can only be used in one
ComponentType. Is that the case ?
Can't we use the same implementation in different
component types, e.g. representing
different ways to use a same large chunk of code
that we don't want to split?
Otherwise this means that there is only one unique
ComponentType associated with
this implementation, and all my Components need to
configure that single ComponentType
no matter how different they are, or which subset
of the implementation they use.
[Comment 4] differences between Services /
interfaces of a Component and of a ComponentType:
- It is understood that Services and related
interfaces of a COmponent Type, can be under-represented
in a derived (or "configured") Component, as the
latter may be interested in only a subset of what the
implementation has to offer.
- interestingly, the interfaces associated with a
component's References must be a superset
of those in the ComponentType.
If my Component is only intersted in a subset of
the functions of the implementation,
to the point where the Services/interfaces are a
subset of those of the ComponentType,
can't in many cases this subset of functions be
known to only use a subset of References operations
as well?
This rule appears to be too restrictive and
unpractical. Its intent - I guess - is to ensure that
an Implementation of a ComponentType will always be
able to access the refs it needs,
when deploying a Component configured after this
ComponentType. But in many cases you can tell
which References are needed based on which Services
are used - and same thing for the operations
inside large interfaces.
[Comment 5] Services, Refs and Properties declared
by an implementation:
- L158: "Depending on the implementation type, the
implementation can declare the services,
references and properties that it has and it also
might be able to set values for
all the characteristics of those services,
references and properties. "
- isn't that the same thing as defining a
ComponentType for this implementation?
- If not, then it seems that it is more some kinds
of capabilities that the implementation
declares, rather than full-fledged Services /
References.
E.g. an implementation could have "Interfaces" but
no Service name associated with these.
So it is more like it "declares" interface
capabilities, that a ComponentType can then use
to define specific Services, with a name of its
choice.
[Comment 6] intents and policy sets in
Implementations:
- in the bullet list L162 it seems that the
implementation has the ability to
"define" intents and policy sets discriminately for
Service, Reference and Property.
What is the relationship between these
declarations, and the single list
of policy intents, and of policy sets that shows in
the mark-up L435 (3.1.4)?
Should be clarified.
[Comment 7] Define implementation
Instance:
- L584: Components are configured instances of
implementations. What does mean Instance here?
If this is a deployed run-time implementation as
suggested in L664 then that is
rather late in the spec for a definition, as we
have heard of "implementations"
long before. It sounds in L664 that there is a
notion of "run-time" instance (as opposed
to a "static" instance?) Need a more precise
definition (in a glossary?)
[Comment 8] Figures glitches:
- Every figure should be preferably referenced by
its Fig # (instead of
"the following picture illustrates ..." use "Figure
3 illustrates ...")
- Fig 4: can we add labels to the dashed lines?
They obviously have different meanings
from one line to the other. Would be great to use a
precise terminology to identify these
relationshhips ("derived-from", "refers-to")
throughout the spec.
- Fig 5 is same as Fig 1. Can't the section 4.5
just refer to Fig 1 instead?
Fig 6, 8 and 10 are the same too and redundant. A
single one could be referred.
[Comment 9] Composite is too
inclusive:
Section 5.6: A composite really has no
architectural semantics as it can be any subset
of child elements allowed in the Composite
container.
Consequently, it has only the semantics of an
identifiable wrapper or bag for almost anything,
as illustrated in fig 13.
This is at odds with the intuitive meaning of a
Composite as a "composite application"
or usable as implementation of a Component, as
conveyed by most of the early parts of the specification
including Section 5 (from 5.1 to 5.5).
That confuses the reader. So I'll make a bold
suggestion less disruptive than it seems actually:
- dissociate clearly the "inclusion" mechanism
necessary to identify and import the parts you need,
from the assembly mechanism of these parts into
architectural units or composites.
That could be done by:
- The inclusion mechanism does not target
"Composite" , but instead a simpler construct
called a "Bag" (or a "kit" or a "toolbox"), that can contain any set
of parts as its elements.
(and if a Bag refers to other Bags, what you
include is the union of all their contents).
- once several Components are configured and wired
to work together, that system becomes
a "Composite application" (or in short:
"Composite"). So a Composite would always contain
at least a Component. In turn this Composite can be
used as implementation of a componentType,
(as "Composite Implementation").
- only for the purpose of becoming an
implementation of a componentType (Composite Implementation),
should this Composite application bother to
advertise its own Service/References/Properties as
described in sections 5.1 to 5.4., with the meaning
given in section 3 (L158-L170).
These sections (5.1 to 5.4.) now would concern
"Composite Implementations".
So in Figure 3, the only change needed is that
COmposite X and Composite Y are really a single Composite,
that could have been assembled from included
material from two "bags" Bx
and By.
Same in Fig 13: it really shows a single composite,
and each one of the internal squares
would
identify the included "bag" the material comes
from.
[Comment 10] Autowire:
- the notion of "compatibility" for Autowire
feature is rather vague and too inclusive.
I suspect that looking at the component interface +
policy intents is not enough. That leads to
two suggestions:
1. The mechanism involved in Autowire should be
more modestly described as "Automatch", the result of
which could be several (hopefully a small number)
wiring options, to choose from.
2. In order to make autowiring (or automatch) more
effective, a simple mechanism for semantic
annotation could help. E.g. a Binding element ina
reference could have some "attributes"
that the autowire mechanism will try to match to
candidate Services.
E.g. If I have two components that provide the same
service "address validation" with similar
intents & policies, but for different regions
of the world: US vs. S.E.Asia. I'd like to annotate
each service with an "area" attribute = "US" or
="S.E.Asia". Then if my Composite is designed
for the US market, I'll annotate my reference
binding with a similar "area" attribute = "US",
to be involved in the compatiblity assessment. A
kind of "intent" for Services & Interfaces...
Of course it is not as simple as this - but SCA
should provide the "hooks" for such a semantic
annotation.
[Comment 11] Mark-up snippets in Section 4 should
not show Composites:
Several code snippets in Section 4 show "composite"
element embedding all.
Suggest to remove these: irrelevant to section 4
that should remian independent from Composite.
-Jacques
D.
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]