martes marzo 28, 2006

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.

viernes marzo 17, 2006

Ya hace un tiempo que los POJOs (Plain Old Java Objects) están invadiendo las diferentes capaz de nuestras aplicaciones. Empujados por el intenso uso de lightweight frameworks (Spring por ejemplo) y AOP (Aspect Oriented-Programming), este tipo de objetos se están utilizando masivamente en el desarrollo de nuevas aplicaciones en JEE (Java Enterprise Edition).

Los POJOs son utilizados en la capa de persistencia a través de los ORM, donde se realizan mapeos entre estos objetos y tablas del mundo relacional. Persistence frameworks como Hibernate, JDO o Java Persistence API alientan el uso de los pojos y suministran persistence transparente para estos objetos.

En la capa de servicios, cada ves es mas común ver pojos publicados bajo diferentes mecanismos (EJB, web services, etc) y gracias a la utilización de AOP se pueden obtener objetos con muy bajas dependencias que disfruten de servicios de bajo nivel como transacciones, seguridad, logging, validaciones, notificaciones, etc. Utilizando POJOs como facade simplifica el desarrollo permitiendo que toda la lógica sea desarrollada y testeada fuera del application server y al mismo tiempo soportar los servicios de bajo nivel ya mencionados.

En la capa de presentación se encuentra JSF, donde sus managed bean pueden verse como pojos, objetos sin dependencias que son manejados por JSF.

Ahora bien, en la capa de integración con otros sistemas, el jugador más importante es XML. Sin embargo hay formas de transformar XML a Pojo y viceversa utilizando frameworks como JAXB, XMLBeans o XStreams por mencionar algunas.

Donde también los POJOs entran en acción es en el desarrollo del modelo de dominio que representan las entidades del mundo real que el sistema trata de modelar. Aquí los POJOs suministran simplicidad, OOD (Object-Oriented Design), mantenibilidad y extensibilidad

Como dijimos anteriormente frameworks como Spring, Hibernate, etc. alientan el uso de POJOs para el desarrollo de aplicaciones y cabe destacar que EJB3 también alienta la utilización de POJOs sobre todo por nueva API de persistencia de Java - JPA y por el uso de POJOs Facade, donde el EJB Container es el encargado de suministrar los servicios de bajo nivel

Para concluir podemos decir que hoy en día, para desarrollar una aplicación lo que se desarrollaran son POJOs utilizando técnicas de OOP y OOD, conectándolos y configurándolos a través de frameworks externas como ser Spring, Hibernate, EJB3, etc.

miércoles marzo 15, 2006

Hace un tiempo fui a un par de cursos de Oracle sobre ADF - Application Development Framework, aunque a mi me gusta llamarla "Awful Development Framework".
La verdad que no me gusta en nada (salvo la nueva versión que trae el diseño de paginas JSF bastante bueno) y aunque no la conozco profundamente voy a dar mi opinión acerca de esta mmm, llamemosla framework.

• Porque pagar por una framework cuando tengo Spring, Hibernate, JSF (MyFaces), Seam, Shale, etc?
• UIX es extramadamente complejo a la hora de entrar a mirar el código que genera y es muy dificil de "tocar" sin no es atraves de los editores de jdev
• ADF-BC es BC4J con otro nombre. Yo trabaje con esta framework y me parecio muy dificil de programar, la API es horrible y demasiado orientada a la base de datos y no a objetos
• Toplink me parece lo mejor de esta framewowk, un ORM bastante solido y eficiente . Vale decir que no fue desarrollada inicialmente por Oracle, sino que fue comprada.
• La programación gráfica facilita muchas cosas e incrementa la productividad, pero es buena a la hora de implementar un desarrollo grande dende los patrones y buenas practicas deben predominar a la simplicidad? Donde se requiere un codigo eficiente y simple de mantener? La programación gráfica creo que sirve para sistemas pequeños y no ayuda en sistemas grandes
• La programación grafica me permite modificar el codigo generado? Que tan dificil es realizar estas modificaciones? Luego de una modificación, me permite seguir trabajando en forma visual?
• El IDE (JDeveloper) es muy pesado ya con un proyecto de pocas clases y es mucho menos eficiente que Eclipse o NetBeans. A pesar de que crecio bastante en este ultimo tiempo, creo que le falta bastante. Sin embargo debo decir que la creación de interfaces graficas con JSF viene en buen camino.