Introducción
Oracle Application Development Framework (Oracle ADF) es un framework construido bajo la especificación JEE que utiliza estándares y tecnologías que permiten simplificar y acelerar la implementación de aplicaciones Web, es uno de los productos estrella incluido en Fusion Middleware 11g ampliamente conocido y difundido a nivel mundial.
Oracle JDeveloper 11g y Oracle ADF proveen un ambiente que cubre todo el ciclo de desarrollo de software desde el diseño hasta el despliegue. Además, la arquitectura de Oracle ADF sigue el patrón de diseño MVC, permitiendo a los desarrolladores una separación de la lógica de negocio y acceso a datos (ADF Bussines Components, ADF Model y ADF Bindings), Interface de Usuario (ADF RichFaces) y Flujo de la aplicación o navegación entre páginas (ADF Task Flow).
Por otro lado se tiene la tecnología EJB que es un framework de componentes que se ejecutan de lado del servidor, simplifican el proceso de construcción de clases empresariales de aplicaciones distribuidas escritas en Java. EJB está diseñado para soportar portabilidad y reusabilidad de aplicaciones a lo largo de cualquier vendedor de servicios Middleware. El objetivo de los EJB es dotar al programador de un modelo que le permita abstraerse de los problemas generales de una aplicación empresarial (concurrencia, transacciones, persistencia, seguridad, etc.) para centrarse en el desarrollo de la lógica del negocio.
El presente artículo pretende mostrar una estrategia para adaptar la tecnología EJB mediante la utilización del meta-framework que lo denominamos BindingsEjb en aplicaciones Oracle ADF, con el objetivo de resolver las problemáticas encontradas con el uso de ADF. Para esto, en el artículo presentamos de manera genérica las problemáticas de ADF, la arquitectura con la que se construyó BindingsEjb, el proceso de adaptación de BindingsEjb en aplicaciones ADF, un análisis de rendimiento de ADF versus BindingsEjb y las conclusiones respectivas.
Problemática con el framework ADF
A pesar de que Oracle nos dice que ADF reduce el tiempo de aprendizaje, la práctica dicta lo contrario pues la curva de aprendizaje es alta, el abstraerse de las complejidades no siempre es el camino ideal, sin duda un desarrollador tendrá que dedicar tiempo para entender todo el ciclo de desarrollo y las dificultades que involucra el enlazamiento de las capas de vista con el modelo llamado “databinding”.
Si bien es cierto que Oracle ADF Model permite abstraer la capa de persistencia de datos de una aplicación construyendo modelos basados en Tablas Planas, tecnología EJB, etc., para luego utilizar este modelo mediante ADF Bindings exponiendo objetos y métodos de negocio en páginas JSPX por medio de ADF RichFaces y ADF TaskFlow, existen problemas en cuanto al alto consumo de Memoria RAM en los servidores Weblogic donde se despliega la aplicación, lo que conlleva a ampliar la capacidad RAM de los servidores y su número inclusive para un trabajo normal (si se trabaja en Cluster). Otro problema apreciable, es el gran número de conexiones JDBC que abre ADF Model hacia la Base de Datos, es decir por cada Application Module que se ejecuta en la aplicación se abre una conexión JDBC que sigue latente, hasta que el usuario cierre su sesión en la aplicación o el servidor Weblogic mate automáticamente dicha sesión.
BindingsEjb un meta-framework para aplicaciones ADF
Existen varias alternativas para incorporar el framework EJB en aplicaciones ADF, como se mencionó anteriormente la más rápida consistiría en utilizar ADF Model para enlazar componentes del modelo con componentes de la capa vista y controlador (paginas, fragmentos de páginas, métodos de negocio, Expression Language, etc.), utilizando ADF Bindings.
Otra opción, consistiría en crear estos enlaces manualmente, es decir crear clases Java que realicen esta función y sincronicen las operaciones DML adecuadamente, para este caso se diseñó el meta-framework que lo denominamos BindingsEjb.
BindingsEjb agrupa una serie de componentes arquitectónicos que siguen patrones de diseño estándares para JEE conocidos y ampliamente utilizados que se plasman en clases Java de tipo POJO. Entre los patrones de diseño que utiliza BindingsEjb podemos mencionar a Data Transfer Objects (DTO) y Data Access Objects (DAO), de los componentes EJB se utilizan Entity Beans y Stateless Session Beans.
Para acceder al modelo de dominio definido con EJB, se añaden componentes estándares de acceso a los servicios de negocio de EJB a través de una clase genérica denominada GenericService, estos servicios podrán ser utilizados por páginas JSF, fragmentos de páginas JSFF y principalmente en Backing Beans.
Para acceder a colecciones de datos que se recuperan por medio de consultas JPQL, se tiene una capa de acceso denominada GenericIteratorBinding, la misma posee métodos para realizar operaciones CRUD, también permite ejecutar consultas a la Base de Datos con o sin paginación, realizar la sincronización Maestro/Detalle entre dos colecciones, recuperar el registro activo en una colección, Commitear o realizar Rollback de las operaciones realizadas en la colección, etc.
Para utilizar componentes de tipo LOV’s, ComboBoxes y ListBoxes, en las páginas JSPX y JSFF, se disponen de clases Java que permiten definir LOV’s y ComboBoxes, a partir de la definición de un Query nativo SQL (Lov Definition, Query Lov y Query Popup).
Si se requiere utilizar componentes de búsqueda dinámica en las páginas, se tienen las clases QuerySearch y QueryDef, estas clases pueden complementarse con el uso de clases que permiten definir criterios de búsqueda (CriteriaExpression, CriteriaParameter y CriteriaOrder).
La siguiente figura ilustra la arquitectura de BindingsEjb:
Arquitectura del meta-framework BindingsEjb.
Adaptación de BindingsEjb en aplicaciones ADF
La propuesta se centra en reemplazar la capa ADF Model, por una capa de componentes de negocio basados en el framework EJB 3.0, esta acción consiste en crear un proyecto como modelo de datos de la aplicación, crear paquetes para definir las entidades del negocio (paquete entities), crear clases dto para transferir datos a la capa del cliente por cada entidad de negocio (paquete dto), por cada entidad de negocio que se persistirá en la Base de Datos se crea una clase dao (paquete dao) y finalmente a toda entidad se asociara una clase de servicio de negocio (paquete services).
Creación del proyecto ModelEjb.
Creación de Entity Beans (paquete entities).
Creación de DTO’s (paquete dto) y DAO’s (paquete dao).
Creación de Session Bean Stateless (paquete services).
Una vez creado el modelo del dominio de datos, en el proyecto de la Vista/Controlador se deberá crear una clase listener que extienda de ServletContextListener en la misma se harán las respectivas inyecciones de dependencia a las interfaces locales de los Servicios de Negocio, posteriormente se registraran todos los Servicios de Negocio inyectados en el ServletContext, esto permitirá recuperar un Servicio desde el objeto FacesContext de la aplicación., finalmente la clase listener deberá ser registrada en el archivo web.xml del proyecto.
Inicialización de los Servicios y creación de Listener en el archivo web.xml.
A continuación, se deberán crear clases para administrar colecciones de datos, conocidas como clases iteradoras que extienden de la clase GenericIteratorBinding y tienen asociada una clase DTO, luego se crea la clase denominada BindingsEjb, en la cual se crean instancias de las clases iteradoras definidas, adicionalmente se crean métodos getters para poder recuperar un determinado iterador. La acción más importante para concluir todas estas definiciones es el de registrar la clase BindingsEjb como un Managead Bean con ámbito de tipo “session” en el archivo de configuración adfc-config.xml, este ámbito permitirá acceder al objeto desde cualquier lugar de la aplicación web.
Creación de clases Iteradoras y clase BindingsEjb.
Definición en Managed Beans del archivo adf-config.xml, la clase BindingsEjb con ámbito “sesión”.
A continuación se modificaran los componentes de acceso a los servicios de negocio comprendidos en las páginas JSF y fragmentos de páginas JSFF ya existentes por expresiones EL que hagan uso de BindingsEjb. Los componentes Bindings de ADF definidos en cada página (archivos pagedef.xml) ya no son necesarios, por lo que pueden eliminarse paulatinamente.
Finalmente, se optimizan las clases Java relacionadas a las paginas (Backing Beans), depurando enlaces entre elementos de las páginas con atributos de la clase no utilizados, reemplazando el código de ejecución de métodos de negocio ADF con el de BindingsEjb y creando funcionalidad necesaria para utilizar componentes LOV’s, Querys, ComboBoxes, ListBoxes, etc.en las páginas.
Uso de LOV’s
Uso de Comboboxes
Acceso a las clases iteradoras en las páginas.
Áreas de Búsqueda.
Paginadores
Tablas de Datos.
Uso de clases iteradoras en Backing Beans.
Análisis de Rendimiento.
Para analizar el rendimiento del meta-framework BindingsEjb frente a una aplicación ADF tradicional, se adaptó una aplicación compleja con 7 tablas involucradas, una tabla maestra y 6 tablas detalle (documento de ejecución de recursos). La aplicación funciona con una página JSPX de tipo Listado que permite realizar consultas genéricas sobre la tabla cabecera, el usuario realiza operaciones de búsqueda para aquellos registros ya almacenados en la Base de Datos pudiendo editarlos o eliminarlos, caso contrario podría crear un nuevo registro. La información de la cabecera y de cada detalle, se capturan en una página JSPX de tipo Documento que tiene incluida un flujo de tareas con 7 páginas de tipo fragmento JSFF, que permiten la edición de toda la información.
Aplicación ADF adaptada con BindigsEjb, pagina de tipo Listado y Documento.
La prueba de rendimiento, se realizó sobre la aplicación original comparada con la aplicación adaptada, se utilizaron las siguientes herramientas:
- JMETER: Herramienta que permite realizar pruebas de rendimiento, en nuestro caso sobre la aplicación original y la adaptada.
- Panel de Control del WEBLOGIC: Utilizada principalmente para monitorear las conexiones activas JDBC administradas por las aplicaciones.
- ENTERPRISE MANAGER 11G: Permite ver el rendimiento del Java Heap: (Pool de Memoria de uso actual), las sesiones activas y tiempo de procesamiento de las solicitudes de una aplicacion.
Se realizó la prueba con 120 usuarios concurrentes (hilos en JMETER) ejecutados en un lapso de 1 minuto, cada usuario simulo el llenado de un documento de ejecución de recursos de forma completa (tabla maestra y 7 tablas detalle). Las pruebas con la aplicación original tuvieron una duración de 25 minutos y la aplicación adaptada tuvo una duración 15 minutos. Los resultados que muestran las herramientas de monitoreo fueron las siguientes:
Panel de control Weblogic
Podemos observar que las conexiones activas en la aplicacion con el trazo amarillo y el trazo celeste llegan a su capacidad tope del servidor con la aplicación original. Con la aplicación adaptada las conexiones crecen en un instante dado pero luego decrecen rapidamente.
Conexiones JDBC activas, aplicación original.
Conexiones JDBC activas, aplicación adaptada.
ENTERPRISE MANAGER
En la graficas siguientes podemos observar lo siguiente:
- Sesiones activas ya sea en ambos casos tienen el mismo comportamiento, hasta que el servidor Weblogic vaya eliminando las sesiones automáticamente.
- Los tiempos de procesamiento de las solicitudes en la aplicación original llegan a un máximo de 2000 ms (milisegundos), teniendo un mejor tiempo de procesamiento la aplicación adaptada con 150 ms como máximo.
- En las solicitudes por minuto se tiene en ambos casos una similitud con alrededor de 20k a 25k solicitudes por minuto.
Tiempo de procesamiento de solicitudes, aplicación original.
Tiempo de procesamiento de solicitudes, aplicación adaptada.
RENDIMIENTO JVM (Memoria de uso)
En el pool de memoria se puede evidenciar mediante las gráficas una diferencia entre ambas aplicaciones en cuanto al uso de memoria heap, donde la aplicación original no tiende a liberar la memoria teniendo casi un comportamiento continuo a comparación de la aplicación adaptada donde su comportamiento es más oscilante.
Uso de memoria Java Heap, aplicación original.
Uso de memoria Java Heap, aplicación adaptada.
Conclusiones
Si bien es cierto que Oracle ADF es un framework que permite cubrir todo el ciclo de desarrollo de software, permitiendo acelerar la implementación de aplicaciones Web, su componente de negocios ADF Bussines Components tiende a incrementar el uso de conexiones JDBC a la Base de Datos, el uso de memoria del Java Heap no es liberada oportunamente y la respuesta a las peticiones es mayor en relación al meta-framework BindingsEjb.
Una aplicación ADF adaptada con BindingsEjb es simple, ya que está basada en clases Java de tipo POJO y clases EJB, una ventaja seria que el desarrollador tiene el control de lo que programa y como lo programa. El tiempo de adaptación es relativamente corto ya que la aplicación original que queramos adaptar debería estar en pleno funcionamiento y es cuestión de aplicar los pasos sucesivos y necesarios indicados para su implementación.
