Kdo může psát o frameworku Spring fundovaněji než jeho autor Rod Johnson. Dnešní díl se tedy bude věnovat myšlenkám, které stály u zrodu Springu a které Rod prezentoval knižně. Chcete-li poznat skutečně podrobně důvody proč používat k vývoji J2EE aplikací Spring framework, měli byste si přečíst Johnsonovu knihu Expert one-on-one J2EE Design and Development.
Rod se v knize věnuje architektuře, návrhu a vývoji J2EE aplikací a rozebírá i problémy, se kterými se J2EE vývojáři setkávají. V knize je průběžně prezentován kód jakéhosi frameworku, který by měl vývoj J2EE aplikací usnadnit, zjednodušit a zpřehlednit a který je původně nazván Interface21. Rod později tento kód rozšíří, jeho pomocníkem a „pravou rukou“ se stává Juergen Hoeller a Interface21 je uvolněn jako open-source pod názvem Spring framework. Takže ten, kdo chce se Springem začít od úplného začátku a myslí to s ním vážně, by si tuhle více než sedmisetstránkovou knihu neměl nechat ujít.
Původně jsem chtěl ve třetím díle seriálu o Springu prezentovat triviální příklad funkční aplikace, ale rozhodl jsem se, že nebude na škodu ještě před tím uvést některé Johnsonovy myšlenky z uvedené knihy, a to zejména ty, které mají souvislost s EJB. Takže tady jsou:
Dobře navržená „enterprise“ aplikace musí splňovat tyto podmínky
- robustnost – musí být spolehlivá a bez chyb,
- výkonnost,
- škálovatelnost – musí být navržena tak, aby se dokázala přizpůsobit zvýšené zátěži při zvýšení hardwarové kapacity. Toho může být dosaženo například distribuovanou architekturou, kdy různé části aplikace budou moci běžet v různých JVM a tedy i na fyzicky různých serverech,
- objektově orientovaný návrh – to, že všechny moderní a nově vznikající programovací jazyky jsou svou podstatou objektově orientované má své dobře známé důvody (lze si o tom přečíst např. v knize R. Pecinovského Myslíme objektově v jazyce Java 5.0),
- nepřítomnost nadbytečné složitosti – jak praví jedno z hesel eXtreme Programming, je třeba dělat věci tak jednoduše, jak jen je to možné,
- udržovatelnost a rozšiřitelnost – je známým faktem, že údržba již nasazené aplikace je zdaleka nejdražší částí jejího životního cyklu, takže je třeba docílit takového návrhu, kdy bude mít každá komponenta jasně vymezenou odpovědnost a bude s ostatními svázána jen volně,
- včasnost dodání,
- snadná testovatelnost,
- znovupoužitelnost – tento požadavek souvisí s OO návrhem, jednotlivé komponenty aplikace by mělo být alespoň do jisté míry možné využít v dalších projektech,
Dalšími požadavky, které mohou být v některých případech vzneseny, jsou
- podpora více typů klientů,
- přenositelnost – ve smyslu změny databáze či aplikačního serveru.
EJB
- EJB není jádrem J2EE, je jen jednou z J2EE technologií.
- EJB je nejsložitější technologií J2EE.
- EJB je velmi pokročilá technologie, která řeší konkrétní problémy velmi dobře, ale existuje tendence využívat ji ve všech J2EE aplikacích, což je špatně.
- Specifikace EJB tvrdí, že její využití umožní snadné psaní aplikací. Zkušenosti naproti tomu říkají, že použití EJB často přidá aplikaci minimálně tolik složitosti, kolik jí ušetří.
- Použití EJB učiní aplikaci hůře testovatelnou, protože silně závisí na službách kontejneru.
- Použítí EJB ztíží nasazení (deployment) aplikace z důvodu nutnosti řešení složitých problémů s classloadery, problémů se složitými deployment descriptory, a také z důvodu vyšší časové náročnosti cyklu vývoj-nasazení-test.
- Remote rozhraní používaná v EJB způsobují problémy s efektivností, protože vzdálená volání jsou časově náročná. Řeší se to pomocí zúžení rozhraní objektů, což porušuje prinicipy OO návrhu. Tato námitka samozřejmě neplatí v případech, kdy je remoting nutností.
- Použití EJB může učinit snadné věci složitými, a to např. implementaci návrhového vzoru Singleton či read-only cachování.
- Použití EJB implikuje možnost provozovat aplikaci pouze na omezeném množství aplikačních serverů.
Argumenty pro použití EJB
- Požadavek vzdáleného přístupu k aplikaci prostřednictvím protokolu RMI/IIOP. V případě požadavku přístupu pomocí webové služby však použití EJB nutné není.
- Požadavek rozložení jednotlivých komponent po více fyzických serverech. V tomto případě jsu EJB rozhodně vhodnější než implementace komunikace pomocí webových služeb.
- Požadavek podpory více typů Java či CORBA klientů.
- Požadavek implementace konzumenta zpráv JMS – Message-driven beany jsou nejjednodušším možným řešením.
Diskutabilní argumenty pro použití EJB
- Zjednodušení psaní vícevláknového kódu – existují však knihovny, které v tomto aspektu dokáží EJB nahradit.
- Deklarativní management transakcí a na rolích založené bezpečnosti aplikace (pozn.: tohle dnes ale umí i Spring)
- Dosažení čistého návrhu zpřístupněním business objektů jako EJB – téhož však lze dosáhnout s využitím starých dobrých obyčejných (POJO) objektů v kombinaci s aplikací klasickýh návrhových vzorů.
- Požadavek vývoje škálovatelných a robustních aplikací – totéž ale umí i obyčejné webové aplikace. Navíc nezkušení programátoři si mohou s využitím EJB způsobit více problémů než bez nich.
Uvedli jsme si samozřejmě jen malou část z množství myšlenek, které Rod publikoval ve zmíněné knize a které tedy stály u zrodu frameworku Spring. Jen upřesním, že Rod hodnotil EJB specifikaci 2.0 a že kniha byla vydána v roce 2003.
No a příště snad už tedy skutečně opustíme suchou teorii a vrhneme se do psaní kódu.
Poslední komentáře