Fachbereich Informatik

Save this PDF as:
 WORD  PNG  TXT  JPG

Größe: px
Ab Seite anzeigen:

Download "Fachbereich Informatik"

Transkript

1 Diplomarbeit Strategien zur Prozessorchestrierung und Workflow-Integration in Web-Applikationen Andreas Kümpel Dezember 2004 Betreuer: Prof. Dr. Paul Müller Dipl.-Wirtsch.-Ing. Jochen Müller Fachbereich Informatik AG Integrierte Kommunikationssysteme Universität Kaiserslautern Postfach Kaiserslautern

2

3 Erklärung Hiermit versichere ich, dass ich die vorliegende Diplomarbeit selbständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel verwendet habe. Kaiserslautern, den (Andreas Kümpel)

4

5 Abstract Mit dem zunehmenden Einsatz des Electronic Business werden Geschäftsprozesse und Anwendungssysteme über die Grenzen eines Unternehmens geöffnet und mit denen anderer Geschäftspartner kombiniert. Die Business Process Execution Language for Web Services ermöglicht es, Geschäftsprozesse zu beschreiben und einzelne Web Services miteinander zu kombinieren, um durchgängige Geschäftsprozesse sowohl auf Anbieter- als auch auf Kundenseite zu unterstützen. In dieser Arbeit soll ein bestehendes webbasiertes Informationsportal weiter entwickelt werden, um so die Abarbeitung von Geschäftsprozessen zu unterstützen. Als Realisierungsbeispiel dient ein Prozess aus der Flächennutzungsplanung.

6

7 Strategien zur Prozessorchestrierung und Workflow-Integration in Web-Applikationen Inhaltsverzeichnis 1. Einleitung Ausgangslage und Problemstellung Ziel der Diplomarbeit Aufbau der Diplomarbeit Grundlagen Portale Geschäftsprozesse, Workflows & Workflow-Management Web Services Architektur Der Dienst-Anbieter Der Dienst-Konsument Die Gelben Seiten WSDL Business Process Execution Language Aufbau eines BPEL-Prozesses Interaktion Partner Links Partner Link Types Business Partner Kommunikation Scopes Fehlerbehandlung Kompensation Variablen Ausdrücke Korrelationen Aktivitäten Basisaktivitäten VII

8 Inhaltsverzeichnis Strukturelle Aktivitäten Nebenläufiger Ablauf Synchronisation Übergangsbedingungen Ereignisse BPEL4WS-Implementationen IBM (alphaworks) BPWS4J Oracle BPEL Process Manager ActiveBPEL FNP-Implementation KLinform-Framework Flächennutzungsplanung Teilprozess Persistente Datenhaltung FNP-Datenbankschema Erweiterung der KLinform-Relationen Architektur des Systems Web-Frontend Web Services BPEL-Prozess WSDL-Schnittstelle BPEL-Dokument Zusammenfassung und Ausblick Anhang Installation AXIS Installation BPWS4J Installation FileUpload Datenbank VIII

9 Strategien zur Prozessorchestrierung und Workflow-Integration in Web-Applikationen Literaturverzeichnis Abbildungsverzeichnis IX

10 Inhaltsverzeichnis X

11 Strategien zur Prozessorchestrierung und Workflow-Integration in Web-Applikationen 1. Einleitung Der erste Abschnitt der Einleitung beschäftigt sich mit der Ausgangslage und der Problemstellung des Themas dieser Diplomarbeit. Im zweiten Abschnitt wird das Ziel dieser Arbeit vorgestellt. Abschließend erfolgt die Beschreibung des Aufbaus der Diplomarbeit. 1.1 Ausgangslage und Problemstellung Das Electronic Business führt zu einer erheblichen Umgestaltung von Markt- und Wertschöpfungsstrukturen. Die verteilte Struktur und die große Verfügbarkeit des Internets erlauben eine Rekonfiguration von Wertschöpfungsketten. Geschäftsprozesse und Anwendungssysteme werden über die Grenzen eines Unternehmens geöffnet und mit denen anderer Partner kombiniert [West04]. Ein Geschäftsprozess kann als Folge von zusammenhängenden Aktivitäten betrachtet werden. Er bildet die Basis der Wertschöpfung sowohl für das Unternehmen als auch für den Kunden; Kundenorientierung, Durchlaufzeit, Reaktionsschnelligkeit und Flexibilität sind dabei die Zielgrößen eines Geschäftsprozesses [Voig03]. Um die einzelnen Aktivitäten eines unternehmensübergreifenden Geschäftsprozesses zu realisieren, bietet sich der Einsatz von Web Services an. Der große Vorteil von Web Services besteht in der Integrationsfähigkeit in bestehende Systeme. Die Business Process Execution Language for Web Services ermöglicht es, Geschäftsprozesse zu beschreiben und einzelne Web Services miteinander zu kombinieren, um durchgängige Geschäftsprozesse sowohl auf Anbieter- als auch auf Kundenseite zu unterstützen [West04]. Viele Unternehmen besitzen bereits Mitarbeiterportale oder Informationsportale, über die sie den Kunden Dienstleistungen und Informationen anbieten, über die aber auch Mitarbeiter vorhandene Unternehmensinformationssysteme verwenden. Es bietet sich also an, eine bereits bestehende Infrastruktur zu verwenden, um den Beteiligten eines Geschäftsprozesses Zugriff auf den Prozess selber zu ermöglichen. 11

12 Einleitung 1.2 Ziel der Diplomarbeit Das Ziel dieser Arbeit ist es, ein bestehendes webbasiertes Informationsportal zu einem Prozessportal weiter zu entwickeln, um so die Abarbeitung von Geschäftsprozessen zu unterstützen. Als Informationsportal dient das Framework KLinform, das an der Technischen Universität Kaiserslautern in der Arbeitsgruppe Integrierte Kommunikationssysteme zum modularen Aufbau von Web-Applikationen entwickelt wurde. Als Realisierungsbeispiel dient ein Teilprozess aus der Flächennutzungsplanung. Das Portal soll entsprechend der unterschiedlichen beteiligten Rollen eine Web-Oberfläche zur Abarbeitung des Teilprozesses zur Verfügung stellen. Das Management dieses Teilprozesses soll mit der Sprache Business Process Execution Language for Web Services (BPEL4WS) realisiert werden, die einzelnen Komponenten des Prozesses als Web Services. 1.3 Aufbau der Diplomarbeit Neben dieser Einleitung gliedert sich die Arbeit in vier weitere Kapitel sowie einen Anhang. Im folgenden zweiten Kapitel werden die Grundlagen von Geschäftsprozessen, Web-Portalen und Web Services gelegt. Dabei wird versucht, eine klare Begriffsabgrenzung vorzunehmen und die verwendeten Technologien entsprechend einzuordnen. Kapitel 3 befasst sich detailliert mit der Business Process Execution Language for Web Services (BPEL4WS). Anhand von Beispielen werden alle Elemente von BPEL4WS ausführlich vorgestellt und beschrieben. Da die Sprache BPEL4WS seit mehr als zwei Jahren spezifiziert ist, existieren mittlerweile eine Reihe von Implementationen, die die Ausführung von mit BPEL4WS verfassten Geschäftsprozessen ausführen können. Im zweiten Abschnitt des dritten Kapitels werden einige bekannte BPEL4WS-Implementationen vorgestellt. Die Beschreibung der Einbettung des Teilprozesses aus dem Bereich Flächennutzungsplanung, kurz FNP, in das KLinform-Framework steht im Mittelpunkt von Kapitel 4. Zu Beginn erfolgt eine kurze Beschreibung des KLinform-Frameworks und des zu realisierenden Teilprozesses. Anschließend erfolgt ein kleiner Exkurs in den Bereich der FNP. Nach einer Beschreibung des zu realisierenden FNP-Teilprozesses, wird der im Rahmen 12

13 Strategien zur Prozessorchestrierung und Workflow-Integration in Web-Applikationen dieser Diplomarbeit entwickelte Prototyp zur rechnerunterstützten Ausführung des Teilprozesses vorgestellt. Das fünfte und letzte Kapitel beinhaltet eine kurze Zusammenfassung dieser Arbeit sowie einen Ausblick. Im Anhang befinden sich Anleitungen und wichtige Hinweise zur Installation der Software, die bei dem in Kapitel vier vorgestellten Prototyp zur Realisierung verwendet wurden. 13

14 Einleitung 14

15 Strategien zur Prozessorchestrierung und Workflow-Integration in Web-Applikationen 2. Grundlagen Im zweiten Kapitel werden die Grundlagen von Geschäftsprozessen näher erläutert. Dabei wird versucht, klare Begriffsabgrenzungen und Definitionen vorzunehmen und die verwendeten Technologien entsprechend einzuordnen. Im ersten und zweiten Abschnitt werden die im Zusammenhang mit Geschäftsprozessen verwendeten Begriffe kurz erklärt. Im dritten Abschnitt wird die verwendete Technologie der Web Services vorgestellt, die bei der Realisierung des Prototyps verwendet wurde. 2.1 Portale Die im Laufe der Zeit in Unternehmen typischerweise entstandene Applikationslandschaft ist dadurch gekennzeichnet, dass häufig dedizierte Informationssysteme für die einzelnen Bereiche eines Unternehmens (Finanzbuchhaltung, Materialwirtschaft, etc.) entwickelt wurden. Oftmals werden redundante Dateninformationen parallel in den unterschiedlichen Systemen gehalten. Besonders im Bereich der Wartbarkeit weisen diese dedizierten Systeme dadurch große Nachteile auf. Anfang der 90er Jahre wurden diese Nachteile durch so genannte Querschnittsysteme abgefangen, Systeme die die einzelnen dedizierten Informationssysteme miteinander verbinden. Portale lassen sich zu diesen Querschnittsystemen zählen. Es handelt sich dabei um Anwendungstypen, die das Internet als Kommunikations- und insbesondere als Vertriebsmedium erschließen und sich stärker als die traditionellen Applikationen an den Geschäftsprozessen und den Kunden orientieren. Allgemein definiert ist ein Portal eine Web- Anwendung, in der Inhalte, Dienste und Funktionen integriert werden [ScWi02]. Der Begriff des Portals im Bereich Internet hat sich im Laufe der Zeit gewandelt. Wurde zu Beginn bereits eine einfache Suchmaschine als Portal bezeichnet, so versteht man mittlerweile unter dem Begriff interaktive Anwendungen, die u. a. als Kommunikationsplattformen dienen, sowohl innerhalb des Unternehmens zwischen den eigenen Abteilungen und Angestellten als auch gegenüber Geschäftspartnern oder Kunden. Es hat also eine Entwicklung vom Informationsportal hin zum Geschäftsprozessportal statt gefunden. Üblicherweise verschafft dabei ein Webbrowser-basiertes Frontend den Zugang zu unterschiedlichen Backend-Systemen [ScWi02]. 15

16 Grundlagen Portale lassen sich auf unterschiedliche Arten klassifizieren. Die Grenzen zwischen diesen Arten sind in der Praxis jedoch oft fließend. Im Folgenden sind einige dieser Arten aufgeführt (in Anlehnung an [Spar02]): Branchenportale Branchenportale bilden einen Anlaufpunkt im Internet zu Themen einer bestimmten Branche. Neben den Diensten einzelner Anbieter werden dem Besucher hier oft unternehmensübergreifende Beratungen, Marktplätze oder Benutzerforen angeboten. Kundenportale Einzelne Unternehmen bieten dem Kunden über spezielle Kundenportale die Möglichkeit, Daten und Dienste zu den angebotenen Produkten und Dienstleistungen in Anspruch zu nehmen. Mitarbeiterportale Diese Art von Portalen bietet einen ortsunabhängigen Zugang zu den betriebsinternen Daten und Systemen eines Unternehmens für die Mitarbeiter. Regionale Portale Regionale Portale (oder auch Informationsportale) bieten oft branchenübergreifende Dienste an. Angefangen von Verzeichnissen aller in der Region vorhandenen Unternehmen oder Dienstleistern, bis hin zu örtlichen Bekanntmachungen oder Neuigkeiten. Das in Kapitel vier vorgestellte Portal KLinfom gehört zu der letzten Kategorie. Der Trend gerade bei Kunden- oder Mitarbeiterportalen geht dazu hin, die offerierten Dienste mit existierenden Geschäftsprozessen, zugrunde liegenden Unternehmensinformationssystemen und Anwendungen zu integrieren [Spar02]. 16

17 Strategien zur Prozessorchestrierung und Workflow-Integration in Web-Applikationen 2.2 Geschäftsprozesse, Workflows & Workflow-Management Im Bereich der Geschäftsprozessmodellierung und des Workflow-Managements wurden insbesondere durch die Workflow Management Coalition (WfMC) versucht, mittels Standardisierungen eindeutige Definitionen für die relevanten Begriffe zu finden [Kühb02]. In der Literatur sind jedoch immer noch unterschiedliche Definitionen von Prozessen, Geschäftsprozessen, Workflows und Workflow-Management zu entdecken. In diesem Abschnitt soll deshalb versucht werden, Begriffsdefinitionen zu bestimmen, die eine gewisse Akzeptanz gefunden haben Geschäftsprozesse In der Literatur wird oft nicht genau zwischen den Begriffen Prozess und Geschäftsprozess unterschieden [VoBe96]. Zweifellos umfasst ein Prozess eine Kombination von Funktionen oder Aktivitäten die sowohl von Menschen als auch von Maschinen oder zumindest maschinen-gestützt durchgeführt werden können [Klat02]. Geschäftsprozesse sind ein Spezialfall von Prozessen, bei denen betriebswirtschaftlich relevante Objekte in den Prozess mit eingebunden sind. Ein Geschäftsprozess ist eine inhaltlich abgeschlossene zeitliche und sachlogische Abfolge von Funktionen oder Aktivitäten, die zur Bearbeitung eines betriebswirtschaftlich relevanten Objektes notwendig ist. Dieses Objekt prägt den Geschäftsprozess, weitere Objekte können in diesen Prozess einfließen. Geschäftsprozesse weisen zudem i. d. R. eine Schnittstelle zu externen (Markt-) Partnern auf [VoBe96]. Bei diesen Objekten kann es sich, neben materiellen Dingen, wie hergestellte Ware, auch um Informationsobjekte, wie Rechnungen oder Dokumente handeln. Ein typisches Beispiel für einen Geschäftsprozess ist die Abarbeitung einer Rechnung. Sie beginnt mit dem Rechnungseingang und führt über die Funktionen Rechnungsprüfung und Rechnungsbuchung bis zum Rechnungsausgleich [Gali03]. 17

18 Grundlagen Dieses Beispiel zeigt, dass an einem Geschäftsprozess mehrere Personen und Informationssysteme beteiligt sein können, eventuell auch mehrere externe Unternehmen. Im Bereich der Geschäftsprozesse und Workflows fallen zunehmend auch die Begriffe Orchestration und Choreography, besonders im Zusammenhang mit Web Services (siehe Kapitel 2.3), die einzelne Funktionen oder Aktivitäten eines Geschäftsprozesses realisieren können [MiMM03]. Orchestration bezieht sich auf einen ausführbaren Geschäftsprozess, der mit geschäftsinternen und -externen Web Services interagiert und beschreibt, wie diese Web Services miteinander interagieren können. Darin ist neben der Business Logik auch die Ausführungsreihenfolge der Interaktionen enthalten. Während Orchestration den gesamten Ablauf beschreibt, so beschreibt die Choreography lediglich den Nachrichtenaustausch zwischen den einzelnen Web Services und dessen Reihenfolge [Pelt03] Workflows & Workflow-Management Die Workflow Management Coalition definiert einen Workflow in etwa wie folgt [Kühb02]: Ein Workflow ist die Automation eines gesamten Geschäftsprozesses oder nur eines Teils, bei dem Dokumente, Informationen oder Aufgaben von einem Beteiligten zu einem anderen übergeben werden, um gewissen Aktionen durchzuführen, entsprechend vorgegebenen (Ablauf-) Regeln. Das heißt ein Workflow beinhaltet die rechnergestützte Ablauforganisation von Geschäftsprozessen durch ein Software-System [Gali03]. Die Technologie dazu heißt Workflow-Management. Das Software-System, das diese Unterstützung leistet, heißt Workflow-Management-System. Es ist ein System, dass Workflows komplett definiert, verwaltet und ausführt. 18

19 Strategien zur Prozessorchestrierung und Workflow-Integration in Web-Applikationen Im Gegensatz zu EAI-Systemen (Enterprise Application Integration), bei denen vollautomatisierte Prozesse im Vordergrund stehen, konzentrieren sich Workflow- Management-Systeme auf Arbeitsabläufe, bei denen Benutzerinteraktionen erforderlich sind [BoFL04]. Im Zusammenhang mit Workflows wird als Technologie oft die in Kapitel 3 ausführlich behandelte Sprache Business Process Execution Language for Web Services (BPEL4WS oder kurz BPEL) erwähnt. Doch BPEL stellt weder ein Workflow-Management-System dar, noch kann es ganze Workflows modellieren. Mit BPEL kann lediglich ein Teil eines Workflows realisiert werden, d. h. BPEL kann auch nur ein Teil eines größeren Workflow-Management- Systems sein, da BPEL für den Benutzer lediglich eine Schnittstelle bietet. Das Frontend, also die Oberfläche oder das Programm, mit dem der Benutzer auf einen mit BPEL erstellten Geschäftsprozess zugreifen kann, ist nicht in dieser Sprache enthalten, ebenso wenig wie ein durch Web Services realisierbares Backend. Die Business Process Execution Language for Web Services ist also vielmehr ein Mittel, um beispielsweise ein Portal und Web Services miteinander zu einem Workflow-Management-System zu verbinden und dabei die Web Services zu orchestrieren. 2.3 Web Services Die Bedeutung und die Verbreitung von Web Services haben in den vergangenen Jahren erheblich zugenommen. Im Zuge der immer stärkeren Vernetzung von Rechnern steigt der Bedarf an lose gekoppelten und verteilten Anwendungen. Web Services bieten sich an dieser Stelle an. Web Services sind eine relativ neue Technologie, auch wenn es sich dabei nicht wirklich um eine neue Erfindung handelt. Man nehme zwei Technologien, die erprobt und ausgereift sind, füge sie (mit einigen Extras) zusammen, kupfere dabei bei Middleware ab und gebe den Ganzen schließlich einen Eindrucksvollen Namen: Web Services [Lang03]. Bei den beiden erprobten Technologien handelt es sich um XML (Extended Markup Language) und RPC (Remote Procedure Call). Die Vorteile von Web Services liegen in der Unabhängigkeit von Programmiersprachen, da als Austauschformat der Daten XML verwendet wird, und in der Möglichkeit der losen Kopplung über ein Netz (LAN, WAN oder Internet). Unter Web Services versteht man allgemein Applikationen, die ihre Dienste über ein Web zur Verfügung stellen [Lang03]. Die Clients, die den Dienst der Applikation in Anspruch nehmen, kommunizieren mit dem Web Service über das auf XML basierende SOAP- 19

20 Grundlagen Protokoll. Das Trägerprotokoll kann dabei beliebig gewählt werden, wobei sehr häufig das weit verbreitete HTTP-Protokoll (HyperText Transfer Protocol) [BFG+99] verwendet wird. Die Standardisierungsorganisation W3C definiert Web Services wie folgt: Ein Web Service ist ein Softwaresystem, das durch eine URI identifiziert wird und dessen öffentliche Schnittstellen mit XML definiert und beschrieben werden. Die Definition des Web Service kann durch andere Softwaresysteme ermittelt werden. Diese Softwaresysteme können mit dem Web Service in einer Art und Weise interagieren, die in seiner Definition festgelegt wurde, und dabei XML-basierte Nachrichten austauschen, die von Internet-Protokollen transportiert werden. [CFNO02] In den beiden folgenden Abschnitten (2.3.1 und 2.3.2) soll nun kurz der Aufbau von Web Services erläutert werden, wobei ein Schwerpunkt auf die Beschreibung der Web Services durch WSDL (Web Service Description Language) gelegt wird, da WSDL auch zur Beschreibung von Geschäftsprozessen von der Sprache BPEL4WS verwendet wird. Auf detaillierte Erklärungen zum Aufbau zu Web Services und des SOAP-Protokolls wird an dieser Stelle verzichtet und auf [Lang03] und [Lins03] verwiesen Architektur Bei der Web Service-Architektur lassen sich drei unterschiedliche Rollen vergeben [Lang03]: Zum einen der Dienst-Anbieter, der Dienst-Konsument und die Gelben Seiten Der Dienst-Anbieter Der Dienst-Anbieter bietet eine Dienstleistung an, beispielsweise die Lieferung der Aktienkurse in Echtzeit. Der Dienst selber wird dabei als Web Service angeboten. Damit später dieser angebotene Dienst auch von einem Konsumenten problemlos in Anspruch genommen werden kann, muss dieser Dienst in einer standardisierten Form beschrieben werden. Der Standard zur Beschreibung von Web Services ist WSDL und wird in Kapitel näher erläutert. Die WSDL-Beschreibung ist somit vergleichbar mit der Interface Description Language (IDL) von klassischen Middleware-Technologien [Lang03]. 20

21 Strategien zur Prozessorchestrierung und Workflow-Integration in Web-Applikationen Der Dienst-Konsument Als Dienst-Konsumenten, oder auch Client, werden all diejenigen bezeichnet, die den Dienst eines Anbieters in Anspruch nehmen. Der Client kann dabei den von ihm gewünschten Web Service über die Gelben Seiten auswählen oder ihn direkt ansprechen. Die WSDL- Beschreibung des Web Service kann direkt über den Dienst-Anbieter abgefragt werden. Sobald alle notwendigen Informationen über den Web Service bekannt sind, kann der Client mittels RPC (Remote Procedure Call) direkt den Dienst ansprechen Die Gelben Seiten Die Gelben Seiten, oder auch Discovery Agency [Lins03], sind eine Art Anlaufpunkt für Konsumenten, die einen bestimmten Dienst in Anspruch nehmen wollen. Die Dienst-Anbieter können ihren Dienst bei dem zentralen Verzeichnis registrieren. Bei dieser Registrierung können detaillierte Informationen zu dem Dienst mit angegeben werden. Mit Hilfe dieser Informationen sind interessierte Dienst-Konsumenten in der Lage, den für sie relevanten Dienst in dem Verzeichnis aufzufinden. Die Beschreibung des Dienstes innerhalb des Verzeichnisses ist ebenfalls standardisiert und erfolgt mit UDDI (Universal Definition, Discovery and Integration). Die Relevanz dieser Gelben Seiten ist allerdings weniger groß. Oftmals ist der Bedarf an Suche bestimmter Dienste im Web nicht erforderlich ist, da alle verwendeten Dienste bekannt sind. Kommen Web Services in Geschäftsprozessen, die mittels BPEL4WS realisiert werden, zur Verwendung, so ist solch eine Registrierung sogar gänzlich unnötig, da dem Prozess alle beteiligten Web Services bei der Implementierung bekannt sein müssen. Die Registrierung eines Web Service in einem der zentralen Verzeichnisse ist für Web Services nicht zwingend erforderlich WSDL Die Web Service Description Language wurde von den Unternehmen Ariba, IBM und Microsoft entwickelt und mit der Version 1.0 im September 2000 zum ersten Mal veröffentlicht. Version 1.1 wurde im März 2001 veröffentlicht. Da die aktuelle Version

22 Grundlagen der Business Process Execution Language for Web Services (BPEL4WS) die WSDL- Spezifikation Version 1.1 verwendet, soll hier nur diese Version berücksichtigt werden. Der Standard von WSDL wird von der W3C wie folgt definiert: Die Web Services Description Language (WSDL) stellt ein Modell und ein XML-Format bereit, um Web Services zu beschreiben. WSDL ermöglicht die Separation der Beschreibung der abstrakten Funktionalität, die von einem Web Service angeboten wird, von den konkreten Details der Servicebeschreibung [CGMW03]. Kurz gesagt basiert WSDL auf XML und beschreibt einen Web Service, um später nicht nur von Menschen, sondern auch von anderen Softwaresystemen gelesen werden zu können. Auch diese Idee ist nicht neu und existierte schon vor den Web Services. Ein wesentlicher Bestandteil der Middelware-Technologie CORBA ist IDL, die Interface Description Language [OMGr04]. Ein Interface ist ein Methodenkatalog, in dem aufgelistet wird, welche Methode von Clientseite mit welchen Parametern und Rückgabetyp auf einem Server ausgeführt werden kann [Lang03]. Zudem können auch eigene Typdefinitionen festgelegt werden. Die Beschreibung dieser Methoden und der Typdefinitionen erfolgt bei CORBA mittels IDL. Der Sinn ist auch hier eine Unabhängigkeit von einer bestimmten Programmiersprache. Mit Hilfe eines Tools können durch Auslesen IDL-Datei beispielsweise entsprechende Java-Klassen generiert werden. Genau dasselbe ist bei Web Services möglich, nur das hier WSDL zur Beschreibung verwendet wird. Das WSDL-Dokument eines Web Service beantwortet im Wesentlichen die drei Folgenden Fragen [KoLe04]: Was bietet der Web Service? D. h. wie müssen die eingehenden Nachrichten aussehen, wie sehen die vom Web Service ausgehenden Nachrichten aus und welche Methoden bietet der Web Service an? Wie funktioniert der Datenaustausch? D. h..welche Protokolle werden verwendet und wie werden die Nachrichten kodiert? Wo befindet sich der Web Service? D. h. unter welcher Internet-Adresse ist der Web Service erreichbar? 22

23 Strategien zur Prozessorchestrierung und Workflow-Integration in Web-Applikationen Ein WSDL-Dokument besitzt grundsätzlich folgenden Aufbau: Im ersten Schritt erfolgt die Festlegung der unterschiedlichen Namespaces die in dem Dokument verwendet werden. <definitions targetnamespace= urn:fnp:fnpprocess xmlns:wsdlsoap= xmlns:wsdl= xmlns= > In WSDL können eigene einfache und komplexe strukturierte Datentypen definiert werden, die nicht vom XML Schema-Standard abgedeckt werden [Lang03]. Diese Datentypen werden in dem durch die Elemente <types></types> festgelegten Bereich definiert. <types> <complextype name= Adresse > <sequence> <element name= vorname type= xsd:string /> <element name= nachname type= xsd:string /> <element name= strasse type= xsd:string /> <element name= plz type= xsd:int /> <element name= ort type= xsd:string /> </sequence> </complextype> </types> Mit Hilfe der Elemente <message></message> werden in abstrakter Form die Nachrichten beschrieben, die von dem Web Service empfangen und gesendet werden. Die einzelnen Elemente einer Nachricht werden mittels einem oder mehreren <part/>-elementen festgelegt. Bei SOAP-RPC-Nachrichten, wie sie auch im Rahmen dieser Arbeit verwendet wurden, entsprechen die <part/>-elemente den Parametern beim Aufruf einer Methode des Web Service bzw. dem Rückgabewert. <message name= getkontostandrequest > <part name= name type= xsd:string /> <part name= vorname type= xsd:string /> <part name= kontonummer type= xsd:int /> <part name= blz type= xsd:int /> 23

24 Grundlagen </message> <message name= getkontostandresponse > <part name= kontostand type= xsd:int /> </message> Innerhalb des <porttype>-elementes wird festgelegt und beschrieben, welche Operationen des Web Service aufgerufen werden können und wie dieser Aufruf zu erfolgen hat, d. h. welche Parameter übergeben werden. <porttype name= > <operation name= getkontostand > <input message= getkontostandrequest /> <output message= getkontostandresponse /> </operation> </porttype> In diesem Beispiel besitzt der Web Service die Operation getkontostand. Der Aufruf dieser Operation erfolgt mit vier Parametern, die im <message>-element getkontostandrequest definiert sind: Name, Vorname, Kontonummer, BLZ. Als Rückgabewert liefert die Operation einen Wert vom Typ xsd:int, den Kontostand. In der WSDL-Datei wird zusätzlich innerhalb des <binding>-elementes definiert, an welches Nachrichtenformat und Übertragungsprotokoll die Schnittstelle mit den vorhandenen Operationen gebunden wird. Dies kann für jede einzelne Operation festgelegt werden. Siehe dazu [Lang03]. Als letztes wird innerhalb des <service>-elementes bestimmt, unter welcher Adresse der Web Service erreichbar ist. <!-- Name und Adresse des Web Service --> <service name= myexampleservice > <port name= binding= > </port> </service> </definition> <wsdlsoap:address location= /> 24

25 Strategien zur Prozessorchestrierung und Workflow-Integration in Web-Applikationen Zusammen mit dem eigentlichen Web Service wird dieses WSDL-Dokument einem potentiellen Client öffentlich zugänglich gemacht. Mit Hilfe von Tools kann ein Anwendungsentwickler nun beispielsweise auf der Clientseite dieses WSDL-Dokument auswerten und Grundgerüste für Java-Klassen erzeugen, um so den Arbeitsaufwand für den Entwickler zu verringern. Für weitergehende Informationen zu Web Services wird auf [Lang03] und [ACKM04] verwiesen. 25

26 Grundlagen 26

27 Strategien zur Prozessorchestrierung und Workflow-Integration in Web-Applikationen 3. Business Process Execution Language BPEL4WS (auch BPEL) ist die Abkürzung für Business Process Execution Language for Web Services. BPEL4WS ist eine XML Sprache mit der Geschäftsprozesse spezifiziert werden können. BPEL ermöglicht es, verteilte Web Services zu Geschäftsprozessen zusammenzufassen und unterstützt dabei die Interaktion zwischen den Web Services untereinander und die Interaktion mit dem Client. Auf diese Weise ist es möglich, die Geschäftslogik des Prozesses von der eigentlichen Anwendung zu trennen. BPEL ist mittlerweile zu einem anerkannten Standard für die Komposition von Web Services geworden. Mit BPEL ist es möglich komplexe Prozesse zu erstellen, indem unterschiedliche Aktivitäten erstellt und zusammengefasst werden können [Aals03]. Bei den Aktivitäten kann es sich beispielsweise um den Aufruf von Web Services handeln, die Manipulation von Daten oder das Abfangen und Behandeln von Fehlern innerhalb des Prozesses. Diese einzelnen Aktivitäten können verschachtelt werden und zu Abläufen, wie Schleifen oder einer parallelen Abarbeitung, kombiniert werden. Die Kommunikation des Prozesses mit dem Client und anderen Web Services erfolgt über das Web Service Interface. Der BPEL-Geschäftsprozess kann also vereinfacht als ein aus Web Services zusammengesetzter Web Service betrachtet werden. Auf diese Weise bleibt dem Client die interne Prozessstruktur verborgen, ebenso wie dessen Kommunikation mit anderen im Prozess eingebundenen Web Services. Abbildung 1 zeigt ein Schema eines BPEL-Prozesses. Mittels BPEL wird ein neuer Web Service aus einer Reihe von bereits vorhandenen Web Services erstellt. Sowohl die Kommunikation zwischen dem Geschäftsprozess und den Web Services, als auch mit dem Client erfolgt über das WSDL-Interface (siehe Kapitel 2.3.2). Die prozessinterne sequentielle oder parallele Abarbeitung der Schritte bleibt dem Benutzer verborgen. 27

28 Business Process Execution Language for Web Services Abbildung 1 BPEL - Allgemeines Schema [Pelt03] Ein in diesem Fall häufig aufgeführtes Beispiel ist die Buchung eines Urlaubs über einen Reiseanbieter. Der Kunde startet den Geschäftsprozess, indem er den BPEL-Prozess des Reiseanbieters aufruft. Anhand der vom Kunden übermittelten Informationen wird im BPEL- Prozess ausgewählt, ob ein Ticket bei der Bahn oder bei einer Fluggesellschaft gebucht werden soll. Dementsprechend wird über ein Web Service der Bahn eine Fahrkarte für den Kunden bestellt. Zusätzlich werden gegebenenfalls Hotel- oder Autoreservierungen vorgenommen. Abschließend wird der Bank des Kunden eine Rechnung übermittelt. Der Kunde selbst bekommt dann eine Bestätigung vom Reiseanbieter, dass sein Urlaub erfolgreich gebucht wurde. Der zunehmende Bedarf an Standards, um mehrere Web Services zu Business Prozessen zusammen zu fassen, führte zu einer ganzen Reihe von unterschiedlichen und miteinander konkurrierenden Spezifikationen, wie beispielsweise PDL (Process Definition Language) [CSPP04], XPDL (XML Process Definition Language) [WMCo02], BPSS (Business Process Specification Schema) [BPrT01], EDOC (Enterprise Distributed Object Computing) [CBO+01], BPML (Business Process Modeling Language) [Arka02], WSDL [CGMW03], 28

29 Strategien zur Prozessorchestrierung und Workflow-Integration in Web-Applikationen WSCI (Web Service Choreography Interface) [AAF+02], ebxml (Electronic Business using extensible Markup Language) [Arka02] oder BPEL4WS. Die Fülle an sich überlappenden Standards für Web Services ist enorm. Einige Autoren bezeichnen diese miteinander konkurrierenden Standards deshalb scherzhaft auch als die Hölle der Web Services Akronyme [Aals03]. Die Business Process Execution Language for Web Services basiert auf den beiden Spezifikationen WSFL (Web Services Flow Language) [Leym01] von IBM und XLANG (Web Services for Business Process Design) [That01] von Microsoft. XLANG ist eine Sprache mit hierarchischen Strukturen und stellt beispielsweise Kontrollflussstrukturen wie Sequenzen, Switch-Anweisungen oder While-Schleifen zur Verfügung. WSFL erlaubt im Gegensatz dazu direkte Graphen, wobei die Graphen zwar geschachtelt, aber nicht azyklisch erstellt werden dürfen [Aals03]. Abbildung 2 BPEL Historie [Sher03] Abbildung 2 zeigt die zeitliche Entwicklung von BPEL auf [Sher03]. Dezember 2000 veröffentlichte Microsoft die erste Spezifikation von XLANG. Im März 2001 folgte die erste Spezifikation von WSFL seitens IBM. Im August 2002 wurden XLANG und WSFL zusammengefügt und die erste Version (1.0) der Spezifikation der Business Process Execution Language for Web Services veröffentlicht. Collaxa lieferten die erste komplette Implementation von BPEL 1.0. Im Mai 2003 erschien Version 1.1 von BPEL4WS, gegenwärtig wird an Version 2.0 gearbeitet. 29

30 Business Process Execution Language for Web Services BPEL4WS (Version 1.1) hängt von den folgenden XML-basierten Spezifikationen ab: WSDL 1.1, XML Schema 1.0, XPath 1.0 und WS-Adressing. BPEL baut auf dem Service Modell auf, das durch WSDL 1.1 definiert ist. Der BPEL-Geschäftsprozess und die Partner des Prozesses werden als WSDL Services modelliert. Ein Geschäftsprozess in BPEL definiert die Koordination der Interaktionen zwischen der Prozessinstanz und den Partnern [And+03]. Abbildung 3 BPEL und Web Service Protokoll Hierarchie Abbildung 3 (in Anlehnung an [FiWe04]) zeigt die Position von BPEL in der Web Service Architektur. Grundsätzlich lassen sich dabei vier Schichten unterscheiden: Transport-Schicht: Über die unterste Schicht tauschen die Web Services bzw. der BPEL-Geschäftsprozess Informationen aus. Die versendeten Nachrichten werden über Protokolle wie HTTP (Hypertext Transfer Protocol), SMTP (Simple Mail Transfer Protocol) oder FTP (File Transfer Protocol) übertragen. Nachrichten-Schicht: In dieser Schicht werden die übertragenen Informationen de- bzw. encodiert. Verwendet werden hier auf XML basierende Formate wie XML-RPC oder SOAP. Beschreibung: An dieser Stelle erfolgt die Beschreibung des Web Services, d.h. seine Schnittstelle nach außen. Zur Beschreibung wird sowohl für Web Services als auch für BPEL-Geschäftsprozesse WSDL (Web Service Description Language) verwendet. 30

31 Strategien zur Prozessorchestrierung und Workflow-Integration in Web-Applikationen Orchestrations-Schicht: In der obersten Schicht erfolgt die Beschreibung, wie die Web Services miteinander interagieren können. Hier wird die Business Logik und die Ausführungsreihenfolge der Web Services beschrieben. Die Orchestration kann beispielsweise mit BPEL4WS erfolgen. Bei Geschäftsprozessen in BPEL wird grundsätzlich zwischen zwei Typen von Prozessen unterschieden [WCK+04]: Ausführbaren Geschäftsprozessen und Abstrakten Geschäftsprozessen. Ausführbare Geschäftsprozesse beschreiben den kompletten Ablauf eines Prozesses sowie dessen Interaktion mit anderen Web Services. Mit BPEL4WS beschriebene ausführbare Geschäftsprozesse können von einer BPEL4WS-Engine gelesen, instanziiert und ausgeführt werden. Abstrakte Geschäftsprozesse hingegen beschreiben nur einen Teil eines Prozesses. So werden die öffentlichen Rahmenbedingungen beim Nachrichtenaustausch festgelegt und der Prozess allgemein beschrieben. Diese abstrakte Beschreibung dient dazu, die Integration und das Verständnis des Prozessablaufes für die Partner zu vereinfachen, die mit dem Prozess interagieren möchten. Interne, eventuell auch vertrauliche Details des Prozesses bleiben dem Partner dabei verborgen. In dieser Arbeit sollen abstrakte Geschäftsprozessbeschreibungen mit BPEL jedoch außer Acht gelassen werden. Einem BPEL-Prozess liegt ein bestimmtes Lebenszyklus-Modell zugrunde. Die Partner des Geschäftsprozesses, Clients oder Web Services, interagieren mit einer speziellen Instanz eines Prozesses. Im Gegensatz zu objekt-orientierten Programmiersprachen werden die Instanzen in BPEL nicht explizit erzeugt, sondern implizit sobald eine Nachricht an die noch nicht erzeugte Instanz eines Prozesses geschickt wird [FiWe04], siehe dazu auch Kapitel Eine Instanz wird terminiert, sobald die letzte Aktivität eines Prozesses abgearbeitet wurde oder innerhalb des Kontrollflusses eine explizit angegebene Aktivität zur Terminierung des Prozesses erreicht wird. Im Folgenden soll nun der Aufbau und die einzelnen Elemente eines BPEL-Prozesses genau erläutert werden. 31

32 Business Process Execution Language for Web Services 3.1 Aufbau eines BPEL-Prozesses Die Beschreibung eines BPEL-Prozesses besteht im Wesentlichen aus drei Hauptelementen: 1. WSDL-Beschreibungen von Partnern (optional) 2. WSDL-Beschreibung des Prozesses 3. BPEL-Prozessbeschreibung Die WSDL-Beschreibungen von Partnern beinhalten die Schnittstellenbeschreibung der Web Services, die vom Geschäftsprozess angesprochen werden oder selber den Prozess ansprechen. Diese WSDL-Beschreibungen werden zusammen mit dem zum Geschäftsprozess zugehörigen Web Services als vorhanden vorausgesetzt. Da der Geschäftsprozess in BPEL4WS einem Client als Web Service angeboten wird, wird eine WSDL-Beschreibung des Prozesses benötigt. Das WSDL-Dokument des Prozesses beschreibt, genau wie bei einem Web Service, die Schnittstelle nach außen. Bestandteile der WSDL-Beschreibung sind u.a. [KaBu03]: Definition von (komplexen) Datentypen Messages PartnerLinkTypen PortTypes Die Prozessbeschreibung stellt die eigentliche Definition des Prozesses dar und erfolgt innerhalb eines BPEL-Dokumentes. Grundsätzlich haben BPEL-Dokumente folgenden Grundaufbau [And+03]: 32

33 Strategien zur Prozessorchestrierung und Workflow-Integration in Web-Applikationen <! > <process name= ncname targetnamespace= uri <!-- Standard: XPath 1.0 URI (optional) --> querylanguage= anyuri <!-- Standard: XPath 1.0 URI (optional) --> expressionlanguage= anyuri <!-- joinfailure für alle Aktivitäten unterdrücken (optional) --> suppressjoinfailure= yes no <!-- Prozessinstanz als Ganzes kompensierbar? (optional) --> enableinsancecompensation= yes no <!-- abstrakter oder ausführbarer Prozess? (optional) --> abstractprocess= yes no xmlns= > <!-- unterschiedliche Links zu einem oder mehreren Partnern --> <partnerlinks> <partnerlink name= ncname partnerlinktype= qname </partnerlinks> myrole= ncname partnerrole= ncname ></partnerlink> <!-- die Partner des BPEL-Prozesses --> <partners> <partner name= ncname > </partner> </partners> <partnerlink name= ncname \> <!-- (globale) Variablen --> <variables> <variable name= ncname type= xsd:int /> </variables> <!-- Identifikationsmerkmale --> <correlationsets> <correlationset name= ncname properties= qname-list /> </corelationsets> <!-- Reaktionen im Falle eines Fehlers einer Aktivität --> <faulthandlers> <catch faultname= qname faultvariable= ncname > </catch> <catchall> </catchall> </faulthandlers> <!-- Aktivitäten --> <!-- Aktivitäten --> 33

34 Business Process Execution Language for Web Services <!-- Kompensation von bereits ausgeführten Aktivitäten --> <compensationhandler> <!-- Aktivitäten --> </compensationhandler> <!-- Ereignisbehandlung --> <eventhandlers> <onmessage partnerlink= ncname porttype= qname operation= ncname variable= ncname > <correlations> <correlation set= ncname initiate= yes no /> </correlations> <!-- Aktivitäten --> </onmessage> <onalarm for= duration-expr until= deadline-expr > <!-- Aktivitäten --> </onalarm> </eventhandlers> <!-- der eigentliche Prozessablauf --> <!-- Aktivitäten --> </process> Der Platzhalter <!-- Aktivitäten --> kann dabei durch folgende Elemente ersetzt werden: receive, invoke, reply, assign, throw, terminate, wait, empty, sequence, switch, while, pick, flow, scope, compensate. Diese einzelnen Aktivitäten werden in den folgenden Abschnitten detailliert erläutert. 34

35 Strategien zur Prozessorchestrierung und Workflow-Integration in Web-Applikationen Interaktion BPEL dient in erster Linie dazu, mehrere Web Services zu einem gesamten Geschäftsprozess zusammenzufassen. Aus diesem Grund ist die Interaktion zwischen dem Prozess und anderen Web Services integraler Bestandteil von BPEL4WS Partner Links Alle Verbindungen vom Geschäftsprozess zu Web Services oder Clients werden in BPEL4WS als Partner Links bezeichnet. Dabei definiert ein Partner Link genau eine bestimmte Beziehung zwischen dem Prozess und Web Service oder dem Client. Das folgende Beispiel zeigt eine Beziehung zwischen dem Geschäftsprozess und einem Client. <partnerlinks> <partnerlink name= echotest partnerlinktype= echokontakt myrole= dasecho partnerrole= derrufende /> </partnerlinks> Jeder Partner Link ist von einem bestimmten Typ (Partner Link Type). Es können somit mehrere Partner Links von einem Partner Link Type existieren. So könnte in dem oben gezeigten Beispiel ein Partner Link mit dem Namen langerechotest erstellt werden, der ebenfalls vom Partner Link Typ echokontakt ist. Die Rolle des definierten Geschäftsprozesses wird durch das Attribut myrole definiert, die Rolle des Partners durch das optionale Attribut partnerrole Partner Link Types Die Definition von Partner Link Types erfolgt nicht im BPEL-Dokument, sondern in der WSDL-Beschreibung des Geschäftsprozesses. Partner Link Types charakterisieren die Beziehung zwischen zwei Web Services, bzw. im Speziellen zwischen einem Geschäftsprozess und einem Web Service. Bei der Definition werden die Rollen der beiden 35

36 Business Process Execution Language for Web Services beteiligten Partner festgelegt, sowie die entsprechenden Port Types (siehe Kapitel 2.3.2), um die Nachrichten im entsprechenden Kontext zu erhalten. Ein Partner Link Type wird wie folgt definiert: <partnerlinktype name= echokontakt xmlns= > <role name= dasecho > </role> </partnerlinktype> <porttype name= echoport /> Jede Rolle spezifiziert genau einen WSDL Port Type. Normalerweise stammen die Port Types von unterschiedlichen Namespaces der jeweils beteiligten Partner. In diesem Falle sei der porttype zusammen mit der zu übertragenden Nachricht in der WSDL-Datei des Prozesses wie folgt definiert <message name= textnachricht > </message> <part name= echotext type= xsd:string /> <porttype name= echoport > <operation name= echo > <input message= textnachricht /> <output message= textnachricht /> </operation> </porttype> Business Partner Geschäftsprozesse bestehen in den meisten Fällen aus mehreren Beziehungen zwischen zwei Partnern, d. h. die Interaktion mit einem Geschäftspartner erfordert mehrere Partner Links. Geschäftspartner werden in BPEL4WS als Partner bezeichnet. Ein Partner kann dabei einen oder mehrere (Web) Services anbieten, die Bestandteil des gesamten Geschäftsprozesses sind. Das folgende Beispiel zeigt die Definition eines Partners im BPEL-Dokument: 36

37 Strategien zur Prozessorchestrierung und Workflow-Integration in Web-Applikationen <partner name= echopartner > <partnerlink name= echotest \> <partnerlink name= langerechotest \> </partner> Die Definitionen von Partnern sind optional. Ein Partner Link darf in höchstens einer Partnerdefinition vorkommen, allerdings müssen die in der WSDL-Beschreibung definierten Partner Links nicht alle durch die Partnerdefinitionen abgedeckt werden [And+03] Kommunikation BPEL bietet drei unterschiedliche Aktivitäten zur Kommunikation mit Web Services bzw. einem Client an: receive, reply und invoke. Receive Die Aktivität receive empfängt eine von einem Web Services gesendete Nachricht. Sie spezifiziert, über welchen Nachrichtenkanal der Prozess die Nachricht empfängt und in welcher Variablen der Nachrichteninhalt abgelegt wird [Stah04]. <receive partnerlink="echotest" porttype="echoport" operation="echo" variable="frage" createinstance="yes" name="echofrage"/> Das oben stehende Beispiel zeigt eine Definition der <receive>-aktivität in BPEL, wobei die Aktivität durch einen Namen (Attribut name) eindeutig gekennzeichnet ist. Die eigentliche empfangene Nachricht wird in der Variable frage abgespeichert, die ebenfalls im BPEL-Dokument definiert sein muss: <variables> <variable name= frage messagetype= textnachricht /> </variables> 37

38 Business Process Execution Language for Web Services Die Nachricht ist vom Typ textnachricht, der in der WSDL-Beschreibung des Prozesses festgelegt wurde. Instanzen werden in BPEL implizit durch eingehende Nachrichten erzeugt. Mit receive kann solch eine Instanz erzeugt werden. Wird das Attribut createinstance auf yes gesetzt, wird eine Instanz des Geschäftsprozesses erzeugt, sobald entsprechende Nachricht beim Prozess eintrifft. Siehe dazu auch Kapitel Reply Mit reply wird bei einer synchronen Kommunikation mit einem Web Service die Antwort auf eine mit reveive empfangene Nachricht zurück geschickt. Die Aktivität reply wird wie folgt definiert: <reply partnerlink= echotest porttype= echoport operation= echo variable= frage name= echoantwort /> In diesem Beispiel wird die mit receive zuvor empfangene Nachricht, die in der Variablen frage abgespeichert wurde, unverändert wieder zurückgeschickt. Ebenso wie bei receive wird die Aktivität mit einem eindeutigen Namen durch das Attribut name gekennzeichnet. Invoke Bei der Aktivität invoke wird zwischen der asynchronen und der synchronen Aktivität invoke unterschieden [Stah04]. Beim asynchronen invoke wird vom Prozess ein Web Service aufgerufen. Dabei wird die als Input-Variable definierte Nachricht an den Web Service geschickt. Es erfolgt keine Antwort des Web Service. 38

39 Strategien zur Prozessorchestrierung und Workflow-Integration in Web-Applikationen Die synchrone Variante des invoke dient zum normalen Nachrichtenaustausch, wobei wieder die als Input-Variable definierte Nachricht an den Web Service geschickt wird. Die vom Web Service empfangene Antwort wird in der in invoke festgelegten Output- Variablen gespeichert. Das folgende Beispiel zeigt die Definition der synchronen <invoke>-aktivität: <invoke name="uebersetzeraufrufen" partnerlink="babelfishservice" porttype="babelfish:babelfishporttype" operation="babelfish" inputvariable="englischertext" outputvariable="deutschertext"/> Bei der asynchronen Variante wird das Attribut outputvariable nicht benötigt. Im Gegensatz zu den Aktivitäten reply und receive kann bei invoke direkt die Fehlerbehandlung bzw. die Kompensation erfolgen und braucht nicht in das umschließende Scope eingebunden werden. Siehe dazu auch die beiden folgenden Kapitel und Scopes Scopes (Gültigkeitsbereiche) dienen in BPEL dazu, eine oder mehrere Aktivitäten in einem gemeinsamen Kontext zusammenzufassen. Innerhalb eines Scopes können Variablen und zu Aktivitäten entsprechende Fehlerbehandlungen, sowie Ereignisse, Korrelationsmengen und Kompensationen definiert werden, die nur innerhalb dieses Scopes sichtbar und nur für diesen Scope gültig sind. Jeder Scope hat eine Aktivität, die dessen normales Verhalten darstellt. Diese Aktivität kann dabei auch eine komplexe strukturierte Aktivität darstellen, die beliebig tief verschachtelt werden kann. Scopes können weitere Scopes beinhalten. Das folgende Beispiel zeigt einen möglichen Aufbau eines Scopes. <scope> <variables> </variables> <correlationsets> </corellationsets> <faulthandler> </faulthandler> <eventhandler> </eventhandler> 39

40 Business Process Execution Language for Web Services <!-- Aktivitäten: --> <flow> </flow> </scope> <invoke /> <invoke /> Fehlerbehandlung Die Fehlerbehandlung in einem Geschäftsprozess wird benötigt, sobald das tatsächliche Verhalten des Prozesses von seinem geplanten Verhalten abweicht. Fehler können sowohl intern innerhalb des Prozesses, als auch extern durch Fehler beim Aufruf von Web Services erzeugt werden. BPEL4WS bietet eine Fehlerbehandlung an (faulthandler), um mögliche Fehler abzufangen und um entsprechend auf die Fehler reagieren zu können. Eine Fehlerbehandlung kann für jeden Scope und für den gesamten Prozess festgelegt werden. Bei der Behandlung des Fehlers sollen die unvollständig und nicht korrekt abgeschlossenen Aktivitäten eines Scopes, in dem der Fehler aufgetreten ist, rückgängig gemacht werden. Auch wenn die Fehlerbehandlung eines Scopes erfolgreich abgeschlossen wird, so wird der Scope weiterhin als nicht abgeschlossen betrachtet, so dass die erfolgreiche Beendigung des Scopes oder der Aufruf einer entsprechenden Kompensation nicht mehr möglich ist. Das folgende Beispiel zeigt eine Definition eines FaultHandlers in BPEL [And+03]: <faulthandlers> <catch faultname= fehler1 faultvariable= variable1 > <!-- Aktivität(en) --> </catch> <catch faultname= fehler2 > <!-- Aktivität(en) --> </catch> <catch faultvariable= variable2 > <!-- Aktivität(en) --> </cach> <catchall> <!-- Aktivität(en) --> </catchall> </faulthandlers> 40

41 Strategien zur Prozessorchestrierung und Workflow-Integration in Web-Applikationen Innerhalb eines faulthandlers können mehrere <catch>-aktivitäten definiert werden. Jede dieser Catch-Aktivitäten dient dazu, genau einen bestimmten Fehler abzufangen. Identifiziert wird ein Fehler durch einen eindeutigen Fehlernahmen und dem Namen einer Variablen, deren Daten mit dem Fehler assoziiert werden. Zusätzlich kann eine <catchall>-aktivität festgelegt werden, die alle Fehler abfängt, die nicht explizit durch <catch>-aktivitäten abgedeckt werden. Die Attribute faultname und faultvariable in der <catch>-aktivität sind optional, wobei mindestens einer dieser Attribute vorhanden sein muss. Eine Sonderstellung bei der Fehlerbehandlung nimmt die Aktivität invoke ein. Beim Aufruf von invoke kann die Fehlerbehandlung direkt mit angegeben werden und muss nicht in die Fehlerbehandlung des umschließenden Scopes eingebunden werden. Dieses Beispiel zeigt einen Ausschnitt der WSDL-Beschreibung eines angesprochenen Web Service. <porttype name= clientport > <operation name= getkontostand > <input message= getkontostandrequest /> <output message= getkontostandresponse /> <fault name= falschekontonummer message= getkontostandfalschekontonummer /> </operation> </porttype> Der Aufruf der Operation getkontostand sollte normalerweise eine Nachricht vom Typ getkontostandresponse liefern. Im Fehlerfall wird jedoch vom Web Service eine Exception geworfen. Diese Exception kann in BPEL wie folgt abgefangen werden: <invoke operation= getkontostand > <catch faultname= ws1:falschekontonummer > <empty name= tuenichts /> </catch> </invoke> Hier wird die Fehlerbehandlung direkt nach dem Invoke durchgeführt. 41

42 Business Process Execution Language for Web Services Neben den durch den Benutzer festgelegten Fehlern können auch Laufzeitfehler auftreten. BPEL unterscheidet zwischen folgenden Laufzeitfehlern: selectionfailure, conflictingreceive, conflictingrequest, mismatchedassignmentfailure, joinfailure, forcedtermination, correlationviolation, uninitializedvariable, repeatedcompensation und invalid Reply [And+03] Kompensation Wenn mehrere Aktivitäten wie geplant durchgeführt wurden, kann es notwendig sein, einige davon wieder rückgängig zu machen. Wurde beispielsweise in einem ersten Schritt ein Zimmer in einem Hotel gebucht, in einem zweiten Schritt versucht einen Flug zu dem Zielort zu erhalten, so muss die Hotelbuchung rückgängig gemacht werden können, falls kein Flug mehr verfügbar ist. Ein einfaches undo kann hier nicht durchgeführt werden. BPEL bietet hier die Möglichkeit der Kompensation. Zu jedem Scope kann ein optionaler Compensation Handler festgelegt werden, der alle notwendigen Aktivitäten beinhaltet, die benötigt werden, um die im Scope durchgeführten Aktivitäten rückgängig zu machen bzw. zu kompensieren. Dieser Compensation Handler wird erst aktiv, sobald ein Scope komplett abgeschlossen wurde. Das folgende Beispiel zeigt eine Definition eines Compensation Handlers: <scope name= Flugbuchung > <compensationhandler> <invoke /> </compensationhandler> <invoke /> </scope> Der Compensation Handler kann nur über die <compensate>-aktivität aufgerufen werden, wobei der Name des entsprechenden Scopes als Attribut angegeben werden muss. <compensate scope= Flugbuchung /> 42

43 Strategien zur Prozessorchestrierung und Workflow-Integration in Web-Applikationen Wird ein Compensation Handler eines Scopes aufgerufen, der noch nicht abgeschlossen wurde, so wird automatisch die <empty>-aktivität ausgeführt und nicht die Aktivitäten des Compensation Handlers. Die Compensate-Aktivität kann nur in den folgenden Abschnitten eines Geschäftsprozesses aufgerufen werden: im Fault Handler eines den Scope direkt umschließenden weiteren Scopes im Compensation-Handler eines den Scope direkt umschließenden weiteren Scopes Die folgende Abbildung 4 veranschaulicht den Aufruf der Compensate-Aktivität: Abbildung 4 BPEL Compensation Handler Alle Aktivitäten der Scopes B und C wurden bereits ausgeführt. Ein Fehler bei einer Aktivität im Scope A führt dazu, dass der Catch-Block des Scopes ausgeführt wird. Innerhalb dieses Blocks wird der Compensation Handler des Scopes B ausgerufen, um alle Aktivitäten aus Scope B zu kompensieren. Innerhalb des Compensation Handlers von Scope B wird wiederum der Compensation Handler von Scope C aufgerufen. 43

44 Business Process Execution Language for Web Services Variablen Instanzen von Business Prozessen in BPEL besitzen einen Zustand, der sich aus den empfangenen Nachrichten, den gesendeten Nachrichten und anderen für den Prozess relevanten Daten, beispielsweise dem aktuelle Wert eines Zählers in einer Schleife, zusammensetzt [And+03]. Zum Speichern dieser Werte verwendet BPEL4WS Zustandsvariablen oder kurz Variablen. Um den Kontrollfluss eines Business Prozesses steuern zu können, muss auf die Variablen zugegriffen werden können, um beispielsweise Vergleiche durchführen zu können. BPEL bietet diese Möglichkeit. Eine Variable kann ein WSDL-Nachrichtentyp, ein einfacher XML Schema-Datentyp oder ein XML Schema-Element sein. Variablen werden in BPEL wie folgt deklariert: <variables> <variable name= var_1 messagetype= InvMessage /> <variable name= var_2 type= xsd:int /> <variable name= var_3 element= Kundenkonto /> </variables> Dieses Beispiel zeigt die drei unterschiedlichen Varianten von Variablendefinitionen in BPEL4WS. Das Element variable kann neben dem Attribut name, das den eindeutigen Namen der Variable festlegt, eins von drei weiteren Attributen besitzen: messagetype bezieht sich auf die Definition eines WSDL-Nachrichtentyps, das Attribut type auf einen einfachen Typ ( Simple Type ) eines XML Schemas (z.b. xsd:int). Das dritte Attribut element bezieht sich auf ein Element des XML Schemas. Um komplexe Typen ( Complex Type ) eines XML Schemas als Variablentyp in BPEL verwenden zu können, muss der Typ mit einem Element assoziiert werden. In BPEL wird zwischen lokalen und globalen Variablen unterschieden, abhängig von dem Sichtbarkeitsbereich, in dem sie definiert werden. Siehe dazu auch Kapitel In einem Business Prozess ist jedoch auch notwenig, Werte von einer Variablen zu einer anderen zu kopieren oder neue Werte einer Variablen zuzuweisen, beispielsweise bei der Erhöhung eines Zählers in einer Schleife. Die Wertänderung einer Variablen erfolgt mittels der <assign>-aktivität. 44

45 Strategien zur Prozessorchestrierung und Workflow-Integration in Web-Applikationen <assign> <copy> <from> </from> <to variable= meinkontostand /> </copy> <copy> <from variable= alte_adresse part= strasse /> <to variable= neue_adresse part= strasse /> </copy> </assign> In einer <assign>-aktivität können ein oder mehrere copy-elemente eingefügt werden. Das Element from kann alternativ zu einem literalen Wert mehrere Attribute besitzen, wobei das Attribut part optional ist [And+03]: <from variable= ncname part= ncname /> <from variable= ncname property= qname /> <from partnerlink= ncname endpointreference= myrole partnerrole /> <from expression= general-expr /> Das Attribut part darf nicht verwendet werden, wenn es sich bei den Variablen um einfache Typen ( SimpleType ) eines XML Schemas handelt. In dem Element to können mehrere unterschiedliche Attribute festgelegt werden: <to variable= ncname part= ncname /> <to partnerlink= ncname /> <to variable= ncname property= qname /> Bevor Variablen in BPEL verwendet werden können, müssen sie initialisiert werden. Diese Initialisierung geschieht automatisch, falls die Variable einer Aktivität wie receive oder invoke als Parameter übergeben und damit automatisch mit einem bestimmten Wert belegt wurde. Soll aber beispielsweise der Rückgabewert von einem Aufruf eines Web Service in eine andere Variable kopiert werden, die bis zu diesem Zeitpunkt noch nicht verwendet wurde, so 45

46 Business Process Execution Language for Web Services muss diese Variable zuvor initialisiert werden. Das folgende Beispiel zeigt eine solche Initialisierung: <assign> <copy> <from> <adresse xmlns= > <name/> <strasse>testweg</strasse> <ort/> <plz>12345</plz> </adresse> </from> <to variable= ausgabe part= adresse > </copy> </assign> Die Variable ausgabe ist im BPEL-Dokument definiert: <variable name= ausgabe messagetype= tns:ausgabenachricht /> Die Nachricht ausgabenachricht ist in der WSDL-Beschreibung des Prozesses definiert: <message name= ausgabenachricht > </message> <part name= daten element= tns:adresse > Bei adresse handelt es sich um einen komplexen Datentyp, der aus einer Reihe von einfachen Elementen (siehe Beispiel oben) besteht und ebenfalls in der WSDL-Beschreibung des Prozesses definiert wird. Soll in diesem Beispiel ein neuer Wert in das Element PLZ eingefügt werden, muss auf ein Element des Datentyps adresse zugegriffen werden. Der Zugriff auf diese Elemente erfolgt über Querys: <assign> 46 <copy>

47 Strategien zur Prozessorchestrierung und Workflow-Integration in Web-Applikationen <from>67653</from> <to variable= ausgabe part= daten query= /adresse/plz /> </copy> </assign> Innerhalb von Prozessen ist es oftmals notwendig, direkt auf die Werte zugreifen zu können, um in Bedingungen Vergleiche durchführen zu können. In BPEL wird dies mit der Funktion bpws:getvariabledata ermöglicht: <variable name= vorhanden type= xsd:boolean /> <variable name= textnachricht messagetype= tns:textnachricht /> <variable name= ausgabe messagetype= tns:ausgabenachricht /> <while condition= bpws:getvariabledata( vorhanden ) > <!-- --> </while> <while condition= bpws:getvariabledata( textnachricht, text ) = hallo > <!-- --> </while> <while condition= bpws:getvariabledata( ausgabe, daten, /plz ) = > <!-- --> </while> In diesem Beispiel sei der Typ textnachricht eine Nachricht mit dem Element text vom Typ xsd:string, der Typ ausgabenachricht bezieht sich auf das vorangegangene Beispiel Ausdrücke Ausdrücke werden in BPEL bei mehreren Aktivitäten zur Bestimmung des weiteren Prozessablaufs benötigt, beispielsweise als Bedingung einer While-Schleife oder in einer Wait-Anweisung. Bei BPEL werden zwischen folgenden unterschiedlichen Typen von Ausdrücken unterschieden [And+03]: - boolsche Ausdrücke - deadline-valued Ausdrücke 47

48 Business Process Execution Language for Web Services - duration-valued Ausdrücke - generelle Ausdrücke BPEL4WS unterstützt die Verwendung von XPath 1.0 als Ausdruckssprache. Siehe dazu auch [ClDe99] und [WWWC04]. Boolsche Ausdrücke Boolsche Ausdrücke entsprechen der XPath 1.0 Expression [ClDe99], deren Auswertung einen boolschen Wert ergibt. Beispiele hierfür sind true(), false(), 1 = 1, 1 < 2, 1!= 1. Boolsche Ausdrücke werden u. a. in der <while>-aktivität oder im Case-Element der <switch>-aktivität verwendet. Deadline-Valued Ausdrücke Die Auswertung der XPath Ausdrücke muss einen Wert vom XML Schema Typ datetime oder date ergeben. Ein Beispiel hierfür ist T18:00:00. Siehe dazu auch [WWWC04]. Duration-Valued Ausdrücke Alle XPath Ausdrücke, die als Auswertung den Typ duration ergeben, können an dieser Stelle eingesetzt werden. In BPEL werden Ausdrücke dieser Art in der <wait>- Aktivität benutzt. Der Ausdruck besteht i. d. R. aus zwei Teilen: Einer Zeiteinheit, die größer gleich ein Tag ist, gefolgt von einer Zeiteinheit, die kleiner als ein Tag ist. Getrennt werden die beiden Teile von dem Separator T. Dieser Separator muss nur dann hinzugefügt werden, wenn die Zeitangabe auch Stunden, Minuten oder Sekunden beinhaltet. <wait for= P1Y2M3DT4H5M6S /> In diesem Beispiel wird der Prozess für ein Jahr, zwei Monate, drei Tage, vier Stunden, fünf Minuten und sechs Sekunden angehalten. Dem Ausdruck muss immer 48

49 Strategien zur Prozessorchestrierung und Workflow-Integration in Web-Applikationen ein P voranstehen. Beträgt der Wert des Jahres, des Tages oder anderen Einheiten null, so kann der entsprechende Bezeichner (z. B. Y für Year) weggelassen werden. Generelle Ausdrücke Generelle Ausdrücke umfassen alle mit XPath generierbaren Ausdrücke (siehe [ClDe99]) Korrelationen Oftmals laufen bei Geschäftsprozessen mehrere Instanzen eines Prozesses parallel nebeneinander ab. Bei sehr einfachen Geschäftsprozessen, bei denen ein Prozess lediglich ein oder zwei Web Service-Aufrufe kapselt, stellt dies kein Problem dar. Interagiert aber der Prozess mehrfach mit einem Client, eventuell sogar mit mehreren unterschiedlichen Clients, so reicht es nicht, den WSDL-Port eines Prozesses als Ziel des Clients anzugeben. In solchen Fällen ist es auch notwendig, die Nachricht an die entsprechende Instanz eines Prozesses weiterzuleiten. Bei objekt-orientierten Programmiersprachen werden solche Interaktionen mittels Objekt- Referenzen ermöglicht. Durch Referenzen können gezielt spezifische Objekte erreicht werden, die einen bestimmten Zustand und eine bestimmte Historie der Interaktion besitzen. Im Gegensatz zu mit objekt-orientierten Programmiersprachen realisierten Implementationen besteht bei der losen gekoppelten Architektur von Web Services das Problem, dass solche Referenzen zu einem schnell immer größer werdenden Netz heranwachsen würden. Bei jedem Partner des Geschäftsprozesses müssten entsprechende Informationen gespeichert werden. Solch ein Referenz-Netz hätte auf Dauer keine lange Überlebenschance [And+03]. Ein Mechanismus, um dieses Problem zu beheben, ist die Verwendung von so genannten Tokens. Ein Token ist eine Zeichenfolge, die einmalig ist. In jeder Nachricht wird, zusätzlich zu der eigentlichen zu transportierenden Information, ein Token mitgeliefert, mit dessen Hilfe die Nachricht einer bestimmten Instanz eines Geschäftsprozesses zugeordnet werden kann. Ein Token könnte beispielsweise bei einem Bestellvorgang aus der Bestell- oder einer Vorgangsnummer bestehen. BPEL4WS ermöglicht es, diesen Token-Mechanismus einzusetzen. So können die Position des Tokens in der Nachricht und seine Struktur festgelegt werden. 49

50 Business Process Execution Language for Web Services Die Verwendung dieser Tokens kann jedoch komplex werden. Da die Lebenszeit eines Geschäftsprozess relativ lang sein kann, kann sich eine Gruppe von Tokens (beispielsweise die ID und der Name eines Benutzers) durchaus nur auf einen Teil dieser Lebenszeit beziehen, ggf. können sogar mehrere Gruppen parallel übertragen werden, wenn sich die Lebenszeit der Token überlappen. Solche Gruppen von Tokens werden in BPEL als correlationsets (Korrelationsmengen) bezeichnet. Jede Korrelationsmenge hat einen Namen und in WSDL definierte Bestandteile (properties), auf die alle Nachrichten zugreifen können, die diese Tokens transportieren. Die Sichtbarkeit dieser Korrelationsmengen entspricht denen von Variablen. Korrelationsmengen können innerhalb von Scopes definiert werden und haben außerhalb dieser Scopes keine Gültigkeit. Globale Korrelationsmengen hingegen sind im gesamten Prozess sichtbar. Sie können nur einmal initziiert werden und können so zur Identifikation des gesamten Prozesses dienen. Lokale Korrelationsmengen innerhalb von Scopes können nur zur Lebenszeit eines Scopes initziiert werden und müssen ihren Wert behalten, bis der Scope abgeschlossen ist. Eine Korrelationsmenge wird in BPEL wie folgt definiert: <correlationsets> <correlationset name= benutzercs properties= benutzerid /> </correlationsets> Diese Korrelationsmenge besteht lediglich aus einer Benutzer-ID. Durch Leerzeichen getrennt können ggf. weitere Elemente angegeben werden. Diese properties werden innerhalb der WSDL-Datei definiert. <bpws:property name= benutzerid type= xsd:int/> An dieser Stelle wird der Datentyp der BenutzerID festgelegt. Die Korrelationsmengen werden in die Nachrichten in der WSDL-Datei des Geschäftsprozesses eingebettet, d. h. es muss festgelegt werden, wo sich die oben definierte 50

51 Strategien zur Prozessorchestrierung und Workflow-Integration in Web-Applikationen Benutzer-ID in den jeweiligen Nachrichten an oder von dem Prozess befinden. Dies wird in der WSDL-Datei mittels eines der Definition von propertyalias festgelegt: <definitions name= properties targetnamespace= xmlns:tns= xmlns:bpws= xmlns= > <message name= beispielnachrichtrequest > <part name= identifikationsnummer type= xsd:int /> <part name= meinname type= xsd:string /> <part name= meintext type= xsd:string /> </message> <message name= beispielnachrichtresponse > <part name= text type= xsd:string /> </message> <bpws:property name= benutzerid type= xsd:int/> <porttype name= beispielport > <operation= beispieloperation > <input message= beispielnachrichtrequest /> <output message= beispielnachrichtresponse /> </operation> </porttype> <partnerlinktype name= beispiellinktype > <bpws:propertyalias propertyname= cor:benutzerid messagetyp= tns:beispielnachrichtrequest query= /identifikationsnummer /> <role name= webservice > <porttype name= beispielport /> </role> </partnerlinktype> </definitions> Diese correlationsets werden instanziiert, sobald eine Aktivität aufgerufen wird, die das Attribut initiate=yes beinhaltet und sich auf das jeweilige correlationset bezieht. Ein correlationset kann mittels der Aktivitäten invoke, pick, receive oder reply instanziiert werden. 51

52 Business Process Execution Language for Web Services <receive partnerlink= beispiellink porttype= beispielport operation= beispieloperation variable= beispielnachrichtrequestvar createinstance= yes > <correlations> <correlation set= benutzercs initiate= yes /> </correlations> </receive> Aktivitäten BPEL unterscheidet zwischen so genannten Basisaktivitäten und strukturierten Aktivitäten [Djem04]. Basisaktivitäten sind atomare Aktionen, die beispielsweise die Kommunikation mit anderen Web Services ermöglichen. Folgende primäre Aktivitäten sind in BPEL verfügbar: receive, reply, invoke, assign, throw, terminate, wait, empty, scope, compensate Strukturelle Aktivitäten beschreiben die Ablaufreihenfolgen und Ablaufbedingungen ihrer gekapselten Elemente, welche einfache primäre Aktivitäten oder weitere strukturelle Aktivitäten sein können [Djem04]. Folgende strukturierte Aktivitäten stellt BPEL zur Verfügung: sequence, switch, while, pick, flow Abbildung 5 zeigt die unterschiedlichen Typen von Aktivitäten und deren Abhängigkeiten untereinander. 52

53 Strategien zur Prozessorchestrierung und Workflow-Integration in Web-Applikationen Abbildung 5 BPEL Aktivitätstypen [Dubr03], [FiWe04] Die einzelnen Basis- und strukturellen Aktivitäten werden, soweit nicht bereits in den vorangegangenen Abschnitten geschehen, im Folgenden näher erläutert. 53

54 Business Process Execution Language for Web Services Basisaktivitäten Wait Mit Wait kann der Geschäftsprozess für eine bestimmte Zeitspanne angehalten werden (Attribut for) oder solange angehalten werden, bis eine bestimmte Deadline eingetreten ist (Attribut until). Das folgende Beispiel zeigt die Verwendung des Attributs for: <sequence> <wait for= P0Y0M1DT1H0M0S /> <invoke partnerlink= LinkZumChef porttype= AutomaticPhoneCall operation= TextToSpeech inputvariable= WeihnachtsgrussAnChef > </invoke> </sequence> In diesem Beispiel wird ein Tag und eine Stunde gewartet, bevor die <invoke>- Aktivität aufgerufen wird. In Kapitel werden die Ausdrücke, die im for- und until-attribut verwendet werden können, näher erläutert. Empty Wie der Name der Aktivität vermuten lässt, passiert bei dessen Aufruf nichts. Oftmals wird eine Aktivität benötigt, bei der keinerlei Aktion durchgeführt wird. Dies ist beispielsweise der Fall, wenn Fehler abgefangen und unterdrückt werden müssen. Die Syntax ist wie folgt festgelegt: <empty standard-attributes> </empty> <!-- standard-elements --> 54

55 Strategien zur Prozessorchestrierung und Workflow-Integration in Web-Applikationen Strukturelle Aktivitäten Sequence Innerhalb einer <sequence>-aktivität werden alle aufgeführten Aktivitäten der Reihe nach ausgeführt, d. h. erst wenn eine Aktivität ausgeführt und beendet wurde, wird die darauf folgende Aktivität aufgerufen. <sequence> </sequence> <!-- Aktivitäten --> Switch Die <switch>-aktivität erlaubt es, anhand eines Kriteriums eine bestimmte Aktivität auszuwählen. Sie ist von der Funktionalität her identisch mit der Switch-Anweisung der Programmiersprache JAVA. Mittels einer Fallunterscheidung wird eine bestimmte Aktivität ausgewählt. Optional kann mittels otherwise ein alternativer Ablauf festgelegt werden, falls keiner der definierten Fälle eingetreten ist. Die alternativen Fälle schließen sich bei BPEL aus, d. h. ein Break am Ende jedes Falles, wie in JAVA, ist nicht erforderlich. Das folgende Beispiel veranschaulicht die Verwendung der Switch-Aktivität: <switch> <case condition= bpws:getvariabledata( konto, kontostand ) < 0 > <!-- Aktivität(en) --> </case> <case condition= bpws:getvariabledata( konto, kontostand ) > 0 > <!-- Aktivität(en) --> </case> <otherwise> <!-- Aktivität(en) --> </otherwise> </switch> 55

56 Business Process Execution Language for Web Services While Ebenso wie Switch entspricht die <while>-aktivität bei BPEL den While- Anweisungen aus imperativen Programmiersprachen. Solange eine bestimmte Bedingung erfüllt ist, werden die in der While-Schleife definierten Aktivitäten ausgeführt. <while condition= bpws:getvariabledata( zaehler ) < 10 > <! - Aktivität(en) --> </while> Pick Innerhalb von Geschäftsprozessen kann die Notwendigkeit bestehen, auf mehrere alternativ eintreffende Nachrichten eines Benutzers oder eines Web Services zu reagieren. Mit Hilfe der <pick>-aktivität kann dieses Szenario in BPEL realisiert werden. Innerhalb der <pick>-aktivität können mehrere Ereignisse festgelegt werden, auf die der Prozess wartet. Tritt eines dieser Ereignisse ein, so wird dieses entsprechend abgehandelt und die <pick>-aktivität beendet. Die einzelnen Ereignisse schließen sich dabei gegenseitig aus, d. h. es kann nur das Ereignis ausgelöst werden, welches als erstes eintritt. <pick createinstance= yes > <onmessage > </onmessage> <onmessage > </onmessage> <onalarm > </onalarm> </pick> Wie im Beispiel zu sehen ist, kann die <pick>-aktivität auch am Anfang eines Prozesses definiert werden, so dass das erste eintreffende Ereignis eine Instanz des Prozesses erzeugt (Attribut createinstance). Die Definitionen von Ereignissen, wie Nachrichten oder Alarme, werden in Kapitel näher erläutert. 56

57 Strategien zur Prozessorchestrierung und Workflow-Integration in Web-Applikationen Nebenläufiger Ablauf Im Gegensatz zu der <sequence>-aktivität können in BPEL mit Hilfe der <flow>-aktivität weitere Aktivitäten definiert werden, die nebenläufig ausgeführt werden. Sobald der Prozessablauf eine <flow>-aktivität erreicht, werden alle dort definierten Aktivitäten aktiviert. Sobald alle Aktivitäten abgeschlossen sind, ist die <flow>-aktivität ebenfalls beendet und der Prozessablauf läuft sequentiell weiter. <flow> <invoke name= A partnerlink= A /> <invoke name= B partnerlink= B /> <sequence> <receive name= Frage /> <reply name= Antwort /> </sequence> </flow> Dieses Beispiel zeigt die Definition einer Flow-Aktivität. Die beiden Invoke-Aktivitäten A und B sowie der Sequence-Block werden parallel ausgeführt. Die Aktivitäten innerhalb der Sequenz werden jedoch nacheinander abgehandelt Synchronisation Mit BPEL ist es möglich, die einzelnen Aktivitäten innerhalb einer Flow-Aktivität zu synchronisieren, d. h. Abhängigkeiten zwischen einzelnen Aktivitäten zu modellieren. Das ist insbesondere dann sinnvoll, wenn unterschiedliche Aktivitäten auf gemeinsame Variablen zugreifen und Inkonsistenzen vermieden werden sollen. Zur Veranschaulichung der Synchronisation soll folgendes Beispiel in Abbildung 6 dienen: 57

58 Business Process Execution Language for Web Services Abbildung 6 Beispielprozess mit Synchronisation Nach Ausführen von invoke start werden parallel sequence X, sequence Y und invoke E ausgeführt. Innerhalb der beiden Sequenzen X und Y werden der Reihe nach jeweils zwei weitere Aktivitäten ausgeführt. Nach Abschluss der parallelen Abarbeitung wird invoke ende ausgeführt. Folgende zusätzlichen Abhängigkeiten sind durch gepunktete Pfeile gekennzeichnet: sequence Y darf erst nach invoke E ausgeführt werden, invoke B erst nach Beendigung von invoke D. Zu Beginn des Flows müssen alle Abhängigkeiten festgelegt werden. Dies wird in BPEL durch so genannte Links realisiert: <invoke name= start /> <flow> <links> <link name= EvorY /> <link name= DvorB /> 58

Business Process Execution Language. Christian Vollmer <christian.vollmer@udo.edu> Oliver Garbe <oliver.garbe@udo.edu>

Business Process Execution Language. Christian Vollmer <christian.vollmer@udo.edu> Oliver Garbe <oliver.garbe@udo.edu> Business Process Execution Language Christian Vollmer Oliver Garbe Aufbau Was ist BPEL? Wofür ist BPEL gut? Wie funktioniert BPEL? Wie sieht BPEL aus?

Mehr

9. Business Process Execution Language

9. Business Process Execution Language 1 9. Business Process Execution Language Beobachtung: häufige Änderungen der Geschäftsprozesse dies erfordert leichte und schnelle Software-Anpassung Idee: Software in (Web-)Services gliedern ( SOA) diese

Mehr

Enterprise Applikation Integration und Service-orientierte Architekturen 11 BPEL

Enterprise Applikation Integration und Service-orientierte Architekturen 11 BPEL Enterprise Applikation Integration und Service-orientierte Architekturen 11 BPEL Prozesse und Services Prof. Dr. Holger Wache 2 Problem: Prozesssteuerung mit WSDL Jeder Prozess ist zustandsbehaftet. Dieser

Mehr

Web Services Composition (BPWS4J )

Web Services Composition (BPWS4J ) Web Services Composition (BPWS4J ) Hager Markus, Kober Christoph, Linde Kai, Ott Florian, Erdmann Dennis Programmierung verteilter Systeme Lab Institut für Informatik Universität Augsburg Universitätsstraße

Mehr

Workflow, Business Process Management, 4.Teil

Workflow, Business Process Management, 4.Teil Workflow, Business Process Management, 4.Teil 24. Januar 2004 Der vorliegende Text darf für Zwecke der Vorlesung Workflow, Business Process Management des Autors vervielfältigt werden. Eine weitere Nutzung

Mehr

Business Process Execution Language for Web Services (BPEL4WS)

Business Process Execution Language for Web Services (BPEL4WS) Hauptseminar und Vorlesung Web Services WS 2003/04 Business Process Execution Language for Web Services (BPEL4WS) Patrick Sauter 2/17 Vortrag - Überblick Definition, Zielsetzung und Allgemeines einfacher

Mehr

Java und XML 2. Java und XML

Java und XML 2. Java und XML Technische Universität Ilmenau Fakultät für Informatik und Automatisierung Institut für Praktische Informatik und Medieninformatik Fachgebiet Telematik Java und XML Hauptseminar Telematik WS 2002/2003

Mehr

Seminarbericht Rechnernetze XML Web Services Schnittstelle zwischen den Welten.NET und Java

Seminarbericht Rechnernetze XML Web Services Schnittstelle zwischen den Welten.NET und Java Seminarbericht Rechnernetze XML Web Services Schnittstelle zwischen den Welten.NET und Java von Christian Brand Kennnummer: 09376 November 2005 Abkürzungen Abkürzungen API - Application Programming Interface

Mehr

WSDL. Web Services Description Language. André Vorbach. André Vorbach

WSDL. Web Services Description Language. André Vorbach. André Vorbach André Vorbach WSDL Web Services Description Language André Vorbach Übersicht Was ist WSDL? Dokumentenstruktur Elemente Definitions Types Messages porttype Binding Service SOAP-Bindings Beispiel Was ist

Mehr

Wiederholung: Beginn

Wiederholung: Beginn B) Webserivces W3C Web Services Architecture Group: "Ein Web Service ist eine durch einen URI eindeutige identifizierte Softwareanwendung, deren Schnittstellen als XML Artefakte definiert, beschrieben

Mehr

Webservices. 1 Einführung 2 Verwendete Standards 3 Web Services mit Java 4 Zusammenfassung. Hauptseminar Internet Dienste

Webservices. 1 Einführung 2 Verwendete Standards 3 Web Services mit Java 4 Zusammenfassung. Hauptseminar Internet Dienste Hauptseminar Internet Dienste Sommersemester 2004 Boto Bako Webservices 1 Einführung 2 Verwendete Standards 3 Web Services mit Java 4 Zusammenfassung Was sind Web Services? Web Services sind angebotene

Mehr

3-schichtige Informationssystem-Architektur

3-schichtige Informationssystem-Architektur 3-schichtige Informationssystem-Architektur plattformunabhängig beliebige Endgeräte Client als Applikation & Applet XML über SOAP Standard plattformunabhängig objektorientierte Architektur multiuserfähig

Mehr

Gliederung. 1. Einleitung (1) 1. Einleitung (3) 1. Einleitung (2)

Gliederung. 1. Einleitung (1) 1. Einleitung (3) 1. Einleitung (2) Referat im Rahmen des Proseminars Internettechnologie WS 2007/2008 Thema: Web Services und serviceorientierte Architekturen (SOA) vorgelegt von: Intelligente Web Services sind für das Informationszeitalter,

Mehr

Möglichkeiten der Orchestrierung von Grid Web Services mit BPEL. Uschi Beck Marko Brosowski

Möglichkeiten der Orchestrierung von Grid Web Services mit BPEL. Uschi Beck Marko Brosowski Möglichkeiten der Orchestrierung von Grid Web Services mit BPEL Uschi Beck Marko Brosowski Gliederung Motivation BPEL Entstehung/Ziele ein kurzes Beispiel Basiskonzepte Probleme BPEL Engines BPEL im Grid

Mehr

Tutorial zu WS-BPEL. Veranstaltung: Entwicklung verteilter Softwaresysteme mit Webservices im Sommersemester 2008

Tutorial zu WS-BPEL. Veranstaltung: Entwicklung verteilter Softwaresysteme mit Webservices im Sommersemester 2008 Tutorial zu WS-BPEL Veranstaltung: Entwicklung verteilter Softwaresysteme mit Webservices im Sommersemester 2008 Universität Hamburg Department Informatik Arbeitsbereich VSIS Gruppe 01: Johannes Kuhlmann,

Mehr

Geschäftsprozessmodellierung essmodellierung mit BPEL

Geschäftsprozessmodellierung essmodellierung mit BPEL Geschäftsprozessmodellierung essmodellierung mit BPEL Autor: Stefan Berntheisel Datum: 8. Januar 2010 Stefan Berntheisel Hochschule RheinMain Fachseminar WS 09/10 Agenda Grundlagen Business Process Execution

Mehr

Model-Driven Software Development

Model-Driven Software Development Model-Driven Software Development BPEL 2.0 Robert Siebert Das Forschungs- und Entwicklungsprojekt OrViA wird mit Mitteln des Bundesministeriums für Bildung und Forschung (BMBF) gefördert, die innerhalb

Mehr

Seminararbeit Einbindung von Webservices über BPEL

Seminararbeit Einbindung von Webservices über BPEL Seminararbeit Einbindung von Webservices über BPEL Julian Harrer IBB4B Hochschule München Sommersemester 2008 Seminar: Integration von Geschäftsprozessen Prof. Dr. Zimmer Torsten München 10.07.2008 I.

Mehr

A Comparison of BPML and BPEL4WS

A Comparison of BPML and BPEL4WS A Comparison of BPML and BPEL4WS Wirtschaftsinformatik Universität Trier Seite 1 Ziele des Vortrags 1. Heterogenität der Business Process Modelling Initiativen für Web Services erkennen 2. Beschreibungsmöglichkeit

Mehr

Ein Beispiel. Ein Unternehmen will Internettechnologien im Rahmen des E- Business nutzen Welche Geschäftsprozesse?

Ein Beispiel. Ein Unternehmen will Internettechnologien im Rahmen des E- Business nutzen Welche Geschäftsprozesse? Ein Beispiel Ein Unternehmen will Internettechnologien im Rahmen des E- Business nutzen Welche Geschäftsprozesse? Dipl.-Kfm. Claus Häberle WS 2015 /16 # 42 XML (vereinfacht) visa

Mehr

Vertiefte Grundlagen Graphentheorie

Vertiefte Grundlagen Graphentheorie Bauinformatik Vertiefte Grundlagen Graphentheorie 6. Semester 9. Übung BPEL Webservice-Orchestrierung i Technische Umsetzung am Beispiel Biegespannung eines Einfeldträgers Nürnberger Str. 31a 2. OG, Raum

Mehr

Web Services stellen eine Integrationsarchitektur dar, die die Kommunikation zwischen verschiedenen Anwendungen

Web Services stellen eine Integrationsarchitektur dar, die die Kommunikation zwischen verschiedenen Anwendungen 9 3 Web Services 3.1 Überblick Web Services stellen eine Integrationsarchitektur dar, die die Kommunikation zwischen verschiedenen Anwendungen mit Hilfe von XML über das Internet ermöglicht (siehe Abb.

Mehr

Markus Schulz Seminar: XML für Fortgeschrittene 30.06.2003

Markus Schulz Seminar: XML für Fortgeschrittene 30.06.2003 Markus Schulz Seminar: XML für Fortgeschrittene 30.06.2003 Vortragsgliederung 1. Motivation 2.-8. WS : Definition, Ansatz, Architektur,... 9.x. SOAP : Definition, Geschichte,... 10.x.x. WSDL : siehe oben...

Mehr

POIS-Praktikum 2007. Prozessimplementierung, RosettaNet PIPs 3A

POIS-Praktikum 2007. Prozessimplementierung, RosettaNet PIPs 3A POIS-Praktikum 2007 Prozessimplementierung, RosettaNet PIPs 3A Manuel Blechschmidt, David Foerster, Michael Leben, Mike Nagora, Jonas Rogge, Paul Römer Gliederung 2 Einleitung Was war unsere Aufgabe? Was

Mehr

Konzepte und Anwendung von Workflowsystemen. Kapitel 8: Workflow Ausführungssprache BPEL

Konzepte und Anwendung von Workflowsystemen. Kapitel 8: Workflow Ausführungssprache BPEL Vorlesung Wintersemester 2011/12 Konzepte und Anwendung von Workflowsystemen Kapitel 8: Workflow Ausführungssprache BPEL Lehrstuhl für Systeme der Informationsverwaltung, Prof. Böhm Institut für Programmstrukturen

Mehr

Modellierung von Geschäftsprozessen mit BPEL4WS

Modellierung von Geschäftsprozessen mit BPEL4WS Seminararbeit von Abstract Die Business Process Execution Language for Web Services (BPEL4WS) ermöglicht es, sowohl Geschäftsprozesse zu beschreiben, welche Web Services nutzen, als auch Geschäftsprozesse

Mehr

Geschäftsprozessmodellierung mit BPEL4WS: Aufbau und Beispiel

Geschäftsprozessmodellierung mit BPEL4WS: Aufbau und Beispiel Seminar Service Orientierte Architektur Geschäftsprozessmodellierung mit BPEL4WS: Aufbau und Beispiel SOA-Seminar 2006 - BPEL4WS - Christoph Forster (Winf 2370) 1 Agenda (1) Überblick (2) Der Geschäftsprozess

Mehr

Autor: Peter Seemann Seminar: Softwarearchitekturen Betreuer: Benedikt Meurer

Autor: Peter Seemann Seminar: Softwarearchitekturen Betreuer: Benedikt Meurer Autor: Peter Seemann Seminar: Softwarearchitekturen Betreuer: Benedikt Meurer *Was sind Web Services? *Beispiele für Web Services *Web Service Architektur *Web Services Technologien *Fazit 2 *Übertragungsstandard

Mehr

Integration und Orchestrierung von Geschäftsprozessen in Web Applikationen Ein Service-Orientierter Ansatz

Integration und Orchestrierung von Geschäftsprozessen in Web Applikationen Ein Service-Orientierter Ansatz Integration und Orchestrierung von Geschäftsprozessen in Web Applikationen Ein Service-Orientierter Ansatz Jochen Müller, Andreas Kümpel, Paul Müller AG Integrierte Kommunikationssysteme Universität Kaiserslautern

Mehr

Seminar E-Services WS 02/03 WSDL. Web Services Description Language. Moritz Kleine SES 02 - WSDL

Seminar E-Services WS 02/03 WSDL. Web Services Description Language. Moritz Kleine SES 02 - WSDL Seminar E-Services WS 02/03 WSDL Web Services Description Language SES 02 - WSDL Zum Ablauf Einleitung Webservices und WSDL Grundlagen (XML - Schema und Namespaces) WSDL Syntax Beispiel Zusammenfassung

Mehr

Sind Prozessmanagement-Systeme auch für eingebettete Systeme einsetzbar?

Sind Prozessmanagement-Systeme auch für eingebettete Systeme einsetzbar? Sind Prozessmanagement-Systeme auch eingebettete Systeme einsetzbar? 12. Symposium Maritime Elektrotechnik, Elektronik und Informationstechnik, 8.-12. Oktober 2007 Rostock, Deutschland Rostock, Deutschland

Mehr

Bachelorarbeit. Modellierung interaktiver Web Service Workflows. Thema: Benjamin Koch. von

Bachelorarbeit. Modellierung interaktiver Web Service Workflows. Thema: Benjamin Koch. von Bachelorarbeit Thema: Modellierung interaktiver Web Service Workflows von Benjamin Koch Gliederung Beispiel Interaktive Workflows Komponenten o BPEL o Web Service o Web-Interface o Eclipse-Plugin Vorführung

Mehr

SOA. Prof. Dr. Eduard Heindl Hochschule Furtwangen Wirtschaftsinformatik

SOA. Prof. Dr. Eduard Heindl Hochschule Furtwangen Wirtschaftsinformatik SOA Prof. Dr. Eduard Heindl Hochschule Furtwangen Wirtschaftsinformatik Laderampen müssen passen Modularisieren Softwarearchitektur Modul A Modul B Modul C Modul D Große Anwendung im Unternehmen Modul

Mehr

Microsoft.NET und SunONE

Microsoft.NET und SunONE Microsoft.NET und SunONE, Plattformen und Application Service Providing Agenda Einordnung.NET und SunONE Kurzvorstellung Gegenüberstellung Zusammenfassung ASP (Application( Service Providing) ) und Ausblick

Mehr

WSDL. 7363 - Web-basierte Anwendungen WSDL WSDL. Eine Vertiefungsveranstaltung mit Schwerpunkt auf XML-Technologien. Web Services Description Language

WSDL. 7363 - Web-basierte Anwendungen WSDL WSDL. Eine Vertiefungsveranstaltung mit Schwerpunkt auf XML-Technologien. Web Services Description Language Fachhochschule Wiesbaden - Fachhochschule Wiesbaden - 7363 - Web-basierte Anwendungen Eine Vertiefungsveranstaltung mit Schwerpunkt auf XML-Technologien Web Services Description Language 10.06.2004 H.

Mehr

Verteilte Systeme: Übung 4

Verteilte Systeme: Übung 4 Verteilte Systeme: Übung 4 WSDL und SOAP Oliver Kleine Institut für Telematik https://www.itm.uni-luebeck.de/people/kleine SOAP Nachrichten Serialisierung in XML Root-Element einer SOAP Nachricht ist

Mehr

Praktikum aus Softwareentwicklung 2. Web Services. Java Praktikum SS 2010 Gerald.Ehmayer@borland.com

Praktikum aus Softwareentwicklung 2. Web Services. Java Praktikum SS 2010 Gerald.Ehmayer@borland.com Web Services Java Praktikum SS 2010 Gerald.Ehmayer@borland.com 1 Web Services Einführung Definition, Eigenschaften, Anwendungen... JAX-RPC Überblick, Architektur... JAX Übersicht, Architektur Java Praktikum

Mehr

SOA goes real Service-orientierte Architekturen erfolgreich planen und einführen

SOA goes real Service-orientierte Architekturen erfolgreich planen und einführen Daniel Liebhart SOA goes real Service-orientierte Architekturen erfolgreich planen und einführen ISBN-10: 3-446-41088-0 ISBN-13: 978-3-446-41088-6 Inhaltsverzeichnis Weitere Informationen oder Bestellungen

Mehr

Client/Server-Systeme

Client/Server-Systeme Fachbereich Informatik Projektgruppe KOSI Kooperative Spiele im Internet Client/Server-Systeme Vortragender Jan-Ole Janssen 26. November 2000 Übersicht Teil 1 Das Client/Server-Konzept Teil 2 Client/Server-Architekturen

Mehr

Themen. Web Services und SOA. Stefan Szalowski Daten- und Online-Kommunikation Web Services

Themen. Web Services und SOA. Stefan Szalowski Daten- und Online-Kommunikation Web Services Themen Web Services und SOA Wer kennt den Begriff Web Services? Was verstehen Sie unter Web Services? Die Idee von Web Services Ausgangspunkt ist eine (evtl. schon bestehende) Software Anwendung oder Anwendungskomponente

Mehr

Systematische Entwicklung serviceorientierter Workflows: Ein Beitrag zur prozessorientierten Dienstkomposition in Anwendungsdomänen

Systematische Entwicklung serviceorientierter Workflows: Ein Beitrag zur prozessorientierten Dienstkomposition in Anwendungsdomänen Systematische Entwicklung serviceorientierter Workflows: Ein Beitrag zur prozessorientierten Dienstkomposition in Anwendungsdomänen Vom Fachbereich Informatik der Technischen Universität Kaiserslautern

Mehr

1 YAWL Yet Another Workflow Language

1 YAWL Yet Another Workflow Language 1 YAWL Yet Another Workflow Language Das YAWL Workflow-Management-System wurde von Wil van der Aalst und seinem Team an der Eindhoven University of Technology entwickelt. Das System ist in seiner jetzigen

Mehr

Seminar XML und Datenbanken. Thema: Workflow

Seminar XML und Datenbanken. Thema: Workflow Seminar XML und Datenbanken Thema: Workflow Betreuer: Markus Bon Bearbeiter: Kristof Barklage Gliederung (1) Grundlagen (2) Workflow Management Coalition (3) XML Process Definition Language (XPDL) (4)

Mehr

BPMN Kategorien und Elementgruppen. Flussobjekte

BPMN Kategorien und Elementgruppen. Flussobjekte BPMN Kategorien und Elementgruppen Flussobjekte Business Process BP... Activity1 Activity Eine Activity ist die generischer Ausdruck für in Unternehmen anfallende Tätigkeiten. Das Element Activity kann

Mehr

Softwareentwicklung in verteilten Umgebungen Middleware Case Studies (Coulouris et al., Kapitel 5 und 19) Dieter Schmalstieg Jens Grubert

Softwareentwicklung in verteilten Umgebungen Middleware Case Studies (Coulouris et al., Kapitel 5 und 19) Dieter Schmalstieg Jens Grubert Softwareentwicklung in verteilten Umgebungen Middleware Case Studies (Coulouris et al., Kapitel 5 und 19) Dieter Schmalstieg Jens Grubert Partly based on material by Victor García Barrios and Paul Krzyzanowski

Mehr

Workflow Systeme mit der Windows Workflow Foundation

Workflow Systeme mit der Windows Workflow Foundation Studiengang Electronic Business (EB) Diplomarbeit (280000) Workflow Systeme mit der Windows Workflow Foundation externe Betreuung durch Christoph Müller vorgelegt bei Prof. Dr. Michael Gröschel von Hans-Martin

Mehr

E-Services mit der Web-Service-Architektur

E-Services mit der Web-Service-Architektur E-Services mit der Web-Service-Architektur im Seminar Neue Konzepte anwendungsorientierter Middleware - Stefan Kürten - Literatur A. Tsalgatidou and T. Pilioura, An Overview of Standards and Related Rechnology

Mehr

Webservices in der IBM Welt eine neue Herausforderung für DB2 Spezialisten

Webservices in der IBM Welt eine neue Herausforderung für DB2 Spezialisten Betrifft Webservices in der IBM Welt eine neue Herausforderung für DB2 Spezialisten Autor Andreas Börlin (info-zuerich@trivadis.com) Erstellungsdatum Januar 2004 Informationen innerhalb einer Unternehmung

Mehr

Zustandsgebundene Webservices

Zustandsgebundene Webservices Zustandsgebundene Webservices Präsentation ausgewählter Problemstellungen der Informatik Markus Oertel oer@uni-paderborn.de Universität Paderborn 25. September 2005 Zustandsgebundene Webservices Seite

Mehr

Standards und Standardisierungsgremien

Standards und Standardisierungsgremien Standards und Standardisierungsgremien Begriffe Norm und Standard synonym Organisationen z.b. ISO: International Standards Organization DIN: Deutsches Institut für Normung e.v. ANSI: American National

Mehr

Microsoft.NET. InfoPoint 8. Juni 2005 Stefan Bühler

Microsoft.NET. InfoPoint 8. Juni 2005 Stefan Bühler Microsoft.NET InfoPoint 8. Juni 2005 Stefan Bühler Inhalt Was ist.net Was steckt dahinter Warum ist.net so wie es ist Die Säulen von.net.net Framework 2.0 / VisualStudio 2005 Beispiel Referenzen & Links

Mehr

Error-Hospital für Oracle SOA Suite

Error-Hospital für Oracle SOA Suite Error-Hospital für Oracle SOA Suite Markus Lohn esentri AG Ettlingen Schlüsselworte Fusion Middleware, SOA, SOA Suite Einleitung Die Entwicklung von Services mit der SOA Suite erfolgt überwiegend deklarativ

Mehr

SOAP und WSDL in der Praxis. Wie wird SOAP/WSDL verwendet? Heutige Vorlesung. .net. und Apache Axis

SOAP und WSDL in der Praxis. Wie wird SOAP/WSDL verwendet? Heutige Vorlesung. .net. und Apache Axis Heutige Vorlesung SOAP und WSDL in der Praxis Aufbau von WSDL-Beschreibungen Protokoll-Bindungen in WSDL Google-WSDL lesen und erweitern können Vor- und Nachteile von WSDL heute Wie wird SOAP/WSDL verwendet?.net,

Mehr

Übersicht. Angewandte Informatik 2 - Tutorium 6. Teile einer WSDL-Datei. Was ist WSDL. Besprechung: Übungsblatt 5

Übersicht. Angewandte Informatik 2 - Tutorium 6. Teile einer WSDL-Datei. Was ist WSDL. Besprechung: Übungsblatt 5 Übersicht Angewandte Informatik 2 - Tutorium 6 Besprechung: Übungsblatt 5 Götz Bürkle (goetz@buerkle.org) Übungsblatt 5: Aufgabe 4 - Webservices Institut für Angewandte Informatik und Formale Beschreibungsverfahren

Mehr

etutor Benutzerhandbuch XQuery Benutzerhandbuch Georg Nitsche

etutor Benutzerhandbuch XQuery Benutzerhandbuch Georg Nitsche etutor Benutzerhandbuch Benutzerhandbuch XQuery Georg Nitsche Version 1.0 Stand März 2006 Versionsverlauf: Version Autor Datum Änderungen 1.0 gn 06.03.2006 Fertigstellung der ersten Version Inhaltsverzeichnis:

Mehr

Using Workflows to Coordinate Web Services in Pervasive Computing Environments

Using Workflows to Coordinate Web Services in Pervasive Computing Environments Using Workflows to Coordinate Web Services in Pervasive Computing Environments Vortrag im Rahmen des Seminars SOA 2005 im Fachbereich Informatik angefertigt von Volker Henke Agenda 1. Ubiquitous Computing

Mehr

Web- und Gridservices zur Überwindung von Heterogenität. Bearbeiter: Lei Xia 16.07.2004

Web- und Gridservices zur Überwindung von Heterogenität. Bearbeiter: Lei Xia 16.07.2004 Web- und Gridservices zur Überwindung von Heterogenität Bearbeiter: Lei Xia 16.07.2004 Gliederung Einleitung Formen von Heterogenität Grundlagen Web Services als Schnittstelle zu DBMS Grid Data Services

Mehr

CAS genesisworld.exchange connect Abgleich von Adressen und Terminen

CAS genesisworld.exchange connect Abgleich von Adressen und Terminen Abgleich von Adressen und Terminen Stand Juni 2004 Was ist CAS genesisworld.exchange connect? Inhalt 1 Was ist CAS genesisworld.exchange connect?... 3 2 Systemvoraussetzungen... 5 2.1 Software...5 2.2

Mehr

Web Services mit Java

Web Services mit Java Web Services mit Java Neuentwicklung und Refactoring in der Praxis Torsten Langner new technology Markt+Technik Verlag Inhaltsverzeichnis Vorwort 13 Warum ausgerechnet dieses Buch? 13 An wen richtet sich

Mehr

Enterprise Application Integration Erfahrungen aus der Praxis

Enterprise Application Integration Erfahrungen aus der Praxis Enterprise Application Integration Erfahrungen aus der Praxis Teil 4: EAI und.net, EAI und J2EE Tutorial NODs 2002, Wolfgang Keller and Generali 2001, 2002, all rights reserved 1 Überblick EAI und....net

Mehr

6 Zusammenschaltung von Web-Services

6 Zusammenschaltung von Web-Services 6 Zusammenschaltung von Web-Services Komposition von Web-Services zu neuen Web-Services abstrakte Beschreibung der internen Struktur Workflow-Konzept abstrakte Beschreibung der Zusammenhänge und Interaktionen

Mehr

Wissenschaftliche Vertiefung Web Services. Esslingen, 22. Januar 2016 Simon Schneider

Wissenschaftliche Vertiefung Web Services. Esslingen, 22. Januar 2016 Simon Schneider Wissenschaftliche Vertiefung Web Services Esslingen, 22. Januar 2016 Agenda 1. Einführung 2. Serviceorientierte Architektur 3. SOAP Web Service 4. Standards und Protokolle von SOAP Web Services 5. Bewertung

Mehr

CORBA-Konzept. Ziele. Common Object Request Broker Architecture CORBA. Plattformunabhängige Kommunikation Transparente Verteilung von Objekten

CORBA-Konzept. Ziele. Common Object Request Broker Architecture CORBA. Plattformunabhängige Kommunikation Transparente Verteilung von Objekten CORBA-Konzept Ziele Common Object Request Broker Architecture CORBA Plattformunabhängige Kommunikation Transparente Verteilung von Objekten CORBA-Konzept Object Management Group Spezifiziert den CORBA-Standard

Mehr

Whitepaper Walkyre Enterprise Resource Manangement

Whitepaper Walkyre Enterprise Resource Manangement Whitepaper Walkyre Enterprise Resource Management Seite 1 Whitepaper Walkyre Enterprise Resource Manangement Stand 15.11.2004 Inhalt 1. Hinweis... 2 2. Grundsätzliches zur Funktionalität... 3 3. Der Walkyre-Client...

Mehr

SOAP Integrationstechnologie für verteilte Middlewarearchitekturen?

SOAP Integrationstechnologie für verteilte Middlewarearchitekturen? SOAP Integrationstechnologie für verteilte Middlewarearchitekturen? Großer Beleg Christian Wurbs Zwischenbericht http://www.inf.tu-dresden.de/~cw6 cw6@inf.tu-dresden.de Überblick 2 Aufgabenstellung CORBA

Mehr

Hauptseminar Internetdienste Prof. F. Schweiggert Sommersemester 2004 Universität Ulm. Web Services. Boto Bako

Hauptseminar Internetdienste Prof. F. Schweiggert Sommersemester 2004 Universität Ulm. Web Services. Boto Bako Hauptseminar Internetdienste Prof. F. Schweiggert Sommersemester 2004 Universität Ulm Web Services Boto Bako Inhaltsverzeichnis 1.Einführung und Motivation...3 2.Verwendete Standards...4 2.1.SOAP...5 2.2.WSDL...6

Mehr

Web-Sevices : WSDL Entwicklung von Web-Anwendungen

Web-Sevices : WSDL Entwicklung von Web-Anwendungen Web-Sevices : WSDL Entwicklung von Web-Anwendungen Axel Reusch : ar047 MIB page 1 : 50 Agenda! Allgemeines! Prinzip! Anwendung! Details! WSDL und SOAP! Beispiel mit Java! Erweiterungen! Vorteile! Nachteile!

Mehr

Inhalt I. Blick zurück II. Was sind WebServices? III. Rahmenwerk für edienstleistungen IV. Verwendete WebServices

Inhalt I. Blick zurück II. Was sind WebServices? III. Rahmenwerk für edienstleistungen IV. Verwendete WebServices WebServices Applikationen und Services Ralf Günther Consultant HP Services April, 2003 Ralf.Guenther@hp.com DECUS Symposium 2003, Vortrag 2L06 9.04.2003 Inhalt I. Blick zurück II. Was sind WebServices?

Mehr

Entwurf und Implementierung einer Workflow-basierten Anwendung zur Auswertung mathematischer Formeln

Entwurf und Implementierung einer Workflow-basierten Anwendung zur Auswertung mathematischer Formeln Entwurf und einer Workflow-basierten Anwendung zur Auswertung mathematischer Formeln Object 14 Service Orientated Architecture (SOA) Web Services Business Process Execution Language (BPEL) SOA [1/3] Service

Mehr

BPEL - Business Process Executable Language

BPEL - Business Process Executable Language Martin Luther Universität Halle Wittenberg Fachbereich Mathematik und Informatik Institut für Informatik Lehrstuhl für Softwaretechnik und Programmiersprachen BPEL - Business Process Executable Language

Mehr

... MathML XHTML RDF

... MathML XHTML RDF RDF in wissenschaftlichen Bibliotheken (LQI KUXQJLQ;0/ Die extensible Markup Language [XML] ist eine Metasprache für die Definition von Markup Sprachen. Sie unterscheidet sich durch ihre Fähigkeit, Markup

Mehr

Web Services. XML, WSDL, SOAP und UDDI Einblicke und Ausblicke. 31.03.2003 J.M.Joller 1

Web Services. XML, WSDL, SOAP und UDDI Einblicke und Ausblicke. 31.03.2003 J.M.Joller 1 Web Services XML, WSDL, SOAP und UDDI Einblicke und Ausblicke 31.03.2003 J.M.Joller 1 Inhalt Architekturen Main Stream.NET J2EE und Applikations-Server Sicht der Anbieter Java J2EE J2EE versus.net Web

Mehr

Service-Orientierte Architekturen

Service-Orientierte Architekturen Hochschule Bonn-Rhein-Sieg Service-Orientierte Architekturen Kapitel 7: Web Services IV Exkurs über Sicherheitsanforderungen Vorlesung im Masterstudiengang Informatik Sommersemester 2010 Prof. Dr. Sascha

Mehr

Enterprise Applikation Integration und Service-orientierte Architekturen. 09 Simple Object Access Protocol (SOAP)

Enterprise Applikation Integration und Service-orientierte Architekturen. 09 Simple Object Access Protocol (SOAP) Enterprise Applikation Integration und Service-orientierte Architekturen 09 Simple Object Access Protocol (SOAP) Anwendungsintegration ein Beispiel Messages Warenwirtschaftssystem Auktionssystem thats

Mehr

Grid-Systeme. Betrachtung verschiedener Softwareplattformen zur Realisierung von Grids und Vorstellung des Globus Toolkit. 07.06.2002 Grid Systeme 1

Grid-Systeme. Betrachtung verschiedener Softwareplattformen zur Realisierung von Grids und Vorstellung des Globus Toolkit. 07.06.2002 Grid Systeme 1 Grid-Systeme Betrachtung verschiedener Softwareplattformen zur Realisierung von Grids und Vorstellung des Globus Toolkit 07.06.2002 Grid Systeme 1 Gliederung Vorstellung verschiedener Plattformen Globus

Mehr

Web Services: Inhalt

Web Services: Inhalt Web Services Fachseminar Verteilte Systeme 8. April 2002 - Marco Steiner Assistent: Thomas Schoch Professor: Dr. F. Mattern Web Services: Inhalt Bedeutung Gegenwart Architektur SOAP WSDL UDDI Vergleich

Mehr

Web-Services Grundlagen

Web-Services Grundlagen Web-Services Grundlagen Praktikum Informationsintegration 1.11.2005 Agenda Aktueller Stand Was sind Web-Services? Allgemeines Web-Service-Technologien SOAP WSDL 2 Umgebung (Korrektur) Rechner/Server mangold.informatik.hu-berlin.de

Mehr

Musterlösung zur Vorlesung Modellbasierte Softwareentwicklung Wintersemester 2014/2015 Übungsblatt 9

Musterlösung zur Vorlesung Modellbasierte Softwareentwicklung Wintersemester 2014/2015 Übungsblatt 9 Prof. Dr. Wilhelm Schäfer Paderborn, 15. Dezember 2014 Christian Brenner Tristan Wittgen Musterlösung zur Vorlesung Modellbasierte Softwareentwicklung Wintersemester 2014/2015 Übungsblatt 9 Aufgabe 1 Codegenerierung

Mehr

EAI - Enterprise Application Integration

EAI - Enterprise Application Integration EAI - Enterprise Application Integration Jutta Mülle WS 2005/2006 EAI - Folie 1 Überblick und Begriffsbildung Zusammenfassung und Ausblick hinweise EAI - Folie 2 Conclusion EAI Enterprise Application Integration

Mehr

Definition Web Service

Definition Web Service Gliederung Einführung Definition Web Service Drei Schhichtenmodell Architectural Model System Model Web Service Standards SOAP WSDL UDDI Types of Web Services Programmatic Web Services Interactive Web

Mehr

Dokumentation zum Projekt Mail-Adapter in SAP PI. 17.01.2011 Sinkwitz, Sven 519707 Theel, Thomas 519696

Dokumentation zum Projekt Mail-Adapter in SAP PI. 17.01.2011 Sinkwitz, Sven 519707 Theel, Thomas 519696 Dokumentation zum Projekt Mail-Adapter in SAP PI 17.01.2011 Sinkwitz, Sven 519707 Theel, Thomas 519696 Inhalt 1. Einleitung... 2 2. Vorgehen... 3 1. Datentyp für die Mail einrichten... 3 2. Message Typen

Mehr

2 Ist-Zustand des Systems 3

2 Ist-Zustand des Systems 3 Pflichtenheft Softwaretechnologie-Projekt für die ITC AG Gruppe 05 Tabelle 1: Historie Version Beschreibung Autor, Datum 0.1 Erstentwurf Sven Goly, 28.10.2014 0.2 Portierung in Latex, Kriterien Sven Goly,

Mehr

5.5.8 Öffentliche und private Eigenschaften

5.5.8 Öffentliche und private Eigenschaften 5.5.8 Öffentliche und private Eigenschaften Schnittstellen vs. Implementierungen: Schnittstelle einer Klasse beschreibt, was eine Klasse leistet und wie sie benutzt werden kann, ohne dass ihre Implementierung

Mehr

WebService-basierte Integration externer Datenquellen in relationale Datenbanksysteme

WebService-basierte Integration externer Datenquellen in relationale Datenbanksysteme WebService-basierte Integration externer Datenquellen in relationale Datenbanksysteme Workshop XML-Technologien für Middleware - Middleware für XML-Anwendungen XMIDX 2003 Berlin, 17. Februar 2003 Vortragender:

Mehr

Anbindung externer Webanwendung an PDF- AS-WEB 4.0

Anbindung externer Webanwendung an PDF- AS-WEB 4.0 Dokumentation Anbindung externer Webanwendung an PDF- AS-WEB 4.0 Anbindung einer externen Webanwendung an PDF-AS-WEB 4.0 Version 0.3, 05.06.2014 Andreas Fitzek andreas.fitzek@egiz.gv.at Christian Maierhofer

Mehr

Seminar E-Services (SES 02)

Seminar E-Services (SES 02) Seminar E-Services (SES 02) Einführungsveranstaltung Übersicht Die VSIS Gruppe Inhalte & Lehre Seminareinführung Formales Seminarthemen Referate & Termine Page 2 VSIS Gruppe Verteilte Systeme und Informations-Systeme

Mehr

Datenbank-basierte Webserver

Datenbank-basierte Webserver Datenbank-basierte Webserver Datenbank-Funktion steht im Vordergrund Web-Schnittstelle für Eingabe, Wartung oder Ausgabe von Daten Datenbank läuft im Hintergrund und liefert Daten für bestimmte Seiten

Mehr

XML und Web Services. Mario Jeckle DaimlerChrysler Forschungszentrum Ulm mario.jeckle@daimlerchrysler.com mario@jeckle.de www.jeckle.

XML und Web Services. Mario Jeckle DaimlerChrysler Forschungszentrum Ulm mario.jeckle@daimlerchrysler.com mario@jeckle.de www.jeckle. XML und s Mario Jeckle DaimlerChrysler Forschungszentrum Ulm mario.jeckle@daimlerchrysler.com mario@jeckle.de www.jeckle.de Gliederung I. XML Herkunft und Hintergrund Die evolution Wo stehen wir heute?

Mehr

1 Übungsaufgaben mit Lösungen YAWL-System

1 Übungsaufgaben mit Lösungen YAWL-System 1 Übungsaufgaben mit Lösungen YAWL-System 1.1 Beispiel für das YAWL System (Reisebuchungsszenario) Um den Umgang mit YAWL und insbesondere mit dem YAWL-editor zu illustrieren soll ein Beispiel bearbeitet

Mehr

Abschlussklausur Geschäftsprozessmodellierung und Workflowmanagement

Abschlussklausur Geschäftsprozessmodellierung und Workflowmanagement Abschlussklausur Geschäftsprozessmodellierung und Workflowmanagement (Wintersemester 2007/2008, Freitag, 08.02.2008, Leo18) Es können maximal 120 Punkte erreicht werden. 1 Punkt entspricht etwa einer Minute

Mehr

Termin 4: Web Services Computing

Termin 4: Web Services Computing Arbeitsgruppe Übung Netzbasierte Informationssysteme Termin 4: Web Services Computing Prof. Dr. Adrian Paschke Arbeitsgruppe Corporate Semantic Web (AG-CSW) Institut für Informatik, Freie Universität Berlin

Mehr

An Geschäftsprozessen ausgerichtete IT- Infrastruktur. In SOA werden Services (Dienste) lose miteinander verbunden.

An Geschäftsprozessen ausgerichtete IT- Infrastruktur. In SOA werden Services (Dienste) lose miteinander verbunden. SOA - Service Oriented Architecture An Geschäftsprozessen ausgerichtete IT- Infrastruktur. In SOA werden Services (Dienste) lose miteinander verbunden. Service Provider (bietet den Dienst an) Service Consumer

Mehr

Produktskizze. 28. November 2005 Projektgruppe Syspect

Produktskizze. 28. November 2005 Projektgruppe Syspect 28. November 2005 Carl von Ossietzky Universität Oldenburg Fakultät II Department für Informatik Abteilung Entwicklung korrekter Systeme Inhaltsverzeichnis 1 Einleitung 3 2 Die graphische Oberfläche der

Mehr

Implementierung von Web Services: Teil I: Einleitung / SOAP

Implementierung von Web Services: Teil I: Einleitung / SOAP Implementierung von Web Services: Teil I: Einleitung / SOAP Prof. Dr. Kanne - FSS 2007 Carl-Christian Kanne, February 25, 2007 Web Services - p. 1/12 Web Services: Allgemein XML Datenaustauschformat plattformunabhängig

Mehr

B2B für meine Geschäftspartner

B2B für meine Geschäftspartner B2B für meine Geschäftspartner Michael Stapf Oracle Deutschland B.V. & Co. KG Frankfurt Schlüsselworte B2B, Business-to-Business, Geschäftspartnerintegration, Elektronische Geschäftskommunikation Einleitung

Mehr

Kapitel WT:VI (Fortsetzung)

Kapitel WT:VI (Fortsetzung) Kapitel WT:VI (Fortsetzung) VI. Architekturen und Middleware-Technologien Client--Architekturen Ajax REST RPC, XML-RPC, Java RMI, DCOM Web-Services CORBA Message-oriented-Middleware MOM Enterprise Application

Mehr

SAS Metadatenmanagement Reporting und Analyse

SAS Metadatenmanagement Reporting und Analyse SAS Metadatenmanagement Reporting und Analyse Melanie Hinz mayato GmbH Am Borsigturm 9 Berlin melanie.hinz@mayato.com Zusammenfassung Metadaten sind seit Version 9 ein wichtiger Bestandteil von SAS. Neben

Mehr

Szenario 3: Service mit erweiterter Schnittstelle

Szenario 3: Service mit erweiterter Schnittstelle 2. Hintergrundverarbeitung in Android: Services und Notifications Szenarien für lokale Services Szenario 3: Service mit erweiterter Schnittstelle Ein Service bietet zusätzliche Methoden an, über die sich

Mehr

Geschäftsprozessimplementierung mit BPMN, ADF und WebCenter

Geschäftsprozessimplementierung mit BPMN, ADF und WebCenter Geschäftsprozessimplementierung mit BPMN, ADF und WebCenter Johannes Michler PROMATIS software GmbH Ettlingen Schlüsselworte Geschäftsprozess, Horus, SOA, BPMN, ADF, WebCenter Einleitung Die Umsetzung

Mehr