Enterprise Applikation Integration und Service-orientierte Architekturen 11 BPEL

Transkript

1 Enterprise Applikation Integration und Service-orientierte Architekturen 11 BPEL

2 Prozesse und Services Prof. Dr. Holger Wache 2

3 Problem: Prozesssteuerung mit WSDL Jeder Prozess ist zustandsbehaftet. Dieser Zustand setzt sich zusammen aus den ausgetauschten Nachrichten und den temporären Daten zur Auswertung. Web Service sind geeignet für das Austauschen von Nachrichten von Prozessen mit anderen Diensten und/oder Prozessen Aber: WSDL ist zustandslos, so dass mehrere Anfragen auch desselben Auftraggebers als grundsätzlich voneinander unabhängige Transaktionen zu behandeln sind. D.h. die Eigenschaften: Koordinierung und Zustand fehlen Prof. Dr. Holger Wache 3

4 Komposition Zusammenschalten von Web Services zu neuen Web Services Beschreibung der Zusammenhänge und Interaktionen Anforderungen Koordination Ausgeführte Aktivitäten müssen einer konkreten Workflow-Instanz zugeordnet werden und Ergebnisse weitergeleitet werden können Asynchrone Aufrufe Jede Antwort muss einem passenden Aufruf zugeordnet werden können Zustandsverwaltung Speicherung des Zustands eines Prozesses, der sich aus ausgetauschten Nachrichten und den temporären Daten zur Auswertung der Geschäftslogik zusammensetzt Transaktionen Führt ein Vorgang zu einem Fehler, muss dieser (und alle davon abhängigen Vorgänge) zurückgenommen werden Prof. Dr. Holger Wache 4

5 Orchestration vs. Choreography Orchestration Beschreibung, wie Web Services auf der Ebene von Messages mit einander interagieren können Beinhaltet die Geschäftslogik und Ausführungsreihenfolge der Interaktionen Die Interaktionen können sich über mehrere Applikationen und auch über mehrere Unternehmen erstrecken und führen zu einem Multi-Step- Prozessmodell im Kontext von Long-running transactions Bezieht sich auf einen ausführbaren Geschäftsprozess, der aus Sicht einer der beteiligten Parteien beschrieben wird. Choreographie Beschreibung der Abfolge von Messages, in die mehrere Parteien und mehrere Quellen verwickelt sein können Der öffentliche Austausch von Messages steht im Vordergrund Welcher Service nimmt im Rahmen der Interaktion welche Rolle ein Prof. Dr. Holger Wache 5

6 Orchestration vs. Choreography Booking Service Airline reservation Airline Reservation Service Swiss reservation Swiss Airlines Reservation Service Hotel reservation Hotel Reservation Service Alitalia reservation Alitalia Reservation Service Vehicle reservation Vehicle Reservation Service Lufthansa reservation Lufthansa Reservation Service Reserverd anything Credit Card Prof. Dr. Holger Wache 6

7 BPEL Business Process Execution Language for Web Service XML-basierte Sprache zur Definition und Ausführung von Geschäftsprozessen unter Verwendung von Web Services Hervorgegangen aus XLAng von Microsoft und WSFL von IBM Ist nach aussen hin wieder ein Web Service Ziel: Beschreibung eines Geschäftsprozesses Dazu muss jeder einzelne Schritt beziehungsweise jede einzelne Aktivität des Prozesses beschrieben werden Prof. Dr. Holger Wache 7

8 Grundstruktur eines BPEL-Prozesses <process name="..."...> <! - Definition and roles of process participants --> <partnerlinks>... </partnerlinks> <!-- Data/state used within the process --> <variables>... </variables> <!-- Properties that enable conversations --> <correlationsets>... </correlationsets> <!-- Exception handling --> <faulthandlers>... </faulthandlers> <!-- Error recovery undoing actions --> <compensationhandlers>... </compensationhandlers> <!-- Concurrent events with process itself --> <eventhandlers>... </eventhandlers> <!-- Business process flow: Mindestens eine activity --> <! (activities)+ --> </process> Prof. Dr. Holger Wache 8

9 Elemente Partners und Partner-Links Beziehungen zu Services Activities Einzelne Statements von BPEL Receive, Reply, Invoke, Assign, Throw, Catch, Terminate, Wait, Empty, Sequence, Switch, While, Pick, Flow, Link, Scope, Compensate Scopes Fassen mehrere Aktivitäten zu einem gemeinsamen Kontext zusammen Throw Fehlermeldungen Prof. Dr. Holger Wache 9

10 Partnerlinks Prof. Dr. Holger Wache 10

11 Partner Links Ein BPEL-Prozess nutzt Dienste in Form von Web Services Die Dienste werden von Dritten so genannten Partnern zur Verfügung gestellt Mit Hilfe des Elements <partnerlinks> wird definiert, wie ein Prozess mit seinen Partnern kommuniziert Prinzipiell kann ein Partner mehrere Rollen einnehmen. Die Rolle hängt davon ab, welchen Zweck die Kommunikation erfüllt. Einzelhandel Verkäufer Kunde Auskunftgeber Grosshandel Verkäufer Käufer Hersteller Auskunftsuchender Prof. Dr. Holger Wache 11

12 PartnerLinkType PartnerLinkType spezifiziert die Rollen, die in einer Beziehung zwischen zwei Services vorkommen booking Zusätzlich wird zu jeder Rolle der porttype spezifiziert (porttypes sind aus WSDL bekannt) Booker (BookerPT) AirlineBooker (AirlineReservationPT) Partner Link Types sind in WSDL mit einem speziellen Namespace definiert: <plnk:partnerlinktype name="booking"> <plnk:role name="booker"> <plnk:porttype name="bookerpt"/> </plnk:role> <plnk:role name="airlinebooker"> <plnk:porttype name="airlinereservationpt"/> </plnk:role> </plnk:partnerlinktype> <wsdl:porttype name="airlinereservationporttype"> <wsdl:operation name="reserve"> <wsdl:input message="tns:airlineinput"/> <wsdl:output message="tns:airlinebooked"/> </wsdl:operation> </wsdl:porttype> Prof. Dr. Holger Wache 12

13 Kommunikationselemente in BPEL BPEL partnerlink receive reply pick invoke BPEL partnerlinktype WSDL porttype WSDL porttype interface binding WSDL port WSDL port porttype entspricht der Komponente interface in WSDL 2.0 Prof. Dr. Holger Wache 13

14 PartnerLinks Jede Kommunikationsverbindung mit einem Partner muss über ein Element PartnerLink definiert werden Jede Verbindung erhält über das Attribut name einen eindeutigen Bezeichner Für jede Rolle wird festgelegt welche Rolle der eigene Prozess (myrole) und welche der externe Partner (partnerrole) übernimmt. Die Rollen wurden im entsprechenden PartnerLinkType definiert booking <bpel:partnerlink myrole="booker" name="booking" partnerlinktype="ns1:booking" partnerrole="airlinebooker"/> Booker (BookerPT) Process airlineservice (AirlineReservationPT) Web Service n n n Werden sowohl myrole als auch partnerrole angegeben, so handelt es sich um eine synchrone Kommunikation (request-response-zyklus) Wird nur eine Rolle angegeben, so ist die Kommunikation asynchron Wird nur das Attribut myrole angegeben, so handelt es sich um einen request-aufruf Prof. Dr. Holger Wache 14

15 Kommunikationselemente in BPEL - Beispiel receive BPEL partnerlink reply pick invoke BPEL booking Booker AirlineReservationPT AirlineBooker Booker WSDL (BoockerPT) interface binding <wsdl:porttype name= BookerPT"> <wsdl:operation name= book"> <wsdl:input message="tns:bookinput"/> <wsdl:output message="tns:bookoutput"/> </wsdl:operation> </wsdl:porttype> <wsdl:porttype name="airlinereservationporttype"> <wsdl:operation name="reserve"> <wsdl:input message="tns:airlineinput"/> <wsdl:output message="tns:airlinebooked"/> </wsdl:operation> </wsdl:porttype> Prof. Dr. Holger Wache 15

16 Variablen Der Zustand eines Prozesses setzt sich zusammen aus den ausgetauschten Nachrichten und den temporären Daten zur Auswertung der Geschäftslogik (z.b. Verzweigungen). Diese Informationen werden in Variablen gehalten, die im Element variable deklariert werden. Es gibt drei Arten von Datentypen: WSDL message type XML Schema simple type XML Schema element Beispiel für Variablen-Deklaration: <wsdl:message name="bookinginput"> <wsdl:part name="name" type="xsd:string"/> <wsdl:part name="wantstofly" type="xsd:boolean"/> <wsdl:part name="wantsacar" type="xsd:boolean"/> <wsdl:part name="wantshotel" type="xsd:boolean"/> <wsdl:part name="creditcard" type="xsd:string"/> </wsdl:message> <variables> <variable name="bookinginput messagetype="ns1:bookinginput"/> <variable name="name" element="nameelement"/> <variable name="counter" type="xsd:int"/> </variables> <xsd:element name="nameelement"> <xsd:complextype> <xsd:sequence> <xsd:element name="name" type="xsd:string"/> <xsd:element name="age" type="xsd:int"/> </xsd:sequence> </xsd:complextype> </xsd:element> Prof. Dr. Holger Wache 16

17 Gültigkeitsbereich Gültigkeitsbereiche von Variablen werden durch das Element scope definiert Verwendung von scope ist optional Wie in Java gilt: "lokale Variable verdecken globale Variablen" Prof. Dr. Holger Wache 17

18 Wertzuweisungen mit assign Mit Hilfe von assign können Variablen Werte von anderen Variablen und neu berechnete Werte zugewiesen werden BPEL ist ein streng getypte Sprache, d.h. die Typen von Variable und Wert müssen identisch sein. Innerhalb eines assign-elements können mehrere copy-elemente vorkommen. <assign> <copy> <from variable="name" part="familyname"/> <to variable="customername" part="fname"/> </copy> <copy> <from> 1000 </from> <to variable="maxprice"> </copy> </assign> Prof. Dr. Holger Wache 18

19 Elementare und strukturierte Aktivitäten BPEL unterscheidet zwischen elementaren Aktivitäten (auch Basisaktivitäten genannt) und strukturierten Aktivitäten (Kontrollkonstrukten). Jede Aktivität ist ein separates Element in einem BPEL-Dokument Elementare Aktivitäten <invoke> <receive> <reply> <assign> <throw> <wait> <terminate> Strukturierte Aktivitäten Aufruf eines anderen Web Services Wartet, dass ein Client den Prozess durch Senden einer Nachricht aktiviert Antwort für eine synchrone Operation erzeugen Manipulation von Variablenwerten Anzeigen von Fehlern oder Ausnahmen eine vorgegebene Zeit abwarten den Prozess beenden <sequence> Sequenz von Aktivitäten <flow> Parallele Ausführung von Akivitäten <switch> Verzweigung <while> Schleife <pick> Auswahl von Alternativen aufgrund externer Ereignisse (nichtdeterministische Verzweigungen) Prof. Dr. Holger Wache 19

20 invoke Mit der Aktivität invoke werden andere Web Services aufgerufen Attribute von invoke legen ausserdem fest: partnerlink porttype operation inputvariable outputvariable Booker (BookerPT) booking reserve (AirlineInput) AirlineBooked airlineservice (AirlineReservationPortType) invoke kann sowohl für synchrone als auch asynchrone Aufrufe verwendet werden bei asynchronem Aufruf genügt die Angabe der inputvariable ein synchroner Aufruf benötigt zusätzlich die Angabe der outputvariable <bpel:invoke inputvariable="airlineinput" outputvariable="airlinebooked operation="reserve" partnerlink="booking" porttype="ns2:airlinereservationporttype"/> Prof. Dr. Holger Wache 20

21 receive und reply Wann immer ein BPEL-Prozess mit einem Partner (z.b. einem aufgerufenen Web Service) in Verbindung tritt, geschieht das über ein Aktivitäten-Paar bestehend aus receive und dem zugehörigen reply Das reply-konstrukt antwortet auf eine Nachricht, die über ein receive erhalten wurde receive blockiert einen Prozess und wartet auf das Eintreffen einer für ihn bestimmten SOAP- Nachricht, die ihn veranlasst, den Workflow entweder zu starten oder weiterzubearbeiten. reply veranlasst die Rückgabe eines Ergebnis-Wertes an den aufrufenden Partner Da ein BPEL-Prozess selber auch wieder ein Web Service ist, ist die erste Aktivität eines BPEL-Prozesses immer eine receive-aktivität <bpel:receive operation="book" partnerlink="bookinglt" porttype="ns1:bookerpt" variable="bookinginput"/> <bpel:reply operation="book" partnerlink="bookinglt" porttype="ns1:bookerpt" variable="response"/> Prof. Dr. Holger Wache 21

22 Strukturierte Aktivitäten sequence, switch, while steuern den sequentiellen Ablauf von Aktivitäten flow beschreibt den Fluss von parallel oder synchronisiert ablaufenden Aktivitäten pick legt die Aktivitäten fest, die aufgrund externer Ereignisse ausgeführt werden, d.h. nicht-deterministische Verzweigungen Prof. Dr. Holger Wache 22

23 Strukturierte Aktivitäten (I) switch entspricht der mehrfachen Verzweigung. Das Element otherwise wird ausgeführt, wenn keine der anderen Verzweigungen gewählt wurde <switch> <case condition="boolean(bookinginput.wantstofly )"> <invoke... /> </case> <otherwise> <receive... /> </otherwise> </switch> Bei while wird eine Menge von Aktivitäten so lange ausgeführt, bis die als Attribut angegebene Bedingung nicht mehr erfüllt ist. <while condition="bpws.getvariabledata('counter')<10"> <!--activities--> </while> Prof. Dr. Holger Wache 23

24 Strukturierte Aktivitäten (II) Sollen mehrere Aktivitäten in einer vorgegebenen Reihenfolge ausgeführt werden, so werden sie mit Hilfe des Elements sequence geklammert Für die parallele Ausführung von Aktivitäten steht das Element flow zur Verfügung <sequence> <!--activity1--> <!--activity2--> </sequence> <flow> <invoke...> </invoke> <sequence> <receive... /> <invoke...> </invoke> </sequence> </flow> Prof. Dr. Holger Wache 24

25 Beeinflussung der Ausführungsreihenfolge durch das link-element <flow> <links> <link name="avorb"/> <link name="xvory"/> </links> <invoke name="a"> <source linkname="avorb"/> </invoke> <invoke name="b"> <target linkname="avorb"/> </invoke> <invoke name="x"> <source linkname="xvory"/> </invoke> <invoke name="y"> <target linkname="xvory"/> </invoke> </flow> Das auf XML-basierende Konzept von sequence und flow-aktvitäten stösst an seine Grenzen, wenn Abläufe nicht hierarchisch geschachtelt sind. Daher gibt es noch ein Element links zur Verknüpfung von Aktivitäten Links erlauben es, aus der hierarchischen XML- Struktur herauszuspringen und Aktivitäten zu synchronisieren. Dazu werden die Elemente source und target als zusätzliche Aktivitäten definiert Der Fluss der Aktivitäten verläuft von der Aktivität mit dem Element source zur Aktivität mit dem Element target Die Identifizierung der miteinander verküpften Aktivitäten erfolgt über das Attribut linkname Prof. Dr. Holger Wache 25

26 Beeinflussung der Ausführungsreihenfolge durch das link-element <flow> <links> <link name="avorb"/> <link name="xvory"/> </links> <invoke name="a"> <source linkname="avorb"/> </invoke> <invoke name="b"> <target linkname="avorb"/> </invoke> <invoke name="x"> <source linkname="xvory"/> </invoke> <invoke name="y"> <target linkname="xvory"/> </invoke> </flow> source A X target B Y Prof. Dr. Holger Wache 26

27 Weiteres Beispiel <flow> <links> <link name="receive-to-approval"/> <link name="receive-to-assess"/> <link name="assess-to-approval"/> </links> <receive createinstance="yes" name="receive1" > <source linkname="receive-to-approval" /> <source linkname="receive-to-assess" /> </receive> <invoke name="invokeapprover" > <target linkname="receive-to-approval"/> <target linkname="assess-to-approval"/> </invoke> <assign name="invokeassessor" > <target linkname="receive-to-assess"/> <source linkname="assess-to-approval"/> <copy> <from expression="'approved'"/> <to part="accept" variable="approvalinfo"/> </copy> </assign> </flow> Prof. Dr. Holger Wache 27

28 Ein weiteres Beispiel mit Links <flow> <links> <link name="receive-to-approval"/> <link name="receive-to-assess"/> <link name="assess-to-approval"/> </links> <receive createinstance="yes" name="receive" > <source linkname="receive-to-approval" /> <source linkname="receive-to-assess" /> </receive> <invoke name="invokeapprover" > <target linkname="receive-to-approval"/> <target linkname="assess-to-approval"/> </invoke> <assign name="invokeassessor" > <target linkname="receive-to-assess"/> <source linkname="assess-to-approval"/> <copy> <from expression="'approved'"/> <to part="accept" variable="approvalinfo"/> </copy> </assign> </flow> receive invokeapprover invokeassessor Prof. Dr. Holger Wache 28

29 Ereignisbehandlung Mit Hilfe des Elements eventhandler können ein oder mehrere Nachrichten zusammengefasst werden, die auf externe Ereignisse reagieren Das Element onmessage definiert ein Ereignis, das von einem externen Partner aufgerufen werden kann. Bei Bedarf kann mit Hilfe des Attributs variable an die in dem Element onmessage gekapselten Aktivitäten ein Wert übergeben werden. Wird eine in einem onmessage-element beschriebene Nachricht empfangen, werden die zugehörigen im eventhandler enthaltenen Aktivitäten ausgeführt. <onmessage partnerlink="buyer" porttype="car" operation="cancel" variable="canceldetails"> <terminate/> </onmessage> Abbruch eines Geschäftsvorgangs durch Aufruf von cancel Prof. Dr. Holger Wache 29

30 BPEL - Engine Das BPEL-Dokument dient als Eingabe für eine Komponente (Prozess Manager, Workflow-Engine) welche die Anweisungen ausführt. Quelle: Prof. Dr. Holger Wache 30

31 BPEL-Werkzeuge Kommerzielle Produkte ORACLE Process Manager und Designer IBM WBISFMicrosoft BizTalk Server 2004 ActiveVOS Designer Open Source-Produkte Eclipse BPEL-Plugin OpenESB mit Glassfish Prof. Dr. Holger Wache 31

32 ÜBUNG Prof. Dr. Holger Wache 32

33 Quelle Hinkelmann, K. 2007, Vorlesungsfolien. Dostal, W., Jeckle, M., Melzer, I. and Zengler, B. 2005, Service-orientierte Archtitekturen mit Web Services, Konzepte- Standards-Praxis, Elvesier GmbH, München. Alonso, G., Casati, F., Kuno, H. and Machiraju, V.1998, Web Services, Concepts, Architectures and Application, Springer- Verlag, Berlin, Heidelberg, New York. Prof. Dr. Holger Wache 33