Simple Object Access Protocol (SOAP) - obecný popis. protokol SOAP. Základní pojmy. Struktura zprávy SOAP

Co je SOAP?

SOAP je zkratka pro Simple Přístup k objektu Protokol (Simple Object Access Protocol). Doufám, že po přečtení článku budete jen zmateni: "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ředávání 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í). Odesílá data na web Nasdaq a generuje na základě vráceného HTML kýžený výsledek. Dále, abyste umožnili ostatním vývojářům používat ji ve svých aplikacích, uděláte z této služby komponentu, která vyhledá informace o nabídkách prostřednictvím internetu. Funguje to skvěle, dokud jednoho dne Nasdaq nezmění rozložení svých stránek. Musíte zkontrolovat 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ě pravidelně, můžete si mezi svými kolegy vývojáři udělat spoustu nepřátel. A s programátory, jak víte, jsou vtipy špatné. Nechcete zítra dostat 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á vezme ticker (typu string) jako vstup a vrátí cenu akcií (typu float nebo double). Nebylo by tedy jednodušší nechat své vývojáře, aby tuto funkci nějak zavolali přes web? Skvělý! To je pro mě také novinka, existuje COM a Corba a Java, které to dělají léta ... co je pravda, je pravda, ale tyto metody nejsou bez chyb. dálkový Nastavení COM ne triviální. Navíc je potřeba otevřít tolik portů ve firewallu, že neušetříte dostatek piva pro správce systému. Ano, a musíte zapomenout na uživatele všech operačních systémů kromě Windows. Ale koneckonců i uživatelé Linuxu mají občas o výměnu zájem.

Pro uživatele Linuxu však 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í doporučuji čtenářům najít v těchto přístupech nevýhody.

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, která je dostupná přes síť, a přijímat volání ve formě paketů SOAP. Poté ověříte vstup, spustíte svou funkci a vrátíte výsledek v novém balíčku SOAP. Celý proces může běžet přes HTTP, takže nemusíte otevírat hromadu portů ve firewallu. je to jednoduché?

O čem je tento článek

Toto je první ze série článků o SOAP, které 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 zmátla. Ale nelekejte se. 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 pakety SOAP jsou ve formátu XML. Co to znamená? Uvidíme. Podívejte se na tuto funkci (Pascal):
function GetStockQuote(Symbol: string) : double; Vypadá skvěle, ale problém je v tom, že je to Pascal. K čemu je tato jednoduchá definice pro vývojáře v Javě? Nebo pro někoho, kdo pracuje s VB? Potřebujeme něco, čemu rozumí každý, dokonce i programátoři VB. Dejte jim tedy XML obsahující stejné informace (parametry, kurzy akcií atd.). Vytvoříte SOAP balíček, 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 se před našima očima zjednodušuje. Dobře, vtipy stranou. Nyní se vám pokusím vysvětlit, jak tomuto volání SOAP rozumět.

Dešifrování značek

První značka, která vás zaujme, je . Tato značka je vnějším obalem balíčku SOAP a obsahuje několik deklarací jmenného prostoru, které nás málo zajímají, ale jsou velmi důležité pro jakýkoli programovací jazyk nebo analyzátor. Jmenné prostory jsou definovány tak, že analyzátor akceptuje následující předpony, jako je "SOAP-ENV:" nebo "xsd:".

Další značka je . (Vynechali jsme značku, která zde není uvedena - . 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 funkce, kterou je třeba volat. Podle terminologie SOAP se tomu říká operace. GetStockQuote je tedy operace, která má být provedena. ns1 je v našem případě jmenný prostor ukazující na urn:xmethods-quotes.

Poznámka na okraj o jmenných prostorech: Jmenný prostor vám umožňuje kvalifikovat značku XML. Nemůžete mít například dvě proměnné se stejným názvem ve stejné proceduře, ale pokud jsou ve dvou různých procedurách, není problém. Procedura je tedy jmenný prostor, protože všechna jména v něm jsou jedinečná. Podobně jsou tagy XML vymezeny v rámci jmenných prostorů, takže daný jmenný prostor a název značky je lze jednoznačně identifikovat. Definujeme jmenný prostor jako URI, abychom odlišili náš NS1 od imitátorů. Ve výše uvedeném příkladu je NS1 alias ukazující na urn:xmethods-quotes.

Všimněte si 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 – značku . Všimněte si tohoto řádku vedle značky:
xsi:type="xsd:string"
Zhruba takto XML definuje typy. (Všimněte si, jak chytře jsem použil slovo „přibližně“, když zobecňuji o technologii, což 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, který byl opět definován 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 balíček SOAP, který definuje volání na server SOAP. A SOAP server pomocí analyzátorů XML, červeného tlačítka a vesmírné stanice MIR dekóduje toto volání a určí, že potřebujete cenovou nabídku. Okamžitě najde požadovanou 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 akcie IBM je 34,5.

Většina komerčních serverů by vrátila mnohem více informací, například v jaké měně a za jakou cenu byla poslední akcie koupena. 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? Lze použít jakýkoli transport. Nejosvětlenější je HTTP. Nebudu zabíhat do podrobností 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 by vypadal asi takto:
POST /StockQuote HTTP/1.1
Hostitel: www.stockquoteserver.com

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

Zde je paket žádosti o mýdlo... Jediná další věc, kterou je třeba poznamenat, je hlavička SOAPAction. Tato hlavička označuje účel požadavku a je povinná. Každý server SOAP může mít neomezený počet funkcí 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ě nemusejí otevírat mnoho samostatných portů pro volání SOAP... web server může hovory v klidu vyřizovat, 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 stránky autora: http://www.agnisoft.com/soap

Historie stvoření

S příchodem osobní počítače bylo také potřeba je kombinovat. Nejprve šlo o jednoduché kabelové připojení, pak se objevily síťové protokoly, které sjednotily počítače běžící na stejném OS, s rozvojem technologie nebylo potřeba mít jeden OS na všech počítačích a bylo možné kombinovat počítače běžící pod různými OS. Internet změnil rychlost pohybu na cestě sjednocení.

Ale ani dnes nejsou všechny integrační problémy vyřešeny, bohužel neexistoval jednotný protokol pro komunikaci mezi internetovými aplikacemi a službami. K vyřešení tohoto problému se společnosti jako Microsoft, DevelopMentor, UserLand Software, IBM a Lotus Development spojily a v důsledku jejich společných aktivit se (Simple Object Access Protocol) ukázal jako jednoduchý objektový přístupový protokol popisující vzdálený standard volání procedur založený na XML (Extensible Markup Language) - rozšiřitelný značkovací jazyk). SOAP je navržen tak, aby co nejvíce zjednodušil vývoj mezijazykových aplikací a nástrojů pro obchodní integraci. Začátek byl položen SOAP 1.0, který ke svému fungování vyžadoval protokol HTTP.

Poté, co se objevila počáteční verze SOAP, vytvořená, jak již bylo uvedeno, společným úsilím společností Microsoft, DevelopMentor a UserLand, IBM a Lotus se připojily k vývoji produktu. V důsledku toho specifikace prošla výrazným přepracováním a lépe se hodí pro integraci heterogenních prostředí. Hlavním rozdílem mezi další verzí SOAP 1.1 a původní verzí byl přechod od Microsoftu XML-Data na XML Schema. V nové verzi navíc specifikace přestala záviset na transportních protokolech. SOAP 1.0 vyžadoval pro fungování HTTP, zatímco SOAP 1.1 se nestaral o typ přenosu: můžete použít e-mailem nebo ukazatele na fronty zpráv (masážní odkazy). Společnosti, které již přijaly SOAP 1.0, zjistily, že jsou svázány s nestandardní technologií společnosti Microsoft. Řada slibných produktů této společnosti, včetně BizTalk Server a SQL Server 7.0, však také spoléhá na XML-Data. S příchodem verze 1.1 se okruh příznivců protokolu SOAP rozšiřuje

Počáteční SOAP 1.1 předložen Task Force technická podpora Internet IETF, byl založen na technologii XML-Data navržené společností Microsoft v lednu 1998. Nicméně v procesu zvažování standardů v konsorciu W3C základní struktura bylo nahrazeno schématem XML. World Wide Web Consortium bylo požádáno, aby zvážilo SOAP 1.1 jako potenciální standard.

Nejnovější verze specifikace SOAP (Simple Object Access Protocol) je k dispozici na webovém serveru obsluhujícím členy programu MSDN™ Developer Program (http://msdn.microsoft.com/). SOAP je otevřený protokol založený na standardech, který definuje společný formát založený na XML (Extensible Markup Language) pro komunikaci mezi libovolnými internetovými aplikacemi a službami. Tato verze rozšiřuje možnosti SOAP v asynchronní komunikaci o podporu nejen HTTP, ale také internetových protokolů, jako jsou SMTP, FTP a TCP/IP. Nejnovější verze specifikace SOAP získala širokou podporu společností jako ActiveState Tool Corp., Ariba Inc., BORN Information Services Inc., Commerce One Inc., Compaq Computer Corp., DevelopMentor Inc., Extensibility Inc., IBM, IONA Technologies PLC, Intel Corp., Lotus Development Corp., ObjectSpace Inc., Rogue Wave Software Inc., Scriptics Corp., Secret Labs AB, UserLand Software a Zveno Pty. Ltd. Specifikace SOAP poskytuje společný mechanismus pro integraci služeb přes internet a/nebo intranet, bez ohledu na základní operační systém, objektový model nebo programovací jazyk. Na základě internetových standardů XML a HTTP umožňuje protokol SOAP jakékoli nové resp stávající aplikace. Webové stránky, které podporují SOAP, se mohou stát webovými službami, ke kterým lze přistupovat čistě programově a nevyžadují lidský zásah. Jediná infrastruktura, která poskytuje přímou interakci mezi aplikacemi připojenými k internetu, otevírá nové možnosti pro integraci služeb a zařízení – bez ohledu na to, kde se na internetu nacházejí.

Webové služby a SOAP

Webové služby a SOAP jsou navrženy tak, aby řešily problémy interakce aplikací napříč platformami. Článek pomůže získat představu o těchto nových slibných technologiích.

Co je SOAP

V současnosti používané technologie vzdáleného volání metod (DCOM, CORBA/IIOP a RMI) jsou poměrně komplikované v nastavení a organizaci interakce. To s sebou nese problémy v provozu a fungování distribuovaných systémů (bezpečnostní problémy, přenos přes firewally atd.). Stávající problémy byly úspěšně vyřešeny vytvořením SOAP (Simple Object Access Protocol), jednoduchého protokolu založeného na XML pro zasílání zpráv v distribuovaných prostředích (WWW). Je určen pro vytváření webových služeb a volání metod na dálku. SOAP lze použít s řadou transportních protokolů, včetně HTTP, SMTP a tak dále.

Co jsou webové služby

Webové služby jsou funkce a data poskytovaná pro použití externími aplikacemi, které interagují se službami prostřednictvím standardních protokolů a datových formátů. Webové služby jsou zcela nezávislé na jazyku a implementační platformě. Technologie webových služeb je základním kamenem programový model Microsoft .NET Abych demonstroval sílu SOAP, použil jsem nedávno vydanou implementaci SOAP Toolkit od společnosti Microsoft verze 2.0. Je třeba poznamenat, že Současná verze Toolkit se výrazně liší od předchozího (Microsoft SOAP Toolkit pro vizuální studio 6.0) a ze SOAP Toolkit 2.0 beta.

Mechanismus interakce mezi klientem a serverem

Klientská aplikace vytvoří instanci objektu SOAPClient
SOAPClient čte soubory s popisem metod webových služeb (WSDL a Web Services Meta Language - WSML). Tyto soubory mohou být také uloženy na klientovi.
Klientská aplikace pomocí schopností pozdní vazby metod objektu SOAPClient volá metodu služby. SOAPClient vygeneruje paket požadavku (SOAP Envelope) a odešle jej na server. Je možné použít jakýkoli transportní protokol, ale obvykle se používá HTTP.
Balíček vezme aplikaci naslouchacího serveru (může to být aplikace ISAPI nebo stránka ASP), vytvoří objekt SOAPServer a předá mu paket požadavku.
SOAPServer čte popis webové služby, načítá popis a balíček požadavků do XML DOM stromů
SOAPServer vyvolá metodu na objektu/aplikaci, která implementuje službu
Výsledky provádění metody nebo popis chyby jsou převedeny objektem SOAPServer na paket odpovědi a odeslány klientovi
Objekt SOAPClient analyzuje přijatý paket a vrátí se klientská aplikace výsledky služby nebo popis chyby, ke které došlo.

Soubor WSDL je dokument XML, který popisuje metody poskytované webovou službou. Dále parametry metody, jejich typy, názvy a umístění Listeneru služby. Průvodce SOAP Toolkit automaticky vygeneruje tento dokument.

SOAP Envelope (Package) – XML dokument, který obsahuje požadavek/odpověď na provedení metody. Nejvhodnější je považovat jej za poštovní obálku, do které jsou vloženy informace. Značka Envelope musí být kořenovým prvkem balíčku. Element Header je volitelný a tělo musí být přítomno a být přímým potomkem elementu Envelope. V případě chyby při provádění metody server vygeneruje paket obsahující prvek Fault v tagu Body, který obsahuje podrobný popis chyby. Pokud používáte vysokoúrovňová rozhraní SOAPClient, SOAPServer, pak nemusíte zacházet do složitostí formátu balíčku, ale pokud chcete, můžete použít nízkoúrovňová rozhraní nebo dokonce vytvořit balíček "ručně" .

Objektový model SOAP Toolkit umožňuje pracovat s nízkoúrovňovými objekty API:

SoapConnector - Poskytuje transportní protokol pro výměnu paketů SOAP
SoapConnectorFactory – Poskytuje metodu pro vytvoření konektoru pro transportní protokol specifikovaný v souboru WSDL (tag)
SoapReader - čte zprávy SOAP a staví XML DOM stromy
SoapSerializer – obsahuje metody pro vytvoření zprávy SOAP
IsoapTypeMapper, SoapTypeMapperFactory – Rozhraní, která vám umožní pracovat s komplexními datovými typy

Pomocí objektů API na vysoké úrovni můžete přenášet data pouze jednoduchých typů (int, srting, float ...), ale specifikace SOAP 1.1 umožňuje pracovat se složitějšími datovými typy, jako jsou pole, struktury, seznamy a jejich kombinace. Chcete-li pracovat s takovými typy, musíte použít rozhraní IsoapTypeMapper a SoapTypeMapperFactory.

tutorial

Ahoj všichni!
Stalo se tak, že v Nedávno 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 vlastní popis webové služby (WSDL);
odeslat pole stejného typu dat na server klientem.

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:

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

Něco mi říká, že k tomu je nutné odeslat následující:

číslo mobilního telefonu a
Text SMS.

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

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

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

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:

PRAVDA - paket úspěšně dorazil na server, prošel ověřením a ve frontě pro odeslání poskytovateli SMS
NEPRAVDA – ve všech ostatních případech

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!

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.

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ým množstvím metod a složitým protokolem. 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ě žádné dohady nejsou?… 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í - jelikož 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ě to, co většinu z nás děsí ze samotného pokusu vzít a implementovat vlastní API na 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:

Jaké jmenné prostory byly použity,
Jaká datová schémata byla použita,
Jaké typy zpráv webová služba očekává od klientů,
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 klientské hovory zasílány.

Jak vidíte, tento soubor 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 je SOAP především metodou interakce mezi klientem a serverem a jako transportní prostředek se používá značkovací jazyk XML, v této části trochu pochopíme, jak probíhá automatická validace dat prostřednictvím schémat XML.

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:

čára,
číslo,
booleovský,
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é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.

Navrhuji nejít daleko a napsat schéma XML pro naši zprávu SMS! Níže je uveden xml popis sms zprávy:

71239876543 Testovací zpráva 2013-07-20T12:00:00 12
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!

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:

71239876543 Testovací zpráva 1 2013-07-20T12:00:00 12 71239876543 Testovací zpráva N 2013-07-20T12:00:00 12
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!

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!

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.

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, 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»:

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.

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:

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). Proto jsme zde uvedli, že provedeme volání RPC 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 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 ("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é.

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 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».

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!

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í server SOAP

Již dříve jsem psal, že k vytvoření SOAP serveru v PHP použijeme vestavěnou třídu SoapServer. Za všechno další akce stalo se to samé 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 umístit na váš webový server si nejlépe přečtěte na oficiálních stránkách PHP (viz reference).

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();
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.

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 výmluvným názvem " 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“:

"; ?> /" 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 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í:

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, 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.

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.
Pojďme to spustit a uvidíme, co jsme nakonec dostali!

Ze serveru jsem obdržel následující objekt:

Object(stdClass) public "status" => boolean true
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!

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:

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

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ž 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? Pravděpodobně nejjednodušším způsobem by bylo uspořádat pole uvnitř prvku messageList! Pojďme na to:

// 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 následující paket přišel od klienta:

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

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?“. Ale navrhuji, abychom nezoufali a pokusili se přené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 Pošli SMS 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ě, 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:

// 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;
Co když budeme mít štěstí a ze schématu 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! Vstoupil Pošli SMS 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á - "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:

můžete napsat potřebný soubor WSDL pro vaši webovou službu;
můžete si bez problémů napsat vlastního klienta, který dokáže komunikovat se serverem pomocí protokolu SOAP;
můžete napsat svůj vlastní server komunikace s vnějším světem prostřednictvím SOAP;
ze svého klienta můžete odeslat pole stejného typu objektů na server (s určitými omezeními).

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

nativní třída SoapClient neví, jak správně serializovat datové struktury stejného typu v XML;
při serializaci pole do XML, které vytváří extra prvek Se jménem Struktura;
při serializaci objektu do XML se vytvoří další prvek s názvem FALEŠNÝ;
FALEŠNÝ menší zlo než Struktura díky tomu, že obálka je kompaktnější (v XML hlavičce obálky se nepřidávají žádné 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).

Název tématu je opravdu otázka, protože Sám nevím, co to je a poprvé se s tím pokusím pracovat v rámci tohoto článku. Jediné, co mohu zaručit, je, že níže uvedený kód bude fungovat, nicméně mé fráze budou pouze domněnky a dohady o tom, jak tomu všemu sám rozumím. Tak pojďme...

Úvod

Musíme začít tím, k čemu byl koncept webových služeb vytvořen. V době, kdy se tento koncept objevil, již ve světě existovaly technologie, které umožňovaly interakci aplikací na dálku, kdy jeden program mohl zavolat nějakou metodu v jiném programu, kterou pak bylo možné spustit na počítači umístěném v jiném městě nebo dokonce zemi. To vše se označuje zkratkou RPC (Remote Procedure Calling - vzdálené volání procedur). Příklady zahrnují technologie CORBA a pro Javu - RMI (Remote Method Invoking - vzdálené vyvolání metody). A zdá se, že je v nich všechno dobré, zvláště v CORBA, protože můžete s ním pracovat v jakémkoli programovacím jazyce, ale stále tomu něco chybělo. Domnívám se, že nevýhodou CORBA je, že místo toho funguje prostřednictvím některých síťových protokolů prostý HTTP, který bude procházet jakýmkoli firewallem. Myšlenkou webové služby bylo vytvořit takové RPC, které by se vkládalo do HTTP paketů. Tak začal vývoj standardu. Jaké jsou základní pojmy tohoto standardu:

MÝDLO. Před voláním vzdálené procedury musíte toto volání popsat v souboru XML ve formátu SOAP. SOAP je jen jedním z mnoha XML značení, který se používá ve webových službách. Cokoli, co chceme někam poslat přes HTTP, se nejprve promění Popis XML SOAP je pak spojen do paketu HTTP a odeslán do jiného počítače v síti přes TCP/IP.
WSDL. Existuje webová služba, tzn. program, jehož metody lze volat na dálku. Norma ale vyžaduje, aby byl k tomuto programu připojen popis, který říká, že „ano, nemýlili jste se – toto je skutečně webová služba a můžete z ní volat takové a takové metody.“ Tento popis je reprezentován jiným souborem XML, který má jiný formát, a to WSDL. Tito. WSDL je pouze soubor XML popisující webovou službu a nic jiného.

Proč se ptáš tak krátce? Nemůžeš jít podrobněji? Pravděpodobně můžete, ale k tomu se budete muset obrátit na knihy, jako je Mashnin T. "Java Web Services". Tam je pro prvních 200 stránek podrobný popis každé značky standardů SOAP a WSDL. Stojí to za to? Podle mého názoru ne, protože to vše se v Javě vytváří automaticky a stačí napsat obsah metod, které mají být vzdáleně volány. Takže v Javě existuje takové API jako JAX-RPC. Pokud někdo neví, když se říká, že Java má takové a takové API, znamená to, že existuje balíček se sadou tříd, které zapouzdřují danou technologii. JAX-RPC se dlouhou dobu vyvíjel od verze k verzi a nakonec se vyvinul v JAX-WS. WS zjevně znamená WebService a možná si myslíte, že jde o jednoduché přejmenování RPC na populární módní slovo dnešní doby. Není tomu tak, protože nyní se webové služby vzdálily původní myšlence a umožňují nejen volání vzdálených metod, ale také jednoduché zasílání zpráv o dokumentech ve formátu SOAP. Proč je to potřeba, zatím nevím, je nepravděpodobné, že odpověď zde bude „pro případ, že je to náhle potřeba“. Sám bych se rád učil od zkušenějších soudruhů. A nakonec se objevil JAX-RS pro tzv. webové služby RESTful, ale to je téma na samostatný článek. Tento úvod lze dokončit, protože. dále se naučíme pracovat s JAX-WS.

Obecný přístup

Webové služby mají vždy klienta a server. Server je naše webová služba a někdy se nazývá koncový bod (například koncový bod, kam dosáhnou zprávy SOAP od klienta). Musíme provést následující:

Popište rozhraní naší webové služby
Implementujte toto rozhraní
Spusťte naši webovou službu
Napište klienta a vzdáleně zavolejte požadovanou metodu webové služby

Webovou službu můžete spustit různými způsoby: buď popište třídu hlavní metodou a spusťte webovou službu přímo jako server, nebo ji nasaďte na server, jako je Tomcat nebo jakýkoli jiný. V druhém případě my sami nespouštíme nový server a neotevíráme na počítači další port, ale jednoduše sdělíme kontejneru servletu Tomcat, že „napsali jsme sem třídy webových služeb, prosím publikujte je, aby naši webovou službu mohl používat každý, kdo vás kontaktuje.“ Bez ohledu na to, jak bude webová služba spuštěna, budeme mít stejného klienta.

Server

Spusťte IDEA a vytvořte nový projekt Vytvořit nový projekt. Zadejte název hellowebservice a stiskněte tlačítko další, poté tlačítko Dokončit. Ve složce src vytvořit balíček en.javarush.ws. V tomto balíčku vytvoříme rozhraní HelloWebService: package ru. javarush. ws; // jedná se o anotace, tzn. způsob, jak označit naše třídy a metody, // ve vztahu k technologii webových služeb import javax. jws. WebMethod; importovat javax. jws. webová služba; importovat javax. jws. mýdlo. SOAPBinding; // říkáme, že naše rozhraní bude fungovat jako webová služba@Webová služba // říkají, že webová služba bude použita k volání metod@SOAPBinding(style = SOAPBinding.Style.RPC) veřejné rozhraní HelloWebService( // řekněme, že tato metoda může být volána vzdáleně@WebMethod public String getHelloString(Název řetězce) ; ) V tomto kódu jsou třídy WebService a WebMethod tzv. anotacemi a nedělají nic jiného, než že označují naše rozhraní a jeho metodu jako webovou službu. Totéž platí pro třídu SOAPBinding. Jediný rozdíl je v tom, že SOAPBinding je anotace s parametry. V tomto případě je použit parametr style s hodnotou, která říká, že webová služba bude fungovat nikoli přes zprávy dokumentů, ale jako klasické RPC, tzn. zavolat metodu. Pojďme implementovat naši logiku rozhraní a vytvořit v našem balíčku třídu HelloWebServiceImpl. Mimochodem podotýkám, že třída končící na Impl je konvence v Javě, podle které se tak označuje implementace rozhraní (Impl - od slova implementace, tedy implementace). Toto není požadavek a můžete si třídu pojmenovat, jak chcete, ale dobré mravy to vyžadují: package ru. javarush. ws; // stejná anotace jako pro popis rozhraní, importovat javax. jws. webová služba; // ale zde se používá s parametrem endpointInterface, // ukazování celé jméno třída rozhraní naší webové služby@WebService(endpointInterface= "en.javarush.ws.HelloWebService") veřejná třída HelloWebServiceImpl implementuje službu HelloWebService ( @Override public String getHelloString (název řetězce) ( // stačí vrátit pozdrav return "Dobrý den, " + jméno + "!" ; ) ) Spusťte naši webovou službu jako samostatný server, tj. bez účasti jakéhokoli Tomcatu a aplikačních serverů (toto je téma na samostatnou diskusi). Chcete-li to provést, ve struktuře projektu ve složce src vytvoříme balíček ru.javarush.endpoint a v něm vytvoříme třídu HelloWebServicePublisher s metodou main: package ru. javarush. koncový bod; // třída pro spuštění webového serveru s webovými službami importovat javax. xml. ws. koncový bod; // třída naší webové služby import en. javarush. ws. hellowebserviceimpl; public class HelloWebServicePublisher( public static void main(String. . . args)( // spuštění webového serveru na portu 1986 // a na adrese uvedené v prvním argumentu, // spuštění webové služby předané ve druhém argumentu koncový bod. publikovat( "http://localhost:1986/wss/hello", nový HelloWebServiceImpl () ); ) ) Nyní spusťte tuto třídu kliknutím Shift+F10. V konzole se nic nezobrazí, ale server běží. Můžete to ověřit zadáním http://localhost:1986/wss/hello?wsdl do prohlížeče. Otevřená stránka na jedné straně dokazuje, že na našem počítači (localhostu) máme webový server (http://) běžící na portu 1986, a na druhé straně zobrazuje WSDL popis naší webové služby. Pokud aplikaci zastavíte, popis se stane nepřístupným, stejně jako samotná webová služba, takže to neuděláme, ale přejdeme k psaní klienta.

Klient

Ve složce projektu src vytvoříme balíček ru.javarush.client a v něm třídu HelloWebServiceClient s hlavní metodou: package ru. javarush. klient; // potřeboval získat popis wsdl a přes něj // dosažení samotné webové služby importovat java. síť. URL; // taková výjimka nastane při práci s objektem URL importovat java. síť. MalformedURLException; // třídy pro analýzu xml s popisem wsdl // a sáhněte po servisní značce v něm importovat javax. xml. jmenný prostor. Qname; importovat javax. xml. ws. servis; // rozhraní naší webové služby (potřebujeme další) import en. javarush. ws. hellowebservice; public class HelloWebServiceClient( public static void main(String args) vyvolá MalformedURLException( // vytvořit odkaz na popis wsdl URL url = nová URL( "http://localhost:1986/wss/hello?wsdl") ; // Podíváme se na parametry dalšího konstruktoru v úplně první WSDL popisné značce - definice // podívejte se na 1. argument v atributu targetNamespace // 2. argument hledá v atributu name QName qname = nový QName ("http://ws.site/" , "HelloWebServiceImplService" ) ; // Nyní můžeme dosáhnout servisní značky v popisu wsdl, Servisní služba= služba. vytvořit (url, qname) ; // a pak na značku portu vnořenou v něm, takže // získat odkaz na objekt webové služby vzdálený od nás HelloWebService hello = služba. getPort(HelloWebService.class) ; // Hurá! Nyní můžete volat vzdálená metoda Systém. ven. println(ahoj. getHelloString("JavaRush" ) ) ; ) ) Ve výpisu jsem dal maximálně komentáře ke kódu. Nemám co dodat, tak spusťte (Shift + F10). V konzoli bychom měli vidět text: Hello, JavaRush! Pokud jste to neviděli, pravděpodobně jste zapomněli spustit webovou službu.

Závěr

V tomto tématu byla představena krátká exkurze do webových služeb. Ještě jednou, hodně z toho, co jsem napsal, je můj odhad, jak to funguje, a proto by se mi nemělo příliš věřit. Byl bych vděčný, kdyby mě znalí lidé opravili, protože pak se něco naučím. UPD.

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í. SOAP byl původně určen především k implementaci vzdálené 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 ve formátu XML, a nikoli pouze k 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í 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 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.

· Ačkoli je SOAP 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.

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 – je XML dokument s obalem SOAP na kořenovém prvku.