Der Thementitel ist wirklich eine Frage, denn... Ich selbst weiß nicht, was es ist und werde im Rahmen dieses Artikels zum ersten Mal versuchen, damit zu arbeiten. Das Einzige, was ich garantieren kann, ist, dass der unten dargestellte Code funktioniert, aber meine Formulierungen werden nur Annahmen und Vermutungen darüber sein, wie ich selbst das alles verstehe. So lass uns gehen...
Einführung
Wir müssen damit beginnen, warum das Konzept der Webdienste geschaffen wurde. Als dieses Konzept auf der Welt erschien, gab es bereits Technologien, die es Anwendungen ermöglichten, aus der Ferne zu interagieren, wobei ein Programm eine Methode in einem anderen Programm aufrufen konnte, die auf einem Computer in einer anderen Stadt oder sogar einem anderen Land gestartet werden konnte. All dies wird als RPC (Remote Procedure Calling) abgekürzt. Beispiele hierfür sind CORBA-Technologien und für Java RMI (Remote Method Invoking). Und bei ihnen scheint alles gut zu sein, besonders bei CORBA, denn... Man kann damit in jeder Programmiersprache arbeiten, aber es fehlte noch etwas. Ich glaube, dass der Nachteil von CORBA darin besteht, dass es über einige seiner eigenen Funktionen funktioniert Netzwerkprotokolle anstelle von einfachem HTTP, das jede Firewall durchdringt. Die Idee des Webdienstes bestand darin, einen RPC zu erstellen, der in HTTP-Pakete eingefügt wird. Damit begann die Entwicklung des Standards. Was sind die Grundkonzepte dieser Norm:- SEIFE. Bevor Sie eine Remote-Prozedur aufrufen, müssen Sie diesen Aufruf in einer XML-Datei im SOAP-Format beschreiben. SOAP ist nur eines von vielen XML-Markup, das in Webdiensten verwendet wird. Alles, was wir über HTTP irgendwohin senden möchten, wird zunächst in eine XML-SOAP-Beschreibung umgewandelt, dann in ein HTTP-Paket gestopft und über TCP/IP an einen anderen Computer im Netzwerk gesendet.
- WSDL. Es gibt einen Webservice, d.h. ein Programm, dessen Methoden remote aufgerufen werden können. Der Standard verlangt jedoch, dass diesem Programm eine Beschreibung beigefügt wird, die besagt: „Ja, Sie haben Recht – das ist wirklich ein Webdienst, und Sie können von dort aus die eine oder andere Methode aufrufen.“ Diese Beschreibung wird durch eine andere XML-Datei dargestellt, die ein anderes Format hat, nämlich WSDL. Diese. WSDL ist nur eine XML-Datei, die einen Webdienst beschreibt, mehr nicht.
Allgemeiner Ansatz
Bei Webdiensten gibt es immer einen Client und einen Server. Der Server ist unser Webdienst und wird manchmal als Endpunkt bezeichnet (z. B. als Endpunkt, an dem SOAP-Nachrichten vom Client ankommen). Wir müssen Folgendes tun:- Beschreiben Sie die Oberfläche unseres Webservices
- Implementieren Sie diese Schnittstelle
- Starten Sie unseren Webservice
- Schreiben Sie einen Client und rufen Sie die gewünschte Webdienstmethode aus der Ferne auf
Server
Lassen Sie uns IDEA starten und erstellen neues Projekt Neues Projekt erstellen. Geben wir den Namen an HelloWebService und drücken Sie die Taste Nächste, dann Taste Beenden. Im Ordner src Lass uns ein Paket erstellen ru.javarush.ws. In diesem Paket erstellen wir die HelloWebService-Schnittstelle: Paket ru. Javarush. ws; // das sind Annotationen, d.h. eine Möglichkeit, unsere Klassen und Methoden zu kennzeichnen, // im Zusammenhang mit Web-Service-Technologie Javax importieren. Zeugen Jehovas. WebMethod; Javax importieren. Zeugen Jehovas. Internetservice; Javax importieren. Zeugen Jehovas. Seife. SOAPBinding; // Wir sagen, dass unsere Schnittstelle als Webdienst funktionieren wird@Internetservice // Wir sagen, dass der Webdienst zum Aufrufen von Methoden verwendet wird@SOAPBinding (style = SOAPBinding. Style. RPC) öffentliche Schnittstelle HelloWebService ( // Wir sagen, dass diese Methode remote aufgerufen werden kann@WebMethod public String getHelloString(String name) ; ) In diesem Code sind die Klassen WebService und WebMethod sogenannte Annotationen und tun nichts anderes, als unsere Schnittstelle und ihre Methode als Webdienst zu markieren. Gleiches gilt für die SOAPBinding-Klasse. Der einzige Unterschied besteht darin, dass SOAPBinding eine Annotation mit Parametern ist. In diesem Fall wird der Parameter „style“ mit einem Wert verwendet, der angibt, dass der Webdienst nicht über Dokumentnachrichten, sondern als klassischer RPC, d. h. eine Methode aufrufen. Lassen Sie uns unsere Schnittstellenlogik implementieren und eine HelloWebServiceImpl-Klasse in unserem Paket erstellen. Ich stelle übrigens fest, dass das Beenden einer Klasse mit „Impl“ eine Konvention in Java ist, nach der die Implementierung von Schnittstellen so bezeichnet wird (Impl – vom Wort „Implementierung“, d. h. „Implementierung“). Dies ist keine Voraussetzung und es steht Ihnen frei, der Klasse einen beliebigen Namen zu geben, aber gute Manieren erfordern es: Paket ru. Javarush. ws; // die gleiche Annotation wie bei der Beschreibung der Schnittstelle, Javax importieren. Zeugen Jehovas. Internetservice; // aber hier wird es mit dem endpointInterface-Parameter verwendet, // zeigt an Vollständiger Name Schnittstellenklasse unseres Webservices@WebService(endpointInterface= „ru.javarush.ws.HelloWebService“) öffentliche Klasse HelloWebServiceImpl implementiert HelloWebService ( @Override public String getHelloString (String name) ( // erwidere einfach den Gruß return „Hallo, „ + Name + „!“ ; ) ) Starten wir unseren Webdienst als unabhängigen Server, d.h. ohne die Beteiligung von Tomcat und Anwendungsservern (dies ist ein Thema für eine separate Diskussion). Dazu in der Projektstruktur im Ordner src Erstellen wir ein Paket ru.javarush.endpoint und darin eine HelloWebServicePublisher-Klasse mit der Hauptmethode: Paket ru. Javarush. Endpunkt; // Klasse zum Ausführen eines Webservers mit Webdiensten Javax importieren. xml. ws. Endpunkt; // Klasse unseres Webservices ru importieren. Javarush. ws. HelloWebServiceImpl; öffentliche Klasse HelloWebServicePublisher ( public static void main (String... args) ( // Den Webserver auf Port 1986 starten // und an die im ersten Argument angegebene Adresse, // den im zweiten Argument übergebenen Webdienst starten Endpunkt. veröffentlichen( „http://localhost:1986/wss/hello“, new HelloWebServiceImpl () ); ) ) Lassen Sie uns nun diese Klasse durch Klicken ausführen Umschalt+F10. In der Konsole wird nichts angezeigt, aber der Server läuft. Sie können dies überprüfen, indem Sie die Zeile http://localhost:1986/wss/hello?wsdl in Ihren Browser eingeben. Die Seite, die sich öffnet, beweist einerseits, dass auf unserem Computer (localhost) ein Webserver (http://) auf Port 1986 läuft, und zeigt andererseits eine WSDL-Beschreibung unseres Webservices. Wenn Sie die Anwendung stoppen, ist die Beschreibung nicht mehr verfügbar, ebenso wie der Webdienst selbst. Daher werden wir dies nicht tun, sondern mit dem Schreiben des Clients fortfahren.Klient
Im Projektordner src Erstellen wir ein Paket ru.javarush.client und darin die Klasse HelloWebServiceClient mit der Hauptmethode: Paket ru. Javarush. Klient; // benötigt, um die WSDL-Beschreibung zu erhalten und durch diese zu gelangen // den Webdienst selbst erreichen Java importieren. Netz. URL; // Diese Ausnahme tritt auf, wenn mit einem URL-Objekt gearbeitet wird Java importieren. Netz. MalformedURLException; // Klassen zum Parsen von XML mit WSDL-Beschreibung // und das darin enthaltene Service-Tag erreichen Javax importieren. xml. Namensraum. QName; Javax importieren. xml. ws. Service; // Schnittstelle unseres Webservices (wir brauchen mehr) ru importieren. Javarush. ws. HelloWebService; öffentliche Klasse HelloWebServiceClient ( public static void main (String args) löst MalformedURLException aus ( // Einen Link zur WSDL-Beschreibung erstellen URL-URL= neue URL ( „http://localhost:1986/wss/hello?wsdl“) ; // Wir schauen uns die Parameter des nächsten Konstruktors im allerersten Tag der WSDL-Beschreibung an – Definitionen // Sehen Sie sich das erste Argument im Attribut targetNamespace an // Schauen Sie sich das 2. Argument im Namensattribut an QName qname = neuer QName ("http://ws.javarush.ru/" , "HelloWebServiceImplService" ); // Jetzt können wir das Service-Tag in der WSDL-Beschreibung erreichen, Servicedienst = Service. create (url, qname) ; // und dann bis zum darin verschachtelten Port-Tag, damit // einen Link zu einem von uns entfernten Webservice-Objekt erhalten HelloWebService hallo = Dienst. getPort(HelloWebService.class); // Hurra! Jetzt können Sie anrufen Remote-Methode System. aus. println (hello. getHelloString( "JavaRush" ) ); ) ) Ich habe den Code in der Auflistung maximal kommentiert. Ich habe nichts hinzuzufügen, also lasst uns loslegen (Umschalt+F10). Wir sollten den Text in der Konsole sehen: Hallo, JavaRush! Wenn Sie es nicht gesehen haben, haben Sie wahrscheinlich vergessen, den Webdienst zu starten.Abschluss
Dieses Thema bot einen kurzen Ausflug in Webdienste. Ich möchte noch einmal sagen, dass vieles von dem, was ich geschrieben habe, meine Vermutungen darüber sind, wie es funktioniert, und dass Sie mir daher nicht zu sehr vertrauen sollten. Ich wäre dankbar, wenn sachkundige Leute mich korrigieren würden, denn dann werde ich etwas lernen. UPD.Web Services Description Language (WSDL)
In den letzten Beispielen haben Sie möglicherweise einige WSDL-Codeausschnitte gesehen. Denken Sie daran, dass WSDL eine XML-basierte Grammatik ist, die beschreibt, wie externe Clients mit den Webmethoden interagieren können, die unter einer bestimmten URL unter jedem unterstützten Kommunikationsprotokoll verfügbar sind. In vielerlei Hinsicht kann man sich ein WSDL-Dokument als „Vertrag“ zwischen dem Webdienst-Client und dem Webdienst selbst vorstellen. Dies ist eine weitere Metasprache. Insbesondere wird WSDL verwendet, um die folgenden Merkmale aller verfügbaren Webmethoden zu beschreiben:
Name der XML-Webmethode;
Anzahl, Art und Reihenfolge der Parameter (falls vorhanden);
Rückgabetyp (falls angegeben);
HTTP GET-, HTTP POST- und SOAP-Aufrufbedingungen.
In den meisten Fällen werden WSDL-Dokumente automatisch vom entsprechenden Webserver generiert. Denken Sie daran, dass der Webserver ein WSDL-Dokument für den angegebenen XML-Webdienst generiert, wenn Sie das Suffix „?wsdl“ zu einer URL hinzufügen, die auf eine *.asmx-Datei verweist.
http://localhost/SomeWS/theWS.asmx?wsdl
Aber wenn IIS das WSDL-Dokument für einen bestimmten XML-Webdienst automatisch generiert, warum benötigen Sie dann ein tiefes Verständnis der Syntax der generierten WSDL-Daten? Die Antwort hängt normalerweise davon ab, wie Ihr Dienst von externen Anwendungen genutzt wird. Für XML-Webdienste, die für den „internen“ Gebrauch vorgesehen sind, reicht in der Regel die vom Webserver generierte WSDL aus.
In der Zwischenzeit. Es ist durchaus möglich, mit der Entwicklung eines XML-Webdienstes zu beginnen, indem Sie manuell ein WSDL-Dokument erstellen (wie oben beschrieben). Die Hauptidee, die Entwicklung durch die Erstellung eines WSDL-Dokuments zu starten, hängt mit Kompatibilitätsproblemen zusammen. Denken Sie daran, dass es vor der WSI-Spezifikation üblich war, dass verschiedene Tools zum Erstellen von Webdiensten inkompatible WSDL-Beschreibungen generierten. Wenn Sie die Entwicklung mit WSDL-Code beginnen, können Sie das Dokument nach Bedarf erstellen.
Wie Sie vielleicht erraten haben, erfordert das Starten eines XML-Webdienstes durch Erstellen eines WSDL-Dokuments sehr gute Kenntnisse der WSDL-Grammatik, die im Kontext dieses Kapitels nicht behandelt werden. Aber wir werden uns die Grundstruktur eines WSDL-Dokuments ansehen. Sobald Sie die Grundlagen verstanden haben, können Sie den Nutzen des Dienstprogramms schätzen Befehlszeile wsdl.exe.
Kommentar. Die neuesten Informationen zu WSDL finden Sie unter http://www.w3.org/tr/wsdl.
Definieren eines WSDL-Dokuments
Das eigentliche WSDL-Dokument wird durch das Wurzelelement ‹definitions› geöffnet und geschlossen. Der Eröffnungsdeskriptor definiert normalerweise verschiedene xmlns-Attribute. Sie definieren XML-Namespaces, die verschiedene Unterelemente definieren. Das Element ‹definitions› muss mindestens den Namespace angeben, in dem die WSDL-Elemente selbst definiert sind (http://schemas.xmlsoap.org/wsdl). Um nützlich zu sein, muss der öffnende ‹Definitionen›-Deskriptor auch die definierenden XML-Namespaces angeben einfache Typen WSDL-Daten, XML-Schematypen, SOAP-Elemente und Ziel-Namespace. So sieht beispielsweise der Abschnitt „Definitionen“ für unseren Rechner-Webdienst aus.
‹wsdl:definitionen xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:tm="http://microsoft.com/wsdl/mime/textMatching/"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns-mime="http://schemas.xmlsoap.org/wsdl/mime/"
xmlns:tns="http://www.IntertechTraining.com/"
xmlns:s="http://www.w3.org/2001/XMLSchema"
xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/"
xmlns:http="http://schemes.xmlsoap.org/wsdl/http/"
targetNamespace="http://www.IntertechTraining.com/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"›
‹/wsdl:Definitionen›
Im Kontext des Wurzelelements finden Sie fünf Unterelemente. Das allgemeine Erscheinungsbild des WSDL-Dokuments sollte in etwa so aussehen.
‹?xml version="1.0"kodierung="utf-8"?›
‹wsdl:definitionen…›
‹wsdl:types›
‹!-- Liste der für diesen Webdienst verfügbaren Typen --›
‹wsdl:/types›
‹wsdl:message›
‹!-- Nachrichtenformat --›
‹wsdl:/message›
‹wsdl:portType›
‹!-- Hafeninformationen --›
‹wsdl:/portType›
‹wsdl:binding›
‹!-- Verbindliche Angaben --›
‹wsdl:/binding›
‹wsdl:service›
‹!-– Informationen zum XML-Webdienst selbst --›
‹wsdl:/service›
‹wsdl:/definitions›
Wie zu erwarten ist, enthält jedes dieser Unterelemente zusätzliche Elemente und Attribute, die die Beschreibung der verfügbaren Funktionen weiter verdeutlichen. Schauen wir uns nacheinander die wichtigsten gültigen Knoten an.
Element-‹Typen›
Wir schauen uns zunächst das Element ‹types› an, das Beschreibungen aller vom Webservice angebotenen Datentypen enthält. Möglicherweise wissen Sie, dass XML selbst eine Reihe von „Kern“-Datentypen definiert, die alle im XML-Namespace http://www.w3.org/2001/XMLSchema definiert sind (der im Kontext des Stammverzeichnisses angegeben werden muss). Element ‹ Definitionen ›). Nehmen Sie zum Beispiel die Subtract()-Methode unseres Taschenrechner-Webdienstes, die über zwei ganzzahlige Eingabeparameter verfügt. In WSDL-Begriffen wird der Common Language Runtime-Typ System.Int32 im Kontext des ‹complexType›-Elements beschrieben.
‹s:element name= "Subtrahieren"›
‹s:sequenz›
‹s:element minOccurs=" 1 "maxOccurs=" 1 "name=" X"Typ=" s:int" /›
‹s:element minOccurs="" 1 "maxOccurs=" 1 "name=" j"Typ=" s:int" /›
‹/s:sequenz›
‹/s:complexType›
‹/s:element›
Die von der Subtract()-Methode zurückgegebene Ganzzahl wird auch im Element ‹types› beschrieben.
‹s:element name= " SubtractResponse"›
‹s:complexType›
‹s:sequenz›
‹s:element minOccurs=" 1 " maxOccurs=" 1 "name=" SubtractResult"Typ=" s:int"/›
‹/s:sequenz›
‹ /s:complexType›
‹/s:element›
Wenn Sie über eine Webmethode verfügen, die zurückgibt oder empfängt benutzerdefinierte Typen Daten werden sie auch im Kontext des ‹complexType›-Elements angezeigt. Wir werden uns später mit den Details befassen, wie benutzerdefinierte .NET-Datentypen mithilfe der Web-Methode verfügbar gemacht werden. Nehmen wir für dieses Beispiel an, Sie definieren eine Webmethode, die eine Struktur namens Point zurückgibt.
öffentliche Struktur Point(
öffentliche Zeichenfolge pointName;
Die WSDL-Beschreibung für diese „komplexe Struktur“ würde etwa so aussehen.
‹s:complexType name=" Punkt"›
‹s:sequenz›
‹s:element minOccurs=" 1 "maxOccurs=" 1 "name=" X"Typ=" s:int" /›
‹s:element minOccurs=" 1 "" maxOccurs=" 1 "name=" j"Typ=" s:int" /›
‹s:element minOccurs=" 0 "maxOccurs=" 1 "name=" Punktname"Typ=" s:string" /›
‹/s:sequenz›
‹/s:complexType›
‹Nachricht›-Element
Das Element ‹message› wird verwendet, um das Format für den Austausch von Anfragen und Antworten für eine bestimmte Webmethode zu definieren. Da ein einzelner Webdienst die Übertragung mehrerer Nachrichten zwischen einem Absender und einem Empfänger ermöglicht, kann ein einzelnes WSDL-Dokument mehrere Nachrichtenelemente definieren. Typischerweise verwenden diese Definitionen die im ‹types›-Element angegebenen Typen.
Unabhängig von der Anzahl der im WSDL-Dokument definierten ‹message›-Elemente sind sie normalerweise paarweise „vorhanden“. Die erste Definition repräsentiert das Eingabeformat einer Nachricht und die zweite Definition repräsentiert das Ausgabeformat derselben Nachricht. Beispielsweise definiert die Subtract()-Methode des CalculatorWebService-Webdienstes die folgenden Elemente
‹wsdl:message name=" Subtrahieren Sie SoapIn"›
‹wsdl:part name="parameters" element="tns:Subtract" /›
‹/wsdl:message›
‹wsdl: Nachrichtenname=" SubtractSoapOut"›
‹wsdl:part name="parameters" element="tns:SubtractResponse" /›
‹/wsdl:message›
Hier sehen Sie nur die SOAP-Kommunikation des entsprechenden Dienstes. Wie zu Beginn dieses Kapitels erläutert, können XML-Webdienste mithilfe von SOAP oder den HTTP-Methoden GET und POST aufgerufen werden. Wenn Sie jedoch die HTTP-POST-Kommunikation aktivieren (später erklärt), sollte die generierte WSDL die folgenden ‹Nachrichten›-Daten anzeigen.
‹wsdl: Nachrichtenname=" SubtractHttpPostIn"›
‹part name="n1" type="s:string" /›
‹part name="n2" type="s:string" /›
‹wsdl:/message›
‹wsdl:message name=" SubtractHttpPostOut"›
‹part name="Body" element="s0:int" /›
‹wsdl:/message›
‹message›-Elemente sind für sich genommen nicht sehr nützlich. Auf diese Nachrichtendefinitionen wird jedoch von anderen Teilen des WSDL-Dokuments verwiesen.
Kommentar. Nicht alle Webmethoden erfordern sowohl eine Anfrage als auch eine Antwort. Wenn die Web-Methode „unidirektional“ ist, benötigt sie nur das ‹message›-Element der Anfrage. Mithilfe des Attributs können Sie eine Webmethode als unidirektional kennzeichnen.
‹portType›-Element
Das Element „portType“ definiert die verschiedenen Verbindungen, die zwischen dem Client und dem Server auftreten können, und jede dieser Beziehungen wird durch ein verschachteltes Element „operation“ dargestellt. Es ist leicht zu erraten, dass die typischsten Vorgänge hier SOAP, HTTP GET und HTTP POST sein sollten. Es gibt jedoch noch andere Operationen. Beispielsweise ermöglicht eine unidirektionale Operation einem Client, eine Nachricht an einen bestimmten Webserver zu senden, aber keine Antwort zu erhalten (dies ähnelt dem Aufruf einer Methode, ohne einen Rückgabewert zu erwarten). Eine Anfrage-Antwort-Operation ermöglicht es dem Server, eine Anfrage zu senden, während der Client antwortet (was als Erweiterung der Anfrage-Antwort-Operation betrachtet werden kann).
Um das Format des optionalen Unterelements ‹operation› zu veranschaulichen, betrachten Sie die WSDL-Definition für die Subtract()-Methode.
‹wsdl portType name= „RechnerWebServiceSoap"›
‹wsdl:operation name=" Subtrahieren"›
‹wsdl:input message=" tns:SubtractSoapIn" /›
‹wsdl:output message=" tns:SubtractSoapOut" /›
‹ /wsdl:operation›
‹wsdl:/portType›
Beachten Sie, dass sich die Elemente „input“ und „output“ auf den entsprechenden Nachrichtennamen beziehen, der im Element „message“ definiert ist. Wenn für die Subtract()-Methode HTTP POST aktiviert wäre, würden Sie Folgendes sehen zusätzliches Element
‹wsdl:portType name="CalculatorWebServiceHttpPost"›
‹wsdl:input message=" s0:SubtractHttpPostIn" /› ‹wsdl:output message= " s0:SubtractHttpPostOut" /› ‹wsdl:/operation› ‹wsdl:/portType› Beachten Sie abschließend, dass das Element „operation“ ein verschachteltes Element „documentation“ enthält, wenn eine bestimmte Webmethode mithilfe der Eigenschaft „Description“ beschrieben wird. Das ‹verbindliche› Element Dieses Element gibt das genaue Format des GET-, POST- und SOAP-Austauschs an. Dies ist das ausführlichste aller Elemente, die im Kontext des Stammelements ‹definition› enthalten sind. Hier ist zum Beispiel eine Definition eines ‹Binding›-Elements, das beschreibt, wie ein Aufrufer mit der Webmethode MyMethod() interagieren kann. mit SOAP. ‹wsdl:binding name="СalculatorWebServiceSoap12" type=" tns:CalculatorWebServiceSoap"› ‹soap12:binding transport=" http://schemas.xmlsoap.org/soap/http" /›
‹wsdl:operation name=" Subtrahieren"› ‹soap12:operation SoapAction=" http://www.IntertechTraining.com/Subtract" style="document" /› ‹wsdl:input› ‹soap12:body use=" wörtlich" /› ‹/wsdl:input› ‹wsdl:output› ‹soap12:body use=" wörtlich" /› ‹/wsdl:output› ‹/wsdl:operation› ‹/wsdl:binding› ‹Service›-Element Schließlich haben wir das Element ‹service›, das die Eigenschaften des Webdienstes selbst angibt (z. B. seine URL). Die Hauptaufgabe dieses Elements besteht darin, die Menge der von diesem Webserver geöffneten Ports zu beschreiben. Um dies zu erreichen, kann das ‹services›-Element beliebig viele verschachtelte ‹port›-Elemente verwenden (nicht zu verwechseln mit dem ‹portType›-Element). So sieht das ‹service›-Element für CalculatorWebService aus. ‹wsdl:service name= „CalculatorWebService"› ‹wsdl:documentation xmlns:wsdl ="http://schemas.xmlsoap.org/wsdl/"› Wundervoller Webrechner-Service ‹/wsdl:documentation› ‹wsdl:Portname= „CalculatorWebServiceSoap“ Bindung= „tns:RechnerWebServiceSoap"› ‹soap:address location= „http://localhost:1109/CalculatorWebService/Service.asmx“/› ‹/wsdl:port› ‹wsdl:port name="CalculatorWebServiceSoap12" Bindung=" tns:RechnerWebServiceSoap12"› ‹soap12:address location= „http://localhost:1109/CalculatorWebService/Service.asmx“/› ‹/wsdl:port› ‹/wsdl:service› Wie Sie sehen, ist der WSDL-Code, der automatisch vom ITS-Server zurückgegeben wird, nicht besonders komplex, aber da es sich bei der WSDL um eine XML-basierte Grammatik handelt, ist der Code ziemlich ausführlich. Allerdings sollten Sie jetzt ein besseres Verständnis für die Rolle von WSDL haben, also schauen wir uns die Kommunikationsprotokolle von XML-Webdiensten etwas genauer an. Kommentar. Denken Sie daran, dass der System.Web.Services.Description-Namespace viele Typen enthält, die es Ihnen ermöglichen, rohen WSDL-Code programmgesteuert zu lesen und zu verarbeiten (sehen Sie sich das selbst an, wenn Sie interessiert sind). Webdienste sind Technologien zur Anwendungsintegration, die im Internet genutzt werden können. Als Beispiel für den möglichen Einsatz von Webdiensten betrachten wir die Reiseplanung. Typischerweise erfordert diese Situation: die Buchung von Flugtickets, Hotelreservierungen, die Anmietung eines Autos und möglicherweise die Inanspruchnahme der Dienste lokaler Unternehmen, die Ausflüge organisieren. Bei herkömmlicher Nutzung des Internets müssen Sie den Server der Fluggesellschaft, den Server des Hotels oder der Hotelkette, den Server der Autovermietung und den Server des Unternehmens, das sich auf die Organisation von Ausflügen an den Ort Ihrer Wahl spezialisiert hat, aufsuchen. Bei all diesen Maßnahmen kann es ziemlich lange dauern, bis Sie Ihr Ziel erreichen. Und gleichzeitig wird keines der von Ihnen beauftragten Unternehmen Ihre Pläne kennen und daher nicht in der Lage sein, Ihre Zeit zu optimieren. Das Problem besteht darin, dass Unternehmen, die sich auf bestimmte Bereiche spezialisiert haben – Fluggesellschaften, Hotels, Autovermietungen usw. – in den meisten Fällen für sich selbst verschlossen sind und ihre eigenen Mittel zur Speicherung und Darstellung von Daten verwenden. Bequemer wäre es, eine Anwendung zu starten, die die notwendigen Informationen von Ihnen erhält und alle Routineaktionen – Ticketbuchung, Hotelbuchung usw. – automatisch und ohne Ihr Zutun ausführt. Um dies zu ermöglichen, müssen Sie Webdienste nutzen. Schauen wir uns an, was sich in diesem Fall ändern wird. Nehmen wir an, eine Fluggesellschaft stellt einen Webdienst bereit, der es Anwendungen ermöglicht, eine Liste von Flügen zwischen zwei Städten für ein bestimmtes Datum abzurufen. In diesem Fall müssen Sie nicht mehr auf die Website der Fluggesellschaft gehen und verschiedene Suchkriterien eingeben – alle notwendigen Informationen stehen in einem einzigen XML-Dokument zur Verfügung. Nehmen wir nun an, dass eine Fluggesellschaft, ein Hotel und eine Autovermietung Webdienste bereitstellen, mit denen Sie programmgesteuert Tickets kaufen, Zimmer buchen und Autos mieten können. In diesem Fall können Sie Aufrufe aller dieser Dienste in einer einzigen Anwendung kombinieren, die alle Routinearbeiten ohne Benutzereingriff ausführen kann. Damit ist die Funktionalität der neuen Klasse von Webanwendungen jedoch noch nicht erschöpft. Unsere Anwendung kann beispielsweise regelmäßig Kontakt zum Webservice der Fluggesellschaft aufnehmen, um den Status des Fluges zu ermitteln und im Falle einer Verspätung Hoteldienste, Mietdienste usw. zu benachrichtigen. um Ihre Reservierung zu verlängern. Neben der offensichtlichen Verbesserung des Kundenerlebnisses bietet die Nutzung von Webdiensten viele weitere Vorteile. Wenn beispielsweise eine Autovermietung weiß, dass Ihr Flug verspätet ist, kann sie mit ihren Autos flexibler sein. Mit zunehmender Anzahl von Webdiensten werden wir komplexere Beispiele für deren Verwendung sehen. Es ist jedoch zu beachten, dass die Einführung des Konzepts der Webdienste nicht nur eine Überarbeitung vieler Geschäftsregeln und Interaktionsmuster zwischen Branchen und Sektoren einer bestimmten Branche erfordert, sondern auch eine erhöhte Sicherheit des Datenaustauschs. Nachdem wir die praktische Anwendung von Webdiensten betrachtet haben, wenden wir uns den Standards zu, die diesen Diensten zugrunde liegen. Standards Wie wir bereits wissen, basieren Webdienste auf Internetstandards. Diese Standards definieren Protokolle und nicht, wie sie implementiert werden. Diese Aussage ist der Schlüssel zum Erfolg des Internets – kein Unternehmen kann Internetstandards beeinflussen und eigene Spielregeln festlegen. Web-Service-Standards werden beispielsweise gemeinsam von Unternehmen wie IBM, Microsoft, Ariba und mehreren anderen entwickelt und im Komitee des World Wide Web Consortium (W3C) diskutiert. Webdienste basieren auf drei Hauptwebstandards: SOAP (Simple Object Access Protocol) – ein Protokoll zum Senden von Nachrichten über HTTP und andere Internetprotokolle; WSDL (Web Services Description Language) – eine Sprache zur Beschreibung von Softwareschnittstellen von Webdiensten; UDDI (Universal Description, Discovery and Integration) ist ein Standard zur Indizierung von Webdiensten. Anwendungsserver speichern Webdienste und stellen sie über die Protokolle HTTP GET, HTTP POST und HTTP SOAP zur Verfügung. Bestehende Webdienste werden in WSDL-Dokumenten beschrieben, die entweder auf dem Anwendungsserver oder in speziellen XML-Speichern liegen. Ein WSDL-Dokument kann auf andere WSDL-Dokumente und XSD-Dokumente (XML-Schema) verweisen, die die von Webdiensten verwendeten Datentypen beschreiben. XML-Speicher werden zur Verwaltung von WSDL-Dokumenten verwendet. Im WSDL-Dokument befindet sich die Adresse (URL) des Webdienstes. Webdienste werden in einem Unternehmensregister beschrieben und indiziert, das Adressen (URLs) von WSDL-Dokumenten enthält. In den folgenden Abschnitten werden wir uns die drei wichtigsten Webstandards, auf denen Webdienste basieren – SOAP, WSDL und UDDI – genauer ansehen. SOAP – Simple Object Access Protocol SOAP ist ein Standard zum Senden und Empfangen von Nachrichten über das Internet. Dieses Protokoll wurde ursprünglich von Microsoft als Mittel für Remote-Prozeduraufrufe (RPC, Remote Procedure Call) über HTTP vorgeschlagen, und die SOAP 1.0-Spezifikation (Userland, Microsoft, Developmentor) war eng mit dem Component Object Model verwandt. IBM und eine Reihe anderer Unternehmen, darunter Lotus, leisteten einige Beiträge zur Entwicklung dieses Protokolls und seine Spezifikation wurde zur Prüfung an das W3C-Komitee geschickt. Die SOAP-Spezifikation definiert einen XML-„Umschlag“ für die Nachrichtenübertragung, eine Methode zum Kodieren programmatischer Datenstrukturen im XML-Format und ein Mittel zur Kommunikation über das HTTP-Protokoll. SOAP-Nachrichten gibt es in zwei Arten: Anfrage und Antwort. Die Anfrage ruft eine Methode eines Remote-Objekts auf, die Antwort gibt das Ergebnis der Ausführung dieser Methode zurück. Hier ist ein Beispiel für eine Anfrage im SOAP-Format: Und hier ist die Antwort: Die SOAP-Spezifikation definiert ein Codierungsformat, das wiederum definiert, wie Daten im XML-Format dargestellt werden. WSDL – Beschreibungssprache für Webdienste Damit Anwendungen Webdienste nutzen können, müssen deren Programmierschnittstellen detailliert beschrieben werden – aus dieser Sicht spielt WSDL die gleiche Rolle wie Interface Definition Language (IDL) im verteilten Computing. Die Beschreibung kann Informationen wie Protokoll, Serveradresse, verwendete Portnummer, Liste der verfügbaren Vorgänge, Anforderungs- und Antwortformat usw. enthalten. Zur Beschreibung dieser Informationen wurden mehrere Sprachen vorgeschlagen. Eine davon war die Service Description Language (SDL), die von Microsoft entwickelt und in der ersten Version des Microsoft SOAP Toolkits enthalten war. IBM hat die Spezifikation überarbeitet und unter Verwendung der NASSL-Spezifikation (Network Accessible Service Specification Language) das NASSL Toolkit als Teil von SOAP4J veröffentlicht. Die in NASSL umgesetzten Ideen beeinflussten die von Microsoft vorgeschlagene SOAP Contract Language (SCL)-Spezifikation. Derzeit werden beide Spezifikationen (NASSL und SDL/SCL) sowie Vorschläge anderer Unternehmen in der WSDL-Sprachspezifikation berücksichtigt. Zur Beschreibung der Geschäftslogik arbeiten IBM und Microsoft an der Spezifikation Web Services Flow Language (WSFL). Hier ist ein Beispiel für ein Dienstbeschreibungsgerüst in WSDL: Wie wir sehen können, handelt es sich bei der Beschreibung von Diensten um ein XML-Dokument, das aus mehreren Elementen besteht, darunter eine Beschreibung des Namespace, Beschreibungen von Typen und Elementen, Nachrichten, Ports sowie mögliche Operationen – Anfragen und Antworten. UDDI – Universelle Beschreibung, Entdeckung und Integration Der Zweck von UDDI besteht darin, einen Mechanismus zum Erkennen von Webdiensten bereitzustellen. UDDI definiert ein Unternehmensregister, in dem Webdienstanbieter Dienste registrieren können und Entwickler nach den von ihnen benötigten Diensten suchen können. IBM, Microsoft und Ariba haben ihre eigenen UDDI-Register erstellt (die bald in einer Web-Registrierung zusammengeführt werden), in denen Entwickler ihre Webdienste registrieren können, woraufhin die Daten automatisch in andere Register repliziert werden. UDDI basiert auf vier Arten von Elementen: Geschäftsentität, Geschäftsdienst, Bindungsvorlage und Technologiemodell. Das Element „Business Entity“ beschreibt die Branche, die diesen Webdienst bereitstellt. Dieses Element kann Kategoriebeschreibungen für eine bestimmte Branche enthalten und so eine detailliertere Suche nach Dienstleistungen erleichtern. Business Service ist eine Klasse von Dienstleistungen innerhalb einer bestimmten Branche oder Dienstleistung. Jede Branche gehört zu einer bestimmten Geschäftseinheit. Zusammen definieren die Bindungsvorlage und das Technologiemodell einen Webdienst. Das Technologiemodell enthält eine abstrakte Beschreibung und die Bindungsvorlage enthält eine konkrete Spezifikation des Dienstes. Jedes Bindungsvorlagenelement gehört zu einem bestimmten Business Service-Element, aber mehrere Bindungsvorlagenelemente können auf ein einzelnes Technologiemodellelement verweisen. Das UDDI-Unternehmensregister ist selbst ein SOAP-Webdienst. Es unterstützt die Vorgänge des Erstellens, Änderns, Löschens und Suchens nach Elementen aller vier oben besprochenen Typen. Abstract des ICSI-Studenten, wissenschaftlicher Betreuer – Sergey Kunegin In diesem Artikel werde ich darüber sprechen, was eine WSDL-Datei ist, warum sie benötigt wird und wie man damit arbeitet. Artikelkarte Was ist WSDL? WSDL ist eine Webservice-Beschreibungssprache mit XML-Struktur. Der Hauptzweck einer WSDL-Datei besteht darin, als Schnittstelle für den Zugriff auf Dienstfunktionen und Rückgabedatentypen zu dienen. Pfad zum Server, der Anfragen verarbeitet usw. Der Pfad zur WSDL-Datei sieht normalerweise wie folgt aus: http://host/services/wsdl/gbdar-v2-2.wsdl Es gibt viele Tools und Bibliotheken, die zum Lesen einer WSDL-Datei entwickelt wurden. SoapUi
Ein solches Tool ist SoapUi(). Sobald Sie die für Ihre Plattform konzipierte Distribution installiert haben, können Sie mit dem Befehl „Datei/Neues SoapUi-Projekt“ ein neues Projekt erstellen. Lassen Sie im Dialog zum Anlegen eines neuen Projekts die Checkbox Musteranfragen erstellen aktiviert Abfragen ausführen Im neuen Projekt werden automatisch Anforderungsvorlagen für den Dienst erstellt, deren Beschreibung in der WSDL-Datei enthalten ist. Links im Baum sehen Sie eine Liste der in der WSDL-Datei enthaltenen Funktionen. Ich werde die Replikationsfunktion offenlegen. Darin befindet sich eine Anfrage Request1. Wenn Sie darauf doppelklicken, wird ein Dialog mit einer Anfragevorlage angezeigt. Anstelle der Standardparameter werden Fragezeichen angezeigt. Damit die Funktion ordnungsgemäß ausgeführt wird, müssen Sie alle Parameter eingeben, die nicht mit dem Tag „Optional“ gekennzeichnet sind, und dann auf das grüne Dreieck in der oberen linken Ecke des Dialogfelds klicken. Wenn alle Parameter korrekt angegeben sind, erscheint rechts die Antwort des Dienstes auf die Anfrage. SoapUi bietet die Möglichkeit, die Parameter einer WSDL-Datei anzuzeigen; dazu müssen Sie auf den Schnittstellennamen doppelklicken (markiert mit einem grünen Symbol im WSDL-Dateibaum, für mich - gdbar-v2-2SOAP). Im Dialog finden Sie: Dokumentationserstellung
Mit SoapUi können wir eine WSDL-Funktionsdokumentation erstellen. Klicken Sie dazu mit der rechten Maustaste auf die Schnittstelle und rufen Sie den Befehl auf Dokumentation erstellen. Als Ergebnis erhalten wir eine ausführliche Anleitung im HTML-Format. Das ist alles, abonnieren Sie neue Beiträge, hinterlassen Sie Kommentare und machen Sie Vorschläge zur Verbesserung des Artikels. Der Thementitel ist wirklich eine Frage, denn... Ich selbst weiß nicht, was es ist und werde im Rahmen dieses Artikels zum ersten Mal versuchen, damit zu arbeiten. Das Einzige, was ich garantieren kann, ist, dass der unten dargestellte Code funktioniert, aber meine Formulierungen werden nur Annahmen und Vermutungen darüber sein, wie ich selbst das alles verstehe. So lass uns gehen...
xmlns:SOAP-ENV="http:///envelope"
SOAP-ENV:encodingStyle="http:///encoding//"
xmlns="http://(soaporg)/wsdl/">
...
Einführung
Wir müssen damit beginnen, warum das Konzept der Webdienste geschaffen wurde. Als dieses Konzept auf der Welt erschien, gab es bereits Technologien, die es Anwendungen ermöglichten, aus der Ferne zu interagieren, wobei ein Programm eine Methode in einem anderen Programm aufrufen konnte, die auf einem Computer in einer anderen Stadt oder sogar einem anderen Land gestartet werden konnte. All dies wird als RPC (Remote Procedure Calling) abgekürzt. Beispiele hierfür sind CORBA-Technologien und für Java RMI (Remote Method Invoking). Und bei ihnen scheint alles gut zu sein, besonders bei CORBA, denn... Man kann damit in jeder Programmiersprache arbeiten, aber es fehlte noch etwas. Ich glaube, dass der Nachteil von CORBA darin besteht, dass es über einige seiner eigenen Netzwerkprotokolle funktioniert und nicht über einfaches HTTP, das durch jede Firewall passt. Die Idee des Webdienstes bestand darin, einen RPC zu erstellen, der in HTTP-Pakete eingefügt wird. Damit begann die Entwicklung des Standards. Was sind die Grundkonzepte dieser Norm:
Warum fragst du so kurz? Können Sie nicht genauer sein? Es ist wahrscheinlich möglich, aber dazu müssen Sie auf Bücher wie „Java Web Services“ von T. Mashnin zurückgreifen. Dort finden Sie auf den ersten 200 Seiten eine detaillierte Beschreibung jedes Tags der SOAP- und WSDL-Standards. Lohnt es sich? Meiner Meinung nach nein, denn... All dies wird in Java automatisch erstellt, und Sie müssen nur die Inhalte der Methoden schreiben, die remote aufgerufen werden sollen. Daher erschien in Java eine API wie JAX-RPC. Wenn jemand es nicht weiß: Wenn er sagt, dass Java diese und jene API hat, bedeutet das, dass es ein Paket mit einer Reihe von Klassen gibt, die die betreffende Technologie kapseln. JAX-RPC entwickelte sich im Laufe der Zeit von Version zu Version weiter und wurde schließlich zu JAX-WS. WS steht offensichtlich für WebService und man könnte denken, dass dies einfach eine Umbenennung von RPC ist, einem heutzutage beliebten Schlagwort. Das stimmt nicht, denn Jetzt haben sich Webdienste von der ursprünglichen Idee entfernt und ermöglichen nicht nur den Aufruf von Remote-Methoden, sondern auch das einfache Senden von Dokumentnachrichten im SOAP-Format. Ich weiß noch nicht, warum das nötig ist; es ist unwahrscheinlich, dass die Antwort hier „nur für den Fall, dass es nötig ist“ lautet. Ich selbst würde gerne von erfahreneren Kameraden lernen. Und schließlich erschien JAX-RS für sogenannte RESTful-Webdienste, aber das ist Thema eines separaten Artikels. Die Einleitung kann hier enden, denn... Als nächstes lernen wir, mit JAX-WS zu arbeiten. Allgemeiner Ansatz
Bei Webdiensten gibt es immer einen Client und einen Server. Der Server ist unser Webdienst und wird manchmal als Endpunkt bezeichnet (z. B. als Endpunkt, an dem SOAP-Nachrichten vom Client ankommen). Wir müssen Folgendes tun:
Sie können einen Webdienst auf unterschiedliche Weise starten: Beschreiben Sie entweder eine Klasse mit der Hauptmethode und starten Sie den Webdienst direkt als Server oder stellen Sie ihn auf einem Server wie Tomcat oder einem anderen bereit. Im zweiten Fall starten wir selbst keinen neuen Server und öffnen keinen weiteren Port auf dem Computer, sondern teilen dem Tomcat-Servlet-Container einfach mit, dass „wir hier Webdienstklassen geschrieben haben. Bitte veröffentlichen Sie sie, damit jeder, der Sie kontaktiert, dies tun kann.“ Nutzen Sie unseren Webservice. Unabhängig von der Methode zum Starten des Webdienstes haben wir denselben Client. Server
Lassen Sie uns IDEA starten und ein neues Projekt erstellen Neues Projekt erstellen. Geben wir den Namen an HelloWebService und drücken Sie die Taste Nächste, dann Taste Beenden. Im Ordner src Lass uns ein Paket erstellen ru.javarush.ws. In diesem Paket erstellen wir die HelloWebService-Schnittstelle: Paket ru. Javarush. ws; // das sind Annotationen, d.h. eine Möglichkeit, unsere Klassen und Methoden zu kennzeichnen,
// im Zusammenhang mit Web-Service-Technologie Javax importieren. Zeugen Jehovas. WebMethod; Javax importieren. Zeugen Jehovas. Internetservice; Javax importieren. Zeugen Jehovas. Seife. SOAPBinding; // Wir sagen, dass unsere Schnittstelle als Webdienst funktionieren wird@Internetservice // Wir sagen, dass der Webdienst zum Aufrufen von Methoden verwendet wird@SOAPBinding (style = SOAPBinding. Style. RPC) öffentliche Schnittstelle HelloWebService ( // Wir sagen, dass diese Methode remote aufgerufen werden kann@WebMethod public String getHelloString(String name) ; ) In diesem Code sind die Klassen WebService und WebMethod sogenannte Annotationen und tun nichts anderes, als unsere Schnittstelle und ihre Methode als Webdienst zu markieren. Gleiches gilt für die SOAPBinding-Klasse. Der einzige Unterschied besteht darin, dass SOAPBinding eine Annotation mit Parametern ist. In diesem Fall wird der Parameter „style“ mit einem Wert verwendet, der angibt, dass der Webdienst nicht über Dokumentnachrichten, sondern als klassischer RPC, d. h. eine Methode aufrufen. Lassen Sie uns unsere Schnittstellenlogik implementieren und eine HelloWebServiceImpl-Klasse in unserem Paket erstellen. Ich stelle übrigens fest, dass das Beenden einer Klasse mit „Impl“ eine Konvention in Java ist, nach der die Implementierung von Schnittstellen so bezeichnet wird (Impl – vom Wort „Implementierung“, d. h. „Implementierung“). Dies ist keine Voraussetzung und es steht Ihnen frei, der Klasse einen beliebigen Namen zu geben, aber gute Manieren erfordern es: Paket ru. Javarush. ws; // die gleiche Annotation wie bei der Beschreibung der Schnittstelle, Javax importieren. Zeugen Jehovas. Internetservice; // aber hier wird es mit dem endpointInterface-Parameter verwendet,
// gibt den vollständigen Namen der Schnittstellenklasse unseres Webdienstes an@WebService(endpointInterface= „ru.javarush.ws.HelloWebService“) öffentliche Klasse HelloWebServiceImpl implementiert HelloWebService ( @Override public String getHelloString (String name) ( // erwidere einfach den Gruß return „Hallo, „ + Name + „!“ ; ) ) Starten wir unseren Webdienst als unabhängigen Server, d.h. ohne die Beteiligung von Tomcat und Anwendungsservern (dies ist ein Thema für eine separate Diskussion). Dazu in der Projektstruktur im Ordner src Erstellen wir ein Paket ru.javarush.endpoint und darin eine HelloWebServicePublisher-Klasse mit der Hauptmethode: Paket ru. Javarush. Endpunkt; // Klasse zum Ausführen eines Webservers mit Webdiensten Javax importieren. xml. ws. Endpunkt; // Klasse unseres Webservices ru importieren. Javarush. ws. HelloWebServiceImpl; öffentliche Klasse HelloWebServicePublisher ( public static void main (String... args) ( // Den Webserver auf Port 1986 starten
// und an die im ersten Argument angegebene Adresse,
// den im zweiten Argument übergebenen Webdienst starten Endpunkt. veröffentlichen( „http://localhost:1986/wss/hello“, new HelloWebServiceImpl () ); ) ) Lassen Sie uns nun diese Klasse durch Klicken ausführen Umschalt+F10. In der Konsole wird nichts angezeigt, aber der Server läuft. Sie können dies überprüfen, indem Sie die Zeile http://localhost:1986/wss/hello?wsdl in Ihren Browser eingeben. Die Seite, die sich öffnet, beweist einerseits, dass auf unserem Computer (localhost) ein Webserver (http://) auf Port 1986 läuft, und zeigt andererseits eine WSDL-Beschreibung unseres Webservices. Wenn Sie die Anwendung stoppen, ist die Beschreibung nicht mehr verfügbar, ebenso wie der Webdienst selbst. Daher werden wir dies nicht tun, sondern mit dem Schreiben des Clients fortfahren. Klient
Im Projektordner src Erstellen wir ein Paket ru.javarush.client und darin die Klasse HelloWebServiceClient mit der Hauptmethode: Paket ru. Javarush. Klient; // benötigt, um die WSDL-Beschreibung zu erhalten und durch diese zu gelangen
// den Webdienst selbst erreichen Java importieren. Netz. URL; // Diese Ausnahme tritt auf, wenn mit einem URL-Objekt gearbeitet wird Java importieren. Netz. MalformedURLException; // Klassen zum Parsen von XML mit WSDL-Beschreibung
// und das darin enthaltene Service-Tag erreichen Javax importieren. xml. Namensraum. QName; Javax importieren. xml. ws. Service; // Schnittstelle unseres Webservices (wir brauchen mehr) ru importieren. Javarush. ws. HelloWebService; öffentliche Klasse HelloWebServiceClient ( public static void main (String args) löst MalformedURLException aus ( // Einen Link zur WSDL-Beschreibung erstellen URL-URL = neue URL ( „http://localhost:1986/wss/hello?wsdl“)
;
// Wir schauen uns die Parameter des nächsten Konstruktors im allerersten Tag der WSDL-Beschreibung an – Definitionen
// Sehen Sie sich das erste Argument im Attribut targetNamespace an
// Schauen Sie sich das 2. Argument im Namensattribut an QName qname = neuer QName ("http://ws.site/" , "HelloWebServiceImplService" ); // Jetzt können wir das Service-Tag in der WSDL-Beschreibung erreichen, Servicedienst = Service. create (url, qname) ; // und dann bis zum darin verschachtelten Port-Tag, damit
// einen Link zu einem von uns entfernten Webservice-Objekt erhalten HelloWebService hallo = Dienst. getPort(HelloWebService.class); // Hurra! Sie können nun die Remote-Methode aufrufen System. aus. println (hello. getHelloString( "JavaRush" ) ); ) ) Ich habe den Code in der Auflistung maximal kommentiert. Ich habe nichts hinzuzufügen, also lasst uns loslegen (Umschalt+F10). Wir sollten den Text in der Konsole sehen: Hallo, JavaRush! Wenn Sie es nicht gesehen haben, haben Sie wahrscheinlich vergessen, den Webdienst zu starten. Abschluss
Dieses Thema bot einen kurzen Ausflug in Webdienste. Ich möchte noch einmal sagen, dass vieles von dem, was ich geschrieben habe, meine Vermutungen darüber sind, wie es funktioniert, und dass Sie mir daher nicht zu sehr vertrauen sollten. Ich wäre dankbar, wenn sachkundige Leute mich korrigieren würden, denn dann werde ich etwas lernen. UPD.