kommunizierende workflow-services modellieren und analysieren

Informatik Forsch. Entw. (2005) 20: 90–101DOI 10.1007/s00450-005-0209-5

R E G U L Ä R E B E I T R Ä G E

Wolfgang Reisig • Karsten Schmidt • Christian Stahl

Kommunizierende Workflow-Services modellieren und analysieren

Eingegangen am 13. Januar 2005 / Angenommen am 4. August 2005 / Online publiziert am 21. September 2005© Springer-Verlag 2005

Zusammenfassung Zur adäquaten Nutzung von Workflow-Implementierungen kommunizierender Geschäftsprozessewerden Konzepte vorgeschlagen, die von konkreten Imple-mentierungen abstrahieren. Auf der Basis von Petrinetzenwerden unterschiedliche Varianten der Bedienbarkeit vonWorkflows charakterisiert und dafür Entscheidungsalgorith-men vorgestellt. Die Angemessenheit des Ansatzes wird amBeispiel der Semantik von Komponenten der Geschäftspro-zess-Modellierungssprache BPEL demonstriert.

Schlüsselwörter Petrinetze · offene Workflow-Netze ·Workflow-Services · BPEL · Bedienbarkeit

Abstract We consider workflow implementations of com-municating business processes. We propose theoretic con-cepts for their adequate use. Based on a class of Petri nets,we characterize different versions of usability (or control-lability) of workflows and present decision procedures forthese properties. Through a Petri net semantics for the webservice description language BPEL, we link our concepts toa practically relevant domain.

Keywords Petri nets · Open workflow nets · Workflowservices · BPEL · Controllability

CR Subject Classification I.2.2 · H.3.5 · D.2.2 · D.2.4

1 Einleitung

1.1 Kommunizierende Workflow-Services

Ein Geschäftsprozess ist eine funktionsübergreifende Verket-tung zusammengehörender Aktivitäten, die gemeinsam einenWert für Kunden erzeugen [21]. Unter den Aktivitäten einesGeschäftsprozesses sind unter anderem solche, die den Aus-

W. Reisig · K. Schmidt · C. StahlHumboldt-Universität zu Berlin, Institut für Informatik,Tel.: +49-30-2093 3066Fax: +49-30-2093 3067E-mail: {reisig, kschmidt, stahl}@informatik.hu-berlin.de

tausch von Informationen, Dokumenten oder realen Güternmit Kunden, Unternehmen oder Unternehmensteilen außer-halb des Geschäftsprozesses realisieren. Diese Aktivitätenumfassen sowohl manuelle als auch mechanische Funktionen(Ausweis zeigen vs. Email senden). Im Folgenden wollen wirAktivitäten zusammenfassend als Kommunikationsaktivitä-ten bezeichnen. Die neben dem Geschäftsprozess selbst ander Kommunikation beteiligten Akteure (Kunden, Unterneh-men) nennen wir zusammenfassend Partner. In diesem Arti-kel wollen wir Geschäftsprozesse speziell unter dem Aspektder Kommunikation mit Partnern untersuchen und dabei vonanderen, ebenfalls bedeutenden Aspekten abstrahieren.

Unser Interesse am Kommunikationsaspekt von Ge-schäftsprozessen ergibt sich aus aktuellen Entwicklungen.Zunächst werden Geschäftsprozesse zunehmend informati-onstechnisch unterstützt, durch Workflows [1,4,17,20]. Work-flows wiederum werden mehr und mehr dazu eingesetzt,die interne Abarbeitungsstruktur von Services, insbesondereWeb-Services zu spezifizieren. In der aktuellen Diskussionum Architekturen verteilter, heterogener Systeme und ihrerAnwendungs-Szenarien spielen Services eine zentrale Rol-le. Ein Service enthält ausführbare, in einer Kontrollstrukturangeordnete Operationen, eine Schnittstelle (z.B. definiert inWSDL) und einen Identifizierer (z.B. eine URI).

Die Kommunikation eines Service dient nicht der klassi-schen Form der Eingabe vor Beginn einer Abarbeitung undder Ausgabe nach Beendigung einer Abarbeitung, sondernder Kommunikation mit allen Partnern, d.h. der Umgebungdes Service während einer Abarbeitung.

Die Umgebung eines Service besteht im Allgemeinen ausanderen Services, so dass in natürlicher Weise Netzwerkekommunizierender Services entstehen. Diese Architektur hatvielfältige Vorteile: Sie ist flexibel, weil sich z.B. ein neuerService vergleichsweise einfach in ein bestehendes Netzwerkvon Services integrieren oder austauschen lässt. Ein Servicekann ggf. in mehreren Netzwerken verwendet werden. Vorallem aber können ggf. Services miteinander kommunizie-ren, die völlig unabhängig voneinander, beispielsweise beiverschiedenen Firmen, entwickelt und betrieben werden.

Kommunizierende Workflow-Services modellieren und analysieren 91

Ein typisches Beispiel für einen Service ist die Organi-sation der Vermietung von Fahrzeugen eines Autoverleihers:Der Autoverleiher hat seine Geschäftsprozesse rechnerinte-griert eingerichtet und kommuniziert entsprechend mit Kun-den, Fahrzeughändlern, Versicherern etc. Damit betreibt ereinen Workflow-Service, also einen Service, dessen Kontroll-struktur ein Workflow ist.

Beim Mieten eines Fahrzeugs realisiert auch ein Kun-de einen Workflow-Service: Er weist eine Fahrerlaubnis vor,wählt eine Versicherungsvariante aus, nimmt den Autoschlüs-sel entgegen, etc.

Autoverleiher und Kunde schließen einen Vertrag, indemsie über eine gemeinsame Schnittstelle Informationen, Doku-mente und Objekte austauschen und schließlich gemeinsameinen Endzustand erreichen.

1.2 Die Sprache BPEL

Die Kontrollstruktur eines Service kann als Software reali-siert sein. Interessanterweise entwickelt sich aber gerade zurBeschreibung von Services eine Sprache, BPEL1, zum Stan-dard, in der Kontrollstrukturen als Workflow, also die opera-tionelle Beschreibung eines Geschäftsprozesses, spezifiziertwerden. BPEL wurde von IBM und Microsoft als Weiterent-wicklung von WSFL bzw. XLANG im Juli 2002 vorgeschla-gen. Die Sprache wird inzwischen von einem Konsortiumaus über 130 Firmen unterstützt.

BPEL basiert auf bekannten Middleware-Technologien,insbesondere dem Web Service Technology Stack, bestehendaus Core Layers für den Transport und die Formatierung vonNachrichten und Emerging Layers, die Quality of Service ga-rantieren und letztlich die verteilten Geschäftsprozesse reali-sieren. Teil der Emerging Layers ist auch die Web Service De-scription Language (WSDL), dem bereits etablierten Stan-dard zur Spezifikation von Schnittstellen.

Ein BPEL-Prozess beschreibt den Aufbau eines Ge-schäftsprozesses innerhalb eines Web-Service und spezifi-ziert zugleich die Interaktion eines einzelnen Geschäftspro-zesses mit den Partnern seiner Umgebung.

Der Web Service Technology Stack mit BPEL an derSpitze ist nicht der einzige Ansatz, eine Architektur für Web-Services zu definieren. Ein konkurrierender Vorschlag ist bei-spielsweise Electronic Business XML (ebXML) von OASIS.BPEL ist jedoch mit Abstand am weitesten verbreitet und an-erkannt. Wir zeigen in dieser Arbeit am Beispiel der SpracheBPEL, wie sich aus in der Praxis akzeptierten Beschreibungs-formen Modelle ableiten lassen, die einer theoretisch fundier-ten Analyse relevanter Fragestellungen zugänglich sind.

1.3 Zentrale Fragestellungen

Beim Entwurf von Workflow-Services entstehen spezifischeFragestellungen, die sich in zwei Klassen gliedern: Zum einen

1 Business Process Execution Language for Web Services [7], auchals BPEL4WS und WS-BPEL abgekürzt

geht es um die Frage der genauen Bedeutung, also das Ver-halten eines Workflow-Service. Das wird insbesondere kri-tisch, wenn bereits ausgeführte Aktivitäten (beispielswei-se die Buchung eines Fluges) zurückgesetzt werden müssen(weil sich beispielsweise später herausstellt, dass kein Hotel-zimmer verfügbar ist). Die zweite Klasse betrifft Eigenschaf-ten von Workflow-Services, beispielsweise die Möglichkeit,einen Workflow-Service sinnvoll zu nutzen. Wir gehen aufbeide Klassen ein:

Beim Verhalten von Workflow-Services unterscheidetman positiven Kontrollfluss, also die Formulierung des beab-sichtigten zielführenden Verhaltens und den negativen Kon-trollfluss, der das Verhalten im Fehler- und Ausnahmefall,insbesondere das Zurücksetzen (Kompensieren) von Aktivi-täten betrifft. BPEL trennt beide Aspekte sehr konsequentund stellt dabei Beschreibungsmittel für die transaktionaleKapselung von Serviceteilen bereit.

Bei den Eigenschaften von Workflow-Services ist derAspekt der Bedienbarkeit wichtig: Ein „vernünftiger“ Work-flow-Service hat einen wohldefinierten Anfangszustand, indem jede Ausführung beginnt. Entsprechend hat er einen odermehrere Endzustände. Die Abarbeitung eines Workflow-Ser-vice sollte nicht zu einem Deadlock führen (d.h. sowohlWorkflow-Service als auch Partner warten auf Nachrichten,Dokumente oder Güter, die vom anderen aber wegen dessenWarten nicht bereitgestellt werden). Die Abarbeitung sollteaußerdem nicht dazu führen, dass der Workflow-Service vomPartner gesendete Nachrichten, Dokumente oder Güter nichtverbraucht (und andersherum).

Die „Schuld“ an einem Deadlock oder unverbrauchbarenObjekt kann dabei nicht immer dem Workflow-Service zu-gesprochen werden. Ein „böswilliger“ Partner kann vernünf-tiges Verhalten verhindern, indem er beispielsweise Nach-richten nicht sendet, die der Workflow-Service erwartet. An-dererseits ist ein Workflow-Service wenigstens insofern für„gutartige“ Kommunikation verantwortlich, als seine Struk-tur dem Partner wenigstens die Möglichkeit gibt, eine einmalbegonnene Ausführung eines Service bis zum Endzustandvoranzubringen, also den Workflow-Service zu bedienen.

Wir studieren die Bedienbarkeit eines Workflow-Service,also die Frage nach der Existenz bedienender Partner. Dabeiberücksichtigen wir, ob ein Workflow-Service mit lediglicheinem Partner oder mit mehreren, unabhängig voneinanderagierenden Partnern, kommuniziert. Wir stellen Lösungen fürdie verschiedenen Varianten der Bedienbarkeit für Workflow-Services mit zyklenfreier Kontrollstruktur vor.

1.4 Die Notwendigkeit der Modellbildung

Im letzten Abschnitt haben wir Fragen aufgeworfen, die nichteinfach zu beantworten sind. Die Schwierigkeiten beginnenschon damit, dass die Semantik von Web-Service-Beschrei-bungssprachen wie BPEL letztendlich bisher nur umgangs-sprachlich formuliert vorliegt. So sind in BPEL Feinheitender Fehlerbehandlung, insbesondere das Zurücksetzen vonAktivitäten nicht eindeutig geklärt. Ob zwei BPEL-Prozesse

92 Wolfgang Reisig et al.

P und Q semantisch kompatibel (d.h. P und Q können mit-einander fehlerfrei interagieren), bedienbar (d.h. es existiertfür P ein Q, so dass P und Q semantisch kompatibel sind)oder austauschbar (d.h. anstelle von P kann immer Q ver-wendet werden) sind, kann aus ihrer gegebenen syntaktischenDarstellung nicht abgeleitet werden.

Man benötigt ein semantisches Modell für Web-Service-Beschreibungssprachen wie z.B. BPEL. Ein solches Modellstellt die Bedeutung der Prozesse auf der gewählten Abstrak-tionsebene eindeutig dar und stellt zugleich Techniken bereit,die die aufgeworfenen Fragen nach Bedienbarkeit, seman-tischer Kompatibilität und Austauschbarkeit von Prozessenbeantworten helfen.

Wir schlagen in dieser Arbeit ein solches Modell vor. Esverwendet High-Level Petrinetze. Die Gründe für diese Wahlwerden kurz erläutert:

Workflow-Services verwenden als elementare Objekteund Operationen abstrakte Aktivitäten, beispielsweise „Ant-wort auf eine Nachricht“ oder „einen Auftrag stornieren“,ohne eine konkrete Repräsentation in konventionellen Da-tenstrukturen (Integers, Arrays). High-Level Petrinetze un-terstützen das Konzept abstrakter Aktivitäten.

Für den Austausch von Nachrichten, Dokumenten undGütern gibt es oft keine oder nur grobe Zeitvorgaben. Insbe-sondere können sich Nachrichten „überholen“. Die Semantikvon Petrinetzen entspricht dem in natürlicher Weise.

Die Komposition einzelner Workflow-Services entsprichtunmittelbar der Komposition von Petrinetzen, indem manPlätze der Petrinetz-Modelle der Prozesse verschmilzt. Akti-vitäten verschiedener Prozesse wirken lokal und unabhängigvoneinander, genau wie Transitionen mit disjunkten Vor- undNachbereichen in einem Petrinetz.

Einige Aspekte von Workflow-Services, wie z.B. die Zu-ordnung von Rollen oder die Unterscheidung manueller vonmaschinellen Tätigkeiten, haben keinen wesentlichen Ein-fluss auf die hier studierten Fragestellungen. Sie sind daherauch nicht Bestandteil der Modellbildung.

1.5 Aufbau der Arbeit

Aus den geschilderten Sachverhalten und Fragestellungenfolgt der Aufbau dieser Arbeit: Im zweiten Abschnitt wirdzunächst die Semantik für Web-Service-Beschreibungsspra-chen am Beispiel von BPEL dargestellt. Der positive Kon-trollfluss ist dabei vergleichsweise einfach zu handhaben.Seine Semantik ist auch schon an anderer Stelle beschriebenworden [10–14, 18]. Wir konzentrieren uns auf den negati-ven Kontrollfluss und zeigen insbesondere am Beispiel derreceive-Aktivität, wie negativer Kontrollfluss innerhalb ei-nes kommunizierenden Geschäftsprozesses propagiert wird.Schließlich wird noch einmal validiert, warum die gewählteSemantik angemessen ist: Mit Hilfe eines Model Checkerswurde für konkrete BPEL-Prozesse gezeigt, dass ihr Modellfundamentale semantische Eigenschaften der BPEL-Spezifi-kation bewahrt. Durch die Formalisierung der Semantik vonBPEL können wir direkt Modelle kommunizierender Ge-schäftsprozesse aus realen Anwendungen ableiten.

Im dritten Abschnitt schlagen wir eine Vereinfachungder aus Workflow-Services generierten Petrinetze vor, mitdem Ziel, die computergestützte Analyse der Modelle zu ver-einfachen. Weiterhin werden mit Hilfe der Petrinetz-Klasseder „offenen Workflow-Netze“ verschiedene Varianten desBegriffes der Bedienbarkeit beleuchtet und gegenüber denSoundness-Konzepten der Literatur abgegrenzt.

Im vierten Abschnitt werden Algorithmen beschrieben,um die unterschiedlichen Formen der Bedienbarkeit zu verifi-zieren.

2 Petrinetz-Semantik für BPEL

2.1 Zentrale Konzepte der Sprache BPEL

BPEL ist eine ausführbare Sprache zur Beschreibung kom-munizierender Geschäftsprozesse. Diese Sprache wurde2002 von IBM, Microsoft und Bea entwickelt. Nachdemdas Konsortium auf über 130 Firmen anwuchs, wurde BPEL2004 der OASIS zur Standardisierung übergeben. Der Stan-dardisierungsprozess ist aber noch nicht abgeschlossen. DieSprache ist in einer XML-Syntax notiert und mit englischemFließtext informal beschrieben [7]. BPEL selbst bietet keinegraphische Notation. Es existiert lediglich die Business Pro-cess Modeling Notation (BPMN) [28], die auch die Darstel-lung von BPEL unterstützt. BPEL baut auf Aktivitäten auf.Man unterscheidet elementare und strukturierte Aktivitäten.

Zu den elementaren Aktivitäten zählen insbesondere in-voke (Senden einer Nachricht) und receive (Empfangen einerNachricht). Eine strukturierte Aktivität umschließt eine Men-ge von (ggf. ebenfalls strukturierten) Aktivitäten, für die sieeine kausale Ordnung der Ausführung definiert. Beispielesind u.a. sequence und flow, die gegebene Aktivitäten se-quentiell bzw. nebenläufig anordnen. Über das Konzept deslink können Aktivitäten eines flow kausal geordnet werden.

Eine Sonderrolle unter den strukturierten Aktivitätennimmt der scope ein: Ein scope umschließt eine Aktivität fürdie er einen fault handler und einen compensation handlerdefiniert. Ein fault handler erkennt Laufzeit-Fehler und kor-rigiert sie so weit wie möglich. Im Gegensatz dazu arbeitetder compensation handler im Stile eines Transaktionsmana-gers einer Datenbank: Er macht die Effekte der vollständigabgearbeiteten Aktivität seines scope rückgängig, sofern derumgebende scope das verlangt. Ein scope und eine Schnitt-stelle beschreiben einen BPEL-Prozess.

Ein BPEL-Prozess kann zugleich in mehreren Instanzenvorliegen, die nebenläufig ausgeführt werden. Jede Instanzenthält einen Identifizierer (correlation set). Eine Nachrichtwird einer Instanz eindeutig zugeordnet, wenn der Wert ihrescorrelation set sich aus dem Inhalt der Nachricht feststellenlässt. Der Wert des correlation set einer neu gebildeten In-stanz wird durch die erste ein- oder ausgehende Nachrichtinitialisiert.

Die informelle Beschreibung von BPEL ist in einigenAspekten ungenau, insbesondere im Bereich des compensa-tion handling. Zudem kann die Korrektheit und andere Ei-


genschaften von BPEL-Prozessen nicht gegen eine nur um-gangssprachlich gegebene Semantik verifiziert werden. Nö-tig ist vielmehr eine formale Semantik für BPEL.

Eine solche Semantik haben wir in [25, 26] beschrieben.Im Folgenden betrachten wir exemplarisch das semantischeModell der oben informell beschriebenen Aktivität receivein ihrem hierarchischen Kontext.

2.2 Das Muster für receive

Gegeben sei eine Instanz einer receive-Aktivität mit einervorliegenden Nachricht im Nachrichtenkanal. Die receive-Aktivität hat zudem eine Variable, mit der jeweils zuletztempfangenen Nachricht als aktuellem Wert.

In diesem Zustand verarbeitet die receive-Aktivität ei-ne eingehende Nachricht: Entweder wird die Nachricht neu-er Wert der Variable, oder die receive-Aktivität erzeugt ei-ne Fehler-Nachricht (weil beispielsweise das correlation setder Prozess-Instanz sich nicht aus der Nachricht feststellenlässt). Während des gesamten Verarbeitungsprozesses kanndie receive-Aktivität ein Stop-Signal empfangen und damitden Verarbeitungsprozess mit einer entsprechenden Nach-richt an ihre Umgebung abbrechen.

Abbildung 1 zeigt die Petrinetz-Repräsentation der re-ceive-Aktivität: Die „schwarze“ Marke auf dem Platz initi-al aktiviert die Instanz. Ihr correlation set ist c, der aktuel-le Wert der Variable ist v. Zudem zeigt Abb. 1 einen Zu-stand, in dem eine Nachricht n den Platz channel erreichthat. Damit ist t1 aktiviert mit der Validierung X = n undCS = c (Durch Pfeile ohne Inschrift, beispielsweise von in-itial nach t1, „fließt“ eine „schwarze“ Marke). Indem nun t1eintritt, verschwindet die „schwarze“ Marke von initial unddie Marke n von channel. Auf dem Platz running erscheintdas Paar (n, c).

Als Inschrift von t2 und negiert als Inschrift von t3 istcor(X) = CS ein logischer Ausdruck in den Variablen X undCS. Der Ausdruck wird zu falsch ausgewertet, wenn das mitder Funktion cor aus n berechnete correlation set nicht mit csidentisch ist. Außer dem eben beschriebenen Fehler könnenauch andere Fehler auftreten, die der Einfachheit halber inAbb. 1 nicht berücksichtigt werden. Die genaue Umsetzungin [25, 26] verallgemeinert dazu den logischen Ausdruck anden Transitionen t2 und t3.

Wenn der Ausdruck zu „wahr“ evaluiert wird, wird mitdem Eintritt von t2 die Variable auf den Wert n aktualisiertund damit die Aktivitäten beendet (Marke auf final). An-dernfalls wird über t3 eine Marke auf den Schnittstellenplatzfailed abgelegt. Damit haben wir den positiven Kontrollflussvon receive beschrieben: Er beginnt mit einer Marke auf in-itial und endet in final oder failed. Der positive Kontrollflusskann jederzeit durch ein Signal auf stop mit einer der Transi-tionen t4, t5 oder t7 unterbrochen werden. Einzelheiten dazuerläutert der nächste Abschn. 2.3.

Abbildung 1 zeigt das Muster für den Fall, dass das cor-relation set bereits initialisiert wurde. Der andere Fall, dascorrelation set wird durch die eingehende Nachricht initiali-siert, unterscheidet sich nur in einer Kante von Abb. 1 und

Abb. 1 receive-Muster

wird in dieser Arbeit nicht betrachtet. Wir verweisen den in-teressierten Leser auf [26].

2.3 Negativer Kontrollfluss

Der oben beschriebene positive Kontrollfluss des receive-Musters und aller anderen Muster ist intuitiv und formal ein-fach zu beschreiben. Deutlich schwieriger ist der negativeKontrollfluss: Wenn in einer Instanz einer Aktivität ein Fehlerauftritt, leitet sie den entsprechenden Fehler an den fault hand-ler ihres scope weiter. Als erstes wird der positive Kontroll-fluss dieses scope gestoppt. Anschließend wird der fault hand-ler aktiviert, der versucht, den aufgetretenen Fehler zu behan-deln.Kannder fault handlerdenFehlernichtbehandeln, reichter ihn an den fault handler seines umgebenden scope weiter.Kann der Fehler vom fault handler des Prozesses nicht bear-beitet werden, endet der Prozess, genauer die Prozessinstanz,fehlerhaft. Die BPEL-Spezifikation gibt lediglich die Anfor-derungen für das Beenden vor, z.B. ein flow wird beendet, in-dem alle seine eingebetteten Aktivitäten beendet werden. DieBPEL-Spezifikation macht keinerlei genaue Vorgaben, wiediese Anforderungen umgesetzt werden sollen.

In [26] schlagen wir ein Muster – das stop-Muster – fürdas Stoppen eines scope vor. Das stop-Muster stoppt die inAbb. 1 dargestellte Instanz des receive-Musters durch ein Si-gnal auf stop. Mit Hilfe der Transition t6 wird das Muster imFalle eines aufgetretenen Fehlers mit einem Signal auf stop-ped beendet. Im Gegensatz dazu verarbeiten die Transitionent4, t5, t7 das stop-Signal, indem sie den positiven Signalfluss


– wo immer er sich befindet – unterbrechen und mit einemSignal auf stopped beenden können. Man mag hier erwarten,dass t4 vor t1 und t5 vor t2 eine Priorität bekommt. Dies wür-de jedoch den asynchronen Charakter des Modells zerstören,ohne dass es die Menge der möglichen Abläufe ändert. Spä-testens mit einer Marke auf final wird das stop-Signal übert7 abgefangen.

Eine gesamte Prozessinstanz wird abgebrochen, indementlang ihrer induktiven Struktur Signale an einzelne Aktivi-täten propagiert werden.

2.4 Konzepte einer Petrinetz-basierten Semantik

Nachdem wir das semantische Modell der receive-Aktivitätbeschrieben haben, betrachten wir nun die generellen Kon-zepte der Petrinetz-Semantik.

Orientiert am hierarchischen Aufbau von BPEL-Prozes-sen beschreiben wir die Semantik von BPEL mit hierarchi-schen Petrinetzen. Jeder Aktivität wird ein Petrinetz, ihr Mu-ster, zugeordnet. Es gibt ein zusätzliches Muster – das inAbschn. 2.3 beschriebene stop-Muster. Das Muster jeder ele-mentaren Aktivität hat einen initial- und einen final-Platz.Über diese Schnittstelle können Muster komponiert werden.Beispielsweise ist die sequentielle Anordnung von zwei In-stanzen des receive-Musters ein Muster, in dem der final-Platz der ersten receive-Instanz der initial-Platz der zweitenreceive-Instanz ist. Zusätzlich müssen die beiden receive-Muster noch an die stop-Komponente des sequence-Musters„angeschlossen“ werden. Allgemein formuliert, jedes Mustereiner strukturierten Aktivität hat entsprechende Steckplätzefür die Muster der einzubettenden Aktivitäten. Da auch dieMuster der strukturierten Aktivitäten einen initial- und einenfinal-Platz haben, können sie selbst wieder (wie Aktivitätenvon BPEL) komponiert werden.

Die Sammlung unserer 45 Muster zusammen mit denRegeln für ihre Komposition und ihre Hierarchisierung bil-det die Petrinetz-Semantik für BPEL [26]. Ein Muster mussdie fundamentalen, semantischen Eigenschaften der entspre-chenden BPEL-Aktivität bewahren, wie sie in der BPEL-Spezifikation informal beschrieben sind.

Die oben dargestellten Muster sind nicht zu verwech-seln mit den Workflow-Patterns von van der Aalst et al. [2].Workflow-Patterns stellen Anforderungen an Geschäftspro-zessbeschreibungssprachen dar. Dazu gehört beispielsweiseauch das Kompensieren von Aktivitäten, das in [2] infor-mal beschrieben ist (Pattern Cancel Activity). Die BPEL-Spezifikation legt auch informal, aber wesentlich detaillier-ter fest, wann ein compensation handler aktiviert wird undwie dessen Ausführung aussieht. Die Petrinetz-Semantik istoperationell und implementiert die informale Beschreibungder BPEL-Spezifikation.

2.5 Validierung der Petrinetz-Semantik

Für die oben vorgestellte Petrinetz-Semantik ist es nicht mög-lich, formal zu beweisen, dass sie die fundamentalen semanti-

Abb. 2 Purchase Order Prozess

schen Eigenschaften der informalen BPEL-Spezifikation be-wahrt. Aus diesem Grund ist es notwendig, die Semantikauf ihre Plausibilität zu überprüfen. Dazu müssen wir einehinreichend große Anzahl von BPEL-Prozessen in ein Pe-trinetz entsprechend der Semantik transformieren und unter-suchen, ob die Muster wie erwartet zusammenspielen undob das Modell zum entsprechenden BPEL-Prozess seman-tisch äquivalent ist. Zu diesem Zweck abstrahieren wir in denPetrinetz-Mustern von Daten, d.h. wir richten unser Haupt-augenmerk auf den Kontrollfluss. Wir formulieren Behaup-tungen über Eigenschaften des abstrakten Petrinetzmodells.Diese Behauptungen verifizieren wir mit Hilfe unseres Petri-netz-basierten Werkzeugs LoLA [22] – einem explizitenModel Checker, der leistungsstarke Reduktionstechnikenimplementiert.

In [24] haben wir mit der Validierung der Petrinetz-Se-mantik begonnen und einen BPEL-Prozess in ein Petrinetzübersetzt. Es handelt sich dabei um eine Modifikation desPurchase Order Prozesses aus der BPEL-Spezifikation [7, S.14 ff.], visualisiert in Abb. 2. Wir verwenden in Abb. 2 ei-ne Variante der in Abschn. 2.1 erwähnten BPMN. Sie un-terscheidet den Kontrollfluss zwischen zwei Aktivitäten voneinem link zwischen den Aktivitäten.

Jede Aktivität ist durch ein Rechteck dargestellt. Einenscope oder den Prozess visualisieren wir mit einer dickerenLinie. Sequentieller Kontrollfluss ist durch gestrichelte Pfei-le gekennzeichnet, Nebenläufigkeit von Aktivitäten durch dieparallele Anordnung der Aktivitäten. Ein Pfeil mit durchge-zogener Linie symbolisiert einen link. Betrachten wir denAblauf: Nachdem der Prozess die Bestellung des Kundenerhalten hat (receive), werden drei Aufgaben parallel initi-


iert: die Berechnung des Endpreises für die Bestellung (linkeSequenz), die Auswahl eines Spediteurs (mittlere Sequenz)und die zeitliche Planung der Produktion und des Versandes(rechte Sequenz). Zwischen diesen drei Aufgaben existierenAbhängigkeiten, die mit Hilfe der links modelliert werden.Nachdem die drei Aufgaben erledigt sind, kann die Rechnungan den Kunden gesendet werden (reply).

Obwohl es sich bei diesem Prozess um ein einfachesBeispiel handelt, werden verschiedene Aktivitäten inklusi-ve fault handler und links verwendet. Um die Komplexitätnoch etwas zu erhöhen, haben wir das synchrone invoke ineinen scope eingebettet, so dass im Falle eines Fehlers ei-ne Fehlernachricht gesendet werden kann. Mit Hilfe dieserKonstruktion konnten wir das Abbrechen eines eingebettetenscope untersuchen.

Das entsprechend unserer Semantik transformierte Netzhat 158 Plätze und 249 Transitionen und wurde per Hand ge-neriert. Der Zustandsraum besteht aus 9991 Zuständen. UnterVerwendung der Reduktionstechniken konnte der Zustands-raum auf 1286 Zustände reduziert werden.

Wir haben den Prozess nach toten Plätzen und Transi-tionen untersucht. LoLA berechnete 15 tote Plätze und 101tote Transitionen. Diese doch erhebliche Anzahl von Plätzenund Transitionen beruht nicht – wie man vielleicht annehmenkönnte – auf einem Fehler bei der Transformation des BPEL-Prozesses, sondern ist auf die Muster zurückzuführen: JedesMuster der Semantik deckt das vollständige Verhalten derentsprechenden Aktivität ab, insbesondere sämtliche Spezi-alfälle. Beispielsweise enthält der scope aus Abb. 2, der dassynchrone invoke einbettet, ein stop-Muster. Das stop-Musterkann z.B. auf einen Fehler reagieren, der bei der Ausführungdes compensation handler signalisiert wird. Da der scope inAbb. 2 keinen scope einbettet und somit der compensationhandler bei seiner Aktivierung nichts macht, kann kein Fehlerauftreten. Aus diesem Grund enthält das stop-Muster einigeüberflüssige Konstruktionen, die nie verwendet werden. Inzukünftigen Arbeiten planen wir, die Modelle flexibel zurLaufzeit zu bilden. Mit anderen Worten, wir wollen die Mu-ster erstens genau auf den jeweiligen BPEL-Prozess „maß-schneidern“, und zweitens auf die Sachverhalte beschränken,die im jeweiligen Kontext benötigt werden.

Des Weiteren berechnete LoLA die 196 (erwarteten) End-zustände des Prozesses. Schließlich haben wir noch einigemusterspezifische Eigenschaften verifiziert, wie beispiels-weise „jeder Ablauf der stop enthält wird später einmal auchstopped enthalten“ oder „die target-Aktivität eines links trittimmer nach der source-Aktivität auf“.

Der Validierung schloss sich die Verifikation des Purcha-se Order Prozesses an. Hier wurden die prozessspezifischenEigenschaften untersucht, beispielsweise die Terminierungoder das Problem, ob der Prozess dem Kunden immer ei-ne Antwort sendet. Bei der letzten Eigenschaft handelt essich um eine sehr komplexe temporallogische Formel, derenGültigkeit aber von unserem Werkzeug aufgrund des kleinenZustandsraums problemlos berechnet werden konnte.

Die Resultate bei der Validierung der Semantik mit Hil-fe von LoLA zeigen die Plausibilität der Semantik. LoLA

kann auch größere Prozesse verifizieren, da die Redukti-onstechniken des Werkzeugs auf den aus BPEL gewonne-nen Petrinetzen gut arbeiten. Diese Aussage untermauernweitere größere Fallstudien der Praxis mit einer Größen-ordnung von 50 Aktivitäten, die mit Hilfe von LoLA verifi-ziert werden konnten [16]. Die Transformation eines BPEL-Prozesses von dieser Größenordnung ermöglicht uns ein Par-ser, BPEL2PN [15], der einen in BPEL spezifizierten Prozessin ein Petrinetz entsprechend der Semantik übersetzt.

3 Abstrakte Modelle

3.1 Abstraktion

Der Hauptgrund für die Verwendung von High-Level Petri-netzen für die semantische Fundierung von BPEL ist derenFähigkeit, Datenaspekte korrekt abzubilden. Für die Abbil-dung des Kontrollflusses reichen dagegen Modellierungsmit-tel, die bereits von Low-Level Petrinetzen bereitgestellt wer-den. Low-Level Netze haben Plätze, die ununterscheidbare(in den Abbildungen als schwarze Punkte gezeichnete) Mar-ken tragen.

Wegen ihrer geringeren Komplexität eignen sich Low-Level Netze wesentlich besser für die Analyse relevanterEigenschaften. Die Kontrollstruktur eines BPEL-Prozessesgewinnt man durch Abstraktion von Datenaspekten. Im Mo-dell schlägt sich diese Abstraktion dadurch nieder, dass z.B.auf Kommunikationskanälen statt des Inhalts einer Nachrichtnur noch die Anwesenheit einer Nachricht modelliert wird.Wenn inhaltliche Aspekte von Nachrichten den Kontrollflussbeeinflussen, kann man einen Kanal für solche Nachrichtendurch mehrere Kanäle ersetzen. Hat z.B. im High-Level Mo-dell eine Nachricht einen Wahrheitswert als Inhalt, führt manim Low-Level Modell zwei Kanäle ein, wobei die Anwesen-heit einer Nachricht in einem der Kanäle eine Nachricht mitInhalt true und eine Nachricht im anderen Kanal eine Nach-richt mit Inhalt false repräsentiert.

Mit ähnlichen Konstruktionen kann man auch andere be-sonders wichtige Datenabhängigkeiten mit den Mitteln vonLow-Level Petrinetzen ausdrücken. Einen geeigneten Gradan Abstraktion kann man entweder manuell, auf der Grundla-ge von Kenntnissen über das modellierte System, oder durcheinen automatischen Prozess der schrittweisen Abstraktions-verfeinerung [5] gewinnen.

3.2 Offene Workflow-Netze

Die Abstraktion von BPEL-Prozessen führt zu Petrinetzenmit einigen typischen strukturellen Merkmalen. Auf der Ba-sis dieser Merkmale wird in diesem Abschnitt eine Klassevon Petrinetzen, offene Workflow-Netze (oWFN), vorgestelltund in den folgenden Abschnitten weiter studiert. Dabei istes im weiteren Verlauf dieses Artikels nicht mehr relevant,ob die untersuchten Netze aus BPEL-Prozessen entstandenoder anderweitig generiert wurden.


Abb. 3 oWFN. Die umrandeten Plätze sind Schnittstellenplätze. a, b,g und h sind Eingangskanäle, c, d, e und f Ausgangskanäle. Die beidenUmrandungen sollen andeuten, dass für dieses Netz zwei unabhängigagierende Partner vorgesehen sind

Abbildung 3 zeigt ein oWFN. In einem oWFN gibt esAnfangs- und möglicherweise mehrere Endmarkierungen.In Abb. 3 ist die Anfangsmarkierung dargestellt. Das Netzhat eine einzige Endmarkierung: ω trägt genau eine Mar-ke, alle anderen Stellen sind unmarkiert. Weiterhin gibt esin einem oWFN Schnittstellenplätze (in Abb. 3 die Stellen abis h). Ein Schnittstellenplatz modelliert einen asynchronenNachrichtenkanal zu einer nicht modellierten Umgebung.Die Schnittstellenplätze sind unterschieden in Eingangs- undAusgangskanäle. Ein Eingangskanal (in Abb. 3 a, b, g undh) hat keine Transitionen in seinen Vorbereich, ein Aus-gangskanal (die übrigen Schnittstellenplätze in Abb. 3) keineTransitionen in seinem Nachbereich. Die Schnittstellenplät-ze sind partitioniert in Ports. In Abb. 3 gibt es zwei Ports,{a, c, e, g} und {b, d, f, h}. Die Aufteilung in Ports re-präsentiert die Tatsache, dass die Umgebung eines oWFNaus unabhängigen, autonom agierenden Partnern besteht. Sohat ein Online-Reisebüro z.B. Schnittstellen zu einem Kun-den, zu einem Flugreservierungssystem und einem Hotel-reservierungssystem. Ein oWFN-Modell eines solchen Rei-sebüros würde dann die Schnittstellenplätze in drei Portspartitionieren.

Die Markierung der Schnittstellenplätze kann nicht nurim oWFN selbst, sondern auch von der Umgebung des Pro-zesses verändert werden. Eine Umgebung kann Marken vonAusgangskanälen entfernen und Marken auf Eingangskanä-len erzeugen.

Offene Workflow-Netze umfassen echt die Klasse derWorkflow-Netze [1]. Der entscheidende Unterschied sind da-bei die in [1] nicht vorgesehenen Schnittstellenplätze. We-gen der dadurch modellierten Offenheit gegenüber einer Um-gebung ergeben sich völlig neuartige Fragestellungen. Einedieser Fragestellungen, Bedienbarkeit, wird im nächsten Ab-schnitt vorgestellt.

3.3 Bedienbarkeit

In [1] wird für Workflow-Netze der Begriff der Soundnessstudiert. Ein Workflow-Netz ist sound, falls es von jeder er-reichbaren Markierung aus in einen Endzustand übergehen(terminieren) kann und jede Transition aktivierbar ist. Derhier vorgestellte Begriff der Bedienbarkeit passt den Begriffder Soundness auf die Klasse der oWFN an.

Ob ein oWFN terminiert oder in einen Deadlock gerät,hängt im allgemeinen davon ab, ob die Umgebung „proto-kollgerecht“ agiert. Terminierung bei jedem möglichen Ver-halten der Umgebung zu verlangen, wäre sicher ein zu star-kes Kriterium, da eine böswillige Umgebung immer in derLage ist, erwartete Nachrichten zu verweigern oder unerwar-tete Nachrichten zu senden. Wir können aber ganz sicher einoWFN N dann als fehlkonstruiert ausweisen, wenn es fürdie Umgebung überhaupt keine Möglichkeit gibt, so mit Nzu interagieren, dass N terminiert.

Wir können uns das Verhalten einer bestimmten Umge-bung, ebenfalls durch ein oWFN modelliert, vorstellen. Einsolches oWFN wollen wir Partner nennen, wobei wir, um derim vorigen Abschnitt motivierten Strukturierung der Umge-bung in unabhängige Teile gerecht zu werden, je einen Part-ner pro Port vorsehen. Ein Partner für einen Port π einesoWFN N ist ein oWFN M mit einem einzigen Port, dergenau die Stellen in π umfasst, aber in umgekehrter Aus-richtung: Ist eine Stelle aus π Ausgangskanal in N , so istsie Eingangskanal ist M und umgekehrt. Abgesehen von denSchnittstellenplätzen, setzen wir die Elemente von N und Mals disjunkt voraus.

Für ein oWFN und seine Partner ist der Begriff der Kom-position unmittelbar einsichtig: Es werden sämtliche Stellen,Transitionen und Kanten vereinigt. Die Anfangsmarkierungeiner Stelle ergibt sich als die Summe aller Marken auf dieserStelle in denjenigen Netzen, in denen sie vorkommt. Endmar-kierungen werden analog gebildet, für jede Kombination ausje einer Endmarkierung pro beteiligtem oWFN. Im kompo-nierten System gibt es keine Schnittstellenplätze mehr.

Auf der Basis der Begriffe Partner und Komposition de-finieren wir nun den Begriff Bedienbarkeit: Ein oWFN Nheißt bedienbar, falls Partner (einer pro Port von N ) der-art existieren, dass im komponierten Netz von jeder Markie-rung aus eine Endmarkierung erreichbar ist. Ist dabei jedeTransition von N im komponierten System aus N und we-nigstens einem Tupel von Partnern aktivierbar, so nennenwir N vollständig bedienbar. Da das komponierte Systemkeine Schnittstellenplätze enthält, also im wesentlichen einWorkflow-Netz nach [1] ist2, heißt vollständige Bedienbar-keit also die Existenz von Partnern, mit denen komponiert Nsound ist.

Von einer Menge von Partnern mit den gesuchten Eigen-schaften sagen wir, sie bedienen N bzw. bedienen N voll-ständig.

2 es gibt bei van der Aalst einige syntaktische Einschränkungen, z.B.die Existenz je eines Start- und Endplatzes, auf die wir bei oWFNverzichten.


In [8] wird der Begriff der relaxed Soundness als die Exi-stenz eines Schedulers für ein Workflow-Netz N definiert, derdas Verhalten von N so beschränkt, dass N sound wird. Derdort verwendete Begriff des Schedulers unterscheidet sich si-gnifikant von unserem Begriff von Partnern. Während unserePartner über die Schnittstellen asynchron und „von außen“mit N wechselwirken, agiert der Scheduler aus [8] synchronund im „Inneren“ von N , hat insbesondere direkten Zugriffauf die Markierung sämtlicher Stellen von N (nicht nur derSchnittstellenplätze).

Der Begriff der Bedienbarkeit stellt daher ein neues Kon-zept dar und verlangt neue Heransgehensweisen für seineAnalyse. Im nächsten Abschnitt stellen wir Techniken zurAnalyse der Bedienbarkeit vor.

4 Analyse der Bedienbarkeit

Bedienbarkeit verlangt die Existenz bestimmter Partner fürein gegebenes oWFN. Wir stellen nun Entscheidungsverfah-ren für die Bedienbarkeit azyklischer oWFN vor, also vonoWFN, in denen keine Markierung von sich selbst wiedererreichbar ist.

4.1 Automaten als Partner

Unser Verfahren ist konstruktiv, im Fall der Bedienbarkeitwird also ein Satz bedienender Partner explizit angegeben.Für die Berechnung der Partner gehen wir jedoch einen Um-weg. Statt direkt oWFN zu berechnen, konstruieren wir zu-nächst Automaten, die die gleiche Rolle wie die gesuchtenPartner spielen. Aus diesen Automaten berechnen wir dannoWFN derart, dass ihr Erreichbarkeitsgraph genau den kon-struierten Automaten entspricht. Für die Berechnung einesoWFN aus einem Automaten verweisen wir auf die Techni-ken aus [3, 6, 9, 19] und gehen hier nicht weiter darauf ein.

Wir betrachten im Rest dieses Abschnittes also klassi-sche endliche Automaten. Da sie letztlich das Verhalten vonPartnern beschreiben, nennen wir sie ebenfalls Partner. Ab-bildung 4 zeigt zwei solche Automaten. Einen Partner, derden Port π benutzt, modellieren wir als Automat, der auf demAlphabet π operiert. Einen Übergang mit einem Ausgangs-kanal des Netzes bezeichnen wir demnach als Empfangsakti-on und einen Übergang mit einem Eingangskanal des Netzesals Sendeaktion des Partners.

Das Zusammenspiel eines oWFN N mit einer MengeM von Partnern beschreiben wir als Transitionssystem, dasKooperationssystem von N mit M. Abbildung 5 zeigt dasKooperationssystem des oWFN aus Abb. 3 mit den beidenPartnern in Abb. 4.

Ein Zustand eines Kooperationssystems ist ein Tupel, dasaus einer Markierung von N sowie je einem Zustand derPartner besteht. Jeder Übergang eines Partnerautomaten undjedes Schalten einer Transition des oWFN definiert je einenÜbergang im Kooperationssystem wie folgt. Ein mit x be-schrifteter Übergang eines Partners bewirkt, dass eine Marke

Abb. 4 Ein mögliches Paar von Partnern des oWFN aus Abb. 3. Siebedienen das oWFN. Würde sich Partner 1 allerdings wie Partner 2verhalten (also durch den gleichen Automaten, nur mit jeweils den Vor-gängerbuchstaben beschriftet), so würde das System in dem Zustandverklemmen, wo alle Nachplätze von t1 oder die von t2 markiert sind

Abb. 5 Kooperationssystem für das oWFN aus Abb. 3 und die Partneraus Abb. 4. Jeder Übergang im Kooperationssystem entspricht einemÜbergang im oWFN oder einem der Partner. Dabei bewirkt ein Über-gang eines Partners die Änderung der Markierung eines Schnittstellen-platzes des oWFN

auf Schnittstellenplatz x von N erzeugt bzw. entfernt wird.Wir verzichten hier auf eine formale Definition, merken aberan, das diese Definition genau den Kompositionsbegriff füroWFN nachbildet.

Wir unterscheiden für das Bedienbarkeitsproblem dreiFragestellungen. Die erste Fragestellung nennen wir zentraleBedienbarkeit. Hier untersuchen wir oWFN, die genau einenPort besitzen.

Im zweiten Fall, der verteilten Bedienbarkeit, betrachtenwir oWFN mit mehr als einem Port.

Der dritte Fall, autonome Bedienbarkeit, ist ein Spezi-alfall verteilter Bedienbarkeit. Hier fragen wir, ob sich die


Partner für die einzelnen Ports sogar unabhängig voneinan-der konstruieren lassen.

Für alle drei Fragestellungen bieten wir Lösungen für denFall an, dass das oWFN azyklisch ist. Sämtliche in diesemAbschnitt gezeigten Beispielnetze sind azyklisch.

4.2 Entscheidungsverfahren für zentrale Bedienbarkeit

Zur Lösung des zentralen Bedienbarkeitsproblems ist es un-ser Ziel, einen bedienenden Partner für ein gegebenes oWFNN zu konstruieren, wann immer einer existiert. Ein solcherPartner muss mit N geeignet kommunizieren. Ob eine be-stimmte Nachricht in einer bestimmten Situation geeignetoder ungeeignet ist, hängt natürlich davon ab, in welcherMarkierung sich N gerade befindet. Die Entscheidung, obein Partner eine Nachricht sendet oder auf den Empfang einerNachricht wartet, muss der Partner aber treffen, ohne direk-ten Zugriff auf diese Markierung zu haben. Zur Entscheidungkann er lediglich die jeweils aufgelaufene Kommunikationheranziehen. In Kenntnis von N kann man aus der aufge-laufenen Kommunikation Rückschlüsse auf die Markierungvon N ziehen. Man kann zwar im allgemeinen nicht exaktbestimmen, in welcher Markierung sich N befindet, kann je-doch die Menge der möglichen Markierungen eingrenzen.Das „Wissen“ eines Partners über bisherige Kommunikationspiegelt der jeweils erreichte Zustand des Partners wieder.Die Rückschlüsse aus der aufgelaufenen Kommunikation aufdie Markierungen, in denen sich N befinden kann, könnenwir also darstellen als eine Abbildung K (knowledge), diejedem Automatenzustand q des Partners die Menge derjeni-gen Markierungen zuordnet, in denen sich N befinden kann,während der Partner sich in q befindet. Zu gegebenem Nund einem beliebigen gegebenen Partner können die WerteK (q) aus dem zugehörigen Kooperationssystem abgeleitetwerden.

Mit Hilfe dieser Zuordnung können wir ein Kriterium fürbedienende Partner aufstellen.

Theorem 1(CharakterisierungbedienenderPartner, [23])Ein einzelner Partner M bedient ein oWFN N genau dann,wenn für alle Zustände q von M und alle Markierungenm ∈ K (q) gilt: Wenn bei m keine Transition von N schaltenkann, so ist m eine Endmarkierung oder es gibt in q Über-gänge für M, die in [m, q] im Kooperationssystem aktiviertsind.

Dieses Kriterium liefert ein Verfahren zur Konstruktioneines bedienenden Partners: Wir konstruieren den Partneraus einem Automaten, der in jedem Zustand jede möglicheSende- und Empfangsaktion vorsieht, also eher mehr als dasletztlich akzeptable Verhalten umfasst. Diesen Automatenkönnen wir als Baum konstruieren, dessen Tiefe der erwähn-ten Obergrenze für Kommunikationsschritte entspricht, undin dem von jedem inneren Knoten mit jedem Zeichen desAlphabets (also mit jedem Schnittstellenplatz des gegebenenoWFN) ein Übergang vorhanden ist. Zu jedem Zustand qdieses Automaten kann man nun den Wert K (q) berechnen

Abb. 6 Ein oWFN

Abb. 7 Konstruktion eines bedienenden Partners für das oWFN N inAbb. 6. Gezeigt ist der Automat, mit dem man die Konstruktion be-dienender Partner beginnt, zusammmen mit den Werten der Wissens-funktion K , wobei Markierungen, bei denen in N keine Transitionenaktiviert sind, mit (d) gekennzeichnet sind. Die Zustände sind mit Se-quenzen aus Schnittstellenplätzen beschriftet, zeigen also die bis dahinstattgefundene Kommunikation. Wir streichen zunächst alle terminalenKnoten, wo ein mit (d) gekennzeichneter Zustand möglich ist, der keineEndmarkierung (d*) ist. Nach dem Streichen des Zustands links untenmuss auch dessen Vorgänger gestrichen werden, weil nun auch er keinenNachfolger hat, aber einen mit (d) gekennzeichneten Zustand in K (q)enthält. Es verbleibt der Automat, der aus den ausgefüllt dargestelltenZuständen besteht. Dieser bedient das Netz in Abb. 6

und in K (q) Markierungen bestimmen, in denen keine Tran-sition von N aktiviert ist. Solange es Zustände gibt, die dasKriterium aus Thm. 1 verletzen, werden diese Zustände sowiedie bei diesen Zuständen beginnenden Teilbäume gestrichen.Wir verzichten hier auf die Präsentation von Pseudocode undverweisen stattdessen auf das in Abb. 7 dargestellte Beispielder Berechnung eines bedienenden Partners für das oWFNin Abb. 6.

Terminiert die Konstruktion mit einem nichttrivialen Au-tomaten (also einer nichtleeren Zustandsmenge), ist das Netzbedienbar. Führt die Konstruktion dagegen zu einem Automa-ten mit leerer Zustandsmenge, ist das Netz nicht bedienbar.

Diese Konstruktion ist in dieser Form für große Netze si-cher nicht durchführbar, weil der Automat, mit dem wir star-ten, zu viele Zustände hat. Um diesem Problem zu begegnen,haben wir bereits eine Reihe von Reduktionen vorgeschla-gen [27], die genau diese Zustandsexplosion bekämpfen.


Auf der Basis unserer Konstruktion können wir zeigen,dass es zu jedem oWFN einen eindeutig bestimmten libe-ralsten bedienenden Partner gibt, also einen, aus dem einzigdurch weitere Verhaltenseinschränkung jeder beliebige an-dere bedienende Partner abgeleitet werden kann. Mit Hilfedes liberalsten Partners kann leicht vollständige Bedienbar-keit untersucht werden: Ein oWFN ist vollständig bedienbargenau dann, wenn jede Transition bei Komposition mit demliberalsten bedienenden Partner aktivierbar ist.

4.3 Entscheidungsverfahren für Verteilte Bedienbarkeit

Wir stellen nun ein Entscheidungsverfahren für den Fall vor,dass ein oWFN mehrere Ports hat. Beispielsweise bedienendie beiden Partner aus Abb. 4 zusammen das oWFN in Abb. 3verteilt.

Wenn ein oWFN verteilt bedienbar ist, kann man die be-dienenden Partner zusammen als einen Partner auffassen, derdas oWFN zentral bedient (nach Vereinigung aller Ports zueinem einzigen): Mit einem geeigneten Begriff für paralleleKomposition ist der zentrale Partner die parallele Komposi-tion der verteilt bedienenden Partner.

Umgekehrt kann man die Frage nach verteilt bedienendenPartnern auffassen als die Frage nach einem zentral bedienen-den Partner, der die Form einer parallelen Komposition ver-teilter Partner hat. Diese Form hat ein zentraler Partner, fallsdie zu verschiedenen Ports gehörenden Übergänge sich nichtgegenseitig beeinflussen. Ein Übergang von q nach q ′ mit xbeeinflusst einen Übergang von q1 nach q ′

1 mit y, wenn imzentral bedienenden Partner eine der folgenden Bedingungengilt:

– x aktiviert y: q ′ = q1 und es gibt keinen Übergang mit ybei q;

– x deaktiviert y: q = q1 und es gibt keinen Übergang mity bei q ′;

– Die Reihenfolge von x und y ist relevant: Es gibt einenÜbergang von q ′ zu einem q ′′ mit y und einen Übergangvon q ′

1 zu einem q ′′2 mit y, die bei q ′′ und q ′′

1 beginnendenTeilbäume des Partners sind aber nicht isomorph.

Theorem 2 (Verteilte Bedienbarkeit [23]) Ein oWFN istverteilt bedienbar genau dann, wenn es einen zentral bedie-nenden Partner gibt, in dem sich die zu verschiedenen Portsgehörenden Übergänge nicht gegenseitig beeinflussen.

Eine Implementierung der gezeigten Idee führt zu einemAlgorithmus, der mit Backtracking arbeitet. Wir verzichtenhier auf eine Darstellung dieses Algorithmus. Backtrackingals Bestandteil einer Implementation scheint unumgänglich,weil wir es, wie Abb. 8 zeigt, mit Symmetriebruchproble-men3 zu tun haben, für die Backtracking eine der wenigenLösungsmöglichkeiten darstellt. Das Beispiel zeigt weiter-hin, dass es im verteilten Fall nicht notwendigerweise eineeindeutig bestimmte „liberalste“ Menge bedienender Partnergibt.

3 Das Problem, in einem System gleichartiger Partner aus einem sym-metrischen in einen unsymmetrischen Zustand überzugehen.

Abb. 8 Für das oben abgebildete oWFN lassen sich die beiden darunterdargestellten bedienenden Partnerpaare berechnen. Beide Partner zu-sammen bedienen das oWFN jeweils verteilt. Obwohl das Netz selbstsymmetrisch ist, sind die beiden bedienenden Umgebungen nicht insich symmetrisch (sondern nur zueinander). Es gibt für das oWFN keinsymmetrisches Paar bedienender Partner

4.4 Autonome Bedienbarkeit

Für das Problem der verteilten Bedienbarkeit wird eine Men-ge von Partnern konstruiert, die gemeinsam das Netz bedie-nen. Der Konstrukteur der Partner kann dabei jeden Partnerin Kenntnis der anderen Partner konstruieren. In Abb. 8 kanner beispielsweise den Partner für Port {b} nur dann so bilden,dass dieser gar keine Aktion ausführt, wenn der Partner fürPort {a} tatsächlich die Aktion a ausführt.

Hier fragen wir uns nun, inwieweit es sinnvoll und über-haupt möglich ist, einen einzelnen der beteiligten Partner oh-ne Kenntnis der anderen Partner zu konstruieren. Wir suchenalso einen Partner, der mit beliebigen anderen Partnern zu-sammen das gegebene oWFN bedient. In dieser Fassung istdie Fragestellung allerdings trivial: Beliebig „destruktive“andere Partner können Bedienbarkeit immer verhindern. Wirbeschränken uns deshalb auf kooperative Partner und defi-nieren zunächst diesen Begriff.

Im weiteren sei N ein oWFN mit den Ports π1, . . . , πkund πi ein ausgezeichneter Port. Im weiteren definieren wir,wann ein Partner eine Markierung beachtet, bei der keineTransition von N aktiviert ist, wie das auf πi reduzierte NetzNπi aussieht, wann ein Partner von N kooperativ ist undschließlich, wann ein oWFN autonom bedienbar heißt.

Sei U ein Partner, der Port πi benutzt, also, wie in Ab-schn. 3.3 definiert, ein endlicher Automat mit Alphabet πi .Für einen Zustand q von U kann die in Abschn. 4.2 defi-nierte Menge K (q) Markierungen enthalten, in denen keineTransition von N aktiviert ist. Sei m eine solche Markierung,z.B. die Markierung βχ des Netzes in Abb. 3. Für m be-trachten wir die Menge E derjenigen Eingangskanäle, die inm unmarkiert sind, deren Markierung aber wenigstens eine


Transition von N aktivieren würde. Für die Markierung βχwäre E = {a, b}. U beachtet m, falls kein Eingangskanalaus E zum Port von U gehört oder es in U einen Übergangbei q gibt, der in m möglich ist, also entweder eine beliebi-ge Sendeaktion oder eine Empfangsaktion von einer bei mmarkierten Schnittstelle.

Es mag verwundern, dass wir in q nicht unbedingt eineSendeaktion auf ein Element aus E fordern. Diese Liberali-tät ist einerseits notwendig, weil U in q Gelegenheit habensoll, vielleicht noch einige Empfangsaktionen auszuführen,oder Sendeaktionen, die später relevant sind, bereits vorzu-ziehen. Andererseits ist die Liberalität auch ausreichend, weilgegebenenfalls die bei m deaktivierten Transitionen deakti-viert bleiben und das Problem also nur aufgeschoben wird.Unendlichen Aufschub können wir durch eine Abschätzungder Höchstzahl der Kommunikationsschritte mit dem (azy-klischen!) oWFN ausschließen.

Das oWFN Nπi reduziert N auf die Schnittstellenplät-ze des Ports πi . Nπi entsteht aus N durch Streichen allerSchnittstellen, die nicht in πi liegen, sowie durch Streichender angrenzenden Kanten. Der Partner U ist kooperativ, wenn

– er jede Markierung von N beachtet, in der keine Transi-tion von N aktiviert ist und bei der wenigstens ein un-markierter Eingangskanal in πi liegt, und

– Nπi zentral bedient.

Zum oWFN in Abb. 3 ist Partner 1 aus Abb. 4 kooperativ,Partner 2 dagegen nicht. Die Markierung βχ liegt in K (6)

(dem Anfangszustand von Partner 2) und der von Partner 2benutzte Eingangskanal b ist unmarkiert. Partner 2 beach-tet diese Markierung nicht, weil er im Zustand 6 lediglichdie in βχ nicht möglichen Empfangsaktionen d und f alsÜbergänge hat.

Ein oWFN nennen wir autonom bedienbar, falls es zujedem seiner Ports einen kooperativen Partner gibt.

Kooperative Partner sind deshalb interessant, weil koope-rative Partner in der Lage sind, mit jedem beliebigen anderenkooperativen Partner zusammenzuarbeiten:

Theorem 3 ([23]) Jede Partnermenge, die für jeden Port ei-nes oWFN einen kooperativen Partner enthält, bedient dasoWFN.

Die Existenz kooperativer Partner (und also autonomeBedienbarkeit) können wir, für jeden Port einzeln, mit einemAlgorithmus entscheiden, der mit dem für zentrale Bedien-barkeit fast identisch ist.

Verhalten sich beide Partner aus Abb. 4 nach dem Sche-ma wie Partner 1 (also kooperativ), terminiert das oWFN inAbb. 3, während es in den Markierungen βχ bzw. δε ver-klemmen kann, wenn beide sich wie Partner 2 verhalten. Fürdas oWFN in Abb. 8 existieren keine kooperativen Partner;es ist nicht autonom bedienbar.

5 Zusammenfassung

Neben der Bedienbarkeit gibt es eine Reihe weiterer wich-tiger Fragestellungen an Modelle kommunizierender Work-

flow-Services, beispielsweise die Konstruktion eines publicviews oder von Bedienungsanleitungen, Äquivalenzbegrif-fe und Probleme semantikerhaltender Verfeinerung, sowiedas weite Feld transaktionalen Verhaltens. Einige Fragestel-lungen betreffen nur die Kontrollstruktur kommunizierenderWorkflow-Services, andere sind auch von Datenaspekten ab-hängig (beispielsweise die Konstruktionen zur Semantik vonBPEL in Abschn. 2). Petrinetze bieten Varianten an, die genauauf beide Aspekte zugeschnitten sind und in engem Zusam-menhang stehen.

Zusammengefasst formuliert, sollen die in diesem Bei-trag dargestellten Konzepte und Algorithmen zeigen, dassdie oben geschilderten Begriffe mit Petrinetzen angemessenmodelliert und computergestützt analysiert werden können.

Literatur

1. Aalst W (1998) The Application of Petri Nets to Workflow Manage-ment. The Journal of Circuits, Systems and Computers 8(1):21–66

2. Aalst W, Hofstede A, Kiepuszewski B, Barros AP (2003) Workflowpatterns. Distrib Parallel Databases 14(1):5–51

3. Badouel E, Darondeau P (1998) Theory of regions. LNCS: Lectureson Petri Nets I: Basic Models 1491:529–586

4. Casati F, Ceri S, Pernici B, Pozzi G (1995) Conceptual Modeling ofWorkflows. In: Papazoglou MP (ed) Proceedings of the OOER’95,14th International Object-Oriented and Entity-Relationship Mo-delling Conference, Springer-Verlag, vol 1021, pp 341–354

5. Clarke E, Grumberg O, Jha S, Lu Y, Veith H (2003) Counter-example-guided abstraction refinement for symbolic modelchecking. J ACM 50(5):752–794

6. Cortadella J, Kishinevsky M, Lavagno L, Yakovlev A (1998) Deri-ving petri nets from finite transition systems. IEEE Trans Comput47(8):859–882

7. Curbera F, Goland Y, Klein J, Leymann F, Roller D, WeerawaranaS (2003) Business Process Execution Language for Web Services,Version 1.1. Tech. rep., BEA Systems, International Business Ma-chines Corporation, Microsoft Corporation

8. Dehnert J, Rittgen P (2001) Relaxed soundness of business proces-ses. LNCS: Advanced Information System Engineering, CAISE2001 2068:157–170

9. Desel J, Reisig W (1996) The Synthesis Problem of Petri Nets.Acta Informatica 33(4):297–315

10. Fahland D (2005) Complete Abstract Operational Semantics forthe Web Service Business Process Execution Language. Tech. Rep.190, Humboldt-Universität zu Berlin

11. Farahbod R, Glässer U, Vajihollahi M (2004) Specification andValidation of the Business Process Execution Language for WebServices. In: Abstract State Machines, Springer, LNCS, vol 3052,pp 78–94

12. Ferrara A (2004) Web services: a process algebra approach. In:ICSOC, ACM, pp 242–251

13. Fisteus JA, Fernández LS, Kloos CD (2004) Formal Verificationof BPEL4WS Business Collaborations. In: Proceedings of the 5thInternational Conference on Electronic Commerce and Web Tech-nologies (EC-Web ’04), Springer, LNCS

14. Fu X, Bultan T, Su J (2004) Analysis of interacting BPEL webservices. In: WWW ’04: Proceedings of the 13th international con-ference on World Wide Web, ACM Press, pp 621–630

15. Hinz S (2005) Implementation einer Petrinetz-Semantik fürBPEL4WS. Diplomarbeit, Humboldt-Universität zu Berlin

16. Hinz S, Schmidt K, Stahl C (2005) Transforming BPEL to Pe-tri Nets. In: accepted for Third International Conference on Busi-ness Process Management (BPM 2005), Nancy, France, September2005

17. Hollingsworth D (1995) The workflow reference model. Tech. Rep.TC00-1003, Workflow Management Coalition


18. Foster H, Magee J, Uchitel S, Kramer J (2003) Model-based Veri-fication of Web Service Compositions. In: 18th IEEE InternationalConference on Automated Software Engineering, IEEE ComputerSociety, pp 152–163

19. Nielsen M, Rozenberg G, Thiagarajan PS (1992) Elementary tran-sition systems. Theoretical Computer Science 96

20. Oberweis A (1996) Modellierung und Ausführung von Work-flows mit Petri-Netzen. Teubner Reihe Wirtschaftsinformatik, B.G.Teubner Verlag, Stuttgart, Germany

21. Schmelzer HJ, Sesselmann W (2004) Geschäftsprozessmanage-ment in der Praxis, 4th edn. Hanser

22. Schmidt K (2000) Lola – a low level analyser. In: Nielsen M, Simp-son D (eds) International Conference on Application and Theoryof Petri Nets, Springer-Verlag, LNCS, vol 1825, p 465 ff

23. Schmidt K (2004) Controlability of Business Processes. Tech. Rep.180, Humboldt-Universität zu Berlin

24. Schmidt K, Stahl C (2004) A Petri net semantic for BPEL4WS – va-lidation and application. In: Kindler E (ed) Proceedings of the 11thWorkshop on Algorithms and Tools for Petri Nets (AWPN’04),Universität Paderborn, pp 1–6

25. Stahl C (2004) Transformation von BPEL4WS in Petrinetze. Di-plomarbeit, Humboldt-Universität zu Berlin

26. Stahl C (June, 2005) A Petri Net Semantic for BPEL. Tech. Rep.188, Humboldt-Universität zu Berlin

27. Weinberg D (2004) Analyse der Bedienbarkeit. Diplomarbeit,Humboldt-Universität zu Berlin

28. White SA (2004) Business Process Modelling Notation Version1.0. Tech. rep., Business Process Management Initiative (BPMI)

Wolfgang Reisig studierte Mathe-matik in Karsruhe und in Bonn.Er arbeitete als Assistent an derRWTH Aachen, wo er 1979 pro-movierte. Von 1983–1987 arbeite-te er als Projektleiter bei Dr. Pe-tri. Zwischen 1987–1993 war er alsProfessor an der TU München tä-tig. Seither leitet er den Lehrstuhl„Theorie der Programmierung“ ander Humboldt-Universität zu Berlin.Sein Forschungsschwerpunkt sindformale Modelle für verteilte und re-aktive Syteme.

Karsten Schmidt promovierteund habilitierte an der Humboldt-Universität zu Berlin. Er arbeiteteaußerdem bereits an der HelsinkiUniversity of Technology, der Tech-nischen Universität Dresden und derCarnegie Mellon University in Pitts-burgh. Er arbeitet als wissenschaft-licher Mitarbeiter am Lehrstuhl„Theorie der Programmierung“an der Humboldt-Universitäthauptsächlich im Gebiet ModelChecking sowie der Modellierungund Analyse von Workflows.

Christian Stahl studierte Informa-tik an der Humboldt-Universität zuBerlin. Er arbeitet als wissenschaft-licher Mitarbeiter am Lehrstuhl„Theorie der Programmierung“ ander Humboldt-Universität. SeineForschungsschwerpunkte sind Mo-dellierung und Verifikation verteil-ter Systeme, vor allem Workflowsund asynchrone Hardware.

kommunizierende workflow-services modellieren und analysieren

Documents