A few comments from Jacques Durand

[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.