RE: Multiple participants

Sorry to expose my ignorance, but before going deeper into the
concurrent case how does one deal with just the sequential case of
multiple participants. In answer to my quick question, Martin said one
has an array of participants (presumably with matching arrays of
relationship, etc). I haven't seen any examples of this and would like
to. Presumably there are syntactic constructs for what in other language
might appear as supplier[i].purchaseOrderState. Is this just nightmarish
(and dynamic ?) XPointer ? I can find nothing in the existing draft that
hints at how to work this.
 
 
 
By the way, on a quite different syntactic note, how does one enter
things like globalizedTriggers, with their three-level nesting of
quotations ?  One of the examples from discussion has:
 
guard="cdl:globalizedTrigger("cdl:getVariable(PO-State, "B") ==
Canceling", "B","cdl:getVariable(PO-State, "S") == Canceling", "S")"
 
which chokes anything that tries to parse it. xmlspy will take it if you
convert all the inner " to ", but I suspect that might give one's
XPath interpreter a hard time as it tried to sort out the the first "B"
and first "S" shouldn't be converted until the second pass. 
 
Does it have to be represented as
guard="cdl:globalizedTrigger("cdl:getVariable(PO-State,
"B") == Canceling"
"B","cdl:getVariable(PO-State, "S") ==
Canceling", "S")"
 
which kind of obscures things. Even the old style: just doubling quotes
would give us
guard="cdl:globalizedTrigger(""cdl:getVariable(PO-State, """"B"""") ==
Canceling"", ""B"",""cdl:getVariable(PO-State, """"S"""") ==
Canceling"", ""S"")".  or
 
 
Peter

-----Original Message-----
From: Gary Brown [mailto:gary@enigmatec.net] 
Sent: 09 November 2004 20:08
To: public-ws-chor@w3.org
Subject: 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 <mailto:gary@enigmatec.net>  
To: Martin Chapman <mailto:martin.chapman@oracle.com>  ;
steve@enigmatec.net 
Cc: Nickolas Kavantzas <mailto:nickolas.kavantzas@oracle.com>  
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 <mailto:gary@enigmatec.net>  
To: Nickolas Kavantzas <mailto:nickolas.kavantzas@oracle.com>  
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 <mailto:nickolas.kavantzas@oracle.com>  
To: Gary Brown <mailto:gary@enigmatec.net>  
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  <mailto:gary@enigmatec.net> Brown 
To: Nickolas Kavantzas <mailto:nickolas.kavantzas@oracle.com>  
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

Choreology Anti virus scan completed