Currently the core of the Additional Structuring Mechanisms for the OTS (aka
Activity Service) assumes synchronous responses from participants (Actions)
at the instigation of the coordinator messages (generated by the SignalSet).
As we have found in several recent studies and other work on extended
transactions (e.g., the OASIS BTP) there are good reasons why participants
may want to asynchronously send "responses" to messages the coordinator
hasn't yet generated. For example, in a two-phase protocol, a participant
may be able to spontaneously prepare and send the coordinator the relevant
Outcome.

In the current spec. this isn't possible directly. Obviously there are
tricks that could be played with another-level-of-indirection (e.g., enlist
a "cacheing" participant with the coordinator that the real Action enlists
with and this receives [and stores] any spontaneous responses). However,
even this doesn't really address the entire problem since the response the
Action sent (the Outcome) is made with respect to a presumed specific Signal
that the coordinator sent. So, what if the coordinator doesn't send that
Signal?

Having this as part of the core will help us to continue to support a wide
range of coordination/extended transaction protocols.

No Data Available

The broadcast method of CosActivityCoordination::Current in the CosActivity
IDL should return an
Outcome.

Editorial change to make the IDL compile

There are a couple of IDL issues with the current CosActivity module:

InvalidState is multiply defined.

(ii) The ActivityInformation struct should go after the Outcome struct,
since it now uses Outcome.

Editorial change to make the IDL compile

The ActivityCoordinator complete_activity operation may raise
ActivityPending
and ChildContextPending exceptions. The conditions under which these
exceptions
are raised should be independent of whether they occur in the root or a
subordinate node. For example, if the a subordinate node had earlier
spawned an
asynchronous thread that was not complete when the subordinate was signaled
for
preCompletion, then the application originator (on the root) should receive
an ActivityPending exception that does not cause the Activity to complete
or
mark is as failed only.
Yet, at the subordinate, the only response that the subordinate
Synchronization
Action can give during preCompletion is an Outcome of preCompletionSuccess
or
preCompletionFailed or an ActionError exception, none of which result in
the desired
behaviour.

Possible solutions are:
1. New exceptions on the Action::process_signal exception that
the root ActivityCoordinator converts to ActivityPending or
ChildContextPending.
CORBA::TRANSIENT could be used if the minor codes were architected.
This is ugly because its specific to the processing of the
Synchronization
SignalSet.
2. New predefined Outcomes for the Synchronization SignalSet that the root
ActivityCoordinator can recognize and convert accordingly. Still a
little
ugly in that the ActivityCoordinator needs to understand the meaning of
an Outcome.

In either case, the Synchronization SignalSet needs to be capable of being
redriven
after returning such an Outcome/Exception.

see above

The final adopted specification of the Activity Service specification
states, in section 2.2.1:
"If the parent of a sub-Activity is not a root Activity (i.e., it is an
interposed subordinate)
then the distribution of the ChildLifetime signals is delegated upstream to
the superior
ActivityCoordinator."

Since no service context would flow on a delegated process_signal_set
request to an
upstream ActivityCoordinator, then any Action registered in the upstream
node with an
interest in the ChildLifetime SignalSet would not be able to determine the
identity
of the child activity begun.

Any solution to this problem needs to interoperable rather than dependent
on implementation
since the upstream ActivityCoordinator could be part of a foreign domain.

2 potential solutions are:
1. New methods on the ActivityCoordinator and and SignalSet interfaces:
ActivityCoordinator::process_signal_set_with_data(in string ssName,
in CompletionStatus cs, in any signalData);
and
SignalSet::get_signal_with_data(inout boolean lastSignal, in any signalData);

The subordinate Coordinator-Action could build the ActivityInformation any
required by the ChildLifetime SignalSet and pass this in the signalData on
the upstream process_signal_set_with_data.
2. Change the specification to state that ChildLifetime signals are distributed
from the node in which the child Activity begins. In the case where there are
Actions registered with the parent in an upstream node on which the child does
not execute, then these Actions are not informed of the event.

(2) is simpler but compromises the ideal of location transparency.

see above

In the Additional Structuring Mechanisms for the OTS, an Action can register
interest in more than one SignalSet, i.e., it can be passed to add_action
more than once, with a different SignalSet parameter. However, remove_action
is not parameterised on the SignalSet, so currently it must remove the
Action from all registered SignalSets. We can either add the SignalSet as a
parameter to remove_action or add another method, leaving the semantics of
remove_action as they are

close no change

The current specification implicitly assumes that, as with the OTS, contexts
do not get propagated on system messages such as processSignal. However,
this needs to be explicitly stated.

close no change