index.html
73.9 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
<!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>WS Choreography Model Overview</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>WS Choreography Model Overview</h1>
<h2><a id="w3c-doctype" name="w3c-doctype"></a>W3C Working Draft 24 March 2004</h2><dl><dt>This version:</dt><dd>
<a href="http://www.w3.org/TR/2004/WD-ws-chor-model-20040324/">http://www.w3.org/TR/2004/WD-ws-chor-model-20040324/</a>
</dd><dt>Latest version:</dt><dd>
<a href="http://www.w3.org/TR/ws-chor-model/">http://www.w3.org/TR/ws-chor-model/</a>
</dd><dt>Editors:</dt><dd>David Burdett, Commerce One <a href="mailto:david.burdett@commerceone.com"><david.burdett@commerceone.com></a></dd><dd>Nickolas Kavantzas, Oracle <a href="mailto:nickolas.kavantzas@oracle.com"><nickolas.kavantzas@oracle.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>It's purpose is to provide an information model that describes the data and the relationships between them that is needed to define a choreography that describes the sequence and conditions in which the data exchanged between two or more participants in order to meet some useful purpose.</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 <a href="http://www.w3.org/2004/02/Process-20040205/tr.html#first-wd">first W3C Working Draft</a> of the Web Services Choreography Model Overview document. </p><p>It has been produced by 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 not a chartered deliverable of the <a href="http://www.w3.org/2002/ws/chor/">Web Services Choreography Working Group</a>; however, it is the corner stone of the Choreography Definition Language, which is a chartered deliverable.</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="#introduction">Introduction</a><br>
1.1 <a href="#purpose">Purpose</a><br>
1.2 <a href="#goals">Goals</a><br>
1.3 <a href="#documentscope">Document Scope</a><br>
2 <a href="#abstractportableandconcretechoreographies">Abstract, Portable and Concrete Choreographies</a><br>
2.1 <a href="#abstractchoreography">Abstract Choreography</a><br>
2.2 <a href="#portablechoreography">Portable Choreography</a><br>
2.3 <a href="#concretechoreographies">Concrete Choreographies</a><br>
2.4 <a href="#relationshipbetweenchoreographytypes">Relationship between Choreography Types</a><br>
3 <a href="#modeldescription">Model Description </a><br>
3.1 <a href="#rolesparticipantsandrelationships">Roles, Participants and Relationships</a><br>
3.1.1 <a href="#roles">Roles</a><br>
3.1.2 <a href="#participants">Participants</a><br>
3.1.3 <a href="#relationships">Relationships</a><br>
3.2 <a href="#choreographystructure">Choreography Structure</a><br>
3.3 <a href="#choreographycompositionandimport">Choreography Composition and Import</a><br>
3.3.1 <a href="#choreographycomposition">Choreography Composition</a><br>
3.3.2 <a href="#importstatements">Import Statements</a><br>
3.4 <a href="#typesvariablesandtokens">Types, Variables and Tokens</a><br>
3.4.1 <a href="#types">Types</a><br>
3.4.1.1 <a href="#variabletypes">Variable Types</a><br>
3.4.1.2 <a href="#channeltypes">Channel Types</a><br>
3.4.2 <a href="#variables">Variables</a><br>
3.4.2.1 <a href="#variablesandabstractconcretechoreographies">Variables and Abstract/Concrete Choreographies</a><br>
3.4.3 <a href="#tokens">Tokens</a><br>
3.5 <a href="#interactions">Interactions</a><br>
3.5.1 <a href="#interactionroles">Interaction Roles</a><br>
3.5.2 <a href="#interactionmessagecontent">Interaction Message Content</a><br>
3.5.3 <a href="#interactionchannelvariables">Interaction Channel Variables</a><br>
3.5.4 <a href="#interactionoperations">Interaction Operations</a><br>
3.5.5 <a href="#interactionstatechanges">Interaction State Changes</a><br>
3.5.6 <a href="#interactionbasedalignment">Interaction Based Alignment</a><br>
3.5.7 <a href="#protocolbasedinformationexchanges">Protocol Based Information Exchanges</a><br>
3.6 <a href="#activitiesandcontrolstructures">Activities and Control Structures</a><br>
3.6.1 <a href="#workunits">Work Units</a><br>
3.6.2 <a href="#performedchoreography">Performed Choreography</a><br>
3.6.3 <a href="#assign">Assign</a><br>
3.6.4 <a href="#noaction">NoAction</a><br>
3.6.5 <a href="#sequencecontrolstructure">Sequence Control Structure</a><br>
3.6.6 <a href="#choicecontrolstructure">Choice Control Structure</a><br>
3.6.7 <a href="#parallelcontrolstructure">Parallel Control Structure</a><br>
3.7 <a href="#choreographyexceptionsandtransactions">Choreography Exceptions and Transactions</a><br>
3.7.1 <a href="#exceptionblock">Exception Block</a><br>
3.7.2 <a href="#transactionblock">Transaction Block</a><br>
3.8 <a href="#semantics">Semantics</a><br>
</p></div><hr><div class="body"><div class="div1">
<h2><a id="introduction" name="introduction"></a>1 Introduction</h2><div class="div2">
<h3><a id="purpose" name="purpose"></a>1.1 Purpose</h3><p>Business or other activities that involve multiple different organizations or independent processes that use Web service technology to exchange information can only be successful if they are properly coordinated. This means that the sender and receiver of a message know and agree in advance:</p><ul><li><p>The format and structure of the (SOAP) messages that are exchanged, and</p></li><li><p>The sequence and conditions in which the messages are exchanged.</p></li></ul><p>WSDL and its extensions provide a mechanism by which the first objective is realized, however, it does not define the sequence and conditions, or <em>choreography</em>, in which messages are exchanged.</p><p>To solve this problem, a shared common or "global" definition of the sequence and conditions in which messages are exchanged is produced that describes the observable complementary behavior of all the participants involved. Each participant can then use the definition to build and test solutions that conform to the global definition.</p><p>The main advantage of a global definition approach is that it separates the process being followed by an individual business or system within a "domain of control" from the definition of the sequence in which each business or system exchanges information with others. This means that, as long as the "observable" sequence does not change, the rules and logic followed within the domain of control can change at will.</p><p>The purpose of this paper is to describe an information model or "meta model" for a Choreography Definition Language that identifies the information and structures required to build a "global" definition.</p></div><div class="div2">
<h3><a id="goals" name="goals"></a>1.2 Goals</h3><p>Some additional goals of this model of a choreography definition language are to permit: </p><ul><li><p>
<em>Reusability</em>. The same choreography definition is usable by different participants operating in different contexts (industry, locale, etc) with different software (e.g. application software) and different message formats and standards</p></li><li><p>
<em>Cooperative</em>. Choreographies define the sequence of exchanging messages between two (or more) independent participants or processes by describing how they should cooperate</p></li><li><p>
<em>Multi-Party</em>. Choreographies can be defined involving any number of participants or processes</p></li><li><p>
<em>Semantics</em>. Choreographies can include human-readable documentation and semantics for all the components in the choreography. </p></li><li><p>
<em>Composability</em>. Existing choreographies can be combined to form new choreographies that may be reused in different contexts</p></li><li><p>
<em>Modular.</em> Choreographies can be defined using an "import" facility that allows a choreography to be created from components contained in several different choreographies</p></li><li><p>
<em>Information Driven</em>. Choreographies describe how participants that take part in choreographies maintain where they are in the choreography by recording the state changes caused by exchanges of information and their reactions to them</p></li><li><p>
<em>Information Alignment</em>. Choreographies allow the participants that take part in choreographies to communicate and synchronize their states and the information they share</p></li><li><p>
<em>Transactionality</em>. The processes or participants that take part in a choreography can work in a "transactional" way with the ability to specify how transactions are compensated</p></li><li><p>
<em>Exception Handling</em>. Choreographies can define how exceptional or unusual conditions that occur whilst the choreography is performed are handled</p></li><li><p>
<em>Design Time Verification</em>. A developer of a business process can use the Choreography Definition, on their own to:</p><ul><li><p>Generate a behavioral interface that conforms to a BPEL definition that describes the sequence and conditions in which one of the participants in a choreography sends and receives messages</p></li><li><p>Verify that a BPEL definition conforms to behavior defined by in a Choreography Definition</p></li></ul></li><li><p>
<em>Run Time Verification</em>. The performance of a choreography can be verified at run time against the Choreography Definition to ensure that it is being followed correctly. If errors are found then the choreography can specify the action that should be taken</p></li><li><p>
<em>Compatibility with other Specifications</em>. The specifications will work alongside and complement other specifications such as the WS Reliability, WS WS Composite Application Framework (WSCAF), WS Security (WSS), WS Business Process Execution Language (WSBPEL) etc.</p></li></ul></div><div class="div2">
<h3><a id="documentscope" name="documentscope"></a>1.3 Document Scope</h3><p>This model focuses on describing the different types of information required to define a Choreography. It does not provide an XML representation of that information nor does it describe in any detail the operational semantics of how such a representation could or should be used.</p><p>This paper identifies several open issues highlighted like this. These are a non-exhaustive list of topics, ideas or problems where the authors think that more thought is needed.</p></div></div><div class="div1">
<h2><a id="abstractportableandconcretechoreographies" name="abstractportableandconcretechoreographies"></a>2 Abstract, Portable and Concrete Choreographies</h2><p>One of the key goals of this model is to enable Choreography reuse. Global definitions of a choreography facilitate this especially if choreographies are defined with varying degrees of abstraction. Although more could be defined, this model identifies and supports three different levels of abstraction in which choreographies can usefully be defined and used.</p><div class="div2">
<h3><a id="abstractchoreography" name="abstractchoreography"></a>2.1 Abstract Choreography</h3><p>The first is a highly abstract choreography that defines:</p><ul><li><p>The types of information that is exchanged, for example an order sent between a buyer and a seller</p></li><li><p>The sequence and conditions under which the information is sent.</p></li></ul><p>However, it does not define:</p><ul><li><p>The physical structure of the information that is exchanged, for example there are no definitions of the XML documents, SOAP messages, WSDL port types and operations, URLs etc that are to be used</p></li><li><p>How the different conditions that are used to control the sequence of exchanging information are determined</p></li><li><p>Where the messages in the choreography should be sent e.g. to a URL</p></li><li><p>How the messages are to be secured (if at all) and whether or not the messages are to be sent reliably.</p></li></ul><p>Although abstract, this approach will be useful for defining generally accepted or "canonical" definitions for very common processes, such as placing an order. Definitions of theses types of choreography would best be carried out by international standards organizations that have a cross-industry, multi-geographic responsibility.</p></div><div class="div2">
<h3><a id="portablechoreography" name="portablechoreography"></a>2.2 Portable Choreography</h3><p>Clearly, the development of these abstract choreographies will take some time to complete, so the second type of choreography to define is a "portable" choreography. In this type of choreography definition the definitions in an Abstract Choreography are extended with:</p><ul><li><p>Detailed definitions of the physical structure of the information that is exchanged including the WSDL port types and operations</p></li><li><p>Details of the technology to be used, for example, how to secure the messages and send them reliably</p></li><li><p>Rules that express, as far as possible, the conditions that are used to control the sequence of exchange of information, in terms of, for example XPath expressions that reference data in the messages</p></li></ul><p>However they do not specify the URLs to which the messages are sent nor, for example, the digital certificates used to secure them. This means that an organization should be able to design and build a solution that conforms, in detail, to the rules of the choreography, and only require limited additional information at run time to determine where messages should be sent. As a result realizing interoperability should be much easier.</p><p>This "portable" type of choreography is targeted more at vertical industry organizations, such as RosettaNet, that want to define rules for collaboration between the members of their industry and simplify, as far as possible, the implementation and integration process.</p></div><div class="div2">
<h3><a id="concretechoreographies" name="concretechoreographies"></a>2.3 Concrete Choreographies</h3><p>The final type of choreography, is a Concrete Choreography, where all the details are specified that are required to send a message. This extends the definition in a Portable Choreography to include information about the "endpoints". This can include information such as:</p><ul><li><p>The URLs that are the destinations of the messages that are sent, and</p></li><li><p>Other "endpoint" specific rules such as digital certificates to be used for securing messages.</p></li></ul><p>These types of choreographies are probably most applicable where two or more participants want to specify how they will cooperate and there is little or no need for other organizations to follow the same process.</p></div><div class="div2">
<h3><a id="relationshipbetweenchoreographytypes" name="relationshipbetweenchoreographytypes"></a>2.4 Relationship between Choreography Types</h3><p>The table below summarizes the three different types of choreographies.;</p><table border="1" frame="border"><thead><tr><th>
</th><th>
Abstract
</th><th>
Portable
</th><th>
Concrete
</th></tr></thead><tbody><tr><td>
<em>Types of Messages</em>
</td><td>
Identified
</td><td>
Identified
</td><td>
Identified
</td></tr><tr><td>
<em>Message Structure</em>
</td><td>
Not Defined
</td><td>
Defined
</td><td>
Defined
</td></tr><tr><td>
<em>Conditions</em>
</td><td>
Identified
</td><td>
Identified
</td><td>
Identified
</td></tr><tr><td>
<em>Condition evaluation rules</em>
</td><td>
Not defined
</td><td>
Defined as far as possible
</td><td>
Defined as far as possible
</td></tr><tr><td>
<em>Technology used</em>
</td><td>
Not defined
</td><td>
Defined
</td><td>
Defined
</td></tr><tr><td>
<em>Message Endpoint Data</em>
</td><td>
Not defined
</td><td>
Not Defined
</td><td>
Defined
</td></tr></tbody></table><p>The model described in this paper allows an Abstract Choreography to be extended to become a Portable Choreography and a Portable Choreography to be extended to become a Concrete Choreography.</p><p>The model also allows each different type of Choreography to be defined directly. This means that:</p><ul><li><p>A Portable Choreography can be defined without first defining the Abstract Choreography</p></li><li><p>A Concrete Choreography can be defined without defining an Abstract or Portable Choreography.</p></li></ul></div></div><div class="div1">
<h2><a id="modeldescription" name="modeldescription"></a>3 Model Description </h2><p>The following diagram is the full model of all the entities (without attributes).</p><img src="figure1.png" alt="Full model of all entities"><p>
<em>Figure 1: Full Model</em>
</p><p>The rest of this Model Description section describes the following subsets of the model (including attributes).</p><ul><li><p>
<em>Participants, Roles and Relationships</em>. In a Choreography information is always exchanged between Participants, such as a Business or Organization acting in one or more <em>Roles</em>, for example Buyer or Seller as part of a Relationship, for example purchasing goods.</p></li><li><p>
<em>Choreography Structure</em>. This section describes the major components of a Choreography at a high level</p></li><li><p>
<em>Choreography Composition and Import</em>. This explains how one Choreography can be created by performing other, pre-existing choreographies and importing content from other choreographies.</p></li><li><p>
<em>Types, Variables and Tokens</em>. <em>Variables </em>contain information about objects in the choreography such as the messages exchanged or the state of the <em>Roles </em>involved. <em>Tokens </em>are aliases that can be used to reference parts of a <em>Variable</em>. Both <em>Variables </em>and <em>Tokens </em>have <em>Types </em>that define the structure of what the <em>Variable </em>or <em>Token </em>contains.</p></li><li><p>
<em>Interactions</em>. These are the basic building blocks of the Choreography which result in the sending of messages between Roles in either a "one-way" or "request-response" message pattern</p></li><li><p>
<em>Activities and Control Structures</em>. Activities are the lowest level components of the Choreography that do the actual work. Control Structures combine activities with other Control Structures in a nested structure to express the sequence and conditions in which the messages in the choreography are exchanged</p></li><li><p>
<em>Choreography Exceptions and Transactions</em>. <em>Choreography Exceptions</em> describe how to specify what additional Interactions should occur when a Choreography behaves in an abnormal way. <em>Choreography Transactions</em> describes how to specify what additional Interactions should occur to reverse the effect of an earlier completed choreography</p></li><li><p>
<em>Semantics</em>. Semantics allow the creation of descriptions that can record the semantic definitions of almost every single component in the model.</p></li></ul><div class="div2">
<h3><a id="rolesparticipantsandrelationships" name="rolesparticipantsandrelationships"></a>3.1 Roles, Participants and Relationships</h3><p>In a Choreography information is always exchanged between Participants, such as a Business or Organization acting in one or more Roles, for example Buyer or Seller as part of a Relationship, for example purchasing goods.</p><p>The diagram below shows the model for Participants, Roles and Relationships.</p><img src="figure2.png" alt="Model for Participants, Roles and Relationships"><p>
<em>Figure 2: Model for Participants, Roles and Relationships</em>
</p><div class="div3">
<h4><a id="roles" name="roles"></a>3.1.1 Roles</h4><p>A Role identifies a set of related behaviors, for example the Buyer role is associated with purchasing of goods or services and the Supplier role is associated with providing those goods or services for a fee.</p></div><div class="div3">
<h4><a id="participants" name="participants"></a>3.1.2 Participants</h4><p>A Participant identifies a set of related Roles, for example a Commercial Organization could take both a Buyer Role when purchasing goods and a Seller role when selling them.</p></div><div class="div3">
<h4><a id="relationships" name="relationships"></a>3.1.3 Relationships</h4><p>A Relationship is the association of two Roles for a purpose. A relationship represents the possible ways in which two roles can interact. For example the Relationships between a Buyer and a Seller could include:</p><ul><li><p>A "Purchasing" Relationship, for the initial procurement of goods or services, and</p></li><li><p>A "Customer Management" Relationship to allow the Supplier to provide service and support after the goods have been purchased or the service provided.</p></li></ul><p>Although Relationships are always between two Roles, Choreographies involving more than two Roles are possible. For example if the purchase of goods involved a third-party Shipper contracted by the Supplier to deliver the Supplier's goods, then, in addition to the Purchasing and Customer Management relationships described above, the following relationships might exist:</p><ul><li><p>A "Logistics Provider" relationship between the Supplier and the Shipper, and</p></li><li><p>A "Goods Delivery" relationship between the Buyer and the Shipper.</p></li></ul></div></div><div class="div2">
<h3><a id="choreographystructure" name="choreographystructure"></a>3.2 Choreography Structure</h3><p>The diagram below shows the model for a Choreography Definition:</p><img src="figure3.png" alt="Model for Choreography Structure"><p>
<em>Figure 3: Model for Choreography Structure</em>
</p><p>A <em>Choreography Definition </em>defines the information required by the choreography and sequence in which it is exchanged. It contains the following:</p><ul><li><p>Zero or More "sub" Choreography Definitions which define Choreographies that can be performed by the Choreography being defined</p></li><li><p>A <em>Definition Block</em> that contains set of <em>Variable Definitions</em> and <em>Token Definitions </em>that define information about objects used by the choreography </p></li><li><p>The actual <em>Choreography </em>that in turn contains:</p><ul><li><p>A required <em>Base Choreography </em>part, that defines the normal sequence of information exchanges that should occur</p></li><li><p>An optional <em>Exception Block</em>, that contains the sequence of information exchanges that are followed when some exceptional or unusual circumstance has occurred while the Choreography was being performed, and</p></li><li><p>An optional <em>Transaction Block </em>which, if present can make the Choreography "transactional" in that it contains information exchanges that are followed when the effects of the choreography need to be <em>Compensated</em>
</p></li></ul></li><li><p>One or more <em>Work Units</em>, within the <em>Base Choreography, Exception Block </em>or <em>Transaction Block </em>that do the actual useful work within the Choreography in terms of exchanging messages and other information between the Participants. Each <em>Work Unit</em> contains a single <em>Activity </em>that is performed whenever an optional enabling condition on the <em>Work Unit</em>, called a <em>Guard</em>, is true.</p></li></ul></div><div class="div2">
<h3><a id="choreographycompositionandimport" name="choreographycompositionandimport"></a>3.3 Choreography Composition and Import</h3><p>Choreographies can be combined and built from other Choreographies as illustrated by the diagram below.</p><img src="figure4.png" alt="Model for Choreography Composition and Import"><p>
<em>Figure 4: Model for Choreography Composition and Import</em>
</p><div class="div3">
<h4><a id="choreographycomposition" name="choreographycomposition"></a>3.3.1 Choreography Composition</h4><p>Choreography Composition is the creation of new Choreographies by reusing existing choreography definitions. For example if two separate Choreographies were defined as follows:</p><ul><li><p>A Request for Quote (RFQ) Choreography that involved a Buyer role sending a request for a quotation for goods and services to a Supplier to which the Supplier responding with either a "Quotation" or a "Decline to Quote" message, and</p></li><li><p>An Order Placement Choreography where the Buyer placed and order for goods or services and the Supplier either accepted the order or rejected it. </p></li></ul><p>You could then create a new "Quote and Order" Choreography by reusing the two where the RFQ choreography was executed first, and then, depending on the outcome of the RFQ Choreography, the order was placed using the Order Placement Choreography.</p><p>In this case the new choreography is "composed" out of the two previously defined choreographies. These choreographies may be specified either:</p><ul><li><p>
<em>Locally</em>, i.e. they are included, as a <em>Sub Choreography,</em> in the same choreography definition as the choreography that performed them, or</p></li><li><p>
<em>Globally, </em>i.e. they are specified in a separate choreography definition that is defined elsewhere.</p></li></ul><p>Using this approach, Choreographies can be recursively combined to support choreographies of any required complexity allowing more flexibility as Choreographies defined elsewhere can be reused.</p></div><div class="div3">
<h4><a id="importstatements" name="importstatements"></a>3.3.2 Import Statements</h4><p>An <em>Import </em>statement can contain references to a complete Choreography or part of a Choreography.</p><p>
<em>Import </em>statements must be interpreted in the sequence they occur.</p><p>When the <em>Import </em>statement contains references to variables or other data that have the same identity, then the content of the later <em>Import </em>statement replaces the same content referenced by the earlier <em>Import </em>statement.</p><p>This means, for example, that if an initial Choreography definition referenced by an <em>Import</em> statement contained variables, etc, that were defined in an Abstract way, then the replacement definition could either be Portable or Concrete.</p><p>It also enables one Choreography definition to effectively be "cloned" by replacing the definitions for some or all of its variables.</p><div class="issue"><p class="prefix"><a id="CCI-01" name="CCI-01"></a><b>Issue (CCI-01):</b></p><p>How are definitions identified as being the same and therefore should be overridden</p><p class="prefix"><b>Resolution:</b></p><p>None recorded.</p></div><div class="issue"><p class="prefix"><a id="CCI-02" name="CCI-02"></a><b>Issue (CCI-02):</b></p><p>Import statements need to apply at potentially other points within the choreography apart from the top level?</p><p class="prefix"><b>Resolution:</b></p><p>None recorded.</p></div></div></div><div class="div2">
<h3><a id="typesvariablesandtokens" name="typesvariablesandtokens"></a>3.4 Types, Variables and Tokens</h3><p>
<em>Variables </em>contain information about objects in the choreography such as the messages exchanged or the state of the <em>Roles </em>involved. <em>Tokens </em>are aliases that can be used to reference parts of a <em>Variable</em>. Both <em>Variables </em>and <em>Tokens </em>have <em>Types </em>that define the structure of what the <em>Variable </em>or <em>Token </em>contains.</p><p>The diagram below shows the model for Types, Variables and Tokens:</p><img src="figure5.png" alt="Model for Types, Variables and Tokens"><p>
<em>Figure 5: Model for Types, Variables and Tokens</em>
</p><div class="div3">
<h4><a id="types" name="types"></a>3.4.1 Types</h4><div class="div4">
<h5><a id="variabletypes" name="variabletypes"></a>3.4.1.1 Variable Types</h5><p>Variable Types describe the type of information that is being captured within a Variable at a Role. The type of information that is referenced will vary depending on the type of the Choreography and the type of information that the variable contains.;</p><table border="1" frame="border"><thead><tr><th>
Choreography Type
</th><th>
Variable Type
</th></tr></thead><tbody><tr><td>
<em>Abstract</em>
</td><td>
In an Abstract Choreography, the Variable Type is described by:
<ul><li><p>A unique identifier, e.g. a URI, that identifies the variable type and</p></li><li><p>A semantic definition that explains the purpose of the variable type and outlines its content.</p></li></ul>
No detail is provided of the actual type, e.g. XSD definitions
</td></tr><tr><td>
<em>Portable</em>
</td><td>
In a Portable Choreography the Variable Type extends the Abstract Variable Type by defining its XML Schema Type. Note that this may be simple or complex depending on the need.
</td></tr><tr><td>
<em>Concrete</em>
</td><td>
In a Concrete Choreography, Variable Type is defined in the same way as for a Portable Choreography
</td></tr></tbody></table><div class="issue"><p class="prefix"><a id="TVT-01" name="TVT-01"></a><b>Issue (TVT-01):</b></p><p>Should this be extended to include other items such as SOAP headers, security, etc when the Variable is describing a Message?</p><p class="prefix"><b>Resolution:</b></p><p>None recorded.</p></div></div><div class="div4">
<h5><a id="channeltypes" name="channeltypes"></a>3.4.1.2 Channel Types</h5><p>A Channel identifies where and how to send information to the To Role. Additionally, it identifies what is the allowed Channel information that can be passed to the To Role and the usage of a Channel within a participant.</p><p>The content varies depending on the type of the choreography:;</p><table border="1" frame="border"><thead><tr><th>
Choreography Type
</th><th>
Channel
</th></tr></thead><tbody><tr><td>
<em>Abstract</em>
</td><td>
In an Abstract Choreography, the Channel Type is described by:
<ul><li><p>A unique identifier, e.g. a URI that identifies the Channel Type within the Role</p></li><li><p>A semantic definition, that describes the type of channel information that the Channel can accept. Including:</p><ul><li><p>What channel information can be passed using this channel type</p></li><li><p>How a channel should be used</p></li></ul></li></ul>
</td></tr><tr><td>
<em>Portable</em>
</td><td>
In a Portable Choreography, the abstract Channel Type is extended by identifying:
<ul><li><p>One or more WSDL Service Interfaces that collectively implement the channel type.</p></li><li><p>How Correlation of the messages sent using the Channel Type is to be done</p></li></ul>
</td></tr><tr><td>
<em>Concrete</em>
</td><td>
Channel Types in a Concrete Choreography are defined in the same way as for a Portable Choreography.
</td></tr></tbody></table></div></div><div class="div3">
<h4><a id="variables" name="variables"></a>3.4.2 Variables</h4><p>Variables capture information about objects in a Choreography. They have the following usages as defined by the <em>Variable Usage</em>:</p><ul><li><p>
<em>Information Exchange Variables</em> that contain information such as an Order that is used to:</p><ul><li><p>Populate the content of a message to be sent, or</p></li><li><p>Populated as a result of a message received</p></li></ul></li><li><p>
<em>State Variables </em>that contain information about the State of a Role as a result of information exchanged. For example:</p><ul><li><p>When a Buyer sends an order to a Seller, the Buyer could have a <em>State Variable </em>called "OrderState" set to a value of "OrderSent" and once the message was received by the Seller, the Seller could have an <em>State Variable </em> called "OrderState" set to a value of "OrderReceived". Note that the variable "OrderState" at the Buyer is a different variable to the "OrderState" at the Seller</p></li><li><p>Once an order is received, then it might be validated and checked for acceptability in other ways that affect how the choreography is performed. This could require additional states to be defined for "Order State", such as: "OrderError", which means an error was detected that stops processing of the message, "OrderAccepted", which means that there were no problems with the Order and it can be processed, and "OrderRejected", which means, although there were no errors, it cannot be processed, e.g. because a credit check failed.</p></li></ul></li><li><p>
<em>Channel Variables</em> that contain information that describes how and where a message is sent to a Role. For example, a Channel Variable could contain information such as the URL to which the message should be sent, the policies that are to be applied, such as security, whether or not reliable messaging is to be used, etc.</p></li><li><p>
<em>Other Variables</em> including</p><ul><li><p>
<em>Locally Defined Variables </em>that contain information created and changed locally by a Role. They can be Information Exchange, State or Channel Variables as well as variables of other types. For example "Maximum Order Amount" could be data created by a seller that is used together with an actual order amount from an Order received to control the flow of the choreography. In this case how Maximum Order Amount is calculated and its value would not be known by the other Roles</p></li><li><p>
<em>Common Variables</em> that contain information that is common knowledge to two or more Roles, e.g. "OrderResponseTime" which is the time in hours in which a response to an Order must be sent</p></li></ul></li></ul><p>The value of Variables can be:</p><ul><li><p>Known by all the roles prior to the start of the choreography</p></li><li><p>Assigned by one role and optionally communicated to other roles</p></li><li><p>Assigned as a result of an interaction</p></li><li><p>Assigned by one role from other information</p></li><li><p>Used to determine the decisions and actions to be taken in a Choreography. </p></li></ul><p>The way Variables are defined will vary depending on the type of choreography.;</p><table border="1" frame="border"><thead><tr><th>
Choreography Type
</th><th>
Variables
</th></tr></thead><tbody><tr><td>
<em>Abstract</em>
</td><td>
In an abstract choreography, variables are described by:
<ul><li><p>An Role name that identifies the role within which the variable is known</p></li><li><p>A name that identifies the variable, that is unique within the Role within the Choreography Definition </p></li><li><p>A semantic definition, that describes what the variable means</p></li></ul>
</td></tr><tr><td>
<em>Portable</em>
</td><td>
In a portable choreography, the abstract definition of the Variables is extended to include a Variable Type, which define what type of information the variable contains
</td></tr><tr><td>
<em>Concrete</em>
</td><td>
Variables in a Concrete Choreography are defined in the same way as for a Portable Choreography.
</td></tr></tbody></table><div class="issue"><p class="prefix"><a id="TVT-02" name="TVT-02"></a><b>Issue (TVT-02):</b></p><p>How could (or should) we combine variables of the form, e.g. "Account Balance + Order Amount" so that it could be compared with "Credit Limit"
</p><p class="prefix"><b>Resolution:</b></p><p>None recorded.</p></div><div class="div4">
<h5><a id="variablesandabstractconcretechoreographies" name="variablesandabstractconcretechoreographies"></a>3.4.2.1 Variables and Abstract/Concrete Choreographies</h5><p>Defining Variables to hold information about the objects in a Choreography means that:</p><ul><li><p>Variables contain all the information about a Choreography that can change from implementation to implementation</p></li><li><p>The definition of the sequence and conditions in which information is exchanged is independent of how those information exchanges are actually implemented</p></li><li><p>As new methods are developed for defining interfaces, messages, as well as other Web Services standards, only the way the variables are defined should need to change. The essence of the choreography, i.e. the basic definition of the sequence and conditions in which information is exchanged, remains the same.</p></li></ul><p>In addition the <em>Import </em>statement also allows definitions in one choreography, to be over-ridden by other, replacement definitions. This means that:</p><ul><li><p>The same choreography can be reused in different contexts with different interfaces, message types and varying levels of detail as required</p></li><li><p>The <em>Abstraction Level </em>of the variables can change as required from abstract through to concrete</p></li><li><p>The definitions of the variables in an "abstract" choreography can be used as a checklist to validate that any replacement definitions at either the Portable or Concrete levels form a complete list.</p></li></ul></div></div><div class="div3">
<h4><a id="tokens" name="tokens"></a>3.4.3 Tokens</h4><p>A Token is an alias for a piece of data in a variable or message that needs to be used by a Choreography. Tokens differ from Variables in that Variables contain values whereas Tokens contain information that defines how to access the piece of the data that is relevant. </p><p>For example a Token for "Order Amount" within an Order business could be an alias for an expression that pointed to the Order Amount element within an XML document. This could then be used as part of a condition that controls the flow of a choreography, for example "Order Amount gt; $1000"
</p><p>All tokens may have a type, for example, an Order Amount would be of type amount, Order Id could be alphanumeric and counter an integer.</p><p>The way these tokens are defined will vary depending on the type of choreography.;</p><table border="1" frame="border"><thead><tr><th>
Choreography Type
</th><th>
Tokens
</th></tr></thead><tbody><tr><td>
<em>Abstract</em>
</td><td>
In an abstract choreography, tokens are described by:
<ul><li><p>A unique identifier, e.g. a URI that identifies the token</p></li><li><p>A semantic definition, that describes what the token means</p></li></ul>
However Abstract tokens do not have a type.
</td></tr><tr><td>
<em>Portable</em>
</td><td>
In a portable choreography, a token extends an Abstract definition of a token by defining:
<ul><li><p>Its type, e.g. by giving it an XML Schema type</p></li><li><p>A reference to the location of the item, for example using an XML Path expression</p></li></ul>
</td></tr><tr><td>
<em>Concrete</em>
</td><td>
Tokens in a Concrete Choreography are defined in the same way as for a Portable Choreography.
</td></tr></tbody></table></div></div><div class="div2">
<h3><a id="interactions" name="interactions"></a>3.5 Interactions</h3><p>The diagram below shows the model for <em>Interactions</em>.</p><img src="figure6.png" alt="Model for Interactions"><p>
<em>Figure 6: Model for Interactions</em>
</p><p>An <em>Interaction</em> always involves the exchange of information between two Roles in a Relationship that conform to a Message Exchange Pattern as defined by WSDL 1.2. This means an Interaction can be one of two types:</p><ul><li><p>A <em>One-Way Interaction</em> that involves the sending of single message,</p></li><li><p>A <em>Request-Response Interaction</em> when two messages are exchanged. </p></li></ul><p>An Interaction also contains "references" to:</p><ul><li><p>The <em>From Role</em> and <em>To Role </em> that are involved</p></li><li><p>The <em>Message Content Type </em>that is being exchanged</p></li><li><p>The <em>Information Exchange Variables </em>at the From Role and To Role that are the source and destination for the <em>Message Content</em>
</p></li><li><p>The <em>Channel Variable </em>that specifies the interface and other data that describe where and how the message is to be sent</p></li><li><p>The <em>Operation </em>that specifies what the recipient of the message should do with the message when it is received</p></li><li><p>A list of potential <em>States Changes </em>that can occur and may be aligned at the <em>From Role </em>and the <em>To Role </em>as a result of carrying out the Interaction.</p></li></ul><p>Each of these is described below.</p><div class="issue"><p class="prefix"><a id="I-01" name="I-01"></a><b>Issue (I-01):</b></p><p>The model diagram does not describe how error responses are handled</p><p class="prefix"><b>Resolution:</b></p><p>None recorded.</p></div><div class="div3">
<h4><a id="interactionroles" name="interactionroles"></a>3.5.1 Interaction Roles</h4><p>Interactions always have a "direction" in that there is a <em>From Role</em> that sends the original message and a <em>To Role</em> that receives the message. In the case of a request/response MEP, the "To Role" will also send a response message back to the "From Role". </p></div><div class="div3">
<h4><a id="interactionmessagecontent" name="interactionmessagecontent"></a>3.5.2 Interaction Message Content</h4><p>
<em>Message Content </em>identifies the type of information that is exchanged between the roles and the <em>Information Exchange Variables </em>used as follows:</p><ul><li><p>
<em>One Way From Message </em>is the variable that is the source for a One-Way Message at the <em>From Role</em>
</p></li><li><p>
<em>One Way To Message</em> is the variable that is the destination for a One-Way Message at the <em>To Role</em>
</p></li><li><p>
<em>Request From Message </em>is the variable that is the source for Request Message at the <em>From Role</em>
</p></li><li><p>
<em>Request To Message </em>is the variable that is the destination for Request Message at the <em>To Role</em>
</p></li><li><p>
<em>Response To Message </em>is the variable that is the source for Response Message at the <em>To Role</em>
</p></li><li><p>
<em>Response From Message </em>is the variable that is the destination for Response Message at the <em>From Role</em>
</p></li></ul><p>The type of information that is referenced will vary depending on the type of the Choreography.;</p><table border="1" frame="border"><thead><tr><th>
Choreography Type
</th><th>
Message Content
</th></tr></thead><tbody><tr><td>
<em>Abstract</em>
</td><td>
In an Abstract Choreography, the message content that is exchanged is described by:
<ul><li><p>A unique identifier, e.g. a URI, that identifies the message content and</p></li><li><p>A semantic definition that explains the purpose of the message and outlines its content.</p></li></ul>
No detail is provided of the actual message content, e.g. XSD definitions
</td></tr><tr><td>
<em>Portable</em>
</td><td>
In a Portable Choreography, the Abstract definition of Message Content is extended to include a WSDL Message Type or an XSD element type
</td></tr><tr><td>
<em>Concrete</em>
</td><td>
In a Concrete Choreography, Message Content is defined in the same way as for a Portable Choreography
</td></tr></tbody></table><div class="issue"><p class="prefix"><a id="I-02" name="I-02"></a><b>Issue (I-02):</b></p><p>Should Portable Choreography message content be extended to include other items such as SOAP headers, security, etc or should this be included in the Channel?</p><p class="prefix"><b>Resolution:</b></p><p>None recorded.</p></div></div><div class="div3">
<h4><a id="interactionchannelvariables" name="interactionchannelvariables"></a>3.5.3 Interaction Channel Variables</h4><p>A Channel Variable contains information on where and how to send information to a specific instance of the To Role. This is because Concrete Channel information plus Correlation information about a Choreography contains sufficient information to identify how to send messages to a specific instance of a process.</p><p>Additionally, Channel Variable information can be passed within Message Content. This allows the destination for messages in a choreography to be determined dynamically.</p><p>For example, a Buyer could specify Channel information to be used for sending delivery information. The Buyer could then send the Channel information to the Seller who then forwards it to the Shipper. The Shipper could then send delivery information directly to the Buyer using the Channel Information originally supplied by the Buyer.</p><p>The content varies depending on the type of the choreography.;</p><table border="1" frame="border"><thead><tr><th>
Choreography Type
</th><th>
Channel
</th></tr></thead><tbody><tr><td>
<em>Abstract</em>
</td><td>
In an Abstract Choreography, the channel is described by:
<ul><li><p>A unique identifier, e.g. a URI that identifies the Channel within the Role</p></li><li><p>A semantic definition, that describes the type of channel information that the Channel can accept</p></li></ul>
</td></tr><tr><td>
<em>Portable</em>
</td><td>
In a Portable Choreography, the abstract channel is extended by identifying its Channel Type, which defines what type of information the variable contains.
</td></tr><tr><td>
<em>Concrete</em>
</td><td>
In a concrete choreography, the channel extends a portable channel by adding end point information for each interface such as complex Service References or simple URIs, digital certificates etc.
</td></tr></tbody></table><p>At run time, information about a channel variable is expanded further. This requires that the messages in the Choreography also contain Correlation information, for example by including:</p><ul><li><p>A SOAP header that specifies the correlation data to be used with the Channel, or </p></li><li><p>Using the actual value of data within a message, for example the Order Number of the Order that is common to all the messages sent over the Channel</p></li></ul><p>In practice, when a Choreography is performed, several different ways of doing correlation may be employed which vary depending on the <em>Channel Type</em>.</p></div><div class="div3">
<h4><a id="interactionoperations" name="interactionoperations"></a>3.5.4 Interaction Operations</h4><p>An Operation specifies the particular part of an interface that is the target for a message. The content varies depending on the type of choreography.;</p><table border="1" frame="border"><thead><tr><th>
Choreography Type
</th><th>
Interaction
</th></tr></thead><tbody><tr><td>
<em>Abstract</em>
</td><td>
In an abstract choreography, an operation is described by a unique name within the Interface within the Channel
</td></tr><tr><td>
<em>Portable</em>
</td><td>
In a portable choreography, an operation is described referencing a WSDL one-way or request-response Operation
</td></tr><tr><td>
<em>Concrete</em>
</td><td>
Same as portable.
</td></tr></tbody></table></div><div class="div3">
<h4><a id="interactionstatechanges" name="interactionstatechanges"></a>3.5.5 Interaction State Changes</h4><p>States contain information about the State of a Role as a result of information exchanged in the form of an <em>Interaction</em>. For example after an Interaction where an order is sent by a Buyer to a Seller, the Buyer could create the <em>State Variable </em>
"Order State" and assign the value "Sent" when the message was sent, and when the Seller received the order, the Seller could also create its own version of the "Order State"
<em>State Variable </em>and assign it the value "Received".</p><p>As a result of a State Change, several different outcomes are possible which can only be determined at run time. The <em>Interaction</em> lists each of these allowed <em>State Changes</em>, for example when an order is sent from a Buyer to a Seller the outcomes could be one of the following <em>State Changes</em>:</p><ol class="enumar"><li><p>Buyer.OrderState = Sent, Seller.OrderState = Received</p></li><li><p>Buyer.OrderState = SendFailure, Seller.OrderState not set</p></li><li><p>Buyer.OrderState = AckReceived, Seller.OrderState = OrderAckSent</p></li></ol></div><div class="div3">
<h4><a id="interactionbasedalignment" name="interactionbasedalignment"></a>3.5.6 Interaction Based Alignment</h4><p>In some choreographies there may be a requirement that, at the end of an Interaction, the Roles in the Choreography have agreement of the outcome. More specifically within an Interaction, a Role needs to have a common understanding of the state changes of one or more<em> State Variables</em> that are complimentary to one or more <em>State</em>
<em>Variables</em> of its partner Role. Additionally within an Interaction, a Role needs to have a common understanding of the values of the <em>Information Exchange Variables </em>at the partner Role.</p><p>Without alignment the Buyer knows that her "OrderState" is set to "Sent", but does not know the value of the OrderState at the Seller. Once the Seller receives the Order then the Seller knows that his "OrderState" variable is set to "Received". He also knows the Buyers "OrderState" was set to "Sent", as the Choreography defines that the Buyer's Order State variable is set in this way when an Order is sent.</p><p>With Choreography Alignment the difference is that both the Buyer and the Seller have:</p><ul><li><p>State Variables such as Order State variables at the Buyer and Seller, that have Values that are complementary to each other, e.g. Sent at the Buyer and Received at the Seller, and</p></li><li><p>Knowledge of the values of each others States Variables, i.e. the Buyer knows that the Seller's "OrderState" variable has the value "Received" and the Seller knows that the Buyer's "OrderState" variable is set to "Sent"
</p></li><li><p>Information Exchange Variables that have the same types with the same content, e.g. The Order variables at the Buyer and Seller have the same Variable Types and hold the same order</p></li></ul><p>This assurance of the outcome with respect to States is achieved by an "agreement" protocol that is used in conjunction with the Choreography such as the Web Services and other specifications designed to coordinate long-running transactions.</p></div><div class="div3">
<h4><a id="protocolbasedinformationexchanges" name="protocolbasedinformationexchanges"></a>3.5.7 Protocol Based Information Exchanges</h4><p>The <em>One-Way</em>, <em>Request </em>or <em>Response </em>messages in an Interaction may also be implemented using a <em>Protocol Based Exchange </em>where a series of messages are exchanged according to some well-known protocol, such as the reliable messaging protocols defined in specifications such as WS Reliability.</p><p>In both cases, the same or similar <em>Message Content </em>may be exchanged as in a simple Interaction, for example the sending of an Order between a Buyer and a Seller. Therefore some of the same <em>State Changes </em>may result.</p><p>However when protocols such as the reliable messaging protocols are used, additional <em>State Changes</em> will occur. For example, if a reliable messaging protocol were being used then the Buyer, once confirmation of delivery of the message was received, would also know that the Seller's "Order State" variable was in the state "Received" even though there was no separate Interaction that described this.</p><div class="issue"><p class="prefix"><a id="I-03" name="I-03"></a><b>Issue (I-03):</b></p><p>Do we add additional standard states to describe the outcomes of using reliable messaging protocols? Similarly, should we include additional states to handle other outcomes, such as security failures?</p><p class="prefix"><b>Resolution:</b></p><p>None recorded.</p></div><div class="issue"><p class="prefix"><a id="I-04" name="I-04"></a><b>Issue (I-04):</b></p><p>Do we want to specify standard "reusable" names for the State Variable values for the common states associated with Interactions, e.g. for an Interaction you could have "Sent", "Received", "SendFailure", etc</p><p class="prefix"><b>Resolution:</b></p><p>None recorded.</p></div></div></div><div class="div2">
<h3><a id="activitiesandcontrolstructures" name="activitiesandcontrolstructures"></a>3.6 Activities and Control Structures</h3><p>The diagram below shows the model for Activities ...</p><img src="figure7.png" alt="Model for Activities"><p>
<em>Figure 7: Model for Activities</em>
</p><p>... and this diagram shows the model for Control Structures ...</p><img src="figure8.png" alt="Model for Control Structures"><p>
<em>Figure 8: Model for Control Structures</em>
</p><p>
<em>Activities </em>are the lowest level components of the Choreography which do the actual work, such as the Interactions described earlier or the performance of other Choreographies. </p><p>
<em>Control Structures </em>combine these <em>Activities </em>with other <em>Control Structures </em>in a nested way to specify the sequence and flow of the exchange of information within the Choreography.</p><p>However at the highest level, the Choreographies consist of <em>Work Units</em>, that each contain a single Activity that is performed whenever an optional enabling condition on the <em>Work Unit</em>, called a <em>Guard</em>, is true.</p><p>Each <em>Activity </em>within a Work Unit is then either:</p><ul><li><p>A <em>Basic Activity </em>that does the actual work. These are:</p><ul><li><p>An <em>Interaction</em>, i.e. the Work Unit consists of a single Interaction as described earlier</p></li><li><p>A <em>Perform, </em>which means that a complete, separately defined choreography is performed</p></li><li><p>An <em>Assign</em>, which assigns, within one Role, the value of one Variable to the value of a Variable or Token, or makes a Token reference a Variable or another Token</p></li><li><p>
<em>No Action</em>, which means that the Choreography should take no particular action at that point</p></li></ul></li><li><p>
<em>Control Structures </em>that group Basic Activities and Control Structures together in a nested structure to express the logic and decision flow involved in the Choreography. The Control Structures are:</p><ul><li><p>
<em>Sequence</em>, which specifies a list of Activities that are performed in sequence</p></li><li><p>
<em>Choice</em>, which specifies that just one of two or more Activities are performed depending on the condition on a Guard</p></li><li><p>
<em>Parallel</em>, which means that all the Activities are performed at the same time.</p></li></ul></li></ul><p>Note that an <em>Activity </em>is a modeling concept that would not appear in an XML equivalent of a Choreography definition. However it is needed to allow the Sequence, Choice and Parallel <em>Activities </em>to contain other <em>Activities </em>in a nested structure that allows the specification of <em>Work Units </em>that contain multiple <em>Activities </em>to be created.</p><p>Each of the ideas above, apart from Interaction, which was described earlier, is described in more detail below.</p><div class="div3">
<h4><a id="workunits" name="workunits"></a>3.6.1 Work Units</h4><p>Each Work Unit has two optional conditions or guards associated with it:</p><ul><li><p>An <em>Enabling Condition</em>, which specifies a combination of states that must be available and also evaluate to true before the Work Unit can be performed, and</p></li><li><p>A <em>Repeat Condition</em> that specifies a combination of states that, if they evaluate to true once the Work Unit is complete, means that the enabling condition of the Work Unit (if specified) is re-checked.</p></li></ul><p>Examples of a Work Unit include:</p><ul><li><p>A <em>Send PO </em>Work Unit that includes Interactions for the Buyer to send an Order, the Supplier to acknowledge the order, and then later accept (or reject) the order. This work unit would probably not have a guard</p></li><li><p>An <em>Order Delivery Error</em> Work Unit that is performed whenever the <em>Place Order</em> Work Unit did not reach a "normal" conclusion. This would have a Guard condition that identifies the error, see also Choreography Exceptions and Transactions</p></li><li><p>A <em>Change Order</em> Work Unit that can be performed whenever an order acknowledgement message has been received and an order rejection has not been received.</p></li></ul><div class="issue"><p class="prefix"><a id="ACS-01" name="ACS-01"></a><b>Issue (ACS-01):</b></p><p>How do you limit the number of repetitions of a work unit to a specific number where the number is fixed, or where the number of repetitions varies by instance or dependent on some "Locally Defined variable".</p><p class="prefix"><b>Resolution:</b></p><p>None recorded.</p></div></div><div class="div3">
<h4><a id="performedchoreography" name="performedchoreography"></a>3.6.2 Performed Choreography</h4><p>The Performed Choreography Structure enables a Choreography to define that a separately defined Choreography is to be performed. The Choreography that is performed can be defined either within the same Choreography Definition or separately.</p><div class="issue"><p class="prefix"><a id="ACS-02" name="ACS-02"></a><b>Issue (ACS-02):</b></p><p>Should variables be used to define:</p><ul><li><p>How Message Content is passed to (or from) the performed choreogaphy</p></li><li><p>How state information is passed to (or from) a performed choreography </p></li></ul><p class="prefix"><b>Resolution:</b></p><p>None recorded.</p></div></div><div class="div3">
<h4><a id="assign" name="assign"></a>3.6.3 Assign</h4><p>Assign sets, within one Role, the value of one Variable to the value of a Variable or Token, or makes a Token reference a Variable or another Token. The assignments may include:</p><ul><li><p>Assigning one <em>Information Exchange Variable</em> to another, for example so that a Choreography can define that a message received by one role is forwarded to another</p></li><li><p>Assigning a <em>Locally Defined Variable </em>to part of the data contained in an Information Exchange Variable</p></li></ul></div><div class="div3">
<h4><a id="noaction" name="noaction"></a>3.6.4 NoAction</h4><p>This <em>Activity </em>means that the choreography at this point should take no particular action. Examples of its use include:</p><ul><li><p>In a <em>Work Unit</em>, when there is a need to wait until the Guard condition on the <em>Work Unit</em> is true, for example you need to wait until say three separate Interactions are complete before progressing to the next step in the Choreography</p></li><li><p>In a <em>Choice </em>so that you can enumerate all the possible choices even if some of the choices involve no Interactions.</p></li></ul></div><div class="div3">
<h4><a id="sequencecontrolstructure" name="sequencecontrolstructure"></a>3.6.5 Sequence Control Structure</h4><p>The Sequence Control Structure enables a <em>Work Unit</em> to define that one or more Activities must be performed in sequence. It works by grouping the <em>Activities</em> within a lt;Sequencegt; ... lt;/Sequencegt;</p><p>
<em>Activities </em>must be performed in the same sequence that they are defined.</p></div><div class="div3">
<h4><a id="choicecontrolstructure" name="choicecontrolstructure"></a>3.6.6 Choice Control Structure</h4><p>The Choice Control structure enables a <em>Work Unit</em> to define that only one of two or more Activities should be performed. It works by:</p><ul><li><p>Grouping the <em>Work Units</em> within a lt;Choicegt; ... lt;/Choicegt;</p></li><li><p>Adding a Guard statement to each individual Activity within the Choice.</p></li></ul><p>An Activity<em> </em>should only occur if the Guard on the Activity evaluates to true. Once one of the <em>Activities </em>in the Choice have been performed, then no other <em>Activities</em> in the Choice must be performed.</p></div><div class="div3">
<h4><a id="parallelcontrolstructure" name="parallelcontrolstructure"></a>3.6.7 Parallel Control Structure</h4><p>The Parallel Control Structure enables a <em>Work Unit</em> to define that Activities are performed in parallel. It works by grouping the Activities within a lt;Parallelgt; ... lt;/Parallelgt;</p></div></div><div class="div2">
<h3><a id="choreographyexceptionsandtransactions" name="choreographyexceptionsandtransactions"></a>3.7 Choreography Exceptions and Transactions</h3><p>The diagram below shows the model for Choreography Exceptions and Transactions.</p><img src="figure9.png" alt="Model for Exceptions and Transactions"><p>
<em>Figure 9: Model for Exceptions and Transactions</em>
</p><p>Choreographies are the unit for recovery purposes. This means that the Choreography should provide:</p><ul><li><p>
<em>Exception Handling </em>so that Information Exchanges can be defined that are to be followed when an unexpected condition occurs while the Choreography is being performed</p></li><li><p>
<em>Transaction Handling </em>so that one Choreography can perform another Choreography up to a suitable point and then later perform the Choreography again to compensate for its effects.</p></li></ul><p>To handle both of these a Choreography may contain an optional <em>Recovery Block</em> which contains one or both of:</p><ul><li><p>An <em>Exception Block</em>, that contains one or more <em>Work Units </em>with guards. If some exceptional circumstance occurs when the Choreography is performed one of the Work Units will be followed</p></li><li><p>A <em>Transaction Block</em>, that contains a single <em>Work Unit</em> that is followed when the effects of the Choreography need to be reversed</p></li></ul><p>Note however, that although recovery from errors can be defined, depending on the nature of the choreography and the problem that occurs, recovery, in practice may not be possible.</p><div class="div3">
<h4><a id="exceptionblock" name="exceptionblock"></a>3.7.1 Exception Block</h4><p>A Choreography can sometimes fail as a result of an exceptional circumstance or error. Different types of exceptions are possible including this non-exhaustive list:</p><ul><li><p>
<em>Interaction Failures</em>, for example the sending of a message did not occur</p></li><li><p>
<em>Protocol Based Exchange failures</em>, for example no acknowledgement was received as part of a reliable messaging protocol</p></li><li><p>
<em>Security failures</em>, for example a Message was rejected by a recipient because the digital signature was not valid</p></li><li><p>
<em>Choreography Sequence Failures</em>, for example a Message was received that was not in the sequence as defined by the Choreography</p></li><li><p>
<em>Timeout errors</em>, for example an Interaction did not complete within a required timescale</p></li><li><p>
<em>Validation Errors</em>, for example an XML order document was not well formed or did not conform to its schema definition</p></li><li><p>
<em>Business Process "failures"
</em>, for example the goods ordered were out of stock.</p></li></ul><p>To handle these and other "errors" separate Work Units are defined in the <em>Exception Block </em>for each "exception" condition (as identified by its guards) that needs to be handled. Only one Work Unit per exception should be performed.</p><div class="issue"><p class="prefix"><a id="CET-01" name="CET-01"></a><b>Issue (CET-01):</b></p><p>What happens if you get an error in a Work Unit that is within an Exception Block</p><p class="prefix"><b>Resolution:</b></p><p>None recorded.</p></div><div class="issue"><p class="prefix"><a id="CET-02" name="CET-02"></a><b>Issue (CET-02):</b></p><p>What happens if you get an error condition for which no Work Unit in an Exception Block is specified</p><p class="prefix"><b>Resolution:</b></p><p>None recorded.</p></div><div class="issue"><p class="prefix"><a id="CET-03" name="CET-03"></a><b>Issue (CET-03):</b></p><p>Should you be able to resume a choreography where the exception occurred if the exception block managed, for example, to fix the problem</p><p class="prefix"><b>Resolution:</b></p><p>None recorded.</p></div><div class="issue"><p class="prefix"><a id="CET-04" name="CET-04"></a><b>Issue (CET-04):</b></p><p>How do you indicate that the choreography completed with an error if the choreography is being performed</p><p class="prefix"><b>Resolution:</b></p><p>None recorded.</p></div><div class="issue"><p class="prefix"><a id="CET-05" name="CET-05"></a><b>Issue (CET-05):</b></p><p>Do we need "special" standard conditions/states that correspond to such things as "choreography out of sequence" that are choreography language specific</p><p class="prefix"><b>Resolution:</b></p><p>None recorded.</p></div><div class="issue"><p class="prefix"><a id="CET-06" name="CET-06"></a><b>Issue (CET-06):</b></p><p>What does exception matching in the Work Unit guard condition?</p><p class="prefix"><b>Resolution:</b></p><p>None recorded.</p></div><div class="issue"><p class="prefix"><a id="CET-07" name="CET-07"></a><b>Issue (CET-07):</b></p><p>Do we want to allow "catch all" conditions in Work Units in an Exception Block so that you can define the behavior of the Choreography when common but unlikely errors occur? For example, you could have an enabling condition that looked something like "*.StateVariable=SendFailure".</p><p class="prefix"><b>Resolution:</b></p><p>None recorded.</p></div></div><div class="div3">
<h4><a id="transactionblock" name="transactionblock"></a>3.7.2 Transaction Block</h4><p>Transaction handling allows one Choreography to perform another Choreography up to a suitable point and then later perform the Choreography again to compensate for its effects.</p><p>For example, a Choreography could exist that supported the purchasing of a property that involved exchanging information between many Roles including: a Purchaser who was buying the property, a Seller who was selling the property, a Buyers Agent who was advising the Purchaser, a Bank that was going to provide a mortgage, and a Title Company to prepare all the legal documents and handle the transfer of the actual moneys.</p><p>Only when the purchase was completed, could the choreography fully complete, and if the purchase fell through, then the effects of the Choreography would need to be reversed at each Role.</p><p>The Choreography model supports this type of example by defining a <em>Transaction Block</em> that contains one Work Unit that is followed when the effects of the Choreography need to be reversed.</p><p>In the example given above, this would work by defining a Choreography that: </p><ul><li><p>Performs one Choreography to carry out the main part of the process of creating and exchanging information required for the transaction</p></li><li><p>Waits until the critical messages have been received that indicate that the transaction is either going to go ahead or fail</p></li><li><p>Performs the main choreography again indicating that the effect of the Choreography should be Compensated by performing a <em>Work Unit </em>in the <em>Transaction Block</em>.</p></li></ul></div></div><div class="div2">
<h3><a id="semantics" name="semantics"></a>3.8 Semantics</h3><p>Although not shown on this model, descriptions will be required to allow the recording of semantics definitions. In principle, this will be supported by including a <em>Description</em> structure in the definition of almost every single component within the model.</p><p>This <em>Description</em> structure will allow for the recording of semantics in any or all of the following ways:</p><ul><li><p>
<em>Text.</em> This will be in plain text or possibly HTML and should be brief.</p></li><li><p>
<em>Document Reference</em>. This will contain a URL to a document that more fully describes the component. For example on the top level Choreography Definition that might reference a complete paper</p></li><li><p>
<em>Structured Attributes.</em> This will contain a machine processable definition in languages such as RDF or OWL.</p></li></ul><p>
<em>Descriptions </em>that are <em>Text </em>or <em>Document References </em>can be defined in multiple different human readable languages.</p><div class="issue"><p class="prefix"><a id="S-01" name="S-01"></a><b>Issue (S-01):</b></p><p>The "document reference" should be a URI, not a URL, that is could also point to other kinds of resources than text documents -- I can imagine businesses that want to use URNs to point to non-web resources, URIs (with the fragids included) to point to parts of documents, etc. Source: Jim Hendler</p><p class="prefix"><b>Resolution:</b></p><p>None recorded.</p></div></div></div></div></body></html>