We have seen that services provide business-aligned operations. To fulfill the SOA promise services need to be composed into new larger services. We compose services until the aggregate services provide support for the whole business processes. Business processes are thus defined as a collection of activities through which services are invoked. For the outside world—that is for the clients—a business process looks like any other service. In real-world scenarios we will usually create two kinds of business processes: those that will contain services from within enterprise only, and those that will consume services provided by several companies. With service composition we can use services provided by business partners in our processes, and business partners can use our services in their processes.

For example, a business process for planning of business travel will invoke several services. In an oversimplified scenario, the business process will require us to specify the employee name, destination, dates, and other travel details. Then the process will invoke a web service to check the employee status. Based on the employee status it will select the appropriate travel class. Then it will invoke web services of several airline companies (such as American Airlines, Delta Airlines, etc.) to check the airfare price and buy the one with the lowest price. The structure of services composed into the business process is shown in the following figure. In Chapter 3 we will discuss this example in detail and show how to define this process using BPEL:

From the perspective of our business process, we do not care whether the web service for checking the employee status accesses a legacy system, a database directly, or retrieves the status in any other way. We also do not care whether the web services of airline companies are composed of other, lower-level services. From the perspective of the client for our business process the client sees the process as any other service and does not care whether the process is implemented through composition of other services, or some other way. This stimulates reuse and further composition. Real-world business processes will usually be much more complicated than our example. Usually they will contain several services and invoke their operations either in sequence or in parallel. They will also contain flow logic, handle faults, take care of transactions and message correlation, etc.

Composition of services into business processes requires the definition of collaboration activities and data‑exchange messages between involved web services. WSDL provides the basic technical description and specifications for messages that are exchanged. However, the description provided by WSDL does not go beyond simple interactions between the client (sender) and the web service (receiver). These interactions may be stateless, synchronous, or asynchronous. These relations are inadequate to express, model, and describe complex compositions of multiple web services in business activities, which usually consist of several messages exchanged in a well-defined order. In such complex compositions, synchronous and asynchronous messages can be combined, and interactions are usually long running, often involving state information that has to be preserved. An important aspect is also the ability to describe how to handle faults and other exceptional situations. Given the limitations of WSDL, we need a mechanism to describe the composition of web services into more complex processes.

The composition of services into business processes could be realized using one of the well-known programming languages (Java, C#, …). But it turns out that the composition of services differs somehow from traditional programming. With composition, we merge functionalities (services) into larger services and processes. In other words, we do programming in the large, which differs from traditional programming in the small. Programming in the large refers to representation of the high-level state transition logic of a system. Using programming languages, such as Java, C#, etc., for composition often results in inflexible solutions, particularly because there is no clear separation between the process flow and the business logic, which should not be tightly coupled.

In addition to these facts, the composition of business processes has other specific requirements, such as support for many process instances, long-running processes, compensation, etc. All this makes the use of dedicated solutions reasonable. This is why over the years several proprietary BPM (Business Process Management) products have been developed, such as Dralasoft Workflow and Tibco Business Process Management . The disadvantage of using proprietary BPMs is that these are traditionally niche products, sold from a top-down perspective to large business users. Such products usually are expensive and bound to a certain provider.