In diesem Szenario implementiert der Broker eine neue Web-Service-Schnittstelle. Die WSDL für den Web-Service wird aus einer Nachrichtengruppe generiert und den Clients zur Verfügung gestellt. Ein auf dieser WSDL und der Nachrichtengruppe basierender Nachrichtenfluss empfängt eine Anforderung und erstellt daraufhin eine Antwortnachricht aus Daten, die er von einer bestehenden Anwendung erhält, die kein Web-Service ist.
Das folgende Diagramm zeigt eine Nachrichtengruppe, die aus einer Schnittstellendefinition (z. B. aus einer Headerdatei) einer bestehenden Anwendung erstellt wurde, die zur Zeit nicht als Web-Service zugänglich ist. Aus der Nachrichtengruppe wird eine WSDL-Datei generiert und für die Verwendung durch einen Web-Service-Client exportiert. Zum Aufruf der Anwendung wird ein auf der Nachrichtengruppe und der WSDL basierender Nachrichtenfluss erstellt. Der Nachrichtenfluss und die Nachrichtengruppe werden in einem Broker implementiert. Dadurch wird der Ursprungsanwendung eine Web-Service-Schnittstelle zur Verfügung gestellt.
Beschreibung der Symbole:
Dieses Szenario wird manchmal als Web-Service-Fassade bezeichnet. Das Design der Web-Service-Schnittstelle besteht in der Regel aus einigen Umgruppierungen, Einschränkungen oder Erweiterungen der bestehenden Schnittstellen und wird nicht durch eine bestehende WSDL-Definition eingeschränkt.
Ihr Nachrichtenfluss empfängt eine Web-Service-Anforderung, wandelt sie in ein von der bestehenden Anwendung erwartetes Format um und ruft die bestehende Anwendung auf. Die Antwort von der bestehenden Anwendung wird in eine gültige Web-Service-Antwort umgewandelt.
In diesem Beispiel wird ein bestehender Nachrichtenfluss so modifiziert, dass er einen Web-Service bereitstellt. Falls die Daten des bestehenden Nachrichtenflusses in einer Nachrichtengruppe modelliert sind, kann aus dieser Nachrichtengruppe eine WSDL-Definition generiert und den Clients zur Verfügung gestellt werden.
Die meisten Nachrichtenflüsse, die WebSphere MQ derzeit für Ein- oder Ausgabeoperationen verwenden, können so angepasst werden, dass sie Web-Services als Ersatz oder zusätzliches Protokoll unterstützen.
Bei Verwendung der SOAP-Domäne unterscheidet sich der Aufbau der logischen Baumstruktur von der ursprünglichen Domäne. Dies muss im Nachrichtenfluss berücksichtigt werden. Bei Verwendung der HTTP-Knoten mit der ursprünglichen Domäne bleibt der Aufbau der logischen Baumstruktur unverändert. Informationen zur Auswahl der Domäne finden Sie im Abschnitt WebSphere Message Broker und Web-Services.
In diesem Beispiel wird ein Nachrichtenfluss erstellt, der asynchronen Zugriff auf eine WebSphere MQ-Anwendung bereitstellt.
In beiden Fällen empfängt der erste Nachrichtenfluss ankommende Anforderungen von einem Web-Service-Client. Der Knoten 'Rechenknoten1' wandelt die Anforderung um und ein MQOutput-Knoten sendet die geänderte Anforderung an die bestehende Anwendung.
Im zweiten Nachrichtenfluss empfängt ein MQInput-Knoten die Antwort der Anwendung. Der Rechenknoten2 wandelt die Nachricht daraufhin um und leitet sie an einen Antwortknoten weiter, der dem ursprünglichen Web-Service-Client antwortet.
Zudem muss der Rechenknoten1 einige Korrelationsdaten speichern, die vom Rechenknoten2 abgerufen werden, um sicherzustellen, dass die Antworten von der WebSphere MQ-Anwendung an den Client zurückgegeben werden, der die ursprüngliche Anforderung gesendet hat.
HTTPInput- und MQOutput-Knoten für die abgehende Nachricht und MQInput- und HTTPReply-Knoten für die Antwortnachricht verwenden:
Eine Möglichkeit, die Korrelationsdaten zu bewahren, besteht in der Verschlüsselung der Korrelations-ID in der abgehenden Nachricht durch den Rechenknoten1. (Eine alternative Möglichkeit wäre das Speichern der ID in einer Datenbank). Die SOAPInput- und HTTPInput-Knoten fügen die ID in ein Feld in der Baumstruktur der lokalen Umgebung ein. Der Rechenknoten1 kann diesen Wert lesen und speichern. Die Speicherposition der ID unterscheidet sich, je nachdem, ob die ID vom SOAPInput- oder vom HTTPInput-Knoten eingefügt wird. Näheres hierzu erfahren Sie in den folgenden Abschnitten.
SOAP-Knoten
SET OutputRoot.XMLNS.A.MessageID =
CAST(InputLocalEnvironment.Destination.SOAP.Reply.ReplyIdentifier AS CHARACTER);
Fügen Sie
im ESQL-Modul für den Rechenknoten2 eine Anweisung wie die folgende ein: SET OutputLocalEnvironment.Destination.SOAP.Reply.ReplyIdentifier =
CAST(InputRoot.XMLNS.A.MessageID AS BLOB);
HTTP-Knoten
SET OutputRoot.XMLNS.A.MessageID =
CAST(InputLocalEnvironment.Destination.HTTP.RequestIdentifier AS CHARACTER);
Fügen Sie
im ESQL-Modul für den Rechenknoten2 eine Anweisung wie die folgende ein: SET OutputLocalEnvironment.Destination.HTTP.RequestIdentifier =
CAST(InputRoot.XMLNS.A.MessageID AS BLOB);