Serviciu Wsdl. Definiția operațiunii de serviciu de listă de cărți

Pagina 2 din 3

Descriere folosind WSDL

SOAP funcționează foarte bine dacă se știe totul despre serviciul Web. Cu toate acestea, acest lucru nu este întotdeauna cazul. Mijlocul de descriere a interfeței pentru accesarea unui serviciu Web este limbajul WSDL (Web Services Description Language). Acest standard a fost dezvoltat în comun de IBM, Microsoft și webMethods. Fiecare dintre aceste trei companii a avut propria abordare pentru a dezvolta un standard pentru descrierea serviciilor Web: IBM a creat NASSL, Microsoft a dezvoltat SCL, iar webMethods a creat WIDL.

Rezultatul colaborării lor a fost versiunea 1.1 a limbajului WSDL.În ceea ce privește W3C, trebuie menționat că, ca și în cazul SOAP, consorțiul W3C bazat pe versiunea 1.1 a dezvoltat WSDL 1.2, care este acum o recomandare W3C. Descrierea WSDL a unui serviciu Web conține toate informațiile necesare utilizării serviciului, inclusiv metodele disponibileși parametrii acestora. Aceste informații sunt cuprinse în următoarele cinci elemente:

• - protocoale suportate.
• - Mesaje de serviciu web (cerere, răspuns).
• Toate metodele disponibile.
• - URI serviciu.
• - tipuri de date utilizate.

Toate aceste informații sunt stocate în elementul rădăcină al descrierii WSDL Lista de mai jos prezintă un exemplu de descriere WSDL a unui serviciu Web.

Descrierea WSDL a serviciului Web

Da... nu vă puteți da seama fără un pahar, dar acesta este unul dintre cele mai simple (!) fișiere WSDL. Din păcate, unul dintre dezavantajele extensiei SOAP pentru PHP 5 este că, spre deosebire de alte implementări SOAP, nu generează automat descrieri WSDL (cel puțin nu încă). Cu siguranță acest defect va fi corectat în versiunile viitoare de PHP.

Apropo!

Pentru a genera automat descrierea WSDL, puteți utiliza implementări alternative ale protocolului SOAP în PHP:

Căutare în director folosind UDDI

Acum că știm cum să obținem informații despre un serviciu web și cum să-l interogăm, trebuie să învățăm cum să găsim un astfel de serviciu. În acest scop există ceva asemănător Paginilor Aurii și anume registrele UBR (Registrele Universale de Afaceri) - directoare de servicii web.

Există mai multe astfel de registre, inclusiv cele ale IBM, Microsoft, NTT-Com și SAP. Aceste registre își sincronizează datele, astfel încât să puteți utiliza oricare dintre ele. Versiunea actuală a standardului UDDI este UDDI 3.0, deși majoritatea implementărilor folosesc versiunea 2. Dezvoltatorii acestui standard includ companii gigantice precum HP, Intel, Microsoft și Sun.

Pentru a interacționa cu UBR există două tipuri de API: Inquiry API și Publish API. Interfață Inquiry API (Solicitare) este pentru solicitare servicii în registrele UBR și interfața Publish API permite dezvoltatorilor să-și înregistreze serviciile. Se pare că este doar o chestiune de timp până când conținutul registrelor se umple cu spam :)

Apropo!

Există registre de testare concepute pentru a testa înregistrările de servicii înainte de a le plasa în registrele „adevărate”.

Iată cum arată o solicitare de serviciu web:

sortByNameAsc sortByDateDesc %guid%

În exemplul de mai sus, puteți vedea că cererea UDDI este încapsulată într-un mesaj SOAP, așa că pare destul de familiar. Răspunsul la cerere este, de asemenea, un document SOAP, prezentat mai jos:

Tur ghidat al serviciilor web Exemple de servicii web pentru ghidul de turism Tur ghidat Serviciul de cotații

Instalare

Instalarea extensiei SOAP pentru PHP5 este destul de ușoară. Pe Windows, acest modul se află în subdirectorul ext al directorului de instalare PHP. Pentru a-l folosi, trebuie să adăugați următoarea linie la fișierul php.ini: extensie=php_soap.dll Pentru a funcționa, acest modul necesită ca acesta să fie inclus implicit în PHP 5, cel puțin în versiunea Windows.

Cum definește WSDL 1.1 serviciile Web și cum se creează modele Java pentru a verifica și transforma documentele WSDL

Seria de conținut:

Despre această serie de articole

Serviciile web sunt o caracteristică importantă a tehnologiei Java™ în calcularea întreprinderii. În această serie de articole, consultantul în XML și servicii Web Denis Sosnovsky vorbește despre principalele structuri și tehnologii valoroase pentru dezvoltatorii Java care folosesc serviciile Web. Urmărește articolele din serie pentru a fi la curent cu cele mai recente evoluții din acest domeniu și pentru a ști cum să le aplici în propriile proiecte.

Serviciile web pentru aplicațiile de întreprindere se bazează în mare măsură pe utilizarea definițiilor serviciilor. Definițiile serviciului descriu acordul de bază dintre furnizorul de servicii și orice consumator potențial, detaliind tipurile de funcții furnizate de serviciu și mesajele din cadrul fiecărei funcții. Furnizorii și consumatorii sunt liberi să aleagă cum să-și implementeze obiectele de schimb în măsura în care mesajele efective pe care le trimit corespund definiției serviciului. Utilizarea unei definiții de serviciu care descrie modul în care sunt schimbate mesajele XML este ceea ce distinge serviciile Web de tehnologiile anterioare de programare distribuită.

Au fost propuse diferite metode pentru definirea serviciilor Web, dar WSDL 1.1 rămâne abordarea cea mai utilizată. WSDL 1.1 are unele deficiențe, inclusiv o structură prea complexă care face dificilă citirea pentru cei neinițiați. De asemenea, suferă de lipsa unei definiții formale cu autoritate, ceea ce a dus la „rafinări” succesive care umple unele dintre lacunele din documentul de specificație original. Ca rezultat, stivele de servicii Web încearcă să gestioneze documentele WSDL 1.1 cât mai flexibil posibil. Această flexibilitate poate adăuga confuzie în înțelegerea WSDL 1.1, deoarece dezvoltatorii văd o gamă largă de structuri WSDL fără nicio indicație despre care abordare este de preferat.

În acest articol, vă vom arăta cum să analizați documentele WSDL 1.1 și să privim primele părți ale modelului Java pentru validarea documentelor WSDL și convertirea lor în formă standard.

Analizarea WSDL 1.1

Spații de nume utilizate

Acest articol folosește:

• prefix wsdl pentru a reprezenta spațiul de nume WSDL 1.1 http://schemas.xmlsoap.org/wsdl/ ;
• prefixul soap pentru spațiul de nume http://schemas.xmlsoap.org/wsdl/soap/ utilizat de extensia SOAP 1.1 pentru WSDL 1.1;
• xs pentru spațiul de nume http://www.w3.org/2001/XMLSchema utilizat pentru definițiile schemelor XML.

Revizia 1.1 a WSDL, publicată la începutul anului 2001, a fost înlocuită din punct de vedere tehnic de recomandările W3C WSDL 2.0, publicate în 2007. WSDL 2.0 oferă o structură mai curată decât WSDL 1.1 împreună cu o flexibilitate mai mare. Dar WSDL 2.0 suferă de o problemă de găină și ouă: WSDL 2.0 nu este utilizat pe scară largă pentru că nu este acceptat pe scară largă și, pentru că nu este utilizat pe scară largă, dezvoltatorii de stive de servicii Web au puține stimulente să îl susțină. În ciuda tuturor deficiențelor sale, WSDL 1.1 este suficient de bun pentru majoritatea scopurilor.

Specificația originală WSDL 1.1 a fost imprecisă în ceea ce privește numărul de funcții utilizate. Deoarece obiectivul WSDL era să lucreze cu definițiile serviciului SOAP, a inclus și suport pentru caracteristici SOAP (cum ar fi codificarea rpc) care ulterior s-au dovedit a fi nedorite. Web Services Interoperability Organization (WS-I) a abordat aceste probleme în Profilul de bază (BP), care oferă îndrumări practice pentru serviciile Web care utilizează SOAP și WSDL. BP 1.0 a fost aprobat în 2004, iar BP 1.1 a fost lansat în 2006. Acest articol acoperă WSDL 1.1 pe baza recomandărilor WS-I BP și nu se referă la caracteristicile actuale depreciate, cum ar fi codificarea rpc pentru SOAP.

Se presupune că structura documentelor XML este specificată de definițiile Schemei XML. Specificația originală WSDL 1.1 a inclus o descriere a schemei, dar schema nu se potrivește cu descrierile textuale în mai multe privințe. Acest lucru a fost corectat ulterior într-o versiune modificată a schemei, dar documentul WSDL 1.1 nu a fost editat pentru a reflecta această modificare. Echipa BP WS-I a decis apoi să facă și mai multe modificări la schema WSDL și a creat ceea ce sunt prezentate drept ghiduri practice pentru această schemă alunecoasă. Documentele scrise pentru o versiune a unei scheme nu sunt, în general, compatibile cu alte versiuni (în ciuda utilizării aceluiași spațiu de nume), dar, din fericire, majoritatea instrumentelor de servicii web ignoră în mare parte schema și acceptă orice pare rezonabil. (Vezi link-uri către multe scheme WSDL în secțiune).

Chiar și versiunea BP WS-I a schemei WSDL 1.1 nu face mare lucru pentru a asigura conformitatea cu specificațiile documentelor WSDL 1.1. Diagrama nu reflectă toate limitările WS-I BP, în special în ceea ce privește ordinea componentelor. În plus, schema XML nu poate gestiona multe tipuri de constrângeri ușor stabilite în documente (cum ar fi atribute alternative sau elemente suplimentare necesare dintr-o schemă separată). Prin urmare, verificarea conformității unui document WSDL 1.1 cu specificația WSDL 1.1 (așa cum a fost modificată de BP WS-I) implică mult mai mult decât doar efectuarea validării schemei XML. Vom reveni la acest subiect mai târziu în acest articol. Dar mai întâi, să ne uităm la structura descrierilor de servicii WSDL 1.1.

Descriere Componente

Documentele WSDL 1.1 folosesc un element rădăcină fix, denumit convenabil . În cadrul acestui element rădăcină, spațiul de nume WSDL 1.1 definește un element copil „pasiv” (pur și simplu o legătură către documente WSDL 1.1 individuale) și cinci elemente „active”. elemente copil(care constituie de fapt descrierea serviciului):

• face referire la un document WSDL 1.1 separat cu descrieri care trebuie incluse în acel document;
• definește tipurile sau elementele XML utilizate pentru mesagerie;
• definește mesajul real în termeni de tipuri sau elemente XML;
• definește un set abstract de operațiuni efectuate de serviciu;
• definește implementarea efectivă folosind protocoale și formate specifice;
• definește serviciul ca un întreg, incluzând de obicei unul sau mai multe elemente cu informații de acces pentru elemente .

Există și un element , care poate fi folosit în scopuri de documentare ca prim element copil , precum și primul copil al oricăruia dintre elementele de mai sus.

O descriere completă a unui serviciu necesită de obicei cel puțin un element din fiecare dintre aceste tipuri, cu excepția , dar nu trebuie să fie toate în același document. Pentru a asambla un WSDL complet din mai multe documente, puteți utiliza , care permite subdivizarea descrierilor pentru a se potrivi nevoilor organizației. De exemplu, primele trei elemente ale descrierii ( , Și ) împreună constituie o descriere completă a interfeței de serviciu (poate definită de grupul de arhitectură), deci este logic să le păstrăm separate de elementele orientate spre implementare Și . Toate stivele de servicii web majore acceptă împărțirea descrierilor în mai multe documente WSDL.

Lista 1 prezintă un exemplu de descriere a serviciului WSDL împărțită în două documente WSDL, astfel încât componentele de descriere a interfeței să fie conținute în fișierul BookServerInterface.wsdl, iar componentele de implementare să fie conținute în fișierul BookServerImpl.wsdl. Lista 1 arată BookServerInterface.wsdl.

Lista 1. BookServerInterface.wsdl

Definirea interfeței serviciului de carte. ... ... Implementarea serviciului de carte. Aceasta creează o bibliotecă inițială de cărți atunci când clasa este încărcată, apoi acceptă apeluri de metodă pentru a accesa informațiile bibliotecii (inclusiv adăugarea de cărți noi). Obțineți cartea cu un anumit ISBN. ... Adăugați o carte nouă.

Lista 2 arată BookServerImpl.wsdl. Element la început importă descrierea interfeței BookServerInterface.wsdl.

Lista 2. BookServerImpl.wsdl

Definiția implementării efective a serviciului de carte. ...

Pe lângă definițiile elementelor (și atributelor) din spațiul de nume WSDL 1.1, WSDL 1.1 definește și elemente suplimentare. Acestea sunt concepute pentru a umple anumite celule din descrierile serviciilor WSDL 1.1 pentru a transmite informații suplimentare necesare pentru un anumit tip de serviciu. Singurele elemente suplimentare WSDL 1.1 care sunt încă utilizate pe scară largă sunt legăturile pentru SOAP 1.1 (acestea sunt introduse în , în elementele Și ), care au fost definite în specificația originală WSDL 1.1 și pentru SOAP 1.2, definită printr-o specificație separată în 2006.

Detalii componente

Element conține toate definițiile XML utilizate pentru mesaje, ca unul sau mai multe elemente . (WSDL permite alternative XML Scheme pentru aceste definiții, dar majoritatea stivelor acceptă doar scheme XML.) Dacă este necesar, elemente poate utiliza sau să includă alte scheme externe WSDL (precum și să se refere la scheme separate în cadrul aceluiași WSDL).

Din moment ce un element poate conține orice număr de definiții de schemă, nu există niciun motiv pentru a utiliza mai mult de un element într-un document WSDL . Pentru a element se află în partea de sus a paginii BookServerInterface.wsdl.

in afara de asta Și , toate componentele de nivel superior ale unui document WSDL primesc nume individuale folosind atributul de nume necesar. Când utilizați atributul targetNamespace pe elementul rădăcină document (care este de obicei cel mai bun), numele acestor componente sunt definite în acest spațiu de nume țintă. Aceasta înseamnă că atunci când definiți un nume, este suficient să atribuiți partea simplă sau „locală” a numelui, dar referințele la acea componentă trebuie să califice numele utilizând un prefix de spațiu de nume sau folosind un spațiu de nume implicit. Figura 1 prezintă cele mai importante legături dintre componentele WSDL, cu linii continue reprezentând legături prin nume complet și linii punctate reprezentând legături după nume utilizate pentru identificare fără calificarea spațiului de nume.

Figura 1. Relațiile dintre componentele WSDL

Mesaje reprezentate prin elemente , sunt situate în centrul descrierilor de servicii WSDL. Elemente sunt descrieri ale datelor XML transferate între client și furnizorul de servicii. Fiecare element conține zero sau mai multe (de obicei, unul) elemente copil . Fiecare element de parte necesită propriul său atribut de nume (unic în ) și unul dintre atributele de element sau tip care fac referire la definiția schemei de date XML. Elemente multiple afișat în , după element în BookServerInterface.wsdl.

Elemente definiți o interfață abstractă de serviciu în ceea ce privește mesajele trimise și primite de la serviciu. Elemente conține orice număr de elemente copil . Fiecare element copil necesită propriul atribut de nume (WS-I BP necesită ca acesta să fie unic în interiorul ), și conține unul sau mai multe elemente copil care descriu mesajele utilizate de operație. Elementele copil sunt de trei tipuri, corespunzătoare diferitelor utilizări:

• : datele trimise de client către furnizorul de servicii ca intrare în operațiune;
• : date returnate clientului de furnizorul de servicii ca urmare a unei operațiuni;
• : Datele returnate clientului de către furnizorul de servicii atunci când apare o eroare în timpul procesării.

WSDL 1.1 definește mai multe modele de interacțiune între un client și un furnizor de servicii, reprezentate de diverse secvențe de elemente copil Și , dar nu toate modelele sunt suficient de bine definite pentru a fi implementate. BP WS-I permite doar două modele: operații cerere-răspuns, unde ar trebui să , și operațiuni unidirecționale care conțin numai . În cazul operațiunilor cerere-răspuns (de departe cel mai comun tip) din spatele elementelor Și poate fi urmată de orice număr de elemente .

Fiecare element , sau se referă la o descriere a mesajului prin intermediul atributului de mesaj necesar. Aceasta este o referință calificată pentru spațiu de nume, așa că de obicei necesită adăugarea unui prefix. Exemple pot fi văzute în: de exemplu, când un element utilizat în descrierea operațiunii getBook. (Prefixul tns servește ca definiție a elementului rădăcină cu același URI de spațiu de nume ca și atributul targetNamespace.)

În multe privințe poate fi considerat echivalentul logic al unei interfețe Java, deci elementele sunt echivalente cu metode, elemente - parametrii, elementele metodei - rezultatele metodelor și elementelor - verificate exceptii. Aceste mapări sunt utilizate atunci când se generează cod Java din WSDL, la fel ca majoritatea instrumentelor care generează WSDL din codul Java existent.

Comparație dintre SOAP 1.1 și 1.2

SOAP 1.1 a fost utilizat pe scară largă pentru serviciile Web de când specificația a fost publicată în 2000. SOAP 1.2 a fost dezvoltat cu suport mai larg din industrie prin W3C și publicat ca standard oficial W3C în 2007. SOAP 1.2 este mai bine documentat și mai curat decât SOAP 1.1, cu unele dintre aspectele urâte ale lui 1.1 eliminate chirurgical. În ciuda acestei structuri curățate, pentru majoritatea serviciilor Web există o mică diferență practică între ele. Poate cea mai semnificativă caracteristică a SOAP 1.2 este că este singura modalitate acceptată oficial de a folosi suportul îmbunătățit de la SOAP pentru atașamentele XML-binary Optimized Packaging (XOP) și mecanismul de optimizare a transmisiei mesajelor SOAP (MTOM). Într-o buclă Servicii web Java Am folosit SOAP 1.1 până acum pentru că unele stive mai vechi nu acceptă SOAP 1.2, dar pentru dezvoltarea de noi servicii Web, 1.2 este probabil o alegere mai bună.

Elemente reprezintă o instanță a unei interfețe abstracte definite , care este vizibil la începutul paginii BookServerImpl.wsdl. Atributul type conține Numele complet tipul de port implementat în legare.

Elemente copil conțin informații detaliate despre cum este implementat tipul de port. Elementele copil din spațiul de nume WSDL corespund elementelor și ar trebui să folosească aceeași valoare a numelui - dar nu legături cu clarificarea spațiului de nume, ca în cazul . această legătură este indicată prin linii punctate la nivel . Aceeași relație prin nume se aplică elementelor copil / / elemente . În ciuda acestei reutilizari a acelorași nume de elemente, conținutul acestor elemente diferă semnificativ atunci când sunt elemente copil , nu elementul .

Extensiile definite de WSDL intră în joc . Element copil utilizat într-o definiție a serviciului SOAP (singurul tip de serviciu permis de WS-I BP, deși WSDL 1.1 permite și legături HTTP). Acest obiect folosește atributul de transport necesar pentru a specifica tipul de transport utilizat de legare. (HTTP, așa cum se vede în valoarea http://schemas.xmlsoap.org/soap/http în , este singura opțiune permisă de WS-I BP.) Atributul de stil opțional vă permite să alegeți între stilul rpc și documentul pentru reprezentarea datelor XML (cea mai comună valoare a documentului corespunde mesajelor care utilizează elemente de definire a schemei mai degrabă decât tip).

În interiorul fiecărui element copil element element poate fi folosit pentru a specifica valoarea unei acțiuni SOAPA în scopul identificării cererilor de apelare a acelei operații (și, potențial, de asemenea, pentru a suprascrie alegerea stilului de document sau rpc specificat de element , deși BP WS-I interzice o astfel de utilizare). Fiecare element copil / / conține un alt element suplimentar, care este întotdeauna un element (indicând că datele mesajului sunt trimise în corpul mesajului SOAP - datele și chiar erorile pot fi trimise și în anteturile SOAP, deși nu recomand acest lucru) pt. sau , sau echivalentul acestuia , folosit cu .

Ultima componentă a descrierii serviciului WSDL este elementul , care constă dintr-un grup de elemente . Fiecare element asociază adresa de acces cu . Adresa de acces este conținută într-un element suplimentar imbricat .

Lucrul cu WSDL

Nu este surprinzător că, cu toate variațiile în schemele și regulile pentru documentele WSDL 1.1, multe documente nu sunt conforme cu cele mai bune practici BP WS-I. Suportul multor abateri de la cele mai bune practici în stivele de servicii Web a contribuit la perpetuarea utilizării designurilor învechite sau incorecte, ducând la răspândirea practicilor proaste în întreaga industrie. Și cu siguranță nu sunt imun la această infecție - în timp ce mă uit la documentele WSDL pe care le-am oferit ca exemple de cod pentru această serie, am fost surprins să constat că niciunul dintre ele nu era complet corect.

Deci, când m-am decis să scriu acest articol, m-am gândit că ar fi bine să includ un instrument care vă permite să verificați documentele WSDL cu cele mai bune practici. S-ar părea că acesta este la doar un pas de a converti documentele WSDL în forma corectă, cu condiția ca WSDL original să nu aibă erori. Dar a fost mult mai mult decât plănuisem inițial și voi include informații complete despre acest model în următoarele două articole ale acestei serii.

Au fost construite multe modele diferite pentru lucrul cu documente WSDL în Java, inclusiv Limbajul de descriere a serviciilor web pentru Java Toolkit (WSDL4J), utilizat pe scară largă, care este o implementare de referință a JSR 110 (vezi secțiunea ). Niciunul dintre aceste modele nu se potrivește cu ceea ce mi-am propus, din cauza naturii duble a problemei: în primul rând, citirea documentelor WSDL în orice formă semi-inteligentă și raportarea erorilor și abaterilor de la cele mai bune practici și, în al doilea rând, scrierea WSDL-urilor fără erori. documente reformatate într-o formă conformă cu recomandările practice. WSDL4J, de exemplu, nu păstrează ordinea elementelor de intrare, astfel încât problemele de ordonare să poată fi raportate și nu gestionează definițiile schemei, astfel încât să nu poată fi utilizat direct pentru a verifica referințele din elemente. . Așa că a trebuit să aleg între o enunțare a problemei mai realistă și să scriu propriul meu model. Desigur, am decis să-mi scriu propriul model.

Model WSDL

Validare și verificare

În acest articol folosesc termenul verificare pentru a se referi la verificarea validității unui document WSDL, deoarece termenul alternativ validare, folosit în mod obișnuit pentru documentele XML, înseamnă verificarea documentelor cu o definiție de schemă.

Am implementat anterior parțial un model WSDL pentru utilizare cu legarea de date JiBX ca parte a proiectului JiBX/WS. Acest model are numai rezultate și include un număr relativ mic de clase care, în unele cazuri, agregează date din elemente imbricate ale unei structuri XML WSDL ( combinat cu un element copil , , Și interior în combinaţie cu elementul sau etc.). Această structură de clasă compactă a făcut ușoară construirea subsetului de documente WSDL susținute de cadru, dar când am început să iau în considerare construirea unui instrument de verificare și restructurare bazat pe acest model, mi-am dat seama că modelul pentru susținerea intrării de WSDL posibil slab structurat ar trebuie să fie mai aproape de XML.prezentare.

O altă opțiune este generarea codului din schema WS-I BP pentru WSDL 1.1. După ce am văzut asta, mi-am dat seama că simpla folosire a claselor generate în mod direct ar duce la confuzie, deoarece designul include tipuri redundante, precum și câteva constructe incomode care sunt folosite pentru a reprezenta diferite modele de mesagerie (unele dintre ele au fost apoi interzise de WS- I BP text) .

Așa că am ajuns să compilez manual clasele, deși rezultatul a fost aproape același ca și cum aș fi început cu codul generat din schemă și pur și simplu am redus dublarea și complexitatea inutile. Legarea de date JiBX acceptă mai multe legături la aceleași clase, așa că am putut crea o legare de intrare pentru a gestiona întreaga gamă de variații permise de orice versiune de WSDL 1.1, deși setarea legării de ieșire pentru ieșirea WSDL a fost doar în formă de cea mai bună practică.

Lista 3 arată partea din clasa Definitions corespunzătoare elementului rădăcină .

Lista 3. Clasa de definiții (parțială)

public class Definiții extinde ElementBase ( /** Listează elementele copil în ordinea așteptată. */ static enum AddState ( invalid, imports, types, message, portType, binding, service ); /** Listă de nume de atribute permise. */ public static final StringArray s_allowedAttributes = new StringArray(new String ("nume", "targetNamespace" )); /** Validarea contextului de utilizat. */ private ValidationContext m_validationContext; /** Starea curentă (utilizată pentru a verifica ordinea în care */ /** sunt adăugați copii). */ private AddState m_state; /** Numele acestei definiții. */ private String m_name; /** Spațiul de nume WSDL țintă. */ private String m_targetNamespace; /** Lista tuturor elementelor copil importate. */ lista privată m_imports = noua ArrayList (); /** Lista tuturor tipurilor de elemente copil. */ lista privată m_types = noua ArrayList (); /** Lista tuturor mesajelor elementelor copil. */ lista privată m_messages = noua ArrayList (); /** Lista tuturor elementelor copil ale portType. */ lista privată M_portTypes = noua ArrayList (); /** Lista tuturor legăturilor elementului copil. */ lista privată m_bindings = noua ArrayList (); /** Lista tuturor serviciilor pentru copii. */ lista privată m_services = noua ArrayList m_nameMessageMap = nou HashMap (); /** Mapează numele calificat la tipul de port din această definiție. */ Hartă privată m_namePortTypeMap = noua Hartă Hash (); /** Mapează numele calificat la mesajul din această definiție. */ Hartă privată m_nameBindingMap = nou HashMap (); /** Mapează numele calificat la serviciu în această definiție. */ Hartă privată m_nameServiceMap = HashMap nou (); ... /** * Verificați stările de tranziție între diferitele tipuri de elemente copil. * Dacă elementele nu sunt în ordinea așteptată, * primul element din ordinea așteptată este marcat pentru raport. * @param state new add state * @param comp element component */ private void checkAdd(AddState state, ElementBase comp) ( if (m_state != state) ( if (m_state == null || (m_state != AddState.invalid &&) state.ordinal() > m_state.ordinal())) ( // trece la un alt tip de elemente copil m_state = stare; ) else if (state.ordinal()< m_state.ordinal()) { // отчет о дочерних элементах вне ожидаемого порядка m_validationContext.addWarning ("Child element of wsdl:definitions out of order", comp); m_state = AddState.invalid; } } } ... /** * Добавление немаршаллизированного дочернего элемента wsdl:message. * Здесь же сообщение индексируется по имени для доступа с целью валидации. * * @param child */ public void addMessage(Message child) { checkAdd(AddState.message, child); m_messages.add(child); addName(child.getName(), child, m_nameMessageMap); } ...

Organizarea datelor elementului copil în arată modul în care modelul acceptă atât formularul general de intrare, cât și formularul de ieșire conform recomandari practice. În loc de o singură listă de copii de toate tipurile, se folosesc liste separate pentru fiecare tip. Legarea de intrare JiBX tratează elementele copil ca pe un set neordonat, apelând specific de acest tip metoda de setare a elementelor ori de câte ori un element copil este deplasat. În loc să înlocuiască oricare dintre valorile precedente, setter-ul adaugă instanța la lista tastată, așa cum se vede în setter-ul addMessage() care este utilizat pe elementele copil. . Fiecare setter efectuează, de asemenea, o verificare a stării pentru a prinde elementele necomandate.

Atributele și elementele suplimentare sunt permise în orice element WSDL (de obicei toate atributele sau elementele care nu utilizează spațiul de nume WSDL 1.1). Un exemplu de astfel de elemente suplimentare sunt configurațiile WS-Policy încorporate în documentele WSDL din articolele anterioare a acestui ciclu, precum și linkuri către politici reale. Cel mai bine este ca aceste elemente suplimentare să precedă orice elemente copil din spațiul de nume WSDL 1.1 și așa sunt tratate în legarea de ieșire. Legarea de intrare gestionează elemente și atribute suplimentare folosind codul clasei de bază din clasele de elemente WSDL care nu sunt afișate în , și permite elementelor să urmeze în orice ordine (generând un avertisment dacă urmează un element din spațiul de nume WSDL 1.1).

Modelul procesează elemente cunoscute folosind legături separate pentru fiecare spatiu suplimentar nume, fiecare având propriile sale set propriu clase. Voi analiza mai detaliat gestionarea acestor elemente suplimentare în numărul următor Servicii web Java, unde codul sursă va fi prezentat mai detaliat.

Verificarea modelului

Unele verificări de bază ale datelor WSDL se efectuează pe măsură ce obiectele nedistribuite corespunzătoare elementelor sunt adăugate la structura arborescentă a documentului WSDL, așa cum se arată în codul addMessage() de la sfârșitul . Acest cod folosește metoda checkAdd() pentru a verifica ordinea elementelor copil și metoda addName() pentru a verifica dacă este prezentat un nume valid (textul se potrivește cu tipul schemei NCName și valoarea este unică în cadrul tipului de element) și hărți numele obiectului. Dar aceasta este doar verificarea informațiilor de bază pentru element individual; pentru a verifica alte proprietăți ale fiecărui element și relațiile dintre elemente este necesar cod suplimentar verificare.

JiBX vă permite să apelați gestionari de extensii personalizați ca parte a procesului de clasificare și dezasamblare. Pentru a executa logica de verificare, modelul WSDL folosește unul dintre acești handlere suplimentari, metoda post-set. Metoda post-set este apelată după ce obiectul asociat a terminat demarshalingul, deci acest lucru este adesea mod bun efectuarea de verificări precum verificarea obiectelor. În cazul verificării WSDL, cea mai simplă abordare este de a efectua toate verificările obiectelor dintr-o singură metodă post-set pe elementul rădăcină. . Această abordare evită problema referirii directe la componentele documentului WSDL atunci când componentele nu apar în ordinea așteptată.

Alte suplimente

Acest articol oferă elementele de bază ale structurii și utilizării WSDL și o introducere în modelul de date Java pentru WSDL, care este conceput pentru a sprijini verificarea documentelor WSDL și transformarea lor într-o formă de cele mai bune practici.

Următorul articol va continua acest subiect analizând problemele întâlnite frecvent la scrierea afirmațiilor WS-Policy și WS-SecurityPolicy. De asemenea, se va analiza mai atent modelul WSDL și procesul de verificare, inclusiv extinderea modelului pentru a include afirmațiile WS-Policy/WS-SecurityPolicy încorporate în WSDL.

Î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 o structură 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(). Prin instalarea unei distribuții concepute pentru platforma dvs., puteți crea proiect nou de echipa de proiect File/New SoapUi. Î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 partea dreaptă.

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.

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 va trece 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 suna procedura de la distanta, trebuie să descrii 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 primii 200 paginile merg o descriere detaliată a fiecărei etichete 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 s-ar putea să credeți 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 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 (cum ar fi, 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ă

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 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 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 nimic 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 o metodă. 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 al clasei de interfață a serviciului nostru web@WebService(endpointInterface= „ru.javarush.ws.HelloWebService”) clasa publică HelloWebServiceImpl implementează HelloWebService ( @Override public String getHelloString (nume șir) ( // returnează doar salutul 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; // clasă 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 în descriere 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 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ă 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

În acest subiect a fost prezentat scurtă excursie la 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.

Limbajul de descriere a serviciilor web (WSDL)

În ultimele exemple, este posibil să fi văzut câteva fragmente de cod WSDL. Amintiți-vă că WSDL este o gramatică bazată pe XML concepută pentru a descrie modul în care clienții externi pot interacționa cu metodele Web disponibile prin intermediul la aceasta adresa URL în cadrul fiecărui protocol de comunicare acceptat. În multe feluri, un document WSDL poate fi gândit ca un „contract” între clientul serviciului Web și serviciul Web însuși. Acesta este un alt metalimbaj. Mai exact, WSDL este folosit pentru a descrie următoarele caracteristici orice metoda Web accesibilă:

Numele metodei XML Web;

Numărul, tipul și ordinea parametrilor (dacă există);

Tip de returnare (dacă este furnizat);

Condiții de apel HTTP GET, HTTP POST și SOAP.

În cele mai multe cazuri, documentele WSDL sunt generate automat de serverul Web corespunzător. Amintiți-vă că atunci când adăugați sufixul ?wsdl la adresa URL indicând către un fișier *.asmx, serverul Web generează un document WSDL pentru serviciul Web XML specificat.

http://localhost/SomeWS/theWS.asmx?wsdl

Dar dacă IIS generează automat documentul WSDL pentru un anumit serviciu Web XML, atunci de ce aveți nevoie de o înțelegere profundă a sintaxei datelor WSDL generate? Răspunsul depinde de obicei de modul în care va fi utilizat serviciul dvs aplicatii externe. Pentru serviciile Web XML destinate utilizării „interne”, WSDL-ul generat de serverul Web va fi de obicei suficient.

Între timp. Este complet posibil să începeți dezvoltarea unui serviciu web XML prin crearea manuală a unui document WSDL (așa cum sa discutat mai sus). Ideea principală de a începe dezvoltarea prin crearea unui document WSDL este legată de problemele de compatibilitate. Amintiți-vă că înainte de specificația WSI, era obișnuit ca diferite instrumente de construire a serviciilor Web să genereze descrieri WSDL incompatibile. Dacă începeți dezvoltarea cu cod WSDL, puteți crea documentul după cum este necesar.

După cum ați putea ghici, pornirea unui serviciu Web XML prin crearea unui document WSDL necesită o cunoaștere foarte bună a gramaticii WSDL, ceea ce nu este discutat în contextul acestui capitol. Dar vom lua în considerare structură de bază document WSDL. Odată ce înțelegi elementele de bază, poți aprecia utilitatea utilitarului Linie de comanda wsdl.exe.

Cometariu. Cele mai recente informații despre Limbajul WSDL poate fi găsit la http://www.w3.org/tr/wsdl.

Definirea unui document WSDL

Documentul WSDL propriu-zis este deschis și închis de elementul rădăcină ‹definiții›. Descriptorul de deschidere definește de obicei diverse atribute xmlns. Ei definesc spații de nume XML care definesc diferite subelemente. Cel puțin, elementul ‹definitions› trebuie să indice spațiul de nume în care sunt definite elementele WSDL în sine (http://schemas.xmlsoap.org/wsdl). Pentru a fi util, descriptorul ‹definiții› de deschidere trebuie să specifice, de asemenea, spațiile de nume XML care definesc tipurile de date WSDL simple, tipurile de schemă XML, elementele SOAP și spațiul de nume țintă. De exemplu, așa arată secțiunea ‹definiții› pentru serviciul nostru web calculator.

‹wsdl:definiții xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"

xmlns:tm="http://microsoft.com/wsdl/mime/textMatching/"

xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"

xmlns-mime="http://schemas.xmlsoap.org/wsdl/mime/"

xmlns:tns="http://www.IntertechTraining.com/"

xmlns:s="http://www.w3.org/2001/XMLSchema"

xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/"

xmlns:http="http://schemes.xmlsoap.org/wsdl/http/"

targetNamespace="http://www.IntertechTraining.com/"

xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"›

‹/wsdl:definiții›

În contextul elementului rădăcină, puteți găsi cinci subelemente. Forma generală Documentul WSDL ar trebui să fie ceva de genul acesta.

‹?xml version="1.0" encoding="utf-8"?›

‹wsdl:definitions…›

‹wsdl:tipuri›

‹!-- Lista de tipuri disponibile pentru acest serviciu web --›

‹wsdl:/tipuri›

‹wsdl:message›

‹!-- Format mesaj --›

‹wsdl:/message›

‹wsdl:portType›

‹!-- Informații despre port --›

‹wsdl:/portType›

‹wsdl:binding›

‹!-- Informații obligatorii --›

‹wsdl:/binding›

‹wsdl:service›

‹!-– Informații despre serviciul web XML în sine --›

‹wsdl:/service›

‹wsdl:/definitions›

După cum v-ați aștepta, fiecare dintre aceste subelemente va conține elemente și atribute suplimentare care clarifică și mai mult descrierea capabilităților disponibile. Să ne uităm unul câte unul la cele mai importante noduri valide.

‹tipuri› de elemente

Mai întâi ne vom uita la elementul ‹tipuri›, care conține descrieri ale tuturor tipurilor de date oferite de serviciul Web. Poate știi asta Limbajul XML el însuși definește un număr de tipuri de date „de bază”, toate acestea fiind definite în spațiul de nume XML http://www.w3.org/2001/XMLSchema (care trebuie specificat în contextul elementului rădăcină ‹definiții›). Luați, de exemplu, metoda Subtract() a serviciului nostru web calculator, care are doi parametri de intrare întregi. În termeni WSDL, tipul de runtime a limbajului comun System.Int32 este descris în contextul elementului ‹complexType›.

‹s:nume element= „Scădere”›

‹s:sequence›

‹s:element minOccurs=" 1 "maxOccurs=" 1 "nume=" X"tip=" s:int" /›

‹s:element minOccurs="" 1 "maxOccurs=" 1 "nume=" y"tip=" s:int" /›

‹/s:sequence›

‹/s:complexType›

‹/s:element›

Întregul returnat de metoda Subtract() este descris și în cadrul elementului ‹types›.

‹s:nume element= " Scăderea răspunsului"›

‹s:complexType›

‹s:sequence›

‹s:element minOccurs=" 1 " maxOccurs=" 1 "nume=" SubtractResult"tip=" s:int"/›

‹/s:sequence›

‹ /s:complexType›

‹/s:element›

Dacă aveți o metodă Web care returnează sau primește tipuri personalizate date, acestea vor apărea și în contextul elementului ‹complexType›. Vom analiza mai târziu detaliile despre cum să facem disponibile tipuri de date .NET personalizate folosind metoda Web. De dragul acestui exemplu, să presupunem că definiți o metodă Web care returnează o structură numită Point.

punct de construcție publică (

șir public pointName;

Descrierea WSDL pentru această „structură complexă” ar arăta cam așa.

‹s:complexType name=" Punct"›

‹s:sequence›

‹s:element minOccurs=" 1 "maxOccurs=" 1 "nume=" X"tip=" s:int" /›

‹s:element minOccurs=" 1 "" maxOccurs=" 1 "nume=" y"tip=" s:int" /›

‹s:element minOccurs=" 0 "maxOccurs=" 1 "nume=" pointName"tip=" s: șir" /›

‹/s:sequence›

‹/s:complexType›

element ‹mesaj›

Elementul ‹mesaj› este folosit pentru a defini formatul pentru schimbul de cereri și răspunsuri pentru o anumită metodă Web. Deoarece un singur serviciu Web permite transmiterea mai multor mesaje între un expeditor și un destinatar, un singur document WSDL poate defini mai multe elemente de mesaj. De obicei, aceste definiții folosesc tipurile specificate în elementul ‹tipuri›.

Indiferent de numărul de elemente ‹mesaj› definite în documentul WSDL, acestea sunt de obicei „prezente” în perechi. Prima definiție reprezintă formatul de intrare al unui mesaj, iar a doua definiție reprezintă formatul de ieșire al aceluiași mesaj. De exemplu, metoda Subtract() a serviciului web CalculatorWebService definește următoarele elemente.

‹wsdl:nume mesaj=" ScădereSoapIn"›

‹wsdl:part name="parameters" element="tns:Subtract" /›

‹/wsdl:message›

‹wsdl: nume mesaj=" ScădereSoapOut"›

‹wsdl:part name="parameters" element="tns:SubtractResponse" /›

‹/wsdl:message›

Aici vedeți doar comunicarea SOAP a serviciului corespunzător. După cum sa discutat la începutul acestui capitol, serviciile Web XML pot fi invocate folosind SOAP sau metodele HTTP GET și POST. Dar dacă activați comunicarea HTTP POST (explicată mai târziu), WSDL-ul generat ar trebui să arate următoarele date ‹mesaj›.

‹wsdl: nume mesaj=" Scăderea HttpPostIn"›

‹part name="n1" type="s:string" /›

‹part name="n2" type="s:string" /›

‹wsdl:/message›

‹wsdl:nume mesaj=" Scăderea HttpPostOut"›

‹part name="Body" element="s0:int" /›

‹wsdl:/message›

Elementele ‹mesaj› nu sunt foarte utile singure. Cu toate acestea, aceste definiții de mesaje sunt menționate de alte părți ale documentului WSDL.

Cometariu. Nu toate metodele Web necesită atât o cerere, cât și un răspuns. Dacă metoda Web este „unidirecțională”, necesită doar elementul ‹mesaj› al cererii. Puteți desemna o metodă Web ca unidirecțională folosind atributul.

element ‹portType›

Elementul ‹portType› definește diferitele conexiuni care pot apărea între client și server, iar fiecare astfel de relație este reprezentată de un element ‹operațiune› imbricat. Este ușor de ghicit că cele mai tipice operațiuni de aici ar trebui să fie SOAP, HTTP GET și HTTP POST. Cu toate acestea, există și alte operațiuni. De exemplu, o operațiune unidirecțională permite clientului să trimită un mesaj acest server Web dar nu primiți un răspuns (acesta este ca și cum ați apela o metodă fără a aștepta o valoare returnată). O operație cerere-răspuns permite serverului să trimită o cerere în timp ce clientul răspunde (ceea ce poate fi considerat o extensie a operațiunii cerere-răspuns).

Pentru a ilustra formatul subelementului opțional ‹operațiune›, luați în considerare definiția WSDL pentru metoda Subtract().

‹wsdl portType name= „CalculatorWebServiceSoap"›

‹wsdl:operation name=" Scădea"›

‹wsdl:input message=" tns:SubtractSoapIn" /›

‹wsdl:output message=" tns:SubtractSoapOut" /›

‹ /wsdl:operation›

‹wsdl:/portType›

Observați cum elementele ‹input› și ‹output› se referă la numele mesajului corespunzător definit în elementul ‹message›. Dacă metoda Subtract() ar avea metoda HTTP POST activată, veți vedea următorul element suplimentar ‹operațiune›.

‹wsdl:portType name="CalculatorWebServiceHttpPost"›

‹wsdl:input message=" s0:SubtractHttpPostIn" /›

‹wsdl:output message= " s0:SubtractHttpPostOut" /›

‹ wsdl:/operation›

‹wsdl:/portType›

În cele din urmă, rețineți că, dacă o anumită metodă Web este descrisă folosind proprietatea Description, elementul ‹operațiune› va conține un element ‹documentație› imbricat.

Elementul ‹legare›

Acest element specifică formatul exact al schimbului GET, POST și SOAP. Acesta este cel mai verbos dintre toate elementele conținute în contextul elementului rădăcină ‹definiție›. De exemplu, iată o definiție a unui element ‹binding› care descrie modul în care un apelant poate interacționa cu metoda Web MyMethod(). folosind SAPUN.

‹wsdl:binding name="СalculatorWebServiceSoap12" type=" tns:CalculatorWebServiceSoap"›

‹soap12:binding transport=" http://schemas.xmlsoap.org/soap/http" /›

‹wsdl:nume operație= " Scădea"›

‹soap12:operation soapAction=" http://www.IntertechTraining.com/Subtract" stil="document" /›

‹wsdl:input›

‹soap12:body use=" literal" /›

‹/wsdl:input›

‹wsdl:ieșire›

‹soap12:body use=" literal" /›

‹/wsdl:output›

‹/wsdl:operation›

‹/wsdl:binding›

element ‹serviciu›

În cele din urmă, avem elementul ‹service›, care specifică caracteristicile serviciului Web însuși (de exemplu, URL-ul acestuia). Sarcina principală a acestui element este de a descrie setul de porturi deschise de acest server Web. Pentru a realiza acest lucru, elementul ‹services› poate folosi orice număr de elemente ‹port› imbricate (a nu fi confundat cu elementul ‹portType›). Așa arată elementul ‹service› pentru CalculatorWebService.

‹wsdl:nume serviciu= „CalculatorWebService"›

‹wsdl:documentație xmlns:wsdl ="http://schemas.xmlsoap.org/wsdl/"›

Serviciu minunat de calculator web

‹/wsdl:documentation›

‹wsdl:nume port= „CalculatorWebServiceSoap” legare= "tns:CalculatorWebServiceSoap"›

‹săpun:adresă locație= „http://localhost:1109/CalculatorWebService/Service.asmx”/›

‹/wsdl:port›

‹wsdl:port name="CalculatorWebServiceSoap12" legare=" tns:CalculatorWebServiceSoap12"›

‹soap12:adresă locație= „http://localhost:1109/CalculatorWebService/Service.asmx”/›

‹/wsdl:port›

‹/wsdl:service›

Deci, după cum puteți vedea, codul WSDL care este returnat automat de serverul ITS nu este super complex, dar, deoarece WSDL este o gramatică bazată pe XML, codul este destul de pronunțat. Cu toate acestea, acum ar trebui să înțelegeți mai bine rolul WSDL, așa că să ne uităm puțin mai atent la protocoalele de comunicare ale serviciilor web XML.

Cometariu. Amintiți-vă că spațiul de nume System.Web.Services.Description conține multe tipuri care vă permit să citiți și să procesați codul WSDL brut (verificați-l singur dacă sunteți interesat).