Generisches Web Service Interface um Simulationsanwendungen in BPEL-Prozesse einzubinden

Transkript

1 Institut für Architektur von Anwendungssystemen Universität Stuttgart Universitätsstraße 38 D Stuttgart Diplomarbeit Nr Generisches Web Service Interface um Simulationsanwendungen in BPEL-Prozesse einzubinden Jens Rutschmann Studiengang: Softwaretechnik Prüfer: Betreuer: Prof. Dr.-Ing. Dimka Karastoyanova Dipl.-Math. Michael Reiter begonnen am: 15. Februar 2009 beendet am: 17. August 2009 CR-Klassifikation: H.3.5, H.3.4, I.6.3, I.6.7

2

3 Inhaltsverzeichnis 1 Einleitung Motivation Aufgabe dieser Arbeit Aufbau der Arbeit Grundlagen SOA und Web Services SOA Web Services Web Service Interface Workflow Prozesse und Workflows Workflow Management Systeme Workflow-Sprachen BPEL IT für e-science Simulationen Simulationssoftware Finite Elemente Methode Message Passing Interface Verwandte Arbeiten Trident Taverna Verwendete Software Simulationssoftware DUNE ChemShell Interprozesskommunikation D-Bus Axis gsoap Serverplattform III

4 3.3.1 Apache Tomcat Apache ODE Web Service Interface Anforderungen Generische Verwendbarkeit Interoperabilität mit Legacy-Anwendungen Plattformunabhängigkeit Erweiterbarkeit Synchrone und asynchrone Ausführung Laufzeitumgebung Spezifikation Simulationsinstanzen Statische und interaktive Simulationen Lebenszyklus einer Simulationsinstanz Anwendungsfälle Entwurf Architektur Web Service-Operationen für den Client Asynchrone Rückantworten an den Client Erweiterungen für interaktive Simulationsanwendungen Web Service-Operationen für Simulationsanwendungen Implementierung Generierung von Web Service-Klassen mit Axis Paketierung der kompilierten Klassen Verwendete Verzeichnisse in der Laufzeitumgebung Entpacken von Archiven Test Fallbeispiel: Integration einer DUNE-Anwendung Web Service Interface Plugin für DUNE Änderungen an DUNE Anpassen des Quellcodes Weitere Anmerkungen Fallbeispiel: Integration von ChemShell Web Service Interface Plugin für ChemShell Änderungen an ChemShell Anpassen des Quellcodes Weitere Anmerkungen Laufzeitumgebung Import in Virtualisierungssoftware Virtualisierte Hardware-Komponenten Aufbau der Laufzeitumgebung Interaktion mit der Laufzeitumgebung Interaktion mit dem Web Service Interface IV

5 5.4.2 Benutzung des Betriebssystems Integration in ein Netzwerk Sicherheitsaspekte Zusammenfassung und Ausblick Ausblick A Anhang 117 A.1 XML-Typendefinitionen der WSDL-Schnittstellenbeschreibungen A.2 Schnittstelle des Basis Web Service A.3 Schnittstelle des Clients für asynchrone Rückantworten A.4 Schnittstelle des Callback Web Service für Simulationsinstanzen A.5 Schnittstelle des DUNE-Plugins A.6 Schnittstelle des ChemShell-Plugins A.7 Schnittstelle des Clients des ChemShell-Plugins Abkürzungsverzeichnis 141 Abbildungsverzeichnis 143 Verzeichnis der Listings 145 Literaturverzeichnis 147 V

6

7 Kapitel 1 Einleitung Der Einsatz von Computer-gestützten Simulationen in Wirtschaft und Forschung nimmt seit Jahren zu. Vor dem Hintergrund stetig steigender Rechenleistung aktueller Rechnersysteme ist ein Anhalten dieses Trends abzusehen [GKC + ]. Computer-gestützte Simulationen sind Simulationen, die komplett an einem oder mehreren Rechnern durchgeführt werden. Diese Arbeit befasst sich lediglich mit Computer-gestützten Simulationen in der Wissenschaft, im Folgenden der Einfachheit halber Simulationen genannt. Eine genaue Definition des Begriffs Simulation befindet sich in Abschnitt dieser Arbeit. Die Gründe für den Einsatz einer Simulation sind vielfältig. So lassen sich Kosten sparen, indem ein Experiment simuliert wird, statt dieses in der reellen Welt durchzuführen. In anderen Fällen ist ein Experiment in der reellen Welt oft nicht durchführbar, z.b. bei der Forschung in der Raumfahrt. Weiterhin bieten Simulationen Vorteile, die bei reellen Experimenten nicht gegeben sind: Aufwändige Vorbereitungen entfallen. Zudem werden mögliche Unterschiede bei mehreren Wiederholungen desselben Experiments weitgehend ausgeschlossen, da die Ausgangssituation bei einer Simulation konstant gehalten werden kann und nicht von Umweltparametern beeinflusst wird. Weiterhin lässt sich eine Simulation unterbrechen und fortsetzen, oder komplett abbrechen wenn bereits während der Simulation genug Erkenntnisse gesammelt werden konnten. Die Auswirkungen auf die reale Welt sind minimal: Die Simulation verursacht Kosten durch die Nutzung von Rechenressourcen. Oft sind auch weniger Mitarbeiter in Simulationen involviert als bei entsprechenden Ausführungen in der realen Welt. Der Wert einer Simulation bemisst sich an der Verwertbarkeit der Ergebnisse und der Realitätsnähe. Wenn die Ergebnisse nicht verwertet werden können sind, hatte die Simulation keinen Sinn. Ebenso schwindet meist der Wert einer Simulation je stärker sich die simulierte Welt von der reellen Welt unterscheidet. Umgekehrt steigt der Wert einer Simulation, je mehr Einflüsse aus der reellen Umgebung in der Simulation abgebildet werden. Aktuelle Simulationsprogramme sind meist auf einen bestimmten Zweck hin entwickelt worden [GKC + ], wie z.b. die Krafteinwirkung von starkem Wind auf ein Hallendach. Andere Simulationen bilden die Ausdehnung bestimmter Materialien bei unterschiedlichen Temperaturen ab. Interessant für einen Architekten sind aber nicht die Einzelergebnisse dieser Simulationen, sondern deren kombinierte Aussage: Wie verhält sich das Hallendach während und nach einem 1

8 1 Einleitung plötzlichen Sommergewitter bzgl. der Temperaturschwankung und der Krafteinwirkungen durch Regen oder Hagel und des Windes? Die Zweckgebundenheit vieler vorhandener Simulationsprogramme hat zur Folge, dass die Programme aus informationstechnischer Sicht schlecht zu gekoppelten Simulationen zusammengefügt werden können. Oft liegt es daran, dass die Programme entweder von nicht mit den aktuellen Arbeitsweisen, Werkzeugen und Technologien der Informatik vertrauten Personen entwickelt wurden, oder so stark für ein bestimmtes Einsatzgebiet optimiert sind, dass sie sich schlecht erweitern lassen. Ein Hemmnis für den Einsatz von Simulationen ist unter anderem, dass die Initiatoren der Simulation oft nur über eingeschränkte Programmierkenntnisse verfügen [KP08]. Dies führt dazu, dass entweder das Programmieren erst erlernt werden muss oder auf externe Entwickler zugegriffen werden muss. Ersteres ist meist sehr zeitaufwändig und oft frustrierend, da in dieser Zeit keine Forschung im eigentlichen Fachgebiet betrieben werden kann. Letzteres resultiert in zusätzlichen Kosten und verlangsamter Entwicklung, da ein erhöhter Kommunikationsaufwand zu erwarten ist. Weiterhin sind Probleme und Missverständnisse zu erwarten, die während der Kommunikation aufgrund mangelnder Expertise im Fachgebiet des jeweiligen Gegenübers auftreten. Ein Ziel des Exzellenzclusters Simtech 1 ist die interdisziplinäre Zusammenarbeit für das Vorantreiben von Simulationen in der Wissenschaft. Diese Arbeit dient mit als Grundlage für die vereinfachte Erstellung von integrierten Simulationen und Simulationen mit mehreren Skalen, so dass auch Wissenschaftler mit wenigen Kenntnissen in der Programmierung komplexe Simulationen durchführen können. 1.1 Motivation Aus der oben beschriebenen Situation leiten sich verschiedene wünschenswerte Eigenschaften von Simulationen ab. Eine Computer-basierte Simulation soll: die Wirklichkeit möglichst gut abbilden daher viele Außeneinflüsse simulieren können von Wissenschaftlern mit wenig bis gar keinen Programmierkenntnissen möglichst mit Unterstützung grafischer Hilfsmittel erstellt werden können einen klar erkennbaren Ablauf verfolgen. Diese Eigenschaften können den Einsatz von Simulationen in Gebieten fördern, in denen sie bisher wenig oder gar nicht eingesetzt werden. 1 Simtech, 2

9 1.2 Aufgabe dieser Arbeit 1.2 Aufgabe dieser Arbeit Um die oben genannten Eigenschaften umzusetzen ist es wichtig, dass vorhandene Simulationsprogramme miteinander kombiniert weiterverwendet werden können. Eine Kombination setzt voraus, dass vorhandene Simulationsanwendungen über standardisierte Schnittstellen und Datenformate verfügen. Die Problemstellung bezüglich der Datenformate ist häufig innerhalb einer Wissenschaftsdisziplin bereits in großen Teilen gelöst. Die Schaffung von Datenformaten für interdisziplinäre Zusammenarbeit ist nicht Teil dieser Arbeit. Diese Arbeit befasst sich mit der Erstellung einer einheitlichen und möglichst generischen Schnittstelle, über die die Simulationsprogramme angesprochen werden können. Die Kombination der einzelnen Simulationskomponenten kann dann durch Verwendung von Prozessmodellierungssprachen umgesetzt werden, wie zum Beispiel der Business Process Execution Language (BPEL) [CGK + 02], beschrieben in Abschnitt Die Schnittstelle soll möglichst abstrakt und plattformübergreifend gehalten sein, daher werden für die Implementierung der Ziele dieser Arbeit Web Services für die Schnittstelle verwendet, die in Abschnitt erläutert werden. Die Web Services Description Language (WSDL) [CCMW01], beschrieben in Abschnitt 2.1.2, erlaubt die abstrakte Beschreibung von Schnittstellen sowie die konkrete Angabe von Adressierung und Kommunikationsparametern von Implementierungen dieser Schnittstellen. Weiterhin soll die Schnittstelle eine grafische Erstellung komplexer Simulationen unterstützen. Das grafische Modellierungswerkzeug ist jedoch nicht Aufgabe dieser Arbeit. Neben der Schnittstelle selbst soll eine Laufzeitumgebung erstellt werden, in der die Schnittstelle, die verwendeten Simulationsanwendungen, sowie die Workflow-Umgebung ausgeführt werden können. 1.3 Aufbau der Arbeit Die Arbeit gliedert sich in sechs Kapitel. Der Einleitung folgt eine Einführung in grundlegende Technologien, die für diese Arbeit von Relevanz sind. Danach werden Softwaresysteme erklärt, mit und an denen im Verlauf dieser Arbeit gearbeitet wurde. In Kapitel drei wird lediglich auf diejenigen System eingegangen, die für das Funktionieren der Web Service-Schnittstelle von Bedeutung sind, verwendete Entwicklungsumgebungen und ähnliche Werkzeuge werden in dieser Arbeit nicht erläutert. Kapitel vier enthält die Anforderungen der Web Service- Schnittstelle, deren Spezifikation, sowie Entwurfs- und Implementierungs-Details. Die Web Service-Schnittstelle benötigt eine spezielle Laufzeitumgebung, welche in Kapitel fünf beschrieben wird. Das letzte Kapitel bilden eine Zusammenfassung und ein Ausblick auf mögliche Erweiterungen. Diese Arbeit ist in deutscher Sprache verfasst. Viele Bezeichnungen lassen sich jedoch nicht oder nur schlecht aus dem Englischen übersetzen. Um schlechte und sinnverfälschende Übersetzungen oder umständliche Umschreibungen zu vermeiden, werden deshalb in diesen Fällen die 3

10 1 Einleitung englischen Begriffe ohne Übersetzung verwendet. Dies dient auch der Erleichterung weiterer Recherchen, da somit Übersetzungsunterschiede zu anderen Arbeiten vermieden werden. 4

11 Kapitel 2 Grundlagen Dieses Kapitel enthält kurze Einführungen in grundlegende Konzepte und Technologien, die für das Verständnis der Arbeit hilfreich bzw. notwendig sind. Zunächst werden Service-orientierte Architekturen und Web Services erläutert (Abschnitt 2.1), danach das Konzept von Workflows und Workflow Management Systemen, sowie die verschiedenen Workflow-Sprachen (Abschnitt 2.2). Den Abschluss bildet eine Einführung in den Bereich e-science, in Simulationssoftware und in die Finite Elemente Methode (Abschnitt 2.3). 2.1 SOA und Web Services Service-orientierte Architekturen (SOA) hängen in der Regel eng mit Web Services zusammen, da diese die momentan populärste technische Umsetzung der SOA darstellen [Pv07]. Aus diesen Gründen ist es sinnvoll beide Themen zu beschreiben. Service-orientierte Architekturen und Web Services sind auch für das Verständnis von Workflow-Management-Systemen von Bedeutung, insbesondere für die Workflow-Beschreibungssprache Business Process Execution Language (BPEL), die in Kapitel beschrieben wird SOA Im Rahmen von SOA ist ein Service oder Dienst eine bestimmte Menge an Funktionalität, die zur Verwendung bereitgestellt wird. Weiterhin tauchen drei Grundbegriffe wiederholt auf. Der Service Provider ist der Anbieter eines Dienstes. Dieser wird vom Service Client verwendet, wenn er den Dienst in Anspruch nehmen möchte. Das Service Verzeichnis dient dem Service Provider zur Publizierung seines Dienstes, dem Entwickler des Service Clients hilft es bei der Auswahl eines konkreten Service Providers. Das viel zitierte SOA-Dreieck in Abbildung 2.1 zeigt diesen Zusammenhang grafisch. Die Service-orientierte Architektur ist ein spezieller Architekturstil, der für Anwendungen verwendet wird, welche ihre Funktionalität teilweise oder komplett als Dienste bereitstellen sollen. Diese Dienste können dann von anderen Anwendungen verwendet werden. 5

12 2 Grundlagen Service Verzeichnis veröffentlichen (1) abfragen (2) Service Provider nutzen (3) Service Client Abbildung 2.1: SOA Dreieck Die SOA wurde konzipiert um den Anforderungen nach immer schneller entwickelbaren und anpassbaren Anwendungen gerecht zu werden. Genauer gesagt soll sie als Antwort auf Anforderungen nach lose gekoppelten, auf Standards basierenden, verteilten, sowie protokollund plattform-unabhängigen Anwendungen dienen, die im Rahmen der Enterprise Information Systems (EIS) möglichst direkt auf Geschäftsprozesse abgebildet werden können [Pv07]. Die SOA selbst ist dabei nicht an eine bestimme Technologie gebunden, sondern legt nur fest, dass Dienste in einer bestimmten Beschreibungssprache definiert sind und für den Geschäftsprozess sinnvolle Schnittstellen bieten. Die Definitionen und Beschreibungen der SOA sind häufig auf das Business-Umfeld ausgerichtet, jedoch lassen sich innerhalb einer SOA auch Dienste für andere Arten von Prozessen erstellen, wie zum Beispiel die in dieser Arbeit erstellten Dienste für das Scientific-Umfeld. Dienste haben in einer SOA nach [Pv07] die folgenden Charakteristika: Dienste sind in sich abgeschlossen, sie verwalten ihren aktuellen Zustand selbstständig. Dienste bestehen aus einer Schnittstelle und einer Implementierung, welche jedoch nicht plattformunabhängig sein muss. Dienste können auf dynamische Weise aufgefunden, verwendet und zu anderen Diensten kombiniert werden. Innerhalb einer SOA wird die gesamte Funktionalität in Form von wiederverwendbaren Diensten bereitgestellt. Dies gilt sowohl für Funktionen, die direkt auf ein Objekt im (Geschäfts-)Prozess abgebildet werden können, als auch für Funktionen, die lediglich intern in der gesamten SOA-Anwendung verwendet werden, jedoch nicht für die direkte Nutzung durch Benutzer der Anwendung bestimmt sind. Dienste in einer SOA sind komplett neu entwickelte Funktionalitäten, alte Anwendungen, die mit einer Schnittstelle ausgestattet wurden, oder ein Verbund mehrerer alter und neuer Funktionalitäten. 6

13 2.1 SOA und Web Services Dienste sind nicht einsehbar, d.h. wie der Dienst die von ihm bereitgestellte Funktionalität umsetzt, ist anhand seiner Beschreibung nicht erkennbar. Die Ausführung eines Dienstes ist isoliert von anderen Diensten, d.h. ein Dienst kann andere Dienste nur dadurch beeinflussen, indem er sie entweder selbst verwendet, oder indem er Daten modifiziert, die auch andere Dienste verwenden. Für den Service Client ist es nicht relevant, ob sich der Dienst lokal oder auf einer Maschine im Netzwerk befindet. Bestandteile eines Dienstes Service Interface A - Operation 1 - Operation 2 - Operation 3... Interface B - Operation 1 - Operation Implementation Business Logic Service contract Data Abbildung 2.2: Bestandteile eines Dienstes nach [KBS07] Abbildung 2.2 beschreibt die Bestandteile eines Dienstes nach [KBS07]. Im Wesentlichen besteht ein Dienst aus drei Komponenten: einer oder mehreren Schnittstellen (Interface), einer informellen Beschreibung (Service Contract) und einer Implementierung (Implementation). Schnittstellen Die formelle Beschreibung der Schnittstellen enthält eine Liste aller Operationen, die die jeweilige Schnittstelle des Dienstes enthält. Ein Dienst kann mehrere Schnittstellen auf einmal implementieren. Die Aufteilung der Funktionalität auf mehrere Schnittstellen dient meist zur Gruppierung von Funktionalitäten und zur Übersichtlichkeit. Informelle Beschreibung Die informelle Beschreibung des Dienstes enthält Informationen zu dessen Verhalten und 7

14 2 Grundlagen weitere Details, die nicht in der formellen Beschreibung enthalten sind, wie zum Beispiel der Zweck und mögliche Einschränkungen des Dienstes. Implementierung Die Implementierung ist das Programm bzw. die technische Umsetzung, die als Dienst bereitgestellt wird. Sie ist im Normalfall nicht in der Beschreibung dokumentiert und daher nicht für Nutzer des Dienstes einsehbar. Die Implementierung besteht wie nahezu alle Anwendungen aus einer Logik (im Bild Business Logic genannt) und aus Daten (Data), auf die die Logik angewendet wird. Binden eines Clients an einen Service-Provider Im Kontext von SOA werden zwei verschiedene Konzepte der Bindung bereitgestellt: Early Binding oder Development-Time Binding: Eine statische Bindung von Client und Provider zum Zeitpunkt der Entwicklung der Client-Anwendung. Der Client ist fest mit dem gewählten Provider verbunden. Ein Wechsel zu einem anderen Provider bedeutet Änderungen an der Anwendung, meist in deren Quellcode. Eine weitere Bezeichnung für diese Art von Bindung ist Build-Time Binding. Late Binding oder Runtime Binding: Die Bindung von Client und Provider erfolgt dynamisch während der Laufzeit der Client-Anwendung, unter Umständen erst unmittelbar vor dem Aufruf des Dienstes beim Provider. Der entsprechende Provider wird anhand verschiedener Kriterien automatisiert ausgewählt. Die dynamische Bindung ist ein komplexer Prozess und nicht von direkter Bedeutung für diese Arbeit, es sei daher auf die Literatur zu diesem Thema verwiesen. [KBS07] und [DJMZ08] geben Einblick in dieses Thema. Die im Rahmen dieser Arbeit erstellte Software verwendet Bindung von Client und Provider zur Entwicklungszeit, daher wird diese Bindungsart im Folgenden näher erläutert. Abbildung 2.3 zeigt schematisch den Zusammenhang der einzelnen Komponenten während der statischen Bindung wie [KBS07] ihn beschreibt. Der Prozess läuft folgendermaßen ab: 1. Der Entwickler der Client-Anwendung sucht in einem Service-Verzeichnis nach einem passenden Dienst und Service Provider für diese Art von Dienst. 2. Anhand der formellen Beschreibung des Dienstes aus dem Verzeichnis kann automatisiert ein Service-Stub generiert werden. 3. Der generierte Stub ist fest mit dem Provider aus der Beschreibung des Dienstes verbunden. 4. Die Client-Anwendung integriert diesen Service-Stub und kann durch diesen den Service aufrufen. Wie oben bereits erwähnt muss bei einem Provider-Wechsel der Service-Stub neu generiert werden, d.h. der Quellcode der Client-Anwendung geändert werden. Weiterhin muss zunächst ein Entwickler einen neuen Provider für den Service auswählen. 8

15 2.1 SOA und Web Services Service Verzeichnis sucht in enthält erstellt Service Beschreibung beschreibt erfüllt Service Implementierung ruft auf Service Client gebunden an basiert auf Service Stub benutzt Abbildung 2.3: Service-Bindung während der Entwicklung nach [KBS07] Service Bus Der Service Bus ist in der Regel die Komponente, die innerhalb einer SOA die anderen Komponenten wie Service-Provider, -Client und -Verzeichnis miteinander verbindet. Er stellt sozusagen die Kommunikationsinfrastruktur dar. Oberflächlich betrachtet lässt sich der Service Bus mit dem von CORBA bekannten Software Bus vergleichen, bietet jedoch bei näherer Betrachtung einige Vorteile im Hinblick auf die im nächsten Abschnitt beschriebenen Web Services. So ist der Service Bus nicht auf eine Technologie festgelegt, sondern bietet eine Vielfalt an Kommunikationskonzepten an. Ein Service Bus kann beispielsweise synchrone und asynchrone Kommunikation über Technologien wie Remote Procedure Call, Remote Method Invocation, Messaging, Dateiaustausch per FTP usw. erlauben. [KBS07] fasst die Charakteristika wie folgt zusammen: Konnektivität: Die Hauptaufgabe des Service Bus ist es, Kommunikation einzelner Clients und Services zu ermöglichen. Heterogenität der Technologie: Der Bus ist nicht auf eine bestimmte Technologie festgelegt. Heterogenität der Kommunikationskonzepte: Der Bus erlaubt beispielsweise synchrone und asynchrone Kommunikation. 9

16 2 Grundlagen Technische Dienste: Die technischen Dienste umfassen Quality of Services wie Sicherheit, Transaktionen und andere Funktionen wie Auditing, Logging oder das Umwandeln von Nachrichten in andere Formate Web Services Web Services stellen die momentan populärste Vorgehensweise zur technischen Realisierung einer SOA dar [Pv07, WCL + 08]. Web Services sollen als Antwort dienen auf die Forderung nach lose gekoppelten Komponenten und einheitlichen Methoden, um diese Komponenten oder Dienste innerhalb eines Netzwerks zu beschreiben, aufzufinden, und schließlich zu verwenden [WCL + 08]. Der Unterschied zu älteren Lösungen wie der Common Object Request Broker Architecture (CORBA) oder dem Distributed Component Object Model (DCOM) von Microsoft liegen in dieser losen Kopplung und Plattformunabhängigkeit. Mit Architekturspezifikationen wie CORBA oder DCOM werden Anwendungen erstellt, die fest an die entsprechenden Plattformen gebunden sind. Weitere Unterschiede sind, dass bei Web Services die Dienste zur Entwicklungszeit wegen der Möglichkeit der dynamischen Bindung nicht bekannt sein müssen, sowie die Verwendung offener Technologien und Spezifikationen. Diese Spezifikationen werden von Konsortien wie dem World Wide Web Consortium (W3C) oder der Organization for the Advandcement of Structured Information Standards (OASIS) erarbeitet. Das W3C definiert einen Web Service in [BHM + 04] wie folgt: A Web service is a software system designed to support interoperable machine-tomachine interaction over a network. It has an interface described in a machineprocessable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Webrelated standards. Diese Definition entspricht in Teilen der Definition eines Dienstes aus Abschnitt Auf Eigenschaften wie die Abgeschlossenheit und die dynamische Wiederverwendbarkeit wird hier allerdings nicht explizit eingegangen. Hinzu kommen Details zur technischen Umsetzung wie der Transport von XML-Daten über das HTTP-Protokoll, was bei Web Services eine verbreitete Umsetzung darstellt. Die Web Service Technologie wird geprägt durch einen modularen Aufbau. Für Konzepte wie Verzeichnisdienste, Sicherheit der Übertragungswege, Authentifizierung von Service Client und Service Provider und Transaktionen existieren weitere Spezifikationen, die auf die grundlegenden Spezifikationen aufsetzen. Dieser modulare Aufbau wird Web Service-Stack genannt. Einen guten Überblick geben der Artikel [BHM + 04] des W3C oder das Buch [WCL + 08]. Web Services Description Language (WSDL) Die formelle Beschreibungssprache für Web Services ist die Web Services Description Language (WSDL). Sie dient zur Beschreibung der Dienste und enthält Erweiterungsmöglichkeiten für die 10

17 2.1 SOA und Web Services in anderen Web Service-Spezifikationen definierten Konzepte, wie zum Beispiel die Richtlinien aus der WS-Policy-Spezifikation [BBC + 06]. Eine WSDL-Datei besteht im Allgemeinen aus zwei verschiedenen Teilen. Der abstrakte Teil beschreibt, was ein Dienst an Funktionalität bietet. Der konkrete Teil enthält Informationen dazu, wie der Dienst wo aufgerufen werden kann. Listing 2.1 enthält eine (gekürzte) WSDL- Beschreibung eines Beispiel-Dienstes mit einer Operation. Abstrakter Teil Der abstrakte Teil wird gebildet aus den Definition von wsdl:types, wsdl:message und wsdl:porttype. Er beschreibt welche Schnittstellen (wsdl:porttype) der Dienst enthält, welche Operationen die jeweilige Schnittstelle enthält, welche Nachrichten während der Ausführung einer Operation zwischen Service Client und Service Provider ausgetauscht werden (wsdl:message) und welche XML-Datentypen (wsdl:types) diese Nachrichten transportieren. Konkreter Teil Der konkrete Teil wird gebildet aus den Definitionen von wsdl:binding und wsdl:service. Das wsdl:binding beschreibt, wie ein Dienst verwendet werden kann, der wsdl:service enthält einen oder mehrere wsdl:port-definitionen. Diese sind jeweils mit einem wsdl:binding verknüpft und geben somit an, wo ein Dienst auf welche Weise bereitgestellt wird. Daher kann ein Dienst auch auf verschiedene Weisen verwendet werden, für jedes wsdl:binding wird dazu ein zusätzlicher wsdl:port definiert. WSDL-Dateien können sich auch auf die Beschreibung eines Teiles beschränken. In dem Fall kann der abstrakte Teil in einer oder mehreren anderen WSDL-Dateien mit konkreten Teilen importiert und wiederverwendet werden. Neben den beschriebenen Definitionen kann eine WSDL-Datei noch Erweiterungselemente in nahezu allen Abschnitten enthalten. Diese werden in den zusätzlichen Spezifikationen des Web Service-Stacks beschrieben. Die genaue Spezifikation der WSDL ist vom W3C unter [CCMW01] veröffentlicht worden. SOAP SOAP ist ein Nachrichten-Framework, das unter anderem von Web Services verwendet wird. Im eigentlichen Sinne ist SOAP sowohl ein Nachrichtenformat als auch ein Regelwerk für die Verarbeitung von Nachrichten während des Transports von Sender zu Empfänger. Abbildung 2.4 zeigt den Aufbau nach [WCL + 08]. Die Nachricht besteht aus zwei Bereichen, dem optionalen Header-Bereich, der die Kopfzeilen enthält, und dem Body-Bereich, der die Nutzdaten für den Empfänger enthält, auch Payload genannt. Da SOAP auf XML basiert, werden beide Bereiche in XML-Notation angegeben. Das gilt auch für den Body-Bereich, der sämtliche Nutzdaten im XML-Format enthält. Binär-Daten können entweder Base64 -kodiert direkt im Body-Bereich enthalten sein oder über eine spezielle Erweiterung als SOAP-Attachment an die Nachricht angehängt werden. Letzteres Vorgehen 11

18 2 Grundlagen Listing 2.1 Beispiel für eine WSDL-Datei 1 <definitions name="helloworld" targetnamespace=" 2 <types> 3 <schema targetnamespace=" 4 <element name="helloworldrequest" type="string"/> 5 <element name="helloworldresponse" type="string"/> 6 </schema> 7 </types> 8 9 <message name="helloworldrequestmessage"> 10 <part name="payload" element="tns:helloworldrequest"/> 11 </message> 12 <message name="helloworldresponsemessage"> 13 <part name="payload" element="tns:helloworldresponse"/> 14 </message> <porttype name="helloworld"> 17 <operation name="process"> 18 <input message="tns:helloworldrequestmessage" /> 19 <output message="tns:helloworldresponsemessage"/> 20 </operation> 21 </porttype> <binding name="helloworldsoapbinding" type="tns:helloworld"> 24 <soap:binding style="document" transport=" /> 25 <operation name="process"> 26 <soap:operation soapaction=" /> 27 <input><soap:body use="literal" /></input> 28 <output><soap:body use="literal" /></output> 29 </operation> 30 </binding> <service name="helloworldprocessservice"> 33 <port name="helloworldprocessport" binding="tns:helloworldsoapbinding"> 34 <soap:address location=" /> 35 </port> 36 </service> 37 </definitions> wird vor allem bei großen Datensätzen empfohlen, da die Base64-Kodierung aufgrund des verringerten Zeichensatzes Binärdaten stark vergrößert und die Kodierung selbst auch lange dauern kann [WCL + 08]. Der Pfad der Nachricht vom ursprünglichen Sender bis zum endgültigen Empfänger kann über beliebig viele Zwischenstationen verlaufen. Jede dieser Zwischenstationen kann dabei die Nachricht einfach weiterleiten oder zunächst weiterverarbeiten. Die Kopfzeilen im Header- Bereich werden in der Regel von den Zwischenstationen entfernt, nachdem sie ausgewertet wurden. Dies kann mittels eines speziellen Attributs verhindert werden können, wenn ein Header-Block während des gesamten Transports erhalten bleiben soll. 12

19 2.1 SOA und Web Services SOAP Envelope SOAP Header Header Block 1... Header Block M SOAP Body Body sub-element 1... Body sub-element N Abbildung 2.4: Aufbau von SOAP-Nachrichten nach [WCL + 08] SOAP ist nicht an ein bestimmtes Transportprotokoll gebunden sondern kann jedes Protokoll verwenden, für das SOAP-Bindings existieren. Das HTTP-Binding für SOAP wird im W3C- Artikel [GHM + 07] erläutert. Andere Protokolle wie Java Message Service (JMS) oder Simple Mail Transfer Protocol (SMTP) können über entsprechende Bindings ebenfalls verwendet werden. Weitere Informationen zu SOAP können dem Buch [WCL + 08] oder den unter [BEK + 00] angegebenen Spezifikation des W3C entnommen werden. WS-Addressing WS-Addressing wurde entwickelt, um Web Service-Endpunkte beschreiben zu können und um diese Endpunktbeschreibungen in SOAP-Nachrichten einbetten zu können. Die Einbettung ermöglicht den Nachrichtenaustausch zwischen Nutzern und Anbietern eines Web Services, auch wenn die beiden Partner zur Entwicklungszeit des Clients oder Dienstes noch nicht feststehen. WS-Addressing wurde vom W3C in [GHR06a] spezifiziert. Der Begriff Web Service-Endpunkt bezeichnet im Prinzip einen in WSDL definierten wsdl:port. Ein solcher Port ist immer genau einem Dienst zugeordnet. Da Web Services selbst nicht an ein bestimmtes Transport-Protokoll gebunden sind, muss dies auch für WS-Addressing gelten. Daher werden keine Protokoll-spezifischen Eigenschaften für die Adressierung von Endpunkten verwendet. Wie oben erwähnt, besteht WS-Addressing aus zwei Teilspezifikation. Der erste Teil spezifiziert die Endpoint Reference (EPR), die als Zeiger auf einen Web Service Endpunkt dient. Der zweite Teil spezifiziert Möglichkeiten, EPRs in SOAP-Nachrichten einzubetten. 13

20 2 Grundlagen Der Einsatz von WS-Addressing ist immer dann notwendig, wenn Request Message (Anfrage) und Response Message (Rückantwort) nicht im Kontext eines synchronen Web Service-Aufrufs stattfinden, sondern zwei Einwege-Nachrichten ausgetauscht werden. Dies liegt daran, dass bei einem synchronen Aufruf die Rückantwort über denselben Transportkanal und dieselbe Verbindung gesendet wird, wie die Anfrage und der Service Client solange blockiert wird. Bei asynchronen Aufrufen wird der Transportkanal und die Verbindung dagegen geschlossen, nachdem die Anfrage abschickt wurde. Die Rückantwort wird in diesem Fall in einer neuen Verbindung gesendet, auch der Transportkanal kann ein anderer sein. Bei synchronen Web Service-Aufrufen wird im Normalfall auf WS-Addressing verzichtet, daher sehen die nachfolgenden Beschreibungen einen asynchronen Aufruf mit dem Austausch von zwei Einwege-Nachrichten vor. Listing 2.2 Beispiel für eine SOAP-Nachricht 1 <soap:envelope xmlns:soap=" 2 xmlns:wsa=" 3 xmlns:f123=" 4 <soap:header> 5 <wsa:messageid>uuid:aaaabbbb-cccc-dddd-eeee-ffffffffffff</wsa:messageid> 6 <wsa:replyto> 7 <wsa:address> 8 </wsa:replyto> 9 <wsa:to>mailto:joe@fabrikam123.example</wsa:to> 10 <wsa:action> 11 </soap:header> 12 <soap:body> 13 <f123:delete> 14 <maxcount>42</maxcount> 15 </f123:delete> 16 </soap:body> 17 </soap:envelope> EPR Eine Endpoint Reference (EPR) enthält alle Informationen um einen Web Service zu adressieren. Neben den Adress-Informationen können auch noch weitere Informationen enthalten sein, wie Referenz-Properties und -Parameter. Die Informationen lassen sich nach [WCL + 08] in zwei Klassen einteilen: Runtime-Informationen, die für die Adressierung notwendig sind und Metadaten, die den Endpunkt weiter beschreiben. Runtime Informationen Dieser Teil enthält immer ein Adressfeld, das den Endpunkt angibt, sowie optionale Referenz-Properties und -Parameter. Referenz-Properties sind Datensätze, die bei der Zustellung zum Endpunkt verwendet werden oder das Verhalten des Endpunkts bestimmen können, indem z.b. Richtlinien aus der WS-Policy Spezifikation [BBC + 06] angeben werden. Referenz-Parameter dagegen sind Daten, die vom Endpunkt intern verwendet werden können, aber nicht für die Identifikation des Endpunkts benötigt werden. 14

21 2.1 SOA und Web Services Metadaten Die Metadaten sind optional und können Informationen wie die Namen von wsdl:porttype, wsdl:port und wsdl:service enthalten. Dies ist speziell dann nützlich, wenn der referenzierte Endpunkt temporär für die Rückantwort auf eine Anfrage erstellt wurde und daher keine WSDL-Beschreibung für ihn existiert. Weiterhin können Richtlinieninformation angegeben werden. Die Metadaten sind in [GHRY07] spezifiziert. SOAP Message Endpoint Reference Address Source To Reference Property Reference Property Reference Parameter Reference Parameter Port Type MessageID Service/Port Policy WSDL Port Type Operation Input/Action ReplyTo FaultTo Action Output/Action Service Port Abbildung 2.5: WS-Addressing in SOAP-Nachrichten nach [WCL + 08] Message Headers Für die Einbettung von EPRs in SOAP-Nachrichten spezifiziert WS-Addressing verschiedene Kopfzeilen [GHR06b]. Bei den folgenden Definitionen bezeichnet der Begriff Endpunkt immer genau den Endpunkt, an den eine Nachricht geschickt wird, falls nicht anders angegeben. To Enthält die Adresse, unter der der Endpunkt erreichbar ist. Zwingend notwendig. 15

22 2 Grundlagen Abbildung 2.6: WS-Addressing in Request- und Response-Nachrichten nach [WCL + 08] Action Definiert, wie eine Nachricht am Endpunkt verarbeitet wird. Zwingend notwendig. Die Action-Kopfzeile ist besonders dann wichtig, wenn der Web-Service nicht den RPC-Stil verwendet, da verschiedene Operationen des Dienstes den gleichen Typ von Eingabedaten enthalten können und in diesem Fall der Nachricht nicht eindeutig eine Operation zuordenbar wäre. Die Action-Kopfzeile referenziert daher im Normalfall die Input-Nachricht einer Operation. ReplyTo Enthält eine EPR des Endpunkts, an den die Rückantwort gesendet werden soll. Diese Kopfzeile ist nur dann vorgeschrieben, wenn die Nachricht eine Anfrage ist, auf die eine Rückantwort erfolgen soll. 16

23 2.1 SOA und Web Services FaultTo Enthält die EPR des Endpunkts, an den Fehlermeldungen gesendet werden sollen, die während der Verarbeitung einer Anfragenachricht auftreten. Diese Kopfzeile ist optional, wenn sie fehlt kann der Dienst entscheiden, ob eventuelle Fehlerfälle an die EPR aus ReplyTo oder Source geschickt werden. Source Enthält die EPR des Clients. Diese Kopfzeile ist immer optional und kann vom Dienst auf unterschiedliche Weise ausgewertet werden, zum Beispiel um herauszufinden, wer die Anfrage geschickt hat, falls ReplyTo-Header fehlen, etc. MessageID Enthält eine eindeutige Identifikation der Nachricht. Wird nur innerhalb von Anfrage- Nachrichten benötigt, auf die eine Rückantwort erfolgen soll. RelatesTo Enthält die Identifikation aus der MessageID-Kopfzeile der Anfrage und die Rolle der Nachricht innerhalb des Nachrichtaustausches. WS-Addressing sieht hier bisher nur den Typ Reply vor. Die RelatesTo-Kopfzeile ist nur innerhalb einer Rückantwort auf eine Anfrage vorgesehen. Listing 2.2 zeigt das Beispiel einer SOAP-Nachricht mit eingebetteten WS-Addressing- Kopfzeilen. Abbildung 2.5 zeigt wie die einzelnen Bestandteile von WSDL und EPR des Dienstes beim Erstellen einer SOAP-Nachricht eingebettet werden. Dabei ist zu beachten, dass die EPR in der ReplyTo-Kopfzeile kein Action-Feld enthält. Dieses wird vom aufgerufenen Dienst aus dem Namen der Output-Nachricht erzeugt und dann bei der Rückantwort eingefügt. Dies wird in Abbildung 2.6 veranschaulicht, die das Zusammenspiel von EPRs in Anfrage- und Rückantwort-Nachrichten zeigt Web Service Interface Wenn ein Unternehmen seine Software auf eine Service-orientierte Architektur umstellt, dann führt dies in den meisten Fällen zu der Frage, wie Legacy-Anwendungen in die SOA integriert werden können. Dies sind existierende Anwendungen, die oft bereits seit langer Zeit eingesetzt werden. Die Entwicklung und Wartung dieser Werkzeuge hat oft lange gedauert und viele Ressourcen gekostet, daher sind sie meist ausgereift und sollen möglichst weiter verwendet werden [Gim07]. Bei der Entwicklung solcher Programme wurde oft jedoch nicht bedacht, dass sie eines Tages in ein neues System integriert werden sollen. Daher fehlen entsprechende Schnittstellen. Um eine solche Legacy-Anwendung zu integrieren, wird eine Art Schnittstelle benötigt, die dabei hilft, die Anwendung in die SOA zu integrieren, indem die SOA-typischen Kommunikationsformen auf eine Form übersetzt werden, die die Anwendung versteht. Für die Anbindung einer Legacy-Anwendung gibt es dazu eine Vielzahl an Möglichkeiten. Im Folgenden werden zwei Möglichkeiten zur Anbindung über ein Web Service Interface vorgestellt, die auch im Rahmen dieser Arbeit angewendet wurden. 17

24 2 Grundlagen Web Service Interface mit Adapter-Anwendung Bei dieser Lösung wird eine komplett neue Adapter-Anwendung erzeugt, die auf der einen Seite einen Web Service bereitstellt und auf der anderen Seite über verschiedene Kommunikationsformen mit der Legacy-Anwendung kommuniziert. Abbildung 2.7 veranschaulicht dies. Für die Kommunikation mit der Legacy-Anwendung stehen dabei verschiedene Lösungen bereit, die stark von der jeweiligen Anwendung abhängen: WS Port Web Service Adapter Anwendung Kommunikation Legacy Anwendung Betriebssystem Abbildung 2.7: Web Service Interface mit Adapter-Anwendung Dateiaustausch: Der Adapter stellt die Dateien bereit, auf denen die Anwendung arbeiten soll. Danach startet der Adapter die Anwendung, unter Umständen mit bestimmten Parametern. Nachdem die Anwendung die Bearbeitung abgeschlossen hat, kann der Adapter die erzeugten Dateien auswerten und dem Web Service Client entsprechende Informationen zurücksenden. Standard-Ein-/Ausgabe: Der Adapter startet die Anwendung und benutzt dann die Standard-Ein-/Ausgabe des Betriebssystems, um mit der Anwendung zu kommunizieren. Weitere Mechanismen zur Interprozesskommunikation: Wenn die Anwendung bereits vorher mit anderen Anwendungen zusammengearbeitet hat, werden unter Umständen IPC-Mechanismen (siehe Abschnitt 3.2) verwendet. Der Adapter kann diese für die Kommunikation verwenden. Die Adapter-Anwendung kann eine eigenständige Anwendung sein, die einen Server für den bereitgestellten Web Service integriert. Eine andere Möglichkeit ist eine Anwendung, die im Kontext einer Server-Plattform läuft und beispielsweise einen Service Bus für die Bereitstellung ihres Web Services verwendet. Legacy-Anwendung mit integriertem Web Service Interface Bei dieser Lösung wird die Legacy-Anwendung selbst modifiziert. In die Anwendung wird ein Server integriert, der den Web Service der Anwendung bereitstellt. Sobald die Anwendung gestartet wurde und der integrierte Web Service Server aktiv ist, kann der Web Service 18

25 2.2 Workflow verwendet werden. Abbildung 2.8 zeigt dies. Die Kommunikation intern erfolgt durch direkte Verwendung der Funktionalität anhand von Funktionsaufrufen, etc. WS Port Web Service Server Legacy Anwendung Betriebssystem Abbildung 2.8: Legacy-Anwendung mit integriertem Web Service Interface Diese Lösung setzt meist voraus, dass die Anwendung in der Lage ist, verschiedene Anfragen gleichzeitig parallel behandeln zu können, ohne dass diese sich gegenseitig beeinflussen. Ist dies gewährleistet, kann die Anwendung auch an einen Service Bus angebunden werden oder als Art Bibliothek im Rahmen einer Server-Plattform verwendet werden. Diese Lösungsmöglichkeit ist daher nicht ohne Weiteres verwendbar, wenn die Anwendung die zuvor erwähnten Eigenschaften nicht besitzt, sondern beispielsweise so entwickelt wurde, dass für jede Programmbenutzung eine eigene Programminstanz gestartet werden muss. 2.2 Workflow Dieses Unterkapitel gibt einen Einblick in das Thema Workflow. Dazu werden zunächst Prozesse und Workflows generell vorgestellt und danach erläutert, was ein Workflow Management Systeme (WfMS) ist. Den Abschluss bilden eine Übersicht an Workflow-Sprachen und ein Einblick in die Workflow-Sprache BPEL Prozesse und Workflows Ein Prozessmodel beschreibt nach [LR00] die Struktur eines (Geschäfts-)Prozesses in der reellen Welt. Es legt fest, wie ein Prozess abläuft, d.h. es enthält alle Aktivitäten eines Prozesses und die möglichen Pfade zwischen diesen Aktivitäten. Das Prozessmodell wird als Vorlage verwendet, wenn ein Prozess tatsächlich ausgeführt wird. Dann wird eine so genannte Prozessinstanz aus dem Modell erzeugt. Wenn beispielsweise ein Prozessmodell existiert, das den Vorgang Konto eröffnen bei einer Bank festlegt, dann wird eine Instanz einem Kunden zugeordnet, der bei der Bank ein Konto eröffnen möchte. Der Pfad durch das Prozessmodell kann bei jeder Prozessinstanz unterschiedlich sein, so kann zum Beispiel einem Kunden ein spezielles Angebot gemacht werden, wenn er bereits vorher Kunde bei der Bank war. 19

26 2 Grundlagen Prozesse müssen nicht notwendigerweise auf Rechnern ausgeführt werden, sondern können auch von Personen direkt durchgeführt werden. Dies führt zum Begriff des Workflow-Modells, welches diejenigen Teile eines Prozessmodells bezeichnet, die von Computern ausgeführt werden. Analog zum Prozessmodell dient das Workflow-Modell als Vorlage zur Instanzierung von Workflow- Instanzen. Im Folgenden werden die Begriffe Prozessmodell und Workflow-Modell, sowie Prozessinstanz und Workflow-Instanz jeweils als Synonym verwendet, da sich diese Arbeit lediglich mit Prozessen beschäftigt, die auf Rechnern ausgeführt werden. Weiterhin wird der Begriff Prozess als Kurzform für Prozessinstanz verwendet. Es wird zwischen Business Workflows und Scientific Workflows unterschieden [AMA06]. Obwohl im Rahmen dieser Arbeit Workflows für wissenschaftlichen Simulationen erstellt wurden, kommen ausschließlich Workflows, Werkzeuge und Sprachen aus dem Business-Bereich zum Einsatz. Dieses war eine grundlegende Anforderung an die Arbeit. Workflow Dimensionen Im Buch [LR00] werden Prozessen drei verschiedene Dimensionen zugeordnet: Wer?, Wie? und Mit Was?. Diese können wie folgt beschrieben werden: Wer Wie Diese Dimension beschreibt Organisationen, Rollen oder individuelle Personen, die eine Aktivität innerhalb des Prozesses ausführen. Wenn die Ausführung einer Aktivität auch automatisiert erfolgen kann, dann wird die Aktivität vom Workflow Management System selbst ausgeführt, siehe Abschnitt Diese Dimension beschreibt die Aktivitäten, die während eines Prozesses ausgeführt werden müssen, und wie sie ausgeführt werden müssen. Aktivitäten können sowohl sequentiell als auch parallel ausgeführt werden, je nachdem, wie es im Prozessmodell festgelegt ist. Mit Was Diese Dimension beschreibt die IT-Ressourcen, die für eine Aktivität eingesetzt werden. Abbildung 2.9 zeigt die drei Workflow-Dimensionen als Würfel. Die Ausführung eines Prozesses, also eine konkrete Prozessinstanz, kann nach [LR00] als Pfad innerhalb dieses Würfels dargestellt werden. Die Abbildung zeigt eine teilweise Ausführung des Prozesses anhand des grauen Pfeils. Die grauen Kreise stellen jeweils die Ausführung einer Aktivität dar. Die Ausführung einer Aktivität kann sich bei jeder Prozessinstanz unterscheiden, zum Beispiel kann ein und dieselbe Aktivität von unterschiedlichen Personen innerhalb der Organisation auf verschiedenen IT-Ressourcen durchgeführt werden. 20

27 2.2 Workflow Prozesslogik Organisation IT-Infrastruktur Abbildung 2.9: Workflow-Dimensionen nach [LR00] Workflow Management Systeme Als Workflow Management System (WfMS) bezeichnet man Programme, die dazu dienen, Workflows zu definieren, verwalten und auszuführen. Die Workflow Management Coalition (WfMC) definiert ein Workflow Management System in [H + 94] wie folgt: A system that completely defines, manages and executes workflows through the execution of software whose order of execution is driven by a computer representation of the workflow logic. WfMS werden nach dem Referenz-Modell der WfMC in mehrere Teile unterteilt, die wiederum aus vielen verschiedenen Komponenten bestehen. Die WfMC teilt ein solches System in die folgenden Bereiche ein: Buildtime Dieser Bereich umfasst alle Komponenten, die zur Erstellung und Verwaltung von Prozessmodellen, Ressourcen usw. verwendet werden. Runtime Im Runtime-Bereich sind alle Komponenten enthalten, die zur Ausführung einer Prozessinstanz benötigt werden. Database Die gesamte Datenhaltung wird im Normalfall von Datenbanken übernommen. Dieser Bereich kann beliebig viele und verschiedene Datenbanken umfassen. 21

28 2 Grundlagen Workflow Management Systeme sind äußerst komplex und umfangreich. Da sie für diese Arbeit nicht von entscheidendem Einfluss sind, sei für die weitere Lektüre auf das Buch [LR00] verwiesen. Weiterhin ist zu beachten, dass in dieser Arbeit nur Scientific Workflows betrachtet werden, siehe Abschnitt Workflow-Sprachen Für die Beschreibung von Prozessen werden spezielle Sprachen benötigt. In der Vergangenheit wurden mehrere dieser Sprachen entwickelt, von denen einige explizit zwischen Datenund Kontroll-Fluss unterscheiden. Dieser Abschnitt gibt einen kurzen Überblick über einige Sprachen. Die Kontrollfluss-orientierte Workflow-Sprache BPEL wird in Abschnitt näher erläutert. In dieser Arbeit werden nur Scientific Workflows betrachtet, jedoch die Sprachen und Werkzeuge aus dem Umfeld der Business-Workflows verwendet. Siehe auch Abschnitt Web Service Flow Language Die Web Service Flow Language (WSFL) wurde von IBM entwickelt. WSFL beschreibt Prozesse anhand eines gerichteten Graphen, dessen Knoten die Aktivitäten und dessen Kanten den Kontrollfluss oder Datenfluss zwischen den einzelnen Aktivitäten darstellen. Die Kanten können dazu mit Transitionsbedingungen ausgestattet werden. Im Gegensatz zu BPEL (siehe Abschnitt 2.2.4) unterscheidet WSFL explizit Kontrollfluss von Datenfluss. Ein WSFL-Dokument dient zur Verbindung mehrerer Web Services zu einem Flow Model oder Global Model. Das Flow Model beschreibt dabei, wie die Funktionalität eines Verbundes von Web Services im Gesamten zu Nutzen ist. Dabei wird auch eine Reihenfolge für die Aufrufe der einzelnen Web Services vorgegeben. Dies erfolgt durch die explizite Vorgabe von Kontrollfluss und Datenfluss. Das Global Model beschreibt hingegen keinerlei Reihenfolge. Es beschreibt die Interaktionen ähnlich wie XLANG (siehe Abschnitt 2.2.3) als Verknüpfungen von verschiedenen Web Service- Operationen. Ähnlich wie bei XLANG ist somit die Gesamtlogik des Modells nur verteilt dokumentiert. Die WSFL ist in [L + 01] spezifiziert. XLANG Microsofts XLANG stellt eine Erweiterung für WSDL dar, die es erlaubt, die Definition von wsdl:service-elementen mit Verhaltensbeschreibungen anzureichern. Diese enthält dann genaue Definitionen wie und bei welchem Ereignis Nachrichten zwischen Web Services ausgetauscht werden müssen. Dazu werden für einen bestimmten Prozess alle involvierten Web Services bestimmt und jeder Web Services aus dieser Gruppe mit einer Verhaltensbeschreibung ausgestattet. XLANG verfolgt dabei den Ansatz, dass jeder Web Service nur sein eigenes 22