Business Process Execution Language

Last updated

WS-BPEL
Web Services Business Process Execution Language
AbbreviationWS-BPEL or BPEL
StatusPublished
Year started2001 (2001)
First publishedApril 2003;20 years ago (2003-04)
Latest version 2.0
11 April 2007;16 years ago (2007-04-11)
Organization OASIS
CommitteeOASIS Web Services Business Process Execution Language (WSBPEL) TC
Base standards XML
DomainWeb service integration
Website docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.html

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.

Contents

Overview

One can describe Web-service interactions in two ways: as executable business processes and as abstract business processes.

  1. An executable business process: models an actual behavior of a participant in a business interaction.
  2. An abstract business process: is a partially specified process that is not intended to be executed. Contrary to Executable Processes, an Abstract Process may hide some of the required concrete operational details. Abstract Processes serve a descriptive role, with more than one possible use case, including observable behavior and/or process template.

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.

Programming in the large/small

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:

  1. 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.
  2. 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, et cetera.

History

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[ citation needed ].

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.[ citation needed ]

Topics

Design goals

There were ten original design goals associated with BPEL:

  1. Define business processes that interact with external entities through web service operations defined using Web Services Description Language (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.
  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. [9]
  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.
  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.
  5. Provide data manipulation functions for the simple manipulation of data needed to define process data and control flow.
  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.
  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.
  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.
  9. Use Web Services as the model for process decomposition and assembly.
  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, 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:

Relationship of BPEL to BPMN

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.[ citation needed ]

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

BPEL4People

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.

Objectives

Within the context of a business process BPEL4People

  • supports role-based interaction of people
  • provides means of assigning users to generic human roles
  • takes care to delegate ownership of a task to a person only
  • supports scenario as

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.

WS-BPEL 2.0

Version 2.0 introduced some changes and new features:

See also

Related Research Articles

A web service (WS) is either:

The Organization for the Advancement of Structured Information Standards is a nonprofit consortium that works on the development, convergence, and adoption of open standards for cybersecurity, blockchain, Internet of things (IoT), emergency management, cloud computing, legal data exchange, energy, content technologies, and other areas.

<span class="mw-page-title-main">Business Process Model and Notation</span> Graphical representation for specifying business processes

Business Process Model and Notation (BPMN) is a graphical representation for specifying business processes in a business process model.

<span class="mw-page-title-main">XPDL</span>

The XML Process Definition Language (XPDL) is a format standardized by the Workflow Management Coalition (WfMC) to interchange business process definitions between different workflow products, i.e. between different modeling tools and management suites. XPDL defines an XML schema for specifying the declarative part of workflow / business process.

YAWL is a workflow language based on workflow patterns. It is supported by a software system that includes an execution engine, a graphical editor and a worklist handler. It is available as open-source software under the LGPL license.

Business Process Modeling Language (BPML) is an XML-based language for business process modeling. It was maintained by the Business Process Management Initiative (BPMI) until June 2005 when BPMI and Object Management Group announced the merger of their respective business process management activities to form the Business Modeling and Integration Domain Task Force. It is deprecated since 2008. BPML was useful to OMG in order to enrich UML with process notation.

OpenESB is a Java-based open-source enterprise service bus. It can be used as a platform for both enterprise application integration and service-oriented architecture. OpenESB allows developers to integrate legacy systems, external and internal partners and new development in business processes. It supports a multitude of integration technologies including standard JBI, XML with support for XML Schemas, WSDL, and BPEL with the aim of simplicity, efficiency, long-term durability, and low TCO.

The Business Process Definition Metamodel (BPDM) is a standard definition of concepts used to express business process models, adopted by the OMG. Metamodels define concepts, relationships, and semantics for exchange of user models between different modeling tools. The exchange format is defined by XSD and XMI, a specification for transformation of OMG metamodels to XML. Pursuant to the OMG's policies, the metamodel is the result of an open process involving submissions by member organizations, following a Request for Proposal (RFP) issued in 2003. BPDM was adopted in initial form in July 2007, and finalized in July 2008.

Workflow Management Coalition (WfMC) was a consortium formed to define standards for the interoperability of workflow management systems. The coalition was disbanded in 2019 and no longer exists.

A workflow management system provides an infrastructure for the set-up, performance and monitoring of a defined sequence of tasks, arranged as a workflow application.

<span class="mw-page-title-main">Apache ODE</span>

Apache ODE is a software coded in Java as a workflow engine to manage business processes which have been expressed in the Web Services Business Process Execution Language (WS-BPEL) via a website. It was made by the Apache Software Foundation and released in a stable format on March 23, 2018. The software principally communicates with one or more Web services, sending and receiving messages, manipulating data and handling exceptions (errors) as defined by any given process. The engine is capable of running both long and short living processes to coordinate all the services that make up a service or application (orchestration).

BPELscript is a language to specify BPEL processes. It provides a compact syntax inspired by scripting languages such as JavaScript and Ruby and a full coverage of all features provided by BPEL.

Service choreography in business computing is a form of service composition in which the interaction protocol between several partner services is defined from a global perspective. The idea underlying the notion of service choreography can be summarised as follows:

"Dancers dance following a global scenario without a single point of control"

Web Services Flow Language 1.0 (WSFL) was an XML programming language proposed by IBM in 2001 for describing Web services compositions. Language considered two types of compositions. The first type was for describing business processes as a collection of web services and the second was for describing interactions between partners. WSFL was proposed to be layered on top of Web Services Description Language.

<span class="mw-page-title-main">Enterprise Architect (software)</span> Visual modeling and design tool

Sparx Systems Enterprise Architect is a visual modeling and design tool based on the OMG UML. The platform supports: the design and construction of software systems; modeling business processes; and modeling industry based domains. It is used by businesses and organizations to not only model the architecture of their systems, but to process the implementation of these models across the full application development life-cycle.

Imixs Workflow is an Open-Source-Project, providing technologies for building Business Process Management solutions. The project focus on human based workflows used to execute and control workflows in organisations and enterprises. In difference to task-oriented workflow engines, which focus on automated program flow control (tasks), Imixs Workflow is a representative of an event-based workflow engine. Here, the engine controls the status of a process instance within a defined state-diagram. By entering an event, the state of a process instance can be abandoned or changed. In human-centric workflow engines, events usually occur by an interaction of the actor with the system, for example by approving or rejecting a business transaction. They can also be triggered by scheduled events. An example of this is an escalation of an unfinished task.

<span class="mw-page-title-main">Frank Leymann</span> German computer scientist and mathematician

Frank Leymann is a German computer scientist and mathematician. He is professor of computer science at the University of Stuttgart, Germany, and director and founder of the Institute of Architecture of Application Systems (IAAS).

References

  1. ↑ OASIS Standard WS-BPEL 2.0
  2. ↑ Business Process Execution Language for Web Services, Version 1.1 Archived 3 December 2020 at the Wayback Machine (5 May 2003)
  3. ↑ "OASIS Members Form Web Services Business Process Execution Language (WSBPEL) Technical Committee". OASIS WSBPEL Technical Committee. 29 April 2003.
  4. ↑ "Cover Pages: Web Services Flow Language (WSFL)". xml.coverpages.org/. 6 June 2001. Retrieved 9 October 2014.
  5. ↑ "XLANG". xml.coverpages.org/. 2001. Retrieved 9 October 2014.
  6. ↑ "XLANG/s Language". Microsoft. Retrieved 9 October 2014.
  7. ↑ Web Services BPEL Technical Committee.
  8. ↑ "choreology.com". choreology.com. Archived from the original on 27 February 2012. Retrieved 17 April 2013.
  9. ↑ Chinosi, Michele (1 January 2009). "Representing business processes: conceptual model and design methodology".{{cite journal}}: Cite journal requires |journal= (help)
  10. ↑ "Archived copy" (PDF). Archived from the original (PDF) on 15 September 2012. Retrieved 17 April 2013.{{cite web}}: CS1 maint: archived copy as title (link)
  11. ↑ BPMN2BPEL.
  12. ↑ BPELJ Archived 16 May 2005 at the Wayback Machine
  13. ↑ JSR 207

Further reading

Books on BPEL 2.0
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.