Implementierung einer bestehenden Web-Service-Schnittstelle durch den Broker

Informieren Sie sich über ein typisches 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 (Implementierung eines neuen Web-Services durch den Broker) 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 zugrunde liegende Implementierung und verpackt anschließend die Rückgabewerte als WebSphere MQ-Antwort. Die Datenstrukturen, die an diese bestehenden Operationen geliefert und von diesen zurückgegeben werden, sind in einer C-Headerdatei oder einem COBOL-Copybook definiert.

In diesem Beispiel ist das, was der Web-Service bereitstellen muss, jedoch eingeschränkt, da die WSDL-Definition für den Web-Service-Client bereits vorhanden ist.

Bei einem möglichen Szenario könnte 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 Web Services Interoperability Organization (WS-I) empfiehlt, die Web-Service-Nutzdaten durch Namespaces zu qualifizieren, deshalb sollte der Benutzer beim Importieren den Ziel-Namespace angeben.

    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 mithilfe des ESQL-Editors 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 (MXSD-Dateien) automatisch in die Nachrichtengruppe eingeschlossen. Der Import betrifft vor allem die MXSD-Datei mit der SOAP-Rahmenanweisung und, falls erforderlich, die MXSD-Datei 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 WebSphere MQ, abhängig von der vom Client verwendeten Transportmethode. Der Empfangsknoten hat folgende Merkmale:
    • Nachrichtendomäne: MRM
    • Nachrichtengruppe: die Nachrichtengruppe mit der Definition der SOAP-Rahmenanweisung
    • Nachrichtentyp: Envelope
    • Nachrichtenformat: XML1
  5. Nach dem Aufruf durch den Nachrichtenfluss erstellt der Parser eine logische Baumstruktur, einschließlich der SOAP-Rahmenanweisung, so wie sie durch die bereitgestellte SOAP-Nachrichtendefinitionsdatei (MXSD-Datei) 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 Sie die Zuordnung erst anwenden können, wenn Sie ermittelt haben, welche Nutzdaten Sie empfangen haben. Sie können folgenden ESQL-Code verwenden:
     
     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") ...
     
    Wenn der Inhalt bekannt ist, kann sich der Nachrichtenfluss entsprechend verzweigen (z. B. durch Verwendung eines RouteToLabel-Knotens), wobei jeder Zweig über inhaltsspezifische Mapping-Knoten und/oder Compute-Knoten verfügt. Bei einfachen Nachrichtenflüssen können Sie die gesamte Logik bei Bedarf in einem einzelnen Compute-Knoten codieren.

    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. Dieses Szenario ähnelt dem unter Implementierung eines neuen Web-Services durch den Broker beschriebenen Szenario, außer dass der Nachrichtenfluss 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 Nachrichtenflussentwickler muss die Möglichkeit berücksichtigen, dass die Geschäftsanwendung die erwartete Antwort nicht innerhalb eines angemessenen Zeitraums sendet.

Zugehörige Konzepte
Nachrichtenflüsse bei der XML-Domäne
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, in neuem Web-Service
Zugehörige Tasks
Implementierung einer bestehenden Web-Service-Schnittstelle durch den Broker
Broker ruft bestehenden Web-Service auf - Details
Bemerkungen | Marken | Downloads | Bibliothek | Unterstützung | Feedback

Copyright IBM Corporation 1999, 2009Copyright IBM Corporation 1999, 2009.
Letzte Aktualisierung : 2009-02-17 15:28:30

ac34580_