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

RE: Definition of Choreography

From: Jianhua Zhu <jzhu@silkvalleytech.com>
Date: Sun, 20 Oct 2002 13:32:25 -0700
To: www-ws-arch@w3.org
Message-id: <KEELLHDILJCDGPIFLJMJAEEFCAAA.jzhu@silkvalleytech.com>


Interesting thread...

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

Other questions:

3) In this discussion thread, some are for, and some against, having a
formal
   description of choregraphies (public processes), and they being separate
from
   private processes.  This question is for the "for"s, isn't the BPSS of
ebXML
   precisely for the purpose of defining public processes?  If that is not
sufficient
   for the purpose of choregraphy, what are missing? why?
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?



>Following is an example I try to put up.  My "event" is probably same as
>your "trigger", and I further constraint the event can only be a web
>ervice message exchange.

>I don't think "exception" need to be defined different in the
>model.  Basically, you only need to define some "state" to for exception
>situation, the event that reach those states are SOAP faults.  The same
>model can be used to represent the exception situation and its handling
>already.

>Comments are very welcome !

><choreography startState="state1">
>     <roleDefinition>
>         <role name="roleA">
>             <portType name="PT-A"/>
>         </role>
>          <role name="roleB">
>             <portType name="PT-B"/>
>         </role>
>         <role>....</role>
>    </roleDefinition>
>     <state name="state1">
>         <transition>
>             <event name="eventX" nextState="state2 state3">
>                 <invoke>
>                     <sender role="roleA"/>
>                     <receiver role="roleB">
>                         <portType name="PT-B">
>                             <operation name="opM"/>
>                         </portType>
>                     <receiver>
>                 </invoke>
>             </event>
>         </transition>
>         <transition> .... </transition>
>     </state>
>     <state>...</state>
></choreography>

>Best regards,
>Ricky
Received on Sunday, 20 October 2002 16:36:35 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:09 GMT