A few comments from Jacques Durand

["Jacques R. Durand" <JDurand@us.fujitsu.com>]

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