Business Transaction Protocol · 2004-11-10 · carriage of BTP messages over other communication...

1

ansaction Protocol Business Tr2

3

rking Draft 05, 9 November 2004 4

identifier: 5 6

: 7 8

Editor: 9 Furniss, Choreology Ltd. <mailto:[email protected]> 10

11

Co-auth12 13 14 15

sion 1.1) 16 x Ceponkus, individual (for versions 1.0 and 1.1) 17

18

Abstrac19 20 21 22 23 24 25

chematized in XML. 26 o allows the 27

28 29

ntation choices are avoided. The protocol also tries to avoid unnecessary 30 31

Status: 32 33

ing the TC review of 34 This 35

36 37 38

sis-open.org list. To subscribe, send an email 39 40

41

Version 1.0.9.5

BTP 1.1 Wo

Document business_transaction-btp-1.1-spec-wd-05

Locationhttp://docs.oasis-open.org/business_transaction/

Peter (for versions 1.0 and 1.1)

ors: Sanjay Dalal, BEA Systems (for version 1.0) Tony Fletcher, Choreology Ltd (for version 1.0)

ersion 1.0) Alastair Green, Choreology Ltd (for vBob Haugen, Choreology Ltd. (for verAleBill Pope, individual (for version 1.0)

t: The Business Transaction Protocol (BTP) is a carrier-neutral protocol to allow coordination of application work between multiple autonomous, cooperating participants. It defines protocol exchanges to ensure the overall application achieves a consistent result. This consistency may be defined a priori: all the work is confirmed or none is (an atomic business transaction or atom); or it can be determined by application intervention in the selection of the work to be confirmed (a cohesive business transaction or cohesion). The protocol is defined in terms of abstract messages sThis specification defines communications protocol bindings to SOAP but alscarriage of BTP messages over other communication protocols. BTP is based on a permissive and minimal approach, where constraints on implemedependencies on other standards, with the aim of lowering the hurdle to implementation.

This is working draft 5 of the revision of Committee Specification BTP 1.0 (June 2002), inpreparation for BTP 1.1. This draft includes minor corrections followworking draft 4 – two cells in Table 11, state S1 and colouring of the example xml. text will be submitted for approval as Committee Draft as BTP 1.1. Committee members should send comments on this specification to the [email protected] list. Others should subscribe to and send comments to the [email protected] to [email protected] with the word"subscribe" as the body of the message.

business_transaction-btp-1.1-spec-wd-05 9 November 2004 Copyright © OASIS Open 2002, 2004. All Rights Reserved. of 163

mailto:[email protected]




http://www.oasis-open.org/committees/business-transaction/

http://www.oasis-open.org/committees/business-transaction/

For information on whether implementing this specificat

any patents have been disclosed that may be essential to 42 ion, and any offers of patent licensing terms, please refer to 43

the Intellectual Property Rights section of the Business Transactions TC web page 44 45 (http://www.oasis-open.org/committees/business-transaction/).


Table of Contents 46

In47 1 48 2 49

2.50 2.51

3 52 3.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

3.78 79 80 81 82 83 84

3.85 3.86

87 3.6.2 Addresses .................................................................................................................... 54 88

troduction .......................................................................................................................................8 Structure of this specification ...................................................................................................9 Conventions and terminology ............................................................................................... 11

1 Typographical and Linguistic Conventions and Style ......................................................... 11 2 Glossary .............................................................................................................................. 11 Conceptual Model ................................................................................................................. 18

1 Concepts ............................................................................................................................. 18 3.1.1 Example Core .............................................................................................................. 18 3.1.2 Business transactions .................................................................................................. 19 3.1.3 External Effects............................................................................................................ 20 3.1.4 Two-phase outcome .................................................................................................... 21 3.1.5 Actors and roles ........................................................................................................... 21 3.1.6 Superior:Inferior relationship........................................................................................ 21 3.1.7 Business Transaction Trees ........................................................................................ 22 3.1.8 Atoms and Cohesions.................................................................................................. 24 3.1.9 Participants, Sub-Coordinators and Sub-Composers.................................................. 25

3.2 Business transaction lifecycle ............................................................................................. 25 3.2.1 Business Transaction creation..................................................................................... 25 3.2.2 Business Transaction propagation .............................................................................. 26 3.2.3 Creation of Intermediates (Sub-Coordinators and Sub-Composers) .......................... 27 3.2.4 “Checking” and context-reply....................................................................................... 28 3.2.5 Message sequence...................................................................................................... 29 3.2.6 Control of inferiors........................................................................................................ 33 3.2.7 Evolution of Confirm-set............................................................................................... 36 3.2.8 Confirm-set of intermediates........................................................................................ 40

3.3 Optimisations and variations ............................................................................................... 43 3.3.1 Spontaneous prepared ................................................................................................ 43 3.3.2 One-shot ...................................................................................................................... 43 3.3.3 Resignation .................................................................................................................. 45 3.3.4 One-phase confirmation............................................................................................... 45 3.3.5 Autonomous cancel, autonomous confirm and contradictions .................................... 46

4 Recovery and failure handling............................................................................................. 47 3.4.1 Types of failure ............................................................................................................ 47 3.4.2 Persistent information .................................................................................................. 47 3.4.3 Recovery messages .................................................................................................... 48 3.4.4 Redirection................................................................................................................... 49 3.4.5 Terminator:Decider failures and transaction timelimit ................................................. 50 3.4.6 Contradictions and hazard........................................................................................... 50

5 Relation of BTP to application and Carrier Protocols.......................................................... 52 6 Other elements.................................................................................................................... 53 3.6.1 Identifiers ..................................................................................................................... 53


3.6.3 Qualifiers...................................................................................................................... 54 89 90

4 91 4.92 4.93 4.94

95 96 97 98 99

100 4.101

102 103 104 105 106 107

4.108 109 110

4.111 5 112

5.113 5.114 5.115

116 5.117

118 5.119

120 121 122 123 124 125 126 127 128 129 130 131 132

3.6.4 Lists.............................................................................................................................. 55 Actors, Roles and Relationships........................................................................................... 56

1 Relationships....................................................................................................................... 56 2 Roles ................................................................................................................................... 57 3 Roles involved in the Outcome Relationships..................................................................... 58 4.3.1 Superior........................................................................................................................ 58 4.3.2 Inferior .......................................................................................................................... 59 4.3.3 Enroller......................................................................................................................... 60 4.3.4 Participant .................................................................................................................... 60 4.3.5 Sub-coordinator ........................................................................................................... 61 4.3.6 Sub-composer.............................................................................................................. 61

4 Roles involved in the Control Relationships........................................................................ 61 4.4.1 Decider......................................................................................................................... 61 4.4.2 Coordinator .................................................................................................................. 62 4.4.3 Composer .................................................................................................................... 62 4.4.4 Terminator.................................................................................................................... 62 4.4.5 Initiator ......................................................................................................................... 63 4.4.6 Factory ......................................................................................................................... 63

5 Other roles........................................................................................................................... 64 4.5.1 Redirector .................................................................................................................... 64 4.5.2 Status Requestor ......................................................................................................... 64

6 Summary of relationships.................................................................................................... 65 Abstract Messages and Associated Contracts ..................................................................... 66

1 Addresses ........................................................................................................................... 66 2 Request/response pairs ...................................................................................................... 67 3 Compounding messages .................................................................................................... 67

5.4 Extensibility ......................................................................................................................... 69 5 Messages ............................................................................................................................ 69 5.5.1 Qualifiers...................................................................................................................... 69

6 Messages not restricted to outcome or Control Relationships. .......................................... 70 5.6.1 CONTEXT.................................................................................................................... 70 5.6.2 CONTEXT_REPLY...................................................................................................... 71 5.6.3 REQUEST_STATUS ................................................................................................... 72 5.6.4 STATUS....................................................................................................................... 73 5.6.5 FAULT.......................................................................................................................... 75 5.6.6 REQUEST_INFERIOR_STATUSES, INFERIOR_STATUSES................................... 77

5.7 Messages used in the Outcome Relationships................................................................... 77 5.7.1 ENROL......................................................................................................................... 77 5.7.2 ENROLLED.................................................................................................................. 78 5.7.3 RESIGN ....................................................................................................................... 79 5.7.4 RESIGNED .................................................................................................................. 80 5.7.5 PREPARE.................................................................................................................... 80 5.7.6 PREPARED ................................................................................................................. 81


5.7.7 CONFIRM .................................................................................................................... 82 133 134 135 136 137 138 139 140 141 142

5.143 144 145 146 147 148 149 150 151 152 153

5.154 155 156 157 158 159

5.160 161 162 163 164 165 166

6 167 6.168 6.169 6.170

171 6.172 6.173 6.174 6.175

7 176

5.7.8 CONFIRMED ............................................................................................................... 83 5.7.9 CANCEL ...................................................................................................................... 84 5.7.10 CANCELLED ............................................................................................................. 84 5.7.11 CONFIRM_ONE_PHASE .......................................................................................... 85 5.7.12 HAZARD .................................................................................................................... 86 5.7.13 CONTRADICTION..................................................................................................... 87 5.7.14 SUPERIOR_STATE................................................................................................... 88 5.7.15 INFERIOR_STATE .................................................................................................... 89 5.7.16 REDIRECT................................................................................................................. 91

8 Messages used in Control Relationships............................................................................ 92 5.8.1 BEGIN.......................................................................................................................... 92 5.8.2 BEGUN ........................................................................................................................ 93 5.8.3 PREPARE_INFERIORS .............................................................................................. 94 5.8.4 CONFIRM_TRANSACTION ........................................................................................ 96 5.8.5 TRANSACTION_CONFIRMED ................................................................................... 98 5.8.6 CANCEL_TRANSACTION........................................................................................... 99 5.8.7 CANCEL_INFERIORS............................................................................................... 100 5.8.8 TRANSACTION_CANCELLED ................................................................................. 101 5.8.9 REQUEST_INFERIOR_STATUSES ......................................................................... 102 5.8.10 INFERIOR_STATUSES........................................................................................... 103

9 Groups – combinations of related messages.................................................................... 104 5.9.1 CONTEXT & Application Message ............................................................................ 104 5.9.2 CONTEXT_REPLY & Application Message .............................................................. 105 5.9.3 CONTEXT_REPLY & ENROL ................................................................................... 105 5.9.4 CONTEXT_REPLY (& ENROL) & PREPARED / & CANCELLED ............................ 106 5.9.5 CONTEXT_REPLY & ENROL & Application Message (& PREPARED) .................. 106

10 Standard qualifiers .......................................................................................................... 107 5.10.1 Transaction timelimit ................................................................................................ 107 5.10.2 Inferior timeout ......................................................................................................... 107 5.10.3 Minimum inferior timeout.......................................................................................... 108 5.10.4 Inferior name............................................................................................................ 109 5.10.5 Cancel-on-zero-participants..................................................................................... 109 5.10.6 Expected-time-till-state-change ............................................................................... 110 State Tables........................................................................................................................ 111

1 Status queries ................................................................................................................... 111 2 Decision events ................................................................................................................. 111 3 Disruptions – failure events............................................................................................... 112

6.4 Invalid cells and assumptions of the communication mechanism .................................... 112 5 Meaning of state table events ........................................................................................... 113 6 Persistent information........................................................................................................ 116 7 Superior state table ........................................................................................................... 119 8 Inferior state table.............................................................................................................. 124 Persistent information ......................................................................................................... 130


8 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200

8.2.18 CONTRADICTION................................................................................................... 138 201 8.2.19 SUPERIOR_STATE................................................................................................. 138 202 8.2.20 INFERIOR_STATE .................................................................................................. 138 203 8.2.21 REDIRECT............................................................................................................... 138 204 8.2.22 BEGIN...................................................................................................................... 139 205 8.2.23 BEGUN .................................................................................................................... 139 206 8.2.24 PREPARE_INFERIORS .......................................................................................... 139 207 8.2.25 CONFIRM_TRANSACTION .................................................................................... 140 208 8.2.26 TRANSACTION_CONFIRMED ............................................................................... 140 209 8.2.27 CANCEL_TRANSACTION ...................................................................................... 140 210 8.2.28 CANCEL_INFERIORS............................................................................................. 140 211 8.2.29 TRANSACTION_CANCELLED ............................................................................... 141 212 8.2.30 REQUEST_INFERIOR_STATUSES ....................................................................... 141 213 8.2.31 INFERIOR_STATUSES........................................................................................... 141 214

8.3 Standard qualifiers ............................................................................................................ 142 215 8.3.1 Transaction timelimit .................................................................................................. 142 216 8.3.2 Inferior timeout ........................................................................................................... 142 217 8.3.3 Minimum inferior timeout............................................................................................ 142 218 8.3.4 Inferior name.............................................................................................................. 142 219 8.3.5 Cancel-on-zero-participants....................................................................................... 142 220

XML representation of Message Set .................................................................................. 131 8.1 Field types ......................................................................................................................... 131

8.1.1 Addresses .................................................................................................................. 131 8.1.2 Qualifiers.................................................................................................................... 132 8.1.3 Identifiers ................................................................................................................... 132 8.1.4 Message References................................................................................................. 132

8.2 Messages .......................................................................................................................... 132 8.2.1 CONTEXT.................................................................................................................. 132 8.2.2 CONTEXT_REPLY.................................................................................................... 132 8.2.3 REQUEST_STATUS ................................................................................................. 133 8.2.4 STATUS..................................................................................................................... 133 8.2.5 FAULT........................................................................................................................ 133 8.2.6 ENROL....................................................................................................................... 134 8.2.7 ENROLLED................................................................................................................ 135 8.2.8 RESIGN ..................................................................................................................... 135 8.2.9 RESIGNED ................................................................................................................ 135 8.2.10 PREPARE................................................................................................................ 135 8.2.11 PREPARED ............................................................................................................. 136 8.2.12 CONFIRM ................................................................................................................ 136 8.2.13 CONFIRMED ........................................................................................................... 136 8.2.14 CANCEL .................................................................................................................. 137 8.2.15 CANCELLED ........................................................................................................... 137 8.2.16 CONFIRM_ONE_PHASE ........................................................................................ 137 8.2.17 HAZARD .................................................................................................................. 137


8.3.6 Expected-time-till-state-change ................................................................................. 143 221 8.4 Compounding of Messages .............................................................................................. 143 222

............................................................................................................. 143 223 or BTP messages ............................................................................... 143 224

225 226

144 227 . 145 228

........................................................ 146 229 47 230 49 231

232 151 233

e-way binding................................................................................ 152 234 235

236 237

gments ................................................................................................... 157 238 158 239

240 241

.. 160 242 ... 162 243

............................................ 163 244 245

8.5 XML Schemas ......8.5.1 XML schema f8.5.2 XML schema for standard qualifiers .......................................................................... 143

9 Carrier Protocol Bindings .................................................................................................... 144 9.1 Carrier Protocol Binding Proforma ....................................................................................9.2 Bindings for request/response Carrier Protocols .............................................................

9.2.1 Request/response exploitation rules..................9.3 SOAP Binding ................................................................................................................... 1

9.3.1 Example scenario using SOAP binding..................................................................... 19.4 SOAP + Attachments Binding ........................................................................................... 150

9.4.1 Example using SOAP + Attachments binding ...........................................................9.5 11.5 WSDL-friendly on

10 Conformance....................................................................................................................... 15411 References.......................................................................................................................... 156

11.1 Normative ........................................................................................................................ 156 Appendix A. AcknowledAppendix B. Revision History ......................................................................................................Appendix C. Notices .................................................................................................................... 159Appendix D. Node State Information Serialisation ...................................................................... 160

D.1 Abstract Format for Node State Information ..............................................................D.2 Informal XML for Node State Information..................................................................D.3 XML schema for Node State Information .........................


Introduction 246

multiple participants owned or 247 outcome coordination protocol to 248

249 250 251 252 253

ent. For this reason this specification defines 254 protocol bindings which target the emerging Web Services arena, while 255

TP messages over other communication protocols. Protocol 256 content is 257

c258 P nts. Such 259

sistent reversal of the effects of atoms. For example, BTP participants 260 es, or compensation operations to provide the “roll-261

mic 262 s263

BTP264 265

ed 266 by a267 BTP268 choi269 stan270 The n inaugural meeting in 271

272 m 273

in th274 1.1.275

276 sec277 som278

BTP is designed to allow coordination of application work between controlled by autonomous organizations. BTP uses a two-phaseensure the overall application achieves a consistent result. BTP permits the consistent outcome to be defined a priori: all the work is confirmed or none is (an atomic business transaction or atom) or it can be determined by application intervention into the selection of the work to be confirmed (a cohesive business transaction or cohesion). BTP’s ability to coordinate between services offered by autonomous organizations makes it

Web Services environmideally suited for use in a communications preserving the capacity to carry Bmessage structure and content constraints are schematized in XML, and message en oded in XML instances. BT allows great flexibility in the implementation of business transaction participaparticipants enable the conmay use recorded before- or after-imagforward, roll-back” capacity which enables their subordination to the overall outcome of an atobu iness transaction.

is an interoperation protocol which defines the roles which software agents (actors) may occupy, the messages that pass between such actors, and the obligations upon and commitments made by actors-in-roles. It does not define the programming interfaces to be us

pplication programmers to stimulate message flow or associated state changes. is based on a permissive and minimal approach, where constraints on implementation ces are avoided. The protocol also tries to avoid unnecessary dependencies on other dards, with the aim of lowering the hurdle to implementation. OASIS Business Transaction Technical Committee began its work at a

San Jose, Calif. on 13 March 2001, and version 1.0 of this specification was endorsed as a Co mittee Specification by a unanimous vote on 16th May 2002. The TC revised the specification

e light of feedback and implementation experience to form this present specification of BTP

The BT Technical Committee has consciously avoided specifying the integration of BTP with urity standards or technology. It is assumed that all BTP actors are within a trust domain or e separate specification defines the integration with security mechanisms.


Part 1. Purpose and Features of BTP 279

Structure of this specification 1 280

This specification document includes, in Part 1, an explanation and description of the conceptual 281 model of BTP, and, in Part 2, a fully normative specification of the protocol. 282 The use and definition of terms in the model can be regarded as authoritative but should not be 283 taken to restrict implementations or uses of BTP. In case of (unintended) disagreement between 284 the parts, Part 2 takes precedence over Part 1. 285 Part 1 contains: 286 • This structure description; 287 • A description of the typographic and other conventions used in the document; 288 • A glossary that provides succinct definitions of terms used in the document; 289 • Conceptual Model. 290 Part 2 contains the following sections: 291 • Actors, roles and relationships: defines the model entities used in the specification, their 292

relationships to each other and indicates the correspondence of these to real implementation 293 constructs. This section also lists which messages are sent and received for each role. 294

• Abstract message set: defines a set of abstract messages that are exchanged between 295 software agents performing the various roles to create, progress and complete the 296 relationships between those roles. For each abstract message the parameters are defined 297 and the associated “contract” is stated. The contract defines the meaning of the message in 298 terms of what the receiver can infer of the sender’s state and the intended effect on the 299 receiver. This section does not itself specify a particular encoding or representation of the 300 messages nor a single mechanism for communicating the messages. 301

• State tables: specifies the state transitions for the Superior and Inferior roles, detailing when 302 particular messages may be sent and when internal decisions may be made that affect the 303 state. 304

• XML representation: defines an XML representation of the message set. Other 305 representations of the message set, or parts of it are possible; these may or may not be 306 suitable for interoperation between heterogeneous implementations. This section uses an 307 informal syntax to the structure of the BTP messages and references the XML schemas 308 which are separate documents. These separate XML documents should be considered a 309 normative part of this specification, as if they were part of this document. They are presented 310 as separate documents to avoid possible inconsistencies due to formatting and copying. 311

• Carrier protocol bindings: defines a “carrier binding proforma” that details the information 312 required to specify the mapping to a particular carrier protocol such that independent 313 implementations can interoperate. The proforma requires an identification for the binding, the 314 nature of the addressing information used with the binding, how the messages are 315 represented and encoded and how they are carried (e.g. which carrier protocol messages or 316 fields they are in) and may include other requirements. 317

• Using the carrier protocol proforma, this section fully specifies bindings to SOAP 1.1, using 318 the XML representation of the abstract message set. This section references separate XML 319 documents containing WSDL definitions. These documents should be considered integral, 320 but non-normative parts of this specification. 321

• Conformance definitions: defines combinations of facilities (expressed as roles) that an 322 implementation can declare it supports. 323


Following Part 2 there are several appendices. The only technical appendix is the informational 324 appendix D which defines a format for the serialised state information of a BTP node. This is a 325

ation roles, which is an 326 327

328

first step towards enabling the migration of the transaction coordinimportant feature for scalable transaction systems.


2 Conventions and terminology 329

2.1 Ty330

s in terms which are defined (at least in their substantive or infinitive 331 : 332

• Can333 334

• App335 nce of a word defined in the Glossary is given in bold, thus: 336

Coordin337 may be given in bold in other contexts (for example, in section headings or captions) 338

hasize their status as formally defined terms. 339 The nam340 • BEG341

342 • RES343 The val344 • BEG345

es that are related semantically are joined by an ampersand: 346 347

BTP pro348 + VOTE 349

XML sc350

pographical and Linguistic Conventions and Style The initial letters of wordform) in the Glossary are capitalized whenever the term used with that exact meaning, thus

cel • Participant

lication Message The first occurre

ator Such words to emp

es of abstract BTP protocol messages are given in upper-case throughout: IN

• CONTEXT IGN

ues of elements within a BTP protocol message are indicated thus: IN/atom

BTP protocol messag• BEGIN/atom & CONTEXT

tocol messages that are transmitted together in a compound are joined by a + sign: • ENROL

hemata and instances are given in Courier and are shaded:

<btp:begin> ... </btp:begin> 351

The key d, 352 may, an353

354

2.2 G355

Actor 356 357

Addres358 359

360 361 362

, which may be distributed, that perform a common purpose. 363

364 ner of a single system or is explicitly part of the 365

words must, must not, required, shall, shall not, should, should not, recommended optional in lowercase bold in this document are to be interpreted as described in

[RFC2119].

lossary

An entity that executes procedures, a software agent. (See also BTP Actor)

s An identifier for an endpoint.

Application An Actor, which uses the Business Transaction Protocol (in the context of this specification).

Also, a group of such Actors

(When used in phrases such as “determined by the Application”, it is not relevant to BTP whether this is determined by the ow

Contract that defines the distributed collaborative application. When it is necessary to distinguish the responsibilities of a single party, the term “Application Element” is used.)

tion Element

366 367

Applica368 municates, using Application Protocols, with other Application 369

ore 370 371

372 373 374

Applica375 376

Approp377 378

379 e only 380 s 381

382

383 384

s in the transaction will 385 tructions that will result in a homogeneous outcome. That is, they will be 386

387

e Prepared 388 essfully instructed to Cancel 389

rm. 390

BTP Ac391 392 393 394

395 396

BTP Ad397 und address consisting of three parts. The first part, the “binding name”, 398

rticular Carrier Protocol – some bindings are specified in this 399 400 401

e third part, 402 nal information”, is not used or understood by the Carrier Protocol. The 403

dditional information” may be a structured value. 404

BTP El405 ports an Application Element (or elements) but is not itself 406

ncerned with Application Messages or semantics. 407

(Busine408 nings and their permitted sequences used to effect a change in 409

siness relationship. 410

(Business) Application System 411

An Actor that comElements, as part of an overall distributed application. A single system may contain mthan one Application Element.

Application Message A message produced by an Application Element and consumed by an Application Element.

tion Operation An operation, which is started when an Application Message arrives.

riate In accordance with a pertinent contract or specification.

Atom A set of participants, which are the direct inferiors of a BTP Node (which may havone member), all of which will receive instructions that will result in a homogeneououtcome. That is, they will be issued instructions to all Confirm or all Cancel.

Atomic Business Transaction A complete Business Transaction that follows the atom rules for every BTP Node in the

ree over space and time, so that all the participantTransaction Treceive insissued instructions to all Confirm or all Cancel.

BecomEnsure that of a set of procedures is capable of being succor to Confi

tor A software entity, or agent, that is able to take part in Business Transaction Protocol exchanges i.e. that sends or receives BTP messages. A BTP Actor may be capable of only playing a single Role, or of playing several different roles concurrently and / or sequentially. A BTP Actor may be involved in one, or more, transactions, concurrentlyand / or sequentially.

dress A compoidentifies the binding to a padocument, others can be specified elsewhere. The second part of the address, the “binding address”, is meaningful to the Carrier Protocol itself, which will use it for the communication (i.e. it will permit a message to be delivered to a receiver). Th“additio“a

ement A BTP Actor that supco

ss) Application Protocol The messages, their meathe state of a bu


A system that contains one or more business applications, and resources such asand persistent storage for business state information. It may also contain other thin

volatile 412 gs 413

s an operating system and BTP Elements. 414

Busine415 416 417

Busine418 uter systems controlled by 419

arties, and these changes are related in some application defined manner. 420 ss Transaction is subject to, and a part of, a business relationship. (BTP 421

distinct and 422 utonomous Application Systems, which do not require knowledge of each others’ 423 plementation or internal state representations. Access to such loosely coupled 424

425

Busine426 this 427 uired to 428

effects of Application Protocol to achieve a Business Transaction. 429

Cancel 430 431

ays that this may be achieved in practice. 432

tocol 433 es how the transmission of BTP messages occur. 434

435 436

437 t may receive 438

ctions that may result in different outcomes for each participant. That is they will be 439 articipants 440

441 r a Cohesion is fixed, then all participants in the Confirm set are treated atomically. 442

443 444 445

446 447

cohesion rules. The other BTP Nodes in the Transaction Tree of a Cohesive 448 449

Confirm450 nsure that the effect of a set of procedures is completed. There are a number of 451

452

453 n to 454

tor, and upon which any other knowing Actor may rely. 455

tionship 456

such a

ss relationship A business relationship is any distributed state held by the parties, which is subject to contractual constraints agreed by those parties.

ss Transaction A set of state changes that occur, or are desired, in compsome set of pA Busineassumes that the parties involved in a Business Transaction haveaimsystems is assumed to occur only through service interfaces.)

ss Transaction Protocol (BTP) The messages, their meanings and their permitted sequences defined inspecification. Its purpose is to provide the interactions (or signalling) reqcoordinate the

Process a counter effect for the current effect of a set of procedures. There are a number of different w

Carrier ProA protocol, which defin

Client An Actor, which sends Application Messages to services.

CohesionA set of participants, which are the direct inferiors of a BTP Node thainstruissued instructions to Confirm or Cancel according to the application logic. Pmay resign or be instructed to Cancel until the Confirm set is fixed. Once the Confirm set foThat is they will all be instructed to Confirm unless one, or more, Cancel in which case all will be instructed to Cancel. All participants not in the Confirm set will be instructed to Cancel.

Cohesive Business Transaction usiness Transaction for which at least one BTP Node over space and time A complete B

follows the Business Transaction may follow either the cohesion rules or the atom rules.

Edifferent ways that this may be achieved in practice.

Contract Any rule, agreement or promise which constrains an Actor’s behaviour and is knowany other Ac

Control Rela


The Application Element:BTP Element relationships that create the nodes of the Transaction Tr

457 ee (Initiator:Factory) and drive the completion (Terminator:Decider). 458

459 action and decides the outcome of its 460

immediate branches according to the Atom rules defined in this specification. It has a 461 lifetime, which is coincident with that of the Atom. A coordinator can issue instructions to 462

463 464

essages. 465

Counte466 nded to counteract a Provisional Effect. 467

468 called 469

ause the Terminator can only request confirmation – the Decider makes the final 470 interpreted as “Composer or Coordinator”. 471

e other end of a Control Relationship to a Terminator. 472

Deliver473 e transmission of the 474

age to its target or the transmission of an immediate reply.. Distinguished from 475 476

Endpoi477 478

Enrolle479 480

Factory481 e that creates transaction contexts and deciders. 482

Final E483 484

Inferior485 The end of a BTP Node to BTP Node relationship governed by the outcome protocol that 486

487

Inferior488 used to communicate with an Actor playing the Role of an Inferior. 489

Inferior490 491 492

493 ement) that starts a transaction. 494

495 496 497

osed 498

CoordinatorA BTP Actor, which is the top BTP node of a trans

prepare, Cancel and Confirm. These instructions take the form of BTP messages. A coordinator is identified by its transaction-identifier. A coordinator must also have a BTP Address to which participants can send BTP m

r-effect An appropriate effect inte

Decider The top BTP Node of a Transaction Tree, a composer or a coordinator (sobecdetermination). The term can always be

It is the Role at th

y Parameter A parameter of an abstract message that is concerned with thmessPayload Parameter.

nt A sender or receiver.

r The BTP Actor Role that informs a superior of the existence of an inferior.

The BTP Actor Rol

ffect An appropriate effect intended to complete and finalise a Provisional Effect

is topologically further from the top of the Transaction Tree.

-Address The address

-identifier A globally unambiguous identification of a particular Inferior within a single transaction

presented as an URI or equivalent). (re

Initiator e (an Application ElThe BTP Actor Rol

Intermediate A BTP Node that is a sub-composer or a sub-coordinator. An alternative term to interposed.

Interp


A BTP Node that is a sub-composer or a sub-coordinator. An alternative term to intermediate.

499 500

501 nd then consumed. 502

503 t 504

505 506

k Node: A computer system or program that hosts one or more BTP Actors (and 507 BTP Nodes) 508

Operat509 ure, which is started by a receiver when a message arrives at it. 510

Outcom511 512

Outcom513 514 515

516 517 518 519 520 521

l 522 an inferior-523

ntifier. 524

Payloa525 age that is will be received and processed or retained by 526

527 528

529 530 531

532 533 534

other Actors. 535

536 537

Respon538 entifier carried in a BTP message that can be interpreted as transaction-identifier, a 539

540 541

Role 542

MessageA datum, which is produced a

Node BTP Node, Business Transaction Tree Node, Transaction Tree Node: A logical entity thais associated with a single transaction. A BTP Node is a composer, a coordinator, a sub-coordinator, a sub-composer, or a participant.

Networthus, often,

ion A proced

e A decision to either Cancel or Confirm.

e Relationship The Superior:Inferior relationship (i.e. between BTP Actors within the Transaction Tree) and the Enroller:Superior relationship used in establishing it.

Participant A participant is part of an Application System that also contains one or more applications, which manipulate resources. It is a Role of a BTP Actor that is (or is equivalent to) a set of procedures, which is capable of receiving instructions from another BTP Actor to prepare, Cancel and Confirm. These signals are used by the application(s) to determine whether to effect (Confirm) or counter effect (Cancel) the results of Application Operations. A participant must also have a BTP Address, to which these instructions wilbe delivered, in the form of BTP messages. A participant is identified by ide

d Parameter A parameter of an abstract messthe receiving BTP Actor. The various identifier parameters are considered Payload Parameters . Distinguished from Delivery Parameter.

Peer The other party in a two-party relationship, as in Superior to Inferior, or Sender to Receiver.

Provisional Effect The changes induced by the incomplete or complete processing of a set of procedures by an Actor, which are subject to later completion or Counter-effecting. The Provisional Effect may or may not be observable by

Receiver The consumer of a message.

ders-identifier An idsuperior-identifier, or an inferior-identifier according to the nature of the Role in a BTP Actor that is responding to a received message.


The participation of a software agent in a particular relationship in a particular Business 543 544

Sender 545 546

Service547 n Application Element), which on receipt of Application Messages, may start 548

549 550 551

Status 552 553

Sub-co554 its 555

ranches according to the cohesive 556 this specification. It has a lifetime, which is coincident with that of the 557

558 559 560 561

r 562 s an outcome from its 563

anches according to the Atom 564 rules defined in this specification. It has a lifetime, which is coincident with that of this 565 Atom. A sub-coordinator can issue instructions to prepare, Cancel and Confirm. These 566 instructions take the form of BTP messages. A sub-coordinator must also have at least 567 one BTP Address to which lower BTP Nodes can send BTP messages. 568

Superior 569 The BTP Role that will accept enrolments of Inferiors and subsequently inform the Inferior 570 of the Outcome applicable to it. 571

A Superior will be one of Composer, Coordinator, Sub-composer, or Sub-coordinator. 572

A Superior is considered to be a Superior even if it currently has no enrolled Inferiors. 573

Superior-address 574 The set of BTP addresses used to communicate with an Actor playing the Role of a 575 Superior. 576

Superior-identifier 577 A globally unambiguous identifier of a particular Superior within a particular transaction 578 (represented as an URI or equivalent). 579

Target-identifier 580 An identifier carried in a BTP message that can be interpreted as transaction-identifier, a 581 superior-identifier, or an inferior identifier according to the nature of the Role in a BTP 582 Actor that receives this identifier. 583

Terminator 584 A BTP Role performed by an Application Element communicating with a Decider to 585 control the completion of the Business Transaction. Frequently will be identical to the 586 Initiator, but distinguished because the control of the Business Transaction can be 587 passed between Application Elements. 588

Transaction. The software agent performing a Role is termed an Actor.

The producer of a message.

An Actor (aan Appropriate Application Operation. For example, a process that advertises an interface allowing defined RPCs (remote procedure calls) to be invoked by a remote client.

Requestor The BTP Actor Role that requests the status of another BTP Actor.

mposer An Actor, which is not the top BTP Node of a transaction. It receives an outcome fromsuperior and decides the outcome of its immediate brules defined in Cohesion. A sub-composer can issue instructions to prepare, Cancel and Confirm on individual branches. These instructions take the form of BTP messages. A sub-composer must also have at least one BTP Address to which lower nodes can send BTP messages.

Sub-coordinatoAn Actor, which is not the top BTP Node of a transaction. It receivesuperior and propagates the outcome to its immediate br


Transaction 589 A complete unit of work as defined by an application. A transaction starts when a part of 590

tes some work that is to be a part of a new 591 w and shrink over time and (logical) space. A 592

593 594

595 odes that provides the coordination of a distributed application 596

There is single top BTP Node (a Decider) that interacts with the initiating 597 hich is a part of a distributed application). The Decider BTP Node has one, 598

tor, 599 600 601

602 603 604

entifier 605 ous identifier for a particular a Decider (represented as an URI or 606 er is the top BTP Node of the transaction and thus this identifier also 607

608 609

610 611

612

the distributed transaction first initiatransaction. The Transaction Tree may grotransaction completes when all the participants in a transaction have completed (that is have replied to their Confirm or Cancel instruction).

Transaction Tree A pattern of BTP Ntransaction. application (wor more Outcome Relationships with other BTP Nodes (sub-composer, sub-coordinaor participant BTP Nodes). Any intermediate BTP Nodes (Sub-composer or Sub-coordinator nodes) have exactly one relationship up the tree in which they act as Inferior, and one, or more, relationships down the tree in which they act as Superior. Participantsare leaves of the tree. That is they have exactly one relationship up the tree in which they act as Inferior and no down tree relationships.

Transaction-idA globally unambiguequivalent). A Decidunambiguously identifies the transaction. Often identical to the Superior-identifier of theDecider in its Role as Superior, though the protocol does not require this.

Transmission The passage of a message from a sender to a receiver.


3 Conceptual Model 613

614 615

r 616 617

618

BTP is designed to make minimal assumptions about the implementation structure and the 619 properties of the Carrier Protocols. This allows BTP to be bound to more than one Carrier 620 Protocol. BTP implementations built in quite different ways should be able to interoperate if they 621 are bound to the same Carrier Protocol. This flexibility requires that much of the text is abstract 622 and may be difficult to visualise in the absence of a particular implementation pattern or Carrier 623 Protocol. To aid understanding some possible implementation examples are presented in the 624 following text. 625

3.1.1 Example Core 626

An advanced manufacturing company (Manufacturer A) orders the parts and services it needs 627 on-line. It has existing relationships with parts suppliers and providers of services such as 628 shipping and insurance. All of the communications between these organizations is via XML 629 messages. The interactions of these business transactions include: 630

• Manufacturer A’s production scheduling system sends an Order message to a 631 Supplier. 632

• The Supplier’s order processing system sends back an order confirmation with the 633 details of the order. 634

• Manufacturer A orders delivery from a Shipper for the ordered parts. 635 • The Shipper evaluates the request and based on its truck schedu s back a 636

reply. 637 • Some shipments need to be insured based on their value, where they are shipped 638

Manufacturer A sends an Order message to an 639 ry. 640

641 642 643 644 645 646 647 648 649 650

e was required. 651 652 653 654 655 656

This section introduces the concepts of BTP. Its use and definition of terms can be regarded as authoritative but should not be taken to restrict implementations or uses of BTP. Part 2 of the specification is fully normative and in case of disagreement takes precedence over statements oexamples in this section.

3.1 Concepts

le it sendpositive or negative

from, and method of transportation. Insurer when this is necessa

• The Insurer responds with a bid or a no-bid response. Problems have arisen with some of these interactions.

• Manufacturer A had ordered parts from a supplier and contacted shipper M about delivering the goods. Shipper M was busy and agreed to the contract, but only for a scheduled delivery the day after the parts were needed. By the time this was addressed, it was too late to schedule alternate shipping.

• There were communications problems with supplier Z that resulted in an order not being confirmed. The shipper arrived to pick up the order and supplier Z knew nothing about it.

• Goods have been shipped without insurance when company policy dictated that insuranc

These problems occur because of the unreliable nature of the Internet and the lack of visibility a company has into the workings and state of an outside organization. By using BTP in support of this supply application, these problems can be ameliorated. BTP is a protocol, that is, a set of specific messages that get exchanged between computer systems supporting an application, with rules about the meaning and use of the messages. The


computer systems will also exchange other, application-specific messages. Thus, within the example, the Manufacturer’s system and the Supplier’s system (say), will exchange applicatiomessages detailing what the goods are, how many, what price and will also exchanmessages. The parts of the application in both systems that handle these different sets of messages can be distinguished, as in Figure 1. In each BTP-u

657 n 658

ge BTP 659 660

sing party there is an Application 661 662 663 664 665

this model, may include supporting infrastructure elements, such as containers or 666 tion-specific code. 667

Element and a BTP Element. The Application Elements exchange the order information and cause the associated business functions to be performed. The BTP Elements, which send and receive the BTP messages, perform specific roles in the protocol. These BTP Elements assist the application in getting the work of the application done. The Application Element, as understood byinterceptors, as well as applica

Manufacturing Application

Element

BTP

Supplier Application

Element

BTP

Shipping Application

Element

BTP

Insurance Application

Element

M

Z

S

I

BTP 668 F mple 669

3.1.2 Business transacti670

A e onsisten state s 671 r e siness r y dis eld by 672 t n traints ag those partie a 673 m ement, which permits the placing of orders for compo nown 674 b bu r to exc in675 c an order. Such agreements m e spec shared or 676 c ata formats, of the messages that carry thos and their permitted sequences, 677 all of which are need ation of an agreement. This d678 b te re ” tra 679 p for profit, verification of autho ndi loans, 680 c (replication) of government ordina le sites, or any other 681 computerized interaction where the parties require high confidence of consistent delivery or 682 processing of data. 683 In each party or site where business relationship state resides an Application System must exist 684 which can maintain that state and communicate it as needed to other parties. The Business 685 Transaction Protocol (BTP) assists the Application Systems of the various parties to bring about 686 consistent and coordinated changes in the relationship as viewed from each party. BTP assumes 687 that for a given Business Transaction, state changes occur, or are desired, in computer systems 688

igure 1 – Manufacturer Exa

ons Business Transaction can b

elationship between two or morhe parties which is subject to coaster purchasing agre

defined as a c parties. A butractual cons

t change in theelationship is anreed by

of a businestributed state h

s. For example, nents by k

uying organizations, allows areation and processing ofanonical d

yer and a selle hange meaningfulay include th

e formats

formation about the ification of

ed for an automateusiness relationship is deliberaarties: it might be tradingonsistent publication

d implemently silent on the natu

efinition of a nsacted between theture or

of the “businessrizations for expences to multip


controlled by some set of parties, and that these changes are related in some application-definedmanner. BTP assumes that the parties involved in a Business Transaction have distinct and autonomous Application Systems,

689 690

which do not require knowledge of each others’ 691 692 693

694 695 696 697

698

699 700 701 702

name and replying. When the manufacturer 703 ages 704 – 705

706 g707

man708 m709

710 rvation of the order is the Provisional 711

712 Som ion approaches are shown in Table 1. From the perspective of BTP and 713

714 s 715

effe716 717

implementation or internal state representations. Access to such loosely coupled Application Systems is assumed to occur only through service interfaces. The state changes that BTP is concerned with are only those affecting the immediate businessrelationship. Although these externally visible changes will typically correspond to internal state changes of the parties, use of BTP does not itself imply any constraints or requirements on the internal state.1

3.1.3 External Effects BTP coordinates the state changes caused by the exchange of Application Messages. These state changes are part of the Contract between BTP-using parties. In the manufacturing example, an interaction between the manufacturer and the supplier might involve the supplier receiving the order (an Application Message), checking to ensure that it had enough product on hand, reserving the product in the manufacturer’s agrees to the purchase (assuming the shipping and insurance are also reserved), BTP messare sent to confirm the purchase. In this case, the supplier is offering a BTP-enabled servicethe Application Element and its supporting BTP Elements together offer this service. In eneral, to be able to satisfy such contracts a BTP-enabled service must support in some

ner provisional or tentative state changes (the transaction’s Provisional Effect) and pletion either through confirmation (Final Effect) or caco ncellation (Counter-effect). The

meaning of provisional, final, and Counter-effect are specific to the application and to the implementation of the application. In the example, the reseEffect, the completion of the purchase is the Final Effect.

e of the implementatthe initiator application, all these are considered equivalent. Outside of BTP the underlying bu iness relationship (or Contract) between the parties can constrain the degree to which the

cts are visible. Table 1 Some alternatives for Provisional, Final and Counter-Effects

Provisional Effect Final Effect Counter effect Comment

Store intended changes Perform the Delete the storedwithout performing them changes

changes, unperformed

Provisional Effect may include checking for validity

Perform the changes, making them visible; store information to undo the changes

Delete undo information

Perform undo action

One form of compensation approach

Store original state, prevent outside access, perform changes

Allow access Restore original state; allow access

A typical databaapproach

se

Perform the changes, marked or typed as provisional, making them visible

Mark or transform as final

Delete or mark/transform as ca

E.g. quote-to-ocycle

ncelled

rder

1 Although a Business Transaction is defined as concerning a business relationship, the facilities of BTP make it suitable for other environments where loosely coupled systems require coordination and consistency.


These alternatives are not the only ones – they can be combined or varied. The visible statethe application information prior to confirmation or cancellation may be different from both the original state and the final state. Especially in the compensation approach, if the changes are cancelled, the Counter-effect may be a precise inversion or removal of provisional changes, or it may be the processing of operations that in some way compensate for, make good, alleviate or supplement their effect. There may be side-effects of various kinds from a Counter-effected operation – such as levying cancellation charges or the record of the operation may be visible, bu

of 718 719 720 721 722 723

of 724 t marked as cancelled. The 725

possibility of these side-effects is considered to be part of the overarching Contract. 726

727

728 First 729

730 731 732 733 734 735

Confirm736 operation, whichever is subsequently instructed, and 737

eparedness) to a central coordinating entity. 738 739 740 741 742 743 744

r is required in order to achieve a consistent outcome for a set of 745 operations. The two phases of the BTP protocol ensure that either the entire attempted 746 transaction is abandoned or a consistent set of participants is confirmed. 747

3.1.5 Actors and roles 748

BTP centres on the bilateral relationship between the computer systems of the coordinating entity 749 and those of one of the parties in the overall Business Transaction. For each bilateral relationship 750

within the coordinating entity’s systems plays the 751 752 753 754

755 756

s in multiple 757 Business Transactions, either concurrently or con cutively. 758

ip 759

760 761 762

– 763 een the 764

3.1.4 Two-phase outcome The BTP protocol coordinates the transitions into and out of the event states described above by sending messages between the transaction parties. This involves a two-phase exchange. the Application Elements exchange messages that determine the characteristics and cause the performance of the Provisional Effect; then a separate message, to the BTP Element, asking for the performance of the final or the counter effect. In general, the Application Elements in the systems involved having first communicated the Application Messages, each system that has to make changes in its own state: • determines whether it is able achieve its Provisional Effect and then ensure it will be able

either to Cancel (Counter-effect) its operation or to (give Final Effect to) its

• reports its ability to Confirm-or-cancel (its prAnd, after receiving these reports, the coordinating entity: • determines which of the systems should be instructed to Confirm and which should be

instructed to Cancel • informs each system whether it should Confirm or Cancel (the “outcome”).by sending a

message to its BTP Element When there is more than one system that has to make changes, such a two-phase exchange mediated by a coordinato

in a Business Transaction, a software agent BTP Role of Superior and a software agent within the systems of the party play the BTP Role of Inferior. The concept “Role” refers strictly to the participation in a particular relationship in a particular Business Transaction. The software agent performing a Role is termed an Actor. An Actor is distinguished from other Actors by being distinguishably addressable. The same Actormay perform multiple roles in the same Business Transaction (including the case where a Superior is also an Inferior), and may also perform the same or different role

se

3.1.6 Superior:Inferior relationshA basic case of a single Superior:Inferior relationship, including the association with Application Elements, is illustrated in Figure 2. In many cases, including the manufacturer supply example, the Application Element associated with the superior will directly initiate the application exchanges – as does the manufacturer’s application client to the supplier’s server, for example but this is not invariably the case. It is possible that the first direct communication betw


Application Elements is from one associated with an Inferior to the one associated with the Superior – for example, with

765 an application that requested quotes by advertising the identity and 766

location of the Superior along with invitation to quote; incoming quotes would be the first direct 767 Application Message exchanged. But in all cases the topmost Application Element in a tree or 768 subtree will be aware of the Business Transaction first. How the identity of the transaction and the 769 address of the BTP Superior are communicated to the secondary Application Element is a matter 770 for the Application Protocol and not strictly part of BTP, although it will commonly be done by 771 associating a BTP CONTEXT message with Application Messages.. 772

initiating application

element

BTP Superior

service application

element

BTPInferior

BTP messages

Application messages

773 774

y, 775 776 777 778 779 780 781 782 783 784

rees 785

786 787

s – 788 789 790 791

ether the operations at the inferior, B were eventually 792 n793

Figure 2 Basic Superior:Inferior relationship for BTP

An Inferior is associated with some set of application activities that create effects within the partfor a given Business Transaction. As stated above, commonly, though not invariably, this application activity within the party will be a result of some operation invocations from elsewhere (shown as the “initiating Application Element” in Figure 2), associated with the Superior to an Application Element associated with the Inferior (shown as “Service Application Element”). This second Application Element determines what activities the Inferior is responsible for, and then the Inferior is responsible for reporting to the Superior whether the associated operations’ Provisional Effect can be confirmed/cancelled – this is called “becoming prepared”, because the Inferior has to remain prepared to receive whichever order eventually arrives (subject to various exceptions and exclusions, detailed below).

3.1.7 Business Transaction TThere are many patterns in which the service provider participants involved in a Business Transaction may be arranged in respect of the two-phase exchange and the determination of which are eventually confirmed. The simplest is shown in Figure 3 involving only two partieone (B) making itself subject to the decision of Confirm-or-Cancel made by the other (A). This basic bilateral relationship, in which one side makes itself inferior to the other, is the building block used in all Business Transaction patterns. In this simplest case, the “coordination” by the superior, A, is just that A can be sure whca celled or confirmed.

Superior InferiorA B 794

Figu795

In the n796 with two rior to a single Superior, C. From the 797 per798 unawar799 betwee800

re 3 Simple two-party Business Transaction

ext simplest case, as in Figure 4, a bilateral, Superior:Inferior relationship appears twice, Inferiors, D and E, both making themselves infe

spective of either D or E, they are in the same position as B in the previous case –they are e of and unaffected (directly) by each other. It is only within C that there is any linkage n the Confirm-or-Cancel outcomes that apply to D and E.


Superior

Inferior Inferior

ED

C

Figure 4 Business Transaction with two inferiors

The same Superior:Inferior relationship is used in Business Transaction Trees that are both “wider” – with more Inferiors reporting

801 802

803 their preparedness to be Confirm-or-canceled to a single 804

r 805 an 806

807 808 809

Superior – and “deeper”. In a “deeper” tree, as in Figure 5, an entity (G) that is Superior to one omore Inferiors (H, J), is itself Inferior to another entity (F) – it is said to be interposed or isIntermediate (either term can be used). In this case, G will collect the information on preparedness of its Inferiors before passing on its own report to its Superior, F, and awaiting the outcome as advised by F.

SuperiorF

InferiorInferior

Superior

Inferior Inferior

JH

KG

810 Figure 5 Business Transaction with an Intermediate (interpostion) 811

ps can, in 812 813

r 814 815

816 817

818 819 820 821

A Business Transaction Tree, made up of these bilateral Superior:Inferior relationshitheory, be arbitrarily “wide” or “deep” – there are no fixed limits to how many Inferiors a singleSuperior can have, or how many levels of intermediates there are between the top-most Superio(that is Inferior to none) and the bottom-most leaf Inferior. The actual creation of the tree dependson the behaviour and requirements of the application. Given the (potentially) inter-organisational nature of Business Transactions, there may be no overall design or control of the structure of thetree. Each Inferior has only one Superior. However, a single Superior may (and commonly does) have multiple relationships with Inferiors. Multiple inferiors does not necessarily imply multiple parties; one party may control several participants in that are Inferiors of the same Superior.


3.1.8 Atoms and Cohesions 822

ceives reports from its Inferiors as to whether 823 o ascertain which Inferiors should be 824

825 826 827

828 • Is it an Inferior to another Superior? 829

or cohesively? 830 831

n 832 833 834 835 836 837

838 se 839

840 841 842

of this Superior should Confirm, but only if confirmation is 843 nator; 844

e 845 846

of which Inferiors should be candidates to Confirm until later, allowing 847 848 849 850 851

/Confirm as 852 having veto power, causing the Superior to instruct all its Inferiors to Cancel. A Business 853

ic Business Transaction, or Atom – 854 855 856 857 858 859 860 861 862

fore the 863 e 864

865 ecoming prepared, and reporting this to its 866

own Superior will depend on the receipt of prepared reports from its Inferiors. If it is atomic (i.e. is 867 a sub-coordinator), it will only Become Prepared if all Inferiors reported preparedness to it; if it is 868 cohesive (i.e. is a sub-composer), the controlling Application Element will determine whether the 869 set of Inferiors that have reported as prepared is sufficient. 870

As described in the previous section, the Superior rethey are prepared. It gathers these reports in order tcancelled and which confirmed - those that cannot prepare will have already cancelled themselves. This determined, directly or indirectly, by the Application Element responsible of thecreation and control of the Superior, which determines the nature of the Superior. There are twodimensions of variation in the Superior:

• Does it treat its own Inferiors atomicallyThe distinction between atomic and cohesive behaviour is whether the Superior will choose or allow some Inferiors to Cancel while others Confirm – this is not allowed for atomic behaviour, iwhich all must Confirm or all must Cancel, but is allowed for cohesive behaviour. The possible cases for a Superior, given these two dimensions of variation, are:

a) the Application Element initiated the Business Transaction (causing the creation of the Superior), and instructed that all Inferiors of the Superior should Confirm or all should Cancel; the Superior is an Atom Coordinator;

b) the Application Element initiated the Business Transaction, but deferred the choice ofwhich Inferiors should Confirm until later, allowing it (the Application Element) to choosome subset to be confirmed, others to Cancel; the Superior is a Cohesion Composer;

c) the Application Element was itself involved in an existing Business Transaction, and the Superior in this relationship is the Inferior in another one; this Application Element instructed that all Inferiors instructed from above or all should Cancel; the Superior is an (atomic) Sub-coordi

d) the Application Element was itself involved in an existing Business Transaction, and thSuperior in this relationship is the Inferior in another one; this Application Element deferred the choice it (the Application Element) to choose some subset to be confirmed, given that confirmation is instructed from above, others to Cancel; the Superior is a (cohesive) Sub-composer.

In the atomic case, the two-phase outcome exchange means a Superior acting as an atomic Coordinator or sub-coordinator will treat any Inferior which cannot prepare to Cancel

Transaction whose topmost Superior is atomic is an Atomthe superior is the Atom Coordinator. In the cohesion case, with the Superior acting as a cohesive Composer or Sub-Composer, the controlling Application Element will determine the implications of an Inferior’s failure to be prepared to Confirm-or-Cancel; the Application Element may Cancel some or all other Inferiors, do other application work, which may involve new Inferiors or may just accept the cancellation of that one Inferior and carry on. A Business Transaction whose topmost Superior is cohesive is a Cohesive Business Transaction, or Cohesion – the Superior is the Cohesion Composer. For a Cohesion, the set of Inferiors that eventually Confirm is called the Confirm-set. The term is also used to mean the set of Inferiors that have been chosen to (potentially) Confirm befinal outcome is decided – if the Cohesion is eventually cancelled, then Confirm-set cancels. (Sesection “Evolution of Confirm-set”). The Confirm-set of an Atom is all of the Inferiors. If the Superior is itself an Inferior, its own action of b


If the Superior is not an Inferior, the determination of when, if and, for a Cohesion, what it should Confirm depends on the controlling application. This “top-most” Superior has a different relationship to the controlling application to that of an Inferior to its Superior: an Inferior reportthat it is prepared to the Superior, which instructs it whether to Cancel or to Confirm; the top-most Superior is asked by the Application Element to attempt to Confirm, but, dependent on the preparedness of its Inferiors, the top-most Superior makes the final decision. Consequently the top-most Superior is termed the Decider; the Application Element that asks it to Confirm is the Termi

871 872

s 873 874 875 876 877

nator. 878

3.1.9 Participants, Sub-Coordinators and Sub-Composers 879

An Inferior may directly be responsible for applying the Confirm-or-Cancel decision to some 880 application effects, or may in turn be a BTP Superior to which others will enrol. If it only handles 881 application effects it is called a Participant, in the latter case it is called a Sub-coordinator or a 882 Sub-composer, depending on whether it is atomic or cohesive with respect to its own future 883 Inferiors. (If an Inferior is both responsible for application effects, and is a BTP Superior, it is not 884 considered a Participant, according to the strict definitions, though informally it may be referred to 885 as such.) The Superior is unaware, via the BTP exchanges, whether the Inferior is a Participant, 886 Sub-coordinator or Sub-composer. This specification does not define messages or interfaces for 887 the creation of Participants or for the Application Element to tell the Participant what the 888 application effects are or how they are to be confirmed or cancelled as necessary. (Although out-889 of-scope for this specification, one or more APIs could be standardised.) 890

3.2 Business transaction lifecycle 891

3.2.1 Business Transaction creation 892

This section describes in some detail how a BTP Business Transaction is created. The 893 interaction diagram in Figure 6 also shows this sequence. The messages shown in lower-case 894 italics (between Factory and Coordinator) represent interactions that are not specified in BTP. 895

Initiator Factory Coordinator

BEGIN

new

getContext()

createContext()

BEGUN&CONTEXT

Figure 6 – Creation of a Business Tr

896 ansaction 897


A Business Transaction is started at the initiative of an Application Element, which causes the 898 r. Any Inferiors participating in this transaction will enrol 899 ct messages (BEGIN, BEGUN) to request this but the 900

r 901 902

IN 903 is 904

905 906 907 908

ese 909 910

911 912

lement 913 this information to some 914

915 916

rdinator 917 f the 918

919 920

921

922 923 924 925 926

927 928

929 930 931 932 933 934 935 936

ct 937 938

nd to 939 e 940

941

creation of a Coordinator or Composewith this Superior. BTP defines abstraequivalent function can also be achieved using proprietary means, especially if the Factory oCoordinator is an internal component of the initiating application. If the BTP messages are used, the Application Element performs the Role of Initiator and sends BEGIN to a Factory. The BEGmessage identifies whether a Coordinator (for an Atom) or a Composer (for a Cohesion)desired. The Factory, after the creation of the new Coordinator or Composer, replies with a BEGUN message, which contains a CONTEXT message. The Coordinator's or Composer's creation is the establishment of a new instance of a BTP Role. It may involve only the assignment of a new identifier within an existing Actor (which may also be performing the Factory Role, for example). Alternatively a new Actor with a distinct address may be instantiated. Thand other alternatives are implementation choices, and BTP ensures other Actors are unaffectedby the choice made. The BEGUN message provides the addressing and identification information needed for a Terminator to access the new Coordinator or Composer as Decider; the Application Eperforming the Initiator Role may itself act as Terminator, or may passother Application Element. Whether this interoperable BTP Initiator:Factory relationship or some other mechanism is used to initiate the Business Transaction, a CONTEXT is made available. This identifies the Cooor Composer as a Superior – containing both addressing information and the identification orelevant state information. The CONTEXT is also marked as to whether or not this Superior will behave atomically with respect to its Inferiors (i.e. is it a Coordinator or Composer).

3.2.2 Business Transaction propagation The propagation of the Business Transaction from one party to another, to establish the Superior:Inferior relationships, involves the transmission of the CONTEXT. This is commonly in association with, or related to, one or more Application Messages between the parties. In a typical case, an Application Message is sent from the Application Element that performed the Initiator Role (the “sending application” in Figure 2) to some other Application Element (the receiving application). The CONTEXT is sent with the Application Message in such a way that theApplication Elements understand that work performed as a result of the Application Message is tobe the subject of a Confirm-or-Cancel decision of the Superior.2 The receiving Application Element causes the creation of an Inferior (which, as for the Superior may involve just assignment on a new identifier, or instantiation of an new Actor) and ensures the new Inferior is enrolled with the Superior identified in the received CONTEXT, using an ENROL message sent to the Superior using the address in that CONTEXT. Figure 7 shows a sequence diagram of the propagation of a Business Transaction. It is assumed the transaction has already been created, and thus the Application Element and Coordinator exist. The diagram shows the Enroller as a distinct Role, with non-standardised interactions between the Application Element, the Enroller and the new Inferior. The Enroller Role may in fabe performed by the Application Element, by the Inferior or by some other entity. At least the Superior-identifier and Superior-address from the CONTEXT has to be passed the Enroller athe Inferior so they can communicate with the Coordinator (whose identifier and address thesare).

2 The relationship between the application activity and BTP is subtle, and summarised in this sentence.


enrol(CONTEXT)request & CONTEXT/atom

SendingApplication Coordinator Receiving

Application

ENROL

response + CONTEXT_REPLY/completed

ENROLLED

Enroller Inferior

new(CONTEXT)

942 943

944 945

-946 s a 947 an 948

in the 949 950 951

The Factory is responsible for enrolling the new Sub-coordinator or Sub-952 composer as an Inferior of the Superior identified by the received CONTEXT. The reply from the 953 Factory is a BEGUN containing a CONTEXT – this being the CONTEXT for the new Sub-954 coordinator (‘b’) or Sub-composer as a Superior. The Sub-coordinator/Sub-composer is not a 955 Decider, as its decision is subordinated to the outcome received from the Superior. For a Sub-956 coordinator, further control by the application is primarily a matter of relating the new CONTEXT 957 to appropriate application activity. For a Sub-composer, there is also a requirement for the 958 application to determine which of the Inferiors of the Sub-composer must have reported they are 959 prepared before the Sub-composer can report that it is itself prepared to its own Superior, and 960 then which of these Inferiors are to be ordered to Confirm if the Sub-composer is ordered to 961 Confirm. This specification does not provide an interface or interoperable message to control this; 962 like the relationship between Application Element and Participant, it is left to the implementation 963 or independent standardisation. 964

Figure 7 Sequence diagram of propagation

3.2.3 Creation of Intermediates (Sub-Coordinators and Sub-Composers)

If the new Inferior is to be a Sub-coordinator or Sub-composer, this can be created using a nonstandard mechanism or the Initiator:Factory relationship can be used again. Figure 8 showsequence diagram, using the latter mechanism. The Application Element, having received Application Message and a CONTEXT from some Superior – shown as “Coordinator/a”diagram - wants to create the new Inferior. Acting in the Initiator Role, the Application Element issues BEGIN to the Factory, with the CONTEXT for the original Superior (Coordinator/a) as a field of the BEGIN.


ApplicationElement Factory SubCoordinator/

bCoordinator/a

BEGIN & CONTEXT/a

new(CONTEXT/a)

ENROL

ENROLLED

BEGUN & CONTEXT/b

createContext()

getContext()

application msg & CONTEXT/a

965 Figure 8 – Creation of a Sub-coordinator 966

The creation of a new Inferior and establishment of a Superior:Inferior relationship does not 967 always imply that the BTP Actors are under the control of different business parties or Application 968 Elements. In particular, an Application Element may begin a Cohesion, then create and enrol 969 (atomic) Sub-coordinators as Inferiors of the Composer, then associate a different Sub-970 coordinator’s CONTEXT with each of several aspects of the application work, transmitting that 971 CONTEXT with the Application Messages for that aspect to the other parties in the Business 972 Transaction. Those parties can then create Participants (or other Inferiors) that are enrolled with 973 the appropriate Sub-coordinator. Later, the Application Element (as Terminator, or its equivalent) 974 can choose which of the Cohesion Composers’ Inferiors to Cancel and which to Confirm. By 975 interposing its own atomic Sub-coordinator the initiating Application Element can indicate to the 976 other parties that some associated set of application work will be confirmed or cancelled as a unit. 977 This may allow the receiving parties to share information between Application Operations and 978 to make one Participant responsible for applying the outcome to several operations. 979

3.2.4 “Checking” and context-reply 980

In BTP, enrolment is at the initiative of an Application Element that has received or has access to 981 the CONTEXT which creates an Inferior (BTP uses a “pull” paradigm for enrolment). An 982 Application Element in possession of a CONTEXT can choose, perhaps constrained by an 983 overarching business and application understanding, whether and how many Inferiors to create 984 and enrol. Consequently, in general, an Application Element which propagates a CONTEXT to 985 another (via whatever mechanisms it choose), cannot be sure how many Inferiors will be enrolled 986 as a result. Without further controls, there would be a possibility that an Application Element 987 receiving a CONTEXT might attempt to enrol an Inferior with a Superior after the Superior had 988 been asked to Confirm and had received PREPARED from all the Inferiors it knew about, or even 989

at should have been part of a 990 991 992 993 994

995

had completed confirmation. In such a case application work thconfirmed Atomic Business Transaction could be cancelled, violating the atomicity in a manner that will not be apparent to the application. To avoid this, whenever a CONTEXT is transmitted to another party by or on behalf of the application, the transmission of the CONTEXT itself can be replied to with a CONTEXT_REPLY message – this is required for an Atom, allowed for a Cohesion. An Application Element that has


received a BTP CONTEXT is able, because it knows the Superior’s identification and address inthe CONTEXT, to enrol Inferiors (Figure 9).

996 997

ws the 998 999

1000 k 1001

1002 1003

re a confirmation decision can be made; or whether it is acceptable to proceed to 1004 1005 1006 1007

ever 1008 1009 1010 1011 1012

is existing 1013 1014 1015 1016 1017 1018

1019

1020 an be categorised into: 1021

• Outcome Relationships : the Superior:Inferior relationship (i.e. between BTP Actors within 1022 the Transaction Tree) and the Enroller:Superi r relationship used in establishing it 1023

hat create the nodes of the 1024 Transaction Tree (Initiator:Factory) and drive the completion (Terminator:Decider). 1025

The Outcome Relationships and the messages used in them are essential parts of BTP. For the 1026 Control Relationships, it would be possible to achieve the same general function using non-1027 standardised messages or API mechanisms. There are other distinguishable relationships 1028 between roles defined by BTP that are not standardised in this specification. 1029 Figure 9 shows the message exchange for the conventional progression of a simple transaction 1030 to confirmation with a single Superior:Inferior relationship, assuming the standard Control 1031 Relationship. Two Application Elements using a request/response Application Message exchange 1032 are involved – the first is represented as the Initiator and Terminator, the second as the Service 1033 and Enroller. The Decider/Superior is shown as a Coordinator, but with only one Inferior there 1034 would be no difference with a Cohesion Composer. The Factory:Coordinator events are non-1035 standardised, but represent interactions that must occur in some form. There are other 1036 interactions between the various application groups – Initiator-Terminator and Participant-1037 Enroller-Service that are not shown – in particular the Service:Participant relationship. 1038 The message sequence is shown is the “conventional” sequence, with all messages explicitly 1039 present and sent separately. There are several variations and optimisations possible – these are 1040 discussed below. 1041

3 Replying with CONTEXT_REPLY means that the sender (the earlier receiver of a CONTEXT) will not enrol any more Inferiors (unless it follo“late enrolment discipline”, see below). Consequently the sender of a CONTEXT can keep track of whether there are any outstanding (un-replied to) CONTEXTs that could be used for an enrolment and can avoid requesting or permitting confirmation until everything is safe. This checis required for an Atom, but is not always essential when the CONTEXT is for a Cohesion. For a Cohesion, it is a matter for the controlling application whether all would-be Inferiors must be enrolled befoconfirmation at some point in time with the already enrolled Inferiors (or a subset thereof), accepting the automatic cancellation of any late arrivals. CONTEXT_REPLY can also indicate that attempted enrollments failed. This can occur if the Enroller is unable to contact the Superior, but it able to return a CONTEXT_REPLY to where-the CONTEXT came from. Despite the above considerations, it is safe for an Application Element to enrol Inferiors after it has sent a CONTEXT_REPLY and even after the Superior has begun the termination sequence, provided it follows the “late enrolment discipline”. This requires that the Application Element ensures that there is an already enrolled Inferior of the same Superior, and that thInferior does not go prepared or resign until it is known that the new Inferior is correctly enrolled. The Superior (at least if atomic) will be unable to make a confirm decision until it has received PREPARED or RESIGN from that first Inferior and there is thus no risk of the new Inferior breaking the atomicity guarantee. Again, for a Cohesion, it is a matter for the controlling application to determine when a confirm decision is appropriate.

3.2.5 Message sequence BTP messages are used in relationships between several pairs of roles. These particular pair-wise relationships c

o• Control Relationships : the application:BTP Actor relationships t

3 The “application element” from the perspective of BTP may include infrastructure software such as containers or interceptors, as well the application-specific code itself.


Participant(Inferior)EnrollerService

BEGIN

new (CONTEXT)

Initiator andTerminator Factory

Coordinator(Decider,Superior)

getContext()

createContext()

BEGUN

request & CONTEXT

enrol(CONTEXT)

new(CONTEXT)

ENROL

ENROLLED

response + CONTEXT_REPLY

CONFIRM_TRANSACTION

PREPARE

PREPARED

CONFIRM

CONFIRMED

TRANSACTION_CONFIRMED

1042 1043

1044 y 1045

ent 1046 is not sent until the ENROLLED has returned. 1047

(CONTEXT-REPLY does have a “related” relationship to an application message when used to 1048 pass the identifier for the new Inferior, though again the exact meaning will be defined by the 1049

1050

Figure 9 A conventional message sequence for a simple transaction

Note the CONTEXT, passed to the Initiator as a field of the BEGUN has “related” (&) relationship to the application request, although the exact meaning of this is defined by the application, not bBTP. The response + CONTEXT_REPLY need have no semantic significance, and could be sseparately, provided the CONTEXT_REPLY

application.)


The progression of a single instance of the central outcome (Superior:Inferior) relationship can also be presented as a set of state transitions. The normative part of the specification includestate tables for the Superior side of such a relationship and for the Inferior. Since a single Superior (Coordinator, Composer, Sub-coordinator, Sub-composer) can have multiple Inferiors, each Superior will have multiple instances of the “Superior state”. How these link together is discussed below in the section “3.2.7 Evolution of Confirm-set”, but the state transitions for the individual Superior:Inferior relationships include “decision events” which constrain the behaviour of the Business Transaction Tree Node as a whole, and thus define the semantics of the BTP messages. The normative state tables distinguish some states that differ only in which messages can be rece

1051 s 1052

1053 1054 1055 1056 1057 1058 1059 1060

ived and thus allow for a level of error checking. The progress of the Outcome Relationship 1061 1062 1063

1064 1065

r 1066 1067 1068 1069 1070

n event” – which may be an internal 1071 1072

NCEL 1073 1074 1075 1076

rrors, timeout or known recovery events) that messages 1077 1078

can be followed without dropping to such a detailed level, and the state diagrams shown here aggregate some of the states that are distinguished in the state tables. The single letters in parentheses in the diagrams correspond to the state names used in the tables. For simplicity, thestate diagrams do not include the events leading to the sending of a HAZARD message – the detection and recording of a “problem” – meaning that the Inferior is unable to cleanly Confirm ocleanly Cancel the operations it is responsible for. As is specified in the state tables, such a problem can be detected in most states, and reported with a HAZARD message. It should be noted that, with some exceptions, the transmission of a message from a Superior or Inferior does not cause a state change at that side. State changes are normally caused either by the receipt of a message from the Peer, or by a “decisiochange, including a change in the persistent information for the transactions, or may be the receipt of a message on another relationship (e.g. as when a Sub-coordinator receives CAfrom its Superior, which is a decision event as perceived on the relationships to its Inferiors). It would be normal for an implementation on entering a new state to send the message it can now send (there will be only one). It may repeat this message at any interval – in practice only if there is reason to believe (due to lower-layer emay have got lost.


Enrolling inferior (A)

Inferior Enrolled (B)

Preparing (D)

Prepared (E)

Resigning (C)

Resigned

Confirming (F)

Confirmed

Receive ENROL

Send ENROLLED

Receive RESIGN

Receive RESIGN

Cancelled

Cancelling (G)

TX Cancel-Contradiction

Contradicting(K)

TX Confirm-

(delete log)

Decide toconfirm(write log)

Send

(/auto)

ReceiveReceivePREPARED

PREPARED RESIGNED

Decide tocancel

Receive CANCELLED

Contradiction

Receive CONFIRMED

(delete log)Receive

CANCELLED

Send CONTRADICTION

Receive CONFIRMED

Send CANCEL

Send CONFIRM

Receive CANCELLED

(TX Confirmed)

Contradicting (L)(TX Cancelled)

Send CONTRADICTION

(I)

Decide toprepare send

PREPARE

One-phase-confirming (S)

Decide toconfirm

one-phase

SendONE_PHASE_CONFIRM

ReceiveFIRMED CON

Confirmed

1079 Figure 10 State diagram for Superior side of a Superior:Inferior relationship 1080


Enrolling (a)

Enrolled (b)

Preparing (d)

Prepared (e)

Resigning (c)

Created (i)

Resigned

Confirming (f)Cancelling (n)

Confirmed

Cancelled

Auto Cancelling (j)

Auto Confirming (h)

Send ENROL

Receive ENROLLED

ReceivePREPARE

Send CONFIRMED

(delete log)

Decide toprepare(write log)

Decide tocancel

(delete log)

Decide tocancel

Receive CANCEL

ReceiveReceive

CONTRADICTION(delete log)

Receive CONFIRM

ReceiveCONFIRM

Receive RESIGNED

Send CANCELLED

(delete log)

(delete log)

Send RESIGN

Send RESIGN

Decide toconfirm

CANCELReceive

CONTRADICTION

Confirm-Contradiction

Cancel-Contradiction

SendPREPARED

Send CANCELLED

Send CONFIRMED /auto

One-phase-confirming (s)

ReceiveCONFIRM_ONE_PHASESend

CANCELLED

SendCONFIRMED

Confirmed

1081 Figu1082

1083

In th NTEXT has been propagated from one 1084 determination of whether to 1085

a ct 1086 1087

may1088 Ele1089

re 11 State diagram for Inferior side of Superior:Inferior relationship

3.2.6 Control of inferiors e case as shown in Figure 12, where the CO

Application Element (A) to others (B, C, and from C to D,E), the cre te and enrol Inferiors is, in general, up to the receiving Application Element – this is an aspeof the fundamental autonomy of the parties involved in a Business Transaction. This autonomy

be constrained in particular situations, by inter-party agreement or where the Application ments are in fact under common control.


A (Initiator)

Composer

B

ParticipantB1

ParticipantB2

C

Sub-coordinator

D

Participant

E

Inf

Inf

Sup

Inf

Inf

Inf

Sup

Participant

Figure 12 Transaction Tree showing various application:Participant relationships

1090 1091

the 1092 ENR1093 app uperior-side 1094

1095 1096

con trolling 1097 . 1098

has rior 1099 is a1100 chil (thus, in Figure 12, the Composer at A is unaware of D and 1101

1102 The control exercised by the immediately 1103

to 1104 1105

that1106 p1107

s 1108 of th of the 1109 Con1110 imp1111 all I t. 1112

The relationship between the Application Messages and either the propagated CONTEXT or OL message(s) sent to the Superior is strictly part of the Application Protocol (or the

lication-with-BTP combination protocol). However defined, this allows the SApplication Element to be aware of what application work will be confirmed or cancelled under thecontrol of an Inferior. However, from the perspective of the Superior, and the Application Element

trolling it, the Inferior is opaque – it is not in general possible for the Superior or its conApplication Element to determine whether an Inferior is a Sub-composer or Sub-coordinator (i.e

Inferiors of its own) or is a Participant, with no further BTP relationships. Thus, if the Infe Sub-composer or Sub-coordinator, the Superior has no visibility or control of its “grand-dren” – the Inferiors of its Inferior

E) opacity of an Inferior does not however apply to the

controlling Application Element. An Application Element, acting as Terminator to a Decider (i.e. a Composer or Coordinator), can be aware of and distinguish the different Inferiors enrolled with

Decider (i.e. Inferiors enrolled with the Decider in its Role as Superior). (E.g.in Figure 12, lication EAp lement A knows of the Inferiors at C, B1 and B2) This is especially the case for a

Cohesion Composer, where the Terminator will be able to control which of the enrolled Inferiore Composer are eventually confirmed – more exactly, the application will have controlfirm-set for the Cohesion. For an Atom Coordinator, visibility of the Inferiors is useful but less ortant, since no selection can be made among which will be in the Confirm-set – for an Atom, nferiors are ipso facto members of the Confirm-se


For this control of the Inferiors to be useful, the Terminator Application Element will need to be able to associate particular parts of the application work with each Inferior. In a traditional transaction system, users do not need to see participants, but they see se

1113 1114

rvices or objects. What 1115 1116 n 1117

1118 its 1119

1120 ibility of both the identities of its inferiors and 1121

tify 1122 1123 1124

f 1125 1126 1127

d to 1128 1129 1130 1131 1132

(as 1133 1134

ciated, directly or indirectly, with each ENROL, and the Terminator Application 1135 Element can thus determine what each Inferior is responsible for. 1136

In both cases, the means by which the Application Message and the BTP CONTEXT or ENROL 1137 are associated are ultimately application-specific, and there are several ways this can be done. 1138 • At the abstract message level, BTP defines the concept of transmitting “related” BTP and 1139

Application Messages – particular bindings to Carrier Protocols can specify interoperable 1140 ways to represent this relatedness (e.g. the BTP message can be in a “header” field of the 1141 Carrier Protocol, the Application Message in the body). 1142

• An Application Message may contain fields that identify or point to the BTP message (e.g. the 1143 “inferior-identifier” from the ENROL may be a field of the Application Message). 1144

• BTP messages, including CONTEXT and ENROL, can carry “qualifiers” – extension fields 1145 that are not core parts of BTP or are not defined by BTP at all. The standard qualifier “inferior-1146 name” or application-specific qualifiers can be used to associate application information and 1147 the BTP message. The qualifiers received from the Inferiors on ENROL are visible to the 1148 Terminator application on the INFERIOR_STATUSES message. The application design will 1149 need to ensure that the Terminator can determine which parts of the application work are 1150 associated with each Inferior. 1151

NOTE -- For example, a service receiving an invocation associated with a 1152 Cohesion CONTEXT, but where the application design meant that there would be 1153 no more than one Inferior enrolled as a result of that invocation, could be required 1154 to include information identifying the service and the invocation in the “inferior-1155 name” qualifier on the consequent ENROL. These qualifiers would be visible to the 1156 Terminator on INFERIOR_STATUSES, allowing the Terminator to determine which 1157 “inferior-identifiers” to include in the “inferiors-list” parameter of the 1158 CONFIRM_TRANSACTION which defines which Inferiors are to be confirmed. 1159 Among other alternatives, the “inferior-identifier” itself could be a field of the 1160 application response – this would also be applicable where there could be multiple 1161 Inferiors enrolled as a consequence of one invocation for the Terminator to choose 1162 between. 1163

participants are enlisted with a transaction on behalf of those services and objects is not really ofinterest to the user. When it comes to commit or rollback the transaction, it acts on the transactioand not on the individual participants. In BTP that is still the case if we work purely with atoms. While an Atomic Coordinator knowsparticipants it cannot pick and choose among them. In contrast, a Cohesive Terminator must have significant, detailed knowledge and visassociation of parts of the application work with each Inferior. The user must be able to idenwhich participants to cancel/prepare/confirm. This identification can be achieved by various means. Taking the case of an Application Element controlling a Cohesion Composer:

a) The Application Element can create an Atom Sub-coordinator as an immediate Inferior othe Cohesion Composer and propagate the Sub-coordinator’s CONTEXT associated with Application Messages concerned with the particular part of the application work; any Inferiors (however many there may be) enrolled with Sub-coordinator can be assumebe responsible for (some of) that part of the application, and the Terminator Application Element can just deal with the immediate Inferior of the Composer that it created.

b) The Application Element can propagate the Composer’s own CONTEXT, and the receiving Application Element can create its own Inferior (or Inferiors) which will be responsible for some part of the application, and send ENROL(s) to the Composer Superior). Application Messages concerned with that part of the application are asso


These considerations about control of the Inferiors of a Decider also apply to the control of the 1164 Inferiors of a Sub-composer (and, again of less importance, a Sub-coordinator). 1165

3.2.7 Evolution of Confirm-set 1166

As mentioned above, the set of Inferiors of a Cohesion that will eventually Confirm is called the 1167 Confirm-set. The determination of the Confirm-set is made by the controlling application, but is 1168 affected by events from the Inferiors themselves. If the standard Control Relationship is used, the 1169 control of the Cohesion Composer is expressed by the Terminator:Decider exchanges, and the 1170 progressive determination of the Confirm-set (its evolution) is effectively the event sequence for 1171 the Terminator:Decider relationship. 1172 An Atom also has a Confirm-set, but this always includes all the Inferiors and so does not evolve 1173 in the same way as Cohesion’s. With some exceptions, the Terminator:Decider relationship is the 1174 same for Atom Coordinators as for Cohesion Composers; this section deals with both, noting the 1175 exceptions. 1176 The event sequence for a Composer or Coordinator is summarised in the state diagram in Figure 1177 13. The step-by-step description refers to “Composer”, but should be read as referring to 1178 Coordinators as well, unless stated otherwise. 1179 Initially, the Composer is created (by the Factory, using BEGIN with no related CONTEXT), and 1180 has no Inferiors. The Composer is now in the active state. 1181


Active

[Composer]PREPARE-INFERIORS

[Composer]CANCEL-INFERIORS

Cancelling Preparing

Confirming

Cancelled Confirmed

Create

D response recorded

1182 1183

1184 1185 1186 1187 1188 1189

ny 1190 1191

an Inferior; there is no required immediate effect, but if 1192 1193 1194 1195 1196 1197 1198

1199 th 1200 d 1201

CANCEL-TRANSACTIONor

[Atom]

CONFIRM-TRANSACTION

CANCELLED received from an Inferior

CANCELLED received from an Inferior in the confirm set

CANCELLED recorded from allor cannot persist confirm decision

PREPARED received fromall the confirm set

and confirm decision persisted

TRANSACTION-CANCELLED

CONFIRMEfrom all the confirm set

TRANSACTION-CONFIRMED

Figure 13 State diagram for a Composer or Coordinator (i.e. Decider)

While in the active state, the following may occur, in any order and with any repetition or overlapping: • Inferiors are enrolled – ENROL is received by the Composer – adding to the set of Inferiors of

the Composer. • Inferiors may resign - RESIGN is received from an Inferior (see section 3.3.3 Resignation

below). The Inferior is immediately removed from the set of Inferiors, as if it had never been enrolled (a RESIGNED message may be sent to the Inferior, but it no longer “counts” in aof the Composer-wide considerations here.

• CANCELLED may be received fromthis is a Coordinator the Atom will certainly Cancel eventually (and an implementation may choose to initiae cancellation immediately).

• PREPARED may be received; there is no immediate effect • The Terminator may issue PREPARE_INFERIORS to the Composer (as Decider) for some

subset of the Inferiors; PREPARE is sent to each and any of the Inferiors in the subset, excluding any from RESIGN, CANCELLED or PREPARED has been received; the sending of PREPARE will induce the Inferiors to reply with PREPARED, CANCELLED or RESIGN; whenreplies have been received from all, the Composer (as Decider) replies to the Terminator wiINFERIOR_STATUSES, reporting the replies received (which may in fact have been receive


before the PREPARE_INFERIORS). PREPARE_INFERIORS is not issued to Atom Coordinators.

• The Terminator may issue CANCEL_INFERIORS to the Composer (as Decider) for some subset of the Inferiors; CANCEL is sent to each and any of the Inferiors in the subset, excluding any from RESIGN or CANCELLED has been received; the sending of CANCnormally induce the Inferiors to reply with CANCELLED – th

1202 1203 1204 1205

EL will 1206 ere are some exception cases; 1207

1208 1209 1210 1211

ue REQUEST_INFERIOR_STATUSES to the Composer (as Decider) 1212 1213 1214

N 1215 that determines whether the 1216

and heuristic decisions or hazards within the 1217 omposer (as Decider) is sent to the 1218

Terminator. (See section “3.3.5 Autonomous cancel, autonomous confirm and contradictions” for 1219 es). 1220

1221 1222 1223 1224 1225

1226 1227 1228

fines the Confirm-set. If the parameter is absent (which it must be for an Atom 1229 1230 1231 1232

1233 d 1234

1235 from which neither CANCELLED or RESIGN has 1236

1237 s 1238

1239 e 1240

1241 SIGN is received from an Inferior, it is immediately removed from the 1242 ay trigger the decision making) 1243

1244 1245 1246

1247 1248 1249 1250 1251

when replies have been received from all, the Composer (as Decider) replies to the Terminator with INFERIOR_STATUSES, reporting the replies received. CANCEL_INFERIORS is not issued to Atom Coordinators. CANCEL_INFERIORS may be issued for an Inferior regardless of whether PREPARED has been received from it.

• The Terminator may issfor all or some subset of the Inferiors; the Composer immediately replies with INFERIOR_STATUSES, reporting the current state of the Inferiors as known to the Superior.

Eventually, the Terminator issues one of the completion messages – CANCEL_TRANSACTIOor CONFIRM_TRANSACTION. These messages have a flag Terminator wishes to be informed of contradictory transaction – this affects when the reply from the C

details on contradictory and heuristic casIf the message is CANCEL_TRANSACTION, CANCEL is sent to all Inferiors that it has not already been sent to, and from which neither RESIGN or CANCELLED have been received. If the Terminator indicates it does not want to be informed of contradictions, the Composer will immediately reply with TRANSACTION_CANCELLED. Otherwise, if and when CANCELLED or RESIGN has been received from all Inferiors, the Composer replies to the Terminator with TRANSACTION_CANCELLED; but if HAZARD or CONFIRMED is received from any Inferior, thereply is INFERIOR_STATUSES, identifying which Inferior(s) had problems. If the completion message is CONFIRM_TRANSACTION, the inferiors-list parameter of the message deCoordinator), then all Inferiors (excluding only those that have resigned) are the Confirm-set; otherwise the Confirm-set is only the Inferiors identified in the inferiors-list parameter (less any from which RESIGN has been received). The processing to arrive at the Confirm decision is: • If at the point of receiving CONFIRM_TRANSACTION or at any point before making the

Confirm decision (see below), CANCELLED is received, then the transaction is cancelled anprocessing continues as if CANCEL_TRANSACTION had been received.

• If there any Inferiors not in the Confirm-set been received, CANCEL is sent to them (this cannot happen for Atom Coordinators)

• If initially or later, there is exactly one Inferior in the Confirm-set, and either PREPARE hanot been sent to it, or PREPARED has been received from it, then at implementation or configuration option, CONFIRM_ONE_PHASE can be sent to that Inferior. This delegates thConfirm decision to the Inferior

• If at any point, REConfirm-set (this m

• If there are any Inferiors in the Confirm-set from which none of PREPARED, CANCELLED has been received and to which PREPARE has not yet been sent, PREPARE is sent to that Inferior

• If initially or later, PREPARED has been received from all Inferiors in the Confirm-set, theComposer makes the Confirm decision; it persists (or attempts to persist) information identifying the Inferiors in the Confirm-set; if this fails, the transaction is cancelled and processing continues as if CANCEL_TRANSACTION had been received; if the information is persisted, the Confirm decision has been made.


When the Confirm decision is made, CONFIRM is sent to all the Inferiors in the Confirm-set. And, if on the CONFIRM_TRANSACTION the Terminator indicated it did not wish to be informed ocontradictions, TRANSACTIO

1252 f 1253

N_CONFIRMED is sent to the Terminator. 1254 es to it 1255

1256 her 1257

1258 1259 1260 1261

in 1262 r messages represent the inferior-identifiers in the 1263

1264 e 1265 ot 1266

1267 the 1268

1269 1270 1271 1272 1273 1274

If the Terminator indicated it wanted to be informed of contradictions, the Composer repliwith TRANSACTION_CONFIRMED if and when CONFIRMED has been received from all the Inferiors in the Confirm-set and CANCELLED or RESIGN has been received from any otInferiors. If other replies (CANCELLED from a Confirm-set Inferior, CONFIRMED from other Inferiors, HAZARD from any) are received, the reply to the Terminator is INFERIOR_STATUSES, identifying which Inferior(s) had problems. Figure 14 shows an example message sequence for a Composer with three Inferiors. The Terminator (Application Element) chooses to prepare Inferiors 1 and 3 explicitly – the numbersparentheses on the Terminator:Compose“inferior-list” parameters. Both 1 and 3 prepare successfully, but the Terminator then decides to make 1 and 2 the Confirm-set; that is, if the transaction confirms only 1 and 2 are confirmed. ThTerminator issues CONFIRM_TRANSACTION to the Composer. A PREPARED message has nbeen received from Inferior 2 yet, so the Composer issues PREPARE to it, and waits for the PREPARED. At the same time, it sends CANCEL to Inferior 3, which has been excluded fromConfirm-set by the CONFIRM_TRANSACTION. After the PREPARED is received from Inferior 2, the Composer makes the Confirm decision and issues CONFIRM to the Inferiors, and waits for the CONFIRMED messages before reporting to the Terminator. The CONFIRM_TRANSACTION in this case did not ask for reporting of hazards (see below) – if it had not, the TRANSACTION_CONFIRMED would have been sent at the same time as the CONFIRM messages.


Participant(Inferior) 3



Initiator andTerminator

Composer(Decider,Superior)

CONFIRM-TRANSACTION (1, 2 )

CANCELLED

CONFIRM

PREPARE

PREPARED

CANCEL

PREPARED

PREPARE

CONFIRMED

CONFIRM

CONFIRMED

TRANSACTION-CONFIRMED

PREPARE_INFERIORS (1, 3)

INFERIOR_STATUSES (1, 3 )

PREPARE

PREPARED


1275

f intermediates 1276

1277 1278 1279

d 1280 ding 1281

1282 , 1283

1284 1285

poser or Sub-coordinator. 1286

Figure 14 Termination sequence for a composer

3.2.8 Confirm-set oAn Intermediate, that is a Superior that is also an Inferior, also has a Confirm-set, but this is controlled rather differently to the top-most Superior (Decider) described above. As an Inferior, the interface between the application and BTP Elements is not fully defined in this specification. However, within the standard Control Relationship, issuing BEGIN with a relateCONTEXT to a Factory will cause the creation of a Sub-coordinator or Sub-composer (depenon whether the BEGIN parameter asked for atomic or cohesive behaviour). Initially, of course, the new Intermediate has no Inferiors – however, unlike a Participant (in the strict sense of the term)it has a “superior-address” to which ENROL can be sent to enrol Inferiors. This address is a field of the new CONTEXT. Figure 15 is a state diagram for a Sub-com

Idle

RESIGN (one, or more, inferiors)or

Active

enrolledENROL from an inferior

or[Sub-Composer]

PREPARE (one, or more, inferiors)

[Sub-Composer]CANCEL (one, or more, inferiors)

Cancelling

CANCEL from superioror

[Sub-Coordinator]CANCEL received from an inferior

orlocal application decision

Preparing

CONFIRM_ONE_PHASE orPREPARE from superior

CANCELLED received from aninferior in the confirm set

CANCELLED recorded from all orcannot persist prepared decision

CANCELLED to superior

remove prepared decision (if persisted)

CancelledCancelledwith hazard

CONFIRMED or HAZARDreceived from an inferior

HAZARD (or CANCELLED)sent to superior

Prepared

PREPARED received fromall the confirm set and

prepared decision persisted

Confirming

Confirmed

CONFIRMED response recorded

CANCEL from superior

CONFIRM from superior

from all the confirm set

CONFIRMED sent to superior

remove prepared decision

Confirmedwith hazard

HAZARD (or CONFIRMED)sent to superior

CANCELLED or HAZARDreceived from an inferior

CONFIRM_ONE_PHASE receivedfrom superior and sent on to

single inferior

Figure 15 State diagram for Sub-coordinator or Sub-composer

The behaviour of the Intermediate towards its Inferiors, during the active phase, is basically the same as for the Decider: • ENROL messages can be received, adding a new Inferior

1287 1288

1289 1290 1291 1292 1293 1294 1295 1296

to 1297 s Superior at its own initiative (whereas a Decider can only respond to a 1298

1299 1300 1301 1302

b-coordinator, the Sub-1303 1304 1305

• Inferiors may resign - RESIGN is received from an Inferior. The Inferior is immediately removed from the set of Inferiors

• CANCELLED may be received from an Inferior • PREPARED may be received from an Inferior In some circumstances, receipt of an incoming message allows an Intermediate to determine that a state change for the whole Transaction Tree Node takes place. The Intermediate is able send messages to itreceived message from the Terminator), so the receipt of a message from an Inferior can trigger the sending of messages. This is especially the case if the Intermediate knows (from application knowledge, perhaps involving received or sent CONTEXT_REPLY messages) that there will be no further enrolments. In particular: • If CANCELLED is received from an Inferior, and this is a Su

coordinator can itself Cancel - CANCEL is sent to other Inferiors, and CANCELLED to the Superior


• If RESIGN is received from the only Inferior and there will be no other enrolments, the Intermediate can itself resign, sending RESIGN to the Superior

1306 1307

1308 1309

ropriate information) and send PREPARED to the Superior. 1310 be involved in determining what effect a 1311 – though in a real implementation, this logic 1312

may be delegated to the BTP-support software. 1313 ancellation or the two-phase outcome exchange, either as a result 1314

1315 1316

nferiors and send 1317 a 1318

Dec1319 hav E 1320 will ay be visible to the Application 1321

1322 fe1323

som1324 1325 1326 1327 1328 1329

, 1330 1331 1332 1333

ancel 1334 1335 1336

ordinator, CONFIRM is 1337 1338 1339 1340 1341 1342 1343 1344

r 1345 1346 1347

M_ONE_PHASE is received from the Superior, either before or after the Intermediate 1348 has Become Prepared, the effect is very similar to a Decider receiving 1349

nly one Inferior, the CONFIRM_ONE_PHASE may be 1350 e Intermediate behaves as a Decider, making a Confirm 1351

1352 1353

1354 1355 1356

• If PREPARED is received from the Inferior, it is known there will be no other enrolments andthis is a Sub-coordinator, the Sub-coordinator can Become Prepared (assuming successful persistence of the app

For a Sub-composer, application logic will invariablyCANCELLED and PREPARED from an Inferior have

The Intermediate may initiate cof receiving the corresponding message (CANCEL, PREPARE) from the Superior, or triggered by its own controlling Application Element. For a Sub-composer, this may be partial - a Sub-composer might be instructed by the Application Element to Cancel some IPREPARE to others. Receipt of PREPARE from the Superior will often have a similar effect to

ider receiving CONFIRM_TRANSACTION – PREPARE is propagated to all Inferiors that e not indicated they are PREPARED. However, exactly what happens on receiving PREPARdepend on the application – receipt of the PREPARE m

Element and cause it to initiate further application activity (perhaps causing enrolment of new In riors) before it is determined whether to propagate PREPARE; and with a Sub-composer,

e of the Inferiors may be instructed to Cancel instead. Assuming the Intermediate does not Cancel as a whole (in which case CANCEL would be sent to all Inferiors), the Intermediate will at some point attempt to Become Prepared. If it is a Sub-coordinator, this will require that PREPARED has been received from all Inferiors. For a Sub-composer, application logic will determine from which Inferiors PREPARED is required, with the others being cancelled. In either case, the Intermediate will persist the information about the Inferiors that are to be in the Confirm-set and about the Superior, if this persisting is successfulsend PREPARED to its own Superior. If CANCEL is subsequently received from the Superior, this is propagated to all the Inferiors and the persistent information removed (or effectively removed as far as recovery is concerned). It is not important which order this is done in, since the recovery sequence will ensure that a coutcome is eventually delivered anyway. If CONFIRM is received from the Superior (which can only be after sending PREPARED to the Superior), this is likewise propagated to the Inferiors. For a Sub-coinvariably sent to all Inferiors. However, for a Sub-composer it is possible that further application logic intervenes and some of the Inferiors are rejected from the Confirm-set at this late stage. (This can only occur when the application work, as defined by the Contract to the Superior, can be performed by some sub-set of the Inferiors.) The Intermediate may, but is not required to, change the persistent information to reflect the Confirm outcome (though a Sub-composer that selects only some Inferiors probably will need to re-write the information to ensure the correct subset are confirmed despite possible failures). If the information is not changed, then, on recovery, the Intermediate will find itself to be in a prepared state and will interrogate the Superioto re-determine the outcome. If the information is changed, a recovered Intermediate can immediately continue with ordering confirmation to its Inferiors. If CONFIR

CONFIRM_TRANSACTION. If there is opropagated to that Inferior. Otherwise, thdecision if it can. If one or more Inferiors make contradictory autonomous decisions, or HAZARD is received from an Inferior, the Intermediate may report this to the Superior using HAZARD. However, BTP doesnot require this. Since the Superior may be owned and controlled by a different organisation, there may be business reasons not to report such problems.


3.3 Optimisations and variations

3.3.1 Spontaneous prepared As described above, before a Superior can order confirmation to an Inferior, the Inferior must become “prepared”, meaning that it is ready to Confirm or to Cancel as it so ordered and send thPREPARED message as a report of this. In the conventional message sequence, as shown above, the Inferior attempts to Become Prepared when it receives a PREPARE message from the Superior. The PREPARE in turn is sent by the Superior when it receives an appropriate request from its controlling application (or from its own Superior, if there is one). The application controlling the Superior will request the sending of PREPARE when it determines that no further application work associated with this Inferior (or, perhaps with the whole Business Transactio

1357

1358

1359 e 1360

1361 1362 1363 1364 1365

n) 1366 1367 1368 1369 1370

d to Inferiors, it is possible for the Inferior-side Application 1371 1372 1373 1374 1375 1376 1377 1378 1379

1380

r 1381 1382

1383 1384 1385 1386

, it is 1387 1388

dination 1389 1390 1391 1392 1393 1394 1395 1396

ed by the user application itself, or might be performed by 1397 the path between the Application Elements. (Figure 9 could 1398

1399 1400

1401 1402

rior, the 1403 1404 1405

the 1406

will occur. However, for some applications, the Application Element controlling the Inferior will know that the application work for which the Inferior will be responsible is complete before a PREPARE is sent from the Superior. In fact, because the Application Element has autonomy in determining how application work is to be allocateElement to know the work is complete for a particular Inferior when Superior-side Application Element will be sending more message to the Inferior-side. (The future work will, probably, require the enrollment of additional Inferiors.) BTP consequently allows the Application Element controlling an Inferior to cause the Inferior to Become Prepared, and to send PREPARED to the Superior without PREPARE having been received from the Superior. From the perspective of the BTP Superior the Inferior sends PREPARED spontaneously. Apart from this, a spontaneous PREPARED message is the same as, and has the same effect and implications as one induced by a PREPARE message.

3.3.2 One-shot In the “conventional” message sequence shown above and assuming the Initiator, Terminatoand Coordinator on the one side, and “Service”, Enroller and Participant on the other are locatedwithin their respective parties, there are eight messages passed in one direction or the other between the two parties. There are four round-trip exchanges: the application request and response exchange, the ENROL/ENROLLED exchange (going in the opposite direction and overlapped with the application exchange), then PREPARE/PREPARED and the CONFIRM/CONFIRMED. However, if the application exchange is a single request/responsepossible to reduce these eight to two round-trips– the first of which merges the first three of the conventional sequence. The fundamental two-phase nature of BTP (or any coormechanism) means there have to be at least two round trips – one before the Confirm-or-Cancel decision is made at the Superior, one after. This merging of the exchanges is termed “one-shot”, as it requires only one exchange to take the relationship from non-existent to waiting for the Confirm-or-Cancel decision. Figure 16 shows a typical “one-shot” message sequence. The diagram distinguishes an additional aspect of the Application Elements, labelled “context-handler”. This is not a Role in the BTP model, but is used only to distinguish a set of responsibilities and actions. In a real implementation these might be performthe BTP-supporting infrastructure on be redrawn to show the context-handlers, but to no particular benefit) As in the conventional case, the CONTEXT is sent related to the application request (the creation of the CONTEXT bythe Factory is not shown and is the same as the conventional case). The “context-handler” is aware of the sending of the CONTEXT. On the responder (service side), however, when the Application Element creates the InfeENROL is not sent immediately, but retained. The application performs the “Provisional Effect” implied by the received message and the Inferior becomes prepared and issues a PREPARED message, which is also retained. When the application response is available, it is sent with


retained messages and the CONTEXT_REPLY (which indicates that the related ENROL will complete the enrolments implied by the earlier transmission of the C

1407 ONTEXT. 1408

ntained 1409 1410 1411

n 1412 1413 1414

1415 1416 1417 1418 1419 1420 1421 1422 1423 1424

When this group of messages is received by the context-handler on the Client side, the coENROL and PREPARED messages are forwarded to the Superior (whose address was on the original CONTEXT and so is known to the context-handler). An ENROLLED message is sent back to the context-handler, assuring it that the enrolment was successful and the application caprogress. If enrollment fails and the Business Transaction is atomic, confirmation must be prevented – this responsibility falls on the context-handler and the Client application, since the failure of the enrolment implies that Superior itself is inaccessible. If enrolment fails and theBusiness Transaction is a Cohesion, the appropriate response is a matter for the application. With “one-shot”, if there are multiple Inferiors created as a result of a single Application Message, there is an ENROL and PREPARED message for each one sent related with the CONTEXT_REPLY. If an operation fails, a CANCELLED message may be sent instead of a PREPARED – if the Superior is atomic, this will ensure it cancels, if cohesive, the Client application will be aware of this and behave appropriately. Whether the “one-shot” mechanism is used is determined by the implementation on the responding (Inferior) side. This may be subject to configuration and may also be constrained by the application or by the binding in use.


Participant(Inferior)EnrollerServiceI

Tnitiator anderminator

Context_Handlerat Initiator-side


request & CONTEXT

CONFIRM_TRANSACTION

CONFIRM

CONFIRMED

TRANSACTION_CONFIRMED

Context_Handlerat Service-side

request

request & CONTEXT

enrol(CONTEXT)

new (CONTEXT)

ENROLLED

response + CONTEXT

PREPARED

ENROL

response + CONTEXT_REPLY& ENROL & PREPARED

ENROL + PREPARED

response

1425 hot” optimisation 1426

1427

s 1428 1429

1430 1431 1432 1433

een received is not considered an Inferior in discussion of 1434 1435

1436

1437 st 1438

1439 1440

ads to 1441

Figure 16 A message sequence showing the “one-s

3.3.3 Resignation After an Inferior is enrolled, it may be determined that the application work it is responsible for hano real effect – more exactly, that the Counter-effect, if cancelled, and the Final Effect, if confirmed, will be identical. In such a case the Inferior can effectively un-enrol itself by sending aRESIGN message to the Superior. This can be done “spontaneously” (as far as BTP is concerned) or as a response to a received PREPARE message. It cannot be done after the Inferior has Become Prepared. An Inferior from which RESIGN has bthe Confirm-set – the phrase “remaining Inferiors” is used to mean only non-resigned Inferiors.

3.3.4 One-phase confirmation If a Coordinator or Composer that has been requested to Confirm has only one (remaining) Inferior in the Confirm-set, it may delegate the Confirm-or-Cancel decision to that Inferior, jurequesting it to Confirm rather than performing the two-phase exchange. This is done by sending the CONFIRM_ONE_PHASE message. Unlike the two-phase exchange (PREPARED received, CONFIRM sent), it is possible with CONFIRM_ONE_PHASE for a failure to occur that le


the original Coordinator or Composer (and its controlling Application Element – the Termbeing uncertain whether the outcome was confirmation or cancllation.

3.3.5 Autonomous cancel, autonomous confirm and contradictionsAs described above, BTP does not require a Participant, while it is responsible for holding

inator) 1442 1443

1444

1445 1446

1447 ect” 1448

nly 1449 1450 1451 1452 1453 1454 1455

pplication Element and the Participant) 1456 may need to limit the promise made by sending PREPARED, and retain the right to apply its own 1457 decision to Confirm or Cancel to the Participant a cation effects it is responsible for. 1458 This is described as an “autonomous” decision. It is closely analogous to the heuristic decisions 1459

e conceptual one that 1460 1461 1462 1463

they 1464 1465 1466

ncy of 1467 1468 1469 1470

perior). An Inferior taking an 1471 , as 1472 he outcome 1473

ions 1474 1475

com er, 1476 regardle ge is 1477 needed1478 If th u 1479 record t to management systems or inform the Terminator application or its own 1480

1481 1482

), the 1483 1484 1485 1486 1487 1488 1489 1490

epared promise to remain valid. 1491 1492 1493

application resources such that can be confirmed or cancelled, to use any particular mechanismfor maintaining this state. A Participant that “becomes prepared” may choose to let the “Provisional Effect” be identical to the “Final Effect”, and hold a compensating “counter effready to implement cancellation; or it may make the Provisional Effect effectively null, and operform the real application work as the Final Effect if confirmed; or the “Provisional Effect” may involve performance of the application work and locking application data against other access; or other patterns, as may be constrained or permitted by the application. Although a Participant is not required to lock data (as would be the case with some other transaction specifications) on becoming prepared, it is nevertheless in a state of doubt, and this doubt may have application or business implications. Accordingly it is recognised that a Participant (or, rather the business party controlling the A

nd the appli

recognised in other transaction specifications. The only difference is thheuristic decisions are typically considered to occur only as a result of rare and unpredictable failure, whereas BTP recognises that the right to take an autonomous decision may be critical to the willingness of a business party to be involved in the Business Transaction at all. BTP therefore allows Participants (and all Inferiors) to indicate that there are limits on how longare willing to promise to remain in the prepared state, and that after that time they may invoke their right of taking an autonomous decision. Taking an autonomous decision will of course run the risk of breaking the intended consisteoutcome across the Business Transaction, if the autonomous decision of the Inferior contradicts the decision (for this Inferior) made by the Superior. The Superior will have received the PREPARED message and thus be permitted to make a Confirm decision (directly, or through exchanges with a Terminator Application Element or with its own Suautonomous decision informs the Superior by sending CONFIRMED or CANCELLEDappropriate, without waiting for an outcome order from the Superior. This may cross tmessage from the Superior, or the Superior may not make its decision till later. If the decisagree, the normal CONFIRM or CANCEL message is sent. In the case of CANCEL, this

pletes the relationship – the CANCEL and CANCELLED messages acknowledge each othss of which travels first. In the case of CONFIRM, another CONFIRMED messa

. e S perior’s decision is contradicted by the autonomous decision, the Superior may need to

his, report itSuperior. When this has been done (details are implementation-specific, but may be constrainedby the application), the Superior sends a CONTRADICTION message to the Inferior. If an outcome message was sent earlier (crossing the announcement of the autonomous decisionInferior will already know there was a contradiction, but the receipt of the CONTRADICTION message informs the Inferior that the Superior knows and has done whatever it considers necessary to cope. As mentioned, BTP allows an Inferior to inform the Superior, with a qualifier on the PREPARED message, that the promise to remain in the prepared state will expire. In turn this allows the application on the Superior side to avoid risking a contradictory decision by making and sending its own decision in time. The Superior side can also indicate, with another qualifier, a minimum time for which it expects the prAs well as deliberate and forewarned autonomous decisions, BTP recognises that failures and exceptional conditions may force unplanned autonomous decisions. In the protocol sequence


these are treated exactly like planned autonomous decisions – if they contradict, the Superior wbe informed and a CONTRADICTION message sent to the Inferior. Autonomous decisions, planned or unplanned, are equivalent to the heuristic decisions of other transaction systems. The term is avoided in BTP since it may carry implications that it only occurs in an unplanned manner.

3.4 Recovery and failure handling

3.4.1 Types of failure

ill 1494 1495 1496 1497 1498

1499

1500

the 1501 1502 1503 1504

lost, but does not assume that all losses are reported nor that messages 1505 1506

• re): a machine hosting one or more BTP 1507 1508

1509 Com e may become known to a BTP implementation by an indication from the 1510

1511 com quires only that the two Actors can again send messages to each other 1512

1513 of 1514

1515 e state information will be persisted despite Network Node failure. 1516

1517 1518 1519 1520

destruction 1521 1522 1523 1524

s; 1525 1526 1527

of 1528 1529 1530 1531

ion behaves much as if a communication failure had 1532 1533

1534

s an 1535 Inferior’s decision to be prepared, a Superior’s decision to Confirm and an Inferior’s autonomous 1536 decision . Requiring the first two to be persistent ensures that a consistent decision can be 1537 reached for the Business Transaction and that it is delivered to all involved BTP Nodes, despite 1538 failure. Requiring an Inferior’s autonomous decision to be persistent allows BTP to ensure that, if 1539 the autonomous decision is contradictory (i.e. opposite to the decision at the Superior), the 1540 contradiction will be reported to the Superior, despite failures. 1541

BTP is designed to ensure the delivery of a consistent decision for a Business Transaction toparties involved, even in the event of failure. Failures can be classified as: • Communication failure: messages between BTP Actors are lost and not delivered. BTP

assumes the Carrier Protocol ensures that messages are either delivered correctly (without corruption) or are sent separately are delivered in the order of sending. Network Node failure (system failure, site failuActors stops processing and all its volatile data is lost. BTP assumes a site fails by stopping –it either operates correctly or not at all, it never operates incorrectly. munication failur

lower layers or may be inferred (or suspected) by the expiry of a timeout. Recovery from a munication failure re

and continue or complete the progress of the Business Transaction. A Network Node failure is distinguished from communication failure because there is loss volatile state. To ensure consistent application of the decision of a Business Transaction, BTP requires that somImplementations choose, depending on application requirements, what real events correspond toNetwork Node failure but leave the persistent information undamaged; however, for most application uses, power failure should be survivable (an exception would be if the data manipulated by the associated operations was volatile). In all cases, there will be some level of event sufficiently catastrophic to lose persistent information and the ability to recover– of the computer or bankruptcy of the organisation, for example. Recovery from Network Node failure involves recreating an accessible communications endpoint in a Network Node that has access to the persistent information for incomplete transactions. This may be a recreation of the original Actor using the same addresses; or using a different addresor there may be a distinct recovery entity, which can access the persistent data, but has a different address; other implementation approaches are possible. The recovered, and possibly relocated Actor may or may not be capable of performing new application work. Restoration the Actor from persistent information will often result in a partial loss of state, relative to the volatile state reached before the failure. In some states, there may be total loss of knowledge of the Business Transaction, including particular Superior:Inferior relationships. After recovery from Network Node failure, the implementatoccurred.

3.4.2 Persistent information BTP requires that certain state information is persisted – these are information that record


BTP also permits, but does nostate (unlike many transaction

t require, recovery of the Superior:Inferior relationship in the active 1542 protocols, where a communication or node failure in active state 1543

rollback of the transaction). Recovery in the active state may require that 1544 e is resynchronised as well – BTP does not directly support this, but 1545

1546 1547 1548 1549 1550 1551 1552 1553 1554 1555

rior. 1556 1557 1558 1559 1560 1561 1562 1563

r that is an intermediate in the tree – i.e. it is an Inferior to some other 1564 he information about each of its own Inferiors as part of (or before) 1565

as 1566 s 1567

1568 1569 1570

nd there is a node failure, 1571 1572 1573

e 1574 1575 1576

carr plies both to qualifiers on PREPARED (which would be persisted 1577 uld be persisted by the Superior). 1578

1579 1580

1581 1582

d 1583 sion. 1584

1585

1586 1587

1588 visible 1589

1590 the re-establishment of 1591

rs. 1592 1593

would invariably causethe application exchangallows continuation of the Business Transaction if the application desires it. Apart from the (optional) recovery in active state, BTP follows the well-known presume-abort model – it is only required that information be persisted when decisions are made (and not, for example, on enrolment). This means that on recovery one side may have persistent information while the other does not. This occurs, among other cases, when an Inferior has decided to be prepared but the Superior never confirmed (so the decision is “presumed” to be cancelled), and when the Superior did Confirm, the Inferior applied the confirmation and removed its persistent information but the acknowledgement message (CONFIRMED) was never received by the.Superior. Information to be persisted when an Inferior decides to be prepared has to be sufficient to re-establish communication with the Superior, to apply a Confirm decision and to apply a Cancel decision. It will thus need to include the addressing and identification information for the SupeThe information needed to apply the Confirm or Cancel decision will depend on the application and the associated operations. A Superior must persist the corresponding information to allow it to re-establish communication with the Inferior – that is the addressing and identification information for the Inferior. When it must persist this information depends on its position within the Transaction Tree. If it is the top of the tree – i.e. it is the Decider for the Business Transaction -- it need only persist this information if and when it makes a decision to Confirm (and, for a Cohesion, only if this Inferior is in the Confirm-set). A SuperioSuperior –must persist tpersisting its own decision to be prepared. For such an intermediate, the “decision to confirm” Superior is made when either CONFIRM is received from its Superior or it makes an autonomoudecision to Confirm. If CONFIRM is received, the persistent information may be changed to show the Confirm decision, but alternatively, the receipt of the CONFIRM can be treated as the decision itself and the CONFIRM message propagated to the Inferiors without changing the persistent information. If the persistent information is left unchanged aon recovery the entity (as an Inferior) will be in a prepared state, and will rediscover the Confirm decision (using the recovery exchanges to its Superior) before propagating it to its Inferior(s). Since BTP messages may carry application-specified qualifiers, and the BTP messages may brepeated if they are lost in transit (see next section), the persistent information may need to include sufficient information to recreate the qualifiers, to allow them to be resent with their

ying BTP message. This apby the Inferior) and on CONFIRM (which woIn some cases, an implementation may not need to make an active change to have a persistent record of a decision, provided that the implementation will restore itself to the appropriate state onrecovery. For example, an implementation that, as Inferior, always used the default-is-cancel mechanism, and recorded the timeout (to Cancel) in the persistent information on becoming prepared, and always updated or removed that record when it applied a Confirm instruction coultreat the presence of an expired record as effectively a record of an autonomous Cancel deci

3.4.3 Recovery messages Once the Superior:Inferior relationship has entered the completion phase, BTP does not generallyuse special messages in recovery, but merely permits the resending of the previous message.Thus, for example, PREPARE, PREPARED, CANCEL, CONFIRM can all be sent repeatedly. Resending the previous message means a possible loss of the original message may be into the receiver. The trigger for this re-sending is implementation dependent – a reported communication failure, a timeout expiry while waiting for a reply,communications or the general restoration of function after a node failure are all possible triggeAn incoming repetition of the last message received, if it has already been replied to (e.g.


receiving PREPARE after PREPARED has been sent), should normally trigger a resending of thelast message sent – since that sent message may have got lost.

1594 1595 1596 1597 1598

1599 e 1600

1601 R_STATE message, that reply does not ask for a 1602

1603 1604

1605 ernatively, it can reply with a SUP|INFERIOR)STATE 1606

message with a status showing that the message has been received but the definitive reply is not 1607 be particularly useful in long-lived business transactions, where the time 1608 de may be much longer than a reasonable retry time. 1609

1610 1611 1612

n 1613 1614

ERIOR_STATE messages are also available as replies to any Superior:Inferior 1615 message in the (transient, one hopes) case where, after failure, an implementation cannot 1616

ine whether the persistent information exists or not, or what its state is, and so 1617 finitive answer. A SUP|INFERIOR_STATE message with a status of 1618

1619 1620

1621

As described above, BTP uses the presume-abort model for recovery. A corollary of this is that 1622 there are cases where one side will attempt to re-establish communication when there is no 1623 persistent information for the relationship at the far-end, because that side either never reached a 1624 state where the state was persisted, or had been persisted, but then progressed to remove the 1625 state information. In such cases, it is important the side that is attempting recovery can 1626 distinguish between unsuccessful attempts to connect to the holder of the persistent information 1627 and when the information no longer exists. If the Peer information does not exist, the side that is 1628 attempting recovery can draw appropriate conclusions (that the Peer either was never prepared, 1629 never confirmed or has already completed) and complete its part of the transaction; if it merely 1630 fails to get through, it is stuck in attempting recovery. 1631 Two mechanisms are provided to assist implementation flexibility while allowing completion of 1632 Superior:Inferior relationships when only one side has any persistent information. The 1633 mechanisms are: 1634 • Address fields which provide the address that will be used by the Peer to send messages to 1635

an Actor (effectively a “callback address”) can be a set of addresses, which are alternatives, 1636 one of which is chosen as the target address for the future message. If the sender of that 1637 message finds the address does not work, it can try a different alternative. 1638

4 While in the active phase – i.e. prior to entering completion – there is no appropriate last message that can be sent. However, for active-phase recovery there needs to be some way for the BTP Actors to determine that the Peer is still there and still aware of the Superior:Inferior relationship. In this case, the peers can interrogate each other using the INFERIOR_STATE orSUPERIOR_STATE messages, informing the Peer of their own state and requesting a respons– which may be the opposite message, or one of the main BTP messages (which perhaps had been lost). If it is another SUP|INFERIOresponse. Receiving a SUP|INFERIOR _STATE messages that asks for a response does not require an immediate response. Especially if an implementation is waiting to determine a decision(perhaps because it is itself waiting for a decision from elsewhere), an implementation may choose not to reply until it wishes too. Alt

yet available. This mayfor a decision to be maThe SUP|INFERIOR_STATE messages are also used as replies when the receiver of any of the Superior:Inferior message has determined that there is no corresponding state information – the targeted Superior or Inferior does not exist (or is known to have completed and is no longer an active entity). The SUP|INFERIOR_STATE messages with a status of “unknown” is the indicatiothat the state information does not exist. The SUP|INF

currently determcannot give a de“inaccessible” indicates that the existence of state information cannot be determined. The receiver of such a message should normally treat it as a “retry later” suggestion.

3.4.4 Redirection

4 BTP’s capability of binding to alternative carrier protocols is part of the motivation for not having a distinct recovery message sequence, since the carrier binding does not necessarily have a well-defined communication failure indication.


• The REDIRECT message can be used to inform the Peer that an addressno longer valid and to supply a replacement address (or set of addresses

previously given is 1639 ). REDIRECT can 1640

be issued either as a response to receipt of a message or spontaneously. 1641 The two mechanisms can be used in combination, with one or more of the original set of 1642

ct access to the state 1643 riate REDIRECT. 1644

1645 1646

ges. 1647 r, 1648

1649 1650

1651 1652

ith 1653 d 1654

1655

1656

1657 1658

wledge of the Decider’s address and identifier), but this is an implementation 1659 1660 1661 1662

initiating a call to a Terminator to ensure that it is still active, and thus no 1663 1664 1665 1666

he 1667 applic mit” can 1668 be us t request 1669 confir o it (the Decider) should initiate cancellation. 1670

and hazard 1671

cancel, autonomous confirm and contradictions”), in 1672 e 1673

p1674 on the PREPARED mes1675

1676 r. An 1677

auto ly a contradiction – it only results in a contradiction if 1678 e 1679

1680 nd communication failures, it is 1681

req1682 messag er that there was no contradiction (the 1683 deci1684 rece1685 (CONTR ecome aware of the fact of the 1686 contradi sion 1687 until it r 1688

addresses just being a redirector, which does not itself ever have direinformation for the transaction, but will respond to any message with an appropREDIRECT as a message is only used on the Superior:Inferior relationship, where each side holds the address of the other. On the other relationships (e.g. Terminator:Decider), one side (e.g. Terminator) has the address of the other, and initiates all the message exchanHowever, the entity whose address is known to the other may itself move - e.g. if a Coordinatowhich will be both Decider and Superior changes its address as a Superior, it will probably change its address as a Decider too. In this case, a FAULT reply to a misdirected message canbe used, assuming there is some entity available at, or on the path to the old address that understands BTP sufficiently to provide the redirection information. Some implementations, in which a single addressable entity with one constant address deals wall transactions, distinguishing them by identifier, will not need to supply “backup” addresses (anwould only use REDIRECT if permanently migrated).

3.4.5 Terminator:Decider failures and transaction timelimit BTP does not provide facilities or impose requirements on the recovery of Terminator:Decider relationships, other than allowing messages to be repeated. A Terminator may survive failures (by retaining knooption. Although a Decider (if it decides to Confirm) will persist information about the Confirm decision, it is not required, after failure, to remain accessible using the address it originally gave to the Initiator (and used by the Terminator). Any such recovery is an implementation option. A Decider has no way ofway of detecting that a Terminator has failed. The Decider always has the right to initiate cancellation, but if the application (Terminator) and the Decider have different views about how long a “long time” is, then either the Decider might wait unnecessarily for a completion request (e.g. CONFIRM_TRANSACTION) that will never arrive, or it might initiate cancellation while t

ation is still active. To avoid these irritations, a standard qualifier “Transaction timelied (by the Initiator) to inform the Decider when it can assume the Terminator will nomation and s

3.4.6 ContradictionsAs described above (see “3.3.5 Autonomoussome circumstances an Inferior may apply a decision that is contradictory to the decision of thSu erior. This can occur in a semi-planned manner, when the Inferior has announced a timeout

sage but no outcome message has been received, or as a result of an exceptional condition that forces the Inferior to break the promise implicit in PREPARED, regardless of timers. In both cases, this is considered an autonomous decision by the Inferio

nomous decision, of itself, does not impthe decision is opposite to that of the Superior (in the case of a cohesive Superior, opposite to thdecision that applies to this Inferior). In order to ensure that a contradiction is detected despite node a

uired that information about the taking of the autonomous decision be persisted until a BTP e received from the Superior indicates eith

sions were in line – CANCEL is received after an autonomous Cancel or CONFIRM is ived after an autonomous Confirm) or that the Superior is aware of the contradiction

ADICTION is received). Note that the Inferior will bction when it receives the “wrong” message, but must retain the record of its own deci

eceives the CONTRADICTION message, which tells it the Superior knows too.


The1689 specification. In particular, if the Superior is a Sub-coordinator or Sub-composer, it is not required 1690 by t s 1691 controlled by 1692 systems the 1693 contradi rminator Application Element. 1694 A c a1695 conditio1696 cancelle1697 coordin mixed condition to its own Superior with the 1698 HAZ n report the problem with the 1699 INF I 17 shows a 1700 messag mous 1701 Can1702 Coordin ed on by the Sub-coordinator, crosses with the CANCELLED message from the 1703

1704 1705

Superior’s action on becoming aware of the contradiction is not determined by this

his pecification to report the contradiction to its own Superior (which may, for example, bent a different organisation). The Superior may report the problem to manageme

or record it for manual repair. However, BTP does provide mechanisms to report ction to the next higher Superior (if there is one) or to the Te

ontr diction occurring in an Inferior will usually mean the immediate Superior has a “mixed” n – some of the application work it was responsible for has confirmed, some has d (and contrary to any Cohesion Confirm-set selection). If the Superior is a Sub-

ator or Sub-composer, it can report theARD message. If the Superior is the top-most in the tree, it ca

ER OR_STATUSES message, which will detail the state of all the Inferiors. Figuree sequence in a Transaction Tree with two levels. The Participant makes an autono

cel decision, but the Coordinator decides to Confirm. The Confirm decision from the ator, pass

Participant. The Participant waits for the CANCELLED from the Sub-coordinator, which chooses to report the problem with HAZARD to the Coordinator.

Participant(Inferior)Sub-Coordinator


CONFIRM

PREPAREPREPARE

PREPARED (+timeout)

CANCELLED

CONFIRM

CONTRADICTED

PREPARED

HAZARD

1706 Figure 17 Message sequence showing contradiction, reported with HAZARD 1707

If a Sub-coordinator or Sub-composer, having sent (or attempted to send) the outcome message 1708 to its Inferiors, is temporarily unable to get a response (CONFIRMED or CANCELLED), it may 1709 either wait until a response does come back or choose to reply to its own Superior with a 1710 HAZARD message indicating that a contradiction is “possible”. If it does choose to send 1711 HAZARD, it is required to persist a record of this until it receives a CONTRADICTION message 1712 from the Superior, or a message from the Inferior indicating there was no contradiction in fact. 1713


HAZARD is also used to indicate that it has become impossible to cleanly and consistently 1714 achieve either a confirmed or a cancelled state for the application work. In this case, there is can 1715 be no guarantee that the problem will be reliably reported – especially because it may be the 1716 inability to persist information that is the cause of the problem. 1717

3.5 Relation of BTP to application and Carrier Protocols 1718

BTP messages are communicated between Actors in two distinguishable circumstances: 1719 a) in establishing and progressing the outcome and Control Relationships between BTP 1720

Actors, and between Application Elements and BTP Actors – Initiator:Factory, 1721 Terminator:Decider, Superior:Inferior etc. 1722

b) in association with Application Messages that are communicated between Application 1723 Elements. 1724

In the first case, interoperable communication requires a specification of how the abstract BTP 1725 messages are represented and encoded, and how they are transmitted. This specification is a 1726 carrier protocol binding (or just “binding”, if the context is clear). BTP allows bindin1727

only requirement that BTP makes is that the transmission of 1728 pted message or fails. BTP does not require that the carrier 1729

report failure to deliver a message, to either side, nor that messages are delivered in the order 1730 they are sent (though implementations can take a vantage of information from a richer carrier, 1731

various ways). BTP messages communicated in this way have 1732 ck 1733 e 1734

1735 on. Interoperation with 1736

1737 TP. 1738

be 1739 he combination of the Application 1740

rate such that the two 1741 ness Transaction. This 1742

will often be achieved by sending Application Messages and BTP messages in “association” in 1743 ge sent in association with a CONTEXT can be specified 1744

1745 1746 1747 1748 1749 1750 1751

a 1752 1753

uperior-identifier or inferior-identifier that 1754 1755

1756 1757 1758 1759 1760

gs to a multiplicity of Carrier Protocols. The a message either delivers an uncorru

dwhich can improve performance insemantics that are defined in this specification – a PREPARE message (for example), refers bato the ENROL via the “inferior-identifier” parameter and is an instruction to the Inferior to becomand report that it is prepared. In the second case, the full semantics cannot be defined in this specificatiBTP requires that the parties have a common understanding of what is being confirmed or cancelled, but this mutual understanding is defined by the Contract of the application, not by B(The Contract may be explicit or implicit, declared by one side as take-it-or-leave-it, or maynegotiated in some way.) Part of this Contract will include how tProtocol (i.e. the Application Messages and their sequencing) and BTP opesides are agreed as to which Application Operations are part of which Busi

some way – thus an Application Messa(by the application Contract) to mean that if work is done as result of the receipt of the message, one or more Inferiors should be enrolled to apply the Confirm/Cancel decision to that work. Similarly, an Application Message may be sent associated with an ENROL with the contractual understanding that the message refers to some application work that has been made the responsibility of the Inferior being enrolled. The concrete representation of this “association” is also a matter for the Application Protocol specification. There are several ways this can be done, including: • the BTP message is contained within the Application Message, or both are contained within

larger construct; • the Application Message contains a field that is the s

is also present on the CONTEXT or the ENROL • the BTP message contains a qualifier that references (a field of) the Application Message in

some way (e.g. if the Application Message is an invoice, the qualifier might contain the invoice number)

• the encoding of the BTP and Application Messages reference each other (e.g. using XML id and refid attributes)


In all cases, n5 will need to define the mechanism so that both parties 1761 have commo lications w anism and their 1762 specification refore take advantage of stan s, and their implementations of 1763 standard too1764 The associa cation Message with a B to the concept of 1765 “related” BT s. “Related” BTP messages declared and 1766 defined sem Associated applica can be considered as 1767 “related”, wi hat the semantic is defin not by BTP. 1768 There is no onship between how the Application Messages and any associated 1769 BTP messag er Protocol r binding for the BTP 1770 messages. B ably sent to a BTP Actor whose address has been passed to 1771 the sender b ans – thus a CONTEXT contains the address of the Superior to which 1772 ENROLs wil ROL contains the address of the Inferior. Similarly, BEGUN 1773 contains the f the new Comp ordinator. These addresses are all 1774 sets of addr d entifies which 1775 binding is to C d with an 1776

pplication Message, the ENROL will travel on a carrier binding identified by the particular 1777 p to 1778

1779 Despite this, it will be common that the application binding and the BTP binding will use the same 1780

case in the bindings specified in this edition of the specification, which define a 1781 1782 1783

e SOAP body. 1784

1785

1786

tion of the state corresponding to one of Decider, 1787 1788

1789 1790

it 1791 1792

1793 1794

), 1795 s are 1796

specified, in the XML representation, as syntactically URIs - by their use as names of BTP 1797 entities, they are URNs. If an Identifier happens to location (i.e. it is a URL), it is 1798 treated as a ue by BTP) 1799 Identifiers ar s being globally unambiguous - the same Identifier only ever identifies 1800 one Decider r Inferior over all systems and all time. In practice, an Identifier could be 1801 re-used if there is no possibility of the colliding values being confused. However implementations 1802 are recomm ous Identifi rs (that is to use them as URNs). 1803

the application specificatio understanding. Many appn

s can theill use the sadard pattern

me mech

ls. tion of an Appli TP message is analogous

with aP message are sent as a group,antic for the group. tion and BTP messages

d by the application, th the proviso t enecessary relaties are transmitted by Carri

ges are invaris, and the carrie

TP messay some mel be sent, and the ENaddress (as Decider) o oser or Co

esses (possibly of cardinality one), an be used. Thus, for example, when a

each individual address idONTEXT is sent associate

Aaddress from the CONTEXT that the Enroller chooses to use – which may have no relationshihow the Application Message arrived.

carrier. This is the binding of BTP to SOAP 1.1 over HTTP. Included in this SOAP/HTTP binding specification, are rules that allow an application to associate (relate) a single CONTEXT or a single ENROL (carried in the SOAP header) with the Application Message(s) carried in th

3.6 Other elements

3.6.1 Identifiers An Identifier is a globally unambiguous identificaSuperior or Inferior. Where a single entity has more than one of these roles (at the same BTPNode in the same transaction, as with a Sub-coordinator that is both Superior and Inferior), the Identifiers may be the same or different, at implementation option - they are distinguished by which messages the Identifier is used on. (A Superior has only one Superior-identifier, although may be in multiple Superior:Inferior relationships, each with a separate state in terms of the statetable). The state identified by an Identifier can be accessed by BTP messages sent to any of the addresses supplied with the Identifier in the appropriate message (CONTEXT, BEGUN, ENROLor as updated by REDIRECT. An Identifier itself has no location implications. (Identifier

specify a networkn opaque vale specified a, Superior o

ended to use truly unambigu e

5 The “appli tion specification” or “application pro n” may be very informal or may be a sta reement.

ca tocol specificationdardised ag


3.6.2 Addresses 1804

In most case d to communica rmed of each others addresses 1805 from receive s T message which 1806 ontains the address of the Superior will have been received or otherwise passed to the Enroller 1807

and the Inferior. The ENROL message received by the Superior contains the address of the 1808 returned from a Factory to the Initiator contains the address of the Decider, 1809 ed to the Terminator or any Status Requestor. 1810

1811 1812 1813

• a “binding rmat specific to the information necessary to 1814 connect u1815

• an option al information field. 1816 he optional additional information is opaque to all but the future destination (which also created 1817

1818 1819 1820 1821 1822

bindings that it supports obviously, but not 1823 otherwise constrained by the specification. The binding address will be used by the sender’s 1824

epending on the protocol, the address may or may not be transmitted – 1825 1826 1827 1828

he 1829 1830

1831 1832 1833

ing a single “reply-address”. Depending on the binding, and the particular use 1834 1835 1836

other 1837 side, ed and must be responded to, but the Peer is 1838 unkno messages contain (in abstract) a single “senders-1839 address n1840 may be imp1841 The CONTE s not contain a “target-address”, even as an abstract message, as it 1842 is never tran1843 or BEGU m1844 association 1845

3.6.3 Qu1846

Qualifiers a1847 the Actors. Qualifiers ca1848 groups, B1849 qualifier1850 time limits, a1851 interchange rotocol or carry application-specific 1852

1853

s, BTP Actors that nee te are infod BTP messages. When an Inferior i to be enrolled, a CONTEX

c

Inferior. The BEGUNand this can be passThe addresses carried in these messages (which are effectively “call-back” addresses, to be usedas the destination of future messages) are sets of tripartite addresses. Each contains: • an identifier (binding name) for the binding to an underlying transport, or Carrier Protocol;

address”, in a fosing that carrier;

carrier which is the

al additionTthis address for itself) and is used however the implementation there wishes (e.g. it can be usedto distinguish a particular program object, or to relay on, perhaps over a different protocol). The multiple members of the set allow support of multiple carrier bindings (including both different versions of standard bindings and proprietary bindings) and for relocation of the BTP Actor. When a message is actually to be sent, the sender, possessing the set of addresses for the destination, chooses one - restricting its choice to

carrier implementation (dwith http, for example, it is), The additional information, if present, will be included in the BTP message. The chosen address is considered the “target-address” when considering the abstract message, but only the additional information will normally appear within the encoded BTP-message (the encoding used is part of the binding specification, which could require that all of taddress is (redundantly) transmitted, if the specifier so chose). Where a BTP message invokes a reply – as with the Initiator:Factory, Terminator:Decider andStatus Requestor:various roles – the receiver (Factory, Decider, etc) of the message will not know a priori the address of the sender. Accordingly, in these cases the abstract messages are specified as containof the binding, the “reply-address” may be directly represented in the encoding of the BTP message, or may be implicit in the Carrier Protocol. Similar considerations apply in the Superior:Inferior relationship where, although the addresses are normally known by the

there are cases when a message is receivwn. Accordingly, the Superior:Inferior

” a d the identifier of the sender. As with the “reply-address”es, the “senders-address” licit in the Carrier Protocol. XT message doesmitted between BTP Actors on its own – it is always either related to a BTP BEGIN

N essage, or is passed between Application Elements with some (application-detailed) with Application Messages.

alifiers re elements of the BTP messages used to exchange additional information between

n be specified in the BTP specification (“standard qualifiers”), by industry by TP implementors or for the purposes of particular applications. Of the standard s in this version of the specification some are constraints on the BTP Contract, such as

nd some are further identifiers used to distinguish specific parties in the BTP . Non-standard qualifiers could extend the p

information.


3.6.4 Lists 1854

a list of inferiors (e.g. the inferiors-list and targetted-1855 e. 1856

1857 1858 1859

Where a parameter of a message represents qualifiers-list parameters of several messages), each inferior SHOULD only be represented oncThere is no specified behaviour for an implementation that receives such a parameter with one or more inferiors represented more than once (implementations are free to ignore the duplicate or to return a FAULT).


Part 2. Normative Specification of BTP 1860

ationships 4 Actors, Roles and Rel1861

utations. BTP Actors are addressable for the 1862 ol messages transmitted over some underlying 1863

m 5.1 “Addresses” for more detail.) 1864 and processing of messages. These roles are 1865

by 1866 cation. (These contracts are stated formally in sections 5 “Abstract Messages and 1867

Associated Contracts” and 6 “State Tables”.) A BTP Actor’s computations put the contracts into 1868 1869 1870 1871 1872

ow 1873 nt choices. 1874

ole may be assigned to a 1875 ementer. An Actor playing a Role is termed an 1876

1877 t oles played by Actors may be implemented using 1878

ctor-in-role. The section 10 “Conformance”, gives 1879 erable 1880

1881 ss Transaction, 1882 ception cases – 1883

ation. 1884

is approximately equivalent to an interface in some distributed 1885 comput ort-type in W of a Role includes 1886 behavio1887

4.1 Relationships 1888

lationships in BTP. 1889 be 1890

e BTP Actor at the top of the Transaction Tree (the 1891 1892

(the Superior) will inform the other (the 1893 1894 1895

at is 1896 1897

can; or (for 1898 1899

it can 1900 1901 1902 1903

Actors are software agents which process comppurposes of receiving application and BTP protocco munications or carrier protocol. (See sectionBTP Actors play roles in the sending, receiving associated with responsibilities or obligations under the terms of software contracts defined this specifi

effect. A Role is defined and described in terms of a single Business Transaction. An implementation supporting a Role may, as an addressable entity, play the same Role in multiple Business Transactions, simultaneously or consecutively, or a separate addressable entity may be created for each transaction. This is a choice for the implementer, and the addressing mechanisms allinteroperation between implementations that make differeWithin a single transaction, one Actor may play several roles, or each Rdistinct Actor. This is again a choice for the impl“actor-in-role”. Ac ors may interoperate, in the sense that the rsoftware created by different vendors for each aguidelines on the groups of roles that may be implemented in a partial, interopimplementation of BTP. The descriptions of the roles concentrate on the normal progression of a Busineand some of the more important divergences from this. They do not cover all exthe message set definition and the state tables provide a more comprehensive specific

Note – A BTP Roleing mechanisms, or a p SDL. The definition ur.

There are two primary re• Between an Application Element that determines that a Business Transaction should

completed (the Role of Terminator) and thRole of Decider);

• Between BTP Actors within the tree, where one Inferior) what the outcome decision is.

These primary relationships are involved in arriving at a decision on the outcome of a Business Transaction, and propagating that decision to all parties to the transaction. Taking the path thfollowed when a Business Transaction is confirmed:

a) The Terminator determines that the Business Transaction should Confirm, if ita Cohesion), which parts should Confirm

b) The Terminator asks the Decider to apply the desired outcome to the tree, ifguarantee the consistency of the Confirm decision

c) The Decider, which is Superior to one or more Inferiors, asks its Inferiors if they can agree to a Confirm decision (for a Cohesion, this may not be all the Inferiors)


d) If any of those Inferiors are also Superiors, they ask their Inferiors and so on down thetree

1904 1905

their Superior 1906 1907

agre riors, and can agr1908 g) Eve ported t the Decider 1909

make cision (h des, 1910 everything else just asked); if any have dis cannot be 1911 pers ade 1912

h) The Decider, as Superior tells its Inferiors o1913 i) Infe s tell their In he tree 1914 j) The q the outcome 1915

deci1916 tionships that are secondary to Terminator:Decider, Superior:Inferior, mostly 1917 blishment of the primary relationships. The various particular relationships can 1918

y; 1919 1920

onships are linked in that a Decider is a Superior to one or more Inferiors. 1921 There are als e semantics of som (messages) within the 1922 relationships.1923 All exchanges between Terminator and Decider are initiated by the Terminator (it is 1924

essentially a request/response relationship); either of Superior or Inferior may initiate 1925 1926

ferior relationship is recoverable – depending on the progress of the 1927 two sides will re-establish their shared state after failure; the 1928

1929 1930

not need to know the address of the Terminator 1931 y of returning the response to a received message). 1932

4.21933

9 -- show the BTP roles that are specialisations of the central Superior and 1934 1935

e) Inferiors that are not Superiors report if they can agree to a Confirm tof) Inferiors that are also Superiors report their agreement only if they received such

ement from their Infe ee themselves ntually agreement (or not) is re

s and persists the Confirm deo the Decider. If all have agreed, ence the term “Decider” – it deci

agreed, or if the Confirm decision isted, a Cancel decision is m

f the outcome riors that are also Superior feriors, recursively down t Decider replies to the Terminator’s resion

uest to Confirm, reporting

There are other relainvolved in the estabe grouped as the “control” relationships – primarily Terminator:Decider, but also Initiator:Factorand the “outcome” relationships – primarily Superior:Inferior, but also Enroller:Superior. The two groups of relati

o similarities in th e of the exchanges However they differ in that

•

messages to the other • The Superior:In

relationship, theTerminator:Decider relationship is not recoverable. The nature of the Superior:Inferior relationship requires that the two parties know of each other’s addresses from when the

d; the Decider does relationship is establishe(provided it has some wa

Roles Figure 18 and Figure 1Inferior roles.


Superior

Sub-composerDecider Sub-coordinator

ComposerCoordinator

1936 1937

Figure 18 -- Superior and derived roles

Inferior

Participant Sub-coordinator Sub-composer

1938 Figure 19 -- Inf1939

In the followin h messages that are 1940 ent or received by that Role are listed. Note that some roles exist only to have a name for an 1941 ctor that issues a message and receives a reply to that message. Some of these roles may be 1942

1943 ages 1944

s are 1945 sometimes sent first, received second, sometimes vice versa.) 1946

4.3 Roles involved in the Outcome Relationships 1947

4.3.1 Superior 1948

Accepts enrolments of Inferiors from Enrollers, establishing a Superior:Inferior relationship with 1949 each. In cooperation with other Actors and constrained by the messages exchanged with the 1950 Inferior, the Superior determines the Outcome applicable to the Inferior and informs the Inferior 1951 by sending CONFIRM or CANCEL. This outcome can be Confirm only if a PREPARED message 1952 is received from the Inferior, and if a record, identifying the Inferior can be persisted. (Whether 1953 this record is also a record of a Confirm decision depends on the Superior’s position in the 1954 Business Transaction as a whole.). The Superior must retain this persistent record until it 1955 receives a CONFIRMED (or, in exceptional cases, CANCELLED or HAZARD) from the Inferior. 1956 A Superior may delegate the taking of the Confirm or Cancel decision to an Inferior, if there is 1957 only one Inferior, by sending CONFIRM_ONE_PHASE. 1958

erior and derived roles

g sections, the responsibility of eac Role is defined, and the sAplayed by several Actors in the course of a single Business Transaction. For each Role, a table shows which messages are received and sent. Where the messappear on the same line, the second is a reply to the first. (Consequently the column


A Superior may be Atomic or Cohesive; an Atomic Superior will apply its Inferiors; a Cohesive Superior may apply C

the same decision to all of 1959 onfirm to some Inferiors and Cancel to others, or 1960

1961 1962

nship is ended; the Inferior has 1963 no further effect on the behaviour of the Superior as a whole. 1964

Superior receives Superior sends

may Confirm some after others have reported cancellation. The set of Inferiors that the Superior confirms (or attempts to Confirm) is called the “Confirm-set”. If RESIGN is received from an Inferior, the Superior:Inferior relatio

ENROL ENROLLED PREPARE CONFIRM CANCEL RESIGNED CONFIRM_ONE_PHASE CONTRADICTION SUPERIOR_STATE PREPARED CONFIRMED CANCELLED HAZARD RESIGN INFERIOR_STATE REQUEST_STATUS STATUS REQUEST_INFERIORS_STATUS INFERIOR_STATUSES

1965 Receipt of ENROL establishes a new Superior:Inferior relationship (unless the ENROL is a 1966 duplicate). ENROLLED is sent only if a reply is asked for on the ENROL. 1967

4.3.2 Inferior 1968

Responsible for applying the Outcome to some set of associated operations – the application 1969 determines which operations are the responsibility of a particular Inferior. 1970 An Inferior is Enrolled with a single Superior (hereafter referred to as “its Superior”), establishing 1971 a Superior:Inferior relationship. If the Inferior is able to ensure that either a Confirm or Cancel 1972 decision can be applied to the associated operations, and can persist information to retain that 1973 condition, it sends a PREPARED message to the Superior. When the Outcome is received from 1974 the Superior, the Inferior applies it, deletes the persistent information, and replies with 1975 CANCELLED or CONFIRMED as appropriate. 1976 If an Inferior is unable to come to a prepared state, it cancels the associated operations and 1977 informs the Superior with a CANCELLED message. If it is unable to either come to a prepared 1978 state, or to Cancel the associated operations, it informs the Superior with a HAZARD message. 1979 An Inferior that has Become Prepared may, exceptionally, make an autonomous decision to be 1980 applied to the associated operations, without waiting for the Outcome from the Superior. It is 1981 required to persist this autonomous decision and report it to the Superior with CONFIRMED or 1982

M or CANCEL is received, the autonomous 1983 perior are contradictory, the Inferior must retain 1984

the record of the autonomous decision until receiving a CONTRADICTION message. 1985

Inferior receives Inferior sends

CANCELLED as appropriate. If, when CONFIRdecision and the decision received from the Su

PREPARE CONFIRM CANCEL RESIGNED


Inferior receives Inferior sends CONFIRM_ONE_PHASE CONTRADICTION SUPERIOR_STATE PREPARED CONFIRMED CANCELLED HAZARD RESIGN INFERIOR_STATE REQUEST_STATUS STATUS REQUEST_INFERIORS_STATUS INFERIOR_STATUSES

1986

1987

Caus in some 1988 imple ill be performed by the application, in some the 1989

1990 1991

4.3.3 Enroller es the enrolment of an Inferior with a Superior. This Role is distinguished becausementations the enrolment request w

application will ask the Actor that will play the Role of Inferior to enrol itself, and a Factory may enrol a new Inferior (which will also be Superior) as a result of receiving BEGIN&CONTEXT.

Enroller sends Enroller receives ENROL ENROLLER

ENROLLED is received only if the Enroller asked for a response when the ENROL was sent. An ENROL message sent from an Enroller that did not require an ENROLLED response may be modified en route to the Superior by an intermediate Actor to ask for an ENROLLED response to be sent to the intermediate. (This may occur in the “one-shot” scenario, where an ENROL/no-rsp-req is received in relation to a CONTEXT_REPLY/related; the receiver of the CONTEXT_REPLYwill need to ensure the enrolment is successful).

4.3.4 Participant

1992 1993 1994 1995 1996

1997 1998

1999

alized for the purposes of an application. Some Application Operations 2000 2001 2002 2003 2004

r 2005 2006 2007 2008

2009 2010

2011

2012 2013 2014 2015 2016

An Inferior which is speciare associated directly with the Participant, which is responsible for determining whether a prepared condition is possible for them, and for applying the outcome (“associated directly” as opposed to involving another BTP Superior:Inferior relationship, in which this Actor is the Superior). The associated operations may be performed by the Actor that has the Role of Participant, othey may be performed by another Actor, and only the Confirm/Cancel application is performed by the Participant. In either case, the Participant, as part of becoming prepared (i.e. before it can send PREPARED to the Superior), will persist information allowing it apply a Confirm decision to the operations andto apply a Cancel decision. The nature of this information depends on the operations.

Note – Possible approaches include:

• The operations may be performed completely and the Participant persists information to perform Counter-effect operations (compensating operations) to apply cancellation;

• The operations may be just checked and not performed at all; the Participant persists information to perform them to apply confirmation;


• The Participant persists the prior state of data affected by the operations and the operations are performed; the Participant restores the prior state to apply cancellation;

• As the previous, but other access to the affected data is forbidden until the decis

2017 2018 2019

ion is 2020 2021 2022

lled, 2023 rked as cancelled. 2024

Sin2025

4.32026

An Inferior whic2027 2028 2029 2030 2031 2032 2033 2034 2035 2036

Since a Sub-coordinator is both an Inferior and a Superior, it sends and receives the messages 2037 2038

2039

2040 2041 2042 2043 2044 2045 2046 2047 2048 2049

2050

2051

Superior:Inferior relationship. It is the top BTP node in 2052 the Tr for the 2053 Busin ction, it 2054 is the cision 2055 is syn d. 2056 An Inferior s PREPARED has been received from it. 2057

g CANCEL_TRANSACTION. 2058 2059 2060

known • The operations are performed completely, with the changes made accessible but

marked as provisional; if confirmed, the provisional marking is removed; if cancethey are deleted or ma

ce a Participant is an Inferior, it sends and receives the messages for an Inferior.

.5 Sub-coordinator h is also an Atomic Superior.

A sub-coordinator is the Inferior in one Superior:Inferior relationship and the Superior in one or more Superior:Inferior relationships. From the perspective of its Superior (the one the sub-coordinator is Inferior to), there is no difference between a sub-coordinator and any other Inferior. From this perspective, the “associated operations” of the sub-coordinator as an Inferior include the relationships with its Inferiors. A sub-coordinator does not Become Prepared (and send PREPARED to its Superior) until and unless it has received PREPARED (or RESIGN) from all its Inferiors. The outcome is propagated to all Inferiors.

for both.

4.3.6 Sub-composer An Inferior which is also a Cohesive Superior. Like a sub-coordinator, a sub-composer cannot be distinguished from any other Inferior from the perspective of its Superior. A sub-composer is similar to a sub-coordinator, except that the constraints linking the different Inferiors concern only those Inferiors in the Confirm-set. How the Confirm-set is controlled, and when, is not defined in this specification. If the sub-composer is instructed to Cancel, by receiving a CANCEL message from its Superior, the cancellation is propagated to all its Inferiors. Since a Sub-composer is both an Inferior and a Superior, it sends and receives the messages for both.

4.4 Roles involved in the Control Relationships

4.4.1 Decider A Superior that is not also the Inferior on a

ansaction Tree and receives requests from a Terminator as to the desired outcomeess Transaction. If the Terminator asks the Decider to Confirm the Business Transa responsibility of the Decider to finally take the Confirm decision. The taking of the deonymous with the persisting of information identifying the Inferiors that are to be confirme

cannot be confirmed unlesA Decider is instructed to Cancel by receivinA Decider that is an Atomic Superior (all Inferiors will have the same outcome) is a Coordinator. A Decider that is a Cohesive Superior (some Inferiors may Cancel, some Confirm) is a Composer.


Decider receives Decider sends CONFIRM_TRANSACTION TRANSACTION_CONFIRMED

TRANSACTION_CANCELLED INFERIOR_STATUSES

CANCEL_TRANSACTION TRANSACTION_CANCELLED INFERIOR_STATUSES

REQUEST_INFERIOR_STATUSES INFERIOR_STATUSES 2061

2062

2063

cision will be applied to all Inferiors 2064 2065 2066 2067 2068 2069 2070 2071 2072

2073

2074 -set of the Cohesion. 2075

2076 2077 2078 2079 2080 2081 2082 2083 2084 2085 2086 2087

A Decider is also a Superior and thus sends and receives the messages for a Superior.

4.4.2 Coordinator A Decider that is an Atomic Superior. The same outcome de(excluding any from which RESIGN is received). PREPARED must be received from all remaining Inferiors for a Confirm decision to be taken. A Coordinator must make a Cancel decision if • it is instructed to Cancel by the Terminator • if CANCELLED is received from any Inferior • if it is unable to persist a Confirm decision Since a Coordinator is a Decider, it receives the messages appropriate for a Decider and a Superior.

4.4.3 Composer A Decider that is a Cohesive Superior. If the Terminator requests confirmation of the Cohesion, that request will determine the ConfirmPREPARED must be received from all Inferiors in the Confirm-set (excluding any from which RESIGN is received) for a Confirm decision to be taken. A Composer must make a Cancel decision (applying to all Inferiors) if: • it is instructed to Cancel by the Terminator • if CANCELLED is received from any Inferior in the Confirm-set • if it is unable to persist a Confirm decision A Composer may be asked to prepare some or all of its Inferiors by receiving PREPARE_INFERIORS. It issues PREPARE to any of those Inferiors from which none of PREPARED, CANCELLED or RESIGN have been received, and replies to the PREPARE_INFERIORS with INFERIOR_STATUSES. A Composer may be asked to Cancel some of its Inferiors, but not itself, by receiving CANCEL_INFERIORS.

Composer receives Composer sends PREPARE_INFERIORS INFERIOR_STATUSES CANCEL_INFERIORS INFERIOR_STATUSES

4.4.4 Terminator Asks a Decider to Confirm the Business Transaction, or instructs it to Cancel all or (for a Cohesion) part of the Business Transaction. All communications between Terminator and Decider are initiated by the Terminator. A Terminator is usually an Application Element.

2088

2089 2090 2091 2092


A request to Confirm is made by sending CONFIRM_TRANSACTION to the target Decider. If the Decider is a Cohesion Composer, the Terminator may sele

2093 ct which of the Composer’s Inferiors 2094

2095 2096 2097 2098 2099

le 2100 if all Inferiors Cancel 2101

2102 FERIORS to Cancel some of the 2103

2104 2105

Decider replies with INFERIOR_STATUSES. 2106

ends Terminator receives

are to be included in the Confirm-set. If the Decider is an Atom Coordinator, all Inferiors are included. After applying the decision, the Decider replies with TRANSACTION_CONFIRMED, TRANSACTION_CANCELLED or (in the case of problems) INFERIOR_STATUSES. A Terminator may ask a Composer (but not a Coordinator) to prepare some or all of its Inferiors with PREPARE_INFERIORS. The Composer replies with INFERIOR_STATUSES. A Terminator may send CANCEL_TRANSACTION to instruct the Decider to Cancel the whoBusiness Transaction. The Decider replies with CANCEL_COMPLETEsuccessfully, and with INFERIOR_STATUSES in the case of problems. If the Decider is a Cohesion Composer, the Terminator may send CANCEL_INInferiors; the Decider always replies with INFERIOR_STATUSES. A Terminator may check the status of the Inferiors of the Decider by sending REQUEST_INFERIOR_STATUSES. The

Terminator sCONFIRM_TRANSACTION TRANSACTION_CONFIRMED

TRANSACTION_CANCELLED INFERIOR_STATUSES

CANCEL_TRANSACTION TRANSACTION_CANCELLED INFERIOR_STATUSES

PREPARE_INFERIORS INFERIOR_STATUSES CANCEL_INFERIORS INFERIOR_STATUSES REQUEST_INFERIOR_STATUSES INFERIOR_STATUSES

4.4.5 Initiator 2107

p-2108 2109 2110

sends Initiator receives

Requests a Factory to create a Superior – this will either be a Decider (representing a new tolevel Business Transaction) or a sub-coordinator or sub-composer to be the Inferior of an existing Business Transaction.

InitiatorBEGIN BEGUN

2111 2112

4.4.6 Factory2113

Creates Su rns the CONTEXT for the new Superior as a parameter of BEGUN. 2114 The followi erior are created : 2115 • Decide 2116

– Co2117 – Co2118

• Sub-co2119 Sub-coordinator 2120

2121

The CONTEXT in the BEGUN is that for the new Superior.

periors and retung types of Supr, which is eithermposer or ordinator mposer

•

Factory receives Factory sends BEGIN BEGUN

2122


If the BEGIN has no contained CONTEXT, the Factory creates a Decider, either a Cohesion 2123 Compo2124 BEGIN. 2125

tained CONTEXT, the new Superior is also enrolled as an Inferior of the 2126 e CONTEXT. The new Superior is thus a sub-composer or sub-2127

coordin2128

4.5 O2129

4.5.1 2130

Sends a pplied 2131 for the P2132 new ad2133 A Redir the old 2134 address2135

ior moves from the superior-address in its CONTEXT, or an Inferior moves from the 2136 2137

catches sage 2138 giving th inbound message may itself be a REDIRECT message, in 2139

s the target for 2140 2141

After r essage, the BTP Actor must use the new address not the old one, 2142 2143

ser or an Atom Coordinator, as determined by the “superior type” parameter on the

If the BEGIN has a conSuperior identified by th

ator, as determined by the “superior type” parameter on the BEGIN.

ther roles

Redirector REDIRECT message to inform a Superior or Inferior that an address previously sueer (i.e. an Inferior or Superior, respectively) is no longer appropriate, and to supply a

dress or set of addresses to replace the old one. ector may send a REDIRECT message in response to receiving a message using, or may send REDIRECT at its own initiative.

If a Superinferior-address in the ENROL message, the implementation must ensure that a Redirector

any inbound messages using the old address and replies with a REDIRECT mese new address. (Note that the

which case the Redirector shall use the new address in the received message athe REDIRECT that it sends.)

eceiving a REDIRECT munless failure prevents it updating its information.

Redirector receives Redirector sends Any message for Superior or Inferior

REDIRECT

4.5.2 Status Requestor 2144

the current status of a Transaction Tree Node – any of an Inferior, 2145 2146 2147 2148 2149

Requests and receivesSuperior or Decider, or the current status of the nodes relationships with its Inferiors, if any. The Role of Status Requestor has no responsibilities – it is just a name for where REQUEST_STATUS and REQUEST_INFERIOR_STATUSES come from (REQUEST_INFERIOR_STATUSES is also issued by a Terminator to a Decider).

Status Requestor sends Status Requestor receives REQUEST_STATUS STATUS REQUEST_INFERIOR_STATUS INFERIOR_STATUSES

2150 The receiver efuse to prov tus information by replying with 2151 FAULT(Statu rmation retur TUS will always relate to the 2152 Transaction T whole (e.g. as an it is also a Superior). 2153

of the request can rsRefused). The info

ide the staned in STA

ree Node as a Inferior, even if


4.6 Summary of relationships 2154

Figure 2 ing 2155 2156

0 summarises the relationships between the BTP roles. BTP can be implemented uss of the Terminator and Decider roles. proprietary equivalent

Terminator Initiator

Composer(Decider)

1..n

1

1..n

1

Termi nator:Decider

1..n

1

1..n

1

Service

Coordinato r(De cider)

1..n

11

1..n

Terminator:Decider

1..n

11

11

1..n1..nOn ly o ne Deci der in a tre e a t a ti me 1..n

Sub-coordinator

Participant

1..n

1

1..n

1

111

0..n0..n

1

Superior:Inferior

Su b-composer+Superior/Infe

+Inferior/Superior

rior

0..n0..n

Superior:Inferior

11

1..n1..nSuperior:Inferior

1..n

11

1..n

Superior:Inferior

2157 Figure 22158 0 Summary of relationships between roles


5 Abst essages a acts ract M nd Associated Contr2159

BT Protocol Messages are defined in this sectio bstract information that has to 2160 be communicated. These abstract messages s 2161 communicated by a particular Carrier Protoco ings defined). 2162 The abstract message set and the associated ol will 2163 • deliver messages completely and correct ted messages will not be 2164

delivered2165 • report som cation failures, but i.e. not all message 2166

deliveries are positively acknowledged wi2167 es deliver successive messages in a different order than they were sent; and 2168

• doe link a request and a response 2169

se assumptions would be met by a mapping to SMTP and more than 2170 2171

Howeve essage set is mapped to a Carrier Protocol that provides a richer 2172 st/response 2173

2174 lues 2175

s. 2176 n 2177

2178 2179

lar implementation configurations, parts or all of the Delivery Parameters may be implicit in 2180 s 2181

ly those parameters that are concerned 2182 with the transmission of this message, or of an immediate reply (thus address parameters to be 2183

the identifiers of both sender and receiver are Payload 2184 tion, Delivery Parameters are shown in shaded cells. 2185

2186

All of the mes t CONTEXT have a t address” parameter and many also have 2187 other address se latter identify the desired target of other messages in the set. In 2188 all cases, the exact value will have been origin ntation that is the 2189 target or intended target. 2190 The detailed format of the address will depen lar Carrier Protocol, but at this 2191 abstract level have three par g name”, identifies the 2192 binding to a particul r Protocol – some bi specified in this document, others can 2193

ere. The second part of the address, the “binding address”, is meaningful to 2194 the Car2195 be deliv2196 the Car2197 When a2198 which C o 2199 the Car tire binding address is considered to be “consumed” by the Carrier 2200

plementation. All of it may be used by the sending implementation, or some of it may 2201 the Carrier Protocol, but then used or consumed 2202

by the r rrier Protocol to direct the BTP message to a BTP-2203 -aware in that it is capable of interpreting the BTP messages). The “additional 2204

n in terms of the a will be mapped to concrete messagel (there can be several such mapp state table assume the Carrier Protocly, or not at all (corrup

); e communi will not necessarily report all (

thin the carrier); • sometim

s not have built-in mechanisms to

Note -- themet by mappings to SOAP/HTTP.

r, when the abstract mservice (e.g. reports all delivery failures, guarantees ordered delivery or offers a requemechanism), the mapping can take advantage of these features. Typically in such cases, some of the parameters of an abstract message will be implicit in the carrier mechanisms, while the vaof other parameters will be directly represented in transmitted elementThe abstract messages include Delivery Parameters that are concerned with the transmissioand delivery of the messages as well as Payload Parameters directly concerned with the progression of the BTP relationships. When bound to a particular Carrier Protocol and for particuthe Carrier Protocol and will not appear in the "on-the-wire" representation of the BTP messageas such. Delivery Parameters are defined as being on

used in repeated later messages andParameters). In the tables in this sec

5.1 Addresses sages excep “targe parameters. The

ally determined by the impleme

d on the particu is considered to

ar Carriets. The first part, the “bindin

ndings are be specified elsewh

rier Protocol itself, which will use it for the communication (i.e. it will permit a message to ered to a receiver). The third part, “additional information”, is not used or understood by rier Protocol. The “additional information” may be a structured value. message is actually transmitted, the “binding name” of the target address will identify arrier Protocol is in use and the “binding address” will identify the destination, as known trier Protocol. The en

Protocol imbe transmitted in headers, or as part of a URL in

eceiving implementation of the Caaware entity (BTP


informa y by 2205 the rece e on to some other BTP 2206

the target address, only the “additional information” field is transmitted in the 2207 nd the “additional information” is opaque to parties other than the recipient. 2208

For othe within the message. 2209 rior relationship have an identifier parameter 2210

get side as well as the target address. This allows full flexibility for implementation 2211 an implementation can: 2212

a) mation for multiple Business 2213 he relevant state information; 2214

ame binding address for multiple Business Transactions and use the additional 2215 2216

nt binding address for each Business Transaction. 2217 s is used is opaque to the entity sending the message – both parts of the 2218

2219 2220

BTP recovery the state informat a Superior or Inferior is accessible after 2221 failure and that the Peer can distinguish betw porary inaccessibility and the permanent 2222 non-existence of the state information. As is e n “3.4.4 Redirection” in the conceptual 2223 model, BTP p mechanisms – having a Addresses for some parameters, and 2224 the REDIREC age – that make this po if the recovered state information is on a 2225 different address to the original one, as may b c) above is used. 2226

e pairs 2227

Many o2228 the resp2229

type of request. To allow for this, the abstract message set treats each message as 2230 standal 2231 For any2232 messag2233 Betwee2234 address” on a r CONTEXT or the “inferio ress” on a recei However, in 2235 some cas ssage w rior or – the state 2236 informatio nger exists. This is not an exceptional condition but occurs when one side has 2237 either not r has stent state in a res, but a 2238 message has got lost in a failure s st e to a 2239 message for an unknown (and logically non-existent) Sup known, 2240 for an unkno r it is INFERIO TATE/unknown. Howeve is 2241 unknown, o info e the Peer, which sage. To 2242 enable the receiver to reply with the appropriate *_STATE ges between 2243 Superior rior hav te to be sent in 2244 response to e wh s a “sen r, the 2245 FAULT message is sent to ss. 2246

Note – Both reply-ad ers-address ma rrier 2247 Protocol itself has a request/response pattern. In these der 2248 add licitl der of the reques a 2249 response) 2250

5.3 Compounding messages 2251

BTP messages may be sent in combination with each other, or with pplication) messages. 2252 There are two cases: 2253

tion” of the target address will be part of the BTP message itself and used in some waiving BTP-aware entity (it could be used to route the messag

entity). Thus, forBTP message a

r addresses in BTP messages, all three components will beAll messages that concern a particular Superior:Infefor the tarchoices –

Use the same binding address and additional inforTransactions, using the identifier parameter to locate t

b) Use the sinformation to locate the information; or

c) Use a differeWhich of these choiceaddress and the identifier originated at the recipient of this message (and were transmitted as parameters of earlier messages in the opposite direction).

requires that ion for een temxplained i

rovidesT mess

set of BTP ssible, even e the case if case

5.2 Request/responsf the messages combine in pairs as a request and its response. However, in some cases onse message is sent without a triggering request, or as a possible response to more

than oneone; but where a request does expect a reply, a “reply-address” parameter will be present. message with a reply address parameter, in the case of certain errors, a FAULT e will be sent to the reply address instead of the expected reply. n Superior and Inferior the address of the Peer is normally known (from the “superior-

n earliees a men no lo

r-addill be received for a Supe

ved ENROL).Inferior that is not known

created o removed its persi, and the Peer still ha

ccordance with the proceduate information. The responserior is SUPERIOR_STATE/un

wn Inferio there is n

R_Srmation to locat

r, since the intended target sent the undeliverable mes/unknown, all the messa

and Infemessag

e a “senders-address” parameich (as an abstract message) ha

that addre

r. If a FAULT message isders-address” paramete

dress and send y be absent when the Ca cases, the reply or sen

ress is imp y that of the sen t (and thus the destination of

other (a


a) Sending the messages together where the combination has semantic significance. One 2254 message is said to be “related to” the other – the combination is termed a “group”. 2255

b) Sending of the m the combination2256 merely a conven ation. This is term ion is 2257 termed a “bundle”. 2258

The form A&B is used to refer to a combination (group) w is sent in relation to A 2259 (“relation” is a c). T r to A and B bundle2260 transmiss nd l d by the 2261 transmission of B. 2262 Only certain combination a relation is 2263 specifically defined for ea ext ated as 2264 a unit for transmission – it has a e target address. Th ges 2265 in the group – the specification for the group defines which. 2266 A “bundle es ess essages. 2267 The only constraint on w n b that all have the same 2268 binding address, but eac e different “additional information” values. (Messages within a 2269 related gr ve d he ru this). 2270 Unless constrained by th grou e same 2271 binding address may be the bindin es are the same is a 2272 necessar ent determ bundled. 2273 A particular and importan is where a BTP CONTEXT message is sent 2274 related to an n M se, the target of the Applicatio s the 2275 destinatio E he receiving imp the 2276 CONTEX ring the Application Message to t r, but from 2277 the perspective of the sender, the two are sent to the sam2278 The compounding mechanisms, and the multi-part address “one-wire” and 2279 “one-shot icatio2280 In “one-wi e exchanges between two sides ip, 2281 including the associated Application Messages, pass via t ndpoints” 2282 may in fact be relays, routing messages on to particular A2283 routing w some s t ender. This can be 2284 achieved if the relaying e dress in its domain have the 2285 relay’s address as their binding address, and any routing wn 2286 domain is placed in the additional information. (This may involve the relay changing addresses in 2287 message t way out). On rec s the 2288 within-dom n ed additional info n) and 2289 forwards the message appropriately. The sender is unawa rely sees addresses 2290 with the s g ad bu itional 2291 information” is a matter o ld put an er 2292 implemen i a quite diffe entation can be 2293 construct iving e ll roles, using 2294 the received identifiers to e. 2295 “One-shot” communicatio A e 2296 application reply, enrol a e responsible for th ncel of the operations of 2297 those message and inform r that the Inferior is p ange 2298

etwork (e.g. one request/reply of a Carrier Protocol).. The application request is sent 2299 with a r pplication response is sent with a relation group of 2300

message and a PREPARED message. This is 2301 he Superior address is different from the address of the Application Element that 2302

sends t en be 2303 an iden n Element). The target addresses of the ENROL and 2304 PREPARED (the Superior address) are not transmitted; the Actor that was originally responsible 2305

essages where ience or optimis

has no semantic significance, but is ed “bundling” – the combinat

here message Bsymmetri

ion of the buhe form A+B is used to refe

le "A+B" is semantically identica

s of messages are possible inch such combination in the n

singl

d together- the to the transmission of A followe

group, and the meaning of the section. A particular group is treis is usually that of one of the messa

” of messag may contain both unrelated mhich messages and groups cah may hav

ages and groups of related me bundled is

oup may ha ifferent addresses, where te binding, any messages orbundled – the fact that

les of their relatedness permit ps that are to be sent to thg address

y and suffici condition for the sender tot case of related messages

ine that the messages can be

Application of the CONTT before delive

essage. In this caXT message. T

n Message definelementation may in fact removehe application (Service) propee place.

structures, support the” communre”, all messag

n patterns. of a Superior:Inferior relationshhe same “endpoints”. These “ectors within their domain. The onward

ill require further addressing, but this handpoint ensures that all ad

o be opaque to the ses for Actors information it will need in its o

s as they passain destinatio

hrough it on the from the receiv

eiving a message, it determinermation (which is thus rewrittere of this, and me

ame bindin dress, which it is permitted tonly for the relay – it cou

ndle. The content of the “add entire BTP Address in there, or oth

tation-defineded where there i

nformation. Note thats no relaying, but the rece locate the appropriate statn makes it possible to send an

n Inferior to b the Superio

rent one-wire implemntity effectively performs a

pplication Message, receive the Confirm/Ca

repared, all in one two-way exchacross the n

elated CONTEXT message. The aCONTEXT_REPLY/related, ENROL/no-rsp-req possible even if t

he original message (if the application exchange is request/reply, there may not evtifiable address for the Applicatio


for adding the CONand forwards the E

TEXT to the outbound Application Message remembers the Superior address 2306 NROL and PREPARED appropriately. 2307

, 2308 ated to the CONTEXT_REPLY. If 2309

an operation f ELLED message i nstead of a PREPARED. 2310 If the CONTE pe” of “atom”, then subsequent messages to the same Service, 2311 with the same can have the ciated operations put under the 2312 control of the only a CONT LY/completed is sent back with the 2313 response (if th rations fail, it will be send back 2314 CONTEXT_R ated, or send CANCELLE rior type” on the CONTEXT is 2315 “cohesive”, ea n will require separa t. 2316 Whether the “ mechanism is used is by the implementation on the 2317 responding (I . This may be subjec and may also be constrained by 2318 the applicatio se. 2319

ty 2320

To simp ns of 2321 future e r Qualifiers may be 2322

any parameter added to an existing message in a future revision of this 2323 efault for “must-be-understood” shall be “true”, so an implementation receiving 2324

an unre2325 (the FAULT value “UnrecognisedParameter” is available, but other errors, including lower-layer 2326

rshalling errors may be reported instead). If “must-be-understood” with the value 2327 ntation 2328

should2329 b-parameter is associated with the new parameter is determined by the particular 2330

binding2331 No spec m is provided to allow for the introduction of completely new messages. 2332

5.5 Messages 2333

5.5.1 Qualifiers 2334

All messages have a Qualifiers parameter which contains zero or more Qualifier values. A 2335 Qualifier has sub-parameters: 2336

Sub-parameter Type

qualifier name string

qualifier group URI

must-be-understood Boolean

to-be-propagated Boolean

content Arbitrary – depends on type

2337 qualifier group 2338

ensures the Qualifier name is unambiguous. Qualifiers in the same group need not have 2339 any functional relationship. The qualifier group will typically be used to identify the 2340 specification that defines the qualifier’s meaning and use. Qualifiers may be defined in 2341 this or other standard specifications, in specifications of a particular community of users 2342 or of implementations or by bilateral agreement. 2343

With “one-shot”, if there are multiple Inferiors created as a result of a single Application Messagethere is an ENROL and PREPARED message for each sent rel

ails, a CANC s sent iXT has “superior-ty related CONTEXT/atom, ir assosame Inferior, and EXT_REPe new ope

EPLY/repudinecessary to

D). If the “supech operatio te enrolmenone-shot” determinednferior) siden or by the binding in u

t to configuration

5.4 Extensibililify interoperation between implementations of this edition of BTP with implementatioditions, the “must-be-understood” sub-parameter as specified fo

defined for use withspecification. The d

cognised parameter without a “false” value for “must-be-understood” shall not accept it

parsing/unma“false” is present as a sub-parameter of a parameter in any message, a receiving impleme

ignore the parameter. How the su

. ial mechanis


qualifier name 2344 e ing s 2345 t2346

must-be-understood 2347 value no Qualifier type 2348

(or does not implem FAULT “UnsupportedQualifier” 2349 shall be returned an ll not be processed. Default is “true”. 2350

to-b d 2351 if this has the value the receiving entity passes the BTP message (which may 2352

EXT, but s to the same 2353 e shall e ll not be 2354

automatically include s. (If the receiving entity 2355 does support the qu pagated message may contain another 2356

e same type, nt – this is no2357 n of the o lse”. 2358

content 2359 the type (which may e content is defined by the 2360 specification of the Q2361

5.6 Messages not r or Control 2362 Relationships. 2363

The is section CONTEXT message is used in the 2364 Initiator:Factory relationship EGUN), and related to an 2365 application ‘message’ to prop tween parts of the 2366 app _REP TEX STATUS can be 2367 issued to, and STATUS retu r. FAULT can be used on 2368 any relationship to indicate a of a message. 2369

5.62370

A CONTEXT is supplied by ( of) a Superior and related to one or more Application 2371 Me w sented i and 2372 the bindin the Applicati erio s 2373 whether the Superior will apply the sa sion to all Inferiors enrolled using the same superior 2374 ide “ re ” is 2375 “cohesion”). 2376

erior-addre resse

superior-identifier Identifier

superior-type c

qualifiers iers

this identifies the mwithin the scope of

aning and use of the Qualifier, ushe Qualifier group.

a name that is unambiguou

if this has the “true” and the receiving entity does ent the necessary functionality), ad the message sha

t recognise the

e-propagate“true” and

be a CONTQualifier valu

can be other messages) onwardbe included. If the value is “false”, thd if the BTP message is passed onward

alifier type, it is possible a pro

other entities, Qualifier sha

instance of thpropagatio

even with the same Conteriginal qualifier.). Default is “fa

be structured) and meaning of thualifier.

t considered

estricted to outcome

messages in th are used between various roles.(when it is related to BEGIN or to Bagate the Business Transaction be

lication.CONTEXT LY is used as the reply to a CONrned by any of Decider, Superior or Inferion error condition back to the sender

T.REQUEST_

.1 CONTEXT or on behalf

ssages. (The means byg mechanisms of

hich this relationship is repreon Protocol.) The “sup

me deci

s determined by the bindingr-type” parameter identifie

ntifier (“superior-type” is atom”) or whether it may apply diffe nt decisions (“superior-type

Parameter T

sup

ype

ss Set of BTP Add s

ohesion/atom

List of qualif

reply-address BTP Address

ddress 2377 2378 2379

entifier 2380

superior-athe address to which ENROL and other messages from an enrolled Inferior are to be sent. This can be a set of alternative addresses.

superior-id


identifies the Superior. This shall be globally unambiguous. 2381

2382 2383

qualifie2384 2385 2386

reply2387 the address to which a replying CONTEXT_REPLY is to be sent. This may be different 2388

2389 2390 2391

the 2392 2393 2394 2395

2396

is sent after receipt of CONTEXT (related to Application Message(s)) to 2397 l necessary enrolments have already completed (ENROLLED has been 2398

2399 2400

ssage related to the CONTEXT). In some 2401 Application Message. CONTEXT_REPLY 2402

is used in some of the related groups to allow essages to be sent to a Superior with an 2403 Application Me2404

Ty

Id

-status compl ete/related/repudiated

Lis

superior-type identifies whether the CONTEXT refers to a Cohesion or an Atom. Default is atom.

rs standardised or other qualifiers. The standard qualifier “Transaction timelimit” is carried by CONTEXT.

-address

each time the CONTEXT is transmitted – it refers to the destination of a replying CONTEXT_REPLY for this particular transmission of the CONTEXT. It shall be absent when CONTEXT is transmitted as a parameter of the BEGIN or BEGUN messages.

There is no “target-address” parameter for CONTEXT as it is only transmitted in relation toApplication Messages or as a parameter of BEGIN and BEGUN. The forms CONTEXT/cohesion and CONTEXT/atom refer to CONTEXT messages with the “superior-type” with the appropriate value.

5.6.2 CONTEXT_REPLY CONTEXT_REPLYindicate whether alreceived) or will be completed by ENROL messages sent in relation to the CONTEXT_REPLY or if an enrolment attempt has failed. CONTEXT_REPLY may be sent related to an Application Message (typically the response to the Application Mebindings the CONTEXT_REPLY may be implicit in the

BTP mssage.

Parameter pe


inferior-identifier entifier

completion eted/incompl

qualifiers t of qualifiers

target-address BTP Addres

2405 2406 2407

2408 Superior 2409

y the CONTEXT. This parameter is optional (it is used in the 2410 2411

comple2412 ther all enrol operations made necessary by the receipt of the earlier 2413

2414

Value meaning

succeeded already

s

superior-identifier

m the CONTEXT the “superior-identifier” fro

inferior-identifier r-identifier” of an Inferior that has been (or is being) enrolled with the the “inferio

identified bCONTEXT_REPLY&Application message related group)

tion-status: reports wheCONTEXT message have completed. Values are

completed All enrolments (if any) have


Value meaning

plete incom Further enrolments are possible (used only in related groups with other BTP

L messages to the CONTEXT_REPLY. All

other enrolments (if any) have succeeded already.

rolment has failed. The eceiving the

CONTEXT have not been honoured.

qualifie2415 s. 2416

2417 2418 2419

2420 2421 2422

Y/completed or CONTEXT_REPLY/related. 2423 2424

2425 2426

pudiated is received, the receiving implementation must ensure that 2427 will not be confirmed. 2428

2429

Sent to an Inf r or to a Decider to to reply with STATUS. The receiver may 2430 reject the req StatusRefus2431

tifier Identifier

messages)

related At least some enrolments are to be performed by ENROrelated

repudiated At least one enimplications of r

rs standardised or other qualifier

target-address the address to which the CONTEXT_REPLY is sent. This shall be the “reply-address” from the CONTEXT.

The form CONTEXT_REPLY/completed, CONTEXT_REPLY/related and CONTEXT_REPLY/repudiated refer to CONTEXT_REPLY messages with status having the appropriate value. The form CONTEXT_REPLY/ok refers to either of CONTEXT_REPLIf there are no necessary enrolments (e.g. the Application Messages related to the received CONTEXT did not require the enrolment of any Inferiors), then CONTEXT_REPLY/completed isused. If a CONTEXT_REPLY/rethe Business Transaction

5.6.3 REQUEST_STATUS erior, Superio ask it uest with a FAULT( ed).

Parameter Type

target-iden

qualifiers List of qualifiers

target-address BTP Address


target-i2432 er for the Business Transaction, or part of Business Transaction whose status 2433

eter shall be the 2434 he “target-address” is an “inferior-2435

ress”, this parameter shall be the “inferior-identifier” on the ENROL message. If the 2436 dress”, this parameter shall be the “superior-identifier” 2437

2438

2439 2440

2441

dentifier The identifiis sought. If the target-address is a “decider-address”, this param“transaction-identifier” on the BEGUN message. If tadd“target-address” is a “superior-adon the CONTEXT.

qualifiers standardised or other qualifiers.

target-address


the address to which the REQUEST_STATUS message is sent. This can be any of 2442 ress”. 2443

reply-address 2444 to which the replying STATUS should be sent. 2445

2446 2447 2448 2449

StatusRefus2450 if the ared to repo to the sender of this message 2451

5.6.4 STA2452

Sent by a Infe n reply to a REQUEST_STATUS, reporting the overall 2453 state of the T Tree Node represent 2454

ifier

See below

“decider-address”, “inferior-address” or “superior-add

the address

Types of FAULT possible (sent to “reply-address”): General Redirect

if the intended target now has a different address

ed receiver is not prep rt its status

TUS rior, Superior or Decider i

ransaction ed by the sender.

Parameter Type

responders-ident Identifier

status



respon2455 the state, identical to the “target-identifier” on the REQUEST_STATUS. 2456

status 2457 tes the current status of the Transaction Tree Node represented by the sender. Some 2458

e sender is an Inferior. If the Transaction Tree Node is 2459 -coordinator or sub-composer), and two status 2460

ould be valid for the current state, it is the sender’s option which one is used. 2461

Not applicable The Inferior exists (and is

Not applicable ENROL has been sent, but ENROLLED is awaited

Active New enrolment of inferiors is possible

The Inferior is enrolled

has been sent; D is awaited

ders-identifier the identifier of

staof the values are only issued if thboth Superior and Inferior (i.e. is a subvalues w

status value

Meaning from Superior Meaning from Inferior

Created addressable) but it has not been enrolled with a Superior

Enrolling

Resigning Not applicable RESIGN RESIGNE

Resigned Not applicable RESIGNED has been received

Preparing Not applicable PREPARE has been received; PREPARED has not been sent


status value

Meaning from Superior Meaning from Inferior

Prepa cable PREPARED has been sent; no outcome has been received or autonomous decision made

Confirm Confirm decision hamade or CONFIRM

ived as Inferior ses from inferiors a

ng

as been received auto-confirm has been

cided (CONFIRMED/auto ot have been

nt); CONFIRMED/response has not been sent

have been received from all Inferiors

as been sent

has been made but responses from

CANCEL has been received or auto-cancel has been

NCELLED has been received from all Inferiors

CANCELLED has been sent

has not been received

ction Autonomous confirm decision was made, CANCEL received; CONTRADICTION has not been received

Hazard A hazard has been reported from at least one Inferior

A hazard has been discovered; CONTRADICTION has not

received

Unk o state information for the er exist

No state information for the target-identifier exists

Inac may be state information for this tidentifier but it cann

hed/existence cned

There may be state mation for this target-ifier but it cannot be

ched/existence cannot be ned

2462 2463

2464 ply-address” on the 2465

2466

red Not appli

ing s been has been

CONFIRM hor an

rece but deresponpendi

re may or may nse

Confirmed CONFIRMED/responses CONFIRMED/response h

Cancelling Cancel decision

inferiors are pending decided

Cancelled CA

Cancel- Not applicable Autonomous Cancel decision contradiction was made, CONFIRM

received; CONTRADICTION

Confirm- Not applicable contradi

been received

Contradicted Not applicable CONTRADICTION has been

nown Ntarget-identifi s

cessible Therearget-ot be

inforident

reac annot be readetermi determi


target-address the address to which the STATUS is sent. This will be the “reREQUEST_STATUS message


5.6.5 2467

s to report an error condition. The FAULT message is used on 2468 ps as a general negative reply to a message. 2469

rior-identifier Identifier

w

fault-text Text string


FAULT s messageSent in reply to variou

all the relationshi

Parameter Type

supe

inferior-identifier Identifier

fault-type See below

fault-data See belo


superior-identifier 2470 2471 2472

2473 2474 2475

fault-type 2476 identi e error, as s r each of the main messages. 2477

fault-data 2478 inform he particular h “fault-type” defines the content of the 2479 “fault2480

the “superior-identifier” as on the CONTEXT message and as used on the ENROL message (present only if the FAULT is sent to the superior).

inferior-identifier the “inferior-identifier” as on the ENROL message (present only if the FAULT is sent to the inferior)

fies the nature of th pecified fo

ation relevant to t error. Eac-data”:


fault-text

was received on

2481 rmation. Whether this parameter is 2482

plementation option. 2483

2484

faul

Any fault arising from the carrier mechanism and communication

Determined by the carrier mechanism and binding

problem

was sent to is not valid (at all or for this Terminator and transaction

The address

Inva ferior-identifier” in the

not identify a known Inferior

One or more invalid

The received identifier is not The identifier

StatusRef The receiver will not report the ested status r

stor

None

InvalidTer e address the was sent to is not valid (at all or for this

cider and tran r)

The address

UnknownP BTP messageceived with an

parameter

None

Unkunknown

The transaction-identifier

Unsis not recognised and on which “must-be-Understood” is “true”.

nd name

Wro e has arrived when the recipient or the transaction

None

The target of the BTP message now has a different address

Set of BTP Addresses, to be used instead of the

e

t-type meaning fault-data

re CommunicationFailu

infrastructure. specification

DuplicateInferior An inferior with the same address and identifier is already enrolled with this Superior

The identifier

General Any otherwise unspecified None

InvalidDecider The address the message

identifier)

lidInferior The “inmessage or at least one “inferior-identifier”s in an “inferior-list” parameter is not known or does

identifiers

InvalidSuperior known or does not identify a known Superior

used requstatuses) to this StatusRe

(or inferioque

minator Th message

De saction identifie

arameter A re

has been unrecognised

nownTransaction The transaction-identifier is

upportedQualifier A qualifier has been received that Qualifier group a

ngState The messag

identified by a related CONTEXT is in an invalid state.

Redirect

address the BTP messag

Free text describing the fault or providing more infopresent, and exactly what it contains are an im

qualifiers


standardised or other qualifiers. 2485

target-a2486 ch the FAULT is sent. This may be the “reply-address” from a received 2487 dress of the opposite side (superior/inferior) as given in a CONTEXT 2488

2489

2490 r than they were sent in, the 2491

“Wrong is not sent and sh e ignored if received. 2492

5.6.6 REQ OR_STATUSES, INFERIOR_STATUSES 2493

REQUEST_IN SES may be INFERIOR_STATUSES sent from any 2494 Decider, Supe ing it to repo tatus of its relationships with Inferiors (if 2495 any). Since Decid quired to respond to REQ OR_STATUSES with 2496 INFERIOR_S but non-Deciders ma T(StatusRefused), and 2497 INFERIOR_S o used as a rep sages from Terminator to Decider, 2498 these messages a ow under the m sed in the Control Relationships. 2499

used in the Outcome Relationships 2500

2501

A reque ceipt of a CONTEXT 2502 application request. 2503

2504

response-requested Boolean

Set of BTP Addresses

rior-identifier Identifier

ddress the address to whimessage or the ador ENROL message

Note – If the carrier mechanism used for the transmission of BTP messages is capable of delivering messages in a different orde

State” FAULT ould b

UEST_INFERIFERIOR_STATU sent to andrior or Inferior, ask rt on the s

ers are reTATUSES

UEST_INFERIy just issue FAUL

TATUSES is als ly to other mesre described bel essages u

5.7 Messages

5.7.1 ENROL st to a Superior to ENROL an Inferior. This is typically issued after re

message in relation to an The Actor issuing ENROL plays the Role of Enroller.

Parameter type


inferior-address

infe




superio2505 essage 2506

-requested 2507 ENROLLED response is required, false otherwise. Default is false. 2508

inferior2509 2510 2511

inferi2512 lly unambiguous.. 2513

2514 nt. 2515

target-address 2516

r-identifier. The “superior-identifier” as on the CONTEXT m

responsetrue if an

-address the address to which PREPARE, CONFIRM, CANCEL and SUPERIOR_STATE messages for this Inferior are to be sent.

or-identifier an identifier that identifies this Inferior. This shall be globa

qualifiers standardised or other qualifiers. The standard qualifier “Inferior name” may be prese


the address tCONTEXT m

o which the ENROL is sent. This will be the “superior-address” from the 2517 essage. 2518

2519 the address to which a replying ENRO is to be sent, if “response-requested” is true. 2520 If this field is absent and “response-re is true, the ENROLLED should be sent to 2521 the “i r one of them ’s option) 2522

Types of FAULT possible (sent to “reply-address”): 2523 General 2524 Redirect 2525

if the ifferent su2526

2527 e same and the same “inferior-2528

already enrolled 2529

WrongS2530 is too late to enrol new Inferiors (generally if the Superior has already sent a 2531

rior or terminator, or if it has already issued CONFIRM 2532 2533

/rsp-req refers to an ENROL message with “response-requested” having the 2534 value “t g 2535 the valu2536

is typically sent in relation to CONTEXT_REPLY/related. ENROL/rsp-req is 2537 typically has 2538 been re2539

2540

age, to indicate the Inferior has been 2541 the termination exchanges) 2542

Parameter Type


List of qualifiers

reply-address LLED

quested” nferior-address” (o , at sender

Superior now has a d perior-address

DuplicateInferior if inferior with at least one of the set “inferior-address” thidentifier” is

tate if it PREPARED message to its supeto other Inferiors).

The form ENROLrue”; ENROL/no-rsp-req refers to an ENROL message with “response-requested” havine “false”

ENROL/no-rsp-req when CONTEXT_REPLY/completed will be used (after the ENROLLED messageceived.)

5.7.2 ENROLLED Sent from Superior in reply to an ENROL/rsp-req messsuccessfully enrolled (and will therefore be included in


qualifiers


sender-address BTP Address

erior-identifier sup2543 2544

2545 2546

2547 2548

target-addre2549 the address to whi D is s will be the “reply-address” from the 2550 ENRO f the “inferior-address”es if the “reply-address” was empty) 2551

sender-addre2552

the “superior-identifier” as on the CONTEXT message

inferior-identifier the “inferior-identifier” as on the ENROL message

lifiers quastandardised or other qualifiers.

ss ch the ENROLLE

L message (or one osent. Thi

ss


the address from which the ENROLLED is sent. This is an address of the Superior. 2553

No FAULT m e issued on receiving2554

5.7.3 RES2555

Sent from an the Superior nferior from the enrolment. This can 2556 erations of the Business Transaction have had no effect as perceived by the 2557

Inferior. 2558 nt at any time prior to the sending of a PREPARED or CANCELLED message 2559 be sent). RESIGN may be sent in response to a PREPARE message. 2560

r-identifier identifier

List of qualifiers

essages ar ENROLLED.

IGN enrolled Inferior to to remove the I

only be sent if the op

RESIGN may be se(which cannot then

Parameter type

superior-identifier identifier

inferio


qualifiers



superior-identifier 2561 he “superior-identifier” as on the ENROL message 2562

er 2563 2564

ted 2565 D response is required. Default is “false”. 2566

quali2567 2568

targe2569 erior address as used on 2570

2571

2572 2573

2574 issued 2575

Types of FAU “sender-ad2576 General 2577 InvalidInferior 2578

if no E been received for th ier” 2579

WrongState 2580 if a P NCELLED has eceived by the Superior from this 2581

2582

The form response-requested” having the 2583 N /no-rsp-req refers to an RESIGN message with “response-requested” 2584 lse” 2585

T

inferior-identifiThe “inferior-identifier” as on the earlier ENROL message

response-requesis set to “true” if a RESIGNE

fiers standardised or other qualifiers.

t-address the address to which the RESIGN is sent. This will be the supthe ENROL message.

sender-address the address from which the RESIGN is sent. This is an address of the Inferior.

Note -- RESIGN is equivalent to readonly vote in some other protocols, but can be early.

LT possible (sent to dress”):

NROL had is “inferior-identif

REPARED or CA already been rInferior

RESIGN/rsp-req refers to an RESIGN message with “value “true”; RESIGhaving the value “fa


5.7.4 RESIGNED 2586

Sent in 2587

ior-identifier Identifier

reply to a RESIGN/rsp-req message.

Parameter Type


infer




inferior-identifier 2588 he “inferior-identifier” as on the earlier ENROL message for this Inferior. 2589

qualifiers 2590 r other qualifiers. 2591

2592 2593 2594

2595 ss from which the RESIGNED is sent. This is an address of the Superior. 2596

After is “inferior-2597 identi2598 Types2599

al 2600 tate 2601 if RES been sent 2602

5.7.5 PRE2603

Sent from Su to an Inferior from whom E er CANCELLED nor RESIGN have 2604 been received, requesting a PREPARED message.2605 PREPARED m2606

r

entifier Identifier

T

standardised o

target-address the address to which the RESIGNED is sent. This will be the “inferior-address” from the ENROL message.

sender-address the addre

receiving this message the Inferior will not receive any more messages with thfier”. of FAULT possible (sent to “sender-address”):

GenerWrongS

IGN has not

PARE perior NROL but neith

PREPARE can be sent after receiving a essage.

Parameter Type

superior-identifie Identifier

inferior-id




superio2607 2608

ntifier 2609 arlier ENROL message. 2610

2611

r-identifier the “superior-identifier” as on the CONTEXT message

inferior-idethe “inferior-identifier” as on the e

qualifiers


standardised or other qualifiers. The standard qualifier “Minimum inferior timeout” is carried by PREPAR

2612 E. 2613

2614 ddress” 2615

2616

ddress 2617 ess from which the PREPARE is sent. This is an address of the Superior. 2618

On rece D, CANCELLED or RESIGN. 2619 2620 2621 2622

has already been received by this Inferior. 2623

2624

2625 Inferior has d operations associ ith the Inferior can be confirmed and can be 2626 cancelled, as y the Super on is a local matter (i.e. it is 2627 the Inferiors c ed by the sh nding of the application exchanges) – 2628 other access ay see applie f operations or may see the original state. 2629

r

r

-is cancel Boolean

target-address the address to which the PREPARE message is sent. This will be the “inferior-afrom the ENROL message.

sender-athe addr

iving PREPARE, an Inferior should reply with a PREPARETypes of FAULT possible (sent to “sender-address”): General WrongState

if a CONFIRM or CANCEL

5.7.6 PREPARED Sent from Inferior to Superior, either unsolicited or in response to PREPARE, but only when the

etermined the ated wmay be instructed bhoice, as constrain

ior. The level of isolatiared understa

may be blocked, m d results o

Paramete Type

superior-identifie Identifier


default




superior-identifier 2630 ENROL message 2631

r 2632 2633

2634 2635 2636

e, it will Cancel the associated operations. 2637 he value “true” will invariably be used with a qualifier indicating under what 2638 rcumstances (usually a timeout) an autonomous decision to Cancel will be made. If 2639

t a CONFIRM or CANCEL message as appropriate, even if 2640 us decision will be made. 2641

2642 r other qualifiers. The standard qualifier “Inferior timeout” may be carried 2643

2644

targ2645

the “superior-identifier” as on the

inferior-identifieThe “inferior-identifier” as on the ENROL message

default-is-cancel if “true”, the Inferior states that if the outcome at the Superior is to Cancel the operations associated with this Inferior, no further messages need be sent to the Inferior. If the Inferior does not receive a CONFIRM messagTci“false”, the Inferior will expecqualifiers indicate that an autonomo

qualifiers standardised oby PREPARED.

et-address


the address to which the PREPARED is sent. This will be the Superior address as on thENROL message.

sender-address the address from which the PREPARED is sent. This is an address of the Inferior.

On sending a PREPARED, the Inferior undertakes to maintain its ability to Confirm or Cancel the effects of the associated opera

e 2646 2647

2648 2649

2650 tions until it receives a CONFIRM or CANCEL message. Qualifiers 2651

may define a time limit or other constraints on omise. The “default-is cancel” parameter 2652 affects only the su xchan s not of itself state that cancellation will 2653 occur. 2654 Types of FAU to “sender-ad2655 General 2656 InvalidInferio2657

if no E been received for th ier”, or if RESIGN has been 2658 received from this Inferior 2659

The form PRE refers to a PRE ge with “default-is cancel” = “true”. 2660 The unqualifie D refers to a essage with “default-is cancel” = 2661

2662

5.7.7 2663

r to an Inferior from whom PREPARED has been received. 2664


lifiers

this prbsequent message e ges and doe

LT possible (sent dress”):

r NROL has is “inferior-identif

PARED/cancel PARED messad form PREPARE PREPARED m

“false”.

CONFIRM Sent by the Superio

Parameter Type


qualifiers List of qua



NTEXT message superior-identifier 2665

the “superior-identifier” as on the CO2666

inferior-identifier 2667 The “ on the earli2668

qualifiers 2669 stand ifiers. 2670

target-address 2671 the address to which the CONFIRM m t. This will be the “inferior-address” 2672 from . 2673

sender-address 2674 the address from which the CONFIRM ss of the Superior. 2675

On receiving s releas e 2676 operations associated with the Inferior. The e ailable to 2677 everyone (if they weren’t already). 2678 Types of FAULT possible (sent to “sender-ad2679 General 2680

inferior-identifier” as er ENROL message for this Inferior.

ardised or other qual

essage is senthe ENROL message

is sent. This is an addre

CONFIRM, the Inferior i ed from its promise to be able to undo thffects of the operations can be made av

dress”):


WrongState 2681 if no PREPARED has been sent by, o y this Inferior. 2682

5.7.8 CONFIRMED 2683

Sent after the Inferior has applied the confirmation, bo NFIRM or when the Inferior 2684 decision, and in reply to a CONFIRM_ONE_PHASE if the 2685

Inferior 2686


Identifier

firm-received Boolean

r if CANCEL has been received b

th in reply to COhas made an autonomous Confirm

decides to Confirm its associated operations.

Parameter Type

inferior-identifier

con




superio2687 2688

2689 ssage. 2690

2691 2692 2693 2694 2695

2696 2697

2698 2699 2700

2701 CONFIRMED is sent. This is an address of the Inferior. 2702

ender-address”): 2703 2704 2705 2706 2707

2708 2709 2710 2711

he form CONFIRMED/auto refers to a CONFIRMED message with “confirm-received” = “false”; 2712 D/response refers to a CONFIRMED message with “confirm-received” = ”true”. 2713

r-identifier the “superior-identifier” as on the CONTEXT message.

inferior-identifier the “inferior-identifier” as on the earlier ENROL me

confirm-received “true” if CONFIRMED is sent after receiving a CONFIRM message; “false” if an autonomous Confirm decision has been made and either if no CONFIRM message has been received or the implementation cannot determine if CONFIRM has been received (due to loss of state information in a failure).


target-address the address to which the CONFIRMED is sent. This will be the Superior address as on the CONTEXT message.

sender-address the address from which the

Types of FAULT possible (sent to “sGeneral InvalidInferior

if no ENROL has been received for this “inferior-identifier”, or if RESIGN has been received from this Inferior.

Note – A CONFIRMED message arriving before a CONFIRM message is sent, or after a CANCEL has been sent, will occur when the Inferior has taken an autonomous decision and is not regarded as occurring in the wrong state. (The latter will cause a CONTRADICTION message to be sent.)

TCONFIRME


5.7.9 CAN2714

Sent by the S r at any time before (and unless) CONFIRM has been sent. 2715

r-identifier Identifier

CEL uperior to an Inferio

Parameter Type

superio





superior-identifier 2716 2717

2718 sage. 2719

rs 2720 2721

target-addr2722 the a the CANCEL m or-address” 2723 from the ENROL message. 2724

sender-address 2725 the address from which the CANCEL perior. 2726

When received by an Inferior, the effects of a nferior should be 2727 undone. If the Inferior had sent PREPARED, e to 2728 Confirm the o2729 Types of FAULT possible (sent to “sender-ad2730 General 2731 WrongState 2732

if a CONFIRM has been received by 2733

5.7.10 CANCELLED 2734

Sent when the Inferior h d (or is appl ssociated with 2735 the Inferior. CANCELLED is sent from Inferio2736 • before (and instead of) sending PREPAR unable to apply the 2737

operation cancelling all of th2738 • in reply to CANCEL, regardless of whethe2739 • after sending PREPARED and then maki sion to Cancel; 2740 • in reply to CONFIRM_ONE_PHASE if the Inferior decides to Cancel the associated 2741

operations2742 As is specified in the state tables, cases 1, 2 stances 2743 of recovery and resending of messages. 2744

Parameter

identifier Identifier


the “superior-identifier” as on the CONTEXT message

inferior-identifier the “inferior-identifier” as on the earlier ENROL mes

qualifiestandardised or other qualifiers.

ess ddress to which essage is sent. This will be the “inferi

is sent. This is an address of the Su

ny operations associated with the Ithe Inferior is released from its promise to be abl

dress”): perations.

this Inferior.

as applie ying) cancellation of the operations ar to Superior in the following cases: ED, to indicate the Inferior is

s in full and is em; r PREPARED has been sent;

ng and applying an autonomous deci

. and 3 are not always distinct in some circum

superior-


Parameter




er 2745 2746

inferior-identifier 2747 r identifier as on the earlier ENROL message. 2748

qualifiers 2749 2750

2751 2752 2753

2754 2755

2756 2757 2758 2759 2760

2761 2762

2763 2764 2765 2766

5.7.11 CONFIRM_ONE_PHASE 2767

n enrolled Inferior, when there is only one such enrolled Inferior. In this 2768 2769 2770

eter Type

tifier Identifier

lifiers

superior-identifithe “superior-identifier” as on the CONTEXT message.

the inferio

standardised or other qualifiers.

target-address the address to which the CANCELLED is sent. This will be the Superior address as on the CONTEXT message.

sender-address the address from which the CANCELLED is sent. This is an address of the Inferior.

Types of FAULT possible (sent to “sender-address”): General InvalidInferior

if no ENROL has been received for this ”inferior-identifier”, or if RESIGN has been received from this Inferior

WrongState if CONFIRM has been sent

Note – A CANCELLED message arriving before a CANCEL message is sent, or after a CONFIRM has been sent, will occur when the Inferior has taken an autonomous decision and is not regarded as occurring in the wrong state. (The latter will cause a CONTRADICTION message to be sent.)

Sent from a Superior to acase the two-phase exchange is not performed between the Superior and Inferior and the outcome decision for the operations associated with the Inferior is determined by the Inferior.

Param

superior-iden


qualifiers List of qua



superior-iden2771 the “s ” as on the CO e 2772

2773 The “inferior-identifier” as on the earlier ENROL message for this Inferior. 2774

tifier uperior-identifier NTEXT messag

inferior-identifier


qualifie2775 2776

2777 message is sent This will be the 2778

r-address” on the ENROL message. 2779

sender2780 This is an address of the 2781

r. 2782

CONFIR2783 ed (subject to the requirement that there is only one enrolled Inferior). 2784

r-address”): 2785 2786

5.7.122787

d 2788 ior is 2789

as not occurred. 2790 2791 2792 2793

it signals that 2794 ive a confirmatory 2795

r CANCEL, or a CONTRADICTION if the autonomous decision by the 2796 the opposite of that made by the Superior. 2797

2798

entifier

ifier er

rs standardised or other qualifiers.

target-address the address to which the CONFIRM_ONE_PHASE “inferio

-address the address from which the CONFIRM_ONE_PHASE is sent. Superio

M_ONE_PHASE can be issued by a Superior to an Inferior from whom PREPARED has been receivTypes of FAULT possible (sent to “sendeGeneral

HAZARD Sent when the Inferior has either discovered a “mixed” condition: that is unable to correctly anconsistently Cancel or Confirm the operations in accord with the decision , or when the Inferunable to determine that a “mixed” condition hHAZARD is also used to reply to a CONFIRM_ONE_PHASE if the Inferior determines there is a mixed condition within its associated operations or is unable to determine that there is not a mixed condition.

Note - If the Inferior makes its own autonomous decision, thendecision with CONFIRMED or CANCELLED and waits to receCONFIRM oInferior was

Parameter Type

superior-identifier Id

inferior-ident Identifi

level mixed/possible




superior-iden2799 ior-identifier” as on the ENROL message 2800

inferior2801 ENROL message 2802

2803 ue 2804

2805

qualifie2806 tandardised or other qualifiers. 2807

target-address 2808

tifier The “super

-identifier The “inferior-identifier” as on the earlier

level indicates, with value “mixed” that a mixed condition has definitely occurred; or, with val“possible” that it is unable to determine whether a mixed condition has occurred or not.

rs s


the address to which the HAZARD is sent. This will be the superior address from the ENROL message.

-address

2809 2810

sender2811 ss from which the HAZARD is sent. This is an address of the Inferior. 2812

Types o2813 Genera2814

2815 2816

2817 2818

2819

Sent the 2820 decis ED or 2821 CANC e. 2822

dentifier Identifier

er


the addre

f FAULT possible (sent to “sender-address”): l

InvalidInferior if no ENROL has been received for this “inferior-identifier”

The form HAZARD/mixed refers to a HAZARD message with “level” = “mixed”, the form HAZARD/possible refers to a HAZARD message with “level” = “possible”.

5.7.13 CONTRADICTION by the Superior to an Inferior that has taken an autonomous decision contrary toion for the Atom. This is detected by the Superior when the ‘wrong’ one of CONFIRMELLED is received. CONTRADICTION is also sent in response to a HAZARD messag

Parameter Type

superior-i

inferior-identifier Identifi



superio2823 XT message 2824

2825 r-identifier” as on the earlier ENROL message for this Inferior. 2826

2827 stand r qualifiers. 2828

target-addre2829 the address to whi RADICTI will be the “inferior-2830 addre OL message. 2831

sender-addre2832 the address from which the CONTRA is an address of the Superior. 2833

Types of FAU e (sent to “sender-ad2834 General 2835

IOR_STATE 2836

Sent by2837 • in th2838 • there is u re 2839

n). 2840

r-identifier the “superior-identifier” as on the CONTE

inferior-identifier The “inferio

qualifiers ardised or othe

ss ch the CONT ON message is sent. This

ss” from the ENR

ss DICTION is sent. This

LT possibl dress”):

5.7.14 SUPER a Superior as a query to an Inferior when e active state

ncertainty what state the Inferior has reached (due to recovery from previous failuor other reaso


Also se2841 messag2842 messag d the Superior is waiting on some other event before it can 2843

ws implementations to avoid excessive retransmissions of 2844 nding a SUPERIOR_STATE/*-received does not necessarily imply the 2845

receipt d 2846 with a n2847

status see below

List of qualifiers

nt by the Superior to the Inferior in response to a received INFERIOR_STATE or other e, in particular states. The <message>-received values can be used when a normal e has been received an

proceed with the protocol. This allomessages. However, se

of the previous message has been recorded persistently. (though this could be indicateon-standard qualifier)

Parameter Type




qualifiers



superio2848 2849

2850 2851

2852 of its relation to this Inferior only. 2853

Meaning

r )

D has been received from ome is yet

received to has been received

lable

ed as been received from sult of an

cision), but no outcome is yet available

or for its relationship with this Inferior, if it exists, cannot be accessed at the

it does not

r-identifier the “superior-identifier” as on the CONTEXT message

inferior-identifier The “inferior-identifier” as on the earlier ENROL message for this Inferior.

status states the current state of the Superior, in terms

status value

active The relationship with the Inferior is in the active state from the perspective of the Superior; ENROLLED has been sent, PREPARE has not been sent and PREPARED has not been received (as far as the Superioknows

prepared-received PREPAREthe Inferior, but no outcavailable

confirmed- CONFIRMED/aufrom the Inferior, but no outcome is yet avai

cancelled-receiv CANCELLED hthe Inferior (as a reautonomous de

inaccessible The state information for the Superior,

moment. This should be a transient condition

unknown The Inferior is not known –

status value Meaning exist from the perspective of the Superior. The Inferior can treat this as

respon2854 true, if SUPERIOR_STATE is sent as a query at the Superior’s initiative; false, if 2855 SUPERIOR_STATE is sent in reply to a received INFERIOR_STATE or other message. 2856 Can o true if status is active or prepared-received. Default is “false” 2857

qualifiers 2858 standardised or other qualifiers. 2859

target-address 2860 the address to which the SUPERIOR s sent. This will be the “inferior-2861 addre e ENROL message. 2862

sender-address 2863 the address from which the SUPERIOR_ t. This is an address of the 2864

2865

The Inferio uested = true, should reply in a 2866 timely m2867 INFERI he appropriate status value. 2868

wn shall only be sent if it has been determined for certain that the Superior has 2869 no know the 2870 Inferior 2871 it is not IOR_STATE/*/y (or other) message 2872

uperior or that entity cannot determine whether any such persistent information 2873 exists o2874

2875 2876

2877 ith 2878

2879 lue/y refers to a similar message, but with “response-requested” = “true”. The form 2880

2881 2882

2883

n Inferior as a query when in the active state to a Superior, when (due recovery from 2884 er reason) there is uncertainty what state the Superior has reached. 2885

n response to a received SUPERIOR_STATE or other 2886 messag ssage>-received values can be used when a normal 2887

as been received and the Inferior is waiting on some other event before it can give a 2888 retransmissions of messages. 2889

Howeve t necessarily imply the receipt of the 2890 een recorded persistently. (though this could be indicated with a non-2891

standar2892 2893

an instruction to Cancel any associated operations

se-requested

nly be

_STATE message iss” from th

STATE is senSuperior.

r, on receiving SUPERIOR_STATE with “response-reqanner by (depending on its state) repeating the previous message it sent or by sending

OR_STATE with tA status of unkno

ledge of the Inferior, or (equivalently) it can be determined that the relationship with was cancelled. If there could be persistent information corresponding to the Superior, but accessible from the entity receiving an INFER

targeted to the Sr not, the response shall be Inaccessible.

SUPERIOR_STATE/unknown is also used as a response to messages, other than INFERIOR_STATE/*/y, that are received when the Inferior is not known (and it is known there isno state information for it). The form SUPERIOR_STATE/some-status-value refers to a SUPERIOR_STATE message wthe specified status value and with “response-requested” = “false”. SUPERIOR_STATE/some-status-vaSUPERIOR_STATE/*/y refers to a SUPERIOR_STATE message with “response-requested” = “true” and any value for status.

5.7.15 INFERIOR_STATE Sent by aprevious failure or othAlso sent by the Inferior to the Superior i

es, in particular states. The <memessage hdefinite reply. This allows implementations to avoid excessive

r, sending a SUPERIOR_STATE/*-received does noprevious message has b

d qualifier)

Parameter Type

List of qualifiers



status see below


qualifiers



superior-iden2894 The “ d on th message 2895

inferior-iden2896 The “ r” as on the ENR age 2897

status 2898 states Inferior e sent to the 2899 Superi2900

ious message sent

p with the Superior is in the active state from the perspective of the Inferior; ENROL

PREPARED has not been made.

able to reply with CONFIRMED, CANCELLED or HAZARD.

The state information for the relationship with the Superior, if it

wn r is not known – it does not om the perspective of the

response-requested 2901

tifier superior-identifier” as use e ENROL

tifier inferior-identifie OL mess

the current state of theor by (or in the case of ENROL for) the Infe

, which corresponds to the last messagrior

status value meaning/prev

active The relationshi

has been sent, a decision to send

prepare-received PREPARE has been received from the Superior, but the Inferior is not yet able to reply with PREPARED, CANCELLED or RESIGN.

confirm-received CONFIRM has been received from the Superior, but the Inferior is not yet able to reply with CONFIRMED, CANCELLED or HAZARD.

cancel-received CANCEL has been received from the Superior, but the Inferior is not yet

inaccessible

exists, cannot be accessed at the moment. This should be a transient condition

unkno The Inferioexist frSuperior. The Inferior can be treated as cancelled


“true” if INFERIOR_STATE is sent as a query at the Superior’s initiative; “false” if 2902 INFERIO in reply to a re essage. 2903 Can o e” if “status” is “active “false” 2904


target-a2907 2908

OL message. 2909

sender2910 2911

receiving INFERIOR_STATE with “response-requested” = “true”, should reply in 2912 2913

SUPER2914 A status of “u determined for certain that the Inferior has 2915

a relationship with the Superior. If there could be persistent information 2916 corresp2917

2918 2919 2920 2921 2922 2923 2924

ior, and related Application 2925 Eleme EXT. 2926 Simila on the 2927 progr2928 The fo ATE message with the 2929

2930 2931 2932 2933

2934

2935 2936 2937

R_STATE is sent nly be “tru

ceived SUPERIOR_STATE or other m” or “prepared-received”. Default is

ddress the address to which the INFERIOR_STATE is sent. This will be the “target-address” asused the original ENR

-address the address from which the INFERIOR_STATE is sent. This is an address of the Inferior.

The Superior, ona timely manner by (depending on its state) repeating the previous message it sent or by sending

IOR_STATE with the appropriate status value. nknown” shall only be sent if it has been

no knowledge ofonding to the Superior, but it is not accessible from the entity receiving an

SUPERIOR_STATE/*/y (or other) message targetted on the Inferior or the entity cannot determine whether any such persistent information exists, the response shall be “inaccessible”. INFERIOR_STATE/unknown is also used as a response to messages, other than SUPERIOR_STATE/*/y, that are received when the Inferior is not known (and it is known there is no state information for it). A SUPERIOR_STATE/INFERIOR_STATE exchange that determines that one or both sides are in the active state does not require that the Inferior be cancelled (unlike some other two-phase commit protocols). The relationship between Superior and Infer

nts may be continued, with new Application Messages carrying the same CONTrly, if the Inferior is prepared but the Superior is active, there is no required impact

ession of the relationship between them. rm INFERIOR_STATE/some-status-value refers to a INFERIOR_ST

specified status value and with “response-requested” = “false”. INFERIOR_STATE/some-status-value/y refers to a similar message, but with “response-requested” = “true”. The form INFERIOR_STATE/*/y refers to a INFERIOR_STATE message with “response-requested” = “true” and any value for status.

5.7.16 REDIRECT Sent when the address previously given for a Superior or Inferior is no longer valid and the relevant state information is now accessible with a different address (but the same superior or “inferior-identifier”).

Parameter Type



old-address Set of BTP Addresses

new-address Set of BTP Addresses



superior-identifier 2938


The “superior-identifier” as on the CONTEXT message and used on an ENROL 2939 nt only if the REDIRECT is sent from the Inferior). 2940

inferior2941 e “inferior-identifier” as on the ENROL message 2942

old-add2943 dress of the sender of REDIRECT. A match is considered to apply if any 2944

at is already known. 2945

2946 s sent to this entity. 2947

2948 2949

2950 2951 2952

If the Actor whose address is changed is an Inferior, the “new-address” value replaces the 2953 2954

e replaces the 2955 sm 2956

2957

5.8 Messages used in Control Relationships 2958

5.8.1 BEG2959

A request to a create a new Busine his may either be a new top-level 2960 transaction, in Composer or C be the Decider, or the new Business 2961 Transaction may be immediately made the Inferior within an existing Business Transaction (thus 2962

r or sub-Coordinator). 2963

transaction-type cohesion/atom

CONTEXT message

lifiers List of qualifiers

message. (prese

-identifier Th

ress The previous adof the “old-address” values match one th

new-address The (set of alternatives) “new-address” values to be used for message


target-address the address to which the REDIRECT is sent. This is the address of the opposite side (superior/inferior) as given in a CONTEXT or ENROL message

“inferior-address” as present in the ENROL. If the Actor whose address is changed is a Superior, the “new-address” valuSuperior address as present in the CONTEXT message (or as present in any other mechaniused to establish the Superior:Inferior relationship).

IN Factory to ss Transaction. T which case the oordinator will

creating a sub-Compose

Parameter Type

context

qua



transaction-type 2964 2965 2966

qualifiers 2967 stand iers. The ualifier “Transaction timelimit” may be 2968 prese set the timelim ew Business Transaction and will be 2969 copied to the new NTEXT. The stan “Inferior name” may be present if 2970 there EXT related to the B2971

context 2972

identifies whether a new Cohesion or new Atom is to be created; this value will be the “superior-type” in the new CONTEXT

ardised or other qualif standard qnt on BEGIN, to

COit for the n

dard qualifier is a CONT EGIN.


the CONTEXT of an existing Business Transaction. This parameter is present only if a 2973 sub-Com nator is being created. If present, the “reply-address” 2974 param TEXT shall be2975

target-addre2976 he entity to which the BEGIN is sent. How this address is acquired and 2977

2978

2979 ould be 2980

2981

A new t2982 Transac2983 parame2984

as an Inferior of the Superior identified in that CONTEXT. 2985

N rovide a standardised means to determine 2986 poser are in its Confirm set. This is considered 2987

n:inferior relationship. 2988

The form e 2989 corresp2990 Types of FAULT possible (sent to “reply-address”): 2991 General 2992 Redirect 2993

if the Factory now has a different add2994

WrongState 2995 only issued if the context field is present r identified by that CONTEXT is 2996 in the te to enrol new Inferio2997

5.8.2 BEGUN 2998

BEGUN 2999 the new3000

ider-address Set of BTP Addresses

r

ntext CONTEXT message

poser or sub-Coordieter of the CON absent.

ss the address of tthe nature of the entity are outside the scope of this specification.

reply-address the address to which the replying BEGUN and related CONTEXT message shsent.

op-level Business Transaction is created if there is no context parameter. A Business tion that is to be Inferior in an existing Business Transaction is created if the context ter is present. In this case, the Factory is responsible for enrolling the new Composer or

Coordinator

ote – This specification does not pwhich of the Inferiors of a sub-Compart of the applicatio

s BEGIN/cohesion and BEGIN/atom refer to BEGIN with “transaction-type” having thonding value.

ress

and the Superio wrong sta rs

is a reply to BEGIN. There is always a contained CONTEXT, which is the CONTEXT for Business Transaction.

Parameter Type

dec

inferior-address Set of BTP Addresses

transaction-identifier Identifie

co



decider-address for a top-m

3001 ost transaction (no context parameter on the BEGIN), this is the address to 3002

ION, 3003 3004 3005

3006 rameter was present on the BEGIN), this is 3007

the “inferior-address” used in the enrolment of this Business Transaction with the 3008

which PREPARE_INFERIORS, CONFIRM_TRANSACTION, CANCEL_TRANSACTCANCEL_INFERIORS and REQUEST_INFERIOR_STATUSES messages are to be sent; if a context parameter was present on the BEGIN this parameter is absent

inferior-address for a non-top-most transaction (a context pa


Superior identified by the context parameter on the BEGIN. The parameter is optional 3009 r’s choice) if this is not a top-most transaction; it shall be absent if this is a 3010

3011

dentifier 3012 mbiguous identifier for the new 3013 -most transaction, the transaction-3014

the inferior-identifier used in the enrolment of this Business Transction 3015 xt parameter of the BEGIN. 3016

he “transaction-identifier” may be identical to the “superior-identifier” in the 3017 XT message in the context parameter of this BEGUN. 3018

context 3019 ss Transaction, ready to be propagated by application 3020

3021

3022 stand her qualifiers. 3023

target-addre3024 the a ch the BEGUN is s e “reply-address” from the BEGIN. 3025

At implementation option, the “decider-addres r-address” and the “superior-3026 address” in th T message in the co ay be the same or may be 3027 different. The requirement that they even use the same bindings. Any may also be 3028 the same as the “target-a ss” of the BEGIN entifier on messages will ensure 3029 they are appli priate Composer ). 3030

e issued on receiving BEGUN. 3031

ARE_INFERIORS 3032

Sent fro e all 3033 or some , 3034 RESIGN o3035

absent, the request applies to all the inferiors; if the parameter is 3036 present feriors of the Decider (Composer). 3037

ameter Type

(implementotop-most transaction.

transaction-iif this is a top-most transaction, this is an globally-unaDecider (Composer or Coordinator). If this is not a topidentifier shall bewith the Superior identified by the conte

Note – TCONTE

the context for the new Busine means or used for enrolment.

qualifiers ardised or ot

ss ddress to whi ent. This will be th

s” and/or “inferiontext parameter me CONTEX

re is no general ddre

ed to the appro message (the id

or CoordinatorNo FAULT messages ar

5.8.3 PREPm a Terminator to a Decider, but only if it is a Cohesion Composer, to tell it to prepar of its inferiors, by sending PREPARE to any that have not already sent PREPARED

r CANCELLED to the Decider (Composer) on its relationships as Superior. If the inferiors-list parameter is

, it applies only to the identified in

Par

transaction-identifier Identifier

inferiors-list List of Identifiers


targetted-qualifiers-list List of Targetted-qualifiers-items (see below)



transaction-identifier identifies the Decider and will be the transaction-identifier from the

3038 BEGUN message. 3039

inferi3040 g the 3041

“inferior-identifiers” as on the ENROL received by the Decider (in its Role as Superior). If 3042 this parameter is absent, the PREPARE applies to all Inferiors. 3043

ors-list defines which of the Inferiors of this Decider preparation is requested for, usin



3044 3045

3046 ntains a number of Targetted-qualifiers-items identifying one or more Inferiors and 3047 ntaining one or more qualifiers that are to be sent to each of those inferior if it is 3048

d. The fields of an Targetted-qualifers-item are: 3049

3050

Field Type

more Inferior-identifiers (each of which shall be one

those in the inferiors-list meter), identifying which inferiors

this item refers to.

t to the identified inferiors on the PREPARE

erior whose inferior-identifier is in the inferior-identifier-list, the qualifiers are 3051 included in the PREPARE message sent to that Inferior. 3052

ancelled, prepared or resigned, the qualifiers 3053 3054

3055 3056 3057

reply-addres3058 the address of the Terminator sending the PREPARE_INFERIORS message. 3059

For all Inferio in the inferiors-list p iors if the parameter is absent), 3060 from which none of PREPARED, CANCELLE has been received, the Decider 3061 shall issue PR eply to the Term e “reply-address” on the 3062

sending an INFERIOR_STATUSES message giving the 3063 fied on the inferiors-list parameter (all of them if the parameter was 3064

absent)3065 If one or more of the “inferior-identifier”s in the "inferior-list" is unknown (does not correspond to 3066

Inferior), a FAULT/Invalid-inferior shall be returned. It is an implementation option 3067 eriors that are validly identified in the "inferiors-list". 3068

Types of FAULT possibl ress): 3069 3070

InvalidD3071 if Decider address is unknown 3072

3073 3074

3075 3076

3077 if one or more inferior-identifiers on the inferiors-list is unknown 3078

targetted-qualifiers-list: cococonfirme

inferior-identifier-list A list of one or

ofpara

qualifiers A list of qualifiers to be sen

messages.

For each Inf

NOTE – If an Inferior has spontaneously cwill not be sent.

target-address the address to which the PREPARE_INFERIORS message is sent. This will be the decider-address from the BEGUN message.

s

rs identified arameter (all InferD or RESIGNED

EPARE. It will r inator, using thPREPARE_INFERIORS message,status of the Inferiors identi

.

an enrolledwhether CANCEL is sent to any of the Inf

e (sent to Superior addGeneral

ecider

Redirect if the Decider now has a different “decider-address”

UnknownTransaction if the transaction-identifier is unknown

InvalidInferior


WrongState 3079 if a C N or CA ANSACTION has already been received 3080 by thi3081

The form PREPARE_INFERIORS/all refers to ERIORS message where the 3082 “inferiors-list” parameter is absent. The form PREPARE_INFERIORS/specific refers to a 3083 PREPARE_INFERIORS message where the arameter is present. 3084

5.8.4 CON NSACTION 3085

inator to a Decider to request confirmation of the Business Transaction. If the 3086 Busines r. 3087

ction-identifier Identifier

rs-list List of Identifiers

d-qualifiers-list List of Targetted-qualifiers-items (see below)

ONFIRM_TRANSACTIOs Composer.

NCEL_TR

a PREPARE_INF

“inferiors-list” p

FIRM_TRASent from a Term

s Transaction is a Cohesion, the Confirm-set is specified by the “inferiors-list” paramete

Parameter Type

transa

inferio

report-hazard Boolean


targette



transac3088 3089

3090 poser, are to be 3091 he Decider (in its 3092

ecider is an Atom Coordinator. 3093

zard 3094 fines whether the Terminator wishes to be informed of hazard events and 3095

tion. If “report-hazard” is “true”, the 3096 will wait until responses (CONFIRMED, CANCELLED or HAZARD) have been 3097 from all of its inferiors, ensuring that any hazard events are reported. If “report-3098

3099 3100

qualifie3101 other qualifiers. 3102

targette3103 d 3104

r if it is 3105 3106

Type

tion-identifier identifies the Decider. This will be the transaction-identifier from the BEGUN message.

inferiors-list defines which Inferiors enrolled with the Decider, if it is a Cohesion Comconfirmed, using the “inferior-identifiers” as on the ENROL received by tRole as Superior). Shall be absent if the D

report-haDecontradictory decisions within the Business Transacreceiver received hazard” is “false”, the Decider will reply with TRANSACTION_CONFIRMED or TRANSACTION_CANCELLED as soon as the decision for the transaction is known.

rs standardised or

d-qualifiers-list: contains a number of Targetted-qualifiers-items identifying one or more Inferiors ancontaining one or more qualifiers that are to be sent to each of those inferioconfirmed. The fields of an Targetted-qualifers-item are:

Field

inferior-identifier-list A list of one or more Inferior-identifiers, identifying which inferiors this item refers to.


Field Type

qualifiers A list of qualifiers to be sent to the RM

If a C n is made, and se inferior-identifier is in the inferior-3107 n the confirm-set, the qualifiers are included in the CONFIRM message 3108 rior. 3109

riors not in the 3110 firm-set, CANCEL), the PREPARE_INFERIORS (or CANCEL_INFERIORS) 3111

3112

target-a3113 the address to which the CONFIRM_ ACTION message is sent. This will be the 3114 “decide EGUN messa3115

reply-address 3116 the address of the Terminator sendin TRANSACTION message. 3117

If the “inferior rameter is present, the -set” of the 3118 Cohesion. It the parameter is absent and the the “Confirm-3119 set” shall be a g Inferiors. If the Bus irm-set” is 3120 automatically all the Inferiors. 3121 Any Inferiors from which RESIGN is received3122 If, for each of the Inferiors in the Confirm-set, nt and PREPARED has 3123 not bee3124

N D not yet received from an 3125 Inferior set, it is a tation option whether and when to re-3126 send P Superior im tion may choose to re-send PREPARE if 3127 there a tions that the ear elivered. 3128

A Confirm de be made only Inferiors in the 3129 “Confirm-set”. The making of the decis be persistent (and if it is not possible to persist the 3130 decision, it is If there is only t” and PREPARE 3131 has not been ONFIRM_ON3132 All remaining Inferiors that are not in th3133 If a Confirm decision is made and “rep ” was “false”, a TRANSACTION_CONFIRMED 3134 message sha the “reply-ad3135 If a Cancel de nd “repo ANCELLED 3136 message sha “reply-ad3137 If "report-hazard" was "tru CTIO ddress" 3138 after CONFIR received CELLED or 3139 RESIGN from ny Inferior no3140 If “report-hazard” was “true” and any HAZARD o s received (i.e. 3141 CANCELLED rior in the Co t in the 3142 Confirm-set), an INFERIOR_STATUSE us for all Inferiors shall be sent to the 3143 “reply-addres3144 If one or more of the "inferior-identifier" orrespond to 3145 an enrolled In ULT/Invalid-i ot make a 3146 Confirm decision and shall not send C rior. 3147 Types of FAULT possible (sent to “reply-address”): 3148

identified inferiors on the CONFImessages, if one is sent to the inferior.

ONFIRM decisio an Inferior whoidentifier-list is isent to that Infe

NOTE – If qualifiers are required to be sent on a PREPARE (or for Infeconmessages and their targeted-qualifiers-list parameter should be used.

ddress TRANS

r-address” on the B ge.

g the CONFIRM_

s-list” pa Inferiors identified shall be the “ConfirmBusiness Transaction is a Cohesion,

ll remainin iness Transaction is an Atom, the “Conf

are not counted in the Confirm-set. PREPARE has not been se

n received, PREPARE shall be issued to that Inferior.

OTE -- If PREPARE has been sent but PREPARE in the Confirm-REPARE. The

n implemenplementa

re indica lier PREPARE was not d

cision may if PREPARED has been received from allion shall

not made). sent to it, C

one remaining Inferior in the “Confirm seE_PHASE may be sent to it. e Confirm set shall be cancelled.

ort-hazardll be sent to dress”. cision is made all be sent to the

rt-hazard” was “false”, a TRANSACTION_Cdress”.

e", TRANSAMED has been each and a

N_CONFIRMED shall be sent to the "reply-afrom each Inferior in the Confirm-set and CANt in the Confirm-set.

r contradictory message wa from an Infe nfirm-set or CONFIRMED from an Inferior no

S reporting the stats”.

s in the "inferior-list" is unknown (does not cnferior shall be returned. The Decider shall nONFIRM to any Infe

ferior), a FA


General 3149 InvalidDecid3150

if Decider address is unknown 3151

Redirect 3152 if the Decider now has a differ3153

UnknownTra3154 if the transaction-identifier is u3155

InvalidInferio3156 if one or more “inferior -identifi3157

WrongState 3158 if a CANCEL_TRANSACTION has already been received . 3159

_TRANSACTION/all refers to a CONFIRM_TRANSACTION message where 3160 3161

CONFIR3162

ION_CONFIRMED 3163

3164 CONFIR3165 Inferiors zards, or if the Decider made a Confirm decision and the 3166

3167

List of qualifiers

er

ent “decider-address”

nsaction nknown

r ers” in the inferiors-list is unknown

The form CONFIRMthe “inferiors-list” parameter is absent. The form CONFIRM_TRANSACTION/specific refers to a

M_TRANSACTION message where the “inferiors-list” parameter is present.

5.8.5 TRANSACTA Decider sends TRANSACTION_CONFIRMED to a Terminator in reply to

M_TRANSACTION if all of the Confirm-set confirms (and, for a Cohesion, all other Cancel) without reporting ha

CONFIRM_TRANSACTION had a “report-hazards” value of “false”.

Parameter Type

transaction-identifier identifier

qualifiers


transaction-identifier the “transaction-identifier” as on the BEGUN message (i.e. the identifier of the Decider aa whole).

qualifiers standardised or other qual

3168 s 3169

3170

3171 ifiers. 3172

3173 FIRMED is sent., this will be the “reply-3174

3175

3176

3177

Type

target-address the address to which the TRANSACTION_CONaddress” from the CONFIRM_TRANSACTION message

5.8.6 CANCEL_TRANSACTION Sent by a Terminator to a Decider at any time before CONFIRM_TRANSACTION has been sent.

Parameter


report-hazard Boolean


targetted-qualifiers-list List of Targetted-qualifiers-items (see below)


Parameter Type



transaction-identifier 3178 essage. 3179

repor3180 3181

rue”, the 3182 ponses (CONFIRMED, CANCELLED or HAZARD) have been 3183

are reported. If “report-3184 N_CANCELLED immediately. 3185

3186 3187

3188 3189

each of those inferior if it is 3190 3191

inferior-identifier-list A list of one or more Inferior-

s item refers to.

in the inferior-identifier-list, the qualifiers are 3192 3193

alifiers 3194 3195

3196 3197 3198

3199 3200

opagated to any remaining Inferiors by issuing 3201 3202 3203 3204 3205 3206

ress" 3207 Inferior. 3208

Types of FAULT possible (sent to “reply-address”): 3209

identifies the Decider and will be the transaction-identifier from the BEGUN m

t-hazard Defines whether the Terminator wishes to be informed of hazard events and contradictory decisions within the Business Transaction. If “report-hazard” is “treceiver will wait until resreceived from all of its inferiors, ensuring that any hazard events hazard” is “false”, the Decider will reply with TRANSACTIO


targetted-qualifiers-list: contains a number of Targetted-qualifiers-items identifying one or more Inferiors and containing one or more qualifiers that are to be sent to confirmed. The fields of an Targetted-qualifers-item are:

Field Type

identifiers (each of which shall be one of those in the inferiors-list parameter), identifying which inferiorthis

qualifiers A list of qualifiers to be sent to the identified inferiors on the CANCEL messages.

For each Inferior whose inferior-identifier is included in the CANCEL message sent to that Inferior.

NOTE – If an Inferior has spontaneously cancelled, prepared or resigned, the quwill not be sent.

target-address the address to which the CANCEL_TRANSACTION message is sent. This will be the decider-address from the BEGUN message.

reply-address the address of the Terminator sending the CANCEL_TRANSACTION message.

The Business Transaction is cancelled – this is prCANCEL to them. No more Inferiors will be permitted to enrol. If "report-hazard" was "false", a TRANSACTION_CANCELLED message shall be sent to the "reply-address". If "report-hazard" was "true" and any HAZARD or CONFIRMED message was received, an INFERIOR_STATUSES reporting the status for all Inferiors shall be sent to the "reply-address". If "report-hazard" was "true", TRANSACTION_CANCELLED shall be sent to the "reply-addafter CANCELLED or RESIGN has been received from each


General InvalidDecider

3210 3211 3212

3213 3214

3215 3216

3217 Composer. 3218

3219

3220 3221

if Decider address is unknown

Redirect if the Decider now has a different “decider-address”


WrongState if a CONFIRM_TRANSACTION has been received by this

5.8.7 CANCEL_INFERIORS Sent by a Terminator to a Decider, but only if is a Cohesion Composer, at any time before CONFIRM_TRANSACTION or CANCEL_TRANSACTION has been sent.

Parameter Type






3222 3223

3224 cider are to be cancelled, using the “inferior-3225

3226

3227 s. 3228

3229 3230 3231

3232 3233

D or 3234 RESIGN ived, the Decider shall issue CANCEL. It will reply to the Terminator, 3235

3236 ied on the inferiors-list 3237

3238 3239 3240

INFERIORS for all of the currently enrolled Inferiors will leave 3241 nrol. 3242

transaction-identifier identifies the Decider and will be the transaction-identifier from the BEGUN message.

inferiors-list defines which of the Inferiors of this Deidentifiers” as on the ENROL received by the Decider (in its Role as Superior).

qualifiers standardised or other qualifier

target-address the address to which the CANCEL_TRANSACTION message is sent. This will be the decider-address from the BEGUN message.

reply-address the address of the Terminator sending the CANCEL_TRANSACTION message.

For all Inferiors identified in the inferiors-list parameter, from which neither CANCELLEED has been rece

using the "reply-address" on the CANCEL_INFERIORS message, sending an INFERIOR_STATUSES message giving the status of the Inferiors identifparameter. Only the Inferiors identified in the inferiors-list are to be cancelled. Any other inferiors are unaffected by a CANCEL_INFERIORS. Further Inferiors may be enrolled.

Note – A CANCEL_the Cohesion ‘empty’, but permitted to continue with new Inferiors, if any e


If one or more of the "inferior-identifier"s in the "inferior-list" is unknown (does not correspond to 3243 3244

3245 3246 3247 3248 3249

3250 rent “decider-address” 3251

3252 3253

3254 or more inferior-identifiers on the inferiors-list is unknown 3255

3256 3257 3258

3259

ELLED to a Terminator in reply to 3260 3261 3262

3263 3264

ist of qualifiers

an enrolled Inferior), a FAULT/Invalid-inferior shall be returned. It is an implementation option whether CANCEL is sent to any of the Inferiors that are validly identified in the "inferiors-list". Types of FAULT possible (sent to “reply-address”): General InvalidDecider

if Decider address is unknown

Redirect if the Decider now has a diffe


InvalidInferior if one

WrongState if a CONFIRM_TRANSACTION or CANCEL_TRANSACTION has been received by this Composer.

5.8.8 TRANSACTION_CANCELLED A Decider sends TRANSACTION_CANCCANCEL_TRANSACTION or in reply to CONFIRM_TRANSACTION if the Decider decided to Cancel. In both cases, TRANSACTION_CANCELLED is used only if all Inferiors cancelled without reporting hazards or the CANCEL_TRANSACTION or CONFIRM_TRANSACTION had a“report-hazard” value of “false.

Parameter

transaction-identifier identifier

qualifiers L


transaction-i3265 the “transaction-identifier” as on the BEGUN message (i.e. the identifier of the Decider as 3266

hole). 3267

qualifie3268 3269

target-address 3270 TRANSACTION_CANCELLED is sent. This will be the “reply-3271

3272

3273

3274 ent to any Actor with a “superior-address” or “inferior-address”, asking it 3275

3276 3277 3278

dentifier

a w

rs standardised or other qualifiers.

the address to which theaddress” from the CANCEL_TRANSACTION or CONFIRM_TRANSACTION message.

5.8.9 REQUEST_INFERIOR_STATUSES Sent to a Decider to ask it to report the status of its Inferiors with an INFERIOR_STATUSES message. It can also be sabout the status of that Transaction Tree Nodes Inferiors, if there are any. In this latter case, thereceiver may reject the request with a FAULT(StatusRefused). If it is prepared to reply, but has no Inferiors, it replies with an INFERIOR_STATUSES with an empty “status-list” parameter.


Parameter Type

target-identifier Identifier





target-identifier identif

3279 ies the transaction (or Transaction Tree Node). When the message is used to a 3280

ill 3281 3282 3283

3284 arget are to be included in the 3285

INFE ES, using the “inferior-identifiers” as on the ENROL received by the 3286 Decider (in its Role as Superior). If the list is absent, the status of all enrolled Inferiors will 3287 be re3288


dress 3291 3292 3293

message. 3294

3295 3296

Types o sent to reply-address): 3297 3298 3299 3300

3301 3302 3303 3304

3305 if the transaction-identifier is unknown 3306

ST_STATUS with the 3307 RIOR_STATUS/specific refers to a 3308

REQUEST_INFERIO the inferio st present. 3309

5.8.10 INFERIOR_STATUSES 3310

ent by a Decider to report the status of all or some of its inferiors in response to a 3311 R_STATUSES, PREPARE_INFERIORS, CANCEL_INFERIORS, 3312

3313 with “re3314 REQUE e any. 3315

Decider, this will be the transaction-identifier from the BEGUN message. Otherwise it wbe the superior-identifier from a CONTEXT or an inferior-identifier from an ENROL message.

inferiors-list defines which inferiors enrolled with the t

RIOR_STATUS

ported.

target-adthe address to which the REQUEST_ STATUS message is sent. When used to a Decider, this will be the “decider-address” from the BEGUN message. Otherwise it may be a “superior-address” from a CONTEXT or “inferior-address” from an ENROL

reply-address the address to which the replying INFERIOR_STATUSES is to be sent

f FAULT possible (General Redirect

if the intended target now has a different address

StatusRefused if the receiver is not prepared to report its status to the sender of this message. This “fault-type” shall not be issued when a Decider receives REQUEST_STATUSES from the Terminator.

UnknownTransaction

The form REQUEST_INFERIOR_STATUSES/all refers to a REQUEinferiors-list absent. The form REQUEST_INFE

R_STATUS with rs-li

SREQUEST_INFERIOCANCEL_TRANSACTION with “report-hazard” value of “true” and CONFIRM_TRANSACTION

port-hazard” value of “true”. It is also used by any Actor in response to a received ST_INFERIOR_STATUSES to report the status of inferiors, if there ar


Parameter Type

responders-identifier Identifier

status-list Set of Status items - see below

general-qualifiers List of qualifiers


3316 identifier used on the REQUEST_INFERIOR_STATUSES. 3317

3318 of the 3319

3320

se ubset of those for STATUS)

ist of qualifiers as received from the r inferior or associated with

rior in earlier messages (e.g. rior name qualifier).

The status value reports the current status of the particular inferior, as known to the 3321 mposer or Coordinator). Values are: 3322

r is enrolled

has been received from the

been sent

cancelled then CANCELLED has been received but no nt

M has been sent, no outcome reply has been received

ed CONF has been received

cancelling CANCEL has been sent, no outcome reply has been received

responders-identifier the target-

status-list contains a number of Status-items, each reporting the status of one of the inferiorsDecider. The fields of a Status-item are

Field Type

inferior-identifier Inferior-identifier, identifying which inferior this Status-item contains information for.

status One of the status values below (theare a s

qualifiers A lparticulathe infean Infe

Decider (Co

status value Meaning

active The Inferio

resigned RESIGNEDInferior

preparing PREPARE has been sent to the inferior, none of PREPARED, RESIGNED, CANCELLED, HAZARD have been received

prepared PREPARED has been received

autonomously confirmed

CONFIRMED/auto has been received, no completion message has

autonomously PREPARED had been received, and since

completion message has been se

confirming CONFIR

confirm IRMED/response


status value Meaning

cancelled CANCELLED has been received, and PREPARED was not received previously

cancel-contradiction Confirm had been ordered (and may have been sent), but CANCELLED was received

confirm-contradiction Cancel had been ordered (and may have

TATUSES/specific)

3323 general-qual3324

stand r qualifiers applying the INFERIOR_STATUSES as a whole. Each 3325 Statu alifiers” fiel ing qualifiers applying to (and received 3326 from) the particular Inferior. 3327

3328 ss” 3329

3330

If the in r was present on the received message, only the inferiors identified by 3331 that parameter shall have their status reported in status-list of this message. If the inferiors-list 3332 parameter was absent, the status of all enrolled inferiors shall be reported, except that an inferior 3333 that had been reported as cancelled or resigned on a previous INFERIOR_STATUSES message 3334 may be omitted (sender’s option). 3335

5.9 Groups – combinations of related messages 3336

The following combinations of messages form related groups, for which the meaning of the group 3337 is not just the aggregate of the meanings of the messages. The “&” notation is used to indicate 3338 relatedness. Messages appearing in parentheses in the names of groups in this section indicate 3339 messages that may or may not be present. The notation A & B / & C in a group name in this 3340 section indicates a group that contains A and B, or A and C, or A, B and C, possibly with any of 3341 those appearing more than once. 3342

5.9.1 CONTEXT & Application Message 3343

Meaning: the transmission of the Application Message is deemed to be part of the Business 3344 Transaction identified by the CONTEXT. The exact effect of this for application work implied by 3345 the transmission of the message is determined by the application – in many cases, it will mean 3346 the effects of the Application Message are to be subject to the outcome delivered to an enrolled 3347 Inferior, thus requiring the enrolment of a new Inferior if no appropriate Inferior is enrolled or if the 3348 CONTEXT is for cohesion. 3349 target-address: the “target-address” is that of the Application Message. It is not required that the 3350 application address be a BTP Address (in particular, there is no BTP-defined “additional 3351 information” field – the Application Protocol (and its binding) may or may not have a similar 3352 construct). 3353 There may be multiple Application Messages related to a single CONTEXT message. All the 3354 Application Messages so related are deemed to be part of the Business Transaction identified by 3355 the CONTEXT. This specification does not imply any further relatedness among the Application 3356 Messages themselves (though the application might). 3357

been sent) but CONFIRM/auto was received

hazard A HAZARD message has been received

invalid No such inferior is enrolled (used only in reply to a REQUEST_INFERIOR_S

ifiers ardised or othe to s-item contains a “qu d contain

target-address the address to which the INFERIOR_STATUSES is sent. This will be the “reply-addreon the received message

feriors-list paramete


The Actor that sends the group shall retain knowledge of the Superior address in the CONTEXT. 3358 If the CONTEXT is a CONTEXT/atom, the Actor shall also keep track of transmitted CONTEXTs 3359

has been received. 3360 /atom, the Actor receiving the CONTEXT shall ensure that a 3361

3362 3363

3364 3365 3366

ent on the same connection) – some kind of referencing 3367 3368

3369

essage contains an inferior 3370 3371 he 3372

3373 3374 3375

at the 3376 3377 3378 3379

Note – The representation of the relation between CONTEXT_REPLY and one or 3380 ages depends on the binding to the Carrier Protocol 3381

3382

3383 3384 3385 3386 3387 3388 3389 3390 3391 3392 3393 3394

ED 3395 3396

LED is not received), and the “completion-status” of the 3397 d”, the Actor is required to ensure that the Superior does not 3398

nt 3399 3400 3401 3402 3403 3404

for which no CONTEXT_REPLYIf the CONTEXT is a CONTEXTCONTEXT_REPLY message is sent back to the “reply-address” of the CONTEXT with the appropriate completion status.

Note – The representation of the relation between CONTEXT and one or more Application Messages depends on the binding to the Carrier Protocol. It is not necessary that the CONTEXT and Application Messages be closely associated “on the wire” (or even smechanism may be used.

5.9.2 CONTEXT_REPLY & Application Message Meaning: This related group applies only if the CONTEXT_REPLY midentifier parameter. In this case the transmission of the Application Message (and applicationeffects implied by its transmission) has been associated with the Inferior whose identifier is in tCONTEXT_REPLY and the effects will be subject to the outcome delivered to that Inferior. As for CONTEXT & Application message, the exact effect of this for application work implied by the transmission of the message is determined by the application. target-address: the “target-address” is that of the Application Message. It is not required thapplication address be a BTP Address (in particular, there is no BTP-defined “additional information” field – the Application Protocol (and its binding) may or may not have a similar construct).

more Application Mess

5.9.3 CONTEXT_REPLY & ENROL Meaning: the enrolment of the Inferior identified in the ENROL is to be performed with the Superior identified in the CONTEXT message this CONTEXT_REPLY is replying to. If the “completion-status” of CONTEXT_REPLY is “related”, failure of this enrolment shall prevent the confirmation of the Business Transaction. target-address: the “target-address” is that of the CONTEXT_REPLY. This will be the “reply-address” of the CONTEXT message (in many cases, including request/reply application exchanges, this address will usually be implicit). The “target-address” of the ENROL message is omitted. The Actor receiving the related group will use the retained Superior address from the CONTEXT sent earlier to forward the ENROL. When doing so, it changes the ENROL to ask for a response (if it was an ENROL/no-rsp-req) and supplies its own address as the “reply-address”, remembering the original “reply-address” if there was one. If ENROLLED is received and the original received ENROL was ENROL/rsp-req, the ENROLLis forwarded back to the original “reply-address”. If this attempt fails (i.e. ENROLCONTEXT_REPLY was “relateproceed to confirmation. How this is achieved is an implementation option, but must take accouof the possibility that direct communication with the Superior may fail. (One method is to prevent CONFIRM_TRANSACTION being sent to the Superior (in its Role as Decider); another is to enrol as another Inferior before sending the original CONTEXT out with an Application Message). If the Superior is a sub-coordinator or sub-composer, an enrolment failure must ensure the sub-coordinator does not send PREPARED to its own Superior.


If the Actor receiving the related group is also the Superior (i.e. it has the same binding address), the expli

3405 cit forwarding of the ENROL is not required, but the resultant effect – that if enrolment 3406

3407 3408

rior 3409 3410 3411 3412 3413

g the group shall forward the ENROLs, 3414 3415

3416

racterised by a related CONTEXT_REPLY and either or both of 3417 PREPARED and CANCELLED, with or without ENROL. 3418

required processing is the same as for 3419 3420 3421

3422 3423

3424 3425 3426 3427 3428

3429 t 3430

3431 ELLED message are for the same Inferior, 3432

the ENROL shall be sent first, but the Actor need not wait for the ENROLLED to come back 3433 from this 3434

3435 The g ltiple ENROL, PREPARED and CANCELLED messages. Each 3436

3437 3438

er message 3439 3440

lication Message (& 3441 3442

This3443 Mes elated group. 3444

P messages is as for the preceding groups. The 3445 3446 3447 3448

f the 3449 3450 3451

fails the Superior does not Confirm or issue PREPARED – shall be the same. A CONTEXT_REPLY & ENROL group may contain multiple ENROL messages, for several Inferiors. Each ENROL shall be forwarded and an ENROLLED reply received before the Supeis allowed to Confirm if the “completion-status” in the CONTEXT_REPLY was “related”. When the group is constructed, if the CONTEXT had “superior-type” value of “atom”, the “completion-status” of the CONTEXT_REPLY shall be “related”. If the “superior-type” was “cohesive”, the “completion-status” shall be “incomplete” or “related” (as required by the application). If the value is “incomplete”, the Actor receivinbut is not required to prevent confirmation (though it may do so).

5.9.4 CONTEXT_REPLY (& ENROL) & PREPARED / & CANCELLED This combination is cha

Meaning: If ENROL is present, the meaning andCONTEXT_REPLY & ENROL. The PREPARED or CANCELLED message(s) are forwarded to the Superior identified in the CONTEXT message this CONTEXT_REPLY is replying to.

Note – the combination of CONTEXT_REPLY & ENROL & CANCELLED may be used to force cancellation of an atom

target-address: the “target-address” is that of the CONTEXT_REPLY. This will be the “reply-address” of the CONTEXT message (in many cases, including request/reply application exchanges, this address will usually be implicit). The “target-address” of the PREPARED and CANCELLED message is omitted – they will be sent to the Superior identified in the earlier CONTEXT message. The Actor receiving the group forwards the PREPARED or CANCLLED message to the Superiorin as for an ENROL, using the retained Superior address from the CONTEXT sent earlier, excepthere is no reply required from the Superior. If (as is usual) an ENROL and PREPARED or CANC

before sending the PREPARED or CANCELLED (so an ENROL+PREPARED bundleActor to the Superior could be used).

roup can contain muPREPARED and CANCELLED message will be for a different Inferior. There is no constraint on the order of their forwarding, except that ENROL and PREPARED or CANCELLED for the same Inferior shall be delivered to the Superior in the order ENROL first, followed by the othfor that Inferior.

5.9.5 CONTEXT_REPLY & ENROL & AppPREPARED)

combination is characterised by a related CONTEXT_REPLY, ENROL and an Application sage. PREPARED may or may not be present in the r

Meaning: the relation between the BTtransmission of the Application Message (and application effects implied by its transmission) has been associated with the Inferior identified by the ENROL and will be subject to the outcome delivered to that Inferior. target-address: the “target-address” of the group is the “target-address” oCONTEXT_REPLY which shall also be the “target-address” of the Application Message. The ENROL and PREPARED messages do not contain their “target-address” parameters.


The processing of ENROL and PREPARED messages is the same as for the previous groups. This group can be used when participation in Business Transaction (normally a co

3452 hesion), is 3453

res the CONTEXT, with some 3454 rk for the transaction and sends an 3455

3456 3457

with 3458 . 3459

3460

3461

3462 3463 3464 3465

3466

ess 3467 3468

e appropriate to initiate cancellation if the active phase appears to 3469 3470

3471 he 3472

3473 3474 3475 3476 3477 3478

3479 3480

e of 3481 3482 3483

5.10.2 Inferior tim3484

Th ws an Inferior to limit th of its “promise”, when sending PREPARED, 3485 th onfirm3486 W xpe . 3487 If r is3488 ind3489 It s 3490 Confirm or Cancel de CO3491 ex t used). S3492 wi is c c 3493 de us is 3494

initiated by the service (Inferior) side, which fetches or acquiassociated application semantic, performs some woApplication Message with a related ENROL. The CONTEXT_REPLY allows the addressing of the application (and the CONTEXT_REPLY) to be distinct from that of the Superior. The Actor receiving the group may associate the “inferior-identifier” received on the ENROLthe Application Message in a manner that is visible to the application receiving the message (e.gfor subsequent use in Terminator:Decider exchanges).

5.10 Standard qualifiers The following qualifiers are expected to be of general use to many applications and environments. The URI “http://docs.oasis-open.org/business-transaction/business_transaction-btp-1.1-qualifiers-schema-wd-05.xsd” is used in the Qualifier group value for the qualifiers defined here.

5.10.1 Transaction timelimit The transaction timelimit allows the Superior (or an Application Element initiating the BusinTransaction) to indicate the expected length of the active phase, and thus give an indication to the Inferior of when it would bcontinue too long. The time limit ends (the clock stops) when the Inferior decides to be preparedand issues PREPARED to the Superior. It should be noted that the expiry of the time limit does not change the permissible actions of tInferior. At any time prior to deciding to be prepared (for an Inferior), the Inferior is permitted to initiate cancellation for internal reasons. The timelimit gives an indication to the entity of when it will be useful to exercise this right. The qualifier is propagated on a CONTEXT message. The “Qualifier name” shall be “transaction-timelimit”. The “Content” shall contain the following field:

Content field Type

timelimit Integer

timelimit

indicates the maximum (further) duration, expressed as whole seconds from the timtransmission of the containing CONTEXT, of the active phase of the Business Transaction.

eout is qualifier allo e duration

at it will maintain the ability to C or Cancel the effects of all associated operations. ithout this qualifier, an Inferior is ethe timeout does expire, the Inferio

cted to retain the ability to Confirm or Cancel indefinitely released from its promise and can apply the decision

icated in the qualifier. should be noted that BTP recognise

cision before the the possibility that an Inferior may be forced to apply a

NFIRM or CANCEL is received and before this timeout pires (or if this qualifier is no uch a decision is termed a heuristic decision, and (as th other transaction mechanisms), cisions, the taking of an autonomo

onsidered to be an exceptional event. As with heuristi decision by an Inferior subsequent to the expiry of th


timeout is liable to cause contradictory decisions across the Business Transaction. BTP ensures 3495 that at least the occurrence of such a contradiction will be (eventually) reported to the Superior of 3496 th s “t er 3497 timeout the same way – in fact, the expiry in this timeout does not cause a qualitative (state table) 3498 ch an happen, but rather 3499 The expiry of the timeout does not strictly require that the Inferior immediately invokes the 3500 intende t it is at liberty to tation may choose to only apply 3501 th ention for the r example. Nevertheless, 3502 Su oid re ss 3503 Tran3504 latency etc.). 3505 Th a PREP 3506 “default-is cancel” parameter “true”, the of this qualifier shall have 3507 th3508 The “Qualifier name” shall be “inferio3509 The “Content” shall contain the followin3510

timeout Integer

nded-decision

3511 meout 3512

indicates how long, e e of transmission of the 3513 message, the Inferior maintain its ability to either Confirm or Cancel 3514

ciated operation as ordered by the receiving Superior. 3515

intende3516 come will be applied, if the timeout completes and an autonomous 3517

3518

5.10.3 Minimum inferior time3519

This qualifier allows a Superior to constrain the ifier received from the Inferior. 3520 If ion for e be determined for 3521 some period, it can require that Inferiors 3522 timeouts that would expire before then. A I3523 PREPARED message with a longer (or no) timeout th CANCELLED. 3524 Th ONT X 3525 more than one, and with different values of the MinimumTimeout field, the value on ENROLLED 3526 shall prevail over that on CONTEXT and e r of the 3527 others. 3528 Th imum3529 The “Content” shall contain the following fie3530

Content field

3531 minimum-timeout 3532

meout x ble in 3533 er on an a3534

e Business Transaction. BTP treat rue” heuristic decisions and autonomous decisions aft

ange in what c a step change in the probability that it will.

d decision, only thae decision if there is cont

do so. An implemen underlying resource, fo

periors are recommended to avsaction are made before these time

lying on this and ensure that decisions for the Busineouts expire (and allow a margin of error for network

e qualifier may be present on ARED message. If the PREPARED message has then the “IntendedDecision” field

e value “cancel”. r-timeout”.

g fields:

Content field Type

inte “confirm” or “cancel”

tixpressed as whole seconds from the tim

carrying the effects of the asso

intends to s,

d-decision indicates which outdecision is made.

out Inferior timeout qual

a Superior knows that the decis th Business Transaction will not do not send PREPARED messages with Inferior n nferior that is unable or unwilling to send a

should Cancel, and reply wie qualifier may be present on a C E T, ENROLLED or PREPARE message. If present on

th value on PREPARE shall prevail over eithe

e “Qualifier name” shall be “min -inferior-timeout”.

ld:

Type

minimum-timeout Integer

is the minimum value of tithe Inferior timeout qualifi

, e pressed as whole seconds, that will be acceptanswering PREPARED message.


5.10.4 Inferior name 3535

Th s an Enroller to suppl 3536 INFERIOR_STATUSES and thus allow th T3537 Composer or Coordinator) is related to which inferior-3538 identifier” field. The name can be human-read le3539 debugging and auditing. 3540 The name is never used by the BTP Actors the3541 messages. (The BTP Actors use the ad3542 th3543 This specification makes no requirement that n ope 3544 (unlike the globally unambiguous “inferior-ide fie3545 specifications, including those defining use of TP3546 requirements on the use and form of the nam . (3547 passed in Application Messages or in other, non-s3548 The qualifier may be present on BEGIN in the “qualifiers” field of a Status-item in 3549 INFERIOR_STATUSES. It is present on BEG o3550 the same qualifier value should be included in the3551 INFERIOR_STATUSES includes a Status-item for ose ENROL had an inferior-3552 name qualifier, the same qualifier value shou be3553 The “Qualifier -name” shall be “inferior-name”3554

he “Content” shall contain the following fields: 3555

Content field

rior-name String

3556 inferior-name 3557

the name assigned to the enroll I3558

5.10.5 Cancel-on-zero-participa3559

The cancel-on-zero-participants qualifie au 3560 cancelled if its list of registered participants IORS 3561 or RS message is re iv l-3562 on-zero-participants is set to true, and the re _CANCELLED 3563 message returned to the terminator as a3564 CANCEL_INFERIORS message, instea f3565 The qualifie sent on BEGIN if the “transaction-type” is “cohesion” and on 3566 PREPARE_INFERIORS and CANCEL I f present on PREPARE_INFERIORS or 3567 CANCEL_INFERIORS the value overrides an3568 If the qualifier is not present on any message, a co value 3569 was “false”. 3570 The “Qualifier -name” shall be “cancel-on- r3571 The “Content” shall contain the following field3572

Content field Typ

value “true

is qualifier allow y a name for the Inferior that will be visible on e in erm ator to determine which Inferior (of the

application work. This is in addition to the “ and can also be used in fault tracing, ab

mselves to identify each other or to direct dresses and the identifiers in the message parameters for

ose purposes.) the ames are unambiguous within any scnti r” on ENROLLED and BEGUN). Other

with a particular application may plac B e es This may include reference to information

tandardised, qualifiers.) , ENROL and

IN nly if there is a related CONTEXT; if present, consequent ENROL. If an Inferior wh

ld included in the Status-item.

T

Type

infe

ing nferior.

nts r c ses a cohesion composer to be automatically

becomes zero after either a PREPARE_INFERCANCEL_INFERIO ce ed. This cancellation happens if the value for cance

sult will be a TRANSACTION reply to the PREPARE_INFERIORS or d o INFERIOR_STATUSES.

r may be preNFERIORS. I

y previous value. hesion composer shall behave as if the

ze o-participants”

:

e

” or “false”


5.10.6 Expected-time-till-state-change 3573

Th ll-state-change qua r ication of 3574 when the sender anticipates it will under a3575 For example, an Inferior receiving PREP3576 to complete could send INFERIOR_STATE xpected-time-to-state-3577 change of 4000 seconds (giving itself so e 3578 information to modify its polling and retry alg3579 Va indicatio tate 3580 change in either party. Sending does not re arlier, 3581 nor inhibit the sending of any message reflecting ge; neither does it commit the 3582 se at the time sta . d 3583 by BTP are not affected. 3584

he “Qualifier -name” shall be “expected-time-till-state-change” 3585 The “Content” shall contain the following field: 3586

Type

3587 3588

3589 3590 3591

e excepted-time-ti lifie can be sent on any message to give an indgo state change that would trigger a further message. ARE that triggers application work that will take an hour

/prepare-received with an em margin for error). The Superior could use this

orithm. lues sent on this qualifier are ns only. Sending this qualifier never causes a s

p vent the sender from changing state much esuch a chan

nder to changing state ted The persistence and recovery requirements implie

T

Content field

expected-time Integer

expected-time

is a time expressed as whole seconds, within which the sender anticipates that it willundergo a state change triggered by events other than the receipt of messages on this BTP relationship.


6 State ables T3592

The state tables deal with the state transitions of the Superior and Inferior roles and which 3593 message can nt in each state. The state tables directly cover only a single, bi-3594 lateral Superio erio eractions between, for example, multiple Inferiors of a 3595 single Superior that will apply t of them, are dealt with in the 3596 definitions of the “dec anges are made to persistent state 3597 information (see below3598 There are two ta erior, one for Inferior. States are identified by a letter-digit 3599 pair, with uppe se erior, lower-case for the inferior. The same letter is used to 3600 group states w ha , persistent state, with the digit indicating volatile 3601 state changes or mino er and lower-case letters are used to 3602 identify (appro tel Inferior states. 3603 The Inferior table inclu rring both at the Inferior as such and at the associated 3604 Enroller, as the Enroll ed by and constrain the Inferior Role itself. 3605 In the state tables, each ting to make a decision or can send a message. For 3606 some states, t es a repetition of a regular message; for other states, the 3607 INFERIOR_ST or TATE message can be sent, requesting a response. 3608 Normally, on entry to a state that allows the sending of any message other than one of the 3609 *_STATE messages, at message – failure to do so will cause the 3610 relationship to up an be resent if the implementation determines that the 3611 original message (or t e sent in reply) may have been lost. 3612

6.1 Status e3613

In BTP the messages R_STATE are available to prompt the 3614 Peer to report its current st ssage (when this is allowed) or by 3615 sending the ot _S sted” parameter of these messages 3616 distinguishes between ompt and as a reply. An implementation receiving a 3617 *_STATE message w ed” as “true” is not required to reply immediately – it may 3618 choose to dela y r urs and then send the appropriate new 3619 message (e.g. ece ile in state E1, a superior is 3620 permitted to d unt “decide to cancel”). However, this 3621 may cause the other s TATE messages. 3622 Note that a Su r ( -extinct Superior) uses 3623 SUPERIOR_S E/u ed from an Inferior where the 3624 Superior:Inferior relati te “Y1”). The *_STATE messages with a 3625 “state” value “inacces received and the 3626 implementatio em ip is known or what the 3627 state is. Recei the sages is not shown in the tables and has no 3628 effect on the state at the re cause the implementation to resend its 3629 own message r so n choosing). 3630

3631

The persistent state changes (equivalent to logging in a regular transaction system) and some 3632 other events are modelled as “decision events” (e.g. “decide to confirm”, “decide to be prepared”). 3633 The exact nature of the real events and changes in an implementation that are modelled by these 3634 events depends on the position of the Superior or Inferior within the Business Transaction and on 3635 features of the implementation (e.g. making of a persistent record of the decision means that the 3636 information will survive at least some failures that otherwise lose state information, but the level of 3637

be se and receivedr:Inf r relationship. The int

he same decision to all or someision” events which also specify when ch).

stater-ca

bles, one for Supletters for the sup

hich ve the same, or similarr variations. Corresponding upp

y) corresponding Superior andximades events occu

er’s actions are constrainside is either wai

sage to be sent ishe mATE SUPERIOR_S

the implementation will send th lock . The message c

he next messag

qu ries SUPERIOR_STATE and INFERIO

ate by repeating the previous meher * TATE message. The “reply_reque

their use as a prith “reply_request

y an eply until a decision event occ on relay

iving INFERIOR_STATE/prepared/y whil it has performed “decide to confirm” oride to repeatedly send interrogatory *_S

perioTAT

or some entity standing in for a nownknown to reply to messages receivonship is in an unknown (using stasible” can be used as a reply when any message isporarily unable to determine whether the relationshn is t

pt of *_STATE/inaccessible mesceiving side (though it may

afte me interval of its ow

6.2 Decision events


survival depends on the purpose of 3 and Table 4 define the decision 3638 events. 3639 The Superior e t “d nsidered semi-persistent. Since the sending of 3640 PREPARE ind es t hange (to associate operations with the Inferior) is 3641 complete, it is me r the Superior:Inferior relationship to revert to an earlier state 3642 corresponding n in application exchange. However, implementations are not 3643 required to make the PREPARE persistent in terms of recovery – a Superior that 3644 experiences fa af PREPARE may, on recovery, have no information about the 3645 transaction, in h c nsidered to be in the completed state (Z), which will imply the 3646 cancellation of Inf associated operations. 3647 Where a Superior is a n Inferior to another Superior entity), in a 3648 Transaction Tr its “ nfirm” and “decide to cancel” decisions will in fact be the receipt 3649 of a CONFIRM or CA uperior, without necessary change of local 3650 persistent information nd inferior information, pointing both 3651 up and down t ee)3652

6.3 Disrup ns3653

Failure events are mo ilure and the subsequent recovery will (or may) 3654 cause a chang sta odel different extents of loss 3655 of state inform n. A the possible disruption 3656 events, but it is t all not correspond to a possible 3657 disruption. The ere endpoint to be in 3658 after it has been resto of a destination state for the 3659 disruption events mea mple, an Inferior 3660 that has decid be e of the information 3661 persisted in the “decid nt. 3662 In addition to t isru s in the tables, there is an implicit “disruption 0” event, which 3663 involves possi nte es in transit, but no change of state 3664 (either becaus sta use recovery from persistent information 3665 restores the im en t would typically be an 3666 appropriate ab ctio3667

6.4 Invalid cells and assumptions of the communication 3668 mech ism3669

The empty cel sta or events corresponding to 3670 sending a message o – e.g. a conformant 3671 implementatio the r events 3672 corresponding ece perties of the 3673 underlying communic3674 For all commu tion3675 • the two dir ns or communication are not synchronised – that is 3676

messages elli any degree; any number 3677 of messag ay3678

• messages y be rily. 3679 If the communication livery (i.e. that messages, if delivered at 3680 all, are deliver th re sent), then receipt of a message in a state 3681

here the corresponding cell is empty indicates that the far-side has sent a message out of order 3682 essage with the “fault-type” “WrongState” can be returned. 3683

If the communication mechanisms cannot guarantee ordered delivery, then messages received 3684 where the corresponding cell is empty should be ignored. Assuming the far-side is conformant, 3685

the implementation). Table

venicat

ecide to prepare” is cohat the application exc

not aningful fo to a complete

sending of ilure whic

ter sendingase it is co

the erior and itsn Intermediate (i.e. is itself a

ee, decide to coNCEL instruction from its own S (which would combine both superior a

he tr .

tio – failure events delled as “disruption”. A fa

e ofatio

te. The disruption events in the state tables mn implementation is not required to exhibit all

no owed to exhibit state transitions that do diff nt levels of disruption describe legitimate states for the

red to normal functioning. The absence ns that such a transition is not legitimate – thus, for exa prepared will always recover to the same state, by virtued toe to be prepared” eve

he d ption eventble i rruption of service and loss of message no te information was lost, or becaplem tation to the same state). The “disruption 0” even

tion failure. stra n for a communica

an ls in te table represent events that cannot happen. F

r any of the decision events, this prohibition is absolute Superior active state “B1” will not send CONFIRM. Fon in

to r iving a message, the interpretation depends on the proations mechanism.

nica mechanisms, it is assumed that: ectio of the Superior:Inferi trav ng in opposite directions can cross each other to es m be in transit in either direction; and ma lost arbitra

mechanisms guarantee ordered deed to e receiver in the order they we

w– a FAULT m


these messages can assumed to be “stale” analready delivered. (If the far-side is n

d have been overtaken by messages sent later but 3686 on-conformant, there is a problem anyway). 3687

6.5 Meanin3688

T the events (rows) in th t l a d ines the events 3689 c g BTP messages he is nt Table 3 3690 d an Inferior, Table 4 th fo S i3691 T fined in Table 4 c it nce to 3692 o is Superior, and to its relation with the application or other entity that 3693 ( pplication) drives it.3694 T any Actors to w n in u rio d h 3695 a mic decision unit with (and thus incl in e rio3696 r XT for this Superior:Inferior a e r-t o3697 t same Superior r-i ntifier” except 3698 t ceived. If the CO a r-t e” oh3699 t s been d rm will be canc s 3700 a ludes only se r w h a onf d on stil3701 p of exactly which Inferiors are “remaining Inferiors3702 i y the applic on. The term “Other g 3703 I ship. A Superior with ing Inf or will have no 3704 “3705 I n decision is delivered to all ai I io es3706 f st persistently record which Inferiors e e he add sse nd 3707 identifiers). It must also either record that the decision is Confirm, or ensu th e nfir3708 d one) is persistently recorded somew re e e, and that it will be told about it. 3709 T rior were also BTP Inferior to another e ity w ich rsis3710 C r recursively deferred it still higher). H we , s e there is no requirement 3711 t e also a BTP Inferior to any other entity, the beh f as e ntit3712 t nfirm decision is termed "offering confirmation" - the Superior offers 3713 t nd its remaining Infe rs t o th ent . If that entity (o3714 s make and persist a Con m d is he up or is instr ted3715 t M). 3716 The appli half of the application, may request a Sup3717 t pically impl th the wil no ore per ons3718 a to prepare all rema ing feriors, the Superior 3719 m sted the prepare. (If the Superior is also a BTP 3720 I g o beh f of e a lica n.) 3721 T half o e a lic on, ay a o re est 3722 c erior is to attempt to make a pe ist a Con d ision sel3723 r3724

able 2 : send, receive and disruption 3725

Meaning

g of state table events he tables in this section define e sta e tab es. T ble 2 eforresponding to sending or receivin and t d ruption eve s. escribes the decision events for ose r a uper or. he decision events for a Superior, de annot be specified w hout referether Inferiors to which it acting ultimately on behalf of the a he term “remaining Inferiors” refers to hich this e dpo t S is pe r n, a w ichre to be treated as an ato

TEud g) th Infe r on this

elationship. If the CON relationship had “sup rio ype” f “atom”, his will be all Inferiors established with

re addre

Ess anX h

d “superio dehose from which RESIGN has been NT T d “superio yp of “c esion”, he “remaining Inferiors” excludes any that it ha ete ined elled, as well any that have resigned – in other words it inc tho fo hic C irm ecisi is l ossible or has been made. The determination ”

n a Cohesion is determined, in some way, b ati remaininnferiors” excludes this Inferior on this relation a s le eriother remaining Inferiors”. n order to ensure that the confirmatio rem ning nfer rs, d pite ailures, the Superior mu thes ar (i.e. t ir re s a

re at th Co m ecision (if there is he ls his latter would apply if the Supe nt h pe ted a onfirm decision (o o ver inc

hat the Superior b aviour o king anoth r e y o make (and persist) the Cohe possible confirmation of itself, a rio o s me o er ity r omething higher up) then does fir ec ion, t S eri " uc o confirm" (which is equivalent BTP CONFIR

cation, or an entity acting indirectly on bety

erior o prepare an Inferior (or all Inferiors). This ies at re l be m o ati ssociated with the Inferior. Following a request

uein In

ay offer confirmation to the entity that reqnferior, its superior can be considered an entity actin n al th pp tiohe application, or an entity acting indirectly on be f th pp ati m ls quonfirmation. This means the Sup nd rs firm ec it f, ather than offer confirmation.

T events

Event name

send/receive ENROL/rsp-req send/receive ENROL th o -re ested = true wi resp nse qu

send/receive ENROL/no-rsp-req send/receive ENROL with respo - sted = false nse reque

send/receive RESIGN/rsp-req send/receive RESIGN with spo -r ues d = re nse eq te true

send/receive RESIGN/no-rsp-req send/receive RESIGN with spo -r ues d = se re nse eq te fal

send/receive PREPARED send/receive PREPARED, with default-cancel = false

send/receive PREPARED/cancel send/receive PREPARED, with default-cancel = true


Event name Meaning

send/receive CONFIRME auto send/receive CON w o ived = true

D/ FIRMED, ith c nfirm-rece

send/receive CONFIRMED/response

send/receive CONF ME , with confirm ive = false

IR D -rece d

send/receive HAZARD send/receive HAZ ARD

send/receive INF_STATE/***/y send/receive INF R_STATE with status *** and response-request t

ERIOed = rue

send/receive INF_STATE/*** send/receive INF R_STATE with status *** anresponse-requeste

ERIOd = false

d

send/receive SUP_STATE/***/y send/receive SUPERIORse-requeste tru (“prepa ts

pared-received

_STATE with status *** and respon d = e red-rcvd” represen“pre ”)

send/receive SUP_STATE/*** send/receive SUPERIORnse-requeste fa (“p pa cv sents

epared-received”)

_STATE with status *** and respo d = lse re red-r d” repre“pr

disruption *** Loss of state– new ate sta p glocal recovery proc ses om te

st is te a plyin after any es c ple

3726 le 3 : Decision events for Inferior 3727

Meaning

Tab

Event name

decide to resign • Any associated operations have had no effect (data state is unchan d). ge

decide to be prepared • Effects of all associated operatio ca e nfirmed or ca elled;

information to retain confirm/can l abeen made per ten

ns n bco nc

• ce ility has b sis t

decide to be prepared/cancel • As “decide to be pre redrsistent information ecif

action will be to cancel

pa ”; • the pe sp ies that the default

decide to confirm autonomously • Decision to confirm autono ously has een made persistent;

• the effects of associated operations will be confirmed rega less of failures

m b

rd

decide to cancel autonomously • Decision to Cancel autono us as en de persistent

• the effects of associated operations will be cancelled rega ss of failures

mo ly h be ma

rdle

apply ordered confirmation • Effects of all associated operations have been confirmed;

• Persistent information is effectively removed

remove persistent information • Persistent information is effectively removed;


Event name Meaning

detect problem • For at least some of the asso ted operations, o EITHER they can t b onsistently

cancell or ns d; o OR it cannot be determined whether they will

be can lled r c firm• AND informat ut this is not persistent.

ciano e c

ed co istently confirme

ce o on ed; ion abo

detect and record problem • For at least some of the asso ted operations, o EITHER they can b onsistently

cancell s tently confirmed; o OR it cannot be determined whether they will

be can lled r c firmAND o EITHER information re rding this has been

persist (to the degre nsidered approp te)

o OR the detection itself is persistent. (i.e. will be re-detect on covery)

cianot e c

ed or con is

ce o on ed; •

coed e coria

ed re

3728 le 4: Decision events for a Superi3729

Meaning

Tab or

Event name

decide to confirm one-phase • All associate pp atio Me ages to be sent to the service h e b n sent; There are no the m ing Inferiors

• If an Atom, all enrolments that would create other Inferiors ha m te o outstanding CONTEXT_ LY ) The Superior as n uested to confirm

d A lic n ssav ee

• o r re ain

ve co ple d (nREP s

• h bee req

decide to prepare • All associate pp a ges to be sent to ervice h e b n

• The Superior as en uested to prepare this Inferior

d A lic tion Messathe s av ee sent;

h be req

decide to confirm • Either o PREPARED P D/cancel has

been r eiv from all other remaining Inferio AND

o Superi ed to confirm; AND

o persi a n r rds the confirm decision and identifies all remaining Inferiors;

• Or o persistent information records an offer of

confirmation and has been instructed to confirm

or REPAREec edrs;or has been request

stent inform tio eco


Event name Meaning

decide to cancel • Superior has rm n • Superior has offered nfir atio and s b

instructed to Ca cel; OR • Superior has offered nfir atio but s made

an autonomous canc latio dec n

not offered c fion atio ; R Oco m n ha een

nco m n hael n isio

remove confirm information • Persistent informatio as been effe yremoved;

n h ctivel

record contradiction • Information re i e r ion a npersisted (to the deg co ide d ap )

cord ng th cont adict h s bee ree ns re propriate

3730

63731

Persi ation at an Inferior, confirm information at a 3732 S te carried in Qualifiers of the correspondin3733 messag ation). It may also include application-specific 3734 i allow the future con i c ce n th3735 associated operations. In some cases it will also include information allowing an Application 3736 M BTP message (e.g. PREPARED) to be repeated. 3737 T nt information allows for po bility that the in rm n i3738 r r audit and tracing purposes) but some ange to the persistent informatio3739 ( s that if there is a failure after such chan , on cov n3740 i the endpoint to return the state ou have recovered to before t 3741 c3742 I ation described as “persis nt” w l su ve failure is a 3743 c implementatio ho d describe the level of failure 3744 t ions manipulating form tion at tse3745 n nt to make the BTP state information ore3746 p tion. 3747 T of a hazard (problem) t an Inferior and reco ng of a 3748 d from ap yi t rs ent epa d 3749 a uratio y o h ard d 3750 c agement mechanisms rath r th through BTP. Such passing of 3751 i could be treated “record p blem” or cor3752 c3753

.6 Persistent information sted information (especially prepared inform

uperior) may include qualifications of the sta g e (e.g. inferior timeouts in prepa

nformation (especially in Inferiors) to red inform

firmat on or an llatio of e

essage sent with ahe “effective” removal of persiste the ssi fo atio s etained (perhaps fo ch n as a whole) mean ge re ery, the persiste t nformation does not cause it w ld hehange. n all cases, the degree to which inform te il rvionfiguration and implementation option. An n s ulhat it is capable of surviving. For applicat in a th is i lf volatile (e.g. etwork configurations), there is no requireme m ersistent that than the application informahe degree of persistence of the recording a rdietected contradiction at a Superior may be different that pl ng to he pe ist pr rend confirm information. Implementations and config n ma ch ose to pass az anontradiction information via man e an

nformation to a management mechanism as ro “re d ontradiction”.


Table 5 : Superior states 3754

State summary

I1 CONTEXT created

A1 ENROLing

B1 ENROLLED (active)

B2 ENROLLED – repeat ENROL received

C1 resigning

D1 PREPARE sent

E1 PREPARED received

E2 PREPARED/cancel received

F1 CONFIRM sent

F2 completed after confirm

G1 Cancel decided

G2 CANCEL sent

G3 cancelling, RESIGN received

G4 both cancelled

H1 inferior autonomously confirmed

J1 Inferior autonomously cancelled

K1 confirmed, contradiction detected

L1 cancelled, contradiction detected

P1 hazard reported

P2 hazard reported in null state

P3 hazard reported after confirm decision

P4 hazard reported after Cancel decisi on

Q1 contradiction detected in null state

R1 Contradiction or hazard recorded

R2 completed after contradiction or haz recorded ard

S1 one-phase confirm decided

Y1 completed queried

Z completed and unknown

3755


Table 6 : Inferior states 3756

summary State i1 aware of CONTEXT a1 enrolli ngb1 enrolled c1 resigning d1 preparing e1 prepared e2 prepared,default to cancel f1 confirming f2 confirming after default cancel g1 CANCEL received in prepared state g2 CANCEL received in prepared/cance tal s te h1 Autonomously confirmed h2 autonomously confirmed, superior confirmed j1 autonomously cancelled j2 autonomously cancelled, superior ca ellenc d k1 autonomously cancelled, contradicted k2 autonomously cancelled, CONTRADICTION received l1 autonomously confirmed, contradicted l2 autonomously confirmed, CONTRADICTION received

m1 confirmation applied n1 cancelling n2 cancelling after receiving PREPARE p1 hazard detected, not recorded p2 hazard detected in prepared state, not recorded q1 hazard recorded s1 CONFIRM_ONE_PHASE received after prepared state s2 CONFIRM_ONE_PHASE received s3 CONFIRM_ONE_PHASE received, c firm g on ins4 CONFIRM_ONE_PHASE received, c cel g an lins5 CONFIRM_ONE_PHASE received, h ard etec d az d tes6 CONFIRM_ONE_PHASE received, hazard recorded x1 completed, presuming abort x2 completed, presuming abort after prepared/cancel y1 completed, queried y2 completed, default cancel, a message received y3 Completed after cancelled, a messag received e z completed z1 completed with default cancel z2 completed after cancellation

3757


6.7 Superior state table 3758

perior state table – active, resigning and prepared 3759 I1 1 1 2 1 D1 E1 E2

Table 7: Su A B B C

receive ENROL/rsp-req A1 2 2 D1 A1 B Breceive ENROL/no-rsp-req B1 1 1 D1 B Breceive RESIGN/rsp-req Y1 1 1 1 C1 C C Creceive RESIGN/no-rsp-req Z Z Z Z Zreceive PREPARED Y1 E1 1 E1 E1 Ereceive PREPARED/cancel Y1 E2 2 E2 E2 Ereceive CONFIRMED/auto Q1 H1 1 H1 H1 Hreceive CONFIRMED/response receive CANCELLED Y1 Z J1 J1 Z Z receive HAZARD P1 1 1 1 P1 P1 P1 P P Preceive INF_STATE/active/y Y1 1 1 2 D1 A B Breceive INF_STATE/active 2 D1 B1 Breceive INF_STATE/prepare-rcvd/y D1 receive INF_STATE/prepare-rcvd D1 receive INF_STATE/confirm-rcvd/y receive INF_STATE/confirm-rcvd receive INF_STATE/cancel-rcvd/y receive INF_STATE/cancel-rcvd receive INF_STATE/unknown Z Z Z Zsend ENROLLED 1 B1 Bsend RESIGNED Zsend PREPARE D1 send CONFIRM_ONE_PHASE send CONFIRM send CANCEL send CONTRADICTION send SUP_STATE/active/y 1 Bsend SUP_STATE/active 1 Bsend SUP_STATE/prepared-rcvd/y E1 E2 send SUP_STATE/prepared-rcvd E1 E2 send SUP_STATE/confirmed-rcvd/y send SUP_STATE/confirmed-rcvd send SUP_STATE/cancelled-rcvd/y send SUP_STATE/cancelled-rcvd send SUP_STATE/contradiction-known/y send SUP_STATE/contradiction-known send SUP_STATE/unknown decide to confirm one-phase 1 1 S1 S1 S1 S Sdecide to prepare 1 1 D Ddecide to confirm F1 F1 decide to cancel 1 G1 G1 Z G1 G G1 remove persistent information record contradiction disruption I Z Z Z Z Z Z Z B1disruption II D1 D1 Z disruption III B1 B1 disruption IV


Table 8 : Superior state table -- confirming and cancellng 3760 F1 F2 G1 G2 G3 G4

receive ENROL/rsp-req 2 G1 Greceive ENROL/no-rsp-req 2 G1 Greceive RESIGN/rsp-req G3 Z G3 receive RESIGN/no-rsp-req Z Z Z receive PREPARED F1 G1 G2 receive PREPARED/cancel F1 G1 G2 receive CONFIRMED/auto F1 L1 L1 receive CONFIRMED/response F2 F2 receive CANCELLED K1 G4 Z G4 receive HAZARD P3 P4 P4 receive INF_STATE/active/y G1 G2 receive INF_STATE/active G1 G2 receive INF_STATE/prepare-rcvd/y G1 G2 receive INF_STATE/prepare-rcvd G1 G2 receive INF_STATE/confirm-rcvd/y F1 receive INF_STATE/confirm-rcvd F1 receive INF_STATE/cancel-rcvd/y G2 receive INF_STATE/cancel-rcvd G2 receive INF_STATE/unknown Z Z Z Z send ENROLLED send RESIGNED send PREPARE send CONFIRM_ONE_PHASE send CONFIRM F1 send CANCEL G2 G2 Z Z send CONTRADICTION send SUP_STATE/active/y send SUP_STATE/active send SUP_STATE/prepared-rcvd/y send SUP_STATE/prepared-rcvd send SUP_STATE/confirmed-rcvd/y send SUP_STATE/confirmed-rcvd send SUP_STATE/cancelled-rcvd/y send SUP_STATE/cancelled-rcvd send SUP_STATE/contradiction-known/y send SUP_STATE/contradiction-known send SUP_STATE/unknown decide to confirm one-phase decide to prepare decide to confirm decide to cancel remove persistent information Z record contradiction disruption I F1 Z Z Z Z disruption II G2 G2 disruption III disruption IV

3761


Table 9 : Superior state table – autonomous decisions 3762 H1 J1 K1 L1

receive ENROL/rsp-req receive ENROL/no-rsp-req receive RESIGN/rsp-req receive RESIGN/no-rsp-req receive PREPARED receive PREPARED/cancel receive CONFIRMED/auto H1 L1 receive CONFIRMED/response receive CANCELLED J1 K1 receive HAZARD receive INF_STATE/active/y receive INF_STATE/active receive INF_STATE/prepare-rcvd/y receive INF_STATE/prepare-rcvd receive INF_STATE/confirm-rcvd/y receive INF_STATE/confirm-rcvd receive INF_STATE/cancel-rcvd/y receive INF_STATE/cancel-rcvd receive INF_STATE/unknown send ENROLLED send RESIGNED send PREPARE send CONFIRM_ONE_PHASE send CONFIRM send CANCEL send CONTRADICTION send SUP_STATE/active/y send SUP_STATE/active send SUP_STATE/prepared-rcvd/y send SUP_STATE/prepared-rcvd send SUP_STATE/confirmed-rcvd/y H1 send SUP_STATE/confirmed-rcvd H1 send SUP_STATE/cancelled-rcvd/y J1 send SUP_STATE/cancelled-rcvd J1 send SUP_STATE/contradiction-known/y K1 L1 send SUP_STATE/contradiction-known K1 L1 send SUP_STATE/unknown decide to confirm one-phase S1 decide to prepare decide to confirm F1 K1 decide to cancel L1 G4 remove persistent information record contradiction R1 R1 disruption I Z Z F1 Z disruption II E1 E1 G2 disruption III D1 D1 disruption IV B1 B1

3763


Table 10 : Superior state table – hazard 3764 P1 P2 P3 P4 Q1 R1 R2

receive ENROL/rsp-req receive ENROL/no-rsp-req receive RESIGN/rsp-req receive RESIGN/no-rsp-req receive PREPARED receive PREPARED/cancel receive CONFIRMED/auto Q1 R1 R1 receive CONFIRMED/response Z R2 R2 receive CANCELLED R1 R1 receive HAZARD P1 P2 P3 P4 R1 R1 receive INF_STATE/active/y receive INF_STATE/active receive INF_STATE/prepare-rcvd/y receive INF_STATE/prepare-rcvd receive INF_STATE/confirm-rcvd/y receive INF_STATE/confirm-rcvd receive INF_STATE/cancel-rcvd/y receive INF_STATE/cancel-rcvd receive INF_STATE/unknown P1 P2 P4 R2 R2 send ENROLLED send RESIGNED send PREPARE send CONFIRM_ONE_PHASE send CONFIRM send CANCEL send CONTRADICTION R2 send SUP_STATE/active/y send SUP_STATE/active send SUP_STATE/prepared-rcvd/y send SUP_STATE/prepared-rcvd send SUP_STATE/confirmed-rcvd/y send SUP_STATE/confirmed-rcvd send SUP_STATE/cancelled-rcvd/y send SUP_STATE/cancelled-rcvd send SUP_STATE/contradiction-known/y P1 P3 P4 send SUP_STATE/contradiction-known P1 P3 P4 send SUP_STATE/unknown decide to confirm one-phase decide to prepare decide to confirm decide to cancel remove persistent information Z record contradiction R1 R1 R1 R1 R1 disruption I Z Z Z Z Z R1 disruption II D1 F1 G2 disruption III B1 disruption IV

3765


Table 11 : Superior state table – one phase confirm and completing 3766 S1 Y1 Z

receive ENROL/rsp-req S1 Y1 Y1 receive ENROL/no-rsp-req S1 Y1 Y1 receive RESIGN/rsp-req Z Y1 Y1 receive RESIGN/no-rsp-req Z Z Z receive PREPARED S1 Y1 Y1 receive PREPARED/cancel S1 Y1 Y1 receive CONFIRMED/auto S1 Q1 Q1 receive CONFIRMED/response Z Z Z receive CANCELLED Z Y1 Y1 receive HAZARD Z P2 P2 receive INF_STATE/active/y S1 Y1 Y1 receive INF_STATE/active S1 Y1 Z receive INF_STATE/prepare-rcvd/y S1 Y1 Y1 receive INF_STATE/prepare-rcvd S1 Y1 Z receive INF_STATE/confirm-rcvd/y receive INF_STATE/confirm-rcvd receive INF_STATE/cancel-rcvd/y Y1 Y1 receive INF_STATE/cancel-rcvd Y1 Z receive INF_STATE/unknown Z Z Z send ENROLLED send RESIGNED send PREPARE send CONFIRM_ONE_PHASE S1 send CONFIRM send CANCEL send CONTRADICTION send SUP_STATE/active/y send SUP_STATE/active send SUP_STATE/prepared-rcvd/y send SUP_STATE/prepared-rcvd send SUP_STATE/confirmed-rcvd/y send SUP_STATE/confirmed-rcvd send SUP_STATE/cancelled-rcvd/y send SUP_STATE/cancelled-rcvd send SUP_STATE/contradiction-known/y send SUP_STATE/contradiction-known send SUP_STATE/unknown Z decide to confirm one-phase decide to prepare decide to confirm decide to cancel remove persistent information record contradiction disruption I Z Z disruption II disruption III disruption IV

3767


6.8 Inferior state table 3768

Table 12: Inferior state table – active, resigning and prepared 3769 i1 a1 b1 c1 d1 e1 e2

send ENROL/rsp-req a1 a1 send ENROL/no-rsp-req b1 b1 send RESIGN/rsp-req c1 send RESIGN/no-rsp-req z send PREPARED e1 send PREPARED/cancel e2 send CONFIRMED/auto send CONFIRMED/response send CANCELLED z2 z2 send HAZARD send INF_STATE/active/y a1 b1 send INF_STATE/active b1 send INF_STATE/prepare-rcvd/y d1 send INF_STATE/prepare-rcvd d1 send INF_STATE/confirm-rcvd/y send INF_STATE/confirm-rcvd send INF_STATE/cancel-rcvd/y send INF_STATE/cancel-rcvd send INF_STATE/unknown receive ENROLLED b1 b1 c1 e1 e2 receive RESIGNED z receive PREPARE d1 d1 c1 d1 e1 e2 receive CONFIRM_ONE_PHASE s2 s2 z d1 s1 s1 receive CONFIRM f1 f2 receive CANCEL n1 n1 z n2 g1 g2 receive CONTRADICTION receive SUP_STATE/active/y b1 b1 c1 e1 e2 receive SUP_STATE/active b1 b1 c1 e1 e2 receive SUP_STATE/prepared-rcvd/y e1 e2 receive SUP_STATE/prepared-rcvd e1 e2 receive SUP_STATE/confirmed-rcvd/y receive SUP_STATE/confirmed-rcvd receive SUP_STATE/cancelled-rcvd/y receive SUP_STATE/cancelled-rcvd receive SUP_STATE/contradiction-known/y receive SUP_STATE/contradiction-known receive SUP_STATE/unknown z z z z x1 x2 decide to resign c1 c1 decide to be prepared e1 e1 decide to be prepared/cancel e2 e2 decide to confirm autonomously h1 decide to cancel autonomously j1 z1 apply ordered confirmation remove persistent information detect problem p1 p1 p1 p2 p2 detect and record problem disruption I z z z z disruption II b1 disruption III


Table 13 : Inferior state table – confirm and cancel 3770 f1 f2 g1 g2

send ENROL/rsp-req send ENROL/no-rsp-req send RESIGN/rsp-req send RESIGN/no-rsp-req send PREPARED send PREPARED/cancel send CONFIRMED/auto send CONFIRMED/response send CANCELLED send HAZARD send INF_STATE/active/y send INF_STATE/active send INF_STATE/prepare-rcvd/y send INF_STATE/prepare-rcvd send INF_STATE/confirm-rcvd/y f1 f2 send INF_STATE/confirm-rcvd f1 f2 send INF_STATE/cancel-rcvd/y g1 g2 send INF_STATE/cancel-rcvd g1 g2 send INF_STATE/unknown receive ENROLLED receive RESIGNED receive PREPARE receive CONFIRM_ONE_PHASE receive CONFIRM f1 f2 receive CANCEL g1 g2 receive CONTRADICTION receive SUP_STATE/active/y receive SUP_STATE/active receive SUP_STATE/prepared-rcvd/y receive SUP_STATE/prepared-rcvd receive SUP_STATE/confirmed-rcvd/y receive SUP_STATE/confirmed-rcvd receive SUP_STATE/cancelled-rcvd/y receive SUP_STATE/cancelled-rcvd rece ction-known/y ive SUP_STATE/contradireceive ntradiction-known SUP_STATE/co rec ive SUP wn x1e _STATE/unkno x2 dec ide to resign decide ep to be pr ared decid e e to be prepar d/cancel decid utonomously e to confirm adecide to cancel autonomously apply ordered confirmation m1 m1 remove persistent information n1 n1 detect problem p2 p2 p2 p2 detect and record problem disruption I e1 e2 e1 e2 disruption II disruption III


Table 14 : inferior state table – autonomous decisions and contradiction 3771 h1 h2 j1 j2 k1 k2 l1 l2

send ENROL/rsp-req send ENROL/no-rsp-req sen p- d req RESIGN/rssend RESIGN/no-rsp-req sen d PREPARED send PREPARED/cancel sen h1 l1 d CONFIRMED/auto sen d CONFIRMED /responsesend CANCELLED j1 k1 send HAZARD sen active/y d INF_STATE/sen E/active d INF_STATsen vd/y d INF_STATE/prepare-rcsen rcvd d INF_STATE /prepare-send INF rcvd/y _STATE /confirm-send INF_STATE/confirm-rcvd h2 send INF_STATE/cancel-rcvd/y send INF_STATE/cancel-rcvd j2 send INF_STATE/unknown receive ENROLLED h1 j1 receive RESIGNED receive PREPARE h1 j1 receive CONFIRM_ONE_PHASE s3 s4 receive CONFIRM h2 h2 k1 k1 receive CANCEL l1 j2 j2 l1 receive CONTRADICTION l2 k2 k2 k2 l2 l2 receive SUP_STATE/active/y h1 j1 receive SUP_STATE/active h1 j1 receive SUP_STATE/prepared-rcvd/y h1 j1 receive SUP_STATE/prepared-rcvd h1 j1 receive SUP_STATE/confirmed-rcvd/y h1 receive SUP_STATE/confirmed-rcvd h1 receive SUP_STATE/cancelled-rcvd/y j1 receive SUP_STATE/cancelled-rcvd j1 receive SUP_STATE/contradiction-known/y h1 j1 k1 l1 receive SUP_STATE/contradiction-known h1 j1 k1 l1 receive SUP_STATE/unknown l1 j2 j2 k2 k2 l1 deci de to resign decide to be prepared decide cel to be prepared/candecide usly to confirm autonomo decide n sly to cancel auto omou apply irmation ordered conf remove persistent information m1 z z z detect problem detect blem and record prodisruption I h1 j1 j1 k1 h1 l1 disrupt j1 h1 ion II disru ption III

3772


Table 15 : infer – cancelling and hazard ior state table3773 m1 n1 n2 p1 p2 q1

send OL/rsp-req ENRsend ENR req OL/no-rsp-send RESIGN/rsp-req send RE req SIGN/no-rsp-send PRE PARED send PREPARED/cancel send CO NFIRMED/auto send nse z CONFIRMED/resposend CANCELLED z2 z2 send HAZARD p1 p2 q1 send INF_STATE/active/y send INF_STATE/active send INF vd/y _STATE/prepare-rc send IN re-rcvd F_STATE/prepasend INF m-rcvd/y _STATE/confirsend IN i F_STATE/conf rm-rcvd send INF _STATE/cancel-rcvd/y send IN F_STATE/cancel-rcvd send INF n _STATE/unknowreceive ENROLLED p1 p2 q1 receive RESIGNED recei p1 p2 q1 ve PREPARE receive CONFIRM_ONE_PHASE s5 s5 s6 receive CONFIRM m1 p2 q1 receive CANCEL n1 n2 p1 p2 q1 rece CTION z z z ive CONTRADIreceive q1 SUP_STATE/active/y p1 p2 receive tive q1 SUP_STATE/ac p1 p2 receive SUP_STATE/prepared-rcvd/y p2 q1 receive SUP_STATE/prepared-rcvd p2 q1 receive SUP_STATE/confirmed-rcvd/y receive confirmed-rcvd SUP_STATE/receive cancelled-rcvd/y SUP_STATE/receive ancelled-rcvd SUP_STATE/creceive wn/y p1 p2 q1 SUP_STATE/contradiction-knoreceive SUP_STATE/contradiction-known p1 p2 q1 receive z2 z2 p1 p2 q1 SUP_STATE/unknown decid gn e to residecide to be prepared decide to be prepared/cancel decide to confirm autonomously deci autonomously de to cancelapply ordered confirmation remove ion persistent informat detect problem p1 p1 detect problem q1 q1 and record disrup z z tion I z z disrup b1 d1 tion II disrupt b1 ion III

3774


Table 16 : inferior state table – one phase confirmation 3775 s1 s2 s3 s4 s5 s6

send ENROL/rsp-req send ENROL/no-rsp-req send RESIGN/rsp-req send RESIGN/no-rsp-req send PREPARED send PREPARED/cancel send CONFIRMED/auto send CONFIRMED/response z send CANCELLED z2 send HAZARD z z send INF_STATE/active/y send INF_STATE/active send INF_STATE/prepare-rcvd/y send INF_STATE/prepare-rcvd send INF_STATE/confirm-rcvd/y send INF_STATE/confirm-rcvd send INF_STATE/cancel-rcvd/y send INF_STATE/cancel-rcvd send INF_STATE/unknown receive ENROLLED receive RESIGNED receive PREPARE receive CONFIRM_ONE_PHASE s1 s2 s3 s4 s5 s6 receive CONFIRM receive CANCEL receive CONTRADICTION s3 z s6 receive SUP_STATE/active/y rece /active ive SUP_STATErece /prepared- ive SUP_STATE rcvd/y receive SUP_STATE/prepared-rcvd receive SUP_STATE/confirmed-rcvd/y receive SUP_STATE/confirmed-rcvd rece /cancelled-rcvd/y ive SUP_STATEreceive ed-rcvd SUP_STATE/cancellreceive iction-known/y SUP_STATE/contradreceive ction-known SUP_STATE/contradi recei /u z z ve SUP_STATE nknown x1 z z z decid e to resign decide to be prepared decide to be prepared/cancel decide to confirm autonomously s3 decide to cancel autonomously s4 appl onfirmation y ordered cremove ion persistent informat s2 detect problem detect and record problem s6 disrupt e1 z z z ion I disrupti on II disrupti on III

3776


Tabl able – completing states including queried when completed 3777 x1 x2 y1 y2 y3 z z1 z2

e 17 : inferior state t

send EN ROL/rsp-req send -rsp-req ENROL/nosend RESIGN/rsp-req send RESIGN/no-rsp-req send PREPARED send cel PREPARED/cansend CON FIRMED/auto send CON ponse FIRMED/res send CANCELLED z1 z2 send HA ZARD send INF _STATE/active/y send IN F_STATE/active send INF -rc _STATE/prepare vd/y send INF_STATE/pre -rcvd paresend IN rcvd/y F_STATE/confirm-send on rcvd INF_STATE/c firm-send INF_STATE/cancel-rcvd/y send INF_STATE/cancel-rcvd send INF_STATE/unknown z rece y1 y2 y3 z z1 z2 ive ENROLLEDreceive z RESIGNED y1 receiv 3 y1 z1 y3 e PREPARE y1 y2 yreceiv y3 y1 y1 y3 e CONFIRM_ONE_PHASE y1 y2 receiv m1 y2 e CONFIRM y2 receive y1 z y3 y1 y1 y3 CANCEL receive O z z z z CONTRADICTI N receiv y1 y2 y3 y1 y2 y3 e SUP_STATE/active/y receive y1 y2 y3 z z1 z2 SUP_STATE/active receive are y2 y2 SUP_STATE/prep d-rcvd/y receive SUP_STATE/ ared-rcvd y2 z1 prepreceive rmed-rcvd/y SUP_STATE/confirecei ATE/ rmed-rcvd ve SUP_ST confirecei TE/cancelled-rcvd/y y2 y2 ve SUP_STAreceive SUP_STATE/cancelled-rcvd y2 z1 receive SUP_STATE/contradiction-known/y y1 y2 y1 y2 rece /contradiction-known y1 y2 z z1 ive SUP_STATEreceiv 2 z z z2 e SUP_STATE/unknown x1 x2 y1 y2 zdecide to resign decide to be prepared decide ed/cancel to be prepardecide to confirm autonomously decide to cancel autonomously apply tio ordered confirma n remove persistent rmation z z infodetect problem detec d em t and recor probldisru e1 e2 z z1 z z ption I disruption II disruption III


7 Persistent information 3778

The BTP recovery mecha s require that information is persisted by the BTP Actors that 3779 perform th r roles. To ensure consistent application of the outcome, despite 3780 failures ust persist some state information at the point of becoming prepared, and 3781 the Superior at the point of making a Confirm decision. If the Superior is a Sub-coordinator or 3782 Sub-composer, it must persist information when, as an Inferior, it becomes prepared. The 3783 minimum information to be persisted is the identifiers and addresses of the Peer Inferiors and 3784 Super persistence being itself an indication of the preparedness or Confirm 3785 decision ery of a Super cur in other cases 3786 – during a Confirm decision ha , in general, the 3787 BTP Act current state of3788 Since BTP messages may carry application-specified qualifiers, which may need to be re-sent in 3789 the case o the first attempt got lost). BTP Actors should be prepared to persist 3790 such qua3791 A Particip e information concerning the application work 3792 whose fi is re he nature of this information is not considered 3793 further in this specification3794 Informa is n Inferior’s “decision to be prepared” must be sufficient to re-3795 establis on with the Superior, to apply a Confirm decision and to apply a Cancel 3796 decision. It will thus need to include 3797 “superior-address”(as on CONTEXT as updated by REDIRECT) 3798 fier” (as on CONTEXT) 3799 “default on PREPARED3800 A Super g information t munication with 3801 the Inferior. Thus, for each Inferior 3802 “inferi ated by REDIRECT) 3803 “inferior-identifier” (as on ENROL) 3804 In order nctio r and Inferior will need to persist their own 3805 Identifier (“superior-identi nd “inferior-identifier”) and, depending on the implementation, may 3806 need to pe erior-address” or “inferior-address”. 3807

nisme Superior and Inferio

, the Inferior m

ior – the fact of the. However, BTP allows recov ior:Inferior relationship to oc the active phase, and before s been made. Thusors will need to persist the the relationships.

f failure (becauselifiers as well. ant will normally also need to persist som

nal or counter effect it sponsible for. T.

tion to be pers ted for ah communicati

“superior-identi-is-cancel” value (as )

ior must record correspondin o allow it to re-establish com

or-address” (as on ENROL, as upd

to recover their own fu n, both Superiofier” a

rsist their original “sup


8 XML representation of Message Set 3808

This sec synt BTP message s represent a 3809 midpoint between the abstract messages and what actually gets sent on the wire. 3810 All URIs e URLs starting “http://docs.oasis-3811 open.org/business-transaction/business_transaction-btp-1.1-“. (Note that “business” and 3812 “transactio tances (where it is a directory name on the 3813 OASIS s rscor echnical committee name 3814 forming a single part of the ent identification). The last part will identify the status of the 3815 document ttee draft, oasis standard). The schemas will usually be 3816 accessi rencing that URL. (BTP 1.0 used URN-form URIs). 3817 The XML Namespace for the BTP messages is: 3818 http://docs.oasis-open.org/business-transaction/business_transaction-btp-1.1-core-schema-wd-3819 05.xsd3820 In additio pecification use ribe the structure 3821 of the BT pears as an X contain data types 3822 instead o lowin s are append structs: ? (zero 3823 or one), * (zero or more), + (one or more.) The absence of one of these symbols corresponds to 3824 "one and 3825 The Delivery Parameters are shown in the XML with a darker background. 3826

8.1 Fie3827

8.1.1 3828

As described in the “Abstract Message and Associated Contracts – Addresses” section, a BTP 3829 Address comprises three parts, and for a “target-address” only the “additional information” field is 3830 inside es whose abstract form includes a “target-address” 3831 param representation incl formation” 3832 element.3833 For othe ree f re represent, as in: 3834

tion describes the ax for s in XML. These XML message

for the XML schemas defined by BTP ar

n” are joined by a hyphen in the first inserver) and by an unde e in the second (where it is the t

docum (working draft, commi

ble by derefe

n to an XML schema, this s s an informal syntax to descP messages. The syntax ap ML instance, but the values f values. The fol g symbol ed to some of the XML con

only one."

ld types

Addresses

the BTP messages. For all BTP messageter, the corresponding XML udes a “target-additional-in

This element may be omitted if it would be empty. r addresses, all th ields a

<btp priority=”...value...”?> :some-address 3835 < ng name...</btp:binding-name> 3836 btp:binding-name>...carrier bindi <btp:binding-address>...carrier specific address...</btp:binding-3837 addr3838 ess> < onal additional addressing 3839 btp:additional-information>...optiinformation...</btp:additional-information> ? 3840 </btp:some-address> 3841

3842 A "published" address can be a set of <some-address>, which are alternatives which can be 3843 chosen by the Peer (sender.) Multiple addresses are used in two cases: different bindings to 3844 same kup endpoints. In the former, the receiver of the message has the choice of 3845 which ad which binding ere multiple 3846 addresse a priority attrib the receiver 3847 choose a ddresses- the addre h ed, other things 3848 being eq used as a hin not enforce any behaviour in the receiver of 3849 the message. The lower the value, the higher the priority. Default priority is a value of 1. 3850

endpoint, or bacdress to use (depending on is preferable.) In the case whs are used for redundancy, ute can be specified to help mong the a ss with the ighest priority should be usual. The priority is t and does

8.1.2 Q3851

The “Qua the element name, within the namespace of the “Qualifier group”. 3852 Examp3853

ualifiers lifier name” is used as

les: <btpq:inferior-timeout 3854 xmlns:btpq="http://docs.oasis-open.org/business-3855 transaction/business_transaction-btp-1.1-qualifiers-schema-wd-05.xsd" 3856 ocs.oasis-open.org/business-3857 xmlns:btp="http://dtra action-btp-1 d" 3858 nsaction/business_trans .1-core-schema-wd-05.xs b erst false" 3859 tp:must-be-und ood=" btp:to-be-propagated="false">1800</btpq:inferior-timeout> 3860 3861 <au3862 th:username xmlns:auth="http://www.example.com/ns/auth" 3863 xm rg/business-3864 lns:btp="http://docs.oasis-open.otransaction/business_transaction-btp-1.1-core-schema-wd-05.xsd" 3865 btp:must-be-understood="true" 3866 bt ="true">jtauber</auth:username> 3867 p:to-be-propagated 3868

Attributes must-be-understood has default value “true” and to-be-propagated has default value 3869 “false”. 3870

8.1.33871

Identifier Is. 3872

No lobally unambig eration, the 3873 only operation the BTP implementations have to perform on identifiers is to match 3874 them3875

8.1.4 M3876

Each BT tional id attribute to give it a unique identifier. An application can 3877 make use t no processing is enforced. 3878

8.2 Messages 3879

Element content specified in bold is the default when the element is absent. 3880

8.2.1 C3881

Identifiers s shall be UR

te – Identifiers need to be g uous. Apart from their gen

.

essage References P message has an op of those identifiers, bu

ONTEXT <btp:context id?> 3882 < riority?> + 3883 btp:superior-address p 3884 ...address... </btp:superior-address> 3885 ...URI...</btp:superior-identifier> 3886 tp:superior-id < btp:superior-type> ? 3887 btp:superior-type>cohesion|atom</ <btp:qualifiers> ? 3888 3889 ...qualifiers... <3890 /btp:qualifiers> <btp:reply-addr ? 3891 ess> 3892 ...address... s> 3893 </btp:reply-addres</btp:context> 3894

8.2.2 CONTEXT_REPLY 3895

<btp:context-reply id?> 3896 < >...URI...</ > btp:superior-identifier btp:superior-identifier3897

<btp:completion-3898 sta ncom e|related|re >3899 tus>completed|i plet pudiated</btp:completion-status 3900 .. 3902 ...qualifiers. </btp:qualifiers> 3903 ? 3904 tp:target-additional-inf ...additional address information... 3905 </ > 3906 btp:target-additional-information</btp:context-reply> 3907

8.2.3 RE3908 QUEST_STATUS <btp:request-status id?> 3909 <btp:target-identifier>...URI...</btp:target-identifier> 3910 <btp:qualifiers> ? 3911 ...qualifiers... 3912 fie3913 </btp:quali rs> < l-information> ?3914 btp:target-additiona nal address information...3915 ...additio < ditional-information> 3916 /btp:target-ad <btp:reply-address> ? 3917 3918 ...address... <3919 /btp:reply-address> </btp:request-status> 3920

8.2.4 STATUS 3921

 3922 >...URI...</btp:responders-identifier> 3923 <btp:responders-identifier <btp:status-value>created|enrolling|active|resigning| 3924 resigned|preparing|prepared| 3925 confirming|confirmed|cancelling|cancelled| 3926 ontradiction|confirm-contradiction| 3927 cancel-c n|inaccessible</btp:status-value> 3928 hazard|contradicted|unknow <btp:qualifiers3929 > ? 3930 ...qualifiers... <3931 /btp:qualifiers> <btp:target-additional-information> ? 3932 ...additional address information... 3933 < ormation> 3934 /btp:target-additional-inf</btp:status> 3935

8.2.5 FA3936 ULT <btp:fault id?> 3937 ? 3938 tp:superior-identifier>...URI...< ri btp:inferior-identifier> ? 3939 <btp:infe or-identifier>...URI...</ >...fault type name...</btp:fault-type> 3940 <btp:fault-type <btp:fault-data>...fault data...</btp:fault-data> ? 3941 <btp:fault-text>...string data ...</btp:fault-text> ? 3942 <btp:qualifiers> ? 3943 3944 ...qualifiers... <3945 /btp:qualifiers> < nal- formation> ?3946 btp:target-additio in nformation..3947 ...additional address i . </ na nformation> 3948 btp:target-additio l-i</btp:fault> 3949

3950

The follo y simple strings, corresponding to the entries 3951 defined in the abstract message set: 3952 • com3953 • duplicate-inferior 3954 • gen3955 • invalid-decider 3956 • invalid-inferior 3957 • in3958 • statu3959 • invali3960 • unkno3961 • unkn3962 • unsup3963 • wron3964 • redire3965 3966 Revisions ay add other fault type names, which shall be simple strings of 3967 letters, r specifications define fault type names to be used with 3968 BTP, th3969 Fault data can take on various forms: 3970 Identifier: 3971

wing fault type names are represented b

munication-failure

eral

valid-superior s-refused d-terminator wn-parameter

own-transaction ported-qualifier

g-state ct

of this specification mnumbers and hyphens. If othee names shall be URIs.

<bt p:fault-datap:fault-data>...URI...</bt > 3972

3973 Inferior Id3974 entity:

<btp:fault-data> 3975 <b3976 tp:inferior-address> + 3977 ...address... 3978 </btp:inferior-address> <btp:inferior-identifier>...URI...</btp:inferior-identifier> 3979 </btp:fault-data> 3980

3981

8.2.6 E3982

NROL <btp:enrol id?> 3983 < </btp:superior-identifier> 3984 btp:superior-identifier>...URI... < </btp:response-requested> ? 3985 btp:response-requested>true|false + 3987 ...address... </ > 3988 btp:inferior-address ...URI...</btp:inferior-identifier> 3989 tp:inferior-ident 3990 <btp:qualifiers> ? 3991 ...qualifiers... </btp:qualifiers> 3992 <btp:target-additional-information> ? 3993 ...additional address information... 3994 l-information> 3995 </btp:target-additiona <3996 btp:reply-address> ? ...address... 3997

< > /btp:reply-address3998 </btp:enrol> 3999

8.2.7 ENROLLED 4000

<btp:enrolled id?> 4001 <btp:inferior-identifier>...URI...</btp:inferior-identifier> 4002 <b4003 tp:qualifiers> ? 4004 ...qualifiers... </btp:qualifiers4005 > ? 4006 tp:target-additio ess information... 4007 ...additional addr > 4008 </btp:target-additional-information <btp:sender-address> ? 4009 ...address... 4010 </btp:sender-address> 4011 </btp:enrolled> 4012

8.2.8 RESIGN 4013

<btp:resign id?> 4014 <btp:superior-identifier>...URI...</btp:superior-identifier> 4015 4016 tp:inferior-identifier>...URI...< ru btp:response-requested> ? 4017 <btp:response-requested>t e|false</ 4018 <btp:qualifiers> ? ...qualifiers... 4019 </btp:qualifiers> 4020 <btp:target-additional-information> ? 4021 tion... 4022 ...additional address informa <4023 /btp:target-additional-information> < > ? 4024 btp:sender-address .4025 ..address... </ > 4026 btp:sender-address</btp:resign> 4027

8.2.9 R4028 ESIGNED <btp:resigned id?> 4029 < tifi btp:inferior-identifier> 4030 btp:inferior-iden er>...URI...</ <btp:qualifiers> ? 4031 4032 ...qualifiers... 4033 </btp:qualifiers> > ? 4034 <btp:target-additional-information ...additional address information... 4035 </btp:target-additional-information> 4036 <btp:sender-address> ? 4037 4038 ...address... <4039 /btp:sender-address> </btp:resigned> 4040

8.2.10 PR4041 EPARE <btp:prepare id?> 4042 <btp:superior-identifier>...URI...</btp:superior-identifier> 4043 <btp:inferior-identifier </btp:inferior-identifier> 4044 >...URI... <btp:4045 qualifiers> ? ...qualifiers... 4046 </btp4047 :qualifiers> <btp:target-additional-information> ? 4048

...additional address information... 4049 < ditional-information> 4050 /btp:target-ad <btp:sender-address> ? 4051 .4052 ..address... <4053 /btp:sender-address> </btp:prepare> 4054

8.2.114055 PREPARED <btp:prepared id?> 4056 <btp:superior-identifier>...URI...</btp:superior-identifier> 4057 <btp:inferior-identifier>...URI...</btp:inferior-identifier> 4058 <btp:default-is-cancel>true|false</btp:default-is-cancel> 4059 <btp:qualifiers> ? 4060 ...qualifiers... 4061 </btp:qualifiers> 4062 <btp:target-additional-information> ? 4063 nformation... 4064 ...additional address i < di nformation> 4065 /btp:target-ad tional-i < > ? 4066 btp:sender-address .4067 ..address... 4068 </btp:sender-address> </btp:prepared> 4069

8.2.12 CONFIRM 4070

< t ?>b p:confirm id 4071 < >...URI...</btp:superior-identifier> 4072 btp:superior-identifier ...URI...</btp:inferior-identifier> 4073 tp:inferior- <4074 btp:qualifiers> ? 4075 ...qualifiers... 4076 </btp:qualifiers> <btp:target-additional-information> ? 4077 ...additional address information... 4078 </btp:target-additional-information> 4079 4080 <btp:sender-address> ? 4081 ...address... </ 4082 btp:sender-address></btp:confirm> 4083

8.2.13 CONFIRMED 4084

<btp:confirmed id?> 4085 ntifier>...URI...</btp:superior-identifier> 4086 <btp:superior-ide < ifier>...URI...</btp:inferior-identifier> 4087 btp:inferior-ident < >true|false</btp:confirm-received> 4088 btp:confirm-received <b4089 tp:qualifiers> ? ...qualifiers... 4090 4091 </btp:qualifiers> <btp:target-additional-information> ? 4092 ...additional address information... 4093 </btp:target-additional-information> 4094 4095 <btp:sender-address> ? ..4096 ...address . </btp:sender-address> 4097 </btp:confirmed> 4098

8.2.14 CANCEL 4099

<btp:cancel id?> 4100 < if btp:superior-identifier> 4101 btp:superior-ident ier>...URI...</ <btp:inferior-identifier>...URI...</btp:inferior-identifier> 4102 <b4103 tp:qualifiers> ? 4104 ...qualifiers... 4105 </btp:qualifiers> <btp:target-additional-information> ? 4106 ...additional address information... 4107 </btp:target-additional-information> 4108 <btp:sender-address> ? 4109 ...address... 4110 </btp:sender-address> 4111 </btp:cancel> 4112

8.2.15 C4113 ANCELLED <btp:cancelled id?> 4114 ..</btp:superior-identifier> 4115 <btp:superior-identifier>...URI. ntifier>...URI...</btp:inferior-identifier> ? 4116 <btp:inferior-ide <btp:qualifiers> ? 4117 ...qualifiers... 4118 </btp:qualifiers> 4119 <btp:target-additional-information> ? 4120 ...additional address information... 4121 </btp:target-additional-information> 4122 <btp:sender-address> ? 4123 ...address... 4124 r-address> 4125 </btp:sende< t > /b p:cancelled4126

8.2.16 _ONE_PHASE 4127 CONFIRM<btp:confirm-one-phase id?> 4128 <btp:superior-identifier>...URI...</btp:superior-identifier> 4129 <btp:inferior-identifier>...URI...</btp:inferior-identifier> 4130 <btp:qualifiers> ? 4131 ...qualifiers... 4132 </btp:qualifiers> 4133 <btp:target-additional-information> ? 4134 ...additional address information... 4135 </btp:target-additional-information> 4136 <btp:sender-address> ? 4137 ...address... 4138 </btp:sender-address> 4139 </btp:confirm-one-phase> 4140

8.2.17 HAZARD 4141

<btp:hazard id?> 4142 <btp:superior-identifier>...URI...</btp:superior-identifier> 4143 <btp:inferior-identifier>...URI...</btp:inferior-identifier> 4144 <btp:level>mixed|possible</btp:level> 4145 <btp:qualifiers> ? 4146 ...qualifiers... 4147 </btp:qualifiers> 4148 <btp:target-additional-information> ? 4149 ...additional address information... 4150 </btp:target-additional-information> 4151

<btp:sender-address> ? 4152 ...address... 4153 </btp:sender-address> 4154 </btp:hazard> 4155

8.2.18 CONTRADICTION 4156

<btp:contradiction id?> 4157 <btp:inferior-identifier>...URI...</btp:inferior-identifier> 4158 <btp:qualifiers> ? 4159 ...qualifiers... 4160 </btp:qualifiers> 4161 <btp:target-additional-information> ? 4162 ...additional address information... 4163 </btp:target-additional-information> 4164 <btp:sender-address> ? 4165 ...address... 4166 </btp:sender-address> 4167 </btp:contradiction> 4168

8.2.19 SUPERIOR_STATE 4169

<btp:superior-state id?> 4170 <btp:inferior-identifier>...URI...</btp:inferior-identifier> 4171 <btp:status>active|prepared-received|inaccessible|unknown</btp:status> 4172 <btp:response-requested>true|false</btp:response-requested> ? 4173 <btp:qualifiers> ? 4174 ...qualifiers... 4175 </btp:qualifiers> 4176 <btp:target-additional-information> ? 4177 ...additional address information... 4178 </btp:target-additional-information> 4179 <btp:sender-address> ? 4180 ...address... 4181 </btp:sender-address> 4182 </btp:superior-state> 4183

8.2.20 INFERIOR_STATE 4184

<btp:inferior-state id?> 4185 <btp:superior-identifier>...URI...</btp:superior-identifier> 4186 <btp:inferior-identifier>...URI...</btp:inferior-identifier> 4187 <btp:status>active|inaccessible|unknown</btp:status> 4188 <btp:response-requested>true|false</btp:response-requested> ? 4189 <btp:qualifiers> ? 4190 ...qualifiers... 4191 </btp:qualifiers> 4192 <btp:target-additional-information> ? 4193 ...additional address information... 4194 </btp:target-additional-information> 4195 <btp:sender-address> ? 4196 ...address... 4197 </btp:sender-address> 4198 </btp:inferior-state> 4199

8.2.21 REDIRECT 4200

<btp:redirect id?> 4201 <btp:superior-identifier>...URI...</btp:superior-identifier> ? 4202

<btp:inferior-identifier>...URI...</btp:inferior-identifier> 4203 <btp:old-address> + 4204 ...address... 4205 </btp:old-address> 4206 <btp:new-address> + 4207 ...address... 4208 </btp:new-address priority?> 4209 <btp:qualifiers> ? 4210 ...qualifiers... 4211 </btp:qualifiers> 4212 <btp:target-additional-information> ? 4213 ...additional address information... 4214 </btp:target-additional-information> 4215 </btp:redirect> 4216

8.2.22 BEGIN 4217

<btp:begin id?> 4218 <btp:transaction-type>cohesion|atom</btp:transaction-type> 4219 <btp:context> .. context content .. </btp:context> ? 4220 <btp:qualifiers> ? 4221 ...qualifiers... 4222 </btp:qualifiers> 4223 <btp:target-additional-information> ? 4224 ...additional address information... 4225 </btp:target-additional-information> 4226 <btp:reply-address> ? 4227 ...address... 4228 </btp:reply-address> 4229 </btp:begin> 4230

8.2.23 BEGUN 4231

<btp:begun id?> 4232 <btp:decider-address priority?> * 4233 ...address... 4234 </btp:decider-address> 4235 <btp:inferior-address priority?> * 4236 ...address... 4237 </btp:inferior-address> 4238 <btp:transaction-identifier>...URI...</btp:transaction-identifier> 4239 <btp:context> .. context content .. </btp:context> 4240 <btp:qualifiers> ? 4241 ...qualifiers... 4242 </btp:qualifiers> 4243 <btp:target-additional-information> ? 4244 ...additional address information... 4245 </btp:target-additional-information> 4246 </btp:begun> 4247

8.2.24 PREPARE_INFERIORS 4248

<btp:prepare-inferiors id?> 4249 <btp:transaction-identifier>...URI...</btp:transaction-identifier> 4250 <btp:inferiors-list> ? 4251 <btp:inferior-identifier>...URI...</btp:inferior-identifier> + 4252 </btp:inferiors-list> 4253 <btp:qualifiers> ? 4254 ...qualifiers... 4255 </btp:qualifiers> 4256

<btp:target-additional-information> ? 4257 ...additional address information... 4258 </btp:target-additional-information> 4259 <btp:reply-address> ? 4260 ...address... 4261 </btp:reply-address> 4262 </btp:prepare-inferiors> 4263

8.2.25 CONFIRM_TRANSACTION 4264

<btp:confirm-transaction id?> 4265 <btp:transaction-identifier>...URI...</btp:transaction-identifier> 4266 <btp:inferiors-list> ? 4267 <btp:inferior-identifier>...URI...</btp:inferior-identifier> + 4268 </btp:inferiors-list> 4269 <btp:report-hazard>true|false</btp:report-hazard> 4270 <btp:qualifiers> ? 4271 ...qualifiers... 4272 </btp:qualifiers> 4273 <btp:target-additional-information> ? 4274 ...additional address information... 4275 </btp:target-additional-information> 4276 <btp:reply-address> ? 4277 ...address... 4278 </btp:reply-address> 4279 </btp: confirm_transaction> 4280

8.2.26 TRANSACTION_CONFIRMED 4281

<btp:transaction-confirmed id?> 4282 <btp:transaction-identifier>...URI...</btp:transaction-identifier> 4283 <btp:qualifiers> ? 4284 ...qualifiers... 4285 </btp:qualifiers> 4286 <btp:target-additional-information> ? 4287 ...additional address information... 4288 </btp:target-additional-information> 4289 </btp:transaction-confirmed> 4290

8.2.27 CANCEL_TRANSACTION 4291

<btp:cancel-transaction id?> 4292 <btp:transaction-identifier>...URI...</btp:transaction-identifier> 4293 <btp:report-hazard>true|false</btp:report-hazard> 4294 <btp:qualifiers> ? 4295 ...qualifiers... 4296 </btp:qualifiers> 4297 <btp:target-additional-information> ? 4298 ...additional address information... 4299 </btp:target-additional-information> 4300 <btp:reply-address> ? 4301 ...address... 4302 </btp:reply-address> 4303 </btp:cancel-transaction> 4304

8.2.28 CANCEL_INFERIORS 4305

<btp:cancel-inferiors id?> 4306 <btp:transaction-identifier>...URI...</btp:transaction-identifier> 4307

<btp:inferiors-list> 4308 <btp:inferior-identifier>...URI...</btp:inferior-identifier> + 4309 </btp:inferiors-list> 4310 <btp:qualifiers> ? 4311 ...qualifiers... 4312 </btp:qualifiers> 4313 <btp:target-additional-information> ? 4314 ...additional address information... 4315 </btp:target-additional-information> 4316 <btp:reply-address> ? 4317 ...address... 4318 </btp:reply-address> 4319 </btp:cancel-inferiors> 4320

8.2.29 TRANSACTION_CANCELLED 4321

<btp:transaction-cancelled id?> 4322 <btp:transaction-identifier>...URI...</btp:transaction-identifier> 4323 <btp:qualifiers> ? 4324 ...qualifiers... 4325 </btp:qualifiers> 4326 <btp:target-additional-information> ? 4327 ...additional address information... 4328 </btp:target-additional-information> 4329 </btp:transaction-cancelled> 4330

8.2.30 REQUEST_INFERIOR_STATUSES 4331

<btp:request-inferior-statuses id?> 4332 <btp:target-identifier>...URI...</btp:target-identifier> 4333 <btp:inferiors-list> ? 4334 <btp:inferior-identifier>...URI...</btp:inferior-identifier> + 4335 </btp:inferiors-list> 4336 <btp:qualifiers> ? 4337 ...qualifiers... 4338 </btp:qualifiers> 4339 <btp:target-additional-information> ? 4340 ...additional address information... 4341 </btp:target-additional-information> 4342 <btp:reply-address> ? 4343 ...address... 4344 </btp:reply-address> 4345 </btp:request-inferior-statuses> 4346

8.2.31 INFERIOR_STATUSES 4347

<btp:inferior-statuses id?> 4348 <btp:responders-identifier>...URI...</btp:responders-identifier> 4349 <btp:status-list> 4350 <btp:status-item> + 4351 <btp:inferior-identifier>...URI...</btp:inferior-identifier> 4352 <btp:status>active|resigned|preparing|prepared| 4353 autonomously-confirmed|autonomously-cancelled| 4354 confirming|confirmed|cancelling|cancelled| 4355 cancel-contradiction|confirm-contradiction| 4356 hazard|invalid</btp:status> 4357 <btp:qualifiers> ? 4358 ...qualifiers... 4359 </btp:qualifiers> 4360 </btp:status-item> 4361

</btp:status-list> 4362 <btp:qualifiers> ? 4363 ...qualifiers... 4364 </btp:qualifiers> 4365 <btp:target-additional-information> ? 4366 ...additional address information... 4367 </btp:target-additional-information> 4368 </btp:inferior-statuses> 4369

8.3 Standard qualifiers 4370

The informal syntax for these messages assumes the namespace prefix “btpq” is associated with 4371 the URI “http://docs.oasis-open.org/business-transaction/business_transaction-btp-1.1-qualifiers-4372 schema-wd-05.xsd”. 4373

8.3.1 Transaction timelimit 4374

<btpq:transaction-timelimit> 4375 <btpq:timelimit> 4376 ...time in seconds... 4377 </btpq:timelimit> 4378 </btpq:transaction-timelimit> 4379

8.3.2 Inferior timeout 4380

<btpq:inferior-timeout> 4381 <btpq:timeout> 4382 ...time in seconds... 4383 </btpq:timeout> 4384 <btpq:intended-decision>confirm|cancel</btpq:intended-decision> 4385 </btpq:inferior-timeout> 4386

8.3.3 Minimum inferior timeout 4387

<btpq:minimum-inferior-timeout> 4388 <btpq:minimum-timeout> 4389 ...time in seconds... 4390 </btpq:minimum-timeout> 4391 </btpq:minimum-inferior-timeout> 4392

8.3.4 Inferior name 4393

<btpq:inferior-name> 4394 <btpq:inferior-name> 4395 ...string... 4396 </btpq:inferior-name> 4397 </btpq:inferior-name> 4398

8.3.5 Cancel-on-zero-participants 4399

<btpq:cancel-on-zero-participants> 4400 <btpq:value> 4401 true|false 4402 </btpq:value> 4403 </btpq: cancel-on-zero-participants > 4404

8.3.6 Expected-time-till-state-change 4405

<btpq:expected-time-till-state-change> 4406 <btpq:expected-time> 4407 ...time in seconds... 4408 </btpq:expected-time> 4409 </btpq: expected-time-till-state-change > 4410

8.4 Compounding of Messages 4411

Relati ther, in a “group” is represented by containing them within the 4412 btp:r the related messages as child elements. The processing for the 4413 group s s .9 Groups – combinations of related messages”. For example 4414

ng BTP to one anoelated i defined in the

-group element, with ection “5

<btp:4415 related-group> <btp:context-reply> 4416 ...<completion-status>related</completion-status> ... 4417 </btp:context-reply> 4418 <btp:en4419 rol>...</btp:enrol> <btp:pre tp:prepared> 4420 pared>...</b</btp:relat4421

If the the ess” of the abs tted, the 4422 corre shall be absen the related-4423 group. The Carrie ies how a relation between application and BTP 4424 messages is rep4425 Bund ic bination s and related groups is 4426 indicated with th " ment, w ages and related groups as 4427 child elements. o t n): 4428

ed-group>

rules for group state that the “target-addr tract message is omisponding target-address-information element t in the message in

r Protocol binding specifresented.

ling (semant ally insignificant com ) of BTP messagee "btp:messages ele ith the bundled messF r example (confirming one and ca her inferiors of a Cohesioncelling ano

<btp:messages> 4429 <btp:confirm>...</btp:confirm> 4430 <btp:cancel>...</btp: cancel>4431 </btp:mes ges>

ema for essage wiess_tr ction-btp-1

be considered as an inte

sa4432 4433

8.5 XML Schemas 4434

8.5.1 XML schema for BTP messages 4435

The XML sch the BTP m s, th namespace “http://docs.oasis-open.org/business-4436 transaction/busin ansa .1-core-schema-wd-05.xsd” is available at the same URL. 4437 This file is to gral and normative part of this document. 4438

8.5.2 XML schema for standard qualifiers 4439

The XML schema for the standard qualifiers, with namespace http://docs.oasis-4440 open.org/business-transaction/business_transaction-btp-1.1-qualifiers-schema-wd-05.xsd 4441 available at the same URL. This file is to be considered as a integral and normative part of this 4442 document. 4443 4444

9 Carrier Protocol Bindings 4445

The c ween the BTP 4446 unde s must define various particulars 4447 mes ow the related Application Mes d. 4448 This document s : a SOAP b Attachments binding. 4449 However, other b cified by th l committee or by a third 4450 party. For th ding might exist to put a BTP message directly on top of 4451 HTTP without the use of SOAP, or a closed community could define their own binding. To ensure 4452 that a ding a be 4453 included in a bindi4454 A registry of bindings the binding spec aintained on the OASIS website, 4455 linked from the asis-open.o /business-transaction). Any 4456 party may submit a binding specification and request its addition to this registry. The presence of 4457 an entry in the re , ply ratification or approval by OASIS or the BTP 4458 Technical Co4459

9.1 Carrie Proforma 4460

A BT ing informatio4461 Binding name 4462

A na in ed in the “binding name” field of BTP Addresses (and 4463 av de an implementation). Binding specified in this 4464

future revisions of this document have binding names that are simple 4465 strings of letters, numbers and hyphens (and, in particular, do not contain colons). 4466 Bindings specified elsewhere shall have binding names that are URIs. Bindings specified 4467 in this document use numbers to identify the version of the binding, not the version(s) of 4468 the Carrier Protocol. 4469

Binding address format 4470 This section states the format of the “binding address” field of a BTP Address for this 4471 binding. For many bindings, this will be a URL of some kind; for other bindings it may be 4472 some other form 4473

BTP message representation 4474 This section will define how BTP messages are represented. For many bindings, the BTP 4475 message syntax will be as specified in the XML schema defined in this document, and 4476 the normal string encoding of that XML will be used. 4477

Mapping for BTP messages (unrelated) 4478 This section will define how BTP messages that are not related to Application Messages 4479 are sent in either direction between Superior and Inferior (i.e. those messages sent 4480 directly between BTP Actors). This mapping need not be symmetric (i.e. Superior to 4481 Inferior may differ to some degree to Inferior to Superior). The mapping may define 4482 particular rules for particular BTP messages, or messages with particular parameter 4483 values (e.g. the FAULT message with “fault-type” “CommunicationFailure” will typically 4484 not be sent as a BTP message). The mapping states any constraints or requirements on 4485 which BTP may or must be bundled together by compounding. 4486

Mapping for BTP messages related to Application Messages 4487 This section will define how BTP messages that are related to Application Messages are 4488 sent. A binding specification may defer details of this to a particular application (e.g. a 4489 mapping specification could just say “the CONTEXT may be carried as a parameter of an 4490

notion of bindings is introdu ed to act as the glue bet messages and an rlying tran port. A binding specification of how the BTP

sages are carried and some aspects of h sages are carriepecifies two bindings inding and a SOAP +indings could be spe e Oasis BTP technica

example, in e future a bin

such specific tions are complete, the Bin Proforma defines the inform tion that must ng specification.

, with links to ifications is mBTP page (http://www.o rg/committees

gistry does not, of itself immmittee.

r Protocol Binding P carrier binding specification should provide the follow n:

me for the bind g, as usailable for claring the capabilities of

document, and


application invocation”). Alternatively, the binding may specify a general method that 4491 represents the relationship between application and BTP messages. 4492

Implicit messages 4493 This section specifies which BTP messages, if any, are not sent explicitly but are treated 4494 as implicit in carrier-protocol mechanisms, Application Messages or other BTP 4495 messages. This may depend on particular parameter values of the BTP messages or the 4496 Application Messages. 4497

Faults 4498 The relationship between the fault and exception reporting mechanisms of the Carrier 4499 Protocol and of BTP shall be defined. This may include definition of which Carrier 4500 Protocol exceptions are equivalent to a FAULT/communication-failure message. 4501

Relationship to other bindings 4502 Any relationship to other bindings is defined in this section. If BTP Addresses with 4503 different bindings are be considered to match (for purposes of identifying the Peer 4504 Superior/Inferior and redirection), this should be specified here. 4505

Limitations on BTP use 4506 Any limitations on the full range of BTP functionality that are imposed by use of this 4507 binding should be listed. This would include limitations on which messages can be sent, 4508 which event sequences are supported and restrictions on parameter values. Such 4509 limitations may reduce the usefulness of an implementation, but may be appropriate in 4510 certain environments. 4511

Other 4512 inding, especially any that will potentially affect interoperation, 4513

cified here. This may include restrictions or requireme s on the use or 4514 er parameters or mechanisms or use of stan r other 4515

qualifiers. 4516

9.2 Bindings for request/response Carrier Protocols 4517

BTP does not ge sponse pattern. In particular, on the Outcome 4518 Relationship either te a message – ntial part of the presume-abort 4519 recovery paradigm to reco owever, there are some BTP 4520 messages, especially in the Control Relationship, that do have a request/response pattern. Many 4521 (potential) Carri ) do have a request/response pattern. The specification of 4522 a binding specifica e Carrier Protocol needs to state what 4523 whic c , which by responses. The simp4524 BTP messages ck empty. This would be 4525 inefficient in us s, and po hen used for the BTP 4526 request/resp4527 This secti et of rules that allow more efficient use of the carrier, while allowing the 4528 initiator of a onse pair to ensure he BTP response is sent back on the carrier 4529 response. s are specified in this section to enable binding specifications to reference 4530 them, w each binding specification to repeat similar information. These rules also 4531 allow the receiver of a message between Superior and Inferior (in either direction) on a Carrier 4532 Protocol request to send any reply message on the carrier response – the “sender-address” field 4533 is implicitly considered to be that of the sender of the carrier request. 4534 A bin quest/response carrier is not required to use these rules. It may define other 4535 rules. 4536

Other features of the bsh ntsu dard o

nerally follow a request/reside may initia this is an essealthough it is not limited very cases. H

er Protocols (e.g. HTTPtion to a request/respons rules apply –

h messages an be carried by requests lest rule is to send all on requests, and let the carrier responses travel ba

e of network resource ssibly inconvenient wonse pairs.

on defines a s BTP reques t

These ruleithout requiring

ould be spepport of optional carri

t/resp

ding to a re


9.2.1 Request/response exploitation rules 4537

These rules allow implementations to use the request and response of the Carrier Protocol 4538 efficiently, and, when a BTP request/response exchange occurs, to either treat the 4539 request/response exchanges of the Carrier Protocol and of BTP independently, if both sides wish, 4540 or allow either side to map them closely. 4541 Under these rules, an implementation sending a BTP request (i.e. a message, other than 4542 CONTEXT, which has “reply-address” as a parameter in the abstract message definition) can 4543 ensure that it and the reply map to a carrier request/response by supplying no value for the 4544 “reply-address”. An implementation receiving such a request is required to send the BTP 4545 response on the carrier response. 4546 Conversely, if an implementation does supply a “reply-address” value on the request, the receiver 4547 has the option of sending the BTP response back on the carrier response, or sending it on a new 4548 carrier request. 4549 Within the Outcome Relationship, apart from ENROL, there is no “reply-address”, and the parties 4550 normally know each other’s “superior-address” and “inferior-address”. However, these messages 4551 have a “sender-address”, which is used when the receiver does not have knowledge of the Peer. 4552 In this case, the “sender-address” is treated as the “reply-address” of the other messages – if the 4553 field is absent in a message on a carrier request, the “sender-address” is implicitly that of the 4554 request sender. Any message for the Peer (including the three messages mentioned, but also 4555 FAULT and any other valid message in the Superior:Inferior relationship) may be sent on the 4556 carrier response. Apart from this, both sides are permitted to treat the carrier request/response 4557 exchanges as opportunities for sending messages to the appropriate destination. 4558 The rules: 4559

a) A BTP Actor may bundle one or more BTP messages and related groups that have the 4560 same binding address for their target in a single btp:messages and transmit this 4561 btp:messages element on a Carrier Protocol request. There is no restriction on which 4562 combinations of messages and groups may be so bundled, other than that they have the 4563 same binding address, and that this binding address is usable as the destination of a 4564 Carrier Protocol request. 4565

b) A BTP Actor that has received a Carrier Protocol request to which it has not yet 4566 responded, and which has one or more BTP messages and groups whose binding 4567 address for the target matches the origin of the carrier request may bundle such BTP 4568 messages in a single btp:messages element and transmit that on the Carrier Protocol 4569 response. 4570

c) A BTP Actor that has received, on a Carrier Protocol request, one or more BTP 4571 messages or related groups that require a BTP response and for which no “reply-4572 address” was supplied, must bundle the responding BTP message and groups in a 4573 btp:messages element and transmit this element on the Carrier Protocol response to the 4574 request that carried the BTP request. 4575

d) A BTP Actor that has received, on a Carrier Protocol request, one or more BTP 4576 messages or related groups that, as abstract messages, have a “sender-address” 4577 parameter but no “reply-address” was supplied, and which does not have knowledge of 4578 the Peer address, must bundle the responding BTP message and groups in a 4579 btp:messages element and transmit this element on the Carrier Protocol response to the 4580 request that carried the BTP request. If the Actor does have knowledge of the Peer 4581 address it may send one or messages for the Peer in the Carrier Protocol response, 4582 regardless of whether the binding address of the Peer matches the address of the Carrier 4583 Protocol requestor. 4584

e) Where only one message or group is to be sent, it must be contained within a 4585 btp:messages element, as a bundle of one element. 4586


f) A BTP Actor that receives a Carrier Protocol request carrying BTP messages that do 4587 have a “reply-address”, or which initiate processing that produces BTP messages whose 4588 target binding address matches the origin of the request, may freely choose whether to 4589 use the Carrier Protocol response for the replies, or to send back an “empty Carrier 4590 Protocol response”, and send the BTP replies in a separately initiated Carrier Protocol 4591 request. The characteristics of an “empty Carrier Protocol response” shall be stated in the 4592 particular binding specification. 4593

g) A BTP Actor that sends BTP messages on a Carrier Protocol request must be able to 4594 accept returning BTP messages on the corresponding Carrier Protocol response and, if 4595 the Actor has offered an address on which it will receive carrier requests, must be able to 4596 accept “replying” BTP messages on a separate Carrier Protocol request. 4597

9.3 SOAP Binding 4598

This binding describes how BTP messages will be carried using SOAP as in the [SOAP 1.1] 4599 specification, using the SOAP literal messaging style conventions. If no Application Message is 4600 sent at the same time, the BTP messages are contained within the SOAP Body element. If 4601 Application Messages are sent, the BTP messages are contained in the SOAP Header element. 4602 Binding name 4603

soap-http-1 4604

Binding address format 4605 shall be a URL, of scheme http or https. 4606

BTP message representation 4607 The string representation of the XML, as specified in the XML schema defined in this 4608 document shall be used. The BTP XML messages are embedded in the SOAP message 4609 without the use of any specific encoding rules (literal style SOAP message); hence the 4610 encodingStyle attribute need not be set or can be set to an empty string. 4611

Mapping for BTP messages (unrelated) 4612 The “request/response exploitation” rules shall be used. 4613

BTP messages sent on an HTTP request or HTTP response which is not carrying an 4614 Application Message, the messages are contained in a single btp:messages element 4615 which is the immediate child element of the SOAP Body element. 4616

An “empty Carrier Protocol response” sent after receiving an HTTP request containing a 4617 btp:messages element in the SOAP Body, when the implementation chooses just to reply 4618 at the lower level (and when the request/response exploitation rules allow an empty 4619 Carrier Protocol response), shall be any of: 4620

• an empty HTTP response 4621 • an HTTP response containing an empty SOAP Envelope 4622 • an HTTP response containing a SOAP Envelope containing a single, empty 4623

btp:messages element. 4624 The receiver (the initial sender of the HTTP request) shall treat these in the same way – 4625 they have no effect on the BTP sequence (other than indicating that the earlier sending 4626 did not cause a communication failure.) 4627

If an Application Message is being sent at the same time, the mapping for related 4628 messages shall be used, as if the BTP messages were related to the Application 4629 Message. (There is no ambiguity in whether the BTP messages are related, because 4630 only CONTEXT and ENROL can be related to an Application Message.) 4631

Mapping for BTP messages related to Application Messages 4632


All BTP messages sent with an Application Message, whether related to the Application 4633 Message or not, shall be sent in a single btp:messages element in the SOAP Header. 4634 There shall be precisely one btp:messages element in the SOAP Header. 4635

The “request/response exploitation” rules shall apply to the BTP messages carried in the 4636 SOAP Header, as if they had been carried in a SOAP Body, unrelated to an Application 4637 Message, sent to the same binding address. 4638

Note 1 – The Application Protocol itself (which is using the SOAP Body) may use the 4639 SOAP RPC or document approach – this is determined by the application. 4640

Only CONTEXT and ENROL messages are related (&) to Application Messages. If there 4641 is only one CONTEXT or one ENROL message present in the SOAP Header, it is 4642 assumed to be related to the whole of the Application Message in the SOAP Body. If 4643 there are multiple CONTEXT or ENROL messages, any relation of these BTP messages 4644 shall be indicated by application specific means. 4645

Note 2 – An Application Protocol could use references to the ID values of the BTP 4646 messages to indicate relation between BTP CONTEXT or ENROL messages and the 4647 Application Message. 4648

Note 3 -- However indicated, what the relatedness means, or even whether it has any 4649 significance at all, is a matter for the application. 4650

Implicit messages 4651 A SOAP FAULT, or other communication failure received in response to a SOAP request 4652 that had a CONTEXT in the SOAP Header shall be treated as if a 4653 CONTEXT_REPLY/repudiated had been received. See also the discussion under “other” 4654 about the SOAP mustUnderstand attribute. 4655

Faults 4656 A SOAP FAULT or other communication failure shall be treated as 4657 FAULT/communication-failure. 4658

Relationship to other bindings 4659 A BTP Address for Superior or Inferior that has the binding string “soap-http-1” is 4660 considered to match one that has the binding string “soap-attachments-http-1” if the 4661 binding address and additional information fields match. 4662

Limitations on BTP use 4663 None 4664

Other 4665 The SOAP BTP binding does not make use of SOAPAction HTTP header or actor 4666 attribute. The SOAPAction HTTP header is left to be application specific when there are 4667 Application Messages in the SOAP Body, as an already existing web service that is being 4668 upgraded to use BTP might have already made use of SOAPAction. The SOAPAction 4669 HTTP header shall contain no value when the SOAP message carries only BTP 4670 messages in the SOAP Body. 4671

The SOAP mustUnderstand attribute, when used on the btp:messages containing a BTP 4672 CONTEXT, ensures that the receiver (server, as a whole) supports BTP sufficiently to 4673 determine whether any enrolments are necessary and replies with CONTEXT_REPLY as 4674 appropriate. The sender of the CONTEXT (and related Application Message) can use this 4675 to ensure that the application work is performed as part of the Business Transaction, 4676 assuming the receiver’s SOAP implementation supports the mustUnderstand attribute. If 4677 mustUnderstand is false, a receiver can ignore the CONTEXT (if BTP is not supported 4678 there), and no CONTEXT_REPLY will be returned. It is a local option on the sender 4679 (Client) side whether the absence of a CONTEXT_REPLY is assumed to be equivalent to 4680


a CONTEXT_REPLY/ok (and the Business Transaction is allowed to proceed to 4681 confirmation). 4682

Note – some SOAP implementations may not support the mustUnderstand attribute 4683 sufficiently to enforce these requirements. 4684

9.3.1 Example scenario using SOAP binding 4685

The example below shows an application request with CONTEXT message sent from 4686 client.example.com (which includes the Superior) to services.example.com (Service). 4687

<soap:Envelope 4688 xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" 4689 soap:encodingStyle=""> 4690 <soap:Header> 4691 <btp:messages xmlns:btp="http://docs.oasis-4692 open.org/business_transaction/business_transaction-btp-1.1-core-schema-4693 wd-05.xsd"> 4694 <btp:context> 4695 <btp:superior-address> 4696 <btp:binding>soap-http-1</btp:binding> 4697 <btp:binding-4698 address>http://client.example.com/soaphandler</btp:binding-address> 4699 <btp:additional-information>btpengine</btp:additional-4700 information> 4701 </btp:superior-address> 4702 <btp:superior-identifier>http://example.com/1001</btp:superior-4703 identifier> 4704 <btp:superior-type>atom</btp:superior-type> 4705 <btp:qualifiers> 4706 <btpq:transaction-timelimit xmlns:btpq=” http://docs.oasis-4707 open.org/business_transaction/business_transaction-btp-1.1-qualifiers-4708 schema-wd-4709 05.xsd”><btpq:timelimit>1800</btpq:timelimit></btpq:transaction-4710 timelimit> 4711 </btp:qualifiers> 4712 </btp:context> 4713 </btp:messages> 4714 </soap:Header> 4715 <soap:Body> 4716 <ns1:orderGoods 4717 xmlns:ns1="http://example.com/2001/Services/xyzgoods"> 4718 <custID>ABC8329045</custID> 4719 <itemID>224352</itemID> 4720 <quantity>5</quantity> 4721 </ns1:orderGoods> 4722 </soap:Body> 4723 </soap:Envelope> 4724

4725 The example below shows CONTEXT_REPLY and a related ENROL message sent from 4726 services.example.com to client.example.com, in reply to the previous message. There is no 4727 application response, so the BTP messages are in the SOAP Body. The ENROL message does 4728 not contain the target-additional-information, since the grouping rules for CONTEXT_REPLY & 4729 ENROL omit the “target-address” (the receiver of this example remembers the superior address 4730 from the original CONTEXT) 4731

<soap:Envelope 4732 xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" 4733 soap:encodingStyle=""> 4734 <soap:Header> 4735 </soap:Header> 4736 <soap:Body> 4737

<btp:messages xmlns:btp="http://docs.oasis-4738 open.org/business_transaction/business_transaction-btp-1.1-core-schema-4739 wd-05.xsd"> 4740 <btp:related-group> 4741 <btp:context-reply> 4742 <btp:target-additional-information>btpengine</btp:target-4743 additional-information> 4744 <btp:superior-identifier>http://example.com/1001</btp:superior-4745 identifier> 4746 <completion-status>related</completion-status> 4747 </btp:context-reply> 4748 <btp:enrol> 4749 <btp:superior-4750 identifier>http://example.com/1001</btp:superior-identifier> 4751 <btp:response-requested>false</btp:response-requested> 4752 <btp:inferior-address> 4753 <btp:binding>soap-http-1</btp:binding> 4754 <btp:binding-address> 4755 http://services.example.com/soaphandler 4756 </btp:binding-address> 4757 </btp:inferior-address> 4758 <btp:inferior-identifier> 4759 http://example.com/AAAB 4760 </btp:inferior-identifier> 4761 <btp:target-additional-information>btpengine</btp:target-4762 additional-information> 4763 </btp:enrol> 4764 </btp:related-group> 4765 </btp:messages> 4766 </soap:Body> 4767 </soap:Envelope> 4768

4769

9.4 SOAP + Attachments Binding 4770

This binding describes how BTP messages will be carried using SOAP as in the [SOAP 4771 Attachments] specification. It is a superset of the Basic SOAP binding, soap-http-1. The two 4772 bindings only differ when Application Messages are sent. 4773 Binding name 4774

soap-attachments-http-1 4775

Binding address format 4776 as for soap-http-1 4777

BTP message representation 4778 As for soap-http-1 4779

Mapping for BTP messages (unrelated) 4780 As for “soap-http-1”, except the SOAP Envelope containing the SOAP Body containing 4781 the BTP messages shall be in a MIME body part, as specified in SOAP Messages with 4782 Attachments specification. If an Application Message is being sent at the same time, the 4783 mapping for related messages for this binding shall be used, as if the BTP messages 4784 were related to the Application Message(s). 4785

Mapping for BTP messages related to Application Messages 4786 MIME packaging shall be used. One of the MIME multipart/related parts shall contain a 4787 SOAP Envelope, whose SOAP Headers element shall contain precisely one 4788 btp:messages element, containing any BTP messages. Any BTP CONTEXT in the 4789 btp:messages is considered to be related to the Application Message(s) in the SOAP 4790

Body, and to also any of the MIME parts referenced from the SOAP Body (using the 4791 “href” attribute). 4792

Implicit messages 4793 As for soap-http-1. 4794

Faults 4795 As for soap-http-1. 4796

Relationship to other bindings 4797 A BTP Address for Superior or Inferior that has the binding string “soap-http-1” is 4798 considered to match one that has the binding string “soap-attachements-http-1” if the 4799 binding address and additional information fields match. 4800

Limitations on BTP use 4801 None 4802

Other 4803 As for soap-http-1 4804

9.4.1 Example using SOAP + Attachments binding 4805 Content-Type: Multipart/Related; boundary=MIME_boundary; type=text/xml; 4806 start="someID" 4807 --MIME_boundary 4808 Content-Type: text/xml; charset=UTF-8 4809 Content-ID: someID 4810 <?xml version='1.0' ?> 4811 <soap:Envelope 4812 xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" 4813 soap:encodingStyle=" "> 4814 <soap:Header> 4815 <btp:messages xmlns:btp="http://docs.oasis-4816 open.org/business_transaction/business_transaction-btp-1.1-core-schema-4817 wd-05.xsd"> 4818 <btp:context> 4819 <btp:superior-address> 4820 <btp:binding>soap-http-1</btp:binding> 4821 <btp:binding-address> 4822 http://client.example.com/soaphandler 4823 </btp:binding-address> 4824 </btp:superior-address> 4825 <btp:superior-identifier>http://example.com/1001</btp:superior-4826 identifier> 4827 <btp:superior-type>atom</btp:superior-type> 4828 </btp:context> 4829 </btp:messages> 4830 </soap:Header> 4831 <soap:Body> 4832 <orderGoods href="cid:anotherID"/> 4833 </soap:Body> 4834 </soap:Envelope> 4835 --MIME_boundary 4836 Content-Type: text/xml 4837 Content-ID: anotherID 4838 <ns1:orderGoods 4839 xmlns:ns1="http://example.com/2001/Services/xyzgoods"> 4840 <custID>ABC8329045</custID> 4841 <itemID>224352</itemID> 4842 <quantity>5</quantity> 4843 </ns1:orderGoods> 4844

4845 --MIME_boundary— 4846

4847

9.5 11.5 WSDL-friendly one-way binding 4848

This binding avoids any compounding, placing one message in each HTTP request. All 4849 messages are transmitted in the same way – the request/response exploitation rules are not 4850 used. This makes it straight-forward to represent the BTP protocol using WSDL, as constrained 4851 by the [WS-I Basic Profile 1.0]. 4852 Binding name 4853

wsdl-friendly-one-way-1 4854

Binding address format 4855 shall be a URL, of type HTTP or HTTPS. 4856

BTP message representation 4857 The string representation of the XML, as specified in the XML schema referenced by the 4858 BTP 1.1 spec shall be used. The BTP XML messages are embedded in the SOAP 4859 message without the use of any specific encoding rules (literal style SOAP message). 4860

Note -- the btp:messages and btp:related-group elements are NOT used in this binding. 4861

Mapping for BTP messages (unrelated) 4862 A single BTP message shall be sent as the sole child-element of Body of a SOAP 4863 message sent on an HTTP request. (only). The HTTP response shall be empty or shall 4864 contain an empty SOAP message. 4865

BTP FAULT messages are sent in the same way as other BTP messages, as the sole 4866 child-element of a SOAP Body. 4867

Mapping for BTP messages related to Application Messages 4868 When the association between a BTP CONTEXT, CONTEXT-REPLY or ENROL 4869 message and an Application Message is to be represented by the SOAP layer, the BTP 4870 message shall be an immediate child of the SOAP Header element (i.e. it shall be a 4871 header in its own right). There may be more than one BTP message as a child element of 4872 the SOAP Header element. (The association may be represented by other means, such 4873 as embedding the BTP message in the application message – this would be invisible to 4874 this binding). 4875

A CONTEXT-REPLY message appearing in a SOAP header shall be deemed to be in a 4876 (abstract) related group with any ENROL messages with the same superior-identifier in 4877 the SOAP message. 4878

Implicit messages 4879 A SOAP FAULT, or other communication failure received in response to a SOAP request 4880 that had a CONTEXT in the SOAP Header shall be treated as if a 4881 CONTEXT_REPLY/repudiated had been received. See also the discussion under “other” 4882 about the SOAP mustUnderstand attribute. 4883

Faults 4884 A SOAP FAULT or other communication failure shall be treated as 4885 FAULT/communication-failure. 4886

Relationship to other bindings 4887 None 4888

Limitations on BTP use 4889


Bundling is not supported in this binding – BTP messages that are not semantically 4890 related have to be sent on separate HTTP requests. 4891

Related-grouping is not supported in this binding for BTP messages to be sent in the 4892 SOAP Body (i.e. other than in combination with application messages) and only 4893 CONTEXT, CONTEXT-REPLY and ENROL can be related when sent in the header. 4894

Other 4895 An implementation or service may offer this binding in all its roles or could use this 4896 binding on some and other bindings on other roles (e.g this binding as Factory and 4897 Decider, soap-http-1 as Superior and Inferior). It may also use this binding for the 4898 actor:actor relationships and some other binding when sending BTP messages 4899 associated with application messages. In this latter case, the “binding” could be a part of 4900 the application protocol specification and need not be identified as a distinct BTP binding 4901 in any way. 4902

WSDL specifications with the target namespaces - 4903 • http://docs.oasis-open.org/business-transaction/business_transaction-btp-1.1-abstract-wsdl-4904

wd-05.wsdl 4905 • http://docs.oasis-open.org/business-transaction/business_transaction-btp-1.1-soap_binding-4906

wsdl-wd-05.wsdl 4907 • http://docs.oasis-open.org/business-transaction/business_transaction-btp-1.1-soap_services-4908

wsdl-wd-05.wsdl 4909 - accessible at those URLs, are intended to correspond to this binding. These wsdl documents 4910 form an integral but informative part of this specification. The three documents are: 4911 • Abstract WSDL definitions of portytpes corresponding to the roles defined in BTP 4912 • SOAP bindings to ports for each of these PortTypes 4913 • Partial Service definitions for the combinations of Ports that will typically be combined. They 4914

are partial because they do not include target addresses 4915


10 Conformance 4916

A BTP implementation need not implement all aspects of the protocol to be useful. The level of 4917 conformance of an implementation is defined by which roles it can support using the specified 4918 messages and Carrier Protocol bindings for interoperation with other implementations. 4919 An implementation may implement some roles and relationships in accordance with this 4920 specification, while providing the (approximate) functionality of other roles in some other manner. 4921 (For example, an implementation might provide an equivalent of the Control Relationships using a 4922 language-specific API, but support roles involved in the Outcome Relationships using standard 4923 BTP messages.) Such an implementation is conformant in respect of the roles it does implement 4924 in accordance with this specification. 4925 An implementation can state which aspects of the BTP specification it conforms to in terms of 4926 which Roles it supports. Since most Roles cannot usefully be supported in isolation, the following 4927 Role Groups can be used to describe implementation capabilities: 4928

Role Group Roles

Initiator/Terminator Initiator Terminator

Cohesive Hub Factory Composer (as Decider and Superior) Coordinator (as Decider and Superior) Sub-composer Sub-coordinator

Atomic Hub Factory Coordinator Sub-coordinator

Cohesive Superior Composer (as Superior only) Sub-Composer Coordinator (as Superior only) Sub-coordinator

Atomic Superior Coordinator (as Superior only)) Sub-coordinator

Participant Inferior Enroller

4929 The Role Groups occupy different positions within a Business Transaction Tree and thus require 4930 presence of implementations supporting other Role Groups: 4931 • Initiator/Terminator uses Control Relationship to Atomic Hub or Cohesive Hub to initiate and 4932

control Atoms or Cohesions. Initiator/Terminator would typically be a library linked with 4933 application software. 4934

• Atomic Hub and Cohesive Hub would often be standalone servers. 4935


• Cohesive Superior and Atomic Superior would provide the equivalent of Initiator/Terminator 4936 functionality by internal or proprietary means. 4937

• Cohesive Hubs, Atomic Hubs, Cohesive Superior and Atomic Superior use Outcome 4938 Relationships to Participants and to each other. 4939

• Participants will establish Outcome Relationships to implementations of any of the other Role 4940 Groups except Initiator/Terminator. A Participant “covers” a resource or application work of 4941 some kind. It should be noted that a Participant is unaffected by whether it is enrolled in an 4942 Atom or Cohesion – it gets only a single outcome. 4943

An implementation may support one or more Role Groups. The following combinations are 4944 defined as commonly expected conformance profiles, although other combinations or selections 4945 are equally possible. 4946

Conformance Profile Role Groups

Participant Only Participant

Atomic Atomic Superior Participant

Cohesive Cohesive Superior Participant

Atomic Coordination Hub

Initiator/Terminator Atomic Hub Participant

Cohesive Coordination Hub

Initiator/Terminator Cohesive Hub Participant

4947 BTP has several features, such as optional parameters, that allow alternative implementation 4948 architectures. Implementations should pay particular attention to avoid assuming their peers have 4949 made the same implementation options as they have (e.g. an implementation that always sends 4950 ENROL with the same inferior address and with the “reply-address” absent (because the Inferior 4951 in all transactions are dealt with by the same addressable entity), must not assume that the same 4952 is true of received ENROLs) 4953


11 References 4954

11.1 Normative 4955

[RFC2119] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, 4956 http://www.ietf.org/rfc/rfc2119.txt, IETF RFC 2119, March 1997. 4957

[SOAP 1.1] D. Box et al, Simple Object Access Protocol (SOAP) 1.1, 4958 http://www.w3.org/TR/soap/, W3C Note, May 2000 4959

[SOAP Attachments] J.J.Barton, S. Thatte, H.F.Nielsen, SOAP Messages with 4960 Attachments, http://www.w3.org/TR/SOAP-attachments , W3C Note, 4961 December 2000 4962

[WS-I Basic Profile 1.0] K.Ballinger et al, Basic Profile Version 1.0, http://www.ws-4963 i.org/Profiles/BasicProfile-1.0.html, WS-I, April 2004 4964

4965


Appendix A. Acknowledgments 4966

The followi bers of the committee during the development of this 4967 specification. Where members changed their affiliation, their latest affiliation is shown: 4968 • Mark Little, Arjuna Technology Ltd. 4969 • William Cox, BEA Systems, Inc. 4970 • Sanjay Dalal, BEA Systems, Inc. 4971 • Pal Takacsi-Nagy, BEA Systems, Inc. 4972 • Rocky Stewart, BEA Systems, Inc. 4973 • Sazi Temel, BEA Systems, Inc. 4974 • Ed Felt, BEA Systems, Inc. 4975 • James Tauber, mValent 4976 • Tony Fletcher, Choreology Ltd 4977 • Peter Furniss, Choreology Ltd 4978 • Alastair Green, Choreology Ltd 4979 • Bob Haugen, Choreology Ltd 4980 • Roddy Herries, Choreology Ltd 4981 • Mike Abbott, CodeMetamorphosis 4982 • Alex Berson, Entrust, Inc 4983 • Victor Corrales, Hewlett-Packard Co. 4984 • Savas Parastatidis, Hewlett-Packard Co. 4985 • Jim Webber, Hewlett-Packard Co. 4986 • Fred Carter, individual (previously Sun Microsystems) 4987 • Alex Ceponkus, individual (previously Bowstreet) 4988 • Bill Pope, individual (previously Bowstreet) 4989 • Gordon Hamilton, individual (previously Applied Theory) 4990 • Steve Viens, individual 4991 • Mark Hale, Interwoven Inc. 4992 • Pyounguk Cho, Iona 4993 • Hatem El-Sebaaly, IPNet 4994 • Geoff Brown, Oracle 4995 • Martin Chapman, Oracle 4996 • Anne Manes, Systinet 4997 • Alan Davies, SeeBeyond Inc. 4998 • Steve White, SeeBeyond Inc. 4999 • Doug Bunting, Sun Microsystems 5000 • Bill Flood, Sybase 5001 • Mark Potts, Talking Blocks 5002

In memory of Ed Felt

ng individuals were mem

5003 Ed Felt of BEA Systems Inc. was an active and highly valued contributor to the work of the 5004

OASIS Business Transactions Technical Committee. 5005 His many years of design and implementation experience with the Tuxedo system, WebLogic’s 5006 Java transactions, and Weblogic Integration’s Conversation Management Protocol were brought 5007

to bear in his comments on and proposals for this specification. 5008 He was killed in the crash of the hijacked United Airlines flight 93 near Pittsburgh, 5009

on 11 September 2001. 5010

5011



Appendix B. Revision History 5012

Rev Version Date By Whom What

BTP 1.0 2002-06-03 BT TC Committee Specification BTP 1.0

wd-01 1.0.9.1 2004-05-05 Peter Furniss Included all agreed technical changes of that date, change-marked by issue

wd-02 1.0.9.2 2004-08-27 Peter Furniss Included all agreed technical changes of that date, change-marked by issue

wd-03 1.0.9.3 2004-09-28 Peter Furniss Previous changes accepted, and new agreed and proposed technical changes applied, up to and including maint-17. XML schemas moved to separate documents

wd-04 1.0.9.4 2004-10-25 Peter Furniss, Bob Haugen

Changed to OASIS template, copying the text in and modifying the non-technical sections; reviewed Part 1 and aligned with agreed changes in Part 2

wd-05 1.0.9.4 2004-11-09 Peter Furniss Corrected two cells in Table 11, state S1. Applied XML colouring to example sections. Ready for CD vote.

5013


Appendix C. Notices 5014

OASIS takes no position regarding the validity or scope of any intellectual property or other rights 5015 that might be claimed to pertain to the implementation or use of the technology described in this 5016 document or the extent to which any license under such rights might or might not be available; 5017 neither does it represent that it has made any effort to identify any such rights. Information on 5018 OASIS's procedures with respect to rights in OASIS specifications can be found at the OASIS 5019 website. Copies of claims of rights made available for publication and any assurances of licenses 5020 to be made available, or the result of an attempt made to obtain a general license or permission 5021 for the use of such proprietary rights by implementors or users of this specification, can be 5022 obtained from the OASIS Executive Director. 5023 OASIS invites any interested party to bring to its attention any copyrights, patents or patent 5024 applications, or other proprietary rights which may cover technology that may be required to 5025 implement this specification. Please address the information to the OASIS Executive Director. 5026 Copyright © OASIS Open 2002, 2003, 2004. All Rights Reserved. 5027 This document and translations of it may be copied and furnished to others, and derivative works 5028 that comment on or otherwise explain it or assist in its implementation may be prepared, copied, 5029 published and distributed, in whole or in part, without restriction of any kind, provided that the 5030 above copyright notice and this paragraph are included on all such copies and derivative works. 5031 However, this document itself does not be modified in any way, such as by removing the 5032 copyright notice or references to OASIS, except as needed for the purpose of developing OASIS 5033 specifications, in which case the procedures for copyrights defined in the OASIS Intellectual 5034 Property Rights document must be followed, or as required to translate it into languages other 5035 than English. 5036 The limited permissions granted above are perpetual and will not be revoked by OASIS or its 5037 successors or assigns. 5038 This document and the information contained herein is provided on an “AS IS” basis and OASIS 5039 DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO 5040 ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 5041 RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 5042 PARTICULAR PURPOSE. 5043


Appendix D. Node State Information Serialisation 5044

This Appendix is informational. 5045 This Appendix provides a simple, but standardized, format for the serialised essential state 5046 information of a BTP Node. It does not specify the events that would cause serialisation to take 5047 place, nor does it specify how this serialisation format is extracted from a BTP Node and 5048 transferred elsewhere. The format is specified in abstract form and as an XML Schema. 5049

D.1 Abstract Format for Node State Information 5050

The node state information represents the BTP state information for a single BTP Node in some 5051 Transaction Tree. It contains information for a single transaction that was extant at the BTP Node 5052 at the time the serialisation was performed. 5053

Parameter Sub-Parameter Type

date and time Date and Time Role composer/coordinator/sub-

composer/sub-coordinator/participant

own information transaction type cohesion/atom

own-identifier Identifier

own-address Set of BTP Addresses information as inferior

transaction type cohesion/atom

inferior-state-identification

State identifier

superior’s identifier Identifier

superior’s address Set of BTP Addresses

Qualifiers List of qualifiers Set of information as superior

superior-state-identification

State identifier

inferior’s identifier Identifier

inferior’s address Set of BTP Addresses

Qualifiers List of qualifiers

5054 date and time 5055

the date and time that this node state information was generated to an agreed resolution 5056 and accuracy. The presence of this information is optional. 5057

role 5058


the type of the BTP Node. Its value is one of composer / coordinator / sub-composer / 5059 sub-coordinator / participant. 5060

own information 5061 identification information for this BTP Node. This information is required. It consists of 5062 the following information: 5063

transaction type 5064 the type of this part of the transaction propagated to inferiors. Its value is one of 5065 cohesion or atom. 5066

own identifier 5067 identifies this BTP Node. This may be the superior identifier from the CONTEXT 5068 for the node and/or the inferior identifier on the ENROL for the node. This shall 5069 be globally unambiguous. 5070

own address 5071 the address at which this BTP Node may be accessible. This can be a set of 5072 alternative addresses. 5073

information as inferior 5074 information relevant to the BTP Node’s Role as an inferior. Should be present, once 5075 only, if the BTP Node is a sub-composer or a sub-coordinator or a participant, otherwise 5076 absent. It includes information about the superior of this BTP Node and consists of the 5077 following information: 5078

transaction type 5079 the type of this part of the transaction that applies to the BTP Node acting as an 5080 inferior as indicated in the CONTEXT for the BTP Node. Its value is one of 5081 cohesion or atom. 5082

inferior-state-identification 5083 identifies the state of the inferior state machine at this BTP Node. This is 5084 represented as a small letter followed by a number, which designates the inferior 5085 state. Refer to the section on ‘State Tables’ and in particular Tables 6 and 12 - 5086 17. 5087

superior’s identifier 5088 identifies the Superior of this BTP Node. This shall be globally unambiguous. 5089

superior’s address 5090 the address to which ENROL and other messages from this enrolled Inferior were 5091 sent. This can be a set of alternative addresses. 5092

qualifiers 5093 list of the qualifiers and their values in force for this node as an inferior. 5094

set of information as superior 5095 information relevant to the node’s Role as superior. Should be present, if the BTP Node 5096 is a composer, coordinator, sub-composer, or a sub-coordinator, and shall be absent if 5097 the BTP Node is a participant. It may be present multiple times, once for each inferior 5098 that this BTP Node has a relationship with. It includes information about an inferior of this 5099 node and consists of the following information: 5100

superior-state-identification 5101 identifies the state of the superior state machine for this particular inferior. This is 5102 represented as a capital letter followed by a number, which designates the 5103

superior state. Refer to the section on ‘State Tables’ and in particular Tables 5 5104 and 7 - 11. 5105

inferior’s identifier 5106 identifies an Inferior of this BTP Node. This shall be globally unambiguous. 5107

inferior’s address 5108 the address to which PREPARE, CONFIRM, CANCEL and SUPERIOR_STATE 5109 messages for this Inferior have been or are to be sent. This can be a set of 5110 alternative addresses. 5111

qualifiers 5112 list of the qualifiers and their values in force for this BTP Node as superior to this 5113 inferior. 5114

D.2 Informal XML for Node State Information 5115

<btpst:node-information> 5116 5117 <btpst:date-time>2002-05-31T13:20:00.000-05:00</btpst:date-time> ? 5118 5119 <btpst:role>composer|coordinator|sub-composer| 5120 sub-coordinator|participant</btpst:role> ? 5121 5122 <btpst:own-information> 5123 <btpst:trx-type>cohesion|atom</btpst:trx-type> 5124 <btpst:own-identifier>...URI...</btpst:own-identifier> 5125 <btpst:own-address> + 5126 <btp:binding-name>...carrier binding name...</btp:binding-name> 5127 <btp:binding-address>...carrier specific 5128 address...</btp:binding-address> 5129 <btp:additional-information>...optional additional 5130 addressing information...</btp:additional-information> ? 5131 </btpst:own-address> 5132 </btpst:own-information> 5133 5134 <btpst:information-as-inferior> ? 5135 <btpst:trx-type>cohesion|atom</btpst:trx-type> 5136 <btpst:I_state>.. statename from inferior state table 5137 e.g. d1..</btpst:I_state> 5138 <btpst:superiors-identifier>...URI...</btpst:superiors-identifier> 5139 <btpst:superiors-address> + 5140 <btp:binding-name>...carrier binding name...</btp:binding-name> 5141 <btp:binding-address>...carrier specific 5142 address...</btp:binding-address> 5143 <btp:additional-information>...optional additional 5144 addressing information...</btp:additional-information> ? 5145 </btpst:superiors-address> 5146 <btp:qualifiers> ...qualifiers... </btp:qualifiers> ? 5147 </btpst:information-as-inferior> 5148 5149 <btpst:information-as-superior> + 5150 <btpst:S_state>.. statename from superior state table 5151 e.g. D1..</btpst:S_state> 5152 <btpst:inferiors-identifier>...URI...</btpst:inferiors-identifier> 5153 <btpst:inferiors-address> + 5154 <btp:binding-name>...carrier binding name...</btp:binding-name> 5155 <btp:binding-address>...carrier specific 5156 address...</btp:binding-address> 5157 <btp:additional-information>...optional additional 5158 addressing information...</btp:additional-information> ? 5159

</btpst:inferiors-address> 5160 <btp:qualifiers> ...qualifiers... </btp:qualifiers> ? 5161 </btpst:information-as-superior> 5162 5163 </btpst:node-information> 5164

D.3 XML schema for Node State Information 5165

The XML schema for the Node State Information, with namespace “http://docs.oasis-5166 open.org/business-transaction/business_transaction-btp-1.1-node-state-information-schema-wd-5167 05.xsd” is available at same URL. That schema document is to be considered as an integral part 5168 of this informative annex. 5169 5170

Business Transaction Protocol · 2004-11-10 · carriage of BTP messages over other communication...

Documents

Transcript of Business Transaction Protocol · 2004-11-10 · carriage of BTP messages over other communication...