pick

Die pick-Aktivität definiert eine Menge von Events. Jeder dieser Events ist mit einer BPEL-Aktivität assoziiert. Die pick-BPEL-Aktivität wartet bis einer der Events ausgelöst wird, dann führt die dazugehörige Aktivität aus und ist damit beendet. Weitere ausgelösten Events werden danach nicht mehr akzeptiert. Events können entweder durch das Eintreffen einer Nachricht oder durch das Verstreichen eines Zeitintervalls bzw. das Erreichen eines absoluten Zeitpunktes ausgelöst werden. Die nachrichtenbasierten Events werden durch ein oder mehrere onMessage-Elemente spezifiziert, die zeitbasierten durch mehrere onAlarm-Elemente.

Die pick-Aktivität besteht also aus mehreren Event-Aktivität Paaren. Sie ist beendet, nachdem ein solches Paar ausgewählt wurde und seine Aktivität beendet worden ist.

Ähnlich wie eine receive-Aktivität (vgl. Abschnitt 3.1) verhält sich ein onMessage-Event. Es wird spezifiziert über welchen PartnerLink und unter dem Aufruf welcher Operation die Nachricht zu empfangen ist. Die optionalen Attribute variable und messageExchange, sowie die Elemente correlations und fromParts besitzen die gleiche Semantik wie bei einer receive-Aktivität. Ebenso sind die Fehler, die durch einen onMessage-Event signalisiert werden können, die gleichen wie die, die bei der Ausführung einer receive-Aktivität auftreten können.

Ein onAlarm-Event spezifiziert entweder ein absoluter Zeitpunkt durch eine Deadline Expression in einem until-Element oder ein relativer Zeitpunkt durch eine Duration Expression in einem for-Element. Man sieht also die Ähnlichkeit, die zu einer wait-Aktivität besteht (vgl. Abschnitt 3.5).

Durch eine pick-Aktivität kann man, genau wie bei einer receive-Aktivität, eine neue Prozessinstanz erzeugen. Dazu spezifiziert man das Attribut createInstance und setzt dieses auf den Wert „yes“. Der Unterschied zu einem receive ist jedoch, dass während ein receive eine neue Prozessinstanz durch das Empfangen eine einzige Nachricht erzeugen kann, ist das bei einem pick durch das Eintreffen einer Nachricht aus einer Menge von Nachrichten möglich (durch die Spezifikation von mehreren onMessage-Events).

<pick>

<onMessage partnerLink="buyer" portType="orderEntry" operation="inputLineItem" variable="lineItem">

<correlations>

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

</correlations <receive …/>

</onMessage>

<onMessage partnerLink="buyer" portType="orderEntry" operation="orderComplete"

variable="completionDetail">

<receive …/>

</onMessage>

<onAlarm>

<for>'P3DT10H'</for>

<throw …/>

</onAlarm>

</pick>

Listing 13: Beispiel für eine pick-Aktivität

In Abbildung 16 ist das pick-EWFN dargestellt.

Bevor die Evaluierung des Kontrollflusses im pick-EWFN beschrieben wird, soll der Aufbau dieses EWFNs betrachtet werden.

Am Anfang dieses Abschnittes wurden die Ähnlichkeiten zwischen einem Event in einem onMessage-Zweig und einer receive-Aktivität, sowie zwischen einem Event in einem onAlarm-Zweig und einer Aktivität festgestellt. Da man eine receive- bzw. wait-Aktivität bereits in einem entsprechenden EWFN transformiert hat, liegt die Idee nahe, diese EWFNs im Aufbau des pick-EWFNs zu benutzen. Die Idee bei der Übersetzung besteht also darin, dass man jeden onMessage-Zweig durch zwei EWFNs übersetzt. Das erste EWFN entspricht dem EWFN einer receive-Aktivität, das zweite – dem EWFN einer beliebigen BPEL-Aktivität. Ähnlich sieht es mit einem onAlarm-Zweig aus. Das erste EWFN entspricht dem EWFN einer wait-Aktivität, das zweite EWFN kann für jede beliebige BPEL-Aktivität stehen. Die receive- und wait-EWFNs innerhalb des pick-EWFNs werden im Folgenden unter dem Namen „Event-EWFNs“ zusammengefasst. Die Schnittstelle bilden die Plätze start, ended und failed. Zu der inneren Struktur gehört der P3-Platz. Dieser wird für den Fall benötigt, dass von außen ein CF-Token empfangen wird. Der P3-Platz dient dann der Aktivierung der Aktivität genau eines Event-Aktivität Paares, nachdem der dazugehörige Event ausgelöst wurde. Die Transitionen T1 und T2 sind für das Empfangen eines CF-, DP- oder FAIL-Tokens, die Aktivierung aller Events (es werden dadurch noch keine inneren Aktivitäten aktiviert), sowie das Weiterreichen eines Tokens an die umgebende oder nachfolgende Aktivität verantwortlich. Die Transitionen T3 bis T5 aktivieren genau eine Aktivität aus einem Event-Aktivität Paar mit Hilfe des P3-Platzes.

Die Evaluierung des Kontrollflusses im pick-EWFN wird anhand der bereits aus Abschnitt 4.1 bekannten Szenarien erläutert.

Im ersten Szenario liegt ein CF-Token auf dem start-Platz des pick-EWFNs. Die Transition T1 schreibt dann ein CF-Token auf den start-Platz jedes Event-EWFNs. Zusätzlich wird ein CF-Token auf den Platz P3 abgelegt. Nachdem ein Event ausgelöst wurde, d.h. eine entsprechende Nachricht wurde empfangen oder ein Zeitintervall ist verstrichen, liegt ein oder FAIL-Token auf dem ended-Platz des entsprechenden Event-EWFNs. Im Falle eines CF-Token wird die zu diesem Event zugehörige Aktivität durch ein CF-CF-Token aktiviert. Alle anderen inneren Aktivitäten werden durch ein DP-Token zur DPE (vgl. Abschnitt 2.1) aufgefordert. Liegt dagegen ein FAIL-Token auf dem ended-Platz des Event-EWFNs, dann wird das FAIL-Token an alle inneren Aktivitäten weiterpropagiert. Angenommen, es wurde der erste Event aus dem Beispiel in Listing 13 ausgelöst. Falls dabei kein Fehler signalisiert wurde, liegt ein CF-Token auf dem ended-Platz des receive-EWFNs. Die Transition T3 schreibt dann ein CF-Token auf den start-Platz von Aktivität 1 und ein DP-Token auf den start-Platz von Aktivität 2 und Aktivität 3. Dadurch wird Aktivität 1 ausgeführt und alle anderen Aktivitäten als tot markiert, d.h. sie setzen nur den Status ihrer Links auf den Wert false. Das Sicherstellen, dass genau eine Aktivität ausgeführt wird, wird durch das CF-Token auf dem Platz P3 garantiert. Nur eine Transition aus der Gruppe T3 bis T5 wird dieses Token konsumieren. Alle anderen Transitionen können danach nicht mehr schalten. Wenn bei der Auslösung des ersten Events ein Fehler signalisiert wird, dann liegt ein FAIL-Token auf dem ended-Platz des receive-EWFNs. Die Transition T3 schreibt dann ein FAIL-Token auf den start-Platz von Aktivität 1 und ein DP-Token auf den start-Platz von Aktivität 2 und 3. Die Transition T2 synchronisiert die Tokens, die an die inneren Aktivitäten propagiert wurden und bestimmt die Art des Tokens, das nach außen gesendet wird. Sie hat das gleiche Verhalten, wie Transition T2 aus Abschnitt 4.4 und wird deswegen an dieser Stelle nicht nochmals erläutert.

Die Evaluierung des Kontrollflusses im zweiten Szenario ist identisch mit der Umsetzung im if-EWFN aus Abschnitt 4.4.