Von: Bernd Reder
Webservices zählen zu den Feldern, denen trotz - oder gerade wegen - der gegenwärtigen Wirtschaftskrise ein erhebliches Potenzial bescheinigt wird. Vereinfacht gesagt lassen sich Webservices als modulare Softwarekomponenten beschreiben, die lose miteinander gekoppelt sind und über IP-Netze zur Verfügung gestellt werden. Der Nutzer kann solche Dienste nach dem Baukastenprinzip mit anderen kombinieren. Webservices dienen in erster Linie dazu, das Zusammenspiel, also die Interoperabilität, von Anwendungen zu gewährleisten. Diese Applikationen können innerhalb eines Unternehmensnetzes bereitgestellt werden, aber auch in Form von Diensten, die ein Webserviceprovider über das Internet offeriert.
Eine Webservice-Architektur umfasst drei Grundfunktionen:
- "Discovery", also das Identifizieren von Webservices oder Geschäftspartnern im E-Business,
- "Description", das heißt Informationen über Unternehmen und die Webservices, die sie anbieten, in einem globalen Register (Registry) sowie
- den Transport der Daten.
Jede dieser Funktionen ist durch entsprechende Standards abgedeckt, die alle auf der Extended Markup Language (XML) basieren. Welche Dienste zur Verfügung stehen, Stichwort "Discovery", lässt sich mithilfe von "Universal Description, Discovery and Integration" (UDDI) ermitteln. Für die Description ist die "Web Services Description Language" (WSDL) zuständig, und der Transport erfolgt mittels des "Simple Object Access Protocol" (Soap).
Bevor Transaktionen stattfinden können, muss ein Webserviceprovider einen Dienst zusammenstellen und eine Beschreibung dieses Services in einer Registry hinterlegen. Dieses Verzeichnis ist ein Index von Servicebeschreibungen, mit dessen Hilfe sich Webservices ermitteln und aufrufen lassen. Ein so genannter "Web Service Requestor", also etwa ein Dienst oder Unternehmen, das einen bestimmten Service nutzen möchte, durchsucht die Registry nach einer passenden Service-Description. Hat der Service Requestor die entsprechende Information gefunden, nimmt er Verbindung zum Webserviceprovider auf und ruft den gewünschten Dienst auf.
Das Kernelement von UDDI, die "UDDI Business Registry", ist eine zentrale Datenbank, in der Firmen oder Organisationen ihre Web-dienstleistungen kostenlos registrieren lassen können. Die Registry ist also eine Art Adressbuch, in dem Anbieter und deren Leistungen aufgelistet sind. Die UDDI Business Registry stellt drei Arten von Informationen zur Verfügung:
- Die "Weißen Seiten" (White Pages): Sie enthalten unter anderem Namen und Adressdaten des Anbieters eines Webservices, inklusive Telefon- und Faxnummer, E-Mail- und Webadresse. Auf den Weißen Seiten ist beispielsweise auch die D-U-N-S-Nummer einer Firma zu finden, mit deren Hilfe sich das Unternehmen mittels eines von Dun & Bradstreet entwickelten Verfahrens identifizieren lässt.
- Die "Gelben Seiten" (Yellow Pages): Details zur geschäftlichen Ausrichtung eines Unternehmens. Dazu gehören Angaben über die Branche, in dem das Unternehmen aktiv ist, sowie das Produktportfolio oder die Regionen, welche die Firma abdeckt. Welche Produkte ein Unternehmen anbietet, gibt die "Universal Standard Products and Services Classification" (UNSPSC) an. Informationen über die Branche liefert das North American Industry Classification System (NAICS), Daten zur Ausrichtung nach geografischen Märkten die ISO-Norm für Länder und Regionen.
- Die "Grünen Seiten" (Green Pages): technische Daten zu den Servicetypen, Schnittstellen und Protokollen, die bei den E-Businesstransaktionen verwendet werden.
UDDI nutzt ein Informationsmodell, das auf XML aufsetzt. UDDI-XML definiert vier Arten von Informationen, die ein User benötigt, um den Webservice eines Anbieters zu nutzen:
- "Business Information",
- "Service Information",
- "Binding Information" und
- Daten über die Servicespezifikationen.
Die Businessinformationen werden im "Business Entity Element" abgelegt. Zu ihnen zählen Name und Adresse des Webservice-Anbieters. Die Business-Entity-Daten erlauben es zudem Interessenten, ähnlich wie ein Branchenfernsprechbuch, nach einem bestimmten Service zu suchen, etwa einem Dienst, der in einer speziellen Region zur Verfügung steht oder auf eine Branche zugeschnitten ist. Das Business Entity Element fungiert zudem als eine Art Informationscontainer, in dem alle anderen Informationen über einen Webservice enthalten sind, also Service- und Binding-Informationen.
Dienste nach Kategorien sortieren
Die Serviceinformationen sind im "Business-Service"-Element fixiert. Sie dienen dazu, Dienste in Gruppen zu sortieren, etwa auf Grundlage der Geschäftsprozesse, für die sie konzipiert wurden oder anhand von Dienstkategorien. Beispiele für Geschäftsprozesse sind etwa E-Business-Dienste für den Einkauf von Waren oder Logistikservices. Technische Daten für die Applikationen, mit deren Hilfe ein Nutzer Kontakt zu einem Webservice aufnimmt und mit diesem kommuniziert, liefern die "Binding Templates". In diese Kategorie fällt zum Beispiel die Webadresse, unter der ein Service zu erreichen ist.
Noch detailliertere technische Daten stellt eine Untermenge der Binding Templates bereit, das so genannte "tModel-Element". Es beschreibt die Spezifikationen der Schnittstellen, die ein Webservice verwendet. Das "tModel" eines Webservices enthält einen Schlüssel, der den Dienst beschreibt. Haben zwei Services denselben Schlüssel, bedeutet dies, dass sie auf denselben Standards aufsetzen und folglich zueinander kompatibel sind.
Der Zugriff auf die Registry erfolgt mithilfe eines Application Programming Interface (API), das wiederum aus zwei Teilen besteht: dem Inquiry API und dem Publisher API. Das Inquiry API ist notwendig, um Daten aus dem UDDI-Verzeichnis auszulesen. Die Publisher-Schnittstelle erlaubt es Anwendern, Informationen in die Registry einzugeben - vorausgesetzt, sie sind dazu autorisiert. Auf welche Weise sich Firmen oder Abteilungen authentifizieren, die ihre Angebote in eine UDDI-Registry eingeben wollen, ist nicht vorgegeben.
Die Architektur von UDDI ermöglicht es, sowohl öffentliche als auch private Registries aufzubauen. Firmen können beispielsweise private Verzeichnisse in einem Extranet bereitstellen, auf das Geschäftspartner Zugriff haben. Doch auch innerhalb firmeninterner Netze, also Intranets, lassen sich Webservice-Registries einsetzen. Gegenwärtig ist davon auszugehen, dass zunächst private Verzeichnisse in stärkerem Maße zum Einsatz kommen als öffentliche Kataloge. Der Grund dafür ist, dass Firmen derzeit dazu tendieren, Webdienste zunächst in ihrem Corporate Network einzusetzen, das durch Firewalls nach außen abgeschottet ist.
Parallel dazu haben einige große Softwarefirmen öffentliche UDDI-Registries aufgebaut. Dazu zählen Microsoft, IBM, Hewlett-Packard und die SAP AG (Die Links zu diesen Verzeichnissen finden Sie in der Online-Version dieses Beitrages auf unserer Webseite). Diese Firmen haben so genannte Operator Sites etabliert, über welche die Business Registry zugänglich ist.
UDDI-Version 3 kommt im Juli
Derzeit ist die dritte Version UDDI-Spezifikation im Beta-Test. Die endgültige Fassung soll im Juli herauskommen. Version 2, die im Juni 2001 veröffentlich wurde, erlaubt es unter anderem, Beziehungen zwischen Unternehmen zu registrieren. Auf diese Weise lassen sich komplexe Geschäftsprozesse abbilden, etwa solche zwischen eigenständigen Tochterfirmen innerhalb eines Konzernverbundes.
UDDI 3.0 soll die Kommunikation zwischen privaten, halbprivaten und öffentlichen Verzeichnissen verbessern. Außerdem berücksichtigt dieser Ansatz verstärkt Sicherheitsfragen. So ist geplant, in stärkerem Maße die Authentizität von Verzeichnisdaten sicherzustellen. Hier, so Claus von Riegen, UDDI-Spezialist von SAP, seien Technologien viel versprechend wie die XML-Signatur des World Wide Web Consortium (W3C).