Service-Orientierte Architekturen

Transkript

1 Hochschule Bonn-Rhein-Sieg Service-Orientierte Architekturen Kapitel 6: Web Services III Business Process Execution Language (BPEL) Vorlesung im Masterstudiengang Informatik Sommersemester 2010 Prof. Dr. Sascha Alda

2 (Vorläufiger) Aufbau der Vorlesung Kapitel Thema 1 Organisation, Einführung in Software-Architekturen 2 Einführung in Service-Orientierte Architekturen 3 Design Prinzipien von Service-Orientierten Architekturen 4 (11.5.) Web Services I (SOAP, WSDL) 5 (18.5.) Web Services II (Axis2, WS-Adressing) 6 (25.5.) Modellierung von Geschäftsprozessen (BPEL, BPMN) 7 (1.6.) Web Services IV 8 (8.6.) REST Architekturen 9 (15.6.) Einführung in Swordfish 11 (22.6.) Exception Handling in SOA (Gastvortrag) 12 (29.6.) SOA Point of View von Accenture (Gastvortrag) Folie 2

3 Ziele dieser Unterrichtseinheit Grundlagen des Web Services Framework erweitern Grundlagen der Geschäftsprozessmodellierung verstehen Den Standard BPEL zur Implementierung von Workflows verstehen und anwenden Einordnung BPEL zu den Grundprinzipien einer SOA Folie 3

4 Aufbau dieser Veranstaltung Kapitel 6: Web Services III, Einführung in BPEL 1 Wiederholung: Workflow Services 2 Grundlegender Aufbau eines BPEL-Workflow 3 Asynchrone Implementierung eines BPEL-Workflow 4 Fehlerbehandlung in einem BPEL-Workflow 5 Benutzerinteraktionen in einem BPEL-Workflow 6 Bewertung des BPEL-Ansatzes 7 Zusammenfassung und Ausblick Folie 4

5 Ziel: Flexible Integration der verschiedenen Subsysteme über fachlich definierte Services und Prozesse Benutzerinterfaces (User Interfaces) Business Processes (IT-unterstützte Geschäftsprozesse, Workflow) Services Prozess Archivierung von Rechnungen Business Services (Geschäftsfunktionen, fachliche Services) SAP FI Service CR Service Archiv Service PDF : printinvoice( Invoice) Invoice: getinvoice( Client ) removeclient( ID ) getclient( ID ) savepdf( pdf) Applikationen (Alt-Systeme, Legacy) SAP 2.0 FI System SAP R3 CO System Sub-Tochter (eignes Intranet) SAP Netweaver Oracle Siebel System Siebel System FI SAP R3 MM System SAP R3 System FI... Web Frontend

6 Abgrenzung Fachliche Services und Workflow Service Aus der Referenz-Architektur einer SOA ergeben sich zwei Typen von Services: Business Services (Fachliche Services) Business Process Services (Workflow Services) Fachliche Services repräsentieren eine zusammengefasste Funktionalität innerhalb einer Service-Orientierten Architektur Zugriff auf Backend und andere Services möglich, jedoch kein Prozess-Charakter erkennbar Konstante Implementierung, Änderung erfolgen über die Laufzeit einer Architektur nur selten Workflow Services fassen eine Menge von Services in einer vom Anwender definierten Reihenfolge zur Abarbeitung zusammen Prozess-Charakter erkennbar und explizit beschrieben Volatile Implementierung, wird über die Laufzeit einer Architektur potentiell oft verändert (z.b. wenn sich Prozesse in einer Firma ändern) Folie 6

7 Implementierung eines Workflow Services Wie lässt sich ein Workflow Service implementieren? Prozess Archivierung von Rechnungen Programmierung des Prozesses in einer Programmiersprache wie Java innerhalb eines Web Service (z.b. AXIS2) Vorteil: rasche, kostengünstige Entwicklung Nachteil: keine standardisierten Programmierkonstrukte, schlechte Portierbarkeit, schlechte Anpassbarkeit In einer deklarativen Prozesssprache (wie z.b. BPEL) Einführung von einfachen, programmiersprachneutralen Standardkonstrukten zur Beschreibung von Prozessen Besserer Tool-Support Bessere Portierbarkeit, bessere Anpassbarkeit Folie 7

9 Business Process Execution Language (BPEL) BPEL erlaubt die einfache Beschreibung von Workflows, deren einzelne Aktivitäten auf Web Services verzweigen Standardisiert von der OASIS, aktuelle Version 2.0 Hervorgegangen durch die Vorgängerstandards WSFL und XLANG Link: Basiert auf der Metasprache XML, kompatibel zum Web Services BP 1.1: Ein Workflow wird selber wieder als ein Web Services mittels WSDL beschrieben Zugriff auf einen Workflow mittels SOAP BPEL-Workflows werden, wie einfache Web Services auch, in einer speziellen Laufzeitumgebung ausgeführt BPEL-Beschreibungen sind ausführbar Keine graphische (Standard-)Notation vorhanden Alternative: Business Process Management Notation (BPMN) Folie 9

10 Literatur und Quellen Generell nur wenige gute Bücher auf dem Markt vorhanden über BPEL Gute Online Tutorials: https://blueprints.dev.java.net/bpcatalog/ee5/soa/ Folie 10

11 Grob-Aufbau eines BPEL-Workflow (High-Level) Business Process (als Web Service) activity1 invoke Service Provider A Web Service a Service User uses Consumer Application Interaktionskomponente oder fachliche Komponente request response activity4 activity2 Parallel flow activity5 activity3 invoke Service Provider B Web Service b Service Provider C Beschrieben durch invoke Web Service c <process> <sequence> <receive> <invoke> </invoke> <flow> </flow> <reply> </sequence> </process> BPEL file

12 Beispiel-Workflow für dieses Kapitel Der ChangePartnerService (Kapitel 5/6) soll als Workflow erweitert werden Konzentration auf die Änderung von Daten eines Partners (Operation changepartner) Die zu ändernden Daten werden auf einem externen Datenbank-Server abgespeichert Web Service als Schnittstelle vorhanden Nach der Abspeicherung der Daten eines soll der Vorgesetzter über diese Änderungen benachrichtigt werden Falls der Partner ein Manager ist: Benachrichtigung mit allen Daten an den Vorstand Falls der Partner kein Manager ist: Benachrichtigung an seinen Manager ohne Übermittlung der Daten Kapselung des ganzen Workflow durch einen Web Service Folie 12

13 Vorgehensweise bei der Entwicklung eines BPEL-Workflow Suche nach den relevanten Web Services (Analyse der Anforderungen) Definition der Schnittstelle des BPEL-Prozesses WSDL-Beschreibung Identifikation / Definition der Partner Link Types zu den relevanten Web Services Entwicklung des BPEL-Prozesses (.bpel File) Grundsätzliche Eigenschaften des BPEL-Prozesses Definition der Partner Links Einbindung aller Web Services Deklaration der internen Variablen Definition Workflow-Logik (Abfolge von Aktivitäten) [Ausnahmebehandlung] Deployment des BPEL-Workflow Abhängig von Laufzeitumgebung Meist zusammenfassendes Deployment des.bpel und des.wsdl Files Folie 13

14 Aufbau eines BPEL-Workflow Ein Workflow in BPEL ist hierarchisch durch XML beschrieben. Grob-Aufbau: <process name = PartnerChangeWorkflow > <import location = Service.WSDL.../> <partnerlinks>... </partnerlinks> <variables>... <variables> <sequence> // Grundlegende Aktivitäten (invoke, receive, reply, wait..) // Strukturierende Aktivitäten (if... else, Switch,...) </sequence> </process> Folie 14

15 Definition der Namespaces und Import von WSDLs Im Tag <process> werden alle zu referenzierenden Namespaces definiert Im Tag <import> werden alle notwendigen WSDLs in den BPEL-Prozess import. Im Einzelnen: Namespaces aller intern verwendeten Web Services Namespace der WSDL-Beschreibung des BPEL-Prozesses (= Sicht Client) <process name = PartnerChangeWorkflow xmlns:chs = "http:/myserver.com/bpel/change/" xmlns:dbs = "http:/myserver.com/services/dbsave/" xmlns:nos = "http:/myserver.com/services/dbsave/" > <import location = file://... ChangeService.wsdl... /> <import location = DatabaseService.wsdl.../> <import location = NotificationService.wsdl.../>... </process> Folie 15

16 Partner Link Types Partner Link Types repräsentieren die abstrakten Verbindungen zwischen einem BPEL Prozess und allen involvierten Web Services: Web Services (Client), der den BPEL Prozess aufruft Web Services, die der BPEL Prozess selbst intern aufruft Partner Link Types referenzieren innerhalb von WSDL auf PortTypes Jeder Partner Link Type wird in dem WSDL-File des Web Service beschrieben: <<Client>> Application Service Provider (BPEL-Workflow als Web Service) PartnerChangeWorkflow Service Provider B Database Service WSDL-File <partnerlinktype name = DB-Access > WSDL-File WSDL-File Service Provider C Notification Service Folie 16

17 Partner Link Types in WSDL Ein Partner-Link Type referenziert durch eine Rolle einen PortType innerhalb eines WSDL-Files um den Aufruf des Web Service zu definieren Synchroner Aufruf: Rückgabe erfolgt über die gleiche Operation eines PortType Asynchroner Aufruf: Zusätzlicher Rolle / PortType notwendig (später mehr dazu...) <definitions name = DatabaseService > <types>... </types> <porttype name = DatabaseWrite >... <porttype> </porttypes> <bindings>... </bindings> <plnk:partnerlinktype name= DB-Access"> <plnk:role name= savedataforchange"> <plnk:porttype name="tns:databasewrite" /> </plnk:role> </plnk:partnerlinktype>... <definitions> WSDL-Auszug zur Definition des Web Service DatabaseService Folie 17

18 Partner Links Partner Links repräsentieren konkrete Verbindungen zu Web Services, die mit dem BPEL Prozess interagieren Jeder Partner Link bezieht sich zu einem konkreten Partner Link Type (aus importierten WSDL-Files) Zu einem Partner Link Type kann es mehrere Partner Links geben <process name = PartnerChangeWorkflow > <partnerlinks> <partnerlink name = client partnerlinktype = chs:changeservice partnerrole = ChangeServiceClient /> <partnerlink name = managernotification // vorstandnotifcation partnerlinktype = nos:notificationservice partnerrole = notificationservice /> <partnerlink name = databaseconnection partnerlinktype = dbs:db-access partnerrole = savedataforchange />... </partnerlinks>... BPEL-Auszug zur Definition der Partner Links Folie 18

19 Variablen innerhalb eines BPEL-Workflow Variablen werden eingesetzt, um Nachrichten innerhalb eines BPEL- Workflow zwischenzuspeichern und ggf. zu ändern Eine Variable pro Nachricht, die von einem Web Services empfangen wird bzw. die verschickt wird. Angabe eines Nachrichtentyps ist notwendig: Übernahme aus dem WSDL-Files der Web Services Eigene Typ-Definition z.b. aus einem XML-Schema <variables> <variable name = changerequest messagetype = chs:changerequest /> <variable name = changeresponse messagetype = chs:changeresponse /> <variable name = notificationrequest messagetype = nos:notificationrequest /> <variable name = notificationresponse messagetype = nos:notificationresponse />... </variables> Folie 19

20 Grundlegende Aktivitäten in BPEL Ein BPEL-Prozess besteht aus besteht aus einzelnen Schritten, auch Aktivität bezeichnet. Grundlegende Aktivitäten (primitive activities) repräsentieren einfache, atomare Aktivitäten innerhalb eines Workflows. Aufruf eines externen Services (<invoke>) (Rück-)Aufruf des Workflow durch einen Client (<receive>) Rückantwort an einen Client bei synchronem Aufruf (<reply>) Manipulation, Umkopieren von Werten in den Prozess-Variablen (<assign>) Ausweisung von Fehlern und Ausnahmen (<throw>) Anhalten (Wartestellung) des Prozesses (<wait>) Terminierung des Prozesses (<terminate>) Folie 20

21 Strukturierende Aktivitäten in BPEL Ein BPEL-Prozess besteht aus besteht aus einzelnen Schritten, auch Aktivität bezeichnet. Strukturierende Aktivitäten (structure activities) repräsentieren komplexe Aktivitäten innerhalb eines Workflows Sequentieller Ablauf von Aktivitäten (<sequence>) Paralleler Ablauf von Aktivitäten (<flow>) Einführung von Branches (Verzweigungen) (<if>) Definition von Loops (Schleifen) <while>, <repeat>...<until> Auswahl von Pfaden (<pick>) Bildung von Scopes (<scope>) Fehlerbehandlung (<compensate>) Folie 21

22 Aufruf eines Workflow (<receive>) <receive> spezifiziert den initialen Aufruf des Workflow durch einen Client und somit die erste eingehende Nachricht in dem Prozess Die erste Aktivität innerhalb der Top-Level Sequenz eines Workflow Nur eine Operation bzw. ein Message-Type kann aufgerufen / übergeben werden (Alternative: Pick) BPEL Workflow wartet auf den ersten Aufruf, befindet sich bis dahin in einem Wartezustand <process>... <sequence> <receive> partnerlink = client > porttype = chs:partnerchange operation = changepartner variable = ChangeRequest createinstance = yes </>... </sequence> </process> Folie 22

23 Aufruf eines Workflow (<pick>) <pick> spezifiziert den initialen Aufruf des Workflow durch einen Client und somit die erste eingehende Nachricht in dem Prozess Mehrere unterschiedliche Operationen bzw. Nachrichten-Typen können initial empfangen werden, Unterscheid mit <onmessage> Auch innerhalb des Workflow verwendbar (z.b. innerhalb einer <flow> Aktivität) <sequence> <pick> <onmessage partnerlink= client" porttype="chs:partnerchange" operation="changepartner" variable="changerequest">... // Subprozess für das Ändern eines Partners </onmessage> <onmessage partnerlink= client porttype="chs:partnerchange" operation= deletepartner" variable= DeleteRequest">... // Subprozess für das Löschen... <onmessage> </pick> Folie 23

24 Umkopieren von Variablen-Werten (<assign>, <copy>) Durch die <assign>... <copy> Aktivität werden Variablenwerte umkopiert Dient der Vorbereitung von weiteren Aktivitäten innerhalb des BPEL Workflow (z.b. Aufruf eines Web Service) Erweitere Kopier- und Transformationsoptionen mit XPATH möglich <process>... <assign> < Normales Kopieren > <copy> <from variable = changerequest part = name > <to variable = databaserequest part name > </copy> < Transformation mit XPATH > <copy> <from expression = concat( Gehalt:, $changerequest.payload/gehalt) /> <to variable = databaserequest part gehalt > </copy> </assign>... </sequence> </process> Folie 24

25 Synchroner Aufruf eines Web Service (<invoke>) Mit der Aktivität <invoke> wird ein externer Web Service aufgerufen Input wird in der Regel durch ein vorhergehendes Assign-Statement zugewiesen (siehe letzte Folie) <process>... <sequence>... <assign>... </assign> <invoke partnerlink= databaseconnection" porttype= dbs:databasewrite" operation= savedata" inputvariable="databaserequest" outputvariable="databaseresponse" />... </sequence> </process> Folie 25

26 Sequenz und Flow von Aktivitäten In der Top-Level Sequenz können weitere sequentielle Abfolgen (<sequenz>) sowie parallele Aktivitäten (<flow>) definiert werden: <process>... <sequence> <flow> <sequence> <assign>... </assign> <invoke partnerlink= databaseconnection... />... </sequence> <sequence> <assign>... </assign> <invoke partnerlink= databaseconnection2... />... </sequence> </flow> </process> Folie 26

27 Verzweigungen in einem BPEL-Workflow Mit der <if>.. <else> Aktivität können bedingte Verzweigungen in einem Workflow eingeführt werden Die Bedingung wird in dem Tag <condition> spezifiert... <if name = FallsPersonManagerIst> <condition> bpws:getvariabledata( changerequest, payload, /type ) = Manager </condition> <assign> <copy>... </copy> </assign> <invoke partnerlink = notificationvorstand porttype= nos:notificationfunctions" operation= notifypartner" inputvariable= notificationrequest" outputvariable="notificationresponse" /> </if> <else> <assign>...</assign> <invoke partnerlink = notificationmanager </else>... Folie 27

28 Versenden der Response an den Client Mit der Aktivität <reply> wird die Response an den aufrufenden Client zurücksendet (repräsentiert durch PartnerLink) Eine <receive>... <reply> Sequenz realisiert einen synchronen Aufruf des BPEL-Prozesses Client ist während der Abarbeitung des Aufrufs geblockt <process>... <sequence> <receive> partnerlink = client porttype = chs:partnerchange operation = changepartner variable = ChangeRequest createinstance = yes />.... <reply partnerlink = client operation = changepartner variable = changepartnerresponse /> </sequence> </process> Folie 28

29 Visualisierung des synchronen Workflow in BPEL* *erstellt mit Eclipse BPEL Designer unter Eclipse 3.4 Folie 29

30 Konkretisierung des synchronen BPEL-Workflow AntwortClient Folie 30

31 Einbettung eines BPEL-Workflow in eine service-orientierte Architektur <<Web Service>> PartnerChange Service (porttype PartnerChange, operation changepartner) <<BPEL-Workfllow Komponente>> <<Web Service>> <<client>> DatabaseAccess <<Web Service>> Notification Service AntwortClient Folie 31

32 Laufzeitumgebungen für BPEL-Workflow Ein BPEL Workflow wird in einer speziellen Laufzeitumgebung deployed und ausgeführt Servlet-Anwendung in einem Servlet-Container (z.b. Tomcat) Kommerzielle Anbieter: WebSphere Process Server SAP Netweaver Oracle BPEL Process Manager Microsoft BizTalk Server OpenSource: ActiveBPEL jbpm Apache ODE Folie 32

34 Asynchroner Aufruf eines BPEL-Workflow Ein BPEL-Workflow kann als Web Service auch asynchron aufgerufen werden Client ist nach dem initialen Aufruf nicht geblockt Client muss selber eine Schnittstelle (porttype) zur Verfügung stellen, damit BPEL-Workflow einen Callback durchführen kann: <<client>> <<Web Service>> PartnerChange Service (porttype PartnerChange, operation changepartner) <<BPEL-Workfllow Komponente>> <<Web Service>> PartnerChange ServiceResponse (porttype ChangeResponse, operation callback) Folie 34

35 Abbildung eines asynchronen Aufrufs als Partner Link Type Bei einem asynchronen Aufruf eines BPEL-Workflow werden beide notwendigen Schnittstellen (porttypes) innerhalb eines Partner Link Types in der WSDL-Schnittstelle des BPEL-Workflows definiert (neue Rolle) Die Schnittstelle für den Callback-Aufruf muss auf Seiten des Client implementiert werden (also ein Regelwerk für den Client) <definitions name = ChangePartnerService > <types>... </types> <porttype name = PartnerChange >... <porttype> <porttype name = PartneChangeResponse >... <porttype> </porttypes> <plnk:partnerlinktype name= ChangeServiceLT"> <plnk:role name= receivepartnerforchange"> <plnk:porttype name= chs:partnerchange" /> </plnk:role> <plnk:role name= callbackresultofchange"> <plnk:porttype name= chs:partnerchangeresponse" /> </plnk:role> </plnk:partnerlinktype>... <definitions> WSDL-Auszug zur Definition des Web Service ChangePartnerService Folie 35

36 Abbildung eines asynchronen Aufrufs als Partner Link Type Innerhalb der BPEL-Spezifikation muss auf die neue Rolle innerhalb der zutreffenden Partner Link Definition verwiesen werden Rollentyp myrole spezifiziert die Rolle in dem Partner Link aus Sicht des BPEL Workflow <process name = PartnerChangeWorkflow > <partnerlinks> <partnerlink name = client partnerlinktype = chs:changeservicelt, myrole = receivepartnerforchange partnerrole = callbackresultofchange />... </partnerlinks>... BPEL-Auszug zur Definition der Partner Links Folie 36

37 Rückgabe des Ergebnisses in einem asynchronen Aufruf Anstelle der <reply> Aktivität wird bei einem asynchronen Aufruf das Ergebnis mittels einer <invoke> Aktivität zurückgeliefert: <process>... <sequence> <receive> partnerlink = client porttype = chs:partnerchange operation = changepartner variable = ChangeRequest createinstance = yes />.... <invoke partnerlink = client porttype = PartnerChangeResponse operation = sendbackresult variable = changeresponse /> </sequence> </process> Folie 37

38 Konkretisierung des BPEL-Workflow Folie 38

39 Asynchroner Aufruf von Web Services aus einem BPEL-Workflow Ein BPEL-Workflow kann selber Web Services auch asynchron aufrufen BPEL-Workflow ist nach dem Aufruf nicht geblockt BPEL-Workflow muss selber eine Schnittstelle (porttype) zur Verfügung stellen, damit BPEL-Workflow einen Callback durchführen kann: <<BPEL-Workfllow Komponente>> NotificationRequest <<Web Service >> <<Web Service>> Notification Service (porttype Notification, operation send) <<Web Service>> Notification ServiceResponse (porttype NotificationRespo, operation callback) NotificationResponse Folie 39

40 Optimierung der Asynchronität Eine Optimierung der Asynchronität kann mit einer <Flow> Aktivität (parallele Ausführung von Aktivitäten ermöglicht werden: Ein Prozess horcht auf die reinkommende Callback-Nachricht Folie 40

42 Fault Handler Bei der Ausführung eines BPEL-Prozesses können Fehler (faults) auf verschiedenen Wegen auftreten Fachliche Fehler: Explizit aus einem BPEL-Prozess (<throw> Aktivität) Nach dem Aufruf eines Web Services über <invoke> (Rückgabe eines Fault- Wertes des Web Services) Technische Fehler Fehler aus der BPEL-Laufzeitumgebung (z.b. Timeouts, syntaktische Fehler) Explizites Melden von fachlichen Fehlern durch <throw> Definition mit einem Namen Optional: Angabe einer FaultVariable <throw faultname="dbaccessnotsuccesfull" faultvariable= DBFault" /> Meist eingebettet in einer konditionalen Abfrage (<if>... <else>) FaultVariable muss im Bereich <Variables> definiert sein. Folie 42

43 Standardwerte für technische Faults in BPEL Folie 43

44 Fault Handler Signalisierte Fehler werden in Fault Handler (<faulthandler>) Abfolge von Aktivitäten innerhalb eines BPEL-Prozesses, um einen Fehler zu beheben Delegation von Fehler an andere Web Services Benachrichtigung des aufrufenden Client Fault Handler werden vor der ersten Aktivität des BPEL-Prozesses definiert: <partnerlinks>... </partnerlinks> <variables>... <variables> <faulthandlers> <catch faultname = DBAccessNotSuccesfull >  </catch> <catch all>  </catch>... </faulthandlers> <sequence>... </sequence> Folie 44

45 Beispiel: Fehlerbehandlung nach Datenbankzugriff <process>... <sequence> <receive...> <assign>... </assign> <invoke partnerlink= databaseconnection" porttype= dbs:databasewrite" operation= savedata" inputvariable="databaserequest" outputvariable="databaseresponse" /> <if> <condition> bpws:getvariabledata( databaseresponse, payload, /result ) = false </condition> <assign> <copy> <from variable = databaseresponse part = reason > <to variable = DBFault part reason > </copy> <assign> <throw faultname="dbaccessnotsuccesfull" faultvariable= DBFault" /> </if>.. Definition der <throw> Aktivität in BPEL (Auszug) Folie 45

46 Beispiel: Fehlerbehandlung nach Datenbankzugriff <process>... <faulthandlers> <catch faultname = DBAccessNotSuccesfull > <assign> <copy> <from variable = DBFault part = reason > <to variable = changepartnerresponse part comment > </copy> </assign> <reply partnerlink = client operation = changepartner variable = changepartnerresponse /> </catch> <catch faultname = NotificationNotSuccesfull >  </catch>... </faulthandlers> Definition der Faulthandler in BPEL (Auszug) Folie 46

47 Scopes in BPEL Mit Scopes können BPEL-Prozesse hierarchisch unterteilt werden Scopes können eigene Variablen und FaultHandler definieren, die nur innerhalb des Scope sichtbar sind Dedizierte Startaktivität muss vorhanden sein (meist eine <sequence>), in dem ein normaler Ablauf spezifiziert wird Vorteile: Bessere Strukturierung und Lesbarkeit des Prozesses <process>... <scope name = PartnerChangeScope > <variables>  </variables> <faulthandlers>  </faulthandlers> Startaktivität <scope name = SubProzess >... </scope> </scope> </process> Folie 47

48 Compensation Handler Compensation Handler dienen der Rückgängigmachung von bereits erfolgreich ausgeführten Aktivitäten mittels einer Gegenaktion Bsp.: Hotel buchen Hotel stornieren Bsp.: Partner-Daten abgespeichert Partner-Daten wieder auf alten Stand bringen Bewahrung der Konsistenz von langläufigen Transaktionen Bei Workflows mit Benutzerinteraktion oft der Fall Optimistischer Ansatz: normaler Ablauf ist die Regel, Fehler sind Ausnahme BPEL kennt kein automatisches Rollback, Compensation muss explizit definiert werden Transaktionsgrenzen werden durch Scope dargstellt Folie 48

49 Definition von Compensation Handler Compensation Handlers werden im Rahmen eines Scope definiert: <process>... <scope name = PartnerChangeScope > <variables>  </variables> <faulthandlers>  </faulthandlers> <compensationhandler>... </compensationhandler> </scope> </process> Folie 49

50 Aufruf eines Compensation Handler Ein Compensation Handler zur Rückgängigmachung einer Aktivität wird immer in einem <catch> oder <catch all> Block aus einem Fault Handler oder aus einem <compensationhandler> Block aufgerufen Der Befehl <compensatescope> ruft den Compensation Handler eines Kind-Scope auf. <process> (oder <scope>) <faulthandlers> <catch faultname = NotificationNotSuccesfull > <compensatescope target = PartnerChangeScope /> </catch>... <faulthandlers> <scope name = PartnerChangeScope > <compensationhandler>... </compensationhandler> </scope> <sequence>... <throw faultname="notificationnotsuccesfull" > </sequence> Folie 50

51 Compensation ein Beispiel In unserem Beispiel wird die Änderung des Partners rückgängig gemacht, falls ein Vorgesetzter oder ein Manager die Änderung ablehnt Denkbare Begründung: zu hohes Gehalt <scope name = PartnerChangeScope > <compensationhandler>... <invoke partnerlink= databaseconnection" porttype= dbs:databasewrite" operation= restoredata" inputvariable="databaserequest" outputvariable="databaseresponse" />... </compensationhandler> </scope> Folie 51

52 Behandlung eines Fehlers mit <rethrow> Mit der Aktivität <rethrow> kann ein Fehler innerhalb eines Scope zu dem Vater -Scope weiterdelegiert werden Separate Fehlerbehandlung dann möglich <process> (oder <scope>) <faulthandlers> <catch faultname = BadNotification > <compensatescope target = PartnerChangeScope />... <faulthandlers> <scope name = PartnerChangeScope > <compensationhandler>... </compensationhandler> </scope> <scope name = NotificationScope > <faulthandlers> <catch faultname = NotificationNotSuccesfull >... <rethrow faultname = BadNotification /> </catch> </scope> Folie 52

54 Benutzerinteraktion in BPEL BPEL definiert selber keine Sprachkonstrukte, um eine Benutzerinteraktion zuzulassen Annahme: rein automatisierter Ablauf des Workflow ohne Benutzerinteraktion Feststellung: Viele Szenarien fordern die Interaktion mit einem Benutzer vor / während / nach der Ausführung eines Workflow: Mögliche Formen: Manuelle Abnahme von wichtigen Aktivitäten / Entscheidungen Durchführung von komplexen Aufgaben mit einem dedizierten Ziel Eingabe von komplexen Daten (Initialisierung des Workflow) Anzeige von Zwischenergebnissen Status-Anzeige Blockierung des BPEL-Prozesses zum Teil möglich bis Benutzerinteraktion erfolgt ist Synchrone vs. asynchrone Ausführung Folie 54

55 Normale Anbindung einer Interaktionskomponente an eine Workflow-Komponente Aufruf eines Workflow aus einer Interaktionskomponente <<BPEL-Workfllow Komponente>> <<Web Service>> PartnerChange Service (porttype PartnerChange, operation changepartner) <<Interaktionskomponente>> <<Servlet>> oder <<Java Server Page>> Folie 55

56 Anbindung einer Interaktionskomponente an eine Workflow-Komponente (Pattern Arbeitsspeicher ) Asynchrone Übermittlung einer Aktivität für einen Benutzer (oder eine Benutzergruppe) an die Interaktionskomponente (Arbeitsspeicher) <<BPEL-Workfllow Komponente>> <<Web Service>> PartnerChange Service (porttype PartnerChange, operation changepartner) <<Interaktionskomponente>> <<Servlet>> oder <<Java Server Page>> <<Web Service>> Arbeitsspeicher (porttype Arbeits speicher, operation setzeinteraktion) <<component>> Arbeitsspeicher Folie 56

57 Anbindung einer Interaktionskomponente an eine Workflow-Komponente (Pattern Arbeitsspeicher ) Darstellung des Arbeitsspeichers mit den aktuellen ToDos beim Einloggen des Benutzers (z.b. über Startseite) Zusätzliche Benachrichtigung über Mail ist üblich BPEL-Prozess kann von da an weiter ausgeführt werden (z.b. über callback) <<Interaktionskomponente>> <<Servlet>> oder <<Java Server Page>> Browser <<Web Service>> Arbeitsspeicher (porttype Arbeits speicher, operation setzeinteraktion) <<component>> Arbeitsspeicher Vorgesetzter Folie 57

58 BPEL4People BPEL4People ist eine Erweiterung des BPEL-Standards zur Abbildung und Integration von menschlichen Aktivitäten in einem BPEL-Workflow Spezifikation von OASIS (2007, ongoing) In vielen Laufzeitumgebungen bereits integriert (z.b. ActiveVOS, Oracle) Spezifikation sehr vage, oberflächlich, Implementierung somit immer noch herstellerabhängig Infos unter: Folie 58

59 BPEL4People Grundlegende Konzepte Einführung einer neuen Aktivität: <peopleactivity> Benachrichtigung (ohne Ergebnis) Abarbeitung einer Aufgabe (mit Ergebnis) Zuweisung von Personen (People) zu einer Aktivität Wer muss eine Aktivität ausführen? Wer kann einen neuen (Sub-)Workflow starten? Welche Rolle besitzt eine Person (z.b. Entscheider, Mitarbeiter, Besitzer) Zuordnung von Personen und Rollen über <peoplelinks> Referenzieren auf Directories (z.b. LDAP) um spezifische Informationen über Personen zu erhalten Folie 59

60 BPEL4People Mögliche Szenarien Zuweisung und Ausführung von Aufgaben an eine Gruppe von Personen Zuweisung, welche Personen einen Prozess starten dürfen Management von langlaufenden Prozessen (z.b. Involvierung bei Timeout oder Fehler) 4-Augen Prinzip bei der Abschließung von wichtigen Aktivitäten Eskalation von Prozessen Nominierung von Zuständigkeiten für unklare Aufgaben Lifecycle Management (Delegation von Zuständen von Tasks zu Prozess) Folie 60