ebXML (Electronic Business XML) is a framework that provides a set of technologies, BPSS (Business Process Specification Schema) being one of them. ebXML has been developed under the initiative of OASIS and UN/CEFACT and consists of the following technologies:

BPSS covers the same domain as BPEL. The BPSS approach to the process specification follows the choreography pattern and is therefore comparable to abstract BPEL processes. In addition to specifying the process logic, BPSS also specifies the communication protocol details.

BPSS is designed around the concept of business transactions, which is, however, not fully conformant with the Web Services Transactions specifications. A BPSS business transaction is used to describe message exchange between two abstract roles: the sender and the responder. Each message consists of an XML document and optional attachments, which can be XML or binary. For each responding message, we specify whether it is a positive or negative message. Each message is associated with a business transaction protocol. Collaboration in BPSS can be bilateral or multi-party and is described by the business transaction protocol.

We can see that BPSS is not a direct alternative to BPEL and is used in environments where ebXML is applied. For more information on ebXML, read the following books:

BPML (Business Process Markup Language) has been developed by BPMI.org (Business Process Management Initiative). Intalio has played an important role, and has been the initiator of BPML. BPML is a meta-language for modeling business processes and provides an abstract execution model for describing collaborations and transactions. It defines a formal model for expressing abstract and executable processes, and supports:

BPML can describe a process in a specific language, defined on top of the extensible BPML scheme. Business processes are defined as groups of flows (control flows, data flows, and event flows). Formatting features, security rules, and transactional contexts can also be defined. BPML offers support for synchronous and asynchronous distributed transactions and can be used for process components of existing applications.

Comparing BPML to BPEL shows that both share similar roots in web services and leverage other web services specifications, particularly WS-Security, WS-Coordination, and WS-Transactions. BPML, however, supports modeling more complex business processes through its support for advanced semantics such as nested processes and complex compensated transactions. BPML can therefore be regarded as a superset of BPEL. The extensions of BPEL with business rules, task management, human interactions, etc. are defined in BPXL (Business Process Extension Layers). The fact that both BPEL and BPML share the same idioms and have similar syntax can be a basis for possible future convergence. This is interesting because BPMI.org provides solutions for analysis and design of business processes (Business Process Modeling Notation—BPMN), a semantic model (Business Process Semantic Model—BPSM), and a query language (Business Process Query Language—BPQL). Find out more at http://www.bpmi.org/.

WSCI (Web Services Choreography Interface) version 1.0 has been developed by Sun, BEA, SAP, and Intalio. WSCI is a language for describing flows of messages exchanged by web services in the context of a process. It allows us to describe the observable behavior of a web service in a message exchange. WSCI also describes the collective message exchange among interacting web services, providing a global and message-oriented view of a process involving multiple web services.

In WSCI, message exchange is described from the viewpoint of each web service. Each exchange can be qualified by message correlations, transactions descriptions, and location capabilities. WSCI therefore describes the observable behavior of web services. However, WSCI does not address the definition of the processes driving the message exchange. It also does not address the definition of the internal behavior of each web service.

Since WSCI follows the choreography pattern and does not address defining executable business processes, it compares directly only to BPEL abstract processes. WSCI has a cleaner interface, which makes it a little easier to learn than BPEL. The WSCI specification has also been submitted to W3C, which has published it as a W3C Note. Further, W3C has formed a WS-Choreography working group, which will address the choreography of web services, but has only released the requirements specification so far.

WSCI has not gained industry support comparable to BPEL and the only company that has provided support in tools is Sun with the SunONE WSCI Editor. The industry consensus seems to support BPEL. The WSCI specification is accessible at http://www.w3.org/TR/wsci/.

WS-CDL is a language for specifying the choreography of collaborating services. It targets the composition of interoperable collaborations between services. With WS-CDL we can specify peer-to-peer collaboration of web services through the definition of their observable behavior. We can define sets of rules that define how and in what order different services should act together. Such specification provides a flexible systemic view of the process.

Its authors position WS-CDL as a complementary language to BPEL (and other business process languages). While BPEL focuses on behavior specification of a specific business partner, WS-CDL focuses on the description of message interchanges between business partners. WS-CDL provides the global model needed by BPEL processes to ensure that the behavior of endpoints is consistent across all cooperating services.

A business partner can use the WS-CDL choreography specification to verify if their internal processes have their outside behavior defined in a way that will allow them to participate in choreography. WS-CDL choreography specifications can be used to generate public interfaces, for example, specified using BPEL abstract processes. WS-CDL specifications are also useful at run time to verify the execution of message exchange between business partners.

As WS-CDL is a complementary language to BPEL we cannot make a direct comparison. However, WS-CDL differs considerably from BPEL. With WS-CDL we define the message flows exchanged by all partners, while with BPEL we focus on message flow and the behavior of a specific partner—that is on the internal behavior of a business process. The WS-CDL description of message flows is done from a general perspective, while BPEL specifies message exchange from the point of view of a specific partner. A BPEL process specifies activities that are executed. WS-CDL specifies reactive rules, which are used by all participants of a collaboration.

At the time of writing WS-CDL has been under development and has been published as a W3C Working Draft. This is why WS-CDL has not yet gained wide industry support. It is also difficult to predict how important the role of WS-CDL will be in the future. The WS-CDL specification is accessible at http://www.w3.org/TR/ws-cdl-10/.