PDF 174K

Komponentenorientierte
Softwareentwicklung und Hypermedia
Seminar
bei Herr Prof. Dr. Frank Thiesing
Web Service
Achim Grimm
Fabian Unterschütz
- Seite 1 von 18 -
Inhaltsverzeichnis
Definition und Übersicht über Web Services.............................................. Seite 4
Installation & Beispielanwendung............................................................. Seite 6
SOAP .................................................................................................... Seite 10
Web Service Description Language (WSDL).............................................. Seite 11
Universial Description, Discovery und Integration (UDDI).......................... Seite 12
Enterprise Java Beans (EJB) und Web Service........................................... Seite 13
Sicherheit von Web Services.................................................................... Seite 14
Ausblick.................................................................................................. Seite 17
Quellenangabe........................................................................................ Seite 18
- Seite 2 von 18 -
Abbildungsverzeichnis
Das Web Service Rollenmodell................................................................. Seite 5
JWDP Ordern-Struktur (%jwsp_home%).................................................. Seite 6
Axis-Webapps Ordner-Struktur................................................................. Seite 7
Happyaxis.jsp - Satusanzeige über die Installation des Axis Web Services... Seite 8
Das Web Service Rollenmodell................................................................. Seite 10
- Seite 3 von 18 -
World Wide Web Consortium
W3C Das “World Wide Web” wurde vor knapp 15 Jahren vom W3C – Vorsitzenden
Tim Bernes – Lee erfunden. In dieser Zeit wurden viele neue Technologien
entwickelt und gewannen an Bedeutung, wie beispielsweise das Internetprotokoll
HTTP oder die Skriptsprachen HTML und XML. Das World Wide Web Consortium teilt
diese Technologien in Working Groups auf, die um einen einheitlichen Standard
bemüht sind und versuchen einen solchen zu entwickeln und zu wahren. Web
Services sind ebenfalls bereits in solche Working Groups aufgeteilt und die W3C Web
Service Architecture Working Group hat eine offizielle Definition für Web Services
herausgegeben, die folgendes ausdrückt:
„Ein Web Service ist eine durch einen URI (Uniform Ressource Identifier) eindeutig
identifizierte Softwareanwendung, deren Schnittstellen als XML – Artefakte definiert,
beschrieben und gefunden werden können. Ein Web Service unterstützt die direkte
Interaktion mit anderen Softwareagenten durch XML – basierte Nachrichten, die über
Internetprotokolle ausgetauscht werden.“ (http://www.w3c.org)
Des Weiteren kann man Web Services wie folgt beschreiben:
·
Web – Services sind selbst beschreibende, modulare Softwarekomponenten im
Internet, die sich gegenseitig aufrufen können und so im Sinne einer Programmzu-Programm Kommunikation zu unterschiedlichen Gesamtlösung
zusammengefügt werden.
·
Die Softwarekomponenten kommunizieren über Internetprotokolle miteinander
und verwenden allgemeine, plattform- und betriebssystemunabhängige Standards
(SOAP, WSDL, UDDI).
·
Ein Web – Service ist eine unabhängige in sich geschlossene Anwendung. Web –
Services sind ortsunabhängig und haben keine graphische Benutzeroberfläche.
·
Der Zugriff wird über Berechtigungen geregelt.
·
Ein Web – Service wird begleitet von Metadaten, die während ihrer Laufzeit von
weiteren Web – Services ausgewertet werden können.
·
Web – Services sind nicht monolithisch sondern modular.
- Seite 4 von 18 -
Einführung in den Gedanken des Web Services
Ein „normaler“ Ablauf bei dem ein Web Service ist, eine Person sich einen Passenden
Web Service bei einer Regierungsstellen (UDDI) sucht. Dies geschieht dann meist
über dessen Web Interface. Dann wird dazu ein Client geschrieben, mit dessen Hilfe
dann der Web Service angesprochen wird.
Es kann jedoch auch vorkommen, dass ein Client-Programm bereits existiert und ein
dazu passender Web Service gesucht wird. Dies kann dann auch automatisch über
die UDDI passieren.
Somit bieten sich Web Services sehr gut für die Kommunikation verschiedenster
Programm an, sodass sie sich zu einem großen Modularem System entwickeln, das
verschiedenste Dienste erbringt. Es ist auch möglich, dass ein Web Service
gleichzeitig ein Client eines anderen Web Services ist.
Den Zusammenhang der drei beteiligten Stellen verdeutlicht die folgende Graphik:
Abbildung 1 Das Web Service Rollenmodell
- Seite 5 von 18 -
Installation
Die Installation eines Web Services besteht aus mehreren Schritten bei denen häufig
Fehler auftreten können. In diesem Dokument wird nur ein von vielen möglichen
Vorgehensweise beschrieben.
Der Prozess der Installation ist in X Schritte unterteilt und wird wie folgt
durchgeführt:
1. Downloaden der benötigten Komponenten:
●
Java Web Service Developer Pack (JWSDP) von http://www.java.sun.com
In dem JWSDP ist unter anderem der Tomcat Webserver enthalten in dem der
Web Service integriert werden soll.
●
Apache Axis von http://ws.apache.org/axis
Dies ist der Eigentlich Web Service und einige nützliche Tools auf die wir später
noch einmal eingehen werden wenn wir einen Beispiel Client erstellen.
2. Nach der Installation des JWSDP findet sich auf der Festplatte folgende OrdnerStruktur wieder:
Abbildung 2 JWDP Ordern-Struktur (%jwsp_home%)
- Seite 6 von 18 -
Abbildung 3 Axis-Webapps Ordner-Struktur
3. Als nächster Schritt wird das Axis-Archiv entpackt und alle Unterordner des
Ordners %axis_home%/webapps in den Ordner %jwsp_home%/webapps kopiert.
Dadurch ergibt sich im Ordner webapps folgende Ordner-Struktur:
4. Nun müssen die Jar-Files die im Axis Archiv enthalten waren in das Verzeichnis %
jwsp_home%\common\lib kopiert werden. Und die Datei %jwsp_home%
\webapps\axis\happyaxis.jsp in das Verzeichnis %jwsp_home%\webapps\ROOT
kopiert werden.
5. Jetzt kann der Tomcat-Webserver gestartet werden. Dies geschieht am
komfortabelsten über einen im Start-Menü angelegten Eintrag der Setup-Routine.
Zum Testen ob bei der Installation Fehler aufgetreten sind, ruft man jetzt am
besten die Diagnose-Seite im Internet Explorer unter der Adresse:
http://localhost:8080/happyaxis.jsp auf. An dieser Stelle sei gesagt, dass diverse
Probleme mit anderen Browsern, wie z.B. Opera, auftreten können und daher nun
immer vom Internet Explorer als Browser gesprochen werden wird.
Wird die Seite fehlerfrei angezeigt wird, kann man mit der Installation fortfahren.
Die Seite sollte wie folgt aussehen:
- Seite 7 von 18 -
Abbildung 4 Happyaxis.jsp - Satusanzeige über die Installation des Axis Web Services
6. Der nächste Schritt ist es ein Beispiel Web Service zu schreiben. Hierbei wird sich
auf das Beispiel „Hi.jws“ des Seminar-Vortrages berufen. Der Quellcode sieht wie
folgt aus:
public class Hi{
public String hello(){
System.out.println ("Hello Welt! Ich bin ein
Webservice");
return "Hello Welt! Ich bin ein Webservice";
}
}
Es ist sinnvoll den Quellcode für den Web Service in einer Java IDE zu schreiben
und dann die Datei umzubenennen.
- Seite 8 von 18 -
7. Unter der URL http://localhost:8080/axis/Hi.jws?WSDL kann man sich das
dazugehörige WSDL Dokument anzeigen lassen. Axis nutzt hierzu intern das Tool
Java2WSDL. Wenn man diese Datei speichert, kann man sie nutzen um mit dem
Tool WSDL2Java einen entsprechenden Client zu schreiben. Der entsprechende
Kommandozeilenaufruf sieht wie folgt aus:
java org.apache.axis.wsdl.WSDL2Java -d Request Hi.WSDL
8. Das Kommando erzeugt unter anderem eine Interface-Datei und eine Stub-Klasse
die sich um die eigentliche Kommunikation mit dem Web Service kümmert. Unser
Beispielclient sieht wie folgt aus:
import localhost.axis.Hi_jws.*;
import java.net.*;
public class AxisClient{
public static void main(String[] args) throws
java.lang.Exception{
HiServiceLocator loc = new HiServiceLocator();
System.out.println ("Stelle eine Verbindung zu >>“+
her...");
+“http://localhost:8080/axis/Hi.jws <<
Hi ser = loc.getHi(new URL
("http://localhost:8080/axis/Hi.jws"));
System.out.println ("Verbindung aufgebaut!\n\n");
System.out.println (ser.hello());
}
}
9. Die Ausgabe des Clients ist der Rückgabe wert des Web Services.
- Seite 9 von 18 -
SOAP
Simple Object Access Protocol (SOAP) ist ein leichtwertiges Protokoll, dessen Zweck
der Austausch strukturierter Informationen in einer dezentralisierten verteilten
Umgebung ist. Dazu wird auf der Basis von XML ein Rahmenwerk für den Austausch
von Nachrichten beschrieben, wobei diese Nachrichten über eine Auswahl
verschiedener Transportprotokolle übertragen werden können. Das
Nachrichtenformat ist komplett anwendungsunabhängig, aber natürlich ist es
möglich, anwendungsspezifische Daten in einer SOAP-Nachricht zu transportieren.
Jede SOAP-Nachricht besteht aus einem „Envelope“ der die gesamte Nachricht
umfasst. Dieser Umschlag enthält zwei Komponenten, nämlich einen SOAP Header
und einen SOAP Body. Siehe Abbildung:
Abbildung 5 Aufbau einer SOAP Nachricht
Die Informationen die der Web Service benötigt, werden im Body übertrage. Hier
findet sich dann die jeweiligen Methodenaufrufe oder ihre Rückgabewerte wieder.
Natürlich ist dieser Teil ebenfalls in XML. Dies führt dazu, dass verschiedenste eigene
Datentypen bzw. Datenstrukturen übertragen werden können.
- Seite 10 von 18 -
WSDL
Wie bei jeder Middelware, ein Web Service ist defakto nichts anderes, muß es ein
unabhängige Beschreibung der verschiedensten Funktionen stattfindend. Die
Beschreibungssprache die Web Services nutzen, heißt Web Service Description
Language. Oder kurz WSDL.
WSDL-Dokumente sind in XML formatiert und nutzen den WSDL-XML-Namespace zur
Standardisierung der Funktionen. Dies hat den entscheidenden Vorteil, dass sowohl
Mensch als auch Maschine diese Beschreibungen lesen können.
In der Regel ist für einen Entwickler nicht notwendig ein WSDL-Dokument zu lesen,
geschweige denn selber zu schreiben. Für beide Fälle gibt es entsprechende Tools
die dies dem Entwickler abnehmen können. Dies hat auch den immensen Vorteil,
dass die Entwicklungszeit eines Web Services sehr gering ist, da sich der Entwickler
nur um die eigentliche Fachlogik kümmern muß. Die Umsetzung geschieht dann voll
automatisch.
Dies ist ähnlich zu dem Ansatz der RMI aus Java. Tatsächlich werden Web Services in
Java über die Funktionsweise der RMI angesprochen.
Hierfür stellt Sun zwei Werkzeuge zur Verfügung.
1. JAVA2WSDL: Dies ist ein Tool mit dem man aus einem Java Programm einen
WSDL Code erzeugen kann. Dies ist vor allem für den Diensterbringer notwendig.
Da er ja seinen Dienst beschreiben muß.
2. WSDL2JAVA: Dies ist ein Tool aus dem man wiederum aus einem WSDL
Dokument, das man z.B. von einem Internetserver bezogen hat, ein Java
Programm zu erstellen.
Es gibt noch diverse andere Tools die aber ähnliche Funktionsweisen anbieten. Zum
Beispiel gibt es von Microsoft im .net Paket solle Tools die die Kommunikation
zwischen C# und Web Services erlauben. So das er möglich ist, eine Web Service
anzubieten, der in Java Programmiert wurde, und der von einem C# Programm
genutzt wird.
- Seite 11 von 18 -
UDDI
Universal Description, Discovery und Integration (UDDI) ist also der Verzeichnisdienst
für Web Services. Man kann UDDI neben SOAP und WSDL zu den drei
Grundbausteinen des Web-Service-Ansatzes zählen (siehe Das Web Service
Rollenmodell auf Seite 5). Es geht auf eine Initiative der drei Firmen Microsoft, IBM
und Ariba zurück und wurde im Jahre 2000 erstmals vorgestellt.
Inzwischen wird UDDI von OASIS standardisiert. Die aktuelle Version des Standards
ist 3.0 und wurde im Juli 2002 verabschiedet. Die besten und aktuellsten
Informationen bekommt man von der UDDI-eigenen Web-Seite http://uddi.org
Die Veröffentlichungen der UDDI-Arbeitsgruppe (http://uddi.org/specification.html)
innerhalb OASIS lassen sich in drei Arten von Dokumenten gruppieren:
1. die eigentlichen Standards, die die entsprechenden Normen darstellen. Wenn es
Konflikte mit anderen Dokumenten geben sollte, dann sind dies die
entscheidenden. Es gibt Dokumente für UDDI v1, v2 und v3.
2. die Best Practices. Hier wird beschrieben, wie man in der Praxis UDDI-Registries
am besten einsetzt und wie man darauf zugreift.
3. die so genannten Technical Notes. Auch hier wird auf eher technischer Ebene
beschrieben, wie man UDDI-Registries benutzt.
Der Name UDDI setzt sich aus den drei Funktionen der Registry zusammen:
1. Description: oder auch „Yellow Pages“ genannt. Hier findet man alle angebotenen
Web Services sortiert nach ihrem Dienst.
2. Discovery: oder auch „White Pages“ genannt. Sie enthalten alle Relevanten Daten
über die Firmen oder Organisationen die sich bei der UDDI Registriert haben.
3. Integration: oder auch „Green Pages“ genannt. Hier findet man die URI aller
registrierten Web Services und deren WSDL Beschreibung.
- Seite 12 von 18 -
EJB & Web Services
Eine recht neue Idee ist es, einen Web Service bereit zu stellen, der als „Interface“
für einen EJB-Server dient. Damit hat man natürlich den Vorteil, dass man die
Features beider Systeme nutzen kann.
Ein paar Probleme gibt es auf dem Weg dahin aber natürlich doch noch zu lösen.
Zum einen gibt es bei den EJBs Java Beans, bei denen eine Session nicht nur mit der
Übertragung einer einzigen Nachricht beendet ist. Da ein Web Service aber eben
nicht nach halten kann, ob ein Client zu einer bestimmten Session gehört, muß der
Client eine Session-ID bei jedem Aufruf mitliefern. Dies kann jedoch Problematisch
sein.
Eine schon sehr weit Entwickelte und beliebt EJB Lösung heißt JBoss. Dies ist ein
Open-Source-Applikations-Server bei dem man sich bemüht eine Anbindung an Web
Services zu realisieren.
Für weitere Informationen sei hier auf den Vortrag zu EJBs innerhalb dieses Seminars
verwiesen.
- Seite 13 von 18 -
Sicherheitsanforderungen
Der Begriff der Sicherheit in verteilten Systemen ist zunächst natürlich sehr allgemein
gehalten. Gemeinhin versucht man deshalb, die Anforderungen, die an solche
Systeme bzgl. der Sicherheit bestehen, weiter aufzuschlüsseln. Dabei hat sich das
Schema, nach dem wir im Folgenden den Begriff Sicherheit definieren, als Standard
heraus geschält. Dazu zählen Vertraulichkeit, Authentizität, Integrität, NichtAnfechtbarkeit und Verfügbarkeit.
1. Vertraulichkeit
Vertraulichkeit wird erreicht, wenn nur diejenigen eine Nachricht bzw. ein Datum
lesen können, die dazu autorisiert sind. Das bedeutet nicht, dass andere diese
Nachricht nicht sehen können, es heißt nur, dass sie den Inhalt nicht verstehen
können.
Das Problem einer kompromittierten Vertraulichkeit entsteht vor allem durch die
Übertragung von Daten. Es ist gemeinhin leichter, Nachrichten zu lesen, die über
irgendeine Art von Medium übertragen werden, als in einen Computer einzubrechen
(der nicht am Netz ist) und die Daten dort auszuspähen. Insbesondere die
zunehmende Verbreitung drahtloser Kommunikation spielt hier eine wichtige Rolle,
denn gerade das Medium Funk ist sehr leicht abzuhören.
Vertrauliche Nutzung von Web Services bedeutet, dass niemand, der nicht das Recht
dazu hat, mitbekommt, welche Daten Sie an einen Web Service übertragen und
welche Antwort der Web Service zurückschickt. Auf den ersten Blick könnte man
meinen, das Problem wäre doch eigentlich mit dem schon bekannten HTTPS gelöst.
Wir werden weiter unten sehen, dass das nur zum Teil stimmt, weswegen man sich
einige andere Lösungen hat einfallen lassen.
2. Authentizität
Authentizität ist erreicht, wenn Sie sicher sein können, dass derjenige, mit dem Sie
gerade digital kommunizieren, auch tatsächlich der ist, für den Sie ihn halten. Das ist
keineswegs selbstverständlich: Wenn Sie eine E-Mail bekommen mit einer
bestimmten Absenderadresse, dann gehen Sie gewöhnlich davon aus, dass diese
Adresse auch stimmt. Unglücklicherweise ist es sehr einfach, diese Adresse zu
fälschen.
Probleme bei der Authentizität sind vor allem deshalb ein Problem, weil sie die Basis
für den Prozess der Autorisierung bildet: Aufgrund der Tatsache, dass man jemanden
eine bestimmte Identität (oder besser eine Rolle) zuschreibt, werden ihm auf einem
System entsprechende Rechte gewährt. Mit anderen Worten: Wenn es jemandem
- Seite 14 von 18 -
gelingt, unrechtmäßig eine bestimmte Rolle einzunehmen, dann stehen ihm
sämtliche Rechte zu, die mit
dieser Rolle verbunden sind. Wenn man sich beispielsweise als Administrator
gegenüber einem System authentifizieren kann, dann kann man auf dem System
praktisch alles tun.
Ein bekanntes Authentifizierungsverfahren beruht auf der Verwendung von
Passworten oder von PINs und TANs z.B. beim Homebanking. Hier weist man sich
durch den Besitz gewisser Kenntnisse aus. Modernere Verfahren arbeiten mit
biometrischen Methoden, bei denen beispielsweise Fingerabdrücke oder die Netzhaut
gescannt werden.
Authentizität bei Web Services bedeutet, dass der Diensterbringer weiß, von wem ein
Dienstaufruf kommt, und dass der Dienstnutzer nachvollziehen kann, von wem dieser
Dienst erbracht wird. Sicherlich wären auch hier z.B. Passworte einzusetzen, wir
werden jedoch sehen, dass das nicht immer eine gute Lösung ist und dass man sich
deshalb spezielle Verfahren zur Authentifizierung auf der Nachrichtenebene
ausgedacht hat.
3. Integrität
Bei der Bewahrung der Integrität von Nachrichten geht es darum sicherzustellen,
dass diese Nachrichten während der Übertragung nicht von einem Dritten verändert
werden. Auch dies ist natürlich aus denselben Gründen möglich, wie der Bruch von
Vertraulichkeit: Wenn es einem böswilligen Dritten gelingt, einen Zwischenrechner im
Netz unter Kontrolle zu bringen, dann ist es ihm ohne Probleme möglich, eintreffende
Nachrichten abzufangen und entsprechend den eigenen Wünschen zu ändern.
Bei Web Services würde das bedeuten, dass einerseits Aufrufe eines Dienstes
verändert werden könnten, so dass z.B. der Zustand einer Ressource anders
beeinflusst werden würde als dies ursprünglich vorgesehen war. Andererseits könnte
auch die Ergebnisnachricht abgefangen werden. Interessanterweise kann man
Integrität für Nachrichten mit denselben bzw. sehr ähnlichen Mitteln erreichen wie
Authentizität.
4. Nicht-Anfechtbarkeit
Bei vielen geschäftlichen Situationen kommt es darauf an, dass zweifelsfrei
nachgewiesen werden kann, dass ein bestimmtes Ereignis stattgefunden hat. Dazu
gehören beispielsweise alle Arten von Bestellungen. Hier möchte der Empfänger
sichergehen, dass das Produkt auch wirklich korrekterweise ausgeliefert und nicht
wieder zurückgeschickt wird, wobei der Besteller behaupten könnte, er hätte das
Produkt gar nicht bestellt. Im realen Leben geschieht dies beispielsweise durch
Unterschriften unter Kaufverträge. In der digitalen Welt muss dazu ein Äquivalent
- Seite 15 von 18 -
gefunden werden. Es geht also darum, im Nachhinein dem Sender einer Nachricht
nachweisen zu können, dass er die Nachricht tatsächlich abgeschickt hat.
5. Verfügbarkeit und Zugangskontrolle
Bei diesem letzten Punkt geht es schließlich darum, dass Ressourcen im Netz auch
verfügbar sein müssen, damit sie von Nutzen sind. Der schönste Dienst bringt nichts,
wenn man von ihm keine Antworten bekommt.
Es gibt viele Möglichkeiten, dafür zu sorgen, dass ein Dienst nicht verfügbar ist. Die
Palette reicht von der physischen Zerstörung des Rechners, auf dem der Dienst läuft,
über ein Einbrechen auf dem Rechner und z.B. dem Löschen von für den Dienst
wichtigen Daten bis hin zu den massiven Denial-of-Service-Angriffen aus dem Netz,
bei denen ein Rechner schlicht mit Nachrichten überschwemmt wird, bis er nicht
mehr antworten kann.
Zur Sicherstellung der Verfügbarkeit hat man sich ebenfalls eine Reihe von
Maßnahmen einfallen lassen, die jedoch nicht immer funktionieren. Wir werden eines
der wichtigsten Mittel, den Firewall, im nächsten Abschnitt besprechen, werden aber
auch feststellen müssen, dass ein traditioneller Firewall gerade bei Web Services ins
Leere läuft.
- Seite 16 von 18 -
Ausblick
Web Services werden heutzutage schon sehr erfolgreich als plattformübergreifende
Middleware eingesetzt. Besonders von Vorteil ist hierbei die Eigenschaft, auf
bestehenden und gut etablierten Internettechnologien wie HTTPS oder DNS
aufzubauen, anstatt zu versuchen das Rad neu zu erfinden. Auch die Durchlässigkeit
von Firewalls auf den Ports für HTTP und HTTPS ist eine große Hilfe, auch wenn
dadurch natürlich das Sicherheitskonzept untergraben wird. Firewalls, die SOAPAufrufe erkennen und filtern, werden sicher auch nicht mehr lange auf sich warten
lassen.
Natürlich gibt es unzählige Szenarien, wie verschiedene Angebote genutzt werden
können, sei es das intelligente Haus, das Ihnen aufgrund des schlechten
Wetterberichts das Mitnehmen des Regenschirms nahe legt, oder Ihr Auto, das Sie
künftig über die Radarfalle um die Ecke informiert. Allen Szenarien liegt ein Prinzip
zugrunde, nämlich die Kombination der Daten aus verschiedenen Quellen. Web
Services übertragen Daten, wie es Web-Server heute schon mit HTML-Seiten tun.
Allerdings sind die Daten in XML strukturiert und ermöglichen es dem Client so, die
Information programmatisch weiter zu verwenden. Damit ist es möglich, Dinge zu
tun, die der einzelne Serviceanbieter nicht leisten kann. Die Staumeldung im Radio
ist hilfreich. Sie ist aber noch viel hilfreicher, wenn diese Information mit der GPS
Positionsinformation des Nutzers kombiniert wird.
Diese Möglichkeiten werden heute nur ansatzweise genutzt. In den nächsten Jahren
wird man sicherlich noch vieles über Web Services hören und vor allem sehen
werden.
- Seite 17 von 18 -
Quellenangabe
http://www.w3c.org
Java Web Services - O'Reilly – ISBN: 3-897-21284-6
Web Services – Hanser Verlag - ISBN: 3-446-22530-7
- Seite 18 von 18 -