Entwicklung eines Monitoring-Toolszur Unterstützung von parametrisierten WebService Flows

Transkript

1 InstitutfürArchitekturvonAnwendungssystemen Universität Stuttgart Universitätsstraße 38 D Stuttgart DiplomarbeitNr.2388 Entwicklung eines Monitoring-Toolszur Unterstützung von parametrisierten WebService Flows JörgNitzsche Studiengang: Informatik Prüfer: Betreuer: begonnen am: beendet am: Prof.Dr.FrankLeymann M.Sc.Dimka Karastoyanova CR-Klassifikation: D.2.12,D.2.13,H.4.1,H.5.2, H.5.3

2

3 Inhaltsverzeichnis Seite i Inhaltsverzeichnis Inhaltsverzeichnis...i 1 Einleitung Grundlagen Web Services SOAP WSDL UDDI Web Service Flows Workflow Web Service Flow BPEL WS flow Flexibilität Workflowflexibilität WS flow Flexibilität BPEL Spracherweiterungen für Prozessflexibilität Die BPEL Erweiterung <find_bind> Die BPEL Erweiterung <evaluate> Monitoring Abgrenzung Datenbeschaffung Datenpräsentation Anforderungen an die Realisierung Anforderungen an den Monitor Anforderungen an die Engine Umsetzung Beschreibung der ActiveBPEL Engine Engine Architektur Anbindung an den Application Server Anbindung an den Web Service Container... 31

4 Inhaltsverzeichnis Seite ii Business Process Engine Manager Prozesslebenszyklus ActiveBPEL Web Administration Applikation EventFramework Remote Administration Interface Engine Erweiterungen Mögliche Lösungsansätze zum Monitoring Architektur Controller Message Broker Monitor Kommunikationskomponente Prozessverwaltung GUI Use Cases Anmeldung Eventpublishing Aktives Eingreifen in eine Prozessinstanz prompt Bearbeitung Beispielprozess Zusammenfassung und Ausblick Abbildungsverzeichnis...VII Tabellenverzeichnis... IX Abkürzungsverzeichnis... X Literaturverzeichnis... XI Anhang...XV Eidesstattliche Erklärung...XLI

5 1 Einleitung Seite 1 1 Einleitung Web Services als Ausprägung einer serviceorientierten Architektur bieten eine (webbasierte) Infrastruktur, die zur Integration sowohl interner Anwendungen (EAI) als auch unternehmensübergreifender Anwendungen (B2B) genutzt werden kann. Durch die konsequente Nutzung offener Standards und einfacher Protokolle gewährleisten Web Services im Gegensatz zu bisherigen verteilten Anwendungen, dass ausschließlich herstellerunabhängige Produkte entstehen und sämtliche proprietären Elemente entfallen bzw. versteckt werden. Der Fokus von Web Services liegt jedoch nicht nur auf fertigen, isolierten Anwendungen sondern Web Services ermöglichen es weltweit verfügbare einzelne Dienste wieder zu verwenden und sie zu neuen Anwendungen bzw. zu Prozessen zusammenzustellen. Diese Realisierung komplexer Prozesse durch die Orchestrierung einzelner Web Services wird Web Service Flow (WSflow) genannt. Die Anforderungen an Prozesse können sich innerhalb kurzer Zeit sehr schnell ändern, sei es durch neue Gesetzgebung, technische Neuerungen, organisatorische Änderungen oder einfach durch die Prozessanalyse im Rahmen der Prozessoptimierung. Außerdem gilt in vielen Bereichen der Industrie, z.b. im Versicherungswesen, die Formel Prozess = Produkt, die besagt, dass in vielen Firmen das Produkt, das sie verkaufen (z.b. eine Versicherungspolice) dem Prozess gleich ist, durch welchen es hergestellt bzw. bearbeitet wird. Deshalb ist es wichtig, Prozesse sehr schnell an neue Gegebenheiten anpassen zu können, um konkurrenzfähig zu bleiben. Da viele Prozesse Tage, manche auch Jahre dauern, ist es nötig, Prozesse auch zur Laufzeit anpassen und konfigurieren zu können, und nicht nur während des Designs oder beim Deployment in das Workflow Managementsystem (WfMS). Dazu existieren bei den zu WS flows verwandten herkömmlichen Workflows verschiedenste Ansätze, die z.t. auch bei WS flows anwendbar sind. Es fehlt allerdings die Möglichkeit konkrete Instanzen eines Web Services oder sogar die abstrakte Beschreibung des Web Services innerhalb einer Prozessdefinition zur Laufzeit austauschen zu können. In [31] und [30] werden zwei Spracherweiterungen der Sprache BPEL (Business Process Execution Language), ein de facto Standard zur Beschreibung von WSflows, vorgestellt. Diese Spracherweiterungen ermöglichen sowohl die Änderung der abstrakten Beschreibung des Web Services als auch den Austausch der zu verwendenden Instanz zur Laufzeit. Die Integration dieser Konstrukte in die BPEL Engine ActiveBPEL [4] wird in [58] beschrieben. Ziel dieser Arbeit ist es, eine Infrastruktur zu entwerfen und entwickeln, welche es ermöglicht diese durch die beiden Spracherweiterungen parametrisierten

6 1 Einleitung Seite 2 WS flows zu verwalten und zu monitoren sowie eine Interaktive Strategie zur Bestimmung der abstrakten WS Beschreibung zu unterstützen. Deshalb baut sich die Arbeit folgendermaßen auf: Grundlagen Zunächst wird in die den WS flows zugrunde liegenden Technologien, Web Services und Workflow, eingeführt. Danach werden die wichtigsten Merkmale der WS flows anhand eines Vergleichs mit Workflows herausgestellt und die Sprache BPEL vorgestellt. Es folgt ein Überblick über Workflow bzw. WSflowadaptabilität. Als letztes wird auf die Grundsätze des Monitoring eingegangen. Anforderungen Im dritten Kapitel werden die Anforderungen an die Plattform, d.h. an die WSflow Engine und alle zum Betrieb benötigten Komponenten, sowie an die zu realisierende Architektur formuliert. Umsetzung Das Kapitel Umsetzung beschreibt zunächst die ActiveBPEL Engine, auf deren Grundlage die BPEL Erweiterungen implementiert sind. Im Anschluss werden kurz die möglichen Ansätze erläutert und die gewählte Architektur inklusive ihrer Komponenten beschrieben. Schließlich wird die Funktionsweise an Use Cases erläutert. Beispielprozess Anhand eines praktischen Beispiels wird im fünften Kapitel die Verwendung der BPEL Erweiterungen und der Monitor Applikation verdeutlicht.

7 2 Grundlagen Seite 3 2 Grundlagen Im diesem Kapitel werden alle für die Arbeit relevanten Grundlagen geschaffen. Zunächst wird ein Überblick über Web Services, Workflows und WS flows gegeben. Anschließend wird sowohl Workflowadaptabilität als auch WS flowadaptabilität eingeführt und schließlich wird auf die Grundsätze des Monitoring eingegangen. 2.1 Web Services Web Services und serviceorientierte Architekturen sind derzeit sowohl im akademischen Umfeld als auch in der Industrie sehr populär [53]. Diese Popularität begründet sich darauf, dass Forschung und Industrie gemeinsam die offenen Standards für Web Services entwickelt haben [52]. Sie resultieren aus der Entwicklung von Adaptern im Zuge der Enterprise Application Integration (EAI), [52], [7] wurden also entwickelt um Kommunikation zwischen Maschinen in einer heterogenen Umgebung zu ermöglichen [24]. Weil es durch Web Services auch möglich ist über Unternehmensgrenzen hinweg zu kommunizieren kann ein Unternehmen unrentable Dienste auslagern (Outsourcing) und dadurch ein so genanntes virtuelles Unternehmen errichten. Im Extremfall kann ein Unternehmensprozess sogar ausschließlich externe Dienste nutzen. Für Web Services gibt es einige Definitionen, die sich meist nur wenig unterscheiden. Allerdings gibt es keine als einzig richtig anerkannte Definition [24]. Stellvertretend wird hier die Definition vom World Wide Web Consortium (W3C) zitiert [49]: 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 Web related standards. Ein sehr wesentlicher Bestandteil eines Web Services ist seine Schnittstelle [52]. Alle vom Web Service angebotenen Operationen werden in seiner Schnittstellenbeschreibung durch die Kombination von konsumierten und produzierten Nachrichten definiert (siehe Abbildung 1). Dabei ist die Programmiersprache in der die Implementierung erfolgt irrelevant. Web Services sind plattformunabhängig und können wegen ihrer abstrahierenden Funktion auch als Abstraktionsschicht oder virtuelles Komponentenmodell angesehen werden.

8 2 Grundlagen Seite 4 Message Message Message Operation Operation Port Type Business Funktionalität Message Message Operation Port Type Operationen Interface Abbildung 1: Web Service Web Services sind eine Implementierung der Serviceorientierten Architektur (SOA). Die SOA definiert drei Rollen, die jeweils durch einen Web Service realisiert werden können (siehe Abbildung 2). Service Provider: Der Service Provider bietet bestimmte Funktionalitäten an, die er bei einem globalen Verzeichnisdienst registrieren kann. Service Requester: Der Service Requester fragt bei einem Verzeichnisdienst eine bestimmte Funktionalität an, und erhält die Adresse und Binding Informationen eines Services, der diese Funktionalität erfüllt. Anschließend bindet er sich an den gewählten Service und lässt die Funktion dort ausführen und erhält das Resultat der Ausführung. Service Registry: Bei der Service Registry registrieren Service Provider ihre Services, die dann von den Service Requesters angefragt werden. Sie dient also zum Auffinden eines Services im Netzwerk und führt Anbieter und Konsument zusammen.

9 2 Grundlagen Seite 5 Web Service Requestor WSDL Web Service Provider SOAP Service aufrufen SOAP Service registrieren SOAP Service finden Web Service Registry UDDI White Pages YellowPages Green Pages Abbildung 2: SOA mit Web Services Für die Industrie ergeben sich durch die Nutzung einer SOA die nachfolgend aufgeführten Vorteile [25]: Nutzung und Erhaltung von Anwendungsinvestitionen durch Kapselung existierender Funktionen Offene Standards für SOA und Web Services und damit Unabhängigkeit vom Anbieter dieser Services ermöglichen Interoperabilität Kürzere Software Produktzyklen zur Reduzierung von time to market Geringere Kosten und geringere Risiken in Entwicklung und Betrieb Konzentration auf Prozesse und nicht auf Anwendungsprogramme Wiederverwendung von Funktionalität Plattform und Programmiersprachenunabhängigkeit Im Folgenden werden die wichtigsten Basistechnologien, welche Bestandteile von Web Services sind, beschrieben. Zunächst die Nachrichtenarchitektur (SOAP)[46], welche zur Kommunikation zwischen Web Services verwendet werden, dann die Schnittstellenbeschreibung eines Web Service, welche durch die Sprache WSDL (Web Service Definition Language)[48] ausgedrückt wird, und schließlich der Verzeichnisdienst, das Universal Description, Discovery and Integration (UDDI)[41].

10 2 Grundlagen Seite SOAP Ursprünglich stand SOAP als Akronym für Simple Object Access Protocol. Weil in der Spezifikation [46], die momentan in der Version 1.2 vorliegt, allerdings keine Objekte vorkommen, wollte das W3C SOAP umbenennen. Da sich der Begriff allerdings bereits eingebürgert hatte wurde auf die Umbenennung verzichtet [16]. Mittlerweile steht SOAP für sich selbst und beschreibt nicht mehr einfach nur ein Protokoll, sondern bildet ein Framework, welches es ermöglicht, strukturierte, typisierte Nachrichten zwischen zwei Partnern in einem Netzwerk zu versenden und bildet einen de facto Standard für die Kommunikation zwischen Web Services. SOAP definiert: 1. eine standardisierte Struktur der SOAP Nachrichten als ein XML Infoset [50]. 2. ein Prozessmodell welches definiert, wie ein SOAP Knoten die Nachrichten zu verarbeiten hat. Es gibt verschiedene Rollen, die ein SOAP Knoten einnehmen kann. Er kann der ursprüngliche Sender sein, er kann eine Nachricht empfangen und weiterleiten und kann der letztendliche Empfänger sein. Die Menge der Knoten, die auf dem Weg durch das Netzwerk einer Nachricht beteiligt sind, bilden den Nachrichtenpfad. Ein Knoten, der die SOAP Nachricht empfängt und weiterleitet wird Intermediary genannt. SOAP spezifiziert weiterhin ein Binding Framework für das Binding von SOAP Nachrichten an verschiedene Protokolle. Die jeweiligen Spezifikationen, die dem Framework entsprechen, beschreiben wie das Infoset transportiert werden kann ohne Informationen zu verlieren. So beschreibt beispielsweise [47] das Binding von SOAP über HTTP (Hyper Text Transfer Protocol). Dadurch ist es möglich SOAP Nachrichten mit Hilfe von unterschiedlichsten Protokollen auszutauschen. Es ist sogar möglich, dass auf einem Nachrichtenpfad nicht nur ein Protokoll verwendet wird, sondern dass zwischen einzelnen SOAP Knoten unterschiedliche Protokolle zur Anwendung kommen (siehe Abbildung 3). Das ist der wichtigste Unterschied zu herkömmlichen Nachrichtenverarbeitungsmodellen anderer Middlewarestandards.

11 2 Grundlagen Seite 7 SOAP-Nachricht SOAP-Nachricht SOAP-Nachricht ursprünglicher Sender HTTP Intermediary FTP Intermediary JMS letztendlicher Empfänger Abbildung 3: SOAP Nachrichtenpfad Auch Daten, die nicht in XML Notation dargestellt werden können, also Binärdaten, z.b. Bilder oder Videos, können in eine SOAP Nachricht kodiert werden. Dazu wird die Binärinformation gemäß der in IETF RFC 2045 spezifizierten Base64 content encoding scheme in Character umgewandelt [52]. Allerdings ist die Umrechnung sehr aufwendig und die dadurch entstehenden Nachrichten werden sehr groß. SOAP ist nicht zustandsbehaftet und ist ein Ein Weg Paradigma. Andere Nachrichtenaustauschmuster (message exchange patterns) z.b. Request Response müssen als Kombinationen der einzelnen Nachrichten durch die Anwendungslogik realisiert werden. Eine SOAP Nachricht besteht aus einem <envelope>, der die Elemente <header> und <body> enthält (siehe Abbildung 4). <SOAP:Envelope xmlns:soap= <!-- pflicht --> <SOAP:Header> <!-- optional --> </SOAP:Header> <SOAP:Body> <!-- pflicht --> <SOAP:Fault> <!-- optional --> </SOAP:Fault> </SOAP:Body> </SOAP:Envelope> Abbildung 4: SOAP Nachrichtenformat

12 2 Grundlagen Seite 8 Die konkreten Inhalte der Elemente <header> und <body> sind applikationsabhängig und werden nicht weiter spezifiziert, es wird lediglich die Methodik definiert, wie sie aufgebaut sein müssen. SOAP-Header Der SOAP Header ist optional, d.h. es muss kein <header> definiert werden. Er enthält nicht die eigentlichen Nutzdaten sondern kann in den so genannten headerblocks zusätzliche Informationen wie z.b. Anforderungen an Quality of Service (QoS) enthalten. Durch den SOAP Header ist es möglich komplexe Services zu realisieren, bei denen nicht nur der letztendliche Empfänger eine Funktion übernimmt, sondern auch die Intermediaries. Diese können die Informationen in den headerblocks nicht nur interpretieren und daraufhin eine Funktion übernehmen, wie z.b. Logging, sondern sie auch löschen bzw. weitere headerblocks hinzufügen. SOAP-Body Der SOAP Body enthält die Information für den letztendlichen Empfänger der Nachricht. Um sowohl die synchrone als auch die asynchrone Kommunikation unterstützten zu können, werden zwei Modelle, RPC Style (Remote Procedure Call) und Document Style angeboten. In dem optionalen Fault Element kann definiert werden, wie im Fehlerfall (oder in Fehlerfällen) zu verfahren ist WSDL WSDL steht für Web Service Description Language und spezifiziert eine XML Grammatik mit der jeder Entwickler eines Web Services anderen mitteilt, wie der Web Service verwendet werden kann [52]. Die aktuelle Spezifikation von WSDL liegt in der Version 2.0 vor [48]. In einem WSDL Dokument werden alle öffentlich verfügbaren Operationen eines Web Services in Form von zwischen Partnern ausgetauschten Nachrichten, den darin verwendeten Datentypen, dem verwendeten Transportprotokoll, sowie der Adresse unter welcher der Service aufrufbar ist, beschrieben [53]. Die Beschreibung beschränkt sich allerdings auf die Syntax. Um nichtfunktionale Eigenschaften von Web Services zu beschreiben sind andere Ansätze notwendig, beispielsweise WS Policy [13]. Ein WSDL kann auf zwei verschiedene Arten verwendet werden. Als Beschreibung für die Klienten, die den Service nutzen möchten und als Beschreibung eines Standardservices für Entwickler, die den Service implementieren möchten [52]. Ein WSDL Dokument besteht aus sechs Hauptelementen (Abbildung 5), die im Folgenden beschrieben werden [53], [52]:

13 2 Grundlagen Seite 9 <definitions> <!-- Wurzel-Element des WSDL Dokuments --> <types> </types> <!-- Welche Datentypen werden gesendet? --> <message> <!-- Welche Nachrichten werden gesendet? --> </message> <porttype> <!-- Welche Operationen werden unterstützt? --> </porttype> <binding> </binding> <service> </service> <!-- Wie werden die Nachrichten gesendet? --> <!-- Wo befindet sich der Service? --> </definitions> Abbildung 5: WSDL Spezifikation definitions Das <definitions> Element ist das Wurzel Element des WSDL Dokuments. In ihm werden die im Dokument verwendeten Namensräume, der Name des WSDLs, sowie die folgenden Elemente und der Namensraum, dem sie zugeordnet werden, der targetnamespace, definiert. types Innerhalb des <types> Elements werden alle für das Dokument, also alle innerhalb der Nachrichten verwendeten Datentypen definiert. Hierzu spezifiziert WSDL keine eigene Sprache, sondern erlaubt es andere Sprachen zur Definition der Datenstrukturen zu verwenden. Am weitesten verbreitet ist die Verwendung des W3C Typensystems XML Schema [51]. message Im <message> Element werden alle Nachrichten beschrieben, welche der Service zur Kommunikation benötigt. Es sind jeweils einzelne Nachrichten, also entweder ein einzelner Request oder ein einzelner Response. Die Nachrichten

14 2 Grundlagen Seite 10 können aus mehreren <part> Elementen bestehen, welche einen bestimmten Typ haben und den jeweiligen Parametern bzw. Rückgabewerten entsprechen. porttype Im <porttype> Element werden Operationen durch die Kombination von Nachrichten definiert. Dabei können mehrere Operationen für einen porttype definiert werden. Es werden vier verschiedene Kommunikationsmuster unterstützt [52]: One way: Ein Client schickt einem Service eine Nachricht, der nicht antwortet. Notification: Der Service schickt dem Client eine Nachricht und erhält keine Antwort. Request response: Ein Client fragt beim Server an, und dieser antwortet ihm. Solicit response: Der Server fragt beim Klienten nach und erhält eine Antwort. binding Das <binding> legt fest auf welche Art und Weise die Informationen über das Netzwerk übermittelt werden, also welches Protokoll zur Anwendung kommt. Außerdem wird beschrieben wie die Informationen in die Nachricht kodiert werden müssen. Da die einzelnen bindings protokollspezifisch sind, sind sie nicht mehr teil von WSDL. service Im <service> Element ist unter den <port> Elementen im <address> Element beschrieben, wo der Service zu finden ist. Außerdem ist festgelegt, mit welchem binding der Service auf diesem port aufzurufen ist UDDI UDDI steht für Universal Description, Discovery and Integration [41]. Es ist ein logisch zentrales aber physikalisch verteiltes globales Onlineverzeichnis für Services. Es bietet eine Menge von Web Services an, die es zum einen Entwicklern ermöglichen ihre Web Services zu registrieren und zum anderen potentiellen Nutzern die Möglichkeit geben den Web Service zu finden, der ihren Anforderungen am besten genügt. Die in einem UDDI vorhandenen Daten lassen sich in drei Kategorien, die durch unterschiedliche Datenstrukturen repräsentiert werden, einteilen, die nun kurz beschrieben werden

15 2 Grundlagen Seite 11 White Pages In den so genannten White Pages befinden sich Informationen über die Anbieter von Web Services. Diese Informationen werden in businessentity Objekten gespeichert. Zu den Informationen gehören u.a. Name, Adresse und weitere Kontaktinformationen wie Telefonnummer oder Adressen. Zudem eine kurze Beschreibung des Unternehmens. Yellow Pages Yellow Pages klassifizieren die Unternehmen bzw. die angebotenen Web Services beispielsweise in verschiedene Branchen oder Produkte. Für die Klassifizierung werden businessservice Objekte verwendet. Green Pages Die Green Pages beschreiben in bindingtemplate Objekten die Art, wie auf die Services zugegriffen werden kann. Dazu enthalten sie Informationen über die Endpoint Reference des Services, und das zu verwendende Protokoll. Diese Informationen entsprechen dem im WSDL definierten binding. Da für einen Web Service verschiedene bindings implementiert werden können, kann das UDDI für einen businessservice mehrere bindingtemplates enthalten. [42] beschreibt das optimale Verfahren ein WSDL, d.h. die syntaktische Beschreibung eines Web Services, in einem UDDI abzubilden. Allerdings wurde noch keine Einigkeit darüber erzielt, wie die semantische Beschreibung eines Web Services exakt auszusehen hat und wie diese Informationen in einem UDDI abgebildet werden. Es existieren also keine expliziten Datenstrukturen zur Modellierung von Semantik. Es besteht jedoch die Möglichkeit nichtfunktionale Informationen in Form von WS Policy [13] an die syntaktische Beschreibung anzuhängen [15]. Außerdem ist es möglich in einem UDDI beliebig viele unterschiedliche Taxonomien einzuführen und die Web Services so zu klassifizieren. Dadurch ist auch eine semantische Klassifizierung der Web Services möglich. 2.2 Web Service Flows Web Service Flows (WS flows) sind ein Ansatz zur Komposition von Web Services. Ein WS flow kombiniert Web Services anhand eines prozessbasierten Ansatzes; WS Kompositionen können auch ohne die Anwendung des oben genannten Ansatzes erstellt werden. Da WS flows eine Kombination von Technologien ist, den bereits im letzten Kapitel beschriebenen Web Services und Workflows, wird zunächst kurz die Workflow Technologie vorgestellt und anschließend durch den Vergleich der beiden Technologien wichtige Eigenschaften der WS flows herausgestellt. Danach wird eine kurze Einführung in die WS flow Sprache BPEL gegeben.

16 2 Grundlagen Seite Workflow Workflows sind organisationsweite arbeitsteilige Prozesse, die aus einzelnen Aktivitäten aufgebaut sind, die jeweils vom Prozess in Abhängigkeit zueinander gebracht werden. Dabei muss festgelegt werden, welche Arbeitsschritte seriell bzw. parallel ausgeführt werden können. Die Workflow Management Coalition definiert Workflows wie folgt [56]: The automation of a business process, in whole or part, during which documents, information or tasks are passed from one participant to another for action, according to a set of procedural rules. Die anfallenden Aktivitäten innerhalb eines Workflows können von Personen oder auch von Software Systemen durchgeführt, koordiniert und überwacht werden. Ein Workflow Management System übernimmt die aktive Steuerung dieser arbeitsteiligen Prozesse. Es stellt sicher, dass die Prozesse korrekt abgearbeitet werden. Änderungen eines Prozesses oder des Workflows müssen so schnell wie möglich im Workflow Management System abgebildet werden. Workflow Management Systeme werden von der WfMC folgendermaßen definiert [56]: A system that defines, creates and manages the execution of workflows through the use of software, running on one or more workflow engines, which is able to interpret the process definition, interact with workflow participants and, where required, invoke the use of IT tools and applications. Aus Unternehmenssicht kann die Workflow Technologie bereits auf eine längere Historie zurückblicken [35][33]. In den späten 80er Jahren dem so genannten document routing age wurde Workflow verwendet, wenn Dokumente verschiedene Stationen durchlaufen mussten um sie z.b. von verschiedenen Personen unterschreiben bzw. überprüfen zu lassen. Anwendung fand das document routing vor allem in so genannten Papierfabriken, wie Banken oder Versicherungsunternehmen. Später im people facing age ging es nicht nur um die Verwaltung von Dokumenten, sondern auch um die die Ausführung von kleinen Applikationen oder Funktionen in bestimmter Reihenfolge. Da diese Anwendungen Parameter brauchen, wurden in und out Container für sie bereitgestellt, und damit ein Datenfluss modelliert. Außerdem können mit Hilfe der in den Containern enthaltenen Variablenwerte Entscheidungen über den weiteren Verlauf des Prozesses gefällt und somit also ein Kontrollfluss festgelegt werden [33]. Da man jetzt große Prozesse unterstützen kann rückt in den frühen 90ern die Workflow Technologie in den Fokus des Business Process Reengineerings (BPR). Dieses beschäftigt sich mit der Optimierung von Prozessen, um Kosten zu sparen. Die Optimierung und damit die Beschleunigung der Prozesse wird

17 2 Grundlagen Seite 13 durch Umorganisation eines Workflows, z.b Parallelisierung, und durch Monitoring erreicht. Mitte der 90er Jahre im production age werden Workflow Management Systeme aufgrund ihrer Vorteile zunehmend in den Unternehmen produktiv eingesetzt. Wegen der Menge der durch ein Workflow Management System abgebildeten und gesteuerten Geschäftsprozesse, werden Workflow Management Systeme immer wichtiger und müssen nun einen bestimmten Quality of Service (QoS) bieten, z.b. hohe Verfügbarkeit, Robustheit und Skalierbarkeit. Ende der 90er im so genannten automation age gerät die Integration von Anwendungen in den Fokus der Weiterentwicklung von Workflow Management Systemen. Ziel der Automatisierung ist es die Kosten zu optimieren und die Prozesslaufzeiten noch weiter zu minimieren. Deshalb sollen mehr und mehr Aktivitäten von Software Systemen übernommen werden. Sowohl bestehende Anwendungen als auch neu geschriebene Komponenten sollen in einen Workflow integrierbar sein. Dabei werden zunächst organisatorische Grenzen innerhalb eines Unternehmens überschritten (EAI) und später auch die Unternehmensgrenzen selber (B2B). Um diese Entwicklung zu unterstützen werden in dieser Zeit große Anstrengungen unternommen, Workflow Management Systeme sowie das Meta Modell zur Beschreibung von Workflows zu standardisieren. Ein Ergebnis dieser Anstrengungen ist das Workflow Reference Model der Workflow Management Coalition [55], welches allerdings kein Standard für ein Meta Modell zur Beschreibung von Workflows darstellt, sondern den Aufbau eines Workflow Management Systems sowie verschiedene Schnittstellen beschreibt. Die Vereinheitlichung der Meta Modelle zur Beschreibung von Workflows wird nicht erreicht. Als neueste Entwicklung im Bereich Workflow stellt sich die Kombination von Workflow Technologie und Web Services heraus; diese Kombination ist unter den Namen WS flow, WS basierte Prozesse, WS Kompositionen, Prozesse, und WS Orchestrierung bekannt.

18 2 Grundlagen Seite Web Service Flow Der Begriff Web Service Flow oder auch Web Service Orchestrierung beschreibt einen Geschäftsprozess als Kombination von Web Services, die in einer bestimmten Reihenfolge abgearbeitet werden. Dabei wird der Prozess aus der Sicht eines beteiligten Geschäftspartners kontrolliert [43]. Im Gegensatz dazu beschreibt Web Service Choreographie das Zusammenspiel aller beteiligten Partner, d.h. die öffentliche Sicht auf eine koordinierte Interaktion zwischen Partnern wird dargestellt bzw. ausgedrückt. Im Folgenden werden anhand eines Vergleichs zwischen herkömmlichen Workflows und WS flows die wesentlichen Eigenschaften von WS flows aufgezeigt. Dimensionen In traditionellen Workflows werden drei Dimensionen unterschieden (siehe Abbildung 6). Der Kontrollfluss und der Datenfluss bilden gemeinsam die was Dimension. Während der Kontrollfluss angibt welche Aktivitäten wann durchgeführt werden beschreibt der Datenfluss wie und welche Daten zwischen Aktivitäten ausgetauscht werden. Dies gilt ebenfalls für WS flows. Allerdings wird in BPEL der Datenfluss nicht explizit modelliert sondern wird implizit durch den Zugriff der einzelnen Aktivitäten auf global sichtbare Container realisiert. Die womit Dimension beschreibt bei WS flows durch welchen Web Service eine Aktivität ausgeführt wird, sofern es sich um eine Aktivität handelt, die Interaktion mit einem Web Service erfordert. In traditionellen Workflows sind jedoch nicht nur Web Services als auszuführende Komponente denkbar. Eine Aktivität kann durch unterschiedlichste Applikationen realisiert werden. Auch die Durchführung einer Aktivität ohne IT Unterstützung, beispielsweise mit Papier und Bleistift, ist denkbar. Die Einschränkung bei WS flows auf Web Services als auszuführende Komponente hat auch Auswirkungen auf die dritte Dimension, die wer Dimension. Da Web Services ausschließlich von Computern ausgeführt werden, ist es im Gegensatz zu traditionellen Workflows nicht möglich, dass auch Mitarbeiter eines Unternehmens Aktivitäten ausführen. WS flow Management Systeme brauchen also keine Informationen über Organisationsstrukturen. Die Interaktion von WS flows mit einem Benutzer ist nur möglich, wenn ein Web Service Benutzereingaben erlaubt bzw. erfordert. Ein erster Ansatz Interaktionen mit Benutzern zu ermöglichen wurde vor kurzem in [32] beschrieben.

19 2 Grundlagen Seite 15 Workflow WS-flow was was wer womit womit Abbildung 6: Dimension von Workflow und Web Service Flow Programmieren im Großen und im Kleinen Durch Workflow Management Systeme und auch durch WS flow Management Systeme wird eine strikte Trennung der Prozesslogik und der Funktionen welche die Logik unterstützen eingeführt. Damit nach der Datenunabhängigkeit, welche durch Datenbankmanagementsysteme gewährleistet wird, nun auch die Flussunabhängigkeit, und somit eine weitere Entkopplung der Prozess Logik von den Anwendungen erreicht (siehe Abbildung 7). Anwendung Datenunabhängigkeit DBMS Flußunabhängigkeit WfMS Applicationserver DBMS Abbildung 7: Flussunabhängigkeit Durch die bereits angesprochene strikte Trennung von Logik und Funktionen kommt es zu einer 2 Teilung in der Entwicklung von Anwendungen. Dies gilt ebenfalls sowohl für herkömmliche Workflows als auch für WS flows.

20 2 Grundlagen Seite 16 Einerseits müssen Prozesse von speziell dafür ausgebildeten Fachleuten in entsprechenden Modellierungstools modelliert werden. Andererseits müssen die Komponenten, welche die Aktivitäten realisieren, durch IT Spezialisten implementiert werden. Bei WS flows beschränkt sich dies auf die Entwicklung von Web Services, oder auf die Bereitstellung von Funktionen als Web Services. Binding Bei Workflows werden bei der Prozessdefinition bereits die konkreten Implementierungen, die eine Aktivität zu erledigen haben, festgelegt. Bei Verwendung von Web Services reicht es aus während des Prozessdesigns lediglich die Schnittstellenbeschreibung festzulegen, um die auszuführende Funktion zu bestimmen. Zum Festlegen einer konkreten Instanz eines Web Services gibt es 4 verschiedene Strategien [52]: Statisches Binding während des Designs Statisches Binding während des Deployments Dynamisches Binding unter Verwendung von Lookups Dynamisches Binding durch passed in Endpoints BPEL Die Business Process Execution Language for Web Services (BPEL4WS oder kurz BPEL) wurde aus zwei konkurrierenden Sprachen zur Web Services Komposition, der Web Service Flow Language (WSFL) von IBM [34] und XLANG von Microsoft [45] entwickelt und gilt als de facto Standard zur Beschreibung von WS flows [52]. Die folgende kurze Beschreibung stützt sich auf die aktuell vorliegende Spezifikation BPEL4WS v1.1 [17]. Ein BPEL Prozess besitzt eine WSDL Beschreibung und kann von anderen Prozessen oder Aktivitäten als Web Service verwendet werden. Er beschreibt einen Prozess aus der Sicht eines einzigen Partners eines Geschäftsprozesses und wird implizit durch den Aufruf eines anderen Partners gestartet. Möglichkeiten zum Stoppen und Fortsetzen eines Prozesses sind im Meta Modell nicht vorgesehen.