BPEL ist für Prozess- und Workflow-Techniken das, was SQL für die relationalen Datenbanken ist!", so steht es im aktuellen Präsentationsmaterial von Oasis. Ob die inzwischen von mehreren führenden Herstellern mit BPEL-Engines unterstützte Orchestrierungs- und Integrationssprache diesen Status erreichen wird, muss die Zukunft zeigen - mit den im März abgeschlossenen Spezifikationen der Version 2.0 dürfte der Standard diesem Ziel jedoch ein ganzes Stück näher kommen.

Web-Services für Aktivitäten, XML-Dokumente für Nachrichten

Bei WS-BPEL handelt es sich um eine ausführbare, XML-basierende Sprache zur Beschreibung von Geschäftsprozessen, deren Aktivitäten durch Web-Services implementiert werden und deren Nachrichtenaustausch über XML-Dokumente erfolgt. Das Besondere daran: WS-BPEL bietet eine homogene Syntax für die Ablaufbeschreibung und den Datenzugriff auf XML-Dokumente. Und es enthält Elemente, die speziell auf die Ablaufproblematik langlaufender Geschäftsprozesse mit mehreren Partnern zugeschnitten sind. So können die Aktivitäten eines Geschäftsprozesses in Scopes, das heißt in kontextorientierten, transaktionalen Einheiten zusammengefasst werden. Für den Fehlerfall, bei dem bereits abgeschlossene Scopes zurückgesetzt werden müssen - man spricht von Kompensation - , enthält WS-BPEL mächtige syntaktische Konstrukte. Hier ist WS-BPEL anderen Programmiersprachen klar überlegen - in der Theorie.

Neue Spezifikation ist doppelt so umfangreich

In der Praxis war die Semantik von WS-BPEL 1.1, deren Veröffentlichung fast vier Jahre zurückliegt, an vielen Stellen unscharf. Aus Sicht der Anwender war oft unklar, ob ihr BPEL-Code auf den BPEL-Engines verschiedener Hersteller zu gleichen Prozessabläufen führt. Oasis, die für die Standardisierung verantwortliche Organisation, hat diesen Bedarf erkannt: Die Spezifikation von WS-BPEL 2.0 ist doppelt so umfangreich wie die der Vorgängerversion. Neue Sprachkonzepte machen dabei nur einen Teil des Zuwachses aus. Vereinfachungen, aber vor allem die Präzisierung vorhandener Konzepte bilden den Kern der neuen Version. Betroffen ist davon auch der zentrale Ansatz der Kompensation.

Klarheit über dynamisches Verhalten

WS-BPEL 2.0 stellt klar, wie der Kompensationsmechanismus, der ohne die klassischen verteilten, atomaren Transaktionen auskommt, im Detail funktioniert. Das Update definiert, dass beim Abschluss aller Aktivitäten eines Scopes dessen aktueller Zustand als ein lokaler Schnappschuss festgehalten wird. Diese Momentaufnahme enthält unter anderem die aktuellen Variablen, Partnerverbindungen (Partner-Links) und die so genannten Correlation Sets des Scopes. Letztere sind Datenfelder, die zur Identifizierung von Prozessinstanzen dienen. Zur Kompensation eines Scopes erfolgt eine Kompensationsaktivität. Sie kann auf den Schnappschuss und die aktuellen Zustände der umschließenden Scopes zurückgreifen.

Ergänzend zu der präziseren Formulierung des Kompensationsmechanismus werden in der neuen BPEL-Version mehrere komplexe Kompensationsszenarios behandelt: Klargestellt wird, wie die voreingestellte Fehlerbehandlung mit Kompensation abläuft. Definiert ist auch, welcher Datenzustand bei der Kompensation eingebetteter Scopes genutzt und in welcher Reihenfolge bei der Kompensation geschachtelter Scopes vorgegangen wird. Zudem hat Oasis die Kompensation isolierter Scopes neu geregelt. Hier handelt es sich um Scopes, die gemeinsame Ressourcen verwenden, wobei durch ihre als Isolation bezeichnete Eigenschaft ein kontrollierter konkurrierender Zugriff auf die Ressourcen gewährleistet wird.

WS-BPEL beschreibt den Ablauf von Geschäftsprozessen als strukturierte Aktivitäten. Hier schafft die neue Version mehr Reichhaltigkeit und lehnt sich gleichzeitig stärker an die klassischen Programmiersprachen an: Jetzt gibt es eine <if>-<elseif>-<else>-Aktivität, vorher als <switch>-Aktivität bezeichnet. Die <while>-Aktivität für die bedingungsabhängige, wiederholte Ausführung von Aktivitäten wird durch die neuen Aktivitäten <repeatUntil> und <forEach> ergänzt, wobei <forEach> in zwei Varianten verwendet werden kann: zur Steuerung der seriellen und der parallelen Ausführung von Aktivitäten.

Die genannten Beispiele sind nur einige von zahlreichen Klarstellungen und Erweiterungen im Bereich der Ablaufbeschreibung. Innovationen finden sich dagegen eher auf der Seite der Datenmanipulation, wie folgende Beispiele zeigen.

Elegante Sprachmittel für Datenzugriffe

Eine BPEL-Variable referenziert in Version 2.0 ein so genanntes XML-Infoset, das aus einem oder mehreren XML-Dokumenten besteht. Eine der häufigsten Aufgaben in einer BPEL-Anwendung ist es, im XML-Ergebnisdokument eines Serviceaufrufs spezielle Elemente zu finden und in das XML-Eingabedokument eines nachfolgenden Serviceaufrufs zu kopieren. Für die Suche in XML-Dokumenten gibt es mit XPath eine leistungsfähige Sprache.

Nun lässt sich das Konzept der XPath-Variablen nutzen

In WS-BPEL 2.0 wurde das Konzept der XPath-Variablen eingeführt. Eine XPath-Variable entsteht syntaktisch einfach dadurch, dass einer BPEL-Variablen ein $-Zeichen vorangestellt wird. Das Ergebnis einer Suche kann damit direkt als Ausdruck weiterbenutzt werden. Variablenzuweisungen, die in WS-BPEL durch <assign>-Aktivitäten erfolgen, lassen sich nun ähnlich elegant formulieren wie Zuweisungen in objektorientierten Sprachen.

Für Prozesse, in denen Suchen und Kopieren zum Aufbau von Nachrichten nicht ausreichen, bietet die neue BPEL-Version standardmäßig einen integrierten Ausdruck für die XSLT-Transformation einer XPath-Variablen.

Vereinfachtes Handling von Serviceaufrufen

In der Praxis werden Services oft als elementare EJB 3.0 Session Beans implementiert und das performante Nachrichtenformat Document/Literal verwendet. Nachrichten in diesem Format enthalten genau ein XML-Dokument. In WS-BPEL 2.0 kann eine Variable, die für ein einzelnes XML-Dokument definiert wurde, inline initialisiert und direkt als Ein- und Ausgabe für Serviceaufrufe benutzt werden. Damit entfällt die Auswahl eines einzelnen XML-Dokuments aus dem XML-Infoset einer BPEL-Variablen.

Weitere syntaktische Ergänzungen sind implizite <assign>-Aktivitäten direkt im Aufruf einer Serviceoperation, eine neue explizite <validate>-Aktivität zur Validierung von Variablen gegen ihre XML-Definition und die Möglichkeit zur impliziten Validierung in einer <assign>-Aktivität. Durch Elemente wie die hier exemplarisch beschriebenen wird die Datenmanipulation mit WS-BPEL 2.0 deutlich einfacher.

Auf dem Weg zum Industriestandard

Die Aussichten für WS-BPEL, sich als Industriestandard durchzusetzen, sind aus heutiger Sicht viel versprechend. Treiber in dieser Richtung ist auch der Umstand, dass die Sprache auf einem rekursiven Aggregationsmodell für Web-Services basiert: Die mit WS-BPEL beschriebenen Prozesse verwenden Web-Services und können selbst als Web-Service benutzt werden. Dieses Modell bietet ein hohes Gestaltungspotenzial für Service-orientierte Architekturen. Damit ist die neue BPEL-Version klarer, einfacher, praktikabler, allerdings nicht voll aufwärtskompatibel.