Abfrage-API für die UDDI-Registry der Version 3

Die Abfrage-API (Inquiry) unterstützt vier Arten von Abfragen, die weitestgehend den Konventionen folgen, die den Anforderungen von Software entsprechen, die traditionell in Registrys verwendet wird.

Die vier Abfrageformen sind:
  • Suchmuster,
  • Drilldown-Muster,
  • Aufrufmuster,
  • Funktionen der Inquiry-API.

Suchmuster für die UDDI-Registry

Software, die die Möglichkeit bietet, Daten, insbesondere hierarchisch organisierte Daten, zu durchsuchen und zu untersuchen, benötigt Anzeigefunktionen. Das Suchmuster ist normalerweise so aufgebaut, dass zunächst allgemeine Informationen gegeben, Suchvorgänge durchgeführt, allgemeine Ergebnismengen bereitgestellt und dann spezifischere Informationen für das Drilldown-Muster ausgewählt werden.

Laut den Spezifikationen der UDDI-API wird das Suchmuster durch API-Aufrufe des Typs find_xx aktiviert. Diese Aufrufe sind die von der API bereitgestellten Suchfunktionen. Diese Aufrufe werden mit den zusammenfassenden Antwortnachrichten, die Informationen in Form von Übersichten bereitstellen, abgeglichen. Die Informationen beziehen sich auf registrierte Daten, die dem Typ der Anforderungsnachricht und den in der Anforderung angegebenen Suchkriterien zugeordnet sind.

Bei einer typischen Anzeigefolge wird z. B. geprüft, ob Informationen für ein Ihnen bekanntes Geschäft registriert sind. Diese Folge beginnt mit dem Aufruf von "find_business" und übergibt vielleicht die ersten Zeichens eines Geschäftsnamens, den Sie kennen. Diese Aktion gibt ein Ergebnis vom Typ "businessList" zurück. Diese Liste enthält Informationen in Form einer Übersicht, einschließlich Schlüsseln, Namen und Beschreibungen, die von den registrierten businessEntity-Daten abgeleitet sind und mit dem angegebenen Namensfragment übereinstimmen. Wenn das gesuchte Geschäft in der Liste aufgeführt ist, können Sie den API-Aufruf "find_service" verwenden, um die entsprechenden businessService-Informationen strukturiert anzuzeigen und nach bestimmten technischen Modellen, z. B. Kauf oder Lieferung, zu suchen. Wenn Sie den technischen Fingerabdruck (tModel-Signatur) einer bestimmten Softwareschnittstelle kennen und prüfen möchten, ob das ausgewählte Geschäft diese Schnittstelle unterstützt, können Sie die Nachricht der Inquiry-Funktion "find_binding" verwenden.

Drilldown-Muster für die die UDDI-Registry

Wenn Sie einen Schlüssel für einen der vier hauptsächlich von einer UDDI-Registry verwalteten Datentypen haben, können Sie mit diesem Schlüssel auf die vollständigen, registrierten Einzeldaten für eine bestimmte Dateninstanz zugreifen. Die UDDI-Datentypen sind businessEntity, businessService, bindingTemplate und tModel. Sie können auf die vollständigen, registrierten Informationen für eine dieser Strukturen zugreifen, indem Sie einen relevanten Schlüsseltyp an einen der get_xx-API-Aufrufe übergeben.

Wenn wird das Beispiel aus dem vorherigen Abschnitt weiter verwenden, sind die Schlüsseldaten ein Datenelement, das von allen find_x-Rückgabesätzen zurückgegeben wird. Für das Business, an dem Sie interessiert sind, kann der businessKey-Wert, der im Inhalt einer businessList-Struktur zurückgegeben wird, als Argument an die get_businessDetail-Nachricht übergeben werden. Die erfolgreiche Rückgabe an diese Nachricht ist eine businessDetail-Nachricht, die die vollständigen registrierten Informationen für die Entität mit dem übergebenen Schlüsselwert enthält. Diese Informationen sind eine vollständige businessEntity-Struktur.

Aufrufmuster für die UDDI-Registry

Damit eine Anwendung einen fernen Web-Service nutzen kann, der von anderen Geschäften oder Entitäten in der UDDI-Registry registriert wurde, müssen Sie die Anwendung so konfigurieren, dass sie die in der Registry gefundenen Informationen für den aufzurufenden Service verwendet.

Die bindingTemplate-Daten, die aus der UDDI-Registry abgerufen werden, stellen die spezifischen Details über eine Instanz eines bestimmten Schnittstellentyps dar, einschließlich der Position, an der ein Programm mit der Interaktion mit dem Service beginnt. Die aufrufende Anwendung bzw. das aufrufende Programm speichert diese Informationen im Cache und verwendet sie, um eine Verbindung zum Service an der registrierten Adresse herzustellen, wenn die aufrufende Anwendung mit der Serviceinstanz kommunizieren muss.

In den bisher gängigen Technologien mit fernen Prozeduren automatisieren Tools die Tasks, die mit dem Caching oder mit der festen Codierung von Positionsinformationen in Verbindung stehen. Es treten jedoch Probleme auf, wenn ein ferner Service verschoben wird, und die aufrufenden Anwendungen oder Programme darüber nicht informiert werden. Für das Verschieben eines Service kann es viele Gründe geben, z. B. ein Serverupgrade, eine Wiederherstellung nach einem Katastrophenfall, eine Serviceübernahme oder eine Anpassung an den Geschäftsnamen.

Wenn ein Aufruf fehlschlägt, während er zwischengespeicherte Informationen, die zuvor von einer UDDI-Registry abgerufen wurden, verwendet, besteht das richtige Verhalten darin, die aktuellen bindingTemplate-Informationen von der UDDI-Registry abzufragen. Wenn sich die zurückgegebenen Daten von den zwischengespeicherten Daten unterscheiden, kann der Serviceaufruf den Aufruf unter Verwendung der aktualisierten Informationen automatisch wiederholen. Wenn das Ergebnis dieser Wiederholung positiv ist, werden die zwischengespeicherten Informationen durch die neuen Informationen ersetzt.

Mit der Verwendung dieses Musters für Web-Services kann ein Geschäft, das eine UDDI-Registry verwendet, die Wiederherstellung einer hohen Anzahl von Partnern ohne unnötige Kommunikations- und Koordinationskosten automatisieren. Wenn ein Geschäft beispielsweise einen Standort für Wiederherstellung aktiviert, schlagen die meisten Aufrufe von Partnern fehl, wenn sie versuchen, Services am ausgefallenen Standort aufzurufen. Durch die Aktualisierung der UDDI-Informationen mit der neuen Serviceadresse, finden die Partner, die das Aufrufmuster verwenden, die neuen Serviceinformationen automatisch und sind ohne administratives Eingreifen wiederhergestellt.


Symbol, das den Typ des Artikels anzeigt. Konzeptartikel



Symbol für Zeitmarke Letzte Aktualisierung: 25.05.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cwsu_inquiry_api
Dateiname:cwsu_inquiry_api.html