Fachbereich Informatik

Transkript

1 Diplomarbeit Strategien zur Prozessorchestrierung und Workflow-Integration in Web-Applikationen Andreas Kümpel Dezember 2004 Betreuer: Prof. Dr. Paul Müller Dipl.-Wirtsch.-Ing. Jochen Müller Fachbereich Informatik AG Integrierte Kommunikationssysteme Universität Kaiserslautern Postfach Kaiserslautern

2

3 Erklärung Hiermit versichere ich, dass ich die vorliegende Diplomarbeit selbständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel verwendet habe. Kaiserslautern, den (Andreas Kümpel)

4

5 Abstract Mit dem zunehmenden Einsatz des Electronic Business werden Geschäftsprozesse und Anwendungssysteme über die Grenzen eines Unternehmens geöffnet und mit denen anderer Geschäftspartner kombiniert. Die Business Process Execution Language for Web Services ermöglicht es, Geschäftsprozesse zu beschreiben und einzelne Web Services miteinander zu kombinieren, um durchgängige Geschäftsprozesse sowohl auf Anbieter- als auch auf Kundenseite zu unterstützen. In dieser Arbeit soll ein bestehendes webbasiertes Informationsportal weiter entwickelt werden, um so die Abarbeitung von Geschäftsprozessen zu unterstützen. Als Realisierungsbeispiel dient ein Prozess aus der Flächennutzungsplanung.

6

7 Strategien zur Prozessorchestrierung und Workflow-Integration in Web-Applikationen Inhaltsverzeichnis 1. Einleitung Ausgangslage und Problemstellung Ziel der Diplomarbeit Aufbau der Diplomarbeit Grundlagen Portale Geschäftsprozesse, Workflows & Workflow-Management Web Services Architektur Der Dienst-Anbieter Der Dienst-Konsument Die Gelben Seiten WSDL Business Process Execution Language Aufbau eines BPEL-Prozesses Interaktion Partner Links Partner Link Types Business Partner Kommunikation Scopes Fehlerbehandlung Kompensation Variablen Ausdrücke Korrelationen Aktivitäten Basisaktivitäten VII

8 Inhaltsverzeichnis Strukturelle Aktivitäten Nebenläufiger Ablauf Synchronisation Übergangsbedingungen Ereignisse BPEL4WS-Implementationen IBM (alphaworks) BPWS4J Oracle BPEL Process Manager ActiveBPEL FNP-Implementation KLinform-Framework Flächennutzungsplanung Teilprozess Persistente Datenhaltung FNP-Datenbankschema Erweiterung der KLinform-Relationen Architektur des Systems Web-Frontend Web Services BPEL-Prozess WSDL-Schnittstelle BPEL-Dokument Zusammenfassung und Ausblick Anhang Installation AXIS Installation BPWS4J Installation FileUpload Datenbank VIII

9 Strategien zur Prozessorchestrierung und Workflow-Integration in Web-Applikationen Literaturverzeichnis Abbildungsverzeichnis IX

10 Inhaltsverzeichnis X

11 Strategien zur Prozessorchestrierung und Workflow-Integration in Web-Applikationen 1. Einleitung Der erste Abschnitt der Einleitung beschäftigt sich mit der Ausgangslage und der Problemstellung des Themas dieser Diplomarbeit. Im zweiten Abschnitt wird das Ziel dieser Arbeit vorgestellt. Abschließend erfolgt die Beschreibung des Aufbaus der Diplomarbeit. 1.1 Ausgangslage und Problemstellung Das Electronic Business führt zu einer erheblichen Umgestaltung von Markt- und Wertschöpfungsstrukturen. Die verteilte Struktur und die große Verfügbarkeit des Internets erlauben eine Rekonfiguration von Wertschöpfungsketten. Geschäftsprozesse und Anwendungssysteme werden über die Grenzen eines Unternehmens geöffnet und mit denen anderer Partner kombiniert [West04]. Ein Geschäftsprozess kann als Folge von zusammenhängenden Aktivitäten betrachtet werden. Er bildet die Basis der Wertschöpfung sowohl für das Unternehmen als auch für den Kunden; Kundenorientierung, Durchlaufzeit, Reaktionsschnelligkeit und Flexibilität sind dabei die Zielgrößen eines Geschäftsprozesses [Voig03]. Um die einzelnen Aktivitäten eines unternehmensübergreifenden Geschäftsprozesses zu realisieren, bietet sich der Einsatz von Web Services an. Der große Vorteil von Web Services besteht in der Integrationsfähigkeit in bestehende Systeme. Die Business Process Execution Language for Web Services ermöglicht es, Geschäftsprozesse zu beschreiben und einzelne Web Services miteinander zu kombinieren, um durchgängige Geschäftsprozesse sowohl auf Anbieter- als auch auf Kundenseite zu unterstützen [West04]. Viele Unternehmen besitzen bereits Mitarbeiterportale oder Informationsportale, über die sie den Kunden Dienstleistungen und Informationen anbieten, über die aber auch Mitarbeiter vorhandene Unternehmensinformationssysteme verwenden. Es bietet sich also an, eine bereits bestehende Infrastruktur zu verwenden, um den Beteiligten eines Geschäftsprozesses Zugriff auf den Prozess selber zu ermöglichen. 11

12 Einleitung 1.2 Ziel der Diplomarbeit Das Ziel dieser Arbeit ist es, ein bestehendes webbasiertes Informationsportal zu einem Prozessportal weiter zu entwickeln, um so die Abarbeitung von Geschäftsprozessen zu unterstützen. Als Informationsportal dient das Framework KLinform, das an der Technischen Universität Kaiserslautern in der Arbeitsgruppe Integrierte Kommunikationssysteme zum modularen Aufbau von Web-Applikationen entwickelt wurde. Als Realisierungsbeispiel dient ein Teilprozess aus der Flächennutzungsplanung. Das Portal soll entsprechend der unterschiedlichen beteiligten Rollen eine Web-Oberfläche zur Abarbeitung des Teilprozesses zur Verfügung stellen. Das Management dieses Teilprozesses soll mit der Sprache Business Process Execution Language for Web Services (BPEL4WS) realisiert werden, die einzelnen Komponenten des Prozesses als Web Services. 1.3 Aufbau der Diplomarbeit Neben dieser Einleitung gliedert sich die Arbeit in vier weitere Kapitel sowie einen Anhang. Im folgenden zweiten Kapitel werden die Grundlagen von Geschäftsprozessen, Web-Portalen und Web Services gelegt. Dabei wird versucht, eine klare Begriffsabgrenzung vorzunehmen und die verwendeten Technologien entsprechend einzuordnen. Kapitel 3 befasst sich detailliert mit der Business Process Execution Language for Web Services (BPEL4WS). Anhand von Beispielen werden alle Elemente von BPEL4WS ausführlich vorgestellt und beschrieben. Da die Sprache BPEL4WS seit mehr als zwei Jahren spezifiziert ist, existieren mittlerweile eine Reihe von Implementationen, die die Ausführung von mit BPEL4WS verfassten Geschäftsprozessen ausführen können. Im zweiten Abschnitt des dritten Kapitels werden einige bekannte BPEL4WS-Implementationen vorgestellt. Die Beschreibung der Einbettung des Teilprozesses aus dem Bereich Flächennutzungsplanung, kurz FNP, in das KLinform-Framework steht im Mittelpunkt von Kapitel 4. Zu Beginn erfolgt eine kurze Beschreibung des KLinform-Frameworks und des zu realisierenden Teilprozesses. Anschließend erfolgt ein kleiner Exkurs in den Bereich der FNP. Nach einer Beschreibung des zu realisierenden FNP-Teilprozesses, wird der im Rahmen 12

13 Strategien zur Prozessorchestrierung und Workflow-Integration in Web-Applikationen dieser Diplomarbeit entwickelte Prototyp zur rechnerunterstützten Ausführung des Teilprozesses vorgestellt. Das fünfte und letzte Kapitel beinhaltet eine kurze Zusammenfassung dieser Arbeit sowie einen Ausblick. Im Anhang befinden sich Anleitungen und wichtige Hinweise zur Installation der Software, die bei dem in Kapitel vier vorgestellten Prototyp zur Realisierung verwendet wurden. 13

14 Einleitung 14

15 Strategien zur Prozessorchestrierung und Workflow-Integration in Web-Applikationen 2. Grundlagen Im zweiten Kapitel werden die Grundlagen von Geschäftsprozessen näher erläutert. Dabei wird versucht, klare Begriffsabgrenzungen und Definitionen vorzunehmen und die verwendeten Technologien entsprechend einzuordnen. Im ersten und zweiten Abschnitt werden die im Zusammenhang mit Geschäftsprozessen verwendeten Begriffe kurz erklärt. Im dritten Abschnitt wird die verwendete Technologie der Web Services vorgestellt, die bei der Realisierung des Prototyps verwendet wurde. 2.1 Portale Die im Laufe der Zeit in Unternehmen typischerweise entstandene Applikationslandschaft ist dadurch gekennzeichnet, dass häufig dedizierte Informationssysteme für die einzelnen Bereiche eines Unternehmens (Finanzbuchhaltung, Materialwirtschaft, etc.) entwickelt wurden. Oftmals werden redundante Dateninformationen parallel in den unterschiedlichen Systemen gehalten. Besonders im Bereich der Wartbarkeit weisen diese dedizierten Systeme dadurch große Nachteile auf. Anfang der 90er Jahre wurden diese Nachteile durch so genannte Querschnittsysteme abgefangen, Systeme die die einzelnen dedizierten Informationssysteme miteinander verbinden. Portale lassen sich zu diesen Querschnittsystemen zählen. Es handelt sich dabei um Anwendungstypen, die das Internet als Kommunikations- und insbesondere als Vertriebsmedium erschließen und sich stärker als die traditionellen Applikationen an den Geschäftsprozessen und den Kunden orientieren. Allgemein definiert ist ein Portal eine Web- Anwendung, in der Inhalte, Dienste und Funktionen integriert werden [ScWi02]. Der Begriff des Portals im Bereich Internet hat sich im Laufe der Zeit gewandelt. Wurde zu Beginn bereits eine einfache Suchmaschine als Portal bezeichnet, so versteht man mittlerweile unter dem Begriff interaktive Anwendungen, die u. a. als Kommunikationsplattformen dienen, sowohl innerhalb des Unternehmens zwischen den eigenen Abteilungen und Angestellten als auch gegenüber Geschäftspartnern oder Kunden. Es hat also eine Entwicklung vom Informationsportal hin zum Geschäftsprozessportal statt gefunden. Üblicherweise verschafft dabei ein Webbrowser-basiertes Frontend den Zugang zu unterschiedlichen Backend-Systemen [ScWi02]. 15

16 Grundlagen Portale lassen sich auf unterschiedliche Arten klassifizieren. Die Grenzen zwischen diesen Arten sind in der Praxis jedoch oft fließend. Im Folgenden sind einige dieser Arten aufgeführt (in Anlehnung an [Spar02]): Branchenportale Branchenportale bilden einen Anlaufpunkt im Internet zu Themen einer bestimmten Branche. Neben den Diensten einzelner Anbieter werden dem Besucher hier oft unternehmensübergreifende Beratungen, Marktplätze oder Benutzerforen angeboten. Kundenportale Einzelne Unternehmen bieten dem Kunden über spezielle Kundenportale die Möglichkeit, Daten und Dienste zu den angebotenen Produkten und Dienstleistungen in Anspruch zu nehmen. Mitarbeiterportale Diese Art von Portalen bietet einen ortsunabhängigen Zugang zu den betriebsinternen Daten und Systemen eines Unternehmens für die Mitarbeiter. Regionale Portale Regionale Portale (oder auch Informationsportale) bieten oft branchenübergreifende Dienste an. Angefangen von Verzeichnissen aller in der Region vorhandenen Unternehmen oder Dienstleistern, bis hin zu örtlichen Bekanntmachungen oder Neuigkeiten. Das in Kapitel vier vorgestellte Portal KLinfom gehört zu der letzten Kategorie. Der Trend gerade bei Kunden- oder Mitarbeiterportalen geht dazu hin, die offerierten Dienste mit existierenden Geschäftsprozessen, zugrunde liegenden Unternehmensinformationssystemen und Anwendungen zu integrieren [Spar02]. 16

17 Strategien zur Prozessorchestrierung und Workflow-Integration in Web-Applikationen 2.2 Geschäftsprozesse, Workflows & Workflow-Management Im Bereich der Geschäftsprozessmodellierung und des Workflow-Managements wurden insbesondere durch die Workflow Management Coalition (WfMC) versucht, mittels Standardisierungen eindeutige Definitionen für die relevanten Begriffe zu finden [Kühb02]. In der Literatur sind jedoch immer noch unterschiedliche Definitionen von Prozessen, Geschäftsprozessen, Workflows und Workflow-Management zu entdecken. In diesem Abschnitt soll deshalb versucht werden, Begriffsdefinitionen zu bestimmen, die eine gewisse Akzeptanz gefunden haben Geschäftsprozesse In der Literatur wird oft nicht genau zwischen den Begriffen Prozess und Geschäftsprozess unterschieden [VoBe96]. Zweifellos umfasst ein Prozess eine Kombination von Funktionen oder Aktivitäten die sowohl von Menschen als auch von Maschinen oder zumindest maschinen-gestützt durchgeführt werden können [Klat02]. Geschäftsprozesse sind ein Spezialfall von Prozessen, bei denen betriebswirtschaftlich relevante Objekte in den Prozess mit eingebunden sind. Ein Geschäftsprozess ist eine inhaltlich abgeschlossene zeitliche und sachlogische Abfolge von Funktionen oder Aktivitäten, die zur Bearbeitung eines betriebswirtschaftlich relevanten Objektes notwendig ist. Dieses Objekt prägt den Geschäftsprozess, weitere Objekte können in diesen Prozess einfließen. Geschäftsprozesse weisen zudem i. d. R. eine Schnittstelle zu externen (Markt-) Partnern auf [VoBe96]. Bei diesen Objekten kann es sich, neben materiellen Dingen, wie hergestellte Ware, auch um Informationsobjekte, wie Rechnungen oder Dokumente handeln. Ein typisches Beispiel für einen Geschäftsprozess ist die Abarbeitung einer Rechnung. Sie beginnt mit dem Rechnungseingang und führt über die Funktionen Rechnungsprüfung und Rechnungsbuchung bis zum Rechnungsausgleich [Gali03]. 17

18 Grundlagen Dieses Beispiel zeigt, dass an einem Geschäftsprozess mehrere Personen und Informationssysteme beteiligt sein können, eventuell auch mehrere externe Unternehmen. Im Bereich der Geschäftsprozesse und Workflows fallen zunehmend auch die Begriffe Orchestration und Choreography, besonders im Zusammenhang mit Web Services (siehe Kapitel 2.3), die einzelne Funktionen oder Aktivitäten eines Geschäftsprozesses realisieren können [MiMM03]. Orchestration bezieht sich auf einen ausführbaren Geschäftsprozess, der mit geschäftsinternen und -externen Web Services interagiert und beschreibt, wie diese Web Services miteinander interagieren können. Darin ist neben der Business Logik auch die Ausführungsreihenfolge der Interaktionen enthalten. Während Orchestration den gesamten Ablauf beschreibt, so beschreibt die Choreography lediglich den Nachrichtenaustausch zwischen den einzelnen Web Services und dessen Reihenfolge [Pelt03] Workflows & Workflow-Management Die Workflow Management Coalition definiert einen Workflow in etwa wie folgt [Kühb02]: Ein Workflow ist die Automation eines gesamten Geschäftsprozesses oder nur eines Teils, bei dem Dokumente, Informationen oder Aufgaben von einem Beteiligten zu einem anderen übergeben werden, um gewissen Aktionen durchzuführen, entsprechend vorgegebenen (Ablauf-) Regeln. Das heißt ein Workflow beinhaltet die rechnergestützte Ablauforganisation von Geschäftsprozessen durch ein Software-System [Gali03]. Die Technologie dazu heißt Workflow-Management. Das Software-System, das diese Unterstützung leistet, heißt Workflow-Management-System. Es ist ein System, dass Workflows komplett definiert, verwaltet und ausführt. 18

19 Strategien zur Prozessorchestrierung und Workflow-Integration in Web-Applikationen Im Gegensatz zu EAI-Systemen (Enterprise Application Integration), bei denen vollautomatisierte Prozesse im Vordergrund stehen, konzentrieren sich Workflow- Management-Systeme auf Arbeitsabläufe, bei denen Benutzerinteraktionen erforderlich sind [BoFL04]. Im Zusammenhang mit Workflows wird als Technologie oft die in Kapitel 3 ausführlich behandelte Sprache Business Process Execution Language for Web Services (BPEL4WS oder kurz BPEL) erwähnt. Doch BPEL stellt weder ein Workflow-Management-System dar, noch kann es ganze Workflows modellieren. Mit BPEL kann lediglich ein Teil eines Workflows realisiert werden, d. h. BPEL kann auch nur ein Teil eines größeren Workflow-Management- Systems sein, da BPEL für den Benutzer lediglich eine Schnittstelle bietet. Das Frontend, also die Oberfläche oder das Programm, mit dem der Benutzer auf einen mit BPEL erstellten Geschäftsprozess zugreifen kann, ist nicht in dieser Sprache enthalten, ebenso wenig wie ein durch Web Services realisierbares Backend. Die Business Process Execution Language for Web Services ist also vielmehr ein Mittel, um beispielsweise ein Portal und Web Services miteinander zu einem Workflow-Management-System zu verbinden und dabei die Web Services zu orchestrieren. 2.3 Web Services Die Bedeutung und die Verbreitung von Web Services haben in den vergangenen Jahren erheblich zugenommen. Im Zuge der immer stärkeren Vernetzung von Rechnern steigt der Bedarf an lose gekoppelten und verteilten Anwendungen. Web Services bieten sich an dieser Stelle an. Web Services sind eine relativ neue Technologie, auch wenn es sich dabei nicht wirklich um eine neue Erfindung handelt. Man nehme zwei Technologien, die erprobt und ausgereift sind, füge sie (mit einigen Extras) zusammen, kupfere dabei bei Middleware ab und gebe den Ganzen schließlich einen Eindrucksvollen Namen: Web Services [Lang03]. Bei den beiden erprobten Technologien handelt es sich um XML (Extended Markup Language) und RPC (Remote Procedure Call). Die Vorteile von Web Services liegen in der Unabhängigkeit von Programmiersprachen, da als Austauschformat der Daten XML verwendet wird, und in der Möglichkeit der losen Kopplung über ein Netz (LAN, WAN oder Internet). Unter Web Services versteht man allgemein Applikationen, die ihre Dienste über ein Web zur Verfügung stellen [Lang03]. Die Clients, die den Dienst der Applikation in Anspruch nehmen, kommunizieren mit dem Web Service über das auf XML basierende SOAP- 19

20 Grundlagen Protokoll. Das Trägerprotokoll kann dabei beliebig gewählt werden, wobei sehr häufig das weit verbreitete HTTP-Protokoll (HyperText Transfer Protocol) [BFG+99] verwendet wird. Die Standardisierungsorganisation W3C definiert Web Services wie folgt: Ein Web Service ist ein Softwaresystem, das durch eine URI identifiziert wird und dessen öffentliche Schnittstellen mit XML definiert und beschrieben werden. Die Definition des Web Service kann durch andere Softwaresysteme ermittelt werden. Diese Softwaresysteme können mit dem Web Service in einer Art und Weise interagieren, die in seiner Definition festgelegt wurde, und dabei XML-basierte Nachrichten austauschen, die von Internet-Protokollen transportiert werden. [CFNO02] In den beiden folgenden Abschnitten (2.3.1 und 2.3.2) soll nun kurz der Aufbau von Web Services erläutert werden, wobei ein Schwerpunkt auf die Beschreibung der Web Services durch WSDL (Web Service Description Language) gelegt wird, da WSDL auch zur Beschreibung von Geschäftsprozessen von der Sprache BPEL4WS verwendet wird. Auf detaillierte Erklärungen zum Aufbau zu Web Services und des SOAP-Protokolls wird an dieser Stelle verzichtet und auf [Lang03] und [Lins03] verwiesen Architektur Bei der Web Service-Architektur lassen sich drei unterschiedliche Rollen vergeben [Lang03]: Zum einen der Dienst-Anbieter, der Dienst-Konsument und die Gelben Seiten Der Dienst-Anbieter Der Dienst-Anbieter bietet eine Dienstleistung an, beispielsweise die Lieferung der Aktienkurse in Echtzeit. Der Dienst selber wird dabei als Web Service angeboten. Damit später dieser angebotene Dienst auch von einem Konsumenten problemlos in Anspruch genommen werden kann, muss dieser Dienst in einer standardisierten Form beschrieben werden. Der Standard zur Beschreibung von Web Services ist WSDL und wird in Kapitel näher erläutert. Die WSDL-Beschreibung ist somit vergleichbar mit der Interface Description Language (IDL) von klassischen Middleware-Technologien [Lang03]. 20

21 Strategien zur Prozessorchestrierung und Workflow-Integration in Web-Applikationen Der Dienst-Konsument Als Dienst-Konsumenten, oder auch Client, werden all diejenigen bezeichnet, die den Dienst eines Anbieters in Anspruch nehmen. Der Client kann dabei den von ihm gewünschten Web Service über die Gelben Seiten auswählen oder ihn direkt ansprechen. Die WSDL- Beschreibung des Web Service kann direkt über den Dienst-Anbieter abgefragt werden. Sobald alle notwendigen Informationen über den Web Service bekannt sind, kann der Client mittels RPC (Remote Procedure Call) direkt den Dienst ansprechen Die Gelben Seiten Die Gelben Seiten, oder auch Discovery Agency [Lins03], sind eine Art Anlaufpunkt für Konsumenten, die einen bestimmten Dienst in Anspruch nehmen wollen. Die Dienst-Anbieter können ihren Dienst bei dem zentralen Verzeichnis registrieren. Bei dieser Registrierung können detaillierte Informationen zu dem Dienst mit angegeben werden. Mit Hilfe dieser Informationen sind interessierte Dienst-Konsumenten in der Lage, den für sie relevanten Dienst in dem Verzeichnis aufzufinden. Die Beschreibung des Dienstes innerhalb des Verzeichnisses ist ebenfalls standardisiert und erfolgt mit UDDI (Universal Definition, Discovery and Integration). Die Relevanz dieser Gelben Seiten ist allerdings weniger groß. Oftmals ist der Bedarf an Suche bestimmter Dienste im Web nicht erforderlich ist, da alle verwendeten Dienste bekannt sind. Kommen Web Services in Geschäftsprozessen, die mittels BPEL4WS realisiert werden, zur Verwendung, so ist solch eine Registrierung sogar gänzlich unnötig, da dem Prozess alle beteiligten Web Services bei der Implementierung bekannt sein müssen. Die Registrierung eines Web Service in einem der zentralen Verzeichnisse ist für Web Services nicht zwingend erforderlich WSDL Die Web Service Description Language wurde von den Unternehmen Ariba, IBM und Microsoft entwickelt und mit der Version 1.0 im September 2000 zum ersten Mal veröffentlicht. Version 1.1 wurde im März 2001 veröffentlicht. Da die aktuelle Version

22 Grundlagen der Business Process Execution Language for Web Services (BPEL4WS) die WSDL- Spezifikation Version 1.1 verwendet, soll hier nur diese Version berücksichtigt werden. Der Standard von WSDL wird von der W3C wie folgt definiert: Die Web Services Description Language (WSDL) stellt ein Modell und ein XML-Format bereit, um Web Services zu beschreiben. WSDL ermöglicht die Separation der Beschreibung der abstrakten Funktionalität, die von einem Web Service angeboten wird, von den konkreten Details der Servicebeschreibung [CGMW03]. Kurz gesagt basiert WSDL auf XML und beschreibt einen Web Service, um später nicht nur von Menschen, sondern auch von anderen Softwaresystemen gelesen werden zu können. Auch diese Idee ist nicht neu und existierte schon vor den Web Services. Ein wesentlicher Bestandteil der Middelware-Technologie CORBA ist IDL, die Interface Description Language [OMGr04]. Ein Interface ist ein Methodenkatalog, in dem aufgelistet wird, welche Methode von Clientseite mit welchen Parametern und Rückgabetyp auf einem Server ausgeführt werden kann [Lang03]. Zudem können auch eigene Typdefinitionen festgelegt werden. Die Beschreibung dieser Methoden und der Typdefinitionen erfolgt bei CORBA mittels IDL. Der Sinn ist auch hier eine Unabhängigkeit von einer bestimmten Programmiersprache. Mit Hilfe eines Tools können durch Auslesen IDL-Datei beispielsweise entsprechende Java-Klassen generiert werden. Genau dasselbe ist bei Web Services möglich, nur das hier WSDL zur Beschreibung verwendet wird. Das WSDL-Dokument eines Web Service beantwortet im Wesentlichen die drei Folgenden Fragen [KoLe04]: Was bietet der Web Service? D. h. wie müssen die eingehenden Nachrichten aussehen, wie sehen die vom Web Service ausgehenden Nachrichten aus und welche Methoden bietet der Web Service an? Wie funktioniert der Datenaustausch? D. h..welche Protokolle werden verwendet und wie werden die Nachrichten kodiert? Wo befindet sich der Web Service? D. h. unter welcher Internet-Adresse ist der Web Service erreichbar? 22

23 Strategien zur Prozessorchestrierung und Workflow-Integration in Web-Applikationen Ein WSDL-Dokument besitzt grundsätzlich folgenden Aufbau: Im ersten Schritt erfolgt die Festlegung der unterschiedlichen Namespaces die in dem Dokument verwendet werden. <definitions targetnamespace= urn:fnp:fnpprocess xmlns:wsdlsoap= xmlns:wsdl= xmlns= > In WSDL können eigene einfache und komplexe strukturierte Datentypen definiert werden, die nicht vom XML Schema-Standard abgedeckt werden [Lang03]. Diese Datentypen werden in dem durch die Elemente <types></types> festgelegten Bereich definiert. <types> <complextype name= Adresse > <sequence> <element name= vorname type= xsd:string /> <element name= nachname type= xsd:string /> <element name= strasse type= xsd:string /> <element name= plz type= xsd:int /> <element name= ort type= xsd:string /> </sequence> </complextype> </types> Mit Hilfe der Elemente <message></message> werden in abstrakter Form die Nachrichten beschrieben, die von dem Web Service empfangen und gesendet werden. Die einzelnen Elemente einer Nachricht werden mittels einem oder mehreren <part/>-elementen festgelegt. Bei SOAP-RPC-Nachrichten, wie sie auch im Rahmen dieser Arbeit verwendet wurden, entsprechen die <part/>-elemente den Parametern beim Aufruf einer Methode des Web Service bzw. dem Rückgabewert. <message name= getkontostandrequest > <part name= name type= xsd:string /> <part name= vorname type= xsd:string /> <part name= kontonummer type= xsd:int /> <part name= blz type= xsd:int /> 23

24 Grundlagen </message> <message name= getkontostandresponse > <part name= kontostand type= xsd:int /> </message> Innerhalb des <porttype>-elementes wird festgelegt und beschrieben, welche Operationen des Web Service aufgerufen werden können und wie dieser Aufruf zu erfolgen hat, d. h. welche Parameter übergeben werden. <porttype name= > <operation name= getkontostand > <input message= getkontostandrequest /> <output message= getkontostandresponse /> </operation> </porttype> In diesem Beispiel besitzt der Web Service die Operation getkontostand. Der Aufruf dieser Operation erfolgt mit vier Parametern, die im <message>-element getkontostandrequest definiert sind: Name, Vorname, Kontonummer, BLZ. Als Rückgabewert liefert die Operation einen Wert vom Typ xsd:int, den Kontostand. In der WSDL-Datei wird zusätzlich innerhalb des <binding>-elementes definiert, an welches Nachrichtenformat und Übertragungsprotokoll die Schnittstelle mit den vorhandenen Operationen gebunden wird. Dies kann für jede einzelne Operation festgelegt werden. Siehe dazu [Lang03]. Als letztes wird innerhalb des <service>-elementes bestimmt, unter welcher Adresse der Web Service erreichbar ist. <!-- Name und Adresse des Web Service --> <service name= myexampleservice > <port name= binding= > </port> </service> </definition> <wsdlsoap:address location= /> 24

25 Strategien zur Prozessorchestrierung und Workflow-Integration in Web-Applikationen Zusammen mit dem eigentlichen Web Service wird dieses WSDL-Dokument einem potentiellen Client öffentlich zugänglich gemacht. Mit Hilfe von Tools kann ein Anwendungsentwickler nun beispielsweise auf der Clientseite dieses WSDL-Dokument auswerten und Grundgerüste für Java-Klassen erzeugen, um so den Arbeitsaufwand für den Entwickler zu verringern. Für weitergehende Informationen zu Web Services wird auf [Lang03] und [ACKM04] verwiesen. 25

26 Grundlagen 26

27 Strategien zur Prozessorchestrierung und Workflow-Integration in Web-Applikationen 3. Business Process Execution Language BPEL4WS (auch BPEL) ist die Abkürzung für Business Process Execution Language for Web Services. BPEL4WS ist eine XML Sprache mit der Geschäftsprozesse spezifiziert werden können. BPEL ermöglicht es, verteilte Web Services zu Geschäftsprozessen zusammenzufassen und unterstützt dabei die Interaktion zwischen den Web Services untereinander und die Interaktion mit dem Client. Auf diese Weise ist es möglich, die Geschäftslogik des Prozesses von der eigentlichen Anwendung zu trennen. BPEL ist mittlerweile zu einem anerkannten Standard für die Komposition von Web Services geworden. Mit BPEL ist es möglich komplexe Prozesse zu erstellen, indem unterschiedliche Aktivitäten erstellt und zusammengefasst werden können [Aals03]. Bei den Aktivitäten kann es sich beispielsweise um den Aufruf von Web Services handeln, die Manipulation von Daten oder das Abfangen und Behandeln von Fehlern innerhalb des Prozesses. Diese einzelnen Aktivitäten können verschachtelt werden und zu Abläufen, wie Schleifen oder einer parallelen Abarbeitung, kombiniert werden. Die Kommunikation des Prozesses mit dem Client und anderen Web Services erfolgt über das Web Service Interface. Der BPEL-Geschäftsprozess kann also vereinfacht als ein aus Web Services zusammengesetzter Web Service betrachtet werden. Auf diese Weise bleibt dem Client die interne Prozessstruktur verborgen, ebenso wie dessen Kommunikation mit anderen im Prozess eingebundenen Web Services. Abbildung 1 zeigt ein Schema eines BPEL-Prozesses. Mittels BPEL wird ein neuer Web Service aus einer Reihe von bereits vorhandenen Web Services erstellt. Sowohl die Kommunikation zwischen dem Geschäftsprozess und den Web Services, als auch mit dem Client erfolgt über das WSDL-Interface (siehe Kapitel 2.3.2). Die prozessinterne sequentielle oder parallele Abarbeitung der Schritte bleibt dem Benutzer verborgen. 27

28 Business Process Execution Language for Web Services Abbildung 1 BPEL - Allgemeines Schema [Pelt03] Ein in diesem Fall häufig aufgeführtes Beispiel ist die Buchung eines Urlaubs über einen Reiseanbieter. Der Kunde startet den Geschäftsprozess, indem er den BPEL-Prozess des Reiseanbieters aufruft. Anhand der vom Kunden übermittelten Informationen wird im BPEL- Prozess ausgewählt, ob ein Ticket bei der Bahn oder bei einer Fluggesellschaft gebucht werden soll. Dementsprechend wird über ein Web Service der Bahn eine Fahrkarte für den Kunden bestellt. Zusätzlich werden gegebenenfalls Hotel- oder Autoreservierungen vorgenommen. Abschließend wird der Bank des Kunden eine Rechnung übermittelt. Der Kunde selbst bekommt dann eine Bestätigung vom Reiseanbieter, dass sein Urlaub erfolgreich gebucht wurde. Der zunehmende Bedarf an Standards, um mehrere Web Services zu Business Prozessen zusammen zu fassen, führte zu einer ganzen Reihe von unterschiedlichen und miteinander konkurrierenden Spezifikationen, wie beispielsweise PDL (Process Definition Language) [CSPP04], XPDL (XML Process Definition Language) [WMCo02], BPSS (Business Process Specification Schema) [BPrT01], EDOC (Enterprise Distributed Object Computing) [CBO+01], BPML (Business Process Modeling Language) [Arka02], WSDL [CGMW03], 28

29 Strategien zur Prozessorchestrierung und Workflow-Integration in Web-Applikationen WSCI (Web Service Choreography Interface) [AAF+02], ebxml (Electronic Business using extensible Markup Language) [Arka02] oder BPEL4WS. Die Fülle an sich überlappenden Standards für Web Services ist enorm. Einige Autoren bezeichnen diese miteinander konkurrierenden Standards deshalb scherzhaft auch als die Hölle der Web Services Akronyme [Aals03]. Die Business Process Execution Language for Web Services basiert auf den beiden Spezifikationen WSFL (Web Services Flow Language) [Leym01] von IBM und XLANG (Web Services for Business Process Design) [That01] von Microsoft. XLANG ist eine Sprache mit hierarchischen Strukturen und stellt beispielsweise Kontrollflussstrukturen wie Sequenzen, Switch-Anweisungen oder While-Schleifen zur Verfügung. WSFL erlaubt im Gegensatz dazu direkte Graphen, wobei die Graphen zwar geschachtelt, aber nicht azyklisch erstellt werden dürfen [Aals03]. Abbildung 2 BPEL Historie [Sher03] Abbildung 2 zeigt die zeitliche Entwicklung von BPEL auf [Sher03]. Dezember 2000 veröffentlichte Microsoft die erste Spezifikation von XLANG. Im März 2001 folgte die erste Spezifikation von WSFL seitens IBM. Im August 2002 wurden XLANG und WSFL zusammengefügt und die erste Version (1.0) der Spezifikation der Business Process Execution Language for Web Services veröffentlicht. Collaxa lieferten die erste komplette Implementation von BPEL 1.0. Im Mai 2003 erschien Version 1.1 von BPEL4WS, gegenwärtig wird an Version 2.0 gearbeitet. 29

30 Business Process Execution Language for Web Services BPEL4WS (Version 1.1) hängt von den folgenden XML-basierten Spezifikationen ab: WSDL 1.1, XML Schema 1.0, XPath 1.0 und WS-Adressing. BPEL baut auf dem Service Modell auf, das durch WSDL 1.1 definiert ist. Der BPEL-Geschäftsprozess und die Partner des Prozesses werden als WSDL Services modelliert. Ein Geschäftsprozess in BPEL definiert die Koordination der Interaktionen zwischen der Prozessinstanz und den Partnern [And+03]. Abbildung 3 BPEL und Web Service Protokoll Hierarchie Abbildung 3 (in Anlehnung an [FiWe04]) zeigt die Position von BPEL in der Web Service Architektur. Grundsätzlich lassen sich dabei vier Schichten unterscheiden: Transport-Schicht: Über die unterste Schicht tauschen die Web Services bzw. der BPEL-Geschäftsprozess Informationen aus. Die versendeten Nachrichten werden über Protokolle wie HTTP (Hypertext Transfer Protocol), SMTP (Simple Mail Transfer Protocol) oder FTP (File Transfer Protocol) übertragen. Nachrichten-Schicht: In dieser Schicht werden die übertragenen Informationen de- bzw. encodiert. Verwendet werden hier auf XML basierende Formate wie XML-RPC oder SOAP. Beschreibung: An dieser Stelle erfolgt die Beschreibung des Web Services, d.h. seine Schnittstelle nach außen. Zur Beschreibung wird sowohl für Web Services als auch für BPEL-Geschäftsprozesse WSDL (Web Service Description Language) verwendet. 30

31 Strategien zur Prozessorchestrierung und Workflow-Integration in Web-Applikationen Orchestrations-Schicht: In der obersten Schicht erfolgt die Beschreibung, wie die Web Services miteinander interagieren können. Hier wird die Business Logik und die Ausführungsreihenfolge der Web Services beschrieben. Die Orchestration kann beispielsweise mit BPEL4WS erfolgen. Bei Geschäftsprozessen in BPEL wird grundsätzlich zwischen zwei Typen von Prozessen unterschieden [WCK+04]: Ausführbaren Geschäftsprozessen und Abstrakten Geschäftsprozessen. Ausführbare Geschäftsprozesse beschreiben den kompletten Ablauf eines Prozesses sowie dessen Interaktion mit anderen Web Services. Mit BPEL4WS beschriebene ausführbare Geschäftsprozesse können von einer BPEL4WS-Engine gelesen, instanziiert und ausgeführt werden. Abstrakte Geschäftsprozesse hingegen beschreiben nur einen Teil eines Prozesses. So werden die öffentlichen Rahmenbedingungen beim Nachrichtenaustausch festgelegt und der Prozess allgemein beschrieben. Diese abstrakte Beschreibung dient dazu, die Integration und das Verständnis des Prozessablaufes für die Partner zu vereinfachen, die mit dem Prozess interagieren möchten. Interne, eventuell auch vertrauliche Details des Prozesses bleiben dem Partner dabei verborgen. In dieser Arbeit sollen abstrakte Geschäftsprozessbeschreibungen mit BPEL jedoch außer Acht gelassen werden. Einem BPEL-Prozess liegt ein bestimmtes Lebenszyklus-Modell zugrunde. Die Partner des Geschäftsprozesses, Clients oder Web Services, interagieren mit einer speziellen Instanz eines Prozesses. Im Gegensatz zu objekt-orientierten Programmiersprachen werden die Instanzen in BPEL nicht explizit erzeugt, sondern implizit sobald eine Nachricht an die noch nicht erzeugte Instanz eines Prozesses geschickt wird [FiWe04], siehe dazu auch Kapitel Eine Instanz wird terminiert, sobald die letzte Aktivität eines Prozesses abgearbeitet wurde oder innerhalb des Kontrollflusses eine explizit angegebene Aktivität zur Terminierung des Prozesses erreicht wird. Im Folgenden soll nun der Aufbau und die einzelnen Elemente eines BPEL-Prozesses genau erläutert werden. 31

32 Business Process Execution Language for Web Services 3.1 Aufbau eines BPEL-Prozesses Die Beschreibung eines BPEL-Prozesses besteht im Wesentlichen aus drei Hauptelementen: 1. WSDL-Beschreibungen von Partnern (optional) 2. WSDL-Beschreibung des Prozesses 3. BPEL-Prozessbeschreibung Die WSDL-Beschreibungen von Partnern beinhalten die Schnittstellenbeschreibung der Web Services, die vom Geschäftsprozess angesprochen werden oder selber den Prozess ansprechen. Diese WSDL-Beschreibungen werden zusammen mit dem zum Geschäftsprozess zugehörigen Web Services als vorhanden vorausgesetzt. Da der Geschäftsprozess in BPEL4WS einem Client als Web Service angeboten wird, wird eine WSDL-Beschreibung des Prozesses benötigt. Das WSDL-Dokument des Prozesses beschreibt, genau wie bei einem Web Service, die Schnittstelle nach außen. Bestandteile der WSDL-Beschreibung sind u.a. [KaBu03]: Definition von (komplexen) Datentypen Messages PartnerLinkTypen PortTypes Die Prozessbeschreibung stellt die eigentliche Definition des Prozesses dar und erfolgt innerhalb eines BPEL-Dokumentes. Grundsätzlich haben BPEL-Dokumente folgenden Grundaufbau [And+03]: 32

33 Strategien zur Prozessorchestrierung und Workflow-Integration in Web-Applikationen <! > <process name= ncname targetnamespace= uri <!-- Standard: XPath 1.0 URI (optional) --> querylanguage= anyuri <!-- Standard: XPath 1.0 URI (optional) --> expressionlanguage= anyuri <!-- joinfailure für alle Aktivitäten unterdrücken (optional) --> suppressjoinfailure= yes no <!-- Prozessinstanz als Ganzes kompensierbar? (optional) --> enableinsancecompensation= yes no <!-- abstrakter oder ausführbarer Prozess? (optional) --> abstractprocess= yes no xmlns= > <!-- unterschiedliche Links zu einem oder mehreren Partnern --> <partnerlinks> <partnerlink name= ncname partnerlinktype= qname </partnerlinks> myrole= ncname partnerrole= ncname ></partnerlink> <!-- die Partner des BPEL-Prozesses --> <partners> <partner name= ncname > </partner> </partners> <partnerlink name= ncname \> <!-- (globale) Variablen --> <variables> <variable name= ncname type= xsd:int /> </variables> <!-- Identifikationsmerkmale --> <correlationsets> <correlationset name= ncname properties= qname-list /> </corelationsets> <!-- Reaktionen im Falle eines Fehlers einer Aktivität --> <faulthandlers> <catch faultname= qname faultvariable= ncname > </catch> <catchall> </catchall> </faulthandlers> <!-- Aktivitäten --> <!-- Aktivitäten --> 33

34 Business Process Execution Language for Web Services <!-- Kompensation von bereits ausgeführten Aktivitäten --> <compensationhandler> <!-- Aktivitäten --> </compensationhandler> <!-- Ereignisbehandlung --> <eventhandlers> <onmessage partnerlink= ncname porttype= qname operation= ncname variable= ncname > <correlations> <correlation set= ncname initiate= yes no /> </correlations> <!-- Aktivitäten --> </onmessage> <onalarm for= duration-expr until= deadline-expr > <!-- Aktivitäten --> </onalarm> </eventhandlers> <!-- der eigentliche Prozessablauf --> <!-- Aktivitäten --> </process> Der Platzhalter <!-- Aktivitäten --> kann dabei durch folgende Elemente ersetzt werden: receive, invoke, reply, assign, throw, terminate, wait, empty, sequence, switch, while, pick, flow, scope, compensate. Diese einzelnen Aktivitäten werden in den folgenden Abschnitten detailliert erläutert. 34

35 Strategien zur Prozessorchestrierung und Workflow-Integration in Web-Applikationen Interaktion BPEL dient in erster Linie dazu, mehrere Web Services zu einem gesamten Geschäftsprozess zusammenzufassen. Aus diesem Grund ist die Interaktion zwischen dem Prozess und anderen Web Services integraler Bestandteil von BPEL4WS Partner Links Alle Verbindungen vom Geschäftsprozess zu Web Services oder Clients werden in BPEL4WS als Partner Links bezeichnet. Dabei definiert ein Partner Link genau eine bestimmte Beziehung zwischen dem Prozess und Web Service oder dem Client. Das folgende Beispiel zeigt eine Beziehung zwischen dem Geschäftsprozess und einem Client. <partnerlinks> <partnerlink name= echotest partnerlinktype= echokontakt myrole= dasecho partnerrole= derrufende /> </partnerlinks> Jeder Partner Link ist von einem bestimmten Typ (Partner Link Type). Es können somit mehrere Partner Links von einem Partner Link Type existieren. So könnte in dem oben gezeigten Beispiel ein Partner Link mit dem Namen langerechotest erstellt werden, der ebenfalls vom Partner Link Typ echokontakt ist. Die Rolle des definierten Geschäftsprozesses wird durch das Attribut myrole definiert, die Rolle des Partners durch das optionale Attribut partnerrole Partner Link Types Die Definition von Partner Link Types erfolgt nicht im BPEL-Dokument, sondern in der WSDL-Beschreibung des Geschäftsprozesses. Partner Link Types charakterisieren die Beziehung zwischen zwei Web Services, bzw. im Speziellen zwischen einem Geschäftsprozess und einem Web Service. Bei der Definition werden die Rollen der beiden 35

36 Business Process Execution Language for Web Services beteiligten Partner festgelegt, sowie die entsprechenden Port Types (siehe Kapitel 2.3.2), um die Nachrichten im entsprechenden Kontext zu erhalten. Ein Partner Link Type wird wie folgt definiert: <partnerlinktype name= echokontakt xmlns= > <role name= dasecho > </role> </partnerlinktype> <porttype name= echoport /> Jede Rolle spezifiziert genau einen WSDL Port Type. Normalerweise stammen die Port Types von unterschiedlichen Namespaces der jeweils beteiligten Partner. In diesem Falle sei der porttype zusammen mit der zu übertragenden Nachricht in der WSDL-Datei des Prozesses wie folgt definiert <message name= textnachricht > </message> <part name= echotext type= xsd:string /> <porttype name= echoport > <operation name= echo > <input message= textnachricht /> <output message= textnachricht /> </operation> </porttype> Business Partner Geschäftsprozesse bestehen in den meisten Fällen aus mehreren Beziehungen zwischen zwei Partnern, d. h. die Interaktion mit einem Geschäftspartner erfordert mehrere Partner Links. Geschäftspartner werden in BPEL4WS als Partner bezeichnet. Ein Partner kann dabei einen oder mehrere (Web) Services anbieten, die Bestandteil des gesamten Geschäftsprozesses sind. Das folgende Beispiel zeigt die Definition eines Partners im BPEL-Dokument: 36

37 Strategien zur Prozessorchestrierung und Workflow-Integration in Web-Applikationen <partner name= echopartner > <partnerlink name= echotest \> <partnerlink name= langerechotest \> </partner> Die Definitionen von Partnern sind optional. Ein Partner Link darf in höchstens einer Partnerdefinition vorkommen, allerdings müssen die in der WSDL-Beschreibung definierten Partner Links nicht alle durch die Partnerdefinitionen abgedeckt werden [And+03] Kommunikation BPEL bietet drei unterschiedliche Aktivitäten zur Kommunikation mit Web Services bzw. einem Client an: receive, reply und invoke. Receive Die Aktivität receive empfängt eine von einem Web Services gesendete Nachricht. Sie spezifiziert, über welchen Nachrichtenkanal der Prozess die Nachricht empfängt und in welcher Variablen der Nachrichteninhalt abgelegt wird [Stah04]. <receive partnerlink="echotest" porttype="echoport" operation="echo" variable="frage" createinstance="yes" name="echofrage"/> Das oben stehende Beispiel zeigt eine Definition der <receive>-aktivität in BPEL, wobei die Aktivität durch einen Namen (Attribut name) eindeutig gekennzeichnet ist. Die eigentliche empfangene Nachricht wird in der Variable frage abgespeichert, die ebenfalls im BPEL-Dokument definiert sein muss: <variables> <variable name= frage messagetype= textnachricht /> </variables> 37

38 Business Process Execution Language for Web Services Die Nachricht ist vom Typ textnachricht, der in der WSDL-Beschreibung des Prozesses festgelegt wurde. Instanzen werden in BPEL implizit durch eingehende Nachrichten erzeugt. Mit receive kann solch eine Instanz erzeugt werden. Wird das Attribut createinstance auf yes gesetzt, wird eine Instanz des Geschäftsprozesses erzeugt, sobald entsprechende Nachricht beim Prozess eintrifft. Siehe dazu auch Kapitel Reply Mit reply wird bei einer synchronen Kommunikation mit einem Web Service die Antwort auf eine mit reveive empfangene Nachricht zurück geschickt. Die Aktivität reply wird wie folgt definiert: <reply partnerlink= echotest porttype= echoport operation= echo variable= frage name= echoantwort /> In diesem Beispiel wird die mit receive zuvor empfangene Nachricht, die in der Variablen frage abgespeichert wurde, unverändert wieder zurückgeschickt. Ebenso wie bei receive wird die Aktivität mit einem eindeutigen Namen durch das Attribut name gekennzeichnet. Invoke Bei der Aktivität invoke wird zwischen der asynchronen und der synchronen Aktivität invoke unterschieden [Stah04]. Beim asynchronen invoke wird vom Prozess ein Web Service aufgerufen. Dabei wird die als Input-Variable definierte Nachricht an den Web Service geschickt. Es erfolgt keine Antwort des Web Service. 38

39 Strategien zur Prozessorchestrierung und Workflow-Integration in Web-Applikationen Die synchrone Variante des invoke dient zum normalen Nachrichtenaustausch, wobei wieder die als Input-Variable definierte Nachricht an den Web Service geschickt wird. Die vom Web Service empfangene Antwort wird in der in invoke festgelegten Output- Variablen gespeichert. Das folgende Beispiel zeigt die Definition der synchronen <invoke>-aktivität: <invoke name="uebersetzeraufrufen" partnerlink="babelfishservice" porttype="babelfish:babelfishporttype" operation="babelfish" inputvariable="englischertext" outputvariable="deutschertext"/> Bei der asynchronen Variante wird das Attribut outputvariable nicht benötigt. Im Gegensatz zu den Aktivitäten reply und receive kann bei invoke direkt die Fehlerbehandlung bzw. die Kompensation erfolgen und braucht nicht in das umschließende Scope eingebunden werden. Siehe dazu auch die beiden folgenden Kapitel und Scopes Scopes (Gültigkeitsbereiche) dienen in BPEL dazu, eine oder mehrere Aktivitäten in einem gemeinsamen Kontext zusammenzufassen. Innerhalb eines Scopes können Variablen und zu Aktivitäten entsprechende Fehlerbehandlungen, sowie Ereignisse, Korrelationsmengen und Kompensationen definiert werden, die nur innerhalb dieses Scopes sichtbar und nur für diesen Scope gültig sind. Jeder Scope hat eine Aktivität, die dessen normales Verhalten darstellt. Diese Aktivität kann dabei auch eine komplexe strukturierte Aktivität darstellen, die beliebig tief verschachtelt werden kann. Scopes können weitere Scopes beinhalten. Das folgende Beispiel zeigt einen möglichen Aufbau eines Scopes. <scope> <variables> </variables> <correlationsets> </corellationsets> <faulthandler> </faulthandler> <eventhandler> </eventhandler> 39

40 Business Process Execution Language for Web Services <!-- Aktivitäten: --> <flow> </flow> </scope> <invoke /> <invoke /> Fehlerbehandlung Die Fehlerbehandlung in einem Geschäftsprozess wird benötigt, sobald das tatsächliche Verhalten des Prozesses von seinem geplanten Verhalten abweicht. Fehler können sowohl intern innerhalb des Prozesses, als auch extern durch Fehler beim Aufruf von Web Services erzeugt werden. BPEL4WS bietet eine Fehlerbehandlung an (faulthandler), um mögliche Fehler abzufangen und um entsprechend auf die Fehler reagieren zu können. Eine Fehlerbehandlung kann für jeden Scope und für den gesamten Prozess festgelegt werden. Bei der Behandlung des Fehlers sollen die unvollständig und nicht korrekt abgeschlossenen Aktivitäten eines Scopes, in dem der Fehler aufgetreten ist, rückgängig gemacht werden. Auch wenn die Fehlerbehandlung eines Scopes erfolgreich abgeschlossen wird, so wird der Scope weiterhin als nicht abgeschlossen betrachtet, so dass die erfolgreiche Beendigung des Scopes oder der Aufruf einer entsprechenden Kompensation nicht mehr möglich ist. Das folgende Beispiel zeigt eine Definition eines FaultHandlers in BPEL [And+03]: <faulthandlers> <catch faultname= fehler1 faultvariable= variable1 > <!-- Aktivität(en) --> </catch> <catch faultname= fehler2 > <!-- Aktivität(en) --> </catch> <catch faultvariable= variable2 > <!-- Aktivität(en) --> </cach> <catchall> <!-- Aktivität(en) --> </catchall> </faulthandlers> 40

41 Strategien zur Prozessorchestrierung und Workflow-Integration in Web-Applikationen Innerhalb eines faulthandlers können mehrere <catch>-aktivitäten definiert werden. Jede dieser Catch-Aktivitäten dient dazu, genau einen bestimmten Fehler abzufangen. Identifiziert wird ein Fehler durch einen eindeutigen Fehlernahmen und dem Namen einer Variablen, deren Daten mit dem Fehler assoziiert werden. Zusätzlich kann eine <catchall>-aktivität festgelegt werden, die alle Fehler abfängt, die nicht explizit durch <catch>-aktivitäten abgedeckt werden. Die Attribute faultname und faultvariable in der <catch>-aktivität sind optional, wobei mindestens einer dieser Attribute vorhanden sein muss. Eine Sonderstellung bei der Fehlerbehandlung nimmt die Aktivität invoke ein. Beim Aufruf von invoke kann die Fehlerbehandlung direkt mit angegeben werden und muss nicht in die Fehlerbehandlung des umschließenden Scopes eingebunden werden. Dieses Beispiel zeigt einen Ausschnitt der WSDL-Beschreibung eines angesprochenen Web Service. <porttype name= clientport > <operation name= getkontostand > <input message= getkontostandrequest /> <output message= getkontostandresponse /> <fault name= falschekontonummer message= getkontostandfalschekontonummer /> </operation> </porttype> Der Aufruf der Operation getkontostand sollte normalerweise eine Nachricht vom Typ getkontostandresponse liefern. Im Fehlerfall wird jedoch vom Web Service eine Exception geworfen. Diese Exception kann in BPEL wie folgt abgefangen werden: <invoke operation= getkontostand > <catch faultname= ws1:falschekontonummer > <empty name= tuenichts /> </catch> </invoke> Hier wird die Fehlerbehandlung direkt nach dem Invoke durchgeführt. 41

42 Business Process Execution Language for Web Services Neben den durch den Benutzer festgelegten Fehlern können auch Laufzeitfehler auftreten. BPEL unterscheidet zwischen folgenden Laufzeitfehlern: selectionfailure, conflictingreceive, conflictingrequest, mismatchedassignmentfailure, joinfailure, forcedtermination, correlationviolation, uninitializedvariable, repeatedcompensation und invalid Reply [And+03] Kompensation Wenn mehrere Aktivitäten wie geplant durchgeführt wurden, kann es notwendig sein, einige davon wieder rückgängig zu machen. Wurde beispielsweise in einem ersten Schritt ein Zimmer in einem Hotel gebucht, in einem zweiten Schritt versucht einen Flug zu dem Zielort zu erhalten, so muss die Hotelbuchung rückgängig gemacht werden können, falls kein Flug mehr verfügbar ist. Ein einfaches undo kann hier nicht durchgeführt werden. BPEL bietet hier die Möglichkeit der Kompensation. Zu jedem Scope kann ein optionaler Compensation Handler festgelegt werden, der alle notwendigen Aktivitäten beinhaltet, die benötigt werden, um die im Scope durchgeführten Aktivitäten rückgängig zu machen bzw. zu kompensieren. Dieser Compensation Handler wird erst aktiv, sobald ein Scope komplett abgeschlossen wurde. Das folgende Beispiel zeigt eine Definition eines Compensation Handlers: <scope name= Flugbuchung > <compensationhandler> <invoke /> </compensationhandler> <invoke /> </scope> Der Compensation Handler kann nur über die <compensate>-aktivität aufgerufen werden, wobei der Name des entsprechenden Scopes als Attribut angegeben werden muss. <compensate scope= Flugbuchung /> 42

43 Strategien zur Prozessorchestrierung und Workflow-Integration in Web-Applikationen Wird ein Compensation Handler eines Scopes aufgerufen, der noch nicht abgeschlossen wurde, so wird automatisch die <empty>-aktivität ausgeführt und nicht die Aktivitäten des Compensation Handlers. Die Compensate-Aktivität kann nur in den folgenden Abschnitten eines Geschäftsprozesses aufgerufen werden: im Fault Handler eines den Scope direkt umschließenden weiteren Scopes im Compensation-Handler eines den Scope direkt umschließenden weiteren Scopes Die folgende Abbildung 4 veranschaulicht den Aufruf der Compensate-Aktivität: Abbildung 4 BPEL Compensation Handler Alle Aktivitäten der Scopes B und C wurden bereits ausgeführt. Ein Fehler bei einer Aktivität im Scope A führt dazu, dass der Catch-Block des Scopes ausgeführt wird. Innerhalb dieses Blocks wird der Compensation Handler des Scopes B ausgerufen, um alle Aktivitäten aus Scope B zu kompensieren. Innerhalb des Compensation Handlers von Scope B wird wiederum der Compensation Handler von Scope C aufgerufen. 43

44 Business Process Execution Language for Web Services Variablen Instanzen von Business Prozessen in BPEL besitzen einen Zustand, der sich aus den empfangenen Nachrichten, den gesendeten Nachrichten und anderen für den Prozess relevanten Daten, beispielsweise dem aktuelle Wert eines Zählers in einer Schleife, zusammensetzt [And+03]. Zum Speichern dieser Werte verwendet BPEL4WS Zustandsvariablen oder kurz Variablen. Um den Kontrollfluss eines Business Prozesses steuern zu können, muss auf die Variablen zugegriffen werden können, um beispielsweise Vergleiche durchführen zu können. BPEL bietet diese Möglichkeit. Eine Variable kann ein WSDL-Nachrichtentyp, ein einfacher XML Schema-Datentyp oder ein XML Schema-Element sein. Variablen werden in BPEL wie folgt deklariert: <variables> <variable name= var_1 messagetype= InvMessage /> <variable name= var_2 type= xsd:int /> <variable name= var_3 element= Kundenkonto /> </variables> Dieses Beispiel zeigt die drei unterschiedlichen Varianten von Variablendefinitionen in BPEL4WS. Das Element variable kann neben dem Attribut name, das den eindeutigen Namen der Variable festlegt, eins von drei weiteren Attributen besitzen: messagetype bezieht sich auf die Definition eines WSDL-Nachrichtentyps, das Attribut type auf einen einfachen Typ ( Simple Type ) eines XML Schemas (z.b. xsd:int). Das dritte Attribut element bezieht sich auf ein Element des XML Schemas. Um komplexe Typen ( Complex Type ) eines XML Schemas als Variablentyp in BPEL verwenden zu können, muss der Typ mit einem Element assoziiert werden. In BPEL wird zwischen lokalen und globalen Variablen unterschieden, abhängig von dem Sichtbarkeitsbereich, in dem sie definiert werden. Siehe dazu auch Kapitel In einem Business Prozess ist jedoch auch notwenig, Werte von einer Variablen zu einer anderen zu kopieren oder neue Werte einer Variablen zuzuweisen, beispielsweise bei der Erhöhung eines Zählers in einer Schleife. Die Wertänderung einer Variablen erfolgt mittels der <assign>-aktivität. 44

45 Strategien zur Prozessorchestrierung und Workflow-Integration in Web-Applikationen <assign> <copy> <from> </from> <to variable= meinkontostand /> </copy> <copy> <from variable= alte_adresse part= strasse /> <to variable= neue_adresse part= strasse /> </copy> </assign> In einer <assign>-aktivität können ein oder mehrere copy-elemente eingefügt werden. Das Element from kann alternativ zu einem literalen Wert mehrere Attribute besitzen, wobei das Attribut part optional ist [And+03]: <from variable= ncname part= ncname /> <from variable= ncname property= qname /> <from partnerlink= ncname endpointreference= myrole partnerrole /> <from expression= general-expr /> Das Attribut part darf nicht verwendet werden, wenn es sich bei den Variablen um einfache Typen ( SimpleType ) eines XML Schemas handelt. In dem Element to können mehrere unterschiedliche Attribute festgelegt werden: <to variable= ncname part= ncname /> <to partnerlink= ncname /> <to variable= ncname property= qname /> Bevor Variablen in BPEL verwendet werden können, müssen sie initialisiert werden. Diese Initialisierung geschieht automatisch, falls die Variable einer Aktivität wie receive oder invoke als Parameter übergeben und damit automatisch mit einem bestimmten Wert belegt wurde. Soll aber beispielsweise der Rückgabewert von einem Aufruf eines Web Service in eine andere Variable kopiert werden, die bis zu diesem Zeitpunkt noch nicht verwendet wurde, so 45

46 Business Process Execution Language for Web Services muss diese Variable zuvor initialisiert werden. Das folgende Beispiel zeigt eine solche Initialisierung: <assign> <copy> <from> <adresse xmlns= > <name/> <strasse>testweg</strasse> <ort/> <plz>12345</plz> </adresse> </from> <to variable= ausgabe part= adresse > </copy> </assign> Die Variable ausgabe ist im BPEL-Dokument definiert: <variable name= ausgabe messagetype= tns:ausgabenachricht /> Die Nachricht ausgabenachricht ist in der WSDL-Beschreibung des Prozesses definiert: <message name= ausgabenachricht > </message> <part name= daten element= tns:adresse > Bei adresse handelt es sich um einen komplexen Datentyp, der aus einer Reihe von einfachen Elementen (siehe Beispiel oben) besteht und ebenfalls in der WSDL-Beschreibung des Prozesses definiert wird. Soll in diesem Beispiel ein neuer Wert in das Element PLZ eingefügt werden, muss auf ein Element des Datentyps adresse zugegriffen werden. Der Zugriff auf diese Elemente erfolgt über Querys: <assign> 46 <copy>

47 Strategien zur Prozessorchestrierung und Workflow-Integration in Web-Applikationen <from>67653</from> <to variable= ausgabe part= daten query= /adresse/plz /> </copy> </assign> Innerhalb von Prozessen ist es oftmals notwendig, direkt auf die Werte zugreifen zu können, um in Bedingungen Vergleiche durchführen zu können. In BPEL wird dies mit der Funktion bpws:getvariabledata ermöglicht: <variable name= vorhanden type= xsd:boolean /> <variable name= textnachricht messagetype= tns:textnachricht /> <variable name= ausgabe messagetype= tns:ausgabenachricht /> <while condition= bpws:getvariabledata( vorhanden ) > <!-- --> </while> <while condition= bpws:getvariabledata( textnachricht, text ) = hallo > <!-- --> </while> <while condition= bpws:getvariabledata( ausgabe, daten, /plz ) = > <!-- --> </while> In diesem Beispiel sei der Typ textnachricht eine Nachricht mit dem Element text vom Typ xsd:string, der Typ ausgabenachricht bezieht sich auf das vorangegangene Beispiel Ausdrücke Ausdrücke werden in BPEL bei mehreren Aktivitäten zur Bestimmung des weiteren Prozessablaufs benötigt, beispielsweise als Bedingung einer While-Schleife oder in einer Wait-Anweisung. Bei BPEL werden zwischen folgenden unterschiedlichen Typen von Ausdrücken unterschieden [And+03]: - boolsche Ausdrücke - deadline-valued Ausdrücke 47

48 Business Process Execution Language for Web Services - duration-valued Ausdrücke - generelle Ausdrücke BPEL4WS unterstützt die Verwendung von XPath 1.0 als Ausdruckssprache. Siehe dazu auch [ClDe99] und [WWWC04]. Boolsche Ausdrücke Boolsche Ausdrücke entsprechen der XPath 1.0 Expression [ClDe99], deren Auswertung einen boolschen Wert ergibt. Beispiele hierfür sind true(), false(), 1 = 1, 1 < 2, 1!= 1. Boolsche Ausdrücke werden u. a. in der <while>-aktivität oder im Case-Element der <switch>-aktivität verwendet. Deadline-Valued Ausdrücke Die Auswertung der XPath Ausdrücke muss einen Wert vom XML Schema Typ datetime oder date ergeben. Ein Beispiel hierfür ist T18:00:00. Siehe dazu auch [WWWC04]. Duration-Valued Ausdrücke Alle XPath Ausdrücke, die als Auswertung den Typ duration ergeben, können an dieser Stelle eingesetzt werden. In BPEL werden Ausdrücke dieser Art in der <wait>- Aktivität benutzt. Der Ausdruck besteht i. d. R. aus zwei Teilen: Einer Zeiteinheit, die größer gleich ein Tag ist, gefolgt von einer Zeiteinheit, die kleiner als ein Tag ist. Getrennt werden die beiden Teile von dem Separator T. Dieser Separator muss nur dann hinzugefügt werden, wenn die Zeitangabe auch Stunden, Minuten oder Sekunden beinhaltet. <wait for= P1Y2M3DT4H5M6S /> In diesem Beispiel wird der Prozess für ein Jahr, zwei Monate, drei Tage, vier Stunden, fünf Minuten und sechs Sekunden angehalten. Dem Ausdruck muss immer 48

49 Strategien zur Prozessorchestrierung und Workflow-Integration in Web-Applikationen ein P voranstehen. Beträgt der Wert des Jahres, des Tages oder anderen Einheiten null, so kann der entsprechende Bezeichner (z. B. Y für Year) weggelassen werden. Generelle Ausdrücke Generelle Ausdrücke umfassen alle mit XPath generierbaren Ausdrücke (siehe [ClDe99]) Korrelationen Oftmals laufen bei Geschäftsprozessen mehrere Instanzen eines Prozesses parallel nebeneinander ab. Bei sehr einfachen Geschäftsprozessen, bei denen ein Prozess lediglich ein oder zwei Web Service-Aufrufe kapselt, stellt dies kein Problem dar. Interagiert aber der Prozess mehrfach mit einem Client, eventuell sogar mit mehreren unterschiedlichen Clients, so reicht es nicht, den WSDL-Port eines Prozesses als Ziel des Clients anzugeben. In solchen Fällen ist es auch notwendig, die Nachricht an die entsprechende Instanz eines Prozesses weiterzuleiten. Bei objekt-orientierten Programmiersprachen werden solche Interaktionen mittels Objekt- Referenzen ermöglicht. Durch Referenzen können gezielt spezifische Objekte erreicht werden, die einen bestimmten Zustand und eine bestimmte Historie der Interaktion besitzen. Im Gegensatz zu mit objekt-orientierten Programmiersprachen realisierten Implementationen besteht bei der losen gekoppelten Architektur von Web Services das Problem, dass solche Referenzen zu einem schnell immer größer werdenden Netz heranwachsen würden. Bei jedem Partner des Geschäftsprozesses müssten entsprechende Informationen gespeichert werden. Solch ein Referenz-Netz hätte auf Dauer keine lange Überlebenschance [And+03]. Ein Mechanismus, um dieses Problem zu beheben, ist die Verwendung von so genannten Tokens. Ein Token ist eine Zeichenfolge, die einmalig ist. In jeder Nachricht wird, zusätzlich zu der eigentlichen zu transportierenden Information, ein Token mitgeliefert, mit dessen Hilfe die Nachricht einer bestimmten Instanz eines Geschäftsprozesses zugeordnet werden kann. Ein Token könnte beispielsweise bei einem Bestellvorgang aus der Bestell- oder einer Vorgangsnummer bestehen. BPEL4WS ermöglicht es, diesen Token-Mechanismus einzusetzen. So können die Position des Tokens in der Nachricht und seine Struktur festgelegt werden. 49

50 Business Process Execution Language for Web Services Die Verwendung dieser Tokens kann jedoch komplex werden. Da die Lebenszeit eines Geschäftsprozess relativ lang sein kann, kann sich eine Gruppe von Tokens (beispielsweise die ID und der Name eines Benutzers) durchaus nur auf einen Teil dieser Lebenszeit beziehen, ggf. können sogar mehrere Gruppen parallel übertragen werden, wenn sich die Lebenszeit der Token überlappen. Solche Gruppen von Tokens werden in BPEL als correlationsets (Korrelationsmengen) bezeichnet. Jede Korrelationsmenge hat einen Namen und in WSDL definierte Bestandteile (properties), auf die alle Nachrichten zugreifen können, die diese Tokens transportieren. Die Sichtbarkeit dieser Korrelationsmengen entspricht denen von Variablen. Korrelationsmengen können innerhalb von Scopes definiert werden und haben außerhalb dieser Scopes keine Gültigkeit. Globale Korrelationsmengen hingegen sind im gesamten Prozess sichtbar. Sie können nur einmal initziiert werden und können so zur Identifikation des gesamten Prozesses dienen. Lokale Korrelationsmengen innerhalb von Scopes können nur zur Lebenszeit eines Scopes initziiert werden und müssen ihren Wert behalten, bis der Scope abgeschlossen ist. Eine Korrelationsmenge wird in BPEL wie folgt definiert: <correlationsets> <correlationset name= benutzercs properties= benutzerid /> </correlationsets> Diese Korrelationsmenge besteht lediglich aus einer Benutzer-ID. Durch Leerzeichen getrennt können ggf. weitere Elemente angegeben werden. Diese properties werden innerhalb der WSDL-Datei definiert. <bpws:property name= benutzerid type= xsd:int/> An dieser Stelle wird der Datentyp der BenutzerID festgelegt. Die Korrelationsmengen werden in die Nachrichten in der WSDL-Datei des Geschäftsprozesses eingebettet, d. h. es muss festgelegt werden, wo sich die oben definierte 50

51 Strategien zur Prozessorchestrierung und Workflow-Integration in Web-Applikationen Benutzer-ID in den jeweiligen Nachrichten an oder von dem Prozess befinden. Dies wird in der WSDL-Datei mittels eines der Definition von propertyalias festgelegt: <definitions name= properties targetnamespace= xmlns:tns= xmlns:bpws= xmlns= > <message name= beispielnachrichtrequest > <part name= identifikationsnummer type= xsd:int /> <part name= meinname type= xsd:string /> <part name= meintext type= xsd:string /> </message> <message name= beispielnachrichtresponse > <part name= text type= xsd:string /> </message> <bpws:property name= benutzerid type= xsd:int/> <porttype name= beispielport > <operation= beispieloperation > <input message= beispielnachrichtrequest /> <output message= beispielnachrichtresponse /> </operation> </porttype> <partnerlinktype name= beispiellinktype > <bpws:propertyalias propertyname= cor:benutzerid messagetyp= tns:beispielnachrichtrequest query= /identifikationsnummer /> <role name= webservice > <porttype name= beispielport /> </role> </partnerlinktype> </definitions> Diese correlationsets werden instanziiert, sobald eine Aktivität aufgerufen wird, die das Attribut initiate=yes beinhaltet und sich auf das jeweilige correlationset bezieht. Ein correlationset kann mittels der Aktivitäten invoke, pick, receive oder reply instanziiert werden. 51

52 Business Process Execution Language for Web Services <receive partnerlink= beispiellink porttype= beispielport operation= beispieloperation variable= beispielnachrichtrequestvar createinstance= yes > <correlations> <correlation set= benutzercs initiate= yes /> </correlations> </receive> Aktivitäten BPEL unterscheidet zwischen so genannten Basisaktivitäten und strukturierten Aktivitäten [Djem04]. Basisaktivitäten sind atomare Aktionen, die beispielsweise die Kommunikation mit anderen Web Services ermöglichen. Folgende primäre Aktivitäten sind in BPEL verfügbar: receive, reply, invoke, assign, throw, terminate, wait, empty, scope, compensate Strukturelle Aktivitäten beschreiben die Ablaufreihenfolgen und Ablaufbedingungen ihrer gekapselten Elemente, welche einfache primäre Aktivitäten oder weitere strukturelle Aktivitäten sein können [Djem04]. Folgende strukturierte Aktivitäten stellt BPEL zur Verfügung: sequence, switch, while, pick, flow Abbildung 5 zeigt die unterschiedlichen Typen von Aktivitäten und deren Abhängigkeiten untereinander. 52

53 Strategien zur Prozessorchestrierung und Workflow-Integration in Web-Applikationen Abbildung 5 BPEL Aktivitätstypen [Dubr03], [FiWe04] Die einzelnen Basis- und strukturellen Aktivitäten werden, soweit nicht bereits in den vorangegangenen Abschnitten geschehen, im Folgenden näher erläutert. 53

54 Business Process Execution Language for Web Services Basisaktivitäten Wait Mit Wait kann der Geschäftsprozess für eine bestimmte Zeitspanne angehalten werden (Attribut for) oder solange angehalten werden, bis eine bestimmte Deadline eingetreten ist (Attribut until). Das folgende Beispiel zeigt die Verwendung des Attributs for: <sequence> <wait for= P0Y0M1DT1H0M0S /> <invoke partnerlink= LinkZumChef porttype= AutomaticPhoneCall operation= TextToSpeech inputvariable= WeihnachtsgrussAnChef > </invoke> </sequence> In diesem Beispiel wird ein Tag und eine Stunde gewartet, bevor die <invoke>- Aktivität aufgerufen wird. In Kapitel werden die Ausdrücke, die im for- und until-attribut verwendet werden können, näher erläutert. Empty Wie der Name der Aktivität vermuten lässt, passiert bei dessen Aufruf nichts. Oftmals wird eine Aktivität benötigt, bei der keinerlei Aktion durchgeführt wird. Dies ist beispielsweise der Fall, wenn Fehler abgefangen und unterdrückt werden müssen. Die Syntax ist wie folgt festgelegt: <empty standard-attributes> </empty> <!-- standard-elements --> 54

55 Strategien zur Prozessorchestrierung und Workflow-Integration in Web-Applikationen Strukturelle Aktivitäten Sequence Innerhalb einer <sequence>-aktivität werden alle aufgeführten Aktivitäten der Reihe nach ausgeführt, d. h. erst wenn eine Aktivität ausgeführt und beendet wurde, wird die darauf folgende Aktivität aufgerufen. <sequence> </sequence> <!-- Aktivitäten --> Switch Die <switch>-aktivität erlaubt es, anhand eines Kriteriums eine bestimmte Aktivität auszuwählen. Sie ist von der Funktionalität her identisch mit der Switch-Anweisung der Programmiersprache JAVA. Mittels einer Fallunterscheidung wird eine bestimmte Aktivität ausgewählt. Optional kann mittels otherwise ein alternativer Ablauf festgelegt werden, falls keiner der definierten Fälle eingetreten ist. Die alternativen Fälle schließen sich bei BPEL aus, d. h. ein Break am Ende jedes Falles, wie in JAVA, ist nicht erforderlich. Das folgende Beispiel veranschaulicht die Verwendung der Switch-Aktivität: <switch> <case condition= bpws:getvariabledata( konto, kontostand ) < 0 > <!-- Aktivität(en) --> </case> <case condition= bpws:getvariabledata( konto, kontostand ) > 0 > <!-- Aktivität(en) --> </case> <otherwise> <!-- Aktivität(en) --> </otherwise> </switch> 55

56 Business Process Execution Language for Web Services While Ebenso wie Switch entspricht die <while>-aktivität bei BPEL den While- Anweisungen aus imperativen Programmiersprachen. Solange eine bestimmte Bedingung erfüllt ist, werden die in der While-Schleife definierten Aktivitäten ausgeführt. <while condition= bpws:getvariabledata( zaehler ) < 10 > <! - Aktivität(en) --> </while> Pick Innerhalb von Geschäftsprozessen kann die Notwendigkeit bestehen, auf mehrere alternativ eintreffende Nachrichten eines Benutzers oder eines Web Services zu reagieren. Mit Hilfe der <pick>-aktivität kann dieses Szenario in BPEL realisiert werden. Innerhalb der <pick>-aktivität können mehrere Ereignisse festgelegt werden, auf die der Prozess wartet. Tritt eines dieser Ereignisse ein, so wird dieses entsprechend abgehandelt und die <pick>-aktivität beendet. Die einzelnen Ereignisse schließen sich dabei gegenseitig aus, d. h. es kann nur das Ereignis ausgelöst werden, welches als erstes eintritt. <pick createinstance= yes > <onmessage > </onmessage> <onmessage > </onmessage> <onalarm > </onalarm> </pick> Wie im Beispiel zu sehen ist, kann die <pick>-aktivität auch am Anfang eines Prozesses definiert werden, so dass das erste eintreffende Ereignis eine Instanz des Prozesses erzeugt (Attribut createinstance). Die Definitionen von Ereignissen, wie Nachrichten oder Alarme, werden in Kapitel näher erläutert. 56

57 Strategien zur Prozessorchestrierung und Workflow-Integration in Web-Applikationen Nebenläufiger Ablauf Im Gegensatz zu der <sequence>-aktivität können in BPEL mit Hilfe der <flow>-aktivität weitere Aktivitäten definiert werden, die nebenläufig ausgeführt werden. Sobald der Prozessablauf eine <flow>-aktivität erreicht, werden alle dort definierten Aktivitäten aktiviert. Sobald alle Aktivitäten abgeschlossen sind, ist die <flow>-aktivität ebenfalls beendet und der Prozessablauf läuft sequentiell weiter. <flow> <invoke name= A partnerlink= A /> <invoke name= B partnerlink= B /> <sequence> <receive name= Frage /> <reply name= Antwort /> </sequence> </flow> Dieses Beispiel zeigt die Definition einer Flow-Aktivität. Die beiden Invoke-Aktivitäten A und B sowie der Sequence-Block werden parallel ausgeführt. Die Aktivitäten innerhalb der Sequenz werden jedoch nacheinander abgehandelt Synchronisation Mit BPEL ist es möglich, die einzelnen Aktivitäten innerhalb einer Flow-Aktivität zu synchronisieren, d. h. Abhängigkeiten zwischen einzelnen Aktivitäten zu modellieren. Das ist insbesondere dann sinnvoll, wenn unterschiedliche Aktivitäten auf gemeinsame Variablen zugreifen und Inkonsistenzen vermieden werden sollen. Zur Veranschaulichung der Synchronisation soll folgendes Beispiel in Abbildung 6 dienen: 57

58 Business Process Execution Language for Web Services Abbildung 6 Beispielprozess mit Synchronisation Nach Ausführen von invoke start werden parallel sequence X, sequence Y und invoke E ausgeführt. Innerhalb der beiden Sequenzen X und Y werden der Reihe nach jeweils zwei weitere Aktivitäten ausgeführt. Nach Abschluss der parallelen Abarbeitung wird invoke ende ausgeführt. Folgende zusätzlichen Abhängigkeiten sind durch gepunktete Pfeile gekennzeichnet: sequence Y darf erst nach invoke E ausgeführt werden, invoke B erst nach Beendigung von invoke D. Zu Beginn des Flows müssen alle Abhängigkeiten festgelegt werden. Dies wird in BPEL durch so genannte Links realisiert: <invoke name= start /> <flow> <links> <link name= EvorY /> <link name= DvorB /> 58