Entornos para el desarrollo de grandes aplicaciones de gestión de redes

Transcripción

1 Entornos para el desarrollo de grandes aplicaciones de gestión de redes Virgilio Gilart Iglesias 1 y Alfonso Capella D alton 1 1 Departamento de Tecnología Informática y Computación, Universidad de Alicante AP. 99, 03080, Alicante, España {vgilart, acapella}@dtic.ua.es Resumen. Como consecuencia de la globalización de la economía y la evolución de los sistemas logísticos y de telecomunicaciones, han surgido nuevos modelos de negocio para los que las arquitecturas tradicionales no ofrecen una solución adecuada. La apertura de mercados a nivel mundial y la dispersión de las propias empresas precisan de arquitecturas de aplicación distribuidas, segmentadas en múltiples niveles y con amplias capacidades de interconexión e interoperabilidad. En este contexto, surgen plataformas empresariales, como J2EE y.net, que satisfacen los requerimientos de los nuevos modelos de negocio emergentes. Dichas plataformas introducen una complejidad tecnológica que hace necesaria la adopción de un entorno de trabajo, metodológico y sistemático, sostenido por una infraestructura adecuada. En este artículo proponemos un modelo de trabajo junto con las tecnologías y herramientas más adecuadas que dé soporte a la creación y mantenimiento de grandes aplicaciones y servicios capaces de cubrir estas necesidades al tiempo que aprovechan el verdadero potencial que ofrece Internet. Introducción Internet se ha convertido en un medio que ha cambiado la forma de comprender los negocios empresariales [1]. Las organizaciones encuentran en este entorno nuevos modelos de competencia relaciones entre empresas, formas de captar clientes e introducción en nuevos mercados que, por su elevado coste, estaban reservados únicamente a las grandes corporaciones. Todas estas transformaciones llevan asociadas la aparición de nuevos requerimientos, no contemplados por los modelos de software tradicionales, y que, por lo tanto, obligan a adoptar nuevas estrategias para adaptar los procesos de negocio y sistemas software reingeniería de procesos. Para la mayoría de las organizaciones la resistencia a los cambios suele ser elevada e incluso a veces traumática [1]. Esto se debe principalmente al esfuerzo que requiere abandonar la cultura empresarial creada, a la complejidad de integración de los sistemas heredados que contienen información de vital importancia para la organización, a la modificación de las infraestructuras establecidas y a la creación de procesos de aprendizaje y formación de sus empleados. Sin embargo, a pesar de estas

2 dificultades, la aparición de nuevas empresas que se adaptan con rapidez a estas tecnologías fuerza al resto a evolucionar hacia estos entornos [1]. Las arquitecturas tradicionales no proporcionan una solución global a las necesidades planteadas por los nuevos modelos de negocio puesto que muchos de los requerimientos que plantean no formaban parte de su diseño: estándares que faciliten la integración entre aplicaciones y diferentes dispositivos [3,4], escalabilidad que permita que las aplicaciones crezcan a la vez que crece el negocio [2,4], flexibilidad frente a las nuevas tecnologías y sistemas de computación ubicua [3,4], seguridad en entornos no fiables y proclives a ataques [7], portabilidad a diferentes sistemas [4]. Para llenar este hueco aparece una nueva generación de plataformas software basadas en componentes sobre arquitecturas distribuidas (n-niveles), que ofrecen una solución completa que permite abordar los nuevos modelos de negocio y que aprovechan el entorno tecnológico que propone Internet [1]. Ante los nuevos modelos de desarrollo y enfoques empresariales surge la necesidad de reemplazar muchas de las prácticas de gestión de proyectos convencionales y requerimientos técnicos por nuevos enfoques. Éstos deben combinar técnicas de éxito, procedentes de experiencias anteriores, con avances tecnológicos en la ingeniería del software [5]. Al igual que las aplicaciones creadas para los nuevos modelos empresariales, las infraestructuras sobre las que se sustenta el desarrollo de dichas aplicaciones deben ser flexibles y escalables para adaptarse a los cambios derivados de los nuevos modelos. Las nuevas plataformas de desarrollo software establecen una serie de roles y filosofías de trabajo derivadas de su arquitectura de n-niveles que permiten la realización de proyectos de manera horizontal [6]. Cada rol tiene un cometido específico que en ciertas etapas del ciclo de vida del software podrán desempeñar de forma paralela mientras que, en otras, deberán hacerlo en cascada. El trabajo en grupo para este tipo de modelos resulta imprescindible y la sincronización de las tareas específicas de cada rol, determinante [4]. En este artículo se propone un marco de trabajo que dé cobertura a la creación y mantenimiento de aplicaciones para los nuevos modelos empresariales basados en componentes distribuidos. Modelo de Entornos Hemos definido el entorno de trabajo para el desarrollo de un producto software como el conjunto de circunstancias y estados en los que se puede encontrar dicho producto a lo largo de su ciclo de vida. Tras este análisis, basado en la experiencia de los componentes del Grupo de Redes perteneciente a la unidad singular de investigación redes de computadores e informática industrial del Departamento de Tecnología y Computación de la Universidad de Alicante, hemos definido un modelo del entorno de trabajo que nos proporciona una serie de elementos lógicos, relacionados con el estado del software en un determinado momento y asociado a un conjunto de funciones y roles, con el que abordar los proyectos realizados con las plataformas empresariales mencionadas anteriormente.

3 Figura 1. Modelo de entonos. En la figura 1 se muestra los elementos que componen el modelo y la interacción que existe entre ellos. A continuación se explica cada elemento y sus principales funciones dentro del marco propuesto. El repositorio software El elemento, posiblemente, más importante de nuestro modelo es el Repositorio Software. Podemos definir un repositorio como un almacén, común a un grupo de trabajo, de elementos software necesario para el desarrollo de aplicaciones y la gestión de proyectos. El repositorio software se compone de dos partes bien diferenciadas. - Herramienta de control de versiones - Servidor de archivos distribuidos Con la herramienta de control de versiones tenemos ciertas ventajas para desarrollar aplicaciones: - Control de versiones del software - Facilita el trabajo en grupo - Comparación entre versiones - Facilita los desarrollos de versiones en paralelo Con el servidor de archivo conseguimos tener centralizados todos los documentos de especial interés para el desarrollo de aplicaciones y nos facilita la localización del software necesario para el desarrollo. La justificación principal de estos dos elementos se basa en el grado de cambio que tendrán los archivos almacenados en ambos y que se define a continuación.

4 Repositorio Software Servicio de control de versiones Sistema de archivos distribuidos Figura 2. Elementos del Repositorio Software. Sistema de archivos distribuido El sistema de archivos distribuido nos proporciona la infraestructura necesaria para el almacenamiento de documentos tecnológicos y software que no van a sufrir modificaciones por parte del grupo de trabajo. La documentación almacenada está relacionada con la tecnología que se ha ido utilizando en el desarrollo de proyectos. Existen periodos de autoformación en los cuales se debe buscar información de interes en la red Internet. En este proceso se debería considerar si la información encontrada puede ser de utilidad para el grupo y para uno mismo. Es una forma de tenerla localizada y compartirla con el resto del equipo. Por otra parte se encuentran las aplicaciones software utilizadas dentro del grupo y de los entornos de trabajo. Utilizar un sistema de archivos distribuidos permite una fácil localización de las herramientas con los cuales se debe trabajar y por lo tanto una mejora de la productividad. Con esta filosofía se pretende evitar los costes de tiempo que supone: la descarga de software de terceros por múltiples usuarios, pérdida de documentación de interés, perdida de software almacenados en diversos dispositivos Control de versiones Por otra parte existe una serie de archivos código fuente, documentación, políticas de trabajo que son susceptibles de a ser modificadas en algún momento. Normalmente estos archivos han sido generados por el equipo y por lo tanto pueden evolucionar y ser mejorados. Estos archivos deben ser compartidos por el conjunto del grupo en función del rol al que pertenezcan. Para ello existen una serie de herramientas de control de versiones imprescindibles a la hora de montar cualquier entorno de desarrollo de medio o alto nivel. En el desarrollo de aplicaciones las herramientas de control de versiones son de gran utilidad para conocer el estado del código fuente en cada momento, proporcionándonos las siguientes ventajas: centralización del código fuente y documentación relacionada con los proyectos, controlar la versión o estado del software que se está desarrollando, regresar a versiones anteriores en caso de errores, facilitar el trabajo en paralelo entre diferentes versiones, control completo de la evolución del software, proporcionar mecanismos

5 para la automatización de tareas de paso de entornos políticas de etiquetado, facilitar el conocimiento del autor de cada versión y las modificaciones realizadas. Los entornos Podemos definir un entorno, dentro de nuestro marco de trabajo, como la infraestructura necesaria para acometer las tareas específicas requeridas por el producto software, en función del estado en el que se encuentra. En nuestro modelo un producto software sufre una evolución de manera que, en un momento dado, puede encontrase en uno de los siguientes estados: - Desarrollo - Estabilidad - Integración - Demostración - Preproducción - Producción + Estabilidad Cada estado define un nivel de estabilidad del software, y la secuencia de estados representa la evolución del producto software desde su fase más temprana toma de requerimientos hasta su puesta en funcionamiento deployment o despliegue en producción. Figura 3. Evolución del producto a través de los distintos entornos del modelo. Estos cinco estados nos definirán los entornos de trabajo que vamos a describir para el desarrollo de nuestras aplicaciones, y cada entorno se centrará en un subconjunto específico de las tareas de creación y mantenimiento de la aplicación.

6 El entorno de desarrollo. El entorno de desarrollo conlleva el abanico más amplio de tareas, que abarca desde el comienzo del ciclo de vida del software toma de requerimientos hasta la obtención de una versión minimamente estable de la aplicación, o de un subconjunto de la misma módulos. En este entorno se llevan acabo las siguientes tareas: Toma de requerimientos: Una vez hemos concretado las necesidades del cliente y hemos establecido varias reuniones con este fin, es aconsejable documentarlo, de manera que todo el equipo pueda tener una visión global del proyecto requerimientos funcionales. Este documento se podrá ir completando en posteriores entrevistas puesto que nunca quedan resueltas desde un principio las necesidades funcionales del sistema. En esta fase suele ser necesario usar herramientas de documentación y toma de requerimientos. Análisis de arquitectura y Diseño técnico: Estas son dos de las tareas más importantes del desarrollo software y que pueden determinar el éxito o fracaso de un proyecto. Se deben realizar las siguientes funciones: acuerdo inequívoco de los requerimientos especificados, elección de la tecnología que pueda abarcar las necesidades del proyecto con una adecuada arquitectura y el diseño de los componentes, localización de las fases más criticas, aportando soluciones de contención ante posibles problemas que pudieran aparecer. Además necesitaremos una serie de herramientas que nos permitan realizar estas funciones de forma productiva. Implementación: Indica el comienzo de la implementación con la tecnología adecuada elegida en la fase de análisis. Si se ha realizado un buen análisis y modelado técnico se reduce considerablemente la complejidad de la implementación. Pruebas de unidad y módulos: Estas pruebas se deben realizar sobre los módulos y componentes que cada desarrollador vaya finalizando. Se realizan en un entorno local para comprobar su correcto funcionamiento y poder integrarlas para obtener el producto final. De las anteriores tareas podemos deducir las necesidades tanto software como hardware del entorno de desarrollo, teniendo en cuenta la política de trabajo en equipo que decidamos seguir. Desarrollo en paralelo Los nuevos modelos de desarrollo producen un entorno idóneo para el trabajo en grupo. La división en roles dentro de estos modelos permite que se trabaje a dos niveles: en cascada con roles de diferentes niveles arquitectos, diseñadores técnicos, desarrolladores, equipo de calidad ; en paralelo dentro del mismo ámbito de funciones diseñadores de interfaces, programadores de lógica.

7 Se debe distribuir el proceso, responsabilizándose cada uno de un subconjunto de la de módulos de la aplicación. De esta manera, se puede lograr un paralelismo temporal en el desarrollo cada grupo trabaja sus módulos en paralelo, de forma simultánea, que minimice el tiempo de desarrollo, siempre que existan suficientes recursos humanos y tecnológicos. Las dependencias entre módulos pueden reducir el paralelismo temporal en la medida en que un grupo debe esperar a que se completen otros módulos para finalizar las tareas. Un buen diseño que minimiza las dependencias entre módulos y una buena planificación temporal que configura el orden y prioridades óptimos para el desarrollo evitarán en gran medida estos tiempos muertos. Política de trabajo El desarrollo de aplicaciones empresarial es, como ya hemos mencionado, complejo y requiere de un elevado número de servicios y sistemas heredados para su realización. En función de cómo distribuyamos los servicios necesarios para el desarrollo y las pruebas podemos encontrarnos diferentes problemáticas. Servicios compartidos En este esquema de trabajo, los distintos equipos de desarrollo comparten los recursos y servicios necesarios para desarrollar las aplicaciones bases de datos, servicios de directorios, servidores Web y de aplicaciones. De esta forma, en los equipos locales, únicamente tendremos las herramientas necesarias orientadas al desarrollo y no a las pruebas mejoramos el rendimiento local. En el mundo real surge un problema con este enfoque. Cuando existen varios desarrolladores que quieren realizar las pruebas básicas de sus módulos pueden realizar cambios sobre los datos o las configuraciones de los servicios compartidos o sobrescribir versiones y generar problemas colaterales que no existían y que pueden disminuir la productividad temporal del proyecto. Servicios en el entorno local Cada miembro del equipo de desarrollo tiene localizado en su equipo local las herramientas y servicios necesarios para desarrollar y realizar las pruebas sobre los módulos. El problema que puede surgir con este enfoque es de rendimiento debido a la saturación. En función de la tecnología utilizada y del equipo disponible podemos tener una perdida de rendimiento que se traduzca en una disminución de la productividad. Enfoque mixto Es una solución de compromiso entre las políticas mencionadas anteriormente en función criterios asociados al recurso o servicio que se quiere utilizar: Estimación de la probabilidad de interferencias. Cuanto menor sea, mejor se adaptará el recurso al enfoque centralizado. Coste económico del recurso. Cuanto menor sea, más factible es que se instale en el entorno local.

8 Coste temporal de la instalación/configuración del recurso. A medida que aumenta el tiempo necesario para instalar y configurar el servicio o la aplicación y aumenta el número de equipos locales el coste temporal se multiplica. En este caso es propicio optar por un enfoque centralizado. El entorno de integración En el entorno de integración se lleva a cabo las siguientes tareas: Integración de los distintos módulos que componen la aplicación Pruebas de integración En el proceso de integración tiene especial importancia el sistema de control de versiones. Debemos obtener los fuentes etiquetados con la versión estable que deseamos integrar. Cuando los fuentes son obtenidos se compilan y se genera la aplicación con todos los módulos integrados. Llegados a este punto, debemos poner en funcionamiento la aplicación para someterla a las pruebas de integración. Desplegamos la aplicación basándonos en los documentos generados durante el proyecto. Una vez integrada y activada la aplicación, llevaremos a cabo la secuencia de pruebas. El objetivo de estas pruebas es comprobar el funcionamiento de la aplicación como un todo. En ellas, se trata de probar las funcionalidades que debe cumplir el producto, aunque también debe ser probadas las anteriores funcionalidades para evitar que los cambios introducidos alteren inadvertidamente el comportamiento de las mismas. Si la aplicación satisface las pruebas de integración, entonces está lista para su paso al entorno de preproducción para realizar las pruebas de calidad y al entorno de demostración para permitir el acceso al cliente. En el caso en el que se produzca un error en estas pruebas debemos generar una incidencia se debe crear una política de gestión de incidencias y emitirla al encargado del módulo en el cual se produjo. El entorno de preproducción En el entorno de preproducción se lleva a cabo las pruebas finales de la aplicación antes de su paso final al entorno de producción, donde se pondrá en funcionamiento en un escenario real. Para ello, en primer lugar se transfiere la aplicación una vez ha sido validada en el entorno de integración a ser posible de una forma automatizada. El equipo de calidad, someterá la aplicación a un conjunto exhaustivo de pruebas, de diversos tipos: Funcionales y estructurales De rendimiento De tolerancia a fallos De seguridad Si estas pruebas, conocidas como de aceptación, resultan satisfactorias, entonces la aplicación está ya lista para su paso al entorno de producción.

9 Si alguna de las pruebas falla debemos seguir el protocolo creado para la gestión de incidencias. El entorno de producción El entorno de producción contiene en todo momento la versión activa de la aplicación. Los usuarios finales tienen acceso a la aplicación implantada en este entorno, de modo que resulta indispensable planificar y adoptar las medidas de seguridad oportunas, en consonancia con la importancia de la información que maneja el sistema. Por otra parte, este entorno también contiene los datos reales, información que es preciso salvaguardar frente a posibles pérdidas mediante la aplicación sistemática de una política de copias de seguridad. También debemos proteger los datos frente a exposición o usos fraudulentos de los mismos, restringiendo su acceso exclusivamente al personal de confianza que administra el sistema. La aplicación se despliega en el entorno de producción procedente de la versión existente en el entorno de preproducción. La subida debería producirse de forma automática para evitar, en la medida de lo posible, la introducción de errores. El entorno de demostración Este entorno tiene dos funciones: posibilitar al cliente el acceso a la aplicación que se está desarrollando y mostrar los productos existentes con el fin de atraer a posibles clientes. La aplicación se transferirá desde el entorno de integración con un proceso similar a la subida a preproducción. Pasos entre entornos Este proceso es uno de los puntos más importantes en el ciclo de vida del software. Debe contar con una serie de procedimientos y protocolos que se cumplan siempre que se produzca un cambio de entorno. Es un proceso crítico que se debe ser mejorado con la experiencia. Vamos a dividir los pasos de entornos en tareas más pequeñas para describir todo el proceso. Desarrollo a Integración Este es el proceso menos crítico de los que se deben llevar a cabo. En este paso participan los siguientes elementos: Desarrolladores Documentos de despliegue Sistemas de control de versiones Responsable del paso de entorno.

10 Los desarrolladores son los responsables de subir los módulos al sistema de control de versiones y etiquetarlos correctamente conforme a las políticas que se hayan definido. Los documentos de despliegue son muy necesarios puesto que ayudan a tener un control de qué archivos han sido modificados en la versión del proyecto. Si bien puede parecer redundante, puesto que si se ha etiquetado correctamente se tendría localizado, es una buena solución como medida de seguridad que nos evite tener imprevistos. El sistema de control de versiones es necesario puesto que el entorno de integración obtendrá de ahí los archivos que hayan sido modificados. Tener un responsable para esta tarea se hace indispensable para canalizar, a través de una única persona, el proceso de obtención de los archivos modificados. Este rol debe ser asumido por uno de los componentes del proyecto. El proceso es sencillo y consta de los siguientes pasos: Los desarrolladores deben subir sus módulos correspondientes al sistema de control de versiones. Estos deben ser etiquetados siguiendo la política de etiquetado de la organización. Una vez que se hayan subido todos los módulos el responsable de la integración deberá obtener dichos archivos, seleccionándolos por la etiqueta correspondiente, y actualizarlos en el entorno de integración. Una vez actualizados los archivos en el entorno de integración se procederá a compilar el proyecto y a instalarlo, siguiendo el documento de despliegue. Integración a Preproducción Una vez que el proyecto ha sido validado mediante las pruebas de integración, se etiqueta el proyecto para pasarlo a preproducción. En este paso no se utilizará el sistema de control de versiones. El contenido del entorno de integración se subirá a preproducción. Al igual que en el caso anterior habrá un responsable encargado de desplegar el proyecto en el entorno de preproducción utilizando el documento de despliegue. Dicho documento indica que módulos se deben subir y cual es la localización correspondiente a cada módulo. Preproducción a Producción Este paso es el más crítico de todos. La tarea a realizar es idéntica al paso anterior. Si ha habido algún problema de subida de entorno por ejemplo, olvidarse subir archivos debe producirse en el entorno anterior y se debe quedar resuelto antes de llegar a este punto.

11 Caso de estudio: marco de trabajo para el Grupo de Redes Repositorio software Como mencionamos anteriormente, el repositorio software presta dos servicios: el sistema de control de versiones y el sistema de archivos distribuidos. Control de versiones mediante CVS Como herramienta de control de versiones, utilizamos el sistema CVS [8] Concurrent Versions System, o Sistema de Versiones Concurrentes. Se trata de una aplicaión de software libre ampliamente difundido. En nuestro caso utilizamos el esquema cliente/servidor de manera que todas las versiones de archivos fuente y configuración para cada proyecto se encuentran centralizadas en un servidor. Para un uso más ágil y cómodo del mismo, empleamos clientes con interfaces gráficos de usuario, como WinCVS para Windows o Cervisia disponible para Linux. Por otra parte, en el caso de que necesitemos trabajar con servidores CVS a través de redes inseguras, el sistema admite el empleo de protocolos de transporte seguros (SSL), que cifran la información. A la hora de gestionar los archivos de un proyecto mediante CVS, creamos un módulo por cada proyecto: un módulo CVS es un elemento jerárquico, similar a un directorio, que contiene un conjunto de versiones de archivos. De esta manera, podemos gestionar los permisos de los usuarios CVS restringiendo el acceso a los módulos en función del proyecto asignado y su rol. A fin de organizar los distintos archivos del proyecto, crearemos una estructura de directorios dentro del módulo correspondiente, donde situaremos cada archivo en función de su categoría: Requerimientos Diseño Implementación Despliegue Documentación Debido a que la información contenida en el repositorio es sumamente importante y crítica para nuestro negocio, debemos nombrar un administrador del mismo. El administrador velará por la integridad y coherencia del repositorio, y otorgará a cada usuario/grupo permisos para acceder a los módulos que esté desarrollando. Por supuesto, es imprescindible salvaguardar la información del repositorio mediante una política de copias de seguridad con una frecuencia suficiente: En nuestro caso, optamos por realizar una copia diaria, de forma automatizada, en las horas nocturnas cuando no hay actividad y los desarrolladores ya han incorporado los archivos correspondientes al trabajo diario.

12 Política de etiquetado Una correcta utilización de un sistema de control de versiones requiere definir una política de etiquetado. De esta manera podremos realizar seguimientos y localizar versiones concretas del proyecto. Constituye la clave para el paso de aplicaciones entre distintos entornos. Dicha política se traduce en una nomenclatura específica para las etiquetas. Tabla 1. Política de etiquetado. Entorno Sintaxis de la etiqueta Significado del prefijo Desarrollo DR_NombreProyecto_VersiónProyecto Development Release Integración IR_NombreProyecto_VersiónProyecto Integration Release Preproducción PR_NombreProyecto_VersiónProyecto Preproduction Release Producción FR_NombreProyecto_VersiónProyecto Final Release Sistema de archivos distribuido: SMB Para compartir archivos comunes, que no precisan de control de versiones tales como instaladores, documentación externa, etc. ofrecemos, dentro del repositorio software, un servicio de archivos en red de tipo SMB [9]. Este servicio resulta muy cómodo y práctico pues permite trabajar con los directorios compartidos como si se tratase de unidades locales a la máquina cliente y ofrece una alta compatibilidad entre sistemas Linux y Windows. Ambos servicios se encuentran instalados sobre servidores Linux en nuestro entorno de trabajo. Entorno de desarrollo En nuestro entorno de desarrollo, seguimos una política de trabajo local, donde cada desarrollador posee su propia máquina, en la cuál instala todos los servicios y herramientas requeridos para llevar a cabo sus actividades de manera que sea completamente autosuficiente. No obstante, en determinadas situaciones habilitaremos servidores externos para prestar servicios comunes a todos los usuarios de un entorno. Es el caso del servicio de directorio Active Directory [10]. Dicho servicio es compartido entre todos los usuarios en los entornos de desarrollo e integración política mixta.

13 Figura 4. Esquema de nuestro entorno de desarrollo. De forma estándar, configuramos las máquinas de desarrollo con el siguiente software: Tabla 2. Configuración estándar de software para las máquinas de desarrollo. Sistema operativo Windows XP ó 2003 Suite ofimática MS-Office Cliente de correo electrónico y agenda MS-Office Outlook Servidor de directorio OpenLDAP y Active Directory Servidor de B.D. MySQL y SQL Server Servidor Web Apache Tomcat Servidor de aplicaciones JBoss Herramienta de modelado software ArgoUML / Poseidon for UML Herramienta de modelado de datos DBDesigner IDE (entorno integrado de desarrollo) Eclipse + plugins Herramienta de generación automática Ant Compilador J2EE SDK Intérprete/Máquina virtual J2EE Runtime Environment/Java Virtual Machine Generación de archivos históricos (logs) Log4Java Cliente de directorio Softerra LDAP Browser / Administrador de Active Directory Cliente de B.D. (administración) MySQL Administrator Cliente de B.D. (navegador) MySQL Browser Cliente Web Microsoft Internet Explorer / Netscape Navigator Cliente CVS WinCVS Editor XML Cooktop

14 Para permitir un funcionamiento ágil del sistema, teniendo en cuenta la carga que suponen los anteriores servicios y aplicaciones, utilizaremos configuraciones hardware de características equivalentes o superiores a las siguientes: Tabla 3. Configuración hardware mínima para las máquinas de desarrollo. Procesador Pentium III o Athlon XP Memoria RAM 512 MB Disco 40 GB Interfaz de red Ethernet 100 Mbps Entorno de integración En este entorno obtendremos los archivos correspondientes a la versión que queremos compilar del CVS. Debemos contar con las herramientas necesarias para obtener de una forma sencilla los archivos, para compilarlos y para ejecutar la aplicación. Para las pruebas de integración será necesario poner en funcionamiento la aplicación, por tanto serán necesarios los servidores de base de datos, de directorio, Web y de aplicaciones, así como la máquina virtual de Java. Además, necesitaremos un cliente CVS para obtener del repositorio la versión correspondiente de los archivos fuente que componen la aplicación. Figura 5. Esquema del entorno de integración. En cuanto al conjunto de datos utilizado para las pruebas, se trata de datos ficticios para evitar problemas con la información sensible. Tabla 4. Configuración software para el entorno de integración.

15 Sistema Operativo Cliente CVS Servidor de aplicaciones Servidor Web Servidor de directorio Servidor de B.D. Compilador Intérprete/Máquina virtual Herramienta para generación automática Generación de archivos históricos (logs) Linux Servicia JBoss Apache Tomcat OpenLDAP y Active Directory MySQL J2EE SDK J2EE Runtime Environment Ant Log4Java Tabla 5. Configuración hardware mínima para el entorno de integración. Procesador Pentium III o Athlon XP Memoria RAM 512 MB Disco 40 GB Interfaz de red Ethernet 100 Mbps Entorno de preproducción. En este entorno se llevan a cabo las pruebas de aceptación del producto, las últimas realizadas antes de pasar la aplicación al entorno de producción. Por este motivo, el entorno de preproducción debe contener la infraestructura necesaria para ejecutar la aplicación. Para ello será necesario el servidor de aplicaciones, servidor Web, de base de datos y de directorio. La carga de datos en este entorno debe ser similar a la de producción para poder realizar pruebas de rendimiento reales. Figura 6. Esquema del entorno de preproducción. Tabla 4. Configuración software para el entorno de preproducción.

16 Sistema Operativo Cliente CVS Servidor de aplicaciones Servidor Web Servidor de directorio Servidor de B.D. Compilador Intérprete/Máquina virtual Herramienta para generación automática Generación de archivos históricos (logs) Windows WinCVS JBoss Apache Tomcat Active Directory MySQL J2EE SDK J2EE Runtime Environment Ant Log4Java Tabla 5. Configuración hardware para el entorno de integración. Procesador Xeon Memoria RAM 1 GB Disco 140 GB Interfaz de red Ethernet 1 Gbps / 100 Mbps Entorno de producción. En nuestro entorno de producción utilizamos una configuración hardware/software idéntica a la de preproducción, garantizando en la medida de lo posible un comportamiento similar de la aplicación en ambos entornos. Por otra parte, en este entorno los usuarios finales tienen acceso a la aplicación, por tanto adoptamos las medidas de seguridad oportunas para evitar ataques o usos ilegítimos del sistema. Figura 7. Esquema del entorno de producción. Tabla 4. Configuración software para el entorno de preproducción.

17 Sistema Operativo Cliente CVS Servidor de aplicaciones Servidor Web Servidor de directorio Servidor de B.D. Compilador Intérprete/Máquina virtual Herramienta para generación automática Generación de archivos históricos (logs) Windows WinCVS JBoss Apache Tomcat Active Directory MySQL J2EE SDK J2EE Runtime Environment Ant Log4Java Tabla 5. Configuración hardware para nuestro entorno de integración servidores Proliant. Procesador Xeon Memoria RAM 1 GB Disco 140 GB Interfaz de red Ethernet 1 Gbps / 100 Mbps Conclusiones Los nuevos modelos empresariales requieren aplicaciones dotadas de las siguientes características: Seguridad. Robustez y fiabilidad. Tolerancia a fallos. Escalabilidad. Flexibilidad. Interoperabilidad. Mantenimiento y gestión. Con el objetivo de soportar estas características, que suponen una complejidad tecnológica considerable, surgen plataformas como J2EE y.net, que ofrecen las infraestructuras básicas necesarias para crear tales aplicaciones. Para que dicha construcción tenga lugar de forma ordenada y rigurosa, encajando las piezas adecuadas en los lugares clave, necesitamos ayudarnos de una serie de guías de diseño. Entre estas se encuentran los patrones de diseño, que ofrecen soluciones a problemas basados en la experiencia de terceros. Por último, como productores de aplicaciones, deseamos que éstas se construyan al ritmo adecuado, aprovechando al máximo los recursos humanos y tecnológicos disponibles, optimizando los costes y la calidad del producto. Para lograr estos objetivos, necesitamos un modelo de trabajo bien definido que soporte las diversas fases del proceso software y contemple las herramientas y tecnologías utilizadas en dicho proceso. Este modelo debe evolucionar para incorporar la experiencia obtenida en cada nuevo desarrollo. Se trata, en definitiva, de un concepto análogo al de los

18 patrones de diseño de aplicaciones, pero orientado a las políticas y metodologías de trabajo. En este artículo hemos propuesto un modelo de trabajo genérico que ofrece soporte a la creación y mantenimiento de aplicaciones utilizando plataformas empresariales. Para simplificar nuestro modelo, lo hemos dividido en entornos asociados a las fases del ciclo de vida del software, estableciendo políticas de paso de la aplicación entre los entornos. Esta división permite adaptar cada entorno a las necesidades específicas de la aplicación en cada estado concreto de su ciclo de vida, sin perder por ello la visión global del proyecto. Finalmente, hemos aplicado el modelo genérico a un caso práctico, especificando el modelo concreto que utilizamos para desarrollar proyectos en el Grupo de Redes, utilizando la plataforma J2EE. Referencias 1. P. Harmon, M. Rosen y M. Guttman. Developing E-business Systems and Architectures: A Manager s Guide. Ed: Morgan Kaufmann Publishers, J.L. Weaver, K. Mukhar y J. Crume. Begining j2ee 1.4: From novice to professional. Ed: Apress, U. Hansmann, L.Merk, M.S. Nicklous y T. Stober. Pervasive Computing, second edition. Springer, Sing, I, Stearns, B, Jonson, M: Design Enterprise Applications with J2EE Plantaform, Second Edition. Ed: Addison-Wesley, Royce, W.: Software project management. Ed.Addison-Wesley, Bodoff, S., Green, D., Haase, K., Jendrock, E., Pawlan, M., Stearns, B.: The J2EE tutorial. Ed. Addison-Wesley, Gong, L.: Inside Java 2 paltform security. Ed. Addison-Wesley, Eckstein, R., Collier-Brown, D., Kelly, P.: Using Samba. Ed. O Reilly, Allen, R.: Active Directory Cookbook for Windows Server 2003 and Windows Ed. O Reilly, 2003.