Contributions for the development of ebBP examples of UBL related documents by J. Dean Hemopo, ebxml-dev, New Zealand (user community), and Stephen Green, UK local government (user community) and Sacha Schlegel (Member).

Related Work:

See Section 1.4 : Related Documents.

Abstract:

This document defines a standards-based business process foundation that promotes the automation and predictable exchange of Business Collaboration definitions using XML.

Status:

This set of ebBP documents are compatible with the ebXML Business Process Specification Schema v1.01 technical specification and schema, and a migration path is possible from v1.01, v1.04 and v1.05 to v2.0.x documents. The technical specification supersedes the v2.0 Committee Draft / Committee Specification[1], v2.0.1 and v2.0.2 Committee Drafts, and the v2.0.3 Committee Specification.

Six packages are provided for ebBP:

1. Normative: A package for the technical specification and appendices (Artifact Type: Spec, and Artifact Type: Spec and Descriptive Name: Appendices)

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

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

4. Non-normative: A package that includes the Public Review comments list, files for an exemplary XSLT transform to assist the user community to begin to migrate v1.01, v1.04 and v1.05 ebBP instances (for information and reference only) [Artifact Type: Document, Descriptive Name: Supplements]

5. Normative: A package of ebBP schema-generated documentation for ebBP schema (Artifact Type: Document, Descriptive Name: Schema)

6. Normative: A package of ebBP signal schema-generated documentation (Artifact Type: Document, Descriptive Name: SignalSchema).

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

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

Exemplary process definition and signal instances and illustrations are also provided in a publicly available package on the OASIS site. This final package is non-normative and outside the review and TC process cycle of this technical specification. This technical specification provides non-normative examples (XML instance snippets) while more complex ebBP definitions may be found in the examples package.

The ebXML Business Process TC charter including scope is found at: http://www.oasis-open.org/committees/ebxml-bp/charter.php.

Committee members should send comments on this specification to the ebxml-bp@lists.oasis-open.org list. Others should subscribe to and send comments to the ebxml-bp-comment@lists.oasis-open.org list. To subscribe, send an email message to ebxml-bp-comment-request@lists.oasis-open.org with the word "subscribe" as the body of the message.

For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the ebXML Business Process TC web page (http://www.oasis-open.org/committees/ebxml-bp/ipr.php). The IPR policy in effect as of this document is the Legacy IPR policy.

The non-normative errata page for this specification is located at www.oasis-open.org/committees/ebxml-bp.

Notices

OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS's procedures with respect to rights in OASIS specifications can be found at the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification, can be obtained from the OASIS Executive Director.

OASIS invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to implement this specification. Please address the information to the OASIS Executive Director.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to OASIS, except as needed for the purpose of developing OASIS specifications, in which case the procedures for copyrights defined in the OASIS Intellectual Property Rights document must be followed, or as required to translate it into languages other than English.

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

This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Table of Contents

ebXML Business Process Specification Schema Technical Specification v2.0.4. 1

1 Introduction.. 9

1.1 Terminology. 9

1.2 Summary of Contents of Document 9

1.3 Audience. 9

1.4 Related Documents. 10

1.5 Normative References. 10

1.6 Non-Normative References. 10

2 Design Objectives. 13

2.1 Goals/Objectives/Requirements/Problem Description.. 13

2.2 Caveats and Assumptions. 13

2.3 Detailed Specification of Model Components. 14

2.3.1 Use of ebBP With Other Specifications. 14

2.4 Relationship to Other Specifications and Standards. 16

2.4.1 Relationship to CPP/CPA. 16

2.4.2 Relationship to Core Components. 16

2.4.3 Relationship to ebXML Message Service Specification. 17

2.4.4 Relationship to WSDL. 17

2.4.5 Relationship to Registry/Repository. 17

3 Language Overview.. 18

3.1 XML Schema Representation of Business Process Definitions. 20

3.2 Business Signal Definitions. 21

3.3 Well-Formedness Rules. 21

3.4 Key Concepts of This Technical Specification.. 22

3.4.1 Business Collaborations. 22

3.4.2 Business Transactions. 24

3.4.3 Business Document Flows. 25

3.4.4 Choreography. 25

3.4.5 How to Design Business Collaborations and Business Transactions. 26

3.4.6 Packages, Includes and Specifications. 28

3.4.6.1 Packages. 28

3.4.6.2 Specification element 29

3.4.6.3 Include elements. 30

3.4.7 Versioning. 31

3.4.8 Attribute Substitution Sets. 32

3.4.9 Business Transaction and Business Document Flow.. 32

3.4.9.1 Key Semantics of a Business Transaction. 32

3.4.9.2 Sample syntax. 48

3.4.9.3 Business Signals. 48

3.4.9.3.1 Receipt Acknowledgement Business Signal 48

3.4.9.3.2 Acceptance Acknowledgement Business Signal 48

3.4.9.3.3 Business Signal Criteria. 49

3.4.9.4 Sample syntax. 51

3.4.9.5 Business Document Flows. 52

3.4.9.6 Sample syntax. 52

3.4.9.7 Business Transaction Activity. 54

3.4.9.8 Operation Mapping. 54

3.4.9.9 Sample syntax. 57

3.4.10 Specify a Business Collaboration. 58

3.4.10.1 Key Semantics of a Business Collaboration. 58

3.4.10.2 Sample syntax. 63

3.4.11 Choreography. 64

3.4.11.1 Key Semantics of a Choreography. 64

3.4.11.1.1 Use of Variables and Condition Expressions. 65

3.4.11.2 Sample syntax. 67

3.5 Core Business Transaction Semantics. 68

3.5.1 Interaction Predictability. 69

3.5.1.1 Transaction Interaction Patterns. 71

3.5.2 Business Transactions and Shared Intent 71

3.5.3 Non-Repudiation. 72

3.5.4 Authorization security. 73

3.5.5 Document security. 73

3.5.6 Reliability. 74

3.5.7 Parameters required for CPP/CPA. 74

3.5.7.1 Handling Partner Roles. 74

3.5.7.2 Handling Operation Mapping. 75

3.6 Run time Business Transaction Semantics. 75

3.6.1 Timeouts. 77

3.6.2 Protocol Exceptions. 78

3.6.2.1 Receipt Acknowledgement Exception. 78

3.6.2.2 Acceptance Acknowledgement Exceptions. 79

3.6.2.3 Notification of Failure Business Messages and General Exception Signals. . 79

3.6.2.4 BSI Conformance. 82

3.6.3 Computation of the status of a Business Transaction Activity. 83

3.7 Where the ebXML Business Process Specification May Be Implemented.. ....... 87

3.8 Business Collaboration and Business Transaction Well-Formedness Rules. . 87

3.8.1 Assumptions. 87

3.8.2 Referential Constraints. 88

3.8.3 Functional or Other Well-Formedness Rules. 90

3.8.3.1 Specification Element 90

3.8.3.2 Variables. 90

3.8.3.3 Business Collaborations. 91

3.8.3.4 Business Signals. 91

3.8.3.5 Roles. 91

3.8.3.6 Notation for Visual Representation. 92

3.8.3.7 Timing Parameters. 92

3.8.3.8 Operation Mapping. 92

3.8.3.9 Other 92

4 ebXML Business Process Specification Schema. 93

4.1 Documentation for the ebBP and Signal Schemas. 93

Note: Appendices are held in a separate document in the Spec package.

1 Introduction

The eBusiness eXtensible Markup Language (ebXML) Business Process Specification Schema (BPSS) technical specification defines a standard language by which business systems MAY be configured to support execution of Business Collaborations consisting of Business Transactions. It is based upon prior UN/CEFACT work, specifically the metamodel behind the UN/CEFACT Modeling Methodology (UMM) defined in the “UN/CEFACT Modeling Methodology - Meta Model - Revision 10. In the future, when a reference guide becomes available subsequent versions will be evaluated and other metadata requirements analyzed. These could include those developed under the United Nations Centre for Trade and Facilitation and Electronic Business (UN/CEFACT), such as from the Unified Business Agreements and Contracts (UBAC).[2] The ebBP technical specification supports the specification of Business Transactions and the choreography of Business Transactions into Business Collaborations. All Business Transactions are implemented using one of many available standard patterns. These patterns are defined in the UMM specification. A pattern is not executable; it rather specifies the type of the message exchange (request, response and signals) that applies for a given Business Transaction definition. It is a way to define classes of Business Transaction definitions. These patterns could potentially be related to different classes of electronic commerce transactions.

The current version of the ebBP technical specification addresses Business Collaborations between any number of parties (Business Collaborations specialized to Binary or Multiparty Collaborations). It also enables participants, which are capable of using Web service or combined technologies (such as ebXML and web services) to participate in a Business Collaboration. It is anticipated that a subsequent version of this technical specification will address additional features such as the semantics of economic exchanges and contracts, and context based content based on the metadata requirements provided by relevant organizations.

Implementation Note:

Throughout this document, shorthand is used. The technical specification is referenced as the ebBP technical specification. An ebBP business process definition is identified as an ebBP definition. An ebXML BPSS instance is an ebBP instance. An ebXML BPSS schema is an ebBP schema.

1.1 Terminology

The key words must, must not, required, shall, shall not, should, should not, recommended, may, and optional in this document are to be interpreted as described in [RFC 2119]. These provide indications as to normative capabilities defined in this technical specification.

1.2 Summary of Contents of Document

This document describes the ebBP technical specification.

The document first introduces general concepts and semantics, and then applies these semantics in a detailed discussion of each part of the model. The document then specifies all elements in XML form.

1.3 Audience

The primary audience is business process analysts. We define a business process analyst as someone who interviews business people and as a result documents business processes in unambiguous syntax.

An additional audience is designers of business process definition tools who need to specify the conversion of user input in the tool into the XML representation of the ebBP artifacts.

1.4 Related Documents

As mentioned above, other documents provide detailed definitions of some of the components of the ebBP technical specification and of their inter-relationship. They include ebXML Specifications on the following topics:

· ebXML Technical Architecture Specification, version 1.04

· ebXML Core Components Technical Specification, version 2.01

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

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

· ebXML Business Process Analysis Worksheets & Guidelines, version 1.0

· ebXML E-Commerce Patterns, version 1.0

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

· UN/CEFACT - Common Business Process Catalog Technical Specification, version 1.0 (updated)

· ebXML Message Service Specification version 2.0

· UN/CEFACT Modeling Methodology (UMM) as defined in the N090R10 metamodel and reference specification

1.5 Normative References

[XML] Extensible Markup Language (XML), World Wide Web Consortium, http://www.w3.org/XML.

[XSD1] XML Schema Part 1: Structures, Worldwide Web Consortium, http://www.w3.org/TR/xmlschema-1/.

[XSD2] XML Schema Part 2: Datatypes, Worldwide Web Consortium, http://www.w3.org/TR/xmlschema-2/.

[XInclude] XInclude, Recommendation, W3C, 20 December 2004: http://www.w3.org/TR/xinclude.

[RFC2119] S. Bradner. Request for Comments 2119, Key words for use in RFCs to Indicate Requirement Levels. IETF (Internet Engineering Task Force). 1997. Internet Engineering Task Force RFC 2119, http://www.ietf.org/rfc/rfc2119.txt.

[XPath] XML Path Language (XPath), W3C Recommendation, 16 November 1999, http://www.w3.org/TR/xpath.

[RFC2396] T. Berners-Lee. Request for Comments 2396, Uniform Resource Identifiers (URI): Generic Syntax. IETF (Internet Engineering Task Force). 1998. Internet Engineering Task Force RFC 2396, http://www.ietf.org/rfc/rfc2396.txt.

1.6 Non-Normative References

[BPAW] ebXML Business Process Analysis Worksheets & Guidelines, v1.0, http://www.ebxml.org/specs/bpWS.pdf.

[BPBIA] ebXML Business Process and Business Information Analysis Overview, v1.0, http://www.ebxml.org/specs/bpOVER.pdf.

[BPMN] Business Process Modeling Notation (BPMN) v1.0, Object Management Group (OMG), at: www.bpmn.org (BPMN site) or http://www.omg.org/docs/dtc/06-02-01.pdf (at OMG).

[CBPC1] (original) ebXML Catalog of Common Business Processes, v1.0, http://www.ebxml.org/specs/bpPROC.pdf.

[CBPC2] (updated) UN/CEFACT - Common Business Process Catalog Technical Specification, v1.0, 30 September 2005, http://www.cen.eu/UNcEFACTforum/TBG/tbg14.htm.

[DocEng] Glushko, Robert and Tim McGrath. Document Engineering - Analyzing and Designing Documents for Business Informatics and Web Services, http://www.docengineering.com/.

[ebCCTS] ISO/TS 15000-5:2005 Electronic Business Extensible Markup Language (ebXML) — Part 5: ebXML Core Components Technical Specification, v 2.01 (ebCCTS), http://www.oasis-open.org/committees/download.php/6232/CEFACT-CCTS-Version-2pt01.zip.

[ebCPPA2.1] ebXML Collaboration-Protocol Profile and Agreement working editor’s draft errata, v2.1, 13 July 2005, http://lists.oasis-open.org/archives/ebxml-cppa/200507/msg00000.html. Note: The .zip file is included in message. At the time of this technical specification the schema is under revision related to CPA changes.

[ebCPPA2] ebXML Collaboration-Protocol Profile and Agreement Specification v2.0, 20 May 2002, http://www.oasis-open.org/committees/download.php/202/ebCPP-2_0.pdf.

[ebMS2] ebXML Message Service Specification, v2.0, http://www.oasis-open.org/committees/document.php?document_id=5553&wg_abbrev=ebxml-msg.

[ebRIM3] ebXML Registry Information Model OASIS Standard, v3.0, 5 May 2005, http://docs.oasis-open.org/regrep/v3.0/regrep-3.0-os.zip.

[ebRS3] ebXML Registry Services OASIS Standard, v3.0, 5 May 2005, http://docs.oasis-open.org/regrep/v3.0/regrep-3.0-os.zip.

[ebTA] ebXML Technical Architecture Specification, v1.04, http://www.ebxml.org/specs/ebTA.pdf.

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

[MIME] Multipurpose Internet Mail Extensions (MIME) Part One, IETF RFC 2045: Format of Internet Message Bodies, N. Freed, N. Borenstein, Authors. Internet Engineering Task Force, November 1996. Available at http://www.ietf.org/rfc/rfc2045.txt

[RNIF] RosettaNet Implementation Framework: Core Specification, Vv1.0: Release 2.00.00, 13 July 2001.

[SCH] Schematron, published ISO standard (DSDL project, www. dsdl.org), ISO/IEC 19757 - DSDL Document Schema Definition Language - Part 3: Rule-based validation - Schematron, http://xml.ascc.net/resource/schematron/schematron.html, http://www.iso.ch/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=40833.

[UMM] UN/CEFACT Modelling Methodology - Meta Model and Reference Information - Revision 10, N090 (2001-11-01) specification, http://www.untmg.org/index.php?option=com_docman&task=docclick&Itemid=137&bid=21&limitstart=0&limit=5 (as of September 2006).

[WS-A] WS-Addressing, W3C, W3C Recommendation, May 2006, http://www.w3.org/2005/08/addressing.

[WSDL1.1] Web Services Description Language, v1.1, W3C Note, 15 March 2001, http://www.w3.org/TR/wsdl.

[WSDL2] Web Services Description Language, v2.0, Candidate Recommendation, 27 March 2006, http://www.w3.org/TR/wsdl20/.

[XSLT] XML Transformations (XSLT), W3C Recommendation, v1.0, 16 November 1999, http://www.w3.org/TR/xslt.

2 Design Objectives

2.1 Goals/Objectives/Requirements/Problem Description

ebBP definitions describe interoperable business processes that allow business partners to collaborate and achieve a given business goal. These definitions MUST be executed by software components that collaborate on behalf of the business partners.

The goal of the ebBP technical specification is to provide the bridge between eBusiness process modeling and execution of eBusiness software components.

The ebBP technical specification provides for the nominal set of specification elements necessary to specify a Business Collaboration between business partners, and to provide configuration parameters for the partners’ runtime systems in order to execute that Business Collaboration between a set of eBusiness software components.

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

The ebBP technical specification is available as an XML Schema (http://www.w3.org/2001/XMLSchema). The ebBP XML schema, that provides the specification for XML based ebBP definitions, can be found at this location:

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

(schema: ebbp-2.0.4.xsd)

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

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

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

In order to accommodate varying tool capabilities surrounding namespaces and directories using URIs, the URI for each schema has been updated. Current URI paths are found on the OASIS ebBP public web site at:

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

Under “’Technical Work Produced by the Committee’”

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

2.2 Caveats and Assumptions

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

It is not intended to incorporate a methodology, and does not directly prescribe the use of a methodology. This specification does not by itself define Business Documents Structures. It is intended to work in conjunction with already existing Business Document definitions, and/or the document metamodel defined by the ebXML Core Components specifications.

The ebBP technical specification recognizes and concretely expresses the six defined, Business Transaction patterns-Commercial Transaction, Notification, Information Distribution, Request-Response, Request-Confirm, and Query Response. In the future, it is expected that new or additional business requirements (such as for metadata) may be defined for contractual agreements, acceptance, revocation of offers, etc. through efforts such as that of UN/CEFACT at a minimum.

Examples, sample instances and the glossary are non-normative in this technical specification. They are provided to aid the user community and implementers to use the ebBP v2.0.4 technical specification and associated schemas. In addition to portions of this technical specification, the ebBP and Business Signal schemas are related to and normative to this technical specification. The examples are held outside of the non-normative and normative packages to enable frequent updates.

2.3 Detailed Specification of Model Components

As with all the other specifications in the ebXML framework, an ebBP process definition may be effectively used with other technologies. The ebXML framework has been composed of several independent, but related or aligned, components. Specifications for each component can be used individually, composed as desired, or integrated with other evolving technologies.

From the onset, these specifications have sought to be aligned as much as practical and capable of being composed together and used with other technologies. That flexibility and composability are important aspects not only to the adoption of these standards but their effective use and successful deployment into heterogeneous environments and across domains. In the context of this technical specification, Business Collaborations may be executed using the ebBP process definition and/or used with other technologies. As it relates to the other specifications in the ebXML framework, an ebBP process definition supports the loose coupling and alignment needed to execute Business Collaborations. This specification may also be used when several other software components are used to enable the execution of Business Collaborations. One example is the use of web services mapped to business transactions activities. The ebBP technical specification is used to specify the business process related configuration parameters for configuring a Business Service Interface (BSI) to execute and monitor these collaborations. The ebBP business semantics and syntax are also well-suited to enable definition of modular process building blocks that are combined in complex activities to meet user community needs.

This section discusses:

· How the ebBP technical specification fits in with other ebXML specifications and may be used with other emerging technologies (such as WSDL). An ebBP process definition does not preclude composition with other process related technologies.

· How to use the ebBP artifacts at design time, either for specifying brand new collaborations and transactions, or for re-using existing ones.

· How to specify core transaction semantics and parameters needed for or that may be used by a Collaboration-Protocol Profile (CPP) or Collaboration Protocol Agreement (CPA).

· Run-time transaction and collaboration semantics that the ebBP schema specifies and the BSI is expected to manage.

As this technology matures and relevant profiles emerge, more compatibility points will be specified or conformance information (where appropriate and applicable) defined in the context of heterogeneous technology integration. For example, an ebBP profile is under development in OASIS ebXML Implementation, Interoperability Conformance (IIC) TC, based on their deployment template.

2.3.1 Use of ebBP With Other Specifications

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

A Business Collaboration consists of a set of roles that collaborate by exchanging Business Documents through a set of choreographed transactions.

As shown in the following figure, Business Documents are defined at the intersection between the ebBP technical specification and the ebXML Core Component specifications. An ebBP definition will reference, but not define, a set of logical Business Documents. Within an ebBP definition, Business Documents are either defined by some external document specification, or assembled from lower level information structures called core components. The assembly is based on a set of contexts, many of which are provided by the business processes, i.e. collaborations that use the documents in their Document Flows.

The combination of the business process specification and the document specification become the basis against which business partners can make agreements on conducting electronic business with each other.

Figure 1: ebBP Definition and other ebXML artifacts

The user will extract and transform the necessary information from an existing Business Process and Information Model and create an XML representation of an ebBP definition.

The XML representation of the ebBP definition gets stored in the ebXML repository and registered in the ebXML registry for future retrieval. The ebBP definition would be registered using classifiers derived during its design.

When implementers want to establish trading partner Collaboration Protocol Agreement, the ebBP definition document, or the relevant parts of it, are simply referenced by the CPP and used in the CPA XML documents. ebXML CPP and CPA XML documents MAY reference business process specifications in XML such as an ebBP definition.

If one or more parties wish to participate on the basis of one or more web service definitions the corresponding WSDL file(s) associated to the BTA(s) that is(are) representing the party MAY be generated and MAY be referenced in the CPA if necessary.

Guided by the CPP and CPA specifications the resulting XML document then MAY become the configuration file for one or more BSI, i.e. the software component that MAY manage either business partner’s participation in a Business Collaboration.

2.4 Relationship to Other Specifications and Standards

This section describes the relationship of ebBP technical specification to other specifications and/or standards. Later in Section 3, use of this specification with CPA is discussed in further detail.

2.4.1 Relationship to CPP/CPA

An ebBP definition is, along with protocol specifications, the object of the agreement between two or more parties. The ebBP definition MAY therefore be incorporated with or referenced by ebXML trading partner CPP or CPA. The CPA articulates the technical mechanisms that configure a runtime system and encourage interoperability between two parties that may use different applications or software from different vendors.

Each CPP MAY declare its support for one or more Roles within the ebBP definition. An ebBP definition is also a machine interpretable specification needed for a BSI, which will enforce its definition at run-time. The CPP profiles and CPA agreements contain further technical parameters resulting in a full specification of the run-time software at each trading partner. The CPA currently supports the notion of business transactions between collaborating roles.

Messaging and CPA support conversations between parties. Each individually and collectively map to the ebBP. The ebBP schema (and technical specification) provides guidance to the CPA and messaging service regarding the processes used, the constraints expected, and the relationship that exists between the parties.

2.4.2 Relationship to Core Components

The ebBP technical specification does not by itself support the definition of Business Documents. Rather, an ebBP definition merely points to the definition of logical Business Documents.[3] Such definitions MAY either be XML based, or – as attachments – MAY be any other structure, or completely unstructured (e.g. related to images, EDI, binary data). XML based Business Document Specifications MAY be based on the ebXML Core Components Technical Specification (CCTS) such as OASIS Universal Business Language (UBL) specifications. In the addition to the non-normative appendices to this technical specification, example instance will be included in a separate package, publicly available on the OASIS web site to aid user communities. These examples or illustrations of ebBP v2.0.4 instance use relevant document vocabularies such as UBL and its corresponding Small Business Subset (SBS) to equate the use of ebBP in real-world scenarios.

In ebBP, transitions are handled by state changes, whether sequential or determined through the transitions. These transition conditions MAY relate to the sequential ordering handled by the messaging and where those ebBP expectations MAY be enforced. The relationship between the Messaging Service Interface and the BSI are further described in the appendices to this technical specification.

2.4.3 Relationship to ebXML Message Service Specification

The ebBP technical specification will provide choreography of business messages and signals. The ebXML Message Service Specification provides the infrastructure for message / signal identification, typing, and integrity; as well as placing any one message in sequence with respect to other messages in the choreography.

Messaging and CPA support conversations between parties. Each individually and collectively may map to the ebBP. The ebBP schema (and technical specification) provides guidance to the CPA and messaging service regarding the processes used, the constraints expected, and the relationship that exists between the parties.

2.4.4 Relationship to WSDL

This version of the ebBP technical specification provides a mapping between BTAs (i.e. the usage of a Business Transaction definition in a Business Collaboration definition) and operations of one or multiple web services. The support of WSDL operations is intended for the design of Business Collaborations in which one or more of the business partners are not capable of supporting ebXML interchanges. The mapping provides the capability to map request, possible responses and signals to abstract operation messages. The reference to an actual WSDL file is specified as part of the Collaboration Profile Agreement (such as namespace references).

The correlation between the different operation invocations is implemented at run-time. The specification does not provide any design-time correlation specification but recommends the use of run-time correlation and endpoint references based on emerging addressing mechanisms such as WS-Addressing, WS-MessageDelivery or others.

Correlation can provide additional functionality that could be desired where complex composed activities occur, and visibility of the parties and their activities must be managed.

Implementation note

The possible capabilities of the underlying infrastructure and services chosen may impact the capability to support business requirements defined by the involved parties. For example, specific constraints may apply to WSDL-based exchanges that may not exist for those implementations using ebXML Messaging Service.