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 bestehende Web-Service-Schnittstelle

In diesem Szenario implementiert der Broker eine bestehende Web-Service-Schnittstelle. Die WSDL für den Web-Service ist bereits vorhanden und wird für die Zusammenstellung einer Nachrichtengruppe importiert. Ein auf dieser 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.

Die Abbildung wird im vorhergehenden Text beschrieben.

Beschreibung der Symbole:

In diesem Diagramm werden die Symbole beschrieben, die in den anderen Diagrammen verwendet werden; diese werden nicht hier beschrieben, da es eigene Beschreibungen dazu gibt.

Mögliche Einsatzbereiche

Entwicklungsschritte

  1. Importieren Sie die WSDL-Definition, um eine Nachrichtengruppe mit Definitionen für die SOAP-Nachrichten, die von der WSDL beschrieben werden, zu erstellen.
  2. Passen Sie die Nachrichtengruppe für die erforderliche bestehende Schnittstelle an, indem Sie beispielsweise eine bestehende Schnittstellendefinition, z. B. eine C-Headerdatei oder ein COBOL-Copy Book, importieren.
  3. 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 stellt ein bestehender HTTP-Web-Service-Client Informationen zu einem bestimmten Thema (z. B. Aktien- oder Wechselkurse) zur Verfügung. Sie möchten diesen Service durch eine Lösung mit einer unternehmensinternen Datenbanksuchfunktion ersetzen, dabei jedoch nicht die Clients ändern, da diese unternehmensweit implementiert sind.

Typische Nachrichtenflussmuster werden in den folgenden Beispielen gezeigt. In jedem dieser Fälle ruft der zwischengeschaltete Knoten die Informationen aus der Datenbank ab:

  1. SOAPInput- und SOAPReply-Knoten verwenden:
    In diesem Knoten wird ein Nachrichtenfluss angezeigt, der mithilfe der SOAPInput- und SOAPReply-Knoten als Lösung für die Datenbanksuche verwendet wird.
  2. HTTPInput- und HTTPReply-Knoten verwenden:
    Das Diagramm zeigt einen Nachrichtenfluss, der mithilfe von HTTPInput- und HTTPReply-Knoten als Lösung für die Datenbanksuche agiert.

In den oben dargestellten Nachrichtenflüssen empfangen die Empfangsknoten die Web-Service-Anforderung. Der Rechenknoten1 ruft danach die benötigten Informationen aus der Datenbank ab und generiert aus diesen Daten eine passende Web-Service-Antwort. Die Antwort wird vom Antwortknoten an den Client zurückgesendet. Statt der Compute-Knoten können Sie in diesem Beispiel auch Mapping-Knoten verwenden.

Beispiel 2

In diesem Beispiel wird eine bestehende Anwendung als Web-Service bereitgestellt. Allerdings gilt für die als Web-Service bereitgestellte Schnittstelle eine Einschränkung, da von einem vielfach eingesetzten Client bereits ein ähnlicher Service genutzt wird, der durch eine bestehende WSDL-Definition festgelegt ist. Möglicherweise bietet der Broker dem Client die gleiche Schnittstelle ein weiteres Mal an, weil der ursprüngliche Service eine andere Servicequalität bietet oder demnächst außer Funktion gesetzt wird.

Typische Nachrichtenflussmuster werden in den folgenden Beispielen gezeigt. In jedem dieser Fälle empfangen die Nachrichtenflüsse die Web-Service-Anforderung und erstellen die Antwortnachricht aus Daten, die via WebSphere MQ von der Anwendung zurückgegeben werden.

  1. SOAPInput-, SOAPReply- und MQGet-Knoten verwenden:
    Das Diagramm zeigt einen Nachrichtenfluss, der im umgebenden Text beschrieben wird.
  2. HTTPInput-, HTTPReply- und MQGet-Knoten verwenden:
    Das Diagramm zeigt einen Nachrichtenfluss, der im umgebenden Text beschrieben wird.
  3. Zwei Nachrichtenflüsse mit SOAPInput- und SOAPReply-Knoten verwenden:
    Das Diagramm zeigt einen Nachrichtenfluss, der im umgebenden Text beschrieben wird.
  4. Zwei Nachrichtenflüsse mit HTTPInput- und HTTPReply-Knoten verwenden:
    Das Diagramm zeigt einen Nachrichtenfluss, der im umgebenden Text beschrieben wird.
Der Nachrichtenfluss wird wie folgt erstellt:
  1. Erstellen Sie ein Nachrichtenmodell für die bestehende Anwendungsschnittstelle, zum Beispiel durch den Import einer C-Headerdatei für die Anwendung.
  2. Importieren Sie eine bestehende WSDL-Definition für den Client.
  3. Erstellen Sie einen auf der Nachrichtengruppe basierenden Nachrichtenfluss, um die Web-Service-Schnittstelle zu implementieren und mit der bestehenden Anwendung zu kommunizieren.
Die Nachrichtenflüsse 1 und 2 zeigen einen synchronen Anwendungsaufruf mittels der MQOutput- und MQGet-Knoten. Im MQGet-Knoten können Sie einen Zeitlimitwert einstellen, um den Vorgang bei einem Fehler der fernen Anwendung abzubrechen. Die Umsetzung der Anforderung in die Antwort kann in einem einzigen Vorgang ausgeführt, wodurch eine eventuell erforderliche Zurücksetzung und Wiederherstellung einfach durchzuführen ist. Jedoch muss jede eingehende Anforderung vor dem Fortfahren mit der nächsten Anforderung vollständig verarbeitet und beantwortet worden sein. Bei langen Antwortzeiten der Anwendung kann sich dieses Verhalten auf die Leistung auswirken. Die Nachrichtenflüsse der Beispiele 3 und 4 zeigen den gleichen Anwendungsaufruf, allerdings als asynchronen Vorgang. In beiden Fällen endet der erste Nachrichtenfluss, nachdem er die Nachricht an die Anwendung gesendet hat, und steht dadurch wieder weiteren Anforderungen zur Verfügung. Dieses Szenario setzt allerdings voraus, dass der Anforderungsfluss den Korrelationskontext speichert und dieser vom Antwortfluss wiederhergestellt wird. Der Korrelationskontext kann zum Beispiel in einer Warteschlange gespeichert und mithilfe eines MQGet-Knotens im Antwortfluss abgerufen werden. Durch diese Nachrichtenflusskonfiguration werden die Anforderungen sofort an die Anwendung durchgestellt und die Antworten werden in der Reihenfolge übermittelt, in der sie empfangen wurden. Statt der Compute-Knoten können Sie in diesem Beispiel auch Mapping-Knoten verwenden.

In diesen Szenarios sollte bevorzugt die SOAP-Domäne verwendet werden. Weitere Informationen zur Auswahl einer Domäne für Web-Services finden Sie im Abschnitt WebSphere Message Broker und Web-Services.

Weitere Informationen zum Szenario der Anforderung und Beantwortung einer asynchronen Operation finden Sie im Abschnitt Szenario des Typs 'Anforderung/Antwort' unter Verwendung eines MQGet-Knotens.

Das Szenario der Anforderung und Beantwortung einer asynchronen Operation wird auch im folgenden Beispiel beschrieben, das auch für die Web-Service-Verwendung angepasst werden kann.
Ein weiteres Web-Service-Szenario wird im folgenden Beispiel beschrieben:

Informationen zu Beispielen können nur bei Verwendung des in das WebSphere Message Broker Toolkit integrierten bzw. online verfügbaren Information Center angezeigt werden. Muster können nur ausgeführt werden, wenn das im WebSphere Message Broker Toolkit integrierte Information Center verwendet wird.

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 | ac34550_