Dost často kolem sebe slyším při rozhovorech o vhodných technologiích pro určitý projekt, že použijeme EJB, tím se nedá nic zkazit. Je to prověřená technologie, je to dostatečně enterprise, je to standard, takže vlastně nejsou žádné důvody, proč to nepoužít.
Já si myslím, že těch nevýhod může být celkem hodně. V tomto článku bych rád některé nevýhody prezentoval:
- Testovatelnost aplikace - pokud chci testovat EJB, tak potřebuji EJB kontejner. Sice existuje pěkná knihovna Jakarta Cactus, ale přeci jen to není tak přímočaré, jako když mám POJO. Nebo mohu použít Embedded EJB kontejner, popis zde.
- Přenositelnost - myslím, že každý ocení, když někde vyvine aplikaci, kterou pak může nasadit na libovolný server tak jak je, bez nějaké další potřeby konfigurace aplikačního serveru. Obecně se dá říci, že kolečko develop-test-deploy je rychlejší u lightweight řešení než u řešení s EJB.
- Rychlost spouštění - jakýkoliv server, který obsahuje něco více než čistý webový Java kontejner se mi bude spouštět pomaleji. A během vývoje takový server pouštím opravdu často. Ano, nepoužívané služby si mohu vypnout, ale pak je otázka, proč potřebuji plný J2EE server. Proto se mi moc líbí myšlenka profilů ve specifikaci J2EE 6.
- Náklady na EJB server - samotný EJB server se sehnat nedá (nebo dá?) a pokud je tedy EJB (přesněji řečeno EJB kontejner) potřeba, člověk musí sáhnout po J2EE serveru. Jedna věc jsou náklady na pořízení serveru, druhá věc jsou náklady spojené s instalací a školením pro práci s J2EE serverem. Přeci jen vše je složitější než Tomcat :).
Některé nevýhody jsou více či méně významné, nutné je také brát velký posun od EJB 2.1 k EJB 3.0 (nevýhod EJB 2.1 je o dost více, ale ty zde neuvádím). Nechci, aby tento článek vyzněl, že nemám rád EJB, to není vůbec pravda. Já se jen snažím říci, že EJB ano, ale jen pro ten typ aplikací, kde je to opravdu potřeba, protože EJB je "heavyweight" technologie, což sebou přináší určité nevýhody. Typický příklad - pro webovou CRUD aplikaci nad jednou databází bych EJB nepoužíval.
Kromě nevýhod má řešení s EJB i spoustu výhod:
- EJB je řešení pro distribuované aplikace, tj. aplikační logika nebo aplikační komponenty jsou umístěny na více serverech (nemyslím cluster) nebo aplikace má několik typů klientů včetně tlustého klienta.
- EJB zjednodušuje psaní vícevláknových aplikací
- EJB nabízí transakční kontejner, který umožňuje efektivní řešení transakcí přes více datových zdrojů
- pokud je distribuovaná EJB aplikace dobře napsaná, tak lze docílit větší robustnosti a škálovatelnosti aplikace než když aplikace bude bez EJB umístěná na jednom serveru.
Výhod je tedy hodně, ale potřebuji nebo ocením toto vše pro mojí aplikaci? Pokud ne, tak EJB nepotřebuji a mohu využít výhod lightweight aplikací.
Příspěvky
14 komentářů:
EJB je řešení pro distribuované aplikace, tj. aplikační logika nebo aplikační komponenty jsou umístěny na více serverech (nemyslím cluster) nebo aplikace má několik typů klientů včetně tlustého klienta.
Tak tomu se priznam vubec nerozumim. Kdyz to neni cluster, tak jak se tomu rika.
EJB zjednodušuje psaní vícevláknových aplikací
To povazujete za vyhodu, ze si nemuzete ridit concurrency na vlastnim kodu? A nebo, ze neexistuje jednoduchy zpusob, jak neco volat asynchronne.
EJB nabízí transakční kontejner, který umožňuje efektivní řešení transakcí přes více datových zdrojů
Rika se tomu JTA a muzete to pouzivat i bez EJB.
pokud je distribuovaná EJB aplikace dobře napsaná, tak lze docílit větší robustnosti a škálovatelnosti aplikace než když aplikace bude bez EJB umístěná na jednom serveru.
To tezko, minimalne co se tyka skalovatelnosti. Jedine co EJB nabizi v oblasti skalovatelnosti, a co nedostanete "zadarmo" jinde, je skalovani na urovni volani metody, ale to nema vyznam pokdu neni cluster.
Samozrejme EJB ma svoje vyhody, ale to je dane jenom tim, ze sami vyrobci aplikacnich serveru nektere veci odladili. Ale tahle "konkurencni" vyhoda pomalu pada a Javou 6 bude minimalne omezena.
Mozna nez o vyhode bych mluvil o vecech, ktere funguji a jinak se budou delat tezko:
- vnorene transakce
- neleakujici JMS listenery aka MDB
No a pak je ten zbytek, ktere mozna ocenite v 5% pripadu jako napriklad JCA.
ad cluster: chtěl jsem tím říci, že to nebude jedna aplikace na více strojích, ale jednotlivé části aplikační logiky (komponenty) na více strojích.
ad vícevláknové aplikace: ano, to považuji za výhodu, protože ve většině aplikací mi to bude pomáhat a bude mě to zbavovat starostí.
ad JTA: nevím, zda JTA API je ideální rozhraní na používání :). Je tedy určitě rozumné používat něco nad JTA, aby se s tím lépe dělalo - a to mohou být EJB nebo třeba Spring (JtaTransactionManager) nebo něco jiného. Ale nechtěl jsem Spring do tohoto článku vůbec tahat...
ad škálovatelnost: toto nemám ze své hlavy, ale je to tvrzení Roda Johnsona. Když si vezmu, že aplikace bude distribuovaně rozmístěna na více serverů, tak tam vidím skoro neomezené možnosti škálování.
Tech vyhod a nevyhod je opravdu hodne. Urcite je snad nejvetsi opruz testovani (skoncil jsem u vlastniho reseni), nemoznost hotdeploy a posledni veci je JNDI. Nikde neni JNDI poradne standardizovano a kdyz se podivam na JBoss vs. Glassfish, je skoro nemozne napsat vetsi aplikaci tak, aby bezela beze zmen na obou serverech :/
Na druhou stranu ma EJB i spousty vyhod:
Neni treba resit zavislosti knihoven tretich stran. JTA, JPA ci JMS spolecne s EJB je dobra volba. I kdyz na to muze nekdo nadavat, tak je to spise o moznostech pouziti.
Ja si treba na JTA tolik stezovat nemohu. Veci ktere mi nefungovali byly temer vzdy zpusobene moji chybou, nikoli nemoznosti to pres JTA nastavit. Proste umozni ingorovat hromady kodu a ruznych try-catch bloku.
Jednoduche DI v podobne anotaci je take hezka vychytavka. At uz to jsou jine EJB komponenty nebo ruzne resources.
Distribuovana java, pres Remote rozhranni se skutecne da psat dobre desktop aplikace. Nebo spojeni vice AS treba prave pres remote call.
Nevim co si mam predstavit pod vicevlaknovou aplikaci, ale kdyz neco budu delat asynchronne, pujdu pres JMS.
Co se tyce ceny, tak to je podle meho blbost.
1. JBoss nebo Glassfish jsou casto dostacujici, pokud ne, tak pujde o vetsi projekt, kde cena AS bude miziva oproti ostatnim nakladum
2. Specifikace je jasne popsana a az na par vyjimek (vychytavek) ruznych AS.
Presto uznavam, ze na psani aplikaci typu: 10 objektu v DB, 5 klientu aplikace + neexistence napojeni na dalsi zdroje; je EJB dost tezkopadne a skutecne k nicemu.
Ale aplikace preci nejsou jen 10 objektu v DB, 5 kli.... :)
ad vicevlaknove aplikace.) prave snaha o zakryvani komplexnosti v teto oblasti je hodne sporna. Od EJB 3.1 chteji tohle zmenit "Specification of concurrency options for stateful session beans.".
ad JTA.) a v pripade BMT to EJB usnadnuje jak? Nijak, je to uplne ekvivalentni tomu, kdyz se to pouziva mimo EJB.
ad saklovatelnost.) no skalovat to nemusi, zalezi na tom jak bude aplikace napsane a jaky bude overhead toho distribuovaneho volani. IMHO je daleko lepsi ve vetsine pripadu skalovat na urovni HTTP pozadavku.
Nevim co si mam predstavit pod vicevlaknovou aplikaci, ale kdyz neco budu delat asynchronne, pujdu pres JMS.
No ale to je pekny opruz... Opet odkazu na EJB 3.1 "Support for asynchronous session bean invocation.". Proc by to tam asi tak davali kdyz je k dispozici JMS? Odpovim si sam, protoze EJB je silene tezkopadne na pouziti.
ad JTA: Já bych asi BMT vůbec nepoužíval...
ad škálovatelnost: V článku jsem psal, že aplikace musí být dobře napsaná, tedy hlavně vše stateless. Jinak souhlasím, že nejlepší je škálovat na webové (prezentační) vrstvě, ale když se bavíme o "enterprise", tak to vždycky stačit nemusí.
Romane, musím se trochu sám sobě smát, protože jsem ten článek začal psát s tím, abych našel co nejvíce důvodu proti EJB, ale teď to vypadá, že EJB hájím :). Mám z EJB úplně stejný pocit jako ty - je to moc těžkopádné.
>Roman
Paci sa mi ta tvoja "objektivnost", Roman. Veci ako "No a pak je ten zbytek, ktere mozna ocenite v 5% pripadu jako napriklad JCA." mozes napisat iba ak mas naozaj skusenosti s velkymi enterprise aplikaciami pre velke korporacie, kde sa clusteruje, skaluje a integruje o sto tristo.
J2EE nie je vseliek na vsetky problemy, ale vo svete javovskych enterprise rieseni nema konkurenta. Tym mam na mysli napr. specifikacie a skalovatelnost. Tu sa spring jednoducho nechyta...
Dle mého názoru bych vůbec nestavěl J2EE vs. Spring. Není problém přeci využívat J2EE a tam kde mi to přinese přidanou hodnotu, tak budu používat Spring.
Když to přeženu, tak Spring sám o sobě skoro nic neumí, snaží se jen o lepší práci se stávajícími J2EE specifikacemi. Pár příkladů: JDBC vs. Spring JDBC, LDAP vs. Spring LDAP, transakční manažery atd.
to Milos> Aby jsme si porozumneli. Vemte vedle sebe sto aplikaci napsanych nad J2EE platformou, kolik z nich bude asi potrebovat neco jineho nez Servlety, JSP, a mozna JSF ci JPA? Jajenom rikam, ze tech aplikaci bude hrozne malo. To ze dezinterpretujete moje slova je vec jina a uz vubec se mi nelibi, ze mi podsouvate Spring, o kterem se vubec nezminuji.
"Tym mam na mysli napr. specifikacie a skalovatelnost."
To s tou skalovetelnosti je jeden velky mytus! Proc, kdyz je J2EE skvely koncept v oblasti skalovatelnosti, tak voli vsichni jina reseni viz napriklad eBay. Znate stranku http://highscalability.com/, kolik zminek o J2EE tam najdete? Podivejte se jaky smer reseni se vybira pro vypocetne a pametove narocne ulohy v Jave a jak do toho fituje cele J2EE s jeho konceptem one size fits all. Co je a neni potom enterprise? Koncept J2EE tak jak ho zname dnes nema sanci na preziti, dukazem budiz to co panove planuji pro J2EE 6.
Kazda technologia nevynimajuc J2EE prechadza svojim vyvojom.
Ja mam taky pocit, ze problem tejto diskusie je ten, ze vsetky argumenty, ktore sa tu prezentuju proti j2ee nie su zalozene na realnych skusenostiach na projektoch, kde sa j2ee hodi. Skor mam dojem, ze je to o tom co si kto precital, stotoznil sa s tym a prezentoval dalej...
No me to prijde prave naopak. Kazdy kdo obhajuje J2EE az za hrob, to nemohl v zivote pouzivat. Nevim jaka je Vase zkusenost, ale ta moje je zalozena na zkusenostech s projekty, ktere behaly snad na vsech komercnich aplikacnich serverech + JBossu. Rozdil mezi nami je v tom, ze ja jsem schopen uznat, ze jsou typy aplikaci, ktere mohou J2EE vyuzit. Jenom podotykam, ze tech aplikaci bude velke minimum. Jinak samozrejme nemam problem priznat, ze se ztotoznuji s negativnimi nazory na nektere casti J2EE, protoze mi mnohdy prijdou z moji vlastni zkusenosti opodstatnene.
Uz v samotnom uvode som spominal, ze j2ee nie je vseliek na vsetko. Tym som chcel povedat, ze na vela veci je to kanon na vrabca. Samozrejme existuje vela pripadov, kde je rozumnejsie siahnut po niecom jednoduchsom. V tom teda medzi nami rozdiel nie je ;).
"Jenom podotykam, ze tech aplikaci bude velke minimum."
Toto je relativne. Zalezi ci sa na to pozerame podla poctu projektov alebo podla ich velkosti resp. ceny.
Javu jsem z pc odstranil a nikdy bych si ji dobrovolně nenaistaloval. Chyby v zabezpečení, které java obsahuje, jsou v tak velkém množství, že používat toto prostředí může jen blázen. Vlastně co používám počítač na mnoho různých činností práce s hudbou, grafikou, stříhání videa, kancelář, tak jsem program v javě nikdy nepotřeboval. A java je pomalá jako slimák.
Okomentovat