WebSphere Message Broker Version 8.0.0.5 Betriebssysteme: AIX, HP-Itanium, Linux, Solaris, Windows, z/OS

Sehen Sie sich die Informationen zur aktuellen Produktversion im IBM Integration Bus Version 9.0 an.

Broker implementiert neue Web-Service-Schnittstelle

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.

Die Abbildung wird im umgebenden Text beschrieben.

Beschreibung der Symbole:

In dieser Tabelle werden die Symbole beschrieben, die in den anderen Abbildungen verwendet werden; diese anderen Abbildungen werden nicht hier beschrieben, sondern an der Stelle, an der sie vorkommen.

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 dem Nachrichtensatz 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.

Zur Ausführungszeit

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

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.

Nachfolgend finden Sie typische Nachrichtenflussmuster für dieses Beispiel. In jedem dieser Fälle ersetzen oder ergänzen die Empfangs- und Antwortknoten die ursprünglichen MQInput- und MQOutput-Knoten. Der größte Teil des Nachrichtenflusses erfüllt nützliche Verarbeitungsaufgaben.
  • Bei Verwendung von SOAPInput- und SOAPReply-Knoten:
    Diese Abbildung zeigt einen Nachrichtenfluss, der unter Verwendung von SOAPInput- und SOAPReply-Knoten einen Web-Service bereitstellt.
  • Bei Verwendung von HTTPInput- und HTTPReply-Knoten:
    Diese Abbildung zeigt einen Nachrichtenfluss, der unter Verwendung von HTTPInput- und HTTPReply-Knoten einen Web-Service bereitstellt.

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.

HTTP-Details
Wenn Sie die HTTP-Knoten verwenden, können Sie 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 2

In diesem Beispiel wird ein Nachrichtenfluss erstellt, der asynchronen Zugriff auf eine WebSphere MQ-Anwendung bereitstellt.

Nachfolgend finden Sie typische Nachrichtenflussmuster für dieses Beispiel. In jedem dieser Fälle empfängt der Nachrichtenfluss eine Web-Service-Anforderung und erstellt die Antwortnachricht aus Daten, die via WebSphere MQ von der Anwendung zurückgegeben werden.
  • Zwei Nachrichtenflüsse mit SOAPInput- und SOAPReply-Knoten verwenden:
    Das Diagramm zeigt zwei Nachrichtenflüsse, die mithilfe von SOAPInput- und SOAPReply-Knoten asynchronen Zugriff auf eine WebSphere MQ-Anwendung bereitstellen.
  • Zwei Nachrichtenflüsse mit HTTPInput- und HTTPReply-Knoten verwenden:
    Das Diagramm zeigt zwei Nachrichtenflüsse, die mithilfe von HTTPInput- und HTTPReply-Knoten asynchronen Zugriff auf eine WebSphere MQ-Anwendung bereitstellen.

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.

HTTP-Details

HTTPInput- und MQOutput-Knoten für die abgehende Nachricht und MQInput- und HTTPReply-Knoten für die Antwortnachricht verwenden:

Die Abbildung zeigt, wie Sie HTTPInput- und MQOutput-Knoten als Knoten für abgehende Nachrichten und MQInput- und HTTPReply-Knoten als Knoten für Antwortnachrichten verwenden können.

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

Der Rechenknoten2 liest die SOAP-Antwort-ID aus der Nachricht und legt 'LocalEnvironment.Destination.SOAP.Reply.ReplyIdentifier' auf Basis dieses Werts fest. Der SOAPReply-Knoten stellt anhand der Antwort-ID sicher, dass die Nachricht den richtigen HTTP-Client erreicht. Fügen Sie im ESQL-Modul für den Rechenknoten1 eine Anweisung wie die folgende ein:
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

Der Rechenknoten2 liest die HTTP-Anforderungs-ID aus der Nachricht und legt 'LocalEnvironment.Destination.HTTP.RequestIdentifier' auf Basis dieses Werts fest. Der HTTPReply-Knoten stellt anhand der Anforderungs-ID sicher, dass die Nachricht den richtigen HTTP-Client erreicht. 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);
Bemerkungen | Marken | Downloads | Bibliothek | Support | Feedback

Copyright IBM Corporation 1999, 2014Copyright IBM Corporation 1999, 2014.

        
        Letzte Aktualisierung:
        
        Letzte Aktualisierung: 2015-02-28 16:20:11


KonzeptthemaKonzeptthema | Version 8.0.0.5 | ac34540_