Někteří lidé nazývají webové služby (dále jen WS – web services) jako nejnovější implementaci distribuovaných objektů. To je mýlka, která vyplývá z nepochopení architektury WS. Z použití WS sice vyplývá distribuovanost, ale zde podobnost v podstatě končí. V tomto zápisku bych rád osvětlil základní principy webových služeb.
Webové služby se dají daleko lépe přirovnat k messagingovým systémům, posílají se zprávy a odpovědi na tyto zprávy. Transportní vrstva není pevně dána, nemusíte používat jen HTTP, ale například právě nějaký messagingový systém (například JMS). Kdybych měl být přesnější, transportní vrstvou proudí XML dokumenty – mohli bychom tedy dokonce říci, že WS jsou dokumentově orientovaný systém. Každopádně je chyba říci, že WS jsou pouze RPC pro internet.
Vysvětlení co jsou WS není až tak jednoduché, každá WS se skládá z několika klíčových komponent:
Protokol, který se pro WS v drtivé většině používá, je SOAP – Simple Object Access Protocol. To je velmi zavádějící název, protože SOAP nemá nic společného se vzdáleným přístupem k objektům. SOAP zpráva jako taková se skládá z
Webové služby mají velmi jednoduchou a rozšiřitelnou architekturu, což vedlo k určitému tříštění a vzájemným nekompatibilitám. Každá firma si přidávala vlastní řešení určitých problémů – například pokud chcete zajistit spolehlivý přenos dat, musíte si do přenášených dat přidávat informace navíc. Takových případů je spoustu, proto vzniklo spoustu specifikací, které se bohužel často překrývají, nebo jsou špatně navržené. Jejich základní přehled uvádím na konci zápisku.
Ačkoli by se mohlo zdát, že WS jsou velmi podobné distribuovaným objektům (DO), pravdou je opak. WS mají sice jazyk pro popis „rozhraní“, stejný komunikační protokol a podobný proces registrace a vyhledání služeb, ale tím podobnost končí. Dalo by se dokonce říci, že WS jsou ve své holé podstatě velmi chudé a oprosti vyspělým distribuovaným systémům, jako je například CORBA, nemohou vůbec obstát co se týká spolehlivosti, transakčního zpracování a dalších služeb.
Pakliže budu hovořit o tom, co u WS nejde, tak bych rád uvedl na pravou míru, že tím myslím koncepční nemožnost – lze použít jednu z mnoha specifikací, které se snaží tu či onu funkčnost do WS „napasovat“.
Klíčovou vlastností, která u WS chybí, je možnost vytvoření vzdálené instance objektu, následné volání metod na této instanci a konečně finální uvolnění objektu. Také není možné vrátit referenci na objekt – u WS se vždy pracuje s XML dokumenty, které sice mohou mít jakousi základní objektovou strukturu, ale spíše by se to dalo přirovnat k podpoře struktur v programovacím jazyce. Třídy nebo dokonce dědičnost – to jsou pojmy pro WS zcela neznámé.
WS nemohou nabídnout žádnou ze služeb, které vyžadují, aby byl zachycen stav. Například nemůžete mít WS, do které se přihlásíte (login), provedete požadované operace a poté se odhlásíte (logout). Samozřejmě, že takové webové služby mohou existovat, ale jejich existence pramení právě z nepochopení jejich podstaty. Do takové WS se musela „domontovat“ jakás takás podpora pro sezení.
Časté parsování XML dat při každém požadavku způsobuje, že WS jsou značně pomalé.
WS mají výhodu v tom, že nepotřebují protokol HTTP – můžete využít i jiných transportních protokolů, jako je například TCP/UDP, SMTP, JMS nebo MQ-Series. Nejpopulárnější je ovšem protokol HTTP a to z jednoduchého důvodu – mnoho firem používá WS jako komunikační bránu se světem (s internetem). To má pak často za následek situaci, kdy návrhář vnitřního systému zavrhne jiné možnosti transportu. Jistá výhoda z toho pramenící však nelze upřít – protokol HTTP projde většinou firewallů.
U WS se poměrně složitě řeší verzování služeb.
WS přes HTTP nejsou spolehlivým messagingovým řešením. Ačkoli HTTP protokol využívá TCP, což by měl být spolehlivý protokol, tato reliabilita je vzdálená potřebám WS. TCP například neřeší, když se jedna ze stran odpojí – pouze zajistí, aby všechna data prošla socketem na druhou stranu. Jestli byla data kompletní, ve správné formě nebo zda-li byla korektně zpracována – to už TCP řešit nemůže. Podobné je to s doručením zprávy právě jednou – aplikace může například selhat a poslat jednu a tutéž zprávu dvakrát a TCP si toho „ani nevšimne“. Je třeba tedy přidat informace, abychom docílili požadované spolehlivosti – a to WS ve své podstatě neřeší. Můžete vytvořit vlastní řešení, nebo implementovat některou ze specifikací
WS se poměrně složitě ladí.
Webové služby zažívají veliký úspěch. Může za to možná internet, možná trend ve větších společnostech – integrace a SOA. Každopádně programátoři, architekti i vedoucí IT by si neměli WS plést s DO.
Uvádím slíbený přehled specifikací, které obohacují WS o další důležité věci.
Abstraktní model používající XML, pomocí kterého WS publikují své politiky (bezpečnosti, QoS a podobně). Tato pravidla specifikují například použití zabezpečujících tokenů, šifrovacích algoritmů a podobně.
Specifikace definující společné politiky pro pravidla typu kódování textu, použitého jazyka, verzování a podobně.
http://www.ibm.com/developerworks/library/specification/ws-polas/
Definuje dva obecné mechanismy pro asociování politik s objekty, pro které jsou určeny.
Řeší to samé jako WS-Policy.
http://download.boulder.ibm.com/ibmdl/pub/software/dw/specs/ws-secpol/ws-secpol.pdf
Definuje multicast protokol, kterým se WS nacházejí. Některé komponenty Windows Vista, používají tuto specifikaci.
http://specs.xmlsoap.org/ws/2005/04/discovery/ws-discovery.pdf
Specifikace pro nacházení dokumentů (documents discovery), podobná technologie je použitá v produktu Microsoft DISCO.
http://www-128.ibm.com/developerworks/library/specification/ws-wsilspec/
Toto je sada specifikací, která se snaží řešit velmi komplexní a složitou záležitost, totiž v podstatě vytvořit prostředek pro vytvoření stavových WS (například může mít připojení k určitému prostředku, zachovávat stav). Specifikace se snaží dělat z WS distribuované objekty (DO – např. CORBA nebo DCOM). Pomineme-li fakt, že v tomto případě se jedná o nepochopení způsobu, jakým by se měly WS používat (SOA). WSRF stojí na těchto specifikacích:
Prakticky jedinou implementací je Globus Toolkit, také existuje projekt Apache Muse a pár pokusů v Perlu a .NETu. IBM WebSphere má jakou si podporu WSRF. (zdroj: Wikipedia)
V současnosti existuje tlak nahradit WSRF jinou sadou specifikací, které stojí na nových verzích WS-Transfer, WS-ResourceTransfer, WS-MetadataExchange, WS-Addressing a WS-Eventing. Velké firmy se na tom dohodly, tak uvidíme, který způsob bude preferovaný.
Umožňuje WS akceptovat a podávat subskripce (subscribe).
Má na starosti předávání adresních informací mezi WS, identifikuje se zdrojová i cílová WS, akce, ID z právy a podobně. Tato specifikace obsahuje funkce ze zastaralých WS-Routing a WS-Referal.
WS-Addressing je součástí JAX-WSA API, který je součástí JAX-WS od verze 2.1.
Zachycuje XML reprezentaci zdrojů tak, aby se mohly napasovat na WS infrastrukturu.
Popisuje způsob přidání podpisu a kryptovacích informací k SOAP zprávám. Pro sdílení takových konvencí může být využita specifikace WS-SecureConversation, podobně navazuje i WS-SecurityPolicy v otázkách bezpečnostních politik.
Řeší otázku bezpečnostních tokenů (vydávání, prolongaci a kontrolu).
Rozšiřuje WS-Trust o lepší možnosti sdílení bezpečnostních informací a interoperabilitu mezi vendory.
Obě specifikace řeší v podstatě to samé – spolehlivý přenos přes SOAP/HTTP. Druhá jmenovaná specifikace je novější a bohatší.
První jmenovaná řeší obecné věci ohledně koordinace, přičemž WS-Transaction na této specifikaci staví podporu pro distribuované transakce. Vystupují zde další (dílčí) specifikace jako je WS-AtomicTransaction nebo WS-BusinessActivity.
Je skupina specifikací řešící událostní messaging (publish/subscribe). Staví na specifikaci WS-Eventing a další klíčové subspecifikace jsou:
Skupina specifikací řešící správu a administraci WS.
Zdroje: