index.html 61.8 KB
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html lang="en-US"><head><META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Web Services Choreography Requirements</title><style type="text/css">
code           { font-family: monospace; }

div.constraint,
div.issue,
div.note,
div.notice     { margin-left: 2em; }

ol.enumar      { list-style-type: decimal; }
ol.enumla      { list-style-type: lower-alpha; }
ol.enumlr      { list-style-type: lower-roman; }
ol.enumua      { list-style-type: upper-alpha; }
ol.enumur      { list-style-type: upper-roman; }


div.exampleInner pre { margin-left: 1em;
                       margin-top: 0em; margin-bottom: 0em}
div.exampleOuter {border: 4px double gray;
                  margin: 0em; padding: 0em}
div.exampleInner { background-color: #d5dee3;
                   border-top-width: 4px;
                   border-top-style: double;
                   border-top-color: #d3d3d3;
                   border-bottom-width: 4px;
                   border-bottom-style: double;
                   border-bottom-color: #d3d3d3;
                   padding: 4px; margin: 0em }
div.exampleWrapper { margin: 4px }
div.exampleHeader { font-weight: bold;
                    margin: 4px}
</style><link type="text/css" rel="stylesheet" href="http://www.w3.org/StyleSheets/TR/W3C-WD.css"></head><body><div class="head"><p><a href="http://www.w3.org/"><img width="72" height="48" alt="W3C" src="http://www.w3.org/Icons/w3c_home"></a></p>
<h1><a id="title" name="title"></a>Web Services Choreography Requirements</h1>
<h2><a id="w3c-doctype" name="w3c-doctype"></a>W3C Working Draft 11 March 2004</h2><dl><dt>This version:</dt><dd>
			<a href="http://www.w3.org/TR/2004/WD-ws-chor-reqs-20040311/">http://www.w3.org/TR/2004/WD-ws-chor-reqs-20040311/</a>
		</dd><dt>Latest version:</dt><dd>
			<a href="http://www.w3.org/TR/ws-chor-reqs/">http://www.w3.org/TR/ws-chor-reqs/</a>
		</dd><dt>Previous version:</dt><dd>
			<a href="http://www.w3.org/TR/2003/WD-ws-chor-reqs-20030812/">http://www.w3.org/TR/2003/WD-ws-chor-reqs-20030812/</a>
		</dd><dt>Editors:</dt><dd>Daniel Austin, Sun. <a href="mailto:Daniel.B.Austin@Sun.COM">&lt;Daniel.B.Austin@Sun.COM&gt;</a></dd><dd>Abbie Barbir, Nortel Networks, Inc. <a href="mailto:abbieb@nortelnetworks.com">&lt;abbieb@nortelnetworks.com&gt;</a></dd><dd>Ed Peters, WebMethods, Inc. <a href="mailto:ed.peters@webmethods.com">&lt;ed.peters@webmethods.com&gt;</a></dd><dd>Steve Ross-Talbot, Enigmatec, Inc. <a href="mailto:steve@enigmatec.com">&lt;steve@enigmatec.com&gt;</a></dd></dl><p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a>&nbsp;&copy;&nbsp;2004&nbsp;<a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>&reg;</sup> (<a href="http://www.csail.mit.edu/"><acronym title="Massachusetts Institute of Technology">MIT</acronym></a>, <a href="http://www.ercim.org/"><acronym title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>, <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a>, <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> and <a href="http://www.w3.org/Consortium/Legal/copyright-software">software licensing</a> rules apply.</p></div><hr><div>
<h2><a id="abstract" name="abstract"></a>Abstract</h2><p>As the momentum around Web Services grows, the need for effective mechanisms to co-ordinate the interactions among Web Services and their users becomes more pressing. The Web Services Choreography Working Group has been tasked with the development of such a mechanism in an interoperable way.</p><p>This document describes a set of requirements for Web Services choreography based around a set of representative use cases, as well as general requirements for interaction among Web Services. This document is intended to be consistent with other efforts within the W3C Web Services Activity.</p></div><div>
<h2><a id="status" name="status"></a>Status of this Document</h2><p><em>This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the <a href="http://www.w3.org/TR/">W3C technical reports index</a> at http://www.w3.org/TR/.</em></p><p>This is the second <a href="http://www.w3.org/2004/02/Process-20040205/tr.html#RecsWD">W3C Working Draft</a> of the Web Services Choreography Requirements document. </p><p>It is a <a href="http://www.w3.org/2003/01/wscwg-charter">chartered </a>deliverable of the <a href="http://www.w3.org/2002/ws/chor/">Web Services Choreography Working Group</a>, which is part of the <a href="http://www.w3.org/2002/ws/Activity">Web Services Activity</a>.  Although the Working Group agreed to request publication of this document, this document does not represent consensus within the Working Group about Web Services choreography requirements.</p><p>This document is in a state of perpetual change. Feedback on this document is sought by the Working Group.</p><p>Comments on this document should be sent to <a href="mailto:public-ws-chor-comments@w3.org">public-ws-chor-comments@w3.org</a>

(<a href="http://lists.w3.org/Archives/Public/public-ws-chor-comments/">public archive</a>). It is inappropriate to send discussion emails to this address.</p><p>Discussion of this document takes place on the public <a href="mailto:public-ws-chor@w3.org">public-ws-chor@w3.org</a> mailing list (<a href="http://lists.w3.org/Archives/Public/public-ws-chor/">public archive</a>) per the email communication rules in the <a href="http://www.w3.org/2003/01/wscwg-charter">Web Services Choreography Working Group charter</a>.</p><p>Patent disclosures relevant to this specification may be found on the Working Group's <a href="http://www.w3.org/2002/ws/chor/3/01/17-IPR-statements.html">patent disclosure page</a>.
</p><p>Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.</p></div><div class="toc">
<h2><a id="contents" name="contents"></a>Table of Contents</h2><p class="toc">1 <a href="#mission_statement">Mission Statement</a><br>
2 <a href="#Introduction">Introduction</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;2.1 <a href="#What_is_Web_Services_Choreography">What is Web Services Choreography?</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;2.2 <a href="#How_is_a_Choreography_used">How is a Choreography used?</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;2.3 <a href="#Benefits_of_Choreography_used">Benefits of Choreography Language</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;2.4 <a href="#N10125">Conventions used in this document</a><br>
3 <a href="#Use_Cases">Use Cases</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;3.1 <a href="#Use_Case_Descriptions">Use Case Descriptions</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.1.1 <a href="#UC-001">C-UC-001 -Travel Agent</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.1.1.1 <a href="#N10150">Primary Description</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.1.1.2 <a href="#N1019C">Requirements</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.1.1.3 <a href="#N101B5">Variation on the use case</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.1.1.3.1 <a href="#N101B8">Variation 1</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.1.1.3.2 <a href="#N101C6">Variation 2</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.1.1.3.3 <a href="#N101DB">Variation 3</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.1.1.3.4 <a href="#N101EA">Variation 4</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.1.1.3.5 <a href="#N101FE">Variation 5</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.1.1.3.6 <a href="#N1020C">Variation 6</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.1.2 <a href="#UC-002">C-UC-002 - Quote Request</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.1.2.1 <a href="#N10222">Primary description</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.1.2.2 <a href="#N10255">Requirements</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.1.2.3 <a href="#N10265">Variations on the use case</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.1.2.3.1 <a href="#N10268">Variation 1</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.1.2.3.2 <a href="#N1027F">Variation 2</a><br>
4 <a href="#Critical_Success_Factor_Analysis">Critical Success Factor Analysis</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;4.1 <a href="#CSF_Analysis_Goals">CSF Analysis Goals</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;4.1.1 <a href="#G-001">C-G-001</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;4.1.2 <a href="#G-002">C-G-002</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;4.1.3 <a href="#G-003">C-G-003</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;4.1.4 <a href="#G-004">C-G-004</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;4.1.5 <a href="#G-005">C-G-005</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;4.1.6 <a href="#G-006">C-G-006</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;4.1.7 <a href="#G-007">C-G-007</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;4.1.8 <a href="#G-008">C-G-008</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;4.2 <a href="#Critical_Success_Factors">Critical Success Factors</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;4.2.1 <a href="#CSF-001">C-CSF-001</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;4.2.2 <a href="#CSF-002">C-CSF-002</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;4.2.3 <a href="#CSF-003">C-CSF-003</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;4.2.4 <a href="#CSF-004">C-CSF-004</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;4.2.5 <a href="#CSF-005">C-CSF-005</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;4.2.6 <a href="#CSF-006">C-CSF-006</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;4.2.7 <a href="#CSF-007">C-CSF-007</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;4.2.8 <a href="#CSF-008">C-CSF-008</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;4.2.9 <a href="#CSF-009">C-CSF-009</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;4.2.10 <a href="#CSF-010">C-CSF-010</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;4.2.11 <a href="#CSF-011">C-CSF-011</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;4.2.12 <a href="#CSF-012">C-CSF-012</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;4.2.13 <a href="#CSF-013">C-CSF-013</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;4.2.14 <a href="#CSF-014">C-CSF-014</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;4.2.15 <a href="#CSF-015">C-CSF-015</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;4.2.16 <a href="#CSF-016">C-CSF-016</a><br>
5 <a href="#Choreography_Requirements">Choreography Requirements</a><br>
6 <a href="#Correlation_of_Use_Cases_and_Requirements">Correlation of Use Cases and Requirements</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;6.1 <a href="#N105BE">Use Cases and Requirements Cross-Reference</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;6.2 <a href="#N10769">Requirements and Use Cases Cross-Reference</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;6.3 <a href="#N10889">Requirements Coverage</a><br>
7 <a href="#refs">Appendix A - References</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;7.1 <a href="#N10892">Normative References</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;7.2 <a href="#N10908">Informative References</a><br>
8 <a href="#acks">Appendix B - Acknowledgements</a><br>
</p></div><hr><div class="body"><div class="div1">
<h2><a id="mission_statement" name="mission_statement"></a>1 Mission Statement</h2><p>The mission of the W3C Web Services Choreography Working Group is to define a language based on WSDL 2.0, that can describe a peer-to-peer global model for cross-enterprise interactions and their semantics through the composition of web services that are independent of any specific programming language.				</p></div><div class="div1">
<h2><a id="Introduction" name="Introduction"></a>2 Introduction</h2><p>
The description of interactions among Web Services in particular with regard to the exchange of messages, their composition, and the sequences in which they are transmitted and received - is an important problem. These interactions may take place among groups of services which, in turn, make up a larger, composite service, or which interact across organizational boundaries in order to obtain and process information. The problems of Web Services choreography are largely focused around message exchange and sequencing these messages in time to the appropriate destinations. In order to fulfill the needs of the Web Services community, these aspects of Web Services must be developed and standardized in an interoperable manner, taking into account the needs of each individual service as well as those of its collaborators and users.</p><p>This document describes a set of requirements for Web Services choreography based around a set of representative use cases, as well as general requirements for interaction among Web Services. In order to gather requirements for Web Services Choreography, the working group has currently chosen to follow two paths toward this end. The first means of gathering requirements consists of examination of member-submitted use cases, from which requirements may be inferred. The second methods involves the use of the Critical Success Factor analysis methodology.


			</p><p>This document is intended to be consistent with other efforts within the W3C Web Services Activity. 

</p><div class="div2">
<h3><a id="What_is_Web_Services_Choreography" name="What_is_Web_Services_Choreography"></a>2.1 What is Web Services Choreography?</h3><p>
				Web Services Choreography concerns the observable interactions of services with their users. Any user of a Web Service, automated or otherwise, is a client of that service. These users may, in turn, be other Web Services, applications or human beings.  A specific set of interactions maybe related over time to some form of collaboration grouping that is initiated at some source and runs through a set of  Web Services and their client. We use the term "collaboration group" as a generic term that  may encompass the  concept of a "business transaction",  an "ACID transaction" or a "cohesion". Thus for the purpose of clarity we define a collaboration group among Web Services and their clients as a specific set of observable interactions to which further meaning maybe attached.

				
				</p><p>A choreography description is a multi-party contract that describes from global view point  the external observable behavior across multiple clients (which are generally Web Services but not exclusively so) in which external observable behavior is defined as the presence or absence of messages that are exchanged between a Web Service and it's clients.

				</p><p>A choreography description language (CDL) is the means by which such a technical contract is described. 				</p></div><div class="div2">
<h3><a id="How_is_a_Choreography_used" name="How_is_a_Choreography_used"></a>2.2 How is a Choreography used?</h3><p>The main use of a choreography description is to precisely define the sequence of interactions between a set of cooperating web services in order to promote a common understanding between participants and to make it as easy as possible to: </p><ol class="enumar"><li><p>promote a common understanding between WS participants; 
</p></li><li><p>automatically validate conformance;
</p></li><li><p>ensure interoperability;</p></li><li><p>increase robustness; and to</p></li><li><p>generate code skeletons. </p></li></ol><p>A choreography description may be used to generate the necessary code skeletons that can be said to implement the required external observable behavior for that Web Service. For example, a choreography description that is used to describe the multi-party contract between a travel agent and a number of hotel companies might be used by any potential participant to generate a code skeleton for a web service that can be guaranteed to be interoperable with that particular travel agent. 

					</p><p>A choreography description may also be used to aid the testing of participating Web Services through the generation of test messages that could be sent to participants by means of an appropriate vendor specific tool that reads the choreography description and manages the test interaction according to the choreography description.
					</p><p>A choreography description may also be used to validate the multi-party observable interactions amongst a collection of Web Services. For example, a hotel may load a choreography description into a vendor specific tool which informs them of any breaches of the cherography. 

					</p><p>A choreography description may also be used to show the presence of usefull properties such as lock freedom and leak freedom in the behavioral contract. In this sense a choreography description acts as a model of the behavior across a number of Web Services which in turn can be subject to static analysis to show that if and only if the underlying Web Services behave according to the contract that the interaction between the Web Services will exhibit these properties. 

					</p></div><div class="div2">
<h3><a id="Benefits_of_Choreography_used" name="Benefits_of_Choreography_used"></a>2.3 Benefits of Choreography Language</h3><p>The Web Services Choreography working group believes that all uses of a choreography description necessitate the existence of a standardized language for the description of choreographies. The benefits of such an approach: </p><ol class="enumar"><li><p>will enable more robust Web Services to be constructed;</p></li><li><p>will enable more effective interoperability of Web Services through behavioral multi-party contracts, which are choreography descriptions; 
</p></li><li><p>will reduce the cost of implementing Web Services by ensuring conformance to expected behavior; 
</p></li><li><p>will increase the utility of Web Services as they will be able to be shown to meet contractual behavior.
</p></li></ol></div><div class="div2">
<h3><a id="N10125" name="N10125"></a>2.4 Conventions used in this document</h3><p>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this document are to be interpreted as described in<a href="http://www.ietf.org/rfc/rfc2119.txt"> RFC 2119</a>.</p><p>A few words on the naming convention used here and throughout this document: all use cases and requirements are labeled according to the following convention:</p><p>[D-](C|)(G|CSF|R|UC)mmnn</p><p>[D-] indicates that the item is in a draft state</p><p>(C) indicates Candidate status.</p><p>(G|CSF|R|UC|) is one of Goal, Critical Success Factor, Requirement, Use Case.</p><p>mmnn where, mm indicates the section number and nn is sequence number of the item. </p><p>Please note that due to the changing nature of requirements analysis, numbering of requirements and use cases may not always reflect sequential order.</p></div></div><div class="div1">
<h2><a id="Use_Cases" name="Use_Cases"></a>3 Use Cases</h2><p>It is intended that the use cases presented here are to include the widest possible number of requirements using the fewest possible number of use cases. </p><p>The use cases included here are meant to be representative, meaning that the general concepts are common to many possible use cases across a broad array of organizations. 

 </p><div class="div2">
<h3><a id="Use_Case_Descriptions" name="Use_Case_Descriptions"></a>3.1 Use Case Descriptions</h3><div class="div3">
<h4><a id="UC-001" name="UC-001"></a>3.1.1 C-UC-001 -Travel Agent</h4><div class="div4">
<h5><a id="N10150" name="N10150"></a>3.1.1.1 Primary Description</h5><p>A travel agent wants to offer to customers the ability to book complete packages that may consist of services offered by various providers. The available services may include: air travel, train travel, bus tickets, hotels, car rental, excursions and other services such as insurance.

</p><p>The goal of the consumer is to get the best combination of services and prices suiting their needs. The travel agent tries to maximize customer satisfaction and sell packages. Service providers aim to sell as many products as possible. Credit card companies guarantee and perform payments for purchased products.</p><p>In this scenario, service providers offer Web Services that could be used by the Travel agent to query their offerings and perform various tasks such as reservations. Credit card companies provide services to guarantee payments made by consumers. The client should be able to query, reserve and purchase any available service. The basic steps of the interaction are listed below: 

</p><ol class="enumar"><li><p>The client interacts with the travel agent to request information about various services.</p></li><li><p>Prices and availability matching the client requests are returned  to the client. The client can then perform one of the following actions: </p><ol class="enumla"><li><p>The client can refine their request for information, possibly selecting more services from the provider (Repeat step 2). OR</p></li><li><p>The client may reserve services based on the response, OR </p></li><li><p>The client may quit the interaction with the travel agent.</p></li></ol></li><li><p>When a customer makes a reservation, the travel agent then checks the availability of the requested services with each service provider.</p></li><li><p>Either</p><ol class="enumla"><li><p>All services are available, in which case they are reserved. OR</p></li><li><p>For those services that are not available, the client is informed.</p><ol class="enumlr"><li><p>Either</p><ol class="enumua"><li><p>Given alternative options for those services. OR</p></li><li><p>Client is advised to restart the search by going back to step 1.</p></li></ol></li><li><p>Go back to step 3.</p></li></ol></li></ol></li><li><p>For every relevant reserved service the travel agent takes a deposit for the reservation. A credit card can be used as a form of deposit</p></li><li><p>The client is then issued a reservation number to confirm the transaction.</p></li><li><p>Between the reservation time and the final date for confirmation, the client may modify the reservation. Modifications may include cancellation of some services or the addition of extra services.</p><ol class="enumla"><li><p>Client is expected to fully pay for those relevant services that require full payment prior to final confirmation.</p></li></ol></li></ol><p>The use case is illustrated in the figure below.</p><img src="f1.jpg" alt="Participants and relationships involved in the use case"></div><div class="div4">
<h5><a id="N1019C" name="N1019C"></a>3.1.1.2 Requirements</h5><ol class="enumar"><li><p>Need to facilitate cancellation of orders and exception handling.
</p></li><li><p>	Needs callbacks to be able to express asynchronous interactions such as credit checking in a credit card company or availability from an airline.</p></li><li><p>	Needs hierarchical composition to be able to reuse established choreographies such as that used by a credit card company. </p></li><li><p>	Needs reference passing to enable the car hire company to interact with the credit card company on behalf of the user.

</p></li><li><p>	Need to demarcate transactional boundaries in order to define the collaboration boundaries in order to provide guidance on the underlying infrastructure required to implement the collaboration.</p></li><li><p>Need variable timeouts to model different interactions that have a different
time-to-live. For instance, each carrier may impose a different limitation
on the lifetime of a pending reservation.</p></li><li><p>Need to be able to express concurrent paths in order to check availability of services at multiple service providers.</p></li></ol></div><div class="div4">
<h5><a id="N101B5" name="N101B5"></a>3.1.1.3 Variation on the use case</h5><div class="div5">
<h6><a id="N101B8" name="N101B8"></a>3.1.1.3.1 Variation 1</h6><p>The travel agency might use a choreography definition internally as a documented model for its entire reservation booking process. The choreography definition language would need to present a multi-party global view of the reservation choreography, depicting the communication amongst the travel agent and all its various partners. Further, the definition language would need to support the addition of annotation or comments to the various elements of a choreography, in order to fully describe the behavior of the global choreography. 


							</p><p>Requirements for variation 1</p><ol class="enumar"><li><p>There MUST be a mechanism for adding free form annotation or comments to a choreography description.
</p></li><li><p>A CDL must support the description of a multi-party global model.
</p></li></ol></div><div class="div5">
<h6><a id="N101C6" name="N101C6"></a>3.1.1.3.2 Variation 2</h6><p>The travel agent might assist new service providers to join its "network" by providing them with a choreography description outlining their communication responsibilities. The choreography definition language should support the construction of a global model (see above) and allow choreographies to reference one another, thus providing composition. 

							</p><p>For instance, the travel agent would share a "credit check" choreography with a new credit bureau, and the travel agent's internal global choreography would simply include an instruction to "call credit check" choreography. The global choreography could be composed of calls to many such nested choreographies. This has the added benefit of making the travel agent's global choreography modular and easier to understand. 


							</p><p>
							Optionally, the travel agent could share the entire global choreography with the new credit bureau, withholding nested choreographies that details its interaction with other parties, such as airlines and rental car companies. This takes advantage of hierarchical composition to provide information hiding in contexts where partial information loss is appropriate.

</p><p>Requirements for variation 2</p><ol class="enumar"><li><p>A CDL must facilitate decomposition to enable 
choreography descriptions to reference each other.
</p></li><li><p>Some level of validation of a hierarchically composed choreography
definition should be possible even when some or all nested choreographies
are missing, in order to support information hiding by the use of
hierarchical composition.</p></li><li><p>Choreographies must be uniquely named. </p></li></ol></div><div class="div5">
<h6><a id="N101DB" name="N101DB"></a>3.1.1.3.3 Variation 3</h6><p>In order to protect against out-of-sequence messaging, a choreography participant might use a choreography definition to provide runtime validation of message typing and sequencing.  When messages arrive they are checked for appropriate sequencing and, if the check fails, an exception is issued.

							</p><p>A car rental agency might wish to protect its backend systems from potential corruption by out-of-sequence messages; for instance, a reservation being cancelled before it's ever placed. The corresponding action might be to respond to the offending document with an error message.

							</p><p>This runtime validation and exception generation is the responsibility of each participant; however, the choreography definition language must not preclude the implementation of such a feature.
							</p><p>Requirements for variation 3</p><ol class="enumar"><li><p>Failure to adhere exception MAY be generated by a choreography participant. 

</p></li></ol></div><div class="div5">
<h6><a id="N101EA" name="N101EA"></a>3.1.1.3.4 Variation 4</h6><p>In some cases, there will be system or infrastructure errors. For example, when confirming the travel itinerary, it may happen that one or more of the parties fails and are not immediately re-contactable.  Depending on the urgency and importance of the travel services offered by the crashed parties, some form of  recovery  or correction may be required. In some cases it may be necessary to wait for the crashed parties to become active again, and to replay the messages back to them from some  pre-defined checkpoint. The ability to demarcate such  checkpoints is required in order to support this sort of scenario.

							</p><p>Requirements for variation 4</p><ol class="enumar"><li><p>Needs exception handling to be able to express observable actions to take on receipt of an exception message.
</p></li><li><p>Needs timeouts to be able to express time to live on reservations.
</p></li><li><p>A CDL shall facilitate the demarcation of observable actional behavior in order to define collaboration boundaries and provide guidance to the underlying infrastructure (for example, recovery, replay messages etc.).
</p></li><li><p>Need to be able to model retries and timeouts and the ability to choose different paths based on which timeout expires first. 
</p></li></ol></div><div class="div5">
<h6><a id="N101FE" name="N101FE"></a>3.1.1.3.5 Variation 5</h6><p> 
							When interacting with the various parties, a number of application errors could occur. For example, between being offered services to a certain destination and confirming those services, it is entirely possible that the destination is withdrawn from sale for some travel advisory reason. When the client goes to book such services this should result in a set of error messages, that signify some erroneous state. Depending on how the actual web services are defined, these errors may simply be specific WSDL operations, or may be defined as WSDL faults; which is chosen is a web service design issue. 

								</p><p>Requirements for variation 5</p><ol class="enumar"><li><p>A CDL shall support the description of choreography specific errors.
</p></li><li><p>A CDL shall support the description of WSDL faults.</p></li></ol></div><div class="div5">
<h6><a id="N1020C" name="N1020C"></a>3.1.1.3.6 Variation 6</h6><p>In this variation of the Travel Agent use case most of the main carriers (airlines) have in place a robust messaging infrastructure that delivers high quality robust connections that ensure guaranteed delivery. However the rise of budget airlines means that a new class of carriers have become part of the overall offering from travel agents where the messing infrastructure is no where near as reliable.
							</p><p>Fortunately the same choreography description can be used for both classes of carrier and the only thing that needs to change on both sides of the connection is for the participants to bind to the underlying messaging protocol available. 


							</p><p>Also in this variation each carrier has different correlation keys that are used to match messages that belong to a specific transaction. The choreography that is used across the various carrier types is left unchanged with only the binding to correlation different across them. For each instance of a choreography the choreography description, on instantiation with a participant, bind the appropriate correlation mechanism in to the choreography so that it may be followed. Binding on a per participant basis enables the choreography to use whatever correlation mechanism is required between any two participants. 
							</p><p>Requirements for variation 6</p><ol class="enumar"><li><p>There should be a means to describe the differing QoS as applied to messaging.
</p></li><li><p>There should be a means to describe the differing correlation mechanisms as applied to messaging.
</p></li></ol></div></div></div><div class="div3">
<h4><a id="UC-002" name="UC-002"></a>3.1.2 C-UC-002 - Quote Request</h4><div class="div4">
<h5><a id="N10222" name="N10222"></a>3.1.2.1 Primary description</h5><p>In this use case a buyer interacts with multiple suppliers who in turn interact with multiple manufacturers in order to get a quote for some goods or services. A concrete example might be for a company that wishes to purchase a fleet of cars from automobile suppliers which in turn request quotes for specific bill or material items from their component manufacturers. The basic steps of the interaction are listed below:</p><ol class="enumar"><li><p>A buyer request a quote from a set of suppliers.</p></li><li><p>All suppliers receive the request for quote and send requests 
for bill of material items to their respective manufacturers.</p></li><li><p>The suppliers interact with their manufacturers to build their quotes for the buyer. The eventual quote is then sent back to the buyer.
</p></li><li><p>EITHER</p><ol class="enumla"><li><p>The buyer agrees with one or more of the quotes and places the order or
orders. OR
</p></li><li><p>The buyer responds to one or more of the quotes by modifying the 
quotes and sending them back to the relevant suppliers.
</p></li></ol></li><li><p>EITHER</p><ol class="enumla"><li><p>The suppliers respond to a  modified quote by agreeing to it and 
sending a confirmation message back to the buyer. OR
</p></li><li><p>The supplier responds by modifying the quote and sending it 
back to the buyer and the buyer goes back to step 4. OR
</p></li><li><p>The supplier responds to the buyer rejecting the modified quote. OR
</p></li><li><p>The quotes from the manufacturers need to be renegotiated by the supplier. Go to step 3.
</p></li></ol></li></ol><p>The use case is illustrated in the figure below.</p><img src="f2.jpg" alt="descriptions of the relationships and involved parties in this use case"></div><div class="div4">
<h5><a id="N10255" name="N10255"></a>3.1.2.2 Requirements</h5><ol class="enumar"><li><p>The ability to repeat the same set of interactions is needed. The interactions between supplier and manufacturers need only be defined once and then repeated for each relevant supplier manufacturer pairing. 
</p></li><li><p>Needs participant sets that may be bounded at design time, at runtime, or
not at all. For instance, the set of suppliers may be determined when the
choreography is designed, when the choreography is instantiated, or may be
completely dynamic as the choreography progresses.</p></li><li><p>Needs (observable) transactional boundaries to facilitate recovery in the event of a participant failure.</p></li><li><p>Needs to be able to reference a choreography from within a choreography to support recursive behavior such as a manufacturer placing an order with its supplier.
</p></li></ol></div><div class="div4">
<h5><a id="N10265" name="N10265"></a>3.1.2.3 Variations on the use case</h5><div class="div5">
<h6><a id="N10268" name="N10268"></a>3.1.2.3.1 Variation 1</h6><p>In this variation of the Quote Request use case a new manufacturer wishes to participate in the overall supply chain. They manufacture a component in a new way that makes them very competitive with their rivals and the suppliers certainly wish them to participate.
						</p><p>In order for them to participate they look for tools that can be used in conjunction with the existing CDL descriptions that the suppliers use in order to generate the web services required. In this case they use their preffered IDE with a new W3C CDL plug-in. The tool imports the CDL description and generates the necessary Java code skeletons for the relevant Web Services. This enables the new manufacturer to build the necessary web services to participate in the supply chain at a much lower entry cost that would have been possible otherwise. 


							
							</p><p>Having created the necessary Web Services, the CDL IDE plug-in uses the CDL document to generate test messages that are then played into the newly created Web Services. This further cuts the cost of this work and ensures that the Web Services conform to the contractual definition laid down by the CDL document that is in use by the existing suppliers. 

							</p><p>In some cases the initial document may need to be modified to add a new partner. However, the new document may introduce problems into the design. Using CDL IDE plug-in, the document desgin can be checked for various properties. Thus, the designers may be able to statictaly detect problematic areas such as livelocks, deedlocks and leaks. 
						
							
							
							</p><p>Requirements for variation 1</p><ol class="enumar"><li><p>A CDL description may be used in the generation of code skeletons (for example, may be WS-BPEL, Java, C# or others).
</p></li><li><p>A CDL description may be used in the generation of test messages. 
</p></li><li><p>A CDL tool may need the capability to check for correctness properties in order to ensure the robustness of an implementation.</p></li></ol></div><div class="div5">
<h6><a id="N1027F" name="N1027F"></a>3.1.2.3.2 Variation 2</h6><p>A variation of this is that modified quotes from a buyer are an 
agreement to order based on the modified quote. Or the supplier may, in response to the buyer require that there to be more 
than one manufacturer that can meet the quote.
							</p><p>
							
							
							</p><p>Requirements for variation 2</p><ol class="enumar"><li><p>Needs the support of conditional paths.
</p></li><li><p>Needs the support of sequence. 
</p></li></ol></div></div></div></div></div><div class="div1">
<h2><a id="Critical_Success_Factor_Analysis" name="Critical_Success_Factor_Analysis"></a>4 Critical Success Factor Analysis</h2><p> From the CSF Analysis 8 goals were extracted, 16 critical success 
factors identified and 19 requirements. These are summarized next.




</p><div class="div2">
<h3><a id="CSF_Analysis_Goals" name="CSF_Analysis_Goals"></a>4.1 CSF Analysis Goals</h3><p>The next subsections list the CSF goals.
	</p><div class="div3">
<h4><a id="G-001" name="G-001"></a>4.1.1 C-G-001</h4><p>To be able to capture the interaction of a set of web services, 
from a global perspective.

		</p></div><div class="div3">
<h4><a id="G-002" name="G-002"></a>4.1.2 C-G-002</h4><p>To be able to work with existing standards (i.e. WS-BPEL and 
other standards) to avoid duplication where possible).
		</p></div><div class="div3">
<h4><a id="G-003" name="G-003"></a>4.1.3 C-G-003</h4><p>To provide a conceptual model that is understandable by normal 
human beings.


		</p></div><div class="div3">
<h4><a id="G-004" name="G-004"></a>4.1.4 C-G-004</h4><p>To enable interoperability amongst participating web services. 	</p></div><div class="div3">
<h4><a id="G-005" name="G-005"></a>4.1.5 C-G-005</h4><p>To be simple for simple things and as simple as possible for 
complex things.	</p></div><div class="div3">
<h4><a id="G-006" name="G-006"></a>4.1.6 C-G-006</h4><p>To be robust (against change). This might be achieved by being 
sufficiently abstract.		</p></div><div class="div3">
<h4><a id="G-007" name="G-007"></a>4.1.7 C-G-007</h4><p>To be able to express business processes.		</p></div><div class="div3">
<h4><a id="G-008" name="G-008"></a>4.1.8 C-G-008</h4><p>To be applicable to a domain wider than B2B applications.		</p></div></div><div class="div2">
<h3><a id="Critical_Success_Factors" name="Critical_Success_Factors"></a>4.2 Critical Success Factors</h3><p>Those factors that define the success of a choreography description 
language are as follows:

	</p><div class="div3">
<h4><a id="CSF-001" name="CSF-001"></a>4.2.1 C-CSF-001</h4><p>To be successful a CDL MUST NOT assume a single controller.
		</p></div><div class="div3">
<h4><a id="CSF-002" name="CSF-002"></a>4.2.2 C-CSF-002</h4><p>To be successful a CDL MUST promote a peer to peer 
relationships.
		</p></div><div class="div3">
<h4><a id="CSF-003" name="CSF-003"></a>4.2.3 C-CSF-003</h4><p>To be successful a CDL MUST enable choreographies to be composed 
of other choreographies.	</p></div><div class="div3">
<h4><a id="CSF-004" name="CSF-004"></a>4.2.4 C-CSF-004</h4><p>To be successful a CDL MUST enable a choreography to be 
segmented based on some facet.	</p></div><div class="div3">
<h4><a id="CSF-005" name="CSF-005"></a>4.2.5 C-CSF-005</h4><p>To be successful a CDL MUST be able to describe a declarative 
global model of interaction.
	</p></div><div class="div3">
<h4><a id="CSF-006" name="CSF-006"></a>4.2.6 C-CSF-006</h4><p>To be successful a CDL MUST enable state to be aligned between participants. 	</p></div><div class="div3">
<h4><a id="CSF-007" name="CSF-007"></a>4.2.7 C-CSF-007</h4><p>To be successful a CDL description MUST be verifiable at runtime.</p></div><div class="div3">
<h4><a id="CSF-008" name="CSF-008"></a>4.2.8 C-CSF-008</h4><p>To be successful a CDL description MUST enable 
static verification of correctness properties.	</p></div><div class="div3">
<h4><a id="CSF-009" name="CSF-009"></a>4.2.9 C-CSF-009</h4><p>To be successful a CDL MUST NOT be dependent on future 
specifications.
	</p></div><div class="div3">
<h4><a id="CSF-010" name="CSF-010"></a>4.2.10 C-CSF-010</h4><p>To be successful a CDL MUST be extensible.
		</p></div><div class="div3">
<h4><a id="CSF-011" name="CSF-011"></a>4.2.11 C-CSF-011</h4><p>To be successful a CDL MUST have a simple conceptual model.  
	</p></div><div class="div3">
<h4><a id="CSF-012" name="CSF-012"></a>4.2.12 C-CSF-012</h4><p>To be successful a CDL MUST facilitate the use of tools to 
manage and generate descriptions of choreographies.	</p></div><div class="div3">
<h4><a id="CSF-013" name="CSF-013"></a>4.2.13 C-CSF-013</h4><p>To be successful a CDL MUST be able to capture interactions between participants with different policy requirements.

	</p></div><div class="div3">
<h4><a id="CSF-014" name="CSF-014"></a>4.2.14 C-CSF-014</h4><p>To be successful a CDL MUST support WSDL 2.0.	</p></div><div class="div3">
<h4><a id="CSF-015" name="CSF-015"></a>4.2.15 C-CSF-015</h4><p>To be successful a CDL MUST NOT require changes to the WSDL definiton of a  Web Service.	</p></div><div class="div3">
<h4><a id="CSF-016" name="CSF-016"></a>4.2.16 C-CSF-016</h4><p>To be successful a CDL MUST be consistent with the emerging Semantic Web.	</p></div></div></div><div class="div1">
<h2><a id="Choreography_Requirements" name="Choreography_Requirements"></a>5 Choreography Requirements</h2><a id="C-CR-1001" name="C-CR-1001"></a><table><tbody><tr><td>
								C-CR-1001
							</td><td></td></tr><tr><td>
All specified choreography descriptions MUST be compatible with WSDL 2.0.
</td><td></td><td></td></tr></tbody></table><a id="C-CR-1002" name="C-CR-1002"></a><table><tbody><tr><td>
					C-CR-1002
				</td><td>
				</td></tr><tr><td>
A choreography MUST be independent of implementation technology.
				</td><td></td><td></td></tr></tbody></table><a id="C-CR-1003" name="C-CR-1003"></a><table><tbody><tr><td>
					C-CR-1003
				</td><td>
				</td></tr><tr><td>
A choreography MUST provide a global model for presenting its interactions from the point of view of all the parties and not from the point of view of just one party.
				</td><td></td><td></td></tr></tbody></table><a id="C-CR-2301" name="C-CR-2301"></a><table><tbody><tr><td>
					C-CR-2301
				</td><td>
								
				</td></tr><tr><td>
A choreography language MAY provide a mean by which a choreography description can be bound to technologies other than WSDL 2.0.	</td><td></td><td></td></tr></tbody></table><a id="C-CR-4210" name="C-CR-4210"></a><table><tbody><tr><td>
					C-CR-4210
				</td><td>
				</td></tr><tr><td>
A choreography MUST provide error handeling capabilities.
				</td><td></td><td></td></tr></tbody></table><a id="C-CR-4211" name="C-CR-4211"></a><table><tbody><tr><td>
					C-CR-4211
				</td><td>
				</td></tr><tr><td>
A choreography language MUST be able to describe a timeout against any observable interaction.
							</td><td></td><td></td></tr></tbody></table><a id="C-CR-4212" name="C-CR-4212"></a><table><tbody><tr><td>
					C-CR-4212
				</td><td>
				</td></tr><tr><td>
A choreography language MUST be able to describe the handling of unexpected erros. 
							</td><td></td><td></td></tr></tbody></table><a id="C-CR-4213" name="C-CR-4213"></a><table><tbody><tr><td>
					C-CR-4213
				</td><td>
				</td></tr><tr><td>
A choreography definition MUST enable a participant to point a deviation in a choreography.

				</td><td></td><td></td></tr></tbody></table><a id="C-CR-4220" name="C-CR-4220"></a><table><tbody><tr><td>
					C-CR-4220
				</td><td></td></tr><tr><td>
A CDL MUST enable the definition of interactions between participants that are independent of message format.

			</td><td></td><td></td></tr></tbody></table><a id="C-CR-4222" name="C-CR-4222"></a><table><tbody><tr><td>
					C-CR-4222
				</td><td></td></tr><tr><td>
It MUST be possible to pass participants identification data.

							</td><td></td><td></td></tr></tbody></table><a id="C-CR-4223" name="C-CR-4223"></a><table><tbody><tr><td>
					C-CR-4223
				</td><td></td></tr><tr><td>
It MUST be possible to model message flows that repeat.
							</td><td></td><td></td></tr></tbody></table><a id="C-CR-4310" name="C-CR-4310"></a><table><tbody><tr><td>
					C-CR-4310
				</td><td></td></tr><tr><td>
A CDL MUST provide the ability to add annotations.
				</td><td></td><td></td></tr></tbody></table><a id="C-CR-4311" name="C-CR-4311"></a><table><tbody><tr><td>
					C-CR-4311
				</td><td></td></tr><tr><td>
A CDL MUST provide means of abstractions.

						</td><td></td><td></td></tr></tbody></table><a id="C-CR-4510" name="C-CR-4510"></a><table><tbody><tr><td>
					C-CR-4510
				</td><td></td></tr><tr><td>
A CDL MUST be able to describe conditional behavior.
				</td><td></td><td></td></tr></tbody></table><a id="C-CR-4511" name="C-CR-4511"></a><table><tbody><tr><td>
					C-CR-4511
				</td><td></td></tr><tr><td>

A CDL MUST enable the describtion of external observable behavior between participants. 
				</td><td></td><td></td></tr></tbody></table><a id="C-CR-4514" name="C-CR-4514"></a><table><tbody><tr><td>
					C-CR-4514
				</td><td></td></tr><tr><td>
A CDL MUST be able to describe multi-party interaction.
						</td><td></td><td></td></tr></tbody></table><a id="C-CR-4610" name="C-CR-4610"></a><table><tbody><tr><td>
					C-CR-4610
				</td><td></td></tr><tr><td>
It MUST be possible to refere to a choreography from within its description.
						</td><td></td><td></td></tr></tbody></table><a id="C-CR-4611" name="C-CR-4611"></a><table><tbody><tr><td>
					C-CR-4611
				</td><td></td></tr><tr><td>
A CDL MUST enable changes to bindings at run time to allow dynamic participation.
						</td><td></td><td></td></tr></tbody></table><a id="C-CR-4612" name="C-CR-4612"></a><table><tbody><tr><td>
					C-CR-4612
				</td><td></td></tr><tr><td>
A CDL MUST enable the definitoin of synchronization points.


				</td><td></td><td></td></tr></tbody></table><a id="C-CR-4613" name="C-CR-4613"></a><table><tbody><tr><td>
					C-CR-4613
				</td><td></td></tr><tr><td>
A CDL MUST provide mechanisms to support syntactic reuse.	
						</td><td></td><td></td></tr></tbody></table><a id="C-CR-4615" name="C-CR-4615"></a><table><tbody><tr><td>
					C-CR-4615
				</td><td></td></tr><tr><td>
A CDL MUST be able to describe sequences of dependent interactions and parallel interactions.



	
						</td><td></td><td></td></tr></tbody></table><a id="C-CR-5001" name="C-CR-5001"></a><table><tbody><tr><td>
					C-CR-5001
				</td><td></td></tr><tr><td>
A CDL MUST enable validation of choreography definition for correctness properties, including: livelock, deadlock and leak freedom.
				</td><td></td><td></td></tr></tbody></table><a id="C-CR-5100" name="C-CR-5100"></a><table><tbody><tr><td>
					C-CR-5100
				</td><td></td></tr><tr><td>
It MUST be possible to unambigously reference a choreography.
				</td><td></td><td></td></tr></tbody></table><a id="C-CR-5200" name="C-CR-5200"></a><table><tbody><tr><td>
					C-CR-5200
				</td><td></td></tr><tr><td>
A CDL MUST enable the generation of implementation code and test cases.
</td><td></td><td></td></tr></tbody></table><a id="C-CR-5201" name="C-CR-5201"></a><table><tbody><tr><td>
					C-CR-5201
				</td><td></td></tr><tr><td>
A CDL MUST be independent of business semantics.
</td><td></td><td></td></tr></tbody></table><a id="C-CR-5202" name="C-CR-5202"></a><table><tbody><tr><td>
					C-CR-5202
				</td><td></td></tr><tr><td>
A CDL MUST enable the specification of QoS properties.
</td><td></td><td></td></tr></tbody></table><a id="C-CR-5203" name="C-CR-5203"></a><table><tbody><tr><td>
					C-CR-5203
				</td><td></td></tr><tr><td>
A CDL MUST enable the demarcation of collaboration groups.
</td><td></td><td></td></tr></tbody></table><a id="C-CR-5204" name="C-CR-5204"></a><table><tbody><tr><td>
					C-CR-5204
				</td><td></td></tr><tr><td>
A CDL MUST enable the expression of static and dynamic timeouts.
</td><td></td><td></td></tr></tbody></table><a id="C-CR-5205" name="C-CR-5205"></a><table><tbody><tr><td>
					C-CR-5205
				</td><td></td></tr><tr><td>
A CDL MUST enable the determination of which collaboration group a message belongs to.
</td><td></td><td></td></tr></tbody></table></div><div class="div1">
<h2><a id="Correlation_of_Use_Cases_and_Requirements" name="Correlation_of_Use_Cases_and_Requirements"></a>6 Correlation of Use Cases and Requirements</h2><div class="div2">
<h3><a id="N105BE" name="N105BE"></a>6.1 Use Cases and Requirements Cross-Reference</h3><p>
				This section cross references the use case requirements with requirements. 
				</p><a id="xrefucreq" name="xrefucreq"></a><table border="1"><caption>Use Cases and Requirements Cross-Reference</caption><tbody><tr><th>Use Case Reference</th><th>Variation</th><th>Requirement Reference</th></tr><tr><td>C-UC-001</td><td>Primary</td><td>C-CR-4210, D-CR-4212</td></tr><tr><td>C-UC-001</td><td>Primary</td><td>C-CR-4222</td></tr><tr><td>C-UC-001</td><td>Primary</td><td>C-CR-4613, C-CR-4612</td></tr><tr><td>C-UC-001</td><td>Primary</td><td>C-CR-4222</td></tr><tr><td>C-UC-001</td><td>Primary</td><td>C-CR-5203</td></tr><tr><td>C-UC-001</td><td>Primary</td><td>C-CR-5204</td></tr><tr><td>C-UC-001</td><td>Primary</td><td>C-CR-4615</td></tr><tr><td>C-UC-001</td><td>Variation 1</td><td>C-CR-4310</td></tr><tr><td>C-UC-001</td><td>Variation 1</td><td>C-CR-1003, C-CR-4514</td></tr><tr><td>C-UC-001</td><td>Variation 2</td><td>C-CR-4613, C-CR-4610, C-CR-5100</td></tr><tr><td>C-UC-001</td><td>Variation 2</td><td>C-CR-4613, C-CR-4610, C-CR-5100, C-CR-5001</td></tr><tr><td>C-UC-001</td><td>Variation 2</td><td>C-CR-5100</td></tr><tr><td>C-UC-001</td><td>Variation 3</td><td>C-CR-4213, C-CR-4210</td></tr><tr><td>C-UC-001</td><td>Variation 4</td><td>C-CR-4212, C-CR-4213, C-CR-4210</td></tr><tr><td>C-UC-001</td><td>Variation 4</td><td>C-CR-4211</td></tr><tr><td>C-UC-001</td><td>Variation 4</td><td>C-CR-5203, C-CR-5205</td></tr><tr><td>C-UC-001</td><td>Variation 4</td><td>C-CR-4211, C-CR-4223</td></tr><tr><td>C-UC-001</td><td>Variation 5</td><td>C-CR-4212</td></tr><tr><td>C-UC-001</td><td>Variation 5</td><td>C-CR-1001</td></tr><tr><td>C-UC-001</td><td>Variation 6</td><td>C-CR-4220, C-CR-5202</td></tr><tr><td>C-UC-001</td><td>Variation 6</td><td>C-CR-5205</td></tr><tr><th>Use Case Reference</th><th>Variation</th><th>Requirement Reference</th></tr><tr><td>C-UC-002</td><td>Primary</td><td>C-CR-4223</td></tr><tr><td>C-UC-002</td><td>Primary</td><td>C-CR-4611</td></tr><tr><td>C-UC-002</td><td>Primary</td><td>C-CR-5205</td></tr><tr><td>C-UC-002</td><td>Primary</td><td>C-CR-4610</td></tr><tr><td>C-UC-002</td><td>Variation 1</td><td>C-CR-5200</td></tr><tr><td>C-UC-002</td><td>Variation 1</td><td>C-CR-5200</td></tr><tr><td>C-UC-002</td><td>Variation 1</td><td>C-CR-5001</td></tr><tr><td>C-UC-002</td><td>Variation 2</td><td>C-CR-4510</td></tr><tr><td>C-UC-002</td><td>Variation 2</td><td>C-CR-4615</td></tr></tbody></table></div><div class="div2">
<h3><a id="N10769" name="N10769"></a>6.2 Requirements and Use Cases Cross-Reference</h3><p>
				This section cross references requirements with use cases requirements. 
				</p><a id="xrefrequc" name="xrefrequc"></a><table border="1"><caption>Requirements and Use Cases Cross-Reference</caption><tbody><tr><th>Requirement Reference</th><th>Use Case Reference</th></tr><tr><td>Req Ref</td><td>Use Case Ref</td></tr><tr><td>C-CR-1001</td><td>C-UC-001/Var5</td></tr><tr><td>C-CR-1002</td><td>Charter</td></tr><tr><td>C-CR-1003</td><td>C-UC-001/Var1</td></tr><tr><td>C-CR-2301</td><td>Charter</td></tr><tr><td>C-CR-4210</td><td>C-UC-001/Primary/Var3/Var4</td></tr><tr><td>C-CR-4211</td><td>C-UC-001/Var4</td></tr><tr><td>C-CR-4212</td><td>C-UC-001/Primary/Var4/Var5</td></tr><tr><td>C-CR-4213</td><td>C-UC-001/Var3/Var4</td></tr><tr><td>C-CR-4220</td><td>C-UC-001/Var6</td></tr><tr><td>C-CR-4222</td><td>C-UC-001/Primary</td></tr><tr><td>C-CR-4223</td><td>C-UC-001/Var4, C-UC-002/Primary</td></tr><tr><td>C-CR-4310</td><td>C-UC-001/Var1</td></tr><tr><td>C-CR-4311</td><td></td></tr><tr><td>C-CR-4510</td><td>C-UC-001/Var2</td></tr><tr><td>C-CR-4511</td><td>Charter/Mission</td></tr><tr><td>C-CR-4514</td><td>C-UC-001/Var1</td></tr><tr><td>C-CR-4610</td><td>C-UC-001/Var2, C-UC-002/Primary</td></tr><tr><td>C-CR-4611</td><td>C-UC-002/Primary</td></tr><tr><td>C-CR-4612</td><td>C-UC-001/Primary</td></tr><tr><td>C-CR-4613</td><td>C-UC-001/Primary/Var2</td></tr><tr><td>C-CR-4615</td><td>C-UC-001/Primary, C-UC-002/Var2</td></tr><tr><td>C-CR-5001</td><td>C-UC-001/Var2, C-UC-002/Var1</td></tr><tr><td>C-CR-5100</td><td>C-UC-001/Var2</td></tr><tr><td>C-CR-5200</td><td>C-UC-002/Var1</td></tr><tr><td>C-CR-5201</td><td></td></tr><tr><td>C-CR-5202</td><td>C-UC-001/Var6</td></tr><tr><td>C-CR-5203</td><td>C-UC-001/Primary/Var4</td></tr><tr><td>C-CR-5204</td><td>C-UC-001/Primary</td></tr><tr><td>C-CR-5205</td><td>C-UC-001/Var4/Var6, C-UC-002/Primary</td></tr></tbody></table></div><div class="div2">
<h3><a id="N10889" name="N10889"></a>6.3 Requirements Coverage</h3><p>No requirements document can provide complete coverage for any particular technology. However, these user scenarios, use cases, the requirements derived from them are intended to provide coverage for the majority of the most common possible use of Web Service Choreography. It is hoped that any omissions or errors contained herein will be corrected as this document matures.</p></div></div><div class="div1">
<h2><a id="refs" name="refs"></a>7 Appendix A - References</h2><div class="div2">
<h3><a id="N10892" name="N10892"></a>7.1 Normative References</h3><dl><dt class="label"><a id="DAML-S" name="DAML-S"></a>DAML-S</dt><dd>
						<em>DAML-S: Semantic Markup for Web Services</em>,
			The DAML Services Coalition, Version 0.9 Beta.
			Available from 
			<a href="http://www.daml.org/services/daml-s/0.9">
http://www.daml.org/services/daml-s/0.9</a>.
			</dd><dt class="label"><a id="SOAP-1.2" name="SOAP-1.2"></a>SOAP-1.2</dt><dd>
						<em>SOAP Version 1.2 Part 1: Messaging Framework
</em>,
			Martin Gudgin, Marc Hadley, Noah Mendelsohn, Jean-Jacques Moreau,
			Henrik Frystyk Nielsen, Editors.  World Wide
			Web Consortium, 24 June 2003.  Available from
			<a href="http://www.w3.org/TR/soap12-part1">
http://www.w3.org/TR/soap12-part1</a>.
			</dd><dt class="label"><a id="RFC2119" name="RFC2119"></a>RFC2119</dt><dd> S. Bradner, <em>RFC 2119:
			Key words for use in RFCs to Indicate Requirement Levels</em>,
			Internet Engineering Task Force, 1997.  Available from 
			<a href="http://www.ietf.org/rfc/rfc2119.txt">http://www.ietf.org/rfc/rfc2119.txt</a>.
			</dd><dt class="label"><a id="WS-ARCH" name="WS-ARCH"></a>WS-ARCH</dt><dd>
						<em>Web Services Architecture</em>,
			David Booth, Michael Champion, Chris Ferris, Francis McCabe,
			Eric Newcomer, David Orchard, Editors.  World Wide Web
			Consortium Working Draft.  Available from
			<a href="http://www.w3.org/TR/ws-arch">
http://www.w3.org/TR/ws-arch</a>.
			</dd><dt class="label"><a id="WS-CHOR" name="WS-CHOR"></a>WS-CHOR</dt><dd>
						<em>Web Services Choreography Working Group Charter</em>,
			World Wide Web Consortium, January 2003.  Available from
			<a href="http://www.w3.org/2003/01/wscwg-charter">
http://www.w3.org/2003/01/wscwg-charter</a>.
			</dd><dt class="label"><a id="WSDL-2.0" name="WSDL-2.0"></a>WSDL-2.0</dt><dd>
						<em>Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language</em>,
			Roberto Chinnici, Martin Gudgin, Jean-Jacques Moreau,
			Sanjiva Weerawarana, Editors.  World Wide
			Web Consortium Working Draft.  Available from
			<a href="http://www.w3.org/TR/wsdl12">
http://www.w3.org/TR/wsdl12</a>.
			</dd></dl></div><div class="div2">
<h3><a id="N10908" name="N10908"></a>7.2 Informative References</h3><dl><dt class="label"><a id="BPEL" name="BPEL"></a>BPEL</dt><dd>
						<em>Business Process Execution Language for Web Services Version 1.1</em>,

			Tony Andrews, Francisco Curbera, Hitesh Dholakia, Yaron Goland,
			Johannes Klein, Frank Leymann, Kevin Liu, Dieter Roller,
			Doug Smith, Satish Thatte, Ivana Trickovic, Sanjiva Weerawarana.
			BEA, IBM, Microsoft, SAP, and Siebel, 2003.  Available from
			<a href="http://www-106.ibm.com/developerworks/library/ws-bpel">
http://www-106.ibm.com/developerworks/library/ws-bpel</a>.
			</dd><dt class="label"><a id="BPML" name="BPML"></a>BPML</dt><dd>
						<em>Business Process Markup Language 1.0</em>,
			Assaf Arkin.  BPMI.org, 2002.  Available from
			<a href="http://www.bpmi.org/specifications.esp">
http://www.bpmi.org/specifications.esp</a>.
			</dd><dt class="label"><a id="BPSS" name="BPSS"></a>BPSS</dt><dd>
						<em>ebXML Business Process Specification Schema Version 1.01</em>,
			ebXML Business Process Project Team.  UN/CEFACT and Oasis, 11 May 2001.
			Available from
			<a href="http://www.ebxml.org/specs/ebBPSS.pdf">
http://www.ebxml.org/specs/ebBPSS.pdf</a>.
			</dd><dt class="label"><a id="CSF" name="CSF"></a>CSF</dt><dd>
						<em>Chief Executives Define Their Own Data Needs</em>, 
			Rockart, J., Harvard Business Review, March/April 1979.
			</dd><dt class="label"><a id="UML" name="UML"></a>UML</dt><dd>
						<em>Unified Modeling Language Version 1.5</em>,
			Object Management Group, March 2003.  Available from
			<a href="http://www.omg.org/technology/documents/formal/uml.htm">
http://www.omg.org/technology/documents/formal/uml.htm</a>.
			</dd><dt class="label"><a id="WSCI" name="WSCI"></a>WSCI</dt><dd>
						<em>Web Service Choreography Interface 1.0</em>,
			Assaf Arkin, Sid Askary, Scott Fordin, Wolfgang Jekeli,
			Kohsuke Kawaguchi, David Orchard, Stefano Pogliani,
			Karsten Riemer, Susan Struble, Pal Takacsi-Nagy,
			Ivana Trickovic, Sinisa Zimek, Editors.  World Wide
			Web Consortium, 15 March 2001.  Available from
			<a href="http://www.w3.org/TR/wsci">
http://www.w3.org/TR/wsci</a>.
			</dd><dt class="label"><a id="WSCL" name="WSCL"></a>WSCL</dt><dd>
						<em>Web Services Conversation Language (WSCL) 1.0 
			W3C Note 14 March 2002</em>,
			Arindam Banerji, Claudio Bartolini, Dorothea Beringer,
			Venkatesh Chopella, Kannan Govindarajan, Alan Karp,
			Harumi Kuno, Mike Lemon, Gregory Pogossiants, Shamik Sharma,
			Scott Williams, Editors.  World Wide
			Web Consortium, 14 March 2002.  Available from
			<a href="http://www.w3.org/TR/wscl10">
http://www.w3.org/TR/wscl10</a>.
			</dd><dt class="label"><a id="WS-COOR" name="WS-COOR"></a>WS-COOR</dt><dd>
						<em>Web Services Coordination (WS-Coordination)</em>,
			Felipe Cabrera, George Copeland, Tom Freund, Johannes Klein,
			David Langworthy, David Orchard, John Shewchuk, Tony Storey.
			BEA, IBM and Microsoft, 2002.  Available from
			<a href="http://www-106.ibm.com/developerworks/library/ws-coor/">
http://www-106.ibm.com/developerworks/library/ws-coor/</a>.
			</dd><dt class="label"><a id="WS-TRANS" name="WS-TRANS"></a>WS-TRANS</dt><dd>
						<em>Web Services Transaction (WS-Transaction)</em>,
			BEA, IBM and Microsoft, 2002.  Available from
			<a href="http://www-106.ibm.com/developerworks/webservices/library/ws-transpec/">http://www-106.ibm.com/developerworks/webservices/library/ws-transpec/</a>.
			</dd></dl></div></div><div class="div1">
<h2><a id="acks" name="acks"></a>8 Appendix B - Acknowledgements</h2><p>This document has been produced by the members of the Web Services Choreography Working Group. The chairs of this Working Group are Martin Chapman (Oracle Corporation) and Steve Ross-Talbot (Enigmatec Corporation).The editors would like to thank the Working Group members for their contributions. Members of the Working Group are (at the time of writing): Assaf Arkin (Intalio Inc.),
Daniel Austin (Sun Microsystems, Inc.),
Abbie Barbir (Nortel Networks),
Alistair Barros (DSTC Pty Ltd (CITEC)),
Carine Bournez (W3C),
Gary Brown (Enigmatec Corporation),
Mike Brumbelow (Apple),
David Burdett (Commerce One),
Ravi Byakod (Intalio Inc.),
Michael Champion (Software AG),
David Chapell (Sonic Software),
Ugo Corda (SeeBeyond Technology Corporation),
Fred Cummins (EDS),
William Eidson (TIBCO Software),
Keith Evans (Hewlett-Packard),
Anthony Fletcher (Choreology Ltd),
Peter Furniss (Choreology Ltd),
Yaron Goland (BEA Systems),
Leonard Greski (W. W. Grainger, Inc.),
Jim Hendler (University of Maryland (Mind Lab)),
Ricky Ho (Cisco Systems Inc.),
Andre Huertas (Uniform Code Council),
Duncan Johnston-Watt (Enigmatec Corporation),
Nickolas Kavantzas (Oracle Corporation),
Eunju Kim (National Computerization Agency),
Mayilraj Krishnan (Cisco Systems Inc.),
Melanie Kudela (Uniform Code Council),
Yutaka Kudou (Hitachi, Ltd.),
Yves Lafon (W3C),
Paul Lipton (Computer Associates),
Kevin Liu (SAP AG),
Monica Martin (Sun Microsystems, Inc.),
Francis McCabe (Fujitsu Ltd.),
Jeff Mischkinsky (Oracle Corporation),
Eric Newcomer (IONA),
Ed Peters (webMethods, Inc.),
Greg Ritzinger (Novell),
Yoko Seki (Hitachi, Ltd.),
Evren Sirin (University of Maryland (Mind Lab)),
Ivana Trickovic (SAP AG),
William Vambenepe (Hewlett-Packard),
Jim Webber (Arjuna Technologies Ltd.),
Stuart Wheater (Arjuna Technologies Ltd.),
Prasad Yendluri (webMethods, Inc.),
Hadrian Zbarcea (IONA).
</p><p>Previous members of the Working Group were:Steven White (SeeBeyond Technology Corporation), Steve Pruitt (Novell), Richard Bonneau (IONA), Sanjay Patil (IONA), Colleen Evans (Sonic Software), Carol McDonald (Sun Microsystems, Inc.), Daniel Austin (W. W. Grainger, Inc.), Jon Dart (TIBCO Software), Allen Brown (Microsoft Corporation), Greg Meredith (Microsoft Corporation). 
</p></div></div></body></html>