17. dubna 2008

Porovnání webových frameworků

Včera jsem zkouknul zajímavou prezentaci, kde se autor snaží na základě svých zkušeností a z pohledu různých kritérií porovnat Java webové frameworky (JSF, Spring MVC, Stripes, Struts 2, Tapestry, Wicket).
Pokud si chce člověk udělat takový první názor a nechce si všechny ty frameworky zkoušet, tak mi ta prezentace přijde super.

15. dubna 2008

Výhody a nevýhody EJB

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

14. dubna 2008

Konkurenční přístup k datům - zamykací mechanismy, díl čtvrtý

Dnes bych rád popsal pesimistické offline zamykání. Tento poslední díl mého mini-seriálu o zamykacích mechanismech navazuje na předchozí tři díly (1, 2, 3).

Důvody, proč někdy nestačí online zamykací mechanismy jsem popsal v minulém díle, nyní se budu tedy hned věnovat samotnému pesimistickému zamykání.

Pesimistické offline zamykání

Tento typ zamykání se nám hodí zejména v takových případech užití, kde pravděpodobnost "střetu" je velká nebo následky velké. Jen pro úplnost dodávám, že se jedná o offline zamykání, protože jinak bychom mohli použít Pesimistické online zamykání.

Tento typ zamykání je řešen na aplikační úrovni aplikace a před jeho realizací je nutné si zodpovědět následující otázky:
  • Co je potřeba zamykat? Objekt, mapu objektů nebo bude stačit jen určitý atribut objektu? Může se hodit např. tento přístup od Martina Fowlera.

  • Kdy se data budou zamykat a odemykat?

  • Jaký typ zámku použiji? Použiji zámek pouze na zápis dat nebo i pro jejich čtení?

  • Jak budu identifikovat vlastníka zámku? Bude to HTTP Session ID nebo uživatelské ID nebo něco jiného?

  • Jak budu udržovat zámky? Bude mi stačit interní paměť nebo budu potřebovat databázi.

  • Jak budu uvolňovat zámky? Mám na mysli standardní případy, kdy někdo bude mít zamknutá data a odejde na oběd. Má se zámek po určité době automaticky uvolnit, dovolíme jiným uživatelům tento zámek získat?


Těch otázek není málo a od jejich odpovědí se odvyjí implementace. Znám dvě:
  • Centrální zamykací systém (lock manager). Tento způsob používám, protože se mi líbí, že je to neinvazivní způsob (nemusím měnit objekty, pouze kde potřebuji přidám LockManager), je to centralizované řešení a dle potřeby mohu zvolit implementace uložení zámků - paměť vs. databáze.

  • Ukládání zámků přímo v objektech. Ty objekty, které potřebuji zamykat vybavím speciálními atributy, abych poznal, že daný objekt je nebo není zamknutý.



Pozn.: Většinu informací, které jsem v této sérii článků prezentoval, jsem našel v knížce POJO in Facade.

6. dubna 2008

Konkurenční přístup k datům - zamykací mechanismy, díl třetí

Jak jsem již zmiňoval v předchozím díle, dnes bych se věnoval tzv. offline zamykacím mechanismům. Offline zamykací mechanismy přicházejí v úvahu, když nemůžeme využít online (předchozí) mechanismy, tj. hlavně když

  • jedna transakce by běžela příliš dlouho
  • realizace případu užití se skládá z více transakcí

Optimistické offline zamykání

Pokud bych to měl stručně vyjádřit, tak myšlenka a implementace je velice podobná jako u optimistického zamykání z prvního dílu, jen s tím rozdílem, že zde se nepohybujeme pouze v rámci jedné transakce.

Příklad:
  • Transakce A1 načte objednávku a uloží číslo verze (nebo jinou informaci, podle které je možné rozlišit různé verze objektu) do session.
  • Transakce B1 načte a zruší objednávku, což způsobí změnu verze
  • Transakce A2 se pokusí změnit objednávku. Protože se změnil stav objednávky resp. se změnila verze, tak změna neprojde.

Implementace: jak již bylo naznačeno, optimistické zamykání funguje na principu porovnání stavu objektu po načtení a před úpravou. Toho lze docílit buď evidencí verze, časového razítka nebo přímo porovnáním hodnot. Offline porovnání má ještě to specifikum, že je potřeba informaci o verzi uchovat přes více transakcí. Vhodné úložiště je uživatelská session.

Pro optimistické offline zamykání se nabízí ještě jedna možnost implementace - přes detašované objekty. Načtu objekt z databáze a uložím detašovanou verzi objektu někde bokem, např. v uživatelské session. Uživatel provede operaci, hodnoty detašovaného objektu se nám změní. Aplikace se pokusí převést tento objekt znovu do persistentního stavu a zde nám ORM nástroj dá sám vědět, zda pracujeme pořád nad stejnou verzí objektu nebo ne.
Výhodou tohoto řešení je, že aplikace sama nemusí řešit porovnávání různých verzí objektů, to za nás udělá ORM knihovna. Také se zde neomezujeme pouze na jeden objekt, ale můžeme takto porovnat celý graf objektů.

Použití: vhodné pro takové případy užití, kde se pracuje s daty přes více transakcí, kde je malá pravděpodobnost konkurenčního přístupu nebo tolik nevadí návrat zpět po neúspěšném pokusu změny dat. Také se tento typ zamykání hodí pro ty případy, kde máme problémy se zajištěním vymazání zámku (viz dále pesimistické offline zamykání).

Popis s diagramem tohoto patternu lze nalézt na stránkách Martina Fowlera.

Myslel jsem, že ten můj miniseriál již dnes ukončím, ale bude ještě jeden díl - Pesimistické offline zamykání.

1. dubna 2008

JSF a Spring - postup o krok dále

Velice mě zaujala prezentace o možnostech integrace JSF a Springu, hlavně tzv. Spring-centric JSF Integration Approach.

Uvedu jen základní informace (vše ostatní je v prezentaci):
JSF plugs into Spring as a View implementation
• Integrates with Spring MVC and Web Flow
• FacesServlet is not used

Spring is used
• As the managed bean provider
• As the request dispatcher
• As the navigation handler
• As the state manager
• As a lightweight JSF component library

Mimo jiné mě také zaujalo toto - "The ability to inject the result of an EL expression evaluation into a managed bean" - to by mělo být dostupné ve Springu 3.0.

Pro mě jako Springaře je to dobrá zpráva, protože na mě kolegové pořád tlačí s JSF a Seamem a takhle budu mít zase o něco lepší alternativu k jejich návrhům.