CORBA 2.6 NO IDEA Avatar
  1. OMG Issue

CORBA26 — Deployment Object Life Cycles

  • Key: CORBA26-45
  • Legacy Issue Number: 3982
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The description of the life cycle and system dynamics of the various
    objects that contribute to component deployment and execution is
    incomplete. From an implementation perspective, there are many run-time
    objects involved that contribute to, or are required for, the overall
    operation of a component. But the CCM does not adequately show the
    interrelationships among such objects. Even the most rudimentary
    implementation depends on the assumptions hidden behind these

    The following questions need to be addressed in order to build a
    portable implementation:

    1. Deployment support services:

    • What is the life cycle of the support services needed to create an
      Assembly object?
    • Do these already need to be executing in, known to, or exposed by one
      or more servers?
    • How are these services contacted in a dynamic environment?
    • Is this structure equivalent to the TINA DPE concepts?
    • What is the life cycle of the Assembly object itself?
    • When and how is an Assembly object deleted?

    2. Application servers, containers, homes, components:

    • What is the exact life cycle of these various objects?
    • The specification identifies how component instances are created. How
      are they deleted?
    • When and how is a home removed from a container?
    • When and how is a container removed from an application server?
    • When and how is an application server terminated?

    3. Related or referenced objects:

    • What is the life cycle of event channels?
    • Does the life cycle of objects vary if they are "private" to an
    • When and how are event subscriptions released from their publisher or
    • When and how are objects "registered" with the naming service or
      trader unregistered?

    A full and representative life cycle description of the run-time objects
    denoted above is necessary to understand the dynamic system model and
    its inherent limitations. This will be critical for systems that must
    exhibit very high reliability and availability. There appear to be many
    assumptions, particularly with respect to the deployment tools, that
    affect recovery operations from fault conditions. These must all be made
    explicit. Thus, the CCM description should include a comprehensive state
    transition model. This may be documented as cooperating or nested state
    machines for the various pieces.

  • Reported: CORBA 2.4 — Mon, 23 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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