Krátké doplnění k "resuscitované mrtvole"
Po přečtení dalšího příspěvku na stránkách Jirky Hradila si dovolím raději vypíchnout to podstatné, co by se laskavému čtenáři v předchozím dlouhém povídání o EJB obecbě i EJB3 zvláště nemělo ztratit:
- EJB3 nepovažuji za "oživování mrtvoly" (jak kdosi poznamenal v diskusi u Romana Pichlika)
- stávající verze EJB (2.1) je zbytečně složitá (nemluvě o verzích starších), zvlášť porovnáme-li EJB přístup s variantou třeba Hibernate+String
- toto uznávají i tvůrci specifikace EJB3 (momentálně ve stavu Early Draft)
- nezabývám se plusy technologie EJB jako takové (škálovatelnost, přesněji škálovatelnost směrem vzhůru ;))
- podíváme-li se na specifikaci EJB3, musíme uznat, že to s avizovaným zjednodušením vypadá opravdu nadějně
Pokud někdo začíná s EJB právě teď, doporučuji obrátit pozornost rovnou k EJB3, není-li si jist, že má pro zabývání se staršími verzemi opravdu vážný důvod.
Takovýmto důvodem jistě může být potřeba stihnout projekt využívající výhod EJB dříve, než vzniknou prověřené implementace EJB3 kontejneru dle finální podoby specifikace.
Ale položme si otázky:
- za jak dlouho provozní prostředí naší aplikace začne výhod EJB opravdu využívat?
- nevyžádá si udržovatelnost a efektivita vývoje později stejně přechod k novým možnostem EJB3?
- nebude vzhledem k výše uvedenému nakonec úspornější začít s nějakým odlehčeným řešením, a na EJB (pochopitelně již v řadě 3.x) přejít, až bude čas?
Není-li toto případ váženého čtenáře, rozhodně jej od EJB2 zrazovat nebudu — ale nezávidím mu to.
EJB 3.0 aneb Proč že tu mrtvolu stále resuscitují?
Onehdá jsem si procházel, co mi nového uteklo na Dagblogu a v komentáři k článku o Hibernate (který se lehce dotýkal EJB3) zazněl názor:
Pokud jde o EJB, nechapu proc tu mrtvolu stale resuscituji... :-("
Sám EJB specifikaci ve verzích starších než 3.0 považuju za notně komplikovaný nástroj a v mnoha případech kanón na vrabce. Nazývat ale EJB "mrtvolou" mi přijde přeci jen zcestné a svědčící spíše o neznalosti aktuálního vývoje.
Na druhou stranu s prominutím naivně nadšený spot Jirky Hradila mne dnes přeci jen mírně překvapil. Dovolím si okomentovat závěrečnou citaci:
Jak tak procházím java konferenci, či různé příspěvky, mám z nich pocit, že EJB se nepoužívají jednoduše proto, že spoustě lidí připadají příliš složité (což nejsou). Možná je ale pravda jinde-prostě je všichni používají, ale nepíšou o tom :)."
To je slovo do pranice — jsou či nejsou EJB složité?
Vzhledem k tomu, že specifikace se dá přelouskat během pár cest tramvají, základní pravidla jistě nijak nepochopitelná nejsou. Z trochou zdravého selského rozumu (nebo knížkou Core J2EE Patterns) si člověk snadno osvojí i postupy užití, které ve specifikaci nenajde. Ale přeci jenom se nabízí otázka — je to všechno nutné? Opravdu je takovou radostí mít pro každou třídu aplikační logiky implementaci, dvě rozhraní a pasáž v obludně dlouhém deployment descriptoru? Muset vyhazovat předepsané výjimky, které nakonec na business delegate vrstvě v rámci odstínění stejně zabalíme do něčeho jiného? Implementovat? Rezignovat na dědičnost? Udržovat ručně obrovský deployment descriptor, nebo se při buildu smířit čekáním než Xdoclet přechroupe všechny naše zdrojáky a vygeneruje co potřebuje? (OK, tohle s dnešním hardwarem už tolik nebolí).
Představme si nejprve, že se nepotřebujeme zaobírat všelijakými lahůdkami stran dostupnosti a škálovatelnosti, kterými nás dodavatelé serverů ohromují. ale píšeme jen triviální webovou aplikaci. Postavme vedle sebe EJB 2.x a kombo Hibernate/Spring.
Odmyslíme-li si (mnohdy pravda nezanedbatelné) výhody, které nám mohou nabídnout dodavatelé EJB kontejnerů a zohledníme-li prostou jednoduchost vývoje, testovatelnost a udržovatelnost, naše nadšení pro EJB musí nutně opadnout.
Ale zas na druhou stranu — EJB je jasně specifikovaný standard posvěcený velkým Sunem, že jo? Přece se na to jen tak nevykváknem, a vůbec, přece na tom musí něco být, když si s tím všichni ti chytří pánové a dámy dali takovou práci.
Jirka Hradil ale má štěstí — objevil EJB v pravý čas, kdy vzniká specifikace EJB 3.0, momentálně ve stavu early draft. Na úvodní stránce technologie EJB na java.sun.com se totiž dočteme, že:
Účelem EJB 3.0 je zlepšení architektury tím, že ji — bráno z pohledu vývojáře — zjednodušíme".
Jak se k tomuto cíli autoři EJB 3 rozhodli dospět?
Metadata
JDK 5 nám přináší možnost přiřadit jednotlivým kouskům kódu metainformace formou anotací.
A uznejme — přeci jen informace o tom, zda nějaký objekt je session beanou či nikoli, je sémanticky přirozenější sdělovat pomocí metadat než implementováním rozhraní.
Pomocí vkusných anotací dále popíšeme vztahy mezi jednotlivými komponentami snáze a srozumitelněji než rozvláčným deployment descriptorem.
A v neposlední řadě anotacemi snadno namodelujeme vztahy mezi doménovými objekty potřebne pro O/R mapping — opět namísto toho, abyhom je popisovali v upovídaném XML konfiguráku.
Implicitní hodnoty
Prosté — nenutit vývojáře konfigurovat do mrtě každý kousek kódu, naopak jasně specifikovat z praxe vycházející defaultní hodnoty pro co nejvíce metadat.
Příklad — máme-li entity beanu s CMP, nemusíme u jednotlivých properties specikovat, že jsou persistentní — naopak máme-li výjimečně pár get/set metod, který nedefinuje persistentní pole, musíme ho explicitně označit (anotací @Transient).
Dependency Injection
Namísto vyhledávání přes JNDI, popisování vztahů mezi objekty užvaněným XML apod. použijeme mechanismus "dependency injection" — tedy poskytneme ve třídách, které se odkazují na jiné zdroje či služby vhodnou set-metodu a on už nám container jejím prostřednictvím poskytne patřičný objekt sám.
Další informace o DI včetně odkazů na zdroje najdete třeba u Romana Pichlíka.
"Od-invazivnění" API
Dřivější verze EJB specifikace vás nutily implementovat rozličná předepsaná rozhraní a vyhazovat předepsané výjimky. S tím je teď konec, enterprise java beanou nyní může být jakákoli vkusně anotovaná třída (pro což se zažil "cool" termín POJO). Díky tomu konečně budeme moci v EJB používat dědičnost, což původní návrh tak trochu komplikoval.
Další
- vylepšení dotazovacího jazyka EJB-QL
- zjednodušení CMP entity bean — ne nadamo byl mezi tvůrce specifikace přizván i autor Hibernate Gavin King
- ...
Určitě mi ještě něco uteklo, ale Jirka Hradil mezi tím stihl napsat další článek s tematikou EJB 2.x, takže jsem s publikací tohoto povídání vážně nemohl dále otálet 
A doufám, že k sepsání něčeho s detailními pohledy dovnitř nové specifikace se v dohledné době také dostanu.
Odkazy:
- JCP pro specifikaci EJB3
- stránky EJB technologie na java.sun.com, odkud je možno stáhnout specifikaci EJB3
- Hibernate
- předběžná verze EJB3 implementace od JBosse
- článek EJB3 in a Nutshell na JavaWorld.com
JBoss 4.0 má volně dostupnou dokumentaci
... a to zdá se poměrně rozumnou. Vztahuje se k aktuální verzi JBoss 4.0.1 a k dostání je na adrese http://docs.jboss.org/jbossas/jboss4guide/r1/html/. Na http://docs.jboss.org/ najdete přehled ostatní JBossí dokumentace v různých stadiích použitelnosti.
A konečně v diskusi na ServerSide si můžete přečíst, jak z oněch HTML stránek na docs.jboss.org snadno a rychle uvařit PDF.