pátek 4. května 2007

J2EE zakázané techniky - vlastní thready

Jedním z pochybení, kterého se vývojáři enterprise/web aplikací v Jave dopouštějí je vytváření vlastních vláken za účelem asynchronní exekuce. Typicky se jedná o spouštění dlouhotrvajících procesů (generování reportů, odesílání velkých dat atd.) z prohlížeče a nebo o různé formy plánovačů např. pro čištění dočasných prostředků jako cache. Avšak využívání threadů k těmto účelům uvnitř aplikačních serverů je zakázáno a existují pro to rozumné důvody.

  • Aplikační server je zodpovědný a musí garantovat správu zdrojů, proto je velice nepěkné vytvářet/alokovat nějaké zdroje bokem mimo jeho kontrolu. Odpadá tím například výhoda sdílení těchto zdrojů mezi aplikacemi.
  • Není na škodu si připomenout, že EJB specifikace přímo vytváření threadů zakazuje. Některé aplikační servery, jako například IBM WebSphere, dokonce neumožňují práci (vyhození výjimky) s prostředky aplikačního serveru pokud není thread spravován přímo aplikačním serverem.
  • Thready nejsou vhodné z hlediska clusteru např. failover, není je možné jednoduše restartovat a případný pád serveru nepřežijí. Samozřejmě netriviálním naprogramováním vlastního API, lze i toto vyřešit.

Každý aplikační server (JBoss, WebLogic, WebSphere) přitom nabízí oficiální prostředky pokryté specifikací a někdy i proprietární pro dosažení asynchronního zpracování. Samozřejmě v případě servletových kontejnerů jako Tomcat nebo Jetty je situace horší.

JMS

Základním prostředkem pro dosažení asynchronního zpracování je JMS (Java Message Service). Tuto službu musí mít každý J2EE server. JMS participuje v transakcích (odeslání/zpracování zprávy), je reliabilní - potvrzení přijmu, persistentní (přežije pád serveru), durable subsription a umožňuje posílání zpráv 1:1 a 1:M. Pokud je k dispozici JMS není co řešit.

Work Manager API

Work Manager API nabízí nepřímo vypůjčení threadů aplikačního serveru pro potřeby aplikace. Je sice pokryté JSR-237, ale není součástí J2EE specifikace, avšak jak aplikační server WebLogic taki WebSphere jej podporuje. Pokud tedy potřebujete k něčemu asynchronní exekuci a JMS nemůžete z nějakého důvodu použít, měl by být tento způsob preferovaný.

The Spring TaskExecutor abstraction

Spring TaskExecutor abstraction je abstraktní vrstva poskytovaná Spring frameworkem, která umožňuje asynchronní exekuci s možností nastavení vlastního thread poolu. Použití tohoto API bych doporučil z důvodů přenositelnosti, protože je možné snadno nastavit, aby se thready alokovaly pomocí Work Manager API (WebLogic, WebSphere) a nebo bokem (Tomcat, Jboss), když není možnost získat managed thready.

Výhoda tohoto řešení je v tom, že v prostředí, kde jsou thready spravované aplikačním serverem, lze tyto thready získat legálně. Tam kde tato podpora není, sice dochází k alokaci bokem, ale pokud se v dalších verzích produktu objeví, nebude problém změnou konfigurace přejít na její použití. Tento přístup může být preferovaný i pro deploymenty, kde není JMS k dispozici a nebo by jeho rozběhnutí složité.

Několik rada na závěr, pokud máte nutkání vytvářet nový thread:

    vždycky si dvakrát rozmyslete, jestli není k dispozici lepší (standardní) cesta, jak dosáhnout toho samého
  • vytvářejte pouze počet threadů, které opravdu potřebujete někdy opravdu stačí jenom jeden
  • pokud už takový thread máte, snažte se, aby nesahal na zdroje spravované aplikačním serverem

čtvrtek 3. května 2007

CZ podcast volume #10 - novinky

Podcast s pořadovým číslem deset přicházel na svět ve velkých porodních bolestech, protože Filemonova pracně nastavená infrastruktura trochu zklamala a Roumen pro jistotu odletěl na J1 bez toho, aby se s námi podělil o svůj audio stream. Každopádně podcast je tu a doufám, že se bude líbit. Při jeho poslechu se dozvíte opět plno novinek ze světa Javy.

úterý 1. května 2007

Král je mrtev at žije král. Struts 2?

Co se stane, když vezmete jeden webový framework a druhy webový framework a spojíte je dohromady? Teoreticky vznikne nový webový framework, který si z obou vezme to nejlepší. O něco podobného se pokusili vývojáři WebWorku a Struts a výsledkem je framework Struts 2.

Právě jsme dokoukal prezentaci Patricka Lightbody na téma WebWork (Struts 2) In Action, ze které je patrné, že Struts 2 vsázejí na osvědčený koncept action (request) based frameworku a k tomu přidávají cukřík v podobě AJAX, POJO, Spring integrace, OGNL a jiných populárních termínů.

Z prezentace jsem měl pocit, že Struts 2 nepřináší nic bombastického co by tu nebylo již nějaký čas. Na druhou stranu, podle prezentovaných vlastností to vypada, že Struts 2 nepostrádají nic ze základních požadavků na web framework.

  • jednoduchá konfigurace
  • binding, validace
  • integrace s business logikou
  • AJAX podporu
  • elegantní cesta pro psaní unit/integračních testů
  • vyměnitelnost renderovacích technologií