RE: Definition of Choreography

Zhu

You asked ...

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

BPSS is close but is more complex than is needed.

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

Yes, messages are equally important, but I don't think you should be
specific, for example you can do ...
BUYER                              SELLER
Order ----------------------------------->
       <----------------------------------- Order Response

Where Order is an EDI, RosettaNet, xCBL, cXML, etc. etc...

If you have different choreographies for every separate messge format, then
you will get unnecessary duplication.

David

-----Original Message-----
From: Jianhua Zhu [mailto:jzhu@silkvalleytech.com]
Sent: Sunday, October 20, 2002 1:32 PM
To: www-ws-arch@w3.org
Subject: RE: Definition of Choreography




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