ADF: desarrollo Java EE con Oracle
ADF: desarrollo Java EE con Oracle
Dentro de las tecnologías de desarrollo JavaEE, Recordemos que lo de J2EE está ya pasado de moda, se ha llegado a un punto de estabilidad donde han conseguido tener presencia aquellas técnicas, ideas y librerías que se lo merecen porque con su “saber hacer” aportan algo útil a los desarrolladores. Entre todos los supervivientes, cada grupo de desarrollo debe elegir, en función de sus políticas de gestión de proyectos, aquellos elementos que resulten más beneficiosos en su trabajo.
Como desarrolladores y arquitectos Java entendemos que el conocer más posibilidades sólo puede llevarnos al beneficio y la comodidad en nuestro trabajo, y pensamos que la apuesta de Oracle por ADF es una de esas técnicas que merecen ser conocidas y entendidas.
Arquitectura JavaEE: el misterio de los frameworks y los patrones
De todas las técnicas e ideas que han llegado a estabilizarse como soluciones Java, lo que está de moda son los frameworks.Así que consideramos importante aclarar algunos aspectos sobre los frameworks. Al nombrar esta palabra inmediatamente nos acuden a la mente muchos acrónimos y nombres, casualmente todos ellos muy sonoros: TOPLINK, STRUTS, SPRING, HIBERNATE, JMAKI, COCOON,FREEMAKER, etc...
Cuando uno oye todos los nombres de las “cosas” que finalmente son definidas como frameworks de desarrollo, no le queda más remedio que ampliar la definición de framework, y la ampliamos y ampliamos tanto que finalmente pierde su utilidad. Desde nuestro humilde punto de vista definiremos framework como: Quizás algunos términos de esta definición no son muy ortodoxos pero cualquiera que ande próximo a los mundos de ldesarrollo Java entiende lo que se quiere decir. Y volviendo a la definición, un trozo de una arquitectura JavaEE debe ser la implementación de uno o más patrones, es decir, la implementación de una o más soluciones preconstruidas, y perfectamente especificadas, a los problemas que se deben solucionar en un aplicativo de ámbito empresarial.Y quizás éste sea el “quid” de la cuestión, uniendo la definición y el párrafo anterior, los framewoks deben aportarnos una o más soluciones preconstruidas. Por tanto la arquitectura JavaEE de un aplicativo es igual a un conjunto de problemas que se deben solucionar aplicando patrones. Crear una arquitectura es por tanto seleccionar los patrones y una vez seleccionados los patrones que se deben implementar, la manera más sencilla de hacerlo bien es utilizando correctamente uno o más frameworks. El patrón por excelencia encualquier arquitectura JavaEE es el famoso MVC (Modelo-Vista-Controlador), si un framework nos ofrece una implementación válida de este patrón quizás estemos hablando de una solución que por principio podremos adoptar para cualquier aplicación, y precisamente éste es el caso de Oracle ADF, es decir, Oracle Application Framewok Developer.
¿Que es ADF?
Oracle ADF implementa el patrón de diseño MVC, la separación conceptual de este patrón permite un mejor mantenimiento de los componentes desarrollados, y propicia la reutilización, por lo tanto conseguimos una arquitectura orientada al servicio, con bajo acoplamiento entre capas. Pero Oracle ADF hace una separación aún mayor de las capas tradicionales. La capa modelo, debido a su complejidad es subdividida por ADF en dos partes: modelo de negocio y servicios de negocio. Esta nueva división aplica claramente el principio de desacoplamiento, tan importante en arquitectura JavaEE. Por lo tanto una aplicación desarrollada mediante el framework ADF, va a constar de los elementos que podemos observar en la fig.1. Ala vista de estas definiciones podemos afirmar que ADF es un framework completo, que nos asiste a lo largo de todo el desarrollo pero a su vez permite en cada una de sus capas la utilización de diferentes técnicas de implementación como veremos a continuación. Esto es posible, principalmente, gracias a la capa de modelo, que es realmente el corazón de ADF, ya que actúa como enlace entre las tecnologías que el desarrollador seleccione para sus métodos de negocio y las tecnologías que haya elegido para implementar la vista.
Definición de componentes
• ADF Faces: Librería de componentes para la vista, 100% compatible con Java Server Faces, basada en la especificación JSF JSR127.Se trata tambiénde una evoluciónde la tecnología UIX deOracle, y la apariencia de los componentes de ambas es muy similar. Cubre algunas de las principales demandas de los desarrolladores Java que utilizan JSF: validación en cliente, paso de valores entre páginas, estrategia combinada de mantenimiento de la persistencia de clientes, etc... Pero lo más importante si usamos ADF Faces en vez de otra tecnología posible es que estamos en disposición de usar directamente los ADF Bindings proporcionados por la capa modelo deADF.
• Controlador: Necesario en el caso de aplicativos web, en aplicativos cliente pesado este componente no existe. Un controlador se encarga de recibir todos los request o eventos provocados a través de las vistas y guiar el flujo de la aplicación, pero además es necesario que controle el ciclo de vida de todos los componentes participes en las vistas. Existen tres tecnologías posibles para desarrollar el componente ADF Controller: Modelo1 (técnica original de Oracle), Struts y JSF.Actualmente JSF es la mejor integrada ya que JDeveloper 11g, ofrece un gran número de asistentes para su desarrollo; no debemos olvidar además que los componentes ADF Faces están especialmente preparados para este controlador.
• Data Bindings: Son las implementaciones abstractas necesarias para que los componentes de la interfaz de usuario de una página accedan a la operativa get/set o a las acciones que provocan la intervención de los servicios de negocio. Siguen la especificación formal de Java Beans para que los componentes de interfaz puedan acceder de manera declarativa independientemente del servicio de negocio al que enlacen. Su función principal es implementar la tarea estándar de ‘view helper’.
• Data Control: Son las implementaciones abstractas llamadas desde los Data Bindings,realmente realizan los servicios de negocio y siempre son generados a partir de los mismos.
•ADF BussinesComponent Es un subframework deADF que esta diseñado para el desarrollo de las funciones de negocio y para proporcionar servicios persistencia, este nivel tan complejo podemos subdividirlo en varios elementos: Domain Components: Entidades definidas partiendo de tablas o relaciones existentes en una base de datos. Incluyenunatributo por columna y dispone de ciertas funciones como la gestión de mascaras de formato o las validaciones de negocio. Model Components: Funcionalidad que opera con los conjuntos de componentes de dominio a través de los interfaces fachada llamados View Object o View Link, estos incluyen los atributos expuestos de las entidades más atributos calculados y manejo de multiplicidades, ordenaciones, filtros, etc... Los Viewson utilizados desde los Application Module que representan las operaciones del sistema y que mantienen la sesión de base de datos y por tanto la gestión transaccional. Todos estos componentes están orientados a una mejora de la escalabilidad y el rendimiento, y además están optimizados para la interacción con la base de datos.
Pero...¿Oracle FORMS?
Como creo que vemos claramente ADF no tiene nada que ver con Oracle Forms. Cualquiera que tenga entre sus responsabilidades entender qué es ADF y decidir su utilización en un proyecto deberá conocer bastante de esos contenidos denominados genéricamente arquitectura JavaEE. Así que ya estamos, cuando parecía que encontrábamos una salida a nuestros proyectos de desarrollo, otra vez con “el disgusto”: los jefes de proyecto no saben arquitectura Java, los analistas ni idea de Java y los programadores solo saben Oracle Developer. Desde nuestra opinión podíamos plantear un bonitocaminoparairabandonandoestosproblemasatrásyorganizarnosauténticos equipos de desarrollo Java, eso sí, no será un camino de rosas pero tampoco deberemos hacer un “parón”,ni tendremos que abandonar drásticamente nuestra dinámica de desarrollo, ni por supuesto olvidarnos de los conocimientos que ya tenemos.Cualquier jefe de proyecto y/o analista con algo de experiencia, tiene capacidad suficiente, si quiere, para hacer abstracción de los conceptos que maneja y es capaz de ponerse al día en arquitectura Java sin demasiadas dificultades.Quizás en este caso el problema está en encontrar un buen documento, compendio de todos los conceptos que son necesarios y donde no se abuse de ejemplos “en código” que para el caso es como si fueran en chino.Tampoco es necesario un esfuerzo titánico para empezar, está claro que ADF en si mismo determina una arquitectura, y aunque nuestro primer proyecto con ADF no sea el que gane un premio al diseño de arquitectura JavaEE, será aceptablemente bueno y perfectamente válido en cualquier entorno IT. Por nuestra parte en este sentido recomendaríamos acudir a la información “original”: los blueprints y los tutoriales residentes en http://java.sun.com son un buen comienzo. Respecto a los desarrolladores, las facilidades de ADF les van a permitir comenzar a desarrollar en Java a la vez que aprenden el lenguaje.Si se utiliza JDeveloper con la combinación ADF Business Components y ADF Faces, se dispone de mecanismos de asistencia y edición visual que, aislándonos delcódigo Java, permiten al desarrollador de Forms equipararmuchos de los conceptos que maneja con los que ahora debeempezar a conocer enel entorno JavaEE.Lo ideal para conseguirl legar a esta situación en la que los programadores pueden ser autónomos, es contar con la ayuda de un desarrollador-consultor con capacidad de comunicación, experto en Forms y en Java, lo cual ya es un poco más complicado que buscar información en la web. Pero como decían algunos “pienso, luego existo”.