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.
Um also auch nicht webbasierte Services anzusprechen, müssen die Services sich so verhalten wie Web Services – die Branche spricht hierbei von einem erweiterten Service. Dabei hilft einer der ältesten echten Standards, die bei SOA vorkommen: die Web Services Description Language (WSDL). Bei IBM heißt sie zwar Web Services Development Language, gemeint ist aber jedes mal eine Schnittstellenbeschreibung, die die abstrakten Eigenschaften eines Services aufzeigt. Sie ermöglicht es jedem Service, sich als Web Service darzustellen, und damit von der BPEL als SOA-taugliche Funktion erkannt zu werden. Erst dann kann der Service seinen Part im Orchester der neuen Architektur spielen.
Diese anderen Services sind laut Winterberg beispielsweise konkrete Funktionen oder Teilfunktionen, wie sie in Fachabteilungen vorkommen. Oft würden sie von Anwendern gar nicht als IT-ähnlich erkannt, so der Berater. “Also: Ein erweiterter Service ist ein Service, dessen Schnittstelle sich mit WSDL beschreiben lässt. Auch die Methoden einer Java-Klasse sind durch WSDL SOA-tauglich, sie können also als Service angesprochen werden”, fasst er zusammen. SOA funktioniere dank BPEL unabhängig von der jeweiligen Ausgestaltung der Hersteller, weil WSDL die Services in jedem Falle in der BPEL-Engine lesbar macht.
Business bestimmt das Tempo
Rolf Scheuch, stellvertretender Vorsitzender der Deutschen Oracle Anwendergruppe DOAG, legt unabhängig von Technikfragen großen Wert auf den Gedanken der Geschäftsprozesse. Gerade deshalb betont er die Bedeutung von Engines, die die einzelnen definierten Prozesse über verschiedene Anwendungen hinweg korrekt ausführen und Änderungen verfolgen. Gerade bei lang laufenden Prozessabfolgen dürfe die Rückmeldung durch Monitoring und Controlling nicht zurücktreten, gibt er zu bedenken. “Eine zentrale Instanz, beispielsweise eine BPEL-Engine, erscheint sehr sinnvoll”, so Scheuch.
Schließlich seien die Treiber die Geschäftsprozesse. Einzelne Prozessschritte werden “optimalerweise durch einzelne Services abgehandelt.” BPEL fasse dabei die Geschäftsprozesse zusammen, damit sie ablauffähig sind. “Das ist der größte Benefit aus dem Gebrauch von BPEL: Prozesse sind lauffähig und können überwacht werden”, fasst Scheuch zusammen. Zudem würden Workflow- und Integrationsideen mit abgehandelt. Er versteht deshalb die Sprache als notwendige Ergänzung von Geschäftsprozessmanagement (BPM). “Schließlich müssen die technischen Artefakte ja irgendwohin – genau hier setzt BPEL an”, sagt er.
Sieht also ganz so aus, als stelle sich der Einsatz von BPEL innerhalb einer SOA als ein “Muss” dar. Auch die Unterstützung der Beschreibungssprache seitens großer Hersteller wie IBM, Software AG, Microsoft, Oracle und anderen scheint gesichert. Doch gibt es andere Wege? Nach Meinung von Rolf Scheuch gibt es die sehr wohl, wenn auch mit Einschränkungen. Diese Alternative werde deutlich wenn man sich beispielsweise die Funktionsweise von ‘jBPM’ ansieht, einer BPEL-Engine von JBoss.
jBPM heißt Java Business Process Management und geht auf ein Projekt zurück, das von JBoss betrieben und weiterentwickelt wurde. Es ist eine kleine Engine für Business Process Management (BPM) auf Open-Source-Basis, die SOA auch in kleinen Unternehmen realisierbar machen soll. jBPM wird oft als eine Schnittstelle zwischen den Anwendern, Applikation und Services bezeichnet.
Ist Java der direktere Weg?
Die Engine stützt sich auf BPEL, doch nicht ausschließlich. Mit ‘jPDL’ unterstützt sie auch ein prozessorientiertes Programmiermodell auf Java-Basis. Es vereint Java mit deklarativen Programmiertechniken und erlaubt Anwendungsentwicklern, ihre Software mithilfe von Prozessdiagrammen zu strukturieren. Diese Methode soll laut JBoss die Kommunikation zwischen Technikern und Business-Leuten erleichtern.
jBPM wird gern zusammen mit einem passenden Applikationsserver von JBoss angeboten, ist aber auch in jedem anderen Java-fähigen Applikationsserver lauffähig. Bei einem Betrieb mit einem JBoss-Appserver können Nutzer auf eine nahtlose Ausführung vertrauen, weil Services und Engine in einem Transaktionskontext ausgeführt werden. Das soll bei Fehlern oder Änderungen einen leichteren Rollback erlauben. JBoss versteht die Engine dabei nicht als Alternative, sondern als eine mittelstandstaugliche Version einer BPEL-Engine.
Entgegen einigen Befürchtungen nach dem jüngsten Zukauf von JBoss durch den Linux-Distributor Red Hat, soll jBPM weiter existieren. “Alle Produkte der JBoss Enterprise Middleware Suite, eingeschlossen JBoss jBPM, werden weiterhin von JBoss als einer Abteilung von Red Hat entwickelt und unterstützt werden”, das bestätigte Shaun Connolly, Vice President of Product Management von JBoss.
Einstweilen gibt sich die Technik versöhnend: Die neue jBPM-Version wird im September noch BPEL Version 1.1 unterstützen, etwas später im Jahr soll die Unterstützung für die brandneue Version BPEL 2.0 vorliegen. Damit präsentiert sich JBoss als Vorreiter, wenn es um massentaugliche SOA-Lösungen auf Open-Source-Basis geht, die trotzdem mit den Welten der großen Hersteller kompatibel ist – das hofft zumindest Pierre Fricke, JBoss Director of Product Management.
