RE: Definition of Choreography

>Lets model a ordering process.  Buyer send a purchase order to the
>seller 
>("start" state), and the seller may accept it ("accepted" state) or
>reject 
>it ("rejected" state) based on whether the stock has enough units.
>Another 
>seller may be based on whether the buyer has a good credit.  Can you
>show 
>me how do I use your XML language to describe the model without exposing
>how the seller may make his decision ?  In my language, it will be done
>as

Ricky, first I'd need to understand why you wouldn't want to expose
those criteria, since they are crucial to the client's being able to do
business with these particular sellers.  Why would a seller want to
play games with a client, rejecting purchase orders mysteriously?

Also note that you have two sellers here; two sets of business rules
equals two different state machines, no?  The snippet below has the same
problem for me as your earlier one.  If I care enough about the difference
between "acceptedState" and "rejectedState" as a client, then I want to
know what hoops I'm responsible for, and how the process can go off
track even if I satisfy all my prereqs.  There is a level of detail that
I don't need also, but I don't think you've gotten there yet.


><choreography>
>     <state name="startState">
>         <transition>
>             <event name="receiveOrder" nextState="acceptedState 
>rejectedState"/>
>         </transition>
>     </state>
>     </state name="acceptedState"/>
>     <state name="rejectedState"/>
></state>


>In your model representation, it is NOT possible to describe the
>situation 
>that one event occurance can lead to multiple possible next states
>without 
>using the guard conditions.  And using guard condition has two risks.

No, that's not true.  It's only true if you need your model to be
deterministic.  That said, I think simple models for purchasing things
ought to be deterministic, for the sake of client sanity.  The guard
condition is there to discriminate, but you can leave it off.  But the
complete language of the model has to include guards.

>1) It force the implementor to publicize its decision making criteria.
>(we 
>may disagree on whether guard condition is private or public, but your 
>answer to my above example will make it clear)

Well, I didn't answer your example above, because it failed one of my
pre-conditions. ;-)

>2) There is no way to enforce guard conditions to be mutually 
>exclusive.  (what is the next state if two different guard conditions 
>leading to them are both true ?)

As I mentioned above, if you are modeling a deterministic process, then
the right combination of events and guards will provide the level of
discrimination you're after.  Were you forgetting about events?


>>If I'm in state1 (balanced on a rock amid a rushing torrent) and I want
>>to get to state 3 (safe on the opposite bank) and avoid state 2
(drowned),
>>how would I use your model safely?

>Very easy, you just don't specify state2 in the attribute "nextState" of
>eventX.

><state name="state1">
>     <transition>
>         <event name="eventX" nextState="state3"/>
>     </transition>
>     <transition> .... </transition>
></state>

Er, that wouldn't be nice.  Ricky, I've been going on the assumption
that our models were going to tell the truth.  I don't believe you can
model risk away like that. ;-)

Walden

Received on Sunday, 20 October 2002 21:52:22 UTC