Für die SOAPInput-, SOAPRequest- und SOAPAsyncRequest-Knoten können zwei Betriebsmodi gesetzt werden: der WSDL-Modus und der Gateway-Modus.
Im WSDL-Modus (dem Standardmodus) werden die vom Knoten ausgeführten Web-Service-Operationen über eine WSDL-Spezifikation vorgegeben, mit der der Knoten konfiguriert wird. Im Gateway-Modus handhaben SOAP-Knoten generische SOAP-Anforderungsnachrichten in den folgenden Szenarios:
- Provider-Szenario
- In diesem Szenario empfängt WebSphere Message
Broker generische SOAP/HTTP- oder SOAP/JMS-Anforderungen über einen SOAPInput-Knoten und sendet an den Client, von dem die Anforderungen stammen, eine Antwort über einen SOAPReply-Knoten. Ein einzelner SOAPInput-Knoten kann eine beliebige SOAP-Anforderungsnachricht empfangen und wird nicht mit einer WSDL konfiguriert.
- Konsumentenszenario
- In diesem Szenario kann WebSphere Message
Broker eine SOAP-Anforderung über einen SOAPRequest-Knoten oder ein SOAPAsyncRequest/SOAPAsyncResponse-Knotenpaar eine SOAP-Anforderung an einen externen Web-Service-Provider senden. Endpunktinformationen können in der lokalen Umgebung angegeben werden; diese Informationen werden zur Ausführungszeit dynamisch herangezogen, um die abgehende Anforderungsnachricht zu senden.
- Fassadenszenario
- In diesem Szenario kann WebSphere Message
Broker SOAP-Anforderungen von verschiedenen Clients empfangen und an einen der Back-End-Web-Service-Provider oder an eines der vorhandenen Systeme senden. Endpunktinformationen für den Back-End-Web-Service-Provider können dynamisch während der Ausführungszeit angegeben werden, indem in der lokalen Umgebung entsprechende Werte gesetzt werden.
Die SOAP-Knoten werden in den beiden Modi jeweils unterschiedlich konfiguriert; auch ihre Funktionsweise unterscheidet sich in den beiden Betriebsmodi.
- Wenn Sie einen Knoten im Gateway-Modus konfigurieren, sind einige Knoteneigenschaften inaktiviert, da sie im Gateway-Modus nicht anwendbar sind.
- Die Transporteigenschaften müssen konfiguriert werden. Die erforderlichen transportspezifischen Eigenschaften sind von dem Wert abhängig, der für die Eigenschaft Transport angegeben wird; bei Auswahl von JMS müssen beispielsweise die JMS-Transporteigenschaften angegeben werden.
- Ein SOAPInput-Knoten kann nur zum Empfang von Nachrichten eines einzelnen angegebenen Transports konfiguriert werden, beispielsweise HTTP. Verwenden Sie separate Eingabeknoten, um Nachrichten mit verschiedenen Transportmethoden zu senden oder zu empfangen.
- Ein SOAPRequest-Knoten kann nur zum Senden von Nachrichten eines einzelnen angegebenen Transports konfiguriert werden, beispielsweise JMS. Der Name der Transportmethode für eine beliebige Nachricht kann jedoch mithilfe der lokalen Umgebung geändert werden.
- Ein SOAPAsyncRequest-Knoten kann nur für das Senden und Empfangen von Nachrichten über eine einzige Transportmethode (beispielsweise JMS) konfiguriert werden; diese Methode wird von dem ihm zugeordneten SOAPAsyncResponse-Knoten für den Empfang der Antwortnachrichten verwendet. Sie können jedoch für jede Nachricht über die lokale Umgebung die Transportmethode für die abgehenden Anforderungen ändern.
Wird beispielsweise ein SOAPAsyncRequest-Knoten so konfiguriert, dass er den JMS-Transport verwendet, erwartet sein paariger SOAPAsyncResponse-Knoten immer den Empfang von Antworten über JMS. Dies kann nicht geändert werden.
Auch während der Ausführungszeit verwendet der SOAPAsyncRequest-Knoten JMS als Standardtransportmethode. Sie können den Knoten jedoch über die lokale Umgebung anweisen, die Anforderung über das HTTP-Protokoll zu senden.
Diese Anforderung beinhaltet die WSA:ReplyTo-JMS-Adresse für den SOAPAsyncResponse-Knoten.
- Wenn ein SOAPInput-Knoten eine unidirektionale SOAP-Anforderung empfängt, versucht der Knoten festzustellen, ob es sich um eine unidirektionale Nachricht handelt. Der Knoten kann jedoch nicht immer feststellen, ob es sich um eine unidirektionale Nachricht handelt, daher muss der SOAPReply-Knoten manchmal über die lokale Umgebung darauf hingewiesen werden, dass es sich um eine unidirektionale Nachricht handelt. Beispiel:
SET OutputLocalEnvironment.Destination.SOAP.Reply.Gateway.OneWay = True;
Der Abschnitt Unidirektionale Nachrichten im Gateway-Modus enthält weitere Informationen hierzu.
- Wird der SOAPAsyncRequest-Knoten im Gateway-Modus verwendet, muss die WS-Addressing-Eigenschaft Action in der lokalen Umgebung im Nachrichtenfluss vor dem SOAPAsyncRequest-Knoten gesetzt werden. Legen Sie diese Eigenschaft durch Verwendung von OutputLocalEnvironment.Destination.SOAP.Request.WSA.Action fest.
- Wird der SOAPRequest-Knoten im Gateway-Modus verwendet und wird vom fernen Service-Provider eine SOAPAction erwartet, muss das Feld 'SOAPAction' im Nachrichtenfluss gesetzt werden. Im Gateway-Modus steht dem Knoten keine 'SOAPAction' aus einer WSDL zur Verfügung. So wird die 'SOAPAction' beispielsweise mithilfe von ESQL gesetzt:
SET OutputRoot.HTTPRequestHeader.SOAPAction = 'mySoapAction';
Standardmäßig sendet der SOAPRequest-Knoten ein leeres SOAPAction-Feld ("").
- Wird der SOAPRequest-Knoten im Gateway-Modus eingesetzt und wird WS-Addressing verwendet, muss die WS-Addressing-Eigenschaft Action in der lokalen Umgebung im Nachrichtenfluss vor dem SOAPRequest-Knoten gesetzt werden. Legen Sie diese Eigenschaft durch Verwendung von OutputLocalEnvironment.Destination.SOAP.Request.WSA.Action fest.
- Im Gateway-Modus können eingehende 'must understand'-Header an den
SOAPInput- oder an die
SOAPRequest- und
SOAPAsyncRequest-Knoten gesendet werden, indem in der
Knoteneigenschaft die Details angegeben werden. Wenn Sie jedoch Services dynamisch hinzufügen, bei denen alle 'must understand'-Header nicht im Voraus bekannt sind, können Sie diese Header mit einem Platzhalter (*) für Name, Namespace, Vorgang oder für eine beliebige Kombination dieser drei hinzufügen. Sie müssen Ihren Nachrichtenfluss dann nicht erneut implementieren, wenn
neue Services hinzugefügt werden. Wenn Sie einen Platzhalter für den Namen, den Namespace oder auch
einen Vorgang hinzufügen, müssen Sie jedoch berücksichtigen, dass alle Header mit dem Attribut
'must understand' für den Fluss zulässig sind.
- Wird der SOAPReply-Knoten als Teil eines Fassadennachrichtenflusses verwendet, wobei für den SOAPInput-Knoten der Gateway-Modus und für den SOAPRequest-Knoten der WSDL-Modus gesetzt ist, müssen Sie auf dem SOAPReply-Knoten die Prüffunktion inaktivieren oder wie oben angegeben im Eigenschaftenordner eine explizite Nachrichtengruppe setzen. Wenn Sie die Prüfung nicht inaktivieren oder auf keine Nachrichtengruppe im Eigenschaftenordner verweisen, treten beim Serialisieren der Nachrichten Parsing-Fehler auf.
- Im Gateway-Modus senden die SOAP-Knoten standardmäßig SOAP-1.1-Nachrichten, akzeptieren jedoch auch eingehende SOAP-1.2-Nachrichten. Um eine abgehende SOAP 1.2-Nachricht zu senden, setzen Sie das Feld SOAP.Context so, dass es angibt, dass SOAP 1.2 erforderlich ist. So setzen Sie das Feld beispielsweise mithilfe von ESQL:
SET OutputRoot.SOAP.Context.SOAP_Version = '1.2';
Die abgehende Nachricht verwendet dann eine SOAP 1.2 SOAP-Rahmenanweisung. Sie können auch das Namespace-Präfix festlegen, das von der SOAP-Rahmenanweisung verwendet wird. Hier ein Beispiel unter Verwendung von ESQL:DECLARE soapenc NAMESPACE 'http://www.w3.org/2003/05/soap-envelope';
SET OutputRoot.SOAP.Context.Namespace.(SOAP.NamespaceDecl)xmlns:soap12 = soapenc;
SET OutputRoot.SOAP.Context.SOAP_Version = '1.2';
In diesem Beispiel ist soap12 das verwendete Präfix in der abgehenden Nachricht.