Analyse und Vergleich von Ansätzen zur Einbindung von menschlichen Interaktionen in komplexe Web Services

Transkript

1 Analyse und Vergleich von Ansätzen zur Einbindung von menschlichen Interaktionen in komplexe Web Services Diplomarbeit an der Technischen Universität Dresden Juni 2006 Nicolás Bleyh Betreuer: Dr.-Ing. Iris Braun Hochschullehrer: Prof. Dr. rer. nat. habil Dr. h. c. Alexander Schill Lehrstuhl Rechnernetze Institut für Systemarchitektur Fakultät Informatik

2

3 Erklärung Hiermit erkläre ich, Herr Nicolás Bleyh, die vorliegende Diplomarbeit zum Thema Analyse und Vergleich von Ansätzen zur Einbindung von menschlichen Interaktionen in komplexe Web Services selbständig und ausschließlich unter Verwendung der im Quellenverzeichnis aufgeführten Literatur- und sonstigen Informationsquellen verfasst zu haben. Dresden, am Unterschrift (Nicolás Bleyh)

4

5 Inhaltsverzeichnis Inhaltsverzeichnis 1 Einleitung Grundlagen Web Services Grundlagen Standards XML SOAP WSDL UDDI Einsatzgebiete Bewertung Komplexe Web Services Workflow-Management Komposition Choreographie Behavioral Interface Orchestration Szenarien für Benutzerinteraktionen Ziel-orientierte Nutzerinteraktion Task-orientierte Nutzerinteraktion Fazit Existierende Lösungen Kompositionssprachen WSCI WS-CDL BPEL Vergleich und Bewertung Generische Benutzerschnittstellenbeschreibung XForms Generierung auf Grundlage von WSDL Generierung auf Grundlage von WSDL und User Interface Markup Web Services for Remote Portlets (WSRP) Benutzerinteraktion in komplexen Web Services BPEL4PEOPLE Integration von Benutzerinteraktionen über Tasks Bewertung Konzept Kompositionsbeschreibung Choreographieansatz Orchestrationsansatz Darstellung Statische Generierung Dynamische Generierung Fehlermeldungen Architektur Komposition der Dienste Interaktionskomponente Ablaufsteuerungskomponente Copyright TU Dresden, Nicolás Bleyh i

6 Inhaltsverzeichnis Darstellungskomponente Beispielhafter Programmablauf Autorenprozess Zusammenfassung Implementierung Orchestration der Dienste Implementierung elementarer Web Services BPEL-Erstellung BPEL Ausführung Implementierung von GUI4CWS Ablaufsteuerung Darstellung Interaktion Anwendung auf das Szenario einer Reisebuchung Mögliche Verbesserungen des Prototyps Zusammenfassung und Ausblick Glossar Literaturverzeichnis Anhang Klassendiagramm von GUI4CWS Dokumente für das Reisebuchungsszenario Inhalt der CD Copyright TU Dresden, Nicolás Bleyh ii

7 Abbildungsverzeichnis Abbildungsverzeichnis Abbildung 1: Beispiel für die bisherige Vorgehensweise bei Nutzerinteraktionen mit mehreren Diensten [1]... 2 Abbildung 2: Service-orientierte Architektur (SOA)... 4 Abbildung 3: schematische Repräsentation einer SOAP-Nachricht [10]... 6 Abbildung 4: schematischer Aufbau einer WSDL-Datei... 9 Abbildung 5: Abstrakte Sichten und Datenstrukturen von UDDI [13] Abbildung 6: Web Service Stack [16] Abbildung 7: Choreographie Abbildung 8: Orchestration Abbildung 9: Aktivitätsdiagramm für eine Reisebuchung Abbildung 10: Szenario bei Verwendung eines Behavioral Interfaces Abbildung 11: Szenario bei Verwendung einer Choreographie Abbildung 12: Szenario für eine Orchestration Abbildung 13: Web Service Choreography Interface [27] Abbildung 14: Hauptelement von BPEL Abbildung 15: Task-orientierte Benutzerinteraktion beim Oracle BPEL Process Manager [62] Abbildung 16: Übliche Vorgehensweise bei der Interaktion eines Benutzers mit einem komplexen Web Service Abbildung 17: Architektur des Choreographieansatzes Abbildung 18: Beispiel für den Choreographieansatz Abbildung 19: Orchestrationsansatz mit einer abstrakten BPEL-Prozessbeschreibung als Behavioral Interface Abbildung 20: Transformationsweg von WSDL zu einer geräteunabhängigen Benutzeroberfläche Abbildung 21: Darstellung von Vorlagewerten Abbildung 22: Gesamtarchitektur Abbildung 23: Von GUI4CWS verwendete Dokumente Abbildung 24: Realisierte SOA Abbildung 25: Reiseangebote suchen (Screenshot) Abbildung 26: Sequenzdiagramm für einen Operationsaufruf mit GUI4CWS Abbildung 27: Reise buchen (Screenshot) Abbildung 28: Ergebnis der Reisebuchung (Screenshot) Abbildung 29: UML Klassendiagramm von GUI4CWS Copyright TU Dresden, Nicolás Bleyh iii

8 Quellcodeverzeichnis Quellcodeverzeichnis Quellcode 1: Definition der Rollen in WS-CDL Quellcode 2: Relationen zwischen Rollen in WS-CDL Quellcode 3: Definition der Kommunikationswege in WS-CDL Quellcode 4: Definition eines Datentypen in WS-CDL Quellcode 5: Beispiel einer mit WS-CDL beschriebenen Choreographie Quellcode 6: Definition der Teilnehmer in BPEL Quellcode 7: Definition von Variablen in BPEL Quellcode 8: Definition eines correlationset Quellcode 9: Mit BPEL beschriebener Teilablauf einer Reisebuchung Quellcode 10: Beispiel eines XForms Quellcode 11: Beispiel für die XML-Repräsentation der Nutzereingaben Quellcode 12: Angabe eines Datentyps zum Zweck der Validierung Quellcode 13: Beispiel für die Definition eines Eingabefelds in einer GUIDD Quellcode 14: Beispiel für die Beschreibung eines statischen Geschäftsablaufs mit BPEL Quellcode 15: Beispiel für die Beschreibung eines dynamischen Geschäftsablaufs mit BPEL Quellcode 16: Definition einer dynamischen Auswahlliste in der GUIDD Quellcode 17: Automatisch generierte Listenelemente Quellcode 18: vereinfachte BPEL-Prozessbeschreibung des Reisebuchungsszenarios Quellcode 19: Definition von property und propertyalias Quellcode 20: Inhalt eines SOAP-Bodys als Variablenwert Quellcode 21: Inhalt einer BPEL-Bedingung Quellcode 22: Verkürzte abstrakte BPEL-Prozessbeschreibung des Reisedienstes Quellcode 23: TravelProcess.wsdl (Auszug) Quellcode 24: AirlineService.wsdl (Auszug) Quellcode 25: HotelService.wsdl (Auszug) Quellcode 26: TravelProcess.bpel (Auszug) Quellcode 27: abstracttravelprocess.bpel Quellcode 28: wsdlcatalog.xml Quellcode 29: travel.pdd Quellcode 30: travelprocess.guidd (Auszug) Copyright TU Dresden, Nicolás Bleyh iv

9 Einleitung 1 Einleitung In den letzten Jahren erfuhren Web Services, also verteilt aufrufbare Dienste, als Middleware- Technologie der Zukunft eine immer größere Verbreitung. Dies liegt zum einen an der Nutzung standardisierter Internetprotokolle, zum anderen an der massiven Unterstützung durch die IT-Industrie. Somit konnten sich Spezifikationen zur Beschreibung der Dienstschnittstelle und der ausgetauschten Nachrichten etablieren. Mittlerweile ist es mit Hilfe von Prozessbeschreibungssprachen möglich, mehrere Web Services miteinander zu einem komplexen Web Service zu kombinieren. Ursprünglich wurden Web Services als Kommunikations- und Austauschform zwischen Softwareanwendungen konzipiert. Ein Beispiel hierfür wäre ein Web Service zur Kontrolle der Lagerbestände in einem Unternehmen. Sobald der Lagerbestand einen bestimmten Wert unterschreitet, wird automatisch der Web Service eines Partnerunternehmens aufgerufen, durch den eine Bestellung der benötigten Waren ausgelöst wird. Web Services unterstützen damit in erster Linie B2B (Business-to-Business) Beziehungen. Mittlerweile ist aber auch die Anforderung entstanden, Web Services für B2C (Business-to- Consumer) Beziehungen einzusetzen. Dies ist immer dann notwendig, wenn Eingaben erforderlich sind bzw. Entscheidungen getroffen werden müssen, die nicht automatisiert werden können. Falls ein Web Service durch eine menschliche Interaktion ausgelöst werden soll, muss dafür zunächst ein Benutzerinterface zur Verfügung gestellt werden. Da der menschliche Faktor im Web-Service-Konzept bisher noch keine Berücksichtigung findet, muss von Entwicklern für jeden elementaren Web Service ein Benutzerinterface erstellt werden. Abgesehen von dem damit verbundenen Aufwand, besitzt diese Vorgehensweise auch keinerlei Flexibilität. Bei jeder syntaktischen Veränderung auf der Seite des Web Services, wie die Änderung des Namens einer Funktion oder eines Parameters, muss das Benutzerinterface angepasst werden. Wünschenswert wäre hier eine automatische Generierung des Benutzerinterfaces anhand der Schnittstellenbeschreibung des Web Services. Um diese Anforderung zu erfüllen existieren bereits einige Forschungsarbeiten, auf die in dieser Arbeit eingegangen wird. Web Services werden heutzutage aber meistens nicht in ihrer elementaren Form eingesetzt, sondern sie werden zu komplexeren Anwendungen miteinander kombiniert, um so Geschäftsprozesse zwischen Unternehmen zu automatisieren. Auch hier tritt die Anforderung auf, menschliche Benutzer in die Lage zu versetzten, in den Geschäftsprozess einzugreifen bzw. diesen auszulösen. Ein Beispiel hierfür ist das Szenario einer Reisebuchung, in der z.b. mehrere Web Services zur Flugbuchung und zur Hotelbuchung angeboten werden. Im Normalfall müsste der Kunde, wie in der Abbildung 1 dargestellt, das Benutzerinterface für den Dienst der Hotelbuchung und der Flugbuchung parallel nebeneinander laufen lassen, über copy-and-paste die gleichen Anfragedaten eingeben und die Ergebnisse miteinander abgleichen, so dass der Zeitraum des Hotelaufenthalts mit den An- und Abreisedaten der Fluglinie übereinstimmen. Da diese Vorgehensweise sehr umständlich ist, sollten die Benutzerinterfaces der beiden Dienste miteinander kombiniert werden. Der Ablauf der Reisebuchung kann über eine Kompositionssprache festgelegt werden. So werden Anfragen an den Dienst der Fluggesellschaft und den des Hotels immer parallel ausgeführt, damit der Reisezeitraum übereinstimmt. Außerdem muss zunächst jeweils von der Fluglinie und vom Hotel ein Angebot eingeholt werden, bevor anschließend anhand des Angebots der Flug und das Hotel gebucht werden können. Copyright TU-Dresden, Nicolás Bleyh 1

10 Einleitung Abbildung 1: Beispiel für die bisherige Vorgehensweise bei Nutzerinteraktionen mit mehreren Diensten [1] Da die Nutzerinteraktion über ein Benutzerinterface erfasst werden muss, liegt die Problemstellung vor allem darin, abhängig vom Zustand des Geschäftsprozesses und je nach Ein- und Ausgabeparameter dynamisch eine passende und nutzerfreundliche Benutzerschnittstelle zu generieren. Ziel der Arbeit ist es, Lösungen für diese Problemstellung zu finden und zu evaluieren. Anhand dieser Analyse soll ein Konzept erarbeitet werden, wie mit Hilfe der in einer Kompositionssprache definieren Abhängigkeiten und Abläufe ein Benutzerinterface dynamisch zur Laufzeit generiert werden kann, so dass menschliche Benutzerinteraktionen in komplexen Web Services möglich sind. Die Arbeit untergliedert sich in die sechs Kapitel Grundlagen Web Services, Komplexe Web Services, Existierende Lösungen, Konzept, Implementierung und Zusammenfassung und Ausblick. Zunächst werden im zweiten Kapitel die Grundlagen von Web Services und die damit verbundenen Technologien XML, SOAP, WSDL und UDDI vorgestellt. Das dritte Kapitel behandelt theoretische Konzepte zur Komposition von elementaren Web Services zu einem komplexen Dienst. Anschließend erfolgt die Beschreibung zweier unterschiedlicher Szenarien zur menschlichen Interaktion mit komplexen Web Services. Im Kapitel Existierende Lösungen werden Ansätze und Technologien, die für die Lösung der Aufgabenstellung dieser Arbeit relevant sind, analysiert und bewertet. Dabei werden zunächst Kompositionssprachen zur Beschreibung komplexer Web Service vorgestellt. Anschließend werden unterschiedliche Ansätze zu generischen Benutzerschnittstellen behandelt. Zum Abschluss wird untersucht, inwiefern menschliche Benutzerinteraktionen in komplexen Web Services heutzutage umgesetzt sind. Das fünfte Kapitel beinhaltet den eigenen Lösungsansatz. Dabei werden zunächst Überlegungen angestellt, wie die Komposition und Darstellung eines komplexen Dienstes aus der Benutzersicht geeignet realisiert werden kann. Darauf aufbauend wird die Architektur des Konzepts beschrieben. Im vorletzten Kapitel wird die Implementierung des Konzepts in Form eines Prototyps vorgestellt. Zum Abschluss wird die Funktionalität des Prototyps anhand des Szenarios einer Reisebuchung demonstriert. Das sechste Kapitel fasst die grundlegenden Inhalte dieser Arbeit und das zur Lösung der Aufgabenstellung entwickelte Konzept kurz zusammen und gibt einen Ausblick auf mögliche Erweiterungen und Verbesserungen der Lösungsidee. Copyright TU-Dresden, Nicolás Bleyh 2

11 Grundlagen Web Services 2 Grundlagen Web Services Zunächst soll in diesem Kapitel das Konzept von Web Services und die grundlegenden Technologien, die für ihre Realisierung verwendet werden, vorgestellt werden. 2.1 Grundlagen Ursprünglich wurde das WWW ausschließlich für die Mensch-Maschine-Kommunikation verwendet. Dafür entwickelten sich zahlreiche Webtechnologien, angefangen vom statischen HTML bis hin zu JSP, PHP und anderen dynamischen Skriptsprachen. Durch die Verbreitung der Internettechnologie und der zunehmenden Vernetzung von Rechnern entstand vor allem im Unternehmensbereich die Notwendigkeit, eine Maschine-Maschine-Kommunikation zu entwickeln, so dass Anwendungen in verteilten Systemen miteinander interagieren können. Grundlage dafür war die Idee des Remote Procedure Calls (RPC), mit denen Funktionsaufrufe auf Programme entfernter Rechner durchgeführt werden können. Allerdings müssen bei RPCs die Infrastruktur als Teil der Anwendung realisiert werden [2]. Weiteführende Technologien wie CORBA (Common Object Request Broker Architecture), DCOM (Distributed Component Object Model) oder RMI (Remote Method Invocation) stellen diese Infrastruktur in der Laufzeitumgebung bereit. Trotzdem besitzen sie entscheidende Nachteile. DCOM und RMI, die von Microsoft bzw. Sun entwickelt wurden, sind nicht plattformunabhängig. So können diese Technologien in heterogenen Umgebungen nur eingesetzt werden, wenn die einzelnen Applikationen durch zusätzliche Schnittstellen (Wrapper) für die Kommunikation erweitert werden. CORBA ist zwar generell plattformunabhängig, allerdings muss die Umgebung einen so genannten Objekt Request Broker, der die Kommunikation zwischen den verteilten Anwendungen ermöglicht, bereitstellen, was eine relativ hohe Anforderung an das System stellt. Auch die Einführung eines neuen Transportprotokolls namens Internet Inter-ORB Protocol (IIOP) wirkte sich nachteilig auf die Durchsetzung von CORBA aus. Außerdem fehlte CORBA die Unterstützung der IT-Industrie (vor allem die von Microsoft). Web Services (in den späteren Kapiteln auch als Service oder Dienst bezeichnet) verfolgen den gleichen Ansatz, nämlich die Kommunikation zwischen verteilten Anwendungen, allerdings auf der Grundlage von standardisierten, plattformunabhängigen Technologien, die sich durch die Verbreitung des Internets durchgesetzt haben. Für die Bezeichnung Web Service finden sich in der Literatur zahlreiche Definitionen. Vom World Wide Web Consortium (W3C) stammt die folgende [3]: A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards. In dieser Definition werden bereits die verwendeten Technologien erwähnt, auf die im nächsten Unterkapitel näher eingegangen werden soll. Allgemein betrachtet kommuniziert ein Web Service mit anderen Softwarekomponenten über XML-Nachrichten. Der Nachrichtenaustausch kann dabei insbesondere mit Hilfe von Internetprotokollen (z.b. HTTP oder SMTP) stattfinden. Damit ein Web Service von anderen Anwendungen aufgerufen werden kann, benötigt dieser eine maschinenlesbare Schnittstelle und muss durch eine URI (Uniform Ressource Identifier) eindeutig identifiziert werden. Web Services sind autonom, d.h., wie und ob eine Nachricht von einem Web Service verarbeitet wird, kann nicht beeinflusst werden [4]. Copyright TU-Dresden, Nicolás Bleyh 3

12 Grundlagen Web Services Web Services werden oft auch im Zusammenhang mit dem Paradigma der Serviceorientierten Architektur (SOA) erwähnt. Dabei handelt es sich um ein Architekturmuster, das den Aufbau einer Anwendungslandschaft aus einzelnen Anwendungsbausteinen beschreibt, die jeweils eine klar umrissene Aufgabe wahrnehmen. Diese Anwendungsbausteine sind lose miteinander gekoppelt, indem sie einander ihre Funktionalitäten in Form von Services anbieten. Ein Service ist eine feste, definierte Leistung, die als Element eines oder mehrerer größerer Verarbeitungsabläufe verwendet werden kann. Als solcher stellt der Service eine abstrakte fachliche Sicht auf den anbietenden Anwendungsbaustein dar und verbirgt alle Implementationsdetails. Services werden über einen einheitlichen Mechanismus aufgerufen, der die Anwendungsbausteine plattformunabhängig miteinander verbindet und alle technischen Details verbirgt. Die elementaren Grundgedanken einer SOA sind somit die Trennung der Zuständigkeiten nach fachlichen Gesichtspunkten sowie die Kapselung technischer Details [5]. In einer SOA existieren drei verschiedene Rollen: der Service Provider als Anbieter eines Services, der Service Requester als Interessent an einem solchen und der Service Broker, einem Verzeichnisdienst als Vermittler zwischen beiden. Das Zusammenspiel zwischen diesen Rollen sieht folgendermaßen aus [2]: 1. Zunächst implementiert ein Service Provider einen Service und registriert diesen beim Service Broker. 2. Der Service Requestor sucht bei einem Verzeichnisdienst nach einem Service mit den gewünschten Eigenschaften. Findet er einen passenden Service, holt er sich beim Service Provider eine Beschreibung des Services, welche die Spezifikation der Schnittstelle enthält. 3. Über ein lokales Interface ruft er den Service auf, womit es zur Ausführung des Dienstes kommt. Dieser Ablauf soll in der folgenden Abbildung grafisch verdeutlicht werden. Abbildung 2: Service-orientierte Architektur (SOA) Der Service Requestor und der Service Provider sind "lose gekoppelt". Das heißt, beide müssen über die Schnittstellenbeschreibung hinaus nichts von einander wissen. Genau das macht das Prinzip der Service-orientierten Architektur so mächtig [6]. Durch die Standardisierung der Schnittstellen ist eine flexible Kopplung von verteilten Softwarekomponenten möglich. Als tragende Technologie für den Aufbau einer SOA werden Web Services und die damit verbundenen Standards diskutiert. Der große Vorteil einer standardisierten Infrastruktur auf Basis von Web Services liegt in der Interoperabilität von Softwareprodukten. Aus dem Architekturmodell SOA stammt laut [7] auch der Name Service. Die Bezeichnung Web entwickelte sich daraus, weil sich HTTP als Transport-Protokoll durchsetzte. Technologisch kann eine SOA aber auch mit anderen Technologien wie beispielsweise CORBA umgesetzt wer- Copyright TU-Dresden, Nicolás Bleyh 4

13 Grundlagen Web Services den. Den in der Abbildung 2 dargestellten Ablauf unterstützen Web Services mit Hilfe von vier Standards, auf die in den folgenden Kapiteln näher eingegangen werden soll. 2.2 Standards Zur Beschreibung der Schnittstelle eines Services dient die Web Service Description Language (WSDL). Diese wird über einen Service Broker veröffentlicht, dessen Aufgabe UDDI (Universal Description, Discovery and Integration) übernimmt. Die Kommunikation zwischen den drei Teilnehmern erfolgt über SOAP, einem XML-basierten Nachrichtenformat. Grundlage für SOAP und WSDL ist XML XML XML (Extensible Markup Language) ist heutzutage das Standardformat zur Erstellung maschinen- und menschenlesbarer Dokumente. Es ist eine deskriptive Sprache, die vor allem zur plattformunabhängigen Beschreibung und für den Austausch komplexer Datenstrukturen eingesetzt wird [8]. Pflege und Weiterentwicklung des XML-Standards liegen in der Verantwortung des W3C (World Wide Web Consortium) [9]. XML-Dokumente sind in Form einer Baumstruktur aufgebaut, die durch Elemente repräsentiert wird. Um XML-Dokumente automatisch verarbeiten zu können, müssen diese den in der XML-Spezifikation festgelegten Regeln bezüglich Notation und Struktur genügen [2]. Man unterscheidet daher zwischen wohlgeformten und gültigen Dokumenten. Wohlgeformtheit bedeutet, dass das Dokument die Regeln von XML, wie beispielsweise die Verschachtelung von Elementen, erfüllen. Ein XML-Dokument ist gültig, falls es wohlgeformt ist und zusätzlich eine Grammatik besitzt. Diese Grammatik kann z. B. in Form einer DTD (Document Type Definition) oder durch XML-Schema definiert werden. XML-Schema ist eine komplexe Sprache zur Beschreibung der Struktur von XML- Dokumenten. Diese Beschreibung umfasst die Spezifikation neuer XML-Elemente, deren Attribute sowie deren Kindelemente. Außerdem wird eine große Anzahl von Datentypen unterstützt. Ferner bietet XML-Schema auch die Möglichkeit, den Inhalt von Elementen und Attributen zu beschränken, z. B. auf Zahlen, Datumsangaben oder Zeichenketten. Die Syntax von XML-Schema ist wiederum XML. Mittels XML-Schema können Dokumentstrukturen (bzw. Datenstrukturen) sehr genau beschrieben und die gespeicherten Informationen auf ihre Korrektheit hin (in Bezug auf die Struktur) überprüft werden. SOAP wie auch WSDL werden jeweils durch ein XML-Schema spezifiziert. Ein weiterer wichtiger Bestandteil von XML sind Namensräume. Bei der Aggregation von mehreren XML-Dokumenten können Namenskonflikte auftreten, wenn Elemente oder Attribute gleichen Namens, aber unterschiedlicher Bedeutung verwendet werden. Mit Hilfe von Namensräumen können gleichnamige Elemente unterschieden werden. Definiert wird ein Namensraum durch eine eindeutige URI und ein optionales Präfix, dass bei Verwendung dem entsprechenden Elementnamen vorangestellt wird. Durch die Durchsetzung von XML als plattformunabhängiger Standard zur Definition von beliebigen, in ihrer Grundstruktur jedoch stark verwandten Auszeichnungssprachen verwenden sowohl SOAP als auch WSDL XML zur Beschreibung von Schnittstellen, Datenstrukturen und Übertragungsformaten. Copyright TU-Dresden, Nicolás Bleyh 5

14 Grundlagen Web Services SOAP SOAP ist der Standard des Middleware-Protokolls von Web Services und wurde von Microsoft als Nachfolger des XML-RPCs entwickelt [8]. Mittlerweile liegt SOAP ebenfalls in der Verantwortung des W3C. Das Akronym SOAP stand ursprünglich für Simple Object Access Protocol. Da das Protokoll jedoch aus der Nähe betrachtet weder einfach noch objektorientiert ist, wurde der Name mit Version 1.2 weggelassen, geblieben ist das Akronym. SOAP erlaubt das Versenden von Funktionsaufrufen (RPC) und Daten im XML-Format. RPC-Protokolle für den Aufruf von Funktionen in verteilten Systemen werden bereits von verschiedenen Plattformen unterstützt, zum Beispiel in RMI oder.net Remoting. Diese Protokolle besitzen jedoch entscheidende Nachteile [2]: Client und Server müssen die gleiche Plattform verwenden, d.h. sie sind eng gekoppelt. Plattformübergreifende Aufrufe sind, wenn überhaupt, nur mit speziellen Brückentechniken möglich. Sie sind nicht für das Internet als Übertragungsmedium geeignet, da sie spezielle Ports verwenden, die von Firewalls in der Regel aus Sicherheitsgründen blockiert werden. Der Einsatz ist normalerweise auf unternehmensinterne Anwendungen beschränkt. SOAP ist dagegen plattformunabhängig und kann unternehmensübergreifend eingesetzt werden, da es für die Kommunikation das HTTP-Protokoll verwenden kann. Der dafür verwendete Port wird von Firewalls gemeinhin nicht blockiert. Jede SOAP-Nachricht besitzt einen envelope als Wurzelelement. Dieser enthält einen oder mehrere optionale header-elemente sowie ein obligatorisches body-element. Die Elemente header und body können selbst wieder aus mehreren Blöcken bestehen. In der Abbildung 3 ist dieser grundlegende Aufbau einer SOAP-Nachricht dargestellt. Abbildung 3: schematische Repräsentation einer SOAP-Nachricht [10] Mit dem SOAP header werden zusätzliche Informationen wie Sicherheits- oder Transaktionseigenschaften (z.b. eine Transaktionsnummer) an den Empfänger einer Nachricht übermittelt. Der Inhalt des header ist allerdings nicht Bestandteil der SOAP-Spezifikation, sondern muss anwendungsspezifisch festgelegt werden. Die Übertragung von SOAP-Nachrichten im Internet geht in der Regel über mehrere Netzknoten. Neben dem Sender und dem Empfänger einer Nachricht kann es daher auch noch eine Anzahl von Zwischenknoten geben, den Intermediaries. Diese sind gleichzeitig Sender und Empfänger. Im SOAP header kann festgelegt Copyright TU-Dresden, Nicolás Bleyh 6

15 Grundlagen Web Services werden, wie sich jeder einzelne Knoten zu verhalten hat, wenn er eine Nachricht bekommt. Zwei Attribute des header-elements regeln deren Verarbeitung: Das role-attribut gibt an, welche Zwischenknoten die Informationen im header- Element verarbeiten müssen. Das mustunderstand-attribut wird verwendet, um anzugeben, ob die Verarbeitung eines header-elementes für einen betroffenen Zwischenknoten verpflichtend oder optional ist. Das relay-attribut gibt an, ob ein header-element nach seiner Abarbeitung an den nachfolgenden Zwischenknoten weitergegeben oder aus der SOAP-Nachricht gelöscht werden soll [11]. Im body-element befinden sich die eigentlichen Informationen, die übertragen werden sollen. Dabei wird zwischen zwei Nachrichtenarten unterschieden. Zum einen kann es sich dabei um einen dokumentenbasierten Nachrichtenaustausch handeln, d.h., mittels SOAP werden XML-Dokumente ausgetauscht. Die zweite Nachrichtenart wird SOAP RPC genannt, womit ein XML-kodierter Funktionsaufruf bezeichnet wird. Die SOAP-Spezifikation legt dabei fest, wie ein Funktionsaufruf mit zugehörigen Parametern und Rückgabewert in XML repräsentiert wird. Beim Fehlschlag eines Funktionsaufrufes kann der SOAP body auch eine Fehlermeldung enthalten. Darin wird unter Angabe des Fehlercodes, der Fehlerbeschreibung und weiterer Details die Fehlermeldung erläutert [12]. Zusammenfassen lässt sich SOAP als ein auf XML basierendes Nachrichtenformat beschreiben, welches für den Transport bestehende und verbreitete Kommunikationsprotokolle wie HTTP, SMTP oder FTP verwendet [8] WSDL Eine wichtige Voraussetzung für das Publizieren und Benutzen von Web Services ist eine standardisierte Beschreibung der Schnittstellen. So benötigt der Aufrufer eines Dienstes beispielsweise Informationen über vorhandene Methoden, deren Parameter und Rückgabewerte. Dazu dient die Web Service Description Language (WSDL). Die WSDL-Beschreibung eines Web Services beantwortet folgende drei Fragen [4]: Was bietet der Web Service? Welche Protokolle werden zum Nachrichtenaustausch verwendet und wie werden die Nachrichten kodiert? Wie heißt der Web Service und unter welcher Internet-Adresse kann man Nachrichten an den Web Service schicken. WSDL erlaubt die Deklaration von Operationen und die Definition der Nachrichten, die ein Web Service empfangen kann und die er verschickt. Das Format, in dem Web Services beschreiben werden, ist XML [4]. Entwickelt wurde WSDL von IBM, Microsoft und Ariba, wie SOAP und XML wird es aber mittlerweile vom W3C standardisiert. Obwohl WSDL in der Version 2.0 vorliegt, wird in dieser Arbeit nur auf die Version 1.1 eingegangen. Grund dafür ist die noch fehlende Unterstützung von WSDL 2.0 sowohl in Web-Service- Autorenwerkzeugen als auch in weiterführenden Web-Service-Standards wie z.b. BPEL (siehe Kapitel 4.1.3). Das Wurzelelement eines WSDL-Dokuments ist definitions. Es definiert Namen und Namensraum des Web Services sowie den Namensraum der verwendeten Standards. Das Copyright TU-Dresden, Nicolás Bleyh 7

16 Grundlagen Web Services Element types enthält alle Datentypdefinitionen, die für den Aufruf des Service benötigt werden und nicht im Standard XML-Schema des W3C definiert sind. Diese werden mit Hilfe von XML-Schema beschrieben. Die Definition von Nachrichten, die bei einem SOAP-Aufruf übertragen werden, erfolgt durch das message-element. Werden mehrere Nachrichten benötigt, wie beispielsweise Eingabeparameter und Rückgabewert, so werden mehrere Nachrichten definiert. Eine Nachricht kann aus logischen Teilelementen, so genannten part- Elementen bestehen. Ein part-element definiert ein Name-Wert-Paar als Parameter einer Nachricht. Das Element operation definiert eine vom Web Service angebotene Funktion. Dieses Element kann ein input- und ein output-element beinhalten, welches jeweils auf das message-element verweist, das die Ausgangs oder Eingangsnachricht einer Funktion darstellt. Grundsätzlich gibt es vier unterschiedliche Typen von Operationen: One-way: Der Client sendet eine Nachricht an den Web Service, eine Antwort wird nicht erwartet. Request-Response: Der Client sendet eine Nachricht und erhält vom Web Service eine Antwort. Solicit Response: Der Server sendet eine Nachricht und erhält vom Client eine Antwort. Notification: Der Server sendet eine Nachricht an den Client, eine Antwort wird nicht erwartet. Das Element porttype beinhaltet eine Sammlung von operation-elementen. Diese bisher vorgestellten Elemente werden als abstrakter Teil der WSDL-Beschreibung bezeichnet. Der konkrete Teil der WSDL-Beschreibung besteht aus den Elementen binding, port und service. Das binding-element legt das Protokoll und das Nachrichtenformat für einen porttype fest. Es hat die Attribute style und transport. Das style-attribut gibt an, ob es sich um eine Dokument-orientierte oder RPC-orientierte Operation handelt (zum Unterschied siehe Kapitel ) Das transport-attribut gibt an, welches Transportprotokoll verwendet wird, während das port-element einen Kommunikationsendpunkt festlegt, z.b. die URL, unter dem der Web Service zu erreichen ist. Über das service-element können mehrere solche konkreten Endpunkte zu einem abstrakten Endpunkt zusammengefasst werden [8]. Zur Verdeutlichung wird in der Abbildung 4 der hierarchische Aufbau einer WSDL- Beschreibung schematisch dargestellt. Copyright TU-Dresden, Nicolás Bleyh 8

17 Grundlagen Web Services Abbildung 4: schematischer Aufbau einer WSDL-Datei Durch die Trennung von abstraktem und konkretem Teil erhöht sich die Wiederverwendbarkeit von WSDL-Beschreibungen. So kann ein abstrakter Teil für mehrere konkrete Teile verwendet werden. Um andere WSDL-Dokumente zu importieren, existiert ein import- Element. WSDL-Schnittstellenbeschreibungen werden üblicherweise nicht von Hand erstellt. Web- Service-Plattformen stellen Werkzeuge zur Verfügung, die aus der Schnittstellendefinition in einer spezifischen Programmiersprache ein WSDL-Dokument erstellen [8]. Umgekehrt generieren Werkzeuge aus der WSDL-Beschreibung einen Methodenrumpf für die jeweilige Programmiersprache, über welche der Client den Web Service aufrufen kann. Mit WSDL kann weder die Semantik des Web Services noch die seiner Parameter beschrieben werden (siehe hierzu RDF(S), OWL(S)). WSDL definiert auch keine Bindung von Datentypen an eine Programmiersprache. Ob ein Integer-Parameter zum Beispiel auf eine 32-Bit oder eine 64-Bit-Zahl abgebildet wird, ist daher implementierungsspezifisch [2]. Auch ist es mit WSDL nicht möglich, beispielsweise die Reihenfolge, in der die Operationen eines Web Services aufgerufen werden dürfen, festzulegen. Hierfür sind Erweiterungen notwendig, auf die im Kapitel 4.1 eingegangen wird UDDI Als Vermittler zwischen dem Anbieter und den Nutzern von Web Services wird ein Verzeichnis benötigt, bei dem Dienste registriert werden können bzw. nach Diensten anderer Anbieter gesucht werden kann. Zu diesem Zweck wurde UDDI (Universal Description, Discovery and Integration) von IBM, Ariba und Microsoft entwickelt [10]. Seit dem Jahr 2002 wird UDDI vom Standardisierungsgremium OASIS (Organization for the Advancement of Structured Information Standards) betreut und weiterentwickelt. Ein UDDI-Verzeichnis hat im Wesentlichen zwei Aufgaben zu erfüllen: Anbieter können in einem UDDI-Verzeichnisdienst ihre Web Services veröffentlichen. Hierzu definiert der Standard eine Publishing-API. Servicenutzer können anhand von inhaltlichen Kriterien nach Web Services suchen. Hierzu definiert der Standard eine Inquiry-API. Copyright TU-Dresden, Nicolás Bleyh 9

18 Grundlagen Web Services Um die Informationen über Web Services in einem UDDI-Verzeichnis kategorisieren zu können, enthält die UDDI-Spezifikation außerdem ein Datenmodell. Dieses bietet für den Zugriff auf die in dem Verzeichnis abgelegten Daten drei (abstrakte) Kategorien: Weiße Seiten enthalten Adressen und Kontaktdaten der registrierten Unternehmen. Gelbe Seiten strukturieren die Informationen nach verschiedenen Taxonomien, z.b. nach dem Ort oder Industriezweig eines Unternehmens oder nach den von ihm angebotenen Produkten/Services. Grüne Seiten enthalten Informationen über die von dem jeweiligen Unternehmen angebotenen Web Services. Im Wesentlichen werden hier die WSDL- Schnittstellenbeschreibungen bereitgestellt. Grundlage dafür ist die UDDI Business Registration, eine XML-Datei, die dazu dient, ein Unternehmen und seine Web Services zu beschreiben. Das von UDDI verwendete Informationsmodell ist in einem XML-Schema festgelegt und beinhaltet folgende Elemente [2]: businessentity: Im Element businessentity sind Informationen über das Unternehmen selbst enthalten, zum Beispiel der Name, eine Beschreibung, Kontaktinformationen sowie das servicekey-element, ein Verweis auf die von dem Unternehmen angebotenen Web Services. businessservice: Das Element businessservice dient zur Beschreibung eines konkreten Web Service. Es beinhaltet den Namen und eine textuelle Beschreibung des Service sowie eine Liste von bindingkey-elementen, die auf die technische Beschreibung des Service verweisen. bindingtemplate: Neben einer optionalen textuellen Beschreibung befinden sich in dem Element bindingtemplate die Angaben, die zum Aufrufen eines Web Service benötigt werden. Es handelt sich dabei also um den konkreten Teil der WSDL- Beschreibung. Außerdem enthält dieses Element über einen so genannten tmodelkey einen Verweis auf ein tmodel-element. tmodel (Technology Model): Das tmodel-element enthält Zusatzinformationen, die ein Nutzer des Web Service benötigt. Dies sind im Wesentlichen die abstrakten Bestandteile der WSDL [1]. Neben einer textuellen Beschreibung enthält es in der Regel Verweise auf zusätzliche Dokumentationen. publisherassertion: Das Element publisherassertion ist für große Konzerne gedacht, die nicht durch ein einziges businessentity-element repräsentiert werden können. Es ermöglicht einem solchen Unternehmen, mehrere businessentity-elemente einzutragen, die z.b. die verschiedenen Unternehmensbereiche repräsentieren, diese aber trotzdem als zusammengehörig zu kennzeichnen. Abbildung 5 zeigt die Datenstrukturen einer UDDI Business Registration und die abstrakte Sicht darauf. Copyright TU-Dresden, Nicolás Bleyh 10

19 Grundlagen Web Services Abbildung 5: Abstrakte Sichten und Datenstrukturen von UDDI [13] Nicht jeder UDDI-Verzeichnisdienst kann und muss die Anforderungen eines universellen, globalen Verzeichnisdienstes erfüllen. Im UDDI-Standard werden zwei Typen von Dienstanbietern unterschieden: UDDI-Operatoren und private UDDI-Verzeichnisdienste. Der Unterschied dieser beiden Betreiber von UDDI-Verzeichnisdiensten liegt darin, dass UDDI- Operatoren bestimmte Anforderungen zu erfüllen haben. Dazu gehört die Zusicherung der Eigenschaften Verfügbarkeit, Sicherheit und Performance für ihre Verzeichnisdienste [8]. Diese und weitere Eigenschaften wie beispielsweise geschäftlich relevante Informationen (z.b. Kosten, Zahlungsart) können über so genannte Policies spezifiziert werden [4]. Die UDDI-Verzeichnisse der UDDI-Operatoren arbeiten eng zusammen und werden in ihrer Gesamtheit als Universal Business Registry (UBR) bezeichnet. UDDI-Operatoren sind u.a. Microsoft, IBM und SAP. Da die API von UDDI eine WSDL-Schnittstellenbeschreibung besitzt und über SOAP- Nachrichten angesprochen werden kann, stellt UDDI selbst einen Web Service dar. 2.3 Einsatzgebiete Um das große Potential von Web Services zu verdeutlichen, sollen im Folgenden ein paar Einsatzgebiete vorgestellt werden. Wie bereits in Kapitel 2.1 erwähnt, sind Web Services momentan die maßgebende Technologie zur Realisierung von Service-orientierten Architekturen. Dadurch, dass Funktionen nur einmal implementiert werden müssen und dann als Service anderen Programmen zur Verfügung gestellt werden, können bei der Softwareentwicklung Redundanzen vermieden und Kosten gesenkt werden. Da die eigentlichen Implementierungsdetails der Services gekapselt sind, also vor dem Benutzer des Service verborgen bleiben, können die Funktionen einfacher und schneller angewendet werden [6]. Ein weiteres großes Einsatzfeld von Web Services ist die Enterprise Application Integration (EAI). Damit bezeichnet man die Integration der einzelnen Software-Systeme eines Unternehmens. Eine solche Integration ist notwendig, um eine weitere Automatisierung und Optimierung der Abläufe, d.h. der Geschäftsprozesse, in einem Unternehmen zu erreichen. So erfordert ein Ablauf die Interaktion zwischen mehreren Software-Systemen innerhalb des Unternehmens und zunehmend auch unternehmensübergreifend. In der Vergangenheit erfolgte die Integration von Anwendungen in vielen Fällen durch Punkt-zu-Punkt-Verbindungen. Dabei wurden jeweils zwei Anwendungen durch geeignete Adapter miteinander verbunden, die es ihnen erlaubte, miteinander zu kommunizieren und Daten auszutauschen. Dies führte Copyright TU-Dresden, Nicolás Bleyh 11

20 Grundlagen Web Services im Laufe der Zeit zu einer oft unüberschaubaren Vielzahl von Verbindungen mit der Konsequenz, dass es immer schwieriger und teuerer wurde, weitere Anwendungen zu integrieren. Als Lösung für diese Problematik werden mehrere Geschäftsanwendungen innerhalb eines Intranets mittels einer zentralen Komponente miteinander verbunden. Bietet die zentrale Komponente umfangreiche Funktionalität bzgl. Nachrichtentransport, Routing und Datentransformation, so wird durch diese Architektur die direkte Kommunikation vieler Anwendungen über einzeln zu entwickelnde Adapter überflüssig. Für die Kommunikation der einzelnen Anwendungen mit der zentralen Komponente kann eine Web-Service-Schnittstelle zum Einsatz kommen. Da die Integration auf Geschäftslogikebene voraussetzt, dass die einzelnen Anwendungen über Programmierschnittstellen verfügen, über die auf die Geschäftslogik zugegriffen werden kann, sollten die Anwendungen ebenfalls über eine Web-Service- Schnittstelle zugänglich gemacht werden [2]. Auf diese Weise ist es möglich, mit Hilfe der Web-Service-Technologie heterogene Software-Systeme in eine gemeinsame Infrastruktur zu integrieren. Mehr Informationen zum Thema EAI finden sich u.a. in [10]. Im Einsatzgebiet des B2B (Business-to-Business) wird der EAI Ansatz über Unternehmensgrenzen hinweg fortgesetzt, da die Integration von Anwendungen externer Partnerunternehmen in die unternehmensinterne Anwendungslandschaft in der heutigen Zeit eine zunehmende Rolle spielt. Durch die Verwendung von standardisierten Web-Service-Protokollen besteht die Aussicht, solche Anbindungen schneller, billiger und flexibler als mit bisherigen Standards, wie z.b. EDIFACT (Electronic Data Interchange For Administration, Commerce, and Transport) realisierten zu können. Das Zielt dieser Arbeit ist jedoch die Unterstützung von B2C (Business-to-Consumer) Beziehungen. In diesem Einsatzfeld interagieren Kunden über entsprechende Benutzerschnittstellen mit den von einer Firma bereitgestellten Web-Service-Komponenten. 2.4 Bewertung In den letzten Jahren haben Web Services im Unternehmensbereich und im universitären Umfeld eine immer größere Aufmerksamkeit erreicht. Einige Gründe, die für den Erfolg der Web-Service-Technologie sprechen, sollen im Folgenden aufgezählt werden [4]: Lose Kopplung: Die einzelnen Systeme bleiben autonom und kommunizieren über Nachrichten miteinander. Ein gemeinsames Kompilieren oder Binden der einzelnen Anwendungen zu einer großen Anwendung findet nicht statt. Hierdurch können die einzelnen Systeme unabhängig voneinander weiterentwickelt werden. Einheitliche Konventionen: Web Services unterstützen viele unterschiedliche Datenformate, Protokolle und Mechanismen zur Zusicherung von Qualitätseigenschaften und schränken somit die verwendeten Technologien nicht ein. Web-Service- Technologien bestimmen hierzu einheitliche Konventionen, wie ein Web Service die Datenformate, Protokolle und Qualitätseigenschaften zur Interaktion mit anderen Web Services festlegt. Standards: Einer der wesentlichen Gründe für den Erfolg von Web Services ist die Festlegung von Standards, an die sich alle großen Plattform-Anbieter (wie z.b. BEA, IBM und Microsoft), Anbieter von Softwareanwendungen (wie z.b. SAP und Siebel) und Anwender (z.b. Unternehmen aus der Industrie) halten. So genießen SOAP und WSDL eine breite Herstellerunterstützung. Unterstützung der Industrie: Web Services werden mittlerweile von allen namhaften Herstellern unterstützt. Die immensen Investitionen aller Beteiligten in diesem Be- Copyright TU-Dresden, Nicolás Bleyh 12

21 Grundlagen Web Services reich resultieren in einer weit verbreiteten Unterstützung der Web-Service-Standards und Standard-Vorschläge. SOAP ist leichtgewichtig: Durch die Verwendung von SOAP und HTTP werden nur geringe Anforderungen an die Client-Maschine gestellt. Sie beschränken sich auf die Fähigkeiten, HTTP-Nachrichten zu senden und zu empfangen, die enthaltenen SOAP- Nachrichten im XML-Format zu parsen und an die registrierten Anwendungen weiterzuleiten. Beide Aufgaben sind auf allen Plattformen und für alle Programmiersprachen hinreichend gut unterstützt. Programmiersprachen- und Programmiermodellunabhängigkeit: Web Services auf der Basis von SOAP machen keinerlei Annahmen über das Programmiermodell und sind durch die weite Verbreitung von XML sehr leicht in allen relevanten Sprachen zu realisieren. Transport von XML-Nachrichten: Übertragene Nachrichten sind von Entwicklern lesbar, was vor allem in der Entwicklungsphase und in Fehlerfällen günstig ist. Zweitens ermöglicht die Verwendung von XML im Gegensatz zu einem festen Nachrichtenund Typsystem flexible Erweiterungen. SOAP-Nachrichten könne Firewalls passieren: Vor allem im B2B-Bereich muss Kommunikation durch die Firewalls der beteiligten Unternehmen möglich sein. SOAP-Nachrichten über HTTP können Firewalls über den standardmäßigen Port (80) problemlos passieren. Nachteile von Web Services resultieren vor allem aus der Verwendung von XML. Durch die Verwendung von XML als Nachrichtenformat bläht sich die Größe der zu übertragenden Daten um bis zu 30 % auf [8], wodurch sich der Datenverkehr gegenüber binären Nachrichten eklatant erhöht. Außerdem erfordert das Parsen der XML-Nachrichten und Schnittstellen eine erhöhte Rechenleistung der beteiligten Rechner. Ein weiterer Grund gegen Web Services ist das sich noch in der Entwicklung befindliche Sicherheits- und Transaktionskonzept. Daher werden Web Services bis jetzt vor allem für sicherheitsunkritische Geschäftsabläufe eingesetzt. Zusammenfassend zeigt die Abbildung 6 die grundlegenden Technologien, auf denen Web Services basieren. Nicht abgebildet sind zusätzliche Erweiterungen, die notwendig sind, um Web Services auch für kritische Geschäftsabläufe gewinnbringend einsetzen zu können. Dazu zählen die Sicherheit der Datenübertragung (siehe [14]), Gewährleistung von Transaktionsmechanismen (Business Transaction Protocol, WS-Transaction, WS-Coordination), Qualities of Service (Policies) und die semantische Beschreibung von Web Services (siehe [15]). Abbildung 6: Web Service Stack [16] Copyright TU-Dresden, Nicolás Bleyh 13

22 Grundlagen Web Services Der Fokus dieser Arbeit liegt auf der obersten Schicht des abgebildeten Web Service Stacks, also auf die Orchestrierung und Choreographie von Web Services und wie dabei menschliche Interaktionen geeignet integriert werden können. Copyright TU-Dresden, Nicolás Bleyh 14

23 Komplexe Web Services 3 Komplexe Web Services Mit den im vorherigen Kapitel vorgestellten Standardtechnologien ist es lediglich möglich, einfache verteilte Anwendungen zu realisieren, da immer nur ein Web Service aufgerufen werden kann (zur Unterscheidung werden diese im Folgenden als elementare Web Services bezeichnet). Sie reichen jedoch nicht aus, um komplexere Abläufe zu realisieren. Ein Beispiel für so einen Ablauf wäre das in der Einleitung vorgestellte Szenario einer Reisebuchung mit den Teilnehmern Hotel, Fluglinie und Bank. Jeder dieser Teilnehmer stellt einen elementaren Web Service zur Verfügung. Diese müssen geeignet miteinander kombiniert werden, um so den Geschäftsprozess einer Reisebuchung abbilden zu können. Ein so komponierter Web Service kann selbst wieder als elementarer Web Service verfügbar gemacht werden [17]. Bisher wurde die Komposition von Web Services meist in traditionellen Programmiersprachen wie Java oder C# realisiert, wobei der Entwickler u.a. viel Ziel mit der bloßen Konvertierung von Daten zwischen einzelnen Anwendungen, dem Erstellen von SOAP-Nachrichten, der Fehlerbehandlung, dem Zuordnen von Nachrichten zu Instanzen und der Unterstützung für Transaktionen verbringen muss [10]. Diese systemnahen Aspekte und die Geschäftslogik sind dann im Quellcode vermischt, was die Pflege und Wartung entsprechender Anwendungen erschwert [17]. Außerdem müssen so bei der Erstellung von komplexen Web Services viele low-level Details beachtet werden, anstatt sich nur auf die Geschäftslogik zu konzentrieren. Hier liegt es nahe, die von Workflow-Management-Systemen (WfMS) bekannte Idee aufzugreifen, die Prozesslogik (Kontroll- und Datenfluss, transaktionales Verhalten, usw.) von der Beschreibung und Implementierung der Anwendungsfunktionen hier den (elementaren) Web Services zu trennen. Damit lässt sich der Kontrollfluss einer Anwendung vom Code in die Prozesssteuerung verlagern und es wird eine klare Arbeitsteilung zwischen dem Softwareentwickler, der Anwendungsbausteine als Web Service bereitstellt, und dem Geschäftsanalysten, der diese Bausteine zu einem Geschäftsprozess zusammenfügt, ermöglicht [2]. Um dies zu realisieren, wurden Prozessbeschreibungssprachen (oder Kompositionssprachen) entwickelt. Diese unterstützen die Darstellung von komplexen Geschäftsvorgängen in und zwischen Unternehmen und legen damit fest, welche Services (bzw. Service-Operationen) in welcher Reihenfolge und unter welchen Bedingungen ausgeführt werden sollen [17]. Die Prozessbeschreibungen werden durch ein spezielles Laufzeitsystem interpretiert, was eine automatische Ausführung des Geschäftsprozesses erlaubt [8]. Da Kompositionssprachen ihren Ursprung in Bereich des Workflow-Managements haben, sollen zunächst einige grundlegende Begriffe zu diesem Thema definiert werden. Anschließend werden die verschiedenen Unterbegriffe der Komposition erläutert. Zuletzt werden in diesem Kapitel anhand von Szenarien drei verschiedene Möglichkeiten vorgestellt, wie Benutzerinteraktion in einen komplexen Web Service integriert werden können. 3.1 Workflow-Management Im Bereich des Workflow-Managements existieren zwei Organisationen, die sich mit Spezifikationen und Modellen zum Workflow-Management beschäftigen. Seit 1993 befasst sich die Workflow-Management Coalition (WfMC, [18]), eine Vereinigung von Forschungsinstituten, Hochschulen, Anwendern und Softwareherstellern, mit Standards im Bereich des Workflow- Managements [19]. Die andere Organisation ist die Business Process Management Initiative (BPMI, [20]), eine Organisation von Herstellern, Beratern und Anwendern, die sich zwecks Copyright TU-Dresden, Nicolás Bleyh 15

24 Komplexe Web Services der Standardisierung der Architektur und Schnittstellen von Geschäftsprozess-Management- Systemen (BPMS) zusammengefunden haben. Die in diesen Organisationen entwickelten Geschäftsprozesssprachen sind Technologieunabhängig und können daher bis auf die Business Process Modeling Language (BPML) nicht direkt für die Definition von komponierten Web Services verwendet werden. Trotzdem bilden sie die Grundlagen für die in Kompositionssprachen verwendeten Sprachkonstrukte und Konzepte. Deshalb sollen im Folgenden einige grundlegende Begriffe voneinander abgegrenzt werden: Geschäftsprozess (Business Process): Ein Geschäftsprozess ist eine zielgerichtete, zeitlich-logische Abfolge von Aktivitäten, die von Nutzern oder Softwareanwendungen getätigt werden, um ein Geschäftsziel zu erreichen (Beispiel: Buchung einer Reise) [10], [19]. Aktivität (Activity): Aktivitäten sind die elementaren Bestandteile eines Geschäftsprozesses. Sie besitzen bestimmte Ein- und Ausgaben und können maschinell oder durch einen Menschen ausgeführt werden [21]. Arbeitsablauf (Workflow): Ein Workflow ist die teilweise oder gesamte Automatisierung eines Geschäftsprozesses, in welchem Dokumente, Information oder Aufgaben zwischen Teilnehmern dieses Geschäftsprozesses weitergereicht werden [21]. Er beinhaltet die zeitlichen, fachlichen und ressourcenbezogenen Spezifikationen, die für eine automatische Steuerung des Arbeitsablaufes auf der operativen Ebene erforderlich sind. Die hierbei anzustoßenden Arbeitsschritte sind zur Ausführung durch Mitarbeiter oder durch Anwendungsprogramme vorgesehen. Ein wichtiger Unterschied zum Geschäftsprozess besteht darin, dass der Workflow beschreibt, wie und mit welchen Mitteln etwas umgesetzt werden soll. Ein Geschäftsprozess beschreibt dagegen, was zu tun ist, um eine vorgegebene Geschäftsstrategie umzusetzen [19]. (Das deutsche Wort Arbeitsablauf taucht in der Literatur nur selten auf, daher wird in dieser Arbeit der englische Begriff verwendet.) Worfklow-Management: Workflow-Management bezeichnet ein operatives Konzept zur Umsetzung der von der strategischen Unternehmensplanung vorgegebenen übergeordneten Geschäftsprozessziele. Zu diesem Zweck stellt das Workflow- Management Methoden und Werkzeuge zur computergestützten Analyse, Planung, Simulation, Steuerung und Überwachung von Arbeitsabläufen bereit [19]. Workflow-Management-Systeme (WfMS): Workflow-Management-Systeme automatisieren die Ausführung von Workflows und ermöglichen es, während der Durchführung von Workflows zur richtigen Zeit Fremdapplikationen aufzurufen, menschliche Interaktion zu erwarten und gleichzeitig die passenden Daten bereitzustellen [22]. Workflow-Management-Systeme werden durch Softwareplattform realisiert, die Design, Entwicklung, Ausführung und Analyse von Workflow-Prozessen unterstützt [10]. Geschäftsprozessmanagement (Business Process Management, BPM): Geschäftsprozessmanagement ist die funktionsübergreifende Gestaltung der Ablaufarchitektur eines Unternehmens durch Verkettung der wertschöpfenden Aktivitäten unter Integration von Führung, Organisation und Controlling der Prozesse mit dem Ziel, Strategieumsetzung und Erfüllung der Kundenerwartungen effektiv und effizient zu realisieren [23]. Geschäftsprozessmanagement-Systeme (BPMS): Diese Systeme dienen der Unterstützung des Geschäftsprozessmanagements. Das Workflow-Management-System stellt dabei eine Teilkomponente des Geschäftsprozessmanagement-Systems dar [20]. Copyright TU-Dresden, Nicolás Bleyh 16

25 Komplexe Web Services Wichtig ist die Unterscheidung der Begriffe Geschäftsprozess und Workflow. Während in einem Geschäftsprozess ein Ablauf in der Realität beschrieben wird, so bezeichnet ein Workflow die ausführbare Beschreibung eines Geschäftsprozesses in der Rechnerwelt [10]. Trotzdem werden in den meisten Kompositionssprachen Abläufe unter dem Term process anstatt workflow zusammengefasst (siehe Kapitel 4.1). Um Verwirrungen zu vermeiden, werden daher in dieser Arbeit die Begriffe Geschäftsprozess (bzw. Prozess) und Workflow synonym verwendet, auch wenn die theoretischen Definitionen nicht übereinstimmen. Eine Workflow kann über einen gerichteten Graphen spezifiziert werden, der die Ausführungsreihenfolge der am Workflow beteiligten Knoten definiert. In [10] werden die folgenden drei Bestandteile eines Workflow-Graphen genannt: Arbeitsknoten repräsentieren eine Aufgabe, die von einem Nutzer oder einer automatisierten Ressource ausgeführt werden soll. Dies entspricht der oben genannten Definition von Aktivitäten. Routing nodes definieren die Reihenfolge, in der die Aufgaben ausgeführt werden sollen. Diese erlauben die Definition von parallelen, sequentiellen oder konditionalen Aktivierungen von Arbeitsknoten. Start und End Knoten initialisierten bzw. beenden einen Geschäftsprozess. Es existieren jedoch noch zahlreiche weitere Vorgehensweisen, um einen Geschäftsprozess zu modellieren. Dazu gehören u.a. UML Aktivitäts- und Zustandsdiagramme oder Petri Netze. Beispiele für Beschreibungssprachen von Geschäftsprozessen sind die XML Process Definition Language (XPDL, [24]) von der WfMC und die Business Process Modeling Language (BPML) von der BPMI. BPMI hat zudem eine grafische Modellierungssprache für Geschäftsprozesse namens Business Process Modeling Notation (BPMN) entwickelt. Im Unterschied zu XPDL ist BPML für den Einsatz von Web Services konzipiert. Als Kompositionssprache für Web Services scheint sich aber die Business Process Execution Language (BPEL) durchgesetzt zu haben. BPEL liegt in der Verantwortung der Organization for the Advancement of Structured Information Standards (OASIS, [25]) und wird im Kapitel ausführlich besprochen. 3.2 Komposition Mit dem Aufkommen der Web-Service-Technologie wurde versucht, das Konzept von Workflows zu erweitern. Waren die Teilnehmer früherer Workflows vor allem menschliche Nutzer, so sollen nun auch Softwareanwendungen in den Geschäftsprozess integriert werden. Da bei Web Services deren Funktionalitäten über eine standardisierte Schnittstelle beschrieben und ansprechbar sind, können diese als Aktivitäten in die Beschreibung integriert werden. Abgesehen vom Einsatz in Workflows können durch eine Komposition auch mehrere Web Services zu einer neuen Anwendung zusammengefügt werden. Dadurch entsteht ein neues Programmierparadigma, in dem man zwischen programming in the large und programming in the small unterscheidet. Je nach Zeitpunkt, zu dem bekannt sein muss, welche konkreten Web Services in der Anwendung verwendet werden, unterscheidet man zwischen proaktiver und reaktiver Komposition. Proaktive Komposition bedeutet, dass die neue Anwendung bereits zur Entwicklungszeit komplett zusammengestellt ist, d.h. alle verwendeten Services sind a priori bekannt. Reaktive Komposition bezeichnet das dynamische Komponieren des neuen Dienstes, z.b. zu dem Zeitpunkt, zu dem er nachgefragt wird [17]. Um Web Services dynamisch zu komponieren, müs- Copyright TU-Dresden, Nicolás Bleyh 17

26 Komplexe Web Services sen diese eine maschinenlesbare semantische Beschreibung ihrer Dienste anbieten. Ein Ansatz hierfür ist beispielsweise OWL-S [26]. Bei der Komposition von Web Services unterscheidet man drei verschiedene Ansätze: die Choreographie, das Behavioral Interface und die Orchestration. Diese sollen im Folgenden erläutert werden Choreographie Eine Choreographie beschreibt eine Kollaboration zwischen mehreren Diensten, um ein gemeinsames Ziel zu erreichen. Es legt dabei die Interaktionen fest, welche die teilnehmenden Dienste ausführen müssen, um dieses Ziel zu erreichen. Zwischen den Interaktionen können Abhängigkeiten und Ablaufregeln festgelegt werden. Des Weiteren kann definiert werden, wie während des Nachrichtenaustausches mit mehreren Teilnehmern die Zustände verwaltet werden, so dass beispielsweise empfangene Antworten zu gesendeten Anfragen zugeordnet werden können [10]. Es handelt sich bei einer Choreographie also um eine Übereinkunft, auf die sich die beteiligten Partner einigen, um durch einen global definierten Ablauf ein gemeinsames (Geschäfts-) Ziel zu erreichen. Dabei beschreibt die Choreographie für jeden involvierten Partner den Teil, den derjenige in der Interaktion spielt [27]. Durch die globale Sicht auf die Interaktionen nehmen alle beteiligten Dienste gleichberechtigt an der Choreographie teil, d.h. es existiert keine übergeordnete, ausführende Instanz. Über die interne Prozesslogik der einzelnen Teilnehmer werden in einer Choreographie keine Angaben gemacht [17]. Die Abbildung 7 zeigt die Idee einer Choreographie. Dabei wird deutlich, dass die beteiligten Web Services autonom und selbst für die korrekte Beteiligung an der Choreographie zuständig sind. Abbildung 7: Choreographie Statt Choreographie ist in diesem Zusammenhang oftmals auch von Koordination oder Konversation die Rede. Die Beschreibung der Menge zulässiger Nachrichtenabfolgen wird Konversations-, Koordinations- oder (in [10]) Geschäftsprotokoll (business protocol) genannt. Beispiele für Choreographiebeschreibungssprachen sind WSCI und WS-CDL, auf die in den Kapiteln und eingegangen wird Behavioral Interface WSDL beschreibt lediglich einzelne Operationen von Web Services, nicht aber Nachrichtenabfolgen. Mit Hilfe des Modells des Behavioral Interface wird WSDL dahingehend erweitert, Copyright TU-Dresden, Nicolás Bleyh 18

27 Komplexe Web Services dass Abhängigkeiten zwischen Interaktionen festgelegt werden können. Dabei können Kontrollflussabhängigkeiten, Datenflussabhängigkeiten, Zeitbedingungen, Nachrichtenbeziehungen und transaktionale Abhängigkeiten definiert werden. Im Gegensatz zur Choreographie liegt beim Behavioral Interface der Fokus auf einem einzelnen Teilnehmer. Deshalb können damit auch keine kompletten Interaktionen festgelegt werden, weil ein Behavioral Interface immer nur die Nachrichtenabfolge eines Teilnehmers beschreibt. Wie Choreographien beschreibt auch ein Behavioral Interface keine internen Details wie z.b. Datentransformationen [28]. Beispiele für Beschreibungssprachen, mit denen ein Behavioral Interfaces beschrieben werden kann, sind WSCL und die abstrakten BPEL-Prozesse (siehe Kapitel 4.1.3) Orchestration Eine Orchestration beschreibt einen Geschäftsprozess aus der Sicht eines Teilnehmers. Diese beinhaltet Kommunikations- und interne Aktionen, deren Reihenfolge und Ausführungsbedingungen. Interne Aktionen können z.b. Datentransformationen oder Aufruf von internen Softwaremodulen sein, die nicht als Web Service angeboten werden. Kommunikationsaktionen sind dagegen Aufrufe an externe oder firmeneigene Web Services. In einer Orchestration können auch Kommunikationsaktionen oder Abhängigkeiten zwischen diesen enthalten sein, die nicht in der Beschreibung eines Behavioral Interface oder einer Choreographie auftauchen. Dies begründet sich durch die Tatsache, dass in Choreographien und Behavioral Interfaces nur die Informationen enthalten sind, die für alle Teilnehmer sichtbar sind. Da eine Orchestration aber die interne, nicht öffentliche Geschäftslogik aus der Perspektive einer kontrollierenden Instanz beschreibt, können interne Ablaufdetails formuliert werden. Die Abbildung 8 zeigt das Prinzip einer Orchestration. Abbildung 8: Orchestration Orchestrationen werden auch als ausführbare Prozesse (executable processes) bezeichnet, da sie meist zur Ausführung in einer Orchestrierungs-Engine verwendet werden [28]. Beispiele für Orchestrierungssprachen sind BPML und die ausführbaren BPEL-Prozesse (siehe Kapitel 4.1.3). 3.3 Szenarien für Benutzerinteraktionen Um die Unterschiede der in Kapitel 3.2 vorgestellten Kompositionsarten noch einmal zu vertiefen, werden im Folgenden zwei Szenarien vorgestellt. Dabei soll auch die Notwendigkeit von Benutzerinteraktionen innerhalb von komplexen Web Services verdeutlicht und so die Motivation für die folgenden Kapitel gegeben werden. Copyright TU-Dresden, Nicolás Bleyh 19

28 Komplexe Web Services Die beiden Szenarien unterscheiden sich darin, ob die Benutzerinteraktion Teil innerhalb eines Workflows ist, d.h. die Nutzerinteraktion ist notwendig, um den Workflow erfolgreich abzuarbeiten ( Task-orientierte Nutzerinteraktion ), oder ob der Nutzer den Workflow anstößt, d.h. der Workflow dient der Zielerreichung des Nutzers ( Ziel-orientierte Nutzerinteraktion ) Ziel-orientierte Nutzerinteraktion Als Beispiel für dieses Szenario soll eine (stark vereinfachte) Reisebuchung dienen, die in Ansätzen bereits in Kapitel 1 vorgestellt wurde. Die beteiligten Partner sind der Nutzer, ein Hotelagent, eine Fluggesellschaft und eine Bank, wobei Hotelagent, Fluggesellschaft und Bank jeweils einen Web Service darstellen. Zunächst schickt der Nutzer parallel eine Anfrage an den Hotelagent und die Fluggesellschaft mit Angabe des gewünschten Reisezeitraums, der Personenanzahl und des Zielortes. Für die Fluggesellschaft wird zusätzlich noch der Startort angegeben. Anhand der zurückgegebenen Angebote wählt der Nutzer ein passendes aus und schickt einen entsprechenden Buchungsauftrag an den Hotelagenten und die Fluglinie. Hotelagent und Fluggesellschaft schicken daraufhin eine Überweisungsaufforderung an die Bank. Diese bestätigt die Überweisung, woraufhin Hotelagent und Fluggesellschaft an den Nutzer eine Buchungsbestätigung schicken. Um das Szenario möglichst einfach zu halten, wird ein optimaler Ablauf des Geschäftsprozesses angenommen, d.h. Ausnahmefälle wie ein Abbruch des Ablaufs durch einen der Teilnehmer (z.b. wenn aufgrund von zu geringem Kontostand zwar eine Banküberweisung für den Flug, nicht aber für das Hotel durchgeführt werden kann) werden nicht betrachtet. Dieser vereinfachte Ablauf soll anhand eines UML- Aktivitätsdiagramms in der folgenden Abbildung verdeutlicht werden. Copyright TU-Dresden, Nicolás Bleyh 20

29 Komplexe Web Services Abbildung 9: Aktivitätsdiagramm für eine Reisebuchung Die Notwendigkeit einer Benutzerinteraktion wird bei der Auswahl eines passenden Fluges und Hotels deutlich. Hier muss eine Entscheidung getroffen werden, die sinnvollerweise nur durch einen menschlichen Benutzer getroffen werden kann. Mit Hilfe heutiger Kompositionssprachen ist es lediglich möglich, die Entscheidung zu automatisieren, z.b. indem immer die billigste Reise ausgewählt wird. Die Frage ist nun, was die Grundlage für die generische Beschreibung der Benutzeroberfläche ist. Es bieten sich dabei zwei Möglichkeiten an, die davon abhängen, auf welche Art der Geschäftsprozess aus Sicht des Kunden beschrieben ist. Dabei kann zwischen einem Behavioral Interface und einer Choreographie unterschieden werden. Ein Behavioral Interface legt lediglich den Ablauf der Operationsaufrufe eines Web Services fest. So können zahlreiche Abhängigkeiten zwischen den Operationen definiert werden, wie beispielsweise die Ausführungsreihenfolge oder Nachrichtenkorrelationen (wenn Operation A Copyright TU-Dresden, Nicolás Bleyh 21

30 Komplexe Web Services ein bestimmtes Ergebnis liefert, muss Operation B ausgeführt werden). Die eigentliche Komposition der einzelnen Web Services erfolgt dann über eine Orchestration. Das Behavioral Interface bietet, wie der Name schon sagt, nur eine Schnittstelle, über welche mit der Orchestration interagiert werden kann. Auf das Anwendungsszenario der Reisebuchung bezogen, müsste der Geschäftsprozess durch einen zusätzlichen Web Service (beispielsweise ein Reisebüro) gekapselt werden. Dieser Web Service kümmert sich um die Geschäftslogik und den Aufruf der beteiligten Web Services. Dies kann mit Hilfe einer Orchestrationssprache geschehen. Dem Nutzer wird lediglich eine Schnittstelle angeboten, damit er weiß, in welcher Reihenfolge er die angebotenen Operationen zur Buchung eines Fluges und eines Hotels aufrufen kann. Dieses Behavioral Interface wird vom Web Service des Reisebüros zur Verfügung gestellt und bietet die Grundlage für die dynamische Generierung der Benutzerschnittstelle. Abbildung 10: Szenario bei Verwendung eines Behavioral Interfaces Wird das Szenario dagegen mit Hilfe einer Choreographie realisiert, so entfällt der Web Service des Reisebüros. Stattdessen existiert ein Dokument, das den Geschäftsprozess aus einer globalen Sicht heraus beschreibt. Anhand dieses Dokuments können die beteiligten Teilnehmer ihr öffentliches Verhalten so implementieren, dass der Geschäftsprozess korrekt und erfolgreich ablaufen kann. Dieses Dokument wäre somit auch Grundlage für die dynamische Generierung der Benutzeroberfläche. Ein Beschreibungsstandard, mit dem Choreographien beschrieben werden können, ist die Web Service Choreography Description Language (WS- CDL). Auf diesen wird im Kapitel näher eingegangen. Abbildung 11: Szenario bei Verwendung einer Choreographie Copyright TU-Dresden, Nicolás Bleyh 22

31 Komplexe Web Services Task-orientierte Nutzerinteraktion Im zweiten hier vorgestellten Einsatzszenario zu menschlichen Benutzerinteraktionen in komplexen Web Services findet die Interaktion als Teil eines Workflows statt. Als Beispiel soll hier der komplexe Web Service einer Bank dienen, der zur Gewährung von Krediten dient. Übersteigt die Kreditsumme einen bestimmten Betrag, so muss ein verantwortlicher Bankangestellter entscheiden, ob der Kredit genehmigt wird oder nicht. Abbildung 12 zeigt das zugehörige Aktivitätsdiagramm. Abbildung 12: Szenario für eine Orchestration Bei diesem Anwendungsszenario handelt es sich um eine Orchestration, da der gesamte Ablauf von einer Instanz kontrolliert wird, nämlich der Orchestrierungs-Engine. Diese führt den Geschäftsprozess anhand einer Kompositionssprache aus. Die Problemstellung ist hier, wie aus dem Geschäftsprozess heraus Nutzer angesprochen werden können, die im Unterschied zur Ziel-orientierten Nutzerinteraktion keine Anfrage gestellt haben. Um dies zu ermöglichen, müssen in der Beschreibung des Geschäftsprozesses spezielle Tasks definiert werden, die der Orchestrierungs-Engine mitteilen, dass eine Benutzerinteraktion für das Fortführen des Geschäftsablaufes notwendig ist. Tritt im Geschäftsablauf ein so definiertes Task auf, so stellt die Orchestrierungs-Engine dem verantwortlichen Nutzer automatische eine grafische Benutzerschnittstelle (GUI) zur Abarbeitung der Aufgabe bereit. In der Syntax der bisherigen Kompositions- bzw. Orchestrierungssprachen (siehe Kapitel 4.1) existieren allerdings noch keine Sprachkonstrukte, wie die Integration von Benutzerinteraktionen in komplexe Web Services über Tasks realisiert werden können. Lediglich BPEL4PEOPLE (Kapitel 4.4.1) bietet dazu einen Ansatz. 3.4 Fazit Zwischen den drei vorgestellten Modellen gibt es einige Überschneidungspunkte. So kann eine Choreographie dazu verwendet werden, das Behavioral Interface der teilnehmenden Dienste zu bestimmen. Außerdem kann anhand des Behavioral Interface zur Laufzeit über- Copyright TU-Dresden, Nicolás Bleyh 23

32 Komplexe Web Services prüft werden, ob ein Dienst die Anforderungen einer gegebenen Choreographie erfüllt und festgestellt werden, welche Rolle er in dieser spielt. Ebenso ist es möglich, das Behavioral Interface als Grundlage für eine Orchestration zu verwenden. Das Behavioral Interface definiert dabei den Rahmen des Services, während über eine Orchestration die Details festgelegt werden [28]. Im Konzept dieser Arbeit wird vor allem untersucht, wie das Szenario der Ziel-orientierten Nutzerinteraktion realisiert werden kann, da einige Hersteller für die Task-orientierte Nutzerinteraktion bereits proprietäre Lösungen anbieten. Einige dieser Lösungen werden im Kapitel 4.4 kurz vorgestellt. Da es bei der Ziel-orientierten Nutzerinteraktion vor allem darum geht, wie eine Benutzerschnittstelle automatisch anhand der Beschreibung eines komplexen Web Service erstellt werden kann, ist insbesondere das Konzept des Behavioral Interface interessant. Hier wird festgelegt, in welcher Reihenfolge die angebotenen Operationen ausgeführt werden können und welche Bedingungen bzw. Abhängigkeiten mit den ausgetauschten Nachrichten verknüpft sind. Daher sollen die im folgenden Kapitel untersuchten Kompositionssprachen unter anderem darauf überprüft werden, inwiefern sie dieses Konzept unterstützen. Copyright TU-Dresden, Nicolás Bleyh 24

33 Existierende Lösungen 4 Existierende Lösungen In diesem Kapitel sollen existierende Lösungen und Technologien vorgestellt werden, die zur Erreichung von Benutzerinteraktionen in komplexen Web Services benötigt werden. Begonnen wird dabei mit Kompositionssprachen, die zur Definition von Geschäftsprozessen dienen. Anschließend wird darauf eingegangen, wie anhand der Schnittstellenbeschreibung eines Web Service eine grafische Benutzeroberfläche generiert werden kann. Zum Schluss findet sich eine kleine Übersicht über bereits bestehende Lösungen zur Integration von Benutzerinteraktionen in komplexe Web Services bzw. Geschäftsprozesse. 4.1 Kompositionssprachen Dieses Kapitel stellt einige wichtige Kompositionssprachen (die alle XML als Syntax verwenden) für Web Services vor. Dabei soll überprüft werden, ob sie sich als Grundlage für eine generische Benutzerschnittstellenbeschreibung eignen, bzw. inwiefern sie menschliche Nutzerinteraktionen unterstützen. In [27] werden folgende Anforderungen an Kompositionssprachen genannt: Flexibilität: Diese kann erreicht werden, indem eine klare Trennung zwischen der Prozesslogik und den verwendeten Web Services vorgenommen wird. So können bei Bedarf Prozesse leicht ausgelagert werden Elementare und strukturierte Aktivitäten: Es sollte die Unterscheidung zwischen elementaren Aktivitäten, wie beispielsweise der Aufruf eines externen Web Service, und strukturieren Aktivitäten, in denen der Prozessablauf festgelegt wird, gemacht werden. Rekursive Komposition: Ein komponierter Web Service kann selber Teil eines übergeordneten komponierten Web Services sein. Daher müssen komponierte Web Services bestimmte Eigenschaften erfüllen, um die Integrität und Konsistenz der Interaktionen zu sichern. Dazu gehören zum einen die Persistenz und die Korrelation. Bei der Komposition von Web Services ist es wichtig, Zustände persistent speichern und Anfragen zueinander in Korrelation stellen zu können. Zum anderen müssen komponierte Web Services Ausnahmen und transaktionale Integrität gewährleisen. So dürfen beispielsweise in einer lang andauernden Transaktion keine Ressourcen gesperrt werden. Bei den Kompositionssprachen treffen die Ideen der Service-orientierten Architekturen und des Geschäftsprozess-Managements (BPM) aufeinander. Durch Service-orientierte Architekturen lassen sich Design und Entwicklung einer Unternehmensanwendung modularisieren und in fachlich verschiedene Bereiche aufteilen. So können einzelne Fachbereiche ihre spezifischen Prozesse definieren und unabhängig voneinander modellieren, um diese dann anderen Unternehmensbereichen als Service zur Verfügung zu stellen. Mit Hilfe von Kompositionssprachen (deren Ursprünge aus dem BPM stammen) können Anwendungen wesentlich schneller entwickeln werden, da man nicht alle Business-Funktionen neu programmieren muss, sondern nur noch existierende Services neu zusammenstellt [6]. Um die Kompositionssprachen besser zu erläutern und auf ihre Eignung zu überprüfen, wird das Reisebuchungsszenario aus dem Kapitel erneut aufgegriffen. Allerdings wird aus Gründen der Vereinfachung auf den Teilnehmer Bank verzichtet. Somit besteht das Szenario aus drei Teilnehmern: dem Kunden, der Fluglinie und einem Hotelagenten. Die Fluglinie und der Hotelagent bieten Operationen zur Lieferung von Angeboten und zur Buchung an. Dabei kann der Kunde eine Reise erst buchen, wenn vorher ein Angebot eingeholt wurde. Da Flug und Hotel Bestandteil einer Reise sind, laufen die Anfragen an diese beiden Dienste immer Copyright TU-Dresden, Nicolás Bleyh 25

34 Existierende Lösungen parallel ab. Der Ablauf dieses Geschäftsprozesses ist in der Abbildung 9 grafisch dargestellt. Die späteren Code-Beispiele beziehen sich alle auf diesen Geschäftsprozess WSCI Mit WSDL ist es nur möglich, die von einem Web Service angebotenen Operationen mit ihren zugehörigen Ein- und Ausgabeparametern zu definieren. Es ist jedoch nicht möglich, beispielsweise die Reihenfolge anzugeben, in der die angebotenen Operationen ausgeführt werden sollen. Um dieser Problematik zu begegnen, entwickelten BEA, SAP, SUN und Intalio WSCI (Web Service Choreography Interface). Die Verantwortung für WSCI wurde an das W3C übergeben, wo WSCI als Note (also ohne normativen Anspruch) in der Version 1.0 vorliegt [29]. WSCI erweitert WSDL dahingehend, dass beschrieben werden kann, wie die durch WSDL definierten Operationen im Kontext der mit anderen Web Services ausgetauschten Nachrichten choreographiert werden sollen. Eine Schlüsseleigenschaft von WSCI ist, dass nur das beobachtbare Verhalten eines Web Services beschrieben wird. WSDL legt mittels der Operationen die Eingangspunkte des Web Services fest, während WSCI die Interaktionen zwischen diesen beschreibt. WSCI beschreibt den Ablauf sowohl aus der Sicht eines Teilnehmers, als auch aus der globalen Sicht. Dadurch, dass mehrere Teilnehmer jeweils mit Hilfe ihrer WSCI- Schnittstelle miteinander kollaborieren, wird eine Choreographie erreicht. Dieser Sachverhalt ist in der Abbildung 13 dargestellt. Im Gegensatz zu einer Orchestration existiert bei WSCI keine den Gesamtablauf kontrollierende Instanz [27]. Abbildung 13: Web Service Choreography Interface [27] Das beobachtbare Verhalten eines Web Services drückt sich in den temporalen und logischen Abhängigkeiten zwischen den mit anderen Web Services ausgetauschten Nachrichten aus. WSCI unterstützt daher die folgenden Schlüsselanforderungen, um einen lang andauernden, choreographierten und zustandsbehafteten Nachrichtenaustausch zu realisieren [29]: Message choreography: WSCI beschreibt die Reihenfolge, in der Nachrichten gesendet oder empfangen werden. Dazu dienen Regeln, die diese Reihenfolge steuern sowie Anfangs- und Endpunkte des Nachrichtenaustauschs. Transaction boundaries and compensation: Es kann definiert werden, welche Operationen als Transaktion ausgeführt werden. Damit werden die anderen Teilnehmer darüber informiert, dass diese Operationenabfolge ganz oder gar nicht ausgeführt wird. Copyright TU-Dresden, Nicolás Bleyh 26

35 Existierende Lösungen Außerdem ermöglicht diese Eigenschaft dem Web Service, als Teil innerhalb einer Transaktion mit anderen Web Services teilzunehmen. Wie der Web Service die Transaktion durchführt (z.b. als 2-Phasen Commit) wird in WSCI nicht festgelegt. Es wird lediglich mitgeteilt, ob der Web Service Transaktionsmechanismen unterstützt. Exception handling: Hiermit wird die Reaktion des Web Service bei einer Ausnahmebzw. Fehlersituation beschrieben, indem alternative Ablaufanweisungen angegeben werden können. Thread management: WSCI beschreibt, ob und wie ein Web Service mehrere Konversationen gleichzeitig führen kann. Außerdem kann der Zusammenhang zwischen den verschiedenen, zur selben Konversation gehörenden Nachrichten beschrieben werden. Wie der Web Service den parallelen Ablauf mehrere Konversationen realisiert, kann nicht durch WSCI festgelegt werden. Properties and Selectors: Mittels WSCI können Elemente der ausgetauschten Nachrichten festgelegt werden, die das beobachtbare Verhalten des Web Service beeinflussen. Connectors: Mit WSCI kann festgelegt werden, wie die Operationen verschiedener Web Services in einem Nachrichtenaustausch zueinander in Beziehung stehen. Dazu dient das so genannte Global Model, mit dem aus globaler Sicht die Interaktion verschiedener Web Services beschrieben wird. Ein Global Model besteht aus einer Sammlung von WSCI-Schnittstellen der beteiligten Web Services und einer Liste von Verbindungen zwischen WSDL-Operationen. Verbindungen zwischen Operationen zeigen an, dass zwischen diesen Operationen ein direkter Nachrichtenfluss stattfindet. So können beispielsweise die ausgehenden Nachrichten eines Teilnehmers mit den eingehenden Nachrichten eines anderen Teilnehmers assoziiert werden. Operational context: WSCI beschreibt, wie sich derselbe Web Service im Kontext unterschiedlicher Nachrichtenaustausche verhält. Mit WSCI kann folglich sowohl das Behavioral Interface der einzelnen Web Services und, durch das Global Model, eine Choreographie beschrieben werden. Eine Orchestration ist allerdings nicht möglich. Deshalb wird im Zusammenhang mit WSCI oftmals BPML (Business Process Modeling Language) erwähnt. BPML wurde von der BPMI ins Leben gerufen und besitzt starke Ähnlichkeiten mit BPEL [30], ist also ebenfalls eine Orchestrierungssprache. Allerdings hat sich hier BPEL durchgesetzt, weshalb auf den BPML-Standard in dieser Arbeit nicht näher eingegangen wird. Auch wenn mit WSCI ein interessanter Ansatz verfolgt wird, so konnte sich dieser scheinbar nicht durchsetzen. Ein Grund hierfür ist, dass die Kompositionssprache BPEL, die eine große Unterstützung durch die IT-Industrie erfährt, mit dem Konzept von abstrakten Prozessen e- benfalls eine Beschreibung für das beobachtbare Verhalten (Behavioral Interface) eines Web Services bietet. WSCI erreichte beim W3C auch nie den Stand einer Empfehlung, die letzte Note stammt vom 8. August Ebenso existieren keine frei verfügbaren Autorenwerkzeuge zur Erstellung von WSCI-Beschreibungen. Aufgrund dieser Tatsachen scheidet WSCI als Grundlage für eine generische Benutzerschnittstellenbeschreibung für komplexe Web Services aus. Das Konzept von WSCI als Choreographiebeschreibungssprache wurde jedoch in WS-CDL integriert und weiterentwickelt WS-CDL WS-CDL (Web Service Choreography Description Language) ist eine klassische Choreographiesprache (siehe Kapitel 3.2.1) und beschreibt aus einer globalen Sichtweise heraus die Kollaboration mehrerer Teilnehmer, indem das öffentliche Verhalten (also der Nachrichtenaustausch zwischen den Teilnehmern) definiert wird. Mit Hilfe von WS-CDL ist somit ein Copyright TU-Dresden, Nicolás Bleyh 27

36 Existierende Lösungen technischer Vertrag möglich, in dem die Komposition der beteiligten Teilnehmer beschrieben wird. Jeder Teilnehmer kann diese globale Definition verwenden, um vertragskonforme Lösungen zu implementieren. Vorteil dieses Ansatzes ist, dass von der internen Prozesslogik eines Teilnehmers abstrahiert werden kann. Solang die öffentlichen Schnittstellen unverändert bleiben, kann die interne Prozesslogik verändert werden, ohne dass dies Auswirkungen auf die Gesamtchoreographie hat. Ein weiterer Vorteil ist, dass Unternehmen normalerweise ihre Prozesslogik nicht unter die Kontrolle eines anderen Teilnehmers stellen möchten. WS-CDL wird vom W3C entwickelt und liegt momentan als Recommendation in der Version 1.0 vor. Im Folgenden sind die in [31] definierten Ziele von WS-CDL aufgelistet: Wiederverwendbarkeit: Dieselbe Choreographiedefinition kann von mehreren Teilnehmern verwendet werden, die jeweils in verschiedenen Umgebungen und mit unterschiedlicher Software agieren. Kooperation: Choreographien beschreiben die Sequenz des Nachrichtenaustausches zwischen zwei oder mehreren Teilnehmern. In die Choreographie kann eine beliebige Anzahl von Teilnehmern oder Prozessen mit einbezogen werden. Semantiken: Menschenlesbare Dokumentationen und Semantiken können für alle Komponenten beigefügt werden. Komposition: Existierende Choreographien können zu neuen Choreographien zusammengesetzt werden. Modularität: über ein inclusion -Konstrukt kann eine Choreographie aus Teilen verschiedener anderer Choreographien aufgebaut werden. Informationsgetriebene Kollaboration: Choreographien beschreiben, wie Teilnehmer innerhalb einer Kollaboration voranschreiten, indem die ausgetauschten Informationen und die Veränderungen im beobachtbaren Verhalten gespeichert werden. Informationsabgleich: Choreographien erlauben es den Teilnehmern, zu kommunizieren und ihre beobachtbaren Informationen zu synchronisieren. Fehlerbehandlung: Choreographien beschreiben, wie Ausnahmesituationen während der Choreographie behandelt werden. Transaktionen: Die Prozesse der beteiligten Teilnehmer können auf transaktionale Weise zusammenarbeiten. Da WS-CDL momentan der einzig aktiv verfolgte Ansatz zur Beschreibung von Choreographien ist, soll wie auch bei BPEL eine kleine Einführung in den Standard gegeben werden. Dabei wird das im Kapitel 4.1 vorgestellte Beispiel verwendet. Ein WS-CDL-Dokument ist eine Sammlung von Definitionen mit dem Wurzelelement package. Zunächst müssen die Rollen (z.b. Käufer) der Choreographie definiert werden. Dies geschieht über das Element roletype. Das Verhalten der Rollen wird über das behavior- Element spezifiziert. Es kann das Attribut interface besitzen, welches die entsprechende WSDL-Beschreibung des Teilnehmers angibt. Wird dieses Attribut nicht verwendet, so handelt es sich bei dem Teilnehmer um keinen Web Service. Im Quellcode 1 werden die Rollen des Kunden und der Fluglinie definiert, wobei nur die Rolle der Fluggesellschaft einen Web Service anbietet. Copyright TU-Dresden, Nicolás Bleyh 28

37 Existierende Lösungen <roletype name="clientrole"> <behavior name="clientforairline"/> <behavior name="clientforhotel"/> </roletype> <roletype name="airlinerole"> <behavior name="airlineforclient" interface="airline.wsdl"/> </roletype> Quellcode 1: Definition der Rollen in WS-CDL Als nächstes müssen die Relationen zwischen diesen Rollen festgelegt werden. Dies geschieht über das Elemente relationshiptype, welches genau zwei roletype-elemente beinhaltet. Diese verweisen über die Attribute typeref und behavior auf die Rolle und das Verhalten des Teilnehmers in dieser Relation. Der folgende WS-CDL Ausschnitt definiert eine Relation zwischen dem Kunden und der Fluggesellschaft. <relationshiptype name="client2airlinerelation"> <roletype typeref="clientrole" behavior="clientforairline"/> <roletype typeref="airlinerole"/> </relationshiptype> Quellcode 2: Relationen zwischen Rollen in WS-CDL Um die Kommunikationswege zwischen den Rollen zu beschreiben, werden channeltypes benötigt. Über das Element roletype wird angegeben, welcher Teilnehmer der Dienstanbieter ist. Das reference-element enthält einen token, der wiederum den Endpunkt des Dienstanbieters, z.b. in Form einer URL angibt. Im Beispiel wird der channeltype der Fluggesellschaft und der über einen token definierter zugehöriger Endpunkt festgelegt. Dabei handelt es sich um eine Kommunikation mit Anfrage- und Antwortnachricht (requestrespond), was über das Attribut action angegeben wird. <token name="airlineref" informationtype="uritype"/> <channeltype name="airlinechanneltype" action="request-respond"> <roletype typeref="airlinerole"/> <reference> <token name="airlineref"/> </reference> </channeltype> Quellcode 3: Definition der Kommunikationswege in WS-CDL Bevor mit der Beschreibung der eigentlichen Choreographie begonnen werden kann, müssen zunächst noch die verwendeten Datentypen definiert werden. Dies geschieht mit den Elementen informationtype. Über das Attribut type wird der Datentyp angegeben. Dabei kann auch auf einen Datentyp verwiesen werden, der in einer WSDL-Beschreibung definiert ist. Im Quellcode 4 wird ein Datentyp angegeben, welcher in der Schnittstellenbeschreibung der Fluggesellschaft beschrieben ist. <informationtype name="getflightstype" type="airline:getflights"/> Quellcode 4: Definition eines Datentypen in WS-CDL Innerhalb des choreography-elements wird die Kollaboration zwischen den Teilnehmern definiert. Um diese zu beschreiben, existieren verschiedene Aktivitätselemente: Copyright TU-Dresden, Nicolás Bleyh 29

38 Existierende Lösungen sequence, parallel, choice: Dabei handelt es sich um so genannte ordering structures. Diese geben die Reihenfolge vor, in der die einzelnen Aktivitäten ausgeführt werden sollen. workunit: Hiermit wird eine einzelne Aktivität beschrieben, die über eine Schleife wiederholt abgearbeitet werden kann. Außerdem können Bedingungen zur Ausführung angegeben werden. interaction: Dieses Element beschreibt den Nachrichtenaustausch zwischen den Teilnehmern. perform: Mit diesem Element können andere Choreographien rekursiv aufgerufen werden. assign: Dieses Element dient der Zuweisung von Werten zu Variablen. noaction, silentaction: Damit werden Punkte in einer Choreographie beschrieben, in der ein Teilnehmer entweder keine Aktion (noaction) ausführt bzw. die Abarbeitung der Aktion den Rest der Choreographie nicht beeinflusst und daher nicht öffentlich ist (silentaction). Um die Notation einer Choreographie etwas zu verdeutlichen, wird im folgenden Quellcode der (vereinfachte) parallele Ablauf einer Anfrage an den Web Service eines Hotelagenten und einer Fluggesellschaft beschrieben (siehe zum Vergleich mit BPEL Kapitel 4.1.3). Zunächst müssen die in der Choreographie verwendeten Relationen und Variablen definiert werden. Dabei werden die bereits im Quellcode 2 und Quellcode 4 definierten relationshiptypeund informationtype-elemente verwendet. Nun folgt mit der Definition der parallelen Ausführung zweier Interaktionen die eigentliche Choreographie. Innerhalb der Interaktionen werden die beteiligten Rollen festgelegt. Außerdem wird angegeben, welche Variable an den Dienst gesendet und welche empfangen wird. WS-CDL stellt dafür die Operation getvariable zur Verfügung, über die mit Angabe des Rollen- und Variablennamens die gesendeten bzw. empfangenen Werte ausgelesen werden können. <choreography name="travel" root="true"> <relationship type="airlinerelation"/>... <variabledefinitions> <variable name="getflights" informationtype="getflightstype"/>... </variabledefinitions> <parallel> <interaction channelvariable="airlinechannel" name="getflightsinteraction" operation="getflights"> <participate toroletyperef="airlinerole" relationship Type="client2airlineRelation" fromroletyperef="clientrole"/> <exchange action="request" name="requestairline" information Type="getFlightsType"> <send variable="cdl:getvariable(getflights, clientrole)"/> <receive variable="cdl:getvariable(getflights, airlinerole)"/> </exchange> </interaction>... </parallel> </choreography> Quellcode 5: Beispiel einer mit WS-CDL beschriebenen Choreographie In vielen Bereichen wie beispielsweise im E-Commerce verlaufen die Geschäftsprozesse über Unternehmensgrenzen hinweg. Bei der Umsetzung dieser Geschäftsprozesse mit Hilfe einer Orchestrierungssprache (wie z.b. mit BPEL) würde jeder der beteiligten Dienste eine Or- Copyright TU-Dresden, Nicolás Bleyh 30

39 Existierende Lösungen chestrierungs-engine benötigen, die zur Realisierung der Komposition parallel ablaufen müssten. Dies führt zu einer starken Erhöhung der Komplexität des Gesamtsystems. Hier liegt der klare Vorteil von WS-CDL, da eine globale Sicht des Geschäftsablaufs beschrieben und dadurch die Abhängigkeiten zwischen den verschiedenen, unternehmensinternen Prozessen kontrolliert werden können [32]. Mit WS-CDL-Beschreibungen können somit Codeskelette für Web Services oder abstrakte BPEL-Prozesse generiert werden. WS-CDL stellt eine abstraktere Beschreibung von Geschäftsprozessen zur Verfügung, so dass sie nicht zwangsweise auf der Web-Service-Technologie basieren muss. Allerdings wird durch diese Abstraktion die ohnehin umfangreiche WS-CDL-Spezifikation noch komplexer und schwerer anzuwenden. Hinzu kommt, dass WS-CDL praktisch keine Herstellerunterstützung genießt [33]. Ohne geeignete Autorenwerkzeuge wird es daher sehr schwer möglich sein, diesen Standard durchzusetzen und zu verbreiten BPEL BPEL (Business Process Execution Language) ist eine Prozessbeschreibungssprache für Web Services. Ziel von BPEL ist die Modellierung von Geschäftsprozessen auf Basis elementarer Web Services. Damit können vorhandene Web Services zu einem neuen Dienst komponiert werden. Die Erstellung komponierter Web Services durch BPEL rückt das zweistufige Programmieren (bzw. metaprogramming) in das Zentrum des Programmiermodells für Web Services: Klassische Programmiersprachen werden verwendet, um nichtzusammengesetzte Web Services zu erstellen (programming in the small), BPEL wird verwendet, um neue Web Services aus bestehenden zusammenzusetzen (programming in the large) [4]. BPEL geht aus den beiden Kompositionssprachen WSFL (Web Services Flow Language) und XLANG hervor, die von IBM bzw. Microsoft entwickelt wurden. Standardisiert und weiterentwickelt wird BPEL von OASIS (Organization for the Advancement of Structured Information Standards). Zurzeit liegt BPEL in der Version 1.1 unter der Bezeichnung BPEL4WS (BPEL for Web Services) vor. Für die Version 2.0 wird der Name erneut umbenannt, und zwar in WS-BPEL. Um Verwirrungen zu vermeiden, wird in dieser Arbeit der ursprüngliche Name BPEL verwendet. BPEL stellt Sprachkonstrukte zur Verfügung, mit denen Geschäftsprozesse in Form einer Abfolge von Aktivitäten modelliert werden können (zu den theoretischen Grundlagen zur Beschreibung eines Workflows bzw. Geschäftsprozesses siehe Kapitel 3.1). Gemäß der BPEL-Syntax wird im Folgenden der Term Prozess (process) für einen Geschäftsprozess verwendet. BPEL unterscheidet zwischen zwei Arten von Prozessen: ausführbaren (executable) und abstrakten (abstract) Prozessen. Ausführbare Prozesse definieren den internen Ablauf eines Geschäftsprozesses und werden innerhalb einer Organisation ausgeführt. Dazu wird eine BPEL-Engine benötigt, die den ausführbaren BPEL-Code verarbeitet. Hier wird das Konzept der Orchestration (Kapitel 3.2.3) realisiert, da der gesamte Ablauf von einer Instanz gesteuert wird. Abstrakte Prozesse sind dagegen nicht ausführbar. Sie dienen dazu, das Geschäftsprotokoll aus der Sicht eines Partners zu beschreiben. Dabei wird der sichtbare Nachrichtenaustausch zwischen den Partnern spezifiziert. Das interne Verhalten der beteiligten Partner bleibt dagegen transparent [34]. Es handelt sich dabei um das Konzept des Behavioral Interface (Kapitel 3.2.2). Im Folgenden soll mit Hilfe des in Kapitel 4.1 vorgestellten Szenarios eine kleine Einführung in die BPEL-Spezifikation gegeben werden. Copyright TU-Dresden, Nicolás Bleyh 31

40 Existierende Lösungen Das Wurzelelement eines BPEL-Dokuments ist process. Über das Attribut abstractprocess wird angegeben, ob es sich um einen abstrakten oder ausführbaren Prozess handelt. Eine vereinfachte Prozessbeschreibung besteht aus den drei Bereichen partnerlinks, variables und dem eigentlichen Prozessablauf. Über das Element partnerlinks wird beschrieben, welche Teilnehmer (im Beispiel: Kunde, Fluglinie, Hotelagent) in den Prozess involviert sind und welche Rolle (im Beispiel: Airline_Role, HotelAgent_Role) sie dort spielen. Dies wird durch das Element partnerrole angegeben. Über das Attribut parterlinktype wird der mit dieser Rolle assoziierte Web Service referenziert. Die partnerlinktype-elemente sind eine von BPEL eingeführte Erweiterung von WSDL. Sie definieren zwei Rollen eines bilateralen Nachrichtenaustausches und deren porttypes. Damit ist es möglich, Rollen zu WSDL porttypes zuzuordnen. Im Quellcode 6 wird über das Namensraumpräfix air bzw. hotel auf die entsprechenden WSDL- Beschreibungen verwiesen. <partnerlinks> <partnerlink name="airline" partnerrole="airline_role" partnerlinktype="air:airline_pl"/> <partnerlink name="hotelagent" partnerrole="hotelagent_role" partnerlinktype="hotel:hotelagent_pl"/>... </partnerlinks> Quellcode 6: Definition der Teilnehmer in BPEL Der Zustand eines Geschäftsprozesses wird über variable-elemente gesteuert. Diese können Daten der Prozesslogik oder der ausgetauschten Nachrichten beinhalten. Erhält ein Prozess eine Nachricht, so werden die übergebenen Daten in die angegebene Variable geschrieben, so dass diese im weiteren Verlauf ausgewertet werden kann. Als Datentyp kann entweder ein Standard XML-Schema-Typ (Attribut type), die Definition einer WSDL-Nachricht (Attribut messagetype) oder ein Element einer WSDL-Nachricht (Attribut element) angegeben werden. Quellcode 7 zeigt die Definition von zwei Variablen, wobei als Datentyp eine WSDL-Nachricht angegeben ist. <variables> <variable name="hotelrequest" messagetype="hotel:gethotelsrequest"/> <variable name="hotelresponse" messagetype="hotel:gethotelsresponse"/>... </variables> Quellcode 7: Definition von Variablen in BPEL Ein BPEL-Prozess wird in Instanzen ausgeführt. Damit mehrere Instanzen parallel ausgeführt werden können, müssen diese durch eine eindeutige ID identifiziert werden. Die Definition einer solchen ID geschieht in einem correlationset. Dabei wird über das Attribut properties ein WSDL-Datentyp angegeben, der in den ausgetauschten Nachrichten enthalten ist und die zugehörige BPEL-Instanz identifiziert. Jede Aktivität, die Nachrichten empfängt (invoke, receive), kann ein so definierter correlationset zugewiesen werden. Das Attribut initiate legt dabei fest, ob die correlationset bereits initialisiert wurde, oder dies mit der empfangenen Nachricht geschieht. Der folgende Quellcode zeigt die Definition eines correlationsets. Im Quellcode 9 wird gezeigt, wie ein correlationset einer empfangenen Nachricht zugewiesen wird. Copyright TU-Dresden, Nicolás Bleyh 32

41 Existierende Lösungen <correlationsets> <correlationset name="usercorrelation" properties="client:userid"/> </correlationsets> Quellcode 8: Definition eines correlationset Die eigentliche Beschreibung des Prozessablaufes besteht aus elementaren Aktivitäten (basic activities) und daraus zusammengesetzten strukturierten Aktivitäten (structured activities). Elementare Aktivitäten sind die folgenden [34]: empty: Stellte eine leere Aktion dar. invoke: Definiert einen asynchronen Aufruf einer WSDL-Operation. receive: Mit dieser Aktivität wartet der Prozess auf den Empfang einer Nachricht. reply: Sendet eine Nachricht als Antwort auf die durch eine receive-aktivität erhaltene Anfrage. assign: Weist einem variable-element einen Wert zu, wobei dieser über XPath- Funktionen zusätzlich manipuliert werden kann. wait: Der Prozess wird für eine angegeben Zeit angehalten. throw: Wirft eine Fehlermeldung aus. terminate: Beendigt mit sofortiger Wirkung den Prozess. compensate: Setzt bereits ausgeführte Aktivitäten zurück. Mit Hilfe der strukturieren Aktivitäten wird der Kontrollfluss des Prozesses beschreiben. Sie können elementare Aktivitäten oder wieder strukturierte Aktivitäten beinhalten. flow: Führt Aktivitäten parallel aus. sequence: Führt Aktivitäten sequentiell aus. pick: Mit Hilfe dieses Konstrukts kann eine Sammlung von Nachrichten angegeben werden. Sobald den Prozess eine der angegebenen erreicht, werden die innerhalb des pick-konstruktes enthaltenen Aktivitäten ausgeführt. while: Die Aktivitäten werden solange in einer Schleife ausgeführt, bis ein angegebenes Kriterium erfüllt ist. switch: Anhand eines Kriteriums wird exakt eine der aufgelisteten Aktivitäten ausgeführt. scope: Mit diesem Elemente können mehrere Aktivitäten zusammengefasst werden, um diesen einen gemeinsamen faulthandler oder compensationhandler zuzuweisen, der bei einem innerhalb des scope-elements ausgelösten Ausnahmeereignis ausgeführt wird. Die Sprachelemente von BPEL sind in der Abbildung 14 noch einmal zusammengefasst dargestellt. Copyright TU-Dresden, Nicolás Bleyh 33

42 Existierende Lösungen Abbildung 14: Hauptelement von BPEL Der folgende Codeausschnitt zeigt die BPEL-Beschreibung eines Teilablaufs bei der Einholung eines Reiseangebots. Dieser besteht aus den parallel ausgeführten synchronen Aufrufen der Dienste der Fluggesellschaft und des Hotelagenten. Dabei wird der porttype und der Operationsname des Web Services angegeben. Über die Attribute inputvariable und outputvariable wird dem Prozess mitgeteilt, welchen Variablen die empfangenen bzw. gesendeten Nachrichten zugewiesen werden sollen. Zusätzlich werden die empfangenen Nachrichten dem in Quellcode 8 definierten correlationset zugewiesen. <flow> <invoke name="invokehotelagent" partnerlink="hotelagent" porttype="hotel:hotelagent" operation="gethotels" inputvariable="hotelrequest" outputvariable="hotelresponse"> <correlations> <correlation initiate="no" set="usercorrelation"/> </correlations> </invoke> <invoke name="invokeairline" partnerlink="airline" porttype="air:airline" operation="getflights" inputvariable="airlinerequest" outputvariable="airlineresponse"> <correlations> <correlation initiate="no" set="usercorrelation"/> </correlations> </invoke> </flow> Quellcode 9: Mit BPEL beschriebener Teilablauf einer Reisebuchung Zur Prozessbeschreibung greift BPEL auf WSDL und die Standard XML-Schema-Definition zurück. BPEL und WSDL stehen auf folgende Art und Weise zueinander in Relation [35]: Jeder BPEL-Prozess besitzt als öffentliche Ein- und Ausgangspunkte eine WSDL- Beschreibung, wodurch er als Web Service veröffentlicht wird. Außerdem werden die WSDL-Beschreibungen externer Web Services verwendet, um diese aus dem Prozess heraus ansprechen zu können. Die in den WSDL-Beschreibungen definierten Datentypen können im BPEL-Prozess verwendet werden. Copyright TU-Dresden, Nicolás Bleyh 34

43 Existierende Lösungen Der BPEL-Standard wird oftmals mit den Spezifikationen von BPML und WSCI verglichen (z.b. in [17]), wobei mit BPML die ausführbaren BPEL-Prozesse dargestellt werden können, während die abstrakten BPEL-Prozesse den WSCI-Beschreibung entsprechen. Dies ist mit Bezug auf den WSCI-Vergleich jedoch nicht korrekt, da es mit WSCI auch möglich ist, eine Choreographie aus der Sicht aller Teilnehmer zu beschreiben [36]. Im Jahr 2006 soll die nächste Evolutionsstufe von BPEL veröffentlicht werden und zwar unter dem Namen WS-BPEL 2.0. Dort wird unter anderem das Konstrukt der Unterprozesse (sub-processes) eingeführt. Damit können Abhängigkeiten zwischen Vater- und Unterprozessen definiert werden, womit z.b. die Nutzung gemeinsamer Ressourcen ermöglicht wird [37]. Eine Erweiterung um Elemente zur Beschreibung von menschlichen Interaktionen ist jedoch auch in der Version 2.0 nicht vorgesehen [38]. Nach dem momentanen Stand der Dinge wird sich BPEL wohl als Standard für die Komposition von Web Services durchsetzten. Dies liegt vor allem an der massiven Unterstützung durch die IT-Industrie, vor allem der wichtigsten Hersteller von Web-Service-Lösungen, IBM und Microsoft [8]. Aus diesem Grund gibt es für BPEL im Gegensatz zu den anderen Kompositionssprachen bereits eine größere Anzahl von kommerziellen und Open-Source- Werkzeugen, um BPEL-Prozesse zu erstellen und auszuführen Vergleich und Bewertung WS-CDL und insbesondere BPEL sind zurzeit die bekanntesten und am weitest verbreiteten Kompositionssprachen zur Aggregation von Web Services. Es existieren allerdings noch weitere Ansätze zur Beschreibung komplexer Web Services. Erwähnt werden soll hier WSCL und das RosettaNet Projekt. WSCL steht für Web Service Conversation Language und wurde ursprünglich von HP entwickelt, dann aber in die Verantwortung des W3C übergeben. Es erweitert WSDL dahingehend, dass die erlaube Reihenfolge des Nachrichtenaustausches beschrieben werden kann. Allerdings sind die von WSCL angebotenen Möglichkeiten sehr eingeschränkt. So können lediglich sequentielle Abläufe definiert werden. WSCL liegt als Note in der Version 1.0 vor und wurde zuletzt am 14. März 2002 aktualisiert [39], womit dieser Ansatz wohl nicht weiter verfolgt wird. RosettaNet [40] ist ein Konsortium mit über 500 Unternehmen, das Standards zum elektronischen Geschäftsverkehr entwickelt. Ein Bestandteil von RosettaNet sind die so genannten Partner Interface Processes (PIP), womit Standard-Nachrichten und -Choreographien bezeichnet werden, die einen bestimmten Geschäftsprozess (wie beispielsweise eine Bestellung) beschreiben. Außerdem wird über Dictionaries das in den Nachrichten verwendete Vokabular standardisiert. Der dritte Bestandteil von RosettaNet ist das RosettaNet Implementation Framework (RNIF). Dieses beinhaltet Spezifikationen, um Sicherheit und Vertrauen im Nachrichtenaustausch zu gewähren. Dabei wird definiert, wie Daten gesendet, transportiert und empfangen werden [41]. Im Unterschied zu den bisher besprochenen Kompositionssprachen (bis auf WS-CDL) basiert RosettaNet jedoch nicht auf der Web-Service-Technologie. Außerdem ist es nicht möglich, eine eigene Choreographie zu spezifizieren, sondern es wird mit den PIP lediglich eine umfangreiche Sammlung von fest definierten Geschäftsprozessbeschreibungen angeboten, die als Standard Choreographien bezeichnet werden können [28]. Anhand der bisherigen Betrachtung der vorgestellten Kompositionssprachen liegt der Fokus dieser Arbeit auf den Spezifikationen von BPEL und WS-CDL. Diese werden als Grundlage Copyright TU-Dresden, Nicolás Bleyh 35

44 Existierende Lösungen für die Generierung einer Benutzerschnittstelle weiter verfolgt. Zusammenfassend sollen diese beiden Kompositionssprachen noch einmal voneinander abgegrenzt und bewertet werden. Vergleicht man die Syntax der beiden Standards, so stimmen die Semantiken zahlreicher Aktivitäten überein. Diese Ähnlichkeiten wurden in der Arbeit [42] ermittelt, um sie als Grundlage für eine automatische Überführung von WS-CDL- in BPEL-Beschreibungen und umgekehrt zu verwenden. Trotz einiger Gemeinsamkeiten kann diese Transformation jedoch nicht vollständig vorgenommen werden. Der Hauptunterschied liegt darin, dass mit WS-CDL Choreographien beschrieben werden können, während BPEL den Schwerpunkt auf die Orchestration legt. Mit BPEL kann daher lediglich die Sicht eines Teilnehmers auf den Nachrichtenaustausch abgebildet werden, während WS-CDL eine globale Sicht anbietet. WS-CDL definiert reagierende Regeln, die von jedem Teilnehmer genutzt werden, um den aktuellen Stand der Choreographie und den Fortlauf des Nachrichtenaustausch zu ermitteln. BPEL definiert aktive Regeln, die ausgeführt werden, um die nächsten Aktionsschritte zu ermitteln [43]. Interessant an BPEL sind die abstrakten Prozesse, womit es im Gegensatz zu WS-CDL möglich ist, das Behavioral Interface eines Web Service zu beschreiben. Für BPEL bieten zahlreichen IT-Unternehmen Werkzeuge zur Erstellung und Ausführung von in der BPEL-Syntax modellierte Geschäftsprozesse sowie Lösungen zur Integration der BPEL-Technologie in bestehende Systeme an. Im Gegensatz dazu gibt es für den WS-CDL- Standard praktisch keine Herstellerunterstützung [33]. Die einzigen Open-Source- Autorenwerkzeuge für WS-CDL sind pi4soa [44] und wscdl-eclipse [45]. Bei beiden handelt es sich um Eclipse-Plugins, mit denen der Erstellungsprozess von WS-CDL-Dokumenten erleichtert wird. Allerdings weist die in pi4soa verwendete Syntax erhebliche Divergenzen zum vom W3C definierten Standard auf. Das Werkzeug wscdl-eclipse besitzt dafür keine graphischen Hilfsmittel, um die Beschreibung anzulegen. Möglich ist zwar eine grafische Darstellung des definierten Ablaufs, allerdings stellte sich beim Testen des Werkzeuges heraus, dass diese Funktion noch sehr unzureichend bzw. fehlerhaft implementiert ist. Trotz dieser Unzulänglichkeiten und des klaren Vorteils von BPEL im Bereich von Autorenumgebungen soll versucht werden, für beide Kompositionssprachen eine Konzeptidee zu finden, wie WS-CDL bzw. BPEL in ein Modell zur Generierung von Benutzerschnittstellen für komplexe Web Services integriert werden kann. 4.2 Generische Benutzerschnittstellenbeschreibung Um heutzutage einen Web Service über eine menschliche Benutzerinteraktion aufrufen zu können, muss auf der Entwicklerseite zuerst eine entsprechende grafische Oberfläche implementiert werden. Dies beinhaltet jedoch zahlreiche Nachteile. So muss für den Aufruf jedes einzelnen Web Services eine neue Clientanwendung geschrieben werden. Da die Schnittstellenbeschreibung eines Web Services jedoch alle benötigten Informationen wie Eingabe-, Ausgabeparameter und deren Datentypen beinhaltet, bietet es sich an, das Benutzerinterface generisch anhand der WSDL zu erstellen. Allerdings stellt die WSDL-Beschreibung keine Anhaltspunkte bereit, wie die Benutzerschnittstelle formatiert werden soll. So gibt es mehrere Möglichkeiten, um aus einer Liste einen Datensatz auszuwählen. Dies kann z.b. über Checkboxen, Radiobuttons oder eine Auswahlliste erfolgen. Außerdem beschreibt WSDL keine Semantiken der Funktionen oder deren Ein- und Ausgabeparameter. Der Nutzer erhält zwar eine korrekte Eingabemaske, als Beschriftung werden jedoch die Bezeichnungen der WSDL-Beschreibung übernommen, die meistens aus Programmierersicht und nicht aus Nutzersicht gewählt sind. Copyright TU-Dresden, Nicolás Bleyh 36

45 Existierende Lösungen Um Web Services über eine Benutzerschnittstelle anzusprechen, existieren zwei Lösungsansätze. Der einfachere dieser beiden bestimmt die grafische Benutzerschnittstelle lediglich aus den Informationen, die die WSDL-Beschreibung liefert. Im zweiten Ansatz wird zusätzlich zur WSDL-Datei noch ein Dokument beigelegt, in dem Formatierungsregeln und semantische Informationen enthalten sind, die für eine nutzerfreundliche Gestaltung der Benutzerschnittstelle notwendig sind. Unterschieden wird außerdem zwischen Rich-Client- und Web-Anwendungen. Rich-Client- Anwendungen bezeichnet Applikationen, die vor der Verwendung auf der Nutzerseite installiert werden müssen. Web-Anwendungen werden dagegen über einen Browser aufgerufen. Rich-Client-Anwendungen bieten den Vorteil, dass sie in der Lage sind, die SOAP- Nachrichten direkt zu verschicken und zu empfangen, ohne das vorher eine Transformation durch einen zwischengeschalteten Dienst erfolgen muss. Dies ist bei Web-Anwendungen notwendig, da Browser nicht in der Lage sind, SOAP-Nachrichten zu interpretieren. Dafür sind Web-Anwendungen plattformunabhängig und besitzen durch ihre Ausführung mittels eines Browsers eine höhere Verfügbarkeit. In den folgenden Kapiteln wird mit XForms zunächst ein Standard für elektronische Formulare zur Datenerfassung vorgestellt. Im Anschluss werden unterschiedliche Konzepte zur Generierung von Benutzerschnittstellen für Web Services vorgestellt, wobei unterschieden wird, ob die Generierung lediglich auf Grundlage der WSDL oder noch eines zusätzlichen Dokuments erfolgt XForms Die bekannteste Form einer Benutzerschnittstelle zur elektronischen Erfassung von Nutzereingaben stellen HTML-Formulare dar. Bei Rich-Client-Anwendung stellt meistens die jeweilige Programmiersprache Bibliotheken zur Verfügung, mit denen Formularelemente erstellt werden können. Sowohl die Verwendung von HTML also auch von GUI-Bibliotheken besitzen jedoch den Nachteil, dass sie erstens plattformabhängig sind und zweitens nur beschränkte Möglichkeiten zur Validierung der Nutzereingaben bieten, die im Fall von HTML z.b. durch das Einbinden von Java-Script-Funktionen zu lösen versucht wird. Deshalb soll in diesem Kapitel eine Beschreibungssprache für Formulare namens XForms vorgestellt werden, die eben genannte Nachteile nicht besitzt. XForms ist ein vom W3C-Konsortium entwickelter Standard zur Beschreibung multimodaler und plattformunabhängiger Benutzerschnittstellen mit Hilfe von XML. Die momentane Version 1.0 liegt seit dem 14. März 2006 als Empfehlung vor [46]. XForms soll der Nachfolger der HTML-Formulare werden. Im Gegensatz zu diesen trennen XForms das Datenmodell von ihrer Präsentation. Dabei stellen XForms keinen eigenen Dokumenttyp dar, sondern werden zur Darstellung in andere XML-Dokumente wie z.b. XHTML oder WML (Wireless Markup Language) eingebettet. XForms eigenen sich somit sehr gut zur Beschreibung von Benutzerschnittstellen und finden auch im WSGUI Ansatz Verwendung (siehe Kapitel ) Deshalb sollen in diesem Kapitel die Grundlagen des Standards erläutert werden. XForms spezifiziert zwei verschiedene Bereiche. Zum einen das model, indem die einzugebenden Daten und Datentypen definiert werden. Zum anderen die form controls. Hier erfolgt die Darstellung der Interaktionelemente für die Benutzereingaben. Der folgende Quellcode zeigt ein Xforms-Artefakt mit den Benutzereingaben Name und Vorname. Dabei wird im Copyright TU-Dresden, Nicolás Bleyh 37

46 Existierende Lösungen model ein XML-Template definiert, dass durch die Nutzereingaben gefüllt und in dieser Form an den Server geschickt wird. <model> <instance> <person> <name/> <vorname/> </person> </instance> </model> <input ref="person/name"><label>nachname: </label></input> <input ref="person/vorname"><label>vorname: </label></input> Quellcode 10: Beispiel eines XForms Über das input-element wird eine Benutzereingabe definiert, die mittels eines label- Elements beschriftet werden kann. Mit dem Attribut ref wird über einen XPath-Ausdruck das Element aus der Instanz des Datenmodells referenziert, für welches die Eingabe bestimmt ist. Die bei obigem Beispiel nach einer Nutzereingabe abgeschickte XML-Nachricht ist im Quellcode 11 dargestellt. <person> <name>mustermann</name> <vorname>max</vorname> </person> Quellcode 11: Beispiel für die XML-Repräsentation der Nutzereingaben Neben dem input-element gibt es weitere Interaktionselemente, wie z.b. select1 (Auswahl eines Elements aus einer Liste) oder select (Auswahl eines oder mehrerer Elemente aus einer Liste). Wie diese Interaktionelemente letztendlich auf der Benutzerseite dargestellt werden, hängt von dem verwendeten Endgerät ab. Bei Geräten mit kleinen Displays würden die Inhalte des select-elements beispielsweise als Radiobuttons angezeigt, während auf einem Desktop-Rechner eine Repräsentation als dropdown-liste vorstellbar wäre. Dadurch sind XForms geräteunabhängig einsetzbar. Um Eingabefelder mit vordefinierten Werten zu versehen, müssen in der Instanz des Datenmodells die entsprechenden Werte eingetragen werden. Des Weiteren ist es möglich, die eingegebenen Daten gegenüber einem XML-Schema automatisch zu validieren, so dass dies nicht mehr durch extra Routinen wie beispielsweise Java-Script-Funktionen erfolgen muss. Dabei können sowohl Standard XML-Schema-Typen als auch eigene XML-Schema- Definitionen angegeben werden. Die Zuweisung eines Elementes zu einem Datentyp kann im Element selber oder über das bind-element erfolgen. Dort erfolgt eine Referenzierung mittels eines XPath-Ausdrucks auf das zu validierende Element und die Angabe des zugehörigen Datentyps. <bind nodeset="/person/name" type="xsd:string"/> Quellcode 12: Angabe eines Datentyps zum Zweck der Validierung Auch wenn die meisten bestehenden Web-Anwendungen noch keine XForms verwenden, so existieren doch bereits einige Werkzeuge, die den XForms-Standard unterstützen. So gibt es für den Mozilla Firefox ein Plugin [47], mit dem in XHTML eingebettet XForms dargestellt werden können. Copyright TU-Dresden, Nicolás Bleyh 38

47 Existierende Lösungen Durch die konzeptionelle Ausrichtung von XForms auf geräteunabhängige Benutzerinteraktionen, bietet es sich an, diese Technologie für die Beschreibung von Benutzerschnittstellen für (komplexe) Web Services zu verwenden. Dadurch, dass die vom Benutzer eingegebenen Daten als XML verschickt werden, lässt sich die Benutzerinteraktion sehr gut in das Web- Service-Konzept integrieren. Für einen Web-Service-Aufruf müssten diese Daten somit nur noch in die SOAP-Nachricht eingebunden werden. Auch die Möglichkeit von XForms, die Eingabedaten anhand von XML-Schema zu validieren, lässt sich gut mit Web Services kombinieren, da über die WSDL-Beschreibung die für den Funktionsaufruf einzugebenden Datentypen bereits definiert sind Generierung auf Grundlage von WSDL Einer der ersten Versuche, anhand der WSDL-Beschreibung eines Web Services automatisch ein Benutzerinterface zu generieren, war SOAPClient [48]. Dabei existiert eine HTML- Benutzeroberfläche, in der die Adresse einer WSDL-Datei angegeben werden kann. Anhand deren Beschreibung wird ein einfaches HTML-Formular ausgegeben, in der alle Operationen mit ihren entsprechenden Eingabeparameter aufgelistet sind. Auf die Formatierung der Formularelemente kann allerdings kein Einfluss genommen werden, ebenso sind die Formularelemente auf Textfelder beschränkt. Daher eignet sich der SOAPClient lediglich für einfache Web-Service-Anfragen. Neben SOAPClient existieren noch weitere Lösungen, die als Grundlage für eine Benutzerschnittstellenbeschreibung lediglich WSDL verwenden. Als Beispiel soll hier die Arbeit von S. Apfel [13] genannt werden. Für die semantische Beschreibung der Interaktionselemente wird dort das WSDL-Element description genutzt. Die Generierung der Eingabemaske für den Benutzer erfolgt durch eine Umwandlung der in XML-Schema definierten Datentypen in die entsprechenden Java-GUI-Elemente. Eine ähnliche Idee wird in [49] beschrieben. Dort werden aus WSDL-Beschreibungen XForms generiert, um damit multimodale und plattformunabhängige Benutzerinterfaces für mobile Endgeräte zum Aufrufen von Web Services zu ermöglichen. Bis auf [13] besitzen die genannten Ansätze alle den Nachteil, dass die Operations- und Parameterbenennung in den WSDL-Beschreibungen oftmals für den normalen Endanwender nicht verständlich sind, da sie in erster Linie aus der Sicht von Programmierern gewählt werden. Ein bedienbares Nutzerinterface ist so davon abhängig, ob in der WSDL-Datei nutzerfreundliche Bezeichnungen gewählt wurden. Abgesehen davon kann bei den oben vorgestellten Ansätzen von der Autorenseite keinerlei Einfluss auf die Formatierung der Nutzeroberfläche genommen werden. Der Ansatz von [13], anhand von XML-Schema Java-GUI-Elemente zu generieren, ist zwar vielversprechend, allerdings geht dabei die Plattformunabhängigkeit verloren. Vorteilhaft ist hier die Idee aus [49], stattdessen eine Umwandlung in XForms vorzunehmen. Diese Vorgehensweise wird auch in WSGUI (siehe Kapitel ) verfolgt Generierung auf Grundlage von WSDL und User Interface Markup Um die im vorherigen Kapitel genannten Nachteile zu beheben, existieren weitere Ansätze, die ein zusätzliches Dokument zur Beschreibung des Benutzerinterfaces einführen. Zwei davon werden im Folgenden vorgestellt enode Bei enode [50] handelt es sich um eine in Java implementierte Rich-Client-Anwendung, die zur Beschreibung der grafischen Oberfläche eines Web Services zusätzlich zu WSDL eine Copyright TU-Dresden, Nicolás Bleyh 39

48 Existierende Lösungen eigene Markupsprache namens enode UI Markup Language verwendet. Diese dient hauptsächlich dazu, Java-GUIs mittels XML zu beschreiben. Es ist somit auch möglich, mehrere Web Services in einer Benutzeroberfläche zu integrieren. Allerdings handelt es sich bei enode um kein Open-Source-Projekt. Hinzu kommt, dass für die Ausführung einer enode- Anwendung das Java Runtime Environment und Java Web Start auf dem Client installiert sein muss. Mit enode kann somit ein Rich Client erstellt werden, der Web Services aufruft. Das primäre Ziel von enode ist jedoch nicht die Benutzerinteraktion mit Web Services. Die Programmlogik sowie die Zuweisung von Eingabedaten zu Operationsaufrufen muss vom Entwickler innerhalb einer Java-Anwendung realisiert werden und kann nicht generisch anhand der WSDL und der enode UI Markup Language ablaufen. Das Projekt enode bietet damit vor allem einen interessanten Ansatz, wie Java-GUIs mit Hilfe von XML beschrieben werden können WSGUI Das Konzept von WSGUI (Web Services Graphical User Interface) wurde ursprünglich in einer Arbeit an der Stanford University [51] entwickelt, wird aber mittlerweile von J. Spillner am Lehrstuhl Rechnernetze der TU Dresden implementiert und weiterentwickelt (siehe [52] und [53]). Ziel von WSGUI ist es, für (elementare) Web Services eine nutzerfreundliche grafische Oberfläche zur Verfügung zu stellen. Hierfür wird zusätzlich zur WSDL-Beschreibung ein weiteres XML-Dokument verwendet, und zwar der GUI deployment descriptor (GUIDD). Darin wird eine abstrakte Beschreibung des Benutzerinterfaces definiert. Durch eine GUIDD- Engine kann mit Hilfe dieser beiden Dokumente auf der Serverseite eine Benutzeroberfläche generiert werden, die z.b. in Form von HTML an den aufrufenden Web-Browser zurück geschickt wird. Da die Beschreibung des Benutzerinterfaces mit der Syntax von XForms realisiert wird, können die Eingabemasken auch in andere Ausgabeformate wie beispielsweise WML oder VoiceXML integriert werden. WSGUI beschränkt sich somit nicht nur auf browserbasierte Lösungen, sondern kann auch für Rich Clients verwendet werden. Die Beschreibung der Benutzeroberfläche erfolgt in der GUIDD durch die Elemente operations, formcomponents und outputtypes. Jede operation besitzt ein Attribut name, mit dem auf die zugehörige WSDL-Operation verwiesen wird. Außerdem besitzt eine operation die Kindelemente prettyname und description, mit denen zum Zweck der Nutzerfreundlichkeit ein Name und eine Beschreibung des Formulars für die entsprechende Operation angegeben werden kann. Die Beschriftung kann mit Hilfe des Attributes lang in mehreren Sprachen angeboten werden. Die eigentlichen Formularelemente werden über in den formcomponent-elementen enthaltene form controls (siehe Kapitel 4.2.1) definiert. Dabei wird über einen XPath-Ausdruck für jede formcomponent ein Element eines in der WSDL definierten Datentyps referenziert. Das vom aufgerufenen Web Service zurückgelieferte Ergebnis kann über das Element outputtype dargestellt werden. Auch hier wird der Inhalt des darzustellenden Elements über einen XPath-Ausdruck referenziert und über form controls dargestellt. Das folgende GUIDD-Codebeispiel zeigt die Definition eines Eingabefeldes. Über die Elemente label und hint kann das Eingabefeld beschriftet und mit einer Erläuterung versehen werden. Die Syntax innerhalb der formcomponent-elemente entspricht dem XForms- Standard. Die Zuweisung der eingegebenen Daten zu einem in der WSDL-Datei beschriebenen Parameter, der für den Operationsaufruf benötigt wird, erfolgt innerhalb des formcomponent-elements und des input-elements über einen XPath-Ausdruck. Copyright TU-Dresden, Nicolás Bleyh 40

49 Existierende Lösungen <formcomponent xpath="/travel/startlocation"> <xforms:input ref="/travel/startlocation"> <xforms:label>startpunkt: </xforms:label> <xforms:hint>startpunkt der Reise</xforms:hint> </xforms:input> </formcomponent> Quellcode 13: Beispiel für die Definition eines Eingabefelds in einer GUIDD Im ursprünglichen Konzept von [51] wurden noch weitere Ideen aufgezeigt, die bis jetzt aber nicht in die Implementierung von [53] übernommen wurden. Dazu gehört neben der GUIDD ein zweites Dokument, nämlich ein look and feel stylesheet (L&F stylesheet), mit welchem der Autor einen stärkeren Einfluss auf die Darstellung des Benutzerinterfaces nehmen kann. Zu einer GUIDD können mehrere L&F stylesheets erstellt werden, so dass es möglich ist, funktional gleiche Benutzerinterfaces unterschiedlich darzustellen. Des Weiteren soll es den Autoren von GUIDDs ermöglicht werden, mit Hilfe virtueller Operationen eine Operation darzustellen, die sich aus mehreren WSDL-Operationen zusammensetzt. In der bisherigen Implementierung ebenfalls noch nicht unterstützt sind dynamicenumeration-elemente. Damit ist es für den Nutzer möglich, innerhalb eines Formulars Elemente zu einer Liste hinzuzufügen oder zu entfernen. WSGUI besitzt starke Ähnlichkeit mit einem anderen Konzept zur Generierung von Benutzerschnittstelen für Web Services, nämlich WSUI (Web Service User Interface, [54]). Dieses Projekt wird allerdings nicht weiter verfolgt und soll nur der Vollständigkeit halber erwähnt werden. Mittlerweile existiert nicht einmal mehr eine projekteigene Seite. Für die Realisierung von Benutzeroberflächen für die Interaktion mit komplexen Web Services konzentriert sich diese Arbeit daher vor allem auf WSGUI. 4.3 Web Services for Remote Portlets (WSRP) Bei der Betrachtung von Benutzerinteraktionen in komplexen Web Service muss auch die Portaltechnologie erwähnt werden. Mit ihr ist es möglich, mehrere Dienste über so genannte Portlets in einer Benutzeroberfläche, dem Portal, zu integrieren. In diesem Kapitel soll kurz ein Standard namens Web Service for Remote Portlets (WSRP, [55]) vorgestellt werden, mit dem über eine Web-Service-Schnittstelle entfernte Portlets aufgerufen und in die eigene Portalumgebung integriert werden können. WSPR, von OASIS entwickelt, stellt dazu Schnittstellen und Semantiken bereit, mit denen die entfernten Portlets über eine Web-Service-Schnittstelle in andere Portale integriert werden können. Dabei wird zwischen den Rollen Producer und Comsumer unterschieden. Ein Producer ist ein Web Service, der ein oder mehrere Portlets bereitstellt und diese über eine WSPR-Schnittstellen anbietet. Der Consumer ist ein Web-Service-Client, der WSRP-Web-Services aufruft und eine Portalumgebung bereitstellt, in welche die angebotenen Portlets integriert werden können. Producer müssen ein Service Description Interface und ein Markup Interface bereitstellen. Das Service Description Interface enthält Metadaten über den Anbieter, die angebotenen Portlets und Operationen. Über das Markup Interface können dagegen Consumer mit den vom Producer angebotenen, verteilt laufenden Portlets interagieren. In welchem Kontext WSPR für die Lösung der Problemstellung dieser Arbeit verwendet werden könnte, wird im Kapitel erläutert. Copyright TU-Dresden, Nicolás Bleyh 41

50 Existierende Lösungen 4.4 Benutzerinteraktion in komplexen Web Services Lösungen, mit denen die in Kapitel vorgestellte Ziel-orientierte Benutzerinteraktion mittels eines komplexen Web Services generisch realisiert werden kann, existieren bis heute nicht. Zur Realisierung des Konzepts der Task-orientierten Benutzerinteraktion (Kapitel 3.3.2) gibt es dagegen verschiedene Ansätze. Zwei davon sollen in den folgenden beiden Kapiteln vorgestellt werden. Im ersten wird eine Erweiterung der BPEL-Syntax vorgeschlagen, um Nutzerinteraktionen in Geschäftsprozessen abbilden zu können. Der zweite Ansatz realisiert die Nutzerinteraktion über einen zusätzlichen Web Service, der eine Schnittstelle zwischen dem Nutzer und dem BPEL-Prozess darstellt BPEL4PEOPLE Von IBM und SAP wurde im Juli 2005 ein White Paper veröffentlicht, in dem eine Erweiterung von BPEL vorgeschlagen wird, um menschliche Benutzeraktionen in den Geschäftsprozess zu integrieren, da BPEL nur auf Web Services basierende automatisierte Geschäftsprozesse unterstützt [56]. Ein Beispiel für die Einbeziehung von Menschen in einen Geschäftsprozess wurde im Kapitel mit der Kreditvergabe an einen Kunden bereits illustriert. Bei nicht eindeutiger Kreditwürdigkeit oder falls der Kredit eine bestimmte Höhe überschreitet, soll ein Bankmitarbeiter Einfluss auf den weiteren Verlauf des Geschäftsprozesses nehmen. Da es sich bei BPEL4PEOPLE um den einzigen bekannten Versuch handelt, auf Web Services basierende Prozessbeschreibungen um Nutzerinteraktionen zu erweitern, soll hier ein kurzer Überblick über die Ideen und Ansätze des White Paper gegeben werden. Um die Notwendigkeit der Integration von menschlichen Benutzerinteraktionen in Geschäftsprozesse zu verdeutlichen, werden darin zahlreiche Szenarien vorgestellt: Benutzeraktivitäten: Benutzer können als spezielle Art von Aktivitäten in den Geschäftsprozess mit einbezogen werden. Dabei unterscheidet man bei diesen Aktivitäten zwischen task und notification. Bei einem task wird der Geschäftsprozess solange gestoppt, bis ein Benutzer die ihm zugeteilte Aufgabe erledigt hat. Dagegen wird bei einer notification der Benutzer lediglich informiert, der Geschäftsprozess aber nicht angehalten. Benutzer stoßen Prozesse an: Ein weiteres Szenario ist, dass Benutzer nicht Teil eines Geschäftsprozesses sind, sondern diesen anstoßen. Dabei kann der Geschäftsprozess unterschiedlich ablaufen, je nachdem, wer den Geschäftsprozess anstößt. Ein Beispiel wäre der Urlaubsantrag in einem Unternehmen, der bei Festangestellten und Praktikanten unterschiedlich abgearbeitet wird. Verwalten von lang andauernden Prozessen: Benutzerinteraktionen können bei lang andauernden Geschäftsprozessen notwendig sein. Dies ist dann der Fall, wenn der Geschäftsprozess nur mit Hilfe einer menschlichen Benutzerinteraktion fortgeführt werden kann. Ein Beispiel wäre ein Timeout, der eintritt, wenn eine bestimmte Aktion innerhalb eines Zeitraums nicht durchgeführt wurde. Dann muss ein Benutzer entscheiden, wie der Prozess weiter ablaufen soll. Möglicherweise müssen auch einige Prozessschritte rückgängig gemacht werden. Dies ist zwar mit Hilfe von BPEL möglich, allerdings ist dies bei Geschäftsprozessen, die mehrere Tage andauern, nicht wünschenswert. Auch hier sollte ein Nutzer entscheiden, welche Teile eines Geschäftsprozesses rückgängig gemacht werden und welche nicht. Dazu führt BPEL4PEOPLE die Rolle des business administrator ein, der einem oder mehreren Geschäftsprozessen als Verantwortlicher zugeordnet wird. Der business administrator ist in der Lage, mit einem Geschäftsprozess zu interagieren, indem er den Status abfragt, fehlende Daten Copyright TU-Dresden, Nicolás Bleyh 42

51 Existierende Lösungen eingibt, Prioritäten setzt oder den Prozess mit anderen Geschäftsprozessen synchronisiert. Erweiterte Interaktionen: Des Weiteren werden in [56] komplexere Abläufe (Muster) vorgestellt, wie Benutzer mit Geschäftsprozessen interagieren. Auch für diese Interaktionsmuster ist eine Erweiterung von BPEL notwendig. Ein Beispiel hierfür ist das 4- Augen-Prinzip. Dabei wird oftmals aus Sicherheitsgründen eine Entscheidung von zwei Benutzern unabhängig voneinander getroffen (wie z.b. die Gewährung eines Kredites). Nur wenn beide zustimmen, wird der Geschäftsprozess weiter ausgeführt. Ein weiteres Beispiel ist der Vertretungsmechanismus für Mitarbeiter. Kann eine Aufgabe von einem Benutzer nicht abgearbeitet werden (z.b. durch Krankheit), so muss ein Stellvertreter benachrichtig werden, der dann für diese Aufgabe verantwortlich ist. Ein anderes Ablaufmuster ist das der verketteten Ausführung. Diese tritt dann auf, wenn eine Sequenz von Arbeitsschritten vom gleichen Nutzer ausgeführt wird. Es soll möglich sein, dass der Nutzer diese Schritte auch hintereinander abarbeiten kann, ohne nach jedem Schritt zurück zur Aufgabenliste zu müssen und diese zu aktualisieren, bevor er mit dem nächsten Arbeitsschritt fortfahren kann. Um diesen Anforderungen gerecht zu werden, wird in BPEL eine neue Aktivität namens people activity eingeführt, das im Unterschied zu bisherigen BPEL-Aktivitäten nicht von einer Software, sondern durch die Aktion eines menschlichen Benutzers abgearbeitet wird. Eine people activity besteht aus einem oder mehreren tasks. Tasks sind unteilbare Aufgaben, die nur von einem Benutzer bearbeitet werden können. Sie besitzen als Eigenschaften eine mehrsprachige Aufgabenbeschreibung, eine Priorität, Deadlines und ein Benutzerinterface. Damit eine Client-Applikation mit dem task interagieren kann, muss das task bestimmte Operationen zur Verfügung stellen. Dazu gehört unter anderem das Liefern einer Liste mit allen unerledigten Aufgaben und das Übernehmen bzw. Abbrechen eine Aufgabe. Ein task durchläuft zudem mehrer Zustände (ready, claimed, completed, failed). Als weiteres Element wird people link vorgeschlagen. Damit kann eine Gruppe von Nutzern repräsentiert und einer people activity zugeordnet werden. Wenn von einer BPEL-Engine eine people activity initialisiert wird, erstellt sie Aufgaben (tasks) und verteilt diese an alle durch einen people link identifizierten verantwortlichen Nutzer. Um Daten über in einen Geschäftsprozess involviere Mitarbeiter zu erhalten, wird das Element people queries benötigt. Mit Hilfe einer Anfragesprache können so Informationen über einen Mitarbeiter aus den Datenbeständen eines Unternehmens gezogen und durch die Assoziation mit people link Elementen dem Geschäftsprozess verfügbar gemacht werden. BPEL4PEOPLE erweitert BPEL ebenfalls um eine Nutzerintegration, also der Relationen zwischen Benutzern und Geschäftsprozessen. Dabei werden mit Hilfe von generic human roles unterschiedlichen Arten identifiziert, wie Benutzer mit Prozessen interagieren. Folgende generic human roles wurden dabei spezifiziert: Der process initiator bezeichnet die Person, die einen Geschäftsprozess startet. Der process stakeholder kann die Instanz eines Geschäftsprozess beeinflussen, indem er z.b. eine Aktivität weiterleitet. People activities besitzen potential owners. Diese sind berechtigt, eine people activity zu beanspruchen und abzuarbeiten. Die Aufgaben des business administrator sind administrative Tätigkeiten wie z.b. die Problembehandlung bei Ablauf einer Deadline innerhalb eines Geschäftprozesses. Im Gegensatz zum process stakeholder hat er ein Interesse an allen Instanzen eines Geschäftsprozesses. Copyright TU-Dresden, Nicolás Bleyh 43

52 Existierende Lösungen Über das Element people link werden Benutzergruppen mit einer generic human role assoziiert. Um diese Benutzergruppen zu ermitteln, wird innerhalb einer people query eine Anfrage an die Datenbestände des Unternehmens gestellt. So könnten z.b. die potential owner der Benutzergruppe Marketing Manager zugeordnet werden, indem diese generic human role über einen people link mit der Anfrage select head of department where department_name= marketing verbunden ist. BPEL4PEOPLE legt den Fokus der Integration von menschlichen Benutzerinteraktionen in komplexe Web Services auf die Orchestration. Die Integration in Choreographien ist mit diesem Ansatz nicht möglich (siehe dazu auch Kapitel 3.3.2). Innerhalb des Zeitraums dieser Arbeit gab es zu BPEL4PEOPLE jedoch keine weiteren Veröffentlichungen. Es existiert somit weder eine BPEL4PEOPLE-Syntax noch eine entsprechend erweiterte BPEL-Engine. Daher konnte der Ansatz trotz interessanter Lösungsideen in dieser Arbeit nicht weiterverfolgt werden Integration von Benutzerinteraktionen über Tasks Außer dem BPEL4PEOPLE-Ansatz existieren noch weitere Lösungen zur Realisierung einer Task-orientierten Nutzerinteraktion. Im Unterschied zu BPEL4PEOPLE werden die Nutzeraktivitäten bei diesen jedoch nicht innerhalb der Geschäftsprozessbeschreibung definiert, sondern der Nutzer kann über einen zusätzlichen Web Service mit dem Geschäftsprozess interagieren. So wird in [57] eine Architektur namens PerCollab vorgestellt, wie eine Task-orientierte Benutzerinteraktion mit BPEL realisiert werden kann. Der eigentliche Geschäftsablauf wird dabei in einer BPEL-Beschreibung definiert und in einer BPEL-Engine ausgeführt. Zusätzlich wird noch die Komponente des Interaction Controller eingeführt. Dabei handelt es sich um einen Web Service, der sich um die Generierung und der Verarbeitung der Aufgaben für die Nutzer kümmert. Über ein Kontextmodell ist es dabei möglich, dem Nutzer die Aufgaben auf dem gerade verfügbaren Endgerät zu übermitteln, sei es ein Desktop-PC oder ein Handy. Der Interaction Controller stellt über WSDL eine Web-Service-Schnittstelle zur Verfügung, so dass er vom BPEL-Prozess aufgerufen werden kann. Darüber hinaus haben einige Hersteller von Workflow-Systemen in ihre Anwendungen die Möglichkeit integriert, Benutzerinteraktionen über Tasks in einen Geschäftsprozess einzubinden. Zu nennen wäre dabei der (kommerzielle) WebSphere Process Choreographer von IBM ([58], [59]) und das Open-Source-Projekt Agila (früher unter dem Namen Twister bekannt) [60], welches neben der eigentlichen BPEL-Engine noch die Möglichkeit bietet, Aufgaben über Work Items an einen Benutzer zu delegieren. Eine weitere Lösung bietet der Oracle BPEL Process Manager [61], der als Beispiel für die Realisierung einer Task-orientierten Nutzerinteraktion näher vorgestellt werden soll. Der Oracle BPEL Process Manager stellt einen so genannten TaskManager Service bereit. Dieser besitzt Ähnlichkeiten mit dem Interaction Controller aus der vorher erwähnten Architektur PerCollab. Auch der TaskManager Service bietet eine WSDL-Schnittstelle an, so dass dieser wie ein normaler Web Service angesprochen werden kann. Die angebotenen Funktionen sind dabei: initiatetask: Stößt ein Task an. updatetask: Aktualisiert ein Task. completetask: Teilt mit, wenn ein Task erledigt oder abgebrochen wurde. Copyright TU-Dresden, Nicolás Bleyh 44

53 Existierende Lösungen ontaskresult: Wird aufgerufen, wenn ein Task abgearbeitet wurde. ontaskexpired: Wird bei einem Timeout ausgelöst. Der TaskManager Service stellt einen asynchronen Dienst dar. Als Parameter wird jeweils das entsprechende Task übergeben, wobei es sich um ein XML-Dokument handelt, welches alle Informationen des jeweiligen Tasks beinhaltet. Dieses Dokument enthält u.a. folgende Elemente: taskid: Eine eindeutige ID des Tasks. title: Der für den Nutzer sichtbare Titel des Task, z.b. Bestätigung der Bestellung #142. creationdate: Wird automatisch vom TaskManager bei Erstellung eines Tasks gesetzt. creator: ID der Anwendung, des Systems oder des Nutzers, welche den Task erstellt hat. modifydate: Gibt an, wann das Task verändert wurde. modifier: Gibt anhand einer ID an, wer das Task verändert hat assignee: ID des Nutzers, der Rolle oder der Gruppe, die für die Abarbeitung des Tasks verantwortlich ist. status: Gibt den Status des Tasks mit den Werten active oder completed an. expired: Boolean-Wert, der vom TaskManager auf false gesetzt wird, wenn die Zeit zur Ausführung des Task abgelaufen ist. expirationdate: Optionaler Wert, mit dem angegeben werden kann, wann die Gültigkeit des Tasks abläuft. duration: Gibt die Dauer an, für welche das Task gültig ist. priority: Legt die Priorität des Tasks anhand eines Integer-Werts fest. conclusion: Optionaler Wert, in dem das Ergebnis des Tasks angegeben werden kann (z.b. approved, refused,...). Dieser Wert kann für den weiteren Verlauf des BPEL-Prozesses ausgewertet werden. attachment: Über dieses Feld können spezielle Informationen zu dem Task in einem beliebigen Datentyp eingefügt werden. Die Operationen des TaskManagers können vom BPEL-Prozess wie die eines normalen externen Web Services aufgerufen werden. Davor muss ein Task innerhalb eines assign- Konstrukts initialisiert werden, um dann durch eine invoke-aktivität an den TaskManager Service gesendet zu werden. Mit der Aktivität receive wird das Ergebnis der ontaskresult- Operation empfangen, die wiederum aus dem (modifizierten) Task-Dokument besteht. Um Tasks über ein grafisches Benutzeroberfläche anzeigen und manipulieren zu können, stellt der Oracle BPEL Process Manager eine Java Worklist API zur Verfügung. Mit dieser können z.b. innerhalb einer JSP-Seite die von der BPEL-Engine übergebenen Tasks dargestellt und vom Nutzer bearbeitet werden. Die folgende Abbildung zeigt das Zusammenspiel des BPEL-Prozesses mit dem TaskManager Service und einer Webanwendung, durch die der Nutzer mit dem Geschäftsprozess über Tasks interagieren kann. Copyright TU-Dresden, Nicolás Bleyh 45

54 Existierende Lösungen Abbildung 15: Task-orientierte Benutzerinteraktion beim Oracle BPEL Process Manager [62] 4.5 Bewertung Wie im vorherigen Kapitel gesehen, bieten einige BPEL-Engines bereits Lösungen für die Realisierung einer Task-orientierten Nutzerinteraktion an. Nachteil all dieser Anwendungen ist jedoch, dass es sich jeweils um eine proprietäre Lösung handelt. Somit kann eine einmal definierte Task-orientierte Nutzerinteraktion nicht auf anderen Plattformen eingesetzt werden. Ein Ansatz wäre die Standardisierung der Web-Service-Schnittstelle des Dienstes, über die eine Client-Anwendung die Aufgaben bzw. Aufgabenlisten bezieht, indem sich die WfMS- Hersteller z.b. auf die Operationen des Dienstes und den Datentyp eines Tasks einigen. Allerdings ist eine solche Einigung schon alleine aus kommerziellen Gesichtspunkten eher unwahrscheinlich. Eine weitere Idee ist, neue BPEL-Elemente einzuführen, um eine Task-orientierten Nutzerinteraktion innerhalb eines BPEL-Prozesses zu beschreiben. Um diese neuen Elemente zu interpretieren müssten die existierenden BPEL-Engines entsprechend modifiziert werden. Eine Erweiterung des BPEL-Standards ist im Rahmen dieser Arbeit aber nicht sinnvoll, abgesehen davon, dass mit BPEL4PEOPLE ein entsprechender Ansatz bereits diskutiert wird. Außerdem würde die Aufgabe, eine BPEL-Engine um die Interpretation neuer Elemente zu erweitern, den Rahmen dieser Arbeit sprengen. In dieser Arbeit soll daher ein Konzept entwickelt werden, wie eine Ziel-orientierte Nutzerinteraktion realisiert werden kann. Dazu gibt es bisher weder kommerzielle noch Open-Source- Lösungen. Um die Dienste über eine grafische Benutzeroberfläche anzusprechen, soll WSGUI verwendet und gegebenenfalls erweitert werden, da allein die Informationen der WSDL nicht zur Generierung einer adäquaten Benutzeroberfläche ausreichen. Copyright TU-Dresden, Nicolás Bleyh 46

55 Konzept 5 Konzept Um die Motivation hinter einem Konzept zur Generierung einer Benutzerschnittstelle für komplexe Web Services noch einmal zu verdeutlichen, zeigt die Abbildung 16, wie die übliche Vorgehensweise aussieht, um eine Benutzerinteraktion mit einem komplexen Web Service zu erreichen. Dabei wird sowohl die Komposition der einzelnen Web Services als auch das Benutzerinterface bereits zur Entwicklungszeit in einer Server-Anwendung festgelegt und implementiert. Abbildung 16: Übliche Vorgehensweise bei der Interaktion eines Benutzers mit einem komplexen Web Service Nachteil dieser Lösung ist die mangelnde Flexibilität. Ändert sich etwas an der Schnittstelle eines beteiligten Web Services wie beispielsweise ein Operationsparameter, so muss die Anwendung aktualisiert, gegebenenfalls neu kompiliert und wieder veröffentlicht werden. Außerdem ist eine Wiederverwendung dieses komplexen Web Services schwer möglich, da die Anwendung von einer bestimmten Plattform abhängig ist. Handelt es sich dabei beispielsweise um ein Java Servlet, so kann dieses nicht auf eine Windows.NET Umgebung portiert werden. Ebenfalls fest implementiert ist die Darstellung des Benutzerinterfaces. Eine Veränderung der grafischen Benutzerschnittstelle ist nur durch direkte Modifikationen am Quellcode möglich. Das erste Ziel ist, den Ablauf des komplexen Web Services nicht im Quellcode festzulegen, sondern ihn mit Hilfe einer Kompositionssprache in einem separaten Dokument zu beschreiben. Zum einen sind dadurch Änderungen im Ablauf und Anpassungen an veränderte Web- Service-Schnittstellen einfacher möglich, weil es z.b. gerade für BPEL eine Vielzahl von guten Autorenumgebungen gibt. Außerdem kann die Kompositionsbeschreibung leichter auf eine andere Plattform portiert werden, sofern die gleiche Kompositionssprache genutzt wird. Durch die Verwendung eines separaten Dokuments ist es sogar möglich, den Ablauf des komplexen Web Services dynamisch zu laden und zu interpretieren, so dass die Kompositionsbeschreibung nicht bereits zur Entwicklungszeit feststehen muss, sondern auch erst zur Laufzeit vorgelegt werden kann. Das zweite Ziel ist, nicht nur die Kompositionsbeschreibung, sondern auch die Beschreibung der Benutzeroberfläche vom Quellcode zu trennen. Da die WSDL-Informationen hierzu nicht ausreichen, bietet es sich an, ein zusätzliches Dokument heranzuziehen, um eine nutzerfreundliche Oberfläche für die Darstellung der von einem Web Service angebotenen Operationen und zurückgegebenen Ergebnisse anzubieten. Der bisher einzige dazu bestehende Open- Source-Ansatz sind die GUIDD-Dokumente des WSGUI-Projekts, die auch in dieser Arbeit verwendet werden. Copyright TU-Dresden, Nicolás Bleyh 47

56 Konzept Als nächstes stellt sich die Frage, ob der Nutzer über eine Web- oder eine Rich-Client- Anwendung mit dem Dienst interagiert. Der Vorteil einer Rich-Client-Anwendung ist, dass kein Server zwischen dem Client und den Diensten zwischen geschaltet werden muss, um sich um die Transformation von SOAP in eine Oberflächenbeschreibungssprache zu kümmern, da dies innerhalb der Rich-Client-Anwendung realisiert werden kann. Da Web-Browser bis jetzt keine SOAP-Nachrichten interpretieren können, ist diese Transformation bei Web- Anwendungen nötig. Dafür bieten Web-Anwendungen den Vorteil der Plattformunabhängigkeit, einer großen Verbreitung und damit hoher Verfügbarkeit. Außerdem sind Browser bereits in der Lage, Benutzerschnittstellen anhand von Oberflächenbeschreibungssprachen (wie z.b. HTML) darzustellen. Das Mapping von einer Oberflächenbeschreibungssprache auf graphische Ein- und Ausgabeelemente muss bei einer Rich-Client-Anwendung erst noch implementiert werden. Insofern bieten Web-Anwendungen auch eine viel größere Geräteunabhängigkeit, da bei einer Rich-Client-Anwendung für jedes Gerät eine neue Oberfläche implementiert werden muss. Bei Web-Anwendungen genügt dagegen eine Anpassung der Oberflächenbeschreibung, da sich um deren Interpretation der Browser kümmert. Aufgrund dieser genannten Vorteile wird im vorliegenden Konzept eine browserbasierte Lösung verfolgt. In den folgenden Unterkapitel soll anhand einiger bisher vorgestellten Technologien ein Konzept namens GUI4CWS (GUI for Complex Web Services) vorgestellt werden, wie das Szenario einer Ziel-orientierten Nutzerinteraktion mit einem komponierten Web Service umgesetzt werden kann. Dabei werden zunächst zwei Ansätze zur Komposition der Dienste vorgestellt und verglichen. Anschließend wird auf die Möglichkeiten eingegangen, wie anhand eines derart komponierten Dienstes eine Benutzerschnittstelle generiert werden kann. Den Abschluss des Kapitels bilden eine Vorstellung der Gesamtarchitektur des erarbeiteten Konzeptes und eine kurze Beschreibung des Autorenprozesses. 5.1 Kompositionsbeschreibung Wie in Kapitel 3.2 gezeigt, existieren drei verschiedene Ansatzpunkte zur Komposition von Web Services: die Choreographie, die Orchestration und das Behavioral Interface. Für den Fall einer Task-orientierten Nutzerinteraktion bietet sich eine Orchestration der Dienste an. Der Prozess wird hier durch die Orchestrierungs-Engine ausgeführt, die bei Bedarf Nutzerinteraktionen über Tasks integriert. Für diesen Ansatz existieren allerdings bereits Lösungen, von denen einige im Kapitel 4.4 vorgestellt wurden. Bei einer Ziel-orientierten Nutzerinteraktion kann eine reine Orchestrierung nicht verwendet werden, da der Geschäftsprozess immer von einer übergeordneten Instanz, nämlich der Orchestrierungs-Engine kontrolliert wird. Im Falle einer Ziel-orientierten Nutzerinteraktion müsste aber der Nutzer die übergeordnete Instanz darstellen, was hieße, dass auf der Nutzerseite eine Orchestrierungs-Engine vorhanden sein muss. Da dies weder bei Rich-Client- noch bei Web-Anwendungen sinnvoll ist, wird ein Behavioral Interface benötigt, über das der Client eine Orchestrierungs-Engine ansprechen kann. Im Gegensatz dazu wird der Geschäftsprozess beim Choreographieansatz nicht durch eine Orchestrierungs-Engine kontrolliert, sondern jeder Teilnehmer, der Benutzer mit eingeschlossen, ist autonom und kümmert sich selbstständig um seine korrekte Teilnahme am Ablauf der Choreographie. Diese beiden Ansätze sollen nun in Bezug auf die Integration von Benutzerinteraktionen näher vorgestellt und miteinander verglichen werden. Copyright TU-Dresden, Nicolás Bleyh 48

57 Konzept Choreographieansatz Die Idee hinter dem Choreographieansatz ist, dass die Benutzerseite sich konzeptionell selbst wie ein Web Service verhält und somit zusammen mit den anderen Diensten Teil des komponierten Dienstes ist. Zur Beschreibung der Choreographie bietet sich WS-CDL an (siehe Kapitel 4.1.2). Darin wird der gesamte globale Ablauf zwischen den beteiligten Diensten, inklusive der Benutzerseite, festgelegt. Da der Client im Gegensatz zu den anderen Teilnehmern technisch gesehen keinen Web Service darstellt, muss eine Serveranwendung zwischen dem Nutzer und den anderen Web Services eingeführt werden. Diese Serveranwendung nimmt die Rolle des Clients in der Choreographie ein und kümmert sich um den Aufruf der beteiligten Dienste, das Empfangen der Nachrichten und die Generierung der entsprechenden Benutzeroberfläche. In der Abbildung 17 ist eine Architektur zu der soeben beschriebenen Konzeptidee dargestellt. Der Client kann über den Browser ein Standard Web-Formular aufrufen, indem er einen gewünschten (komponierten) Dienst auswählt. Dieser wird durch ein WS-CDL Dokument beschrieben. Die WS-CDL-Beschreibung kann von einem oder mehreren der beteiligten Dienste mit Hilfe von entsprechenden Autorenwerkzeugen erstellt worden sein und steht öffentlich zur Verfügung. Die Serveranwendung besteht aus zwei Komponenten: einer Darstellungskomponente und einer Choreographiekomponente. Die Aufgabe der Darstellungskomponente besteht darin, ein Benutzerinterface für die Eingaben und Ausgaben des Web Services zu generieren. Dazu dienen die WSDL-Beschreibungen und eventuell vorhandene Formatierungsdokumente wie z.b. GUIDDs der beteiligten Web Services. Um den gesamten Ablauf des Geschäftsprozesses zu steuern, wird die Choreographiekomponente benötigt. Diese interpretiert die aufgerufene WS-CDL-Beschreibung und steuert anhand dessen den Ablauf für die Benutzerseite. Aufgaben der Choreographiekomponente sind also unter anderem, den Zustand des Geschäftsablaufes zu speichern, Anfragen des Clients zu extrahieren, die Daten an den jeweiligen Web Service weiterzuleiten und Ergebnisse je nach Bedarf zu transformieren. Die Choreographiekomponente muss damit in der Lage sein, die Mächtigkeit des WS-CDL- Standards zu interpretieren. Abbildung 17: Architektur des Choreographieansatzes Ein beispielhafter Ablauf bei Verwendung dieser Architektur ist in der Abbildung 18 dargestellt. Die vom Nutzer eingegebenen Daten werden empfangen und auf Grundlage der WS- CDL- und zugehörigen WSDL-Beschreibungen transformiert und an die entsprechenden Web Services geschickt. Im Beispiel handelt es sich um einen parallelen Operationsaufruf an einen Hotel- und Flugdienst. Wie die zurückgelieferten Dokumente für den Nutzer präsentiert werden sollen, entnimmt die Darstellungskomponente den einzelnen Formatierungsdokumenten (z.b. in Form einer GUIDD) der beteiligten Dienste. Da es sich um einen parallelen Aufruf handelt, müssen die so formatierten Daten von der Darstellungskomponente für die Darstel- Copyright TU-Dresden, Nicolás Bleyh 49

58 Konzept lung geeignet aggregiert werden, um dem Nutzer eine adäquate Oberfläche zur Verfügung zu stellen, die es diesem ermöglicht, die nächste Benutzerinteraktion vorzunehmen (im Beispiel Auswahl und Buchung einer passenden Reise) Einsatz von Portlets Abbildung 18: Beispiel für den Choreographieansatz Gerade der Fall eines parallelen Aufrufs mehrerer Dienste führt zu einer wachsenden Komplexität bei der Generierung einer entsprechenden Benutzerschnittstelle. So ist es beispielsweise nicht möglich, die innerhalb eines HTML-Formulars eingegebenen Daten an zwei oder mehrere verschiedene Endpunkte zu verschicken. Eine Lösungsmöglichkeit wäre der Einsatz von ontologischen Beschreibungen der Parameter einer Operation. Auf das Beispiel in der Abbildung 18 bezogen, könnte so die Choreographiekomponente erkennen, dass sich die Syntax und Semantik der Eingabeparameter für die Operationen des Hotel- und Flugdienstes überschneiden. Anhand der ontologischen Beschreibung ist es möglich, die eingegebenen Parameter entsprechend zu trennen und den jeweiligen Operationen zuzuweisen. Um Formularinhalte an unterschiedliche Endpunkte zu senden, können aber auch XForms eingesetzt werden, mit denen dies im Unterschied zu HTML möglich ist. Allerdings ist XForms eine relative neue Technologie und soll erst ab XHTML 2.0 die bisherigen HTML- Formular ablösen. Trotzdem wird der Einsatz von XForms im Kapitel 5.2 zur Darstellung der Benutzeroberfläche weiter untersucht. Eine elegante Lösungsvariante zum parallelen Operationsaufruf ist der Einsatz von Portalen und WSRP (siehe Kapitel 4.3). Dieser Ansatz ist möglich, wenn die beteiligten Dienste Portlets über eine Web-Service-Schnittstelle zur Verfügung stellen. Auf das in der Abbildung 18 dargestellte Beispiel bezogen, könnten die vom Hotel- und Flugdienst über eine WSRP- Schnittstelle zurück gelieferten Portlets in einem Portal dem Benutzer zur Verfügung gestellt werden. Die Choreographiekomponente müsste sich somit nicht mehr um die Aggregation der zurückgelieferten Daten kümmern. Abgesehen davon entfallen die Aufgaben der Darstellungskomponente, da von den beteiligten Diensten bereits fertige Portlets geliefert werden. Copyright TU-Dresden, Nicolás Bleyh 50

59 Konzept Das ist allerdings auch der große Nachteil jener Variante. Die beteiligten Web Services müssen die entsprechenden Portlets anbieten, was im Normalfall eher nicht der Fall sein wird. Außerdem laufen die einzelnen Portlets innerhalb eines Portals autonom ab, so dass durch den entfernten Charakter Abhängigkeiten oder Beziehungen zwischen den einzelnen Portlets nur schwer zu modellieren sind. Bezogen auf das Beispiel in der Abbildung 18 ist es somit lediglich möglich, dem Nutzer gleichzeitig zwei Portlets zur Verfügung zu stellen, in denen er jeweils getrennt die Daten für den Hotel- und den Flugdienst eintragen kann. Die Anfragen müssen einzeln abgesendet werden, genauso wie das Ergebnis nicht aggregiert sondern im jeweiligen Portlet zurückgeliefert wird. Daher wird diese Lösungsidee im weiteren Konzept nicht weiter verfolgt Bewertung Vorteil des Choreographieansatzes ist, dass für die Benutzerinteraktion keine Autorentätigkeiten notwendig sind. Die mit WS-CDL definierte Choreographie wird von den anbietenden Diensten erstellt und veröffentlicht, so dass diese vom Nutzer zur Laufzeit ausgewählt werden kann und von der Choreographiekomponente interpretiert und ausgeführt wird. Die Darstellung der Benutzerschnittstelle erfolgt anhand der Formatierungsdokumente der einzelnen Dienste, welche ebenfalls bereits zur Laufzeit zur Verfügung stehen. Diese werden von der Darstellungskomponente eingelesen und für die Generierung der Benutzeroberfläche verwendet. Der große Schwachpunkt dieser Idee ist jedoch die Komplexität der Choreographiekomponente. WS-CDL wurde dafür konzipiert, einen Geschäftsablauf zwischen mehreren Diensten aus technischer Sicht vertraglich festzulegen und anhand ebenjener Definition den eigenen Dienst entsprechend zu implementieren. Das ist vergleichbar mit dem Prinzip der Stub- Generierung bei verteilten Systemen. Idee bei WS-CDL ist, dass zunächst die WS-CDL- Beschreibung erstellt wird und dann anhand dieser Beschreibung jeder beteiligte Dienst seinen eigenen (elementaren oder wiederum komplexen) Dienst implementiert. Entsprechend umfangreich ist auch die WS-CDL-Spezifikation, da sie die Grundlage ist, um beispielsweise die Orchestration eines beteiligten Dienstes entsprechend zu realisieren. Für das bisher vorgestellte Konzept bei Verwendung eines Choreographieansatzes würde dies bedeuten, dass die Choreographiekomponente in der Lage sein muss, die WS-CDL- Beschreibung komplett zu interpretieren und auszuführen. Da in ihr auch Definitionen zur Nachrichtenkorrelation, Ablaufabhängigkeiten, Datentransformationen und weitere Details enthalten sind, käme die Komplexität und der Aufgabenbereich der Choreographiekomponente dem einer Orchestrierungs-Engine ziemlich nahe. Ein Beispiel für diese Komplexität ist die Nachrichtenabhängigkeit bei der parallelen Buchung von Flug und Hotel aus dem Szenario in Kapitel Schlägt die Buchung des Fluges aus irgendeinem Grund wie z.b. mangelnder Kapazität fehl, so soll auch die Buchung des Hotels nicht ausgeführt bzw. zurückgesetzt werden. Die Implementierung einer derart umfangreichen Anwendung würde den Rahmen dieser Arbeit sprengen. Da es sich beim Aufgabenbereich der Choreographiekomponente außerdem praktisch um den gleichen wie bei einer Orchestrierungs-Engine handelt, erscheint es sinnvoller, den Einsatz einer bestehenden und frei verfügbaren Orchestrierungs-Engine zu untersuchen und diese für den Prototyp zu verwenden. Da diese meistens auf der Prozessbeschreibungssprache BPEL basieren, soll im folgenden Kapitel untersucht werden, wie das bisherige Konzept derart verändert werden kann, so dass BPEL anstelle von WS-CDL zur Beschreibung des Geschäftsablaufs verwendet wird. Copyright TU-Dresden, Nicolás Bleyh 51

60 Konzept Orchestrationsansatz Der grundlegende Unterschied des Orchestrationsansatzes zum Choreographieansatz besteht darin, dass die Steuerung und der Ablauf der Geschäftslogik nicht über eine (neu zu entwickelnde) Choreographiekomponente, sondern über eine (bereits existierende) Orchestrierungs-Engine erfolgt. Daher wird der Geschäftsprozess auch nicht mehr durch eine Choreographiesprache wie WS-CDL sonder mittels einer Orchestrierungssprache beschrieben, wobei sich hiefür die Verwendung von BPEL anbietet, da dieser Standard die mit Abstand größte Verbreitung und Unterstützung besitzt. Da BPEL selber keine Sprachkonstrukte zur Definition von Benutzerinteraktionen zur Verfügung stellt, wird wiederum eine zusätzliche Komponente benötigt, die sich um die Integration der Benutzerschnittstelle kümmert. Über sie werden durch Nutzerinteraktionen Operationen aufgerufen, die in der zum BPEL-Prozess zugehörigen WSDL-Beschreibung veröffentlich sind. Um einen korrekten Geschäftsablauf zu gewährleisten, muss die Reihenfolge festgelegt werden, in der die angebotenen Operationen ausgeführt werden sollen. Hierfür eignet sich die Beschreibung eines abstrakten BPEL-Prozesses, der wie eine WS-CDL-Beschreibung ebenfalls öffentlich zugänglich ist (im Gegensatz zur ausführbaren BPEL-Prozessbeschreibung). Im Unterschied zu ausführbaren Prozessen können interne Details wie Datentransformationen oder der Aufruf externer Web Services weggelassen werden. Mit der Verwendung von abstrakten BPEL-Prozessen wird das Konzept des Behavioral Interface aus dem Kapitel verwirklicht. Da sich die Syntax abstrakter und ausführbarer BPEL-Prozesse nicht unterscheidet, können die bestehenden BPEL-Autorenwerkzeuge verwendet werden, um abstrakte BPEL-Prozessbeschreibungen zu erstellen. Bei der Beschreibung des Behavioral Interfaces eines BPEL-Prozesses kann zwischen einem statischen und einem dynamischen Ablauf des Geschäftsprozesses unterschieden werden Statischer Geschäftsablauf Für einen statischen Geschäftsablauf reicht es aus, lediglich die Sequenz der Operationsaufrufe zu definieren. In der BPEL Syntax geschieht dies durch das sequence-element. Alle weiteren strukturieren Aktivitäten (flow, scope,...) sind in diesem Kontext nicht sinnvoll, da sich um die eigentlich Komposition der Dienste die Orchestrierungs-Engine kümmert. Abgesehen davon wäre beispielsweise ein paralleler Aufruf von verschiedenen Operationen desselben Web Service (der, der durch die Orchestrierungs-Engine repräsentiert wird) nicht sinnvoll. Das folgende Codebeispiel zeigt die Beschreibung eines abstrakten BPEL-Prozesses, in dem der statische Geschäftsablauf einer Reisebuchung definiert wird. Dabei erfolgt zunächst die Einholung eines Reiseangebotes, woraufhin im Anschluss die Buchung der Reise getätigt werden kann. Zusammen mit der WSDL-Datei sind in der BPEL-Beschreibung die notwendigen Informationen enthalten, die für den Aufruf durch einen Nutzer notwendig sind. Während die WSDL-Beschreibung die Datentypen und Bindungsinformationen des angebotenen komplexen Web Service zur Verfügung stellt, definiert der abstrakte BPEL-Prozess die auszuführende Operationsreihenfolge und deren porttypes. Die Definition von partnerlinks ist eigentlich nicht notwendig, da es im Gegensatz zum ausführbaren BPEL-Prozess, der normalerweise mit mehreren externen Diensten kommuniziert, nur einen beteiligten Teilnehmer gibt, nämlich den Nutzer. Allerdings kann es durchaus sein, dass die abstrakte BPEL- Prozessbeschreibung auch von anderen Diensten zum Aufruf des Geschäftsprozesses genutzt wird. In diesem Fall würde der abstrakte Prozess mehrere partnerlink-elemente enthalten. Copyright TU-Dresden, Nicolás Bleyh 52

61 Konzept Um daher die Funktionalität der abstrakten Prozesse nicht unnötig einzuschränken, wird das partnerlink-attribut innerhalb der receive- und reply-aktivitäten trotzdem verwendet. <process abstractprocess="yes">... <sequence> <receive partnerlink="client" porttype="client:travelprocess" operation="gettravel"/> <reply partnerlink="client" porttype="client:travelprocess" operation="gettravel"/> <receive partnerlink="client" porttype="client:travelprocess" operation="booktravel"/> <reply partnerlink="client" porttype="client:travelprocess" operation="booktravel"/> </sequence> </process> Quellcode 14: Beispiel für die Beschreibung eines statischen Geschäftsablaufs mit BPEL Dynamischer Geschäftsablauf Neben einem statischen Ablauf der Operationsaufrufe kann die Reihenfolge jedoch auch dynamischer Natur sein. Für diesen Fall stellt BPEL die strukturierten Aktivitäten switch und while zur Verfügung, mit denen zur Laufzeit Einfluss auf die Operationsreihenfolge genommen werden kann. Dabei werden Abhängigkeiten im Bezug auf den Nachrichteninhalt festgelegt. Ausgewertet werden kann der Request (die Nachricht, die der Nutzer an den Dienst schickt) oder der Response (die Nachricht, die vom Dienst zurückgeliefert wird). Um diese Nachrichten auswerten zu können, ist es notwendig, in der Prozessbeschreibung Variablen zu definieren, denen der Nachrichteninhalt zugewiesen wird. Die Auswertung selber erfolgt mittels XPath-Funktionen, XPath-Ausdrücken und der BPEL-eigenen Funktion getvariabledata. Die folgende abstrakte Prozessbeschreibung illustriert ein Beispiel für einen dynamischen Ablauf, wobei es sich wieder um eine Reisebuchung handelt. Liefert die Operation gettravel keine Daten zu verfügbaren Flügen für eine bestimmte Nutzereingabe, so soll diese Funktion erneut aufgerufen werden, anstatt zur Buchungsfunktion fortzuschreiten. Zu diesem Zweck werden die nach dem Aufruf der Operation gettravel empfangene Nachricht der Variablen travelvar zugewiesen. Die Auswertung dieser Variablen erfolgt in der while-anweisung. Copyright TU-Dresden, Nicolás Bleyh 53

62 Konzept <process abstractprocess="yes">... <variables> <variable name="travelvar" element="gettravelresponse"/> </variables> <sequence> <receive partnerlink="client" porttype="client:travelprocess" operation="gettravel" /> <reply partnerlink="client" porttype="client:travelprocess" operation="gettravel" variable="travelvar"/> <while condition="bpws:getvariabledata('travelvar','count(//travel)'))=0"> <sequence> <receive partnerlink="client" porttype="client:travelprocess" operation="gettravel"/> <reply partnerlink="client" porttype="client:travelprocess" operation="gettravel" variable="travelvar"/> </sequence> </while> <receive partnerlink="client" porttype="client:travelprocess" operation="booktravel"/> <reply partnerlink="client" porttype="client:travelprocess" operation="booktravel"/> </sequence> </process> Quellcode 15: Beispiel für die Beschreibung eines dynamischen Geschäftsablaufs mit BPEL Idee der Ablaufsteuerungskomponente Das Beispiel des dynamischen Geschäftsablaufs zeigt, dass diese erweiterten Kontrollfunktionalitäten die Komplexität des BPEL-Codes stark erhöhen. Es wird daher eine Ablaufsteuerungskomponente eingeführt, die neben der Kontrolle des Ablaufs der Operationsaufrufe zusätzlich noch die empfangenen und gesendeten Nachrichten ausliest und anhand von XPath- Funktionen und -Ausdrücken auswertet. Es kann auch notwendig sein, mit Hilfe der assign- Aktivität Transformationsoperationen mit den Variablen vorzunehmen, um die so modifizierten Variablen als Entscheidungsgrundlagen für die Auswahl der als nächstes auszuführende Operation zu verwenden. Allerdings ist diese Aufgabe nicht unbedingt notwendig und kann besser von der Orchestrierungs-Engine erfüllt werden. Daher werden assign-aktivitäten in diesem Konzept nicht als Bestandteil von abstrakten BPEL-Prozessen angesehen. Die Ablaufsteuerungskomponente muss zur Bestimmung der Operationsreihenfolge nur eine Teilmenge der BPEL-Syntax interpretieren. Da der BPEL-Standard von der Syntax und dem Dokumentaufbau her keine Unterscheidung zwischen abstrakten und ausführbaren Prozessen macht, sollen im Folgenden die für eine abstrakte Prozessbeschreibung notwendigen Sprachkonstrukte aufgelistet werden: partnerlinks, partnerlink: Diese beiden Elemente sind optional und werden nur dann benötigt, wenn die abstrakte Prozessbeschreibung zusätzlich noch von anderen Diensten zum Aufruf des Prozesses verwendet wird. In diesem Fall müssen die einzelnen Aufrufer durch ein partnerlink-element eindeutig identifiziert werden, welches in den Interaktionselementen receive und reply referenziert wird. Ferner können diese Elemente bei einer Erweiterung des Konzeptes notwendig werden, falls die Komposition der Dienste nicht mehr durch eine Orchestrierungs-Engine sondern durch die Ablaufsteuerungskomponente erfolgt. Copyright TU-Dresden, Nicolás Bleyh 54

63 Konzept variables, variable: Variablen werden benötigt, falls die strukturierten Elemente switch oder while verwendet werden. Ihnen wird ein in der WSDL beschriebener oder Standard XML-Schema-Datentyp zugewiesen. Initialisiert werden die Variablen durch gesendete oder empfangen Nachrichten, wobei die Zuweisung in den Elementen receive oder reply erfolgt. receive, reply: Durch diese Elemente erfolgt die Kommunikation zwischen dem Client und dem komplexen Dienst. Da die Operationen durch den Nutzer über eine Webanwendung aufgerufen werden und es sich somit um eine synchrone Kommunikation handelt, wird auf eine Anfrage immer eine Antwort erwartet. Daher beinhaltet die Definition eines Operationsaufrufes immer eine receive- und eine anschließende reply-aktivität. Da es sich um die Realisierung einer Ziel-orientierten Nutzerinteraktion handelt, in welcher der Nutzer immer der Auslöser der Aktivitäten ist, reicht die Unterstützung des WSDL-Operationstyp request-response (siehe Kapitel 2.2.3) aus. sequence: Dieses Element repräsentiert den sequentiellen Ablauf und enthält elementare und/oder strukturierte Aktivitäten. switch, while: Durch diese beiden Konstrukte kann der Ablauf der Operationsaufrufe dynamisch beeinflusst werden. Hierfür werden mit Hilfe von XPath und der BPEL-eigenen Funktion getvariabledata die in der Prozessbeschreibung definierten und zur Laufzeit mit Ein- oder Ausgabenachrichten initialisierten Variablen ausgewertet. Um eine abstrakte Prozessbeschreibung auf ihre Korrektheit überprüfen zu können, wird ein XML-Schema definiert, welches nur oben aufgezählte Elemente beinhaltet, ansonsten aber weiterhin dem Schema der BPEL-Spezifikation genügt. Bei Verwendung von BPEL als Orchestrationssprache kann durch eine automatisch durchgeführte Transformation (z.b. durch XSLT) eine ausführbare in eine abstrakte Prozessbeschreibung überführt werden. Dies erleichtert den Autorenprozess, da sich der Entwickler so nur noch um die ausführbare BPEL- Beschreibung kümmern muss. Abbildung 19 verdeutlicht den hier vorgestellten Orchestrierungsansatz. Die Orchestrierungs- Engine muss dabei nicht lokal verfügbar sein, sondern kann von der Ablaufsteuerungskomponente auch auf einem entfernten Server angesprochen werden. Dabei ist das hier vorgestellte Konzept völlig unabhängig davon, was für eine Orchestrierungs-Engine verwendet wird. Es kann sich dabei um eine BPEL-Engine, aber z.b. auch um eine Java-Anwendung handeln. Entscheidend ist nur, dass das öffentliche Verhalten des komplexen Dienstes in Form eines abstrakten BPEL-Prozesses beschrieben ist. Zu den Aufgaben der Ablaufsteuerungskomponente gehört das Parsen und Interpretieren dieser abstrakten Prozessbeschreibung und die Verwaltung der eingehenden und abgehenden SOAP-Nachrichten. Anhand der so gewonnenen Informationen wird die Operationsreihenfolge bestimmt. Dies geschieht mit Hilfe einer Zustandsvariable, die anzeigt, welche Operation gerade ausgeführt wurde, so dass der Nutzer die Operationen in der korrekten Reihenfolge über ein Benutzerinterface aufrufen kann. Abbildung 19: Orchestrationsansatz mit einer abstrakten BPEL-Prozessbeschreibung als Behavioral Interface Copyright TU-Dresden, Nicolás Bleyh 55

64 Konzept Vorteil an diesem Konzept ist, dass mit BPEL eine existierende und weit verbreitete Sprache eingesetzt werden kann. Allerdings besitzt es nicht die gleiche Flexibilität wie der in Kapitel diskutierte Choreographieansatz. Dort wird nur das WS-CDL-Dokument benötigt, um die Benutzerinteraktion mit einem komplexen Web Service zu realisieren. Beim Orchestrierungsansatz muss dagegen eine Orchestration beschrieben und ausgeführt werden, z.b. in einer BPEL-Engine. Dies stellt hohe Anforderungen an das Vorhandensein einer technischen Infrastruktur und an den Autorenprozess. Trotz dieses erhöhten Aufwandes erscheint es Aufgrund der klaren Vorteile von BPEL gegenüber WS-CDL (siehe Kapitel 4.1.4) und der in Kapitel genannten Nachteile des Choreographieansatzes erfolgsversprechender, den Orchestrationsansatz für das Konzept GUI4CWS zu verwenden. 5.2 Darstellung Zur Generierung der Benutzeroberfläche für einen komplexen Dienst baut das Konzept dieser Arbeit auf WSGUI und den darin verwendeten XForms auf (siehe Kapitel und ). Somit erfolgt die nutzerfreundliche und plattformunabhängige Benutzerschnittstellenbeschreibung in der GUIDD. Sie wird zusätzlich zur WSDL vom komplexen Dienst angeboten und für die Generierung der Benutzeroberfläche verwendet. In dem hier vorgestellten Konzept besitzt der komplexe Web Service eine einzige GUIDD. Für den Autor des komponierten Web Service bedeutet dies, dass er neben der Komposition der Dienste auch eine GUIDD erstellen muss, falls er eine nutzerfreundliche Benutzerschnittstelle anbieten möchte. Um den Autorenprozess zu vereinfachen, wäre eine mögliche Verbesserung von GUI4CWS, wenn jeder beteiligte Web Service für seine angebotenen Operationen eine GUIDD zur Verfügung stellt. Dadurch ist auch eine Wiederverwendung der GUIDDs der einzelnen Web Services möglich. Soll z.b. ein bestehender komplexer Web Service um zusätzlichen Web Services erweitert werden, so muss der Autor nicht jedes Mal eine neue GUIDD erstellen, da GUI4CWS jeweils die passende GUIDD der involvierten Web Services verwendet. Allerdings geht dieser Ansatz erneut in die Richtung einer Choreographie. Die Komplexität von GUI4CWS wird dadurch enorm erhöht, da zur aktuellen Operation des komplexen Dienstes die passenden GUIDDs der beteiligten elementaren Dienste interpretiert und deren Inhalte entsprechend aggregiert werden müssen, um die Benutzeroberfläche zu generieren. Ein weiteres auftretendes Problem ist, wenn das von der Orchestrierungs-Engine zurückgelieferte Ergebnis eine Fehlermeldung ist. Ein Beispiel wäre, wenn die Orchestrierungs-Engine zwei Web Services parallel aufruft, aber nur einer ein gültiges Ergebnis liefert, so dass die Orchestrierungs-Engine auf die Anfrage von GUI4CWS mit einer Fehlermeldung antwortet. In diesem Fall existiert keine Beschreibung, wie diese Fehlermeldung grafisch dargestellt werden soll, da die von der Orchestrierungs-Engine zurück gelieferte SOAP-Nachricht keiner GUIDD zugeordnet werden kann. Für diese Art von Fehlermeldungen müsste auch für den BPEL-Prozess eine GUIDD erstellt werden. Aus diesen Gründen existiert im Konzept von GUI4CWS für jeden komplexen Dienst nur eine GUIDD. Bei der Generierung einer Benutzerschnittstelle kann zwischen zwei Varianten unterschieden werden: einer statischen und einer dynamischen. In der statischen Darstellung wird die Eingabemaske anhand der in der WSDL-Beschreibung definierten Operation und der zugehörigen Datentypen erstellt. Diese Variante wird auf jeden Fall für die erste Operation, die durch eine Benutzerinteraktion innerhalb eines komplexen Dienstes ausgeführt werden soll, verwendet. Für die darauf folgenden Operationen kann eine dynamische Generierung notwendig sein, d.h. dass die Benutzeroberfläche zum Aufruf einer Operation abhängig von den Ergebnissen Copyright TU-Dresden, Nicolás Bleyh 56

65 Konzept der davor ausgeführten Operation ist. Die Umsetzung dieser beiden Varianten wird in den folgenden beiden Unterkapiteln erläutert Statische Generierung Anhand der Operations- und Datentypbeschreibung innerhalb der WSDL-Datei wird für jede Operation automatisch ein XForms model erstellt. In der GUIDD sind vom Autor die zugehörigen form controls, mit denen die Dateninstanz innerhalb des model durch Benutzerinteraktionen gefüllt werden kann, definiert. In diesen form controls erfolgt eine nutzerfreundliche Beschriftung der Eingabemaske. Dadurch, dass der Datentyp der einzugebenden Daten durch ein XML-Schema innerhalb der WSDL-Beschreibung festgelegt ist, können die Benutzereingaben vor dem Versenden zusätzlich auf ihre Korrektheit hin überprüft werden. XForms sind nicht an ein Endgerät oder eine Plattform gebunden sind, so dass die so erstellten Formulare in unterschiedliche Beschreibungssprachen eingebettet werden können, wie beispielsweise XHTML oder WML. Wird der XForms-Standard auf Benutzerseite nicht unterstützt, kann durch XSL-Stylesheets eine Umwandlung in ein adäquates Pendant wie z.b. HTML- Formulare erfolgen. In der Abbildung 20 werden die einzelnen Transformationsschritte von der WSDL- zur Benutzerschnittstellenbeschreibung dargestellt. Die vom Dienst bereitzustellenden Dokumente sind dabei die durch WSDL erfolgte Schnittstellenbeschreibung, welche die XML-Schema- Definitionen der verwendeten Datentypen enthält, und die GUIDD. Die XForms selber bestehen aus dem automatisch aus dem XML-Schema generierten Dateninstanzen und den in der GUIDD beschriebenen form controls. Abbildung 20: Transformationsweg von WSDL zu einer geräteunabhängigen Benutzeroberfläche Außer der Benutzeroberfläche für die erste und letzte Seite des Operationsablaufs werden immer zwei XForms model verwendet. Ein model enthält eine (normalerweise) leere Dateninstanz, welche über die Eingabeelemente (= form controls) gefüllt und an den Dienst gesendet wird. Das zweite model besteht aus einer (gefüllten) Dateninstanz, welche die Ergebnisse der vorherigen Operation enthält. Werte dieser Instanz können durch das XForms output- Copyright TU-Dresden, Nicolás Bleyh 57

66 Konzept Element über einen XPath-Ausdruck referenziert und dargestellt werden. Folgt eine weitere Operation, so wird die Eingabemaske dieser Operation unter der Ergebnisdarstellung platziert. Für den Fall, dass die Ausgabewerte der einen Operation die Eingabemaske der Nachfolgenden beeinflussen, muss das bisherige Vorgehen zur Generierung der Benutzeroberfläche erweitert werden. Dies wird im folgenden Kapitel vorgestellt Dynamische Generierung Bei der dynamischen Variante der Generierung einer Benutzeroberfläche wird zusätzlich zu den WSDL-Daten noch das Ergebnis des letzten Operationsaufrufs verwendet, welches als SOAP-Nachricht vorliegt. Das XForms-Formular wird mit den dort enthaltenen Daten in der Art erweitert, dass für den darauf folgenden Operationsaufruf eine adäquate Eingabemaske generiert werden kann. Ein Beispiel hierfür ist das Ergebnis einer Anfrage nach verfügbaren Flügen. In der darauf folgenden Benutzerinteraktion soll einer dieser Flüge zur Buchung ausgewählt werden. Für die Buchungsoperation muss es möglich sein, einen der zurückgelieferten Flüge auszuwählen, z.b. über eine Liste. Hier werden die Defizite eines statisch generierten XForms-Formulars deutlich. Dieses basiert lediglich auf der WSDL-Beschreibung und der GUIDD. Anhand der in der WSDL- Beschreibung definierten Datentypen können für eine Operation nur standardisierte Eingabemasken automatisch generiert werden. Auch auf die Gestaltung der Benutzeroberfläche in Abhängigkeit der zurückgelieferten Daten der vorher ausgeführten Operation kann bei der statischen Generierung kein Einfluss genommen werden. Um eine dynamische Generierung zu erreichen, gibt es mehrere Möglichkeiten. So könnte der Autor beispielsweise für jede angebotene Operation ein XSLT zur Verfügung stellen, welches sich um die Transformation der von der Operation zurückgelieferten SOAP-Nachricht in ein XForms-Formular kümmert. Allerdings steigt damit der Aufwand des Autors, da er für jede angebotene Operation ein entsprechendes XSLT erstellen muss. Zwar würde in diesem Fall keine GUIDD mehr benötigt, allerdings ist der Erstellungsprozess einer XSLT um einiges aufwendiger als der einer GUIDD. Daher soll versucht werden, eine Lösung ohne ein zusätzlich zu erstellendes Dokument zu finden. Dabei wurden zwei Szenarien einer mehrstufigen Benutzerinteraktion (also Benutzerinteraktionen, mit mehr als einem Operationsaufruf) identifiziert, bei der die Ergebnisse der vorhergehenden Operation Einfluss auf die Eingabemaske der nachfolgenden Operation besitzen, da die vorhergehende Operation jeweils Werte liefert, die für die nachfolgende Operation benötigt werden. Hier wird deutlich, dass die Definition der Reihenfolge der Operationsaufrufe auch auf die Darstellung der Benutzerschnittstelle Auswirkungen hat. Die beiden Szenarien unterscheiden sich konzeptionell gesehen in ihrer Auswirkung auf die XForms Elemente. Während beim ersten Szenario das model modifiziert werden muss, werden beim zweiten Szenario die form controls beeinflusst Vorlagewerte Es kann notwendig sein, dass Formularfelder zum Aufruf einer Operation durch Rückgabewerte der vorhergehenden Operation als Vorlage gefüllt sein sollen. Ein Anwendungsbeispiel hierfür ist das Ändern von Kundendaten. Mit der ersten Operation werden die Daten eines bestimmten Kunden geliefert. Die zweite Operation soll es ermöglichen, diese Kundendaten zu ändern. Um dies nutzerfreundlich zu realisieren, stehen die angeforderten Kundendaten als Vorlage in den entsprechenden Eingabefeldern (Name, Vorname,...), damit sie in diesen ge- Copyright TU-Dresden, Nicolás Bleyh 58

67 Konzept ändert und an die zweite Operation, welche die Änderung vornimmt, abgeschickt werden können. Für dieses Szenario müssen Eingabefelder mit Werten vorbelegt werden können. Mit XForms ist dies möglich, indem im model Daten in die Instanz eingegeben werden. Das model wird, wie bereits in Kapitel erklärt, automatisch aus den XML-Schema-Datentypen der WSDL generiert, allerdings normalerweise ohne vordefinierte Werte. Die vordefinierten Werte werden aus der SOAP-Nachricht der vorhergehenden Operation extrahiert und in das model eingefügt. Hierbei stellt sich das Problem, wie automatisch erkannt wird, ob zurückgelieferte Werte als Anfangswerte für die folgende Operation verwendet werden sollen. Eine maschinenlesbare semantische Beschreibung der Daten wäre wünschenswert, anhand der eine semantische Gleichheit der zurückgelieferten und einzugebenden Daten festgestellt werden kann. Da die über Web Services ausgetauschten Daten normalerweise jedoch keine semantische Beschreibung besitzen, wird im Konzept dieser Arbeit lediglich die Namens- und Typgleichheit der Elemente überprüft. Diese beiden Informationen sind jeweils aus der WSDL-Beschreibung ersichtlich, da sowohl Eingabe- als auch Ausgabeparameter der Operationen definiert sind. Ist der Elementname und der Datentyp in der der empfangenen SOAP-Nachricht mit einem des für den folgenden Operationsaufrufes notwendigen Elementes identisch, wird im Datenmodell das Element dieses Namens mit dem Wert des entsprechenden Elements der SOAP-Nachricht gefüllt. Zur Verdeutlichung soll die folgende Abbildung dienen. Zunächst wird ein leeres Datenmodell aufgrund des XML-Schemas generiert, welches für den folgenden Operationsaufruf benötigt wird. Da der Datentyp des Eingabeparameters identisch ist mit dem Ausgabeparameter der vorherigen Operation, werden die Werte des <fname> und <lname> Elements aus der empfangenen SOAP-Nachricht ausgelesen und in das leere model übernommen, wodurch sie als Vorlagenwerte dienen Auswahlwerte Abbildung 21: Darstellung von Vorlagewerten Im zweiten Szenario werden die Ausgabeparameter einer Operation zwingend als Eingabeparameter der nachfolgenden Operation benötigt. Notwendig wird dies, wenn, wie im Beispiel in Kapitel gezeigt, eine List mit mehreren Werten zurückgeliefert wird und für die nächste Operation einer oder mehrere dieser als Eingabewerte benötigt wird. Dem Nutzer muss also eine Benutzerinterface zur Verfügung gestellt werden, dass diese Auswahl ermöglicht. Copyright TU-Dresden, Nicolás Bleyh 59

68 Konzept Auch hier besteht die Möglichkeit, für jede Operation ein XSLT zu erstellen, so dass die als SOAP-Nachricht zurückgelieferten Ausgabewerte in die entsprechende Eingabemaske transformiert werden. Die Nachteile dieses Ansatzes wurden bereits im vorhergehenden Kapitel diskutiert. Deshalb wird die Syntax von WSGUI um einen Platzhalter namens <items> erweitert. Dieser wird in der GUIDD verwendet und markiert die Stelle, an der auf Grundlage einer empfangenen SOAP-Nachricht dynamisch eine XForms-Liste generiert wird. Die Transformation der SOAP-Nachricht in die XForms-Syntax erfolgt über ein internes Standard XSLT. Wie bereits beim Szenario der Vorlagewerte wird anhand des Datentyps des Rückgabewertes einer Operation erkannt, ob dieser Wert für die Eingabemaske der folgenden Operation benötigt wird. Handelt es sich beim Datentyp des Rückgabewertes einer Operation um eine Liste, so wird diese für die Eingabemaske der folgenden Operation verwendet, sofern anhand der Ablaufdefinition eine nachfolgende Operation existiert. In der GUIDD wird lediglich definiert, um was für eine Liste es sich handelt, also ob mehrere Elemente oder nur ein Element ausgewählt werden kann. Der folgende GUIDD-Codeausschnitt zeigt eine solche Definition mit dem Platzhalter <items>. <select1 ref="/bookflight/flights"> <label>verfügbare Flüge:</label> <items/> </select1> Quellcode 16: Definition einer dynamischen Auswahlliste in der GUIDD Nach dem Empfang der SOAP-Nachricht und der XSL-Transformation sind die Listenelemente entsprechend eingefügt, wie der Quellcode 17 zeigt. <select1 ref="bookflight"> <label>verfügbare Flüge:</label> <item> <label>frankfurt Rom </label> <value>10089</value> </item> <item> <label>frankfurt Rom </label> <value>10127</value> </item> </select1> Quellcode 17: Automatisch generierte Listenelemente Ein Listenelement besteht immer aus einer Beschriftung und einem Wert, der bei Auswahl des entsprechenden Elementes in die entsprechende Dateninstanz eingefügt und an den Dienst geschickt wird. Allerdings kann den Elementen der als Rückgabewert empfangenen Liste nicht automatisch entnommen werden, welcher Wert dem label- und welcher dem value- Element zugeordnet werden soll. Eine Möglichkeit ist, dass das label in der GUIDD definiert wird, so dass nur noch der value-wert aus der SOAP-Nachricht ermittelt wird. Vorteil dieser Lösung ist, dass sich der Autor der GUIDD um die (internationale) Beschriftung der Listenelemente kümmert und dies nicht Aufgabe des Dienstes ist. Nachteil ist, dass der dynamische Charakter verloren geht, da der Autor bereits zur Entwicklungszeit die label- Werte der Listenelemente definiert. Wird auf die Hilfestellung der GUIDD verzichtet, muss festgelegt werden, welche Elemente der zurückgelieferten Liste den label- und welche den value-wert enthalten. Die in der Liste enthaltenen XML-Instanzen dürfen somit maximal Copyright TU-Dresden, Nicolás Bleyh 60

69 Konzept zwei Elemente besitzen. Bei XML-Instanzen mit einem Element werden den Elementen label und value eines Listeneintrags die gleichen Werte zugewiesen Fehlermeldungen Bei der Kommunikation mit dem komponierten Dienst können zwei unterschiedliche Fehlersituationen auftreten. Zum einen kann die SOAP-Kommunikation zwischen GUI4CWS und der Orchestrierungs-Engine scheitern. Das Abfangen dieser Ausnahmesituation geschieht innerhalb von GUI4CWS, so dass der Nutzer durch eine standardisierte Fehlermeldung, auf die der Autor keinen Einfluss besitzt, vom Scheitern des Nachrichtenaustausches informiert wird. Bei der zweiten Fehlersituation tritt die Ausnahme bei der Komposition der beteiligten Dienste auf. Dies kann z.b. der Fall sein, wenn die SOAP-Kommunikation mit einem beteiligten Dienst scheitert, oder ein Dienst einen Rückgabewert liefert, der von der Orchestrierungs- Engine nicht verarbeitet werden kann. In diesem Fall kann in der Orchestrierungs-Engine eine Ausnahmebehandlung definiert werden, die bestimmt, welche Nachricht im Fehlerfall an GUI4CWS gesendet wird. Damit GUI4CWS diese Fehlernachricht auch interpretieren kann, muss bei der Beschreibung der Operationsdefinition neben der Ein- und Ausgabenachricht ein zusätzlicher Nachrichtentyp hinzugefügt werden, der diese im Fehlerfall vom Dienst zurückgeschickt Nachricht beschreibt. Der Autor kann die Darstellung dieser Fehlernachricht in der GUIDD mittels eines form control (über das Element output) bestimmen, da die Fehlernachricht als Instanz innerhalb des model vorliegt. 5.3 Architektur Die Abbildung 22 gibt einen Überblick über die in dieser Arbeit entwickelte Gesamtarchitektur zur Realisierung der im vorherigen Kapitel genannten Ziele. Die Hauptbestandteile dieser Architektur sind: Eine Orchestrierungs-Engine zur Ausführung des komplexen Dienstes. Eine Interaktionskomponente zum Aufruf der Operationen des komplexen Dienstes. Sie kümmert sich um das Versenden und Empfangen der SOAP-Nachrichten und um die Kommunikation mit dem Client. Eine Ablaufsteuerungskomponente, welche die Abfolge der Operationsaufrufe aus der Sicht des Nutzers regelt. Eine Darstellungskomponente, deren Aufgabe die Generierung der Benutzerschnittstelle ist. Während die Orchestrierungs-Engine auf einen externen Server ausgelagert werden kann, sind die Interaktions-, Ablaufsteuerungs- und Darstellungskomponente Bestandteil der GUI4CWS- Anwendung. Copyright TU-Dresden, Nicolás Bleyh 61

70 Konzept Abbildung 22: Gesamtarchitektur Im Folgenden sollen die vier Bestandteile der Architektur und deren Zusammenspiel miteinander ausführlicher vorgestellt werden Komposition der Dienste Zunächst muss die Komposition der verschiedenen Dienste zu einem komplexen Web Service erfolgen. Dies kann z.b. mit Hilfe der Kompositionsbeschreibungssprache BPEL und einer zugehörigen BPEL-Engine erfolgen. Generell ist das hier vorgestellte Konzept jedoch unabhängig davon, wie die Komposition der Dienste erfolgt. Entscheidend ist nur, dass der Autor eines komplexen Dienstes die folgenden drei Dokumente veröffentlicht, um das Zusammenspiel mit GUI4CWS zu ermöglichen: Das ist zum einen die WSDL-Beschreibung, die der komplexe Dienst wie jeder elementare Web Service veröffentlicht. Abgesehen von den benötigten Verbindungsdaten zum Aufrufen der Operationen wird die dort enthaltene Beschreibung der verwendeten Datentypen von der Darstellungskomponente für die Generierung der passenden Benutzerschnittstelle verwendet. Beim zweiten Dokument handelt es sich um die Beschreibung des abstrakten BPEL- Prozesses. Darin wird die Abfolge der Operationsaufrufe, gegebenenfalls in Abhängigkeit der gesendeten oder empfangenen SOAP-Nachrichten, definiert. Dieses Dokument wird von der Ablaufsteuerungskomponente benötigt, um den Nutzer korrekt durch den Prozess zu führen. Das dritte Dokument ist die GUIDD, wodurch die Darstellungskomponente bei der Generierung einer nutzerfreundlichen Benutzerschnittstelle zum Aufrufen der Operationen des komplexen Dienstes unterstützt wird. Im Gegensatz zu den beiden vorherigen Dokumenten ist die GUIDD jedoch optional, da notfalls auf eine nutzerfreundliche Beschriftung der anhand der WSDL generierten Formulare verzichtet werden kann. Das Zusammenspiel zwischen den Dokumenten und den einzelnen Bestandteilen von GUI4CWS zeigt die Abbildung 23. Copyright TU-Dresden, Nicolás Bleyh 62

71 Konzept Interaktionskomponente Abbildung 23: Von GUI4CWS verwendete Dokumente Die Interaktionskomponente kümmert sich um den Nachrichtenaustausch von GUI4CWS mit dem komplexen Dienst und dem Client. Für die Interaktion mit der Orchestrierungs-Engine wird die veröffentlichte WSDL-Beschreibung verwendet, in welcher der Kommunikationsendpunkt (bzw. Kommunikationsendpunkte) des Dienstes und das verwendete Transportprotokoll und Nachrichtenformat definiert ist. Die Nachrichten werden dabei im SOAP-Format an die Orchestrierungs-Engine verschickt und empfangen. Die Ablaufsteuerungskomponente teilt der Interaktionskomponente mit, welche Operation aktuell auszuführend ist. Zusätlich zur Operation wird der zugehörige porttype übergeben, da die gleiche Operation unterschiedlichen porttypes und somit unterschiedlichen Kommunikationsendpunkten zugeordnet sein kann. Mit diesen Informationen und den aus der empfangenen SOAP-Nachricht extrahierten Daten wird von der Darstellungskomponente eine Benutzerschnittstelle angefordert und an den Client gesendet. Durch die Verwendung von XForms werden die Nutzereingaben als XML empfangen, so dass diese in einen SOAP-Body verpackt und an den komponierten Dienst geschickt werden Ablaufsteuerungskomponente Die Ablaufsteuerungskomponente kümmert sich um die korrekte Abfolge der Operationsaufrufe. Dieser Ablauf wird von der Orchestrierungs-Engine mit Hilfe einer abstrakten BPEL- Prozessbeschreibung veröffentlicht. Aufgabe der Komponente ist es, diese Beschreibung zu parsen und den aktuellen Prozesszustand zu speichern. Die Ablaufsteuerungskomponente kommuniziert sowohl mit der Interaktions- als auch mit der Darstellungskomponente. Bei jedem Senden und Empfangen von SOAP-Nachrichten ruft die Interaktionskomponente die Ablaufsteuerungskomponente auf. Dabei wird zum einen der Prozessstatus inkrementiert, d.h. ein virtueller Zeiger wird auf die nächste reply- oder receive-aktivität in der Prozessbeschreibung gesetzt. Bei einer Anfrage nach dem aktuellen Prozessstand wird eine dieser beiden Aktivitäten zurückgeliefert, denen ein Operationsname, ein WSDL porttype und optional eine in BPEL definierte Variable zugeordnet ist (was den Attributen eines receive- bzw. reply-elements entspricht). Strukturierte Aktivitäten werden nicht zurückgeliefert, da diese für die Kommunikation nicht benötigt und intern in der Ablaufsteuerungskomponente ausgewertet werden. Neben der Verwaltung des Prozessstatus werden von der Ablaufsteuerungskomponente die Variablen, die in der Prozessbeschreibung mit receive- oder reply-aktivitäten assoziiert sind, anhand der empfangenen bzw. zu versendenden Daten initialisiert. Die so gesetzten Variablen können bei einem dynamischen Copyright TU-Dresden, Nicolás Bleyh 63

72 Konzept Ablauf in while- oder switch-konstrukten ausgewertet werden und so den weiteren Ablauf der Operationsaufrufe beeinflussen Darstellungskomponente Die Hauptaufgabe der Darstellungskomponente ist die Generierung einer Benutzeroberfläche, mit der durch menschliche Interaktion ein komplexer Web Service angesprochen werden kann. Dabei ist die Kommunikation mit der Ablaufsteuerungskomponente notwendig, um anhand des aktuellen Prozesstandes den Operationsnamen zu ermitteln. Mit Hilfe dieser Information kann durch die vorliegende WSDL-Beschreibung und GUIDD ein entsprechendes Formular generiert werden. Im Wesentlichen wird hier das WSGUI-Konzept (Kapitel ) übernommen, das für die Benutzereingaben den XForms-Standard verwendet. Die vom komplexen Web Service zurückgelieferten Daten werden von der Interaktionskomponente zur Verfügung gestellt. Wie die Generierung einer Benutzeroberfläche anhand der GUIDD, der empfangenen XML-Daten und WSDL-Beschreibung erfolgt, ist im Kapitel 5.2 bereits ausführlich beschrieben worden. Innerhalb der Darstellungskomponente kann im Bezug auf den aktuellen Prozessstand zwischen drei Zuständen unterschieden werden: dem Anfangszustand, Zwischenzustand und Endzustand. Die Unterscheidung ist deshalb wichtig, weil jeweils eine andere Zusammenstellung der form controls erfolgt. Im Anfangszustand existieren noch keine vom Dienst empfangenen Ergebnisse, so dass keine output-elemente verwendet werden. Im Zwischenzustand müssen dagegen sowohl form controls zur Eingabe als auch zur Ausgabe von Daten verwendet werden. Dabei muss bei den empfangenen Daten unterschieden werden, ob sie Grundlage für den nächsten Operationsaufruf und damit Bestandteil des Eingabeformulars sind, oder ob sie lediglich zur Ausgabe vorgesehen sind (siehe Kapitel 5.2.2). Im Endzustand wiederum werden keine Eingabeformulare mehr angezeigt, sondern lediglich die zuletzt empfangen Daten dargestellt, da laut der Prozessbeschreibung keine weiteren Operationen folgen. Die Information, in welchem dieser drei Zustände sich die Anwendung befindet, liefert wiederum die Ablaufsteuerungskomponente. Zusätzlich zu den generisch erstellten Interaktionselementen besitzt jede Formularseite zwei Standard Steuerungselemente zum Abschicken der Formulardaten an die Serveranwendung und zum Abbrechen des Prozesses. Diese sind auf jeder Seite vorhanden und damit unabhängig von der generierten Benutzeroberfläche. Wird ein Prozess abgebrochen, so wird dem Nutzer wieder das Formular für die erste in der abstrakten BPEL-Prozessbeschreibung definierte Operation geliefert. Somit kann der Nutzer jederzeit einen Geschäftsprozess abbrechen und wieder von der Einstiegsoperation aus starten Beispielhafter Programmablauf Der folgende beispielhafte Ablauf soll das Zusammenspiel der Komponenten von GUI4CWS verdeutlichen. Als Grundlage soll dabei die im Quellcode 15 dargestellte abstrakten Prozessbeschreibung dienen: 1. Zu Beginn kann der Nutzer über ein öffentliches Verzeichnis wie z.b. UDDI einen komplexen Dienst auswählen. 2. Beim ersten Aufruf des Dienstes werden die abstrakte BPEL-Prozessbeschreibung, die WSDL-Beschreibung und die GUIDD geladen und in einer Sitzungsvariable gespeichert, auf die alle drei Komponenten von GUI4CWS Zugriff haben. Copyright TU-Dresden, Nicolás Bleyh 64

73 Konzept 3. Die Interaktionskomponente ruft bei der Ablaufsteuerungskomponente den aktuellen Prozessstand ab. Diese liefert die als erstes auszuführende Aktivität, nämlich ein receive mit der Operation gettravel. 4. Die Aktivitätsdaten werden an die Darstellungskomponente weitergeleitet, anhand derer sie mit Hilfe der WSDL-Beschreibung und der GUIDD ein nutzerfreundliches XForms-Formular erstellt. 5. Das XForms-Formular wird von der Interaktionskomponente an den Nutzer gesendet. 6. Die vom Nutzer eingegebenen Daten werden von der Interaktionskomponente ausgelesen und in einer SOAP-Nachricht verpackt, die an den komplexen Dienst gesendet wird. Der zugehörige Kommunikationsendpunkt des porttypes der Operation wird der WSDL-Beschreibung entnommen. Nach dem SOAP-Aufruf wird bei der Ablaufsteuerungskomponente die nächste Aktivität abgefragt. Diese liefert ein reply. 7. Da der aktuellen reply-aktivität eine Variable zugeordnet ist, werden die Daten der vom komplexen Web Service empfangenen SOAP-Nachricht der Variable travelvar zugewiesen. Die Auswertung dieser Variable erfolgt in der strukturieren Aktivität while. Anschließende wird bei der Ablaufsteuerungskomponente wieder die nächste Aktivität (receive) abgefragt. Für den weiteren Programmablauf wird wieder zu 4. gesprungen. 5.4 Autorenprozess Um einen komplexen Dienst mit einer menschlichen Benutzerschnittstelle zu erstellen, sind diverse Autorentätigkeiten notwendig. Diese sollen hier kurz erläutert werden. Zunächst muss die Komposition der beteiligten Dienste erfolgen. Diese kann entweder über eine Anwendung implementiert werden, oder über eine Orchestrationssprache und -Engine. Letzteres wird aufgrund der höheren Flexibilität und besseren Wartbarkeit empfohlen (zu den Vorteilen siehe Kapitel 4.1 und 4.1.3). Eine ausführliche Beschreibung des Autorenprozesses bei der Erstellung eines komplexen Dienstes findet sich im Kapitel 6.1. Als nächstes muss die Schnittstelle des komponierten Dienstes erstellt werden. Da es sich um einen Web Service handelt, wird hierfür eine WSDL-Beschreibung verwendet. Erfolgt die Komposition der Dienste über eine Java-Anwendung, so kann z.b. das Tool Apache Axis verwendet werden, welches die WSDL-Beschreibung automatisch generiert. Unabhängig davon, wie der komplexe Dienst implementiert wird, muss dessen öffentliches Verhalten als abstrakte BPEL-Prozessbeschreibung definiert werden. Wird BPEL bereits zur Beschreibung der Komposition verwendet, so kann durch eine Transformation aus dieser Beschreibung der zu veröffentlichende abstrakte BPEL-Prozess generiert werden, da dessen Syntax lediglich aus einer Untermenge der BPEL-Konstrukte besteht (siehe Kapitel 5.1.2). Theoretisch könnte für die Ablaufsteuerung auch der eigentliche, ausführbare BPEL-Prozess verwendet werden. Dies ist jedoch oftmals nicht wünschenswert, da damit auch Details des Geschäftsprozesses wie beispielsweise Datentransformationen oder Aufrufe beteiligter Dienste offen gelegt werden, die nicht für die Öffentlichkeit bestimmt sind. Daher sollten in der abstrakten Prozessbeschreibung nur die Informationen enthalten sein, die für die Ablaufsteuerung auch benötigt werden. Erfolgt die Komposition der Dienste nicht mit BPEL, so muss die abstrakte BPEL-Prozessbeschreibung per Hand erstellt werden. Dazu können allerdings zahl- Copyright TU-Dresden, Nicolás Bleyh 65

74 Konzept reiche BPEL-Autorenwerkzeuge verwenden werden, solange die in Kapitel vorgestellte eingeschränkte BPEL-Syntax für abstrakte Prozessbeschreibungen berücksichtigt wird. Um eine nutzerfreundliche Oberfläche zur Interaktion mit dem komplexen Dienst zu bieten, kann eine GUIDD erstellt werden. Bisher gibt es hierfür jedoch keine Autorentools, so dass diese mit Hilfe eines Text- bzw. XML-Editors erzeugt werden muss. Wird ein komplexer Dienst ohne GUIDD veröffentlicht, so werden als Beschriftung die Bezeichnungen innerhalb der WSDL-Beschreibung angezeigt. 5.5 Zusammenfassung In diesem Kapitel sollen noch einmal die grundlegenden Aspekte des in dieser Arbeit erstellten Konzeptes zur Erreichung von Benutzerinteraktionen in komplexen Web Service zusammengefasst werden. Die verwendeten Technologien sind dabei, neben den Web-Service- Standards, WSGUI, XForms und BPEL. Die eigentliche Komposition der Dienste erfolgt durch eine Orchestrierungs-Engine. Um eine Nutzerinteraktion mit dem komplexen Dienst zu ermöglichen, veröffentlicht die Orchestrierungs-Engine eine WSDL-Beschreibung, eine (optionale) GUIDD und eine abstrakte BPEL-Prozessbeschreibung des komponierten Dienstes. Die Interaktion des Clients mit dem komplexen Dienste erfolgt über GUI4CWS. Diese kann anhand der von der Orchestrierungs-Engine veröffentlichten WSDL-Beschreibung und GUIDD nutzerfreundliche XForms-Formulare zum Aufruf der angebotenen Operationen generieren. Anhand der abstrakten BPEL-Prozessbeschreibung bestimmt GUI4CWS ferner, ob und in welcher Reihenfolge die den angebotenen Operationen zugeordneten Formulare angezeigt werden. Vorteile der hier entwickelten Lösung sind die Folgenden: Die eigentliche Orchestrierung und somit die gesamte Geschäftsprozesslogik wird auf eine Orchestrierungs-Engine ausgelagert. Somit kann der Autor selbstständig bestimmen, wie die verschiedenen Dienste komponiert werden. Dies kann mit Hilfe einer BPEL-Engine, aber z.b. auch mit einer Java-Anwendung erreicht werden. Allerdings bietet sich zur Orchestrierung die BPEL-Technologie an, da diese erstens eine breite Unterstützung der Industrie erfährt, und zweitens durch die Trennung der Geschäftslogik vom Programmcode eine weitaus höhere Flexibilität und bessere Wartbarkeit als bei einer reinen Softwareanwendung gegeben ist. Egal auf welche Art der komplexe Dienst letztendlich komponiert ist, für den Client ist nur das öffentliche Verhalten des komplexen Dienstes entscheidend. Die Beschreibung dieses Verhaltens erfolgt durch eine abstrakte BPEL-Prozessbeschreibung. Dadurch kann zum einen die relativ ausgereifte BPEL-Syntax verwendet werden, zum andere ist es möglich, die abstrakte Prozessbeschreibung mit BPEL-Designern zu erstellen, von denen zahlreiche kostenlos zur Verfügung stehen. Durch die Verwendung von GUIDDs zur benutzerfreundlichen Darstellung wird eine Trennung der Darstellung von der Programmlogik erreicht. Dies unterstützt wiederum die Flexibilität und setzt damit das Model-View-Controller-Paradigma aus der Softwaretechnologie um. Dabei entspricht die GUIDD dem View, die WSDL dem Model und die abstrakte BPEL-Beschreibung dem Controller. Durch den Einsatz von XForms als Benutzerschnittstelle ist es möglich, dem Client geräte- und plattformunabhängigen Zugriff auf den komplexen Dienst zu gewährleisten. Zudem werden die ausgetauschten Daten als XML repräsentiert, so dass zum einen eine clientseitige Validierung der eingegebenen Daten vorgenommen werden kann, zum anderen die Einbindung der ausgetauschten Daten in SOAP-Nachrichten leicht möglich ist. Copyright TU-Dresden, Nicolás Bleyh 66

75 Konzept Es soll auch noch einmal der generische Charakter von GUI4CWS hervorgehoben werden. Lediglich drei (XML-)Dokumente sind notwendig, um durchaus komplexere Web-Anwendungen zu erstellen. Dabei ist das Anwendungsfeld nicht auf die Steuerung von Geschäftsprozessen beschränkt. Copyright TU-Dresden, Nicolás Bleyh 67

76 Konzept Copyright TU-Dresden, Nicolás Bleyh 68

77 Implementierung 6 Implementierung In diesem Kapitel soll die Implementierung des Prototyps vorgestellt werden. Dabei wurde zum einen eine Service-orientierte Architektur (SOA) mit einer BPEL-Engine und zwei zu komponierenden Web Services aufgebaut, um das Szenario einer Reisebuchung zu simulieren. Der Hauptteil der Implementation beschäftigt sich mit der Realisierung des Prototypen GUI4CWS, dessen einzelne Bestandteile im Kapitel 6.2 erläutert werden. Zum Abschluss des Kapitels wird der Ablauf bei Anwendung des Reisebuchungsszenarios anhand des erstellten Prototypen und der aufgesetzten SOA-Umgebung durchgespielt. 6.1 Orchestration der Dienste Implementierung elementarer Web Services Um eine SOA-Umgebung aufzubauen, müssen zunächst elementare Web Services implementiert werden. Im Szenario der Reisebuchung handelt es sich dabei um den Dienst einer Fluggesellschaft und den eines Hotelagenten. Beide Dienste bieten zwei Funktionen an: Die Funktion getflights bzw. gethotels, welche anhand der Angabe eines Reisezieles eine Liste mit verfügbaren Flügen bzw. Hotels liefert. Die Funktion bookflight bzw. bookhotel, durch welche ein durch eine ID eindeutig bestimmter Flug bzw. bestimmtes Hotel gebucht wird. Das Open-Source-Projekt Axis von Apache ermöglicht es, Funktionen einer Java-Klasse als Web Service zu veröffentlichen und automatisch eine zugehörige WSDL zu erstellen. Axis kann unter [63] bezogen werden. Die von Axis bereitgestellten Bibliotheken können in einem Servlet-Container verwendet werden, wodurch die Funktionalität in Java Servlets genutzt werden kann. In dieser Arbeit wurde als Servlet-Container der Apache Tomcat [64] in der Version verwendet. Um eine Java-Klasse und ihre Funktionen mittels Axis als Web Service zu veröffentlichen, muss ein so genannter deployment descriptor erstellt werden. In ihm wird die Klasse festgelegt, die als Web Service veröffentlich wird. Außerdem kann angegeben werden, welcher SOAP-Stil für die Kommunikation verwendet wird, wobei zur Auswahl rpc und document stehen (zum Unterschied der beiden Stile siehe Kapitel 2.2.2). Für den Austausch einfacher Datentypen wie String oder Integer kümmert sich Axis um die Serialisierung, also die Transformation von XML in Java-Objekte und umgekehrt. Werden komplexere Datentypen verwendet, so muss im deployment descriptor ein bean mapping angegeben werden. Dabei wird eine Java-Klasse auf einen komplexen XML-Datentyp abgebildet. Die Java-Klasse muss dabei der Java-Bean-Spezifikation entsprechen, die u.a. besagt, dass der Zugriff auf die Attribute der Klasse über get- und set-methoden erfolgt. Für das Szenario der Reisebuchung verwendet sowohl der Dienst der Fluggesellschaft als auch der des Hotelagenten komplexe Datentypen. Das wäre zum einen der Typ Flight mit den Attributen startlocation, endlocation, company, price und flightid, zum anderen der Typ Hotel mit den Attributen location, name, price und hotelid. Zu berücksichtigen ist auch, das Axis keine Java Collections auf XML-Datentypen abbilden kann. Soll also, wie im Szenario, eine Liste mit Flügen zurückgeliefert werden, so muss dies über Arrays geschehen. Copyright TU-Dresden, Nicolás Bleyh 69

78 Implementierung BPEL-Erstellung Um die Komposition der Dienste zu realisieren, wurde in dieser Arbeit die BPEL- Technologie verwendet. Hierfür musste zunächst ein BPEL-Dokument erstellt werden, welches dann später in einer BPEL-Engine ausgeführt werden konnte. Im Netz sind zahlreiche BPEL-Designer verfügbar, von denen drei hier kurz vorgestellt werden sollen: BPWS4J [65]: BPWS4J (Business Process Execution Language for Web Services Java) wurde von IBM entwickelt und enthält eine BPEL-Engine und einen BPEL- Designer, die beide frei verfügbar sind. Beim BPEL-Designer handelt es sich um ein Eclipse-Plugin, welches den Autorenprozess allerdings nur durch sehr eingeschränkte Funktionalitäten unterstützt. Oracle BPEL Designer [61]: Dieser von Oracle entwickelte Designer ist ein sehr mächtiges Autorentool mit ausgereifter grafischer Unterstützung, welcher ebenfalls frei verfügbar ist. Einziger Nachteil dieses Autorentools ist das Fehlen eines Werkzeuges zur Erstellung von WSDL-Beschreibungen. ActiveBPEL Designer [66]: Die Firma active endpoints hat sich auf das Ausführen und Erstellen von BPEL-Prozessen spezialisiert. Der ActiveBPEL Designer bietet dem Autor umfangreiche grafische Hilfsmittel, allerdings wirkt hier der Oracle BPEL Designer ausgereifter. Hinzu kommt, dass der ActiveBPEL Designer nur 30 Tage kostenlos getestet werden kann, da es sich um ein kommerzielles Produkt handelt. Alle drei vorgestellten BPEL-Designer haben gemeinsam, dass der Quellcode nicht offen gelegt ist. Zur ausführlicheren Beschreibung einiger der hier erwähnten und zusätzlicher BPEL- Designer kann die Bachelorarbeit von O. Hoffmann [67] herangezogen werden. Im Rahmen dieser Arbeit wurden die besten Erfahrungen mit dem Oracle BPEL Designer gemacht. Allerdings gilt es zu beachten, dass dieser kein grafisches Autorentool zur Erstellung einer WSDL beinhaltet. Vor der Erstellung eines BPEL-Prozesses sollten daher die Operationen, die der komponierte Dienst zur Verfügung stellt, bereits definiert sein. Eine mögliche Vorgehensweise ist, eine abstrakte Java-Klasse mit den vom komplexen Dienst anzubietenden Methoden zu implementieren. Mit Hilfe von Apache Axis kann aus dieser Java-Klasse automatisch eine WSDL-Beschreibung generiert werden, die dann als öffentliche Schnittstelle des BPEL- Prozesses dient. Damit erspart sich der Autor den Aufwand, die WSDL-Beschreibung per Hand zu erstellen. Allerdings muss beachtet werden, dass Axis für jeden komplexen Datentyp eine neue XML-Schema-Definition anlegt. GUI4CWS (und auch ActiveBPEL) ist jedoch nur in der Lage, innerhalb einer WSDL-Beschreibung nur eine XML-Schema-Definition zu parsen. Daher muss das von Axis generierte WSDL-Dokument so angepasst werden, dass alle Datentypen innerhalb eines XML-Schemas definiert sind. Die WSDL-Beschreibung des implementierten Reisedienstes bietet zwei Operationen: gettravels(string endlocation, int userid): Übergeben werden muss der Zielort und eine eindeutige ID, so dass jedem Nutzer eine Prozessinstanz zugeordnet werden kann. Der Rückgabewert besteht aus einer Liste mit Fluginformationen, einer Liste mit Hotelinformationen und der übergebenen Nutzer-ID. booktravel(int flightid, int hotelid, int userid): Mit dieser Operation wird anhand der eingegebenen IDs der entsprechende Flug bzw. das entsprechende Hotel gebucht. Zur Prozessinstanzidentifikation ist wieder die Nutzer-ID notwendig. Zurückgegeben wird der komplexe Datentyp Travel, welcher alle Informationen der gebuchten Reise enthält. Neben der eigenen WSDL-Beschreibung werden für die Erstellung des BPEL-Prozesses noch die der zu komponierenden Dienste, also die Schnittstelle des Flugdienstes und des Hotelagenten, benötigt. Der Oracle BPEL Designer fügt in die WSDL-Beschreibung automatisch Copyright TU-Dresden, Nicolás Bleyh 70

79 Implementierung eine partnerlink-definition ein, um die Kommunikationsteilnehmer im Prozess einem Dienst zuordnen zu können. Somit sind am Ende des Autorenprozesses diese vier Dokumente in einer BPEL-Engine für die Ausführung zu hinterlegen: Die ausführbare BPEL-Beschreibung des Geschäftsprozesses zur Reisebuchung. Die WSDL-Beschreibung des Geschäftsprozesses. Die WSDL-Beschreibung des Flugdienstes. Die WSDL-Beschreibung des Hotelagenten. Der in dieser Arbeit erstellte BPEL-Prozess definiert den in der Abbildung 9 dargestellten Workflow, allerdings ohne den Teilnehmer Bank. Zunächst empfängt der Prozess die Nutzeranfrage für ein Reiseangebot über die Operation gettravel, leitet diese an den Hotel- und Flugdienst weiter und liefert eine Liste mit Reiseangeboten zurück. Falls einer der beiden Dienste keine Angebote zurückliefert, wird durch einen faulthandler eine entsprechende Variable gesetzt. Diese wird in der nachfolgenden while-schleife ausgewertet. So lange einer der beiden Dienste kein Reiseangebot zurückliefert, wird die Operation gettravel erneut aufgerufen. Kann der Prozess ein gültiges Reiseangebot zusammenstellen, so erfolgt durch den Nutzer der nächste Operationsaufruf booktravel. Der Quellcode 18 zeigt eine vereinfachende Übersicht über die BPEL-Prozessbeschreibung. Der ausführlichere BPEL-Code befindet sich im Anhang. <process>... <sequence> <receive partnerlink="client" operation="gettravel"/> <scope> <faulthandlers> <catchall> <assign>...</assign> </catchall> </faulthandlers> <sequence> <flow> <invoke partnerlink="hotelservice" operation="gethotels"/> <invoke partnerlink="airlineservice" opertion="getflights"/> </flow> </sequence> <scope> <reply partnerlink="client" operation="gettravel"/> <while condition="..."> <receive partnerlink="client" operation="gettravel"/>... <reply partnerlink="client" operation="gettravel"/> </while> <receive partnerlink="client" operation="booktravel"/> <flow> <invoke partnerlink="hotelservice" operation="bookhotel"/> <invoke partnerlink="airlineservice" opertion="bookflight"/> </flow> <reply partnerlink="client" operation="booktravel"/> </sequence> </process> Quellcode 18: vereinfachte BPEL-Prozessbeschreibung des Reisebuchungsszenarios Damit der BPEL-Prozess von mehreren Nutzern parallel aufgerufen werden kann, müssen CorrelationSets verwendet werden (siehe Kapitel 4.1.3). Diese können auch dazu benutzt werden, einen Nutzer eindeutig zu identifizieren. Eine solche Maßnahme ist gerade bei Copyright TU-Dresden, Nicolás Bleyh 71

80 Implementierung kritischen Operationen wie der Buchung einer Reise notwendig. Um ein CorrelationSet zu definieren, müssen der Datentyp und der Bestandteil der empfangen Nachricht, durch welcher der BPEL-Prozess identifiziert wird, angegeben werden. Beides erfolgt in der WSDL- Beschreibung. Der Datentyp wird über das Element property festgelegt. Über das Element propertyalias wird ein Teil einer WSDL-Nachricht einer property zugewiesen. Da der Nutzer zwei verschiedene Nachrichten an den BPEL-Prozess sendet (jeweils eine für die beiden Operationen gettravel und booktravel), müssen zwei propertyalias angegeben werden. Der folgende Quellcode zeigt die Definition der beiden Elemente property und propertyalias für das Reisebuchungsszenario. <property name="userid" type="xsd:int"/> <propertyalias propertyname="userid" messagetype="gettravelrequest" part="parameters" query="/gettravel/userid"/> BPEL Ausführung Quellcode 19: Definition von property und propertyalias Zur Ausführung von BPEL-Prozessen gibt es eine Vielzahl von BPEL-Engines. Die in dieser Arbeit getesteten sind in der folgenden Liste aufgezählt: BPEL Execution Engine (bexee, [68]), eine Open-Source BPEL-Engine, entwickelt an der Berner Hochschule für Technik und Informatik. Process Execution Engine (pxe, [69]), ebenfalls eine Open-Source-Lösung. Agila BPEL ([60]), lief früher unter dem Namen Twister und wird nun von der Apache Foundation betreut. ActiveBPEL ([70]), von active endpoints entwickelte Open-Source BPEL-Engine. Oracle BPEL Engine ([61]), frei verfügbare BPEL-Engine von Oracle. BPWS4J ([65]), frei verfügbare BPEL-Engine von IBM. Bis auf die Oracle BPEL Engine und ActiveBPEL besitzen jedoch alle aufgelisteten Engines den Nachteil, dass zur Kommunikation mit den hinterlegten Prozessen nur der SOAP- Kommunikationsstil rpc verwendet werden kann. Die mittels GUI4CWS erstellten generischen Clients benötigen für die Kommunikation jedoch den SOAP-Kommunikationsstil document. Die Gründe hierfür werden im Kapitel deutlich. Somit stehen nur noch die Oracle BPEL Engine und ActiveBPEL zur Auswahl. Hier besaß ActiveBPEL allerdings klare Vorteile, da die Oracle BPEL Engine unverhältnismäßig viele Ressourcen (vor allem Arbeitsspeicher) benötigt, und die Ausführung eines Prozesses in der zur Verfügung stehenden Testumgebung nicht realisiert werden konnte. ActiveBPEL besticht dagegen durch eine sehr gute Administrationsoberfläche, in welcher u.a. der Ablauf der aktiven Prozesse grafisch in allen Details dargestellt wird, was gerade für Entwicklung und Fehlersuche sehr hilfreich ist. Um einen BPEL-Prozess in ActiveBPEL zu veröffentlichen, müssen die zugehörigen Dateien in einer festgelegten Verzeichnisstruktur hinterlegt werden und in ein jar-archiv verpackt werden. Zusätzlich zum BPEL-Prozess und den zugehörigen WSDL-Beschreibungen werden zwei weitere Dateien benötigt. Zum einen eine Datei namens wsdlcatalog, in welcher die Pfade der WSDL-Beschreibungen angegeben sind. Zum anderen muss ein process deployment descriptor (pdd) erstellt werden. Dieser gibt den Pfad des BPEL-Prozesses, den zugehörigen Namensraum, die am Prozess beteiligten Dienste (partnerlinks), den verwendeten SOAP-Kommunikationsstil (rpc oder document) und Referenzen auf die vom Prozess verwendeten WSDL-Beschreibungen an. Bei Verwendung des (kommerziellen) ActiveBPEL Copyright TU-Dresden, Nicolás Bleyh 72

81 Implementierung Designer (siehe Kapitel 6.1.2) zur Erstellung des Prozesses übernimmt dieser die Erstellung der Verzeichnisstruktur, des wsdlcatalogs und des process deployment descriptors. Nach einer gewissen Einarbeitung lässt sich dieses jedoch auch gut per Hand bewerkstelligen. Im Anhang ist der vollständige process deployment descriptor und wsdlcatalog zum in dieser Arbeit erstellen BPEL-Prozess dargestellt. ActiveBPEL läuft innerhalb eines Tomcat-Servers und benötigt Apache Axis. Das erstellte jar-archiv muss zur Veröffentlichung des Prozesses lediglich in ein bei der Installation von ActiveBPEL angelegtes Verzeichnis kopiert werden. Beim Ansprechen des veröffentlichten BPEL-Prozesses muss beachtet werden, dass der Inhalt des SOAP-Bodys (bei Verwendung des Kommunikationsstils document) denselben Namensraum wie das XML-Schema in der WSDL-Beschreibung, in welcher der übergebene Datentyp definiert ist, besitzt. Im Unterschied dazu ist beispielsweise für das Ansprechen eines elementaren Axis Web Service die Angabe eines Namensraumes nicht zwingend. Ferner sind noch zwei Konfigurationseinstellungen, die auf den Administrationsseiten von AktiveBPEL gemacht werden können, für das Veröffentlichen eines Prozesses relevant. Zum einen muss die Eigenschaft Auto create target path for Copy/To aktiviert werden, so dass im Prozess bei der erstmaligen Zuweisung von Werten zu Variablen diese automatisch initialisiert werden. Die zweite wichtige Einstellung ist die Eigenschaft Validate Input/Output messages against schema. Wie der Name bereits sagt, werden dabei die gesendeten und empfangen Nachrichten gegenüber dem entsprechenden XML-Schema validiert. Diese Einstellung kann sich auf den Prozessablauf auswirken, wenn z.b. faulthandler definiert werden, die bei einer ungültigen Ein- oder Ausgangsnachricht ausgelöst werden. 6.2 Implementierung von GUI4CWS Die in der Programmiersprache Java realisierte Anwendung GUI4CWS implementiert die im Konzept dieser Arbeit vorgestellten Funktionalitäten zur Benutzerinteraktion mit einem komplexem Web Service. Den Hauptbestandteil bilden dabei die folgenden drei Packages: behavioralinterface implementiert Funktionalitäten zur Steuerung des Ablaufs. interaction kümmert sich um die externe und programminterne Kommunikation. representation generiert die Benutzerinterfaces. Ferner existiert noch das Package discovery, welches Funktionen zum Zugriff auf ein Verzeichnis zur Verfügung stellt, in der Daten zum Auffinden eines komplexen Dienstes enthalten sind. Ein vollständiges UML-Klassendiagramm zu GUI4CWS befindet sich im Anhang Ablaufsteuerung Im Package behavioralinterface sind die Klassen zusammengefasst, die sich um die Ablaufsteuerung kümmern. Das ist vor allem die Klasse AbstractBPELProcess, deren Hauptaufgaben das Parsen der abstrakten BPEL-Prozessbeschreibung und das bestimmen der Reihenfolge der Operationsaufrufe ist. Da das Parsen und Überführen der abstrakten BPEL- Prozessbeschreibung in ein Java-Objekt ebenfalls Bestandteil von existierenden BPEL- Engines ist, wurde in dieser Arbeit kein neuer BPEL-Parser implementiert, sondern eine existierende BPEL-API verwendet. Hierzu wurden die APIs der BPEL-Engines untersucht, die bereits im vorherigen Kapitel vorgestellt wurden. Die Entscheidung fiel dabei auf die API von BPWS4J, welche am übersichtlichsten und einfachsten zu verwenden ist. Für die Nutzung dieser API müssen die Bibliotheken bpws4j, commons-logging, log4j, serializer, wsdl4j und xalan eingebunden werden. Copyright TU-Dresden, Nicolás Bleyh 73

82 Implementierung Um den aktuellen Prozesstand zu ermitteln, wurde die Methode AbstractBPELProcess.getNextActivity() implementiert. Beim Aufruf dieser Methode wird über die Objektrepräsentation der BPEL-Prozessbeschreibung iteriert und die aktuell abzuarbeitende Aktivität ermittelt. Bei den zurückgelieferten Aktivitäten handelt es sich entweder um eine receiveoder eine reply-aktivität. Wurde eine dieser Aktivitäten zurückgeliefert, so muss diese entsprechend gekennzeichnet werden, damit beim nächsten Durchlaufen der Prozessrepräsentation erkannt wird, dass diese Aktivität bereits abgearbeitet wurde und zur darauf folgenden gesprungen wird. Hierfür wird das Attribut getjoincondition verwendet, welches alle Aktivitäten besitzen. Da dieses Attribut in einer abstrakten Prozessbeschreibung keine Verwendung findet, wird es im Rahmen von GUI4CWS als Status-Attribut zweckentfremdet, indem es entweder den Wert null oder STATUS_COMPLETED erhält. Jede receive- und reply- Aktivität wird somit nur einmal ausgeführt. Ein Spezialfall tritt jedoch beim Einsatz einer while-aktivität auf. Die darin enthaltenen Aktivitäten können mehrmals ausgeführt werden, nämlich solange, wie die Bedingung der while-aktivität erfüllt ist. Um dies zu gewährleisten, werden nach der Abarbeitung aller Aktivitäten innerhalb des while-konstrukts der Status dieser wieder auf null gesetzt. Die von der Methode AbstractBPELProcess.getNextActivity() zurückgelieferte Aktivität reply bzw. receive besitzen folgende Attribute: joincondition: Legt den Status der Aktivität fest, wobei der Wert null für unbearbeitet, der Wert STATUS_COMPLETED für abgearbeitet steht. operation: Gibt den Namen der zur Aktivität zugehörigen Operation an. porttype: Enthält den Namen des WSDL porttype der Operation. variable: Dieses Attribut ist optional und verweist auf die Variable innerhalb der Prozessbeschreibung, die mit dieser Aktivität assoziiert ist. Da nach Nutzereingaben immer eine Antwort erwartet wird und somit auf jedes receive ein reply folgen muss, ist diesen zwei aufeinander folgenden Aktivitäten immer die gleiche Operation zugeordnet. Die Unterscheidung in receive und reply ist jedoch trotzdem wichtig, da sie den Variablen verschiedene Werte zuweisen. Der Variable einer receive- Aktivität werden die ausgehenden Daten, während der Variable einer reply-aktivität die empfangenden Daten zugewiesen werden. Die Verwendung der Variablen ist notwendig, um einen dynamischen Ablauf realisieren zu können (siehe Kapitel ). Hierzu wurde die Methode AbstractBPELProcess.initializeVariable(Activity activity, Node node) implementiert. Sie initialisiert eine Variable anhand der aktuellen Aktivität mit dem Inhalt des empfangenen oder gesendeten SOAP- Bodys. Die Auswertung der initialisierten Variablen erfolgt durch die strukturieren Aktivitäten while und switch. Diese besitzen ein Attribut namens condition, in dem als Bedingung für die Ausführung der enthaltenen Aktivitäten XPath-Ausdrücke auf in der Prozessbeschreibung definierte Variablen angewendet werden. Neben Standard XPath-Funktionen bietet BPEL zusätzliche XPath-Funktionserweiterungen, mit denen auf prozessspezifische Informationen zugegriffen werden kann. Die wichtigste, und am meisten genutzte dieser Erweiterungen, ist die Funktion getvariabledata(variablename, partname, locationpath), die den Zugriff auf Daten von BPEL-Variablen ermöglicht. Hierbei spezifiziert der variablename die zu referenzierende Variable, der optionale partname den zu verwendenden part der durch eine WSDL-Nachricht getypten Variable und der optionale locationpath einen XPath- Pfadausdruck, der ein bestimmtes Element des part spezifiziert. Das Ergebnis dieser Funktion kann dann für eine boolesche Abfrage verwendet werden. Copyright TU-Dresden, Nicolás Bleyh 74

83 Implementierung Ursprünglich war auch hier das Ziel, eine bestehende API zur Auswertung der Funktion get- VariableData bzw. allgemein zur Auswertung einer condition zu verwenden. Das stellte sich allerdings als nicht machbar heraus, da bei allen untersuchten BPEL-APIs diese Funktion nur innerhalb einer laufenden BPEL-Engine genutzt werden kann. Deshalb musste für den entwickelten Prototyp eine eigene Implementation der Funktion getvariabledata vorgenommen werden. Um die angegebene Bedingung zu parsen, dient die Klasse Condition. In der Funktion AbstractBPELProcess.evaluateCondition(String condition) erfolgt mit Hilfe dieser Klasse und der XPathAPI von Apache die Auswertung. Da es sich allerdings um eine prototypische Implementierung handelt, sind die Eingaben für eine Bedingung eingeschränkt. Während es in BPEL möglich ist, in einer condition mehrere getvariabledata Funktionsaufrufe zu verwenden und diese auch zu verschachteln, kann im realisierten Prototyp nur ein Funktionsaufruf angegeben werden. Auch die Verwendung von XPath-Funktionen wie beispielsweise count() wird nicht unterstützt. Das folgende Beispiel soll die Verwendung von Konditionen bei dynamischen Abläufen verdeutlichen. Im Quellcode 20 ist der Inhalt eines SOAP-Bodys dargestellt, welcher beim Aufruf der Operation gettravel zurückgeliefert wurde und der Variable travelresponse zugeordnet ist. <gettravelreturn> <flightid>-1</flightid> </gettravelreturn> Quellcode 20: Inhalt eines SOAP-Bodys als Variablenwert Die folgende Bedingungsabfrage soll in einer while-aktivität ausgewertet werden. Dabei wird zunächst der Inhalt der angegebenen Variable geladen. Dann folgt die Auswertung des XPath-Ausdrucks. Zum Abschluss wird das Ergebnis des XPath-Ausdrucks für die boolesche Abfrage verwendet. bpws:getvariabledata('travelresponse','/gettravelreturn/flightid )=-1 Quellcode 21: Inhalt einer BPEL-Bedingung Um den Autorenprozess für eine abstrakte BPEL-Prozessbeschreibung zu vereinfachen (siehe Kapitel 5.4), wurde ein Werkzeug namens abstracter implementiert. Dieses nutzt ebenfalls die API BPWS4J und transformiert einen ausführbaren in einen abstrakten BPEL-Prozess, indem aus der ursprünglichen Beschreibung nur die im Kapitel definierten BPEL- Konstrukte übernommen werden Darstellung Die Programmlogik zur Darstellung der Benutzeroberfläche des komplexen Dienstes ist im Package representation enthalten. In dieser Arbeit werden XForms zur Repräsentation der Benutzeroberfläche verwendet, die in der Klasse XFormsAdapter generiert werden. Generell kann in GUI4CWS jedoch jede Darstellungssprache über eine Adapterklasse eingebunden werden. Zur dynamischen Generierung der XForms verwendet der XFormsAdapter die folgenden, zum Teil bereits für WSGUI erstellten APIs, um die entsprechenden XML-Dokumente in eine Objektrepräsentation zu überführen und Zugriffsmethoden bereitzustellen: Copyright TU-Dresden, Nicolás Bleyh 75

84 Implementierung Das Package wsdl wird zum Parsen der WSDL-Beschreibung benötigt. Dabei wird die API WSDL4J verwendet. Läuft GUI4CWS innerhalb einer Tomcat-Umgebung, muss in der Datei web.xml im Konfigurationsverzeichnis ein mime-mapping für WSDL- Dateien hinzugefügt werden, da WSDL4J diese sonst nicht einlesen kann. Die Bibliothek xsd4java dient zum Parsen des XML-Schemas innerhalb der WSDL- Beschreibung, da diese Aufgabe nicht von WSDL4J realisiert wird. guidd4java kümmert sich um das Parsen der GUIDD. Sollen auf einer XForms-Formularseite Daten eingegeben und von der vorherigen Operation zurückgelieferte Ergebnisse dargestellt werden, so werden zwei XForms models generiert. Die Instanz des einen wird über Eingabeelemente mit den Nutzereingaben gefüllt und abgeschickt, während die Instanz des zweiten XForms model den Inhalt der letzten empfangenen SOAP-Nachricht enthält und von output-elementen ausgelesen und dargestellt werden kann. Um die beiden Datenmodelle unterscheiden zu können, wird dem model, welches für die darzustellenden Daten bestimmt ist, die id return zugewiesen. Sollen Inhalte der darin enthaltenen Instanz ausgelesen werden, so muss bei der Erstellung der GUIDD darauf geachtet werden, in den entsprechenden output-elementen das Attribut model auf den Wert return zu setzen. Da mit XForms keinerlei Einfluss auf die Formatierung der Formulare genommen werden kann, wurde für den Prototyp ein Stylesheet erstellt, mit dem zumindest eine übersichtliche Anordnung der Formularelemente erreicht wird. Zudem kann mit Hilfe von Stylesheets ein Nachteil ansatzweise behoben werden, der beim Einsatz von XForms auftritt. Mit Hilfe einer Datentypangabe ist es mit diesen zwar möglich, die Nutzereingaben auf ihre Korrektheit hin zu überprüfen. Allerdings erfolgt für den Nutzer bei einer negativen Validierung keine Rückmeldung. Das Formular wird in diesem Fall ohne Angabe von Gründen nicht abgeschickt. Mit Stylesheets ist es möglich, die Formularfelder, die fehlerhafte Nutzerdaten enthalten, farblich hervorzuheben Interaktion Das Package interaction beinhaltet die Klassen, die sich um die Kommunikation zwischen dem Client und dem komponierten Web Service kümmert. Dabei wird zwischen externer und (programm-)interner Kommunikation unterschieden. Für die externe Kommunikation sind folgende Klassen zuständig: XFormsServlet: Diese Klasse stellt ein Servlet dar, mit welchem der Client über HTTP-Requests mit GUI4CWS interagieren kann. XmlRequest: In dieser Klasse werden die als XML vorliegenden Nutzereingaben in eine DOM (Document Object Model) Repräsentation überführt, um sie für den weiteren Programmablauf verwenden zu können. SoapQuery: Hier findet die SOAP-Kommunikation statt. Dazu werden die Nutzereingaben in den SOAP-Body der zu versendenden SOAP-Nachricht eingefügt, während die empfangenen Daten aus dem SOAP-Body extrahiert und als DOM-Repräsentation zurückgeliefert werden. Um die SOAP-Kommunikation zu realisieren, verwendet die Klasse SoapQuery Apache Axis. Dafür müssen die Bibliotheken activation, axis, axisant, commons-logging, commons-discovery, jaxrpc, log4j, mail, saaj und wsdl4j eingebunden werden. Voraussetzung für diese Umsetzung ist jedoch, dass für die SOAP- Nachrichten der Kodierungsstil document und nicht rpc verwendet wird (siehe dazu Kapitel 2.2.2), da sonst die zu sendenden und empfangenen XML-Daten aufwendig anhand des SOAP Encoding Schemas transformiert werden müssten (der Kodierungsstil rpc dient dazu, XML-Nachrichten auf (Java-)Objekte abzubilden, was für Copyright TU-Dresden, Nicolás Bleyh 76

85 Implementierung GUI4CWS jedoch nicht benötigt wird). Deshalb wird in der Implementierung nur der SOAP-Kodierungsstil document unterstützt, welcher es erlaubt, die zu sendenden und empfangenen XML-Daten direkt zu verwenden. Bei den empfangenen Daten werden außerdem alle Namensräume entfernt. Da diese Daten in das XForms model übernommen werden, hat dies den Vorteil, dass bei der Referenzierung in den output- Elementen der GUIDD die Namensräume nicht berücksichtig werden müssen, wodurch der Autorenprozess vereinfacht wird. Die programminterne Kommunikation wird mit den folgenden drei Klassen realisiert. Sie sind damit auch für den Ablauf von GUI4CWS zuständig. Session: Diese Klasse stellt die Sitzungsvariable von GUI4CWS dar. In ihr wird zu Beginn der Anwendung u.a. die Objektrepräsentation der einzelnen Dokumente gespeichert, so dass auf diese von allen Klassen aus zugegriffen werden kann. DynvokerEntrance: Hier sind die Schnittstellenfunktionen zwischen der SOAP- Kommunikation, der Darstellung und dem Servlet implementiert. DynvokerCore: In dieser Klasse wird vor allem die dynamische Darstellung vorbereitet, indem die empfangenen SOAP-Daten in die von der XFormsAdapter Klasse zurück gelieferten XForms eingebunden werden. Im unterschied zum Konzept in Kapitel ist für das Einfügen von Listen ein Platzhalter nicht notwendig, da durch das select1-element (bzw. select-element) und deren Attribut path der passende Einfügeort bereits eindeutig bestimmt ist. Die Klassen DynvokerEntrance und DynvokerCore stammen ursprünglich aus dem WSGUI- Projekt und wurden für die Integration in GUI4CWS entsprechend angepasst und erweitert. 6.3 Anwendung auf das Szenario einer Reisebuchung Um den Prototypen zu testen, wurde das Szenario einer (stark vereinfachten) Reisebuchung durchgespielt. Der Ablauf einer solchen ist im Aktivitätsdiagramm der Abbildung 9 (ohne den Teilnehmer Bank) dargestellt. Um den genannten Anwendungsfall zu realisieren, musste zunächst eine SOA-Architektur aufgesetzt werden. Diese besteht zum einen aus dem Dienst der Fluggesellschaft und des Hotelagenten. Die Komposition dieser beiden Web Services zu einem Reisedienst erfolgt durch die BPEL-Engine ActiveBPEL. Damit der Client den komplexen Dienst über eine Benutzerschnittstelle ansprechen kann, muss er die GUI4CWS- Anwendung aufrufen. Sie leitet die über XForms eingegebenen Daten als SOAP-Nachrichten an ActiveBPEL weiter, womit der komplexe Dienst in Gang gesetzt wird. Zur SOAP- Kommunikation wird Apache Axis verwendet, welches als Servlet innerhalb eines Tomcat Servers läuft. Die Architektur der in dieser Arbeit aufgesetzten SOA-Umgebung ist in der Abbildung 24 dargestellt. Abbildung 24: Realisierte SOA Im Folgenden soll nun erläutert werden, wie der Nutzer mit Hilfe von GUI4CWS durch den Geschäftsprozess einer Reisebuchung geführt wird. Die hierfür von GUI4CWS verwendete abstrakte BPEL-Prozessbeschreibung wurde vom abstracter (siehe Kapitel 6.2.1) erstellt und Copyright TU-Dresden, Nicolás Bleyh 77

86 Implementierung ist im Quellcode 22 verkürzt abgebildet. Die zughörigen WSDL-Beschreibungen, der abstrakte und ausführbare BPEL-Prozess und die GUIDD befinden sich im Anhang. <process> <variables>...</variables> <sequence> <receive operation="gettravel" variable="gettravels"/> <reply operation="gettravel" variable="gettravelresponse"/> <while condition="..."> <sequence> <receive operation="gettravel" variable="gettravels"/> <reply operation="gettravel" variable="gettravelresponse"/> </sequence> </while> <receive operation="booktravel" variable="booktravel"/> <reply operation="booktravel" variable="booktravelresponse"/> </sequence> </process> Quellcode 22: Verkürzte abstrakte BPEL-Prozessbeschreibung des Reisedienstes Zunächst kann der Kunde aus einer Liste einen komplexen Dienst auswählen. Diese Liste wurde anhand eines Verzeichnisses generiert, wofür das Package discovery zuständig ist. Nach der Auswahl des Reisedienstes wird dem Nutzer die Formularseite für den Aufruf der ersten Operation des Dienstes angezeigt (gettravel). Gemäß der Operationsdefinition gibt er über ein Eingabefeld einen Zielort für seine Reise und eine Nutzer-ID, wodurch die ihm zugewiesen Prozessinstanz eindeutig identifiziert werden kann, an. Die Abbildung 25 zeigt einen Screenshot dieses Formulars. Abbildung 25: Reiseangebote suchen (Screenshot) Neben einer Schaltfläche zum Abschicken der Nutzerdaten bzw. Aufrufen der nächsten Operation enthält jede Formularseite zwei weitere Schaltflächen, durch deren Betätigung entweder wieder zum Beginn des Geschäftsprozesses gesprungen werden kann oder erneut die Seite mit der Auswahl der verfügbaren komplexen Dienste angezeigt wird. Das folgende UML-Sequenzdiagramm zeigt den vereinfachten programminternen Ablauf, der beim Aufruf einer Operation innerhalb von GUI4CWS abläuft. Zunächst werden die vom Servlet empfangenden Nutzerdaten ( Rom als Zielort, 27 als Nutzer-ID) über die Funktion call an die Klasse DynvokerEntrance übergeben. Dort wird von der Klasse AbstractB- PELProcess die nächste Aktivität (receive) angefragt und der zugehörigen Variable die Nutzereingaben zugewiesen. Die so initialisierte Variable wird bei jedem Aufruf der Funktion getnextactivity in den entsprechenden while- bzw. switch-konstrukten ausgewertet. Anschließend erfolgt der SOAP-Aufruf durch die Klasse SoapQuery. Nach dem Empfang der Ergebnisdaten wird die nächste Aktivität (reply) von der Klasse AbstractBPELProcess angefragt und die zugehörige Variable mit den empfangenen Daten (jeweils eine Liste mit Flügen und Hotels und die Nutzer-ID) initialisiert. Nun erfolgt die Generierung des XForms mit Copyright TU-Dresden, Nicolás Bleyh 78