In diesem Web-Service-Szenario stellt der Broker einer bestehenden Anwendung, bei der es sich nicht um einen Web-Service handelt, eine Web-Service-Schnittstelle zur Verfügung.
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.
Eine bestehende CICS-Anwendung verfügt über eine COBOL-Copy Book-Schnittstelle.
Die meisten Nachrichtenflüsse, die zurzeit WebSphere MQ für Ein- oder Ausgabeoperationen verwenden, können so angepasst werden, dass sie HTTP als Ersatz oder zusätzliches Protokoll nutzen.
Sie können die Eingabenachricht in der MRM-Domäne modellieren und WSDL-Code aus dem Modell generieren; Sie können aber auch eine generische XMLNS-Domänennachricht verarbeiten. Wenn Sie die Nachricht in der MRM-Domäne definiert haben, können Sie den HTTPInput-Knoten so konfigurieren, dass er die Eingabenachricht prüft. Der Knoten generiert eine Ausnahme, wenn die Nachricht nicht mit dem Modell konform ist.
Sie können den HTTPReply-Knoten so konfigurieren, dass er für die an den Client gesendete Antwortnachricht einen Satz von HTTP-Standard-Headern generiert. Dadurch verringern sich die Änderungen, die Sie durchführen müssen, um den Nachrichtenfluss so umzuwandeln, dass er statt WebSphere MQ-Nachrichten HTTP-Nachrichten verarbeitet.
Der erste Nachrichtenfluss empfängt ankommende Anforderungen von Web-Service-Clients in einem HTTPInput-Knoten. Er enthält einen Compute-Knoten, der eine Anforderungsumwandlung durchführt, und einen MQOutput-Knoten, der die geänderte Anforderung an die WebSphere MQ-Anwendung sendet.
Der zweite Nachrichtenfluss empfängt die Antwort der betreffenden Anwendung in einem MQInput-Knoten. Die Nachricht wird an einen Compute-Knoten übergeben, der die Nachricht umwandelt und an einen HTTPReply-Knoten weitergibt, der sie als Antwort an den ursprünglichen Web-Service-Client sendet.
Auch wenn die von den einzelnen Compute-Knoten durchgeführten Umwandlungen nur geringfügig sind, muss der ESQL-Code im ersten Compute-Knoten HTTP-Statusinformationen speichern, die vom zweiten Compute-Knoten 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.
Der erste Nachrichtenfluss empfängt die Nachricht, führt die erforderlichen Umwandlungen durch und codiert die HTTP-Anforderungs-ID in der abgehenden Nachricht. (Die Anforderungs-ID kann auf Wunsch auch in einer Datenbank gespeichert werden). Der HTTPInput-Knoten stellt die Anforderungs-ID im Feld 'Destination.HTTP.RequestIdentifier' in der Baumstruktur 'LocalEnvironment' bereit. Der Compute1-Knoten kann diesen Wert lesen und speichern.
Der zweite Nachrichtenfluss empfängt die Antwortnachricht und wandelt sie wieder in das Clientnachrichtenformat um. Der Compute2-Knoten liest die HTTP-Anforderungs-ID aus der Nachricht und legt 'LocalEnvironment.Destination.HTTP.RequestIdentifier' auf Basis dieses Wertes fest. Der HTTPReply-Knoten stellt anhand der Anforderungs-ID sicher, dass die Nachricht den richtigen HTTP-Client erreicht.
Die Implementierung dieses Szenarios erfordert eine korrekte Handhabung des MQMD. Nachrichten, die über HTTP in einen Nachrichtenfluss eingehen, muss ein MQMD-Header hinzugefügt werden, bevor sie an einen MQOutput-Knoten übergeben werden. Umgekehrt muss aus allen Nachrichten, die über WebSphere MQ eingehen, der MQMD-Header entfernt werden, bevor sie an einen HTTPReply- oder HTTPRequest-Knoten gesendet werden (außer wenn ein MQMD-Header im HTTP-Datenstrom gewünscht wird).
Fügen Sie im ESQL-Modul für den Rechenknoten1 eine Anweisung wie die folgende ein:
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);