CORBA 2.6 NO IDEA Avatar
  1. OMG Issue

CORBA26 — Component assemblies do not follow composition pattern

  • Key: CORBA26-58
  • Legacy Issue Number: 4077
  • Status: closed  
  • Source: Iconixx ( Thomas Hawker)
  • Summary:

    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

  • Reported: CORBA 2.4.1 — Fri, 24 Nov 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:


  • Updated: Fri, 6 Mar 2015 20:58 GMT