Link Semantics

Jede BPEL-Aktivität kann anhand des sources-Elements einen Source-Container und anhand des targets-Elements einen Target-Container spezifizieren. Diese enthalten mindestens ein source- bzw. target-Element. Diese Elemente werden benutzt, um Synchronisationsabhängigkeiten zwischen Aktivitäten herzustellen. Dazu spezifiziert das Attribut linkName den Namen eines Links, der in einer umgebenden flow-Aktivität deklariert ist. Für die nachfolgenden Betrachtungen werden die Links einer Aktivität, die in ihren source-Elementen spezifiziert sind, als ihre ausgehenden Links bezeichnet und die Aktivität als die Source-Aktivität dieser Links, während die Links, die in ihren target-Elementen sich befinden, als ihre eingehenden Links und die Aktivität als die Target-Aktivität dieser Links.

Wenn die Aktivität X einen eingehenden Link besitzt, der die Aktivität Y als ausgehenden Link spezifiziert, dann sagt man, dass die Aktivität X eine Synchronisationsabhängigkeit von der Aktivität Y hat. Jeder Link ist mit einem Status assoziiert, der drei Werte repräsentiert:

true, false oder unset.

Für jeden Target-Container kann anhand des joinCondition-Elements eine boolesche Bedingung spezifiziert werden. Wenn diese Bedingung nicht explizit spezifiziert ist, dann wird diese als die logische OR-Verknüpfung des Status ihrer eingehenden Links gebildet.

Wenn eine Aktivität in einer BPEL-Prozessinstanz aktiviert wird, dann darf sie solange nicht starten, bis der Status aller ihrer eingehenden Links bekannt ist und die JoinCondition evaluiert wird. Die Semantik der Evaluierung des Status eines Links wird in den folgenden Schritten beschrieben.

• Nachdem die Aktivität A fehlerfrei ausgeführt worden ist, wird der Status jedes ihrer ausgehenden Links anhand der TransitionCondition bestimmt. Der Status wird den Wert true oder false haben.

• Für jede Aktivität B, die eine Synchronisationsabhängigkeit von A besitzt, wird überprüft:

o ob B ausgeführt werden kann.

o der Status aller eingehenden Links von B bekannt ist.

Wenn die letzten zwei Bedingungen wahr sind, dann wird die JoinCondition der Aktivität B evaluiert. Ergibt die Auswertung den Wert true, dann wird B gestartet. Ansonsten wird B nicht ausgeführt und der BPEL-Standardfehler bpel:joinFailure signalisiert, es sei denn der Wert von suppressJoinFailure gleich yes ist. In diesem Fall wird DPE (vgl. Abschnitt 5.5) angestoßen.

Eine Aktivität muss fehlerfrei ausgeführt werden, bevor ihre TransitionConditions evaluiert werden. Im Fall einer Scope-Aktivität ist eine fehlerfreie Ausführung nicht erforderlich, solange ein FaultHandler für die Scope-Aktivität vorhanden ist und dieser fehlerfrei abgearbeitet wird. Ein Fehler bei der Evaluierung einer TransitionCondition wird an den zuständigen FaultHandler signalisiert. Der Status aller ausgehenden Links, die eine Target-Aktivität hat, die außerhalb des umgebenden Scope liegen, werden auf den Wert false gesetzt.

Wenn die Source-Aktivität sich in dem umgebenden Scope befindet, dann ist der Status irrelevant, weil der FaultHandler den Kontrollfluss in diesem Scope beenden wird. Ist die Source-Aktivität ein Scope, dann wird ein Fehler, bei der Evaluierung der TransitionCondition an den FaultHandler des Vater-Scopes propagiert.

4.7.1 Source-Aktivität

In Listing 15 ist ein Beispiel für die Definition einer Source-Aktivität gezeigt.

<flow>

In Abbildung 18 ist das Source-EWFN dargestellt.

Abbildung 18: Source-EWFN

Das Source-EWFN besteht aus dem EWFN der Source-Aktivität und den Transitionen T1 und T2. Die Schnittstelle zu der umgebenden bzw. benachbarten Aktivität bilden die Plätze start und ended. Die Schnittstelle zu dem FaultHandler bildet der failed-Platz. Der Links-Platz ist ein Aggregation-Platz. Hinter ihm stehen die Links-Plätze aller Target-Aktivitäten, die eine Synchronisationsabhängigkeit von dieser Source-Aktivität haben.

Im Folgenden wird der Kontrollfluss durch das Source-EWFN erläutert.

Nachdem ein Token auf den start-Platz des Source-EWFNs gelandet ist, schaltet die Transition T1 und schreibt dieses auf den start-Platz des Source-Aktivität-EWFNs. Nachdem deises Token durch das EWFN der Source-Aktivität durchgelaufen ist, liegt es auf ihrem ended-Platz. Die Transition T2 schaltet und man unterscheidet in Abhängigkeit von dem Typ des Tokens zwei Szenarien. Ist das Token ein CF-Token, dann wird die TransitionCondition für jeden ausgehenden Link evaluiert und der Status dieses Links an die entsprechende Target-Aktivität (über den Links-Platz) weiterpropagiert. Ein CF-Token wird auf den ended-Platz des

selbst im Falle einer fehlerhaften Ausführung evaluieren darf, es sei denn, der zuständige FaultHandler kann den Fehler nicht bearbeiten und muss ihn an den Vater-Scope weiterreichen.

4.7.2 Target-Aktivität

In Listing 16 ist ein Beispiel für die Definition einer Target-Aktivität gezeigt.

<flow>

<links>

<link name="XtoY" />

<link name="XtoZ" />

</links>

<sequence name="Y">

<receive name="C" ...>

<targets>

<target linkName="XtoY" />

</targets>

</receive>

<invoke name="D" ...>

<targets>

<target linkName="XtoZ" />

</targets>

</invoke>

</sequence>

</flow>

Listing 16: Beispiel für eine Target-Aktivität

In Abbildung 19 ist das Target-EWFN dargestellt.

Abbildung 19: Target-EWFN

Das Target-EWFN besteht aus dem EWFN der Target-Aktivität und den Transitionen T1 und T2. Die Schnittstelle zu der umgebenden bzw. benachbarten Aktivität bilden die Plätze start und ended. Die Schnittstelle zu dem FaultHandler bildet der failed-Platz. Der Links-Platz bildet die Schnittstelle zu den Source-Aktivitäten. Der P3-Platz speichert den Typ des von außen empfangenen Tokens und dient zur Bestimmung des Tokens, das nach außen weitergereicht wird.

Im Folgenden wird der Kontrollfluss durch das Target-EWFN erläutert.

Nachdem ein Token auf den start-Platz des Target-EWFNs gelandet ist und der Status aller eingehenden Links bekannt ist (anhand des linkStatus-Feldes in den Tupeln im Links-Platz), schaltet die Transition T1 und unterscheidet zwei Szenarien in Abhängigkeit von dem Typ des Tokens. Im Falle eines CF-Tokens wird anhand des Status aller eingehenden Links die JoinCondition evaluiert. Ergibt die Evaluierung den Wert false und ist das Attribute supressJoinFailure auf den Wert no gesetzt, dann wird ein FAIL-Token auf den start-Platz des Target-Aktivität-EWFNs produziert und der BPEL-Standardfehler bpel:joinFailure an den FaultHandler propagiert. Ist das Attribute supressJoinFailure auf den Wert yes gesetzt,

an die nachfolgende bzw. umgebende Aktivität weitergereicht. Ist das Token ein DP-Token, dann wird ein DP-Token nach außen propagiert, falls das Token im P3-Platz ebenfalls ein DP-Token ist, ansonsten wird ein CF-Token auf den ended-Platz des Target-EWFNs geschrieben.