Cândva, mi s-a dat sarcina de a începe dezvoltarea serviciilor Web și mi-a dat planurile pentru cel mai simplu proiect fără nicio explicație. Proiectul, desigur, nu a început. Ce este primăvara și cum funcționează, nici nu aveam idee. De asemenea, nu am putut găsi articole adecvate despre dezvoltarea serviciilor Web folosind Spring, nici în rusă, nici în engleză. A trebuit să mă ocup eu de toate, s-a dovedit că totul nu era atât de înfricoșător.
Și recent, m-am hotărât să văd ce funcții noi au fost adăugate la Spring de atunci și să actualizez serviciile vechi, ceea ce, ca urmare, m-a determinat să scriu acest articol.
Acest articol este un ghid pentru dezvoltarea unui serviciu web simplu folosind protocolul SOAP folosind Spring-WS.
Și așa, vom scrie cel mai simplu serviciu Un care acceptă un nume de utilizator și trimite un salut și ora curentă pe server.
De ce vom avea nevoie?
- IDE. Eu folosesc eclipse.
Pregătirea pentru muncă
Noi creăm proiect nou aplicații web. În Eclipse este: „File => New => Dynamic Web Project”.Am numit proiectul: HelloService.
Apoi, copiați bibliotecile din Spring, XMLBean, wsdl4j, commons-logging în directorul de proiect WEB-INF/lib.
Dacă doriți, le puteți adăuga în bibliotecile serverului pentru a nu le transporta cu fiecare aplicație.
Crearea unei scheme WSDL
În esență, o schemă WSDL este destinată să descrie un serviciu.Desigur, nu îl vom crea manual. Schema va fi generată automat de instrumentele Spring, dar mai multe despre asta mai târziu.
Definiți datele de intrare și de ieșire
Date de intrare:- Nume șir.
- Salutare șir;
- Ora ora curenta.
Creăm o descriere a datelor de intrare și de ieșire
În directorul WEB-INF, creați fișierul HelloService.xsd. Acest fișier va fi necesar pentru a genera schema WSDL și pentru a crea clasele Java corespunzătoare.Textul fișierului:
Atribut targetNamspace- spațiul de nume de utilizat. Acestea. toate obiectele create vor fi localizate în pachetul org.example.helloService.
Elemente Solicitare serviciuȘi ServiceResponse descrieți datele de intrare și respectiv de ieșire (cerere/răspuns).
Atribute minApareȘi maxApare determina numărul de repetări ale unei componente date în cadrul unui element. Dacă acești parametri nu sunt specificați, atunci implicit sunt considerați egali cu 1. Pentru o componentă opțională, trebuie să specificați minOccurs=0. Cu un număr nelimitat de componente: maxOccurs=unbounded.
Puteți citi mai multe despre Schemele XML.
Crearea JavaBeans
Pe baza schemei create, vom crea clase Java. Pentru a face acest lucru, creați un fișier build.xml:Parametru WS_HOME trebuie să indice directorul în care se află XMLBeans.
HelloService.xsd- calea către schema creată.
lib\helloservice.jar- se creează biblioteca java.
Apoi, rulați Ant-build (sper că l-ați instalat deja).
În Eclipse, îl puteți rula astfel: RMB pe fișierul build.xml => Run As => Ant Build.
Dacă prin Linie de comanda:
ant-buildfile build.xml
Ei bine, așteptăm finalizarea construcției. După aceea, putem verifica directorul proiectului WEB-INF\lib pentru prezența bibliotecii corespunzătoare (helloservice.jar).
Implementarea serviciului
Creați o interfață și o clasă de servicii
Interfață de serviciu: HelloService.java:pachet org.example; import java.util.Calendar; interfața publică HelloService ( public String getHello(Nume șir) aruncă o excepție; public Calendar getCurrentTime(); )
Implementarea serviciului: HelloServiceImpl.java:
pachet org.example; import java.util.Calendar; import org.springframework.stereotype.Service; Clasa publică @Service HelloServiceImpl implementează HelloService ( public String getHello(String name) aruncă Excepție ( return „Hello, " + name + "!"; ) public Calendar getCurrentTime() ( return Calendar.getInstance(); ) )
Acest cod, cred, nu are nevoie de comentarii. Singurul lucru care poate pune întrebări persoanelor care nu au mai întâlnit Spring este adnotarea @ Service. Dar voi vorbi despre asta puțin mai târziu.
punctul final
Endpoint - o clasă care va fi responsabilă pentru procesarea cererilor primite (un fel de punct de intrare).Creați fișierul HelloServiceEndpoint.java:
pachet org.example; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.ws.server.endpoint.annotation.Endpoint; import org.springframework.ws.server.endpoint.annotation.PayloadRoot; import org.example.helloService.ServiceRequestDocument; import org.example.helloService.ServiceRequestDocument.ServiceRequest; import org.example.helloService.ServiceResponseDocument; import org.example.helloService.ServiceResponseDocument.ServiceResponse; @Endpoint clasă publică HelloServiceEndpoint( private static final String namespaceUri = "http://www.example.org/HelloService"; privat HelloService helloService; @Autowired public void HelloService (HelloService helloService) ( this.helloService = helloService; ) @PayloadRoot( localPart = "ServiceRequest", namespace = namespaceUri) public ServiceResponseDocument getService(ServiceRequestDocument request) aruncă o excepție ( ServiceRequestDocument reqDoc = cerere; ServiceRequest req = reqDoc.getServiceRequest(); ServiceResponseDocument respDoc = ServiceResponseDocument.Respons. addNewServiceResponse(); String userName = req.getName(); String helloMessage = testNewService.getHello(userName); Calendar currentTime = testNewService.getCurrentTime(); resp.setHello(helloMessage); resp.setCurrentTime(currentTime); return respDoc; ) )
Ce se face aici?
adnotare @endpoint stabilește doar că această clasă va procesa cererile primite.
namespaceUri– același spațiu de nume specificat la crearea schemei xml.
Acum să ne întoarcem puțin și să ne amintim despre adnotare @ Serviciu. Fără a intra în detalii, pentru a nu supraîncărca cititorul cu informații inutile, atunci această adnotare îi spune lui Spring să creeze obiectul potrivit. Și adnotarea @Cablat automat servește pentru injecție înlocuire automată) a obiectului corespunzător. Desigur, atunci când construiești aplicații simple, nu are rost să folosești aceste adnotări, dar tot am decis să nu le exclud în acest exemplu.
În rest, din nou, totul ar trebui să fie clar. Rețineți că ServiceRequest, ServiceResponse etc. - acestea sunt doar clasele care au fost create pe baza schemei noastre xml.
Configurarea serviciului de primăvară
Aici se apropie sfârșitul.Creați un fișier service-ws-servlet.xml.
sws:adnotare-driven- spune doar asta în acest proiect se folosesc adnotări.
DAR context:component-scan specifică pachetul pentru a căuta adnotări, inclusiv subpachete.
Următoarele două coșuri vor fi întotdeauna aceleași. Esența lor constă în primirea și convertirea unei cereri din Xml într-un obiect Java și apoi convertirea acesteia înapoi.
sws:dynamic-wsdl răspunzător de generare automată Document WSDL bazat pe schema XML generată.
Locație indică calea către schemă.
locatieUri– adresa (relativă la container) unde va fi disponibilă schema WSDL.
În cazul meu, WSDL este disponibil la următoarea adresă:
localhost/HelloService/HelloService.wsdl
Descriptor de implementare
Și în sfârșit, ultimul.În directorul WEB-INF, schimbăm sau creăm un fișier web.xml.
Nu voi mai descrie acest fișier, majoritatea oamenilor ar trebui să știe deja. Pentru proiecte simple, în esență nu ar trebui să se schimbe. Este de remarcat doar că numele servlet-ului (servlet-name) trebuie să se potrivească cu numele fișierului de configurare Spring al serviciului serviciu ws-servlet.xml.
Control medical
Chiar primul semn funcționare corectă este schema WSDL generată.Pentru a verifica, mergeți la adresa acestei scheme (http://localhost/HelloService/HelloService.wsdl) și uitați-vă: acolo ar trebui să fie afișat un fișier xml. Dacă nu se afișează nimic sau ce eroare a apărut, recitim cu atenție întregul articol și căutăm ce am greșit.
Pentru o verificare suplimentară, avem nevoie de soapUI (am versiunea 3.0.1).
Instalați-l și rulați-l.
Creați un nou proiect: Fișier => Nou proiect soapUI. În câmpul WSDL/WADL inițial, inserați un link către schema WSDL (http://localhost/HelloService/HelloService.wsdl).
În proiectul creat, deschideți cererea necesară. 
În câmpul Nume, introduceți un nume și faceți clic pe butonul „Trimite cererea”. 
Ca rezultat, primim un răspuns de la server cu un salut și ora curentă. 
Dacă ceva a mers prost, atunci recitiți acest articol din nou.
Ce urmeaza?
Ei bine, atunci trebuie să scriem un client pentru acest serviciu web. Dar acesta este deja material pentru un alt articol, care poate fi scris mai târziu, dacă materialul dat cineva va fi interesat.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 de mai jos va funcționa, cu toate acestea, frazele mele vor fi doar presupuneri și presupuneri despre cum înțeleg eu însumi toate acestea. Deci să mergem...
Introducere
Trebuie să începem cu ce a fost creat conceptul de servicii web. Până la apariția acestui concept, în lume existau deja tehnologii care permiteau aplicațiilor să interacționeze la distanță, unde un program putea apela o metodă într-un alt program, care putea fi apoi lansată pe un computer situat într-un alt oraș sau chiar țară. Toate acestea sunt prescurtate ca RPC (Remote Procedure Calling - apel de procedură la distanță). Exemplele includ tehnologiile CORBA, iar pentru Java - RMI (Remote Method Invoking - remote method invocation). Și totul pare să fie bine în ei, mai ales în CORBA, pentru că poț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 va trece prin orice firewall. Ideea unui serviciu web a fost de a crea un astfel de RPC care să fie împins în pachete HTTP. Astfel a început dezvoltarea standardului. Care sunt conceptele de bază ale acestui standard:- 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 doar unul dintre numeroasele markupuri XML utilizate în serviciile web. Tot ceea ce dorim să trimitem undeva prin HTTP este mai întâi transformat într-o descriere XML SOAP, apoi introdus într-un pachet HTTP și trimis către un alt computer din rețea prin TCP/IP.
- WSDL. Există un serviciu web, adică un program ale cărui metode pot fi apelate de la distanță. Dar standardul cere ca acestui program să fie atașată o descriere, care spune că „da, nu v-ați înșelat - acesta este într-adevăr un serviciu web și puteți apela astfel de metode din acesta”. Această descriere este reprezentată de un alt fișier XML care are alt format și anume WSDL. Acestea. WSDL este doar un fișier XML care descrie un serviciu web și nimic altceva.
Abordare generală
Serviciile web au întotdeauna un client și un server. Serverul este serviciul nostru web și uneori este denumit punctul final (cum ar fi, punctul final, unde ajung mesajele SOAP de la client). Trebuie să facem următoarele:- Descrieți interfața serviciului nostru web
- Implementați această interfață
- Porniți serviciul nostru web
- Scrieți un client și apelați de la distanță metoda de serviciu web dorită
Server
Lansați IDEA și creați un nou proiect Creați un nou proiect. Specificați un nume hellowebserviceși apăsați butonul Următorul, apoi butonul finalizarea. În dosar src creați un pachet ro.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 // spune că serviciul web va fi folosit pentru a apela metode@SOAPBinding(style = SOAPBinding.Style.RPC) interfață publică HelloWebService( // spune 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, adică. a apela metoda. Să implementăm logica interfeței noastre și să creăm o clasă HelloWebServiceImpl în pachetul nostru. Apropo, observ că clasa care se termină 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 și pentru descrierea interfeței, import javax. jws. serviciu web; // dar aici este folosit cu parametrul endpointInterface, // arătând Numele complet clasa de interfață a serviciului nostru web@WebService(endpointInterface= „en.javarush.ws.HelloWebService”) clasa publică HelloWebServiceImpl implementează HelloWebService ( @Override public String getHelloString (nume șir) ( // returnează doar salutul returnează "Bună ziua, " + nume + "!" ; ) ) Să rulăm serviciul nostru web ca server autonom, de ex. 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 haideți să creăm un pachet ru.javarush.endpoint și în el vom crea o clasă HelloWebServicePublisher cu metoda main: package ru. javarush. punct final; // clasă pentru a porni un server web cu servicii web import javax. xml. ws. punct final; // clasa serviciului nostru web import en. 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 rulați 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 http://localhost:1986/wss/hello?wsdl în browser. Pagina deschisă, 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ă descrierea WSDL a serviciului nostru web. Dacă opriți aplicația, descrierea va deveni inaccesibilă, precum ș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; // o astfel de excepție va apărea când lucrați cu obiectul URL import java. net. MalformedURLException; // clase pentru a analiza xml cu descrierea wsdl // și atingeți 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 en. javarush. ws. hellowebservice; clasă publică HelloWebServiceClient( public static void main(String args) aruncă MalformedURLException( // creează un link către descrierea wsdl url= URL nou ( „http://localhost:1986/wss/hello?wsdl”) ; // Ne uităm la parametrii următorului constructor din prima etichetă de descriere WSDL - definiții // uită-te la primul argument din atributul targetNamespace // Al doilea argument se uită în atributul nume 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 la eticheta de port imbricată în ea, astfel încât // obțineți o referință la un obiect de serviciu web aflat la distanță de la noi HelloWebService hello = serviciu. getPort(HelloWebService.class) ; // Ura! Acum poți suna metoda de la distanta 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ă rulați (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 thread prezentat scurtă digresiune la serviciile web. Încă o dată, mare parte din ceea ce am scris este presupunerea mea despre cum funcționează și, prin urmare, nu ar trebui să am prea multă încredere în mine. Aș fi recunoscător dacă oamenii cunoscători mă corectează, pentru că atunci voi învăța ceva. UPD.WSDL (Limbajul de descriere a serviciilor web) versiunea 1.1 a fost publicată pe 15 martie 2001. WSDL este un format bazat pe XML folosit pentru a descrie serviciile web folosind mesaje care conțin informații despre cum să accesați un anumit serviciu web. WSDL este extensibil pentru a permite descrierea serviciilor (serviciilor) și a mesajelor acestora, indiferent de formatele de mesaje sau protocoalele de rețea utilizate pentru transport, totuși, WSDL 1.1 este cel mai frecvent utilizat împreună cu SOAP 1.1, HTTP GET/POST și MIME. În măsura în care WSDL a fost dezvoltat în comun cu SOAP, la fel Microsoft, Ariba și IBM. Dacă ne uităm la document WSDL intuitiv, se poate spune că permite raspunde la 4 intrebari:
1) ce faci? Răspunsul la această întrebare este dat într-o formă potrivită atât pentru percepția umană, cât și pentru forma percepută de o mașină. Răspuns pentru persoanele din etichete:<Nume/>, <documentație/>, pentru mașină -<mesaj/>, <pointType>
2) Ce limba vorbesti? (ce tipuri folosești?) Răspuns în etichetă:<tipuri/>
3) Cum voi comunica cu tine? (cum va accesa clientul serviciul web?): HTTP sau SMTP. Răspunsul este în<legare/>
4) unde te pot găsi? (unde pot găsi acest serviciu web sau care este adresa URL a acestuia?). Raspunsul este:<serviciu/>
Structura:
Fiecare document WSDL poate fi împărțit în trei părți logice:
1. definirea tipurilor de date - definirea tipului de mesaje trimise și primite de serviciul XML
2. operații abstracte - lista de operatii care pot fi efectuate asupra mesajelor
3. obligatoriu de serviciu - modul în care va fi transmis mesajul
Documentele WSDL poate fi creat manual, dar formalizarea strictă a limbajului WSDL vă permite să automatizați procesul de scriere WSDL-documente. Multe instrumente de creare a serviciilor Web conțin utilitare care creează automat WSDL-fișiere care descriu servicii Web gata făcute. De exemplu, Web Services Authoring Tool Apache Axis conţine o clasă Java2WSDL, crearea WSDL-fișier după clasa Java sau interfața care descrie serviciul Web. Pachetul IBM WSTK, care include Axă, conține utilitate java2wsdl A care creează și pornește un obiect din această clasă. Funcționează din linia de comandă.
Elementele unui document WSDL
Să descriem cele mai frecvent utilizate etichete WSDL:
Etichetă
1) spațiu de nume țintă este spațiul de nume al serviciului nostru web
2)xmlns - spațiu de nume de document WSDL standard
3)xmlns: SOAP_ENC este spațiul de nume folosit pentru a descrie codificarea SOAP
4) xmlns: impl și intf - spațiul de nume al implementării și definiției serviciului nostru web
・Document de definire a serviciului web
・Document pentru implementarea serviciului web
Pentru simplitate, de regulă, se folosește 1 fișier, care conține toate informațiile
Element
Pentru a descrie un apel RPC, trebuie să creați un mesaj de intrare și un mesaj de ieșire.
În cadrul acestui element, puteți specifica parametrii metodei folosind elementul
Element
Operațiile pot avea mesaje de intrare, precum și mesaje de eroare.
Element
Element
Element import . Foarte des, elementul de serviciu este separat în documentul său wsdl din motive practice.
Pentru a vă permite să asamblați un document wsdl din mai multe documente, este folosit elementul de import. Vă permite să includeți un document wsdl în altul.
Element tipuri vă permite să specificați tipurile de date transmise dacă acestea nu sunt standard.
WSDL acceptă 4 moduri de operare:
operațiuni unidirecționale sau operațiuni unidirecționale. Mesajul este trimis la punctul final al serviciului. În acest caz, operația este descrisă de un singur mesaj de intrare.
· Request-Response—mod cerere-răspuns. Acest mod de operare este cel mai comun. În acest mod, descrierea operațiunii conține un mesaj de intrare și de ieșire și un mesaj de eroare opțional.
· Operațiune de tip cerere-răspuns. În acest mod, punctul final este un client al altui punct final. Formatul operației este similar cu modul provocare-răspuns, dar datele de ieșire sunt listate înaintea datelor de intrare.
· Aviz de operare. Acest mod este o altă versiune a primitivei de transmisie unidirecțională în care punctul final trimite mesajul mai degrabă decât să-l primească. Operația conține doar un mesaj de ieșire.
cuvânt înainte
Clienții clienților le-au cerut clienților fișiere xsd pentru structurile trecute de serviciile Web implementate. Clienții ca răspuns au sugerat ca clienții clienților să facă WSDL-uri. Acea. în mod neașteptat, „din senin” a devenit necesar să se realizeze nu doar scheme xsd pentru validarea datelor, ci „WSDL-uri întregi”. De obicei, WSDL-urile sunt folosite pentru SOAP și avem REST...
Am mai scris despre
Introducere
Termenul de servicii web este de obicei asociat cu servicii bazate pe operațiuni sau acțiuni bazate pe standarde SOAP sau WS*, cum ar fi WS-Addressing sau WS-Security. Termenul REST Web Services se referă de obicei la o arhitectură bazată pe resurse a serviciilor Web care transmit XML prin HTTP. Fiecare dintre aceste stiluri arhitecturale are propriul loc, dar până de curând, standardul WSDL nu a acceptat ambele stiluri. Prin urmare, legarea HTTP WSDL 1.1 a fost inadecvată pentru a descrie comunicarea folosind XML peste HTTP. nu a existat o modalitate formală de a descrie serviciile web REST folosind WSDL. Publicarea standardului WSDL 2.0 (care a fost dezvoltat având în vedere necesitatea de a descrie serviciile web REST) ca recomandare mondială rețeaua largă Consorțiul (W3C) a oferit un limbaj pentru descrierea serviciilor Web REST.
REST este un stil arhitectural care tratează Web-ul ca pe o aplicație centrată pe resurse. Practic, aceasta înseamnă că fiecare URL dintr-o aplicație RESTful este o resursă. Adresele URL sunt ușor de înțeles și de reținut. De exemplu, o librărie poate defini adresa URL http://www.bookstore.com/books/ pentru o listă de cărți de vânzare și http://www.bookstore.com/books/0321396855/ pentru detalii despre o anumită carte cu ISBN 0321396855. Acest lucru contrastează cu aplicațiile centrate pe acțiune, de obicei cu adrese URL lungi, greu de criptat, care descriu acțiunile care trebuie efectuate, cum ar fi http://www.bookstore.com/action/query?t=b&id=11117645532&qp =0321396855 . Parametrii de interogare sunt utilizați pentru a selecta datele necesare. Folosind exemplul de librărie, specificarea parametrului subiect restricționează subiectul cărții. De exemplu, fizică sau povești polițiste sau, de exemplu, adresa URL http://www.bookstore.com/books/?subject=computers/eclipse - o solicitare care returnează o listă de cărți despre platforma Eclipse.
Termenul REST a fost inventat de Roy Fielding în teza sa de doctorat. El a văzut hyperlinkurile ca pe un mijloc de schimbare (stocare) a stării unei aplicații. Hyperlinkurile sunt stocate în resursele aplicației și reprezintă o metodă de schimbare a stării aplicației, redirecționând de la o stare la alta. De obicei, hyperlinkurile în (X)HTML sunt destinate uzului uman, nu au fost folosite în XML, care a fost destinat procesării automate. La fel ca (X)HTML, serviciile Web REST folosesc hyperlinkuri în XML.
Aplicațiile web tradiționale accesează resursele prin operațiuni HTTP GET sau POST. Aplicațiile RESTfull funcționează cu resurse de stil „creați, citiți, actualizați și ștergeți (CRUD)” folosind complete Capabilitati HTTP protocol (POST, GET, PUT și DELETE).
Un alt notă importantă despre aplicația REST: aplicațiile RESTful ar trebui să fie apatride. Aceasta înseamnă că aplicația REST nu stochează nicio stare de sesiune pe partea serverului. Toate informațiile necesare pentru a îndeplini o solicitare sunt transmise în cererea în sine. (Prin urmare, serverul trebuie să răspundă solicitărilor repetate în același mod, nota traducătorului). În consecință, clientul poate stoca în cache resursele primite, ceea ce poate accelera semnificativ viteza aplicației acolo unde serviciul o permite în mod explicit. Pentru a afla mai multe despre REST, consultați linkurile către articol.
WSDL și REST
WSDL conține toate detaliile despre serviciul web, inclusiv:
- adresa URL a serviciului web
Mecanisme de comunicare pe care serviciul web le înțelege
Operații pe care le poate efectua un serviciu web
Structura mesajelor serviciului web
Clienții pot folosi detaliile enumerate pentru a interacționa cu serviciul.
WSDL 2.0 a fost declarată recomandare W3C în iunie 2007. Această versiune a standardului WSDL a fost lansată pentru a aborda problemele din standardul WSDL 1.1, multe dintre ele fiind descoperite de Web Services Interoperability (WS-I). În plus, WSDL 2.0 are suport îmbunătățit pentru legăturile HTTP.
WSDL în sine este XML - un subset care descrie în mod oficial un serviciu web. Gândiți-vă la descrierea WSDL a unui serviciu web ca la contractul său API cu clientul. WSDL specifică adresa, metodele de comunicare valide, interfața și tipurile de mesaje ale serviciului web. Pe scurt, descrierea WSDL conține toate informațiile de care un client are nevoie pentru a consuma un serviciu web.
Aplicabilitatea WSDL depășește utilizarea sa ca contract API. Fiind o definiție formală, WSDL poate fi utilizat de software care simplifică implementarea serviciilor web pentru operațiuni precum:
- Generaţie cod sursa aplicație client și server pentru un serviciu web în diferite limbaje de programare
- Publicarea unui serviciu web
- Testare dinamică a serviciului web
Majoritate instrumente software pentru lucrul cu serviciile web includ suport pentru WSDL 1.1. În ultima vreme există un număr tot mai mare de instrumente de dezvoltare a serviciilor web care acceptă WSDL 2.0. Proiect Apache Web servicii constă din două subproiecte care suportă în prezent WSDL 2.0. Woden este un parser WSDL 2.0 bazat pe Java. Proiectul Apache Web Services oferă, de asemenea, o transformare XSL (XSLT) WSDL 2.0 numită WSDL 2.0 drăguță imprimantă, care oferă o mai bună lizibilitate umană a documentului WSDL. Axis2 este un motor de servicii web popular (tot de la Apache) care generează cod Java client și server dintr-un document WSDL 2.0.
Descrierea unui serviciu web REST utilizând WSDL 2.0
Creați o librărie care are o adresă URL promovată: http://www.bookstore.com . Ați creat deja două servicii web REST:
- lista de carti- serviciul primește o listă cu cărțile vândute de dvs.
- detalii carte - serviciul primește informații despre o anumită carte.
Răspunsul este returnat în documente XML.
Element interfata definește o listă de operațiuni ale serviciului web, inclusiv o descriere a mesajelor de intrare, de ieșire și de eroare pentru operațiuni, precum și ordinea în care sunt transmise.
Element legare definește mijloacele de comunicare între client și serviciul web. În cazul serviciilor web REST, HTTP este specificat ca mijloc de comunicare.
Elementul de serviciu asociază adresele de servicii web cu interfețe specifice (interfață) și mijloace de comunicare (legare). (adică se potrivește cu adresa URL a operațiunii serviciului web și cu elementul legare).
Legarea listei de cărți la HTTP
Element legare specifică legarea unui serviciu web la un anumit protocol de transfer de date. Pentru a lega serviciul de listă de cărți la HTTP, trebuie să specificați valoarea http://www.w3.org/ns/wsdl/http pentru atribut tip element legare.
Element legare se poate referi opțional la interfata. Lăsați atributul interfata gol. Îl vei crea în secțiunea următoare. Dacă interfata asociat cu legare, apoi legare un element poate defini opțional un element copil Operațiune, care este o oglindă pentru operarea interfeței element. Trebuie să creați un element stub Operațiune si completati linkul Operațiune mai târziu după creaţie interfata.
Există 4 metode de comunicare HTTP
- ȘTERGE
Serviciul Book list citește cererea și funcționează în consecință cu un HTTP GET. Instalare metoda GET pentru elementul operatioin folosind atributul method din spațiul de nume HTTP WSDL 2.0. Pentru a utiliza acest atribut, trebuie mai întâi să definiți spațiul de nume http://www.w3.org/ns/wsdl/http pe element Descriere.
Lista de cărți Serviciul de legare este definit în lista următoare. Specificați acum legareîn element punctul final:tns:BookListHTTPBinding.
Definiția operațiunii de serviciu de listă de cărți
Până acum ați învățat cum să vă adresați și să comunicați cu serviciu web de listă de cărți. Apoi specificați operațiunea serviciului de listă de cărți, care descrie ce serviciul de liste de cărți nu.
Deci, ați învățat cum să setați adresa și să setați legarea (metoda de comunicare) pentru serviciul web. Apoi, trebuie să definiți o operațiune de serviciu care definește ceea ce face serviciul web cu listă de cărți.
Elementul de interfață și elementul său de operare copil sunt utilizate pentru a defini operațiunile de serviciu. În cazul listei de cărți, definiți o singură operație getBookList care returnează o listă de cărți.
Apoi definiți trei atribute pe elementul de operare:
model
Folosit pentru a specifica modelul de schimb de mesaje model de schimb de mesaje(MEP) pentru operațiune. MEP definește succesiunea de mesaje pentru o operațiune și direcția acestora. În acest caz, trebuie să specificați valoarea http://www.w3.org/ns/wsdl/in-out pentru a indica faptul că serviciul web primește un mesaj de intrare care solicită o listă de cărți și trimite un mesaj de ieșire cu un lista de carti. Pentru a sprijini acest europarlamentar, specificați elemente copil intrareȘi ieșire pentru element Operațiune. Aceste elemente folosesc elementele descrise în schema XML pentru a defini structurile mesajelor. Detalii în secțiunea următoare.
stil
Folosit pentru a indica informatii suplimentare Cu privire la locul de muncă. Specificați valoarea http://www.w3.org/ns/wsdl/style/iri , care impune restricții asupra conținutului elementelor de intrare, cum ar fi solicitarea ca acesta să utilizeze numai elemente de schemă XML.
wsdlx:sigur
wsdlx:safe: Din spațiul de nume al extensiilor WSDL, acest atribut declară că această operație este idempotent. Acest tip de operație nu modifică resursa și, prin urmare, poate fi apelată de mai multe ori cu aceleași rezultate. Pentru a utiliza acest element, declarați spațiul de nume al extensiilor WSDL http://www.w3.org/ns/wsdl-extensions pe elementul descriere.
Acest atribut provine din spațiul de nume de extensii WSDL. Se precizează că operațiunea este idempotent. Această operațiune nu modifică resursa, așa că poate fi apelată de mai multe ori cu aceleasi rezultate. Pentru a utiliza acest element, trebuie să declarați extensiile WSDL ale spațiului de nume http://www.w3.org/ns/wsdl-extensions în elementul rădăcină (elementul descriere).
Puteți găsi modelele de schimb de mesaje, stilurile și definițiile wsdlx:safe predefinite la WSDL 2.0 Part 2: Adjuncts
Mai jos este definiția serviciului de liste de cărți cu o descriere adăugată interfata. După adăugarea unei interfețe, acum puteți schimba elementul de operare de legare pentru a specifica legături către cele descrise interfataȘi Operațiune.
Definirea mesajelor de operare a listei de cărți
Serviciul web de listă de cărți utilizează două mesaje: intrare și ieșire. Trebuie să descrieți structurile acestor mesaje, astfel încât programele client să știe ce să trimită la adresa serviciului și la ce să se aștepte înapoi.
WSDL 2.0 acceptă mai multe sisteme de tip pentru descrierea conținutului mesajului, dar schema XML este singura utilizată. Această secțiune nu acoperă detaliile schemei XML. Schema XML este folosită în multe alte aplicații, cum ar fi WSDL 1.1, și există multe articole bune despre aceasta. Această secțiune evidențiază cum să utilizați schema XML pentru serviciul Web REST pentru lista de cărți și cum să utilizați atribute suplimentare definite de WSDL 2.0 pentru a adnota un atribut de schemă.
WSDL 2.0 acceptă multe sisteme de definire a tipurilor, dar în practică este folosită doar schema XML. Acest articol nu intră în detaliile schemei XML. Schema XML este folosită în multe alte aplicații, cum ar fi WSDL 1.1 și există multe articole bune despre el. (). Această secțiune demonstrează, aplicarea XML schema aplicată la exemplu concret REST al serviciului de listă de cărți, precum și utilizarea atributelor suplimentare definite în WSDL 2.0 pentru adnotarea atributelor schemei.
Pentru a descrie 2 mesaje pentru lista de cărți, trebuie să descrii 2 elemente globale.
- getBookList reprezintă mesajul de intrare. Conține o secvență de elemente, inclusiv fiecare parametru de interogare permis pentru serviciu: autor, titlu, editor, subiectȘi limba. În interiorul mesajului getBookList, numai elemente pot fi utilizate deoarece stilul IRI este ales pentru operarea interfeței.
- lista de carti reprezintă mesajul de ieşire. Conține o secvență de elemente de carte. Fiecare element de carte conține, la rândul său, atribute titlu și URL. Atributul titlului se explică de la sine. Atributul URL este un link către serviciul de detalii despre carte care returnează informații detaliate despre o anumită carte.
Definiția atributului dvs. URL utilizează la rândul său 2 atribute din spațiul de nume al extensiilor WSDL. Atributele wsdlx:interfață și wsdlx:binding specifică interfața și legarea pentru serviciu. Software poate folosi aceste informații pentru a găsirea automată serviciu. Pentru a utiliza aceste atribute, specificați spațiul de nume al extensiilor WSDL pentru element schemă. Includeți, de asemenea, spațiul de nume cu detaliile cărții din descrierea sa WSDL 2.0.
Schema XML pentru serviciul de liste de cărți este prezentată mai jos.
Pentru a face referire la elementele de intrare și de ieșire, trebuie să importați schema în documentul dumneavoastră WSDL. Pentru a importa o schemă, utilizați elementul de import de schemă din secțiunea tipuri, așa cum se arată în lista de mai jos. În plus, trebuie să adăugați referințe la elementele getBookList și Booklist în elementele de intrare și ieșire ale operațiunii de interfață și să adăugați spațiile de nume ale schemei XML din lista de cărți la elementul rădăcină WSDL.
Pregătiți WSDL pentru serviciul web de listă de cărți.
Nota traducătorului
Mi-am luat libertatea de a nu traduce rezumatul și linkurile. Amândoi se uită la autor. în articolul original. Trebuie să spun că limba originală este foarte grea. Totuși, sper că articolul este de ajutor.
În acest articol, voi vorbi despre ce este un fișier WSDL, de ce aveți nevoie de el și cum să lucrați cu el.
Harta articolului
Ce este WSDL
WSDL este un limbaj de descriere a serviciului web care are o structură XML. Scopul principal al unui fișier WSDL este de a oferi o interfață pentru accesarea funcțiilor de serviciu returnate de tipurile de date; calea către serverul de procesare a cererilor etc.
Calea către fișierul wsdl este de obicei http://host/services/wsdl/gbdar-v2-2.wsdl
Există multe instrumente, biblioteci, concepute pentru a citi fișierul WSDL.
SoapUi
Un astfel de instrument este soapUi(). După instalarea kit-ului de distribuție conceput pentru platforma dvs., puteți crea un nou proiect cu comanda File/New SoapUi project. În caseta de dialog pentru crearea unui proiect nou, lăsați bifată caseta de selectare Creare cereri de eșantion
Executarea interogărilor
Noul proiect va genera automat șabloane de solicitare pentru serviciul descris în fișierul wsdl. În partea stângă a arborelui veți vedea o listă de funcții conținute în fișierul WSDL. Voi extinde funcția de replicare. În interiorul ei 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 fi puse 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 corecti, răspunsul serviciului la cerere va apărea în partea dreaptă.
SoapUi oferă posibilitatea de a vizualiza parametrii fișierului WSDL, pentru aceasta trebuie să faceți dublu clic pe numele interfeței (marcat cu o pictogramă verde în arborele fișierului WSDL, am gdbar-v2-2SOAP). În dialog puteți găsi:
- Fila Prezentare generală - o descriere a parametrilor generali WSDL, o listă de funcții și acțiuni de server aferente
- 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 de interfață WS-I
Generarea documentelor
SoapUi ne permite să generăm documentație pentru funcțiile WSDL. Pentru a face acest lucru, faceți clic dreapta pe interfață și apelați comanda Generați documentație. Drept urmare, obținem un manual detaliat în format html.
Atât, abonați-vă la noi intrări, lăsați comentarii, faceți sugestii pentru a îmbunătăți articolul.
