1 Einleitung Motivation Aufgabenstellung Aufbau der Arbeit Grundlagen Web Services Business Process

1 Einleitung ... 2

1.1 Motivation ... 2

1.2 Aufgabenstellung ... 3

1.3 Aufbau der Arbeit ... 3

2 Grundlagen ... 4

2.1 Web Services Business Process Execution Language (BPEL) ... 4

2.2 Linda ... 7

2.3 Executable Workflow Networks (EWFN) ... 9

2.4 Allgemeines Vorgehen ... 11

2.4.1 Generic Pattern ... 12

2.4.2 Places ... 12

2.4.3 Grafische Darstellung ... 13

3 Übersetzung der Grundaktivitäten ... 15

3.1 receive ... 15

3.2 reply ... 19

3.3 invoke ... 22

3.4 throw ... 25

3.5 wait ... 26

3.6 empty ... 28

4 Übersetzung der strukturierten Aktivitäten ... 30

4.1 sequence ... 30

4.2 while ... 33

4.3 repeatUntil ... 34

4.4 if ... 35

4.5 pick ... 39

4.6 flow ... 43

4.7 Link Semantics ... 45

4.7.1 Source-Aktivität ... 46

4.7.2 Target-Aktivität ... 48

4.8 forEach ... 50

5 Übersetzung des Scopes ... 53

5.1 Scope ... 53

5.2 Fault Handlers ... 59

5.3 Compensation Handler ... 64

5.4 Termination Handler ... 66

5.5 Default Compensation Order ... 68

5.6 Compensation-Aktivitäten ... 68

5.7 Event Handlers ... 72

6 Implementierung ... 76

6.1 EWFN Markup Language (EML) ... 76

6.1.1 TupleType ... 76

6.1.2 Tuple ... 77

1 Einleitung

Komplexität ist eine Tatsache in der Welt der Informationstechnologie. Diese zu bewältigen bei der Erstellung neuer oder das Austauschen existierender Software, sowie die zeitgemäße Erfüllung von Wartungs- und Erweiterungsanforderungen stellen eine der Hauptherausforderung heutzutage dar.

Würden alle Applikationen eine kompatible Programmierschnittstelle sowie gemeinsame Interoperabilitätsprotokolle nutzen, dann würde die Komplexität enorm reduziert werden und bestehende Funktionalität kann sehr einfach wieder verwendet werden. Durch das Etablieren einer gemeinsamen Programmierschnittstelle, durch die Applikationen aufgerufen werden können, existierende IT-Infrastruktur kann einfach ersetzt und modernisiert werden.

Durch solche verheißungsvollen Ansätze nimmt das Service Oriented Development of Applications (SODA) seit langem einen festen Platz in der Softwareentwicklung. Seine Umsetzung anhand einer Service Oriented Architecture (SOA) [Erl05] schafft die Grundlage für neue unternehmensstrategische Lösungsansätze, wie z. B. Enterprise Application Integration (EAI) [HW03, Lin99], automatisierte Geschäftsprozesse sog. Workflows, etc.

Eine SOA ermöglicht die Erstellung von Services, durch die Applikations-, System- und Unternehmensgrenzen überwinden und Geschäftsprozesse rationalisiert werden können.

Solche Services sind heutzutage aus der Welt der Informationstechnologie kaum noch wegzudenken. Ihre weite Verbreitung liegt in der Etablierung einer Reihe von Web Service Standards. Die Web Services Description Language (WSDL) [New02] hat sich zu einer Standard- Programmierschnittstelle entwickelt, durch die auf eine beliebige Applikation zugegriffen werden kann, und SOAP [KST01] - zu einem Standard- Interoperabilitätsprotokoll, durch das Applikationen Nachrichten austauschen können. Diese zwei Standards bilden die Grundlage für die Umsetzung von Web Services und auf die bauen weitere Web Service-Spezifikationen auf, die zusätzliche Unternehmensanforderungen und quality of service erfüllen. Solche Spezifikationen widmen sich den Themen Sicherheit (WS- Security), Zuverlässigkeit (WS-ReliableMessaging), Transaktionen (WS-Transaction), Orchestrierung (BPEL), etc.

1.1 Motivation

Die Orchestrierung von Web Services, ermöglicht durch die Standard-Sprache BPEL, ist ein Beispiel der Two-level-Programmierparadigma, wo einzelne Services zu neuen Services sog.

Web Service-Flows zusammengesetzt werden. Diese werden mit Hilfe von BPEL- Kontrollflusskonstrukten definiert. Während die einzelnen Services von unterschiedlichen Partnern und auf damit auf unterschiedlichen Knoten implementiert werden können, wird die Ausführung von Web Service-Flows, d .h. die Evaluierung der BPEL-Prozesslogik, heutzutage durch eine zentralisierte Workflow-Engine, die Teil eines Workflow-Management- Systems ist, vorgenommen.

Es existiert jedoch eine Vielzahl an Szenarien, wo dieser zentralisierter schwergewichtiger Ansatz als ein Nachteil erscheint. So führen besonders komplexe Partner-Interaktionen zu

unnatürlichen Prozessmodellen, die nicht mehr durch das primäre Unternehmensziel, sondern durch infrastrukturelle oder Organisationsgegebenheiten gesteuert sind.

1.2 Aufgabenstellung

Grundlage dieser Arbeit stellen die Web Services Business Process Execution Language (BPEL) (vgl. Abschnitt 2.1) und Executable Workflow Networks (EWFN) (vgl. Abschnitt 2.3) dar.

BPEL ist der Standard für die Beschreibung von Geschäftsprozessen, der in der Lage ist verschiedene Services zu einer Gesamtanwendung zu verknüpfen. Auf dem Markt befindet sich bereits ein breites Spektrum an verschiedensten Implementierungen des BPEL-Standards.

Zusätzlich existiert eine Fülle an Werkzeugen für die Modellierung, Verwaltung, Monitoring etc. von BPEL-Prozessen.

EWFN basieren auf gefärbte Petri-Netze [Jen92] und Boolesche-Netze [LSW97] und stellen ein geeignetes Modell für die verteilte und dezentralisierte Ausführung von BPEL-Prozessen.

Das Modell zeichnet sich durch eine wohlgeformte, formale Syntax und eine wohl definierte Semantik [MWL08a].

In der vorliegenden Arbeit soll ein Verfahren spezifiziert werden, das BPEL-Prozesse in semantisch äquivalente EWFNs transformiert. Zusätzlich soll ein geeignetes Datenformat für die Darstellung von EWFN definiert und ein Tool implementiert werden, das BPEL-Dateien in dieses Ziel-Datenformat umwandelt.

1.3 Aufbau der Arbeit

Die vorliegende Arbeit gliedert sich in sieben Kapiteln. Diese sind:

Kapitel 2 – Grundlagen führt durch eine ausführliche Beschreibung in die Begriffe Web Services Business Process Execution Language, Linda-Modell und Executable Workflow Networks ein, die die Grundlage für die nachfolgenden Kapitel darstellen. Anschließend wird der Ansatz vorgestellt, der in den Kapiteln 3 bis 5 angewendet wird.

Kapitel 3 – Übersetzung der Grundaktivitäten, Kapitel 4 – Übersetzung der strukturierten Aktivitäten, Kapitel 5 – Übersetzung des Scopes beschreiben jede BPEL- Aktivität und die Idee bei ihrer Übersetzung in ein EWFN. Anschließend werden die einzelnen Schritte bei der EWFN-Ausführung detailliert erläutert und das EWFN grafisch dargestellt.

2 Grundlagen

2.1 Web Services Business Process Execution Language (BPEL)

Web Services Business Process Execution Language (BPEL) [JMS06, WCL+05] ist eine Sprache für die Definition und Ausführung von Geschäftsprozessen. Obwohl sie nicht die einzige Standard-Sprache ist, ist sie mit Abstand der bekannteste und damit am weitest verbreitete Vertreter der Business Process-Sprachenfamilie.

Es gibt im Allgemeinen zwei Darstellungsformen für Geschäftsprozesse: XML und grafisch.

BPEL ist zusammen mit Business Process Modeling Language (BPML) [bpm], XML Process Definition Language (XPDL) [wmc] und anderen Vertretern unter den XML-basierten Sprachen einzusiedeln. Grafische Spezifikationssprachen sind unter anderem die Business Process Modeling Notation (BPMN) [BPM08]sowie UML-Aktivitätsdiagramme [PP05].

IBM, Microsoft und BEA waren hauptsächlich an der Erstellung der BPEL-Spezifikation [OAS07a] beteiligt und die meisten BPEL-Konzepte decken sich mit früheren Business Process Management (BPM) Initiativen dieser Unternehmen: IBM’s Web Services Flow Language (WSFL) [Wes02], Microsoft’s XLANG und BEA's Process Definition for Java (PD4J).

Die BPEL-Spezifikation basiert auf existierende Standards, wie z.B. Web Services Definition Language (WSDL) [W3C07a], XMLSchema [W3C04a], XPath [W3C07b] und WS- Addressing [W3C04b]. In der Vergangenheit waren Web Services Interaktionen zustandslos.

BPEL ermöglicht es zustandsbehaftete und lang andauernde Geschäftsprozesse, basierend auf Web Services, zu definieren.

Jede BPEL-Prozessdefinition besteht aus zwei Dateitypen:

• WSDL: spezifiziert Web Services Interfaces – Partner Link Types, Properties, Port Types, Operations, Messages und Parts – die vom BPEL-Prozess sowie aufgerufen als auch implementiert werden.

• BPEL: spezifiziert den Prozess in XML. Dieser beinhaltet die primäre Aktivität, Partner Links, Correlation Sets, Variables, sowie alle Handler.

Die WSDL-Dateien zusammen mit der Prozessdefinition bilden den Kontrollfluss für den Prozess, der wiederum mit externen Partnern über Web Services Schnittstellen kommunizieren kann. Ein BPEL-Prozess enthält Aktivitäten über die andere Web Services aufgerufen werden, sowie der BPEL-Prozess selbst von externen Partnern aufgerufen werden kann. Solche Aktivitäten sind receive, pick, invoke, reply und EventHandlers. Jeder BPEL- Prozess muss mit einer receive- oder pick-Aktivität beginnen, d.h. er muss als ein Service aufgerufen werden. Abbildung 1 zeigt ein Travel Agency Process in einem typischen BPEL- Szenario.

Abbildung 1: Travel Agency Process [CW03]

Der Source-Code ist eine BPEL- sowie eine oder mehrere WSDL-Dateien. Diese werden in einer BPEL-Execution Engine deployed, welche die Ausführung der Prozesslogik überwacht.

Der Travel Agency Process startet durch das Empfangen einer Nachricht vom Customer Process, die Daten zu einer Reise enthält. Er versucht dann ein Hotel, Flug und Mietwagen zu buchen und anschließend sendet eine Bestätigung an den Customer Process. Der Customer Process läuft parallel mit dem Travel Agency Process und Aktionen in dem einen lösen Aktionen in dem anderen aus. Die Interaktionen mit den einzelnen Reservierungssystemen basieren auf Web Services und diese sind gewöhnlich zustandslos.

Abbildung 2 zeigt ein UML-Klassendiagramm des BPEL-Objektmodells. Im Folgenden werden die einzelnen Objekte kurz vorgestellt und damit die Struktur eines BPEL-Prozesses erläutert.

Abbildung 2: BPEL-Objektmodell [CW03]

• Process: ein Process enthält ein oder mehrere der nachfolgenden Objekten.

• Variable: eine Variable wird in einem Process oder Scope verwendet. Der Typ darf ein WSDL-Message Type, ein XSD-Element oder ein XSD-Basic Type sein. Ein Process oder Scope kann mehreren Variablen definieren.

• Property, Property Alias: ein Property ist eine Dateneinheit in einer WSDL-Message.

Ein Property Alias ist ein XPath-Ausdruck, um den Wert des Properties aufzufinden.

• Correlation Set: ein Correlation Set ist eine Menge von Properties, um Nachrichten mit einer Prozess-Instanz zu korrelieren. Ein Process oder Scope kann mehrere Correlation Sets definieren.

• Partner Link Type: ein Partner Link Type ist eine Abbildung von Web Services Port Types zu Partner Roles.

• Partner Link: ein Partner Link definiert weche Role der Process ausführt, sowie welche Roles externe Partner ausführen sollten. Ein Process oder Scope kann mehrere Partner Links definieren.

Alle Aktivitäten sind ausführich in den Kapiteln 3 und 4 beschrieben. Die Handlers sind im Kapitel 5 aufgeführt.

In den nachfolgenden Kapiteln werden einige Begriffe stets verwendet. Um den Erklärungsaufwand zu minimieren, werden sie an dieser Stelle erläutert.

Correlation Consistency Constraint: nachdem ein Correlation Set initialisiert worden ist, müssen die Werte der Properties für alle Messages in allen Operations, die dieses Correlation Set spezifizieren, identisch sein.

Correlation Initiation Constraint: im Abhängigkeit des Wertes des initiate-Attributes eines Correlation Set Elements werden folgende Fälle unterschieden.

• initiate=“yes“: die Aktivität, die dieses Correlation Set spezifiziert, muss versuchen dieses zu initialisieren. Ist das Correlation Set bereits initialisiert, muss der BPEL- Standardfehler bpel:correlationViolation signalisiert werden.

• initiate=“join“: die Aktivität, die dieses Correlation Set spezifiziert, muss versuchen dieses zu initialisieren, falls noch nicht initialisiert. Ist das Correlation Set bereits initialisiert und das Correlation Consistency Constraint verletzt, muss der BPEL- Standardfehler bpel:correlationViolation signalisiert werden.

• initiate=“no“ oder nicht explizit gesetzt: die Aktivität, die dieses Correlation Set spezifiziert, darf dieses nicht initialisieren. Ist das Correlation Set nicht bereits initialisiert, muss der BPEL-Standardfehler bpel:correlationViolation signalisiert werden. Ist das Correlation Set bereits initialisiert und das Correlation Consistency Constraint verletzt, muss der BPEL-Standardfehler bpel:correlationViolation signalisiert werden.

Dead Path Elimination (DPE): wird eine Target-Aktivität (vgl. Abschnitt 4.7) aufgrund ihrer JoinCondition (explizit oder implizit) nicht ausgeführt, dann muss der Status ihrer ausgehenden Links auf den Wert false gesetzt werden. Dieses Verfahren wird solange angewendet, bis der Kontrollfluss, gebildet von aufeinander folgenden Links, eine Aktivität erreicht, deren JoinCondition zu dem Wert true evaluiert.

2.2 Linda

In [Gel85] definiert man Linda als ein Modell und Sprache, neben Monitors [Ben06], Message Passing [HW03] und Remote Operations [Lin99], für die Koordination von verteilten Anwendungen [MSM04, Gof04].

Linda unterscheidet sich von dem klassischen Message Passing-Modell, in dem was Gelernter communication orthogonality nennt. Communication orthogonality bezieht sich dabei auf Interprozesskomunikation, die in Raum, Zeit und Ziel völlig entkoppelt ist.

unterstützt. IBM’s TSpaces zeichnen sich durch erweiterte matching-Algorithmen und Operationen für mehrere Tuple (z.B. AND und OR), sowie XML-content.

Linda ist keine vollständige Programmiersprache, sondern eine Kommunikations- und Koordinationssprache. Sie ist gedacht als eine Erweiterung zu einer Host-Sprache, um durch ihre Koordinationsprimitiven eine Basis für parallele und verteilte Anwendungen zu schaffen.

Diese Koordinationsprimitiven bilden die read()-, in()- und out()-Operation. Die Idee dabei ist, dass mehrere Prozesse über ein gemeinsames Tuple Space und unter Benutzung der Linda-Operationen kommunizieren und sich koordinieren.

Ein Tuple Space stellt einen Container für Tuples dar, wobei ein Tuple als eine geordnete Liste von typisierten Feldern definiert wird. Ein Tuple wird als aktiv bezeichnet, falls ein oder mehrere seiner Felder berechnet werden, dagegen enthält ein passives Tuple reine Daten. Die Linda-Operationen manipulieren das Tuple Space basierend auf ein spezifiziertes Template.

Templates stellen Tuples in ein Linda-Programm dar. Ein Template erweitert dabei die Definition eines Tuples durch die Unterscheidung der Felder von passiven Tuples in formal oder actual. Formal-Felder repräsentieren typisierten Wildcards für die matching- Operationen.

Die read()- und in()-Operation benutzen eine Form von associative addressing, um nach einem Tuple in dem Tuple Space zu suchen, das ihrem spezifizierten Template entspricht.

Wenn erfolgreich ausgeführt, liefern diese Operationen eine Kopie des entsprechenden Tuples in dem alle formal-Felder durch ihre actual-Felder ersetzt worden sind. Zusätzlich entfernt die in()-Operation das Tuple aus dem Tuple Space. Werden mehrere Tuples, die dem spezifizierten Template entsprechen, gefunden, dann wird nichtdeterministisch eins davon zurückgegeben. Existieren dagegen kein entsprechendes Tuple in dem Tuple Space, dann blockieren die Operationen solange, bis ein Tuple durch eine out()-Operation zu dem Tuple Space hinzugefügt wird. Die out()-Operation erzeugt ein neues Tuple in dem Tuple Space.

Dieses Tuple ist eine Kopie des in der Operation spezifizierten Templates. Alle drei Linda- Operationen operieren nur auf passive Tuples. Die read()- und in()-Operation sind synchron, dagegen wird die out()-Operation asynchron ausgeführt.

Ein einfaches one-to-one Communication Pattern zwischen zwei Prozessen kann als eine Kombination aus einer out()-Operation, gefolgt von einer in()-Operation, wie Abbildung 3 zeigt, ausgedrückt werden. In diesem Beispiel ist („point“, 27, 11) das Tuple, das vom Prozess 1 in dem Tuple Space geschrieben wird. Das Template („point“, i:integer, j:integer) enthält ein actual-Feld („point“), anhand dessen ein passendes Tuple gesucht wird, und zwei formal-Felder, die durch ein vorangestelltes „?“ gekennzeichnet sind. Die zwei Variablen i und j werden mit den Werten 27 und 11 belegt, wenn die entsprechende in()-Operation erfolgreich ausgeführt wird.

Andere Communication-, wie z.B. one-to-many, many-to-one, oder Synchronization-Patterns, können aus den einfachen Linda-Primitiven synthetisiert werden. Für weitere Details des Linda-Programmiermodells wird auf [CG90] verwiesen.

Abbildung 3: One-to-One Communication Pattern

Communication orthogonality bezieht sich auf drei für verteilte Programmierung besonders erwünschten Eigenschaften.

• Destination decoupling: das Tuple Space agiert als eine Art Channel auf dem Informationen für die Kommunikation verteilter Prozesse generiert wird und von dem Informationen gelesen werden. Anders als bei Message Passing benötigt der Sender der Information keine Auskunft darüber, wer der Empfänger ist und umgekehrt weiß der Empfänger-Prozess nicht, wer die Information in dem Tuple Space bereitgestellt hat.

• Time decoupling: Informationen können in dem Tuple Space zur Verfügung gestellt werden, lange bevor ein Empfänger-Prozess überhaupt existiert. Umgekehrt können Informationen erst gelesen werden, nachdem der Sender-Prozess nicht mehr existiert.

• Space decoupling: Tuples in dem Tuple Space werden durch associative addressing aufgesucht. Dadurch stellt das Tuple Space ein plattformunabhängiger Speicherort dar.

2.3 Executable Workflow Networks (EWFN)

Executable Workflow Networks (EWFN) [WML08] definieren ein Modell für die Ausführung von BPEL-Prozessen auf ein Linda-Tuplespace-System (vgl. Abschnitt 2.2). Sie basieren auf gefärbten Petri-Netzen [Jen92] und Boolesche Netzen [LSW97].

Ein EWFN ist ein gerichteter Graph EWFN = (Σ, P, T, F, X, A, Lw). Σ = {CF, DATA × N,

• Daten-Tokens: ein Daten-Token ist definiert als DATA = („DATA“ × N × N) an dem Variablen-Definitionen angehängt sind. Die Daten-Tokens repräsentieren BPEL- Variablen und Prozess-Metadaten.

• Empty-Token: ε ist das leere Token. Dieses enthält keine Daten.

Die zwei Integer-Felder repräsentieren die Prozessmodell- und Prozessinstanz-ID und ermöglichen die Unterscheidung zwischen mehreren Prozessmodellen sowie mehreren Prozessinstanzen.

P ist die Menge der Plätzen (places) und T - die Menge der Transitionen (transitions).

F = (T × P) U (P × T × R), mit R = (read, take) ist die Menge der Kanten (arcs). Diese Menge definiert, dass eine Kante zwei Plätzen oder zwei Transitionen nicht verbinden darf.

Die EWFN- Kanten entsprechen den Linda-Operationen (vgl. Abschnitt 2.2). Die Kanten aus der Menge (T × P) (write-Kanten) entsprechen der Linda out()-Primitive, die Kanten aus der Menge (P × T × read) (read-Kanten) – der Linda read()-Operation, während Kanten aus der Menge (P × T × take) (take-Kanten) – der Linda in()-Primitive.

X ist die Menge der Templates. Diese können entweder konkrete Werte oder Variablen als Platzhalter enthalten.

A: (P × T × R) → X ist eine totale Funktion, die read- und take-Kanten ein Template zuweist.

Lw: (T × P) →Σ ist eine totale Funktion, die jeder write-Kante ein Token zuweist.

Eine detaillierte Beschreibung der Syntax und der Semantik von EWFNs ist in [MWL08a]

aufgeführt.

Um die Anforderungen der vorliegenden Arbeit zu genügen, wird das EWFN-Modell an zwei Stellen erweitert.

Zum einen wird ein dritter Wert „fail“ in dem B-Feld des Kontrollfluss-Tokens aufgenommen. Dieser Wert signalisiert, dass ein Fehler bei der Ausführung einer Aktivität (vgl. Abschnitt 2.1) aufgetreten ist und dadurch wird ein Handler eine Terminierung der Aktivität anstoßen.

Zum anderen wird das Kontrollfluss-Token um ein fünftes Feld (History-Feld) erweitert, das der Prozesszustand aus der Sicht einer Aktivität darstellt. Dieser Prozesszustand setzt sich aus allen in einem Scope (vgl. Abschnitt 2.1) definierten Daten zusammen und wird beim Aktivieren eines Scopes im History-Feld (als ein Integer-Wert) mit übertragen. Wird der Scope zu Ende ausgeführt, so wird de letzte Komponente im History-Feld abgeschnitten. Zu beachten ist, dass das History-Feld als ein Tupel definiert wird. Dadurch können alle Aktivitäten, sowie Handlers bei verschachtelten Scopes auf ihren aktuellen Prozesszustand zugreifen. Abbildung 4 zeigt ein Beispiel dafür, wie das History-Feld an ein Token angehängt bzw. von diesem abgeschnitten wird. Das Beispiel stellt eine while-Aktivität, die Scope A enthält, dar. Scope A enthält seinerseits Scope B als seine primäre Aktivität. Weiterhin zeigt das Beispiel den Token-Fluss in Scope A und ScopeB unter der Annahme, dass die while- Aktivität zweimal ausgeführt wird. Beim Aktivieren von Scope A in der ersten while-Instanz wird in das History-Feld die Scope-Instanz-ID mit dem Wert 1 geschrieben. Danach wird Scope B aktiviert und das History-Feld um die Scope-Instanz-ID (enthält den Wert 1) von

Scope B erweitert. Das gleiche gilt für die zweite while-Instanz. Beim Verlassen von Scope B wird das History-Feld um die letzte Komponente (enthält den Wert 1) gekürzt. Das gleiche gilt, wenn der Kontrollfluss Scope A verlässt.

Abbildung 4: Beispiel: History-Feld

betrachtet, da er die Struktur eines BPEL-Prozesses widerspiegelt. Ein BPEL-Prozess enthält unter anderem eine primäre Aktivität. Dabei kann es sich um jede beliebige BPEL-Aktivität handeln, d.h. ein BPEL-Prozess kann sowohl eine Basic-Aktivität als auch eine Structured- Aktivität, die wiederum eine Basic-Aktivität oder eine Structured-Aktivität rekursiv enthalten kann, spezifizieren. Die Idee, die dabei nahe liegt, ist daher jede BPEL-Aktivität, basic oder structured, getrennt in ein EWFN zu übersetzen und diese resultierende EWFN anhand von Schnittstellen-Plätzen sog. Interface-Places zu einem Process-EWFN zu verbinden.

2.4.1 Generic Pattern

Alle EWFN in den Kapitel 3 bis 5 sind nach einem Generic-Pattern aufgebaut. Dieses unterscheidet man nach zwei Kriterien: nach der EWFN-Struktur und nach den Inerface- Places.

• nach der EWFN-Struktur: man unterscheidet zwischen EWFN, die elementare Schritte bei der Ausführung der Prozesslogik, z.B. Web Sevice-Aufrufe, Zuweisung von Werten an Variablen, etc., ausführen und EWFN, die den Prozess-Kontrollfluss steuern und daher andere EWFN einbetten. Beispiel für die erste Art von EWFN sind alle Grundaktivitäten (vgl. Abschnitt 3), dagegen sind alle strukturierte Aktivitäten (vgl. Abschnitt 4), der Scope, sowie alle Handler (vgl. Abschnitt 5) ein Beispiel für die zweite Art von EWFN.

• nach den Interface-Places: man unterscheidet zwischen EWFN, die nur über Interface-Places verfügen um den Kontrollfluss aufzunehmen (start) bzw. diesen wieder an andere EWFN zu übergeben (ended) und EWFN, die einen Fehler signalisiert bekommen und aufgrund dessen über zusätzliche Plätzen das Terminieren von eingebetteten Aktivitäten vornehmen. Zu der ersten Gruppe gehören alle EWFN von Grundaktivitäten und strukturierten Aktivitäten. Zu der zweiten Gruppe zählen der Scope, der FaultHandler, der TerminationHandler, die EventHandlers und die Compensation-Aktivitäten (vgl. Abschnitt 5.6).

2.4.2 Places

Im Folgenden werden alle Plätze, die Daten-Tokens (vgl. Abschnitt 2.3) enthalten können, erläutert, da auf diese von mehreren BPEL-Aktivitäten zugegriffen werden kann und der Erklärungsaufwand soll dadurch minimiert werden.

• Variables: dieser Platz speichert BPEL-Variablen, die in einem Scope oder Process deklariert sind. Die Struktur der Tupel in diesem Platz ist folgend aufgebaut:

(variableName, variableType, variableValue).

• Correlations: in dem Platz Correlations sind alle initialisierten CorrelationSets, die in einem Scope oder Process deklariert sind. Die Tupel in diesem Platz haben folgenden Aufbau: (correlationSetName, (propertyName, propertyValue)*).

• PartnerLinks: der Platz PartnerLinks speichert alle in einem Scope oder Process deklarierten PartnerLinks. Die Tupel haben folgenden Aufbau: (partnerLinkName, partnerLinkValue).

• Messages: dieser Platz speichert alle Nachrichten, die von dem BPEL-Prozess empfangen wurden. Die Tupel haben folgenden Aufbau: (partnerLinkName, Operation, Data).

• failed: über diesen Platz werden Fehler an den FaultHandeler (vgl. Abschnitt 5.2) signalisiert. Die Tupel haben den folgenden Aufbau: (faultName, faultType, faultData).

• P1: dieser Platz dient dem Entdecken der BPEL-Standardfehler bpel:conflictingReceive und bpel:ambigousReceive. Die Tupel haben folgenden Aufbau: (partnerLinkName, Operation, correlationSetName, State). Dieser Platz muss, wie im Abschnitt 5.1 beschrieben, initialisiert werden.

• P2: dieser Platz dient dem Entdecken der BPEL-Standardfehler bpel:missingRequest, bpel:missingReply und bpel:conflictingRequest. Die Tupel haben folgenden Aufbau:

(partnerLinkName, Operation, messageExchangeName, State). Dieser Platz muss, wie im Abschnitt 5.1 beschrieben, initialisiert werden.

• Clock: durch diesen Platz wird eine Uhr modelliert.

• Links: dieser Platz speichert alle Links einer Target-Aktivität (vgl. Abschnitt 4.7.2).

Die Tupel haben den folgenden Aufbau: (linkName, linkStatus).

• State: dieser Platz speichert den Zustand eines Scopes. Der Default-Zustand ist not_running. Alle möglichen Werte, die in diesem Platz gespeichert werden können, sind im Abschnitt 5.1 beschrieben.

• to_MW: durch diesen Platz wird die Middleware-Komponente aufgerufen, die das Terminieren der entsprechenden Aktivitäten vornimmt. Die Werte, die gespeichert werden können, sind im Abschnitt 5.1 erläutert.

• from_MW: durch diesen Platz wird eine Antwort von der Middleware-Komponente empfangen, dass das Terminieren der entsprechenden Aktivitäten vorgenommen wurde. Die Werte, die gespeichert werden können, sind im Abschnitt 5.1 erläutert.

• CH: in diesem Platz werden die IDs von fehlerfrei ausgeführten Scope-Instanzen gespeichert (vgl. Abschnitt 5.1), die dann von einer Compensation-Aktivität (vgl.

Abschnitt 5.6) in DCO (vgl. Abschnitt 5.5) aufgerufen werden.

• Process-Metadata: dieser Platz enthält die XML-Darstellung der BPEL- Prozessbeschreibung. Der wird von allen Aktivitäten verwendet und ist nicht in den einzelnen EWFNs eingezeichnet, um die Übersicht noch beizubehalten.

2.4.3 Grafische Darstellung

Ähnlich wie Petri-Netze haben EWFN eine grafische Darstellung. In Abbildung 5 sind alle Elemente mit ihrer Bedeutung dargestellt, die bei der Darstellung der EWFN in den nachfolgenden Kapiteln vorhanden sind. Ein Pattern-Gitter grenzt ein EWFN von anderen EWFNs ab. Ein Aggregation-Platz stellt dabei die Aggregation mehrerer Plätze dar. So sind z.B. Varaibles, Correlations, PartnerLinks, P1 und P2 bei allen Grundaktivitäten und strukturierten Aktivitäten solche Aggregation-Plätze. Hinter ihnen stehen die gleichnamigen Plätze aus allen umschließenden Scopes. Ein anderes Beispiel ist der Platz, der zum Terminieren von Kinder-Scopes benutzt wird (z.B. terminate_CS-Platz im Scope-EWFN oder terminate_FH-Platz im FaultHandler-EWFN). Hinter ihm befinden sich alle terminate- Plätzen von Kinder-Scopes.

Abbildung 5: EWFN-Elemente

3 Übersetzung der Grundaktivitäten

Alle Grundaktivitäten zeichnen sich durch ihre generische Schnittstelle aus. Diese besteht aus den Plätzen start und ended. Dadurch werden sie beliebig in strukturierten Aktivitäten (vgl.

Abschnitt 4) zusammengesetzt. Gemeinsam für alle Grundaktivitäten ist, dass ein DP- oder FAIL-Token auf dem start-Platz direkt auf ihren ended-Platz weitergegeben wird.

3.1 receive

Ein BPEL-Prozess bietet seine WebService-Operationen externen Partnern durch die receive- Aktivität an. Sie erlaubt dem BPEL-Prozess auf eine passende Nachricht zu warten und diese in einer Variablen abzulegen. Die receive-Aktivität spezifiziert über welchen PartnerLink die Nachricht empfangen wird, sowie welche Operation und optional PortType von dem Partner aufzurufen ist. Die receive-Aktivität blockiert solange die Ausführung von nachfolgenden Aktivitäten, bis eine passende Nachricht empfangen wird.

Die Aktivität spielt eine entscheidende Rolle im Lebenszyklus eines BPEL-Prozesses. Eine Möglichkeit eine neue Prozessinstanz zu erzeugen, ist eine receive-Aktivität mit dem Attribut createInstance=“yes“ zu versehen. [OAS07a] definiert eine startActivity als eine receive- oder pick-Aktivität, deren Attribut createInstance auf den Wert „yes“ gesetzt ist. Es ist erlaubt mehr als eine startActivity in einem BPEL-Prozess zu haben. Weiterhin definiert [OAS07a]

eine initialStartActivity als eine startActivity, die eine neue Prozessinstanz erzeugt. Die initialStartActivity einer bestimmten Prozessinstanz muss zu Ende ausgeführt werden, bevor andere startActivities aktiv werden. Das führt dazu, dass nur eine Nachricht, die in startActivities empfangen wird, die aktuelle Prozessinstanz erzeugt, wenn die Reihenfolge in der die einzelnen Nachrichten ankommen, nicht vorhersehbar ist. Zu diesem Zweck müssen mehrere startActivities mit correlationSets (vgl. Abschnitt 2.1) mindestens ein gemeinsames correlationSet besitzen und das Attribut initiate aller gemeinsamer correlationSets muss auf den Wert „join“ gesetzt werden. Konforme Implementierungen müssen sicherstellen, dass nur eine der eingehenden Nachrichten, die aktuelle Prozessinstanz erzeugt (normalerweise ist das die erste empfangene Nachricht, dennoch ist es implementierungsabhängig). Später ankommende Nachrichten werden an die receive-Aktivitäten in der bereits erzeugten Prozessinstanz weitergeleitet.

Das optionale Attribut messageExchange wird benutzt, um eine receive-Aktivität mit einer reply-Aktivität zu assoziieren.

Zur Verdeutlichung des Vorgangs der Evaluierung des Kontrollflusses und der Ausführung der receive-Aktivität durch das receive-EWFN sollen die einzelnen Schritte, die dabei durchlaufen werden, an dieser Stelle anhand eines Beispiels einer receive-Aktivität exemplarisch vorgestellt werden. Die Definition dieser receive-Aktivität ist in Listing 1 dargestellt.

<receive partnerLink=“Seller“ operation=“PurchaseResponse“ variable=”POResponse”

messageExchange=”ME”>

<correlations>

<correlation set=”PurchaseOrder” initiate=”no” />

<correlation set=”Invoice” initiate=”yes” />

</correlations>

</receive>

Listing 1: Definition einer receive-Aktivität

Abbildung 6 zeigt den Aufbau des receive-EWFNs. Zuerst betrachtet man den Fall, dass die receive-Aktivität keine startActivity ist, d.h. das Attribut createInstance=“no“ ist. Wie sich das receive-EWFN verändert, wenn createInstance=“yes“ ist, d.h durch die receive-Aktivität eine neue Prozessinstanz erzeugt wird, wird im Anschluss erläutert.

Abbildung 6: receive-EWFN

Die Idee bei der Übersetzung der receive-Aktivität ist folgend: wenn der Kontrollfluss bei der receive-Aktivität angekommen ist, dann wird anhand der Plätze P1 und P2 überprüft, ob ein Konflikt mit einem parallel stattfindenden receive besteht. Bei einem Konflikt wird der Kontrollfluss an den FaultHandler weitergereicht und der receive ist damit beendet.

Ansonsten wird mit dem Empfang einer passenden Nachricht fortgeführt. Die einzelnen Nachrichten werden dabei, wie im Abschnitt 2.4 beschrieben, als Tupel in dem Platz

Messages modelliert. Eine Nachricht passt auf einem receive, wenn das Correlation Consistency Constaint (vgl. Abschnitt 2.1) nicht verletzt ist. Dazu benötigt man den Platz Correlations. Bevor der Inhalt der Nachricht in einer Variablen (repräsentiert als Tupel in dem Platz Variables) gespeichert wird und damit der Kontrollfluss an den Platz ended weitergereicht wird, werden alle CorrelationSets initiiert. Dabei können weitere Fehler signalisiert werden.

Im Folgenden wird die Evaluierung des Kontrollflusses durch die Transition T1 beschrieben.

Wenn die receive-Aktivität für eine Prozessinstanz aktiviert wird, dann liegt ein CF-Token auf dem start-Platz des receive-EWFN. Im nächsten Schritt wird in(te₂) auf dem Platz P1 ausgeführt. te₂ wird definiert als te₂=(„Seller“, “PurchaseResponse“, „PurchaseOrder“, state:String). Wenn state=“open“ ist, dann bedeutet das, dass kein parallel stattfindender receive für das Tripel (Seller, PurchaseResponse, PurchaseOrder) in der aktuellen Prozessin- stanz aktiv ist. Danach wird out(tu₂) auf dem Platz P1 mit tu₂=(„Seller“,

“PurchaseResponse“, „PurchaseOrder“, „closed“) ausgeführt. Wenn state=“closed“ ist, dann wird der BPEL-Standardfehler bpel:conflictingReceive in den Platz failed geschrieben.

Analog dazu verläuft das Entdecken von einem parallel verlaufenden receive für das Tripel (Seller, PurchaseResponse, ME), d.h. es wird in(te₃) mit te₃= („Seller“,

„PurchaseResponse“, „ME“, state:String) auf dem Platz P2 ausgeführt. Wenn state=“open“

ist, dann wird out(tu₃) mit tu₃=(„Seller“, “PurchaseResponse“, „ME“, „closed“) ausgeführt, ansonsten wird der BPEL-Standardfehler bpel:conflictingRequest in den Platz failed geschrieben. In beiden Fällen wird der receive damit beendet.

Als nächstes muss T1 auf eine passende Nachricht warten. Passend bedeutet in diesem Zu- sammenhang, dass der Correlation Consistency Constaint eingehalten wird. Die Variable, in der die Nachricht abgelegt werden soll, muss von einem messageType sein, dessen Namen dem inputMessage der entsprechenden WSDL-Operation äquivalent ist [W3C01]. Da WSDL- Messages aus mehreren logischen Parts aufgebaut werden können und die einzelnen Parts mit einem Typ aus einem beliebigen Typsystem, z.B. XSD [W3C04a], assoziiert werden, wird auf eine genaue Definition von te₄ verzichtet. Durch te₄ wird eine Nachricht aus dem Platz Messages gelesen, d.h. es wird read(te₄) ausgeführt. Informal beschrieben liefert te₄ eine Nachricht zurück, die auf dem PartnerLink „Seller“ bei dem Aufruf der Operation

„PurchaseResponse“ empfangen wurde. Der Datentyp dieser Nachricht muss dem Datentyp der Variablen „POResponse“ entsprechen. Weiterhin muss gelten, dass die Werte der Properties für den CorrelationSet „PurchaseOrder“ mit den Werten der Properties für einen bereits initiierten CorrelationSet „PurchaseOrder“ für die Prozessinstanz in der der receive aktiv ist übereinstimmen müssen. Ist der CorrelationSet „PurchaseOrder“ in der Prozessinstanz nicht initiiert oder ist der Correlation Consistency Constraint nicht erfüllt, dann blockiert die Operation read(te₄) solange bis eine passende Nachricht empfangen wird.

Element aus der Menge A\B, die folgend definiert sind: A ist die Menge aller initiierten CorrelationSets für die Prozessinstanz, in der der receive aktiv ist. B ist die Menge, die als einziges Element den CorrelationSet „PurchaseOrder“ enthält. Informal beschrieben, werden dadurch eine zweite aktive receive-Aktivität aufgefunden (signalisiert durch „closed“), die auf den PartnerLink „Seller“ und der Operation „PurchaseResponse“ auf eine Nachricht warten. Als nächstes schreibt T1 das Tupel, das als Ergebnis der Operation in(te₅) erhalten wurde, in den Platz P1 zurück, wobei das letzte Element auf dem Wert von id gesetzt wird.

Da jedoch mehr als zwei CorrelationSets in einem Scope oder Process (vgl. Abschnitt 5.1) deklariert sein können, muss die Operation in(te₅) nicht nur ein einziges passendes Tupel zurückliefern, sondern alle Tupel, die den gleichen PartnerLink und Operation, wie die receive-Aktivität selbst, aber unterschiedliche CorrelationSets spezifizieren. Dazu benötigt man eine Erweiterung der Linda-Primitiven (vgl. Abschnitt 2.2) um eine neue Operation, die ähnlich einer read- bzw. take-Operation ist, allerdings alle passenden Tupel zurückliefert. In [M05] ist eine Erweiterung der einfachen Linda-Primitiven, die dieser Anforderung nachkommen, vorgeschlagen.

Als nächstes wird read(te₆) auf dem Platz P1 ausgeführt, wobei te₆=(„Seller“,

„PurchaseResponse“, „PurchaseOrder“, „closed“, id1:Integer). Nun werden die Werte von id1 und id verglichen und wenn sie gleich sind, dann wird der BPEL-Standardfehler bpel:ambigousReceive in den Platz failed geschrieben. Ansonsten wird der CorrelationSet

„Invoice“ initiiert, die Nachricht wird in die Variable „POResponse“ (repräsentiert als ein Tupel in dem Platz Variables) gespeichert und ein CF-Token wird auf den Platz ended produziert. Die Elemente derjenigen Tupel, die man für das Signalisieren eines Fehlers benutzt hat, werden auf „open“ zurückgesetzt. Wenn der CorrelationSet „Invoice“ bereits initiiert worden ist, dann wird den BPEL-Standardfehler bpel:correlationViolation in den Platz failed geschrieben. In beiden Fällen ist der receive damit beendet.

Im Folgenden betrachtet man, wie sich das Aussehen des receive-EWFN verändert, wenn eine oder mehrere receive-Aktivitäten mit dem Attribut createInstance=“yes“ vesehen sind. Das bedeutet im Einzelnen, welche zusätzlichen Plätze werden benötigt und welches Verhalten durch die Transition T1 gewährleistet werden muss, um das Erhalten der BPEL-Semantik zu garantieren.

Listing 2 zeigt ein Beispiel für eine Definition einer flow-Aktivität (vgl. Abschnitt 4.6), die zwei receive-Aktivitäten enthält. Es handelt sich dabei um startActivities mit dem gemeinsamen CorrelationSet „OrderNo“.

<correlationSets xmlns:cor=http://example.com/supplyCorrelation“>

<correlationSet name=“OrderNo“ properties=“cor:Order“ />

</correlationSets>

<flow>

<receive name=“GetLoginData“ partnerLink=“Customer“ operation=”enterLoginData” createInstance=”yes”>

<correlations>

<correlation set=”OrderNo“ initiate=“join“/>

<correlations>

</receive>

<receive name= “GetProductData“ partnerLink=“Customer“ operation=”enterProductData”

createInstance=”yes”>

<correlations>

<correlation set=”OrderNo“ initiate=“join“/>

<correlations>

</receive>

</flow>

Listing 2: Definition einer flow-Aktivität mit zwei receive-Aktivitäten

Wie am Anfang dieses Abschnittes bereits erläutert wurde, muss die initialStartActivity zu Ende ausgeführt werden, bevor die andere startActivity aktiv wird. In dem Beispiel oben be- deutet das, dass entweder die GetLoginData Aktivität oder die GetProductData Aktivität für zwei eingehende Nachrichten, die die gleichen Werte für das Property „Order“ enthalten, eine neue Prozessinstanz erzeugen wird.

Auf dem ersten Anblick könnte man meinen, dass man ähnlich wie bei dem Signalisieren von bpel:conflictingReceive bzw. bpel:conflictingRequest vorgehen kann, d.h. man hat einen zusätzlichen Platz, der Tupel der Form (correlationSet, property, value, state) speichert. Dann könnte jede receive-Aktivität in diesem Platz nachschauen, ob sich da ein Tupel befindet, der die zu erzeugende Prozessinstanz repräsentiert und dessen state=“open“ ist, danach state=“closed“ setzen und die Prozessinstanz in dem Platz Correlations erzeugen. Dieser Ansatz wird nicht funktionieren, weil dieser Platz, auf den man im Folgenden mit dem Namen ProsessInstance referenziert, nicht vorinitialisiert werden kann. Bei der Prozessinitialisierung kann man also nicht Tupel in diesem Platz ablegen, d.h. er ist leer. Damit es aber möglich ist, dass zwei receive-Aktivitäten synchron in dem Platz Tupel schreiben können ohne sich dabei in die Quere zu kommen, benötigt man einen zusätzlichen Platz, z.B. mit dem Namen PID, der eine Art Synchronisation-Token enthält. Bevor jetzt ein receive ein Tupel in dem Platz ProcessInstance schreibt, benötigt er das Token aus dem Platz PID und erst dann ist es sichergestellt, dass nur eine von mehreren für die Erzeugung der gleichen Prozessinstanz konkurrierende receive-Aktivitäten die Prozessinstanz tatsächlich erzeugen wird. Damit die Tupel aus dem Platz ProcessInstance wieder entfernt werden können, könnte man zuerst in den Platz Correlations schauen, ob sich da bereits eine Prozessinstanz befindet und wenn ja, dann das Verhalten von einem receive mit createInstance=“no“ nachgehen.

Erwähnenswert ist weiterhin, dass das Tupel in dem Platz PID die ID der zu erzeugenden

Operation eines WSDL-PortTypes des Prozesses. Die reply-Aktivität spezifiziert den PartnerLink, PortType und Operation über die die Antwort zu verschicken ist. Optional enthält sie das Attribut Variable, das die Variable spezifiziert, die die Nachricht enthält.

Das optionale Attribut messageExchange wird benutzt nur wenn bei der Ausführung einer Prozessinstanz mehrere gleichzeitig aktive IMA-reply Paare auftreten können.

[OAS07a] beschreibt eine open-IMA als der Zustand einer WebService-Operation, die durch eine Request-Response-IMA gestartet wurde, noch nicht aber durch eine assoziierte reply- Aktivität erfolgreich beendet wurde. Weiterhin definiert [OAS07a] eine orphaned-IMA als eine open-IMA, die einen PartnerLink oder MessageExchange benutzt, die in einem Scope, der gerade beendet wird oder beendet worden ist, definiert sind. Wenn die primäre Aktivität und die EventHandlers eines Scope beendet werden, dann wird überprüft, ob orphaned-IMAs existieren. Im Zusammenhang mit der reply-Aktivität bedeutet das, dass open-IMAs duch entsprechende reply-Aktivitäten „geschlossen“ werden, um dadurch nicht zu orphaned-IMAs zu werden.

Bei der Ausführung der reply-Aktivität kann einen BPEL-Standardfehler signalisiert werden, wenn die Aktivität nicht mit einer open-IMA assoziiert werden kann. Die Assoziation basiert dabei auf der Kombination aus PartnerLink, Operation und MessageExchange.

Listing 3 zeigt ein Beispiel für die Definition einer reply-Aktivität. Anhand dieses Beispiels wird im Folgenden die Evaluierung des Kontrollflusses durch das entsprechende reply-EWFN vorgestellt.

<reply partnerLink=“Customer“ operation=“Request“ variable=”Approval” messageExchange=”ME”>

<correlations>

<correlation set=”RequestID” initiate=”no” />

<correlation set=”ApprovalNo” initiate=”join” />

<correlation set=”ResponseID” initiate=”yes” />

</correlations>

</reply>

Listing 3: Definition einer reply-Aktivität

Abbildung 7 zeigt den Aufbau des reply-EWFNs.

Abbildung 7: reply-EWFN

Die Idee bei der Übersetzung ist folgend: zuerst wartet man, dass ein CF-Token auf dem Platz start geschrieben wird. Damit ist das reply aktiviert. Im nächsten Schritt wird überprüft, ob zu der reply-Aktivität eine zuvor erhaltene receive-Aktivität existiert. Dazu benötigt man den Platz P2 in dem reply-EWFN. Danach wird der Inhalt der Variablen (repräsentiert als Tupel im Platz Variables) ausgelesen und der Correlation Initiation Constraint (vgl. Abschnitt 2.1) überprüft, weshalb auf den Platz Correlations lesend zugegriffen wird. Ein Fehler aufgrund der oben genannten Überprüfungen wird über den Platz failed an den FaultHandler weitergeleitet. Der Inhalt der Variablen wird in eine Nachricht gespeichert, d. h. ein Tupel wird in den Platz Messages gespeichert. Die CorrelationSets werden initiiert und die open- IMA für das receive wird „geschlossen“. Der Kontrollfluss geht in den Platz ended über und die reply–Aktivität ist beendet.

Im Folgenden wird die Evaluierung des Kontrollflusses durch die Transition T1 beschrieben.

Wenn die reply-Aktivität aktiviert wird, dann liegt ein CF-Token auf dem start-Platz des reply-EWFN. Danach wird read(te₂) auf dem Platz P2 ausgeführt mit te₂=(„Customer“,

Platz Variables mit te₃=(„Approval“, type:String, data:dataType) ausgeführt. Der Correlation Consistency Constraint (vgl. Abschnitt 2.1) wird überprüft, d.h. ob die Werte der Properties für den CorrelationSet „RequestID“ identisch sind mit den entsprechenden MessageParts der Variablen „data“. Falls der CorrelationSet „ApprovalNo“ für die aktuelle Prozessinstanz bereits initiiert worden ist, dann wird die gleiche Überprüfung vorgenommen.

Wenn der Correlation Consistency Constraint für eins von beiden CorrelationSets verletzt ist, dann wird der BPEL-Standardfehler bpel:correlationViolation in den Platz failed geschrieben. Als nächstes wird versucht, die CorrelationSets „ResponseID“ und

„ApprovalNo“, falls letzter nicht bereits initiiert worden ist, zu initiieren. Wenn der CorrelationSet „ResponseID“ bereits existiert, dann wird der BPEL-Standardfehler bpel:correlationViolation in den Platz failed geschrieben. Im letzten Schritt wird out(tu₃) mit tu₃=(„Customer“, „Request“, data) auf den Platz Messages ausgeführt und das reply ist damit beendet.

3.3 invoke

Die invoke-Aktivität wird verwendet um einen Web Service aufzurufen. Es wird spezifiziert über welchen PartnerLink der Partner Web Service aufzurufen ist, sowie die aufzurufende Operation des Partner-PortTypes. Die Operation kann sowohl One-Way als auch Request- Response sein, entsprechend den WSDL-Übertragungsprimitiven [W3C07a]. WS-BPEL benutzt die gleiche Syntax für die beiden Operationsarten mit einigen zusätzlichen Attributen für den Request-Response Fall. Ein One-Way Aufruf spezifiziert nur das Attribut inputVariable, während eine Request-Response-Operation zusätzlich das Attribut outputVariable festlegt.

Bei der Ausführung der invoke-Aktivität kann der BPEL-Standardfehler bpel:

uninitializedPartnerRole signalisiert werden. Bei einer Request-Response-Operation kann zusätzlich eine Fehlernachricht, sofern durch die entsprechende Operation spezifiziert, empfangen werden. Die Fehlernachricht veranlasst das Ausführen einer intern festgelegten catch- bzw. catchAll-Aktivität oder den Aufruf des zuständigen FaultHandlers.

Listing 5 zeigt ein Beispiel für die Definition einer invoke-Aktivität. Anhand dieses Beispiels wird im Folgenden die Evaluierung des Kontrollflusses durch das entsprechende reply-EWFN vorgestellt. Das Beispiel zeigt den Request-Response Fall, weil dieser sicherlich der kompliziertere ist und die One-Way Variante mit sich beinhaltet. Dem Leser wird an einer geeigneten Stelle bei der Beschreibung des Kontrollflusses mitgeteilt, wo der One-Way- invoke zu Ende ist. Listing 4 zeigt die WSDL-PortTypeDefinition des PortTypes

„PurchasingPT“, der in dem Beispiel benutzt wird. Dadurch ist es ersichtlich und nachvollziehbar, dass der invoke als Antwort eine Fehlernachricht erhalten kann, die für den Vorgang der Evaluierung des Kontrollflusses von entscheidender Bedeutung ist.

<wsdl:definitions

targetNamespace=“http://example.com/purchasing“

xmlns:smsg=“http://example.com/supplyMessages“>

xmlns:wsdl=“http://schemas.xmlsoap.org/wsdl/“>

xmlns:pos=“http://example.com/purchasing“>

…

<wsdl:portType name=“PurchasingPT“>

<wsdl:operation name=“Purchase“>

<wsdl:input message=“smsg:POMessage“/>

<wsdl:output message=”smsg:POResponse”/>

<wsdl:fault name=”tns:RejectPO” message=”smsg:PoReject”/>

</wsdl:operation>

…

</wsdl:definitions>

Listing 4: Definition einer Request-Response-Operation mit einem fault-Element

Im Listing 5 repräsentiert das Präfix SP den Namensraum “http://example.com/purchasing“.

<invoke partnerLink="Seller" portType="SP:PurchasingPT" operation="SP:Purchase" inputVariable="sendPO"

outputVariable="getResponse">

<correlations>

<correlation set="PurchaseOrder" initiate="yes" pattern="request" />

<correlation set="Invoice" initiate="yes" pattern="response" />

</correlations>

</invoke>

Listing 5: Definition einer invoke-Aktivität

Abbildung 8 zeigt die Plätze und Transitionen aus denen sich das invoke-EWFN zusammensetzt.

Abbildung 8: invoke-EWFN

Bevor man mit der genauen Beschreibung der Transition T1 beginnt, möchte man die Idee bei der Übersetzung der invoke-Aktivität erläutern. Ein invoke ist sehr ähnlich von der Funktionsweise einem reply gefolgt von einem receive. Die zu versendende Nachricht wird aus einer Variablen gelesen und als eine Nachricht verschickt, anschließend wird auf eine Nachricht gewartet und diese wird in eine Variable gespeichert. Im Unterschied zu einem reply benötigt man bei einem invoke keine Nachricht, die zuvor durch eine IMA [OAS07a]

empfangen wurde. Für die Übersetzung bedeutet das, dass keine Überprüfung stattfindet und deswegen einen Zugriff auf den Platz P2 nicht benötigt wird. Bei einem receive wurde das Signalisieren des BPEL-Standardfehlers bpel:conflictingReceive durch den Platz P1 modelliert. Da dieser Fehler bei einem invoke nicht auftreten kann, wird ein Zugriff auf den Platz P1 in dem invoke-EWFN ebenfalls nicht benötigt. Der Correlation Initiation Constraint bzw. Correlation Consistency Constraint (vgl. Abschnitt 2.1) werden getrennt für die beide Nachrichten (input und output) überprüft.

Da bei der Übersetzung der reply- und der receive-Aktivität bereits Vorarbeit durch die genaue Beschreibung der Transitionen für diese zwei Aktivitäten, geleistet wurde, verzichtet man an dieser Stelle von der gesamten Spezifikation der Transition T1. Stattdessen werden nur die Stellen bei der Kontrollflussevaluierung berücksichtigt, die eigen für die invoke- Aktivität sind und deswegen bereits nicht besprochen wurden.

Im Folgenden gilt die Annahme, dass der PartnerLink „Seller“ mit dem initializePartnerRole=“yes“ Attribut definiert wurde.

Nachdem ein CF-Token aus dem start-Platz gelesen wurde, überprüft die invoke-Aktivität ob der PartnerLink „Seller“ initialisiert wurde (vgl Abschnitt 5.1). Dazu wird der Platz PartnerLinks benötigt. Es wird also read(te₁) auf dem Platz PartnerLinks mit te₁=(„Seller“

value:String) ausgeführt. Wenn der PartnerLink nicht initialisiert worden ist, dann wird der BPEL-Standardfehler bpel:unitializedPartnerRole in den failed Platz geschrieben und der invoke ist damit beendet. Ansonsten wird wie im Abschnitt 3.2 vorgegangen (d.h. die gleiche Kontrollflussevaluierung wie bei einem reply). An dieser Stelle wäre ein One-Way-invoke beendet, d.h. ein CF-Token wird in den Platz ended geschrieben. Da man das kompliziertere Szenario mittels eines Request-Response-invoke beschreiben möchte wird die Kontrollflussevaluierung für die invoke-Aktivität weiter mit dem Warten auf eine passende Nachricht auf dem Platz Messages weiter. Das Warten auf eine passende Nachricht bedeutet die Operation in(te₂) mit te₂=(„Seller“, „Purchase“, data:dataType) auf dem Platz Messages auszuführen. Die Variable „data“ enthält die Nachricht. Anschließend überprüft T1 den Datentyp der gelesenen Nachricht. Falls data eine Nachricht vom Datentyp smsg:POResponse enthält, dann wird der Kontrollfluss durch ein CF-Token an den Platz ended weitergegeben. Die Nachricht wird ähnlich wie bei einem receive in den Platz Variables geschrieben, d.h. es wird out(tu₁) mit tu₁=(„getResponse“, „smsg:POResponse“, data) ausgeführt. Der invoke ist damit beendet. Wenn die Variable „data“ vom Datentyp smsg:PoReject ist, dann wird out(tu₂) mit tu₂=(“SP:RejectPO”, „smsg:PoReject“, data) auf den Platz failed ausgeführt und der Kontrollfluss wird dadurch an den FaultHandler weitergegeben.

Zu erwähnen ist noch die Tatsache, dass es in WSDL [W3C01] möglich ist, eine Operation zu definieren, die mehrere Fehler mit dem gleichen Datentyp deklariert. Einige WSDL-Bindings liefern keine Auskunft darüber, welcher von den Fehlern gemeint ist. In diesem Fall spezifiziert [OAS07a] folgendes Vorgehen: es wird derjenige Fehler signalisiert, der zuerst in der entsprechenden Operation vorkommt.

3.4 throw

Die throw-Aktivität erlaubt einem BPEL-Prozess einen internen Fehler explizit zu signalisieren. Die throw-Aktivität ist eine Möglichkeit den Kontrollfluss an den zuständigen FaultHandler zu übergeben. Die Aktivität spezifiziert den Namen des Fehlers durch das Attribut faultName und eine Variable, in der Informationen zu dem Fehler enthalten sind.

Listing 6 zeigt ein Beispiel für die Definition einer throw-Aktivität.

<throw xmlns:FLT=”http://example.com/faults“ faultName="FLT:LoginFailure"faultVariable=”LoginFailure”/>

Listing 6: Definition einer throw-Aktivität

Abbildung 9 zeigt den Aufbau des throw-EWFNs.

Abbildung 9: throw-EWFN

Im Folgenden werden die einzelnen Schritte bei der Ausführung der throw-Aktivität aus Listing 6 durch die Transition T1 beschrieben.

Wenn der Kontrollfluss bei dem throw angekommen ist, dann liegt ein CF-Token auf dem start-Platz. Danach wird out(tu₁) mit tu₁=(„FLT:LoginFailure”, „type“, „LoginFailure“) auf dem Platz failed ausgeführt. Damit wird der Kontrollfluss an den FaultHandler weitergereicht und die throw-Aktivität damit beendet. Zum Schluss wird ein CF-Token auf dem ended-Platz des throw-EWFNs geschrieben.

3.5 wait

Die wait-Aktivität führt zu einer Pause bei der Ausführung einer Prozessinstanz. Diese Pause kann relativ, d.h. für einen vorgegebenen Zeitintervall, oder absolut, d.h. bis einen Zeitpunkt erreicht wird. Die wait-Aktivität ist in gewisser Hinsicht ähnlich zu einer pick-Aktivität (vgl.

Abschnitt 4.5), allerdings fehlt im Unterschied zu einem pick der nachrichtenorientierte Aspekt. Das Stoppen des Kontrollflusses für ein Zeitintervall wird durch eine Duration Expression, spezifiziert in einem for-Element, definiert. Das Erreichen eines absoluten Zeitpunktes wird durch eine Deadline Expression, spezifiziert in einem until-Element, definiert. Wenn das Zeitintervall in dem for-Element negativ bzw. gleich null ist oder wenn der Zeitpunkt in dem until-Element in der Vergangenheit liegt, dann wird die Aktivität sofort beendet. Ein typisches Szenario für die wait-Aktivität ist wenn eine Aktivität zu einem vorgegebenen Zeitpunkt ausgeführt werden muss.

Listing 7 zeigt ein Beispiel für die Definition einer wait-Aktivität.

<wait>

<until>'2002-12-24T18:00+01:00'</until>

</wait>

Listing 7: Definition einer wait-Aktivität

Die Übersetzung der wait-Aktivität wird in Abbildung 10 gezeigt.

Abbildung 10: wait-EWFN

Zunächst werden die einzelnen Schritte, die bei der Evaluierung des Kontrollflusses durch die Transition T1 aus Abbildung 10 durchlaufen werden anhand bei Beispiels aus Listing 7, beschrieben.

Wenn der Kontrollfluss bei der wait-Aktivität angekommen ist, dann wird die Duration Expression ausgewertet. Wenn die Auswertung einen gültigen Wert zurückliefert (z.B. vom Typ xsd:duration) dann wird read(te₁) mit te₁=(timestamp:timestamp) auf den Platz Clock ausgeführt. Ansonsten wird einen BPEL-Standardfehler, der bei der Auswertung einer

Im Folgenden wird beschrieben, wie der Kontrollfluss im Fall eines for-Elements durch die Transition T1 evaluiert wird.

Als erstes wird ein CF-Token auf dem start-Platz empfangen. Danach wird die Deadline Expression ausgewertet. Wenn die Auswertung einen gültigen Wert zurückliefert (z.B. vom Typ xsd:date oder xsd:dateTime) dann überprüft man, ob das Zeitintervall negativ oder gleich null ist. Wenn das der Fall ist, dann wird die wait-Aktivität beendet und ein CF-Token auf den Platz ended produziert. Wenn das Zeitintervall positiv ist dann wird read(te₁) mit te₁=(timestamp1:timestamp) auf den Platz Clock ausgeführt. Die Variable timestamp1 enthält nach diesem Schritt die aktuelle Zeit. Nun wird die aktuelle Zeit zu dem spezifizierten Zeitintervall hinzuaddiert und den Wert z.B. in der Variablen timestamp2 gespeichert. Als letztes führt man, ähnlich wie bei der until-Variante, read(te₂) mit te₂=(timestamp2). Damit ist der wait beendet und ein CF-Token liegt auf dem ended Platz.

3.6 empty

Die empty-Aktivität stellt das „no op“ in einem BPEL-Prozess dar. Die Aktivität wird z. B.

verwendet, um einen Fehler durch einen catch-Konstrukt (vgl. Abschnitt 5.2) abzufangen und ihn zu unterdrücken. Ein anderes Anwendungsszenario ist wenn zwei Aktivitäten in einer flow-Aktivität (vgl. Abschnitt 4.6) synchronisiert werden müssen.

Listing 8 zeigt ein Beispiel für die Definition einer empty-Aktivität.

<empty/>

Listing 8: Definition einer empty-Aktivität

Der empty-EWFN ist in Abbildung 11 dargestellt.

Abbildung 11: empty-EWFN

Nachdem der Kontrollfluss bei der empty-Aktivität angekommen ist, führt die Transition T1 aus Abbildung 11 eine einzige Operation: sie schreibt ein CF-Token auf dem Platz ended.

Damit ist die Aktivität beendet.

4 Übersetzung der strukturierten Aktivitäten

4.1 sequence

Die sequence-Aktivität enthält eine oder mehrere innere Aktivitäten, die sequentiell ausgeführt werden. Die Reihenfolge der Ausführung wird dabei durch die Reihenfolge des Vorkommens der inneren Aktivitäten in der sequence-Aktivität bestimmt. Die Aktivität ist beendet, nachdem die letzte eingebettete Aktivität beendet worden ist.

Listing 9 zeigt ein Beispiel für die Definition einer sequence-Aktivität. Es wird eine sequence-Aktivität mit drei inneren Aktivitäten definiert. Das Beispiel soll als Hilfe dienen, die Struktur des sequence-EWFNs aus Abbildung 12 zu verdeutlichen, sowie die Evaluierung des Kontrollflusses zu erläutern.

<sequence>

<flow>…</flow>

<scope>…</scope>

<pick>…</pick>

</sequence>

Listing 9: Beispiel für eine sequence-Aktivität

In Abbildung 12 ist das sequence-EWFN dargestellt.

Die Idee bei der Übersetzung besteht darin, dass man die einzelnen inneren Aktivitäten so zusammenschaltet, dass ein CF-Token auf dem ended-Platz einer Aktivität an den start-Platz der nächsten Aktivität weitergereicht wird. Wichtig ist dabei noch die Tatsache zu berücksichtigen, dass ein DP- oder FAIL-Token auf dem start-Platz des sequence-EWFNs produziert werden kann, wenn die Aktivität in einem Konstrukt sich befindet, der nicht ausgeführt wird, wie z. B. in einem Zweig einer if- oder pick-Aktivität oder wenn in dem umgebenden Scope einen Fehler signalisiert wird.

Die Schnittstelle des sequence-EWFNs besteht aus den Plätzen start und ended. Die innere Struktur enthält eine beliebige Anzahl von Aktivitäten, die durch ihre EWFNs repräsentiert sind. Die Transitionen T1 bis T4 sind für das Weiterreichen eines CF-, DP- oder FAIL-Tokens von einer Aktivität zur nächsten verantwortlich.

Im Folgenden wird der Vorgang der Evaluierung des Kontrollflusses durch das sequence- EWFN erläutert. Das sequence-EWFN wird durch ein Token auf dem start-Platz aktiviert.

Im ersten Szenario wird die Annahme getroffen, dass der Kontrollfluss bei der sequence- Aktivität angekommen ist und diese ausgeführt wird. Zu Beginn dieses Szenario befindet sich also einen CF-Token auf dem start-Platz des sequence-EWFNs. Die Transition T1 schaltet und schreibt das CF-Token auf dem start-Platz von Aktivität 1. Danach wird die Aktivität abgearbeitet und ein Token liegt auf ihrem ended-Platz. Unter der Annahme, dass Aktivität 1 einen Fehler signalisiert hat, befindet sich auf ihrem ended-Platz ein FAIL-Token. Der FaultHandler des umgebenden Scope wird den Kontrollfluss beenden und damit werden die Aktivitäten 2 und 3, sowie der sequence-Aktivität nachfolgende Aktivitäten nicht ausgeführt.

[OAS07a] definiert aber, dass Aktivitäten, die sich in einem Konstrukt befinden, dessen Kontrollfluss nicht zu ihrer Ausführung führt, den Status ihrer ausgehenden Links auf false setzen müssen. Deswegen muss die Transition T2 ein FAIL-Token an die nachfolgende Aktivität weitereichen. Das Weiterreichen des CF- bzw. FAIL-Tokens durch die inneren Aktivitäten geht so weiter bis das Token auf dem ended-Platz von Aktivität 3 gelandet ist.

Danach schaltet T4 und schreibt das Token auf dem ended-Platz des sequence-EWFNs. Damit ist die sequence-Aktivität beendet.

Im zweiten Szenario werden folgende Annahmen getroffen: die sequence-Aktivität befindet sich in einem Zweig der Prozessinstanz, der nicht abgearbeitet wird (z. B. in einem Zweig einer if-Aktivität) oder ihre JoinCondition wird zu dem Wert false ausgewertet oder ein Fehler in dem umgebenden Scope wird signalisiert. Der erste und der zweite Fall dienen einer DPE (vgl. Abschnitt 2.1), der dritte dem richtigen Setzen aller den umgebenden Scope verlassenden Links, bevor dieser terminiert wird. In allen Fällen liegt also ein DP- oder FAIL-Token auf dem start-Platz des sequence-EWFNs. Daraufhin schaltet T1 und produziert das gleiche Token auf dem start-Platz von Aktivität 1. Durch dieses Token wird garantiert, dass Aktivität 1 den Status ihrer ausgehenden Links auf false setzen wird. Danach wird das Token auf den ended-Platz von Aktivität 1 landen und durch das Schalten von T2 wird das Weiterreichen an Aktivität 2 sichergestellt. Am Ende dieses Szenarios befindet sich das Token auf dem ended-Platz des sequence-EWFNs. Dadurch propagiert man ein DP- oder FAIL-Token an die nachfolgende Aktivität oder der FaultHandler des umgebenden Scope wird aktiviert, weil erst nachdem das Token die primäre Aktivität des Scopes durchlaufen hat, garantiert wird, dass alle ausgehenden Links von eingebetteten Aktivitäten auf den Status false gesetzt worden sind.