MatthiasKirchmayr,SS2003 SeminarInternetDiensteWebservices Universit¨atUlm

Universit¨at Ulm

Seminar Internet Dienste

Webservices

Matthias Kirchmayr, SS 2003

Inhaltsverzeichnis

1 Motivation 1

2 Definition 1

3 XML & Co. 3

3.1 XML - eXtensible Markup Language . . . . 3

3.2 SOAP - Simple Object Access Protocol . . . . 3

3.3 WSDL - Web Service Description Language . . . . 5

3.4 UDDI - Universal Description, Discovery and Integration . . . . 7

3.5 Zusammenfassung . . . . 8

4 Sicherheitsaspekte 9 5 Anwendungsbeispiele 9 5.1 B2B - Business to Business . . . . 9

5.2 EAI - Enterprise Application Integration . . . . 9

1 MOTIVATION 1

1 Motivation

Durch den Boom des Internets w¨ahrend der 90iger Jahre und die weiterhin steigende Anzahl an neuen Informationen, ist es notwendig geworden, m¨oglichst viele Berei- che des Internets zu automatisieren. So ist es also ein Ziel, Anwendungen miteinander kommunizieren zu lassen, ohne das der Datenaustausch “von Hand“ geregelt werden muss. Hierf¨ur sind nat¨urlich gewisse Voraussetzungen notwendig. Ein Ansatz wur- de bereits 1991 von der Object Management Group (OMG) entwickelt. Bei CORBA (Common Object Request Broker Architecture) wird durch Einsatz von Middleware ei- ne orts-, plattform- und implementations-unabh¨angige Kommunikation zwischen Ap- plikationen erm¨oglicht.

Die Idee der Web Services besteht hingegen darin, durch den Einsatz von webbasier- ten Standards, Middleware zu ersetzen. Wie k¨onnte nun also so ein Web Service aus- sehen? Ein beliebtes Beispiel hierf¨ur ist die Reiseplanung. Man reserviert in Internet einen Flug und m¨ochte nun auch gleichzeitig das Hotel, einen Mietwagen, etc. buchen.

Bisher musste man sich nun die entsprechenden Seiten suchen und dann die Termine abgleichen. Web Services erm¨oglichen nun, dass durch das System der Fluggesell- schaft die n¨otigen Informationen weitergegeben werden und man direkt Angebote der passenden Hotels, ... erh¨alt.

2 Definition

A Web Service is a software application identified by a URI, whose interfaces and binding are capable of being defined, described and discovered by XML artifacts and supports direct interactions with other software applications using XML based messa- ges via Internet-based protocols.[1]

Ein Web Service ist folglich eine Softwareanwendung, welche durch XML definiert wird und mittels bestehender Internet-Protokolle (TCP/IP, ...) mit anderen Anwendun- gen kommunizieren kann.

Web Services lassen sich ¨uber einen Protokollstack beschreiben. Die in Abb. 1 (S. 2) bezeichneten Schichten ¨ubernehmen hierbei folgende Aufgaben. Als Basis dient die Transportschicht. Hier wird das verwendete Transportprotokoll festgelegt. Die dar¨uber- liegende Schicht ist daf¨ur verantwortlich, die Nachrichten in ein XML-Format umzu- wandeln. Diese Schicht wird durch SOAP repr¨asentiert. Die Funktionalit¨at des Dienstes wird in der n¨achsten Schicht (Description) definiert. Zuletzt wird dann die Entdeckung des Dienstes durch UDDI geregelt.

Hieraus l¨asst sich bereits die Bedeutung der Standards SOAP, WSDL und UDDI, er-

kennen, welche im folgenden noch genauer beschrieben werden.

2 DEFINITION 2

Discovery (UDDI)

Description (WSDL)

Transportschicht (HTTP, SMTP, FTP, ...) XML−messaging (SOAP, XML, XML−RPC)

Abbildung 1: Protokollstack

Alternativ lassen sich Web Services auch durch die Aufteilung in verschiedene Rollen beschreiben. Dabei exisitieren zumeist drei Rollen.

Dienstanbieter (Service Provider)

– Bietet Dienstleistung ¨uber das Internet an – Beschreibt und annonciert diesen Dienst

– ¨ Ubernimmt Implementierung, Wartung und Betrieb Dienstnachfrager (Service Requestor)

– Nutzt angebotenen Dienst

– Sucht angebotene Dienste nach gewissen Kriterien – Integriert Service in eigene Dienste und Applikationen Dienstmakler (Service Broker)

– Bietet Speicherung von Dienstbeschreibungen an – Verwaltet kategorisierte Dienstbeschreibungen

– Erm¨oglicht automatisiertes Auffinden existierender Dienste

3 XML & CO. 3 Da diese drei Rollen in der Regel verteilte Komponenten sind, k¨onnen keine identi- schen Grundvoraussetzungen gemacht werden. Deshalb soll durch die Einf¨uhrung von Standards die Unabh¨angigkeit der Dienste von sowohl der Plattform, als auch der zu- grundeliegenden Programmiersprache erreicht werden. In Verbindung mit der weiten Verbreitung (speziell der guten Verf¨ugbarkeit) des Internets ist somit die Integration eines Dienstes relativ einfach. Die daraus resultierende lose Kopplung erm¨oglicht das dynamische Binden der jeweiligen Dienste zur Laufzeit. Durch den Einsatz vom XML sind Web Services stark dokumentenorientiert.

3 XML & Co.

3.1 XML - eXtensible Markup Language

Wie bereits erw¨ahnt, bauen Web Services auf XML auf. Aber was ist eigentlich XML?

XML ist eine Metasprache, d.h. sie erfasst nicht nur die formalen Strukturen des Tex- tes, sondern sorgt daf¨ur, dass Dokumente in ihrem Aufbau gewissen Grundmustern folgen. Durch Trennung von Form und Inhalt sind Programmierer in der Lage, An- wendungen zu schreiben, welche mit solchen Dokumenten arbeiten k¨onnen. Genauso wie HTML ist auch XML ein textbasiertes Format, welches keine spezielle Anforde- rungen an Hardware oder Netzinfrastruktur stellt.

3.2 SOAP - Simple Object Access Protocol

Bei der Bereitstellung eines Diesntes ¨uber das Internet m¨ussen aus Sicht des Dienstan- bieters folgende Probleme gel¨ost werden:

Abwicklung der Kommunikation (Protokoll)

– synchrone Aufrufe ¨uber HTTP: Aufrufer wartet auf Antwort

– asynchrone Aufrufe ¨uber SMTP: Entkopplung von Aufruf und Antwort Struktur des Kommunikationsinhalts

Die bekannteste L¨osung hierf¨ur stellt SOAP dar. Die Grundidee dabei ist es, entfern- te Methodenaufrufe und Nachrichtenaustausch zu erm¨oglichen. Dabei trennt SOAP zwischen Nutzinformationen und Metadaten und bietet eine XML-Darstellung belie- biger Inhalte. Wie aus Abb. 1 (S. 2) leicht ersichtlich ist, ist SOAP unab¨angig von dem gew¨ahlten Transportprotokoll.

Abbildung 2 (S. 4) zeigt, wie eine SOAP Nachricht aufgebaut ist.

3 XML & CO. 4 Protocol Header

Der Protocol Header ist von dem Protokoll (z.B. HTTP) abh¨angig, auf dem die SOAP Nachricht transportiert wird. Darin befindet unter anderem auch Angaben zur ¨ Ubertragungsmethode (POST/GET) und zum Zielrechner.

SOAP Envelope

Die SOAP Envelope ist ein Container f¨ur die beiden Elemente SOAP Header und SOAP Body. Der SOAP Header enth¨alt Informationen ¨uber die SOAP Nachricht, w¨ahrend der SOAP Body die eigentliche Nachricht enth¨alt.

SOAP Header

Wie oben erw¨ahnt sind im Header Informationen ¨uber die SOAP-Nachricht ent- halten. Diese Informationen sind jedoch optional. Ebenfalls im Header k¨onnen Anweisungen f¨ur die aufgerufene Anwendung enthalten sein.

SOAP Body

Der SOAP Body enth¨alt die eigentliche XML-Nachricht. In ihr ist das aufzuru- fende Objekt mit der entsprechend aufzurufenden Methode angegeben. Weiter enth¨alt der Body die zu ¨ubergebenden Parameter als einzelne Tags.

SOAP Body

Message Name & Data

SOAP Envelope SOAP Header

Headers Protocol Header SOAP Message

Abbildung 2: Aufbau einer SOAP Nachricht

3 XML & CO. 5 Programm 3.1 (S. 5) ist ein Beispiel f¨ur eine SOAP Nachricht. Hier wird unter der Ad- dresse http://www.stock.org/stock die Methode GetStockPrice aufgerufen. In diesem Fall bekommt die Methode den Namen der Aktie (IBM) als Parameter ¨ubergeben.

Programm 3.1 Beispiel f¨ur einen Aufruf mit SOAP

<soap:Envelope>

<soap:Body>

<xmlns:m="http://www.stock.org/stock" />

<m:GetStockPrice>

<m:StockName>IBM</m:StockName>

</m:GetStockPrice>

</soap:Body>

</soap:Envelope>

Eine Antwort auf diese Anfrage k¨onnte folgende Form haben (Programm 3.2, S. 5).

Programm 3.2 Beispiel f¨ur eine Antwort mit SOAP

<soap:Envelope>

<soap:Body>

<xmlns:m="http://www.stock.org/stock" />

<m:GetStockPriceResponse>

<m:Price>34.5</m:Price>

</m:GetStockPriceResponse>

</soap:Body>

</soap:Envelope>

3.3 WSDL - Web Service Description Language

Mit Hilfe von WSDL wird definiert, welche Methoden beim Dienstanbieter aufge-

rufen werden k¨onnen und welche Parameter diese ben¨otigen. Desweiteren wird hier

festgelegt, welche R¨uckgabewerte diese Methoden produzieren. WSDL Dokumente

sind dabei in zwei Teile aufgeteilt (siehe Abb. 3, S. 6). Im ersten werden abstrakt die

verwendeten Datentypen (types), die ¨ubertragenen Daten (messages) und die aufrufba-

ren Methoden, sowie deren Parameter (portType) beschrieben. Im zweiten Teil werden

dann konkret sowohl der Kommunikationsendpunkt (service), d.h. die Adresse (¨ubli-

cherweise URL), als auch das verwendete Protokoll (binding) definiert. Ein WSDL

3 XML & CO. 6 Dokument wird vom Dienstanbieter erstellt und ¨uber einen Dienstmakler dem Dienst- nachfrager zur Verf¨ugung gestellt (vgl. Abb. 4, S. 8). Wie SOAP, so ist auch WSDL im Grunde ein XML Dokument.

Das Operation Element (siehe Abb. 3, S. 6) kann dabei folgendes sein:

“One-Way“

Eine Nachricht, die der Dienstnachfrager an den Dienstanbieter sendet, auf die er aber keine Antwort erhalten wird

“Request/Response“

Eine Nachricht, die der Dienstnachfrager an den Dienstanbieter sendet, worauf dieser eine Antwort sendet

“Solicit-Response“

Eine Nachricht, die der Dienstanbieter sendet, worauf der Dienstnachfrager ant- wortet

“Notification“

Der Dienstanbieter sendet eine Nachricht an den Dienstnachfrager

Konkrete Definition Abstrakte Definition

Bindings

Ports Operations

enthaelt enthaelt

Services

Operations

enthaelt

PortTypes Messages Types

Abbildung 3: Aufbau eines WSDL Dokuments

Mit dem Element ports wird lediglich der Registrierungsname des Web Services an-

gegeben.

3 XML & CO. 7

3.4 UDDI - Universal Description, Discovery and Integration

UDDI wurde aus der Idee heraus entwickelt, ein globales, plattformunabh¨angiges Netz- werk zu erschaffen, um:

Informationen ¨uber das Unternehmen in einer globalen Registry ablegen zu k¨onnen Gesch¨aftspartner zu ermitteln

Gesch¨aftsprozesse ¨uber Unternehmensgrenzen hinweg zu beschreiben und nutz- bar zu machen

UDDI unterst¨utzt die Suche nach dem passenden Dienst und bietet dar¨uber hinaus die M¨oglichkeit, aus einer Großzahl von Unternehmen und Angeboten w¨ahlen zu k¨onnen bzw. gew¨ahlt zu werden. Dadurch lassen sich die grundlegenden Fragen ei- ner Gesch¨aftsbeziehung

Welche Firma den Dienst anbietet Wo sich der angebotene Dienst befindet Welcher Service angeboten wird

Wie der Dienst benutzt werden kann

beantworten. UDDI stellt somit einen Verzeichnisdienst (und dadurch auch selbst einen Web Service) dar. Die hier verwalteten Daten werden kategorisch gespeichert und k¨onnen gezielt gesucht werden. Die g¨angisten Kategorien sind

“white pages“

nach Namen sortiertes Register

“yellow pages“

nach Kategorien sortiertes Register

“green pages“

Detailinformationen

Ins Leben gerufen wurde UDDI von Ariba, IBM und Mircosoft, ist aber inzwischen

ein weithin akzeptierter Standard.

3 XML & CO. 8

3.5 Zusammenfassung

Abbildung 4 (S. 8) soll nun verdeutlichen, wie SOAP, WSDL und UDDI eingesetzt werden, um die Kommunikation zwischen Dienstanbieter, Dienstnachfrager und Dienst- makler zu regeln.

(Service Requestor) Dienstnachfrager Dienstmakler

(Service Broker)

UDDI

SOAP Dienstanbieter

(Service Provider) WSDL

Abbildung 4: Web Service Architektur

4 SICHERHEITSASPEKTE 9

4 Sicherheitsaspekte

Bei allen Anwendungen, welche das Internet als Medium benutzen, muss man sich die Frage stellen, ob sie ausreichende Sicherheitsmechanismen stellen. Gerade im Be- reich B2B (Business to Business) m¨ussen Authentifizierung, Authorisierung und Da- tenschutz sichergestellt sein. Gen¨ugt also SOAP solchen Anforderungen? SOAP bie- tet keine Mechanismen, welche den sicherheitstechnischen Anforderungen gen¨ugen w¨urden. Aber das war auch kein Ziel f¨ur SOAP. Dennoch lassen sich die gew¨unsch- ten Eigenschaften nat¨urlich erreichen. Zum einen kann SOAP derart erweitert wer- den, dass durchaus akzeptable Resultate erzielt werden (vergleichbar mit dem SSL ¹ -Zertifizierungsverfahren)[8]. Zum anderen lassen sich auch die existierenden Mecha- nismen des gew¨ahlten Transportprotokolls nutzen (beispielsweise HTTPS).

5 Anwendungsbeispiele

5.1 B2B - Business to Business

Wie bereits erw¨ahnt lassen sich durch Web Services eigene Dienste fremden Unter- nehmen zur Verf¨ugung zu stellen (z.B. Kreditkartenvalidisierung). Diese Art der Ver- wendung ist wohl die naheliegenste. Denkbare w¨are aber auch die Realisierung un- ternehmens¨ubergreifender Gesch¨aftsprozesse mit Hilfe solcher Dienste. Somit k¨onnen Lieferanten oder Partner in die eigene Systemwelt integriert werden.

5.2 EAI - Enterprise Application Integration

Eine weitere Einsatzm¨oglichkeit ist die Integration unternehmensinterner Gesch¨aftpro- zesse. Dadurch k¨onnen Kosten und Aufwand minimiert werden. Die Wiederverwert- barkeit der Dienste f¨uhrt ebenfalls zu einer Kosteneinsparung.

1 Secure Sockets Layer

LITERATUR 10

Literatur

[1] http://www.w3.org [2] http://www.jeckle.de [3] http://www.fzi.de

[4] http://www.firstsurf.com [5] http://informatik.hsr.ch

[6] www3.informatik.tu-muenchen.de [7] http://www.newtelligence.com/

[8] http://discuss.develop.com/

ABBILDUNGSVERZEICHNIS 11

Abbildungsverzeichnis

1 Protokollstack . . . . 2

2 Aufbau einer SOAP Nachricht . . . . 4

3 Aufbau eines WSDL Dokuments . . . . 6

4 Web Service Architektur . . . . 8

Beispielprogramme 3.1 Beispiel f¨ur einen Aufruf mit SOAP . . . . 5

3.2 Beispiel f¨ur eine Antwort mit SOAP . . . . 5