Metainformation systems and Web services (Metainformační systémy a webové služby)

Ing. Pavel Děrgel, Ing. Michal Šeliga
Institut geoinformatiky
VŠB - Technická univerzita Ostrava
tř. 17. Listopadu
708 33 Ostrava - Poruba
E - mail: pavel.dergel.st@vsb.cz, michal.seliga.st@vsb.cz

Abstract

This article should outline the main idea of an metainformation system based upon the web services technology. Discussed will be the architecture, advantages and disadvantages of such an approach as well as the possibilities of further development. At least the practical aspects of using such a system will be described.

Abstrakt

V tomto příspěvku bude nastíněna hlavní myšlenka metainformačního systému, postaveného na webových službách. Bude rozebrána architektura takového systému, výhody a nevýhody této architektury a možností dalšího vývoje. Dále budou popsány možností využití takového systému v praxi.

Úvod

V současné době existuje velké množství úzce specializovaného softwaru, který řeší určitou problematiku. Velkou nevýhodou je obvykle velmi vysoká cena za specializovaný produkt, který obvykle obsahuje množství funkcí, které zůstávají nevyužity. Dalším problémem je přístup k datům, který je neméně nákladný.

Dobrým řešením výše zmíněných problémů je využití systému, založeného na webových službách. Tím odpadá nákup drahého softwaru. Zákazník platí pouze za použití služby, nikoliv za software, který tuto službu zprostředkovává.

Koncept webových služeb je dalším krokem objektového designu podnikových aplikací. Cílem je vytváření uzavřených funkčních částí kódu (komponent), které spolu navzájem komunikují přes internetové komunikační protokoly. Takto jsou spojovány ve flexibilní aplikace, kdy nehraje roli fyzické umístění ani platforma, na které jsou provozovány.

Metainformační systém umožňuje tyto služby registrovat, vyhledávat a realizovat základní komunikaci s nimi, ať už po stránce funkční, tak i ekonomické.

Na klientovi (resp. klientské aplikaci) je pouze využít služeb metainformačního systému, vyhledat služby, které vyhovují požadavkům uživatele a jejich funkcionalitu vhodným způsobem propojit. Uživatel má možnost na základě těchto webových služeb v podstatě poskládat kompletní informační systém, který přesně vyhovuje jeho požadavkům, přičemž ušetří za nákup, či vývoj speciálního softwaru. Tento přístup přináší úplně nový rozměr do oblasti vývoje informačních systémů.

Webové služby přicházejí do života postupně, s rostoucí nabídkou produktů pro jejich vytváření a zvyšující se vyspělostí jednotlivých standardů. Právě v této oblasti dochází k bouřlivému rozvoji. V podstatě také každá silnější IT firma přichází se svými nástroji pro vytváření a provoz webových služeb (IBM, Microsoft, HP, SUN a další) včetně některých specifických prvků, ať už v podobě před připravených komponent nebo jemných aplikačních závislostí.

Základní koncept informačních systémů "příští" generace je vybudování systému, ve kterém budou jednotlivé webové služby registrovány a dynamicky vyhledávány ve chvíli, kdy bude jiná aplikace vyžadovat jejich funkce. Tak bude pro určitou funkci vybrána právě nejvhodnější aplikace, i když z pohledu systému nebo uživatele budou tyto rozhodovací operace neznatelné.

Cílem tohoto příspěvku je nastínit možnou architekturu výše popsaného systému.

Webové služby

Webové služby jsou pojmem, o kterém se stále hodně hovoří. Ale již málo kde se dočtete, že tato vyvíjející se technologie si klade za svůj primární cíl standardizaci komunikačních prostředků, které umožňují bezproblémovou komunikaci mezi různými systémy na různých platformách. Firma Microsoft na nich založila svoji novou architekturu .NET a SUN hovoří o nové generaci distribuovaných systémů. Jinými slovy, webové služby se chystají nahradit dosavadní standardy používané ke tvorbě distribuovaných systémů jako jsou např. RPC, COM, DCOM, ActiveX, CORBA, RMI ... Jeden z důvodů proč tomu má tak být je ten, že webové služby musí vycházet z následujících principů:

Je zřejmé, že webové služby pokrývají poměrně široké spektrum problémů z oblasti IS i IT, se kterými se musí vypořádat a k tomu všemu podle výše zmíněných pravidel. K řešení jednotlivých dílčích problémů jsou navrhnuty a neustále navrhovány patřičné standardy, kterých je již poměrně hodně, jmenujme zde alespoň několik základních HTTP, SOAP, XML, UDDI, WSIL, WSDL, WS-Security ...

Jako komunikační protokol je používaný výhradně protokol HTTP nebo jeho zabezpečená verze HTTPS. Jde o protokol, který vznikl před více než dvaceti lety a je ověřen mnoha lety masivního používání Webových prohlížečů. Je to vyzrálý protokol, který je implementován prakticky na všech dnes používaných aplikačních platformách. V dohledné době nelze v žádném případě očekávat jeho nahrazení nebo vytlačení některým z konkurenčních standardů. Pří návrhu webových služeb se navrhuje používání HTTP protokolu ve verzi 1.1, alternativně za použití SSL protokolu pro zabezpečení důvěrnosti komunikace a autentizace mezi oběma stranami. Pro ověření druhé strany, v bezpečnostně nejcitlivějších případech, lze použít klientský certifikát vydaný důvěryhodnou certifikační autoritou.

Aby komunikace mezi poskytovatelem webové služby a jejím klientem byla co nejjednodušší a platformně nezávislá byla dána přednost standardu SOAP před vyspělými, ale nedostatečně rozšířenými standardy jako jsou DCOM, RMI, CORBA apod.

SOAP je ve své podstatě pouze velmi jednoduchý komunikační protokol určený pro přenos XML dokumentů, které mohou případně obsahovat parametry volání služeb. Výsledná komunikace pak spočívá v odeslání potřebných dat zapouzdřených do XML a v přijetí odpovědi v obdobném formátu.

Jelikož filozofie webových služeb mluví o jednotlivých službách jako o stavebních kamenech celého systému na této bázi vytvořeného vzniká reálná potřeba se rychle orientovat a vyhledávat mezi existujícími a dostupnými službami. K tomuto účelu firmy IBM a Microsoft vyvinuly standard UDDI (Universal Description, Discovery and Integration), který poskytuje veřejnou databázi existujících služeb. UDDI je vlastně taky služba a je zařazena jako volitelná součást instalace Windows 2003. Tato služba umožňuje registraci nových služeb i jejich vyhledávání, ale jelikož jde o veřejnou databázi nelze zaručit důvěryhodnost ani relevantnost jednotlivých záznamů. Proto výše zmíněné společnosti vyvinuli další standard WSIL, který je založen na opačném principu než UDDI. V tomto případě poskytovatel nehledá klienty, ale naopak klient hledá poskytovatele a jeho služby. Popis služeb je uložen v souboru inspection.wsil, který se nachází vždy v hlavním adresáři web serveru poskytovatele.

Nyní víme jak najít požadovanou službu a jak ji zavolat, ale to vše je nám k ničemu pokud neznáme aplikační rozhraní implementované danou službou, které je nezbytné pro efektivní využívání webových služeb. Při popisu rozhraní je nutné definovat jaké informace a v jakém formátu jsou požadovány na vstupu a co lze očekávat na výstupu. Tento popis slouží jako dokumentace rozhraní na základě kterého lze generovat kód, který tyto služby a informační zdroje využívá. Pro popis rozhraní byl vyvinut jazyk WSDL (Web Services Description Language), založený na XML a hojně využívající standardy XML Namespaces a XML Schema. WSDL 1.1 je v podstatě XML popis API rozhraní nezávislý na platformě a operačním systému. WSDL je fakticky XML dokument popisující rozhraní služeb, jejich zprávy a jakým způsobe lze volat definované zprávy či jaké síťové protokoly lze použít při komunikaci se službami. To, že WSDL je navrženo obecně podtrhuje i to, že pouze jedna jeho část popisuje jak propojit danou službu se standardy jako jsou SOAP 1.1, HTTP a MIME.

Webové služby se ani zdaleka nedají považovat za již probádanou oblast, ale přesně naopak, je to zcela nová věc, která je nyní ve fázi intenzivního vývoje, a která hledá své standardy a uplatnění na poli vývoje moderního softwaru.

Architektura metainformačního systému

Předtím než budete seznámeni se základní architekturou metainformačního systému, zkusíme nastínit co to vlastně metainformační systém je. Jedná se o takový informační systém, jež je složen z komponent, které jsou propojeny dle pravidel poskytovatelů jednotlivých komponent a klientů využívajících služeb takového systému. Jinými slovy, klientovi je dána do rukou možnost navrhnout si vlastní informační systém, který mu bude nabízet jen tu funkcionalitu, kterou on sám požaduje. Pod komponentou si lze představit určitou webovou službu nebo klidně i skupinu služeb, které na základě formalizovaného vstupu vygenerují požadovaný výstup, opět ve formalizovaném tvaru. Takhle to zní poměrně jednoduše, ale tento systém musí zajistit mino jiné výběr patřičných služeb a jejich následné propojení v podobě jakého si "vláčku", na jehož konci klient obdrží odezvu informačního systému na svůj požadavek.

Obr. 1 Architektura metainformačního systému

Jedna z možných architektur takového systému je znázorněna na obrázku 1. Tento obrázek je již na první pohled rozdělen na tři části, které symbolizují komunikaci a vztahy mezi jednotlivými částmi systému. Přímo mezi sebou mohou komunikovat vždy jen komponenty, které jsou ve shodné nebo sousední úrovni. Horní a prostřední část představuje vzdálenou stranu serverů a spodní část představuje stranu klientů systému.

Strana serverů stojí za podrobnější popis. Na všechny komponenty z nichž se strana serverů skládá lze pohlížet totiž jako na webové služby, jelikož splňují všechny podmínky na ně kladené. Z tohoto důvodu mohou být registrovány ve veřejných (UDDI) i soukromých (WSIL) databázích. Další výhodou tohoto přístupu je, že se mohou hierarchicky spojovat ve větší celky řešící komplexnější sadu problémů. Tato architektura řeší otázky plateb za využité či zprostředkované služby nebo problematiku jednoznačné identifikace komunikujících stran jen rámcově. Ale s ohledem na současný vývoj lze říci, že k úplnému řešení těchto problémů bude použit zatím jediný a pravděpodobně na chvíli i poslední standard WS-Security, který byl přijat výborem pro standardizaci organizace OASIS i největšími poskytovateli jako je RSA Security, Microsoft, IBM a BEA. Bohužel v současné době jsou dostupné pouze komerční implementace tohoto standardu jako např. software RSA BSAFE Secure-WS.

MetaServer

I přesto, že název komponenty obsahuje slovo "server" jedná se stále o službu. Hlavní úkolem této služby je ověřovat klienty vstupující do interakce se systémem a ukládat informace s nimi související. Dále shromažďuje informace o jednotlivých komponentách a službách do systému začleněných. Nad těmito daty je dále možno provádět různé analýzy, na základě, kterých mohou být struktura i datové toky v systému optimalizovány.

Z důvodů zvýšení robustnosti systému se předpokládá, že v systému bude několik funkčních MetaServerů, které si budou navzájem vyměňovat určitá data, a v případě, že dojde k výpadku některého z nich bude zastoupen jiným. Zjednodušeně řečeno MetaServer je řídící logikou pro určitou část systému, která muže být v případě výpadku zastoupena jinou.

PaymentServer

Jak již sám název napovídá, jedná se o část systému, jejímž úkolem je řešit otázky plateb za užívání respektive poskytování služeb. Tyto platby a převody budou realizovány na základě smluv či dohod poskytovatelů služeb a klientů mezi provozovatelem metainformačního systému. K tomuto, aby bylo možné tento mechanizmus realizovat je zapotřebí mít k dispozici prostředek pro jednoznačnou identifikaci klientů a služeb. Touto problematikou se zabývá standard WS-Security. V současné době jsou veškeré platby řešeny přímo mezi klientem a poskytovatelem, což znamená velkou režii pro obě strany, která díky PaymentServeru odpadne.

MetaKlient

Úkolem MetaKlienta je v podstatě zprostředkovávat flexibilní rozhraní mezi klientem (koncovou uživatelskou aplikací) a webovými službami. Veškerá komunikace s klientskou stranou probíhá prostřednictvím XML dokumentů, což zaručuje otevřenost a vysoký stupeň standardizace. MetaKlient by měl pružně reagovat na požadavky klienta, vyhledávat v databázi webových služeb takové služby, které nejvíce odpovídají jeho požadavkům, popřípadě vhodně kombinovat funkcionalitu několika služeb.

Dalším důležitým úkolem MetaKlienta je zvyšovat robustnost systému v tom smyslu, že pokud se stane, že nějaká služba přestane fungovat, pokusí se automaticky najít a použít vhodnou náhradní službu aniž by to koncový uživatel zjistil.

Díky výše popsané architektuře je možné, aby uživatel, popřípadě firma mohli jednoduchým způsobem zabudovat funkcionalitu metainformačního systému do svého informačního systému, pokud již existuje, popřípadě vyvinout jednoduchou specifickou aplikaci, která bude služeb metainformačního systému využívat. Tím odpadnou náklady na vývoj nebo nákup specializovaného softwaru a navíc se otevřou nové možnosti pro budování firemního informačního systému .

Klient

Klient není z pohledu návrhu architektury nějak zvlášť zajímavý. Může být tvořen libovolnou aplikací, která umí pracovat s daty v definovaném XML formátu, tzn. Servlet, Webový prohlížeč, Informační sytém ...

Praktické využití

Využití myšlenky a potenciálu webových služeb přináší do tvorby moderních informačních systémů zcela nový rozměr. Celá technologie je postavena na distribuci jednotlivých částí systému v počítačové síti (v případě webových služeb internetu) a umožňuje systém dynamicky rozvíjet podle toho, jaké služby jsou momentálně k dispozici. V následujícím příkladě je zachycen scénář jedné jednoduché konkrétní situace a možnost jejího řešení s využitím metainformačního systému.

Požadavky klienta

Zobrazit mapu určené oblasti na základě souřadnic, přijatých z terénního měření pomocí GPS.

Obr. 2 Sekvence zpracování požadavku na metainformační systém

Služby k dispozici

Řešení

Uživatel zadá klientské aplikaci požadavek na zprostředkování funkce pro zobrazení mapy na základě souřadnic z GPS. Klientská aplikace zformuluje požadavek ve formě XML pro Metaklienta. Jeho úkolem je vyhledat v UDDI databázi služby, které odpovídají požadavkům uživatele, popřípadě propojit funkcionalitu dvou či více služeb tak, aby co nejvíce požadavku vyhovovaly a celkový výsledek opět ve formě XML dokumentu předá klientské aplikaci. Ta v konečné fázi zobrazí výsledek požadavku uživateli. Scénář průběhu celé operace je znázorněn na obrázku 2.

Závěr

Oblast webových služeb je v současné době stále ještě předmětem intenzivního vývoje, ačkoliv samotná myšlenka je již poměrně stará. Velkou nevýhodou je nedostatečná standardizace, především v oblasti bezpečnosti. V dohledné době se ale dá očekávat zlepšení této situace, protože jisté standardy již existují, bohužel však jsou zatím k dispozici pouze komerční implementace.

Cílem tohoto příspěvku bylo nastínit možnosti využití webových služeb a popsat návrh metainformačního systému, který je na této myšlence založen.

Dá se říci, že webové služby jsou novým fenoménem v oblasti vývoje především internetových aplikací. Dlouhodobě je potřeba roli webových služeb chápat jako technologii a koncept pro vytváření moderních informačních systémů, bez ohledu na to, jestli výsledkem má být vizuální webová aplikace nebo vnitřní funkce v rámci podnikového systému.

Webové služby přicházejí do života postupně a je jen otázkou času, jak se vyvinou standardy s nimi související.

Literatura

  1. EKONOM.IHNED.CZ, Pavel Ranš [online]. 2002. Dostupný na WWW:<http://tematickeprilohy.ihned.cz/>
  2. Microsoft UDDI Business registry node, [online]. 2003. Dostupný na WWW: <http://uddi.microsoft.com/>
  3. UDDI, [online]. 2003. Dostupný na WWW: <http://www.uddi.org/>
  4. IBM UDDI, [online]. 2003. Dostupný na WWW: <https://uddi.ibm.com/>
  5. OASIS Web Services, [online]. 2003. Dostupný na WWW: <http://www.oasis-open.org/>
  6. Web Services Architect, [online]. 2003. Dostupný na WWW: <http://www.webservicesarchitect.com/content/articles/modi01.asp>
  7. Web Services, , [online]. 2003. Dostupný na WWW: <http://www.w3.org/>