W3C home > Mailing lists > Public > public-ws-chor@w3.org > April 2003

RE: Requirements

From: Burdett, David <david.burdett@commerceone.com>
Date: Fri, 11 Apr 2003 12:16:25 -0700
Message-ID: <C1E0143CD365A445A4417083BF6F42CC053D197E@C1plenaexm07.commerceone.com>
To: "'Martin Chapman'" <martin.chapman@oracle.com>, public-ws-chor@w3.org
I think all these requriements can map to the three-party/role choreography
we discussed on the last conference call. All you need to do (I think) is
the following:
1. Assume that a three party/role Choreography Definition instance, that
conforms to the choreography described in the Use Case, has been created
using the Choreography definition language that is the result of this
Activity.
2. One (any) of the roles in the Use Case want to implement a process that
conforms to the choreography definition.
3. As part of a role's implementation of that process, the role wants to
meet *all* the requirements identified below.
 
Does this answer your question?

David

-----Original Message-----
From: Martin Chapman [mailto:martin.chapman@oracle.com]
Sent: Friday, April 11, 2003 11:53 AM
To: public-ws-chor@w3.org
Subject: Requirements


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 <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 Friday, 11 April 2003 15:16:26 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:00:58 UTC