Wenn von einem Unternehmen Web Services als Dienst öffentlich angeboten werden, ist es wichtig, dass andere Unternehmen diese auch finden. Ist ein Web Service mittels WSDL definiert, muss er daher veröffentlicht werden. Dieser Vorgang kann mit dem Eintrag in eine Übersichtsliste verglichen werden. Ein Beispiel aus der Nicht-Computerwelt sind die „Gelben Seiten“ des Branchentelefonbuchs.
Im IT-Umfeld nennen sich die „Gelben Seiten“ Verzeichnisdienste, bei der SOA sind sie eine zentrale Komponente der Architektur. Sie ermöglichen erst die lose Kopplung von Diensten. Damit lassen sich Services dynamisch suchen, finden und verwenden.
Ein Verzeichnisdienst als zentrale Anlaufstelle zur Suche von Diensten ist immer dann unabdingbar, wenn eine SOA mehr als nur eine kleine Anzahl von Diensten umfassen soll. Er ermöglicht durch standardisierte Schnittstellen und entsprechende interne Datenstrukturen eine strukturierte Suche nach einem passenden Dienst.
Für Web Services gibt es gleich mehrere Standards, die sich dieser Aufgabe annehmen. Zu diesen gehören die neuere „Web Services Inspection Language“ (WS-Inspection) und „Universal Description, Discovery and Integration“ (UDDI). WS-Inspection hat bislang noch keine große Bedeutung, so dass wir diesen Standard nur kurz abhandeln werden. Ausführlicher gehen wir hingegen auf das populärere UDDI ein. Dieser Standard stellt neben SOAP und WSDL die dritte Technologiesäule im Umfeld von Web Services dar.
|
Teil 1 |
|
|
Teil 2 |
|
|
Teil 3 |
|
|
Teil 4 |
|
|
Teil 5 |
|
|
Teil 6 (in Planung) |
Web Services und Sicherheit |
WS-Inspection - Web Services Inspection Language
WS-Inspection (WS-I) ist ein im Vergleich zu UDDI einfaches Konzept zum Finden von Web Services. Beide Verfahren unterscheiden sich grundsätzlich. So setzt UDDI auf wenige, zentralisierte Verzeichnisse, in denen verschiedene Service-Anbieter ihre Dienste publizieren. Im Gegensatz dazu arbeitet WS-I mit vielen dezentralen, kleinen Verzeichnissen, in denen nur einer oder wenige Anbieter ihre Dienste veröffentlichen.
Mit seinem Konzept versucht WS-I eine der Hauptschwierigkeiten von UDDI zu umgehen: Die ungenügende Moderation der Verzeichnisse und die damit verbundenen schlechten Suchergebnisse. WS-I erlaubt es zudem, Dienste nur bei Anbietern zu suchen, die als vertrauenswürdig gelten.
Technisch betrachtet ist WS-I dokumentenbasiert. Das bedeutet, dass auf der Website des Anbieters ein Dokument von vordefinierten Namen bereit liegt. Dieses Dokument enthält die Informationen über die angebotenen Dienste. Nutzer rufen das Dokument via HTTP-Protokoll auf; sie erhalten dann eine Liste der Web Services und eine Beschreibung im WSDL-Format.
Aufbau von WS-I
Die Abbildung unten zeigt den Aufbau eines möglichen WS-I Dokumentes, das auf einem Webserver abgelegt ist. Es kann mehrere Referenzen auf Dienstbeschreibungen enthalten, etwa alle Webservices eines Providers. Das Dokument kann auch eine Referenz auf ein anderes WS-I Dokument in einem anderen Verzeichnis enthalten. Der Provider kann so seine Webservices strukturieren. Er kann Verzeichnisse für verschiedene Arten der Webservices anlegen. So kann eine Verzeichnisstruktur aufgebaut werden, die eine bessere Übersicht über das Angebot von Webservices erlaubt.
Veröffentlicht werden WS-I-Dokumente im Basisverzeichnis des Unternehmens-Webservers. Die genauen Regeln für das Auffinden der WS-I-Dateien legt die WS-I-Spezifikation (http://www-128.ibm.com/developerworks/library/specification/ws-wsilspec/) fest, die von IBM und Microsoft entwickelt wurde. Obwohl die Version 1.0 im November 2001 veröffentlicht wurde, hat sich WS-I noch nicht durchgesetzt.
UDDI - Universal Description, Discovery and Integration
UDDI besitzt im Gegensatz zu WS-I definierte Schnittstellen für Suche, Verwaltung und Replikation – ein Vorteil, der vor allem bei größeren Verzeichnissen von großem Wert ist.
Plakativ gesagt ermöglicht UDDI das Veröffentlichen und Auffinden eines Web Services im Internet. UDDI ist dabei wie ein großes Verzeichnis zu verstehen, in dem Web Services aufbewahrt werden. Hierzu stellt der Web Service Anbieter die WSDL-Beschreibung seines Dienstes in das UDDI-Verzeichnis ein. Ein Interessent kann diesen Dienst im Verzeichnis finden und die Schnittstellenbeschreibung in Form des WSDL-Dokumentes anfordern.
Am besten versteht man die Grundlagen von UDDI über die Telefonbuch-Metapher. Das Telefonbuch entspricht dabei einer der vier Haupttabellen im UDDI-Verzeichnis. UDDI ist dabei in folgende vier Kategorien unterteil:
-
White Pages („Telefonbuch“): Die White Pages beinhalten Informationen zu den Serviceanbietern: Kontaktinformationen und Beschreibungen zur Organisation, die einen Web Service in ein UDDI-Verzeichnis einstellt. Ein anschauliches Beispiel hierfür ist die Site www.whitepages.com.
-
Yellow Pages („Gelbe Seiten“): Die Yellow Pages kategorisieren Services in Geschäftsfelder. Mit den Yellow Pages erhält man die Dienste aller Anbieter, sortiert nach Branchen (Geschäftsfeldern). Ein anschauliches Beispiel hierfür ist die Site www.yellowpages.com.
-
Green Pages: Die Green Pages geben menschenlesbare Informationen über die angebotenen Dienste. Weiß ein Interessent, welchen Service er benötigt, aber kennt er den Anbieter nicht und weiß er auch nicht, zu welcher Branche er gehört, kann er jeden Service von Hand durchsuchen.
-
Service Type Registration: Die Service Type Registration ist das maschinenlesbare Pendant zu den Green Pages, welche primär für den menschlichen Nutzer gedacht sind.
Es gibt somit zwei Arten von Nutzern von UDDI: Mensch und Maschine. Aus diesem Grund bietet ein Provider im Normalfall zwei verschiedene Zugänge zu UDDI an. Zutritte für den menschlichen User werden dabei in vielen Fällen mit einer webbasierten Anwendung entwickelt.
Der maschinenorientierte Zugang ist für Applikationen gedacht, die automatisiert Dienste finden möchten. Die notwendigen Schnittstellen-Informationen werden dabei über die WSDL-Datei gegeben.
UDDI-Beispielszenarios
Bevor wir auf die technischen Details von UDDI eingehen, sollen zwei Beispielszenarios die Rolle von UDDI anschaulich verdeutlichen.
Beispiel 1
Ein Finanzdienstleistungsunternehmen möchte einen Web Service für die Abfrage von aktuellen Aktienkursen anbieten. Mit Hilfe von WSDL wird dieser Dienst, der beim Anbieter etwa in Visual Basic auf einem Windows-Rechner implementiert ist, genau beschrieben und in einem UDDI-Verzeichnis veröffentlicht.
Ein Portal-Betreiber, der im Rahmen seines Portals auch die Möglichkeit zur Aktienkursabfrage anbieten möchte, kann nun über das UDDI-Verzeichnis einen entsprechenden Service suchen und dann in sein Portal, das zum Beispiel mit Java unter Linux realisiert ist, einbinden.
Die komplette Anwendungslogik verbleibt dabei beim Web Service Anbieter, Anfragen an den Service über das Portal werden über SOAP direkt an den Web Service beim Anbieter weitergeleitet. Durch die standardisierten Schnittstellenbeschreibungen in WSDL und das Kommunikationsprotokoll SOAP wird eine plattform- und programmiersprachenunabhängige Anwendungsintegration ermöglicht.
Beispiel 2
Ein Temperaturdienst soll zu einem vom Benutzer vorgegebenen Zeitpunkt die Temperatur zurückliefern, die an einem bestimmten Temperatursensor in der Stadt München gemessen wurde. Hat der Dienst für den geforderten Zeitpunkt keine Messdaten zur Verfügung, liefert er die Temperatur zum nächstgelegenen Zeitpunkt, zu dem ein Messwert existiert. Weitere Dienste sind Temperatur-Einheiten-Umrechner.
Die Abbildung unten gibt einen Überblick über alle nötigen Aktionen, um einen Web Service zur Verfügung zu stellen und diesen zu nutzen. Ein Dienstanbieter muss seine Dienste (im Bild Web Service A und Web Service B) bei einem UDDI-Verzeichnisdienst registrieren, um die Informationen verfügbar zu machen, welche Dienste er anbietet und wie man diese ansprechen kann. Wie die Kommunikation mit den Diensten aussehen muss, ist dabei in WSDL-Dokumenten beschrieben, die nicht im UDDI-Verzeichnis selbst, sondern „irgendwo“ im Internet gespeichert sind. Will nun ein Client einen Dienst nutzen, sucht er sich einen für seine Zwecke geeigneten Dienst aus dem UDDI-Verzeichnis aus.
Nach der Auswahl eines Dienstes - in der Abbildung Web Service B - wird das zugehörige WSDL-Dokument geladen und dazu verwendet, einen Proxy für den Web Service zu generieren. Diese beiden Schritte können bereits automatisiert werden. Der generierte Proxy wird verwendet, um mit dem tatsächlichen Web Service via SOAP-Nachrichten zu kommunizieren.
Technische Aspekte von UDDI
Die treibenden Kräfte der UDDI-Spezifikation sind unter anderem Microsoft und IBM. Im Jahr 2000 wurde die erste Version von UDDI freigegeben, die von einer eigenständigen Organisation (www.uddi.org) koordiniert wurde. Seit Frühjahr 2005 ist die Version 3.0 freigegeben, die Sicherheitsaspekte in das Verzeichnis integriert und die mittlerweile von dem Industriekonsortium OASIS (http://www.oasis-open.org) betreut wird. Die Tabelle gibt einen Überblick über die Entwicklung von UDDI.
|
Version |
1.0 |
2.0 |
3.0 |
|
Jahr |
2000 |
2003 |
2005 |
|
Ziel |
Grundlagen |
Ausrichtung auf Web Services / erweiterte Taxonomie |
Sicherheit (private / public) für SOA |
|
Verantwortlich |
Ariba, Microsoft, IBM |
Ariba, Microsoft, IBM |
OASIS |
Die wesentlichen Bestandteile der UDDI-Spezifikation sind die Beschreibung der Datenstruktur in UDDI und das API zum Abfragen und Publizieren von Services in der UDDI-Registry:
-
Das UDDI-XML-Schema definiert das Datenmodell von UDDI und stellt vier Hauptdatenstrukturen bereit: Das Datenmodell von UDDI wurde entwickelt, um die wichtigsten Funktionen optimal zu unterstützen. Dazu gehören die standardisierte Suche, die Administration, die Kategorisierung und die Katalogisierung von Web Services. Die Kategorisierung etwa ist unerlässlich, um in größeren Verzeichnissen zu suchen oder den Dienst zu finden, wenn der Suchende Anbieter oder den konkreten Namen des Dienstes nicht kennt.
-
Die UDDI-API ist eine Anzahl von Anwendungs-Schnittstellen, die selbst Web Services sind und das SOAP-Protokoll verwenden. Die Schnittstellen dienen zur Suche, Veröffentlichung und Verwaltung von Daten in Verzeichnissen.
Das UDDI-Datenmodell
Das Datenmodell von UDDI kennt im Wesentlichen die folgenden Datenstrukturen, die auch in der Abbildung unten dargestellt sind.
-
businessEntity: Organisation, die den Webservice anbietet (inklusive Kontaktinformationen)
-
businessService: Webservicegruppe, Identifikation und Klassifikation des Webservices (durch tmodels)
-
bindingTemplate: Technische Informationen eines Webservices(z.B. URI des Webservices), Referenzen auf tModels.
-
tModel (technical model): Technische Spezifikation eines Webservices, Schnittstellenbeschreibung, Klassifikationsschemata
-
publisherAssertation: Wenn mehrere Unternehmen in einer bestimmten Beziehung zueinander stehen (z.B. Mutter- und Tochtergesellschaft) oder bestimmte Beziehungen eingehen wollen (z.B. Teilnahme an einem globalen Marktplatz), können diese Beziehungen in UDDI-Registry mit der Hilfe von publisherAssertation dargestellt werden. Dieses Element ist optional.
Aus den Bestandteilen eines UDDI-Eintrages kann ein WSDL Dokument generiert werden, mit dem auf den Webservice zugegriffen werden kann. Im Folgenden gehen wir auf die einzelen Datenstrukturen näher ein.
Die Datenstruktur businessEntity
Das Element „businessEntity“ ist der Container für alle anderen Elemente. Mit dem Datentyp werden Unternehmen oder Organisationen modelliert, die den Web Service anbieten. Es enthält das Element „businessKey“, ein global eindeutiger Bezeichner für das jeweilige Unternehmen, sowie weitere Informationen über die Organisation. Hierfür stehen Elemente wie <name>, <description> und <contacts> zur Verfügung.
bussinesEntity
---------------------------------------------
+businessKey: uddi:businessKey[0..1]
+discoveryUrls: uddi:discoveryURLs[0..1]
+name: uddi:name[1..*]
+description: uddi:description[*]
+contacts: uddi:contacts[0..1]
+businessService: uddi:businessService[0..1]
+identifierBag: uddi:identifierBag[0..1]
+categoryBag: uddi:categoryBag[0..1]
+dsig:Signature: dsig:Signature[*]
Die einzelnen Felder haben die folgende Bedeutung:
-
businessKey: ist die eindeutige Kennzeichnung eine businessEntity
-
name: spezifiziert den Namen der BusinessEntity
-
discoveryURLs: ist optional und gibt andere Wege an, über die angebotene Dienste aufgelistet werden können
-
description: beinhaltet eine Beschreibung der businessEntity
-
contacts: listet die Kontaktdaten der businessEntity auf
-
businessService: enthält die Dienste, die businessEntity anbietet
-
identifierBag: weitere Angaben, die die businessEntity kennzeichnen
-
categoryBag: dient der Kategorisierung der businessEntity
-
dsig:Signature: kann verwendet werden, um eine businessEntity mit einer digitalen Signatur zu versehen
Die folgende Abbildung verdeutlicht anhand eines konkreten Beispiels der Sammlung von Wetterdaten die Nutzung der businessEntity-Datenstruktur.
Die Datenstruktur businessService
Das Element „businessService „beschreibt die von der Organisation bereit gestellten Webdienste. Sie definiert den Dienst auf logischer bzw. betriebswirtschaftlicher Ebene und kann als Produkt verstanden werden, das ein Unternehmen anbietet.
Ein Unternehmen könnte beispielsweise den Dienst „Gehaltsrechner“ anbieten, der Netto- und Bruttolöhne berechnet. Der Dienst ist aus betriebswirtschaftlicher Sicht ein Produkt, aus technischer Sicht ein aus mehreren Web Services bestehender Rechenvorgang.
Die businessService-Datenstruktur wird durch das Element „serviceKey“ eindeutig gekennzeichnet. Benannt wird sie durch „name“, näher beschrieben durch „description“. Technische Informationen werden in bindingTemplates abgelegt.
businessService
----------------------------------------------
+serviceKey: uddi:serviceKey[0..1]
+businessKey: uddi:businessKey[0..1]
+name: uddi:name[*]
+description: uddi:description[*]
+bindingTemplates: uddi:bindingTemplates[0..1]
+categoryBag: categoryBag[0..1]
+dsig:Signature: dsig:Signature[*]
Die einzelnen Felder haben die folgende Bedeutung:
-
serviceKey: bezeichnet den businessService eindeutig
-
businessKey: gibt an, zu welcher businessEntity der businessService gehört
-
name: spezifiziert den Namen des businessService
-
description: beschreibt den businessService
-
bindingTemplates: listet die technische Beschreibung der enthaltenen Web Services auf
-
categoryBag: kategorisiert den businessService
-
dsig:Signature: kann verwendet werden, um eine businessEntity mit einer digitalen Signatur zu versehen
Die folgende Abbildung ist wieder ein Beispiel für die businessService-Datenstruktur.
Die Datenstruktur bindingTemplate
bindingTemplate beschreibt die technischen Details, wie ein Service aufzurufen ist. Ein bindingTemplate umfasst zunächst die Zugriffsadresse des Services, die unter dem Attribut accessPoint spezifiziert ist. Meist ist dies eine URL. Die ausführlichen technischen Beschreibungen von dem Service werden unter den so genannten tModelInstanceDetails abgelegt, einer Datenstruktur, die unter anderem auf die Service-Typbeschreibungen (tModels) referenziert.
bindingTemplate
----------------------------------------------
+bindingKey: uddi:bindingKey[0..1]
+serviceKey: uddi:serviceKey[0..1]
+description: uddi:description[*]
+accessPoint: uddi:accessPoint[0..1]
+hostingRedirector: uddi:hostingRedirector [0..1]
+tModelInstanceDetails: uddi:tModelInstanceDetails[0..1]
+categoryBag: categoryBag[0..1]
+dsig:Signature: dsig:Signature[*]
bindingTemplate enthält die folgenden Felder:
-
bindingKey: damit wird bindingTemplates eindeutig gekennzeichnet
-
serviceKey: bezieht sich auf den businessService, zu dem das bindingTemplate gehört
-
accesspoint: gibt die Netzadresse an, über die der Dienst erreicht werden kann, eine URL oder Mail-Adresse
-
hostingRedirector: Diese Funktion wird seit Version drei von accesspoint abgedeckt
-
tModelInstanceDetails: enthält eine Liste mit einem oder mehreren Models; die Summe ist die Schnittstellenbeschreibung des Web Service
-
categoryBag: Kategorisierung des bindingTemplates
-
dsig:Signature: kann verwendet werden, um eine businessEntity mit einer digitalen Signatur zu versehen
Die Abbildung gibt wieder ein Beispiel für ein bindingTemplate:
Die Datenstruktur tModel
tModel ist das Kernstück von UDDI-Verzeichnissen. Es wird verwendet, um einzigartige Konzepte oder Konstrukte darzustellen. Beispielsweise kann ein tModel dazu verwendet werden darzustellen, dass ein Web Service die ebXML-Spezifikation verwendet.
Im Gegensatz zu den anderen Datenstrukturen sind tModels nicht als Kind-Elemente in Datenstrukturen wie businessEntity enthalten. Der Grund liegt darin, dass jedes tModel ein eigenständiges Konzept darstellt, das keiner anderen Datenstruktur untergeordnet ist.
Man kann tModels anhand einer Tabelle in einer Datenbank veranschaulichen, die folgende Spalten besitzt: ID, Name, Beschreibung, URL. Wichtig ist, dass diese Tabelle eigenständig ist und somit ohne andere Tabelle existieren kann. Diese Tabelle fungiert als eine Mappings-Tabelle, die auch als Domänentabelle oder Katalogtabelle bekannt ist.
tModel
----------------------------------------------
+tModelKey: uddi:tModelKey[0..1]
+deleted: uddi:deleted[0..1]
+name: uddi:name[1]
+description: uddi:description[*]
+overviewDoc: uddi:overviewDoc[0..1]
+identifierBag: uddi:identifierBag[0..1]
+categoryBag: categoryBag[0..1]
+dsig:Signature: dsig:Signature[0..*]
Die tModel-Datenstruktur enthält die folgenden Felder:
-
tModelKey: dient der Kennzeichnung eines tModels
-
deleted: zeigt, ob das tModel logisch gelöscht wurde. Normalerweise können tModels in UDDI-Verzeichnissen nicht vollständig gelöscht werden, da sonst Verweise aus anderen Datenstrukturen ins Leere zeigen. Mit dem Attribut deleted können tModels deshalb als gelöscht markiert werden.
-
name: enthält den Namen des tModels, anzugeben in URL-Form
-
description: beschreibt das tModel
-
overviewDoc: verweist auf externe Dokumente, ist aber optional
-
identifierBag: ermöglicht die Angabe weiterer Daten, die ein tModel kennzeichnen
-
categoryBag: technische Beschreibung des tModels
-
dsig:Signature: kann verwendet werden, um eine businessEntity mit einer digitalen Signatur zu versehen
Die Abbildung gibt wieder ein Beispiel für ein tModel:
Die folgende Abbildung zeigt noch einmal zusammenfassend die Beziehungen zwischen den Datenmodellen:
Die UDDI API
Die UDDI API dient der Interaktion zwischen UDDI-Client und UDDI-Server. Die Kommunikation findet allein durch den Austausch von XML-Dokumenten über standardisierte Internet-Protokolle statt. Dabei sind die APIs in UDDI in Form von XML-Segmenten spezifiziert, die beim Aufruf in SOAP-Envelope eingebettet werden.
Generell lassen sich die Requests in zwei Gruppen unterteilen: Inquiry-API und Publisher-API. Das Inquiry-API enthält alle Requests zur Suche nach einem bestimmten UDDI-Datentyp (find_business, find_service, find_binding und find_tModel) sowie die Requests zur Abfrage von Details der Datentypen (get_businessDetail, get_serviceDetail, get_bindingDetail und get_tModelDetail usw.). Diese Methoden werden in erster Linie von Service Consumer in Anspruch genommen und verlangen keine zusätzliche Authentifizierung.
Das Publisher-API enthält dagegen Requests zum Verändern bzw. Anlegen von Daten (save_business, save_service, save_binding und save_tModel) sowie Requests zum Löschen von Daten (delete_business, delete_service, delete_binding und delete_tModel). Diese Requests verlangen einen Sicherheits-Token, den der Benutzer beim Anmelden mit dem Request get_authToken erlangen und beim Abmelden mit dem Request discard_authToken verwerfen kann.
Fazit
UDDI wurde entwickelt, um ein öffentliches Verzeichnis zu schaffen, indem jeder Anbieter von Web Services seine Dienste anbieten kann. Das Verzeichnis ist jedem zugänglich, jeder kann eigene Web Service veröffentlichen und kann diese Web Services wieder verwenden. Im Moment ist man von eine großflächigen Nutzung des Verfahrens allerdings noch weit entfernt.
Obwohl die erste Spezifikation schon im Jahr 2000 veröffentlicht worden ist, ist das öffentliche UDDI nicht über ein Testverzeichnis mit wenig sinnvollen Daten hinausgekommen. Bislang hat es UDDI noch nicht zu dem gebracht, was Sourceforge.net heute für die Opensource Gemeinde ist.
Etwas anderes ist die unternehmensinterne Nutzung von UDDI. Viele Firmen benutzen ihr eigenes UDDI-Verzeichnis. Da die Ausführung der Web Services dann auf das Unternehmen beschränkt ist, macht das auch Sinn. Im Bereich Business to Business ist möglich, eventuell Partnern Zugriff auf ein gemeinsam genutztes Verzeichnis zu geben. In jedem Fall bildet UDDI einen zentralen Baustein einer serviceorientierten Architektur. (ala)
|
Teil 1 |
|
|
Teil 2 |
|
|
Teil 3 |
|
|
Teil 4 |
|
|
Teil 5 |
|
|
Teil 6 (in Planung) |
Web Services und Sicherheit |