Sémantické služby – příliš vzdálená budoucnost? (1/3)

Přestože webové služby jsou na světě již nějaký ten pátek a skloňují se takřka ve všech pádech, již z kolébky si nesou některé problémy, jejichž mantinely začínáme velmi zblízka pociťovat. Tento miniseriál si klade za cíl seznámit čtenáře s problematikou „nové“ generace webových služeb, které by tyto problémy mohly vyřešit...

Dnes si představíme v rychlosti koncept klasických webových služeb. Ti z nás, co již s webovými službami pracují, se dnes možná mnoho nového nedozví.

Klasické webové služby

Jak tedy bylo řečeno, koncept webových služeb je relativně nový, avšak byl velmi rychle adoptován. Snahy o integraci aplikací samozřejmě existovaly ještě před webovými službami (WS). Většina předchozích koncepcí ale měla určité nedostatky, které jim bránily stát se široce používaným standardem (např. standard EDI definoval spíše výměnu dat, COM+ a jeho předchůdci jsou svázáni s jednou platformou, CORBA je příliš těžkopádný, EJB přišel jen o málo dříve než webové služby, navíc je svázán s platformou Java, kterou není vždy vhodné použít). Mnoho řešení bylo proto prováděno ad-hoc.

Oddělení rozhraní webových služeb od jejich implementace, stejně jako dodržování vrstvení u protokolů, kterých WS mohou využívat, a požadavek na využívání již existujících a široce podporovaných technologií jsou patrně těmi nejdůležitějšími faktory, které stojí za úspěchem rozšíření WS jako standardu a rovněž jako základny pro další integraci aplikací (viz např. definice SOA).

Technický popis

Samotná webová služba je navenek reprezentována rozhraním, které popisuje protokol WSDL (viz dále). Rozhraní je zajištěno existencí tzv. wrapperu, který de facto umožňuje, aby se k rozhraní připojovali klienti. Wrapperem může být nějaký webový server, který má příslušné moduly umožňující zapouzdření byznys logiky, jež tvoří jádro webové služby. Před světem je tak nejen uchráněna implementace byznys logiky, ale vlastně nezáleží ani na wrapperu, ale pouze na rozhraní, které wrapper nabízí (např. aplikační logika může být napsána v Javě, v Pythonu či C# a může běžet na webovém serveru založeném na Apache či MS ISS, ale navenek bude tato služba zcela identická). Následuje popis jednotlivých nosných specifikací.

SOAP

SOAP je (dle Wikipedie) protokol pro výměnu zpráv (založených na XML) na počítačových sítích, obyčejně využívající protokol HTTP. SOAP umožňuje popsat samotnou zprávu, způsob jejího zpracování, datové typy ve zprávě použité (včetně definice vlastních). Specifikace 1.2 již přímo definuje vazbu na protokol HTTP, a mj. již upouští od původního významu zkratky, kterou SOAP představoval (Simple Object Access Protocol), a dále již tento pojem definuje jen jako technický termín.

SOAP se v prostředí webových služeb využívá jako prvek, který zapouzdřuje vlastní zprávu. Jinak řečeno, SOAP je jakousi obálkou, která obsahuje přenášená data a jejich popis. SOAP je možno využívat ale i za účelem, pro který byl původně navržen, tedy přímo k volání vzdálených funkcí (RPC). Rozdíl mezi těmito dvěma koncepcemi (a jejich deriváty) je v tom, že zatímco v prvním případě je SOAP chápán jako přenášený dokument, v druhém případě plní funkci zprostředkovatele komunikace (v režimu dotaz-odpověď).

Roli SOAP v prostředí webových služeb nejlépe ilustruje příklad, modelová komunikace je k dispozici na příslušném webu.

WSDL

WSDL (Web Services Description Language) je jazyk sloužící pro popis webové služby. Každá webová služba má takovýto svůj popis reprezentován souborem. Soubor WSDL reprezentuje tu část specifikace WS, která popisuje funkcionalitu webové služby ve formě čitelné strojem. Jde tedy o dodatečnou informaci (dodatečnou v tom smyslu, že k vlastnímu zavolání služby a převzetí výsledku není za splnění několika předpokladů technicky nutné WSDL dokument použít), která umožňuje klientské aplikaci samu sebe volané službě částečně přizpůsobit. V opačném případě by klientská aplikace musela být napsána „na míru“ webové službě (např. by musela přímo obsahovat URL služby) a musela by se měnit při každé sebemenší změně rozhraní této služby.

WSDL dokument lze rozdělit na dvě části, z nichž jedna popisuje obecné vlastnosti služby (abstraktní část) a druhá (konkrétní) vazbu na implementaci služby.

Abstraktní část popisuje především logické skupiny operací, které jsou v rámci služby dostupné, a také definuje zprávy (včetně jejich pořadí), které si klient a server během komunikace musí vyměnit. Konkrétní část pak obsahuje vazby (což je vlastně popis konkrétní implementace služby s odvolávkami na operace, které jsou definované v abstraktní části, a konkrétně použitých protokolů) a porty (neboli konkrétní místa, kde je vazba dostupná).

Ukázku velmi jednoduchého WSDL lze najít např. zde.

UDDI

UDDI (Universal Description Discovery and Integration) je další nosnou specifikací, která se pro webové služby používá. Jestliže protokol SOAP určuje podobu a popis přenášených dat, WSDL popisuje způsob komunikace se službou, pak UDDI nabízí databázi webových služeb a informace o jejích poskytovatelích, neboli o tom, kde lze službu daného typu nalézt.

Na UDDI lze nahlížet dvěma způsoby. Jednak UDDI obsahuje část specifikační, neboli popis formátu, ve kterém jsou uložena data popisující služby a jejich poskytovatele. Dále lze pod pojmem UDDI rozumět také konkrétní adresář (veřejný či „intranetový“). Filozofií UDDI je vytvořit celosvětovou soustavu takovýchto veřejných adresářů (paralelu lze hledat např. u systému DNS).

Cílem takovéto struktury je pak globální adresář, ve kterém budou poskytovatelé své služby registrovat a uživatelé v nich budou vyhledávat (a to buď prostřednictvím API daného adresáře nebo prostřednictvím jeho webového rozhraní).

Závěrem

V příštím díle se podíváme na nedostatky této koncepce a povíme si něco o sémantice.

20. 7. 2007

Autor: