Fw: Ideas for 'n' multiple concurrent flows issue

Hi
Don't think this has been logged as an issue in bugzilla yet, but was briefly discussed at the f2f. I consider this to be an important issue that must be resolved. Below is some ideas on a possible approach, but it needs email discussion to flush out the potential issues before a proper proposal can be written - so please comment asap.



Handling an arbitrary number of concurrent flows

9th March 2005

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