Fw: Multiple participants

This is an issue regarding the fact that at the moment CDL does not support a choreography which needs to *concurrently* perform multiple instances of a sub-choreography against multiple participants (e.g. request for quote procedure).

We need to determine whether this is a scenario that needs to be supported in the last-call version of CDL, or whether it can wait.

----- Original Message ----- 
From: Gary Brown 
To: Martin Chapman ; steve@enigmatec.net 
Cc: Nickolas Kavantzas 
Sent: Friday, November 05, 2004 1:47 PM
Subject: Fw: Multiple participants


Hi Martin/Steve

I think we need to add this topic to the next agenda for discussion. The basic summary of the issue is:

Currently it is not possible to model a choreography that involves a particular sub-choreography being performed concurrently with multiple participants. Examples of this type of choreography may be in a request for quote scenario, where we would want to send the RFQ document to 'n' potential suppliers in parallel, and then select the "best" quote.

The limitation is that currently the repetition construct (workunit with a repetition condition) effectively executes the repeated activities in sequence (i.e. one at a time), not allowing any concurrency.

Nick and I have started to discuss possible solutions, but I think the issue needs to be raised to the group to determine whether this is something that is so important that it is required for last-call, whether it could be solved as one of the 'tidy-up' fixes resulting from feedback of building reference implementations, or whether it is not considered important enough for CDL1.0.

I have not raised this on the public list yet. If you would like me to do so, prior to the conf call, then let me know - otherwise possibly we should just minute the discussion on the conf call.

Regards
Gary

----- Original Message ----- 
From: Gary Brown 
To: Nickolas Kavantzas 
Cc: steve@enigmatec.net 
Sent: Thursday, November 04, 2004 9:33 AM
Subject: Re: Multiple participants


Hi,

What you propose is potentially ok, although I think there would need to be a rule that stated that the overall workunit would only complete when all concurrent interations of the workunit had completed. I agree that it needs more consideration to determine any affects........ as to whether it is a showstopper, that would be a decision for the group. I think it would preclude having multiple concurrent conversations of the same time - and we may therefore need to declare this limitation in the spec???

Possibly we need to raise the issue to the group and let them decide whether we can afford the time - or possibly this is a post last-call issue, with the intention to get a solution asap?

BTW - this impacts the correlation problem, as if we have multiple concurrent instances of a performed choreography (for example) in which that choreo establishes two or more new channel instances, then we would need to be able to correlate the channel instance to the overall session instance, but also to the particular 'thread' instance.

This is another issue that may have to be shelved for now - still discussing it with Steve to see if we can come up with enhancements to the previous suggestion.

Regards
Gary


  ----- Original Message ----- 
  From: Nickolas Kavantzas 
  To: Gary Brown 
  Cc: steve@enigmatec.net 
  Sent: Wednesday, November 03, 2004 8:21 PM
  Subject: Re: Multiple participants


  Gary, i understand your concern.


  Here are some initial thoughts:

  Perform does a textual substitution and NOT is not really a function call. So we cannot make it an 'async' oper. As you
  remember a similar issue came up with supporting recursion in CDL when performing a choreo. As I explained
  in the NY F2F this was not allowed for CDL because of the same reason.


  Oneidea that comes to my mind is that we could change the semantics of WorkUnit when repeat is defined for accomplishing 
  what you are looking for: 

  We could add a new attribute 'concurrent' in the WorkUnit that can be true only if repeat is defined.

  Here is an example:

  <workunit repeat="boolean XPATH-expr" concurrent="true">
     <seq>
         ixn
         perform
         ...
     </seq>
  </workunit>



  The new workunit semantics, when attribute 'concurrent' is set to true, would be :

  when the repeat is evaluated and it is true then the body of the workunit is enabled to be performed but in addition the repeat 
  is evaluated again immediately without waiting for the body of the workunit to complete before it will be re-evaluated (as is the
  case today in CDL). Under the new semantics one can have two or more instanses of the workunit body being performed 
  concurrently.

  What do you think? 



  BTW, do you think that this is a showstopper for us before we do the last-call? I am kind of
  uncomfortable making these kind of design changes so late in the game, since they may have greater
  implications than one can think in a short timeframe.

  --
  Nick
    ----- Original Message ----- 
    From: Gary Brown 
    To: Nickolas Kavantzas 
    Cc: steve@enigmatec.net 
    Sent: Tuesday, November 02, 2004 11:33 PM
    Subject: Multiple participants


    Hi Nick

    Just wanted to pass something by you, regarding choreographies with multiple participants.

    One problem I see is that any choreography that needs to deal with 'n' participants (e.g. in a bartering situation), essentially needs to be able to perform a particular sub-choreography with each of those participants. Therefore the natural CDL construct to support this would be a workunit repeating 'n' times over a set of activities (probably a perform of an enclosed choreography).

    The problem with this is that each of the 'n' sub-choreography instances (I use the word loosely) would be performed sequentially, which is not necessarily a true reflection on how these communications would occur.

    Therefore, I thought that possibly the best (and easiest) change to support this would be to enable a 'perform' activity to be asynchronous. This would enable the repetition to essentially trigger multiple instances of the same sub-choreography concurrently, which could still be terminated using the 'complete' expression. Not sure if we would also need some other join concept, but the 'complete' mechanism would probably be sufficient for now.

    From a language perspective, I think this would only require the addition of an optionally 'asynchronous' boolean attribute on the perform activity, which would default to false.

    This way, we would not need to manage a collection of choreography "instances", which I think would require alot more changes to the spec, especially as there is not really the concept of a choreography instance in relation to a perform.

    Let me know what you think, or whether you have any other ideas on how to represent such a choreography.

    Regards
    Gary