Čas webových služeb nadešel

Hlavní motivací pro použití webových služeb je interoperabilita. Tedy schopnost heterogenních systémů vyměňovat si ...


Hlavní motivací pro použití webových služeb je interoperabilita. Tedy schopnost
heterogenních systémů vyměňovat si informace bez pomoci různých prostředníků.
Je zjevné, že nastal čas se technologií, která interoperabilitě napomůže, vážně
zabývat.
Zjednodušení (záměrně nepoužíváme slovo vyřešení) problémů interoperability je
základním předpokladem pro levnou a rychlou integraci heterogenních systémů.
Prvním krokem k cíli byla specifikace jednoduchého XML protokolu, který byl
používán pro volání vzdálených procedur přes HTTP. Tento protokol, Simple
Object Access Protocol (SOAP), má za sebou dlouhou standardizační cestu ve W3C
a v současné době již splňuje všechny nároky poskytovatelů produktů pro webové
služby (web services).
Zároveň bylo třeba zautomatizovat tvorbu zpráv a umožnit jejich validaci. Za
tímto účelem byl, rovněž ve W3C, vytvořen jazyk pro popis rozhraní těchto
systémů -Web Services Description Language (WSDL). Pokusy o dosažení
interoperability mohly začít. V současné době je již její úroveň velmi dobrá, a
to i díky organizaci WS-I, která určuje hlavní cíle v této oblasti.

Architektura SOA
Samotná interoperabilita (za použití SOAP a WSDL) je však pro složitější
integrační projekty nedostatečná. Jakým způsobem budou komunikující systémy
zabezpečeny? Co dělat, když potřebujeme několik vzájemně souvisejících volání
dát do jednoho kontextu (či dokonce transakce)? Jak zajistit spolehlivou výměnu
zpráv? A co když integrované systémy komunikují asynchronně a ve velmi dlouhých
časových intervalech? Jakým způsobem se systémy vzájemně najdou a jak o své
existenci dají vědět okolnímu světu? A jak vlastně nejlépe použít webové
služby, abychom zase nezabředli do stále stejných integračních problémů
tentokrát obalených do špičatých závorek? S přibývajícími odpověďmi na tyto
otázky se začala formovat takzvaná Service-Oriented Architecture (SOA). Ta
definuje, zjednodušeně řečeno, co zprávy obsahují, jak jsou systémy schopny
komunikovat a kde jsou přístupné.
Obsah jednotlivých zpráv je popsán ve WSDL dokumentu. Dále existuje mnoho
specifikací zaměřených na konkrétní oblasti, jako je například bezpečnost
(WS-Security), spolehlivost (WS-ReliableMessaging), adresování a směrování
(WS-Addressing), transakce (WS-Transaction) a podobně. Každá z těchto
specifikací říká, co má XML zpráva obsahovat, aby byla zpracovatelná zamýšleným
způsobem (například spolehlivě doručena). Tyto specifikace se vzájemně velmi
dobře doplňují a tvoří modulární a rozšiřitelný systém.
To, jak jsou systémy schopny komunikovat, se dnes popisuje rovněž ve WSDL
dokumentu. Jedná se hlavně o specifikaci transportních mechanismů (protokolů),
o vyžadované úrovně bezpečnosti, o schopnosti spolehlivého doručování zpráv, o
XML protokoly apod. V této souvislosti se rovněž začíná používat WS-Policy
framework, který dále rozšiřuje schopnosti systémů popsat svoje komunikační
detaily. Pro výměnu těchto informací se má v blízké budoucnosti prosadit
specifikace WS-MetadataExchange.

Kde je služba
Zbývá zjistit, kde se určitá služba nachází. Pro tento účel se používají dva
mechanismy. Máme-li malý počet služeb, je nejjednodušší zpřístupnit jejich WSDL
dokumenty na dohodnutém místě (URL). Samotný WSDL dokument poté obsahuje
informaci o fyzickém umístění služby. Je zřejmé, že při větším počtu služeb je
tento přístup příliš zranitelný. Strategičtější je použít dedikovanou službu,
která umožňuje registraci a vyhledávaní jiných služeb. Lze tu využít další
specifikaci Universal Description, Discovery, and Integration (UDDI). Službám
nabízejícím tuto funkcionalitu se říká Registry. Ještě dodejme, že pro velmi
dynamické systémy, například systémy vzájemně komunikujících přenosných
zařízení, se nehodí ani jeden z výše uvedených přístupů, a proto se pracuje na
další specifikaci jménem WS-Discovery.

Fáze nasazení SOA
Prvním úkolem při nasazování je příprava systémů pro integraci. Je tedy třeba
navrhnout WSDL dokumenty, které v podstatě definují funkční fasádu, pod kterou
budou systémy zveřejněny. Je velmi důležité, aby tato fasáda byla navržena v
souladu s vlastnostmi SOA. Fakt, že používáme WSDL a SOAP pro komunikaci mezi
dvěma systémy, ještě zdaleka neznamená, že jsme vyrobili dobré webové služby.
Přípravná fáze by se měla řídit hlavně předpokládaným použitím daného systému.
Přímočarý export původního API systému do WSDL lze téměř vždy považovat za
špatný nápad. Výjimku tvoří snad jen messagingové systémy, které definují
striktní sémantiku. Když tedy chceme propojit například JMS s aplikací napsanou
ve Visual Basicu, musíme značnou část JMS API zveřejnit ve formě WSDL dokumentů.
Jakmile jsou systémy připraveny pro integraci, je vhodné je zorganizovat
například pomocí již zmíněné UDDI registry. Fáze vlastní integrace pak v
podstatě znamená implementaci kódu, který dané systémy propojí. V drtivé
většině případů jde o jednoduché skripty.
Poslední fází je implementace byznys procesů. Z pohledu SOA je byznys proces
jazykově nezávislou orchestrací několika webových služeb. Jsou to právě byznys
procesy, které představují největší potenciál ve světě SOA. Nutno ale dodat, že
čas těchto orchestrací teprve přijde. Mnohdy je nejlepší, alespoň
metodologicky, začít odvozovat požadavky na integrované systémy (respektive na
jejich WSDL dokumenty) právě s ohledem na to, v jakých procesech budou
používány.

SOA v praxi
Při rozhodování, zda použít SOA v konkrétním integračním projektu, je potřeba
mít na paměti jeden důležitý fakt: Zpracovávání XML zpráv nepatří mezi
výpočetně jednoduché úkoly, a tudíž nelze očekávat srovnatelnou rychlost
komunikace. XML zprávy jsou totiž podstatně objemnější a nejsou plně
strukturované. Tento problém je koncepční.
S určitou nadsázkou lze ovšem onu pomalost označit za chvályhodnou, protože
alespoň nutí programátory více přemýšlet o návrhu WSDL dokumentů. V praxi se
lze jen zřídka setkat s případy, kdy je nízká výkonnost příčinou volby jiného
integračního řešení. Spíše naopak bývá příčinou lepšího (jednoduššího) návrhu.
Mírná ztráta na výkonnosti je ale jen malou daní za výhody, které SOA přináší
programátorům, architektům a byznysu. Integrace pomocí webových služeb je totiž
implementačně a návrhově jednodušší, flexibilnější, levnější (mnohdy řádově) a
hlavně otevírá nové možnosti pro mezifiremní komunikaci. Taková komunikace
navíc není pouze technickou záležitostí, ale také záležitostí nových byznys
modelů.
Autor pracuje jako VP of Engineering u společnosti Systinet.

Významné vlastnosti SOA
Narozdíl od starších distribuovaných architektur typu CORBA je SOA
minimalistická a rezignuje na mnoho ambicí, které se mimochodem v praxi stejně
nikdy nepodařilo naplnit. Jednou z nich byl například předpoklad, že by
distribuovaný systém měl zajistit maximální transparentnost faktu distribuce.
Programátoři, ale ani administrátoři nebo manažeři se neměli starat o to, že
najednou používají aplikaci rozmístěnou na několika serverech, které jsou
propojeny počítačovou sítí. Tento předpoklad se ukázal jako naivní. Naopak, v
distribuovaném systému musí programátor počítat s tím, že rozhraní aplikací má
být úsporné, aby se zbytečně nepřenášelo deset malých zpráv, když lze přenést
jednu větší. Vzájemná komunikace musí být nestavová, aby se předešlo problémům
s výpadky sítě. Distribuované transakce by se neměly používat vůbec, a když už
je to nutné, rozhodně by to neměly být klasické transakce ACID. Datový model
zpráv by měl být rozšiřitelný, aby se minimalizovaly problémy spojené s evolucí
aplikací. Dalším významným rozdílem je, že SOA staví na technologiích
internetu. Pro transport zpráv jsou nejčastěji používány protokoly HTTP, FTP,
nebo SMTP. Lze tedy s úspěchem používat zavedené produkty, jako jsou DNS
servery, HTTP proxy, firewally apod. Internet jako prokazatelně škálovatelný
distribuovaný systém poskytuje SOA dokonalou komunikační infrastrukturu, kterou
žádný ze starších distribuovaných systémů nedokázal smysluplně využít.









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