BPEL - Business Process Execution Language

BPEL Business Process Execution Language Dr. Martin Bartonitz Product Manager SAPERION AG Vorsitzender des Aufsichtsrates: Dieter Matheis | Vorstand: Rudolf Gessinger (Vorstandsvorsitzender), Andreas Kunze | Amtsgericht Berlin-Charlottenburg HRB Nr. 78848 | BPEL - Business Process Execution Language Das korrekte von der OASIS - Organization for the Advancement of Structured Information Standards - in 2004 festgelegte Akronym ist WSBPEL und steht für Web Service Business Process Execution Language in Anlehnung an die anderen Web-Service-relevanten Spezifikationen wie WSDL – Web Service Definition Language. BPEL ist eine XML-basierte, interpretierbare, d.h. von Workflow-Engines ausführbare Programmierspra- che zur Orchestrierung von Web-Services zum Zwecke der Automatisierung von Geschäftsprozessen. BPEL kämpfte in den letzten Jahren mit einigen weiteren Definitionen um die Standardbeschreibung von ausführbarem Code. Mittlerweile gibt es nur noch einen ernsthaften Konkurrenten, die XPDL der WfMC – Workflow Management Coalition. XPDL steht für Process Definition Language mit de X für XML-basiert. 1: Die Grafik zeigt die Zusammenhänge zwischen den wichtigsten Standards rund um BPEL. Der Zeit- strahl ist nicht exakt, wichtig sind hier die Zusammenhänge. WSBPEL verbindet seit 2002 unter der Bezeichnung BPEL4WS die Ideen der kalkülbasierten Sprache XLANG von Microsoft und der Graph-basierten Sprache WSFL - Web Services Flow Language - von IBM. Ein Jahr später wurden die Standardisierungsbemühungen unter das Dach der OASIS gestellt, d.h. der Kreis der mitarbeitenden Firmen ist um weitere wichtige Namen wie BEA, SAP, ORACLE gewachsen. Die aktuelle Version ist 1.1. Die Version 2.0 steht kurz vor der Freigabe. BPEL ist ein Kind des Internet-Hypes Ende der 1990er Jahre. In dieser Zeit wurden verstärkt sogenannte End-to-End-Prozesse zwischen Business-Partnern auf Basis von Web-Technologien umgesetzt. Daraus entwickelt hat sich eine neue Sicht auf Software-Architekturen, mit dem besonderen Schwerpunkt der Agilität. Prozesse über unterschiedliche Plattformen und Applikationen hinweg werden immer schnelle- biger und müssen daher immer schneller angepasst werden. Die Antwort lautet SOA: Service Oriented Architecture. Im Kontext von SOA sind die Services im Wesentlichen Web-Services, allgemein ist jedoch damit gemeint, das Applikationen zukünftig keine Software-Monolithen sein werden sondern in sinnvoll große Services unterteilt werden, deren Business-Logik wo nötig in andere Komponenten eingebunden werden. 21.02.2008 Seite 2 von 7 Der BPEL-Kontext Da BPEL im Zusammenhang mit dem Web entstand, gründet es vorrangig auf weiteren Standards aus die- sem Umfeld. Während viele Autoren die Standards mittels Schichtenmodelle mit bis zu 10 Ebenen darzu- stellen versuchen, schlägt Gartner 2004 eine Netzdarstellung der Abhängigkeiten der BPEL-tangierenden Standards vor. Neben der Nutzung von XML für die Definition eines Prozesses ist in der Grafik klar er- kennbar, wie eng BPEL mit den Ideen der Web-Services verzahnt ist, denn überall dort, wo ein Name mit „WS“ anfängt, ist damit Web-Service gemeint. Abbildung 2: Die Grafik zeigt die Vernetzung der mit BPEL im Zusammenhang stehenden weiteren Standards Grafische Modellierung WSBPEL ist eine rein ASCI-orientierte Beschreibung von zeitlichen Abläufen der Web-Services und kann diese nicht grafisch darstellen. Seit 2005 wird dazu die Modellierungssprache BPMN – Business Process Modeling Language – genutzt. Dabei muss jedoch festgestellt werden, dass dies selbst mit der WSBPEL Version 2.0 nur eine Einbahnstraße ist. D.h. aus der BPMN werden WSBPEL-Definitionen erzeugt. Dage- gen kann aus einer WSBPEL-Definition keine BPMN-Grafik erzeugt werden. Der Grund liegt an den feh- lenden Sprachelementen wie z.B. die Koordinaten oder auch z.B. die BPMN-Elemente Pool und Events. Hier zeigen sich klare Vorteile für den Konkurrenten XPDL der WfMC ab. Mit der Mitte 2005 freigegebe- nen Version 2.0 ist die Sprache genau um diese fehlenden Elemente ergänzt worden, so dass ein bi- direktionaler Austausch zwischen BPMN und XPDL möglich ist. Die BPMN wird unter dem Dach OMG – Object Management Group – vorangetrieben, die auch die grafi- schen Diagramme für ein objektorientiertes Design von Applikationen mittels der UML – Unified Meta Language – vorantreibt. Unterschiede zwischen WSPBEL und XPDL Als unbedarfter Außenstehender könnte man schnell die Frage formulieren: Lassen sich die beiden Stan- dardisierungslager in naher Zukunft zusammen bringen? Da die Motivation für die jeweilige Beschreibungssprachen derzeit noch sehr weit auseinander liegen, ist mit einem Zusammengehen vor dem ersten Jahrzehnt diese Jahrtausends nicht zu rechnen. Während das Lager der BPEL vorrangig dafür Sorge tragen will, dass die einzelnen Funktionsblöcke in Form von Web-Services ordentlich mit einander arbeiten können (Orchestrierung), kümmert sich die XPDL im Schwerpunkt auf das koordinierte Ablaufen von durch Menschen auszuführenden Aufgaben. Letztere stehen immer im Kontext einer Information, die im Schwerpunkt ein unstrukturiertes Dokument 21.02.2008 Seite 3 von 7 einer Akte ist (Case Handling). Die nachfolgende Tabelle zeigt die wesentlichen Unterschiede der beiden Sprach-Definitionen: Merkmal XPDL BPEL Zielsetzung Offener Austausch von Prozeß- Spezifikation von ausführbaren und Definitionen abstrakten Geschäftsprozessen auf (WfMC Interface 1) und Dateiformat für Basis von Web Services BPMN Prozess- „Participants“: Resource, Role, Intern keine Zuordnung von Teilneh- Teilnehmer Org Unit, Human, System mern, Externe im Message Flow über Dynamische Zuordnung mittels Rules “Partner (Links)” während Laufzeit Technische Diverse, z.B. Web Service, EJB, Pojo, Web Services (WSDL) Schnittstellen Script, Rule Binding beliebig Manuelle Tasks Explizite Definition von Aktivitäten als Nicht explizit unterstützt “TaskManual” Modularisierung Unterprozesse werden unterstützt Eingeschränkt möglich durch „scope“ Simulation Enthält Attribute für Time Estimation, Nicht explizit unterstützt Cost Unit u.a. Datenfluss Nur bei Übergabe während Start und Collaboration zwischen parallelen Web Ende eines Subprozesses Services Laufzeitverhalten, Für langlaufende automatische Aktivi- Enthält „fault handler“, “compensati- Problembehand- täten (Teilprozesse) keine expliziten on handler” und „transaction demar- lung Definitionen cation“ Austausch mit Die Version 2.0 enthält neben Koordi- Keine grafischen Elemente, BPMN naten und Shape-Größen die Elemente Nur unidirektionaler Austausch von Pool, Lane, Gateway und Event, d.h. BPMN nach BPEL möglich. bidirektionaler Austausch mit BPMN möglich Tabelle 1: Gegenüberstellung der Merkmale von XPDL und BPEL Eine sehr detaillierte Analyse der Unterschiede zwischen BPEL und XPDL hat Wil van der Aalst auf seiner Web-Site mit dem Titel Workflow-Pattern publiziert. Hier stellt er nicht nur die Unterschiede zwischen den beiden Konkurrenten heraus sonder vergleicht diese noch mit BPMN und UML so den Engines der Hersteller IBM und ORACLE. SAP und IBM haben aufgrund der fehlenden Elemente hinsichtlich der Interaktion mit Menschen eine Er- weiterung für WSBPEL in einem Whitepaper 2005 veröffentlicht. Nach Auskunft eines der Autoren ist a- ber nicht damit zu rechnen, dass diese Erweiterung noch den Weg in die Spezifikation der WSBPEL Ver- sion 2.0 finden wird. Dennoch werden wohl beide Firmen die in dem Whitepaper beschriebenen Erweite- rungen in ihren BPEL Engines einbauen. 21.02.2008 Seite 4 von 7 BPEL-Sprachelemente Die Elemente der WSBPEL lassen sich in drei Gruppen unterteilen, den elementaren Basisaktivitäten, die nicht aus anderen Aktivitäten aufgebaut werden können, den strukturierten Aktivitäten, die aus den e- lementaren Basisaktivitäten zusammen gesetzt werden können u.a. zum Zwecke der Rekursion, und dem Scope, um Gruppen von Aktivitäten Verfahren für Fehler („fault handler“), Ereignisse („event handler“) und zur Kompensation („compensation handler“) im Falle von Abbrüchen zuzuordnen. Die Sprachelemente der Basic Activities sind: assign Zuweisen oder Verändern von Werten zu einer Variablen. empty in einer solchen Aktivität ist nichts tun, kann z. B. dazu verwendet werden, um eine Fehlermeldung zu unterdrücken. invoke Aufruf eines Web Service receive/reply legt fest, ob die Web Service Schnittstelle synchronen oder asynchronen genutzt wird throw Soll ein Fehler nicht den globalen Scope erreichen und damit den Prozesses termi- niert, so kann er mit dem expliziten Signal für eine weitere Fehlerbehandlungen auf- gefangen werden. wait Es wird auf einen Zeitpunkt oder für eine Zeitspanne gewartet.