Shërbimi Wsdl. Përkufizimi i funksionimit të shërbimit të listës së librave

Faqja 2 nga 3

Përshkrimi duke përdorur WSDL

SOAP funksionon shumë mirë nëse dihet gjithçka për shërbimin në internet. Megjithatë, kjo nuk është gjithmonë rasti. Mjeti i përshkrimit të ndërfaqes për të hyrë në një shërbim ueb është gjuha WSDL (Gjuha e përshkrimit të shërbimeve të uebit). Ky standard është zhvilluar bashkërisht nga IBM, Microsoft dhe webMethods. Secila prej këtyre tre kompanive kishte qasjen e vet për zhvillimin e një standardi për përshkrimin e shërbimeve të Uebit: IBM krijoi NASSL, Microsoft zhvilloi SCL dhe webMethods doli me WIDL.

Rezultati i bashkëpunimit të tyre ishte versioni 1.1 i gjuhës WSDL. Lidhur me W3C, duhet theksuar se, ashtu si me SOAP, konsorciumi W3C i bazuar në versionin 1.1 zhvilloi WSDL 1.2, i cili tani është një rekomandim i W3C. Përshkrimi WSDL i një shërbimi Web përmban të gjithë informacionin e nevojshëm për të përdorur shërbimin, duke përfshirë metodat e disponueshme dhe parametrat e tyre. Ky informacion përmbahet në pesë elementët e mëposhtëm:

• - protokollet e mbështetur.
• - Mesazhet e shërbimit në ueb (kërkesë, përgjigje).
• Të gjitha metodat e disponueshme.
• - URI e shërbimit.
• - llojet e të dhënave të përdorura.

I gjithë ky informacion ruhet në elementin rrënjë të përshkrimit WSDL Lista e mëposhtme tregon një shembull të një përshkrimi WSDL të një shërbimi Web.

Përshkrimi WSDL i shërbimit në internet

Po... nuk mund ta kuptoni pa një gotë, por ky është një nga skedarët më të thjeshtë (!) WSDL. Fatkeqësisht, një nga të metat e zgjerimit SOAP për PHP 5 është se, ndryshe nga implementimet e tjera SOAP, ai nuk gjeneron automatikisht përshkrime WSDL (të paktën jo ende). Me siguri kjo e metë do të korrigjohet në versionet e ardhshme të PHP.

Meqe ra fjala!

Për të gjeneruar automatikisht përshkrimin WSDL, mund të përdorni implementime alternative të protokollit SOAP në PHP:

Kërkimi i drejtorisë duke përdorur UDDI

Tani që dimë se si të marrim informacione për një shërbim Web dhe si ta kërkojmë atë, duhet të mësojmë se si të gjejmë një shërbim të tillë. Për këtë qëllim, ekziston diçka e ngjashme me Faqet e Verdha, përkatësisht regjistrat UBR (Universal Business Registries) - drejtoritë e shërbimeve të internetit.

Ka disa regjistra të tillë, duke përfshirë ato të IBM, Microsoft, NTT-Com dhe SAP. Këta regjistra sinkronizojnë të dhënat e tyre, kështu që ju mund të përdorni cilindo prej tyre. Versioni aktual i standardit UDDI është UDDI 3.0, megjithëse shumica e implementimeve përdorin versionin 2. Zhvilluesit e këtij standardi përfshijnë kompani gjigante si HP, Intel, Microsoft dhe Sun.

Për të bashkëvepruar me UBR ekziston dy lloje të API-ve: Inquiry API dhe Publish API. Ndërfaqja Inquiry API (Kërkesë) është për të kërkuar shërbimet në regjistrat UBR dhe ndërfaqja Publish API i lejon zhvilluesit të regjistrojnë shërbimet e tyre. Duket se është vetëm çështje kohe para se përmbajtja e regjistrave të mbushet me spam :)

Meqe ra fjala!

Ka regjistra testimi të krijuar për të testuar regjistrimet e shërbimeve përpara se t'i vendosin ato në regjistrat "realë".

Kështu duket një kërkesë për shërbim në ueb:

sortByNameAsc sortByDateDesc %guid%

Në shembullin e mësipërm, mund të shihni se kërkesa UDDI është e kapsuluar në një mesazh SOAP, kështu që duket mjaft e njohur. Përgjigja ndaj kërkesës është gjithashtu një dokument SOAP, i paraqitur më poshtë:

Ueb-shërbime udhërrëfyese Shembuj të shërbimeve të uebit për Udhëzues me udhëzime Shërbimi i Kuotave të Stokut të Turit me Guidë

Instalimi

Instalimi i shtesës SOAP për PHP5 është mjaft i lehtë. Në Windows, ky modul ndodhet në nëndrejtorinë e jashtme të drejtorisë së instalimit PHP. Për ta përdorur atë, duhet të shtoni rreshtin e mëposhtëm në skedarin php.ini: extension=php_soap.dll Për të funksionuar, ky modul kërkon që ai të përfshihet në PHP 5 si parazgjedhje, të paktën në versionin e Windows.

Si i përcakton WSDL 1.1 shërbimet në internet dhe si të krijohen modele Java për të verifikuar dhe transformuar dokumentet WSDL

Seria e përmbajtjes:

Rreth kësaj serie artikujsh

Shërbimet e uebit janë një veçori e rëndësishme e teknologjisë Java™ në informatikën e ndërmarrjeve. Në këtë seri artikujsh, konsulenti i shërbimeve XML dhe Web Denis Sosnovsky flet për strukturat dhe teknologjitë kryesore të vlefshme për zhvilluesit Java që përdorin shërbimet e Uebit. Ndiqni artikujt në seri për të qëndruar të përditësuar me zhvillimet më të fundit në këtë fushë dhe të dini se si t'i zbatoni ato në projektet tuaja.

Shërbimet e uebit për aplikacionet e ndërmarrjeve mbështeten shumë në përdorimin e përkufizimeve të shërbimit. Përkufizimet e shërbimit përshkruajnë marrëveshjen bazë midis ofruesit të shërbimit dhe çdo konsumatori të mundshëm, duke detajuar llojet e funksioneve të ofruara nga shërbimi dhe mesazhet brenda secilit funksion. Ofruesit dhe konsumatorët janë të lirë të zgjedhin se si të zbatojnë objektet e tyre të shkëmbimit në masën që mesazhet aktuale që ata dërgojnë përputhen me përkufizimin e shërbimit. Përdorimi i një përkufizimi shërbimi që përshkruan se si shkëmbehen mesazhet XML është ajo që i dallon shërbimet e Uebit nga teknologjitë e programimit të shpërndarë më parë.

Janë propozuar metoda të ndryshme për përcaktimin e shërbimeve të Uebit, por WSDL 1.1 mbetet qasja më e përdorur. WSDL 1.1 ka disa mangësi, duke përfshirë një strukturë tepër komplekse që e bën të vështirë leximin për të pa iniciuarit. Ai gjithashtu vuan nga mungesa e një përkufizimi zyrtar autoritar, i cili ka çuar në "përpunime" të njëpasnjëshme që plotësojnë disa nga boshllëqet në dokumentin origjinal të specifikimit. Si rezultat, grupet e shërbimeve të uebit përpiqen t'i trajtojnë dokumentet WSDL 1.1 sa më fleksibël të jetë e mundur. Ky fleksibilitet mund të shtojë konfuzionin në të kuptuarit e WSDL 1.1, pasi zhvilluesit shohin një gamë të gjerë strukturash WSDL pa asnjë tregues se cila qasje është e preferueshme.

Në këtë artikull, ne do t'ju tregojmë se si të analizoni dokumentet WSDL 1.1 dhe të shikoni pjesët e para të modelit Java për vërtetimin e dokumenteve WSDL dhe konvertimin e tyre në formën standarde.

Analiza e WSDL 1.1

Hapësirat e emrave të përdorura

Ky artikull përdor:

• prefiksi wsdl për të përfaqësuar hapësirën e emrave WSDL 1.1 http://schemas.xmlsoap.org/wsdl/ ;
• prefiksi i sapunit për hapësirën e emrave http://schemas.xmlsoap.org/wsdl/soap/ i përdorur nga ekstensioni SOAP 1.1 për WSDL 1.1;
• prefiksi xs për hapësirën e emrave http://www.w3.org/2001/XMLSchema që përdoret për përkufizimet e skemave XML.

Rishikimi 1.1 i WSDL, i botuar në fillim të vitit 2001, teknikisht është zëvendësuar nga rekomandimet e W3C WSDL 2.0, të botuara në 2007. WSDL 2.0 ofron një strukturë më të pastër se WSDL 1.1 së bashku me fleksibilitet më të madh. Por WSDL 2.0 vuan nga një problem pule dhe vezë: WSDL 2.0 nuk përdoret gjerësisht sepse nuk mbështetet gjerësisht dhe për shkak se nuk përdoret gjerësisht, zhvilluesit e grupeve të shërbimeve të Uebit kanë pak nxitje për ta mbështetur atë. Pavarësisht nga të gjitha mangësitë e tij, WSDL 1.1 është mjaft i mirë për shumicën e qëllimeve.

Specifikimi origjinal WSDL 1.1 ishte i pasaktë në lidhje me numrin e funksioneve të përdorura. Për shkak se fokusi i WSDL ishte të punonte me përkufizimet e shërbimit SOAP, ai përfshinte gjithashtu mbështetje për veçoritë SOAP (si kodimi rpc) që më vonë doli të ishin të padëshirueshme. Organizata e Ndërveprueshmërisë së Shërbimeve të Uebit (WS-I) i ka trajtuar këto çështje në profilin bazë (BP), i cili ofron udhëzime praktike për shërbimet e uebit duke përdorur SOAP dhe WSDL. BP 1.0 u miratua në 2004, dhe BP 1.1 u lëshua në 2006. Ky artikull mbulon WSDL 1.1 bazuar në rekomandimet e WS-I BP dhe nuk prek veçoritë aktuale të vjetruara si kodimi rpc për SOAP.

Struktura e dokumenteve XML supozohet të specifikohet nga përkufizimet e Skemës XML. Specifikimi origjinal i WSDL 1.1 përfshinte një përshkrim të skemës, por skema nuk përputhet me përshkrimet tekstuale në disa aspekte. Kjo u korrigjua më vonë në një version të modifikuar të skemës, por dokumenti WSDL 1.1 nuk u redaktua për të pasqyruar këtë ndryshim. Ekipi i BP WS-I më pas vendosi të bënte edhe më shumë ndryshime në skemën WSDL dhe krijoi ato që shpallen si udhëzime praktike për këtë skemë të rrëshqitshme. Dokumentet e shkruara për një version të një skeme në përgjithësi nuk janë të përputhshme me versionet e tjera (megjithë përdorimin e të njëjtës hapësirë ​​emri), por për fat të mirë shumica e mjeteve të shërbimeve të Uebit injorojnë kryesisht skemën dhe pranojnë çdo gjë që duket e arsyeshme. (Shih lidhjet me shumë skema WSDL në seksion).

Edhe versioni BP WS-I i skemës WSDL 1.1 nuk bën shumë për të siguruar përputhjen me specifikimet e dokumenteve WSDL 1.1. Diagrami nuk pasqyron të gjitha kufizimet e WS-I BP, veçanërisht në lidhje me renditjen e komponentëve. Përveç kësaj, skema XML nuk është në gjendje të trajtojë shumë lloje të kufizimeve të vendosura lehtësisht në dokumente (të tilla si atributet alternative ose elementët shtesë të kërkuar nga një skemë e veçantë). Prandaj, verifikimi që një dokument WSDL 1.1 përputhet me specifikimin WSDL 1.1 (i amenduar nga BP WS-I) përfshin shumë më tepër sesa thjesht kryerjen e vërtetimit të skemës XML. Ne do t'i kthehemi kësaj teme më vonë në këtë artikull. Por së pari, le të shohim strukturën e përshkrimeve të shërbimit WSDL 1.1.

Përshkrim Komponentët

Dokumentet WSDL 1.1 përdorin një element rrënjësor fiks, me emërtim të përshtatshëm . Brenda këtij elementi rrënjë, hapësira e emrave WSDL 1.1 përcakton një element fëmijë "pasiv" (thjesht një lidhje me dokumente individuale WSDL 1.1) dhe pesë "aktive". elementet fëmijë(që në fakt përbëjnë përshkrimin e shërbimit):

• referon një dokument të veçantë WSDL 1.1 me përshkrime që do të përfshihen në atë dokument;
• përcakton llojet ose elementet XML të përdorura për mesazhe;
• përcakton mesazhin aktual në terma të llojeve ose elementeve XML;
• përcakton një grup abstrakt operacionesh të kryera nga shërbimi;
• përcakton zbatimin aktual duke përdorur protokolle dhe formate specifike;
• përcakton shërbimin në tërësi, duke përfshirë zakonisht një ose më shumë elementë me informacion aksesi për elementet .

Ekziston edhe një element , i cili mund të përdoret për qëllime dokumentacioni si elementi i parë i fëmijës , si dhe fëmija i parë i ndonjë prej elementeve të mësipërm.

Një përshkrim i plotë i një shërbimi zakonisht kërkon të paktën një element të secilit prej këtyre llojeve, përveç , por jo të gjithë duhet të jenë në të njëjtin dokument. Për të mbledhur një WSDL të plotë nga dokumente të shumta, mund të përdorni , i cili lejon përshkrimet të ndahen për t'iu përshtatur nevojave të organizatës. Për shembull, tre elementët e parë të përshkrimit ( , Dhe ) së bashku përbëjnë një përshkrim të plotë të ndërfaqes së shërbimit (ndoshta të përcaktuar nga grupi i arkitekturës), kështu që ka kuptim t'i mbash ato të ndara nga elementët e orientuar drejt zbatimit Dhe . Të gjitha grupet kryesore të shërbimeve të Uebit mbështesin ndarjen e përshkrimeve në dokumente të shumta WSDL.

Lista 1 tregon një shembull të përshkrimit të shërbimit WSDL të ndarë në dy dokumente WSDL, në mënyrë që përbërësit e përshkrimit të ndërfaqes të përmbahen në skedarin BookServerInterface.wsdl dhe komponentët e zbatimit të përmbahen në skedarin BookServerImpl.wsdl. Lista 1 tregon BookServerInterface.wsdl.

Listimi 1. BookServerInterface.wsdl

Përkufizimi i ndërfaqes së shërbimit të librit. ... ... Zbatimi i shërbimit të librit. Kjo krijon një bibliotekë fillestare të librave kur ngarkohet klasa, më pas mbështet thirrjet e metodave për të hyrë në informacionin e bibliotekës (duke përfshirë shtimin e librave të rinj). Merrni librin me një ISBN të veçantë. ... Shto një libër të ri.

Lista 2 tregon BookServerImpl.wsdl. Elementi në fillim importon përshkrimin e ndërfaqes BookServerInterface.wsdl.

Listimi 2. BookServerImpl.wsdl

Përkufizimi i zbatimit aktual të shërbimit të librit. ...

Përveç përcaktimeve të elementit (dhe atributit) në hapësirën e emrave WSDL 1.1, WSDL 1.1 përcakton gjithashtu elementë shtesë. Ato janë krijuar për të mbushur qeliza specifike në përshkrimet e shërbimit WSDL 1.1 për të përcjellë informacion shtesë të nevojshëm për një lloj të caktuar shërbimi. Të vetmit elementë shtesë WSDL 1.1 që janë ende në përdorim të gjerë janë lidhjet për SOAP 1.1 (këto janë futur në , në elementet Dhe ), të cilat u përcaktuan në specifikimin origjinal WSDL 1.1, dhe për SOAP 1.2, të përcaktuara nga një specifikim i veçantë në 2006.

Detajet e Komponentit

Elementi përmban të gjitha përkufizimet XML të përdorura për mesazhet, si një ose më shumë elementë . (WSDL lejon alternativa të Skemës XML për këto përkufizime, por shumica e pirgjeve mbështesin vetëm skemat XML.) Nëse është e nevojshme, elementet mund të përdorin ose për të përfshirë skema të tjera të jashtme për WSDL (si dhe referojuni skemave të veçanta brenda të njëjtës WSDL).

Meqenëse një element mund të përmbajë çdo numër përkufizimesh skemash, nuk ka asnjë arsye për të përdorur më shumë se një element në një dokument WSDL . Për element ndodhet në krye të BookServerInterface.wsdl.

Përveç kësaj Dhe , të gjithë komponentëve të nivelit të lartë të një dokumenti WSDL u jepen emra individualë duke përdorur atributin e kërkuar të emrit. Kur përdorni atributin targetNamespace në elementin rrënjë dokument (i cili zakonisht është më i miri), emrat e këtyre komponentëve përcaktohen në këtë hapësirë ​​të emrave të synuar. Kjo do të thotë që gjatë përcaktimit të një emri, mjafton të caktohet pjesa e thjeshtë ose "lokale" e emrit, por referencat ndaj atij komponenti duhet të kualifikojnë emrin duke përdorur një prefiks të hapësirës së emrit ose duke përdorur një hapësirë ​​të paracaktuar të emrit. Figura 1 tregon lidhjet më të rëndësishme midis komponentëve WSDL, me vija të forta që përfaqësojnë lidhjet me emrin e plotë dhe vija me pika që përfaqësojnë lidhjet sipas emrit të përdorur për identifikim pa kualifikim të hapësirës së emrit.

Figura 1. Marrëdhëniet ndërmjet komponentëve WSDL

Mesazhet e përfaqësuara nga elementë , janë të vendosura në thelbin e përshkrimeve të shërbimit WSDL. Elementet janë përshkrime të të dhënave XML të transferuara ndërmjet klientit dhe ofruesit të shërbimit. Çdo element përmban zero ose më shumë (zakonisht një) elementë fëmijë . Çdo element i pjesës kërkon atributin e vet të emrit (unik brenda ) dhe një nga atributet e elementit ose tipit që i referohet përkufizimit të skemës së të dhënave XML. Elemente të shumëfishta treguar në , pas elementit në BookServerInterface.wsdl.

Elementet Përcaktoni një ndërfaqe shërbimi abstrakt në kuptim të mesazheve të dërguara dhe të marra nga shërbimi. Elementet përmbajnë çdo numër elementësh fëmijë . Çdo element fëmijë kërkon atributin e vet të emrit (WS-I BP kërkon që ai të jetë unik brenda ), dhe përmban një ose më shumë elementë fëmijë që përshkruajnë mesazhet e përdorura nga operacioni. Elementet e fëmijëve vijnë në tre lloje, që korrespondojnë me përdorime të ndryshme:

• : të dhënat e dërguara nga klienti te ofruesi i shërbimit si hyrje në operacion;
• : të dhënat që i kthehen klientit nga ofruesi i shërbimit si rezultat i një operacioni;
• : Të dhënat i kthehen klientit nga ofruesi i shërbimit kur ndodh një gabim gjatë përpunimit.

WSDL 1.1 përcakton disa modele ndërveprimi midis një klienti dhe një ofruesi shërbimi, të përfaqësuara nga sekuenca të ndryshme të elementeve fëmijë Dhe , por jo të gjitha modelet janë të përcaktuara mirë për t'u zbatuar. BP WS-I lejon vetëm dy modele: operacionet kërkesë-përgjigje, ku duhet , dhe operacionet e njëanshme që përmbajnë vetëm . Në rastin e operacioneve të përgjigjes së kërkesës (lloji shumë më i zakonshëm) pas elementeve Dhe mund të pasohet nga çdo numër elementësh .

Çdo element , ose i referohet një përshkrimi të mesazhit nëpërmjet atributit të kërkuar të mesazhit. Kjo është një referencë e kualifikuar për hapësirën e emrit, kështu që zakonisht kërkon shtimin e një prefiksi. Shembujt mund të shihen në: për shembull, kur një element përdoret në përshkrimin e operacionit getBook. (Prefiksi tns shërben si përkufizim i elementit rrënjë me të njëjtën URI të hapësirës së emrit si atributi targetNamespace.)

NË shumë aspekte mund të konsiderohet ekuivalenti logjik i një ndërfaqe Java, pra elementet janë të barasvlershme me metodat, elementet - parametrat e metodës, elementet - rezultatet e metodave dhe elementet - përjashtime të kontrolluara. Këto harta përdoren kur gjenerohet kodi Java nga WSDL, siç janë shumica e mjeteve që gjenerojnë WSDL nga kodi ekzistues Java.

Krahasimi i SOAP 1.1 dhe 1.2

SOAP 1.1 është përdorur gjerësisht për shërbimet në ueb që kur specifikimi u publikua në 2000. SOAP 1.2 u zhvillua me mbështetje më të gjerë të industrisë përmes W3C dhe u botua si një standard zyrtar W3C në 2007. SOAP 1.2 është më i dokumentuar dhe më i pastër se SOAP 1.1, me disa nga aspektet e shëmtuara të 1.1 të hequra kirurgjikale. Pavarësisht kësaj strukture të pastruar, për shumicën e shërbimeve të Uebit ka pak dallim praktik midis tyre. Ndoshta veçoria më domethënëse e SOAP 1.2 është se është e vetmja mënyrë e mbështetur zyrtarisht për të shfrytëzuar mbështetjen e zgjeruar të SOAP-it për bashkëngjitjet XML-binare të Paketimit të Optimizuar (XOP) dhe Mekanizmin e Optimizimit të Transmetimit të Mesazheve SOAP (MTOM). Në një lak Shërbimet në ueb Java Unë kam përdorur SOAP 1.1 deri më tani sepse disa grupe të vjetra nuk e mbështesin SOAP 1.2, por për zhvillimin e shërbimeve të reja të Uebit, 1.2 është ndoshta një zgjedhje më e mirë.

Elementet përfaqësojnë një shembull të një ndërfaqe abstrakte të përcaktuar , e cila është e dukshme në fillim të BookServerImpl.wsdl. Atributi tip përmban emri i plotë lloji i portit të zbatuar në lidhje.

Elementet fëmijë përmbajnë informacion të detajuar se si zbatohet lloji i portit. Elementet fëmijë nga hapësira e emrave WSDL korrespondojnë me elementët dhe duhet të përdorë të njëjtën vlerë emri - por jo lidhjet me sqarimin e hapësirës së emrit, si në rastin . kjo lidhje tregohet me vija me pika në nivel . E njëjta marrëdhënie me emër vlen edhe për elementët fëmijë / / elementet . Pavarësisht këtij ripërdorimi të emrave të njëjtë të elementeve, përmbajtja e këtyre elementeve ndryshon ndjeshëm kur janë elementë fëmijë , jo elementi .

Shtesat e përcaktuara nga WSDL hyjnë në lojë . Elementi fëmijë përdoret në një përkufizim të shërbimit SOAP (i vetmi lloj shërbimi i lejuar nga WS-I BP, megjithëse WSDL 1.1 gjithashtu lejon lidhjet HTTP). Ky artikull përdor atributin e kërkuar të transportit për të specifikuar llojin e transportit të përdorur nga lidhja. (HTTP, siç shihet në vlerën http://schemas.xmlsoap.org/soap/http në , është e vetmja zgjedhje e lejuar nga WS-I BP.) Atributi i stilit opsional ju lejon të zgjidhni midis stileve rpc dhe dokumentit për përfaqësimin e të dhënave XML (vlera më e zakonshme e dokumentit korrespondon me mesazhet që përdorin elementë të përkufizimit të skemës në vend të tipit).

Brenda çdo elementi fëmijë element element mund të përdoret për të specifikuar vlerën e një SOAPAction për qëllimin e identifikimit të kërkesave për të thirrur atë operacion (dhe potencialisht gjithashtu për të anashkaluar zgjedhjen e dokumentit ose stilit rpc të specifikuar nga elementi , megjithëse BP WS-I e ndalon një përdorim të tillë). Çdo element fëmijë / / përmban një element tjetër shtesë, i cili është gjithmonë një element (duke treguar që të dhënat e mesazhit dërgohen në trupin e mesazhit SOAP - të dhënat dhe madje gabimet mund të dërgohen gjithashtu në titujt e SOAP, megjithëse nuk e rekomandoj këtë) për ose , ose ekuivalentin e tij , përdoret me .

Komponenti i fundit i përshkrimit të shërbimit WSDL është elementi , i cili përbëhet nga një grup elementësh . Çdo element lidh adresën e aksesit me . Adresa e aksesit përmbahet në një element shtesë të mbivendosur .

Puna me WSDL

Nuk është për t'u habitur që me të gjitha ndryshimet në skemat dhe rregullat për dokumentet WSDL 1.1, shumë dokumente nuk përputhen me praktikat më të mira të BP WS-I. Mbështetja e shumë devijimeve nga praktikat më të mira në grupet e shërbimeve të Uebit ka ndihmuar në vazhdimësinë e përdorimit të modeleve të vjetruara ose të pasakta, duke çuar në përhapjen e praktikave të këqija në të gjithë industrinë. Dhe definitivisht nuk jam imun ndaj këtij infeksioni - ndërsa shikoja dokumentet WSDL që ofrova si shembuj kodesh për këtë seri, u befasova kur zbulova se asnjëri prej tyre nuk ishte plotësisht i saktë.

Kështu që kur vendosa të shkruaj këtë artikull, mendova se do të ishte mirë të përfshija një mjet që ju lejon të kontrolloni dokumentet WSDL kundrejt praktikave më të mira. Duket se ky është vetëm një hap larg konvertimit të dokumenteve WSDL në formën e duhur, me kusht që WSDL origjinal të mos ketë gabime. Por kishte shumë më tepër punë nga sa kisha planifikuar fillimisht, dhe do të përfshij informacion të plotë rreth këtij modeli në dy artikujt e ardhshëm të kësaj serie.

Shumë modele të ndryshme janë ndërtuar për të punuar me dokumentet WSDL në Java, duke përfshirë përdorimin e gjerë të gjuhës së përshkrimit të shërbimeve të internetit për Java Toolkit (WSDL4J), e cila është një zbatim referues i JSR 110 (shih seksionin). Asnjë prej këtyre modeleve nuk përshtatet me atë që kam vendosur të bëj, për shkak të natyrës së dyfishtë të problemit: së pari, leximi i dokumenteve WSDL në çdo formë gjysmë inteligjente dhe raportimi i gabimeve dhe devijimeve nga praktikat më të mira, dhe së dyti, shkrimi i WSDL-ve pa gabime. dokumentet e riformatuara në një formë në përputhje me rekomandimet praktike. WSDL4J, për shembull, nuk ruan rendin e elementeve hyrëse në mënyrë që problemet e renditjes të mund të raportohen dhe nuk trajton përkufizimet e skemave në mënyrë që të mos mund të përdoret drejtpërdrejt për të kontrolluar referencat nga elementët . Kështu që më duhej të zgjidhja mes një deklarate problemi më realiste dhe shkrimit të modelit tim. Natyrisht, vendosa të shkruaj modelin tim.

Modeli WSDL

Vleresimi dhe Verifikimi

Në këtë artikull unë përdor termin verifikimi për t'iu referuar kontrollit të vlefshmërisë së një dokumenti WSDL, sepse termi alternativ vërtetimi, që përdoret zakonisht për dokumentet XML, nënkupton kontrollimin e dokumenteve kundrejt një përkufizimi të skemës.

Më parë kam zbatuar pjesërisht një model WSDL për përdorim me lidhjen e të dhënave JiBX si pjesë e projektit JiBX/WS. Ky model është vetëm për dalje dhe përfshin një numër relativisht të vogël klasash që, në disa raste, grumbullojnë të dhëna nga elementët e mbivendosur të një strukture WSDL XML ( kombinuar me një element fëmijë , , Dhe brenda në kombinim me elementin ose etj.). Kjo strukturë kompakte e klasës e bëri të lehtë ndërtimin e nëngrupit të dokumenteve WSDL të mbështetur nga korniza, por kur fillova të konsideroja ndërtimin e një mjeti verifikimi dhe ristrukturimi bazuar në këtë model, kuptova se modeli për mbështetjen e hyrjes së WSDL-së me strukturim të dobët do duhet të jenë më afër prezantimit XML.

Një opsion tjetër është të gjeneroni kod nga skema WS-I BP për WSDL 1.1. Pasi pashë këtë, kuptova se thjesht përdorimi i klasave të krijuara drejtpërdrejt do të çonte në konfuzion, pasi dizajni përfshin lloje të tepërta, si dhe disa konstruksione të pakëndshme që përdoren për të përfaqësuar modele të ndryshme mesazhesh (disa prej të cilave më pas u ndaluan nga WS- Teksti I BP) .

Kështu përfundova duke i përpiluar klasat me dorë, megjithëse rezultati ishte pothuajse i njëjtë sikur të kisha filluar me kodin e krijuar nga skema dhe thjesht reduktova dyfishimin dhe kompleksitetin e panevojshëm. Lidhja e të dhënave JiBX mbështet lidhje të shumta për të njëjtat klasa, kështu që unë munda të krijoja një lidhje hyrëse për të trajtuar gamën e plotë të variacioneve të lejuara nga çdo version i WSDL 1.1, megjithëse vendosja e lidhjes së daljes për daljen WSDL ishte vetëm në formën më të mirë të praktikës.

Lista 3 tregon pjesën e klasës Definitions që korrespondon me elementin rrënjë .

Listimi 3. Klasa e përkufizimeve (e pjesshme)

Përkufizimet e klasës publike zgjerojnë ElementBase ( /** Listoni elementët fëmijë në rendin e pritur. */ numër statik AddState ( i pavlefshëm, importe, lloje, mesazh, portType, lidhje, shërbim); /** Lista e emrave të atributeve të lejuara. */ statike publike final StringArray s_allowedAttributes = i ri StringArray(varg i ri ( "emri", "targetNamespace" )); /** Vërtetimi i kontekstit për t'u përdorur. */ private ValidationContext m_validationContext; /** Gjendja aktuale (përdoret për të kontrolluar rendin në të cilin */ /** janë shtuar fëmijët). */ private AddState m_state; /** Emri i këtij përkufizimi. */ Vargu privat m_emri; /** Synoni hapësirën e emrave WSDL. */ String privat m_targetNamespace; /** Lista e të gjithë elementëve fëmijë të importuar. */ Lista private m_imports = ArrayList i ri (); /** Lista e të gjitha llojeve të elementeve fëmijë. */ Lista private m_types = ArrayList i ri (); /** Lista e të gjitha mesazheve të elementeve fëmijë. */ Lista private m_messages = ArrayList i ri (); /** Lista e të gjithë elementëve fëmijë të portType. */ Lista private M_portTypes = ArrayList i ri (); /** Lista e të gjitha lidhjeve të elementeve fëmijë. */ Lista private m_bindings = ArrayList i ri (); /** Lista e të gjitha shërbimeve për fëmijë. */ Lista private m_services = ArrayList i ri m_nameMessageMap = HashMap i ri (); /** Harton emrin e kualifikuar me llojin e portit në këtë përkufizim. */ Harta private m_namePortTypeMap = HashMap i ri (); /** Harto emrin e kualifikuar për mesazhin në këtë përkufizim. */ Harta private m_nameBindingMap = HashMap i ri (); /** Harto emrin e kualifikuar për shërbimin në këtë përkufizim. */ Harta private m_nameServiceMap = HashMap i ri (); ... /** * Kontrolloni për gjendjet e tranzicionit midis llojeve të ndryshme të elementeve fëmijë. * Nëse elementet nuk janë në rendin e pritshëm, * elementi i parë jashtë rendit të pritur shënohet për raportin. * @param gjendje e re shto gjendje * @param comp komponent element */ private void checkAdd(AddState state, ElementBase comp) ( if (m_state != State) ( if (m_state == null || (m_state != AddState.invalid && gjendje.ordinal() > m_state.ordinal())) ( // kaloj te një lloj tjetër elementesh fëmijë m_state = gjendje; ) tjetër nëse (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); } ...

Organizimi i të dhënave të elementeve fëmijë në tregon se si modeli mbështet si formularin e përgjithshëm të hyrjes ashtu edhe formën e daljes sipas rekomandime praktike. Në vend të një liste të vetme të fëmijëve të të gjitha llojeve, përdoren lista të veçanta për secilin lloj. Lidhja e hyrjes JiBX trajton elementët fëmijë si një grup të parregulluar, duke thirrur specifik të këtij lloji Metoda e vendosjes së elementeve sa herë që një element fëmijë nuk është në vend. Në vend që të zëvendësojë ndonjë nga vlerat e mëparshme, vendosësi shton shembullin në listën e shtypur, siç shihet në përcaktuesin addMessage() që përdoret në elementët fëmijë . Çdo vendosës kryen gjithashtu një kontroll të gjendjes për të kapur elementë jashtë rendit.

Atributet dhe elementet shtesë lejohen në çdo element WSDL (zakonisht të gjitha atributet ose elementët që nuk përdorin hapësirën e emrave WSDL 1.1). Një shembull i këtyre elementeve shtesë janë konfigurimet e politikës WS të ngulitura në dokumentet WSDL nga artikujt e mëparshëm të këtij cikli, si dhe lidhjet me politikat aktuale. Është mirë që këta elementë shtesë t'i paraprijnë çdo elementi fëmijë nga hapësira e emrave WSDL 1.1, dhe kështu trajtohen në lidhjen e daljes. Lidhja e hyrjes trajton elemente dhe atribute shtesë duke përdorur kodin e klasës bazë nga klasat e elementeve WSDL që nuk shfaqen në , dhe i lejon elementët të ndjekin në çdo rend (duke gjeneruar një paralajmërim nëse ndjekin një element nga hapësira e emrave WSDL 1.1).

Modeli përpunon elementë të njohur duke përdorur lidhje të veçanta për secilin hapësirë ​​shtesë emra, secila prej të cilave ka të vetat komplet i vet klasat. Unë do të shikoj trajtimin e këtyre elementeve shtesë në më shumë detaje në numrin tjetër Shërbimet në ueb Java, ku kodi burimor do të prezantohet më në detaje.

Verifikimi i modelit

Disa verifikime bazë të të dhënave WSDL kryhen pasi objektet e pa marshalluara që korrespondojnë me elementët shtohen në strukturën e pemës së dokumentit WSDL, siç tregohet në kodin addMessage() në fund të . Ky kod përdor metodën checkAdd() për të kontrolluar renditjen e elementeve fëmijë dhe metodën addName() për të kontrolluar nëse një emër i vlefshëm është paraqitur (teksti përputhet me llojin e skemës NCName dhe vlera është unike brenda llojit të elementit) dhe harton emri i objektit. Por ky është vetëm kontrollimi i informacionit më bazë element individual; për të kontrolluar vetitë e tjera të secilit element dhe marrëdhëniet ndërmjet elementeve është e nevojshme kod shtesë verifikimi.

JiBX ju lejon të telefononi mbajtës të shtesave të personalizuara si pjesë e procesit të marshallimit dhe heqjes së marshallimit. Për të ekzekutuar logjikën e verifikimit, modeli WSDL përdor një nga këta mbajtës shtesë, metodën post-set. Metoda e post-setit thirret pasi objekti shoqërues të ketë përfunduar zbërthimin, kështu që shpesh ndodh mënyrë e mirë kryerja e kontrolleve si verifikimi i objektit. Në rastin e verifikimit WSDL, qasja më e thjeshtë është të kryhet i gjithë verifikimi i objektit nga një metodë e vetme post-set në elementin rrënjë. . Kjo qasje shmang problemin e referimit të drejtpërdrejtë të komponentëve të dokumentit WSDL kur komponentët nuk shfaqen në rendin e pritur.

Shtesa të tjera

Ky artikull ofron bazat e strukturës dhe përdorimit të WSDL dhe një hyrje në modelin e të dhënave Java për WSDL, i cili është krijuar për të mbështetur verifikimin e dokumenteve WSDL dhe transformimin e tyre në një formë praktike më të mirë.

Artikulli tjetër do ta vazhdojë këtë temë duke parë çështjet që hasen zakonisht kur shkruani pohimet e politikave WS dhe Politikës së Sigurisë WS. Ai gjithashtu do të marrë një vështrim më të afërt në modelin WSDL dhe procesin e verifikimit, duke përfshirë zgjerimin e modelit për të përfshirë pohimet WS-Policy/WS-SecurityPolicy të integruara në WSDL.

Në këtë artikull do të flas se çfarë është një skedar WSDL, pse është i nevojshëm dhe si të punohet me të.

Harta e artikullit

Çfarë është WSDL

WSDL është një gjuhë përshkrimi e shërbimit në internet që ka një strukturë XML. Qëllimi kryesor i një skedari WSDL është si një ndërfaqe për aksesin në funksionet e shërbimit dhe kthimin e llojeve të të dhënave; rrugën drejt serverit që përpunon kërkesat, etj.

Rruga drejt skedarit wsdl zakonisht duket si http://host/services/wsdl/gbdar-v2-2.wsdl

Ka shumë mjete, biblioteka të krijuara për të lexuar një skedar WSDL.

SapunUi

Një mjet i tillë është soapUi(). Duke instaluar një shpërndarje të krijuar për platformën tuaj, ju mund të krijoni projekt i ri nga ekipi i projektit File/New SoapUi. Në dialogun për krijimin e një projekti të ri, lini të aktivizuar kutinë e kontrollit Krijoni kërkesat e mostrës

Ekzekutimi i pyetjeve

Në projektin e ri, shabllonet e kërkesave do të krijohen automatikisht për shërbimin, përshkrimi i të cilit gjendet në skedarin wsdl. Në të majtë në pemë do të shihni një listë të funksioneve të përfshira në skedarin WSDL. Unë do të ekspozoj funksionin e Replikimit. Brenda saj ka një kërkesë Kërkesë1, duke klikuar dy herë mbi të cilën do të shohim një dialog me një shabllon kërkese, në vend të parametrave të paracaktuar do të ketë pikëpyetje. Që funksioni të ekzekutohet saktë, duhet të plotësoni të gjithë parametrat që nuk janë shënuar me etiketën Opsionale dhe më pas të klikoni trekëndëshin e gjelbër në këndin e sipërm të majtë të dialogut.

Nëse të gjithë parametrat janë specifikuar saktë, përgjigja e shërbimit ndaj kërkesës do të shfaqet në të djathtë.

SoapUi ofron mundësinë për të parë parametrat e një skedari WSDL; për ta bërë këtë, duhet të klikoni dy herë në emrin e ndërfaqes (të shënuar me një ikonë të gjelbër në pemën e skedarit WSDL, për mua - gdbar-v2-2SOAP). Në dialog mund të gjeni:

• Skeda "Përmbledhje". - përshkrim parametrat e përgjithshëm WSDL, një listë funksionesh dhe veprimesh të lidhura me serverin
• Tab. Pikat përfundimtare të shërbimit - rruga për në server dhe parametra të tjerë
• Përmbajtja WSDL - pema e navigimit të skedarëve
• Pajtueshmëria WS-I — këtu mund të krijoni një raport WS-I mbi ndërfaqen

Gjenerimi i dokumentacionit

SoapUi na lejon të gjenerojmë dokumentacionin e funksionit WSDL. Për ta bërë këtë, klikoni klikoni me të djathtën përmes ndërfaqes dhe thirrni komandën Krijo dokumentacion. Si rezultat marrim manual i detajuar në formatin html.

Kjo është e gjitha, abonohuni në postime të reja, lini komente, bëni sugjerime për përmirësimin e artikullit.

Titulli i temës është vërtet një pyetje, sepse... Unë vetë nuk e di se çfarë është dhe për herë të parë do të përpiqem të punoj me të në kuadrin e këtij artikulli. E vetmja gjë që mund të garantoj është se kodi i paraqitur më poshtë do të funksionojë, por frazat e mia do të jenë vetëm supozime dhe supozime se si unë vetë e kuptoj gjithë këtë. Pra, le të shkojmë ...

Prezantimi

Duhet të fillojmë me arsyen pse u krijua koncepti i shërbimeve në internet. Në kohën kur ky koncept u shfaq në botë, tashmë ekzistonin teknologji që lejonin aplikacionet të ndërveprojnë në distancë, ku një program mund të thërriste një metodë në një program tjetër, i cili mund të lansohej në një kompjuter të vendosur në një qytet apo edhe një vend tjetër. E gjithë kjo shkurtohet si RPC (Remote Procedure Calling). Shembujt përfshijnë teknologjitë CORBA, dhe për Java - RMI (Remote Method Invoking). Dhe gjithçka duket të jetë mirë tek ata, veçanërisht në CORBA, sepse... Mund të punoni me të në çdo gjuhë programimi, por diçka ende mungonte. Unë besoj se disavantazhi i CORBA është se funksionon përmes disa të vetave protokollet e rrjetit në vend të HTTP të thjeshtë, i cili do të kalojë nëpër çdo mur zjarri. Ideja e shërbimit në internet ishte krijimi i një RPC që do të futej në paketat HTTP. Kështu filloi zhvillimi i standardit. Cilat janë konceptet bazë të këtij standardi:

1. SAPUNI. Para se të telefononi procedurë në distancë, duhet ta përshkruani këtë thirrje në skedar XML e format SOAP. SOAP është thjesht një nga shënjimet e shumta XML që përdoren në shërbimet e internetit. Gjithçka që duam të dërgojmë diku përmes HTTP, fillimisht konvertohet në një përshkrim XML SOAP, më pas futet në një paketë HTTP dhe dërgohet në një kompjuter tjetër në rrjet nëpërmjet TCP/IP.
2. WSDL. Ekziston një shërbim në internet, d.m.th. një program metodat e të cilit mund të thirren nga distanca. Por standardi kërkon që ky program të shoqërohet me një përshkrim që thotë se "po, keni të drejtë - ky është me të vërtetë një shërbim në internet dhe ju mund të quani metoda të tilla dhe të tilla prej tij". Ky përshkrim përfaqësohet nga një skedar tjetër XML, i cili ka një format të ndryshëm, domethënë WSDL. Ato. WSDL është thjesht një skedar XML që përshkruan një shërbim në internet dhe asgjë më shumë.

Pse kaq shkurt pyet? Nuk mund të jeni më konkret? Ndoshta është e mundur, por për ta bërë këtë do t'ju duhet t'i drejtoheni librave të tillë si T. Mashnin, "Java Web Services". Atje për 200 të parat faqet shkojnë një përshkrim të detajuar të çdo etikete të standardeve SOAP dhe WSDL. A ia vlen të bëhet? Sipas mendimit tim, jo, sepse ... e gjithë kjo krijohet automatikisht në Java, dhe ju duhet vetëm të shkruani përmbajtjen e metodave që supozohet të thirren nga distanca. Pra, një API si JAX-RPC u shfaq në Java. Nëse dikush nuk e di, kur thotë se Java ka një API të tillë, do të thotë se ekziston një paketë me një grup klasash që përmbledhin teknologjinë në fjalë. JAX-RPC evoluoi me kalimin e kohës nga versioni në version dhe përfundimisht u bë JAX-WS. WS padyshim qëndron për WebService dhe ju mund të mendoni se ky është thjesht një riemërtim i RPC si një fjalë popullore këto ditë. Kjo nuk është e vërtetë, sepse Tani shërbimet e uebit janë larguar nga ideja origjinale dhe ju lejojnë jo vetëm të telefononi metoda në distancë, por edhe thjesht të dërgoni mesazhe dokumentesh në formatin SOAP. Nuk e di pse kjo është ende e nevojshme; nuk ka gjasa që përgjigjja këtu të jetë "vetëm në rast se është e nevojshme". Unë vetë do të doja të mësoja nga shokë më me përvojë. Dhe së fundi, atëherë JAX-RS u shfaq për të ashtuquajturat shërbime në internet RESTful, por kjo është tema e një artikulli të veçantë. Prezantimi mund të përfundojë këtu, sepse... Më pas do të mësojmë të punojmë me JAX-WS.

Qasje e përgjithshme

Në shërbimet e internetit ka gjithmonë një klient dhe një server. Serveri është shërbimi ynë në ueb dhe nganjëherë quhet pika përfundimtare (si p.sh. pika e fundit, ku mbërrijnë mesazhet SOAP nga klienti). Duhet të bëjmë sa vijon:

1. Përshkruani ndërfaqen e shërbimit tonë të internetit
2. Zbatoni këtë ndërfaqe
3. Nisni shërbimin tonë të internetit
4. Shkruani një klient dhe telefononi në distancë metodën e dëshiruar të shërbimit në internet

Shërbimi në internet mund të hapet menyra te ndryshme: ose përshkruani një klasë me një metodë kryesore dhe ekzekutoni shërbimin e uebit drejtpërdrejt si një server, ose vendoseni atë në një server si Tomcat ose ndonjë tjetër. Në rastin e dytë, ne nuk e lëshojmë veten server i ri dhe ne nuk hapim një port tjetër në kompjuter, por thjesht i themi kontejnerit të servletit Tomcat se "ne kemi shkruar klasa të shërbimit të uebit këtu, ju lutemi publikojini ato në mënyrë që të gjithë ata që ju kontaktojnë të mund të përdorin shërbimin tonë të internetit". Pavarësisht nga mënyra e nisjes së shërbimit të ueb-it, ne do të kemi të njëjtin klient.

Serveri

Le të hapim IDEA dhe të krijojmë një projekt të ri Krijo projekt të ri. Le të tregojmë emrin HelloWebService dhe shtypni butonin Tjetra, pastaj butonin Përfundo. Në dosje src le të krijojmë një paketë ru.javarush.ws. Në këtë paketë ne do të krijojmë ndërfaqen HelloWebService: paketë ru. javarush. ws; // këto janë shënime, d.m.th. një mënyrë për të shënuar klasat dhe metodat tona, // në lidhje me teknologjinë e shërbimit në internet import javax. jws. WebMethod; import javax. jws. WebService; import javax. jws. sapun. Lidhja SOAP; // ne themi se ndërfaqja jonë do të funksionojë si një shërbim në internet@WebService // themi se shërbimi në internet do të përdoret për të thirrur metoda Ndërfaqja publike @SOAPBinding (style = SOAPBinding. Style. RPC) HelloWebService ( // themi se kjo metodë mund të thirret nga distanca@WebMethod String publik getHelloString(emri i vargut) ; ) Në këtë kod, klasat WebService dhe WebMethod janë të ashtuquajturat shënime dhe nuk bëjnë asgjë përveçse shënojnë ndërfaqen tonë dhe metodën e saj si një shërbim ueb. E njëjta gjë vlen edhe për klasën SOAPBinding. I vetmi ndryshim është se SOAPBinding është një shënim me parametra. Në këtë rast, parametri i stilit përdoret me një vlerë që tregon se shërbimi në internet nuk do të funksionojë përmes mesazheve të dokumenteve, por si një RPC klasik, d.m.th. për të thirrur një metodë. Le të zbatojmë logjikën tonë të ndërfaqes dhe të krijojmë një klasë HelloWebServiceImpl në paketën tonë. Nga rruga, vërej se përfundimi i një klase me Impl është një konventë në Java, sipas së cilës zbatimi i ndërfaqeve është përcaktuar kështu (Impl - nga fjala implementim, d.m.th. zbatim). Kjo nuk është një kërkesë dhe ju jeni të lirë të emërtoni klasën si të doni, por sjelljet e mira e kërkojnë atë: paketë ru. javarush. ws; // i njëjti shënim si kur përshkruani ndërfaqen, import javax. jws. WebService; // por këtu përdoret me parametrin endpointInterface, // duke treguar emrin e plotë të klasës së ndërfaqes së shërbimit tonë të internetit@WebService(endpointInterface= "ru.javarush.ws.HelloWebService") klasa publike HelloWebServiceImpl zbaton HelloWebService ( @Override string publik getHelloString (emri i vargut) ( // thjesht ktheni përshëndetjen kthej "Përshëndetje, " + emri + "!" ; ) ) Le të hapim shërbimin tonë të internetit si një server i pavarur, d.m.th. pa pjesëmarrjen e ndonjë serveri Tomcat dhe aplikacioni (kjo është një temë për një diskutim të veçantë). Për ta bërë këtë, në strukturën e projektit në dosje src Le të krijojmë një paketë ru.javarush.endpoint, dhe në të do të krijojmë një klasë HelloWebServicePublisher me metodën kryesore: paketë ru. javarush. pika e fundit; // klasë për drejtimin e një serveri në internet me shërbime në internet import javax. xml. ws. Pika e fundit; // klasa e shërbimit tonë të internetit import ru. javarush. ws. HelloWebServiceImpl; klasa publike HelloWebServicePublisher ( kryesore publike statike e zbrazët (String... args) ( // filloni serverin në internet në portin 1986 // dhe në adresën e specifikuar në argumentin e parë, // filloni shërbimin e uebit të kaluar në argumentin e dytë Pika e fundit. publikoj( "http://localhost:1986/wss/hello", i ri HelloWebServiceImpl () ); ) ) Tani le ta ekzekutojmë këtë klasë duke klikuar Shift + F10. Asgjë nuk do të shfaqet në tastierë, por serveri po funksionon. Ju mund ta verifikoni këtë duke shtypur rreshtin http://localhost:1986/wss/hello?wsdl në shfletuesin tuaj. Faqja që hapet, nga njëra anë, dëshmon se ne kemi një server në internet (http://) që funksionon në portin 1986 në kompjuterin tonë (localhost) dhe, nga ana tjetër, tregon një përshkrim WSDL të shërbimit tonë të internetit. Nëse e ndaloni aplikacionin, përshkrimi do të bëhet i padisponueshëm, si dhe vetë shërbimi në internet, kështu që ne nuk do ta bëjmë këtë, por do të kalojmë në shkrimin e klientit.

Klienti

Në dosjen e projektit src Le të krijojmë një paketë ru.javarush.client, dhe në të klasën HelloWebServiceClient me metodën kryesore: paketë ru. javarush. klient; // nevojiten për të marrë përshkrimin wsdl dhe përmes tij // arrini vetë shërbimin në internet import java. neto. URL; // ky përjashtim do të ndodhë kur punoni me një objekt URL import java. neto. I keqformuarURLEpërjashtim; // klasa për të analizuar xml me përshkrimin wsdl // dhe arrini etiketën e shërbimit në të import javax. xml. hapësira e emrit. QEmri; import javax. xml. ws. Shërbimi; // ndërfaqja e shërbimit tonë të internetit (ne kemi nevojë për më shumë) import ru. javarush. ws. HelloWebService; klasa publike HelloWebServiceClient ( kryesore publike statike e zbrazët (String args) hedh MalformedURLException ( // krijoni një lidhje me përshkrimin e wsdl URL-ja e URL-së= URL e re ( "http://localhost:1986/wss/hello?wsdl") ; // Ne shikojmë parametrat e konstruktorit të ardhshëm në etiketën e parë të përshkrimit WSDL - përkufizimet // shikoni argumentin e parë në atributin targetNamespace // shikoni argumentin e dytë atribut emri QName qname = new QName ("http://ws.javarush.ru/" , "HelloWebServiceImplService" ); // Tani mund të arrijmë në etiketën e shërbimit përshkrimi wsdl, Shërbimi i shërbimit= Shërbimi. krijoj (url, qname) ; // dhe pastaj deri te etiketa e portit e vendosur në të, në mënyrë që // merrni një lidhje me një objekt shërbimi ueb të largët nga ne HelloWebService përshëndetje = shërbim. getPort (HelloWebService.class); // Ura! Tani mund të telefononi metodë në distancë Sistemi. jashtë. println (përshëndetje. getHelloString ("JavaRush")); ) ) Kam dhënë komente maksimale për kodin në listë. Nuk kam asgjë për të shtuar, kështu që le të ekzekutojmë (Shift+F10). Duhet të shohim tekstin në tastierë: Përshëndetje, JavaRush! Nëse nuk e keni parë, atëherë ndoshta keni harruar të filloni shërbimin në internet.

konkluzioni

Në këtë temë u prezantua ekskursion i shkurtër te shërbimet e internetit. Edhe një herë, do të them se shumë nga ato që kam shkruar janë supozimi im se si funksionon, dhe për këtë arsye nuk duhet të më besoni shumë. Do të isha mirënjohës nëse njerëz të ditur Do të më korrigjojnë, sepse atëherë do të mësoj diçka. UPD.

Gjuha e përshkrimit të shërbimeve të uebit (WSDL)

Në shembujt e fundit, mund të keni parë disa copa të kodit WSDL. Kujtoni se WSDL është një gramatikë e bazuar në XML e krijuar për të përshkruar se si klientët e jashtëm mund të ndërveprojnë me metodat e uebit të disponueshme nëpërmjet në këtë adresë URL brenda secilit protokoll komunikimi të mbështetur. Në shumë mënyra, një dokument WSDL mund të mendohet si një "kontratë" midis klientit të shërbimit të Uebit dhe vetë shërbimit të Uebit. Kjo është një tjetër metagjuhë. Në mënyrë të veçantë, WSDL përdoret për të përshkruar karakteristikat e mëposhtme ndonjë metodë e aksesueshme në internet:

Emri i metodës XML Web;

Numri, lloji dhe renditja e parametrave (nëse ka);

Lloji i kthimit (nëse ofrohet);

Kushtet e thirrjes HTTP GET, HTTP POST dhe SOAP.

Në shumicën e rasteve, dokumentet WSDL gjenerohen automatikisht nga serveri përkatës në ueb. Kujtoni se kur shtoni prapashtesën ?wsdl në Adresa URL duke treguar një skedar *.asmx, serveri i uebit gjeneron një dokument WSDL për shërbimin e specifikuar XML Web.

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

Por nëse IIS gjeneron automatikisht dokumentin WSDL për një shërbim të caktuar XML Web, pse atëherë keni nevojë për një kuptim të thellë të sintaksës së të dhënave të krijuara WSDL? Përgjigja zakonisht varet nga mënyra se si do të përdoret shërbimi juaj aplikacionet e jashtme. Për shërbimet XML Web të destinuara për përdorim "të brendshëm", WSDL-ja e gjeneruar nga serveri në internet zakonisht do të jetë e mjaftueshme.

Ndërkohë. Është plotësisht e mundur të filloni të zhvilloni një shërbim XML Web duke krijuar një dokument WSDL me dorë (siç u diskutua më lart). Ideja kryesore e fillimit të zhvillimit duke krijuar një dokument WSDL lidhet me çështjet e përputhshmërisë. Mos harroni se përpara specifikimit WSI, ishte e zakonshme që mjete të ndryshme të ndërtimit të shërbimeve të Uebit të gjeneronin përshkrime të papajtueshme WSDL. Nëse filloni zhvillimin me kodin WSDL, mund ta ndërtoni dokumentin sipas nevojës.

Siç mund ta merrni me mend, fillimi i një shërbimi XML Web duke krijuar një dokument WSDL kërkon një njohuri shumë të mirë të gramatikës WSDL, e cila nuk diskutohet në kontekstin e këtij kapitulli. Por ne do të shqyrtojmë struktura bazë Dokumenti WSDL. Pasi të kuptoni bazat, mund të vlerësoni dobinë e mjetit linja e komandës wsdl.exe.

Komentoni. Informacionet më të fundit rreth Gjuha WSDL mund të gjendet në http://www.w3.org/tr/wsdl.

Përcaktimi i një dokumenti WSDL

Dokumenti aktual WSDL hapet dhe mbyllet nga elementi rrënjë ‹definitions›. Përshkruesi i hapjes zakonisht përcakton atribute të ndryshme xmlns. Ato përcaktojnë hapësirat e emrave XML që përcaktojnë nën-elemente të ndryshme. Së paku, elementi ‹definitions› duhet të tregojë hapësirën e emrave ku janë përcaktuar vetë elementët WSDL (http://schemas.xmlsoap.org/wsdl). Për të qenë i dobishëm, përshkruesi i hapjes ‹përkufizime› duhet të specifikojë gjithashtu hapësirat e emrave XML që përcaktojnë llojet e thjeshta të të dhënave WSDL, llojet e skemës XML, elementët SOAP dhe hapësirën e emrave të synuar. Për shembull, kjo është se si duket seksioni ‹përkufizime› për shërbimin tonë të uebit të kalkulatorit.

‹wsdl:përkufizime xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"

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

xmlns:soapence="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:përkufizime ›

Në kontekstin e elementit rrënjë, mund të gjeni pesë nënelemente. Forma e përgjithshme Dokumenti WSDL duhet të jetë diçka e tillë.

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

‹wsdl:përkufizime…›

‹wsdl:llojet›

‹!-- Lista e llojeve të disponueshme për këtë shërbim ueb --›

‹wsdl:/types›

‹wsdl:message›

‹!-- Formati i mesazhit --›

‹wsdl:/message›

‹wsdl:portType›

‹!-- Informacioni i portit --›

‹wsdl:/portType›

‹wsdl:binding›

‹!-- Informacion detyrues --›

‹wsdl:/binding›

‹wsdl:service›

‹!-– Informacion rreth vetë shërbimit XML Web --›

‹wsdl:/service›

‹wsdl:/definitions›

Siç do të prisnit, secili prej këtyre nënelementeve do të përmbajë elemente dhe atribute shtesë që sqarojnë më tej përshkrimin e aftësive të disponueshme. Le të shohim nyjet më të rëndësishme të vlefshme një nga një.

Elementi ‹llojet›

Fillimisht do të shikojmë elementin ‹llojet›, i cili përmban përshkrime të të gjitha llojeve të të dhënave të ofruara nga shërbimi Web. Ju mund ta dini këtë Gjuha XML vetë përcakton një numër të llojeve të të dhënave "bazë", të cilat të gjitha përcaktohen brenda hapësirës së emrave XML http://www.w3.org/2001/XMLSchema (i cili duhet të specifikohet në kontekstin e elementit rrënjësor ‹definitions›). Merrni, për shembull, metodën Subtract() të shërbimit tonë të kalkulatorit në ueb, i cili ka dy parametra të hyrjes së numrave të plotë. Në terma WSDL, gjuha e zakonshme e tipit të kohës së ekzekutimit System.Int32 përshkruhet në kontekstin e elementit ‹complexType›.

‹s:element name= "Zbris"›

‹s:sequence›

‹s:element minOccurs=" 1 "maxOccurs=" 1 "emri = " x"type=" s:int" /›

‹s:element minOccurs="" 1 "maxOccurs=" 1 "emri = " y"type=" s:int" /›

‹/s:sequence›

‹/s:complexType›

‹/s:element›

Numri i plotë i kthyer nga metoda Subtract() përshkruhet gjithashtu brenda elementit ‹types›.

‹s: emri i elementit = " SubtractResponse"›

‹s:complexType›

‹s:sequence›

‹s:element minOccurs=" 1 "maxOccurs=" 1 "emri = " ZbrisRezultati"type=" s:int"/›

‹/s:sequence›

‹ /s:complexType›

‹/s:element›

Nëse keni një metodë Web që kthen ose merr llojet me porosi të dhënat, ato do të shfaqen edhe në kontekstin e elementit ‹complexType›. Më vonë do t'i shikojmë detajet se si t'i vëmë në dispozicion llojet e të dhënave të personalizuara .NET duke përdorur metodën Web. Për hir të këtij shembulli, le të themi se përcaktoni një metodë Web që kthen një strukturë të quajtur Point.

Pika e strukturës publike (

Emri i pikës së vargut publik;

Përshkrimi WSDL për këtë "strukturë komplekse" do të dukej diçka si kjo.

‹s:complexType name=" Pika"›

‹s:sequence›

‹s:element minOccurs=" 1 "maxOccurs=" 1 "emri = " x"type=" s:int" /›

‹s:element minOccurs=" 1 "" maxOccurs=" 1 "emri = " y"lloj=" s:int" /›

‹s:element minOccurs=" 0 "maxOccurs=" 1 "emri = " Emri i pikës"type=" s:string" /›

‹/s:sequence›

‹/s:complexType›

elementi ‹mesazh›

Elementi ‹message› përdoret për të përcaktuar formatin për shkëmbimin e kërkesave dhe përgjigjeve për një metodë të caktuar Web. Për shkak se një shërbim i vetëm ueb lejon kalimin e shumë mesazheve midis një dërguesi dhe një marrësi, një dokument i vetëm WSDL lejohet të përcaktojë elemente të shumëfishta mesazhi. Në mënyrë tipike, këto përkufizime përdorin llojet e specifikuara brenda elementit ‹llojet›.

Pavarësisht nga numri i elementeve ‹message› të përcaktuara në dokumentin WSDL, ato zakonisht janë "të pranishme" në çifte. Përkufizimi i parë përfaqëson formatin hyrës të një mesazhi, dhe përkufizimi i dytë përfaqëson formatin e daljes së të njëjtit mesazh. Për shembull, metoda Subtract() e shërbimit të internetit CalculatorWebService përcakton elementët e mëposhtëm‹mesazh›.

‹wsdl: emri i mesazhit=" SubtractSoapIn"›

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

‹/wsdl:message›

‹wsdl: emri i mesazhit=" SubtractSoapOut"›

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

‹/wsdl:message›

Këtu shihni vetëm komunikimin SOAP të shërbimit përkatës. Siç u diskutua në fillim të këtij kapitulli, shërbimet XML Web mund të thirren duke përdorur SOAP ose metodat HTTP GET dhe POST. Por nëse aktivizoni komunikimin HTTP POST (shpjegohet më vonë), WSDL-ja e krijuar duhet të tregojë të dhënat e mëposhtme ‹mesazh›.

‹wsdl: emri i mesazhit=" SubtractHttpPostIn"›

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

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

‹wsdl:/message›

‹wsdl: emri i mesazhit=" SubtractHttpPostOut"›

‹emri i pjesës="Trupi" element="s0:int" /›

‹wsdl:/message›

Elementet ‹message› nuk janë shumë të dobishëm më vete. Megjithatë, këto përkufizime mesazhesh referohen nga pjesë të tjera të dokumentit WSDL.

Komentoni. Jo të gjitha metodat e Uebit kërkojnë një kërkesë dhe një përgjigje. Nëse metoda e Uebit është "njëdrejtimëshe", ajo kërkon vetëm elementin ‹message› të kërkesës. Ju mund të caktoni një metodë Web si njëkahëshe duke përdorur atributin.

elementi ‹portType›

Elementi ‹portType› përcakton lidhjet e ndryshme që mund të ndodhin midis klientit dhe serverit, dhe secila marrëdhënie e tillë përfaqësohet nga një element i ndërlidhur ‹operacioni›. Është e lehtë të merret me mend se operacionet më tipike këtu duhet të jenë SOAP, HTTP GET dhe HTTP POST. Megjithatë, ka operacione të tjera. Për shembull, një operacion i njëanshëm i lejon klientit të dërgojë një mesazh këtë server në internet por mos merrni përgjigje (kjo është si të thërrisni një metodë pa pritur një vlerë kthimi). Një operacion kërkesë-përgjigje i lejon serverit të dërgojë një kërkesë ndërkohë që klienti po përgjigjet (që mund të konsiderohet një zgjatje e operacionit të përgjigjes së kërkesës).

Për të ilustruar formatin e nën-elementit opsional ‹operacion›, merrni parasysh përkufizimin WSDL për metodën Subtract().

‹wsdl portType name= "CalculatorWebServiceSoap"›

‹wsdl: emri i operacionit=" Zbrit"›

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

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

‹ /wsdl:operation›

‹wsdl:/portType›

Vini re se si elementët ‹hyrje› dhe ‹dalje› i referohen emrit të mesazhit përkatës të përcaktuar brenda elementit ‹mesazh›. Nëse metoda Subtract() do të kishte të aktivizuar metodën HTTP POST, do të shihni elementin e mëposhtëm shtesë ‹operacion›.

‹wsdl:portType name="CalculatorWebServiceHttpPost"›

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

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

‹ wsdl:/operation›

‹wsdl:/portType›

Së fundi, vini re se nëse një metodë e dhënë Uebi përshkruhet duke përdorur veçorinë Description, elementi ‹operacion› do të përmbajë një element ‹documentation› të ndërlidhur.

Elementi ‹lidhja›

Ky element specifikon formatin e saktë të shkëmbimit GET, POST dhe SOAP. Ky është më i foluri nga të gjithë elementët që përmbahen në kontekstin e elementit rrënjë ‹përkufizim›. Për shembull, këtu është një përkufizim i një elementi ‹binding› që përshkruan se si një thirrës mund të ndërveprojë me metodën Web MyMethod(). duke përdorur sapun.

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

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

‹wsdl: emri i operacionit = " Zbrit"›

‹soap12:operation soapAction=" http://www.IntertechTraining.com/Subtract"style="dokument" /›

‹wsdl:input›

‹soap12:body use=" fjalë për fjalë" /›

‹/wsdl:input›

‹wsdl:output›

‹soap12:body use=" fjalë për fjalë" /›

‹/wsdl:output›

‹/wsdl:operation›

‹/wsdl:binding›

elementi ‹shërbimi›

Së fundi, kemi elementin ‹service›, i cili specifikon karakteristikat e vetë shërbimit të Uebit (për shembull, URL-në e tij). Detyra kryesore e këtij elementi është të përshkruajë grupin e portave të hapura nga ky server në internet. Për ta arritur këtë, elementi ‹services› mund të përdorë çdo numër elementësh të ndërlidhur ‹port› (të mos ngatërrohet me elementin ‹portType›). Kështu duket elementi ‹service› për CalculatorWebService.

‹wsdl: emri i shërbimit= "Llogaritësi WebService"›

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

Shërbim i mrekullueshëm i kalkulatorit në internet

‹/wsdl:documentation›

‹wsdl: emri i portit= "CalculatorWebServiceSoap" lidhëse= "tns:CalculatorWebServiceSoap"›

‹sapun:address location= "http://localhost:1109/CalculatorWebService/Service.asmx"/›

‹/wsdl:port›

‹wsdl:port name="CalculatorWebServiceSoap12" detyruese = tns:Llogaritësi WebServiceSoap12"›

‹soap12:address location= "http://localhost:1109/CalculatorWebService/Service.asmx"/›

‹/wsdl:port›

‹/wsdl:service›

Pra, siç mund ta shihni, kodi WSDL që kthehet automatikisht nga serveri ITS nuk është super kompleks, por duke qenë se WSDL është një gramatikë e bazuar në XML, kodi është mjaft i përmbledhur. Megjithatë, tani duhet të keni një kuptim më të mirë të rolit të WSDL, kështu që le të shohim pak më nga afër protokollet e komunikimit të shërbimeve XML Web.

Komentoni. Kujtoni që hapësira e emrave System.Web.Services.Description përmban shumë lloje që ju lejojnë të lexoni dhe përpunoni në mënyrë programore kodin e papërpunuar WSDL (kontrollojeni vetë nëse jeni të interesuar).