BPEL: Who Needs It Anyway?
Keith Swenson starts his new article by evaluating BPEL’s usage in today’s BPM products:
It seems that conventional wisdom has been for a while that "Business Process Execution Language" or "WS-BPEL4WS" is the standard for execution in the BPM space. At the same time, the majority of BPM and workflow products on the market today work successfully without using BPEL. Some say that those products that don't implement BPEL are simply dragging their feet in the mud. Others say it is not possible to do what their product does in BPEL. Whom are we to believe?... Recently an article was written on InfoQ which took a particular process scenario drawn in Business Process Modeling Notation (BPMN), and investigated in detail why it can not be implemented using BPEL. That process can, however, be run on a system that directly executes BPMN... Since you can execute the BPMN directly, it begs the question: why translate to BPEL at all?
According to Keith, there are plenty of vendors and publications promoting BPEL "as the one-and-only-true-way to support BPM". In reality, there are plenty of successful BPM products that are based on other technologies. As a result, potential users should be asking the question "Is BPEL appropriate for what I want to do?"
Keith attributes popularity of BPEL to the following assumptions, often made by its proponents:
- The people making the processes are programmers
- The activities in a process only need to send, receive, or transform XML data.
- Any standard will be better than no standard.
Analyzing those, Keith states that the first two assumptions are:
...valid in some situations; the product category that we call EAI is in fact configured primarily by programmers, and need only to send, receive, and manipulate bytes of data. So for EAI, BPEL might be a reasonable choice. But many BPM products are designed to be configured by non-programmers; by the business people themselves (and that is indeed why we call them business processes in the first place). Non-BPEL approach exist that allow non-programmers to draw up and execute processes, safely and reliably. Those processes are qualitatively different from the processes a programmer might draw up, and many people familiar with EAI-style "BPM" are incredulous, but that basically circular reasoning based on the assumption that the process designer is a programmer. To be fair, some believe that business people will draw up initial process diagrams, that will then be fixed up by programmers. But there are other situations where there is a no programmer at all, and that in those situations BPEL would be a poor choice.
As for the last assumption, Keith considers it more "marketware" then reality:
people think that since there is overwhelming "magazine" evidence that BPEL is the right standard, then anyone not supporting BPEL is simply too lazy or trying to disrupt the marketplace. Unfortunately for these people, the process world is inherently more complex than they realize; the variations among approaches are not simply the randomness of vendor whim, but in fact an appropriates response to the variations in the needs for process support. People should keep in mind real requirements: if BPEL meets the need, then fine, but don’t blindly assume that one size will necessarily fit all.
Keith suggests replacing BPEL with the direct execution of BPMN-based process definition and shows how Fujitsu BPM Studio allows to do this. He finishes his article by stating:
Why again do analysts recommend BPEL? It seems to me... to be nothing but a limitation.
The confusion about BPEL and BPM in general seems to keep growing in the industry. There is still no agreement on the most basic BPM issues:
- Is BPM a business Discipline or software engineering?
- Whose responsibility is it to implement (automate) a business process?
- Should we aim to move from design to deployment with no programming?
- Whose responsibility is it to maintain a business process?
Only by getting agreement on these issues will allow us to frame BPEL discussion and the whole BPMN/BPEL relationship discussion correctly.
I don't need it
I have seen tutorials from SUN that show how to access rows in a database table with BPEL. What a brilliant idea. Let business people drag their data from databases directly! That about says it all how some vendors treat BPEL. It's just yet another programming language with a fancy graphical interface. "Hey, look what I can do with BPEL! Isn't that neat?". Hello? Service orientation?
BPEL has no modularity. BPEL has no concept of reusable patterns or code fragments (besides functional decomposition into yet more processes - did someone say high-level?). Reusing patterns in BPEL means cut&paste of sourcecode. No signs of object orientation anywhere. It is a low-level web-service caller with a functional decomposition design model and a little event dispatching with parallel execution. Oh, and you can shuffle data around in XML-based structures.
The ubiquitous GUIs give the illusion of a high abstraction. Ironically, they are necessary because BPEL code is a pain to write as text. The graphics are merely the syntactical representation of a very basic programming language.
Vendors pimp up BPEL engines with additional features to alleviate weaknesses of the language. This may even result in practically usable products, if done well. However, that makes BPEL non-portable in all but trivial cases and renders the whole standard useless.
I am deeply frustrated by the level of intelligence in this standard. I believe that it will not take the software industry any closer to more efficiency or excellence.
I don't need it. It doesn't get the job done.
Meant BPM when I said BPMN
before we throw the baby with the bath water...
ebXML was the stack to kill and indeed it was killed. Funny enough, WS and BPEL are now put on death row too.
The major problem I see with all these people making all kinds of claim that "we need this" or "we don't need that" is simply the complete lack of understanding of how a Service-Oriented, Process-Centric, Model-Driven programming model works.
Moving forward, there is no other way than "Composite Applications". We have enough silos, we don't need another system of record. However we will always need to build new solutions on top of existing systems of record. Since we don't need more silos, we don't need more integration. How do you build composite applications? You need to bring Service-Orientation, Resource-Orientation and Event-Orientation together in one coherent programming model. Yet our industry and many pundits love to oppose each and anyone of them. Can it become more insane?
Composite Applications and SREOA (sorry it does not sound as good as SOA) are about reusing information and information management as you create new solutions. These solutions are by nature process centric (for over 90%) of them.
Orchestration Languages (like BPEL) are an essential technology for creating process-centric programming model. But it does not work like keith is explaning. Compiling BPMN into BPEL is yet another example of how insane our industry has become. Is there a better square peg that you would want to fit in a round hole? For 10 years this stupid idea initiated by Intalio has dammaged BPM to the point that we are nowhere today, and it is actually pushing the BPM people in a dead-end direction as well. Executable BPMN alone will not work. Yes, a lot of (simple) cases can be covered by this model. I have no problem with that, I like simple solutions to simple problems and there are plenty of examples where people have done a great job at creating executable BPMN engines. Is that enough? are we heading for another wall just as big as the BPMN-BPEL conjecture?
The problem is that executable BPMN will not give us the ability to create composite application where we can reuse information and information management across solutions. I have written over a year ago an article explaining how orchestration languages fit in a SOPCMD programming model: www.infoq.com/articles/seven-fallacies-of-bpm
In this article, I explain how orchestration languages can be used to manage the lifecycle of business entities. It is not until we bring resources in alignment with processes that we will effectively build process centric. This is very tragic, because the failure to understand where BPEL fit is pushing the BPM people in an as big as an abyss that will take us another 10 years to dig out.
Couldn't we just end these stupid discussions and think just for 2 minutes how services, resources, events, processes and tasks fit together? Don't you think it would be a tremendous benefit to our industry to articulate all these concepts rather than opposing them? Can't the BPMN people see how limited their views are? Can't the OMG which produced so much great work in the past take the lead, stop BPMN 2.0 and create this unification? After 10 years are working at this problem and getting nowhere, somehow, we could decide that it is enough. This problem cannot be that complicated, provided we care to look the right way rather than fighting over "my concept is better than yours". All concepts have merit, all we need is to articulate them.
Re: Meant BPM when I said BPMN
Several comments to your reply:
- BPEL was never ment to be a high-level process design language. People that advertise it as such are either misleading their audience to sell their product or just do not know what they are talking about. In fact, the name itself stands for Business Process Execution (not design) Language.
- BPEL is based on XML, so GUI editors are very usefull to to simplify programming. I know people that can write BPEL using notepad, but the majority would would use GUI tools.
- BPEL is a high -level domain specific language, so I am not sure that introduction of OO elements is appropriate for it. In general you do not write, for example, business logic in BPEL - you use it as a glue to orchestrate business logic implemented in services, written in other languages.
- Reuse in BPEL is really process decomposition and is typically done through either subprocesses or wrapping existing processes as services and using them for building higher level orchestrations.
And if you refer to the previous discussion - BPM is not software engineering, but its automation definitly is.
Re: Meant BPM when I said BPMN
Francisco Jose Peredo Noguez
I agreew with Boris Lublinsky, BPM is not software engineering, but its automation definitely is.
* Whose responsibility is it to implement (automate) a business process?
Again the confusion, this are two questions merged in to one:
Whose responsibility is it to implement a business process? that is a business management question
Whose responsibility is it to automate a business process? that is a software engineering question*
*Should we aim to move from design to deployment with no programming?
Again, this question needs to be analyzed and decomposed: What do you exactly mean by design? What do you exactly mean by deployment? What do you exactly mean by programming? I few days ago a vendor arrived at the company where I work selling us: "Code-less Programing". According to him, with his product you could program, without code... because you could "Drag & drop" stuff like "if" and "while loops" in to diagram. (Something similar, to this www.zoho.com/creator/overview/deluge-script.html, but more "graphical")... I didn't know if wanted to laugh or to cry.
Who cares if you are dragging and dropping things or actually using the keyboard? you still need to program, because you still need to "create an algorithm", it does not matter if you do it in Java, in C#, in Ruby, in Lisp or in BPEL. if you are creating algorithms, you are programming, period.
Even if you use logic programing and your responsability is only "ensuring the truth of programs expressed in logical form" you are still programming.
So, we should ask ourselves, does it even make sense to talk about "move from design to deployment with no programming"
* Whose responsibility is it to maintain a business process?
Again, define "maintain"... from what perspective? business strategic planning? or software automation?
Re: Meant BPM when I said BPMN
okay, I add process automation to my vocabulary and keep it separate from modelling. Makes sense.
Granted, BPEL may not have been invented as a high-level process design language and I was trapped in vendors promises. On the other hand, BPEL is the highest level that most vendors can offer. That's probably why they are selling it this way.
BPEL is not high-level because it does not shield the low-level issues that I named. A typical BPEL process is cluttered with low-level exception handling - provided you take exception handling serious. The mickey mouse tutorials and examples I found in the net are outright ridiculous.
I think, the actual level of a process is defined by the services that get orchestrated. Low-level services result in low-level orchestration. BPEL itself does not add any abstraction to it.
I cannot agree that glueing services together is not business logic. I think it is, because once code processes/transforms business data, it becomes part of the business logic. In service orchestration, data mapping is typical. Also, if a business process is not business logic, what else is it?
If we are going to build applications by composition of services, we definately need someting with more power. This begins with an intelligent infrastructure or programming model, as Jean-Jacques is furiously promoting (no pun intended).
For me, BPEL is a dead end. I will tell all my customers to stay away from it (if they are willing to listen).
BPEL and BPMN were only ever "friends"
The question "BPEL: who needs it anyway?" is very general. Are there any valid uses of BPEL: yes.
The question "Does BPMN need BPEL?" or "Do BPMN products need BPEL" is more specific - and more importantly answerable: No.
The question "Does BPEL need BPMN" is also answerable: No.
Maybe they should just agree to go their separate ways.
Re: BPEL and BPMN were only ever
I agree with your two answers, but is it that simple? Are we confident that "Executable BPMN" is sufficient to build composite applications or are we proposing a new conjecture? Where is the proof? Because some cases work, it is definitely "the answer"?
Keith comes up with "one" example and tells us, look "you don't need BPEL" and by the way my product can do this example so why don't you buy my product and we never talk about BPEL again?
However, I think Keith shows the problem very clearly in his little example: there is a very interesting activity in its 4 activity process: "Fill HR DB". This for me signals that an "Executable BPMN" will strongly couple the "executable side" with the "modeling side". Business processes are going to start filling up with tons of those "update this", "create that", or "delete those" activities. How is "reuse" going to play in that world?
Couldn't we think about an alternative model where you have the BPMN layer (the activity layer) and the Resource Layer? Isn't it the goal of any process to transform resources to generate value and/or achieve a particular goal? How come the "resource layer" is so crippled at the BPMN level? Can't we describe the resource lifecycles using an orchestration language (such as BPEL) and associate the activities of the process to state transitions within these lifecycles?
So I would ask the following questions
a) can executable BPMN be used to create process centric composite applications?
b) can BPEL be used to create process centric composite applications?
An propose the following answers:
a) no, except in very simple cases. Otherwise, Enterprise Solutions would have long been rewritten on these executable BPMN engines
b) no, hell no
However, if you consider BPMN + BPEL ( again, to be clear, not BPMN <-> BPEL or BPMN -> BPEL) each taking care of a different levels of abstraction you can create a very powerful composite application model that suits both the business analyst and the developers. But what do I know? At least, I have no product to sell.</->
Re: BPEL and BPMN were only ever
I like you approach to look wider than just BPMN vs BPEL and consider a multi-layer architecture for process-centric composite applications in which many of existing technologies would co-exist. Do you know a (maybe, virtual) place where such a wider scope can be discussed? Topics for discussion, for example, are: BPM reference model (offer my contribution www.slideshare.net/samarin/bpm-concepts-de-base... ), BPM reference architectures, etc. I think they should lead us to a commonly agreed architecture for process-centric composite applications.
Fine-grain and Coarse-Grain
Most of the time one ideology fits better either for Fine-grain or for Coarse-grain elements. BEPL fits better if you have later kind of elements in your system.
Re: BPEL and BPMN were only ever
this is a great presentation and sadly, yes, we have to suffer for this "war" between vendors in the standardization group. It has been a nightmare ever since I started and it seems there is no end in sight. Even with great people like Conrad Bock and Fred Cummins whom I respect immensely, we unfortunately one more time heading in the wrong direction with BPMN 2.0. I don't know what it will take to get it right.
I don't know a forum that discusses BPM in ways that could help users. As you mentioned this space is locked by vendors.