Simple Object Access Protocol (SOAP) - obecný popis. Co je WSDL, SOAP a REST
Jak bylo uvedeno v předchozí kapitole, webové služby komunikují s klienty a mezi sebou navzájem zasíláním zpráv jazyk XML. Tagy této implementace XML, pravidla formátování pro dokument XML a pořadí, ve kterém jsou dokumenty vyměňovány, jsou definovány protokolem SOAP. protokol SOAP Vytvořeno v roce 1998 vývojovým týmem vedeným Davem Winerem ve společnosti Microsoft a Userland. Název protokolu - "Simple Object Access Protocol" - odráží jeho původní účel - přístup k metodám vzdálených objektů. Účel protokolu se změnil, nyní je to protokol pro veškerou interakci mezi webovými službami a komponentami volně propojených distribuovaných aplikací. Už to není úplně jednoduché a neříká to nic o objektech. Mnoho vývojářů navrhuje nazývat to „Service Oriented Architecture Protocol“ a ponechává předchozí zkratku. Aby se tyto pokusy zastavily, specifikace SOAP 1.2 uvádí, že slovo „SOAP“ již nebude žádným způsobem dekódováno.
Na konci roku 1999 byl vývoj protokolu převeden do konsorcia W3C (http: // www.w3.org/).
V květnu 2000 konsorcium vydalo svou verzi SOAP 1.1. Zpráva napsaná pomocí protokolu SOAP je formátována jako dokument XML, který aktivně využívá jmenné prostory. Názvy prvků XML SOAP 1.1 odkazují na jmenný prostor s identifikátorem http://schemas.xmlsoap.org/soap/envelope/.
Návrh druhé verze SOAP 1.2 byl vydán v roce 2001, jeho jmenný prostor byl v té době http://www.w3.org/2001/06/soap-envelope.
Všimněte si, že je to identifikátor jmenného prostoru, nikoli číslo 1.1 nebo 1.2, co určuje verzi SOAP. Server nebude brát v úvahu zprávu SOAP a vrátí chybovou zprávu, pokud si toho všimne
neshoda jmenného prostoru.
Zatímco píšu tyto řádky, SOAP 1.1 stále funguje. Verze 1.2 nemůže opustit přípravnou fázi, ale je již používána např. v SOAP::Lite, Apache SOAP 2.3, Apache Axis. Proto v této kapitole představím verzi 1.2, přičemž si všimneme jejích odlišností od verze 1.1.
Specifikace pracovní verze SOAP je vždy uložen na http://www.w3.org/TR/SOAP/. Dokumenty umístěné na této adrese jsou nahrazeny novými při výměně pracovní verze.
Koncept verze SOAP je neustále aktualizován a identifikátor jmenného prostoru se mění. Nejnovější verze návrhu v době psaní tohoto článku byla uložena na http://www.w3.org/TR/soapl2-partl/ a jmenný prostor, který používal, byl http://www.w3.org/2002/06/soap- obálka. Všimněte si, že specifikace SOAP 12 má dvě části: část 1 a část 2. Druhá část specifikace - aplikace - obsahuje pravidla pro zápis komplexních datových typů. Specifikace má ještě jednu část - příklady zpráv sestavených podle pravidel SOAP 1.2.
Struktura zprávy SOAP
Specifikace definuje zprávu SOAP jako XML dokument A, které neobsahuje deklaraci typu dokumentu nebo pokyny pro zpracování. Kořenový prvek tohoto dokumentu XML se nazývá
a další atributy s předponou. Kořenový prvek obsahuje jeden volitelný prvek obsahující záhlaví zprávy a jeden povinný prvek
, ve kterém je zapsán obsah zprávy. Verze 1.1 povolena po těle zapsat libovolné prvky, jejich jména musí mít předponu. Verze 1.2 zakazuje za element cokoliv psát . Stručně řečeno, obecná struktura zprávy SOAP je: xmlns:env="http://www.w3.org/2002/06/soap-envelope"> < ! - Блоки заголовка -> Živel Je to proto, že zpráva SOAP může projít více servery SOAP nebo více aplikacemi na stejném serveru. Tyto aplikace předzpracují bloky záhlaví zprávy a předávají si je navzájem. Všechny tyto servery a/nebo aplikace se nazývají uzly SOAP. Specifikace SOAP nedefinuje pravidla pro předávání zpráv řetězem serverů. K tomu se vyvíjejí další protokoly, jako je Microsoft WS-Routing. Atribut actor určuje cílový uzel SOAP – ten na konci řetězce, který zpracuje hlavičku jako celek. Význam Atribut actor označuje, že první server, který obdrží hlavičku, zpracuje hlavičku. Atribut actor se může objevit v samostatných blocích hlavičky označující uzel, který daný blok zpracovává. Po zpracování je blok ze zprávy SOAP odstraněn. Ve verzi 1.2 je atribut aktér nahrazen atributem role, protože v této verzi SOAP hraje každý uzel jednu nebo více rolí. Specifikace zatím definuje tři role uzlů SOAP. Roli http://^^.w3.org/2002/06/soap-envelope/role/ultimateReceiver hraje konečný cílový uzel, který zpracuje hlavičku. Roli http://www.w3.org/2002/06/soap-envelope/role/next hraje mezilehlý nebo cílový uzel. Takový uzel může hrát další, další role. Roli http://www.w3.org/2002/06/soap-envelope/role/none nesmí hrát žádný uzel SOAP. Distribuované aplikace mohou na základě svých potřeb k těmto rolím přidávat další role, například zavést zprostředkující server, který kontroluje digitální podpis a definovat pro něj tuto roli pomocí nějakého řetězce URI. Hodnotou atributu role může být libovolný řetězec URI označující roli uzlu, kterému je tento blok záhlaví určen. Výchozí hodnotou tohoto atributu je prázdná hodnota, tedy jen dvojice uvozovek nebo řetězec URI http://\vw\v.w3.org/2002/06/soap-envelope/rale/ultimateReceiver. Hodnota atributu role označuje, že blok by měl být zpracován uzlem, který hraje roli určenou stejným řetězcem. Další atribut prvku V SOAP 1.2 je třeba místo čísla o napsat slovo false a místo čísla 1 slovo true. V těle záhlaví Výpis 3.1. Záhlaví s jedním blokem xmlns:t="http://some.com/transaction" env:role= "http://www.w3.org/2002/06/soap-envelope/role/ultimateReceiver" env:mustUnderstand="1"> Prvky vnořené do bloků záhlaví se již nenazývají bloky. Nemohou obsahovat role, herce a atributy, kterým musíte rozumět. Živel Chybové hlášení Pokud SOAP server při zpracování jím přijaté zprávy SOAP zaznamená chybu, zastaví zpracování a odešle klientovi zprávu SOAP, do jejíhož těla zapíše jeden prvek Ve zprávě napsané v těle prvku verze SOAP 1.1 Existují čtyři části popsané následujícími vnořenými prvky. Chybový kód Popis chyby Umístění chyby Detaily chyby Například: xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> SOAP verze 1.2 změnil obsah prvku, jak je popsáno v jmenný prostor http://www.w3.org/2002/06/soap-envelope, má dva povinné prvky a tři volitelné prvky. Povinné prvky. Chybový kód Příčina chyby Volitelné prvky. ? ? ? Výpis 3.2 zobrazuje chybovou zprávu, která se vyskytla při pokusu o provedení procedury. Chyba spočívá v tom, že názvy argumentů procedur jsou ve zprávě SOAP napsány nesprávně a procedura jim nerozumí. Výpis 3.2. Chybové hlášení xmlns:env="http://www.w3.org/2002/06/soap-envelope" xmlns:rpc='http://www.w3.org/2002/06/soap-rpc'> xmlns:e="http://www.example.org/chyby"> Typy chyb Seznam chybových kódů se neustále mění a rozšiřuje. Verze 1.1 definuje čtyři typy chyb. VersionMismatch – obor názvů nebyl rozpoznán. Možná je zastaralý nebo je jeho název špatně napsaný. MustUnderstand – Blok záhlaví označený atributem mustUnderstand s hodnotou 1 neodpovídá své syntaxi definované ve schématu dokumentu. Klient - XML dokument obsahující zprávu má chybný formát az tohoto důvodu jej server nemůže zpracovat. Klient by měl změnit zprávu. Server - server nemůže z vlastních interních důvodů zpracovat správně zaznamenanou zprávu. Verze 1.2 definuje pět typů chyb. VersionMismatch – obor názvů nebyl rozpoznán. Možná je zastaralá, její název je napsán chybně nebo zpráva narazila na název prvku XML, který není v daném oboru názvů definován. Server zapíše prvek do hlavičky odpovědi MustUnderstand – Blok záhlaví označený atributem mustunderstand nastaveným na hodnotu true neodpovídá své syntaxi definované ve schématu dokumentu. Server zapisuje prvky do hlavičky odpovědi DataEncodingUnknown - ve zprávě byly nalezeny nesrozumitelné údaje, možná jsou zapsány v neznámém kódování. Odesílatel – XML dokument obsahující zprávu má chybný formát az tohoto důvodu jej server nemůže zpracovat. Klient by měl změnit zprávu. Přijímač - server nemůže z vlastních interních důvodů zpracovat správně zaznamenanou zprávu, například chybí požadovaný XML parser. Server může k těmto typům chyb přidat některé své vlastní typy chyb. Obvykle podrobně popisují standardní typy a zprávy o nich se objevují v prvcích ? Výpis 3.3. Odpověď serveru s chybovou zprávou typu VersionMismatch xmlns:env="http://www.w3.org/2002/06/soap-envelope"> xmlns:upg="http://www.w3.org/2002/06/soap-upgrade"> xmlns:nsl="http://www.w3.org/2002/06/soap-envelope"/> xmlns:ns2="http://schemas.xmlsoap.org/soap/envelope/"/> Seznam 3.4. Odpověď serveru s chybovou zprávou, jako je MustUnderstand xmlns:t='http://some.com/transaction' /> Jedno nebo více povinných záhlaví není pochopeno Literatura: Khabibullin I. Sh. Vývoj webových služeb pomocí Javy. - Petrohrad: BHV-Petersburg, 2003. - 400 s.: ill. MÝDLO je textový protokol, který používá XML k výměně strukturovaných zpráv v distribuovaném výpočetním prostředí. Zpočátku byl SOAP určen hlavně k implementaci vzdáleného volání procedur (RPC) a název byl zkratkou: Simple Object Access Protocol – jednoduchý protokol pro přístup k objektům. Nyní se protokol používá k výměně libovolných zpráv XML formát nejen pro volání procedur. Oficiální specifikace Nejnovější verze 1.2 protokolu název SOAP nijak nedešifruje. SOAP je rozšířením protokolu XML-RPC. SOAP lze použít s jakýmkoli protokolem aplikační vrstva: SMTP, FTP, HTTP atd. Jeho interakce s každým z těchto protokolů má však své vlastní charakteristiky, které je nutné definovat samostatně. Nejčastěji se SOAP používá přes HTTP. SOAP je jedním ze standardů, na kterých je založena technologie webových služeb. Komunikace mezi webovými službami a jejich klienty probíhá prostřednictvím zpráv ve formátu XML. SOAP (Simple Object Access Protocol) je protokol pro zasílání zpráv pro výběr webových služeb. Můžeme říci, že formát SOAP je ideální pro technologii RPC (Remote Procedure Call), protože zpráva SOAP obsahuje parametry zaslané klientem nebo návratovou hodnotu zaslanou službou. Výhody použití formátu SOAP: · Flexibilnější datové typy. Podpora záhlaví a rozšíření: nedostatky: · Použití protokolu SOAP k přenosu zpráv zvyšuje jejich objem a snižuje rychlost zpracování. V systémech, kde je důležitá rychlost, je běžnější posílat XML dokumenty přímo přes HTTP, kde jsou parametry požadavku předávány jako normální parametry HTTP. Zatímco SOAP je standard, různé programyčasto generují zprávy v nekompatibilním formátu. Například dotazu generovanému klientem AXIS nebude server WebLogic rozumět. klobouky 23. července 2013 ve 13:09 Ahoj všichni! Doufám, že po přečtení tématu budete schopni: A přesto jsem na něco zapomněl! Když se trochu více zamyslíme, stojí za zmínku, že klient může na server odeslat jednu SMS zprávu najednou nebo určitý počet. Jinými slovy, v jednom datovém paketu může být od jedné do nekonečna zpráv. Výsledkem je, že abychom mohli odeslat SMS zprávu, potřebujeme následující údaje: Odpověděli jsme na první otázku, nyní je třeba odpovědět na otázku druhou. A snad si dovolím trochu podvádět. Ze serveru tedy budeme posílat pouze booleovská data, jejichž hodnota má následující význam: Tím popis problémového prohlášení končí! A konečně, pojďme k tomu nejzajímavějšímu – zjistíme, co je to za podivnou bestii toto SOAP! A svůj příběh začnu tím, že tento protokol pro výměnu dat patří do podmnožiny protokolů založených na tzv. paradigmatu RPC (Remote Procedure Call), jehož antipodem je REST (Representational State Transfer, přenos reprezentativního stavu). Více si o tom můžete přečíst na Wikipedii, odkazy na články jsou na samém konci tématu. Z těchto článků musíme pochopit následující: „Přístup RPC vám umožňuje používat malý počet síťové zdroje S velké množství metody a komplexní protokol. S přístupem REST je počet metod a složitost protokolu výrazně omezena, což může vést k velkému počtu jednotlivých zdrojů.“ To znamená, že ve vztahu k nám to znamená, že na webu v případě přístupu RPC bude vždy jeden vstup (odkaz) na službu a jakou proceduru zavolat pro zpracování příchozích dat, která předáme spolu s daty, zatímco s přístupem REST na našem webu má stránka mnoho vstupů (odkazů), z nichž každý přijímá a zpracovává pouze určitá data. Pokud někdo, kdo čte, ví, jak vysvětlit rozdíl v těchto přístupech ještě jednodušeji, pak určitě napište do komentářů! Další věc, kterou potřebujeme vědět o SOAP je, že tento protokol používá stejné XML jako transport, což je na jednu stranu velmi dobré, protože. okamžitě, plný výkon hromady technologií založených na daný jazyk markup, konkrétně XML-Schema - jazyk pro popis struktury XML dokumentu (díky Wikipedii!), který umožňuje automaticky ověřovat data od klientů přicházejících na server. A tak nyní víme, že SOAP je protokol používaný k implementaci vzdáleného volání procedur a používá XML jako transport! Pokud si přečtete článek na Wikipedii, pak se odtud můžete také dozvědět, že jej lze použít nad jakýmkoli protokolem aplikační vrstvy, a ne pouze spárovat s HTTP (bohužel v tomto tématu budeme uvažovat pouze SOAP přes HTTP). A víte, co se mi na tom všem líbí nejvíc? Pokud neexistují žádné dohady, pak vám dám nápovědu – MÝDLO!… Stejně neexistují žádné odhady?… Určitě jste četl článek na Wikipedii?… Obecně vás nebudu dále mučit. Ihned proto přejdu k odpovědi: „SOAP (z angl. Simple Object Access Protocol – jednoduchý protokol přístup k objektům; dle specifikace 1.2)". Zvýraznění tohoto řádku je uvedeno kurzívou! Nevím, jaké závěry jste z toho všeho vyvodil, ale vidím následující - protože tento protokol v žádném případě nelze nazvat „jednoduchým“ (a zřejmě s tím souhlasí i w3), tak od verze 1.2 přestal být vůbec dešifrovat! A stalo se známé jako SOAP, jen SOAP a tečka. Dobře, prosím, uklouzl jsem trochu na stranu. Jak jsem psal dříve, XML se používá jako transport a pakety, které běží mezi klientem a serverem, se nazývají SOAP obálky. Pokud vezmeme v úvahu zobecněnou strukturu obálky, bude se vám zdát velmi známá, protože připomíná strukturu HTML stránky. Má hlavní část - Obálka, která zahrnuje oddíly záhlaví A Tělo nebo Chyba. V Těloúdaje jsou přenášeny a je to povinná část obálky, přičemž záhlaví je volitelný. V záhlaví může být přenášena autorizace, nebo jakákoliv jiná data, která přímo nesouvisí se vstupními daty procedur webové služby. Pro Chyba není zde nic zvláštního, kromě toho, že to přichází klientovi ze serveru v případě jakýchkoli chyb. Zde můj přehledový příběh o protokolu SOAP končí (na samotné obálky a jejich strukturu se podíváme podrobněji, až se náš klient a server konečně naučí, jak je do sebe zapojit) a začíná nový – o společníkovi SOAP volal WSDL(jazyk popisu webových služeb). Ano, ano, to je právě ta věc, která většinu z nás děsí ze samotného pokusu vzít a implementovat naše API tento protokol. Výsledkem je, že obvykle znovu vynalézáme naše kolo s JSON jako transport. Takže, co je WSDL? WSDL je jazyk pro popis webových služeb a přístup k nim na základě jazyka XML (c) Wikipedie. Pokud vám z této definice nevyplývá celý posvátný význam této technologie, pak se ji pokusím popsat vlastními slovy! WSDL je navržen tak, aby našim klientům umožňoval normální komunikaci se serverem. K tomu jsou v souboru s příponou „*.wsdl“ popsány následující informace: Hlavním úkolem schématu je popsat strukturu dat, která budeme zpracovávat. Všechna data ve schématech XML jsou rozdělena do jednoduchý(skalární) a komplex(struktury) typy. Mezi jednoduché typy patří tyto typy: Navrhuji nejít daleko a napsat schéma XML pro naši zprávu SMS! Níže je uveden xml popis sms zprávy: Myslím, že význam prvků" živel" A " komplexníTyp» vše se vám víceméně vyjasnilo, proto se jim již nebudeme věnovat a přepneme rovnou na prvek skladatel « sekvence". Když použijeme prvek compositor " sekvence» sdělujeme, že prvky v něm obsažené musí být vždy v pořadí uvedeném ve schématu a také všechny jsou povinné. Ale nezoufejte! Ve schématech XML jsou další dva prvky skladatele: výběr" A " Všechno". Hudební skladatel výběr" označuje, že by v něm měl být jeden z uvedených prvků, a skladatel " Všechno» – jakákoli kombinace uvedených prvků. Jak si vzpomínáte, v první části tématu jsme se shodli, že balíček lze přenášet od jedné do nekonečna SMS zpráv. Proto navrhuji pochopit, jak jsou taková data deklarována ve schématu XML. Obecná struktura balíček může vypadat takto: Druhý blok schématu deklaruje prvek " seznam zpráv» typ « Seznam zpráv". Je jasné, že" Seznam zpráv' je komplexní typ, který obsahuje alespoň jeden prvek ' zpráva“, ale maximální počet takových prvků není omezen! Obecně, aby nám vše správně fungovalo, musíme klientovi přenést soubor WSDL se správným MIME typem. Chcete-li to provést, musíte odpovídajícím způsobem nakonfigurovat svůj webový server, konkrétně nastavit typ MIME pro soubory s příponou *.wsdl na následující řádek: Aplikace/wsdl+xml Header("Content-Type: text/xml; charset=utf-8"); Chci vás hned varovat, naše jednoduchá webová služba bude mít poměrně působivý popis, takže se nelekejte, protože. většina textu je povinná voda a jakmile je napsán, může být neustále kopírován z jedné webové služby do druhé! Vzhledem k tomu, že WSDL je XML, musíte o něm hned na prvním řádku napsat přímo. Kořenový prvek souboru se musí vždy jmenovat " definice»:
Poté prohlašujeme, že v naší webové službě " Služba SMS" existuje vstupní bod ("port"), který se nazývá " SmsServicePort". Právě do tohoto vstupního bodu budou odesílány všechny požadavky od klientů na server. A specifikujeme v prvku " adresa» odkaz na soubor obslužného programu, který bude přijímat požadavky. Poté, co jsme definovali webovou službu a určili pro ni vstupní bod, musíme s ní svázat podporované procedury:
Poté musíme proceduru svázat se zprávami:
Nyní je třeba popsat samotné zprávy, tzn. příchozí a odchozí:
Nyní musíme udělat jen málo - přidat popis těchto typů do našeho souboru WSDL! A jak si myslíte, že WSDL popisuje příchozí a odchozí data? Myslím, že už dávno všemu rozumíte a říkáte si, že s pomocí XML schémat! A budete mít naprostou pravdu!
Až bude vše nainstalováno a nakonfigurováno, budeme muset vytvořit soubor “ smsservice.php» s následujícím obsahem: setClass("SoapSmsGateWay"); //Spuštění serveru $server->handle(); Nyní přicházíme na server! Jak vidíte, celý SOAP server má pouze tři řádky! V prvním řádku vytvoříme novou instanci objektu SoapServer a jeho konstruktoru předáme adresu popisu naší webové služby WSDL. Nyní víme, že bude umístěn v kořenovém adresáři hostingu v souboru s mluvící jméno « smsservice.wsdl.php". Ve druhém řádku říkáme SOAP serveru, kterou třídu má stáhnout, aby zpracoval obálku přijatou od klienta a vrátil obálku s odpovědí. Jak jste možná uhodli, v této třídě bude popsána naše jediná metoda. Pošli SMS. Ve třetím řádku spustíme server! Vše, náš server je připraven! K čemuž nám všem gratuluji! Nyní musíme vytvořit soubor WSDL. Chcete-li to provést, můžete buď jednoduše zkopírovat jeho obsah z předchozí části, nebo si ho trochu „upravit“: ";
?>
messageList = new MessageList(); $req->messageList->message = new Message(); $req->messageList->message->phone = "79871234567"; $req->messageList->message->text = "Testovací zpráva 1"; $req->messageList->message->date = "2013-07-21T15:00:00.26"; $req->messageList->message->type = 15; $client = new SoapClient("http://($_SERVER["HTTP_HOST"])/smsservice.wsdl.php", array("soap_version" => SOAP_1_2)); var_dump($client->sendSms($req)); Poté, co jsme definovali objekty, musíme vytvořit objekt ( $požad), který bude odeslán na server. Pak přijdou pro nás dvě nejcennější linie! Náš SOAP klient! Věřte nebo ne, ale to stačí k tomu, aby náš server začal sypat zprávy od klienta a také aby je náš server úspěšně přijal a zpracoval! V prvním z nich vytvoříme instanci třídy SoapClient a jeho konstruktoru předáme adresu umístění souboru WSDL a v parametrech výslovně uvedeme, že budeme pracovat s protokolem SOAP verze 1.2. Na dalším řádku zavoláme metodu Pošli SMS objekt $klient a okamžitě zobrazí výsledek v prohlížeči. Ze serveru jsem obdržel následující objekt: Object(stdClass) public "status" => boolean true Nyní se podívejme na protokol, který obezřetně vedeme na straně serveru! V jeho první části vidíme nezpracovaná data, která vstoupila na server:
Object(stdClass) public "messageList" => object(stdClass) public "message" => object(stdClass) public "phone" => string "79871234567" (délka=11) public "text" => string "Testovací zpráva 1 " (délka=37) public "date" => řetězec "2013-07-21T15:00:00.26" (délka=22) public "type" => řetězec "15" (délka=2) // vytvoření objektu k odeslání na server $req = new Request(); $req->messageList = new MessageList(); $msg1 = nová zpráva(); $msg1->phone = "79871234567"; $msg1->text = "Testovací zpráva 1"; $msg1->date = "2013-07-21T15:00:00.26"; $msg1->type = 15; $msg2 = nová zpráva(); $msg2->phone = "79871234567"; $msg2->text = "Testovací zpráva 2"; $msg2->date = "2014-08-22T16:01:10"; $msg2->type = 16; $msg3 = nová zpráva(); $msg3->phone = "79871234567"; $msg3->text = "Testovací zpráva 3"; $msg3->date = "2014-08-22T16:01:10"; $msg3->type = 17; $req->messageList->message = $msg1; $req->messageList->message = $msg2; $req->messageList->message = $msg3;
Object(stdClass) public "messageList" => object(stdClass) public "message" => object(stdClass) public "Struct" => pole (velikost=3) 0 => object(stdClass) public "phone" => řetězec "79871234567" (délka=11) public "text" => řetězec "Testovací zpráva 1" (délka=37) public "date" => řetězec "2013-07-21T15:00:00.26" (délka=22) public " typ" => řetězec "15" (délka=2) 1 => objekt (stdClass) public "telefon" => řetězec "79871234567" (délka=11) public "text" => řetězec "Testovací zpráva 2" (délka= 37) public "date" => řetězec "2014-08-22T16:01:10" (délka=19) public "type" => řetězec "16" (délka=2) 2 => objekt (stdClass) public "telefon " => řetězec "79871234567" (délka=11) public "text" => řetězec "Testovací zpráva 3" (délka=37) public "datum" => řetězec "2014-08-22T16:01:10" (délka= 19) public "type" => řetězec "17" (délka=2) $req->messageList->message = (objekt)$req->messageList->message;
Object(stdClass) public "messageList" => object(stdClass) public "message" => object(stdClass) public "BOGUS" => pole (size=3) 0 => object(stdClass) public "phone" => string "79871234567" (délka=11) public "text" => řetězec "Testovací zpráva 1" (délka=37) public "date" => řetězec "2013-07-21T15:00:00.26" (délka=22) public " typ" => řetězec "15" (délka=2) 1 => objekt (stdClass) public "telefon" => řetězec "79871234567" (délka=11) public "text" => řetězec "Testovací zpráva 2" (délka= 37) public "date" => řetězec "2014-08-22T16:01:10" (délka=19) public "type" => řetězec "16" (délka=2) 2 => objekt (stdClass) public "telefon " => řetězec "79871234567" (délka=11) public "text" => řetězec "Testovací zpráva 3" (délka=37) public "datum" => řetězec "2014-08-22T16:01:10" (délka= 19) public "type" => řetězec "17" (délka=2) // vytvoření objektu k odeslání na server $req = new Request(); $msg1 = nová zpráva(); $msg1->phone = "79871234567"; $msg1->text = "Testovací zpráva 1"; $msg1->date = "2013-07-21T15:00:00.26"; $msg1->type = 15; $msg2 = nová zpráva(); $msg2->phone = "79871234567"; $msg2->text = "Testovací zpráva 2"; $msg2->date = "2014-08-22T16:01:10"; $msg2->type = 16; $msg3 = nová zpráva(); $msg3->phone = "79871234567"; $msg3->text = "Testovací zpráva 3"; $msg3->date = "2014-08-22T16:01:10"; $msg3->type = 17; $req->messageList = $msg1; $req->messageList = $msg2; $req->messageList = $msg3; $req->messageList = (objekt)$req->messageList;
Object(stdClass) public "messageList" => object(stdClass) public "BOGUS" => pole (velikost=3) 0 => object(stdClass) public "phone" => řetězec "79871234567" (délka=11) public " text" => řetězec "Testovací zpráva 1" (délka=37) public "date" => řetězec "2013-07-21T15:00:00.26" (délka=22) public "type" => řetězec "15" (délka =2) 1 => objekt (stdClass) veřejný "telefon" => řetězec "79871234567" (délka=11) public "text" => řetězec "Testovací zpráva 2" (délka=37) public "datum" => řetězec " 2014-08-22T16:01:10" (délka=19) veřejný "typ" => řetězec "16" (délka=2) 2 => objekt (stdClass) veřejný "telefon" => řetězec "79871234567" (délka= 11) public "text" => string "Test message 3" (délka=37) public "date" => string "2014-08-22T16:01:10" (length=19) public "type" => string " 17" (délka=2) 10 odpovědí WSDL je dokument XML, který popisuje webovou službu. Ve skutečnosti to znamená jazyk definice webové služby. SOAP je protokol založený na XML, který umožňuje výměnu informací mezi aplikacemi přes specifický protokol (jako je HTTP nebo SMTP). Je to zkratka pro Simple Object Access Protocol a používá XML pro svůj formát zpráv k přenosu informací. REST je architektonický styl síťové systémy a prosazuje přesun reprezentativního státu. Není to standard sám o sobě, ale používá standardy jako HTTP, URL, XML atd. Pokaždé, když někdo zmíní SOAP/WSDL, myslím na objekty a třídy definované v xml... "Používáte SOAP stejně jako každá třída PHP. V tomto případě však třída neexistuje v místním prostředí." souborový systém aplikací, ale na vzdáleném hostiteli přístupném přes http."... "Pokud uvažujeme o použití služby SOAP jako další třídy PHP, pak dokument WSDL je seznam všech dostupné metody a vlastnosti třídy. A kdykoli někdo mluví o REST, myslím na HTTP příkazy (metody požadavku) jako POST, GET a DELETE Příklad: jednoduchými slovy pokud máte webovou službu kalkulačky. WSDL: WSDL hovoří o funkcích, které můžete implementovat nebo zpřístupnit klientovi. Například: sčítání, odebírání, odečítání atd. SOAP: kde pomocí SOAP ve skutečnosti provádíte akce jako doDelete(), doSubtract(), doAdd(). SOAP a WSDL jsou tedy jablka a pomeranče. Neměli bychom je srovnávat. Oba mají své vlastní funkce. Proč používáme SOAP a WSDL: k výměně dat nezávislých na platformě. EDIT: V běžném každodenním životě: WSDL: Když jdeme do restaurace, vidíme položky menu, toto je WSDL. Proxy třídy: Nyní, když se podíváme na položky nabídky, rozhodneme se (zpracujeme pohled na objednávku): Takže v podstatě vytváříme třídy Proxy založené na dokumentu WSDL. MÝDLO: Pak, když si skutečně objednáme jídlo na základě menu: předpokládáme, že použijeme proxy třídy k volání servisních metod, které se provádějí pomocí SOAP. :) SOAP → SOAP (Simple Object Access Prototype) je aplikační protokolová vrstva určená pro komunikaci mezi stroji. Protokol definuje standardní pravidla. Všechny strany, které používají určitý protokol, musí dodržovat pravidla protokolu. Stejně jako TCP se odvíjí na transportní vrstvě. Protokol SOAP bude chápán na aplikační úrovni (jakákoli aplikace, která podporuje SOAP - Axis2, .Net). Zpráva WSDL → SOAP se skládá z SoapEnevelope-> SoapHeader a SoapBody. Nedefinuje, jaký bude formát zprávy? jaké všechny transporty (HTTP, JMS) jsou podporovány? bez těchto informací. Pro každého klienta, který chce použít konkrétní webovou službu k vytvoření zprávy SOAP, je to obtížné. I když ano, nebudou mít jistotu, že to bude fungovat pořád. WSDL je zachránce. WSDL (Web Services Description Language) definuje operace, formáty zpráv a přenosová data pro zprávu SOAP. REST → REST (Representation State Transfer) je založen na dopravě. Na rozdíl od SOAP, které je zaměřeno na akce, REST je více o zdrojích. REST najde zdroje pomocí adresy URL (příklad -http://(adresa serveru)/zaměstnanci/číslo zaměstnance/12345) a závisí na transportní protokol(s HTTP-GET, POST, PUT, DELETE, ...) pro akce ke spuštění zdrojů. Služba REST vyhledá zdroj na základě adresy URL a provede akci na základě slovesa transportní akce. Je to spíše architektonický styl a konvence. SOAP je zkratka pro Simple (sic) Object Access Protocol. Jeho cílem bylo provádět vzdálená volání procedur vzdáleným objektům odesláním XML přes HTTP. WSDL je jazyk popisu webových služeb. Požadavek končící koncovým bodem ".wsdl" bude mít za následek reprezentaci zprávy XML popisující požadavek a odpověď, kterou může použití očekávat. Popisuje smlouvu mezi službou a klientem. REST používá HTTP k odesílání zpráv službám. SOAP je specifikace, REST je styl. Nebudete „jen“ rozumět něčemu složitému. WSDL je jazyk založený na XML pro popis webové služby. Popisuje zprávy, operace a informace o dopravní síť Používané službou. Tyto webové služby obvykle používají SOAP, ale mohou používat i jiné protokoly. WSDL je čten programem a lze jej tedy použít ke generování celého kódu klienta nebo jeho části potřebného k vyvolání webové služby. To znamená nazývat webové služby orientované na SOAP „sebepopisující“. REST s WSDL vůbec nesouvisí. Wikipedia říká: "Web Services Description Language je jazyk založený na XML, který poskytuje model pro popis webových služeb." Jinými slovy, WSDL odkazuje na webovou službu, jako javadoc odkazuje na java. Na WSDL je však velmi pěkné to software může generovat klienta a server pomocí WSDL.. Obsahuje požadovaný vnořený prvek<:value>s kódem chyby a volitelným vnořeným prvkem 
Základní koncepty protokolů:
Strana, která odesílá zprávu SOAP, se nazývá odesílatel SOAP, strana, která zprávu přijímá, se nazývá příjemce SOAP. Cesta, kterou zpráva SOAP vede od původního odesílatele ke konečnému příjemci, se nazývá trasa zprávy. Cesta zprávy obsahuje původního odesílatele, konečného příjemce a 0 nebo více prostředníků SOAP. Entity, které zpracovávají zprávy podle pravidel definovaných protokoly SOAP, se nazývají uzly SOAP. Elementární jednotka informací, která se účastní výměny mezi SOAP uzly, se nazývá SOAP zpráva - jedná se o XML dokument se SOAP obalem kořenového prvku.Psaní SOAP klient-server aplikace v PHP
Tak se stalo, že jsem se v poslední době začal věnovat vývoji webových služeb. Ale dnes toto téma není o mně, ale o tom, jak můžeme napsat vlastní XML webovou službu založenou na protokolu SOAP 1.2.
Jak asi tušíte, všechna kouzla budou hotová pomocí PHP a vestavěné třídy SoapClient a SoapServer. Jako králík budeme mít službu na posílání sms zpráv. 1 Problémové prohlášení
1.1 Hranice
Na začátku navrhuji zabývat se výsledkem, kterého dosáhneme na konci tématu. Jak bylo avizováno výše, napíšeme službu pro odesílání sms zpráv, přesněji řečeno budeme přijímat zprávy z různých zdrojů pomocí protokolu SOAP. Poté zvážíme, v jaké formě přicházejí na server. Proces řazení zpráv do fronty pro další odesílání poskytovateli bohužel z mnoha důvodů přesahuje rámec tohoto příspěvku. 
1.2 Jaké údaje budou změněny?
Dobře, máme limity! Dalším krokem, který je třeba udělat, je rozhodnout, jaká data si budeme mezi serverem a klientem vyměňovat. Na toto téma navrhuji, abyste nebyli dlouho moudřejší a okamžitě si odpověděli na hlavní otázky:
Něco mi říká, že k tomu je nutné odeslat následující:
V zásadě stačí tyto dvě charakteristiky k odeslání, ale hned se mi zdá, že vám přijde sms s přáním k narozeninám ve 3 hodiny ráno, nebo ve 4! V tuto chvíli budu všem moc vděčná, že na mě nezapomněli! Proto také zašleme na server a
Další věc, kterou bych chtěl poslat na server, je
Tento parametr není povinný, ale může se nám velmi hodit, pokud potřebujeme rychle šéfovi sdělit, kolik našich klientů jsme „potěšili“ našimi novinkami, a také nakreslit krásné statistiky v této věci. 
2 Co je SOAP?
Obecně jsem původně neměl v plánu psát nic o tom, co je SOAP, a chtěl jsem se omezit na odkazy na stránky w3.org s potřebnými specifikacemi a odkazy na Wikipedii. Ale nakonec jsem se rozhodl napsat krátkou referenci o tomto protokolu. 
Jak je vidět, daný soubor a tam je celá webová služba. Zadáním adresy WSDL souboru v klientovi budeme vědět vše o jakékoli webové službě! V důsledku toho nemusíme vědět absolutně nic o tom, kde se samotná webová služba nachází. Stačí znát umístění jeho WSDL souboru! Brzy zjistíme, že SOAP není tak děsivý, jak se maluje (c) ruské přísloví. 3 Úvod do schématu XML
Nyní víme hodně o tom, co je SOAP, co je v něm, a máme přehled o tom, jaký technologický stack ho obklopuje. Protože SOAP je především způsob interakce mezi klientem a serverem a jazyk se pro něj používá jako transport. XML značení, pak v této části trochu pochopíme, jak probíhá automatická validace dat prostřednictvím schémat XML.
Něco velmi jednoduchého, co nemá uvnitř žádné rozšíření. Jejich antipodem jsou složité komplexní typy. Nejjednodušším příkladem složitého typu, který každého napadne, jsou předměty. Například kniha. Kniha se skládá z vlastností: autor, název, cena, ISBN číslo atd. A tyto vlastnosti zase mohou být jak jednoduché typy, tak složité. A úkolem XML schématu je popsat jej.
Naše schéma komplexního typu bude vypadat takto:
Tento záznam zní následovně: máme proměnnou " zpráva» typ « zpráva"a existuje složitý typ s názvem" zpráva", který se skládá ze sekvenční sady prvků" telefon» typ tětiva, « text» typ tětiva, « datum» typ čas schůzky, « typ» typ desetinný. Tyto typy jsou jednoduché a jsou již definovány v definici schématu. Gratulujeme! Právě jsme napsali naše první schéma XML!
Schéma pro takový komplexní typ by vypadalo takto:
První blok obsahuje známou deklaraci komplexního typu „ zpráva". Pokud si všimnete, pak v každém jednoduchém typu zahrnutém v " zpráva“, byly přidány nové kvalifikační atributy “ minOccurs" A " maxOccurs". Jak není těžké uhodnout z názvu, první ( minOccurs) označuje, že daná sekvence musí obsahovat alespoň jeden prvek typu " telefon», « text», « datum" A " typ“, zatímco další ( maxOccurs) nám deklaruje, že v naší sekvenci je maximálně jeden takový prvek. Výsledkem je, že když píšeme naše schémata pro jakákoli data, máme nejširší výběr, jak je nakonfigurovat!4 Zápis vašeho WSDL
Pamatujete si, že WSDL je naše webová služba? Doufám, že si pamatuješ! Jak to píšeme, bude na něm plavat naše malá webová služba. Takže doporučuji nepodvádět.
Ale v praxi jsem obvykle posílal HTTP hlavičku přes PHP " text/xml»:
a vše fungovalo skvěle!
Obvykle se WSDL skládá ze 4-5 hlavních bloků. Úplně prvním blokem je definice webové služby, nebo jinými slovy vstupního bodu.
Tady se píše, že máme službu s názvem -" Služba SMS". V zásadě si můžete všechna jména v souboru WSDL změnit na cokoliv si budete přát, protože nehrají absolutně žádnou roli.
K tomu vypíše, které operace a v jakém tvaru se bude y volat. Tito. pro přístav SmsServicePort» vazba s názvem « SmsServiceBinding", který má typ volání " rpc” a HTTP se používá jako přenosový protokol (transport). Tudíž jsme zde naznačili, že budeme implementovat RPC volání přes HTTP. Poté popíšeme, které postupy ( úkon) jsou podporovány ve webové službě. Budeme podporovat pouze jeden postup - " Pošli SMS". Prostřednictvím tohoto postupu budou naše skvělé zprávy odeslány na server! Po vyhlášení postupu je nutné uvést, v jaké formě budou údaje předány. V tento případ specifikoval, že budou použity standardní SOAP obálky.
Za tímto účelem specifikujeme, že naše vazba ("vazba") je typu " SmsServicePortType"a v prvku" portType» se stejným názvem typu zadejte vazbu procedur na zprávy. Tak, příchozí zpráva(klient na server) se bude nazývat " sendSmsRequest"a odchozí (ze serveru ke klientovi)" sendSmsResponse". Stejně jako všechna jména ve WSDL jsou názvy příchozích a odchozích zpráv libovolné.
K tomu přidáme prvky " zpráva» se jmény « sendSmsRequest" A " sendSmsResponse“ resp. V nich označujeme, že na vstup má přijít obálka, jejíž struktura odpovídá datovému typu " Žádost". Poté se ze serveru vrátí obálka obsahující datový typ - " Odezva».
Můžete nám gratulovat! Náš první WSDL byl napsán! A jsme o krok blíže k dosažení našeho cíle.
Dále se budeme zabývat tím, co nám PHP poskytuje pro vývoj vlastních distribuovaných aplikací.5 Náš první SOAP server
Již dříve jsem psal, že k vytvoření SOAP serveru v PHP použijeme vestavěnou třídu SoapServer. Aby všechny další akce proběhly stejně jako moje, budete muset trochu upravit své PHP. Abychom byli ještě přesnější, musíte se ujistit, že máte nainstalované rozšíření „php-soap“. Jak jej umístit na váš webový server si nejlépe přečtěte na oficiálních stránkách PHP (viz reference).
Co je nad řádkem u funkce „ini_set“, doufám, není třeba vysvětlovat. Protože definuje, které HTTP hlavičky budeme odesílat ze serveru klientovi a konfiguruje prostředí. V řádku „ini_set“ zakážeme ukládání do mezipaměti souboru WSDL, aby se naše změny v něm okamžitě projevily na klientovi.
V této fázi by nám měl výsledný server plně vyhovovat, protože. můžeme zaznamenat obálky, které k němu přicházejí, a pak v klidu analyzovat příchozí data. Abychom mohli přijímat cokoli na server, potřebujeme klienta. Tak pojďme na ně!6 SOAP klient na cestě
Nejprve si musíme vytvořit soubor, do kterého budeme klienta zapisovat. Jako obvykle jej vytvoříme v kořenovém adresáři hostitele a nazveme jej „ klient.php“ a dovnitř napíšeme následující:
Popišme naše předměty. Když jsme psali WSDL, byly v něm popsány tři entity pro obálku vstupující na server: Žádost, Seznam zpráv A zpráva. V souladu s tím třídy Žádost, Seznam zpráv A zpráva jsou odrazy těchto entit v našem PHP skriptu.
Pojďme to spustit a uvidíme, co jsme nakonec dostali!
A to je úžasné, protože. nyní s jistotou víme, že náš server funguje a nejen že funguje, ale také může klientovi vrátit některé hodnoty!
Toto je obálka. Teď už víte, jak to vypadá! Ale je nepravděpodobné, že bychom měli zájem jej neustále obdivovat, takže pojďme deserializovat objekt ze souboru protokolu a uvidíme, zda je s námi vše v pořádku:
Jak vidíte, objekt byl deserializován správně, k čemuž bych chtěl nám všem pogratulovat! Dále nás čeká něco zajímavějšího! Klientem totiž na server nepošleme jednu sms zprávu, ale celý balíček (přesněji tři celé)!7 Odesílání složitých objektů
Pojďme se zamyslet nad tím, jak můžeme poslat na server spoustu zpráv v jednom balíčku? Asi nejvíc jednoduchým způsobem uvnitř elementu messageList bude organizace pole! Pojďme na to:
Naše protokoly ukazují, že následující paket přišel od klienta:
Jaký nesmysl, říkáte si? A budete mít v jistém smyslu pravdu, protože. stejně jako jsme se dozvěděli, že který objekt opustil klienta, přišel na náš server ve formě obálky v úplně stejné podobě. Pravda, sms zprávy nebyly serializovány v XML tak, jak jsme potřebovali – musely být zabaleny do prvků zpráva, ne v Struktura. Nyní se podívejme, v jaké formě takový objekt do metody přichází Pošli SMS:
Co nám toto poznání dává? Pouze to, že cesta, kterou jsme zvolili, není správná a nedostali jsme odpověď na otázku - „Jak můžeme získat správnou datovou strukturu na serveru?“. Ale navrhuji, abychom nezoufali a pokusili se přenést naše pole na typ objekt:
V tomto případě obdržíme další obálku:
Vstoupil do metody Pošli SMS objekt má následující strukturu:
Pokud jde o mě, pak „ze změny místa pojmů se součet nemění“ (c). Co FALEŠNÝ, Co Struktura Ještě jsme nedosáhli svého cíle! A abychom toho dosáhli, musíme se ujistit, že místo těchto nesrozumitelných jmen bude náš rodák zpráva. Jak toho ale dosáhnout, zatím autor neví. Proto jediné, co můžeme udělat, je zbavit se přebytečného kontejneru. Jinými slovy, nyní se ujistíme, že místo toho zpráva stal se FALEŠNÝ! Chcete-li to provést, změňte objekt takto:
Najednou máme štěstí a ustoupíme ze schématu správné jméno? Chcete-li to provést, podívejme se na doručenou obálku:
Ano, zázrak se nestal! FALEŠNÝ- nevyhrajeme! Vstoupil Pošli SMS objekt v tomto případě bude vypadat takto:
Jak se říká - "Skoro"! V této (trochu smutné) poznámce navrhuji, abychom to tiše zakončili a vyvodili pro sebe nějaké závěry.8 Závěr
Konečně jsme se sem dostali! Pojďme se rozhodnout, co můžete nyní udělat:
Během našeho malého výzkumu jsme také učinili několik objevů pro sebe: