• Keine Ergebnisse gefunden

4 Übersetzung der strukturierten Aktivitäten

4.4 if

Die if-Aktivität führt aufgrund einer booleschen Bedingung genau eine Aktivität aus einer Menge von Aktivitäten aus. Sie entspricht dem if-Konstrukt einer Programmiersprache. Die if-Aktivität enthält einen oder mehrere Zweige, definiert durch das if-Element, gefolgt von optional mehreren elseif-Elementen und einem else-Element. Die if- und elseif-Zweige werden in der Reihenfolge abgearbeitet, in der sie spezifiziert sind. Der erste Zweig, dessen Bedingung zu dem Wert true evaluiert, wird ausgewählt und seine Aktivität wird ausgeführt.

<if xmlns:inventory=”http://supply-chain.org/inventory“>

<condition>bpel:getVariableProperty('stockResult','inventory:level') > 100</condition>

<flow>…</flow>

<elseif>

<condition>bpel:getVariableProperty('stockResult','inventory:level') >= 0</condition>

<throw … />

</elseif>

<else>

<throw … />

</else>

</if>

Listing 12: Beispiel für eine if-Aktivität

In Abbildung 15 ist das if-EWFN dargestellt.

CF-, DP- und FAIL-Tokens sowie das Weiterreichen dieser nach außen geregelt ist.

Ähnlich wie bei der Aktivität sequence, kann eine if-Aktivität beliebig viele innere Aktivitäten enthalten. Die Schittstelle bilden die Plätze start, ended und failed. Es wird außerdem auf den Variables-Platz zugegriffen, um die booleschen Bedingungen auszuwerten.

Die Transitionen T1 und T2 sind für das Empfangen eines CF-, DP- oder FAIL-Tokens von außen, sowie das Bestimmen und Weiterreichen dieses Tokens an die entsprechende innere Aktivität verantwortlich. Zusätzlich reichen sie ein Token an ihre Umgebung weiter. Wichtig ist dabei zu erwähnen, dass die Transition T1 ebenfalls einen Fehler signalisieren kann, der bei der Auswertung der einzelnen booleschen Bedingungen auftreten kann. Diese Transition muss allerdings das Setzen der Links der inneren Source-Aktivitäten garantieren.

Im Folgenden möchte man den Kontrollfluss im if-EWFN anhand des Beispiels aus Listing 12 diskutieren. Man betrachtet dazu die einzelnen Szenarien aus Abschnitt 4.1.

Im ersten Szenario liegt ein CF-Token auf dem start-Platz des if-EWFNs. Die Transition T1 wertet die booleschen Bedingungen der Reihe ihrer Spezifikation nach und schreibt ein CF-Token auf dem start-Platz jener inneren Aktivität, deren booleschen Bedingung zuerst zu dem Wert true evaluiert wird. An alle anderen inneren Aktivitäten wird ein DP-Token propagiert.

Dadurch wird sichergestellt, dass alle Aktivitäten in den Zweigen der if-Aktivität, die nicht zur Ausführung kommen, ihre ausgehenden Links auf den Status false setzen werden. Bei der Auswertung der booleschen Bedingungen kann einen BPEL-Standardfehler signalisiert werden. Deswegen ist die Transition T1 durch eine write-Kante mit dem failed-Platz des if-EWFNs verbunden. Die Transition T2 synchronisiert nun alle Tokens, die im if-EWFN verteilt wurden und bestimmt die Art des Tokens, das auf den ended-Platz des if-EWFNs zu schreiben ist. Das Synchronisieren ist wichtig, da dadurch garantiert wird, dass alle die if-Aktivität verlassenden Links ihren Status auf den richtigen Wert gesetzt haben. Dadurch kann eine nachfolgende Aktivität, die einen Fehler signalisiert, davon ausgehen, dass alle ihr vorausgehenden Source-Aktivitäten den Status ihrer Links auf den Wert false gesetzt haben.

Bei der Bestimmung der Art des Token, das auf den ended-Platz des if-EWFNs produziert wird, werden zwei Fälle unterschieden. Um diese Fälle zu verdeutlichen, wird angenommen, dass die erste innere Aktivität im if-EWFN zur Ausführung kam, d.h. die Transition T1 hat auf ihrem start-Platz ein CF-Token produziert. Im ersten Fall wird die innere Aktivität fehlerfrei abgearbeitet, d.h. nach ihrer Ausführung liegt ein CF-Token auf ihrem ended-Platz.

Daraufhin wird T2 ebenfalls ein CF-Token auf den ended-Platz des if-EWFNs schreiben. Im zweiten Fall signalisiert die innere Aktivität einen Fehler, d.h. ein FAIL-Token liegt auf ihrem ended-Platz. Dann wird T2 ein FAIL-Token nach außen weiterpropagieren. Der Algorithmus, der durch T2 ausgeführt wird, besteht somit aus zwei Teilen. Zum einen werden die Tokens aus den ended-Plätzen aller inneren Aktivitäten gelesen und zum zweiten wird ein CF-Token auf den ended-Platz des if-EWFNs geschrieben, falls ein CF-Token in der Menge der gelesen Tokens enthalten ist, ansonsten wird ein Token nach außen propagiert, falls ein FAIL-Token in der Menge der gelesenen FAIL-Tokens enthalten ist. Zu beachten ist, dass in der Menge der ended-Plätze aller inneren Aktivitäten nur ein solcher Platz existieren kann, der ein CF- oder FAIL-Token enthalten kann (nämlich der jenige, dessen innere Aktivität ausgeführt wurde). Alle anderen ended-Plätze enthalten dann DP-Tokens. Wurde also die if-Aktivität ausgewählt, so liegt nach ihrer Ausführung ein CF- oder FAIL-Token (je nachdem, ob sie fehlerfrei oder nicht ausgeführt wurde) auf ihrem ended-Platz. Die ended-Plätze von der elseif- und der else-Aktivität enthalten dann DP-Tokens. Der Grund dafür ist, dass keine EWFN-Aktivität aus einem DP-Token ein CF- oder FAIL-Token machen kann.

Im zweiten Szenario liegt ein DP- oder FAIL-Token auf dem start-Platz des if-EWFNs. Die Transition T1 wertet nun die booleschen Bedingungen nicht aus, sondern schreibt nur auf den start-Platz jeder inneren Aktivität dieses Token. Dadurch garantiert man, dass ein von außen empfangenes DP- oder FAIL-Token an jede eingebettete Aktivität weiterpropagiert wird. Der Algorithmus, der von T2 ausgeführt wird bleibt der gleiche wie bei der Erläuterung im ersten Szenario.