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. 

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. 

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. 

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 
> > > 
> > > 
> > 
> > 
> > 
>