W3C home > Mailing lists > Public > public-ws-chor@w3.org > August 2003

Re: simultaneous execution

From: Assaf Arkin <arkin@intalio.com>
Date: Tue, 05 Aug 2003 13:47:01 -0700
Message-ID: <3F3017C5.7020906@intalio.com>
To: "Cummins, Fred A" <fred.cummins@eds.com>
CC: Mark Little <mark.little@arjuna.com>, "Burdett, David" <david.burdett@commerceone.com>, jdart@tibco.com, public-ws-chor@w3.org

A choreography is more like a legal proceeding and a legal proceeding 
does have an instance. You start by filing a case, serve a summons, 
arrange a day to show up and plead your case, etc.

The choreography does not define what is sent or received, only what is 
expected. That lets the sender know what they should send, since the 
receiver would probably ignore anything else. Going back to legal 
proceedings, you can't arrange a day in court unless you provide proof 
that summons has been served. Of course, you can always go to the court 
without one, they'll just turn you down. It's useful to know what the 
proper sequence is so you can follow it.

As for determine, I sort of agree with your statement. But I do think 
the word determine is appropriate. Perhaps a more accurate and verbose 
definition would be "provides the rules by which participants can 
determine", but I think if we understand the role that a choreography 
plays, then we can just as well say "determines".

arkin

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:49:07 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:01:00 UTC