ebxml Business Process Specification Schema Technical Specification v2.0.4

(1)

ebxmlbp-v2.0.4-Spec-os-en 21 December 2006

1

2 ebXML Business Process Specification Schema

3 Technical Specification v2.0.4

4 OASIS Standard, 21 December 2006

(2)

ebxmlbp-v2.0.4-Spec-os-en 21 December 2006 Specification URIs:

6

This Version:

7

docs.oasis-open.org/ebxml-bp/2.0.4/OS/spec/ebxmlbp-v2.0.4-Spec-os-en.doc

8

docs.oasis-open.org/ebxml-bp/2.0.4/OS/spec/ebxmlbp-v2.0.4-Spec-os-en-html/

9

docs.oasis-open.org/ebxml-bp/2.0.4/OS/spec/ebxmlbp-v2.0.4-Spec-os-en.odt

10

docs.oasis-open.org/ebxml-bp/2.0.4/OS/spec/ebxmlbp-v2.0.4-Spec-os-en.pdf

11

Previous Version:

12

docs.oasis-open.org/ebxml-bp/2.0.4/ebxmlbp-v2.0.4-Spec-cs-en.odt

13

docs.oasis-open.org/ebxml-bp/2.0.4/ebxmlbp-v2.0.4-Spec-cs-en.pdf

14

Latest Version:

15

docs.oasis-open.org/ebxml-bp/2.0.4/ebxmlbp-v2.0.4-Spec-os-en.doc

16

docs.oasis-open.org/ebxml-bp/2.0.4/ebxmlbp-v2.0.4-Spec-os-en.html

17

docs.oasis-open.org/ebxml-bp/2.0.4/ebxmlbp-v2.0.4-Spec-os-en.odt

18

docs.oasis-open.org/ebxml-bp/2.0.4/ebxmlbp-v2.0.4-Spec-os-en.pdf

19

Technical Committee:

20

ebXML Business Process Technical Committee

21

Co-chairs:

22

Dale Moberg, Cyclone Commerce/Axway

23

Monica J. Martin, Sun Microsystems

24

Editors:

25

Jean-Jacques Dubray, Individual, [email protected] [previous member]

26

Sally St. Amand, Individual, [email protected]

27

Monica J. Martin, Sun Microsystems, [email protected]

28

Contributors:

29

John Yunker, Individual [email protected] (previous member)

30

David Webber, Individual, <[email protected]>

31

Dale Moberg, Cyclone Commerce/Axway, co-chair, [email protected]

32

Kenji Nagahashi, Fujitsu, [email protected]

33

Stephen Green, Individual, [email protected] (previous member)

34

Sacha Schlegel, Individual, [email protected]

35

Monica J. Martin, Sun Microsystems, co-chair, [email protected]

36

37

Contributions for the development of ebBP examples of UBL related documents by J. Dean

38

Hemopo, ebxml-dev, New Zealand (user community), and Stephen Green, UK local government

39

(user community) and Sacha Schlegel (Member).

40

Related Work:

41

See Section 1.4 : Related Documents.

42

Abstract:

43

This document defines a standards-based business process foundation that promotes the

44

automation and predictable exchange of Business Collaboration definitions using XML.

45

(3)

ebxmlbp-v2.0.4-Spec-os-en 21 December 2006 Status:

46

This set of ebBP documents are compatible with the ebXML Business Process Specification

47

Schema v1.01 technical specification and schema, and a migration path is possible from v1.01,

48

v1.04 and v1.05 to v2.0.x documents. The technical specification supersedes the v2.0

49

Committee Draft / Committee Specification1, v2.0.1 and v2.0.2 Committee Drafts, and the v2.0.3

50

Committee Specification.

51

Six packages are provided for ebBP:

52

1. Normative: A package for the technical specification and appendices (Artifact Type:

53

Spec, and Artifact Type: Spec and Descriptive Name: Appendices)

54

2. Normative: A package for the core schema (Artifact Type: Schema)

55

3. Normative: A package for the Business Signal schema (Artifact Type: Schema,

56

Descriptive Name: SignalSchema)

57

4. Non-normative: A package that includes the Public Review comments list, files for an

58

exemplary XSLT transform to assist the user community to begin to migrate v1.01, v1.04

59

and v1.05 ebBP instances (for information and reference only) [Artifact Type: Document,

60

Descriptive Name: Supplements]

61

5. Normative: A package of ebBP schema-generated documentation for ebBP schema

62

(Artifact Type: Document, Descriptive Name: Schema)

63

6. Normative: A package of ebBP signal schema-generated documentation (Artifact Type:

64

Document, Descriptive Name: SignalSchema).

65

These documents are updated periodically. Send comments to the editor.

66

Note: The schemas (core and signals) are also located individually outside of the packages as specified

67

in Section 2.

68

69

Exemplary process definition and signal instances and illustrations are also provided in a publicly

70

available package on the OASIS site. This final package is non-normative and outside the review and TC

71

process cycle of this technical specification. This technical specification provides non-normative examples

72

(XML instance snippets) while more complex ebBP definitions may be found in the examples package.

73

The ebXML Business Process TC charter including scope is found at:

http://www.oasis-74

open.org/committees/ebxml-bp/charter.php.

75

Committee members should send comments on this specification to the [email protected]

76

list. Others should subscribe to and send comments to the [email protected] list.

77

To subscribe, send an email message to [email protected] with the word

78

"subscribe" as the body of the message.

79

For information on whether any patents have been disclosed that may be essential to implementing this

80

specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights

81

section of the ebXML Business Process TC web page (

http://www.oasis-open.org/committees/ebxml-82

bp/ipr.php). The IPR policy in effect as of this document is the Legacy IPR policy.

83

The non-normative errata page for this specification is located at

www.oasis-open.org/committees/ebxml-84

bp.

85

86

87

1

The preceding OASIS TC process indicates Committee Specification while the new TC process indicates Committee Draft followed by a Committee Specification. The v2.0 packages were applicable under the old TC process as the quorate TC vote was initiated prior to the effective date of the new TC process (although the vote concluded after 15 April 2005). Under the new TC process, this document is a Committee Draft.

(4)

Notices

88

OASIS takes no position regarding the validity or scope of any intellectual property or other rights that

89

might be claimed to pertain to the implementation or use of the technology described in this document or

90

the extent to which any license under such rights might or might not be available; neither does it

91

represent that it has made any effort to identify any such rights. Information on OASIS's procedures with

92

respect to rights in OASIS specifications can be found at the OASIS website. Copies of claims of rights

93

made available for publication and any assurances of licenses to be made available, or the result of an

94

attempt made to obtain a general license or permission for the use of such proprietary rights by

95

implementors or users of this specification, can be obtained from the OASIS Executive Director.

96

OASIS invites any interested party to bring to its attention any copyrights, patents or patent applications,

97

or other proprietary rights which may cover technology that may be required to implement this

98

specification. Please address the information to the OASIS Executive Director.

99

100

This document and translations of it may be copied and furnished to others, and derivative works that

101

comment on or otherwise explain it or assist in its implementation may be prepared, copied, published

102

and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice

103

and this paragraph are included on all such copies and derivative works. However, this document itself

104

may not be modified in any way, such as by removing the copyright notice or references to OASIS,

105

except as needed for the purpose of developing OASIS specifications, in which case the procedures for

106

copyrights defined in the OASIS Intellectual Property Rights document must be followed, or as required to

107

translate it into languages other than English.

108

The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors

109

or assigns.

110

This document and the information contained herein is provided on an "AS IS" basis and OASIS

111

DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY

112

WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR

113

ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

114

(5)

1 Introduction

212

The eBusiness eXtensible Markup Language (ebXML) Business Process Specification Schema (BPSS)

213

technical specification defines a standard language by which business systems MAY be configured to

214

support execution of Business Collaborations consisting of Business Transactions. It is based upon prior

215

UN/CEFACT work, specifically the metamodel behind the UN/CEFACT Modeling Methodology (UMM)

216

defined in the “UN/CEFACT Modeling Methodology - Meta Model - Revision 10. In the future, when a

217

reference guide becomes available subsequent versions will be evaluated and other metadata

218

requirements analyzed. These could include those developed under the United Nations Centre for Trade

219

and Facilitation and Electronic Business (UN/CEFACT), such as from the Unified Business Agreements

220

and Contracts (UBAC).2 The ebBP technical specification supports the specification of Business

221

Transactions and the choreography of Business Transactions into Business Collaborations. All Business

222

Transactions are implemented using one of many available standard patterns. These patterns are defined

223

in the UMM specification. A pattern is not executable; it rather specifies the type of the message

224

exchange (request, response and signals) that applies for a given Business Transaction definition. It is a

225

way to define classes of Business Transaction definitions. These patterns could potentially be related to

226

different classes of electronic commerce transactions.

227

The current version of the ebBP technical specification addresses Business Collaborations between any

228

number of parties (Business Collaborations specialized to Binary or Multiparty Collaborations). It also

229

enables participants, which are capable of using Web service or combined technologies (such as ebXML

230

and web services) to participate in a Business Collaboration. It is anticipated that a subsequent version of

231

this technical specification will address additional features such as the semantics of economic exchanges

232

and contracts, and context based content based on the metadata requirements provided by relevant

233

organizations.

234

Implementation Note:

235

Throughout this document, shorthand is used. The technical specification is referenced as the

236

ebBP technical specification. An ebBP business process definition is identified as an ebBP

237

definition. An ebXML BPSS instance is an ebBP instance. An ebXML BPSS schema is an ebBP

238

schema.

239 1.1 Terminology

240

The key WORDS MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT,

241

RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in [RFC

242

2119]. These provide indications as to normative capabilities defined in this technical specification.

243 1.2 Summary

of

Contents of Document

244

This document describes the ebBP technical specification.

245

The document first introduces general concepts and semantics, and then applies these semantics in a

246

detailed discussion of each part of the model. The document then specifies all elements in XML form.

247 1.3 Audience

248

The primary audience is business process analysts. We define a business process analyst as someone

249

who interviews business people and as a result documents business processes in unambiguous syntax.

250

An additional audience is designers of business process definition tools who need to specify the

251

conversion of user input in the tool into the XML representation of the ebBP artifacts.

252

2

(9)

1.4 Related

Documents

253

As mentioned above, other documents provide detailed definitions of some of the components of the

254

ebBP technical specification and of their inter-relationship. They include ebXML Specifications on the

255

following topics:

256

• ebXML Technical Architecture Specification, version 1.04

257

• ebXML Core Components Technical Specification, version 2.01

258

• ebXML Collaboration-Protocol Profile and Agreement Specification version 2.1 errata

259

• ebXML Business Process and Business Information Analysis Overview, version 1.0

260

• ebXML Business Process Analysis Worksheets & Guidelines, version 1.0

261

• ebXML E-Commerce Patterns, version 1.0

262

• ebXML Catalog of Common Business Processes, version 1.0 (original)

263

• UN/CEFACT - Common Business Process Catalog Technical Specification, version 1.0

264

(updated)

265

• ebXML Message Service Specification version 2.0

266

• UN/CEFACT Modeling Methodology (UMM) as defined in the N090R10 metamodel and

267

reference specification

268 1.5 Normative

References

269

[XML] Extensible Markup Language (XML), World Wide Web Consortium,

270

http://www.w3.org/XML.

271

[XSD1] XML Schema Part 1: Structures, Worldwide Web Consortium,

272

http://www.w3.org/TR/xmlschema-1/.

273

[XSD2] XML Schema Part 2: Datatypes, Worldwide Web Consortium,

274

http://www.w3.org/TR/xmlschema-2/.

275

[XInclude] XInclude, Recommendation, W3C, 20 December 2004:

276

http://www.w3.org/TR/xinclude.

277

[RFC2119] S. Bradner. Request for Comments 2119, Key words for use in RFCs to Indicate

278

Requirement Levels. IETF (Internet Engineering Task Force). 1997. Internet

279

Engineering Task Force RFC 2119, http://www.ietf.org/rfc/rfc2119.txt.

280

[XPath] XML Path Language (XPath), W3C Recommendation, 16 November 1999,

281

http://www.w3.org/TR/xpath.

282

[RFC2396] T. Berners-Lee. Request for Comments 2396, Uniform Resource Identifiers

283

(URI): Generic Syntax. IETF (Internet Engineering Task Force). 1998. Internet

284

Engineering Task Force RFC 2396, http://www.ietf.org/rfc/rfc2396.txt.

285 1.6 Non-Normative

References

286

[BPAW] ebXML Business Process Analysis Worksheets & Guidelines, v1.0,

287

http://www.ebxml.org/specs/bpWS.pdf.

288

[BPBIA] ebXML Business Process and Business Information Analysis Overview, v1.0,

289

http://www.ebxml.org/specs/bpOVER.pdf.

290

[BPMN] Business Process Modeling Notation (BPMN) v1.0, Object Management Group

291

(OMG), at: www.bpmn.org (BPMN site) or

http://www.omg.org/docs/dtc/06-02-292

01.pdf (at OMG).

293

(10)

ebxmlbp-v2.0.4-Spec-os-en 21 December 2006 [CBPC1] (original) ebXML Catalog of Common Business Processes, v1.0,

294

http://www.ebxml.org/specs/bpPROC.pdf.

295

[CBPC2] (updated) UN/CEFACT - Common Business Process Catalog Technical

296

Specification, v1.0, 30 September 2005,

297

http://www.cen.eu/UNcEFACTforum/TBG/tbg14.htm.

298

[DocEng] Glushko, Robert and Tim McGrath. Document Engineering - Analyzing and

299

Designing Documents for Business Informatics and Web Services,

300

http://www.docengineering.com/.

301

[ebCCTS] ISO/TS 15000-5:2005 Electronic Business Extensible Markup Language

302

(ebXML) — Part 5: ebXML Core Components Technical Specification, v 2.01

303

(ebCCTS),

http://www.oasis-open.org/committees/download.php/6232/CEFACT-304

CCTS-Version-2pt01.zip.

305

[ebCPPA2.1] ebXML Collaboration-Protocol Profile and Agreement working editor’s draft

306

errata, v2.1, 13 July 2005,

http://lists.oasis-open.org/archives/ebxml-307

cppa/200507/msg00000.html. Note: The .zip file is included in message. At the

308

time of this technical specification the schema is under revision related to CPA

309

changes.

310

[ebCPPA2] ebXML Collaboration-Protocol Profile and Agreement Specification v2.0, 20 May

311

2002, http://www.oasis-open.org/committees/download.php/202/ebCPP-2_0.pdf.

312

[ebMS2] ebXML Message Service Specification, v2.0,

http://www.oasis-313

open.org/committees/document.php?document_id=5553&wg_abbrev=ebxml-314

msg.

315

[ebRIM3] ebXML Registry Information Model OASIS Standard, v3.0, 5 May 2005,

316

http://docs.oasis-open.org/regrep/v3.0/regrep-3.0-os.zip.

317

[ebRS3] ebXML Registry Services OASIS Standard, v3.0, 5 May 2005,

http://docs.oasis-318

open.org/regrep/v3.0/regrep-3.0-os.zip.

319

[ebTA] ebXML Technical Architecture Specification, v1.04,

320

http://www.ebxml.org/specs/ebTA.pdf.

321

[ecPAT] ebXML E-Commerce Patterns, v1.0, http://www.ebxml.org/specs/bpPATT.pdf.

322

[MIME] Multipurpose Internet Mail Extensions (MIME) Part One, IETF RFC 2045: Format

323

of Internet Message Bodies, N. Freed, N. Borenstein, Authors. Internet

324

Engineering Task Force, November 1996. Available at

325

http://www.ietf.org/rfc/rfc2045.txt

326

[RNIF] RosettaNet Implementation Framework: Core Specification, Vv1.0: Release

327

2.00.00, 13 July 2001.

328

[SCH] Schematron, published ISO standard (DSDL project, www. dsdl.org), ISO/IEC

329

19757 - DSDL Document Schema Definition Language - Part 3: Rule-based

330

validation - Schematron,

331

http://xml.ascc.net/resource/schematron/schematron.html,

332

http://www.iso.ch/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=40

333

833.

334

[UMM] UN/CEFACT Modelling Methodology - Meta Model and Reference Information -

335

Revision 10, N090 (2001-11-01) specification,

336

http://www.untmg.org/index.php?option=com_docman&task=docclick&Itemid=13

337

7&bid=21&limitstart=0&limit=5 (as of September 2006).

338

[WS-A] WS-Addressing, W3C, W3C Recommendation, May 2006,

339

http://www.w3.org/2005/08/addressing.

340

[WSDL1.1] Web Services Description Language, v1.1, W3C Note, 15 March 2001,

341

http://www.w3.org/TR/wsdl.

342

(11)

ebxmlbp-v2.0.4-Spec-os-en 21 December 2006 [WSDL2] Web Services Description Language, v2.0, Candidate Recommendation, 27

343

March 2006, http://www.w3.org/TR/wsdl20/.

344

[XSLT] XML Transformations (XSLT), W3C Recommendation, v1.0, 16 November 1999,

345

http://www.w3.org/TR/xslt.

346

347

348

349

(12)

2 Design Objectives

350 2.1 Goals/Objectives/Requirements/Problem

Description

351

ebBP definitions describe interoperable business processes that allow business partners to

352

collaborate and achieve a given business goal. These definitions MUST be executed by software

353

components that collaborate on behalf of the business partners.

354

The goal of the ebBP technical specification is to provide the bridge between eBusiness process

355

modeling and execution of eBusiness software components.

356

The ebBP technical specification provides for the nominal set of specification elements necessary

357

to specify a Business Collaboration between business partners, and to provide configuration

358

parameters for the partners’ runtime systems in order to execute that Business Collaboration

359

between a set of eBusiness software components.

360

A business process definition created with the ebBP technical specification is referred to as an

361

ebBP definition.

362

The ebBP technical specification is available as an XML Schema

363

(http://www.w3.org/2001/XMLSchema). The ebBP XML schema, that provides the specification

364

for XML based ebBP definitions, can be found at this location:

365

http://docs.oasis-open.org/ebxml-bp/ebbp-2.0

366

(schema: ebbp-2.0.4.xsd)

367

The ebBP XML signal schema can be found at this location:

368

http://docs.oasis-open.org/ebxml-bp/ebbp-signals-2.0

369

(signal schema: ebbp-signals-2.0.4.xsd)

370

In order to accommodate varying tool capabilities surrounding namespaces and directories using

371

URIs, the URI for each schema has been updated. Current URI paths are found on the OASIS

372

ebBP public web site at:

373

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ebxml-bp

374

Under “’Technical Work Produced by the Committee’”

375

The schemas reflect the latest computable formats for an ebBP process definition.

376 2.2 Caveats

and

Assumptions

377

This technical specification is designed to specify the run time aspects of a Business

378

Collaboration.

379

It is not intended to incorporate a methodology, and does not directly prescribe the use of a

380

methodology. This specification does not by itself define Business Documents Structures. It is

381

intended to work in conjunction with already existing Business Document definitions, and/or the

382

document metamodel defined by the ebXML Core Components specifications.

383

The ebBP technical specification recognizes and concretely expresses the six defined, Business

384

Transaction patterns-Commercial Transaction, Notification, Information Distribution,

Request-385

Response, Request-Confirm, and Query Response. In the future, it is expected that new or

386

additional business requirements (such as for metadata) may be defined for contractual

387

agreements, acceptance, revocation of offers, etc. through efforts such as that of UN/CEFACT at

388

a minimum.

389

(13)

Examples, sample instances and the glossary are non-normative in this technical specification.

390

They are provided to aid the user community and implementers to use the ebBP v2.0.4 technical

391

specification and associated schemas. In addition to portions of this technical specification, the

392

ebBP and Business Signal schemas are related to and normative to this technical specification.

393

The examples are held outside of the non-normative and normative packages to enable frequent

394

updates.

395 2.3 Detailed Specification of Model Components

396

As with all the other specifications in the ebXML framework, an ebBP process definition may be

397

effectively used with other technologies. The ebXML framework has been composed of several

398

independent, but related or aligned, components. Specifications for each component can be used

399

individually, composed as desired, or integrated with other evolving technologies.

400

401

From the onset, these specifications have sought to be aligned as much as practical and capable

402

of being composed together and used with other technologies. That flexibility and composability

403

are important aspects not only to the adoption of these standards but their effective use and

404

successful deployment into heterogeneous environments and across domains. In the context of

405

this technical specification, Business Collaborations may be executed using the ebBP process

406

definition and/or used with other technologies. As it relates to the other specifications in the

407

ebXML framework, an ebBP process definition supports the loose coupling and alignment needed

408

to execute Business Collaborations. This specification may also be used when several other

409

software components are used to enable the execution of Business Collaborations. One example

410

is the use of web services mapped to business transactions activities. The ebBP technical

411

specification is used to specify the business process related configuration parameters for

412

configuring a Business Service Interface (BSI) to execute and monitor these collaborations. The

413

ebBP business semantics and syntax are also well-suited to enable definition of modular process

414

building blocks that are combined in complex activities to meet user community needs.

415

This section discusses:

416

• How the ebBP technical specification fits in with other ebXML specifications and may be

417

used with other emerging technologies (such as WSDL). An ebBP process definition

418

does not preclude composition with other process related technologies.

419

• How to use the ebBP artifacts at design time, either for specifying brand new

420

collaborations and transactions, or for re-using existing ones.

421

• How to specify core transaction semantics and parameters needed for or that may be

422

used by a Collaboration-Protocol Profile (CPP) or Collaboration Protocol Agreement

423

(CPA).

424

• Run-time transaction and collaboration semantics that the ebBP schema specifies and

425

the BSI is expected to manage.

426

427

As this technology matures and relevant profiles emerge, more compatibility points will be

428

specified or conformance information (where appropriate and applicable) defined in the context of

429

heterogeneous technology integration. For example, an ebBP profile is under development in

430

OASIS ebXML Implementation, Interoperability Conformance (IIC) TC, based on their deployment

431

template.

432 2.3.1 Use of ebBP With Other Specifications

433

The ebBP technical specification provides the structure and semantics of Business Collaboration

434

definitions.

435

(14)

A Business Collaboration consists of a set of roles that collaborate by exchanging Business

436

Documents through a set of choreographed transactions.

437

As shown in the following figure, Business Documents are defined at the intersection between the

438

ebBP technical specification and the ebXML Core Component specifications. An ebBP definition

439

will reference, but not define, a set of logical Business Documents. Within an ebBP definition,

440

Business Documents are either defined by some external document specification, or assembled

441

from lower level information structures called core components. The assembly is based on a set

442

of contexts, many of which are provided by the business processes, i.e. collaborations that use

443

the documents in their Document Flows.

444

The combination of the business process specification and the document specification become

445

the basis against which business partners can make agreements on conducting electronic

446

business with each other.

447

448

449

Figure 1: ebBP Definition and other ebXML artifacts

(15)

The user will extract and transform the necessary information from an existing Business Process

451

and Information Model and create an XML representation of an ebBP definition.

452

The XML representation of the ebBP definition gets stored in the ebXML repository and

453

registered in the ebXML registry for future retrieval. The ebBP definition would be registered

454

using classifiers derived during its design.

455

When implementers want to establish trading partner Collaboration Protocol Agreement, the

456

ebBP definition document, or the relevant parts of it, are simply referenced by the CPP and used

457

in the CPA XML documents. ebXML CPP and CPA XML documents MAY reference business

458

process specifications in XML such as an ebBP definition.

459

If one or more parties wish to participate on the basis of one or more web service definitions the

460

corresponding WSDL file(s) associated to the BTA(s) that is(are) representing the party MAY be

461

generated and MAY be referenced in the CPA if necessary.

462

Guided by the CPP and CPA specifications the resulting XML document then MAY become the

463

configuration file for one or more BSI, i.e. the software component that MAY manage either

464

business partner’s participation in a Business Collaboration.

465 2.4 Relationship to Other Specifications and Standards

466

This section describes the relationship of ebBP technical specification to other specifications

467

and/or standards. Later in Section 3, use of this specification with CPA is discussed in further

468

detail.

469 2.4.1 Relationship to CPP/CPA

470

An ebBP definition is, along with protocol specifications, the object of the agreement between two

471

or more parties. The ebBP definition MAY therefore be incorporated with or referenced by ebXML

472

trading partner CPP or CPA. The CPA articulates the technical mechanisms that configure a

473

runtime system and encourage interoperability between two parties that may use different

474

applications or software from different vendors.

475

Each CPP MAY declare its support for one or more Roles within the ebBP definition. An ebBP

476

definition is also a machine interpretable specification needed for a BSI, which will enforce its

477

definition at run-time. The CPP profiles and CPA agreements contain further technical

478

parameters resulting in a full specification of the run-time software at each trading partner. The

479

CPA currently supports the notion of business transactions between collaborating roles.

480

Messaging and CPA support conversations between parties. Each individually and collectively

481

map to the ebBP. The ebBP schema (and technical specification) provides guidance to the CPA

482

and messaging service regarding the processes used, the constraints expected, and the

483

relationship that exists between the parties.

484 2.4.2 Relationship

to Core Components

485

The ebBP technical specification does not by itself support the definition of Business Documents.

486

Rather, an ebBP definition merely points to the definition of logical Business Documents.3 Such

487

definitions MAY either be XML based, or – as attachments – MAY be any other structure, or

488

completely unstructured (e.g. related to images, EDI, binary data). XML based Business

489

Document Specifications MAY be based on the ebXML Core Components Technical

490

Specification (CCTS) such as OASIS Universal Business Language (UBL) specifications. In the

491

addition to the non-normative appendices to this technical specification, example instance will be

492

included in a separate package, publicly available on the OASIS web site to aid user

493

communities. These examples or illustrations of ebBP v2.0.4 instance use relevant document

494

3

(16)

vocabularies such as UBL and its corresponding Small Business Subset (SBS) to equate the use

495

of ebBP in real-world scenarios.

496

In ebBP, transitions are handled by state changes, whether sequential or determined through the

497

transitions. These transition conditions MAY relate to the sequential ordering handled by the

498

messaging and where those ebBP expectations MAY be enforced. The relationship between the

499

Messaging Service Interface and the BSI are further described in the appendices to this technical

500

specification.

501 2.4.3 Relationship to ebXML Message Service Specification

502

The ebBP technical specification will provide choreography of business messages and signals.

503

The ebXML Message Service Specification provides the infrastructure for message / signal

504

identification, typing, and integrity; as well as placing any one message in sequence with respect

505

to other messages in the choreography.

506

Messaging and CPA support conversations between parties. Each individually and collectively

507

may map to the ebBP. The ebBP schema (and technical specification) provides guidance to the

508

CPA and messaging service regarding the processes used, the constraints expected, and the

509

relationship that exists between the parties.

510 2.4.4 Relationship

to

WSDL

511

This version of the ebBP technical specification provides a mapping between BTAs (i.e. the

512

usage of a Business Transaction definition in a Business Collaboration definition) and operations

513

of one or multiple web services. The support of WSDL operations is intended for the design of

514

Business Collaborations in which one or more of the business partners are not capable of

515

supporting ebXML interchanges. The mapping provides the capability to map request, possible

516

responses and signals to abstract operation messages. The reference to an actual WSDL file is

517

specified as part of the Collaboration Profile Agreement (such as namespace references).

518

The correlation between the different operation invocations is implemented at run-time. The

519

specification does not provide any design-time correlation specification but recommends the use

520

of run-time correlation and endpoint references based on emerging addressing mechanisms such

521

as WS-Addressing, WS-MessageDelivery or others.

522

Correlation can provide additional functionality that could be desired where complex composed

523

activities occur, and visibility of the parties and their activities must be managed.

524

Implementation note

525

The possible capabilities of the underlying infrastructure and services chosen may impact

526

the capability to support business requirements defined by the involved parties. For

527

example, specific constraints may apply to WSDL-based exchanges that may not exist

528

for those implementations using ebXML Messaging Service.

529 2.4.5 Relationship to Registry/Repository

530

Although independent, the ebXML components are designed to work together in a loosely

531

coupled fashion. At a minimum, the ebXML Registry/Repository could allow the discovery and

532

use of ebBP instances. If artifacts are given a classification, the instances and the profiles of the

533

BT patterns could be part of a business process catalogue. They may be available to an industry

534

group, enterprise or entity. The ebXML Registry/Repository provides the capability to version and

535

manage such artifacts (See preceding figure and a similar one in Section 3).

536

(17)

3 Language Overview

537

The ebBP technical specification defines a standard language for business process specification.

538

An ebBP definition works with the ebXML CPP/CPA specification to bridge the gap between

539

Business Process Modeling and the configuration of eBusiness software (See following figure).

540

The software component that manages Business Collaborations on behalf of one business

541

partner is referenced in this specification as the BSI. A detailed discussion on the BSI can be

542

found in the appendices to this technical specification. The BSI supports predictable eBusiness

543

interactions. However, this does not specifically limit the use of ebBP technical specification to

544

those interactions. This technical specification supports the computable and executable language

545

used for Business Collaboration, rather than the processing accomplished from the view of a

546

single party. Predictability is supported within the scope of and at the level of abstraction that a

547

Business Collaboration operates. The functions are described in this technical specification.

548

A business process specification may be used to guide other executable process mechanisms to

549

drive enterprise components where Business Collaboration definition enables monitoring and/or

550

control (rather than creation) of service behavior.

551

552

553

Figure 2: Business Process Specification and Business Service Interface Configuration

554

555

Using business process modeling, a user MAY create a complete business process and

556

information Model.

557

Based on this model and using the ebBP technical specification the user will then extract and

558

format the nominal set of elements necessary to configure an ebXML runtime system in order to

559

execute a set of ebXML Business Transactions. The result is an ebBP definition.

560

Alternatively the ebBP definition MAY be created directly, without prior explicit business process

561

modeling.

562

(18)

An ebBP definition contains the specification of Business Transactions and the choreography of

563

these Business Transactions that are included in Business Collaborations.

564

This ebBP definition may then be the input to the formation of ebXML trading partner

565

Collaboration Protocol Profiles and Collaboration Protocol Agreements.

566

These ebXML trading partner Collaboration Protocol Profiles and Collaboration Protocol

567

Agreements in turn serve as configuration files for BSI software component.

568

569

When a reference is generically made to a “BSI”, it may logically represent middleware,

570

applications, backend systems, software or services. These components may exist

571

within a logical enterprise (one or more domains of control). The BSI was a key

572

component in the original ebXML framework.

573

The BSI represents an important component in realizing eBusiness automation and deployment.

574

The BSI MAY be configured from an ebBP definition and a CPA. The architecture of the ebBP

575

technical specification consists of the following functional components:

576

• A representation of Business Collaboration using accepted business process modeling

577

techniques. Representations in this specification use the Business Process Modeling

578

Notation (BPMN).

579

• XML Schema definition of the ebBP definition. Each ebBP definition MUST conform to

580

this schema definition.

581

• Business Signal Definitions

582

Together these components allow you to specify the run time aspects of a business process

583

model within the scope of this current version of the ebBP . However, all the parameters of the

584

ebBP definition are intended to be specified at design time rather than specified or inferred at

run-585

time. However, some values may be acquired or quantified at other than design time.

586

These components are shown in Figure 3 that follows.

587

(19)

588

UMM Metamodel and Reference (N090, R10)

ebXML ebBP (Schema and Technical

Specification) Business Signal Definitions Logical Business Document Definition Business Information Core Component Business Information Business Transaction Patterns and Semantics ebXML ebBP Instance CPP CPA CPP

589

Figure 3: Relationship of ebBP technical specification to UMM, CPP/CPA and Core

590

Components

591

592

593

Throughout this document, typically business partner is used when related to agreement

594

between parties. Trading partner is used when related to CPA. Party is typically used

595

when related to a role that a business partner plays, such as a responding party.

596 3.1 XML Schema Representation of Business Process

597 Definitions

598

The corresponding XML Schema representation of the ebBP technical specification provides the

599

specification for XML based definitions of an ebBP schema, and MAY serve as a target for

600

production rules from other representations. Thus, a user MAY either create an ebBP definition

601

directly as an XML document or from other representations.

602

Any methodologies and/or metamodels used for the creation of ebBP definitions MUST at a

603

minimum support the production of the elements and relationships contained in the XML

604

representation of the ebBP technical specification and defined in the ebBP schema.

Well-605

formedness rules are specified in order to facilitate the understanding and use of the XML

606

schema representation of the ebBP technical specification.

607

The complete XML schemas (core and signal) and their association documentation are provided

608

in separate Schema and Signal Schema packages. Example XML instances are provided in a

609

(20)

non-normative package outside of this technical specification and the appendices to aid user

610

communities.

611 3.2 Business Signal Definitions

612

A Business Signal is an object that is transmitted back to the activity that initiated the transfer of

613

execution control. Business signals have a specific business purpose and are separate from

614

lower protocol and transport signals as defined in the ebXML Message Service Specification. The

615

state of a given Business Transaction Activity (BTA) instance can be explicitly calculated at

run-616

time by evaluating these signals. As such they are instrumental in establishing a Business

617

Collaboration protocol that insures that the representation of the state of a Business Collaboration

618

instance for each party, is strictly identical. For example, an Acceptance Acknowledgement

619

signal is generated after an application, service or middleware4 has successfully processed and

620

business validated a Business Document. The process of exchanging signals and state changes

621

of a Business Transaction enables "state alignment" between the parties involved. The structures

622

of ebXML Business Signals are ‘universal’ and do not vary from transaction to transaction. Thus,

623

they can be defined once and for all. The Signal schema is in the packages that support this

624

technical specification.

625

The ebBP technical specification provides both the structure and choreography of Business

626

Signals. The ebXML Message Service Specification provides a reliable messaging infrastructure.

627

This is the basis upon which the ebBP technical specification builds its protocol for business state

628

alignment using Business Signals. The Business Signal payload structures are optional and

629

normative and are intended to provide business semantics to the Business Signals.

630

A schema is provided for the possible Business Signals. Examples of sample signal instances are

631

available in addition to this technical specification and the appendices. They may be found on the

632

OASIS web site in a non-normative example package.

633 3.3 Well-Formedness

Rules

634

A starting set of well-formedness rules is provided to aid implementers in using ebBP technical

635

specification constructs. In Section 3.8, well-formedness rules exist for the use of, at a minimum:

636

• Business Collaborations

637

• Time To Perform

638

• Notification of Failure and exceptions

639

• Condition expressions and variables

640

• Web services operations

641

• Packages and includes

642

643

Referential and functional constraints are described in Section 3.8. Other well-formedness rules

644

will be defined as more industry and user community knowledge and requirements are available.

645

646

4

When a reference is generically made to an “application”, it may represent middleware, applications, backend systems, software or services. These components typically exist within a logical enterprise (one or more domains of control).

(21)

3.4 Key Concepts of This Technical Specification

647

The ebBP specification specifies the structure and semantics of machine processable Business

648

Collaborations definitions. These semantics are aligned with guiding principles relevant to

649

business processes such as the UMM.

650

At a high level, a Business Collaboration consists of a set of roles collaborating through a set of

651

choreographed Business Transactions by exchanging Business Documents.

652

These basic semantics of a Business Collaboration are illustrated in Figure 4.

653

654

Figure 4: Illustration of the basic semantics of a Business Collaboration

655

Two or more business partners participate in the Business Collaboration through roles. The roles

656

always exchange messages in the context of Business Transactions. Each Business Transaction

657

consists of one or two predefined Business Document Flows. One or more Business Signals

658

MAY additionally be exchanged as part of a Business Transaction to ensure state alignment of

659

both parties. The Business Collaboration is defined as a choreography of Business Transactions

660

performed relative to each other.

661

The following section describes the concepts of a Business Collaboration, a Business

662

Transaction, a Business Document Flow, and Choreography. Business messages and Business

663

Signals are discussed throughout. A business message is typically associated with a Business

664

Document Flow rather than a Business Signal.

665 3.4.1 Business

Collaborations

666

A Business Collaboration is a set of Business Activities executing Business Transactions

667

between business partners or collaborating parties. Each business partner plays one or more

668

abstract partner roles in the Business Collaboration. The state of the Business Collaboration is

669

logical between the parties interacting in a peer-to-peer rather than a controlled environment. The

670

virtual state of the Business Collaboration lies with the involved partners. Peer-to-peer

671

(22)

collaboration may involve business partners as well as distributed collaborating parties. For the

672

latter, one example may be cross-organizational collaboration between parties involved in

673

technical publishing where the nested, complex activities may be required to support an authoring

674

process. Cross-organizational collaboration may occur in many organizations, such as those

675

government departments and agencies enabling eGovernment. The relevance of and use of the

676

business transaction patterns in such an environment is discussed in the book by Robert Glushko

677

and Tim McGrath, Document Engineering - Analyzing and Designing Documents for Business

678

Informatics and Web Services.5

679

The ebBP technical specification supports several levels of Business Collaborations. Business

680

Collaborations can be specialized as Binary or Multiparty (Business) Collaborations.6

681

When a Business Collaboration is specialized, a Binary (Business) Collaboration involves two

682

top-level or abstract partner roles only. For the purposes of this specification, these roles are

683

sometimes called abstract partner roles. Multiparty (Business) collaborations involve more than

684

two abstract partner roles. Business Collaborations are expressed as a set of Business Activities

685

between these roles. Each abstract partner role occupies a specific role when associated with a

686

Business Activity.

687

688

The Business Activity can be a Business Transaction Activity (i.e. the activity of conducting a

689

single Business Transaction) or a Collaboration Activity (i.e. the activity of conducting another

690

Business Collaboration such as a Binary (Business) Collaboration within another Binary

691

(Business) Collaboration). An example of the former is the activity of “process purchase order”.

692

An example of the latter is the activity of “negotiating a technical contract”. The example

693

instances, found on the OASIS web site show how an ebBP definition could be used for CPA

694

negotiation. In either case the activities can be choreographed relative to other activities as per

695

below.

696

697

The ability of a Binary (Business) Collaboration to have activities that in effect are executing

698

others is the key to recursive compositions and re-use of Business Collaborations.

699

700

In essence each Business Collaboration is a re-useable protocol between two or more agreeable

701

parties that may assume and occupy different roles at various steps in the process.

702

Typically, a Business Transaction is defined once. However, the BT could appear many times as

703

different Business Transaction Activities, where the roles change within the same Binary

704

(Business) Collaboration, such as for an Offer and Counter Offer. As shown in the CPA example

705

in the non-normative examples package, this is a known case in CPA negotiation. An activity,

706

whether it is a Business Transaction Activity (BTA) or a Collaboration Activity represents the

707

usage of a definition within another Business Collaboration. In the Business Transaction

708

Activities, the abstract role in the Business Transaction becomes a specific role, where roles may

709

change within the same Binary (Business) Collaboration. In that case, either abstract role in the

710

Business Transaction MAY assume the initiating role in the BTA.

711

712

Business Collaboration between more than two abstract partner roles (i.e. Multiparty

713

Collaboration) may be conducted in many presumed ways, including using coordination or as a

714

community of peers. Functions to support Multiparty Collaboration may include status visibility,

715

state alignment, identity, business constraints, etc. Business requirements are being gathered to

716

gain more understanding of and define constructs for complementary functionality to support this

717

type of Business Collaboration in addition to capabilities in this technical specification.

718

5

In Chapters 9 and 10 (particularly Sections 9.3 and 9.3.1), many core aspects in ebBP are described such as the relevance of logical business documents, business transaction patterns, and context where used. As well, it outlines the importance of collaboration and the underlying patterns composed and used for business partners and collaborating parties. See: http://www.docengineering.com/.

6

Note: In this version, specific Binary and Multiparty Collaboration elements are being retained but are to be replaced by Business Collaboration. For consistency herein, when either is referenced “(Business)” is also specified to familiarize the user community with this upcoming change.

(23)

3.4.2 Business

Transactions

719

A Business Transaction represents an atomic unit of work that may be associated with a trading

720

arrangement between two business partners. The scope of the ebBP technical specification is to

721

articulate more fully the Business Transactions, rather than primarily focusing on their relationship

722

to trading arrangements between business partners. In the future, more requirements are

723

anticipated to further express this relationship, such as from UN/CEFACT. Atomicity in the

724

context of this technical specification is outlined in the glossary at the end of this document.

725

A Business Transaction is conducted between two parties playing opposite abstract roles in that

726

transaction. Each party, as an abstract partner, assumes an abstract role in a Business

727

Transaction. Those roles are always generic and labeled as Requesting and Responding roles.

728

The specific roles(e.g. buyer, seller) MUST be specified at the Business Transaction Activity

729

level, when the Business Transaction definition is used for a distinct purpose. At that point, the

730

abstract partner assumes and occupies a specific role, as a role occupant. Only two role

731

occupants may be active at one time in a BTA.

732

733

Like a Binary (Business) Collaboration, a Business Transaction is a re-useable protocol between

734

two abstract roles (explicit generic Requesting and Responding Roles). The way it is re-used is

735

by referencing it from a Binary (Business) Collaboration through the use of a BTA as per above.

736

In a Business Transaction Activity the specific roles of the Binary (Business) Collaboration are

737

assigned to the execution of the Business Transaction. As indicated in the previous section, a

738

Business Collaboration may be composed within another Business Collaboration via a

739

Collaboration Activity. Each abstract partner participates in the Business Collaboration and

740

occupies different role (occupants) in the included Business Transactions. How the external role

741

in a Business Collaboration maps to the roles defined within the enclosed Business Transactions

742

is mapped to a series of role relationships. How this is accomplished using the Performs element

743

and external role mapping is found later in Sections 3.4.5 (shows Multiparty interactions) and

744

3.4.10.1.

745

746

Unlike a Binary (Business) Collaboration, however, the Business Transaction is atomic; it cannot

747

be decomposed into lower level message exchanges that could be reused independently of each

748

other.

749

A Business Transaction is a very specialized and very constrained protocol used to achieve very

750

precise and support enforceable transaction semantics and achieve state alignment when

751

needed between both parties. The software component managing the Business Transaction, i.e.

752

a BSI component, SHOULD enforce these semantics. For example, the BSI monitors the timers

753

and requirements of the Business Collaboration. It is important to note that the BSI MAY interact

754

with other software components that check the validity of business messages or documents or

755

perform other monitoring or application functions. A Business Transaction MUST succeed or fail

756

from both a technical and business protocol perspective. If it succeeds from both perspectives it

757

MAY be designated as having shared intent between the two business partners, or otherwise

758

govern their collaborative activity. As defined by the parties’ expectations, if it fails then it is null

759

and void, and each partner MUST terminate and release any shared statement established by the

760

transaction7. In addition, if it fails from protocol perspective, each party MUST synchronize their

761

state to the state prior to the start of the transaction. For instance, a purchase order state should

762

advance to “sent” when and only when the BSI reports a Protocol Success. In the case of a

763

Business Failure, the state has already been “synchronized” and it is the duty of each application

764

or service to take the proper actions. A Business Failure is any Failure that is identified by an

765

application or service during the processing of the Business Document(s) and based on

766

information not available in or part of the ebBP instance. For instance, a “reject purchase order”

767

response document would be considered as a Business Failure. In this case, it is the role of the

768

applications to mark the state of the purchase order appropriately. Success and failure, the

769

7