RE: Definition of Choreography

RE: Definition of Choreography> BPSS is close but is more complex than is
needed.

So, a subset of it might be sufficient?

>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

I agree on a grand scale of reuse scheme that it's nice to have a *single*
public process to cover
the conversation pattern for all buyer-seller type of interactions, and that
this *single* public process be
reused by everyone.  From a pragmatic view point, it might be valuable if
message formats are also
available, so that a potential partner may know what kind of
processing/transformation capabilities are
required to correctly interpret and correlate the information, before
getting into a collaborative relationship.

Joshua
  -----Original Message-----
  From: Burdett, David [mailto:david.burdett@commerceone.com]
  Sent: Sunday, October 20, 2002 7:03 PM
  To: jzhu@silkvalleytech.com; www-ws-arch@w3.org
  Subject: 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