Business Process Execution Language

Encyclopedia : B : BU : BUS : Business Process Execution Language

In computing, Business Process Execution Language (or BPEL, pronounced 'bipple', or 'bee-pell'), is a business process language that grew out of WSFL and XLANG. 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.

Contents

1 Purpose
2 BPEL Design Goals
3 The BPEL language
4 What's new in WS-BPEL 2.0
5 Adding 'programming in the small' support to BPEL
6 History
7 See also
8 External links

8.1 Standards
8.2 BPEL and business process sites
8.3 BPEL articles

Purpose

Programming in the large generally refers to the high-level state transition interactions of a process—BPEL refers to this concept as an Abstract Process. A BPEL Abstract Process represents a set of publicly observable behaviors in a standardized fashion. An Abstract Process includes information such as when to wait for messages, when to send messages, when to compensate for failed transactions, etc. Programming in the small, in contrast, deals with short-lived programmatic behavior, often executed as a single transaction and involving access to local logic and resources such as files, databases, etc. BPEL's development came out of the notion that programming in the large and programming in the small required different types of language.

BPEL Design Goals

There were ten original design goals associated with BPEL:

Goal 1: Define business processes that interact with external entities through Web Service operations defined using WSDL 1.1, and that manifest themselves as Web services defined using WSDL 1.1. The interactions are “abstract” in the sense that the dependence is on portType definitions, not on port definitions.
Goal 2: Define business processes using an XML based language. Do not define a graphical representation of processes or provide any particular design methodology for processes.
Goal 3: Define a set of Web service orchestration concepts that are meant to be used by both the external (abstract) and internal (executable) views of a business process. Such a business process defines the behavior of a single autonomous entity, typically operating in interaction with other similar peer entities. It is recognized that each usage pattern (i.e. abstract view and executable view) will require a few specialized extensions, but these extensions are to be kept to a minimum and tested against requirements such as import/export and conformance checking that link the two usage patterns.
Goal 4: Provide both hierarchical and graph-like control regimes, and allow their use to be blended as seamlessly as possible. This should reduce the fragmentation of the process modeling space.
Goal 5: Provide data manipulation functions for the simple manipulation of data needed to define process data and control flow.
Goal 6: Support an identification mechanism for process instances that allows the definition of instance identifiers at the application message level. Instance identifiers should be defined by partners and may change.
Goal 7: Support the implicit creation and termination of process instances as the basic lifecycle mechanism. Advanced lifecycle operations such as "suspend" and "resume" may be added in future releases for enhanced lifecycle management.
Goal 8: Define a long-running transaction model that is based on proven techniques like compensation actions and scoping to support failure recovery for parts of long-running business processes.
Goal 9: Use Web Services as the model for process decomposition and assembly.
Goal 10: Build on Web services standards (approved and proposed) as much as possible in a composable and modular manner.

The BPEL language

BPEL is an orchestration language, not a choreography language. The primary difference between orchestration and choreography is scope. An orchestration model provides a larger scope, encompassing all parties and their associated interactions (e.g. a peer to peer model). A choreography model is between two participants (specifically focusing on the view of one participant).

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:

A property-based message correlation mechanism
XML and WSDL typed variables
An extensible language plug-in model to allow writing expressions and queries in multiple languages: BPEL supports Xpath 1.0 by default
Structured-programming constructs including if-then-elseif-else, while, sequence (to enable executing commands in order) and flow (to enable executing commands in parallel)
A scoping system to allow the encapsulation of logic with local variables, fault-handlers, compensation-handlers and event-handlers
Serialized scopes to control concurrent access to variables

What's new in WS-BPEL 2.0

New activity types (if-then-else, repeatUntil, validate, forEach, extensionActivity)
Completion condition in forEach activity
Variable initialization
XSLT for variable transformations (New XPath extension function bpws:doXslTransform)
XPath access to variable data (XPath variable syntax $variable[.part]/location)
XML schema variables in Web service activities (for WS-I doc/lit style service interactions)
Locally declared messageExchange (internal correlation of receive and reply activities)
Clarification of Abstract Processes (syntax and semantics)

Adding 'programming in the small' support to BPEL

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] is an effort related to [JSR 207] that may enable Java to function as a 'programming in the small' language within BPEL.

History

IBM and Microsoft had each defined their own, fairly similar, 'programming in the large' languages, WSFL and XLANG, respectively. 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]. Although BPEL4WS appeared as both a 1.0 and 1.1 version, the OASIS WS-BPEL technical committee [voted] on 14 September 2004 to name their spec WS-BPEL 2.0. This change in name and version number reflects the significant and in many cases incompatible differences between BPEL4WS 1.1 and WS-BPEL 2.0. If you are not discussing a specific version, “BPEL” is sufficient.

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. An informal [mapping] from BPMN to BPEL 1.1 is also available.

External links

Standards

BPEL and business process sites

BPEL articles

From Wikipedia, the Free Encyclopedia. Original article here. Support Wikipedia by contributing or donating.
All text is available under the terms of the GNU Free Documentation License See Wikipedia Copyrights for details.