UDDI - Universal Description Discovery and Integration: Grundlagen und Datenstrukturen

Inhaltsverzeichnis

WAS IST UDDI?
PROBLEMSTELLUNG
WOFÜR STEHT UDDI?
DESCRIPTION
DISCOVERY
INTEGRATION
ENTSTEHUNG
VORTEILE DER UDDI-REGISTRY

DIE UDDI BUSINESS REGISTRY
DIE UDDI BUSINESS REGISTRY OPERATORS
REGISTRARS
ÜBERBLICK: UDDI API IN DER UDDI BUSINESS REGISTRY
DAS PUBLICATION API
DAS INQUIRY API
BEISPIEL FÜR EINE INQUIRY-MESSAGE
DIE STANDARD-KLASSIFIZIERUNGSSYSTEME

GRUNDLEGENDE DATENSTRUKTUREN
DAS TMODEL-KONZEPT
ANWENDUNG
DIE DATENSTRUKTUR TMODEL
BEISPIEL FÜR TMODEL-DEFINITION – „NAICS“-KLASSIFIZIERUNGSSYSTEM
DIE BUSINESSENTITY-STRUKTUR
DIE BUSINESSSERVICE-STRUKTUR
DIE BINDINGTEMPLATE-STRUKTUR
UDDI V2: DIE PUBLISHERASSERTION-STRUKTUR

IDENTIFIER UND KATEGORIEN
DER IDENTIFIERBAG
DER CATEGORYBAG

DAS PUBLICATION API
AUTHENTIFIZIERUNG
DIE SAVE -OPERATIONEN
DIE DELETE -OPERATIONEN
SPEZIELLE OPERATIONEN , DIE A UTHENTIFIZIERUNG BENÖTIGEN

DAS INQUIRY API
DIE FIND -OPERATIONEN
DIE GET DETAIL -OPERATIONEN

PRIVATE UDDI REGISTRIES
WOZU EINE PRIVATE UDDI R EGISTRY ?
5 A NWENDUNGS -S ZENARIEN FÜR PRIVATE UDDI R EGISTRIES
E-MARKETPLACE
PORTAL UDDI
PARTNER CATALOG
EAI UDDI (INTERNAL ENTERPRISE APPLICATION INTEGRATION)
TEST UDDI

SOAP UND UDDI
SOAP F AULT -M ESSAGES

BEISPIEL-IMPLEMENTIERUNG

FAZIT

QUELLENANGABEN

ANHANG

Was ist UDDI?

UDDI ist die Bezeichnung für einen Typ von webbasierten Registries, die Informationen über Unternehmen oder Organisationen, sowie über die angebotenen Dienste zur Verfügung stellen. Bei diesen Diensten muss es sich nicht zwangsläufig um die so genannten „Web-Services“, d.h. Dienste, die über das Web bereitgestellt werden, handeln. Es kann praktisch jede Art von Dienst in einer solchen Registry abgelegt werden; allerdings wird die Nutzung von UDDI in Verbindung mit Web- Services das Haupt-Anwendungsgebiet sein.

UDDI definiert neben den Datenstrukturen zur Speicherung der Daten auch das Format von Zugriffs- Funktionen in zwei getrennten APIs (Inquiry API und Publication API).

Eine UDDI Registry besitzt immer einen (oder mehrere) Operator(s), die den Zugriff auf die Registry regeln, üblicherweise durch vorherige Registrierung des Nutzers.

Abbildung in dieser Leseprobe nicht enthalten

Die Nutzer einer UDDI Registry werden Service Provider und Service Requestor genannt. Der Service Provider legt die Beschreibung seiner Dienstangebote (z. B. WSDL) in der Registry ab (publish). Der Service Requestor sucht in der Registry nach passenden Angeboten (find). So wird die Integration von Diensten (bind) von Fremdanbietern vereinfacht.

Problemstellung

Die Definition von Datenstrukturen war das Hauptproblem bei der Definition der UDDI Registry. Sie muss Informationen zum Anbieter selbst (Kontaktinformationen), zur Klassifizierung des Anbieters und der angebotenen Dienste, sowie die Adresse zum Aufruf des Dienstes (bei Web-Services) und der zugehörigen Schnittstellenbeschreibung.

Zu jeder Registry gehören neben den Datenstrukturen aber auch die Zugriffsfunktionen zum Speichern, Suchen und Löschen in der Registry. Beim Speichern und Löschen müssen zudem die Berechtigungen des Benutzers überprüft werden. So kann ein Benutzer nur die Daten löschen, die er auch selber gespeichert hat. Eine Authentifizierungs-Methode muss definiert werden und es muss in den Datenstrukturen festgehalten werden, wem welche Daten gehören.

Um eine solche Registry sinnvoll nutzen zu können, ist die Definition von komplexen Suchfunktionen unerlässlich. Dazu gehören auch sinnvolle und erweiterbare Klassifizierungs-Systeme.

Wie UDDI diese Probleme löst, werde ich in den folgenden Kapiteln erläutern.

Wofür steht UDDI?

Die Abkürzung UDDI steht für Universal Description Discovery and Integration. Dieser Name zeigt auch schon die verschiedenen Aspekte, die von UDDI behandelt werden:

Description

„Description“ = Beschreibung. Unternehmen können sich und ihre Dienste mit den von UDDI bereitgestellten Datenstrukturen (businessEntity, businessService,...) beschreiben.

Discovery

„Discovery“ = Entdecken. UDDI definiert eine Schnittstelle zum Suchen in der Registry (find_business, ...) und ermöglicht die Klassifizierung von Unternehmen und Diensten. Das Suchen in der Registry kann manuell (über ein Web-Browser-Interface), aber auch, hier liegt die Stärke von UDDI im Gegensatz zu herkömmlichen Suchmaschinen, automatisch, d.h. mit Hilfe eines Programms, das das UDDI API benutzt, erfolgen.

Integration

Integration bedeutet in diesem Fall die Integration von Diensten Fremdanbieter in den eigenen Geschäftsprozess. Diese Integration kann zur Laufzeit erfolgen („dynamic bind“). In diesem Fall würde ein Programm in der Registry selbstständig einen passenden Anbieter suchen und dessen Dienst aufrufen. Ein mögliches Szenario hierfür wäre eine automatische Preisabfrage, die den günstigsten Anbieter eines bestimmten Dienstes auswählt.

Die automatische Integration von Diensten kann aber nur erfolgen, wenn bestimmte Standards festgelegt sind, die von allen in der Registry registrierten Dienstanbietern anerkannt werden. Denn das Programm, das in der Registry sucht, muss das Format und die Bedeutung des angebotenen Dienstes vorher kennen.

Entstehung

UDDI ist das Projekt eines Firmen-Konsortiums (uddi.org), unter Beteiligung großer Unternehmen, z.B. Microsoft, IBM und Ariba). Es wurde im September 2000 ins Leben gerufen. Das Ziel dieses Projektes war, ausgehend von den bestehenden Standards (HTTP, XML und SOAP) die Geschäftsabwicklung über das Internet zu vereinfachen und zu standardisieren.

Die erste Implementierung einer UDDI Registry ging im Mai 2001 ans Netz. Sie existiert auch heute noch unter dem Namen „UDDI Business Registry“.

Die erste Definition von UDDI (UDDI V1) stammt von 30. September 2000. Es gibt mittlerweile auch schon die zweite Version (UDDI V2) vom 8. Juni 2001, die einige Verbesserungen in der Suchfunktionalität und eine neue Datenstruktur enthält.

Heute sind ca. 310 Unternehmen am UDDI Projekt beteiligt.

Am 3. Juli 2002 erschien die dritte Version UDDI V3. Unter Anderem werden jetzt digitale Signaturen für die Daten, erweiterte Authentifizierungs-Mechanismen und zusätzliche Such- und Klassifizierungsmöglichkeiten unterstützt. Auf die Neuerungen von V3 werde ich im Folgenden nicht eingehen, da dies den Rahmen dieser Arbeit sprengen würde, sie sind aber in dem Dokument http://www.uddi.org/pubs/uddi_v3_features.htm zusammengefasst.

Vorteile der UDDI-Registry

Die UDDI Registry hat klare Vorteile gegenüber herkömmlichen Suchmaschinen und Portalen. Es ist nun möglich das Ergebnis einer Suchanfrage maschinell weiterverarbeiten zu lassen.

Immer mehr Unternehmen aus aller Welt bieten ähnliche Dienste über das Web an. Es ist nicht immer einfach aus dieser Menge von Anbietern den Richtigen herauszufinden. UDDI vereinfacht zu dem die Kontaktaufnahme mit neuen Geschäftspartnern, da diese über einen standardisierten Weg erfolgen kann. Die Integration von externen Diensten in den eigenen Geschäftsprozess wird erleichtert. Das steigert die Effizienz und führt zu Kostenersparnis. So fördert UDDI den E-Commerce (vor allem den B2B-Bereich).

Ein weiterer wichtiger Vorteil ist die Plattformunabhängigkeit. Wenn die Service Provider und Service Requestors aus verschiedenen Teilen der Welt kommen, muss dennoch sichergestellt werden, dass die UDDI Registry von jedem genutzt werden kann. UDDI erreicht das, indem es sich auf standardisierte Internet-Technologie (HTTP, XML und SOAP) stützt.

Die UDDI Business Registry

Mit „UDDI Business Registry“ wird die erste Implementierung der UDDI Registry bezeichnet. In dieser Registry darf jeder ohne Zugangsbeschränkung suchen. Nach Registrierung bei einem der UDDI Business Registry-Operators kann auch jeder dort seine Dienste anbieten.

Die UDDI Business Registry Operators

Jeder dieser Operatoren betreibt einen Server, auf dem eine Kopie der Business Registry liegt. Er stellt die spezifizierten Zugriffsfunktionen zur Verfügung und regelt den Zugriff auf die Registry. Damit die Kopien auf den unterschiedlichen Servern zu jeder Zeit identisch sind, definiert UDDI einen Standard für die Replikation der UDDI Datenbanken. Dieser ist in http://www.uddi.org/pubs/Replication-V2.00-Open-20010608.pdf beschrieben.

Zurzeit gibt es 2 Business Registry Operators (IBM und Microsoft), aber auch HP und SAP werden bald dazu gehören.

Registrars

Mit „Registrars“ werden Unternehmen bezeichnet, die für andere Unternehmen die Registrierung in der UDDI Business Registry übernehmen.

Überblick: UDDI API in der UDDI Business Registry

Die UDDI-Operationen sind als SOAP Messages definiert. Im Body dieser SOAP-Messages werden die Daten oder Funktionsaufrufe als XML-Dokumente übermittelt. Bei Fehlern werden SOAP Fault- Messages zurückgeschickt.

Grundsätzlich kann man zwei verschiedene UDDI APIs unterscheiden: Das Publication API und das Inquiry API.

Das Publication API

Das Publication API ermöglicht das Hinzufügen, Ändern und Löschen von Daten in der UDDI Registry. Um Funktionen dieses APIs zu nutzen muss der Benutzer sich zuerst authentifizieren. Die gesamte Kommunikation läuft über HTTPS.

Das Inquiry API

Das Inquiry API ermöglicht das Durchsuchen der UDDI Registry. Bei der UDDI Business Registry besteht keine Zugangskontrolle und die Kommunikation läuft über HTTP.

Beispiel für eine Inquiry-Message

Abbildung in dieser Leseprobe nicht enthalten

Der Benutzer schickt an den Host www.uddioperator.com den Funktionsaufruf find_business. Im XML-Dokument werden die Suchkriterien angegeben. Diese habe ich aus Gründen der Übersichtlichkeit weggelassen. Auf das genaue Format der Funktionsaufrufe werde ich in den folgenden Kapiteln eingehen.

Die Standard-Klassifizierungssysteme

UDDI definiert 3 Standard-Klassifizierungssysteme zur Klassifizierung von Unternehmen und Diensten: NAICS (North American Industry Classification System), UNSPC (Universal Standard Products and Service Classification) und ISO 3166 (geographische Klassifizierung).

Das ist nicht gerade viel, es ist aber möglich, eigene, z.B. spartenspezifische Klassifizierungssysteme zu definieren.

Grundlegende Datenstrukturen

Das tModel-Konzept

tModels in einer UDDI Registry sind abstrakte Beschreibungen von Service-Typen oder Klassifizierungssystemen. Jeder kann eigene tModels definieren, die dann von jedem referenziert werden können. Die tModels beinhalten selbst keine konkrete Spezifikation, sie verweisen lediglich auf solche Dokumente (z.B. WSDL).

tModels können selber in Kategorien eingeteilt werden. So kann zum Beispiel festgelegt werden, dass es sich bei einem tModel um die Repräsentation einer WSDL-Beschreibung eines Web-Services handelt. UDDI definiert ein Wurzel-tModel und einige Sub-Kategorien (z.B. categorization, specification oder soapSpec), unter denen alle anderen neuen tModels einsortiert werden können. Dadurch ergibt sich eine hierarchische Struktur innerhalb aller definierten tModels, was bei der Suche nach bestimmten tModels sehr hilfreich ist.

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Graham, Simeonov u. A. (2002), „Building Web Services with Java“, S. 415

Anwendung

tModels können auch als „technical fingerprint“ bezeichnet werden. Sie repräsentieren Übereinkünfte für die Form von angebotenen Diensten. Ein Beispiel hierfür wäre folgendes Szenario: Ein Unternehmen hat sich eine neue Software für die Geschäftsabwicklung über das Internet gekauft. Nun sucht es nach möglichen Geschäftspartnern, die ebenfalls diese Software nutzen. Der Hersteller dieser E-Commerce-Software hat in der UDDI-Registry ein tModel, das seine Software repräsentiert, registriert. Alle Unternehmen, die diese Software nutzen, haben dieses tModel bei der Registrierung ihre Services angegeben. So können schnell alle möglichen Geschäftspartner gefunden werden.

Eine andere Anwendungsmöglichkeit wäre die Definitionen von zusätzlichen Klassifizierungssystemen. So könnten zum Beispiel die Yahoo!-Kategorien als tModel definiert werden. Die angebotenen Dienste könnten jetzt auch nach diesem Klassifizierungssystem eingeordnet werden. Wie das genau funktioniert werde ich im Kapitel „Identifier und Kategorien“ erläutern.

Die Datenstruktur tModel

Abbildung in dieser Leseprobe nicht enthalten¹

Quelle: Graham, Simeonov u. A. (2002), „Building Web Services with Java“, S. 405

Jede Datenstruktur hat in UDDI einen eindeutigen Key, damit sie eindeutig referenziert werden kann. Hier ist das der „tModelKey“. Als Attribut wird auch der Benutzername, der es registriert hat als Attribut festgehalten. So kann später festgestellt werden, wer der „Besitzer“ dieser Datenstruktur ist und somit die Berechtigung zum Löschen hat.

Jedes tModel hat einen Namen und optional eine oder mehrere Beschreibung(en). Das optionale

„overviewDoc“ verweist auf die konkrete Spezifikation. Es kann eine URL angegeben werden, an der das Spezifikations-Dokument abgerufen werden kann.

Mit Hilfe des identifierBag und des categoryBag kann das tModel in die tModel-Hierarchie eingeordnet werden. Mehr dazu im Kapitel „Identifier und Kategorien“.

[...]

¹ Die abgerundeten Rechtecke stehen für Attribute, die eckigen für Felder oder Container.