Friedrich. Kiltz. Java Webservices

Transkript

1 Friedrich Kiltz Java Webservices

2 Einleitung Zunächst stelle ich Ihnen die Zielsetzung des Buches und die Zielgruppe vor, also die Fragen nach dem WAS für WEN. Dann zeige ich die Struktur des Buches auf und beschreibe mein durchgängiges Beispiel. Am Ende der Einleitung erläutere ich noch kurz die Bestandteile und den Aufbau der einzelnen Anwendungsfälle, die in den entsprechenden Kapiteln als Handlungshilfe angefügt sind. Ziel des Buches Webservices sind nach der Zeit des Hypes schon längst erwachsen und zu einem ernst zu nehmenden Bestandteil der IT-Landschaft geworden. Wenn eine Technologie erwachsen wird, verdichten sich die Leistungen der Frameworks auf jene konkreten Aufgaben, die sich in der Praxis für diese Technologie bewährt haben. Dennoch gibt es eine riesige Vielfalt von Aufgaben für Webservices, die sich auch in der Berechtigung der unterschiedlichen Frameworks widerspiegelt. Inzwischen gibt es eine schon fast unüberschaubare Anzahl von Frameworks, die uns dabei unterstützen sollen, Webservices effektiv zu erstellen und performant zu nutzen. In der Praxis kristallisieren sich drei Hauptbereiche für die Nutzung von Webservices heraus: Einfache und schnelle Webservices Umfangreiche und komplexe Webservice-Applikationen Normale Webservices, die den Standardanforderungen von Webservices entsprechen Für die einfachen Webservices wie die Abfrage einer BLZ oder die Nutzung der Schufa-Auskunft wird immer öfter die Kombination aus REST und JSON genutzt. Für die komplexen, tiefgreifend konfigurierbaren Webservice-Landschaften ist Axis2 immer eine sehr gute Wahl. In Bezug auf die Standardanforderungen kann auch sehr gut der Standard JAX-WS mit Metro zum Einsatz kommen. Was hier ein wenig plakativ erscheint, wird das Buch genauer beleuchten. Darzustellen, welches Framework für welche Aufgabe in welcher Umgebung sinnvoll sein wird, ist eines der Ziele dieses Buches. Hierbei lege ich den Schwerpunkt auf die folgenden Top-Frameworks: Axis2 Metro für JAX-WS 13

3 Einleitung Jersey für JAX-RS Spring-WS Apache CXF Diese Frameworks stelle ich in ihren Grundlagen, Stärken und Schwächen vor und gebe ganz konkrete Hilfen für den Einsatz und die Nutzung, wobei der Schwerpunkt der Vorstellung auf dem Einstieg und den gebräuchlichsten Nutzungsarten liegt. Im Rahmen dieses Buches kann und will ich nicht bis in die letzten Details der Frameworks vordringen. Zweites Ziel des Buches ist es, dem Entwickler eine Art Handbuch zu bieten, in dem typische Situationen dargestellt und Schritt für Schritt gelöst werden. Hierbei werden auch kleine Abstecher in alternative Wege und mögliche Fehlersituationen gemacht, um der Praxis Rechnung zu tragen. Das Buch setzt sich nicht mit den konzeptionellen Überlegungen von SOA auseinander, sondern betrachtet die technischen Realisierungen per Webservices, die sich aus einer SOA heraus ergeben können. Für die ausgiebige Betrachtung der SOA kann ich nur das Buch»SOA in der Praxis«von [Josuttis08] empfehlen. Zielgruppe Dieses Buch bietet einen Einstieg in die Realisierung von Webservices und die Nutzung einiger interessanter Frameworks. Es soll Entwickler und Programmierer beim Einstieg in ihr Webservice-Projekt und bei der Auswahl des richtigen Frameworks unterstützen. Ich stelle die grundlegenden Technologien und den Kontext von Webservices vor und biete konkrete Handlungsanweisungen für die unterschiedlichen Aufgaben, die sich bei der Entwicklung von Webservices ergeben. Weiterhin stelle ich mehrere Frameworks mit ihren Stärken und Schwächen vor. Ich stelle heraus, was diese Frameworks so besonders macht und in welchem Umfeld sie sich am besten entfalten können. Dabei setze ich beim Leser gute Java-Kenntnisse voraus. Ein Verständnis für verteilte Anwendungen ist erforderlich. Zu diesem Zweck habe ich in Kapitel 7 einen Exkurs in die Entwicklung der verteilten Anwendungen beigefügt. Kenntnisse über XML sind ebenfalls erforderlich. Als Wiederholung ist in Anhang D eine kurze Erinnerung eingefügt. Downloads im Internet Die Listings zu allen Beispielen finden Sie zum kostenlosen Download im Internet unter 14

4 Aufbau des Buches Aufbau des Buches Teil A: Bestimmung der Mitte und Stecken der Grenzen. Im ersten Teil arbeite ich den Schwerpunkt des Buches heraus und stelle die Nachbardisziplinen mit ihren Schnittstellen vor. Kapitel 1: Überblick Webservices zeigt, was Webservices sind und stellt die sich daraus ergebenden Aufgabenbereiche vor. Kapitel 2: Kontext von Webservices erklärt die Einbettung und Abgrenzung von Webservices zu ihren Nachbardisziplinen. Teil B: Technische Grundlagen beschreibt die Techniken, auf denen Webservices aufbauen. Sie bilden die Grundlagen unserer Realisierungen. Kapitel 3: Technologien für Webservices klärt die allgemeinen technischen Vorkenntnisse. Kapitel 4: SOAP stellt das SOAP-Protokoll vor. Kapitel 5: WSDL Web Services Description Language zeigt den Aufbau, die Nutzung und die Versionen von WSDL. Kapitel 6: REST REpresentational State Transfer zeigt den Aufbau und das Wesen von REST. Kapitel 7: Webservice-Architektur in Java zeigt die Entwicklung zur Architektur für Webservices in einem kurzen Abriss von Socket-Verbindungen über RMI zu JAX-RPC bis zu JAX-WS. Teil C: Tools und Frameworks stellt die gebräuchlichsten Frameworks für die Realisierung von Webservices vor. Kapitel 8: Axis2 Die zweite Generation des erfolgreichen Frameworks. Kapitel 9: Metro-Framework Die Referenzimplementierung von JAX-WS. Kapitel 10: Jersey Die Referenzimplementierung für REST. Kapitel 11: Spring-WS Springs Lösung für Webservices. Kapitel 12: Apache CXF Der Zusammenschluss von XFire und Celtix. Kapitel 13: Vergleich der Frameworks zeigt die Unterschiede, Stärken und Schwächen der Frameworks im Überblick. Teil D: Weitere wichtige Information Kapitel 14: Weiterführende Themen zu wichtigen Themen wie Performance, Interoperabilität und Sicherheit. Beispiel Ein Beispiel für Webservices aufzubauen, ist gar nicht einfach, da ihr Einsatzbereich sehr breit gefächert ist. Einer meiner Kunden nutzt Webservices, um unter- 15

5 Einleitung schiedliche Systeme miteinander zu verbinden. Da werden Cobol-Programme, die die Kernfunktionalität abbilden, weiterhin genutzt und per Webservices anderen Programmen zur Verfügung gestellt. Andere bilden ganz konkrete B2B-Aufgaben zu ihren verteilten Geschäftspartnern mit Webservices ab und wieder andere wie Amazon bieten die Dienste ihrer Websites als Webservices an, damit diese in die Programme ihrer Kunden integriert werden können. Ich habe als durchgängiges Beispiel eine kleine Importfirma klassischer und erlesener Waren vor Augen. Sie hat den Namen Edeltraut GmbH kurz Traudel. Wir importieren Weine aus Frankreich und Italien, Olivenöl und Halloumi aus Zypern, Datteln aus Marokko, Vanille aus Madagaskar, Safran aus dem Iran und natürlich Whisky aus Schottland. Diese Firma werden wir aus den Blickwinkeln betrachten, die durch eine Vernetzung per Webservices unterstützt werden können. Dies sind die Beziehungen zu den zahlreichen, weit verstreuten Lieferanten, dies sind die unterschiedlichen Absatzkanäle, mit denen wir unsere Waren wieder verkaufen, und dies sind die Beziehungen zu verbundenen Unternehmen, die unser wichtiges Netzwerk bilden. Der folgende Überblick zeigt, dass diese Beziehungen fast überall zu finden sind. Edeltraut steht für das moderne vernetzte Unternehmen. uc Edeltraut und Partner Lieferanten Gastronomie Edeltraut Vertrieb Einzelhandel Unterstützung Spedition Zoll Abb. E.1: Edeltraut und Partner 16

6 Beispiel Um eine Vergleichbarkeit der Frameworks sicherzustellen, werde ich zwei Anwendungsfälle von Edeltraut durch alle Frameworks ziehen lassen. Zum einen wird ein kleiner Kommunikationstest aufgebaut, ein»hallo World«oder ein»ping«, also eine Überprüfung der Kommunikation, um die Erreichbarkeit unserer Services zu testen. Die Komplexität des Ping wird zwar meist belächelt, zeigt aber die Schritte auf, die ich zum Aufbau eines funktionierenden Webservices brauche. Zum anderen wird ein abgeschlossenes, aber komplexeres Beispiel in allen Frameworks beleuchtet, das einen zentralen Anwendungsfall von Edeltraut beinhaltet: eine komplexere Datenstruktur in Form einer Rechnung und ein paar Methoden zum Erstellen und Lesen von Rechnungen. Die Datenstruktur der Rechnungen enthält die üblichen Fallstricke und Klippen für Webservices. Die Rechnung hat schöne Beziehungen zu anderen komplexen Typen (Artikel, Kunde), enthält die gebräuchlichsten Datentypen (Primitive, Date etc.), eine Liste mit Positionen und eine Enumeration für den Status. Der Service bietet Methoden, um neue Rechnungen zu erstellen, alte Rechnungen zu lesen und Rechnunclass domain Serializable Rechnung - datum: Date - id: Long - kunde: Kunde - nr: String -positionen * -kunde Serializable Position - artikel: Artikel - id: Long - menge: int -artikel Artikel - id: Long - preis: float - status: Status - txt: String -status «enumeration» Status AUF_LAGER LIEFERBAR NICHT_LIEFERBAR Serializable Kunde - id: Long - name: String - ort: String - plz: String - strasse: String - vorname: String Abb. E.2: Domain-Modell der Rechnung 17

7 Einleitung gen zu finden. In dieser Datenstruktur sind einige Anforderungen, die uns im Umgang mit einem Webservice das Leben schwer machen können. Ich denke, dass das Beispiel Edeltraut zukunftsfähig ist, denn ich gehe davon aus, dass die Zukunft der Unternehmen in der Vernetzung liegt. Ich hoffe, dass die Zukunft darin liegt, dass selbstständige Unternehmen miteinander kooperieren und freie Netzwerke bilden. Dies kann nur dann effektiv funktionieren, wenn eine reibungslose und effiziente Kommunikation zwischen den Unternehmen und alternativen Handelspartnern möglich ist. Die Reibungsverluste durch die Eigenständigkeit des Unternehmens müssen durch eine geeignete Technologie vermindert werden. Diese Anforderung kann durch Webservices erfüllt werden. In meinen Beispielen nutze ich das Paket de.traudel. Die Domain traudel.de gehört mir nicht. Zum jetzigen Zeitpunkt möchte jemand diese Domain verkaufen. Ich hoffe, dass derjenige, der sie dann kauft, keinen Groll gegen meine dreiste Nutzung hegen mag. Aufbau der Anwendungsfälle Am Ende der betreffenden Kapitel stelle ich typische Aufgaben rund um das Framework in Form von Anwendungsfällen zusammen. Die Anwendungsfälle sollen die Situation des Entwicklers widerspiegeln, in denen er sich bei der Realisierung von Webservices befinden kann. Die Anwendungsfälle sollen dann eine gezielte Unterstützung der Bearbeitung dieser Aufgabe sein. Der Aufbau für die Anwendungsfälle stellt sich folgendermaßen dar: Name: Name des Anwendungsfalls und somit Name des Abschnitts. Kurzbeschreibung: Ein oder zwei Sätze, um zu erkennen, um was es in dem Anwendungsfall geht und ob der Anwendungsfall für mich zutrifft. Ausgangssituation/Voraussetzung: Auf welcher Umgebung setzen wir auf? Welche Programme sollten installiert sein? Welche Programmteile sollten schon vorhanden sein? Einige Anwendungsfälle bauen aufeinander auf. Das Ziel eines Anwendungsfalls kann eine Voraussetzung für den aktuellen Anwendungsfall sein. Ziel: Was wollen wir mit dem Anwendungsfall erreichen? Wann sind wir fertig mit der Aufgabe? Hierbei versuche ich, objektiv erreichbare Zustände zu definieren. Durch die Definition eines klaren Ziels wird vermieden, dass man sich in die vielen wundervollen Einzelheiten (die auch noch mit dem Fall zu tun haben) verliert. Alternativen und interessante Randgebiete werden später noch behandelt. Ablauf: Das Good-Day-Szenario. Hier stelle ich den grundsätzlichen Ablauf ohne Alternativen oder Umwege dar. Der Weg ist meist nicht der einzig grad- 18

8 Aufbau der Anwendungsfälle linige, aber der aus meiner Sicht beste, um von der Ausgangssituation zum Ziel zu kommen. Die aufgeführten Schritte sind klein und übersichtlich gehalten und zeigen das Wesen des Schrittes. Die dabei nicht selten notwendigen Quellcodes füge ich der Übersichtlichkeit wegen an das Ende des Anwendungsfalls. Fehlersituationen: In diesem Abschnitt zeige ich zu den einzelnen Schritten des Ablaufs gern gemachte Fehler auf. Dabei beschreibe ich die Ursache des Fehlers und seine Lösungsmöglichkeiten. Alternativen: Bei vielen Aufgaben gibt es auch andere Wege zu einer Lösung, die in bestimmten Situationen meist auch gar nicht schlechter, sondern sogar besser sind als die Schritte aus dem Ablauf. Diese alternativen Wege und ihre Bedeutung stelle ich in diesem Abschnitt dar. Dokumente: Um die Übersichtlichkeit in den vorherigen Abschnitten zu erhalten, füge ich erst am Ende des Anwendungsfalls die genutzten Quellcodes, Diagramme und Screenshots ein, die für den Anwendungsfall wichtig sind. 19