Seminarbericht Rechnernetze XML Web Services Universal Description, Discovery and Integration (UDDI)

Transkript

1 Seminarbericht Rechnernetze XML Web Services Universal Description, Discovery and Integration (UDDI) von Florian Koch Kennnummer: Dezember 2005

2 Inhaltsverzeichnis Inhaltsverzeichnis 1 Einleitung SOA (Service Oriented Architecture) Geschichte UDDI-Topologien Die UDDI Business Registry (UBR) Der UDDI E-marketplace Der UDDI Private node Der UDDI Extranet node UDDI-Datenmodell Die Datenstrukturen Das tmodel UDDI API Design und Architektur Die Inquiry API Die Publisher API Beispiel: find_business Schlussbetrachtung Abkürzungsverzeichnis Quellenverzeichnis

3 Einleitung 1 Einleitung UDDI steht für Universal Description, Discovery and Integration. Es repräsentiert neben SOAP und WSDL die dritte Technologiesäule im Bereich der Web Services und dient dem Publizieren und Lokalisieren dieser

4 SOA (Service Oriented Architecture) 2 SOA (Service Oriented Architecture) UDDI baut wie auch SOAP und WSDL auf der serviceorientierten Architektur, kurz als SOA bezeichnet, auf. Innerhalb dieser Architektur löst UDDI das Problem des Publizierens und Auffindens von wieder verwendbaren Services. Ein Problem, welches in der Praxis häufig vorkommt, ist, dass dieselbe Funktionalität mehrmals von verschiedenen Abteilungen in einem Unternehmen implementiert wird, weil nicht bekannt ist, dass die benötigte Komponente schon vorhanden ist. Diesem Problem wird bei SOA mit einem zentralen Verzeichnis oder einer Registry Abhilfe verschafft. In diesem Verzeichnis sind alle nutzbaren Services registriert. Es verwaltet die zu den Services gehörenden Metainformationen in einem Repository und stellt diese Informationen über eine definierte Schnittstelle für Clients zur Verfügung. In einer serviceorientierten Architektur werden drei Rollen identifiziert (Abb.1): Abb. 1: Das magische Dreieck - der Service Provider (Anbieter eines Services) ist verantwortlich für das Implementieren und Bereitstellen (Hosting) des Services publiziert die Service-Beschreibung in einem Repository (optional) - 3 -

5 SOA (Service Oriented Architecture) - der Service Consumer (Nutzer eines Services) falls Schnittstelle und Adresse des Services nicht schon bekannt sind, muss er zuerst durch Abfrage in der Registry die notwendigen Informationen in Erfahrung bringen nimmt den Service durch verschicken von Requests in Anspruch - der Service Broker (Vermittler zwischen Provider und Consumer) wird oft von einem zentralen Verzeichnis für Service-Registrierung und Service-Suche erfüllt Web Services sind typischerweise auf dieser serviceorientierten Architektur aufgebaut. Die Rolle des Service Brokers wird von XML-Verzeichnissen wie UDDI oder ebxml-registry übernommen

6 Geschichte 3 Geschichte Durch die Verbreitung der Web Service-Technologie und den zunehmenden Bedarf an B2B-Kollaborationen im Web wurde schnell erkannt, dass ein Vermittlungsmechanismus fehlt, der die Verbindungen zwischen den Geschäftspartnern im Web herstellen bzw. vermitteln kann. Dafür wurde von IBM, Microsoft und Ariba im Jahr 2000 das UDDI Projekt ins Leben gerufen, was heutzutage den De-facto-Standard für XML-Verzeichnisse von Web Services darstellt. Innerhalb von wenigen Monaten entwickelte sich eine Partnerschaft von mehr als 200 Mitgliedern, die sich zum Ziel gesetzt haben, die UDDI Spezifikation zu definieren. Einige gut bekannte Unternehmen in diesem Projekt sind zum Beispiel: BEA Systems, Boeing, Cisco Systems, Compaq, Dell, Ford Motor Company, Fujitsu, Hitachi, Hewlett-Packard, Intel, Iomega, IONA, NEC, Oracle, Rational, SAP, Sun Microsystems, Unisys, usw. Diese große Community ist in das uddi.org Konsortium involviert. VERSION DATUM 1.0 September 2000 Gründung der Foundation um internetbasierte Business-Services zu registrieren 2.0 Juni 2001 Erweiterung der Spezifikation um die Web Service Architektur und mehr Flexibilität bei Taxonomien 3.0 Juli 2002 Mehr Support bei Interaktionen bei privaten und öffentlichen Implementierungen Tab. 1:Geschichte der UDDI Spezifikation 2002 übernahm die Organisation zur Förderung von Standards für strukturierte Informationen OASIS die offizielle Pflege des Standards. Mit dem Übergang an OASIS sollte sich UDDI nunmehr endgültig als offener Standard etablieren und noch breitere Unterstützung finden

7 UDDI-Topologien 4 UDDI-Topologien In UDDI wird meistens in vier Typen von Topologien unterschieden: - Die UDDI Business Registry ist ein Netzwerk von öffentlichen UDDI Registries im Internet - Der UDDI E-marketplace stellt eine UDDI Registry dar, die einem bestimmten Industriezweig zugeordnet ist - Der UDDI Private node ist eine UDDI Registry in einem Intranet, die UDDI-Funktionalität firmenintern zur Verfügung stellt - Der UDDI Extranet node bezeichnet eine UDDI Registry in einem Extranet, um UDDI-Funktionalität Geschäftspartnern zur Verfügung zu stellen 4.1 Die UDDI Business Registry (UBR) IBM, Microsoft, SAP und NTT Communications besitzen öffentliche UDDI Web Seiten. Beispielsweise ist die öffentliche UDDI Registry von IBM unter der Internet- Adresse zu finden. Jede Firma kann sich in dieser Registry über ihre Dienstleistungen registrieren oder nach Dienstleistungen anderer Gesellschaften suchen. Eine wichtige Eigenschaft der UDDI Registries von IBM, Microsoft, SAP und NTT Communications ist, dass ihre Daten untereinander repliziert werden. Somit können diese Registries dann als ein einziges aus vielen Nodes gebautes System betrachtet werden. Dieses Netzwerk von UDDI Registries wird als UDDI Business Registry (UBR) bezeichnet, und ist auch unter dem Begriff Public Cloud bekannt. Im Prinzip kann jede Firma ein Mitglied der UDDI Business Registry werden, wenn sie eine öffentliche UDDI Registry aufstellt und diese in den UBR- Replikationsprozess einbindet. Um die Qualität des Dienstes jedoch zu sichern, würde diese Firma noch eine ziemlich lange Liste von in der UDDI Operator Spezifikation festgelegten Voraussetzungen erfüllen müssen

8 UDDI-Topologien Die Inhalte der UDDI Operator Spezifikation betreffen u. a. die UUID Generierungsalgorithmen, die XML-Datenüberprüfung (validation), die Systeme zur Sicherung (backup) und Wiederherstellung (recovery) und die Verfahren zur Datenreplizierung (replication). 4.2 Der UDDI E-marketplace E-Marketplaces sind auf bestimmte Geschäftszweige, wie den Verlagshandel oder die Reisebranche ausgelegt. Zwei Aspekte von UDDI sind für e-marketplaces besonders relevant: die Kategorisierungs-Architektur und die Fähigkeit, technische Angaben zu erfassen, um auf Dienstleistungen zuzugreifen. Kategorisierung: Ohne eine korrekte Klassifizierung und Kategorisierung können große Inhalte nicht effektiv gehandhabt werden, und sie zu durchsuchen, kann sich sehr schwierig gestalten. Klassische e-marketplaces entwickeln und benutzen für gewöhnlich ihre eigene Struktur für die Kategorisierung. Dahingegen profitiert der UDDI e-marketplace von der flexiblen UDDI-Architektur für die Kategorisierung. UDDI nimmt nicht nur alle bekannten Taxonomie-Architekturen wie NAICS oder UNSPSC an, sondern erlaubt es auch neue Taxonomie-Architekturen einzuführen. 4.3 Der UDDI Private node Firmen zeigen ein zunehmendes Interesse für die UDDI private nodes. Die UDDI private nodes setzen auf dem firmeneigenen Intranet auf und befinden sich für gewöhnlich hinter der Firewall. Sie sind meist vom Internet getrennt, oder nur eingeschränkt zugänglich, und die Daten, die sie enthalten, werden in der UBR nicht repliziert. Bei private nodes können die Zugriffsregeln wesentlich feiner gestaltet werden, oder demselben Zugriffsmodell wie der UBR folgen. Zudem kann eine Gruppierung von UDDI private nodes, welche ihre Daten untereinander replizieren, in der Firma errichtet werden

9 UDDI-Topologien UDDI private nodes beinhalten Einträge für Webdienste, die anderen Abteilungen oder Gruppen innerhalb der Firma zur Verfügung gestellt werden. Zum Beispiel, könnte ein Datenverarbeitungszentrum eine Reihe von Webdiensten veröffentlichen, um auf Kataloginformation zuzugreifen. Diese Webdienste könnten von den Webmastern verwendet werden, um Online-Systeme zu realisieren. Gewöhnlich werden Standards innerhalb des Unternehmens entwickelt, und die verwendeten technischen Modelle entsprechen dann diesen Technologiestandards. 4.4 Der UDDI Extranet node Der UDDI extranet node ist für die Verwendung in Partnergesellschaften gedacht. Er verzeichnet Webdienste, auf die durch Firmen zugegriffen werden kann, die in einem Geschäfts-Verhältnis zueinander stehen. Der UDDI extranet node stellt nur seine Inquiry API autorisierten Gesellschaften zur Verfügung, die Publisher API bleibt unöffentlich und ist nur dem UDDI extranet operator für die Administrierung zugänglich. Firmen können die UDDI extranet nodes ihrer Partner durchsuchen und die Web Service Definitionen in ihre eigenen private nodes kopieren. Da Geschäfts- Verhältnisse fortwährend gebildet und aufgelöst werden, werden die Eintragungen im UDDI private node dementsprechend aktualisiert. Somit können Anwendungen geschrieben werden, die an die Web Services der Geschäftspartner anknüpfen

10 UDDI-Datenmodell 5 UDDI-Datenmodell Vergleicht man das Architekturbild einer typischen verteilten Anwendung (sei es auf CORBA-, RMI- oder EJB-Basis) mit dem der serviceorientierten Architektur, wird sofort ersichtlich, dass UDDI bzw. der Service Broker die Rolle des Namensdienstes (CoSNaming, RMIRegistry oder JNDI) in klassischen verteilten Architekturen spielt. UDDI weist aber wesentlich mehr Funktionalitäten auf als ein bloßer Namensdienst wie JNDI. So können Daten in der UDDI-Registry auf verschiedene Arten abgefragt werden: - White Pages die UDDI-Registry enthält Namen, Beschreibung und sämtliche Kontaktinformationen von Unternehmen, die Web Services publiziert haben - Yellow Pages alle Unternehmen sowie ihre veröffentlichten Services werden innerhalb der UDDI-Registry klassifiziert und kategorisiert, sodass die ganze Registry wie ein Branchenbuch oder die Gelben Seiten benutzt werden kann - Green Pages die UDDI-Registry enthält zusätzlich noch die technischen Dokumentationen, die die veröffentlichten Services beschreiben Die wesentlichen Bestandteile der UDDI-Spezifikation sind die Beschreibung der Datenstrukturen in UDDI und die API zum Anfragen und Publizieren von Services in der UDDI-Registry. Da UDDI selbst eine Web Service-Anwendung ist, benutzt es als Kommunikationsprotokoll SOAP. Demzufolge werden alle APIs und Datenstrukturen in XML- bzw. XML Schema-Format spezifiziert

11 UDDI-Datenmodell 5.1 Die Datenstrukturen Das Datenmodell von UDDI kennt im Wesentlichen die folgenden fünf Datenstrukturen, welche auch in Abb. 2 dargestellt sind. Abb. 2: Datenstrukturen von UDDI - businessentity repräsentiert ein reales Unternehmen, das Web Services in der UDDI- Registry veröffentlicht besitzt neben Attributen wie Name, Beschreibung und Kontaktinformationen auch eine Liste von businessservices, die die vom Unternehmen veröffentlichten Services darstellt jede businessentity wird einer eindeutigen ID in Form einer UUID (Universal Unique Identifier) zugeordnet

12 UDDI-Datenmodell - businessservice besitzt ebenfalls eine eindeutige ID kennt zusätzlich noch die ID der zugehörigen businessentity, sodass die Eltern-Kind-Beziehung jederzeit über diese ID hergestellt werden kann es besteht die Möglichkeit, dass ein Service auf verschiedene Arten aufgerufen werden kann diese unterschiedlichen Zugänge zu diesem Service werden in den Kind- Elementen (bindingtemplates) von businessservice abgelegt - bindingtemplate beschreibt die technischen Details, wie ein Service aufzurufen ist umfasst einerseits die Zugriffsadresse des Services, die unter dem Attribut accesspoint spezifiziert ist andererseits werden die ausführlichen technischen Beschreibungen von diesem Service unter den so genannten tmodelinstancedetails abgelegt, einer Datenstruktur, die u. a. auf die Servicetypbeschreibungen (tmodels) referenziert - publisherassertation wenn mehrere Unternehmen in einer bestimmten Beziehung zueinander stehen (z.b. Mutter- und Tochtergesellschaft) oder bestimmte Beziehungen wollen (z.b. Teilnahme an einem globalen Marktplatz), können diese Beziehungen in der UDDI-Registry mit der Hilfe von publisherassertation dargestellt werden - tmodel wichtiger und zugleich mysteriöser Begriff in der UDDI-Welt

13 UDDI-Datenmodell Das tmodel Ein tmodel ist an sich eine einfache Datenstruktur. Jedem tmodel wird beim Anlegen eine UUID zugeordnet und besitzt außerdem Subelemente wie Name, Beschreibung oder Übersichtsdokument. Im Gegensatz zur Eltern-Kind-Beziehung zwischen businessentity und businessservice sowie zwischen businessservice und bindingtemplate werden tmodels nur von anderen Datenstrukturen referenziert. Sie sind nicht als Kind-Elemente in anderen Datenstrukturen 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 (Tab. 2). Wichtig hierbei 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. ID Name Beschreibung URL 1 Telefon Repräsentiert eine Telefonnummer 2 Fax Repräsentiert eine Faxnummer 3 Steuernummer Repräsentiert eine Steuernummer 4 Aktienkursservice Repräsentiert einen Service, der Aktienkurs liefert Tab. 2: tmodel als Tabelle Ein tmodel wird innerhalb von UDDI für zwei verschiedene Zwecke verwendet. Zum einen kann ein tmodel einen technischen Fingerprint oder eine technische Spezifikation beschreiben. Ein typisches Beispiel für diese Art der Verwendung ist das Ablegen eines WSDL-Dokuments als Servicespezifikation in die UDDI-Registry, wie das tmodel mit der ID 4 in der Tab. 2. Ein solches WSDL-Dokument enthält die Beschreibung der abstrakten Serviceschnittstelle mit Datentypen (type), Nachrichten (message) und Porttyp (port type & operation). Diese abstrakte Servicespezifikation repräsentiert einen eigenen Servicetyp und wird daher in UDDI unter einem tmodel mit einer eindeutigen UUID abgelegt. Wenn ein Service diese abstrakte Servicespezifikation bzw. diesen Servicetyp unterstützt, kann er dies ausdrücken, indem er in seinen tmodelinstancedetails auf die UUID dieses tmodels referenziert

14 UDDI-Datenmodell Ein Service Consumer, der diesen Service nutzen will, kann dann das tmodel bzw. den Servicetyp studieren, um diesen Service korrekt aufzurufen. Ein tmodel kann ebenfalls verwendet werden, um abstrakte Namensräume für Typisierungen zu definieren. Wenn die drei folgenden Nummern ohne Kontext betrachtet werden, ist es schwer zu erkennen, was diese Nummern genau bedeuten: Wenn aber jeder Nummer ein tmodel oder die ID eines tmodels zugeordnet wird, dann ist die Semantik der einzelnen Nummern sofort klar: Für die erste Nummer wird tmodelkey=1 zugeordnet. D.h., es handelt sich bei um eine Telefonnummer. Die zweite Nummer (die dritte) bekommt tmodelkey=2 (tmodelkey=3) und ( ) ist daher eine Faxnummer (Steuernummer). In diesem Fall definiert jedes tmodel einen eigenen Namensraum, der für die Klassifizierung bzw. Kategorisierung von Datenstrukturen in UDDI verwendet werden kann. Datenstrukturen wie businessentity oder businessservice können optional zwei Subelemente besitzen: identifierbag und categorybag. Ein identifierbag ist nichts anderes als eine Sammlung von Key-Value-Paaren, die nur in einem bestimmten Kontext sinnvoll sind. Dieser Kontext entspricht dem Namensraum, der durch das zugehörige tmodel identifiziert wird. Ähnlich ist categorybag aufgebaut, nur dass der vom entsprechenden tmodel identifizierte Namensraum auf eine vordefinierte Kategorie (Taxonomy) verwiesen wird. In UDDI sind Standard-Identifiertypen und Kategorien definiert, die in den Tabellen 3 und 4 aufgelistet sind

15 UDDI-Datenmodell Identifier D-U-N-S Thomas Register tmodel dnb-com:d-u-n-s thomasregistrer-com:supplierid Tab. 3: Standard-Identifiertypen Ein von UDDI bereitgestelltes Identifizierungssystem ist die D-U-N-S Nummer (Data Universal Numbering System), entwickelt von Dun & Bradstreet, ein Anbieter von Businessinformationen und Services. Die D-U-N-S Nummer erlaubt es weltweit eine eindeutige Identifikation von Business-Enitäten. Mehr als 60 Millionen Unternehmen unterstützen dieses Identifikationssystem und es wird von mehr als 50 globalen Standardisierungs-, Industrie- und Handelsgesellschaften wie z.b.: - ANSI (American National Standards Institute), - EDIFACT (Electronic Data Interchange for Administration), - ISO (International Organization for Standardization), - European Commission (Standard für den elektronischen Handel) angewendet. Thomas Register ist das umfassendste Verzeichnis von US-amerikanischen und kanadischen Herstellern in der Welt, mehr als Industrieprodukt und Dienstleistungsgesellschaften verzeichnend. Taxonomy tmodel Beschreibung NAICS ntis-gov:naics:1997 North American Industry Classification System UNSPSC unspsc-org:unspsc Universal Standard Products and Services Classification ISO 3166 uddi-org:iso-ch:3166:1999 ISO 3166, internationaler Standard für geographische Regionen Andere Taxonomy uddi-org:general_keywords Klassifizierung nach Schlüsselwort Tab. 4: Standard-Kategorien UNSPSC (Universal Standard Products and Services Classification) ist eine Klassifizierung von Produkten und Services und wurde von ECCMA (Electronic Commerce Code Management Association) entwickelt

16 UDDI-Datenmodell NAICS (North American Industry Classification System) stellt eine Klassifizierung von Industriecodes dar und besitzt zudem geographische Klassifizierungen durch lokale Codes basierend auf dem ISO 3166 Country Code

17 UDDI API 6 UDDI API In diesem Abschnitt wird die allgemeine Architektur der UDDI API besprochen und näher auf die einzelnen API-Aufrufe (Methoden) eingegangen, mit denen eine UDDI- Registry manipuliert und abgefragt werden kann. Alle Aussagen beziehen sich auf die UDDI Spezifikation in der Version Design und Architektur Beim Design der UDDI-API wurde sehr viel Wert auf Einfachheit gelegt. Es wurde darauf geachtet, dass die API nicht zu viele Aufrufe definiert, die sich in ihrer Funktionalität nicht überlappen und allgemein eine einfache und verständliche Struktur haben. Die Aufrufe sollten eine gute Performance aufweisen und ohne großen Programmieroverhead direkten Zugang zu den wichtigen Strukturen einer Registry erlauben. Die Kommunikation mit einer UDDI-Registry geschieht über SOAP-Nachrichten, welche die von der API definierten XML-Strukturen transportieren. Die Kommunikation basiert auf einem Anfrage/Antwort-Mechanismus, bei dem der UDDI-Client einen API-Aufruf an die Registry sendet und darauf eine Antwort in Form einer XML-Struktur in einem SOAP-Envelope erhält. Die SOAP- Nachrichten werden mittels HTTP und HTTPS über das TCP/IP-Protokoll transportiert. Die von der API definierten Aufrufe sind allesamt atomar. Entweder ist die ganze Transaktion erfolgreich, oder die gesamte Transaktion wird abgebrochen. Es werden keine Teilresultate zurückgeliefert. Des Weiteren sind alle Aufrufe blockierend, basieren also auf einem synchronen Kommunikationsmodell. Die gesamte API ist in eine Inquiry API und eine Publisher API unterteilt. Die Inquiry API definiert Aufrufe, mit denen eine Registry nach Einträgen durchsucht werden kann und bietet Methoden, die eine direkte Abfrage der vier UDDI-Datenstrukturen erlauben. Die publisherassertation als fünfte UDDI-Datenstruktur wird in diesem Abschnitt nicht näher beleuchtet. Die Publisher API definiert Methoden, mit denen die Einträge einer Registry verändert werden können und neue Einträge eingefügt werden können

18 UDDI API 6.2 Die Inquiry API Mit den Aufrufen der Inquiry API können Businesses, Services, Bindings und tmodels in einer Registry gesucht (find_xx Aufrufe) oder direkt die entsprechenden Strukturen abgefragt werden, wenn man bereits deren eindeutige Schlüssel kennt (get_xxdetail Aufrufe). Die Inquiry API ist frei verfügbar und benötigt keinerlei Authentifikation bei einem Aufruf. Die Kommunikation wird nicht verschlüsselt und geschieht über das HTTP-POST Protokoll. Die Inquiry definiert folgende Anfragenachrichten zum Suchen und Lokalisieren von Registry-Einträgen. Als Argumente nehmen die meisten einen Namen, einen categorybag und identifier-bag für die Suche nach kategorisierten und standardisierten Einträgen. Auch besteht immer die Möglichkeit, das Standard- Suchverhalten mittels findqualifiers zu verändern, um z.b. nur case sensitive Treffer zuzulassen. - find_binding Suchen von passenden Bindings liefert eine bindingdetail-nachricht zurück - find_business Suchen von Businesses nach Namen oder angebotenen Services und tmodels liefert eine businesslist-nachricht zurück - find_relatedbusinesses Suchen von Business, die mit einem anderen Business verwandt sind liefert eine relatedbusinesseslist-nachricht zurück - find_service Suchen von Services, entweder global oder innerhalb einer bestimmten businessentity liefert eine servicelist-nachricht zurück - find_tmodel Suchen von tmodel-strukturen liefert eine tmodellist-nachricht zurück

19 UDDI API Folgende Aufrufe für direkten Zugriff auf die Datenstrukturen sind vorhanden. Diese Methoden nehmen alle als einziges Argument den eindeutigen Schlüssel der jeweiligen Struktur, die abgefragt werden soll. - get_bindingdetail Abfragen einer bestimmten bindingtemplate-struktur, die Informationen für den Aufruf des Webservices enthält liefert eine bindingdetail-nachricht zurück - get_businessdetail Abfragen einer bestimmten businessentity-struktur, die Informationen zu Firmen und Organisationen enthält liefert eine businessdetail-nachricht zurück - get_businessdetailext Abfragen von erweiterten Informationen zu einer businessentity liefert eine businessdetailext-nachricht zurück - get_servicedetail Abfragen einer bestimmen businessservice-struktur, die Informationen zu einem Webservice enthält liefert eine servicedetail-nachricht zurück - get_tmodeldetail Abfragen einer bestimmen tmodel-struktur, die den technischen Fingerabdruck eines Webservices enthält liefert eine tmodeldetail-nachricht zurück

20 UDDI API 6.3 Die Publisher API Mit den Aufrufen der Publisher API können Einträge einer Registry verändert und gelöscht werden oder es können neue Einträge publiziert werden. Da bei diesen Aufrufen die Registry verändert wird und nicht jeder einfach beliebige Einträge abändern oder löschen können soll, muss sich jemand, der einen solchen Aufruf tätigen will, bei der Registry authentifizieren. Dazu muss er sich beim entsprechenden Registry Node registrieren und bekommt seine Login-Daten. Bevor er eine Methode aufrufen kann, muss er sich von der Registry ein Authentification Token holen, das er nur bekommt, wenn die Login-Daten korrekt sind. Alle Aufrufe der Publisher API verlangen nun als Argument ein solches Authentification Token und der Aufruf wird nur bearbeitet, wenn das Token gültig ist und der Besitzer des Tokens auch gleichzeitig der Besitzer des zu bearbeitenden Eintrages ist, ihn also in der gleichen Registry Node erstellt hat. Die wichtigsten Aufrufe der Publisher API sind die folgenden: - get_authtoken Anfragen eines Authentification Tokens von einer Registry Node - discard_authtoken Invalidieren eines Authentification Tokens - delete_service Löschen einer businessservice-struktur liefert eine dispositionreport-nachricht zurück, welche über den Erfolg oder Misserfolg der Aktion Auskunft gibt - delete_business Löschen einer businessentity-struktur liefert eine dispositionreport-nachricht zurück - delete_binding Löschen einer bindingtemplate-struktur liefert eine dispositionreport-nachricht zurück - delete_tmodel Löschen einer tmodel-struktur liefert eine dispositionreport-nachricht zurück

21 UDDI API - save_service Publizieren einer businessservice-struktur liefert eine servicedetail-nachricht zurück, welche die gespeicherten Änderungen enthält - save_business Publizieren einer businessentity-struktur liefert eine businessdetail-nachricht zurück, welche die gespeicherten Änderungen enthält - save_binding Publizieren einer bindintemplate-struktur liefert eine bindingdetail-nachricht zurück, welche die gespeicherten Änderungen enthält - save_tmodel Publizieren einer tmodel-struktur liefert eine tmodeldetail-nachricht zurück, welche die gespeicherten Änderungen enthält

22 UDDI API 6.4 Beispiel: find_business Am Beispiel des find_business Aufrufes soll kurz auf die Syntax eines API-Aufrufes eingegangen werden. Im folgenden Beispiel wird eine Art EBNF-Syntax verwendet, wobei Elemente zwischen eckigen Klammern optional sind und zwischen geschweiften Klammern beliebig oft (auch gar nicht) vorkommen können. Hier ist nur die eigentliche XML-Message ohne SOAP-Envelope und andere Header sichtbar. <find_business [maxrow="nn"] generic="2.0" xmlns="urn:uddi-org:api_v2"> [ <findqualifiers/> ] { <name/> } [ <discoveryurls/> ] [ <identifierbag/> ] [ <categorybag/> ] [ <tmodelbag/> ] </find_business> Das find_business-element hat drei Attribute. maxrow ist nicht obligatorisch und kann die Anzahl zurückgegebener Suchresultate beschränken. Die Attribute generic und xmlns müssen vorhanden sein und dienen der Versionskontrolle (generic) und definieren den Namensraum (xmlns). Die folgenden Unterelemente von find_business sind allesamt optional und können auch fehlen. Mit dem Element findqualifiers kann das Standard-Suchverhalten verändert werden, wenn z.b. die Resultate sortiert werden sollen oder ein exact match verlangt wird. Mit name können Businesses nach Namen gesucht werden, wobei mehrere Namen für die Suche mit OR verknüpft werden. Mit discoveryurl kann nach der URL gesucht werden, die eine Registry einem Eintrag beim Erstellen automatisch zuweist und mit der mittels HTTP-GET direkt zugegriffen werden kann. categorybag und identifierbag erlauben eine Suche eines Businesses in verschiedenen Taxonomien und standartisierten Klassifizierungen. Schließlich kann mit tmodelbag auch nach Businesses gesucht werden, die Services mit einem bestimmten technischen Fingerabdruck bereitstellen, so dass leicht passende Handelspartner gefunden werden können, die mit den eigenen Services kompatibel sind

23 UDDI API Die Antwort der Registry auf eine solche find_business Anfrage ist eine businesslist- Struktur, die Informationen zu allen gefundenen Businesses in Kurzform enthält. Mit dem entsprechenden businesskey, der aus der businesslist extrahiert werden kann, können dann mittels get_businessdetail-aufruf detailliertere Informationen zu einem gewünschten Business abgerufen werden. Die businesslist enthält auch Informationen zu den Services, die ein Business anbietet, sodass auch gleich für einen passenden Service ein bindingtemplate geholt werden kann. Zur Veranschaulichung wird in Listing 1 und 2 das Request-Response-Paar eines UDDI-Aufrufs gezeigt. Hier wird als Suchkriterium ein Name-Value-Paar in dem Namensraum angegeben, der durch das tmodel mit uuid:4e49a8d6-d5a2-4fc2-93a0-0411d8d19e88 definiert ist. Da hinter dieser UUID das tmodel ISO 3166 für geographische Regionen steht, bedeutet es einfach, dass hier nach Unternehmen gesucht wird, die in Deutschland ansässig sind. <soap-env:envelope xmlns:soapenv=" <soap-env:body> <find_business generic="2.0" xmlns="urn:uddi-org:api_v2"> <categorybag> <keyedreference keyname="germany" keyvalue="de" tmodelkey="uuid:4e49a8d6-d5a2-4fc2-93a0-0411d8d19e88"/> </categorybag> </find_business> </soap-env:body> </soap-env:envelope> Listing 1: UDDI Inquiry Request für find_business

24 UDDI API <soap-env:envelope xmlns:soapenv=" <soap-env:header/> <soap-env:body> <businesslist generic="2.0" operator="sun Microsystems Inc." truncated="false" xmlns="urn:uddi-org:api_v2"> <businessinfos> <businessinfo businesskey="f6058fd2-47f6-058f-e5e8-f3b5bf62f171"> <name xml:lang="de" xmlns:xml=" Star</name> <description xml:lang="de" xmlns:xml=" training and consulting</description> <serviceinfos> <serviceinfo businesskey="f6058fd2-47f6-058f-e5e8-f3b5bf62f171" servicekey="f6058fd2-56f6-058f-2742-aa7e5b7a3605"> <name xml:lang="en">format Java Code</name> </serviceinfo> </serviceinfos> </businessinfo> </businessinfos> </businesslist> </soap-env:body> </soap-env:envelope> Listing 2: UDDI Inquiry Response für find_business

25 Schlussbetrachtung 7 Schlussbetrachtung Es ist zwar in der serviceorientierten Architektur nicht zwingend notwendig, dass ein Service Broker wie UDDI-Registry benutzt wird, doch stellt UDDI eine sehr nützliche Technologie dar, die das Lokalisieren von wieder verwendbaren Services wesentlich erleichtert. Dabei muss man die Nutzung nicht nur auf die globalen Verzeichnisse, die von den Big Playern wie IBM, Microsoft oder SAP betrieben werden, beschränken. Es ist zu erwarten, dass immer mehr UDDI-Verzeichnisse innerhalb eines Unternehmens eingerichtet werden, wo die wieder verwendbaren Services registriert sind, um die Wiederverwendung von Komponenten in einem Unternehmen zu fördern

26 Abkürzungsverzeichnis 8 Abkürzungsverzeichnis ANSI API B2B CORBA CoSNaming D-U-N-S EBNF ebxml ECCMA EDIFACT EJB HTTP HTTPS ISO JNDI NAICS OASIS RMI SOA SOAP TCP/IP UDDI UNSPSC UUID WSDL XML American National Standards Institute Application Programming Interface Business to Business Common Object Request Broker Architecture Common Object Services Naming Data Universal Numbering System Extended Backus-Naur Form Electronic Business using Extensible Markup Language Electronic Commerce Code Management Association Electronic Data Interchange For Administration, Commerce and Transport Enterprise Java Beans Hyper Text Transfer Protocol Hyper Text Transfer Protocol Secure International Organization for Standardization Java Naming and Directory Interface North American Industry Classification System Organization for the Advancement of Structured Information Standards Remote Method Invocation Service Oriented Architecture Simple Object Access Protocol Transmission Control Protocol / Internet Protocol Universal Description, Discovery and Integration United Nations Standard Products and Services Code Universal Unique IDentifier Web Services Description Language Extensible Markup Language

27 Quellenverzeichnis 9 Quellenverzeichnis