In dit artikel zal ik vertellen wat een WSDL-bestand is, waarom het nodig is en hoe je ermee kunt werken.
Artikel kaart
Wat is WSDL
WSDL is een beschrijvingstaal voor webservices met een XML-structuur. Het belangrijkste doel van een WSDL-bestand is als een interface voor toegang tot servicefuncties en retourgegevenstypen; pad naar de server die verzoeken verwerkt, enz.
Het pad naar het wsdl-bestand ziet er meestal als volgt uit: http://host/services/wsdl/gbdar-v2-2.wsdl
Er zijn veel tools en bibliotheken die zijn ontworpen om een WSDL-bestand te lezen.
ZeepUi
Eén zo'n tool is soapUi(). Door een distributie te installeren die voor uw platform is ontworpen, kunt u nieuw project door het File/New SoapUi-projectteam. Laat in het dialoogvenster voor het aanmaken van een nieuw project het selectievakje Voorbeeldaanvragen aanmaken ingeschakeld
Query's uitvoeren
In het nieuwe project worden automatisch aanvraagsjablonen voor de dienst aangemaakt, waarvan de beschrijving in het wsdl-bestand staat. Aan de linkerkant van de boom ziet u een lijst met functies in het WSDL-bestand. Ik zal de replicatiefunctie blootleggen. Daarin bevindt zich een verzoek Request1, door te dubbelklikken waarop we een dialoogvenster met een verzoeksjabloon zullen zien, in plaats van de standaardparameters zullen er vraagtekens zijn. Om de functie correct uit te voeren, moet u alle parameters invullen die niet zijn gemarkeerd met de optionele tag en vervolgens op de groene driehoek in de linkerbovenhoek van het dialoogvenster klikken.
Als alle parameters correct zijn opgegeven, verschijnt het antwoord van de service op het verzoek aan de rechterkant.
SoapUi biedt de mogelijkheid om de parameters van een WSDL-bestand te bekijken; hiervoor moet u dubbelklikken op de interfacenaam (gemarkeerd met een groen pictogram in de WSDL-bestandsboom, voor mij - gdbar-v2-2SOAP). In het dialoogvenster vindt u:
- Tabblad Overzicht - beschrijving algemene parameters WSDL, een lijst met functies en bijbehorende serveracties
- Tabblad Service-eindpunten — pad naar de server en andere parameters
- WSDL-inhoud - bestandsnavigatieboom
- WS-I-naleving — hier kunt u een WS-I-rapport op de interface maken
Documentatie genereren
Met SoapUi kunnen we WSDL-functiedocumentatie genereren. Om dit te doen, klikt u op klik met de rechtermuisknop via de interface en roep het commando op Documentatie genereren. Als resultaat ontvangen wij een gedetailleerde handleiding in html-formaat.
Dat is alles, abonneer u op nieuwe berichten, laat opmerkingen achter, doe suggesties om het artikel te verbeteren.
Elke webservice biedt een WSDL-document (Web Service Description Language) waarin alles wordt beschreven wat de klant nodig heeft om met deze service te kunnen werken. Een WSDL-document biedt een ontwikkelaar een eenvoudige en consistente manier om de syntaxis te specificeren voor het aanroepen van een webmethode. Bovendien staat dit document het gebruik toe van automatische tools voor het genereren van proxyklassen, vergelijkbaar met die in de raamwerken Visuele studio.NET en .NET Framework. Dankzij deze tools is het gebruik van een webservice net zo eenvoudig als het gebruik van een lokale klasse.
Het WSDL-document is gebaseerd op XML-formaat, volgens welke informatie in vijf groepen is verdeeld. De eerste drie groepen zijn abstracte definities die onafhankelijk zijn van platform-, netwerk- of taalspecificaties, terwijl de overige twee groepen concrete beschrijvingen bevatten.
zeep protocol
De communicatie tussen webservices en hun klanten vindt plaats via berichten in XML-formaat.
SOAP (Simple Object Access Protocol) is een berichtenprotocol voor het selecteren van webservices.
Het hoofdidee van de SOAP-standaard is dat berichten gecodeerd moeten worden in een gestandaardiseerd XML-formaat.
Naast SOAP-berichten kunt u de GET- en POST-protocol HTTP.
Voordelen van het gebruik van het SOAP-formaat ten opzichte van andere formaten voor gegevensoverdracht:
Het coderen van datastructuren en datasets in XML met behulp van SOAP is net zo eenvoudig als het coderen van eenvoudige scalaire gegevenstypen.
Wanneer u SOAP-berichten gebruikt, extra gereedschap, waardoor u bijvoorbeeld eenvoudig beveiligings- of traceringsfuncties kunt toevoegen.
Er zijn SOAP-toolkits voor verschillende programmeertalen (en zelfs eerdere). Microsoft-versies C++ en Visual Basic). Anders, om communicatie met de dienst mogelijk te maken via GET-methoden en HTTP POST, moet u uiteraard zelf de querystring samenstellen en vervolgens het antwoord parseren.
Disco-standaard
De DISCO-standaard biedt de eenvoudigste manier om toegang te krijgen tot manifestbestanden, waardoor u verwijzingen naar webservices kunt groeperen.
DISCO-bestand kan bestanden van verschillende webservers bevatten en ondersteunt "dynamisch zoeken" - automatisch zoeken map met webservicebestanden op de server.
Manifestbestanden zijn nuttig omdat ze meerdere webservices combineren in één lijst, maar klanten niet toestaan om naar een specifiek type webservice te zoeken zonder de naam op te geven van het bedrijf dat deze heeft ontwikkeld.
uddi-specificatie
De UDDI-specificatie (Universal Description, Discovery, and Integration) vermijdt deze problemen door gebruik te maken van een speciale opslagplaats (repository) waar bedrijven en organisaties gegevens kunnen plaatsen over de diensten die zij leveren. Meer dan 100 bedrijven hebben pionierswerk verricht bij het creëren van UDDI-technologie (een volledige lijst is te vinden op http://www.uddi.org/community.html), waaronder Sun en Microsoft. Samen ontwikkelden deze bedrijven een concept-UDDI-specificatie, die na 18 maanden werd gestandaardiseerd.
De informatie in deze repository moet handmatig worden bijgewerkt. Daartoe onderhouden sommige "knooppuntoperatoren" identieke kopieën van de UDDI-repository. Deze bedrijven bieden opslag van de opgegeven repository en gratis toegang daartoe om webservices populair te maken. Bovendien heeft Microsoft een versie van UDDI in de software opgenomen Windows-server.NET voor gebruik op bedrijfsintranetten.
De UDDI-winkel bevat informatie over de bedrijven die webservices leveren, het type van elke service en relaties met informatie en specificaties met betrekking tot die services. De UDDI-interface zelf is een webservice. Om u te registreren of een dienst te zoeken, moet u een SOAP-bericht verzenden.
De belangrijkste nadelen van webservices zijn lagere prestaties en grotere omvang netwerk verkeer vergeleken met technologieën zoals RMI, CORBA, DCOM vanwege het gebruik van XML-tekstberichten.
De topictitel is eigenlijk een vraag, want... Ik weet zelf niet wat het is en voor het eerst zal ik proberen ermee te werken in het kader van dit artikel. Het enige dat ik kan garanderen is dat de onderstaande code zal werken, maar mijn zinnen zullen slechts aannames en gissingen zijn over hoe ik dit zelf allemaal begrijp. Dus laten we gaan...
Invoering
We moeten beginnen met de reden waarom het concept van webservices is ontstaan. Tegen de tijd dat dit concept in de wereld verscheen, bestonden er al technologieën die het mogelijk maakten dat applicaties op afstand konden communiceren, waarbij het ene programma een methode in een ander programma kon aanroepen, dat kon worden gelanceerd op een computer in een andere stad of zelfs een ander land. Dit alles wordt afgekort als RPC (Remote Procedure Calling). Voorbeelden zijn onder meer CORBA-technologieën en voor Java - RMI (Remote Method Invoking). En alles lijkt goed te zijn in hen, vooral in CORBA, omdat... Je kunt er in elke programmeertaal mee werken, maar er ontbrak nog iets. Ik denk dat het nadeel van CORBA is dat het via een aantal van zijn eigen middelen werkt netwerkprotocollen in plaats van eenvoudige HTTP, die door elke firewall past. Het idee van de webservice was om een RPC te maken die in HTTP-pakketten zou worden ingevoegd. Zo begon de ontwikkeling van de standaard. Wat zijn de basisconcepten van deze standaard:- ZEEP. Voordat u een externe procedure oproept, moet u deze oproep beschrijven XML-bestand e SOAP-formaat. SOAP is slechts een van de vele XML-opmaak, dat wordt gebruikt in webservices. Alles wat we ergens via HTTP naartoe willen sturen, wordt eerst omgezet XML-beschrijving SOAP, vervolgens in een HTTP-pakket gestopt en via TCP/IP naar een andere computer op het netwerk verzonden.
- WSDL. Er is een webservice, d.w.z. een programma waarvan de methoden op afstand kunnen worden aangeroepen. Maar de standaard vereist dat dit programma vergezeld gaat van een beschrijving die zegt: "Ja, je hebt gelijk - dit is echt een webservice en je kunt er bepaalde methoden uit oproepen." Deze beschrijving wordt weergegeven door een ander XML-bestand, dat een ander formaat heeft, namelijk WSDL. Die. WSDL is slechts een XML-bestand dat een webservice beschrijft en niets meer.
Algemene benadering
Bij webservices is er altijd een client en een server. De server is onze webservice en wordt soms het eindpunt genoemd (zoals in het eindpunt waar SOAP-berichten van de client aankomen). We moeten het volgende doen:- Beschrijf de interface van onze webservice
- Implementeer deze interface
- Lanceer onze webservice
- Schrijf een klant en bel op afstand gewenste methode webservice
Server
Laten we IDEA lanceren en een nieuw project maken Nieuw project maken. Laten we de naam aangeven HalloWebService en druk op de knop Volgende en vervolgens op de knop Finish. In map src laten we een pakket maken ru.javarush.ws. In dit pakket maken we de HelloWebService-interface: package ru. Javarush. ws; // dit zijn annotaties, d.w.z. een manier om onze klassen en methoden te markeren, // met betrekking tot webservicetechnologie Javax importeren. jws. WebMethode; Javax importeren. jws. WebService; Javax importeren. jws. zeep. ZEEPbinden; // we zeggen dat onze interface zal werken als een webservice@WebService // we zeggen dat de webservice zal worden gebruikt om methoden aan te roepen@SOAPBinding (stijl = SOAPBinding. Stijl. RPC) openbare interface HelloWebService ( // we zeggen dat deze methode op afstand kan worden aangeroepen@WebMethod public String getHelloString(Stringnaam) ; ) In deze code zijn de klassen WebService en WebMethod zogenaamde annotaties en doen ze niets anders dan onze interface en de bijbehorende methode markeren als een webservice. Hetzelfde geldt voor de klasse SOAPBinding. Het enige verschil is dat SOAPBinding een annotatie met parameters is. IN in dit geval de stijlparameter wordt gebruikt met een waarde die aangeeft dat de webservice niet via documentberichten werkt, maar als een klassieke RPC, d.w.z. om de methode aan te roepen. Laten we onze interfacelogica implementeren en een HelloWebServiceImpl-klasse in ons pakket maken. Overigens merk ik op dat het beëindigen van een klasse met Impl een conventie is in Java, volgens welke de implementatie van interfaces zo wordt aangeduid (Impl - van het woord implementatie, d.w.z. implementatie). Dit is geen vereiste en je bent vrij om de klasse een naam te geven die je wilt, maar goede manieren vereisen het: pakket ru. Javarush. ws; // dezelfde annotatie als bij het beschrijven van de interface, Javax importeren. jws. WebService; // maar hier wordt het gebruikt met de parameter endpointInterface, // wijzend op voor-en achternaam interfaceklasse van onze webservice@WebService(endpointInterface= "ru.javarush.ws.HelloWebService") public class HelloWebServiceImpl implementeert HelloWebService ( @Override public String getHelloString (String-naam) ( // beantwoord gewoon de begroeting return "Hallo, " + naam + "!" ; ) ) Laten we onze webservice lanceren als zelfstandige server, d.w.z. zonder de deelname van Tomcat en applicatieservers (dit is een onderwerp voor een aparte discussie). Om dit te doen, in de projectstructuur in de map src Laten we een pakket ru.javarush.endpoint maken, en daarin zullen we een HelloWebServicePublisher-klasse maken met de hoofdmethode: pakket ru. Javarush. eindpunt; // klasse voor het draaien van een webserver met webservices Javax importeren. xml. ws. Eindpunt; // klasse van onze webservice import ru. Javarush. ws. HalloWebServiceImpl; public class HelloWebServicePublisher ( public static void main (String... args) ( // start de webserver op poort 1986 // en naar het adres dat is opgegeven in het eerste argument, // start de webservice die in het tweede argument is doorgegeven Eindpunt. publiceren( "http://localhost:1986/wss/hello", nieuwe HelloWebServiceImpl () ); ) ) Laten we nu deze klasse uitvoeren door te klikken Shift+F10. Er verschijnt niets in de console, maar de server draait. U kunt dit verifiëren door de regel http://localhost:1986/wss/hello?wsdl in uw browser te typen. De pagina die wordt geopend, bewijst enerzijds dat we een webserver (http://) hebben die op poort 1986 op onze computer draait (localhost), en toont anderzijds een WSDL-beschrijving van onze webservice. Als u de applicatie stopt, is de beschrijving niet meer beschikbaar, evenals de webservice zelf. We doen dit dus niet, maar gaan verder met het schrijven van de client.Cliënt
In de projectmap src Laten we een pakket ru.javarush.client maken en daarin de klasse HelloWebServiceClient met de hoofdmethode: pakket ru. Javarush. cliënt; // nodig om de wsdl-beschrijving op te halen en er doorheen te gaan // bereik de webservice zelf java importeren. netto. URL; // deze uitzondering treedt op als u met een URL-object werkt java importeren. netto. MisvormdeURLException; // klassen om XML te parseren met wsdl-beschrijving // en bereik de servicetag erin Javax importeren. xml. naamruimte. QNaam; Javax importeren. xml. ws. Dienst; // interface van onze webservice (we hebben meer nodig) import ru. Javarush. ws. HalloWebService; public class HelloWebServiceClient ( public static void main (String args) gooit MalformedURLException ( // maak een link naar de wsdl-beschrijving URL-URL= nieuwe URL ( "http://localhost:1986/wss/hello?wsdl") ; // We kijken naar de parameters van de volgende constructor in de allereerste tag van de WSDL-beschrijving - definities // kijk naar het eerste argument in het targetNamespace-attribuut // kijk naar het tweede argument in het naamattribuut QName qname = nieuwe QName ("http://ws.site/" , "HelloWebServiceImplService" ); // Nu kunnen we de servicetag bereiken wsdl-beschrijving, Dienstverlening= Dienst. create (url, qname) ; // en dan naar de poorttag die erin is genest, zodat // ontvang een link naar een webserviceobject op afstand van ons HalloWebService hallo = service. getPort(HelloWebService.class); // Hoera! Nu kunt u bellen methode op afstand Systeem. uit. println (hallo. getHelloString ("JavaRush") ); ) ) Ik heb zoveel mogelijk commentaar gegeven op de code in de aanbieding. Ik heb niets toe te voegen, dus laten we rennen (Shift+F10). We zouden de tekst in de console moeten zien: Hallo, JavaRush! Als je het niet hebt gezien, ben je waarschijnlijk vergeten de webservice te starten.Conclusie
In dit onderwerp werd gepresenteerd korte excursie naar webservices. Nogmaals, ik zal zeggen dat veel van wat ik schreef mijn inschatting is van hoe het werkt, en daarom moet je mij niet te veel vertrouwen. Ik zou dankbaar zijn als deskundige mensen Ze zullen mij corrigeren, want dan leer ik iets. UPD.In hoofdstuk 2 hebben we besproken dat nadat je een webservice op de server hebt gemaakt als een servlet, JSP-pagina, JWS-bestand, EJB of ander object, je de samenstelling en mogelijkheden van de webservice in een platformonafhankelijke taal moet beschrijven. besturingssysteem, het programmeersysteem dat wordt gebruikt om de webservice te maken. Deze beschrijving wordt geregistreerd op een openbaar toegankelijke locatie op internet, zoals een UDDI- of ebXML-register, of opgeslagen op een webserviceserver. De beschrijving moet volledige en bevatten exacte informatie over alle diensten die door de webdienst worden aangeboden, methoden voor het verkrijgen van diensten, de inhoud van het verzoek om de dienst, het formaat van de verstrekte informatie.
Eén van de middelen om webservices accuraat en uniform te beschrijven is de WSDL-taal, ontwikkeld door het W3C-consortium. Deze taal is een andere implementatie van XML. De nieuwste aanbevolen specificatie wordt altijd op de pagina gepubliceerd http://www.w3.org/TR/wsdI. Op het moment dat dit boek werd geschreven, was de WSDL-versie 1.2, die we in dit hoofdstuk zullen beschrijven.
Samenstelling van een WSDL-document
Het rootelement van het XML-document – de WSDL-beschrijving – is het element
WSDL-definities maken uitgebreid gebruik van verschillende naamruimten. Naast eigennamen gebruikt WSDL vaak elementnamen in type- en declaratietaal XSD-schema's(zie hoofdstuk 1) en taalnamen SOAP-protocol. De WSDL-naamruimte wordt vaak omschreven als de standaardnaamruimte. De naamruimte-ID van de nieuwste versie van WSDL 1.2 was op het moment van schrijven gelijk aan http://www.w3.org/2002/07/wsdl. De doelnaamruimte waarvan de identificatie wordt gespecificeerd door het attribuut, wordt gewoonlijk voorafgegaan door tns (doelnaamruimte).
Naar het rootelement
?
?
?
?
?
? < service >- specificeert de locatie van de webservice als een of meer poorten. Elke poort wordt beschreven door een genest element
Naast deze zes hoofdelementen zijn er nog twee hulpelementen.
?
Een reactie. Het kan in elk element worden opgenomen
WSDL-beschrijvingen.
We kunnen zeggen dat de elementen
Elementen
Tenslotte de elementen
De structuur van een WSDL-document wordt weergegeven in Listing 4.1. Tekens tussen vierkante haakjes zijn niet opgenomen in het document. Ze tonen de herhaling van een element of attribuut in een webservicebeschrijving:
Het teken [?] betekent dat het element of attribuut nul of één keer in het document mag voorkomen;
Het [*]-symbool betekent dat het element nul of meerdere keren mag voorkomen;
Het [+] symbool betekent dat het element één of meerdere keren mag voorkomen;
Het ontbreken van een teken tussen vierkante haken betekent dat het attribuut precies één keer moet voorkomen.
j Lijst 4.1. WSDL-documentschema
targetNamespace="nfleH l ra«iij locatie = "URI-aflpec" /> [*] Gratis commentaar Beschrijvingen van complexe en niet-standaard typen.
Een abstracte beschrijving van een SOAP-bericht als een reeks samenstellende delen.
Een abstracte beschrijving van een webservice als een reeks bewerkingen (services). Omschrijving van de dienst als het ontvangen (invoer) en verzenden (uitvoer, storings)meldingen. Bericht ontvangen. Verstuurd message="nMH corresponderend element Het foutbericht dat moet worden verzonden. type="MMH van het overeenkomstige element Specifieke protocoldetails. Ze zijn gedefinieerd in het schema dit protocol. -> Elementen die details beschrijven, worden hier geschreven specifieke operatie. -> Elementen die beschrijven details van het specifieke ontvangen bericht. -> Elementen die beschrijven details van het specifieke bericht dat wordt verzonden. ->
Elementen die beschrijven details van het specifieke foutbericht. ->
serviceType="MMH van het overeenkomstige element Beschrijving van de webservice-interface als een set poorten.
binding="nMH van het overeenkomstige element Het verplichte en enige adres van de webservice-interface wordt hier geschreven, geschreven volgens de regels protocol gespecificeerd in het element
Elk specifiek protocol voor berichtoverdracht - SOAP, HTTP, FTP, SMTP - voegt zijn eigen aanvullende elementen toe aan de zes hoofd- en twee hulpelementen van de WSDL-taal, en beschrijft de kenmerken van dit protocol.
Laten we een eenvoudig voorbeeld geven. In Listing 3.14 hebben we een eenvoudige webservice geschreven als een Java-klasse die het verzonden verzoek retourneert zonder enige verwerking:
openbare klasse EchoService(
public String getEcho(String req) ( return req;
Listing 4.2 beschrijft deze webservice in WSDL met behulp van het SOAP-protocol.
Lijst 4.2. Beschrijving van de EchoService-webservice
versie = "1.0" codering = "UTF-8" ?>
targetNamespace="http://echoservice.com/echoservice.wsdl" xmlns="http://www.w3.org/2002/07/wsdl" xmlns:tns="http://echoservice.com/echoservice.wsdl " xmlns:soap="http://www.w3.org/2002/07/wsdl/soapl2" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
transport = "http://schemas.xmlsoap.org/soap/http" /> "http://schemas.xmlsoap.org/soap/encoding/" naamruimte = "http://echoservice.ccm/echcservice.wsdl" use = "gecodeerd" /> ^oapKbocy enccdingStyle= "http: //schemas .xmlsoap.org/soap/encoding/" namespace= "http: //echoservice. c^/ech^service .wsdl" use="encoded" /> "http://localhost:8080/axis/EchoService.jws" /> In Listing 4.2 bevinden we ons in het element De namen "getEchoRequest" EN "getEchoResponse" WORDEN GEBRUIKT IN HET VOLGENDE ELEMENT txarspcrt^=^"ht:tp^://?chepas^.>plscap^.c^rc^/?cap^/ht:tp^" /> Als de SOAP-documentstijl wordt gebruikt, wordt het stijlattribuut ingesteld op "document". Eindelijk in het element In Listing 4.2 specificeerden namen voorafgegaan door soap de beschrijving van het bericht en hoe het werd verzonden. Laten we eens kijken welke specifieke protocollen de WSDL 1.2-specificatie biedt. Literatuur: Khabibullin I. Sh. Ontwikkeling van webservices met behulp van Java. - St. Petersburg: BHV-Petersburg, 2003. - 400 p.: ill. De topictitel is eigenlijk een vraag, want... Ik weet zelf niet wat het is en voor het eerst zal ik proberen ermee te werken in het kader van dit artikel. Het enige dat ik kan garanderen is dat de onderstaande code zal werken, maar mijn zinnen zullen slechts aannames en gissingen zijn over hoe ik dit zelf allemaal begrijp. Dus laten we gaan...Invoering
We moeten beginnen met de reden waarom het concept van webservices is ontstaan. Tegen de tijd dat dit concept in de wereld verscheen, bestonden er al technologieën die het mogelijk maakten dat applicaties op afstand konden communiceren, waarbij het ene programma een methode in een ander programma kon aanroepen, dat kon worden gelanceerd op een computer in een andere stad of zelfs een ander land. Dit alles wordt afgekort als RPC (Remote Procedure Calling). Voorbeelden hiervan zijn CORBA-technologieën en voor Java - RMI (Remote Method Invoking). En alles lijkt goed te zijn in hen, vooral in CORBA, omdat... Je kunt er in elke programmeertaal mee werken, maar er ontbrak nog iets. Ik denk dat het nadeel van CORBA is dat het via een aantal van zijn eigen netwerkprotocollen werkt in plaats van via eenvoudige HTTP, die door elke firewall past. Het idee van de webservice was om een RPC te maken die in HTTP-pakketten zou worden ingevoegd. Zo begon de ontwikkeling van de standaard. Wat zijn de basisconcepten van deze standaard:
Waarom zo kort vraag je? Kun je niet specifieker zijn? Het is waarschijnlijk mogelijk, maar om dit te doen zul je boeken moeten raadplegen zoals T. Mashnin, “Java Web Services.” Daar vindt u op de eerste 200 pagina's een gedetailleerde beschrijving van elke tag van de SOAP- en WSDL-standaarden. Is het de moeite waard om te doen? Volgens mij niet, want... dit alles wordt automatisch in Java gemaakt en u hoeft alleen de inhoud te schrijven van de methoden die op afstand moeten worden aangeroepen. Er verscheen dus een API zoals JAX-RPC in Java. Als iemand het niet weet, als hij zegt dat Java een bepaalde API heeft, betekent dit dat er een pakket is met een reeks klassen die de betreffende technologie inkapselen. JAX-RPC evolueerde in de loop van de tijd van versie naar versie en werd uiteindelijk JAX-WS. WS staat duidelijk voor WebService en je zou kunnen denken dat dit tegenwoordig simpelweg een nieuwe naam is voor RPC als een populair modewoord. Dit is niet waar, omdat Nu hebben webservices afstand genomen van het oorspronkelijke idee en kunt u niet alleen externe methoden aanroepen, maar ook eenvoudigweg documentberichten in SOAP-formaat verzenden. Ik weet nog niet waarom dit nodig is; het is onwaarschijnlijk dat het antwoord hier zal zijn ‘voor het geval dat het nodig is’. Zelf zou ik graag willen leren van meer ervaren kameraden. En als laatste verscheen JAX-RS voor zogenaamde RESTful-webservices, maar dit is het onderwerp van een apart artikel. De introductie kan hier eindigen, want... Vervolgens gaan we leren werken met JAX-WS. Algemene benadering
Bij webservices is er altijd een client en een server. De server is onze webservice en wordt soms het eindpunt genoemd (zoals in het eindpunt waar SOAP-berichten van de client aankomen). We moeten het volgende doen:
U kunt een webservice op verschillende manieren starten: beschrijf een klasse met de hoofdmethode en start de webservice rechtstreeks als server, of implementeer deze op een server zoals Tomcat of een andere. In het tweede geval lanceren we zelf geen nieuwe server en openen we geen andere poort op de computer, maar vertellen we eenvoudigweg aan de Tomcat-servletcontainer dat “we hier webserviceklassen hebben geschreven, publiceer ze alstublieft zodat iedereen die contact met u opneemt, kan gebruik onze webservice." Ongeacht de manier waarop de webservice wordt gestart, we hebben dezelfde klant. Server
Laten we IDEA lanceren en een nieuw project maken Nieuw project maken. Laten we de naam aangeven HalloWebService en druk op de knop Volgende en vervolgens op de knop Finish. In map src laten we een pakket maken ru.javarush.ws. In dit pakket maken we de HelloWebService-interface: package ru. Javarush. ws; // dit zijn annotaties, d.w.z. een manier om onze klassen en methoden te markeren,
// met betrekking tot webservicetechnologie Javax importeren. jws. WebMethode; Javax importeren. jws. WebService; Javax importeren. jws. zeep. ZEEPbinden; // we zeggen dat onze interface zal werken als een webservice@WebService // we zeggen dat de webservice zal worden gebruikt om methoden aan te roepen@SOAPBinding (stijl = SOAPBinding. Stijl. RPC) openbare interface HelloWebService ( // we zeggen dat deze methode op afstand kan worden aangeroepen@WebMethod public String getHelloString(Stringnaam) ; ) In deze code zijn de klassen WebService en WebMethod zogenaamde annotaties en doen ze niets anders dan onze interface en de bijbehorende methode markeren als een webservice. Hetzelfde geldt voor de klasse SOAPBinding. Het enige verschil is dat SOAPBinding een annotatie met parameters is. In dit geval wordt de parameter style gebruikt met een waarde die aangeeft dat de webservice niet via documentberichten werkt, maar als een klassieke RPC, d.w.z. om de methode aan te roepen. Laten we onze interfacelogica implementeren en een HelloWebServiceImpl-klasse in ons pakket maken. Overigens merk ik op dat het beëindigen van een klasse met Impl een conventie is in Java, volgens welke de implementatie van interfaces zo wordt aangeduid (Impl - van het woord implementatie, d.w.z. implementatie). Dit is geen vereiste en je bent vrij om de klasse een naam te geven die je wilt, maar goede manieren vereisen het: pakket ru. Javarush. ws; // dezelfde annotatie als bij het beschrijven van de interface, Javax importeren. jws. WebService; // maar hier wordt het gebruikt met de parameter endpointInterface,
// geeft de volledige naam aan van de interfaceklasse van onze webservice@WebService(endpointInterface= "ru.javarush.ws.HelloWebService") public class HelloWebServiceImpl implementeert HelloWebService ( @Override public String getHelloString (String-naam) ( // beantwoord gewoon de begroeting return "Hallo, " + naam + "!" ; ) ) Laten we onze webservice lanceren als een onafhankelijke server, d.w.z. zonder de deelname van Tomcat en applicatieservers (dit is een onderwerp voor een aparte discussie). Om dit te doen, in de projectstructuur in de map src Laten we een pakket ru.javarush.endpoint maken, en daarin zullen we een HelloWebServicePublisher-klasse maken met de hoofdmethode: pakket ru. Javarush. eindpunt; // klasse voor het draaien van een webserver met webservices Javax importeren. xml. ws. Eindpunt; // klasse van onze webservice import ru. Javarush. ws. HalloWebServiceImpl; public class HelloWebServicePublisher ( public static void main (String... args) ( // start de webserver op poort 1986
// en naar het adres dat is opgegeven in het eerste argument,
// start de webservice die in het tweede argument is doorgegeven Eindpunt. publiceren( "http://localhost:1986/wss/hello", nieuwe HelloWebServiceImpl () ); ) ) Laten we nu deze klasse uitvoeren door te klikken Shift+F10. Er verschijnt niets in de console, maar de server draait. U kunt dit verifiëren door de regel http://localhost:1986/wss/hello?wsdl in uw browser te typen. De pagina die wordt geopend, bewijst enerzijds dat we een webserver (http://) hebben die op poort 1986 op onze computer draait (localhost), en toont anderzijds een WSDL-beschrijving van onze webservice. Als u de applicatie stopt, is de beschrijving niet meer beschikbaar, evenals de webservice zelf. We doen dit dus niet, maar gaan verder met het schrijven van de client. Cliënt
In de projectmap src Laten we een pakket ru.javarush.client maken en daarin de klasse HelloWebServiceClient met de hoofdmethode: pakket ru. Javarush. cliënt; // nodig om de wsdl-beschrijving op te halen en er doorheen te gaan
// bereik de webservice zelf java importeren. netto. URL; // deze uitzondering treedt op als u met een URL-object werkt java importeren. netto. MisvormdeURLException; // klassen om XML te parseren met wsdl-beschrijving
// en bereik de servicetag erin Javax importeren. xml. naamruimte. QNaam; Javax importeren. xml. ws. Dienst; // interface van onze webservice (we hebben meer nodig) import ru. Javarush. ws. HalloWebService; public class HelloWebServiceClient ( public static void main (String args) gooit MalformedURLException ( // maak een link naar de wsdl-beschrijving URL-URL = nieuwe URL ( "http://localhost:1986/wss/hello?wsdl")
;
// We kijken naar de parameters van de volgende constructor in de allereerste tag van de WSDL-beschrijving - definities
// kijk naar het eerste argument in het targetNamespace-attribuut
// kijk naar het tweede argument in het naamattribuut QName qname = nieuwe QName ("http://ws.javarush.ru/" , "HelloWebServiceImplService" ); // Nu kunnen we de servicetag in de wsdl-beschrijving bereiken, Servicedienst = Service. create (url, qname) ; // en dan naar de poorttag die erin is genest, zodat
// ontvang een link naar een webserviceobject op afstand van ons HalloWebService hallo = service. getPort(HelloWebService.class); // Hoera! U kunt nu de externe methode aanroepen Systeem. uit. println (hallo. getHelloString ("JavaRush") ); ) ) Ik heb zoveel mogelijk commentaar gegeven op de code in de aanbieding. Ik heb niets toe te voegen, dus laten we rennen (Shift+F10). We zouden de tekst in de console moeten zien: Hallo, JavaRush! Als je het niet hebt gezien, ben je waarschijnlijk vergeten de webservice te starten. Conclusie
Dit onderwerp bood een korte excursie naar webservices. Nogmaals, ik zal zeggen dat veel van wat ik schreef mijn inschatting is van hoe het werkt, en daarom moet je mij niet te veel vertrouwen. Ik zou dankbaar zijn als deskundige mensen mij corrigeren, want dan leer ik iets. UPD.
