Prototypische GUI-Implementierung zur prozessorientierten Kopplung von BPMN-Modellen und Web Services

Inhaltsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

Abkürzungsverzeichnis

1. Einleitung
1.1 Aufbau der Arbeit

2. Business Process Execution Language
2.1 Begriffliche Abgrenzung
2.1.1 BPEL
2.1.2 WS-BPEL 2.0
2.1.3 BPEL4People
2.1.4 WS-BPEL 3.0
2.2 Zusammenhang zwischen BPEL und WSDL
2.3 Abbildungsvorschriften von BPMN nach BPEL
2.4 Komposition von Web Services
2.4.1 Orchestrierung
2.4.2 Choreografie
2.4.3 WS-CDL

3. Der BPMN-Modellierungsprototyp
3.1 Verwendete Entwicklungsumgebung und Software
3.2 Analyse und Design
3.3 Implementierung

4. Abschließende Betrachtung und Ausblick
4.1 Zusammenfassung
4.2 Ausblick

Anhang A: Abbildungsregeln von BPMN nach BPEL
A.1 Abbildung allg. Attribute eines BPMN-Diagramms
A.2 Abbildung der Attribute eines Geschäftsprozesses
A.3 Abbildung der Attribute für Flow-Objekte allgemein
A.4 Abbildung der Attribute für Activities
A.4.1 Abbildung der Attribute aller Activities
A.4.2 Abbildung von Schleifen
A.4.3 Abbildung der Attribute von Subprozessen
A.4.4 Abbildung der Attribute von Tasks
A.5 Abbildung der Attribute von Gateways
A.5.1 Abbildung der Attribute aller Arten von Gateways
A.5.2 Abbildung der Attribute von XOR-Gateways
A.5.3 Abbildung der Attribute von OR-Gateways
A.6 Abbildung der Attribute von Events
A.6.1 Abbildung der Attribute von Start Events
A.6.2 Abbildung der Attribute von End Events
A.7 Abbildung der Attribute von Sequence Flow
A.8 Abbildung der Attribute von Message Flow

Anhang B: Aufteilung der Implementierung

Anhang C: Aufteilung der Dokumentation

Literaturverzeichnis

Verzeichnis Elektronische Quellen

Abbildungsverzeichnis

Abbildung 1: Evolution des Standards WS-BPEL 2.0 [Bart05, S. 6]

Abbildung 2: BPMN als Schnittstelle [Kra+05, S. 108]

Abbildung 3: WSDL im SOA-Kontext (in Anlehnung an [PeRi05, S. 2])

Abbildung 4: Übersicht der verwendeten BPMN-Elemente

Abbildung 5: In BPMN modellierter Beispielprozess

Abbildung 6: In BPEL dargestellter Beispielprozess

Abbildung 7: Die verschiedenen Kompositionsmodelle [Masa07, S. 105]

Abbildung 8: Orchestrierung und Choreografie [Dos+05, S. 106]

Abbildung 9: Choreografie [Dos+05, S. 203]

Abbildung 10: Der Web Service Stack mit WS-CDL [Masa07, S. 259]

Abbildung 11: Paketdiagramm des Prototypen

Abbildung 12: Package bpelGen

Abbildung 13: Package bpmGui

Abbildung 14: Package elements

Abbildung 15: Package webServices

Abbildung 16: Benutzeroberfläche

Abbildung 17: Zoom-Funktion

Abbildung 18: Verbinden zweier Elemente mittels Sequence Flow

Abbildung 19: Verbinden zweier Elemente mittels Message Flow

Abbildung 20: Input-Dialog zur Benennung des neuen Elements

Abbildung 21: Set Name Schalter

Abbildung 22: Markiertes Element

Abbildung 23: Kontextmenü

Abbildung 24: Einfügen mittels Paste

Abbildung 25: Add Web Service

Abbildung 26: Auswahl eines Web Services

Abbildung 27: Auswahl einer Operation

Abbildung 28: Tasks mit zugeordnetem Web Service bzw. Operation

Abbildung 29: Öffnen eines Subprozesses

Abbildung 30: Menüleiste bei geöffnetem Subprozess

Abbildung 31: Ausschneiden und kopierenüber die Menüleiste

Abbildung 32: Öffnen, Speichern, Neu, Drucken, Schließen

Abbildung 33: Dialog Öffnen

Abbildung 34: Dialog Speichern

Abbildung 35: Sicherheitsabfrage

Abbildung 36: Druckfunktion

Abbildung 37: BPEL-Dokument generieren

Abbildung 38: Generierung des Zwischenformats .bpmn

Tabellenverzeichnis

Tabelle 1: Vergleich von BPEL mit WS-CDL [Masa07, S. 260]

Tabelle 2: Abbildung allg. Attribute eines BPMN-Diagramms

Tabelle 3: Abbildung allg. Attribute eines BPMN-Geschäftsprozesses

Tabelle 4: Abbildung allg. Attribute eines BPMN-Flow-Objekts

Tabelle 5: Abbildung allg. Attribute einer BPMN-Aktivität

Tabelle 6: Abbildung allg. Attribute eines BPMN-Subprozesses

Tabelle 7: Abbildung allg. Attribute eines BPMN-Diagramms

Tabelle 8: Abbildung allg. Attribute eines BPMN-Tasks

Tabelle 9: Abbildung der Attribute eines BPMN-Services

Tabelle 10: Abbildung allg. Attribute von BPMN-Gateways

Tabelle 11: Abbildung der Attribute eines BPMN-XOR-Gateways

Tabelle 12: Abbildung der Attribute eines BPMN-OR-Gateways

Tabelle 13: Abbildung der Attribute eines BPMN-Start-Events

Tabelle 14: Abbildung der Attribute eines BPMN-End-Events

Tabelle 15: Abbildung der Attribute eines BPMN-Sequence-Flows

Tabelle 16: Aufteilung der Implementierung in Stunden

Tabelle 17: Aufteilung der Dokumentation

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1. Einleitung

Durch den immer rasanteren technischen Fortschritt von Kommunikations- und Transporttechniken nimmt die internationale Verflechtung von Unternehmen stark zu. Dies hat seinen Ursprung in erster Linie bei der Globalisierung. Durch sie sind Unternehmen immer mehr gezwungen, sich stärker zu spezialisieren, bzw. sich auf ihre Kernkompetenzen zu konzentrieren. Dies hat zwei wichtige Folgen: Zum einen schrumpft die Zeitspanne, innerhalb derer (Software-) Produkte auf den Markt gebracht werden können und zum anderen steigt die Notwendigkeit der Kommunikation zwischen Unternehmen, da diese durch die Spezialisierung auf die in der Wertschöpfungskette vor- und nachgelagerten Unternehmen ange- wiesen sind.

An dieser Stelle setzt das Paradigma der Service-orientierten Architekturen (SOA) an: Durch die lose Kopplung von Softwarekomponenten soll zum einen eine flexiblere und schnellere Softwareentwicklung, verglichen mit der bisherigen Ent- wicklung von monolithischer (Individual-)Software, und zum anderen eine vereinfachte Kommunikation mit anderen Unternehmen ermöglicht werden. Einzelne Softwarebausteine bestehen dabei aus sogenannten Web Services, welche Funktionalität kapseln und durch ihre Schnittstellenöffentlichen Zugriff erlauben. Sie können dabei (z. T. automatisiert) zu komplexen Softwareprodukten zusammengesetzt werden.

Dazu benötigt man allerdings die Möglichkeit, die Geschäftsprozesse eines Unternehmens oder einer sogenannten Unternehmenskette (Supply Chain) zu modellieren, um diese Web Services den Bausteinen der Geschäftsprozesse zuzuordnen, um dann daraus ein Beschreibungsdokument zu erzeugen, welches wiederum der Erstellung der Software dienen soll.

An dieser Stelle setzt die vorliegende Arbeit an: Im theoretischen Teil werden die zugrundeliegenden Begriffe und Standards abgegrenzt und erläutert. Dabei handelt es sich in erster Linie um die Modellierungssprache Business Process Modeling Notation (BPMN) und Business Process Execution Language (BPEL) sowie die Transformationsregeln von BPMN nach BPEL, sowie um die Beschreibungssprache Web Service Choreography Description Language (WS- CDL) zur Choreografie von Web Services.

Im praktischen Teil wird ein Modellierungswerkzeug zur Modellierung von Geschäftsprozessen mittels BPMN implementiert. Dieses Werkzeug soll außer- dem eine Schnittstelle zur Generierung von BPEL Dokumenten sein, was dem oben genannten Beschreibungsdokument zur automatisierten Erstellung von Software entspricht.

1.1 Aufbau der Arbeit

Der theoretische Teil der vorliegenden Arbeit beschränkt sich im Wesentlichen auf Kapitel 2. In diesem Kapitel werden zunächst wesentliche Begriffe im Zusammenhang mit BPEL voneinander abgegrenzt. Danach wird der Zusammen- hang zwischen BPEL und WSDL erläutert. Anschließend werden die Transformationsregeln von BPMN nach BPEL an einem Beispiel gezeigt. Ab- schließend werden noch die verschiedenen Arten der Komposition von Web Services erklärt.

Der praktische Teil beschränkt sich wiederum auf Kapitel 3, das in Zusammenarbeit mit Patrick Müller [Müll08] entstanden ist, da die Implemen- tierung des Prototypen zur Modellierung von Geschäftsprozessen in BPMN bzw. zur automatisierten Generierung von BPEL-Dokumenten in gemeinsamer Arbeit entstanden ist und es als nicht sinnvoll erschien, die jeweils entwickelten Funktionsbausteine getrennt zu dokumentieren. Die Aufteilung der Implemen- tierungsarbeit ist in Anhang B und die Aufteilung der Dokumentationsarbeit in Anhang C ersichtlich.

Kapitel 4 als abschließender Teil ist in Zusammenarbeit entstanden und beinhaltet in erster Linie dem vorliegenden Prototypen fehlende Funktionen, welche in naher Zukunft, von auf der vorliegenden Studienarbeit aufbauenden Studienarbeiten, implementiert werden sollten.

2. Business Process Execution Language

Im vorliegenden Kapitel soll zunächst die begriffliche Abgrenzung der Standards rund um BPEL erfolgen. Danach werden weitere Standards, wie z.B. WSDL beleuchtet, da BPEL auf ihnen aufbaut. Weiterhin werden Abbildungsvorschriften von BPMN nach BPEL exemplarisch vorgestellt und auszugsweise erklärt. Im Anschluss daran erfolgt dann die Beschreibung der Komposition von Web Services, welche im Wesentlichen in BPEL umgesetzt wird. Es wird dabei auch dargestellt, wann sich eine andere Beschreibungssprache, nämlich WS-CDL, für die Komposition von Web Services, verwenden lässt und in welchen Fällen dies möglich ist.

2.1 Begriffliche Abgrenzung

In diesem Kapitel erfolgt eine Abgrenzung der in der vorliegenden Arbeit häufig verwendeten, bzw. im Allgemeinen häufig zu Verwirrung führenden Begriffe. In Abbildung 1 werden alle wesentlichen Beschreibungs- bzw. Modellierungs- sprachen abgebildet, die die aktuelle Spezifikation der BPEL, WS-BPEL 2.0, beeinflusst haben. Da die Erstellung der WS-BPEL 3.0 Spezifikation nach wie vor noch nicht abgeschlossen ist, ist die Abbildung immer noch aktuell. Im Folgenden wird ein Überblicküber BPMN 1.0, WS-BPEL 2.0, WS-BPEL 3.0, WS-CDL, und BPEL4WS 1.1 gegeben.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Evolution des Standards WS-BPEL 2.0 [Bart05, S. 6]

BPMN wurde, wie in Abbildung 1 ersichtlich, von der Organisation BPMI erstellt, welche seit Juni 2005 zur Object Management Group (OMG) gehört. Zu diesem Zeitpunkt vereinigten die beiden Organisationen ihre Bestrebungen bezüglich der Standardisierung des Business Process Management (BPM) und stellten gemeinsam den Standard BPMN 1.0 adopted fertig.

Die BPMN wird verwendet, um Geschäftsprozesse grafisch zu modellieren. KRAFZIG et al. vergleichen BPMN mit der Unified Modeling Language (UML), da beide eine grafische Repräsentation von Objekt-Modellen bieten, welche unabhängig von der darunterliegenden Implementierungssprache seien [Kra+05, S.107]. An dieser Stelle wird aber auch hervorgehoben, dass BPMN im Vergleich zur UML viel geeigneter für die Modellierung von Geschäftsprozessen sei, da sie in erster Linie für den Gebrauch in Bezug auf BPM entwickelt worden sei [Kra+05, S.107].

Weiterhin sei UML eher in der IT-Organisation angesiedelt, um abstrakte Konzepte und Modelle zu verdeutlichen; BPMN hingegen habe als Ziel, der de facto Standard für die Schnittstelle zwischen IT und Betriebswirtschaft zu werden [Kra+05, S. 107], wie in Abbildung 2 dargestellt:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: BPMN als Schnittstelle [Kra+05, S. 108]

Außerdem beinhaltet die Spezifikation der BPMN einen Satz an Transformationsregeln zur Umwandlung eines in BPMN erstellten Modells nach BPEL4WS 1.1 [Obje06, S. 137 ff ]. Wie in Abbildung 1 zu sehen ist, ist BPEL4WS 1.1 allerdings nicht der aktuellste Standard. Eine aktuelle BPMNSpezifikation, mit Transformationsregeln beispielsweise für den aktuellen Standard WSBPEL 2.0, liegt leider derzeit noch nicht vor.

2.1.1 BPEL

BPEL ist ein Überbegriff der Spezifikationen WS-BPEL 2.0, WS-BPEL 3.0 und BPEL4WS. Daher soll an dieser Stelle nurüber allgemeine Eigenschaften der BPEL berichtet werden.

Die Beschreibungssprache BPEL hat seinen Ursprung in den XML-Sprachen von XLANG Microsoft und IBMs Web Service Flow Language WSFL, siehe Abbildung 1.

WSFL beschreibt Geschäftsprozesse als gerichtete Aktivitätsgrafen, wohingegen sich XLANG eher auf die Spezifikation des Nachrichtenaustausches von Web Services konzentriert [Wee+05, S. 316 f. ].

Laut WEERAWARANA et al. ist BPEL daher eine Kombination der Graforientierten Darstellung von WSFL und des algebraischen Stils von XLANG [Wee+05, S. 317].

Weiterhin definieren STARKE und TILKOV BPEL als „XML-basierte Sprache zur Orchestrierung von Webservices“ [StTi07, S. 811]. Als Intention von BPEL nennen diese die Beschreibung von „[…] Geschäftsprozesse[n] als Zusammenspiel einzelner Services“ [StTi07, S. 811].

An dieser Stelle sei darauf hingewiesen, dass die genauere Erläuterung des Begriffs der Orchestrierung in Kapitel 2.5 erfolgt.

2.1.2 WS-BPEL 2.0

2002 von IBM, Bea und Microsoft eingeführt, damals noch BPEL4WS genannt, wird die Weiterentwicklung seit 2003 von der Organization for the Advancement of Structured Information Standards (Oasis) vorangetrieben, was im derzeit aktuellen Standard WS-BPEL 2.0 [Alv+07] mündete, siehe Abbildung 1.

2.1.3 BPEL4People

Die WS-BPEL Extension for People (BPEL4People), Version 1.0, ist ein Standard, der menschliche Interaktionen in BPEL darstellbar machen soll [Agr+07, S. 3]. Die in erster Linie aus den Häusern IBM und SAP stammenden Autoren definieren darin eine neue Art von Aktivität, welche menschliche Aktivitäten sozusagen als Implementierung verwenden können [Agr+07, S. 3]. Wie in Abbildung 1 zu sehen war, ist ein Einfluss von BPEL4People auf die kommende Version WS-BPEL 3.0 geplant, aber noch nicht sicher.

2.1.4 WS-BPEL 3.0

Mit Spannung wird die Weiterentwicklung WS-BPEL 3.0 erwartet, hier sollen die Anregungen des BPEL4People Standards integriert werden. Wann diese Version erscheinen wird, ist momentan noch völlig ungewiss.

2.2 Zusammenhang zwischen BPEL und WSDL

Laut ALVES et al. hängt WS-BPEL 2.0 von den folgenden XML-basierenden Spezifikationen ab: WSDL 1.1, XML Schema 1.0, Xpath 1.0, XSLT 1.0 und Infoset, vgl. [Alv+07, S. 11].

Darunter habe WSDL den größten Einfluss auf WS-BPEL, da das WS-BPEL- Prozessmodell auf dem durch WSDL 1.1 definierten Servicemodell läge [Alv+07, S. 11]. Aufgrund des großen Einflusses von WSDL soll an dieser Stelle nur der Zusammenhang von WSDL und WS-BPEL näher beleuchtet werden, da eine Erläuterung aller oben genannten Standards den Rahmen der Arbeit sprengen würde.

Mit Hilfe von WSDL werden alle externen Ressourcen und Partner durch die Definition von Schnittstellen beschrieben. Dabei besitzen auch die BPELProzesse eine Schnittstellenbeschreibung in WSDL, da sie selbst auch nach außen wie Web Services agieren sollen [PeRi05, S. 2].

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: WSDL im SOA-Kontext (in Anlehnung an [PeRi05, S. 2])

In Abbildung 3 zeigt sich nun folgendes Zusammenspiel: Der Service Provider stellt seine Web Services in Form von WSDL-Beschreibungsdokumenten bereit und trägt diese in ein zentrales Verzeichnis ein. Dieses wird hier als Universal Discovery and Description (UDDI)-Verzeichnis dargestellt. Ein Service Requestor, der ein Client oder auch ein anderer Web Service sein kann, kann auf diese bereitgestellten Informationen zugreifen. Anhand der bereitgestellten Be- schreibung, wird auch die Kommunikationsart bzgl. der Services festgelegt, sodass der Requester diese direkt beim Provider ausführen kann [ReSt04, S. 2]. Was hat dies nun mit BPEL zu tun?

PERA und RINTELMANN schreiben hierzu:

„Ein BPEL Prozess kann als [ein] aus Web Services zusammengesetzter Service gesehen werden, wobei diese Web Services selbst wieder durch BPEL Prozesse implementiert sein können.“ [PeRi05, S. 2].

Ein Geschäftsprozess definiert also die Koordination der Interaktionen der Prozessinstanzen und deren Partner bzw. eine BPEL Prozess-Definition bietet und bzw. oder verwendet einen oder mehrere WSDL Services [Alv+07, S. 11].

2.3 Abbildungsvorschriften von BPMN nach BPEL

Um aus einem BPMN-Diagramm ein BPEL-Dokument zu erzeugen, damit dieses von einer BPEL-Engine eingelesen und verarbeit werden kann, müssen für jedes BPMN-Element Transformationsregeln festgelegt werden. Dies ist vor allem wichtig, da eine konsistente und automatisierte Transformation von BPMN nach BPEL möglich sein soll. Abbildung 4 zeigt alle in der vorliegenden Arbeit verwendeten Elemente; sie bilden ein sogenanntes Core Component Set (CCS) und bestehen im Wesentlichen aus den am häufigsten in BPMN verwendeten Elementen zur Modellierung von Geschäftsprozessen.

Nachfolgend wird exemplarisch ein in BPMN modellierter Geschäftsprozess erläutert und dessen Transformation in BPEL gezeigt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Übersicht der verwendeten BPMN-Elemente

In Abbildung 5 ist ein einfacher Geschäftsprozess dargestellt; dabei geht es um einen möglichen Prozess im Rahmen des Neuanlegens eines Kunden in einem Unternehmen, hier in der Abteilung Vertrieb.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: In BPMN modellierter Beispielprozess

Das Start-Event zeigt dabei in der Regel auf das erste Element eines Geschäfts- prozesses, in unserem Fall zeigt es auf „Kundeüberprüfen“. Dazu gehört auch ein sogenanntes Artefakt: ein Informationsobjekt, das auf vorhandene Daten des Kunden zeigt. Danach muss entschieden werden, ob der Kunde in der Datenbank schon angelegt wurde oder nicht. Dabei kann nur eine von beiden Möglichkeiten gewählt werden, da diese sich gegenseitig ausschließen. Deshalb erfolgt die Verzweigung anhand eines XOR-Objekts. Dabei wäre es auch möglich ein allgemeines XOR zu wählen; der einzige Unterschied ist, dass dieses nicht durch ein ‚X’ markiert ist.

Für den Fall, dass der Kunde in der Datenbank noch nicht existiert, wird nun der Prozess ‚Kunde anlegen’ ausgeführt - der Kunde wird in der Datenbank neu angelegt. Im anderen Fall stößt man nun auf ein Element, das sich „Subprozess“ nennt und durch ein kleines ‚+’ in einem Kästchen am unteren Rand eines Prozesssymbols befindet. Das bedeutet, dass innerhalb dieser Tätigkeit noch ein weiterer Geschäftsprozess hinterlegt ist, in dem der Datenabgleich zwischen bereits in der Datenbank vorhandenen und den aktuell vorliegenden Daten erfolgt. Wenn eine von beiden Aktivitäten abgeschlossen ist, werden die verzweigten Kontrollflüsse wieder durch ein XOR zusammengeführt, da sie vorher durch ein XOR verzweigt wurden. Verzweigung und Zusammenführung müssen also durch das gleiche Gateway erfolgen.

Dieses XOR-Element zeigt auf ein End-Event, was bedeutet, dass der Geschäftsprozess nun abgeschlossen ist.

In Abbildung 6 ist die Umsetzung des exemplarischen BPMN-Geschäftsprozesses in BPEL zu sehen:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6: In BPEL dargestellter Beispielprozess

Bevor es nun zu der genauen Erklärung des in Abbildung 6 dargestellten Prozesses kommt, soll zunächst festgestellt werden, dass es durch das Design von BPEL Beschränkungen in Bezug auf die Prozess-Topologien, die in BPEL beschrieben werden können, gibt.

Dadurch ist es möglich, BPMN-Prozesse darzustellen, die nicht in BPELüber- führt werden können [Obje06, S. 178].

Es gibt einige wenige Ausdrücke in BPMN, die BPMN zwar repräsentieren kann, welche aber mit keiner Technologie implementiert werden können. Dazu gehören u. a. Pools, Lanes und Artefakte. Ein Pool kann zwar aus organisatorischen Gründen einen gesamten BPEL Geschäftsprozess umfassen; dies wird aber durch keinen Ausdruck in BPEL ausgewiesen. Aus diesem Grund enthält Abbildung 6 keinerlei Elemente, die den Pool „Vertrieb“ oder das Artefakt „Kunde“ repräsentieren.

Jedes BPEL-Dokument beginnt zunächst mit dem im XML-Standard festgelegten Prolog <?xml version="1.0" encoding="UTF-8"?> [Stey05, S.34]. Weiterhin wird der gesamte Geschäftsprozess mit <process> bzw. <process/> Klammern umschlossen. Dabei werden imöffnenden Tag verschiedene Attribute festgelegt; zum einen der Name des Prozesses, der XML-Namespace nach dem aktuellen BPEL-Standard WS-BPEL 2.0 und zum anderen noch der sogenannte Target Namespace. Da die genaue Erläuterung dieser XML-spezifischen Deklaration den Rahmen dieser Arbeit sprengen würde, sei an dieser Stelle auf die offizielle XML-Spezifikation [Bra+06] bzw. auf weiterführende Literatur, wie z.B. [Stey05] verwiesen.

Innerhalb der <process> Tags erfolgt zunächst die Definition sogenannter partnerLinks. Normalerweise werden hier extern aufgerufene Services deklariert. Da in unserem Beispiel keine externen Services verwendet werden, stehen dort keine.

Im Anschluss werden die verwendeten Variablen deklariert. Man kann hier mit <variable name=" " /> quasi beliebig Variablen deklarieren und im weiteren Verlauf wiederverwenden. Allerdings müssen auf jeden Fall die Variablen für die verschiedenen verzweigenden Äste, beispielsweise bei Verwendung einer Verzweigung in Form eines XORs, festgelegt werden.

Nach der Variablendeklaration erfolgt nun die Modellierung des eigentlichen Ab- laufs. <sequence> legt dabei eigentlich nur fest, dass die von <sequence> eingeschlossenen Elemente in der im BPEL-Dokument festgelegten Reihenfolge abgearbeitet werden müssen. Die im Beispiel vorgenommene Namensvergabe ist optional.

Innerhalb von <sequence> werden weitere Elemente definiert. receive name="ProcessInstantiation" sorgt dafür, dass durch das Aufrufen des definierten Geschäftsprozesses eine Instanz desselben erzeugt wird, anhand derer die eigentliche Ausführung des Prozesses erfolgt. Dabei werden verschiedene Attribute festgelegt, wie z.B. dass die Instanziierung lokal erfolgt. Für genauere Erklärungen bzgl. dieser Eigenschaften, sei auf Anhang A, Kapitel A.1 bzw. A.2 verwiesen. Der Aufruf von receive name="ProcessInstantiation" entspricht dabei dem Start-Event in BPMN.

Nun erfolgt die Deklaration der ersten Tätigkeit Kundeüberprüfen mit invoke name="KundeUeberpruefen". Auch hier werden analog zu receive versch. Eigenschaften festgelegt. Zusätzlich werden noch inputVariable und outputVariable deklariert, was den in die Tätigkeit ein- bzw. ausgehenden Daten entspricht. Im Anschluss daran erfolgt die erste Verzweigung des Workflows mittels <switch>. An dieser Stelle benötigen wir zum ersten Mal eine zu Beginn bereits deklarierte Variable: <case condition="kunde_nex"> zeigt an, dass direkt darunter alle Elemente stehen, die bei der Wahl der Verzweigung Kunde existiert noch nicht abgearbeitet werden. Das Ende dieser einen Verzweigung wird mit einem schließenden Tag, </case>, angezeigt. Die Deklaration der anderen möglichen Verzweigung erfolgt analog. Die in der erstgenannten Verzweigung erfolgende Deklaration von Kunde Anlegen erfolgt analog zur Deklaration von Kundeüberprüfen. Die Deklaration des Subprozess-Elements der zweiten Verzweigung erfolgtähnlich, weist aber einen kleinen Unterschied auf: operation= "call_DatenPruefen" weist auf den Aufruf eines weiter unten oder in einem anderen BPEL-Dokument definierten Geschäftsprozesses namens DatenPruefen hin. Dieser wird wiederum genauso wie der bereits dargestellte Geschäftsprozess modelliert, das heißt, auch dieser kann wieder Subprozesse enthalten, sodass eine mehrfache Verschachtelung möglich ist.

Am Schluss des BPEL-Dokuments erfolgt nur noch das Schließen der ineinander verschachtelten Tags, und zwar in der Reihenfolge, in der sie geöffnet wurden. Da eine genaue Beschreibung aller in BPEL möglichen Attribute den Rahmen der Arbeit an dieser Stelle sprengen würde, sei zum Schluss nochmals auf Anhang A, Abbildungsregeln von BPMN nach BPEL, verwiesen.

2.4 Komposition von Web Services

In diesem Kapitel sollen die Begriffe „Komposition, Orchestration und Choreografie“ voneinander abgegrenzt und näher beleuchtet werden. Darüber hinaus soll die Web Services Choreography Description Language (WS-CDL), die für die Erstellung von Web Service Choreografien verwendet wird, beschrieben, eingeordnet und mit BPEL verglichen werden.

Um aus elementaren Web Servicesübergeordnete zusammen zu stellen (Komposition), wird im Allgemeinen zwischen zwei verschiedenen Heran- gehensweisen unterschieden [Dos+05, S. 202 ff. ], [Masa07, S. 105 ff. ], [ReSt04, S. 26 ff. ] und [StTi07, S. 443 f. ]: Orchestration gegenüber Choreografie von Web Services. Dabei stellt die Komposition einen Teil der Mächtigkeit des Service-Orientierungsparadigmas dar [Masa07, S. 104].

MASAK bezeichnet die (Service-)Komposition von Web Services als eine grund- legende Flexibilität, “[...] damit sehr rasch auf Veränderungen der Umgebung reagiert werden kann.“ [Masa07, S. 104]. Er unterscheidet dabei zwischen „Geschäftsprozesskomposition“ und „Servicelevelkomposition“. Der Unterschied besteht dabei in den verwendeten Abstraktionsebenen. Auf der Abstraktionsebene der Geschäftsprozesse werden „[...] völlig neue Geschäftsprozesse aus be- stehenden Teilprozessen oder Services“ komponiert. Als Vorteile davon sieht MASAK für den Endbenutzer Transparenz und Kundenzentriertheit. Als Nachteil nennt er eine durch die „hochgradige Interaktivität“ nötige „intensive Beteiligung von Domänenexperten“ [Masa07, S. 104].

Bei der Servicelevelkomposition, d.h. bei der Komposition auf Serviceebene, wird die Komposition von Services hingegen mit Workflowsystemen verglichen, wobei hier „Interoperabilität und technische Machbarkeit im Vordergrund“ stehen. Als Nachteil wird die mangelnde „Berücksichtigung organisatorischer Abläufe“ [Masa07, S.105] bezeichnet.

Weiterhin kann die Servicekomposition in verschiedene Kompositionsmodelle unterteilt werden, wie in Abbildung 7 dargestellt:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 7: Die verschiedenen Kompositionsmodelle [Masa07, S. 105]

Dabei wird zwischen zwei Gruppen von Kompositionsmodellen unterschieden: Statische und dynamische Komposition, welche jeweils eine andere Art von Ergebnis generieren. Die dynamische Komposition generiert semantische, die statische dagegen komplexe Services, die entweder durch Orchestrierung oder durch eine Choreografie komponiert wurden.

Im Hinblick auf die dynamische Komposition beschreibt HEUTSCHI diese als „[...] einen Schritt weiter in der Automatisierung der Applikationsentwicklung […]“ und nennt dies „Vision einer regelbasierten, dynamischen Servicekomposition“ [Heut07, S. 187]. Weiterhin meint HEUTSCHI, dass sich solch ein Automatisierungsgrad „[...] ausserhalb geschlossener, semantisch stark standardisierter Bereiche […]“ in naher Zunkunft nicht realisieren ließe [Heut07, S. 188]. An dieser Stelle sei auf die Seminararbeit [Meix08] verwiesen, welche sich mit dem Semantic Web in Bezug auf SOA und im Speziellen auch mit der dynamischen Komposition von Web Services beschäftigt, verwiesen.

Bei der statischen Komposition stellt sich hingegen die zentrale Frage: „Wie kann ein Service genutzt werden, um eine komplexe Aufgabenstellung zu lösen?“

[...]