Re: Requirements

Roughly speaking some of my use case touches on this because it shows 
exceptions that may be propagated as well, if the use case was 
decomposed could show the state transitions.

Monica

Martin Chapman wrote:

> Can we map these requirements use cases?
>
>     -----Original Message-----
>     *From:* public-ws-chor-request@w3.org
>     [mailto:public-ws-chor-request@w3.org] *On Behalf Of *Burdett, David
>     *Sent:* Thursday, April 10, 2003 3:51 PM
>     *To:* 'jdart@tibco.com'; Cummins Fred A
>     *Cc:* public-ws-chor@w3.org
>     *Subject:* RE: Events and States (was: timeouts & states (was:
>     Abstract Bind able Choreography))
>
>     >>>Very good questions. But what do you want (or perhaps more
>     importantly,
>     need) it to do? As you say, a state machine is really a mechanism.
>     What
>     is the functional requirement?<<<
>
>     I would put the functional requirements for which state machines
>     are a possible answer as follows:
>
>     "An implementation of a process that is following a choreography
>     MUST be able to verify that the choreography is being followed
>     correctly as specified in the choreography definition."
>
>     I would then have two further more closely defined but related
>     requirements of the products of this group ...
>
>     "A choreography definition should be usable at Design Time to
>     validate that a process should be capable of carrying out a
>     choreography correctly as specified."
>
>     "A choreography definition shoule be usable at Run Time to
>     validate that a process is executing a choreography correctly as
>     specified".
>
>     ... and finally one more ...
>
>     "If a process detects that a choreography is not being followed
>     correctly, then the process SHOULD be able to use the choreography
>     definition to identify exactly what went wrong."
>
>     This last one means that you stand a better chance of being able
>     to fix the problem when it occurs.
>
>     Thoughts?
>
>     David
>
>
>     -----Original Message-----
>     From: Jon Dart [mailto:jdart@tibco.com]
>     Sent: Thursday, April 10, 2003 2:56 PM
>     To: Cummins Fred A
>     Cc: public-ws-chor@w3.org
>     Subject: Re: Events and States (was: timeouts & states (was: Abstract
>     Bindable Choreography))
>
>
>
>     Cummins, Fred A wrote:
>     > This raises questions about the scope of a choreography.  When does
>     > it end?  When a disconnect occurs?  When a particular business
>     > transaction is completed?  When a relationship is terminated?
>     > Maybe any of the above?
>     >
>     > Do the state machines provide the mechanism for nesting of
>     component
>     > choreographies?
>
>     Very good questions. But what do you want (or perhaps more
>     importantly,
>     need) it to do? As you say, a state machine is really a mechanism.
>     What
>     is the functional requirement?
>
>     At minimum, I would guess it is the ability to transition to a
>     distinct
>     state when a timeout occurs. This state could be the termination
>     of the
>     choreography (implying no more processing will occur). Or it could
>     be an
>     error state (implying there might be some warning given, or some
>     recovery effort made, e.g. a retry - this assumes you are doing
>     this at
>     the application level and not in some lower-level reliable messaging
>     protocol). Certainly I can think of real-world examples where
>     you'd need
>     this functionality. This is something of a simplification of earlier
>     proposals. If we need something more complex, I'd like to see some
>     rationale behind it.
>
>     --Jon
>

Received on Saturday, 12 April 2003 01:11:16 UTC