Is BPEL irrelevant?

Some time ago I wrote about the issues with the new 2.0 version of BPEL, namely backward capability. Many of those issues, according to people using the technology, came true. The movement to 2.0 was somewhat of a challenge. However, the challenges around BPEL may not be around backward compatibility these days; it may be more around not being made irrelevant in the context of SOA.

OK, perhaps it’s just me but I don’t see BPEL that much these days, either around its use within SOA problem domains I’m tracking, or a part of larger SOA strategies within enterprises. Understand, however, that my data points are limited, but I think they are pretty far-reaching relative to most industry analysts’. So, you may have another opinion, I’m sure the BPEL vendors will. Moreover, I’m sure sales figures can be tossed my way, but those are typically around bundled solutions, and in many instances BPEL is just shelfware.

Full disclosure: I worked on one of the first BPEL engine years ago and found issues with the standard then. Over the years, I think the BPEL vendors have done a good job in improving the standard and their products (many with proprietary extensions) that follow the standard, but perhaps BPEL is not catching on to the degree that many predicted.

Core issues with BPEL include the fact that it is very synchronous in its approach and has a few programmer-level issues including limitations around request/reply exchanges in a heterogeneous architecture, exception handling, failure recover, multi-programming model support, and a few other issues which I view as minor. However, what’s core to the issue with BPEL is that it’s not very good at adding a human as part of the process and as SOA moves forward, I’m finding that composites and workflows are more applicable than simple service binding and extending. Moreover, there is not a lot of BPEL on-demand, and many SOAs are heading the way of the Web, or Web Oriented Architecture (WOA).