Ein Werbeagentur-Extranet als Web-Service-Prototyp

Inhaltsverzeichnis

1. Einleitung
1.1. Aufgabenstellung
1.2. Aufbau der Arbeit

2. Fachliches Umfeld - Web-Service-Technologien
2.1. Web-Services
2.1.1. Definition
2.1.2. Einsatzgebiete
2.1.3. Web-Service-Interoperabilität
2.1.4. Web-Service-Sicherheit
2.2. Web-Service-Vorläufer und -Alternativen
2.3. XML-RPC
2.4. SOAP
2.5. REST
2.6. WSDL
2.6.1. WSDL-Aufbau
2.6.2. Nachrichtenstil und Kodierungsstil
2.7. UDDI
2.8. Serviceorientierte Architektur (SOA)

3. Ist-Beschreibung des Xtranet Staging Site Systems
3.1. Aufbau und grundsätzlicher Nutzen des Systems
3.2. Begrifflichkeiten
3.3. Funktionalitäten des Systems für den Kunden . .

4. Anforderungsdefinition des Xtranet-Web-Service
4.1. Zielbestimmungen
4.1.1. Musskriterien
4.1.2. Wunschkriterien
4.1.3. Abgrenzungskriterien
4.2. Produkteinsatz
4.2.1. Anwendungsbereiche
4.2.2. Zielgruppen
4.2.3. Betriebsbedingungen
4.3. Produktumgebung
4.3.1. Software
4.3.2. Hardware und Orgware
4.4. Produktfunktionen und Produktdaten
4.5. Produktleistungen
4.6. Benutzungsoberfläche
4.7. Testszenarien und Testfälle

5. Entwurf
5.1. Wahl der zu verwendenden Technologien
5.2. Wahl der zu verwendenden Entwicklungswerkzeuge und -umgebungen
5.3. Entwurf des Xtranet-Web-Service
5.3.1. Datenobjekte
5.3.2. Listenobjekte
5.3.3. Fehlerbehandlung
5.3.4. Die Xtranet-Web-Service-Klasse
5.3.5. E-Mail-Benachrichtigungen
5.3.6. Web-Service-Client

6. Realisierung des Xtranet-Web-Service
6.1. WSDL-Beschreibung der SOAP-Nachrichten
6.2. Realisierung des SOAP-Servers
6.2.1. Realisierung der Xtranet-Web-Service-Klasse
6.2.2. Realisierung der Error-Klasse
6.2.3. Realisierung der Daten- und Listenklassen
6.2.4. Realisierung des SOAP-Endpunkts
6.3. Realisierung der SOAP-Clients
6.3.1. Realisierung des PHP5-SOAP-Clients
6.3.2. Realisierung des Java-Axis-SOAP-Clients
6.3.3. Realisierung des SOAP-Clients in Flash 8 Actionscript .

7. Test des Xtranet-Web-Service
7.1. Funktionale Tests
7.2. Interoperabilitätstests
7.3. Leistungstests

8. Schlussbetrachtung
8.1. Zusammenfassung
8.2. Bewertung und Ausblick

A. Datenbankstruktur des Xtranet-Systems

B. Verzeichnisse
Abkürzungen
Glossar
Listingverzeichnis
Abbildungsverzeichnis
Tabellenverzeichnis
Literaturverzeichnis

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 wie- der erwähnte 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öglichen eine Kommunikation von Systemen auf unterschiedlichen Plattformen und in verschiedensten Programmiersprachen untereinander. Interessant ist dies zum einen innerhalb von Firmen, die verschiedene, über die Zeit getrennt voneinander entwickelte Software-Systeme miteinander integrieren wollen. Zum anderen ermöglichen Web-Services die Kommunikation zwischen Software-Systemen verschiedener Geschäftspartner. Die vorliegende Arbeit dokumentiert die Entwicklung eines Web-Service für einen solchen Business-to-Business Anwendungsfall.

1.1. Aufgabenstellung

Das 2004 geschaffene Extranet namens ”XtranetStagingSiteSystem“(”Xtranet“)er- möglicht einer Werbeagentur mit ihren Kunden über die in Auftrag gegebenen Arbeiten zu kommunizieren. Die Agentur kann u. a. Dateien, die sie dem Kunden zur Begutachtung zur Verfügung stellen will, in das System hochladen. Der Kunde hat die Möglichkeit, über eine HTML-Benutzeroberfläche (Browser-Interface) auf die verschiedenen Arbeiten zuzugreifen, sie zu kommentieren und freizuzeichnen.

Im Rahmen dieser Arbeit soll prototypisch ein Web-Service entworfen und implemen- tiert werden, der es dem Kunden ermöglicht, passwortgeschützt über eine Programmier- schnittstelle (API) auf seinen Teil des Extranets zugreifen zu können. Es sollen min- destens die gleichen Funktionalitäten zur Verfügung stehen, wie beim Zugriff über das Browser-Interface, z. B. das Abrufen von Informationen über die Projekte und Dateien des Kunden.

Die zu entwickelnde Web-Service-API ermöglicht es einem Programmierer des Kunden, eine Anwendung in einer fast beliebigen, gängigen Programmiersprache zu schaffen, die auf das ”Xtranet“Systemzugreift.DerKundehättesodieMöglichkeit,Inhalteausdem Agentur-Extranet - z. B. Informationen über Aufträge und Dateien - in eigene Systeme einzubinden.

1.2. Aufbau der Arbeit

Kapitel 2 erklärt den Begriff Web-Service und beschreibt verschiedene Spezfikationen von Web-Service-Technologien und ihre Zusammenhänge, deren Kenntnis Voraussetzung für das Verständnis dieser Arbeit ist.

Kapitel 3 beschreibt den Aufbau, die Begrifflichkeiten und die Funktionalitäten des ”XtranetStagingSiteSystem“.DieseInformationensindebenfallsgrundlegendzum Verständnis 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ändiges Pflichtenheft zu verstehen.

Kapitel 5 erläutert 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ächst Definitionen des Web-Service-Begriffs beschrieben. Danach werden die Vorläufer und Alternativen zu Web-Services kurz erwähnt, bevor auf konkrete Web-Service-Technologien eingegangen wird. Abschließend wird noch der Begriff der serviceorientierten Architektur (SOA) erläutert.

2.1. Web-Services

Wenn man die Bedeutung zunächst nur vom Begriff Web Service abzuleiten versuchen würde, könnte es zu Missverständnissen kommen. Man könnte vermuten, ein Benutzer greift mit Hilfe eines Clients - also z. B. eines Browsers - über ein Netzwerk ( ”Web“) auf die Funktionalitäten ( ”Services“)einerApplikationaufeinementferntenServerzu, welcher eine Antwort zurückliefert, 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 han- delt!

2.1.1. Definition

Paul Prescod formuliert zunächst sehr allgemein:

”AwebserviceisasetoffunctionalityofferedonthepublicInternetora 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ät dar, die ein Computer über 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 ”Ser- vice“) zugreift, die eine andere, entfernte Applikation bereitstellt. Man spricht davon, dass ein WS-Client einen Web-Service ”konsumiert“.

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

”IBMDeveloper-

”(...)aWebserviceisanypieceofsoftwarethatmakesitselfavailableover the Internet and uses a standardized XML messaging system.“ [Cer02]

”Webservicesisatechnologythatallowsapplicationstocommunicatewith 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ür eine Kommunikation zwischen Software-Applikationen, die plattform- und programmierspra- chenunabhängig sind. Die Definition von ”IBMDeveloperWorks“benenntaußerdemdas 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übergreifenden Austausch zwischen Anwendungen ermöglichen (mehr dazu in Kapitel 2.2). Im Unterschied dazu können aber Applikationen, die mit Hilfe von Web-Services kommunizieren, sich auf unterschiedlichen Plattformen befinden und in verschiedenen Programmiersprachen geschrieben sein. Sie können miteinander kom- munizieren, 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.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1.: Web-Service-Beispiel - vereinfachte Darstellung

Fast synonym zum Web-Service-Begriff wird heute das vom ”WorldWideWebConsor- tium“ (W3C) standardisierte Protokoll-Paar SOAP/WSDL genannt, obwohl es z. B. mit XML-RPC und REST noch Alternativen zu SOAP gibt. Auf die genannten Technologien wird später noch im Detail eingegangen.

Das W3C hat noch in seinem Web-Services-Glossar 11/2002 eine ähnliche allgemeine Erklärung des Begriffs Web-Service gegeben [W3C02], wie die oben zitierten Definitio- nen. 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:

”AWebserviceisasoftwaresystemdesignedtosupportinteroperablemachine- 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 SOAP- messages, typically conveyed using HTTP with an XML serialization in con- junction with other Web-related standards.“ [W3C04b]

Aus Sicht des W3C ist ein Web-Service ein System für eine Maschine-Maschine-Interaktion, dessen Schnittstellen mit WSDL beschrieben werden und mit dem andere Systeme mit- tels über HTTP beförderte SOAP-Nachrichten interagieren.

2.1.2. Einsatzgebiete

Paul Prescod beschreibt zwei Haupteinsatzfelder für Web-Services [Pre06b, Kapitel 4]: Als erstes können sie innerhalb einer Firma eingesetzt werden, um die Integration verschiedener Software-Systeme zu ermöglichen oder zu vereinfachen (Enterprise Application Integration (EAI). Mittels Web-Services können 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äftspartnern oder Kunden eine öffentliche Schnittstelle anbieten, die eine programmatische Interaktion mit den Software-Systemen der Firma erlaubt, z. B. um Preisauskünfte zu geben oder ein direktes Bestellen von Produkten zu ermöglichen.

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ügung.

2.1.3. Web-Service-Interoperabilität

Der Web-Service-Anbieter kennt nicht unbedingt die Software-Architekturen des Geschäftspartners, der den Web-Service konsumieren will. Er muss aber einen möglichst einfachen Zugriff auf das System sowie eine Interoperabilität mit möglichst vielen verschiedenen und gängigen Programmiersprachen und Plattformen ermöglichen.

Für fast alle gängigen 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 da- zu führt, dass einige Web-Service-Implementierungen Eigenheiten mit sich bringen und nicht immer voll kompatibel mit anderen Implementierungen sind. Um eine möglichst ho- he Interoperabilität zu fördern, arbeitet die ”WebServicesInteroperabilityOrganization“ (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ügung, mit denen man einen Web-Service auf seine Einhaltung eines WS-I-Profils überprüfen kann.

2.1.4. Web-Service-Sicherheit

Da das System quasi öffentlich im Internet zu erreichen ist, müssen Sicherheitsmechanismen wie Verschlüsselung und Passwortschutz verwendet werden.

Web-Service-Protokolle wie der SOAP-Standard definieren von sich aus keine Sicher- heitsmechanismen. Die damit übermittelten Daten werden also unverschlüsselt und un- signiert transportiert. Zur Erhöhung der Sicherheit könnte der Web-Server, der den Web- Service anbietet, den gesamten Transportkanal mit Hilfe von HTTPS verschlüsseln.

Alternativ können Web-Service-Erweiterungen verwendet werden, die Sicherheitsaspekte behandeln. Die Standardisierungsgruppe ”OrganizationfortheAdvancementofStructu- red Information Standards“ (OASIS) verabschiedete dazu einen Standard ”WS-Security“ [OAS06], in dem verschiedene Sicherheitstechniken zusammengefasst werden. Dazu ge- hören u. a. Verschlüsselungen mittels XML-Encryption und Signaturen mittels XML- Signature.

2.2. Web-Service-Vorläufer und -Alternativen

Einige Programmiersprachen bringen Techniken mit, die eine RPC-Kommunikation mit entfernten Programmen, die in derselben Sprache geschrieben wurden, ermöglichen. Die- se Art der Maschine-Maschine-Kommunikation wird bei objektorientierten Sprachen Re- moting genannt. Bekannte Beispiele sind Remote Method Invocation (RMI) in Java oder .NET Remoting von Microsoft. Wie gerade erwähnt, können sich also z. B. zwei entfernte Java-Programme oder zwei entfernte .NET-Programme miteinander unterhalten. Vorteil dieser Remoting-Technologien ist eine höhere Performance des binären 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übergreifende Kommunikati- on in heterogenen Umgebungen ist mit diesen Techniken nicht möglich. Diesen Nachteil versuchte bereits CORBA (Common Request Broker Architecture) zu überwinden. Es steht als Kommunikationsvermittler zwischen Applikationen, welche in verschiedenen Sprachen entwickelt sein können. CORBA gilt allerdings als kompliziert [HL04, S.25], ”zulangsamundoftmalsnichtkompatibelgenug,wennesumverschiedeneImplemen- 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

”UserLandSoftwareInc.“unterLeitungvonDaveWinerentwickelteXML-

RPC 1998. Die offizielle XML-RPC-Website von Dave Winer beschreibt das Protokoll wie folgt:

”[XML-RPCis]aspecandasetofimplementationsthatallowsoftware 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önnen mit XML-RPC Methoden über HTTP in Form XML-codierter Nachrichten aufrufen.

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

Für die Parameter der Anfrage und die Rückgabewerte der Antwort stehen in XML-RPC eine Reihe von Datentypen zur Verfügung, die in einfache und komplexe Datentypen unterschieden werden können. Tabelle 2.1 listet alle einfachen Datentypen auf.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2.1.: Einfache Datentypen in XML-RPC

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

Abbildung in dieser Leseprobe nicht enthalten

Listing 2.1: Ein Beispiel Array in XML-RPC

Wie man in Listing 2.1 sieht, können die Werte des Arrays verschiedene Datentypen annehmen (in diesem Beispiel Integer, String und Boolean). Ein Indexwert wird nicht mitgeführt. 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)

Abbildung in dieser Leseprobe nicht enthalten

Listing 2.2: Eine Beispiel Struktur in XML-RPC

Eine Struktur besteht aus member-Elementen, welche je ein name- und value-Elemente- Paar enthalten. Diese Datentypen können natürlich 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ür eine Methode namens getJob, die Informationen eines Jobs mit der ID 12 zurückliefern soll, kann wie in Listing 2.3 dargestellt aussehen.

Abbildung in dieser Leseprobe nicht enthalten

Listing 2.3: Ein Beispiel Methodenaufruf in XML-RPC

Das Wurzelelement der Anfrage ist methodCall. Nach dem Namen der Methode methodName folgen die zu übergebenden 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ögliche Antwort erfolgt im HTTP-Response. Das Wurzelelement der Antwort ist methodResponse, welches unter params den Rückgabewert enthält.

Man beachte, dass die Übergabeparameter bei der Anfrage und die Rückgabewerte der Antwort keine identifizierenden Namen haben. Falls mehrere Parameter verwendet werden, müssen sie über ihre Reihenfolge identifiziert werden, oder sie werden durch Verwendung des Struktur-Datentyps indiziert.

Im Falle einer nicht erfolgreichen Anfrage kann eine Fehlerantwort zurückgeliefert 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ängigen Programmiersprachen implementiert und bietet sich als einfache Technologie für die Kommunikation über HTTP zwischen verteilten Software-Systemen an. Die Einfachheit des Protokolls hat aber sowohl Vor- als auch Nachteile. Für die synchrone Nachrichtenübermittlung 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älle be- schränkt. Ein weiterer wichtiger Kritikpunkt ist eine fehlende Meta-Beschreibung der vom XML-RPC-Web-Service zur Verfügung gestellten Methoden. So müssen demjeni- gen, der einen WS-Client implementieren will, eine Beschreibung in natürlicher 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äuterten Standards SOAP. So hat Microsoft seine Unterstützung für XMLRPC aus .NET herausgenommen. [HL04, S.39] Viele öffentliche Web-Services, wie z. B. von Google [Goo06] oder Amazon [Ama06], setzen nicht auf XML-RPC, sondern bieten SOAP- oder REST-APIs an.

2.4. SOAP

Microsoft unterstützte zunächst 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ünglich stand SOAP für ”SimpleObjectAccessProtocol“.SOAPstehtseitVersion 1.2 für 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ält keine Referenzen auf Objekte, sondern höchstens statische Variablen und Methodenaufrufe.

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

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

Wird SOAP derzeitig zwar hauptsächlich für den Nachrichtenaustausch zwischen zwei SOAP-Knoten verwendet, so spezifiziert der Standard zumindest auch, dass der Kommunikationsweg über mehrere SOAP-Knoten - sogenannte Intermediates - laufen kann. Nach [EF03, S.183] könnte ein ein konkretes Anwendungsbeispiel wie folgt aussehen: Eine Nachricht läuft zunächst über einen vertrauenswürdigen Dritten, der die Nachricht signiert, bevor sie zum endgültigen SOAP-Knoten gelangt.

Eine SOAP-Nachricht ist grundsätzlich wie folgt aufgebaut: In einem SOAP-Envelope (Umschlag) stecken ein SOAP-Header (Kopf) und ein SOAP-Body (Körper). Der SOAPHeader ist optional und wird daher meist auch weggelassen. Er kann z. B. für Transaktionsoder Authentifizierungsinformationen verwendet werden. Läuft die Kommunikation der SOAP-Nachricht über Intermediates, wird der SOAP-Header für entsprechende Metainformationen benötigt. Der SOAP-Body enthält 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 über die Methode getJob angefordert.

Abbildung in dieser Leseprobe nicht enthalten

Listing 2.4: Ein Beispiel Methodenaufruf in SOAP 1.2

Die SOAP-spezifischen und die anwendungsspezifischen Teile werden durch entsprechen- de Namespaces (hier env und ns1) unterschieden. Ähnlich wie bei XML-RPC sind Me- thodenaufruf und die Methodenparameter miteinander verschachtelt. Wie schon erwähnt muss der anwendungsspezifische Teil im SOAP-Body nicht diesem RPC-Stil folgen, son- dern kann auch als beliebig strukturiertes Dokument formuliert sein, welches die konsu- mierende Anwendung verstehen muss. Auffallend an diesem Beispiel ist, dass keine An- gabe zum Datentyp von jobId zu finden ist. Es handelt sich um eine SOAP-Nachricht im literal Kodierungsstil. In diesem Fall wäre die Datentyp-Beschreibung in einer XML- Schema-Definition enthalten, welche sich in der WSDL-Beschreibung befindet. Wäre das SOAP-Encoding (encoded Kodierungsstil) zum Einsatz gekommen, würde sich die Datentyp-Beschreibung direkt in der SOAP-Nachricht finden. In diesem Beispiel sähe der Parameter jobID z. B. so aus:

Abbildung in dieser Leseprobe nicht enthalten

Mehr zu den beiden Kodierungsstilen literal und encoded folgt im Kapitel 2.6 zu WSDL. Listing 2.5 zeigt eine mögliche erfolgreiche Antwort auf die oben gestellte Anfrage. Dem WS-Client wird eine Struktur zurückgegeben, die eine entsprechende SOAP-Implement- ierung einer Programmiersprache - je nachdem, was für Datenstrukturen die Sprache anbietet - z. B. in ein Job-Objekt deserialisiert. Dieses Objekt könnte dann die Attri- bute jobId, jobName, jobNumber, mainCategoryName und jobCategoryName enthalten. Vorstellbar wäre auch eine Deserialisierung in ein assoziatives Job-Array.

Fehler werden in SOAP mit einer SOAP-Fault -Nachricht angezeigt. Diese enthält die Elemente FaultCode und FaultString, die den Fehler beschreiben können.

Abbildung in dieser Leseprobe nicht enthalten

Listing 2.5: Ein Beispiel Antwort in SOAP 1.2

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ür ”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 Architek- turstil, der Standards wie HTTP, URI, HTML und XML verwendet. In einem REST- basierten Web-Service stehen sogenannte Ressourcen im Mittelpunkt, die über einen ein- deutigen URI (Uniform Resource Identifier) identifizierbar sind. Das Format einer Res- source ist meist XML, kann aber z. B. auch eine Bilddatei sein. Ein Beispiel für eine Res- source des in dieser Arbeit behandelten Extranets wäre ein Job. Im Gegensatz zum RPC- Stil, in dem der Zugriff auf einen Job mit der ID 815 mit einer Methode getJob(815) möglich sein könnte, würde beim REST-Stil der Zugriff über den URI der Ressource erfol- gen, z. B. http://thederan.com/xtranet/ws/Job/815. Sämtliche Zugriffe und Veränderun- gen auf die Ressource finden mittels der von HTTP zur Verfügung gestellten Methoden statt. Ein lesender Zugriff erfolgt mit der Methode GET. Veränderungen werden mit den Methoden POST, PUT und DELETE vorgenommen. Ein Zugriff mit GET auf den ge- nannten URI würde eine bestimmte Repräsentation bzw. Verkörperung (Representation) der Ressource z. B. in Form einer HTML-Datei namens job815.html zurückliefern. Die Verkörperung könnte auch ein XML-Dokument sein, das die Informationen des Jobs in einer strukturierten Form enthält. Die Verkörperung versetzt den aufrufenden Client in einen bestimmten Zustand (state) und kann Hyperlinks zu weiteren URIs von Ressour- cen enthalten. Die oben genannte Ressource Job kann bspw. Links zu den Assets enthal- ten, die dem Job zugeordnet sind, wie z. B. http://thederan.com/xtranet/ws/Asset/9541. Folgt der Client einem Link, verändert (transfer ) die Verkörperung der neuen Ressource dessen Zustand.

REST beschreibt im Grunde die Architektur des Webs. Das Browsen durch das Web über Hyperlinks funktioniert nach dem Prinzip des REST-Ansatzes. Da die Repräsentationen der Web-Ressourcen jedoch nicht auf HTML-Dokumente beschränkt sind, sondern auch strukturierte maschinenlesbare XML-Dokumente sein können, ist auch der Aufbau von Kommunikations-Architekturen für verteilte Software-Systeme - also Web-Services - mit REST möglich. Die Struktur der Parameter der Anfragen und die Rückgabewerte der Antworten müssen für 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ätzliche 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ählen REST genauso dazu wie SOAP. Da REST wie be- reits erwähnt 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 über Informationen zur Schnittstelle des SOAP-Servers verfügen: die Adresse (URI) unter der die Schnittstelle zu erreichen ist, die Namen der Methoden sowie die Namen und Datentypen bzw. Objekt- Strukturen der zu übergebenden Eingabeparameter und der zu erwartenden Rückga- bewerte. 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ültigen 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ützen, 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öglicht, mit Hilfe einer WSDL-Beschreibung einen Stellvertreter des Web-Service - ein sogenanntes Proxy- Objekt - zu schaffen, das den Web-Service auf der Client-Seite repräsentiert.Über dieses Proxy-Objekt können dann alle Methoden des Web-Service aufgerufen werden.

Für einige Implementierungen gibt es Werkzeuge (z. B. WSDL2Java), die aus einer WSDL-Beschreibung automatisch ein Code-Gerüst 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ünf 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 Übergabeparameter und Rückgabewerte der Me- thoden definiert. message enthält ein oder mehrere part Elemente, in denen die Daten- typen 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ür jede Methode gibt es ein operation Element. Je nachdem, ob die Methode Übergabepa- rameter erwartet und/oder Daten zurückliefert, 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önnen SOAP, HTTP-GET oder HTTP-POST sein. Außerdem wird hier der Nach- richtenstil (document oder rpc) und der Kodierungsstil (literal oder encoded ) für alle ÜbergabeparameterundRückgabewerte der Methoden angegeben. Mehr dazu im fol- genden Kapitel 2.6.2.

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

Optional können die meisten WSDL-Teile mit einem documentation-Element kommentiert werden.

Abbildung in dieser Leseprobe nicht enthalten

Listing 2.6: Grundstruktur einer WSDL-Beschreibung

2.6.2. Nachrichtenstil und Kodierungsstil

Wie die WSDL-Operationen (also die Methoden der Anwendung) in SOAP übersetzt werden, wird, wie zuvor schon erwähnt, im Binding Teil der WSDL-Beschreibung festgelegt. Es stehen dabei die beiden Nachrichtenstile rpc und document zur Verfügung. Bei Verwendung des rpc-Stils, wird eine im WSDL-Dokument angegebene Operation in der SOAP-Nachricht automatisch zu einem Element, das die Eingabeparameter der Methode umschließt. Listing 2.7 zeigt dies beispielhaft.

Abbildung in dieser Leseprobe nicht enthalten

Listing 2.7: SOAP-Nachricht im rpc-Stil

Der document -Stil würde veranlassen, dass die Operation nicht zu einem Element in der SOAP-Anfrage wird, und nur die Methoden-Parameter direkt im SOAP-Body stehen, wie in Listing 2.8 zu sehen ist.

Abbildung in dieser Leseprobe nicht enthalten

Listing 2.8: SOAP-Nachricht im literal -Stil

Die Bezeichnungen legen nahe, dass man den rpc-Nachrichtenstil bei synchronen RPC- Anwendungen einsetzt, und der document -Stil bei einem Programmieransatz für asyn- chronen dokumentenzentrierten Nachrichtenaustausch verwendet werden soll. Russell Butek erklärt in [But05], dass diese Nachrichtenstil-Bezeichnungen unglücklich gewählt sind, weil darüber lediglich festgelegt wird, wie die Operationen des WSDL-Bindings in der SOAP-Nachricht erscheinen sollen. Den Entwicklern sollte darüber aber nicht dik- tiert werden, welches Programmiermodell sie verwenden sollen. Es steht ihnen sehr wohl frei, auch eine RPC-Anwendung im document -Nachrichtenstil zu realisieren. Dazu weiter unten mehr.

Für die Serialisierung von Datentypen einer Programmiersprache zu einer XML-Struktur bietet der SOAP-Standard ein eigenes SOAP-Encoding an. Man spricht vom encoded - Kodierungsstil der Nachricht. Die Verwendung dieses SOAP-Encodings ist optional. Beim sogenannten literal -Kodierungsstil kann die XML-Serialisierung nach eigenen Re- geln erfolgen. In der Regel wird dann XML-Schema [W3C04a] zur Beschreibung der Datentypen verwendet. Das SOAP-Encoding (encoded ) wurde zur XML-Serialisierung entwickelt, als der XML-Schema Standard noch nicht verabschiedet war. Heute wird des- halb die Benutzung des SOAP-Encoding teilweise in Frage gestellt (z. B. in [EF03, S.189ff SOAP Encodings]), da mit XML-Schema ein ausgereifter Standard für die Definition der Datentypen besteht.

Es ergeben sich nun daraus vier verschiedene Kombinationsmöglichkeiten von Nachrich- tenstil und Kodierungsstil: rpc/encoded, rpc/literal, document/encoded und document/- literal. Es wird darüber diskutiert, welche Stile am besten verwendet werden sollten. Von Bedeutung sind die sich gegenüberstehenden Kombinationen rpc/encoded und document/literal. Der rpc/encoded Stil entspricht nicht dem WS-I Basic Profile 1.1, document/literal nur unter bestimmten Umständen. Eine volle Interoperabilität ist damit also nicht gewährleistet. Der größte Nachteil der Verwendung des reinen document/- literal -Stils für eine RPC-Anwendung besteht offensichtlich darin, dass der Name der Methode in der SOAP-Nachricht fehlen würde.

Russell Butek beschreibt alle vier Stil-Kombinationsmöglichkeiten und stellt eine leicht veränderte - ursprünglich von Microsoft propagierte - fünfte Variante, den sogenann- ten document/literal wrapped Stil, als universalste Lösung heraus, die in den meisten Anwendungsfällen verwendet werden kann [But05]. In diesem Fall kann die Nachricht immer noch für eine RPC-Anwendung dienen. Im SOAP-Body einer Anfrage steht der Name der aufgerufenen Methode als alles umschließendes Element (daher wrapped ) und hätte so wieder die Form einer RPC-Nachricht wie in Listing 2.7. Dieses, die Metho- de beschreibende Element, wird im WSDL-Dokument im types-Teil mit XML-Schema definiert, und nicht wie beim rpc-Stil aus den operation Elementen abgeleitet. Der Vorteil von document/literal wrapped ist, dass nun der gesamte Inhalt des SOAP-Body mittels XML-Schema definiert ist und damit validiert werden kann. Beim rpc/literal Stil ist dies nicht möglich, da nicht die gesamte Nachricht des SOAP-Bodies mit XML- Schema beschrieben ist, sondern nur die Parameter der Methoden. Dadurch, dass sich bei document/literal wrapped das XML-Schema mit der gesamten Datentyp-Beschreibung im WSDL-Dokument befindet, kann sich zudem die Größe der zu übertragenden SOAP- Nachrichten verringern, im Vergleich zu rpc/encoded, wo sich die Datentyp-Beschreibung mit in den Elementen der SOAP-Nachricht befinden. Ein Web-Service nach document/- literal wrapped Stil hält zudem die Spezifikationen des WS-I Basic Profiles 1.1 ein.

2.7. UDDI

Universal Description, Discovery and Integration (UDDI) ist ein Standard der OASIS [OAS04], der einen Verzeichnisdienst für Web-Services beschreibt. Dienstanbieter, die ihren Web-Service bekannt machen wollen, können hierfür ein UDDI-Verzeichnis nutzen. Potentielle Nutzer können entsprechende Web-Services in diesem Verzeichnis suchen.

Es gibt öffentliche UDDI-Verzeichnisse wie das von SAP (http://uddi.sap.com/). UDDI kann im B2B und EAI Bereich natürlich auch nicht öffentlich eingesetzt werden. Der Zugriff auf ein Verzeichnis zur Suche und Veröffentlichung von Web-Services kann sowohl manuell über ein Browser-Interface geschehen als auch programmatisch.

Ein UDDI-Eintrag kann in drei Kategorien eingeteilt werden. In den White Pages stehen

- wie in einem Telefonbuch - grundsätzliche Angaben zur Firma, die den Web-Service anbietet, wie Name und Kontaktdaten. Die Yellow Pages kategorisieren die Einträge wie die gelben Seiten nach Branchen. Die Green Pages schließlich enthalten die technischen Angaben zum angebotenen Web-Service wie dessen URI und WSDL-Beschreibung.

2.8. Serviceorientierte Architektur (SOA)

Im Zusammenhang mit Web-Services findet man immer wieder die Erwähnung des Para- digmas der serviceorientierten Architektur (SOA). Im Gegensatz zum objektorientierten Modell, bei dem die Objekte über ihre Schnittstellen eng miteinander verbunden sind (tight-coupling), werden bei der SOA Ressourcen (Services) an verschiedenen Stellen in einem Netzwerk über möglichst neutrale Schnittstellen lose verbunden (loose-coupling). Die einzelnen Services selbst können natürlich objektorientiert entwickelt sein, das ge- samte Design der Kommunikation zwischen den Services ist jedoch serviceorientiert (nach [IBM06a]). Bei der serviceorientierten Architektur geht es darum, Fähigkeiten, die ver- schiedene Inhaber in einem Netzwerk verteilt bereitstellen, zu organisieren und zu nut- zen. Interaktionen sollen dabei nicht mehr nur in Punkt-zu-Punkt Verbindungen funk- tionieren, sondern wie über einen Marktplatz von Services laufen. Ein Service ermöglicht dabei den Zugriff auf eine Fähigkeit und wird von einem Service-Provider zur Verfügung gestellt. Der Service-Konsument will ein bestimmtes Bedürfnis befriedigen. Der Service- Provider hat die Fähigkeit mit seinem Service diese Bedürfnisse zu befriedigen (nach [ML06]). Als Beispiel für eine konkrete Implementierung einer SOA wird zumeist das Dreigespann der Techniken SOAP, WSDL sowie UDDI genannt.

Abbildung 2.2.: Serviceorientierte Architektur

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.2 verdeutlicht das Prinzip der SOA. Der Service-Provider macht seinen Service in einem UDDI-Verzeichnis mit Hilfe von WSDL bekannt. WSDL beschreibt den Service. Der Service Konsument kann den gewünschten Service im Verzeichnis suchen und u. a. über dessen Beschreibung seinen URI also die Adresse des Service beim Provider erfahren. Der Konsument stellt dann mittels SOAP eine Anfrage an den Provider und erhält die Antwort wieder über SOAP.

3. Ist-Beschreibung des Xtranet Staging Site Systems

Im Folgenden wird das Extranet

”XtranetStagingSiteSystem“beschrieben.DieseWeb- Anwendung wurde 2004/2005 von mir in Zusammenarbeit mit der Agentur ”The7th Art“ in New York entwickelt. Es wird zunächst der grundsätzliche Aufbau und Nutzen des Systems erklärt, bevor Begrifflichkeiten erläutert werden, die in der Kommunikation zwischen Agentur und Kunde Anwendung finden. Danach werden die Funktionalitäten gezeigt, die dem Kunden von der Werbeagentur im Extranet zur Verfügung gestellt werden.

Der Begriff Extranet ist nicht standardisiert und wird teilweise unterschiedlich interpretiert. In dieser Arbeit wird ein Extranet wie folgt verstanden: Es ist ein nicht öffentliches System, in dem eine Organisation (z. B. eine Firma) einer ausgewählten Benutzergruppe (z. B. ihren Kunden) Inhalte über das Web anbietet. Die Benutzer müssen sich beim Zugang zum Extranet authentifizieren.

3.1. Aufbau und grundsätzlicher Nutzen des Systems

Das ”Xtranet“dientzurKommunikationderWerbeagenturmitihrenKundenüberdie Werke, an denen die Agentur für sie arbeitet. Das ”Xtranet“isteinContentManagement System (CMS), welches klassischerweise aus den beiden Teilen Content Management Ap- plication (CMA) und Content Delivery Application (CDA) besteht. Die graphischen Be- nutzeroberflächen beider Teile sind Webseiten. Die Mitarbeiter der Agentur können über den CMA-Teil Inhalte in das Extranet einstellen. Sie laden Dateien wie Bilder, Videos, Audiostücke oder Texte für den Kunden in das System hoch und können den Kunden dann via E-Mail aus dem System heraus darüber informieren. Es handelt sich aber nicht um ein Projektmanagement-Werkzeug, welches die Kundenaufträge und Kontaktdaten verwaltet und organisiert, sondern dient nur zur Kommunikation über die geleisteten Arbeiten.

Der Kunde kann dann über den CDA-Teil des Extranets die für ihn erledigten Arbeiten betrachten bzw. herunterladen sowie kommentieren.

[...]

---

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

² Wenn in einigen älteren Publikationen von WSDL 1.2 die Rede ist, ist WSDL 2.0 gemeint. Das W3C änderte die Versionsnummer während der Arbeit am Working Draft im November 2003 von 1.2 auf 2.0