Service invocation and orchestration

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.