Services are self-contained units of functionality. BPEL processes specify the exact order in which participating services should be invoked—this is called orchestration. We can do this sequentially or in parallel. With BPEL, we can also express conditional behavior; for example, a service invocation can depend on the return value of a previous invocation. We will see that BPEL processes are essentially graphs of activities.
In this chapter, we will learn how to use BPEL for service invocations using sequential flows. We will develop a BPEL process, which will invoke other services and orchestrate them. This way, the BPEL process will consume services, thus building a composite application.
In traditional programming languages, we used to invoke operations sequentially, one by one. In business processes, however, we often need to execute activities in parallel. We will see that BPEL provides a relatively easy way to invoke services and execute other activities in parallel.
In this chapter, we will extend our example process from the previous chapter and learn how to invoke and compose services in a sequential and parallel manner. In this chapter, we shall:
- Understand service invocation and orchestration of services
- Develop a book warehousing process that will invoke and orchestrate services
- Understand sequential invocation and partner links
- Understand parallel invocation, parallel flows, and develop a process using parallel invocation
So let's get started.
In the previous chapter, we learned the basics of BPEL. We learned that BPEL processes can be synchronous or asynchronous. BPEL processes consist of activities. A process usually begins with a <receive> activity, which is responsible for receiving the request from the process client. Then, the BPEL process executes some logic. So far, we have become familiar with the <assign> activity for manipulating variables and with the <if> activity for conditions.
We have also learned that BPEL is a programming-in-the-large language, meaning that we do not program distinct functionalities in BPEL. Rather, we use BPEL to orchestrate services—in other words, it invokes several services in a specific order to perform a certain business process.
In a typical scenario, the BPEL business process receives a request. To fulfill it, the process then invokes the involved services and finally responds to the original caller. Every BPEL process specifies the exact order in which the participating services should be invoked. This can be done sequentially or in parallel. With BPEL, we can express conditional behavior; for example, a service invocation can depend on the value of a previous invocation. We can also construct loops, declare variables, copy and assign values, define fault handlers, and so on. By combining all these constructs, we can define complex business processes in an algorithmic manner. We can describe deterministic as well as nondeterministic flows.
To demonstrate how to use BPEL to invoke services and orchestrate them into business processes, we will define a simple business process for book warehousing. Let's consider a big bookstore, which has two bookstores located at different locations in the city. It also has a central office location where all the new books are delivered. When a new book is delivered to the central office, we have to check the stock quantity for this book in each bookstore. Based on this information, we decide how many books we will send to each bookstore. This simplified process flow is shown in the following screenshot:
To query the book quantity in Bookstore A and Bookstore B, we will use both BPEL processes, the BookstoreA and BookstoreB BPEL processes, which we developed in the previous chapter. These processes return the stock quantity information, which is exactly what we need.
To orchestrate both BPEL processes, we will invoke their operations through the WSDL interface that both processes expose. We have mentioned that each BPEL process is exposed through a WSDL interface, meaning that to the outside world, it looks like a web service.
Although in our example, we invoke BPEL processes for Bookstore A and Bookstore B from the book warehousing process, please remember that with BPEL, we can orchestrate any kind of services, no matter how they are implemented (BPEL, Java, C#, C++, Python, or any other language), or even exposed for an existing application. Therefore, we will refer to them as services.
The following figure shows schematically what we are about to do:
To be able to invoke services, we need to be familiar with their interfaces. For example, the book warehousing process will need to know exactly how to call the BookstoreA and BookstoreB services (please note that we refer to them as services, when they are called from outside, although they are implemented as BPEL processes). To do this, we need to look into WSDL interfaces. In our example, both bookstore services have the same interface. Actually, we can see the operation name on the SCA composite diagram already. We will have a detailed look into the WSDL interfaces later, when we will explain the notion of partner links. Now, however, let's develop the book warehousing process in BPEL.