Performance-Vergleich von BPEL-Engines

Transkript

1 Institut für Architektur von Anwendungssystemen Universität Stuttgart Universitätsstraße 38 D Stuttgart Fachstudie Nr. 63 Performance-Vergleich von BPEL-Engines Carsten Längerer, Fabian Schmitt, Jens Rutschmann Studiengang: Prüfer: Betreuer: Begonnen am: Beendet am: Softwaretechnik Prof. Dr. Frank Leymann Dipl.-Inf. Matthias Wieland 1. August November 2006 CR-Klassifikation: C.4, H.3.4, H.3.5, H.4.1, J.1

2

3 Inhaltsverzeichnis 1 Allgemeines Ablauf und Ziel der Fachstudie Aufbau des Dokumentes Beteiligte Personen Zur Auswahl stehende Workflow-Management Systeme WebSphere Process Server BPEL Unterstützung Voraussetzungen Installation Stuttgarter Workflow Maschine BPEL Unterstützung Voraussetzungen Installation Oracle BPEL Process Manager BPEL Unterstützung Voraussetzungen Installation BizTalk Server 2006 (nicht getestet) BPEL Unterstützung Voraussetzungen Installation jbpm (nicht getestet) BPEL Unterstützung Voraussetzungen Installation Vergleich der Workflow Management Systeme Auswahl der zu testenden Produkte Beschreibung der Performancetests Performance Hardware-Umgebung System für die Workflow Management Systeme System für die Testwerkzeuge Verwendete Testwerkzeuge JMeter SoapUI Modellierung der Prozessmodelle Prozessmodelle der Testprozesse Sequenzieller Invoke synchron...15 Implementierungsdetails Paralleler Invoke synchron...17 Implementierungsdetails Sequenzieller Assign synchron...18 Implementierungsdetails Paralleler Assign synchron...19 Implementierungsdetails Service-Endpunkte Ausführung der Tests Allgemeines Arten der Testläufe...21 I

4 4.1.2 Beschreibung der Ergebnistabellen Sequenzieller Invoke synchron Paralleler Invoke synchron Sequenzieller Assign synchron Paralleler Assign synchron Diagramme Fazit Rückblick Bewertung der Testergebnisse Ausblick Literaturverzeichnis Abkürzungen Listing der BPEL-Prozesse Prozessmodelle für SWoM SeqIn.bpel ParIn.bpel SeqAssign.bpel ParAssign.bpel Prozessmodelle für WebSphere Process Server SeqIn.bpel ParIn.bpel SeqAssign.bpel ParAssign.bpel Prozessmodelle für BPEL Process Manager SeqIn.bpel ParIn.bpel SeqAssign.bpel ParAssign.bpel WSDL des Service Endpunkts WebSphere Application Server BPEL Process Manager...74 II

5 Kapitel 1 Allgemeines Kapitel 1 Allgemeines Mittlerweile gibt es viele verschiedene Implementierungen der Business Process Execution Language [2] (BPEL). Diese unterscheiden sich grundlegend in der unterstützten Menge der im BPEL-Standard enthaltenen BPEL-Konstrukte, der firmenspezifischen Erweiterungen, welche nicht im BPEL-Standard enthalten sind, sowie in der Abarbeitung der einzelnen Prozesse. Letzteres ist ausschlaggebend für die Leistung und wird meist erst erkannt wenn das Produkt schon in Betrieb ist und eine Umstellung auf ein anderes Produkt nicht mehr ohne Weiteres möglich ist. 1.1 Ablauf und Ziel der Fachstudie Im Rahmen dieser Fachstudie wurden drei Produkte hinsichtlich ihrer Performance verglichen. Als erstes mussten drei Produkte aus den auf dem Markt erhältlichen ausgewählt werden. Als nächstes wurde die Testumgebung eingerichtet und die ausgewählten Produkte und ihre Abhängigkeiten in dieser installiert. Der darauf folgende Schritt bestand darin sich in die einzelnen Produkte einzuarbeiten und für jedes Produkt die Testprozesse zu erstellen, was bei den einzelnen Produkten mehr oder weniger einfach war. Zum Schluss erfolgte eine Performance-Messung mit speziell dafür entwickelten Werkzeugen. 1.2 Aufbau des Dokumentes Das erste Kapitel stellt lediglich eine kurze Einführung sowie weitere formelle Informationen bereit. Die ausgewählten Produkte sowie ihre Eigenschaften werden in Kapitel zwei vorgestellt. Dort wird außerdem das Auswahlverfahren behandelt. Die Beschreibungen der Hardware-Umgebung, der Testwerkzeuge und der Testprozesse sowie eine Definition des Begriffs "Performance" sind in Kapitel drei enthalten. Das vierte Kapitel enthält die Ausführung und Auswertung der Testergebnisse. Kapitel fünf schließt das Dokument mit einer Zusammenfassung und Bewertung der Testergebnisse ab. Der Quellcode der getesteten BPEL-Prozesse und der Service Endpunkte befindet sich im Anhang. Performance-Vergleich von BPEL-Engines Seite 1

6 Kapitel 1 Allgemeines 1.3 Beteiligte Personen Auftraggeber: Frank Leymann (frank.leymann@iaas.uni-stuttgart.de) Betreuer: Matthias Wieland (matthias.wieland@iaas.uni-stuttgart.de) Bearbeiter: Carsten Längerer (laengecn@studi.informatik.uni-stuttgart.de) Fabian Schmitt (schmitfn@studi.informatik.uni-stuttgart.de) Jens Rutschmann (rutschjs@studi.informatik.uni-stuttgart.de) Seite 2 Performance-Vergleich von BPEL-Engines

7 Kapitel 2 Zur Auswahl stehende Workflow-Management Systeme Kapitel 2 Zur Auswahl stehende Workflow- Management Systeme In diesem Kapitel werden die getesteten Workflow Management Systeme (WfMS) vorgestellt. Die Übersicht der BPEL-Unterstützung soll dabei nur einen groben Anhaltspunkt bieten, da die BPEL-Kompatibilität in dieser Studie kein Ziel war. 2.1 WebSphere Process Server Der WebSphere Process Server (WPS) 1 ist ein Server von IBM, der zum Betreiben von Geschäftsprozessen dient und auf dem WebSphere Application Server (WAS) läuft. Als Produkt aus der WebSphere Familie werden noch viele zusätzliche Werkzeuge für die Programmierung und Integration einer Service Oriented Architecture (SOA) angeboten BPEL Unterstützung Der WPS unterstützt BPEL in der Version 1.1, sowie einzelne Teile von WS-BPEL 2.0 [1]. Zur besseren Modellierung von Geschäftsprozessen bietet der WPS die Möglichkeit, so genannte Human Tasks einzubinden. Diese basieren auf einer proprietären BPEL-Erweiterung von IBM Voraussetzungen Der WPS benötigt für den Betrieb keine weiteren Programme. Allerdings wird zur Modellierung der BPEL Prozesse eine Entwicklungsumgebung aus der WebSphere Produkt Familie benötigt, da der WPS keine BPEL und WSDL Schnittstelle bietet. Für diese Fachstudie wurde der Websphere Integration Developer (WID) verwendet Installation Die Installation des WPS ist relativ einfach. Um den WPS zu konfigurieren, muss lediglich ein Profil für den WPS erstellt werden, in dem die Struktur des WAS beschrieben wird. Es ist hier möglich den WAS und somit auch den WPS in eine bestehende Serverlandschaft aufzunehmen 1 Performance-Vergleich von BPEL-Engines Seite 3

8 Kapitel 2 Zur Auswahl stehende Workflow-Management Systeme und dadurch mehrere Server für den selben Zweck zu bündeln um eine bessere Performance zu erhalten. Weiterhin kann man einen externen Deploymentmanager für mehrere Server anlegen oder den Server als alleinstehenden Server konfigurieren. Für diese Fachstudie wurde der Server als alleinstehender Server konfiguriert. Außerdem wurde das WAS-Profil als Windows Systemdienst installiert damit das Betriebssystem den Serverprozess verwalten kann. Die Dauer der Installation selbst betrug ungefähr zwei Stunden. 2.2 Stuttgarter Workflow Maschine Die Stuttgarter Workflow Maschine (SWoM) ist das Workflow Management System der Universität Stuttgart. Getestet wurde die Version 1.0, welche den BPEL Standard 1.1 bisher nur teilweise unterstützt BPEL Unterstützung Bedingt durch den momentanen Entwicklungsstand besitzt die SWoM noch einige Einschränkungen: Aktivitäten Handler: Web services können nur synchron aufgerufen werden (two-way-invoke). Als Web service Binding wird nur das SOAP/HTTP Binding unterstützt. Flow Invoke Receive (nur in der Kombination Receive-Reply oder Receive-Invoke) Prozesse können nur durch eine bestimmte Receive-Aktivität gestartet werden Reply Assign Compensate Empty Throw Nur Fault-Handler auf Prozessebene Compensation-Handler auf Prozessebene Seite 4 Performance-Vergleich von BPEL-Engines

9 Kapitel 2 Zur Auswahl stehende Workflow-Management Systeme Voraussetzungen Folgende Programme werden für die Installation der SWoM benötigt. WebSphere Application Server V DB2 V8.2 oder DB2 Express-C Installation Die Installation der SWoM gestaltet sich ähnlich wie die des WPS. Da auch für dieses WfMS der WAS als Application Server verwendet wird, wurde das entsprechende WAS-Profil wie beim WPS als Windows Systemdienst angelegt, um auch für dieses WfMS den Serverprozess vom Betriebssystem verwalten zu lassen. Für die Installation und Konfiguration der SWoM selbst kann auf ein Installationshandbuch und die zur Verfügung gestellten Skripte zurückgegriffen werden. Über diese Skripte werden beispielsweise die Strukturen der einzelnen Datenbanken angelegt sowie die notwendige Konfiguration des WAS abgewickelt. Die Installation ließ sich in mehreren einfachen Schritten durchführen, die genau im Installationshandbuch beschrieben waren. Allerdings werden gewisse Vorkenntnisse über die Web-Konsole des WAS vorausgesetzt. Als Beispiel sei hier das Einbinden von externen Ressourcen wie die Datenbank genannt. Die Installation der SWoM inklusive der Installation des WAS dauerte ungefähr zweieinhalb Stunden. 2.3 Oracle BPEL Process Manager Der Oracle BPEL Process Manager 2 (BPM) ist ein von Oracle entwickelter Server für Geschäftsprozesse mit BPEL-Unterstützung BPEL Unterstützung Der BPM unterstützt BPEL Version 1.1. Zusätzlich gibt es die Möglichkeit, Human Tasks zu verwenden, sowie eigenen Java-Code direkt als Aktivität einzubinden. Das mitgelieferte Modellierungswerkzeug unterstützt allerdings die Flow-Aktivität nur beschränkt: Wird ein Flow erstellt so wird automatisch für jede nebenläufige Aktivität innerhalb dieses Flows eine Sequence-Aktivität angelegt. Zwischen diesen Sequence- Aktivitäten können keinerlei Links definiert werden was dem BPEL-Standard widerspricht. Das Modellierungswerkzeug verhindert außerdem, dass die Sequence-Aktivitäten durch andere Aktivitätstypen ersetzt werden, was es letztendlich unmöglich macht Flow-Aktivitäten ohne Sequence-Aktivitäten zu erstellen Voraussetzungen Der BPM benötigt keine weiteren Komponenten. Das Werkzeug zur Modellierung der Geschäftsprozesse ist ebenfalls bereits im Lieferumfang enthalten. 2 Performance-Vergleich von BPEL-Engines Seite 5

10 Kapitel 2 Zur Auswahl stehende Workflow-Management Systeme Installation Die Installation gestaltet sich einfach. Nach dem Herunterladen der Installationspakete und dem Entpacken derselben muss nur das Installationsprogramm aufgerufen werden. Das System wird dabei so konfiguriert, dass es direkt zu verwenden ist. Die Installation benötigt ungefähr eine halbe Stunde. 2.4 BizTalk Server 2006 (nicht getestet) Der BizTalk Server ist der Microsoft Server für das Betreiben von Geschäftsprozessen. Am Anfang war geplant, diesen Server in den Vergleich mit einzubeziehen. Leider entstanden nach der aufwendigen Installation weitere Probleme, die sich auch nach langer Fehlersuche als unüberwindbar herausstellten. Der BizTalk Server selbst unterstützt nativ kein BPEL. Jedoch gibt es die Möglichkeit, über das Visual Studio.NET BPEL-Prozesse zu importieren und den für den BizTalk Server benötigten Code erzeugen zu lassen. Dieser Schritt konnte jedoch auch nach langer Fehlersuche nicht erfolgreich durchgeführt werden, da das Importieren eines BPEL-Prozesses an internen Problemen des Visual Studios scheiterte. Auch ein BPEL-Beispielprozess, der mit dem BizTalk Server ausgeliefert wird, konnte nicht erfolgreich importiert werden. Nachdem ein großer Aufwand erfolglos in die Fehlersuche und Problembehebung gesteckt wurde, wurde nach Absprache mit den Betreuern entschieden, keine weitere Zeit in den BizTalk Server zu investieren und diesen daher nicht zu testen. Als Ausgleich wurde daher der Test für den Business Process Manager von Oracle hinzugefügt BPEL Unterstützung Der BizTalk Server bietet keine native BPEL Unterstützung. Intern werden die Prozesse in XLANG dargestellt. Aufgrund des fehlenden Tests des BizTalk Servers und da auch nach längere Suche auf der Hompage von Microsoft kein Datenblatt gefunden wurde, welches die Eigenschaften des BizTalk Servers näher beschreibt, konnte die genaue BPEL-Unterstützung nicht ermittelt werden Voraussetzungen Folgende Programme werden für die Installation des BizTalk Server 2006 benötigt. Windows Server 2003 (Microsoft) Internet Information Server IIS (Microsoft) SQL Server 2005 (Microsoft) Visual Studio 2005 (Microsoft) SQLXML 3.0 mit SP3 (Microsoft) Windows SharePoint Services 2.0 mit SP2 (Microsoft) 3 Seite 6 Performance-Vergleich von BPEL-Engines

11 Kapitel 2 Zur Auswahl stehende Workflow-Management Systeme Installation Die Installation von BizTalk Server 2006 war am aufwendigsten. Neben der umfangreichen Liste an Anforderungen gestaltete sich auch die Konfiguration des BizTalk Servers nicht einfach. Die Installation dieser Komponenten und des BizTalk Servers gestaltet sich relativ einfach, jedoch war die darauf folgende Konfiguration sehr aufwändig. Für eine komplette Installation des BizTalk Server 2006 inklusive aller Komponenten benötigt man ungefähr sechs Stunden. 2.5 jbpm (nicht getestet) Der JBoss Business Process Manager (jbpm) 4 ist eine Erweiterung für den JBoss Application Server, die unter anderem auch eine BPEL-Unterstützung bietet. Diese Erweiterung wird ähnlich wie beim WPS von IBM wie jede andere Enterprise Application einfach innerhalb des Application Servers gestartet BPEL Unterstützung Die Unterstützung für BPEL 1.1 befindet sich momentan in der Beta-Phase Voraussetzungen JBoss Application Server Installation Die Installation selbst ist nicht sehr aufwendig, da lediglich ein ZIP-Archiv entpackt werden muss. Danach kann der Server mittels der beiliegenden Batch-Dateien gestartet und gestoppt werden. Die Installation der jbpm-erweiterung wird durch einfaches Kopieren eines Archivs in das Deployment-Verzeichnis des JBoss Application Servers durchgeführt. Hierfür muss man allerdings einige Dateien anpassen und konfigurieren. Dies stellte sich ohne detaillierte Anleitung, welche nicht in dem kostenlos verfügbaren Paket enthalten war als sehr schwierig heraus, wodurch auch das Deployment der Erweiterung immer wieder fehlschlug. Die Installation und Konfiguration dauerte ungefähr eine Stunde. 4 Performance-Vergleich von BPEL-Engines Seite 7

12 Kapitel 2 Zur Auswahl stehende Workflow-Management Systeme 2.6 Vergleich der Workflow Management Systeme In der folgenden Tabelle werden nochmals alle wichtigen Eigenschaften der getesteten WfMS in einer Übersicht zusammen gefasst. Hersteller Feature SWoM WPS BPM IAAS Universität Stuttgart IBM Oracle Unterstützte BPEL Version 1.1 (teilweise) Erweiterungen - Human Tasks Human Tasks Installationsaufwand 2:30 Stunden 2:00 Stunden 0:30 Stunden Voraussetzung Lizenzen Preis je Prozessorlizenz (unbefristet) 1: Information nicht verfügbar WebSphere Application Server DB2 V8.2 / DB2 Express Noch nicht festgelegt - - Inkl. 12 Monate Software Wartung kostenlos Euro [3] Euro [9] Zur Vollständigkeit werden die wichtigsten Eigenschaften der ungetesteten WfMS zusammen gefasst. Feature BizTalk Server 2006 JBPM Hersteller Microsoft JBoss Unterstützte BPEL Version (beta) Erweiterungen Human Tasks Human Tasks Installationsaufwand 6:00 Stunden 1:00 Stunden Vorraussetzung siehe oben JBoss Application Server Lizenzen proprietär LGPL Preis (unbefristet) Dollar kostenlos Auswahl der zu testenden Produkte Bei der Auswahl wurde versucht mindestens ein Open Source Produkt auszuwählen. Da von Betreuer und Auftraggeber gewünscht war die SWoM mit in den Vergleich aufzunehmen, wurde diese trotz unvollständiger BPEL-Unterstützung anstatt anderer Open Source Produkte ausgewählt. Vom Auftraggeber zusätzlich gewünscht wurde der WPS von IBM. Als drittes Produkt sollte zunächst der Microsoft Biztalk Server getestet werden. Da sich dessen Installation und Konfiguration allerdings ausgesprochen schwierig gestaltete wurde dieses Seite 8 Performance-Vergleich von BPEL-Engines

13 Kapitel 2 Zur Auswahl stehende Workflow-Management Systeme Produkt wieder verworfen und stattdessen der jbpm in Betracht gezogen. Auch dieses Produkt wurde aufgrund von nicht ohne größeren Aufwand zu behebenden Fehlern wieder verworfen und stattdessen wurde der BPM von Oracle getestet. Getestete Produkte: Stuttgarter Workflow Maschine (IAAS, Universität Stuttgart) WebSphere Process Server (IBM) BPEL Process Manager (Oracle) Performance-Vergleich von BPEL-Engines Seite 9

14 Kapitel 3 Beschreibung der Performancetests Kapitel 3 Beschreibung der Performancetests In diesem Kapitel werden die Kriterien, nach denen die Tests erfolgten, sowie die Testumgebung und die verwendeten Werkzeuge beschrieben. Zusätzlich werden die Modelle der BPEL-Prozesse vorgestellt. 3.1 Performance Bei Lasttests gibt es grundsätzlich zwei Arten von Performance zu unterscheiden: Durchsatz und Reaktionszeit. Beim Durchsatz wird getestet, wie viele Anfragen ein System innerhalb einer bestimmten Zeit bearbeiten kann. Dabei ist die Zeit, die für die Bearbeitung einer einzelnen Anfrage benötigt wird, unerheblich. Wird dagegen die Reaktionszeit getestet, so kommt es nur darauf an, welcher Zeitraum für das Bearbeiten einer einzelnen Anfrage benötigt wird. Die Anzahl der bearbeiteten Anfragen pro Zeiteinheit spielt hier keine Rolle. Bei den Tests in dieser Fachstudie wurde auf beide Eigenschaften eingegangen. Die Reaktionszeit wurde durch einen Testfall überprüft, bei dem einzelne Anfragen sequenziell an das Workflow Management System geschickt wurden (siehe auch Testfall T1, Kapitel Arten der Testläufe). Bei der Überprüfung des Durchsatzes wurden dagegen viele Anfragen über einen langen Zeitraum gleichzeitig an das Workflow Management System geschickt (siehe auch Testfälle T2 und T3, Kapitel Arten der Testläufe). 3.2 Hardware-Umgebung Für den Test wurden zwei verschiedene Rechner genutzt. Abbildung 1 zeigt schematisch den Aufbau der Testumgebung. Die beiden Maschinen wurden für die Test mit einem 1000MBit Cat5e Crosslink-Kabel verbunden. Seite 10 Performance-Vergleich von BPEL-Engines

15 Kapitel 3 Beschreibung der Performancetests SWoM, WPS, BPM SoapUI (z.b. T3) Instanz 1 Instanz n 1000 MBit Cat5e Crosslink Abbildung 1: Aufbau der Testumgebung System für die Workflow Management Systeme Als Testsystem wurde ein Rechner mit einem 3.2GHz Prozessor und 2GB Arbeitsspeicher verwendet. Da insgesamt drei WfMS getestet werden sollten, wurden auf dem Rechner drei separate Partitionen mit jeweils 30GB eingerichtet, in denen die WfMS unabhängig voneinander installiert wurden. Dazu wurde auf jede Partition Windows 2003 Server SP1 als Betriebssystem installiert System für die Testwerkzeuge Das zweite eingesetzte System, auf dem die eigentlichen Testwerkzeuge gestartet werden, ist ein PC mit einem 3.4GHz Prozessor und 2GB Arbeitsspeicher. Als Betriebssystem wurde Windows XP mit installiertem Service Pack 2 eingesetzt. 3.3 Verwendete Testwerkzeuge Als Testwerkzeuge wurden JMeter und SoapUI verwendet. Diese werden im Folgenden genauer beschrieben JMeter JMeter 5 ist eine Testumgebung unter Java, die zur Durchführung von Funktionalitäts- und Lasttests von der Apache Group entwickelt wurde. JMeter bedarf nur einer geringen Einarbeitung und bietet für die Tests der Workflow Management Systeme genügend Funktionen. 5 Performance-Vergleich von BPEL-Engines Seite 11

16 Kapitel 3 Beschreibung der Performancetests Zusätzlich gibt es in JMeter die Möglichkeit, verteilte Tests durchzuführen. Diese wurde jedoch nicht genutzt, da die getesteten Server schon unter der Last eines einzelnen Clients an ihre Grenzen kamen. Die Erstellung der SOAP-Requests, die man in Abbildung 2 sieht, mussten bei JMeter manuell durchgeführt werden, weswegen dieser Schritt in SoapUI durchgeführt wurde. Da sich im Laufe der Fachstudie herausstellte, dass nur zwei Rechner verfügbar sein werden und dadurch die Möglichkeit eines verteilten Tests wegfiel, bot JMeter keinerlei Vorteile gegenüber SoapUI mehr. Aus diesem Grund wurden die endgültigen Tests mit SoapUI durchgeführt. Abbildung 2: JMeter mit den Einstellungen für Web services Seite 12 Performance-Vergleich von BPEL-Engines

17 Kapitel 3 Beschreibung der Performancetests SoapUI Ein weiteres Werkzeug zur Durchführung von Tests von Web services ist SoapUI. SoapUI bietet wie auch JMeter viele Möglichkeiten zur Durchführung von Last- und Funktionstests. SoapUI bietet eine komfortable Möglichkeit, die SOAP-Requests aus einer bestehenden WSDL zu generieren. In Abbildung 3 wird die Oberfläche von SoapUI gezeigt. Bei SoapUI kann für jede WSDL eine Reihe von Testfällen angelegt werden, welche dann wiederum als Lasttest ausgeführt werden können. Im Verlauf der Fachstudie hat sich die Arbeit mit SoapUI als benutzerfreundlich erwiesen. Abbildung 3: SoapUI vor der Durchführung eines Lasttests 3.4 Modellierung der Prozessmodelle Für die Prozessmodelle der SWoM wurde das Open Source Programm Active BPEL Designer 2.0 von der Firma Active Endpoints [6] verwendet, da es keine proprietäre Entwicklungsumgebung gab. Die BPEL Dateien mussten dafür aber nachträglich noch angepasst werden, da der Active BPEL Designer proprietäre BPEL-Erweiterungen verwendet. Für das Deployment von Prozessen werden keine besonderen Werkzeuge benötigt. Für den Import eines Prozessmodells in die Datenbank, welches vor dem Deployment gemacht werden muss, bietet die SWoM ein eigenes Dateiformat. Diese Datei hat das ZIP Format und enthält den BPEL Prozess, den Deployment Deskriptor und die zugehörigen WSDL Dateien. Performance-Vergleich von BPEL-Engines Seite 13

18 Kapitel 3 Beschreibung der Performancetests Für den WPS wurde der WID verwendet, welcher als extra Werkzeug noch dazu gekauft werden muss, um die Prozessmodelle auf dieses Produkt abzustimmen. Mit Hilfe der Developer Works Seiten [7] gestaltete sich der WID als sehr hilfreiches Werkzeug. Der WPS bietet keine Schnittstelle an um BPEL Prozesse und ihre zugehörigen WSDL Dateien direkt zu importieren. Der Import wickelt sich über die Web-Konsole des unterliegenden WAS ab. Dieser besitzt lediglich eine Schnittstelle für Java Archiv Dateien und daher muss der Prozess in eine EAR Datei gekapselt werden. Dieser Schritt kann nur von Modellierungswerkzeugen der WebSphere Produktfamile durchgeführt werden, da hierbei spezielle Deployment Deskriptoren und weitere proprietäre Metadaten erzeugt werden, welche vom WAS für das Deployment benötigt werden. Die hierbei erzeugte EAR-Datei kann dann über die Administrationskonsole des WAS wie jede andere Unternehmens-Anwendung installiert werden. Am einfachsten zu bedienen war der BPM von Oracle. Im Auslieferungsumfang enthalten ist der JDeveloper BPEL Designer, mit dem die BPEL Prozesse modelliert und direkt auf dem Server deployed werden können. Im Gegensatz zu den anderen getesteten Produkten war dieses Werkzeug mit kleinen Ausnahmen intuitiv zu bedienen und hat keine große Einarbeitungszeit benötigt bis der erste Prozess in Produktion gesetzt war. Rückblickend ist der WID ein sehr umfangreiches Entwicklungswerkzeug, das Bestandteil einer großen Produktfamilie ist. Aus diesem Grund erlaubt das Werkzeug viele verschiedene Sichten auf den Prozess und auch die einzelnen Komponenten des Prozesses lassen sich einfach modellieren und am Schluss mit Hilfe von Drag & Drop integrieren. Aufgrund des Funktionsumfangs und der Komplexität waren die generierten Artefakte nicht immer nachvollziehbar und der Prozess musste einige Male neu modelliert werden, bis das gewünschte Ergebnis erreicht werden konnte. Im Gegensatz dazu besitzt der JDeveloper BPEL Designer weniger Funktionalität. Zum Beispiel ist die Installation an einen Server gebunden. Dadurch lässt sich allerdings auch keine komplexe Server-Struktur in das Programm einbinden. Durch die geringere Funktionalität wirkt das Produkt intuitiver als der WID und lässt sich daher wesentlich einfacher bedienen. 3.5 Prozessmodelle der Testprozesse Dieser Abschnitt bietet eine grafische Darstellung der getesteten Workflow Prozesse. Leider ist es in der Praxis nicht möglich, für die Modellierung eines BPEL-Prozesses ein beliebiges Modellierungswerkzeug zu verwenden. Meistens ist man sehr stark an die Modellierungswerkzeuge gebunden, welche speziell für das verwendete WfMS entwickelt wurden. Die Ursachen dafür sind sowohl einerseits die Deployment-Deskriptoren, die sich zwischen den einzelnen Produkten stark unterscheiden, als auch andererseits die proprietären Erweiterungen des BPEL-Standards, welche ebenfalls meist nur von dem WfMS einer Firma unterstützt werden. Aus diesem Grund wurden für jedes getestete Produkt alle Prozessmodelle jeweils in der dafür vorgesehenen Entwicklungsumgebung angelegt. Hier wird jeder Prozess allerdings nur einmal dargestellt, da sich die Prozesse von der Semantik nur geringfügig unterscheiden. Seite 14 Performance-Vergleich von BPEL-Engines

19 Kapitel 3 Beschreibung der Performancetests Diese Unterschiede sind in den Implementierungsdetails der einzelnen Prozesse näher erläutert. Die vollständigen BPEL-Beschreibungen aller getesteten Prozesse sind in Kapitel 8 aufgelistet. Der Web service "Endpoint1" wurde aus allen Prozessmodellen, welche für die Performance- Messung von Web service-aufrufen erstellt wurden, nur synchron im Sinne der BPEL- Spezifikation aufgerufen. Dies war nötig, da die SWoM keine asynchrone Aufrufe von Partnern unterstützt Sequenzieller Invoke synchron Bei diesem Prozess werden zehn Invoke-Aktivitäten hintereinander aufgerufen. Die Aufrufe gingen alle an den gleichen Web service. Der Web service liefert eine Zeichenkette als Antwort zurück, wodurch die Funktionalität des Web services getestet werden konnte. Der Aufbau des Prozesses wird in der Abbildung 4 graphisch dargestellt. Performance-Vergleich von BPEL-Engines Seite 15

20 Kapitel 3 Beschreibung der Performancetests Abbildung 4: BPEL Prozess für sequenziellen Invoke Implementierungsdetails Beim BPM konnten die Datentypen der Input- und Output-Variablen des Prozesses nicht direkt auf die Input- und Output-Variablen der Invoke-Aktivitäten gemappt werden. Daher mussten hier zwischen den receiveinput - und Invoke_1 -, sowie den Invoke_10 - und replyoutput -Aktivitäten jeweils eine Assign-Aktivität eingefügt werden. Die Auswirkungen der Assign-Aktivität wurden bei der Durchführung der Test nicht explizit berücksichtigt. Bei den beiden anderen Workflow Management Systemen waren die Assign-Aktivitäten nicht nötig, da die Datentypen des Prozesses und die Datentypen des Web services passend zueinander gewählt werden konnten. Seite 16 Performance-Vergleich von BPEL-Engines

21 Kapitel 3 Beschreibung der Performancetests Paralleler Invoke synchron Bei diesem Prozess werden zehn Invoke-Aktivitäten gleichzeitig aufgerufen. Die Aufrufe gingen alle an den gleichen Web service. Der Web service liefert eine Zeichenkette als Antwort zurück, wodurch die Funktionalität des Web services getestet werden konnte. Der Aufbau des Prozesses wird in der Abbildung 5 graphisch dargestellt. Die Antwort des Prozesses enthielt immer nur die Antwort eines aufgerufenen Web services, da für das Zusammenführen der Rückgaben wiederum eine Assign-Aktivität nötig gewesen wäre, welche in diesem Testfall aber nicht getestet werden sollten. Dennoch wird die Reply- Aktivität erst ausgeführt nachdem alle Invoke-Aktivitäten erfolgreich abgearbeitet wurden. Abbildung 5: BPEL Prozess für parallelen Invoke Implementierungsdetails Hier traten beim BPM die selben Probleme wie beim vorigen Prozess auf. Daher wurden hier wieder zwei zusätzliche Assign-Aktivitäten eingefügt um die Datentypen zu konvertieren und zwar eines nach der "receiveinput"- und eines vor der "replyoutput"-aktivität. Performance-Vergleich von BPEL-Engines Seite 17

22 Kapitel 3 Beschreibung der Performancetests Sequenzieller Assign synchron Bei diesem Test wurden zehn Assign-Aktivitäten hintereinander ausgeführt. Der Aufbau des Prozesses wird in der Abbildung 6 graphisch dargestellt. Abbildung 6: BPEL Prozess für sequenziellen Assign Seite 18 Performance-Vergleich von BPEL-Engines

23 Kapitel 3 Beschreibung der Performancetests Implementierungsdetails Dieses Modell konnte bei allen Workflow Management Systemen direkt umgesetzt werden Paralleler Assign synchron Bei diesem Modell werden zehn Assign-Aktivitäten gleichzeitig ausgeführt. Die Rückgabe des Prozesses enthält das Ergebnis einer Assign-Aktivität. Auch hier wurde auf das Zusammenführen der Ergebnisse der einzelnen Assign-Aktivitäten verzichtet um nur die Ausführungszeit der parallelen Assign-Aktivitäten zu messen. Dennoch wird die Reply- Aktivität erst ausgeführt nachdem alle Assign-Aktivitäten erfolgreich abgearbeitet wurden. Das Prozessmodell ist in Abbildung 7 zu sehen. Abbildung 7: BPEL Prozess für parallelen Assign Implementierungsdetails Dieses Modell konnte bei allen Workflow Management Systemen direkt umgesetzt werden. Performance-Vergleich von BPEL-Engines Seite 19

24 Kapitel 3 Beschreibung der Performancetests Service-Endpunkte Die Prozessmodelle "Sequenzieller Invoke" und "Paralleler Invoke" benötigen einen Web service, den sie aufrufen. Hierfür wurde der Web service "Endpoint1" entwickelt und auf jedem der einzelnen Server deployed. Für die SWoM und den WPS konnte die selbe Implementierung benutzt werden, da sie den selben Application Server als Middleware benutzen. Für den BPM musste der Web service "Endpoint1" erneut implementiert werden, da der BPM nicht den gleichen Application Server wie die anderen beiden Workflow Management Systeme nutzt. Als Werkzeug für die Entwicklung des Web service "Endpoint1" kam einmal der Rational Application Developer (RAD) von IBM zum Einsatz, der auf den WAS abgestimmt ist. Hier wurde der Top Down Ansatz durchgeführt. Zu einer gegebenen WSDL generiert der RAD ein Skeleton für Enterprise Java Beans oder auch Java Beans. In dieser Fachstudie wurde auf Grund der Performance ein Enterprise Java Bean Skeleton gewählt. Um diesen Web service mit seiner Funktionalität zu vervollständigen muss noch der gewünschte Code in die entsprechende Operation, welche den Namen der Operation aus der WSDL trägt, eingefügt werden. Abschließend wird die EAR Datei, welche die EJB-JAR Datei enthält, exportiert und über die Web-Konsole des WAS depoyed. Es besteht auch die Möglichkeit das WAS-Profil als Server direkt in den RAD einzubinden und aus dessen Oberfläche zu verwalten. Für den Web service im BPM wurde der Bottom Up Ansatz nachverfolgt. Hier wurde zuerst eine Java Klasse mit der gewünschten Funktionalität implementiert. Über das Menü konnte hiervon ein Web service erzeugt werden und ebenfalls auf dem Server des BPM, der im Gegensatz zum RAD hier schon eingebunden ist, deployed werden. Der Web service "Endpoint1" wurde auf dem selben Server deployed, in dem auch der BPEL- Prozess läuft. Dies wurde so gewählt, da keine weiteren Verzögerungen durch zusätzliche Netzwerkzugriffe entstehen sollten. Andernfalls könnten diese Netzwerkzugriffe zu einem Flaschenhals für den Testlauf werden, und somit das komplette WfMS ausbremsen. Außerdem bildet dieser Aufbau eher die Realität ab, da sich die verwendeten Web services sehr oft auf der gleichen Maschine befinden wie die WfMS, die sie aufrufen. Um die Auswirkung der Web services auf den Performance-Test möglichst gering zu halten wurde eine möglichst einfache Implemnetierung für die Web services gewählt. Wie in Abbildung 8 dargestellt, wird lediglich die Zeichenkette _a an den eingegangen Parameter angehängt. Abbildung 8: Web service Endpoint1 Seite 20 Performance-Vergleich von BPEL-Engines