UDDI TU Chemnitz Fakultät für Informatik SS 2003

Präsentation zum Thema: "UDDI TU Chemnitz Fakultät für Informatik SS 2003"—  Präsentation transkript:

1 UDDI TU Chemnitz Fakultät für Informatik SS 2003
Seminar Web und Service Engineering

2 UDDI Universal Description, Discovery and Integration Thema
Thomas Trommer

3 Übersicht Einleitung Architektur Spezifikation UDDI Tools
Was ist UDDI? Entstehung/ Entwicklung Warum UDDI? Architektur Die UDDI Business Registry Einbettung in den Protokollstack Aufbau der Registry Daten Spezifikation Enkodieren von Informationen Die API UDDI Tools Sicherheit, Alternativen, Kritik Zusammenfassung

4 1. Einführung

5 1.1. Was ist UDDI Plattformunabhängiger offener Standart
Zum beschreiben von Services (Description) Zum auffinden von Unternehmen und deren Web Services (Discovery) Um Services einzubinden (Integration) Gelbe Seiten für Webservices

6 1.2. Entstehung/ Entwicklung
Initiative namhafter Soft- und Hardwarehersteller Entwicklungsbeginn im Jahr 2000: Zusammenarbeit von Ariba, IBM und Microsoft ca. 50 Meetings 6 Monate September 2000: Version 1.0 März 2001: Version 2.0 Dezember 2001: Version 3.0 Aktuelle Anwendungen entsprechen meist Version 2.0

7 1.2. Entstehung/ Entwicklung
B2B Bereich BizTalk, cXML XML, SOAP

8 1.3. Warum UDDI? Wenige kleine Firmen
Angebotene Dienste leicht überschaubar Kein Problem den besten Anbieter manuell zu finden Viele große Unternehmen (Realität) Unzählige Dienstleistungen und Geschäftsbeziehungen Nahezu unmöglich den optimalen Geschäftpartner zu finden Manuell nicht überschaubar

9 1.3. Warum UDDI? Vor UDDI: Telefonbuch Branchenverzeichnis
Suchmaschinen (Google, Yahoo, ...) Langwierige Suche Wahrscheinlich nicht alle Möglichkeiten betrachtet Nicht den optimalen Geschäftspartner gefunden Unnötige Kosten!

10 1.3. Warum UDDI? Anforderungen an UDDI:
Firmen und Dienste schnell auffindbar machen Standardisierte Repräsentation dieser Firmen und Dienste Einfache Suche geeigneter Web Services Leichtere Einbindung von Webdiensten in die unternehmensinterne Struktur Geld sparen!

11 2. Architektur

12 2.1. Die UDDI Business Registry (UBR)
Konzeptionell eine einzige Registrierungsstelle Über viele Operatorknoten verteilt Knoten replizieren und synchronisieren ihre Daten mindestens 1 mal am Tag Anfragen an beliebige Knoten liefern daher selbes Ergebnis Neuer Inhalt wird an einem einzigen Operatorknoten eingefügt Anmeldung bei Knotenbetreiber notwendig Knoten ist Hauptbesitzer des Inhalts Aktualisierungen und Löschungen der Daten nur über diesen Knoten möglich

13 2.1. Die UDDI Business Registry (UBR)
Anfragen Registrierungen Änderungen IBM other UDDI.org Ariba other Microsoft

14 2.2. Einbettung in den Protokollstack
UDDI im Protokollstack Anwendung UDDI SOAP XML HTTP|SMTP|TCP

15 2.3. Aufbau der Registry Daten
White Pages Unternehmen registrieren Informationen über sich und die angebotenen bzw. unterstützten Dienste. technische Beschreibung der Dienste Yellow Pages Green Pages Service Type Registrations

16 2.3. Aufbau der Registry Daten
White Pages Firmenname Beschreibung der Firma (Text) Kontaktinformationen Namen Telefon Fax Homepage ... Eindeutige identifizierende Nummer

17 2.3. Aufbau der Registry Daten
Yellow Pages Beschreibung des Geschäftsfeldes z.B. „produzierendes Gewerbe“ oder „Autohandel“ Green Pages Technische Informationen Beschreibt Form und Verhalten des Web Service Beschreibt wo der Web Service zu finden ist

18 2.3. Aufbau der Registry Daten
Service Type Registrations Konkrete technische Beschreibung des angebotenen Dienstes Unterstützte Standards Interchange-Formate Erforderliche Parameter Verweise auf weitere Beschreibungen der Dienste Eindeutige Identifikation des Servicetyps

19 3. Spezifikation Zwei wesentliche Bestandteile:
XML-Schema für die Datenstrukturen Definiert welche Informationen in UDDI gelistet werden Definiert wie Informationen enkodiert werden API Ermöglicht abfragen, einfügen, ändern und löschen von Informationen

20 3.1. Enkodieren von Informationen
Datenstrukturen sind in XML Schema definiert 5 zentrale Datenstrukturen sind darin spezifiziert: businessEntity businessService bindingTemplate tModel publisherAssertion

21 3.1. Enkodieren von Informationen

22 3.1. Enkodieren von Informationen
businessEntity Grundlegende Informationen über das entsprechende Unternehmen, also den Inhalt der White Pages Enthält eine oder mehrere businessService Strukturen

23 3.1. Enkodieren von Informationen
Spezifikation der XML Struktur: <element name="businessEntity" type="uddi:businessEntity" /> <complexType name="businessEntity">   <sequence>     <element ref="uddi:discoveryURLs" minOccurs="0" />     <element ref="uddi:name" maxOccurs="unbounded" />     <element ref="uddi:description" minOccurs="0" maxOccurs="unbounded" />     <element ref="uddi:contacts" minOccurs="0" />     <element ref="uddi:businessServices" minOccurs="0" />     <element ref="uddi:identifierBag" minOccurs="0" />     <element ref="uddi:categoryBag" minOccurs="0" />   </sequence>   <attribute name="businessKey" type="uddi:businessKey" use="required" />   <attribute name="operator" type="string" use="optional" />   <attribute name="authorizedName" type="string" use="optional" /> </complexType>

24 3.1. Enkodieren von Informationen
businessService Enkodieren der Service Informationen Webservices auch allgemeine Service (z.B.) Telefonhotline Enthält ein oder mehrere bindingTemplate Strukturen

25 3.1. Enkodieren von Informationen
Spezifikation der XML Struktur: <element name="businessService" type="uddi:businessService" /> <complexType name="businessService">   <sequence>     <element ref="uddi:name" minOccurs="0" maxOccurs="unbounded" />     <element ref="uddi:description" minOccurs="0" maxOccurs="unbounded" />     <element ref="uddi:bindingTemplates" minOccurs="0" />     <element ref="uddi:categoryBag" minOccurs="0" />   </sequence>   <attribute name="serviceKey" type="uddi:serviceKey" use="required" />   <attribute name="businessKey" type="uddi:businessKey" use="optional" /> </complexType>

26 3.1. Enkodieren von Informationen
bindingTemplate Informationen wie man einen Service erreicht Beschreibung der Kommunikationsschnittstelle Zeiger auf ein oder mehrere tModel Strukturen

27 3.1. Enkodieren von Informationen
Spezifikation der XML Struktur: <element name="bindingTemplate" type="uddi:bindingTemplate" /> <complexType name="bindingTemplate">   <sequence>     <element ref="uddi:description" minOccurs="0" maxOccurs="unbounded" />    <choice>       <element ref="uddi:accessPoint" />       <element ref="uddi:hostingRedirector" />     </choice>     <element ref="uddi:tModelInstanceDetails" />   </sequence>   <attribute name="serviceKey" type="uddi:serviceKey" use="optional" />   <attribute name="bindingKey" type="uddi:bindingKey" use="required" /> </complexType>

28 3.1. Enkodieren von Informationen
tModel Technische Spezifikation des Webservices Unabhängig vom Business definiert Web Services verschiedener Firmen können auf das gleiche tModel verweisen Enthält nicht die technische Beschreibung selbst, nur den Link auf diese (z.B. auf eine WSDL-Datei)

29 3.1. Enkodieren von Informationen
Spezifikation der XML Struktur: <element name="tModel" type="uddi:tModel" /> <complexType name="tModel"> <sequence>     <element ref="uddi:name" />     <element ref="uddi:description" minOccurs="0" maxOccurs="unbounded" />     <element ref="uddi:overviewDoc" minOccurs="0" />     <element ref="uddi:identifierBag" minOccurs="0" />     <element ref="uddi:categoryBag" minOccurs="0" />   </sequence>   <attribute name="tModelKey" type="uddi:tModelKey" use="required" />   <attribute name="operator" type="string" use="optional" />   <attribute name="authorizedName" type="string" use="optional" /> </complexType>

30 3.1. Enkodieren von Informationen
publisherAssertion Beziehungsstruktur zwischen zwei businessEntity Strukturen Firmen können damit Geschäftsbeziehungen öffentlich machen Beide Firmen müssen ein pulisherAssertion Dokument anlegen

31 3.1. Enkodieren von Informationen
Spezifikation der XML Struktur: <element name="publisherAssertion" type="uddi:publisherAssertion" /> <complexType name="publisherAssertion">   <sequence>    <element ref="uddi:fromKey" />     <element ref="uddi:toKey" />     <element ref="uddi:keyedReference" />   </sequence> </complexType>

32 3.2. Die API Es wird nach zwei Anwendungsszenarien unterteilt:
Publishing-API (Register-API) Inquiry-API (Such-API) Der UDDI-Funktionsaufruf wird im <Body> einer SOAP-Nachricht an die Registry übertragen

33 3.2. Die API Allgemeiner Aufbau der Funktionsaufrufe
<Funktionsname Version-ID [ Attribut ] Namespace-URN > <Argumentname_1>Wert_Argument_1</Argumentname_1> <Argumentname_2>Wert_Argument_2</Argumentname_2> . <Argumentname_n>Wert_Argument_n</Argumentname_n> </Funktionsname >

34 3.2.1. Inquiry API (Such-API)
10 Operationen zum durchsuchen der Registry: find_business - Zum Auffinden von Informationen über Unternehmen find_service - Zum Auffinden von spezifischen Service find_binding - Zum Auffinden von spezifischen Bindungen innerhalb eines businessService find_tModel - Zum Auffinden von tModel Informationsstrukturen find_relatedBusinesses - Zum Auffinden von Informationen über businessEntity Registrierungen, die in Beziehung stehen zur UUID der übergebenen businessEntity get_businessDetail - Zum Erhalten der vollständigen Unternehmensinformation get_businessDetailExt - Zum Erhalten erweiterterer Informationen über ein Unternehmen get_bindingDetail - Zum Erhalten der vollständigen Information über ein bindingTemplate get_serviceDetail - Zum Erhalten aller Details eines businessService get_tModelDetail - Zum Erhalten aller Details eines tModels

35 3.2.2. Publishing API (Register API)
16 Operationen um die Registryinformationen zu verwalten: get_authToken - Erhalt eines Authorisationstokens (das Äquivalent zu einem Login) discard_authToken - Fallenlassen eines Authorisationstokens save_business, save_service, save_binding, save_TModel - Neu, speichern oder updaten der Strukturen delete_business, delete_service, delete_binding, delete_TModel - Löschen der Strukturen add_publisherAssertions - Zufügen von Relationsbeziehungen zwischen Unternehmen delete_publisherAssertions - Löschen der Relationsbeziehungen zwischen Unternehmen get_assertionStatusReport - Liefert einen Status Report, der die Unternehmensbeziehungen und Status Information enthält get_publisherAssertions - Liefert eine Liste aller Unternehmensbeziehungen set_publisherAssertions - Speichert eine Liste aller Beziehungen ( Überschreibt eine bereits existierende Liste) get_registeredInfo - Liefert eine Zusammenfassung der Information

36 3.3. UDDI und SOAP Zugriff auf die UDDI-Registry mittels SOAP

37 4. UDDI Tools Nutzung von Webfrontends: HP Registry Composer:
(zum testen) ... HP Registry Composer: Java Tool um mit Registries zu interagieren JUDDI und UDDI4J Opensource Produkte die das Erstellen eigener Frontends mit Java ermöglichen IBM Web-Services Toolkit Viele nützliche Tools zum arbeiten mit Web Services, unter anderem auch ein UDDI Registry-Server Microsoft Visual Studio .NET, UDDI Software Development Kit

38 5. Sicherheit, Alternativen, Nachteile

39 5.1. Sicherheit Sicherheitsmodell nur auf Anbieterseite
Übertragungssicherheit Veränderungen an der Registry nur über SSL und https Aufbau der Vertrauensbasis im Vorfeld (Austausch von Geschäftsadressen (Abhängig vom Operator) Authentication Token: Von Operator-Site vergeben Werden nur von vergebender Operator-Site akzeptiert Per-account Space Limits Operator legt diese fest Individuell vereinbar Standartwerte z.B.: 1 businessEntity pro Benutzer 4 businessService pro businessEntity 2 bindingTemplates pro businessService 10 tModels pro Benutzer

40 5.2. Alternative Web Service Inspection Language Von Microsoft und IBM
Keine Registrierung, statt dessen „Inspection.wsil“ im root Verzeichnis der Domain gelagert

41 5.3. Nachteile Sicherheit schwer zu gewährleisten Pflege der Datenbank
jeder kann sich als Firma ausgeben Schwieriges und aufwendiges Überprüfen wäre notwendig Pflege der Datenbank Veraltete Einträge Ungültige Einträge Meist nur Firmeninformationen, keine Services

42 6. Zusammenfassung UDDI bietet die Möglichkeit, über eine Operator-Site eine weltweite Präsenz zu erreichen UDDI setzt auf XML und SOAP auf UDDI definiert XML-Datenstrukturen zur Beschreibung von Unternehmensprofilen und Web-Dienst-Schnittstellen UDDI definiert API für die Erzeugung von Unternehmenseinträgen und zu deren Abfrage UDDI ermöglicht es Kunden, sich an die Schnittstelle IHRES Dienstes anzupassen UDDI bietet ein gewisses Minimum an Sicherheit