Send-Mediator werden in Mediationssequenzen im WSO2 ESB ausgiebig verwendet. Ohne einen Send-Mediator wird natürlich wenig passieren, weder in der IN-Sequenz (der Send-Mediator sendet die Nachricht an den von dir definierten Endpunkt) noch in der OUT-Sequenz (der Send-Mediator sendet die Nachricht an den Client zurück).
Es ist Zeit, einen Blick auf diesen Mediator zu werfen, den wir oft benutzen, aber vielleicht nicht wenig. Am Ende des Blogs werfen wir auch einen Blick auf andere Mediatoren, die mit dem Send-Mediator verwandt sind, wie Call, Respond und Drop.
Wie funktioniert der Send-Mediator?
In der einfachsten Form sendet es die Nachricht an den definierten Endpunkt. Dieser Endpunkt kann inline (hartkodiert) definiert werden, ein vordefinierter Endpunkt sein (benannt oder in einem Register) oder von einem XPATH-Ausdruck abgeleitet werden. Wenn kein Endpunkt definiert ist, versucht das Sendeprogramm, die Nachricht an den TO-Kopf zu senden.
Wenn sich der Send-Mediator in der OUT-Sequenz befindet, wird er die Nachricht einfach an den Client senden, wenn kein Endpunkt definiert ist. Durch die Definition eines Endpunktes im Send-Vermittler in der OUT-Sequenz wird die Nachricht an diesen Endpunkt gesendet.
Die Syntax des Send-Mediators ist recht einfach:
<send/>
Wenn ein Endpunkt im Send enthalten ist, sieht die Syntax wie folgt aus:
<send> (endpointref | endpoint)+ </send>
Etwas später werden wir sehen, welche Parameter möglich sind, denn obwohl die Syntax einfach zu sein scheint, lässt sie doch mehr zu, als du denkst.
Der Endpunkt im Send-Mediator kann lauten:
- Leer (siehe vorherigen Absatz für den Ablauf)
- Definiert inline (im entsendenden Vermittler hartkodiert)
- Aus der Registrierung oder einem anderen benannten Endpunkt ausgewählt
- XPath-Anweisung
Laut der Dokumentation kannst du eine Nachricht auch an mehrere Endpunkte senden.
Ein Beispiel für einen Send-Mediator mit einem inline definierten Endpunkt
<send>
<endpoint>
<address uri="http://localhost:9764/services/ADeployedService"/>
</endpoint>
</send> Als Beispiel mit sowohl einem definierten Endpunkt als auch einer benannten OUT-Sequenz
<send receive="ProvideDataSeq">
<endpoint key="PersonDataEpr"/>
</send>Wenn du mit mehreren Endpunkten arbeiten möchtest, musst du sie in einer Empfängerliste definieren. Weitere Informationen findest du in der Dokumentation in einem EIP-Beispiel (Enterpise Integration Pattern). Eine Empfängerliste würde etwa so aussehen:
<inSequence>
<log/>
<send>
<endpoint name="1469526965038">
<recipientlist>
<endpoint>
<address trace="disable"
uri="http://localhost:9764/services/echo"/>
</endpoint>
<endpoint>
<address trace="disable"
uri="http://localhost:9765/services/echo"/>
</endpoint>
</recipientlist>
</endpoint>
</send>
</inSequence>Eine weitere Möglichkeit besteht darin, den Typ der Empfangssequenz für das Senden zu definieren. Damit ist die OUT-Sequenz gemeint (wenn kein empfangender Endpunkt angegeben wird, nimmt sie den Standardendpunkt im Proxy oder API oder einen statischen (benannte Sequenz) oder sogar dynamischen Endpunkt. Im letzteren Fall sollte eine XPath-Anweisung angegeben werden.
Als letzter Parameter ist anzugeben, ob die Nachricht vor dem Senden in den Speicher eingebaut wird. Wenn es eine Logik gibt, die nach dem Senden stattfinden soll, muss dieser Parameter auf Ja gesetzt werden. Andernfalls belasse es auf Nein, was die Leistung verbessert.
Der Sende-Mediator kann über die UI des WSO2 ESB, Developer Studio oder als XML-Snippet definiert werden, das in einen Proxy oder eine API kopiert wird.
UI-Konfiguration
Wichtig ist, sich bewusst zu machen, dass der entsandte Mediator den Flow (IN oder OUT) verlassen wird. Es wird nicht funktionieren, Mediatoren nach Send zu platzieren, da sie nie erreicht werden.
Call-Mediator
Der Call-Mediator macht etwas Ähnliches wie der Send-Mediator, bleibt aber im Gegensatz zum Send-Mediator innerhalb des Flows des Proxy oder der API. Auf diese Weise ist eine Verkettung von Diensten möglich, d.h. eine Reihe aufeinanderfolgender Calls, bei denen z.B. die Ergebnisse von einem Call zu einem anderen mit Hilfe von festgelegten Eigenschaften übergeben werden.
Die Call-Mediator-Syntax ähnelt der Send-Mediator-Syntax
<call [blocking="true"]> (endpointref | endpoint)+ </call>
In diesen Fällen werden mehrere Endpunkte unterstützt, jedoch nur im nicht blockierenden Modus.
Theoretisch gibt es mehr Möglichkeiten, die Verknüpfung zu bedienen, indem man IN- und OUT-Flows einer benannten Sequenz oder sogar eine Konstruktion verwendet, bei der im OUT-Flow z.B. eines Proxy ein Switch und ein weiterer Send verwendet werden (der Switch bestimmt, ob ein weiterer Aufruf gemacht werden muss), aber das ist wirklich suboptimal. Der Call-Mediator ist die Art und Weise, wie eine Verknüpfung von Diensten innerhalb des WSO2 ESB durchgeführt werden kann.
Drop-Mediator
Ein weiterer inhaltlich unbekannter Mediator, der mit dem Send-Mediator verwandt ist, ist der Drop-Mediator, der genau das Gegenteil des Send-Mediators tut: Er legt die Nachricht ab. Wenn der Drop-Mediator in die IN-Reihenfolge gestellt wird, gibt er dem Client eine 202 Akzeptierte Antwort. Wenn der Drop-Mediator in die Out-Sequenz gesetzt wird, gibt er keine Antwort zurück, sondern lässt die Nachricht einfach fallen.
Seine Syntax ist die einfachste von allen: <drop/>
Respond-Mediator
Der Respond-Mediator sendet die Nachricht an den Client zurück und unterbricht die laufende Verarbeitung. Eine der Anwendungen besteht darin, dass der Makefault-Mediator dem Client eine Soap-Nachricht zurückgibt, dass mit der Nachricht etwas nicht in Ordnung ist (z.B. dass die Nutzlast nicht korrekt ist oder so etwas).
Auch in diesem Fall ist die Syntax einfach: <respond/>
Loopback-Mediator
Einer der am wenigsten bekannten Mediatoren ist der Loopback-Mediator. Wie du in der Abbildung unten sehen kannst, überträgt der Loopback-Mediator den Flow in die Out-Sequenz, wo die Variablen auf dem axis2-Scope beibehalten werden.
Die Syntax lautet: <loopback/>
Wann würdest du den Loopback einsetzen? Nun, im Grunde, wenn du die Aussensequenz verwenden möchtest, um die Antwort an den Client zu formatieren.
In diesem Überblick haben wir uns einige der Möglichkeiten zur Verwaltung des Flows innerhalb eines Proxys angesehen, wie z.B. das Senden an verschiedene Endpunkte, das Abrufen benannter Outsequence und so weiter. Jetzt weißt du, dass du die Möglichkeit hast, den Ablauf zu ändern, was sehr praktisch für eines deiner eigenen Projekte sein könnte.
Wenn du Fragen zu diesem Blog hast, kontaktiere uns über den Kommentarbereich dieses Blogs. Schau dir auch unsere WSO2-Tutorials, Webinare oder Whitepapers für weitere technische Informationen an. Benötigst du Unterstützung? Wir bieten WSO2-Produktsupport, WSO2-Entwicklungsunterstützung, WSO2-Betriebsunterstützung und WSO2-Trainingsprogramme.
WSO2TORIALS helfen dir, WSO2-Produkte zu ändern, zu aktualisieren oder zu verbessern und basieren auf unseren Erfahrungen mit den Produkten. WSO2TORIALS werden dich Schritt für Schritt mit minimalen Kenntnissen anleiten.
