Web Services Verschiedene Definitionen Web Service

Web Services
Web Service = Schnittstelle für den
netzbasierten Zugriff auf eine
Anwendungsfunktionalität, die vollständig
auf Standard-Internet-Technologien basiert
Web
Web
Netzwerk
SerService
vice
Anwendungslogik
A. Eberhart, S. Fischer: Web Services. München: Hanser 2003
286
© W. Wahlster, DFKI
Verschiedene Definitionen Web Service
z IBM: “Web services are self-contained, modular
applications that can be described, published,
located, and invoked over a network, generally,
the World Wide Web.”
z Microsoft: “a Web service is programmable
application logic, accessible using standard
Internet protocols,”
z Gartner Group: “a software component that
represents a business function (or a business
service) and can be accessed by another
application (a client, a server or another Web
service) over public networks using generally
available ubiquitous protocols and transports
(i.e. SOAP over HTTP).”
287
© W. Wahlster, DFKI
Just-in-time Integration
z Eine Anwendung findet
erst zur Laufzeit heraus,
Service
Service
Registry
welche Web Services sie
Registry
tatsächlich nutzen will.
1. Registrie2. Suche
z Der Dienst wird dann
rung
„just in time“ integriert.
z Vergleichbar mit „late
Service
Service
Service
binding“ in objektorientierter Service
Consumer
Provider
Provider
Consumer
Programmierung.
3. Bindung
z Vorgehen beruht auf der
„Web Service Architektur“
288
© W. Wahlster, DFKI
Technologie-Ebenen für Web Services
Entdeckung
Entdeckung
Beschreibung
Beschreibung
Verpackung
Verpackung
Transport
Transport
Netzwerk
Netzwerk
289
z Modularisierung der Aufgaben
z Angepasst an Internet Stack
z Entdeckung (discovery): finde
die Beschreibung von Web
Services
z Beschreibung (description):
beschreibe einen Web Service
z Verpackung (packaging):
kodiere die Daten in einem
allg. verständlichen Format
(=marshalling, serialization)
z Transport: Datentransport
zwischen Prozessen
z Netzwerk: Kommunikation
zwischen Maschinen im Netz
© W. Wahlster, DFKI
Wichtige Technologien für Web Services
z Web Services beruhen vor allem auf den
folgenden Technologien:
– XML als übergreifende
Datenbeschreibungssprache
– TCP/IP als zentrale Internet-Protokollfamilie
– HTTP, SMTP (Simple Mail Transfer Protocol)
als Datentransportprotokolle zwischen
Anwendungen
– WSDL: Web Services Description Language
– UDDI: Universal Description, Discovery, and
Integration
290
© W. Wahlster, DFKI
N-Tier Architekturen
z Verteilte (Web-)Anwendungen werden heute als
sog. „N-Tier-Anwendungen“ entwickelt (N=2,3,4)
z Jedes „Tier“ (Layer, Ebene) hat seine eigene
Aufgabe
z Vorteile
– geringere Komplexität der einzelnen Teile
– Verteilung der Implementierungsaufgaben
– Flexibilität bei der Verteilung der einzelnen Aufgaben
(thin client)
– erleichterte Wartbarkeit (keine Client-Software,
Austausch von Versionen)
– Skalierbarkeit, Sicherheit
291
© W. Wahlster, DFKI
3- und 4-Tier-Architekturen
Tier 1:
Präsentation
Tier 2:
Geschäftslogik
Tier 3:
Daten
Tier 1:
Präsentation
292
Geschäftslogik
Tier 2:
Web
Server
Tier 3:
Application
Server
Tier 4: Daten
© W. Wahlster, DFKI
Präsentationsebene
z Benutzerschnittstelle
z heute häufig als „thin client“ ohne jegliche weitere
Anwendungslogik, implementiert über den WebBrowser
z wichtigste Funktionen
– Eingaben des Benutzers „abholen“
– Ausgaben/Ergebnisse der Server-Seite der Anwendung
darstellen
z Wichtigste Technologien
– HTML und WML, vor allem Formulare (dominierend)
– Java Applets
293
© W. Wahlster, DFKI
Ebene der Geschäftslogik
z In dieser Ebene findet sich der Großteil der
Anwendungslogik wieder, bei E-Commerce z.B.
– Warenkorbfunktionen
– Preisberechnungs- und Bezahlfunktionen
z Die Ebene kann aus Skalierbarkeits- und Sicherheitsgründen physisch weiter aufgeteilt sein in
– den Web-Server, der das direkte (und oft einzige)
Interface zum Benutzer darstellt
– den Application Server, der weitere standardisierte und
nutzbare Dienste bereit stellt (Transaktionen, Security)
z Technologien: Servlets, JSP (Java Server Pages),
ASP (MS Active Server Pages), CORBA, EJB
(Enterprise Java Beans)
294
© W. Wahlster, DFKI
Die Datenebene
z Diese Ebene hat die Aufgabe, die eigentlichen
Daten der Anwendung zu verwalten,
bei E-Commerce z.B.
- Kundendaten
- Produktdaten
- Bestellungen
z Typische Implementierungen
Datenbanken wie DB2, Oracle, SQL Server
Enterprise Resource Planning Systeme wie R/3
295
© W. Wahlster, DFKI
Sinn von Servicebeschreibungen
z Um zu wissen, wie ein Service benutzt werden
kann, muss der Aufrufer irgendeine Art von
Dienstbeschreibung besitzen.
z Standardverfahren: textuelle Beschreibung z.B.
auf einer Web-Seite
z Besser: verwende eine formale,
maschinenverarbeitbare Beschreibung mittels
einer Dienstbeschreibungssprache
z Beschrieben werden gewöhnlich die
Schnittstellen, deshalb: Interface Definition
Language (IDL)
296
© W. Wahlster, DFKI
Die Rolle formaler Beschreibungen in der Web
Service Architektur
z Das in der Abbildung
gezeigte Schema
funktioniert nur mittels
formalisierter
Beschreibungen.
z Alle drei Schritte
benötigen die ServiceBeschreibung:
– Registrierung macht das
Aussehen des Dienstes
bekannt
– Suche basiert auf formal
definierten
Eigenschaften
– Bindung des Dienstes
verwendet die formale
Beschreibung zum
korrekten Aufruf
297
Service
Service
Registry
Registry
1. Registrierung
Service
Service
Provider
Provider
3. Bindung
2. Suche
Service
Service
Consumer
Consumer
© W. Wahlster, DFKI
Aufgabe einer Beschreibung
z Eine formale Dienstbeschreibung
muss/sollte/kann die folgenden Fragen
beantworten:
– Wer benutzt den Dienst? Wer bietet ihn an?
– Was wird angeboten? Æ Dienstschnittstelle
– Wo wird der Dienst angeboten? Æ Endpunkte,
URLs
– Warum wird der Dienst angeboten? Æ Aufgabe,
meist nicht formal
– Wie wird der Dienst angeboten? Æ Beschreibung
in der Dienstschnittstelle
298
© W. Wahlster, DFKI
WSDL
z WSDL ist ein „proposed standard“ der W3C.
z Vorgeschlagen von IBM, Microsoft und
anderen
z Aktuelle Version: 1.1
z Verfügbar unter: http://www.w3.org/TR/wsdl
z WSDL ist wie SOAP eine Anwendung der
XML-Spezifikation. Ein WSDL-Dokument ist
konform zur WSDL-Schema-Definition.
z Eine WSDL-Spezifikation beantwortet drei
Fragen:
299
z Was tut ein Service – welche Operationen stellt er
bereit?
z Wie wird auf den Service zugegriffen –
Datenformate, Nachrichten?
z Wo findet sich der Service – URL, etc.?
© W. Wahlster, DFKI
WSDL-Informationsmodell
z Eine WSDL-Spezifikation besteht einerseits
– aus abstrakten Spezifikationen von
Nachrichtentypen etc., andererseits
– aus konkreten Implementierungen dieser
Spezifikationen, also dem aktuell verfügbaren
Dienst
z Zur Beschreibung der abstrakten
Fähigkeiten dient der portType, zur
Beschreibung der aktuellen
Implementierung das binding-Element.
z Die Bindung wird mit einer Adresse
kombiniert; so erhält man einen konkreten
Endpunkt, über den die Implementierung
angesprochen werden kann.
300
© W. Wahlster, DFKI
WSDL-Sprachelemente
z portType: die abstrakte Definition einer Schnittstelle
(entspricht einem Java Interface)
z message: eine Menge von Parametern, die von den
Operationen verwendet werden
z Typen: alle Datentypen, die in den Nachrichten verwendet
werden
z binding: beschreibt, wie die Elemente eines abstrakten
Interfaces in eine konkrete Repräsentation umgewandelt
werden (Kodierungsschema, SOAP über HTTP)
z port: beschreibt, wie eine Bindung an einem konkreten
Endpunkt realisiert wird
z service: eine Sammlung von Endpunkten
301
© W. Wahlster, DFKI
Zusammenhang der Elemente
part
type
(abstrakte) message
(abstrakte)
operation
(konkrete) message
(konkrete)
operation
Konkretisiert
durch
enthält
service
Abstrakte
Schnittstelle
PortType
konkrete
Bindung
Konkreter Endpunkt (port)
302
© W. Wahlster, DFKI
Struktur eines WSDL-Dokuments
z Ein Service ist also eine
Sammlung von Ports.
z Ein Port hat eine abstrakte
Definition (portType) und
eine konkrete Realisierung
(binding).
z PortTypes sind Sammlungen
von abstrakten Operationen,
etc.
z Entsprechend sind WSDLDokumente aufgebaut.
303
Datentypen
<wsdl:types/>
Nachrichten
<wsdl:message/>
Schnittstellen
<wsdl:portType/>
Services
<wsdl:/binding/>
<wsdl:service>
© W. Wahlster, DFKI
XML Schemata zur Datenbeschreibung
z Bei einer Servicebeschreibung muss klar sein,
welche Struktur die ausgetauschten Datentypen
haben.
z WSDL erlaubt im Prinzip jedes
Spezifikationsmittel, allerdings steht XML
Schema eindeutig im Vordergrund.
z Um bei der Definition möglichst flexibel
beliebige Schemabeschreibungen verwenden zu
können, werden Namespaces eingesetzt.
z Damit werden Namen von Datentypen in einen
lokalen Kontext gesetzt.
304
© W. Wahlster, DFKI
Abstrakte Servicebeschreibung
<definitions= ....>
<wsdl:message name=“sayHello_IN“>
<part name=“name“ type=“xsd:string“ />
</wsdl:message>
<wsdl:message name=“sayHello_OUT“>
<part name=“greeting“ type=“xsd:string“ />
</wsdl:message>
<wsdl:portType name=“HelloWorldInterface“>
<wsdl:operation name=“sayHello“>
<wsdl:input message=“tns:sayHello_IN“ />
<wsdl:output message=“tns:sayHello_OUT“ />
</wsdl:operation>
</wsdl:portType>
</definitions>
305
© W. Wahlster, DFKI
Ein SOAP-über-HTTP-Binding
<wsdl:binding name=“HelloWorldBinding“
type=“tns:HelloWorldInterface“>
<soap:binding stype=“rpc“
transport=“http://schemas.xmlsoap.org/soap/http“ />
<wsdl:operation name=“sayHello“>
<soap:operation soapAction=“urn:Hello“ />
<wsdl:input>
<soap body use=“encoded“ ... />
</wsdl:input>
....
</wsdl:operation>
<wsdl:binding>
306
© W. Wahlster, DFKI
Beispiel: Börsenkursabfrage
z Es soll ein Web Service beschrieben werden,
an den man als Anfrage ein Tickersymbol
schicken kann und dann als Antwort den
aktuellen Kurs erhält.
z Wir beschreiben den Dienst in 3 Dateien:
– Die Schemadefinition stockquote.xsd
– Die Operationen in stockquote.wsdl
– Den Service in stockquoteservice.wsdl
307
© W. Wahlster, DFKI
stockquote.xsd
<?xml version=“1.0“?>
<schema
targetNamespace="http://example.com/stockquote.xsd"
xmlns="http://www.w3.org/2000/10/XMLSchema">
<element name="TradePriceRequest">
<complexType>
<all>
<element name=“tickerSymbol" type="string"/>
</all>
</complexType>
</element>
<element name="TradePriceResult">
<complexType>
<all>
<element name="price" type="float"/>
</all>
</complexType>
</element>
</schema>
308
© W. Wahlster, DFKI
stockquote.wsdl
<?xml version="1.0"?>
<definitions name="StockQuote"
targetNamespace="http://example.com/stockquote.wsdl"
xmlns:tns="http://example.com/stockquote/stockquote.wsdl"
xmlns:xsd1="http://example.com/stockquote.xsd"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns="http://schemas.xmlsoap.org/wsdl/">
<import namespace=“http://example.com/stockquote/schemas“
location=“http://example.com/stockquote/stockquote.xsd“>
<message name="GetLastTradePriceInput">
<part name="body" element="xsd1:TradePriceRequest"/>
</message>
<message name="GetLastTradePriceOutput">
<part name="body" element="xsd1:TradePriceResult"/>
</message>
<portType name="StockQuotePortType">
<operation name="GetLastTradePrice">
<input message="tns:GetLastTradePriceInput"/>
<output message="tns:GetLastTradePriceOutput"/>
</operation>
</portType>
</definitions>
309
© W. Wahlster, DFKI
stockquoteservice.wsdl
<?xml version="1.0"?>
<definitions name="StockQuote"
targetNamespace="http://example.com/stockquote/service"
xmlns:tns="http://example.com/stockquote/service"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns="http://schemas.xmlsoap.org/wsdl/">
<import namespace=“http://example.com/stockquote/definitions“
location=“http://example.com/stockquote/stockquote.wsdl“>
<binding name="StockQuoteSoapBinding" type="tns:StockQuotePortType">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="GetLastTradePrice">
<soap:operation
soapAction="http://example.com/GetLastTradePrice"/>
</operation>
</binding>
<service name="StockQuoteService">
<documentation>My first service</documentation>
<port name="StockQuotePort" binding="tns:StockQuoteSoapBinding">
<soap:address location="http://example.com/stockquote"/>
</port>
</service>
</definitions>
310
© W. Wahlster, DFKI
WSDL-Werkzeuge
z Auf der Basis von WSDL-Dokumenten
können nun natürlich wieder eine Reihe
von Werkzeugen implementiert werden:
– Generierung von Java-Klassen und
verschiedenen Code-Stücken, z.B. SOAPZugriff
– Automatisches Deployment von Web Services
– Automatische Registrierung von Web Services
bei UDDI
311
© W. Wahlster, DFKI
Service Discovery
z WSDL legt fest, wie ein Service aufgerufen
werden kann
– URL des Services
– Information über Methoden / Parameter
z Wie wird das WSDL Dokument zwischen
Client und Server ausgetauscht?
– Ein verteiltes System wird von einem Team
geschrieben: Austausch z. B. via Email
(homogenes System)
– Ein System wird von unterschiedlichen Teams
erstellt: Austausch über ein Repository
(heterogenes System)
312
© W. Wahlster, DFKI
Repository Funktionalität
z Ein Service Repository speichert eine
Vielzahl von Metadaten, welche die Services
funktional beschreiben und die Suche
ermöglichen
z Die Funktionalität ist unterschiedlich zum
Naming Service
– Ein Naming Service setzt lediglich den logischen
Namen eines bereits bekannten Services in eine
physikalische Adresse um
– Bei Web Services übernehmen dies die Internet
DNS Server
313
© W. Wahlster, DFKI
UDDI
z UDDI steht für Universal Description Discovery
and Integration
– Wurde Ende 2000 von IBM, Microsoft und Ariba initiiert
– Inzwischen sind einige hundert Firmen dem UDDI
Konsortium beigetreten (u.a. Oracle, SAP)
z UDDI spezifiziert Standards zur Publikation und
Suche von Web Services
z Schnittstellen
– Manuell per Browser
– Automatisiert per Web Services API
314
© W. Wahlster, DFKI
Das Globale UDDI Repository
z Die Spezifikationen werden in einem globalem
Web Service Repository implementiert
z Die drei Initiatoren unterhalten die technische
Infrastruktur
– Drei Server die untereinander Informationen replizieren
• http://uddi.microsoft.com
• http://www.ibm.com/services/uddi
• http://www.ariba.com
– Registrierungsmechanismus
– Filterung von SPAM Einträgen
315
© W. Wahlster, DFKI
Problem: Vertrauensverhältnis
z Das globale UDDI Repository ermöglicht eine
Vielzahl von Anwendungen
– Beispiel: finde einen Web Service, der Fahrpläne der
Fähre von Rom nach Sardinien liefert
z In wieweit kann einem bisher unbekanntem
Service vertraut werden?
– Betrug ist nicht ausgeschlossen
– Qualität gelieferter Teile
– Termingerechte Lieferung
z Es ist unwahrscheinlich, dass große
Transaktionen ohne vorherigen Kontakt / Verträge
abgeschlossen werden
316
© W. Wahlster, DFKI
Lokale Repositories
z Eine naheliegende Lösung besteht darin, UDDI im
kleineren / kontrollierten Rahmen einzusetzen
– Dies wird von den UDDI Initiatoren explizit
vorgeschlagen und erlaubt
z Anwendungsbeispiele:
– Management von Services innerhalb einer großen Firma
Vertrauen innerhalb der Firma ist gegeben
– B2B Internet Marktplatz
Zutritt zum Marktplatz ist nur nach vertraglicher
Bindung und Prüfung erlaubt
317
© W. Wahlster, DFKI
UDDI Browser Interface: Publikation
318
© W. Wahlster, DFKI
UDDI Browser Interface: Suche
319
© W. Wahlster, DFKI
UDDI Browser Interface: Suche II
320
© W. Wahlster, DFKI
UDDI Datenstrukturen: White Pages
z White Pages beinhalten
Informationen über die Institution,
die Services bereitstellt
– Name
– Telefon
z Dies ist vergleichbar mit der
Information im Telefonbuch
321
© W. Wahlster, DFKI
UDDI Datenstrukturen: Yellow Pages
z Die Yellow Pages erlauben eine Klassifikation der
Institutionen nach verschiedenen Schemata
z Momentan werden unterstützt:
– Geographisch (ISO 3166)
– Branchen (NAICS)
– Services / Produkte (UN / SPSC)
z Es können auch eigene Klassifikationsschemata
definiert werden (besonders interessant für lokale
UDDI Repositories)
z Dies entspricht den Gelben Seiten
322
© W. Wahlster, DFKI
UDDI Datenstrukturen: Green Pages
z Green Pages beinhalten technische
Informationen
– Angebotene Web Services
– Wie sind diese aufzurufen
z Technical Models (tModel) werden zur
Identifikation einer bestimmten Art von
Service verwendet
– Diese kann auf ein WSDL Dokument verweisen
– Sie kann sich aber auch auf vorab definierte
Standards wie z.B. RosettaNet beziehen
323
© W. Wahlster, DFKI
UDDI Datenmodell
businessEntity (white
pages)
Name, desc, contacts
businessServices
businessService
Bindings (green pages)
categoryBag (yellow
pages)
...
identifierBag
...
accessPoint URL
tModel
categoryBag (yellow
pages)
Verweise werden durch
UUIDs (universally unique
identifiers) hergestellt
categorization
Name, desc,
UUID
tModel
Specification
z.B. WSDL Doc
Name, desc,
UUID
identifier
Name, desc,
UUID
324
© W. Wahlster, DFKI
Firmeninformation im UDDI Format
325
© W. Wahlster, DFKI
Service Discovery zur Designzeit
z Services werden dem Entwickler mit Hilfe
eines Browsing Werkzeuges angezeigt
– Entwickler wählt den aufzurufenden Service
über die Browser Schnittstelle
– Stubs (Stummel, Kurzersatz für längeres
Programm) werden generiert
– Programmieren des Service Aufrufs
– Kompilieren des Projekts
z Funktioniert ähnlich wie bereits bekannte
Objektbrowser
326
© W. Wahlster, DFKI
Service Discovery zur Laufzeit
z Die Auswahl der Services erfolgt erst zur Laufzeit
– Entwickler wählt tModel (Service Interface ID)
– Stubs werden generiert
– zur Laufzeit Suche der passenden Services über die
Web Services UDDI API
– diese werden dann über den Stub aufgerufen
z Mittels dynamisch compiliertem und gebundenem
Code könnte sogar die Auswahl der tModels zur
Laufzeit erfolgen
327
© W. Wahlster, DFKI