Pag-aayos ng Mga Serbisyo sa Web

mga sumbrero Hulyo 23, 2013 sa 01:09 pm

Pagsusulat ng SOAP client-server application sa PHP

pagtuturo

Kamusta kayong lahat!
Ito ay nangyari na kamakailan lamang ay naging kasangkot ako sa pagbuo 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, 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);
magpadala ng mga array ng parehong uri ng data sa server ng kliyente.

Tulad ng maaari mong hulaan, ang lahat ng magic ay gagawin gamit ang PHP at ang built-in na SoapClient at SoapServer na mga klase. Bilang isang kuneho, magkakaroon kami ng serbisyo para sa pagpapadala ng mga mensahe ng sms.

1 Paglalahad ng problema

1.1 Mga Hangganan

Sa simula, iminumungkahi kong harapin ang resulta na makakamit natin sa pagtatapos ng paksa. Tulad ng inihayag sa itaas, susulat kami ng isang serbisyo para sa pagpapadala ng mga mensahe ng sms, at mas tiyak, makakatanggap kami ng mga mensahe mula sa iba't ibang mapagkukunan gamit ang SOAP protocol. Pagkatapos nito, isasaalang-alang namin sa 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?

Sige, nasa atin na ang mga limitasyon! 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, ipinapanukala kong huwag maging mas matalino sa loob ng mahabang panahon 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?
Ano ang pinakamababang halaga ng data na dapat ipadala mula sa server upang matugunan ang mga pangangailangan ng kliyente?

May nagsasabi sa akin na para dito kinakailangan na ipadala ang sumusunod:

numero ng mobile phone, at
SMS text.

Sa prinsipyo, ang dalawang katangiang ito ay sapat na upang ipadala, ngunit tila sa akin kaagad na ang isang sms na may mga pagbati sa kaarawan ay dumating 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

ang petsa na ipinadala ang mensaheng SMS.

Ang susunod na bagay na nais 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 sumasalamin tayo ng kaunti pa, nararapat na tandaan na ang kliyente ay maaaring magpadala ng isang mensahe ng SMS sa server sa isang pagkakataon, o isang tiyak na bilang ng mga ito. Sa madaling salita, sa isang packet ng data ay maaaring mayroong mula sa isa hanggang sa kawalang-hanggan ng mga mensahe.

Bilang resulta, nakuha namin na upang makapagpadala ng mensaheng SMS, kailangan namin ang sumusunod na data:

numero ng cellphone,
text ng sms,
ang oras ng pagpapadala ng SMS message sa isang subscriber,
uri ng mensahe.

Sinagot namin ang unang tanong, ngayon ay kinakailangan upang sagutin ang pangalawang tanong. At marahil ay hahayaan ko ang aking sarili na manloko ng kaunti. Samakatuwid, mula sa server magpapadala lamang kami ng boolean data, ang halaga nito ay may sumusunod na kahulugan:

TAMA - ang packet ay matagumpay na nakarating sa server, pumasa sa pagpapatunay at nakapila para sa pagpapadala sa sms provider
MALI - sa lahat ng iba pang mga kaso

Ito ay nagtatapos sa paglalarawan ng pahayag ng problema! At sa wakas, bumaba tayo sa pinakakawili-wiling bahagi - aalamin 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 gusto kong limitahan ang aking sarili sa mga link sa w3.org site na may mga kinakailangang detalye, pati na rin ang mga link sa Wikipedia. Ngunit sa pinakadulo nagpasya akong magsulat ng isang maikling sanggunian tungkol sa protocol na ito.

At sisimulan ko ang aking kuwento 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, representative 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 mga sumusunod: “Ang RPC na diskarte ay nagbibigay-daan sa iyo na gumamit ng maliit na halaga ng mga mapagkukunan ng network na may malaking bilang ng mga pamamaraan at isang kumplikadong protocol. Sa isang REST na diskarte, ang bilang ng mga pamamaraan at ang pagiging kumplikado ng protocol ay lubhang limitado, na maaaring humantong sa isang malaking bilang ng mga indibidwal na mapagkukunan. Iyon ay, kaugnay sa amin, nangangahulugan ito na sa kaso ng diskarte sa RPC, ang site ay palaging magkakaroon ng isang input (link) sa serbisyo at kung aling pamamaraan ang tatawagan upang iproseso ang papasok na data na ipinapasa namin kasama ng data, habang gamit ang REST na diskarte sa aming Ang site ay may maraming mga input (link), ang bawat isa ay tumatanggap at nagpoproseso lamang ng ilang data. Kung alam ng isang nagbabasa kung paano ipaliwanag ang pagkakaiba sa mga pamamaraang ito nang mas madali, siguraduhing magsulat sa mga komento!

Ang susunod na bagay na kailangan nating malaman tungkol sa SOAP ay ang protocol na ito ay gumagamit ng parehong XML bilang isang transportasyon, na, sa isang banda, ay napakahusay, dahil. agad na kasama sa aming arsenal ang buong kapangyarihan ng 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 sa awtomatikong pagpapatunay ng data na dumarating sa server mula sa mga kliyente.

At kaya, ngayon alam namin na ang SOAP ay ang protocol na ginagamit upang ipatupad ang remote procedure call at gumagamit ito ng XML bilang isang transportasyon! Kung babasahin mo ang artikulo sa Wikipedia, pagkatapos ay mula doon maaari mo ring malaman na maaari itong magamit sa anumang protocol ng layer ng aplikasyon, at hindi lamang ipinares sa 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 mga hula, pagkatapos ay bibigyan kita ng isang pahiwatig - SOAP!… Wala pa ring mga hula?... Talagang binasa mo ba ang artikulo sa Wikipedia?... Sa pangkalahatan, hindi na kita pahihirapan. Samakatuwid, agad akong magpapatuloy sa sagot: “SOAP (mula sa English. Simple Object Access Protocol - isang simpleng protocol pag-access sa mga bagay; hanggang sa detalye 1.2)". Ang highlight ng linyang ito ay nasa italics! Hindi ko alam kung anong mga konklusyon ang nakuha mo mula sa lahat ng ito, ngunit nakikita ko ang sumusunod - dahil ang protocol na ito ay hindi maaaring tawaging "simple" (at tila kahit na ang w3 ay sumasang-ayon dito), pagkatapos ay mula noong bersyon 1.2 ito ay tumigil na. decrypted sa lahat! At nakilala ito bilang SOAP, SOAP lang at period.

Well, okay, I beg your pardon, nadulas ng kaunti sa gilid. Tulad ng isinulat ko kanina, ang XML ay ginagamit bilang isang transportasyon, at ang mga packet na tumatakbo sa pagitan ng kliyente at ng server ay tinatawag na SOAP na mga sobre. Kung isasaalang-alang namin ang pangkalahatang istraktura ng sobre, kung gayon 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. AT Katawan ang data ay ipinapadala at ito ay isang ipinag-uutos na seksyon ng sobre, habang header ay opsyonal. AT header ang awtorisasyon ay maaaring ipadala, o anumang iba pang data na hindi direktang nauugnay sa input data ng mga pamamaraan ng serbisyo sa web. Pro 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 pangkalahatang-ideya na kuwento tungkol sa SOAP protocol (titingnan natin ang mga sobre mismo at ang kanilang istraktura nang mas detalyado kapag ang aming kliyente at server sa wakas ay natutunan kung paano patakbuhin ang mga ito sa isa't isa) at magsisimula ang isang bago - tungkol sa isang kasamang SOAP tinawag WSDL(Wika sa Paglalarawan ng Mga Serbisyo sa Web). Oo, oo, ito ang mismong bagay na nakakatakot sa karamihan sa atin mula sa mismong pagtatangka na kunin at ipatupad ang sarili nating API sa protocol na ito. Bilang resulta, karaniwan naming muling inaayos ang aming gulong gamit ang JSON bilang isang 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 XML (c) na wika ng Wikipedia. Kung mula sa kahulugan na ito ang buong sagradong kahulugan ng teknolohiyang ito ay hindi naging malinaw sa iyo, pagkatapos ay susubukan kong ilarawan ito sa aking sariling mga salita!

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

Anong mga namespace ang ginamit,
Anong mga data scheme 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,
Sa aling address dapat ipadala ang mga tawag ng kliyente.

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 anumang bagay tungkol sa kung saan mismo matatagpuan ang web service. Sapat na malaman ang lokasyon ng WSDL file nito! Sa lalong madaling panahon malalaman natin na ang SOAP ay hindi nakakatakot gaya ng ipininta (c) kasabihang Ruso.

3 Panimula sa XML Schema

Ngayon ay marami na kaming alam tungkol sa kung ano ang SOAP, kung ano ang nasa loob nito, at mayroon kaming pangkalahatang-ideya kung anong uri ng teknolohiyang stack ang pumapalibot 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 sa pamamagitan ng XML schemas.

Ang pangunahing gawain ng schema 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 uri gaya ng:

linya,
numero,
boolean,
Ang 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, pamagat, presyo, Numero ng ISBN atbp. At ang mga pag-aari na ito, sa turn, ay maaaring parehong mga simpleng uri at 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 sms message:

71239876543 Mensahe ng pagsubok 2013-07-20T12:00:00 12
Magiging ganito ang hitsura ng aming kumplikadong uri ng schema:

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

Sa tingin ko ang kahulugan ng mga elemento " elemento"at" complexType» ang lahat ay naging mas o hindi gaanong malinaw sa iyo, kaya hindi na kami magtutuon sa kanila at lumipat kaagad sa elemento ng kompositor « pagkakasunod-sunod". Kapag ginamit namin ang elemento ng compositor " pagkakasunod-sunod» ipinapaalam namin sa iyo na ang mga elementong kasama dito ay dapat palaging nasa sequence na tinukoy sa scheme, 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" ay nagpapahiwatig 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, napagkasunduan namin na ang pakete ay maaaring maipadala mula sa isa hanggang sa walang katapusan ng mga mensahe ng sms. Samakatuwid, iminumungkahi kong maunawaan kung paano ipinahayag ang naturang data sa XML schema. Maaaring ganito ang hitsura ng pangkalahatang istraktura ng pakete:

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

Ang unang bloke ay naglalaman ng pamilyar na deklarasyon ng kumplikadong uri " mensahe". Kung mapapansin mo, sa bawat simpleng uri na kasama sa " mensahe”, naidagdag ang mga bagong qualifying attribute “ minNangyayari"at" maxOccurs". Dahil hindi mahirap hulaan mula sa pangalan, ang una ( minNangyayari) ay nagpapahiwatig na ang ibinigay na pagkakasunud-sunod 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 ng pinakamalawak na pagpipilian kung paano i-configure ang mga ito!

Ang pangalawang bloke ng schema ay nagpapahayag ng elementong " Listahan ng mensahe"uri" MessageList". Malinaw na" MessageList' ay isang kumplikadong uri na may kasamang hindi bababa sa isang elemento ' mensahe”, ngunit ang maximum na bilang ng mga naturang elemento ay hindi limitado!

4 Pagsusulat ng iyong WSDL

Naaalala mo ba na ang WSDL ay ang aming serbisyo sa web? Sana maalala mo! Habang isinusulat namin ito, lulutang dito ang aming maliit na serbisyo sa web. Kaya iminumungkahi ko na huwag kang mandaya.

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 *.wsdl extension 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!

Nais kong balaan ka kaagad, ang aming simpleng serbisyo sa web ay magkakaroon ng medyo kahanga-hangang paglalarawan, kaya huwag maalarma, dahil. karamihan sa mga teksto ay ipinag-uutos na tubig at kapag naisulat ay maaari itong patuloy na makopya mula sa isang serbisyo sa web patungo sa isa pa!

Dahil ang WSDL ay XML, pagkatapos ay sa pinakaunang linya kailangan mong direktang isulat ang tungkol dito. Ang root element ng isang 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, isang 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 nais mo, dahil wala silang papel na ginagampanan.

Pagkatapos nito, ipinapahayag namin iyon sa aming serbisyo sa web " SmsService" mayroong isang 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 tinukoy namin sa elementong " address» isang link sa isang handler file na tatanggap ng mga kahilingan.

Pagkatapos naming tukuyin ang isang serbisyo sa web at tukuyin ang isang 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 tatawagin. Yung. para sa daungan SmsServicePort"isang nagbubuklod na pinangalanang" SmsServiceBinding", na may uri ng tawag " rpc” at HTTP ang ginagamit bilang transfer protocol (transportasyon). 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 ng SMS". Sa pamamagitan ng pamamaraang ito, ang aming magagandang mensahe ay ipapadala sa server! Matapos ideklara ang pamamaraan, kinakailangang ipahiwatig kung anong anyo ang ipapadala ang data. Sa kasong ito, tinukoy 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 ("nagbubuklod") ay may uri na " SmsServicePortType"at sa elemento" uri ng port» na may parehong uri ng pangalan, tukuyin 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 pangalan sa WSDL, ang mga pangalan ng mga papasok at papalabas na mensahe ay arbitrary.

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

Upang gawin ito, idagdag namin ang mga elemento " mensahe"may mga pangalan" sendSmsRequest"at" sendSmsResponse" ayon sa pagkakabanggit. Sa kanila, ipinapahiwatig namin na ang isang sobre ay dapat dumating sa input, ang istraktura na tumutugma sa uri ng data " Kahilingan". Pagkatapos nito, ang isang sobre na naglalaman ng uri ng data ay ibinalik mula sa server - " 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 palagay ko matagal mo nang naintindihan ang lahat at sinabi sa iyong sarili na sa tulong ng mga XML schema! 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, haharapin 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, isinulat ko na para gumawa ng SOAP server sa PHP, gagamitin natin ang built-in na SoapServer class. Upang maganap ang lahat ng karagdagang aksyon sa parehong paraan tulad ng sa akin, kakailanganin mong i-tweak nang kaunti ang iyong PHP. Upang maging mas tumpak, kailangan mong tiyakin na mayroon kang "php-soap" na extension na naka-install. Kung paano ilagay ito sa iyong web server ay pinakamahusay na basahin sa opisyal na website ng PHP (tingnan ang mga sanggunian).

Matapos mai-install at mai-configure ang lahat, kakailanganin naming lumikha ng file na " smsservice.php» na may sumusunod na nilalaman:

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

Andito na tayo sa server! Tulad ng nakikita mo, ang buong server ng SOAP ay tatlong linya lamang ang haba! Sa unang linya, gumawa kami ng bagong instance ng SoapServer object at ipinapasa ang address ng aming WSDL web service description sa constructor nito. Ngayon alam namin na ito ay matatagpuan sa root ng pagho-host sa isang file na may nagsasabi na pangalan " smsservice.wsdl.php". Sa pangalawang linya, sasabihin namin sa SOAP server kung aling klase ang kukunin 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 ay ilalarawan ang aming tanging paraan. Magpadala ng SMS. Sa ikatlong linya sinisimulan namin ang server! Lahat, handa na ang aming server! Kung saan binabati ko tayong lahat!

Ngayon kailangan naming lumikha ng isang 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, ang resultang server ay dapat na ganap na angkop sa amin, dahil. maaari naming i-log ang mga sobre na darating dito at pagkatapos ay mahinahon na pag-aralan ang mga papasok na data. Upang makatanggap kami ng anumang bagay sa server, kailangan namin ng isang kliyente. Kaya't magpatuloy tayo sa kanila!

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 isinusulat 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, tatlong entity ang inilarawan dito para sa envelope na pumapasok sa server: Kahilingan, MessageList at mensahe. Alinsunod dito, ang mga klase Kahilingan, MessageList at mensahe ay mga reflection ng mga entity na ito sa aming PHP script.

Matapos nating tukuyin ang mga bagay, kailangan nating lumikha ng isang bagay ( $req), na ipapadala sa server. Pagkatapos ay dumating ang dalawang pinakamahal na linya para sa atin! Ang aming kliyente ng SOAP! Maniwala ka man o hindi, ngunit ito ay sapat na para sa aming server upang simulan ang pagbuhos 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 tahasang ipinapahiwatig sa mga parameter na gagana kami gamit ang SOAP protocol na bersyon 1.2. Sa susunod na linya tinatawag namin ang pamamaraan Magpadala ng SMS bagay $kliyente at agad na ipakita ang resulta sa browser.
Patakbuhin natin ito at tingnan kung ano ang nakuha natin sa wakas!

Natanggap ko ang sumusunod na bagay mula sa server:

Object(stdClass) pampublikong "status" => boolean true
At ito ay kahanga-hanga, 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 pumasok 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 interesado sa patuloy na paghanga dito, kaya't i-deserialize natin ang bagay mula sa log file at tingnan kung maayos ang lahat sa atin:

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) pampublikong "type" => string "15" (length=2)
Tulad ng nakikita mo, ang bagay ay na-deserialize nang tama, kung saan nais kong batiin tayong lahat! Susunod, may mas kawili-wiling naghihintay sa amin! Ibig sabihin, magpapadala kami ng kliyente sa server hindi isang sms-message, ngunit isang buong pack (upang maging mas tumpak, tatlong buo)!

7 Pagpapadala ng Mga Kumplikadong Bagay

Pag-isipan natin kung paano tayo makakapagpadala ng isang buong bungkos ng mga mensahe sa server sa isang pakete? Marahil ang pinakamadaling paraan ay ang ayusin ang isang array sa loob ng elemento ng messageList! Gawin natin:

// lumikha ng isang bagay na ipapadala sa server $req = new Request(); $req->messageList = bagong MessageList(); $msg1 = bagong Mensahe(); $msg1->telepono = "79871234567"; $msg1->text = "Test message 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;
Ipinapakita ng aming mga log na ang sumusunod na packet ay nagmula 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. tulad ng nalaman namin kung aling bagay ang umalis sa kliyente, dumating ito sa aming server sa anyo ng isang sobre sa eksaktong parehong anyo. 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 ng SMS:

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-cast ang aming array sa uri isang bagay:

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

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)
Tulad ng para sa akin, pagkatapos ay "mula sa isang pagbabago sa mga lugar ng mga termino, ang kabuuan ay hindi nagbabago" (c). Ano BOGUS, Ano Istruktura Hindi pa namin naabot ang aming layunin! At para makamit ito, kailangan nating tiyakin na sa halip na ang mga hindi maintindihang pangalan na ito, ang ating katutubo mensahe. Ngunit kung paano makamit ito, hindi pa alam ng may-akda. 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 = "Test message 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 ang tamang pangalan sa scheme? Para magawa ito, tingnan natin ang dumating na sobre:

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), iminumungkahi kong tahimik na i-round off at gumawa ng ilang konklusyon para sa ating sarili.

8 Konklusyon

Sa wakas nakarating din kami dito! Magpasya tayo kung ano ang maaari mong gawin ngayon:

maaari mong isulat ang kinakailangang WSDL file para sa iyong serbisyo sa web;
maaari kang sumulat ng iyong sariling kliyente nang walang anumang mga problema na maaaring makipag-usap sa server gamit ang SOAP protocol;
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).

Gayundin, gumawa kami ng ilang mga pagtuklas para sa aming sarili sa panahon ng aming maliit na pananaliksik:

hindi alam ng katutubong klase na SoapClient kung paano i-serialize nang tama ang mga istruktura ng data ng parehong uri sa XML;
kapag nagse-serialize ng array sa XML, lumilikha ito ng karagdagang elemento na pinangalanan Istruktura;
kapag nagse-serialize ng isang bagay sa XML, lumilikha ito ng karagdagang elemento na pinangalanan BOGUS;
BOGUS mas mababang kasamaan kaysa Istruktura dahil sa ang katunayan na ang sobre ay mas compact (walang dagdag na namespaces ay idinagdag sa XML header ng sobre);
sa kasamaang-palad, ang klase ng SoapServer ay hindi awtomatikong nagpapatunay sa data ng sobre sa aming XML schema (marahil ang ibang mga server ay hindi rin).

Ano ang SOAP?

Ang SOAP ay nangangahulugang Simple Object Access Protocol (Simple Object Access Protocol). Sana matapos basahin ang artikulo ay maguguluhan ka lang: "Ano itong kakaibang pangalan?"

Ang SOAP sa kasalukuyang anyo nito ay isang paraan ng remote procedure calling (RPC) sa isang network. (Oo, ginagamit din ito upang ipasa ang mga dokumento bilang XML, ngunit laktawan natin iyon sa ngayon.)

Alamin natin ito. Isipin na mayroon kang isang serbisyo na nagbabalik ng isang stock quote para sa isang ibinigay na ticker (simbolo ng stock). Nagpapadala ito ng data sa site ng Nasdaq at bumubuo ng nais na resulta batay sa ibinalik na HTML. Dagdag pa, upang payagan ang ibang mga developer na gamitin ito sa loob ng kanilang mga application, gagawin mo ang serbisyong ito na isang bahagi na nakakahanap ng impormasyon tungkol sa mga quote sa pamamagitan ng Internet. Gumagana ito nang mahusay hanggang sa isang araw ay binago ng Nasdaq ang layout ng kanilang mga pahina. Kailangan mong suriin ang buong lohika ng bahagi at magpadala ng mga update sa lahat ng mga developer na gumagamit nito. At sila, sa turn, ay kailangang magpadala ng mga update sa lahat ng kanilang mga gumagamit. Kung ito ay nangyayari sa mas marami o hindi gaanong regular na batayan, maaari kang gumawa ng maraming mga kaaway sa iyong mga kapwa developer. At sa mga programmer, tulad ng alam mo, ang mga biro ay masama. Hindi mo nais na makakuha ng larawan ng iyong paboritong pusa mula sa shredder ng opisina bukas, hindi ba?

Anong gagawin? Tingnan natin... ang kailangan mo lang ay magbigay ng isang function na kukuha ng ticker (ng uri ng string) bilang input at magbabalik ng stock quote (ng uri ng float o double). Kaya't hindi ba mas madaling hayaan ang iyong mga developer na tawagan ang function na ito sa web? Magaling! Balita rin sa akin, mayroong COM at Corba, at Java, na ginagawa ito sa loob ng maraming taon ... kung ano ang totoo ay totoo, ngunit ang mga pamamaraang ito ay hindi walang mga bahid. Ang malayuang COM configuration ay hindi mahalaga. Bilang karagdagan, kailangan mong buksan ang napakaraming port sa firewall na hindi ka makakapag-save ng sapat na beer para sa administrator ng system. Oo, at kailangan mong kalimutan ang tungkol sa mga user ng lahat ng operating system maliban sa Windows. Ngunit pagkatapos ng lahat, ang mga gumagamit ng Linux ay minsan din interesado sa palitan.

Ang lahat ay hindi mawawala kahit na para sa mga gumagamit ng Linux kung gumagamit sila ng DCOM, higit pa dito: http://www.idevresource.com/com/library/res/articles/comonlinux.asp.

Wala akong masasabi tungkol sa Corba at Java, kaya bilang isang ehersisyo, iminumungkahi ko sa mga mambabasa na hanapin ang mga kahinaan sa mga pamamaraang ito.

Ang SOAP ay isang pamantayan na nagbibigay-daan sa iyong ilarawan ang gayong malayuang tawag at ang form kung saan ibabalik ang resulta. Kaya, kailangan mong i-host ang iyong function sa isang application na magagamit sa network at tumanggap ng mga tawag sa anyo ng mga SOAP packet. Pagkatapos nito, patunayan mo ang input, patakbuhin ang iyong function, at ibalik ang resulta sa isang bagong SOAP package. Ang buong proseso ay maaaring tumakbo sa HTTP, kaya hindi mo na kailangang magbukas ng isang grupo ng mga port sa firewall. Simple lang ba?

Tungkol saan ang artikulong ito

Ito ang una sa serye ng mga artikulo sa SOAP na isinusulat namin sa Agni Software. Sa artikulong ito, susubukan kong bigyan ka ng ideya kung ano ang SOAP at kung paano magsulat ng isang application na nakikipag-ugnayan sa isang SOAP server.

Sabon at XML

Kung mukhang simple pa rin sa iyo ang SOAP, magdagdag tayo ng XML. Ngayon, sa halip na isang pangalan ng function at mga parameter, nakakakuha kami ng medyo kumplikadong XML na sobre, na parang idinisenyo upang lituhin ka. Ngunit huwag kang matakot. Marami pang darating, at kailangan mong makita ang buong larawan para ma-appreciate ang pagiging kumplikado ng SOAP.
Kung hindi mo alam kung ano ang XML, basahin muna ang aking XML na artikulo dito: http://www.agnisoft.com/white_papers/xml_delphi.asp.

Lahat ng SOAP packet ay nasa XML na format. Ano ang ibig sabihin nito? Tingnan natin. Tingnan ang function na ito (Pascal):
function na GetStockQuote(Simbolo: string): doble; Mukhang mahusay, ngunit ang problema ay na ito ay Pascal. Ano ang gamit ng simpleng kahulugan na ito para sa isang developer ng Java? O para sa isang taong nagtatrabaho sa VB? Kailangan namin ng isang bagay na mauunawaan ng lahat, maging ang mga programmer ng VB. Kaya bigyan sila ng XML na naglalaman ng parehong impormasyon (mga parameter, stock quotes, atbp.). Gumawa ka ng SOAP package, na mahalagang tawag sa iyong function, na nakabalot sa XML upang maunawaan ito ng anumang application sa anumang platform. Ngayon tingnan natin kung ano ang hitsura ng aming SOAP call:
xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/1999/XMLSchema">

IBM

Informative, tama ba? Ang SOAP ay pinasimple sa harap ng ating mga mata. Okay, jokes aside. Ngayon ay susubukan kong ipaliwanag sa iyo kung paano maunawaan ang tawag sa SOAP na ito.

Pag-decryption ng tag

Ang unang tag na pumukaw sa iyong mata ay . Ang tag na ito ay ang panlabas na pambalot ng SOAP package, na naglalaman ng ilang deklarasyon ng namespace na hindi gaanong interesado sa amin, ngunit napakahalaga para sa anumang programming language o parser. Ang mga namespace ay tinukoy upang ang mga kasunod na prefix gaya ng "SOAP-ENV:" o "xsd:" ay tinatanggap ng parser.

Ang susunod na tag ay . (Inalis namin ang isang tag na hindi kinakatawan dito - . Wala ito sa partikular na halimbawang ito, ngunit kung gusto mong magbasa pa tungkol dito, tingnan ang detalye ng SOAP dito: http://www.w3.org/TR/SOAP/). Tag talagang naglalaman ng SOAP na tawag.

Ang susunod na tag sa listahan ay − . Ang pangalan ng tag, GetStockQuote, ay ang function na tatawagan. Ayon sa SOAP terminolohiya, ito ay tinatawag na operasyon. Kaya ang GetStockQuote ay ang operasyon na isasagawa. Ang ns1 ay ang namespace na tumuturo sa urn:xmethods-quotes sa aming kaso.

Isang side note tungkol sa mga namespace: Binibigyang-daan ka ng isang namespace na maging kwalipikado ang isang XML tag. Halimbawa, hindi ka maaaring magkaroon ng dalawang variable na may parehong pangalan sa parehong pamamaraan, ngunit kung sila ay nasa dalawang magkaibang pamamaraan, walang problema. Kaya, ang isang pamamaraan ay isang namespace, dahil ang lahat ng mga pangalan dito ay natatangi. Katulad nito, ang mga XML tag ay nasasakupan sa loob ng mga namespace, kaya kung may namespace at isang tag name, maaari itong makilala nang kakaiba. Tutukuyin namin ang isang namespace bilang isang URI upang makilala ang aming NS1 mula sa mga imitator. Sa halimbawa sa itaas, ang NS1 ay isang alias na tumuturo sa urn:xmethods-quotes.

Tandaan din ang encodingStyle attribute - ang attribute na ito ay tumutukoy kung paano ang SOAP call ay serialized.

Sa loob ng tag naglalaman ng mga parameter. Sa aming pinakasimpleng kaso, mayroon lang kaming isang parameter - ang tag . Pansinin ang linyang ito sa tabi ng tag:
xsi:type="xsd:string"
Ito ay halos kung paano tinutukoy ng XML ang mga uri. (Pansinin kung gaano ako katalinong gumamit ng salitang "humigit-kumulang" kapag nag-generalize tungkol sa teknolohiya, na maaaring magbago kapag nai-publish na ang artikulo.) Ano ang eksaktong ibig sabihin nito: ang uri na tinukoy sa xsi namespace, na napansin mo ay tinukoy sa tag – xsd: string. At ito naman, ay isang string na tinukoy sa xsd namespace, muling tinukoy nang mas maaga. (Sigurado akong matutuwa ang mga abogado sa lahat ng ito).

Sa loob ng tag Nakalista ang "IBM". Ito ang halaga ng parameter ng simbolo ng function na GetStockQuote.

Well, sa huli, tulad ng mga disenteng tao, isinara namin ang lahat ng mga tag.

Kaya nalaman namin ang SOAP package na tumutukoy sa tawag sa SOAP server. At ang SOAP server, gamit ang mga XML parsers, isang pulang button at ang MIR space station, ay nagde-decode ng tawag na ito at tinutukoy na kailangan mo ng stock quote. Hinahanap kaagad nito ang kinakailangang quote at ibinabalik ito sa iyo sa form na ito:
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>

34.5

Matapos buksan ang sobre ng SOAP, tanggalin ang mga ribbon at kaluskos ang wrapper, nalaman namin na ang presyo ng isang bahagi ng IBM ay 34.5.

Karamihan sa mga komersyal na server ay magbabalik ng higit pang impormasyon, tulad ng sa anong pera at sa anong presyo ang huling bahagi ay binili. At ang presyo ng pagbabahagi, marahil, ay magiging mas tumpak.

Sa ganitong paraan malalaman natin kung ano ang inaasahan ng SOAP server at kung ano ang ibabalik nito. Kaya PAANO mo ipapadala ang impormasyong ito? Maaaring gamitin ang anumang transportasyon. Ang pinaka-iluminado ay HTTP. Hindi ko na ilalagay ang mga detalye ng HTTP, para sa mga hindi nakakaalam, ito ang ginagamit ng iyong browser para makipag-ugnayan sa mga site na binibisita mo.

Ang nais na kahilingan sa HTTP ay magiging ganito:
POST /StockQuote HTTP/1.1
Host: www.stockquoteserver.com

Haba ng Nilalaman: nnnn
SOAPAction: "Some-URI"

Ang soap request packet dito... Ang tanging dapat tandaan ay ang SOAPAction header. Isinasaad ng header na ito ang layunin ng kahilingan at kinakailangan. Ang bawat SOAP server ay maaaring magkaroon ng walang limitasyong bilang ng mga function at maaaring gamitin ang SOAPAction header upang matukoy kung aling function ang tinatawag. Ang mga firewall at multiplexer ay maaari ding mag-filter ng nilalaman batay sa header na ito.

Ang tugon ng SOAP mula sa HTTP server ay magiging ganito:
HTTP/1.1 200 OK
Uri ng Nilalaman: text/xml; charset="utf-8"
Haba ng Nilalaman: nnnn

Soap Response packet dito... Bakit HTTP? Una, ang mga administrator ng network ay hindi kailangang magbukas ng maraming hiwalay na port para sa mga SOAP na tawag... ang web server ay maaaring pangasiwaan ang mga tawag nang mapayapa, dahil Karaniwang bukas ang Port 80 sa lahat para makatanggap ng mga papasok na kahilingan. Ang isa pang bentahe ay ang pagpapalawak ng mga web server gamit ang CGI, ISAPI at iba pang katutubong module. Ang pagpapalawak na ito ay nagbibigay-daan sa iyo na magsulat ng isang module na humahawak sa mga kahilingan sa SOAP nang hindi naaapektuhan ang iba pang nilalaman ng web.

Iyon lang

Umaasa ako na ang artikulong ito ay nakatulong sa pagbibigay liwanag sa SOAP. Kung narito ka pa rin at gustong magbasa nang higit pa tungkol sa paksang ito, bisitahin ang site ng may-akda: http://www.agnisoft.com/soap

Bahagi ng liriko.

Isipin na ikaw ay nagpatupad o nagpapatupad ng isang tiyak na sistema na dapat ay magagamit mula sa labas. Yung. mayroong isang tiyak na server kung saan kailangan mong makipag-usap. Halimbawa ng isang web server.

Ang server na ito ay maaaring magsagawa ng maraming mga aksyon, magtrabaho kasama ang database, magsagawa ng ilang mga kahilingan ng third-party sa iba pang mga server, gumawa ng ilang mga kalkulasyon, atbp. mabuhay at posibleng umunlad ayon sa kanyang kilalang senaryo (i.e., ayon sa senaryo ng mga developer). Hindi kawili-wili para sa isang tao na makipag-usap sa naturang server, dahil maaaring hindi niya / hindi nais na magbigay ng magagandang pahina na may mga larawan at iba pang nilalamang madaling gamitin. Ito ay nakasulat at gumagana upang gumana at magbigay ng data sa mga kahilingan para dito, nang walang pakialam na ang mga ito ay nababasa ng tao, ang kliyente ang haharap sa kanila mismo.

Ang ibang mga system, na nag-a-access sa server na ito, ay maaari nang itapon ang data na natanggap mula sa server na ito sa kanilang sariling paghuhusga - proseso, maipon, isyu sa kanilang mga kliyente, atbp.

Well, ang isa sa mga pagpipilian para sa pakikipag-usap sa mga naturang server ay SOAP. SOAP XML messaging protocol.

Praktikal na bahagi.

Ginagawang posible ng isang serbisyo sa web (iyan ang ibinibigay ng server at kung ano ang ginagamit ng mga kliyente) na makipag-ugnayan sa server sa mga mensaheng mahusay ang pagkakaayos. Ang katotohanan ay ang serbisyo sa web ay hindi tumatanggap ng anumang data. Ang anumang mensahe na hindi tumutugma sa mga panuntunan ay ibabalik ng serbisyo sa web nang may error. Ang error ay, sa pamamagitan ng paraan, din sa anyo ng xml na may malinaw na istraktura (na hindi masasabing totoo tungkol sa teksto ng mensahe).

WSDL (Web Services Description Language). Ang mga panuntunan kung saan binubuo ang mga mensahe para sa serbisyo sa web ay inilalarawan din gamit ang xml at mayroon ding malinaw na istraktura. Yung. kung ang isang serbisyo sa web ay nagbibigay ng kakayahang tumawag sa isang pamamaraan, dapat nitong payagan ang mga kliyente na malaman kung anong mga parameter ang ginagamit para sa pamamaraang ito. Kung inaasahan ng serbisyo sa web ang isang string para sa pamamaraang Method1 bilang isang parameter, at ang string ay dapat na pinangalanang Param1, ang mga panuntunang ito ay tutukuyin sa paglalarawan ng serbisyo sa web.

Hindi lamang mga simpleng uri, kundi pati na rin ang mga bagay, ang mga koleksyon ng mga bagay ay maaaring maipasa bilang mga parameter. Ang paglalarawan ng bagay ay nabawasan sa paglalarawan ng bawat bahagi ng bagay. Kung ang bagay ay binubuo ng ilang mga patlang, kung gayon ang bawat patlang ay inilarawan, kung anong uri nito, ang pangalan (ano ang mga posibleng halaga). Ang mga field ay maaari ding maging kumplikadong uri, at iba pa, hanggang sa ang paglalarawan ng mga uri ay magtatapos sa mga simple - string, boolean, numero, petsa... Gayunpaman, ang ilang partikular na uri ay maaaring maging simple, mahalaga na mauunawaan ng mga kliyente kung anong mga halaga ang maaaring mapaloob sa kanila.

Para sa mga kliyente, sapat na malaman ang url ng serbisyo sa web, ang wsdl ay palaging nasa malapit, kung saan makakakuha ka ng ideya tungkol sa mga pamamaraan at kanilang mga parameter na ibinibigay ng serbisyo sa web na ito.

Ano ang mga pakinabang ng lahat ng mga kampana at sipol na ito:

Sa karamihan ng mga system, awtomatikong nangyayari ang paglalarawan ng mga pamamaraan at uri. Yung. sapat na para sa isang programmer sa server na sabihin na ang pamamaraang ito ay maaaring tawagan sa pamamagitan ng isang serbisyo sa web, at ang paglalarawan ng wsdl ay awtomatikong bubuo.

Ang isang paglalarawan na may malinaw na istraktura ay nababasa ng sinumang kliyente ng sabon. Yung. anuman ang serbisyo sa web, mauunawaan ng kliyente kung anong data ang tinatanggap ng serbisyo sa web. Ayon sa paglalarawan na ito, ang kliyente ay maaaring bumuo ng kanyang sariling panloob na istraktura ng mga klase ng bagay, ang tinatawag na. binding" at. Bilang resulta, ang programmer na gumagamit ng serbisyo sa web ay kailangang magsulat ng isang bagay tulad ng (pseudocode):

NewUser:=TSoapUser.Create("Vasya","Pupkin","admin"); soap.AddUser(NewUser);

Awtomatikong pagpapatunay.
- xml pagpapatunay. Ang xml ay dapat na maayos na nabuo. invalid xml - agad na isang error sa kliyente, hayaan siyang malaman ito.
- pagpapatunay ng schema. xml ay dapat magkaroon ng isang tiyak na istraktura. Ang xml ay hindi tumutugma sa scheme - kaagad na isang error sa kliyente, hayaan siyang malaman ito.
- Ang pagpapatunay ng data ay isinasagawa ng soap server upang ang mga uri ng data at mga paghihigpit ay tumugma sa paglalarawan.
Ang pahintulot at pagpapatunay ay maaaring ipatupad sa pamamagitan ng isang hiwalay na paraan. katutubo. o gamit ang http authorization.
Ang mga serbisyo sa web ay maaaring gumana pareho sa soap protocol at sa http, iyon ay, sa pamamagitan ng mga kahilingan sa pagkuha. Iyon ay, kung ang simpleng data (nang walang istraktura) ay ginagamit bilang mga parameter, pagkatapos ay maaari mo lamang tawagan ang karaniwang get www.site.com/users.asmx/GetUser?Name=Vasia o mag-post. Gayunpaman, hindi ito palaging at saanman.
... tingnan ang wikipedia

Mayroon ding maraming cons:

Hindi makatwirang laki ng mensahe. Well, dito ang mismong kalikasan ng xml ay tulad na ang format ay kalabisan, mas maraming tag, mas walang silbi na impormasyon. Dagdag pa ng sabon ang nagdaragdag sa kalabisan nito. Para sa mga intranet system, ang isyu ng trapiko ay hindi gaanong talamak kaysa sa internet, kaya ang sabon para sa mga lokal na network ay higit na hinihiling, lalo na, ang Sharepoint ay may isang soap web service kung saan maaari kang makipag-usap nang may tagumpay (at ilang mga limitasyon).
Ang awtomatikong pagbabago ng paglalarawan ng serbisyo sa web ay maaaring masira ang lahat ng mga kliyente. Well, ito ay tulad ng para sa anumang sistema, kaya kung ang paatras na pagkakatugma sa mga lumang pamamaraan ay hindi suportado, ang lahat ay mahuhulog ...
Hindi isang minus, ngunit isang kawalan. Dapat na atomic ang lahat ng pagkilos ng method call. Halimbawa, kapag nagtatrabaho sa isang subd, maaari tayong magsimula ng isang transaksyon, magsagawa ng ilang query, pagkatapos ay mag-rollback o mag-commit. Walang transaksyon sa sabon. Isang kahilingan, isang tugon, tapos na ang usapan.
Ang pagharap sa paglalarawan ng kung ano ang nasa panig ng server (ang lahat ba ay inilarawan ko nang tama?), Ano ang nasa kliyente (ano ang isinulat sa akin dito?) Maaaring medyo mahirap. Mayroong ilang mga beses na kailangan kong harapin ang panig ng kliyente at kumbinsihin ang programmer ng server na mali niyang inilarawan ang data, ngunit hindi niya maintindihan ang anumang bagay sa mga ito, dahil ang awtomatikong henerasyon at siya, parang, ay hindi dapat, ito ay isang bagay ng software. At ang error ay natural sa code ng pamamaraan, hindi lang nakita ng programmer.
Ipinapakita ng pagsasanay na ang mga developer ng mga serbisyo sa web ay napakalayo sa mga taong gumagamit ng mga serbisyo sa web na ito. Bilang tugon sa anumang kahilingan (wasto mula sa labas), maaaring dumating ang isang hindi maintindihang error na "Error 5. Lahat ay masama." Ang lahat ay nakasalalay sa konsensya ng mga nag-develop :)
Sigurado akong wala akong naalala...

Bilang halimbawa, mayroong isang bukas na serbisyo sa web ng belavia:

http://86.57.245.235/TimeTable/Service.asmx - entry point, mayroon ding text na paglalarawan ng mga pamamaraan para sa mga third-party na developer.
http://86.57.245.235/TimeTable/Service.asmx?WSDL - wsdl paglalarawan ng mga pamamaraan at uri ng natanggap at ibinalik na data.
http://86.57.245.235/TimeTable/Service.asmx?op=GetAirportsList - paglalarawan ng isang partikular na paraan na may halimbawa ng uri ng kahilingan sa xml at tugon ng xml.

Maaari kang manu-manong gumawa at magpadala ng kahilingan tulad ng:

POST /TimeTable/Service.asmx HTTP/1.1 Host: 86.57.245.235 Content-Type: text/xml; charset=utf-8 Haba ng Nilalaman: haba ng SOAPAction: "http://webservices.belavia.by/GetAirportsList" en

ang sagot ay:

HTTP/1.1 200 OK Petsa: Lun, 30 Set 2013 00:06:44 GMT Server: Microsoft-IIS/6.0 X-Powered-By: ASP.NET X-AspNet-Version: 4.0.30319 Cache-Control: pribado, max -age=0 Content-Uri: text/xml; charset=utf-8 Haba ng Nilalaman: 2940

Ang serbisyo sa web ng Threat Aeroflot ay nabuksan nang mas maaga, ngunit pagkatapos ng 1C na magdagdag ng suporta para sa sabon sa 8ku, isang grupo ng mga 1c beta tester ang matagumpay na na-install ito. Ngayon ay may nagbago doon (hindi ko alam ang address, maaari kang maghanap kung interesado ka).
ZZY Disclaimer. Nagsalita siya sa antas ng sambahayan. Maaari kang uminom.

Sa pangkalahatan, ngayon ay may mga karaniwang XML data exchange protocol:

XML-RPC- pumasa ka ng isang packet at tukuyin kung aling paraan sa server ang gusto mong tawagan.
pahinga- mayroong ilang mga bagay sa server. Ang bawat bagay ay nailalarawan sa pamamagitan ng ilang identifier. Ang bawat elemento ay may sariling url. Sa anumang elemento, maaari mong gawin: ipasok, tanggalin, i-update, piliin. Ipapadala mo lang ang nais na kahilingan sa server (halimbawa, ipasok ang ganito at ganoong elemento). Ang palitan ng client-server ay batay sa alinman sa JSON o XML.

Ang SOAP ay batay sa RPC (service oriented architecture, isang set ng mga maluwag na pinagsamang serbisyo na nakikipag-ugnayan sa isa't isa). Ang pangunahing bentahe ng RPC ay ang maliit na halaga ng mga mapagkukunan ng network (mga entry point) at ang maraming mga pamamaraan na kasangkot. Sa kabila ng kalamangan na ito, ang RPC ay isang hindi napapanahong protocol na may ilang mga disadvantages:

Hindi mo mapapatunayan ang XML-RPC na mensahe. Ang lumang protocol ay ginawa bago ang mga schema (data validation method) ay na-standardize sa XML. Yung. ang server ay tumatanggap ng mga kahilingan, dapat nitong tiyakin na ang mga kahilingang ito ay para dito, at ang data ay hindi magkatugma. Sa XML-RPC, ang mga uri ng data ay idineklara para dito, ngunit ito ay isang pagsusuri sa uri ng data, at ang pagkakapare-pareho ng data ay hindi nasuri (na nakatanggap ka ng isang istraktura kasama ang lahat ng kinakailangang mga parameter).
Hindi ka makakagawa ng pinagsamang mga mensahe.
Hindi ka maaaring gumamit ng espasyo at oras (lumabas pagkatapos ng paglikha ng RPC).
Hindi mo maaaring palawakin ang mensahe, i.e. magdagdag ng karagdagang impormasyon.

Ang lahat ng mga pagkukulang na ito ay nalutas sa XML Schema. Ito ang pamantayan sa industriya para sa paglalarawan ng isang XML na dokumento. Yung. ito ay isang paraan ng pagmomodelo ng arbitrary na data. Ang isang XML schema ay maaaring maglarawan ng isang modelo (mga ugnayan sa pagitan ng mga elemento at mga katangian at kanilang istraktura), mga uri ng data (nagpapakita ng mga uri ng data), at bokabularyo (mga pangalan ng mga elemento at katangian).

Batay sa lahat ng mga pagkukulang ng XML-RPC, nilikha nila ang SOAP protocol.

SABON(Simle Object Access Protocol) - protocol para sa pag-access ng isang bagay (entry point). Ngayon ito ang pangunahing pamantayan sa industriya para sa pagbuo ng mga ipinamamahaging aplikasyon.

Ito ay isang extension ng XML-RPC na wika. Yung. ito ay binuo sa prinsipyo: 1 entry point at anumang mga pamamaraan. Ang protocol mismo sa mga tuntunin ng transportasyon (kung paano maglipat ng data) ay nagbibigay ng malawak na pagpipilian: SMTP, FTP, HTTP, MSMQ.

Ang SOAP ay nasa puso ng pagpapatupad ng XML Web Services (XML Web Services). Ang downside ng SOAP ay mahirap matutunan.

Ang SOAP ay batay sa pagpapalitan ng mga mensahe sa pagitan ng kliyente at ng server (kasabay at asynchronously). Ang bawat mensahe ay nagdadala ng impormasyon tungkol sa data (kung anong data ang ipinadala/natatanggap). Inilarawan nang maaga ng SOAP ang buong istraktura ng mensahe gamit ang mga XML schema: kung ano ang dapat na nasa mensahe, kung paano ito ipapadala. Ginagawa nitong posible, nang hindi nalalaman ang server, na maunawaan kung ano ang nangyayari doon, at pinapayagan ang server na suriin kung para sa kanya ang mensaheng ito.

XML Schema

Ang layunin ng isang schema ay upang ilarawan ang istraktura ng data, i.e. kung anong meron tayo. Ang lahat ng data ay nahahati sa simple at kumplikadong mga uri (scalar at istruktura). Ang isang simpleng uri (string, numero, boolean, petsa) ay hindi maglalaman ng anumang bagay sa loob. Ang isang istraktura (bagay) ay maaaring maglaman ng mga katangian.

Mga Pangunahing Operasyon ng SOAP

Hindi lamang simpleng pagpapalitan ng impormasyon ng client-server. Ngunit ang awtomatikong pagkilala ng server at ang paghahanap para sa server na ito, i.e. maaaring walang alam ang kliyente tungkol sa server. Yung. ang kliyente ay unang naghahanap ng isang server, nakahanap ng mga angkop na serbisyo, naiintindihan kung anong mga pamamaraan ang naroroon, kung ano ang nasa server, at tumawag dito.
Ini-publish ng server ang impormasyon nito (lokasyon, anong mga pamamaraan ang sinusuportahan nito) upang mahanap ng kliyente ang server na ito. Nagaganap ang publikasyon sa direktoryo ng UDDI.

Istraktura ng mga SOAP na mensahe:

SOAP Envelope (envelope) - kasama dito ang buong mensahe. Binubuo ng isang header at isang katawan.
SOAP Header (header) - karagdagang impormasyon (pahintulot, halimbawa).
SOAP Body (katawan) - ang mismong mensahe.
SOAP Fault (error) - isang paraan upang ilipat ang mga error mula sa server patungo sa kliyente.

WSDL

WSDL(Web Services Description Language) - Wika ng paglalarawan ng mga serbisyo sa web. Ginamit sa SOAP. Ito ay isang uri ng dokumento na naglalarawan sa lahat: kung anong mga namespace ang ginamit, anong mga scheme ng data ang ginamit, anong mga uri ng mga mensahe ang inaasahan ng server mula sa kliyente, anong mga sobre ang nabibilang sa kung aling paraan, anong mga pamamaraan ang karaniwang umiiral, kung saang address ipapadala, atbp. Sa totoo lang, ang WSDL ay isang serbisyo sa web. Sapat na para sa kliyente na pag-aralan ang mga nilalaman ng dokumentong ito, alam na niya ang lahat tungkol sa server.

Anumang server ay dapat mag-publish ng WSDL.

Ang WSDL ay binubuo ng mga bloke:

Ang kahulugan ng serbisyo mismo, i.e. entry point, ang port ay tinukoy.
Format ng pamamaraan. Ang entry point ay nakasalalay sa mga operasyon, i.e. anong mga pamamaraan ang sinusuportahan nito. Ipahiwatig ang uri ng tawag, ang paraan ng paghahatid. Sa loob ng bawat pamamaraan, mayroong isang paliwanag - sa anong anyo ang data ay ipinadala - sa anyo ng SOAP.
Mga paraan ng pagbubuklod sa isang mensahe.
Paglalarawan ng mga mensahe mismo.

Disclaimer:Maraming mga artikulo ang naisulat sa paksang ito at, tulad ng nahulaan mo, ito ay isa pa. Marahil ay may matututuhan kang bago mula rito, ngunit walang lihim na hindi mo magawang mag-google ang hindi inilarawan dito. Mga tala lamang mula sa personal na karanasan.

Panimula

Isasaalang-alang lamang namin ang sitwasyon kapag mayroong isang third-party na serbisyo sa web at ang gawain ay magtatag ng pagpapalitan ng data.

Ang istraktura ng serbisyo ay inilarawan sa file WSDL(eng. Wika ng Paglalarawan ng Mga Serbisyo sa Web)

Ang file ay kadalasang ina-access sa pamamagitan ng isang link kung saan matatagpuan ang entry point sa web service mismo. Sumulat ako ng "madalas" dahil may mga pagbubukod. Halimbawa, ang isang SAP-based na serbisyo sa Web ay hindi nag-publish ng isang wsdl at maaari lamang makuha mula sa mismong application.

At kaya, mayroon kaming isang paglalarawan ng serbisyo sa web, pag-login, password. Kumonekta tayo.

// Tukuyin ang mga setting ng ServiceNamespace URL = "http://Somesite.ru"; Username = "TestUser"; Password = "q1w2e3"; LocationWSDL = "https://Somesite.ru/WebService/Some?wsdl"; ServiceName = "SomeServiceName"; ConnectionPointName = "SomeService_Port"; // Lumikha ng koneksyon sa SSL = Bagong SecureConnectionOpenSSL(); WSDefinition = Bagong WSDefinition(LocationWSDL,SSL); WSProxy = Bagong WSProxy(WSDefinition, ServiceNamespace URL, ServiceName, ConnectionPointName, SSL); WSProxy.User = Username; WSProxy.Password = Password;

Magaling! Nakakonekta kami sa serbisyo sa web! Sa teorya, ito ang batayan ng anumang pagpipilian sa palitan, dahil pinapayagan ka nitong lumikha bagay na istruktura ng data batay sa wsdl, at ang pagtatrabaho sa naturang bagay ay isang kasiyahan.

Isaalang-alang ang XML na ibinibigay sa amin ng SoapUI

357 121212 M 19900111 Mercedes GLS Audi TT

Ngayon ay ilarawan natin ito sa programmatically

// Lumikha ng isang bagay at punan ito ng data OwnXDTOFactory = WSDefinition.XDTOFactory; RootType = OwnFactoryXDTO.Type(URLServiceNamespace, "SUBMISSION"); RootObject = OwnFactoryXDTO.Create(RootType); RootObject.ID = "4356"; ClientType = OwnFactoryXDTO.Type(URLServiceNamespace, "CUSTOMER"); ClientObject = OwnFactoryXDTO.Create(ClientType); ClientObject.CLIENT_ID = "121212"; ClientObject.SEX = "M"; // F - babae, M - lalaki ClientObject.CLIENT_BIRTHDAY = "19900111"; // Customer Cars AutoType = CustomFactoryXDTO.Type(URLServiceNamespace, "CARS"); AutoObject = OwnFactoryXDTO.Create(AutoType); AutoObject.CLASS = "Mercedes"; AutoObject.MODEL = "GLS"; ClientObject.CARS.Add(AutoObject); AutoObject = OwnFactoryXDTO.Create(AutoType); AutoObject.CLASS = "Audi"; AutoObject.MODEL = "TT"; ClientObject.CARS.Add(AutoObject); RootObject.CUSTOMER.Add(ClientObject);

Matagumpay na nakumpleto ang data. Ngayon kailangan nating ipadala ang mga ito.

Sa sandaling ito, maraming mga nuances ang lumitaw. Subukan nating isaalang-alang ang bawat isa.

Recipe 1. Pagpapadala ng Buong XDTO Object

Resulta = WSProxy.AddCustomers(RootObject);

Ito ay nananatili lamang upang iproseso ang resulta na ibinalik sa amin ng serbisyo at iyon na. Sumang-ayon na ito ay napaka-maginhawa!

Ngunit sa pagsasagawa, hindi ito palaging nangyayari. Halimbawa, ang 1c ay hindi sumasama sa paglalagay ng prefix ng ilang partikular na tag sa loob ng xml kapag ang namespace ng root tag ay naiiba sa pangalan ng mga child tag. Sa ganitong mga kaso, kailangan mong manu-manong mangolekta ng sabon. Kinailangan ko ring harapin ang mga serbisyo sa web na inaasahan ang purong xml bilang isang parameter. Pagkabaliw, ngunit hindi pa rin ito napakahirap gawin.

Recipe 2. Pagpapadala ng purong xml bilang parameter

XMLRecordParameters = NewXMLRecordParameters("UTF-8", "1.0", True); MyXML = Bagong XMLWriter; MyXML.SetString(XMLRecordParameters); MyXML.WriteDeclarationXML(); CustomXDTOFactory.WriteXML(MyXML, RootObject); StringXML = MyXML.Close(); Kung DeleteNamespaceDescription Pagkatapos AttemptFirstTagInString = StrGetString(XMLString,2); RootTagName = RootObject.Type().Name; XMLString = StrReplace(XMLString, FirstTagInString, "<"+ИмяКорневогоТэга+">"); Exception //ErrorDescription() EndTry; EndIf; Resulta = WSProxy.AddCustomers(XML String);

Kung hindi mo aalisin ang namespace na idinaragdag ng 1s bilang default, ito ay naging higit pa sa 5 linya ng code. Kadalasan, binabalot ko ang pagbabagong-anyo ng xml sa isang function, dahil karaniwan naming tinatawag ang higit sa isang paraan.

Recipe 3. Ipadala sa pamamagitan ng katutubong HTTP Request.

SOAP string =" | | |" +StringXML+ " | |"; // Inilalarawan ang mga header ng kahilingan sa HTTP Mga Header = Bagong Tugma; Headers.Insert("Content-Type", "text/xml;charset=UTF-8"); Headers.Insert("SOAPAction", "http:// sap .com/xi/WebService/soap1.1"); Headers.Insert("Authorization", "Basic "+GetBase64AuthorizationHeader(Username, Password)); // ATTENTION!!! // Hindi mo maaaring punan ng programmatically ang mga sumusunod na header, dahil ito ay humahantong sa isang error // Ang platform ay pupunan ang mga ito nang tama //Headers.Insert("Accept-Encoding", "gzip,deflate"); //Headers.Insert("Content-Length", Format(StringLength( SOAP String)," HG=")); // haba ng mensahe //Headers.Insert("Host", "Somesite.ru:8001"); //Headers.Insert("Connection", "Keep-Alive") ; //Mga Header. Insert("User-Agent", "Apache-HttpClient/4.1.1 (java 1.5)"); // Kumonekta sa site. Connection = New HTTPConnection("Somesite.ru/WebService/Some", Username, Password, SSL, false); // Ang address ay dapat walang https:// // Kunin ang text ng root page sa pamamagitan ng POST request. c = Bagong HTTPRequest("/GetCustomer", Mga Header); HTTPRequest.SetBodyFromString(SOAPString); Resulta = Connection.CallHTTPMethod("POST", HTTPRequest);

Sa opsyong ito, kakailanganin nating gumawa ng sabon nang manu-mano. Sa esensya, binabalot lang namin ang xml mula sa recipe 2 sa isang soap wrapper, kung saan, depende sa mga kinakailangan ng serbisyo sa web, maaari naming baguhin ang aming sabon sa nilalaman ng aming puso.

Susunod, inilalarawan namin ang mga header ayon sa dokumentasyon. Ang ilang mga serbisyo ay madaling ngumunguya sa aming kahilingan nang walang mga header, dito kailangan mong tumingin sa isang partikular na kaso. Kung hindi mo alam kung anong mga header ang irereseta, kung gayon ang pinakamadaling paraan ay tingnan ang kahilingan sa SoapUI sa pamamagitan ng paglipat sa tab na RAW.

Ang function para sa pagkuha ng Base64 string ay ganito ang hitsura (sumilip):

Function GetBase64AuthorizationHeader(Username, Password) FileEncoding = TextEncoding.UTF8; TempFile = GetTemporaryFileName(); Record = Bagong TextWrite(TemporaryFile, FileEncoding); Write.Write(Username+":"+Password); Record.Close(); BinData = Bagong BinaryData(TempFile); Resulta = Base64String(DvData); DeleteFiles(TempFile); Resulta = Avg(Resulta,5); Resulta ng Pagbabalik; EndFunctions

May mahalagang punto. Kapag nagtatrabaho sa HTTPConnection, tukuyin ang address nang hindi tinukoy ang "http://" at "https://" na mga protocol, kung hindi, nanganganib kang mag-aksaya ng oras sa paghahanap ng hindi halatang error.

Recipe 4. Pagpapadala sa pamamagitan ng WinHttpRequest

WinHttp = Bagong COMObject("WinHttp.WinHttpRequest.5.1"); WinHttp.Option(2,"UTF-8"); WinHttp.Option(4, 13056); //intSslErrorIgnoreFlag WinHttp.Option(6, true); //blnEnableRedirects WinHttp.Option(12, true); //blnEnableHttpsToHttpRedirects WinHttp.Open("POST", "https://Somesite.ru/WebService/Some/GetCustomer", 0); WinHttp.SetRequestHeader("Content-type", "text/xml"); WinHttp.SetCredentials(Username, Password, 0); WinHttp.Send(SOAP String); WinHttp.WaitForResponse(15); XMLResponse = WinHttp.ResponseText();

Dito, sa katunayan, kapareho ng sa nakaraang bersyon, ngunit nagtatrabaho kami sa isang COMObject. Tinukoy namin ang string ng koneksyon nang buo, kasama ang protocol. Ang espesyal na atensyon ay dapat bayaran lamang sa mga flag para sa hindi pagpansin sa mga error sa mga SSL certificate. Kailangan ang mga ito kung nagtatrabaho tayo sa SSL, ngunit walang partikular na sertipiko, dahil hindi posible na lumikha ng bagong secure na koneksyon sa opsyong ito (o hindi ko alam kung paano). Ang natitirang bahagi ng mekanismo ay katulad ng nauna.

Gayundin, bilang karagdagan sa "WinHttp.WinHttpRequest.5.1", maaari mong gamitin ang "Microsoft.XMLHTTP", "Msxml2.XMLHTTP", "Msxml2.XMLHTTP.3.0", "Msxml2.XMLHTTP.6.0", kung bigla itong hindi tumagal off sa WinHttp. Ang mga pamamaraan ay halos pareho, tanging ang bilang ng mga parameter ay naiiba. Pinaghihinalaan ko na ang isa sa mga opsyong ito ay naka-wire sa loob ng 1c HTTPRequest object.

Sa ngayon, ito ang lahat ng mga recipe na mayroon ako. Kung makatagpo ako ng mga bago, tiyak na pupunan ko ang artikulo.

Pagproseso ng resulta

Sa recipe 1, madalas kaming nakakakuha ng isang handa na bagay na XDTO at gumagana kasama ito bilang isang istraktura. Sa lahat ng iba pang mga kaso, maaari mong i-convert ang xml na tugon sa XDTO

Kung Result.StatusCode = 200 Pagkatapos XMLReader = Bagong XMLReader; ReadingXML.SetString(Result.GetBodyAsString()); ResponseObject = OwnFactoryXDTO.ReadXML(ReadingXML); Ulat(ObjectResponse.Body.Response.RESPONSE_ID); Ulat(ObjectResponse.Body.Response.RESPONSE_TEXT); Tapusin kung;

Simple lang ang lahat dito.

Sa halip na isang konklusyon

1. Magsimulang magtrabaho sa mga serbisyo sa web gamit ang SoapUI program. Idinisenyo ito para sa ganoong gawain at magbibigay-daan sa iyo na mabilis na maunawaan kung paano gumagana ang isang partikular na serbisyo. Mayroong isang artikulo upang matutunan

2. Kung nakikipagpalitan ka sa isang serbisyo sa pamamagitan ng isang hindi secure na channel ng http at lumitaw ang tanong kung ano ang eksaktong ipinapadala ng 1s sa iyong mga mensahe, maaari kang gumamit ng mga traffic sniffer tulad ng Wireshark, Fiddler, at iba pa. Ang problema ay nangyayari lamang kung gumagamit ka ng isang koneksyon sa ssl.

3. Kung, gayunpaman, ang serbisyo sa web ay nakikipag-ugnayan sa pamamagitan ng https, pagkatapos ay i-install namin ang Nginx server sa isang malayuang makina (anuman, pinakamahalaga, hindi sa aming sarili), na aming kokontakin, at ito naman, ay mag-iimpake ng lahat sa https at ipadala ito sa tamang lugar ( baligtarin ang proxy ) at idagdag sa karaniwang config:

Server ( makinig 0.0.0.0:8080; server_name MyServer; lokasyon ~ .* ( proxy_pass https://Somesite.ru:8001; proxy_set_header Host $host; proxy_set_header Authorization "Basic "; proxy_pass_header Authorization; ) )

5. Kung ang pagpapatotoo ay nagsasangkot ng paggamit ng Cookies, ang mga sumusunod ay natagpuan

P.S. Kung mayroon kang mga katanungan, mungkahi para sa pagpapabuti ng code, magkaroon ng iyong sariling mga recipe na naiiba sa mga inilarawan, nakakita ka ng mga error o iniisip na ang may-akda ay "mali" at siya ay "hindi kabilang sa 1s", pagkatapos ay sumulat ng mga komento at tatalakayin natin lahat.