Re: simultaneous execution

I like the term FOLLOWED. I don't like the term EXECUTED. I also like 
the term PERFORMED but that is because it fits with the notion of 
choreography. Choroegraphies in dance are performed but perhaps in 
business FOLLOWED is better.

Cheers

Steve

On Wednesday, August 6, 2003, at 11:23  pm, Burdett, David wrote:

> Fred
>
> One minor comment in line.
>
> David
>
> -----Original Message-----
> From: Cummins, Fred A [mailto:fred.cummins@eds.com]
> Sent: Wednesday, August 06, 2003 2:32 PM
> To: Burdett, David; Mark Little; Assaf Arkin; Burdett, David
> Cc: jdart@tibco.com; public-ws-chor@w3.org
> Subject: RE: simultaneous execution
>
>
> David,
>
> See comments below.
>
> Fred
>
> -----Original Message-----
> From: Burdett, David [mailto:david.burdett@commerceone.com]
> Sent: Tuesday, August 05, 2003 5:13 PM
> To: Cummins, Fred A; Mark Little; Assaf Arkin; Burdett, David
> Cc: jdart@tibco.com; public-ws-chor@w3.org
> Subject: RE: simultaneous execution
>
>
>
> Fred
>
> See comments inline.
>
> David
>
> -----Original Message-----
> From: Cummins, Fred A [ mailto:fred.cummins@eds.com
> <mailto:fred.cummins@eds.com> ]
> Sent: Tuesday, August 05, 2003 1:20 PM
> To: Mark Little; Assaf Arkin; Burdett, David
> Cc: jdart@tibco.com; public-ws-chor@w3.org
> Subject: RE: simultaneous execution
>
>
> 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.
> <DB>I think of a choreography *definition* as a design of *what* you 
> can do
> just as an architect can provide a design for a building. However the 
> same
> design can be followed multiple times resulting in, for the architect,
> multiple building. Identifying each of the buildings that was built is
> obviously useful for example in case there was a probelm with the 
> design
> that needed to be fixed. For exactly the same reason, it is useful to
> identify each time a choreography definition is followed. Now whether 
> the
> term used to describe a choreography being followed should be "used",
> "followed", "complied with", "executed" or something else really 
> requires
> that the semantics of these words in the context of choreographies is
> properly defined. I don't think that "executed" is a good term to uses 
> for
> the same reasons as you as it sounds like a program execution which it
> isn't. I have a marginal preference for "followed" what do others
> think.</DB>
> [FAC] Followed seems appropriate.  The issue is that it is realized by 
> the
> participants, not by something that executes/performs it (the 
> choreography).
> Since it does not perform any actions, per se, it does not make any
> decisions nor operate on any variables.  It only defines what the
> participants can do.
> [Burdett, David] +1
>
> A choreography defines what message types
> are acceptable, but the participants define
> what the message types are.
> <DB>In my WS Choreography spec (aka BurdettML) I introduced the idea of
> specifying choreographies using "message families" where a message 
> family is
> an abstract term for the set of messages that server the same purpose. 
> For
> example an EDI 850, a UBL Order and a RosettaNet Order are all 
> different
> messages but they are all in the "Order" message family.</DB>
> [FAC] I think the choreography must identify the semantic type of the
> messages that are allowed, but these types may be realized in different
> ways, with different formats.  They may, in most cases, be XML, but 
> even
> there, there might be different specifications to achieve the same 
> result.
> In addition, there may be rather generic types, that are specialized 
> for
> particular industries or situations.  This allows the choreography to 
> have
> broad application and avoids unnecessary specialization of the 
> choreography,
> per se.
> [Burdett, David] +1. This variability is something that the Universal
> Business Language (UBL) initiative has identified and, from an XML 
> business
> document perspective, is developing a solution. Meeting this 
> requirement is
> one of the main reasons why I like the idea of "message families".
>
> When a message
> is received, the choreography defines what
> the recipient should expect (one or more
> possibilities).
> <DB>Not sure about this. The choreography should define what a 
> recipient
> should *send* when they receive a message of a particular type.</DB>
> [FAC] When a recipient receives a message of a particular type, it 
> often has
> options on what to return.  In the order example, it may return a 
> rejection
> or a correction or a counter-offer under the right business 
> circumstances.
> The choreograpy only defines the options available by agreement of the
> subscribing parties.  Usually, there is an accept or reject option.
> [Burdett, David] +1
>
> 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.
> <DB>Agreed</DB>
> 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.
> <DB>Does this problem go away if you think of a choreography 
> definition as a
> description of what should be done. Drawing on the architecture 
> analogy.
> What you really need to do is: a) design the building, b) build the
> building, and c) check the building was built according to the design 
> and
> fix the problem if it is not. The same goes for choreographies as you: 
> a)
> Design the choreography, b) build implementations that follow the
> choreography, and c) check the choreography is being followed and fix 
> the
> problems if it is not.</DB>
> [FAC] I think that's fair.
>
> 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.
> <DB>Agreed</DB>
>
> 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.
> <DB>Agreed, specifying the rules to follow is what choreography 
> definitions
> are all about!</DB>
>
> 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.
> <DB>In practice I think that you may *have* to specify that the 
> instances
> are related. For example before paying for goods it might be necessary 
> for
> two choreographies to complete: a) one to check the goods are in 
> stock, and
> b) to know they have left the warehouse. However this only makes sense 
> if
> the goods being order, the goods being checked for in stock and also 
> the
> goods that left the warehous refer to the same goods!/DB>
> [FAC] It may be necessary to reference some symbolic parameter that 
> should
> be the same for the instances to be joined.  I am wary of including 
> any sort
> of logic or reference to values in the messages.  I think these 
> decisions
> probably should be left to the participants and the choreography remain
> abstract.  If nothing else, it retains flexibility in the 
> implementation.
>
> 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).
> <DB> +1 ... and this is *exactly* what I tried to do in the 
> WS-Choreography
> spec. However since this is the WS Choreography group I think we 
> *also* have
> to define how the our Choreography spec binds to web services.</DB>
> [FAC] I don't have any problem with the intent of binding.  I just 
> want to
> do it in a way that allows binding to other technologies as well.  Even
> explicit binding to WSDL might not be too bad if there are explicit 
> mappings
> from WSDL to other technologies.
>
> Fred
>
>> -----Original Message-----
>> From: Mark Little [ mailto:mark.little@arjuna.com
> <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
>>>>
>>>>
>>>
>>>
>>>
>>
>

This email is confidential and may be protected by legal privilege. If you are not the intended recipient,  please do not copy or disclose its content but  delete the email and contact the sender immediately. Whilst we run antivirus software on all internet emails we are not liable for any loss or damage. The recipient is advised to run their own antivirus software.

Received on Thursday, 7 August 2003 04:36:04 UTC