neděle 9. května 2010

Jak jsem si užil Service Oriented Architecture v praxi

Poslední půlrok jsem strávil na zajímavých projektech v jedné z největších bank tady v Česku. Musím říci, že největším zjištěním pro mě bylo něco co bych nazval SOA v praxi. Musím se upřimně přiznat, že před tím, než jsem poznal praxi, přišla mi SOA jako věc příliš abstraktní, pod kterou jsem si nedokázal představit nic konkrétního. Bohužel tato třípísmenná zkratka je natolik zprofanovaná, že těžko najít něco zprofanovanějšího. Pokud se oprostíme od nánosu všeho toho květnatého humusu, myšlenka jako taková se skutečně realizuje. Jak to funguje v praxi se pokusím nastínit na následujících řádcích.

V bankách se donedávna stavěly aplikace s monolitickou architekturou. Ta byla tvořena dvěma částmi frontend a backend, které byly úzce spjaté.

Tohle architektonické rozložení sil vám hází nejeden klacek pod nohy. Především je to špatná znovupoužitelnost toho co nabízejí krabičky s názvem backend a frontend. Pokud to chcete změnit, pak je prakticky nemožné vzít páteř bankovních systému v podobě backendu a začít z ní vytrhávat jednotlivé obratle a ty měnit za něco nového. Jediný možný způsob provedení je vystavení funkcionalit backendu pomocí služeb. Vnímavý čtenář pochopil, zde přichází přerod v SOA. Bohužel backendy jsou často prehistorické systémy, kde schopnost vrátit data v XML je čestnou výjimko. Povětšinou se používají se textové či binární zprávy.

V praxi to znamená, že je potřeba služby vystavit na nějaké infrastruktuře, která umožní použít prostředky, jenž považuje naše doba za standardní. K tomutu účelu se používá Enterprise Service Bus (ESB), která hravě zvládne konverze na úrovni transportního i aplikačního protokolu. Jako technologie se používají Webové služby (SOAP over HTTP).

Takto použité uspořádání znamená, že služby vystavené na ESB definují model. V případě SOAP over HTTP se jedná o model zpráv, které služby přijímají a vracejí. Tento model musí jednak respektovat všechny informace, které potřebují backendy a jednak musí být dostatečně obecný, aby klient nebyl svázaný s konkrétní implementací backendu, nechceme vytvářet příliš těsné vazby. Tento model se nazývá Canonical Data Model (zkráceně CDM).

CDM je jakýmsi lingua franca, pomocí kterého si systémy vyměňují zprávy. Ačkoliv to není na první pohled patrné, CDM je coarse grained, tedy nemusí vždy obsahovat všechny co potřebuje konkrétní klient případně to nemusí být úplně ve vhodném formátu pro interní aplikační použití. Jako příklad může posloužit entita Adresa. Ta je v CDM definována určitým způsobem, ale frontend (klient obecně) může mít různé požadavky na to co všechno si ještě k adrese potřebuje navěsit, například Skype účet, IM účet apod. V takovém případě už máme modely tři, ten poslední je již specifický pro danou aplikaci.

Aplikační model již bývá interně namapován na technologie použité uvnitř aplikace pro ukládání nebo zobrazení. To znamená, že se na něj lepí různé technologické anotace případně je ohýbán, aby se dobře používal. Každá aplikace si musí vyřešit přemapování z aplikačního modelu do CDM modelu. Což lze udělat ručně programově a nebo pomocí šikovné knihovny Dozer.

Samozřejmě, aby to nebylo ještě málo složité, tak máme různé verze modelů a k nim potřebujeme nějakou governance (správu). A to už se dostáváme za rámec tohoto článku a pro mě oblastí neprobádaných.

Na závěr bych ještě pár vět věnoval něčemu málo patrnému, ale o to více důležitému. Žádný vývoj neprobíhá velkým třeskem, to znamená, že služby se průběžně vytvářejí a objevují. Stejně tak služby nejsou vždy dostupné a nebo není možné pro vývoj použít jejich živé systémy. Z tohoto důvodu velkou pozornost získávají simulátory služeb, které vůbec umožňují a výrazně zjednodušují vlastní vývoj aplikací postavených v SOA prostředí. Povídání o simulátorech služeb si ovšem nechám na někdy příště.