I suspect Web Service Business Process Execution Language is known to most people for the graphical designer tooling that vendors bundle with their web services suite products. My first thought when I saw this colorful click and drag tooling being demonstrated was: it looks nice, but why would someone want to code if-then-else constructs with a mouse? Is this yet another effort to bring programming to the non-programmers?
After a bit of reading up I started to recognize WS-BPEL’s true value. It is not the graphical designer tooling. In my opinion, there is simply too much XML technology that cannot be hidden from the user, to make the tooling actually usable to non-programmers. While the designer tooling is still useful, I think the true value lies in the capabilities of the WS-BPEL engine. In this post I will present a realistic working example of WS-BPEL in an ESB environment, I will explain in detail how correlation works and I will give you tons of other tips along the way. What I find very useful is the ability of the WS-BPEL engine to run a really large number of concurrent processes (”process instances”) for a really long time (hours or even months). Compare this to a JEE application server environment. Imagine having an EJB method that run’s for more than just a few seconds. When a lot of users start hitting this method in production, the application server will sooner or later run out of Java threads and refuse to take on more work. This is not the case with the WS-BPEL engine, because its processes live on a level above Java (or operating system) threads. Some WS-BPEL engines can be configured to use database tables to store its running processes and their contexts. In this scenario, you can theoretically scale up to millions of concurrent processes, with an additional bonus: the processes will easily survive crashes or other downtime of the WS-BPEL engine. One can even inspect the state of processes in the underlying database, something that is somewhat similar to looking at Java thread dumps in a JEE application server environment.
I consider a JEE application server and a WS-BPEL engine to be opposites of each other, with both of them being very useful for specific usage scenarios. A JEE server is useful for very short lived CPU- and/or IO-intensive activities while a WS-BPEL engine is useful for activities that are very long lived, but non intensive on system resources (in fact, 99.9999% of time or more these activities are simply waiting for something external to happen). Naturally it is possible to run short lived processes on a WS-BPEL engine, but in my opinion one has to have a good reason to do that, because it should not be a surprise that WS-BPEL’s nice features come hand-in-hand with a noticeable performance penalty.
Being designed to support long running processes, WS-BPEL brings a few other goodies to the table. First of all, there is build-in support for compensating transactions. Compensating transaction will reverse (or at least try to reverse) the effects of transactions that have already been committed, once a process decides that it can’t complete its happy flow. Trying to compensate transactions is an alternative to “ACID-style” locking of resources for the duration of the process and committing only at the end of the process. With long running process, resources may be locked for an equally long time, thus blocking them for other processes, which may not be desirable.
Another goodie of WS-BPEL is the timeout mechanism. Even a long running process can be waiting on something to happen for too long. This may typically be the case when WS-BPEL processes require human interaction. People might simple forget or be unable to perform their action in a process. After a specified waiting period, the WS-BPEL engine will stop waiting and activate a handler to deal with the situation.
Correlation is another important WS-BPEL mechanism (not really a goodie I would say, but something that is necessary for proper operation). A WS-BPEL process invokes other web services (”partners”) but is also a web service itself. Kicking off a new WS-BPEL process instance is not a big challenge, it requires a regular web service call. But what if a call must be made to an already running process instance? This is called a ”callback”, because the partner that is making the callback was – normally speaking – first called by the process. How does the WS-BPEL engine know which instance of the process must handle the callback? To deal with that problem the WS-BPEL specification introduces the mechanism of correlation (correlation will be discussed in detail later in this post).
So far I’ve been able to avoid to use the word “orchestration”. In many WS-BPEL articles I’ve read that WS-BPEL is all about web service orchestration. In my opinion, web service orchestration is not a very meaningful term. Instead, for me the terms “process” and “compound web service” do a better job of underlining the value of WS-BPEL.
In the next part I will introduce an example, by which a number of important WS-BPEL mechanisms will be explained.