Bachelorarbeit. Konzeption und Umsetzung einer Praktikumsaufgabe zur Komposition von Web Services mit BPEL

Transkript

1 TECHNISCHE UNIVERSITÄT DRESDEN FAKULTÄT INFORMATIK INSTITUT FÜR SYSTEMARCHITEKTUR PROFESSUR RECHNERNETZE PROF. DR. RER. NAT. HABIL. DR. H. C. ALEXANDER SCHILL Bachelorarbeit Konzeption und Umsetzung einer Praktikumsaufgabe zur Komposition von Web Services mit BPEL Jens Buschek (Mat.-Nr.: ) Betreuerin: Dr.-Ing. Iris Braun Dresden, 9. Apr. 2007

2 1 Inhaltsverzeichnis 1 Einleitung 4 2 Konzept Einleitung Ziele Wissensvermittlung Kontrolle der Lösungen Aufgabenverteilung Ergebnisse Praxiskonzept BPEL Laufzeitumgebung BPEL Modellierungswerkzeuge Web Services Realisierung Dokumente Technologien Praktikumsaufgaben Anwendungen ActiveBPEL Designer Zusammenfassung 12 Literaturverzeichnis 13 A Technologieübersicht 15 A.1 Einleitung A.2 WS-BPEL A.2.1 Aufbau A.2.2 Data Handling

3 2 A Variablen A Funktionen A.2.3 Aktivitäten A Standardelemente A Basisaktivitäten A Strukurierte Aktivitäten A.2.4 Linksemantik A.2.5 Partnerdefinitionen A.3 WSDL A.4 XPath B Praktikumsaufgaben 32 B.1 Tutorial B.1.1 Einleitung B.1.2 Installation B.1.3 Reisebuchung WSDL B.1.4 Web Services B.1.5 Erstellung eines BPEL Prozesses mit dem ActiveBPEL Designer B Projekterstellung B Erstellung von Partner Links B Aufruf der Web Services B Bedingungen B Assign - Wertübergaben an die Variablen B Scope B Simulation des Prozesses B Compensation Handler B.1.6 Deployment B.2 Aufgabenstellung B.2.1 Buchung des Rückflugs und Fehlerbehandlung B.2.2 Web Service zur Hotelbuchung

4 3 Erklärung Hiermit erkläre ich, dass ich die von mir Arbeit vollkommen selbstständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel benutzt sowie Zitate kenntlich gemacht habe. Dresden, den 9. April 2007 Jens Buschek

5 1. EINLEITUNG 4 1 Einleitung Steigende Wartungskosten und sinkende Flexibilität in großen, verteilten Anwendungslandschaften treiben die Entwicklung des SOA Konzeptes voran. Mit SOA sollen die Kapselung (Information Hiding) und die Trennung der Belange (Separation of Concerns) umgesetzt werden [7]. Ziel hierbei ist die Verbesserung der Flexibilität, mit der Anpassungen von Geschäftsprozessen an Veränderungen des Marktes zeitnah und kostengünstig vorgenommen werden können.weiterhin können mit SOA Geschäftsprozesse auch unternehmensweit flexibel vernetzt werden. Mit SOA steht das Prinzip der Wiederverwendung von Softwarebausteinen im Mittelpunkt des Softwarewareentwicklungsprozesses [2]. Die seit dem Wintersemester 2006/07 an der Fakultät Informatik der Technischen Universität Dresden angebotene Vorlesung Entwicklung Verteilter Systeme auf Basis Serviceorientierter Architekturen behandelt dieses Thema und ermöglicht mit den angebotenen Übungen die praktische Anwendung des vermittelten Stoffes. Meine Aufgabe war die Konzeption und Entwicklung einer Praktikumsaufgabe mit dem Inhalt Komposition von Web Services mit BPEL. Diese Arbeit soll als Erweitung der Übung für die o.g. Vorlesung dienen. Die bereits zu dieser Vorlesung vorliegende Übung bzw. das Tutorial zum Bereich der Web Services wird damit das Thema der Komposition von Web Services zu Geschäftsprozessen bzw. Workflows mit Hilfe von BPEL erweitert [8]. Die Prozessorientierung, eine der Säulen einer Serviceorientierten Architektur, kann mithilfe dieser Art der Geschäftsprozessmodellierung realisiert werden. Dabei werden einzelne Arbeitsschritte bzw. Prozesse zu einem Workflow zusammengestellt, aus dem schließlich ein geschäftlicher Mehrwert entsteht. [6] In diesem Dokument werden die Anforderungen an die verwendete Software sowie die zugehörigen Technologien beschrieben. Der Leser bekommt einen Einblick in Erstellung und Start von BPEL Prozessen. Gliederung Die Arbeit besteht aus sechs Hauptelementen. Der folgende Bereich behandelt das Konzept für die Praktikumsaufgabe, während sich der dritte mit der Realisierung befasst. Es folgen Bewertung und Zusammenfassung. Die letzten beiden Kapitel im Anhang beinhalten das Material für die Studenten. Es handelt sich um eine Übersicht und Beschreibung der Technologien sowie um die Praktikumsaufgaben.

6 2. KONZEPT 5 2 Konzept 2.1 Einleitung Die Studenten sollen mit Hilfe der Anleitung und der Aufgabenstellung einen praktischen Einblick in das SOA Konzept durch die Komposition von Web Services mit BPEL erhalten. Aufbauen soll dies auf der Praktikumsaufgabe Implementierung eines Web Services und verschiedener Client Applikationen. 2.2 Ziele Die Hauptziele sind die Wissensvermittlung für die Studenten, sowie die einfache Kontrolle der Lösungen durch den Tutoren Wissensvermittlung Die Wissenvermittlung des BPEL Konzeptes erfolgt mit der Umsetzung einer Reisebuchung als Geschäftsprozess, der auf die Web Services Flugbuchung und Autobuchung zugreift. Für die Umsetzung dieses Konzepts gibt es zwei Möglichkeiten: Die textuelle Erstellung des Prozesses per Text- oder XML- Editor, oder die Erstellung mit einem grafischen Modellierungswerkzeug. Da es jedoch um das Erlernen der Konzepte geht und die Umsetzung per XML sehr unübersichtlich und zeitaufwändig ist, werden die Studenten im Praktikum ein Modellierungstool verwenden Kontrolle der Lösungen Der Tutor soll die Möglichkeit haben die Lösungen übersichtlich und schnell prüfen zu können. Ein weiterer Vorteil bei der Verwendung eines Modellierungswerkzeugs ist, dass die Ergebnisse übersichtlich angezeigt und getestet werden können.

7 2. KONZEPT Aufgabenverteilung Da die Aufgabenstellung recht umfangreich ist und das Tutorial über Web Services vorausgesetzt wird, sollte die Aufgabe von mindestens 2 Personen gelöst werden. Dabei könnte eine Person die Entwicklung der Hotelbuchung und deren Einflechtung in den Prozess und die zweite Person die Implementierung der Fehlerbehandlung bzw. Kompensationsaktionen übernehmen Ergebnisse Die Ergebnisse des Tutorials und der Aufgabenstellung sollen sowohl als ausführbare BPEL Datei als auch als komplettes Projekt abgegeben werden. Damit kann durch Prüfung des Codes kontrolliert werden, ob Code von anderen kopiert worden ist. Weiterhin wird von jedem Team eine Dokumentation mit Kritiken zum Praktikum eingereicht. 2.3 Praxiskonzept BPEL Laufzeitumgebung Zur Ausführung eines BPEL Prozesses wird eine BPEL Laufzeitumgebung, auch BPEL Engine genannt, benötigt, die sowohl die Prozesse ausführt, als auch die bereitsgestellten WSDL Dateien verarbeitet. Im folgenden werden einige verglichen, zusammen mit der geprüften Version. Die dargestellten Werte sind das Ergebnis eines Forschungsberichts der Universität Stuttgart [9]. Als wichtigste Punkte für die Verwendung in einem Praktikumsversuch mit Studenten sind die Zuverlässigkeit und die kostenfreie Verfügbarkeit zu nennen. Oracle BPEL Process Manager % BPEL4WS 1.1 konform - <links> werden nicht unterstützt. Die Fehlerbehebung ist sehr gut. Der Fehler kann mittels Prozessgraphen, sowie aussagekräftigen und gut verständlichen Hilfetexten nachvollzogen werden. Der Server ist sehr ressourcenintensiv. Der Preis beträgt Euro pro CPU [5]. ActiveBPEL Engine 2.0: 100% BPEL4WS 1.1 konform Es wird angezeigt ob der Prozess erfolgreich deployed werden konnte, sowie gegebenfalls Fehlermeldungen angegeben, die jedoch teilweise recht unkonkret ausfallen.

8 2. KONZEPT 7 Die deployten Prozesse lassen sich in der Administratorenkonsole anzeigen. Der jeweilige Prozessgraph kann während der Abarbeitung angezeigt werden. Die Engine ist Open Source und somit kostenfrei. Apache Agila - Dezember % BPEL4WS 1.1 konform - Probleme treten mit <throw>, <links>, <compensationhandler> und <scopes> auf. Die Fehlerbehandlung findet über Exception Codes ohne weitere Informationen statt. Open Source Cape Clear Enterprise Service Bus % BPEL4WS 1.1 konform - <flow> und <compensationhandler> werden nicht unterstützt. Mit Hilfe eines Eclipse-Plugin ist es möglich auf die genaue Fehlerquelle zu schließen, jedoch wird die Zeile nicht richtig angegeben. Fehler, die das Eclipse-Plugin nicht kennt, werden mit kryptischen Exceptions angegeben. Die Kosten belaufen sich auf Dollar pro CPU [4] FiveSight Process Execution Engine (PXE) 1.0 RC1 90% BPEL4WS 1.1 konform - <eventhandler> wird nicht unterstützt. Die Fehlerbehandlung erfolgt recht gut, auch wenn Probleme bei der Zeilenangabe und bei langen Fehlermeldungen auftreten. OpenLink Virtuoso Server % BPEL4WS 1.1 konform - Prozesse werden nur unterstützt, wenn diese in der ersten Operation aus <sequence> oder <receive> bestehen. Die Fehlerbehandlung erfolgt leicht kryptisch, aber aussagekräftig unter Angabe der Zeilennummer. Das Deployment erfolgt über die Administratorkonsole mit einer speziellen Upload Seite. Open Source, sowie kommerzielle Version ab 5000 US-Dollar erhältlich. [10] IBM Websphere Studio Application Developer Integration Edition % BPEL4WS 1.1 konform - <compensationhandler> und <eventhandler> werden nicht unterstützt. Weiterhin existieren generell Eigenheiten, die ein Veröffentlichen der Prozesse in anderen Umgebungen erschweren, gleiches gilt anderherum. Die Fehlerbehandlung wird sehr gut unterstützt. Fehler und Probleme werden übersichtlich in einer Liste dargestellt und es kann direkt zur passenden Stelle gesprungen werden. Als reine Laufzeitumgebung aufgrund der Anpassungsprobleme eher weniger geeignet. Weiterhin werden beim Veröffentlichen Kommentare entfernt und Attribute hinzugefügt, die die Lesbarkeit erschweren.

9 2. KONZEPT 8 Eine kurze Übersicht stellt die folgende Abbildung dar : Abb.1: Übersicht über die Endwertungen [9] Aufgrund des Umfangs, der Stabilität und der kostenfreien Nutzungsmöglichkeit fiel die Entscheidung auf die ActiveBPEL Open Source Engine. Die ActiveBPEL Engine läuft in einem Servlet Container z.b. Apache Tomcat. Die Architektur der Engine sieht wie folgt aus: Abb.2: Engine Architecture [1]

10 2. KONZEPT BPEL Modellierungswerkzeuge Außer der Möglichkeit, die BPEL Datei per Texteditor zu erstellen und zu bearbeiten, gibt es noch die wesentlich komfortablere Variante per Modellierungswerkzeug. Ebenso wie die Erstellung der WSDL Dateien unübersichtlich und die Fehlerbehandlung per Texteditor problematisch ist, ist dies auch hier der Fall. BPEL Modellierungswerkzeuge ermöglichene die übersichtliche, graphische Erstellung der Prozesse, sowie deren Prüfung. Das Deployment und die Ausführung der Prozesse kann übersichtlich gesteuert werden. Zusätzlich zur Engine wird von Active Endpoints der ActiveBPEL Designer angeboten, der für die private Nutzung kostenfrei ist. Weiterhin gibt es die Möglichkeiten der automatischen Umsetzung von BPEL4WS 1.1 aus früheren ActiveBPEL Designer Projekten zu WS-BPEL 2.0 und der Simulation der erstellten Prozesse. Die Simulation erfolgt mit Testdaten innerhalb des Designer und gibt, ohne dass der Prozess deployed werden muss, Aufschluss über mögliche Probleme, die Auftreten können Web Services Für die Erstellung einer Reisebuchung werden Web Services für die Buchung von Flug und Auto benötigt. Leider ließen sich die Web Services aus der Praktikumsaufgabe Web Services und verschiedene Client-Applikationen [8] nicht verwenden, da sie zu einfach gehalten waren. Es ist mit diesen nicht möglich, z.b. Start- und Zielort zu bestimmen, oder eine Mietdauer festzulegen. Ein Großteil meiner Arbeit bestand deshalb in der Konzeption und Erstellung von Web Services für die Flug- und Autobuchung. Der Web Service für die Hotelbuchung soll später von den Studenten selbst erstellt werden. Dabei wurde bei der Erstellung nach dem o.g. Tutorial vorgegangen, die Web Services somit in Java erstellt. Der Web Service der Flugbuchung ermöglicht die Buchung eines Fluges über die Angabe von Start- und Zielort, sowie der Anzahl der Personen und dem Datum. Weiterhin können gebuchte Flüge über deren BuchungsID, Angabe des Flugnamen und des Start- und Zielorts storniert werden. Es lassen sich auch alle existierenden Flüge und separat alle Flüge eines Ortes anzeigen. Die Autobuchung stellt Methoden zur Buchung, Stornierung und zum Anzeigen aller existierenden Autos zur Verfügung. Die Buchung erfolgt über die Angabe von Buchungsort, sowie Beginn und Ende der Reise. Die Stornierung über die ID des Autos und der Buchung.

11 3. REALISIERUNG 10 3 Realisierung Die Ergebnisse dieser Arbeit werden auf einer CD zusammengefasst. Sie besteht aus den Dokumenten Technologieübersicht und Praktikumsaufgaben sowie den Anwendungen und dem verwendeten ActiveBPEL Designer. 3.1 Dokumente Technologien Das Dokument Technologieübersicht gibt einen Überblick über die BPEL Spezifikation und beschreibt Aktivitäten, sowie die beteiligten Spezifikationen WSDL und XPath Praktikumsaufgaben Das Dokument Praktikumsaufgaben beinhaltet das Tutorial zur Erstellung eines Reisebuchungsprozesses, sowie die darauf aufbauende Aufgabenstellung. 3.2 Anwendungen Für die Durchführung des Tutorials wurden für die Studenten die Web Services und ein Testclient im Verzeichnis webapps, die benötigten WSDL Dateien im Verzeichnis wsdl, sowie die Testdaten für die Durchführung von Simulationen unter Sample bereitgestellt. Unter webapps befinden sich der Flugbuchung und Autobuchung Web Service und der TestClient für die Reisebuchung. Das Projekt Reisebuchung wurde als Beispiellösung des Tutorials umgesetzt und bildet den Grundstein für die dem Tutorial folgende Aufgabenstellung.

12 3. REALISIERUNG ActiveBPEL Designer Der ActiveBPEL Designer wird in der getesteten Version bereitgestellt.

13 4. ZUSAMMENFASSUNG 12 4 Zusammenfassung In dieser Arbeit wurde das Konzept und die Umsetzung einer Praktikumsaufgabe erstellt, die den Studenten einen praktischen Einstieg in die Erweiterungen bietet, die mit Web Services im Bereich der Komposition möglich sind. Sie bekommen einen Überblick über die Modellierung von Geschäftsprozessen mit WS-BPEL und machen sich durch die praktischen Aufgaben damit vertraut. Die Ziele des Konzepts wurden erreicht und der Praktikumsbetrieb ist somit möglich. Ausblick Als Erweiterungen könnten in Zukunft das dynamische Binden aus einer Auswahl von Web Services, sowie das Binden über Universal Description Discovery and Integration (UDDI) betrachtet werden.

14 Literaturverzeichnis 13 Literaturverzeichnis [1] ACTIVEENDPOINTS: ActiveBPEL. active-bpel-engine-overview.htm, Abruf: 13. Jan [2] BENING, G. AND ZIMMER,A.: SOA erfolgreich nutzen. In: Java mit Integrationsspektrum 3 (2006) [3] CHRISTENSEN, E., CURBERA, F., MEREDITH, G., WEERAWARANA, S.: Web Services Description Language (WSDL) Abruf: 5. Dez [4] COMPUTERWOCHE.DE: Cape Clear. pid=362&pk=2675, Abruf: 19. Mar [5] COMPUTERWOCHE.DE: Oracle BPEL Process Manager de/index.cfm?pid=336&pk=438, Abruf: 19. Mar [6] DOSTAL, W. ; JECKLE, M. ; MELZER, I. ; ZENGLER, B.: Service-orientierte Architekturen mit Web Services. Elsevier GmbH, 2005 [7] GEORGE, T. AND WESTERMAN, G.: Model Driven Architecture in einer service-orientierten Anwendungslandschaft. In: Java mit Integrationsspektrum 1 (2006) [8] HAFERKORN, Andre: Konzeption und Umsetzung einer Praktikumsaufgabe zur Implementierung eines Web Service und verschiedener Client-Applikationen [9] HANTSCHEL ; RUF ; STROTBEK: Vergleich von BPEL Laufzeitumgebungen / Universität Stuttgart Forschungsbericht [10] HEISE.DE: Virtuoso. Abruf: 19. Mar [11] JURIC, Matjaz B.: Business Process Execution Language for Web Services. Packt Publishing Ltd., 2004 [12] OASIS: Web Services Business Process Execution Language Committee Draft. wsbpel-specification-draft-may17.htm, Abruf: 26. Mar. 2007

15 Literaturverzeichnis 14 [13] W3C: XML Path Language (XPath) Version Abruf: 9. Feb. 2007

16 ANHANG A. TECHNOLOGIEÜBERSICHT 15 A Technologieübersicht A.1 Einleitung Zur Umsetzung des SOA Konzeptes ist es nötig das Zusammenwirken der Web Services zu gewährleisten. Um die Vorteile von Web Services wie Interoperabität und Lose Kopplung auch in Geschäftsprozessen nutzen zu können, müssen diese miteinander komponiert und die Aktivitäten und Nachrichten zwischen ihnen definiert werden. Mit der Web Service Definition Language (WSDL) wird das Nachrichtenformat für den Datenaustausch zwischen den Web Services festgelegt. Da sich Geschäftsprozesse aus mehreren Aktionen zusammensetzen, ist es nötig die Ergebnisse der einzelnen Aktionen zu koordinieren. Weiterhin werden die Zustände in dem sich die beteiligten Prozesse befinden benötigt. Da dies mit WSDL nicht möglich ist, sind andere Konzepte zur Komposition von Web Services erforderlich. Komposition unterscheidet sich in 2 Aspekten, zum einen Orchestrierung und zum anderen Choreographie. Orchestrierung beschreibt die Sicht eines einzelnen Prozesses, der beteiligte Prozesse steuert und koordiniert. Die involvierten Web Services wissen nicht, dass sie Teil einer Komposition sind. Lediglich der zentrale Koordinator der Orchestrierung weiss, wie der Prozess den Ablauf der einzelnen Web Services steuert und wie die Web Services miteinander kommunizieren. Choreographie beschreibt hingegen wie mehrere Prozesse miteinander kooperieren. In einer Choreographie wird beschrieben, welcher Web Service welche Aufgabe übernimmt. Sie beschreibt also die Kooperation mehrerer Partner. [6] Orchestrierung hat gegenüber der Choreographie folgende Vorteile: Es ist genau nachvollziehbar wer für die Ausführung des gesamten Geschäftsprozesses verantwortlich ist. Weitere Web Services können hinzugefügt werden, selbst wenn diese nichts über ihre Beteiligung am Geschäftsprozess wissen. Es können Alternativszenarien erstellt werden, falls Fehler auftreten. [11]

17 ANHANG A. TECHNOLOGIEÜBERSICHT 16 A.2 WS-BPEL Die Integration von Web Services in Geschäftsprozesse ist von großer Bedeutung und soll auf einem standardisiertem Weg stattfinden. Die Web Services Business Process Execution Language (WS-BPEL) ist eine solche Sprache zur Komposition und Koordination von Web Services. Sie ermöglicht die Modellierung von Geschäftsprozessen mit standardisierten Sprachkomponenten und basiert auf XML. Im Moment liegt die Version BPEL4WS 1.1 vom Mai 2003 vor. Die Version WS-BPEL 2.0 existiert aktuell als Entwurf vom Mai 2006 und ist Grundlage dieser Arbeit. WS-BPEL verwendet folgende XML-basierte Spezifikationen: WSDL 1.1, XML-Schema 1.0, XPath 1.0. Die WSDL Spezifikation ist hierbei jedoch die wichtigste, da sowohl Prozess als auch die Prozesspartner per WSDL veröffentlicht werden. [12] A.2.1 Aufbau Ein BPEL Prozess besteht aus 4 Hauptbereichen und gegebenfalls aus weiter optionalen Elementen: Der <partnerlinks> Bereich beschreibt, welche Prozesse an dem Geschäftsprozess beteiligt sind. Jeder partnerlink wird durch einen partnerlink type und einen oder zwei Rollennamen charakterisiert. 1 < n s : p a r t n e r L i n k s > 2 < n s : p a r t n e r L i n k myrole=" r e i s b u c h u n g S e r v i c e " name=" reisebuchunglt " 3 p a r t n e r L i n k T y p e =" n s 1 : r e i s e b u c h u n g L T " / > 4 < n s : p a r t n e r L i n k name=" flugbuchunglt " p a r t n e r L i n k T y p e =" ns2:flugbuchunglt " 5 p a r t n e r R o l e =" f l u g b u c h u n g S e r v i c e " / > 6 < / n s : p a r t n e r L i n k s > <variables> defininiert die Datenvariablen, die vom Prozess genutzt werden, in Abhängigkeit von den WSDL Nachrichtentypen, XML Schematypen (simple oder komplex) oder XML Schema Elementen. Damit kann die Konsistenz zwischen den ausgetauschten Nachrichten bewahrt werden. 1 < n s : v a r i a b l e s > 2 < n s : v a r i a b l e messagetype=" n s 1 : r e i s e B u c h e n R e q u e s t " 3 name=" r e i s e B u c h e n R e q u e s t " / > 4 < n s : v a r i a b l e messagetype=" n s 1 : r e i s e B u c h e n R e s p o n s e " 5 name=" r e i s e B u c h e n R e s p o n s e " / > 6 < / n s : v a r i a b l e s >

18 ANHANG A. TECHNOLOGIEÜBERSICHT 17 Der <faulthandlers> Bereich beinhaltet die Aktionen, die ausgeführt werden müssen, falls ein Fehler auftritt. In WS-BPEL ist jeder Fehler, egal ob intern oder als Ergebnis eines Serviceaufrufs durch einen qualifizierten Namen identifizierbar. 1 < n s : f a u l t H a n d l e r s > 2 < n s : c a t c h faultname =" ns1:cancelbuchung "> 3 < n s : c o m p e n s a t e S c o p e name=" CompensateBuchung " t a r g e t =" ScopeBuchung " / > 4 < / n s : c a t c h > 5 < / n s : f a u l t H a n d l e r s > Der Rest der Prozessdefinition beinhaltet die Beschreibung des Verhaltens, falls eine Anfrage eintrifft. Die Hauptelemente dieses Bereiches werden im folgenden genannt.

19 ANHANG A. TECHNOLOGIEÜBERSICHT 18 Im folgenden wird ein Überblick über den groben Aufbau eines BPEL Prozesses geliefert und danach detailliert die einzelnen Teile beschrieben [12]: 1 < p r o c e s s name="ncname" t a r g e t N a m e s p a c e =" anyuri " 2 querylanguage =" anyuri "? 3 e x p r e s s i o n L a n g u a g e =" anyuri "? 4 s u p p r e s s J o i n F a i l u r e =" yes no "? 5 e x i t O n S t a n d a r d F a u l t =" yes no "? 6 xmlns=" h t t p : / / schemas. xmlsoap. org / ws / / 0 3 / b u s i n e s s p r o c e s s / "> 7 < e x t e n s i o n s >? 8 < e x t e n s i o n namespace=" anyuri " mustunderstand =" yes no " / > 9 < / e x t e n s i o n s > 10 < i m p o r t namespace=" anyuri "? l o c a t i o n =" anyuri "? importtype =" anyuri " / > 11 < p a r t n e r L i n k s >? 12 <! N o t e : At l e a s t one r o l e must be s p e c i f i e d. > 13 < p a r t n e r L i n k name="ncname" p a r t n e r L i n k T y p e ="QName" 14 myrole="ncname"? p a r t n e r R o l e ="NCName"?>+ 15 < / p a r t n e r L i n k > 16 < / p a r t n e r L i n k s > 17 < messageexchanges >? 18 < messageexchange name="ncname" / >+ 19 < / messageexchanges > 20 < v a r i a b l e s >? 21 < v a r i a b l e name="ncname" messagetype="qname"? 22 t y p e ="QName"? e l e m e n t ="QName"? / >+ 23 < / v a r i a b l e s > 24 < c o r r e l a t i o n S e t s >? 25 < c o r r e l a t i o n S e t name="ncname" p r o p e r t i e s ="QName l i s t " / >+ 26 < / c o r r e l a t i o n S e t s > 27 < f a u l t H a n d l e r s >? 28 <! N o t e : There must be a t l e a s t one f a u l t H a n d l e r > 29 < c a t c h faultname ="QName"? f a u l t V a r i a b l e ="NCName"? 30 f a u l t M e s s a g e T y p e ="QName"? 31 f a u l t E l e m e n t ="QName"?> 32 a c t i v i t y 33 < / c a t c h > 34 < c a t c h A l l >? 35 a c t i v i t y 36 < / c a t c h A l l > 37 < / f a u l t H a n d l e r s > 38 < e v e n t H a n d l e r s >? 39 <! N o t e : There must be a t l e a s t one onevent or onalarm e v e n t H a n d l e r. > 40 <onevent p a r t n e r L i n k ="NCName" p o r t T y p e ="QName"?

20 ANHANG A. TECHNOLOGIEÜBERSICHT o p e r a t i o n ="NCName" ( messagetype="qname" e l e m e n t ="QName" )? 42 v a r i a b l e ="NCName"? 43 messageexchange ="NCName"? > 44 < c o r r e l a t i o n s >? 45 < c o r r e l a t i o n s e t ="NCName" 46 i n i t i a t e =" yes j o i n no "? / >+ 47 < / c o r r e l a t i o n s > 48 < f r o m P a r t p a r t ="NCName" t o V a r i a b l e ="NCName" / > 49 < scope... >... < / scope > 50 < / onevent > 51 <onalarm> 52 <! N o t e : There must be a t l e a s t one e x p r e s s i o n. > 53 ( < f o r e x p r e s s i o n L a n g u a g e =" anyuri "?> d u r a t i o n expr < / f o r > 54 < u n t i l e x p r e s s i o n L a n g u a g e =" anyuri "?> d e a d l i n e expr < / u n t i l > )? 55 < r e p e a t E v e r y e x p r e s s i o n L a n g u a g e =" anyuri "?> 56 d u r a t i o n expr 57 < / r e p e a t E v e r y >? 58 < scope... >... < / scope > 59 < / onalarm> 60 < / e v e n t H a n d l e r s > 61 a c t i v i t y 62 < / p r o c e s s > Dabei gibt es folgende Top-Level Attribute: querylanguage - Dieses Attribut bestimmt mit welcher Anfragesprache auf Knoten innerhalb von Zuweisungen, Variablen, etc. zugegriffen wird. Standard ist die Verwendung von XPath 1.0 mit dem Standardwert: urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0. expressionlanguage - Legt fest welche Ausdruckssprache verwendet werden soll. Standardmäßig ist dies ebenso XPath 1.0 suppressjoinfailure - Dieses Attribut legt fest, ob bei einem joinfailure die Fehlermeldung unterdrückt werden soll oder nicht. Fehler bei der Zusammenführung zweier Ausführungszweige führen zu einer solchen Fehlermeldung. Standardmäßig ist der Wert no. exitonstandardfault - Falls der Wert auf yes gesetzt wird, muss der Prozess beim Auftreten eines WS-BPEL Standardfehlers (außer dem joinfailure) umgehend verlassen werden. Wenn der Wert no ist, kann der Prozess Standardfehler mit einem faulthandler behandeln. Der Standardwert hierfür ist no.

21 ANHANG A. TECHNOLOGIEÜBERSICHT 20 A.2.2 Data Handling In BPEL Prozessen werden zustandsbehaftete Interaktionen spezifiziert, inklusive den Austausch von Nachrichten zwischen den Partnern. Der Zustand eines Prozesses beinhaltet sowohl die Nachrichten die ausgetauscht wurden als auch Daten, die in der Geschäftslogik verwendet und in Nachrichten an Partner gesendet wurden. A Variablen Die Verwaltung der Zustandes der Prozesse erfordert die Verwendung von Variablen. WS-BPEL unterstützt drei Varianten für Variablendeklarationen: WSDL message type, XML Schema type (simple oder complex) und XML Schema element und werden im Element <variables> gehalten. Die Bezeichner der Variablen müssen innerhalb eines Gültigkeitsbereiches eindeutig sein. Weiterhin verdecken lokale die globalen Variablen. Wertzuweisungen werden über die <assign> Aktivität (siehe Aktivitäten) geregelt. A Funktionen WS-BPEL bietet Erweiterungsmöglichkeiten für Anfragen und Ausdrücke. Die Sprache wird festgelegt durch die Attribute querylanguage und expressionlanguage des <process> Elements. XPath 1.0 wird hier als Standardwert mit urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0 vorgegeben. Hiermit lassen sich Teile komplexer Variablen anfragen, sowie Ausdrücke formulieren auf deren Basis Bedingungen bestimmt werden können. WS-BPEL verwendet verschiedene Typen von Ausdrücken: Boolean expressions: Ausdrücke mit Wahrheitswerten, wie transition, join, while und if - Bedingungen. Deadline expressions: Ausdrücke mit Fristen, wie until Ausdrücke von onalarm und wait. Duration expressions: Ausdrücke mit Zeiträumen, für Ausdrücke von onalarm und wait. Unsigned Integer expressions: Ausdrücke mit vorzeichenlosen Integer Werten, wie startcounter- Value, finalcountervalue und Zweige in foreach. General expressions: Allgemeine Ausdrücke, wie assign.

22 ANHANG A. TECHNOLOGIEÜBERSICHT 21 A.2.3 Aktivitäten Die Prozesslogik wird in BPEL über Aktivitäten geregelt. Diese sind in 2 Gruppen aufgeteilt, den Basisaktivitäten und den strukturierten Aktivitäten. Erstere beschreiben die elementaren Schritte der Prozessabfolge, während die strukturierten Aktivitäten für die Kontrollflusslogik zuständig sind. A Standardelemente Jede Aktivität hat zwei optionale Standardattribute: einen eindeutigen Namen <name> und ein Attribut <suppressjoinfailure> zur Unterdrückung der Fehlermeldung beim Zusammenführen zweier Ausführungszweige. Die beiden optionalen Standardelemente <sources> und <targets>, die wiederum aus <source> und <target> Elementen bestehen, existieren zur Erstellung von Relationen für die Aktivitäten. A Basisaktivitäten Die <invoke> Aktivität dient der Kommunikation mit Web Services über deren porttype. Die teilhabenden Web Services werden über die PartnerLinks angegeben. Eine typische Nutzung ist hierbei der Aufruf einer Operation eines Web Services. Ein solcher <invoke> Aufruf kann weitere Aktivitäten beinhalten, wie z.b. Fault Handler oder Compensation Handler. Für Operationen gibt es zwei Aufrufvarianten: request-response oder one-way. Der One- Way-Aufruf benötigt lediglich die <inputvariable>, Request-Response hingegen die inputvariable und die outputvariable. Der Aufruf kann folgendermaßen aussehen: 1 < b p e l : i n v o k e i n p u t V a r i a b l e =" s t o r n i e r e F l u g R e q u e s t " name=" s t o r n i e r e R u e c k f l u g " 2 o p e r a t i o n =" s t o r n i e r e F l u g " o u t p u t V a r i a b l e =" s t o r n i e r e F l u g R e s p o n s e " 3 p a r t n e r L i n k =" FlugbuchungLT " p o r t T y p e =" ns:flugbuchung "> Weiterhin kann die <invoke> Aktivität mit einem <compensationhandler> verknüpft werden, der z.b. Aktionen beim Auftreten von Fehlern rückgängig macht bzw. die Aktionen kompensiert. Dieser kann explizit mit <invoke> aufgerufen werden oder als Standard <compensationhandler> dem <invoke> Aufruf hinzugefügt werden. Die <receive> Aktivität erlaubt dem Prozess auf eintreffende Nachrichten zu warten. Die <receive> Aktivität ist erfolgreich, wenn eine Nachricht eingeht. Das porttype Attribut der <receive> Aktivität ist optional. Das optionale messageexchange Attribut wird verwendet um

23 ANHANG A. TECHNOLOGIEÜBERSICHT 22 der <receive> Aktivität eine <reply> Aktivität zuzuordnen. Mit createinstance wird festgelegt, ob beim Eintreffen einer Nachricht eine Instanz des Prozesses erzeugt werden soll oder nicht. 1 < n s : r e c e i v e c r e a t e I n s t a n c e =" yes " name=" ReceiveReisebuchung " 2 o p e r a t i o n =" r e i s e B u c h e n " p a r t n e r L i n k =" reisebuchunglt " 3 p o r t T y p e =" ns1:reisebuchung " v a r i a b l e =" r e i s e B u c h e n R e q u e s t "> 4 < n s : s o u r c e s > 5 < n s : s o u r c e linkname="l1 " / > 6 < / n s : s o u r c e s > 7 < / n s : r e c e i v e > Die <reply> Aktivität erlaubt es dem Prozess auf eintreffende Nachrichten zu reagieren und eine Antwortnachricht zu senden. Die Antwort kann auf <receive>, <onmessage> oder <onevent> erfolgen und bildet eine request-response Operation an einen WSDL porttype für diesen Prozess. 1 < n s : r e p l y name=" ReplyReisebuchung " o p e r a t i o n =" r e i s e B u c h e n " 2 p a r t n e r L i n k =" reisebuchunglt " p o r t T y p e =" ns1:reisebuchung " 3 v a r i a b l e =" r e i s e B u c h e n R e s p o n s e "> 4 < n s : t a r g e t s > 5 < n s : t a r g e t linkname="l2 " / > 6 < / n s : t a r g e t s > 7 < / n s : r e p l y > Mit <assign> werden Werte von Variablen überschrieben. Ein <assign> Konstrukt kann eine beliebige Anzahl elementarer Zuweisungen enthalten, wie z.b. <copy>. Es lassen sich über Ausdrücke Daten aus einer Variablen in eine andere kopieren, sowie umstrukturieren. Ausdrücke können auf Variablen, Eigenschaften und literal constants angewendet werden. Die <assign> Aktivität kann auch verwendet werden, um endpoint references nach und von partnerlinks zu kopieren. 1 < n s : a s s i g n name=" AssignReiseBuchungResponse "> 2 < n s : c o p y > 3 < n s : f r o m > f a l s e ( ) < / n s : f r o m > 4 < n s : t o p a r t =" p a r a m e t e r s " v a r i a b l e =" r e i s e B u c h e n R e s p o n s e "> 5 < n s : q u e r y >ReiseBuchungResponse / buchungok< / n s : q u e r y > 6 < / n s : t o > 7 < / n s : c o p y > 8 < / n s : a s s i g n > In der Spezifikation ist die <assign> Aktivität wie folgt angegeben:

24 ANHANG A. TECHNOLOGIEÜBERSICHT 23 1 < a s s i g n v a l i d a t e =" yes no "? s t a n d a r d a t t r i b u t e s > 2 s t a n d a r d e l e m e n t s 3 ( <copy keepsrcelementname=" yes no "?> 4 from spec 5 to spec 6 < / copy> 7 < e x t e n s i b l e A s s i g n > 8... a s s i g n element of o t h e r namespace... 9 < / e x t e n s i b l e A s s i g n > ) + 10 < / a s s i g n > Hierbei muss der <from> Teil eine der folgenden Strukturen haben: 1 <from v a r i a b l e ="NCName" p a r t ="NCName"? / > 2 <from p a r t n e r L i n k ="NCName" e n d p o i n t R e f e r e n c e =" myrole p a r t n e r R o l e " / > 3 <from v a r i a b l e ="NCName" p r o p e r t y ="QName" / > 4 <from e x p r e s s i o n L a n g u a g e =" anyuri "?> e x p r e s s i o n < / from> 5 <from>< l i t e r a l > l i t e r a l v a l u e < / l i t e r a l >< / from> Und für den <to> Teil: 1 < t o v a r i a b l e ="NCName" p a r t ="NCName"? / > 2 < t o p a r t n e r L i n k ="NCName" / > 3 < t o v a r i a b l e ="NCName" p r o p e r t y ="QName" / > 4 < t o querylanguage =" anyuri "?> query < / t o > Das optionale keepsrcelementname Attribut von <copy> wird verwendet um den Elementnamen des Ziels mit dem der Quelle zu ersetzen. Mit dem optionalen validate Attribut können in einer <assign> Aktivität die geänderten Variablenwerte validiert werden. <validate> validiert die Werte von Variablen gegen ihre verknüpfte XML oder WSDL Datendefinition. <throw> wird verwendet um einen Fehler innerhalb des Prozesses zu generieren. In folgenden Beispiel werfen die Links L6 und L5 einen Fehler mit dem Namen CancelBuchung : 1 < n s : t h r o w faultname =" ns1:cancelbuchung " name=" CancelBuchung "> 2 < n s : t a r g e t s > 3 < n s : t a r g e t linkname="l6 " / > 4 < n s : t a r g e t linkname="l5 " / > 5 < / n s : t a r g e t s > 6 < / n s : t h r o w >

25 ANHANG A. TECHNOLOGIEÜBERSICHT 24 Mit <wait> wird eine bestimmte Zeit <for> oder bis zu einer bestimmten Zeit <until> gewartet. <empty> ist quasi eine leere Aktion. Diese kann z.b. zur Synchronisation von Aktivitäten verwendet werden. <scope> definiert eine geschlossene Aktivität mit ihren eigenen verknüpften partnerlinks, messageexchanges, variables, correlationsets, faulthandlers, compensationhandler, terminationhandler und eventhandlers. 1 < scope i s o l a t e d =" yes no "? e x i t O n S t a n d a r d F a u l t =" yes no "? 2 s t a n d a r d a t t r i b u t e s > 3 s t a n d a r d e l e m e n t s 4 < p a r t n e r L i n k s >?< / p a r t n e r L i n k s > 5 < messageexchanges >? < / messageexchanges > 6 < v a r i a b l e s >?< / v a r i a b l e s > 7 < c o r r e l a t i o n S e t s >?< / c o r r e l a t i o n S e t s > 8 < f a u l t H a n d l e r s >?< / f a u l t H a n d l e r s > 9 < c o m p e n s a t i o n H a n d l e r >?< / c o m p e n s a t i o n H a n d l e r > 10 < t e r m i n a t i o n H a n d l e r >?< / t e r m i n a t i o n H a n d l e r > 11 < e v e n t H a n d l e r s >?< / e v e n t H a n d l e r s > 12 a c t i v i t y 13 < / scope > <compensatescope> beinhaltet Informationen zur Durchführung einer Kompensation eines bestimmten <scope>, der schon abgeschlossen wurde. Diese Aktivität darf nur innerhalb eines faulthandler, eines anderen compensationhandler oder einem terminationhandler verwendet werden. <compensate> wird zur Kompensation aller beteiligten Scopes verwendet, die bereits ausgeführt wurden. Diese Aktivität darf ebenso nur innerhalb eines faulthandler, eines anderen compensationhandler oder einem terminationhandler verwendet werden. <exit> beendet die Prozessinstanz umgehend. <rethrow> wird verwendet um einen Fehler der eigentlich von einem faulthandler abgefangen worden ist, erneut zu werfen. Diese Aktivität darf nur im faulthandler verwendet werden. <extensionactivity> ist zur Erweiterung von WS-BPEL mit einem neuen Aktivitätstyp vorgesehen. Der Inhalt muss ein einzelnes Element sein, welches die WS-BPEL Standardelemente und Standardattribute enthält.

26 ANHANG A. TECHNOLOGIEÜBERSICHT 25 A Strukurierte Aktivitäten <sequence> wird verwendet um eine Sammlung von Aktivitäten in einer sequentiellen Reihenfolge auszuführen. 1 < s e q u e n c e s t a n d a r d a t t r i b u t e s > 2 s t a n d a r d e l e m e n t s 3 a c t i v i t y + 4 < / s e q u e n c e > Mit der <if> Aktivität wird exakt eine Aktivität aus den Möglichkeiten ausgeführt. 1 < n s : i f > 2 < n s : c o n d i t i o n e x p r e s s i o n L a n g u a g e = 3 " u r n : o a s i s : n a m e s : t c : w s b p e l : 2. 0 : s u b l a n g : x p a t h 1. 0 "> 4 b o o l e a n ($ bucheflugresponse. 5 bucheflugresponse / BucheFlugResponse / buchungsid &g t ; 0 ) 6 < / n s : c o n d i t i o n > 7 < n s : a s s i g n name=" AssignFlugResp "> 8 < n s : c o p y > 9 < n s : f r o m p a r t =" bucheflugresponse " v a r i a b l e =" bucheflugresponse "> 10 < n s : q u e r y >BucheFlugResponse / s t a r t Z e i t < / n s : q u e r y > 11 < / n s : f r o m > 12 < n s : t o p a r t =" p a r a m e t e r s " v a r i a b l e =" r e i s e B u c h e n R e s p o n s e "> 13 < n s : q u e r y >ReiseBuchungResponse / r e i s e B e g i n n < / n s : q u e r y > 14 < / n s : t o > 15 < / n s : a s s i g n > 16 < e l s e i f > < / e l s e i f > 19 < e l s e > < / e l s e > 22 < / i f > <while> führt zur Wiederholung von Aktivitäten, bis die angegebene Bedingung true ist. 1 < w h i l e s t a n d a r d a t t r i b u t e s > 2 s t a n d a r d e l e m e n t s 3 < c o n d i t i o n e x p r e s s i o n L a n g u a g e =" anyuri "?> 4... bool expr... 5 < / c o n d i t i o n > 6 a c t i v i t y 7 < / w h i l e >

27 ANHANG A. TECHNOLOGIEÜBERSICHT 26 <repeatuntil> wiederholt die angegebenen Aktivitäten, bis die Bedingung erfüllt ist. Der Test der Bedingung erfolgt nach Ausführung der Aktivitäten, die somit mindestens ein Mal ausgeführt wird. 1 < r e p e a t U n t i l s t a n d a r d a t t r i b u t e s > 2 s t a n d a r d e l e m e n t s 3 a c t i v i t y 4 < c o n d i t i o n e x p r e s s i o n L a n g u a g e =" anyuri "?> 5... bool expr... 6 < / c o n d i t i o n > 7 < / r e p e a t U n t i l > <foreach> erhöht den Wert bei jeder Ausführung um 1, wobei <finalcountervalue> der Endwert und <startcountervalue> der Anfangswert ist. Mit dem parallel Attribute kann festgelegt werden, dass alle Ausführungen gleichzeitig stattfinden können. Mit <completecondition> ist es möglich die Ausführung bei Erfüllung der Bedingung eher abzubrechen. 1 < f o r E a c h countername="ncname" p a r a l l e l =" yes no " s t a n d a r d a t t r i b u t e s > 2 s t a n d a r d e l e m e n t s 3 < s t a r t C o u n t e r V a l u e e x p r e s s i o n L a n g u a g e =" anyuri "> 4 unsigned i n t e g e r e x p r e s s i o n 5 < / s t a r t C o u n t e r V a l u e > 6 < f i n a l C o u n t e r V a l u e e x p r e s s i o n L a n g u a g e =" anyuri "> 7 unsigned i n t e g e r e x p r e s s i o n 8 < / f i n a l C o u n t e r V a l u e > 9 < c o m p l e t i o n C o n d i t i o n >? 10 < b r a n c h e s e x p r e s s i o n L a n g u a g e =" anyuri "? 11 countcompletedbranchesonly =" yes no "?> 12 unsigned i n t e g e r e x p r e s s i o n 13 < / b r a n c h e s > 14 < / c o m p l e t i o n C o n d i t i o n > 15 < scope... >... < / scope > 16 < / f o r E a c h >

28 ANHANG A. TECHNOLOGIEÜBERSICHT 27 Die <pick> Aktivität wird verwendet um auf eine von mehreren möglichen Nachrichten zu warten, oder bis eine vorgegebene Zeit abläuft. Wenn eine der erwarteten Nachrichten eintrifft, wird der zugehörige Teil ausgeführt und <pick> Aktivität abgeschlossen. 1 < p i c k c r e a t e I n s t a n c e =" yes no "? s t a n d a r d a t t r i b u t e s > 2 s t a n d a r d e l e m e n t s 3 <onmessage p a r t n e r L i n k ="NCName" p o r t T y p e ="QName"? 4 o p e r a t i o n ="NCName" v a r i a b l e ="NCName"? 5 messageexchange ="NCName"? >+ 6 < c o r r e l a t i o n s >? 7 < c o r r e l a t i o n s e t ="NCName" i n i t i a t e =" yes j o i n no "? / >+ 8 < / c o r r e l a t i o n s > 9 < f r o m P a r t p a r t ="NCName" t o V a r i a b l e ="NCName" / > 10 a c t i v i t y 11 < / onmessage> 12 <onalarm> 13 ( < f o r e x p r e s s i o n L a n g u a g e =" anyuri "?> d u r a t i o n expr < / f o r > 14 < u n t i l e x p r e s s i o n L a n g u a g e =" anyuri "?> d e a d l i n e expr < / u n t i l > ) 15 a c t i v i t y 16 < / onalarm> 17 < / p i c k > Mit <flow> können eine oder mehrere Aktivitäten gleichzeitig ausgeführt werden. <links> können innerhalb eines <flow> verwendet werden, um explizit Kontrollabhängigkeiten zwischen geschachtelten Unteraktivitäten zu regeln. 1 < flow s t a n d a r d a t t r i b u t e s > 2 s t a n d a r d e l e m e n t s 3 < l i n k s >? 4 < l i n k name="ncname" / >+ 5 < / l i n k s > 6 a c t i v i t y + 7 < / flow > A.2.4 Linksemantik Links ermöglichen die Verknüfungen einzelner Aktivitäten untereinander. Die Verknüpfung verläuft vom Element source zum Element target und hat einen linkname. Für die Übersichtlichkeit ist jedoch die Verwendung von sequences und flows zu bevorzugen und nur in Ausnahmefällen auf link zurückzugreifen.

29 ANHANG A. TECHNOLOGIEÜBERSICHT 28 A.2.5 Partnerdefinitionen Zur Festlegung von Partnerbeziehungen wird im BPEL Dokument auf die abstrakte Schnittstellenbeschreibung der WSDL Datei des Web Services referenziert. Da das konkrete Binding nicht Bestandteil der BPEL Spezifikation ist und auch in der WSDL Spezifikation keine Beschreibung von Prozessaspekten vorsieht, muss abhängig von der Laufzeitumgebung eine Deploymentdatei erstellt werden. Die Partner des BPEL Prozesses werden mit dem partnerlinks Element definiert. Dabei können die Partner mehrere Rollen haben, die je nach Zweck aufgerufen werden können. Dazu muss für das Element partnerlink eines der beiden Attribute myrole und partnerrole angegeben werden. Werden beide Attribute verwendet handelt es sich um eine synchrone Kommunikation. Wird nur myrole angegeben handelt es sich um einen request. Die Angabe des konkreten Web Services erfolgt über das Attribut partnerlinktype, welches auf einen Kommunikationstypen im WSDL Dokument verweist. Der Kommunikationsweg erfolgt über den von WSDL bekannten porttype. In der BPEL Datei sieht die Partnerdefinition also beispielweise wie folgt aus: 1 < n s : p a r t n e r L i n k s > 2 < n s : p a r t n e r L i n k myrole=" r e i s e b u c h u n g S e r v i c e " name=" reisebuchunglt " 3 p a r t n e r L i n k T y p e =" n s 1 : r e i s e b u c h u n g L T " / > 4 < n s : p a r t n e r L i n k name=" flugbuchunglt " p a r t n e r L i n k T y p e =" ns2:flugbuchunglt " 5 p a r t n e r R o l e =" f l u g b u c h u n g S e r v i c e " / > 6 < n s : p a r t n e r L i n k name=" autobuchunglt " p a r t n e r L i n k T y p e =" ns3:autobuchunglt " 7 p a r t n e r R o l e =" a u t o b u c h u n g S e r v i c e " / > 8 < / n s : p a r t n e r L i n k s > Für den Partner Web Service muss nun noch der Einstiegspunkt innerhalb der WSDL Datei deklariert werden. Dies erfolgt über das Element <partnerlinktype>, welcher einen Container für alle Kommmunikationstypen zwischen den Partnern darstellt. Es können in einem <partnerlinktype> also mehrere Rollen festgelegt werden. Der als Attribut angegebene porttype verweist wie üblich auf den porttype des Web Service. Zum Beispiel passend zum o.g. BPEL Prozess: 1 < p l n k : p a r t n e r L i n k T y p e 2 x m l n s : p l n k =" h t t p : / / schemas. xmlsoap. org / ws / / 0 5 / p a r t n e r l i n k / " 3 name=" flugbuchunglt " > 4 < p l n k : r o l e name=" f l u g b u c h u n g S e r v i c e "> 5 < p l n k : p o r t T y p e name=" t n s : F l u g B u c h u n g " / > 6 < / p l n k : r o l e > 7 < / p l n k : p a r t n e r L i n k T y p e > < w s d l : p o r t T y p e name=" FlugBuchung ">

30 ANHANG A. TECHNOLOGIEÜBERSICHT < w s d l : o p e r a t i o n name=" a l l e F l u e g e A n z e i g e n "> 11 < w s d l : i n p u t message=" t n s : a l l e F l u e g e A n z e i g e n R e q u e s t " / > 12 < w s d l : o u t p u t message=" t n s : a l l e F l u e g e A n z e i g e n R e s p o n s e " / > 13 < / w s d l : o p e r a t i o n > < / w s d l : p o r t T y p e > A.3 WSDL 1.1 Die Web Service Description Language existiert aktuell in der Version 1.1 von 2001, die Version 2.0 befindet sich noch in der Bearbeitung. Die Servicespezifikation enthält 6 wesentliche Elemente: types, message, porttype, binding, port und service [3]. Description ist das Wurzelelement. In welcher Reihenfolge die weiteren Elemente auftreten spielt keine Rolle. Types enthält Datentypendefinitionen der Nachrichten, die der Service sendet und empfängt. Es wird die Verwendung von XML-Schema zur Beschreibung empfohlen. Messages bestehen aus einem oder mehreren logischen parts, die je eine Referenz zu einer XSD Typdefinition haben. PortTypes sind eine Sammlung von abstrakten Operationen. Es gibt 4 Varianten die unterstützt werden: One-way - Der endpoint, diejenige Instanz, die den Request entgegennimmt und den Service zur Verfügung stellt, empfängt eine Nachricht, Request-Response - Der endpoint empfängt eine Nachricht und sendet eine Antwort, Solicit-Response - Der endpoint sendet eine Nachricht und empfängt eine Antwort, und Notification - Der endpoint sendet eine Nachricht. Binding definiert das Nachrichtenformat und Protokolldetails für Operationen und Nachrichten eines bestimmten PortTypes aus technischer Sicht. Es werden Nachrichten- und Transportprotokoll angegeben (z.b. SOAP, HTTP und MIME). Port spezifiziert einen endpoint mit einer einzelnen Adresse. Service gruppiert mehrere ports zusammen.

31 ANHANG A. TECHNOLOGIEÜBERSICHT 30 A.4 XPath 1.0 XML Path Language (XPath) ist eine Anfragesprache zur Adressierung von Teilen eines XML Dokuments, sowie Hilfsmittel zur Manipulation von Zeichenketten, Zahlen und booleschen Werten. XPath wird kann innerhalb des BPEL Prozesses verwendet werden um auf Teile einer komplexen Variablen zuzugreifen, sowie zur Bestimmung von Bedingungen. XPath 1.0 wurde 1999 vom W3C verabschiedet. Der Nachfolger XPath 2.0 liegt als Release Candidate vor. XPath verwendet eine kompakte Nicht-XML-Syntax, mit der die Verwendung von XPath Ausdrücken innerhalb von URIs und XML-Attributen ermöglicht wird. XPath modelliert ein XML Dokument als einen Baum, wobei ein Knoten im Baum je einem Objekt im XML Dokument zugeordnet wird. Es gibt Element-, Attribut- und Textknoten. XPath unterstützt XML Namensräume vollständig. Der Name eines Knotens wird somit als ein Paar aus einem lokalen Bestandteil und einem ggf. leeren Namenraum modelliert. Die XML Deklaration, sowie die Dokumenttypdeklaration lassen sich in der Baumdarstellung nicht wieder auffinden, auch kann man auf diese nicht mit XPath zugreifen. Alle anderen Bestandteile: Wurzeln, Elemente, Textinhalt, Attribute, Namensräume, Kommentare, Process Instructions werden durch entsprechende Knoten des Baumes repräsentiert. XPath kennt 4 Datentypen: node-set, string, boolean, number. Auf diesen Typen basierend können jedoch weitere Typen definiert werden. Die Syntax besteht aus mehreren Teilen. Als erstes wird mittel Lokalisierungspfad auf den Knoten zugegriffen. Dafür können einer oder mehrere Lokalisierungsschritte durchgeführt werden. Ein Lokalisierungsschritt setzt sich aus drei Teilen zusammen: der Achse, dem Knotentest und dem Prädikat, mit dem die Auswahl verfeinert wird. Die Achse kann u.a. self (der Knoten selbst), ancestor (alle direkten Vorfahren des Knotens), preceding (alle Elemente, die vor dem Knoten existieren), following (alle Elemente, die in der Reihenfolge im XML Dokument nach dem Knoten kommen), sowie descendant (alle Nachfolger des Knotens). Ein Knotentest wählt auf einer bestimmten Achse eine Menge von Knoten aus. Der Knotentest ist erfolgreich, wenn der angegebene Name gleich ist oder zwei Knoten übereinstimmen. Weiterhin existieren u.a. noch folgende Möglichkeiten * wählt alle Kindelemente des Kontextknotens aus. text() wählt alle Textknoten aus comment() wählt alle Kommentarknoten aus processing-instructions() wählt alle Prozessanweisungen aus. Mit den Prädikaten ist eine Verfeinerung der Auswahl möglich. Prädikate werden in eckigen Klammern angegeben und enthalten einen logischen Ausdruck, der zu einem booleschen Wert ausgewertet wird.

32 ANHANG A. TECHNOLOGIEÜBERSICHT 31 Ausnahme ist die Angabe einer Position in einer eckigen Klammer. Prädikate können auch Relationszeichen, sowie Funktionen enthalten. Ein Lokalisierungsschritt hat die folgende Syntax: <Achse>::<Knotentest>;[<Prädikat>] Beispiel: 1 / / c h i l d : : B u c h [ c o u n t (. / S e i t e ) < =100][ c o u n t (. / S e i t e ) >=10] oder 2 / / Buch [ c o u n t ( S e i t e ) <=100 and c o u n t ( S e i t e ) > = 1 0 ] ) [13] Die XPath Ausdrücke können mit dem ActiveBPEL Designer teilweise automatisch generiert werden, so dass der Zugriff auf die einzelnen Parameter der Variablen wesentlich übersichtlicher abläuft.

33 ANHANG B. PRAKTIKUMSAUFGABEN 32 B Praktikumsaufgaben B.1 Tutorial B.1.1 Einleitung Mit Hilfe dieser Anleitung soll ein vertiefter Einblick in das SOA Konzept durch die Komposition von Web Services mit BPEL ermöglicht werden. Aufbauen soll dies auf der Praktikumsaufgabe Implementierung eines Web Services und verschiedener Client Applikationen. Als Erweiterung sollen nun ein BPEL Prozess nach Anleitung erstellt und gestartet werden. Ein BPEL Prozess dient der Komposition von Web Services, so dass ein Mehrwert entsteht. Bei unserem BPEL Prozess handelt es sich um die Buchung einer Reise, welche aus einem Hinflug, einem Rückflug und der Buchung eines Autos besteht. Der BPEL Prozess greift dabei über die WSDL Dateien der Web Services auf diese zu und stellt selbst eine WSDL Schnittstellenbeschreibung zur Verfügung. Sowohl die WSDL Datei der Reisebuchung als auch die beiden Web Services zu Buchung von Flug und Auto werden bereitgestellt. Der nach der Anleitung erstellte Prozess soll in der Aufgabenstellung um die Buchung eines Hotels und die Implementierung des Verhaltens im Falle eines Fehlers erweitert werden. Zur Ausführung eines BPEL Prozesses wird ein BPEL Laufzeitumgebung benötigt, auch BPEL Engine genannt, die sowohl die Prozesse ausführt, als auch die bereitsgestellten WSDL Dateien verarbeitet. Aufgrund des Umfangs, der Stabilität und der kostenfreien Nutzungsmöglichkeit fiel die Entscheidung auf die ActiveBPEL Open Source Engine. Die ActiveBPEL Engine läuft in einem Servlet Container z.b. Apache Tomcat. Außer der Möglichkeit, die BPEL Datei per Texteditor zu erstellen und zu bearbeiten, gibt es noch die wesentlich komfortablere Variante per Modellierungswerkzeug. Ebenso wie die Erstellung der WSDL Dateien unübersichtlich und die Fehlerbehandlung per Texteditor problematisch ist, ist dies auch hier der Fall. BPEL Modellierungswerkzeuge ermöglichene die übersichtliche, graphische Erstellung der Prozesse, sowie deren Prüfung. Das Deployment und die Ausführung der Prozesse kann übersichtlich gesteuert