Evaluation von Open Source Produkten zur Ausführung Web Service-basierter Geschäftsprozesse

Transkript

1 Evaluation von Open Source Produkten zur Ausführung Web Service-basierter Geschäftsprozesse Guido Laures, Harald Meyer, Torsten Hamann, Jan Möller, Philip Sommer Hasso-Plattner-Institut für Softwaresystemtechnik GmbH Prof.-Dr.-Helmert-Strasse 2-3, Potsdam, Germany Abstract: Die Bedeutung von Technologien und Frameworks zur Definition, Verwaltung und Ausführung von IT-gestützten Geschäftsprozessen hat gerade mit dem Aufkommen von service-orientierten Architekturen stark zugenommen. Folgerichtig haben nicht nur namhafte Hersteller von Infrastruktur-Software diesen Markt für sich entdeckt. Auch im Open-Source-Bereich haben sich eine Reihe von Projekten etabliert, die zum Ziel haben, eine produktiv verwendbare Workflow-Engine zu veröffentlichen. In diesem Papier evaluieren wir eine Reihe von Open-Source-Produkten auf Ihre Fähigkeit hin, Web Service-basierte Geschäftsprozesse auszuführen. Hierzu werden die der Evaluation zugrunde liegenden Kriterien erarbeitet. Aus einer langen Kandidatenliste extrahieren wir gemäß einer Untermenge dieser Kriterien eine Kurzliste, deren Einträge wir daraufhin genauer untersuchen. Die Diskussion der Erfahrungen bei der Integration des Siegers der Evaluation in ein bestehendes Framework zur Ausführung von Geschäftsprozessen validiert die Ergebnisse der Evaluation. 1 Einführung Der Markt der Workflow- oder Geschäftsprozessmanagement-Produkte (Business Process Management Suite, BPM) hat sich auch aufgrund des zunehmenden Interesses an serviceorientierten Architekturen (SOA) [Bur00, PG03, ACKM04] und Unternehmens-Bussen (Enterprise Service Bus, ESB) stark vergrößert. So ist es nicht verwunderlich, dass auch eine Reihe von Open-Source-Entwicklungen auf dieses Segment abzielen. Jedoch ist der Funktionsbereich, der von solchen Projekten hervorgebrachten Software, meist sehr eingeschränkt. Häufig werden nur sehr wenige oder sehr spezielle Sprachen zur Definition von Prozessen unterstützt. Zudem sind der Reifegrad und die damit verbundenen Einsatzmöglichkeiten der Software oftmals erst durch aufwändige Evaluationen feststellbar. In diesem Papier stellen wir eine Evaluation von ausgewählten Workflow- und BPM- Projekten aus dem Open-Source-Bereich vor und prüfen ihre Einsatztauglichkeit. Diese Untersuchung war Teil des EU-Projektes Adaptive Services Grid 1, in dem eine Plattform zur Bereitstellung semantisch angereicherter Dienste konzipiert und realisiert wurde. 1

2 Die Standardisierungsbemühungen der Industrie zur Spezifikation einer XML-basierten Prozessbeschreibungssprache mündeten in die Business Process Execution Language for Web Services (WS-BPEL) [OAS04]. BPEL wird von Analysten als die Standardsprache zukünftiger BPM-Produkte angesehen [SAA04]. Aus diesem Grund wird BPEL auch in der Referenzarchitektur der ASG Plattform [LJ05] als Standardsprache für Prozesse verwendet. Innerhalb der ASG Referenzarchitektur durchläuft ein semantischer Service-Aufruf verschiedene Stufen. Nachdem auf Basis der semantischen Beschreibung des Service-Aufrufs mittels einer Kompositionskomponente eine Dienstkomposition erstellt wurde, wird diese in der Bindungsphase in einen validen BPEL-Prozess überführt, der dann in der Ausführungsphase mittels einer Prozesskomponente ausgeführt wird. Durch ein Komponentenmodell ist es möglich, verschiedene Implementierungen für Komponenten zu verwenden, ohne dass andere Komponenten innerhalb der Plattform davon beeinflusst werden. Da bereits erfolgreich eine kommerzielle Prozess-Komponente 2 integriert wurde, beschloss dass ASG-Projekt zur Validierung des Komponentenmodells und der definierten Schnittstellen der Referenzarchitektur, den Versuch zu unternehmen, eine weitere Implementierung zur Prozessausführung zu integrieren. Dieses Dokument beschreibt das Vorgehen und die Ergebnisse des Evaluationsprozesses zur Auswahl einer geeigneten Prozesskomponente, die unter einer Open-Source-Lizenz verfügbar ist. Kapitel 2 beschreibt kurz die Schnittstelle, die von der zu integrierenden Komponente innerhalb der Referenzarchitektur bedient werden muss. Kapitel 3 beschreibt die Evaluationskriterien, die auf die in Kapitel 4 vorgestellte Liste von Kandidaten angewandt wurden. Die Extraktion einer Kurzliste durch Anwendung dieser Kriterien ist in Kapitel 5 beschrieben. Die Kandidaten der Kurzliste wurden einem Praxistest mit konkreten Szenarien unterzogen, die in Kapitel 6 beschrieben sind. Kapitel 7 widmet sich einer ausführlichen Diskussion des Siegers der Evaluation, der BPEL-Maschine PXE der Firma FiveSight, und der mit diesem Produkt durchgeführten Integration. Das letzte Kapitel fasst die Ergebnisse noch einmal überblickend zusammen. 2 Schnittstellen zur Integration einer Workflow-Engine Gemäß der ASG-Referenzarchitektur muss eine Komponente zur Ausführung von Geschäftsprozessen befähigt sein, unten aufgeführte Schnittstelle zu bedienen. Die Schnittstellen der Referenzarchitektur sind in Java angeben. Da die verwendeten Datentypen allerdings aus einem XML-Schema generiert wurden, sind sie sprachunabhängig. public interface ServiceEnactment { public Response enactservice( ComposedService composedservice, Request semanticrequest) 2

3 throws ServiceEnactmentException; public void registereventhandler( EnactmentEventHandler eventhandler) throws ServiceEnactmentException; public void unregistereventhandler( EnactmentEventHandler eventhandler) throws ServiceEnactmentException; } Die Funktionalität dieser Schnittstelle besteht im Wesentlichen in der Ausführung eines ComposedService beim Aufruf der Methode enactservice(). Ein Composed- Service beinhaltet einen BPEL-Prozess angereichert mit nicht-funktionalen Qualitätsmerkmalen, die von weiteren Komponenten der Plattform verarbeitet werden. Der BPEL- Prozess adressiert alle relevanten Web Services mittels WS-Addressing [W3C04]. Die anderen Methoden dienen der Anknüpfung von Komponenten, die Ereignisse verarbeiten, die während der Ausführung eines ComposedService auftreten können. So können Komponenten beispielsweise über die erfolgreiche Ausführung eines Dienstes informiert werden und so den Erfolg einer Prozessausführung überwachen. Controller ServiceEnactment Adapter EnactmentEventHandler Component NegotiationManager Component Process Engine Infrastructure WS-Addressing Abbildung 1: Bediente und verwendete Schnittstellen der integrierten BPM Engine Da es zur Zeit noch keine native Unterstützung der ASG Referenzarchitektur in Workflowund BPM-Produkten gibt, muss wie in Abbildung 2 dargestellt, ein Adapter entwickelt werden, der die Anbindung realisiert. Da nur drei Methoden implementiert werden müssen, bedeutet dies keine großen Entwicklungsaufwand. Die verwendeten Datentypen basieren z.b. auf dem BPEL-Standard, so dass existierende Prozesskomponenten, die BPEL unterstützen, leicht integriert werden können. Es ist allerdings nicht zwingend notwendig, dass die integrierte Prozesskomponente nativ BPEL unterstützt. Etwaige Konvertierungen vom nativen Format der Prozesskomponente nach BPEL müssen gegebenenfalls vom Adapter übernommen werden. Neben dem Aufruf der Web Services des auszuführenden BPEL-Prozess verfügt eine vollständige Implementierung von ServiceEnactment auch über einen Fehlerbehandlungsmechanismus. Im Falle eines Fehlers, während der Ausführung, konsultiert Ser-

4 viceenactment eine Komponente, die die Schnittstelle NegotiationManager implementiert. Ein NegotiationManager ist in der Lage, für bestimmte Web Service Aufrufe im BPEL-Prozess Alternativen zu finden und diese in den BPEL-Prozess einzubauen. Damit können defekte Web Services zur Laufzeit durch funktional äquivalente Dienste ersetzt werden und damit die Verfügbarkeit des BPEL-Prozesses selbst erhöhen. 3 Evaluationskriterien Zur Unterstützung der Entscheidung, welche der verfügbaren Workflow- und BPM-Engines am Besten für eine Integration in die ASG-Referenzarchitektur geeignet ist, ist es notwendig überprüfbare Evaluationskriterien festzulegen. Diese resultieren aus den in [Mmo04] definierten Architekturvorgaben und den daraus abgeleiteten Anforderungen. Die erarbeiteten Kriterien können in zwingende und optionale eingeteilt werden. Die zwingenden Kriterien müssen und optionale sollten von der zu integrierenden Software erfüllt sein. Die optionalen Kriterien wurden zur Verfeinerung der Bewertung zusätzlich gewichtet. In Tabelle 1 sind die zwingend notwendigen Kriterien für unsere Evaluation spezifiziert. Kriterium Motivation K1 Einfache Abbildung Integrationsaufwand wird sehr hoch, wenn das interne vom internen Prozessformat Format nur sehr schwer in BPEL überführ- nach BPEL bar ist K2 Unterstützung der wichtigsten Die Kompositionskomponente erstellt BPELter Workflowmus- Prozesse, die Basis- und Abbruch-Muster enthal- [vdathkb03] ten können. K3 Unterstützung von Web Service Aufrufen mittels Service Infrastruktur fordert diese Art der Addressierung. WS-Adressing K4 Open Source Ziel ist die Integration einer frei verfügbaren Implementierung K5 Hoher Produktreifgrad Das Endprodukt soll einmal in kritischen Applikation verwendet werden. K6 Aktives Projekt Die Entwicklung der Komponente sollte noch immer von einer aktiven Gemeinschaft betrieben werden. Tabelle 1: Zwingende Anforderungen Zu den optionalen Kriterien (Tabelle 2) zählen vor allem solche, die sicherstellen sollen, dass die Prozesskomponente einfach integriert und verwendet werden kann. Alle mit K8-x bezeichneten Kriterien zielen auf die Minimierung des Integrationsaufwand ab. Die Zahlen in Klammern kennzeichnen die Gewichtung des Kriteriums (niedrige Zahl bedeutet geringere Wichtigkeit).

5 7.1 PXE Schnittstellen zur Integration Die flexible Architektur von PXE erlaubt dessen Einsatz in verschiedenen Laufzeitumgebungen. Damit PXE innerhalb einer bestimmten Laufzeitumgebung funktionieren kann, muss eine Implementierung der von PXE definierten Binding API (BAPI) vorliegen, die auf diese Umgebung zugeschnitten ist. PXE bringt solche Implementierung bereits für den JBoss Application Server sowie für einen Standalone-Einsatz mit. Projekte, die eine andere Laufzeitumgebung als diese beiden voraussetzen, müssen eine eigene Implementierung bereitstellen. Die technologische Basis für PXE besteht aus Java Management Extensions (JMX) für das Deployment von Prozessen und Ereignisbehandlung sowie Java Transaction API (JTA) für die Unterstützung transaktionaler Prozesse. Eine BAPI Implementierung muss demnach einen Server mit JMX-Unterstützung bereitstellen (MBean Server) sowie einen Transaktions- Manager. JMX und JTA sind reife Technologien im Sinne von K8-2. Eine eigene BAPI Implementierung kommt aufgrund des damit verbundenen Aufwands in unserem Szenario nicht in Frage. Somit muss eine Entscheidung getroffen werden, ob eine auf JBoss basierende Realisierung oder eine Standalone-Version verwendet werden soll. Beide verfügen über eine gemeinsame Schnittstelle zum Deployment, Kontrolle und Überwachung von Prozessen. Somit decken sie beide K9 ab. Eine Implementierung der Methode enactservice der in unserem Fall relevanten Schnittstelle ServiceEnactment kann auf Basis der von PXE definierten Deployment und Management API (speziell com. fs.pxe.swfk.deployment und com.fs.pxe.swfk.mngmt) realisiert werden. Derzeit unterstützt PXE zwei Wege zum Aufruf eines Services. Der eine ist der Versand von SOAP-Nachrichten über HTTP. Der zweite ist proprietärer und basiert auf XML- Dokumenten, die über eine spezielle PXEConnection versendet werden. Nachrichten über den Status einer Prozessausführung, wie sie von den Methoden registerevent- Handler und unregistereventhandler gefordert werden, können basierend auf der PXE BPEL API realisiert werden (com.fs.pxe.bpel.evt und com.fs.pxe. bpel.jmx). Dies erfüllt somit auch K10. Mit Ausnahme des Teils des Kriteriums K8-1, das den Aufruf von Web Services voraussetzt, sind damit alle Kriterien erfüllt. Wie auch K8-1 voll erfüllt werden kann, wird im folgenden Unterkapitel besprochen. 7.2 Web Service Aufruf mittels WS-Adressing Um WS-Addressing verwenden zu können, müssen entweder im BPEL Prozess oder im Prozess Deployment Deskriptor der Workflow Engine Endpunkt-Referenzen deklariert sein. In PXE ist keine dieser beiden Möglichkeiten implementiert. Jedoch beschreibt die PXE Dokumentation, wie selbstdefinierte Attribute innerhalb eines Deployment Deskriptors beschrieben werden können. Eine WS-Addrsssing Erweiterung von PXE, die diesen Mechanismus zur Determinierung von Endpunkt-Referenzen verwendet, würde die erforderliche Funktionalität liefern, um auch K8-1 vollständig zu erfüllen. Allerdings ist eine solche Implementierung insofern eingeschränkt, als dass jeder Partner Link immer exakt

6 eine statische Endpunkt-Referenz verwenden muss. Eine alternative und flexiblere Option wäre die Verwendung der <assign>-aktivität in BPEL. Hierbei wird eine Endpunkt-Referenz als pures XML verwendet. Allerdings ist unklar, ob eine solche Erweiterung der BPEL Prozess-Spezifikation noch als standardkonform angesehen werden kann. Es besteht die Gefahr, dass andere BPEL Engines solche BPEL Prozesse nicht mehr korrekt interpretieren können. Beide Optionen führen dazu, dass auch Kriterium K8-1 erfüllt werden kann. Bei der letztendlich durchgeführten Implementierung eines PXE Adapters wurde letztere Option aufgrund des geringeren Realisierungsaufwandes gewählt und erfolgreich umgesetzt. 8 Zusammenfassung Durch einen mehrstufigen Evaluierungsprozess mit klar definierten Kriterien wurde eine große Menge an verfügbaren Open Source BPM Engines untersucht. Am Ende dieses Prozess blieb lediglich ein Kandidaten übrig, der für die Integration in eine Web Service Architektur, wie sie in unserem Szenario gefordert war, geeignet schien. Dieser Kandidat ist das Produkt PXE der Firma FiveSight. PXE unterstütze alle zwingend erforderlichen Evaluationskriterien mit Ausnahme von WS-Addressing. Die Integration dieses Produktes wurde in einem relativ kurzem Zeitrahmen erfolgreich durchgeführt. Hierbei wurde PXE erfolgreich um WS-Addressing erweitert. Literatur [ACKM04] Gustavo Alonso, Fabio Casati, Harumi Kuno und Vijay Machiraju. Web Services Concepts, Architectures and Applications. Data-Centric Systems and Applications. Springer, [Bur00] Steve Burbeck. The Tao of e-business services. IBM developerworks, [LJ05] G. Laures und K. Jank. Deliverable D6.V-1: Reference Architecture: Requirements, Current Efforts and Design. The ASG Project, [Mmo04] [OAS04] Mariusz Mmotko. D4.III-1: Report on the requirements analysis and evaluation of process enactment, monitoring and visualisation. The ASG Project, OASIS, Organization for the Advancement of Structured Information Standards. Web Services Business Process Execution Language (WS-BPEL), [OMG06] OMG. Business Process Modeling Notation (BPMN) Specification, [PG03] M. P. Papazoglou und D. Georgakopoulos. Service-oriented computing: Introduction. Communications of the ACM, 46(10):24 28, 2003.

7 [SAA04] D. Smith, W. Andrews und C. Abrams. Predicts 2004: Advanced Web Services Gain Traction. Gartner Research, Inc., [Sha02] R. Shapiro. A Technical Comparision of XPDL, BPML and BPEL4WS. Cape Visions, [uea03] T. Andrews und et al. Business Process Execution Language for Web Services 1.1 (BPEL4WS). BEA, IBM, Microsoft, SAP, Siebel, ibm.com/developerworks/library/specification/ws-bpel/. [vdathkb03] W.M.P. van der Aalst, A.H.M. ter Hofstede, B. Kiepuszewski und A.P. Barros. Workflow Patterns. Distributed and Parallel Databases, Seiten 5 51, [W3C04] W3C. Web Services Addressing (WS-Addressing),