Universal Description, Discovery and Integration
11.5.2 Universal Description, Discovery and Integration (UDDI)

UDDI kann als "Meta-Dienst" verstanden werden, der das Auffinden von Web-Services im Internet ermöglicht. Neben den Nutzern und den Anbietern von Diensten werden dabei als zusätzliche Instanzen so genannte UDDI-Registries (Registrierungsstellen) betrachtet. Obwohl UDDI insbesondere auf die Unterstützung einer SOAP-basierten Kommunikation zwischen Computerprogrammen zielt, ist es im Prinzip von SOAP unabhängig. Zum Beispiel können mit UDDI auch Dienste beschrieben werden, die über ein konventionelles Telefongespräch realisiert werden.

UDDI geht ursprünglich auf eine Initiative von IBM, Microsoft und Ariba zurück und wird mittlerweile von rund 220 Unternehmen weltweit unterstützt. Um dem Standard zu weiterer Popularität zu verhelfen und ausreichende Herstellerunabhängigkeit zu gewährleisten, wurde die Weiterentwicklung und Pflege im Juli 2002 an die Organization for the Advancement of Structured Information Standards ( OASIS) übertragen. Zum gleichen Zeitpunkt wurde Version 3 der UDDI-Spezifikation veröffentlicht, auf die sich die folgende Betrachtung stützt.

Die UDDI-Spezifikation legt unter anderem folgendes fest:

  • Ein XML-basiertes Format zur Beschreibung von Web-Services und ihren Anbietern in UDDI-Registries.

  • Etwa 30 SOAP-Nachrichten zur Kommunikation von Dienstanbietern und -suchenden mit UDDI-Registries.

Konzeptuell können die Web-Service-Beschreibungen in UDDI-Registries in drei Teile gegliedert werden:

  • White Pages ("Weiße Seiten") enthalten allgemeine Informationen zu einem Unternehmen (z. B. mehrsprachige Firmenbeschreibung, Kontaktinformationen usw.).

  • Yellow Pages ("Gelbe Seiten") beschreiben die Branchen und angebotenen Dienste kategorisiert nach inhaltlichen Kriterien (z. B. Verkauf von Autoteilen).

  • Green Pages ("Grüne Seiten") enthalten technische Informationen zur Verwendung der Web-Services eines Unternehmens (z. B. URI, Methodennamen, Anzahl und Typ der Parameter).

Abbildung 11.6 zeigt den schematischen Aufbau eines UDDI-Dokuments.

Grafik 11.6

Abbildung 11.6: Aufbau von Einträgen in UDDI-Registries

Konkret stellt UDDI vier Datenstrukturen zur Beschreibung von Web-Services bereit:

  • Der Elementtyp businessEntity definiert allgemeine Informationen über das Unternehmen, die den White Pages und Yellow Pages zuzurechnen sind. Ein Verkäufer von Autoteilen könnte sich hier z. B. innerhalb eines Elements categoryBag als Attributwert für das Attribut keyValue den Code 441310 verwenden, der im North American Industry Classification System ( NAICS) die Bedeutung "Automotive Parts and Accessories Stores" hat.

  • Der Elementtyp businessService beschreibt die angebotenen Dienste mit einem innerhalb der Registrierungsstelle eindeutigen Schlüssel (serviceKey), dem vollen Namen des Dienstes sowie optional einer für Menschen verständlichen Beschreibung.

  • Der Elementtyp bindingTemplate beschreibt die technische Information zum Aufruf eines Dienstes (Green Pages). Für die Abbildung auf SOAP kann dies z. B. durch die Angabe von WSDL-Elementen erfolgen. Im Prinzip ist UDDI aber unabhängig von WSDL, so dass auch alternative Möglichkeiten zur Beschreibung des Dienstzugangspunkts bereit gestellt werden.

  • Der Elementtyp tModel enthält Metadaten über die Implementierung des Dienstes. Hier könnten zum Beispiel benutzte Spezifikationen und erfüllte Normen beschrieben werden. Insbesondere können hier auch inhaltliche, den Yellow Pages zuzurechnende Informationen über den Dienst aufgenommen werden. Zum Beispiel identifiziert der "tModelKey" uuid:68DE9E80-AD09-469D-8A37-088422BFBC36 das tModel "uddi-org:http", das als "http or web browser based web service" beschrieben ist.

UDDI und WSDL sind formal unabhängig voneinander, können aber gemeinsam benutzt werden: Der Eintrag im Feld tModel von einer UDDI-Beschreibung könnte z. B. auf eine abstrakte WSDL-Beschreibung eines Dienstes hinweisen, während der Eintrag im Element bindingTemplate auf dessen konkrete WSDL-Beschreibung verweist.

Neben den Datenstrukturen zur Beschreibung von Unternehmen und angebotenen Diensten definiert UDDI zwei XML-basierte APIs zur Kommunikation mit UDDI-Registries: Das Publish-API (Programmierschnittstelle für das Veröffentlichen von Dienstbeschreibungen) legt einen Satz von SOAP-Nachrichten fest, mit welchen ein Anbieter Informationen in der Registrierungsstelle veröffentlichen oder auch wieder löschen kann. Dazu gehören etwa Methoden wie save_business, save_service, save_binding und save_tModel zum Speichern der entsprechenden UDDI-Datenstrukturen und entsprechend delete_business, delete_service, delete_binding, delete_tModel zum Löschen der Informationen. Darüber hinaus enthält das Publish-API Antworten der Registrierungsstelle über die erfolgreiche oder fehlerhafte Verarbeitung der Nachricht. Das Inquiry-API (Programmierschnittstelle für das Abfragen von Dienstbeschreibungen) definiert SOAP-Nachrichten, die einem Nutzer das Auffinden von Diensten ermöglichen (z. B. find_business, find_service) sowie detaillierte Informationen über deren Verwendung liefern (z. B. get_businessDetail, get_serviceDetail usw.).

UDDI befindet sich als Spezifikation noch in der Entwicklung und wird stetig fortgeschrieben. Durch die Übertragung der Verantwortlichkeit des Standardisierungsprozesses an OASIS ist zu erwarten, dass sich UDDI als Registrierungsformat weiter verbreiten wird.

Mit UDDI Version 3.0 wird auch eine dezentrale Datenhaltung durch die Interaktion verschiedener UDDI-Registries ermöglicht. Hierzu werden in der Spezifikation Verfahren für den Datenabgleich verschiedener Registrierungsstellen definiert und die Eindeutigkeit der Einträge durch die Beschreibung eines Schlüsselgenerierungsverfahrens auf der Basis von DNS-Namen (z. B. uddi:firma.com:abteilung) sichergestellt. Bis UDDI 3.0 war nur eine einzige zentrale Registrierungsstelle, die UDDI Business Registry (UBR), vorgesehen. Durch den dezentralen Ansatz von UDDI 3.0 können jetzt auch kleinere, firmeninterne Registrierungsstellen geschaffen werden, wobei für den weltweiten Abgleich der unterschiedlichen Registries ein hierarchisches Modell mit der UBR als Wurzelknoten vorgesehen ist.

Ein wichtiger Aspekt ist auch die Gewährleistung der Datensicherheit und der Schutz vor Manipulationen der Firmeneinträge. Hier greift UDDI 3.0 auf die W3C-Empfehlung XML Signature zurück, die im Februar 2002 veröffentlicht wurde. Öffentliche UDDI-Registries werden derzeit z. B. von Microsoft, Hewlett-Packard, IBM und SAP unterhalten. Im Rahmen von ebXML, auf das wir in der nächsten Lerneinheit näher eingehen, werden z. T. ähnliche Zielsetzungen wie in UDDI verfolgt. SUN stellt mit JAXR (Java API for XML Registries) ein Java-API bereit, das die Interaktion mit UDDI, ebXML und anderen Registries ermöglichen soll.