The problem

Currently CDL does not permit a business protocol to be specified, where there
is an arbitary number of concurrent threads of communication. For example, in a
request for quote scenario, we would want to define an inner (sub) choreography
that represents the communication between a buyer and a potential supplier.
However, the outer choreography may want to initiate this sub-choreography
across a list of potential suppliers (concurrently) and then evaluate the best
quote, before proceeding with the single selected supplier.

At the moment this business protocol could only be specified with each
sub-choreography being performed in sequence - i.e. talking to one supplier at a
time. However, in real life these would be performed concurrently.

The problem is that the repetition construct, that would be required to iterate
through the list of suppliers, can only execute a single iteration at a time.
All the activities within the body of the repetition must complete before the
next iteration can happen.



How to initiate asynchronous activities

In previous discussions, there were two suggestions of how to handle the
initation of the asynchronous concurrent flows.

(1) Add a 'concurrent' boolean flag to the workunit, to indicate that a
repeating workunit should perform each iteration concurrent. In practice this
would mean the body of the workunit would be performed asynchronously, so that
it does not block the next iteration of the loop being performed.

The problem that was found with this approach is that generally within the
repeating workunit, some of the activities would be used to update state
information which would then be evaluated within the repeat and guard conditions
on the subsequent iteration (e.g. updating a loop counter). Therefore the
problem becomes one of determining which activities within the loop body are to
be performed asynchronously, and which are related to the loop evaluation.

Without changing the structure of the workunit repetition to make this clear,
this does not seem the most natural solution to the problem.

(2) Add an 'asynchronous' attribute to the perform activity. This indicates that
the execution of a performed choreography should be performed asynchronously,
and not block the activity that is following the perform activity.

This approach would have some issues related to choreography lifeline, which
would need to be considered, but does overcome the problems with the previous
solution. The workunit repetition could be used to control the iteration through
the list of suppliers, and the asynchronous performed sub-choreography could be
bound to the state of the choreography, to enable it to query shared information
and update shared state with relevant results (i.e. its quote).

One issue with this approach is that we would need to consider what should
happen if an enclosing choreography attempts to finalize a sub-choreography that
has not completed. One approach is that this could block, pending the completion
of the sub-choreography, and therefore acts as a type of 'join'. Another
approach, which could be used in conjunction with the blocking finalizer, is to
have a CDL function that tests whether the sub-choreography with the supplied
choreography id (from the perform activity) has completed. Again, if part of a
blocking workunit, this could block until true, acting as a 'join'.

This second approach seems to more naturally fit into CDL, and it reflects the
fact that generally the unit of work that is being concurrently performed is
generally multiple instances of the same pattern of activities - i.e. a sub
choreography.



How to handle joins related to those asynchronous activities

As discussed above, joins could be achieved on a single sub-choreography, using
the finalize or an appropriate CDL function.

Other situations where a join may be required is where the join is based on
business related information as opposed to the sub-choreography instances
themselves. This can be achieved using a blocking workunit with an appropriate
condition related to the state information being manipulated by the
sub-choreographies (e.g. a quote has been received that is within my acceptable
parameters and I have waited long enough, so I am not interested in any other
outstanding quotes).

Once the join has occurred, we may then want to terminate any remaining active
sub-choreographies - possibly therefore would need a 'terminate' activity
similar to the 'finalize' syntax.



What should happen if outer choreos complete

Sometimes we may want the sub-choreographies to remain active even when the
enclosing choreography has completed. This is similar to the situation where a
sub-choreo is awaiting finalization, and this may not occur until the finalizer
on a higher level choreography is cascaded down a hierarchy of performed
choreographies.

Alternatively we may want to define an explicit lifetime for the sub-choreos
that ends when the enclosing choreography completes. This may take the form of
an attribute on the choreography. Or we simply have a <terminate
choreographyId="all" /> variation of the terminate activity, which terminates
any remaining active sub-choreographies for this choreography.



Regards

Gary