Eine Sprache für SOA – BPEL kennenlernen

BPEL – Standard für technisch ablauffähige Prozesse

BPEL kann als das Instrument gesehen werden, welches innerhalb der Konzeption einer serviceorientierten Architektur zur Automatisierung von Geschäftsprozessen eine Schlüsselfunktion übernimmt. Denn BPEL bietet als XML-basierte Sprache eine sehr einfache Möglichkeit, die Geschäftsprozesse eines Unternehmens durch die Orchestrierung von (Web) Services abzubilden. Diese Aussage liefert auch gleich die Idee hinter diesem neuen Standard: Mit der Sprache BPEL werden keine Anwendungen im herkömmlichen Sinne geschrieben. Vielmehr geht es darum, eine bestimmte Menge von Services, die innerhalb oder außerhalb des Unternehmens vorliegen, in eine Ablaufreihenfolge zu bringen, die durch den umzusetzenden Geschäftsprozess definiert wird. Man spricht in diesem Fall von Serviceorchestrierung. Damit ist die Kernidee von BPEL auch schon erläutert.

Ein Web Service stellt sich nach außen hin über seinen Servicevertrag, also seine WSDL-Beschreibung dar. WSDL steht für Web Service Description Language und beschreibt unter anderem die abstrakten Eigenschaften eines (Web) Services. Betrachtet man reine WSDL-definierte Web Services, so hat man es meist mit zustandslosen Interaktionsmodellen zu tun, Nachrichten werden dabei in der Regel durch synchrone oder unkorrelierte asynchrone Aufrufe übermittelt. Hinter BPEL steckt dagegen ein robusteres Interaktionsmodell, in dem Nachrichten bidirektional in Peer-to-Peer-Konversationen ausgetauscht werden, die vielleicht Minuten, Stunden, Tage oder Wochen andauern. Daher eignet sich BPEL sehr gut für zustandsbehaftete, zeitlich lang laufende Interaktionen.

Erweiterter Servicebegriff

Bei Vielen hat sich die Meinung festgesetzt, dass der Begriff „Web Service“ mit einer SOA gleichzusetzen sei. Dies ist aber eine Fehleinschätzung, die den Aufbau einer SOA nur unnötig erschwert oder gänzlich verhindert. Bei SOA handelt es sich um ein Architekturparadigma, eine Idee davon, wie Anwendungen in sehr naher Zukunft aussehen sollen. Dabei werden (zunächst) keinerlei Aussagen über Technologien getroffen. Das ist ein wichtiger Aspekt, da sich Technologien im Laufe der Zeit (mitunter auch extrem schnell) wandeln, was prinzipiell zu begrüßen ist, da auf diese Weise Innovationen getrieben werden. Die Architektur eines Unternehmens jedoch, der sich Technologien unterordnen müssen, spielt eine dauerhaftere Rolle. Wenn die Architektur tragfähig umgesetzt wurde, können – im Idealfall – einzelne Technologien problemlos ersetzt werden.

Aktuell bieten sich die Web Services zur Implementierung einer SOA an, da der Standardisierungsgrad der einzelnen Teilaspekte (Adressing, Security, Transactions, Policy) sehr weit fortgeschritten ist. Das bedeutet aber lediglich, dass Web Services einen möglichen Kandidaten bei der Implementierung einer SOA darstellen. Niemand jedoch schreibt vor, dass man sich auf die Web-Service-Technologien beschränken müsste. Für viele Aufgaben sind diese auch nicht adäquat, zum Beispiel wenn es bei der Massendatenverarbeitung um Performanceoptimierung geht.

Aus diesem Grund erweitern viele Hersteller ihre BPEL-Produkte dahingehend, dass neben den Web Services auch Services, die zum Beispiel direkt in Java, Enterprise Java Beans (EJB) oder Datenbanken realisiert sind, in den Prozessen verwendet werden können.

Der Mensch greift steuernd in den Prozess ein

BPEL bietet vielfältige Möglichkeiten zur Orchestrierung von Services, die jedoch alle vollautomatisch ablaufen müssen. In der Praxis bedeutet dies, dass für einen Prozess im Vorfeld bereits alle nötigen Parameter ermittelt werden müssen, die diesem dann als Inputparameter übergeben werden. Fehlt in einem Prozessschritt eine wichtige Information, kann sich der Prozess nicht beim Benutzer melden, um die fehlende Information, zum Beispiel die Entscheidung eines Kreditverantwortlichen, nachzufragen. Das ist leider eine sehr starke Einschränkung, da vollautomatisierte Prozesse in der Praxis eher selten vorkommen. Zudem hängen die Inputparameter für einen Prozess oft von vielen Faktoren ab, die vielleicht nur für bestimmte Ablaufzweige im Prozess relevant sein können. Bereits im Juli 2005 haben IBM und SAP daher ein Whitepaper zu diesem Problem veröffentlich, das den Titel „BPEL4People“ trägt. Darin wird festgestellt, dass „Human Interactions“ als ein wesentlicher Bestandteil lang laufender Prozesse anzusehen sind und es werden Vorschläge beschrieben, wie solche menschlichen Prozessinteraktionen in BPEL realisiert werden könnten. Mittlerweile sind aus diesen Vorschlägen zwei weitere Spezifikationen geworden: WS-Human Task beschreibt allgemeine Funktionalitäten zur Einbindung von Menschen und WS-Bpel4People beschreibt die Verwendung von WS-Human Task direkt in BPEL. Aktuell beherrschen fast alle Produkte auf dem Markt proprietäre Umsetzungen der BPEL4People-Idee, die wohl in naher Zukunft auf Basis der nun verfügbaren Spezifikationen eine vereinheitlichte Implementierung anbieten werden.

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.