CORBA26 — New component issue: connection failure recovery

The CCM does not describe the behavior of the system in case of various fault situations. In particular, this issue only concerns itself with the recovery mechanisms of event subscriptions or facet receptacles that were automatically established through an assembly. While it is outside the scope of the CCM to describe general fault behavior, it is felt that recovery mechanisms (or their absence) should be explicitly identified for connections automatically built between ports. Otherwise, why go to the trouble of building them, since error detection and recovery wrappers would be needed around any use of them?

The following scenario highlights the various situations. It assumes that the components are deployed in separate processes on different platforms so that one of the two components remains operational despite failure or inaccessibility of the other. The scenario primarily deals with the recovery of an interface provided by Component X and used by Component Y. Appropriate questions related to event channels are also given where applicable. Event channels are themselves more difficult because the notification services adds yet another object to the set that may fail during the scenario.

Scenario: Component X declares that it provides an interface A. Likewise, Component Y declares that it uses interface A. (Or, X emits or publishes event A to which Y subscribes.) Instances of the components are combined through an assembly. Now, the assembly description indicates that a connection is to be built between X and Y. That is, the descriptor defines connections in which a connection element defines the association. Said element’s providesport acquires X’s facet A and assigns that through the usesport to Y’s interface receptacle. (For events, read these as emitsport or publishesport and subscribesport.)

The following questions arise:

When does the connection take place, during assembly construction or on reference to the port’s receptacle inside Y? That is, is this immediate or lazy initialization? When are event channels created or attached? Can the producer delay creation or attachment until a push() operation? Can the consumer accomplish the creation? Can an m:n emitter to consumer notification matrix be built? (The specification is unclear on this.)
What happens if the interface reference to A cannot be acquired because (1) X has failed or is inaccessible, (2) X fails during the get operation, or (3) X returns a nil reference?
What happens during run-time when Y invokes an operation on A and:
The application server process containing X has terminated (COMM_FAILURE returned)?
Derived valuetype arguments cannot be marshalled (MARSHALL/BAD_PARAM returned)?
The underlying object supporting A in X has been deleted (INV_OBJREF returned)?
An unexpected application error occurs (UNKNOWN returned)?
With respect to error detection and recovery:
How does one indicate the set of objects that can detect the error? Possible objects are Y, Y’s home, Y’s container, X’s container, X’s home, the assembly, an independent third party.
How does one indicate the set of objects that can recover the error?
How does one indicate whether the error should be detected?
How does one indicate whether recovery should be attempted?
How does one indicate the recovery strategy, especially if there are several objects that can recover the error?
If the strategy has multiple fallback conditions, should this logic be placed into a single object or should it be given as a precedence-ordered list?
Where should this information be specified: IDL, CIDL, or XML?
What are the implications when the components have different type and container semantics?
Let component X be transient and component Y be an entity. If component X fails, can a new X be safely created for its corresponding Y?
Assume a new X was created and the old X still exists but became inaccessible. Can the old X be detected and one of the X’s be deleted [dismissed] after the old X is again accessible?
Assume a request to X completes successfully in X but fails during the reply to Y. Can the operation be retried or the previous results retransmitted, either on the old X after recovery or on a new X?
In these questions, what happens if X is an entity and Y is transient?
In these questions, what happens if Y aborts rather than X?

Ideally, it would be nice if either the IDL extensions or the CIDL constructions permitted specification of an error recovery wrapper around access to a receptacle (or event channel). This could actually work as a general mechanism for any component and not just components grouped in an assembly. The wrapper would be a specialized object implemented specifically in the context of the component or assembly that provided the desired error detection and recovery behavior. It would be a proxy similar to a stub: it would have the same interface as the target object to which it delegates. Errors would be caught (as described) and recovered automatically, if possible. This includes the initial reference to an object, which would now be built or acquired dynamically at run-time rather than semi-statically at assembly instantiation. Multiple inheritance, in languages that support it, would be very useful in standardizing proxy behavior. The component DTD could be used to specify desirable run-time operation and associated characteristics.

rejected