pondělí 2. července 2007

Seam 2.0 je tu

Příznivci aplikačního frameworku Seam zbystřete, Gavin King oznámil uvolnění Seam 2.0 beta (diskuse TSS). Seam 2.0 přinese velké množství změn, viz následující list.

  • Seam WS allows Seam components to function as Web Service endpoints
  • Seam components may now be writted in Groovy
  • The Seam core is now independent of JSF
  • Experimental support for the Google Web Toolkit
  • Integration of Hibernate Search
  • Introduction of JBoss EL, an extension to the Unified EL of Java EE 5
  • Major enhancements to Seam Asynchronicity, including Quartz integration
  • Major enhancements to jBPM integration
  • Completely reorganized packaging of built-in components
  • Migration to JSF 1.2
  • Simplified configuration
  • Support for pageflow composition
  • Enhancements to the integration testing framework
  • New transaction abstraction layer with support for non-JTA environments
  • Enhanced JavaDoc
  • Two new example applications
  • Migration to the new Embedded JBoss
  • Seam JSF controls reimplemented using Ajax4JSF CDK
  • Many, many bugfixes

Pokud si projdete tyhle nové vlastnosti, čtete mezi řádky a znáte tak trochu historii Seamu, tak vás nutně musí něco napadnout. Bylo nebylo, Gavin King začal psát Seam také proto, aby ukázal na použitelnost EJB 3.0. Seam měl demonstrovat, že EJB technologie urazila velkou cestu a nyní je zralá pro všední použití.

Jak rostla rodina uživatelů Seamu, něco se zvrtlo. Najednou se do Seamu pomalu, ale jistě začali vkládat věci, které začali části EJB obcházet. To znamená, že uživatelé chtějí starý dobrý Tomcat a nechtějí nutně používat plnokrevný aplikační server. Ve verzi 2.0 už je to dokonce tak, že se upustilo od embedovaného JBosse uvnitř Tomcatu (sama o sobě zvrácená myšlenka).

Ve verzi 2.0 už vidíte vlastní abstrakci nad transakčním API, aby mohly Seam aplikace běžet mimo JTA prostředí. Pro asynchronní zpracování byl přidán Quartz scheduler. Tyhle změny naznačují, že pro běžné vývojáře je J2EE stack velké sousto na skousnutí a preferují odlehčená řešení fungující především v Tomcatu.

Otázka zní proč je J2EE stack případně aplikační server velké sousto a to může být například hosting a nebo složitější vývoj (konfigurace aplikačního serveru, neznáme technologie v pozadí aplikačního serveru) a celkově větší nároky (paměť, rychlost deploymentu aplikace) robustních aplikačních serveru.