Pe măsură ce Internetul a evoluat, a fost nevoie să se creeze aplicații distribuite. Aplicațiile instalate pe un computer folosesc de obicei bibliotecile găzduite pe acesta. O singură bibliotecă poate fi utilizată de mai multe programe. Este posibil să găzduiți analogi de biblioteci pe web, astfel încât diferite site-uri să le poată apela? Se dovedește că da.
Companiile oferă o varietate de informații pe paginile lor. De exemplu, de pe site-ul său http://www.Ford.com, compania Ford publică informații despre modele și prețuri. Dealerul acestei companii ar dori să aibă aceste informații pe site-ul lor. Un serviciu Web permite unui site de consumator să preia informații de la un site al furnizorului. Site-ul pentru consumatori afișează aceste informații pe paginile sale. Codul pentru generarea acestor informații este scris o singură dată, dar poate fi folosit de mulți consumatori. Datele sunt prezentate în text simplu, astfel încât pot fi utilizate indiferent de platformă.
Serviciile web sunt utilizate pe scară largă atât în aplicațiile desktop, cât și în aplicațiile de internet. Nu sunt aplicații în sine, ci surse de date pentru aplicații. Le lipsesc interfața cu utilizatorul. Serviciile web nu trebuie să fie utilizate pe web - ele pot face parte din proiectul în care sunt utilizate.
Serviciile web sunt funcționalități și date furnizate pentru utilizare de către aplicații externe care interacționează cu serviciile prin protocoale și formate de date standard. Serviciile web sunt complet independente de limbajul și platforma de implementare. Tehnologia serviciilor web este piatra de temelie a modelului de programare Microsoft. NET.
Aceasta este dezvoltare ulterioară programarea componentelor CORBA și DCOM. Cu toate acestea, pentru a utiliza astfel de componente, este necesar să le înregistrați în sistemul consumatorului. Acest lucru nu este necesar pentru serviciile web. Componentele funcționează bine în rețelele locale. Protocolul HTTP nu este potrivit pentru apelurile de procedură la distanță (RPC). Chiar și în cadrul aceleiași organizații, diferit Sisteme de operare, care poate comunica numai prin HTTP .
Au fost făcute mai multe încercări de a crea un limbaj de comunicare între sisteme eterogene - DCOM, CORBA, RMI, IIOP. Nu au câștigat acceptarea generală, deoarece fiecare a fost promovat de un producător diferit și, prin urmare, era legat de tehnologia unui anumit producător. Nimeni nu a vrut să accepte standardul altcuiva. Pentru a rezolva această dilemă, mai multe companii au convenit să dezvolte un standard independent de furnizor pentru mesageria prin HTTP. În mai 2000, IBM, Microsoft, HP, Lotus, SAP, UserLand și alții au apelat la W3C și au prezentat SOAP ca candidat pentru un astfel de standard. SOAP a revoluționat dezvoltarea aplicațiilor prin fuzionarea a două standarde de internet, HTTP și XML.
SĂPUN
Protocolul SOAP bazat pe XML este folosit pentru a interacționa cu serviciile web. Ar fi posibil să folosiți doar XML , dar acesta este un format prea liber, în care fiecare document își creează propriul limbaj. SĂPUN este o convenție despre formatul unui document XML, despre prezența anumitor elemente și spații de nume în acesta.
SOAP vă permite să publicați și să utilizați structuri complexe de date, cum ar fi un DataSet. În același timp, este ușor de învățat. Versiune curentă SAPUN-1.2.
SOAP este protocolul de acces simplu la obiect. SOAP este conceput pentru a facilita comunicarea aplicațiilor prin HTTP. Este un format special de mesagerie pe Internet, independent de platformă. Un mesaj SOAP este doar un document XML obișnuit. Standard
Partea lirică.
Imaginați-vă că ați implementat sau implementați un anumit sistem care ar trebui să fie disponibil din exterior. Acestea. există un anumit server cu care trebuie să comunicați. De exemplu, un server web.
Acest server poate efectua multe acțiuni, poate lucra cu baza de date, poate efectua unele solicitări de la terți către alte servere, poate face niște calcule etc. să trăiască și, eventual, să se dezvolte conform scenariului său bine-cunoscut (adică, conform scenariului dezvoltatorilor). Nu este interesant pentru o persoană să comunice cu un astfel de server, deoarece poate nu poate/nu vrea să ofere pagini frumoase cu imagini și alt conținut ușor de utilizat. Este scris și funcționează să funcționeze și să emită date la solicitările pentru acesta, fără să-i pese că acestea sunt lizibile de om, clientul se va ocupa singur de ele.
Alte sisteme, care accesează acest server, pot deja să dispună de datele primite de la acest server la propria discreție - procesează, acumulează, emit clienților lor etc.
Ei bine, una dintre opțiunile de comunicare cu astfel de servere este SOAP. Protocolul de mesagerie SOAP XML.
Partea practică.
Un serviciu web (așa oferă serverul și ceea ce folosesc clienții) face posibilă comunicarea cu serverul în mesaje bine structurate. Cert este că serviciul web nu acceptă date. Orice mesaj care nu se potrivește cu regulile va fi returnat de serviciul web cu o eroare. Eroarea va fi, de altfel, tot sub formă de xml cu o structură clară (ceea ce nu se poate spune adevărat despre textul mesajului).
WSDL (Web Services Description Language). Regulile prin care sunt compuse mesajele pentru serviciul web sunt descrise în același mod cu folosind xmlși au, de asemenea, o structură clară. Acestea. dacă un serviciu web oferă posibilitatea de a apela o metodă, acesta trebuie să permită clienților să afle ce parametri sunt utilizați pentru această metodă. Dacă serviciul web așteaptă un șir pentru metoda Method1 ca parametru și șirul trebuie să fie numit Param1, atunci aceste reguli vor fi specificate în descrierea serviciului web.
Nu doar tipurile simple, ci și obiectele, colecțiile de obiecte pot fi trecute ca parametri. Descrierea obiectului se reduce la descrierea fiecărei componente a obiectului. Dacă obiectul este format din mai multe câmpuri, atunci fiecare câmp este descris, ce tip are, numele (care sunt valorile posibile). Câmpurile pot fi, de asemenea, de tip complex, și așa mai departe, până când descrierea tipurilor se termină cu unele simple - șir, boolean, număr, dată... Totuși, unele tipuri specifice se pot dovedi a fi simple, este important ca clienții pot înțelege ce valori pot fi conținute în ei.
Pentru clienți este suficient să cunoașteți url-ul serviciului web, wsdl va fi mereu în apropiere, prin care vă puteți face o idee despre metodele și parametrii acestora pe care îi furnizează acest serviciu web.
Care sunt avantajele tuturor acestor clopote și fluiere:
- În majoritatea sistemelor, declararea metodelor și a tipurilor are loc în mod automat. Acestea. este suficient ca programatorul de pe server să spună asta aceasta metoda poate fi apelat printr-un serviciu web, iar descrierea wsdl va fi generată automat.
Validare automată.
- validare xml. xml trebuie să fie bine format. xml invalid - imediat o eroare pentru client, lăsați-l să-și dea seama.
- validarea schemei. xml trebuie să aibă o anumită structură. xml nu se potrivește cu schema - imediat o eroare pentru client, lăsați-l să-și dea seama.
- validarea datelor este efectuată de serverul soap, astfel încât tipurile de date și restricțiile să corespundă descrierii.
- Autorizarea și autentificarea pot fi implementate metoda separata. nativ. sau folosind autorizarea http.
- Serviciile web pot funcționa atât prin protocolul soap, cât și prin http, adică prin solicitări get. Adică, dacă sunt folosite date simple (fără o structură) ca parametri, atunci puteți apela pur și simplu get obișnuit www.site.com/users.asmx/GetUser?Name=Vasia sau post. Cu toate acestea, acest lucru nu este întotdeauna și peste tot.
- ... vezi wikipedia
O descriere care are o structură clară poate fi citită de orice client de săpun. Acestea. indiferent de serviciul web, clientul va înțelege ce date acceptă serviciul web. Conform acestei descrieri, clientul își poate construi propria sa structură internă de clase de obiecte, așa-numitele. binding” și. Ca rezultat, programatorul care folosește serviciul web trebuie să scrie ceva de genul (pseudocod):
NewUser:=TSoapUser.Create("Vasya","Pupkin","admin"); soap.AddUser(NewUser);
Există și o mulțime de dezavantaje:
- Dimensiunea mesajului nerezonabil de mare. Ei bine, aici însăși natura xml-ului este de așa natură încât formatul este redundant, cu cât mai multe etichete, cu atât mai multe informații inutile. În plus, săpunul se adaugă la redundanță. Pentru sistemele intranet, problema traficului este mai puțin acută decât pentru internet, așa că soap pt rețele locale mai solicitat, în special, Sharepoint are un serviciu web soap cu care poți comunica cu succes (și unele limitări).
- Schimbarea automată a descrierii serviciului web poate distruge toți clienții. Ei bine, este ca pentru orice sistem, așa că dacă nu este acceptată compatibilitatea cu vechile metode, totul va cădea...
- Nu un minus, ci un dezavantaj. Toate acțiunile de apel de metodă trebuie să fie atomice. De exemplu, atunci când lucrăm cu un subd, putem începe o tranzacție, executa mai multe interogări, apoi rollback sau commit. Nu există tranzacții în săpun. O cerere, un răspuns, conversația s-a încheiat.
- A face cu descrierea a ceea ce este pe partea de server (este totul descris corect de mine?), Ce este pe client (ce mi s-a scris aici?) Poate fi destul de dificil. Au fost de câteva ori când a trebuit să mă ocup de partea clientului și să-l conving pe programatorul de server că a descris greșit datele, dar nu a putut înțelege nimic din ele, deoarece generarea automată și el, așa cum ar fi, nu ar trebui, aceasta este o chestiune de software. Și eroarea a fost în mod natural în codul metodei, programatorul pur și simplu nu a văzut-o.
- Practica arată că dezvoltatorii de servicii web sunt teribil de departe de oamenii care folosesc aceste servicii web. Ca răspuns la orice solicitare (validă din exterior) poate apărea o eroare de neînțeles „Eroare 5. Totul este rău”. Totul depinde de conștiința dezvoltatorilor :)
- Sunt sigur că nu mi-am amintit nimic...
De exemplu, există un serviciu web belavia deschis:
- http://86.57.245.235/TimeTable/Service.asmx - punct de intrare, există și o descriere text a metodelor pentru dezvoltatorii terți.
- http://86.57.245.235/TimeTable/Service.asmx?WSDL - descrierea wsdl a metodelor și tipurilor de date primite și returnate.
- http://86.57.245.235/TimeTable/Service.asmx?op=GetAirportsList - descrierea unei metode specifice cu un exemplu de tip de solicitare xml și răspuns xml.
Puteți crea și trimite manual o solicitare precum:
POST /TimeTable/Service.asmx HTTP/1.1 Gazdă: 86.57.245.235 Tip de conținut: text/xml; charset=utf-8 Lungimea conținutului: lungime SOAPAction: „http://webservices.belavia.by/GetAirportsList”
raspunsul va fi:
HTTP/1.1 200 OK Data: Luni, 30 Sep 2013 00:06:44 GMT Server: Microsoft-IIS/6.0 X-Powered-By: ASP.NET X-AspNet-Versiune: 4.0.30319 Cache-Control: privat, max -age=0 Content-Type: text/xml; charset=utf-8 Lungimea conținutului: 2940
ZY Anterior, serviciul web Aeroflot a fost deschis, dar după ce 1C a adăugat suport pentru săpun în 8ku, o grămadă de testere beta 1c l-au instalat cu succes. Acum ceva s-a schimbat acolo (nu știu adresa, poți căuta dacă ești interesat).
Disclaimer ZZY. A vorbit la nivel de gospodărie. Poți bea.
Disclaimer:S-au scris o mulțime de articole pe această temă și, după cum, desigur, ați ghicit, acesta este altul. Poate că veți învăța ceva nou din el, dar nimic extrem de secret pe care nu ați putea căuta pe Google pe cont propriu nu este descris aici. Doar note din experiența personală.
Introducere
Vom lua în considerare doar situația în care există un serviciu web terță parte și sarcina este de a stabili schimbul de date.
Structura serviciului este descrisă în dosar WSDL(ing. Limbajul de descriere a serviciilor web)
Fișierul este accesat cel mai adesea printr-un link unde se află punctul de intrare către serviciul web în sine. Am scris „cel mai des” pentru că sunt excepții. De exemplu, un serviciu web bazat pe SAP nu publică un wsdl și poate fi preluat doar din aplicația în sine.
Și așa, avem o descriere a serviciului web, autentificare, parolă. Să ne conectăm.
// Definiți setările URL-ului ServiceNamespace = "http://Somesite.ru"; Nume utilizator = "TestUser"; Parola = "q1w2e3"; LocațieWSDL = "https://Somesite.ru/WebService/Some?wsdl"; ServiceName = "SomeServiceName"; ConnectionPointName = "SomeService_Port"; // Creați o conexiune SSL = New SecureConnectionOpenSSL(); WSDefinition = New WSDefinition(LocationWSDL,SSL); WSProxy = WSProxy nou (WSDefinition, ServiceNamspace URL, ServiceName, ConnectionPointName, SSL); WSProxy.User = Nume de utilizator; WSProxy.Password = Parolă;
Amenda! Ne-am conectat la serviciul web! În teorie, aceasta este baza oricărei opțiuni de schimb, deoarece vă permite să creați obiect structura de date bazat pe wsdl, iar lucrul cu un astfel de obiect este o plăcere.
Luați în considerare XML-ul pe care ni-l oferă SoapUI
Acum să o descriem programatic
// Creați un obiect și umpleți-l cu date OwnXDTOFactory = WSDefinition.XDTOFactory; RootType = OwnFactoryXDTO.Type(URLServiceNamespace, „SUBMISSION”); RootObject = OwnFactoryXDTO.Create(RootType); RootObject.ID = "4356"; ClientType = OwnFactoryXDTO.Type(URLServiceNamespace, „CUSTOMER”); ClientObject = OwnFactoryXDTO.Create(ClientType); ClientObject.CLIENT_ID = "121212"; ClientObject.SEX = "M"; // F - feminin, M - masculin ClientObject.CLIENT_BIRTHDAY = "19900111"; // AutoType Mașini Clienti = CustomFactoryXDTO.Type(URLServiceNamespace, "CARS"); AutoObject = OwnFactoryXDTO.Create(AutoType); AutoObject.CLASS = "Mercedes"; AutoObject.MODEL = "GLS"; ClientObject.CARS.Add(AutoObject); AutoObject = OwnFactoryXDTO.Create(AutoType); AutoObject.CLASS = "Audi"; AutoObject.MODEL = "TT"; ClientObject.CARS.Add(AutoObject); RootObject.CUSTOMER.Add(ClientObject);
Datele au fost finalizate cu succes. Acum trebuie să le trimitem.
Chiar în acest moment, apar multe nuanțe. Să încercăm să luăm în considerare fiecare.
Rețetă 1. Trimiterea întregului obiect XDTO
Rezultat = WSProxy.AddCustomers(RootObject);
Rămâne doar să procesăm rezultatul că serviciul ne-a returnat și atât. De acord că este foarte convenabil!
Dar, în practică, acest lucru nu este întotdeauna cazul. De exemplu, 1c nu se înțelege cu prefixarea anumitor etichete în interiorul xml atunci când spațiul de nume al etichetei rădăcină diferă de cel al etichetelor copil. În astfel de cazuri, trebuie să colectați manual săpunul. Am avut de-a face și cu servicii web care se așteaptă ca parametru xml pur. O nebunie, dar totuși nu este prea greu de făcut.
Rețeta 2. Trimiterea xml pur ca parametru
XMLRecordParameters = NewXMLRecordParameters("UTF-8", "1.0", True); MyXML = XMLWriter nou; MyXML.SetString(XMLRecordParameters); MyXML.WriteDeclarationXML(); CustomXDTOFactory.WriteXML(MyXML, RootObject); StringXML = MyXML.Close(); Dacă DeleteNamespaceDescription, atunci AttemptFirstTagInString = StrGetString(XMLString,2); RootTagName = RootObject.Type().Name; XMLString = StrReplace(XMLString, FirstTagInString, "<"+ИмяКорневогоТэга+">"); Excepție //ErrorDescription() EndTry; EndIf; Rezultat = WSProxy.AddCustomers(XML String);
Dacă nu eliminați spațiul de nume pe care 1s îl adaugă implicit, atunci acesta a devenit mai mult decât doar 5 linii de cod. De cele mai multe ori, împachetez transformarea xml într-o funcție, deoarece de obicei numim mai multe metode.
Rețetă 3. Trimiteți prin Solicitare HTTP nativă.
șir SOAP = "În această opțiune, va trebui să construim manual săpunul. În esență, pur și simplu împachetăm xml-ul din rețeta 2 într-un ambalaj de săpun, unde, în funcție de cerințele serviciului web, ne putem schimba săpunul după pofta inimii.
În continuare, descriem anteturile conform documentației. Unele servicii vor mesteca cu ușurință cererea noastră fără antete, aici trebuie să vă uitați la un caz specific. Dacă nu știți ce anteturi să prescrie, atunci cea mai simplă modalitate este să aruncați o privire la cerere în SoapUI, trecând la fila RAW.
Funcția pentru obținerea șirului Base64 arată astfel (peeped):
Funcția GetBase64AuthorizationHeader(Nume utilizator, Parolă) FileEncoding = TextEncoding.UTF8; TempFile = GetTemporaryFileName(); Înregistrare = New TextWrite (TemporaryFile, FileEncoding); Scrie.Scrie(Nume utilizator+":"+Parolă); Record.Close(); BinData = New BinaryData(TempFile); Rezultat = Base64String(DvData); DeleteFiles(TempFile); Rezultat = Avg(Rezultat,5); Rezultat returnat; EndFunctions
Există un punct important. Când lucrați cu HTTPConnection, specificați adresa fără a specifica protocoalele „http://” și „https://”, altfel riscați să pierdeți timpul căutând o eroare neevidentă.
Rețetă 4. Trimitere prin WinHttpRequest
WinHttp = New COMObject("WinHttp.WinHttpRequest.5.1"); WinHttp.Option(2,"UTF-8"); WinHttp.Option(4, 13056); //intSslErrorIgnoreFlag WinHttp.Option(6, true); //blnEnableRedirects WinHttp.Option(12, true); //blnEnableHttpsToHttpRedirects WinHttp.Open(„POST”, „https://Somesite.ru/WebService/Some/GetCustomer”, 0); WinHttp.SetRequestHeader(„Tipul de conținut”, „text/xml”); WinHttp.SetCredentials(Nume utilizator, Parolă, 0); WinHttp.Send(Șirul SOAP); WinHttp.WaitForResponse(15); XMLResponse = WinHttp.ResponseText();Aici, de fapt, la fel ca în versiunea anterioară, dar lucrăm cu un COMObject. Specificăm șirul de conexiune în întregime, împreună cu protocolul. O atenție specială ar trebui acordată numai steagurilor pentru ignorarea erorilor din certificatele SSL. Sunt necesare dacă lucrăm prin SSL, dar fără un certificat specific, deoarece nu este posibil să se creeze o nouă conexiune securizată în această opțiune (sau nu știu cum). Restul mecanismului este similar cu cel precedent.
De asemenea, pe lângă „WinHttp.WinHttpRequest.5.1”, puteți folosi „Microsoft.XMLHTTP”, „Msxml2.XMLHTTP”, „Msxml2.XMLHTTP.3.0”, „Msxml2.XMLHTTP.6.0”, dacă brusc nu durează dezactivat pe WinHttp. Metodele sunt aproape aceleași, doar numărul de parametri este diferit. Bănuiesc că una dintre aceste opțiuni este conectată în interiorul obiectului HTTPRequest 1c.
În acest moment, acestea sunt toate rețetele pe care le am. Dacă dau peste altele noi, cu siguranță voi completa articolul.
Prelucrarea rezultatelor
În rețeta 1, obținem cel mai adesea un obiect XDTO gata făcut și lucrăm cu el ca structură. În toate celelalte cazuri, puteți converti răspunsul xml în XDTO
Dacă Result.StatusCode = 200, atunci XMLReader = New XMLReader; ReadingXML.SetString(Result.GetBodyAsString()); ResponseObject = OwnFactoryXDTO.ReadXML(ReadingXML); Raport (ObjectResponse.Body.Response.RESPONSE_ID); Raport (ObjectResponse.Body.Response.RESPONSE_TEXT); EndIf;
Totul este simplu aici.
În loc de o concluzie
1. Începeți să lucrați cu serviciile web cu programul SoapUI. Este conceput pentru o astfel de muncă și vă va permite să înțelegeți rapid cum funcționează un anumit serviciu. Există un articol de învățat
2. Dacă faceți schimb cu un serviciu printr-un canal http nesecurizat și apare întrebarea ce anume trimite 1s în mesajele dvs., atunci puteți utiliza sniffer de trafic, cum ar fi Wireshark, Fiddler și altele. Problema apare numai dacă utilizați o conexiune ssl.
3. Dacă, totuși, serviciul web comunică prin https, atunci instalăm serverul Nginx pe o mașină la distanță (orice, cel mai important, nu pe cont propriu), pe care o vom contacta și, la rândul său, va împacheta totul în https și trimiteți-l la locul potrivit ( proxy invers ) și adăugați la configurația standard:
Server ( asculta 0.0.0.0:8080; server_name MyServer; locație ~ .* ( proxy_pass https://Somesite.ru:8001; proxy_set_header Gazdă $host; proxy_set_header Autorizare „De bază
5. Dacă autentificarea implică utilizarea Cookie-urilor, atunci s-au găsit următoarele
P.S. Dacă aveți întrebări, sugestii pentru îmbunătățirea codului, aveți propriile rețete care diferă de cele descrise, găsiți erori sau credeți că autorul „greșește” și „nu aparține în 1”, atunci scrieți comentarii și vom discuta Tot.
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ă de la distanță, trebuie să descrieți acest apel în fișier XML e 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 numit 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
Rulați IDEA și creați proiect nou 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. LA 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, // indicând numele complet al clasei 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= serviciu. 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 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ă 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
În acest subiect, a fost prezentată o scurtă excursie în 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. As fi recunoscator daca oameni cunoscători Voi fi corectat, pentru că atunci voi învăța ceva. UPD.Alexey Boyko
Servicii web SOAP și XML în .Net
Serviciile web XML oferă un nivel de interoperabilitate și interoperabilitate în ceea ce privește sistemele de operare,
platforme și limbi care anterior erau pur și simplu indisponibile.
Andrew Troelsen (Cel mai valoros profesionist din Microsoft MVP)
Dacă nu ați lucrat încă cu XML Web Services, probabil că ați auzit cuvântul „SOAP”. Este timpul să ne ocupăm de aceste concepte.
introducere
Dacă sunteți interesat de internet sau de rețele mai mici, sunt șanse să întâlniți serviciile web XML mai devreme sau mai târziu. Un serviciu web XML este mai mult decât o simplă aplicație web capabilă să afișeze informații într-un browser. Mai degrabă, este o tehnologie de telecomandă care vă permite să apelați metode și proprietăți ale unui obiect din rețea folosind cereri HTTP standard.
În practică, aceasta înseamnă că clienții unui astfel de serviciu pot fi scrisi în diferite limbi și pentru diferite sisteme de operare.
Ca „transport” de informații între serviciu și client, puteți utiliza metodele HTTP GET sau POST.
Și puteți „impone” un alt protocol deasupra - SOAP (Simple Object Access Protocol). Acest lucru se face de obicei, deoarece în acest caz este posibil să treceți tipuri complexe (inclusiv cele definite de utilizator). Iar metodele clasice GET și POST acceptă doar liste, matrice simple și șiruri de caractere.
Exemplu de comunicare SOAP
Un mesaj SOAP este un document XML plasat în corpul unei solicitări HTTP.
Lista 1. Structura mesajului SOAP
Interacțiunea dintre client și serviciu este următoarea:
- clientul formează o cerere SOAP și o trimite serviciului;
- service activat computer la distanță execută procedura și trimite un răspuns SOAP.
De exemplu, o solicitare SOAP care apelează metoda HelloWorld() a unui serviciu web XML la distanță ar putea arăta astfel:
Lista 2. Exemplu de solicitare SOAP
Metoda HelloWorld(), așa cum era de așteptat, returnează șirul „Hello world!”:
Lista 3. Exemplu de răspuns SOAP
Xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
Crearea unui serviciu web XML în .NET 2.0
Puteți crea un serviciu căi diferite, vom folosi Visual Studio 2005. Faceți clic pe „File -> New -> Web Site”, în fereastra care se deschide, selectați „ASP.NET web Service”. La adresa specificată în timpul creării, veți găsi următoarele fișiere și directoare (vezi Fig. 1).
În principiu, un serviciu poate conține un singur fișier *.asmx. (Extensia *.asmx este folosită pentru a desemna serviciile web .Net.) În acest caz, nu este cazul, uitați-vă la conținutul fișierului Service.asmx:
Lista 4. Service.asmx definește fișier extern a sustine
<%@ WebService Language="C#" CodeBehind="~/App_Code/Service.cs" class="Service" %>
Atributul CodeBehind specifică un fișier extern situat în folderul App_Code care conține codul programului care implementează metoda HelloWorld():
Lista 5. Fișier Service.cs care implementează metoda HelloWorld().
folosind System;
folosind System.Web;
folosind System.Web.Services;
serviciu public ()
Întoarceți „Hello World”;
Este posibil să creați un singur fișier Service.asmx fără cod de suport care are aceeași funcționalitate:
Lista 6. Service.asmx fără cod de suport extern
<%@ WebService Language="C#" class="Service" %>
folosind System;
folosind System.Web;
folosind System.Web.Services;
folosind System.Web.Services.Protocols;
Serviciu de clasă publică: System.Web.Services.WebService
serviciu public ()
Șir public HelloWorld() (
Întoarceți „Hello World”;
Nu avem nevoie de ea și nu o vom face.
După cum puteți vedea, singura metodă a serviciului nostru web este marcată cu atributul care informează runtime-ul ASP.NET că această metodă este disponibilă pentru solicitările HTTP primite. Membrii care nu sunt marcați cu acest atribut nu vor fi disponibili pentru programele client.
Un astfel de serviciu simplu este destul de potrivit pentru experimentele noastre, rămâne doar să-l publicăm.
Publicarea unui serviciu web XML utilizând IIS
Nu va fi vorba despre publicarea pe Internet, ci despre crearea condițiilor pentru testarea serviciului nostru pe un computer local.
Mai întâi, instalați IIS (Internet Information Server). Pentru a face acest lucru, deschideți fereastra „Adăugați sau eliminați programe” și selectați „Instalare Componentele Windows". (Niste versiuni Windows nu necesită instalarea IIS, cum ar fi Windows XP Home Edition.)
Notă: Server IIS este mai bine să instalați mai devreme decât .Net Framework, altfel va trebui să configurați IIS pentru a suporta aplicațiile .Net rulând utilitarul Linie de comanda aspnet_regiis.exe (cu steag-ul /i).
Creați un director virtual. Dacă utilizați Windows XP Pro, accesați „Panou de control -> Instrumente administrative -> Servicii de informare pe Internet”. În fereastra care se deschide, selectați „Acțiune -> Creare -> Director virtual”.
Va porni Virtual Directory Creation Wizard. Specificați Soap1 ca alias și setați calea către directorul în care doriți să plasați serviciul, de exemplu C:\Soap1. Acum copiați conținutul serviciului nostru web acolo.
Tastați http://localhost/soap1/Service.asmx în bara de adrese a browserului dvs. și ar trebui să vedeți pagina de testare a serviciului (vezi Figura 2).
Vizualizarea mesajelor SOAP
Pagina de testare nu permite trimiterea și citirea mesajelor SOAP. Din acest motiv, va trebui să utilizați dezvoltare terță parte, vă recomand să utilizați soapUI. (Acesta este un produs gratuit disponibil la http://www.soapui.org.)
Odată ce soapUI este instalat, creați un nou proiect numit soap1, lăsând câmpul WSDL inițial gol (vezi Figura 3).
Faceți clic dreapta pe proiectul nou creat și selectați „Adăugați WSDL de la URL”. În caseta de dialog care se deschide, introduceți http://localhost/soap1/Service.asmx?wsdl. Acum avem capacitatea de a trimite cereri SOAP către serviciul nostru și de a vedea răspunsurile primite. (Solicitările vor fi generate automat de soapUI.)
Ce este acest WSDL? Documentul WSDL descrie modul în care clienții pot interacționa cu un serviciu web. Descrie ce metode de service sunt disponibile pentru apelul extern, ce parametri iau și ce returnează, precum și alte informații necesare pentru telecomandă. Un astfel de document poate fi compilat manual, sau puteți încredința generarea lui serverului, pentru aceasta este suficient să adăugați sufixul ?wsdl la adresa URL care indică fișierul *.asmx.
Pentru a vizualiza documentul WSDL pentru serviciul nostru, introduceți http://localhost/soap1/Service.asmx?wsdl în browser. Informațiile din acest document sunt folosite de soapUI pentru a genera automat solicitări SOAP.
Extensii SOAP
După cum probabil ați observat, pentru a crea un serviciu web XML (precum un client) nu trebuie să vă faceți griji cu privire la forma mesajelor SOAP. Este suficient să marcați metodele dorite cu atributul, iar runtime-ul ASP.NET va compune singur pachetele cu formatul dorit.
Pe fig. Figura 4 prezintă o solicitare de serviciu web și un răspuns primit folosind programul soapUI.
Să o repetăm din nou. Solicitarea este generată de soapUI - atunci când creați clienți reali pentru serviciu, de asemenea, nu trebuie să formatați manual pachetele SOAP. De asemenea, nu am participat direct la crearea răspunsului serviciului. Toate acestea se întâmplă automat.
Cu toate acestea, probabil că va trebui să modificați singur aceste pachete. De exemplu, pentru a comprima sau a cripta datele transmise. Acesta este scopul extensiilor SOAP.
Extensiile SOAP este un mecanism care vă permite să modificați în mod arbitrar mesajele SOAP primite și trimise.
Calea unui mesaj SOAP
Pentru a începe programarea, trebuie să luăm în considerare calea pe care o parcurge un mesaj SOAP înainte de a fi primit și procesat prin metoda adecvată (vezi Figura 5).
Un mesaj SOAP poate fi gândit ca un document XML care descrie un obiect transmis prin rețea. Înainte ca un obiect trecut în acest mod să poată fi folosit, acesta trebuie restaurat (sau, dacă preferați, asamblat) din această descriere. Un serializator XML servește acestui scop.
Pachetele primite sunt deserializate (restaurând un obiect dintr-o descriere XML), iar pachetele trimise sunt serializate (creând o descriere XML a unui obiect).
Pe fig. Figura 5 prezintă patru puncte (BeforeSerialize, AfterDeserialize, BeforeDeserialize, AfterSerialize) în care putem intercepta un mesaj SOAP utilizând extensiile SOAP. Modificați-l și trimiteți-l mai departe.
Implementarea extensiei SOAP
Mai întâi, să definim sarcina: să presupunem că vrem să schimbăm pachetele SOAP trimise de serviciul web așa cum se arată în Lista 7:
Lista 7. Răspunsuri de serviciu web XML „vechi” și noi
Xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
Xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> Text cifrat
Plan de acțiune pentru implementarea extensiei SOAP:
- Creăm un dll cu o clasă care moștenește de la SoapExtension.
- Adăugăm folderul bin la serviciul nostru web și punem acolo dll-ul creat.
- Adăugați un fișier web.config la serviciu și faceți-i modificările necesare.
Rolul folderului bin și al fișierului web.config va fi discutat mai târziu.
Crearea unui DLL cu extensia SOAP
Creați un nou proiect „Bibliotecă de clasă” numit SoapExtensionLib. Acest proiect va trebui să implementeze o singură clasă care va efectua modificările la pachetele SOAP de care avem nevoie. Această clasă trebuie să fie derivată din clasa SoapExtension.
Lista 8. Crearea unei clase care moștenește de la SoapExtension
folosind System;
folosind System.Web.Services;
folosind System.Web.Services.Protocols;
folosind System.IO;
folosind System.Net;
folosind System.Xml;
Fiecare extensie SOAP primește ca parametru un flux care conține un obiect transmis prin rețea (înainte sau după serializare). Și trebuie să returneze fluxul.
Extensia SOAP poate fi gândită ca o „bară laterală” care poate fi plasată în unul sau în toate cele patru puncte (BeforeSerialize, AfterDeserialize, BeforeDeserialize, AfterSerialize) prezentate în Figura 2. 5. Poate exista orice număr de astfel de „inserții” în fiecare punct (vezi Fig. 6).
Pentru a obține aceste fluxuri, utilizați metoda ChainStream.
Lista 9. Implementarea metodei ChainStream
clasă publică TraceExtension: SoapExtension
Stream wireStream;
Stream appStream;
// metoda ca parametru de intrare
// primește fluxul care conține obiectul transmis
Înlocuire publică Stream ChainStream(Stream stream)
WireStream = flux;
AppStream = nou MemoryStream();
return appStream;
…
La punctul BeforeDeserialize, wireStream conține cererea SOAP primită de la rețea. Această solicitare SOAP trebuie să fie transmisă fluxului de aplicație (fluxul appStream).
Și în punctul AfterSerialize, trebuie să transmiteți răspunsul SOAP trimis în rețea către fluxul wireStream, care va fi plasat în appStream.
Pentru a lucra cu fire în fiecare dintre cele patru puncte, trebuie să implementați metoda ProcessMessage.
Lista 10. Implementarea metodei ProcessMessage care nu modifică mesajele SOAP
// ProcessMessage care face o copie obligatorie
// transmite în flux în două puncte (BeforeDeserialize și AfterSerialize)
Comutare (mesaj.etapă)
// la punctul BeforeDeserialize trebuie trecut
// Solicitare SOAP de la un flux de rețea (wireStream)
// la fluxul aplicației (appStream)
Case SoapMessageStage.BeforeDeserialize:
Copiere (wireStream, appStream);
AppStream.Position = 0;
pauză;
// în punctul AfterSerialize trebuie trecut
// Răspuns SOAP de la firul de aplicare la firul de rețea
AppStream.Position = 0;
pauză;
void Copy(Transmite în flux de la, Transmite în flux către)
Cititor TextReader = new StreamReader(de la);
TextWriter writer = new StreamWriter(to);
Writer.WriteLine(reader.ReadToEnd());
Writer.Flush();
Lista 10 poate fi luată ca un gol pentru experimente ulterioare. Această implementare a metodei ProcessMessage nu are sens - răspunsul SOAP de ieșire nu este modificat în niciun fel. Să reparăm asta:
Lista 11. Implementarea metodei ProcessMessage care modifică răspunsul SOAP
public override void ProcessMessage (mesaj SoapMessage)
Comutare (mesaj.etapă)
Case SoapMessageStage.AfterSerialize:
WriteOutput(mesaj);
pauză;
// o parte din cod tăiată pentru a economisi spațiu
// rescrie răspunsul SOAP
public void WriteOutput (mesaj SoapMessage)
AppStream.Position = 0;
// creează un document XML din flux
XmlDocument document = nou XmlDocument();
Document.Load(appStream);
// Pentru a utiliza XPath, trebuie să definiți
// NamespaceManager
XmlNamespaceManager nsmgr = nou XmlNamespaceManager(document.NameTable);
Nsmgr.AddNamespace("soap", "http://schemas.xmlsoap.org/soap/envelope/");
XmlNode ResultNode = document.SelectSingleNode("//soap:Body", nsmgr);
// înlocuiește conținutul nodului
ResultNode.InnerText = "text cifrat";
// șterge fluxul și scrie un nou răspuns SOAP la acesta
AppStream.SetLength(0);
AppStream.Position = 0;
Document.Save(appStream);
// ACȚIUNE NECESARĂ
// transmiteți răspunsul SOAP din fluxul de aplicație (appStream)
// în fluxul de rețea (wireStream)
AppStream.Position = 0;
Copiere (appStream, wireStream);
În continuare, trebuie să definim două metode (dintre care una este supraîncărcată, adică poate fi apelată cu seturi diferite de parametri), care nu sunt necesare în cazul nostru. Totuși, trebuie să le definim conform regulilor de moștenire din clasa SoapExtension.
Lista 12. Alte metode obligatorii
// În conformitate cu regulile de moștenire, trebuie
// definim aceste metode, dar nu le folosim în niciun fel
obiect de anulare publică?
GetInitializer (InfoMetoda LogicăInfoMetoda, atributul SoapExtensionAttribute)
returnează nul;
obiect de suprascriere public GetInitializer(Tip WebServiceType)
returnează nul;
public override void Initialize (inițializator obiect)
întoarcere;
Totul, alcătuim proiectul. În sfârșit, am primit dll-ul SOAP Extension. O listă completă a SoapExtensionLib.dll este disponibilă pe site-ul revistei în secțiunea Cod sursă.
Configurarea unui serviciu web pentru a funcționa cu extensia SOAP
Deschideți din nou proiectul nostru XML Web Service cu Visual Studio. Faceți clic pe „WebSite -> Add Reference” și selectați SoapExtensionLib.dll pe care l-ați creat mai devreme.
Dosarul Bin va fi adăugat automat la proiect. Fișierele *.dll aflate în folderul Bin sunt referite automat de către aplicație.
Acum puneți fișierul Web.Config în directorul serviciului web cu următorul conținut:
Lista 13. Fișier Web.Config
Priority="1" Group="0" />
Acum structura serviciului nostru arată așa cum se arată în Fig. 7. Folosind fișierul Web.Config, informăm mediul ASP.NET că am adăugat serviciului web XML Soap Extension, implementat în clasa TraceExtension aflată în fișierul SoapExtensionLi.dll. Listarea 14. Secțiunea webServices din fișierul Web.Config Priority="1" Group="0" />
După cum știți deja, puteți face mai multe extensii SOAP, iar fluxul care poartă obiectul trecut (înainte sau după serializare) va trece prin fiecare dintre ele. Ordinea în care un flux traversează diferitele extensii SOAP este specificată folosind atributele de prioritate și grup. Este de remarcat faptul că, configurând Web.Config în acest fel, informăm mediul că extensia noastră SOAP va fi apelată pentru fiecare metodă de serviciu marcată cu atributul. Este posibil să vă creați propriul atribut și să marcați cu el doar acele metode pentru care trebuie să apelați extensia SOAP. Lista 15. Exemplu de atribut personalizat șir public HelloWorld() ( Întoarceți „Hello World”; Pentru a face acest lucru, adăugați o clasă moștenită de la SoapExtensionAttribute la SoapExtensionLi.dll (vezi Figura 8). Concluzie Acest articol reflectă principalele puncte de construire și funcționare a serviciilor web XML pe platforma .Net. Sper că materialul prezentat va fi suficient pentru ca, dacă este necesar, să puteți face un studiu mai profund al subiectului. In contact cu
