BPEL vs. BPMN 2.0 – ewiger Catfight? Oder ist BPEL schon tot?
November 18 2009 by Bernd Rücker · 7 Comments
Zurück von der W-JAX 2009 juckt es mich in Fingern über die Zukunft von BPEL zu schreiben. Und da ich auf der W-JAX gelernt habe, dass sowohl Katzenbilder als auch Schlagzeilen, die “Tod” enthalten, eine Garantie für mehr Traffic sind habe ich das doch gleich mal ausprobiert. Übrigens zieht natürlich auch “Porno”, aber so weit wollte ich dann doch nicht gehen 
Nun aber ins inhaltliche. In unserem Vortrag “BPMN 2.0 – Wird BPEL noch gebraucht?” sind wir kurz auch auf unsere Einschätzung von BPEL für die Zukunft eingegangen. Ganz knapp zusammengedampft ist dies in etwa Folgendes:
- BPMN 2.0 wird BPEL im Bereich des “echten” BPM auf jeden Fall verdrängen. Für Business-IT-Alignment war BPEL nie gemacht und ist auch nicht geeignet.
- Alle großen BPEL-Hersteller arbeiten am BPMN-Standard mit, dementsprechend fließt viel Know-how von BPEL in BPMN und es ist auch kein “dein Standard unterstütze ich nicht” zu erwarten.
- Bei vielen Herstellern wird BPMN wie BPEL “nur” eine andere Sprache auf der gleichen Engine sein, somit wird man recht einfach beide Sprachen verwenden können, je nach Problem.
- BPEL wird nicht so schnell verschwinden, da es bereits in Projekten eingesetzt wird.
- In neuen Projekten erwarten wir immer weniger Nachfrage nach BPEL.
Insgesamt tendieren wir also bei der Frage “Wird BPEL noch gebraucht?” zur Antwort “Auf lange Sicht: Nein”. Und nach einigen Gesprächen auf der W-JAX und verhaltenem Gegenwind habe ich das Gefühl, dass wir den “catfight” pro und contra BPEL endlich beerdigen und in eine sachliche Diskussion einsteigen können 
Für mich bleibt die spannende Frage: Wird BPEL überleben für den Use Case “Serviceorchestrierung”, also wenn ich auf technischer Ebene mehrere Webservices zu einem höherwertigen Service zusammenstellen will? Das ist übrigens genau der Anwendungsfall, für den es auch erfunden wurde! Und hier gehen die Meinungen doch noch auseinander. Ich denke, dass BPEL selbst heute noch wenig zum Einsatz kommt und der Masse der Tekkies da draußen auch viel zu kompliziert ist. Okay, BPMN ist auch nicht viel einfacher, aber das müssen sie dank Business-IT-Alignment sowieso lernen (das wissen sie nur noch nicht ). Und mit BPMN 2.0 machen wir einen großen Schritt in Richtung gemeinsame Sprache, was BPEL weder adressiert noch erreicht hat.
Aber es gibt auch Features, bei denen BPEL punktet. Allerdings sind die meiner Ansicht nach schon eher selten anzutreffen, ich greife mir hier einmal wahllos das Beispiel eines “isolated Scopes” heraus, eines der ersten Beispiele die ich auf einem Gespräch auf der W-JAX an den Kopf geworfen bekam. Was ist das? Nun ja, in einem isolated Scope darf sich gleichzeitig immer nur ein Token befinden. Kommt ein zweites Token an diesem Scope an, so muss es warten. Dieses Konstrukt gibt es so direkt in BPMN nicht.
Nun gibt es mehrere Möglichkeiten aus diesem Dilemma:
- Es werden BPMN-Patterns eingeführt, um diesen Sachverhalt zu lösen,
- man wird weiterhin BPEL für diese Problemstellungen verwenden,
- Hersteller führen proprietäre Erweiterungen der BPMN ein,
- BPMN 3.0 deckt die fehlende Funktionalität ab (okay, darauf will ich auch nicht warten!).
Meine persönliche Einschätzung: Viele BPEL-Hersteller werden hineter den Kulissen die gleiche Technologie für die BPEL und BPMN-Engine einsetzen. Daher ist es auch sehr einfach, die BPMN proprietär zu erweitern und beispielsweise ein “isolated=true”-Flag anzubieten. Daraus resultierend würde ich sagen, dass auch BPMN für die Use Cases von BPEL auf kurz oder lang Verwendung finden kann und auch wird.
Dagegen gibt es auch Meinungen, dass BPEL weiter bestehen bleibt. Denn es gibt einfach unterschiedliche Probleme, und für einige davon ist BPEL eben doch besser. Und ich unterstütze die Argumentation, dass es nicht die perfekte Sprache gibt und kenne schon ein paar sehr gute Use Cases für BPEL. Dementsprechend wird es vermutlich auch nicht so bald sterben. Trotzdem könnte ich mir gut vorstellen, dass BPEL schlicht und ergreifend schon zu verbrannt (man denke an die enttäuschten Erwartungen) und nicht mehr “hip” ist und sich deswegen auch nicht mehr groß durchsetzen wird.
Und schlußendlich finde ich das auch nicht schlimm. BPEL ist komplex und teuer. Das wird BPMN 2.0 vielleicht auch, aber dafür bekommt man wenigstens eine Sprache für Business und IT, entledigt sich der problematischen Blockstruktur und ist nicht auf Webservices festgenagelt (siehe dazu auch
Bauen wir uns eine BPMN 2.0 Engine). Neben technologischen Gründen eben vor allem durch das Business-IT-Alignment auch Gründe, die tatsächlich methodische Vorteile bieten und Sichtbarkeit ins Management haben! Und von dort kommt bekanntermaßen auch das Budget…
Hallo Bernd,
2009-11-18 um 11.42 am Uhr. Verfasst von Torsten Winterbergsehr gute Zusammenfassung. Ich teile die meisten Punkte. Aus meiner Sicht entwicklen sich die Dinge positiv: mit BPMN 2.0 bekommen wir eine Sprache, die auch gleich in der IT ausführbar sein wird. Vermutlich in Q1/Q2 im nächsten Jahr werden wir die BPM 11g Implementierung von Oracle offiziell verfügbar haben. BPEL wird noch genau für die Dinge verwendet werden, für die es auch gut funktioniert: nicht die Abbildung fachlicher Prozesse soll umgesetzt werden, sondern z.B. technische Integrationsszenarien, die prozessartig ablaufen. Hierfür ist BPEL hervorragend geeignet. Daher Zustimmung: die Richtung, in der sich der Markt und die Hersteller bewegen, erscheint sehr sinnvoll.
Hallo Torsten,
Du sprichst in Deinem Kommentar davon, im Q1/Q2 die neue Oracle-Suite verfügbar zu haben. Wird es darin neben BPEL auch eine direkte Ausführbarkeit von BPMN geben oder wird immernoch nach BPEL übersetzt (mit allen Problemen, die damit einhergehen)?
@Bernd: Ich möchte nochmal auf Dein Beispiel mit den “Isolated Scopes” zurückkommen. Hast Du ein praktisches Beispiel, wo eine solche Funktionalität benötigt wird? Außerdem schreibst Du, dass Du ein paar sehr gute Use Cases für BPEL kennst: bitte benenne sie konkret. Mir fehlt noch immer _das_ Argument, von dem ich überzeugt bin, dass es nur mit BPEL gelöst werden kann und zu dem es auch in der Praxis Beispiele gibt, wo so etwas konkret benötigt wird.
2009-11-19 um 10.16 am Uhr. Verfasst von Volker StiehlHi Bernd, mit was kabbeln wir uns denn dann in Zukunft?
Ich stimme dir auch in den meisten Punkten zu. BPEL wird keine Renaissance mehr erleben, wird aber eben auch nicht sofort aussterben. Da bleibt zum einen das Erbe, zum anderen müssen Produkte auch erstmal BPMN 2.0 vollständig umsetzen und die Kinderkrankheiten überwinden. Die Entkopplung von Web services ist konzeptionell gut und richtig, trotzdem wird man in der Praxis mit BPMN 2.0 auch noch Web services orchestrieren wollen (idealerweise gleich in Kombination mit anderen Technologien). Das birgt einiges an Komplexität, die Tooling und Middleware hoffentlich weitgehend vor dem Anwender verstecken. Da sind noch einige technische Hürden zu nehmen bis das technische Refinement mit BPMN 2.0 besser (im Sinne von Umfangreicher) und einfacher (guter Toolsupport) wird als derzeit möglich mit BPEL. Und: BPEL (die guten Eigenschaften) lebt natürlich weiter in BPMN 2.x 
@Thorsten: Wenn technische Integrationsszenarien “prozessartig” ablaufen, hängt da nicht immer eine fachliche Anforderung hinter? Ich stimme zu, dass ein fachlicher Prozess nicht auf “Teufel komm raus” als Ganzes technisch umgesetzt werden soll/muss. Aber letztlich führt ein technisches Refinement von fachlichen Prozessen doch immer (zumindest in SOAs) zu prozessartigen Integrationsszenarien. Insofern: Nein, ich will in BPEL keine fachlichen Modelle erstellen, aber ja, ich will mit BPEL fachliche Modelle oder sinnvolle Teile davon ausführbar machen, in dem ich sie auf Intergationsszenarien herunterbreche. Das ist nicht unbedingt BPEL-spezifisch, mit jBPM mache ich das gleiche in dem ich in Java implementierte Geschäftsfunktionen prozessartig integriere.
2009-11-19 um 2.17 pm Uhr. Verfasst von Tammo van LessenIch denke, dass die Hersteller von schon exisitierenden WMS oder BPMS nicht einfach Ihre Engine auf die direkte Ausführung der neuen Serialisierung umstellen werden. Einfacher wird es sein, einen Transformer von BPMN 2.0 in das eigene Serialisierungsformat zu schreiben. Neue Systeme werden sich sicher an der BPMN 2.0 orientieren.
2009-11-21 um 12.13 am Uhr. Verfasst von Martin BartonitzDa beides passieren wird, sehe ich wie Du, dass BPEL auf Dauer (5 Jahre?) den wenigen Atem, den es bisher holen konnte, endgültig auszuhauchen wird.
Hallo zusammen. Jetzt möchte ich auch endlich antworten, hat leider etwas länger gedauert.
@Volker: Ich habe bisher auch keine grossen oder gar erfolgreichen BPEL-Projekte gesehen, eher davon gehört
Daher habe ich jetzt kein aus dem Leben gegriffenes Beispiel. Ich glaube, dass es schon Use Cases gibt, bin aber prinzipiell deiner Meinung, dass man die auch mit BPMN 2.0 erschlagen können wird. Wobei es vielleicht aber auch noch ein BPMN 2.1 oder so braucht, um manche Feinheiten hinzubekommen (wenn du mal schaust, was alles noch in der FTF diskutiert wird).
Wobei ich aber auch seit jeher die Meinung vertrete, dass es unterschiedliche Probleme gibt, also auch unterschiedliche Sprachen Sinn machen können!
Aber als Hersteller ohne BPEL-Engine, der dafür bei der BPMN 2.0 Engine vorne dabei ist, braucht ihr euch sicher keine Sorgen machen. Die Zeit wird für euch arbeiten
Ach ja: Es geht auch bei Oracle meines Wissens direkt um die BPMN 2.0 Ausführung. übrigens wird es das im nächsten Jahr auch Open Source bei jBPM geben, auch wenn noch nicht ganz klar ist, bis wann. Ich sehe das alles sehr positiv, BPMN 2.0 erhält viel “Adaption” (leider auf die schnelle kein gutes deutsches Wort eingefallen), mehr als BPEL. Das wird die Sache voranbringen!
@Tammo: Jo, wir werden was anderes finden. Wäre ja zu langweilig, wenn wir einer Meinung sind
Ansonsten grundsätzlich Zustimmung zum Gesagten im ersten Absatz.
Zum zweiten Absatz nicht ganz. Ich sehe einen Unterschied in der Umsetzung fachlicher Prozesse (im Sinne von SOA: Process Services) und einfach dem Zusammenschalten einfacher Services zu neuen Services, normalerweise ohne Zustand (eher Composed Services). Im Web-Service-Umfeld ist letzteres die Domäne für BPEL, vielleicht auch in Zukunft. Denke, das meinte auch Torsten. Bei jBPM sieht es eigentlich anders aus, da hier das Ziel eher die fachlichen Prozesse sind. Will ich “composed services” in der Welt bauen, würde ich einfach Java verwenden.
@Martin: Was die Hersteller intern genau machen sei mal dahingestellt. Ich denke, bei den Meisten wird es aber meiner Einschätzung nach auf eine Engine hinter den Kulissen hinauslaufen, alles Andere wird denke ich zu teuer. Und dass dies grundsätzlich geht, kann man sich Open Source beispielsweise bei der JBoss PVM anschauen (http://www.jboss.org/jbossjbpm/pvm/). Und wenn das gut funktioniert, bleibt BPEL vielleicht länger erhalten, weil keine grosse Sache für den Hersteller. Und das ist zumindest im Sinne der Wartung interessant, also für – Achtung -: “Legacy BPEL-Anwendungen” (das schreibt sich schön
). Aber aus Markt/Kunden/Projektsicht wird es denke ich nicht mehr lange nachgefragt.
Wobei man natürlich auch nicht vergessen darf, dass sich (leider) nicht jeder auf unserem Blog, den einschlägigen Konferenzen oder in guter Fachliteratur tummelt, somit hat sowas ja immer ne gewisse Verzögerung.
Ach ja, und manche BPEL-Hersteller und Verfechter zucken ja auch noch und sind noch nicht sehr einsichtig, z.B.: http://architects.dzone.com/articles/which-simpler-bpmn-or-bpel. Das muss ich dringend noch in einem eigenen Blog-Post beantworten
2009-12-02 um 9.52 am Uhr. Verfasst von Bernd RückerOracle wird in der Tat in Kürze eine Engine mit “joined runtime core” rausbringen. Die kann dann BPEL _und_ BPMN ausführen. Wobei man dann zur Laufzeit wohl nur eine Sicht haben soll, sprich für das Monitoring soll es egal sein, welche Sprache gerade läuft, weil es wirklich nur eine Engine ist. So der Plan…
2009-12-03 um 3.00 pm Uhr. Verfasst von Torsten Winterbergübrigens (sorry, ich weiss leider nicht, wie ich auf einer schweizer Tastatur einen grossen Umlaut oder das sz hinbekomme) hat Bruce Silver in seinem Blog den “Which is simpler”-Post schon treffend beantwortet: http://www.brsilver.com/wordpress/2009/11/19/bpmn-vs-bpel-are-we-still-debating-this/
2009-12-04 um 9.39 am Uhr. Verfasst von Bernd Rücker