Standardní odpověď aplikačního architekta na otázku zákazníka, jak by navrhl architekturu zamýšlené podnikové aplikace, bude pravděpodobně znít: „Použiji klasickou třívrstvou architekturu.“ Počet vrstev se může samozřejmě případ od případu lišit, faktem však zůstává, že se podobné odpovědi staly v posledních letech tak trochu klišé. Architektonická rozhodnutí jsou do značné míry předurčena etablovanými technologickými platformami, které aplikačnímu architektovi vymezují manipulační prostor pro rozhodování. Mezi nejpoužívanější platformy pro vývoj podnikových aplikací patří v současnosti bezesporu dvě rivalské technologie Microsoft .NET a Java EE[1]. Architekt obvykle nemá možnost volby mezi zmíněnými platformami a je často postaven před hotové rozhodnutí, učiněné s ohledem na obchodní a strategické zájmy dodavatele či zákazníka. Nicméně společným jmenovatelem obou vedoucích technologií je skutečnost, že byly navrženy s důrazem na usnadnění tvorby vícevrstvých, distribuovaných aplikací. Obě platformy poskytují pestrou škálu různých knihoven, API a nástrojů, které významně zefektivňují vývoj. Nezbytnou podmínkou je samozřejmě jejich zvládnutí vývojářem a dostatečná praxe.
Připomeňme si hlavní přednosti vícevrstvé architektury. Je-li správně a racionálně navržena, může mít pozitivní vliv hned na několik systémových kvalit. Asi nejdůležitější kvalitou je škálovatelnost. Tato vlastnost určuje, jak je aplikace schopna vypořádat se s rostoucími nároky, například zvyšujícím se počtem současně přistupujících uživatelů. Rozdělení aplikace do slabě svázaných vrstev umožňuje řešit problematiku úzkého hrdla aplikace na úrovni jednotlivých vrstev. Nejvíce zatíženou vrstvu lze po identifikaci vyčlenit a patřičně posílit. (Obecně platí, že prezentační vrstva se obvykle škáluje přidáváním dalších počítačů, zatímco perzistentní vrstva se škáluje navyšováním paměti a počtu procesorů.)
Vícevrstvá architektura úzce souvisí s architekturou orientovanou na služby (SOA). SOA aplikace jsou obvykle distribuované, vícevrstvé aplikace, které mají prezentační, aplikační a perzistentní vrstvu. Veškerá funkcionalita takové aplikace je vystavena prostřednictvím služeb. V SOA aplikacích se typicky neudržuje stav konverzace s klientem, komunikace probíhá způsobem dotaz-odpověď, případně jednosměrně, komponenty aplikace jsou slabě provázané a primárním zájmem je business logika aplikace poskytovaná formou služeb.
Zajímavým postřehem je, že v uvedených architektonických přístupech jaksi nezbývá místo pro objektové paradigma (OOP), tolik populární před nástupem SOA. Koneckonců, jak .NET tak Java jsou objektové jazyky, jejichž „objektovost“ zde přichází poněkud vniveč. Tyto jazyky mají vestavěné objektové koncepty jako dědičnost, polymorfismus a zapouzdření, které dávají architektům a vývojářů do rukou mocné nástroje při objektovém návrhu aplikací. V servisně orientovaných aplikacích je primárním artefaktem služba, tedy procedurální prvek, který zpracovává či poskytuje data. Data a business logika jsou zde oddělené. Návrhové vzory považované za „best-practicies“ v servisně orientovaném návrhu jsou v objektově orientovaném návrhu často považované za anti-vzory a naopak. Jistě stojí za úvahu, zda-li jsme se spontánním přechodem k servisně orientované architektuře nevědomky neochudili o nějaký důležitý či užitečný koncept ze světa objektového návrhu.
Pro ilustraci uvádím příklad webové aplikace pro ukládání a úpravu fotografií. Uvažujme případ užití, ve kterém si uživatel zobrazí vybranou fotografii. Na stránce s fotkou má k dispozici kontrolky, pomocí kterých může měnit různé vlastnosti a parametry fotky, například rozměr.
Aplikace navržená v intencích SOA paradigmatu bude poskytovat služby pro vyhledání fotografií, pro jejich úpravu, uložení atp. Fotka samotná bude reprezentovaná prostou datovou strukturou bez metod (tzv. anemický objekt). Pokud si uživatel přeje provést nějaké úpravy, aplikace zavolá odpovídající službu, které předá objekt fotografie. Služba vrátí upravený objekt a prezentační vrstva jej zobrazí uživateli. Pokud je uživatel s úpravami spokojen, uloží změny prostřednictvím služby pro ukládání fotografií. Objekt fotografie je po většinu času tzv. odpojený, neboli bez spojení na databázi. Výhody s tím spojené mohou být snadno převáženy komplikovaným a výkonnostně náročným slučováním pozměněného objektu se stávající verzí v databázi během ukládání. Tento problém je obzvlášť citelný v případě rozměrných objektů, jako například právě fotografií.
Podívejme se nyní na stejnou aplikaci, tentokrát navrženou v objektovém paradigmatu. Na rozdíl od servisně orientované architektury, kde je primárním artefaktem služba, zde je v centru pozornosti objekt fotografie. Ten neobsahuje pouze prostá data, ale současně s sebou nese také operace pro manipulace s daty (zapouzdření). Požadavek na přeformátování fotografie se nepředává specializované službě, nýbrž se o přeformátování požádá samotný objekt fotografie. Takový design je velmi intuitivní a přirozený, neboť vystihuje naše vrozené vnímání objektů z okolního světa coby autonomní entity. Významným rozdílem je také skutečnost, že objekt je po celou dobu tzv. připojený, neboli v kontaktu s perzistentní vrstvou. Nedochází zde tudíž k onomu komplikovanému a náročnému slučování verzí. Objektový návrh se také elegantněji vypořádává s požadavkem na odlišné zpracování požadavku v závislosti podle typu objektu (polymorfismus). Lze si představit, že změna rozměrů nějaké speciální fotografie, např. fotky do pasu, bude na rozdíl od obyčejné fotografie provádět jakési dodatečné kontroly na povolené rozměry. Využitím dědičnosti (jejíž podpora je součástí programovacího jazyka) lze tohoto chování snadno docílit. V servisně orientovaném návrhu vede řešení takového požadavku k složitému a předpotopnímu řešení pomocí větvení kódu.
Je potěšující, že poslední verze platformy Java EE přinesla řadu nových technologií a vylepšení (obvykle inspirovaných v open-source projektech – např. Seam a Guice), která návrh objektově orientované architektury podnikových aplikací významně usnadňují. Díky nim může nyní architekt navrhovat podle potřeby oba typy architektur v rámci jedné platformy. Závěrem bych rád podtrhl, že ačkoliv jsou oba přístupy v mnoha ohledech antagonistické, mohou nejen koexistovat v jedné aplikaci, ale mohou se i vhodně a účelně doplňovat.
[1] Další technologie postavené na Javě používané při vývoji podnikových aplikací, jako například Spring a Seam, považuji za produkty vzniklé v důsledku nedokonalostí a omezení starších verzí platformy Java EE. Je pravděpodobné, že současný trend nastavený platformou Java EE 5/6, která převzala řadu inovací a nápadů ze zmíněných technologií, povede k jejich postupnému opouštění.
