Zvládněte aplikační integraci

U aplikační integrace jde v zásadě o realizaci výměny informací (různého charakteru) mezi různými aplikacemi. Výměna přitom může probíhat s využitím široké škály transportních technologií – např. přes sdílený soubor, databáze, webové služby, messaging apod.

Motivace pro integraci je značná. Úspěšný integrační projekt má velkou přidanou hodnotu – rozšiřuje možnosti integrovaných aplikací a jejich uživatelům i provozovatelům zjednodušuje práci a údržbu (v mnoha případech velice výrazně).

Naneštěstí integrace nemusí dopadnout vždy dobře, a výsledný efekt je pak spíše opačný. Pojďme si shrnout, jaké jsou nejčastější problémy integrace a jaká jsou jejich východiska.

Jak to funguje?

Jedním z nejzásadnějších problémů může být už samotný počet integrovaných aplikací a integračních technologií. Komplexnost integrace totiž roste geometricky s počtem vzájemně propojených řešení – matematicky je to n*(n-1), ale běžní IT smrtelníci takovým architekturám říkají spaghetti.

Na rozdíl od italské těstoviny je však integrace „každý s každým“ velice nákladná a jen těžko stravitelná pro všechny zúčastněné strany.

V takové situaci tedy může být velice těžké všechny integrace spravovat a monitorovat a změna v jakémkoliv programu může mít zásadní dopady na ostatní. Transportní technologie (např. webové služby), která se zvolí pro integraci jedné dvojice aplikace, nemusí být z různých důvodů aplikovatelná pro další, a tudíž roste i počet technologií a nároky na jejich znalost.

Navíc zvolené technologie mohou mít i další problémy vycházející z jejich podstaty – například nespolehlivost nebo nízká efektivita (viz  dále).

Typickým řešením těchto problémů je obohacení podnikové architektury o některý z integračních prvků jako např. MOM (Message Oriented Middleware), ESB (Enterprise Service Bus) nebo SOA (Service Oriented Architecture). Všechny tyto prvky i jejich konkrétní implementace více či méně zahrnují podporu pro integrační návrhové vzory.

Jádrem MOM architektury je tzv. Message Broker, který zajišťuje spolehlivé doručení zprávy nesoucí informaci (Message) mezi jednotlivými systémy (prostřednictvím front). MOM snižuje vazbu (technickou) mezi jednotlivými aplikacemi, představuje spolehlivou platformu pro komunikaci, zjednodušuje celkovou topologii architektury a zavádí jednotnou technologii pro komunikaci.

Důležitou vlastností je i časová nezávislost – příjemce zprávy nemusí být schopný přijmout zprávu v době jejího odeslání. A stále přetrvává problém úzké vazby na úrovni interpretace přenášených informací – aplikace, která přijímá data od jiné, musí rozumět cizí reprezentaci dat (na úrovni formátu i sémantiky).

ESB tvoří nadmnožinu MOM. Také představuje centrální prvek komunikace, ale na rozdíl od MOM podporuje širší škálu komunikačních technologií a podporuje také zpracování zpráv – typicky transformace (např. XSLT).

Samo ESB pak představuje mediátora, který přemosťuje rozdíly v komunikačních technologiích a datových formátech. Například jedna aplikace (producent) může zasílat uživatelské informace (adresa, telefon atd.) přes FTP a jako CSV soubor – ESB tato data transformuje do XML a posílá do jiné aplikace (konzument) skrze webové služby.

Tímto se vazba mezi dvěma programy koncentruje do ESB, kde je mnohem jednodušeji implementovaná a spravovaná. Změna producenta nebo konzumenta se implementuje pouze v ESB (bez zásahu do existujících aplikací), což snižuje náklady a zvyšuje flexibilitu celého řešení.

SOA, na rozdíl od výše uvedených přístupů, představuje obecný architektonický přístup k implementaci aplikací, který není limitovaný čistě na integraci existujících programů (nicméně se na ni dá úspěšně aplikovat).

V SOA je základním stavebním prvkem služba (service). Ta by měla splňovat řadu různých principů, mezi které patří například standardizovaný kontrakt, abstrakce, autonomie nebo znovupoužitelnost. Služby jsou nezávislé na komunikačním protokolu a lze je spravovat v registru služeb.

Služby je možné také vytvářet kompozicí ostatních služeb. Z pohledu aplikační integrace lze tedy jednotlivé aplikace a jejich funkcionality abstrahovat jako služby – automaticky tak dojde k žádoucímu oddělení byznys logiky od technických specifik transportu a dat.

Open source nástroje

V oblasti nástrojů pro podporu integrace lze volit z celé řady existujících open source řešení. Ta pokrývají základní oblasti jako Message Broker (třeba JBoss A-MQ, Apache ActiveMQ, RabbitMQ nebo HornetQ), integrační frameworky (například Apache Camel nebo Spring Integration) a kompletní integrační řešení (JBoss Fuse, JBoss Fuse Service Works, Fabric8, Mule ESB nebo Talend).

Kompletní řešení obvykle kombinují několik existujících technologií a toolů do jednoho odladěného celku obsahujícího i instalátor a administrační nástroje. Třeba JBoss Fuse využívá A-MQ a Apache Camel (se kterým pracuje i Talend) doplněné o vývojové studio v Eclipse, OSGi kontejner Karaf a webovou konzoli Hawtio.

Aby to nebylo jednoduché, některé produkty jsou „pouze“ enterprise variantami jiných produktů – např. A-MQ je název pro ActiveMQ podporované a testované společností Red Hat.

A aby to bylo ještě komplikovanější, obvykle nic nebrání využití jiné než přímo podporované messaging technologie v daném řešení – např. Mule ESB lze bez větších problémů provozovat i s ActiveMQ. Z pohledu reálného využití je samozřejmě nejjednodušší a ve většině případů i nejlepší sáhnout po kompletním a otestovaném řešení.

Jaké jsou tedy vlastnosti (důležité z pohledu integrace), které většina uvedených produktů splňuje?...

Autor pracuje jako software architekt ve firmě Unicorn Systems.

Tento příspěvek vyšel v plné podobě v Computerworldu 5/2015.Oproti této on-line verzi je výrazně obsáhlejší a přináší mnohé další poznatky a tipy, které lze využít při praktické implementaci u vás ve firmě.

Zmíněný časopis (starší čísla i předplatné těch nadcházejících) si můžete objednat na adrese našeho vydavatelství.