Serbisyo sa web wsdl. wika ng WSDL. Istraktura ng isang dokumento ng WSDL. Mga paraan ng paglikha. Mga mode ng pagpapatakbo ng WSDL. Gumawa ng interface at klase ng serbisyo

Sa sandaling itinakda nila sa akin ang gawain ng pagsisimula ng pagbuo ng mga serbisyo sa Web at binigyan ako ng mga mapagkukunan ng isang simpleng proyekto nang walang anumang paliwanag. Ang proyekto, siyempre, ay hindi nagsimula. Wala rin akong ideya kung ano ang Spring at kung paano ito gumana. Hindi rin ako makahanap ng sapat na mga artikulo sa pagbuo ng mga serbisyo sa Web gamit ang Spring, alinman sa Russian o sa Ingles. Kinailangan kong malaman ito sa aking sarili, ngunit hindi ito nakakatakot.
At kamakailan ay nagpasya akong tingnan kung anong mga bagong tampok ang naidagdag sa Spring mula noon at i-update ang mga lumang serbisyo, na bilang isang resulta ay nag-udyok sa akin na isulat ang artikulong ito.

Ang artikulong ito ay isang gabay sa pagbuo ng isang simpleng serbisyo sa Web gamit ang SOAP protocol gamit ang Spring-WS.

At kaya, magsusulat kami pinakasimpleng serbisyo, na kumukuha ng username at nagpapadala ng pagbati at kasalukuyang panahon sa server.

Ano ang kailangan natin?
  • IDE. Eclipse ang gamit ko.
Paghahanda para sa trabaho
Gumawa tayo ng bagong proyekto sa Web application. Sa Eclipse ito ay: "File => New => Dynamic Web Project".
Pinangalanan ko ang proyekto: HelloService.
Susunod, kopyahin ang mga aklatan mula sa Spring, XMLBean, wsdl4j, commons-logging sa direktoryo ng proyekto ng WEB-INF/lib.
Kung nais mo, maaari mong idagdag ang mga ito sa mga library ng server upang hindi dalhin ang mga ito sa bawat aplikasyon.
Paglikha ng WSDL Schema
Mahalaga, ang isang WSDL schema ay idinisenyo upang ilarawan ang isang serbisyo.
Siyempre, hindi namin ito gagawin nang manu-mano. Awtomatikong mabubuo ang schema gamit ang Spring, ngunit higit pa doon sa ibang pagkakataon.
Pagtukoy sa data ng input at output
Input na data:
  • Pangalan ng string.
Output:
  • String na pagbati;
  • Ang oras ay ang kasalukuyang oras.
Paglikha ng isang paglalarawan ng input at output data
Sa direktoryo ng WEB-INF, lumikha ng HelloService.xsd file. Kakailanganin ang file na ito upang makabuo ng WSDL schema at lumikha ng kaukulang mga klase ng Java.
Teksto ng file:

Katangian targetNamespace– ginamit ang namespace. Yung. lahat ng ginawang object ay makikita sa org.example.helloService package.
Mga elemento Kahilingan sa Serbisyo At ServiceResponse ilarawan ang input at output data (kahilingan/tugon) ayon sa pagkakabanggit.
Mga Katangian minNangyayari At maxOccurs tukuyin ang bilang ng mga pag-uulit ng isang ibinigay na bahagi sa loob ng isang elemento. Kung ang mga parameter na ito ay hindi tinukoy, kung gayon bilang default, ang mga ito ay itinuturing na katumbas ng 1. Para sa isang opsyonal na bahagi, dapat mong tukuyin ang minOccurs=0. Sa walang limitasyong bilang ng mga bahagi: maxOccurs=unbounded.
Maaari kang magbasa nang higit pa tungkol sa mga XML schema.
Paglikha ng JavaBeans
Batay sa ginawang scheme, gagawa kami ng mga klase ng Java. Upang gawin ito, lumikha ng isang build.xml file:

Parameter WS_HOME dapat tumuro sa direktoryo kung saan matatagpuan ang XMLBeans.
HelloService.xsd– landas patungo sa nilikhang circuit.
lib\helloservice.jar– lumikha ng java library.

Susunod, patakbuhin ang Ant-build (Sana na-install mo na ito).
Sa Eclipse maaari mong patakbuhin ito tulad nito: RMB sa file build.xml => Run As => Ant Build.
Kung sa pamamagitan ng command line:
ant -buildfile build.xml
Well, hinihintay namin na matapos ang construction. Pagkatapos nito, maaari nating suriin ang direktoryo ng proyekto ng WEB-INF\lib para sa pagkakaroon ng kaukulang library (helloservice.jar).

Pagpapatupad ng serbisyo
Gumawa ng interface at klase ng serbisyo
Interface ng serbisyo: HelloService.java:
package org.example; import java.util.Calendar; pampublikong interface HelloService ( public String getHello(String name) throws Exception; public Calendar getCurrentTime(); )
Pagpapatupad ng serbisyo: HelloServiceImpl.java:
package org.example; import java.util.Calendar; import org.springframework.stereotype.Service; Ang @Service public class na HelloServiceImpl ay nagpapatupad ng HelloService ( public String getHello(String name) throws Exception ( return "Hello, " + name + "!"; ) public Calendar getCurrentTime() ( return Calendar.getInstance(); ) )
Ang code na ito, sa palagay ko, ay hindi nangangailangan ng mga komento. Ang tanging bagay na maaaring magbangon ng mga tanong para sa mga taong hindi pa nakatagpo ng Spring ay ang @ Service annotation Ngunit sasabihin ko sa iyo ang tungkol dito sa ibang pagkakataon.
Endpoint
Endpoint – isang klase na magiging responsable para sa pagproseso ng mga papasok na kahilingan (isang uri ng entry point).

Lumikha ng HelloServiceEndpoint.java file:
package org.example; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.ws.server.endpoint.annotation.Endpoint; import org.springframework.ws.server.endpoint.annotation.PayloadRoot; import org.example.helloService.ServiceRequestDocument; import org.example.helloService.ServiceRequestDocument.ServiceRequest; import org.example.helloService.ServiceResponseDocument; import org.example.helloService.ServiceResponseDocument.ServiceResponse; @Endpoint public class HelloServiceEndpoint( private static final String namespaceUri = "http://www.example.org/HelloService"; private HelloService helloService; @Autowired public void HelloService (HelloService helloService) ( this.helloService = helloService; )( @Payload localPart = "ServiceRequest", namespace = namespaceUri) public ServiceResponseDocument getService(ServiceRequestDocument request) throws Exception ( ServiceRequestDocument reqDoc = request; ServiceRequest req = reqDoc.getServiceRequest(); ServiceResponseDocument respDoc = ServiceResponseDocument.Factor=ServiceResponseDocument.Factor; addNewServiceResponse(); String userName();
Ano ang ginawa dito?
Anotasyon @Endpoint tiyak na tinutukoy iyon klaseng ito magpoproseso ng mga papasok na kahilingan.
namespaceUri– ang parehong namespace tulad ng tinukoy kapag lumilikha ng xml schema.

Ngayon bumalik tayo ng kaunti at tandaan ang tungkol sa anotasyon @Serbisyo. Nang hindi pumunta sa mga detalye upang hindi ma-overload ang mambabasa ng hindi kinakailangang impormasyon, ang anotasyong ito ay nagsasabi sa Spring na lumikha ng naaangkop na bagay At ang anotasyon @Autowired nagsisilbi para sa iniksyon (awtomatikong pagpapalit) ng kaukulang bagay. Siyempre, kapag gumagawa ng mga simpleng application, walang saysay na gamitin ang mga anotasyong ito, ngunit nagpasya pa rin akong huwag isama ang mga ito sa halimbawang ito.

Ang natitira, muli, ang lahat ay dapat na malinaw. Pakitandaan na ang ServiceRequest, ServiceResponse, atbp. – ito ang eksaktong mga klase na nilikha batay sa aming xml schema.

Configuration ng serbisyo sa tagsibol
Nalalapit na ngayon ang wakas.
Gumawa ng service-ws-servlet.xml file.

sws:annotation-driven– nangangahulugan lamang ito na ang mga anotasyon ay ginagamit sa proyektong ito.
A context:component-scan ay nagpapahiwatig ng package kung saan hahanapin ang mga anotasyon, at isasagawa rin ang paghahanap sa mga subpackage.

Ang dalawang kasunod na bin ay palaging hindi magbabago. Ang kanilang kakanyahan ay tumanggap at mag-convert ng kahilingan mula sa Xml sa isang Java object at higit pang baligtarin ang conversion.

sws:dynamic-wsdl ay responsable para sa awtomatikong pagbuo ng isang WSDL na dokumento batay sa ginawang XML schema.
lokasyon ay nagpapahiwatig ng landas patungo sa schema.
lokasyonUri– ang address (na may kaugnayan sa lalagyan) kung saan magiging available ang WSDL schema.
Sa aking kaso ang WSDL ay magagamit sa sumusunod na address:
localhost/HelloService/HelloService.wsdl

Deployment Descriptor
At sa wakas, ang huling bagay.
Sa direktoryo ng WEB-INF binabago o ginagawa namin ang web.xml file.
HelloService HelloService serbisyo-ws org.springframework.ws.transport.http.MessageDispatcherServlet transformWsdlLocations totoo serbisyo-ws /*
Hindi ko na ilalarawan ang file na ito; Para sa mga simpleng proyekto, mahalagang hindi ito dapat magbago. Nararapat lamang na tandaan na ang pangalan ng servlet (pangalan ng servlet) ay dapat tumugma sa pangalan ng file ng pagsasaayos ng serbisyo ng Spring serbisyo-ws-servlet.xml.
Pagsusuri sa pag-andar
Ang pinakaunang tanda tamang operasyon ay ang nabuong WSDL schema.
Upang suriin, pumunta lamang sa address ng scheme na ito (http://localhost/HelloService/HelloService.wsdl) at tingnan: ang xml file ay dapat na ipakita doon. Kung walang ipinapakita o may lumilitaw na error, muling basahin nang mabuti ang buong artikulo at hanapin kung ano ang mali namin.

Para sa karagdagang pagsubok kailangan namin ng soapUI (Mayroon akong bersyon 3.0.1).
I-install at ilunsad ito.
Gumawa ng bagong proyekto: File => Bagong SoapUI Project. Sa Initial WSDL/WADL field, maglagay ng link sa WSDL schema (http://localhost/HelloService/HelloService.wsdl).
Sa ginawang proyekto, buksan ang kinakailangang kahilingan.

Ipasok ang pangalan sa field na Pangalan at mag-click sa pindutang "Ipadala ang kahilingan".


Bilang resulta, nakatanggap kami ng tugon mula sa server na may pagbati at kasalukuyang oras.


Kung may mali, basahin muli ang artikulong ito.

Ano ang susunod?
Well, ang susunod na hakbang ay ang pagsulat ng isang kliyente para sa serbisyong ito sa Web. Ngunit ito ay materyal na para sa isa pang artikulo, na maaaring isulat sa ibang pagkakataon, kung materyal na ito may magiging interesado.

Paunang Salita

Tinanong ng mga customer ng mga customer ang mga customer xsd file para sa mga istrukturang ipinasa ng ipinatupad na mga serbisyo sa Web. Tumugon ang mga customer sa pamamagitan ng pag-imbita sa mga customer ng mga customer na lumikha ng mga WSDL. yun. biglang, "out of the blue," bumangon ang pangangailangan na gumawa hindi lamang ng mga xsd schema para sa pagpapatunay ng data, ngunit "buong mga WSDL." Karaniwan ang mga WSDL ay ginagamit para sa SOAP, ngunit gumagamit kami ng REST...

Isinulat ko dati ang tungkol sa

Panimula

Ang terminong mga serbisyo sa Web ay karaniwang nauugnay sa mga serbisyong nakabatay sa operasyon o aksyon batay sa mga pamantayan ng SOAP o WS* gaya ng WS-Addressing o WS-Security. Ang terminong REST Web services ay karaniwang tumutukoy sa isang resource-based na arkitektura ng mga serbisyo sa Web na nakikipag-usap sa XML sa HTTP. Ang bawat isa sa mga istilong arkitektura na ito ay may sariling lugar, ngunit hanggang kamakailan lamang, hindi sinusuportahan ng pamantayan ng WSDL ang parehong mga istilong ito. Ang WSDL 1.1 HTTP binding ay hindi sapat upang ilarawan ang pakikipag-ugnayan sa gamit ang XML sa pamamagitan ng HTTP, i.e. Walang pormal na paraan upang ilarawan ang mga serbisyo sa REST Web gamit ang WSDL. Paglalathala ng pamantayang WSDL 2.0 (na binuo na isinasaalang-alang ang pangangailangang ilarawan ang mga serbisyo sa REST Web) sa status ng rekomendasyon World Wide Ang Web Consortium (W3C) ay nagbigay ng wika para sa paglalarawan ng REST Web services.

Ang REST ay isang istilong arkitektura na itinuturing ang Web bilang isang resource-centric na application. Sa praktikal, nangangahulugan ito na ang bawat URL sa isang RESTful na application ay kumakatawan sa isang mapagkukunan. Ang mga URL ay madaling maunawaan at matandaan. Halimbawa, maaaring tukuyin ng isang bookstore ang URL http://www.bookstore.com/books/ para sa isang listahan ng mga aklat na kanilang ibinebenta at http://www.bookstore.com/books/0321396855/ para sa mga detalye tungkol sa isang partikular na aklat na may ISBN 0321396855. Kabaligtaran ito sa mga application na nakasentro sa pagkilos, kadalasang mayroong mahaba, kumplikadong mga URL na naglalarawan sa mga aksyon na isasagawa, halimbawa http://www.bookstore.com/action/query?t=b&id=11117645532&qp=0321396855 . Ginagamit ang mga parameter ng query upang piliin ang kinakailangang data. Gamit ang halimbawa ng bookstore, ang pagtukoy sa parameter ng paksa ay naglilimita sa paksa ng aklat. Halimbawa, mga kwentong pisika o detective, o halimbawa ang URL na http://www.bookstore.com/books/?subject=computers/eclipse - isang kahilingang nagbabalik ng listahan ng mga aklat tungkol sa platform ng Eclipse.

Ang terminong REST ay likha ni Roy Fielding sa kanyang PhD thesis. Tiningnan niya ang mga hyperlink bilang isang paraan ng pagbabago (pag-iimbak) ng estado ng isang aplikasyon. Ang mga hyperlink ay naka-imbak sa mga mapagkukunan ng aplikasyon at isang paraan ng pagbabago ng estado ng aplikasyon, na nagre-redirect mula sa isang estado patungo sa isa pa. Karaniwan ang mga hyperlink sa (X)HTML ay inilaan para sa paggamit ng mga tao; Tulad ng (X)HTML, ang REST Web services ay gumagamit ng mga hyperlink sa XML.

Ang mga tradisyunal na Web application ay nag-a-access ng mga mapagkukunan sa pamamagitan ng HTTP GET o POST na mga operasyon. Gumagana ang mga RESTfull na application sa mga mapagkukunan sa istilong "lumikha, magbasa, mag-update, at magtanggal (CRUD)" gamit ang buong kakayahan HTTP protocol (POST, GET, PUT, at DELETE).

Isa pang mahalagang tala tungkol sa mga RESTful na application: Ang mga RESTful na application ay dapat na walang estado. Nangangahulugan ito na ang isang REST application ay hindi nagpapanatili ng anumang estado ng session sa gilid ng server. Ang lahat ng impormasyong kinakailangan upang makumpleto ang kahilingan ay ipinadala sa mismong kahilingan. (Samakatuwid, dapat tumugon ang server sa mga paulit-ulit na kahilingan sa parehong paraan. Tala ng tagasalin). Alinsunod dito, maaaring i-cache ng kliyente ang mga natanggap na mapagkukunan, na maaaring makabuluhang mapabilis ang bilis ng application kung saan tahasang pinapayagan ito ng serbisyo. Upang matuto nang higit pa tungkol sa REST, tingnan ang mga link sa artikulo.

WSDL at REST

Ang WSDL ay naglalaman ng lahat ng mga detalye tungkol sa serbisyo sa web kabilang ang:

    URL ng serbisyo sa web
    Mga mekanismo ng komunikasyon na naiintindihan ng serbisyo sa web
    Mga pagpapatakbo na maaaring gawin ng isang serbisyo sa web
    Istraktura ng mensahe ng serbisyo sa web

Maaaring gamitin ng mga kliyente ang mga nakalistang detalye upang makipag-ugnayan sa serbisyo.

Ang WSDL 2.0 ay idineklara na isang rekomendasyon ng W3C noong Hunyo 2007. Ang bersyon na ito ng pamantayan ng WSDL ay inilabas upang tugunan ang mga isyu sa pamantayan ng WSDL 1.1, na marami sa mga ito ay natuklasan ng organisasyong Web Services Interoperability (WS-I). Bilang karagdagan, ang WSDL 2.0 ay nagpabuti ng suporta para sa mga HTTP binding.

Ang WSDL mismo ay XML, isang subset na pormal na naglalarawan ng isang serbisyo sa web. Isipin ang paglalarawan ng WSDL ng isang serbisyo sa web bilang kontrata ng API nito sa kliyente. Tinukoy ng WSDL ang address, mga katanggap-tanggap na paraan ng pagpapadala ng impormasyon, mga interface, at mga uri ng mensahe ng serbisyo sa web. Sa madaling salita, ang isang paglalarawan ng WSDL ay naglalaman ng lahat ng impormasyon na kailangan ng isang kliyente upang magamit ang isang serbisyo sa web.

Ang kakayahang magamit ng WSDL ay umaabot nang higit pa sa paggamit nito bilang isang kontrata ng API. Bilang isang pormal na kahulugan, ang WSDL ay maaaring gamitin ng software upang pasimplehin ang pagpapatupad ng mga serbisyo sa web para sa mga operasyon tulad ng:

  • Pagbuo ng source code para sa isang client application at server para sa isang web service sa iba't ibang programming language
  • Pag-publish ng serbisyo sa web
  • Pagsubok sa serbisyo ng dinamikong web

Karamihan sa software ng mga serbisyo sa web ay may kasamang suporta para sa WSDL 1.1. Kamakailan, dumarami ang bilang ng mga tool sa pagbuo ng serbisyo sa web na sumusuporta sa WSDL 2.0. Ang proyekto ng mga serbisyo ng Apache Web ay binubuo ng dalawang subproject na kasalukuyang sumusuporta sa WSDL 2.0. Si Woden ay isang Java-based na WSDL 2.0 parser-validator. Ang proyekto ng mga serbisyo ng Apache Web ay nagbibigay din ng isang XSL (XSLT) WSDL 2.0 na pagbabagong tinatawag WSDL 2.0 magandang printer, na nagbibigay ng mas mahusay na pagiging madaling mabasa ng tao ng dokumento ng WSDL. Ang Axis2 ay isang sikat na web services engine (mula rin sa Apache) na bumubuo ng client at server ng Java code mula sa isang WSDL 2.0 na dokumento.

Paglalarawan ng isang REST web service gamit ang WSDL 2.0

Gumawa ka ng bookstore na may advanced na URL: http://www.bookstore.com. Nakagawa ka na ng dalawang REST Web services:

  • listahan ng libro - ang serbisyo ay tumatanggap ng listahan ng mga aklat na ibinebenta mo.
  • mga detalye ng libro - ang serbisyo ay tumatanggap ng impormasyon tungkol sa isang partikular na libro.

Ang tugon ay ibinalik sa mga dokumentong XML.

Elemento interface tumutukoy sa isang listahan ng mga pagpapatakbo ng serbisyo sa web, kabilang ang isang paglalarawan ng input, output, at mga mensahe ng error para sa mga pagpapatakbo, pati na rin ang pagkakasunud-sunod ng paghahatid.

Elemento nagbubuklod tinutukoy ang paraan ng komunikasyon sa pagitan ng kliyente at ng serbisyo sa web. Sa kaso ng REST web services, ang HTTP ay tinukoy bilang paraan ng komunikasyon.

Iniuugnay ng elemento ng serbisyo ang mga address ng serbisyo sa web sa mga partikular na interface at binding. (Iyon ay, itinatakda nito ang pagsusulatan sa pagitan ng URL ng pagpapatakbo ng serbisyo sa web at ng elemento nagbubuklod).

I-bind ang listahan ng aklat sa HTTP

Elemento nagbubuklod tumutukoy sa pagbubuklod ng serbisyo sa web sa isang partikular na protocol ng paglilipat ng data. Upang i-bind ang serbisyo ng listahan ng libro sa HTTP, kailangan mong tukuyin ang value na http://www.w3.org/ns/wsdl/http para sa attribute uri elemento nagbubuklod.

Elemento nagbubuklod maaaring opsyonal na sumangguni sa interface. Iwanan ang katangian interface walang laman. Gagawin mo ito sa susunod na seksyon. Kung interface nauugnay sa nagbubuklod, Pagkatapos nagbubuklod maaaring opsyonal na tukuyin ng isang elemento ang isang elemento ng bata operasyon, na salamin para sa pagpapatakbo ng interface elemento. Kailangan mong gumawa ng element stub operasyon at punan ang link sa operasyon mamaya pagkatapos ng paglikha interface.

Mayroong 4 na paraan ng komunikasyon sa HTTP

  • I-DELETE

Binabasa ng serbisyo ng listahan ng libro ang kahilingan at gumagana nang naaayon gamit ang HTTP GET. Itakda ang GET method para sa operatioin element gamit ang method attribute mula sa WSDL 2.0 HTTP namespace. Upang magamit ang katangiang ito, kailangan mo munang tukuyin ang namespace http://www.w3.org/ns/wsdl/http sa elemento paglalarawan.

Ang serbisyo sa pag-binding ng listahan ng libro ay tinukoy sa sumusunod na listahan. Tukuyin ngayon nagbubuklod sa elemento endpoint: tns:BookListHTTPBinding.

Serbisyo ng listahan ng libro ng bookstore.

Kahulugan ng pagpapatakbo ng serbisyo ng listahan ng libro

Sa ngayon, natutunan mo kung paano tugunan at makipag-ugnayan sa serbisyo sa Web ng listahan ng libro. Susunod na tinukoy mo ang pagpapatakbo ng serbisyo ng listahan ng aklat, na naglalarawan kung ano ang ginagawa ng serbisyo ng listahan ng aklat.

Kaya, natutunan mo kung paano itakda ang address at itakda ang pagbubuklod (paraan ng komunikasyon) para sa serbisyo sa web. Susunod, kailangan mong magtakda ng operasyon ng serbisyo, na tumutukoy kung ano ang ginagawa ng serbisyo sa web ng listahan ng libro.

Ang elemento ng interface at ang elemento ng child operation nito ay ginagamit upang tukuyin ang mga pagpapatakbo ng serbisyo. Sa kaso ng listahan ng aklat, tutukuyin mo ang isang solong operasyon, getBookList, na nagbabalik ng listahan ng mga aklat.

Susunod, tukuyin ang tatlong katangian para sa elemento ng pagpapatakbo:

Pattern

Ginagamit upang tukuyin ang isang pattern ng pagmemensahe pattern ng pagpapalitan ng mensahe(MEP) para sa operasyon. Tinutukoy ng MEP ang pagkakasunud-sunod ng mga mensahe para sa isang operasyon at ang kanilang direksyon. Sa kasong ito, dapat mong tukuyin ang halaga http://www.w3.org/ns/wsdl/in-out upang ipahiwatig na ang serbisyo sa web ay tumatanggap ng isang input message na humihiling ng isang listahan ng mga libro, at nagpapadala ng isang output na mensahe na humihingi ng isang listahan ng mga libro. Upang suportahan ang MEP na ito, mangyaring tukuyin elemento ng bata input At output para sa elemento operasyon. Ginagamit ng mga elementong ito ang mga elementong inilarawan sa XML schema upang tukuyin ang mga istruktura ng mensahe. Mga detalye sa susunod na seksyon.

Estilo

Ginagamit upang ipahiwatig karagdagang impormasyon tungkol sa trabaho. Tukuyin ang halaga http://www.w3.org/ns/wsdl/style/iri , na nagpapataw ng mga paghihigpit sa nilalaman ng mga elemento ng pag-input, tulad ng pag-aatas na gumamit lamang ito ng mga elemento ng XML schema.

wsdlx:safe

wsdlx:safe: Mula sa namespace ng mga extension ng WSDL, ipinapahayag ng katangiang ito na ang operasyong ito ay idempotent. Hindi binabago ng ganitong uri ng operasyon ang mapagkukunan at samakatuwid ay maaaring tawagin nang maraming beses na may parehong mga resulta. Upang magamit ang elementong ito, ideklara ang namespace ng mga extension ng WSDL http://www.w3.org/ns/wsdl-extensions sa elemento ng paglalarawan.

Ang attribute na ito ay mula sa WSDL extensions namespace. Tinutukoy nito na ang operasyon ay idempotent. Hindi binabago ng operasyong ito ang mapagkukunan, kaya maaari itong tawagan nang maraming beses na may parehong mga resulta. Upang magamit ang elementong ito, dapat mong ideklara ang namespace na mga extension ng WSDL http://www.w3.org/ns/wsdl-extensions sa root element (element ng paglalarawan).

Mahahanap mo ang paunang natukoy na Mga Pattern ng Pagpapalitan ng Mensahe, mga istilo at wsdlx:safe na mga kahulugan sa WSDL 2.0 Part 2: Adjuncts

Nasa ibaba ang kahulugan ng serbisyo ng listahan ng aklat na may idinagdag na paglalarawan interface. Pagkatapos idagdag ang interface, maaari mo na ngayong baguhin ang binding operation element upang tukuyin ang mga link sa inilarawan interface At operasyon.

Ang RESTful HTTP binding para sa serbisyo ng listahan ng libro. Serbisyo ng listahan ng libro ng bookstore.

Pagtukoy sa mga mensahe ng serbisyo sa pagpapatakbo ng listahan ng libro

Web serbisyo ng libro Ang listahan ay gumagamit ng dalawang mensahe: input at output. Dapat mong ilarawan ang mga istruktura ng mga mensaheng ito upang malaman ng mga programa ng kliyente kung ano ang ipapadala sa serbisyo at kung ano ang aasahan pabalik.

Sinusuportahan ng WSDL 2.0 ang maraming uri ng mga sistema para sa paglalarawan ng nilalaman ng mensahe, ngunit ang XML schema ay ang tanging ginagamit. Hindi saklaw ng seksyong ito ang mga detalye ng XML schema. Ginagamit ang XML schema sa maraming iba pang mga application, tulad ng WSDL 1.1, at maraming magagandang artikulo tungkol dito. Ang seksyong ito ay nagha-highlight kung paano gumamit ng XML schema para sa listahan ng aklat na REST Web service at kung paano gumamit ng mga karagdagang attribute na tinukoy ng WSDL 2.0 para i-annotate ang isang schema attribute.

Sinusuportahan ng WSDL 2.0 ang maraming uri ng mga sistema ng kahulugan, ngunit sa pagsasanay ay ginagamit lamang ang XML schema. Ang artikulong ito ay hindi pumunta sa detalye tungkol sa XML schema. Ginagamit ang XML schema sa maraming iba pang mga application, tulad ng WSDL 1.1, at maraming magagandang artikulo tungkol dito. (). Ang seksyong ito ay nagpapakita ng paggamit ng XML schema kaugnay ng isang partikular na halimbawa ng isang listahan ng aklat na REST service, pati na rin ang paggamit ng mga karagdagang attribute na tinukoy sa WSDL 2.0 para sa schema attribute annotation.

Upang ilarawan ang 2 mensahe para sa isang listahan ng aklat, kailangan mong ilarawan ang 2 pandaigdigang elemento.

  • getBookList kumakatawan sa input message. Naglalaman ito ng pagkakasunod-sunod ng mga elemento, kasama ang bawat parameter ng kahilingan na pinapayagan para sa serbisyo: awtoridad, pamagat, publisher, paksa At wika. Mga elemento lamang ang maaaring gamitin sa loob ng getBookList na mensahe dahil ang istilo ng IRI ay pinili para sa pagpapatakbo ng interface.
  • BookList kumakatawan sa output na mensahe. Naglalaman ito ng pagkakasunod-sunod ng mga elemento ng libro. Ang bawat elemento ng aklat naman ay naglalaman ng mga katangian ng pamagat at url. Ang katangian ng pamagat ay maliwanag. Ang katangian ng url ay isang link sa serbisyo ng mga detalye ng aklat, na nagbabalik ng detalyadong impormasyon tungkol sa isang partikular na aklat.

Gumagamit ang iyong url attribute definition ng 2 attribute mula sa WSDL extensions namespace. Ang wsdlx:interface at wsdlx:binding attribute ay tumutukoy sa interface at binding para sa serbisyo. Maaaring gamitin ng software ang impormasyong ito upang awtomatikong mahanap ang serbisyo. Upang magamit ang mga katangiang ito, tukuyin ang namespace ng mga extension ng WSDL para sa elemento schema. Isama rin ang namespace ng mga detalye ng libro mula sa paglalarawan nitong WSDL 2.0.

Ang XML schema para sa serbisyo ng listahan ng libro ay ibinigay sa ibaba.

Ang elemento ng kahilingan para sa serbisyo ng listahan ng aklat. Ang elemento ng pagtugon para sa serbisyo ng listahan ng aklat.

Upang sumangguni sa mga elemento ng input at output, dapat mong i-import ang schema sa iyong WSDL na dokumento. Upang mag-import ng schema, gamitin ang elemento ng pag-import ng schema sa seksyon ng mga uri tulad ng ipinapakita sa listahan sa ibaba. Bukod pa rito, kailangan mong magdagdag ng mga sanggunian sa getBookList at mga elemento ng Booklist sa mga elemento ng input at output ng operasyon ng interface, at idagdag ang mga namespace ng XML schema ng listahan ng aklat sa elemento ng ugat ng WSDL.

Handa na ang WSDL para sa serbisyo sa web ng listahan ng libro.

Ito ay isang paglalarawan ng WSDL 2.0 ng isang sample na listahan ng serbisyo sa bookstore para sa pagkuha ng impormasyon ng libro. Ang operasyong ito ay nagbabalik ng isang listahan ng mga aklat. Ang RESTful HTTP binding para sa serbisyo ng listahan ng libro. Serbisyo ng listahan ng libro ng bookstore.

Tala ng tagasalin

Kinuha ko ang kalayaan na hindi isalin ang buod at mga link. Tingnan ang may-akda para sa pareho. sa orihinal na artikulo. Dapat kong sabihin na ang orihinal na wika ay napakahirap. Gayunpaman, umaasa ako na ang artikulo ay magiging kapaki-pakinabang.

WSDL (Wika ng Paglalarawan ng Serbisyo sa Web) bersyon 1.1 ay nai-publish noong Marso 15, 2001. WSDL ay isang XML-based na format na ginagamit upang ilarawan ang mga serbisyo sa web gamit ang mga mensaheng naglalaman ng impormasyon kung paano i-access ang isang partikular na serbisyo sa web. WSDL napapalawak, na nagbibigay-daan sa iyong ilarawan ang mga serbisyo (mga serbisyo) at ang kanilang mga mensahe, anuman ang mga format ng mensahe o mga protocol ng network ay ginagamit para sa transportasyon, gayunpaman, ang WSDL 1.1 ay kadalasang ginagamit kasama ng SOAP 1.1, HTTP GET/POST at MIME. kasi WSDL ay binuo nang magkasama sa SOAP, at ang parehong mga kumpanyang Microsoft, Ariba at IBM ay lumahok sa pagpapaunlad nito. Kung isasaalang-alang natin ang dokumento WSDL intuitively, masasabi nating pinapayagan nito sagutin ang 4 na tanong:

1) anong ginagawa mo? Ang sagot sa tanong na ito ay ibinigay sa isang form na angkop para sa parehong pandama ng tao at machine-perceivable form. Sagot para sa tao sa mga tag:<pangalan/>, <dokumentasyon/>, para sa kotse -<mensahe/>, <pointType>

2) anong wika ang ginagamit mo? (anong mga uri ang ginagamit mo?) Sagot sa tag:<mga uri/>

3) paano ako makikipag-usap sa iyo? (paano maa-access ng kliyente ang serbisyo sa web?): HTTP o SMTP. Ang sagot ay nasa<nagbubuklod/>

4) saan kita mahahanap? (saan ko mahahanap ang web service na ito o ano ang URL nito?). Ang sagot ay:<serbisyo/>

Istruktura:

Ang bawat dokumento ng WSDL ay maaaring hatiin sa tatlong lohikal na bahagi:

1. pagtukoy ng mga uri ng data - pagtukoy sa uri ng mga mensaheng ipinadala at natanggap ng serbisyong XML

2. abstract na mga operasyon - listahan ng mga operasyon na maaaring isagawa gamit ang mga mensahe

3. pag-uugnay ng serbisyo - ang paraan kung saan ihahatid ang mensahe

Mga dokumento WSDL ay maaaring gawin nang manu-mano, ngunit ang wika ay mahigpit na pormal WSDL nagbibigay-daan sa iyo na i-automate ang proseso ng pagsulat WSDL-mga dokumento. Maraming mga tool sa pag-akda ng serbisyo sa Web ang naglalaman ng mga utility na awtomatikong lumilikha WSDL-mga file na naglalarawan ng mga yari na serbisyo sa Web. Halimbawa, Web Services Authoring Tool Apache Axis naglalaman ng isang klase Java2WSDL, paglikha WSDL- isang file ng isang klase ng Java o interface na naglalarawan ng isang serbisyo sa Web. Ang IBM WSTK package, na kinabibilangan ng Axis, naglalaman ng utility java2wsdl, na lumilikha at nagpapatakbo ng isang bagay mula sa klase na ito. Nagtatrabaho siya mula sa command line.

Mga Elemento ng Dokumento ng WSDL

Ilarawan natin ang pinakakaraniwang ginagamit na mga tag ng WSDL:

Tag ay ang root tag ng lahat ng mga dokumento ng WSDL. Tinutukoy nito ang ilang mga namespace:

1)target Name space ay ang namespace ng aming web service

2) xmlns – karaniwang WSDL document namespace

3)xmlns: SOAP_ENC – namespace na ginamit upang ilarawan ang SOAP encoding


4) xmlns: impl at intf – ang namespace ng pagpapatupad at kahulugan ng aming serbisyo sa web

· Dokumento ng Kahulugan ng Serbisyo sa Web

· Dokumento para sa pagpapatupad ng serbisyo sa web

Para sa pagiging simple, bilang panuntunan, gumagamit sila ng 1 file na naglalaman ng lahat ng impormasyon

Elemento - nagbibigay ng impormasyon tungkol sa data na inilipat mula sa isang endpoint patungo sa isa pa.

Upang ilarawan ang isang RPC na tawag, dapat kang lumikha ng isang input message at isang output message.

Sa loob ng elementong ito, maaari mong tukuyin ang mga parameter ng pamamaraan gamit ang elemento

Elemento inilalarawan at tinutukoy ang mga operasyon o pamamaraan na sinusuportahan ng isang serbisyo sa web

Ang mga operasyon ay maaaring magkaroon ng mga mensahe ng pag-input pati na rin ng mga mensahe ng error.

Elemento - inilalarawan kung paano ipapadala ang mga operasyong tinukoy sa isang uri ng port sa network. kasi elemento ay gumagamit ng isang uri ng port, dapat itong tukuyin ang isang uri na tinukoy sa isang lugar nang mas maaga sa dokumento.

Elemento - nagsasaad kung saan mahahanap ang serbisyo sa web

Elemento import . Kadalasan ang elemento ng serbisyo ay inilalaan sa wsdl na dokumento nito para sa mga kadahilanan ng pagiging praktikal.

Upang payagan ang pagsasama-sama ng ilang wsdl na dokumento sa isa, ginagamit ang elemento ng pag-import. Pinapayagan ka nitong isama ang isang wsdl na dokumento sa isa pa.

Elemento mga uri nagbibigay-daan sa iyo na tukuyin ang mga uri ng data na ipinadala kung ang mga ito ay hindi karaniwan.

Sinusuportahan ng WSDL ang 4 na mga mode ng operasyon:

· one-way o one-way na operasyon. Ang mensahe ay ipinadala sa endpoint ng serbisyo. Sa kasong ito, ang operasyon ay inilalarawan sa pamamagitan lamang ng isang input message.

· Kahilingan-Tugon – request-response mode. Ang mode ng operasyon na ito ay ang pinaka-karaniwan. Sa mode na ito, ang paglalarawan ng operasyon ay naglalaman ng isang input at output na mensahe at isang opsyonal na mensahe ng error.

· Pagpapatakbo ng uri ng kahilingan-tugon. Sa mode na ito, ang isang endpoint ay isang kliyente ng isa pang endpoint. Ang format ng pagpapatakbo ay katulad ng mode ng kahilingan-tugon, ngunit ang data ng output ay nakalista bago ang data ng pag-input.

· Abiso sa pagpapatakbo. Ang mode na ito ay isa pang bersyon ng one-way transmission primitive, kung saan ang endpoint ay nagpapadala ng mensahe sa halip na matanggap ito. Ang operasyon ay naglalaman lamang ng isang output na mensahe.

mga sumbrero Hulyo 23, 2013 sa 01:09 pm

Pagsusulat ng SOAP application ng client-server sa PHP

  • PHP
  • Tutorial

Hi sa lahat!
Nangyari na kamakailan ay nagsimula akong bumuo ng mga serbisyo sa web. Ngunit ngayon ang paksa ay hindi tungkol sa akin, ngunit tungkol sa kung paano namin isusulat ang aming sariling XML Web Service batay sa SOAP 1.2 protocol.

Umaasa ako na pagkatapos basahin ang paksa ay magagawa mong:

  • isulat ang iyong sariling pagpapatupad ng server ng isang web application;
  • isulat ang iyong sariling pagpapatupad ng kliyente ng isang web application;
  • sumulat ng iyong sariling paglalarawan ng serbisyo sa web (WSDL);
  • ipadala ang mga array ng kliyente ng parehong uri ng data sa server.
Gaya ng nahulaan mo, lahat ng mahika ay gagawin gamit ang PHP at ang mga built-in na SoapClient at SoapServer na mga klase. Ang aming kuneho ay magiging isang serbisyo para sa pagpapadala ng mga mensaheng SMS.

1 Paglalahad ng problema

1.1 Mga Hangganan

Sa simula, iminumungkahi kong harapin ang resulta na makakamit natin sa pagtatapos ng paksa. Gaya ng inanunsyo sa itaas, susulat kami ng serbisyo para sa pagpapadala ng mga mensaheng SMS, at mas tiyak, makakatanggap kami ng mga mensahe mula sa iba't ibang mapagkukunan sa pamamagitan ng SOAP protocol. Pagkatapos nito, isasaalang-alang namin kung anong anyo ang dumating sa server. Ang proseso ng pagpila ng mga mensahe para sa karagdagang pagpapadala sa provider, sa kasamaang-palad, ay lampas sa saklaw ng post na ito para sa maraming dahilan.

1.2 Anong data ang babaguhin natin?

Mahusay, nagpasya kami sa mga hangganan! Ang susunod na hakbang na kailangang gawin ay ang magpasya kung anong data ang ipapalit namin sa pagitan ng server at ng kliyente. Sa paksang ito, iminumungkahi kong huwag hatiin ang mga buhok nang masyadong mahaba at agad na sagutin ang mga pangunahing tanong para sa iyong sarili:
  • Anong minimum na data ang dapat ipadala sa server para makapagpadala ng SMS message sa isang subscriber?
  • Anong minimum na data ang dapat ipadala mula sa server upang matugunan ang mga pangangailangan ng kliyente?
May nagsasabi sa akin na para dito kailangan mong ipadala ang sumusunod:
  • numero ng mobile phone at
  • text ng SMS message.
Sa prinsipyo, ang dalawang katangiang ito ay sapat na para sa pagpapadala, ngunit agad kong naiisip ang kaso ng isang SMS na may mga pagbati sa kaarawan na darating sa iyo sa alas-3 ng umaga, o 4! Sa sandaling ito, ako ay lubos na magpapasalamat sa lahat para sa hindi paglimot sa akin! Samakatuwid, ipapadala din namin sa server at
  • petsa ng pagpapadala ng SMS message.
Ang susunod na bagay na gusto kong ipadala sa server ay:
  • Uri ng mensahe.
Ang parameter na ito ay hindi sapilitan, ngunit maaari itong maging lubhang kapaki-pakinabang sa amin kung kailangan naming mabilis na sabihin sa boss kung gaano karami sa aming mga kliyente ang "natutuwa" sa aming balita, at gumuhit din ng ilang magagandang istatistika sa bagay na ito.

At gayon pa man, may nakalimutan ako! Kung magpapakita kami ng kaunti pa, ito ay nagkakahalaga ng pagpuna na ang kliyente ay maaaring magpadala ng alinman sa isang mensahe ng SMS o isang bilang ng mga ito sa server sa isang pagkakataon. Sa madaling salita, ang isang data packet ay maaaring maglaman mula sa isa hanggang sa mga infinity na mensahe.

Bilang resulta, nakukuha namin iyon upang magpadala ng mensaheng SMS kailangan namin ang sumusunod na data:

  • numero ng mobile phone,
  • Teksto ng mensaheng SMS,
  • oras ng pagpapadala ng mensaheng SMS sa subscriber,
  • uri ng mensahe.

Nasagot na natin ang unang tanong, ngayon kailangan nating sagutin ang pangalawang tanong. At marahil ay hahayaan ko ang aking sarili na magulo ng kaunti. Samakatuwid, mula sa server ay magpapadala lamang kami ng Boolean data, ang kahulugan nito ay may sumusunod na kahulugan:

  • TAMA – matagumpay na naabot ng packet ang server, pumasa sa pagpapatunay at nakapila para sa pagpapadala sa SMS provider
  • MALI – sa lahat ng iba pang kaso

Ito ay nagtatapos sa paglalarawan ng pahayag ng problema! At sa wakas, bumaba tayo sa nakakatuwang bahagi - alamin natin kung anong uri ng kakaibang hayop ang SOAP na ito!

2 Ano ang SOAP?

Sa pangkalahatan, sa una ay wala akong planong magsulat ng anuman tungkol sa kung ano ang SOAP at nais kong limitahan ang aking sarili sa mga link sa website ng w3.org na may mga kinakailangang detalye, pati na rin ang mga link sa Wikipedia. Ngunit sa pinakadulo nagpasya akong magsulat ng isang maikling tala tungkol sa protocol na ito.

At sisimulan ko ang aking kwento sa katotohanan na ang data exchange protocol na ito ay kabilang sa isang subset ng mga protocol batay sa tinatawag na RPC (Remote Procedure Call) paradigm, ang antipode nito ay REST (Representational State Transfer). Maaari mong basahin ang higit pa tungkol dito sa Wikipedia ang mga link sa mga artikulo ay nasa pinakadulo ng paksa. Mula sa mga artikulong ito kailangan nating maunawaan ang sumusunod: “Ang RPC approach ay nagbibigay-daan sa paggamit ng isang maliit na bilang ng mga mapagkukunan ng network Sa isang malaking bilang mga pamamaraan at kumplikadong protocol. Sa diskarte ng REST, ang bilang ng mga pamamaraan at pagiging kumplikado ng protocol ay mahigpit na limitado, na nangangahulugang ang bilang ng mga indibidwal na mapagkukunan ay maaaring malaki." Iyon ay, may kaugnayan sa amin, nangangahulugan ito na sa kaso ng diskarte ng RPC sa site ay palaging mayroong isang input (link) sa serbisyo at kung anong pamamaraan ang tatawagan upang maproseso ang papasok na data na inililipat namin kasama ang data, habang gamit ang REST approach sa aming Ang site ay may maraming input (link), na ang bawat isa ay tumatanggap at nagpoproseso lamang ng ilang data. Kung alam ng sinumang nagbabasa kung paano ipaliwanag ang pagkakaiba sa mga pamamaraang ito nang mas simple, siguraduhing sumulat sa mga komento!

Ang susunod na bagay na kailangan nating matutunan tungkol sa SOAP ay ang protocol na ito ay gumagamit ng parehong XML bilang isang transportasyon, na sa isang banda ay napakahusay, dahil Kasama agad sa aming arsenal ang buong kapangyarihan ng isang stack ng mga teknolohiya batay sa markup language na ito, katulad ng XML-Schema - isang wika para sa paglalarawan ng istruktura ng isang XML na dokumento (salamat sa Wikipedia!), na nagbibigay-daan para sa awtomatikong pagpapatunay ng data na natanggap ng server mula sa mga kliyente.

At kaya, ngayon alam namin na ang SOAP ay isang protocol na ginagamit upang ipatupad ang mga remote procedure na tawag at gumagamit ito ng XML bilang isang transportasyon! Kung babasahin mo ang artikulo sa Wikipedia, maaari mo ring malaman mula doon na maaari itong gamitin sa anumang protocol sa antas ng aplikasyon, at hindi lamang sa kumbinasyon ng HTTP (sa kasamaang palad, sa paksang ito ay isasaalang-alang lamang natin ang SOAP sa HTTP). At alam mo kung ano ang pinakagusto ko sa lahat ng ito? Kung walang hula, then I’ll give a hint - SOAP!... Still no guesses?... Sigurado ka bang nabasa mo ang artikulo sa Wikipedia?... Sa pangkalahatan, hindi na kita pahihirapan. Samakatuwid, diretso ako sa sagot: “SOAP (mula sa English Simple Object Access Protocol- simple protocol pag-access sa mga bagay; hanggang sa detalye 1.2)". Ang pinaka-kahanga-hangang bagay tungkol sa linyang ito ay nasa italics! Hindi ko alam kung anong mga konklusyon ang nakuha mo mula sa lahat ng ito, ngunit nakikita ko ang mga sumusunod - dahil ang protocol na ito ay hindi maaaring tawaging "simple" sa anumang paraan (at tila kahit na ang w3 ay sumasang-ayon dito), pagkatapos ay mula sa bersyon 1.2 ay tumigil ito sa pag-decrypted kahit papaano. ! At nakilala ito bilang SOAP, SOAP lang, period.

Well, okay, please excuse me, medyo na-sidetrack ako. Tulad ng isinulat ko kanina, ang XML ay ginagamit bilang transportasyon, at ang mga packet na naglalakbay sa pagitan ng kliyente at ng server ay tinatawag na SOAP na mga sobre. Kung isasaalang-alang mo ang pangkalahatang istraktura ng sobre, ito ay tila pamilyar sa iyo, dahil... kahawig ng istraktura ng isang HTML page. Mayroon itong pangunahing seksyon - I-envelop, na kinabibilangan ng mga seksyon Header At Katawan, o Kasalanan. SA Katawan ang data ay ipinapadala at ito ay isang ipinag-uutos na seksyon ng sobre, habang Header ay opsyonal. SA Header awtorisasyon o anumang iba pang data na hindi direktang nauugnay sa input data ng mga pamamaraan ng serbisyo sa web ay maaaring maipadala. Tungkol sa Kasalanan walang espesyal na sasabihin, maliban na ito ay dumating sa kliyente mula sa server kung sakaling magkaroon ng anumang mga error.

Dito nagtatapos ang aking kwento ng pagsusuri tungkol sa SOAP protocol (titingnan natin ang mga sobre mismo at ang kanilang istraktura nang mas detalyado kapag ang aming kliyente at server ay natutunan sa wakas na patakbuhin ang mga ito sa isa't isa) at magsisimula ang isang bago - tungkol sa kasamang SOAP na tinatawag na WSDL(Wika sa Paglalarawan ng Mga Serbisyo sa Web). Oo, oo, ito ang mismong bagay na nakakatakot sa karamihan sa atin mula sa pagsubok na ipatupad ang ating API sa protocol na ito. Bilang resulta, karaniwan naming muling inaayos ang aming gulong gamit ang JSON bilang transportasyon. Kaya ano ang WSDL? Ang WSDL ay isang wika para sa paglalarawan ng mga serbisyo sa web at pag-access sa mga ito, batay sa wikang XML (c) Wikipedia. Kung hindi nilinaw sa iyo ng kahulugang ito ang buong sagradong kahulugan ng teknolohiyang ito, susubukan kong ilarawan ito sa sarili kong mga salita!

Ang WSDL ay idinisenyo upang payagan ang aming mga kliyente na makipag-usap nang normal sa server. Upang gawin ito, inilalarawan ng file na may extension na "*.wsdl" ang sumusunod na impormasyon:

  • Anong mga namespace ang ginamit?
  • Anong mga schema ng data ang ginamit?
  • Anong mga uri ng mga mensahe ang inaasahan ng serbisyo sa web mula sa mga kliyente?
  • Aling data ang nabibilang sa aling mga pamamaraan ng serbisyo sa web,
  • Anong mga pamamaraan ang nilalaman ng serbisyo sa web?
  • Paano dapat tawagan ng kliyente ang mga pamamaraan ng serbisyo sa web,
  • Saang address dapat ipadala ang mga tawag ng customer?
Tulad ng nakikita mo, ang file na ito ay ang buong serbisyo sa web. Sa pamamagitan ng pagtukoy sa address ng WSDL file sa kliyente, malalaman namin ang lahat tungkol sa anumang serbisyo sa web! Bilang resulta, hindi namin kailangang malaman ang tungkol sa kung saan mismo matatagpuan ang web service. Ang kailangan mo lang malaman ay ang lokasyon ng WSDL file nito! Malalaman natin sa lalong madaling panahon na ang SOAP ay hindi nakakatakot gaya ng sinasabi ng mga kasabihang Ruso.

3 Panimula sa XML-Schema

Ngayon ay marami na tayong alam tungkol sa kung ano ang SOAP, kung ano ang nasa loob nito, at may pangkalahatang-ideya ng stack ng teknolohiya na nakapalibot dito. Dahil, una sa lahat, ang SOAP ay isang paraan ng pakikipag-ugnayan sa pagitan ng isang kliyente at isang server, at ang XML markup language ay ginagamit bilang isang transportasyon para dito, sa seksyong ito ay mauunawaan natin nang kaunti kung paano nangyayari ang awtomatikong pagpapatunay ng data gamit ang mga XML schemas.

Ang pangunahing gawain ng diagram ay ilarawan ang istruktura ng data na aming ipoproseso. Ang lahat ng data sa XML schemas ay nahahati sa simple lang(scalar) at kumplikado(mga istruktura) mga uri. Ang mga simpleng uri ay kinabibilangan ng mga sumusunod na uri:

  • linya,
  • numero,
  • halaga ng boolean,
  • petsa.
Isang bagay na napakasimple na walang mga extension sa loob. Ang kanilang antipode ay kumplikadong kumplikadong mga uri. Ang pinakasimpleng halimbawa ng isang kumplikadong uri na pumapasok sa isip ng lahat ay mga bagay. Halimbawa, isang libro. Ang aklat ay binubuo ng mga katangian: may-akda, Pangalan, presyo, Numero ng ISBN atbp. At ang mga katangiang ito, sa turn, ay maaaring alinman sa mga simpleng uri o kumplikado. At ang gawain ng XML schema ay ilarawan ito.

Iminumungkahi kong huwag lumayo at magsulat ng XML schema para sa aming SMS message! Nasa ibaba ang xml na paglalarawan ng mensaheng SMS:

71239876543 Mensahe ng pagsubok 2013-07-20T12:00:00 12
Ang aming kumplikadong diagram ng uri ay magiging ganito:


Ang entry na ito ay nagbabasa ng mga sumusunod: Mayroon kaming isang variable " mensahe"type" Mensahe"at mayroong isang kumplikadong uri na tinatawag na " Mensahe", na binubuo ng sunud-sunod na hanay ng mga elemento " telepono"type string, « text"type string, « petsa"type dateTime, « uri"type decimal. Ang mga uri na ito ay simple at natukoy na sa paglalarawan ng schema. Binabati kita! Kakasulat lang namin ng aming unang XML Schema!

Sa tingin ko ang kahulugan ng mga elemento " elemento"At" complexType"Lahat ay naging mas malinaw sa iyo, kaya't hindi na kami magtutuon pa sa mga ito at dumiretso tayo sa elemento ng kompositor" pagkakasunod-sunod" Kapag ginamit namin ang elemento ng kompositor " pagkakasunod-sunod“Ipinapaalam namin sa iyo na ang mga elementong kasama dito ay dapat palaging matatagpuan sa sequence na tinukoy sa diagram, at lahat ng mga ito ay sapilitan. Ngunit huwag mawalan ng pag-asa! May dalawa pang elemento ng kompositor sa XML schemas: " pagpili"At" lahat" kompositor" pagpili" nag-aanunsyo na dapat mayroong isa sa mga elementong nakalista dito, at ang kompositor " lahat» – anumang kumbinasyon ng mga nakalistang elemento.

Tulad ng naaalala mo, sa unang seksyon ng paksa ay napagkasunduan namin na mula sa isa hanggang sa infinity na mga mensaheng SMS ay maaaring ipadala sa isang pakete. Samakatuwid, iminumungkahi kong maunawaan kung paano ipinahayag ang naturang data sa XML schema. Pangkalahatang istraktura Maaaring ganito ang hitsura ng package:

71239876543 Mensahe ng pagsubok 1 2013-07-20T12:00:00 12 71239876543 Test message N 2013-07-20T12:00:00 12
Ang diagram para sa isang kumplikadong uri ay magiging ganito:


Ang unang bloke ay naglalaman ng pamilyar na deklarasyon ng kumplikadong uri " Mensahe" Kung napansin mo, pagkatapos ay sa bawat simpleng uri na kasama sa " Mensahe", naidagdag ang mga bagong katangian sa paglilinaw " minNangyayari"At" maxOccurs" Tulad ng maaari mong hulaan mula sa pangalan, ang una ( minNangyayari) ay nagpapahiwatig na ang pagkakasunud-sunod na ito ay dapat maglaman ng hindi bababa sa isang elemento ng uri " telepono», « text», « petsa"At" uri", habang ang susunod ( maxOccurs) na attribute ay nagpapahayag sa amin na mayroong hindi hihigit sa isang ganoong elemento sa aming sequence. Bilang resulta, kapag isinulat namin ang aming mga schema para sa anumang data, binibigyan kami pinakamalawak na pagpipilian sa pamamagitan ng pag-set up sa kanila!

Ang pangalawang bloke ng diagram ay nagpapahayag ng elementong " Listahan ng mensahe"type" MessageList" Malinaw na" MessageList" ay isang kumplikadong uri na naglalaman ng hindi bababa sa isang elemento " mensahe", ngunit ang maximum na bilang ng mga naturang elemento ay hindi limitado!

4 Isulat ang iyong WSDL

Naaalala mo ba na ang WSDL ay ang aming serbisyo sa web? sana maalala mo! Habang isinusulat namin ito, tatakbo dito ang aming maliit na serbisyo sa web. Samakatuwid, iminumungkahi ko na huwag magulo.

Sa pangkalahatan, para gumana nang tama ang lahat para sa amin, kailangan naming maglipat ng WSDL file na may tamang uri ng MIME sa kliyente. Upang gawin ito, kailangan mong i-configure ang iyong web server nang naaayon, ibig sabihin, itakda ang uri ng MIME para sa mga file na may extension na “*.wsdl” sa sumusunod na linya:

Application/wsdl+xml
Ngunit sa pagsasanay, karaniwan kong ipinadala ang header ng HTTP sa pamamagitan ng PHP " text/xml»:

Header("Content-Type: text/xml; charset=utf-8");
at lahat ay nagtrabaho nang mahusay!

Gusto kong balaan ka kaagad na ang aming simpleng serbisyo sa web ay magkakaroon ng medyo kahanga-hangang paglalarawan, kaya huwag maalarma, dahil... Karamihan sa teksto ay obligadong tubig at, kapag naisulat ito nang isang beses, maaari mo itong patuloy na kopyahin mula sa isang serbisyo sa web patungo sa isa pa!

Dahil ang WSDL ay XML, kailangan mong isulat ang tungkol dito nang direkta sa pinakaunang linya. Ang root element ng file ay dapat palaging may pangalang " mga kahulugan»:


Karaniwan, ang WSDL ay binubuo ng 4-5 pangunahing mga bloke. Ang pinakaunang block ay ang kahulugan ng isang web service o, sa madaling salita, ang entry point.


Sinasabi dito na mayroon kaming isang serbisyo na tinatawag na - " SmsService" Sa prinsipyo, ang lahat ng mga pangalan sa WSDL file ay maaaring baguhin mo sa anumang gusto mo, dahil wala silang papel na ginagampanan.

Pagkatapos nito, inanunsyo namin na sa aming serbisyo sa web " SmsService" may entry point ("port") na tinatawag na " SmsServicePort" Ito ay sa entry point na ang lahat ng mga kahilingan mula sa mga kliyente sa server ay ipapadala. At ipahiwatig sa elementong " address» link sa handler file na tatanggap ng mga kahilingan.

Kapag natukoy na namin ang serbisyo sa web at tinukoy ang entry point para dito, kailangan naming itali ang mga sinusuportahang pamamaraan dito:


Upang gawin ito, inililista nito kung aling mga operasyon at sa anong anyo ang mga ito ay tatawagin. Yung. para sa port" SmsServicePort"Ang isang pagbubuklod ay tinukoy sa ilalim ng pangalan" SmsServiceBinding", na may uri ng tawag " rpc"at ang HTTP ay ginagamit bilang transmission protocol. Kaya, ipinahiwatig namin dito na gagawa kami ng RPC na tawag sa HTTP. Pagkatapos nito inilalarawan namin kung aling mga pamamaraan ( operasyon) ay suportado sa serbisyo sa web. Susuportahan lang namin ang isang pamamaraan - " magpadala ngSms" Sa pamamagitan ng pamamaraang ito ang aming mga magagandang mensahe ay ipapadala sa server! Matapos ideklara ang pamamaraan, kinakailangang ipahiwatig kung anong anyo ang ipapadala ang data. Sa kasong ito, ipinapahiwatig na ang mga karaniwang SOAP na sobre ang gagamitin.

Pagkatapos nito, kailangan nating itali ang pamamaraan sa mga mensahe:


Upang gawin ito, tinukoy namin na ang aming pagbubuklod ay uri " SmsServicePortType"at sa elemento" uri ng port"na may pangalan ng parehong uri, ipinapahiwatig namin ang pagbubuklod ng mga pamamaraan sa mga mensahe. At sa gayon, ang papasok na mensahe (mula sa kliyente hanggang sa server) ay tatawaging " sendSmsRequest", at papalabas (mula sa server hanggang sa kliyente) " sendSmsResponse" Tulad ng lahat ng mga pangalan sa WSDL, ang mga pangalan ng mga papasok at papalabas na mensahe ay arbitrary.

Ngayon kailangan nating ilarawan ang mga mensahe mismo, i.e. papasok at papalabas:


Upang gawin ito, idinagdag namin ang mga elemento " mensahe"may mga pangalan" sendSmsRequest"At" sendSmsResponse" ayon sa pagkakabanggit. Sa mga ito ipinapahiwatig namin na ang input ay dapat na isang sobre na ang istraktura ay tumutugma sa uri ng data " Kahilingan" Pagkatapos nito ay ibinalik ang isang sobre mula sa server na naglalaman ng uri ng data - " Tugon».

Ngayon kailangan nating gumawa ng kaunti - magdagdag ng paglalarawan ng mga ganitong uri sa aming WSDL file! At paano sa palagay mo inilalarawan ng WSDL ang papasok at papalabas na data? Sa tingin ko matagal mo nang naiintindihan ang lahat at sinabi mo sa iyong sarili na gamit ang XML schemas! At ikaw ay magiging ganap na tama!


Maaari mo kaming batiin! Ang aming unang WSDL ay naisulat na! At tayo ay isang hakbang na mas malapit sa pagkamit ng ating layunin.
Susunod, titingnan natin kung ano ang ibinibigay sa atin ng PHP para sa pagbuo ng sarili nating mga ipinamamahaging aplikasyon.

5 Ang aming unang SOAP server

Kanina ko isinulat na para gumawa ng SOAP server sa PHP ay gagamitin natin ang built-in na SoapServer class. Para sa lahat karagdagang mga aksyon nangyari sa parehong paraan tulad ng sa akin, kakailanganin mong i-tweak ang iyong PHP nang kaunti. Upang maging mas tumpak, kailangan mong tiyakin na mayroon kang naka-install na extension na "php-soap". Pinakamainam na basahin kung paano i-install ito sa iyong web server sa opisyal na website ng PHP (tingnan ang listahan ng mga sanggunian).

Matapos ma-install at ma-configure ang lahat, kakailanganin naming lumikha ng isang file sa root folder ng iyong hosting " smsservice.php» na may sumusunod na nilalaman:

setClass("SoapSmsGateWay"); //Simulan ang server $server->handle();
Umaasa ako na hindi na kailangang ipaliwanag kung ano ang nasa itaas ng linya gamit ang function na "ini_set". kasi doon ay tinutukoy kung aling mga HTTP header ang aming ipapadala mula sa server patungo sa kliyente at ang kapaligiran ay na-configure. Sa linya na may "ini_set" hindi namin pinapagana ang pag-cache ng WSDL file upang ang aming mga pagbabago dito ay agad na magkabisa sa kliyente.

Andito na tayo sa server! Tulad ng nakikita mo, ang buong server ng SOAP ay tumatagal lamang ng tatlong linya! Sa unang linya, gumawa kami ng bagong instance ng SoapServer object at ipinapasa ang address ng aming paglalarawan ng WSDL ng web service sa constructor nito. Ngayon alam namin na ito ay matatagpuan sa ugat ng pagho-host sa isang file na may sariling paliwanag na pangalan " smsservice.wsdl.php" Sa pangalawang linya, sasabihin namin sa SOAP server kung aling klase ang kailangang hilahin upang maproseso ang sobre na natanggap mula sa kliyente at ibalik ang sobre na may tugon. Tulad ng maaaring nahulaan mo, sa klase na ito ang aming tanging paraan ay ilalarawan magpadala ngSms. Sa ikatlong linya sinisimulan namin ang server! Iyon lang, handa na ang aming server! Kung saan binabati ko tayong lahat!

Ngayon kailangan nating lumikha ng WSDL file. Upang gawin ito, maaari mong kopyahin lamang ang mga nilalaman nito mula sa nakaraang seksyon, o kumuha ng kalayaan at "i-template" ito nang kaunti:

"; ?> /" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/" xmlns:http="http:// schemas.xmlsoap.org/wsdl/http/" name="SmsWsdl" xmlns="http://schemas.xmlsoap.org/wsdl/"> /"> /smsservice.php" />
Sa yugtong ito, dapat tayong ganap na masiyahan sa nagresultang server, dahil Maaari naming i-log ang mga sobre na darating dito at pagkatapos ay mahinahong pag-aralan ang mga papasok na data. Upang makatanggap kami ng anumang bagay sa server, kailangan namin ng isang kliyente. Kaya hayaan na natin ito!

6 na kliyente ng SOAP sa daan

Una sa lahat, kailangan nating lumikha ng isang file kung saan isusulat natin ang kliyente. Gaya ng dati, gagawin namin ito sa ugat ng host at tatawagin itong " kliyente.php", at sa loob ay isusulat namin ang sumusunod:

messageList = bagong MessageList(); $req->messageList->message = bagong Mensahe(); $req->messageList->message->phone = "79871234567"; $req->messageList->message->text = "Test message 1"; $req->messageList->message->date = "2013-07-21T15:00:00.26"; $req->messageList->message->type = 15; $client = bagong SoapClient("http://($_SERVER["HTTP_HOST"])/smsservice.wsdl.php", array("soap_version" => SOAP_1_2)); var_dump($client->sendSms($req));
Ilarawan natin ang ating mga bagay. Noong isinulat namin ang WSDL, inilarawan nito ang tatlong entity para sa envelope na papasok sa server: Kahilingan, MessageList At Mensahe. Alinsunod na mga klase Kahilingan, MessageList At Mensahe ay mga reflection ng mga entity na ito sa aming PHP script.

Kapag natukoy na natin ang mga bagay, kailangan nating lumikha ng isang bagay ( $req), na ipapadala namin sa server. Pagkatapos nito ay dumating ang dalawang pinakamahal na linya para sa atin! Ang aming kliyente ng SOAP! Maniwala ka man o hindi, sapat na ito para sa aming server upang magsimulang makatanggap ng mga mensahe mula sa kliyente, gayundin para sa aming server na matagumpay na matanggap at maproseso ang mga ito! Sa una sa mga ito, lumikha kami ng isang halimbawa ng klase ng SoapClient at ipinapasa ang address ng lokasyon ng WSDL file sa constructor nito, at sa mga parameter ay tahasan naming ipinapahiwatig na gagana kami gamit ang SOAP protocol na bersyon 1.2. Sa susunod na linya tinatawag namin ang pamamaraan magpadala ngSms bagay $kliyente at agad na ipakita ang resulta sa browser.
Patakbuhin natin ito at tingnan kung ano ang nakuha natin sa wakas!

Ang sumusunod na bagay ay ibinalik sa akin mula sa server:

Object(stdClass) pampublikong "status" => boolean true
At ito ay mahusay, dahil... Ngayon alam namin na sigurado na ang aming server ay gumagana at hindi lamang gumagana, ngunit maaari ring ibalik ang ilang mga halaga sa kliyente!

Ngayon tingnan natin ang log na maingat nating itinatago sa gilid ng server! Sa unang bahagi nito nakikita natin ang raw data na dumating sa server:

79871234567 Mensahe ng pagsubok 1 2013-07-21T15:00:00.26 15
Ito ang sobre. Ngayon alam mo na kung ano ang hitsura nito! Ngunit malamang na hindi tayo magiging interesado na tingnan ito sa lahat ng oras, kaya't i-deserialize natin ang object mula sa log file at tingnan kung maayos ang lahat:

Object(stdClass) pampublikong "messageList" => object(stdClass) pampublikong "message" => object(stdClass) pampublikong "telepono" => string "79871234567" (length=11) pampublikong "text" => string "Test message 1 " (length=37) public "date" => string "2013-07-21T15:00:00.26" (length=22) public "type" => string "15" (length=2)
Tulad ng nakikita mo, ang bagay ay na-deserialize nang tama, kung saan nais kong batiin tayong lahat! May mas kawili-wiling naghihintay sa atin sa susunod! Ibig sabihin, ipapadala namin ang kliyente sa server hindi lamang isang mensahe ng SMS, ngunit isang buong pack (upang maging mas tumpak, tatlo)!

7 Pagpapadala ng mga kumplikadong bagay

Pag-isipan natin kung paano natin mailipat ang isang buong bungkos ng mga mensahe sa server sa isang packet? Marahil ang pinaka sa simpleng paraan magkakaroon ng array organization sa loob ng messageList element! Gawin natin ito:

// lumikha ng isang bagay na ipapadala sa server $req = new Request(); $req->messageList = bagong MessageList(); $msg1 = bagong Mensahe(); $msg1->telepono = "79871234567"; $msg1->text = "Subok na mensahe 1"; $msg1->date = "2013-07-21T15:00:00.26"; $msg1->uri = 15; $msg2 = bagong Mensahe(); $msg2->telepono = "79871234567"; $msg2->text = "Subok na mensahe 2"; $msg2->date = "2014-08-22T16:01:10"; $msg2->uri = 16; $msg3 = bagong Mensahe(); $msg3->telepono = "79871234567"; $msg3->text = "Subok na mensahe 3"; $msg3->date = "2014-08-22T16:01:10"; $msg3->uri = 17; $req->messageList->message = $msg1; $req->messageList->message = $msg2; $req->messageList->message = $msg3;
Ang aming mga log ay nagpapahiwatig na ang sumusunod na packet ay natanggap mula sa kliyente:

79871234567 Mensahe ng pagsubok 1 2013-07-21T15:00:00.26 15 79871234567 Mensahe ng pagsubok 2 2014-08-22T16:01:10 16 79871234567 Mensahe ng pagsubok 3 2014-08-22T16:01:10 17
Anong kalokohan, sinasabi mo? At magiging tama ka sa isang kahulugan, dahil... Sa sandaling nalaman namin na ang isang bagay ay umalis sa kliyente, dumating ito sa aming server sa ganap na parehong anyo sa anyo ng isang sobre. Totoo, ang mga mensaheng SMS ay hindi na-serialize sa XML sa paraang kailangan namin - kailangan nilang balot ng mga elemento mensahe, hindi sa Istruktura. Ngayon tingnan natin kung anong anyo ang gayong bagay na dumating sa pamamaraan magpadala ngSms:

Object(stdClass) pampublikong "messageList" => object(stdClass) pampublikong "message" => object(stdClass) pampublikong "Struct" => array (size=3) 0 => object(stdClass) pampublikong "telepono" => string "79871234567" (length=11) pampublikong "text" => string "Test message 1" (length=37) public "date" => string "2013-07-21T15:00:00.26" (length=22) public " type" => string "15" (length=2) 1 => object(stdClass) public "phone" => string "79871234567" (length=11) public "text" => string "Test message 2" (length= 37) pampublikong "petsa" => string "2014-08-22T16:01:10" (length=19) pampublikong "type" => string "16" (length=2) 2 => object(stdClass) pampublikong "telepono " => string "79871234567" (length=11) pampublikong "text" => string "Test message 3" (length=37) public "date" => string "2014-08-22T16:01:10" (length= 19) pampublikong "uri" => string "17" (haba=2)
Ano ang ibinibigay sa atin ng kaalamang ito? Tanging ang landas na aming pinili ay hindi tama at hindi kami nakatanggap ng sagot sa tanong na - "Paano namin makukuha ang tamang istraktura ng data sa server?" Ngunit iminumungkahi kong huwag mawalan ng pag-asa at subukang i-convert ang aming array sa uri bagay:

$req->messageList->message = (object)$req->messageList->message;
Sa kasong ito, makakatanggap kami ng isa pang sobre:

79871234567 Mensahe ng pagsubok 1 2013-07-21T15:00:00.26 15 79871234567 Mensahe ng pagsubok 2 2014-08-22T16:01:10 16 79871234567 Mensahe ng pagsubok 3 2014-08-22T16:01:10 17
Dumating sa pamamaraan magpadala ngSms ang bagay ay may sumusunod na istraktura:

Object(stdClass) pampublikong "messageList" => object(stdClass) pampublikong "mensahe" => object(stdClass) pampublikong "BOGUS" => array (size=3) 0 => object(stdClass) pampublikong "telepono" => string "79871234567" (length=11) pampublikong "text" => string "Test message 1" (length=37) public "date" => string "2013-07-21T15:00:00.26" (length=22) public " type" => string "15" (length=2) 1 => object(stdClass) public "phone" => string "79871234567" (length=11) public "text" => string "Test message 2" (length= 37) pampublikong "petsa" => string "2014-08-22T16:01:10" (length=19) pampublikong "type" => string "16" (length=2) 2 => object(stdClass) pampublikong "telepono " => string "79871234567" (length=11) pampublikong "text" => string "Test message 3" (length=37) public "date" => string "2014-08-22T16:01:10" (length= 19) pampublikong "uri" => string "17" (haba=2)
Para sa akin, "ang kabuuan ay hindi nagbabago mula sa pagbabago ng mga lugar ng mga termino" (c). Ano BOGUS, Ano Istruktura– hindi pa namin nakakamit ang aming layunin! At para makamit ito, kailangan nating tiyakin na sa halip na ang mga hindi maintindihang pangalang ito ay ipapakita ang ating katutubong pangalan. mensahe. Ngunit hindi pa alam ng may-akda kung paano ito makakamit. Samakatuwid, ang tanging magagawa natin ay alisin ang sobrang lalagyan. Sa madaling salita, sisiguraduhin natin ngayon na sa halip na mensahe naging BOGUS! Upang gawin ito, baguhin ang bagay tulad ng sumusunod:

// lumikha ng isang bagay na ipapadala sa server $req = new Request(); $msg1 = bagong Mensahe(); $msg1->telepono = "79871234567"; $msg1->text = "Subok na mensahe 1"; $msg1->date = "2013-07-21T15:00:00.26"; $msg1->uri = 15; $msg2 = bagong Mensahe(); $msg2->telepono = "79871234567"; $msg2->text = "Subok na mensahe 2"; $msg2->date = "2014-08-22T16:01:10"; $msg2->uri = 16; $msg3 = bagong Mensahe(); $msg3->telepono = "79871234567"; $msg3->text = "Subok na mensahe 3"; $msg3->date = "2014-08-22T16:01:10"; $msg3->uri = 17; $req->messageList = $msg1; $req->messageList = $msg2; $req->messageList = $msg3; $req->messageList = (object)$req->messageList;
Paano kung papalarin tayo at lumabas sa diagram ang tamang pangalan? Para magawa ito, tingnan natin ang dumating na sobre:

79871234567 Mensahe ng pagsubok 1 2013-07-21T15:00:00.26 15 79871234567 Mensahe ng pagsubok 2 2014-08-22T16:01:10 16 79871234567 Mensahe ng pagsubok 3 2014-08-22T16:01:10 17
Oo, walang himala ang nangyari! BOGUS- hindi tayo mananalo! Dumating sa magpadala ngSms ang bagay sa kasong ito ay magiging ganito:

Object(stdClass) pampublikong "messageList" => object(stdClass) pampublikong "BOGUS" => array (laki=3) 0 => object(stdClass) pampublikong "telepono" => string "79871234567" (haba=11) pampublikong " text" => string "Test message 1" (length=37) public "date" => string "2013-07-21T15:00:00.26" (length=22) public "type" => string "15" (haba =2) 1 => object(stdClass) public "phone" => string "79871234567" (length=11) public "text" => string "Test message 2" (length=37) public "date" => string " 2014-08-22T16:01:10" (length=19) pampublikong "type" => string "16" (length=2) 2 => object(stdClass) pampublikong "telepono" => string "79871234567" (length= 11) pampublikong "text" => string "Test message 3" (length=37) public "date" => string "2014-08-22T16:01:10" (length=19) public "type" => string " 17" (haba=2)
Tulad ng sinasabi nila - "Halos"! Sa talang ito (medyo malungkot), ipinapanukala kong dahan-dahang ibalot ang mga bagay-bagay at gumawa ng ilang konklusyon para sa ating sarili.

8 Konklusyon

Sa wakas nakarating din kami dito! Alamin natin kung ano ang maaari mong gawin ngayon:
  • maaari mong isulat ang WSDL file na kinakailangan para sa iyong serbisyo sa web;
  • madali mong maisulat ang iyong sariling kliyente na maaaring makipag-usap sa server sa pamamagitan ng SOAP;
  • maaari kang sumulat ng iyong sariling server na nakikipag-ugnayan sa labas ng mundo sa pamamagitan ng SOAP;
  • maaari kang magpadala ng mga array ng parehong uri ng mga bagay sa server mula sa iyong kliyente (na may ilang mga paghihigpit).
Nakagawa din kami ng ilang mga natuklasan sa aming maliit na pananaliksik:
  • ang katutubong klase ng SoapClient ay hindi wastong nagse-serialize ng mga istruktura ng data ng parehong uri sa XML;
  • kapag nagse-serialize ng array sa XML lumilikha ito ng karagdagang elemento na tinatawag Istruktura;
  • kapag nagse-serialize ng isang bagay sa XML lumilikha ito ng karagdagang elemento na tinatawag BOGUS;
  • BOGUS mas mababa ang kasamaan kaysa Istruktura dahil sa ang katunayan na ang sobre ay mas compact (mga karagdagang namespace ay hindi idinagdag sa XML header ng sobre);
  • Sa kasamaang palad, ang klase ng SoapServer ay hindi awtomatikong nagpapatunay sa data ng sobre gamit ang aming XML schema (marahil ang ibang mga server ay hindi rin ito ginagawa).

Wika ng Paglalarawan ng Serbisyo sa Web (WSDL)

Sa huling ilang halimbawa, maaaring nakakita ka ng ilang snippet ng WSDL code. Alalahanin na ang WSDL ay isang XML grammar, nilayon upang ilarawan ang mga posibilidad ng pakikipag-ugnayan ng mga panlabas na kliyente sa mga pamamaraan sa Web na magagamit sa pamamagitan ng sa address na ito URL sa loob ng bawat suportadong protocol ng komunikasyon. Sa maraming paraan, ang isang WSDL na dokumento ay maaaring isipin bilang isang "kontrata" sa pagitan ng Web service client at ng Web service mismo. Ito ay isa pang metalanguage. Sa partikular, ang WSDL ay ginagamit upang ilarawan ang mga sumusunod na katangian ng anumang magagamit na paraan sa Web:

Pangalan ng XML Web method;

Numero, uri at pagkakasunud-sunod ng mga parameter (kung mayroon);

Uri ng pagbabalik (kung ibinigay);

HTTP GET, HTTP POST at mga kundisyon ng tawag sa SOAP.

Sa karamihan ng mga kaso, ang mga dokumento ng WSDL ay awtomatikong nabuo ng kaukulang Web server. Tandaan na kapag idinagdag mo ang ?wsdl suffix sa isang URL na tumuturo sa isang *.asmx file, ang Web server ay bumubuo ng isang WSDL na dokumento para sa tinukoy na XML Web service.

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

Ngunit kung ang IIS ay awtomatikong bumubuo ng WSDL na dokumento para sa isang naibigay na XML Web service, bakit kailangan mo ng malalim na pag-unawa sa syntax ng nabuong data ng WSDL? Karaniwang nakadepende ang sagot sa kung paano gagamitin ang iyong serbisyo mga panlabas na aplikasyon. Para sa mga serbisyo ng XML Web na inilaan para sa "panloob" na paggamit, ang WSDL na nabuo ng Web server ay karaniwang sapat.

Samantala. Ito ay ganap na posible upang simulan ang pagbuo ng isang XML Web serbisyo sa pamamagitan ng paglikha ng isang WSDL dokumento nang manu-mano (tulad ng tinalakay sa itaas). Ang pangunahing ideya ng pagsisimula ng pag-unlad sa pamamagitan ng paglikha ng isang dokumento ng WSDL ay nauugnay sa mga isyu sa pagiging tugma. Tandaan na bago ang pagtutukoy ng WSI iba't ibang instrumento Ang mga web service build ay madalas na bumubuo ng mga hindi tugmang paglalarawan ng WSDL. Kung sisimulan mo ang pag-develop gamit ang WSDL code, maaari mong buuin ang dokumento kung kinakailangan.

Tulad ng maaari mong hulaan, ang pagsisimula ng isang XML Web service sa pamamagitan ng paglikha ng isang WSDL na dokumento ay nangangailangan ng napakahusay na kaalaman sa WSDL grammar, na hindi tinatalakay sa konteksto ng kabanatang ito. Ngunit isasaalang-alang namin pangunahing istraktura dokumento ng WSDL. Kapag naunawaan mo na ang mga pangunahing kaalaman, maaari mong pahalagahan ang pagiging kapaki-pakinabang ng wsdl.exe command line utility.

Magkomento. Ang pinakabagong impormasyon tungkol sa WSDL ay matatagpuan sa http://www.w3.org/tr/wsdl.

Pagtukoy sa isang WSDL Document

Ang aktwal na dokumento ng WSDL ay binubuksan at isinara ng root element ‹mga kahulugan›. Karaniwang tinutukoy ng opening descriptor ang iba't ibang katangian ng xmlns. Tinutukoy nila ang mga XML namespace na tumutukoy sa iba't ibang mga subelement. Sa pinakamababa, ang elementong ‹definitions› ay dapat ipahiwatig ang namespace kung saan ang mga elemento ng WSDL mismo ay tinukoy (http://schemas.xmlsoap.org/wsdl). Upang maging kapaki-pakinabang, ang pambungad na ‹definitions› descriptor ay dapat ding tukuyin ang XML namespaces na tumutukoy mga simpleng uri Data ng WSDL, mga uri ng XML Schema, mga elemento ng SOAP, at target na namespace. Halimbawa, ito ang hitsura ng seksyong ‹mga kahulugan› para sa aming serbisyo sa Web ng calculator.

‹wsdl:mga kahulugan 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:mga kahulugan›

Sa konteksto ng root element, makakahanap ka ng limang subelement. Ang pangkalahatang hitsura ng dokumento ng WSDL ay dapat na katulad nito.

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

‹wsdl:definitions…›

‹wsdl:types›

‹!-- Listahan ng mga uri na magagamit para sa serbisyong ito sa Web --›

‹wsdl:/types›

‹wsdl:mensahe›

‹!-- Format ng mensahe --›

‹wsdl:/message›

‹wsdl:portType›

‹!-- Impormasyon sa port --›

‹wsdl:/portType›

‹wsdl:binding›

‹!-- Nagbubuklod na impormasyon --›

‹wsdl:/binding›

‹wsdl:service›

‹!-– Impormasyon tungkol sa XML Web service mismo --›

‹wsdl:/service›

‹wsdl:/definitions›

Gaya ng iyong inaasahan, ang bawat isa sa mga subelement na ito ay maglalaman ng mga karagdagang elemento at katangian na higit na magpapalinaw sa paglalarawan ng mga magagamit na kakayahan. Tingnan natin ang pinakamahalagang wastong node nang paisa-isa.

Element ‹mga uri›

Titingnan muna natin ang elementong ‹types›, na naglalaman ng mga paglalarawan ng lahat ng uri ng data na inaalok ng serbisyo sa Web. Alam mo naman siguro yun XML na wika mismo ay tumutukoy sa isang bilang ng mga "base" na uri ng data, na ang lahat ay tinukoy sa loob ng XML namespace http://www.w3.org/2001/XMLSchema (na dapat tukuyin sa konteksto ng root element ‹definitions›). Kunin, halimbawa, ang Subtract() na paraan ng aming calculator Web service, na mayroong dalawa parameter ng input uri ng integer. Sa mga termino ng WSDL, ang karaniwang uri ng runtime ng wika na System.Int32 ay inilalarawan sa konteksto ng elementong ‹complexType›.

‹s:element name= "Bawasin"›

‹s:sequence›

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

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

‹/s:sequence›

‹/s:complexType›

‹/s:elemento›

Ang integer na ibinalik ng Subtract() method ay inilalarawan din sa loob ng ‹types› element.

‹s:element name=" SubtractResponse"›

‹s:complexType›

‹s:sequence›

‹s:element minOccurs=" 1 " maxOccurs=" 1 "pangalan=" SubtractResult"type=" s:int"/›

‹/s:sequence›

‹ /s:complexType›

‹/s:elemento›

Kung mayroon kang paraan sa Web na nagbabalik o tumatanggap ng mga custom na uri ng data, lilitaw din ang mga ito sa konteksto ng elementong ‹complexType›. Titingnan natin ang mga detalye kung paano gawing available ang mga custom na .NET data type gamit ang Web method sa ibang pagkakataon. Para sa kapakanan ng halimbawang ito, sabihin nating tumukoy ka ng isang paraan sa Web na nagbabalik ng istraktura na pinangalanang Point.

pampublikong struct Point (

pampublikong string pointName;

Ang paglalarawan ng WSDL para sa "komplikadong istraktura" ay magiging ganito ang hitsura.

‹s:complexType name=" Punto"›

‹s:sequence›

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

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

‹s:element minOccurs=" 0 "maxOccurs=" 1 "pangalan=" pointName"type=" s:string" /›

‹/s:sequence›

‹/s:complexType›

‹mensahe› elemento

Ang ‹mensahe› elemento ay ginagamit upang tukuyin ang format para sa pagpapalitan ng mga kahilingan at tugon para sa isang ibinigay na pamamaraan sa Web. Dahil ang isang solong serbisyo sa Web ay nagbibigay-daan sa maramihang mga mensahe na maipasa sa pagitan ng isang nagpadala at isang tatanggap, ang isang solong dokumento ng WSDL ay pinapayagan na tumukoy ng maraming mga elemento ng mensahe. Karaniwan, ginagamit ng mga kahulugang ito ang mga uri na tinukoy sa loob ng elementong ‹types›.

Anuman ang bilang ng mga elemento ng ‹mensahe› na tinukoy sa dokumento ng WSDL, kadalasang "naroroon" ang mga ito nang magkapares. Ang unang kahulugan ay kumakatawan sa input format ng isang mensahe, at ang pangalawang kahulugan ay kumakatawan sa output format ng parehong mensahe. Halimbawa, ang pamamaraan ng Subtract() ng serbisyo ng CalculatorWebService Web ay tumutukoy sa mga sumusunod na elemento ng ‹mensahe›.

‹wsdl:message name=" Ibawas angSoapIn"›

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

‹/wsdl:message›

‹wsdl: pangalan ng mensahe=" Ibawas angSoapOut"›

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

‹/wsdl:message›

Dito mo lang makikita ang SOAP na komunikasyon ng kaukulang serbisyo. Tulad ng tinalakay sa simula ng kabanatang ito, ang mga serbisyo ng XML Web ay maaaring gamitin gamit ang SOAP o ang mga pamamaraan ng HTTP GET at POST. Ngunit kung pinagana mo ang HTTP POST na komunikasyon (ipinaliwanag sa ibang pagkakataon), dapat ipakita ng nabuong WSDL ang sumusunod na ‹mensahe› data.

‹wsdl: pangalan ng mensahe=" Ibawas angHttpPostIn"›

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

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

‹wsdl:/message›

‹wsdl:message name=" Ibawas angHttpPostOut"›

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

‹wsdl:/message›

Ang mga elemento ng ‹mensahe› ay hindi masyadong kapaki-pakinabang sa kanilang sarili. Gayunpaman, ang mga kahulugan ng mensaheng ito ay isinangguni ng ibang mga bahagi ng dokumento ng WSDL.

Magkomento. Hindi lahat ng pamamaraan sa Web ay nangangailangan ng parehong kahilingan at tugon. Kung ang Web method ay "one-way", kailangan lang nito ang ‹message› element ng kahilingan. Maaari mong italaga ang isang paraan sa Web bilang one-way gamit ang katangian.

‹portType› elemento

Ang ‹portType› element ay tumutukoy sa iba't ibang koneksyon na maaaring mangyari sa pagitan ng client at ng server, at ang bawat ganoong relasyon ay kinakatawan ng isang nested ‹operation› element. Madaling hulaan na ang pinakakaraniwang mga operasyon dito ay dapat na SOAP, HTTP GET at HTTP POST. Gayunpaman, may iba pang mga operasyon. Halimbawa, ang isang one-way na operasyon ay nagbibigay-daan sa isang kliyente na magpadala ng mensahe sa isang ibinigay na Web server ngunit hindi makatanggap ng tugon (ito ay katulad ng pagtawag sa isang pamamaraan nang hindi umaasa ng isang halaga ng pagbabalik). Ang pagpapatakbo ng pagtugon sa kahilingan ay nagbibigay-daan sa server na magpadala ng kahilingan habang tumutugon ang kliyente (na maaaring ituring na extension ng pagpapatakbo ng paghiling-tugon).

Upang ilarawan ang format ng opsyonal na sub-element na ‹operasyon›, isaalang-alang ang kahulugan ng WSDL para sa Subtract() na paraan.

‹wsdl portType name= "CalculatorWebServiceSoap"›

‹wsdl:pangalan ng operasyon=" Ibawas"›

‹wsdl:input message=" tns:Bawasan angSoapIn" /›

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

‹ /wsdl:operation›

‹wsdl:/portType›

Pansinin kung paano ang ‹input› at ‹output› elemento ay tumutukoy sa katumbas na pangalan ng mensahe na tinukoy sa loob ng ‹message› na elemento. Kung ang paraan ng Subtract() ay pinagana ang HTTP POST, makikita mo ang sumusunod karagdagang elemento‹operasyon›.

‹wsdl:portType name="CalculatorWebServiceHttpPost"›

‹wsdl:input message=" s0: Ibawas angHttpPostIn" /›

‹wsdl:output message=" s0: Ibawas angHttpPostOut" /›

‹ wsdl:/operation›

‹wsdl:/portType›

Panghuli, tandaan na kung ang isang ibinigay na pamamaraan sa Web ay inilarawan gamit ang katangian ng Paglalarawan, ang elementong ‹operasyon› ay maglalaman ng isang nested na elemento ng ‹dokumentasyon›.

Ang ‹binding› element

Tinutukoy ng elementong ito ang eksaktong format ng GET, POST, at SOAP exchange. Ito ang pinaka-verbose sa lahat ng elementong nakapaloob sa loob ng konteksto ng root ‹definition› element. Halimbawa, narito ang isang kahulugan ng ‹binding› element na naglalarawan kung paano maaaring makipag-ugnayan ang isang tumatawag sa Web method na MyMethod(). gamit ang SOAP.

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

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

‹wsdl:pangalan ng operasyon=" Ibawas"›

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

‹wsdl:input›

‹soap12: gamit sa katawan=" literal" /›

‹/wsdl:input›

‹wsdl:output›

‹soap12: gamit sa katawan=" literal" /›

‹/wsdl:output›

‹/wsdl:operasyon›

‹/wsdl:binding›

‹service› elemento

Sa wakas, mayroon kaming elementong ‹service›, na tumutukoy sa mga katangian ng serbisyo sa Web mismo (halimbawa, ang URL nito). Ang pangunahing gawain ng elementong ito ay ilarawan ang hanay ng mga port na bukas ng Web server na ito. Upang makamit ito, ang elementong ‹services› ay maaaring gumamit ng anumang bilang ng mga nested na elemento ng ‹port› (hindi dapat malito sa elementong ‹portType›). Ito ang hitsura ng elementong ‹service› para sa CalculatorWebService.

‹wsdl:pangalan ng serbisyo= "CalculatorWebService"›

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

Kahanga-hangang serbisyo sa web calculator

‹/wsdl:documentation›

‹wsdl:port name= "CalculatorWebServiceSoap" nagbubuklod= "tns:CalculatorWebServiceSoap"›

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

‹/wsdl:port›

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

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

‹/wsdl:port›

‹/wsdl:service›

Kaya, tulad ng nakikita mo, ang WSDL code na awtomatikong ibinalik ng ITS server ay hindi sobrang kumplikado, ngunit dahil ang WSDL ay isang XML-based na gramatika, ang code ay medyo verbose. Gayunpaman, dapat ay mayroon ka na ngayong mas mahusay na pag-unawa sa papel ng WSDL, kaya tingnan natin nang kaunti pa ang mga protocol ng komunikasyon sa XML Web services.

Magkomento. Alalahanin na ang System.Web.Services.Description namespace ay naglalaman ng maraming uri na nagbibigay-daan sa iyong magbasa at magmanipula ng hilaw na WSDL code (tingnan ito para sa iyong sarili kung interesado ka).



MGA KAUGNAY NA ARTIKULO