Inhaltsverzeichnis

1.  Einleitung  1

1.1.  Aufgabenstellung  1

1.2.  Aufbau der Arbeit  2

2.  Fachliches Umfeld - Web-Service-Technologien  3

2.1.  Web-Services  3

2.1.1.  Definition  3

2.1.2.  Einsatzgebiete  5

2.1.3.  Web-Service-Interoperabilit at  5

2.1.4.  Web-Service-Sicherheit  6

2.2.  Web-Service-Vorl aufer und -Alternativen  6

2.3.  XML-RPC  7

2.4.  SOAP  10

2.5.  REST  12

2.6.  WSDL  13

2.6.1.  WSDL-Aufbau  14

2.6.2.  Nachrichtenstil und Kodierungsstil  15

2.7.  UDDI  17

2.8.  Serviceorientierte Architektur (SOA)  18

3.  Ist-Beschreibung des Xtranet Staging Site Systems  19

3.1.  Aufbau und grunds atzlicher Nutzen des Systems  19

3.2.  Begrifflichkeiten  20

3.3.  Funktionalit aten des Systems f ur den Kunden  21

4.  Anforderungsdefinition des Xtranet-Web-Service  24

4.1.  Zielbestimmungen  24

4.1.1.  Musskriterien  24

4.1.2.  Wunschkriterien  25

4.1.3.  Abgrenzungskriterien  25

4.2.  Produkteinsatz  26

4.2.1.  Anwendungsbereiche  26

4.2.2.  Zielgruppen  26

4.2.3.  Betriebsbedingungen  26

4.3.  Produktumgebung  27

I

Inhaltsverzeichnis II

4.3.1.  Software  27

4.3.2.  Hardware und Orgware  27

4.4.  Produktfunktionen und Produktdaten  27

4.5.  Produktleistungen  31

4.6.  Benutzungsoberfl ache  31

4.7.  Testszenarien und Testf alle  31

5.  Entwurf  33

5.1.  Wahl der zu verwendenden Technologien  33

5.2.  Wahl der zu verwendenden Entwicklungswerkzeuge und -umgebungen  34

5.3.  Entwurf des Xtranet-Web-Service  35

5.3.1.  Datenobjekte  36

5.3.2.  Listenobjekte  37

5.3.3.  Fehlerbehandlung  38

5.3.4.  Die Xtranet-Web-Service-Klasse  39

5.3.5.  E-Mail-Benachrichtigungen  42

5.3.6.  Web-Service-Client  42

6.  Realisierung des Xtranet-Web-Service  45

6.1.  WSDL-Beschreibung der SOAP-Nachrichten  45

6.2.  Realisierung des SOAP-Servers  50

6.2.1.  Realisierung der Xtranet-Web-Service-Klasse  50

6.2.2.  Realisierung der Error-Klasse  52

6.2.3.  Realisierung der Daten- und Listenklassen  53

6.2.4.  Realisierung des SOAP-Endpunkts  54

6.3.  Realisierung der SOAP-Clients  54

6.3.1.  Realisierung des PHP5-SOAP-Clients  54

6.3.2.  Realisierung des Java-Axis-SOAP-Clients  59

6.3.3.  Realisierung des SOAP-Clients in Flash 8 Actionscript  62

7.  Test des Xtranet-Web-Service  65

7.1.  Funktionale Tests  65

7.2.  Interoperabilit atstests  66

7.3.  Leistungstests  67

8.  Schlussbetrachtung  69

8.1.  Zusammenfassung  69

8.2.  Bewertung und Ausblick  71

A.  Datenbankstruktur des Xtranet-Systems  73

B.  Verzeichnisse  74

Abk  urzungen  75

Glossar   76

Inhaltsverzeichnis III

Listingverzeichnis   79

Abbildungsverzeichnis   80

Tabellenverzeichnis   81

Literaturverzeichnis   84

1. Einleitung

Anfang dieses Jahrzehnts erlebte die technische Idee der Web-Services einen gewissen Hype. Man begann in dieser Zeit eine Gruppe vom Technologien zu standardisieren, die vom Begriff Web-Service umschrieben werden. In diesem Zusammenhang immer wieder erw¨ ahnte Vorzeigebeispiele sind die Web-Services von Amazon, Google und eBay. Inzwischen ist es zwar etwas ruhiger um den Web-Service-Begriff geworden, was aber auch daran liegt, dass sich Web-Services inzwischen etabliert haben. Nichtsdestotrotz werden derzeit verschiedene Web-Service-Technologien von Standardisierungskonsortien wie dem ” World Wide Web Consortium“ (W3C) weiterentwickelt.

Web-Services erm¨ oglichen eine Kommunikation von Systemen auf unterschiedlichen Platt-formen und in verschiedensten Programmiersprachen untereinander. Interessant ist dies zum einen innerhalb von Firmen, die verschiedene, ¨ uber die Zeit getrennt voneinander

entwickelte Software-Systeme miteinander integrieren wollen. Zum anderen erm¨ oglichen Web-Services die Kommunikation zwischen Software-Systemen verschiedener Gesch¨ aftspartner. Die vorliegende Arbeit dokumentiert die Entwicklung eines Web-Service f¨ ur einen solchen Business-to-Business Anwendungsfall.

1.1. Aufgabenstellung

Das 2004 geschaffene Extranet namens ”

m¨ oglicht einer Werbeagentur mit ihren Kunden ¨

zu kommunizieren. Die Agentur kann u. a. Dateien, die sie dem Kunden zur Begutachtung zur Verf¨ ugung stellen will, in das System hochladen. Der Kunde hat die M¨ oglichkeit, uber eine HTML-Benutzeroberfl¨ ache (Browser-Interface) auf die verschiedenen Arbeiten ¨

zuzugreifen, sie zu kommentieren und freizuzeichnen.

Im Rahmen dieser Arbeit soll prototypisch ein Web-Service entworfen und implementiert werden, der es dem Kunden erm¨ oglicht, passwortgesch¨ utzt ¨ uber eine Programmierschnittstelle (API) auf seinen Teil des Extranets zugreifen zu k¨ onnen. Es sollen mindestens die gleichen Funktionalit¨ aten zur Verf¨ ugung stehen, wie beim Zugriff ¨ uber das

Browser-Interface, z. B. das Abrufen von Informationen ¨ uber die Projekte und Dateien des Kunden.

Die zu entwickelnde Web-Service-API erm¨ oglicht es einem Programmierer des Kunden, eine Anwendung in einer fast beliebigen, g¨ angigen Programmiersprache zu schaffen, die

1

1. Einleitung 2

auf das ” Xtranet“ System zugreift. Der Kunde h¨ atte so die M¨ oglichkeit, Inhalte aus dem Agentur-Extranet - z. B. Informationen ¨ uber Auftr¨ age und Dateien - in eigene Systeme einzubinden.

1.2. Aufbau der Arbeit

Kapitel 2 erkl¨ art den Begriff Web-Service und beschreibt verschiedene Spezfikationen von Web-Service-Technologien und ihre Zusammenh¨ ange, deren Kenntnis Voraussetzung f¨ ur das Verst¨ andnis dieser Arbeit ist.

Kapitel 3 beschreibt den Aufbau, die Begrifflichkeiten und die Funktionalit¨ aten des Xtranet Staging Site System“. Diese Informationen sind ebenfalls grundlegend zum

”

Verst¨ andnis der folgenden Kapitel.

Kapitel 4 definiert die Anforderungen an die zu schaffende Web-Service-Schnittstelle. Der Aufbau des Kapitels erfolgt in Anlehnung an den typischen Aufbau eines Pflichtenheftes, ist jedoch nicht als vollst¨ andiges Pflichtenheft zu verstehen.

Kapitel 5 erl¨ autert die Wahl der zu verwendenden Technologien und Werkzeuge, sowie den Entwurf des zu entwickelnden ” Xtranet“-Web-Service-Systems.

Kapitel 6 beschreibt die Realisierung des zuvor entwickelten Systementwurfs.

Kapitel 7 beschreibt die abschließende Testphase.

Kapitel 8 fasst die Arbeit noch einmal zusammen und bewertet das Ergebnis.

2. Fachliches Umfeld -Web-Service-Technologien

Im folgenden Abschnitt werden zun¨ achst Definitionen des Web-Service-Begriffs beschrieben. Danach werden die Vorl¨ aufer und Alternativen zu Web-Services kurz erw¨ ahnt, bevor auf konkrete Web-Service-Technologien eingegangen wird. Abschließend wird noch der Begriff der serviceorientierten Architektur (SOA) erl¨ autert.

2.1. Web-Services

Wenn man die Bedeutung zun¨ achst nur vom Begriff Web Service abzuleiten versuchen w¨ urde, k¨ onnte es zu Missverst¨ andnissen kommen. Man k¨ onnte vermuten, ein Benutzer greift mit Hilfe eines Clients - also z. B. eines Browsers - ¨ uber ein Netzwerk ( ” Web“) auf die Funktionalit¨ aten ( Services“) einer Applikation auf einem entfernten Server zu,

”

welcher eine Antwort zur¨ uckliefert, die auf dem Browser dargestellt wird, wie z. B. beim Bestellen von Artikeln in einem Webshop. Es stellt sich also eine klassische Mensch-Maschine-Kommunikation dar, worum es sich bei Web-Services aber genau nicht handelt!

2.1.1. Definition

Paul Prescod formuliert zun¨ achst sehr allgemein:

A web service is a set of functionality offered on the public Internet or a

”

private intranet designed to be used by another computer without real-time human oversight.“ [Pre06a]

Ohne auf bestimmte Protokolle oder Technologien einzugehen, stellt Prescod einen Web-Service allgemein als eine Funktionalit¨ at dar, die ein Computer ¨ uber das Internet oder

in einem Intranet automatisch verwenden kann. Das heißt, es handelt sich bei Web-Services um eine Maschine-Maschine-Kommunikation. Nicht ein Mensch, sondern eine Applikation ist der Web-Service-Client (WS-Client), der auf die Funktionen (den ” Service“) zugreift, die eine andere, entfernte Applikation bereitstellt. Man spricht davon, dass ein WS-Client einen Web-Service ” konsumiert“.

3

2. Fachliches Umfeld - Web-Service-Technologien 4

Folgende zwei Definitionen von Ethan Cerami (O’Reilly) und von ” IBM Developer-Works“ werden konkreter:

(. . . ) a Web service is any piece of software that makes itself available over

”

the Internet and uses a standardized XML messaging system.“ [Cer02]

Web services is a technology that allows applications to communicate with

”

each other in a platform- and programming language-independent manner. A Web service is a software interface that describes a collection of operations that can be accessed over the network through standardized XML messaging. It uses protocols based on the XML language to describe an operation to execute or data to exchange with another Web service. A group of Web services interacting together in this manner defines a particular Web service application in a Service-Oriented Architecture (SOA).“ [IBM06b]

Die beiden Definitionen benennen XML-basierte Sprachen als wichtigen Baustein f¨ ur eine Kommunikation zwischen Software-Applikationen, die plattform- und programmiersprachenunabh¨ angig sind. Die Definition von ” IBM DeveloperWorks“ benennt außerdem das

Konzept der serviceorientierten Architektur, die auf Web-Services aufbaut. Mehr dazu in Kapitel 2.8.

Das Zugreifen auf Methoden einer entfernten Software-Applikation ist nichts Neues und u. a. als Remote Procedure Call (RPC) bekannt. Es gibt verschiedene Technologien, die den maschinen¨ ubergreifenden Austausch zwischen Anwendungen erm¨ oglichen (mehr dazu in Kapitel 2.2). Im Unterschied dazu k¨ onnen aber Applikationen, die mit Hilfe von Web-Services kommunizieren, sich auf unterschiedlichen Plattformen befinden und in verschiedenen Programmiersprachen geschrieben sein. Sie k¨ onnen miteinander kommunizieren, da sie sich auf eine standardisierte Sprache (XML-basierende Protokolle, wie SOAP, Kapitel 2.4) und einen standardisierten Transportweg (z. B. HTTP) einigen. Abbildung 2.1 zeigt eine vereinfachte Darstellung.

Fast synonym zum Web-Service-Begriff wird heute das vom ” World Wide Web Consor-

tium“ (W3C) standardisierte Protokoll-Paar SOAP/WSDL genannt, obwohl es z. B. mit

2. Fachliches Umfeld - Web-Service-Technologien 5

XML-RPC und REST noch Alternativen zu SOAP gibt. Auf die genannten Technologien wird sp¨ ater noch im Detail eingegangen.

Das W3C hat noch in seinem Web-Services-Glossar 11/2002 eine ¨ ahnliche allgemeine Erkl¨ arung des Begriffs Web-Service gegeben [W3C02], wie die oben zitierten Definitionen. In der aktuellen Version des Web-Services-Glossar des W3C von 02/2004 benennt es aber schon die zu Grunde liegenden Technologien, die es selbst standardisiert:

A Web service is a software system designed to support interoperable machine-

”

to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAPmessages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards.“ [W3C04b]

Aus Sicht des W3C ist ein Web-Service ein System f¨ ur eine Maschine-Maschine-Interaktion, dessen Schnittstellen mit WSDL beschrieben werden und mit dem andere Systeme mittels ¨ uber HTTP bef¨ orderte SOAP-Nachrichten interagieren.

2.1.2. Einsatzgebiete

Paul Prescod beschreibt zwei Haupteinsatzfelder f¨ ur Web-Services [Pre06b, Kapitel 4]:

Als erstes k¨ onnen sie innerhalb einer Firma eingesetzt werden, um die Integration verschiedener Software-Systeme zu erm¨ oglichen oder zu vereinfachen (Enterprise Application Integration (EAI). Mittels Web-Services k¨ onnen so Schnittstellen geschaffen werden, um die verschiedenen Systeme miteinander interagieren zu lassen.

Als zweites Einsatzfeld nennt Prescod die Cross-Organization Integration (B2B), also eine Business-to-Business Kommunikation. Eine Firma kann ihren Gesch¨ aftspartnern oder Kunden eine ¨ offentliche Schnittstelle anbieten, die eine programmatische Interaktion mit den Software-Systemen der Firma erlaubt, z. B. um Preisausk¨ unfte zu geben oder ein direktes Bestellen von Produkten zu erm¨ oglichen.

In dieser Arbeit handelt es sich um einen Web-Service in einer B2B-Umgebung. Die Agentur stellt ihren Kunden eine Schnittstelle auf das Extranet-System zur Verf¨ ugung.

2.1.3. Web-Service-Interoperabilit¨ at

Der Web-Service-Anbieter kennt nicht unbedingt die Software-Architekturen des Gesch¨ aftspartners, der den Web-Service konsumieren will. Er muss aber einen m¨ oglichst einfachen Zugriff auf das System sowie eine Interoperabilit¨ at mit m¨ oglichst vielen verschiedenen und g¨ angigen Programmiersprachen und Plattformen erm¨ oglichen.

2. Fachliches Umfeld - Web-Service-Technologien 6

F¨ ur fast alle g¨ angigen Programmiersprachen gibt es heute Implementierungen von Web-Service-Technologien - insbesondere von SOAP/WSDL. Die teilweise komplexen Tech-nologiestandards wurden bewusst zum Teil recht allgemein und offen gehalten, was dazu f¨ uhrt, dass einige Web-Service-Implementierungen Eigenheiten mit sich bringen und nicht immer voll kompatibel mit anderen Implementierungen sind. Um eine m¨ oglichst hohe Interoperabilit¨ at zu f¨ ordern, arbeitet die ” Web Services Interoperability Organization“

(WS-I) an verschiedenen Hilfsmitteln. Als wichtigstes Hilfsmittel sind die WS-I-Profile zu nennen. Das sind Spezifikationen, die beschreiben, wie ein Web-Service aussehen sollte. Bisher gibt es das WS-I Basic Profile, welches derzeit in Version 1.1 vorliegt [Web04]. Dazu stellt die WS-I Testwerkzeuge zur Verf¨ ugung, mit denen man einen Web-Service auf seine Einhaltung eines WS-I-Profils ¨ uberpr¨ ufen kann.

2.1.4. Web-Service-Sicherheit

Da das System quasi ¨ offentlich im Internet zu erreichen ist, m¨ ussen Sicherheitsmechanismen wie Verschl¨ usselung und Passwortschutz verwendet werden.

Web-Service-Protokolle wie der SOAP-Standard definieren von sich aus keine Sicherheitsmechanismen. Die damit ¨ ubermittelten Daten werden also unverschl¨ usselt und un-

signiert transportiert. Zur Erh¨ ohung der Sicherheit k¨ onnte der Web-Server, der den Web-Service anbietet, den gesamten Transportkanal mit Hilfe von HTTPS verschl¨ usseln.

Alternativ k¨ onnen Web-Service-Erweiterungen verwendet werden, die Sicherheitsaspekte behandeln. Die Standardisierungsgruppe ” Organization for the Advancement of Structu-

red Information Standards“ (OASIS) verabschiedete dazu einen Standard ” WS-Security“

[OAS06], in dem verschiedene Sicherheitstechniken zusammengefasst werden. Dazu geh¨ oren u. a. Verschl¨ usselungen mittels XML-Encryption und Signaturen mittels XML-Signature.

2.2. Web-Service-Vorl¨ aufer und -Alternativen

Einige Programmiersprachen bringen Techniken mit, die eine RPC-Kommunikation mit entfernten Programmen, die in derselben Sprache geschrieben wurden, erm¨ oglichen. Diese Art der Maschine-Maschine-Kommunikation wird bei objektorientierten Sprachen Remoting genannt. Bekannte Beispiele sind Remote Method Invocation (RMI) in Java oder .NET Remoting von Microsoft. Wie gerade erw¨ ahnt, k¨ onnen sich also z. B. zwei entfernte Java-Programme oder zwei entfernte .NET-Programme miteinander unterhalten. Vorteil dieser Remoting-Technologien ist eine h¨ ohere Performance des bin¨ aren Datenaustauschs, im Vergleich zum Aufwand, der bei der XML-Serialisierung bzw. -Deserialisierung bei der Web-Service-Kommunikation betrieben werden muss. Ein großer Nachteil von Remoting ist aber auch klar zu erkennen: eine programmiersprachen¨ ubergreifende Kommunikati- on in heterogenen Umgebungen ist mit diesen Techniken nicht m¨ oglich. Diesen Nachteil

2. Fachliches Umfeld - Web-Service-Technologien 7

versuchte bereits CORBA (Common Request Broker Architecture) zu ¨ uberwinden. Es

steht als Kommunikationsvermittler zwischen Applikationen, welche in verschiedenen Sprachen entwickelt sein k¨ onnen. CORBA gilt allerdings als kompliziert [HL04, S.25], zu langsam und oftmals nicht kompatibel genug, wenn es um verschiedene Implemen-

”

tierungen und Standards ging“. [Wik06a]

2.3. XML-RPC

Bei XML-RPC handelt es sich um die erste Technologie, die den in Kapitel 2.1 genannten Web-Service-Definitionen entspricht.

Die Firma ” UserLand Software Inc.“ unter Leitung von Dave Winer entwickelte XML-RPC 1998. Die offizielle XML-RPC-Website von Dave Winer beschreibt das Protokoll wie folgt:

[XML-RPC is] a spec and a set of implementations that allow software

”

running on disparate operating systems, running in different environments to make procedure calls over the Internet. It’s remote procedure calling using HTTP as the transport and XML as the encoding. XML-RPC is designed to be as simple as possible, while allowing complex data structures to be transmitted, processed and returned.“ [US06]

Verschiedene entfernte Software-Systeme k¨ onnen mit XML-RPC Methoden ¨ uber HTTP

in Form XML-codierter Nachrichten aufrufen.

XML-RPC wurde mit den Ziel entwickelt, m¨ oglichst leicht verst¨ andlich und einfach implementierbar zu sein. Die letzte Spezifikation von XML-RPC ist aus dem Jahr 1999 [Win99].

F¨ ur die Parameter der Anfrage und die R¨ uckgabewerte der Antwort stehen in XML-RPC eine Reihe von Datentypen zur Verf¨ ugung, die in einfache und komplexe Datentypen unterschieden werden k¨ onnen. Tabelle 2.1 listet alle einfachen Datentypen auf.

2. Fachliches Umfeld - Web-Service-Technologien 8

Als komplexe Datentypen stellt XML-RPC das Array und die Struktur bereit.

Wie man in Listing 2.1 sieht, k¨ onnen die Werte des Arrays verschiedene Datentypen annehmen (in diesem Beispiel Integer, String und Boolean). Ein Indexwert wird nicht mitgef¨ uhrt. Sollen ein assoziatives Array oder ein Objekt mit Attributen verschiedener Datentypen in XML-RPC abgebildet werden, bietet sich die Struktur an. (Siehe Listing 2.2)

Eine Struktur besteht aus member-Elementen, welche je ein name- und value-Elemente- Paarenthalten. Diese Datentypen k¨ onnen nat¨ urlich beliebig ineinander verschachtelt werden. So kann z. B. ein value-Element einer Struktur ein Array aufnehmen.

Die eigentlichen Anfragen und Anworten werden in XML-RPC wie folgt definiert. Eine Anfrage wird in einem HTTP-POST-Request verschickt. Ein Aufruf f¨ ur eine Methode namens getJob, die Informationen eines Jobs mit der ID 12 zur¨ uckliefern soll, kann wie in Listing 2.3 dargestellt aussehen.

Das Wurzelelement der Anfrage ist methodCall. Nach dem Namen der Methode methodName folgen die zu ¨ ubergebenden Parameter unter params und param. Der

Parameterwert erscheint in value, wobei er noch einmal in ein Element gekapselt wird, das den Datentyp angibt.

Eine m¨ ogliche Antwort erfolgt im HTTP-Response. Das Wurzelelement der Antwort ist methodResponse, welches unter params den R¨ uckgabewert enth¨ alt.

Man beachte, dass die ¨ Ubergabeparameter bei der Anfrage und die R¨ uckgabewerte der Antwort keine identifizierenden Namen haben. Falls mehrere Parameter verwendet werden, m¨ ussen sie ¨ uber ihre Reihenfolge identifiziert werden, oder sie werden durch Verwendung des Struktur-Datentyps indiziert.

Im Falle einer nicht erfolgreichen Anfrage kann eine Fehlerantwort zur¨ uckgeliefert werden. Anstelle von params befindet sich in methodResponse ein fault Element, in dessen Wert (value) eine Struktur steckt, in der der Fehlercode (faultCode) und eine Fehlerbeschreibung (faultString) stehen.

XML-RPC wurde in vielen g¨ angigen Programmiersprachen implementiert und bietet sich als einfache Technologie f¨ ur die Kommunikation ¨ uber HTTP zwischen verteilten

Software-Systemen an. Die Einfachheit des Protokolls hat aber sowohl Vor- als auch Nachteile. F¨ ur die synchrone Nachrichten¨ ubermittlung von Remote Procedure Calls, die sehr gut auf das Schema von HTTP-Request und -Response passen, ist XML-RPC gut geeignet. Es ist aber auf HTTP als Transport-Protokoll und RPC-Anwendungsf¨ alle beschr¨ ankt. Ein weiterer wichtiger Kritikpunkt ist eine fehlende Meta-Beschreibung der vom XML-RPC-Web-Service zur Verf¨ ugung gestellten Methoden. So m¨ ussen demjenigen, der einen WS-Client implementieren will, eine Beschreibung in nat¨ urlicher Sprache oder Beispiel-Methodenaufrufe mitgeliefert werden. [HZ03, S.147f]

Die Verbreitung von XML-RPC ist außerdem nicht so groß, wie die des im folgenden Kapitel erl¨ auterten Standards SOAP. So hat Microsoft seine Unterst¨ utzung f¨ ur XML-RPC aus .NET herausgenommen. [HL04, S.39] Viele ¨ offentliche Web-Services, wie z. B. von Google [Goo06] oder Amazon [Ama06], setzen nicht auf XML-RPC, sondern bieten SOAP- oder REST-APIs an.

2. Fachliches Umfeld - Web-Service-Technologien 10

2.4. SOAP

Microsoft unterst¨ utzte zun¨ achst XML-RPC und entwickelte es dann 1999 mit dem XML-RPC Entwickler Dave Winer weiter zu SOAP. Das Protokoll wurde im Jahr 2000 beim W3C in der Version 1.1. zur Standardisierung eingereicht, wo sich weitere Firmen an der Entwicklung beteiligten. Seit 2003 ist die Version 1.2 eine W3C Empfehlung [W3C03]. Urspr¨ unglich stand SOAP f¨ ur ” Simple Object Access Protocol“. SOAP steht seit Version

1.2 f¨ ur sich selbst und ist kein Akronym mehr. Der Name war nicht mehr treffend, da SOAP eine gewisse Einfachheit bei der Weiterentwicklung von XML-RPC verloren hatte, und ein echter Objektzugriff ebenfalls nicht erfolgt. Eine SOAP-Nachricht enth¨ alt keine Referenzen auf Objekte, sondern h¨ ochstens statische Variablen und Methodenaufrufe.

SOAP ist also wie XML-RPC ein auf XML basierendes Protokoll zur Nachrichten¨ ubermittlung. Der Nachrichtenaustausch erfolgt zwischen sogenannten SOAP-Knoten. Bei der Wahl des Transportprotokolls ist SOAP nicht auf HTTP beschr¨ ankt, sondern kann auch u. a. ¨ uber SMTP oder FTP verwendet werden.

SOAP muss - im Gegensatz zu XML-RCP - nicht nur bei Anwendungen im RPC-Stil nach einem synchronen Anfrage-Antwort-Schema zum Einsatz kommen. Es kann auch zur asynchronen Kommunikation f¨ ur einen sogenannten dokumentenzentrierten Nachrichtenaustausch verwendet werden.

Wird SOAP derzeitig zwar haupts¨ achlich f¨ ur den Nachrichtenaustausch zwischen zwei SOAP-Knoten verwendet, so spezifiziert der Standard zumindest auch, dass der Kommunikationsweg ¨ uber mehrere SOAP-Knoten - sogenannte Intermediates - laufen kann. Nach [EF03, S.183] k¨ onnte ein ein konkretes Anwendungsbeispiel wie folgt aussehen: Eine Nachricht l¨ auft zun¨ achst ¨ uber einen vertrauensw¨ urdigen Dritten, der die Nachricht signiert, bevor sie zum endg¨ ultigen SOAP-Knoten gelangt.

Eine SOAP-Nachricht ist grunds¨ atzlich wie folgt aufgebaut: In einem SOAP-Envelope (Umschlag) stecken ein SOAP-Header (Kopf) und ein SOAP-Body (K¨ orper). Der SOAP-Header ist optional und wird daher meist auch weggelassen. Er kann z. B. f¨ ur Transaktions-oder Authentifizierungsinformationen verwendet werden. L¨ auft die Kommunikation der SOAP-Nachricht ¨ uber Intermediates, wird der SOAP-Header f¨ ur entsprechende Metain-formationen ben¨ otigt. Der SOAP-Body enth¨ alt die eigentliche Nachricht, also z. B. eine RPC-Anfrage, eine Antwort oder eine Fehlerantwort.

In Listing 2.4 sieht man eine Beispiel-Anfrage in SOAP. Der Job mit der ID 12 wird uber die Methode getJob angefordert. ¨

Die SOAP-spezifischen und die anwendungsspezifischen Teile werden durch entsprechende Namespaces (hier env und ns1) unterschieden. ¨ Ahnlich wie bei XML-RPC sind Methodenaufruf und die Methodenparameter miteinander verschachtelt. Wie schon erw¨ ahnt muss der anwendungsspezifische Teil im SOAP-Body nicht diesem RPC-Stil folgen, sondern kann auch als beliebig strukturiertes Dokument formuliert sein, welches die konsumierende Anwendung verstehen muss. Auffallend an diesem Beispiel ist, dass keine Angabe zum Datentyp von jobId zu finden ist. Es handelt sich um eine SOAP-Nachricht im literal Kodierungsstil. In diesem Fall w¨ are die Datentyp-Beschreibung in einer XML-Schema-Definition enthalten, welche sich in der WSDL-Beschreibung befindet. W¨ are das SOAP-Encoding (encoded Kodierungsstil) zum Einsatz gekommen, w¨ urde sich die Datentyp-Beschreibung direkt in der SOAP-Nachricht finden. In diesem Beispiel s¨ ahe der Parameter jobID z. B. so aus:

12

Mehr zu den beiden Kodierungsstilen literal und encoded folgt im Kapitel 2.6 zu WSDL.

Listing 2.5 zeigt eine m¨ ogliche erfolgreiche Antwort auf die oben gestellte Anfrage. Dem WS-Client wird eine Struktur zur¨ uckgegeben, die eine entsprechende SOAP-Implementierung einer Programmiersprache - je nachdem, was f¨ ur Datenstrukturen die Sprache anbietet - z. B. in ein Job-Objekt deserialisiert. Dieses Objekt k¨ onnte dann die Attribute jobId, jobName, jobNumber, mainCategoryName und jobCategoryName enthalten. Vorstellbar w¨ are auch eine Deserialisierung in ein assoziatives Job-Array.

Fehler werden in SOAP mit einer SOAP-Fault-Nachricht angezeigt. Diese enth¨ alt die Elemente FaultCode und FaultString, die den Fehler beschreiben k¨ onnen.

2.5. REST

Einige Anbieter von Web-Services bieten neben einem Zugriff mit Hilfe des SOAP-Standards auch sogenannte REST-basierte Programmierschnittstellen an. REST steht f¨ ur ” Representational State Transfer“ und wurde erstmals in der Doktorarbeit von Roy Fielding ¹ definiert [Fie00]. Laut [Cos02] handelt es sich bei REST nicht um ein standar-

disiertes Nachrichtenprotokoll wie XML-RPC oder SOAP, sondern um einen Architekturstil, der Standards wie HTTP, URI, HTML und XML verwendet. In einem RESTbasierten Web-Service stehen sogenannte Ressourcen im Mittelpunkt, die ¨ uber einen eindeutigen URI (Uniform Resource Identifier) identifizierbar sind. Das Format einer Ressource ist meist XML, kann aber z. B. auch eine Bilddatei sein. Ein Beispiel f¨ ur eine Ressource des in dieser Arbeit behandelten Extranets w¨ are ein Job. Im Gegensatz zum RPC-Stil, in dem der Zugriff auf einen Job mit der ID 815 mit einer Methode getJob(815) m¨ oglich sein k¨ onnte, w¨ urde beim REST-Stil der Zugriff ¨ uber den URI der Ressource erfolgen, z. B. http://thederan.com/xtranet/ws/Job/815. S¨ amtliche Zugriffe und Ver¨ anderungen auf die Ressource finden mittels der von HTTP zur Verf¨ ugung gestellten Methoden statt. Ein lesender Zugriff erfolgt mit der Methode GET. Ver¨ anderungen werden mit den Methoden POST, PUT und DELETE vorgenommen. Ein Zugriff mit GET auf den genannten URI w¨ urde eine bestimmte Repr¨ asentation bzw. Verk¨ orperung (Representation) der Ressource z. B. in Form einer HTML-Datei namens job815.html zur¨ uckliefern. Die Verk¨ orperung k¨ onnte auch ein XML-Dokument sein, das die Informationen des Jobs in einer strukturierten Form enth¨ alt. Die Verk¨ orperung versetzt den aufrufenden Client in

¹ Roy Fielding ist einer der Autoren der HTTP-Protokoll-Spezifikation

2. Fachliches Umfeld - Web-Service-Technologien 13

einen bestimmten Zustand (state) und kann Hyperlinks zu weiteren URIs von Ressourcen enthalten. Die oben genannte Ressource Job kann bspw. Links zu den Assets enthalten, die dem Job zugeordnet sind, wie z. B. http://thederan.com/xtranet/ws/Asset/9541. Folgt der Client einem Link, ver¨ andert (transfer ) die Verk¨ orperung der neuen Ressource dessen Zustand.

REST beschreibt im Grunde die Architektur des Webs. Das Browsen durch das Web ¨ uber

Hyperlinks funktioniert nach dem Prinzip des REST-Ansatzes. Da die Repr¨ asentationen der Web-Ressourcen jedoch nicht auf HTML-Dokumente beschr¨ ankt sind, sondern auch strukturierte maschinenlesbare XML-Dokumente sein k¨ onnen, ist auch der Aufbau von Kommunikations-Architekturen f¨ ur verteilte Software-Systeme - also Web-Services - mit REST m¨ oglich. Die Struktur der Parameter der Anfragen und die R¨ uckgabewerte der Antworten m¨ ussen f¨ ur den Nutzer des REST-Web-Service mit Hilfe von bspw. WSDL, XML-Schema oder in Textform in HTML beschrieben werden.

REST wird teilweise als eine gegens¨ atzliche Technik zu Web-Services beschrieben, z. B. in [Wik06b]. Meist wird dann unter dem Begriff Web-Service nur der W3C-Standard SOAP verstanden. Web-Service-Anbieter wie Amazon [Ama06] aber definieren den Web-Service-Begriff allgemein und z¨ ahlen REST genauso dazu wie SOAP. Da REST wie bereits erw¨ ahnt keine standardisierbare Protokollspezifikation ist, sondern ein genereller Architekturstil, gibt es auch keine konkreten REST-Implementierungen oder Program-mierframeworks.

2.6. WSDL

Will ein Programmierer einen SOAP-Client entwickeln, muss er ¨ uber Informationen zur

Schnittstelle des SOAP-Servers verf¨ ugen: die Adresse (URI) unter der die Schnittstelle zu erreichen ist, die Namen der Methoden sowie die Namen und Datentypen bzw. Objekt-Strukturen der zu ¨ ubergebenden Eingabeparameter und der zu erwartenden R¨ uckgabewerte. Die maschinenverarbeitbare Schnittstellenbeschreibung, die einen SOAP-Web-Service beschreibt, heißt Web Service Description Language (WSDL). WSDL wird wie SOAP vom W3C spezifiziert. Zur Zeit der Erstellung dieser Arbeit lag die WSDL-Version 2.0 ² im Status Candidate Recommendation vor [W3C06], also kurz vor der Erhebung in

den endg¨ ultigen Status einer W3C Empfehlung (Recommendation). Praktisch einsetzbar ist WSDL 2.0 allerdings noch kaum, da viele SOAP-Implementierungen bisher noch ausschließlich die WSDL-Version 1.1 unterst¨ utzen, auf die auch im Folgenden eingegangen wird. WSDL 1.1 ist eine W3C Note aus dem Jahr 2001 [W3C01].

In den meisten SOAP-Implementierungen wird es dem Entwickler erm¨ oglicht, mit Hilfe einer WSDL-Beschreibung einen Stellvertreter des Web-Service - ein sogenanntes Proxy- ² Wennin einigen ¨ alteren Publikationen von WSDL 1.2 die Rede ist, ist WSDL 2.0 gemeint. Das W3C ¨ anderte die Versionsnummer w¨ ahrend der Arbeit am Working Draft im November 2003 von 1.2 auf 2.0

2. Fachliches Umfeld - Web-Service-Technologien 14

Objekt - zu schaffen, das den Web-Service auf der Client-Seite repr¨ asentiert. ¨ Uber dieses

Proxy-Objekt k¨ onnen dann alle Methoden des Web-Service aufgerufen werden.

F¨ ur einige Implementierungen gibt es Werkzeuge (z. B. WSDL2Java), die aus einer WSDL-Beschreibung automatisch ein Code-Ger¨ ust eines WS-Clients generieren.

2.6.1. WSDL-Aufbau

Eine WSDL-Beschreibung ist ein XML-Dokument. Listing 2.6 zeigt die Grundstruktur eines WSDL-Dokuments. Das Wurzelelement definitions umschließt die f¨ unf Teile eines WSDL-Dokuments: types, message, portType, binding und service.

Im types-Element werden die zu verwendenden komplexen Datentypen wie Objektstrukturen beschrieben. Dies geschieht mittels XML-Schema. Sollten nur die einfachen XML-Schema Datentypen verwendet werden, kann types weggelassen werden.

Mit message-Elementen werden die ¨ Ubergabeparameter und R¨ uckgabewerte der Me-

thoden definiert. message enth¨ alt ein oder mehrere part Elemente, in denen die Datentypen der Parameter festgelegt werden. Diese sind dann entweder einfache XML-Schema-Typen oder sie beziehen sich auf die unter types definierten komplexen Datentypen.

Die eigentlichen Methoden des Web-Service werden unter portType definiert. F¨ ur jede Methode gibt es ein operation Element. Je nachdem, ob die Methode ¨ Ubergabeparameter erwartet und/oder Daten zur¨ uckliefert, werden input- und output-Elemente angegeben, die sich dann auf Parameter beziehen, die im message-Element definiert wurden.

binding bestimmt die Protokolle, mit denen der portType verwendet wird. Das k¨ onnen SOAP, HTTP-GET oder HTTP-POST sein. Außerdem wird hier der Nachrichtenstil (document oder rpc) und der Kodierungsstil (literal oder encoded ) f¨ ur alle ¨ Ubergabeparameter und R¨ uckgabewerte der Methoden angegeben. Mehr dazu im folgenden Kapitel 2.6.2.

Zuletzt wird unter service in einem port-Element die tats¨ achliche Adresse (URI) definiert, unter der der Web-Service zu erreichen ist.

Optional k¨ onnen die meisten WSDL-Teile mit einem documentation-Element kom- mentiert werden.