Web Services SOAP, UDDI, WS-Inspection und WSDL. Sommersemester 2002Verteilte und Parallele DBMS2 Definition Web Service Keine einheitliche Definition

Web Services

SOAP, UDDI, WS-Inspection und WSDL

Sommersemester 2002 Verteilte und Parallele DBMS 2

Definition Web Service Keine einheitliche Definition i.A. Dienst, der Benutzern über das Web

zur Verfügung gestellt wird und dabei beispielsweise auf XML und HTTP zurückgreift

Unterschied zu klassischen Diensten im Web:auf automatisierte Benutzung ausgelegt


Stand der Technik Viele große Softwarefirmen bieten

entsprechende Produkte an: BEA WebLogic HP Web Services Platform IBM WebSphere Microsoft .NET mySAP.com von SAP SUN ONE


Beispiel für Web Services Marktplätze

Automobilindustrie Fluggesellschaften …

Ziel dieser Marktplätze:Optimierung des Einkaufs, d.h. möglichst schnell das günstigste Angebot unter allen Anbietern zu finden und auch die Bestellung online abwickeln können.

Dazu werden Daten von ERP-Systemen in Marktplätzen integriert.


Motivation Dienste werden im Internet angeboten Bisher allerdings nur mit HTML-

Formularen/ HTML-Seiten als Benutzerschnittstelle

Automatische Benutzung schwierig ( „screen scraping“-Technologien)

Jeder Dienst hat seine eigene Oberfläche, dadurch keine einheitliche Bedienung


Ziel der Web Services Vollautomatische Dienstnutzung Interoperabilität unabhängig vom

zugrundeliegenden Betriebssystem, von der Programmiersprache der Services und von der Web Service Engine

Dienstkomposition Einheitliche Schnittstellen für Dienste, die

dasselbe leisten (z.B. gleiche Schnittstelle für alle Kreditkarten-Bezahl-Dienste, Buchbestellungs-Dienste,…)


Interoperabilität (1) Um die Interoperabilität von Diensten zu

gewährleisten, braucht man Standards: SOAP (Simple Object Access Protocol – IBM,

MS,…) ebXML (Electronic Business using eXtensible

Markup Language – OASIS, UN/CEFACT) UDDI (Universal Description, Discovery and

Integration – HP, IBM, Intel, Microsoft, SAP, Software AG, Sun, …)

WSDL (Web Services Description Language – Ariba, IBM, Microsoft)


Interoperabilität (2) Standards (2):

WSFL (Web Services Flow Language – IBM) XLANG (Microsoft) WS-Inspection (Web Service Inspection

Language – IBM, Microsoft) …

Alle diese Standards basieren auf XML!


XML: Extensible Markup Language Vom World Wide Web Konsortium (W3C)

konzipiert und standardisiert XML-Datenmodell liegt zwischen:

HTML Schema-los Beliebige Daten, solange Syntax stimmt

Relationales Schema Schema Keine Abweichungen

Semi-strukturierte Daten Teilweise schematisch Aber Ausnahmen Wenn Schema, dann muss es eingehalten werden


XML-Daten mit Schema Verschiedene Möglichkeiten

DTD Einfach Nicht sehr leistungsfähig

XML-Schema Mächtiger als DTDs Unterstützt auch komplexe Typen Viele Grundtypen vordefiniert


Aufbau eines XML-Dokumentes Optionale Präambel – u.a. XML-Version Optionales Schema Ein einziges Wurzelelement, das beliebig viele und

beliebig tief geschachtelte Unterelemente beinhalten kann Elemente werden immer von Start- und Ende-Tag

eingeschlossen, z.B. <Vorlesung> und </Vorlesung> Elemente = atomare Informationseinheit Jedes Element hat einen Namen, der durch das Start- bzw.

Ende-Tag angegeben ist Jedes Element kann Attribute besitzen Inhalt eines Elementes = geordnete Liste aus

(Unter-)Elementen, Kommentaren oder Strings


Name des WurzelelementesUnterelementeAttribut des Buch-Elementes

Start- und Ende-Tag des Wurzelelementes

Wurzelelement

Schema

PräambelBeispiel-XML-Dokument<?xml version="1.0" encoding='ISO-8859-1'?>

<!DOCTYPE Buch[ <!ELEMENT Buch (Titel, Autor*, Verlag)> <!ATTLIST Buch Jahr CDATA #REQUIRED> <!ELEMENT Titel (#PCDATA)> <!ELEMENT Autor (#PCDATA)> <!ELEMENT Verlag (#PCDATA)>]>

<Buch Jahr="2001"> <Titel>Datenbanksysteme: Eine Einführung</Titel> <Autor>Alfons Kemper</Autor> <Autor>Andre Eickler</Autor> <Verlag>Oldenbourg Verlag</Verlag></Buch>


UDDI-Verzeichnisdienst

Klient Anbieter

Web Service A

Web Service B

Überblick über den Einsatz von Web Services



Klient Anbieter

WSDL-Dokument A

Web Service A

Web Service B

(1) registrieren

(1) registrieren

WSDL-Dokument B

Überblick Web Services – Dienste registrieren



Klient Anbieter

WSDL-Dokument A

Web Service A

Web Service B

(2) suchen

WSDL-Dokument B

Überblick Web Services – Dienstsuche



Klient Anbieter

WSDL-Dokument A

Web Service A

Web Service B

WSDL-Dokument B

(3) laden WSDL-Dokument B

Überblick Web Services – Proxy generieren (1)



Klient Anbieter

WSDL-Dokument A

Web Service A

Web Service B

Proxy

WSDL-Dokument B

(4) generieren

WSDL-Dokument B

Überblick Web Services - Proxy generieren (2)



Klient Anbieter

WSDL-Dokument A

Web Service A

Web Service B

Proxy

(5) kommunizieren via SOAP

WSDL-Dokument B

Überblick Web Services – Dienst ansprechen


Aktionen des Dienstanbieters

Object1UDDI-Verzeichnisdienst

WSDL-Dokument

Web Service

Verweis aufWSDL-Dokument

Dienstanbieter

interaktive Suche nach geeignetem tModel

falls kein geeignetes tModel verfügbar, registriere neues tModel

fordere zum tModel gehöriges WSDL-Dokument an

laden

dient als Grundlage für

Gerüst

generieren

(Werkzeug)

implementieren & betreiben

registrieren

Web-Service-Gerüst

Web Service



WSDL-Dokument

Klient Web Service

Verweis aufWSDL-Dokument

interaktive Dienstsuche

anfordern

laden

Proxygenerieren

(Werkzeug)

ausführen

Ergebnis

SOAP-RPC-Anforderung

SOAP-RPC-Antwort

dient als Grundlage für

(via Inquiry-API)

Web Service

Verweis aufWeb Service

Aktionen von Klienten


Beispiel-Szenario Vorstellung der weit verbreiteten

Standards SOAP, UDDI, WS-Inspection und WSDL

am Beispiel eines Temperaturdienstes. Die Dienste des Beispiel-Szenarios

werden auf wetter.fmi.uni-passau.de angeboten


Der Temperaturdienst Liefert zu einem vom Benutzer

vorgegebenen Zeitpunkt die Temperatur zurück, die an einem Temperatursensor in der Stadt Passau gemessen wurde.

keine Messdaten zum geforderten Zeitpunkt Messwert vom nächstgelegenen Messzeitpunkt


Weitere Dienste des Szenarios Einheitenumrechnerdienst:

Rechnet Temperaturangaben in verschiedene Einheiten um

TemperaturInFahrenheitDienst:Liefert wie der Temperaturdienst die Temperatur in der Stradt Passau zurück, allerdings in Grad Fahrenheit


Überblick über die Standards SOAP

Kommunikationsprotokoll zum Austausch von Nachrichten

UDDI Standard für Dienstverzeichnisse von Web

Services WS-Inspection

Spezifikation für Site-basierte Dienstsuche WSDL

Sprache zur Dienstbeschreibung


Das Kommunikationsprotokoll SOAP Simple Object Access Protokoll XML-basiertes Protokoll Kommunikationsprotokoll für verteilte

Anwendungen zum Austausch strukturierter und typisierter Daten

Kann z.B. HTTP, SMTP, FTP,… als Übertragungsprotokoll nutzen

Anwendungsspektrum: Vom Zustellen einer Nachricht bis zum RPC (Remote Procedure Call)


SOAP - Serialisierung Eigene Serialisierungs-Spezifikationen

möglich Standard-Serialisierung:

Typsystem basierend auf gebräuchlichen Typsystemen

Objekte bzw. Objektstrukturen dieses Typsystems werden auf XML abgebildet

Arrays und Referenzen sind auch möglich Abbildungen der Typsysteme von

Programmiersprachen auf das SOAP-Typsystem sind nicht festgelegt!


SOAP - Nachrichtenformat

<soap:Envelope soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">

<soap:Header>

</soap:Header>

<soap:Body>  </soap:Body></soap:Envelope> Envelope





</soap:Header>

<soap:Body>  </soap:Body></soap:Envelope> Envelope

Angabe der Serialisierungsspezifikation(Hier Standard-Serialisierung)





</soap:Header>

<soap:Body>  </soap:Body></soap:Envelope>

Header


SOAP - Header Optionales Element Bietet generischen Mechanismus, um

SOAP dezentral zu erweitern Beispiele für Erweiterungen:

Web Service Security Language Transaktionsmanagement





</soap:Header>

<soap:Body>  </soap:Body></soap:Envelope>

Body


SOAP - Body Möglichkeit zwischen Sender und

Empfänger Daten auszutauschen Typische Verwendungszwecke:

Aufnahme serialisierter Daten für RPC-Aufrufe Aufnahme von Fehlernachrichten

SOAP definiert nur das Fault-Element für die Übermittlung von Fehlerzuständen als Unterelement des Body-Elementes


Kommunikation mit SOAP Standardisierte Möglichkeit: SOAP über

HTTP Sender Empfänger: HTTP-Post-

Anforderungen Empfänger Sender: HTTP-Antwort Auch RPC-Aufrufe über SOAP/HTTP sind

standardisiert Alternative Möglichkeiten (nicht

standardisiert): SOAP über SMTP (Mailprotokoll) SOAP über FTP (Dateiübertragungsprotokoll)


Anfrage an den Temperaturdienst

Anfrage: „ Liefere die Temperatur, die am 22.02.2002 um 12.00

Uhr gemessen worden ist“


SOAP-Nachricht eigebettet in eine HTTP-POST-Anforderung

Name der Methode

Name der Methode

Parameter der Methode


Antwort des Temperaturdienstes

Am 22.02.2002, 13.00 Uhr wurden 4.4 Grad Celsius gemessen!

Achtung: Nächstgelegener Messzeitpunkt!


SOAP-Nachricht eingebettet in eine HTTP-Antwort

Anforderung erfolgreich bearbeitet


Dienstverwaltung Um Dienste zu nutzen, benötigt man

Metadaten: Wo findet man einen Dienst? Was tut er genau? Wie spricht man ihn an? Wer betreibt den Dienst? …

Dafür gibt es den Verzeichnisdienst UDDI und als Alternative WS-Inspection


UDDI - Verzeichnisdienst Universal Description, Discovery and Integration Aktuell: Version 2 Initiative von mehr als 300 Firmen (HP, IBM,

Microsoft, SAP, Software AG,…) Ziel: Globales UDDI-Verzeichnis Speicherung der Metadaten in einheitlicher

Datenstruktur UDDI-Schema (XML Schema) Festlegung von Veröffentlichungs-Mechanismen

UDDI-Publishing-API Festlegung einer Anfragesprache UDDI-

Inquiry-API Konzeptuell: Verteiltes Datenbanksystem

(allerdings ohne Transaktionssystem!)


Globales UDDI-Verzeichnis Viele lokale Installationen von UDDI-

Servern Zusammenschluss zu globalem Verbund Periodischer Abgleich der Daten Erscheint dem Benutzer wie ein Server

UDDI-Wolke


UDDI-Server-Verbund


Daten in UDDI White Pages: Daten über den Dienstanbieter

Adressdaten Kontaktpersonen Identifikatoren, z.B. Steuernummern

Yellow Pages: Angaben über Dienste Wie die Gelben Seiten basierend auf

Klassifikationen Eigene Klassifikationen möglich

Green Pages: Teschnische Informationen Adresse von Diensten Wie werden die Dienste konkret angeprochen


Datenstukturen in UDDI (1) Hauptstukturen:

businessEntity: Firmeninformationen businessService: Klassen von Diensten bindingTemplate: Technische Informationen

Logisch in einer Baumstruktur angeordnet:

businessEntity

businessService

businessService

businessService

bindingTemplate

bindingTemplate

bindingTemplate

bindingTemplate

bindingTemplate

bindingTemplate


Datenstukturen in UDDI (2) Strukturen zur Klassifikation und

Kategorienbildug tModel (technical model): Kategorienbildung

und Referenzierung von technischen Informationen

publisherAssertions: Modellierung von Geschäftsbeziehungen (z.B. Allianzen)

Instanzen aller Strukturen durch UUIDs (Universally Unique IDs) eindeutig identifizierbar


UML-Modell des UDDI-Schemas - Teilansicht


UML-Modell des UDDI-Schemas


businessEntity Angaben über eine Firma, Organisation, o.ä. businessKey wird automatisch vergeben Beispiel: businessEntity des Lst. für Dialog. Systeme Hier Kategorisierung nach geographischer Lage:

ISO 3166: DE-BY-PAS = Deutschland-Bayern-Passau


businessService Dienstgruppierung innerhalb eines

businessEntities Keine Auskunft über konkrete Dienste Beispiel: businessService, der

Temperaturdienste gruppiert


bindingTemplate Konkreter Dienst innerhalb eines

businessServices Beinhaltet technische Informationen:

Zugriffspunkt: accessPoint Beschreibung der Aufruf- und Rückgabemodalitäten im

referenzierten tModel

Beispiel: Temperaturdienst


tModel als technischer Fingerabdruck Verweis auf technische Dienstbeschreibungen Normalerweise werden WSDL-Dokumente

referenziert Beispiel: tModel für Temperaturdienst


tModel als Namensraumbezeichner Erzeugen und Benutzung von Taxonomien Beispiel: tModel für ISO 3166:

Beispiel: tModel für WSDL-Dokumente:


Übersicht über die UDDI-Einträge für das Beispielszenario


UDDI-Anfragesprache (Inquiry-API) XML-basiert Kommunikation über SOAP-Protokoll Beschränkt auf relativ einfache Anfragen Zwei Arten von Anfragen:

Browse-Anfragen Drill-Down-Anfragen

Verwendung: z.B. UDDI-Browser zur interaktiven Dienstsuche


Browse-Anfragen Erstmaliges Auffinden von Metadaten Beispiel: Suche alle businessEntities,

deren Name mit „Universitaet“ beginnt:

Maximal 5 Ergebnisse Aufsteigend nach Namen sortiert Präfixvergleich, da nichts anderes angegeben

ist


Drill-Down-Anfragen Liefern detaillierte Daten zu bekannten

Identifikatoren (UUIDs) Beispiel: Suche nach dem tModel mit der

angegebenen UUID:


UDDI-Befehle zur Datenmodifikation (Publishing-API) Ebenfalls XML-basiert Kommunikation über SOAP-Protokoll via

HTTPS Speicher- und Löschaufrufe Beispiel:


Umgang mit bindingTemplates:Pufferung und Puffer-Kohärenz Umgang mit bindingTemplates:

1. Anwendung A lädt die Metadaten von Dienst T. Die technischen Informationen können von A gepuffert werden.

2. Schlägt ein Aufruf von T fehl, muss A erneut die (hoffentlich) aktualisierten Metadaten von T abrufen. Diese können dann wieder gepuffert werden.

Vorteile: Verhindert Überlastung von UDDI-Servern Verhindert Überalterung von gepufferten

Daten


Globale Replikation der Daten Primärkopie-Ansatz

Jedes Datum hat einen Heimat-Server und einen Zeitstempel der letzten Änderung

Am Heimat-Server kann es geändert bzw. gelöscht werden

Periodische Benachrichtigung anderer UDDI-Server

Veraltete Daten werden aktualisiert Replikation läuft über SOAP auf HTTPS-

Verbindungen


Site-basierte Dienstsuche: WS-Inspection Keine Konkurrenz, sondern Ergänzung zu

UDDI Möglichkeit, auf alle Dienste einer Site zu

verweisen Sammlung von Referenzen auf bereits

vorhandene Dienstbeschreibungen Kopien von Beschreibungen nicht nötig

Spezielle Elemente für Verweise auf WSDL-Dokumente und UDDI-Einträge

Flexibel erweiterbar


WS-Inspection-Dokument von wetter.fmi.uni-passau.de

…Referenz auf UDDI-Verzeichnis

Referenz auf WSDL-Datei


Auffinden von WS-Inspection-Dokumenten Möglichkeit 1: inspection.wsil an den

Haupteinstiegspunkten eines Web-Servers: http://wetter.fmi.uni-passau.de/inspection.wsil

Möglichkeit 2: Verweis auf WS-Inspection-Dokumente innerhalb von HTML-Seiten:


Dienstbeschreibung mit WSDL XML-basiert Beschreibung von Diensten:

Operationen Format der Ein- und Ausgabedaten Kommunikationsprotokoll

Erweiterbar durch „Erweiterungselemente“ Verschiedene Protokolle und Datenformate verwendbar


Aufbau von WSDL-Dokumenten Elemente:

types message portType binding port service

Dienst = Menge von Endpunkten, die Nachrichten miteinander austauschen


Struktur eines WSDL-Dokumentes (1)

…


Struktur eines WSDL-Dokumentes (2)

…


Beispiel: Der Temperaturdienst - Typen Definition von Datentypen für die Nachrichten Normalerweise XML-Schema als Typsystem,

andere Typsysteme möglich Vorhandene XML-Schema-Dokumente können

eingebunden werden (import)


Beispiel: Der Temperaturdienst - Nachrichten Definiert Format der Ein- und Ausgabedaten Pro Nachricht ein message-Element

Pro Bestandteil ein part-Element Wenn man Nachrichten mit Funktionen vergleicht,

entsprechen parts den Parametern Nur abstakte Beschreibung von Nachrichten!

Übertragungsformat ist nicht festgelegt!


Beispiel: Der Temperaturdienst – Port-Typen (1) Fasst Nachrichten zu abstrakten Operationen

zusammen Mehrere Operationen pro Port-Typ möglich Vier mögliche Operationsprimitiven:

One-Way: Endpunkt empfängt Nachricht Request-Response: Endpunkt empfängt Nachricht

und antwortet Solicit-Response: Enpunkt sendet Nachricht und

empfängt Antwort Notification: Endpunkt sendet Nachricht


Beispiel: Der Temperaturdienst – Port-Typen (2) Unterelemente einer Operation:

input: Format der zu empfangenen Nachricht output: Format der zu sendenden Nachricht fault: Beschreibung möglicher Fehlernachrichten Reihenfolge/Vorhandensein der Elemente legt den

Operationstyp fest


Beispiel: Der Temperaturdienst – Bindungen Bindung = Port-Typ + Protokoll + Nachrichtenformat Mehrere Bindungen für einen Port-Typ möglich (z.B.

SOAP, HTTP und MIME)


Beispiel: Der Temperaturdienst – Ports und Dienste Port = Bindung + Netzwerkadresse Dienst = Gruppierung zusammengehöriger Ports Einsatz von Erweiterungselementen, um verschiedene Protokolle zu

unterstützen (hier SOAP) SOAP, HTTP und MIME-Erweiterungselemente bereits im WSDL-Standard


WSDL-Dokument des Temperaturdienstes (1)


WSDL-Dokument des Temperaturdienstes (2)


Einbettung von WSDL in UDDI Problem: UDDI und WSDL speichern Daten

über z.B. Netzwerkadresse Redundanz, Schlechte Widerverwendbarkeit des WSDL-Dokumentes

Lösung: service-Element wird aus WSDL-Dokumenten

weggelassen. Diese Informationen werden allein von UDDI verwaltet.

UDDI verweist innerhalb von tModels auf WSDL-Dokumente


Dienstkomposition und -interaktion• Durch Komposition vorhandener Dienste

können neue Dienste „zusammengebaut“ werden.

• Beispiel: TemperaturInFahrenheitDienst = Temperaturdienst + Einheitenumrechnerdienst

• Auch dafür gibt es XML-basierte Sprachen: • Web Services Flow Language (WSFL) von IBM• XLang von Microsoft• XL von Donald Kossmann et al.


Der TemperaturInFahrenheitDienst


ServiceGlobe Forschungsplattform für Web Services

basierend auf: SOAP UDDI WSDL

Neuartige Infrastruktur: Web Services können auf beliebigen Service

Hosts ausgeführt werden Dynamische Dienstauswahl Adaptoren zum Einbinden von existierenden,

nicht-konformen Diensten (z.B. RPC-basierte Dienste)


ServiceGlobe – Dynamische Dienstauswahl „Aufruf von tModels“

passende Implementierung wird während des Kompilierung oder zur Laufzeit ausgewählt

One-, Some-, All-Aufrufe möglich Angabe von Constraints Beispiel: Rufe alle Temperaturdienste auf; beachte

alle Ergebnisse, die innerhalb von einer Minute eintreffen

Vorteile: Optimierung der Abarbeitung möglich Bessere Verfügbarkeit, da bei Ausfall einzelner

Dienste automatisch Alternativen gewählt werden


ServiceGlobe - Architektur


Zusammenfassung Vorstellung der wichtigsten Standards:

SOAP UDDI WS-Inspection WSDL

Servicekomposition und –interaktion

Documents

Web Services SOAP, UDDI, WS-Inspection und WSDL. Sommersemester 2002Verteilte und Parallele DBMS2 Definition Web Service Keine einheitliche Definition