Re: simultaneous execution

I'm not sure actually there was agreement.

My take was that it was necessary for implementations to support 
simultaneous execution. The assertion was made that this requires 
conveyance of instance identity. I think this is actually true, but I 
considered the mechanism for it out of scope for this WG. Others, 
however, do seem to think it is in scope.

--Jon

Cummins, Fred A wrote:
> I believe this thread has reached a 
> conclusion I don't agree with as a result
> of some implicit assumptions:
> 
> 1) that a choreography has instances.
> 
> 2) that a choreography must express 
> how a message type is determined.
> 
> 3) that the choreography must define 
> how one conversation/transaction is 
> distinguished from another when there are
> two or more conversations involving the
> same participants, roles and choreography.
> 
> A choreography does not have instances
> since it is not executed, it is observed
> (i.e., complied with), just as a law does
> not have instances, only instances of 
> people complying or breaking the law.
> 
> A choreography defines what message types
> are acceptable, but the participants define
> what the message types are.  When a message
> is received, the choreography defines what
> the recipient should expect (one or more
> possibilities).  When a message is sent,
> the choreography will define what messages
> may be sent based on what the sender 
> determined it last received and its own
> internal business logic to determine the next
> step. The choreography does not determine which
> type is actually sent.  Consequently, the
> type of a message is what the sender or
> receiver says it is.  This is
> the basis for the sender to decide what
> to expect in return according to the
> choreography and for the receiver to
> determine what it may send in order to
> comply with the choreography.
> 
> Neither does the choreography determine
> which messages are elements of the same
> exchange.  The participants determine this
> possibly with the assistance of the transport 
> protocol (e.g., session id).  A choreography 
> could specify that at some point, an exchange
> could branch into multiple conversations/
> transactions.  It does not, however, need
> to determine which is which, the choreography
> only defines the rules with which each must
> comply.  Possibly, the choreography could also 
> specify that these (or some of these) should
> or may join before some other action is allowed 
> to occur.  The choreography should not specify
> which instance, only that instances complying
> with certain choreography may or should join.
> 
> I want to see the choreography as light-weight
> as possible so that it can be used independent
> of the the message format employed by participants
> or the technology employed, either the internal 
> technology (e.g., the business process language)
> or the communication protocol (e.g., web 
> services or message broker).
> 
> Fred
> 
> 
>>-----Original Message-----
>>From: Mark Little [mailto:mark.little@arjuna.com]
>>Sent: Monday, August 04, 2003 4:55 AM
>>To: Assaf Arkin; Burdett, David
>>Cc: jdart@tibco.com; public-ws-chor@w3.org
>>Subject: Re: simultaneous execution
>>
>>
>>
>>+1. And if you look at the recent WS-CAF specifications 
>>you'll see that
>>there is a separate context service definition precisely 
>>because of this.
>>
>>Mark.
>>
>>----- Original Message -----
>>From: "Assaf Arkin" <arkin@intalio.com>
>>To: "Burdett, David" <david.burdett@commerceone.com>
>>Cc: <jdart@tibco.com>; <public-ws-chor@w3.org>
>>Sent: Thursday, July 31, 2003 10:58 PM
>>Subject: Re: simultaneous execution
>>
>>
>>
>>>I'll have to side with Jon on this. Correlation is a generic and
>>>flexible mechanism that can also be used for that. A more specific
>>>mechanism would be too narrow in scope and would impose some
>>>limitations. Since we're dealing with WS in general, and not
>>>specifically PO scenarios, let's have the more generic mechanisms.
>>>
>>>arkin
>>>
>>>Burdett, David wrote:
>>>
>>>
>>>>If all you have is a request response over the same 
>>
>>channel, then I agree
>>it
>>
>>>>is not necessary unless that request response is part of a 
>>
>>larger and
>>longer
>>
>>>>interaction.
>>>>
>>>>But if you do need to do this, it is hardly rocket science 
>>
>>and has also
>>been
>>
>>>>done in other specs such as ebXML messaging.
>>>>
>>>>What we really want to do is have one *definitive* way of 
>>
>>providing this
>>
>>>>functionality. Now identifying which choreography you are 
>>
>>following is
>>
>>>>definitely, IMO, part of our scope. However identifying 
>>
>>that a set of
>>
>>>>messages are related is broader as you could have some sort of
>>
>>"correlation
>>
>>>>identifier" without specifing the choreography which being 
>>
>>followed.
>>
>>>>David
>>>>
>>>>
>>>
>>>
>>>
> 
> 
>

Received on Tuesday, 5 August 2003 16:43:40 UTC