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.

Das Diagramm zeigt eine bestehende Anwendung, deren Definitionsdatei in eine Nachrichtengruppe importiert wird. Aus der Nachrichtengruppe wird eine WSDL-Datei generiert. Die Nachrichtengruppe wird in einem Nachrichtenfluss in einem Broker implementiert. Der Nachrichtenfluss interagiert zur Laufzeit mit der bestehenden Originalanwendung und dem Web-Service-Client.

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.

Dies 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

Der Broker stellt einer bestehenden Anwendung eine Web-Service-Schnittstelle und damit optional zusätzliche Leistungsmerkmale, z. B. eine Überwachung der gestellten Anforderungen, zur Verfügung.

Mit der Zeit kann die Implementierung geändert werden, ohne dass die Schnittstelle zum Web-Service-Client davon betroffen ist.

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 mit Hilfe 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: HTTPEmpfangsknoten, HTTPAntwortknoten und CICS-Knoten.
  3. Stellen Sie die Web-Service-Fassade mit Hilfe des HTTPEmpfangs- und HTTPAntwortknotens 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 mit Hilfe 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 dem HTTPEmpfangsknoten, dem Rechenknoten1, dem Datenaktualisierungsknoten, dem Rechenknoten2 und dem HTTPAntwortknoten.

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 XML- oder XMLNS-Domänennachricht verarbeiten. Wenn Sie die Nachricht in der MRM-Domäne definiert haben, können Sie den HTTPEmpfangsknoten 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 HTTPAntwortknoten so konfigurieren, dass er einen Satz von standardmäßigen HTTP-Headern für die Antwortnachricht, die an den Client gesendet wird, generiert. Dadurch verringern sich die Änderungen, die Sie durchführen müssen, um den Nachrichtenfluss so umzuwandeln, dass er nicht mehr WebSphere MQ-Nachrichten, sondern 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 HTTPEmpfangsknoten. Er enthält einen Rechenknoten, der eine Anforderungsumwandlung durchführt, und einen MQSendeknoten, der die geänderte Anforderung an die WebSphere MQ-Anwendung sendet.

Der zweite Nachrichtenfluss empfängt die Antwort von der betreffenden Anwendung in einem MQEmpfangsknoten. Die Nachricht wird an einen Rechenknoten übergeben, der die Nachricht umwandelt und an einen HTTPAntwortknoten weitergibt, der sie als Antwort an den ursprünglichen Web-Service-Client sendet.

Auch wenn die von den einzelnen Rechenknoten durchgeführten Umwandlungen nur geringfügig sind, muss der ESQL-Code im ersten Nachrichtenfluss HTTP-Statusinformationen speichern, die vom zweiten 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 den HTTPEmpfangsknoten, den Rechenknoten1 und den MQSendeknoten. Der zweite enthält den MQEmpfangsknoten, den Rechenknoten2 und den HTTPAntwortknoten. Der MQSendeknoten 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 vom MQEmpfangsknoten 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 HTTPEmpfangsknoten stellt die Anforderungs-ID im Feld 'Destination.HTTP.RequestIdentifier' in der Baumstruktur 'LocalEnvironment' bereit. Der Rechenknoten1 kann diesen Wert lesen und speichern.

Der zweite Nachrichtenfluss empfängt die Antwortnachricht und wandelt sie wieder in das Clientnachrichtenformat um. Der Rechenknoten2 liest die HTTP-Anforderungs-ID aus der Nachricht und legt 'LocalEnvironment.Destination.HTTP.RequestIdentifier' auf Basis dieses Wertes fest. Der HTTPAntwortknoten stellt anhand der Anforderungs-ID sicher, dass die Nachricht den richtigen HTTP-Client erreicht.

Die Implementierung dieses Szenarios erfordert eine korrekte Handhabung des MQMD. Zu Nachrichten, die über HTTP in einen Nachrichtenfluss eingehen, muss ein MQMD-Header hinzugefügt werden, bevor sie an einen MQSendeknoten übergeben werden. Ebenso muss aus allen Nachrichten, die über WebSphere MQ eingehen, der MQMD-Header entfernt werden, bevor sie an einen HTTPAntwort- oder HTTPAnforderungsknoten gesendet werden (außer wenn ein MQMD-Header im HTTP-Datenstrom gewünscht wird).

Fügen Sie in das ESQL-Modul für den Rechenknoten1 eine Anweisung wie die folgende ein:

SET OutputRoot.XML.A.MessageID =    
			CAST(InputLocalEnvironment.Destination.HTTP.RequestIdentifier AS CHARACTER);

Fügen Sie in das ESQL-Modul für Rechenknoten2 eine Anweisung wie die folgende ein:

SET OutputLocalEnvironment.Destination.HTTP.RequestIdentifier =     
			CAST(InputRoot.XML.A.MessageID AS BLOB);
Zugehörige Konzepte
Web-Services, WSDL und Nachrichtenflüsse
Broker ruft bestehenden Web-Service auf
Broker implementiert bestehende Web-Service-Schnittstelle
Broker implementiert Schnittstelle, die nicht auf Web-Service basiert, zu neuem Web-Service
Bemerkungen | Marken | Downloads | Bibliothek | Unterstützung | Rückmeldung
Copyright IBM Corporation 1999, 2006 Letzte Aktualisierung: 23. Aug. 2006
ac34540_