Java für Fortgeschrittene Proseminar im Sommersemester 2009

Java für Fortgeschrittene
Proseminar im Sommersemester 2009
Web Services
Julija Got
Technische Universität München
25.05.2009
Zusammenfassung
In dieser Arbeit wird auf die technische Implementierung in Java
und die Bestandteile von Web Services eingegangen. Dabei werden zuerst
Grundbegriffe Web Services und serviceorientierte Architekturen behandelt und im weiteren werden einzelne Komponenten der Web Services und
JAX-WS dargestellt.
1
Einleitung
Heute ist die Fähigkeit Information zwischen Abteilungen, Kunden und Partnern problemlos auszutauschen, lebenswichtig für den Erfolg für ein Unternehmen. Viele Organisationen verwenden eine Vielfalt von unterschiedlichen Anwendungen, die Daten ganz unterschiedlich speichern und austauschen, und
können deshalb nicht miteinander effektiv kommunizieren. Dadurch, dass unterschiedliche Anwendungen nicht immer die Informationen austauschen und aufeinander zugreifen können, entstand der Bedarf, eine Schnittstelle zwischen den
verschiedenen Anwendugen zu entwickeln, die gleichzeitig Plattform- und Programmiersprachenunabhängig ist. Diese Rolle haben Web Services, die nach der
SOA-Philosophie entwickelt wurden, übernommen. Web Services sind interoperabel und geben Programmen, die über Netz verbunden sind, eine Möglichkeit
zu kommunizieren.
Auch im Alltag können wir uns unsere Welt nicht mehr ohne Web Services vorstellen. Dienste, um Ticketpreise für Flüge bei unterschiedlichen Airlines, Hotels
oder gar Pauschalreisen auf derselben Webseite zu vergleichen und zu buchen,
Nachrichten von verschiedenen Agenturen auf einer Seite zu lesen, Transaktionen in Banken und vieles mehr lassen die Illusion entstehen, dass wir nur auf
einen Server zugreifen, obwohl sich dahinter ganze Netze verbergen. Wie solche
Netze entstehen und wie man sie mit Hilfe von JAX-WS verbindet, wird im
Weiteren vorgestellt.
1
2
Web Services und SOA
Im Unterkapitel Web Services“ wird auf die Begrifsdefinition von Web Services
”
eingangen. Anschließend in Service Oriented Architecture“ wird der Grundge”
danke, auf dem Web Services basieren, dargelegt.
2.1
Web Services
Ein Web Service ist ein Stück der Geschäftslogik, das irgendwo“ im Internet
”
liegt und durch standardisierte Internetprotokolle wie HTTP oder SMTP erreichbar ist.
In Anbetracht dieser Definition könnte man mehrere Technologien der Vergangenheit als Web Service-Technologien klassifizieren, wie etwa die Win32 Plattform, J2EE, CORBA und CGI Script. Der Hauptunterschied zwischen diesen
Technologien und der neuen Generation der Web Services ist ihre Standardisierung und die Anerkennung der Technik von den meisten bedeutenden ITUnternehmen. Deshalb werden Web Services mit folgenden 6 Punkten definiert:
• Web Services sind Bestandteile von Anwendungen
• Web Services kommunizieren durch offene Protokolle (HTTP, FTP, JMS,
usw.)
• Web Services sind selbständig und selbstbeschreibend
• Web Services können in UDDI (siehe 3.4) registriert und später wiedergefunden werden
• Web Services können durch Anwendungen benutzt werden
• XML ist die Basis für Web Services (WSDL, XSD, SOAP)
Web Services ermöglichen eine verteilte Umgebung, in der Anwendungen unabhängig von der Programmiersprache und Plattform untereinander kommunizieren können. Web Services fördern eine Umgebung für Systeme, die lose
verbunden sind, und ermöglichen deren Zusammenwirken.
2.2
Service Oriented Architecture
Viele der Ideen für Web Services basieren auf Konzepten der sogenannten
Service-Oriented Architecture (SOA). Eine SOA-Infrastruktur erlaubt verschiedenen Anwendungen, Daten miteinander in einer heterogenen Landschaft auszutauschen. Service-Orientierung zielt auf eine lose Kopplung von Services mit
Betriebssystemen, Programmiersprachen und anderen Technologien; sie trennt
Funktionen in verschiedene Einheiten, oder Services, die Entwickler über ein
Netz zugänglich machen, damit die Benutzer sie kombinieren und in fertigen
Anwendungen wiederverwenden können. Abbildung 1 verdeutlicht den Unterschied zwischen Client/Server- Architektur, wo Kommunikation nur zwischen
PC und Server möglich ist und SOA, die Informationsübermittlung zwischen
unterschiedlichen Servern unterstützt.
2
Abbildung 1: Client/Server Architektur und SOA - Infrastruktur
3
Wie arbeiten Web Services?
Elemente der Web-Service-Plattform sind:
• SOAP (Simple Object Access Protocol)
• UDDI (Universal Description, Discovery and Integration)
• WSDL (Web Services Description Language)
• XML (Extensible Markup Language)
• HTTP (Hypertext Transfer Protokol)
3.1
3.1.1
Internet Standards
XML
XML bezeichnet eine universelle Beschreibungssprache, die ein Standard zur
Erzeugung menschen- und maschinenlesbarer Dokumente beinhaltet. In der
Kombination mit anderen Standards macht XML es möglich, den Inhalt eines Dokumentes getrennt von seiner Formatierung zu definieren und diesen Inhalt in anderen Anwendungen wiederzuverwenden. Dadurch wird XML als eine
plattform- und programmiersprachenunabhängige Sprache definiert, die komplexe Nachrichten und Funktionen ausdrücken kann. XML ist Hauptbestandteil
von WSDL, XSD und SOAP und ist ein Standard des W3C (World Wide Web
Consortium)[8].
3
Abbildung 2: SOAP-Zusammenarbeit
3.1.2
HTTP Protokoll
Das HTTP-Protokoll ist das am meisten verwendete Internetprotokoll, das zur
Datenübertragung benutzt wird (vgl. Abb. 2 und 3). Die Kommunkation erfolgt
über TCP/IP (Transmission Control Protocol/Internet Protocol). Ein solcher
Vorgang könnte zum Beispiel wie folgt ablaufen:
Abbildung 3: Kommunikation zwischen Service und Client
Der HTTP-Client verbindet sich mit dem HTTP-Server mit Hilfe von
TCP. Nach dem Herstellen der Verbindung sendet der Client eine HTTPAnforderungsnachricht zum Server:
4
POST /item HTTP/1.1
Host: 189.123.345.239
Content-Type: text/plain
Content-Length: 200
Der Server antwortet (bei erfolgreicher Verbindung) mit:
POST /item HTTP/1.1
Host: 189.123.345.239
Content-Type: text/plain
Content-Length: 200
<informationen kommen hier>
Web Services können faktisch jedes Übertragungsprotokoll benutzen, aber es
wird üblicherweise HTTP zur Datenübertragung verwendet.
3.2
Web Service Description Language (WSDL)
WSDL ist eine XML-Technologie nach einem Standard des W3C, die das Interface eines Web Services auf eine standardisierte Weise beschreibt und in Form eines XML-Dokumentes angibt, wie bei einem Webdienst die Input- und OutputParameter eines Aufrufes aussehen müssen. Außerdem lokalisiert WSDL den
Web Service, indem es Zugriffsdaten enthält. WSDL ist notwendig für die Verbindung mit dem Service und erlaubt Clients automatisiert zu verstehen, wie
man mit einem Web Service interagieren kann.
3.2.1
Struktur von WSDL-Dokumenten
Bei der Beschreibung von Web Services benutzt WSDL folgende Elemente:
types - definiert Datentypen, die vom Web Service benutzt wurden
message - definiert die Datenelemente einer Operation. Jede Nachricht kann
aus einem oder mehreren Teilen bestehen. Die Teile können mit den Parametern eines Funktionsaufrufs einer traditionellen Programmiersprache verglichen
werden.
portType - beschreibt Web Service Operationen, die ausgeführt werden
können und Nachrichten, die zu den Operationen gehören.
binding - bestimmt das konkrete Protokoll und Datenformat für die Arbeitsschritte und Nachrichten, die durch einen bestimmten Port-Typ gegeben
sind.
service - fasst eine Menge von Ports zusammen.
5
<definitions targetNamespace="http://hello/" name="HelloService">
<types>
<xsd:schema>
<xsd:import namespace="http://hello/" schemaLocation="http://localhost:8080/
Hello/HelloService?xsd=1"/>
</xsd:schema>
</types>
<message name="sayHallo">
<part name="parameters" element="tns:sayHallo"/>
</message>
<message name="sayHalloResponse">
<part name="parameters" element="tns:sayHalloResponse"/>
</message>
<portType name="Hello">
<operation name="sayHallo">
<input message="tns:sayHallo"/>
<output message="tns:sayHalloResponse"/>
</operation>
</portType>
<binding name="HelloPortBinding" type="tns:Hello">
<soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document"/>
<operation name="sayHallo">
<soap:operation soapAction=""/>
<input>
<soap:body use="literal"/>
</input>
<output>
<soap:body use="literal"/>
</output>
</operation>
</binding>
<service name="HelloService">
<port name="HelloPort" binding="tns:HelloPortBinding">
<soap:address location="http://localhost:8080/Hello/HelloService"/>
</port>
</service>
</definitions>
Beispiel: HelloService.wsdl
6
Im oben angegebenen Beispiel wird ein WSDL-File von Hallo-Service (siehe Kapitel 4.1) dargestellt, das die nötigen Informationen über Inhalte von späteren
SOAP-Nachrichten enthält. Im types - Element werden unter schemaLocati”
on=“ virtuelle XSD-Typen definiert und importiert. XML-Schema beschreibt in
einer komplexen Schemasprache Datentypen, einzelne XML-Schema-Instanzen
(Dokumente) und Gruppen solcher Instanzen. Ein konkretes XML-Schema wird
auch als eine XSD (XML-Schema-Definition) bezeichnet. In diesem Beispiel
werden die Typen von http://localhost:8080/Hello/HelloService?xsd=1“ hin”
zugefügt. Folgender Beispiel veranschaulicht die aus einer externen Datei importierte XSD-Datei.
<xs:schema version="1.0" targetNamespace="http://hello/">
<xs:element name="sayHallo" type="tns:sayHallo"/>
<xs:element name="sayHalloResponse" type="tns:sayHalloResponse"/>
<xs:complexType name="sayHallo">
<xs:sequence>
<xs:element name="arg0" type="xs:string" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="sayHalloResponse">
<xs:sequence>
<xs:element name="return" type="xs:string" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
</xs:schema>
Beispiel: HelloService.xsd
Bei JAX-WS werden Java-Typen auf XSD-Typen abgebildet. Das message-Element führt die XSD-Typen
sayHallo“ und
sayHalloRe”
”
sponce“ an, die in portType als Eingangsnachrichtentyp ( sayHal”
lo“) und Ausgangsnachrichtentyp (sayHalloResponse) festgelegt werden.
Wie SOAP-Nachrichten definiert sind, ist in binding unter transport=“http://schemas.xmlsoap.org/soap/http“ angegeben. Außerdem beschreibt binding welche Voraussetzungen der Client beim Anbinden an den
Port des Web Services erfüllen muss. In diesem Beispiel wird als Kommunikationsmittel SOAP-Nachrichten gewählt und als Transportprotokoll HTTP,
wobei das Datenformat als dokument“ (style= dokument“ ) bestimmt
”
”
wird. Auf welche Art und Weise auf den Service zugegriffen wird, ist in service beschrieben. In diesem Beispiel wird es durch http::8080 HelloService“
”
ermöglicht.
7
3.3
Simple Object Access Protocol (SOAP)
Das Simple Object Access Protocol ist ein Kommunikationsprotokoll, um auf
Web Services zuzugreifen.
SOAP ist ein XML-basiertes Protokoll, das Kommunikationsformat zwischen
Service und Client bestimmt. SOAP stellt eine Verpackungsstruktur bereit,
um XML Dokumente über eine Vielfalt von Internettechnologien, einschließlich SMTP, HTTP, und FTP zu transportieren. Es stellt eine Struktur zur
Verfügung, um RPC (Remote Procedure Call) auszuführen und hat einen standardisierten Transportmechanismus, wodurch heterogene Clients und Server
miteinander arbeiten können: .NET Clients können auf EJBs (Enterprise Java Beans) und Java Clients auf .NET- Komponenten durch SOAP zugreifen.
Eine SOAP-Nachricht besteht aus vier Hauptteilen: Envelope, Header, Body
und Fault, die im folgenden Beispiel veranschaulicht sind. Die gezeigte SOAPNachricht wurde basierend auf dem WSDL-File automatisch gebildet.
SOAP Request
<?xml version="1.0" encoding="UTF-8"?>
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Header/>
<S:Body>
<ns2:sayHallo xmlns:ns2="http://hello/">
<arg0>Mr. Mustermann</arg0>
</ns2:sayHallo>
</S:Body>
</S:Envelope>
SOAP Response
<?xml version="1.0" encoding="UTF-8"?>
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Body>
<ns2:sayHalloResponse xmlns:ns2="http://hello/">
<return>Hello, Mr. Mustermann</return>
</ns2:sayHalloResponse>
</S:Body>
</S:Envelope>
Beispiel: SOAP Anfrage und Antwort
Ein Envelope-Element identifiziert das XML Dokument als eine SOAPNachricht und enthält eine Referenz auf den Standard(bspw. W3C) von SOAP.
8
Ein Header-Element ist optional und kann Meta-Informationen, beispielsweise zum Routing, zur Verschlüsselung oder zur Transaktionsidentifizierung
beinhalten.
Ein Body-Element enthält Aufruf- oder Antwortinformation. In eingeführtem
Beispiel (Abb. 6) wird der Text Julija“ in der Request-Nachricht übergeben
”
und nach der Bearbeitung von dieser Information enthält die SOAP-Antwort
die zurückgelieferte Information Hello, Julija“.
”
Ein Fault-Element ist optional und enthält die Information, wie die Nachricht
aussehen wird, falls ein Fehler auftritt bzw. die Fehler- und Zustandsinformationen.
Hier die wichtigsten Syntax-Regeln, die es einzuhalten gilt:
• Eine SOAP-Nachricht muss korrektes XML darstellen.
• Eine SOAP-Nachricht muss den SOAP Envelope namespace verwenden.
• Eine SOAP-Nachricht darf keinen Verweis auf eine DTD (Document Type
Definition) enthalten.
• Eine SOAP-Nachricht darf keine XML-Bearbeitungsanweisungen enthalten.
3.4
UDDI
UDDI ist ein platformunabhängiges Gerüst für die Beschreibung von Services
und die Integration von Business Services übers Internet. UDDI ist ein Verzeichnis von Informationen über Web Services und ist mit einem Telefonbuch
vergleichbar, bei dem an Stelle der Telefonnummer ein Verweis auf die WSDLBeschreibung steht. Weil es in vielen Szenarien nicht benötigt wird, Sicherheit
nicht vollständig gewährleistet ist (keiner trägt die Verantwortung für Richtigkeit und Vollständigkeit der Information) und es einige andere Nachteile gibt,
spielt es in der Praxis keine große Rolle.
3.5
Zusammenarbeit von SOAP, WSDL und UDDI
In Web Services gibt es zwei grundsätzliche Akteure: Application und Service
bzw. Client und Server zwischen denen die Kommunikation entstehen soll.
Web Services erlauben Clients die Prozeduren und Funktionen an entfernten
Objekten durch Benutzung eines XML-basierten Protokolls aufzurufen. Um diese Vorgänge besser zu verstehen, wird dies an Hand nachfolgender Abbildung
erklärt.
Abbildung 4 stellt folgenden Vorgang dar: Der Client stellt eine Anfrage an ein
UDDI Verzeichnis für den Service (entweder namentlich, nach Kategorie oder
nach Bezeichner). Der Client erhält die Information über die Position eines
WSDL-Dokumentes aus dem UDDI-Verzeichnis. Das WSDL-Dokument enthält
Information darüber, wie man sich mit dem Web Service in Verbindung setzt und
das Format von Anfrage-Nachrichten im XML Schema. Der Client erzeugt eine
9
Abbildung 4: Einfache Interaktion von Web Services
SOAP-Nachricht in Übereinstimmung mit dem XML Schema, das im WSDL
steht und sendet eine Anfrage an den Host (auf dem der Dienst bereitgestellt
wird).
Abbildung 5: Größeres System von Web Services
Das Beispiel in Abb. 5 stellt ein größeres System von Web Services dar. In
diesem Fall ist der Server gleichzeitig auch Client eines anderen Services.
4
JAX-WS
JAX-WS steht für Java API für XML Web Services und ist ein Nachfolger von
JAX-RPC 1.1. JAX-WS ist eine Technologie, um Web Services und Clients, die
durch Austausch von Nachrichten im XML-Format kommunizieren, zu erstellen. JAX-WS erlaubt dem Entwickler Web Services Nachrichten-orientiert oder
RPC (Remote Procedure Call)-orientiert zu schreiben. Diese beiden Varianten
unterscheiden sich zunächst einmal auf einer rein technischen Ebene, d.h. sie
10
bestimmen, wie genau die Informationen zwischen den Kommunikationspartner
ausgetauscht werden. SOAP wurde ursprünglich hauptsächlich als plattformunabhängiger Standard für RPC verwendet. In serviceorientierten Architekturen liegt der Fokus aber auf dem nachrichtenorientierten Verarbeitungsmodell.
Dieses wird von SOAP ebenso wie RPC unterstützt. Es werden nicht einzelne
Methoden nacheinander aufgerufen, sondern ein ganzes Dokument übertragen,
das den Geschäftsvorfall repräsentiert. Das führt zu einer viel loseren Kopplung
zwischen den Anwendungen. Dagegen bei RPC werden viele kleine Nachrichten
übertragen, was viel mehr Aufwand für das System mit sich bringt.
Im weiteren wird darauf eingegangen, wie man einen einfachen Web Service in
Java 6 entwickeln kann. Um ein anschauliches Beispiel zu geben, werden wir
einen Web Service und einen Web Client erstellen. Es existieren zwei Methoden
Web Services zu entwickeln:
Top-down Methode zum Erzeugen eines Web Services aus einem schon existierenden WSDL File.
Bottom-up Methode, die schon auf einem existierenden Java Bean basiert,
um daraus einen Web Service und ein WSDL-File zu erstellen.
Bei der Arbeit mit JAX-WS braucht man sich nicht um SOAP-Nachrichten zu
kümmern, die JAX-WS API erledigt das semi-automatisiert für den Entwickler.
Auch das WSDL-File kann von der IDE erzeugt werden, was die Anfangsschritte
noch einfacher macht.
4.1
Ein Beispiel-Webservice
4.1.1
Web Service
Es folgt ein Beispiel für einen einfachen Web Service, dessen WSDL-File und
SOAP-Nachrichten im Kapitel 3 als Beispiele dienten:
package helloservice;
import javax.jws.WebMethod;
import javax.jws.WebService;
@WebService
public class Hello
{
private String message = new String ("Hello, ");
@WebMethod
public String sayHallo(String name)
{
return message + name;
}
}
11
Das @WebService definiert unsere Klasse als sogenannten endpoint vom Web
Service. Die Klasse und die Methoden dürfen nicht final oder abstract sein. Die
Methoden müssen als public deklariert werden. Sie müssen auch mit @WebMethod gekennzeichnet sein.
Es gibt auch weitere Annotationen aus dem Packet javax.jws:
• @SOAPBinding setzt den Stil der Nachrichten auf Dokument oder RPC.
Bsp.: @SOAPBinding (style = SOAPBinding.Style.RPC)
• @WebParam beschreibt die Parameter genauer. Durch @WebParam(name=“neuer Name“) wird der Parametername, der in WSDL erscheint, mit dem angegebenen neuen Namen überschrieben.
Bsp.:
public double bmi(
@WebParam(name="height")double height,
@WebParam(name="weight" double weight)
{..}
• @WebResult ist eine optionale Angabe und definiert die Rückgabe einer
Web-Service-Methode genauer, z. B.:
@WebResult(name="HelloMethodResult")
• @OneWay wird für asynchrone Aufrufe verwendet: es wird nicht auf die
Antwort gewartet, sondern weiter gearbeitet.
Das wsgenTool generiert XML-Artefakte wie WSDL, XML-Schemata, die für
das Funktionieren des Web Services benötigt werden. Zusammen mit Application Server liefert wsgen eine Implementierung des Aplication Servers von
JAX-WS.
Um einen Web Service zu implementieren, sind folgende 5 Schritte nötig:
1. Codieren der Implementierung für die Klasse.
2. Die Klasse compilieren.
3. Mit Hilfe von wsgen nötige Dateien generieren.
4. Die Dateien in eine WAR Datei verpacken (Hauptpackformat für Webapplikationen).
5. Deploy der WAR Datei (z. B. über Tool des Web-Servers).
12
4.1.2
Client
Für das Erstellen des Clients für einen Web Service sind folgende Schritte nötig:
1. Codieren der Client-Klasse (hier wird die URL des fertigen WSDL-Files
gebraucht).
2. Mit wsimport Web Service Dateien generieren und Kompilieren, um Verbindung zum Web Service herzustellen.
3. Die Client Klasse kompilieren.
4. Den Client zum Laufen bringen.
So sieht z. B. ein einfacher Client aus:
import javax.xml.ws.WebServiceRef;
import helloservice.endpoint.HelloService;
import helloservice.endpoint.Hello;
public class HelloClient {
@WebServiceRef(wsdlLocation=
"http://localhost:8080/helloservice/hello?wsdl")
static HelloService service;
public static void main(String[] args)
{
try {
HelloClient client = new HelloClient();
client.doTest(args);
}
catch(Exception e)
{
e.printStackTrace();
}
}
public void doTest(String[] args)
{
try {
System.out.println("Retrieving the port from the following service: " + service);
Hello port = service.getHelloPort();
System.out.println("Invoking the sayHello operation on the port.");
String name;
if (args.length > 0) {
13
name = args[0];
} else {
name = "No Name";
}
String response = port.sayHello(name);
System.out.println(response);
}
catch(Exception e)
{
e.printStackTrace();
}
}
}
5
Vor- und Nachteile von Web Services
JAX-WS ist das moderne Web-Service-Programmiermodell, das die vom Programmiermodell JAX-RPC bereitgestellte Grundlage ergänzt. Die JAX-WS
Spezifizierung liefert Modernisierungen und neue Features bei der Entwicklung
von Web Services (z. B. Unterstützung von Annotationen der Web Services und
Tools für die Entwicklung der s. g. portable artifacts“). Es stellt neue Möglich”
keiten für Entwickler bereit und erweitert die Grenzen des Internets.
Es gibt sehr viele Vorteile, die Web Services mit sich bringen:
• Eine einfache und flexible Gestaltung von Geschäftsprozessen,
Effizientere Projektabwicklung: Durch die Verwendung von bereits
bestehenden und weit verbreiteten Internet-Standards (HTTP, XML etc.)
entsteht eine offene und flexible Architektur, die unabhängig von den verwendeten Plattformen, Programmiersprachen und Protokollen ist.
• Geringere Projektkosten, Investitionsschutz und Zukunftssicherheit: Die verwendeten offenen Standards vermeiden einige Lizenzkosten.
Da zu diesen Standards auch die allgegenwärtigen internetbasierten Technologien gehören, lassen sie sich auch vielerorts einsetzen. Auch hier liegt
ein Kostenvorteil.
• Web Services können faktisch auf jedes Übertragungsprotokoll aufsetzen.
Wobei Web Services auch nicht ohne Nachteile sind:
• Die Hauptschwierigkeiten bei der Umsetzung von Web Services dürften
Sicherheitsaspekte betreffen. So ist beim Transport zu beachten, dass
wichtige Web Services verschlüsselt werden oder eine Authentifizierung
stattfindet.
14
• Ein besonderes Augenmerk liegt auf der Performance. Diese wird durch
XML, Parsen und Dateigröße negativ beeinflusst. Der Verwaltungsaufwand nimmt bei stark verteilten Systemen zu.
6
Demoprojekt
In meinem Demoprojekt wird die Zusammenarbeit von Web Services dargestellt:
es wird ein fertiger Web Service, ein selbsterstellter Web Service und ein Client
benutzt. Das Programm zeigt schematisch, wie ein Internetgeschäft, das Aktien
verkauft, funktioniert. Der fertige Service liefert Aktienpreise von angefragten
Firmen, die an selbsterstellten Service weitergeleitet werden, wo sie bearbeitet
werden und anschliessend an den Client gesendet werden. Die Aufgabe des Clients ist die übergebene Information mit Hilfe von Servlets zu überarbeiten und
durch JSP (JavaServer Pages) anzuzeigen.
7
Zusammenfassung
Web Services ermöglichen eine problemlose Kommunikation zwischen unterschiedlichen Systemen, wodurch eine interoperable Informationsübermittlung
entsteht. Zusammenspiel von WSDL, SOAP und HTTP ermöglichen diese Interaktion.
Sicherheit ist ein Kernaspekt beim Einsatz von Web Services, insbesondere da die zugrunde liegenden Protokolle wie TCP/IP oder HTTP für sich
allein unsichere Transportmechanismen sind und weder XML noch SOAP
inhärente Sicherheitsmechanismen aufweisen. Im Wesentlichen wird zwischen
Sicherheitsmaßnahmen auf Applikations- und Transport-Ebene unterschieden.
In Transport-Ebene wird SSL (Secure Socket Layer) benutzt, aber es bietet
nicht genügend Sicherheit, da SOAP-Message-Header und SOAP-Body nicht
verschlüsselt werden können, weil sonst wichtige Routing-Informationen verloren gingen. Deshalb wird auch Sicherheit auf Applikations-Ebene benutzt, die s.
g. WS-Security. Sie erweitert SOAP um Funktionen wie Verschlüsselung und digitale Signaturen. In WS-Security wird festgeschrieben, wo genau in einer WebService-Schnittstellendefinition die Sicherheitsinformationen untergebracht sind
und dadurch wird fast vollständige Sicherheit der Daten garantiert [9].
Die Weiterentwicklung von Web Services wird hauptsächtlich von IBM und Microsoft beeinflusst und bereits jetzt bauen diese Unternehmen ihre Unternehmensstrategie auf dieser Technologie auf. Aber auch andere Softwarehersteller
wie BEA, Computer Associates, IBM, Microsoft, SAP oder Sun, aber auch Unternehmen aus anderen Branchen wie Bell, BT, die Deutsche Bank, die Deutsche
Telekom und Nokia sind in der Weiterentwicklung und Weiterverbreitung von
Web Services sehr interessiert, deshalb haben sie eine Web Services Interoperability Organization (WS-I, www.ws-i.org) gegründet, die als Hauptaufgabe hat
die Verbreitung von interoperablen Web Services über die Grenzen von Plattformen, Applikationen und Programmiersprachen hinweg zu fördern [10].
15
Literatur
[1]
David A. Chappell, Tyler Jewell
Java Web Services.
O´Reilly, March 2002, ISBN: 0-596-00269-6
[2]
James McGovern, Sameer Tyagi, Michael Stevens, Sunil Matthew
Java Web Services Architecture .
Morgan Kaufmann Publishers, 2003, ISBN:1558609008
[3]
Andrew S. Tanenbaum, Maarten van Steen
Verteilte Systeme (Prinzipien und Paradigmen)2., aktualisierte
Auflage .
2008, ISBN 978-3-8273-7293-2
[4]
Christian Ullenboom
Java ist auch eine Insel,7., aktualisierte Auflage .
2007, ISBN 978-3-8362-1146-8
[5]
Jurgen Dunkel, Andreas Eberhart, Stefan Fischer, Carsten Kleiner,
Arne Koschel
Systemarchitekturen für verteilte Anwendungen .
Hanser, 2008, ISBN 978-3-446-41321-4
[6]
http://java.sun.com/javaee/5/docs/tutorial/doc/bnayk.html
Dokumentation zu Web Services von SUN, 2009
[7]
http://publib.boulder.ibm.com/infocenter/radhelp/v6r0m1/index.jsp?topic=/
com.ibm.etools.webservice.doc/concepts/cwstopdown.html
Dokumentation zu Entwicklung von Web Services von IBM, 2009
[8]
www.w3.org
Dokumentation zum Standard W3C, 2009
[9]
entwickler.com
Web Services-Sicherheit und die SAML
Marc Chanliau, April 2006
[10]
www.informationweek.de
Kommunikation per Web Services
Stefan Zill, Mai 2005
16