RE: simultaneous execution

Fred

See comments inline.

David

-----Original Message-----
From: Cummins, Fred A [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>

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

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>

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