Broker implementiert neuen Web-Service - Details

Dies ist ein Überblick über ein typisches End-to-End-Szenario, in dem der Broker einen Web-Service implementiert.

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.

Es gibt 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.

Der Web-Service muss eine Schnittstelle auf Basis der Operationen bieten, die bereits vom bestehenden System zugänglich gemacht wurden. Diese Schnittstelle kann alle bestehenden Operationen, eine Teilmenge davon und/oder kombinierte Operationen umfassen.

So definieren Sie die Schnittstelle:
  1. Schauen Sie sich die vom bestehenden System angebotene Geschäftsfunktion genau an.
  2. Wählen Sie die Teilmenge der Geschäftsfunktion aus, die zugänglich gemacht werden soll.
  3. Entscheiden Sie, wie diese Teilmenge in der Schnittstelle dargestellt werden soll (als viele diskrete Operationen oder wenige Mehrzweckoperationen).
Eine grundlegende Entscheidung besteht darin, ob die Web-Service-Schnittstelle dem RPC-Format (style=rpc) oder Dokumentformat (style=document) entsprechen soll. (Siehe Web-Services, WSDL und Nachrichtenflüsse und Beziehung zwischen WSDL-Definition und Nachrichtenmodell).
  • Eine Schnittstelle im RPC-Format wird im Allgemeinen entworfen, um sie einer zu Grunde liegenden Gruppe von Operationen, die von einer API zur Verfügung gestellt werden, zuzuordnen. Dabei enthalten die einzelnen Operationen (Methodenaufrufe) relativ wenig Nutzdaten.
  • Eine Schnittstelle im Dokumentformat besteht möglicherweise aus weniger Operationen, die jedoch mehr Nutzdaten enthalten, z. B. ein Dokument für einen Kreditantrag.
Die WS-I (siehe http://www.ws-i.org/) empfiehlt, nur WSDL im Dokumentformat zu verwenden. Allerdings verwenden viele ältere Web-Services das RPC-Format.

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 empfiehlt, die Web-Service-Nutzdaten durch Namespaces zu qualifizieren, so dass der Benutzer beim Importieren den Ziel-Namenspace angeben muss.

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

  2. Generieren Sie die WSDL-Definition. Sofern Sie die erforderlichen Nachrichtenkategorien noch nicht erstellt haben, erstellen Sie eine Nachrichtenkategorie für jede Web-Service-Operation, die zugänglich gemacht werden soll, und ordnen Sie die bestehenden Brokernachrichten den entsprechenden SOAP-Rollen (Eingabe, Ausgabe oder Fehler) zu. (Siehe Mit Nachrichtenkategoriedateien arbeiten.)
    • Wenn Sie sich für WSDL im Dokumentformat entscheiden, wird die Nachrichtengruppe selbst nicht geändert.
    • Wenn Sie sich für WSDL im RPC-Format entscheiden, werden Nachrichten, die der Anforderung und Antwort jeder einzelnen WSDL-Operation entsprechen, erstellt und automatisch zur Nachrichtengruppe hinzugefügt.
  3. Als Ergebnis der WSDL-Generierung werden die entsprechenden SOAP-Nachrichtendefinitionsdateien (MXSDs) automatisch in die Nachrichtengruppe eingeschlossen. Dies betrifft vor allem die MXSD mit der SOAP-Rahmenanweisung (Envelope) und, falls das WSDL-Format RPC-codiert ist, die MXSD mit der SOAP-Codierung.
  4. Wenn Sie einen neuen Web-Service-Client erstellen, verwenden Sie die generierte WSDL-Definition mit der von Ihnen ausgewählten Web-Service-Client-Technologie. Verwenden Sie dazu ein anderes Tool als WebSphere Message Broker, z. B. Rational Application Developer oder .NET.
  5. 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"
  6. 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.)

  7. Sie können eine Zuordnung von den zulässigen Nutzdatennachrichten zu den erforderlichen Nachrichten vom bestehenden System bereitstellen. Beispielsweise können Sie eine einzige Zuordnungsdefinition mit den Nachrichten Nachricht1a und Nachricht1b verwenden, in der beide Nachrichten demselben Ziel, nämlich Nachricht2, zugeordnet sind.
    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”) ...
     
    Da der Inhalt nun 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. Der Datenflussentwickler muss die Möglichkeit berücksichtigen, dass die Geschäftsanwendung die erwartete Antwort nicht innerhalb eines angemessenen Zeitraums sendet.

Ein ähnliches Szenario finden Sie im folgenden Beispiel: Beispielprogramm 'Web Service Host'.

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
ac34570_