Rozhodl jsem se, že se už konečně pořádně naučím EJB. Ano, opravdu, já zavilý odpůrce této technologie, jsem se rozhodl, že poznám nepřítele a to pěkně podrobně.

Začal jsem knihou Head First EJB vřele doporučuji všem, kteří chtějí pochopit EJB. Stejně jako ostatní knihy Head First série nás do tématu uvede hravou a zábavnou formou. Ač je to neuvěřitelné, pokrývá skoro všechny oblasti EJB a to tak, že je pochopíte a zapamatujete si je i při prvním čtení. Nevýhodou této knihy je to, že popisuje EJB 2.0, takže už se zdá trochu pasé. Ale je to zajímavé čtení, které všem doporučuji. Mimo jiné i proto, že stejné jádro je i v EJB 3 i když je notně přikrášleno anotacemi.

Hodně poučné pro mě bylo studium chyb v návrhu a problémů, které tyto chyby působí. Jedna z nejmarkatnějších je recyklace rozhraní. Autoři specifikace se rozhodli, že všechny typy beanů budou sdílet společná rozhraní. Je úplně jedno, že mají úplně jiný životní cyklus a účel, všechny se musejí tvářit jako že jsou v podstatě zaměnitelné. Dostáváme se potom do nepěkné situace, kdy uživatel SLSB vidí na rozharní EJBObjektu nesmyslnou metodu getPrimaryKey. Autor SLSB musí naimplementovat metody ejbActivate a ejbPassivate, které stejně nikdy nebudou zavolány. Stejně tak si může v EJBContextu zavolat metodu setRollbackOnly jenom pokud zrovna používá CMT, když je v BMT, tuto metodu vidí, ale zavolat ji nesmí. Toto nepíši protože bych chtěl kritizovat, nepochybuji o tom, že autoři specifikace měli jenom ty nejlepší úmysly. Je podle mě dobré si ale takovéto chyby uvědomit, abychom je neopakovali.

V tomto případě je zdroj problému zřejmý. V EJB 2 se řeší konfigurací něco by se mělo řešit kódem. Jestli je session bean stateless nebo statefull se určuje v XML souboru. To by naznačovalo, že je to jenom otázka konfigurace a až při deploymentu se rozhodneme jakého typu daný bean bude. To je samozřejmě nesmysl. SLSB a SFSB jsou objekty s naprosto jiným životním cyklem i použitím a jejich kód rozhodně zaměnitelný není. Celá mašinérie EJB by byla mnohem snazší na pochopení, kdyby měl každý typ beanu svá vlastní rozhraní. Nemá smysl psát do konfiguračního souboru něco, co stejně konfigurovat nejde. Co si z toho beru za ponaučení?

Nebudu recyklovat rozhraní.

Nebojte, neustrnul jsem jen u EJB 2. Vrhl jsem se i na verzi 3, ale o tom snad někdy příště.