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"><Daniel.B.Austin@Sun.COM></a></dd><dd>Abbie Barbir, Nortel Networks, Inc. <a href="mailto:abbieb@nortelnetworks.com"><abbieb@nortelnetworks.com></a></dd><dd>Ed Peters, WebMethods, Inc. <a href="mailto:ed.peters@webmethods.com"><ed.peters@webmethods.com></a></dd><dd>Steve Ross-Talbot, Enigmatec, Inc. <a href="mailto:steve@enigmatec.com"><steve@enigmatec.com></a></dd></dl><p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © 2004 <a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>®</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>
2.1 <a href="#What_is_Web_Services_Choreography">What is Web Services Choreography?</a><br>
2.2 <a href="#How_is_a_Choreography_used">How is a Choreography used?</a><br>
2.3 <a href="#Benefits_of_Choreography_used">Benefits of Choreography Language</a><br>
2.4 <a href="#N10125">Conventions used in this document</a><br>
3 <a href="#Use_Cases">Use Cases</a><br>
3.1 <a href="#Use_Case_Descriptions">Use Case Descriptions</a><br>
3.1.1 <a href="#UC-001">C-UC-001 -Travel Agent</a><br>
3.1.1.1 <a href="#N10150">Primary Description</a><br>
3.1.1.2 <a href="#N1019C">Requirements</a><br>
3.1.1.3 <a href="#N101B5">Variation on the use case</a><br>
3.1.1.3.1 <a href="#N101B8">Variation 1</a><br>
3.1.1.3.2 <a href="#N101C6">Variation 2</a><br>
3.1.1.3.3 <a href="#N101DB">Variation 3</a><br>
3.1.1.3.4 <a href="#N101EA">Variation 4</a><br>
3.1.1.3.5 <a href="#N101FE">Variation 5</a><br>
3.1.1.3.6 <a href="#N1020C">Variation 6</a><br>
3.1.2 <a href="#UC-002">C-UC-002 - Quote Request</a><br>
3.1.2.1 <a href="#N10222">Primary description</a><br>
3.1.2.2 <a href="#N10255">Requirements</a><br>
3.1.2.3 <a href="#N10265">Variations on the use case</a><br>
3.1.2.3.1 <a href="#N10268">Variation 1</a><br>
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>
4.1 <a href="#CSF_Analysis_Goals">CSF Analysis Goals</a><br>
4.1.1 <a href="#G-001">C-G-001</a><br>
4.1.2 <a href="#G-002">C-G-002</a><br>
4.1.3 <a href="#G-003">C-G-003</a><br>
4.1.4 <a href="#G-004">C-G-004</a><br>
4.1.5 <a href="#G-005">C-G-005</a><br>
4.1.6 <a href="#G-006">C-G-006</a><br>
4.1.7 <a href="#G-007">C-G-007</a><br>
4.1.8 <a href="#G-008">C-G-008</a><br>
4.2 <a href="#Critical_Success_Factors">Critical Success Factors</a><br>
4.2.1 <a href="#CSF-001">C-CSF-001</a><br>
4.2.2 <a href="#CSF-002">C-CSF-002</a><br>
4.2.3 <a href="#CSF-003">C-CSF-003</a><br>
4.2.4 <a href="#CSF-004">C-CSF-004</a><br>
4.2.5 <a href="#CSF-005">C-CSF-005</a><br>
4.2.6 <a href="#CSF-006">C-CSF-006</a><br>
4.2.7 <a href="#CSF-007">C-CSF-007</a><br>
4.2.8 <a href="#CSF-008">C-CSF-008</a><br>
4.2.9 <a href="#CSF-009">C-CSF-009</a><br>
4.2.10 <a href="#CSF-010">C-CSF-010</a><br>
4.2.11 <a href="#CSF-011">C-CSF-011</a><br>
4.2.12 <a href="#CSF-012">C-CSF-012</a><br>
4.2.13 <a href="#CSF-013">C-CSF-013</a><br>
4.2.14 <a href="#CSF-014">C-CSF-014</a><br>
4.2.15 <a href="#CSF-015">C-CSF-015</a><br>
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>
6.1 <a href="#N105BE">Use Cases and Requirements Cross-Reference</a><br>
6.2 <a href="#N10769">Requirements and Use Cases Cross-Reference</a><br>
6.3 <a href="#N10889">Requirements Coverage</a><br>
7 <a href="#refs">Appendix A - References</a><br>
7.1 <a href="#N10892">Normative References</a><br>
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>