Feedback on the Requirements document (v1.0)

Hi all,

Below please find comments on the Web Services Choreography Requirements document (version 1.0). Unfortunately I am not able to join the f2f meeting.

Kind regards,

Ivana Trickovic
SAP AG, Germany

****************************************************************************************************************************
Feedback on the Web Services Choreography Requirements document, Version 1.0

General issues:
[1]	There are many cases where "choreography language" would be more appropriate term than "choreography". Term "choreography" should be understood as specification/definition of a concrete message exchange between two or more roles. For example, the wording of D-CR-010 should be "A choreography language MAY provide an extensible binding mechanism..." instead of "A choreography MAY provide an extensible mechanism..."

Specific issues:
[1]	D-CR-052: What is meant by "...manage choreographies and their relationships and the message exchange between them"? This requirement is too general. It would be useful to distinguish aspects relevant at design time and at run time.

[2]	D-CR-018: Should the choreography language define a standardized way to recover from catastrophic failure? We should distinguish between a choreography language and standardized choreographies. A choreography language SHOULD provide a means to describe a standardized way to recover from catastrophic failure. But this standardized way (to recover from catastrophic failure) is not part of the language semantics. 

[3]	D-CR-026: What does "robust exception handling" mean? What are features/properties of such an exception handling model?

[4]	D-CR-032: Is there any use case illustrating this requirement? What is meant by "to manage exceptions between choreographies"? How does this differ from "propagation of errors" (D-CR-005) in case when choreographies are hierarchically structured? 

[5]	D-CR-033: Is there any use case illustrating this requirement? How can I assign an error/exception message to a choreography instance that is not instantiated yet? 

[6]	D-CR-064: This requirement does not belong to section "Exception Handling". It could be included in section "Testing and Validation". 

[7]	D-CR-029: Any (standard) taxonomy of messages is out of scope of a choreography language. 

[8]	D-CR-067: What is meant by "... a given service component could be sent at any point in the transaction"?

[9]	D-CR-068: Does it mean that fault codes will be limited to the ones specified by the choreography language?

[10]	D-CR-015: What is meant by "...the ability to have prose associated with it to enable its behavior to be explained"? I strongly believe that no additional prose should be allowed for describing/explaining the behavior. The language specification must include all needed semantics. Annotations, etc. could be part of a modeling tool, but not the choreography language.

[11]	D-CR-044: Is there a use case explaining this requirement?

[12]	Most of the requirements listed in section 4.10 do not belong there. 

[13]	D-CR-059: "Negotiation pattern" is a use case and not a requirement and should be treated as such.

[14]	What is the difference between D-CR-003 and D-CR-024?

[15]	D-CR-036: This requirement should distinguish between synchronous and asynchronous calls. In case of synchronous call choreography calls another choreography and waits until it has completed. In case of asynchronous call choreography calls another choreography and proceeds immediately without waiting for the called choreography to complete.

[16]	For all requirements listed in section 4.11 it would be really useful to provide corresponding use case(s) in order to precisely describe what the requirements are all about. For example, requirement D-CR-042 is talking about "run time changes that allow the behavior of the actual choreography to vary...". One question would be: are all possible normal paths defined as design time?

Received on Tuesday, 16 September 2003 15:10:54 UTC