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.

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.

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:

Provide requirements to Message Service Interface.
Constrain implementation of the Message Service Interface.
Provide for auto generation of Message Service Interface.

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

Messages that map to Business Transactions
Signals that align state
Behavior upon receipt/non-receipt of messages and signals
Enforcements of security constraints

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:

BSI(s) implement business rules to either accept or not accept. That may be preferred to decouple from backend applications.
Develop the Message Service Interface able to look for internal events, generate messages and have collaborative engines to recognize those messages.
Have adapters look for those events, and drive creation of the messages by querying services from those systems.

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
ProcessSpecification/@uuid	ProcessSpecification/@uuid	Required
BusinessCollaboration/@name BinaryCollaboration/@name MultiPartyCollaboration/@name	//Service	Recommended (Note: only where @isInnerCollaboration is false)
BusinessCollaboration/Role/@name BinaryCollaboration/Role/@name MultiPartyCollaboration/Role/@name	CollaborationRole/Role/@name	Required
RequestingBusinessActivity/@name RespondingBusinessActivity/@name	ThisPartyActionBinding/@action	Recommended
RequestingBusinessActivity/@isNonRepudiationRequired RespondingBusinessActivity/@isNonRepudiationRequired	BusinessTransactionCharacteristics/@isNonRepudiationRequired	In ebBP: Specialization via restriction on each concrete BT pattern
RequestingBusinessActivity/@isNonRepudiationReceiptRequired RespondingBusinessActivity/@isNonRepudiationReceiptRequired	BusinessTransactionCharacteristics/@isNonRepudiationReceiptRequired	In ebBP: Specialization via restriction on each concrete BT pattern
DocumentEnvelope/@isConfidential Attachment/@isConfidential	BusinessTransactionCharacteristics/@isConfidential	On Attachment: At the time of this document, the CPP/CPA team is discussing this change and the updated mapping.
DocumentEnvelope/@isAuthenticated Attachment/@isAuthenticated	BusinessTransactionCharacteristics/@isAuthenticated	On Attachment: At the time of this document, the CPP/CPA team is discussing this change and the updated mapping.
DocumentEnvelope/@isTamperDetectable Attachment/@isTamperDetectable	BusinessTransactionCharacteristics/@isTamperProof	In ebBP: isTamperDetectable On Attachment: At the time of this document, the CPP/CPA team is discussing this change and the updated mapping.
RequestingBusinessActivity/@isAuthorizationRequired RespondingBusinessActivity/@isAuthorizationRequired	BusinessTransactionCharacteristics/@isAuthorizationRequired	In ebBP: Specialization via restriction on each concrete BT pattern
RequestingBusinessActivity/@isIntelligibleCheckRequired RespondingBusinessActivity/@isIntelligibleCheckRequired	BusinessTransactionCharacteristics/@isIntelligibleCheckRequired	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
RequestingBusinessActivity/@timetoAcknowledgeReceipt RespondingBusinessActivity/@timetoAcknowledgeReceipt	BusinessTransactionCharacteristics/@timetoAcknowledgeReceipt	In ebBP: Specialization via restriction on each concrete BT pattern
RequestingBusinessActivity/@timetoAcknowledgeAcceptance RespondingBusinessActivity/@timetoAcknowledgeAcceptance	BusinessTransactionCharacteristics/@timetoAcknowledgeAcceptance	In ebBP: Specialization via restriction on each concrete BT pattern
BinaryCollaboration/TimeToPerform MultipartyCollaboration/TimeToPerform BusinessCollaboration/TimeToPerform	BusinessTransactionCharacteristics/@timetoPerform	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.
RequestingBusinessActivity/@retryCount RespondingBusinessActivity/@retryCount	BusinessTransactionCharacteristics/@retryCount	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.

TERM	DEFINITION
(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
Atomicity	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.

TERM	DEFINITION
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
Choreography	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

TERM	DEFINITION
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
Guard	Governs incoming transitions; refers to status of an activity from which the transition originates
hasLegalIntent	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
isConcurrent	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
isIntelligibleCheckRequired	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
Non-repudiation	Authentication that with high assurance can be asserted to be genuine, and that can not subsequently be refuted
Non-substantive	A response that indicates receiving party has reached a satisfactory state (for example, an AcceptanceAcknowledgement signal)
Notification	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

TERM	DEFINITION
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
Package	Mechanism for organizing elements into groups, and defining their namespace
Party	Used when relating to a role that a business partner plays
Pattern	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
Performs	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

TERM	DEFINITION
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)
Role	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

TERM	DEFINITION
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
Timeout	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
TimeToPerform	Element that specifies value that is a time interval within which activities are expected to occur; typically these are from the Requester’s perspective
Transition	Passage from one state to another, re: linking construct
Variable	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

Rev	Date	By Whom	What
cs (diff01) candidate	2006-10-04	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.
cs	2006-10-13	Monica J. Martin	Approved v2.0.4 Committee Specification
os	2006-12-21	Monica J. Martin	Approved v2.0.4 OASIS Standard

Version 2.0.3

Rev	Date	By Whom	What
wd-2.0.3-diff01, r01	2006-03-08	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.
cd	2006-03-24	Monica J. Martin	Approved Committee Draft and to initiate Committee Specification vote 24 March 2006.
cs	2006-04-28	Monica J. Martin	Approved Committee Specification in unanimous quorate vote.

Version 2.0.2

Rev

Date

By Whom

What

2006-01-31

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

Rev	Date	By Whom	What
wd-2.0.1-01	2005-06-06	Monica J. Martin	2.0.1 Committee Draft update with comments received since 21 April 2005 approval. Tracked changes visible for team review
wd-2.0.1-02	2005-06-14	Monica J. Martin	Updated comments re: Responses, editorial corrections and OASIS specification of naming guidelines
wd-2.0.1-03	2005-06-20	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).
wd-2.0.1-04	2005-06-22	Monica J. Martin	Update to OASIS naming guidelines and miscellaneous editorial cleanup.
wd-2.0.1-05	2005-07-01	Monica J. Martin	Integrated proposal for Responding Business Activity. Any editorial/typographical errors detected by TC team.
wd-2.0.1-06	2005-07-13	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
wd-2.0.1-07 Committee Draft Candidate for vote	2005-07-21	Monica J. Martin	Resolved editor questions on timing parameters and any case inconsistencies. Resolve any reference inconsistencies in schemas.
cd	2005-07-21	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)

Rev	Date	By Whom	What
pr-2.0.1-diff01 (commented copy)	2005-11-14	Monica J. Martin	Integrated changes as a result of 60-day public review that ended 15 October 2005.
pr-2.0.1-diff02 (commented copy that includes redlines for diff01 and diff02). Changes accepted r02.	2005-11-21	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.
pr-2.0.1-diff03 (Changes accepted r03)	2006-01-02	Monica J. Martin	Final changes on OASIS template, BPMN diagram updates, and descriptive changes from public review comments.
pr-2.0.1-diff04 (Changes accepted r04)	2006-01-11	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

Rev	Date	By Whom	What
wd-01	2004-11-20	Jean-Jacques Dubray	Initial working draft. Editors distribution
wd-02	2004-12-06	Monica J. Martin	Edited changes related to editors’ F2F inputs. Team distribution
wd-03	2005-01-17	Monica J. Martin	Edited changes on completion evaluation to v2.0 work item list. Team distribution
wd-04	2005-01-25	Monica J. Martin	Edited changes related to informal review from OASIS ebXML BP TC. Apply OASIS specification template. Team distribution
wd-05	2005-01-26	Monica J. Martin	Integrated comments from TC members received. Integrated TC decisions on CPA v2.1 alignment and OperationMapping.
wd-06	2005-01-31	Monica J. Martin	Integrated comments from TC members received through week of 27 January 2005. Integrated BT patterns matrices updates.
wd-07	2005-02-08	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.
wd-08	2005-02-08	Jean-Jacques Dubray, Monica J. Martin	Added resolutions on work item progress and public comments from last week.
wd-09	2005-02-22	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.
wd-10	2005-02-23	Monica J. Martin	Integrated agreed comment changes 22 Feb 2005 teleconference call. General cleanup and OASIS guideline revisions.
wd-11	2005-04-05	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.
wd-12	2005-04-14	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.