WS-Choreo | 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 |