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

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.

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

Jak už název napovídá, celá přednáška měla být o tom, jestli už se Java vyvinula natolik, aby v ní bylo bezproblémové vyvíjet enterprise aplikace. Začíná zajímavým ohlédnutím do roku 2003, kdy jedinými masově rozšířenými open source projekty v Javě byly Struts a Log4j. Upozorňuje také na zajímavý posun v myšlení vývojářů. V roce 2003 panovalo přesvědčení, že na to, aby mohla být technologie úspěšná, musí být i komplexní. Dnes už tomuto věří málokdo.

Dle svého zvyku se přednášející obouvá do EJB. Hlavně do jejich snahy skrýt některé věci před vývojáři (pooling, starání se o vlákna atp.) Zaujaly mě následující hlášky

Když se k vývojářům budeme chovat jako k opicím, jediné co dostaneme bude tlupa naštvaných opic.

Je zásadní chybou definovat infrastrukturu a architekturu s tím, že architekti a vývojáři jsou hloupí.

Tento problém nemají jen EJB, setkáme se s tím i u všelijakých vlastnoručně psaných frameworků. Podle Roda Johnsona se omezením kreativity vývojařů o hodně připravíme. Toto téma vede k zamyšlení nad standardy a specifikacemi. Dovolím se opět ocitovat

Specifikace dobře pochopených problémů jsou úspěšné.

Je snadné standardizovat něco, co se za dvacet let nezměnilo.

Evidentními příklady jsou JMS, JTA a JNDI. Jsou to věci, které v době jejich specifikace byly dobře prozkoumány a jejich standardy jsou tím pádem úspěšné. Naproti tomu standardizování věcí, které ještě nejsou dobře prozkoumány vede k problémům (např. entity beany)

Zásadní myšlenka zazněla přibližně uprostřed prezentace.

Většina Java aplikací není objektově orientována.

Nejprve mě to překvapilo, ale pak jsem si uvědomil, že má pravdu. Uvědomme si, že objekt je cosi co seskupuje data a chování do jedné entity. Podíváme-li se na klasickou třívrstvou Java aplikaci, zjistíme, že tříd, které by měly obojí je tam minimum. Máme servisní vrstvu, která je obvykle bezstavová a kromě konfigurace v sobě moc dat nemá. V podstatě obsahuje jenom chování. Na druhé straně pak máme doménový model, který obvykle jenom drží data a neobsahuje žádné chování. To je zajímavé. Všichni tvrdíme, že OOP je dobrý nápad, ale přesto programujeme více méně procedurálně. Připravujeme se tím o spoustu výhod, které nám OOP nabízí.

Obchodní logika v servisní vrstvě není znovupoužitelná.

Co s tím? Řešením je přesunout logiku do doménových objektů. Tzn. místo toho abychom měli službu, která zaregistruje mazlíčka u veterináře, mít příslušnou metodu přímo u třídy reprezentující veterináře. Narazíme zde ale na jeden problém. Jak nainjektovat podpůrné služby do doménového objektu? Přes Spring to nejde, doménové objekty jsou obvykle instanciovány OR nástroji. Řešením je AspektJ. Napíšeme si malou anotaci (nebo XML konfiguraci) a můžeme injektovat přímo do doménového modelu. Pan Johnson tvrdí, že se tím výrazně zvýší znovupoužitelnost kódu.

V poslední části prezentace uvidíme zajímavou studii interceptorů v EJB 3. Zde se autoři specifikace nepoučili ze zkušeností AOP aliance a rozhodli se, že si problém AOP vyřeší po svém.

Ve skutečnosti nezáleží na tom jak je člověk chytrý, když mu chybí zkušenost.

U EJB 3 máme AOP bez pointcutů. Tzn. jediný způsob jak určit, kdy se interceptor zavolá, je přidat ke třídě nebo metodě příslušnou anotaci (nebo se vrhnou do ekvivalentní XML konfigurace). Není možné říci například, že chci mít interceptor kolem všech metod v tomto balíku. To je přinejmenším nepohodlné. Není možné říci, že chci volat interceptor jen u metod, které mají parametr daného typu. To už je i náchylné na chybu.

EJB interceptory jsou experimentální.

Ano, ještě nikdo nikdy nezkoušel dělat AOP bez pointcutů. Dá se očekávat, že se přitom narazí na problémy.

A jak zní odpověď na otázku v názvu prezentace? Dovolím si zde použít citát z Murphyho zákonů

Končí-li novinový titulek otazníkem, zní odpověď "ne".

Zbývá ještě dost problémů, které je třeba v Javě vyřešit, než budeme moci říci, že vývoj enterprise aplikací je v ní bezproblémový.

Upozornění: V tomto příspěvku se mísí citáty Roda Johnsona s mojí interpretací. Netvrdím, že všechno co zde píši řekl, je to spíš o tom co jsem si z toho vzal já. Pokud chcete informace nezkreslené, vřele doporučuji originál.

EJB 3 nám umožňují psát svoje beany jako normální oanotované POJO. Což nám kromě zjednodušení vývoje přináší i jiné výhody. Jednou z největších je to, že můžeme použít náš kód i mimo kontejner. Nic nám nebrání v tom, abychom vzali EJB a nakonfigurovali je například pomocí Springu. Ale moment, proč bychom je měli konfigurovat? Vždyť už v nich máme anotace, které nám popisují závislosti mezi beany. Máme tam dokonce i anotace, které nám popisují hranice a typ transakcí. Proč nenaučit Spring, aby si tyto anotace přečetl a sám se podle nich nakonfiguroval?

Naštěstí nic takového dělat nemusíme, vyřešili to za nás BEA a Interface21 projektem Pitchfork. Nebudu vás už dál napínat a ukážu vám jak to nakonfigurovat (plnou verzi konfiguračního souboru najdete zde):

<?xml version="1.0" encoding="UTF-8"?>
<beans ...>

	<!-- JPA EntityManagerFactory -->
	<bean id="entityManagerFactory"
	 	class="org.springframework.orm.jpa.LocalEntityManagerFactoryBean">
 		<property name="persistenceUnitName" value="MyPU" />
 	</bean>

	<bean id="txManager"
		class="org.springframework.orm.jpa.JpaTransactionManager">
		<property name="entityManagerFactory" ref="entityManagerFactory" />
	 </bean>

	<bean
	 	class="org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor" />

	<!-- ejb post processor -->
	<bean class="org.springframework.jee.ejb.config.JeeEjbBeanFactoryPostProcessor">
	 	<property name="serviceEnvironment">
	 		<bean class="org.springframework.jee.config.SimpleServiceEnvironment">
	 			<property name="transactionManager" ref="txManager" />
	 		</bean>
	 	</property>
	 </bean>

	<!-- ***************** EJBs *************************** -->
	<bean id="beanA" class="net.krecan.ejb.BeanA" />
	<bean id="beanB" class="net.krecan.ejb.BeanB" />
</beans>

První co jsme nadefinovali je entityManagerFactory, ta nám zprovozní JPA. Dále musíme přidat transaction manager, který se nám bude starat o transakce. Ani to není žádná věda. Dále máme PersistenceAnnotationBeanPostProcessor, který prohledá všechny beany v aplikačním kontextu, projde si jejich anotace a když narazí na @PersistenceUnit nebo @PersistenceContext, injektne tam co je potřeba. Doposud jsme si vystačili se standardními třídami ze Spring 2. Teď přichází na řadu Pitchfork. JeeEjbBeanFactoryPostProcessor je třída, která opět prohledá všechny beany v aplikačním kontextu, projde si jejich anotace a když narazí na EJB anotaci, tak podle ní nakonfiguruje Spring. Tzn. nastaví závislosti mezi beany a podle potřeby vytvoří transakční proxy. Všimněte si tu prosím konfigurace transakcí. Trvalo mi docela dlouho, než jsem přišel na to, že se to musí nakonfigurovat právě takto.

A to je vše, teď už jenom musíme vyjmenovat všechny beany, které chceme použít. To je nezbytný krok. Musíme říci, které třídy chceme konfigurovat. Tím Springu ušetříme spoustu práce s procházením všech tříd v classpath a hledáním těch správných anotací. Sobě tím ušetříme spoustu času při startu kontejneru.

Vidíme tedy, že se dá Springem docela dobře nahradit hodně z funkcionality EJB kontejneru. Otvírá nám to spoustu možností, od snadného testování EJB až po jejich nasazení bez aplikačního serveru. Docela užitečná věc, nemyslíte?

J2EE ≠ EJB

První důležitý bod je to, že Spring se nestaví proti J(2)EE, právě naopak. Dokonce i Rod Johnson (autora Springu) píše, že J2EE je hodně dobrá skupina standardů. Ale je mylné se domnívat, že J2EE = EJB. Pokud se podíváte co to je J2EE tak EJB je jenom jedna část z více než dvaceti! A byl právě důvod, proč vznikl Spring – umožnit snadno používat funkcionalit J2EE.

Vraťme se ale k EJB. Ty nám přinášejí následující věci (převzato z [1]):
1.Declarative Transactions Management
2.Remoting
3.Clustering
4.Resource pooling
5.Security
6.Thread management
7.EJB instance pooling
8.Business object management

Zajímavých je pravděpodobně jenom prvních pět bodů, zbytek využijete jenom pokud máte dostatek odvahy a vrhnete se do SFSB nebo entity bean. V případě že používáte jenom SLSB a MDB, vám poslední tři body žádný užitek nepřinesou (kromě pár starostí).

Projděme si tedy podrobně přínosy, které nám EJB přináší a porovnejme si je Springem

Declarative Transactions Management – Spring nám také umožňuje definovat transakce pomocí anotací (klidně i stejných jako používá EJB) a XML. Navíc tyto transakce fungují i pokud nemáme k dispozici JTA.

Remoting – Spring umožňuje remoting pomocí RMI, Hessian, Burlap, HTTP invokeru a JAX-RPC. Největší legrace je to, že když se rozhodnu změnit technologii, stačí mi změnit pár řádek v konfiguraci. Kód aplikace zůstane nezměněn

Clustering – Jedna z největších výhod EJB. Ale pozor, pokud používáte pouze bezstavové objekty jako SLSB a MDB, je clustering velice snadný. Jste si jisti, že k tomu potřebujete něco tak komplikovaného jako EJB?

Resource pooling – Například pool databázových připojení. To ovšem není vymoženost EJB jako spíše aplikačních serverů. Možné nahradit pomocí C3P0 nebo DBCP

Security – EJB nám poskytují rozsáhlé možnosti zabezpečení. Škoda jen, že si to každý dodavatel aplikačního serveru naimplementoval po svém, takže se můžeme rozloučit s přenositelností. Byla by to jedna z nejužitečnějších přínosů EJB, kdyby ovšem byla dostatečně definována.

Všimněte si že, JTA je ve výčtu chybí. Je to samostatný standard, na EJB zcela nezávislý. Takže argument typu „Pokud potřebujete distribuované transakce, musíte používat EJB“ je naprosto zcestný. JTA můžeme dokonce používat i mimo AS, například pokud použijeme JOTM.

Vidíme tedy, že Spring umí to samé jako EJB. Jak se tedy rozhodnout? V době EJB 2.1 bylo rozhodnutí snadné, pokud jste nepotřebovali žádnou ze specialit EJB jako je clusterování, MDB nebo SFSB bylo lepší zvolit Spring. Ušetřili jste si tak neuvěřitelné množství naprosto zbytečné práce s EJB.

Doba pokročila, EJB prošly kosmetickou operací, při které na starý ošklivý obličej našili masku anotací. Ta ošklivost je tam pořád, ale už ji nevidíme. Což mimo jiné znamená, že už můžeme EJB používat, aniž bychom museli psát (nebo generovat) hromady zbytečného kódu.

Za tu dobu ale i Spring hodně pokročil. Objevily se message driven POJOs, Terracota nám zajistila snadné clusterování i jiných než bezstavových objektů a SFSB pořád ještě nikdo nepoužívá.

Jak si tedy vybrat? Jelikož jsem fanoušek Springu, je odpověď jasná, mám pro to následující důvody:

Zjednodušuje práci s projekty třetích stran

Volání kódu někoho jiného je v podstatě jediné co Spring umí. Umožňuje mi snadno navázat můj kód na různé knihovny a další frameworky. Je důležité si uvědomit, že Spring nic nedělá (až na pár vyjímek). Jenom práci deleguje buď na knihovny nebo aplikační server.

Snadnost práce s nízkoúrovňovými Java standardy

Spring nám zjednodušuje práci s Java standardy, které jsou často hodně nízkoúrovňové. Hezkým příkladem je třeba Java Mail API. Kdo ho někdy používal v čisté podobě ví, že je to API těžko použitelné a kód který ho používá je netestovatelný.

Další příklad je i JDBC, dle mého názoru jedna z nejdůležitějších částí Java API. Opět je to nízkoúrovňové rozhraní, které by nemělo být používáno přímo. Spring nám jeho použití výrazně usnadňuje a navíc nám zamezuje udělat chybu. Malá anketní otázka: když používáte JDBC, jste si jisti, že děláte správně všechno to TCFTC (try{}catch{}finally{try{}catch{}})?

Svoboda výběru

Tím se dostáváme k svobodě výběru. EJB mě nutily pro perzistenci používat entity beany. Když se přišlo na to, že jsou nepoužitelné, nutí mě používat JPA. Pokud ale JPA nechci nebo nemohu používat, už mi nezbude nic jiného než JDBC. Spring mi na druhou stranu říká: „Já ti věřím, že svým potřebám rozumíš natolik, že víš, kterou technologii si vybrat. Ať si vybereš cokoliv, jsem ochoten ti pomoci.“ Takže mi zjednodušuje práci s JDBC, iBatis, JPA, JDO atp. Pokud nevím co si mám vybrat, měl bych se přeškolit na .NET, tam mi to řeknou.

Snadnost konfigurace aneb „Nemáte-li Spring, musíte si ho napsat“

Všiml jsem si, že kdo nepoužívá Spring, napíše si obvykle jeho obdobu. V každé aplikaci potřebuji konfiguraci. Ať už je to čtení nastavení z properties souboru, nebo nějaký druh XML konfigurace. Jelikož mi EJB s tímto ani trochu nepomohou, musím si to obvykle napsat sám. Často se tvoří nějaká SLSB, která konfiguraci načítá a ostatní beany ji využívají. Ale to je přesně to co mi zajišťuje Spring!

Dependency injection

Myslím tím opravdovou dependency injection. Tzn. že si mohu injektnout (šlehnout?) cokoliv kamkoliv. Do jakékoliv třídy mohu vložit string, odkaz na soubor, jméno třídy, referenci na cokoliv, mapu, list, preperties soubor, zkrátka cokoliv mě napadne. EJB jsou v tomto směru dost omezené. Zde bych si dovolil varování. Tato vlastnost Springu je neuvěřitelně návyková. Jakmile si na DI zvyknete, už se vám bez ní bude neuvěřitelně špatně pracovat. Takže pokud chcete pracovat s EJB, radši si se Springem nezačínejte.

Spolupráce s MVC frameworky

Spring podporuje všechny možné MVC frameworky. EJB podporují JSP, servlety a JSF. SLSB prostě nikam jinam neinjektujete.

Dostupnost prostředí

Aplikaci napsanou ve Springu mohu použít v jakémkoliv prostředí, které mi poskytuje služby, které potřebuji. Pokud souhlasíme s tvrzením, že 90% procent aplikací je jednoduchých, tak nám stačí Tomcat nebo Jetty. Aplikaci, napsanou v EJB 3, mohu zatím nasadit na jednom jediném AS, který na tom jen tak mimochodem není moc dobře se stabilitou.

A jaké jsou nevýhody Springu? Jednou z největších je politika. Za EJB stojí velké společnosti a neuvěřitelné množství peněz. Velcí klienti jako třeba banky mají (nebo spíše měli) nedůvěru k open source řešením. I když i to se mění, už i BEA začala výrazně podporovat Spring. To by moho nedůveřivcům něco naznačit. A už i velké společnosti pomalu začínají chápat, že použití nebo úprava open source řešení jim zajistí levnější a kvalitnější produkt, než kdyby jen spoléhali na standardy nebo řešení velkých výrobců.

Objevuje se argument, že EJB 3 jsou pro programátora snazší než Spring. Existuje ale projekt Pitchfork, který Springu umožňuje číst EJB anotace a konfigurovat svůj application context podle nich (o Pitchworku plánuji něco napsat v brzké době). EJB 3 navíc nejsou vůbec jednoduché, jenom se tak na povrchu tváří. Kdo si myslí, že jsou jednoduché, ať mi odpoví na následující otázky. První kdo na ně odpoví a nemá iniciály M.R. získá nehynoucí slávu:

1) EJB 3 umožňují získat referenci na SLSB z JNDI následovně

    InitialContext ic = new InitialContext();
    Hello  hello = (Hello)ic.lookup(Hello.class.getName());
    hello.hello();

Otázka je následující:
a) Na co ukazuje reference hello? (Je to home objekt, nějaká proxy, ...)
b) Musí mít každý klient svoji referenci, nebo je bezpečné ji sdílet?
c) Je potřeba ji nějak vracet do poolu?
d) Co se stane, když po tom co referenci získám a před tím než ji použiji dojde k přerušení spojení s aplikačním serverem?

2)Je bezpečné injektnout SFSB do servletu?

Reference

[1] Johnson, Rod; J2EE Developement without EJB; Wiley Publishing; 2004

[2] Sriganesh, Rima Patel; Mastering Enterprise Java Beans 3.0; Wiley Publishing; 2006