W3C home > Mailing lists > Public > www-ws-arch@w3.org > October 2002

RE: Definition of Choreography

From: Ricky Ho <riho@cisco.com>
Date: Mon, 21 Oct 2002 09:42:24 -0700
Message-Id: <>
To: jzhu@silkvalleytech.com, www-ws-arch@w3.org

>My questions relating to using finite state machines to model choregraphies:
>1) A simple question for clarification: by allowing the state machine to
>    transition to two states (state2 and state2, presumably in parallel)
>    upon the same input, you are suggesting an NFA model (as opposed to a
>    correct?

After thinking deeper, I think we can further constraint that a transition 
caused by an event can only lead to ONE next state.

>2) Based on the dicussion of not wanting to expose internal business logic
>    a choreography, I am safe to assume that the choreography defined by
>    the finite state machine is meant to be a public process.  My question is
>    on the boundary between a public process and a private process, is it
>    boundary) always clear cut... assuming that the private process is also
>    as a finite state machine, are there cases where the states of a public
>    process and the states of an internal process are intertwined, i.e.,
>    to transition from a public process state to a private process state and
>    vice versa?

I think they are pretty clear cut.  A public protocol defines what message 
exchanges is legitimate and lay out all possibilities.  The private process 
doesn't have to be represented by a state machine.  If it happens to be, 
then the event happening at the public process can trigger an event in the 
private process, which do the processing and generate another event, which 
create a public event.  This coupling is very loose.

>4) Shouldn't message formats (those of payload, not the headers or evelops)
>be included
>    in a choreography definition?  Aren't they equally important (if not
>more) as the
>    sequencing of messages?

I think choreography should reference WSDL, where message format is defined.

Best regards,
Received on Monday, 21 October 2002 12:43:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:05:42 UTC