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

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

Embed Size (px)

Citation preview

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

1

UDDIUDDITU ChemnitzFakultät für InformatikSS 2003Seminar Web und Service Engineering

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

2

Sem

inar

Web

un

d S

erv

ice E

ng

ineeri

ng

Thema

UDDIUDDIUniversal Description, Discovery

and Integration

Thomas Trommer ([email protected])

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

3

Sem

inar

Web

un

d S

erv

ice E

ng

ineeri

ng

Übersicht

1. Einleitung1. Was ist UDDI?2. Entstehung/ Entwicklung 3. Warum UDDI?

2. Architektur1. Die UDDI Business Registry2. Einbettung in den Protokollstack3. Aufbau der Registry Daten

3. Spezifikation1. Enkodieren von Informationen2. Die API

4. UDDI Tools5. Sicherheit, Alternativen, Kritik6. Zusammenfassung

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

4

Sem

inar

Web

un

d S

erv

ice E

ng

ineeri

ng

1. Einführung

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

5

Sem

inar

Web

un

d S

erv

ice E

ng

ineeri

ng

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

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

6

Sem

inar

Web

un

d S

erv

ice E

ng

ineeri

ng

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

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

7

Sem

inar

Web

un

d S

erv

ice E

ng

ineeri

ng

1.2. Entstehung/ Entwicklung

B2B Bereich

XML, SOAP

BizTalk, cXML

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

8

Sem

inar

Web

un

d S

erv

ice E

ng

ineeri

ng

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

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

9

Sem

inar

Web

un

d S

erv

ice E

ng

ineeri

ng

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!

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

10

Sem

inar

Web

un

d S

erv

ice E

ng

ineeri

ng

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!

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

11

Sem

inar

Web

un

d S

erv

ice E

ng

ineeri

ng

2. Architektur

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

12

Sem

inar

Web

un

d S

erv

ice E

ng

ineeri

ng

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

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

13

Sem

inar

Web

un

d S

erv

ice E

ng

ineeri

ng

2.1. Die UDDI Business Registry (UBR)

IBM

Ariba

Microsoftother

other UDDI.org

AnfragenRegistrierungenÄnderungen

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

14

Sem

inar

Web

un

d S

erv

ice E

ng

ineeri

ng

2.2. Einbettung in den Protokollstack

HTTP|SMTP|TCPHTTP|SMTP|TCP

XMLXML

SOAPSOAP

UDDIUDDI

AnwendungAnwendung

UDDI im Protokollstack

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

15

Sem

inar

Web

un

d S

erv

ice E

ng

ineeri

ng

2.3. Aufbau der Registry Daten

• Unternehmen registrieren Informationen über sich und die angebotenen bzw. unterstützten Dienste.

• technische Beschreibung der Dienste

WhitePages

YellowPages

GreenPages

Service TypeRegistrations

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

16

Sem

inar

Web

un

d S

erv

ice E

ng

ineeri

ng

2.3. Aufbau der Registry Daten

White Pages Firmenname Beschreibung der Firma (Text) Kontaktinformationen

Namen Telefon Fax Homepage ...

Eindeutige identifizierende Nummer

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

17

Sem

inar

Web

un

d S

erv

ice E

ng

ineeri

ng

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

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

18

Sem

inar

Web

un

d S

erv

ice E

ng

ineeri

ng

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

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

19

Sem

inar

Web

un

d S

erv

ice E

ng

ineeri

ng

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

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

20

Sem

inar

Web

un

d S

erv

ice E

ng

ineeri

ng

3.1. Enkodieren von Informationen

Datenstrukturen sind in XML Schema definiert 5 zentrale Datenstrukturen sind darin

spezifiziert: businessEntity businessService bindingTemplate tModel publisherAssertion

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

21

Sem

inar

Web

un

d S

erv

ice E

ng

ineeri

ng

3.1. Enkodieren von Informationen

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

22

Sem

inar

Web

un

d S

erv

ice E

ng

ineeri

ng

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

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

23

Sem

inar

Web

un

d S

erv

ice E

ng

ineeri

ng

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>

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

24

Sem

inar

Web

un

d S

erv

ice E

ng

ineeri

ng

3.1. Enkodieren von Informationen

businessService Enkodieren der Service Informationen

Webservices auch allgemeine Service (z.B.) Telefonhotline

Enthält ein oder mehrere bindingTemplate Strukturen

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

25

Sem

inar

Web

un

d S

erv

ice E

ng

ineeri

ng

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>

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

26

Sem

inar

Web

un

d S

erv

ice E

ng

ineeri

ng

3.1. Enkodieren von Informationen

bindingTemplate Informationen wie man einen Service erreicht Beschreibung der Kommunikationsschnittstelle Zeiger auf ein oder mehrere tModel Strukturen

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

27

Sem

inar

Web

un

d S

erv

ice E

ng

ineeri

ng

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>

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

28

Sem

inar

Web

un

d S

erv

ice E

ng

ineeri

ng

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)

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

29

Sem

inar

Web

un

d S

erv

ice E

ng

ineeri

ng

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>

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

30

Sem

inar

Web

un

d S

erv

ice E

ng

ineeri

ng

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

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

31

Sem

inar

Web

un

d S

erv

ice E

ng

ineeri

ng

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>

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

32

Sem

inar

Web

un

d S

erv

ice E

ng

ineeri

ng

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

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

33

Sem

inar

Web

un

d S

erv

ice E

ng

ineeri

ng

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 >

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

34

Sem

inar

Web

un

d S

erv

ice E

ng

ineeri

ng

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

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

35

Sem

inar

Web

un

d S

erv

ice E

ng

ineeri

ng

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

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

36

Sem

inar

Web

un

d S

erv

ice E

ng

ineeri

ng

3.3. UDDI und SOAP

Zugriff auf die UDDI-Registry mittels SOAP

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

37

Sem

inar

Web

un

d S

erv

ice E

ng

ineeri

ng

4. UDDI Tools

Nutzung von Webfrontends: https://uddi.ibm.com/ubr/registry.html https://uddi.ibm.com/testregistry/registry.html (zum testen) http://uddi.microsoft.com ...

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

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

38

Sem

inar

Web

un

d S

erv

ice E

ng

ineeri

ng

5. Sicherheit, Alternativen, Nachteile

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

39

Sem

inar

Web

un

d S

erv

ice E

ng

ineeri

ng

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

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

40

Sem

inar

Web

un

d S

erv

ice E

ng

ineeri

ng

5.2. Alternative

Web Service Inspection Language Von Microsoft und IBM Keine Registrierung, statt dessen

„Inspection.wsil“ im root Verzeichnis der Domain gelagert

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

41

Sem

inar

Web

un

d S

erv

ice E

ng

ineeri

ng

5.3. Nachteile

Sicherheit schwer zu gewährleisten 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

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

42

Sem

inar

Web

un

d S

erv

ice E

ng

ineeri

ng

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