Přehled
Programování založené na komponentách se stalo populárnějším než kdy jindy. V současné době se téměř nevytváří aplikace, která by v nějaké formě nevyužívala komponenty, obvykle od různých dodavatelů. S tím, jak se aplikace stávají sofistikovanějšími, roste i potřeba využívat komponenty distribuované na vzdálených počítačích.
Příkladem aplikace založené na komponentách je komplexní řešení elektronického obchodování. Aplikace elektronického obchodu umístěná na webové farmě musí odesílat objednávky do koncové aplikace pro plánování podnikových zdrojů (ERP). V mnoha případech se aplikace ERP nachází na jiném hardwaru a může běžet na jiném operačním systému.
Distribuovaný objektový model komponent (DCOM) společnosti Microsoft, distribuovaná objektová infrastruktura, která umožňuje aplikaci volat komponenty modelu COM (Component Object Model) nainstalované na jiném serveru, byla přenesena na řadu jiných platforem než Windows. DCOM se však na těchto platformách nikdy široce neujal, takže se pro usnadnění komunikace mezi počítači se systémem Windows a počítači s jiným systémem používá jen zřídka. Dodavatelé softwaru ERP často vytvářejí komponenty pro platformu Windows, které komunikují s koncovým systémem prostřednictvím proprietárního protokolu.
Některé služby využívané aplikací elektronického obchodu nemusí být v datovém centru vůbec umístěny. Například pokud aplikace elektronického obchodu přijímá platby kreditní kartou za zboží zakoupené zákazníkem, musí využívat služeb obchodní banky pro zpracování informací o kreditní kartě zákazníka. Pro všechny praktické účely jsou však DCOM a související technologie, jako jsou CORBA a Java RMI, omezeny na aplikace a komponenty instalované v rámci podnikového datového centra. Dva hlavní důvody jsou, že tyto technologie standardně využívají proprietární protokoly a že tyto protokoly jsou ze své podstaty orientovány na připojení.
Klienti komunikující se serverem přes Internet čelí mnoha potenciálním překážkám při komunikaci se serverem. Správci sítí po celém světě, kteří dbají na bezpečnost, zavedli podnikové směrovače a firewally, které znemožňují prakticky všechny typy komunikace přes Internet. Často je třeba zásahu božího, aby správce sítě otevřel porty nad rámec nezbytného minima.
Pokud máte to štěstí, že vám správce sítě otevře příslušné porty pro podporu vaší služby, je pravděpodobné, že vaši klienti takové štěstí mít nebudou. V důsledku toho jsou proprietární protokoly, jako jsou protokoly DCOM, CORBA a Java RMI, pro internetové scénáře nepraktické.
Dalším problémem těchto technologií je, jak jsem již uvedl, že jsou ze své podstaty orientovány na připojení, a proto se nedokážou elegantně vypořádat s přerušením sítě. Protože internet není pod vaší přímou kontrolou, nemůžete předpokládat žádnou kvalitu nebo spolehlivost připojení. Pokud dojde k přerušení sítě, může se stát, že další volání klienta na server selže.
Vzhledem k tomu, že tyto technologie jsou orientovány na připojení, je také obtížné vybudovat infrastrukturu s vyváženou zátěží, která je nezbytná pro dosažení vysoké škálovatelnosti. Jakmile je spojení mezi klientem a serverem přerušeno, nelze jednoduše přesměrovat další požadavek na jiný server.
Vývojáři se pokusili tato omezení překonat využitím modelu tzv. bezstavový programování, ale jejich úspěch je omezený, protože tyto technologie jsou poměrně náročné a obnovení spojení se vzdáleným objektem je nákladné.
Vzhledem k tomu, že zpracování kreditní karty zákazníka provádí vzdálený server na internetu, není systém DCOM ideální pro usnadnění komunikace mezi klientem elektronického obchodu a serverem pro zpracování kreditních karet. Stejně jako v případě řešení ERP je v datovém centru klienta často nainstalována komponenta třetí strany (v tomto případě poskytovatelem řešení pro zpracování kreditních karet). Tato komponenta slouží jen jako proxy server, který usnadňuje komunikaci mezi softwarem elektronického obchodu a bankou obchodníka prostřednictvím proprietárního protokolu.
Vidíte v tom nějaký vzor? Kvůli omezením stávajících technologií při usnadňování komunikace mezi počítačovými systémy se výrobci softwaru často uchylují k budování vlastní infrastruktury. To znamená, že zdroje, které mohly být využity k přidání vylepšených funkcí do systému ERP nebo systému zpracování kreditních karet, byly místo toho věnovány na psaní proprietárních síťových protokolů.
Ve snaze lépe podporovat takové internetové scénáře společnost Microsoft původně přijala strategii rozšíření svých stávajících technologií, včetně služby COM Internet Services (CIS), která umožňuje navázat spojení DCOM mezi klientem a vzdálenou komponentou přes port 80. Z různých důvodů nebyla CIS široce přijata.
Bylo zřejmé, že je zapotřebí nový přístup. Microsoft se proto rozhodl řešit problém zdola. Podívejme se na některé požadavky, které muselo řešení splňovat, aby uspělo.
- Interoperabilita Vzdálenou službu musí být možné využívat klienty na jiných platformách.
- Přívětivost k internetu Řešení by mělo dobře fungovat pro podporu klientů, kteří přistupují ke vzdálené službě z internetu.
- Silně typovaná rozhraní Neměly by existovat žádné nejasnosti ohledně typu dat odesílaných a přijímaných ze vzdálené služby. Datové typy definované vzdálenou službou by se navíc měly poměrně dobře shodovat s datovými typy definovanými většinou procedurálních programovacích jazyků.
- Schopnost využívat stávající internetové standardy Implementace vzdálené služby by měla v co největší míře využívat stávající internetové standardy a vyhnout se vynalézání nových řešení již vyřešených problémů. Řešení postavené na široce přijatých internetových standardech může využívat stávající sady nástrojů a produktů vytvořených pro tuto technologii.
- Podpora libovolného jazyka Řešení by nemělo být úzce vázáno na konkrétní programovací jazyk. Například rozhraní Java RMI je úzce svázáno s jazykem Java. Bylo by obtížné vyvolat funkci vzdáleného objektu jazyka Java z jazyka Visual Basic nebo Perl. Klient by měl být schopen implementovat novou webovou službu nebo používat stávající webovou službu bez ohledu na programovací jazyk, ve kterém byl klient napsán.
- Podpora pro jakoukoli infrastrukturu distribuovaných komponent Řešení by nemělo být úzce vázáno na konkrétní infrastrukturu komponent. Ve skutečnosti byste neměli být nuceni kupovat, instalovat nebo udržovat distribuovanou objektovou infrastrukturu jen proto, abyste mohli vytvořit novou vzdálenou službu nebo využívat stávající službu. Základní protokoly by měly usnadňovat základní úroveň komunikace mezi stávajícími infrastrukturami distribuovaných objektů, jako jsou DCOM a CORBA.
Vzhledem k názvu této knihy nepřekvapí, že řešení, které vytvořila společnost Microsoft, je známé pod názvem Webové služby. Webová služba vystavuje rozhraní pro vyvolání určité činnosti jménem klienta. Klient může k webové službě přistupovat pomocí internetových standardů.
Stavební prvky webových služeb
Následující graf znázorňuje základní stavební prvky potřebné k usnadnění vzdálené komunikace mezi dvěma aplikacemi.
Probereme si účel každého z těchto stavebních prvků. Protože mnozí čtenáři znají DCOM, zmíním se také o ekvivalentu DCOM pro každý stavební blok.
- Discovery Klientská aplikace, která potřebuje přístup k funkcím vystaveným webovou službou, potřebuje způsob, jak určit umístění vzdálené služby. Toho se dosahuje prostřednictvím procesu obecně označovaného jako objev. Vyhledávání lze usnadnit prostřednictvím centralizovaného adresáře i ad hoc metodami. V DCOM poskytuje služby zjišťování Správce řízení služeb (SCM).
- Popis Po určení koncového bodu konkrétní webové služby potřebuje klient dostatek informací, aby s ní mohl správně komunikovat. Popis webové služby zahrnuje strukturovaná metadata o rozhraní, které má klientská aplikace využívat, a také písemnou dokumentaci o webové službě včetně příkladů použití. Komponenta DCOM vystavuje strukturovaná metadata o svých rozhraních prostřednictvím knihovny typů (typelib). Metadata v typelib komponenty jsou uložena v proprietárním binárním formátu a jsou přístupná prostřednictvím proprietárního aplikačního programového rozhraní (API).
- Formát zprávy Aby si klient a server mohli vyměňovat data, musí se dohodnout na společném způsobu kódování a formátování zpráv. Standardní způsob kódování dat zajišťuje, že data zakódovaná klientem budou serverem správně interpretována. V protokolu DCOM jsou zprávy odesílané mezi klientem a serverem formátovány podle definice protokolu DCOM Object RPC (ORPC).
Bez standardního způsobu formátování zpráv je téměř nemožné vyvinout sadu nástrojů, která by vývojáře abstrahovala od základních protokolů. Vytvoření abstraktní vrstvy mezi vývojářem a základními protokoly umožňuje vývojáři soustředit se více na daný obchodní problém a méně na infrastrukturu potřebnou k implementaci řešení.
- Kódování Data přenášená mezi klientem a serverem je třeba zakódovat do těla zprávy. DCOM používá schéma binárního kódování pro serializaci dat obsažených v parametrech vyměňovaných mezi klientem a serverem.
- Doprava Jakmile je zpráva naformátována a data jsou serializována do těla zprávy, musí být zpráva přenesena mezi klientem a serverem prostřednictvím některého transportního protokolu. DCOM podporuje řadu proprietárních protokolů vázaných na řadu síťových protokolů, jako jsou TCP, SPX, NetBEUI a NetBIOS přes IPX.
Rozhodnutí o návrhu webových služeb
Probereme si některá návrhová rozhodnutí, která stojí za těmito stavebními prvky webových služeb.
Výběr přenosových protokolů
Prvním krokem bylo určit, jak budou klient a server mezi sebou komunikovat. Klient a server mohou být umístěni ve stejné síti LAN, ale klient může se serverem potenciálně komunikovat přes internet. Proto musí být transportní protokol stejně vhodný pro prostředí LAN i pro Internet.
Jak jsem se již zmínil, technologie jako DCOM, CORBA a Java RMI nejsou vhodné pro podporu komunikace mezi klientem a serverem přes Internet. Protokoly jako HTTP (Hypertext Transfer Protocol) a SMTP (Simple Mail Transfer Protocol) jsou osvědčené internetové protokoly. Protokol HTTP definuje komunikační vzor požadavek/odpověď pro odeslání požadavku a získání související odpovědi. Protokol SMTP definuje směrovatelný protokol pro asynchronní komunikaci. Podívejme se, proč jsou protokoly HTTP a SMTP vhodné pro Internet.
Webové aplikace založené na protokolu HTTP jsou ze své podstaty bezstavové. Nespoléhají na nepřetržité spojení mezi klientem a serverem. Díky tomu je protokol HTTP ideálním protokolem pro konfigurace s vysokou dostupností, jako jsou například firewally. Pokud se server, který zpracovával původní požadavek klienta, stane nedostupným, mohou být následné požadavky automaticky přesměrovány na jiný server, aniž by o tom klient věděl nebo se o to zajímal.
Téměř všechny společnosti mají zavedenou infrastrukturu podporující protokol SMTP. Protokol SMTP je vhodný pro asynchronní komunikaci. Pokud dojde k přerušení služby, e-mailová infrastruktura automaticky zvládne opakované pokusy. Na rozdíl od protokolu HTTP můžete zprávy SMTP předat místnímu poštovnímu serveru, který se pokusí doručit poštovní zprávu vaším jménem.
Další významnou výhodou protokolů HTTP i SMTP je jejich rozšířenost. Zaměstnanci si zvykli spoléhat na e-mail i na webové prohlížeče a správci sítí mají vysokou úroveň komfortu při podpoře těchto služeb. Technologie, jako je překlad síťových adres (NAT) a proxy servery, umožňují přístup k internetu prostřednictvím protokolu HTTP z jinak izolovaných podnikových sítí LAN. Správci často vystaví server SMTP, který se nachází uvnitř brány firewall. Zprávy odeslané na tento server jsou pak směrovány do svého konečného cíle přes internet.
V případě softwaru pro zpracování kreditních karet je nutná okamžitá reakce banky obchodníka, která určí, zda má být objednávka odeslána do systému ERP. Protokol HTTP se svým vzorem zprávy požadavek/odpověď se pro tento úkol dobře hodí.
Většina softwarových balíků ERP není schopna zpracovat velké objemy objednávek, které mohou být potenciálně vyřizovány z aplikace elektronického obchodu. Navíc není nutné, aby objednávky byly do systému ERP odesílány v reálném čase. Proto lze protokol SMTP využít k zařazení objednávek do fronty, aby je systém ERP mohl zpracovávat sériově.
Pokud systém ERP podporuje distribuované transakce, je další možností využití serveru MSMQ (Microsoft Message Queue Server). Pokud se aplikace elektronického obchodování a systém ERP nacházejí ve stejné síti LAN, není připojení prostřednictvím jiných než internetových protokolů takovým problémem. Výhodou MSMQ oproti SMTP je, že zprávy lze do fronty umisťovat a z fronty odstraňovat v rámci transakce. Pokud se pokus o zpracování zprávy, která byla z fronty vyjmuta, nezdaří, bude zpráva automaticky umístěna zpět do fronty, když se transakce přeruší.
Výběr kódovacího schématu
Protokoly HTTP a SMTP umožňují odesílání dat mezi klientem a serverem. Žádný z nich však neurčuje, jak mají být data v těle zprávy kódována. Společnost Microsoft potřebovala standardní, platformově neutrální způsob kódování dat vyměňovaných mezi klientem a serverem.
Protože cílem bylo využít protokoly založené na internetu, byl přirozenou volbou rozšiřitelný značkovací jazyk (XML). XML nabízí mnoho výhod, včetně podpory různých platforem, společného typového systému a podpory standardních znakových sad.
Binární kódovací schémata, jako jsou schémata používaná DCOM, CORBA a Java RMI, musí řešit problémy s kompatibilitou mezi různými hardwarovými platformami. Například různé hardwarové platformy mají odlišnou vnitřní binární reprezentaci vícebajtových čísel. Platformy Intel řadí bajty vícebajtového čísla pomocí konvence little endian; mnoho procesorů RISC řadí bajty vícebajtového čísla pomocí konvence big endian.
XML se vyhýbá problémům s binárním kódováním, protože používá schéma kódování založené na textu, které využívá standardní znakové sady. Také některé transportní protokoly, jako například SMTP, mohou obsahovat pouze textové zprávy.
Binární metody kódování, jako jsou metody používané v DCOM a CORBA, jsou těžkopádné a vyžadují podpůrnou infrastrukturu, která vývojáře abstrahuje od detailů. Jazyk XML je mnohem lehčí a snadněji se s ním pracuje, protože jej lze vytvářet a používat pomocí standardních technik parsování textu.
Kromě toho je k dispozici celá řada parserů XML, které dále zjednodušují vytváření a konzumaci dokumentů XML prakticky na každé moderní platformě. Jazyk XML je lehký a má vynikající podporu nástrojů, takže kódování XML umožňuje neuvěřitelný dosah, protože s vaší webovou službou může komunikovat prakticky jakýkoli klient na jakékoli platformě.
Výběr konvence formátování
Často je nutné připojit k tělu zprávy další metadata. Například můžete chtít uvést informace o typu služeb, které musí webová služba poskytnout, aby mohla splnit váš požadavek, například zařazení do transakce nebo informace o směrování. Jazyk XML neposkytuje žádný mechanismus pro odlišení těla zprávy od souvisejících dat.
Transportní protokoly, jako je HTTP, poskytují rozšiřitelný mechanismus pro údaje v záhlaví, ale některé údaje spojené se zprávou nemusí být specifické pro daný transportní protokol. Klient může například odeslat zprávu, která musí být směrována do více míst určení, případně přes různé transportní protokoly. Pokud by byly informace o směrování umístěny do hlavičky HTTP, musely by být před odesláním dalšímu prostředníkovi přeloženy přes jiný transportní protokol, například SMTP. Vzhledem k tomu, že směrovací informace jsou specifické pro zprávu, a nikoli pro transportní protokol, měly by být součástí zprávy.
Protokol SOAP (Simple Object Access Protocol) poskytuje prostředky pro přiřazení informací v záhlaví k tělu zprávy, které jsou nezávislé na protokolu. Každá zpráva SOAP musí definovat obálku. Obálka má tělo, které obsahuje užitečné zatížení zprávy, a záhlaví, které může obsahovat metadata spojená se zprávou.
Protokol SOAP neukládá žádná omezení, pokud jde o formátování těla zprávy. To představuje potenciální problém, protože bez konzistentního způsobu kódování dat je obtížné vyvinout sadu nástrojů, která by abstrahovala od základních protokolů. Může se stát, že budete muset strávit poměrně dost času tím, že se budete seznamovat s rozhraním webové služby, místo abyste řešili daný obchodní problém.
Bylo zapotřebí standardního způsobu formátování zprávy vzdáleného volání procedury (RPC) a kódování jejího seznamu parametrů. Přesně to poskytuje oddíl 7 specifikace SOAP. Popisuje standardní konvenci pojmenování a styl kódování zpráv orientovaných na procedury.
Protože protokol SOAP poskytuje standardní formát pro serializaci dat do zprávy XML, mohou platformy, jako je ASP.NET a Remoting, abstrahovat od podrobností.
Výběr mechanismů popisu
SOAP poskytuje standardní způsob formátování zpráv vyměňovaných mezi webovou službou a klientem. Klient však potřebuje další informace, aby mohl správně serializovat požadavek a interpretovat odpověď. Schéma XML poskytuje prostředky pro vytváření schémat, která lze použít k popisu obsahu zprávy.
Schéma XML poskytuje základní sadu vestavěných datových typů, které lze použít k popisu obsahu zprávy. Můžete si také vytvořit vlastní datové typy. Například obchodní banka může vytvořit komplexní datový typ pro popis obsahu a struktury těla zprávy používané k odeslání žádosti o platbu kreditní kartou.
Schéma obsahuje sadu definic datových typů a prvků. Webová služba používá schéma nejen ke sdělení typu dat, která mají být obsažena ve zprávě, ale také k ověření příchozích a odchozích zpráv.
Samotné schéma však neposkytuje dostatek informací pro efektivní popis webové služby. Schéma nepopisuje vzory zpráv mezi klientem a serverem. Klient například potřebuje vědět, zda má očekávat odpověď při odeslání objednávky do systému ERP. Klient také potřebuje vědět, přes jaký transportní protokol webová služba očekává příjem požadavků. A konečně klient potřebuje znát adresu, na kterou se lze s webovou službou spojit.
Tyto informace poskytuje dokument WSDL (Web Services Description Language). WSDL je dokument XML, který plně popisuje konkrétní webovou službu. Nástroje, jako je ASP.NET WSDL.exe a Remoting SOAPSUDS.exe, mohou konzumovat WSDL a automaticky vytvářet proxy pro vývojáře.
Stejně jako každá komponenta používaná k vytváření softwaru by i webová služba měla být doplněna písemnou dokumentací pro vývojáře, kteří proti ní programují. Dokumentace by měla popisovat, co webová služba dělá, jaká rozhraní vystavuje, a některé příklady jejího použití. Dobrá dokumentace je zvláště důležitá, pokud je webová služba vystavena klientům přes internet.
Výběr mechanismů zjišťování
Jak mohou potenciální klienti najít webovou službu, kterou jste vyvinuli a zdokumentovali? Pokud je webová služba navržena tak, aby ji mohl využívat člen vašeho vývojového týmu, může být váš přístup poměrně neformální, například sdílením adresy URL dokumentu WSDL s kolegou o pár kanceláří dál. Pokud jsou však potenciální klienti na internetu, je účinná reklama vaší webové služby úplně jiný příběh.
Potřebujeme společný způsob propagace webových služeb. Univerzální popis, vyhledávání a integrace (UDDI) poskytuje právě takový mechanismus. UDDI je standardní centralizovaná adresářová služba, kterou lze použít k inzerování a vyhledávání webových služeb. UDDI umožňuje uživatelům vyhledávat webové služby pomocí řady vyhledávacích kritérií, včetně názvu společnosti, kategorie a typu webové služby.
Webové služby lze inzerovat také prostřednictvím DISCO, což je proprietární formát dokumentu XML definovaný společností Microsoft, který umožňuje webovým stránkám inzerovat služby, které vystavují. DISCO definuje jednoduchý protokol pro usnadnění hypertextového odkazu pro vyhledávání zdrojů. Hlavním uživatelem DISCO je Microsoft Visual Studio.NET. Vývojář se může zaměřit na konkrétní webový server a procházet různé webové služby vystavené tímto serverem.
Co chybí ve webových službách?
Možná jste si všimli, že některé klíčové položky infrastruktury distribuovaných komponent nejsou definovány webovými službami. Dvě z nejzřetelnějších chybějících položek jsou dobře definované rozhraní API pro vytváření a konzumaci webových služeb a sada komponentových služeb, například podpora distribuovaných transakcí. Probereme si každou z těchto chybějících částí.
- Specifické rozhraní API pro webové služby Většina distribuovaných infrastruktur komponent definuje rozhraní API pro provádění takových úloh, jako je inicializace běhového prostředí, vytvoření instance komponenty a reflektování metadat použitých k popisu komponenty. Protože většina vysokoúrovňových programovacích jazyků poskytuje určitý stupeň interoperability s jazykem C, je rozhraní API obvykle vystaveno jako plochá sada signatur metod jazyka C. RMI jde tak daleko, že těsně spojuje své API s jediným vysokoúrovňovým jazykem, Javou.
Ve snaze zajistit, aby webové služby byly nezávislé na programovacím jazyce, ponechala společnost Microsoft na jednotlivých dodavatelích softwaru, aby podporu webových služeb vázali na konkrétní platformu. Později v knize se budu zabývat dvěma implementacemi webových služeb pro platformu.NET, ASP.NET a Remoting.
- Služby složek Platforma webových služeb neposkytuje mnoho služeb, které se běžně vyskytují v infrastruktuře distribuovaných komponent, jako je vzdálená správa životnosti objektů, sdružování objektů a podpora distribuovaných transakcí. Implementace těchto služeb je ponechána na infrastruktuře distribuovaných komponent.
Některé služby, například podpora distribuovaných transakcí, mohou být zavedeny později, až technologie dozraje. Jiné, například sdružování objektů a případně správa životnosti objektů, lze považovat za implementační detail platformy. Například Remoting definuje rozšíření, která poskytují podporu pro správu životnosti objektů, a Microsoft Component Services poskytuje podporu pro sdružování objektů.
Souhrn
Programování založené na komponentách se ukázalo být přínosem pro produktivitu vývojářů, ale některé služby nelze zapouzdřit do komponenty, která se nachází v datovém centru klienta. Starší technologie, jako jsou DCOM, CORBA a Java RMI, se špatně hodí k tomu, aby umožnily klientům přistupovat ke službám přes internet, takže společnost Microsoft považovala za nutné začít od základu a vytvořit standardní způsob přístupu ke vzdáleným službám.
Webové služby je souhrnný pojem, který označuje soubor standardních průmyslových protokolů a služeb používaných k usnadnění základní úrovně interoperability mezi aplikacemi. Podpora, které se webovým službám dostalo ze strany průmyslu, je bezprecedentní. Nikdy předtím se tolik předních technologických společností nezasadilo o podporu standardu, který usnadňuje interoperabilitu mezi aplikacemi bez ohledu na platformu, na které jsou provozovány.
Jedním z faktorů, které přispěly k úspěchu webových služeb, je skutečnost, že jsou postaveny na stávajících internetových standardech, jako jsou XML a HTTP. Díky tomu může s webovou službou komunikovat jakýkoli systém schopný analyzovat text a komunikovat prostřednictvím standardního internetového transportního protokolu. Společnosti také mohou využít investice, které již do těchto technologií vložily.