close

Anmelden

Neues Passwort anfordern?

Anmeldung mit OpenID

BPEL – Wie werden meine Prozesse ausgeführt? - Fakultät für

EinbettenHerunterladen
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: 81828
Wirtschaftsinformatik
Thomas-Mann-Straße 18
07743 Jena
jens.bachm@gmx.de
Jena, den 16. Juli 2009
Inhaltsverzeichnis
1
Einleitung
1
2
Entstehung des Standards
1
3
Funktionsweise von BPEL
2
3.1
Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
3.2
Syntax: Prozessdefinition . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
3.2.1
Grundstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
3.2.2
<partnerLinks> . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
3.2.3
<variables> . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
3.2.4
Weitere Deklarationen . . . . . . . . . . . . . . . . . . . . . . . .
5
Syntax: Elementare Aktivitäten . . . . . . . . . . . . . . . . . . . . . . . .
6
3.3.1
<invoke>, <receive> und <reply> . . . . . . . . . . . . . . . .
6
3.3.2
<assign> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
3.3.3
Weitere Aktivitäten . . . . . . . . . . . . . . . . . . . . . . . . . .
7
Strukturierte Aktivitäten . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
3.4.1
<sequence> . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
3.4.2
<flow> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
3.4.3
<if> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
3.4.4
<while> und <repeatUntil> . . . . . . . . . . . . . . . . . . . .
9
3.4.5
<forEach> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
3.4.6
<pick> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
Ausführung der Prozesse durch BPEL-Engines . . . . . . . . . . . . . . .
11
3.3
3.4
3.5
4
Beispiel-Modellierung mit BPEL
12
5
Zusammenfassung
14
Literaturverzeichnis
15
i
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
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. E-Mail, 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
• XML Schema: legt in einer XML-Schema-Definition (XSD) die Strukturen für XMLDokumente 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
3.2.1
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
2
< process name = " meinProzess " > <! -- Prozess -- >
targetNamespace = " anyURI "
3
4
5
< extensions >
</ extensions >
<! -- Erweiterungen -- >
< imports / >
<! -- externe Abhängigkeiten -- >
< partnerLinks >
</ partnerLinks >
<! -- Dienste -- >
6
7
8
9
10
11
12
13
< messageExchanges >
</ messageExchanges >
3
14
< variables >
</ variables >
15
16
<! -- Daten -- >
17
< correlationSets >
</ correlationSets >
18
19
20
21
22
< faultHandlers >
</ faultHandlers >
<! -- Fehlerbehandlung -- >
< eventHandlers >
</ eventHandlers >
<! -- Ereignisbehandlung -- >
23
24
25
26
27
28
29
30
31
32
< sequence name = " meineSeq " >
<! -- Ablaufsequenz -- >
< receive >
< assign >
<! -- Aktivitäten -- >
< reply >
</ sequence >
</ 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.
3.2.2
<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
2
3
4
5
6
< partnerLinks >
< partnerLink name = " Fluggesellschaft "
partnerLinkType = " wsdl:FLugPLT "
myRole = " VerfügbarkeitAbfragen "
partnerRole = " FlugService " / >
</ partnerLinks >
Listing 2: PartnerLinks
4
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
2
3
4
5
< variables >
< variable name = " FlugAnfrage " messageType = " FlAnNa " / >
< variable name = " FlugAntwort " messageType = " FlAwNa " / >
< variable name = " FlugPreis " type = " xsd:decimal " / >
</ variables >
Listing 3: Variablen
Um Variablen zu verändern, kann in BPEL standardmäßig X-Path 1.0 genutzt werden [WSB07,
S. 45 ff.].
3.2.4
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
• <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.
3.3.1
<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
1
2
3
4
5
6
< invoke name = " VerfügbarkeitFlugPrüfen "
partnerLink = " Fluggesellschaft "
operation = " FrageVerfügbarkeitAb "
inputVariable = " FlugAnfrage "
outputVariable = " FlugAntwort "
</ 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.
3.3.2
<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
2
3
4
5
6
< assign >
< copy >
< from variable = " Quelle " / >
< to variable = " Ziel " / >
</ copy >
</ assign >
Listing 5: Assign
3.3.3
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
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.
3.4.1
<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
2
3
4
5
6
< sequence name = " AnfrageDienstreise " >
< receive name = " EingangAnfrage " ... / >
< invoke name = " VerfügbarkeitFlugPrüfen " ... / >
< invoke name = " VerfügbarkeitHotelPrüfen " ... / >
< reply name = " SendeRückmeldung " ... / >
</ 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.
3.4.2
<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
2
3
4
< receive name = " EingangAnfrage " ... / >
< flow ... >
< invoke name = " VerfügbarkeitFlugPrüfen " ... / >
< invoke name = " VerfügbarkeitHotelPrüfen " ... / >
8
5
6
7
< invoke name = " VerfügbarkeitMietwagenPrüfen " ... / >
</ flow >
< reply name = " SendeRückmeldung " ... / >
Listing 7: Flow
3.4.3
<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
5 000 Euro liegt, in diesem Fall soll ein Service aufgerufen werden, der zehn Prozent Rabatt
berechnet. Andernfalls prüft der Prozess, ob der Preis über 2 500 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
2
3
4
5
6
7
8
9
10
11
12
13
14
15
< if name = " Rabatt " >
< condition >
$ preis & gt ; 5000
</ condition >
< invoke name = " ZehnProzentRabatt " ... / >
< elseif >
< condition >
$ preis & gt ; 2500
</ condition >
< invoke name = " FünfProzentRabatt " ... / >
</ elseif >
< else >
< reply name = " keinRabatt " ... / >
</ else >
</ if >
Listing 8: If
3.4.4
<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
der Zähler erhöht werden, solange dieser kleiner oder gleich fünf ist. Dazu wird wieder ein
entsprechender Service aufgerufen.
1
2
3
4
5
6
< while >
< condition >
$ i & lt ;= 5
</ condition >
< invoke name = " Plus1 " .../ >
</ while >
1
2
3
4
5
6
< repeatUntil >
< invoke name = " Plus1 " .../ >
< condition >
$ i & lt ;= 5
</ condition >
</ repeatUntil >
Listing 9: While
3.4.5
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
2
3
4
5
6
7
< forEach counterName = " N " parallel = " no " ... >
< startCounterValue >0 </ startCounterValue >
< finalCounterValue >9 </ finalCounterValue >
< scope >
< invoke name = " PrüfeVerfügbarkeit " ... / >
</ scope >
</ forEach >
Listing 11: ForEach
3.4.6
<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
1
2
3
4
5
6
7
8
9
10
11
< pick >
< onMessage partnerLink = " Fluggesellschaft "
operation = " FlugVerfügbar "
variable = " FlugAntwort " >
< invoke name = " FlugBuchen " ... / >
</ onMessage >
< onAlarm >
< for > P0Y0M0DT0H15M0S </ for >
< sequence name = " BuchungAbbrechen " ... / >
</ onAlarm >
</ 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 WebSphere, 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
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
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
< process name = " Seminarteilnahme " >
< sequence >
< pick >
< onAlarm >
< until >
’ 2009 -04 -15 T16:00:00 +02 :00 ’
</ until >
< sequence >
<! -- Kickoff -- >
</ seqence >
</ onAlarm >
</ pick >
< flow >
< invoke name = " Anmeldung " >
partnerLink = " Prüfungsamt "
operation = " anmelden "
</ invoke >
< repeatUntil >
<! -- Besprechung des Themas -- >
<! -- Bearbeitung des Themas -- >
< condition >
current - date () & lt ; 2009 -06 -25
</ condition >
</ repeatUntil >
</ flow >
<! -- Vortrag halten -- >
<! -- Ausarbeitung schreiben
und abgeben -- >
< if >
< condition >
<! -- Ausarbeitung nicht ok -- >
</ condition >
<! -- Korrigieren und abgeben -- >
</ if >
< wait >
< for > ’ P5DT10H ’ </ for >
</ wait >
< if >
< condition >
<! -- bestanden -- >
</ condition >
<! -- Scheinvergabe -- >
< else >
< exit ... / >
</ else >
</ if >
</ sequence >
</ process >
Listing 13: Beispiel-Workflow
13
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
Literaturverzeichnis
[Cov01]
Cover,
R.
(2001):
Technology
Reports:
http://xml.coverpages.org/xlang.html (abgerufen: 13.05.2009).
XLANG.
[FrG08]
Freud, J.; Götzer, K. (2008): Vom Geschäftsprozess zum Workflow: Ein Leitfaden für die Praxis. Carl Hanser Verlag, München.
[MSDN]
Microsoft (Hrsg.): Business Process Execution Language for Web Services Specification. http://msdn.microsoft.com/en-us/library/aa479359.aspx (abgerufen:
09.05.2009).
[OAS07]
OASIS (Hrsg., 2007): OASIS News vom 12.04.2007: Members Approve Web
Services Business Process Execution Language (WS-BPEL) as OASIS Standard. http://www.oasis-open.org/news/oasis-news-2007-04-12.php (abgerufen:
09.05.2009).
[Sne01]
Snell, J. (2001): The Web services insider, Part 4: Introducing the Web Services
Flow Language. http://www.ibm.com/developerworks/library/ws-ref4/ (abgerufen: 13.05.2009).
[SBA08]
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, 54-57.
[W3C99a] Clark, J.; DeRose, S. (1999): W3C Recommendation: XML Path Language
(XPath) Version 1.0. http://www.w3.org/TR/xpath (abgerufen: 02.06.2009).
[W3C99b] Clark, J. (1999): W3C Recommendation: XSL Transformations (XSLT) Version 1.0. http://www.w3.org/TR/xslt (abgerufen: 02.06.2009).
[W3C01]
Christensen, E.; Curbera, F.; Meredith, G.; Weerawarana, S. (2001): W3C Note:
Web Services Description Language (WSDL) 1.1. http://www.w3.org/TR/wsdl
(abgerufen: 01.06.2009).
[W3C04a] Fallside, D.; Walmsley, P. (2004): W3C Recommendation: XML Schema Part
0: Primer Second Edition. http://www.w3.org/TR/xmlschema-0/ (abgerufen:
02.06.2009).
[W3CGl]
Haas, H.; Brown, A.: Web Services Glossary. http://www.w3.org/TR/ws-gloss
(abgerufen: 14.05.2009).
[WiS06]
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. http://docs.oasisopen.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.html (abgerufen: 18.05.2009).
15
Document
Kategorie
Internet
Seitenansichten
7
Dateigröße
569 KB
Tags
1/--Seiten
melden