sca-assembly-comment message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Some more comments
- From: "Jacques R. Durand" <JDurand@us.fujitsu.com>
- To: <sca-assembly-comment@lists.oasis-open.org>
- Date: Tue, 23 Jun 2009 14:48:39 -0700
[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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]