Why BPEL is Like Bytecode
Sunday, May 28, 2006
I'm not convinced that BPEL has much of a future as an executable language (see here
for why). Still, plenty of people think otherwise, and most of the discussion around BPEL assumes this perspective. Even if you accept this view, however, I'd still argue that the typical take on BPEL is inaccurate.
People tend to think of BPEL as a programming language. The expectation is that a developer writes process logic in BPEL just as she writes object-oriented logic in a language such as Java. But unlike Java and every other mainstream programming language, BPEL is defined using XML. Accordingly, it was designed to be generated by tools, not written directly by developers. Whatever BPEL aficionados believe, masses of developers are never going to work directly in a complex XML-based language.
In fact, as an executable language, BPEL's primary goal is to provide a portable description of logic. Isn't this exactly what Java bytecode strives to do? BPEL focuses on process logic, while bytecode takes on a broader problem space. Yet the two are quite analogous: both are tool-generated languages (bytecode by a Java compiler, BPEL by some graphical process design tool) and both can potentially foster portability.
If BPEL is analogous to Java bytecode, what in the BPEL world is analogous to the Java language itself? The answer must be the thing from which BPEL is produced, i.e., the graphical process description format. Today, different vendors take different approaches to doing this. There is an impending standard, however, in the Business Process Modeling Notation (BPMN)
. Just as lots of people know Java, lots of people may one day know BPMN. And just as almost nobody except tool vendors works directly in or even thinks much about Java bytecode, the day may come when almost nobody except tool vendors works directly in or thinks much about BPEL.
If you believe that BPEL has a future as an executable language--and again, this is an open question today--viewing BPEL as more analogous to bytecode than to Java gives a clearer view of the role this language plays.