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.

Beschreibung der Symbole:

Mögliche Einsatzbereiche
- Der Broker stellt eine Web-Service-Implementierung mit einer anderen Servicequalität aus bestehenden Implementierungen zur Verfügung.
- Der Broker stellt eine Migrationsstrategie für die bestehende Implementierung zur Verfügung.
Entwicklungsschritte
- Importieren Sie die WSDL-Definition, um eine Nachrichtengruppe mit Definitionen für die
SOAP-Nachrichten, die von der WSDL beschrieben werden, zu erstellen.
- 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.
- 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:
- SOAPInput- und SOAPReply-Knoten verwenden:
- HTTPInput- und
HTTPReply-Knoten
verwenden:
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.
- SOAPInput-,
SOAPReply- und
MQGet-Knoten
verwenden:
- HTTPInput-,
HTTPReply- und
MQGet-Knoten
verwenden:
- Zwei Nachrichtenflüsse mit SOAPInput- und
SOAPReply-Knoten
verwenden:
- Zwei Nachrichtenflüsse mit HTTPInput- und
HTTPReply-Knoten
verwenden:
Der Nachrichtenfluss wird wie folgt erstellt:
- Erstellen Sie ein Nachrichtenmodell für die bestehende Anwendungsschnittstelle, zum Beispiel durch den Import einer C-Headerdatei für die Anwendung.
- Importieren Sie eine bestehende WSDL-Definition für den Client.
- 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.