EbXML Business Process Specification Schema (BPSS)

The main concepts of ebXML BPSS are business collaboration (binary and multiparty), business transactions, business document flows, and choreography.

You use the ebXML BPSS specific toolbox to create Business Transactions and Business Collaborations in a BPM:

Tool	Description
...	Business Transaction - Creates a default composite process bearing a Business Transaction stereotype, with a sub-process in composite view mode. Each of the various BT tools creates a Business Transaction process with distinct flows between the requesting and the responding activities. In the ebXML toolbox, reading from left to right, tools are available to create: A simple requesting flow A requesting flow with a responding flow A requesting flow, responding flow, and a receipt acknowledgment for the requesting flow A requesting flow, responding flow, and receipt and acceptance acknowledgmentsfor the requesting flow A requesting flow, responding flow, receipt and acceptance acknowledgments for the requesting flow, and a receipt acknowledgment for the responding flow For information about composite views, see Working with Composite Views.
	Binary Collaboration - Creates a default composite process bearing a Binary Collaboration stereotype with a sub-process in composite view mode, attaches two organization units as initiating and responding roles, and creates an initial choreography inside the Binary Collaboration process. You must complete the choreography by specifying a Business Transaction process for implementation.
	MultiParty Collaboration - Creates a default composite process with the following message <<you can only use shortcut of binary collaboration here>>:

Business Transaction

Each Business Transaction consists in one or two predefined Business document flows. A Business Transaction may be additionally supported by one or more Business Signals.

A Business Transaction is the atomic interaction (in a trading arrangement) between two business partners. One party plays the Requesting role, the other plays the Responding role. This interaction always results in one Business Document Flow from the requesting role to the responding role and possibly one or more Business Document Flow in the inverse sense. A Business Transaction may be additionally supported by one or more Business Signals.

Like the Binary Collaboration, a Business Transaction is a reuseable protocol between two roles. The protocol is reused by referencing it from a Binary Collaboration, through the use of a Business Transaction Activity. In a Business Transaction Activity the roles of the Binary Collaboration are assigned to the execution of the Business Transaction.

A Business Transaction can either succeed or fail:

If it succeeds, it may be designated as legally binding between the two partners, otherwise it governs their collaborative activity.
If it fails, it is null and void, and each partner must relinquish any mutual claim established by the transaction.

Business Collaboration

A Business Collaboration consists in a set of roles that interact through Business Transactions by exchanging Business Documents.

Business Collaboration can either be a:

Binary Collaboration between two roles only
MultiParty Collaboration between more than two roles, but such MultiParty Collaborations are always a synthesis from two or more Binary Collaborations

Binary Collaborations are expressed as a set of Business Activities, which can consist in conducting a Business Transaction (Business Transaction Activity) or another complete Binary Collaboration (Collaboration Activity). The business activities are sequenced in a choreography. Placing a purchase order or requesting a catalog can be an example of a Business Transaction Activity; negotiating a contract can be an example of a Collaboration Activity.

The ability of a Binary Collaboration to have activities that execute other Binary Collaborations is the key to recursive compositions of Binary Collaboration, and to the re-use of Binary Collaborations.

A Binary Collaboration must have exactly two associated roles (Initiating and Responding). To do so, you must define role associations in the top-level diagram.

Only one start is allowed in a Binary Collaboration. Its sub-processes must always be implemented by a Business Transaction process or a Binary Collaboration process. Decision objects are not allowed and the activities must be created using Alt+drag and drop.

MultiParty collaboration is a set of Binary Collaboration between business partners. Each partner plays one or more roles in the collaboration.

A MultiParty collaboration can only contain organization units with the icon representation and shortcuts of Binary Collaborations linked to each other using extended dependencies.

Business Document Flows

A business transaction is realized using Business Document flows between the requesting and responding roles. There is always a requesting Business Document, and optionally a responding Business Document, depending on the desired transaction semantics, e.g. one-way notification vs. two-way conversation. To do so, you must define a message format on the flow inside the Business Transaction. It is the only way to exchange data. You cannot define a message format on the flow inside a Binary Collaboration.

The actual document definition is achieved using the ebXML core component specifications, or by some methodology external to ebXML but resulting in a DTD or Schema that an ebXML Business Process Specification can point to. This schema is referenced with a message format object.

Choreography

The Business Transaction Choreography describes the ordering and transitions between business transactions or sub-collaborations within a binary collaboration. The choreography is described in the ebXML Business Process Specification Schema using activity diagram concepts such as start state, completion state, activities, synchronizations, transitions between activities, and guards on the transitions.