Understanding BPEL

The general adoption of business process automation solutions requires a standard foundation and a specialized language for composing services into business processes that provide the ability to express business processes in a standardized way, using a commonly accepted language. BPEL is such a language and is quickly becoming the dominant standard. The main goal of BPEL is to standardize the process of automation between Web Services.

Note

With BPEL we can define business processes that make use of services and business processes that externalize their functionality as services.

Within enterprises, BPEL is used to standardize enterprise application integration and extend the integration to previously isolated systems. Between enterprises, BPEL enables easier and more effective integration with business partners. BPEL stimulates enterprises to further define their business processes, which in turn leads to business process optimization, re-engineering, and the selection of the most appropriate processes, thus further optimizing the organization. Definitions of business processes described in BPEL do not influence existing systems. BPEL is the key technology in environments where functionalities already are, or will be, exposed via Web Services. With increases in the use of web service technology, the importance of BPEL will rise further.

IBM, BEA, and Microsoft developed the first version of BPEL in August 2002. Since then SAP and Siebel have joined in, which has resulted in several modifications and improvements and the adoption of version 1.1 in March 2003. In April 2003, BPEL was submitted to OASIS (Organization for the Advancement of Structured Information Standards) for standardization purposes, where the WSBPEL TC (Web Services Business Process Execution Language Technical Committee) has been formed. Many vendors have joined the WSBPEL TC (http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsbpel) since. This has led to even broader acceptance in industry. In April 2007, BPEL version 2.0 was approved by OASIS after quite a long preparation period.

BPEL represents a convergence of two early workflow languages WSFL (Web Services Flow Language) and XLANG. WSFL was designed by IBM and is based on the concept of directed graphs. XLANG was designed by Microsoft and is a block-structured language. BPEL combines both approaches and provides a rich vocabulary for the description of business processes.

Note

In this book, we will use BPEL version 2.0.

BPEL uses an XML-based vocabulary to specify and describe business processes. BPEL version 2.0 utilizes the WSDL 1.1, XML Schema 1.0, XPath 1.0, and XSLT 1.0 specifications. Familiarity with them is helpful for learning BPEL.

BPEL features

With BPEL we can define simple and complex business processes. To a certain extent, BPEL is similar to traditional programming languages. It offers constructs, such as loops, branches, variables, assignments, and so on that allow us to define business processes in an algorithmic way. BPEL is a specialized language focused on the definition of business processes. It is an execution language for business processes, not a modeling language. Therefore, on one hand it offers constructs, which make the definition of processes relatively simple and on the other hand, it is less complex than traditional programming languages, which simplifies learning.

The most important BPEL constructs are related to the invocation of services. BPEL makes it easy to invoke operations of services either synchronously or asynchronously. We can invoke operations either in sequence or in parallel. We can also wait for callbacks. BPEL provides a rich vocabulary for fault handling, which is very important, as robust business processes need to react to failures in a smart way. BPEL also provides support for long-running process and compensation, which allows undoing partial work done by a process that has not finished successfully. Listed below are the most important features that BPEL provides. With BPEL we can:

• Describe the logic of business processes through composition of services

• Compose larger business processes out of smaller processes and services

• Handle synchronous and asynchronous (often long-running) operation invocations on services, and manage callbacks that occur at later times

• Invoke service operations in sequence or parallel

• Selectively compensate completed activities in case of failures

• Maintain multiple long-running transactional activities, which are also interruptible

• Resume interrupted or failed activities to minimize work to be redone

• Route incoming messages to the appropriate processes and activities

• Correlate requests within and across business processes

• Schedule activities based on the execution time and define their order of execution

• Execute activities in parallel and define how parallel flows merge based on synchronization conditions

• Structure business processes into several scopes

• Handle message-related and time-related events

Orchestration and choreography

Depending on the requirements, the composition of services can address private or public processes, for which the following two terms are used:

• Orchestration

• Choreography

In orchestration, a central process takes control over the involved services and coordinates the execution of different operations on the services involved in the operation. This is done as per the requirements of the orchestration. The involved services do not know (and do not need to know) that they are involved in a composition and that they are a part of a higher business process. Only the central coordinator of the orchestration knows this, so the orchestration is centralized with explicit definitions of operations and the order of invocation of services. Orchestration is usually used in private business processes and is schematically shown as follows:

Choreography, on the other hand, does not rely on a central coordinator. Rather, each service involved in the choreography knows exactly when to execute its operations and whom to interact with. Choreography is a collaborative effort focused on the exchange of messages in public business processes. All participants of the choreography need to be aware of the business process, operations to execute, messages to exchange, and the timing of message exchanges. Choreography in services composition is as shown in the following figure:

From the perspective of composing services to execute business processes, orchestration has an advantage over choreography. Orchestration is a more flexible paradigm, although the line between orchestration and choreography is vanishing. Orchestration has the following advantages:

• We know exactly who is responsible for the execution of the whole business process

• We can incorporate services, even those that are not aware that they are a part of a business process

• We can also provide alternative scenarios when faults occur

BPEL provides support for orchestration and choreography through executable and abstract business processes.

Executable and abstract processes

With BPEL, we can describe business processes in two distinct ways:

• We can specify the exact details of business processes. Such processes are called executable business processes and follow the orchestration paradigm. They can be executed by an orchestration engine.

• We can specify the public message exchange between parties only. Such processes are called abstract business processes. They do not include the internal details of process flows and are not executable. They follow the choreography paradigm.

Executable business processes are processes that comprise a set of existing services and specify the exact algorithm of activities and input and output messages. Such processes are executable by BPEL engines. Executable processes are important because they are the direct answer to the problem of business process automation through IT that we have discussed earlier in this chapter. With BPEL executable processes, we are able to specify the exact algorithm of service composition in a relatively simple and straightforward way, and execute it on a BPEL-compliant engine. Executable processes fill the gap between the business process specifications and the code responsible for their execution.

When we define an executable business process in BPEL, we actually define a new web service that is a composition of existing services. The interface of the new BPEL composite web service uses a set of port types, through which it provides operations like any other web service. To invoke an executable business process, we have to invoke the resulting composite web service. You can see that executable business processes are the most important way of using BPEL. In the majority of cases, BPEL is used to specify executable processes.

Abstract business processes, on the other hand, are not executable. They specify public message exchange between parties only the externally observable aspects of process behavior. The description of the externally observable behavior of a business process may be related to a single service, or a set of services. It might also describe the behavior of a participant in a business process. Abstract processes will usually be defined for two scenarios:

• To describe the behavior of a service without knowing exactly in which business process it will take part

• To define collaboration protocols among multiple parties and precisely describe the external behavior of each party

Abstract processes are rarely used. The most common scenario is to use them as a template to define executable processes. Abstract processes can be used to replace sets of rules usually expressed in natural language, which are often ambiguous. In this book, we will first focus on executable processes and come back to abstract processes in Chapter 3.