Ce este un serviciu web - Descriere folosind WSDL. Care este diferența dintre XSD și WSDL

Elementele de extensie de legare sunt utilizate pentru a specifica o gramatică specifică pentru mesajele de eroare (3) primite (3) și trimise (4) (5). De asemenea, pot fi specificate informații despre nivelul de operare (2) și nivelul obligatoriu (1).

Elementul de legare a operațiunii conține date pentru funcționarea cu același nume a tipului de port asociat. Cu toate acestea, numele operațiunii nu este, în general, unic (de exemplu: metode de supraîncărcare / funcții - folosind aceleași nume cu semnături diferite), prin urmare poate să nu fie suficient pentru a determina în mod unic operațiunea țintă a tipului de port. În astfel de cazuri, operațiunea țintă este adresată prin specificarea suplimentară a numelor adecvate ale elementelor wsdl:input și wsdl:output folosind atributul name.

Legare trebuie sa instalați un singur protocol.

Legare nu ar trebui conțin informații despre adresă.

Port

Un port definește un singur punct final prin setarea unei adrese la care să se lege.

1. <wsdl:definiții .... >
2. <wsdl:serviciu .... > *
3. <wsdl:port name = "nmtoken" binding = "qname" > *
4. <-- extensibility element (1) -->
5. wsdl:port>
6. wsdl:serviciu>
7. wsdl:definiții>

Atributul nume specifică nume unic dintre toate porturile din documentul WSDL. Atributul de legare de tip QName conține o referință la legare (vezi).

Elementele de extensie (1) sunt utilizate pentru a specifica adresa.

Port nu ar trebui specificați mai multe adrese.

Port nu ar trebui conțin orice informații obligatorii, altele decât o adresă.

Serviciu

Un serviciu reunește un set de porturi asociate.

1. <wsdl:definiții .... >
2. <wsdl:serviciu nume = "nmtoken" > *
3. <wsdl:port .... /> *
4. wsdl:serviciu>
5. wsdl:definiții>

Atributul name specifică un nume unic printre toate serviciile definite în documentul WSDL.

Porturile din cadrul unui serviciu sunt conectate după cum urmează:

• Porturile nu comunică între ele (adică ieșirea unui port nu este intrarea altuia).
• Dacă un serviciu are mai multe porturi care împărtășesc un tip de port comun, dar utilizează legături diferite sau au adrese diferite, acele porturi sunt porturi alternative. Fiecare astfel de port implementează un comportament logic echivalent (în cadrul restricțiilor de transport și format de mesaj impuse de legarea corespunzătoare). Acest lucru permite clientului să selecteze un port specific pentru comunicare pe baza diferitelor criterii (suport protocol de transport etc.).
• Privind porturile, puteți determina ce tipuri de porturi sunt acceptate de serviciu. Pe baza acestor date, clientul poate determina capacitatea de a interacționa cu un anumit serviciu. Acest lucru este util dacă este implicată o relație între operațiunile de la tipuri diferite porturi și pentru a efectua o anumită sarcină, serviciul trebuie să accepte toate tipurile de porturi necesare.

1. Aceasta este o traducere gratuită, parțială, extinsă a documentului Web Services Description Language (WSDL) 1.1 din 15 martie 2001
2. Este extrem de incomod să operezi cu termeni indeclinabili scrisi în latină și, de asemenea, sunt traduși fără ambiguitate. Prin urmare, numele original este dat numai atunci când este introdus un termen nou, iar mai departe în text este folosită traducerea în limba rusă.

Titlul subiectului este într-adevăr o întrebare, pentru că... Eu însumi nu știu ce este și pentru prima dată voi încerca să lucrez cu el în cadrul acestui articol. Singurul lucru pe care îl pot garanta este că codul prezentat mai jos va funcționa, dar frazele mele vor fi doar presupuneri și presupuneri despre cum înțeleg eu însumi toate acestea. Deci să mergem...

Introducere

Trebuie să începem cu motivul pentru care a fost creat conceptul de servicii web. Până la apariția acestui concept în lume, deja existau tehnologii care permiteau aplicațiilor să interacționeze la distanță, unde un program putea apela la o metodă într-un alt program, care putea fi lansat pe un computer situat într-un alt oraș sau chiar țară. Toate acestea sunt prescurtate ca RPC (Remote Procedure Calling). Exemplele includ tehnologiile CORBA și pentru Java - RMI (Remote Method Invoking). Și totul pare să fie bine în ei, mai ales în CORBA, pentru că... Puteți lucra cu el în orice limbaj de programare, dar încă lipsea ceva. Cred că dezavantajul CORBA este că funcționează prin unele dintre ele protocoale de rețeaîn loc de HTTP simplu, care se va potrivi prin orice firewall. Ideea serviciului web a fost de a crea un RPC care să fie inserat în pachetele HTTP. Astfel a început dezvoltarea standardului. Care sunt conceptele de bază ale acestui standard:

1. SĂPUN. Înainte de a apela o procedură de la distanță, trebuie să descrieți acest apel în fișier XML e format SOAP. SOAP este pur și simplu unul dintre numeroasele markupuri XML care sunt utilizate în serviciile web. Tot ceea ce dorim să trimitem undeva prin HTTP este mai întâi convertit într-o descriere XML SOAP, apoi introdus într-un pachet HTTP și trimis către un alt computer din rețea prin TCP/IP.
2. WSDL. Există un serviciu web, adică un program ale cărui metode pot fi apelate de la distanță. Dar standardul cere ca acest program să fie însoțit de o descriere care spune că „da, ai dreptate - acesta este într-adevăr un serviciu web și poți apela astfel de metode din el”. Această descriere este reprezentată de un alt fișier XML, care are un alt format și anume WSDL. Acestea. WSDL este doar un fișier XML care descrie un serviciu web și nimic mai mult.

De ce întrebi atât de scurt? Nu poți fi mai precis? Probabil că este posibil, dar pentru a face acest lucru va trebui să apelați la cărți precum T. Mashnin, „Java Web Services”. Acolo pentru primele 200 de pagini vin mai multe detalii descrierea fiecărei etichete standard SOAP și WSDL. Merită făcut? După părerea mea, nu, pentru că... toate acestea sunt create automat în Java și trebuie doar să scrieți conținutul metodelor care ar trebui să fie apelate de la distanță. Deci, un API precum JAX-RPC a apărut în Java. Dacă cineva nu știe, când spune că Java are așa și așa API, înseamnă că există un pachet cu un set de clase care încapsulează tehnologia în cauză. JAX-RPC a evoluat de-a lungul timpului de la o versiune la alta și în cele din urmă a devenit JAX-WS. WS înseamnă, evident, WebService și s-ar putea crede că aceasta este pur și simplu o redenumire a RPC ca un cuvânt popular în zilele noastre. Acest lucru nu este adevărat, pentru că Acum serviciile web s-au îndepărtat de ideea inițială și permit nu numai apelarea metodelor de la distanță, ci și pur și simplu trimiterea de mesaje de document în format SOAP. Nu știu încă de ce este nevoie de acest lucru; este puțin probabil ca răspunsul aici să fie „doar în cazul în care este necesar”. Eu însumi aș dori să învăț de la camarazi mai experimentați. Și, în sfârșit, a apărut JAX-RS pentru așa-numitele servicii web RESTful, dar acesta este subiectul unui articol separat. Introducerea se poate încheia aici, pentru că... În continuare vom învăța să lucrăm cu JAX-WS.

Abordare generală

În serviciile web există întotdeauna un client și un server. Serverul este serviciul nostru web și uneori este numit punctul final (cum ar fi, punctul final, unde ajung Mesaje SOAP de la client). Trebuie să facem următoarele:

1. Descrieți interfața serviciului nostru web
2. Implementați această interfață
3. Lansați serviciul nostru web
4. Scrieți un client și sunați de la distanță metoda dorita serviciu web

Serviciul web poate fi lansat căi diferite: fie descrieți o clasă cu o metodă principală și rulați serviciul web direct ca server, fie implementați-l pe un server precum Tomcat sau oricare altul. În al doilea caz, nu ne lansăm server nouși nu deschidem un alt port pe computer, ci pur și simplu spunem containerului de servlet Tomcat că „am scris clase de servicii web aici, vă rugăm să le publicați, astfel încât toți cei care vă contactează să poată folosi serviciul nostru web”. Indiferent de metoda de lansare a serviciului web, vom avea acelasi client.

Server

Să lansăm IDEA și să creăm proiect nou Creați un nou proiect. Să indicăm numele HelloWebServiceși apăsați butonul Următorul, apoi butonul finalizarea. În dosar src hai să creăm un pachet ru.javarush.ws. În acest pachet vom crea interfața HelloWebService: pachet ru. javarush. ws; // acestea sunt adnotări, i.e. o modalitate de a ne marca clasele și metodele, // în legătură cu tehnologia serviciilor web import javax. jws. WebMethod; import javax. jws. Serviciu web; import javax. jws. săpun. SAPUNLegare;// spunem că interfața noastră va funcționa ca un serviciu web @Serviciu web// spunem că serviciul web va fi folosit pentru a apela metode @SOAPBinding (style = SOAPBinding. Style. RPC) interfață publică HelloWebService (// spunem că această metodă poate fi apelată de la distanță @WebMethod public String getHelloString(Nume șir) ; ) În acest cod, clasele WebService și WebMethod sunt așa-numitele adnotări și nu fac altceva decât să marcheze interfața noastră și metoda acesteia ca serviciu web. Același lucru este valabil și pentru clasa SOAPBinding. Singura diferență este că SOAPBinding este o adnotare cu parametri. În acest caz, parametrul de stil este utilizat cu o valoare care indică faptul că serviciul web va funcționa nu prin mesaje de document, ci ca un RPC clasic, de exemplu. a apela metoda. Să implementăm logica interfeței noastre și să creăm o clasă HelloWebServiceImpl în pachetul nostru. Apropo, observ că terminarea unei clase cu Impl este o convenție în Java, conform căreia implementarea interfețelor este astfel desemnată (Impl - din cuvântul implementare, adică implementare). Aceasta nu este o cerință și sunteți liber să denumiți clasa cum doriți, dar bunele maniere o cer: pachet ru. javarush. ws;// aceeași adnotare ca atunci când descrieți interfața, import javax. jws. Serviciu web; // dar aici este folosit cu parametrul endpointInterface, // indicând Numele complet clasa de interfață a serviciului nostru web @WebService(endpointInterface=„ru.javarush.ws.HelloWebService” ) clasa publică HelloWebServiceImpl implementează HelloWebService ( @Override public String getHelloString (nume șir) ( returnează "Bună ziua, " + nume + "!" ; ) ) Să lansăm serviciul nostru web ca server independent, adică. fără participarea niciunui Tomcat și a serverelor de aplicații (acesta este un subiect pentru o discuție separată). Pentru a face acest lucru, în structura proiectului din folder src Să creăm un pachet ru.javarush.endpoint, iar în el vom crea o clasă HelloWebServicePublisher cu metoda principală: pachetul ru. javarush. punct final; // clasa pentru rularea unui server web cu servicii web import javax. xml. ws. Punct final; // clasa serviciului nostru web import ru. javarush. ws. HelloWebServiceImpl; clasă publică HelloWebServicePublisher ( public static void main (String... args) ( // porniți serverul web pe portul 1986 // și la adresa specificată în primul argument, // pornește serviciul web transmis în al doilea argument Punct final. publica( „http://localhost:1986/wss/hello”, nou HelloWebServiceImpl () ); ) ) Acum să rulăm această clasă făcând clic Shift+F10. Nu va apărea nimic în consolă, dar serverul rulează. Puteți verifica acest lucru tastând linia http://localhost:1986/wss/hello?wsdl în browser. Pagina care se deschide, pe de o parte, demonstrează că avem un server web (http://) care rulează pe portul 1986 pe computerul nostru (localhost) și, pe de altă parte, arată o descriere WSDL a serviciului nostru web. Dacă opriți aplicația, descrierea va deveni indisponibilă, la fel ca și serviciul web în sine, așa că nu vom face acest lucru, ci vom trece la scrierea clientului.

Client

În folderul de proiect src Să creăm un pachet ru.javarush.client , iar în el clasa HelloWebServiceClient cu metoda principală: pachet ru. javarush. client; // necesar pentru a obține descrierea wsdl și prin ea // ajunge la serviciul web în sine import java. net. URL; // această excepție va apărea când lucrați cu un obiect URL import java. net. MalformedURLException; // clase pentru a analiza xml cu descrierea wsdl // și ajungeți la eticheta de serviciu din ea import javax. xml. spatiu de nume. QName; import javax. xml. ws. Serviciu; // interfața serviciului nostru web (avem nevoie de mai mult) import ru. javarush. ws. HelloWebService; clasă publică HelloWebServiceClient ( public static void main (String args) aruncă MalformedURLException ( // creează un link către descrierea wsdl URL URL= URL nou ( „http://localhost:1986/wss/hello?wsdl”) ; // Ne uităm la parametrii următorului constructor din prima etichetă a descrierii WSDL - definiții // uită-te la primul argument din atributul targetNamespace // uită-te la al 2-lea argument atributul numelui QName qname = nou QName ("http://ws.javarush.ru/" , "HelloWebServiceImplService"); // Acum putem ajunge la eticheta de serviciu din descrierea wsdl, Service service= Serviciu. create (url, qname); // și apoi până la eticheta de port imbricată în ea, astfel încât // obțineți un link către un obiect de serviciu web aflat la distanță de la noi HelloWebService hello = serviciu. getPort(HelloWebService.class); // Ura! Acum puteți apela metoda de la distanță Sistem. afară. println (bună ziua. getHelloString ("JavaRush")); ) ) Am dat maxim de comentarii la codul din listare. Nu am nimic de adăugat, așa că hai să alergăm (Shift+F10). Ar trebui să vedem textul în consolă: Bună ziua, JavaRush! Dacă nu l-ați văzut, atunci probabil ați uitat să porniți serviciul web.

Concluzie

Acest subiect a oferit o scurtă excursie în serviciile web. Încă o dată, voi spune că o mare parte din ceea ce am scris este presupunerea mea cu privire la modul în care funcționează și, prin urmare, nu ar trebui să aveți prea multă încredere în mine. As fi recunoscator daca oameni cunoscători Mă vor corecta, pentru că atunci voi învăța ceva. UPD.

Elementele de extensie de legare sunt utilizate pentru a specifica o gramatică specifică pentru mesajele de eroare (3) primite (3) și trimise (4) (5). De asemenea, pot fi specificate informații despre nivelul de operare (2) și nivelul obligatoriu (1).

Elementul de legare a operațiunii conține date pentru funcționarea cu același nume a tipului de port asociat. Cu toate acestea, numele operațiunii nu este, în general, unic (de exemplu: metode de supraîncărcare / funcții - folosind aceleași nume cu semnături diferite), prin urmare poate să nu fie suficient pentru a determina în mod unic operațiunea țintă a tipului de port. În astfel de cazuri, operațiunea țintă este adresată prin specificarea suplimentară a numelor adecvate ale elementelor wsdl:input și wsdl:output folosind atributul name.

Legare trebuie sa instalați un singur protocol.

Legare nu ar trebui conțin informații despre adresă.

Port

Un port definește un singur punct final prin setarea unei adrese la care să se lege.

1. <wsdl:definiții .... >
2. <wsdl:serviciu .... > *
3. <wsdl:port name = "nmtoken" binding = "qname" > *
4. <-- extensibility element (1) -->
5. wsdl:port>
6. wsdl:serviciu>
7. wsdl:definiții>

Atributul name specifică un nume unic printre toate porturile din documentul WSDL. Atributul de legare de tip QName conține o referință la legare (vezi).

Elementele de extensie (1) sunt utilizate pentru a specifica adresa.

Port nu ar trebui specificați mai multe adrese.

Port nu ar trebui conțin orice informații obligatorii, altele decât o adresă.

Serviciu

Un serviciu reunește un set de porturi asociate.

1. <wsdl:definiții .... >
2. <wsdl:serviciu nume = "nmtoken" > *
3. <wsdl:port .... /> *
4. wsdl:serviciu>
5. wsdl:definiții>

Atributul name specifică un nume unic printre toate serviciile definite în documentul WSDL.

Porturile din cadrul unui serviciu sunt conectate după cum urmează:

• Porturile nu comunică între ele (adică ieșirea unui port nu este intrarea altuia).
• Dacă un serviciu are mai multe porturi care partajează un tip de port comun, dar utilizează legături diferite sau au adrese diferite, acele porturi sunt porturi alternative. Fiecare astfel de port implementează un comportament logic echivalent (în cadrul restricțiilor de transport și format de mesaj impuse de legarea corespunzătoare). Acest lucru permite clientului să selecteze un anumit port pentru comunicare pe baza diferitelor criterii (suport protocol de transport etc.).
• Privind porturile, puteți determina ce tipuri de porturi sunt acceptate de serviciu. Pe baza acestor date, clientul poate determina capacitatea de a interacționa cu un anumit serviciu. Acest lucru este util dacă există o conexiune între operațiunile din diferite tipuri de porturi, iar serviciul trebuie să accepte toate tipurile de porturi necesare pentru a efectua o anumită sarcină.

1. Aceasta este o traducere gratuită, parțială, extinsă a documentului Web Services Description Language (WSDL) 1.1 din 15 martie 2001
2. Este extrem de incomod să operezi cu termeni indeclinabili scrisi în latină și, de asemenea, sunt traduși fără ambiguitate. Prin urmare, numele original este dat numai atunci când este introdus un termen nou, iar mai departe în text este folosită traducerea în limba rusă.

Titlul subiectului este într-adevăr o întrebare, pentru că... Eu însumi nu știu ce este și pentru prima dată voi încerca să lucrez cu el în cadrul acestui articol. Singurul lucru pe care îl pot garanta este că codul prezentat mai jos va funcționa, dar frazele mele vor fi doar presupuneri și presupuneri despre cum înțeleg eu însumi toate acestea. Deci să mergem...

Introducere

Trebuie să începem cu motivul pentru care a fost creat conceptul de servicii web. Până la apariția acestui concept în lume, deja existau tehnologii care permiteau aplicațiilor să interacționeze la distanță, unde un program putea apela la o metodă într-un alt program, care putea fi lansat pe un computer situat într-un alt oraș sau chiar țară. Toate acestea sunt prescurtate ca RPC (Remote Procedure Calling). Exemplele includ tehnologiile CORBA și pentru Java - RMI (Remote Method Invoking). Și totul pare să fie bine în ei, mai ales în CORBA, pentru că... Puteți lucra cu el în orice limbaj de programare, dar încă lipsea ceva. Cred că dezavantajul CORBA este că funcționează prin unele dintre propriile protocoale de rețea în loc de simplu HTTP, care se va potrivi prin orice firewall. Ideea serviciului web a fost de a crea un RPC care să fie inserat în pachetele HTTP. Astfel a început dezvoltarea standardului. Care sunt conceptele de bază ale acestui standard:

1. SĂPUN. Înainte de a apela o procedură la distanță, trebuie să descrieți acest apel într-un fișier XML în format SOAP. SOAP este pur și simplu unul dintre numeroasele markupuri XML care sunt utilizate în serviciile web. Tot ceea ce dorim să trimitem undeva prin HTTP este mai întâi convertit într-o descriere XML SOAP, apoi introdus într-un pachet HTTP și trimis către un alt computer din rețea prin TCP/IP.
2. WSDL. Există un serviciu web, adică un program ale cărui metode pot fi apelate de la distanță. Dar standardul cere ca acest program să fie însoțit de o descriere care spune că „da, ai dreptate - acesta este într-adevăr un serviciu web și poți apela astfel de metode din el”. Această descriere este reprezentată de un alt fișier XML, care are un alt format și anume WSDL. Acestea. WSDL este doar un fișier XML care descrie un serviciu web și nimic mai mult.

De ce întrebi atât de scurt? Nu poți fi mai precis? Probabil că este posibil, dar pentru a face acest lucru va trebui să apelați la cărți precum T. Mashnin, „Java Web Services”. Acolo, pe parcursul primelor 200 de pagini există descriere detaliata fiecare etichetă a standardelor SOAP și WSDL. Merită făcut? După părerea mea, nu, pentru că... toate acestea sunt create automat în Java și trebuie doar să scrieți conținutul metodelor care ar trebui să fie apelate de la distanță. Deci, un API precum JAX-RPC a apărut în Java. Dacă cineva nu știe, când spune că Java are așa și așa API, înseamnă că există un pachet cu un set de clase care încapsulează tehnologia în cauză. JAX-RPC a evoluat de-a lungul timpului de la o versiune la alta și în cele din urmă a devenit JAX-WS. WS înseamnă, în mod evident, WebService și ați putea crede că aceasta este pur și simplu o redenumire a RPC ca un cuvânt popular la modă în zilele noastre. Acest lucru nu este adevărat, pentru că Acum serviciile web s-au îndepărtat de ideea originală și vă permit nu numai să apelați metode de la distanță, ci și să trimiteți pur și simplu mesaje de document în format SOAP. Nu știu încă de ce este nevoie de acest lucru; este puțin probabil ca răspunsul aici să fie „doar în cazul în care este necesar”. Eu însumi aș dori să învăț de la camarazi mai experimentați. Și, în sfârșit, a apărut JAX-RS pentru așa-numitele servicii web RESTful, dar acesta este subiectul unui articol separat. Introducerea se poate încheia aici, pentru că... În continuare vom învăța să lucrăm cu JAX-WS.

Abordare generală

În serviciile web există întotdeauna un client și un server. Serverul este serviciul nostru web și uneori este numit punctul final (ca în, punctul final unde ajung mesajele SOAP de la client). Trebuie să facem următoarele:

1. Descrieți interfața serviciului nostru web
2. Implementați această interfață
3. Lansați serviciul nostru web
4. Scrieți un client și apelați de la distanță metoda de serviciu web dorită

Puteți lansa un serviciu web în diferite moduri: fie descrieți o clasă cu metoda principală și lansați serviciul web direct ca server, fie implementați-l pe un server precum Tomcat sau oricare altul. În cel de-al doilea caz, noi înșine nu lansăm un nou server și nu deschidem alt port pe computer, ci pur și simplu spunem containerului de servlet Tomcat că „am scris aici clase de servicii web, vă rugăm să le publicați astfel încât toți cei care vă contactează să poată folosiți utilizarea serviciului web.” Indiferent de metoda de lansare a serviciului web, vom avea acelasi client.

Server

Să lansăm IDEA și să creăm un nou proiect Creați un nou proiect. Să indicăm numele HelloWebServiceși apăsați butonul Următorul, apoi butonul finalizarea. În dosar src hai să creăm un pachet ru.javarush.ws. În acest pachet vom crea interfața HelloWebService: pachet ru. javarush. ws; // acestea sunt adnotări, i.e. o modalitate de a ne marca clasele și metodele, // în legătură cu tehnologia serviciilor web import javax. jws. WebMethod; import javax. jws. Serviciu web; import javax. jws. săpun. SAPUNLegare;// spunem că interfața noastră va funcționa ca un serviciu web @Serviciu web// spunem că serviciul web va fi folosit pentru a apela metode @SOAPBinding (style = SOAPBinding. Style. RPC) interfață publică HelloWebService (// spunem că această metodă poate fi apelată de la distanță @WebMethod public String getHelloString(Nume șir) ; ) În acest cod, clasele WebService și WebMethod sunt așa-numitele adnotări și nu fac altceva decât să marcheze interfața noastră și metoda acesteia ca serviciu web. Același lucru este valabil și pentru clasa SOAPBinding. Singura diferență este că SOAPBinding este o adnotare cu parametri. În acest caz, parametrul de stil este utilizat cu o valoare care indică faptul că serviciul web va funcționa nu prin mesaje de document, ci ca un RPC clasic, de exemplu. a apela metoda. Să implementăm logica interfeței noastre și să creăm o clasă HelloWebServiceImpl în pachetul nostru. Apropo, observ că terminarea unei clase cu Impl este o convenție în Java, conform căreia implementarea interfețelor este astfel desemnată (Impl - din cuvântul implementare, adică implementare). Aceasta nu este o cerință și sunteți liber să denumiți clasa cum doriți, dar bunele maniere o cer: pachet ru. javarush. ws;// aceeași adnotare ca atunci când descrieți interfața, import javax. jws. Serviciu web; // indicând numele complet al clasei de interfață a serviciului nostru web clasa de interfață a serviciului nostru web @WebService(endpointInterface=„ru.javarush.ws.HelloWebService” ) clasa publică HelloWebServiceImpl implementează HelloWebService ( @Override public String getHelloString (nume șir) ( returnează "Bună ziua, " + nume + "!" ; ) ) Să lansăm serviciul nostru web ca server independent, adică. fără participarea niciunui Tomcat și a serverelor de aplicații (acesta este un subiect pentru o discuție separată). Pentru a face acest lucru, în structura proiectului din folder src Să creăm un pachet ru.javarush.endpoint, iar în el vom crea o clasă HelloWebServicePublisher cu metoda principală: pachetul ru. javarush. punct final; // clasa pentru rularea unui server web cu servicii web import javax. xml. ws. Punct final; // clasa serviciului nostru web import ru. javarush. ws. HelloWebServiceImpl; clasă publică HelloWebServicePublisher ( public static void main (String... args) ( // porniți serverul web pe portul 1986 // și la adresa specificată în primul argument, // pornește serviciul web transmis în al doilea argument Punct final. publica( „http://localhost:1986/wss/hello”, nou HelloWebServiceImpl () ); ) ) Acum să rulăm această clasă făcând clic Shift+F10. Nu va apărea nimic în consolă, dar serverul rulează. Puteți verifica acest lucru tastând linia http://localhost:1986/wss/hello?wsdl în browser. Pagina care se deschide, pe de o parte, demonstrează că avem un server web (http://) care rulează pe portul 1986 pe computerul nostru (localhost) și, pe de altă parte, arată o descriere WSDL a serviciului nostru web. Dacă opriți aplicația, descrierea va deveni indisponibilă, la fel ca și serviciul web în sine, așa că nu vom face acest lucru, ci vom trece la scrierea clientului.

Client

În folderul de proiect src Să creăm un pachet ru.javarush.client , iar în el clasa HelloWebServiceClient cu metoda principală: pachet ru. javarush. client; // necesar pentru a obține descrierea wsdl și prin ea // ajunge la serviciul web în sine import java. net. URL; // această excepție va apărea când lucrați cu un obiect URL import java. net. MalformedURLException; // clase pentru a analiza xml cu descrierea wsdl // și ajungeți la eticheta de serviciu din ea import javax. xml. spatiu de nume. QName; import javax. xml. ws. Serviciu; // interfața serviciului nostru web (avem nevoie de mai mult) import ru. javarush. ws. HelloWebService; clasă publică HelloWebServiceClient ( public static void main (String args) aruncă MalformedURLException ( // creează un link către descrierea wsdl URL URL = adresă URL nouă ( „http://localhost:1986/wss/hello?wsdl”) ; // Ne uităm la parametrii următorului constructor din prima etichetă a descrierii WSDL - definiții // uită-te la primul argument din atributul targetNamespace // uită-te la al 2-lea argument din atributul name QName qname = nou QName ("http://ws.site/" , "HelloWebServiceImplService" ); // Acum putem ajunge la eticheta de serviciu din descrierea wsdl, Service service = Service. create (url, qname); // și apoi până la eticheta de port imbricată în ea, astfel încât // obțineți un link către un obiect de serviciu web aflat la distanță de la noi HelloWebService hello = serviciu. getPort(HelloWebService.class); // Ura! Acum puteți apela metoda de la distanță Sistem. afară. println (bună ziua. getHelloString ("JavaRush")); ) ) Am dat maxim de comentarii la codul din listare. Nu am nimic de adăugat, așa că hai să alergăm (Shift+F10). Ar trebui să vedem textul în consolă: Bună ziua, JavaRush! Dacă nu l-ați văzut, atunci probabil ați uitat să porniți serviciul web.

Concluzie

Acest subiect a oferit o scurtă excursie în serviciile web. Încă o dată, voi spune că o mare parte din ceea ce am scris este presupunerea mea cu privire la modul în care funcționează și, prin urmare, nu ar trebui să aveți prea multă încredere în mine. Aș fi recunoscător dacă oamenii cunoscători mă corectează, pentru că atunci voi învăța ceva. UPD.

În acest articol voi vorbi despre ce este un fișier WSDL, de ce este necesar și cum să lucrezi cu el.

Harta articolului

Ce este WSDL

WSDL este un limbaj de descriere a serviciului web care are Structura XML. Scopul principal al unui fișier WSDL este ca o interfață pentru accesarea funcțiilor de serviciu și tipurile de date returnate; calea către serverul de procesare a cererilor etc.

Calea către fișierul wsdl arată de obicei ca http://host/services/wsdl/gbdar-v2-2.wsdl

Există multe instrumente, biblioteci concepute pentru a citi un fișier WSDL.

SoapUi

Un astfel de instrument este soapUi(). Odată ce ați instalat distribuția proiectată pentru platforma dvs., puteți crea un nou proiect folosind comanda File/New SoapUi project. În caseta de dialog pentru crearea unui proiect nou, lăsați activată caseta de selectare Creare cereri de eșantion

Executarea interogărilor

În noul proiect, șabloanele de solicitare vor fi create automat pentru serviciu, a căror descriere este conținută în fișierul wsdl. În partea stângă în arbore veți vedea o listă de funcții conținute în fișierul WSDL. Voi expune funcția de replicare. În interiorul acestuia există o cerere Request1, făcând dublu clic pe care vom vedea un dialog cu un șablon de cerere, în locul parametrilor impliciti vor apărea semne de întrebare. Pentru ca funcția să se execute corect, trebuie să completați toți parametrii care nu sunt marcați cu eticheta Opțional și apoi să faceți clic pe triunghiul verde din colțul din stânga sus al casetei de dialog.

Dacă toți parametrii sunt specificați corect, răspunsul serviciului la cerere va apărea în dreapta.

SoapUi oferă posibilitatea de a vizualiza parametrii unui fișier WSDL pentru a face acest lucru, trebuie să faceți dublu clic pe numele interfeței (marcat cu o pictogramă verde în arborele de fișiere WSDL, pentru mine - gdbar-v2-2SOAP). În dialog puteți găsi:

• Fila Vedere generală - Descriere parametri generali WSDL, o listă de funcții și acțiuni asociate serverului
• Fila Service Endpoints — calea către server și alți parametri
• Conținut WSDL - arborele de navigare a fișierelor
• Conformitatea WS-I — aici puteți crea un raport WS-I pe interfață

Generarea documentatiei

SoapUi ne permite să generăm documentația funcției WSDL. Pentru a face acest lucru, faceți clic Click dreapta prin interfață și apelați comanda Generați documentație. Ca rezultat obținem manual detaliatîn format html.

Atât, abonați-vă la postări noi, lăsați comentarii, faceți sugestii pentru îmbunătățirea articolului.