Desarrollo de Grandes Aplicaciones de Gestión de Red: Decisiones generales de diseño

Transcripción

1 Desarrollo de Grandes Aplicaciones de Gestión de Red: Decisiones generales de diseño Antonio Hernández Sáez 1 y Virgilio Gilart Iglesias 2 1 Escuela Politécnica Superior, Universidad de Alicante , Alicante, España ahs@eps.ua.es 2 Departamento de Tecnología Informática y Computación, Universidad de Alicante AP. 99, 03080, Alicante, España vgilart@dtic.ua.es Resumen. El uso de plataformas empresariales para abordar el desarrollo de grandes aplicaciones es necesario para poder cumplir los requerimientos impuestos por los avances tecnológicos y los deseados por las organizaciones. Estas plataformas nos ayudan minimizando los tiempos de desarrollo y nos ofrecen una serie de servicios que nos facilitan el trabajo. Pero, utilizar estas plataformas requiere un mayor esfuerzo a la hora de realizar los diseños de dichas aplicaciones para evitar posibles problemas derivados de la planificación y análisis, que puede desembocar en problemas mayores que con las aplicaciones tradicionales. En este artículo pretendemos mostrar una serie de guías y estrategias a la hora de realizar aplicaciones utilizando la plataforma empresarial J2EE. Esta serie de guías y patrones se basan en la experiencia aportada por personas que han trabajado durante mucho tiempo con dicha plataforma, y cuyas soluciones nos podrían suponer un ahorro de tiempo de desarrollo, mayor facilidad de mantenimiento y otra serie de beneficios en términos de rendimiento. Introducción Hoy en día las organizaciones solicitan una serie de requisitos a la hora de la realización de grandes aplicaciones de gestión. Dichas organizaciones demandan unos menores tiempos para dichos desarrollos, sin que para ello se resienta la calidad de las aplicaciones. Además se ha de tener en cuenta que las organizaciones requieren que sus viejas aplicaciones sean reutilizadas e integradas con las nuevas emergentes. Hemos visto que con el objetivo de cubrir estas necesidades en el desarrollo de grandes aplicaciones surgen una serie de plataformas (.NET, J2EE o CORBA) las cuales no ayudan a lograr dichos objetivos. En la figura 1 podemos observar un escenario en el cual sería aconsejable la utilización de una plataforma empresarial para construir el software de la organización e integrar el nuevo software con aplicaciones ya existentes. El problema que nos encontramos al utilizar dichas plataformas viene derivado también de

2 escenarios como el de la figura 1. Las plataformas empresariales nos ayudan a la hora de desarrollar dichas aplicaciones. Sin dichas plataformas estos desarrollos serían eternos y posiblemente tendrían poco éxito. Sin embargo estos escenarios son más complejos que los escenarios tradicionales, donde las arquitecturas no son integrables y los entornos no se encuentran prácticamente distribuidos. De aquí surge la importancia de realizar un buen análisis y diseño en cada nivel que nos aporte una visión, lo más temprana posible, de los riesgos y problemas que pudieran surgir. Sin este estudio y análisis técnico se podrían derivar una serie de fallos que podrían llevar al fracaso del proyecto completo. En todas estas aplicaciones aparece una serie de problemas comunes con los cuales se han encontrado anteriormente otras personas que poseen una mayor experiencia en estos entornos y que además se dedican a la mejoras de las plataformas empresariales. Conocer estas soluciones que aportan, nos puede ayudar a mejorar los tiempos de desarrollo y mejorar la aplicación en conjunto. Posteriormente hablaremos de los patrones y de las estrategias y como nos pueden ayudar al desarrollo de grandes aplicaciones. Figura 1. Un ejemplo de un escenario ideal para una aplicación de gestión en la cual participan un amplio número de entornos heterogéneos, los cuales pueden tener a su vez diferentes sistemas de gestión y necesitan integrarse entre ellos para llevar a cabo todo el flujo necesario para realizar el cometido de la organización.[3] Debemos tener en cuenta que las aplicaciones pueden sufrir mejoras constantemente y que las soluciones aportadas por diferentes personas nos pueden ayudar a mejorar el software que ya tengamos desarrollado. En este artículo describimos las consideraciones generales de diseño que debemos tener en cuenta en todos los niveles de las aplicaciones empresariales. Dichas consideraciones se refieren a requerimientos de red, debido a que al ser entornos altamente distribuidos será este el medio por el cual se comunicarán los distintos niveles y por lo tanto haremos referencia a la problemática surgida en cada nivel derivada de la comunicación a través de la red. También nos referiremos a las problemáticas surgidas de la seguridad, puesto al ser la red el principal medio de

3 transmisión de información, debemos tener en cuenta que esta información debe estar protegida de posibles ataques. Por último relacionados con las consideraciones generales veremos las derivadas de la propia plataforma J2EE. Aquí podemos ver qué tecnología J2EE utilizar y dónde utilizarla. Por otro lado veremos las características que debemos tener en cuenta derivadas de cada nivel en particular. Patrones y Estrategias Como hemos comentado en la introducción es imprescindible un buen análisis para el éxito en el desarrollo de grandes aplicaciones de gestión con la plataforma J2EE. Este análisis requiere gran cantidad de tiempo del cual, la mayoría de las veces, no dispondremos. Por otro lado, en la mayoría de los desarrollos, queremos comenzar el proyecto desde cero, como si fuéramos los únicos que abordamos dichos desarrollos de software. Es aquí donde entran en juego los patrones software. Un patrón se puede definir como Una solución aportada desde la experiencia para un problema en un contexto dado, el cual ocurre repetidamente dentro de ese mismo contexto. Es decir soluciones a problemas que se repiten ante las mismas circunstancias y que nos pueden ayudar a minimizar tiempos, tanto de análisis como de desarrollos. Probablemente sin el conocimiento de dichos patrones, y en el mejor de los casos, podríamos llegar a implementar un patrón sin ser conscientes de ello, pero el coste de tiempo hasta dar con dicha solución nos supondría un gran retraso. Podemos clasificar los patrones en función del nivel de la arquitectura empresarial en el cual actúen. Así tendremos la siguiente división de patrones. Patrones de presentación, patrones de empresa y patrones de integración. Las ventajas que aporta la utilización de dichos patrones son múltiples, entre las cuales podemos destacar: la ganancia de tiempo en el desarrollo, al tener solucionados ciertos problemas de antemano con el uso de estos. Por otra parte cada patrón nos proporciona una serie de ventajas, derivadas del fin para el que se creo el patrón. Podemos tener mejoras de tráfico en la red, mayor desacoplamiento entre niveles, mayor facilidad de mantenimiento del software, transparencia de acceso a los datos y otras innumerables ventajas. Hemos visto la definición anterior de un patrón, pero un patrón no deja de ser una especificación de una solución a un problema dado dentro de un contexto. El nivel de definición de un patrón viene dado de una forma muy abstracta y no hace referencia a la forma de implementarlo. Es aquí donde aparece el concepto de Estrategia. Una o varias estrategias nos proporcionan una implementación de un patrón determinado. Además una estrategia de diseño puede no estar relacionada con ningún patrón como pueden ser estrategias de diseño para la internacionalización.

4 Contexto: Conjunto de entornos bajo los cuales existe el patrón. Problema: Describe los problemas de diseño que se ha encontrado el desarrollador. Causas: Lista los razones y motivos que afectan al problema y la solución. La lista de causas ilumina las razones por las que uno podría haber elegido utilizar el patrón y proporciona una justificación de su uso. Solución: Describe brevemente la solución y sus elementos en más detalle. La sección de la solución contiene dos sub-secciones: Estructura: Utiliza diagramas de clases UML para mostrar la estructura básica de la solución. Los diagramas de secuencias UML de esta sección presentan los mecanismos dinámicos de la solución. Hay una explicación detalladas de los participantes y las colaboraciones. Estrategias: Describe diferentes formas en las que se podría implementar el patrón. Consecuencias: Aquí se describen las compensaciones del patrón, esta sección se enfoca en los resultados de la utilización de un patrón en particular o de su estrategia, y anota los pros y los contras que podrían resultar de la aplicación del patrón. Patrones relacionados: Esta sección lista otros patrones relevantes en el catálogo de patrones J2EE u otros recursos externos, como los patrones de diseño GoF. Por cada patrón relacionado, hay una breve descripción de su relación con el patrón que se está describiendo. Figura. 2. Esta es la plantilla genérica utilizada por SUN para definir los patrones Nivel de Cliente En J2EE existen un gran número de tipos de clientes los cuales pueden interactuar con nuestras aplicaciones. Además debemos tener en cuenta que con el rápido avance de tecnología móvil, los tipos de clientes que aparecen cada día son más variados. Por eso debemos contemplar cuando desarrollemos nuestra aplicación, que debe ser lo más flexible posible de tal manera, que soporte el mayor número de clientes existentes y se adapte fácilmente a los nuevos que puedan aparecer. Para ello podemos utilizar estándares ampliamente extendidos que nos proporcionen dicha flexibilidad e independencia del tipo de tecnología utilizada. Es necesario conocer que clientes queremos soportar puesto que debemos tener en cuenta cuestiones como la comunicación con los clientes a través de la red. Debemos elegir el cliente en función de las posibilidades de la red y del tráfico que soporte esta. Si tenemos una Intranet de 1GB o los clientes se conectan a través de Internet mediante un modem de 56 KB. Por otro lado, debemos tener en cuenta la seguridad. La posibilidad de que los clientes se conecten a un lado o a otro del Firewall. En

5 función de a qué lado estén tendremos una serie de protocolos de comunicación, que hacen nuestra aplicación más robusta pero, que no pueden atravesar un Firewall (rmi), o que proporciona un menor acoplamiento (http, soap) pero, que nos aíslan de la utilización de un Firewall. Por último debemos tener en cuenta las posibilidades que nos ofrece la propia plataforma. Según el cliente que vayamos o queramos utilizar tenemos que conocer muy bien que limitaciones tiene, que nos permite y que no nos permite realizar. Entre los diferentes clientes que podemos utilizar, se encuentran los navegadores que pueden utilizar applets para guardar el estado, ampliando su funcionalidad. El abuso de los applets puede llevar a una gran perdida de rendimiento y más si tenemos en cuenta que a estas aplicaciones se conectará la mayoría de la gente desde una línea de baja o media calidad. HTTP/SSL HTTP/SSL HTTP/SSL RMI RMI HTTP/SSL RMI Figura 3. Escenario general de clientes en una aplicación J2EE. A la hora de implementar un cliente debemos tener en cuenta una serie de guías y condicionantes que nos pueden ayudar en dicha implementación y elección del cliente. Carga del cliente La presentación de la vista es una de las tareas fundamentales de los clientes. La lógica de presentación en estas aplicaciones puede obtenerse del servidor, clientes ligeros o navegadores. En este caso, la cantidad de información que se envía a través de la red es más elevada puesto que en la transmisión se envían tanto los datos como la lógica encargada de representarlos. Por otro lado en clientes standalone, lo único que enviamos a través de la red son los datos, este beneficio en la transmisión es muy grande, pero debemos ver si el coste de la realización del cliente es beneficioso. En este último caso el cliente tiene una mayor carga y responsabilidad dentro de la aplicación. La carga en los navegadores se puede ver incrementada con la utilización de javascript, para realizar ciertas operaciones en el cliente, o con la utilización de

6 applets en los navegadores, que aumenta el uso de ancho de banda y se dota al cliente de una mayor carga de trabajo. Validación de entradas del usuario Otro tema importante es donde realizar la validación en los campos de entrada. En el cliente o en el servidor. Por un lado, en los navegadores o clientes ligeros, podemos realizar la validación en el cliente con la utilización de javascript. Qué consecuencias trae esto? En primer lugar, nos da la ventaja de mejorar el rendimiento puesto que su utilización no consume mucho y comparado con las conexiones que se deberían realizar al servidor para validar entradas, el coste es mucho menor. El problema aparece porque cualquier usuario que conozca HTML y javascript se podría saltar estas validaciones enviando datos sin comprobar con las consecuencias que podría conllevar. Por lo tanto, al final, se termina realizando dos veces la misma comprobación, en el cliente y en el servidor. Además, la utilización de javascript en la presentación implica que los roles de programador, diseñador y maquetador no queden tan claramente definidos. Por otro lado tenemos la validación de campos en clientes de escritorio. Es una buena práctica realizar la validación en el cliente puesto que tenemos los beneficios de ganar rendimiento por no estar conectando con el servidor cada vez que se quieran validar entradas y además saltarse estas validaciones es muy complicado al estar el código en binario. Comunicación con el servidor Es obvio pensar que cuando elijamos un tipo de cliente tendremos que pensar en los protocolos de comunicación que soporta para conectar con el servidor. Si vamos a necesitar un cliente ligero se comunicará a través del protocolo HTTP con el servidor. En nuestro caso tendremos un servlet (ActionServlet de Struts) encargado de controlar el acceso a la aplicación para estos clientes. El API de los servlets provee una interfaz simple para el manejo de peticiones HTTP. El abanico de protocolos de comunicación en aplicaciones de escritorio es más amplio que en el caso anterior. Deberemos elegir la forma de comunicación que más nos interese y que más beneficios nos aporte. Hay que tener en cuenta la presencia de Firewalls entre el cliente y el servidor (HTTP o RMI) y si se utilizará distinta tecnología para implementar el cliente y el servidor (SOAP). Manejo del estado conversacional Al igual que en los casos anteriores veremos las posibilidades de los tipos de clientes que pueden aparecer. Por un lado tenemos los navegadores. Estos clientes, como hemos comentado, se comunican con el servidor a través del protocolo HTTP. Dicho protocolo está basado en peticiones y respuesta y cada petición es tratada de manera independiente. Este protocolo por sí solo no tiene mecanismos de mantenimiento del estado entre el cliente y el servidor. Es por esto que se han creado diferentes alternativas para mantener el estado en estos clientes, las cuales mantiene el estado de una sesión entre el cliente y el servidor. Una sesión es un periodo corto de vida en la

7 cual existe un dialogo, basado en peticiones y respuestas, entre el cliente y el servidor. En primer lugar tenemos las cookies. Consisten en pequeños fragmentos de información que el servidor envía al cliente en donde se almacenan. Cada vez que el cliente envía una petición al servidor, el cliente envía las cookies recibidas desde dicho servidor. El problema de las cookies es los agujeros de seguridad que dejan. Por otro lado tenemos un mecanismo de reescritura de la URL incluyendo la sesión en esta. Esta es una alternativa a las cookies pero su problema deriva en el ancho de banda que consumen cada vez que realiza una petición. Con esto es aconsejable que en estos tipos de clientes, el estado sea manejado en el servidor y se establezca un identificador para relacionar al cliente con su estado (Podríamos utilizar la clave de acceso o el login si es único). En los clientes de escritorio, la problemática del estado conversacional no existe puesto que estos clientes pueden manejar el estado de sesión ellos mismos porque pueden manipular y guardar grandes cantidades de datos de estado en memoria. El beneficio de estos clientes es que pueden trabajar sin conexión al servidor con los datos recibidos disminuyendo las conexiones al servidor. Sí se debe tener especial cuidado de no trabajar todo el tiempo sin conexión porque los datos podrían quedar obsoletos en un determinado plazo de tiempo. Nivel Web A la hora de desarrollar el nivel web de nuestras aplicaciones debemos tener en cuenta que es aquí donde se habilita el acceso a la capa de negocio, controlando así la interacción entre los clientes y la lógica de negocio. Se encargará de controlar las peticiones y las respuestas generando contenido dinámico de diversos tipos (Html, sonido, vídeo...). Este nivel también se encarga de mantener el estado de la sesión del cliente (aquí o en el nivel de negocio), acumulando datos sobre las operaciones que ha realizado, y de controlar adecuadamente las transacciones. Estos dos puntos son de especial importancia en aplicaciones críticas, tales como el negocio electrónico o la banca por Internet. Además, este nivel debe proporcionar flexibilidad ante diversos tipos de clientes (navegadores, PDA s, aplicaciones propietarias...), así como mecanismos para tratar la internacionalización. Ambos aspectos permitirán que nuestras aplicaciones sean accesibles y atractivas a un mayor número de clientes. Es por ello que surge la necesidad de diseñar una arquitectura para el desarrollo del nivel Web de nuestras aplicaciones, que nos permita desacoplar adecuadamente este nivel del resto, además de proporcionarnos unos altos niveles de estabilidad, escalabilidad y mantenimiento de dichas aplicaciones. En los siguientes puntos de este capítulo procederemos a la definición de dicha arquitectura y de sus componentes.

8 Utilización de un Framework basado en MVC Si bien todas las aplicaciones Web comparten una serie de requerimientos, las soluciones a estos no son provistas explícitamente por la plataforma J2EE. Para facilitarnos la solución de estos requerimientos surgen los frameworks, que constituyen una extensión del lenguaje mediante una o más jerarquías de clases que implementan una determinada funcionalidad. De este modo, el framework se sitúa como una capa intermedia entre la plataforma J2EE y la aplicación específica, permitiéndonos centrarnos en la lógica de negocio de esta última. Figura 4. Integración del framework con la plataforma y las aplicaciones A la hora de elegir un framework para desarrollar nuestras aplicaciones es conveniente que éste implemente el patrón Modelo-Vista-Controlador (MVC), que es el patrón de diseño de arquitectura recomendado por SUN y el resto de miembros del consorcio J2EE. El patrón MVC organiza una aplicación interactiva en tres módulos separados (uno por cada componente del mismo). Ante una petición del cliente, el controlador interpretará la petición y realizará la comunicación con el modelo, para a partir de dicha interacción seleccionar y generar la siguiente vista que se mostrará al cliente. De este modo se consigue desacoplar la capa de presentación de la lógica de negocio, así como la separación de roles de desarrollo, lo cuál facilita el mantenimiento de dichas aplicaciones. Además, este tipo de frameworks suelen ofrecer otra serie de funcionalidades, además del patrón MVC, como pueden ser la validación automática de campos antes de invocar a la lógica de negocio, métodos automatizados para tratar la internacionalización, integración con otros frameworks o utilidades, así como la implementación de otra serie de patrones.

9 Propuesta de diseño del nivel Web Para el nivel Web hemos definido una arquitectura para el desarrollo de las aplicaciones compuesta por 4 elementos: Servlet Filter: Permite filtrar las peticiones de los clientes. Struts: Framework que implementa que patrón MVC. EJB Controller: Centraliza el acceso al nivel de negocio. Cocoon: Framework para generación de la vista. Figura 5. Esquema general de la arquitectura, y en concreto del nivel web, para el desarrollo de aplicaciones De este modo, se centraliza el acceso mediante el Servlet Filter, para una vez filtrada la petición delegarla en Struts, que, a su vez, delegará le acceso a la lógica de negocio al EJB Controller y devolver los resultados al cliente o delegar la generación de la vista en Cocoon. Servlet Filter Este elemento de la arquitectura intercepta dinámicamente las peticiones y respuestas para transformar o usar la información que contienen. Esta compuesto por un Filter Manager que gestiona una serie de filtros, los cuales se ejecutan según el orden definido en el Filter Chain (un fichero de configuración xml con la secuencia de filtros a utilizar), permitiendo el acceso al recurso objetivo solamente si se han superado dichos filtros. Este patrón, mediante la utilización del Filter Manager y el fichero de configuración, permite añadir y eliminar fácilmente nuevos filtros, lo cual consistiría en generar el código del nuevo filtro y añadirlo en el xml en el lugar adecuado en el que queremos que se ejecute.

10 Figura 6. Esquema del patrón Servlet Filter Entre las ventajas de la utilización del Servlet Filter destacan: Centralización del control de acceso a la aplicación: Mediante la adición de distintos filtros (para validación de usuarios por LDAP, por BD,...) podemos restringir el acceso a nuestra aplicación (el objetivo). Mejora la reutilización: Los filtros se añaden y eliminan al código existente de forma transparente y debido a su interface estándar, funcionan en cualquier combinación y son reutilizables por varias presentaciones. Configuración declarativa y flexible: Al utilizar el Filter Chain para configurar la secuencia de filtros, estos se pueden combinar de distintas maneras sin necesidad de recompilar el código fuente. Permite la depuración y transformación de la salida según el tipo de cliente. Struts El elemento central de nuestra arquitectura para el nivel web es Struts, un framework open source para el desarrollo de aplicaciones web basado en el paradigma de diseño MVC, centrado en las capas de vista y controlador. Este framework centraliza la recepción de peticiones y las asigna a la acción (Action) adecuada, la cual delegará la lógica de negocio en el EJB adecuado (según se indique en el fichero struts-config.xml de configuración de la aplicación), y con el resultado proporcionado por la capa de negocio generará la vista que se devolverá al cliente.

11 Figura 7. Esquema general de Struts Struts esta compuesto por los siguientes elementos: Action Servlet: Este es el componente central del controlador. Recibe las peticiones de los clientes y delega las solicitudes a los Action adecuados, según se indique en el fichero de configuración general struts-config.xml. De este modo, para añadir una nueva funcionalidad a la aplicación bastará con generar el Action correspondiente con la invocación a los métodos de negocio y crear la entrada para dicho Action en el fichero de configuración para atender la petición. Action Mappings: Definidos en el fichero struts-config.xml, asignan a cada solicitud (identificadas por su url) el Action que la procesará. Acceden a los parámetros de la solicitud directamente o mediante los ActionForm. Actions: Son los encargados de procesar las solicitudes del usuario llamando al modelo, devolviendo el resultado en el ActionForm o en la sesión. También devuelven un ActionForward indicando la url que se visualizará a continuación. Action Forms: Permiten acceder a los parámetros de la solicitud, por lo cual son especialmente útiles para obtener y validar los datos de entrada, los cuales se guardan en Value Objects (java beans). También son utilizados por los Actions para devolver los resultados, permitiendo así el tráfico de datos entre capas. Action Forwards: Son definidos en el fichero de configuración general struts-config.xml. Realizan la llamada a la página a visualizar (URL) según el código de éxito o error que devuelva el Action invocado, por lo cual se

12 puede variar la página de destino sin modificar el código del Action, pues solo habría que modificar el destino en el fichero struts-config.xml. Resources Properties: Estos ficheros, con extensión.properties, son los encargados de tratar la internacionalización en Struts. Se define uno por cada idioma, conteniendo cadenas del tipo etiqueta=valor. Form Tags: Librerías de etiquetas para los JSP s mediante las cuales se pueden obtener los datos de los Action Forms y los Resource Properties para generar la vista. Page Templates: Son las páginas JSP mediante las que se generará la vista que se devolverá al cliente. Sólo contienen código de presentación y llamadas a los Form Tags para obtener los datos a visualizar. De este modo, ante una petición del cliente, el Action Servlet consultará el fichero de configuración struts-config.xml para delegar en el Action correspondiente la interacción con la capa de negocio y creará el Action Form con los datos de la solicitud. Una vez ejecutado el Action, este devolverá un Action Forward según haya habido éxito o no, y los datos obtenidos de la capa de negocio se devolverán en el Action Form o en la sesión. El Action Forward obtenido para el Action permitirá al Action Servlet decidir (consultando el struts-config.xml) que JSP generar, el cual utilizará los Form Tags para obtener los datos del Action Form devuelto por el Action y los Resources Properties para la internacionalización. Los patrones que nos proporciona Struts son los siguientes: Front Controller: Implementado por el Action Servlet y el fichero strutsconfig.xml, permite centralizar el procesamiento de las peticiones y simplificar la validación unificada. Además, mejora la modularidad, escalabilidad y mantenimiento de las aplicaciones. Transfer Object: Implementado por los Action Form y los Form Tags, permiten transferir más datos entre capas en menos llamadas, reduciendo así el tráfico de red. Composite View: Implementado por los Page Templates (los JSP s) a la hora de generar las vistas a partir de otros JSP s y HTML, permite mejorar la modularidad, el mantenimiento y la reutilización de código. Cocoon Cocoon es un sistema de publicación web basado en XML/XSL, que formatea y/o genera el XML final según la hoja de estilo XSL utilizada. También permite escribir paginas de servidor en XML (XSP s), añadiendo así una mayor portabilidad a las aplicaciones, pues dichos XSP s son independientes de la tecnología utilizada por el servidor de aplicaciones. Al utilizar Cocoon se obtiene una mayor flexibilidad, al permitir seleccionar el XSL a aplicar al XML según el tipo de cliente o la ubicación del recurso, generando las cabeceras adecuadas para que las entienda el navegador o aplicación del cliente.

13 Figura 8. Funcionamiento de Cocoon Dentro de nuestra arquitectura de desarrollo para el nivel web vamos a utilizar Cocoon para la generación de la vista que se devolverá al cliente, a partir de la vista en formato XML devuelta por Struts, situándose así como una capa intermedia entre Struts y el cliente. De este modo, mediante Cocoon, conseguimos reducir el número de acciones (Actions) de Struts que habría que utilizar para generar distintos tipos de contenido. En lugar de utilizar un Action por cada tipo de contenido, se generará (mediante Struts) un único XML, con el resultado de la interacción con la lógica de negocio, que se formateará con la hoja de estilo XSL adecuada según el tipo de contenido solicitado, lo cual proporcionará una mayor escalabilidad y mantenibilidad a nuestras aplicaciones. StrutsEJB Para el acceso a la lógica de negocio vamos a utilizar un framework, StrutsEJB, que implementa el patrón Front Controller. Mediante éste patrón obtenemos un acceso centralizado al nivel de negocio, acelerando así la integración entre Struts y los EJB s. Con StrutsEJB para acceder a un método de negocio se escribiría un EJBCommand con la lógica de negocio y se indicaría en el struts-config.xml el mapeado con la correspondiente petición. De este modo se evita tener que crear un Session Bean por cada componente de lógica de negocio, al crearlos implícitamente. También nos evita tener que crear un Action y un ActionForm por cada paso de Struts, al utilizar uno genérico al que llamarán los EJBCommand. Además, este framework nos proporciona implícitamente patrones para el acceso a la lógica de negocio como el Business Delegate y el Service Locator, y nos facilita el tráfico de datos entre la capa web y la EJB.

14 Figura 9. Acciones realizadas por StrutsEJB al invocar un EJBCommand StrutsEJB nos libera de tener que implementar una serie de patrones que garantizan el desacople entre las capas web y de negocio de nuestra aplicación. En concreto, ante una petición del cliente, se invocaría a un Action genérico (en lugar de tener que implementar uno por cada método de negocio) con la petición y los parámetros de esta, el cual delegaría su ejecución en el Business Delegate, el cual según el tipo de proceso (indicado en el struts-config.xml) invocaría a un Facade con estado o sin estado, el cual invocaría finalmente al EJBCommand (el que hemos programado) para acceder a la lógica de negocio, tal y como se haya mapeado en el fichero strutsconfig.xml. Los patrones de diseño que nos proporciona este framework son: Business Delegate: Reduce el acoplamiento entre capas y oculta la complejidad de los servicios remotos, al adaptar la interfaz del objeto a una más amigable para el cliente. Transfer Object: Permite el tráfico entre capas transfiriendo más datos en menos llamadas, reduciendo así el tráfico de red. Service Locator: Proporciona un acceso uniforme a los servicios, abstrayendo al cliente de la complejidad de la búsqueda de componentes y tratar con factorías de objetos. Además, facilita la adición de nuevos componentes de negocio y mejora el rendimiento de la red y el cliente. Value List Handler: Implementado como una clase del framework, proporciona un navegador de registros (como el que ofrecen los buscadores para navegar por los resultados de la consulta), ofreciendo así una mayor flexibilidad de consulta, creando una caché de resultados de la consulta en el lado del servidor, con la consiguiente mejora en el rendimiento de la red. Como podemos ver, mediante StrutsEJB conseguimos acelerar el desarrollo de aplicaciones con Struts al facilitarnos el acceso a la capa de negocio y reducimos la cantidad de código a desarrollar, con la consiguiente mejora en mantenibilidad y tiempo de desarrollo de nuestras aplicaciones.

15 Nivel de negocio J2EE ofrece una serie de componentes y servicios ideales para la creación e implementación de la lógica de empresa. Antes de utilizar estos componentes y servicios se deben conocer bien para elegir su correcto uso y localización dentro de nuestra aplicación. Además existen ciertas consideraciones que debemos tener presente. Muchas de estas consideraciones se deben a la aparición de este nuevo nivel, frente a las arquitecturas anteriores en las cuales se hacía prácticamente todo en el nivel web. Debido a las características que nos ofrece el nuevo nivel es el adecuado para la implementación de la lógica de empresa. Las consideraciones las enumeramos a continuación. Transacciones. Utilizar transacciones de forma declarativa o programada. En este nivel y gracias al middleware que nos ofrecen los proveedores de servidores de aplicaciones o contenedores de EJB, utilizaremos de una forma muy sencilla transacciones declarativas, puesto que se encargará el contenedor de manejar esta y nosotros simplemente, en ficheros de configuración, indicamos que un componente utilizará un determinado tipo de transacción. Tipo de comunicación: síncrona o asíncrona. La elección de una o de otra dependerá del tipo de aplicación o de las necesidades de los diferentes módulos que conformen la aplicación. Es obvio que cuando queremos una respuesta inmediata en la comunicación utilizaremos mecanismos ofrecidos por J2EE cuya comunicación es síncrona. Si por el contrario la respuesta no ha de ser inmediata podemos optar por mecanismos asíncronos. Interfaces remotas o locales en los EJB. Estas interfaces son las que nos permiten el acceso a la clase que implementa la lógica. Dichas interfaces pueden ser locales o remotas. Las primeras serán utilizadas cuando los EJB se encuentren en la misma máquina virtual de java de los clientes que quieren acceder a ellos. La utilización de estos interfaces es idónea para evitar perdidas de rendimiento a través de la comunicación. El uso de los interfaces remotos está orientado a permitir el acceso a la lógica de empresa desde otros niveles y desde otras máquinas virtuales. Más adelante describiremos en que casos deberemos utilizar unos u otros. Acceso a datos ya sean sistemas relacionales o sistemas heredados o cualquier sistema que nos permita el almacenamiento de datos es un punto importante en las aplicaciones. J2EE nos proporciona elementos de acceso a bases de datos relacionales y de conexión a sistemas heredados. Además veremos patrones que nos ayudan a hacer el acceso a datos transparente del tipo de almacén utilizado. Mantenimiento del estado conversacional. Una de las grandes cuestiones a la hora de plantear el diseño de la aplicación es En qué nivel mantener el estado conversacional? J2EE ofrece mecanismos para realizarlo en este nivel. Además la mayoría de las implementaciones de contenedores de EJB permiten el traspaso de sesión en caso de que nuestro servidor caiga. Posteriormente también comentaremos que medios se nos ofrecen para el mantenimiento de la sesión en J2EE.

16 La seguridad es otro de los temas importantes que contemplamos en este nivel. J2EE ofrece, por un lado, mecanismos propios de seguridad y por otro lado, la posibilidad de integrar mecanismos de seguridad ampliamente conocidos (SSL, LDAP, Kerberos...). Internacionalización. Simplemente el poder ofrecer tú aplicación en los distintos idiomas o contemplarlo, es un enriquecimiento del software. Debemos diseñar este nivel para devolver los datos al nivel web en función del idioma y la localización solicitada. A continuación veremos más en profundidad las decisiones de diseño que podemos tomar y porque pensamos que son las más adecuadas. Decisiones generales de diseño Antes hemos visto que consideraciones debemos tener en cuenta a la hora del diseño de nuestra aplicación en el nivel de negocio. Ahora describiremos que componentes nos ofrece J2EE y cuando utilizar cada uno con las consideraciones comentadas anteriormente. Entity Beans Este tipo de EJB se encarga de la persistencia de los datos, sea cual sea el tipo de almacén en el que se encuentren. La persistencia la puede manejar el propio EJB (bean-managed persistence) o manejarla el propio contendor de EJB (containermanaged persistence). Normalmente nos interesará que estos tipos de EJB tenga interfaces locales puesto que el rendimiento entre la comunicación de este tipo de EJB debe ser óptimo. Intentaremos evitar las interfaces remotas en estos EJB siempre que sea posible utilizando los EJB de sesión como fachada de acceso a estos. En el caso de ser necesaria la utilización de interfaces remotos utilizaremos patrones como Value Object, que nos ayuden a aumentar el rendimiento de transmisión de la información. Este patrón encapsula los datos, generalmente en una clase, y que dicha clase tendrá los métodos necesarios de acceso a dicha información. Al trabajar con este patrón transmitimos los datos una vez y el cliente ya puede trabajar con ellos, ayudandonos a reducir el número de llamadas remotas. Por otro lado cabe destacar cuando nos interesará utilizar EJB de entidad o no. Los EJB manejados por el contenedor están indicados para mantener la persistencia de bases de datos relacionales. Ofrecen una enorme facilidad para relacionar tablas con EJB y un mecanismo de relaciones que nos permite acceder a los datos de un EJB, que se relaciona con otro, de una forma sencilla. El único problema es que la configuración de estas relaciones es un poco más complicada. El otro tipo de EJB de entidad (bean-managed) nos ofrece un mayor control de operaciones y mayor flexibilidad en detrimento de implementar nosotros la lógica para acceder al almacén de datos. Son adecuados para acceso a datos no relacionales o para hacer transparente al tipo de almacén que accederemos utilizando un patrón llamado Data Access Object. Nos permite un mayor desacople del almacén persistente que utilicemos haciendo sencilla la migración de un sistema a otro.

17 Session Beans Se encargan de controlar la comunicación de los EJB de entidad y del proceso en su conjunto. Normalmente estos EJB serán recomendables que utilicen tanto interfaz remoto como local dependiendo de su uso. Si implementan métodos de negocio, que no representan un caso de uso completo, utilizados por otros EJB de sesión para realizar una funcionalidad completa usaremos interfaces locales. Si el session bean representa uno o varios casos de uso y es la fachada a la lógica de negocio entonces necesitará una interfaz remota. En el último caso, estaremos implementado el patrón Session Facade. Con este patrón encapsulamos la complejidad de la interacción entre los objetos de negocio participantes en un flujo de trabajo. Nos provee de un acceso unificado a la lógica de negocio y nos ayuda en el mantenimiento de la aplicación. Existen dos tipos de EJB de sesión. Por un lado están los EJB que no mantienen el estado (stateless). Simplemente, el cliente hace peticiones, pero estas no necesitan guardar el estado entre ellas. Por otro lado tenemos los EJB que si guardan el estado de la sesión (stateful). Estos, son utilizados para mantener el estado de sesión en el nivel de negocio. Cuando necesitemos mantener el estado de conversación entre el cliente y el servidor deberemos utilizar este tipo de EJB. Es obvio que el coste de utilizar un tipo u otro es diferente. El mantenimiento del estado conlleva un coste pero es un buena política implementar el estado en este nivel en lugar de en el nivel web, donde podríamos perder el estado si el servidor cae. Un caso donde se requiere mantener el estado podría ser un EJB (Stateful) que representase un carrito de la compra. Por último los session bean también pueden ser utilizados para integrar distintos niveles (nivel web y nivel de negocio). Podemos utilizar un Session bean para implementar el patrón Business Delegate y asi obtener los beneficios de este. La idea es reducir el acoplamiento entre la lógica de presentación en el nivel web y los servicios de negocio en el nivel de empresa. Además proporciona una forma unificada de acceder a la lógica de negocio y facilita el mantenimiento de la aplicación. En la figura 10 podemos ver un pequeño escenario genérico donde aparece un ejemplo de cómo se debería utilizar cada componente y cada patrón dentro del nivel de lógica de negocio. El patrón Business Delegate, en nuestro caso implementado por struts-ejb, llamaría al session bean, que implementan el patrón Session Facade, correspondiente al caso de uso que es requerido por el cliente. Este session bean funcionaría de controlador instanciando a los EJB de persistencia y a los EJB de session correspondientes para realizar el caso de uso completo. Los EJB de session instanciados por el Session Facade simplemente realizarían operaciones que completasen el caso de uso, pudiendo agrupar a su vez un conjunto de operaciones. Los EJB de persistencia o entidad como comentamos anteriormente, podían ser de dos tipos. Manejados por el contenedor que como apreciamos en la figura 10 nos sirven para el acceso a bases de datos relacionales. Por otro lado estarían los bean managed, los cuales son controlados por nosotros y nos sirven para implementar el patrón Data Access. En la figura 10 vemos como los datos pueden estar almacenados en múltiples sistemas (Excel, LDAP). El Patrón Data Access Object contempla otra estrategia de implementación como vemos. En este caso no usaríamos EJB de entidad si no que utilizaríamos clases java, las cuales se utilizarían desde Beans de Sesión. El

18 coste de implementar estas es mayor, puesto que no cuentan con los servicios aportados por el contenedor de EJB pero el rendimiento puede ser beneficioso. Value Object remote home SF beanvo interfaz Bean DAO LDAP EJBCommand remote SL home local home BMP BMP EXCEL DTO re m home SL Session Facade local home CMP CMP CMP SGBDR Negocio Persistencia e Integración Nivel de Empresa Nivel de EIS Figura 10. Escenario general de componentes y patrones utilizados en el nivel de negocio en una aplicación J2EE. Caso de estudio En este apartado vamos a presentar un pequeño ejemplo del escenario mostrado en la figura 10. En nuestro ejemplo tenemos una empresa de viajes. Dicha empresa lleva la gestión de hoteles en diferentes ciudades pero se apoya en otras empresas para recibir las tarifas y billetes de vuelo a esas ciudades. Con todos los datos que el cliente solicita se le ofrece una tarifa de precios del viaje completo que quiere realizar. En al figura 11 observamos como la empresa tiene su modelo de datos relacional en los cuales almacena la información de los hoteles en cada ciudad. Hemos creado un Container-maneged encargado de localizar los hoteles por la ciudad elegida por el cliente. Tendremos una clase que implementará el patrón Value Object, encargado de encapsular todos los datos devueltos.

19 Figura 11. Acceso a la información propia de la empresa. En la figura 12 se muestra un diagrama de clases en el cual podemos ver como accedemos a un documento Excel enviado por la empresa externa. Dicho fichero contendría la información de los vuelos por ciudades. Hemos decidido almacenar la información en un fichero Excel pero, para nosotros, debería ser transparente el almacén utilizado. En este caso se implementa un patrón Data Access Object utilizando para ello un bean-managed. Deberíamos utilizar el patrón Value Object para encapsular los datos. Además podemos ver un ejemplo de un Stateless al cual un cliente no puede acceder de una forma directa. Es una sub-operación del caso de uso general del cálculo de precios. Este EJB se encargará de calcular la tarifa de vuelos que vamos a dar al cliente a partir de las que nos proporciona la empresa externa más la comisión por la gestión. En la figura 13 observamos las operaciones que puede realizar un usuario. En primer lugar puede obtener la información de un viaje y posteriormente realizar la reserva. Vemos las operaciones entonces que deberían conllevar un Session Facade que dará acceso al cliente a la lógica de empresa. Este Session Facade estará implementado por un Stateless puesto que entre operaciones no necesitamos conservar el estado. En la siguiente figura vemos como el Session Facade interactúa con los EJB necesarios para poder realizar su operación y devolver los datos al cliente.

20 Figura 12. Acceso a la información de empresa externa. Figura 13. Casos de uso de la gestión de viajes.

21 Figura 14. Escenario general de clases de la gestión de viajes Message Driven Bean Se trata de otro tipo de EJB los cuales están orientados al flujo de procesos. Son EJB dirigidos por mensaje que no tienen una invocación directa desde un cliente. Se encuentran escuchando, esperando la llegada de un mensaje. Cuando este llega comienzan su actividad. Son EJB utilizados para la integración de aplicaciones java con un mecanismo de comunicación asíncrono proporcionado por la plataforma J2EE. Una aplicación puede enviar un mensaje a otra y olvidarse de este mensaje hasta que la otra aplicación los procese y devuelva la respuesta. Uno de sus mayores beneficios es que produce desacoplamiento entre las aplicaciones. En nuestro caso los usaremos como controladores y cada message driven bean se encargará de una actividad dentro del proceso global. Dentro del propio message driven bean no realizaremos las operaciones de negocio oportunas, si no que el message driven bean deberá delegar cada operación en los correspondientes objetos de negocio para conseguir realizar la operación completa. Podrá instanciar EJB de entidad o clases java (Object Delegate) para realizar las tareas o EJB de session que realicen tareas más complejas.

22 Negocio Persistencia Nivel de EIS remote prepararviajefacad gestionestadoviaje ejbcommand DTO home BeanTD SL MDB local CMP home BeanVO estadovo SGBDR BeanHelper Queue Solicitud Queue Respuesta Aplicación Externa Figura 15. Escenario genérico orientado al flujo de proceso En la figura 13 vimos los casos de uso de la agencia de viajes. Las operaciones que podía realizar un usuario eran, obtener información y solicitar reserva. En este apartado vamos a utilizar la última para entender el uso de los message driven beans utilizando la figura 15 como escenario. Como sucedía en el ejemplo anterior, el cliente confirmará la reserva del viaje. El nivel web instanciará la lógica de negocio mediante struts-ejb, el cual implementa varios patrones para producir un mayor desacoplamiento entre los niveles. En este momento se llama al Stateless que implementa el patrón Session Facade, preparaviajefacade. Este EJB se encargará de controlar las operaciones que se deben hacer para la reserva de viaje. En primer lugar llamará a un EJB de entidad que se encargará de marcar el estado de la solicitud del cliente (EN CURSO en principio). Esta información se podría guardar en una tabla de base de datos relacional que indicase el código de la petición y su estado actual. Una vez el Session Facade realiza la operación de estado pasaría a realizar otra operación. En este caso la nueva operación podría ser la petición de billete de avión a la empresa externa que lo gestiona. Para ello utilizaríamos una clase java (Object Delegate) que enviaría el mensaje de petición a una cola JMS en la cual se encuentra escuchando un message driven bean de la empresa externa, que integra su aplicación con la de la empresa de viajes. Una vez la aplicación de la empresa externa acepte o deniegue el billete por

23 falta de vuelos, su aplicación lo enviará a otra cola de mensajes en la cual tendríamos otro message driven bean escuchando. Este message driven bean tendrá dos cometidos. Por un lado actualizar el estado de la petición (ACEPTADA o RECHAZADA) del cual se encargaría en EJB de entidad que comentamos anteriormente. Por otro lado llamaríamos a una clase java (Object Delegate) encargada de enviar un correo al usuario que hizo la petición. Como hemos observado cada cola de mensajes se puede ver como el fin de una actividad del flujo y comienzo de otra. Servicios Web Hemos visto elementos del nivel de empresa de integración entre aplicaciones java. Pero existen unos mecanismos basados en estándares que nos permiten la integración de aplicaciones heterogéneas. También se podría utilizar el protocolo HTTP para interactuar en dichos entornos de diferentes tecnologías, pero el mecanismo de servicios web está orientado a ellos y nos ofrece una interfaz más sencilla de utilizar. Los servicios web nos permiten acceder a cualquier parte de la lógica de empresa, utilizando dentro de las aplicaciones diferentes tecnologías. Negocio Persistencia Nivel de EIS ejbcommand DTO remote SL home BeanTD MDB E local CMP home BeanVO estadovo SGBDR BeanHelper Queue Solicitud Queue Respuesta Web Service Aplicación Externa Figura 16. Escenario genérico orientado al flujo de proceso integrando aplicaciones heterogéneas. En la figura 16 tenemos el mismo caso que mostrábamos antes pero si la empresa externa hubiera desarrollado en otra tecnología, como.net, su aplicación podríamos utilizar los servicios web para integrar ambas. En este caso el message driven bean que escucha en la cola Queue Solicitud estaría en nuestra aplicación y este al recibir

24 un mensaje instanciaría un servicio web de la aplicación externa que realizaría la solicitud. De la misma forma cuando nos enviasen la petición se llamaría a un servicio web encargado de depositar en nuestra cola el mensaje y comenzaría la segunda actividad. Internacionalización Haber contemplado la internacionalización en una aplicación conlleva al enriquecimiento de esta y es un valor añadido, sobre todo cuando la aplicación se ofrece a través de Internet y pueden acceder a ella múltiples usuarios de diferentes países. Una de las principales tareas es preparar todos nuestros modelos de datos para que contemplen la internacionalización. Una manera sencilla de hacerlo es introducir en la clave primaria de las tablas que lo requieran un campo idioma. Si se quiere normalizar más se puede crear tablas con el código de idioma y los textos pero se podría volver inmanejable. Seguridad Comentamos anteriormente que J2EE proporciona mecanismos propios de seguridad pero también nos ofrece APIS que nos permiten utilizar otros mecanismos de seguridad altamente conocidos. En nuestro caso veremos como la seguridad, no solamente la de las aplicaciones si no también la de otros sistemas, la centralizaremos en un servicio de directorios como OpenLDAP o Active Directory. Mediante JNDI podremos acceder a dichos directorios y además podremos utilizar mecanismos de seguridad como Kerberos o SSL gracias al API JAAS. Login Filter Struts Cocoon S t r u t s EJ B home remote SF loginfacade local home logindao BMP jndi;jaas LDAP GenericJaas GenericLdap Login.xml KbJaas SSLJass ADLdap OpenLdap Negocio Integración Nivel Web Nivel de Empresa Figura 17. Escenario de la aplicación para la autenticación de usuarios. En la figura 17 tenemos el escenario de nuestra propuesta para la autenticación de usuarios. Tendremos un fichero XML de configuración mediante el cual podremos definir a qué servicio de directorio vamos a acceder y con qué mecanismo de seguridad. Cuando el usuario se vaya a conectar la implementación del patrón Filter Request que hemos realizado se encargará de leer dicha configuración e instanciar el