BPEL – die unumstrittene SOA-Königin
Eine ausgereifte und funktionierende Service Oriented Architecture (SOA) hat oft ein Geheimnis: eine solide Beschreibungssprache, die Business und IT mittels einer zentralen Engine verbindet. Meistens heißt sie BPEL.
Über die Business Process Execution Language (BPEL) herrscht Klarheit bei den SOA-Firmen. Sie ist grundsolide und bislang unersetzbar – dennoch gibt es beim Einsatz einiges zu beachten. Denn die Missverständnisse drumherum sind verheerend.
Erstens wird mit BPEL keine Anwendung im herkömmlichen Sinne geschrieben. Dieses weit verbreitete Vorurteil nervt die Berater, seit sie beim Implementieren von Lösungen für SOA helfen. Es geht vielmehr darum, eine bestimmte Menge von Services, die innerhalb oder außerhalb eines Unternehmens vorliegen, in eine Ablaufreihenfolge zu bringen. Diese Reihenfolge wiederum wird durch den umzusetzenden Geschäftsprozess bestimmt. Doch beginnen wir von vorn.
Vielstimmiges Orchester
BPEL ist nach Definition von Torsten Winterberg, Senior Consultant beim Beratungshaus und Oracle-Partner Opitz Consulting, ein wichtiger Punkt, wenn nicht sogar der zentrale Bestandteil der Orchestrierung aller Prozesse: “BPEL bietet als XML-basierte Sprache eine sehr einfache Möglichkeit, durch die Orchestrierung von Web Services die Geschäftsprozesse eines Unternehmens abzubilden. Das heißt dann Service Orchestration, und damit ist die Kernidee von BPEL auch schon erläutert.”
Als Orchestrierung der wiederverwendbaren Services bezeichnen die Experten die Bestimmung ihrer Ablaufreihenfolge. Diese wird durch den Geschäftsnutzen bei Bedarf ständig neu bestimmt, die Services werden unabhängig implementiert und stehen so einzeln für den Bau eines Geschäftsprozesses zur Verfügung. Prozesse können dabei lauten: Lieferung, Lagerhaltung und ähnliche Alltagsaufgaben im Unternehmen.
BPEL dürfe aber nicht als eine Folge von Befehlen verstanden werden, sagt Winterberg. Die Sprache fungiere vielmehr innerhalb der Ablaufumgebung als Instrument für die Auslösung des mehrfach verwendeten ‘Invoke’-Befehls. Dieser startet durch Aktivierung ein Programm, einen Ablauf, eine Routine oder Funktion. In diesem Falle ruft er einen bestimmten Prozess zu gegebener Zeit auf und macht ihn unternehmensweit verfügbar.
Weg mit der IT-Fachidiotie
Dabei räumte der Senior Consultant aber mit einem häufigen Missverständnis auf. “Bei vielen Entwicklern hat sich die Meinung festgesetzt, dass der Begriff Web Service mit SOA gleichzusetzen sei”, kritisiert er. Das sei aber eine klassische Fehleinschätzung, die den Aufbau unnötig erschwere. Denn SOA sei ein “Architekturparadigma, eine Idee davon, wie Anwendungen in sehr naher Zukunft aussehen sollen”. Und dabei werde auf präzise Aussagen über Technik zunächst verzichtet. Das sei auch sinnvoll, da SOA länger halten soll als die Technik, die darauf aufsetzt. “Die Architektur, der die in einem Unternehmen verwendeten Technologien untergeordnet sein müssen, spielt eine viel dauerhaftere Rolle”, betont Winterberg. “Deshalb können einzelne Technologien bei fortschreitender Entwicklung einfach ersetzt werden, die Architektur aber bleibt bestehen.”
Dem folgend beschreibt er, dass die Nutzung von Web Services nur eine von vielen Möglichkeiten ist, wie SOA aufgesetzt werden kann. “Manche Aufgaben, gerade im High Performance Computing, benötigen nicht webbasierte Dienste; das heißt, sie sind heute mit Web Services kaum zu schaffen, dennoch können und sollten sie in eine SOA einbezogen werden, eben über andere Funktionen, die wiederverwendbar sind.”
Web Services sind also nicht immer die richtige Wahl – auch wenn die Standardisierung hierbei schon sehr weit fortgeschritten ist, was den Einsatz der Technikaspekte attraktiv macht. Jedoch müssen laut Winterberg ausnahmslos alle Services “so aussehen wie Web Services”, um von der BPEL angesprochen zu werden. Und zumindest die größeren Anwenderunternehmen haben heute mit IBM WebSphere oder Oracles BPEL Process Manager die Beschreibung im Hause.
