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
123
Embed
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
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
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
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
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.3 Where the ebXML Specification Schema May Be Implemented................................. 18 88 7 Specification Element Overview .......................................................................................... 18 89
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
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
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
Context/Metamodel Group January 2001
ebXML Business Process Specification Schema Page 3 of 9
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
Context/Metamodel Group January 2001
ebXML Business Process Specification Schema Page 4 of 10
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
Context/Metamodel Group January 2001
ebXML Business Process Specification Schema Page 5 of 11
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
Context/Metamodel Group January 2001
ebXML Business Process Specification Schema Page 6 of 12
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
Context/Metamodel Group January 2001
ebXML Business Process Specification Schema Page 7 of 13
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
Context/Metamodel Group January 2001
ebXML Business Process Specification Schema Page 8 of 14
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
Context/Metamodel Group January 2001
ebXML Business Process Specification Schema Page 9 of 15
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
Context/Metamodel Group January 2001
ebXML Business Process Specification Schema Page 11 of 17
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
Context/Metamodel Group January 2001
ebXML Business Process Specification Schema Page 12 of 18
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.
Context/Metamodel Group January 2001
ebXML Business Process Specification Schema Page 13 of 19
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.
Context/Metamodel Group January 2001
ebXML Business Process Specification Schema Page 14 of 20
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
Context/Metamodel Group January 2001
ebXML Business Process Specification Schema Page 15 of 21
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
Context/Metamodel Group January 2001
ebXML Business Process Specification Schema Page 16 of 22
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
Context/Metamodel Group January 2001
ebXML Business Process Specification Schema Page 17 of 23
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
Context/Metamodel Group January 2001
ebXML Business Process Specification Schema Page 18 of 24
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
Context/Metamodel Group January 2001
ebXML Business Process Specification Schema Page 19 of 25
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
Context/Metamodel Group January 2001
ebXML Business Process Specification Schema Page 20 of 26
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
Context/Metamodel Group January 2001
ebXML Business Process Specification Schema Page 21 of 27
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
Wellformedness Rules: 824 NONE 825
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
Context/Metamodel Group January 2001
ebXML Business Process Specification Schema Page 22 of 28
Associations: 835 from The initiating role 836 to The responding role 837
Wellformedness Rules: 838 NONE 839
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
Context/Metamodel Group January 2001
ebXML Business Process Specification Schema Page 23 of 29
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
Context/Metamodel Group January 2001
ebXML Business Process Specification Schema Page 24 of 30
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
Context/Metamodel Group January 2001
ebXML Business Process Specification Schema Page 25 of 31
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
Wellformedness Rules: 986
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
Context/Metamodel Group January 2001
ebXML Business Process Specification Schema Page 26 of 32
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
Context/Metamodel Group January 2001
ebXML Business Process Specification Schema Page 27 of 33
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
Wellformedness Rules: 1049
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
Wellformedness Rules: 1062
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
Context/Metamodel Group January 2001
ebXML Business Process Specification Schema Page 28 of 34
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
Wellformedness Rules: 1098
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
Wellformedness Rules: 1109
NONE 1110
1111
Context/Metamodel Group January 2001
ebXML Business Process Specification Schema Page 29 of 35
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
Wellformedness Rules: 1120 NONE 1121
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
Context/Metamodel Group January 2001
ebXML Business Process Specification Schema Page 30 of 36
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
Tagged Values: 1175 NONE 1176
Associations: 1177 Attribute: An AggregateInformationEntity contains one or 1178
more attributes. 1179
Wellformedness Rules: 1180 NONE 1181
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
Context/Metamodel Group January 2001
ebXML Business Process Specification Schema Page 31 of 37
type (enumerated: string, integer, date) 1189 1190
Associations: 1191 NONE (except as inherited from InformationEntity.) 1192
Wellformedness Rules: 1193
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
Wellformedness Rules: 1223 NONE 1224
1225
Context/Metamodel Group January 2001
ebXML Business Process Specification Schema Page 32 of 38
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
Wellformedness Rules: 1241
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
Context/Metamodel Group January 2001
ebXML Business Process Specification Schema Page 33 of 39
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
Wellformedness Rules: 1310
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
Context/Metamodel Group January 2001
ebXML Business Process Specification Schema Page 35 of 41
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
Context/Metamodel Group January 2001
ebXML Business Process Specification Schema Page 36 of 42
[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
Context/Metamodel Group January 2001
ebXML Business Process Specification Schema Page 37 of 43
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
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
Valid values {true, false}
isLink Defines that the attribute references an external document (document not passed in the same document set) of the given data type.
false
Valid values {true, false}
1432 b. Binary Collaboration 1433
XML Element Name: binary-collaboration 1434 DTD Declaration: 1435
Definition: 1451 Defines a contract of interaction between two business roles. 1452
Parents: 1453 • Package 1454
Attributes: 1455 1456
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, _
initiator Name of the initiating role in a binary-collaboration.
No default value. A value must be present. Names may only contain the characters a-z, A-Z, 0-9, _
responder Name of the responding role in a binary-collaboration
No default value. A value must be present. Names may only contain the characters a-z, A-Z, 0-9, _
timeToPerform
Time allowed for execution of the collaboration
zero
Valid values {true, false}
timeUnit For each timing parameter set defined the time unit may also be set.
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
Attributes: 1505 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, _
from The name of the role initiating the activity. No default value. A value
Context/Metamodel Group January 2001
ebXML Business Process Specification Schema Page 42 of 48
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
Parents: 1534 • Package 1535
Attributes: 1536 1537
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, _
isIntelligibleCheckRequired
Must validate readability No Default
Valid values {true, false}
isAuthorizationRequired
sending partner role must sign the business document exchanged and the receiving partner role must validate
No Default
Valid values {true, false}
isSecureTransportRequired
Requires secure transport of message No Default
Valid values {true, false}
isGuaranteedDeliveryRequired
Requires guaranteed delivery of message No Default
Valid values {true, false}
isNonRepudiationRequired
must store the business document in its original form
No Default
Valid values {true, false}
isNonRepudiationReceiptRequired
Must mutually verify receipt of a requesting business document and that the receipt must be non-reputable
No Default
Valid values {true, false}
timeToAcknowledge
Time from initial request to acceptanceAcknowledgement
No default value. A value must be present. Names may
Context/Metamodel Group January 2001
ebXML Business Process Specification Schema Page 44 of 50
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
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
Required Input.
Context/Metamodel Group January 2001
ebXML Business Process Specification Schema Page 45 of 51
Definition: 1570 Defines one element of an aggregate document set 1571
Attributes: 1572 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.
required Defines that the attribute or content must be part of an instance of the aggregate.
false
Valid values {true, false}
isLink
Defines that the attribute references an external document (document not passed in the same document set) of the given data type.
false
Valid values {true, false}
isConfidential
The information entity is encrypted so that unauthorized parties cannot view the information
false
Valid values {true, false}
isTamperProof
The information entity has an encrypted message digest that can be used to check if
false
Context/Metamodel Group January 2001
ebXML Business Process Specification Schema Page 46 of 52
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
Parents: 1584 • Package 1585
Attributes: 1586
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, _
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
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
The information entity is encrypted so that unauthorized parties cannot view the information
false
Valid values {true, false}
isTamperProof
The information entity has an encrypted message digest that can be used to check if the message has been tampered with
false
Valid values {true, false}
isAuthenticated
There is a digital certificate associated with the document entity
false
Valid values {true, 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
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
Attributes: 1654 1655
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
IsConfidential
The information entity is encrypted so that unauthorized parties cannot view the information
false
Valid values {true, false}
isTamperProof
The information entity has an encrypted message digest that can be used to check if the message has been tampered with
false
Valid values {true, false}
Context/Metamodel Group January 2001
ebXML Business Process Specification Schema Page 49 of 55
There is a digital certificate associated with the document entity
false
Valid values {true, 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
Attributes: 1670 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
uuid Unique Identifier No Default Value
version Version of the specification No Default Value
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
Definition Default Value
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.
<!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
Context/Metamodel Group January 2001
ebXML Business Process Specification Schema Page 51 of 57
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
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
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
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.
Definition: 1735 Defines a hierarchical name scope containing reusable elements. 1736
Parents: 1737
• ebXmlProcessSpecification 1738 • package 1739
1740 Attributes: 1741 1742
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
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
Context/Metamodel Group January 2001
ebXML Business Process Specification Schema Page 53 of 59
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
Attributes: 1775 Attribute Name
Definition Default Value
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
Context/Metamodel Group January 2001
ebXML Business Process Specification Schema Page 54 of 60
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
Definition Default Value
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.
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
Attributes: 1806 Attribute Name
Definition Default Value
to Name of the role responding to the activity. The activity must be the same collaboration.
Required Input
1807 1808
u. Transition/Success 1809
Element Name: success 1810
Context/Metamodel Group January 2001
ebXML Business Process Specification Schema Page 55 of 61
Definition: 1818 Defines the successful conclusion of a binary collaboration as a transition from 1819 an activity. 1820
Parents: 1821 • binary-collaboration 1822
Attributes: 1823 Attribute Name
Definition Default Value
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.
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
any false
Allowed Values:
{true, false}
1837
w. Transition 1838
ELEMENT Name: transition 1839 DTD Declaration: 1840
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
Parents: 1851 • binary-collaboration 1852
Attributes: 1853 Attribute Name
Definition Default Value
to Name of the role responding to the activity. The activity must be the same collaboration.
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.
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
Parents: 1876 • Package 1877
Attributes: 1878 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.
mimetype Specified the MIME type that will implement an unstructured document. The string must conform to the MIME type name.
No Default Value.
isConfidential
The information entity is encrypted so that unauthorized parties cannot view the information
false
Valid values {true, false}
isTamperProof
The information entity has an encrypted message digest that can be used to check if the message has been tampered with
false
Valid values {true, false}
isAuthenticated
There is a digital certificate associated with the document entity
false
Context/Metamodel Group January 2001
ebXML Business Process Specification Schema Page 58 of 64
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.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
Context/Metamodel Group January 2001
ebXML Business Process Specification Schema Page 66 of 72
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
Context/Metamodel Group January 2001
ebXML Business Process Specification Schema Page 75 of 81
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.
Context/Metamodel Group January 2001
ebXML Business Process Specification Schema Page 76 of 82
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.
Context/Metamodel Group January 2001
ebXML Business Process Specification Schema Page 77 of 83
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 <!-- 2424
RosettaNet XML Message Schema. 2425
http://www.rosettanet.org 2426
5 From RosettaNet Implementation Framework: Core Specification, Version: Release 2.00.00, 3 January 2001
Context/Metamodel Group January 2001
ebXML Business Process Specification Schema Page 78 of 84
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
Context/Metamodel Group January 2001
ebXML Business Process Specification Schema Page 88 of 94
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 )
Context/Metamodel Group January 2001
ebXML Business Process Specification Schema Page 89 of 95
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
Pattern Nomenclature: Service-Service(BTA_NACC) 2787 Pattern Description: Time to perform equals time to acknowledge acceptance and a 2788 responding business document. 2789
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
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
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
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
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
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
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
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
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
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
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
Pattern Nomenclature: Service-Service(BTA_NACC) 2871 Pattern Description: Time to perform equals time to acknowledge acceptance and a 2872 responding business document. 2873
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
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
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
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
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
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
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
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
Context/Metamodel Group January 2001
ebXML Business Process Specification Schema Page 116 of 122