Arquitecturas de n-niveles y J2EE para el desarrollo de grandes aplicaciones de gestión de red

Transcripción

1 Arquitecturas de n-niveles y J2EE para el desarrollo de grandes aplicaciones de gestión de red Francisco Maciá Pérez 1, Virgilio Gilart Iglesias 1 y Juan Antonio Gil Martínez-Abarca 1 1 Departamento de Tecnología Informática y Computación, Universidad de Alicante AP. 99, 03080, Alicante, España {pmacia, vgilart, gil}@dtic.ua.es Resumen. Abordar el desarrollo e implantación de grandes aplicaciones escalables sobre redes globales dirigidas a entornos empresariales o industriales implica aspectos realmente críticos: cómo elegir las tecnologías más adecuadas en la actualidad y que puedan ser vigentes al mayor largo plazo posible; cómo hacerlo desde una visión global en la que se considere las aplicaciones y sistemas ya existentes y se facilite la implantación y ampliación de aplicaciones e infraestructuras a medida que evoluciona la organización; cuáles son las implicaciones para las aplicaciones de negocio existentes, en particular para las CRM, las ERP, los SCM y la BI; cómo se desarrolla una visión para una arquitectura a largo plazo; o cómo se produce el retorno de la inversión y la mejora en la eficacia. En este artículo se ponen de manifiesto todas estas cuestiones y se presenta una arquitectura de componentes software distribuidos basada en el modelo arquitectural de n-niveles, como uno de los modelos que en la actualidad mejor se adaptan a la resolución de este tipo de problemas. Una vez definido el modelo, se discuten diversas plataformas middleware disponibles en la actualidad para su desarrollo y cuáles son patrones de diseño que mejor se ajustan a las necesidades planteadas. Introducción En la actualidad está claro que las grandes aplicaciones de negocio electrónico deben aprovechar todo el potencial que ofrecen las tecnologías vigentes [6] como Internet, el almacenamiento masivo, las técnicas de programación basadas en componentes software distribuidos, etc., sin embargo, esta necesidad parece que todavía no se ha visto reflejada en el desarrollo de las aplicaciones que deben gestionar tanto estas grandes aplicaciones de negocio electrónico como las infraestructuras que les deben dar soporte: aplicaciones de monitorización de red, de gestión de la seguridad, de administración de sistemas o de gestión de recursos y usuarios en general [7]. Observando este tipo de aplicaciones se puede apreciar con facilidad que siguen modelos tradicionales de diseño, desarrollo e integración con el resto del sistema. Modelos que están mucho más centrados en resolver un determinado problema de administración que en constituirse como parte integrada en

2 un todo. En cualquier caso, se trata de enfoques divergentes con respecto a los enfoques seguidos para las aplicaciones de negocio. En este artículo se propone, precisamente, la necesidad de plantear enfoques convergentes en el desarrollo de ambos tipos de aplicaciones. Es más, la necesidad de no realizar distinciones entre las mismas más allá de lo puramente necesario. Para alcanzar este objetivo resulta imprescindible obtener una visión que permita concebir una arquitectura más sólida y duradera, superando el tradicional modelo clienteservidor [8] y realizando una concepción global del sistema; concepción que debe abarcar todos y cada uno de los aspectos que intervienen y, previsiblemente, intervendrán en el sistema que se desea desarrollar, incluida la identificación de los elementos importantes para mantener las actuales inversiones en sistema de gestión heredados [6,2]. Finalmente, se deberá definir un plan de implantación que determine cómo migrar a dicha arquitectura [6]. Dicho plan deberá establecer los procedimientos, plazos y evaluaciones necesarias para que pueda ser viable un proyecto tan ambicioso. A pesar de esta necesidad ineludible de aprovechar y extraer al máximo aquello que las tecnologías de la información y de las comunicaciones puedan ofrecer en la actualidad, la solución propuesta no puede, ni debe, implicar en ningún momento tecnología. Obviamente, utilizaremos tecnologías Internet y procesos de negocio innovadores para desarrollar aplicaciones de gestión que amplíen los límites tradicionales de tiempo, espacio, departamentos, organizaciones, etc. Sin embargo, esta utilización deberá estar contemplada dentro de un plan global preconcebido [11] en lugar de confiar en ella para resolver posibles problemas que no hubieran sido contemplados desde un principio, como la necesidad de mayores anchos de banda o la ampliación del espacio de almacenamiento. Las aplicaciones así desarrolladas deben ofrecer características adicionales a los sistemas tradicionales de gestión: añadiendo valor, abaratando los costes e impulsando la exploración de nuevos métodos de gestión. Resumiendo, los principios de diseño que se proponen para el desarrollo de estas grandes aplicaciones de gestión son los siguientes: Desarrollo basado en estándares y tecnologías abiertas: flexibilidad para transportar la aplicación entre diferentes plataformas físicas. Dividir la aplicación en diferentes capas: fuertemente acopladas las internas y débilmente con respecto a las de otros modelos. Utilizar tecnologías probadas y estables que presenten una curva de madurez adecuada a las necesidades. Aprovechar inversiones en sistemas existentes: uno de los mayores potenciales de las aplicaciones ebusiness. Prever la dificultad y costes para conseguir personal con habilidades técnicas puesto que se trabaja con un mercado laboral muy concreto. Siguiendo estos principios, en el siguiente apartado analizaremos las tecnologías web actuales como tecnología válida para la implantación de aplicaciones basadas en modelos cliente-servidor ligeros. En el apartado tercero analizaremos las plataformas middleware que deben dar soporte a los modelos basados en componentes software distribuidos. En el apartado cuarto se analizará la conveniencia de contemplar la totalidad de los aspectos que pudieran intervenir en el desarrollo de la aplicación y la idoneidad de utilizar una arquitectura técnica de n-niveles [12,13] que pueda obtener

3 mayor partido de las tecnologías actuales. Una vez sentadas las bases del desarrollo de las aplicaciones, en los apartados cinco, seis y siete nos centraremos en la plataforma J2EE como conjunto de especificaciones y tecnologías que permiten contemplar todos los aspectos descritos, justificando su elección sobre otras tecnología y herramientas. En el apartado octavo se aborda un escenario de integración de las tecnologías implicadas. Finalmente, en el apartado noveno, se analiza las principales conclusiones que se extraen de las propuestas realizadas. Tecnología Web En sus orígenes, la tecnología Web, basada en el protocolo HTTP para la transmisión de hipertexto sobre protocolos de comunicaciones TCP/IP, sirvió para proporcionar una nueva visión de Internet [8]. Si antes, con servicios como FTP, la Red se concebía como un conjunto de nodos servidores que había que conocer, ahora se logra un nivel de abstracción mayor: lo que importa es la información los contenidos en términos del WWW en lugar de su ubicación o de las características de los servidores en los que está ubicada. Es más, deja de preocupar en gran medida desde qué tipo de dispositivo queramos acceder a los contenidos computador personal, PDA, WebTV, teléfono móvil, etc [9]. Cliente Servidor Red de Comunicación Recurso Cliente Protocolo de Comunicación (TCP/IP) Protocolo de Aplicación Servicio Know- How Figura 1. Modelo Cliente/Servidor sobre TCP/IP. Estas características de independencia entre clientes y servidores, unida al auge de la generación de contenidos en Internet y la enorme heterogeneidad reinante en el entorno de las TIC, facilitan que prospere rápidamente este nuevo modelo cliente/servidor [8]. Sin embargo, debido en parte a su cada vez mayor participación en el mundo de los negocios y a la necesidad, por tanto, de generación de contenidos dinámicos, cada vez son más las tecnologías que en los últimos tiempos han ido adosándose a nuestros servidores Web y, porqué no, a engordar nuestros navegadores. Está claro que se necesita una mejor gestión de recursos y una mayor organización. Atrás quedaron los tiempos en que la Web era un mero escaparate de consulta de información estática, dónde las empresas presentaban su catálogo de productos o su oferta de servicios. En la actualidad se tiende a ir paulatinamente haciendo efectivos

4 los diferentes servicios, que ya se prestan por otros medios, en esa red universal que es Internet. Para ello, las aplicaciones convencionales cliente/servidor para redes locales o corporativas, escritas pensando en un entorno determinado, deberán ser adaptadas a las nuevas características e idiosincrasia que imponen las tecnologías de Internet en general y de la Web en particular [6]. Servicio HTTP Básicamente, una aplicación Web es cualquier aplicación basada en la arquitectura cliente/servidor [8], donde el cliente es un navegador y el servidor es un servidor Web, utilizando ambos para su entendimiento los protocolos de Internet (ver figuras 1 y 2). Servidor WEB Gestión de transacciones protocolo solicitud-respuesta (HTTP) representación externa de datos (MIME) Navegador SO protocolo comunicación (TCP/IP) SO TCP/IP HW NIC HW NIC Red de Comunicación Figura 2. Modelo de servicios de la arquitectura cliente/servidor sobre Intenet. El protocolo con el que se comunican las diferentes máquinas conectadas a Internet es TCP/IP [8]. Después, y a modo de capa por encima de éste, cada servicio existente en la red implementa su propio protocolo de aplicación, de forma que clientes y servidores de un mismo servicio puedan entenderse y hablar el mismo leng uaje. Método URL Versión Cabecera GET // HTML/1.1 Figura 3. Formato de una solicitud HTTP. Un servidor Web y un cliente Web o navegador se entienden a través del protocolo HTTP, por medio del cual intercambian información. En la figura 3 se puede apreciar un ejemplo de solicitud de página HTML utilizando este protocolo.

5 El cliente realiza peticiones y el servidor se las sirve. Es la filosofía general de toda aplicación basada en la arquitectura cliente/servidor, dentro de la cuál una aplicación Web no es una excepción. En principio, un servidor Web elemental sólo está preparado para servir información estática, normalmente en forma de páginas HTML, lenguaje que se utiliza para posicionar el contenido de dicha página y que conoce el cliente o navegador que las va a interpretar. En la figura 4 se presenta el contenido de una sencilla página HTML con el típico caso de ejemplo hola a todos. <HTML> <CAB> <TITTLE> Saludos </TITTLE> </CAB> <BODY> Hola a todos <BR> </BODY> </HTML> Figura 4. Contenido de un sencillo documento HTML. Un documento HTML (HiperText Markup Language), tal y como sus siglas indican, está formado por los siguientes elementos: Documento de texto. Etiquetas de formato: <etiqueta [arg1 arg2...]>... [</etiqueta>] Referencias cruzadas: <A HREF= URL > texto descriptivo </A> Puesto que HTML es un protocolo pensado para la transferencia de texto, aquellos archivos de datos binarios (imágenes, sonidos, etc.) asociados al documento y que son necesarios para su representación se codifican en un formato de texto denominado MIME (Multipurpose Internet Mail Extension) que permite el intercambio de datos en formato texto a través de Internet. Una vez recogida la respuesta por parte del navegador, éste la interpretará con el fin de presentársela de forma adecuada generalmente en modo gráfico al usuario final (figura 5). A medida que crece la importancia de las aplicaciones Web y comienzan a necesitar generar información dinámica, propia del mundo de las aplicaciones de índole comercial, empiezan a añadirse una gran diversidad de tecnologías nuevas, tanto a la parte servidora como a la parte cliente. Durante los últimos años, esto se ha ido haciendo de una forma casi anárquica, implementando tecnologías, en su mayoría propietarias, con pretensiones de convertirse en estándares [6]. En la parte cliente, los navegadores crecen en capacidad de interpretación y son capaces de trabajar con tecnologías como DHTML, ActiveX o applets Java, por no

6 mencionar los innumerables plug-ins que introduce el mundo multimedia en la Web. En general, tal y como se muestra en la figura 6, la idea fundamental de estas mejoras se orienta a añadir kown-how en la parte del cliente. Esto se consigue, entre otras formas, transfiriendo dicho conocimiento junto con la información a tratar. Cliente Servidor Web Internet TCP/IP J Pág. PEG J HTML PEG HTML Cliente ligero Navegador Web HTTP JPEG Pág. HTML JPEG httpd Figura 5. Posible escenario de desarrollo para un servicio HTML básico Servidor Web Cliente Internet HTML Cliente ligero Navegador Web HTTP J Pág. PEG J PEG HTML knowhow httpd Figura 6. Modelo de enriquecimiento del Cliente. En la parte servidora, se rodea al servidor Web de una serie de tecnologías que le permiten ampliar su funcionalidad básica de servir información estática. Unas van perfeccionando a otras, pero es tan rápida su evolución que, si bien se tiende a sustituir las más viejas, hoy por hoy conviven todas en cualquier aplicación Web de cierta envergadura o que lleve cierto tiempo en el mercado, como es el caso de los portales corporativos de las grandes empresas. Conviene por ello hacer un repaso, siquiera somero, a todas ellas.

7 Servidores ligeros Dentro de los servidores ligeros se incluyen tecnologías como php, servlets o dll generadas con ASP.Net [14]. En todos los casos, la idea fundamental subyacente es la de crear pequeñas aplicaciones que se ejecutan en el servidor al ser invocadas por un determinado cliente, realizan una tarea y generan una salida que es enviada al navegador, generalmente en términos de HTML o XML. Sus funcionalidades y método de trabajo aportan características como: portabilidad, rendimiento, habilitación del concepto de sesión y software distribuido. Páginas Activas Esta tecnología está basada en la incrustación de código escrito en un lenguaje script dentro de las páginas Web, con el fin de que dicho código sea interpretado por el servidor Web y pasado a HTML antes de servir la página al cliente. Desde este código se accede, si es necesario, a los recursos externos que sean precisos (figura 7). Servidor Web Cliente Internet TCP/IP JP EG HTML JP EG HT+ Script Cliente ligero Navegador Web HTTP JPEG JP EG Pág. HTML Servidor W b JP EG HTML JP EG + Script script script Otros Recursos Externos Figura 7. Escenario de desarrollo para una página activa. Esta forma de desarrollar aplicaciones basadas en Web es de las más aceptadas actualmente ya que otorga un control entre la aplicación y el servidor. Además, habilita el concepto de sesión de usuario, es decir, podemos conocer el estado de la conexión de un usuario en un momento determinado. Asimismo, gestiona bien los recursos externos, como es el caso de accesos a bases de datos, y permite una gran flexibilidad de compartición de los mismos y de programación de la petición y respuesta Web. La mayoría de las operaciones se realizan en el servidor y hasta que no están totalmente gestionadas no se sirve la página resultante al cliente. Esto independiza en gran medida la aplicación Web del navegador que nos visite. El desarrollador deberá aprender el lenguaje script correspondiente, el cual es propietario del servidor Web que lo ha de interpretar. Los servidores Microsoft implementan esta tecnología con el nombre de ASP (Active Server Pages), basadas en Visual Basic Script, mientras que Netscape lo hace con un lenguaje llamado Livewire, basado en Javascript. Una tercera alternativa es JSP (Java Server Pages).

8 Representa una nueva tecnología de páginas activas cuyo lenguaje script es Java, por lo que ofrece todas las características que hacen de éste un lenguaje idóneo para la red [15]. Como ya se ha comentado, las páginas activas de Microsoft y Netscape son propietarias. La tecnología ASP está totalmente vinculada con el servidor Microsoft Internet Information Server [14] y Visual Basic Script y Livewire lo está con Netscape Enterprise Server y es un sucedáneo de Javascript propio. En este sentido, JSP representa la opción que más se ajusta al concepto de tecnologías abiertas y código libre por estar basada en Java estándar. Servidor de Aplicaciones Para centralizar todas las posibles tareas de índole dinámica que un servidor Web ha de realizar no suele ser una buena solución cargarle con todo el trabajo a base de parches o añadidos de diversa naturaleza. Un enfoque más ambicioso es colocar detrás de él un cerebro o motor: el servidor de aplicaciones [9,13]. contenidos estáticos Servidor Web Cliente J PEG Pág. J PEG HT HTML Servidor de Aplicaciones Navegador Web J PEG Pág. J PEG HTML HTTP Servidor Web Pág. HTML Servidor de aplicaciones Otros Recursos Externos contenidos dinámicos Lógica Negocio Figura 8. Relación entre un servidor Web y un servidor de aplicaciones. La filosofía general de funcionamiento es la siguiente: las peticiones que se hagan al servidor Web que deban generar contenido estático las despachará el propio servidor Web como de costumbre; pero las peticiones que deban generar contenido dinámico serán delegadas en el servidor de aplicaciones; éste interactuará con el recurso externo que sea necesario, ejecutará la lógica de negocio que se precise y le pasará la respuesta en formato HTML al servidor Web que, a su vez, la remitirá al cliente (figura 8). Tras la idea de servidor de aplicaciones se esconden todo un conjunto de servicios y tecnologías que hacen viable esta propuesta: estamos hablando del concepto de middleware [9] y, debido a su complejidad, merece un tratamiento especial.

9 Middleware El middleware se puede definir como el nivel lógico del sistema que proporciona una abstracción sobre la infraestructura que le da soporte a las aplicaciones, dotando de transparencia de ubicación e independencia de los detalles del hardware de los computadores, del sistema operativo, de la red de interconexión y de los protocolos de comunicaciones (figura 9) e, incluso, del lenguaje de programación utilizado para su desarrollo. Desde el punto de vista del programador de aplicaciones, el middleware establece un modelo de programación sobre bloques básicos arquitectónicos, utilizando protocolos basados en mensajes para proporcionar abstracciones de nivel superior. Servidor Web Cliente HTML Navegador Web Servidor Web Componentes Middleware Servidores de Aplicaciones Figura 9. Capa de middleware en el contexto de un sistema distribuido basado en componentes software. En cualquier caso el middleware se puede estudiar desde dos puntos de vista bien diferenciados: desde el punto de vista de la propia infraestructura que conforma el middleware y desde el punto de vista del diseñador de aplicaciones. Desde el punto de vista de la infraestructura viene definido por su arquitectura, en la que resaltan los siguientes elementos: El modelo de representación de datos, responsable de convertir las estructuras de datos internas de los componentes en secuencias de bytes, bien para su almacenamiento, bien para su transferencia a través de la red de comunicaciones. El modelo de comunicaciones, encargado de facilitar la comunicación entre componentes a través de una red de comunicaciones. Para desarrollar su labor se apoya en un modelo de representación de datos responsable de su serialización, en un protocolo de comunicaciones tipo petición/respuesta como

10 mecanismo de comunicación efectivo para sistemas distribuidos, y en un modelo de invocación de métodos remotos que permite el acceso a la funcionalidad del componente con el que se quiere establecer contacto. Un conjunto de servicios adicionales que proporcionan un equipamiento genérico que puede utilizarse en una gran variedad de aplicaciones. Estos servicios suelen incluir servicio de nombres, servicios de eventos y notificación, servicio de seguridad, y servicios de transacción y concurrencia. aplicaciones comp comp comp comp comp comp comp comp comp modelo de servicios abstractos middleware middleware middleware RMI protocolo solicitud-respuesta representación externa de datos SO SO SO HW HW HW plataforma de comunicaciones Figura 10. Modelo general de capas del sistema con middleware. Desde el punto de vista del diseñador de aplicaciones, el middleware representa un modelo de programación al que le incumbe definir nítidamente la estructura que deben tener los componentes a diseñar, así como los mecanismos que deben emplearse para acceder a los recursos y a los servicios que proporciona la plataforma [6]. Con respecto a la estructura de los componentes, el modelo define tres grandes elementos: El estado del componente, encargado de mantener las estructuras de datos que utiliza el componente y que definen su bagaje. El comportamiento, definido a través de una serie de métodos que implementan la lógica de aplicación o de negocio que encapsula el componente. La interfaz del componente, en la que deben especificarse los métodos y las propiedades que posee el componente y que están accesibles a otros componentes y objetos. Con respecto al mecanismo de acceso a los recursos de la plataforma, se debe tener en cuenta que, desde el punto de vista del programador o del componente la plataforma es un suministrador de servicios por lo que, con el objetivo de facilitar su acceso sobre todo con independencia de los lenguajes y herramientas de programación que se utilicen, uno de los métodos más habituales es proporcionar un API de los servicios disponibles en la plataforma.

11 Arquitectura middleware Desde el punto de vista de la propia infraestructura que conforma el middleware, éste viene definido por su arquitectura (figura 11), en la que resaltan los siguientes elementos: el modelo de representación de datos, el modelo de comunicaciones en el que se incluye el protocolo de comunicaciones y el modelo de invocación de métodos remotos y los servicios que proporciona la plataforma [16]. Aplicación Cliente Objeto Proxy Réplica auxiliar Interfaz Objeto Componente núcleo servicios middleware núcleo servicios middleware Protocolo comunicación Figura 11. Arquitectura middleware. Modelo de representación de datos Independientemente de la forma de comunicación utilizada, las estructuras de datos y atributos de los objetos deben ser convertidos en una secuencia de bytes antes de su transmisión y, posteriormente, reconstruidos en el destino. Para hacer posible que dos computadores puedan intercambiar información, éstos deben acordar previamente un esquema común o incluir la especificación del formato de emisión en el propio mensaje. Al estándar acordado para la representación de los valores y estructuras de datos a transmitir en los mensajes se le denomina representación externa de datos por ejemplo, CDR de CORBA [16]. Modelo de comunicación El protocolo petición-respuesta define el nivel adecuado para establecer una comunicación típica según la arquitectura cliente/servidor en sistemas distribuidos basados en UDP o TCP. El propio mensaje de respuesta se considera como un reconocimiento del mensaje de petición, evitando de este modo las sobrecargas de los mensajes de reconocimiento adicionales. Sobre esta capa de protocolo se construyen los modelos de comunicación de llamada a procedimiento remoto (RPC) [16] y el modelo de invocación a métodos remotos (RMI) [13]. RPC permite a programas cliente invocar procedimientos pertenecientes a programas servidor que generalmente se ejecutan en computadores distintos. Este modelo evoluciona, posteriormente, permitiendo que objetos de diferentes procesos se comuniquen con los métodos de otros objetos RMI.

12 Servicios Los principales servicios que proporciona el middleware a las capas superiores del sistema son el servicio de nombres, el de eventos y notificaciones y el de seguridad. Servicio de nombres Su objetivo es almacenar los atributos de los objetos en un sistema distribuido, devolviendo esos atributos cuando se realiza una búsqueda sobre cierto nombre de texto. Los principales requisitos que debe poseer son la habilidad para manejar un número arbitrario de nombres, persistencia, alta disponibilidad y tolerancia a fallos. Ejemplos de este servicio son el X.500, LDAP, Jini, etc. Servicio de eventos y notificaciones Este servicio extiende el modelo local de eventos al permitir que varios objetos en diferentes ubicaciones puedan ser notificados de los eventos que tienen lugar en un objeto. Emplean el paradigma del tablón de anuncios, en el que un objeto que genera eventos publica el tipo de eventos que ofrece para su observación. Los objetos que desean recibir notificaciones de un objeto se suscriben a los tipos de eventos que les interesan. Servicio de seguridad Los mecanismos de seguridad se basan esencialmente en la criptografía de clave pública y de clave secreta. Los recursos se protegen mediante mecanismos de control de acceso. Se pueden mantener los derechos de acceso en listas de control (ACL) asociadas a conjuntos de objetos. Ejemplos de este servicio son: el protocolo de autenticación Needham-Schroeder, Kerberos, SSL o Millicent. Modelo de Programación Desde el punto de vista del diseñador de aplicaciones, el middleware representa un modelo de programación al que le incumbe definir nítidamente la estructura que deben tener los componentes a diseñar, así como los mecanismos que deben emplearse para acceder a los recursos y a los servicios que proporciona la plataforma (figura 12). Estructura de un componente Un sistema orientado a objetos consta de un conjunto de componentes que interaccionan entre sí, cada uno de los cuales consiste en un conjunto de datos y un conjunto de métodos. Un objeto se comunica con otro objeto invocando sus métodos, generalmente pasándole argumentos y recibiendo resultados. Así, cada componente se puede estructurar en tres elementos: una interfaz, una lógica de aplicación o de negocio y un estado [6]. Interfaz La interfaz de un componente proporciona una definición de las signaturas de sus métodos los tipos de sus argumentos, valores devueltos, excepciones, etc. sin

13 especificar su implementación. Establece, asimismo, qué métodos y propiedades están accesibles para el resto de componentes y objetos. Por supuesto, nada impide que un mismo objeto implemente distintas interfaces a la vez. componente cliente Interfaz - métodos - propiedades Lógica Negocio Estado API de Servicios Middleware Figura 12. Estructura básica de un componente software y su relación con la plataforma. Cada componente se implementa de forma que oculta tanto su estado como su funcionalidad, excepto la que se hace disponible a través de su interfaz en términos de propiedades y métodos, respectivamente. Esto permite modificaciones en la implementación de la lógica del componente o de su estructura interna siempre que su interfaz se mantenga inalterada. Para que distintos componentes implementados por distintos equipos de desarrollo y, posiblemente, con diferentes lenguajes de programación puedan interactuar entre ellos es necesario que sus interfaces estén definidas de forma homogénea. Para facilitar esto, el modelo de programación introduce los lenguajes de definición de interfaces (IDL) que proporcionan una notación específica en la que, por ejemplo, los parámetros de un método se describen como de entrada o salida y utilizando su propia especificación de tipos. Estado El estado de un componente consta de los valores de sus variables de instancia. En el paradigma de la programación orientada a objetos, el estado de un programa se encuentra fraccionado en partes separadas, cada una de las cuales está asociada a un objeto. El estado de un objeto está accesible sólo para los métodos del objeto, es decir, que no es posible que métodos no autorizados actúen sobre su estado. Algunas implementaciones de middleware, como CORBA [16], permiten empaquetar y almacenar los objetos junto con su estado en un momento dado en los llamados almacenes de objetos persistentes, de forma que métodos de otros objetos puedan activarlos por invocación a través de su interfaz. En general se almacenan en cualquier momento en el que se encuentren en un estado consistente, con lo que dotan al sistema de tolerancia a fallos. Comportamiento El comportamiento define la funcionalidad del componente a través de una serie de métodos que recogen la lógica de aplicación o de negocio que encapsula y a la cual se

14 accede, en caso de estar disponible para otros componentes, a través de las interfaces definidas. Acceso a los servicios Un middleware debe proporcionar un mecanismo que permita a los componentes acceder a sus servicios. El método más habitual es el de proporcionar un API que facilite el acceso, sobre todo, con independencia de los lenguajes y herramientas de programación que se utilicen earchitecture Los sistemas cliente-servidor convencionales resultan muy dependientes tanto del hardware como del software utilizado y precisan de un conocimiento mutuo de las partes dirección del servidor, plug-ins instalados en el cliente, formatos empleados. Esta forma de proceder va en contra de la filosofía abierta de Internet. Un sistema complejo de gestión de redes puede proporcionar mayores oportunidades para automatizar y conseguir eficiencia en nuestra organización [7]. Para ello se debe ampliar el concepto de modelo cliente-servidor hacia un enfoque que aproveche plenamente el verdadero potencial de Internet y las tecnologías que soporta, considerando estándares y redes abiertas, y pensando en términos de arquitecturas cliente-servidor ligeras y aplicaciones basadas en componentes software distribuidos [13]. Dentro de este contexto, si una arquitectura define, a su vez, todo un conjunto de subarquitecturas y modelos, en este artículo, por motivos de espacio, nos centraremos fundamentalmente en cómo definir la arquitectura técnica de nuestra aplicación. Arquitectura técnica La arquitectura técnica describe la estructura de la aplicación y está compuesta por un modelo conceptual que define las diferentes capas funcionales y niveles de distribución de la aplicación, y por las infraestructuras empleadas para su desarrollo: marcos, modelos y patrones. Modelo conceptual El modelo conceptual de una aplicación está compuesto por las capas funcionales, responsables de cada tipo de componente y su ubicación en la capa arquitectural, y los diferentes niveles de distribución que indican cómo se sitúa cada tipo de componente en un sistema distribuido (figura 13) [6].

15 Nivel Usuario Nivel Espacio de trabajo Nivel Empresa Nivel Recursos Capa Aplicaciones User Fuentes Externas Presentación Controlador de Vista Controlador B2B Coordinador Trabajo Perfil Usuario Controlador Actividad Controlador Proceso Componente Entidad Adaptador Aplicación Adaptador Recursos Sistemas Heredados Aplicaciones Empaquetadas Capa Servicios middleware Servicio Autorización Servicios Configuración Servicio Perfiles Servicio Entrada Servicio Flujo Trabajo Servicios Gestión Servicio Reglas Otros Servicios Servicio Persistencia Datos Persistentes Figura 13. El diagrama muestra las distintas capas funcionales tanto de servicio como de aplicación del modelo conceptual que define junto con la infraestructura de desarrollo: marcos, servicios y patrones una arquitectura técnica. Al mismo tiempo, el diagrama recoge los diferentes niveles lógicos en los que se ha dividido dicho modelo conceptual y en el que se han ubicado las diferentes capas funcionales de la aplicación. Podemos resumir los objetivos fundamentales del modelo conceptual en los siguientes puntos: Distribución. Cada capa funcional puede estar ubicada en un nivel distinto. Escalabilidad. La aplicación de los recursos puede realizarse de manera independiente sobre la capa funcional que los precise. Al mismo tiempo, se facilita el balanceo de carga al poder ubicar cada capa en un espacio físico diferente o, incluso, ser replicadas en caso de necesidad. Separación del desarrollo de la aplicación con respecto a las infraestructuras empleadas en su desarrollo. Independencia de la tecnología sobre la que finalmente se implante la aplicación. Independencia del dispositivo utilizado por los clientes para acceder al sistema, gracias a los adaptadores de recursos y controladores de vistas. Integración de aplicaciones. Facilita y sistematiza la integración con aplicaciones y sistemas heredados a través de los adaptadores de aplicaciones. Mejoras y migración. Ante necesidades de actualización o modificación de la aplicación, el impacto que un determinado cambio tenga sobre el resto del sistema es mínimo gracias a su división en capas funcionales. Este mismo esquema será útil para facilitar la migración progresiva del sistema existente a la nueva aplicación. Cada capa funcional puede reemplazarse o dividirse en grano fino y con poco impacto sobre el resto.

16 Capas funcionales Las capas funcionales se pueden dividir, básicamente, en la capa de servicios y la capa de aplicación. La capa de servicios define los componentes del sistema que se consideran básicos, proporcionan servicios a las capas superiores y, en general, estarán disponibles en cualquier nivel lógico y físico en el que se divida la aplicación. Esta capa de servios está plenamente ligada al concepto de middleware abordado en el apartado anterior. En la capa de aplicación es en la que se definen los diferentes componentes desarrollados para la aplicación y que serán particulares para la misma. En nuestro caso, estos componentes pueden ser módulos software, aplicaciones específicas, componentes software distribuidos o clientes ligeros como un navegador web. Niveles de distribución Los niveles de distribución indican cómo se sitúa cada componente dentro de la capa arquitectural. Se diferencia entre niveles de distribución lógico y físico. Los niveles de distribución lógicos indican cómo debe dividirse la aplicación para facilitar la consecución de los objetivos de distribución, escalabilidad y separación antes analizados. Sin embargo, para dicha división no se tendrá en cuenta la ubicación física final de cada componente. A continuación se analizará con más detalle los diferentes niveles lógicos propuestos y que en nuestro caso supone un modelo de n-niveles: Nivel de usuario. Es el nivel en el que se ubica la parte cliente de la aplicación. Está compuesto por el nivel de presentación y por el controlador de vista. La presentación constituye básicamente la aplicación que se proporciona al usuario para interactuar con el sistema. El consejo es intentar que sea lo más ligera e independiente del sistema posible. En cualquier caso, siempre queda la discusión sobre la idoneidad de qué aspectos deben estar embebidos en la misma: funciones muy específicas, validación de datos, etc. El controlador de vista es el encargado de dar soporte a la presentación e independizar al máximo la entrada y salida del sistema del dispositivo y tipo de aplicación cliente con la que ésta se realice. Así, para una presentación que utilice HTML, el controlador puede ser un servlet; en caso de tratarse de una aplicación escrita en Microsoft Visual Basic, estaría generado automáticamente como parte del VB Runtime; si se emplea un teléfono, el controlador sería un simulador de voz para la salida junto con un reconocedor de voz y tecnologías de entrada por teclado para la recogida de información. Nivel de espacio de trabajo. En este nivel se realizan todas las adaptaciones entre el cliente y el servicio; se gestiona la personalización (nivel perfiles de usuario); se recoge toda la información necesaria para un proceso a través de múltiples presentaciones (por ejemplo, un EJB de sesión enlazado con un objeto sesión HTTP). Como caso especial, se contempla la posibilidad de que el usuario que accede al sistema sea, a su vez, otro sistema. En este caso estaríamos hablando de un modelo B2B (frente al modelo B2C tratado hasta el momento) en el que se puede prescindir de mucho del protocolo necesario para tratar con un usuario humano. Representa, por lo tanto, un punto de

17 entrada diferente, mucho más sistematizable y que estará más basado en la comunicación entre procesos a través de estándares como XML. Nivel de empresa. Constituye el núcleo central de la aplicación o servicio. Será en este nivel en el que se recojan las reglas de negocio que rijan la aplicación. Para su desarrollo se ha establecido tres componentes: controlador de actividad, controlador de procesos y reglas de negocio. El controlador de actividad regula el flujo de trabajo, presentando al usuario los procesos de negocio como casos de uso, es decir, como una secuencia de unidades de trabajo, también denominadas funciones de negocio. El controlador de procesos es el encargado de ejecutar un determinado proceso de negocio. Las reglas de negocio constituyen el motor de reglas, por ejemplo: validar información, protocolos de gestión, etc. Nivel de recursos. En este nivel se ubica todo aquello que supone información para nuestra aplicación: aplicaciones heredadas (sistemas ya existentes) o empaquetadas (paquetes ofimáticos o programas de contabilidad) y sistemas de información (bases de datos). Para conseguir la máxima independencia con los recursos se establecen diferentes adaptadores: de aplicaciones y de recursos. Los adaptadores de aplicaciones son componente interfaz con aplicaciones heredadas, mientras que los adaptadores de recursos realizan una traducción de datos existentes a formato utilizado por las entidades de negocio, gestionando la distribución (relación) de los datos (en diferentes aplicaciones, bases de datos, ubicaciones, etc.). Por otra parte, los niveles de distribución físicos indican cuál será la ubicación física de los diferentes componentes definidos por los niveles lógicos. En primer lugar se introduce el concepto de contenedor [2,6]. Un equipo físico puede albergar uno o más contenedores (un contenedor sólo podrá estar en un determinado equipo). Cada contenedor proporciona los servicios (capa middleware) y el entorno de ejecución adecuado para los diferentes componentes que se desplegarán en él. En principio, cada contenedor proporciona todos los servicios, sin embargo, en la práctica, podremos decidir proporcionar tan solo aquellos servicios que precisen los componentes a los cuales darán soporte. En cualquier caso, esto es sólo un problema de optimización de recursos. Una vez establecidos los contenedores adecuados para el despliegue de nuestra aplicación, resultará relativamente sencillo alcanzar los objetivos de distribución, escalabilidad, separación, etc., definidos anteriormente. Por ejemplo, si una vez desplegada nuestra aplicación nos encontramos con que el número de usuarios que acceden a la misma pasa, de los cientos para los que estaba prevista, a los millares, se puede duplicar los contenedores y servidores que los albergan y que estaban encargados de atender las solicitudes de los clientes. Otro ejemplo típico es el de modificaciones en la compañía bien por cambios organizativos internos, bien fruto de absorciones o remodelaciones, de forma que se podrá estudiar cuáles son los nuevos protocolos, casos de uso, reglas de negocio, etc., y actuar sobre los elementos afectados con el menor impacto posible sobre el resto del sistema. Infraestructuras de desarrollo La aplicación de las técnicas, modelos y arquitecturas propuestos supone un cambio de escala radical en el desarrollo de las aplicaciones de gestión. Esto hace que

18 la arquitectura técnica no pueda considerarse completa si no se complementa con aquellos elementos que facilitan su implementación así como la sistematización del proceso. Estos elementos se pueden clasificar en tres grandes apartados: marcos, servicios y patrones. Los marcos hacen referencia a entornos de desarrollo que proporcionen soluciones genéricas configurables (por ejemplo los entornos IDE) y que abarquen todas las fases del desarrollo de la aplicación y todos los niveles funcionales en los que esta se divida. Los servicios representas la infraestructura que permite a las aplicaciones utilizar funciones comunes (seguridad, comunicaciones, acceso a bases de datos, gráficas, etc.) sin que el desarrollador tenga que preocuparse de su implementación, mantenimiento o portabilidad. Los patrones pueden considerarse como plantillas que orientan sobre cómo resolver determinados problemas que aparecen de forma recurrente en el desarrollo de aplicaciones [10]. En la literatura se pueden encontrar patrones de diseño, patrones de integración, patrones de implantación, etc. Plataforma J2EE para soluciones empresariales Hoy en día el desarrollo de aplicaciones conlleva una mayor complejidad, debida principalmente a dos factores estrechamente relacionados. Por un lado, la aparición de requerimientos tecnológicos derivados de los nuevos modelos arquitectónicos comentados. Por otro lado, el número de características que una organización espera y exige que cumplan sus aplicaciones [6,2]. Entre las características y requerimientos necesarios encontramos. Productividad. Es un factor importante para las organizaciones. Las organizaciones cada día solicitan que el desarrollo y la implantación de las aplicaciones sean realizados en el menor tiempo posible y que el tiempo de vida de dichas aplicaciones sea cada vez mayor. Integración. Otro factor deseado es la capacidad de integración de las nuevas aplicaciones con sistemas heredados de la organización, que por su alto coste económico de realización (ERP) o por la importancia de la información almacenada a lo largo del tiempo no pueden ser desechados. Flexibilidad. Las aplicaciones deben adaptarse a los cambios derivados de los avances tecnológicos, sin tener que rediseñar la aplicación. Escalabilidad. Las aplicaciones deben ser capaces de adaptarse ante un crecimiento masivo de usuarios que acceden concurrentemente a dicha aplicación de una manera sencilla o evitar que dicho crecimiento afecte al rendimiento global de la aplicación. Seguridad. La información que mantienen las empresas es muy valiosa y si tenemos en cuenta que dicha información va a circular por entornos poco fiables y proclives a recibir ataques es necesaria la utilización de potentes mecanismos de seguridad en las aplicaciones. Por todas las razones mencionadas aparecen una serie de modelos de desarrollo basados en componentes que aprovechan sofisticadas plataformas de servicios,

19 haciendo que el desarrollo de todas estas aplicaciones sea posible. Si en cada aplicación hubiera que desarrollar estos servicios, necesarios por los requerimientos indicados, la realización de los proyectos no sería factible. Las dos plataformas más importantes en el mercado y con mayores cuotas de usuarios son J2EE y.net. Ambas plataformas satisfacen las necesidades requeridas anteriormente y nos ofrecen servicios equivalentes [13,14]. En la siguiente tabla podemos observar como para cada tecnología ofrecida por una plataforma, existe la equivalente en la otra. Tabla 1. Comparativa de la tecnología J2EE y.net J2EE.NET Componentes EJB.NET Component Mensajería JMS MSMQ Transacciones JTA MTS Acceso distribuido RMI RMI-IIOP.NET Remoting Conectores JCA Host Integration Server Biztalk Server Registro de componentes JNDI Active Directory Bases de datos JDBC ADO.NET Servicios web JAX-RPC.NET Framework Manejo XML JAXP MSXML Sin la existencia de estas plataformas no podríamos adaptarnos de una manera eficiente a los continuos cambios tecnológicos y afectaría directamente a los requerimientos especificados por las organizaciones [11] (productividad, flexibilidad, escalabilidad y seguridad entre otros). Hemos visto que.net y J2EE nos ofrecen soluciones equivalentes. A pesar de esto, no podemos comparar.net con J2EE. La filosofía de ambas es completamente diferente. Mientras que.net es una implementación propietaria de Microsoft como solución a la demanda de las organizaciones, J2EE está formada por un conjunto de especificaciones propuesta por grandes empresas y encabezadas por SUN. Estas especificaciones indican que requerimientos debe cumplir una plataforma J2EE para denominarse como tal. Podríamos comparar.net con una implementación J2EE de un proveedor específico. Esa es una de las ventajas que nos han llevado a optar por J2EE. Se trata de un estándar implementado por varios proveedores (sun, ibm, bea, oracle...) compatibles entre ellos. Esto nos proporciona un amplio abanico donde elegir y no restringirnos a un único proveedor [2]. Por otro lado aunque.net a nivel empresarial pueda ser más apetecible puesto que requiere, a lo mejor, de una menor curva de aprendizaje, J2EE es preferible a nivel universitario puesto que al ser más abierto puede derivar en temas de investigación interesantes para nuestra comunidad. Por último en el momento de tomar la decisión se tuvo en cuenta el tema de las licencias y el coste y puesto que en ese momento, en el cual se debía comenzar a trabajar, J2EE

20 nos ofrecía soluciones empresariales de código abierto se optó por esta solución. En los siguientes puntos veremos más a fondo la plataforma J2EE. Perspectiva general de J2EE La plataforma J2EE conforma un conjunto de especificaciones que nos proveen de servicios y componentes en todos los niveles de una arquitectura de n niveles. Existen componentes y servicios para la creación de aplicaciones clientes y para desarrollar grandes aplicaciones distribuidas de servidor. Estamos pues ante una plataforma de n niveles, donde los distintos módulos de la aplicación pueden correr en diferentes dispositivos. J2EE nos define el número de niveles de los que se compone la plataforma, pudiendo estos a su vez desdoblarse, y qué componentes debemos utilizar en cada nivel con los servicios proporcionados en dichos niveles [2]. Podemos observar que se trata de una plataforma de varios niveles. Vamos a realizar una enumeración de las principales características de J2EE [2]. Gestión de componentes basada en contenedores El contenedor es el elemento principal de la plataforma J2EE. Estos son entornos estándar de ejecución que proveen de servicios específicos a los componentes. Los contenedores nos ofrecen mecanismos que nos permiten modificar el comportamiento de los componentes con simples ficheros XML de configuración en el momento de despliegue de la aplicación. Además este despliegue se realizará en caliente, sin la necesidad de parar la aplicación [2]. J2EE nos define el número de contenedores que una implementación J2EE debería soportar pero no especifica como el proveedor deberá implementar la configuración de los componentes [2]. Por ello si cambiamos de proveedor J2EE deberemos aprender como funciona la configuración del nuevo proveedor.