| WS-BPEL | |
| Long Name: | Web Services Business Process Execution Language |
| Status: | Published |
| Version: | 2.0 |
| Organization: | OASIS |
| Committee: | OASIS Web Services Business Process Execution Language (WSBPEL) TC |
| Base Standards: | XML |
| Abbreviation: | WS-BPEL or BPEL |
| Domain: | Web service integration |
The Web Services Business Process Execution Language (WS-BPEL), commonly known as BPEL (Business Process Execution Language), is an OASIS[1] standard executable language for specifying actions within business processes with web services. Processes in BPEL export and import information by using web service interfaces exclusively.
One can describe Web-service interactions in two ways: as executable business processes and as abstract business processes.
WS-BPEL aims to model the behavior of processes,[2] via a language for the specification of both Executable and Abstract Business Processes. By doing so, it extends the Web Services interaction model and enables it to support business transactions. It also defines an interoperable integration model that should facilitate the expansion of automated process integration both within and between businesses. Its development came out of the notion[3] that programming in the large and programming in the small required different types of languages.
As such, it is serialized in XML and aims to enable programming in the large.
The concepts of programming in the large and programming in the small distinguish between two aspects of writing the type of long-running asynchronous processes that one typically sees in business processes:
The origins of WS-BPEL go back to Web Services Flow Language (WSFL) and Xlang.
In 2001, IBM and Microsoft had each defined their own fairly similar, "programming in the large" languages: WSFL[4] (Web Services Flow Language) and Xlang,[5] respectively. Microsoft even went ahead and created a scripting variant called XLANG/s which would later serve as the basis for their Orchestrations services inside their BizTalk Server. They specifically documented that this language "is proprietary and is not fully documented."[6]
With the advent and popularity of BPML, and the growing success of BPMI.org and the open BPMS movement led by JBoss and Intalio Inc., IBM and Microsoft decided to combine these languages into a new language, BPEL4WS. In April 2003, BEA Systems, IBM, Microsoft, SAP, and Siebel Systems submitted BPEL4WS 1.1 to OASIS for standardization via the Web Services BPEL Technical Committee.[7] Although BPEL4WS appeared as both a 1.0 and 1.1 version, the OASIS WS-BPEL technical committee voted[8] on 14 September 2004 to name their spec "WS-BPEL 2.0". (This change in name aligned BPEL with other web service standard naming conventions which start with "WS-" (similar to WS-Security) and took account of the significant enhancements made between BPEL4WS 1.1 and WS-BPEL 2.0.) If not discussing a specific version, the moniker BPEL is commonly used.
In June 2007, Active Endpoints, Adobe Systems, BEA, IBM, Oracle, and SAP published the BPEL4People and WS-HumanTask specifications, which describe how human interaction in BPEL processes can be implemented.
There were ten original design goals associated with BPEL:
BPEL is an orchestration language, and not a choreography language. The primary difference between orchestration and choreography is executability and control. An orchestration specifies an executable process that involves message exchanges with other systems, such that the message exchange sequences are controlled by the orchestration designer. A choreography specifies a protocol for peer-to-peer interactions, defining, e.g., the legal sequences of messages exchanged with the purpose of guaranteeing interoperability. Such a protocol is not directly executable, as it allows many different realizations (processes that comply with it). A choreography can be realized by writing an orchestration (e.g., in the form of a BPEL process) for each peer involved in it. The orchestration and the choreography distinctions are based on analogies: orchestration refers to the central control (by the conductor) of the behavior of a distributed system (the orchestra consisting of many players), while choreography refers to a distributed system (the dancing team) which operates according to rules (the choreography) but without centralized control.
BPEL's focus on modern business processes, plus the histories of WSFL and XLANG, led BPEL to adopt web services as its external communication mechanism. Thus BPEL's messaging facilities depend on the use of the Web Services Description Language (WSDL) 1.1 to describe outgoing and incoming messages.
In addition to providing facilities to enable sending and receiving messages, the BPEL programming language also supports:
There is no standard graphical notation for WS-BPEL, as the OASIS technical committee decided this was out of scope. Some vendors have invented their own notations. These notations take advantage of the fact that most constructs in BPEL are block-structured (e.g., sequence, while, pick, scope, etcetera.) This feature enables a direct visual representation of BPEL process descriptions in the form of structograms, in a style reminiscent of a Nassi–Shneiderman diagram.
Others have proposed to use a substantially different business process modeling language, namely Business Process Model and Notation (BPMN), as a graphical front-end to capture BPEL process descriptions. As an illustration of the feasibility of this approach, the BPMN specification includes an informal and partial mapping[10] from BPMN to BPEL 1.1. A more detailed mapping of BPMN to BPEL has been implemented in a number of tools, including an open-source tool known as BPMN2BPEL.[11] However, the development of these tools has exposed fundamental differences between BPMN and BPEL, which make it very difficult, and in some cases impossible, to generate human-readable BPEL code from BPMN models. Even more difficult is the problem of BPMN-to-BPEL round-trip engineering: generating BPEL code from BPMN diagrams and maintaining the original BPMN model and the generated BPEL code synchronized, in the sense that any modification to one is propagated to the other.
BPEL's control structures such as 'if-then-elseif-else' and 'while' as well as its variable manipulation facilities depend on the use of 'programming in the small' languages to provide logic. All BPEL implementations must support XPath 1.0 as a default language. But the design of BPEL envisages extensibility so that systems builders can use other languages as well. BPELJ[12] is an effort related to JSR 207[13] that may enable Java to function as a 'programming in the small' language within BPEL.
Despite wide acceptance of Web services in distributed business applications, the absence of human interactions was a significant gap for many real-world business processes.
To fill this gap, BPEL4People extended BPEL from orchestration of Web services alone to orchestration of role-based human activities as well.
Within the context of a business process BPEL4People
by extending BPEL with additional independent syntax and semantic.
The WS-HumanTask specification introduces the definition of human tasks and notifications, 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.
The BPEL4People specification introduces a WS-BPEL extension to address human interactions in WS-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.
Version 2.0 introduced some changes and new features: