A Primer on Business Process Execution Language (BPEL)
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).
BPEL Case Study
We have discussed the English-like description of a funds transfer process earlier. Let us now see how a typical BPEL workflow would look like in the diagrammatic fashion, and also how the syntactical version would look like.
This is how the BPEL workflow would conceptually look like, when drawn in an IDE.
From a syntactical point of view, the above BPEL diagram would translate into the following XML (in a crude translation, done only for conceptual understanding):
<process>
<receive createInstance=”yes” />
<invoke name=”validateAccounts” />
<switch>
<case status=”invalid”>
</case>
<case status=”valid”>
<invoke name=”transferFunds” />
</case>
</switch>
<reply variable=”status” />
</process>
We can see that the BPEL process starts with a process element. It has one or more activities. We can invoke other services using the invoke element. Variables can be defined, conditional code can be written, and so on. What is not shown is that even loops can be written using the while construct. Similar to Java’s try-catch-finally, we have faultHandlers-catch-catchAll blocks here. Event handlers can be specified so that we can write event-based logic.
All in all, we can see that BPEL is a diagrammatic way of describing business processes, and generating XML in the background without having to write a lot of code to achieve the same thing. Of course, the actual backend business logic still needs to be written in some form or the other. But this is abstracted out in a better manner, and is standardized, using BPEL.
Related:
* Understanding Web Services and SOA
