ebXML Business Process Specification Schema Technical Specification Appendices v2.0.4

OASIS Standard, 21 December 2006

Specification URIs:

This Version:





Previous Version:



Latest Version:





Technical Committee:

ebXML Business Process Technical Committee (TC)


Dale Moberg, Cyclone Commerce/Axway

Monica J. Martin, Sun Microsystems


Jean-Jacques Dubray, Individual, jdubray@gmail.com [previous]

Sally St. Amand, Individual, sallystamand@yahoo.com

Monica J. Martin, Sun Microsystems, co-chair, monica.martin@sun.com


 John Yunker, Individual yunker@amazon.com (previous member)

David Webber, Individual, <david@drrw.info>

Dale Moberg, Cyclone Commerce/Axway, co-chair, dmoberg@us.axway.com

Kenji Nagahashi, Fujitsu, nagahashi@us.fujitsu.com

Stephen Green, Individual, stephengreenubl@gmail.com (previous member)

Sacha Schlegel, Individual, sacha@schlegel.li

Monica J. Martin, Sun Microsystems, co-chair, monica.martin@sun.com


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.


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


This set of ebXML Business Process Specification Schema (short name: 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, and v2.0.1 and v2.0.2 Committee Drafts, and the v2.0.3 Committee Specification.[1] 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 Business Transaction patterns matrices, Public Review comments list, a for Extensible Stylesheet Language Transformation (XSLT) conversion 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.

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.

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.

Table of Contents

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

1      Introduction to the Appendices. 5

Appendix A: Business Service Interface. 7

Appendix B: ebBP-CPA Mapping. 11

Appendix C: Manual or Implicit Business Transactions. 13

Appendix D: Handling Recursive or Optional Activities. 14

Appendix E: ebBP Glossary. 16

Appendix F:  Acknowledgements. 22

Appendix G:  Revision History. 23

Note: The technical specification is held in a separate document in the Spec package.

1        Introduction to the Appendices


These appendices are intended to be used with the v2.0.4 technical specification.

·         Appendix A: An overview of the Business Service Interface (BSI)

·         Appendix B: Relevant CPA-ebBP mapping. Note see the non-normative examples package for instances relevant to this mapping.

·         Appendix C: An overview on manual or implicit activities

·         Appendix D: An overview of recursive or optional activities

·         Appendix E: ebBP Glossary

·         Appendix F: Acknowledgements

·         Appendix G: Revision History

Note: Only Appendix A includes normative language while all other appendices are informational in nature. The appendices are included in the normative package with the technical specification.

Exemplary signal and process definition instances are found on the OASIS web site. This package is separate as more examples are anticipated as more user communities and interested parties use ebBP.


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.

Copyright ©OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply.

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.









Appendix A: Business Service Interface

In the context of this technical specification, the Business Service Interface (BSI) is a logical definition for a party's actions, exposed as business services. It may be seen as a logical shared definition at different nodes. Logically, a BSI is a partner's implementation of the shared definition of business states and actions relevant to a common business goal. The BSI specifies the allowed set of business process and business object states of a business process, and the rules governing transitions between those states. In the context of the ebBP technical specification, only the shared business process is being managed. The interface to the BSI is through business messages and signals.


In execution, the BSI uses the current state of the business process, as defined in the Business Collaboration model, to guide actions and report the state changes. The ebBP technical specification defines the BSI behavior within the boundaries of the shared collaboration definition, but does not dictate its technical implementation. Its realization may be accomplished by using other supporting functions.


As described in this technical specification, the BSI is the logical set of transactions necessary to achieve a common goal. The BSI MAY bound the behavior of a Message Service Interface in the context of the shared collaboration definition. The BSI also provides requirements to the Message service Interface, such as quality of service (such as non-repudiation, authorization, etc) and service configuration capabilities.


The logical BSI MAY be associated with the messaging component. The BSI MAY be completely separate from the Message Service Interface (which is also another abstract boundary). The Messaging Service Interface, in the context of this technical specification, encompasses the set of messages exchanged between partners, and the interface-defined rules governing the sequence and processing used to support a business process. The ebBP artifacts may specify the sequence and some of the processing rules. The BSI and Messaging Service Interface MAY effectively be used together. Or, the Message Service Interface MAY be used without a BSI.


Therefore, a BSI is:


1.       A discrete set of business process states (results of Business Transactions) shared and aligned between trading partners.

2.       A discrete set of Business Transactions.

3.       A discrete set of transitions between Business Transactions.

4.       The business rules governing (1) through (3).


As indicated in the technical specification, this software component  recognizes the Business Document Flows and Business Signals, and their relationship to the Business Transaction patterns (and business semantics). These capabilities provide the baseline for shared understanding, state alignment and inherently realization of the expectations of the parties involved.


The set of implementation choices may include use of JavaÔ[2] beans, web services, etc. That may define the business services are not specified.


A CPA actually specifies the interface with access points defined by the business process specification used. The CPA, which may contain a reference to an ebBP definition, serves as the basis for the configuration of the BSI to enforce the protocol and semantics of the ebBP definition or, in certain cases, override such rules, as depicted in Figure 1. The technical specification describes in more detail the relationshp between the ebBP and the CPA.

Figure 1: ebBP Definition and other ebXML artifacts


Implementer Note:: The ebBP technical specification does not specify how the BSI is implemented.  For example, the BSI concepts may be enabled through a BSI-aware business application or through behavior implemented as part of a Message Service Interface component. The business application may produce the Business Signals that are sent (realized) by the Message Service Handler (MSH).


At a minimum, the BSI MAY relate to the Message Service Interface in three ways:



The Message Service Interface may support and enforce the BSI in many ways, including through:



The ebXML Messaging Service (ebMS), Collaboration Protocol Profile and Agreements (CPA) and ebXML BPSS MAY act as a reference set to define the Message Service Interface/BSI behavior with a goal to alleviate human intervention.  At design time, the Message Service Interface may embed BSI business rules or the Message Service Interface and BSI MAY communicate in execution. Design and deployment decisions may guide where an implementation lies on this continuum. In the ebBP technical specification, constraints of the BSI concepts are recommended for any Messaging Service Interface. As a design choice, the  ebXML architecture, and this specification, modularizes and separates these different process and messaging functions.


A collaboration monitoring engine maintains the state of the collaboration. If mature, it may drive creation of messages if need be. In order to allow the messaging and collaboration layers work together, events are created/consumed between them. Each layer has responsibilities. Private or internal, and collaborative processes are decoupled.  The monitoring engine for the collaboration watches state transitions of the shared view.  For example, an Acceptance Acknowledgement (AA) signal may not be generated until successful business logic processing of a Business Document.  The monitoring engine for collaboration may receive a notification that processing is complete in order to generate the Acceptance Acknowledgement. The potential  implementation options could depend on the maturity of the involved systems, the intent of the parties involved and the flexibility/capability to decouple these activities. For example, some options include:



In execution, an implementation (i.e. an engine) may have a specific interface with a MSH and another defined one to domain-specific applications (such as backend systems), services or other engines. Where these logical boundaries lie when implemented, irrespective of actual handlers or interfaces, may be a product of the trading partner design choices and constraints, rather than a concrete boundary of software components.


The shared collaboration definition, that includes the Business Transaction set(s), the applicable Business Transaction patterns used, quality of service capabilities and other service configuration details, may result in profiles relevant to a group of trading partners, industry or domain.

Appendix B: ebBP-CPA Mapping

In the following table, a high-level mapping between service, action context, roles are shown for the v2.0.4 ebBP and the v2.1 CPA errata schemas. Note, see the non-normative public package on the OASIS site for exemplary instances relevant to this mapping.

ebBP v2.0.4

CPA v2.1 Errata (working draft)

Details or Comments









(Note: only where @isInnerCollaboration

 is false)

BusinessCollaboration/Role/@name BinaryCollaboration/Role/@name




RequestingBusinessActivity/@name RespondingBusinessActivity/@name






In ebBP: Specialization via restriction on each concrete BT pattern




In ebBP: Specialization via restriction on each concrete BT pattern




On Attachment: At the time of this document, the CPP/CPA team is discussing this change and the updated mapping.




On Attachment: At the time of this document, the CPP/CPA team is discussing this change and the updated mapping.




In ebBP: isTamperDetectable


On Attachment: At the time of this document, the CPP/CPA team is discussing this change and the updated mapping.




In ebBP: Specialization via restriction on each concrete BT pattern




In ebBP: Specialization via restriction on each concrete BT pattern

Table 1 ebBP and CPA Service-Action-Role Mapping (1 of 2)


ebBP v2.0.4

CPA v2.1 Errata (working draft)

Details or Comments




In ebBP: Specialization via restriction on each concrete BT pattern




In ebBP: Specialization via restriction on each concrete BT pattern





Changed from an attribute to an element in ebBP v2.0 versions. At the time of this document, the CPP/CPA team is discussing this change and the updated mapping.




In ebBP: Specialization via restriction on each concrete BT pattern

Table 1 ebBP and CPA Service-Action-Role Mapping (2 of 2)

Appendix C: Manual or Implicit Business Transactions

As indicated in the technical specification, the patterns are applied to Business Transactions. In a Business Transaction, a Request may be manual, implicit or not apply, whereby the intent of the involved parties may be important. Take the case where a user community is incrementally automating its business collaborations such as a telephone or fax request or a Status Order sent for quality certification.

·         If the Request is manual, a Commercial Transaction pattern could be used where the trigger is known when the Request occurs.

·         If the Request may or may not be used, the Data Exchange pattern could be used as the parties may bound the scope of how the pattern is used. When flexibility rather than predictability is desired, the Data Exchange specialization of a Business Transaction may be used.

·         If the Request is implicit (i.e. the Response is based on previous Commercial Transaction), the Notification pattern could be used. In this case, the Requesting Business Activity is a Response, i.e. the result of an action within the notifying entity. The actual Request may be implicit and the Response indicative of the intent of the parties.

Regardless of the options chosen, the visible state transitions available are modeled, in order to manage the transactions that occur. For example, a fork may be used between the two types of transactions (manual and automated), in order to make the visible state available for monitoring.

Appendix D: Handling Recursive or Optional Activities

In eBusiness, a business partner or collaborating party may need to plan for potential activities - those that  may occur more than once or more, or not at all (i.e. they are optional).  Several mechanisms can assist in realizing these needs including semantic variables, condition expressions and guards on transitions.  In the technical specification, we describe these capabilities in detail.

In this capabilities area, the ebBP primarily concentrates on the actual business collaborations defined by the business partners or collaborating parties involved in order to achieve optimal if not maximum interoperability. A continuum is supported from simple business transactions and collaborations (that are modular in design but capable of being packaged for optimal use by interested user communities) to complex collaborations (that recognize the intricacy of partner expectations).  What is developed and the complexity of the collaborations depends on the community and the partners involved.  When complex collaborations are developed, it is anticipated that the conditions surrounding them will also become more intricate, such as those discussed in 1. below.  It is a delicate balance to provide flexibility in the collaboration definition while also recognizing what user communities can enable and adopt.

For ebBP, conditions expressions are shareable and relevant to the parties involved. In some cases, these expressions may be similar to business rules relevant to a partner only, but may impose constraints on other business partners. There may be situations where they use these functions to elicit more control, such as in a hub.

It is important that user communities understand the potential and intricacy of such expressions when solving their complex eBusiness needs where appropriate. For example, the knit wear industry in Italy or UK local government may engage in activities which may or may not occur,  and, others that may occur more than once. For the Italian case, different order statuses or types of business messages with business documents may occur.  The process designer may utilize the ebBP capabilities for these purposes, including:

·         Condition expressions using BeginsWhen, EndsWhen, PreCondition, and PostCondition on Business Collaborations and Business Transactions: When these expressions are enabled in a computable way, they could be used as gating mechanisms to be available to enter or enter, or be available to exit or exit activities.  In this manner, the activities flow using Fork and Join to drive the correct Business Transactions.

·         Explicit recursions: Any Business Transaction may be part of a recursive loop that continues until explicitly terminated. The EndsWhen could be used in this case.

·         Explicit optionality: Any Business Transaction can be fronted by a Decision that explicitly excludes execution of the Business Transaction. For example, Partner A decides to send a business document today only as a discount offer.  Partner A may handle that through parallel execution paths and BeginsWhen.

·         Other examples:

o        Under certain conditions, it is unknown if more Order Status Update will occur. At some point, a Delivery Confirmation will be received with a different business document.  A Join may relate to this - when the Delivery Confirmation is received, always move on.  If this is not the case and explicit closure is more difficult, a Fork may be used where parallel processing occurs.

o         Both a Delivery Advice and a Freight Status Advice could be occurring concurrently.  A PreCondition could be used to determine that if a Delivery Advice is received, that branch is done and the Business Collaboration completes.

·         Condition expressions on gateways for Fork, Join and Decision: Using condition expressions on ToLink and FromLink: Condition expressions can be associated with the ToLink and FromLink elements. The conditionGuard attribute of the FromLink element can contain status values obtained from the state pointed to by the FromLink; matching the value governs whether a transition is made at run time. For the ToLink completion states can have condition expressions that are checked at runtime to determine whether the transition to a state is actually made.

o        Recursion example: For re-entering a transaction, a Fork could send the process back into the same Business Transaction. Conditions could be used on the Fork that  preclude re-entry. For example, a Freight Status Advice has several possible values - one that reoccurs many times with a condition on the Fork after the advice that says that if this status is 'delivered', then re-entry may not occur.   Otherwise, recycle and look for another one.

In the future, an optional declaration (additional attribute, for example) on a Business Transaction may be considered to support certain types of status messages.  In this case, assuming the explicit modeling of execution paths, any declaration would be considered documentation. However, additional changes will be focused on balancing the capabilities provided against the user communities served and their capability to adopt such functions.

See the technical specification associated with this appendix for more details on condition expressions, condition guards, business states and their characteristics.

Appendix E: ebBP Glossary

In the context and boundary of this technical specification and artifact package, a glossary has been developed to aid user communities for ebBP.



(Abstract) Operation

Description of an abstract action being carried out by a service, which is standalone having no relationship between operations, sequencing or enforcement, e.g. state alignment

Acceptance Acknowledgement

A Business Signal that is required or optional in the defined Business Transaction patterns; it signals that the message received (Request or Response) has been accepted and completed for business processing by the receiving application

Acceptance Acknowledgement exception

Signals an error condition in a Business Activity which requires termination of Business Transaction; usually means the processing application (which is unknown to other party) received the Business Document but was unable to successfully process it


In the context of a Business Transaction, involves a unit of work that cannot be decomposed further

Binary Collaboration

A set of Business Activities between two abstract partners or top level roles

Business Action

An abstract element container that is not included in a Business Transaction definition. It holds the elements common in both of the abstract partner roles of the two parties in a Business Transaction

Business Activity

A Business Activity can be expressed as a Business Transaction Activity, Complex Business Activity or a Collaboration Activity

Business Collaboration

A set of roles that business partners assume in a Business Activity through the exchange of business messages in a peer-to-peer environment rather than a controlled environment to achieve a business goal

Business collaboration choreography

Describes the potential sequencing and transitions in a Business Collaboration

Business collaboration level

Business Collaborations can be specialized as Binary or Multiparty Collaborations; or, nested in another Business Collaboration (in a Collaboration Activity)

Business collaboration protocol

Defines the business messages and signals that insure that state alignment for a Business Collaboration instance is strictly identical for both parties

Business Document

A logical structure that may be defined by an external document specification(s), or assembled from lower level information structures called core components; a logical entity that may be composed from more than one source and may be supplemented by unstructured documents such as attachments

Business Document Flow

A Business Transaction is realized as Business Document flows between the Requesting and Responding roles.




Business message

Can be either a Document Envelope or a Business Signal. It typically includes a Business Document. May include variable message content that may vary at run-time and over time, and is under the control of an application or service

Business Service Interface

A partner’s implementation of the shared definition of business states and actions relevant to a common business goal; may be identified as software component(s) that enforce(s) semantics and achieves state alignment for the parties

Business Signal

An object that is transmitted back to the activity that initiated the transfer of execution control; function is to communicate a specific business purpose; has a fixed structure and under control of infrastructure

Business state

A specific point in a Business Activity including transitions as part of the choreography

Business Transaction Activity

Performs a business transaction in a business collaboration; assigns specific roles, i.e. buyer, to the Requesting or Responding (abstract) roles

Business Transaction patterns

ebBP technical specification lists 8 patterns, which includes the  concrete expression of the 6 defined patterns in UMM; a reusable construct that specifies type of message exchange (request, response and business signals) that applies for a given Business Transaction definition, and the business semantics related to the pattern’s use

Business transaction protocol

Design to achieve state alignment between both parties involved in transaction through use of Business Signals and reliance on a reliable messaging service

Business Transaction

A unit of work in a trading arrangement between two parties playing opposite (abstract yet declared) roles; consists of one or two predefined Business Document Flows; will attain a Success or fail state


The ordering and transitions between Business Transactions, or collaborations, within a Business Collaboration

Collaboration Activity

The activity of conducting a Business Collaboration that transitions to another Business Collaboration

Complex Business Transaction Activity

Allows for nested Business Transaction Activities to happen in a recursive manner; this does not affect the atomicity of the Business Transaction rather it is a sequencing concept that provides status visibility to sub-parties acting in another BTA not the BTA defined

Condition Expression

A logical condition that evaluates to either true or false; used to interrogate contents of the Business Document

Document Envelope

Named representation of the Business Document Flow; is always one Document Envelope for a Requesting Activity. Can be zero, one or more mutually exclusive named Document Envelope for Responding Activity. Each contains one Business Document and may include one or more attachments




Document Envelope Notation

The name or identity of a Document Envelope

ebBP definition

A business process definition created with the ebXML Business Process Specification Schema technical specification; describes interoperable business processes that allow business partners to collaborate and achieve a given business goal

ebBP technical specification

Provides the elements needed to specify a Business Collaboration between business partners, and provides configuration parameters for the partners’ runtime systems in order to execute that Business Collaboration between a set of eBusiness software components (Business Service Interface)

General Exception

A Business Signal that is sent when unplanned (and often catastrophic) events occur


Governs incoming transitions; refers to status of an activity from which the transition originates


May represent shared statement between trading partners and their shared intent

Initiating role

The role in an activity that is assigned the ‘from’ role; the role that sends the first business message, e.g. a request; the Requesting role in the Business Transaction)

Inner collaboration

A Business Collaboration that is part of a Collaboration Activity that is initiated by another Business Collaboration; it cannot be initiated by itself


Governs flow of transactions within Business Collaboration, limits or allows the ability to execute more than one instance of the same Business Transaction within a Collaboration Activity


Message has passed a structure/schema validity check prior to the processing of the Business Document or Document Envelope; this is separate from and in addition to a Receipt Acknowledgement

Message Service Interface

Set of messages (technical) exchanged between partners, and the interface defined rules governing the sequencing and processing used to support a business process

Multiparty Collaboration

A set of Business Activities that involves more than two abstract partners or top-level roles


Authentication that with high assurance can be asserted to be genuine, and that can not subsequently be refuted


A response that indicates receiving party has reached a satisfactory state (for example, an AcceptanceAcknowledgement signal)


A Business Transaction based on the Notification pattern that involves a defined business message that is sent when an event that could reasonably be anticipated occurs and informs the other party, such an Advance Ship Notice or Order Status




Notification of Failure

A Business Transaction based on the Notification pattern that involves a defined business message that is sent when an unwanted event that could reasonably be anticipated occurs, such as a party cannot determine if a contract has been formed

Operation Mapping

Specifies the mapping of a BTA to a set of web service operation invocations that enable the participation of non-ebXML capable business partner in an ebXML relationship

Operational view

A perspective that shows the elements and obligations made by the parties to form a Business Activity


Mechanism for organizing elements into groups, and defining their namespace


Used when relating to a role that a business partner plays


A pattern 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 predictable classes of Business Transaction definitions


Used to assign roles that a party assumes such as in a Business Collaboration that involves more than two parties where the Performs binds the referring and referred to roles, i.e. those assumed and used by the one of the parties




Persistent authentication

Authentication of Business Document is verified at receiving application level

Persistent confidentiality

Decryption occurs after Business Document is received at message node only by authorized application

Protocol exception

Indicates whether processing of the Business Transaction failed at either the Requesting or Responding role

Receipt Acknowledgement

Business signal that is defined as required or optional in a Business Transaction pattern; signals that message has been successfully and properly received

Receipt Acknowledgement exception

Signals an error condition in a Business Activity which requires a transaction to be terminated, i.e. receipt of a business message with a Business Document that has failed

Reliable messaging service

Provides guaranteed message delivery at transport level

Requesting Business Activity

A required component of a Business Transaction that is sent by the Requesting role as a Document Envelope; performed by the partner in a role that is requesting business service from another business partner in a role. The Requesting  Business Activity binds the roles to the associated business action

Requesting role

A top-level or abstract partner role; the partner that initiates and concludes a Business Transaction (initiating role)

Request Document Flow

Contains Business Document that relates to Business Transaction request

Responding Business Activity

Is a component of a Business Transaction. It is performed by a partner in the role that is responding to a request for a business service. The Responding Business Activity binds the roles to the associated business action and may or may not include a Document Envelope (and Business Document)

Response Document Flow

Contains Business Document that relates to Business Transaction response

Responding role

A top-level or abstract partner role in an activity which is assigned the ‘to’ role (i.e. for receiving or responding)


A function played by a business partner in a specific state of the Business Collaboration

Semantic process

Actual business process

Service choreography

Systems implementation of business processes

State alignment

When a Business Collaboration instance and its state are identical for the involved parties

State synchronization

Alignment of business states between the parties when the resources shared by the enterprise systems are limited

Status visibility

An element of a Complex Business Transaction Activity to allow state visibility (possibly for monitoring) of an activity by its parent




Substantive business message

Response that includes a Business Document

Substitution set

Supports the capability to take a generic business process document or attribute, and specialize it for a domain use


Time value has been exceeded for an activity; allows for the definition of a mechanism to allow sender who has not received an acknowledgement in the prescribed time to resend or terminate the Business Transaction as defined by the parties


Element that specifies value that is a time interval within which activities are expected to occur; typically these are from the Requester’s perspective


Passage from one state to another, re: linking construct


Are named information elements that are available to bind concepts across Business Transaction; allow abstract semantic elements used in conditional statements as well as external specifications to link to Business Document contents

Well-formedness rules

Aids to implementers in using specific constructs in addition to implementers’ notes


Appendix F:  Acknowledgements

The following individuals were committee members or observers, and participants on ebxml-dev or interested community experts, during the development of this set of specification packages including the technical specification and schemas as well as the non-normative examples package (external to the packages submitted).  Note, their status may have changed during the course of this specification development.

·         Yano Keisuke, Fujitsu, JEITA, yano@jp.fujitsu.com

·         Martin Roberts, BT Exact, martin.me.roberts@bt.com

·         Anders Tell, Collaborative Toolsmiths, anderst@toolsmiths.se

·         Serm Kulvatunyou, National Institute of Standards and Technology (NIST) [observer], serm@nist.gov

·         J. Dean E. P. Hemopo, (user community, ebxml-dev), jdeanh@ihug.co.nz

·         Jesmond Abela, Individual (observer), jesmonda@maltanet.net

·         Lars Abrell, Telisonera (observer), lars.abrell@teliasonera.com

·         Kenji Nagahashi, Fujitsu (Member), nagahashi@fla.fujitsu.com

·         Steve Capell, Red Wahoo, steve.capell@redwahoo.com

·         Layna Fischer, formerly of WfMC

·         Dale Moberg, Cyclone Commerce/Axway (co-chair), dmoberg@us.axway.com

·         John Yunker, Amazon, yunker@amazon.com

·         Sally St. Amand, Individual, editor, sallystamand@yahoo.com

·         John Jacques-Dubray, previous editor, jdubray@gmail.com

·         David Webber, Individual,  david@drrw.info

·         Ed Buchinski (user community), Government of Canada, buchinski.ed@tbs-sct.gc.ca

·         Sacha Schlegel, Member, sacha@schlegel.li

·         Cristiano Novelli (user community), Member, cristiano.novelli@bologna.enea.it

·         Stephen Green (user community), formerly with OASIS UBL TC, stephengreenubl@gmail.com

·         Bryan Rasmussen (user community), xml-dev, brs@itst.dk

·         Matthew Arrott (user community interested party), TWIST, marrott@novgp.com

·         Dr. Asuman Dogac (user community and Member), METU, (Middle East Technical University), asuman@srdc.metu.edu.tr

Special thanks are extended to Martin Roberts for his early work on the XML schema, to Dean Hemopo, Hima Mukkamala, Dale Moberg, Yano Keisuke, Cristiano Novelli, Stephen Green, Bryan Rasmussen and Kenji Nagahashi who contributed to the exemplary illustrations or examples, schema representations and business scenarios or use cases, to Jean-Jacques Dubray for his long-term support for development of this specification, and to Sally St. Amand for the glossary. As always, all TC members, observers, and outside user communities actively been instrumental to this work and to a successful result.

Appendix G:  Revision History

Version 2.0.4



By Whom


cs (diff01) candidate


Monica J. Martin

Documents with tracked changes that integrate non-substantive changes primarily related to the approval of the Committee Draft Errata, v2.0.4 for v2.0.3 Committee Specification.



Monica J. Martin

Approved v2.0.4 Committee Specification



Monica J. Martin

Approved v2.0.4 OASIS Standard

Version 2.0.3



By Whom


wd-2.0.3-diff01, r01


Monica J. Martin

This Working Draft integrates resolutions for 15-day Public Review comments to v2.0.2 Committee Draft in order to advance to Committee Draft v2.0.3 and anticipated Committee Specification.



Monica J. Martin

Approved Committee Draft and to initiate Committee Specification vote 24 March 2006.



Monica J. Martin

Approved Committee Specification in unanimous quorate vote.


Version 2.0.2



By Whom




Monica J. Martin

Promoted Public Review Draft v2.0.1 with changes from working drafts to Committee Draft v2.0.2. [1]

[1] r01-r04: These were working drafts used to integrate comments and resolutions iteratively throughout 60-day Public Review period.

Version 2.0.1



By Whom




Monica J. Martin

2.0.1 Committee Draft update with comments received since 21 April 2005 approval. Tracked changes visible for team review



Monica J. Martin

Updated comments re: Responses, editorial corrections and OASIS specification of naming guidelines



Monica J. Martin

Clarification on versioning for namespace and file names after further OASIS and TC feedback. Correction to signal schema and XML instance (reflect name changes and correction of syntax error for signal schema).



Monica J. Martin

Update to OASIS naming guidelines and miscellaneous editorial cleanup.



Monica J. Martin

Integrated proposal for Responding Business Activity. Any editorial/typographical errors detected by TC team.



Monica J. Martin

Integrated changes proposed and accepted by TC team on Performs and declared roles on a BT. Any editorial/typographical errors detected by TC team including consistency of terminology and context throughout the technical specification


Committee Draft Candidate for vote


Monica J. Martin

Resolved editor questions on timing parameters and any case inconsistencies. Resolve any reference inconsistencies in schemas.



Monica J. Martin

Promotion to Committee Draft after successful ebXML Business Process TC voting member vote. The TC also voted to promote the CD to Public Review status 2 August 2005.

Version 2.0.1 (continued)




By Whom



(commented copy)


Monica J. Martin

Integrated changes as a result of 60-day public review that ended 15 October 2005.


(commented copy that includes redlines for diff01 and diff02). Changes accepted r02.


Monica J. Martin

Integrated minor composability editorial changes to Sections 2.3, 2.4 and 3.  Part of 60-day public review comments and from TC members. Updated BPMN diagrams reflecting BPMN team comments and suggestions.


(Changes accepted r03)


Monica J. Martin

Final changes on OASIS template, BPMN diagram updates, and descriptive changes from public review comments.


(Changes accepted r04)


Monica J. Martin

Updated text proposed and accepted on Appendix D for recursion and optionality by ebBP Team 10 January 20006. This is the PR Candidate to accept Public Review Comments from 60-day review.


Version 2.0



By Whom




Jean-Jacques Dubray

Initial working draft. Editors distribution



Monica J. Martin

Edited changes related to editors’ F2F inputs. Team distribution



Monica J. Martin

Edited changes on completion evaluation to v2.0 work item list. Team distribution



Monica J. Martin

Edited changes related to informal review from OASIS ebXML BP TC. Apply OASIS specification template. Team distribution



Monica J. Martin

Integrated comments from TC members received. Integrated TC decisions on CPA v2.1 alignment and OperationMapping.



Monica J. Martin

Integrated comments from TC members received through week of 27 January 2005. Integrated BT patterns matrices updates.



Jean-Jacques Dubray, Monica J. Martin

Added figure changes, added operational semantic matrices for BT patterns. Resolution on work item progress from last 2 weeks.



Jean-Jacques Dubray, Monica J. Martin

Added resolutions on work item progress and public comments from last week.



Jean-Jacques Dubray, Monica J. Martin

Added resolutions on work item progress and public comments from last week. Integrated changed related to open comments in the technical specification and schema changes.



Monica J. Martin

Integrated agreed comment changes 22 Feb 2005 teleconference call. General cleanup and OASIS guideline revisions.



Monica J. Martin

Added comments agreed by the team for schema and technical specification including user community comments (pattern name, error propagation, conversations, etc). Included comments from European and Canadian eGovernment inputs, experts involved with RosettaNet and others.



Monica J. Martin

Committee Draft Candidate

Unanimously approved as Committee Draft/Specification 21 April 2005.





[1] The preceding Organization for the Advancement of Structured Information Standards (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 and new TC processes.

[2] www.sun.com, Sun Microsystems.