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.

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:21:12 UTC