David Chappell


Get the Feed! Subscribe

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.

11 comments :: Post a Comment



Whether it is a language (compared to Java) or not, BPEL gives you process oriented support as first class members (such as links for synchronization). And most important, you can run it!

But if these things are useful--and they are--why not add them to a mainstream language, e.g., Java or C#, rather than creating a new language with BPEL? And if you like the idea of creating a new language, why not make it approachable for developers rather than XML-based?

If BPEL is generated from another representation, such as BPMN, there are sensible answers to both of these questions. If you view it as a programming language, however, you're left with a needlessly complex way of describing process logic that's unlikely to ever gain wide developer support.

Object oriented languages can certainly be used in a process centric design model, but is it optimal for a language with its roots in a data centric one?

BPEL is small, compact and sort of domain specific. C# has a history, it's huge, versatile and it's expanding conceptually.

I agree with you in respect to the complexity of describing process logic using BPEL. But wouldn't a process oriented language do better bridging the communication gap between business and tech.

While BPMN is a 1 to 1 abstraction to the underlying runtime model, an object oriented language will have a long and winding road (via case tools, patterns, etc) trying to map to the business.

Btw I see no reason why new languages can't be accepted among developers (even though they are XML-based).

New languages certainly can be adopted by developers, and the idea of a process-oriented language is appealing.

But is that language really for developers? If the goal is to help bridge the gap between business and IT, a graphical language is much more useful. The language that people actually work in should be BPMN or something like it, not a conventional programming language. And it certainly shouldn't be an XML-based language like BPEL. (We'll have to agree to disagree here, I think--I believe that XML-based programming languages just aren't feasible for mainstream developer use.)

Bytecode is useful, and BPEL is useful, too. But neither one has their primary value as a language in which developers directly write logic.

I would say that a process oriented language executing in a runtime environment with process oriented service would be appealing even to developers. Why not?

Watching these guys do magic with message cordination makes me believe in common languages.


I think you're right, Jonas: there certainly are cases where a programming language with process-oriented constructs would be useful. I just don't believe BPEL is the right choice for this language.

I for one could not agree more. If BPM = Human Workflow + Service Orchestration then, BPEL did not have much future to begin with since its initial focus was too much on system to system integration, requiring solid IT programmers to figure out all the complicated and highly theoretical constructs that it presented. I guess, this is what happens when you involve industry heavy weights (a la IBM/Microsoft) who dont agree with one another, but still have to work jointly on a "standard". BPM is all about putting the power back of process automation back in the hands on the business. The other thing is, even now BPEL does not have a standard for the key component of BPM (i.e. Human Workflow).

In summary, I think BPEL is a child of one un-happy union. (i.e. IBM and Microsoft).

On another subject, I have been following the BPMS space for quite sometime and have seen many entrants come and go. Recently I was introduced to the CEO of Selcian, the latest entry in this space. While the company is still in its infancy and quite small,I must say, it was quite refreshing to see a completely independent and business focused approach to product development. In addition to having a just exceptional technical team, their product seems to offer features that many of the existing products dont. They seem to have taken the "3rd Wave" of BPM message to heart. One caveat I have to add is, while Selcian seems to be off to a great start and doing all the right things, time will only tell where they end up in the long run.

Anonymous, from where did you get your definition of BPM?

Could you give examples where BPEL lacks due to its purpose?

Hi Jonas,

I am sure, there are many definitions of BPM, but this is the one I choose to use. Whats yours ?

For BPEL, here are the issues with it.
1) It lacks support to activities involving human workflow.
2) BPEL is not a programming language, but a runtime representation of process logic. If that is correct, then why would I want to 1) write this myself 2) why do I care, what language is used at runtime
3) BPEL has developed un-necessarily complex constructs which are not easy to understand even for those with a technical bent of mind. The whole appeal of BPM is to the business analyst, who wants to make quick changes to the process, without having to know what an "endpoint" or a "port" or a "pipeline" is. BPEL by definition defeats this purpose.

FYI, this blog triggered my to write a blog response. I'm always interested in your comments.


Post a Comment

<< Home