Business Process Execution Language

BPEL (Business Process Execution Language) is one of the new buzzwords thrown around with the same frequency as SOA (Service Oriented Architecture). Let us make an attempt to dismantle this jargon and try and understand the context and usage of this term.
BPEL talks about business processes. Hence, we first need to take a look at this term. It actually means what we think about this term. It is some work that we need to carry out (e.g. transfer money between two accounts, or purchase goods, or generate invoice). Usually, it is composed of a sequence of steps or actions in a specific order. When all the steps are completed successfully, the business process is considered to be complete and successful as as whole. A business process is rarely all-automated, and is usually a mixture of automated steps plus human interventions. Also, it can involve interactions with various other applications/systems inside the organization, or even outside. Hence, usually some sort of integration-related requirements are a part of any business process.

Now, what if we can describe a business processes in a language of its own? Better yet, what if we can implement it as a service (usually a Web service)? That is where we start moving from a business process to BPEL. If we can create a service that spans across all the steps necessary to complete the objectives of the business process, we would provide the technology support for implementing this as well. Hence, we can consider BPEL as a language that allows us to combine multiple small services (called as fine-grained services in the jargon) to create a big service that implements our business process (called as coarse-grained service in the jargon), in the right sequence.

BPEL, like anything else, these days, is based on XML. It is a part of the Web Services specifications. It allows us to define, carry out (i.e. orchestrate in the jargon), and manage business processes. The business processes themselves, as mentioned earlier, are implemented as Web services in the most common form. Therefore, we can crudely define BPEL also as a language that arranges one Web service after the other in a well-defined sequence, and gets some useful work done out from it (which we call as a business process).

The whole idea here is that non-technical people should be able to create and describe business processes. For taking the idea further, most BPEL development environments provide intuitive IDEs that are almost completely GUI-driven. This means that business analysts can not only elicit and describe requirements in plain English, but then can actually draw the flow of events as it is supposed to happen (e.g. Receive account numbers and amount -> Validate accounts -> Perform funds transfer -> On success, return ‘Success’ message, but on failure, return ‘Error’ message) using ready-made icons. Then how is this different from the use cases and sequence diagrams in UML? Well, the idea is quite similar in concept. However, the difference is that BPEL is closely tied to the SOA/Web services buzz (instead of the object orientation buzz), and secondly BPEL diagrams generate code in XML-like syntax (unlike the Java/C++ syntax as in the case of UML).