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.