Co jsou WSDL, SOAP a REST? protokol SOAP. Základní pojmy. Struktura zpráv SOAP

10 odpovědí

WSDL je dokument XML, který popisuje webovou službu. Ve skutečnosti je to zkratka pro Web Services Definition Language.

SOAP je protokol založený na XML, který umožňuje výměnu informací mezi aplikacemi přes specifický protokol (jako je HTTP nebo SMTP). Je to zkratka pro Simple Object Access Protocol a používá XML pro svůj formát zpráv k přenosu informací.

REST je architektonický styl pro síťové systémy a znamená přenos reprezentativního stavu. Není to standard sám o sobě, ale používá standardy jako HTTP, URL, XML atd.

Pokaždé, když někdo zmíní SOAP/WSDL, myslím na objekty a třídy definované v xml...

"SOAP používáte stejně jako každá třída PHP. V tomto případě však třída neexistuje v lokálním souborovém systému aplikace, ale na vzdáleném hostiteli, ke kterému se přistupuje přes http."... "Pokud uvažujeme o použití SOAP- služba jako další třída PHP, pak dokument WSDL je seznam všech dostupných metod a vlastností třídy."

A kdykoli někdo mluví o REST, myslím na HTTP příkazy (metody požadavku) jako POST, GET a DELETE

Příklad: jednoduše řečeno, pokud máte webovou službu kalkulačky.

WSDL: WSDL hovoří o funkcích, které můžete implementovat nebo zpřístupnit klientovi. Například: sčítání, mazání, odečítání atd.

SOAP: Kde pomocí SOAP skutečně provádíte akce jako doDelete(), doSubtract(), doAdd(). SOAP a WSDL jsou tedy jablka a pomeranče. Neměli bychom je srovnávat. Oba mají své vlastní funkce.

Proč používáme SOAP a WSDL: K výměně nezávislých dat napříč platformou.

EDIT: V běžném každodenním životě:

WSDL: Když jdeme do restaurace, vidíme položky menu, toto je WSDL.

Proxy třídy: Nyní, když se podíváme na položky nabídky, složíme svou mysl (zpracujeme svůj pohled na objednávku): Takže v podstatě vytváříme třídy Proxy založené na dokumentu WSDL.

MÝDLO: Když si potom objednáváme jídlo na základě menu: znamená to, že používáme proxy třídy k volání servisních metod, které se provádějí pomocí SOAP :).

SOAP → SOAP (Simple Object Access Prototype) je aplikační vrstva založená na protokolu navržená pro komunikaci mezi stroji. Protokol definuje standardní pravidla. Všechny strany, které používají určitý protokol, musí dodržovat pravidla protokolu. Stejně jako TCP se odvíjí na transportní vrstvě. Protokol SOAP bude chápán na aplikační úrovni (jakákoli aplikace, která podporuje SOAP - Axis2, .Net).

Zpráva WSDL -> SOAP se skládá z SoapEnevelope->SoapHeader a SoapBody. Nedefinuje, jaký bude formát zprávy? jaké všechny transporty (HTTP, JMS) jsou podporovány? bez těchto informací. Pro každého klienta, který chce použít konkrétní webovou službu, je obtížné vytvořit zprávu SOAP. I když ano, nebudou mít jistotu, že to bude fungovat pořád. WSDL je zachránce. WSDL (Web Services Description Language) definuje operace, formáty zpráv a přenosová data pro zprávu SOAP.

REST → REST (Representation State Transfer) je založen na dopravě. Na rozdíl od SOAP, které je zaměřeno na akce, je REST více orientovaný na zdroje. REST najde zdroje pomocí adresy URL (příklad -http://(adresa serveru)/zaměstnanci/číslo zaměstnance/12345) a závisí na transportním protokolu (s HTTP-GET, POST, PUT, DELETE,...) pro akce k provádění zdrojů . Služba REST najde zdroj na základě adresy URL a provede akci na základě slovesa transportní akce. Jde spíše o architektonický styl a konvence.

SOAP je zkratka pro Simple (sic) Object Access Protocol. Jeho cílem bylo provádět vzdálená volání procedur vzdáleným objektům odesláním XML přes HTTP.

WSDL je jazyk pro popis webových služeb. Požadavek končící koncovým bodem ".wsdl" bude mít za následek předložení zprávy XML, která popisuje požadavek a odpověď, jejíž použití lze očekávat. Popisuje smlouvu mezi službou a klientem.

REST používá HTTP k odesílání zpráv službám.

SOAP je specifikace, REST je styl.

Nebudete "jen" rozumět něčemu složitému.

WSDL je jazyk založený na XML pro popis webové služby. Popisuje zprávy, operace a informace o transportní síti používané službou. Tyto webové služby obvykle používají SOAP, ale mohou používat i jiné protokoly.

WSDL je čitelný programem a lze jej tedy použít ke generování celého kódu klienta nebo jeho části potřebného k volání webové služby. To znamená nazývat webové služby orientované na SOAP „sebepopisující“.

REST s WSDL vůbec nesouvisí.

Wikipedia říká: "Web Services Description Language je jazyk založený na XML, který poskytuje model pro popis webových služeb." Jinými slovy, WSDL odkazuje na webovou službu jako javadoc na java knihovnu.

Nicméně, velmi pěkné na WSDL je, že software může generovat klienta a server pomocí WSDL.

Brett McLaughlin Překlad Ilya Chekmenev

SOAP je protokol Simple Object Access Protocol. Pokud jste o tom nikdy předtím neslyšeli, musíte žít uprostřed ničeho, daleko od civilizace. Stala se nejnovější módou ve webovém programování a nedílnou součástí webových služeb, které se s takovým fanatismem používají při vývoji webu nejnovější generace. Pokud jste slyšeli o .NET nebo peer-to-peer „revoluci“, pak jste slyšeli o technologiích, které spoléhají na SOAP (i když nevíte, co to je). Není jeden, ale dva Implementace SOAP od společností Apache a Microsoft, které mají tisíce stránek na svém webu podpory MSDN (http://msdn.microsoft.com/).

V tomto článku vám řeknu, co je SOAP a proč je tak důležitou součástí vývoje paradigmatu webového programování. To vám pomůže přeskočit základy a rovnou se pustit do práce se sadou nástrojů SOAP. Poté poskytnu rychlý přehled stávajících projektů SOAP a ponořím se do implementace Apache. Účelem tohoto článku není poskytnout úplný obrázek o SOAP moje kniha Java & XML, 2. vydání, vyplňuje mnoho mezer. Odpovědi na mnohé otázky, které vyvstaly po přečtení tohoto článku, najdete v knize.

Zavedení

Nejprve musíte pochopit, co je SOAP. Celé (a poměrně dlouhé) stanovisko W3C si můžete přečíst na http://www.w3.org/TR/SOAP. Potom, když na to přijdete a zahodíte všechnu slupku, pochopíte, že SOAP je jen protokol. Je to jednoduchý protokol (pro jeho použití není třeba psát nový) založený na myšlence, že v určitém bodě distribuované architektury je potřeba vyměňovat si informace. Navíc pro systémy, ve kterých existuje možnost přetížení a potíží při zpracování procesů, je tento protokol velmi výhodný v tom, že je lehký a vyžaduje minimální množství zdrojů. Konečně umožňuje provádět všechny operace přes HTTP, což umožňuje obejít tak záludné věci, jako jsou firewally, a chránit se před nasloucháním pomocí soketů na neuvěřitelném počtu portů. Hlavní věc je, že si to uvědomujete a vše ostatní jsou detaily.

Tyto detaily byste samozřejmě rádi znali a já je nebudu ignorovat. Specifikace SOAP má tři základní součásti: obálka SOAP, sada pravidel šifrování a prostředek interakce mezi požadavkem a odpovědí. Představme si zprávu SOAP jako běžný dopis. Pamatujete si ještě ty prastaré věci v obálkách s poštovní známkou a adresou napsanou na přední straně? Tato analogie vám pomůže lépe porozumět konceptu SOAP jako „obálky“. Obrázek 12-1 znázorňuje procesy SOAP ve formě této analogie.

Obrázek 12-1. Proces zpráv SOAP

Mějte tento obrázek na paměti a podívejme se na tři součásti specifikace SOAP. Krátce pohovořím o každém z nich a uvedu příklady, které tento koncept nejlépe vystihují. Tyto tři klíčové komponenty činí SOAP tak důležitým a smysluplným. Zpracování chyb, podpora různých šifrování, serializace parametrů a skutečnost, že SOAP ve většině případů funguje přes HTTP, jej činí atraktivnějším než jiná řešení pro distribuované protokoly.

SOAP poskytuje vysoký stupeň interoperability s jinými aplikacemi, kterým jsem se podrobněji věnoval ve své knize. Prozatím se chci zaměřit na základní prvky SOAP.

Obálka SOAP je podobná běžné dopisní obálce. Obsahuje informace o zprávě, která bude zašifrována v hlavní sekci SOAP, včetně informací o příjemci a odesílateli a také informace o zprávě samotné. Záhlaví obálky SOAP může například indikovat, jak má být zpráva zpracována. Než aplikace začne zpracovávat zprávu, prozkoumá informace o zprávě, včetně toho, zda ji vůbec může zpracovat. Na rozdíl od situace u standardních volání XML-RPC (pamatujete? zprávy XML-RPC, šifrování atd. je vše sloučeno do jediného fragmentu XML), u SOAP dochází k průběžnému zpracování, abychom se o zprávě něco dozvěděli. Typická zpráva SOAP může také obsahovat styl šifrování, který příjemci pomůže při zpracování zprávy. Příklad 12-1 ukazuje obálku SOAP, která končí specifikací kódování.

Příklad 12-1: Obálka SOAP

Krabice na mýdlo http://www-106.ibm.com/developerworks/library/x-soapbx1.html

Jak vidíte, šifrování je nastaveno uvnitř obálky, což aplikaci umožňuje určit (pomocí hodnoty atributu styl kódování), zda dokáže přečíst příchozí zprávu umístěnou v prvku Tělo. Ujistěte se, že je jmenný prostor obálky SOAP správný, nebo servery SOAP, které obdrží vaši zprávu, ohlásí chybu nesouladu verzí a vy s nimi nebudete moci komunikovat.

Šifrování

Druhým důležitým prvkem SOAP je schopnost šifrovat vlastní datové typy. S RPC (a XML-RPC) lze šifrování provádět pouze na předdefinovaných typech dat, které jsou podporovány v sadě nástrojů XML-RPC, kterou jste si stáhli. Šifrování jiných typů dat vyžaduje, abyste sami upravili server RPC a klienta. Pomocí SOAP lze schéma XML poměrně snadno použít ke specifikaci nových datových typů (pomocí struktury komplexníTyp, o kterém pojednává kapitola 2 mé knihy) a tyto nové typy lze reprezentovat v XML jako součást hlavní části SOAP. Díky integraci schématu XML můžete zašifrovat jakýkoli typ dat ve zprávě SOAP jejich logickým popisem ve schématu XML.

Volání

Nejlepší způsob, jak pochopit, jak volání SOAP funguje, je porovnat jej s něčím, co znáte, jako je XML-RPC. Pokud si vzpomínáte, volání XML-RPC vypadá podobně jako fragment kódu uvedený v příkladu 12-2.

Příklad 12-2. Volání do XML-RPC

// Určení procesoru XML (analyzátoru) pro použití XmlRpc.setDriver("org.apache.xerces.parsers.SAXParser"); // Určení serveru, ke kterému je vytvořeno připojení XmlRpcClient client = new XmlRpcClient("http://rpc.middleearth.com"); // Vytváření parametrů Vector params = new Vector(); params.addElement(flightNumber); params.addElement(numSeats); params.addElement(creditCardType); params.addElement(creditCardNum); // Požadavek na booleovské kupované vstupenky = (Boolean)client.execute("ticketCounter.buyTickets", params); // Zpracujte odpověď

Vytvořil jsem jednoduchý program pro objednávání letenek. Nyní se podívejte na příklad 12-3, který demonstruje volání SOAP.

Příklad 12-3. Zavolejte na SOAP

// Vytváření parametrů Vector params = new Vector(); params.addElement(new Parameter("flightNumber", Integer.class, flightNumber, null)); params.addElement(new Parameter("numSeats", Integer.class, numSeats, null)); params.addElement(new Parameter("creditCardType", String.class, creditCardType, null)); params.addElement(new Parameter("číslo kreditníKarty", Long.class, číslo kreditníKarty, null)); // Vytvoření objektu Call Call call = new Call(); call.setTargetObjectURI("urn:xmltoday-letenky-letenky"); call.setMethodName("buyTickets"); call.setEncodingStyleURI(Constants.NS_URI_SOAP_ENC); call.setParams(params); // Odpověď na volání res = call.invoke(new URL("http://rpc.middleearth.com"), ""); // Zpracujte odpověď

Jak vidíte, skutečné volání reprezentované objektem Volání, paměťový rezident. Umožňuje vám zadat cíl volání, metodu volání, styl šifrování, parametry a mnoho dalších parametrů, které nejsou uvedeny v tomto příkladu. Jedná se o flexibilnější mechanismus než metoda XML-RPC a umožňuje vám explicitně specifikovat sadu různých parametrů, které jsou implicitně definovány v XML-RPC. Dále v tomto článku se dozvíte více o procesu volání, včetně toho, jak SOAP zpracovává neplatné požadavky, hierarchii chyb a samozřejmě vrácené výsledky volání.

Po tak krátkém úvodu už víte dost na to, abyste se o tuto vtipnou věc zajímali. Nyní mi dovolte představit vám implementaci SOAP, kterou budu používat. Vysvětlím důvody, proč jsem si to vybral, a podívám se na některé příklady kódu.

Nastavení

Nyní, když jste se naučili základy konceptu, je čas na zábavnou část: programování. K tomu budete potřebovat pohodlný projekt nebo produkt, který je snazší najít, než by se na první pohled mohlo zdát. Pokud potřebujete projekt Java, který poskytuje funkce SOAP, nemusíte dlouho hledat. Existují dvě skupiny produktů: komerční a bezplatné. Stejně jako ve své knize se vyhnu zmínkám o komerčních produktech. Není to vůbec proto, že by byly špatné (některé jsou naopak výborné), ale proto, že bych si přál, aby si každý čtenář mohl některý z uvedených příkladů vyzkoušet. To je způsobeno přístupností, kterou mnoho komerčních produktů nemá. Za jejich používání musíte zaplatit nebo je dočasně používat po omezenou dobu po stažení.

Hladce jsme tak přistoupili k open source projektům. Z této oblasti mohu jmenovat pouze jeden produkt: Apache SOAP. Nachází se na adrese http://xml.apache.org/soap a poskytuje sadu nástrojů SOAP pro Javu. V době psaní tohoto článku vyšla verze 2.2, kterou si můžete stáhnout ze stránek Apache. Právě tuto verzi použiji v příkladech pro tento článek.

Jiné alternativy

Než přejdu k instalaci a konfiguraci Apache SOAP, odpovím na několik otázek, které se vám mohly vloudit do mysli. Myslím, že jsem celkem jasně vysvětlil důvody, proč nepoužívám komerční produkty. Možná však přemýšlíte o nějakých dalších open source nebo souvisejících projektech, které byste mohli rádi používat, a divíte se, že jsem je nekomentoval.

A co IBM SOAP4J?

První na seznamu alternativ je implementace od IBM: SOAP4J. Práce IBM vytvořila základ projektu Apache SOAP, stejně jako IBM XML4J přerostlo v to, co je nyní známé jako projekt Apache Xerces XML parser. Předpokládá se, že implementace IBM bude přepracována, sloučením s Apache SOAP. Totéž se stalo s XML4J od IBM: nyní poskytuje pouze balení v Xercesu. To jen zdůrazňuje trendy - velcí výrobci často podporují a používají projekty OpenSource, v tomto případě oba projekty (Apache a IBM) používají stejnou základnu kódu.

Je Microsoft mimo hru?

Samozřejmě že ne. Microsoft a jeho implementace SOAP, stejně jako celé hnutí .NET (podrobněji rozebráno v mé knize), jsou poměrně významné. Opravdu jsem chtěl strávit většinu času podrobným zkoumáním implementace SOAP společnosti Microsoft, ale podporuje pouze objekty COM a nepodporuje Javu. Z těchto důvodů nemohl být takový popis obsažen v článku o Javě a XML. Microsoft však (navzdory všem výtkám, které jako vývojáři na tuto společnost máme) odvedl důležitou práci na poli webových služeb a uděláte chybu, když ji bez rozmyslu odmítnete, vedeni pouze syrovými emocemi. Pokud potřebujete pracovat s komponentami COM nebo Visual Basic, důrazně doporučuji zkusit použít sadu nástrojů Microsoft SOAP, která je k dispozici na adrese http://msdn.microsoft.com/library/default.asp?url=/nhp/Default .asp ?contentid=28000523 spolu s mnoha dalšími prostředky SOAP.

Co je Axis?

Ti z vás, kteří sledují aktivity Apache, určitě slyšeli o Apache Axis. Axis je sada nástrojů SOAP nové generace vyvinutá také pod záštitou Apache XML. SOAP (specifikace, nikoli konkrétní implementace), který se v poslední době rychle a radikálně rozvíjí, je velmi obtížné sledovat. Pokoušet se vytvořit verzi SOAP, která plně vyhovuje současným požadavkům, jak se vyvíjejí, je také docela náročné. Výsledkem je, že aktuální verze Apache SOAP nabízí řešení omezené svým designem. Když se vývojáři Apache rozhodli, že nemá cenu pokoušet se úplně předělat stávající nástroj, začali vytvářet projekt založený na novém kódu. Tak se zrodila Osa. Změnou prošel i název SOAP, nejprve ze SOAP na XP a poté na XMLP. Poté byl z názvu nového SOAP vypuštěn název specifikace a zrodil se název „Axis“. Nyní to ale vypadá, že se W3C vrací k názvu specifikace SOAP (verze 1.2 nebo 2.0), takže se věci mohou ještě změnit a bude ještě větší zmatek!

Představte si IBM SOAP4J jako architekturu?1 sady nástrojů SOAP. A co Apache SOAP (diskutované v tomto článku) jako architektura?2. A Axis představuje architekturu ?3, architekturu nové generace. Tento projekt používá SAX, zatímco Apache SOAP je založen na DOM. Navíc Axis, na rozdíl od Apache SOAP, poskytuje uživatelsky přívětivější přístup k uživatelské interakci. Po výčtu těchto výhod se možná divíte, proč jsem si jako předmět studia nezvolil Axis. Jen by to bylo trochu předčasné. V současné době se připravuje vydání pouze verze 0.51 Axis. Toto ještě není beta, ani alfa verze. Rád bych mluvil o nových funkcích Axis, ale neměli byste šanci přesvědčit své vedení, že můžete použít sub-alfa open source software pro vaše kritické systémové potřeby. Tak jsem se rozhodl zaměřit se na něco, čím jsi skutečný můžete použít již Dnes- Apache SOAP. Myslím, že než bude vydána konečná verze Apache Axis, aktualizuji tento materiál v příštím vydání mé knihy. Do té doby se zaměřme na řešení, které je již k dispozici.

Instalace

Existují dvě možné formy instalace SOAP. První je spuštění klienta SOAP pomocí rozhraní SOAP API ke komunikaci se serverem, který může přijímat zprávy SOAP. Druhým způsobem je spuštění serveru SOAP, který může přijímat zprávy od klienta SOAP. V této části jsem popsal oba postupy.

Klient

Chcete-li používat klienta SOAP, musíte si nejprve stáhnout Apache SOAP, který je k dispozici na http://xml.apache.org/dist/soap. Stáhl jsem si verzi 2.2 v binárním formátu (z podadresáře verze-2.2). Poté musíte obsah archivu rozbalit do adresáře v počítači. V mém případě to byl adresář javaxml2 (c:\javaxml2 na mém počítači se systémem Windows /javaxml2 na mém počítači Mac OS X). V důsledku toho byly soubory rozbaleny /javaxml2/soap-2_2. Budete si také muset stáhnout balíček JavaMail dostupný od Sun http://java.sun.com/products/javamail/. Bude vyžadována podpora přenosového protokolu SMTP používaného Apache SOAP. Poté si stáhněte Java Beans Activation Framework (JAF), která je také dostupná od Sun http://java.sun.com/products/beans/glasgow/jaf.html. Na základě předpokladu, že již máte nainstalovaný a připravený k použití Xerces nebo jiný analyzátor XML.

Poznámka: Ujistěte se, že váš analyzátor XML je kompatibilní s JAXP a správně používá jmenný prostor. Váš analyzátor tyto požadavky s největší pravděpodobností splňuje. Pokud máte problémy, je nejlepší vrátit se k používání Xerces.

Poznámka: Používejte nejnovější verze Xerces. Bude stačit verze 1.4 a vyšší. SOAP a Xerces 1.3(.1) mají řadu chyb, takže tuto kombinaci nedoporučuji používat.

Rozbalte balíčky JavaMail a JAF a poté zahrňte jejich soubory jar do vaší třídy a také do knihovny mýdlo.nádoba. Každý z těchto souborů jar musí být umístěn buď v kořenovém adresáři odpovídajícího programu, nebo v podadresáři /lib. Po dokončení vaší proměnné třídní cesta by měl vypadat nějak takto:

$ echo $CLASSPATH /javaxml2/soap-2_2/lib/soap.jar:/javaxml2/lib/xerces.jar: /javaxml2/javamail-1.2/mail.jar:/javaxml2/jaf-1.0.1/activation.jar

Pro Windows to bude vypadat takto:

c:\>echo %CLASSPATH% c:\javaxml2\soap-2_2\lib\soap.jar;c:\javaxml2\lib\xerces.jar; c:\javaxml2\javamail-1.2\mail.jar;c:\javaxml2\jaf-1.0.1\activation.jar

A nakonec přidejte adresář javaxml2/soap-2_2/ k vašemu třídní cesta spustit příklady SOAP. Nastavení jsem popsal na několika příkladech v této kapitole.

Server

Chcete-li vytvořit sadu serverových komponent kompatibilní s SOAP, potřebujete nejprve jádro servletů. Stejně jako v předchozích kapitolách jsem jako příklad pro tuto kapitolu použil Apache Tomcat (dostupný na http://jakarta.apache.org/). Budete muset přidat vše, co klient potřebuje třídní cesta server. Nejjednodušší způsob, jak to udělat, je resetovat mýdlo.nádoba, aktivace.jar A mail.jar, stejně jako váš analyzátor, do adresáře knihoven vašeho servletového stroje. Pro Tomcat je to adresář /lib, který obsahuje knihovny pro automatické načítání. Pokud chcete poskytovat podporu pro skripty (které nejsou probírány v této kapitole, ale jsou v příkladech Apache SOAP), musíte zadat bsf.jar(dostupné na http://oss.software.ibm.com/developerworks/projects/bsf) a js.jar(dostupné na http://www.mozilla.org/rhino/) do stejného adresáře.

Poznámka: Pokud používáte Xerces s Tomcatem, budete muset zopakovat trik, který jsem popsal v kapitole 10. Přejmenovat parser.jar PROTI z_parser.jar, A jaxp.jar PROTI z_jaxp.jar abyste se o tom ujistili xerces.jar a zahrnutá verze JAXP je načtena před jakýmkoli jiným analyzátorem nebo implementací JAXP.

Poté restartujte stroj servletu, po kterém jste připraveni zapisovat součásti serveru SOAP.

Servlet routeru a administrátorský klient

Kromě základních operací Apache SOAP obsahuje routerový servlet a také admin klienta. I když je nehodláte používat, doporučuji si je nainstalovat, abyste otestovali, že je SOAP nainstalováno správně. Tento proces závisí na tom, jaký servlet engine používáte, takže proces instalace omezím na Tomcat. Instalační pokyny pro některé další servletové motory lze nalézt na http://xml.apache.org/soap/docs/index.html.

Instalace pod Tomcat je velmi jednoduchá: stačí vzít soubor mýdlo.válka z adresáře soap-2_2/webapps a vložte jej do adresáře $TOMCAT_HOME/webapps- a je to! Chcete-li zkontrolovat instalaci, zadejte adresu do prohlížeče http://localhost:8080/soap/servlet/rpcrouter. Měli byste obdržet odpověď podobnou té, která je znázorněna na obrázku 12-2.

Obrázek 12-2. Směrovač RPC Servlet

Přestože se tato zpráva jeví jako chybová, znamená to, že vše funguje správně. Stejnou odpověď byste měli dostat nasměrováním prohlížeče na adresu klienta správce: http://localhost:8080/soap/servlet/messagerouter.

Chcete-li dokončit testování serveru a klienta, ujistěte se, že jste úplně dodrželi všechny pokyny. Poté spusťte následující třídu Java, jak je uvedeno níže, abyste podpořili adresu URL vašeho servletu pro servlet routeru RPC:

C:\>java org.apache.soap.server.ServiceManagerClient http://localhost:8080/soap/servlet/rpcrouter seznam Nasazené služby:

Měli byste získat prázdný seznam služeb, jak je uvedeno výše. Pokud obdržíte nějaké zprávy, projděte si prosím dlouhý seznam možných chyb, který je k dispozici na http://xml.apache.org/soap/docs/trouble/index.html. Toto je nejkomplexnější seznam problémů, se kterými se můžete setkat. Pokud obdržíte prázdný seznam, znamená to, že nastavení je dokončeno a jste připraveni začít prohlížet příklady uvedené v této kapitole.

Začněme

Existují tři hlavní fáze psaní jakéhokoli systému založeného na SOAP. Poté, co jsem je uvedl, stručně pohovořím o každém z nich:

• Výběr mezi zprávami SOAP-RPC a SOAP;
• Zápis nebo získání přístupu ke službě SOAP;
• Zápis nebo přístup k klientovi SOAP.

Prvním krokem je vybrat si, zda budete SOAP používat pro volání RPC (při kterých se provádí vzdálená procedura na serveru), nebo zprávy (ve kterých klient pouze odesílá informace na server). Tyto procesy podrobně rozebírám níže. Jakmile učiníte toto rozhodnutí, budete muset získat přístup nebo vytvořit vlastní službu. Samozřejmě, protože jsme všichni Java profesionálové, tato kapitola popisuje, jak vytvořit svůj vlastní. A nakonec musíte napsat klienta pro tuto službu, to je vše!

RPC nebo zasílání zpráv?

Váš první úkol nemá nic společného s programováním a je spíše designového charakteru. Musíte si vybrat, zda budete používat službu RPC nebo zprávy. Budeme předpokládat, že jste obeznámeni s RPC (například čtením jedné z kapitol mé knihy). Klient provede vzdálenou proceduru na serveru a poté obdrží odpověď. V tomto scénáři SOAP funguje jako vylepšený systém XML-RPC, který poskytuje lepší zpracování chyb a přenos komplexních datových typů po síti. Tento koncept již znáte, a protože RPC systémy se snadněji píší v SOAP, začnu jimi. Tento článek popisuje vytvoření služby RPC, klienta RPC a uvedení systému do činnosti.

Další způsob práce SOAP je založen na výměně zpráv. Místo provádění vzdálených procedur se používá pouze pro výměnu informací. Jak správně tušíte, jedná se o mocný nástroj, který nevyžaduje, aby klient znal jednotlivé metody libovolného serveru. Modelování vzdálených systémů je také více izolované tím, že umožňuje odesílání datových paketů (pakety v přeneseném smyslu, nikoli v síťovém smyslu) do jiných systémů. Ostatní systémy přitom nemusí vědět o operacích, které byly s těmito daty provedeny. Tento styl je složitější než programování RPC, proto jej zde nebudu popisovat. Najdete ho v mé knize spolu s dalšími podrobnostmi o vzájemné interakci mezi podniky. Nejprve se seznamte s programováním SOAP-RPC.

Stejně jako u většiny problémů s designem je toto rozhodnutí na vás. Analyzujte svou aplikaci a pokuste se zjistit, proč potřebujete používat SOAP. Pokud máte server a sadu klientů, kteří provádějí specifické obchodní funkce na vyžádání, pak je pro vás RPC vhodnější. Ve složitých systémech, ve kterých je výměna dat více než jen provádění specifických obchodních funkcí na vyžádání, je mnohem vhodnější použití zpráv SOAP.

Služba RPC

Nyní, když jsou formality u konce, je čas jednat. Jak víte, v RPC budete potřebovat třídy, jejichž metody budou spouštěny vzdáleně.

Fragmenty kódu

Začnu tím, že se podívám na některé úryvky kódu pro server. Tyto fragmenty jsou třídy s metodami, které se spouštějí pro klienty RPC. Jako příklady jsem použil kód z mé knihy. Místo použití jednoduchých tříd jsem zvolil složitější příklad, abych co nejjasněji demonstroval možnosti SOAP. Takže jsem jako příklad použil třídu CD. Nejprve definujeme prvek mapa pro každý nestandardní typ parametru. Pro atribut styl kódování, alespoň v Apache SOAP 2.2. musíte zadat hodnotu http://schemas.xmlsoap.org/soap/encoding/ . V tuto chvíli je to jediné podporované kódování. Musíte zadat jmenný prostor pro typ definovaný uživatelem a poté název třídy s předponou jmenného prostoru pro tento typ. V našem případě jsem pro tyto účely použil fiktivní jmenný prostor a jednoduchou předponu " x". Potom pomocí atributu javaType, nastavte skutečné jméno třídy Java (pro tento případ - javaxml2.CD). A nakonec kuralesil s přívlastky java2XMLClassName A xml2JavaClassName. S jejich pomocí je specifikována třída, která je převedena z Javy do XML a naopak. Použil jsem úžasně šikovnou třídu BeanSerializer, která je také součástí Apache SOAP. Pokud je váš vlastní parametr ve formátu JavaBean, tento serializátor a deserializátor vás ušetří od nutnosti psát vlastní. Potřebujete třídu s výchozím konstruktorem (nezapomeňte, že pro třídu CD jsem definoval jednoduchý konstruktor bez parametrů) a publikujte všechna data této třídy pomocí metod setXXX A získatXXX. Protože třída CD dokonale splňuje všechny tyto požadavky, BeanSerializer funguje perfektně.

Poznámka: Jaká třída CD splňuje požadavky BeanSerializer. na tom moc nezáleží. Většina tříd je do tohoto formátu snadno převedena. Proto doporučuji vyhnout se psaní vlastních serializátorů a deserializátorů. To je extra bolest hlavy (nic složitého, ale příliš pečlivého) a doporučuji vám šetřit energii a použít konverzi fazolí ve vašich vlastních parametrech. V mnoha případech konverze beanů vyžadují pouze výchozí konstruktor (bez parametrů) ve vaší třídě.

Nyní se pojďme znovu vytvořit sklenice založte a znovu nainstalujte naši službu:

(gandalf)/javaxml2/Ch12$ java org.apache.soap.server.ServiceManagerClient http://localhost:8080/soap/servlet/rpcrouter xml/CDCatalogDD.xml

Pozor: Pokud necháte stroj servletu spuštěný a zároveň přehostíte službu, budete muset restartovat stroj servletu, abyste povolili nové třídy pro službu SOAP a znovu hostili službu.

Nyní zbývá pouze upravit klienta tak, aby používal nové třídy a metody. Příklad 12-10 obsahuje upravenou verzi třídy klienta CDAdder. Změny provedené v předchozí verzi jsou zvýrazněny.

Příklad 12-10: Aktualizovaná třída CDAdder

balíček javaxml2; import java.net.URL; import java.util.Vector; import org.apache.soap.Constants; import org.apache.soap.Fault; import org.apache.soap.SOAPException; import org.apache.soap.encoding.SOAPMappingRegistry; import org.apache.soap.encoding.soapenc.BeanSerializer; import org.apache.soap.rpc.Call; import org.apache.soap.rpc.Parameter; import org.apache.soap.rpc.Response; import org.apache.soap.util.xml.QName; public class CDAdder( public void add (url URL, název řetězce, umělec řetězce, štítek řetězce) vyvolá výjimku SOAPException ( System.out.println("Přidání CD s názvem "" + název + "" umělec "" + umělec + "" studio " + label); CD cd = nové CD(název, umělec, label); // Vytvoření objektu volání Call Call call = new Call(); call.setSOAPMappingRegistry(registr); call.setTargetObjectURI("urn:cd-katalog"); call.setMethodName("addCD"); call.setEncodingStyleURI(Constants.NS_URI_SOAP_ENC);// Nastavení parametrů Vector params = new Vector(); params.addElement(new Parameter("cd", CD.class, cd, null)); call.setParams(params); public static void main(String args) ( if (args.length != 4) ( System.out.println("Šablona: java javaxml2.CDAdder " + "\"[Název CD]\" \"[Jméno interpreta]\ " \"[Studio CD]\""); try ( // URL SOAP serveru, ke kterému je navázáno spojení URL url = new URL(args); // Získání hodnot pro nový CD String title = args; Strunný umělec = args; Popis řetězce = args;

// Přidání CD Adder CDAdder = new CDAdder(); CD:

adder.add(url, název, umělec, štítek);

) catch (Výjimka e) ( e.printStackTrace(); ) ) ) BeanSerializer Jediná opravdu zajímavá změna je v mapování tříd CD// Mapujte tento typ tak, aby mohl být použit s SOAP SOAPMappingRegistry registry = new SOAPMappingRegistry(); BeanSerializer serializer = new BeanSerializer(); registry.mapTypes(Constants.NS_URI_SOAP_ENC, new QName("urn:cd-katalog-demo", "cd"), CD.class, serializátor, serializátor); Takto lze zakódovat uživatelský parametr a přenést jej po síti. Už jsem vám řekl, jak třída lze použít ke zpracování parametrů ve formátu JavaBean, jako je class . Použil jsem deskriptor umístění, abych je uvedl na server, i když nyní musím klientovi sdělit, aby použil tento serializátor a deserializátor. Tuto funkci vykonává třída SOAPMappingRegistry . Metoda mapTypes() vezme zašifrovaný řetězec (opět je lepší použít konstantu NS_URI_SOAP_ENC BeanSerializer) a informace o typu parametru, pro který by měla být použita speciální serializace. Jako první se zadává QName. To je důvod, proč byl v hostitelském deskriptoru použit podivný jmenný prostor. Zde musíte zadat stejné URN a také místní název prvku (pro tento příklad „CD“) a poté objekt Java Volání Třída třída, která bude serializována (.

CD.třída

) a konečně instance třídy pro serializaci a deserializaci. V tomto příkladu budou oba případy zahrnovat instanci. Jakmile všechna tato nastavení zadáte do registru, upozorněte objekt

pomocí metody setSOAPMapping-Registry() pro vás. Vše se vyrábí podle stejné šablony. Chcete-li se otestovat, můžete se podívat na ukázkové soubory pro mou knihu, které již tyto aktualizované třídy obsahují.

Poznámka: Můžete se rozhodnout, protože třída setSOAPMapping-Registry() neinteraguje přímo s objektem CD(vráceno metodou seznam() na typu záleží Hashtable), pak nemusíte provádět žádné změny. Nicméně vrácená třída Hashtable obsahuje instance objektů CD. Pokud SOAP neví, jak je deserializovat, klient vyvolá chybu. V tomto případě musíte k vyřešení problému zadat v objektu Volání kopie BeanSerializer serializer = new BeanSerializer();.

Efektivní zpracování chyb

Nyní, když jste viděli vlastní objekty a provedli volání RPC a podobně, dovolte mi mluvit o méně vzrušujícím tématu: zpracování chyb. Při jakékoli síťové transakci může dojít k mnoha selháním. Služba se nespustí, na serveru je chyba, objekt nelze najít, chybí třídy a mnoho dalších problémů. Doposud jsem pouze používal metodu fault.getString() pro generování chybových zpráv. Ale tato metoda nemusí být vždy užitečná. Chcete-li to vidět v akci, odkomentujte konstruktor CDKatalog:

public CDCatalog() ( //katalog = new Hashtable(); // Vytvořte adresář addCD(new CD("Nickel Creek", "Nickel Creek", "Sugar Hill"));

addCD(nové CD("Let it Fall", "Sean Watkins", "Sugar Hill")); addCD(nové CD("Aerial Boundaries", "Michael Hedges", "Windham Hill")); addCD(nové CD("Taproot", "Michael Hedges", "Windham Hill")); Hashtable)

Znovu jej zkompilujte, restartujte motor servletu a znovu jej hostujte. To bude mít za následek výjimku

Výjimka NullPointerException když se konstruktor třídy pokusí přidat CD do neinicializovaného. Při spouštění klienta se zobrazí chybová zpráva, která však nebude příliš informativní: (gandalf)/javaxml2/build$ java javaxml2.CDLister http://localhost:8080/soap/servlet/rpcrouter Zobrazení aktuálního adresáře CD. Chyba: Nelze vyřešit cílový objekt: null To vůbec nejsou informace, které mohou pomoci při identifikaci a opravě chyby. Rámec se však dobře vyrovnává se zpracováním chyb. Vzpomínáš si? DOMFaultListener, kterou jste zadali jako hodnotu prvku chybaListener? Nastal čas, aby vstoupil do hry. Objekt vrácen v případě chyby Chyba:

import java.net.URL; import java.util.Enumeration; import java.util.Hashtable; import java.util.Iterator; import java.util.Vector; import org.apache.soap.Constants; import org.apache.soap.Fault; import org.apache.soap.SOAPException; import org.apache.soap.encoding.SOAPMappingRegistry; import org.apache.soap.encoding.soapenc.BeanSerializer; import org.apache.soap.rpc.Call; import org.apache.soap.rpc.Parameter; import org.apache.soap.rpc.Response; import org.apache.soap.util.xml.QName;

Nyní provedeme změny pro zpracování chyb v metodě list():

if (!response.generatedFault()) ( Parametr returnValue = response.getReturnValue(); Hashtable Catalog = (Hashtable)returnValue.getValue(); Výčet e = Catalog.keys(); while (e.hasMoreElements()) (String title = (String)e.nextElement(); CD cd = (CD)catalog.get(title) System.out.println(" "" + cd.getTitle() + "" umělec " + cd.getArtist() + " studios " + cd.getLabel() ) else ( Porucha = response.getFault(); System.out.println("Chyba: " + fault.getFaultString()); Vektorové záznamy = fault.getDetailEntries();

for (Iterátor i = entries.iterator(); i.hasNext();) ( org.w3c.dom.Element entry = (org.w3c.dom.Element)i.next(); System.out.println(entry .getFirstChild().getNodeValue()); Použití metody getDetailEntries() získáte přístup ke službě SOAP a serveru nezpracovaných dat podporujících problém. Kód je znovu zpracuje (obvykle existuje pouze jeden prvek, ale vyžaduje zvýšenou pozornost) a zachytí DOMŽivel

, obsažené v každém záznamu. Zde je v podstatě XML, se kterým pracujete: SOAP-ENV:Server.BadTargetObjectURI Nelze vyřešit cíl: null

To je to, co chceme! Jinými slovy, objekt Fault vám poskytuje přístup k části obálky SOAP, která obsahuje chyby. Apache SOAP navíc poskytuje trasování zásobníku Java, když dojde k chybám, a poskytuje podrobné informace potřebné k jejich opravě. Zachycení prvku stackTrace a vytištění hodnoty uzlu Text

z tohoto prvku může váš klient vytisknout trasování zásobníku serveru. Zkompilováním těchto změn a restartováním klienta získáte následující výsledek: (CDCatalog.java:14) v java.lang.Class.newInstance0 (Nativní metoda) v java.lang.Class.newInstance(Class.java:237)

Není to o moc lepší, ale alespoň vidíte pár informací, že došlo k výjimce addCD(nové CD("Aerial Boundaries", "Michael Hedges", "Windham Hill")); a dokonce zjistit čísla řádků ve třídách serverů, ve kterých k tomuto problému došlo. Výsledek těchto nedávných změn vám poskytl jasný obrázek o problému zpracování chyb. Nyní byste měli zkontrolovat chyby ve třídách serveru. Ano, málem bych zapomněl, předtím si nezapomeňte změnit třídu zpět CDKatalog abychom se zbavili chyb, které jsme záměrně zavedli pro přehlednost!

1. Hodně se mluví o provozování SOAP přes jiné protokoly jako SMTP (nebo i Jabber). Standard SOAP to v současné době neposkytuje, ale v budoucnu mohou být přidány podobné funkce. Proto se nedivte, že se setkáte s aktivními diskuzemi na toto téma.

SOAP (Simple Object Access Protocol) je standardizovaný protokol pro přenos zpráv mezi klientem a serverem. Obvykle se používá ve spojení s HTTP(S), ale může také pracovat s jinými protokoly aplikační vrstvy (jako jsou SMTP a FTP).
Testování SOAP z pohledu testovacích technik se nijak zásadně neliší od práce s jinými API, vyžaduje však předběžnou přípravu (z hlediska teorie protokolů) a speciální testovací nástroje. V tomto článku bych rád zformuloval malý kontrolní seznam potřebných znalostí a dovedností, který bude stejně užitečný jak pro SOAP testera (který často po zadání úkolu netuší, čeho se chytit), tak pro manažera, který je nuceni hodnotit znalosti testerů a vypracovávat plány školení.

Teoretický základ

Skutečnost, že SOAP je protokol, má mnoho důsledků pro testování: musíte si prostudovat samotný protokol, „primární“ standardy a protokoly, na kterých je založen, a (podle potřeby) existující rozšíření.

XML
XML je značkovací jazyk podobný HTML. Jakákoli zpráva odeslaná/přijatá prostřednictvím SOAP je dokument XML, ve kterém jsou data pohodlně strukturována a snadno čitelná, například:

Julie
Natasha
Připomínka
Nezapomeňte napsat článek!

Více o XML se můžete dozvědět na w3schools nebo codenet (v ruštině). Určitě věnujte pozornost popisu jmenných prostorů (metoda pro řešení konfliktů při popisu prvků v XML) – jejich použití je v SOAP vyžadováno.

XSD
Při práci je vždy vhodné mít standardizovaný popis případných XML dokumentů a kontrolovat jejich správné vyplnění. Pro tento účel existuje XML Schema Definition (nebo zkráceně XSD). Dva hlavní rysy XSD pro tester jsou popis datových typů a uložení omezení na možné hodnoty. Například prvek z předchozího příkladu může být volitelný a omezen na 255 znaků pomocí XSD:

...







...

Rozšíření SOAP
Při své práci se také můžete setkat s různými „rozšířeními“ SOAP – standardy jako WS-*. Jedním z nejrozšířenějších je WS-Security, který umožňuje pracovat s šifrováním a elektronickými podpisy. Spolu s ním se často používá WS-Policy, pomocí kterého můžete spravovat práva k používání vaší služby.

Příklad použití WS-Security:

Alice
6S3P2EWNP3lQf+9VC3emNoT57oQ=
YF6j8V/CAqi+1nRsGLRbuZhi
2008-04-28T10:02:11Z

Všechna tato rozšíření jsou poměrně složité struktury, které se nepoužívají v každé službě SOAP; jejich podrobné studium v ​​počáteční fázi zvládnutí testování SOAP pravděpodobně nebude relevantní.

Nástroje

Jak již víte, SOAP je vážná věc, abyste s ním mohli pracovat, musíte znát teorii a četné standardy. V praxi by taková složitost vedla k velmi významným mzdovým nákladům (například byste se museli pokaždé podívat na diagram v poznámkovém bloku a posílat požadavky s curl). Proto byly vytvořeny nástroje, které práci se SOAP usnadní.

XML/XSD editory
Dobrý tester začíná s testováním ve fázi psaní dokumentace, takže je vhodné použít k testování obvodů speciální editory. Dva nejznámější jsou Oxygen (pro více platforem) a Altova (pouze Windows); oba jsou placeni. Jedná se o velmi výkonné programy, které analytici aktivně využívají při popisu služeb.

V mé praxi se ukázaly jako užitečné tři funkce editoru: vizualizace XSD, generování XML na základě XSD a validace XML na základě XSD.

1. XSD vizualizace potřebné pro vizuální znázornění diagramu, což vám umožní rychle identifikovat požadované prvky a atributy, stejně jako existující omezení. Například pro CheckTextRequest je prvek text povinný a všechny tři atributy jsou volitelné (s atributem options má výchozí hodnotu nula).

Vizualizace je nezbytná, když je v diagramu mnoho typů a omezení. Pokud potřebujete pouze toto a nechcete platit za speciální editory, můžete zvážit bezplatné alternativy (například JDeveloper).

2. Generování XML na základě XSD užitečné, když chcete vidět platný příklad zprávy. Používám jej k rychlému experimentování s možným dokončením zpráv a testování nuancí toho, jak omezení fungují.

3. Po použití funkce z bodu 2 je užitečné provést Ověření XML proti XSD– to znamená zkontrolovat správnost zprávy. Funkce 2 a 3 dohromady vám umožní zachytit složité vady v XSD, i když je samotná služba ve vývoji.

Testovací nástroj – SoapUI

Testování SOAP téměř vždy zahrnuje použití SoapUI. O použití tohoto nástroje se můžete dočíst v různých zdrojích (,), ale nejúčinnější bude přečíst si oficiální dokumentaci. Identifikuji 8 podmíněných úrovní znalosti SoapUI:

Úroveň 1 – Mohu posílat požadavky
Naučte se vytvářet projekt založený na WSDL. SoapUI za vás může generovat všechny potřebné dotazy; Jediné, co musíte udělat, je zkontrolovat, zda jsou vyplněny správně, a kliknout na tlačítko „Odeslat“. Jakmile si osvojíte dovednosti vytvářet platné dotazy, musíte zvládnout umění vytváření nesprávných dotazů, které způsobují chyby.

Úroveň 2 – Umím dělat testovací sady a testovací případy
Začněte dělat mini-autotesty. Testovací sady a testovací případy vám umožňují vytvářet testovací skripty API, připravovat data pro požadavky a automaticky kontrolovat přijatou odpověď, aby bylo zajištěno, že odpovídá očekávanému. Nejprve je lze použít jednoduše jako kolekce dotazů. Pokud jste například vytvořili defekt a chcete jej po opravě rychle zkontrolovat, můžete přidělit samostatnou testovací sadu speciálně pro požadavky na defekty.

Úroveň 3 – Umím psát tvrzení
Po zvládnutí testovacích případů bude pro vás užitečné naučit se, jak je učinit automaticky ověřitelnými. Poté již nebudete muset hledat informace o odpovědi očima: pokud je automatická kontrola, případy budou označeny zeleně (pokud kontrola projde) nebo červeně (pokud neprojde). SoapUI poskytuje velkou sadu možných tvrzení, ale nejpohodlnější a nejjednodušší jsou Obsahuje a Neobsahuje. S jejich pomocí můžete zkontrolovat přítomnost konkrétního textu v přijaté odpovědi. Tyto kontroly také podporují vyhledávání regulárních výrazů.

Úroveň 4 – použijte XPath a/nebo XQuery v Assertions
Pro ty, kteří jsou trochu obeznámeni s UI pomocí Selenium, je jazyk XPath známá věc. Zhruba řečeno, XPath umožňuje vyhledávat prvky v dokumentu XML. XQuery je podobná technologie, která může interně používat XPath; tento jazyk je mnohem výkonnější, podobá se SQL. Oba tyto jazyky lze použít v Assertions. Kontroly s jejich pomocí jsou cílenější a stabilnější, takže se vaše případy budou těšit větší důvěře.

Úroveň 5 – Umím psát složité testy pomocí speciálních kroků

Testovací případy mohou obsahovat nejen jeden požadavek, ale i několik (například když chcete emulovat standardní uživatelský scénář „vytvořit entitu“ → „exportovat entitu“). Mezi požadavky mohou existovat další speciální kroky, například:

• Vlastnosti a Přenos majetku (pomáhají znovu používat data a přenášet je mezi požadavky);
• JDBC požadavek (používá se k načtení dat z databáze);
• Conditional Goto (umožňuje vytvářet větve nebo smyčky v testovacím případě);
• Spusťte TestCase (pomáhá umístit některé typické dotazy do samostatných testovacích případů a v případě potřeby je volat).

Úroveň 6 – pomocí Groovy skriptů

SoapUI vám umožňuje psát Groovy skripty na různých místech. Nejjednodušším případem je generování dat v samotném dotazu pomocí vložení $(=). Po celou dobu používám tyto vložky:

• $(=new Date().format(“yyyy-MM-dd’T’HH:mm:ss”))– vložit aktuální datum a čas v požadovaném formátu;
• $(=java.util.UUID.randomUUID())– pro vložení správně vytvořeného náhodného GUID.

Jako kroky v případech a kontrolách lze použít plnohodnotné skripty. V určitém okamžiku zjistíte, že několik speciálních kroků z páté úrovně lze nahradit jedním skriptem.

Úroveň 7 – pomocí MockServices
SoapUI založené na WSDL může generovat Mock objekty. Falešný objekt je nejjednodušší simulace služby. Pomocí „zesměšků“ můžete začít psát a ladit testovací případy ještě dříve, než bude služba skutečně dostupná pro testování. Mohou být také použity jako „stub“ pro dočasně nedostupné služby.

Úroveň 8 – SoapUI God
Znáte rozdíl mezi placenou a bezplatnou verzí SoapUI a ve svém kódu používáte SoapUI API. Používáte zásuvné moduly a spouštíte případy prostřednictvím příkazového řádku a/nebo CI. Vaše testovací případy jsou jednoduché a snadno se udržují. Obecně jste na tomto nástroji „sežrali psa“. Rád bych si promluvil s někým, kdo zvládl SoapUI na této úrovni. Pokud jste jedním, přihlaste se do komentářů!

Testování s programovacími jazyky

Zde je příklad toho, jak vypadá požadavek na rozhraní API YandexSpeller vytvořený pomocí groovy-wslite:

import wslite.soap.*
def klient = nový SOAPClient("http://speller.yandex.net/services/spellservice?WSDL")
def response = client.send(SOAPAction: "http://speller.yandex.net/services/spellservice/checkText") (
tělo (
CheckTextRequest("lang": "ru", "xmlns":"http://speller.yandex.net/services/spellservice") (
text("chyba")
}
}
}
potvrdit "chybu" == response.CheckTextResponse.SpellResult.error.s.text()
tvrdit "1" == [e-mail chráněný]()

Pokud vím, zatím neexistují žádné rámce na vysoké úrovni (jako Rest-assured) pro testování SOAP, ale nedávno se objevil zajímavý nástroj - karate. S jeho pomocí můžete popsat případy pro testování SOAP a REST ve formě skriptů jako Cucumber / Gherkin. Pro mnoho testerů bude obrat na karate ideálním řešením, protože takové scénáře budou z hlediska složitosti psaní a podpůrných případů ležet někde uprostřed mezi používáním SoapUI a psaním vlastního frameworku pro testování SOAP.

Závěr

Je nepravděpodobné, že někdy budete chtít testovat SOAP jen pro sebe (jako byste mohli s REST). Jedná se o těžký protokol, který se používá v seriózních podnikových řešeních. Jeho váha je ale zároveň darem pro testera: všechny použité technologie jsou standardizované a pro práci jsou k dispozici kvalitní nástroje. Vše, co se od testera vyžaduje, je chuť se je učit a používat.

Pojďme dát dohromady stejný kontrolní seznam potřebných dovedností pro testera. Pokud tedy teprve začínáte testovat služby SOAP, musíte znát a umět používat:

• WSDL.
• MÝDLO.
• XML/XSD editory (na úrovni vizualizace XSD).
• SoapUI na úrovni 1.

Jak vidíte, hlavní důraz je kladen na učení standardů v SoapUI, stačí jen umět provádět dotazy. Když se ponoříte do testování SOAP, setkáte se s úkoly, které budou vyžadovat vážnější dovednosti a znalosti, ale neměli byste se snažit naučit se vše najednou. Mnohem důležitější je důslednost ve zvyšování úrovně složitosti prováděných úkolů. Při dodržování tohoto doporučení si jednoho dne uvědomíte, že jste se v tomto oboru stali dobrým specialistou!

Historie stvoření

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

Ale ani dnes nebyly vyřešeny všechny problémy s integrací, bohužel neexistoval jediný 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 jako výsledek jejich společných aktivit vznikl Simple Object Access Protocol - jednoduchý protokol pro přístup k objektům, který popisuje standard pro vzdálenou proceduru. volání na základě jazyka XML (Extensible Markup Language - rozšiřitelný značkovací jazyk). SOAP je navržen tak, aby výrazně zjednodušil vývoj mezijazykových aplikací a nástrojů pro obchodní integraci. Začátek byl vytvořen se SOAP 1.0, který ke svému provozu 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 prošla specifikace významnou revizí, aby lépe vyhovovala 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 již nezávisí na transportních protokolech. SOAP 1.0 vyžadoval protokol HTTP, zatímco u SOAP 1.1 na typu přenosu nezáleží: k předávání zpráv můžete použít e-mailové nebo masážní odkazy. Společnosti, které již přijaly SOAP 1.0, byly svázány s nestandardní technologií Microsoftu. Ř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

Původní verze SOAP 1.1 předložená IETF Internet Technical Task Force byla založena na technologii XML-Data navržené společností Microsoft v lednu 1998. Během procesu revize standardů W3C však byla základní struktura nahrazena 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ý na základě XML (Extensible Markup Language) definuje běžný formát pro komunikaci mezi všemi internetovými aplikacemi a službami. Tato verze rozšiřuje možnosti SOAP pro asynchronní komunikaci o podporu nejen pro HTTP, ale také pro internetové protokoly jako 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 použitý operační systém, objektový model nebo programovací jazyk. Na základě internetových standardů XML a HTTP umožňuje SOAP vzájemnou komunikaci jakýchkoli nových nebo stávajících aplikací. Webové stránky, které podporují SOAP, se mohou stát webovými službami, které jsou přístupné čistě programově a nevyžadují lidský zásah. Jediná infrastruktura, která umožňuje přímou interakci mezi internetovými aplikacemi, otevírá nové příležitosti 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 meziplatformní komunikace aplikací. Tento článek vám pomůže získat vhled do těchto nových slibných technologií.

Co je SOAP

V současnosti používané technologie pro vzdálené volání metod (DCOM, CORBA/IIOP a RMI) jsou poměrně náročné na konfiguraci 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 na bázi XML pro výměnu 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 různými transportními protokoly, včetně HTTP, SMTP atd.

Co jsou webové služby

Webové služby jsou funkce a data vystavená 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 implementačním jazyku a platformě. Technologie webových služeb je základním kamenem programovacího modelu .NET společnosti Microsoft. K demonstraci schopností SOAP jsem použil nedávno vydanou implementaci SOAP Toolkit verze 2.0 od Microsoftu. Je třeba poznamenat, že aktuální verze Toolkit se znatelně liší od předchozí (Microsoft SOAP Toolkit pro Visual Studio 6.0) a od beta verze SOAP Toolkit 2.0.

Mechanismus interakce mezi klientem a serverem

1. Klientská aplikace vytvoří instanci objektu SOAPClient
2. 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.
3. Klientská aplikace pomocí schopností pozdní vazby objektu SOAPClient volá metodu služby. SOAPClient vygeneruje paket požadavku (SOAP Envelope) a odešle jej na server. Lze použít jakýkoli přenosový protokol, ale obvykle se používá HTTP.
4. Paket vezme serverovou aplikaci Listener (může to být aplikace ISAPI nebo stránka ASP), vytvoří objekt SOAPServer a předá mu paket požadavku.
5. SOAPServer načte popis webové služby, načte popis a paket požadavku do XML DOM stromů
6. SOAPServer volá metodu objektu/aplikace implementující službu
7. Výsledky provádění metody nebo popis chyby jsou převedeny objektem SOAPServer na paket odpovědi a odeslány klientovi
8. Objekt SOAPClient analyzuje přijatý paket a vrátí klientské aplikaci 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 metod, jejich typy, názvy a umístění služby Listener. 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ý, ale element Body musí být přítomen a být přímým potomkem elementu Envelope. Pokud dojde k chybě 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, 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 práci s transportním protokolem 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.

MÝDLO-textový protokol, který používá XML k výměně strukturovaných zpráv v distribuovaném výpočetním 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 poslední 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 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.

· Ačkoli je SOAP standard, různé programy často generují zprávy v nekompatibilních formátech. 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 konkrétních protokolů SOAP, se nazývají uzly SOAP. 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.