JBoss Seam

En estos momentos me toca trabajar con este de JBoss, y debo decir que le tenía cierta desconfianza y lo prejuzgue anticipadamente.
Luego de participar en una presentación de Gavin King hace un par de años sobre este framework me había quedado la idea de que era poco flexible y apuntaba a resolver la problematica común de las aplicaciones web desde la perspectiva de JSF/EJB/JPA haciendolo así un fullstack framework.

Justamente por lo recien mencionado, me quedo la idea de que JBoss Seam, era solo JSF, EJBs como BackingBean que usan JPA directamente, lo cual no me parecia mal para aplicaciones simples y/o pequeñas, pero para grandes sistemas web no me cerraba sobre todo por el hecho de las capas, en este sentido Seam según mi visión en aquel momento, tenia 2 capas, la vista (con JSF components) o el negocio (EJB como backing beans) cerrando así la posibilidad de tener independencia entre las capas (presentación, negocio, persitencia, integración).

Definitivamente, ahora veo que tenía un pre concepto erróneo de lo que realmente es Seam principalmente porque uno de los features principales de Seam es la flexibilidad.
Encontre en JBoss Seam un framework que resuelve los problemas típicos de las aplicaciones web en una manera simple como por ejemplo:

i18n: Usando .properties

navegación: Usando un mecanismo que extiende al mecanismo de navegación estandar de JSF y que provee muchas mas opciones, como ser condiciones. También soporta pageflows usando un proceso jBPM.

contextos: además de los contextos clásicos agrega contextos muy utilies sobre todo el contexto CONVERSATION.

Manejo de excepciones y paginas de error: Facilita la administración de las excepciones y provee opciones de configuración para las páginas de error de la aplicación.

Manejo de mensajes: Facilita el manejo de mensajes por medio de extensiones al FacesMessage de JSF e inyección del mismo.

Validaciones: Usando Hibernate-Validator

Exportación a varios formatos.

Templating y layout de páginas: Usando Facelets.

Como features que me encontre con los siguientes:

Fuertemente basado en anotaciones (adiós XMLs gigantes) con una gran cantidad de las mismas que permiten configuraciones de las mas variadas.

Gran cantidad de tipos de componentes: Interceptores, Beans, Logger, manejadores de eventos, FacesMessages, IdentityStore, etc.

Bijection: Permite la clásica inyección y agrega la outyección (publicando en algún contexto por ejemplo) de objetos.

Componentes visuales: Permite utilizar frameworks de componentes visuales como RichFaces o ICEFaces. También provee tags especializados que facilitan muchas tareas.

JPA: integración directa con JPA. Inyección del EntityManager.

Seguridad: Presenta un modelo de autenticación y autorización completo basado en clases y anotaciones. Extensible usando componentes Seam.

SpringFramework: Integración con Spring permitiendo inyectar en componentes Seam Spring-beans y definir Spring-beans como componentes Seam

Otros features que no estoy usando: email, caching, remoting

Luego de ver todos estos beneficios y ventajas de usar JBoss Seam, debo concluir en que estaba completamente equivocado sobre todo por la flexibilidad dado que en la implementación del proyecto podríamos haber usado Seam de diferentes maneras:
1. Tal cual lo vi hace año: JSF/RichFaces + EJB (como BackingBeans) + JPA.
2. Usando las mismas tecnologías pero separandolas en capas: JSF/RichFaces + Seam components (presentación) + EJB (negocio) + EJB/DAO + JPA (persistencia).
3. o finalmente como lo implementamos usando JSF/Facelets/Richfaces como componentes para construir las interfaces de usuario (*.xhtml) haciendo un fuerte uso de AJAX, luego componentes Seam (clases simplemente anotadas con @Name) para implementar la lógica de presentación a las cuales se les inyecta un servicio de negocio implementado y configurado con Spring Framework. A su vez Spring tiene otros componentes configurados dentro de su container como ser los Repositories que nos abstraen del acceso a los datos, que en nuestro caso son implementaciones que utilizar Hibernate. Las clases de dominio se mapean al modelo relacional usando anotaciones JPA (y alguna que otra extension de Hibernate-Annotations).

Para concluir podría decir que Seam provee una framework interesante y simple para llevar adelante desarrollos de aplicaciones web en gran escala y desde mi (nuevo) punto de vista podría decir que es mi primera elección (a otro frameworks que he usado como ser SpringMVC, Struts o Wicket) a la hora de comenzar con un nuevo desarrollo web en Java.

Read-Mostly Pattern

Este es un patrón propuesto en la documentación de bea weblogic para incrementar la performance de una aplicación que trabaja en su capa de persistence con EntityBeans más precisamente con CMP 2.0. La idea detras de este es hacer un uso intenso de la cache de entities y del mecanismo de invalidación implícita que WebLogic provee.
Las entidades candidatas a ser implementadas con este patrón son aquellas en las cuales se realizan operaciones de lectura frecuentes y operaciones de escritura ocasionalmente.
Para implementar este patrón se deben crear dos entity beans uno de read-only y otro de read-write apuntando a la misma tabla de la base de datos, el bean de read-only se utiliza para las operaciones de lectura mientras que el bean de read-write se utiliza para las operaciones de escritura y comportamiento transaccional. Luego se indica mediante configuración que cuando el bean de read-write sea modificado invalide el bean read-only de la cache.
Cuando se accede al bean de read-only en una transacción (JTA Transaction) el container activa una nueva instancia de este bean para la transacción con los datos tomados desde la cache, si no se encuentra en la cache llama a el método ejbLoad(), carga el bean y lo coloca en la cache de entities para su posterior uso. De esta forma las operaciones de lectura de la entidad se realizan todas sobre la cache mejorando los tiempos de acceso.

Ahora bien, cuando se utiliza el bean de read-write y este se ve modificado en alguno de sus campos, el container cuando comité la transacción (y llame a ejbStore() del bean) llama al mecanismo de invalidación y de esta forma se invalida el bean de read-only para que en su próxima lectura este se refrescado (se llame a ejbLoad()).

Otra forma de hacer que los beans de read-only se refresquen es utilizando un timeout de forma tal que cada un lapso determinado de tiempo estos bean se sincronizan con los datos en la base de datos.
Con el uso de este patrón se obtienen tiempo de respuesta mucho mejores dado el uso de la cache de bean read-only. Para casos similares podria tenerse en cuenta el uso de estrategias de concurrencia optimistas, las cuales mejoran el control de cambio de las entidades.

EJB3 Notes

La nueva especificación de EJB 3.0 tiene muchas variantes y mejoras con respecto a sus predecesoras:

- Simplifica el desarrollo de aplicaciones
- Uso del nuevo feature de J2SE 5, metadata, para especificar comportamiento esperado del container, para injectar recursos y servicios (otros beans) y especificar el mapeo objeto/relacional. De esta forma el bean provider puede obviar el deployment descriptor.
- Permite el uso de deployment descriptor para sobreescribir las configuraciones realizadas con anotaciones. Tambien se puede obviar el uso de anotaciones y utilizar solamente el deployment descriptor como mecanismo de configuración.
- Utiliza POJO/POJI para definir un Enterprise Bean Class. No hay dependencias con las viejas interfaces (EJBObject o EJBLocalObject).
- Uso mas flexible de excepciones (unchecked exceptions).
- Uso no obligado de callback methods aunque si es necesario si se desea recibir notificaciones y eventos del container. De echo los callback methods se pueden reemplazar por callback listeners de modo de no tener estos metodos dentro de la clase de negocio.
- Permite el uso de interceptores para session y message-driven bean.
- Se eliminaron las Home interface.
- Un entity bean es un objeto de dominio liviano.

Fast Lane Writer Pattern

Contexto.
En las aplicaciones J2EE donde la persistencia es manejada mediante Enterprise JavaBeans de Entidad, mas presisamente utilizando CMP, las actualizaciones (DMLs) de una gran cantidad de datos puede volverse poco eficiente dada la naturaleza de los entity beans.

Problema.
Todos conocemos el patrón Fast Lane Reader (1) que propone un mecanismo para obtener grandes cantidades de información utilizando un acceso directo sobre la base de datos en lugar de trabajarlos con Entity Beans.
Sin embargo se nos planteo el problema de tener que realizar una gran actualización/inserción de información en la base de datos. El problema concreto era por cada registro habia que realizar una actualización campos y una inserción de un registro en otra tabla relacionada. En principio lo trabajamos utilizando los CMP (en Bea Weblogic 8.1) y realizando un poco de tunning (enable-batch-operations = True, concurrency-strategy = Optimistic, etc) pensamos que podria funciona bien, pero al momento de realizar las pruebas con grandes cantidades de datos nos encontramos con que el método no era el mas eficiente (teniamos que, para cada bean actualizarle el atributo y settear la relación) con lo cual los tiempos se fueron un poco de lo esperado.

Solución.
Usamos una modificación de Fast Lane Reader (bautizado Fast Lane Writer) aplicado a la actualización masiva de información en la base de datos y ejecutando DML directamente sobre JDBC o invocando un Stored Procedure, se mejoraron los tiempo en un 500% aproximandamente.
Una de las desventajas de este utilizar esto es la des-sincronización entre las caches (del appserver) y la BD, pero utilizando mecanismos de invalidacion de caches (en el caso nuestro, con weblogic no tuvimos problema) se puede solucionar facilmente.
Otro tema a tener en cuenta es como ejecutarlas sentencias DML que en nuestro caso tuvimos la posibilidad de hacerlo a traves de inserts masivos ( insert / select ... ).

Conclusion.
Con la aplicación de este patrón obtuvimos una mejora importante en la performance del proceso mejorando los tiempos de respuestas y una mejor administración de los recursos, sin tener grandes problemas.

Referencias.
- http://java.sun.com/blueprints/patterns/FastLaneReader.html
- http://java.sun.com/developer/technicalArticles/J2EE/J2EEpatterns/

---