In diesem Szenario ruft der Broker eine die Implementierung eines vorhandenen Web-Service auf. Die WSDL für den Web-Service ist bereits vorhanden und wird für die Zusammenstellung einer Nachrichtengruppe importiert.
Unter Verwendung beispielsweise eines SOAPRequest-Knotens sendet ein Nachrichtenfluss, der auf dieser Nachrichtengruppe basiert, eine Web-Service-Anforderung und empfängt die Antwort.
Beschreibung der Symbole:
Mögliche Einsatzbereiche
- Für Verarbeitungen im Zuge Ihres Nachrichtenflusses möchten Sie einen Web-Service aufrufen.
- Sie nutzen einen bestehenden Web-Service und möchten ihm eine andere Schnittstelle zur
Verfügung stellen. Dabei kann es sich um eine alternative Web-Service-Schnittstelle oder eine
WebSphere MQ-Schnittstelle handeln.
- Sie nutzen einen bestehenden Web-Service und möchten dessen Implementierung ändern, ohne seine Schnittstelle ändern zu müssen, d. h., der Broker agiert als Vermittler zum Web-Service. Beispielsweise kann ein Nachrichtenfluss verwendet werden, um eine Überwachungsfunktion zu aktivieren oder um die Web-Service-Antwort transparent an eine andere Anwendung weiterzugeben.
Entwicklungsschritte
- Importieren Sie eine WSDL-Definition, um eine Nachrichtengruppe mit Definitionen für die
SOAP-Nachrichten, die von der WSDL beschrieben werden, zu erstellen.
- Erstellen Sie einen Nachrichtenfluss, um den Web-Service aufzurufen. Bei Verwendung der
SOAP-Domäne nutzt der Nachrichtenfluss einen
SOAPRequest-Knoten, einen
SOAPAsyncRequest-Knoten oder einen
SOAPAsyncResponse-Knoten. Die Knoten werden mithilfe der
in Schritt 1 importierten WSDL konfiguriert. Bei Bedarf kann die WSDL auf einen leeren
Erstellungsbereich des Nachrichtenflusseditors gezogen werden, um ein völlig neues
Nachrichtenflussgerüst zu erstellen. Wenn Sie die SOAP-Domäne verwenden, müssen Sie den
Nachrichtenfluss mithilfe von Transportknoten sowie einer XML- oder MIME-Domäne erstellen. Gibt die
WSDL-Bindung bei einer SOAP-Anforderungsnachricht beispielsweise HTTP-Transport an, kann mit der
XMLNSC-Domäne ein HTTPRequest-Knoten verwendet werden. In diesem Fall können Sie die Endpunktinformationen für den Web-Service manuell für den Knoten konfigurieren.
- Erstellen Sie eine Brokerarchivdatei für die Implementierung. Die Brokerarchivdatei enthält
Ihren Nachrichtenfluss und die Nachrichtengruppe mit der importierten WSDL. Für die SOAP-Domäne muss
die WSDL auf jeden Fall implementiert sein, da die Nachrichten zur Ausführungszeit anhand der WSDL
überprüft werden. Außerdem werden die WSDL-Informationen zur logischen Baumstruktur hinzugefügt. Die Nachrichtengruppe enthält XML-Schemadefinitionen, die in SOAP-, XMLNSC- oder
MRM-Domänen für die Nachrichtenüberprüfung verwendet werden können.
Zur Ausführungszeit
Ihr Nachrichtenfluss erstellt eine entsprechend formatierte
Web-Service-Anforderung, ruft den Web-Service auf und wertet die Web-Service-Antwort aus. Bei
Verwendung der SOAP-Domäne greift Ihr Nachrichtenfluss auf das logische Baumstrukturmodell von SOAP
zurück. Anderenfalls verwendet der Nachrichtenfluss die logische Baumstruktur der ausgewählten
Domäne; so verwenden Sie beispielsweise die MIME-Domäne, wenn Ihre Web-Service-Nachrichten SOAP mit
Anhängen verwenden.
Beispiel 1
- Zwischengeschalteter Web-Service
- In diesem Beispiel verwendet eine Clientanwendung einen Web-Service namens 'Account', der von
einer anderen Organisation bereitgestellt wird. Der Client wird von vielen Mitarbeitern Ihres Unternehmens verwendet. Er verwendet eine Operation namens 'getBalance'. Der Account-Service wird
nun aber so modifiziert, dass sich die Definition der Operation 'getBalance' ändert. Statt
daraufhin den Client zu bearbeiten, können Sie Nachrichtenflüsse erstellen, die eine Schnittstelle
zum Account-Service bereitstellen. Der Nachrichtenfluss kann den Account-Service zur Erledigung
seiner Arbeit auffordern und der neue Web-Service kann diese an den ursprünglichen Web-Service
delegieren.
Damit kann der Client den Account-Service weiterhin, allerdings mit den neuen
Nachrichtenflüssen verwenden.
In den Beispielen für typische Nachrichtenflussmuster, die hier
gezeigt werden, ruft der zwischengeschaltete Anforderungsknoten den Account-Service auf:
- Bei Verwendung von SOAPInput-,
SOAPRequest- und
SOAPReply-Knoten:
- Bei Verwendung von SOAPInput-,
SOAPAsyncRequest-,
SOAPAsyncResponse- und
SOAPReply-Knoten:
- Bei Verwendung von HTTPInput-, HTTPRequest- und HTTPReply-Knoten:
In den Nachrichtenflüssen
dieses Beispiels passt 'Rechenknoten1' die ursprüngliche 'getBalance'-Nachricht an den geänderten
Account-Service an, während Rechenknoten2 die Antwortnachricht in das Originalformat
zurückkonvertiert. Falls Sie eine WSDL importiert oder generiert haben, verfügen Sie bereits über
ein Nachrichtenmodell für die Operation 'getBalance'. Falls Sie ein Nachrichtenmodell für die
Operation 'getBalance' definiert haben, können Sie
Mapping-Knoten anstelle von
Compute-Knoten verwenden.
HTTP-Details
Wenn Sie die HTTP-Transportknoten wie in diesem Beispiel
verwenden, können Sie den HTTPRequest-Knoten so
konfigurieren, dass er aus den vom HTTPInput-Knoten
empfangenen Headern HTTP-Header generiert. Diese Konfiguration ermöglicht die Weiterleitung von
Cookies und anderen anwendungsspezifischen Headern über den Nachrichtenfluss. Der
HTTPReply-Knoten kann zum Extrahieren der Header aus der
Antwort des Web-Service verwendet werden, um diese an den anfordernden Client zurückzusenden. Zum
Erstellen dieser Konfiguration müssen Sie sowohl für den
HTTPRequest-Knoten als auch für den
HTTPReply-Knoten die Option
HTTP-Standard-Header auf Basis der Antwort generieren auswählen. In der
Regel benötigen Sie zur Generierung der Antwort an den Client die ursprüngliche
Anforderungsnachricht nicht. Sie können daher für den
HTTPRequest-Knoten die Option
Eingabenachricht durch Antwort des Webservices ersetzen auswählen. Falls Sie
Daten aus der Eingabeanforderung beibehalten möchten, speichern Sie sie in der Baumstruktur
'LocalEnvironment' unter 'Rechenknoten1' und rufen Sie sie unter 'Rechenknoten2' ab, um sie in die
Antwort einzufügen.
Beispiel 2
- Verwendung eines Web-Service
- In diesem Beispiel wird ein Prozess für die Personalabteilung Ihres Unternehmens durch einen
WebSphere MQ-Nachrichtenfluss implementiert. Im Zuge der Verarbeitung
ruft der Nachrichtenfluss einen Web-Service auf, um die Mitarbeiter-IDs abzurufen. Mitarbeiter-IDs
werden im Mitarbeiterverzeichnis des Unternehmens verwaltet, auf das über einen Web-Service
zugegriffen wird.
In den Beispielen für typische Nachrichtenflussmuster, die hier gezeigt
werden, ruft der zwischengeschaltete Anforderungsknoten die Mitarbeiter-ID ab:
- MQInput-,
SOAPRequest- und
MQOutput-Knoten
verwenden:
- Bei Verwendung von MQInput-, SOAPAsyncRequest-, SOAPAsyncResponse- und MQOutput-Knoten:
- MQInput-,
HTTPRequest- und
MQOutput-Knoten
verwenden:
In den Nachrichtenflüssen dieses Beispiels bereitet 'Rechenknoten1' die Web-Service-Anforderung vor, während 'Rechenknoten2' die Antwort verarbeitet,
zum Beispiel durch Einfügen der Mitarbeiter-ID in eine andere Nachricht.
Falls Sie ein Nachrichtenmodell definiert haben, können Sie in diesen Beispielen Mapping-Knoten anstelle von Compute-Knoten verwenden.
HTTP-Details
Wenn Sie die HTTP-Transportknoten wie in diesem Beispiel verwenden, empfiehlt es sich in der Regel, die Option Eingabenachricht durch Antwort des Webservices ersetzen in den Eigenschaften des HTTPRequest-Knotens zu inaktivieren.
Die Antwort aus dem Verzeichnisserver des Unternehmens wird in ein temporäres Verzeichnis der Nachrichtenbaumstruktur kopiert. Dieses temporäre Verzeichnis wird durch die Eigenschaft Position der Antwortnachricht in Baumstruktur des gleichen Knotens festgelegt. Im Rechenknoten2 können Sie ESQL so codieren, dass das Ergebnis abgerufen und die endgültige Nachricht aktualisiert wird.
In diesen Szenarios sollte bevorzugt die SOAP-Domäne verwendet werden.
Weitere Informationen zur Auswahl einer Domäne für Web-Services finden Sie im Abschnitt WebSphere Message Broker und Web-Services.