Some more comments

[Comment 11b] :  The chicken or the egg... (or the COmposite vs. 
the Component)

(rewording of my previous comment #11)

 

It is unclear why the Composite is always the 
outermost construct, as the markup

indicates. It seems that the mark-up does not allow 
to expose the Component

directly to users, yet the component has the same 
interfacing constructs

(Services / Properties / References) as the 
Composite.

Yet apparently SCA implementations will often 
directly expose Components (which may

or may not be implemented as composites), e.g. in 
the C++ model.

Couldn't the mark-up reflect this abstraction 
and make Component top-level (beside or even 
instead of Composite?)

NOTE: this comment could be modified along my previous comment 
#9: if some form of "container"

is needed for all kinds of SCA constructs 
(Services, Rferences, Components, Composites...)

that should probably be something new, different 
from "Composite".

 

 

[Comment 12]: Best practices for most typical 
architecture patterns?

 

The control model suggested by Composites, is of 
Components invoking each others via

references and wires. It is unclear how that plays 
with more decoupled architecture patterns 

between components: 

- publish-subscribe async communication between 
Components 

(should a queue manager be itself modeled as a 
component?)

- event listeners.

 

 

[Comment 13]: I don't think there is a clear 
definition of what an "SCA runtime" is.

 

 

Regards,

Jacques