Broker implementiert bestehende Web-Service-Schnittstelle - Details

Dies ist ein Überblick über ein typischen End-to-End-Szenario mit einem Web-Service-Client, dem Sie durch den Broker eine bestehende Funktion, die nicht auf einem Web-Service basiert, zur Verfügung stellen möchten.

Ein bestehendes, auf C oder Cobol basierendes System bietet eine Geschäftslogik an, die auf nützliche Weise einem Web-Service zugänglich gemacht werden kann.

Wie im vorhergehenden Beispiel (Broker implementiert neuen Web-Service - Details) gibt es verschiedene Mechanismen für den Broker, um Operationen auf dem bestehenden System aufzurufen (d. h., das System macht eine Schnittstelle für den Broker zugänglich). Üblicherweise wird das bestehende System für WebSphere MQ aktiviert, d. h., es empfängt MQ-Nachrichten mit Anwendungsdaten, übergibt diese an die zu Grunde liegende Implementierung und verpackt anschließend die Rückgabewerte als MQ-Antwort. Die Datenstrukturen, die an diese bestehenden Operationen geliefert und von diesen zurückgegeben werden, sind in einer C-Headerdatei oder einem COBOL-Copy Book definiert.

In diesem Beispiel gibt es jedoch eine Vorgabe hinsichtlich des Aussehens des Web-Services: Die WSDL-Definition für einen Web-Service-Client ist bereits vorhanden.

Bei einem möglichen Szenario würde ein unternehmensweit verteilter Web-Service-Client den Benutzern bereits den Zugriff auf eine bestimmte Geschäftsfunktion ermöglichen. Die Aufgabe des Brokers besteht darin, dieselbe Schnittstelle für eine neue Implementierung auf Basis des bestehenden System anzubieten. Der ursprüngliche Web-Service-Provider bietet möglicherweise eine andere Servicequalität an, oder die Verbindung muss aus irgendeinem Grund getrennt werden.

Wie zuvor kann der Broker die bestehende Systemfunktion über WebSphere MQ aufrufen.

So implementieren Sie das Szenario:

  1. Importieren Sie die bestehenden API-Datenstrukturen, z. B. mit dem C-Importprogramm. Wenn WSDL im Dokumentformat verwendet wird, müssen Sie dafür sorgen, dass das Importprogramm die erforderlichen globalen Elemente im Brokermodell erstellt. Die WS-I (siehe http://www.ws-i.org/) empfiehlt, die Web-Service-Nutzdaten durch Namespaces zu qualifizieren, so dass der Benutzer beim Importieren den Ziel-Namespace angeben muss.

    Zu diesem Zeitpunkt verfügen Sie über ein Nachrichtenmodell für die Daten zum Aufrufen der bestehenden Operationen.

  2. Importieren Sie die bestehende WSDL-Datei, um das entsprechende Nachrichtenmodell für die erwarteten Instanzdokumente zu erstellen (siehe Datenstrukturen importieren). Der Nachrichtenfluss wertet die zugehörige SOAP-Anforderung aus und ist für die Umwandlung in oder aus dem erforderlichen bestehenden Datenformat zuständig. Sie können die importierten Nachrichtendefinitionen untersuchen und den Nachrichtenfluss mit Hilfe des ESQL- und/oder Zuordnungseditors erstellen. Sie erstellen keine Kategoriedateien und generieren keine WSDL-Datei aus dem Brokermodell.
  3. Als Ergebnis des WSDL-Imports werden die entsprechenden SOAP-Nachrichtendefinitionsdateien (MXSDs) automatisch in die Nachrichtengruppe eingeschlossen. Dies betrifft vor allem die MXSD mit der SOAP-Rahmenanweisung (Envelope) und, falls erforderlich, die MXSD mit der SOAP-Codierung.
  4. Implementieren Sie einen Nachrichtenfluss, um die Web-Service-Anforderung zu empfangen, d. h., er agiert als der Web-Service-Provider. Bei den Endpunktknoten handelt es sich um HTTP oder MQ, abhängig von der vom Client verwendeten Transportmethode. Der Empfangsknoten hat folgende Merkmale:
    • Domäne: "MRM"
    • Gruppe: die Nachrichtengruppe mit der Definition der SOAP-Rahmenanweisung
    • Typ: "Envelope"
    • Format: "XML1"
  5. Nach dem Aufruf durch den Nachrichtenfluss erstellt der Parser eine logische Baumstruktur, einschließlich der SOAP-Rahmenanweisung, so wie sie durch die vordefinierte SOAP-Nachrichtendefinitionsdatei (MXSD) definiert ist. Das Parsing wird automatisch an den Anschlusspunkten innerhalb der SOAP-Rahmenanweisung (SOAP-Hauptteil und -Header) fortgesetzt, wobei versucht wird, einen Abgleich mit anderen Nachrichtendefinitionen in der Nachrichtengruppe vorzunehmen. Führen Sie, falls erforderlich, eine Prüfung am Empfangsknoten durch.

    Zu diesem Zeitpunkt verfügen Sie über eine logische Baumstruktur, wissen jedoch nicht, welche SOAP-Nutzdaten empfangen wurden. Überprüfen Sie das HTTP-Aktionsfeld 'SOAPAction', um den wahrscheinlichen Inhalt zu ermitteln. Dies ist jedoch nur bei HTTP möglich. (Die Nutzung von 'SOAPAction' wird von der WS-I nicht empfohlen.)

  6. Sie können eine einzelne Zuordnung von den zulässigen Nutzdatennachrichten zu den erforderlichen Nachrichten vom bestehenden System bereitstellen. Beispielsweise könnte eine einzige Zuordnungsdefinition die Nachrichten Nachricht1a und Nachricht1b zu demselben Ziel, nämlich Nachricht2, zuordnen.
    Alternativ können getrennte Zuordnungen für jeden Nachrichtentyp oder für Gruppen zusammengehöriger Nachrichtentypen bereitgestellt werden. Diese Vorgehensweise hat den Vorteil, dass Zuordnungsdefinitionen einfacher verwaltet und wiederverwendet werden können. Der Nachteil besteht darin, dass Benutzer ermitteln müssen, auf welche der zuvor empfangenen Nutzdaten sie die Zuordnung anwenden können. Dazu kann folgender ESQL-Code verwendet werden:
     
     DECLARE SOAPENV NAMESPACE 'http://schemas.xmlsoap.org/soap/envelope/';
     SET contentType = FIELDNAME(InputBody.SOAPENV:Body.*[<]);
     IF (contentType = ‘foo’) ...
     
    Alternativ kann eine Feldreferenz verwendet werden, z. B.:
     
     DECLARE R REFERENCE TO InputRoot.MRM.SOAPENV:Body.*[<];
     IF (FIELDNAME(R) = “foo”) ...
     
    Sobald der Inhalt bekannt ist, kann der Nachrichtenfluss entsprechend verzweigen (z. B. über einen Knoten 'Weiterleitung_an_Zieladresse', wobei jede Verzweigung über inhaltsspezifische Zuordnungs- und/oder Rechenknoten verfügt. Bei einfachen Nachrichtenflüssen kann die gesamte Logik bei Bedarf in einem einzigen Rechenknoten untergebracht werden.

    Rufen Sie jetzt das bestehende System auf (üblicherweise über WebSphere MQ), rufen Sie die erwartete Antwort ab, und geben Sie die Web-Service-Antwort weiter. Dies entspricht dem vorhergehenden Szenario (Broker implementiert neuen Web-Service - Details), außer dass der Datenfluss zusätzlich eine Zuordnung zwischen dem vom Web-Service-Client verwendeten Datenformat und dem Format, das von dem bestehenden, für WebSphere MQ aktivierten System verwendet wird, durchführen muss. Der Datenflussentwickler muss die Möglichkeit berücksichtigen, dass die Geschäftsanwendung die erwartete Antwort nicht innerhalb eines angemessenen Zeitraums sendet.

Zugehörige Konzepte
Web-Services, WSDL und Nachrichtenflüsse
Broker ruft bestehenden Web-Service auf
Broker implementiert neue Web-Service-Schnittstelle
Broker implementiert bestehende Web-Service-Schnittstelle
Broker implementiert Schnittstelle, die nicht auf Web-Service basiert, zu neuem Web-Service
Zugehörige Tasks
Broker implementiert bestehende Web-Service-Schnittstelle - Details
Broker ruft bestehenden Web-Service auf - Details
Bemerkungen | Marken | Downloads | Bibliothek | Unterstützung | Rückmeldung
Copyright IBM Corporation 1999, 2006 Letzte Aktualisierung: 23. Aug. 2006
ac34580_