Java SE 8 Standard-Bibliothek  
Professionelle Bücher. Auch für Einsteiger.
 
Inhaltsverzeichnis


Vorwort
1 Neues in Java 8 und Java 7
2 Fortgeschrittene String-Verarbeitung
3 Threads und nebenläufige Programmierung
4 Datenstrukturen und Algorithmen
5 Raum und Zeit
6 Dateien, Verzeichnisse und Dateizugriffe
7 Datenströme
8 Die eXtensible Markup Language (XML)
9 Dateiformate
10 Grafische Oberflächen mit Swing
11 Grafikprogrammierung
12 JavaFX
13 Netzwerkprogrammierung
14 Verteilte Programmierung mit RMI
15 RESTful und SOAP-Web-Services
16 Technologien für die Infrastruktur
17 Typen, Reflection und Annotationen
18 Dynamische Übersetzung und Skriptsprachen
19 Logging und Monitoring
20 Sicherheitskonzepte
21 Datenbankmanagement mit JDBC
22 Java Native Interface (JNI)
23 Dienstprogramme für die Java-Umgebung
Stichwortverzeichnis

Jetzt Buch bestellen
Ihre Meinung?

Spacer
<< zurück
Java SE 8 Standard-Bibliothek von Christian Ullenboom
Das Handbuch für Java-Entwickler
Buch: Java SE 8 Standard-Bibliothek

Java SE 8 Standard-Bibliothek
Pfeil 15 RESTful und SOAP-Web-Services
Pfeil 15.1 Web-Services
Pfeil 15.2 RESTful Web-Services
Pfeil 15.2.1 Aus Prinzip REST
Pfeil 15.2.2 Jersey
Pfeil 15.2.3 JAX-RS-Annotationen für den ersten REST-Service
Pfeil 15.2.4 Test-Server starten
Pfeil 15.2.5 REST-Services konsumieren
Pfeil 15.2.6 Content-Handler, Marshaller und verschiedene MIME-Typen
Pfeil 15.2.7 REST-Parameter
Pfeil 15.2.8 REST-Services mit Parametern über die Jersey-Client-API aufrufen
Pfeil 15.2.9 PUT-Anforderungen und das Senden von Daten
Pfeil 15.2.10 PUT/POST/DELETE-Sendungen mit der Jersey-Client-API absetzen
Pfeil 15.3 Daily Soap und das SOAP-Protokoll
Pfeil 15.3.1 Die technische Realisierung
Pfeil 15.3.2 Web-Service-APIs und Implementierungen
Pfeil 15.3.3 @WebService
Pfeil 15.3.4 Einen Web-Service definieren
Pfeil 15.3.5 Web-Services veröffentlichen
Pfeil 15.3.6 Einen JAX-WS-Client implementieren
Pfeil 15.4 Zum Weiterlesen
 
Zum Seitenanfang

15RESTful und SOAP-Web-Services Zur vorigen ÜberschriftZur nächsten Überschrift

»Wenn die Menschen nur über Dinge reden würden, von denen sie etwas verstehen – das Schweigen wäre bedrückend.«
– Robert Lembke (1913–1989)

 
Zum Seitenanfang

15.1Web-Services Zur vorigen ÜberschriftZur nächsten Überschrift

Zum Ansprechen entfernter Ressourcen und zum Aufrufen entfernter Methoden gibt es mehrere Ansätze. Ein einfaches Verfahren ist die Anfrage mit Parametern an einen Webserver, der den Inhalt zurückliefert. Das entspricht im Wesentlichen dem, was auch ein Client zum Ansprechen einer Suchmaschine macht – er schickt den Such-String zum Server und bekommt eine Antwort zurück. Sind wir in einer Client-Server-Architektur und gilt es, auf einem Server Operationen auszuführen, so gibt es unterschiedliche Standards wie RMI, CORBA, DCOM, RPC, so wie schon im vorangegangenen Kapitel aufgeführt.

Plattformübergreife Kommunikation

Doch Lösungen wie RMI oder CORBA sind nicht immer optimal, und idealerweise unterhalten sich Client und Server unter folgenden Voraussetzungen:

  • Ihre Kommunikation erfolgt über einen offenen Port, denn Sicherheitsbeauftragte tolerieren es nicht, wenn irgendwelche neuen Ports zusätzlich aufgemacht werden müssen. Der Weg über HTML ist hier optimal, da das Protokoll HTTP verbreitet ist und der Port zum HTTP-Server in der Regel frei bzw. über einen Proxy unproblematisch ist. RMI und CORBA lassen sich zwar über HTTP tunneln, aber das ist keine ordentliche und performante Lösung.

  • Java ist zwar immer noch die wichtigste Programmiersprache für kritische Geschäftsanwendungen, aber natürlich nicht die einzige. Lösungen sollten plattformübergreifend sein, damit Client und Server auf beliebigen Betriebssystemen und in beliebigen Programmiersprachen entwickelt werden können. Mit RMI lässt sich nicht wirklich ein .NET-Client mit einem Java EE-Server verbinden. Und Byteorder (Big-Endian, Little-Endian) sollen keine Rolle spielen – genauso wie die interne Repräsentation von Fließkommazahlen.

  • Im Optimalfall ist der Zugriff ohne aufwändige Generatoren zu realisieren. Das vereinfacht auch das Testen enorm.

Es ist naheliegend, die Übertragung über HTTP vorzunehmen und ein neutrales Textprotokoll einzusetzen, um keine Bindung an Rechnersysteme und Programmiersprachen zu erzwingen. Bietet ein Webserver Dienste für Clients an, nennen wir das Web-Service, wobei wir erst einmal offen lassen, wie genau die Kommunikation zwischen Client und Server aussieht.

REST und SOAP

Da es verschiedene Anforderungen in der Webkommunikation gibt, haben sich zwei bekannte Web-Service-Standards herausgebildet:

  • SOAP-Web-Services: SOAP ist ein standardisiertes Protokoll, bei dem XML-Nachrichten übertragen werden. SOAP ist ähnlich wie RMI eine Technologie zum entfernten Methodenaufruf, bei der Argumente übergeben und eine Rückgabe eingesammelt wird. Die Parameter und Rückgaben sind exakt in einer WSDL-Datei beschrieben (ebenfalls im XML-Format), und es lassen sich gut Generatoren einsetzen, die mithilfe dieser WSDL-Datei Zugriffsklassen in allen möglichen Programmiersprachen generieren.

  • RESTful Web-Services: Beim REST-Prinzip wird eine Anfrage über HTTP an den Webserver gestellt. Anstatt entfernte Operationen aufzurufen und Argumente in einem XML-Dokument zu übergeben, kodiert die URL die Ressource, und nur einige wenige Operationen (wie Lesen und Aktualisieren) sind möglich. Im Mittelpunkt steht eine Ressource, die eindeutig adressierbar ist. Die Ressource hat eine Repräsentation, die in jedem Format sein kann, also XML, Text, Bilder oder .mp3-Dateien.

Da SOAP-basierte Web-Services zeitlich vor RESTful Web-Services bekannt wurden, haben sie sozusagen den Begriff »Web-Services« geprägt. RESTful Web-Services kamen später, und so ist der Begriff »Web-Service« eigentlich mehrdeutig. Durch den historischen Vorsprung von SOAP ist der Begriff »Web-Service« in der Öffentlichkeit aber oft noch mit SOAP assoziiert.

Beide Verfahren haben ihre Vorzüge, und es ist nicht so, dass eine Variante immer besser als die andere Variante ist. Wenn es Ressourcenzugriffe und keine entfernten Aufrufe an wirkliche Objekte mit Zuständen und Verhalten gibt, ist ein RESTful Web-Service eine gute Wahl. Stehen entfernte Objekte mit ihren vielfältigen Funktionen im Vordergrund, ist ein SOAP-Web-Service in Ordnung. Beide verfolgen unterschiedliche Philosophien, daher ist die Wahl zwischen REST oder SOAP keine Frage der technischen Realisierung: Web-Services können von einer Variante in die andere überführt werden, doch dann »fühlt« es sich nicht mehr so natürlich an. RESTful ist ein Architekturstil und kein Standard wie SOAP.

 


Ihre Meinung

Wie hat Ihnen das Openbook gefallen? Wir freuen uns immer über Ihre Rückmeldung. Schreiben Sie uns gerne Ihr Feedback als E-Mail an kommunikation@rheinwerk-verlag.de.

<< zurück
Zum Rheinwerk-Shop
Zum Rheinwerk-Shop: Java SE 8 Standard-Bibliothek Java SE 8 Standard-Bibliothek
Jetzt Buch bestellen

 Buchempfehlungen
Zum Rheinwerk-Shop: Java ist auch eine Insel
Java ist auch eine Insel


Zum Rheinwerk-Shop: Professionell entwickeln mit Java EE 8
Professionell entwickeln mit Java EE 8


Zum Rheinwerk-Shop: Besser coden
Besser coden


Zum Rheinwerk-Shop: Entwurfsmuster
Entwurfsmuster


Zum Rheinwerk-Shop: IT-Projektmanagement
IT-Projektmanagement


 Lieferung
Versandkostenfrei bestellen in Deutschland, Österreich und der Schweiz
InfoInfo

 
 


Copyright © Rheinwerk Verlag GmbH 2018. Original - https://www.rheinwerk-verlag.de/openbook/
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das Openbook denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt.
Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.

 

 
 


29.09.2022 - Sitemap.xml