Broker implementiert neue Web-Service-Schnittstelle

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.

Dieses 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 Diagramm beschreibt die in den anderen Diagrammen verwendeten Symbole und wird an dieser Stelle nicht beschrieben, weil es zu jedem der Diagramme eine eigene Beschreibung gibt.

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.

Mögliche Einsatzbereiche

Entwicklungsschritte

  1. Erstellen Sie eine Nachrichtengruppe für Geschäftsnachrichten, indem Sie beispielsweise eine bestehende Schnittstellendefinition, z. B. eine C-Headerdatei oder ein COBOL-Copy Book, importieren.
  2. Generieren Sie aus der Nachrichtengruppe eine WSDL-Definition.
  3. Erstellen Sie mithilfe eines SOAP-Toolkits (z. B. Rational Application Developer) einen geeigneten Web-Service-Client auf Basis der WSDL-Definition.
  4. Entwickeln Sie einen Nachrichtenfluss, um den Web-Service zu implementieren.

Laufzeit

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.

Beispiel 1

Eine bestehende CICS-Anwendung verfügt über eine COBOL-Copy Book-Schnittstelle.

  1. Importieren Sie das COBOL-Copy Book, um ein Nachrichtenmodell zu erstellen.
  2. Erstellen Sie einen Nachrichtenfluss mit folgenden Knoten: HTTPInput HTTPReply und CICS.
  3. Stellen Sie die Web-Service-Fassade mithilfe des HTTPInput- und HTTPReply-Knotens zur Verfügung.
  4. Rufen Sie über den CICS-Knoten die ursprüngliche CICS-Implementierung auf.

Beispiel 2

Der Nachrichtenfluss wird als Web-Service aufgerufen
Sie ändern den Entwurf eines bestehenden Nachrichtenflusses, damit er mit Web-Service-Clients über HTTP interagiert. Der bestehende Nachrichtenfluss nimmt eine klar strukturierte Eingabenachricht entgegen, und der Client kann den Nachrichtenfluss mithilfe eines aus den WebSphere Message Broker-Tools exportierten WSDL-Codes aufrufen.

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.

Dies ist ein Nachrichtenfluss mit den Knoten 'HTTPInput', 'Compute1', 'DataUpdate', 'Compute2' und 'HTTPReply'.

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.

Beispiel 3

Der Nachrichtenfluss ermöglicht den Zugriff auf eine WebSphere MQ-Anwendung
Sie entwerfen zwei Nachrichtenflüsse, die Anforderungen von Web-Service-Clients empfangen und Antworten zurücksenden und die mit einer vorhandenen WebSphere MQ-Anwendung, die nicht für die Kommunikation über HTTP angepasst wurde, interagieren.

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.

Dies sind zwei Nachrichtenflüsse. Der erste enthält die Knoten 'HTTPInput', 'Compute1' und 'MQOutput'. Der zweite enthält die Knoten 'MQInput', 'Compute2' und 'HTTPReply'. Der MQOutput-Knoten am Ende des ersten Nachrichtenflusses stellt eine Nachricht in eine WebSphere MQ-Warteschlange, die von einer vorhandenen Anwendung bedient wird, die ihre Antworten in die Eingabewarteschlange stellt, die wiederum vom MQInput-Knoten am Anfang des zweiten Nachrichtenflusses bedient wird.

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);
Zugehörige Konzepte
Nachrichtenflüsse bei der XML-Domäne
Broker ruft bestehenden Web-Service auf
Broker implementiert bestehende Web-Service-Schnittstelle
Broker implementiert Schnittstelle, die nicht auf Web-Service basiert, in neuem Web-Service
Bemerkungen | Marken | Downloads | Bibliothek | Unterstützung | Feedback

Copyright IBM Corporation 1999, 2009Copyright IBM Corporation 1999, 2009.
Letzte Aktualisierung : 2009-02-17 15:28:30

ac34540_