Geschäftsprozessmodellierung mit BPEL

Transkript

1 Hochschule RheinMain University of Applied Sciences Wiesbaden Rüsselsheim Geisenheim Geschäftsprozessmodellierung mit BPEL Seminararbeit des Masterstudiengangs Informatik Seminarleiter: Prof. Dr.-Ing. Karl-Otto Linn von Stefan Berntheisel Wintersemester 2009/2010 Version Final

2 Inhaltsverzeichnis 1 Einleitung 1 2 Grundlagen XML WSDL SOAP XML-Schema XPath Definition des Geschäftsprozesses Orchestrierung und Choreographie Workflow-Referenz-Modell Process Definition Tools Invoked Applications Workflow Client Applications Workflow Engine Administration and Monitoring Tools Other Workflow Engines Business Process Execution Language Eigenschaften Historie Aktuell Struktur eines BPEL-Dokuments BPEL-Prozess - <process> Erweiterungen - <extensions> Dokumentenreferenzen - <import> Partnerbeziehungen - <partnerlinks> Nachrichtenaustausch - <messageexchanges> Variablen - <variables> Korrelationsmengen - <correlationsets> Fehlerbehandlung - <faulthandlers> Ereignisbehandlung - <eventhandlers> Basisaktivitäten Aufruf eines Web Services - <invoke> Anbieten eines Web Services - <receive>, <reply> Datenzuweisung - <assign> Warten - <wait> Fehlersignalisierung - <throw> Prozessbeendung - <exit> i

3 3.5.7 Platzhalter - <empty> Strukturierte Aktivitäten Kapselung von Aktivitäten - <scope> Sequenzielle Ausführung - <sequence> Parallele Ausführung - <flow> Nicht-deterministische Ausführung - <pick> Bedingte Ausführung - <if>, <elseif>, <else> Schleifen - <while>, <repeatuntil>, <foreach> Weitere Eigenschaften von BPEL Umsetzung eines Beispiel-Szenarios Definition eines Geschäftsprozesses Definition des Datenflusses Erstellung der Datentypen Erstellung der Web-Service-Schnittstellen Erstellung des BPEL-Prozesses Vorbereitung Modellierung des Geschäftsprozesses Fazit 29 ii

4 Abbildungsverzeichnis 1 Orchestrierung Choreographie Workflow-Referenz-Modell iii

5 Listings 1 BPEL-Dokumentenstruktur Variablen Fehlerbehandlung Aufruf eines Web-Services - <invoke> Anbieten eines Web-Services - <receive> Anbieten eines Web-Services - <reply> Datenzuweisung - <assign> Kapselung von Aktivitäten - <scope> Sequenzielle Ausführung - <sequence> Parallele Ausführung - <flow> Nicht-deterministische Ausführung - <pick> Bedingte Ausführung - <if>, <elseif>, <else> Schleifen - <while> Kreditanfrage.xsd - atomare Grunddatentypen Kreditanfrage.xsd - abstrakte Datentypen Kreditanfrage.xsd - komplexe Datentypen Bank.wsdl - Datentypen importieren Bank.wsdl - Nachrichtendefinition Bank.wsdl - Schnittstelle und Operation Bank.wsdl - Partnerbeziehung ermöglichen BPEL-Prozess.xml - Prozessnamen und Namensräume BPEL-Prozess.xml - Ressourcen importieren BPEL-Prozess.xml - Partnerbeziehungen referenzieren BPEL-Prozess.xml - Variablen festlegen BPEL-Prozess.xml - Web-Service anbieten BPEL-Prozess.xml - Vorbereitung der Rating-Agentur-Anfrage BPEL-Prozess.xml - Anfrage an Rating-Agentur ausführen BPEL-Prozess.xml - 1. Fall - Bedingung BPEL-Prozess.xml - 1. Fall - Vorbereitung der Kundenantwort BPEL-Prozess.xml - 1. Fall - Antwort an Kunde BPEL-Prozess.xml - 2. Fall - Bedingung BPEL-Prozess.xml - 2. Fall - Vorbereitung der Kreditanfrage BPEL-Prozess.xml - 2. Fall - Antwort an Kunde BPEL-Prozess.xml - 3. Fall - Antwort an Kunde BPEL-Prozess.xml - Ende der Verzweigung iv

6 Abstract Focus of this seminar is the Business Process Execution Language (BPEL). Main criteria of BPEL is to create complex business processes with the help of electronic services that are offered through web services. The introduction part addresses the current relevance of BPEL and the motivation for this topic. After the introduction the seminar addresses relevant basics that are needed before using BPEL as a modeling language. Topics that are outlined in the basics part are different XML standards, two general processing models, consisting of orchestration and choreography, and the workflow reference model as a general understanding model. These basics, amongst others, play an important role in the context of BPEL. The main section exclusively deals with the Business Process Execution Language and apart from addressing the language specification also discusses characteristics, history and current problems. The focus of the language specification lies both on the basic and the structured activities. Subsequently the use of BPEL will be demonstrated with the help of an example scenario. In the final part of the seminar the expertise of BPEL will be summarized in a conclusion. Zusammenfassung Schwerpunkt dieser Seminararbeit ist die Business Process Execution Language (BPEL). BPEL erlaubt es, elektronische Dienste (Services), die über Web Services angeboten werden zu komplexen Geschäftsprozessen zusammenzufassen. Einleitend wird auf die aktuelle Relevanz der BPEL eingegangen und für das Thema motiviert. Um BPEL als Modellierungssprache einsetzen zu können werden zuvor noch relevante Grundlagen vermittelt. Zu den erläuterten Grundlagen, die im Kontext von BPEL eine wichtige Rolle spielen, zählen verschiedene XML-Standards, zwei generelle Verarbeitungsmodelle, bestehend aus Orchestrierung und Choreographie und das Workflow-Referenz- Modell als allgemeines Verständnismodell. Der Hauptteil befasst sich ausschließlich mit der Business Process Execution Language und geht neben der Sprachspezifikation auch auf Eigenschaften, Historie und aktuelle Probleme ein. Der Fokus der Sprachspezifikation liegt sowohl auf den Basis- als auch auf den strukturierten Aktivitäten. Anschließend wird der Einsatz von BPEL anhand eines Beispiel-Szenarios demonstriert. Im Schlussteil werden die Erkenntnisse zu BPEL in einem Fazit zusammengefasst. v

7 1 Einleitung Die Service-orientierte Architektur (SOA) oder auch dienstorientierte Architektur ist mittlerweile ein etabliertes Paradigma, das im Bereich der verteilten Systeme eine immer stärkere Rolle spielt. Der zentrale Ansatz der SOA besteht darin, vorhandene Systemfunktionalitäten über standardisierte Schnittstellen in Form von öffentlichen Diensten (Services) bereitzustellen. Die SOA kann somit als ein Netzwerk aufgefasst werden, in dem verschiedene Dienste angeboten, gesucht und genutzt werden können. SOA schafft damit die Grundlagen, um Geschäftsprozesse (Workflows) über die in einem Netzwerk vorhandenen Dienste abzubilden. Um beliebige Dienste in einem Netzwerk anbieten zu können, wird hauptsächlich auf die Technologie der Web Services zurückgegriffen, da diese ein Höchstmaß an Interoperabilität gewährleisten. In den letzten Jahren wurden seitens verschiedener Hersteller und Gremien unterschiedliche Ansätze zur Abbildung und Verarbeitung von Geschäftsprozessen in verteilten Umgebungen entwickelt und spezifiziert. Dabei wird aktuell die Business Process Execution Language (BPEL) als besonders vielversprechend angesehen. Die BPEL wurde in der Version 2.0 durch die Organization for the Advancement of Structured Information Standards (OASIS) entwickelt und ist zudem als ein Web Service Standard (WS-*) unter dem Namen WS-BPEL bekannt [3]. BPEL erlaubt es beliebige Geschäftsprozesse zu modellieren, die aus Diensten bestehen, welche über Web Services angeboten werden. BPEL ist eine XML-basierte Sprache und bietet Sprachelemente für die Verarbeitung von Dienstanfragen und -antworten, Prozessvariablen, Kontrollstrukturen und Mechanismen zur Fehlerbehandlung. Im Rahmen von verteilten Geschäftsprozessen ist BPEL zu einem der wichtigsten Schlagwörter geworden, aus diesem Grund bot es sich an, die Grundlagen von BPEL im Rahmen eines Fachseminars näher zu vertiefen. 2 Grundlagen Der Grundlagenteil ist in einen technischen und einen theoretischen Abschnitt gegliedert. Im technischen Abschnitt wird kurz auf die Kerntechnologien eingegangen, die innerhalb des BPEL-Umfeldes benötigt werden. Im theoretischen Abschnitt werden Ansätze und Verfahren erläutert, mit denen Geschäftsprozesse in verteilten Umgebungen abgebildet werden können. Der Übergang zwischen den Abschnitten ist fließend. 1

8 2.1 XML Die Extensible Markup Language (XML) ist eine Auszeichnungssprache zur Darstellung hierarchisch strukturierter Daten in Form von Textdaten [9]. Die XML definiert zudem eine Metasprache, auf deren Basis strukturelle und inhaltliche Einschränkungen anwendungsspezifischer Sprachen (siehe WSDL oder SOAP) festgelegt werden. XML kann damit als herstellerunabhängige Schlüsseltechnologie betrachtet werden, die die Basis für einen interoperablen Datenaustausch darstellt. Die erste XML-Spezifikation wurde im Februar 1998 durch das World Wide Web Consortium (W3C) als Standard freigegeben und im November 2008 in der fünften Auflage spezifiziert. 2.2 WSDL Die Web Services Description Language (WSDL) ist eine wichtige Komponente im Rahmen der Service-orientierten Architektur, denn sie ermöglicht es, eine plattform-, programmiersprachen- und protokollunabhängige Beschreibung von Web-Service-Schnittstellen durchzuführen [5]. Mit der WSDL lassen sich Web Services sowohl auf der abstrakten Ebene der Funktionalität als auch auf der konkreten Ebene der technischen Details beschreiben. WSDL basiert auf der XML-Spezifikation und ist selbst als Metasprache definiert. Die WSDL-Spezifikation gibt es seit März 2001 in der Version 1.1 und seit Juli 2007 in der Version 2.0. Letztere wird auch durch das W3C empfohlen. Der Einsatz der WSDL 2.0 ist allerdings nur selten in realen Systemen zu finden, dort wird größtenteils immer noch die WSDL 1.1 eingesetzt. 2.3 SOAP SOAP, ursprünglich als Simple Object Access Protocol bezeichnet, ist ein leichtgewichtiges Netzwerkprotokoll mit dem XML-basierte Nachrichten zwischen zwei Service-Endpunkten ausgetauscht werden können [7]. Das Protokoll macht keine Vorschriften darüber, wie die Semantik applikationsspezifischer Daten, auszusehen hat. SOAP kann als ein Rahmenwerk (Framework) verstanden werden, das Regeln festlegt wie Daten von Netzwerknachrichten abzubilden und zu interpretieren sind. SOAP wird meist in Verbindung mit TCP/IP und HTTP als Transportprotokolle genannt, diese sind jedoch beliebig austauschbar. 2

9 2.4 XML-Schema XML-Schema ist eine von der W3C empfohlene Schemasprache, die es ermöglicht, Strukturen von Datentypen in XML-Dokumenten zu beschreiben [6]. Mit XML-Schema können einfache atomare Datentypen zu neuen komplexen Datentypen zusammengefasst werden. XML-Schema wird innerhalb von WSDL und BPEL genutzt, um Datentypen zu beschreiben. 2.5 XPath XML Path Language (XPath) ist eine von der W3C im Jahre 2002 entwickelte Abfragesprache, über die ausgewählte Teile eines XML-Dokuments adressiert werden können [8]. XPath modelliert dazu die abstrakte und logische Struktur eines XML-Dokuments als Baum bestehend aus XML-Knoten. Zur Navigation in dieser Baumstruktur benutzt XPath eine Nicht-XML-Syntax. XPath wird zusätzlich von einer eigenen Funktionsbibliothek unterstützt, die zur Navigation, Manipulation und zur Validierung von Knoten oder Knotenmengen genutzt werden kann. 2.6 Definition des Geschäftsprozesses Unter einem Geschäftsprozess (Workflow) versteht man die Abarbeitung einer festgelegten Abfolge von verschiedenen Aktivitäten im Rahmen einer oder mehrerer Organisationseinheiten. Die Festschreibung eines Arbeitsablaufes dient einerseits zum globalen Verständnis eines komplexen Prozesses, andererseits ist sie erforderlich, um eine immer gleichbleibende Produkt- und Servicequalität zu gewährleisten. Ein Geschäftsprozess kann je nach Zielgruppe auf verschiedenen Abstraktionsebenen beschrieben werden. Im Rahmen von SOA werden Geschäftsprozesse meist aus einer technischen Sicht betrachtet. So sind die an einem Geschäftsprozess beteiligten Akteure aus Sicht der SOA in der Regel keine Menschen, sondern überwiegend Dienste. Dies schafft die Grundlage, um völlig automatisierte Geschäftsprozesse realisieren zu können. 2.7 Orchestrierung und Choreographie Im Rahmen von verteilten Diensten werden im Zusammenhang mit Geschäftsprozessen oft die beiden Begrifflichkeiten Orchestrierung und Choreographie genannt. Beide Begriffe beschreiben ein Verarbeitungsmodell für Workflow-Aktivitäten und werden im Folgenden mit Hilfe der Quellen [1] und [2] näher erläutert. 3

10 Die Orchestrierung beschreibt einen Geschäftsprozess aus der Sicht des Prozesses selbst. Besteht ein Geschäftsprozess aus verschiedenen Prozessaktivitäten, die innerhalb eines zentralen Steuerungsprozesses koordiniert werden, spricht man immer von einer Orchestrierung, siehe Abbildung 1. Die komplette Geschäftslogik des Workflows ist somit in einem einzigen Steuerungsprozess gekapselt. Innerhalb dieses Steuerungsprozesses ist genau definiert wie der Daten- und Informationsfluss zwischen den verschiedenen Prozessaktivitäten auszusehen hat. Aus der Sicht der Web Services bedeutet dies, dass der zentrale Steuerungsprozess in der Lage sein muss, Service-Anfragen zu senden, Service-Antworten zu empfangen und diese entsprechend weiterzuverarbeiten. In Fall einer Orchestrierung haben die einzelnen Web Services keine Kenntnisse voneinander. Die Koordination erfolgt alleine durch den zentralen Steuerungsprozess und die beteiligten Web Services weisen generell ein Request/Response-Verhalten auf. Bei der Orchestrierung wird die Verantwortung einer Service-Anfrage an den Aufrufer zurückübertragen, man spricht dann auch von Prozess-Diensten (process services). Abbildung 1: Orchestrierung Die Choreographie beschreibt das Zusammenspiel von mehreren Prozessen aus Sicht der Zusammenarbeit. Besteht ein Geschäftsprozess aus verschiedenen Prozessaktivitäten, die sich selbst ohne einen zentralen Steuerungsprozess gegenseitig koordinieren können, spricht man von einer Choreographie, siehe Abbildung 2. Die komplette Geschäftslogik des Workflows ist somit über die an ihm beteiligten Prozessaktivitäten verteilt. Innerhalb jeder Prozessaktivität ist genau definiert wie der Daten- und Informationsfluss auszusehen hat, der zwischen den an einem Geschäftsprozess beteiligten Aktivitäten stattfindet. Aus Sicht der Web Services bedeutet dies, dass jede Prozessaktivität, die durch eine Service-Anfrage ausgelöst wurde, selbstständig in der Lage sein muss, die aus der Anfrage entstehende Service-Antwort an den im Workflow stehenden Folgeprozess weiterzureichen. Im Falle einer Choreographie weisen die beteiligten Web Services in der Regel ein One-Way-Verhalten auf. Die Verantwortung bezüglich einer Service-Anfrage wird hier nicht an den Aufrufer zurückübertragen, sondern an einen anderen Prozess weitergereicht, man spricht dann auch von komponierten-diensten (composed services). 4

11 Abbildung 2: Choreographie 2.8 Workflow-Referenz-Modell Wie bereits erwähnt, wurden in den letzten Jahren seitens verschiedener Hersteller und Gremien unterschiedliche Ansätze zur Abbildung und Verarbeitung von Geschäftsprozessen entwickelt und spezifiziert. Aus diesem Grund wurde im Jahr 1993 die Workflow Management Coalition (WfMC) mit dem Ziel gegründet, eine Standardisierung der Interoperabilität verschiedener Workflow Management Systeme festzulegen. Dazu veröffentlichte die WfMC im Jahre 1995 ihr Workflow Reference Model, welches heute noch die Grundlage von Business Process Modelling (BPM) und vieler verschiedener Workflow Management Systeme ist, siehe Abbildung 3. Das Workflow-Referenz- Modell verfolgt im Allgemeinen den Ansatz der Orchestrierung. Im Folgenden werden die zentralen Komponenten dieses Workflow-Referenz-Modells nach [4] erläutert. Abbildung 3: Workflow-Referenz-Modell 5

12 2.8.1 Process Definition Tools Über die Komponente Process Definition Tools erfolgt die Definition bzw. Modellierung des Workflows. Die Modellierung kann durch grafische Modellierungswerkzeuge unterstützt werden. Sollten bei der Modellierung herstellerabhängige Modellierungssprachen verwendet werden, ist eine Interoperabilität nicht mehr gewährleistet Invoked Applications Die Invoked Applications beschreiben die Systeme und Anwendungen, die ihre Funktionalität in Form von Diensten über eine standardisierte Schnittstelle bereitstellen. Diese Dienste können dann innerhalb eines Geschäftsprozesses modelliert und eingesetzt werden Workflow Client Applications Mit Hilfe der Workflow Client Applications können Schnittstellen zu menschlichen Prozessaktivitäten geschaffen werden, die sich dann im Rahmen eines elektronischen Geschäftsprozesses modellieren und einsetzen lassen Workflow Engine Die Workflow Engine führt als zentrale Komponente den modellierten Geschäftsprozess aus. Dabei ist es unerheblich in welcher Programmiersprache die Workflow Engine implementiert ist, sie muss nur in der Lage sein, die Modellierungssprache des Geschäftsprozesses verarbeiten bzw. interpretieren zu können Administration and Monitoring Tools Über die Komponente Administration and Monitoring Tools ist es möglich, einen Prozess zur Laufzeit zu überwachen und zu managen Other Workflow Engines Durch die Komponente Other Workflow Engines soll es möglich sein, bereits bestehende Geschäftsprozesse aus anderen Systemen oder Bereichen mit den eigenen zu verknüpfen. 6

13 3 Business Process Execution Language Im Hauptteil dieser Arbeit wird ausschließlich die als Web Service Standard spezifizierte Business Process Execution Language (BPEL) in der Version 2.0 behandelt. Dazu erfolgt eine Gliederung in mehrere Schwerpunkte. Im ersten Abschnitt wird kurz auf die generellen Eigenschaften, die Entstehung und aktuelle Probleme von BPEL eingegangen. Im zweiten Abschnitt werden dann die Sprachelemente und deren Funktionen näher erläutert. Der Übergang zwischen den Abschnitten ist fließend. 3.1 Eigenschaften Mit BPEL können über Web Services angebotene Dienste im Rahmen eines Geschäftsprozesses orchestriert werden. BPEL ist eine XML-basierte Sprache zur Beschreibung fachlicher Abläufe aus der technischen Sicht eines zentralen Steuerungsprozesses. Für die Modellierung von automatisierten Geschäftsprozessen benutzt BPEL standardisierte und semantisch festgelegte Sprachelemente. Dazu kapselt BPEL einen Geschäftsprozess beliebiger Komplexität innerhalb eines XML-Dokuments (BPEL-Dokument). Die Sprachelemente, die innerhalb eines BPEL-Prozesses verwendet werden dürfen, sind über ein festgelegtes XML-Schema definiert. Für die Interaktion mit verteilten Diensten nutzt BPEL die im Rahmen von Web Services bekannte WSDL-Spezifikation in der Version 1.1. BPEL ist dabei eng mit der WSDL- Spezifikation verwoben, so kann jeder in BPEL erstellte Geschäftsprozess selbst wieder über einen in WSDL beschriebenen Web Service zugänglich gemacht und in weiteren Geschäftsprozessen verwendet werden. BPEL ist zudem in der Lage, die innerhalb eines Geschäftsprozesses ausgetauschten Service-Informationen zu verarbeiten. Aus diesem Grund kann BPEL auch als imperative Programmiersprache verstanden werden, in der es Variablen, Funktionen, Kontrollstrukturen und Mechanismen zur Fehlerbehandlung gibt. 3.2 Historie Im Jahre 2001 wurde erstmals die Business Process Modeling Language (BPML) von der Business Process Management Initiation (BPMI) eingeführt. Die BPML beschreibt eine XML-basierte Sprache zur Beschreibung von Geschäftsprozessen und ist ein Teil des von der BPMI spezifizierten Frameworks. Die BPMI ist heute über einen Zusammenschluss mit der Open Management Group (OMG) unter dem Namen Business Modeling and Integration (BMI) Domain Task Force (DTF) zu finden. Auf Grund des großen Erfolgs und Zuspruchs der BPML haben sich IBM und Microsoft dazu entschlossen, 7

14 eine vergleichbare Sprache zu entwickeln. In diesem Zusammenhang wurde im Jahr 2002 die erste BPEL-Spezifikation unter dem Namen BPEL4WS 1.0 veröffentlicht. BPEL4WS ist eine Kombination aus der von IBM entwickelten graphenbasierten Web Service Flow Language (WSFL) und der von Microsoft entwickelten kalkülbasierten Sprache XLANG. Ein Jahr später wurde BPEL4WS in der Version 1.1 durch BEA Systems, IBM, Microsoft, SAP und Siebel Systems im Rahmen des Web Service BPEL Technical Commitee bei der OASIS als Standard eingereicht. Im Jahre 2004 entschied sich die OASIS dafür eine Anpassung an die bestehenden Web Service Standards vorzunehmen. Im Zuge dessen sollte auch die Umbenennung zu WS-BPEL erfolgen. Die durch das BPMI entwickelte BPML wurde zugunsten der Weiterentwicklung von WS-BPEL aufgegeben. Im Jahre 2007 erfolgte dann die Fertigstellung des WS-BPEL 2.0 Standards [2]. 3.3 Aktuell Aktuell bestehen im Zusammenhang mit BPEL einige Probleme. Ein Problem besteht darin, dass BPEL über keine standardisierte, visuelle Notation verfügt, was dazu geführt hat, dass im Moment verschiedene herstellerabhängige Notationen auf dem Markt vertreten sind. Es gibt aber Bestrebungen, eine standardisierte Notation einzuführen bzw. die Überführung in vorhandene Notationen zu realisieren. Die durch das OMG definierte Business Process Modeling Notation (BPMN) spielt hierbei eine wichtige Rolle. Die BPMN ist eine grafische Notation zur Modellierung von Geschäftsprozessen. Die Wurzeln der BPMN liegen in der durch die OMG entwickelte Universal Modeling Language (UML) und der von SAP entwickelten ereignisgesteuerten Prozesskette (EPK). Die gegenseitige Abbildung zwischen BPEL und BPMN ist jedoch eine große Herausforderung. Eines der Hauptprobleme in diesem Zusammenhang ist, dass BPEL den Geschäftsprozess aus Sicht eines technischen Experten, die BPMN dagegen aus Sicht eines fachlichen Experten beschreibt. Dieses Problem soll mit dem ebenfalls durch die OMG entwickelten Standard Business Process Definition Metamodel (BPDM) gelöst werden. Mit Hilfe des BPDM soll es möglich sein, verschiedene Geschäftsprozessmodelle ineinander zu überführen. Ein weiteres Problem der BPEL besteht darin, dass sich keine Geschäftsprozesse modellieren lassen, in denen menschliche Interaktionen abgebildet werden können. Aus diesem Grund wurde BPEL um den von Adobe, IBM, BEA, Oracle, SAP und Active Endpoints entwickelten und bei OASIS eingereichten Standard BPEL4People erweitert. BPEL4People baut auf den von OASIS definierten Standard HumanTask auf. BPEL4People und HumanTask sind beide ebenfalls Web Service Standards [1]. 8

15 3.4 Struktur eines BPEL-Dokuments Wie bereits erwähnt, werden die in BPEL erstellten Geschäftsprozesse in einen XML-Dokument verwaltet. Im Folgenden wird die Struktur und die Bedeutung der in einem BPEL-Dokument verwendeten Sprachelemente erläutert BPEL-Prozess - <process> Das Wurzelelement eines jeden BPEL-Prozesses ist immer <process>. Innerhalb dieses Elementes müssen immer eine oder mehrere Aktivitäten (activities) enthalten sein. Die Aktivitäten repräsentieren einen beliebigen Ausführungsschritt innerhalb des Geschäftsprozesses. In BPEL wird zwischen Basisaktivitäten (basic activities) und strukturierten Aktivitäten (structured activities) unterschieden, die im Folgenden erläutert werden. 1 < process name =" ProcessName " > 2 3 < extensions >... </ extensions > 4 < import > 5 < partnerlinks >... </ partnerlinks > 6 < messageexchanges >... </ messageexchanges > 7 < variables >... </ variables > 8 < correlationsets >... </ correlationsets > 9 < faulthandlers >... </ faulthandlers > 10 < eventhandlers >... </ eventhandlers > <! to N activities --> </ process > Listing 1: BPEL-Dokumentenstruktur Erweiterungen - <extensions> Die BPEL-Spezifikation deckt bereits ein großes Spektrum von Aktivitäten und Funktionen zur Modellierung von Geschäftsprozessen ab. BPEL kann aber auch mit Hilfe der <extensions>, um neue Funktionen, wie z.b. die bereits erwähnte BPEL4People-Spezifikation, erweitert werden Dokumentenreferenzen - <import> Um externe Ressourcen wie z.b. WSDL- oder XML-Schema-Dateien zu referenzieren, wird <import> genutzt. 9

16 3.4.4 Partnerbeziehungen - <partnerlinks> Wie bereits angesprochen, ist BPEL eng mit der WSDL-Spezifikation verwoben. BPEL nutzt die WSDL, um mit den in ihr definierten Web Services zu interagieren. Aus Sicht des BPEL-Prozesses wird zwischen zwei Partnerbeziehungen unterschieden. Die erste Beziehung, der Service Partner, beschreibt Dienste, die direkt durch den BPEL-Prozess aufgerufen werden. Die zweite Beziehung, der Service Consumer, beschreibt Dienste, über die der BPEL- Prozess einem anderen Client zugänglich gemacht werden kann. Damit innerhalb eines BPEL-Dokuments die in der WSDL definierten Web-Service- Schnittstellen genutzt werden können, müssen diese entsprechend ihrer Partnerbeziehung über <partnerlinks> referenziert werden Nachrichtenaustausch - <messageexchanges> In BPEL besteht die Möglichkeit den Nachrichtenaustausch zwischen einem Service Consumer und dem BPEL-Prozess über den <messageexchange> eindeutig zu definieren. Dies ist in der Regel notwendig, wenn der Prozess über eine generische Schnittstelle aufgerufen wird und der weitere Verlauf innerhalb des Geschäftsprozesses anhand der eingehenden Nachrichteninformation entschieden werden soll Variablen - <variables> Geschäftsprozesse sind per Definition immer zustandsbehaftet. Der BPEL- Prozess muss in der Lage sein, auf die Informationen der ausgetauschten Nachrichten zurückzugreifen, um bezüglich der Geschäftslogik entsprechende Entscheidungen treffen zu können. Der Datentyp einer in BPEL verwendeten Variable kann über XML-Schema definiert werden. In der Regel entsprechen die Datentypen den in der WSDL definierten Nachrichtentypen, da diese die kompletten Parameter einer Web-Service-Anfrage und -Antwort enthalten. 1 < variables > 2 < variable name =" vorname " element =" xsd:string "/ > 3 < variable name =" adresse " type =" xsd:adresse "/> 4 < variable name =" daten " messagetype =" wsdl:bestellanfrage "/ > 5 </ variables > Listing 2: Variablen Korrelationsmengen - <correlationsets> Ein BPEL-Prozess kann in mehreren Instanzen ausgeführt werden. Die ausgeführten Instanzen können sich dabei generell in unterschiedlichen Pro- 10

17 zesszuständen befinden. Um die Antwortnachricht einer Service-Anfrage der richten Prozessinstanz zuzuordnen, braucht diese ein eindeutiges Merkmal, wie z.b. einen eindeutigen Schlüssel (unique key). BPEL benutzt für die Zuordnung von Nachrichten die in ihr enthaltenen Informationsfelder. Diese Informationsfelder werden in einer oder mehreren Korrelationsmengen <correlationsets> zusammengefasst und ermöglichen eine eindeutige Zuordnung der Nachrichten Fehlerbehandlung - <faulthandlers> Sollten bei der Ausführung eines BPEL-Prozesses Fehler auftreten, können diese mit entsprechenden <faulthandlers> behandelt werden. Fehler können beispielsweise innerhalb der Geschäftslogik oder durch fehlgeschlagene Service-Anfragen der am Geschäftsprozess beteiligten Dienste entstehen. 1 < faulthandlers > 2 <catch faultname =" NoDatabaseConnection " > 3 < compensate /> 4 </ catch > 5 < catchall > 6 <exit > 7 < catchall > 8 </ faulthandlers > Listing 3: Fehlerbehandlung Ereignisbehandlung - <eventhandlers> Innerhalb eines Geschäftsprozesses kann es vorkommen, dass der Prozess auf eine abgesetzte Service-Anfrage eine darauffolgende Service-Antwort zu einem unbekannten Zeitpunkt erhält. Dies bedeutet bei einer synchronen Anfrage, dass der Prozess bis zum Eintreffen der Antwort blockiert ist. Im asynchronen Fall könnte der Prozess weiterarbeiten, jedoch muss dieser einen <eventhandler> benutzen, um auf das zu einem beliebigen Zeitpunkt eintreffende Ereignis (Nachricht) reagieren zu können. 3.5 Basisaktivitäten Wie bereits erwähnt, repräsentieren die Aktivitäten in BPEL die Ausführungsschritte eines Geschäftsprozesses. Die Basisaktivitäten können aus Sicht des Geschäftsprozesses als atomare Operationen verstanden werden, die die Kommunikation und den Datenfluss innerhalb eines BPEL-Prozesses ermöglichen. Im Folgenden werden die Basisaktivitäten erläutert. 11

18 3.5.1 Aufruf eines Web Services - <invoke> Um innerhalb eines BPEL-Prozesses den Dienst eines Service Partners aufzurufen, wird <invoke> verwendet. Damit der Web Service des Partners aufgerufen werden kann, muss die bereits erläuterte Partnerbeziehung über das Attribut partnerlink angegeben werden. Der Aufruf des Web Services kann je nach Szenario entweder als One-Way- oder Request/Response-Operation erfolgen. Um das Verhalten einer One-Way-Operation abzubilden, wird nur das Attribut inputvariable für die jeweiligen Aufrufparameter angegeben. Um dagegen das Verhalten einer Request/Response-Operation abzubilden, wird zusätzlich noch das Attribut outputvariable für die entsprechenden Rückgabeparameter benötigt. 1 < invoke name =" meinaktienkurs " 2 partner =" Boerse " porttype =" boersens:aktienkurs " operation =" getkurs " 3 inputvariable =" meineunternehmensdaten " outputvariable =" aktienkurs "/ > Listing 4: Aufruf eines Web-Services - <invoke> Anbieten eines Web Services - <receive>, <reply> Um den BPEL-Prozess einem anderen Partner über Web Services zugänglich zu machen und diesem so einen Einstiegspunkt in den Geschäftsprozess zur Verfügung zu stellen, wird das Aktivitätenpaar <receive> und <reply> benötigt. Durch <receive> wird der Geschäftsprozess solange blockiert, bis seitens des Partners eine Nachricht eintrifft, die den BPEL-Prozess dazu veranlasst, zu starten oder fortzufahren. Mit dem dazugehörigen <reply> kann dem aufrufenden Partner eine aus dem Geschäftsprozess resultierende Antwort mitgeteilt werden. Der <reply> kann auch weggelassen werden, wenn der Geschäftsprozess selbst über keine Rückgabe verfügt. Auch hier müssen die jeweiligen Partnerbeziehungen wieder über das Attribut partnerlink angegeben werden. 1 < receive name =" anfragevonkunde " 2 partnerlink =" meinunternehmen:kunde " operation =" bestellung " 3 variable =" datenkundenanfrage "/ > Listing 5: Anbieten eines Web-Services - <receive> 1 <reply name =" antwortankunde " 2 partnerlink =" meinunternehmen:kunde " operation =" bestellung " 3 variable =" datenkundenantwort "/ > Listing 6: Anbieten eines Web-Services - <reply> 12

19 3.5.3 Datenzuweisung - <assign> Für die Datenzuweisung innerhalb eines BPEL-Prozesses wird <assign> benutzt. Um Daten oder Teile eines Datentyps einem anderen zuzuweisen, werden die beiden Unterelemente <from> und <to> benutzt. Diese beiden Elemente bieten verschiedene Attributkombinationen an, mit denen auf unterschiedliche Weise auf die vorhandenen Prozessvariablen zugegriffen werden kann. Die Zuweisung der Daten erfolgt immer von <from> zu <to>. Des Weiteren verfügt BPEL über eine XPath-Bibliothek, in der Funktionen zur Datenselektierung und -manipulation vorhanden sind. 1 < assign > 2 <copy > 3 <from variable =" datenkundeanfrage "/ > 4 <to variable =" datenbearbeitung "/ > 5 </ copy > 6 </ assign > Listing 7: Datenzuweisung - <assign> Warten - <wait> Geschäftsprozesse können mit <wait> zeitlich koordiniert werden, dazu werden die beiden Unterelemente <for> und <until> benutzt. Der Prozess kann mit <for> um eine vorgegebene Zeit und mit <until> um einen vorgegebenen Zeitpunkt angehalten bzw. verzögert werden Fehlersignalisierung - <throw> Zur Signalisierung von Fehlern innerhalb eines Geschäftsprozesses wird <throw> genutzt. Auf die durch <throw> ausgelöste Fehlersignalisierung kann mit Hilfe der bereits erwähnten Fehlerbehandlung <faulthandlers> reagiert werden Prozessbeendung - <exit> Um einen Prozess aus einem fehlerfreien Zustand beenden zu können, wird <exit> verwendet. Dies kann der Fall sein, wenn auf Grund der Geschäftslogik keine weitere Fortsetzung des Prozesses nötig ist Platzhalter - <empty> Innerhalb der Entwicklung eines Geschäftsprozesses kann es vorkommen, dass Teile des Prozesses zwar schon geplant, aber z.b. durch Service Partner oder 13

20 andere Gegebenheiten noch nicht implementiert sind. Um diese Aktivitäten vorab in den Geschäftsprozess aufnehmen zu können, wird <empty> als Platzhalter für zukünftige Aktivitäten verwendet. 3.6 Strukturierte Aktivitäten Die strukturierten Aktivitäten werden innerhalb eines BPEL-Prozesses einerseits dazu benötigt, um die Ausführungsreihenfolge beliebiger Aktivitäten festzulegen, andererseits um mit Hilfe von logischen Konstrukten beliebig komplexe Kontrollstrukturen abzubilden. Im Folgenden werden die strukturierten Aktivitäten erläutert Kapselung von Aktivitäten - <scope> Wie in Programmiersprachen üblich, gibt es auch in BPEL unterschiedliche Gültigkeitsbereiche für Variablen. Der Standard-Gültigkeitsbereich ist mit dem Wurzelelement <process> verbunden. In BPEL gilt ebenfalls der Grundsatz, dass lokale Variablen globale Variablen verdecken. 1 < process name =" meinprozess " > 2 <! -- Variable: var1 = > 3 <scope > 4 <! -- Variable: var1 = 0 -- > 5 <scope > 6 <! -- Variable: var1 = > 7 </ process > Listing 8: Kapselung von Aktivitäten - <scope> Sequenzielle Ausführung - <sequence> Eine <sequence> definiert eine geordnete Menge von Aktivitäten, die in lexigraphischer Ordnung, hintereinander ausgeführt werden. Eine <sequence> ist dann abgeschlossen, sobald die letzte Aktivität beendet ist. 1 < sequence > 2 <! -- Aktivität 1 --> 3 <! -- Aktivität 2 --> 4 <! -- Aktivität 3 --> 5 </ sequence > Listing 9: Sequenzielle Ausführung - <sequence> 14