WS-Choreography Requirements Tracking     Requirements Worksheet                  
                                   
Last Modified: 07/17/03[1]                                
By: SRT[2]                                
Ref ID (number)[3] Req ID (text)[4] SRC URL (text)[5] Category (G|B|T)[6] Entered By (text) Date Entered (mm/dd/yyyy)[7] Included in doc? (y|n) Requirement (text)[8] Associated Requirements (text)[9] Notes (text) RFC 2119 Designation (MUST, SHOULD, MAY, etc)[10] Associated Issues (text)[11] Unused (text)          
0 D-CR-1 N/A 4.1.1 DBA x n All specified choreography descriptions MUST be compatible with WSDL 1.2.[12] 13,19,39,67 This is a
very basic requirement for all of our work according to the charter.
MUST
1 D-CR-2 2003Apr/0224.html 4.1.2 SRT x A Choreography MUST be independent of message formats 57, MUST
2 D-CR-3 2003Apr/0224.html 4.1.5 SRT x A Choreography MAY have run time changes: 32,42,45 MAY
a. the actual participants can vary
b. the actual choreography can vary [ed: I think we ruled this out
but have listed it for completeness]
3 D-CR-4 2003Apr/0224.html 4.1.5 SRT x It MUST be possible to query the state of a Choreography MUST
4 D-CR-5 2003Apr/0224.html 4.1.6 SRT x Error/fault handling and compensation features MUST to be able to be expressed in the language. 12,17,20,21,22,23,41,44,49,53,54,58,61 MUST
5 D-CR-6 2003Apr/0224.html 4.1.11 SRT x Choreographies MUST be composable (into a hierarchy) 36,37,47,51,59,60 Choreographies MUST be composable MUST
6 D-CR-7 2003Apr/0226.html 4.1.7 SRT x A choreography SHOULD express the types of messages a participant may send, and the types of messages/responses the participant should anticipate receiving from the other participant(s) (including time-outs) based on the apparent state of the exchange. SHOULD
7 D-CR-8 2003Apr/0130.html 4.1.12 SRT x 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.
8,9,10,40 Generic validation runtime or static MUST
8 D-CR-8-1 2003Apr/0130.html 4.1.12 SRT x 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.
7,9,10,40 static validation SHOULD
9 D-CR-8-2 2003Apr/0130.html 4.1.12 SRT x A choreography definition MUST be usable at Run Time to validate that a process is executing a choreography correctly as specified.
7,8,10,40 runtime validation MUST
10 D-CR-8-2-1 2003Apr/0130.html 4.1.12 SRT x 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.
7,8,9,40 SHOULD
11 D-CR-9 2003Apr/0129.html 4.1.12 SRT x MUST provide the ability to transition to a distinct state when a timeout occurs. MUST
12 D-CR-5-1 2003Apr/0129.html 4.1.6 SRT x MUST provide ability to transition to a distinct state when an exception occurs. 4,17,20,21,22,23,41,44,49,53,54,58,61 MUST
13 D-CR-1 NA 4.1.1 x Need to provide a binding to WSDL 1.2 0, MUST
14 D-CR-10 ? 4.1.11 x Need to MAY provide an extensible binding mechanism such that choreographies could be bound to other technologies.
Maybe linked to other comps MAY
15 ? Need to provide a level of abstraction for the document formats. Not sure what this about
16 D-CR-11-1 2003Mar/0039.html 4.1.7, 4.1.11 SRT x We need to specify the 'construct' for sending a single message .
18, MUST providea constuct that describes the sending of a single message MUST
17 D-CR-5-2 2003Mar/0039.html 4.1.7, 4.1.14 SRT x MUST support some standard ontology of messages, such as a business messages, generic error reporting messages and acknowledgement messages
4,12,20,21,22,23,41,44,49,53,54,58,61 MUST
18 D-CR-11 ? 4.1.7, 4.1.11 x SHOULD describe exchanges of information that change the state of the process. 16, SHOULD
19 D-CR-1 2003Mar/0040.html 4.1.1 SRT x WS-Chor be defined in terms of WSDL operations using the standard MEPs.
0, Not sure that MEP's are strictly relevant, but then what do I know. MUST
20 D-CR-5-2 2003Mar/0086.html 4.1.6, 4,1,14 SRT x Supporting the following errors/exceptions: 4,12,17,21,22,23,41,44,49,53,54,58,61 Valid starting point but needs further work to validate the ontology is correct
1) Transmission error. - The message was never sent. This is a send side error, the rest below are receive side.
2) Delivery Failure - The message was sent but was (probably) not received - this is the WS-RM domain.
3) Message format error - the components of the message were not validly constructed. If this is really bad, you might not be able to work out who
sent the message and therefore can't send an error back.
4) Message Content structure error. These are errors where one of the parts of the message is not valid.
21 D-CR-5-1 2003Mar/0116.html 4.1.6, 4.1.11 x MUST support for defining behavior of the system, when valid error/exception messages arrive for choreography instances after their completion (or before their initiation). 4,12,17,20,22,23,41,44,49,53,54,58,61 MUST
22 D-CR-5-3 x SHOULD support for unsolicited business exceptions whereby a given service component could send this type of message at any point of the collaboration rather than just as part of a response to a request.
4,12,17,20,21,23,41,44,49,53,54,58,61 SHOULD
23 D-CR-5-1 x Exception types must be limited to the ones that will be used in the choreography definition to specify alternate paths.
4,12,17,20,21,22,41,44,49,53,54,58,61 Not so sure of this one because we could not then be open to exceptions from other choreographies (see XXX)
24 D-CR-12 2003Jul/0050.html 4.1.2, 4.1.14 x A choreography MUST be uniquely named 38, Check on 38 MUST
25 D-CR-6-4 2003Jul/0050.html 4.1.11 x MUST be able to describe a behaviour in terms of their interaction. Their interaction is defined as the sending of a communication on a named channel. MUST
26 D-CR-6-5 2003Jul/0050.html 4.1.11 x MUST be able to describe a behaviour recursively. MUST
27 D-CR-6-6 2003Jul/0050.html 4.1.11 x MUST be able to describe a behaviour that has choice to enable different behaviours to be references. MUST
28 D-CR-6-7 2003Jul/0050.html 4.1.11, 4.1.7 x MUST be able to describe a sequence of communications. Do I really just mean communication MUST
29 D-CR-6-8 2003Jul/0050.html 4.1.11 x MUST be able to describe parallel composition of services. MUST
30 D-CR-13-1 2003Apr/0012.html 4.1.5 x MUST support for a specific observer role 64, Related to runtime validation MUST
31 D-CR-13 GregR ? 4.1.5 x MUSt be able to observe a choreography as it is played out 30, MUST
32 DC-CR-3-1 ? 4.1.11 x MUST be able to dynamically add sub choreographies to a "running" choreography. 2,42,45 MUST
33 D-CR-14 2003May/0132.html 4.1.13 x Non-Executable to make it easier to understand - sounds like a soln rather than a req? Need to reword: Ease of use, minimalist approach so we don't introduce unecessary stuff - I hesitate to put MUST but was tempted SHOULD
34 D-CR-15 2003May/0132.html 4.1.13, 4.1.14 x MUST provide the ability to have prose to enable behaviour to be explained - is this comments? Need to reword MUST
35 D-CR-16 2003May/0132.html 4.1.11, 4.1.14 x MUST provide a Multi-Party Global Model for presenting the interaction from the point of view of all the parties and not from the point of view of just one party 48,55 MUST
36 D-CR-6-1 2003May/0132.html 4.1.11 x MUST enable segmentation to hide those bits of a choreography that you want to hide - sounds like a scoping operator applied to roles possibly? 5,37,47,51,59,60 MUST
37 D-CR-6-2 2003May/0132.html 4.1.11 x Choreographies SHOULD be able to call other choreographies (hierarchical) 5,36,47,51,59,60 SHOULD
38 2003May/0132.html 4.1.2, 4.1.14 x Annotated - Is this unique naming of chors 24, Check on 24
39 D-CR-1 2003May/0132.html 4.1.1 x WSDL1.2 based 0, MUST
40 D-CR-8-2 2003May/0132.html 4.1.12 x MUST provide run time validation of choreographies to ensure compliance with the interaction described 7,8,9,10 MUST
41 D-CR-5 2003Jun/0057.html 4.1.6 x MUST support exceptions 4,12,17,20,21,22,23,44,49,53,54,58,61 MUST
42 D-CR-3-2 2003Jun/0097.html 4.1.11 x MUST be able to dynamically determine participants at runtime. There's an implied requirement that the NUMBER of participants may vary. Nothing said about the interface with these participants varying. 2, 32, 45 MUST
43 4.1.11 x MUST be able to model message flows that repeat based on information within the messages (for instance, the contract negociation protocol).
Maybe out of scope. See Mchampions email on subject
44 D-CR-5-1 4.1.6, 4.1.10, 4.1.11 x MUST be able to model different states for termination of the choreography (e.g. failure and success). 4,12,17,20,21,22,23,41,49,53,54,58,61 MUST
45 D-CR-3-2-1 2003Jun/0184.html x There SHOULD be a distinction between a "participant" and a "role", where the participants might be dynamic but the roles need not be. 2, 32, 42 SHOULD
46 D-CR-13-3 4.1.11 May need a way to describe a callback -- where I give you info about a service that you then use to call me back. Is this related to observing and querying since a chor doesn't send messages it just observes (or acts as a proxy)
47 D-CR-6-2 4.1.11 x MUST to be able to describe a choreography at multiple levels of detail by including sub-choreographies in some "collapsed" form in a higher-level model (hierarchical composition). 5,36,37,51,59,60 MUST
48 D-CR-16-1 4.1.14 x MUST be able to create "limited global views", where not all interactions are presented. 35,55 MUST
49 D-CR-5-4 4.1.6 x MUST be able to distinguish error and regular transitions, and to describe what happens to errors that aren't specifically "dealt with". 4,12,17,20,21,22,23,41,44,53,54,58,61 MUST
50 D-CR-17 2003Jun/0060.html 4.1.14 x SHOULD enable a choreography agreement or an agreement(s) that provides the business context of the choreography definition. 52 SHOULD
51 D-CR-6-2 4.1.11 x Nested processes or choreography sets: Dependencies may exist between or within processes (Whether they are substantive or not should be discussed). 5,36,37,47,59,60 Not sure what to do with this one
52 D-CR-17-1 4.1.14 x Sequence/order is affected by the agreement or references in the choreography definition. Optional paths may be taken that affect dependencies and outcomes. From a business perspective, selecting one or the other could have different agreement implications if an error occurs. The outcome of a given order or the assumptions about the outcome of the given order is based on the business context and agreement(s). 50 Rewrite - too wordy SHOULD
53 D-CR-5-5 4.1.6 x MUST be able to pass/manage exceptions between choreographies, and to include that information in dependency management. 4,12,17,20,21,22,23,41,44,49,54,58,61 MUST
54 D-CR-5-2 4.1.6 x MUST be able to differentiate errors (unknown and fatal) and exceptions (known and potentially recoverable) in the context of choreography. 4,12,17,20,21,22,23,41,44,49,53,58,61 MUST
55 D-CR-16-2 2003Mar/0216.html 4.1.11, 4.1.14 x MUST be able to define multi-party interaction 35,48 Is this a sub on global model MUST
56 D-CR-6-9 4.1.11 x MUST be able to model events that are strictly related in time, as well as those that are unrelated in time -- i.e. parallelism or partial ordering. MUST
57 D-CR-2 4.1.11 x MUST be able to define choreography without having to specify the contents of the messages being used. 1 MUST
58 D-CR-5 2003Apr/0059.html 4.1.6, 4.1.11 x MUST be able to consider errors as part of a choreography, in order to design handling for business-level errors. 4,12,17,20,21,22,23,41,44,49,53,54,61 MUST
59 D-CR-6 2003Apr/0017.html 4.1.11 x It MUST be possible to describe choreographies as a composition of other choreographies (example: an Order Management chor, defined in terms of Order Placement, Order Change, Order Cancellation, etc.) 5,36,37,47,51,60 MUST
60 D-CR-6-3 4.1.11 x You MUST be able to define a new chor by "extending" an existing one (example: define "place order w/ multiple response" as an extension of "place order w/ single response"). 5,36,37,47,51,59 Related to hierarchical comp MUST
61 D-CR-18 2003Apr/0015.html 4.1.6, 4.1.10 x We should define a standardized way to recover from catastrophic failure, such as the use of a standard "request for outstanding activity" chor to be executed by the failed participant. [ed: this is related to but different than exception handling] 4,12,17,20,21,22,3,41,44,49,53,54,58 Assigned indep to exception D-CR-5 - don't know what to do with this one either.
62 D-CR-19 2003Apr/0005.html 4.1.11 x You MUST be able to make a choreography C2 dependent on another choreography C1 such that you can only create a new instance of C2 after a related instance of C1 has been completed. (Example: you can only do Order Change after Order Placement has completed.) Conditional sub choreography, conditional only on oberved behaviour of another choreography MUST
63 2003Mar/0273.html 4.1.11 x A choreography should express the composition of existing web services into a new web services, including input/output mappings, invocation ordering, and binding information. Probably out of scope - thus a MUST NOT
64 D-CR-13-2 2003Mar/0266.html 4.1.11, 4.1.5 x We should have the ability to monitor a "referral" relationship, where one participant is able to connect two other participants and "keep an eye on" the state of their communication. [ed: I believe we decided at the June F2F that a formal representation of this as some kind of choreography "primitive" was out-of-scope, but it's included for completeness.] 30, Not sure how to designate this one.
65 4.1.11 x We should have the ability to describe negociation, where the result of a transaction may depend on repeated iterations of an ask/answer cycle. [ed: I believe we decided at the June F2F that a formal representation of this as some kind of choreography "primitive" was out-of-scope, but it's included for completeness.] Should be able to describe it in terms of obervable behaviour without the need to count
66 D-CR-20 2003Mar/0220.html 4.1.5 SRT x It MUST be possible and practicable to store instances of use of the WS-Chor language in a Registry / Repository, to be a able to search for such instances and to retrieve them. MUST
67 D-CR-1-1 2003Mar/0043.html 4.1.1 SRT x it is preferrable not to be restricted to WSDL 0, Read as: It MAY be possible to bind to non-WSDL services MAY

[1]
Administrator:
Please update this when you modify the spreasheet. Also, turn change tracking on.

[2]
Administrator:
Use your initials here
[3]
Administrator:
This should be the sequential number used to identify this item in the database - not necessarily the number in the reqs document

[4]
Administrator:
This should be the ID from the document

[5]
Administrator:
This URL should point to the original email of submission or the issue in the Mozilla dataase or possibly the associated UC - may leave blank
[6]
Administrator:

New classification:

4.1.1 Charter
4.1.2 Interoperability
4.1.3 Scalability
4.1.4 Security
4.1.5 Mgmt and Prov
4.1.6 Exception Hdling
4.1.7 Msging and Protoc
4.1.8 Interfaces
4.1.9 Reliability
4.1.10 Transaction
4.1.11 Composition
4.1.12 Test/Verify/Validate/Debug

Sari Shein:
4.1.13 Ease of use
4.1.14 Support for semantics
Sari Shein:
[7]
Administrator:
This is for our own tracking purposes

[8]
Administrator:
This column should contain the text of the requirement, including the RFC 2119 designation.
[9]
Administrator:
Reqs Ids here for xref purposes
[10]
Administrator:
Please add this so we can sort by this field.
[11]
Administrator:
This is for tracking issues concerning this requirement from the issues list. Possibly a mozilla tracking number.
Sari Shein:
[12]
Daniel Austin:
The form of a requirement is: noun [MUST|MAY|SHALL (NOT)] do something
Sari Shein: