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.