Alternativní cesty k webovým službám

Marketingová mašinérie velkých dodavatelů způsobila, že si mnozí uživatelé spojují webové služby pouze s technolo...


Marketingová mašinérie velkých dodavatelů způsobila, že si mnozí uživatelé
spojují webové služby pouze s technologickými standardy jako SOAP, WSDL či
UDDI. Mnohé aplikace založené na principu web services lze však realizovat
jednodušeji a flexibilněji pomocí alternativních přístupů.
O počátcích konceptu webových služeb v jeho dnešní podobě kolují nejrůznější
historky. Don Box, který se podílel na vývoji standardu SOAP a dnes
spolupracuje se společností Microsoft, objasňuje jeho vznik tak, že on a další
autoři odborných knih chtěli zjistit, kdo z nich se dostal nejvýše v pořadí
prodejního žebříčku Amazon.com. Za tímto účelem však nechtěli neustále
navštěvovat web tohoto on-line prodejce, nýbrž příslušné informace číst
strojově. Nicméně katalog Amazonu měl podobu HTML stránek, takže příslušné
skripty musely požadované informace extrahovat z hromady údajů webového
layoutu. Proto vznikla potřeba vyvolávat přímo z webu obsah ve formě
strukturovaných dat.
Ve všeobecném pohledu mají webové služby plnit stále stejné požadavky, které už
se snažily vyřešit mnohé jiné technologie: Umožňují komunikaci mezi aplikacemi
na bázi webových standardů, jako jsou HTTP, URI (Uniform Resource Identifier)
či XML. Poslední z nich přitom slouží k definici syntaxe pro popis přenášených
dat. Charakteristickým znakem webových služeb zůstává silné zaměření na
dokumentově orientované aplikace, i když jsou ve stále větší míře budovány
rozsáhlé "oficiální" technologické balíky zaměřené na zpracování transakcí.

Komplexnější služby
Za účelem vybudování rozsáhlejší infrastruktury webových služeb, o kterou by se
firmy mohly spolehlivě a bezpečně opírat, doplňují nejrůznější grémia a
konsorcia výrobců klíčové standardy SOAP, WSDL (Web Service Description
Language) a UDDI (Universal Description, Discovery and Integration) o další
technologie. K tomu je třeba přičíst celý balík bezpečnostních standardů
vztahujících se k XML, které jsou shromážděny pod označením WS Security. Kromě
toho by mělo být pro takové aplikace zajištěno, že SOAP zprávy zaručeně dorazí
ke svému příjemci. Tyto požadavky sleduje samostatná komise pro Reliable
Messaging (spolehlivý přenos zpráv) zastřešená pod konsorciem Oasis.
Dodatečná rozšíření technologického zázemí pro webové služby se týkají řízení
předávání zpráv přes více míst a stejně tak i zpracování obchodních procesů.
Pro řešení prvního z problémů předložila společnost Microsoft už přede dvěma
lety návrh pro SOAP Routing Protocol, standard určený pro definici obchodních
procesů v rámci architektury webových služeb pak Gatesova firma ve spolupráci
se společností IBM pokřtily Busines Process Execution Language (BPEL). Také pro
tuto oblast byla s ohledem na další vývoj založena v rámci Oasis zvláštní
pracovní skupina.
Při vývoji infrastruktury pro webové služby se obzvláště velcí dodavatelé v
podstatě snaží doplnit veškeré podstatné funkce, které známe už z
komponentového modelu CORBA potažmo COM. Takto přebírá například jeden z
klíčových standardů WSDL úlohu IDL (Interface Definition Language), UDDI je
možné přirovnávat k Trader Service modelu CORBA. "Mohutnost" těchto technologií
pak neodvratně směřuje ke značné komplexitě (a jinak tomu není ani u jejich
webových protějšků). Ta je v případě webových služeb výsledkem nejen neustálého
přibývání nových souvisejících standardů, ale také díky rozšiřování uvedených
základních technologií. Takto je například standard SOAP 1.2, nedávno uvolněný
konsorciem W3, založen na specifikaci XML Schema a zdědil přitom i rozsáhlé
definice datových typů.
Nicméně web services zatím nemohou bez kompromisů dostát svým slibům, tedy
propojit veškeré aplikace za hranicemi platforem, na kterých běží právě
nahrazení komplexních datových struktur totiž zatím působí problémy.
Přednedávnem publikovaný "Basic Profile" (základní profil), který zveřejnila
organizace Web Services Interoperability Organization (www.ws-i.org), je pouze
prvním krokem tímto směrem. Sestává ze sady standardů webových služeb, jejich
vysvětlení a pozměňovacích návrhů, které by měly zlepšit interoperabilitu.
Jestliže aplikace nepotřebují plnou funkčnost celého balíku technologií
webových služeb, potom se před vývojáři přirozeně otevírá možnost použít pouze
samotný SOAP. Pro takové požadavky se pak jako alternativa nabízí XML-RPC.
Označení technologie poukazuje na to, že je podobně jako SOAP určena pro volání
vzdálených metod (Remote Procedure Call). Tato podoba přitom není vůbec
náhodná, protože obě mají stejný původ. Druhý iniciátor, který se vedle Dona
Boxe podílel na vývoji SOAPu, Dave Winter z firmy Userland, nechtěl čekat, až
zmíněná technologie projde "mlýny" velkých dodavatelů softwaru a grémii
výrobců. Specifikoval tedy na základě prvotního konceptu SOAPu vlastní,
"odlehčený" XML protokol.

XML-RPC není zastaralý
Jen proto, že se XML-RPC úzce opírá o počáteční návrh protokolu SOAP a zůstává
relativně jednoduchý, nemusí být ještě dlouho pokládán za zastaralý a
překonaný. Mnohé převážně volné implementace ukazují, že se technologie těší
velké podpoře vývojářské komunity. Je dostupná prakticky pro každý skriptovací
jazyk a platformu. K nejznámějším zástupcům možno počítat javovou verzi
webového serveru Apache (http:// ws.apache.org/xmlrpc), jakož i odpovídající
toolkity pro Perl a Python. Implementace pro .Net (www.xml rpc.net) je taktéž k
dispozici, takže aplikace mohou komunikovat také se svými protějšky
provozovanými na platformě Microsoftu.
Na základě svého původu nereprezentuje XML-RPC jak se lze dovtípit žádný
oficiální standard, specifikace je ale volně dostupná a může být bez
jakýchkoliv omezení pozměněna nebo dále rozvíjena. Mnohé open source
implementace pak dalekosáhle zaručují, že nemůže dojít k situaci, kdy by nějaký
výrobce tuto technologii "zdeformoval" na proprietární standard. Na základě
jednoduchých a na platformě nezávislých modelů datových typů XML-RPC umožňuje v
současnosti dokonce i lepší interoperabilitu heterogenních systémů než SOAP.
Přijetí XML-RPC obzvláště v oblasti open source projektů dokládá několik velmi
zajímavých příkladů. Patří mezi ně například systém pro správu obsahu (Content
Management) Zope (www .zope.org), linuxový desktop KDE (www.kde.org), stejně
jako většina systémů populárních weblogů, mezi jinými i Blogger.com nebo
Movable Type (http://movabletype .org). Poslední jmenovaný přitom implementuje
Blogger API, za nímž stojí opět Dave Winer.
Jak prozrazuje už jeho jméno, XML-RPC představuje právě tak jako SOAP
mechanismus pro vzdálené volání funkcí přes web. Nicméně zastánci přístupu
označovaného jako Representational State Transfer (REST) pro realizaci webových
služeb požadují, aby v prostředí webu nebyly používány techniky z oblasti
zpracování transakcí, nýbrž aby byla celá architektura lépe přizpůsobena přímo
architektuře webu. Termín REST se dostal do povědomí pouze v poměrně malé míře
(byl zformován Royem Fieldingem, architektem, který se podílel na HTTP 1.1, a
spoluzakladatelem projektu Apache, v jeho disertační práci), popisuje nicméně
postup, který už dávno našel značné rozšíření. Nejedná se přitom o žádnou
specifikaci ani toolkit, nýbrž o souhrn návrhových principů.

Flexibilní REST
REST představuje design (styl) architektury webových služeb, v němž jsou pro
výměnu dat využívány základní internetové technologie, především HTTP. Zastánci
přístupu REST argumentují, že je zbytečné využívat metody protokolu SOAP
(potažmo UDDI a WSDL), protože lze vše realizovat prostřednictvím příkazů HTTP.
U přístupu REST totiž nezáleží na tom, jsou-li XML data posílána bez dodatečné
nadstavby protokolu SOAP nebo XML-RPC přímo přes HTTP. Například všechny knihy
v katalogu Amazonu, které pojednávají o XML, je možné vyhledat prostřednictvím
URL typu http://xml.amazon .com/onca/xml3?....&mode=books&Key wordSearch=XML.
Výsledek pak bude klientovi poslán nikoliv jako HTML stránka, nýbrž jako XML
dokument. Tyto strukturované informace mohou být programem, jenž je vyvolá,
velmi jednoduše přečteny, transformovány, filtrovány nebo mohou být postoupeny
dalšímu webovému zdroji. Přívrženci REST vidí paralelu k unixovému konceptu v
možnosti propojovat vzájemně programy prostřednictvím pipeline. Výstup, který
je výsledkem jednoho příkazu, se stává vstupem pro ten následující.
Prolinkování se tím pro komunikaci mezi stroji stává stejně důležitým jako pro
lidské uživatele využívající web.

Amazon používá REST
Díky úzké vazbě na základní webové standardy činí REST takto realizované služby
snadno využitelnými. Navíc je možné zabezpečit přenos přes internet pomocí SSL,
přístup ke zdrojům vyžaduje na obou komunikujících stranách autentizaci na
webovém serveru a proxy servery mohou data identifikovatelná pomocí URI ukládat
do cache paměti. Za slabiny REST je ale pokládáno to, že návrhové principy
například konvence pro jména URI nejsou důsledně dodržovány všemi vývojáři.
Navíc lze jen těžko ošetřit vyskytnuvší se chyby.
Příklad Amazonu ironicky ukazuje, že REST je strojově obsluhovanému webu, o
který šlo svého času vynálezcům SOAP, bližší, než webové služby realizované
podle Microsoftu nebo IBM. Zmíněný internetový prodejce nabízí svým obchodním
partnerům už několik měsíců přístup k bezpočtu funkcí svého on-line obchodu jak
prostřednictvím REST API, tak přes SOAP. Tisíce webů používají Amazon a jeho
služby přímo jako platformu pro vývoj aplikací. Colin Bryar, zodpovědný v
Amazonu za program webových služeb, se přitom zmínil, že více dvě třetiny z
nich přitom využívají namísto SOAP rozhraní založené na REST API.
Flexibilita REST se projevuje, když mají být klienti obsluhováni s různými
datovými formáty. Například RSS (Rich Site Summary), coby relativně nový
přístup tohoto typu na poli webových služeb, nedefinuje protokoly nebo principy
designu, ale formát dokumentů pro souhrn obsahu webu. Původní cíl přenos a
zobrazování nadpisů pro zpravodajské služby byl dávno překonán a nyní RSS ve
stále rostoucí míře slouží jako médium pro agregaci dat z různých zdrojů. Jako
XML formát vychází vstříc rovněž požadavkům po strojově čitelných webech.
Amazon je i zde v roli jednoho z pionýrů a nabízí například funkci RSS-Feed pro
žebříčky bestsellerů. Technicky vzato je přitom pouze URI identifikátor
odpovídajícího REST rozhraní doplněn o parametr pro XSLT transformaci.

Protokoly pro web services
XML-RPC: Označení se vztahuje současně na specifikaci i sadu implementací,
které mají umožnit aplikacím provozovaným na různých místech v různých
prostředích volat procedury vzdáleně přes internet. Přesněji řečeno se tedy
jedná o RPC (Remote Procedure Call) systém, který využívá XML a HTTP pro volání
procedur přes TCP/IP síť, potažmo přes internet. HTTP přitom slouží jako
transportní protokol a XML pro kódování. XML-RPC je navržen s důrazem na
jednoduchost, avšak umožňuje přenášet, zpracovávat a vracet i komplexní datové
struktury.
SOAP (Simple Object Access Protocol): Jedná se o schéma založené na XML, které
umožňuje vzájemnou komunikaci počítačů v síti (např. v internetu) typicky
prostřednictvím webových služeb. Kódovací schéma protokolu SOAP popisuje
kódování dat s využitím sady definovaných datových typů. Jestliže tyto typy
nejsou dostačující, uživatel si může nadefinovat své vlastní. Schéma obálky pak
popisuje celkový formát SOAP zprávy. Definuje rovněž vestavěné možnosti
rozšíření formátu zprávy pro podporu některých aplikací. Specifikace SOAP
vyvinutá konsorciem W3C dále popisuje, jak prostřednictvím HTTP posílat a
přijímat zprávy. SOAP umožňuje komunikaci prostřednictvím různých protokolů,
ale právě HTTP je pro většinu aplikací nejpoužívanější. Teoreticky může být
SOAP využit při výměně téměř jakéhokoliv typu dat mezi dvěma aplikacemi, při
kódování RPC je pak využit jako protokol typu "request/response". RPC
požadavek, který identifikuje určitou operaci a obsahuje její parametry, je pak
zakódován do SOAP zprávy.

Web services a princip REST
REST (Representational State Transfer) představuje design architektury webových
služeb, v němž jsou pro výměnu dat využívány základní internetové technologie,
především HTTP (s operátory PUT, GET, POST a DELETE). URL pak může například
reprezentovat umístění souborů dat, k nimž lze pomocí webové služby
přistupovat. Naproti tomu SOAP (i XML-RPC) systémy využívají vlastní syntaxi
pro popis alokace dat.
K nejdůležitějším požadavkům principu REST patří, že každý zdroj, s nímž lze
manipulovat prostřednictvím datových operací, disponuje vlastním URI. Příkazy
nezbytné pro čtení a zápis dat však nejsou ve zprávách XML protokolu zabaleny.
Tento přístup staví do popředí webové standardy HTTP, URI, a XML, přičemž sahá
zpět po základních operátorech HTTP. Ty disponují díky GET, PUT, POST a DELETE
nezbytnými příkazy pro dotazování, vkládání, aktualizaci, jakož i mazání dat, a
s tím i ekvivalenty k příkazům SELECT, INSERT, UPDATE a DELETE používaným v
SQL. Zastánci RESTu si stěžují, že SOAP využívá pro přenos informací přes HTTP
pouze operátor POST. Vlastní adresa požadovaného (kontaktovaného) zdroje, jakož
i plánované datové operace jsou přitom přebírány pouze protokolem SOAP. Z
pohledu REST mohou být XML dokumenty zpracovány přes HTTP (neboť jsou dostupné
prostřednictvím URI) a nikoliv voláním metod či procedur s parametry.









Komentáře
K tomuto článku není připojena žádná diskuze, nebo byla zakázána.