Category Archives: Knihovnička SE

EJB 3 – injektujeme SFSB

(aneb vstřikujeme zrnka sezení plná stavu)

Konečně jsem našel odpověď na otázku, která už mi dlouho ležela v hlavě. Přivedl mě na ni kolega, který na jednom firemním setkání Javistů někdy před rokem nadnesl otázku „Co se stane, když injektnu stateful session bean do servletu?“

Zajímavé co? Stejná otázka se samozřejmě nabízí i u stateless beanů. Co se stane, když něco co drží stav injektnu (vnesu??) do objektu, který je bezstavový.



@Statefull
public class Cart {
 ...
}

@Stateless
public class Shop
{
  @EJB private Cart cart;
  ...
}

Tak co, víte co se stane? Já už ano. Odpověď mi poskytla docela pěkná kniha EJB 3 in Action. Na straně 136 se dočteme:

Mějte na paměti, že nesmíte injektovat stateful session bean do bezstavového objektu, jako je stateless session bean nebo servlet, který může být sdílen více souběžně přistupujícími klienty (v takovýchto případech používejte JNDI)

Hurá, otázka zodpovězena. Jak tento problém řeší Spring? Ten sice nemá žádný ekvivalent SFSB, ale od verze 2 má tzv. scopy (rozsahy) beanů. Je tedy možné, injektnout bean, který se váže na HTTP session uživatele, do beanu, který je sdílen mezi všemi uživateli? Co se stane v tomto případě? Nenastane stejný problém jako u EJB? To je to ale napínavé co?

Nenastane! Springu totiž můžete říci, aby neinjektoval původní bean, ale proxy. Ta ohlídá aby každý uživatel (session) dostal svoji verzi i v kódu, který o scopu a stavech vůbec nic netuší. Tato proxy se také stará o vytvoření beanu, pokud je to potřeba. Více podrobností naleznete v dokumentaci Springu.

Jak jsem potkal EJB

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ě.

Knihovnička softwarového inženýra: Agile software development

Dnes budu psát o knize Agile Software Development, Principles, Patterns, and Practices od pana Roberta C. Martina. Je to poměrně tlustá kniha, na které je vidět, že je koncipována spíše jako učebnice. Trochu mě zklamalo, že se Agilnímu vývoji příliš nevěnuje. Budu-li hodně přísný, o agilním vývoji je jenom prvních 85 stran z asi pěti set.

V první části se seznámíme se základními principy agilního vývoje. Tato část je zakončena úžasným příkladem na programování řízeným testy (TDD). Můžete ho najít na zde. Ve zkratce jde o příklad, kdy se dva programátoři snaží napsat software pro počítání stavu hry v bowlingu. Je na něm ukázáno to, že ač se můžeme ve fázi návrhu snažit sebevíce, TDD nás může dovést k mnohem elegantnějšímu a jednoduššímu návrhu.

Druhá část knihy se jmenuje Agile design. S agilními metodikami to nemá podle mě nic moc společného. Autor tu ukazuje několik základních principů, kterými bychom se při návrhu tříd měli řídit ať už programujeme agilně nebo ne. Mezi jinými tu například podrobně popisuje Open-Closed Principle.

Zbytek knihy je více méně hodně podrobný úvod do návrhových vzorů. Zde se čtenář může seznámit skoro se všemi návrhovými vzory, včetně příkladů, UML diagramů a výpisů kódu v různých jazycích. Občas tu člověk narazí i na hodně zajímavou myšlenku, ale musím se přiznat, že tato část knihy je těžko stravitelná a některé části jsem úplně přeskakoval.

Docela zajímavá byla kapitola o závislostech mezi balíčky. U ní si člověk uvědomí jak by měl řešit rozdělení aplikace na komponenty, jak by měly vypadat závislosti, proč jsou špatné cyklické závislosti atp. Naučíte se tu dokonce spočítat míru abstraktnosti balíčku.

Hodně zajímavé jsou dvě z příloh. První je esej s názvem „What Is Software Design?“ Docela dobře ji vystihuje tento citát

Softwarový návrh není hotov, dokud není nakódován a otestován.

Doporučoval bych to pro přečtení všem, kteří věří tomu, že se dá software navrhovat malováním krabiček v UML nebo psaním dokumentů ve Wordu.

Další příloha je zajímavý příspěvek zvaný „A Satire of Two Companies“. Jde o satiru porovnávající agilní vývoj s vodopádem. Člověku při čtení občas zamrazí v zádech.

Takže abych to nějak shrnul, kniha je to zajímavá, rozhodně bych ji doporučil jako učebnici pro výuku softwarového inženýrství. Pokud se ale chcete něco dozvědět o agilním programování, sáhl bych asi jinam.