Eclipse BPEL Designer: Grafischer Editor zum Modellieren, Deployen, Testen und Debuggen von Geschäftsprozessen

Das richtige Öl für die Badewanne

Philipp Tiedt

Stellen Sie sich vor, Sie betreiben einen Online-Shop, der Badewannenduftöle übers Internet verkauft. Ihre Lieferanten sind überall auf der Welt verteilt und benutzen unterschiedliche Technologien (Java, C++, Cobol) für den Ablauf ihrer Geschäftsprozesse. Um mit Ihren Kunden und Partnern erfolgreich arbeiten zu können, brauchen Sie eine Technologie, die das Problem der Heterogenität in den Griff bekommt. Des Weiteren müssen Sie Geschäftsprozesse entwickeln, die die Abläufe in Ihrem Unternehmen automatisieren. Beim Modellieren dieser Prozesse kann Ihnen ein grafisches Tool einiges an Arbeit abnehmen und entscheidene Vorteile bringen. Ein solcher Geschäftsprozess-Editor lässt sich jetzt bequem über den Eclipse-Update-Mechanismus in Ihre Entwicklungsumgebung einbinden.

Der Geschäftsprozess-Editor basiert auf einem Standard zum Orchestrieren von kleinen Funktionseinheiten. Dieser Standard heißt Business Process Execution Language (WS-BPEL) und wurde von Unternehmen wie z.B. BEA, IBM, Oracle und SAP ins Leben gerufen (www.oasis-open.org). Die Schnittstellen Ihrer Partner können in einer einheitlichen Schnittstellenbeschreibungsprache (Web Service Description Language, WSDL) beschrieben werden und erlauben es somit, unabhängig von der verwendeten Implementierungssprache mit Ihren Partnern zu kommunizieren. Eine beliebig implementierte Funktionalität, deren Schnittstelle mittels WSDL beschrieben wird, nennt man Web Service. Bieten also alle Ihre Partner Web Services an, so brauchen Sie diese nur noch sinnvoll zusammenzuschalten, und Ihre Geschäftslogik ist modelliert.

Der Eclipse BPEL Designer ist ein Open-Source-Projekt der Eclipse-Community, welches von IBM und Oracle ins Leben gerufen wurde. Der Sourcecode ist frei zugänglich und kann somit beliebig erweitert und angepasst werden. So gibt es beispielsweise einen Extension Point, der es erlaubt, BPEL Engines verschiedener Hersteller (z.B. Active BPEL, WebSphere Process Server, JBoss etc.) mit dem Editor zu integrieren. Zum aktuellen Zeitpunkt kann der BPEL Designer bereits installiert und zum Modellieren von Geschäftsprozessen eingesetzt werden. Jedoch ändert sich der Code ständig und neue Funktionalitäten kommen hinzu. Einen releasefähigen Treiber gibt es im Moment noch nicht. Auf der BPEL Designer-Projektseite (www.eclipse.org/bpel) können Sie sich detailliert über den Milestone-Plan und aktuelle News informieren.

Aufsetzen der Umgebung

Es gibt zwei Möglichkeiten, Ihre Umgebung für den BPEL Designer aufzusetzen. Die komfortablere Variante ist das Installieren über den Eclipse-Update-Mechanismus. Wenn Sie jedoch den aktuellsten Codestand und die aktuellste Funktionalität ausprobieren möchten, empfiehlt es sich, den Quellcode aus dem Eclipse CVS zu laden und selbst zu bauen. In beiden Fällen benötigen Sie folgende Vorraussetzung, damit der Editor einsetzbar ist:

  • Eclipse Platform 3.2
  • Eclipse Modeling Framework (EMF) 2.2
  • Graphical Editing Framework (GEF) 3.2
  • Java EMF Model Runtime Driver 1.2
  • Web Tools Platform 1.5
  • J2EE Standard Tools 1.5

Die aufgelisteten Komponenten können einzeln von der Eclipse-Projektseite heruntergeladen werden (www.eclipse.org) oder über die in Eclipse 3.2 eingebaute Callisto Update Site installiert werden.

Zum schnellen Einstieg in den BPEL Designer gibt es zwei vorgefertigte Beispielprozesse, die jeweils in einem kompletten Eclipse-Projekt inklusive allen benötigten Zusatzdateien (WSDL) vorliegen. Die Beispiele kann man direkt von der Projektseite herunterladen und in den Workspace importieren. Alternativ befinden sich die Beispielprojekte im Eclipse CVS in der entsprechenden BPEL-Komponente. Die CVS-Zugangsdaten sind :pserver:anonymous@dev.eclipse.org:/cvsroot/technology
Eine einfache Bestellanfrage

Um einen ersten Eindruck zu gewinnen, schauen wir uns einen einfachen BPEL-Prozess an. Nehmen wir an, ein Kunde möchte wissen, ob ein bestimmtes Duftöl gerade lieferbar ist. Sie haben drei Partner, jeweils einen in Afrika, Europa und Asien, um Produkte von verschiedenen Kontinenten anbieten zu können. Je nach Produktwunsch Ihres Kunden würden Sie die Anfrage an einen Ihrer drei Partner weiterleiten.

Unser Prozess beginnt mit dem Emfpang einer Anfrage. Nehmen wir einfach an, es handelt sich hierbei um eine Produktnummer. Als Nächstes möchten wir herausfinden, welcher Lieferant dieses Produkt herstellen und liefern kann. Dafür rufen wir einen Web Service auf, der anhand der Produktnummer das Produktionsland ermitteln kann. An dieser Stelle verzweigt sich unser Prozess.

Unsere drei Partner bieten jeweils einen Web Service an, mit dessen Hilfe wir erfragen können, ob sie ein bestimmtes Produkt liefern können. Wir rufen je nach Produktionsland den entsprechenden Web Service unseres Partners auf. Am Ende des Prozesses liefern wir die Antwort zurück. Schon dieses einfache Beispiel erfordert ein recht komplexes BPEL-File. Der BPEL Designer stellt jedoch den Kontrollfluss sauber und übersichtlich dar.

Knoten und Kanten

Schauen wir uns die einzelnen Teile des Editors etwas genauer an. Abbildung 1 zeigt den BPEL Designer mit all seinen Bestandteilen. Die große weiße Fläche in der Mitte ist die Arbeitsfläche, auf der Prozesse modelliert werden können. Ein Prozess besteht typischerweise aus Knoten und Kanten, ähnlich einem Flussdiagramm. Die einzelnen Prozessknoten sind durch simple Rechtecke dargestellt. Die Rechtecke sind mit einem Bildchen und einer Beschreibung gekennzeichnet, sodass der Prozess verständlich dargestellt werden kann. Die Prozesskanten werden durch kleine Pfeile zwischen den Knoten dargestellt. Links von der Arbeitsfläche befindet sich die Palette, von der man einzelne Knotentypen auf die Arbeitsfläche ziehen kann. Generell unterscheiden wir drei Arten von Knoten: Aktivitäten, Kontrollstrukturen und Fehlerknoten.

Abb. 1: Ein Bestellanfrageprozess

Aktivitäten sind Knoten, die eine Aktion hervorrufen, zum Beispiel den Aufruf eines Web Service. Kontrollstrukturen werden benutzt, um den logischen Ablauf von Aktivitäten zu steuern, beispielsweise, ob Aktivitäten parallel, sequentiell oder in einer Schleife ablaufen. Fehlerknoten dienen dem Werfen von Fehlern während eines Prozesses. Das ähnelt dem Werfen von Exceptions, das wir aus der Java-Welt kennen. In diesem Kontext gibt es natürlich auch Mechanismen, um Fehler zu behandeln. Rechts von der Arbeitsfläche befindet sich die Ablage. In der Ablage befinden sich Objekte, die nicht direkt als Teil des Prozessflusses angezeigt werden, zum Beispiel Prozessvariablen und Partner. Unterhalb der Arbeitsfläche finden wir die Eigenschaften-Sicht, mit deren Hilfe wir Einstellungen des jeweils angewählten Objektes verändern können. In unserem Beispiel sehen wir die Detaileinstellungen für den Web-Service-Aufruf an unseren Hersteller aus Afrika. Aufgerufen wird die Operation „istArtikelLieferBar“. Wir übergeben eine Prozessvariable, in der die Produktnummer gespeichert ist. Das Ergebnis speichern wir in der Prozessvariablen „IstLieferbar „. Auf der linken Seite sehen wir weitere Reiter, um andere Einstellungen zu verändern. Mit dieser Aufteilung lassen sich beliebig komplexe Prozesse modellieren. Wenn der Platz mal nicht reicht, helfen die Zoom-Werkzeuge links unten in der Palette beim Einstellen der richtigen Ansicht. Außerdem lässt sich der Prozess auch bequem als Baum in der Outline-Sicht anschauen.

Abb. 2: Prozess-Outline
Einen neuen Prozess anlegen & deployen

Für unseren Online-Shop brauchen wir natürlich weitere Geschäftsprozesse. Zunächst legen wir über einen Wizard ein neues BPEL-Projekt an (FILE | NEW | PROJECT …| BPEL 2.0 | BPEL PROJEKT). Wichtig ist hierbei, im zweiten Wizardschritt die BPEL 2.0-Fassette auszuwählen. Die Facette konfiguriert das Projekt entsprechend und erlaubt, BPEL-Prozesse später auf entsprechende Engines zu deployen. Neue Prozesse legt man am besten über den BPEL Wizard an. Der Wizard befindet sich in der „New“-Kategorie unter FILE | NEW | OTHER … | BPEL 2.0 | NEW BPEL PROCESS FILE. Um einen Prozess anzulegen, muss man, wie in Abbildung 3 gezeigt, einen Namen und einen Namensbereich (Namespace) angeben. Zusätzlich kann man eine von drei Vorlagen verwenden, nach deren Muster entweder ein Anfrage-Antwort-Prozess (Synchronous Process), ein Prozess mit einfacher Anfrage (Asynchronous Process) oder ein leerer Prozess erstellt wird.

Abb. 3: Einen neuen Prozess anlegen

Im zweiten Schritt des Wizards wird nun noch das Projekt bestimmt, in dem der Prozess erstellt werden soll. Zusätzlich zum Prozess wird auch ein WSDL-Interface angelegt, durch das der Prozess später aufgerufen werden kann. Nehmen wir an, wir entscheiden uns für einen Anfrage-Antwort-Prozess, dann sieht das Ergebnis wie folgt aus. Der generierte Prozess besteht aus einer Receive-Aktivität (Empfangen) und einer Reply-Aktivität (Antworten). Dieses Gerüst können wir nun erweitern und zwischen Empfangen und Antworten unsere Geschäftslogik implementieren.

Abb. 4: Generierter synchroner Prozess

Ist der Prozess einmal fertiggestellt, wollen wir ihn auch auf einem Server laufen lassen. Dazu muss ein Server mit BPEL Engine in der Workbench definiert sein. Aktuell gibt es eine prototypische Anbindung an die Active BPEL Engine, die für Testzwecke verwendet wurde. Eine genaue Anleitung zum Anbinden der Engine findet sich unter Links & Literatur am Ende dieses Artikels. Nachdem man in der Serversicht einen Active BPEL Server definiert hat, kann man die im Workspace existierenden Prozesse deployen. Dazu öffnet man mit einem Rechtsklick das Kontext-Menü des Servers und wählt ADD AND REMOVE PROJECTS …. Daraufhin erscheint ein Dialog, der es ermöglicht, einzelne Prozesse dem Server hinzuzufügen bzw. zu löschen. Um die Prozesse letztendlich zu deployen, wählt man im Kontext-Menü des Servers PUBLISH, woraufhin Informationen und Dateien generiert werden, die zum Deployment benötigt werden.

Abb. 5: Active BPEL Server – Projekte hinzufügen und löschen
Erweiterbare Architektur

Schauen wir uns nun die Architekur des BPEL Designer an. Prinzipiell setzt sich das Projekt aus drei Komponenten zusammen: dem BPEL Model, dem BPEL User Interface und der BPEL-Runtime-Anbindung. Abbildung 6 zeigt eine grobe Übersicht der Architektur und die Abhängigkeiten zu anderen Eclipse-Projekten.

Abb. 6: BPEL Designer-Architektur

Grundlegende Konzepte werden hier aus GEF übernommen. Die UI-Komponente muss jedoch für die anzuzeigenden Modeltypen die genaue Darstellung (Figuren, Verbindungslinien, Verbindungspunkte usw.) implementieren. Die vorher besprochenen Eigenschaftsseiten werden auf dem Tabbed Properties View Framework implementiert, welches seit Eclipse 3.2 M5 Teil der Eclipse-Plattform ist. Dieses Framework erlaubt es, komplexe Eigenschaftsseiten aus SWT Widgets zu implementieren. Standardmäßig erlaubte die Eclipse-Eigenschaftensicht nur das Anzeigen von Eigenschaften in Tabellenform. Die BPEL Designer-UI-Komponente implementiert verschiedene Eigenschaftsseiten, die schließlich über einen Extension Point mit dem jeweiligen Model-Typen verknüpft werden. Zum Manipulieren des Models wird ein so genanntes Command-Framework benutzt. Alle Änderungen werden über dieses Framework in Form von Commands ausgeführt. Somit ist gewährleistet, dass Änderungen rückgängig gemacht bzw. wiederholt werden können. Die Runtime-Komponente ist schließlich dafür verantwortlich, einen BPEL-Prozess auf einem Server zu deployen. Sie basiert auf dem WTP-Projekt und kann somit die Anbindung an verschieden BPEL Engines implementieren. In Zukunft können wir weitere Komponenten, z.B. für Debugging und Tests, erwarten.

BPEL Engines

Der Markt für BPEL Engines ist groß, dementsprechend bietet sich eine große Auswahl an Alternativen. Es gibt kommerzielle, aber auch Open Source BPEL Engines. Zu den Hauptwettberwerbern zählen IBM, Oracle und JBoss. Namhafte Engines sind:

  • Active BPEL
  • IBM WebSphere Process Server
  • Oracle Business Process Manager
  • JBoss Workflow Engine

Die Architektur des BPEL Designer macht es relativ einfach, existierende BPEL Engines zu integrieren, und so ist es zu erwarten, dass der prototypischen Active BPEL-Anbindung bald weitere folgen.

Eine neue Aktivität

Vielleicht stellen wir irgendwann fest, dass uns die BPEL-Standard-Aktivitäten zum Modellieren unserer Prozesse nicht genügen, und wir benötigen eine Funktion, mit der wir schnell und einfach E-Mails an bestimmten Stellen im Prozess versenden können, ohne über einen Web Service zu gehen. Die BPEL-Spezifikation erlaubt Erweiterungen solcher Art. Voraussetzung ist es jedoch, dass eine BPEL Engine eine Erweiterung versteht, um diese Möglichkeit erfolgreich ausführen zu können. Auch der BPEL Designer ist, wie fast alle Eclipse-Projekte, an vielen Stellen erweiterbar und bietet Extension Points an.

Angenommen, wir haben eine BPEL Engine, die unsere E-Mail-Funktionalität unterstützt, so müssen wir noch folgende Erweiterungen im BPEL Designer vornehmen, damit wir erfolgreich modellieren können:

  • Model-Erweiterung: Wir müssen eine Model-Erweiterung einführen, die unsere Funktionalität repräsentiert, und sicherstellen, dass unser neuer Model-Typ vom BPEL Designer richtig gelesen und gespeichert werden kann.
  • grafische Repräsentation und Funktionalität: Unsere Aktivität muss im BPEL Designer erstellt und dargestellt werden können.
  • Veränderbarkeit der Einstellungen: Letztendlich wollen wir auch die Einstellungen unserer E-Mail-Funktionalität verändern und zum Beispiel die Empfänger und den Inhalt bestimmen. Dafür müssen wir eine Einstellungsseite implementieren und diese mit unserer Model-Erweiterung verknüpfen.

Um diese Erweiterungen vornehmen zu können, bietet der BPEL Designer Extension Points auf Model- und UI-Ebene an. Detaillierte Informationen zu den Extension Points finden Sie unter www.eclipse.org/bpel/developers/extension_points.php.

Noch am Anfang …

Nachdem wir nun die grundlegenden Konzepte kennen gelernt haben, können wir uns ein Bild des aktuellen Funktionsumfangs des BPEL Designer machen. Es können bereits Prozesse modelliert und prototypisch auf einem Server deployt werden. Funktionalitäten wie Debugging und Testing sind zu einem späteren Zeitpunkt zu erwarten. Der BPEL Designer ist so konzipiert, dass er auch der Erweiterbarkeit des BPEL 2.0-Standards entspricht. Jedoch sind zum aktuellen Zeitpunkt noch nicht alle Features implementiert.

Es empfiehlt sich auf jeden Fall jetzt schon mal, die vorhandenen Beispielprozesse aus dem CVS zu laden, und ein bisschen mit dem Editor und seiner Funktionalität herumzuspielen. Freuen wir uns also auf ein hoffentlich baldiges erstes Release, um unser Duftwassergeschäft endlich effizient und mit Open Source modellieren zu können.

Philipp Tiedt ist derzeit als Software Ingenieur bei der IBM Forschung & Entwicklung GmbH tätig und arbeitet dort auf dem Gebiet Business Integration Tools. Er ist Autor verschiedener Fachartikel und Betreuer diverser Studienprojekte im Bereich Eclipse. Tiedt blogt auf philipptiedt.blogspot.com und www.planeteclipse.org.

Geschrieben von
Philipp Tiedt
Kommentare

Schreibe einen Kommentar

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