CORBA26 — Deployment Object Life Cycles

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
interrelationships.

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
  assembly?
• When and how are event subscriptions released from their publisher or
  emitter?
• 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.

see below