Somewhere in the lobby after an IBM/Oracle seminar showing off their shinny and latest BPEL products
Brainwashed customer: I just met with IBM and Oracle and I'm convinced that I need their BPEL engines since we are going down the SOA road. After all, what am I going to do with my business services?
BPEL Zen Master (to herself): Ah. I see I have to do more penance on this earth by suffering these zombies. Looks like they dont know that SOA is dead
BPEL Zen Master : I agree you need to model and monitor your business processes and also automate some 'processes' that you have. How did they convince you that you need BPEL to do this?
Brainwashed customer: They told me that with BPEL my business activities can be modelled and hence I will have control and I can monitor them and I can tweak them and ....
BPEL Zen Master: Ahem! Have you tried modelling your process in a tool that supports BPMN? Have you tried the same with a tool that does it in BPEL.
You must know that you cannot model your Business Process completely in BPEL as you can do in BPMN.
Contrary to what a vendor might tell you, a business analyst just CANT manage (draw, manage, round-trip) a business process as a BPEL today. Anyway, once you model your processes in the vendors modeller, round-tripping that back is virtually impossible. Besides, BPEL is all very technical...Would your like your Business Analyst to know what a SOAP fault is?
Brainwashed customer: SOAP what?!... Nevermind..But...I can orchestrate my stateless "processes" easily!
BPEL Zen Master: Vendors have been fooling customers into using microflows (an IBM innovation... verbiage-wise) which are nothing but stateless 'programs' that invoke (orchestrate) webservices. You're better off using a mediation module (Take that, IBM.. you can stick your microflows where the sun dont shine). Speaking about Oracle, there's really not much to speak of. After acquiring BEA, they seemed to have dumped their BPEL engine in favor of BEA's. Actually, from a quick look at their conFUSION Middleware stack, they dont know their butt from their heads. Buttheads! For the rest of us, a simple composite business service will do. Not only will you yourself save mucho $$$ by not buying the BPEL engine, but also CPU, storage space, administrator time and most importantly user frustration.
Brainwashed customer: But I will be backed by standards if I go with BPEL, wont I? What about long running processes with human interaction? Is'nt BPEL the best for this? I'm solid with the support on standards aren't I?
BPEL Zen Master: Oh yes! A million of them, non which make sense to any business analyst anyway. And here something to thing about: Any decent business process will probably require some human interation.
Well Long running with Human Interaction... Hmm dont let the BPEL vendors fool you on this one. The moment you get human interaction as part of your BPEL, you'd have to use their extensions to BPEL (which are completely proprietary).
That flushing sound you are now hearing is the standards going down the toilet.
In case your still wondering about which way to go, this should enlighten you
I will reproduce it here for your convenience.
Hermann Schmidt: BPEL is advertized as a high-level process design language. That's a lie. BPEL exposes the designer to lowest-level issues like communication failures, SOAP faults, and XML unmarshalling problems. Drawing a BPEL process naively will not produce any usable artifact. It is a programmers job. Picking up the recent discussion about "BPMN is not software engineering", I think it is fair to say that BPEL is one reason why BPMN still is software engineering. 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. |
Brainwashed customer: Master, that was enlightening. During my meditation my mind drifted to a scene from the movie 'The Matrix' and then... then it hit me
