Section 9.2. ebXML BPSS: Collaboration

9.2. ebXML BPSS: Collaboration

The concepts of choreography and orchestration, discussed in previous chapters, pertain to the management of inter- and intraprocess flow, respectively. The pervasive business-to-business (B2B) ecommerce concept of collaboration , whose name, like those of choreography and orchestration, conveys a sense of coordinating individual entities, has a subtly different meaning. The leading model for collaboration is found in the OASIS group's specification of the Business Process Specification Schema (BPSS),^[*] an XML language that is part of the larger electronic business XML (ebXML) B2B system.

^[*] UN/CEFACT, ebXML Business Process Specification Schema, Version 1.09, August 2003, http://xml.coverpages.org/UN-CEFACT-BPSS-V1pt09-DRAFT.pdf.

The key elements of BPSS are the following:

Business transaction

A business transaction is an exchange of data between two partners that is treated as an atomic unit of work; if it fails at any point, both partners agree that exchange is null and void. A business transaction has a requesting and a responding activity and optional signals (acknowledgment messages).

Binary collaboration

A binary collaboration is an exchange between two authorized partners, each of which performs a role (e.g., buyer and seller): one is the initiating role; the other is the responding role. The collaboration consists of a set of activities, each of which can be either a business transaction or another binary collaboration .

Multiparty collaboration

A multiparty collaboration is an exchange between more than two partners, though it is defined in terms of a set of binary collaborations. For example, in the exchange between customer, retailer, and vendor, there are two binary collaborations: one in which the customer is the buyer and the retailer the seller, the other in which the retailer is the buyer and the vendor is the seller.

Choreography

Choreography is the explicit control of flow among activities of a binary collaboration; specifically, control of the start and completion states, forks, synchronization , and transitions.

The structure of a business transaction is depicted in Figure 9-6. One partner sends a request to a second, to which the second partner eventually responds; in between are acknowledgments of receipt and acceptance. In some cases, response or acknowledgement messages are not required. A time limit can be placed on a message (e.g., the response must arrive within five business days from receipt of the request), as well as the legal requirement for nonrepudiation (that is, acknowledgment of receipt).

A binary collaboration, shown in Figure 9-7, is a set of business transactions (e.g., create order and notify shipment) performed by two partner roles (e.g., buyer and seller). The dotted arrows show the direction of message interaction (e.g., buyer initiates a create order; seller initiates a notify shipment).

The choreography of that collaboration is shown in Figure 9-8. The create order business transaction is the first transaction, and it is followed by notify shipment, which is the last transaction.

Figure 9-6. A BPSS business transaction

Figure 9-7. A BPSS binary collaboration

Figure 9-8. A BPSS choreography of a binary collaboration

The difference between choreography and collaboration is this: collaboration is a set of precise, transactional message exchanges with legal and business trade ramifications, whereas choreography is higher-level control flow over the set of transactions. As for orchestration, it does not naturally fit the BPSS approach because that approach emphasizes the inter-partner view rather than a given partner's internal process. BPSS has more in common with WS-CDL, discussed in Chapter 8, than with current BPM languages such as BPEL and BPML.

Example 9-1 contains an excerpt of BPSS XML that represents the example choreographed collaboration, in which the declaration of the binary collaboration (starting at line 1) includes roles buyer and seller (lines 2-3) and the business transactions Create Order and Notify Shipment (lines 4-12), as well as the start state (line 13) and the two end states (lines 17-20: one for success, one for failure). The transition element (lines 14-16) connects Create Order to Notify Shipment.

Example 9-1. BPSS collaboration for order

 1    <BinaryCollaboration name="Product Fulfillment" timeToPerform="P5D"> 2       <InitiatingRole name="buyer"/> 3       <RespondingRole name="seller"/> 4       <BusinessTransactionActivity name="Create Order" 5          businessTransaction="Create Order" 6          fromAuthorizedRole="buyer" 7          toAuthorizedRole="seller"/> 8       <BusinessTransactionActivity 9          name="Notify shipment" 10          businessTransaction="Notify of advance shipment" 11          fromAuthorizedRole="seller" 12          toAuthorizedRole="buyer"/> 13       <Start toBusinessState="Create Order"/> 14       <Transition 15          fromBusinessState="Create Order" 16          toBusinessState="Notify shipment"/> 17       <Success fromBusinessState="Notify shipment" 18          conditionGuard="Success"/> 19       <Failure fromBusinessState="Notify shipment" 20          conditionGuard="BusinessFailure"/> 21    </BinaryCollaboration>