Webdienste in Java SE, Teil 1: Werkzeugübersicht

Java Standard Edition (SE) 6 enthielt Unterstützung für Webdienste. Dieser Beitrag beginnt eine vierteilige Reihe zu Webdiensten in Java SE, in der erläutert wird, was Webdienste sind, und die Unterstützung von Java SE für diese Dienste erläutert wird. Zukünftige Beiträge werden diese Unterstützung zum Erstellen von SOAP-basierten und RESTful-basierten Webdiensten verwenden und auch erweiterte Webdienstthemen behandeln.

Java XML und JSON

In dieser Serie gehe ich davon aus, dass Sie XML und JSON verstehen. Wenn nicht, sollten Sie sich mein Java XML- und JSON- Buch ansehen , das am Ende dieses Beitrags angekündigt wird.

Was sind Webdienste?

Wikipedia definiert Webdienst als "ein Softwaresystem, das die interoperable Interaktion von Maschine zu Maschine über ein Netzwerk unterstützt". Eine detailliertere Definition erhalten Sie, indem Sie zuerst die Teile dieses Begriffs definieren:

  • Web: Ein riesiges, miteinander verbundenes Netzwerk von Ressourcen, bei dem eine Ressource eine URI-Datenquelle (Uniform Resource Identifier) ​​ist, z. B. ein PDF-basiertes Dokument, ein Videostream, eine Webseite oder sogar eine Anwendung. Auf diese Ressourcen kann mithilfe von Standard-Internetprotokollen wie HTTP (HyperText Transfer Protocol) oder SMTP (Simple Mail Transfer Protocol) zugegriffen werden.
  • Dienst: Eine serverbasierte Anwendung oder Softwarekomponente, die eine Ressource über einen Nachrichtenaustausch nach einem Nachrichtenaustauschmuster (MEP) für Clients verfügbar macht. Der Request-Response-MdEP ist typisch.

Angesichts dieser Definitionen ist ein Webdienst eine serverbasierte Anwendungs- / Softwarekomponente, die Clients über einen Nachrichtenaustausch eine webbasierte Ressource zur Verfügung stellt. Diese Nachrichten können gemäß XML (Extensible Markup Language) oder JSON (JavaScript Object Notation) formatiert werden. Diese Nachrichten können auch als Aufrufen von Webdienstfunktionen und Empfangen von Aufrufergebnissen betrachtet werden. Abbildung 1 zeigt diesen Nachrichtenaustausch.

Abbildung 1. Ein Client greift auf eine Ressource zu, indem er Nachrichten mit einem Webdienst austauscht

Unternehmen und Webdienste

Unternehmen nutzen Webdienste, weil sie herkömmliche Middleware-Probleme (z. B. teuer in der Beschaffung und Wartung, nicht in der Lage, mit Backend-Software und Client-Anwendungen über das Internet zu kommunizieren, und unflexibel) überwinden, indem sie auf freien und offenen Standards basieren, durch ihre Wartbarkeit, durch Einbeziehung das Web und durch Flexibilität. Darüber hinaus helfen sie größeren Unternehmen, ihre oftmals erheblichen Investitionen in Legacy-Software zu erhalten.

Webdienste können als einfach oder komplex klassifiziert werden. Einfache Webdienste interagieren nicht mit anderen Webdiensten (z. B. einer eigenständigen serverbasierten Anwendung mit einer einzigen Funktion, die die aktuelle Zeit für eine bestimmte Zeitzone zurückgibt). Im Gegensatz dazu interagieren komplexe Webdienste häufig mit anderen Webdiensten. Beispielsweise kann ein allgemeiner Webdienst für soziale Netzwerke mit Twitter- und Facebook-Webdiensten interagieren, um alle Twitter- und Facebook-Informationen für eine bestimmte Person zu erhalten und an seinen Kunden zurückzugeben. Komplexe Webdienste werden auch als Mashups bezeichnet, da sie Daten aus mehreren Webdiensten mischen (kombinieren).

Serviceorientierte Architektur

Webdienste sind eine Implementierung von Service-Oriented Architecture (SOA) , einem Stil des Software-Designs, bei dem Dienste für verschiedene Softwarekomponenten über ein Kommunikationsprotokoll über ein Netzwerk bereitgestellt werden. Stellen Sie sich SOA als eine Reihe von Entwurfsprinzipien oder als Rahmen für die Implementierung von Geschäftslogik als wiederverwendbare Services vor, die auf unterschiedliche Weise kombiniert werden können, um den sich ändernden Geschäftsanforderungen gerecht zu werden.

SOAP-basierte Webdienste

Ein SOAP-basierter Webdienst ist eine weit verbreitete Webdienstkategorie, die auf SOAP basiert , einer XML-Sprache zum Definieren von Nachrichten (Aufrufe abstrakter Funktionen oder deren Antworten), die von beiden Enden einer Netzwerkverbindung verstanden werden können. Ein Austausch von SOAP-Nachrichten wird als Operation bezeichnet , die einem Funktionsaufruf und seiner Antwort entspricht und in Abbildung 2 dargestellt ist.

Abbildung 2. Ein Webdienstvorgang umfasst Eingabe- und Ausgabemeldungen

Verwandte Vorgänge werden häufig in einer Schnittstelle zusammengefasst , die konzeptionell einer Java-Schnittstelle ähnelt. Eine Bindung enthält konkrete Details darüber, wie eine Schnittstelle an ein Messaging-Protokoll (insbesondere SOAP) gebunden ist, um Befehle, Fehlercodes und andere Elemente über das Kabel zu übertragen. Der URI für die Bindung und eine Netzwerkadresse (eine IP-Adresse und ein Port) wird als Endpunkt bezeichnet , und eine Sammlung von Endpunkten ist ein Webdienst . Abbildung 3 zeigt diese Architektur.

Abbildung 3. Auf Schnittstellen von Operationen kann über ihre Endpunkte zugegriffen werden

SOAP wird häufig mit der WSDL (Web Services Description Language) verwendet , einer XML-Sprache zum Definieren der Vorgänge eines Webdienstes. Ein WSDL-Dokument ist ein formeller Vertrag zwischen einem SOAP-basierten Webdienst und seinen Clients, der alle Details für die Interaktion mit dem Webdienst enthält. In diesem Dokument können Sie Nachrichten in Vorgänge und Vorgänge in Schnittstellen gruppieren. Außerdem können Sie für jede Schnittstelle eine Bindung sowie die Endpunktadresse definieren.

SOAP-basierte Webdienste unterstützen nicht nur WSDL-Dokumente, sondern verfügen auch über die folgenden Eigenschaften:

  • Die Fähigkeit, komplexe nicht funktionierende Anforderungen wie Sicherheit und Transaktionen zu erfüllen : Diese Anforderungen werden über verschiedene Spezifikationen verfügbar gemacht. Um die Interoperabilität zwischen diesen Spezifikationen zu fördern, wurde die Web Services Interoperability Organization (WS-I) (ein Branchenkonsortium) gegründet. WS-I hat eine Reihe von Profilen erstellt, bei denen es sich bei einem Profil um eine Reihe benannter Webdienstspezifikationen auf bestimmten Revisionsebenen handelt, sowie eine Reihe von Implementierungs- und Interoperabilitätsrichtlinien, in denen empfohlen wird, wie die Spezifikationen zur Entwicklung interoperabler Webdienste verwendet werden können. Das allererste Profil, WS-I Basic Profile 1.0 , besteht beispielsweise aus den folgenden nicht proprietären Webdienstspezifikationen:
  • SOAP 1.1
  • WSDL 1.1
  • Universal Description Discovery und Integration (UDDI) 2.0
  • XML 1.0 (Zweite Ausgabe)
  • XML-Schema Teil 1: Strukturen
  • XML-Schema Teil 2: Datentypen
  • RFC2246: Das Transport Layer Security Protocol Version 1.0
  • RFC2459: Internet X.509 Public Key-Infrastrukturzertifikat und CRL-Profil
  • RFC2616: HyperText Transfer Protocol 1.1
  • RFC2818: HTTP über TLS
  • RFC2965: HTTP-Statusverwaltungsmechanismus
  • Das Secure Sockets Layer Protocol Version 3.0

Weitere Profilbeispiele sind das grundlegende WS-I-Sicherheitsprofil und das einfache SOAP-Bindungsprofil. Weitere Informationen zu diesen und anderen Profilen finden Sie auf der WS-I-Website. Java SE unterstützt das WS-I-Basisprofil.

  • Die Fähigkeit, asynchron mit einem Webdienst zu interagieren: Webdienstclients sollten in der Lage sein, nicht blockierend und asynchron mit einem Webdienst zu interagieren. Die clientseitige Unterstützung für asynchrone Aufrufe von Webdienstvorgängen wird in Java SE bereitgestellt.

SOAP-basierte Webdienste werden in einer Umgebung ausgeführt, die einen Dienstanforderer (den Client), einen Dienstanbieter und einen Dienstbroker umfasst. Diese Umgebung ist in Abbildung 4 dargestellt.

Abbildung 4. Ein SOAP-basierter Webdienst umfasst einen Dienstanforderer, einen Dienstanbieter und einen Dienstbroker (z. B. UDDI).

Der Dienstanforderer, normalerweise eine Clientanwendung (z. B. ein Webbrowser) oder möglicherweise ein anderer Webdienst, sucht zuerst den Dienstanbieter auf irgendeine Weise. Beispielsweise kann der Dienstanforderer ein WSDL-Dokument an einen Dienstbroker senden, der mit einem anderen WSDL-Dokument antwortet, das den Standort des Dienstanbieters identifiziert. Der Dienstanforderer kommuniziert dann über SOAP-Nachrichten mit dem Dienstanbieter.

Dienstanbieter müssen veröffentlicht werden, damit andere sie finden und verwenden können. Im August 2000 wurde eine offene Brancheninitiative namens Universal Description, Discovery and Integration (UDDI) gestartet, mit der Unternehmen Servicelisten veröffentlichen, sich gegenseitig entdecken und definieren können, wie die Services oder Softwareanwendungen über das Internet interagieren. Diese plattformunabhängige, XML-basierte Registrierung war jedoch nicht weit verbreitet und wird derzeit nicht verwendet. Viele Entwickler empfanden UDDI als zu kompliziert und ohne Funktionalität und entschieden sich für Alternativen wie die Veröffentlichung der Informationen auf einer Website. Beispielsweise hat Google seine öffentlichen Webdienste (z. B. Google Maps) einmal unter //code.google.com/more/ verfügbar gemacht.

Die SOAP-Nachrichten, die zwischen Dienstanforderern und Dienstanbietern fließen, werden häufig nicht angezeigt und als Anforderungen und Antworten zwischen den SOAP-Bibliotheken ihrer Webdienstprotokollstapel übergeben. Es ist jedoch möglich, direkt auf diese Nachrichten zuzugreifen, wie Sie später in dieser Serie feststellen werden.

Große Webdienste

SOAP-basierte Webdienste werden auch als große Webdienste bezeichnet, da sie auf vielen Spezifikationen basieren, z. B. den zuvor erwähnten WS-I-Profilen.

RESTful Web Services

SOAP-basierte Webdienste können über Protokolle wie HTTP, SMTP, FTP und BEEP (Blocks Extensible Exchange Protocol) bereitgestellt werden. Das Bereitstellen von SOAP-Nachrichten über HTTP kann als eine besondere Art von RESTful-Webdienst angesehen werden.

Ein RESTful-Webdienst ist eine weit verbreitete Webdienstkategorie, die auf Representational State Transfer (REST) basiert , einem Softwarearchitekturstil für verteilte Hypermedia-Systeme (Systeme, in denen sich Bilder, Text und andere Ressourcen in Netzwerken befinden und über Hyperlinks zugänglich sind). . Das Hypermedia-System, das in einem Webdienstkontext von Interesse ist, ist das World Wide Web.

REST-Geschichte

Roy Fielding (Hauptautor der HTTP-Spezifikationsversionen 1.0 und 1.1 und Mitbegründer der Apache Software Foundation) führte REST bereits 2000 in seiner Dissertation ein und definierte sie. Fielding stellte sich REST als den Architekturstil des Web vor, obwohl er schrieb lange nachdem das Web ein Going-Concern war. REST wird allgemein als Lösung für die zunehmende Komplexität von SOAP-basierten Webdiensten angesehen.

Der zentrale Teil von REST ist die URI-identifizierbare Ressource. REST identifiziert Ressourcen anhand ihrer MIME-Typen (Multipurpose Internet Mail Extensions) (z. B. text / xml). Außerdem haben Ressourcen Zustände, die von ihren Darstellungen erfasst werden. Wenn ein Client eine Ressource von einem RESTful-Webdienst anfordert, sendet der Dienst eine MIME-typisierte Darstellung der Ressource an den Client.

Clients verwenden die Verben POST, GET, PUT und DELETE von HTTP, um Ressourcendarstellungen abzurufen und Ressourcen zu bearbeiten. REST ordnet diese Verben wie folgt der Datenbank CRUD-Operationen (Create, Read, Update and Delete) zu:

  • POST: Erstellen Sie eine neue Ressource basierend auf Anforderungsdaten.
  • GET: Lesen Sie die vorhandene Ressource, ohne Nebenwirkungen zu verursachen (ändern Sie die Ressource nicht).
  • PUT: Aktualisieren Sie die vorhandene Ressource mit Anforderungsdaten.
  • LÖSCHEN: Vorhandene Ressource löschen.

Auf jedes Verb folgt eine URI, die die Ressource identifiziert. (Dieser immens einfache Ansatz ist grundsätzlich nicht kompatibel mit dem Ansatz von SOAP, codierte Nachrichten an eine einzelne Ressource zu senden.) Der URI kann sich auf eine Sammlung wie //javajeff.ca/libraryoder auf ein Element der Sammlung beziehen, wie z. B. //javajeff.ca/library/9781484219157- diese URIs sind nur Abbildungen.

Bei POST- und PUT-Anforderungen werden XML-basierte Ressourcendaten als Hauptteil der Anforderung übergeben. Beispielsweise könnten Sie POST //javajeff.ca/library HTTP/ 1.1(wo HTTP/ 1.1die HTTP-Version des Anforderers beschrieben wird) eine Anforderung zum Einfügen POSTder XML-Daten in die //javajeff.ca/libraryErfassungsressource interpretieren .

Bei GET- und DELETE-Anforderungen werden die Daten normalerweise als Abfragezeichenfolgen übergeben, wobei eine Abfragezeichenfolge der Teil eines URI ist, der mit einem ?Zeichen beginnt . Wenn beispielsweise GET //javajeff.ca/libraryeine Liste von Kennungen für alle Bücher in einer libraryRessource zurückgegeben wird, wird GET //javajeff.ca/library?isbn=9781484219157wahrscheinlich eine Darstellung der Buchressource zurückgegeben, deren Abfragezeichenfolge die International Standard Book Number (ISBN) identifiziert 9781484219157.

Erfahren Sie mehr über HTTP-CRUD-Zuordnungen

Eine vollständige Beschreibung der Zuordnungen zwischen HTTP-Verben und ihren CRUD-Gegenstücken finden Sie in der Tabelle "RESTful Web Service HTTP-Methoden" im Eintrag "Representational State Transfer" von Wikipedia.

REST stützt sich auch auf die Standardantwortcodes von HTTP, z. B. 404 (angeforderte Ressource nicht gefunden) und 200 (Ressourcenoperation erfolgreich), sowie auf MIME-Typen (wenn Ressourcendarstellungen abgerufen werden).

RESTful vs big Web Services

Wenn Sie sich fragen, ob Sie einen Webdienst mit SOAP oder REST entwickeln sollen, lesen Sie RESTful Web Services vs. "Big" Web Services: Treffen Sie die richtige Architekturentscheidung.

Webdienstunterstützung in Java SE

Vor Java SE 6 wurden Java-basierte Webdienste ausschließlich mit dem Java Enterprise Edition (EE) SDK entwickelt. Obwohl Java EE für die Entwicklung von Webdiensten aus Produktionssicht bevorzugt wird, bieten Java EE-basierte Server ein sehr hohes Maß an Skalierbarkeit, eine Sicherheitsinfrastruktur, Überwachungsfunktionen usw., die wiederholte Bereitstellung eines Webdienstes auf einem Java EE Container waren oft zeitaufwändig und verlangsamten die Entwicklung. Java SE 6 vereinfachte und beschleunigte die Entwicklung von Webdiensten, indem APIs, Anmerkungen, Tools und ein kompakter HTTP-Server (zum Bereitstellen von Webdiensten auf einem einfachen Webserver und zum Testen in dieser Umgebung) in den Kern aufgenommen wurden.

APIs

Java SE bietet mehrere APIs, die Webdienste unterstützen. Zusammen mit verschiedenen JAXP-APIs (SAX, DOM, StAX usw.), die ich in Java XML und JSON diskutiere , bietet Java SE die JAX-WS-, JAXB- und SAAJ-APIs: