BPEL Wie werden meine Prozesse ausgeführt?

Transkript

1 Friedrich-Schiller-Universität Jena Fakultät für Mathematik und Informatik Lehrstuhl für Datenbanken und Informationssysteme BPEL Wie werden meine Prozesse ausgeführt? Seminar: Business Process Management und Workflow-Technologien: Grundlagen, Produkte, Forschung Prof. Dr. Klaus Küspert, Dr. Andreas Wickenhäuser, Matthias Liebisch von Jens Bachmann Matrikelnummer: Wirtschaftsinformatik Thomas-Mann-Straße Jena Jena, den 16. Juli 2009

2 Inhaltsverzeichnis 1 Einleitung 1 2 Entstehung des Standards 1 3 Funktionsweise von BPEL Grundlagen Syntax: Prozessdefinition Grundstruktur <partnerlinks> <variables> Weitere Deklarationen Syntax: Elementare Aktivitäten <invoke>, <receive> und <reply> <assign> Weitere Aktivitäten Strukturierte Aktivitäten <sequence> <flow> <if> <while> und <repeatuntil> <foreach> <pick> Ausführung der Prozesse durch BPEL-Engines Beispiel-Modellierung mit BPEL 12 5 Zusammenfassung 14 Literaturverzeichnis 15 i

3 1 Einleitung Damit Unternehmen im heutigen Wettbewerb bestehen, müssen sie Geschäftsprozesse effizient ausführen und diese einfach anpassen können, damit bei Veränderungen des Marktes oder innerhalb des Unternehmens diese Änderungen auch innerhalb der Prozesse flexibel und schnell vorgenommen werden können. Großes Interesse liegt in der Automatisierung dieser Geschäftsprozesse. Dabei müssen jedoch verschiedenste Anwendungen auf unterschiedlichen Plattformen miteinander kommunizieren. Laut einer Studie [SBA08] aus dem Jahr 2008 haben 80 % der großen Unternehmen (mindestens 250 Beschäftigte) in Deutschland mittels automatisierten Verfahren Daten mit Partnern, Kunden, Banken oder Behörden ausgetauscht. Hauptsächlich erfolgte dies mit unternehmensspezifischen Standards. Ein einheitlicher Standard würde es ermöglichen, Prozesse effizient zu gestalten, diese zu automatisieren und gleichzeitig Daten untereinander auszutauschen. Dafür bietet sich die Web Services Business Process Execution Language (WS-BPEL) an, eine XML-basierte Standardsprache zur Modellierung von Geschäftsprozessen, welche auf Web-Services basieren. Nachdem in Abschnitt 2 zunächst die Entstehung der Sprache aufgezeigt wird, beschreibt Abschnitt 3 die Funktionsweise von WS-BPEL, stellt einige wichtige Sprachelemente vor und zeigt kurz auf, wie Engines das Business Process Management unterstützen. Zur Verdeutlichung der Syntax beinhaltet Abschnitt 4 ein Beispiel zur Workflow-Modellierung anhand des Prozesses der Seminardurchführung. 2 Entstehung des Standards Die Entstehung der WS-Business Process Execution Language begann mit zwei unterschiedlichen Ausprägungen. Einerseits mit der Web Services Flow Language (WSFL) von IBM und andererseits mit XLANG vom Microsoft. IBM entwickelte WSFL, um Geschäftsprozesse als Web-Services mit Hilfe von gerichteten Graphen zu definieren und auszuführen. Diese Graphen lassen sich in XML-Syntax modellieren und können somit sowohl von Menschen als auch von Maschinen verstanden werden. Die Idee dabei war es, Prozesse schnell und präzise zu erzeugen und durch die geringe Komplexität Kosten bei der Implementierung einzusparen [Sne01]. Microsofts XLANG basiert ebenfalls auf XML und dient der formalen Spezifikation von Web-Services und deren Verhalten als Teil eines Geschäftsprozesses. Damit wird die Erzeugung großer Prozesse ermöglicht, welche wiederum als Komponente in andere Workflows eingehen können. Einmal erstellte Vorgänge können somit immer wieder verwendet werden [Cov01]. 1

4 Die Zusammenführung der strukturierten Prozessorientierung von XLANG und dem graphenorientierten Ansatz von WSFL ergab BPEL4WS Version 1.0 (Business Process Execution Language for Web-Services). Diese wurde im August 2002 von IBM, Microsoft und Bea Systems veröffentlicht. Neben IBM, Microsoft und Bea Systems nahmen nun auch SAP und Siebel an der Entwicklung teil und es konnte im Mai 2003 BPEL4WS Version 1.1 herausgegeben werden. Diese Version wurde an OASIS (Organization for the Advancement of Structured Information Standards) weitergegeben, um die Entwicklung fortzusetzen [MSDN]. Am 12. April 2007 wurde die Arbeit beendet, umbenannt zu Web Services Business Process Execution Language (WS-BPEL) Version 2.0 und als OASIS-Standard freigegeben. Zu diesem Zeitpunkt haben mehr als 37 Organisationen zur Entwicklung von WS-BPEL beigetragen [OAS07]. 3 Funktionsweise von BPEL Dieser Abschnitt soll die Funktionsweise von WS-BPEL 2.0 aufzeigen und einen Einblick in die Sprachelemente geben, welche zur Verfügung stehen. 3.1 Grundlagen Der Standard WS-BPEL 2.0 beschreibt Prozesse in einer ablauffähigen Form. Dazu werden verschiedene, lose gekoppelte Dienste, welche auf Web-Services basieren, orchestriert [Sta05]. Das World Wide Web Consortium (W3C) beschreibt Orchestration als Definition von Reihenfolge und Bedingungen, wie Web-Services aufgerufen werden. Der sich daraus ergebende Prozess ist ebenfalls ein Web-Service und kann dementsprechend wieder als Baustein weiter verwendet werden [W3CGl]. Durch dieses Prinzip lassen sich Aktivitäten einfach kombinieren bzw. neu anordnen, um schnell auf neue Gegebenheiten zu reagieren. BPEL ist plattformunabhängig und unterstützt durch Erweiterungen eine Vielzahl weiterer Technologien, z. B. , Java, Datenbank- und Dateizugriffe, Messageing und viele mehr. Auch diese Funktionen werden als Service beschrieben und können daher einfach integriert werden. Lange Entwicklungszeiten von Software lassen sich damit vermeiden, dies führt wiederum zu Kosteneinsparungen im Unternehmen [WiS06]. Der Standard WS-BPEL verwendet selbst wieder Standards zur Modellierung von Workflows, welche auf XML basieren und im Folgenden aufgelistet sind [WSB07, S. 11]: Web Services Description Language (WSDL): Eine strukturiere Sprache, die Netzwerkdienste (oder auch Web Services) als Sammlung von Kommunikationsendpunkten beschreibt, welche in der Lage sind, Nachrichten auszutauschen [W3C01]. 2

5 XML Schema: legt in einer XML-Schema-Definition (XSD) die Strukturen für XML- Dokumente fest [W3C04a]. XPath: Dient der Adressierung von Teilen eines XML-Dokuments, außerdem können Zeichenketten, Zahlen und boolesche Ausdrücke manipuliert werden [W3C99a]. XSL Transformations (XSLT): Sprache zur Umwandlung von XML-Dokumenten in andere Formate, z. B. HTML, mit Hilfe von Stylesheets [W3C99b]. WS-BPEL sieht zur Modellierung zwei verschiedene Varianten von Prozessen vor: ausführbare und abstrakte Prozesse. Beide Möglichkeiten beruhen auf der gleichen Syntax (s. Abschnitt 3.2). Ausführbare Prozesse sind so modelliert, dass sie auf den BPEL-Engines (s. Abschnitt 3.5) direkt ausgeführt werden können. Im Gegensatz dazu lassen sich abstrakte Prozesse nicht ausführen. Sie dienen als Sicht auf ausführbare Prozesse. So lassen sich beispielsweise einem Geschäftspartner Spezifikationen mitteilen, wie die Services miteinander kommunizieren können, ohne dabei das interne Verhalten des Prozesses weiterzugeben. Ein weiteres Beispiel für einen abstrakten Prozess ist der Prozess der Seminardurchführung in Abschnitt 4. Abstrakte Prozesse lassen sich durch Hinzufügen der notwendigen Spezifikationen in ausführbare Prozesse umwandeln. Ebenso lassen sich ausführbare zu abstrakten Prozessen abändern, indem Informationen entfernt werden [WSB07]. 3.2 Syntax: Prozessdefinition Grundstruktur Der <process>-container ist das äußerste Konstrukt im BPEL-Dokument. Neben den auszuführenden Aktivitäten werden hier Variablen deklariert, Links zu externen Partnern definiert und einige andere Steuerungsfunktionen festgelegt. Das Beispiel in Listing 1 zeigt die Grundstruktur für einen Prozess, welcher sich aus einem Definitionsteil und den Aktivitäten zusammensetzt [Sta05]: 1 <process name =" meinprozess "> <!-- Prozess --> 2 targetnamespace =" anyuri " 3 4 < extensions > <! -- Erweiterungen -- > 5 </ extensions > 6 7 < imports / > <! -- externe Abhängigkeiten --> 8 9 < partnerlinks > <! -- Dienste --> 10 </ partnerlinks > < messageexchanges > 13 </ messageexchanges > 3

6 14 15 < variables > <! -- Daten --> 16 </ variables > < correlationsets > 19 </ correlationsets > < faulthandlers > <! -- Fehlerbehandlung --> 22 </ faulthandlers > < eventhandlers > <! -- Ereignisbehandlung --> 25 </ eventhandlers > < sequence name =" meineseq "> <!-- Ablaufsequenz --> 28 < receive > 29 <assign > <! -- Aktivitäten --> 30 <reply > 31 </ sequence > 32 </ process > Listing 1: Grundstruktur eines BPEL-Prozesses In Zeile eins und zwei des Beispiels werden name und targetnamespace für den Prozess definiert. Beides ist notwendig, um einen Prozess ausführen zu können. Zusätzlich gibt es einige weitere Attribute, die definiert werden können, dazu sei auf [WSB07] verwiesen <partnerlinks> Damit der Prozess mit anderen Web-Services interagieren kann, also andere Services aufrufen oder selbst aufgerufen werden kann, werden Verbindungen mittels <partnerlinks> festgelegt. Diese werden charakterisiert durch einen Namen, einen Typ sowie die Rolle des Prozesses oder des Partners [WSB07, S. 36 ff.]. In folgendem Beispiel wird eine Verbindung zu einer Fluggesellschaft definiert, über welche der Prozess die Verfügbarkeit eines Fluges abfragt (myrole) und eine Antwort von der Fluggesellschaft erwartet (partnerrole). Das Attribut partnerlinktype definiert Kommunikationskanäle pro Partner und verweist auf die ausgetauschten Nachrichten; festgelegt wird dieser an anderer Stelle. 1 < partnerlinks > 2 < partnerlink name =" Fluggesellschaft " 3 partnerlinktype =" wsdl:flugplt " 4 myrole =" VerfügbarkeitAbfragen " 5 partnerrole =" FlugService " / > 6 </ partnerlinks > Listing 2: PartnerLinks 4

7 3.2.3 <variables> In Variablen werden entweder Nachrichten gespeichert, die an einen Service gesendet oder von einem Service empfangen werden, oder sie enthalten Daten, welche der Prozess benötigt. Letztere werden nicht mit anderen Services ausgetauscht. Variablen besitzen einen eindeutigen Namen und können durch drei Typen definiert werden: messagetype verweist auf einen WSDL-Nachrichtentyp type verweist auf einen einfachen oder komplexen XML-Schematyp element verweist auf ein XML-Schema-Element. Jede Variable muss genau einen dieser Typen besitzen. Im Beispiel zur Abfrage der Verfügbarkeit des Fluges verwendet der Prozess die Variablen aus Listung 3. FlugAnfrage in Zeile 2 enthält die Nachricht, die an die Fluggesellschaft geschickt werden soll, in FlugAntwort wird später die Antwort gespeichert und zusätzlich soll in FlugPreis, welche von Typ decimal ist, der Preis gespeichert werden. 1 < variables > 2 < variable name =" FlugAnfrage " messagetype =" FlAnNa " /> 3 < variable name =" FlugAntwort " messagetype =" FlAwNa " /> 4 < variable name =" FlugPreis " type =" xsd:decimal " /> 5 </ variables > Listing 3: Variablen Um Variablen zu verändern, kann in BPEL standardmäßig X-Path 1.0 genutzt werden [WSB07, S. 45 ff.] Weitere Deklarationen Zusätzlich zu <partnerlinks> und <variables> können im Definitionsteil des Prozesses noch deklariert werden: <extensions> dienen der Erweiterung von WS-BPEL, beispielsweise durch neue Attribute oder Elemente [WSB07, S. 164 f.]. <import> deklariert die Abhängigkeit des Prozesses zu externen XML-Schemas oder WSDL-Definitionen [WSB07, S. 32 f.]. <messageexchanges> bringen zusammengehörende, eingehende und ausgehende Nachrichten miteinander in Verbindung, wenn ein Prozess mehrere receive und reply Aktivitäten zum selben partnerlink und zur selben WSDL Operation ausführt. Sonst wäre eine eindeutige Zusammengehörigkeit nicht mehr erkennbar [WSB07, S. 93 f.]. 5

8 <correlationsets> weisen eingehenden Nachrichten die zugehörige Prozessinstanz zu, falls der Prozess in mehreren Instanzen ausgeführt wird [WSB07, S. 74 ff.]. <faulthandlers> dienen der Ausnahmebehandlung bei eingetretenen Fehlern [WSB07, S. 127 ff.]. <eventhandlers> beschreiben die Reaktion auf ein Ereignis, welches während eines Prozesses auftreten kann. Sie sind nur aktiv, wenn ihr zugehöriger Prozess ausgeführt wird und können somit selbst keine neue Instanz erstellen [WSB07, S. 137 ff.]. Nach dem Deklarationsteil werden die eigentlichen Aktivitäten des Prozesses modelliert. Dabei wird zwischen elementaren Aktivitäten (s. Abschnitt 3.3) und strukturierten Aktivitäten (s. Abschnitt 3.4) unterschieden. Alle im <process>-container vorgenommenen Deklarationen sind global, also für den gesamten Prozess gültig. Sollen Deklarationen nur für Teilbereiche erfolgen, kann die <scope>- Umgebung verwendet werden. Die Elemente sind dann nur lokal, also innerhalb der Umgebung, gültig. Ebenso lassen sich Aktivitäten innerhalb der <scope>-umgebung ausführen. 3.3 Syntax: Elementare Aktivitäten Elementare Aktivitäten (Basic Activities) sind Operationen, um andere Services aufzurufen, Daten zu manipulieren oder die zusätzliche Steuerungsinformationen enthalten. Sie enthalten keine weiteren Aktivitäten und sind somit atomar. Die wichtigsten sollen in diesem Abschnitt erläutert werden <invoke>, <receive> und <reply> Zur Kommunikation mit anderen Web-Services dienen die Aktivitäten <invoke>, <receive> und <reply>. Mit der <invoke>-aktivität wird ein Web-Service eines Partners aufgerufen. BPEL unterstützt zwei Arten von Operationen. Entweder wird eine Nachricht gesendet und der Prozess wird fortgesetzt, ohne auf eine Antwort zu warten, oder der Prozess wird blockiert, bis der Partner eine Antwort sendet. In Listing 4 soll der Web Service der Fluggesellschaft über den bereits definierten partnerlink aufgerufen werden. Dabei wird die Nachricht in der inputvariable (Zeile 4) gespeichert und die Antwort in der outputvariable (Zeile 5). Soll der Aufruf keine Antwort empfangen, kann die outputvariable weggelassen werden. Im Beispiel aus Listing 4 wartet der Prozess auf eine Antwort von der Fluggesellschaft [WSB07, S. 84 ff.]. 6

9 1 < invoke name =" VerfügbarkeitFlugPrüfen " 2 partnerlink =" Fluggesellschaft " 3 operation =" FrageVerfügbarkeitAb " 4 inputvariable =" FlugAnfrage " 5 outputvariable =" FlugAntwort " 6 </ invoke > Listing 4: Invoke-Aktivität Die <receive>-aktivität empfängt Nachrichten von anderen Diensten. Dabei wird der Prozess solange blockiert, bis die Nachricht eingegangen ist. Es kann als Startaktivität verwendet werden, um eine neue Prozessinstanz zu starten, beispielsweise wenn mehrere Clients eine Anfrage stellen [WSB07, S. 89 ff.]. Mit <reply> wird auf eine Nachricht geantwortet. Daher tritt es gewöhnlich in Kombination mit <receive> auf, um request-response-operationen durchzuführen [WSB07, S. 89 ff.]. Der Syntax beider ähnelt dem der <invoke>-aktivität <assign> Um Daten zu kopieren, von verschiedenen Quellen zusammenzuführen oder in unterschiedliche Ziele aufzuteilen wird <assign> verwendet. Listing 5 zeigt, wie Daten aus der Variable Quelle in die Variable Ziel kopiert wird, wobei beide den gleichen Datentyp besitzen müssen [WSB07, S. 59 ff.]. 1 <assign > 2 <copy > 3 <from variable =" Quelle " /> 4 <to variable =" Ziel " /> 5 </ copy > 6 </ assign > Listing 5: Assign Weitere Aktivitäten Durch <wait> kann ein Prozess angehalten werden. Dabei wird zwischen zwei Möglichkeiten unterschieden: entweder wird eine feste Zeitspanne vorgegeben, die der Prozess warten soll oder es wird ein genauer Zeitpunkt gesetzt, zu dem der Prozess seine Arbeit wieder aufnimmt. Bei einer negativen Zeitspanne oder einem Zeitpunkt in der Vergangenheit wird der Prozess sofort fortgesetzt [WSB07, S. 95]. Mit <exit> wird eine Prozessinstanz sofort beendet, es werden also alle Aktivitäten ohne Fehlerbehandlung oder ähnlichem abgebrochen [WSB07, S. 96]. Die Aktivität <empty> ist leer, d. h. es passiert nichts. Dies kann beispielsweise nötig sein, 7

10 um einen aufgetretenen Fehler zu behandeln oder dient als Platzhalter, um später Spezifikationen an dieser Stelle durchzuführen [WSB07, S. 95]. Zur Behandlung von Fehlern werden die Aktivitäten <throw> und <rethrow> verwendet [WSB07, S. 94 ff.]. 3.4 Strukturierte Aktivitäten Strukturierte Aktivitäten geben vor, wie andere Aktivitäten ausgeführt werden bzw. kapseln diese. Dazu können sie, im Gegensatz zu elementaren Aktivitäten (s. Abschnitt 3.3), auch weitere Elemente enthalten <sequence> Die einfachste strukturierte Aktivität ist die <sequence>. Alle in ihr aufgeführten Elemente werden in der vorgegebenen Reihenfolge sequenziell abgearbeitet [WSB07, S. 98]. 1 < sequence name =" AnfrageDienstreise " > 2 <receive name =" EingangAnfrage "... /> 3 <invoke name =" VerfügbarkeitFlugPrüfen "... /> 4 <invoke name =" VerfügbarkeitHotelPrüfen "... /> 5 <reply name =" SendeRückmeldung "... /> 6 </ sequence > Listing 6: Sequence Als Beispiel in Listing 6 stellt ein Mitarbeiter zunächst eine Anfrage für eine Dienstreise. Daraufhin fragt der Prozess bei der Fluggesellschaft nach, ob ein Flug verfügbar ist. Nach Eingang der Antwort wird geprüft, ob am Zielort ein Hotel verfügbar ist. Daraufhin erhält der Mitarbeiter eine Rückmeldung <flow> Im Gegensatz dazu lassen sich in der <flow>-umgebung alle Aktivitäten parallel ausführen, sie starten also gleichzeitig. Durch das Hinzufügen von <link>-definitionen lassen sich die parallel laufenden Aktivitäten zusätzlich abstimmen [WSB07, S. 102 ff.]. Beispielsweise die Abfragen der Verfügbarkeit von Flug, Hotel und Mietwagen müssen hier nicht auf den jeweiligen Vorgänger warten, sondern starten die Abfrage gleichzeitig. 1 <receive name =" EingangAnfrage "... /> 2 <flow... > 3 <invoke name =" VerfügbarkeitFlugPrüfen "... /> 4 <invoke name =" VerfügbarkeitHotelPrüfen "... /> 8

11 5 < invoke name =" VerfügbarkeitMietwagenPrüfen "... / > 6 </ flow > 7 <reply name =" SendeRückmeldung "... /> Listing 7: Flow <if> Ein Prozess lässt sich mit <if> verzweigen. Mit <elseif> lässt sich die Verzweigung beliebig verschachteln. Dabei muss beachtet werden, dass nur der Teil nach der ersten wahren Bedingung ausgeführt wird. Die Bedingungen lassen sich mit XPath formulieren. Mit <else> lässt sich zu einer Alternative verzweigen, falls alle vorherigen Bedingungen falsch waren [WSB07, S. 99]. Im Beispiel aus Listing 8 wird zunächst geprüft, ob ein Preis über Euro liegt, in diesem Fall soll ein Service aufgerufen werden, der zehn Prozent Rabatt berechnet. Andernfalls prüft der Prozess, ob der Preis über Euro liegt, dann sollen fünf Prozent Rabatt berechnet werden und ansonsten gibt es eine Rückmeldung, dass kein Rabatt gewährt werden kann. 1 <if name =" Rabatt "> 2 < condition > 3 $ preis > </ condition > 5 <invoke name =" ZehnProzentRabatt "... /> 6 <elseif > 7 < condition > 8 $ preis > </ condition > 10 <invoke name =" FünfProzentRabatt "... /> 11 </ elseif > 12 <else > 13 <reply name =" keinrabatt "... /> 14 </ else > 15 </if > Listing 8: If <while> und <repeatuntil> Zur Wiederholung von Aktivitäten können Schleifen verwendet werden, wie sie auch aus Programmiersprachen bekannt sind. In BPEL gibt es zum einen die <while>-schleife, welche zunächst die Bedingung prüft und dann gegebenenfalls den Schleifenkörper durchläuft. Bei einer von Anfang an falschen Bedingung werden die Kindaktivitäten überhaupt nicht ausgeführt [WSB07, S. 99 f.]. Im Gegensatz dazu werden bei <repeatuntil> erst die enthaltenen Aktivitäten ausgeführt und dann die Bedingung geprüft, so dass mindestens eine Iteration ausgeführt wird [WSB07, S. 100]. Die Bedingungen (Boolescher Ausdruck) lassen sich mit X-Path erstellen. In den Beispielen aus Listing 9 und 10 soll in jeder Iteration 9

12 der Zähler erhöht werden, solange dieser kleiner oder gleich fünf ist. Dazu wird wieder ein entsprechender Service aufgerufen. 1 <while > 2 < condition > 3 $i &lt ;= 5 4 </ condition > 5 <invoke name =" Plus1 ".../ > 6 </ while > Listing 9: While 1 < repeatuntil > 2 <invoke name =" Plus1 ".../ > 3 < condition > 4 $i &lt ;= 5 5 </ condition > 6 </ repeatuntil > Listing 10: RepeatUntil <foreach> Die dritte Möglichkeit mehrere Iterationen durchzuführen, bietet <foreach>. Alle Aktivitäten werden genau N+1 mal ausgeführt, wobei sich N aus <finalcountervalue> minus <startcountervalue> ergibt. Für das Beispiel in Listing 11 bedeutet dies also, dass der Schleifenkörper zehn mal durchlaufen wird. Im Gegensatz zu den anderen strukturierten Aktivitäten müssen sich die auszuführenden Elemente bei <foreach> in einem <scope>- Container befinden. In Listing 11 wird in Zeile 1 parallel="no" definiert, dadurch werden alle Schleifendurchläufe sequenziell abgearbeitet; wird parallel="yes" angegeben, so werden sie parallel durchgeführt [WSB07, S. 112 ff.]. 1 <foreach countername ="N" parallel ="no"... > 2 < startcountervalue >0 </ startcountervalue > 3 < finalcountervalue >9 </ finalcountervalue > 4 <scope > 5 <invoke name =" PrüfeVerfügbarkeit "... /> 6 </ scope > 7 </ foreach > Listing 11: ForEach <pick> Ein Prozess wartet auf das Eintreten eines Ereignisses, wenn die <pick>-aktivität verwendet wird. Es können mehrere Ereignisse und damit verbundene Aktivitäten vorgegeben werden, allerdings reagiert die Umgebung nur auf genau ein Ereignis, alle anderen werden nicht mehr akzeptiert. Ein Ereignis kann einerseits das Eintreffen einer Nachricht sein, dies wird mit <onmessage> behandelt. Jede <pick>-aktivität muss mindestens ein <onmessage>- Element enthalten. Das zweite Ereignis, <onalarm>, tritt entweder nach einer vorgegebenen Zeitspanne oder zu einem bestimmten Zeitpunkt ein. Die Anzahl dieser innerhalb einer <pick>-aktivität ist beliebig. Soll durch ein Ereignis eine neue Instanz des Prozesses gestartet werden, so dürfen ausschließlich <onmessage>s verwendet werden [WSB07, S. 100 ff.]. Dauer oder Zeitpunkt werden als XPath Ausdruck formuliert. 10

13 1 <pick > 2 < onmessage partnerlink =" Fluggesellschaft " 3 operation =" FlugVerfügbar " 4 variable =" FlugAntwort "> 5 <invoke name =" FlugBuchen "... /> 6 </ onmessage > 7 <onalarm > 8 <for > P0Y0M0DT0H15M0S </ for > 9 < sequence name =" BuchungAbbrechen "... /> 10 </ onalarm > 11 </ pick > Listing 12: Pick Im Beispiel in Listing 12 wartet der Prozess auf die Antwort der Fluggesellschaft, um daraufhin den Service für die Buchung zu starten (Zeile 2 bis 6). Trifft nach 15 Minuten keine Antwort ein, so soll eine Sequenz eingeleitet werden, welche die Buchung abbricht (Zeile 7 bis 10). 3.5 Ausführung der Prozesse durch BPEL-Engines In einer BPEL-Engine lassen sich modellierte Geschäftsprozesse hinterlegen, um diese bei Bedarf durchzuführen. Über verschiedene Schnittstellen kann die Engine sowohl mit Maschinen (Web-Services) als auch mit Menschen kommunizieren und ihnen somit Aufgaben aus dem Geschäftsprozess übermitteln sowie deren Beendigung registrieren, um daraufhin neue Aktivitäten zu starten oder fortzusetzen. Somit wird durch eine BPEL-Engine der gesamte Geschäftsprozess gesteuert und gegebenenfalls kontrolliert [FrG08]. Allerdings muss hierbei beachtet werden, dass WS-BPEL selbst keine Interaktion mit Menschen vorsieht und diese Schnittstellen produktspezifisch sind oder BPEL4People verwenden, welche den Standard für Benutzerinteraktionen erweitert. Zur Verdeutlichung zeigt Abbildung 1 das Schema einer BPEL-Engine. Neben der Prozesssteuerung befindet sich hier innerhalb der Engine noch ein BPEL-Designer, in welchem sich die Prozesse grafisch durch den Anwender modellieren lassen. Danach wird der Workflow an den Übersetzer weitergereicht und dort zu einem ausführbaren BPEL-Prozess umgewandelt, welcher an die Prozesssteuerung weitergereicht wird. Dieses Vorgehen wird allerdings nicht von allen Engines unterstützt. Einige dienen einzig der Ausführung der Geschäftsprozesse. Das Ausführen von Geschäftsprozessen sowie das Erstellen der Prozesse mit Hilfe von grafischen Werkzeugen wird beispielsweise durch die kommerziellen Programme IBM Web- Sphere, Microsoft BizTalk sowie Oracle BPEL Process Manager unterstützt. Aber auch die Open Source Plattform Intalio BPM ermöglicht das Modellieren mit Hilfe eines grafischen Designers. Zur Verarbeitung von Geschäftsprozessen werden noch eine Vielzahl weiterer 11

14 Abbildung 1: Schema einer Engine [FrG08] Engines angeboten, welche den BPEL-Standard unterstützen; darunter sind sowohl kommerzielle als auch Open Source Anwendungen. 4 Beispiel-Modellierung mit BPEL In diesem Abschnitt soll das Modellieren eines Workflows am Beispiel der Seminarteilnahme gezeigt werden. Der Ablauf des Seminars sei wie folgt beschrieben: Auftakt-Präsentation mit Themenwahl (Kickoff) Modul-Anmeldung im Prüfungsamt Besprechung und Bearbeitung des Themas in mehreren Iterationen Halten des Seminar-Vortrags Ausarbeitung zum Thema mit eventueller Korrekturschleife Erhalt des Seminarscheins bzw. der Leistungspunkte nach Bewertung. In Listing 13 ist dieser Prozess im BPEL-Syntax dargestellt. Dabei muss beachtet werden, dass es sich hier nicht um einen ausführbaren Prozess handelt, da zum einen nicht sämtliche Details definiert wurden und zum anderen Interaktionen mit Menschen vorgesehen sind, die der WS-BPEL Standard selbst nicht unterstützt. 12

15 1 < process name =" Seminarteilnahme " > 2 < sequence > 3 <pick > 4 <onalarm > 5 <until > T16:00: :00 7 </ until > 8 < sequence > 9 <! -- Kickoff --> 10 </ seqence > 11 </ onalarm > 12 </ pick > 13 <flow > 14 <invoke name =" Anmeldung "> 15 partnerlink =" Prüfungsamt " 16 operation =" anmelden " 17 </ invoke > 18 < repeatuntil > 19 <! -- Besprechung des Themas --> 20 <! -- Bearbeitung des Themas --> 21 < condition > 22 current - date () < </ condition > 24 </ repeatuntil > 25 </ flow > 26 <! -- Vortrag halten -- > 27 <! -- Ausarbeitung schreiben 28 und abgeben -- > 29 <if > 30 < condition > 31 <! -- Ausarbeitung nicht ok --> 32 </ condition > 33 <! -- Korrigieren und abgeben --> 34 </if > 35 <wait > 36 <for > P5DT10H </ for > 37 </ wait > 38 <if > 39 < condition > 40 <! -- bestanden --> 41 </ condition > 42 <! -- Scheinvergabe -- > 43 <else > 44 <exit... /> 45 </ else > 46 </if > 47 </ sequence > 48 </ process > Listing 13: Beispiel-Workflow 13

16 5 Zusammenfassung Mit der XML-basierte Standardsprache Web-Service Business Process Execution Language lassen sich Prozesse modellieren und auf entsprechenden Engines ausführen. Der Standard selbst beinhaltet nur die Orchestrierung von Web Services. Aber durch Erweiterungen wie BPEL4People und einigen anderen lässt sich die Funktionalität enorm erhöhen. Die Modellierung der Prozesse mit WS-BPEL ist sehr komplex und umfangreich, so dass bereits kleine Prozesse hohen Aufwand erfordern. Daher bieten die meisten Engines graphische Werkzeuge zur Entwicklung an und erzeugen den Code intern. WS-BPEL bietet somit eine gute Möglichkeit, unternehmensspezifische Standards abzulösen und Business Process Management entlang der gesamten Supply Chain durchzuführen. 14

17 Literaturverzeichnis [Cov01] Cover, R. (2001): Technology Reports: XLANG. (abgerufen: ). [FrG08] [MSDN] [OAS07] [Sne01] [SBA08] Freud, J.; Götzer, K. (2008): Vom Geschäftsprozess zum Workflow: Ein Leitfaden für die Praxis. Carl Hanser Verlag, München. Microsoft (Hrsg.): Business Process Execution Language for Web Services Specification. (abgerufen: ). OASIS (Hrsg., 2007): OASIS News vom : Members Approve Web Services Business Process Execution Language (WS-BPEL) as OASIS Standard. (abgerufen: ). Snell, J. (2001): The Web services insider, Part 4: Introducing the Web Services Flow Language. (abgerufen: ). Statistisches Bundesamt (Hrsg., 2008): Unternehmen und Arbeitsstätten: Nutzung von Informations- und Kommunikationstechnologie in Unternehmen. [Sta05] Stapf, M. (2005): BPEL, das SQL der Prozesse. Javaspektrum 1/2005, [W3C99a] [W3C99b] [W3C01] [W3C04a] [W3CGl] [WiS06] Clark, J.; DeRose, S. (1999): W3C Recommendation: XML Path Language (XPath) Version (abgerufen: ). Clark, J. (1999): W3C Recommendation: XSL Transformations (XSLT) Version (abgerufen: ). Christensen, E.; Curbera, F.; Meredith, G.; Weerawarana, S. (2001): W3C Note: Web Services Description Language (WSDL) (abgerufen: ). Fallside, D.; Walmsley, P. (2004): W3C Recommendation: XML Schema Part 0: Primer Second Edition. (abgerufen: ). Haas, H.; Brown, A.: Web Services Glossary. (abgerufen: ). Winterberg, T.; Scheuch, R. (2006): Mit BPEL in eine neue Entwicklungs-Ära. Computerwoche 6/2006, 34 f. [WSB07] WSBPEL Technical Committee (2007): Web Services Business Process Execution Language Version 2.0: OASIS Standard. (abgerufen: ). 15