Business Process Execution Language for Web Services
(BPEL4WS)
Hauptseminar und Vorlesung Web Services
WS 2003/04
Patrick Sauter
•
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
Vortrag - Überblick
“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
Definition
“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
Zielsetzung
•
Aktueller Standard: Version 1.1 vom 05.05.2003, 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
Allgemeines
•
gegeben: ein (zweistelliger) Addierer und ein (zweistelliger) Multiplizierer
Beispiel-Workflow (1)
•
Ziel (= Gesamt-Workflow): neuer Web Service, der den (vierstelligen) Ausdruck ((a+b)*(c+d)) berechnet
•
logische Sicht:
+ *
+ +
*
a a
a
b b
b c d
Beispiel-Workflow (2)
+
*
a
a a
b
b b
c
d
+
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
•
Implementierungs-Sicht:
“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>
Spezifizierte tags (1)
Spezifizierte tags (2)
“structured activities”:
•
<sequence> Hintereinanderausführung von primitive activities
•
<flow> parallele Ausführung von primitive activities (AND-
•
<while>
•
<pick> Event-Handling
•
<switch> Verzweigung in nur eine Richtung (OR-Split)
(... etliche weitere...)
Split)
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”.
Code-Beispiel: berechnung.bpel (1)
<process
xmlns="http://schemas.xmlsoap.org/ws/2003/03/business-process/"
name="spieltKeineRolle"
targetNamespace="urn:berechnung"
xmlns:tns="urn:berechnung"
xmlns:addiererNS="http://localhost:60281/axis/Addierer.jws"
xmlns:multipliziererNS="http://localhost:60281/axis/
Multiplizierer.jws">
<partners> ... </partners>
<variables> ... </variables>
<sequence name=“BerechnungSequence”> ... </sequence>
</process>
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>
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>
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 -->
Screenshots
•
restlicher Quellcode: ggf. siehe Vorlesungs-Homepage oder www.uni-ulm.de/~s_psaute/
•
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...
•
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:
•
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)
Bewertung und Einordnung
•
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
•
