Architektura SOA v praxi – 3. díl

Tomáš Kadlec

Vytvoření kompozitní aplikace

V předchozích dvou článcích šlo především o infrastrukturu architektury SOA, která běží na pozadí tzv. „backend“ a poskytuje sdílené služby. Vývojáře však potřebujete stále pro integraci a vytvoření klientské neboli „kompozitní“ aplikace využívající tyto služby, ačkoliv toto platí pro prezentační vrstvu založenou na klasických technologiích z éry Web 1.0. Nejčastěji se jedná o aplikace založené na technologiích ASP, PHP, JSP nebo JSF.

V této souvislosti stojí za zmínku, že celá řada obchodních vztahů a vazeb trvá méně než 12 měsíců, což je způsobeno neustále vzrůstající dynamikou obchodních vztahů. Když vezmeme v úvahu, že i při maximálním úsilí trvá vývoj průměrné aplikace mezi 3 až 6 měsíci, pak zbývá velmi málo času pro realizaci projektu. Protože IT existuje za účelem podpory obchodní činnosti organizace, dalším logickým krokem je požadavek na vytvoření takového programovacího modelu, který bude umožňovat uživatelům ne-vývojářům jednoduše komponovat služby a vytvářet jednoduché klientské aplikace pokrývající i tuto specifickou oblast.

Pro aplikace, které IT není schopno realizovat, ať už z důvodů omezených zdrojů, nebo záporného TCO/ROI, existuje speciální termín "Long tail" nebo také "situační aplikace". Jde o aplikace, které jsou charakterizovány krátkou dobou života nebo malým počtem uživatelů. Jedná se o nepokrytou oblast, kde jsou flexibilita a rychlost změny klíčové, a její využití by přineslo velké konkurenční výhody. V důsledku to znamená, že čelíte problému, jak maximálně využít potenciál vašich služeb. Otázka tedy zní: Jak rychle a flexibilně vytvářet klientské aplikace SOA, které mají atributy "Long tail", ale jsou obchodně zajímavé?

Otázka softwarového vývoje

Řešení existuje, ale není tak jednoduché jej dosáhnout. Je dobré si uvědomit, že podniková SOA a její klíčové komunikační standardy (SOAP, WSDL, XSD, BPEL a WS* standardy pro bezpečnost a transakčnost) byly vyvíjeny především jako robustní a výkonné standardy pro komplexní heterogenní prostředí. Jednoduše řečeno, ačkoliv jsou tyto standardy vynikající pro tvorbu sdílených služeb, ne vždy jsou dostatečně efektivní jako programovací model pro klientské aplikace, resp. browser. Vytvoření klientské aplikace využívající více služeb je tedy v současné době vždy o softwarovém vývoji.

Pro odpověď musíme jinam. Vraťme se do roku 2004, kdy se začal objevovat termín Web 2.0 zaštiťující rozsáhlý konglomerát principů, technologií a standardů, který vznikl s cílem lépe využívat mohutnou internetovou infrastrukturu. Cílem bylo zvýšení úrovně vzájemného sdílení informací, spolupráce v rámci zájmových skupin resp. komunit a celkové posílení sociálních aspektů v elektronické komunikaci. Je zde kladen důraz na zjednodušení programovacího modelu pro jednoduché, obsahově orientované aplikace, které se vyznačují kompozicí obsahu z více nezávislých zdrojů pomocí internetových API založených na principu REST. Z hlediska kompozice není velký rozdíl mezi obsahem a službou SOA, princip zůstává stejný. Pro tyto aplikace se vžilo populární označení „Mashup“.

Web 2.0 představuje významný fenomén, který již dnes má velký vliv na způsob, jak se používá Internet. Názorným příkladem je úspěch stránek jako YouTube, Flickr, Facebook nebo Google Maps.

S ohledem na nepolevující tlak na lepší obchodní výsledky jsou pro organizace z komerční sféry primárně přitažlivé jiné aspekty. Klasické metody jako kontrola nákladů nebo vyšší výrobní produktivita jsou na hraně svých možností a pozornost se přesouvá k inovacím a novým způsobům a přístupům k práci. Snadná kolaborace, sdílení informací a originální kompozice existujících aplikací ve stylu "Mashup" jsou tak velmi atraktivní.

Oddělený vývoj SOA a Web 2.0

Skutečností nicméně zůstává, že SOA a Web 2.0 se do značné míry vyvíjejí odděleně. Dokonce by se dalo říci, že některé technologie Web 2.0 vznikly jako reakce na komplexnost web servisových standardů.

Příkladem je již zmiňovaný REST (Representational state transfer) definovaný ve známé disertační práci pana Fieldinga, jednoho z autoru klíčového standardu HTTP. Zjednodušeně řečeno se jedná o sadu architektonických principů k tomu, jak definovat, adresovat a používat informační zdroje na Internetu. REST představuje geniálně elegantní a jednoduchý způsob, jak realizovat dokumentově orientované webové služby, a to bez komplexnosti protokolů SOAP/WSDL. Důležité je i to, že vpodstatě jakýkoliv moderní webový prohlížeč se velmi snadno stane REST klientem. Naopak chtít po webovém prohlížeči, aby přímo komunikoval s "klasickou" SOAP webovou službou, není nejlepší krok.

REST používá pro svou datovou výměnu několik jednoduchých standardizovaných formátů:

-- ATOM/RSS: velmi populární sada protokolů pro publikaci a aktualizaci informačních zdrojů.
-- JSON (JavaScript Object Notation): speciální záznam popisu dat odvozený z JavaScriptu s nízkou provozní režií, snadno a rychle interpretovatelný v jakémkoliv prohlížeči.
-- XML: univerzální formát, který funguje vždy a všude, ale např. práce s JSON je v prohlížeči mnohem rychlejší.

Především ATOM/RSS je formát, který stojí za zmínku. Určuje jednoduchou standardní strukturu, která dovoluje vytvářet vizuální komponenty s definovanými vstupy, výstupy a událostmi, umožňující uživatelům ne-programátorům jejich vzájemnou kompozici v jednoduchém stylu „drag and drop“. Celá řada Mashup framework, např. i IBM Lotus MashupCenter, je založena právě na tomto formátu.

Klientské komponenty jsou vyvíjeny v JavaScript, resp. v některém z mnoha desítek toolkitů JavaScriptu, které se v posledních letech objevily. Ano, jde skutečně o JavaScript. Navzdory jistým negativním ohlasům ze začátků internetové éry tento jazyk zaznamenal významná technická zdokonalení a standardizaci a v posledních letech se dá dokonce hovořit o jeho globální renesanci. Samozřejmě s tím úzce souvisí AJAX jako klíčová inovace umožňující v rámci obyčejného prohlížeče vytvářet tzv. RIA (Rich Internet Application) srovnatelné s komfortem klasických aplikací Windows.

Přednosti RIA

RIA představují to nejlepší z obou světů, tedy výkon a komfort klientů Windows a univerzálnost a jednoduchou údržbu webových aplikací. Zjednodušeně řečeno, AJAX realizuje asynchronní komunikaci na pozadí a odstraňuje častý nešvar prohlížečů: překreslení celé stránky a synchronní dotaz na server prakticky po každém kliknutí.
Např. pro čtenáře, kteří používají WebSphere, je vhodné v první řadě posoudit Dojo toolkit, který IBM standardně používá pro své Web 2.0 projekty. Použití toolkitu je prakticky nutností. Nikdo dnes neprogramuje přímo v JavaScriptu, samotný AJAX je vysoce komplexní a kompatibilita mezi prohlížeči není zdaleka samozřejmostí.

I po této krátké exkurzi do světa Web 2.0 je zřejmé, že se jedná o značně odlišné architektury založené na odlišných, často až protichůdných principech. Nicméně klíčové principy jako rychlost vývoje, komponentový přístup, kompozice služeb atd. jsou v zásadě podobné.

Architekt zodpovědný za podnikové řešení tedy musí být pragmatický a z obou světů použít to nejlepší. Je zřejmé, že klasické webové služby SOAP jsou dnes hlavní motor podnikových architektur SOA a v dohledné budoucnosti budou v této oblasti dále posilovat. Na obzoru se ani vzdáleně nerýsuje nic převratně nového.

Bohužel v oblasti prezentační vrstvy dlouhodobě panuje značná roztříštěnost. K dispozici jsou desítky, ne-li stovky různých frameworků a toolkitů. Web 2.0 technologie ještě dále rozšiřují nabídku. Možnost flexibilní kompozice uživatelského rozhraní analogické službám SOA "backend" však umožňují pouze některé.

Alternativa v podobě portálů

Významnou alternativou jsou bezesporu portály, které dnes představují vyspělou a ověřenou technologii vhodnou pro klíčové, plošně nasazované aplikace, které vyžadují formálně definované SLA. Koncepce kompozitního uživatelského rozhraní složeného z jednotlivých portletů je v dobré shodě s filosofií SOA a rovněž nabízí relativně vysokou flexibilitu a znovupoužitelnost. Ačkoliv agregace uživatelského obsahu původně probíhala plně na serveru, tedy ve stylu Web 1.0, poslední verze portálových produktů masivně implementují nejrůznější prvky typické pro Web 2.0.

Nicméně ani portál není nejlepší varianta pro aplikaci patřící do kategorie "Long tail". Pokud IT organizace skutečně chce být moderním partnerem obchodních oddělení, je pravděpodobně nutné začít projekty s atributy Web 2.0. Z technického hlediska je nutné existující služby vybavit rozhraním REST, což samo o sobě není zásadním problémem. Je však nutné pamatovat na organizační a governance aspekty celé věci především s ohledem na možnou ztrátu kontroly nad aplikacemi budovanými tímto způsobem.

Bez Web 2.0 samotná SOA nikdy nebude zcela naplňovat potenciál, který představuje. To samé však platí i opačně. Minimálně v komerční podnikové sféře Web 2.0 stojí a padá s existencí kvalitních informačních služeb. SOA představuje komponentový model, kdy jsou jednotlivé služby komponovány pod kontrolou centrální IT organizace s příslušnou úrovní governance. Web 2.0 naopak představuje ideální klientské prostředí pro uživatele s možností komponovat služby podle potřeby, a to pokud možno bez jakéhokoliv omezení. Vzájemné propojení je nevyhnutelné a logické a v nejbližší době budeme svědky vzniku celé řady standardů, které toto propojení budou podporovat.

Profil

Autor v roce 1994 ukončil jadernou fakultu ČVUT. Od roku 1996 je zaměstnán v různých technických pozicích ve společnosti IBM. Od roku 2004 pracuje jako IT architekt v IBM Software Group se zaměřením na finanční a průmyslové podniky. V roce 2006 získal Open Group ITAC certifikaci v oblasti IT Architektury.

Související odkazy:

Changing computing in the enterprise
Choosing between mashups and traditional Web applications
Get started with InfoSphere MashupHub
Web Portal software from WebSphere
IBM Mashup Center
Welcome to Project Zero
Dojotoolkit

Přečtěte si také

Praktické využití architektury SOA - 1. díl
Architektura SOA v praxi – 2. díl