RE: Definition of Choreography

Ricky

You said ...

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

While often true, I don't think it should always be the case.

It is true when you have a one-off service to which you want to integrate,
in this case the messages need to be defined very precisely as the
choreography is required to support only one instance.

On the other hand, when you want to implement common "public" processes, e.g
to submit an order, then you should generalize the message, by specifying
the general idea of an "order" for examle, instead of the specific message,
e.g. a "RosettaNet Order in a SOAP message". If you don't do this, then you
would have to define separate choreographies for each version of an order
that you could possibly get - of which there are potentially thousands.

Thoughts?

David

-----Original Message-----
From: Ricky Ho [mailto:riho@cisco.com]
Sent: Monday, October 21, 2002 9:42 AM
To: jzhu@silkvalleytech.com; www-ws-arch@w3.org
Subject: RE: Definition of Choreography






>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
>DFA),
>    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
>in
>    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
>(the
>    boundary) always clear cut... assuming that the private process is also
>modeled
>    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.,
>needing
>    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,
Ricky

Received on Monday, 21 October 2002 14:33:18 UTC