Timeouts in CDL

Hi,

Just wanted to make a comment on the usage of 'time' within CDL, as the different mechanisms do not seem very consistent. Therefore as part of the last call process, I thought we may wish to review this and simplify the mechanism - an outline proposal is provided at the end.

There are currently three places where time is used, the first two provide a timeout scope mechanism, and the third appears to primarily be used as a 'sleep' activity:

1) Interaction - time to complete

There is an element within the interaction called 'timeout' that can be used to specify the time or duration when the interaction must complete by. If the interaction has not completed, then the 'record' elements referenced by the timeout will be performed. If one of these record elements has a 'causeException=true', then this will cause an exception, otherwise the choreography would just continue past the interaction (with the relevant variables set to indicate the failure).

2) Choreography - 'complete' expression

The complete expression on the 'choreography' element is used to prematurely complete the choreography in a successful state. If the complete expression uses a timeout CDL function, then a timeout can cause the choreography to be completed. It does not seem valid that a choreography that has terminated due to a timeout should be completed in a successful state + this mechanism does not enable activities to be triggered to process the timeout, to enable the state to indicate a failure.

3) Part of a WorkUnit guard condition

When used in a blocking guard condition, with the block attribute set to true, the guard would block until the timeout has occurred. The semantics of this construct is not representing a conditional statement, but is causing a 'sleep' to occur prior to enabling the activities within the work unit.



Proposals:

The first two scenarios would be better represented using a 'timeout' scope activity, which would contain the activities that were subject to the timeout. If the activities within this scope do not complete within the defined time period or duration, then these activities will be terminated and control will be passed to a timeout handler associated with this scope.

In the first scenario described above, the 'record' elements that would have been triggered by the timeout could be replaced by assign activities that would achieve the same goal.

In the second scenario described above, this new mechanism would enable activities to be performed when the timeout occurs, to determine in what state the choreography should really complete.

The other benefit of this approach is that the set of activities within a particular timeout scope can be wider than a single interaction, and less than a whole choreography. Therefore it would be possible to define a timeout duraction associated with a set of interactions - which in practice is more likely to be the case.

The final part of the proposal is to create a new 'sleep' activity to replace the use of the timeout functions within the workunit guard condition. This makes the semantics of this activity very clear, and it also removes the requirement for having the time based CDL functions - which will simplify the XPath expressions.


Regards
Gary