Analyse und Vergleich von Ans¤tzen zur Einbindung von

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

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 Interak-tionen 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)

Menschliche Interaktionen in komplexen Web Services Inhaltsverzeichnis

Copyright TU Dresden, Nicolás Bleyh i

Inhaltsverzeichnis

1 Einleitung ....................................................................................................... 1

2 Grundlagen Web Services ............................................................................ 3 2.1 Grundlagen.................................................................................................................... 3 2.2 Standards....................................................................................................................... 5

2.2.1 XML....................................................................................................................... 5 2.2.2 SOAP...................................................................................................................... 6 2.2.3 WSDL..................................................................................................................... 7 2.2.4 UDDI...................................................................................................................... 9

2.3 Einsatzgebiete ............................................................................................................. 11 2.4 Bewertung ................................................................................................................... 12

3 Komplexe Web Services.............................................................................. 15 3.1 Workflow-Management.............................................................................................. 15 3.2 Komposition................................................................................................................ 17

3.2.1 Choreographie ...................................................................................................... 18 3.2.2 Behavioral Interface ............................................................................................. 18 3.2.3 Orchestration ........................................................................................................ 19

3.3 Szenarien für Benutzerinteraktionen........................................................................... 19 3.3.1 „Ziel-orientierte Nutzerinteraktion“..................................................................... 20 3.3.2 „Task-orientierte Nutzerinteraktion“.................................................................... 23

3.4 Fazit............................................................................................................................. 23

4 Existierende Lösungen ................................................................................ 25 4.1 Kompositionssprachen................................................................................................ 25

4.1.1 WSCI.................................................................................................................... 26 4.1.2 WS-CDL............................................................................................................... 27 4.1.3 BPEL .................................................................................................................... 31 4.1.4 Vergleich und Bewertung..................................................................................... 35

4.2 Generische Benutzerschnittstellenbeschreibung......................................................... 36 4.2.1 XForms................................................................................................................. 37 4.2.2 Generierung auf Grundlage von WSDL............................................................... 39 4.2.3 Generierung auf Grundlage von WSDL und User Interface Markup .................. 39

4.3 Web Services for Remote Portlets (WSRP)................................................................ 41 4.4 Benutzerinteraktion in komplexen Web Services....................................................... 42

4.4.1 BPEL4PEOPLE ................................................................................................... 42 4.4.2 Integration von Benutzerinteraktionen über Tasks .............................................. 44

4.5 Bewertung ................................................................................................................... 46

5 Konzept......................................................................................................... 47 5.1 Kompositionsbeschreibung......................................................................................... 48

5.1.1 Choreographieansatz ............................................................................................ 49 5.1.2 Orchestrationsansatz............................................................................................. 52

5.2 Darstellung.................................................................................................................. 56 5.2.1 Statische Generierung .......................................................................................... 57 5.2.2 Dynamische Generierung..................................................................................... 58 5.2.3 Fehlermeldungen.................................................................................................. 61

5.3 Architektur .................................................................................................................. 61 5.3.1 Komposition der Dienste...................................................................................... 62 5.3.2 Interaktionskomponente ....................................................................................... 63 5.3.3 Ablaufsteuerungskomponente.............................................................................. 63

Menschliche Interaktionen in komplexen Web Services Inhaltsverzeichnis

Copyright TU Dresden, Nicolás Bleyh ii

5.3.4 Darstellungskomponente...................................................................................... 64 5.3.5 Beispielhafter Programmablauf............................................................................ 64

5.4 Autorenprozess ........................................................................................................... 65 5.5 Zusammenfassung....................................................................................................... 66

6 Implementierung ......................................................................................... 69 6.1 Orchestration der Dienste ........................................................................................... 69

6.1.1 Implementierung elementarer Web Services ....................................................... 69 6.1.2 BPEL-Erstellung .................................................................................................. 70 6.1.3 BPEL Ausführung ................................................................................................ 72

6.2 Implementierung von GUI4CWS ............................................................................... 73 6.2.1 Ablaufsteuerung ................................................................................................... 73 6.2.2 Darstellung ........................................................................................................... 75 6.2.3 Interaktion ............................................................................................................ 76

6.3 Anwendung auf das Szenario einer Reisebuchung..................................................... 77 6.4 Mögliche Verbesserungen des Prototyps.................................................................... 80

7 Zusammenfassung und Ausblick ............................................................... 83

8 Glossar .......................................................................................................... 85

9 Literaturverzeichnis .................................................................................... 87

10 Anhang.......................................................................................................... 93 10.1 Klassendiagramm von GUI4CWS........................................................................... 93 10.2 Dokumente für das Reisebuchungsszenario ............................................................ 94 10.3 Inhalt der CD ......................................................................................................... 104

Menschliche Interaktionen in komplexen Web Services Abbildungsverzeichnis

Copyright TU Dresden, Nicolás Bleyh iii

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].................................... 11 Abbildung 6: Web Service Stack [16]...................................................................................... 13 Abbildung 7: Choreographie.................................................................................................... 18 Abbildung 8: Orchestration...................................................................................................... 19 Abbildung 9: Aktivitätsdiagramm für eine Reisebuchung....................................................... 21 Abbildung 10: Szenario bei Verwendung eines Behavioral Interfaces.................................... 22 Abbildung 11: Szenario bei Verwendung einer Choreographie .............................................. 22 Abbildung 12: Szenario für eine Orchestration........................................................................ 23 Abbildung 13: Web Service Choreography Interface [27] ...................................................... 26 Abbildung 14: Hauptelement von BPEL ................................................................................. 34 Abbildung 15: Task-orientierte Benutzerinteraktion beim Oracle BPEL Process Manager [62].................................................................................................................................................. 46 Abbildung 16: Übliche Vorgehensweise bei der Interaktion eines Benutzers mit einem komplexen Web Service........................................................................................................... 47 Abbildung 17: Architektur des Choreographieansatzes........................................................... 49 Abbildung 18: Beispiel für den Choreographieansatz ............................................................. 50 Abbildung 19: Orchestrationsansatz mit einer abstrakten BPEL-Prozessbeschreibung als Behavioral Interface ................................................................................................................. 55 Abbildung 20: Transformationsweg von WSDL zu einer geräteunabhängigen Benutzeroberfläche................................................................................................................... 57 Abbildung 21: Darstellung von Vorlagewerten ....................................................................... 59 Abbildung 22: Gesamtarchitektur ............................................................................................ 62 Abbildung 23: Von GUI4CWS verwendete Dokumente ......................................................... 63 Abbildung 24: Realisierte SOA................................................................................................ 77 Abbildung 25: Reiseangebote suchen (Screenshot) ................................................................. 78 Abbildung 26: Sequenzdiagramm für einen Operationsaufruf mit GUI4CWS ....................... 79 Abbildung 27: Reise buchen (Screenshot) ............................................................................... 79 Abbildung 28: Ergebnis der Reisebuchung (Screenshot) ........................................................ 80 Abbildung 29: UML Klassendiagramm von GUI4CWS ......................................................... 93

Menschliche Interaktionen in komplexen Web Services Quellcodeverzeichnis

Copyright TU Dresden, Nicolás Bleyh iv

Quellcodeverzeichnis

Quellcode 1: Definition der Rollen in WS-CDL...................................................................... 29 Quellcode 2: Relationen zwischen Rollen in WS-CDL........................................................... 29 Quellcode 3: Definition der Kommunikationswege in WS-CDL ............................................ 29 Quellcode 4: Definition eines Datentypen in WS-CDL........................................................... 29 Quellcode 5: Beispiel einer mit WS-CDL beschriebenen Choreographie............................... 30 Quellcode 6: Definition der Teilnehmer in BPEL ................................................................... 32 Quellcode 7: Definition von Variablen in BPEL ..................................................................... 32 Quellcode 8: Definition eines correlationSet ........................................................................... 33 Quellcode 9: Mit BPEL beschriebener Teilablauf einer Reisebuchung .................................. 34 Quellcode 10: Beispiel eines XForms...................................................................................... 38 Quellcode 11: Beispiel für die XML-Repräsentation der Nutzereingaben .............................. 38 Quellcode 12: Angabe eines Datentyps zum Zweck der Validierung ..................................... 38 Quellcode 13: Beispiel für die Definition eines Eingabefelds in einer GUIDD ...................... 41 Quellcode 14: Beispiel für die Beschreibung eines statischen Geschäftsablaufs mit BPEL ... 53 Quellcode 15: Beispiel für die Beschreibung eines dynamischen Geschäftsablaufs mit BPEL.................................................................................................................................................. 54 Quellcode 16: Definition einer dynamischen Auswahlliste in der GUIDD............................. 60 Quellcode 17: Automatisch generierte Listenelemente ........................................................... 60 Quellcode 18: vereinfachte BPEL-Prozessbeschreibung des Reisebuchungsszenarios .......... 71 Quellcode 19: Definition von property und propertyAlias ...................................................... 72 Quellcode 20: Inhalt eines SOAP-Bodys als Variablenwert.................................................... 75 Quellcode 21: Inhalt einer BPEL-Bedingung .......................................................................... 75 Quellcode 22: Verkürzte abstrakte BPEL-Prozessbeschreibung des Reisedienstes ................ 78 Quellcode 23: TravelProcess.wsdl (Auszug) ........................................................................... 95 Quellcode 24: AirlineService.wsdl (Auszug)........................................................................... 96 Quellcode 25: HotelService.wsdl (Auszug) ............................................................................. 97 Quellcode 26: TravelProcess.bpel (Auszug).......................................................................... 100 Quellcode 27: abstractTravelProcess.bpel ............................................................................. 101 Quellcode 28: wsdlCatalog.xml ............................................................................................. 102 Quellcode 29: travel.pdd ........................................................................................................ 102 Quellcode 30: travelProcess.guidd (Auszug) ......................................................................... 103

Menschliche Interaktionen in komplexen Web Services Einleitung

Copyright TU-Dresden, Nicolás Bleyh 1

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 Nut-zung 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 Prozessbe-schreibungssprachen 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 erfor-derlich 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 menschli-che Faktor im Web-Service-Konzept bisher noch keine Berücksichtigung findet, muss von Entwicklern für jeden elementaren Web Service ein Benutzerinterface erstellt werden. Abge-sehen 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 Än-derung des Namens einer Funktion oder eines Parameters, muss das Benutzerinterface ange-passt werden. Wünschenswert wäre hier eine automatische Generierung des Benutzerinter-faces 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äfts-prozesse 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. meh-rere 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 ab-gleichen, so dass der Zeitraum des Hotelaufenthalts mit den An- und Abreisedaten der Flugli-nie übereinstimmen. Da diese Vorgehensweise sehr umständlich ist, sollten die Benutzerinter-faces 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 über-einstimmt. 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.

Menschliche Interaktionen in komplexen Web Services Einleitung


Abbildung 1: Beispiel für die bisherige Vorgehensweise bei Nutzerinteraktionen mit mehreren Diens-ten [1]

Da die Nutzerinteraktion über ein Benutzerinterface erfasst werden muss, liegt die Problem-stellung 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 evalu-ieren. Anhand dieser Analyse soll ein Konzept erarbeitet werden, wie mit Hilfe der in einer Kompositionssprache definieren Abhängigkeiten und Abläufe ein Benutzerinterface dyna-misch 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 „Zusammen-fassung und Ausblick“.

Zunächst werden im zweiten Kapitel die Grundlagen von Web Services und die damit ver-bundenen 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 unter-schiedlicher 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 zu-nächst Kompositionssprachen zur Beschreibung komplexer Web Service vorgestellt. An-schließ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 Überlegun-gen angestellt, wie die Komposition und Darstellung eines komplexen Dienstes aus der Be-nutzersicht geeignet realisiert werden kann. Darauf aufbauend wird die Architektur des Kon-zepts beschrieben.

Im vorletzten Kapitel wird die Implementierung des Konzepts in Form eines Prototyps vorge-stellt. Zum Abschluss wird die Funktionalität des Prototyps anhand des Szenarios einer Rei-sebuchung 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.

Menschliche Interaktionen in komplexen Web Services Grundlagen Web Services


2 Grundlagen Web Services Zunächst soll in diesem Kapitel das Konzept von Web Services und die grundlegenden Tech-nologien, 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 Compo-nent 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 An-wendungen 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, aller-dings 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 serializa-tion in conjunction with other Web-related standards.

In dieser Definition werden bereits die verwendeten Technologien erwähnt, auf die im nächs-ten Unterkapitel näher eingegangen werden soll. Allgemein betrachtet kommuniziert ein Web Service mit anderen Softwarekomponenten über XML-Nachrichten. Der Nachrichtenaus-tausch kann dabei insbesondere mit Hilfe von Internetprotokollen (z.B. HTTP oder SMTP) stattfinden. Damit ein Web Service von anderen Anwendungen aufgerufen werden kann, be-nötigt dieser eine maschinenlesbare Schnittstelle und muss durch eine URI (Uniform Res-source 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].



Web Services werden oft auch im Zusammenhang mit dem Paradigma der Service-orientierten 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 anbie-ten. Ein Service ist eine feste, definierte Leistung, die als Element eines oder mehrerer größe-rer Verarbeitungsabläufe verwendet werden kann. Als solcher stellt der Service eine abstrakte fachliche Sicht auf den anbietenden Anwendungsbaustein dar und verbirgt alle Implementati-onsdetails. Services werden über einen einheitlichen Mechanismus aufgerufen, der die An-wendungsbausteine plattformunabhängig miteinander verbindet und alle technischen Details verbirgt. Die elementaren Grundgedanken einer SOA sind somit die Trennung der Zuständig-keiten 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, ei-nem 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 Ser-vice Provider eine Beschreibung des Services, welche die Spezifikation der Schnitt-stelle enthält.

3. Über ein lokales Interface ruft er den Service auf, womit es zur Ausführung des Diens-tes 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üs-sen ü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 Archi-tekturmodell SOA stammt laut [7] auch der Name „Service“. Die Bezeichnung „Web“ entwi-ckelte sich daraus, weil sich HTTP als Transport-Protokoll durchsetzte. Technologisch kann eine SOA aber auch mit anderen Technologien wie beispielsweise CORBA umgesetzt wer-



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 Langua-ge (WSDL). Diese wird über einen Service Broker veröffentlicht, dessen Aufgabe UDDI (U-niversal Description, Discovery and Integration) übernimmt. Die Kommunikation zwischen den drei Teilnehmern erfolgt über SOAP, einem XML-basierten Nachrichtenformat. Grundla-ge für SOAP und WSDL ist XML.

2.2.1 XML

XML (Extensible Markup Language) ist heutzutage das Standardformat zur Erstellung ma-schinen- und menschenlesbarer Dokumente. Es ist eine deskriptive Sprache, die vor allem zur plattformunabhängigen Beschreibung und für den Austausch komplexer Datenstrukturen ein-gesetzt wird [8]. Pflege und Weiterentwicklung des XML-Standards liegen in der Verantwor-tung des W3C (World Wide Web Consortium) [9].

XML-Dokumente sind in Form einer Baumstruktur aufgebaut, die durch Elemente repräsen-tiert 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ätz-lich eine Grammatik besitzt. Diese Grammatik kann z. B. in Form einer DTD (Document Ty-pe 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 un-terstü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 Attri-bute 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 verwen-den sowohl SOAP als auch WSDL XML zur Beschreibung von Schnittstellen, Datenstruktu-ren und Übertragungsformaten.



2.2.2 SOAP

SOAP ist der Standard des Middleware-Protokolls von Web Services und wurde von Micro-soft 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 Pro-tokolle besitzen jedoch entscheidende Nachteile [2]:

• Client und Server müssen die gleiche Plattform verwenden, d.h. sie sind eng gekop-pelt. 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 wer-den, da es für die Kommunikation das HTTP-Protokoll verwenden kann. Der dafür verwende-te 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 Transakti-onseigenschaften (z.B. eine Transaktionsnummer) an den Empfänger einer Nachricht übermit-telt. 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 Inter-mediaries. Diese sind gleichzeitig Sender und Empfänger. Im SOAP header kann festgelegt



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 sol-len. 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 beschrei-ben, welches für den Transport bestehende und verbreitete Kommunikationsprotokolle wie HTTP, SMTP oder FTP verwendet [8].

2.2.3 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 bei-spielsweise 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 be-schreiben 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 (sie-he 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



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 Nachrich-ten 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 Ant-wort.

• 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 be-zeichnet. 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 2.2.2.) 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.



Abbildung 4: schematischer Aufbau einer WSDL-Datei

Durch die Trennung von abstraktem und konkretem Teil erhöht sich die Wiederverwendbar-keit von WSDL-Beschreibungen. So kann ein abstrakter Teil für mehrere konkrete Teile ver-wendet 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 gene-rieren Werkzeuge aus der WSDL-Beschreibung einen Methodenrumpf für die jeweilige Pro-grammiersprache, über welche der Client den Web Service aufrufen kann.

Mit WSDL kann weder die Semantik des Web Services noch die seiner Parameter beschrie-ben werden (siehe hierzu RDF(S), OWL(S)). WSDL definiert auch keine Bindung von Daten-typen 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.

2.2.4 UDDI

Als Vermittler zwischen dem Anbieter und den Nutzern von Web Services wird ein Ver-zeichnis benötigt, bei dem Dienste registriert werden können bzw. nach Diensten anderer An-bieter gesucht werden kann. Zu diesem Zweck wurde UDDI (Universal Description, Discove-ry and Integration) von IBM, Ariba und Microsoft entwickelt [10]. Seit dem Jahr 2002 wird UDDI vom Standardisierungsgremium OASIS (Organization for the Advancement of Structu-red 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öffentli-chen. 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.



Um die Informationen über Web Services in einem UDDI-Verzeichnis kategorisieren zu kön-nen, 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 ange-botenen Produkten/Services.

• Grüne Seiten enthalten Informationen über die von dem jeweiligen Unternehmen an-gebotenen 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 Informati-onsmodell ist in einem XML-Schema festgelegt und beinhaltet folgende Elemente [2]:

• businessEntity: Im Element businessEntity sind Informationen über das Un-ternehmen selbst enthalten, zum Beispiel der Name, eine Beschreibung, Kontaktin-formationen sowie das serviceKey-Element, ein Verweis auf die von dem Unter-nehmen 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 Be-schreibung 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 Be-standteile 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 Konzer-ne gedacht, die nicht durch ein einziges businessEntity-Element repräsentiert werden können. Es ermöglicht einem solchen Unternehmen, mehrere businessEn-tity-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.



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 Dienstan-bietern unterschieden: UDDI-Operatoren und private UDDI-Verzeichnisdienste. Der Unter-schied 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 Ge-samtheit 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 Technolo-gie 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 Kos-ten 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 Unter-nehmens. Eine solche Integration ist notwendig, um eine weitere Automatisierung und Opti-mierung 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 erfolg-te 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



im Laufe der Zeit zu einer oft unüberschaubaren Vielzahl von Verbindungen mit der Konse-quenz, 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 Daten-transformation, so wird durch diese Architektur die direkte Kommunikation vieler Anwen-dungen über einzeln zu entwickelnde Adapter überflüssig. Für die Kommunikation der ein-zelnen Anwendungen mit der zentralen Komponente kann eine Web-Service-Schnittstelle zum Einsatz kommen. Da die Integration auf Geschäftslogikebene voraussetzt, dass die ein-zelnen Anwendungen über Programmierschnittstellen verfügen, über die auf die Geschäftslo-gik 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 Unternehmens-grenzen hinweg fortgesetzt, da die Integration von Anwendungen externer Partnerunterneh-men in die unternehmensinterne Anwendungslandschaft in der heutigen Zeit eine zunehmen-de Rolle spielt. Durch die Verwendung von standardisierten Web-Service-Protokollen besteht die Aussicht, solche Anbindungen schneller, billiger und flexibler als mit bisherigen Stan-dards, 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) Bezie-hungen. 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 Um-feld 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 Daten-formate, 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-



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 weiter-zuleiten. 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 rea-lisieren.

• Transport von XML-Nachrichten: Übertragene Nachrichten sind von Entwicklern les-bar, 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 Nachrichten- und 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 Da-ten 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 einge-setzt.

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 Transaktions-mechanismen (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]



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.

Menschliche Interaktionen in komplexen Web Services 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 Ser-vice kann selbst wieder als elementarer Web Service verfügbar gemacht werden [17].

Bisher wurde die Komposition von Web Services meist in traditionellen Programmierspra-chen wie Java oder C# realisiert, wobei der Entwickler u.a. viel Ziel mit der bloßen Konver-tierung 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 Anwendun-gen 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 konzentrie-ren.

Hier liegt es nahe, die von Workflow-Management-Systemen (WfMS) bekannte Idee auf-zugreifen, 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 Software-entwickler, der Anwendungsbausteine als Web Service bereitstellt, und dem Geschäftsanalys-ten, 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 Pro-zessbeschreibungen werden durch ein spezielles Laufzeitsystem interpretiert, was eine auto-matische 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 Be-nutzerinteraktion in einen komplexen Web Service integriert werden können.

3.1 Workflow-Management

Im Bereich des Workflow-Managements existieren zwei Organisationen, die sich mit Spezifi-kationen 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



der Standardisierung der Architektur und Schnittstellen von Geschäftsprozess-Management-Systemen (BPMS) zusammengefunden haben.

Die in diesen Organisationen entwickelten Geschäftsprozesssprachen sind Technologieunab-hä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 Kon-zepte. 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 Softwareanwendun-gen getätigt werden, um ein Geschäftsziel zu erreichen (Beispiel: Buchung einer Rei-se) [10], [19].

• Aktivität (Activity): Aktivitäten sind die elementaren Bestandteile eines Geschäftspro-zesses. 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 Automatisie-rung eines Geschäftsprozesses, in welchem Dokumente, Information oder Aufgaben zwischen Teilnehmern dieses Geschäftsprozesses weitergereicht werden [21]. Er bein-haltet 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 Ge-schäftsprozess besteht darin, dass der Workflow beschreibt, wie und mit welchen Mit-teln 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 über-geordneten 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 automati-sieren die Ausführung von Workflows und ermöglichen es, während der Durchfüh-rung 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 De-sign, Entwicklung, Ausführung und Analyse von Workflow-Prozessen unterstützt [10].

• Geschäftsprozessmanagement (Business Process Management, BPM): Geschäftspro-zessmanagement 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, Strategieum-setzung und Erfüllung der Kundenerwartungen effektiv und effizient zu realisieren [23].

• Geschäftsprozessmanagement-Systeme (BPMS): Diese Systeme dienen der Unterstüt-zung des Geschäftsprozessmanagements. Das Workflow-Management-System stellt dabei eine Teilkomponente des Geschäftsprozessmanagement-Systems dar [20].



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üh-rungsreihenfolge 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 automati-sierten Ressource ausgeführt werden soll. Dies entspricht der oben genannten Defini-tion von Aktivitäten.

• Routing nodes definieren die Reihenfolge, in der die Aufgaben ausgeführt werden sol-len. 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 Definiti-on 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äfts-prozesse 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) durch-gesetzt zu haben. BPEL liegt in der Verantwortung der Organization for the Advancement of Structured Information Standards (OASIS, [25]) und wird im Kapitel 4.1.3 ausführlich be-sprochen.

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 beschrie-ben 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 „program-ming in the small“ unterscheidet.

Je nach Zeitpunkt, zu dem bekannt sein muss, welche konkreten Web Services in der Anwen-dung 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 Zeit-punkt, zu dem er nachgefragt wird [17]. Um Web Services dynamisch zu komponieren, müs-



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.

3.2.1 Choreographie

Eine Choreographie beschreibt eine Kollaboration zwischen mehreren Diensten, um ein ge-meinsames 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 beteilig-ten 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 Teil-nehmer 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än-dig sind.

Abbildung 7: Choreographie

Statt Choreographie ist in diesem Zusammenhang oftmals auch von Koordination oder Kon-versation die Rede. Die Beschreibung der Menge zulässiger Nachrichtenabfolgen wird Kon-versations-, Koordinations- oder (in [10]) Geschäftsprotokoll (business protocol) genannt.

Beispiele für Choreographiebeschreibungssprachen sind WSCI und WS-CDL, auf die in den Kapiteln 4.1.1 und 4.1.2 eingegangen wird.

3.2.2 Behavioral Interface

WSDL beschreibt lediglich einzelne Operationen von Web Services, nicht aber Nachrichten-abfolgen. Mit Hilfe des Modells des Behavioral Interface wird WSDL dahingehend erweitert,



dass Abhängigkeiten zwischen Interaktionen festgelegt werden können. Dabei können Kon-trollflussabhängigkeiten, Datenflussabhängigkeiten, Zeitbedingungen, Nachrichtenbeziehun-gen 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 be-schreibt auch ein Behavioral Interface keine internen Details wie z.B. Datentransformationen [28].

Beispiele für Beschreibungssprachen, mit denen ein Behavioral Interfaces beschrieben wer-den kann, sind WSCL und die abstrakten BPEL-Prozesse (siehe Kapitel 4.1.3).

3.2.3 Orchestration

Eine Orchestration beschreibt einen Geschäftsprozess aus der Sicht eines Teilnehmers. Diese beinhaltet Kommunikations- und interne Aktionen, deren Reihenfolge und Ausführungsbe-dingungen. Interne Aktionen können z.B. Datentransformationen oder Aufruf von internen Softwaremodulen sein, die nicht als Web Service angeboten werden. Kommunikationsaktio-nen 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 sicht-bar sind. Da eine Orchestration aber die interne, nicht öffentliche Geschäftslogik aus der Per-spektive 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 (sie-he Kapitel 4.1.3).

3.3 Szenarien für Benutzerinteraktionen

Um die Unterschiede der in Kapitel 3.2 vorgestellten Kompositionsarten noch einmal zu ver-tiefen, 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.



Die beiden Szenarien unterscheiden sich darin, ob die Benutzerinteraktion Teil innerhalb ei-nes Workflows ist, d.h. die Nutzerinteraktion ist notwendig, um den Workflow erfolgreich abzuarbeiten („Task-orientierte Nutzerinteraktion“), oder ob der Nutzer den Workflow an-stößt, d.h. der Workflow dient der Zielerreichung des Nutzers („Ziel-orientierte Nutzerinter-aktion“).

3.3.1 „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. Hotel-agent 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.



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 Kompositions-sprachen 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 Ge-schä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



ein bestimmtes Ergebnis liefert, muss Operation B ausgeführt werden). Die eigentliche Kom-position 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 Or-chestration 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 Operatio-nen 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 Ser-vice des Reisebüros. Stattdessen existiert ein Dokument, das den Geschäftsprozess aus einer globalen Sicht heraus beschreibt. Anhand dieses Dokuments können die beteiligten Teilneh-mer ihr öffentliches Verhalten so implementieren, dass der Geschäftsprozess korrekt und er-folgreich 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 4.1.2 näher eingegangen.

Abbildung 11: Szenario bei Verwendung einer Choreographie



3.3.2 „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 Ab-lauf 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 wer-den können, die im Unterschied zur „Ziel-orientierten Nutzerinteraktion“ keine Anfrage ge-stellt 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 Benut-zerinteraktion für das Fortführen des Geschäftsablaufes notwendig ist. Tritt im Geschäftsab-lauf 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 Benutzerinterakti-onen 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-



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 defi-niert 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 Nut-zerinteraktion“ 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 Benutzer-schnittstelle 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 ver-knüpft sind. Daher sollen die im folgenden Kapitel untersuchten Kompositionssprachen unter anderem darauf überprüft werden, inwiefern sie dieses Konzept unterstützen.

Menschliche Interaktionen in komplexen Web Services 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. Begon-nen 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 Benutzerinterak-tionen in komplexe Web Services bzw. Geschäftsprozesse.

4.1 Kompositionssprachen

Dieses Kapitel stellt einige wichtige Kompositionssprachen (die alle XML als Syntax ver-wenden) 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 Pro-zesslogik und den verwendeten Web Services vorgenommen wird. So können bei Be-darf Prozesse leicht ausgelagert werden

• Elementare und strukturierte Aktivitäten: Es sollte die Unterscheidung zwischen ele-mentaren 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 über-geordneten komponierten Web Services sein. Daher müssen komponierte Web Servi-ces bestimmte Eigenschaften erfüllen, um die Integrität und Konsistenz der Interaktio-nen 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 An-fragen zueinander in Korrelation stellen zu können. Zum anderen müssen komponierte Web Services Ausnahmen und transaktionale Integrität gewährleisen. So dürfen bei-spielsweise 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 Architek-turen lassen sich Design und Entwicklung einer Unternehmensanwendung modularisieren und in fachlich verschiedene Bereiche aufteilen. So können einzelne Fachbereiche ihre spezifi-schen Prozesse definieren und unabhängig voneinander modellieren, um diese dann anderen Unternehmensbereichen als Service zur Verfügung zu stellen. Mit Hilfe von Kompositions-sprachen (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 3.3.1 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



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.

4.1.1 WSCI

Mit WSDL ist es nur möglich, die von einem Web Service angebotenen Operationen mit ih-ren zugehörigen Ein- und Ausgabeparametern zu definieren. Es ist jedoch nicht möglich, bei-spielsweise die Reihenfolge anzugeben, in der die angebotenen Operationen ausgeführt wer-den 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 vor-liegt [29].

WSCI erweitert WSDL dahingehend, dass beschrieben werden kann, wie die durch WSDL definierten Operationen im Kontext der mit anderen Web Services ausgetauschten Nachrich-ten choreographiert werden sollen. Eine Schlüsseleigenschaft von WSCI ist, dass nur das be-obachtbare Verhalten eines Web Services beschrieben wird. WSDL legt mittels der Operatio-nen 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 gesen-det 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 Operati-onen als Transaktion ausgeführt werden. Damit werden die anderen Teilnehmer dar-über informiert, dass diese Operationenabfolge „ganz oder gar nicht“ ausgeführt wird.



Außerdem ermöglicht diese Eigenschaft dem Web Service, als Teil innerhalb einer Transaktion mit anderen Web Services teilzunehmen. Wie der Web Service die Trans-aktion 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 Ausnahme- bzw. Fehlersituation beschrieben, indem alternative Ablaufanweisungen angegeben werden können.

• Thread management: WSCI beschreibt, ob und wie ein Web Service mehrere Konver-sationen 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 Nach-richten festgelegt werden, die das beobachtbare Verhalten des Web Service beeinflus-sen.

• 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 ver-schiedener 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 un-terschiedlicher 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 al-lerdings 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 2002. Ebenso existieren keine frei verfügbaren Autorenwerkzeu-ge zur Erstellung von WSCI-Beschreibungen. Aufgrund dieser Tatsachen scheidet WSCI als Grundlage für eine generische Benutzerschnittstellenbeschreibung für komplexe Web Servi-ces aus. Das Konzept von WSCI als Choreographiebeschreibungssprache wurde jedoch in WS-CDL integriert und weiterentwickelt.

4.1.2 WS-CDL

WS-CDL (Web Service Choreography Description Language) ist eine klassische Choreogra-phiesprache (siehe Kapitel 3.2.1) und beschreibt aus einer globalen Sichtweise heraus die Kollaboration mehrerer Teilnehmer, indem das öffentliche Verhalten (also der Nachrichten-austausch zwischen den Teilnehmern) definiert wird. Mit Hilfe von WS-CDL ist somit ein



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 Teil-nehmern verwendet werden, die jeweils in verschiedenen Umgebungen und mit unter-schiedlicher 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 zusam-mengesetzt werden.

• Modularität: über ein „inclusion“-Konstrukt kann eine Choreographie aus Teilen ver-schiedener 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 kommunizie-ren 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 Choreogra-phien 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 pa-ckage. 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 han-delt 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.



<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 beinhal-tet. Diese verweisen über die Attribute typeRef und behavior auf die Rolle und das Ver-halten 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 Dienstanbie-ter 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. Da-bei handelt es sich um eine Kommunikation mit Anfrage- und Antwortnachricht (request-respond), 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 Elemen-ten 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:



• sequence, parallel, choice: Dabei handelt es sich um so genannte „ordering structures“. Diese geben die Reihenfolge vor, in der die einzelnen Aktivitäten ausge-fü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üh-rung 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 beschrie-

ben, in der ein Teilnehmer entweder keine Aktion (noAction) ausführt bzw. die Ab-arbeitung der Aktion den Rest der Choreographie nicht beeinflusst und daher nicht öf-fentlich 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 relationshipType- und 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-



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üt-zung genießt [33]. Ohne geeignete Autorenwerkzeuge wird es daher sehr schwer möglich sein, diesen Standard durchzusetzen und zu verbreiten.

4.1.3 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: „Klas-sische“ 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 weiter-entwickelt wird BPEL von OASIS (Organization for the Advancement of Structured Informa-tion 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 (execu-table) und abstrakten (abstract) Prozessen. Ausführbare Prozesse definieren den internen Ab-lauf 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 Ge-schäftsprotokoll aus der Sicht eines Partners zu beschreiben. Dabei wird der sichtbare Nach-richtenaustausch 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.



Das Wurzelelement eines BPEL-Dokuments ist process. Über das Attribut abstractPro-cess wird angegeben, ob es sich um einen abstrakten oder ausführbaren Prozess handelt. Eine vereinfachte Prozessbeschreibung besteht aus den drei Bereichen partnerLinks, va-riables und dem eigentlichen Prozessablauf.

Über das Element partnerLinks wird beschrieben, welche Teilnehmer (im Beispiel: Kun-de, Fluglinie, Hotelagent) in den Prozess involviert sind und welche Rolle (im Beispiel: Airli-ne_Role, HotelAgent_Role) sie dort spielen. Dies wird durch das Element partnerRole an-gegeben. Über das Attribut parterLinkType wird der mit dieser Rolle assoziierte Web Ser-vice referenziert. Die partnerLinkType-Elemente sind eine von BPEL eingeführte Erwei-terung 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ön-nen Daten der Prozesslogik oder der ausgetauschten Nachrichten beinhalten. Erhält ein Pro-zess eine Nachricht, so werden die übergebenen Daten in die angegebene Variable geschrie-ben, 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 (Att-ribut messageType) oder ein Element einer WSDL-Nachricht (Attribut element) angege-ben 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 pro-perties 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.



<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 er-

haltene 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 angege-benes Kriterium erfüllt ist.

• switch: Anhand eines Kriteriums wird exakt eine der aufgelisteten Aktivitäten ausge-führt.

• scope: Mit diesem Elemente können mehrere Aktivitäten zusammengefasst werden, um diesen einen gemeinsamen faultHandler oder compensationHandler zuzu-weisen, 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 dar-gestellt.



Abbildung 14: Hauptelement von BPEL

Der folgende Codeausschnitt zeigt die BPEL-Beschreibung eines Teilablaufs bei der Einho-lung 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.



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 un-ter 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 Unterprozes-sen 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 Komposi-tion 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 Kompo-sitionssprachen bereits eine größere Anzahl von kommerziellen und Open-Source-Werkzeugen, um BPEL-Prozesse zu erstellen und auszuführen.

4.1.4 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 wei-tere 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 entwi-ckelt, dann aber in die Verantwortung des W3C übergeben. Es erweitert WSDL dahingehend, dass die erlaube Reihenfolge des Nachrichtenaustausches beschrieben werden kann. Aller-dings sind die von WSCL angebotenen Möglichkeiten sehr eingeschränkt. So können ledig-lich 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 ver-folgt wird.

RosettaNet [40] ist ein Konsortium mit über 500 Unternehmen, das Standards zum elektroni-schen Geschäftsverkehr entwickelt. Ein Bestandteil von RosettaNet sind die so genannten Partner Interface Processes (PIP), womit Standard-Nachrichten und -Choreographien be-zeichnet 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 Fra-mework (RNIF). Dieses beinhaltet Spezifikationen, um Sicherheit und Vertrauen im Nach-richtenaustausch 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ßer-dem ist es nicht möglich, eine eigene Choreographie zu spezifizieren, sondern es wird mit den PIP lediglich eine umfangreiche Sammlung von fest definierten Geschäftsprozessbeschrei-bungen 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



für die Generierung einer Benutzerschnittstelle weiter verfolgt. Zusammenfassend sollen die-se beiden Kompositionssprachen noch einmal voneinander abgegrenzt und bewertet werden.

Vergleicht man die Syntax der beiden Standards, so stimmen die Semantiken zahlreicher Ak-tivitäten überein. Diese Ähnlichkeiten wurden in der Arbeit [42] ermittelt, um sie als Grund-lage für eine automatische Überführung von WS-CDL- in BPEL-Beschreibungen und umge-kehrt zu verwenden. Trotz einiger Gemeinsamkeiten kann diese Transformation jedoch nicht vollständig vorgenommen werden. Der Hauptunterschied liegt darin, dass mit WS-CDL Cho-reographien beschrieben werden können, während BPEL den Schwerpunkt auf die Orchestra-tion legt. Mit BPEL kann daher lediglich die Sicht eines Teilnehmers auf den Nachrichtenaus-tausch 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 „akti-ve“ Regeln, die ausgeführt werden, um die nächsten Aktionsschritte zu ermitteln [43]. Interes-sant 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 gra-phischen Hilfsmittel, um die Beschreibung anzulegen. Möglich ist zwar eine grafische Dar-stellung 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 Autoren-umgebungen soll versucht werden, für beide Kompositionssprachen eine Konzeptidee zu fin-den, 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 imple-mentiert werden. Dies beinhaltet jedoch zahlreiche Nachteile. So muss für den Aufruf jedes einzelnen Web Services eine neue Clientanwendung geschrieben werden. Da die Schnittstel-lenbeschreibung 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 Benutzer-schnittstelle 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 Aus-wahlliste erfolgen. Außerdem beschreibt WSDL keine Semantiken der Funktionen oder deren Ein- und Ausgabeparameter. Der Nutzer erhält zwar eine korrekte Eingabemaske, als Be-schriftung werden jedoch die Bezeichnungen der WSDL-Beschreibung übernommen, die meistens aus Programmierersicht und nicht aus Nutzersicht gewählt sind.



Um Web Services über eine Benutzerschnittstelle anzusprechen, existieren zwei Lösungsan-sä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 Benutzerschnitt-stelle notwendig sind.

Unterschieden wird außerdem zwischen Rich-Client- und Web-Anwendungen. Rich-Client-Anwendungen bezeichnet Applikationen, die vor der Verwendung auf der Nutzerseite instal-liert 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 Formula-re zur Datenerfassung vorgestellt. Im Anschluss werden unterschiedliche Konzepte zur Gene-rierung 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.

4.2.1 XForms

Die bekannteste Form einer Benutzerschnittstelle zur elektronischen Erfassung von Nutzer-eingaben stellen HTML-Formulare dar. Bei Rich-Client-Anwendung stellt meistens die jewei-lige Programmiersprache Bibliotheken zur Verfügung, mit denen Formularelemente erstellt werden können. Sowohl die Verwendung von HTML also auch von GUI-Bibliotheken besit-zen jedoch den Nachteil, dass sie erstens plattformabhängig sind und zweitens nur beschränk-te 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 die-sem 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 Ver-sion 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 4.2.3.2.) Deshalb sollen in diesem Kapi-tel die Grundlagen des Standards erläutert werden.

XForms spezifiziert zwei verschiedene Bereiche. Zum einen das model, indem die einzuge-benden 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



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 (Aus-wahl 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 Daten-modells die entsprechenden Werte eingetragen werden. Des Weiteren ist es möglich, die ein-gegebenen 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 mit-tels 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.



Durch die konzeptionelle Ausrichtung von XForms auf geräteunabhängige Benutzerinterakti-onen, 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 Da-ten 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 kom-binieren, da über die WSDL-Beschreibung die für den Funktionsaufruf einzugebenden Daten-typen bereits definiert sind.

4.2.2 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 For-mularelemente kann allerdings kein Einfluss genommen werden, ebenso sind die Formular-elemente 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 Benutzer-schnittstellenbeschreibung 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 plattfor-munabhä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 Pa-rameterbenennung 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 wer-den. Ein bedienbares Nutzerinterface ist so davon abhängig, ob in der WSDL-Datei nutzer-freundliche Bezeichnungen gewählt wurden. Abgesehen davon kann bei den oben vorgestell-ten 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 vor-zunehmen. Diese Vorgehensweise wird auch in WSGUI (siehe Kapitel 4.2.3.2) verfolgt.

4.2.3 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 da-von werden im Folgenden vorgestellt.

4.2.3.1 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



eigene Markupsprache namens eNode UI Markup Language verwendet. Diese dient haupt-sä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 eNo-de 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 an-hand 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.

4.2.3.2 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 Ober-fläche zur Verfügung zu stellen. Hierfür wird zusätzlich zur WSDL-Beschreibung ein weite-res 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 ge-schickt wird. Da die Beschreibung des Benutzerinterfaces mit der Syntax von XForms reali-siert wird, können die Eingabemasken auch in andere Ausgabeformate wie beispielsweise WML oder VoiceXML integriert werden. WSGUI beschränkt sich somit nicht nur auf brow-serbasierte Lösungen, sondern kann auch für Rich Clients verwendet werden.

Die Beschreibung der Benutzeroberfläche erfolgt in der GUIDD durch die Elemente opera-tions, formComponents und outputTypes. Jede operation besitzt ein Attribut name, mit dem auf die zugehörige WSDL-Operation verwiesen wird. Außerdem besitzt eine ope-ration die Kindelemente prettyname und description, mit denen zum Zweck der Nut-zerfreundlichkeit ein Name und eine Beschreibung des Formulars für die entsprechende Ope-ration angegeben werden kann. Die Beschriftung kann mit Hilfe des Attributes lang in meh-reren 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 Er-gebnis 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 Ele-mente 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 beschriebe-nen Parameter, der für den Operationsaufruf benötigt wird, erfolgt innerhalb des formCom-ponent-Elements und des input-Elements über einen XPath-Ausdruck.



<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 hin-zuzufügen oder zu entfernen.

WSGUI besitzt starke Ähnlichkeit mit einem anderen Konzept zur Generierung von Benut-zerschnittstelen 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 Realisie-rung 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 auf-gerufen 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 Ser-vice, der ein oder mehrere Portlets bereitstellt und diese über eine WSPR-Schnittstellen anbie-tet. Der Consumer ist ein Web-Service-Client, der WSRP-Web-Services aufruft und eine Por-talumgebung bereitstellt, in welche die angebotenen Portlets integriert werden können. Pro-ducer 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 Produ-cer angebotenen, verteilt laufenden Portlets interagieren.

In welchem Kontext WSPR für die Lösung der Problemstellung dieser Arbeit verwendet wer-den könnte, wird im Kapitel 5.1.1 erläutert.



4.4 Benutzerinteraktion in komplexen Web Services

Lösungen, mit denen die in Kapitel 3.3.1 vorgestellte Ziel-orientierte Benutzerinteraktion mit-tels 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 Ka-piteln vorgestellt werden. Im ersten wird eine Erweiterung der BPEL-Syntax vorgeschlagen, um Nutzerinteraktionen in Geschäftsprozessen abbilden zu können. Der zweite Ansatz reali-siert die Nutzerinteraktion über einen zusätzlichen Web Service, der eine Schnittstelle zwi-schen dem Nutzer und dem BPEL-Prozess darstellt.

4.4.1 BPEL4PEOPLE

Von IBM und SAP wurde im Juli 2005 ein „White Paper“ veröffentlicht, in dem eine Erwei-terung von BPEL vorgeschlagen wird, um menschliche Benutzeraktionen in den Geschäfts-prozess zu integrieren, da BPEL nur auf Web Services basierende automatisierte Geschäfts-prozesse unterstützt [56]. Ein Beispiel für die Einbeziehung von Menschen in einen Ge-schäftsprozess wurde im Kapitel 3.3.2 mit der Kreditvergabe an einen Kunden bereits illust-riert. Bei nicht eindeutiger Kreditwürdigkeit oder falls der Kredit eine bestimmte Höhe über-schreitet, 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 Servi-ces basierende Prozessbeschreibungen um Nutzerinteraktionen zu erweitern, soll hier ein kur-zer Überblick über die Ideen und Ansätze des White Paper gegeben werden. Um die Notwen-digkeit der Integration von menschlichen Benutzerinteraktionen in Geschäftsprozesse zu ver-deutlichen, werden darin zahlreiche Szenarien vorgestellt:

• Benutzeraktivitäten: Benutzer können als spezielle Art von Aktivitäten in den Ge-schä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 Prakti-kanten 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 Ge-schäftsprozess nur mit Hilfe einer menschlichen Benutzerinteraktion fortgeführt wer-den kann. Ein Beispiel wäre ein Timeout, der eintritt, wenn eine bestimmte Aktion in-nerhalb eines Zeitraums nicht durchgeführt wurde. Dann muss ein Benutzer entschei-den, wie der Prozess weiter ablaufen soll. Möglicherweise müssen auch einige Pro-zessschritte 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ün-schenswert. Auch hier sollte ein Nutzer entscheiden, welche Teile eines Geschäftspro-zesses 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 ei-nem Geschäftsprozess zu interagieren, indem er den Status abfragt, fehlende Daten



eingibt, Prioritäten setzt oder den Prozess mit anderen Geschäftsprozessen synchroni-siert.

• Erweiterte Interaktionen: Des Weiteren werden in [56] komplexere Abläufe (Muster) vorgestellt, wie Benutzer mit Geschäftsprozessen interagieren. Auch für diese Interak-tionsmuster 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 Auf-gabe 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 peo-ple 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 mehr-sprachige 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 unerledig-ten 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 Ele-ment 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 Asso-ziation 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 Ge-schäftsprozesses.



Über das Element people link werden Benutzergruppen mit einer generic human role assozi-iert. 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 depart-ment_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 die-sem 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 so-mit weder eine BPEL4PEOPLE-Syntax noch eine entsprechend erweiterte BPEL-Engine. Daher konnte der Ansatz trotz interessanter Lösungsideen in dieser Arbeit nicht weiterverfolgt werden.

4.4.2 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 Nutzer-aktivitäten bei diesen jedoch nicht innerhalb der Geschäftsprozessbeschreibung definiert, son-dern der Nutzer kann über einen zusätzlichen Web Service mit dem Geschäftsprozess inter-agieren.

So wird in [57] eine Architektur namens PerCollab vorgestellt, wie eine Task-orientierte Be-nutzerinteraktion mit BPEL realisiert werden kann. Der eigentliche Geschäftsablauf wird da-bei 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 einzubin-den. 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 Archi-tektur PerCollab. Auch der TaskManager Service bietet eine WSDL-Schnittstelle an, so dass dieser wie ein normaler Web Service angesprochen werden kann. Die angebotenen Funktio-nen sind dabei:

• initiateTask: Stößt ein Task an. • updateTask: Aktualisiert ein Task. • completeTask: Teilt mit, wenn ein Task erledigt oder abgebrochen wurde.



• 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 Ele-mente:

• 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ültig-

keit 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 ex-ternen 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 darge-stellt 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.



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. Aller-dings ist eine solche Einigung schon alleine aus kommerziellen Gesichtspunkten eher un-wahrscheinlich.

Eine weitere Idee ist, neue BPEL-Elemente einzuführen, um eine Task-orientierten Nutzerin-teraktion innerhalb eines BPEL-Prozesses zu beschreiben. Um diese neuen Elemente zu inter-pretieren 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 Nutzerin-teraktion 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.

Menschliche Interaktionen in komplexen Web Services 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 übli-che Vorgehensweise aussieht, um eine Benutzerinteraktion mit einem komplexen Web Servi-ce 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 An-wendung 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 beispielswei-se um ein Java Servlet, so kann dieses nicht auf eine Windows .NET Umgebung portiert wer-den. Ebenfalls fest implementiert ist die Darstellung des Benutzerinterfaces. Eine Verände-rung 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 beschrei-ben. 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 gu-ten 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 Kompositi-onsbeschreibung 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 nutzer-freundliche Oberfläche für die Darstellung der von einem Web Service angebotenen Operati-onen 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.



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üm-mern, 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ängig-keit, einer großen Verbreitung und damit hoher Verfügbarkeit. Außerdem sind Browser be-reits in der Lage, Benutzerschnittstellen anhand von Oberflächenbeschreibungssprachen (wie z.B. HTML) darzustellen. Das Mapping von einer Oberflächenbeschreibungssprache auf gra-phische Ein- und Ausgabeelemente muss bei einer Rich-Client-Anwendung erst noch imple-mentiert werden. Insofern bieten Web-Anwendungen auch eine viel größere Geräteunabhän-gigkeit, da bei einer Rich-Client-Anwendung für jedes Gerät eine neue Oberfläche implemen-tiert werden muss. Bei Web-Anwendungen genügt dagegen eine Anpassung der Oberflächen-beschreibung, da sich um deren Interpretation der Browser kümmert. Aufgrund dieser ge-nannten Vorteile wird im vorliegenden Konzept eine browserbasierte Lösung verfolgt.

In den folgenden Unterkapitel soll anhand einiger bisher vorgestellten Technologien ein Kon-zept namens GUI4CWS (GUI for Complex Web Services) vorgestellt werden, wie das Szena-rio 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 Ab-schluss des Kapitels bilden eine Vorstellung der Gesamtarchitektur des erarbeiteten Konzep-tes 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 Be-darf 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 Or-chestrierungs-Engine kontrolliert wird. Im Falle einer Ziel-orientierten Nutzerinteraktion müsste aber der Nutzer die übergeordnete Instanz darstellen, was hieße, dass auf der Nutzer-seite 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 eingeschlos-sen, 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 Benutzerin-teraktionen näher vorgestellt und miteinander verglichen werden.



5.1.1 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 kompo-nierten Dienstes ist. Zur Beschreibung der Choreographie bietet sich WS-CDL an (siehe Ka-pitel 4.1.2). Darin wird der gesamte globale Ablauf zwischen den beteiligten Diensten, inklu-sive 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 Benutzer-oberflä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 ge-wünschten (komponierten) Dienst auswählt. Dieser wird durch ein WS-CDL Dokument be-schrieben. 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 Darstellungs-komponente und einer Choreographiekomponente. Die Aufgabe der Darstellungskomponente besteht darin, ein Benutzerinterface für die Eingaben und Ausgaben des Web Services zu ge-nerieren. Dazu dienen die WSDL-Beschreibungen und eventuell vorhandene Formatierungs-dokumente wie z.B. GUIDDs der beteiligten Web Services. Um den gesamten Ablauf des Geschäftsprozesses zu steuern, wird die Choreographiekomponente benötigt. Diese interpre-tiert 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 darge-stellt. 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 wer-den 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-



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).

Abbildung 18: Beispiel für den Choreographieansatz

5.1.1.1 Einsatz von Portlets

Gerade der Fall eines parallelen Aufrufs mehrerer Dienste führt zu einer wachsenden Kom-plexität bei der Generierung einer entsprechenden Benutzerschnittstelle. So ist es beispiels-weise 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 Choreogra-phiekomponente erkennen, dass sich die Syntax und Semantik der Eingabeparameter für die Operationen des Hotel- und Flugdienstes überschneiden. Anhand der ontologischen Beschrei-bung 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 Port-lets ü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 Darstel-lungskomponente, da von den beteiligten Diensten bereits fertige Portlets geliefert werden.



Das ist allerdings auch der große Nachteil jener Variante. Die beteiligten Web Services müs-sen 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 ledig-lich möglich, dem Nutzer gleichzeitig zwei Portlets zur Verfügung zu stellen, in denen er je-weils 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.

5.1.1.2 Bewertung

Vorteil des Choreographieansatzes ist, dass für die Benutzerinteraktion keine Autorentätigkei-ten 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 Darstel-lung 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 verwen-det.

Der große Schwachpunkt dieser Idee ist jedoch die Komplexität der Choreographiekompo-nente. 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 sei-nen 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 Choreographiekomponen-te 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 3.3.1. 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 wer-den.

Die Implementierung einer derart umfangreichen Anwendung würde den Rahmen dieser Ar-beit sprengen. Da es sich beim Aufgabenbereich der Choreographiekomponente außerdem praktisch um den gleichen wie bei einer Orchestrierungs-Engine handelt, erscheint es sinnvol-ler, den Einsatz einer bestehenden und frei verfügbaren Orchestrierungs-Engine zu untersu-chen und diese für den Prototyp zu verwenden. Da diese meistens auf der Prozessbeschrei-bungssprache 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 Beschrei-bung des Geschäftsablaufs verwendet wird.



5.1.2 Orchestrationsansatz

Der grundlegende Unterschied des Orchestrationsansatzes zum Choreographieansatz besteht darin, dass die Steuerung und der Ablauf der Geschäftslogik nicht über eine (neu zu entwi-ckelnde) Choreographiekomponente, sondern über eine (bereits existierende) Orchestrie-rungs-Engine erfolgt. Daher wird der Geschäftsprozess auch nicht mehr durch eine Choreo-graphiesprache 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 eben-falls ö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 abs-trakten BPEL-Prozessen wird das Konzept des Behavioral Interface aus dem Kapitel 3.2.2 verwirklicht. Da sich die Syntax abstrakter und ausführbarer BPEL-Prozesse nicht unterschei-det, 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.

5.1.2.1 Statischer Geschäftsablauf

Für einen statischen Geschäftsablauf reicht es aus, lediglich die Sequenz der Operationsaufru-fe zu definieren. In der BPEL Syntax geschieht dies durch das sequence-Element. Alle wei-teren strukturieren Aktivitäten (flow, scope, ...) sind in diesem Kontext nicht sinnvoll, da sich um die eigentlich Komposition der Dienste die Orchestrierungs-Engine kümmert. Abge-sehen davon wäre beispielsweise ein paralleler Aufruf von verschiedenen Operationen dessel-ben Web Service (der, der durch die Orchestrierungs-Engine repräsentiert wird) nicht sinn-voll.

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 notwendi-gen Informationen enthalten, die für den Aufruf durch einen Nutzer notwendig sind. Während die WSDL-Beschreibung die Datentypen und Bindungsinformationen des angebotenen kom-plexen Web Service zur Verfügung stellt, definiert der abstrakte BPEL-Prozess die auszufüh-rende Operationsreihenfolge und deren portTypes. Die Definition von partnerLinks ist eigentlich nicht notwendig, da es im Gegensatz zum ausführbaren BPEL-Prozess, der norma-lerweise 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.



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"/>


operation="bookTravel"/>



</sequence>

</process>

Quellcode 14: Beispiel für die Beschreibung eines statischen Geschäftsablaufs mit BPEL

5.1.2.2 Dynamischer Geschäftsablauf

Neben einem statischen Ablauf der Operationsaufrufe kann die Reihenfolge jedoch auch dy-namischer 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 ge-nommen 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 mit-tels 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.



<process abstractProcess="yes">

...

<variables>

<variable name="travelVar" element="getTravelResponse"/>

</variables>

<sequence>


operation="getTravel" />


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>





</sequence>

</process>

Quellcode 15: Beispiel für die Beschreibung eines dynamischen Geschäftsablaufs mit BPEL

5.1.2.3 Idee der Ablaufsteuerungskomponente

Das Beispiel des dynamischen Geschäftsablaufs zeigt, dass diese erweiterten Kontrollfunktio-nalitäten die Komplexität des BPEL-Codes stark erhöhen. Es wird daher eine Ablaufsteue-rungskomponente eingeführt, die neben der Kontrolle des Ablaufs der Operationsaufrufe zu-sä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 modifizier-ten 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 Sprach-konstrukte aufgelistet werden:

• partnerLinks, partnerLink: Diese beiden Elemente sind optional und werden nur dann benötigt, wenn die abstrakte Prozessbeschreibung zusätzlich noch von ande-ren 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.



• 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 Kommuni-kation 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 Nutzerinterak-tion 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 ele-mentare und/oder strukturierte Aktivitäten.

• switch, while: Durch diese beiden Konstrukte kann der Ablauf der Operationsauf-rufe 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 ausgewer-tet.

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 Or-chestrationssprache kann durch eine automatisch durchgeführte Transformation (z.B. durch XSLT) eine ausführbare in eine abstrakte Prozessbeschreibung überführt werden. Dies er-leichtert 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 Ablaufsteuerungskompo-nente 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 Ablaufsteuerungskompo-nente gehört das Parsen und Interpretieren dieser abstrakten Prozessbeschreibung und die Verwaltung der eingehenden und abgehenden SOAP-Nachrichten. Anhand der so gewonne-nen 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



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 5.1.1 diskutierte Choreographieansatz. Dort wird nur das WS-CDL-Dokument benötigt, um die Benutzerinteraktion mit einem komplexen Web Service zu realisieren. Beim Orchestrie-rungsansatz 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 Auf-grund der klaren Vorteile von BPEL gegenüber WS-CDL (siehe Kapitel 4.1.4) und der in Kapitel 5.1.1.2 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 4.2.1 und 4.2.3.2.). Somit erfolgt die nutzerfreundliche und plattformunabhängige Benutzerschnittstellenbe-schreibung 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 Benutzerschnitt-stelle anbieten möchte. Um den Autorenprozess zu vereinfachen, wäre eine mögliche Verbes-serung 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 zu-sä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 Diens-tes die passenden GUIDDs der beteiligten elementaren Dienste interpretiert und deren Inhalte entsprechend aggregiert werden müssen, um die Benutzeroberfläche zu generieren. Ein weite-res auftretendes Problem ist, wenn das von der Orchestrierungs-Engine zurückgelieferte Er-gebnis 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 Or-chestrierungs-Engine auf die Anfrage von GUI4CWS mit einer Fehlermeldung antwortet. In diesem Fall existiert keine Beschreibung, wie diese Fehlermeldung grafisch dargestellt wer-den 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 Einga-bemaske 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



der davor ausgeführten Operation ist. Die Umsetzung dieser beiden Varianten wird in den folgenden beiden Unterkapiteln erläutert.

5.2.1 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 Benutzerinterakti-onen 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 Benutzerein-gaben 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 Be-nutzerschnittstellenbeschreibung 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 beste-hen 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 Datenin-stanz, 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-



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 Nachfolgen-den beeinflussen, muss das bisherige Vorgehen zur Generierung der Benutzeroberfläche er-weitert werden. Dies wird im folgenden Kapitel vorgestellt.

5.2.2 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 aus-gewählt werden. Für die Buchungsoperation muss es möglich sein, einen der zurückgeliefer-ten 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 Eingabe-masken 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 Benutzer-interaktionen, mit mehr als einem Operationsaufruf) identifiziert, bei der die Ergebnisse der vorhergehenden Operation Einfluss auf die Eingabemaske der nachfolgenden Operation besit-zen, 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 Operationsaufru-fe 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.

5.2.2.1 Vorlagewerte

Es kann notwendig sein, dass Formularfelder zum Aufruf einer Operation durch Rückgabe-werte 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-



ändert und an die zweite Operation, welche die Änderung vornimmt, abgeschickt werden kön-nen.

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 5.2.1 erklärt, automatisch aus den XML-Schema-Datentypen der WSDL generiert, allerdings normalerweise ohne vordefinierte Werte. Die vordefinierten Wer-te 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 Beschrei-bung 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 Da-tenmodell aufgrund des XML-Schemas generiert, welches für den folgenden Operationsaufruf benötigt wird. Da der Datentyp des Eingabeparameters identisch ist mit dem Ausgabeparame-ter 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.

Abbildung 21: Darstellung von Vorlagewerten

5.2.2.2 Auswahlwerte

Im zweiten Szenario werden die Ausgabeparameter einer Operation zwingend als Eingabepa-rameter der nachfolgenden Operation benötigt. Notwendig wird dies, wenn, wie im Beispiel in Kapitel 5.2.2 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ög-licht.



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 trans-formiert werden. Die Nachteile dieses Ansatzes wurden bereits im vorhergehenden Kapitel diskutiert.

Deshalb wird die Syntax von WSGUI um einen Platzhalter namens <items> erweitert. Die-ser wird in der GUIDD verwendet und markiert die Stelle, an der auf Grundlage einer emp-fangenen 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 Ab-laufdefinition 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 ausge-wä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 Listenele-mente entsprechend eingefügt, wie der Quellcode 17 zeigt.

<select1 ref="bookFlight">

<label>Verfügbare Flüge:</label>

<item>

<label>Frankfurt – Rom 22.09.2006 – 29.09.2006</label>

<value>10089</value>

</item>

<item>

<label>Frankfurt – Rom 21.10.2006 – 28.10.2006</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 defi-niert 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 dy-namische 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



zwei Elemente besitzen. Bei XML-Instanzen mit einem Element werden den Elementen la-bel und value eines Listeneintrags die gleichen Werte zugewiesen.

5.2.3 Fehlermeldungen

Bei der Kommunikation mit dem komponierten Dienst können zwei unterschiedliche Fehler-situationen 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 Diens-te 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ück-geschickt Nachricht beschreibt. Der Autor kann die Darstellung dieser Fehlernachricht in der GUIDD mittels eines form control (über das Element output) bestimmen, da die Fehlernach-richt als Instanz innerhalb des model vorliegt.

5.3 Architektur

Die Abbildung 22 gibt einen Überblick über die in dieser Arbeit entwickelte Gesamtarchitek-tur 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 Benutzerschnitt-stelle ist.

Während die Orchestrierungs-Engine auf einen externen Server ausgelagert werden kann, sind die Interaktions-, Ablaufsteuerungs- und Darstellungskomponente Bestandteil der GUI4CWS-Anwendung.



Abbildung 22: Gesamtarchitektur

Im Folgenden sollen die vier Bestandteile der Architektur und deren Zusammenspiel mitein-ander ausführlicher vorgestellt werden.

5.3.1 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 unab-hä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 Zusammen-spiel mit GUI4CWS zu ermöglichen:

• Das ist zum einen die WSDL-Beschreibung, die der komplexe Dienst wie jeder ele-mentare 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 Be-nutzerschnittstelle verwendet.

• Beim zweiten Dokument handelt es sich um die Beschreibung des abstrakten BPEL-

Prozesses. Darin wird die Abfolge der Operationsaufrufe, gegebenenfalls in Abhän-gigkeit der gesendeten oder empfangenen SOAP-Nachrichten, definiert. Dieses Do-kument 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 Opera-tionen des komplexen Dienstes unterstützt wird. Im Gegensatz zu den beiden vorheri-gen Dokumenten ist die GUIDD jedoch optional, da notfalls auf eine nutzerfreundli-che 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.



Abbildung 23: Von GUI4CWS verwendete Dokumente

5.3.2 Interaktionskomponente

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 Kommunikations-endpunkt (bzw. Kommunikationsendpunkte) des Dienstes und das verwendete Transportpro-tokoll 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 unterschiedli-chen 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.

5.3.3 Ablaufsteuerungskomponente

Die Ablaufsteuerungskomponente kümmert sich um die korrekte Abfolge der Operationsauf-rufe. 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 re-ceive-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 wer-den 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



Ablauf in while- oder switch-Konstrukten ausgewertet werden und so den weiteren Ablauf der Operationsaufrufe beeinflussen.

5.3.4 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 In-formation kann durch die vorliegende WSDL-Beschreibung und GUIDD ein entsprechendes Formular generiert werden. Im Wesentlichen wird hier das WSGUI-Konzept (Kapitel 4.2.3.2) übernommen, das für die Benutzereingaben den XForms-Standard verwendet.

Die vom komplexen Web Service zurückgelieferten Daten werden von der Interaktionskom-ponente 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 zwi-schen drei Zuständen unterschieden werden: dem Anfangszustand, Zwischenzustand und Endzustand. Die Unterscheidung ist deshalb wichtig, weil jeweils eine andere Zusammenstel-lung der form controls erfolgt. Im Anfangszustand existieren noch keine vom Dienst empfan-genen Ergebnisse, so dass keine output-Elemente verwendet werden. Im Zwischenzustand müssen dagegen sowohl form controls zur Eingabe als auch zur Ausgabe von Daten verwen-det 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 Da-ten dargestellt, da laut der Prozessbeschreibung keine weiteren Operationen folgen. Die In-formation, 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än-gig von der generierten Benutzeroberfläche. Wird ein Prozess abgebrochen, so wird dem Nut-zer 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.

5.3.5 Beispielhafter Programmablauf

Der folgende beispielhafte Ablauf soll das Zusammenspiel der Komponenten von GUI4CWS verdeutlichen. Als Grundlage soll dabei die im Quellcode 15 dargestellte abstrakten Prozess-beschreibung 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 gespei-chert, auf die alle drei Komponenten von GUI4CWS Zugriff haben.



3. Die Interaktionskomponente ruft bei der Ablaufsteuerungskomponente den aktuellen Prozessstand ab. Diese liefert die als erstes auszuführende Aktivität, nämlich ein re-ceive mit der Operation „getTravel“.

4. Die Aktivitätsdaten werden an die Darstellungskomponente weitergeleitet, anhand de-rer 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 ausge-lesen 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 Ab-laufsteuerungskomponente 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 ver-wendet 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 Be-schreibung 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 Diens-te 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 Ablaufsteue-rung 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-



reiche BPEL-Autorenwerkzeuge verwenden werden, solange die in Kapitel 5.1.2.3 vorgestell-te 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 erstell-ten Konzeptes zur Erreichung von Benutzerinteraktionen in komplexen Web Service zusam-mengefasst 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 (op-tionale) 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 ge-nerieren. Anhand der abstrakten BPEL-Prozessbeschreibung bestimmt GUI4CWS ferner, ob und in welcher Reihenfolge die den angebotenen Operationen zugeordneten Formulare ange-zeigt 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 bestim-men, 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äftslo-gik 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 Beschrei-bung dieses Verhaltens erfolgt durch eine abstrakte BPEL-Prozessbeschreibung. Da-durch 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 Soft-waretechnologie 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ährleis-ten. Zudem werden die ausgetauschten Daten als XML repräsentiert, so dass zum ei-nen eine clientseitige Validierung der eingegebenen Daten vorgenommen werden kann, zum anderen die Einbindung der ausgetauschten Daten in SOAP-Nachrichten leicht möglich ist.



• 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 Steue-rung von Geschäftsprozessen beschränkt.



Menschliche Interaktionen in komplexen Web Services 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 simulie-ren. 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

6.1.1 Implementierung elementarer Web Services

Um eine SOA-Umgebung aufzubauen, müssen zunächst elementare Web Services implemen-tiert werden. Im Szenario der Reisebuchung handelt es sich dabei um den Dienst einer Flug-gesellschaft 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 5.5.17 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 festge-legt, 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 Trans-formation von XML in Java-Objekte und umgekehrt. Werden komplexere Datentypen ver-wendet, 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 da-bei der Java-Bean-Spezifikation entsprechen, die u.a. besagt, dass der Zugriff auf die Attribu-te 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.



6.1.2 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, wel-ches 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 Ja-va) 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 Werk-zeuges 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 De-signer ausgereifter. Hinzu kommt, dass der ActiveBPEL Designer nur 30 Tage kosten-los getestet werden kann, da es sich um ein kommerzielles Produkt handelt.

Alle drei vorgestellten BPEL-Designer haben gemeinsam, dass der Quellcode nicht offen ge-legt 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. Aller-dings 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 Vorgehenswei-se 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 par-sen. 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 Ho-telinformationen 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 ent-hä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 Hotel-agenten, benötigt. Der Oracle BPEL Designer fügt in die WSDL-Beschreibung automatisch



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 Nutzer-anfrage 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 ei-ner 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 vereinfa-chende Übersicht über die BPEL-Prozessbeschreibung. Der ausführlichere BPEL-Code befin-det 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 be-nutzt werden, einen Nutzer eindeutig zu identifizieren. Eine solche Maßnahme ist gerade bei



kritischen Operationen wie der Buchung einer Reise notwendig. Um ein CorrelationSet zu definieren, müssen der Datentyp und der Bestandteil der empfangen Nachricht, durch wel-cher 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 bei-den Operationen getTravel und bookTravel), müssen zwei propertyAlias angegeben wer-den. Der folgende Quellcode zeigt die Definition der beiden Elemente property und pro-pertyAlias für das Reisebuchungsszenario.

<property name="userId" type="xsd:int"/>

<propertyAlias propertyName="userId" messageType="getTravelRequest"

part="parameters" query="/getTravel/userId"/>

Quellcode 19: Definition von property und propertyAlias

6.1.3 BPEL Ausführung

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 Apa-

che 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 generi-schen Clients benötigen für die Kommunikation jedoch den SOAP-Kommunikationsstil do-cument. Die Gründe hierfür werden im Kapitel 6.2.3 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 akti-ven Prozesse grafisch in allen Details dargestellt wird, was gerade für Entwicklung und Feh-lersuche 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 deploy-ment 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 ver-wendeten WSDL-Beschreibungen an. Bei Verwendung des (kommerziellen) ActiveBPEL



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 Unter-schied dazu ist beispielsweise für das Ansprechen eines elementaren Axis Web Service die Angabe eines Namensraumes nicht zwingend. Ferner sind noch zwei Konfigurationseinstel-lungen, 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 entsprechen-den XML-Schema validiert. Diese Einstellung kann sich auf den Prozessablauf auswirken, wenn z.B. faultHandler definiert werden, die bei einer ungültigen Ein- oder Ausgangs-nachricht 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 kom-plexem 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 Ver-zeichnis zur Verfügung stellt, in der Daten zum Auffinden eines komplexen Dienstes enthal-ten sind. Ein vollständiges UML-Klassendiagramm zu GUI4CWS befindet sich im Anhang.

6.2.1 Ablaufsteuerung

Im Package behavioralinterface sind die Klassen zusammengefasst, die sich um die Ab-laufsteuerung kümmern. Das ist vor allem die Klasse AbstractBPELProcess, deren Hauptauf-gaben das Parsen der abstrakten BPEL-Prozessbeschreibung und das bestimmen der Reihen-folge 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 exis-tierende 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.



Um den aktuellen Prozesstand zu ermitteln, wurde die Methode AbstractBPELPro-cess.getNextActivity() implementiert. Beim Aufruf dieser Methode wird über die Objektreprä-sentation der BPEL-Prozessbeschreibung iteriert und die aktuell abzuarbeitende Aktivität er-mittelt. Bei den zurückgelieferten Aktivitäten handelt es sich entweder um eine receive- oder eine reply-Aktivität. Wurde eine dieser Aktivitäten zurückgeliefert, so muss diese ent-sprechend gekennzeichnet werden, damit beim nächsten Durchlaufen der Prozessrepräsentati-on erkannt wird, dass diese Aktivität bereits abgearbeitet wurde und zur darauf folgenden gesprungen wird. Hierfür wird das Attribut getJoinCondition verwendet, welches alle Aktivi-tä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 Ak-tivitäten können mehrmals ausgeführt werden, nämlich solange, wie die Bedingung der whi-le-Aktivität erfüllt ist. Um dies zu gewährleisten, werden nach der Abarbeitung aller Aktivi-tä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 Pro-

zessbeschreibung, 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 wich-tig, 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 5.1.2.2). Hierzu wurde die Methode AbstractBPELProc-ess.initializeVariable(Activity activity, Node node) implementiert. Sie initialisiert eine Variab-le 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 Bedin-gung für die Ausführung der enthaltenen Aktivitäten XPath-Ausdrücke auf in der Prozessbe-schreibung definierte Variablen angewendet werden. Neben Standard XPath-Funktionen bie-tet BPEL zusätzliche XPath-Funktionserweiterungen, mit denen auf prozessspezifische In-formationen zugegriffen werden kann. Die wichtigste, und am meisten genutzte dieser Erwei-terungen, 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.



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 vorgenom-men 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 mehre-re 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 ver-deutlichen. Im Quellcode 20 ist der Inhalt eines SOAP-Bodys dargestellt, welcher beim Auf-ruf der Operation getTravel zurückgeliefert wurde und der Variable travelResponse zugeord-net 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 5.1.2.3 definierten BPEL-Konstrukte übernommen werden.

6.2.2 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:



• 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 abge-schickt, 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 geach-tet werden, in den entsprechenden output-Elementen das Attribut model auf den Wert „re-turn“ 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ück-meldung. 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.

6.2.3 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 ei-ne 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 Nutzerein-gaben 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, axis-ant, commons-logging, commons-discovery, jaxrpc, log4j, mail, saaj und wsdl4j ein-gebunden 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 Kodierungs-stil rpc dient dazu, XML-Nachrichten auf (Java-)Objekte abzubilden, was für



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 über-nommen werden, hat dies den Vorteil, dass bei der Referenzierung in den output-Elementen der GUIDD die Namensräume nicht berücksichtig werden müssen, wo-durch 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 ge-speichert, 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 vorberei-tet, indem die empfangenen SOAP-Daten in die von der XFormsAdapter Klasse zu-rück gelieferten XForms eingebunden werden. Im unterschied zum Konzept in Kapitel 5.2.2.2 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 zu-nä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 ei-nem Reisedienst erfolgt durch die BPEL-Engine ActiveBPEL. Damit der Client den komple-xen 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



ist im Quellcode 22 verkürzt abgebildet. Die zughörigen WSDL-Beschreibungen, der abstrak-te 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"/>


<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 zu-gewiesen Prozessinstanz eindeutig identifiziert werden kann, an. Die Abbildung 25 zeigt ei-nen Screenshot dieses Formulars.

Abbildung 25: Reiseangebote suchen (Screenshot)

Neben einer Schaltfläche zum Abschicken der Nutzerdaten bzw. Aufrufen der nächsten Ope-ration enthält jede Formularseite zwei weitere Schaltflächen, durch deren Betätigung entwe-der 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. An-schließ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 an-gefragt 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



Hilfe der Klassen DynvokerCore und XFormsAdapter, wobei sich die DynvokerCore Klasse vor allem um die Einbindung der empfangenen Daten kümmert. Beide Klassen benötigen zur Generierung eine WSDL-Operation, um anhand der für den Aufruf derselben benötigten Da-tentypen die passenden Formularfelder zu generieren. Den Operationsnamen liefert die aktu-elle Aktivität. Das so erstelle XForms wird über das Servlet wieder an den Client zurückgelie-fert.

Abbildung 26: Sequenzdiagramm für einen Operationsaufruf mit GUI4CWS

Im Szenario der Reisebuchung erhält der Nutzer das Formular, welches in der Abbildung 27 dargestellt ist. Er kann anhand zweier Listen eine Reise bestehend aus einem Flug und einem Hotel buchen. Die Listenelemente wurden der empfangen SOAP-Nachricht entnommen und in XForms item-Elemente transformiert. Für die korrekte Darstellung ist es allerdings not-wendig, dass der Autor in der GUIDD die entsprechenden select1-Elemente einfügt. Au-ßerdem ist wiederum die Nutzer-ID notwendig. Da diese jedoch bereits im Rückgabewert der aufgerufenen Operation (getTravel) enthalten ist, wird sie von GUI4CWS automatisch ins passende Formularfeld eingefügt (zum Konzept der Vorlagewerte siehe Kapitel 5.2.2.1).

Abbildung 27: Reise buchen (Screenshot)

Die Abbildung 28 zeigt einen Screenshot der Formularseite für die letzte Aktivität des Ge-schäftsprozesses, die nach dem Buchen einer Reise angezeigt wird. Da der Prozess der Reise-buchung keine weiteren abzuarbeitenden Operationen besitzt, verschwindet auch die Schalt-fläche zum Erreichen des nächsten Prozessschrittes. Das Formular enthält das Ergebnis der Reisebuchung, welches durch entsprechende output-Elemente innerhalb der GUIDD ange-zeigt wird, die jeweils ein Element des komplexen Rückgabewertes referenzieren.



Abbildung 28: Ergebnis der Reisebuchung (Screenshot)

6.4 Mögliche Verbesserungen des Prototyps

Das Szenario der Reisebuchung hat gezeigt, dass mit GUI4CWS menschliche Benutzerinter-aktionen mit komplexen Web Services auf generische Art möglich sind. Da in dieser Arbeit allerdings nur eine prototypische Umsetzung erfolgen konnte, soll hier auf mögliche Verbes-serungsvorschläge eingegangen werden.

Zum einen ist die Verwendung des Prototyps dadurch eingeschränkt, dass nur der SOAP-Kodierungsstil document unterstützt wird. GUI4CWS könnte dahingehend erweitert werden, dass auch rpc kodierte Nachrichten geparst und erstellt werden. Allerdings scheint sich der Kodierungsstil document immer mehr durchzusetzen, so dass der SOAP-Stil rpc in einiger Zeit vielleicht gar nicht mehr verwendet wird.

Ein anderes Defizit ist die implementierte Variablenauswertung in den while- und switch-Aktivitäten. Wünschenswert wäre hier der volle im BPEL-Standard beschriebene Funktions-umfang. Auch die Rolle der partnerLinks in der abstrakten Prozessbeschreibung wurde im Prototyp vernachlässigt. Durch entsprechende Erweiterungen wäre es dann möglich, dass GUI4CWS innerhalb eines Prozesses verschiedene Dienste aufruft, und so eine eingeschränk-te Komposition der Dienste (bei Verwendung der in Kapitel 5.1.2.3 festgelegten Syntax) ohne eine Orchestrierungs-Engine möglich ist.

Zahlreiche weitere Vorschläge ergeben sich bei der Evaluierung der Darstellungskomponente. Eine Verbesserung wäre die Erweiterung der generierten Benutzeroberfläche um die Mög-lichkeit, Listen einzugeben. Bisher unterstützt GUI4CWS Listen lediglich als Ausgabewerte von Operationen. Wird jedoch eine Liste als Eingabeparameter eine Operation benötigt, so kann dafür kein Formular generiert werden. Werden Listen als Auswahlwerte für die nächste Operation verwendet (siehe Kapitel 5.2.2.2), besteht der Nachteil, dass der Datentyp der Lis-tenelemente stark eingeschränkt ist. So darf ein Listenelement maximal zwei einfache Daten-typen beinhalten (Beschriftung und Wert des Listenelements). Hier wäre es wünschenswert, beliebige komplexe Datentypen als Listenelemente zuzulassen, wobei in der GUIDD definiert wird, welche Teile des Datentyps dargestellt werden. Um diese Funktionalitäten zukünftig zu realisieren, müsste allerdings auch die GUIDD-Spezifikation angepasst werden, wobei hier auch ein Augenmerk auf Usability-Gesichtspunkte gelegt werden sollte.



Der in dieser Arbeit implementierte Prototyp verwendet XForms für die Darstellung der Be-nutzeroberfläche. Allerdings können XForms nicht von allen Browsern bzw. Endgeräten in-terpretiert werden. Hierfür können zusätzliche Adapter implementiert werden, welche die entsprechende Oberflächenbeschreibungssprache generieren. Möglich wäre somit auch die automatische Auswahl einer passenden Oberflächenbeschreibungssprache zur Laufzeit.



Menschliche Interaktionen in komplexen Web Services Zusammenfassung und Ausblick


7 Zusammenfassung und Ausblick In dieser Arbeit wurde untersucht, wie menschliche Benutzerinteraktionen mit komplexen Web Services realisiert werden können. Die Motivation war dabei, dass die Web-Service-Technologie zunehmend für B2C-Beziehungen eingesetzt wird, bisherige Ansätze jedoch meist nur auf den B2B-Bereich zielen.

Zunächst wurden dafür die für Web Services relevanten Technologien und Ansätze zur Kom-position von Diensten untersucht. Dabei wurden zwei unterschiedliche Szenarien identifiziert, wie Nutzerinteraktionen in komplexe Web Services realisiert werden können: Task-orientierte und Ziel-orientierte Nutzerinteraktionen. Es stellte sich heraus, dass für die Task-orientierte Nutzerinteraktion bereits zahlreiche Lösungen zur Verfügung stehen, so dass in dieser Arbeit der Schwerpunkt auf die Realisierung einer Ziel-orientierten Nutzerinteraktion gelegt wurde. Um komplexe Dienste beschreiben zu können, existieren zahlreiche Kompositionssprachen. Nach der Analyse und dem Vergleich der bekanntesten Vertreter, stellte sich BPEL als am erfolgsversprechendsten heraus.

Damit nicht für jeden einzelnen Web Service eine neue grafische Oberfläche zum Zweck der Nutzerinteraktion implementiert werden muss, ist es wünschenswert, die Benutzerschnittstel-len generisch anhand der WSDL zu erstellen. Mit WSGUI wird eine solche Vorgehensweise unterstützt, indem mit einem zusätzlichen Dokument, der GUIDD, eine nutzerfreundliche Beschriftung der Formularelemente mit Hilfe des XForms-Standards erreicht wird.

Um eine Ziel-orientierte Nutzerinteraktion in komplexen Web Services zu erreichen, wurde in dieser Arbeit ein Konzept namens GUI4CWS entwickelt. Darin wurde festgelegt, dass die eigentliche Komposition der Dienste in einer Orchestrierungs-Engine erfolgt, die das öffentli-che Verhalten des Dienstes mit Hilfe eines abstrakten BPEL-Prozesses beschreibt. Zusammen mit der WSDL und einer optionalen GUIDD kann die GUI4CWS-Anwendung eine Schnitt-stelle zur Verfügung stellen, über die der Nutzer mit dem komplexen Dienst interagieren kann. Dabei besteht die GUI4CWS-Anwendung aus einer Ablaufsteuerungs-, einer Interakti-ons- und einer Darstellungskomponente, die sich um die Operationsreihenfolge, die SOAP-Kommunikation und die Generierung der Benutzeroberfläche in Form von XForms kümmern.

Das entwickelte Konzept wurde in einem Prototyp umgesetzt und anhand eines Reisebu-chungsszenarios erfolgreich getestet. Hierfür wurde eine SOA-Testumgebung mit zwei Web Services aufgebaut, wobei für die SOAP-Kommunikation und die WSDL-Erstellung Apache Axis verwendet wurde. Die Orchestration der Dienste erfolgte durch die Open-Source BPEL-Engine ActiveBPEL.

GUI4CWS ermöglich somit menschliche Interaktionen mit komplexen Web Services, soweit es sich dabei um eine Ziel-orientierte Nutzerinteraktion handelt. Dies eröffnet zahlreiche neue Anwendungsfälle, da somit die als Web Service bereits implementierten Geschäftsprozesse über eine automatisch generierte Benutzerschnittstelle angesprochen werden können. Neben der generischen Benutzeroberflächengenerierung ist der Vorteil der entwickelten Lösung, dass bestehende Technologien verwendet und zur Lösung der Aufgabenstellung miteinander kombiniert wurden. Erfolgt die Orchestration über eine BPEL-Engine, so reicht es im ein-fachsten Fall aus, die BPEL-Prozess- und die WSDL-Beschreibung zu veröffentlichen, um mit Hilfe von GUI4CWS eine Nutzerinteraktion mit dem komplexen Dienst zu ermöglichen. Bei einer entsprechenden Erweiterung des Konzepts besteht auch die Möglichkeit, auf die Orchestrierungs-Engine zu verzichten und den Dienst nur mit Hilfe der abstrakten BPEL-Beschreibung und der Ablaufsteuerungskomponente zu komponieren. Abgesehen davon bie-

Menschliche Interaktionen in komplexen Web Services Zusammenfassung und Ausblick


tet das GUI4CWS-Konzept einen weiteren positiven Nebeneffekt. So war zwar das ursprüng-lich Ziel, eine Anbindung von Nutzerinteraktionen an komplexe Web Services zu erreichen. Durch die Verwendung von abstrakten BPEL-Prozessbeschreibungen ist es jedoch ebenso möglich, eine allgemeine generische Ablaufsteuerung für Web-Anwendungen zur Verfügung zu stellen, womit der Einsatz von GUI4CWS nicht zwangsläufig auf die Web-Service-Technologie beschränkt ist.

Die Zukunft von komplexen Web Services und insbesondere die Integration von Benutzerin-teraktionen in diese wird u.a. davon abhängen, wie weit der Autorenprozess vereinfacht wer-den kann. Gerade der Aufwand, einen BPEL-Prozess zu erstellen und in einer BPEL-Engine zur Ausführung zu bringen, lohnt sich nach den in dieser Arbeit gemachten Erfahrungen nur für größere Projekte. Auch gilt es hierbei zu beachten, dass komplexe Dienste nicht, wie in dieser Arbeit, speziell für B2C-Szenarien entwickelt werden. Für den Anwendungsfall in der realen Welt wird es fast immer so sein, dass anhand eines bestehenden komplexen Dienstes eine Nutzeroberfläche generiert wird und nicht umgekehrt. So wird ein komponierter Dienst für B2B-Beziehungen meist bereits angeboten, während ein Ansprechen dieses Dienstes über eine Benutzerschnittstelle fehlt. Umso wichtiger ist es, geeignete Autorenwerkzeuge für die Generierung der Benutzerschnittstelle zur Verfügung zu stellen. In dem in dieser Arbeit ent-wickelten Konzept und Prototyp bestimmt der Autor über die GUIDD die Darstellung der Interaktionselemente. Dadurch, dass sich die GUIDD-Syntax noch in der Entwicklung befin-det, existiert hierfür noch kein grafisches Autorenwerkzeug, so dass die GUIDD bisher nur mittels Texteditoren erstellt werden kann. Allerdings wird zurzeit in einer Diplomarbeit an der TU Dresden einen GUIDD-Editor entwickelt, der voraussichtlich im Sommer 2006 zur Ver-fügung steht.

Das Szenario der Reisebuchung zeigt, welches Potential die Integration von Benutzerinterak-tionen in komplexe Web Services besitzt. Dass es sich hierbei nicht nur um eine theoretischen Anwendungsfall handelt, wird z.B. am Projekt SATINE [71] deutlich, in der eine offene Um-gebung für die Reisebranche entwickelt wird, um Dienste auf einfache Art zu publizieren, zu finden, anzusprechen und miteinander zu kombinieren. Eine immer größere Bedeutung spie-len dabei semantische Informationen, um welche die Beschreibung von Web Services erwei-tert wird. Dabei geht es zum einen um maschinenlesbare Semantiken, die dazu dienen, Web Services zur Laufzeit zu orchestrieren. Zum anderen geht es aber auch um die semantischen Beschreibungen zum Zweck der menschlichen Interaktion. In dieser Arbeit wurde dies mit Hilfe der GUIDD realisiert. Allerdings handelt es sich dabei um einen statischen Ansatz. Falls Formularelemente jedoch dynamisch anhand der zurückgelieferten Ergebnisse generiert und semantisch beschriftet werden sollen, müssen neue Konzepte eingeführt werden. Nur so las-sen sich in Zukunft nutzerfreundliche Formulare zur Interaktion mit komplexen Web Services dynamisch zur Laufzeit realisieren.

Menschliche Interaktionen in komplexen Web Services Glossar


8 Glossar BPEL Business Process Execution Language

BPM Business Process Management

BPMI Business Process Management Initiative

BPML Business Process Modeling Language

BPMN Business Process Modeling Notation

BPMS Business Process Management System

B2B Business-To-Business

B2C Business-To-Consumer

CORBA Common Object Request Broker Architecture

DCOM Distributed Component Object Model

DOM Document Object Model

DTD Document Type Definition

EAI Enterprise Application Integration

FTP File Transfer Protocol

GUIDD Graphical User Interface Deployment Descriptor

GUI4CWS Graphical User Interface for Complex Web Service

HTTP HyperText Transfer Protocol

OASIS Organization for the Advancement of Structured Information Standards

OMG Object Management Group

OWL Web Ontology Language

RDF Resource Description Framework

RMI Remote Method Invocation

RPC Remote Procedure Call

SMTP Simple Mail Transfer Protocol

SOA Service Oriented Architecture

UDDI Universal Description, Discovery and Integration

Menschliche Interaktionen in komplexen Web Services Glossar


URL Uniform Resource Locator

URI Uniform Resource Identifiers

WfMC Workflow Management Coalition

WfMS Workflow Management System

WML Wireless Markup Language

WS-CDL Web Service Choreography Language

WSCL Web Service Conversation Language

WSCI Web Service Choreography Interface

WSDL Web Service Description Language

WSFL Web Services Flow Language

WSGUI Web Service Graphical User Interface

WSUI Web Service User Interface

W3C World Wide Web Consortium

XML Extensible Markup Language

XPDL XML Process Definition Language

XSLT Extensible Stylesheet Language Transformation

Menschliche Interaktionen in komplexen Web Services Literaturverzeichnis


9 Literaturverzeichnis [1] A. Ryman: Understanding Web Services. In: Artikel von IBM ( 22. Juli 2003). URL:

http://www-128.ibm.com/developerworks/websphere/library/techarticles/0307_ryman/ryman.html (zuletzt besucht am 25.05.2006).

[2] L. Gläßer: IT-Lösungen im E-Business. Siemens, 2003. – ISBN 3-8957-8203-3

[3] W3C Working Group Note - Web Services Architecture. URL: http://www.w3.org/TR/ws-arch/ (zuletzt besucht am 25.05.2006).

[4] D. Kossmann, F. Leymann: Web Services. In: Informatik Spektrum (26. April 2004). Springer.

[5] J. Richter, H. Haller, P. Schrey: Serviceorientierte Architektur. In: Informatik Spektrum (17. Oktober 2005). Springer.

[6] R. Soika: BPEL und SOA Architekturen. In: Artikel auf BPM-Guide.de. URL: http://www.bpm-guide.de/articles/25 (zuletzt besucht am 25.05.2006).

[7] K. Ma (2005): Web Services: What’s Real and What’s Not? In: IT Pro (March/April 2005). IEEE.

[8] U. Hammerschall: Verteilte Systeme und Anwendungen. Pearson Studium, 2005. – ISBN 3-8273-7096-5

[9] W3C Recommendation - Extensible Markup Language (XML) 1.0 (Third Edition). URL: http://www.w3.org/TR/REC-xml/ (zuletzt besucht am 25.05.2006).

[10] G. Alonso, F. Casati, H. Kuno, V. Machiraju: Web Services. Springer, 2004.

[11] W3C Recommendation - SOAP Version 1.2 Part 0: Primer. URL: http://www.w3.org/TR/2003/REC-soap12-part0-20030624/ (zuletzt besucht am 25.05.2006).

[12] W3C Recommendation - SOAP Version 1.2 Part 1: Messaging Framework. URL: http://www.w3.org/TR/soap12-part1/ (zuletzt besucht am 25.05.2006).

[13] S. Apfel: Ein generisches Framework zur grafischen Anbindung von Web-Services. Diplomarbeit an der Universität Kaiserslautern, Fachbereich Informatik (2004). URL: http://www.icsy.de/~archiv/DPArchiv.0136.pdf (zuletzt besucht am 25.05.2006).

[14] M. Richter: Sicherheitsaspekte von Web Services. Diplomarbeit an der TU Dresden, Fachbereich Informatik (2005).

[15] R. Borchers: Analyse und Test verschiedener Ansätze zur automatischen Suche und Auswahl von Web Services. Bachelorarbeit an der TU Dresden, Fachbereich Informatik (2005).

[16] C. Yushi, L. Wah, D. Limbu: Web Services Composition. -An Overview of Standards. In: Synthesis Journal 2004, (Hrsg.): Information Technology Standards Committee. URL: http://www.itsc.org.sg/synthesis/2004/4_WS.pdf (zuletzt besucht am 25.05.2006).



[17] M. Reichert, D. Stoll: Komposition, Choreographie und Orchestrierung von Web Servi-ces – Ein Überblick. In: EMISA Forum (2004), Band 24, Heft 2, S. 21-32. Universität Ulm, Abteilung Datenbanken und Informationssysteme. URL: http://www.primium.org/fileadmin/_primium/downloads/publikationen/KompositionWebServices.pdf (zuletzt besucht am 25.05.2006).

[18] Hauptseite der Workflow Management Coalition. URL: http://www.wfmc.org/ (zuletzt besucht am 25.05.2006).

[19] A. Gadatsch: Grundkurs Geschäftsprozess-Management. Vieweg, 2005. – ISBN 3-5282-5759-8

[20] Hauptseite der Business Process Management Initiative. URL: http://www.bpmi.org/ (zuletzt besucht am 25.05.2006).

[21] E. A. Stohr, J. L. Zhao: Workflow Automation: Overview and Research Issues. In: In-formation Systems Frontiers (2001), Volume 3, Issue 3, S.181-196.

[22] J. Cardoso, R. P. Bostrom, A. Sheth: Workflow Management Systems vs. ERP Systems: Differences, Commonalities, and Applications. LSDIS Lab, Computer Science Depart-ment, University of Georgia. URL: http://www.terry.uga.edu/~ekarah/cardoso.pdf (zu-letzt besucht am 25.05.2006).

[23] Geschäftsprozessmanagement - die Wertschöpfungskette gestalten. In: Artikel der JP-Consulting & Training GmbH (2005). URL: http://www.jp-consulting.de/JP/Managementberatung/Wissenswertes/E1162.htm?b=1 (zuletzt besucht am 25.05.2006).

[24] Hauptseite der XML Process Definition Language. URL: http://www.wfmc.org/standards/XPDL.htm (zuletzt besucht am 25.05.2006).

[25] Hauptseite von OASIS. URL: http://www.oasis-open.org/home/index.php (zuletzt be-sucht am 25.05.2006).

[26] OWL-S 1.0 Release. URL: http://www.daml.org/services/owl-s/1.0/ (zuletzt besucht am 25.05.2006).

[27] C. Peltz: Web Services Orchestration and Choreography. In: Artikel von Hewlett Pa-ckard ( Juli 2003). URL: http://devresource.hp.com/drc/technical_white_papers/WSOrch/WSOrchestration.pdf (zuletzt besucht am 25.05.2006).

[28] A. Barros, M. Dumas, P. Oaks: A Critical Overwiew of the Web Services Choreogra-phy Description Language (WS-CDL). In: Artikel von BPTrends (März 2005). URL: http://www.bptrends.com/publicationfiles/03%2D05%20WP%20WS%2DCDL%20Barros%20et%20al%2Epdf (zuletzt besucht am 25.05.2006).

[29] W3C Note - Web Service Choreography Interface (WSCI) 1.0. URL: http://www.w3.org/TR/wsci/ (zuletzt besucht am 25.05.2006).

[30] J. Mendling, G. Neumann, M. Nüttgens: A Comparison of XML Interchange Formats for Business Process Modelling. In: Proceedings of EMISA 2004 - Information Systems in E-Business and E-Government (2004), S. 185-198. URL: http://wi.wu-



wien.ac.at/home/mendling/publications/04-EMISA.pdf (zuletzt besucht am 25.05.2006).

[31] W3C Candidate Recommendation - Web Services Choreography Description Language Version 1.0. URL: http://www.w3.org/TR/ws-cdl-10/ (zuletzt besucht am 25.05.2006).

[32] M. Bravetti, C. Guidi, R. Lucchi, G. Zavataro: Supporting e-commerce systems formal-ization with choreography languages. In: Proceedings of the 2005 ACM symposium on Applied computing (SAC ’05). ACM.

[33] M. Havey: What is Business Process Modeling. In: Artikel von ONJava.com (20. Juli 2005). O’Reilly. URL: http://www.onjava.com/pub/a/onjava/2005/07/20/businessprocessmodeling.html (zu-letzt besucht am 25.05.2006).

[34] OASIS - Business Process Execution Language for Web Services, Version 1.1. URL: ftp://www6.software.ibm.com/software/developer/library/ws-bpel.pdf (zuletzt besucht am 26.05.2006).

[35] C. Peltz: An overview of web services orchestration standards. In: Artiekl von Hewlett Packard (März 2003). URL: http://devresource.hp.com/drc/resources/WSOrchestration/index.jsp (zuletzt besucht am 26.05.2006).

[36] Sample Web Process and support of different standards to model the process. University of Georgia, Computer Science Department. URL: http://lsdis.cs.uga.edu/proj/meteor/mwscf/collaboration.html (zuletzt besucht am 26.05.2006).

[37] WS-BPEL 2.0 Extensions for Sub-Processes (Oktober 2005). Contributors: IBM, SAP AG. URL: http://www-128.ibm.com/developerworks/webservices/library/specification/ws-bpelsubproc/ (zu-letzt besucht am 26.05.2006).

[38] P. Krill: BPEL 2.0 is delayed. In: Artikel auf Infoworld (29. Oktober 2005). URL: http://www.infoworld.com/article/05/10/28/HNbpel_1.html (zuletzt besucht am 26.05.2006).

[39] W3C Note - Web Services Conversation Language (WSCL) 1.0. URL: http://www.w3.org/TR/wscl10/ (zuletzt besucht am 26.05.2006).

[40] Hauptseite von RosettaNet. URL: http://www.rosettanet.org/Rosettanet/Public/PublicHomePage (zuletzt besucht am 26.05.2006).

[41] S. Masud: Building a Real-World Web Service. In: Artikel auf XMLJournal (31. Januar 2003). URL: http://xml.sys-con.com/read/40559.htm (zuletzt besucht am 26.05.2006).

[42] J. Mendling, M. Hafner: From Inter-Organizational Workflows to Process Execution: Generating BPEL from WS-CDL. In: Proceedings of OTM 2005 Workshops, (Hrsg.): R. Meersman, Z. Tari, P. Herrero et al. URL: http://wi.wu-wien.ac.at/home/mendling/publications/TR05-WSCDL.pdf (zuletzt besucht am 26.05.2006).



[43] J. Dubray, WS-Choreography Definition Language (WS-CDL). In: Artikel auf ebPML.org. URL: http://www.ebpml.org/ws_-_cdl.htm (zuletzt besucht am 26.05.2006).

[44] Projektseite von pi4soa. URL: http://sourceforge.net/projects/pi4soa/ (zuletzt besucht am 26.05.2006).

[45] Projektseite von WS-CDL Eclipse. URL: http://wscdl-eclipse.sourceforge.net/download.htm (zuletzt besucht am 26.05.2006).

[46] W3C Recommendation - XForms 1.0 (Second Edition). URL: http://www.w3.org/TR/xforms/ (zuletzt besucht am 26.05.2006).

[47] Projektseite Mozilla XForms. URL: http://www.mozilla.org/projects/xforms/ (zuletzt besucht am 26.05.2006).

[48] Projektseite SOAPClient. URL: http://www.soapclient.com/soaptest.html (zuletzt be-sucht am 26.05.2006).

[49] R. Steele, K. Khankan, T. Dillon: Mobile Web Services Discovery and Invocation Through Auto-Generation of Abstract Multimodal Interface. In: Proceedings of the In-ternational Conference on Information Technology: Coding and Computing (ITCC'05) - Volume II - Volume 02, S. 35-41. IEEE.

[50] Projektseite von eNode. URL: http://www.enode.com/x/webservices/index.html (zuletzt besucht am 26.05.2006).

[51] M. Kassoff, D. Kato, W. Mohsin: Creating GUIs for Web Services. Stanford University (2003). URL: http://logic.stanford.edu/~mkassoff/papers/wsgui.pdf (zuletzt besucht am 26.05.2006).

[52] Spezifikation des GUIDD Formats. URL: http://web.inf.tu-dresden.de/~js177634/webservices/guidd.html (zuletzt besucht am 26.05.2006).

[53] Projektseite von WSGUI. URL: http://wsgui.berlios.de/ (zuletzt besucht am 26.05.2006).

[54] R. Cover: Web Services User Interface (WSUI) Initiative. In: Artikel von Cover Pages (29. Oktober 2002). URL: http://www.oasis-open.org/cover/wsui.html (zuletzt besucht am 26.05.2006).

[55] OASIS Committee Draft - Web Services for Remote Portlets 1.0 Primer. URL: http://www.oasis-open.org/committees/download.php/10539/wsrp-primer-1.0.html (zu-letzt besucht am 26.05.2006).

[56] M. Kloppmann, D. Koenig, F. Leymann et al.: WS-BPEL Extension for People – BPEL4PEOPLE. IBM, SAP (2005). URL: ftp://www6.software.ibm.com/software/developer/library/ws-bpel4people.pdf (zuletzt besucht am 26.05.2006).

[57] D. Chakraborty, H. Lei: Extending the Reach of Business Processes. In: Upkar Varsh-ney, Department of CIS, Georgia State University (April 2004), (Hrsg.): IEEE Com-



puter. URL: http://ebiquity.umbc.edu/_file_directory_/papers/87.pdf (zuletzt besucht am 26.05.2006).

[58] J. Wang: Automate human workflow with the WebSphere Application Server Busi-nessProcessService API. In: Artikel von IBM (12. Dezember 2003). URL: http://www-128.ibm.com/developerworks/library/i-supply1f/?ca=dnt-450 (zuletzt besucht am 26.05.2006).

[59] M. McMahon: Develop business processes with WebSphere Process Choreographer, Part 2. In: Artikel von IBM (22. Oktober 2004). URL: http://www-128.ibm.com/developerworks/ibm/library/i-mexch6/index.html (zuletzt besucht am 26.05.2006).

[60] Projektseite von Agila. URL: http://wiki.apache.org/agila/ (zuletzt besucht am 26.05.2006).

[61] Hauptseite des Oracle BPEL Process Manager. URL: http://www.oracle.com/technology/products/ias/bpel/index.html (zuletzt besucht am 26.05.2006).

[62] Tutorial 6: Working with the TaskManager Service. Oracle. URL: http://www.oracle.com/technology/products/ias/bpel/pdf/orabpel-Tutorial6-TaskManagerServiceTutorial.pdf (zuletzt besucht am 26.05.2006).

[63] Hauptseite von Apache Axis. URL: http://ws.apache.org/axis/ (zuletzt besucht am 26.05.2006).

[64] Hauptseite von Apache Tomcat. URL: http://tomcat.apache.org/ (zuletzt besucht am 26.05.2006).

[65] Hauptseite von BPWS4J. URL: http://www.alphaworks.ibm.com/tech/bpws4j (zuletzt besucht am 26.05.2006).

[66] Hauptseite des ActiveBPEL Designer. URL: http://www.active-endpoints.com/products/activebpeldes/index.html?blg (zuletzt besucht am 26.05.2006).

[67] O. Hofmann: Analyse und Test verschiedener Ansätze zur Beschreibung und Komposi-tion von komplexen Web Services. Bachelorarbeit an der TU Dresden, Fachbereich In-formatik (2005).

[68] Hauptseite von bexee - BPEL Execution Engine. URL: http://bexee.sourceforge.net/ (zuletzt besucht am 26.05.2006).

[69] Hauptseite von PXE - Process eXecution Engine. URL: http://pxe.fivesight.com/confluence/display/PXE/Home (zuletzt besucht am 26.05.2006).

[70] Hauptseite von ActiveBPEL. URL: http://www.activebpel.org/ (zuletzt besucht am 26.05.2006).

[71] Projektseite von SATINE - Semantic-based Interoperability Infrastructure for Integrat-ing Web Service Platforms to Peer-to-Peer Networks. URL: http://www.srdc.metu.edu.tr/webpage/projects/satine/ (zuletzt besucht am 26.05.2006).



Menschliche Interaktionen in komplexen Web Services Anhang


10 Anhang

10.1 Klassendiagramm von GUI4CWS

Abbildung 29: UML Klassendiagramm von GUI4CWS



10.2 Dokumente für das Reisebuchungsszenario

<?xml version="1.0" encoding="UTF-8"?>

<wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"

xmlns:impl="http://localhost:8080/webservice/services/TravelProcess"

xmlns:tns1="http://travelProcess" xmlns:tns2="http://travelProcess/travel"

targetNamespace="http://localhost:8080/webservice/services/TravelProcess"

...>

<wsdl:types>

<schema elementFormDefault="qualified"

targetNamespace="http://travelProcess"

xmlns="http://www.w3.org/2001/XMLSchema">

<element name="getTravel">

<complexType>

<sequence>

<element name="endLocation" type="xsd:string"/>

<element name="userId" type="xsd:int"/>

</sequence>

</complexType>

</element>

<element name="getTravelResponse">

<complexType>

<sequence>

<element name="getTravelReturn" type="tns1:Travel"/>


</sequence>

</complexType>

</element>

<element name="bookTravel">

<complexType>

<sequence>

<element name="flightId" type="xsd:int"/>

<element name="hotelId" type="xsd:int"/>


</sequence>

</complexType>

</element>

<element name="bookTravelResponse">

<complexType>

<sequence>

<element name="bookTravelReturn" type="tns1:TravelData"/>

</sequence>

</complexType>

</element>

<complexType name="Flight">

<sequence>

<element name="flightId" type="xsd:int"/>

<element name="information" nillable="true" type="xsd:string"/>

</sequence>

</complexType>

<complexType name="ArrayOf_tns3_Flight">

<sequence>

<element maxOccurs="unbounded" minOccurs="0" name="item"

type="tns1:Flight"/>

</sequence>

</complexType>

<complexType name="ArrayOf_tns4_Hotel">

<sequence>

<element maxOccurs="unbounded" minOccurs="0" name="item"

type="tns1:Hotel"/>

</sequence>



</complexType>

<complexType name="Hotel">...</complexType>

<complexType name="Travel">...</complexType>

<complexType name="TravelData">

<sequence>

<element name="startLocation" nillable="true" type="xsd:string"/>

...

</sequence>

</complexType>

</schema>

</wsdl:types>

<wsdl:message name="getTravelRequest">

<wsdl:part name="parameters" element="tns1:getTravel"/>

</wsdl:message>

<wsdl:message name="getTravelResponse">...</wsdl:message>

...

<wsdl:portType name="travelAgent">

<wsdl:operation name="getTravel">

<wsdl:input name="getTravelRequest"

message="impl:getTravelRequest"/>

<wsdl:output name="getTravelResponse"

message="impl:getTravelResponse"/>

</wsdl:operation>

<wsdl:operation name="bookTravel">...</wsdl:operation>

</wsdl:portType>

<wsdl:binding name="TravelProcessSoapBinding" type="impl:travelAgent">

<wsdlsoap:binding style="document"

transport="http://schemas.xmlsoap.org/soap/http"/>

<wsdl:operation name="getTravel">

<wsdlsoap:operation/>

<wsdl:input>

<wsdlsoap:body use="literal"/>

</wsdl:input>

<wsdl:output>...</wsdl:output>

</wsdlsoap:operation>

</wsdl:operation>

...

</wsdl:binding>

<wsdl:service name="travelAgentService">

<wsdl:port name="TravelProcess"

binding="impl:TravelProcessSoapBinding">

<wsdlsoap:address location="..."/>

</wsdl:port>

</wsdl:service>

<plnk:partnerLinkType name="travelAgent_PL">

<plnk:role name="travelAgent_Role">

<plnk:portType name="impl:travelAgent"/>

</plnk:role>

</plnk:partnerLinkType>

<bpws:property name="userId" type="xsd:int"/>

<bpws:propertyAlias propertyName="impl:userId"

messageType="impl:getTravelRequest" part="parameters"

query="/tns1:getTravel/tns1:userId"/>

<bpws:propertyAlias propertyName="impl:userId"

messageType="impl:bookTravelRequest" part="parameters"

query="/tns1:bookTravel/tns1:userId"/>

</wsdl:definitions>

Quellcode 23: TravelProcess.wsdl (Auszug)


<wsdl:definitions xmlns:tns1="http://airline"



xmlns:impl="http://localhost:8080/webservice/services/AirlineService"

...

xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespa-

ce="http://localhost:8080/webservice/services/AirlineService">

<wsdl:types>

<schema elementFormDefault="qualified" targetNamespa

ce="http://airline" xmlns="http://www.w3.org/2001/XMLSchema">

<element name="getFlights">

<complexType>

<sequence>

<element name="endLocation" type="xsd:string"/>

</sequence>

</complexType>

</element>

<element name="getFlightsResponse">

<complexType>

<sequence>

<element maxOccurs="unbounded" name="getFlightsReturn"

type="tns1:FlightData"/>

</sequence>

</complexType>

</element>

<element name="bookFlight">...</element>

<element name="bookFlightResponse">...</element>

<complexType name="FlightData">

<sequence>

<element name="startLocation" nillable="true" type="xsd:string"/>

...

</sequence>

</complexType>

</schema>

</wsdl:types>

<wsdl:message name="getFlightsResponse">

<wsdl:part name="parameters" element="tns1:getFlightsResponse"/>

</wsdl:message>

<wsdl:message name="bookFlightResponse">...</wsdl:message>

<wsdl:message name="bookFlightRequest">...</wsdl:message>

<wsdl:message name="getFlightsRequest">...</wsdl:message>

<wsdl:portType name="Airline">

<wsdl:operation name="getFlights">...</wsdl:operation>

<wsdl:operation name="bookFlight">...</wsdl:operation>

</wsdl:portType>

<wsdl:binding name="AirlineServiceSoapBinding" type="impl:Airline">

...

</wsdl:binding>

<wsdl:service name="AirlineService">

<wsdl:port name="AirlineService"

binding="impl:AirlineServiceSoapBinding">


</wsdl:port>

</wsdl:service>

<plnk:partnerLinkType name="Airline_PL">

<plnk:role name="Airline_Role">

<plnk:portType name="impl:Airline"/>

</plnk:role>


</wsdl:definitions>

Quellcode 24: AirlineService.wsdl (Auszug)


<wsdl:definitions xmlns:tns1="http://hotelagent"



xmlns:impl="http://localhost:8080/webservice/services/HotelService"

...>

<wsdl:types>

<schema elementFormDefault="qualified"

targetNamespace="http://hotelagent" ...>

<element name="getHotels">

<complexType>

<sequence>

<element name="location" type="xsd:string"/>

</sequence>

</complexType>

</element>

<element name="getHotelsResponse">

<complexType>

<sequence>

<element maxOccurs="unbounded" name="getHotelsReturn"

type="tns1:HotelData"/>

</sequence>

</complexType>

</element>

<element name="bookHotel">...</element>

<element name="bookHotelResponse">...</element>

<complexType name="HotelData">

<sequence>

<element name="hotelId" type="xsd:int"/>

...

</sequence>

</complexType>

</schema>

</wsdl:types>

<wsdl:message name="bookHotelResponse">

<wsdl:part name="parameters" element="tns1:bookHotelResponse"/>

</wsdl:message>

<wsdl:message name="bookHotelRequest">...</wsdl:message>

<wsdl:message name="getHotelsRequest">...</wsdl:message>

<wsdl:message name="getHotelsResponse">...</wsdl:message>

<wsdl:portType name="HotelAgent">

<wsdl:operation name="getHotels">...</wsdl:operation>

<wsdl:operation name="bookHotel">...</wsdl:operation>

</wsdl:portType>

<wsdl:binding name="HotelServiceSoapBinding" type="impl:HotelAgent">

...

</wsdl:binding>

<wsdl:service name="HotelAgentService">

<wsdl:port name="HotelService" binding="impl:HotelServiceSoapBinding">


</wsdl:port>

</wsdl:service>

<plnk:partnerLinkType name="HotelAgent_PL">

<plnk:role name="HotelAgent_Role">

<plnk:portType name="impl:HotelAgent"/>

</plnk:role>


</wsdl:definitions>

Quellcode 25: HotelService.wsdl (Auszug)

<process name="travelBPEL" targetName-



space="http://xmlns.oracle.com/travelBPEL"

xmlns="http://schemas.xmlsoap.org/ws/2003/03/business-process/"

xmlns:bpws="http://schemas.xmlsoap.org/ws/2003/03/business-process/"

xmlns:xsd="http://www.w3.org/2001/XMLSchema"

xmlns:client="http://localhost:8080/webservice/services/TravelProcess"

xmlns:ns9="http://localhost:8080/webservice/services/HotelService"

xmlns:ns1="http://localhost:8080/webservice/services/AirlineService"

xmlns:ns3="http://travelProcess" xmlns:ns2="http://airline"

xmlns:ns10="http://hotelagent">

<partnerLinks>

<partnerLink name="client" partnerLinkType="client:travelAgent_PL"

myRole="travelAgent_Role"/>

<partnerLink name="hotelService" partnerRole="HotelAgent_Role"

partnerLinkType="ns9:HotelAgent_PL"/>

<partnerLink name="airlineService" partnerRole="Airline_Role"

partnerLinkType="ns1:Airline_PL"/>

</partnerLinks>

<variables>

<variable name="getTravels" messageType="client:getTravelRequest"/>

<variable name="getTravelResponse"

messageType="client:getTravelResponse"/>

<variable name="bookTravel" messageType="client:bookTravelRequest"/>

<variable name="bookTravelResponse"

messageType="client:bookTravelResponse"/>

<variable name="getFlights"

messageType="ns1:getFlightsRequest"/>

<variable name="getFlightsReturn"

messageType="ns1:getFlightsResponse"/>

<variable name="indexCounter" type="xsd:int"/>

<variable name="indexHotelCounter" type="xsd:int"/>

<variable name="hotelInformationString" type="xsd:string"/>

<variable name="informationString" type="xsd:string"/>

<variable name="endLocation" type="xsd:string"/>

<variable name="startLocation" type="xsd:string"/>

<variable name="company" type="xsd:string"/>

<variable name="price" type="xsd:int"/>

<variable name="getHotelsRequest" messageType="ns9:getHotelsRequest"/>

<variable name="getHotelsResponse"

messageType="ns9:getHotelsResponse"/>

<variable name="location" type="xsd:string"/>

<variable name="name" type="xsd:string"/>

...

</variables>

<correlationSets>

<correlationSet name="CorrelationSet_1" properties="client:userId"/>

</correlationSets>

<sequence>

<receive name="receiveInput" partnerLink="client" port-

Type="client:travelAgent"

operation="getTravel" variable="getTravels" createInstance="yes">

<correlations>

<correlation initiate="yes" set="CorrelationSet_1"/>

</correlations>

</receive>

<scope>

<faultHandlers>

<catchAll>

<assign name="assign_error">

<copy>

<from expression="-1"/>

<to variable="getTravelResponse" part="parameters"



query="..."/>

</copy>

...

</assign>

</catchAll>

</faultHandlers>

<sequence>

<flow>

<sequence>

<assign name="assign_getHotels">

<copy>

<from variable="getTravels" part="parameters"

query="/ns3:getTravel/ns3:endLocation"/>

<to variable="getHotelsRequest" part="parameters"

query="/ns10:getHotels/ns10:location"/>

</copy>

<copy>

<from expression="1"/>

<to variable="indexHotelCounter"/>

</copy>

</assign>

<invoke name="Invoke_hotel" partnerLink="hotelService"

portType="ns9:HotelAgent" operation="getHotels"

inputVariable="getHotelsRequest"

outputVariable="getHotelsResponse"/>

</sequence>

<sequence>

<assign name="assign_getFlights">...</assign>

<invoke name="invoke_airline" partnerLink="airlineService"

portType="ns1:Airline" operation="getFlights"

inputVariable="getFlights"

outputVariable="getFlightsReturn"/>

</sequence>

</flow>

<while condition= "bpws:getVariableData('indexCounter') <=

count((bpws:getVariableData('getFlightsReturn','

parameters','/ns2:getFlightsResponse'))/ns2:getFlightsReturn)">

<assign name="create_flightList">



<copy>

<from variable="getFlightsReturn" part="parameters"

query="/ns2:getFlightsResponse/ns2:getFlightsReturn

[bpws:getVariableData('indexCounter')]/ns2:flightId"/>

<to variable="getTravelResponse" part="parameters"

query="..."/>

</copy>

...

</assign>

</while>


<assign name="create_hotelList">...</assign>

</while>

</scope>

<assign name="assign_correlation">...</assign>

<reply name="replyOutput" partnerLink="client"

portType="client:travelAgent" operation="getTravel"

variable="getTravelResponse"/>

<while condition="bpws:getVariableData

('getTravelResponse','parameters','/ns3:getTravelResponse/

ns3:getTravelReturn/ns3:flights/ns3:item[1]/ns3:flightId') = -1">

<sequence>



<receive name="receiveInput" partnerLink="client"

portType="client:travelAgent" operation="getTravel"

variable="getTravels" createInstance="no">

<correlations>

<correlation initiate="no" set="CorrelationSet_1"/>

</correlations>

</receive>

<scope></scope>

<reply .../>

</sequence>

</while>

<receive name="ReceiveInput2" partnerLink="client"

portType="client:travelAgent" operation="bookTravel"

variable="bookTravel" createInstance="no">

<correlations>

<correlation initiate="no" set="CorrelationSet_1"/>

</correlations>

</receive>

<flow>

<sequence>

<assign name="assign_bookFlight">

<copy>

<from variable="bookTravel" part="parameters"

query="/ns3:bookTravel/ns3:flightId"/>

<to variable="bookFlight" part="parameters"

query="/ns2:bookFlight/ns2:flightId"/>

</copy>

</assign>

<invoke name="bookFlight" partnerLink="airlineService"

portType="ns1:Airline" operation="bookFlight"

inputVariable="bookFlight" outputVariable="bookFlightResponse"/>

</sequence>

<sequence>

<assign name="assign_bookHotels">

<copy>

<from variable="bookTravel" part="parameters"

query="/ns3:bookTravel/ns3:hotelId"/>

<to variable="bookHotel" part="parameters"

query="/ns10:bookHotel/ns10:hotelId"/>

</copy>

</assign>

<invoke name="bookHotel" partnerLink="hotelService"

portType="ns9:HotelAgent" operation="bookHotel"

inputVariable="bookHotel" outputVariable="bookHotelResponse"/>

</sequence>

</flow>

<assign name="create_bookedData">

<copy>

<from variable="bookFlightResponse" part="parameters"

query="..."/>

<to variable="bookTravelResponse" part="parameters" query="..."/>

</copy>

...

</assign>

<reply name="replyOutput2" partnerLink="client"

portType="client:travelAgent" operation="bookTravel"

variable="bookTravelResponse"/>

</sequence>

</process>

Quellcode 26: TravelProcess.bpel (Auszug)




<process abstractProcess="yes"

xmlns="http://schemas.xmlsoap.org/ws/2003/03/business-process/">

<partnerLinks>

<parterLink myRole="travelAgent_Role" name="client"

partnerLinkType="travelAgent_PL"/>

<parterLink name="hotelService" partnerLinkType="HotelAgent_PL"

partnerRole="HotelAgent_Role"/>

<parterLink name="airlineService" partnerLinkType="Airline_PL"

partnerRole="Airline_Role"/>

</partnerLinks>

<variables>

<variable name="getTravels"/>

<variable name="getTravelResponse"/>

<variable name="bookTravel"/>

<variable name="bookTravelResponse"/>

<variable name="getFlights"/>

<variable name="getFlightsReturn"/>

<variable name="indexCounter"/>

<variable name="indexHotelCounter"/>

<variable name="hotelInformationString"/>

<variable name="informationString"/>

<variable name="endLocation"/>

<variable name="startLocation"/>

<variable name="company"/>

<variable name="price"/>

<variable name="getHotelsRequest"/>

<variable name="getHotelsResponse"/>

<variable name="location"/>

<variable name="name"/>

<variable name="hotelPrice"/>

<variable name="bookHotel"/>

<variable name="bookHotelResponse"/>

<variable name="bookFlight"/>

<variable name="bookFlightResponse"/>

</variables>

<sequence>

<receive operation="getTravel" partnerLink="client"

portType="travelAgent" variable="getTravels"/>

<reply operation="getTravel" partnerLink="client"

portType="travelAgent" variable="getTravelResponse"/>

<while condition="bpws:getVariableData('getTravelResponse',

'parameters', '/ns3:getTravelResponse/ns3:getTravelReturn/ns3:flights/

ns3:item[1]/ns3:flightId') = -1">

<sequence>

<receive operation="getTravel" partnerLink="client"

portType="travelAgent" variable="getTravels"/>

<reply operation="getTravel" partnerLink="client"

portType="travelAgent" variable="getTravelResponse"/>

</sequence>

</while>

<receive operation="bookTravel" partnerLink="client"

portType="travelAgent" variable="bookTravel"/>

<reply operation="bookTravel" partnerLink="client"

portType="travelAgent" variable="bookTravelResponse"/>

</sequence>

</process>

Quellcode 27: abstractTravelProcess.bpel




<wsdlCatalog>

<wsdlEntry location="wsdl/TravelProcess.wsdl"

classpath="wsdl/TravelProcess.wsdl" />

<wsdlEntry location="wsdl/AirlineService.wsdl"

classpath="wsdl/AirlineService.wsdl" />

<wsdlEntry location="wsdl/HotelService.wsdl"

classpath="wsdl/HotelService.wsdl" />

</wsdlCatalog>

Quellcode 28: wsdlCatalog.xml


<process location="bpel/TravelProcess.bpel"

name="bpelns:travelBPEL"

xmlns="http://schemas.active-endpoints.com/pdd/2004/09/pdd.xsd"

xmlns:bpelns="http://xmlns.oracle.com/travelBPEL"

xmlns:wsa="http://schemas.xmlsoap.org/ws/2003/03/addressing">

<partnerLinks>

<partnerLink name="client">

<myRole allowedRoles="" binding="MSG" service="TravelBPEL"/>

</partnerLink>

<partnerLink name="airlineService">

<partnerRole endpointReference="static">

<wsa:EndpointReference

xmlns:s="http://localhost:8080/webservice/services/AirlineService">

<wsa:Address>

s:http://localhost:8080/webservice/services/AirlineService

</wsa:Address>

<wsa:ServiceName

PortName="AirlineService">s:AirlineService</wsa:ServiceName>

</wsa:EndpointReference>

</partnerRole>

</partnerLink>

<partnerLink name="hotelService">

<partnerRole endpointReference="static">

<wsa:EndpointReference

xmlns:s="http://localhost:8080/webservice/services/HotelService">

<wsa:Address>

s:http://localhost:8080/webservice/services/HotelService

</wsa:Address>

<wsa:ServiceName

PortName="HotelService">s:HotelAgentService</wsa:ServiceName>

</wsa:EndpointReference>

</partnerRole>

</partnerLink>

</partnerLinks>

<wsdlReferences>

<wsdl location="wsdl/TravelProcess.wsdl"

namespace="http://localhost:8080/webservice/services/TravelProcess"/>

<wsdl location="wsdl/AirlineService.wsdl"

namespace="http://localhost:8080/webservice/services/AirlineService"/>

<wsdl location="wsdl/HotelService.wsdl"

namespace="http://localhost:8080/webservice/services/HotelService"/>

</wsdlReferences>

</process>

Quellcode 29: travel.pdd



<wsgui:deployment ...>

<wsgui:wsdl href="TravelServicel.wsdl" />

<wsgui:operations>

<wsgui:operation wsdlPort="TravelService" wsdlOperation="getTravel">

<wsgui:prettyName>Reiseangebote anfordern</wsgui:prettyName>

<wsgui:description>Liefert Reiseangebote</wsgui:description>

<wsgui:submit>

<wsgui:label>Abschicken</wsgui:label>

</wsgui:submit>

</wsgui:operation>

<wsgui:operation wsdlPort="TravelService" wsdlOperation="bookTravel">

<wsgui:prettyName>Reise buchen</wsgui:prettyName>

<wsgui:description>Bucht eine Reise</wsgui:description>

<wsgui:submit>

<wsgui:label>Buchen</wsgui:label>

</wsgui:submit>

</wsgui:operation>

</wsgui:operations>

<wsgui:formComponents>



<wsgui:formComponent xpath="/getTravel/endLocation">

<xforms:input ref="/getTravel/endLocation">

<xforms:label>Ziel: </xforms:label>

<xforms:hint>Zielpunkt der Reise</xforms:hint>

</xforms:input>

</wsgui:formComponent>

<wsgui:formComponent xpath="/getTravel/userId">

<xforms:input ref="/getTravel/userId">

<xforms:label>Nutzer ID: </xforms:label>

<xforms:hint>Wird zur Authentifizierung benoetigt</xforms:hint>

</xforms:input>




<wsgui:formComponent xpath="/bookTravel/flightId">

<xforms:select1 ref="/bookTravel/flightId">

<xforms:label>Flugangebote: </xforms:label>

</xforms:select1>


<wsgui:formComponent xpath="/bookTravel/hotelId">

<xforms:select1 ref="/bookTravel/hotelId">

<xforms:label>Hotelangebote: </xforms:label>

</xforms:select1>


<wsgui:formComponent xpath="/bookTravel/userId">

<xforms:input ref="/bookTravel/userId">

<xforms:label>Nutzer ID: </xforms:label>

</xforms:input>




<wsgui:formComponent

xpath="/bookTravelResponse/bookTravelReturn/startLocation">

<xforms:output

ref="/bookTravelResponse/bookTravelReturn/startLocation"

model="return">

<xforms:label>Startort: </xforms:label>

</xforms:output>


...

</wsgui:formComponents>

</wsgui:deployment>

Quellcode 30: travelProcess.guidd (Auszug)



10.3 Inhalt der CD • Diese Diplomarbeit in elektronischer Form als Microsoft Word und PDF. • Die BPEL-Engine activeBPEL (Version 2.0), die SOAP-Engine Apache Axis (Versi-

on 1.4) und der Servlet-Container Apache Tomcat (Version 5.5.17). • Ein XML-Schema des eingeschränkten Sprachumfangs eines abstrakten BPEL-

Prozesses. • Der Quellcode des abstracters und des Prototyps von GUI4CWS mit zugehörigen Ja-

vadocs. • Die für den Prototyp und abstracter benötigten Bibliotheken. • Den Quellcode der beiden Beispieldienste der Fluggesellschaft und des Hotelagenten. • Eine in activeBPEL lauffähige BPR-Datei und die zugehörige Verzeichnisstruktur mit

den benötigten Dokumente (siehe Quellcode 23 bis Quellcode 29). • Eine abstrakte Prozessbeschreibung der Reisebuchung. • Die zur Reisebuchung zugehörige GUIDD.

Date post:	03-Feb-2022
Category:	Documents
Upload:	others
View:	0 times
Download:	0 times

Analyse und Vergleich von Ans¤tzen zur Einbindung von

Documents