OTS — Interoperability of childLifetime

When a child Activity completes, its parent's ActivityCoordinator must
drive the childComplete/childLifetime SignalSet to produce the
childComplete signal for distribution to any Actions with an interest in
this signal. This Signal contains an ActivityInformation structure that
indicates the GlobalId and final CompletionStatus of the completing
Activity. (A separate issues proposes that the final Outcome of the child
Activity also be included in the ActivityInformation). The specification
leaves it to an Activity service implementation to determine how a parent
Activity is notified of its child's completion and how the
ActivityInformation is obtained by the parent's childComplete/childLifetime
SignalSet. A practical approach is for the child ActivityCoordinator to
call its parent ActivityCoordinator's
process_signal_set("org.omg.childComplete") method. If the child Activity
is active on the thread when childCompletion processing occurs, then the
SignalSet in the parent can determine the child's GlobalId and
CompletionStatus via the Current interface. (Note: the completionStatus of
the child may be modified by the completion SignalSet during completion
processing; it is the final completionStatus that should be reported
during childComplete processing).

An interoperation issue arises if a child Activity is rooted on a node that
is downstream from the parent's root. In this case, childComplete signals
need to originate from the parent's root ActivityCoordinator/SignalSet.
Mechanically, the completing child should inform its (local) parent
ActivityCoordinator by whichever implementation-specific means it uses and
then the local (subordinate) parent ActivityCoordinator has to push this
back up to its ultimate superior for distribution throughout the tree. The
means by which this happens need to be defined to ensure interoperation
across different vendors' implementations. One approach would be for the
subordinate ActivityCoordinator to drive its superior's
process_signal_set() method, ensuring that the ActivityContext is
propagated on this flow (in order that the superior can obtain the child's
GlobalId). A similar consideration holds for childBegin. There are issues
with this approach; one is that any child Activity, begun at any node
downstream to its parent, will always have its context imported (as a
subordinate) to all upstream nodes on which its parent is active.
A different solution to the problem might be to introduce a new method on
the ActivityCoordinator interface that can be used during child-completion
to pass the ActivityInformation object. This would mean that no service
context would need to flowed and all the information required to deliver
the childComplete signal would be available to the parent. This could be
something like:
void ActivityCoordinator::set_child_completed(in ActivityInformation ai)
It would still be implementation-specific how that ActivityInformation got
added to the signal, but that is not an interoperation issue.

see above