ebXML Business Process Specification Schema · 2019-11-25 · 170 This document specifies a specification schema for execution of business processes. 171 This document describes the

1 2 3 4

ebXML Business Process Specification Schema 5

Version 0.90 6

7

8

Context/Metamodel Group 9

of the CC/BP Joint Delivery Team 10 11 12

01/17/2001 13 14 15

16 17

1 Status of this Document 18 19 This document is a working DRAFT for the eBusiness community. Distribution of this document 20 is unlimited. This document will go through the formal Quality Review Process as defined by the 21 ebXML Requirements Document. The formatting for this document is based on the Internet 22 Society’s Standard RFC format. 23 24 This version: 25 EbXML_BPschema_0.90 26 27 Latest version: 28

EbXML_BPschema_0.90 29 30 Previous version: 31 EbXML_BPschema_0.87 32 33 34

35

2 ebXML BP/CoreComponents metamodel participants 35 We would like to recognize the following for their significant participation to the development of 36 this document. 37 38 Team Lead: 39 Paul Levine, Telcordia 40 41 Editors: 42

Jim Clark, I.C.O.T. (previously Edifecs) 43 44 Karsten Riemer, Sun Microsystems 45 Cory Casanave, Data Access Technologies 46 47

Participants: 48 Antoine Lonjon, Mega 49 J.J. Dubray, Excelon 50 Bob Haugen, Logistical Software 51 Bill McCarthy, Michigan State University 52 Paul Levine, Telcordia 53 Brian Hayes, CommerceOne 54 Betty Harvey, Electronic Commerce Connection 55 Antonio Carrasco, Data Access Technologies 56

57

3 Table of Contents 57 1 Status of this Document ............................................................................................................i 58 2 ebXML BP/CoreComponents metamodel participants ...........................................................ii 59 3 Table of Contents.................................................................................................................... iii 60 4 Introduction.............................................................................................................................vi 61

Executive Summary....................................................................................................................vi 62 4.1 Summary of Contents of Document ............................................................................... 1 63 4.2 Audience ......................................................................................................................... 1 64 4.3 Related Documents ......................................................................................................... 1 65 4.4 Prerequisites.................................................................................................................... 1 66

5 Design Objectives ................................................................................................................... 1 67 5.1 Goals/Objectives/Requirements/Problem Description ................................................... 1 68 5.2 Caveats and Assumptions ............................................................................................... 2 69 5.3 Metamodel Architecture ................................................................................................. 2 70

6 System Overview .................................................................................................................... 5 71 UML Specification Schema ........................................................................................................ 5 72 DTD Specification Schema......................................................................................................... 5 73 Business Process Interaction Patterns ......................................................................................... 5 74 Common Interaction Pattern Modeling Elements....................................................................... 5 75 Production Rules......................................................................................................................... 5 76 6.1 What the ebXML Business Process Specification Schema Does ................................... 6 77 6.2 How the ebXML Business Process Specification Schema Works ................................. 7 78

6.2.1 Core Business Transaction Semantics .................................................................. 10 79 6.2.2 Response patterns.................................................................................................. 12 80 6.2.3 Timeouts................................................................................................................ 13 81 6.2.4 ControlException.................................................................................................. 14 82 6.2.5 Business Protocol Exceptions (a.k.a. ProcessException) ..................................... 14 83 6.2.6 Security Parameters............................................................................................... 15 84 6.2.7 Concurrency.......................................................................................................... 17 85 6.2.8 Reliability.............................................................................................................. 18 86 6.2.9 Synchronous or Asynchronous ............................................................................. 18 87

6.3 Where the ebXML Specification Schema May Be Implemented................................. 18 88 7 Specification Element Overview .......................................................................................... 18 89

7.1 Business Collaborations ................................................................................................ 19 90 7.1.1 MultiPartyCollaboration ....................................................................................... 19 91 7.1.2 BusinessPartner ..................................................................................................... 19 92 7.1.3 Performs ................................................................................................................ 20 93 7.1.4 AuthorizingRole.................................................................................................... 20 94 7.1.5 BinaryCollaboration.............................................................................................. 21 95 7.1.6 BusinessActivity ................................................................................................... 21 96 7.1.7 BusinessTransactionActivity ................................................................................ 22 97 7.1.8 CollaborationActivity............................................................................................ 23 98

7.2 Business Transactions ................................................................................................... 23 99 7.2.1 BusinessTransaction.............................................................................................. 23 100 7.2.2 RequestingBusinessActivity ................................................................................. 24 101

7.2.3 RespondingBusinessActivity................................................................................ 25 102 7.3 Message Exchange ........................................................................................................ 26 103

7.3.1 DocumentEnvelope ............................................................................................... 26 104 7.3.2 DocumentSet ......................................................................................................... 26 105 7.3.3 Content .................................................................................................................. 27 106

7.4 Document Model........................................................................................................... 27 107 7.4.1 BusinessDocument................................................................................................ 27 108 7.4.2 StructuredDocument ............................................................................................. 28 109 7.4.3 UnstructuredDocument ......................................................................................... 29 110 7.4.4 InformationEntity.................................................................................................. 29 111 7.4.5 AggregateInformationEntity: ................................................................................ 30 112 7.4.6 BasicInformationEntity:........................................................................................ 30 113 7.4.7 Attribute:............................................................................................................... 31 114

7.5 Choreography within Collaborations. ........................................................................... 32 115 7.5.1 BusinessState ........................................................................................................ 32 116 7.5.2 Transition.............................................................................................................. 32 117 7.5.3 Start ....................................................................................................................... 32 118 7.5.4 TerminalState ........................................................................................................ 33 119 7.5.5 Success.................................................................................................................. 33 120 7.5.6 Failure ................................................................................................................... 33 121 7.5.7 SynchronizationState ............................................................................................ 34 122 7.5.8 Guard..................................................................................................................... 34 123

7.6 Definition and Scope..................................................................................................... 34 124 7.7 Collaboration Specification Rules ................................................................................ 35 125

7.7.1 Well- formedness Rules......................................................................................... 35 126 8 Specification Schema – (DTD)............................................................................................. 37 127

8.1 Documentation for the DTD......................................................................................... 37 128 8.2 DTD .............................................................................................................................. 58 129 8.3 XML to UML cross-reference ...................................................................................... 63 130 8.4 Scoped Name Reference ............................................................................................... 65 131 8.5 Sample XML document against above DTD................................................................ 66 132

9 Common Modeling Elements ............................................................................................... 74 133 9.1 Datatyping..................................................................................................................... 74 134

9.1.1 Global Datatypes................................................................................................... 74 135 9.1.2 Local Datatypes..................................................................................................... 77 136

9.2 Business signal structures ............................................................................................. 77 137 9.2.1 ReceiptAcknowledgment DTD............................................................................. 77 138 9.2.2 AcceptanceAcknowledgement DTD..................................................................... 81 139 9.2.3 Exception Signal DTD.......................................................................................... 84 140

10 Production Rules............................................................................................................... 87 141 11 Business Service Interaction Patterns ............................................................................... 88 142

11.1 Service Component Interaction Pattern ........................................................................ 88 143 11.1.1 Service-Service ..................................................................................................... 89 144 11.1.2 Agent-Service-Service .......................................................................................... 94 145 11.1.3 Service-Service-Agent .......................................................................................... 99 146 11.1.4 Service-Agent-Service ........................................................................................ 104 147

11.1.5 Agent-Service-Agent .......................................................................................... 110 148 12 References ....................................................................................................................... 115 149 13 Disclaimer ....................................................................................................................... 115 150 14 Contact Information........................................................................................................ 116 151 Copyright Statement ................................................................................................................... 117 152 153

154

4 Introduction 154

Executive Summary 155 156

The ebXML Specification Schema provides a standard framework by which business 157 systems may be configured to support execution of business transactions. It is based 158 upon prior UN/CEFACT work, specifically the metamodel behind the UN/CEFACT 159 Unified Modeling Methodology (UMM) defined in the N90 specification. 160

The current version of the specification schema facilitates the infrastructure release of 161 ebXML's Transport/Routing/Packaging (TRP), Trading Partner (TP), and 162 Registry/Repository (RegRep) specifications. 163

The current version of the specification schema addresses collaborations between two 164 parties (Binary Collaborations). 165

A subsequent version will address additional features such as the semantics of 166 economic exchanges and contracts, multi-party choreography, and context based 167 content.168

Copyright © ebXML 2000 & 2001. All Rights Reserved.

4.1 Summary of Contents of Document 169 This document specifies a specification schema for execution of business processes. 170 This document describes the Specification Schema, both in its UML form and in its DTD 171 form. To facilitate easy and consistent specification of the required legally binding1 172 electronic commerce transaction this document also provides a set of standard patterns, 173 and a set of modeling elements common to those standard patterns. 174 175 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 176 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 177 document, are to be interpreted as described in RFC 2119 [Bra97]. 178 179

4.2 Audience 180 The primary audience is business process analysts. We define a business process analyst 181 as someone who interviews business people and as a result documents business processes 182 in unambiguous syntax. The audience is not business application developers. 183

4.3 Related Documents 184 As mentioned above, other documents provide detailed definitions of some of the 185 components of The ebXML Specification Schema and of their inter-relationship. They 186 include ebXML Specifications on the following topics: 187

188 ebXML Technical Architecture, version 1.0 189

4.4 Prerequisites 190 It is assumed that the audience will be familiar with or have knowledge of the following 191 technologies and techniques: 192 § Business process modeling techniques and principles 193 § The UML syntax and semantics, the UML metamodel and the UML extension 194

mechanism 195 § The eXtended Markup Language (XML) 196

197

5 Design Objectives 198 199

5.1 Goals/Objectives/Requirements/Problem Description 200 Business process models specify interoperable business processes that allow business 201 partners to collaborate. 202

1 1 Legally binding in this context is refers to the effectivity of a contractual obligation, public or private, in all transactions whether formal or informal, a business transaction is the fulfillment of an exception, without such there is the potential for consequences.

Context/Metamodel Group January 2001

ebXML Business Process Specification Schema Page 2 of 8


The ebXML Specification Schema provides for the nominal set of specification elements 203 necessary to configure a runtime system in order to execute collaboration consisting of a 204 set of ebXML business transactions. This schema facilitates the infrastructure release of 205 ebXML’s TRP, TP, and RegRep specifications. 206 The Specification Schema is available in two stand-alone representations, a UML profile, 207 and a DTD. Users of the Specification Schema will create business process specifications 208 as either UML diagrams, or eXtended Markup Language (XML) documents. 209 The Specification Schema supports the specification of Business Transactions and the 210 choreography of Business Transactions into Business Collaborations. Each Business 211 Transaction can be implemented using one of many available standard patterns. These 212 patterns determine the actual exchange of messages and business signals between the 213 partners to achieve the required electronic commerce transaction. 214 215 Business signals are application level documents that ‘signal’ the current state of the 216 business transaction. These business signals have specific business purpose and are 217 separate from lower protocol and transport signals. 218 219

5.2 Caveats and Assumptions 220 This specification is designed to specify the run time aspects of a business collaboration. 221 It represents one view of the overall metamodel as follows: 222

5.3 Metamodel Architecture 223 224

The ebXML Business Process and Information Meta Model is a description of 225 business semantics that allows Trading Partners to capture the details for a 226 specific business scenario using a consistent modeling methodology. A Business 227 Process describes in detail how Trading Partners take on roles, relationships and 228 responsibilities to facilitate interaction with other Trading Partners in shared 229 Business Processes. The interaction between roles takes place as a 230 choreographed set of Business Transactions. Each Business Transaction is 231 expressed as an exchange of electronic Business Documents. The sequence of 232 the exchange is defined by the Business Process, messaging and security 233 considerations. Business Documents are composed from re-useable business 234 information components. At a lower level, Business Processes can be composed 235 of re-useable Core Processes, and Business Objects can be composed of re-236 useable Core Components. 237

The ebXML Business Process and Information Meta Model supports 238 requirements, analysis and design viewpoints that provide a set of semantics 239 (vocabulary) for each viewpoint and forms the basis of specification of the 240 semantics and artifacts that are required to facilitate business process and 241 information integration and interoperability. 242 An additional view of the metamodel, the Specification Schema, is also provided 243 to support the direct specification of the nominal set of elements necessary to 244 configure a runtime system in order to executive a set of ebXML business 245 transactions. By drawing out modeling elements from several of the other views, 246




the Specification Schema forms a semantic subset of the ebXML Business 247 Process and Information Meta Model. The Specification Schema is available in 248 two stand-alone representations, a UML profile, and a DTD. 249

250 The relationship between the ebXML Business Process and Information Meta 251 Model and the ebXML Specification Schema can be shown as follows: 252

Figure 5-1 Relationship between Metamodel and Specfication 253 Schema254

255 The Specification Schema supports the specification of Business Transactions 256 and the choreography of Business Transactions into Business Collaborations. 257 Each Business Transaction can be implemented using one of many available 258 standard patterns. These patterns determine the actual exchange of messages 259 and business signals between the partners to achieve the required electronic 260 commerce transaction. To help specify the patterns the Specification Schema is 261 accompanied by a set of standard patterns, and a set of modeling elements 262 common to those standard patterns. The full specification, thus, of a business 263 process consists of a business process model specified against the Specification 264 Schema and an identification of the desired pattern(s). This full specification is 265 then the input to the formation of trading partner Collaboration Protocol Profiles 266 and Collaboration Protocol Agreements. 267

This can be shown as follows: 268




Figure 5-2 Relationship of specification schema to TP and Core Components 269

270 As the figure shows, the architecture of the ebXML Specification Schema 271 consists of the following functional components (shown inside the dotted box): 272

UML Specification Schema, 273

DTD specification Schema, 274

Business Process Interaction Patterns, 275

Common Modeling Elements for Business Process Interaction Patterns 276

and the Production Rules needed for the generation of UML specification into a 277 XML Specification Document 278

Together these components allow you to fully specify all the run time aspects of a 279 business process and the accompanying information model. 280

This run time business process and information specification is then incorporated 281 into trading partner Collaboration Protocol Profiles (CPP) and Collaboration 282 Protocol Agreements (CPA). Within these profiles and agreements are then 283 added further technical parameters resulting in a full specification of the run-time 284 software at each trading partner. 285




6 System Overview 286 Each of the components in the Specification Schema is described below: 287

288

UML Specification Schema 289 The UML Specification Schema is a semantic subset of the metamodel behind 290 UMM as specified in UN/CEFACT TMWG’s N90, expressed as a standalone 291 UML profile. The UML Specification Schema guarantees that a XML 292 Specification Document is analytically, semantically and functionally equivalent to 293 one arrived at by modeling the same subset through the use of UMM. 294

DTD Specification Schema 295 The DTD Specification Schema is an isomorphic definition of the UML 296 Specification Schema. The DTD Specification Schema seeks to guarantee that a 297 XML Specification Document is analytically, semantically and functionally 298 equivalent to a UML Specification Model of the same business process. 299

This version of the specification is expressed as a DTD, and some of the 300 constraints may need to be stated separately, in plain text. It is the intent to 301 migrate to W3C schema, as soon as it becomes available as a standard. At that 302 point such constraints, where possible, will be built into the schema. 303

Business Process Interaction Patterns 304 ebXML business service interfaces are configured to execute the business 305 processes defined against the specification schema. They do so by exchanging 306 ebXML messages and business signals. The Business Process Interaction 307 Patterns define the permissible set of message sequences as determined by the 308 type of business transaction defined, type of roles which are participating in the 309 transaction and the timing policy specified in the transactions. 310

Common Interaction Pattern Modeling Elements 311 The Common Modeling Elements specifies the modeling elements, and their 312 interrelationships, that are used to express Interaction Pattern Specification 313

Production Rules 314 The Specification Production rules provide the prescriptive definition necessary 315 to translate a UML Specification Model into a XML Specification Document and 316 the well-formed rules necessary to populate a XML Specification Document. 317

318




6.1 What the ebXML Business Process Specification Schema 319 Does 320

321 The UML Specification Schema provides the semantics, properties and elements 322 necessary to define Business Collaborations, Business Transactions, Message 323 Exchanges, Document Definitions, and Choreography within Collaborations. 324

1. Business Collaborations 325

A Business Collaboration is a set of interactions between business 326 partners. Each partner plays one or more roles in the collaboration. 327 Binary Business Collaborations are between two roles only. Binary 328 Collaborations are expressed as a set of BusinessActivities between the 329 two roles. The BusinessActivities can be ‘atomic’, i.e. the activity of 330 conducting an atomic BusinessTransaction, or ‘composite’, i.e. the activity 331 of conducting another Binary Collaboration. In either case the activities 332 can be choreographed as per below. Binary Collaborations can be 333 synthesized into multi-party Collaborations. In this release there is no 334 choreography among the binary collaborations making up a multiparty 335 collaboration. 336

2. Business Transactions 337

A business transaction is an atomic unit of work in a business 338 collaboration. A business transaction is conducted between two business 339 partners playing opposite roles in the transaction. A business transaction 340 always starts with a requesting activity (carried out by the requesting 341 role). This activity results in the sending of a request. This request serves 342 to transition control to the responding role who then enters a responding 343 activity. During or upon completion of the responding activity zero, zero or 344 one response is sent. Optionally one or more business signals are also 345 sent from the responding role to the requesting role. Part of the pattern of 346 a business transaction determines when control transitions back to the 347 requesting role. 348

A business transaction will always either succeed or fail. If it succeeds it 349 is legally binding for the two partners. If it fails it is null and void, and each 350 partner must relinquish any mutual claim established by the transaction. 351 This can be thought of as ‘rolling back’ the business transaction upon 352 failure. 353

A business transaction activity defines the use of a business transaction 354 in a collaboration. Each business transaction activity, thus, represents an 355 atomic unit of work defined by the business transaction it refers to (uses) 356 within the collaboration. 357 A business collaboration choreographs one or more business transaction 358 activities that are conducted amongst two or more parties. A business 359 collaboration is not a transaction and should be used in cases where 360 transaction rollback is inappropriate. For example, a buying partner may 361 request a purchase order creating from a selling partner. The selling 362 partner may partially accept purchase order and thus complete the 363




transaction but may only return shipping information on part of the order. 364 The buying partner is sent any number of later notifications regarding the 365 outstanding portions of the order until the order is completely reconciled. 366

3. Message Exchanges 367 A business transaction is defined as a set of business documents and 368 signals exchanged between the requesting and responding roles. The 369 documents are enclosed in named document envelopes. One envelope 370 passes from requesting activity to responding activity and zero or one 371 passes back from the responding activity to the requesting activity. In 372 each document envelope is exactly one DocumentSet. A DocumentSet 373 can contain be one or more business documents. The document set is in 374 essence one transaction in the payload in the ebXML TRP message. 375

4. Document Definition 376

An information entity is the basic building block for information structure. 377 An information entity can be basic, aggregate, or specialized as a 378 BusinessDocument. 379

Aggregate information entities can have attributes which can be other 380 information entities. 381

A business document is the only type of information entity that can be 382 contained in a DocumentSet for exchange between parties. A business 383 document is always of a type called ebxmlDocumentType which can be 384 unambiguously mapped to MIME types. 385

5. Choreography 386

The choreography of business transactions within business 387 collaborations, and the recursive nesting of business collaborations, is 388 defined in terms of states, and transitions between those states. States 389 include a start state, a completion state (which comes in a success and 390 failure flavor), the activity state (in-process), and a synchronization state. 391 Transitions are between states. Transitions can be gated by Guards. 392 Guards can refer to the type of document set received in the document 393 envelopes that caused the transition, and/or to postconditions on the prior 394 state. 395

6.2 How the ebXML Business Process Specification Schema 396 Works 397

The ebXML Specification Schema should be used wherever software is being 398 specified to perform a role in an ebXML binary collaboration. Specifically The 399 ebXML Specification Schema is intended to provide the business process and 400 document specification for the formation of a partner Collaboration Protocol 401 Profile and Agreement. A set of specification rules have been established to 402 properly constrain the the expression of a business process and information 403 model in a way that can be directly incorporated into a trading partner 404 Collaboration Protocol Profile and Agreement. 405




A user would use a UML tool to create a model instance against this specification 406 schema, and would then use the production rules to produce the XML version of 407 the model, compliant with the DTD version of the specification schema. 408

Alternatively a user would use an XML based tool to produce the XML version 409 directly. Production rules would then aid in converting into XMI, so that it could be 410 loaded into a UML tool, if required. 411

In either case, the XML version gets registered in the repository for future 412 retrieval when implementers want to establish trading partner Collaboration 413 Protocol Profile and Agreement. At that point the XML document, or the relevant 414 parts of it, are simply imbedded in or referenced by the CCP and CPA XML 415 documents. 416

As described above, the specification schema contains the following main 417 sections: 418

1. Business Collaborations (shown in green in diagram below) 419

2. Business Transactions (shown in blue in diagram below) 420

3. Message Exchanges (shown in yellow in diagram below) 421

4. Document Definition (further detailed in a subsequent diagram) 422

5. Choreography (shown in red in diagram below) 423

424

425 The following picture shows the above semantics as a UML class diagram: 426

427




Performs

Start

Success Failure

Terminal State Sync State

Resul t

MultiPartyCollaboration

Business Partner

* 1

+partners

*

+Collaboration

1

BusinessTransactionActivity

*

1+performers

*+performedBy

1

BusinessActivity

CollaborationActivityBusiness Transaction

1

*+uses

1 +act iv i t ies

*

Authorizin

gRole

1

*

+role

1+performers

*

1

*

+to1

*

1

*

+from1

*

BinaryCollaboration

1

*

+uses 1

+usedBy

*

2

1

+role

2

+col laborat ion

1

RequestingBusinessActivity

1

1

+requester

1

+transaction1

0 . . *

0..*

+requesting

0 . . *

+requesters

0..*

RespondingBusinessActivity

1

1

+responder

1

+transaction1

0..*

0..*

+responders

0..*

+responding

0..*

BusinessState

* 1

+states

*

+collaboration

1

Document Envelope

1

1

1

+requesting 1

1

1

1

+Responding

1

Transition

* 1

+exiting* 1

out

1* 1+entering*

in

Document Set*

*

+Potential Contents

*

*

Guard

1

0. .1

1

+Guard 0. .1

0..1

+requires

0..1

428

Figure 6-1Overall Specification Schema as UML class diagram 429




430 The following picture shows the ebXML document model as a UML class 431 diagram: 432

Basic Information Entity

Integers, Strings, Dates and things that fit in XML

Pictures, Movies, EDI messages...

isLink makes an xPointer (External value) instead of an embeded value

Business Information

Structured Document

Unstructured Document

Abstract Attribute

name : Stringrequired : Boolean

Aggregate Information Entity 0..1*

+supertype

0..1

+subtype

*

Information Entity

Attr ibute

*

1

+attribtues *

+owner1

1 *

+type

1 *

Document Set ebxmlDocument

Content

*

1

+attributes

*

+owner11

*

+type1

*

433

Figure 6-2Document model as UML class diagram 434

435

6.2.1 Core Business Transaction Semantics 436 Before going through the semantics of each of the modeling elements in the 437 class diagram, it is necessary to understand the semantics of the core concept, 438 the business transaction. 439




The concept of a business transaction and the semantics behind it are central to 440 predictable, enforceable commerce. In the ebXML model the business 441 transaction always has the following semantics: 442

1. The business transaction is a unit of work. All of the interactions in a 443 business transaction must succeed or the transaction must be rolled back 444 to a defined state before the transaction was initiated. 445

2. A business transaction is conducted between two business partners 446 playing opposite roles in the transaction. 447

3. The business transaction is always viewed from the viewpoint of the 448 requesting role 449

4. A business transaction always starts with a requesting activity (carried out 450 by the requesting role). This activity results in the sending of a request . 451

5. The request serves to transition control to the responding role. 452

6. The responding role then enters a responding activity. During or upon 453 completion of the responding activity zero or one response is sent. 454

7. The response (if any) transitions control back to the requesting role. If no 455 response is sent then control transitions back to the requesting role based 456 on the receipt of a business signal. 457

8. A receiptAcknowledgement signal is required for all business 458 transactions. The receiptAcknowledgement signal is sent from the 459 responding role to the requesting role upon receipt, and optionally 460 validation of the request. 461

9. All business transactions succeed or fail. Success or failure depends on: 462

a. the receipt or non-receipt of the confirming response or business 463 signals 464

b. the expiration of time-outs 465 c. the occurrence of a business exception 466

d. the occurrence of a control exception 467

Even though all business transactions are governed by the above semantics, 468 business transactions can be carried out in many distinctly and succinctly defined 469 patterns and with different security and exchange characteristics. 470

The groups of specification elements that determine the exact pattern of a 471 business transaction are: 472

1. Response patterns 473 2. Time-outs 474

3. Control exceptions 475

4. Business protocol exceptions 476

5. Security parameters. 477

6. Concurrency 478




7. Reliability 479

8. Synchronous or asynchronous 480

481

6.2.2 Response patterns. 482 There is always only one request. 483

During or upon completion of the responding activity zero or one 484 response document set is sent. Optionally one or more business signals 485 are also sent from the responding role to the requesting role. 486

487 Therefore business transaction response patterns vary based on whether 488 zero or one response is required and on how many business signals are 489 required. 490

In addition to the actual response document set, also called Substantive 491 acceptance there are two possible business signal types: 492

• Receipt acknowledgement – this is a required signal in all 493 business transactions. 494

• Acceptance acknowledgement (Non-Substantive) – this may or 495 may not be required, depending on the particular business 496 transaction. 497

498

The Substantive acceptance will always result in a successful completion 499 of the business transaction. The other two are interim messages, and are 500 of a type called business signal messages. 501

The formal description of the two business signals above is: 502 Receipt acknowledgement business signal. The UN/EDIFACT model 503 Trading Partner Agreement (TPA) suggests that a partners should agree 504 on the point at which a message can be "said" to be properly received 505 and this point should be when a receiving partner can "read" a message2. 506 The property isIntelligibleCheckRequired allows partners to agree that a 507 message should be “readable” before its receipt is verified3. 508

Acceptance Acknowledgement business signal. The UN/EDIFACT model 509 TPA suggests that partners should agree on the point at which a 510 message can be "said" to be accepted for business processing and this 511 point should be after the contents of a business document have passed a 512 business rule validity check.4 513

514

2 The UN/ECE defines this to be the point after which a message passes a structure/ schema validity check. This is not a necessary condition for verifying proper receipt, only accessibility is. 3 4 This is the convention specified for RosettaNet and UN/CEFACT N90 commercial transactions.




The specification of a business transaction may require each one of these 515 independently of whether the other is required. If one is not required, it is 516 actually not allowed. Therefore there is a finite set of combinations. 517

These could then be given pattern names. 518 Business modelers may find it convenient to develop and name business 519 transaction design patterns to facilitate the development of their 520 specifications. The following six property-value conventions for business 521 transactions have proven useful in the application of the metamodel to 522 existing business requirements. 523

Commercial Transaction 524

Request / Confirm 525

Query / Response 526 Request / Response 527

Notification 528

Information Distribution 529

6.2.3 Timeouts 530 Since all business transactions must have a distinct time boundary, there 531 are time-out parameters associated with each of the response types. If 532 the time-out occurs before the required response arrives, the transaction 533 is null and void. 534

535

Here are the time-out parameters relative to the three response types: 536

537

Response required Parameter Name Meaning of timeout

Receipt acknowledgement

timeToAcknowledgeReceipt The time a responding role has to acknowledge receipt of a business document.

Acceptance Acknowledgement (Non-substantive)

timeToAcknowledgeAcceptance The time a responding role has to non-substantively acknowledge business acceptance of a business document.




document.

Substantive acceptance

TimeToPerform

The time a responding role has to substantively acknowledge business acceptance of a business document.

538

A time-out parameter must be specified whenever a requesting partner 539 expects one or more responses to a business document request. A 540 requesting partner must not remain in an infinite wait state. 541

The time-out value for each of the time-out parameters is absolute i.e. not 542 relative to each other. All timers start when the requesting business 543 document is sent. The timer values must comply with the well-formedness 544 rules in the previous section. 545

A responding partner simply terminates if a timeout is thrown. This 546 prevents responding business transactions from hanging indefinitely. 547

When the time to perform an activity equals the time to acknowledge 548 receipt or the time to acknowledge business acceptance then the highest 549 priority time out exception must be used when the originator provides a 550 reason for revoking their original business document offer. The time to 551 perform exception is lower priority than both the time to acknowledge 552 receipt and the time to acknowledge business acceptance. 553

6.2.4 ControlException 554 A ControlException signals an error condition in the management of a 555 business transaction. This business signal is asynchronously returned to 556 the initiating service that originated the request. This exception must 557 terminate the business transaction. These errors deal with the 558 mechanisms of message exchange such as verification, validation, 559 authentication and authorization and will occur up to message 560 acceptance. Typically the rules and constraints applied to the message 561 will have only dealt with structure, syntax and message element values. 562

6.2.5 Business Protocol Exceptions (a.k.a. ProcessException) 563 Under all normal circumstances the response message and/or the time-564 outs determine the success or failure of a business transaction. However 565 the business processing of the transaction can go wrong at either the 566 responding or the requesting role. 567




A ProcessException signals an error condition in a business activity. This 568 business signal is asynchronously returned to the initiating service that 569 originated the request. This exception must terminate the business 570 transaction. These errors deal with the mechanisms that process the 571 business transaction and will occur after message verification and 572 validation. Typically the rules and constraints applied to the message will 573 deal the semantics of message elements and the validity of the request 574 itself and the content is not valid with respect to a responding role’s 575 business rules. This type of exception is usually generated after an 576 AcceptanceAcknowledgement has been returned. 577

A business protocol exception terminates the business transaction. The 578 following are business protocol exceptions. 579

• Negative acknowledgement of receipt. The structure/schema of a 580 message is invalid. 581

• Negative acknowledgement of acceptance. The business rules 582 are violated. 583

• Performance exceptions. The requested business action cannot 584 be performed. 585

• Sequence exceptions. The order or type of a business document 586 or business signal is incorrect. 587

• Syntax exceptions. There is invalid punctuation, vocabulary or 588 grammar in the business document or business signal. 589

• Authorization exceptions. Roles are not authorized to participate in 590 the business transaction. 591

• Business process control exceptions. Business documents are not 592 signed for non-repudiation. 593

A responding role that throws a business protocol exception signals the 594 exception back to the requesting role and then terminates the business 595 transaction. A requesting role that throws a business protocol exception 596 terminates the transaction and then sends a notification revoking the 597 offending business document request. The requesting role does not send 598 a business exception signal to the responding role. 599

If any business exceptions (includes negative receipt and acceptance 600 acknowledgements) are signaled then the business transaction must 601 terminate. 602

6.2.6 Security Parameters 603 604

There are a number of parameters that specify the security characteristics 605 of the business transaction. These fall in a number of categories: 606

• Document security, 607

• Message transfer security, 608




• Action security, 609

• Non-repudiation. 610

611

6.2.6.1 Document security: 612 Each business document being transported, even if many are 613 collected in the same message, can be specified as: 614

615 isConfidential. The information entity is encrypted so that 616

unauthorized parties cannot view the 617 information. 618

isTamperProof. The information entity has an encrypted 619 message digest that can be used to check if the 620 message has been tampered with. This requires 621 a digital signature (sender’s digital certificate 622 and encrypted message digest) associated with 623 the document entity. 624

isAuthenticated. There is a digital certificate associated with the 625 document entity. This provides proof of the 626 signer’s identity. 627

628

6.2.6.2 Message transfer security: 629 630

Each message can be specified to require secure transport. flavor. 631

632

isSecureTransportRequired 633

634 This reuirement comes in two flavors: Persistence NOT required 635 means no-one can snoop the message on the wire. Persistence 636 required means the message will not be readable by anyone until 637 delivered into the application space. 638

6.2.6.3 Action security 639 640

Each request or response may be sent by any number of people 641 in the respective business partners companies. A request can be 642 seen as ‘invoking’ the responding activity. The response can be 643 seen as ‘invoking’ the requesting activity. The act of invoking may 644 require the ‘invoker’ to be authorized. 645

646 IsAuthorizationRequired is specified on the requesting and 647 responding activity accordingly. 648




6.2.6.4 Non-Repudiation 649 650

Business transactions are legally binding. To help the parties have 651 solid documentation to enforce contractual obligation in court, 652 non-repudiation may be required. 653

654

There are two flavors of non-repudiation. 655

656

One requires the two parties to save copies of the transacted 657 documents, each on their own side, i.e. requestor saves his 658 request, responder saves his response. 659

660

This is the isNonRepudiationRequired in the requesting or 661 responding activity. 662

663

The other requires the responder to send a signed copy of the 664 receipt, which the requestor then saves. 665 666

This is the isNonRepudiationOfReceiptRequired in the requesting 667 business activity. 668

669

NonRepudiationOfReceipt is tied to the ReceiptAcknowledgement, 670 in that it requires it to be signed. So one cannot have 671 NonRepudiationOfReceipt without ReceiptAcknowledgement 672 required, and the timeToAcknowledgeReceipt applies to both, i.e. 673 if NonRepudiationOfReceipt is true and a signed receipt is not 674 returned within timeToAcknowledgeReceipt, the transaction is null 675 and void. 676

6.2.7 Concurrency 677 678

There is one more parameter that governs the flow of 679 transactions, but this one does not govern the internal flow of a 680 transaction, rather it determines whether multiple instances of that 681 transaction type can be ‘open’ at the same time as part of the 682 same activity. 683

684 IsConcurrent at business transaction activity level. 685

686




6.2.8 Reliability 687 688

A parameter at the transaction level states whether guaranteed 689 delivery required. 690

691

IsGuaranteedDeliveryRequired is a parameter in the business 692 transaction 693

694

695 696

6.2.9 Synchronous or Asynchronous 697 A business transaction may be implemented as either a 698 synchronous or an asynchronous flow of control between the two 699 activities. The specification of synchronous vs. asynchronous is 700 part of the interaction pattern specification for a business 701 transaction. 702

A partner role that initiates an asynchronous business transaction 703 does not need to receive any business signals. A partner role that 704 initiates a synchronous business transaction must be able to 705 receive business signals and must block until the flow of control is 706 returned. This should not preclude the initiation and execution of 707 multiple concurrent business transactions, however. 708 709

6.3 Where the ebXML Specification Schema May Be 710 Implemented 711

The ebXML Specification Schema should be used wherever software is being 712 specified to perform a role in an ebXML binary collaboration. Specifically The 713 ebXML Specification Schema is intended to provide the business process and 714 document specification for the formation of a trading partner Collaboration 715 Protocol Profile and Agreement. 716 717

7 Specification Element Overview 718 719

In the following we will review all the specification elements in the specification 720 schema, grouped as follows: 721

• Business Collaborations 722

• Business Transactions 723




• Message Exchange 724

• Document model 725

• Choreography 726

727 728

729

7.1 Business Collaborations 730 731 7.1.1 MultiPartyCollaboration 732

A multiparty collaboration is a synthesis of binary collaborations. A 733 multiparty collaboration consists of a number of business partners 734 each playing one or more roles in binary collaborations with each 735 other. In this release a multiparty collaboration is merely a 736 composition of binary collaborations. There is not in this release 737 any support for choreography among the binary collaborations 738 across multiple partners. 739

Tagged Values: 740

741 NONE 742

Associations: 743

partners A multiparty collaboration has two or more 744 BusinessPartners 745

Wellformedness Rules: 746

NONE 747

748 7.1.2 BusinessPartner 749

The business partners that participate in business collaborations 750 are enumerated for each multiparty business collaboration. 751 Partners provide the initiating and responding roles in the 752 underlying binary collaborations. 753

Tagged Values: 754

name. The name of the roles played by partner in the 755 overall multiparty business collaboration, e.g. 756 customer or supplier 757

Associations: 758




performers. The authorizing roles performed by a partner in 759 the binary business collaboration. 760

Wellformedness Rules: 761 A partner must not perform both roles in a business transaction 762

activity. 763 764

7.1.3 Performs 765 Performs is an explicit modeling of the relationship between a 766 BusinessPartner and the Roles it plays. This specifies the use of 767 an authorizing role within a multiparty collaboration. 768

Tagged Values: 769

770 NONE 771

Associations: 772

performedBy An instance of Performs is performed by only 773 one BusinessPartner 774

role Performs is the use of an AuthorizingRole within 775 a multiparty collaboration 776

Wellformedness Rules: 777 NONE 778

779 7.1.4 AuthorizingRole 780

An authorizing role is the role that authorizes the requesting or 781 responding activity, e.g. the buyer authorizes the request for 782 purchase order, the seller authorizes the acceptance of purchase 783 order. 784

Tagged Values: 785 name. The name of the role within the business 786

transaction 787

Associations: 788

performers An AuthorizingRole may be used by one or more 789 performers, i.e. business partners in a multiparty 790 collaboration 791

requestors An AuthorizingRole may authorize one or more 792 requesting activities 793

responders An AuthorizingRole may authorize one or more 794 responding activities 795




from An AuthorizingRole may be the initiator in a 796 business activity 797

to An AuthorizingRole may be the responder in a 798 business activity 799

collaboration An AuthorizingRole may be in only one 800 BinaryCollaboration 801

Wellformedness Rules: 802 An AuthorizingRole may not be both the requestor and the 803

responder in a business transaction 804 An AuthorizingRole may not be both the initiator and the 805

responder in a binary business collaboration 806

807 7.1.5 BinaryCollaboration 808

A binary business collaboration choreographs one or more 809 business transaction activities between two roles. A binary 810 business collaboration is not a transaction and should be used in 811 cases where transaction rollback is inappropriate. 812

Tagged Values: 813

timeToPerform. The time allowed to complete the binary 814 collaboration 815

Associations: 816

role A binary collaboration consists of two roles 817 states A binary collaboration consists of one or more 818

states, some of which are ‘static’, and some of 819 which are action states 820

usedBy A binary collaboration may be used within 821 another binary collaboration via a collaboration 822 activity 823


826 7.1.6 BusinessActivity 827

A business activity is an action state within a binary collaboration. 828 It is the supertype for BusinessTransactionActivity and 829 CollaborationActivity, specifying the activity of performing a 830 transaction or another binary collaboration respectively. 831

Tagged Values: 832 name. The name of the activity within the binary 833

collaboration 834




Associations: 835 from The initiating role 836 to The responding role 837


840 7.1.7 BusinessTransactionActivity 841

A business transaction activity is a business activity that executes 842 a specified business transaction. The business transaction activity 843 can be executed more than once if the isConcurrent property is 844 true. 845

Tagged Values: 846

timeToPerform. Both partners agree to perform a business 847 transaction activity within a specific duration. 848 The originating partner must send a failure 849 notification to a responding partner on timeout. A 850 responding partner simple terminates its activity. 851 The time to perform is the duration from the time 852 a business transaction activity initiates the first 853 business transaction until there is a transition 854 back to the initiating business transaction 855 activity. Both partners agree that the business 856 signal document or business action document 857 specified as the document to return within the 858 time to perform is the “Acceptance Document” in 859 an on-line offer/acceptance contract formation 860 process. 861

862 isConcurrent. If the business transaction activity is concurrent 863

then more than one business transaction can be 864 open at one time. If the business transaction 865 activity is not concurrent then only one business 866 transaction activity can be open at one time. 867

Associations: 868 uses. The business transaction activity executes 869

(uses) exactly one business transaction. 870

Wellformedness Rules: 871 NONE 872 873




7.1.8 CollaborationActivity 874 A collaboration activity is the activity of performing a binary 875 collaboration within another binary collaboration. 876

Tagged Values: 877

NONE (other than inherited) 878

Associations: 879 uses. A collaboration activity uses exactly one binary 880

collaboration 881

Wellformedness Rules: 882 A binary collaboration may not re-use itself 883

884

7.2 Business Transactions 885 886 7.2.1 BusinessTransaction 887

A business transaction is a set of business information and 888 business signal exchanges amongst two commercial partners that 889 must occur in an agreed format, sequence and time period. If any 890 of the agreements are violated then the transaction is terminated 891 and all business information and business signal exchanges must 892 be discarded. business transactions can be formal as in the 893 formation of on-line offer/acceptance commercial contracts and 894 informal an in the distribution of product announcements. 895

Tagged Values: 896 isSecureTransportRequired. Both partners must agree to 897

exchange business information using a secure 898 transport channel. The following security 899 controls ensure that business document content 900 is protected against unauthorized disclosure or 901 modification and that business services are 902 protected against unauthorized access. This is a 903 point-to-point security requirement. Note that 904 this requirement does not protect business 905 information once it is off the network and inside 906 an enterprise. The following are requirements for 907 secure transport channels. 908 Authenticate sending role identity – Verify the 909 identity of the sending role (employee or 910 organization) that is initiating the role interaction 911 (authenticate). 912 Authenticate receiving role identity – Verify 913 the identity of the receiving role (employee or 914




organization) that is receiving the role 915 interaction. 916 Verify content integrity – Verify the integrity of 917 the content exchanged during the role 918 interaction i.e. check that the content has not 919 been altered by a 3rd party. 920 Maintain content confidentiality – 921 Confidentiality ensures that only the intended, 922 receiving role can read the content of the role 923 interaction 924

isGuaranteedDeliveryRequired. Both partners must agree to use 925 a transport that guarantees delivery 926

7.2.2 RequestingBusinessActivity 927 A requestingBusinessActivity is a business activity that is 928 performed by a role requesting commerce from another business 929 role. 930

IsAuthorizationRequired If a partner role needs authorization to 931 request a business action or to respond to a 932 business action then the sending partner role 933 must sign the business document exchanged 934 and the receiving partner role must validate this 935 business control and approve the authorizer. A 936 responding partner must signal an authorization 937 exception if the sending partner role is not 938 authorized to perform the business activity. A 939 sending partner must send notification of failed 940 authorization if a responding partner is not 941 authorized to perform the responding business 942 activity. 943

IsNonRepudiationRequired If non-repudiation of origin and 944 content is required then the business activity 945 must store the business document in its original 946 form for the duration mutually agreed to in a 947 trading partner agreement. A responding partner 948 must signal a business control exception if the 949 sending partner role has not properly delivered 950 their business document. A requesting partner 951 must send notification of failed business control 952 if a responding partner has not properly 953 delivered their business document. 954 955

TimeToPerform The time a responding role has to substantively 956 acknowledge business acceptance of a 957 business document. 958

TimeToAcknowledgeAcceptance The time a responding 959 role has to non-substantively acknowledge 960 business acceptance of a business document. 961

TimeToAcknowledgeReceipt The time a responding role has 962 to acknowledge receipt of a business document. 963




isNonRepudiationOfReceiptRequired. 964 Both partners agree to mutually verify receipt of a requesting 965 business document and that the receipt must be non-reputable. 966 A receiving partner must send notification of failed business 967 control (possibly revoking a contractual offer) if a responding 968 partner has not properly delivered their business document. 969 970 Non-repudiation of receipt provides the following audit controls. 971 Verify responding role identity (authenticate) – Verify the 972 identity of the responding role (individual or organization) that 973 received the requesting business document. 974 Verify content integrity – Verify the integrity of the original 975 content of the business document request. 976 977

Associations: 978 transaction A requesting activity is performed in exactly one 979

business transaction 980 requesters A requesting activity can be performed by one or 981

more responding roles 982 envelope A requesting activity sends exactly one 983

document envelope 984 985


NONE 987 988

7.2.3 RespondingBusinessActivity 989 A respondingBusinessActivity is a business activity that is 990 performed by a role responding to another business role’s request 991 for commerce. 992

Tagged Values: 993 isIntelligibleCheckRequired. Both partners agree that a 994

responding partner role must check that a 995 requesting document is not garbled (unreadable, 996 unintelligible) before verification of properly 997 receipt is returned to the requesting partner. 998

Associations: 999 transaction A responding activity is performed in exactly one 1000

business transaction 1001 responders A responding activity can be performed by one 1002

or more responding roles 1003 envelope A responding activity sends at most one 1004

document envelope 1005




1006


NONE 1008

1009

7.3 Message Exchange 1010 1011 7.3.1 DocumentEnvelope 1012

A document envelope is what conveys business information 1013 between the two roles in a business transaction. One document 1014 envelope conveys the request from the requesting role to the 1015 responding role, and another document envelope conveys the 1016 response (if any) from the responding role back to the requesting 1017 role. 1018

1019

Tagged Values: 1020 NONE 1021

Associations: 1022 requesting A DocumentEnvelope is sent by at most one 1023

requesting activity 1024 responding A DocumentEnvelope is sent by at most one 1025

responding activity 1026 potentialContent A DocumentEnvelope contains only one 1027

Document Set. 1028

Wellformedness Rules: 1029 A DocumentEnvelope cannot be sent by both a requesting and a 1030

responding activity 1031 1032

1033

7.3.2 DocumentSet 1034 1035

A DocumentSet is the collection of business documents that are 1036 contained in a DocumentEnvelope. 1037

A documentSet has at least one, but may have multiple 1038 documents. The documents may be of different types, for instance 1039 the DocumentSet could contain a document, a picture, and a 1040 soundclip. Each document is identified by a name and a type. 1041





Associations: 1044 envelope A DocumentSet is conveyed by one or more 1045

DocumentEnvelopes. 1046 content A DocumentSet contains (uses) one or more 1047

documents represented by Content instances 1048


NONE 1050 1051

. 1052

7.3.3 Content 1053 A Content is an entry in a DocumentSet. It identifies the use of a 1054 document within the set. 1055

Tagged Values: 1056

NONE 1057

Associations: 1058 owner A Content is in exactly one DocumentSet 1059 type A Content identifies exactly one 1060

BusinessDocument 1061


NONE 1063

1064

7.4 Document Model 1065 1066 7.4.1 BusinessDocument 1067

1068

A BusinessDocument is an InformationEntity of type 1069 ebxmlDocumentType. Only BusinessDocuments (i.e. 1070 InformationEntities of type ebxmlDocumentType) can be in a 1071 DocumentSet. BusinessDocuments may be StructuredDocuments 1072 or UnstructuredDocuments. Structured vs. Unstructured does not 1073 refer to whether the document actually has structure or not, only to 1074 whether that structure consists of other InformationEntities found 1075 in the ebXML repository. For instance, a traditional EDI 1076 ‘transaction’ is structured, but its structure is not based on other 1077




InformationEntities found in the ebXML repository. Its structure is 1078 defined elsewhere. 1079

Other examples of unstructured document types are "Picture", 1080 "SoundClip", "Movie". Again, unstructured means ebXML does not 1081 know about their subdivisions, if any. 1082

ebxmlDocumentType is an enumerated list of types that can be 1083 unambiguously mapped to MIME types. 1084

The list includes "TaggedText", "Picture", "SoundClip", "Movie" 1085

ebxmlDocumentType is a technology independent classification of 1086 the kinds of documents that can be included in a DocumentSet. 1087 StructuredDocuments must be of a structured type. 1088 UnstructuredDocuments must be of an Unstructured type. 1089

Tagged Values: 1090

documentType a value from the enumerated list of 1091 ebxmlDocumentTypes 1092

1093

Associations: 1094 content A BusinessDocument may be a Content in one 1095

or more DocumentSets 1096 1097


NONE 1099 1100

7.4.2 StructuredDocument 1101 StructuredDocument is a subtype of BusinessDocument. Its 1102 ebxmlDocumentType is always a structured type. It is also a 1103 subtype AggregateInformationEntity, so it may have attributes. 1104

Tagged Values: 1105 NONE (other than inherited) 1106

Associations: 1107 NONE (other than inherited) 1108


NONE 1110

1111




7.4.3 UnstructuredDocument 1112 UnStructuredDocument is a subtype of BusinessDocument. Its 1113 ebxmlDocumentType is always a unstructured type. It is NOT a 1114 subtype AggregateInformationEntity, so it may have attributes. 1115

Tagged Values: 1116

NONE (other than inherited) 1117

Associations: 1118 NONE (other than inherited) 1119


1122 7.4.4 InformationEntity 1123

An InformationEntity is the building block from which complex 1124 information 'bundles' can be composed. An informationEntity has 1125 one and only one type. 1126

InformationEntity is the supertype for BasicInformationEntity and 1127 AggregateInformationEntity and BusinessDocument. Depending 1128 on the subtype the InformationEntity’s type may be a primitive 1129 type (like string, integer, float, date), or it may be an 1130 ebxmlDocumentType (like "Movie", "EDI message", "Picture"). 1131

1132

An information entity realizes structured business information that 1133 is exchanged by partner roles performing activities in a business 1134 transaction. Information entities include or reference other 1135 information entities through associations. 1136 A secure information entity is an information entity with security 1137 controls. Security controls must be specified when information 1138 must be secured within an enterprise until it is accessed by an 1139 authorized partner role. 1140

These parameters on this model element must be specified in a 1141 manner that ensures document integrity by maintaining a “chain-1142 of-custody” from the sender to the intended recipient of the 1143 business information. 1144

Tagged Values: 1145

isConfidential. The information entity is encrypted so that 1146 unauthorized parties cannot view the 1147 information. 1148

isTamperProof. The information entity has an encrypted 1149 message digest that can be used to check if the 1150 message has been tampered with. This requires 1151




a digital signature (sender’s digital certificate 1152 and encrypted message digest) associated with 1153 the document entity. 1154

isAuthenticated. There is a digital certificate associated with the 1155 document entity. This provides proof of the 1156 signer’s identity. 1157

1158 1159

1160

1161

1162

Associations: 1163

1164 Attribute: An InformationEntity provides the definition (and 1165

type) for one or more attributes in one or more 1166 AggregateInformationEntities. 1167

1168

Wellformedness rules: 1169 NONE 1170

7.4.5 AggregateInformationEntity: 1171 1172

AggregateInformationEntity is a collection of attributes, each 1173 representing an information entity. 1174


Associations: 1177 Attribute: An AggregateInformationEntity contains one or 1178

more attributes. 1179


1182

7.4.6 BasicInformationEntity: 1183 1184

BasicInformationEntity is a subtype of InformationEntity. It 1185 represents an information entity of a primitive type like string, 1186 integer, float, date. 1187




Tagged Values: 1188

type (enumerated: string, integer, date) 1189 1190

Associations: 1191 NONE (except as inherited from InformationEntity.) 1192


NONE 1194 1195

7.4.7 Attribute: 1196 An attribute is the use of an InformationEntity within a 1197 CompositeEntity. The attribute has a name within the composite 1198 entity, and may be flagged as required and/or repeating (using the 1199 multiple flag). The type of the attribute is the type of the 1200 InformationEntity it uses. 1201

Tagged Values: 1202 name the name of the attribute within this 1203

AggregateInformationEntity 1204 required boolean, if YES the attribute is required, else it is 1205

optional 1206 multiple boolean, if YES then more than one value of the 1207

attribute may supplied within one instance of the 1208 attribute. If not YES then only one value may be 1209 supplied. 1210

isLink boolean, if YES then the value of this attribute is 1211 a link to a place where the true value can be 1212 found. 1213

1214

Associations: 1215

owner An attribute belongs to only one 1216 AggregateInformationEntity. 1217

Type An attribute is of exactly one InformationEntity 1218 type. If that InformationEntity happens to be an 1219 AggregateInformationEntity then you in essence 1220 have nested attributes. 1221

1222


1225




1226

7.5 Choreography within Collaborations. 1227 1228 7.5.1 BusinessState 1229

A business state is any state that a binary collaboration can be in. 1230 Some business states are a snapshot right after or right before an 1231 activity, others are action states that denote the state of being in 1232 an activity. 1233

Tagged Values: 1234 none 1235

Associations: 1236

collaboration A business state belongs to only one binary 1237 collaboration 1238

entering A transition that reflects entry into this state 1239 exiting A transition that reflects exiting from this state 1240


NONE 1242

1243 7.5.2 Transition 1244

Choreography is expressed as transitions between business 1245 states 1246

Tagged Values: 1247

None 1248

Associations: 1249

in. The business state this transition is entering 1250 out. The business state this transition is exiting 1251 guard A transition may be governed by one or more 1252

guards 1253

Wellformedness Rules: 1254 A transition cannot enter and exit the same state 1255

1256 7.5.3 Start 1257

The starting state for an activity 1258





Associations: 1261 NONE 1262


NONE 1264

7.5.4 TerminalState 1265 The ending state of an activity, subclassed by success and failure 1266

Tagged Values: 1267 None 1268

Associations: 1269

None 1270

Wellformedness Rules: 1271 None 1272

7.5.5 Success 1273 A subtype of TerminalState which signifies the successful 1274 completion of an activity 1275

Tagged Values: 1276 None. 1277

Associations: 1278 None 1279

Wellformedness Rules: 1280 Every activity must have at least one success 1281

1282 7.5.6 Failure 1283

A subtype of TerminalState which signifies the failed completion of 1284 an activity 1285

Tagged Values: 1286 None. 1287

Associations: 1288 None 1289




Wellformedness Rules: 1290 Every activity must have at least one failure 1291

1292 7.5.7 SynchronizationState 1293

A business state where an activity is waiting for the completion of 1294 one or more other activities. 1295

Tagged Values: 1296

None 1297

Associations: 1298

None 1299

Wellformedness Rules: 1300 None 1301

1302 7.5.8 Guard 1303

The condition under which a transition may happen. 1304

Tagged Values: 1305

exclude. 1306 Precondition 1307

Associations: 1308

Transition The transition(s) that this guard governs 1309


Guards must refer only to the names and contents of document 1311 sets. 1312

1313

7.6 Definition and Scope 1314 The ebXML Specification Schema should be used wherever software is being 1315 specified to perform a role in an ebXML binary collaboration. Specifically The 1316 ebXML Specification Schema is intended to provide the business process and 1317 document specification for the formation of a trading partner Collaboration 1318 Protocol Profile and Agreement. A set of specification rules have been 1319 established to properly constrain the the expression of a business process and 1320 information model in a way that can be directly incorporated into a trading partner 1321 Collaboration Protocol Profile and Agreement. 1322




7.7 Collaboration Specification Rules 1323 The following rules are used to constrain the values of the parameters of the 1324 elements used to define a Commercial Collaboration. 1325

1326

7.7.1 Well-formedness Rules 1327 The following well-formedness rules apply to the definition of a Collaboration 1328 Specification. 1329

General 1330

[0] If non-repudiation is required then the input or returned business 1331 document must be a tamper-proofed entity. 1332

[1] If authorization is required then the input business document and 1333 business signal must be an authenticated or a tamper proofed secure 1334 entity. 1335

[2] The time to acknowledge receipt must be less than the time to 1336 acknowledge acceptance if both properties have values. 1337 1338 timeToAcknowledgeReceipt < timeToAcknowledgeAcceptance 1339

[3] If the time to acknowledge acceptance is null then the time to perform 1340 an activity must either be equal to or greater than the time to 1341 acknowledge receipt. 1342

[4] The time to perform a transaction cannot be null if either the time to 1343 acknowledge receipt or the time to acknowledge acceptance is not 1344 null. 1345

[5] If non-repudiation of receipt is required then the time to acknowledge 1346 receipt cannot be null. 1347

[6] The time to acknowledge receipt, time to acknowledge acceptance 1348 and time to perform cannot all be zero. 1349

[7] If non-repudiation is required at the requesting business activity, then 1350 there must be a responding business document. 1351

[8] The time to acknowledge receipt, time to acknowledge acceptance 1352 and time to perform properties must be specified for both the 1353 requesting and responding business activities and they must be 1354 equal. 1355

RequestingBusinessActivity 1356

[9] There must be one input transition whose source state vertex is an 1357 initial pseudo state. 1358

[10] There must be one output transition whose target state vertex is a 1359 final state specifying the state of the machine when the activity is 1360 successfully performed. 1361




[11] There must be one output transition whose target state vertex is a 1362 final state specifying the state of the machine when the activity is NOT 1363 successfully performed due to a process control exception. 1364

[12] There must be one output transition whose target state vertex is a 1365 final state specifying the state of the machine when the activity is NOT 1366 successfully performed due to a business process exception. 1367

[13] There must be one output DocumentEnvelope that in turn is the 1368 input to a responding business activity. 1369

[14] There must be zero or one output DocumentEnvelope from a 1370 requesting that in turn is the input to the requesting business activity. 1371

RespondingBusinessActivity 1372

[15] There must be one input transition from a DocumentEnvelope that 1373 in turn has one input transition from a requesting business activity. 1374

[16] There must be zero or one output transition to an 1375 DocumentEnvelope that in turn has an output transition to a 1376 requesting business activity. 1377

Information Entity 1378

[17] The associations on an information entity must be aggregation 1379 relationships with other information entities to form a partonomy, a 1380 hierarchical decomposable arrangement of business document parts. 1381

[18] The information entity associations only must be navigable from a 1382 containing entity to an element entity (has-part relationship). 1383

[19] Constraints on an information entity association must be specified 1384 on the role of the part (supplier) with respect to the whole (client). 1385

[20] The client and supplier of an entity association must not be the 1386 same entity. 1387

Business Collaboration 1388

[21] A business partner cannot provide both the initiating and 1389 responding roles of the same business transaction activity. 1390

1391 1392




8 Specification Schema – (DTD) 1393 In this section we describe the DTD version of the Specification Schema. This discussion 1394 includes 1395

• A listing of the DTD itself 1396 • A table listing all the elements found in the DTD with definitions and parent/child 1397

relationships 1398 • A table listing all the attributes found in the DTD with definitions and parent 1399

element relationships 1400 • A table listing all the elements found in the DTD, each with a cross reference to 1401

the corresponding class in the UML version of the specification schema 1402 • An example using the DTD 1403 • Rules about namespaces 1404

Additionally, following this section, a section will describe common modeling elements, 1405 including datatypes, and DTDs for common business signals. And a section after that 1406 describes the production rules we intend to follow for creating XML documents from a 1407 model instance against the UML specification schema. 1408

8.1 Documentation for the DTD 1409 1410

This section will document the DTD. The DTD has been derived from the UML 1411 model. The correlation between the UML entity and DTD element will be shown 1412 for each entity/element. 1413

1414 a. Attribute 1415

XML Element Name: attribute 1416 DTD Declaration: 1417

<!ELEMENT attribute (documentation?)> 1418 <!ATTLIST attribute 1419 name CDATA #REQUIRED 1420 type CDATA #REQUIRED 1421 required (true | false) "false" 1422 multiple (true | false) "false" 1423 isLink (true | false) "false"> 1424

1425 Definition: 1426

Defines one element of a document. 1427 1428

Parent Elements: 1429

• Document 1430 1431




Attributes: 1431 Attribute Name

Definition Default Value

name Defines the name of a model element. This name must be unique within the context of the model element and will be used to reference the element from other points in the model.

Required Input. A value must be present. Names may only contain the characters a-z, A-Z, 0-9, _

type The type of one element as defined by another, referenced element. If type is not supplied it shall be the same as name.

No default value. A value must be present. Names may only contain the characters a-z, A-Z, 0-9, _

required Defines that the attribute or content must be part of an instance of the aggregate.

false

Valid values {true, false}

multiple Defines that the attribute may be repeated multiple times within the aggregate.

false


isLink Defines that the attribute references an external document (document not passed in the same document set) of the given data type.

false


1432 b. Binary Collaboration 1433

XML Element Name: binary-collaboration 1434 DTD Declaration: 1435

<!ELEMENT binary-collaboration ((documentation | 1436 business-transaction-activity | 1437 collaboration-activity | 1438 sync-state | start | transition | 1439 success | failure)*)> 1440 <!ATTLIST binary-collaboration 1441 name CDATA #REQUIRED 1442 initiator CDATA #REQUIRED 1443 responder CDATA #REQUIRED 1444 timeToPerform CDATA #IMPLIED 1445 timeUnit (milliseconds | seconds | 1446 minutes | hours | days | 1447 weeks | months | years) "minutes"> 1448

1449 1450




Definition: 1451 Defines a contract of interaction between two business roles. 1452

Parents: 1453 • Package 1454

Attributes: 1455 1456

Attribute Name




initiator Name of the initiating role in a binary-collaboration.


responder Name of the responding role in a binary-collaboration


timeToPerform

Time allowed for execution of the collaboration

zero


timeUnit For each timing parameter set defined the time unit may also be set.

minutes

Valid values {milliseconds, seconds, minutes, hours, days, weeks, months, years}

1457 1458




Hierarchical Model: 1458

1459 1460 1461

1462 1463 1464 1465 1466 1467 1468 1469 1470

c: Business Partner 1471

1472

Element Name: business-partner 1473 DTD Declaration: 1474

<!ELEMENT business-partner (documentation?, performs+)> 1475 <!ATTLIST business-partner 1476 name CDATA #REQUIRED> 1477 1478

Parents: 1479

• multi-party-collaboration 1480 1481 Attributes: 1482

Attribute Name


name Defines the name of a model element. This name must be unique within the context of

Required Input. A value must




name must be unique within the context of the model element and will be used to reference the element from other points in the model.

A value must be present. Names may only contain the characters a-z, A-Z, 0-9, _

1483 d: Business Transaction Activity 1484

Element Name: business-transaction-activity 1485 Content Model: 1486

<!ELEMENT business-transaction-activity (documentation?)> 1487 <!ATTLIST business-transaction-activity 1488 name CDATA #REQUIRED 1489 type CDATA #IMPLIED 1490 from CDATA #REQUIRED 1491 to CDATA #REQUIRED 1492 timeToPerform CDATA #IMPLIED 1493 timeUnit (milliseconds | seconds | minutes | 1494 hours | days | weeks | months | years) 1495 "minutes" 1496 isConcurrent (true | false) "false"> 1497

1498 Definition: 1499

Defines the use of a business transaction within a binary collaboration. The first 1500 activity must have the "from" attribute match the "initiator" in the binary-1501 collaboration. After the first activity "from" and "to" must match either the 1502 "initiator" or "responder" in the binary collaboration. 1503 1504







from The name of the role initiating the activity. No default value. A value




value. A value must be present. Names may only contain the characters a-z, A-Z, 0-9, _

to Name of the role responding to the activity. The activity must be the same collaboration.


timeToPerform

Time to execute this transaction within this collaboration

zero



minutes


isConcurrent

Multiple instances of this transaction activity can run concurrently

false

1506 e. Business Transaction/Requesting Business Activity/Responding 1507

Business Activity 1508

Element Name: business-transaction 1509 DTD Declaration: 1510

<!ELEMENT business-transaction (documentation?, request, 1511 response*)> 1512 <!ATTLIST business-transaction 1513 name CDATA #REQUIRED 1514 isNonReputiationReceiptRequired (true | false) 1515 #IMPLIED 1516 isIntelligibleCheckRequired (true | false) #IMPLIED 1517 isAuthorizationRequired (true | false) #IMPLIED 1518 isSecureTransportRequired (true | false) #IMPLIED 1519 isGuaranteedDeliveryRequired (true | false) #IMPLIED 1520 isNonRepudiationRequired (true | false) #IMPLIED 1521 isNonRepudiationReceiptRequired (true | false) 1522 #IMPLIED 1523 timeToAcknowledge CDATA #IMPLIED 1524 timeToAcknowledgeReceipt CDATA #IMPLIED 1525 timeToPerform CDATA #IMPLIED 1526




timeUnit (milliseconds | seconds | minutes | 1527 hours | days | weeks | months | years) 1528 "minutes"> 1529

Definition: 1530 Defines the most atomic unit of interchange between business partners 1531 consisting of a request and, potentially, a reply with intermediate handshake 1532 signals as defined by business patterns. 1533



Attribute Name




isIntelligibleCheckRequired

Must validate readability No Default


isAuthorizationRequired

sending partner role must sign the business document exchanged and the receiving partner role must validate

No Default


isSecureTransportRequired

Requires secure transport of message No Default


isGuaranteedDeliveryRequired

Requires guaranteed delivery of message No Default


isNonRepudiationRequired

must store the business document in its original form

No Default


isNonRepudiationReceiptRequired

Must mutually verify receipt of a requesting business document and that the receipt must be non-reputable

No Default


timeToAcknowledge

Time from initial request to acceptanceAcknowledgement

No default value. A value must be present. Names may




only contain the characters a-z, A-Z, 0-9, _

timeToAcknowledgeReceipt

Time from initial request to receiptAcknowledgement


timeToPerform

Time to perform this business transaction or activity

zero



minutes


1538 f. Collaboration Activity 1539

Element Name: collaboration-activity 1540 DTD Declaration: 1541

<!ELEMENT collaboration-activity (documentation?)> 1542 <!ATTLIST collaboration-activity 1543 name CDATA #REQUIRED 1544 type CDATA #IMPLIED 1545 from CDATA #REQUIRED 1546 to CDATA #REQUIRED 1547

Definition: 1548 Defines the use of one binary collaboration within another. The first activity must 1549 have the "from" attribute match the "initiator" in the binary-collaboration. After the 1550 first activity "from" and "to" must match either the "initiator" or "responder" in the 1551 binary-collaboration. 1552

Parents: 1553

• Binary collaboration 1554 Attributes: 1555

Attribute Name


name Defines the name of a model element. This name must be unique within the context of the model element and will be used to reference the element from other points in the

Required Input.




model.


No default value.

from The name of the role initiating the activity.

Required Input


Required Input.

1556 g. Content 1557

Element Name: content 1558 DTD Declaration: 1559

<!ELEMENT content (documentation?)> 1560 <!ATTLIST content 1561 name CDATA #REQUIRED 1562 type CDATA #REQUIRED 1563 required (true | false) "false" 1564 isLink (true | false) "false" 1565 isConfidential (true | false) "false" 1566 isTamperProof (true | false) "false" 1567 isAuthenticated (true | false) "false" 1568 > 1569

Definition: 1570 Defines one element of an aggregate document set 1571




Required Input.

required Defines that the attribute or content must be part of an instance of the aggregate.

false


isLink

Defines that the attribute references an external document (document not passed in the same document set) of the given data type.

false


isConfidential

The information entity is encrypted so that unauthorized parties cannot view the information

false


isTamperProof

The information entity has an encrypted message digest that can be used to check if

false




roof the message has been tampered with Valid values {true, false}

isAuthenticated

There is a digital certificate associated with the document entity

false


1573 1574

h. Basic Information Entity 1575

Element Name: data-type 1576 DTD Declaration: 1577

<!ELEMENT data-type (documentation?)> 1578 <!ATTLIST data-type 1579 name CDATA #REQUIRED> 1580

Definition: 1581 Defines a new, primitive data type in a package in addition to the built-in primitive 1582 types. There must be prior agreement as to the structure of the data type. 1583


Attributes: 1586

Attribute Name




1587 i. Structured Document 1588

Element Name: document 1589 DTD Declaration: 1590

<!ELEMENT document (documentation?, attribute*)> 1591 <!ATTLIST document 1592 name CDATA #REQUIRED 1593 supertype CDATA #IMPLIED 1594 isConfidential (true | false) "false" 1595 isTamperProof (true | false) "false" 1596 isAuthenticated (true | false) "false"> 1597

Definition: 1598 Defines data types in a package composed of other data types (using attributes) 1599 that can be used in document sets. 1600

Parents: 1601




• Package 1602 Attributes: 1603

Attribute Name



Required Input

supertype The name of an aggregate which forms the base of another aggregate. All attributes of the referenced supertype shall become attributes of the aggregate being defined.

No default value

isConfidential


false


isTamperProof

The information entity has an encrypted message digest that can be used to check if the message has been tampered with

false


isAuthenticated


false


1604 1605

j. Documentation (NOTE: No UML Entity) 1606

Element Name: documentation 1607 DTD Declaration: 1608

<!ELEMENT documentation ANY> 1609 1610

Definition: 1611 Defines user documentation for any element which must be the first element of 1612 it's container. The documentation must be in the form of XHTML. 1613

Parents: 1614 • attribute 1615 • binary-collaboration 1616 • business-partner 1617 • business-transaction 1618 • business-transaction-activity 1619 • collaboration-activity 1620 • content 1621 • data-type 1622 • document 1623




• document-set 1624 • ebxmlprocessspecification 1625 • failure 1626 • include 1627 • multi-party-collaboration 1628 • package 1629 • performs 1630 • request 1631 • response 1632 • start 1633 • success 1634 • sync-state 1635 • transition 1636 • unstructured 1637

1638 k. DocumentSet 1639

Element Name: document-set 1640 DTD Declaration: 1641

<!ELEMENT document-set (documentation?, content*)> 1642 <!ATTLIST document-set 1643 name CDATA #REQUIRED 1644 isConfidential (true | false) "false" 1645 isTamperProof (true | false) "false" 1646 isAuthenticated (true | false) "false"> 1647

Definition: 1648 Defines a set of structured or unstructured documents which may be used in a 1649 business transaction. 1650

Parents: 1651 • package 1652 1653


Attribute Name



Required Input

IsConfidential


false


isTamperProof


false





isAuthenticated


false


1656 l. ebXML Specification 1657

Element Name: ebXmlProcessSpecification 1658 DTD Declaration: 1659

<!ELEMENT EbXmlProcessSpecification ((package | include | 1660 documentation)*)> 1661 <!ATTLIST EbXmlProcessSpecification 1662 name CDATA #REQUIRED 1663 uuid CDATA #IMPLIED 1664 version CDATA #IMPLIED> 1665 1666

Definition: 1667 Root element of a process specification document which has a globally unique 1668 identity. 1669




Required Input

uuid Unique Identifier No Default Value

version Version of the specification No Default Value

1671 Hierarchical Model: 1672

1673

m. Transition/Failure 1674

Element Name: failure 1675 DTD Declaration: 1676

<!ELEMENT failure (documentation?)> 1677 <!ATTLIST failure 1678 from CDATA #REQUIRED 1679 guard CDATA #IMPLIED 1680




condition (success | failure | technical-failure 1681 | business-failure | any) "any"> 1682

Definition: 1683 Defines the unsuccessful conclusion of a binary collaboration as a transition from 1684 an activity. 1685

Parents: 1686

• binary-collaboration 1687 Attributes: 1688

Attribute Name


from The name of the role initiating the activity.

Required Input.

guard Name of the document set which must have been the last set sent or returned from the originating activity for the transition to transfer control.

No default value.

condition The status of the orginating activity which must be met for the transition to transfer control. If both the condition and guard are set, both must be true.

Any

Allowed Values: {success, failure, technica-failure, business-failure, any}

1689 n. Include 1690

Element Name: include 1691 DTD Declaration: 1692

<!ELEMENT include (documentation?)> 1693 <!ATTLIST include 1694 name CDATA #REQUIRED 1695 uri CDATA #REQUIRED 1696 uuid CDATA #IMPLIED 1697 version CDATA #IMPLIED> 1698

Definition: 1699 Includes another process specification document and merges that specification 1700 with the current specification. Any elements of the same name and in the same 1701 name scope must have exactly the same specification except that packages may 1702 have additional content. 1703 Documents are merged based on name scope. A name in an included package 1704 will be indistinguishable from a name in the base document. 1705

Parents: 1706 • EbXmlProcessSpecification 1707







Required Input

uri Uniform Resource Indicator. No Default Value

uuid Unique Identifier No Default Value

version Version of the specification No Default Value

1709 1710

o. MultiParty Collaboration 1711

Element Name: multi-party-collaboration 1712 DTD Declaration: 1713

<!ELEMENT multi-party-collaboration (documentation?, 1714 business-partner+)> 1715 <!ATTLIST multi-party-collaboration 1716 name CDATA #REQUIRED> 1717

Definition: 1718 Defines the business partner roles and the binary collaborations they perform as 1719 part of an ebXML business process. 1720

Parents: 1721

• Package 1722 Attributes: 1723

Attribute Name



Required Input

1724 p. Package 1725

Element Name: package 1726 DTD Declaration: 1727

<!ELEMENT package ((documentation | package | 1728 business-transaction | 1729




binary-collaboration | data-type | 1730 document | document-set | unstructured 1731 | multi-party-collaboration)*)> 1732 <!ATTLIST package 1733 name CDATA #REQUIRED> 1734

Definition: 1735 Defines a hierarchical name scope containing reusable elements. 1736

Parents: 1737

• ebXmlProcessSpecification 1738 • package 1739

1740 Attributes: 1741 1742

Attribute Name



Required Input

1743 Hierarchical Model: 1744 1745

q. Performs 1746 Element Name: performs 1747 DTD Declaration: 1748

<!ELEMENT performs (documentation?)> 1749 <!ATTLIST performs 1750 service CDATA #REQUIRED 1751 role CDATA #REQUIRED> 1752

Definition: 1753 Defines which roles in a binary collaboration a business partner role will 1754 implement. 1755

Parents: 1756




• business-partner 1757 Attributes: 1758

Attribute Name


service Name of the binary collaboration which will be performed by the business partner role.

Required Input

role Name of the role in the binary collaboration which will be performed by the business partner role.

Required Input

1759 1760 1761

r. Document Envelope - Request/Result 1762 Element Name: request 1763 DTD Declaration: 1764

<!ELEMENT request (documentation?)> 1765 <!ATTLIST request 1766 type CDATA #REQUIRED> 1767

Definition: 1768 Defines the request part of a busines-transaction which references the 1769 document-set which will be part of that request. 1770 If the type of the request is a document, a document set which contains that 1771 document will be implicitly created. 1772

Parents: 1773 • business-transaction 1774



type The type of one element as defined by another referenced element. If type is not supplied it shall be the same as name.Either the last sentence should be deleted or the default value should be #IMPLIED.

Required Input

1776 s. Document Envelope - Response/Result 1777

Element Name: response 1778 DTD Declaration: 1779

<!ELEMENT response (documentation?)> 1780 <!ATTLIST response 1781 type CDATA #REQUIRED 1782 status (success | failure) "success"> 1783

Definition: 1784




Defines the eresponse part of a business-transaction which references the 1785 document-set which will be part of that request. There may be multiple response 1786 elements indicating potential return scenarios. 1787 If the type of request is a document, a document set which contains that 1788 document will be implicitly created. 1789

Parents: 1790 • business-transaction 1791

Attributes: 1792

Attribute Name


type The type of one element as defined by another referenced element. If type is not supplied it shall be the same as name.

Required Input

status Defines the termination status of the business-transaction for the given document set type.

success

Allowed Values:

{success, failure}

1793 1794

t. Start 1795

Element Name: start 1796 DTD Declaration: 1797

<!ELEMENT start (documentation?)> 1798 <!ATTLIST start 1799 to CDATA #REQUIRED> 1800

Definition: 1801 Defines a start activity. A binary collaboration must have at least one start 1802 activity and that activity must be “to” the “initiator”. 1803

Parents: 1804 • binary-collaboration 1805




Required Input

1807 1808

u. Transition/Success 1809

Element Name: success 1810




DTD Declaration: 1811 <!ELEMENT success (documentation?)> 1812 <!ATTLIST success 1813 from CDATA #REQUIRED 1814 guard CDATA #IMPLIED 1815 condition (success | failure | technical-failure 1816 | business-failure | any) "any"> 1817

Definition: 1818 Defines the successful conclusion of a binary collaboration as a transition from 1819 an activity. 1820




from The name of the role initiating the activity. Required Input.


No default value.


Any


1824 v. SyncState 1825

Element Name: sync-state 1826 DTD Declaration: 1827

<!ELEMENT sync-state (documentation?)> 1828 <!ATTLIST sync-state 1829 name CDATA #REQUIRED 1830 any (true | false) "false"> 1831

Definition: 1832 Defines the point of intersection between concurrent activities. 1833








Required Input

any false

Allowed Values:

{true, false}

1837

w. Transition 1838

ELEMENT Name: transition 1839 DTD Declaration: 1840

<!ELEMENT transition (documentation?)> 1841 <!ATTLIST transition 1842 to CDATA #REQUIRED 1843 guard CDATA #IMPLIED 1844 condition (success | failure | technical-failure 1845 | business-failure | any) "any" 1846 from CDATA #REQUIRED> 1847

Definition: 1848 Defines the capability for a collaboration to transition from one state to another 1849 provided the guard and condition has been met. 1850





Required Input.


No default value.


Any


from The name of the role initiating the activity. Required Input.




1854 1855

x. Unstructured 1856

Element Name: unstructured 1857 DTD Declaration: 1858

<!ELEMENT unstructured (documentation?)> 1859 <!ATTLIST unstructured 1860 name CDATA #REQUIRED 1861 mimeType CDATA #IMPLIED 1862 isConfidential (true | false) "false" 1863 isTamperProof (true | false) "false" 1864 isAuthenticated (true | false) "false"> 1865 If this will point to an external object, i.e., movies, 1866 then the name attribute should be type ENTITY and not 1867 CDATA. 1868 1869 1870

Definition: 1871 Defines a document type in a package where the structure of that document is 1872 determined external to the ebXML specification. Used for movies, picutres, EDI 1873 documents, etc. May also be used for XML documents that fall outside the ebXml 1874 document model. 1875





Required Input.

mimetype Specified the MIME type that will implement an unstructured document. The string must conform to the MIME type name.

No Default Value.

isConfidential


false


isTamperProof


false


isAuthenticated


false




ated the document entity Valid values {true, false}

1879 Additionally, following this section, a section will describe common modeling 1880 elements, including datatypes, and DTDs for common business signals. And a 1881 section after that describes the production rules we intend to follow for creating 1882 XML documents from a model instance against the UML specification schema. 1883

8.2 DTD 1884 1885

This is the Specification Schema DTD: 1886

1887

1888 <?xml version="1.0" encoding="UTF-8"?> 1889

1890

<!ELEMENT EbXmlProcessSpecification ((package | include | documentation)*)> 1891 <!ATTLIST EbXmlProcessSpecification 1892

name CDATA #REQUIRED 1893

uuid CDATA #IMPLIED 1894

version CDATA #IMPLIED 1895

> 1896

<!ELEMENT include (documentation?)> 1897

<!ATTLIST include 1898 name CDATA #REQUIRED 1899

uri CDATA #REQUIRED 1900

uuid CDATA #IMPLIED 1901

version CDATA #IMPLIED 1902

> 1903

<!ELEMENT package ((documentation | package | business-transaction | binary-1904 collaboration | data-type | 1905 document | document-set | unstructured | multi-party-collaboration)*)> 1906

<!ATTLIST package 1907


> 1909

<!ELEMENT data-type (documentation?)> 1910

<!ATTLIST data-type 1911





> 1913

<!ELEMENT document (documentation?, attribute*)> 1914

<!ATTLIST document 1915 name CDATA #REQUIRED 1916

supertype CDATA #IMPLIED 1917

isConfidential (true | false) "false" 1918

isTamperProof (true | false) "false" 1919

isAuthenticated (true | false) "false" 1920

> 1921

<!ELEMENT attribute (documentation?)> 1922

<!ATTLIST attribute 1923 name CDATA #REQUIRED 1924

type CDATA #REQUIRED 1925

required (true | false) "false" 1926

multiple (true | false) "false" 1927

isLink (true | false) "false" 1928

> 1929

<!ELEMENT unstructured (documentation?)> 1930 <!ATTLIST unstructured 1931


mimeType CDATA #IMPLIED 1933




> 1937 <!ELEMENT documentation ANY> 1938

<!ELEMENT document-set (documentation?, content*)> 1939

<!ATTLIST document-set 1940





> 1945




<!ELEMENT content (documentation?)> 1946

<!ATTLIST content 1947


type CDATA #REQUIRED 1949 required (true | false) "false" 1950

isLink (true | false) "false" 1951




> 1955

<!ELEMENT business-transaction (documentation?, request, response*)> 1956

<!ATTLIST business-transaction 1957 name CDATA #REQUIRED 1958

isNonReputiationReceiptRequired (true | false) #IMPLIED 1959

isIntelligibleCheckRequired (true | false) #IMPLIED 1960

isAuthorizationRequired (true | false) #IMPLIED 1961

isSecureTransportRequired (true | false) #IMPLIED 1962

isGuaranteedDeliveryRequired (true | false) #IMPLIED 1963

isNonRepudiationRequired (true | false) #IMPLIED 1964 isNonRepudiationReceiptRequired (true | false) #IMPLIED 1965

timeToAcknowledge CDATA #IMPLIED 1966

timeToAcknowledgeReceipt CDATA #IMPLIED 1967

timeToPerform CDATA #IMPLIED 1968

timeUnit (milliseconds | seconds | minutes | hours | days | weeks | months 1969 | years) "minutes" 1970

> 1971 <!ELEMENT request (documentation?)> 1972

<!ATTLIST request 1973


> 1975

<!ELEMENT response (documentation?)> 1976

<!ATTLIST response 1977


status (success | failure) "success" 1979




> 1980

<!ELEMENT binary-collaboration ((documentation | business-transaction-activity 1981 | collaboration-activity | sync-state | start | transition | success | failure)*)> 1982

<!ATTLIST binary-collaboration 1983 name CDATA #REQUIRED 1984

initiator CDATA #REQUIRED 1985

responder CDATA #REQUIRED 1986



> 1990

<!ELEMENT collaboration-activity (documentation?)> 1991 <!ATTLIST collaboration-activity 1992


type CDATA #IMPLIED 1994

from CDATA #REQUIRED 1995

to CDATA #REQUIRED 1996

> 1997

<!ELEMENT sync-state (documentation?)> 1998 <!ATTLIST sync-state 1999


any (true | false) "false" 2001

> 2002

<!ELEMENT business-transaction-activity (documentation?)> 2003

<!ATTLIST business-transaction-activity 2004

name CDATA #REQUIRED 2005 type CDATA #IMPLIED 2006





isConcurrent (true | false) "false" 2012

> 2013 <!ELEMENT transition (documentation?)> 2014




<!ATTLIST transition 2015


guard CDATA #IMPLIED 2017

condition (success | failure | technical-failure | business-failure | any) 2018 "any" 2019


> 2021

<!ELEMENT success (documentation?)> 2022

<!ATTLIST success 2023



condition (success | failure | technical-failure | business-failure | any) "any" 2026 > 2027

<!ELEMENT failure (documentation?)> 2028

<!ATTLIST failure 2029



condition (success | failure | technical-failure | business-failure | any) "any" 2032

> 2033 <!ELEMENT start (documentation?)> 2034

<!ATTLIST start 2035


> 2037

<!ELEMENT multi-party-collaboration (documentation?, business-partner+)> 2038

<!ATTLIST multi-party-collaboration 2039

name CDATA #REQUIRED 2040 > 2041

<!ELEMENT business-partner (documentation?, performs+)> 2042

<!ATTLIST business-partner 2043


> 2045

<!ELEMENT performs (documentation?)> 2046

<!ATTLIST performs 2047

service CDATA #REQUIRED 2048




role CDATA #REQUIRED 2049

> 2050

2051

8.3 XML to UML cross-reference 2052 2053

The following is a table that references the XML element names in the DTD to 2054 their counterparts in the UML specification schema. 2055

2056 XML Element

Schema Element

attribute Attribute

binary- collaboration

Binary Collaboration

business- partner- Role

Business Partner Role

business- transaction- activity

Business Transaction Activity

business-transaction

Business Transaction,

Requesting Business Activity,

Responding Business Activity

collaboration-activity

Collaboration Activity

content Content

data-type Basic Information Entity

document Structured Document

documentation

None (Should be added)

document-set

DocumentSet




ebXml Process Specification

ebXml Process Specification

failure Transition, Failure.

(Failure state is implicitly created)

multi-party- collaboration

MultiParty Collaboration

package Package

performs Performs

request Document Envelope and “requesting” relation.

“Result” and associated relation to document set.

Potentially creates the document set.

response Document Envelope and “responding” relation will be created by the first response.

“Result” and associated relation to document set.

Potentially creates the document set.

start Defines a start state

success Transition, Success (Success state is implicitly created)




implicitly created)

sync-state

SyncState

timing

transition Transition

unstructured

Unstructured Document

2057

8.4 Scoped Name Reference 2058 Specification elements reference other specification elements by name. EbXML 2059 specification element names are all contained within a name scope, usually a 2060 package. The set of packages describes a hierarchical name space, much like a 2061 directory structure. 2062

The name of the element defined by it’s “name” attribute is the “simple name” of 2063 the element. The simple name is sufficient to reference that element within the 2064 same name scope or any parent name scope. Simple names may only contain 2065 the characters: a—z, A..Z, 0..9, “_”. 2066

The name scope that contains another named element is referred to as the 2067 “parent” of that named element and the contained element is the “child” of the 2068 parent scope. 2069 The “current” name scope is the one from which the scoped name reference is 2070 made. 2071

A simple name is “in scope”, that is can be resolved, if it is in the current name 2072 scope or a parent name scope. 2073

To access elements in other name scopes the name reference must be qualified. 2074

A name qualifier shall precede the simple name with a slash (“/”) character 2075 separating the two names. The qualifying name shall specify the simple name of 2076 the scope in which the simple name may be found. Since a package also has a 2077 name within a name scope, it can also be qualified. Thus qualified names my 2078 reference any depth in the namespace hierarchy. 2079

The first simple name in a qualified name shall be the root. The current name 2080 space shall be searched for the root and, if found, shall resolve that part of the 2081 name. If the root is not found in the current name scope the parent scope shall 2082 be searched, recursively, until the root is found. If the scoped name starts with 2083 “/” the root namespace shall be the one defined by EbXmlProcessSpecification. 2084

Examples of scoped names: 2085

“Foo” (Simple name) 2086




“Billing/invoice” (Name “invoice” found in “Billing” package) 2087

“/accounting/billing/foo” (name “foo” found in “billing” package found in 2088 “accounting” package which is in the ebXmlProcessSpecification) 2089

2090

8.5 Sample XML document against above DTD 2091 <?xml version="1.0"?> 2092

2093

<!DOCTYPE EbXmlProcessSpecification SYSTEM 2094 "ebXmlSpecificationDTD091.dtd"> 2095

<EbXmlProcessSpecification name="GenericQuoteOrder" 2096

version="1.1" uuid="[1234-5678-901234]"> 2097

<package name="Ordering"> 2098

<data-type name="currency"/> 2099 <document name="QuoteRequest"> 2100

<documentation> 2101

This is an example of a minimal order or quote. 2102

</documentation> 2103

2104

<attribute name="ID" type="String" required="true"/> 2105

<attribute name="customerID" type="String" required="true"/> 2106 <attribute name="Items" type="LineItem" multiple="true"/> 2107

</document> 2108

<document-set name="QuoteRequestSet"> 2109

<content name="QuoteRequest" type="QuoteRequest" /> 2110

</document-set> 2111

2112

<document name="Order" supertype="QuoteRequest" 2113 isTamperProof="true"> 2114

<attribute name="total" type="Decimal" required="true"/> 2115

<attribute name="creditCard" type="String" /> 2116

</document> 2117

<document-set name="OrderSet" isConfidential="true"> 2118

<content name="Order" type="Order" isSignatureEntity="true"/> 2119





2121

<unstructured name="image" mimeType="image"/> 2122

2123

<document name="LineItem"> 2124 <documentation> 2125

This is an example of a minimal order line item, used as an attribute 2126

in order and quote. 2127

</documentation> 2128

<attribute name="partID" type="String" required="true"/> 2129

<attribute name="specialInstructions" type="String"/> 2130

<attribute name="quantity" type="Float" required="true"/> 2131

<attribute name="price" type="Decimal" required="false"/> 2132 <attribute name="picture" type="image"/> 2133

</document> 2134

2135

<document name="OrderConfirmation"> 2136


<attribute name="OrderNumber" type="Integer"/> 2138

<attribute name="customerID" type="String" 2139 required="true"/> 2140

<attribute name="total" type="Currency" required="true"/> 2141

<attribute name="expectedShipDate" type="Date"/> 2142

</document> 2143

<document-set name="OrderConfirmationSet"> 2144

<content name="OrderConfirmation" type="OrderConfirmation" 2145 isAuthenticated="true"/> 2146 </document-set> 2147

2148

<document name="OrderDenied"> 2149

<attribute name="ID" type="Integer" required="true"/> 2150


<attribute name="reason" type="Text"/> 2153

</document> 2154 <document-set name="OrderDeniedSet"> 2155




<content name="OrderDenied" type="OrderDenied" /> 2156


2158

<document name="Quote"> 2159 <attribute name="QuoteNumber" type="Integer"/> 2160

<attribute name="Request" type="QuoteRequest" 2161 required="true"/> 2162

<attribute name="Price" type="Currency" required="true"/> 2163

<attribute name="Delivery" type="Date" required="false"/> 2164

<attribute name="GoodUntil" type="Date" 2165 required="false"/> 2166

</document> 2167 <document-set name="QuoteSet"> 2168

<content name="Quote" type="Quote" /> 2169


2171

<document name="ShippingNotice"> 2172


<attribute name="OrderNumber" type="Integer"/> 2174 <attribute name="customerID" type="String" 2175 required="true"/> 2176

<attribute name="shipDate" type="Date"/> 2177

</document> 2178

<document-set name="ShippingNoticeSet"> 2179

<content name="ShippingNotice" type="ShippingNotice" /> 2180

</document-set> 2181 2182

<document name="PaymentNotice"> 2183


<attribute name="OrderNumber" type="Integer"/> 2185


<attribute name="amount" type="Currency"/> 2188

<attribute name="payDate" type="Date"/> 2189 </document> 2190




<document-set name="PaymentNoticeSet"> 2191

<content name="PaymentNotice" type="PaymentNotice" /> 2192


2194  2199

<business-transaction name="OrderBT" isNonRepudiationRequired="true"> 2200

<request type="OrderSet"/> 2201

<response type="OrderConfirmationSet" 2202 status="success"/> 2203

<response type="OrderDeniedSet" status="failure"/> 2204

</business-transaction> 2205

<business-transaction name="QuoteBT" timeToPerform="1" 2206 timeUnit="days"> 2207

<request type="QuoteRequestSet"/> 2208

<response type="QuoteSet" status="success"/> 2209 </business-transaction> 2210

<business-transaction name="ShippingNotice" 2211 isSecureTransportRequired="false" > 2212

<request type="ShippingNoticeSet"/> 2213


<business-transaction name="PaymentNotice"> 2215

<request type="PaymentNoticeSet"/> 2216 </business-transaction> 2217

 2226

<binary-collaboration name="OrderCollaboration" initiator="buy" 2227

responder="sell" timeToPerform="2" timeUnit="days"> 2228

<business-transaction-activity name="OrderBT" 2229 from="buy" to="sell"/> 2230

<business-transaction-activity name="ShippingNotice" 2231 from="sell" to="buy"/> 2232

<business-transaction-activity name="PaymentNotice" 2233 from="buy" to="sell"/> 2234

<start to="OrderBT"/> 2235

<transition from="OrderBT" guard="OrderConfirmationSet" 2236 to="ShippingNotice"/> 2237 <transition from="ShippingNotice" to="PaymentNotice"/> 2238

<success from="PaymentNotice"/> 2239

<failure from="OrderBT" condition="failure"/> 2240

</binary-collaboration> 2241

 2245

<binary-collaboration name="QuoteOrderCollaboration" 2246 initiator="buy" responder="sell"> 2247

<business-transaction-activity name="QuoteBT" 2248 from="buy" to="sell"/> 2249

 2252

<collaboration-activity name="OrderIt" 2253 type="OrderCollaboration" from="buy" to="sell"/> 2254

<start to="QuoteBT"/> 2255

<transition from="QuoteBT" to="OrderIt"/> 2256

<success from="OrderIt" guard="success"/> 2257

<failure from="OrderIt" guard="failure"/> 2258

</binary-collaboration> 2259  2262

<multi-party-collaboration name="BuySell"> 2263

<business-partner name="buyer"> 2264

<performs service="QuoteOrderCollaboration" 2265 role="buy"/> 2266

</business-partner> 2267

<business-partner name="seller"> 2268

<performs service="QuoteOrderCollaboration" 2269 role="sell"/> 2270


</multi-party-collaboration> 2272

2273 </package>  2274

2275

<package name="shipping"> 2276

2277

 2278

<document name="party"> 2279

<attribute name="name" type="String" required="true"/> 2280 <attribute name="address1" type="String" /> 2281

<attribute name="address2" type="String" /> 2282

<attribute name="city" type="String" /> 2283

<attribute name="state" type="String" /> 2284

<attribute name="country" type="String" /> 2285

<attribute name="postCode" type="String" /> 2286

<attribute name="phone" type="String" /> 2287 <attribute name="ParyID" type="String" required="true"/> 2288

<attribute name="contact" type="String" /> 2289

</document> 2290

2291

<unstructured name="AnyDocument" /> 2292

2293

<document name="Waybill"> 2294

<attribute name="shipFrom" type="party" required="true"/> 2295




<attribute name="shipTo" type="party" required="true"/> 2296

<attribute name="via" type="String" /> 2297

<attribute name="shipDate" type="String" required="true"/> 2298

<attribute name="ShipID" type="string" required="true"/> 2299 <attribute name="content" type="String" /> 2300

<attribute name="instructions" type="Text" /> 2301

<attribute name="legalDocuments" type="AnyDocument" 2302 multiple="true" /> 2303

</document> 2304

<document-set name="WaybillSet"> 2305

<content name="Waybill" type="Waybill" /> 2306

</document-set> 2307 2308

<document name="PickupReceipt"> 2309

<attribute name="id" type="String" /> 2310

<attribute name="when" type="DateType" /> 2311

<attribute name="from" type="party" /> 2312

</document> 2313

<document-set name="PickupReceiptSet"> 2314 <content name="PickupReceipt" type="PickupReceipt" /> 2315


2317

<document name="WaybillIncomplete"> 2318

<attribute name="waybill" type="WayBillSet" /> 2319

<attribute name="reason" type="Text" /> 2320

</document> 2321 <document-set name="WaybillIncompleteSet"> 2322

<content name="WaybillIncomplete" type="WaybillIncomplete" /> 2323


2325

<document name="DeliveryReceipt" > 2326

<attribute name="ID" type="String" required="true" /> 2327

<attribute name="party" type="Party" required="true" /> 2328

<attribute name="when" type="Date" /> 2329




</document> 2330

<document-set name="DeliveryReceiptSet"> 2331

<content name="DeliveryReceipt" type="DeliveryReceipt" 2332 isTamperProof="true"/> 2333 </document-set> 2334

2335

<business-transaction name="ShippingBT" 2336 isIntelligibleCheckRequired="true"> 2337

<request type="WaybillSet"/> 2338

<response type="PickupReceiptSet" status="success"/> 2339

<response type="WaybillIncompleteSet" status="failure"/> 2340

</business-transaction> 2341 <business-transaction name="DeliveryAcknoledgementBT"> 2342

<request type="DeliveryReceiptSet"/> 2343


2345

<binary-collaboration name="ShipCollaboration" initiator="send" 2346 responder="ship"> 2347

<business-transaction-activity name="ShippingBT" 2348 from="send" to="ship"/> 2349

<business-transaction-activity 2350 name="DeliveryAcknowledgementBT" from="ship" to="send"/> 2351

<start to="ShippingBT"/> 2352

<transition from="ShippingBT" condition="success" 2353 to="DeliveryAcknowledgementBT"/> 2354

<success from="DeliveryAcknowledgementBT"/> 2355 <failure from="ShippingBT" guard="failure"/> 2356

</binary-collaboration> 2357

 2364

<multi-party-collaboration name="BuySellShip"> 2365




<business-partner name="buyer"> 2366

<performs service="ordering/OrderCollaboration" role="buy"/> 2367


<business-partner name="seller"> 2369 <performs service="ordering/OrderCollaboration" role="sell"/> 2370

<performs service="ShipCollaboration" 2371 role="send"/> 2372


<business-partner name="carrier"> 2374

<performs service="ShipCollaboration" 2375 role="ship"/> 2376

</business-partner> 2377 </multi-party-collaboration> 2378

</package> 2379

</EbXmlProcessSpecification> 2380

2381

2382

9 Common Modeling Elements 2383

9.1 Datatyping 2384 2385

XML currently has limited datatyping capability for attributes and no datatyping 2386 capability for elements. EbXML recognizes that datatyping is a requirement for 2387 business transactions using XML. The World Wide Web Consortium (W3C) has 2388 defined a group of core datatypes as part of the XML Schema Specification (XML 2389 Schema Part 2: Datatypes, W3C Candidate Recommendation, 24 October 2390 2000). The datatypes defined by the W3C will be used for global datatypes. 2391

2392 9.1.1 Global Datatypes 2393 2394

The following two charts defines the global datatypes that will be used for 2395 the ebXML Business Process Specification Schema. The first chart 2396 defines the datatypes that are currently available for use natively within 2397 XML DTDs. The second chart defines the proposed datatypes available 2398 for use with W3C XML Schema Specification. 2399

2400 Datatypes Natively Available in DTDs

Datatype Definition




ID ID represents the ID attribute type from [XML 1.0 Recommendation (Second Edition)].

IDREF IDREF represents the IDREF attribute type from [XML 1.0 Recommendation (Second Edition)].

IDREFS IDREFS represents the IDREFS attribute type from [XML 1.0 Recommendation (Second Edition)].

CDATA CDATA (Character Data) represents white space normalized strings.

ENTITY ENTITY represents the ENTITY attribute type from [XML 1.0 Recommendation (Second Edition)].

ENTITIES ENTITIES represents the ENTITIES attribute type from [XML 1.0 Recommendation (Second Edition)].

NMTOKEN NMTOKEN represents the NMTOKEN attribute type from [XML 1.0 Recommendation (Second Edition)].

NMTOKENS NMTOKENS represents the NMTOKENS attribute type from [XML 1.0 Recommendation (Second Edition)].

NOTATION NOTATION represents the NOTATION attribute type from [XML 1.0 Recommendation (Second Edition)].

2401 The table below shows the datatypes that are not natively provided in 2402 DTDs. These datatypes will be available in W3C Schema Specification, 2403 as well as the Regular Language description for XML (RELAX) schema 2404 language that has recently been submitted to ISO. 2405

2406

Although the datatypes are not currently natively available in DTDs 2407 (native XML parsers cannot validate) processes can be used to validate 2408 the datatypes external from the XML parser. 2409

2410 Datatypes Not Available in DTDs

Datatype Definition

string The string datatype represents character strings in XML. boolean The boolean datatype has the value space required to support the mathematical

concept of binary-valued logic: {true, false}.

float The float datatype corresponds to the IEEE single-precision 32-bit floating point type [IEEE 754-1985].

double The double datatype corresponds to IEEE double-precision 64-bit floating point type [IEEE 754-1985].

decimal The decimal datatype represents arbitrary precision decimal numbers.

timeDuration The timeDuration datatype represents a duration of time. recurringDuration The recurringDuration datatype represents a specific period of time that recurs

with a specific frequency, starting from a specific point in time.




binary The binary datatype represents arbitrary binary data. uriReference The uriReference datatype represents a Uniform Resource Indentifier (URI)

Reference. Qname QName represents XML qualified names. token The token datatype represents tokenized strings. language The language datatype represents natural language identifiers as defined by

[RFC 1766]. Name Name represents XML Names. NCName NCName represents XML "non-colonized" Names. integer The integer datatype is derived from decimal by fixing the value of scale to be

0. nonPositiveInteger nonPositiveInteger is derived from integer by setting the value of

maxInclusive to be 0. negativeInteger The negativeInteger datatype is derived from nonPositiveInteger by setting the

value of maxInclusive to be -1.

long the long datatype is derived from integer by setting the value of maxInclusive to be 9223372036854775807 and minInclusive to be -9223372036854775808. The base type of long is integer.

int The int datatype is derived from long by setting the value of maxInclusive to be 2147483647 and minInclusive to be -2147483648. The base type of int is long.

short short is derived from int by setting the value of maxInclusive to be 32767 and minInclusive to be -32768. The base type of short is int.

byte The byte datatype is derived from short by setting the value of maxInclusive to be 127 and minInclusive to be -128. The base type of byte is short.

nonNegativeIneger The nonNegativeInteger datatype is derived from integer by setting the value of minInclusive to be 0.

unsignedLong The unsignedLong datatype is derived from nonNegativeInteger by setting the value of maxInclusive to be 18446744073709551615. The base type of unsignedLong is nonNegativeInteger.

unsignedInt The unsignedInt datatype is derived from unsignedLong by setting the value of maxInclusive to be 4294967295. The base type of unsignedInt is unsignedLong.

unsignedShort The unsignedShort datatype is derived from unsignedInt by setting the value of maxInclusive to be 65535. The base type of unsignedShort is unsignedInt.

unsignedByte The unsignedByte datatype is derived from unsignedShort by setting the value of maxInclusive to be 255. The base type of unsignedByte is unsignedShort.

positiveInteger The positiveInteger datatype is derived from nonNegativeInteger by setting the value of minInclusive to be 1.




timeInstant The timeInstant datatype represents a specific instant of time.

time The time datatype represents an instant of time that recurs every day.

timePeriod The timePeriod datatype represents a specific period of time with a give start and end.

date The date datatype represents a timePeriod that starts at midnight of a specified day and lasts until midnight the following day.

month The month datatype represents a timePeriod that starts at midnight on the first day of the month and lasts until the midnight that ends the last day of the month.

year The year datatype represents a timePeriod that starts at the midnight that starts the first day of the year and ends at the midnight that ends the last day of the year.

century The century datatype represents a timePeriod that starts at the midnight that starts the first day of the century and ends at the midnight that ends that last day of the century.

recurringDate The recurringDate datatype is a date that recurs, specifically a day of the year such as the third of May.

recurringDay The recurringDay datatype is a day that recurs, specifically a day of the month such as the 5th of the month.

2411 9.1.2 Local Datatypes 2412 2413

Local datatypes used within ebXML, i.e., currency, will be developed by 2414 the ebXML Core Components Working Group. 2415

9.2 Business signal structures 2416 Since signals do not differ in structure from business transaction to 2417 business transaction, they are defined once and for all, and their definition 2418 is implied. Here are the DTD’s for receiptAcknowledgment and 2419 acceptanceAcknowledgement (from the RosettaNet website, courtesy of 2420 RosettaNet, and Edifecs).5 2421

2422

9.2.1 ReceiptAcknowledgment DTD 2423  2435

2436

2437

<!ENTITY % common-attributes "id CDATA #IMPLIED"> 2438 2439

<!ELEMENT ReceiptAcknowledgement ( 2440

fromRole , 2441

NonRepudiationInformation? , 2442

receivedDocumentDateTime , 2443

receivedDocumentIdentifier , 2444

thisMessageDateTime , 2445 thisMessageIdentifier , 2446

toRole ) > 2447

2448

<!ELEMENT fromRole 2449

( PartnerRoleDescription ) > 2450

2451

<!ELEMENT PartnerRoleDescription ( 2452 ContactInformation? , 2453

GlobalPartnerRoleClassificationCode , 2454

PartnerDescription ) > 2455

2456

<!ELEMENT ContactInformation ( 2457

contactName , 2458

EmailAddress , 2459

telephoneNumber ) > 2460




2461

<!ELEMENT contactName 2462

( FreeFormText ) > 2463

2464 <!ELEMENT FreeFormText 2465

( #PCDATA ) > 2466

<!ATTLIST FreeFormText 2467

xml:lang CDATA #IMPLIED > 2468

2469

<!ELEMENT EmailAddress 2470

( #PCDATA ) > 2471

2472 <!ELEMENT telephoneNumber 2473

( CommunicationsNumber ) > 2474

2475

<!ELEMENT CommunicationsNumber 2476

( #PCDATA ) > 2477

2478

<!ELEMENT GlobalPartnerRoleClassificationCode 2479 ( #PCDATA ) > 2480

2481

<!ELEMENT PartnerDescription ( 2482

BusinessDescription , 2483

GlobalPartnerClassificationCode ) > 2484

2485

<!ELEMENT BusinessDescription ( 2486 GlobalBusinessIdentifier , 2487

GlobalSupplyChainCode ) > 2488

2489

<!ELEMENT GlobalBusinessIdentifier 2490

( #PCDATA ) > 2491

2492

<!ELEMENT GlobalSupplyChainCode 2493

( #PCDATA ) > 2494




2495

<!ELEMENT GlobalPartnerClassificationCode 2496

( #PCDATA ) > 2497

2498 <!ELEMENT NonRepudiationInformation ( 2499

GlobalDigestAlgorithmCode , 2500

OriginalMessageDigest ) > 2501

2502

<!ELEMENT GlobalDigestAlgorithmCode 2503

( #PCDATA ) > 2504

2505

<!ELEMENT OriginalMessageDigest 2506 ( #PCDATA ) > 2507

2508

<!ELEMENT receivedDocumentDateTime 2509

( DateTimeStamp ) > 2510

2511

<!ELEMENT DateTimeStamp 2512

( #PCDATA ) > 2513 2514

<!ELEMENT receivedDocumentIdentifier 2515

( ProprietaryDocumentIdentifier ) > 2516

2517

<!ELEMENT ProprietaryDocumentIdentifier 2518

( #PCDATA ) > 2519

2520 <!ELEMENT thisMessageDateTime 2521


2523

<!ELEMENT thisMessageIdentifier 2524

( ProprietaryMessageIdentifier ) > 2525

2526

<!ELEMENT ProprietaryMessageIdentifier 2527

( #PCDATA ) > 2528




2529

<!ELEMENT toRole 2530


2532 9.2.2 AcceptanceAcknowledgement DTD 2533

 2546

2547

2548

<!ENTITY % common-attributes "id CDATA #IMPLIED"> 2549 2550

<!ELEMENT AcceptanceAcknowledgement ( 2551

fromRole , 2552

receivedDocumentDateTime , 2553

receivedDocumentIdentifier , 2554

thisMessageDateTime , 2555

thisMessageIdentifier , 2556 toRole ) > 2557

2558



2561

<!ELEMENT PartnerRoleDescription ( 2562




ContactInformation? , 2563

GlobalPartnerRoleClassificationCode , 2564

PartnerDescription ) > 2565

2566 <!ELEMENT ContactInformation ( 2567

contactName , 2568

EmailAddress , 2569

telephoneNumber ) > 2570

2571



2574 <!ELEMENT FreeFormText 2575

( #PCDATA ) > 2576



2579


( #PCDATA ) > 2581 2582

<!ELEMENT telephoneNumber 2583


2585


( #PCDATA ) > 2587

2588 <!ELEMENT GlobalPartnerRoleClassificationCode 2589

( #PCDATA ) > 2590

2591


BusinessDescription , 2593

GlobalPartnerClassificationCode ) > 2594

2595

<!ELEMENT BusinessDescription ( 2596




GlobalBusinessIdentifier , 2597

GlobalSupplyChainCode ) > 2598

2599

<!ELEMENT GlobalBusinessIdentifier 2600 ( #PCDATA ) > 2601

2602


( #PCDATA ) > 2604

2605


( #PCDATA ) > 2607

2608 <!ELEMENT receivedDocumentDateTime 2609


2611


( #PCDATA ) > 2613

2614

<!ELEMENT receivedDocumentIdentifier 2615 ( ProprietaryDocumentIdentifier ) > 2616

2617

<!ELEMENT ProprietaryDocumentIdentifier 2618

( #PCDATA ) > 2619

2620

<!ELEMENT thisMessageDateTime 2621

( DateTimeStamp ) > 2622 2623



2626


( #PCDATA ) > 2628

2629






2632

9.2.3 Exception Signal DTD 2633  2646

2647 2648

<!ENTITY % common-attributes "id CDATA #IMPLIED"> 2649

2650

<!ELEMENT Exception ( 2651

fromRole? , 2652

reason , 2653

theMessageDatetime , 2654 theOffendingDocumentDateTime? , 2655

theOffendingDocumentIdentifier? , 2656

thisMessageIdentifier , 2657

toRole? ) > 2658

2659


( PartnerRoleDescription ) > 2661 2662

<!ELEMENT PartnerRoleDescription ( 2663

ContactInformation? , 2664




GlobalPartnerRoleClassificationCode? , 2665

PartnerDescription? ) > 2666

2667

<!ELEMENT ContactInformation ( 2668 contactName? , 2669

EmailAddress? , 2670

telephoneNumber? ) > 2671

2672



2675

<!ELEMENT FreeFormText 2676 ( #PCDATA ) > 2677



2680


( #PCDATA ) > 2682

2683 <!ELEMENT telephoneNumber 2684


2686


( #PCDATA ) > 2688

2689

<!ELEMENT GlobalPartnerRoleClassificationCode 2690 ( #PCDATA ) > 2691

2692


BusinessDescription? , 2694

GlobalPartnerClassificationCode? ) > 2695

2696

<!ELEMENT BusinessDescription ( 2697

GlobalBusinessIdentifier? , 2698




GlobalSupplyChainCode? ) > 2699

2700

<!ELEMENT GlobalBusinessIdentifier 2701

( #PCDATA ) > 2702 2703


( #PCDATA ) > 2705

2706


( #PCDATA ) > 2708

2709

<!ELEMENT reason 2710 ( FreeFormText ) > 2711

2712

<!ELEMENT theMessageDatetime 2713


2715


( #PCDATA ) > 2717 2718

<!ELEMENT theOffendingDocumentDateTime 2719


2721

<!ELEMENT theOffendingDocumentIdentifier 2722

( ProprietaryDocumentIdentifier ) > 2723

2724 <!ELEMENT ProprietaryDocumentIdentifier 2725

( #PCDATA ) > 2726

2727



2730


( #PCDATA ) > 2732




2733



10 Production Rules 2736 The Specification Production rules provide the prescriptive definition necessary 2737 to translate a UML Specification Model into an XML Specification Document and 2738 the well-formed rules necessary to populate an XML Specification Document. 2739

There are two relevant mappings from the UML version of the specification 2740 schema to the XML version. 2741 The first is the transform of a UML instance of a business process specification to 2742 an XML document conforming to the schema specification. 2743

The second is the transform of a UML instance of a document definition to a 2744 DTD. 2745

Since the UML form of the Specification Schema is a MOF compliant model, we 2746 are proposing the use of XMI as the production rules for both these two 2747 transforms. 2748

In addition, ebXML may supply XSLT transforms to get the XML document 2749 and/or DTD into an even simpler, easilier human readable form, as illustrated by 2750 the DTD and sample XML in the prior sections. 2751

2752




11 Business Service Interaction Patterns6 2753 This section provides the definition of predefined service interaction patterns that 2754 are used to define interactions based on the type of transaction, the type of 2755 role(s) that are being performed by the partners and the timing/business signals 2756 employed. 2757

11.1 Service Component Interaction Pattern 2758 Networked business services and business agents are configured to execute 2759 business transactions and business collaboration agreements. A message 2760 sequence is used to specify network component interactions. The following 2761 network component interactions are possible. 2762

• Service-Service. 2763

• Agent-Service-Service. 2764

• Service-Service-Agent. 2765

• Service-Agent-Service. 2766

• Agent-Service-Agent 2767

2768

For each Business Transaction one or more of the Service Component 2769 Interaction Patterns may be applicable. 2770

2771

2772

6 6 These patterns have been defined in the UN/CEFACT Modelling Methodology (CEFACT/TMWG/N090R8E )




11.1.1 Service-Service 2773 Business Transaction Activity 2774 Pattern Nomenclature: Service-Service(BTA_NR) 2775 Pattern Description: Time to perform equals time to acknowledge acceptance and no 2776 responding business document. 2777

:

OriginatingService :

RespondingService

1. request(BusinessActionMeaaa

1.1. signal(ReceiptAcknowledgement)

1.2. signal(AcceptanceAcknowledgement)

2778

Figure 1. Service-Service Interaction Pattern 2779

2780 2781 2782 2783 2784 2785 2786




Pattern Nomenclature: Service-Service(BTA_NACC) 2787 Pattern Description: Time to perform equals time to acknowledge acceptance and a 2788 responding business document. 2789

: OriginatingService

: RespondingService

1. request(BusinessAction)


1.2. response(BusinessAction)

1.2.1. signal(ReceiptAcknowledgement)

2790





Pattern Nomenclature: Service-Service(BTA_ACC) 2792 Pattern Description: Time to perform is greater than time to acknowledge acceptance. 2793


: RespondingService






2794





Query/Response Activity, Request/Response Activity and Request/Confirm Activity 2796 Pattern Nomenclature: Service-Service(NACC) 2797 Pattern Description: Time to acknowledge acceptance is not applicable and a responding 2798 business document. 2799


: RespondingService





2800





Information Distribution Activity and Notification Activity 2802 Pattern Nomenclature: Service-Service(ASYNC) 2803 Pattern Description: Time to acknowledge acceptance is not applicable and no 2804 responding business document. 2805


: RespondingService



2806





11.1.2 Agent-Service-Service 2808 Business Transaction Activity 2809 Pattern Nomenclature: Agent-Service-Service(BTA_NR) 2810 Pattern Description: Time to perform equals time to acknowledge acceptance and no 2811 responding business document. 2812


: RespondingService

: OriginatingAgent

1. callTxn( )

1.1. request(BusinessAction)


1.1.2. signal(AcceptanceAcknowledgement)

1.2. return(BusinessSignal)

2813

Figure 6. Agent-Service-Service Interaction Pattern 2814




Pattern Nomenclature: Agent-Service-Service(BTA_NACC) 2815 Pattern Description: Time to perform equals time to acknowledge acceptance and a 2816 responding business document. 2817


: RespondingService

: OriginatingAgent

1. callTxn( )1.1. request(BusinessAction)


1.1.2. response(BusinessAction)

1.2. return(BusinessAction)

1.1.2.1. signal(ReceiptAcknowledgement)

2818





Pattern Nomenclature: Agent-Service-Service(BTA_ACC) 2820 Pattern Description: Time to perform is greater than time to acknowledge acceptance. 2821


: RespondingService

: OriginatingAgent

1. callTxn( )







2822





Query/Response Activity, Request/Response Activity and Request/Confirm Activity 2824 Pattern Nomenclature: Agent-Service-Service(NACC) 2825 Pattern Description: Time to acknowledge acceptance is not applicable and a responding 2826 business document. 2827


: RespondingService

: OriginatingAgent

1. callTxn( )






2828





Information Distribution Activity and Notification Activity 2830 Pattern Nomenclature: Agent-Service-Service(ASYNC) 2831 Pattern Description: Time to acknowledge acceptance is not applicable and no 2832 responding business document. 2833


: RespondingService

: OriginatingAgent

1. callTxn( )




2834





11.1.3 Service-Service-Agent 2836 Business Transaction Activity 2837 Pattern Nomenclature: Service-Service-Agent(BTA_NR) 2838 Pattern Description: Time to perform equals time to acknowledge acceptance and no 2839 responding business document. 2840


: RespondingService

: RespondingAgent




2. queryTxn( )


2.1.1. submit(AcceptanceAcknowledgement)

2841

Figure 11. Service-Service-Agent Interaction Pattern 2842




Pattern Nomenclature: Service-Service-Agent(BTA_NACC) 2843 Pattern Description: Time to perform equals time to acknowledge acceptance and a 2844 responding business document. 2845


: RespondingService

: RespondingAgent





2. queryTxn( )


2.1.1. submit(BusinessAction)

2846





Pattern Nomenclature: Service-Service(BTA_ACC) 2848 Pattern Description: Time to perform is greater than time to acknowledge acceptance. 2849


: RespondingService

: RespondingAgent






2. queryTxn( )



2850





Query/Response Activity, Request/Response Activity and Request/Confirm Activity 2852 Pattern Nomenclature: Service-Service-Agent(NACC) 2853 Pattern Description: Time to acknowledge acceptance is not applicable and a responding 2854 business document. 2855


: RespondingService

: RespondingAgent





2. queryTxn( )



2856





Information Distribution Activity and Notification Activity 2858 Pattern Nomenclature: Service-Service-Agent(ASYNC) 2859 Pattern Description: Time to acknowledge acceptance is not applicable and no 2860 responding business document. 2861


: RespondingService

: RespondingAgent



2. queryTxn( )


2.1.1. submit(ReceiptAcknowledgement)

2862





11.1.4 Service-Agent-Service 2864 Business Transaction Activity 2865 Pattern Nomenclature: Service-Agent-Service(BTA_NR) 2866 Pattern Description: Time to perform equals time to acknowledge acceptance and no 2867 responding business document. 2868


: RespondingService

: RespondingAgent

: OriginatingAgent

1. callTxn( )


1.1.1. transfer(BusinessAction)

1.1.1.1. request(BusinessAction)

1.1.1.1.1. signal(ReceiptAcknowledgement)

1.1.1.1.2. signal(AcceptanceAcknowledgement)

2. queryTxn( )


2869

Figure 16. Service-Agent-Service Interaction Pattern 2870




Pattern Nomenclature: Service-Service(BTA_NACC) 2871 Pattern Description: Time to perform equals time to acknowledge acceptance and a 2872 responding business document. 2873


: RespondingService

: OriginatingAgent

: RespondingAgent

1. callTxn( )





1.1.1.1.2. response(BusinessAction)

1.1.1.1.2.1. signal(ReceiptAcknowledgement)

2. queryTxn( )


2874





Pattern Nomenclature: Service-Agent-Service(BTA_ACC) 2876 Pattern Description: Time to perform is greater than time to acknowledge acceptance. 2877


: RespondingService

: OriginatingAgent

: RespondingAgent

1. callTxn( )

1.1. return(BusinessAction)1.1.1. transfer(BusinessAction)



1.1.1.1.2. signal(AcceptanceAcknowledgement)



2. queryTxn( )


2878





Query/Response Activity, Request/Response Activity and Request/Confirm Activity 2880 Pattern Nomenclature: Service-Agent-Service(NACC) 2881 Pattern Description: Time to acknowledge acceptance is not applicable and a responding 2882 business document. 2883


: RespondingService

: OriginatingAgent

: RespondingAgent

1. callTxn( )







2. queryTxn( )


2884





Request/Confirm Activity 2886 Pattern Nomenclature: Service-Agent-Service(REQ) 2887 Pattern Description: Time to acknowledge acceptance is not applicable and a responding 2888 business document. 2889


: OriginatingAgent

: RespondingAgent

: RespondingService

1. callTxn( )







2. queryTxn( )


2890

Figure 20. Service-Agent-Service interaction Pattern 2891




Information Distribution Activity and Notification Activity 2892 Pattern Nomenclature: Service-Agent-Service(ASYNC) 2893 Pattern Description: Time to acknowledge acceptance is not applicable and no 2894 responding business document. 2895


: OriginatingAgent

: RespondingAgent

: RespondingService

1. callTxn( )


1.1.1. transfer(BusinessAction)1.1.1.1. request(BusinessAction)


2. callTxn( )


2896





11.1.5 Agent-Service-Agent 2898 Business Transaction Activity 2899 Pattern Nomenclature: Agent-Service-Agent(BTA_NR) 2900 Pattern Description: Time to perform equals time to acknowledge acceptance and no 2901 responding business document. 2902


: RespondingService

: OriginatingAgent

: RespondingAgent

1. callTxn( )





2. queryTxn( )


2.1.1. submit(AcceptanceAcknowledgement)

2903

Figure 22. Agent-Service-Agent Interaction Pattern 2904




Pattern Nomenclature: Agent-Service-Agent(BTA_NACC) 2905 Pattern Description: Time to perform equals time to acknowledge acceptance and a 2906 responding business document. 2907


: RespondingService

: OriginatingAgent

: RespondingAgent

1. callTxn( )






2. queryTxn( )



2908





Pattern Nomenclature: Agent-Service-Agent(BTA_ACC) 2910 Pattern Description: Time to perform is greater than time to acknowledge acceptance. 2911


: RespondingService

: OriginatingAgent

: RespondingAgent

1. callTxn( )




2. queryTxn( )






2912





Query/Response Activity, Request/Response Activity and Request/Confirm Activity 2914 Pattern Nomenclature: Agent-Service-Agent(NACC) 2915 Pattern Description: Time to acknowledge acceptance is not applicable and a responding 2916 business document. 2917


: RespondingService

: OriginatingAgent

: RespondingAgent

1. callTxn( )






2. queryTxn( )



2918





Information Distribution Activity and Notification Activity 2920 Pattern Nomenclature: Agent-Service-Agent(ASYNC) 2921 Pattern Description: Time to acknowledge acceptance is not applicable and no 2922 responding business document. 2923


: RespondingService

: OriginatingAgent

: RespondingAgent

1. callTxn( )



2. queryTxn( )


2.1.1. submit(ReceiptAcknowledgement)


2924


2926 2927 2928

2929




12 References 2929 2930

1. UN/CEFACT Modelling Methodology (CEFACT/TMWG/N090R8E ) 2931 2. RosettaNet Implementation Framework: Core Specification, Version: 2932

Release 2.00.00, 3 January 2001 2933 2934

2935 2936

13 Disclaimer 2937 The views and specification expressed in this document are those of the authors and are 2938 not necessarily those of their employers. The authors and their employers specifically 2939 disclaim responsibility for any problems arising from correct or incorrect implementation 2940 or use of this design. 2941

2942




14 Contact Information 2942 2943 Team Leader (Of the BP team): 2944 Paul Levine 2945 Telcordia Technologies, Inc. 2946 45 Knightsbridge Road 2947 Piscataway, N.J. 08854 2948 US 2949 2950 Phone: 732-699-3042 2951 EMail: [email protected] 2952 2953 Sub Team Lead (Of the context/MetamodelGroup) : 2954 2955 Karsten Riemer 2956 Sun Microsystems 2957 1 Network Drive 2958 Burlington, MA 01803 2959 USA 2960 2961 Phone: 781-442-2679 2962 EMail: [email protected] 2963 2964 Editor (of this document): 2965 2966 Karsten Riemer 2967 Sun Microsystems 2968 1 Network Drive 2969 Burlington, MA 01803 2970 USA 2971 2972 Phone: 781-442-2679 2973 EMail: [email protected] 2974




2975

Copyright Statement 2976 Copyright © ebXML 2000 & 2001. All Rights Reserved. 2977 2978 This document and translations of it may be copied and furnished to others, and 2979 derivative works that comment on or otherwise explain it or assist in its implementation 2980 may be prepared, copied, published and distributed, in whole or in part, without 2981 restriction of any kind, provided that the above copyright notice and this paragraph are 2982 included on all such copies and derivative works. However, this document itself may not 2983 be modified in any way, such as by removing the copyright notice or references to the 2984 Internet Society or other Internet organizations, except as needed for the purpose of 2985 developing Internet standards in which case the procedures for copyrights defined in the 2986 Internet Standards process must be followed, or as required to translate it into languages 2987 other than English. 2988 2989 The limited permissions granted above are perpetual and will not be revoked by ebXML 2990 or its successors or assigns. 2991 2992 This document and the information contained herein is provided on an 2993 "AS IS" basis and ebXML DISCLAIMS ALL WARRANTIES, EXPRESS OR 2994 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE 2995 USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 2996 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 2997 PARTICULAR PURPOSE. 2998