Business Process Execution Language for Web Services (BPEL4WS)

Transkript

1 Hauptseminar und Vorlesung Web Services WS 2003/04 Business Process Execution Language for Web Services (BPEL4WS) Patrick Sauter

2 2/17 Vortrag - Überblick Definition, Zielsetzung und Allgemeines einfacher Beispiel-Workflow wichtige tags (Strukturelemente) das Partner-Konzept Implementierung des Beispiel-Workflows: Code-Beispiele (.bpel und zugehörige.wsdl) Screenshots Bewertung und Einordnung Zusammenfassung

3 Definition a notation for specifying business process behavior based on Web Services [BPEL4WS specification 1.1] Folgerungen: XML-basiert zunächst nur (abstrakte) Beschreibung, noch keine Ausführung beschreibt (implizit) einen Prozessgraphen eines bestimmten Geschäftsprozesses/Workflows beschreibt die Arbeitsweise einer Workflow Execution Engine, d.h. die Ausführungsreihenfolge der Einzelschritte des Workflows 3/17

4 Zielsetzung to become the Web Services standard for composition [IBM tutorial] Folgerungen: aus mehreren bereits existierenden Web Services wird ein neuer gemacht, der die bisherigen Web Services in einer bestimmten Reihenfolge aufruft hierdurch ergibt sich keine höhere Mächtigkeit, da mehrere Web Services genauso dadurch zusammengeschaltet werden können, dass z.b. eine Java-Datei diese nacheinander aufruft Vorteil bei Verwendung von BPEL4WS: Workflow-Änderung ohne (Java-)Code-Änderung möglich 4/17

5 5/17 Allgemeines Aktueller Standard: Version 1.1 vom , 136 Seiten Autoren der specification: Microsoft und IBM: jeweils 3 Siebel, SAP und BEA: jeweils 2 Entstanden aus Kombination zweier proprietärer Ansätze: Microsoft XLANG: structural constructs (Blockstruktur) IBM WSFL: Graphen-basiert es gibt keine Referenzimplementierung des Standards, derzeit lediglich einen Prototyp von IBM Schwäche des Spezifikations-Dokuments ist die zum Teil nicht ausreichend spezifizierte Semantik

6 6/17 Beispiel-Workflow (1) gegeben: ein (zweistelliger) Addierer und ein (zweistelliger) Multiplizierer a b + b * a Ziel (= Gesamt-Workflow): neuer Web Service, der den (vierstelligen) Ausdruck ((a+b)*(c+d)) berechnet logische Sicht: a b c d + + *

7 7/17 Beispiel-Workflow (2) Implementierungs-Sicht: a a b b + c a d b + a b * reuse der bereits existierenden Komponenten (Web Services), d.h. es werden keine eigenen Operatoren + oder * verwendet composition bisheriger Web Services Aufgabe des neuen BPEL4WS-Web-Services: Aufruf der drei Operationen und Parameter-Mapping die Additionen können auch parallel ausgeführt werden

8 8/17 Spezifizierte tags (1) primitive activities : <invoke> Aufruf eines externen Web Service <receive> Lesen der Aufrufparameter <reply> Übergabe des Ergebnisses an Aufrufer <wait> <assign> Zuweisung von Variablen <throw> ähnlich WSDL faults <terminate> Workflow-Ende ohne <reply> <empty>

9 9/17 Spezifizierte tags (2) structured activities : <sequence> Hintereinanderausführung von primitive activities <flow> parallele Ausführung von primitive activities (AND- Split) <while> <pick> Event-Handling <switch> Verzweigung in nur eine Richtung (OR-Split) (... etliche weitere...)

10 10/17 Das Partner-Konzept Der BPEL4WS-Web-Service ist zunächst Client aus Sicht der verwendeten Web Services (z.b. Addierer) Server aus Sicht des aufrufenden Programmes Problem: Der BPEL4WS-Web-Service kann auch auf Methoden seines Aufrufers zugreifen. Unterscheidung in Client und Server nicht mehr sinnvoll. Vereinfachung: alle Beteiligten heißen Partner. Der BPEL4WS-Web-Service unterscheidet die Partner, die auf ihn zugreifen und teilt ihnen Rollen zu. Je nach Rolle bekommt der Partner eine für ihn passende Schnittstelle (WSDL porttype ) zu sehen. Diese angepasste Schnittstelle nennt sich dann service link type.

11 11/17 Code-Beispiel: berechnung.bpel (1) <process xmlns=" name="spieltkeinerolle" targetnamespace="urn:berechnung" xmlns:tns="urn:berechnung" xmlns:addiererns=" xmlns:multipliziererns=" Multiplizierer.jws"> <partners>... </partners> <variables>... </variables> <sequence name= BerechnungSequence >... </sequence> </process>

12 12/17 Code-Beispiel: berechnung.bpel (2) <process...> <partners> <partner name="caller" servicelinktype="tns:berechnungslt"/> <partner name="meinaddierer servicelinktype="tns:berechnungslt"/> <partner name="meinmultiplizierer servicelinktype="tns:berechnungslt"/> </partners> <variables>... </variables> <sequence name= BerechnungSequence >... </sequence> </process>

13 Code-Beispiel: berechnung.bpel (3) <process...> <partners>... </partners> <variables> <variable name="request messagetype="tns:berechnungrequest"/> <variable name="erstesummanden messagetype="tns:addiererodermultipliziererrequest"/> <variable name="erstesergebnis messagetype="addiererns:addiereresponse"/> <variable name="zweitesummanden messagetype="tns:addiererodermultipliziererrequest"/> <variable name="zweitesergebnis messagetype="addiererns:addiereresponse"/> <variable name="diemultiplikatoren" messagetype="tns:addiererodermultipliziererrequest"/> <variable name="response messagetype="tns:berechnungsresponse"/> </variables> <sequence name= BerechnungSequence >... </sequence> </process> 13/17

14 Code-Beispiel: berechnung.bpel (4) <process...> <partners>... </partners> <variables>... </variables> <sequence name= BerechnungSequence > <receive>... </receive> <assign>... </assign> <flow> <!-- die Additionen werden parallel ausgeführt --> <sequence> <invoke name="ersterberechnungsschritt" partner="meinaddierer porttype="addiererns:addierer" operation="addiere" inputvariable="erstesummanden outputvariable="erstesergebnis"> </invoke> </sequence> <sequence>... <!-- zweite Addition -->... </sequence> </flow> <assign>... </assign> <invoke>... <!-- die Multiplikation -->... </invoke> </sequence> </process> <!-- Rest hier ausgelassen --> 14/17

15 15/17 Screenshots restlicher Quellcode: ggf. siehe Vorlesungs-Homepage oder Außerdem wird noch die (per Hand erstellte) Datei berechnung.wsdl benötigt, die das Interface des durch berechnung.bpel beschriebenen Web Service nach außen hin deklariert. Screenshots der Implementierung...

16 Nachteile: relativ komplexer Syntax bereits für einfache Beispiele derzeit noch: semantisch nicht vollständig klar definiert derzeit noch: passende wsdl-datei muss per Hand erstellt werden derzeit noch: keine Schema-Änderungen zur Laufzeit möglich derzeit noch: debugging schwierig, da stack traces zu ungenau Vorteile: Bewertung und Einordnung Trennung zwischen Ressourcen-Verwendung und Ablauflogik Standardisierung kein Herstellerabhängigkeit volle Petri-Netz-Mächtigkeit (Blockstruktur ähnlich ADEPT) in Zukunft möglich: Implementierung komplexer Workflows ohne Quellcode zu schreiben mit entsprechendem Modellierungs-Tool Anwendungsmöglichkeiten: Unternehmen mit vielen kleinen Web Services, deren Schnittstelle und Semantik sich auch ändern können ( keine aufwändigen Änderungen im Anwendungs-Code) 16/17

17 17/17 Zusammenfassung BPEL4WS = von IBM, Microsoft und anderen standardisierte Beschreibungssprache für Workflows Zusammenstöpseln bereits existierender Web Services Aufruf mit <invoke> Graph-ähnliche Modellierung mit <sequence>, <flow>, <while>,... alle beteiligten Web Services heißen Partner zu einer.bpel-datei muss noch eine passende.wsdl-datei erstellt werden derzeit: Implementierung von IBM auf Prototyp-Ebene