Chapter 1. Introduction to BPEL and SOA

BPEL (Business Process Execution Language for Web Services, also WS-BPEL, BPEL4WS) is a language used for the composition, orchestration, and coordination of Web Services. It provides a rich vocabulary for expressing the behavior of business processes. In this chapter, we will introduce BPEL, define its role with regard to Service-Oriented Architecture (SOA), and explain the process-oriented approach to SOA and the role of BPEL. We shall also provide short descriptions of the most important BPEL servers the run‑time environments for the execution of business processes specified in BPEL. We will also compare BPEL to other business process languages. In this chapter, we will:

• Discuss the role of business processes and their automation

• Discuss business and IT alignment

• Examine SOA, its concepts, and BPEL

• Look at the SOA building blocks, such as services, Enterprise Service Bus, Registry and Repository, Human Task Support, Process Monitoring, Rule Engine, and Adapters

• Mention SOA governance

• Look at BPEL features

• Distinguish between Orchestration and Choreography

• Examine the relation of BPEL to other languages

• Overview BPEL Servers and SOA platforms

• Discuss the future of BPEL

Why business processes matter

Enterprise applications and information systems have become fundamental assets to companies. Companies rely on them to be able to perform business operations. Enterprise information systems can improve the efficiency of businesses through the automation of business processes. The objective of almost every company is that the applications it uses should provide comprehensive support for business processes. This means that applications should align with business processes closely.

Note

A business process is a collection of coordinated service invocations and related activities that produce a business result, either within a single organization or across several.

Although this requirement does not sound very difficult to fulfill, real-world situations show us a different picture. Business processes are usually dynamic in nature. Companies have to improve and modify, act in an agile manner, optimize and adapt business processes to their customers, and thus improve the responsiveness of the whole company. Every change and improvement in a business process has to be reflected in the applications that provide support for them.

It is most likely that companies have to live with very complex information system architectures consisting of a heterogeneous mix of different applications that have been developed over time using different technologies and architectures. These existing applications (often called legacy applications) are a vital asset in each company and core business usually depends on them. Replacing them with newly developed applications would be very costly and time consuming and usually would not justify the investment.

On the other hand, existing applications have several limitations. Probably the most important fact is that the majority of older applications have been developed from the functional perspective and have addressed the requirements of a single domain. Therefore, such applications typically do not provide support for the whole business process. Rather they support one, or a few activities, in a process. Such applications provide support for certain functions or tasks only. For an information system to provide complete support for business processes, it has to be able to use the functionalities of several existing applications in a coordinated and integrated way.

The consequence is that users need to switch between different applications to fulfill tasks and also perform some tasks manually. The flow of the tasks is in the heads of users, not in the information system, and this has several disadvantages, such as:

• Limited insight into the way business activities are performed

• Difficulties in tracing current status and progress

• Difficulties in monitoring key performance indicators

Existing applications have often been developed using older technologies, languages, and architectures, which are by definition less flexible to change. Tightly coupled applications, constructed of interrelated modules, which cannot be differentiated, upgraded, or refactored with a reasonable amount of effort, place important limitations on the flexibility of such applications. This is why such applications are sometimes called stovepipe applications.

Let us summarize on one side we have the business system, which consists of business processes. Business processes define the order of activities and tasks that produce a specific business result. Business processes have to be flexible in order to adapt to customer requirements, to market demand, and to optimize operations.

On the other side, we have the information system with multiple existing applications. Existing applications have important business logic implemented, which a company relies upon to perform business operations. Existing applications are also difficult to modify and adapt because they have not been developed in a flexible way that would allow modifying application parts quickly and efficiently. This is shown in the following figure: