Java für Fortgeschrittene Proseminar im Sommersemester 2009 Web Services

Transkript

1 Java für Fortgeschrittene Proseminar im Sommersemester 2009 Web Services Julija Got Technische Universität München 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 Fähigkeit Information zwischen Abteilungen, Kunden und Partnern problemlos auszutauschen, lebenswichtig für den Erfolg für ein Unternehmen. Viele Organisationen verwenden eine Vielfalt von unterschiedlichen Anwendungen, die Daten ganz unterschiedlich speichern und austauschen, und können deshalb nicht miteinander effektiv kommunizieren. Dadurch, dass unterschiedliche Anwendungen nicht immer die Informationen austauschen und aufeinander zugreifen können, entstand der Bedarf, eine Schnittstelle zwischen den verschiedenen Anwendugen zu entwickeln, die gleichzeitig Plattform- und Programmiersprachenunabhängig ist. Diese Rolle haben Web Services, die nach der SOA-Philosophie entwickelt wurden, übernommen. Web Services sind interoperabel und geben Programmen, die über Netz verbunden sind, eine Möglichkeit zu kommunizieren. Auch im Alltag können wir uns unsere Welt nicht mehr ohne Web Services vorstellen. Dienste, um Ticketpreise für Flü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 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 Grundgedanke, auf dem Web Services basieren, dargelegt. 2.1 Web Services Ein Web Service ist ein Stück der Geschäftslogik, das irgendwo im Internet liegt und durch standardisierte Internetprotokolle wie HTTP oder SMTP erreichbar ist. In Anbetracht dieser Definition kö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 IT- Unternehmen. 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 selbständig und selbstbeschreibend Web Services können in UDDI (siehe 3.4) registriert und später wiedergefunden werden Web Services können durch Anwendungen benutzt werden XML ist die Basis für Web Services (WSDL, XSD, SOAP) Web Services ermöglichen eine verteilte Umgebung, in der Anwendungen unabhängig von der Programmiersprache und Plattform untereinander kommunizieren können. Web Services fördern eine Umgebung für Systeme, die lose verbunden sind, und ermöglichen deren Zusammenwirken. 2.2 Service Oriented Architecture Viele der Ideen fü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 über ein Netz zugänglich machen, damit die Benutzer sie kombinieren und in fertigen Anwendungen wiederverwenden können. Abbildung 1 verdeutlicht den Unterschied zwischen Client/Server- Architektur, wo Kommunikation nur zwischen PC und Server möglich ist und SOA, die Informationsübermittlung zwischen unterschiedlichen Servern unterstützt. 2

3 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 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 mö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 programmiersprachenunabhängige Sprache definiert, die komplexe Nachrichten und Funktionen ausdrücken kann. XML ist Hauptbestandteil von WSDL, XSD und SOAP und ist ein Standard des W3C (World Wide Web Consortium)[8]. 3

4 Abbildung 2: SOAP-Zusammenarbeit HTTP Protokoll Das HTTP-Protokoll ist das am meisten verwendete Internetprotokoll, das zur Datenübertragung benutzt wird (vgl. Abb. 2 und 3). Die Kommunkation erfolgt über TCP/IP (Transmission Control Protocol/Internet Protocol). Ein solcher Vorgang kö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 HTTP- Anforderungsnachricht zum Server: 4

5 POST /item HTTP/1.1 Host: Content-Type: text/plain Content-Length: 200 Der Server antwortet (bei erfolgreicher Verbindung) mit: POST /item HTTP/1.1 Host: Content-Type: text/plain Content-Length: 200 <informationen kommen hier> Web Services können faktisch jedes Übertragungsprotokoll benutzen, aber es wird üblicherweise HTTP zur Datenü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 Output- Parameter eines Aufrufes aussehen müssen. Außerdem lokalisiert WSDL den Web Service, indem es Zugriffsdaten enthält. WSDL ist notwendig für die Verbindung mit dem Service und erlaubt Clients automatisiert zu verstehen, wie man mit einem Web Service interagieren kann 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 können mit den Parametern eines Funktionsaufrufs einer traditionellen Programmiersprache verglichen werden. porttype - beschreibt Web Service Operationen, die ausgeführt werden können und Nachrichten, die zu den Operationen gehören. binding - bestimmt das konkrete Protokoll und Datenformat für die Arbeitsschritte und Nachrichten, die durch einen bestimmten Port-Typ gegeben sind. service - fasst eine Menge von Ports zusammen. 5

6 <definitions targetnamespace=" name="helloservice"> <types> <xsd:schema> <xsd:import namespace=" schemalocation=" 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=" 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=" </port> </service> </definitions> Beispiel: HelloService.wsdl 6

7 Im oben angegebenen Beispiel wird ein WSDL-File von Hallo-Service (siehe Kapitel 4.1) dargestellt, das die nötigen Informationen über Inhalte von späteren SOAP-Nachrichten enthält. Im types - Element werden unter schemalocation= 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 hinzugefügt. Folgender Beispiel veranschaulicht die aus einer externen Datei importierte XSD-Datei. <xs:schema version="1.0" targetnamespace=" <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 führt die XSD-Typen sayhallo und sayhalloresponce an, die in porttype als Eingangsnachrichtentyp ( sayhallo ) und Ausgangsnachrichtentyp (sayhalloresponse) festgelegt werden. Wie SOAP-Nachrichten definiert sind, ist in binding unter transport= angegeben. Außerdem beschreibt binding welche Voraussetzungen der Client beim Anbinden an den Port des Web Services erfüllen muss. In diesem Beispiel wird als Kommunikationsmittel SOAP-Nachrichten gewä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 HelloService ermöglicht. 7

8 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 über eine Vielfalt von Internettechnologien, einschließlich SMTP, HTTP, und FTP zu transportieren. Es stellt eine Struktur zur Verfügung, um RPC (Remote Procedure Call) auszuführen und hat einen standardisierten Transportmechanismus, wodurch heterogene Clients und Server miteinander arbeiten können:.net Clients kö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 SOAP- Nachricht wurde basierend auf dem WSDL-File automatisch gebildet. SOAP Request <?xml version="1.0" encoding="utf-8"?> <S:Envelope xmlns:s=" <S:Header/> <S:Body> <ns2:sayhallo xmlns:ns2=" <arg0>mr. Mustermann</arg0> </ns2:sayhallo> </S:Body> </S:Envelope> SOAP Response <?xml version="1.0" encoding="utf-8"?> <S:Envelope xmlns:s=" <S:Body> <ns2:sayhalloresponse xmlns:ns2=" <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 SOAP- Nachricht und enthält eine Referenz auf den Standard(bspw. W3C) von SOAP. 8

9 Ein Header-Element ist optional und kann Meta-Informationen, beispielsweise zum Routing, zur Verschlüsselung oder zur Transaktionsidentifizierung beinhalten. Ein Body-Element enthält Aufruf- oder Antwortinformation. In eingeführtem Beispiel (Abb. 6) wird der Text Julija in der Request-Nachricht übergeben und nach der Bearbeitung von dieser Information enthält die SOAP-Antwort die zurückgelieferte Information Hello, Julija. Ein Fault-Element ist optional und enthä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 platformunabhängiges Gerüst für die Beschreibung von Services und die Integration von Business Services übers Internet. UDDI ist ein Verzeichnis von Informationen über Web Services und ist mit einem Telefonbuch vergleichbar, bei dem an Stelle der Telefonnummer ein Verweis auf die WSDL- Beschreibung steht. Weil es in vielen Szenarien nicht benötigt wird, Sicherheit nicht vollständig gewährleistet ist (keiner trägt die Verantwortung für Richtigkeit und Vollstä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 grundsä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 Vorgänge besser zu verstehen, wird dies an Hand nachfolgender Abbildung erklärt. Abbildung 4 stellt folgenden Vorgang dar: Der Client stellt eine Anfrage an ein UDDI Verzeichnis für den Service (entweder namentlich, nach Kategorie oder nach Bezeichner). Der Client erhält die Information über die Position eines WSDL-Dokumentes aus dem UDDI-Verzeichnis. Das WSDL-Dokument enthält Information darü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

10 Abbildung 4: Einfache Interaktion von Web Services SOAP-Nachricht in Übereinstimmung mit dem XML Schema, das im WSDL steht und sendet eine Anfrage an den Host (auf dem der Dienst bereitgestellt wird). Abbildung 5: Größeres System von Web Services Das Beispiel in Abb. 5 stellt ein größeres System von Web Services dar. In diesem Fall ist der Server gleichzeitig auch Client eines anderen Services. 4 JAX-WS JAX-WS steht für Java API fü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 zunächst einmal auf einer rein technischen Ebene, d.h. sie 10

11 bestimmen, wie genau die Informationen zwischen den Kommunikationspartner ausgetauscht werden. SOAP wurde ursprünglich hauptsächlich als plattformunabhängiger Standard für RPC verwendet. In serviceorientierten Architekturen liegt der Fokus aber auf dem nachrichtenorientierten Verarbeitungsmodell. Dieses wird von SOAP ebenso wie RPC unterstützt. Es werden nicht einzelne Methoden nacheinander aufgerufen, sondern ein ganzes Dokument übertragen, das den Geschäftsvorfall repräsentiert. Das führt zu einer viel loseren Kopplung zwischen den Anwendungen. Dagegen bei RPC werden viele kleine Nachrichten übertragen, was viel mehr Aufwand fü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 kümmern, die JAX-WS API erledigt das semi-automatisiert für den Entwickler. Auch das WSDL-File kann von der IDE erzeugt werden, was die Anfangsschritte noch einfacher macht. 4.1 Ein Beispiel-Webservice Web Service Es folgt ein Beispiel für einen einfachen Web Service, dessen WSDL-File und SOAP-Nachrichten im Kapitel 3 als Beispiele dienten: package helloservice; import javax.jws.webmethod; import public class Hello { private String message = new String ("Hello, public String sayhallo(string name) { return message + name; 11

12 definiert unsere Klasse als sogenannten endpoint vom Web Service. Die Klasse und die Methoden dürfen nicht final oder abstract sein. Die Methoden müssen als public deklariert werden. Sie müssen auch gekennzeichnet sein. Es gibt auch weitere Annotationen aus dem Packet setzt den Stil der Nachrichten auf Dokument oder RPC. (style = beschreibt die Parameter genauer. neuer Name ) wird der Parametername, der in WSDL erscheint, mit dem angegebenen neuen Namen überschrieben. Bsp.: public double double weight) ist eine optionale Angabe und definiert die Rückgabe einer Web-Service-Methode genauer, wird für asynchrone Aufrufe verwendet: es wird nicht auf die Antwort gewartet, sondern weiter gearbeitet. Das wsgentool generiert XML-Artefakte wie WSDL, XML-Schemata, die für das Funktionieren des Web Services benö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 nötig: 1. Codieren der Implementierung für die Klasse. 2. Die Klasse compilieren. 3. Mit Hilfe von wsgen nötige Dateien generieren. 4. Die Dateien in eine WAR Datei verpacken (Hauptpackformat für Webapplikationen). 5. Deploy der WAR Datei (z. B. über Tool des Web-Servers). 12

13 4.1.2 Client Für das Erstellen des Clients für einen Web Service sind folgende Schritte nö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 " 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

14 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 ergänzt. Die JAX-WS Spezifizierung liefert Modernisierungen und neue Features bei der Entwicklung von Web Services (z. B. Unterstützung von Annotationen der Web Services und Tools für die Entwicklung der s. g. portable artifacts ). Es stellt neue Möglichkeiten fü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 Geschäftsprozessen, Effizientere Projektabwicklung: Durch die Verwendung von bereits bestehenden und weit verbreiteten Internet-Standards (HTTP, XML etc.) entsteht eine offene und flexible Architektur, die unabhä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 allgegenwärtigen internetbasierten Technologien gehören, lassen sie sich auch vielerorts einsetzen. Auch hier liegt ein Kostenvorteil. Web Services können faktisch auf jedes Übertragungsprotokoll aufsetzen. Wobei Web Services auch nicht ohne Nachteile sind: Die Hauptschwierigkeiten bei der Umsetzung von Web Services dürften Sicherheitsaspekte betreffen. So ist beim Transport zu beachten, dass wichtige Web Services verschlüsselt werden oder eine Authentifizierung stattfindet. 14

15 Ein besonderes Augenmerk liegt auf der Performance. Diese wird durch XML, Parsen und Dateigröß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 Internetgeschä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 übergebene Information mit Hilfe von Servlets zu überarbeiten und durch JSP (JavaServer Pages) anzuzeigen. 7 Zusammenfassung Web Services ermöglichen eine problemlose Kommunikation zwischen unterschiedlichen Systemen, wodurch eine interoperable Informationsübermittlung entsteht. Zusammenspiel von WSDL, SOAP und HTTP ermöglichen diese Interaktion. Sicherheit ist ein Kernaspekt beim Einsatz von Web Services, insbesondere da die zugrunde liegenden Protokolle wie TCP/IP oder HTTP für sich allein unsichere Transportmechanismen sind und weder XML noch SOAP inhä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 genügend Sicherheit, da SOAP-Message-Header und SOAP-Body nicht verschlüsselt werden kö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 Verschlüsselung und digitale Signaturen. In WS-Security wird festgeschrieben, wo genau in einer Web- Service-Schnittstellendefinition die Sicherheitsinformationen untergebracht sind und dadurch wird fast vollständige Sicherheit der Daten garantiert [9]. Die Weiterentwicklung von Web Services wird hauptsä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, gegründet, die als Hauptaufgabe hat die Verbreitung von interoperablen Web Services über die Grenzen von Plattformen, Applikationen und Programmiersprachen hinweg zu fördern [10]. 15

16 Literatur [1] David A. Chappell, Tyler Jewell Java Web Services. O Reilly, March 2002, ISBN: [2] James McGovern, Sameer Tyagi, Michael Stevens, Sunil Matthew Java Web Services Architecture. Morgan Kaufmann Publishers, 2003, ISBN: [3] Andrew S. Tanenbaum, Maarten van Steen Verteilte Systeme (Prinzipien und Paradigmen)2., aktualisierte Auflage. 2008, ISBN [4] Christian Ullenboom Java ist auch eine Insel,7., aktualisierte Auflage. 2007, ISBN [5] Jurgen Dunkel, Andreas Eberhart, Stefan Fischer, Carsten Kleiner, Arne Koschel Systemarchitekturen für verteilte Anwendungen. Hanser, 2008, ISBN [6] Dokumentation zu Web Services von SUN, 2009 [7] com.ibm.etools.webservice.doc/concepts/cwstopdown.html [8] Dokumentation zu Entwicklung von Web Services von IBM, 2009 Dokumentation zum Standard W3C, 2009 [9] entwickler.com Web Services-Sicherheit und die SAML Marc Chanliau, April 2006 [10] Kommunikation per Web Services Stefan Zill, Mai