Re: Fw: Ideas for 'n' multiple concurrent flows issue

Gary, 
 
Added as issue 1166. 
 
Greg

>>>Gary Brown <gary@enigmatec.net> 03/15/05 3:29 pm >>>
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