Wiki Knowledgebase Outline

Browse, edit and add to the BPEL Wiki Knowledgebase.

Capabilities of BPEL

Edit or add pages to this section of the BPEL Wiki Knowledgbase.

Working with BPEL

Edit or add pages to this section of the BPEL Wiki Knowledgbase.

BPEL Community

Edit or add pages to this section of the BPEL Wiki Knowledgbase.

List of organizations using BPEL

BPEL is being deployed worldwide. If your organization uses BPEL, please add to this list. (Log in, select the "edit" tab above, and insert your organization in alphabetical order under the appropriate category below.).

See Case studies for detailed descriptions of representative implementations.

Private sector Public sector

Non-governmental organizations (NGOs)

Universities and Research Centers


BPEL Standardization

Edit or add pages to this section of the BPEL Wiki Knowledgbase.

About BPEL

The Web Services Business Process Execution Language (WS-BPEL) provides a language for formally describing business processes and business interaction protocols. WS-BPEL (pronounced 'bee-pell', 'bipple', or 'bepple') was designed to extend the Web Services interaction model to support business transactions.

WS-BPEL 2.0 was approved as an OASIS Standard in April 2007. It defines a model and a grammar for describing the behavior of a business process based on interactions between the process and its partners. The interaction with each partner occurs through Web services interfaces. The WS-BPEL process defines how multiple service interactions with these partners are coordinated to achieve a business goal, as well as the state and the logic necessary for this coordination.

What BPEL can do

Think of a WS-BPEL process as a reusable definition that can be deployed in different ways and in different scenarios, while maintaining a uniform application-level behavior across all of them. WS-BPEL introduces systematic mechanisms for dealing with business exceptions. This is essential because not all transactions are straightforward and simple. WS-BPEL lets you define how you want activities to be compensated in cases where exceptions occur or a partner requests reversal.

WS-BPEL separates the public aspects of business process behavior from internal or private aspects--and supports both. The standard can be used both for executable processes, which describe the actual behavior of participants in business interactions, and for abstract processes, that may be used to represent publicly observable behaviors. Abstract processes serve a descriptive role and allow for more than one possible use case.

By providing a language for specifying both executable and abstract business processes, BPEL extends the Web services interaction model to help better support business-to-business transactions. This protects business partners from the need to reveal all their internal decision making and data management to one another. Separating public from private processes also provides companies with the freedom to change confidential aspects of the process implementation without affecting the observable behavior.

Where BPEL fits

WS-BPEL leverages other Web services standards such as SOAP and WSDL for communication and interface description. By describing the inbound and outbound process interfaces in WSDL, BPEL enables them to be easily integrated into other processes or applications. In turn, this allows consumers of a process to inspect and invoke a BPEL process just like any other Web service, thereby inheriting all other aspects of a Web service such as quality of service policies.


See also:

- Frequently Asked Questions (FAQ)
- WS-BPEL 2.0 Primer
- BPEL4WS Design Goals





BPEL4People is now being advanced within the OASIS BPEL4People Technical Committee. It was originally published by Active Endpoints, Adobe, BEA, IBM, Oracle and SAP in June 2007 as two specifications:

  • BPEL4People version 1.0 introduces a BPEL extension to address human interactions in BPEL as a first-class citizen. It defines a new type of basic activity which uses human tasks as an implementation, and allows specifying tasks local to a process or use tasks defined outside of the process definition. This extension is based on the WS-HumanTask specification.

  • Web Services Human Task (WS-HumanTask) version 1.0 introduces the definition of human tasks, including their properties, behavior and a set of operations used to manipulate human tasks. A coordination protocol is introduced in order to control autonomy and life cycle of service-enabled human tasks in an interoperable manner.

WS-BPEL 2.0 Extensions

The following specifications have not yet been submitted into the open standards process:

  • BPEL-SPE (WS-BPEL 2.0 Extensions for Sub-Processes)
  • BPELJ (WS-BPEL 2.0 Extensions for Java)


  • BPEL4WS, which combines IBM's WSFL and Microsoft's XLANG, is the precursor to WS-BPEL 2.0. BPEL4WS was submitted to OASIS for standardization in April 2003.

Note on spec names/versions: Although BPEL4WS appeared as both a 1.0 and 1.1 version, the OASIS WS-BPEL Technical Committee voted to name their specification 'WS-BPEL 2.0.' This change in name was done to align BPEL with other Web services standard naming conventions which start with WS- and accounts for the significant enhancements between BPEL4WS 1.1 and WS-BPEL 2.0.


See also:

- BPEL4People — How People Interact with Business Processes by Ivana Trickovic

WS-BPEL 2.0 versus BPEL4WS 1.1

BPEL4WS 1.1 was contributed to the OASIS WS-BPEL Technical Committee, where it was advanced through an open process. The following list summarizes the major changes the Committee incorporated in WS-BPEL 2.0.

Data Access

  • Variables can be declared using XML schema complex types
  • XPath expressions are simplified by using the ‘$’ notation for variable access, for example, $myMsgVar.part1/po:poLine[@lineNo=3]
  • Access to WSDL messages has been simplified by mapping directly mapping WSDL message parts to XML schema element/type variables
  • Several clarifications have been added to the description of the <assign> activity’s <copy> semantics
  • The keepSrcElementName option has been added to <copy> in order to support XSD substitution groups or choices
  • The ignoreMissingFromData has been added to automatically some of <copy> operation, when the from data is missing.
  • An extension operation has been added to the <assign> activity
  • A standardized XSLT 1.0 function has been added to XPath expressions
  • The ability to validate XML data has been added, both as an option of the <assign> activity and as a new <validate> activity
  • Variable initialization as part the of variable declaration has been added

Scope Model

  • New scope snapshot semantics have been defined
  • Fault handling during compensation has been clarified
  • The interaction between scope isolation and control links have been clarified
  • Enrichment of fault catching model
  • A <rethrow> activity has been added to fault handlers
  • The <terminationHandler> has been added to scopes
  • The exitOnStandardFault option has been added to processes and scopes

Message Operations

  • The join option has been added to correlation sets in order to allow multiple participants to rendezvous at the same process with a deterministic order
  • Partner link can now be declared local to a scope
  • The initializePartnerRole option has been added to specify whether an endpoint reference must be bound to a partner link during deployment
  • The messageExchange construct has been added to pair up concurrent <receive> and <reply> activities

New Activities

  • Added serial and parallel <forEach> with optional completion condition
  • Added <repeatUntil>
  • Added new extension activity
  • Changed <switch> to <if>-<elseif>-<else>
  • Changed <terminate> to <exit>
  • Differentiate different cases of <compensate> by renaming them to <compensate> and <compensateScope>

Miscellaneous Changes

  • Added repeatEvery alarm feature to event handlers
  • Clarified resources resolution (e.g. variable, partner link) for event handlers
  • Added formal <documentation> support
  • Added extension namespace declarations in order to specify what extension must be understood
  • Add <import> support to import WSDL and XSD formally

Abstract Processes

  • Clarified Abstract Process usage patterns
  • Introduced Abstract Profiles to address different needs in Abstract Processes, and two profiles “Observable Behavior” and “Process Template” listed in the specification


See also:

- Design Goals of the BPEL4WS Specification


History of BPEL

The Business Process Execution Language for Web Services (BPEL4WS) was first conceived in July, 2002 with the release of the BPEL4WS 1.0 specification, a joint effort by IBM, Microsoft, and BEA. This document proposed an orchestration language inspired by previous variations, such as IBM’s Web Services Flow Language (WSFL) and Microsoft’s XLANG specification.

Joined by other contributors from SAP and Siebel Systems, version 1.1 of the BPEL4WS specification was released less than a year later, in May of 2003. This version received more attention and vendor support, leading to a number of commercially available BPEL4WS-compliant orchestration engines. Just prior to this release, the BPEL4WS specification was submitted to an OASIS technical committee so that the specification could be developed into an official, open standard.

The OASIS WS-BPEL Technical Committee was active from April 2003 to May 2007. It was co-chaired by Diane Jordan of IBM and John Evdemon of Microsoft. The Committee's email archives remain publicly accessible.

In April 2007, WS-BPEL version 2.0 was approved as an OASIS Standard. More than 37 organizations collaborated to develop WS-BPEL, including representatives of Active Endpoints, Adobe Systems, BEA Systems, Booz Allen Hamilton, EDS, HP, Hitachi, IBM, IONA, Microsoft, NEC, Nortel, Oracle, Red Hat, Rogue Wave, SAP, Sun Microsystems, TIBCO, webMethods, and other members of OASIS.

In January 2008, OASIS issued a Call for Participation in the BPEL4People Technical Committee. The group works to define a WS-BPEL extension enabling the definition of human interactions ("human tasks") as part of a WS-BPEL process.


See also:

- OASIS press release: 'Members Approve WS-BPEL 2.0 as OASIS Standard' April 2007
- OASIS press release: 'Members Form WS-BPEL Technical Committee' April 2003
- WS-BPEL 2.0 Primer


Related specifications

Edit or add pages to this section of the BPEL Wiki Knowledgbase.

Service Component Architecture (SCA)

The Service Component Architecture (SCA) is a set of specifications that describe a model for building applications and systems using a Service-Oriented Architecture (SOA). WS-BPEL processes can be used as SCA components.

The OASIS SCA/BPEL Technical Committee works to advance the SCA WS-BPEL Client and Implementation (BPEL C&I) model, which specifies how SCA component implementations for SOA can be written using BPEL.

SCA is based on the idea that business function is provided as a series of services, which are assembled together to create solutions that serve a particular business need. These composite applications can contain both new services created specifically for the application and also business function from existing systems and applications, reused as part of the composition. SCA provides a model both for the composition of services and for the creation of service components, including the reuse of existing application function within SCA compositions.

SCA is a model that aims to encompass a wide range of technologies for service components and for the access methods which are used to connect them. For components, this includes not only different programming languages, but also frameworks and environments commonly used with those languages. For access methods, SCA compositions allow for the use of various communication and service access technologies that are in common use, including, for example, Web services, messaging systems and Remote Procedure Call (RPC).


The Business Process Modeling Notation (BPMN) can be used as a graphical front-end to capture BPEL process descriptions. While a BPEL process can be represented using BPMN, some BPMN models cannot be represented using BPEL.