RE: Definition of Choreography

I don't think this issue is brought by choreography.  The same argument 
applies to why WSDL need to define the concrete XML message format.

I'm not sure if WSDL can allow the message of a parameter to be substituted 
by another message which inherits the type definition of the original 
message.  If so, then your concern is solved.  If not, maybe we should look 
at the issue from a WSDL perspective.

Rgds, Ricky

At 11:33 AM 10/21/2002 -0700, Burdett, David wrote:
>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:56:03 UTC