Přehled o významu XML webových služeb pro vývojáře s úvodem do problematiky SOAP, WSDL a UDDI.

Co je Webová služba XML?

Webové služby XML jsou základní stavební bloky pro přechod k distribuované výpočetní technice na Internetu. Otevřené standardy a zaměření na komunikaci a spolupráci mezi lidmi a aplikacemi vytvořilo prostředí, ve kterém se webové služby XML stávají platformou pro integraci aplikací. Aplikace jsou konstruovány k využívání více webových služeb XML z různých zdrojů a jejich spolupráci, bez ohledu na to, kde jsou umístěny nebo jak byly implementovány.

Existuje pravděpodobně tolik definicí webových služeb XML, kolik je podniků, které je staví. Většina těchto definicí však má společné následující:

• Webové služby XML poskytují webovým uživatelům užitečné funkce prostřednictvím standardního webového protokolu. Ve většině případů se používá protokol SOAP.
• Webové služby XML poskytují způsob, jak dostatečně podrobně popsat svoje rozhraní, aby uživatelé mohli stavět klientské aplikace, které s nimi mohou komunikovat. Tento popis je obvykle poskytován ve formě dokumentu XML nazvaného Web Services Description Language (WSDL).
• Webové služby XML jsou registrované, takže potenciální uživatelé je mohou snadno nalézt. To zajišťuje specifikace Universal Discovery Description and Integration (UDDI).

V tomto článku budou popsány všechny tyto tři technologie, ale nejdříve si vysvětlíme, proč se o webové služby XML máme zajímat.

Jednou z hlavních výhod architektury webových služeb XML je to, že programy mohou být napsány v různých jazycích na různých platformách a že spolu navzájem komunikují standardním způsobem. Ti z vás, kteří pracujete v oboru delší dobu, si nyní jistě říkáte: „Počkat, neslyšel jsem stejné sliby od CORBA a předtím od DCE? Je v tom nějaký rozdíl?“ Prvním rozdílem je skutečnost, že SOAP je podstatně jednodušší než dřívější přístupy, takže překážky zavádění standardům vyhovující implementace SOAP jsou podstatně menší. Paul Kulchenko udržuje seznam implementací SOAP [ http://www.soapware.org/directory/4/implementations ], který v současné době obsahuje 79 položek. Najdete zde implementace SOAP od většiny velkých softwarových firem, což se dalo očekávat, ale naleznete zde i mnoho implementací postavených a udržovaných jediným vývojářem. Další podstatnou výhodou webových služeb XML proti předcházejícím pokusům je to, že pracují se standardními webovými protokoly – XML, HTTP a TCP/IP. Velké množství firem již má vybudovanou webovou infrastrukturu a má lidi se znalostmi a zkušenostmi s její údržbou. Náklady na zavedení webových služeb XML jsou tak podstatně nižší než u předcházejících technologií.

Webovou službu XML jsme definovali jako softwarovou službu vystavenou na web prostřednictvím protokolu SOAP, popsaného souborem WSDL a registrovaného v UDDI. Následuje další logická otázka: „Co mohu s webovými službami XML dělat?“ První webové služby XML měly tendenci být informačními zdroji, které mohou být snadno začleněny do aplikací – ceny akcií, předpovědi počasí, sportovní výsledky atd. Je snadné si představit celou třídu aplikací, které mohou být postaveny k analýze a shromažďování žádaných informací a jejich prezentaci různými způsoby; můžete mít například tabulku aplikace Microsoft® Excel, která shrnuje celou vaši finanční situaci – akcie, spoření, bankovní účty, půjčky atd. Pokud jsou tyto informace dostupné prostřednictvím webových služeb XML, může je Excel neustále aktualizovat. Některé informace mohou být poskytovány zdarma, jiné můžete získat pouze když si předplatíte určitou službu. Většina těchto informací je již na webu dostupná, ale webové služby XML k nim zajistí snadnější a spolehlivější programovaný přístup.

Nabídka existujících aplikací ve formě webových služeb XML umožní uživatelům stavět nové, výkonnější aplikace využívající webové služby XML jako stavební bloky. Uživatel může například vyvinout nákupní aplikaci k automatickému získání cenových informací od různých prodejců, která uživateli umožňuje vybrat prodejce, předat objednávku a pak sledovat dodávku až do jejího přijetí. Prodejní aplikace může zase navíc k nabídce služeb na webu využít webové služby XML ke kontrole úvěru zákazníka, provádět příjem peněz z účtu zákazníka a zajistit dodávku zboží přes dodávkovou službu.

V budoucnu budou patřit mezi nejzajímavější webové služby XML ty, které budou podporovat aplikace využívající web k věcem, jaké nyní nejsou možné. Jednou ze služeb, které bude podporovat projekt Microsoft .NET My Services [ http://msdn.microsoft.com/library/default.asp?url=/nhp/Default.asp?contentid=28001179 ] bude kalendářová služba. Pokud váš zubní lékař nebo automechanik vystaví svoje kalendáře prostřednictvím této webové služby XML, budete si s nimi moci sjednat návštěvu on-line nebo oni sami si mohou naplánovat vaši návštěvu za účelem pravidelné prohlídky přímo ve vašem kalendáři, pokud si to budete přát. Je snadné si představit stovky dalších aplikací, které by mohly být vytvořeny k programování webu.

Další informace o webových službách XML a aplikacích, které vám pomohou při jejich stavbě, najdete na domovské stránce webových služeb [ http://msdn.microsoft.com/library/default.asp?url=/nhp/Default.asp?contentid=28000442 ] MSDN.

SOAP

SOAP je komunikační protokol pro webové služby XML. Je-li SOAP popisován jako komunikační protokol, vzpomene si řada lidí na DCOM nebo CORBA a začne se ptát: „Jak SOAP provádí aktivaci objektů?“ nebo „Jak SOAP využívá službu jmenování (naming service)?“ I když implementace SOAP tyto věci pravděpodobně obsahuje, standard SOAP je nespecifikuje. SOAP je specifikace, která pro zprávy definuje formát XML – a to je vše, co je požadováno pro jednotlivé části specifikace. Máte-li dobře vytvořený fragment XML vložený mezi řadu prvků SOAP, máte zprávu SOAP. Je to jednoduché, že?

Existují ještě další části specifikace SOAP, které popisují, jak vyjádřit programová data ve formě XML a jak SOAP využít, aby prováděl vzdálené volání procedur (Remote Procedure Calls). Tyto volitelné části specifikace se používají k implementaci aplikací ve stylu RPC, kde zpráva SOAP, obsahující volatelnou funkci a parametry předávané funkci, je zaslána klientem a server vrací zprávu s výsledky vykonané funkce. Většina současných implementací SOAP podporuje aplikace RPC, neboť programátoři, kteří tvoří aplikace COM nebo CORBA, rozumí stylu RPC. SOAP rovněž podporuje aplikace ve stylu dokumentu, kde zpráva SOAP je pouze obalem kolem dokumentu XML. Aplikace SOAP ve formě dokumentu jsou velmi pružné a mnoho nových webových služeb XML využívá tuto pružnost ke stavbě služeb, které by bylo obtížné implementovat pomocí RPC.

Poslední volitelná část specifikace SOAP definuje, jak má vypadat zpráva HTTP, která obsahuje zprávu SOAP. Tato vazba na HTTP je důležitá, neboť protokol HTTP je podporován téměř všemi současnými operačními systémy (i mnoha nepříliš současnými OS). Vazba HTTP je volitelná, ale téměř všechny implementace SOAP ji podporují, neboť to je jediný standardizovaný protokol pro SOAP. Z tohoto důvodu vznikla obecně mylná představa, že SOAP vyžaduje HTTP. Některé implementace podporují přenosy MSMQ, MQ Series, SMTP nebo TCP/IP, ale většina současných webových služeb XML používá HTTP, neboť je všudypřítomný. HTTP je základní protokol webu a většina organizací má síťovou infrastrukturu, která podporuje HTTP, a lidi, kteří s tímto protokolem umějí pracovat. V současné době je také pro HTTP snadno dostupná infrastruktura zabezpečení, monitorování a vyrovnávání zátěže.

Hlavním zdrojem nedorozumění při zahájení práce se SOAP je rozdíl mezi specifikací SOAP a mnoha implementacemi specifikace SOAP. Většina lidí používajících SOAP nepíše zprávy SOAP přímo, ale používá k tvorbě a rozboru zpráv SOAP nástrojový kit SOAP (toolkit). Tyto toolkity obecně převádějí volání funkce z určitého jazyka do zprávy SOAP. Microsoft SOAP Toolkit 2.0 například převádí funkční volání COM do SOAP a Apache Toolkit převádí funkční volání JAVA do SOAP. Typy funkčních volání a datové typy podporovaných parametrů jsou u každé implementace SOAP odlišné a funkce, která pracuje s jedním toolkitem nemusí pracovat s jiným. Není to však omezení protokolu SOAP, nýbrž určité používané implementace.

Daleko nejdůležitější funkcí SOAP je možnost implementace na mnoha různých hardwarových a softwarových platformách. Znamená to, že protokol SOAP může být využit ke spojení neslučitelných systémů uvnitř i mimo vaši organizaci. V minulosti bylo uskutečněno mnoho pokusů o vytvoření obecného komunikačního protokolu, který by mohl být využit k integraci systémů, ale žádný z nich nedosáhl tak širokého uplatnění jako SOAP. Proč? Protože SOAP je mnohem menší a jednodušší k implementaci než mnoho předchozích protokolů. Například DCE a CORBA vyžadují k implementaci několik let, takže dosud bylo uvedeno jen několik implementací. SOAP však může na většinu těžké práce používat existující XML Parsers a knihovny HTTP, takže implementace SOAP může být dokončena řádově za měsíce. To je také důvod, proč je již dostupných více než 70 implementací SOAP. SOAP samozřejmě neumí všechno jako DCE nebo CORBA, ale jednoduchost výměny funkcí způsobuje, že je SOAP tak snadno dostupný.

Všudypřítomnost HTTP a jednoduchost SOAP vytváří ideální základnu k implementaci webových služeb XML, které mohou být volány z téměř jakéhokoli prostředí. Další informace o SOAP najdete na domovské stránce MSDN SOAP [ http://msdn.microsoft.com/library/default.asp?url=/nhp/Default.asp?contentid=28000523 ].

A co zabezpečení?

Jednou z prvních otázek těch, kteří začínají se SOAP, je otázka, jak SOAP řeší zabezpečení. V počátečních fázích vývoje se na SOAP pohlíželo jako na protokol založený na HTTP, takže se předpokládalo, že SOAP bude mít stejnou úroveň zabezpečení jako HTTP. Dnes existují tisíce webových aplikací se zabezpečením na úrovni HTTP, takže toto zabezpečení se zdálo přiměřené i pro SOAP. Současný standard SOAP předpokládá, že zabezpečení je věcí přenosu a o ostatních problémech se zabezpečením se mlčí.

Jakmile se SOAP rozšířil a stal se více obecným protokolem běžícím na vrcholu řady přenosů, stal se problém zabezpečení závažnějším. HTTP například poskytuje několik způsobů, jak ověřit, který uživatel provedl volání SOAP, ale jak se má tato identita přenášet, když se zpráva směruje z HTTP na přenos SMTP? Protokol SOAP byl navržen jako stavební blok, takže naštěstí se již pracuje na specifikacích vycházejících ze SOAP, které poskytnou přídavné bezpečnostní funkce pro webové služby. Specifikace WS-Security [ http://msdn.microsoft.com/library/en-us/dnglobspec/html/ws-security.asp ] definuje kompletní šifrovací systém.

WSDL

WSDL (často se vyslovuje jako whiz-dull) je zkratka pro Web Services Description Language (jazyk popisu webových služeb). Pro naše účely postačí, když řekneme, že soubor WSDL je dokument XML popisující sadu zpráv SOAP a způsob, jakým se zprávy vyměňují. Jinými slovy, WSDL je pro SOAP totéž, čím je IDL pro CORBA nebo COM. Jelikož WSDL má formát XML, je čitelný a editovatelný, ale většinou je generován a využíván softwarem.

Abychom si uvědomili hodnotu WSDL, představme si, že chceme začít volání metody SOAP, poskytované jedním z našich obchodních partnerů. Můžeme jej požádat o nějaké ukázkové zprávy SOAP a napsat aplikaci tak, aby vytvářela a přijímala zprávy, které vypadají jako tyto ukázky. Tento způsob však může být náchylný ke vzniku chyb. Vidíte například ID zákazníka s hodnotou 2837 a předpokládáte, že to je celé číslo (integer), ale ve skutečnosti je to řetězec. WSDL specifikuje, co musí obsahovat zpráva s požadavkem a jak má vypadat zpráva s odpovědí v jednoznačném zápisu.

Zápis (notace), který soubor WSDL používá k popisu formátů zpráv je založen na standardu XML Schema. Znamená to, že je neutrální k programovacímu jazyku a je založen na standardech, takže je vhodný k popisu rozhraní webových služeb XML přístupných z celé řady platforem a programovacích jazyků. Kromě popisu obsahu zpráv definuje WSDL, kde je služba dostupná a jaký komunikační protokol je použit ke spojení se službou. Soubor WSDL tedy definuje vše potřebné k tomu, aby mohl být napsán program k práci s webovou službou XML. K dispozici je několik nástrojů ke čtení souboru WSDL a ke generování kódu vyžadovaného ke komunikaci s webovou službou XML. Jedny z nejvýkonnějších takových nástrojů jsou obsaženy v produktu Microsoft Visual Studio® .NET.

Mnoho současných nástrojových kitů SOAP obsahuje nástroje ke generování souborů WSDL z existujících programovacích rozhraní. Existuje i několik nástrojů k přímému psaní WSDL, přesto není nástrojová podpora WSDL tak kompletní, jak by mohla být. Nemělo by trvat dlouho, aby nástroje k tvorbě souborů WSDL a následnému generování proxy objektů – podobně jako u nástrojů COM IDL – se staly součástí většiny implementací SOAP. WSDL se tak stane preferovaným způsobem tvorby rozhraní SOAP pro webové služby XML.

K dispozici je vynikající popis WSDL. Specifikace WSDL můžete najít na http://www.w3.org/TR/wsdl [ http://www.w3.org/TR/wsdl ].

UDDI

Specifikace Universal Discovery Description and Integration (UDDI) jsou zlatými stránkami webových služeb. Stejně jako u tradičních zlatých stránek můžete hledat firmy nabízející požadované služby, přečíst si základní fakta o nabízených službách a kontaktovat někoho k získání dalších informací. webovou službu můžete samozřejmě nabízet bez registrace v UDDI, stejně jako když otevřete obchůdek v přízemí vašeho domku a spolehnete se na „ústní“ reklamu mezi sousedy. Pokud však chcete obsáhnout významnější trh, potřebujete UDDI, aby vás zákazníci mohli najít.

Vstupem do adresáře UDDI je soubor XML, který popisuje podnik a jím nabízené služby. Zápis do adresáře UDDI je možno rozdělit na tři části. „Bílé stránky“ popisují firmu nabízející službu: název, adresu, kontakty atd. „Žluté stránky“ zahrnují průmyslové kategorie založené na standardních systematikách, jako je North American Industry Classification System a Standard Industrial Classification. „Zelené stránky“ popisují dostatečně podrobně rozhraní ke službě, aby kdokoli mohl napsat aplikaci používající webovou službu. Způsob, jakým jsou služby definovány, je uveden v dokumentu UDDI nazvaném Type Model nebo tModel. V mnoha případech obsahuje tModel soubor WSDL, který popisuje rozhraní SOAP k webové službě XML, ale tModel je dostatečně pružný, aby mohl popsat téměř jakýkoli druh služby.

Adresář UDDI rovněž obsahuje několik způsobů, jak vyhledávat služby potřebné ke stavbě vašich aplikací. Můžete například hledat poskytovatele služby v určeném geografickém místě nebo podnik určitého typu. Adresář UDDI pak dodá informace, kontakty, odkazy a technická data, podle kterých vyhodnotíte, které služby splňují vaše požadavky.

UDDI umožňuje vyhledat podniky, od kterých můžete získat určité webové služby. Co když však již víte, s kým chcete obchodovat, ale nevíte jaké služby nabízí? Specifikace WS-Inspection [ http://msdn.microsoft.com/library/en-us/dnglobspec/html/ws-inspection.asp ] umožňuje procházet množinu webových služeb XML nabízených na určitém serveru. Zde můžete zjistit, která služba splňuje vaše požadavky.

Další informace o UDDI jsou dostupné na http://www.uddi.org/about.html [ http://www.uddi.org/about.html ].

Co zbývá?

Dosud jsme mluvili o tom, jak hovořit s webovými službami XML (SOAP), jak jsou webové služby XML popsány (WSDL) a jak webové služby XML najít (UDDI). Toto vše vytváří sadu základních specifikací, které jsou základem pro integraci a agregaci aplikací. Z těchto základních specifikací staví podniky reálná řešení a získávají z nich reálnou hodnotu.

I když bylo již vykonáno mnoho práce, aby se webové služby XML staly realitou, stále ještě zbývá spousta práce. V současné době již lidé úspěšně využívají webové služby XML, existují však stále věci, které jsou dosud jen cvičením pro vývojáře, například zabezpečení, operační management, transakce, spolehlivá výměna informací (messaging). Architektura globálních webových služeb XML pomůže posunout webové služby XML na další úroveň poskytnutím promyšleného obecného modelu pro přidání nových pokročilých modulárních a rozšiřitelných funkcí webových služeb XML.

WS-Security [ http://msdn.microsoft.com/library/en-us/dnglobspec/html/ws-security.asp ] je jednou ze specifikací v architektuře globálních webových služeb (Global Web Services Architecture). Operační management potřebuje směrování (routing) zpráv na mnoho serverů a dynamickou konfiguraci těchto serverů pro zpracování. To je rovněž součástí architektury globálních webových služeb a je obsaženo ve specifikaci WS-Routing [ http://msdn.microsoft.com/library/en-us/dnglobspec/html/ws-routing.asp ] a specifikaci WS-Referral [ http://msdn.microsoft.com/library/en-us/dnglobspec/html/ws-referral.asp ]. S tím jak se bude architektura globálních webových služeb vyvíjet, budou uváděny specifikace pro tyto a další potřeby.