Sie können HTTP-Anforderungen stellen und asynchron eine
Antwort empfangen, indem Sie die Knoten HTTPAsyncRequest
und HTTPAsyncResponse oder die Knoten
SOAPAsyncRequest und
SOAPAsyncResponse in Ihrem Nachrichtenfluss verwenden.
Der
SOAPAsyncRequest-Knoten unterstützt bei
Verwendung des HTTP-Transports zwei Methoden von asynchronen Anforderungen:
- Die Antwort wird über WS-Addressing an den paarigen
SOAPAsyncResponse-Knoten geleitet. Der
SOAPAsyncRequest-Knoten wartet vor der Fortsetzung des
Nachrichtenflusses auf die HTTP 202-Bestätigung. Erhält der
SOAPAsyncRequest-Knoten diese Bestätigung nicht,
blockiert er den Nachrichtenfluss. Der Back-End-Server stellt eine neue HTTP-Verbindung her, um dem
SOAPAsyncResponse-Knoten zu antworten. Dies
ist das Standardverhalten.
- Es wird eine asynchrone HTTP-Anforderung/Antwort verwendet. Wenn die
SOAPAsyncRequest-Eigenschaft Asynchrone
HTTP-Anforderung/Antwort verwenden ausgewählt ist, übergibt der
SOAPAsyncRequest-Knoten das HTTP-Socket an den paarigen
SOAPAsyncResponse-Knoten, damit der Back-End-Server über
dasselbe Socket antworten kann. Ist diese Option ausgewählt, werden WS-Addressing-Header gesendet,
die jedoch nicht vom Back-End-Server verstanden werden müssen. Die WS-Addressing-Header sind nicht
als 'mustUnderstand' markiert und der replyTo-Header ist auf 'anonymous' gesetzt. Der Knoten
verwendet deshalb asynchrone HTTP-Socketverarbeitung statt WS-Addressing, um HTTP-Anforderungen zu
stellen und eine asynchrone Antwort zu empfangen.
Der
HTTPAsyncRequest-Knoten verwendet für asynchrone
Anforderungen und Antworten immer die asynchrone HTTP-Socketverarbeitung.
Asynchrone Anforderungsknoten geben die Kontrolle an den Fluss zurück, ohne auf Antwort zu warten. Dadurch kann der Anforderungsthread schon weitere Anforderungen verarbeiten, während die Antwort noch vom zugeordneten Antwortknoten in einem anderen Thread und in
einer neuen Transaktion verarbeitet wird. Der Antwortknoten kann sich in einem separaten Nachrichtenfluss befinden,
muss sich aber auf demselben Integrationsserver wie der ihm zugeordnete Anforderungsknoten befinden.
Das Verfahren für asynchrone HTTP-Anforderung/Antwort ist nur deshalb asynchron, weil
WebSphere Message
Broker die Anforderung und die Antwort jeweils als solche
behandelt, was es dem Nachrichtenfluss ermöglicht, die nächste Nachricht abzurufen, ohne auf die
Antwort auf die asynchrone Anforderung warten zu müssen. Der Back-End-Server betrachtet die
Anforderung/Antwort-Operation als eine typische synchrone HTTP-Anforderung.
Szenarios
Asynchrone HTTP-Anforderung/Antwort-Operationen können in
folgenden Situationen verwendet werden:
- Bei der Interaktion mit einem Back-End-Server, der eine lange Latenzzeit aufweist, können
synchrone HTTP-Anforderungen zu vielen ausstehenden Anforderungen führen, für die dann eine große
Anzahl von Threads erforderlich ist, um simultane Verbindungen mit dem Back-End-Server
herzustellen. Bei einer asynchronen HTTP-Socketverarbeitung kann die Antwort dagegen von der
Anforderung entkoppelt werden.
- Die Verwendung einer asynchronen HTTP-Anforderung/Antwort-Operation im
SOAPAsyncRequest-Knoten ist eine Alternative zur
Verwendung von WS-Addressing mit einem nicht anonymen replyTo-Header.
Informationen zur
Verwendung von asynchronen HTTP-Anforderung/Antwort-Operationen in Verbindung mit dem
SOAPAsyncRequest-Knoten finden Sie im Abschnitt
Asynchrones Verhalten für den SOAPAsyncRequest-Knoten auswählen.
Einschränkungen
Bei Verwendung des
HTTPAsyncRequest-Knotens oder des
SOAPAsyncRequest-Knotens zusammen mit asynchronen
HTTP-Anforderung/Antwort-Operationen gelten folgende Einschränkungen:
- Umleitungen werden nicht unterstützt. Nachrichten mit einem Umleitungsstatuscode (3xx) werden
als Fehler behandelt und die Antwort wird gemäß den Eigenschaften auf der Registerkarte 'Fehler' an
das Fehlerterminal (Error) des Antwortknotens weitergeleitet.
- WS-RM ist nicht mit asynchronen HTTP-Anforderung/Antwort-Operationen kompatibel.