Technologie mýdla. Protokol SOAP a webové služby. Co je SOAP

• Konzultace

Ahoj všichni!
Stalo se tak, že v v poslední době Začal jsem vyvíjet webové služby. 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.

Doufám, že po přečtení tématu budete schopni:

• napsat vlastní serverovou implementaci webové aplikace;
• napsat vlastní klientskou implementaci webové aplikace;
• napsat svůj vlastní vlastní popis webová služba (WSDL);
• odeslat klientská pole stejného typu dat na server.

Jak jste možná uhodli, všechna kouzla se budou dít s pomocí PHP a vestavěné třídy SoapClient a SoapServer. Náš králík bude služba pro zasí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 oznámeno 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ů prostřednictvím 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 změníme?

Skvělé, rozhodli jsme se pro hranice! Dalším krokem, který je třeba učinit, je rozhodnout, jaká data si budeme mezi serverem a klientem vyměňovat. Na toto téma navrhuji neštípat vlasy příliš dlouho a okamžitě si odpovědět na hlavní otázky:

• Jaká minimální data musí být odeslána na server, aby bylo možné odeslat SMS zprávu účastníkovi?
• Jaká minimální data musí být odeslána ze serveru, aby byly uspokojeny potřeby klienta?

Něco mi říká, že k tomu musíte odeslat následující:

• číslo mobilní telefon a také
• text SMS zprávy.

V zásadě tyto dvě vlastnosti k odeslání stačí, ale okamžitě si představím případ, kdy vám SMS s blahopřáním k narozeninám přijde 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

• datum odeslání SMS zprávy.

Další věc, kterou bych chtěl poslat na server, je:

• Typ zprávy.

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.

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 buď jednu SMS zprávu, nebo jich několik najednou. Jinými slovy, jeden datový paket může obsahovat od jedné do nekonečna zpráv.

Výsledkem je, že k odeslání SMS zprávy potřebujeme následující údaje:

• číslo mobilního telefonu,
• text SMS zprávy,
• čas odeslání SMS zprávy účastníkovi,
• typ zprávy.

Odpověděli jsme na první otázku, nyní musíme odpovědět na druhou otázku. A možná si dovolím trochu makat. Ze serveru tedy budeme posílat pouze booleovská data, jejichž význam má následující význam:

• TRUE – paket úspěšně dorazil na server, prošel autentizací a zařazen do fronty k odeslání poskytovateli SMS
• NEPRAVDA – ve všech ostatních případech

Tímto popis problémového prohlášení končí! A konečně se pustíme do té zábavné části – pojďme přijít na to, co je to za podivnou bestii toto SOAP!

2 Co je SOAP?

Obecně jsem zpočátku neměl v plánu psát nic o tom, co je SOAP a chtěl jsem se omezit na odkazy na web w3.org s potřebnými specifikacemi a také na odkazy na Wikipedii. Ale na úplný závěr jsem se rozhodl o tomto protokolu napsat krátkou poznámku.

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). 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 umožňuje použití malého počtu síťové zdroje S velký počet metody a komplexní protokol. S přístupem REST je počet metod a složitost protokolu přísně omezena, což znamená, že počet jednotlivých zdrojů může být velký.“ To znamená, že ve vztahu k nám to znamená, že v případě přístupu RPC na webu bude vždy jeden vstup (odkaz) na službu a jaký postup zavolat pro zpracování příchozích dat, která předáváme spolu s daty, přičemž s přístupem REST v našem Web má mnoho vstupů (odkazů), z nichž každý přijímá a zpracovává pouze určitá data. Pokud někdo, kdo čte, ví, jak ještě jednodušeji vysvětlit rozdíl v těchto přístupech, 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ě náš arzenál získá plnou sílu 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 automatickou validaci dat přijatých serverem od klientů.

A tak nyní víme, že SOAP je protokol používaný k implementaci vzdálených volání procedur a používá XML jako transport! Pokud si přečtete článek na Wikipedii, můžete se tam také dozvědět, že jej lze použít nad jakýmkoli protokolem aplikační úroveň, a to nejen v kombinaci 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 dám nápovědu - MÝDLO!... Stále žádné odhady?... Jste si jisti, že jste četl článek na Wikipedii?... Obecně vás nebudu dále mučit. Proto přejdu přímo k odpovědi: „SOAP (z anglického Simple Object Přístupový protokol- jednoduché protokol přístup k objektům; dle specifikace 1.2)". To nejpozoruhodnější na tomto řádku je vyznačeno kurzívou! Nevím, jaké závěry jste z toho všeho vyvodil, ale vidím následující - jelikož tento protokol nelze v žádném případě nazvat „jednoduchým“ (a zřejmě s tím souhlasí i w3), tak se od verze 1.2 přestal nějak dešifrovat ! A stalo se známé jako SOAP, prostě SOAP, tečka.

Dobře, prosím, omluvte mě, trochu jsem odbočil. Jak jsem již psal dříve, XML se používá jako transport a pakety, které cestují mezi klientem a serverem, se nazývají SOAP obálky. Pokud vezmete v úvahu obecnou strukturu obálky, bude vám připadat velmi povědomá, 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í mohou být přenášena oprávnění nebo jakákoli jiná data, která přímo nesouvisejí se vstupními daty postupů webové služby. O 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 recenzní příběh o protokolu SOAP končí (na samotné obálky a jejich strukturu se podíváme podrobněji, až se je náš klient a server konečně naučí provozovat jeden na druhém) a začíná nový – o společníkovi SOAP tzv. 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í od snahy převzít a implementovat naše API tento protokol. Výsledkem je, že obvykle znovu vynalézáme naše kolo s JSON jako transport. Co je tedy WSDL? WSDL je jazyk pro popis webových služeb a přístup k nim na základě jazyk XML(c) Wikipedie. Pokud vám tato definice neobjasňuje celý posvátný význam této technologie, pak se ji pokusím popsat vlastními slovy!

WSDL je navrženo tak, aby našim klientům umožnilo normálně komunikovat se serverem. Chcete-li to provést, soubor s příponou „*.wsdl“ popisuje následující informace:

• Jaké jmenné prostory byly použity?
• Jaká datová schémata byla použita?
• Jaké typy zpráv webová služba od klientů očekává?
• Která data patří ke kterým procedurám webové služby,
• Jaké procedury webová služba obsahuje?
• Jak by měl klient volat postupy webové služby,
• Na jakou adresu mají být hovory zákazníků zasílány?

Jak můžete vidět, tento 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í. Vše, co potřebujete vědět, je umístění jeho souboru WSDL! Brzy zjistíme, že SOAP není tak děsivý, jak o něm říkají 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 technologickém zásobníku, který jej obklopuje. Vzhledem k tomu, že SOAP je především metoda interakce mezi klientem a serverem a jako přenos se pro něj používá značkovací jazyk XML, v této části trochu porozumíme tomu, jak probíhá automatická validace dat pomocí schémat XML.

Hlavním úkolem diagramu 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ří následující typy:

• čára,
• číslo,
• booleovská hodnota,
• datum.

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ému přijde na mysl, jsou předměty. Například kniha. Kniha se skládá z vlastností: autor, Jméno, cena, ISBN číslo atd. A tyto vlastnosti zase mohou být buď jednoduchého typu, nebo složité. A úkolem XML schématu je to popsat.

Doporučuji nechodit daleko a napsat schéma XML pro naši SMS zprávu! Níže je uveden xml popis SMS zprávy:

71239876543 Testovací zpráva 2013-07-20T12:00:00 12
Náš komplexní typový diagram bude vypadat takto:

Tento záznam zní následovně: Máme proměnnou " zpráva"typ" Zpráva"a existuje komplexní typ zvaný" Zpráva", který se skládá ze sekvenční sady prvků" telefon"typ řetězec, « text"typ řetězec, « datum"typ datum a čas, « typ"typ desetinný. Tyto typy jsou jednoduché a jsou již definovány v popisu schématu. Gratuluji! Právě jsme napsali naše první schéma XML!

Myslím, že význam prvků" živel"A" komplexníTyp"Všechno je vám víceméně jasné, takže se na ně nebudeme více soustředit a přejdeme rovnou ke skladatelskému prvku." sekvence" Když použijeme prvek skladatel " sekvence„Informujeme vás, že prvky v něm obsažené musí být vždy umístěny v pořadí uvedeném ve schématu a všechny jsou povinné. Ale nezoufejte! Ve schématech XML jsou další dva prvky skladatele: " výběr"A" vše" skladatel" výběr" oznamuje, že v něm musí být jeden z uvedených prvků, a skladatel" vše» – jakákoli kombinace uvedených prvků.

Jak si pamatujete, v první části tématu jsme se shodli, že SMS zprávy lze přenášet v balíčku od jedné do nekonečna. Proto navrhuji pochopit, jak jsou taková data deklarována ve schématu XML. Obecná struktura balíčku může vypadat takto:

71239876543 Testovací zpráva 1 2013-07-20T12:00:00 12 71239876543 Testovací zpráva N 2013-07-20T12:00:00 12
Diagram pro takový složitý typ bude vypadat takto:

První blok obsahuje známou deklaraci komplexního typu „ Zpráva" Pokud jste si všimli, tak v každém jednoduchý typ, zahrnuté v " Zpráva", byly přidány nové objasňující atributy " minOccurs"A" maxOccurs" Jak můžete uhodnout z názvu, první ( minOccurs) označuje, že tato 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 vlastní schémata pro jakákoli data, máme nejširší výběr, jak je nakonfigurovat!

Druhý blok diagramu 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!

4 Napište svůj WSDL

Pamatujete si, že WSDL je naše webová služba? Doufám, že si pamatuješ! Během psaní na něm poběží naše malá webová služba. Proto doporučuji se nemotat.

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
Ale v praxi jsem obvykle posílal HTTP hlavičku přes PHP " text/xml»:

Header("Content-Type: text/xml; charset=utf-8");
a vše fungovalo skvěle!

Chci vás hned varovat, že 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 jej jednou napíšete, můžete jej neustále kopírovat z jedné webové služby do druhé!

Protože WSDL je XML, musíte o tom napsat přímo na prvním řádku. Kořenový prvek souboru by se měl vždy jmenovat " definice»:

Typicky se WSDL skládá ze 4-5 hlavních bloků. Hned 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 chcete, protože nehrají absolutně žádnou roli.

Poté oznamujeme, že v naší webové službě " Služba SMS" existuje vstupní bod ("port") s názvem " SmsServicePort" Právě do tohoto vstupního bodu budou odesílány všechny požadavky od klientů na server. A uveďte v prvku „ adresa» odkaz na soubor obsluhy, který bude přijímat požadavky.

Jakmile definujeme webovou službu a určíme pro ni vstupní bod, musíme s ní svázat podporované procedury:

K tomu vypíše, které operace a v jaké formě budou volány. Tito. pro port" SmsServicePort"vazba je definována pod názvem" SmsServiceBinding", který má typ volání " rpc"a HTTP se používá jako přenosový protokol. Proto jsme zde uvedli, že provedeme volání RPC přes HTTP. Poté popíšeme, které postupy ( operace) jsou podporovány ve webové službě. Budeme podporovat pouze jeden postup – “ odeslatSms" 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 v tomto případě je specifikováno, že budou použity standardní SOAP obálky.

Poté musíme proceduru svázat se zprávami:

Za tímto účelem specifikujeme, že naše vazba je typu " SmsServicePortType"a v prvku" portType„názvem stejného typu označujeme vazbu procedur na zprávy. Tak, příchozí zpráva(z klienta na server) se bude nazývat " sendSmsRequest"a odchozí (ze serveru na klienta) " sendSmsResponse" Stejně jako všechna jména ve WSDL jsou názvy příchozích a odchozích zpráv libovolné.

Nyní je třeba popsat samotné zprávy, tzn. příchozí a odchozí:

K tomu přidáme prvky " zpráva"se jmény" sendSmsRequest"A" sendSmsResponse“ resp. V nich uvádíme, že vstupem by měla být obálka, jejíž struktura odpovídá datovému typu " Žádost" Poté se ze serveru vrátí obálka obsahující datový typ - “ Odpověď».

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ž jste vše dávno pochopili a řekli si, že pomocí XML schémat! A budete mít naprostou pravdu!

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 podíváme na to, co nám PHP poskytuje k vývoji vlastního distribuované aplikace.

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 bylo vše v pořádku další akce se stalo stejným způsobem jako u mě, 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 nainstalovat na webový server je nejlepší si přečíst na oficiálních stránkách PHP (viz seznam referencí).

Poté, co bude vše nainstalováno a nakonfigurováno, budeme muset vytvořit soubor v kořenové složce vašeho hostingu “ smsservice.php» s následujícím obsahem:

setClass("SoapSmsGateWay"); //Spuštění serveru $server->handle();
Doufám, že není třeba vysvětlovat, co je nad řádkem s funkcí „ini_set“. Protože tam se určí, které HTTP hlavičky budeme odesílat ze serveru klientovi a nakonfiguruje se prostředí. V řádku s „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.

Nyní přicházíme na server! Jak vidíte, celý SOAP server zabírá pouze tři řádky! Na prvním řádku vytvoříme novou instanci objektu SoapServer a jejímu konstruktoru předáme adresu našeho WSDL popisu webové služby. Nyní víme, že bude umístěn v kořenovém adresáři hostingu v souboru se samovysvětlujícím názvem „ smsservice.wsdl.php" Na druhém řádku sdělíme SOAP serveru, kterou třídu je třeba stáhnout, aby bylo možné zpracovat obálku přijatou od klienta a vrátit obálku s odpovědí. Jak jste možná uhodli, v této třídě bude popsána naše jediná metoda odeslatSms. Na třetím řádku spustíme server! To je 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 „vymodelovat“:

"; ?> /" 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" />
V této fázi bychom měli být s výsledným serverem zcela spokojeni, 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 jdeme na to!

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í:

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));
Popišme naše předměty. Když jsme psali WSDL, popisoval tři entity pro obálku přicházející na server: Žádost, Seznam zpráv A Zpráva. Podle toho třídy Žádost, Seznam zpráv A Zpráva jsou odrazy těchto entit v našem PHP skriptu.

Jakmile máme definovány objekty, musíme vytvořit objekt ( $požad), který odešleme na server. Poté následují dvě pro nás nejcennější linie! Náš SOAP klient! Věřte nebo ne, stačí to k tomu, aby náš server začal přijímat 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 předáme jeho konstruktoru adresu umístění souboru WSDL a v parametrech výslovně označíme, že budeme pracovat s protokolem SOAP verze 1.2. Na dalším řádku zavoláme metodu odeslatSms objekt $klient a okamžitě zobrazí výsledek v prohlížeči.
Pojďme to spustit a uvidíme, co jsme nakonec dostali!

Ze serveru mi byl vrácen následující objekt:

Object(stdClass) public "status" => boolean true
A to je skvělé, 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!

Nyní se podívejme na protokol, který obezřetně vedeme na straně serveru! V jeho první části vidíme nezpracovaná data, která dorazila na server:

79871234567 Testovací zpráva 1 2013-07-21T15:00:00.26 15
Toto je obálka. Teď už víte, jak to vypadá! Ale je nepravděpodobné, že se na to budeme chtít neustále dívat, takže pojďme deserializovat objekt ze souboru protokolu a uvidíme, zda je vše v pořádku:

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)
Jak vidíte, objekt byl deserializován správně, k čemuž nám všem chci pogratulovat! Příště nás čeká něco zajímavějšího! Klientovi totiž pošleme na server nejen jednu SMS zprávu, ale celý balíček (přesněji tři)!

7 Odesílání složitých objektů

Pojďme se zamyslet nad tím, jak můžeme na server přenést spoustu zpráv v jednom paketu? Asi nejvíc jednoduchým způsobem uvnitř elementu messageList bude organizace pole! Udělejme toto:

// 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->typ = 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;
Naše protokoly ukazují, že od klienta byl přijat následující paket:

79871234567 Testovací zpráva 1 2013-07-21T15:00:00.26 15 79871234567 Testovací zpráva 2 2014-08-22T16:01:10 16 79871234567 Testovací zpráva 3 2014-08-22T16:01:10 17
Jaký nesmysl, říkáte si? A v jistém smyslu budete mít pravdu, protože... Jakmile jsme se dozvěděli, že objekt opustil klienta, přišel na náš server v naprosto stejné podobě ve formě obálky. 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í odeslatSms:

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)
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?" Navrhuji ale nezoufat a zkusit převést naše pole na typ objekt:

$req->messageList->message = (objekt)$req->messageList->message;
V tomto případě obdržíme další obálku:

79871234567 Testovací zpráva 1 2013-07-21T15:00:00.26 15 79871234567 Testovací zpráva 2 2014-08-22T16:01:10 16 79871234567 Testovací zpráva 3 2014-08-22T16:01:10 17
Vstoupil do metody odeslatSms objekt má následující strukturu:

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)
Pokud jde o mě, „součet se změnou místa podmínek nemění“ (c). Co FALEŠNÝ, co Struktura– ještě jsme nedosáhli našeho cíle! A abychom toho dosáhli, musíme zajistit, aby se místo těchto nesrozumitelných jmen zobrazovalo naše rodné zpráva. Autor ale zatím neví, jak toho dosáhnout. 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 se stal FALEŠNÝ! Chcete-li to provést, změňte objekt takto:

// 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->typ = 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;
Co když budeme mít štěstí a z diagramu vypadne správný název? Chcete-li to provést, podívejme se na doručenou obálku:

79871234567 Testovací zpráva 1 2013-07-21T15:00:00.26 15 79871234567 Testovací zpráva 2 2014-08-22T16:01:10 16 79871234567 Testovací zpráva 3 2014-08-22T16:01:10 17
Ano, zázrak se nestal! FALEŠNÝ- nevyhrajeme! Přišel odeslatSms objekt v tomto případě bude vypadat takto:

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)
Jak se říká – „Téměř“! V této (trochu smutné) poznámce navrhuji věci pomalu zabalit a vyvodit pro sebe nějaké závěry.

8 Závěr

Konečně jsme se sem dostali! Pojďme zjistit, co můžete nyní udělat:

• můžete napsat soubor WSDL nezbytný pro vaši webovou službu;
• můžete snadno napsat vlastního klienta, který může komunikovat se serverem přes SOAP;
• můžete napsat svůj vlastní vlastní server komunikace s vnějším světem prostřednictvím SOAP;
• můžete posílat pole objekty stejného typu na server z vašeho klienta (s určitými omezeními).

Během našeho malého výzkumu jsme také učinili několik objevů:

• nativní třída SoapClient správně serializuje datové struktury stejného typu v XML;
• při serializaci pole do XML, které vytvoří extra prvek se jménem Struktura;
• při serializaci objektu do XML se vytvoří zvláštní prvek nazvaný FALEŠNÝ;
• FALEŠNÝ menší zlo jak Struktura díky tomu, že obálka je kompaktnější (do XML hlavičky obálky se nepřidávají další jmenné prostory);
• Bohužel třída SoapServer automaticky neověřuje data obálek s naším schématem XML (možná to nedělají ani jiné servery).

MÝDLO- textový protokol, který používá XML k výměně strukturovaných zpráv v distribuci výpočetní prostředí. SOAP bylo původně zamýšleno především k implementaci vzdáleného volání procedur (RPC) a název byl zkratkou: Simple Object Access Protocol. Protokol se nyní používá k výměně libovolných zpráv ve formátu XML, a nikoli pouze k volání procedur. Oficiální specifikace nejnovější verzi 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í vrstvy: 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 jsou založeny 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 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řes HTTP přímo, kde jsou parametry požadavku předávány jako běžné parametry HTTP.

· Přestože je SOAP standardem, různé programyčasto generují zprávy v nekompatibilním formátu. Například požadavek vygenerovaný klientem AXIS nebude serverem WebLogic pochopen.

Základní pojmy protokolu: Strana, která odesílá zprávu SOAP, se nazývá odesílatel SOAP a strana, která 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. Trasa zprávy obsahuje původního odesílatele, konečného příjemce a 0 nebo více prostředníků SOAP. Objekty, které zpracovávají zprávy podle pravidel určité protokoly SOAP se nazývají SOAP uzly. Elementární jednotka informací, která se účastní výměny mezi SOAP uzly, se nazývá zpráva SOAP – jedná se o XML dokument s kořenovým prvkem SOAP wrapper.

Jak bylo uvedeno v předchozí kapitole, webové služby komunikují s klienty a mezi sebou navzájem prostřednictvím zasílání zpráv v XML. Značky pro toto XML implementace, pravidla pro formátování dokumentu XML a pořadí výměny dokumentů definuje protokol SOAP. protokol SOAP vytvořený v roce 1998 týmem vývojářů vedeným Davem Winerem, který pracoval ve společnostech Microsoft Corporation 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 jakoukoli interakci mezi webovými službami a součástmi 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 ponechat předchozí zkratku. Aby se tyto pokusy zastavily, specifikace SOAP 1.2 uvádí, že slovo „SOAP“ již nebude žádným způsobem hláskováno.

Koncem 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 identifikátor jmenného prostoru http://schemas.xmlsoap.org/soap/envelope/.

Druhý návrh SOAP 1.2 byl vydán v roce 2001, jeho jmenný prostor se v té době jmenoval 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 toto píšu, SOAP 1.1 zůstává funkční. 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 načrtnu verzi 1.2 a upozorním na její odlišnosti 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ší možnost Koncept verze se v době psaní tohoto článku nacházel na http://www.w3.org/TR/soapl2-partl/ a jmenný prostor, který používal, se jmenoval http://www.w3.org/2002/06/soap -obálka. Všimněte si, že specifikace SOAP 12 se skládá ze dvou částí: části 1 a části 2. Druhá část specifikace - aplikace - obsahuje pravidla pro záznam komplexních datových typů. Specifikace má ještě jednu část, část O - příklady zpráv sestavených podle pravidel SOAP 1.2.

Struktura zprávy SOAP

Specifikace definuje zprávu SOAP jako dokument XML, který neobsahuje deklaraci typu dokumentu nebo instrukce pro zpracování. Kořenový prvek tohoto dokumentu XML se nazývá . Prvek může mít atributy, které definují jmenné prostory,

a další atributy opatřené předponami. Kořenový prvek obsahuje jeden volitelný prvek obsahující hlavičku zprávy a jeden povinný prvek , ve kterém je zaznamenán obsah zprávy. Verze 1.1 povolena po těle aby bylo možné zapsat libovolné prvky, musely být jejich názvy opatřeny předponou. Verze 1.2 zakazuje psát cokoli za prvek . zkrátka obecná struktura Zpráva SOAP je:

xmlns:env="http://www.w3.org/2002/06/soap-envelope">

< ! - Блоки заголовка ->

Živel

, pokud je ve zprávě, je zapsán jako první v těle prvku . Kromě atributů xmlns může obsahovat atribut aktéra, který označuje adresu URI konkrétního serveru SOAP, kterému je zpráva určena.

Faktem je, že zpráva SOAP může projít několika servery SOAP nebo několika aplikacemi na stejném serveru. Tyto aplikace předzpracovávají bloky hlaviček zpráv a přenášejí je mezi sebou. 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ů. Pro tento účel jsou vyvíjeny další protokoly, například Microsoft WS-Routing.

Atribut aktér určuje cílový uzel SOAP – ten, který se nachází na konci řetězce a zpracuje celou hlavičku. Význam

Atribut actor označuje, že hlavička bude zpracována prvním serverem, který ji přijme. Atribut actor se může objevit v samostatných blocích hlavičky, což označuje uzel, který tento 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 aktuálně 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 by neměl 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 enter mezilehlý server, který ověřuje digitální podpis a definuje 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í hodnota pro tento atribut 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

, nazvaný urnstUnderstand, nabývá hodnot ​​o nebo 1. Jeho výchozí hodnota je o. Pokud je atribut mustunderstand roven 1, pak musí SOAP uzel při zpracování prvku vzít v úvahu jeho syntaxi definovanou ve schématu dokumentu, nebo zprávu vůbec nezpracovat. To zvyšuje přesnost zpracování zpráv.

Ve verzi 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í

Můžete vnořit libovolné prvky, dříve nazývané položky záhlaví. Ve verzi 1.2 se tyto bloky nazývají hlavičkové bloky. Jejich jména jsou nutně označena předponami. Bloky záhlaví mohou obsahovat roli nebo aktéra a atributy, kterým musí rozumět. Jejich akce se bude vztahovat pouze na tento blok. To umožňuje zpracování jednotlivých bloků hlaviček mezilehlými uzly SOAP, tedy těmi, jejichž role odpovídá roli určené atributem role. Výpis 3.1 ukazuje příklad takového bloku.

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 atributy role, herce a musí rozumět.

Živel musí být napsáno bezprostředně za prvkem

, pokud je ve zprávě, nebo nejprve ve zprávě SOAP, pokud chybí záhlaví. K prvku Můžete vnořit libovolné prvky, specifikace nijak nedefinuje jejich strukturu. Je však definován jeden prvek obsahující chybovou zprávu.

Chybová zpráva

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. s chybovou hláškou.

Ve zprávě napsané v těle prvku SOAP 1.1 je zvýrazněno následující:

Následující dílčí prvky popisují čtyři části.

Kód chyby - zpráva označující typ chyby. Je určen pro program, který zpracovává chyby.

Popis chyby - slovní popis druhu chyby určený osobě.

Umístění chyby - URI serveru, který zaznamenal chybu. Užitečné, když zpráva prochází řetězcem uzlů SOAP k objasnění povahy chyby. Zprostředkující uzly SOAP jsou povinny zaznamenávat tento prvek; cílový server SOAP tak není vyžadován.

Podrobnosti o chybě - popsat chyby v těle zprávu, ale ne v jejím názvu. Pokud při zpracování těla nejsou nalezeny žádné chyby, pak tento prvek chybí.

Například:

xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">

env:Musíte porozumět Chyba SOAP musí rozumět

SOAP verze 1.2 změnil obsah prvku, jak je popsáno v

jmenný prostor http://www.w3.org/2002/06/soap-envelope, obsahuje dva povinné prvky a tři volitelné prvky.

Požadované prvky.

Kód chyby . Obsahuje požadovaný dílčí prvek<:value>s kódem chyby a volitelným dílčím prvkem , obsahující opět prvek s objasněním chybového kódu a prvku a pak se vše rekurzivně opakuje.

Důvod chyby . Obsahuje volitelné xml atribut: lang, udávající jazyk zprávy (viz kapitola D) a libovolný počet vnořených prvků popisujících chybu.

Volitelné prvky.

? - URI mezilehlého uzlu SOAP, který zaznamenal chybu.

? - role SOAP uzlu, který zaznamenal chybu.

? - popis chyby zaznamenané při zpracování těla zprávu, ale ne nadpis.

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ů procedury jsou ve zprávě SOAP zapsány nesprávně a procedura jim nerozumí.

Výpis 3.2. Chybová zpráva

xmlns:env="http://www.w3.org/2002/06/soap-envelope" xmlns:rpc=’http://www.w3.org/2002/06/soap-rpc’>

env:Sender

rpc:BadArgumentsc/env:Value>

Ptocessing ETror

xmlns:e="http://www.example.org/chyby"> #me neodpovídá 999

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 - jmenný prostor nebyl rozpoznán. Může být zastaralý nebo jeho název může být nesprávně napsán.

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 zpracovat správně zaznamenanou zprávu podle svého vnitřní důvody.

Verze 1.2 definuje pět typů chyb.

VersionMismatch - jmenný prostor nebyl rozpoznán. Možná je zastaralý, jeho název je napsán špatně nebo je ve zprávě jméno XML prvek, není v tomto jmenném prostoru definován. Server zapíše prvek do hlavičky odpovědi , výčet vnořených prvků správná jména jmenné prostory, kterým server rozumí. Odpověď serveru je uvedena ve výpisu 3.3.

MustUnderstand – Blok záhlaví označený atributem mustunderstand nastaveným na hodnotu true neodpovídá své syntaxi definované ve schématu dokumentu. Server zapíše do hlavičky odpovědi následující prvky: , jehož atribut qname obsahuje název nesprávného bloku. Výpis 3.4 obsahuje příklad odpovědi, kterou by server provedl, kdyby záhlaví ve Výpisu 3.1 bylo napsáno chybně.

DataEncodingUnknown - zpráva obsahovala nesrozumitelná data, možná byla napsána 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. Obvykle

detailují standardní typy a zprávy o nich se objeví v prvcích , jak je uvedeno výše ve výpisu 3.2.

? Výpis 3.3. Odpověď serveru s chybovou zprávou, jako je 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/"/>

env:VersionMismatch

Neshoda verzí

ListongZ.4. Odpověď serveru s chybovou zprávou, jako je MustUnderstand

xmlns:t=’http://some.com/transaction’ />

env:Musíte porozumět

Jedno nebo více povinných záhlaví není pochopeno

Literatura:

Khabibullin I. Sh pomocí Javy. - Petrohrad: BHV-Petersburg, 2003. - 400 s.: ill.

Co je SOAP?

SOAP je zkratka pro Simple Object Access Protocol. Doufám, že po přečtení článku se budete jen ptát: "Co je to za zvláštní jméno?"

SOAP ve své současné podobě je metoda vzdáleného volání procedur (RPC) přes síť. (Ano, používá se také k přenosu dokumentů jako XML, ale to zatím vynecháme.)

Pojďme na to přijít. Představte si, že máte službu, která vrací nabídku akcií pro daný ticker (symbol akcií). Odešle data na web Nasdaq a vygeneruje je na základě vráceného HTML požadovaný výsledek. Dále, abyste umožnili ostatním vývojářům používat je ve svých aplikacích, vytvoříte z této služby komponentu, která vyhledá informace o nabídkách prostřednictvím internetu. Funguje skvěle, dokud jednoho dne Nasdaq nezmění rozložení svých stránek. Musíte přehodnotit celou logiku komponenty a odeslat aktualizace všem vývojářům, kteří ji používají. A oni zase potřebují posílat aktualizace všem svým uživatelům. Pokud se to stane víceméně neustále, můžete si mezi svými kolegy vývojáři udělat spoustu nepřátel. A s programátory, jak víte, si není radno zahrávat. Nechcete zítra vyndat fotku své oblíbené kočky z kancelářského drtiče, že ne?

co dělat? Podívejme se... vše, co potřebujete, je poskytnout jednu funkci, která bude mít ticker jako vstup ( zadejte řetězec) a vrátit nabídku akcií (plovoucí nebo dvojitého typu). Nebylo by tedy jednodušší nechat své vývojáře, aby tuto funkci nějak zavolali přes internet? Velký! Novinkou pro mě jsou také COM a Corba a Java, které to dělají léta... což je pravda, je to pravda, ale tyto metody nejsou bez chyb. Vzdálený Nastavení COM ne triviální. Navíc je potřeba otevřít tolik portů ve firewallu, že správce systému Nemůžeš mít dost piva. Ano, a budete muset zapomenout na uživatele všech operačních systémů kromě Windows. O výměnu se ale občas zajímají i uživatelé Linuxu.

I když to vypadá, že pro uživatele Linuxu není vše ztraceno, pokud používají DCOM, více zde: http://www.idevresource.com/com/library/res/articles/comonlinux.asp.

O Corbě a Javě toho moc říct nemůžu, takže jako cvičení zvu čtenáře, aby našli nevýhody těchto přístupů.

SOAP je standard, který umožňuje popsat takové vzdálené volání a formu, jakou bude výsledek vrácen. Musíte tedy hostovat svou funkci v aplikaci přístupné přes síť a přijímat volání jako pakety SOAP. Poté ověříte vstup, spustíte funkci a vrátíte výsledek v novém paketu SOAP. Celý proces může běžet přes HTTP, takže na firewallu nemusíte otevírat spoustu portů. Je to opravdu jednoduché?

O čem je tento článek?

Toto je první ze série článků, které o SOAP v Agni Software píšeme. V tomto článku se vám pokusím poskytnout představu o tom, co je SOAP a jak napsat aplikaci, která komunikuje se serverem SOAP.

Mýdlo a XML

Pokud se vám SOAP stále zdá jednoduchý, přidejte XML. Nyní místo názvu funkce a parametrů dostáváme poměrně složitou obálku XML, jako by vás měla zmást. Ale nespěchejte, abyste se báli. Je toho víc a musíte vidět celý obrázek, abyste ocenili komplexnost SOAP.
Pokud nevíte, co je XML, přečtěte si nejprve můj článek o XML zde: http://www.agnisoft.com/white_papers/xml_delphi.asp.

Všechny balíčky SOAP jsou ve formátu XML. co to znamená? Podívejme se. Podívejte se na tuto funkci (Pascal):
function GetStockQuote(Symbol: string) : double; Vypadá to skvěle, ale problém je v tom, že je to Pascal. K čemu je tohle? jednoduchá definice
pro vývojáře v Javě? Nebo pro někoho, kdo pracuje s VB? Potřebujeme něco, co bude srozumitelné všem, dokonce i programátorům VB. Dejte jim tedy XML obsahující stejné informace (parametry, hodnoty cen akcií atd.). Vytvoříte balíček SOAP, který je v podstatě voláním vaší funkce, zabalený do XML, aby mu rozuměla jakákoli aplikace na jakékoli platformě. Nyní se podívejme, jak vypadá naše volání SOAP:
xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"

xmlns:xsd="http://www.w3.org/1999/XMLSchema">


IBM

Informativní, že? SOAP je před našima očima stále jednodušší. Dobře, vtipy stranou. Nyní se vám pokusím vysvětlit, jak tomuto volání SOAP rozumět.

Dekódování značek První značka, která vás zaujme, je . Tato značka je vnější plášť

Balíček SOAP obsahující několik deklarací jmenného prostoru, které nás nijak zvlášť nezajímají, ale jsou velmi důležité pro jakýkoli programovací jazyk nebo parser. Jmenné prostory jsou definovány tak, aby zajistily, že analyzátor porozumí následujícím prefixům, jako je "SOAP-ENV:" nebo "xsd:". Další značka – . Není to v tomto konkrétním příkladu, ale pokud si o tom chcete přečíst více, podívejte se na specifikaci SOAP zde: http://www.w3.org/TR/SOAP/). Štítek ve skutečnosti obsahuje volání SOAP.

Další značka v seznamu je . Název značky, GetStockQuote, je volaná funkce. V terminologii SOAP se tomu říká operace. GetStockQuote je tedy operace, kterou je třeba provést. ns1 je v našem případě jmenný prostor ukazující na urn:xmethods-quotes.

Poznámka ke jmenným prostorům: Jmenný prostor umožňuje kvalifikovat značku XML. Je nemožné mít například dvě proměnné se stejným názvem v jedné proceduře, ale pokud jsou ve dvou různé postupy, nejsou žádné problémy. Procedura je tedy jmenný prostor, protože všechna jména v něm jsou jedinečná. Stejně tak značky XML mají svůj rozsah v rámci jmenných prostorů, takže daný jmenný prostor a název značky je můžete jednoznačně identifikovat. Definujeme jmenný prostor jako URI, abychom odlišili náš NS1 od napodobenin. Ve výše uvedeném příkladu je NS1 alias ukazující na urn:xmethods-quotes.

Věnujte pozornost také atributu encodingStyle – tento atribut určuje způsob serializace volání SOAP.

Uvnitř štítku obsahuje parametry. V našem nejjednodušším případě máme pouze jeden parametr – tag . Všimněte si tohoto řádku vedle značky:
xsi:type="xsd:string"
Zhruba takto jsou typy definovány v XML. (Všimněte si, jak chytře jsem použil slovo „přibližně“, když jsem zobecnil technologii, která se může po zveřejnění článku změnit.) Co to přesně znamená: typ definovaný ve jmenném prostoru xsi, kterého si všimnete, je definován v tagu – xsd:string. A to je zase řetězec, definovaný ve jmenném prostoru xsd, opět definovaný dříve. (Jsem si jistý, že právníci by z toho všeho byli nadšeni).

Uvnitř štítku Je uvedeno "IBM". Toto je hodnota parametru symbol funkce GetStockQuote.

No a nakonec jsme jako slušní lidé uzavřeli všechny štítky.

Takže jsme přišli na paket SOAP, který definuje volání na server SOAP. SOAP server s pomocí XML analyzátory, červené tlačítko a vesmírná stanice MIR dekódují toto volání a určí, že potřebujete cenu akcií. Okamžitě najde správnou nabídku a vrátí vám ji v této podobě:
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>


34.5


Po rozbalení SOAP obálky, strhnutí stuh a zašustění obalu se dozvídáme, že cena akcií IBM je 34,5.

Většina komerčních serverů by hodně vrátila více informací, například v jaké měně a za jakou cenu byla nakoupena poslední akcie. A cena akcií by možná byla přesnější.

Tímto způsobem víme, co SOAP server očekává a co vrátí. JAK tedy tyto informace posíláte? Můžete použít jakoukoli dopravu. Nejvíce pokrytý je HTTP. Nebudu zabíhat do podrobností o HTTP, pro ty, kteří nevědí, je to to, co váš prohlížeč používá ke komunikaci s weby, které navštěvujete.

Požadovaný HTTP požadavek bude vypadat nějak takto:
POST /StockQuote HTTP/1.1
Hostitel: www.stockquoteserver.com

Obsah-délka: nnnn
SOAPAction: "Some-URI"

Paket žádosti o mýdlo zde... Jediná další věc, která stojí za zmínku, je hlavička SOAPAction. Tato hlavička označuje účel požadavku a je povinná. Každý SOAP server může mít neomezené množství funkce a může použít hlavičku SOAPAction k určení, která funkce je volána. Firewally a multiplexery mohou také filtrovat obsah na základě této hlavičky.

Odpověď SOAP od HTTP servery bude vypadat takto:
HTTP/1.1 200 OK
Content-Type: text/xml; charset="utf-8"
Obsah-délka: nnnn

Zde paket odpovědi Soap... Proč HTTP? Za prvé, správci sítě nemusíte otevírat mnoho samostatných portů pro volání SOAP... webový server může snadno zpracovávat volání, protože Port 80 je obvykle otevřen všem pro příjem příchozích požadavků. Další výhodou je rozšiřitelnost webových serverů pomocí CGI, ISAPI a dalších nativních modulů. Tato rozšiřitelnost vám umožňuje napsat modul, který zpracovává požadavky SOAP bez ovlivnění dalšího webového obsahu.

To je vše

Doufám, že tento článek pomohl osvětlit SOAP. Pokud jste stále zde a chcete si přečíst více na toto téma, navštivte web autorů: http://www.agnisoft.com/soap

Vlastně dnes existuje standardní protokoly Výměna dat XML:

• XML-RPC– předáte balíček a uvedete, kterou metodu na serveru chcete volat.
• ODPOČINEK- na serveru jsou nějaké objekty. Každý objekt je charakterizován určitým druhem identifikátoru. Každý prvek má svou vlastní adresu URL. S libovolným prvkem můžete provádět následující akce: vložit, odstranit, aktualizovat, vybrat. Jednoduše pošlete požadovaný požadavek na server (například vložíte takový a takový prvek). Výměna klient-server je založena buď na JSON nebo XML.

SOAP (architektura orientovaná na služby, sada volně propojených služeb, které se vzájemně ovlivňují) je založena na RPC. Hlavní výhodou RPC je malý počet síťových zdrojů (vstupních bodů) a mnoho použitých metod. Navzdory této výhodě je RPC zastaralý protokol, který má řadu nevýhod:

• Platnost zprávy XML-RPC nelze ověřit. Starý protokol, byl vytvořen předtím, než byla schémata (jak ověřovat data) standardizována v XML. Tito. Server přijímá požadavky, musí zajistit, že požadavky jsou pro něj a že data jsou konzistentní. V XML-RPC jsou k tomu deklarovány datové typy, ale jedná se o kontrolu datového typu a nekontroluje se konzistence dat (že jste obdrželi strukturu se všemi potřebnými parametry).
• Nelze vytvářet kombinované zprávy.
• Nelze použít prostor a čas (objevilo se po vytvoření RPC).
• Zprávu nelze rozbalit, tzn. přidat další informace.

Všechny tyto nedostatky byly vyřešeny v XML Schema. Toto je průmyslový standard XML popisy dokument. Tito. je to způsob, jak modelovat libovolná data. XML schémata a umí popsat model (vztahy mezi prvky a atributy a jejich strukturu), datové typy (charakterizuje datové typy) a slovní zásobu (názvy prvků a atributů).

Na základě všech nedostatků XML-RPC byl vytvořen protokol SOAP.

MÝDLO(Simle Object Access Protocol) - přístupový protokol k objektu (do vstupního bodu). Dnes je to hlavní průmyslový standard pro vytváření distribuovaných aplikací.

Představuje rozšíření jazyka XML-RPC. Tito. je postaven na principu: 1 vstupní bod a libovolné metody. Samotný protokol z hlediska transportu (jak přenášet data) dává široký výběr: SMTP, FTP, HTTP, MSMQ.

SOAP je základem implementace webových služeb XML (webové služby XML). Nevýhodou SOAP je, že je obtížné se ho naučit.

SOAP je založen na výměně zpráv mezi klientem a serverem (synchronně a asynchronně). Každá zpráva nese informaci o datech (jaká data jsou přenášena a přijímána). SOAP předem popisuje celou strukturu zprávy pomocí schémat XML: co by ve zprávě mělo být, jak se bude přenášet. To umožňuje, aniž byste znali server, porozumět tomu, co se tam děje, a umožňuje serveru zkontrolovat, zda je tato zpráva určena pro něj.

XML schéma

Účelem schématu je popsat strukturu dat, tzn. co máme. Všechna data jsou rozdělena na jednoduché a komplexní typy(skaláry a struktury). Jednoduchý typ (řetězec, číslo, boolean, datum) nebude uvnitř nikdy nic obsahovat. A struktura (objekt) může obsahovat vlastnosti.

Základní operace SOAP

• Nejen jednoduchá výměna informací klient-server. Ale také automatické rozpoznání server a vyhledejte tento server, tzn. klient nemusí o serveru nic vědět. Tito. klient nejprve vyhledá server, najde vhodné služby, pochopí, jaké existují metody, co server má, a zavolá jej.
• Server zveřejňuje své informace (umístění, jaké metody podporuje), aby klient tento server našel. Publikování probíhá v adresáři UDDI.

Struktura zprávy SOAP:

• SOAP Envelope – to zahrnuje celou zprávu. Skládá se z hlavičky a těla.
• Hlavička SOAP - další informace(například oprávnění).
• SOAP Body (tělo) – samotná zpráva.
• Chyba SOAP (chyba) je způsob přenosu chyby ze serveru na klienta.

WSDL

WSDL(Web Services Description Language) - jazyk pro popis webových služeb. Používá se v SOAP. Jedná se o druh dokumentu, který popisuje vše: jaké jmenné prostory byly použity, jaká datová schémata byla použita, jaké typy zpráv server očekává od klienta, jaké obálky patří k jaké metodě, jaké metody existují, na jakou adresu odeslat atd. . Ve skutečnosti je WSDL webová služba. Klientovi stačí prostudovat obsah tohoto dokumentu, o serveru již ví vše.

Každý server musí publikovat WSDL.

WSDL se skládá z bloků:

• Definice samotné služby, tzn. vstupní bod, je označen port.
• Formát metod. Vstupní bod je navázán na operace, tzn. jaké metody podporuje? Je uveden typ hovoru a způsob přenosu. Uvnitř každé metody je vysvětlení formy, ve které jsou data přenášena – ve formě SOAP.
• Metody vazby na zprávu.
• Popis samotných zpráv.