CORBA26 — Component assemblies do not follow composition pattern

I have noticed that assemblies do not follow the composition pattern.
Thus, assemblies cannot themselves be used as building blocks for other
assemblies. I think part of this comes from the fact that installation
and management of assemblies is mostly "magic" done behind the scenes by
various installation and support utilities. In order to "reuse" an
existing assembly, one must copy an existing assembly definition (I
guess constructed completely by hand) to a new definition, which must
then be tailored to incorporate the new strategy and pieces. This seems
counter-intuitive, besides being manually intensive, for if an assembly
does useful work, why would I want to expose its internal details just
to take advantage of that usefulness? As pointed out by Mr. Dubois in
issue 3939, because all of that "magic" is not specified by various
formal interfaces, it is highly likely approaching certainty that
assemblies will only work for the particular vendor on which they were
built. Since I believe the intention was to promote interoperability in
general and as much code automation as possible for components in
particular, it would seem that we want to restrict the "magic" by taking
the formalisms behind assemblies to another level.<p>

I suggest that, just as a <i>composition</i> exists to tie a component,
its home, and various configuration properties together, we can create
for the CIDL grammar productions for an <i>assembly</i> to tie multiple
compositions together. Subsequently, an assembly could be treated as a
composition, to be used by other assemblies, only exposing selected
facets or events from its constituent entities. I think there are a
number of advantages to this approach: (1) It solves certain semantic
ambiguities with assemblies, for instance whether facets, receptacles,
and events are private or public to the assembly. (2) The assembly
implementation, its XML, and its relation to its constituents and home,
can be generated automatically from the CIDL description [we have been
working on this extensively]. Our approach is to use an assembly
exactly like a composition, as the realization of a component and home
definition. Our research efforts imply that all of the assembly
component and home code can be automatically generated - no user
tailoring will be needed. (3) Because the assembly now acts as a
component (composition), it can be reused by other assemblies without
knowledge of its internal structure. (4) Activation of an assembly
appears the same as for any other component; it merely requires formal
specification of previously undefined interfaces to accomplish it, thus
promoting portability and interoperability. (5) The assembly
"deployment magic" becomes exposed through the interfaces above, thus
removing several of the deployment tools and servers/services identified
in the specification. The only real drawbacks I see are the complexity of the assembly
productions (we can really get out of control with this) and that
assemblies now have an actual code base rather than being "magical
creatures" managed by the deployment tools. I guess these are both
two-edged swords. There might be a run-time footprint change for all of
these extra interfaces, but those had to be lying around in other places
anyway.

rejected