Some More BPEL Fun
Friday, October 24th 2008 | Ismael Ghalimi
The more I’m writing about BPEL, the more people I seem to be annoying. The latest to date is Keith Swenson from Fujitsu, who seems to be pleased by InfoQ’s recent article, and more than happy to join the BPEL bashing party. I call them legacy workflow vendors. They call us EAI folks. Touché! This is so much fun… But let’s take a look at why their arguments just don’t hold.
In all these articles, the main argument seems to be that BPEL is a poorly-designed language for allowing business analysts to describe business processes. Well, guess what? Of course it is! For two reasons: first, it has never been designed to be used by human beings. Two, no business analyst who respect herself would ever use a programming language to begin with, be it BPEL, XPDL, or any other character-based language. So where on Earth did these self-proclaimed BPM experts read anyone claiming that BPEL was good for business analysts?
The thing is, nobody ever said or wrote that. What was stated instead is that BPMN is the proper way for business analysts to describe business processes (everybody seems to agree on this point), and that BPEL was the most powerful way to translate BPMN diagrams into fully executable processes, for this class of processes that need to be distributed across an extended value chain (translation: across multiple servers), mainly because BPEL is based on Pi-Calculus’ most powerful feature: channel passing. That’s it. Nothing more, nothing less.
So, just to make it perfectly clear: as was stated in this past article, BPEL is not for human beings, and even less for business analysts. Business analysts should not use BPEL, nor any other language for that matter. They should use BPMN, and take advantage of its exceptional expressive power for designing end-to-end business processes that can be distributed across any number of participants, on top of a Service Oriented Architecture. And the only language that can support such a deployment model is BPEL. If you disagree with such a statement, please explain to me what I am missing. If not, once again, we made our point.
Entry filed under: BPM 2.0
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Why isn’t BPEL just an implementation detail. In other words, if my execution layer faithfully implements my BPMN diagram well, what matters if it is a BPEL engine, or a Widget Engine, or whatever the heck it is?
Since I’ve seen perfectly good running processes, on systems that don’t use a BPEL engine under the hood, but which execute a BPMN model… I guess I’m not seeing the connection that for BPMN to work right, it has to be BPEL. I’ve even seen such solutions scale to a tremendous degree.
I’m not saying BPEL isn’t valuable, I just don’t buy that it is the only answer. It is an answer, it has a spec/standard, and it has a few implementations. That’s all well and good. But it doesn’t mean that someone can’t come up with another answer…
As an example, think of all the programming languages that also support Java VM implementations of that language (meaning, the language compiles into Java bytecode equivalent and runs inside a JVM). The language cares not that it is being run by JVM bytecode vs. run by native compiler. Even the person writing the code may not care. I think BPMN is similar — I don’t care so much about what is executing it so long as it is a “good” execution of my model. And I might choose a “native” compilation or a “BPEL” compilation or a ABCD compilation (whatever the next standard is).
I think you guys have done a great job with the software, and the evangelism, but I’m not convinced by your arguments and others that BPEL is the only way to implement BPMN.
Scott,
BPEL is not the only way to support BPMN, but it’s the best way, for the very many reasons that have been outlined on this blog. It’s also the only standard way I can think of, from the viewpoint of a standard execution language for processes.
Best regards
-Ismael
Trackback this post | Subscribe to the comments via RSS Feed
Leave a Comment