17
www.osgg.net Página 1 de 17 Integración continua en componentes EJB Omar Salvador Gómez Gómez Enero 2008 versión 1.0 $$ '"% " !##"##$$#'"%# &*& '%% +(&%) "

Integración continua en componentes EJB

Embed Size (px)

Citation preview

Page 1: Integración continua en componentes EJB

www.osgg.net Página 1 de 17

Integración continua en componentes EJB

Omar Salvador Gómez Gómez

Enero 2008 versión 1.0

Page 2: Integración continua en componentes EJB

www.osgg.net Página 2 de 17

Tabla de Contenido

1. INTRODUCCIÓN Y DEFINICIÓN DEL PROBLEMA .......................................... 3

2. TRABAJO PREVIO...................................................................................................... 3

2.1. INTEGRACIÓN CONTINUA ........................................................................................... 32.2. INTEGRACIÓN DE COMPONENTES ............................................................................... 42.3. COMPONENTES EJB................................................................................................... 52.3.1. INTRODUCCIÓN....................................................................................................... 52.3.2. ¿QUÉ ES UN ENTERPRISE BEAN?.............................................................................. 62.3.3. TIPOS DE ENTERPRISE BEANS .................................................................................. 62.3.4. ENTERPRISE BEANS DE SESIÓN................................................................................ 62.3.5. BEANS DIRIGIDOS POR MENSAJES............................................................................ 72.3.6. CONTENIDO DE UN ENTERPRISE BEAN..................................................................... 7

3. SOLUCIÓN PROPUESTA........................................................................................... 8

3.1. PROCESO DE INTEGRACIÓN CONTINUA DE COMPONENTES EJB .................................. 83.1.1. ESPECIFICACIÓN E IMPLEMENTACIÓN DE COMPONENTES ........................................ 83.1.2. VERIFICACIÓN DE COMPONENTES ........................................................................... 83.1.3. INTEGRACIÓN DE COMPONENTES ............................................................................ 93.1.4. VERIFICACIÓN DE INTEGRACIÓN............................................................................. 93.1.5. ENVÍO DE COMPONENTES AL REPOSITORIO CENTRAL.............................................. 93.1.6. CONSTRUCCIÓN Y DESPLIEGUE ............................................................................... 93.2. ANÁLISIS DE HERRAMIENTAS PARA INTEGRACIÓN DE COMPONENTES EJB .............. 103.2.1. HERRAMIENTAS PARA EL PROCESO DE CONSTRUCCIÓN ........................................ 103.2.1.1. ANT ................................................................................................................... 103.2.1.2. MAVEN.............................................................................................................. 113.2.2. SERVIDORES PARA EL PROCESO DE INTEGRACIÓN CONTINUA ............................... 113.2.2.1. ANTHILLPRO ..................................................................................................... 113.2.2.2. BAMBOO............................................................................................................ 123.2.2.3. CONTINUUM ...................................................................................................... 123.2.2.4. CRUISECONTROL ............................................................................................... 123.2.2.5. HUDSON ............................................................................................................ 123.2.2.6. TEAMCITY......................................................................................................... 123.2.3. CUADRO COMPARATIVO ....................................................................................... 133.2.3.1. INFORMACIÓN DEL PROYECTO. .......................................................................... 133.2.3.2. SOPORTE DE SERVIDORES DE CONTROL DE VERSIONES ...................................... 133.2.3.3. GESTIÓN EN LA CONSTRUCCIÓN......................................................................... 143.2.3.4. SEGURIDAD ....................................................................................................... 143.2.3.5. NOTIFICACIONES ............................................................................................... 143.2.3.6. INTERFAZ WEB .................................................................................................. 143.2.3.7. HERRAMIENTAS PARA CONSTRUCCIÓN DE PROYECTOS...................................... 153.2.3.8. INTEGRACIÓN CON OTRAS HERRAMIENTAS ........................................................ 153.2.3.9. INSTALACIÓN Y CONFIGURACIÓN....................................................................... 16

4. CONCLUSIONES ....................................................................................................... 16

5. REFERENCIAS........................................................................................................... 17

Page 3: Integración continua en componentes EJB

www.osgg.net Página 3 de 17

1. Introducción y definición del problema

Uno de los problemas que se tiene en la actualidad durante el desarrollo de grandes

sistemas software es el ocasionado durante la etapa de integración de éstos. A este problema se le ha acuñado el término de, “el infierno de la integración”.

El infierno de la integración es una consecuencia directa de la evolución que ha sufrido el software. Actualmente los sistemas software son más complejos, contienen cientos de miles de líneas de código fuente y, generalmente son desarrollados por distintos equipos de personas que se encuentran dispersos geográficamente.

En la actualidad, se sabe que el esfuerzo requerido para llevar acabo la integración

es exponencialmente proporcional a la cantidad del tiempo en que se posponga esta actividad. Entre más tiempo pase sin efectuar la integración, mayor es el riesgo en que haya conflictos en los cambios, ya sea en el tiempo de construcción del sistema o en el tiempo de ejecución.

En el presente documento se propone un proceso de integración para componentes EJB, este proceso se basa particularmente en la práctica de integración continua que forma parte de la metodología ágil llamada programación extrema. A su vez, se presenta un análisis sobre seis herramientas que pueden ser utilizadas en este proceso. El resto del presente documento se encuentra organizado de la siguiente manera, en la segunda sección se presenta el trabajo previo, en la tercera se propone el proceso de integración continua para componentes EJB, en esta misma sección se realiza un análisis sobre varios servidores de integración continua que pueden ser usados en el proceso de integración aquí propuesto, finalmente en la cuarta sección se presentan una serie de conclusiones.

2. Trabajo previo

En esta sección se presenta una serie de conceptos que serán usados en el desarrollo de la siguiente sección, la redacción de conceptos inicia con una perspectiva general que describe la integración continua de sistemas y finaliza con una perspectiva particular describiendo los componentes software y la tecnología de componentes EJB.

2.1. Integración continua

La integración continua de sistemas es una práctica recomendada por la

metodología ágil conocida como programación extrema. Básicamente en esta práctica se recomienda que los desarrolladores de software envíen sus ultimas versiones de código hacia un repositorio de código centralizado varias veces al día. La finalidad es que todos los desarrolladores trabajen con la última versión de códigos disponible por el repositorio.

Page 4: Integración continua en componentes EJB

www.osgg.net Página 4 de 17

De acuerdo a Fowler [1], la integración continua es una práctica del desarrollo de software en donde los miembros de un equipo integran su trabajo frecuentemente, usualmente cada persona integra al menos diariamente, habiendo múltiples integraciones por día. Cada integración es verificada por un proceso de construcción automatizado (incluye la ejecución de pruebas) que detecta errores de integración tan rápido como es posible. Varios equipos han encontrado que este enfoque permite reducir significativamente los problemas de integración y permite a un equipo desarrollar software cohesivo más rápidamente.

Fowler propone una serie de actividades para llevar a cabo esta práctica, que son: Mantener un único repositorio de artefactos. Automatizar el proceso de construcción. Incluir la automatización de pruebas en el proceso de construcción. Enviar cada día al repositorio las últimas versiones de artefactos. Por cada envío de códigos se deberá construir la línea base del sistema. Mantener el proceso de construcción rápido. Probar en un ambiente de pruebas igual al de producción. Hacer de una manera fácil que cualquier persona obtenga la última versión del

ejecutable. Que todo mundo vea lo que está sucediendo. Automatizar el proceso de despliegue.

2.2. Integración de componentes

La práctica antes descrita es tomada como referencia en este documento para llevar a cabo la integración de componentes software EJB. La integración de componentes software es el proceso mecánico de unir componentes entre si, cubriendo de esta manera las necesidades y servicios de un componente con las necesidades y servicios de otros componentes. Szyperski[2] define un componente software como la unidad de composición con interfaces especificadas contractualmente y explicitas del contexto.

Para llevar a cabo la descripción de un componente software de manera completa y asegurar su correcta integración, mantenimiento y actualización, un componente software deberá consistir de lo siguientes elementos:

Un conjunto de interfaces proporcionadas o requeridas por algún entorno. Éstas son usadas para la interacción con otros componentes.

Un código ejecutable, el cual puede ser acoplado al código de otros componentes a través de sus interfaces.

La interfaz de un componente puede ser definida como una especificación de sus puntos de acceso. Los clientes acceden a los servicios proporcionados por el componente usando estos puntos de acceso. Cabe señalar que una interfaz no ofrece la implementación de ninguna de sus operaciones. En lugar de esto, la interfaz define una colección de operaciones y solamente proporciona las descripciones de éstas.

Page 5: Integración continua en componentes EJB

www.osgg.net Página 5 de 17

Idealmente, cada una de las operaciones de una interfaz deben ser especificadas semánticamente para que se garantice la correcta interacción con otros componentes. Una manera de garantizar dicha interacción es a través del uso de contratos. En un contrato se listan las restricciones globales que el componente debe mantener es decir mantener su invariante. Para cada una de las operaciones dentro del componente, un contrato también lista las restricciones que necesita de cumplir el cliente, es decir cumplir la precondición, y así el componente promete la ejecución de la operación, en otras palabras se garantiza la poscondición. El uso de diseño por contrato puede asegurar que diferentes componentes software puedan trabajar de manera satisfactoria, siendo éstos desarrollados en diferentes tiempos por distintas personas y posiblemente por distintas organizaciones. Además, el uso de contratos para especificar el comportamiento en la interacción de componentes software ayuda a la reutilización, integración y refinamiento de componentes software. En una de las partes del proceso de integración que se describe en la siguiente sección se hace uso del lenguaje descriptivo OCL[3] (Object Constraint Language) para definir los contratos en los componentes. A continuación se describe brevemente la tecnología de componentes EJB.

2.3. Componentes EJB

2.3.1. Introducción

Los Enterprise Beans[4] son componentes Java que implementan la tecnología EJB (Enterprise Java Bean) esta tecnología es parte de la plataforma Java EE (Java Enterprise

Edition). Este tipo de componentes se ejecutan dentro de un contenedor EJB que es un entorno de ejecución dentro de un servidor de aplicaciones. Aunque, transparente para el desarrollador de aplicaciones, el contenedor EJB proporciona servicios a nivel de sistema tales como manejo de transacciones y seguridad para los enterprise beans. Estos tipos de servicios permiten al desarrollador construir y desplegar aplicaciones de manera rápida.

En la siguiente figura se presentan los diferentes tipos de contenedores que existen

en la plataforma Java EE.

Tipos de contenedores en la tecnología JEE

Page 6: Integración continua en componentes EJB

www.osgg.net Página 6 de 17

2.3.2. ¿Qué es un enterprise bean?

Escritos en el lenguaje de programación Java, un enterprise bean es un componente software del lado del servidor que encapsula la lógica del negocio de una aplicación. La lógica del negocio es el código que satisface el propósito de la aplicación.

Los enterprise beans simplifican el desarrollo de grandes aplicaciones distribuidas. Primeramente, porque el contenedor EJB proporciona servicios a nivel de sistema a los enterprise beans, por lo que el desarrollador de estos componentes puede concentrarse solamente en resolver los problemas de la lógica del negocio. Por su parte el contenedor de EJB es responsable por los servicios a nivel de sistema tales como el manejo de transacciones y seguridad. Segundo, los enterprise beans en vez de los clientes, contienen la lógica del negocio de la aplicación, por lo que el desarrollador del cliente puede concentrarse únicamente en la presentación del cliente. Tercero, ya que los enterprise beans son componentes portables, la persona responsable por el ensamblado de componentes puede construir nuevas aplicaciones de componentes existentes.

Se recomienda el uso de esta tecnología cuando: La aplicación deba ser escalable. por ejemplo, si existe un incremento en el número

de usuarios de la aplicación tal vez sea necesario distribuir los componentes que forman la aplicación entre varios ordenadores. Esta tecnología permite que la ubicación de los componentes sea transparente para sus clientes.

Las transacciones deban garantizar la integridad en los datos. Los enterprise beans soportan el manejo de transacciones.

La aplicación deba tener una diversidad de clientes. Con unas pocas líneas de código, los clientes pueden localizar y usar este tipo de componentes.

2.3.3. Tipos de enterprise beans

Existen dos tipos de enterprise beans

Tipo Propósito Sesión Realizan una tarea para un cliente; opcionalmente

pueden implementar un servicio Web. Dirigido por mensajes Actúan como un escuchador para un tipo de

mensaje en particular, tal como la API del servicio de mensajes de Java.

2.3.4. Enterprise beans de sesión

Representan un solo cliente dentro del servidor de aplicaciones. Para acceder a una aplicación que es desplegada en el servidor, el cliente invoca a los métodos del bean de sesión. Este componente realiza el trabajo por sus clientes. Como su nombre lo sugiere un bean de sesión es similar a una sesión interactiva. Un bean de sesión no es compartido; éste solo puede tener un cliente, de la misma manera en que una sesión interactiva solamente se puede tener un usuario. Cómo una sesión interactiva, un bean de sesión no es persistente, es decir sus datos no son almacenados en algún repositorio. Cuando el cliente finaliza la ejecución de alguna operación del bean, el bean de sesión es desasociado del cliente.

Page 7: Integración continua en componentes EJB

www.osgg.net Página 7 de 17

Existen dos tipos de beans de sesión, con estado y sin estado. En un bean de sesión

con estado, el estado de los valores de las variables es retenido durante la duración de la sesión entre el cliente y el enterprise bean. Por su parte, en un bean de sesión sin estado únicamente se mantiene el estado de sus variables durante la invocación de sus métodos.

2.3.5. Beans dirigidos por mensajes

Este tipo de componentes permite a las aplicaciones procesar mensajes de manera asíncrona. Un bean dirigido por mensajes normalmente actúa como escuchador, el cual es similar a un escuchador de eventos a diferencia de que este recibe mensajes en vez de eventos. Los mensajes pueden ser enviados por cualquier componente o por alguna otra aplicación que no utilice la tecnología Java.

2.3.6. Contenido de un enterprise bean

Para desarrollar un enterprise bean, se deben proporcionar los siguientes ficheros: La clase del enterprise bean. Implementa los métodos definidos en las interfaces

(llamadas también interfaces del negocio). Interfaces del negocio. En las interfaces del negocio se definen los métodos que

son implementados por la clase del enterprise bean. Las interfaces pueden ser locales o remotas.

Clases de ayuda. Otras clases necesarias por las clases de los enterprise beans, tales como excepciones y clases utilitarias.

Una vez que se tienen los ficheros anteriores, estos se empaquetan en un fichero

JAR1 llamado EJB JAR que contiene los anteriores ficheros. Un fichero EJB JAR es portable y puede ser usado por distintas aplicaciones. Para ensamblar una aplicación Java EE, se empaqueta uno o varios ficheros EJB JAR (llamados también módulos) dentro de un fichero EAR2 que contiene la aplicación. Una vez que se encuentra listo el fichero EAR, este puede ser desplegado en algún servidor de aplicaciones JEE. En la siguiente figura se muestra la estructura de un fichero EJB JAR.

Estructura física de un EJB

1 Un fichero JAR(Java ARchive) es un fichero que contiene varios ficheros compresos dentro de éste. 2 Un fichero EAR(Enterprise ARchive) es un tipo de fichero usado por la plataforma Java EE para empaquetar uno o más módulos dentro de un fichero.

Page 8: Integración continua en componentes EJB

www.osgg.net Página 8 de 17

3. Solución propuesta

3.1. Proceso de integración continua de componentes EJB

A continuación se presenta un proceso de integración para componentes EJB y las herramientas disponibles para llevar acabo este proceso. Este proceso se basa en el propuesto por Fowler, sin embargo éste es adecuado al ámbito de la tecnología EJB. A su vez se propone el uso de OCL para especificar la semántica de las interfaces de los componentes. El proceso se compone de seis etapas que a continuación se detallan.

proceso de integración continua de componentes EJB

3.1.1. Especificación e implementación de componentes

Este proceso se puede llevar a cabo tomando como referencia el proceso de especificación definido por Chessman et al.[5] y posteriormente aplicado por Liu et al.[6]. En éste, Chessman et al. proponen tres etapas cíclicas para llevar a cabo la especificación que son: identificación, interacción y especificación de componentes software.

En lo que respecta a la definición de semántica en las interfaces de los componentes, los autores utilizan OCL como lenguaje formal. Cabe señalar que el proceso antes descrito es un proceso genérico, este proceso se adapta muy bien para llevarlo a cabo en la tecnología EJB. El autor del presente documento ha usado en dos ocasiones este proceso para implementar componentes EJB. La primera ocasión se usó en la implementación de componentes EJB 2.1 y la segunda en la implementación de componentes EJB 3.0.

3.1.2. Verificación de componentes

Es recomendable que se utilice algún lenguaje formal para especificar la semántica en las interfaces de los componentes. Habitualmente solo se efectúa la especificación sintáctica de éstos. Una de las ventajas de especificar la semántica en las interfaces es que la persona responsable por implementar los componentes conoce de manera previa el contrato que se debe satisfacer para que el componente le brinde los servicios que este ofrece.

Brucker et al.[7] proponen un pequeño proceso en el que transforman un modelo UML de clases que contienen una serie de restricciones definidas en OCL a un modelo de componentes EJB. Durante la transformación, las restricciones OCL son colocadas en las interfaces de los componentes EJB, por lo que de esta manera se logra la definición del contrato de uso de cada componente.

Page 9: Integración continua en componentes EJB

www.osgg.net Página 9 de 17

3.1.3. Integración de componentes

Durante este proceso se efectúan las uniones entre el conjunto de componentes previamente especificados e implementados. El especificar los contratos en los componentes reduce el riesgo de no poder integrar algún componente.

3.1.4. Verificación de integración

En este proceso se pueden definir un conjunto de pruebas y ejecutarlas antes de proceder a enviar los componentes al repositorio central. En particular las pruebas de componentes EJB 3.0 se pueden llevar a cabo con una herramienta llamada Ejb3Unit3. Ejb3Unit proporciona una serie de pruebas que se pueden realizar en los diferentes tipos de componentes que existen en la tecnología EJB 3.0. Una característica particular de esta herramienta es que las pruebas se efectúan fuera del contenedor EJB. Una vez que se definen las pruebas, éstas se pueden ejecutar utilizando la herramienta Maven que se describe posteriormente en este documento.

3.1.5. Envío de componentes al repositorio central

Una vez que se ejecutan las pruebas, el desarrollador procede a enviar los componentes EJB al repositorio central. Este proceso se recomienda sea llevado varias veces al día o cada que alguna característica importante es implementada. Para llevar a cabo este proceso, se puede apoyar de la herramienta llamada Subversion, que es una de las más utilizadas para controlar el manejo de versiones en proyectos de desarrollo de software.

3.1.6. Construcción y despliegue

Este proceso puede ser automatizado utilizando algún servidor de integración continua. Los desarrolladores mantienen sus códigos acompañados de las pruebas en un servidor de control de versiones en el que continuamente, un servidor de integración continua monitorea los cambios efectuados en éste.

Cada que el servidor de integración continua detecta algún cambio, este ejecuta un

script que construye el proyecto. Generalmente el script de construcción regresa las ultimas versiones de todos los códigos y de las pruebas que se ejecutaron, compila el código junto con las pruebas y finalmente ejecuta las pruebas.

Si el código falla durante la compilación o si fallan las pruebas, se dice que la construcción del proyecto ha fallado, de otra manera se dice que el proyecto se ha construido satisfactoriamente. El resultado de la construcción es publicado a los desarrolladores de ese proyecto a través del envío de correos o mensajería instantánea. En lo que respecta al despliegue, algunos servidores de integración continua tienen la capacidad de desplegar la aplicación en un ambiente de pruebas que es igual al de producción. 3 Más información en http://ejb3unit.sourceforge.net/

Page 10: Integración continua en componentes EJB

www.osgg.net Página 10 de 17

A continuación se presenta un escenario en que se usa el proceso de integración antes descrito.

Escenario de integración continua de componentes EJB

En la figura anterior, un conjunto de desarrolladores trabajan sobre la especificación

e implementación de componentes, efectúan las pruebas y la integración de componentes, después los desarrolladores envían sus últimas versiones de los componentes al repositorio central (repositorio remoto), el cual es monitoreado por el servidor de integración continua que procede a realizar la construcción y despliegue del sistema. Cabe señalar que los desarrolladores pueden estar dispersos geográficamente.

3.2. Análisis de herramientas para integración de componentes EJB

3.2.1. Herramientas para el proceso de construcción

Existen dos herramientas que pueden ser usadas para el proceso de construcción de componentes EJB estas son Ant y Maven, a continuación de describen brevemente.

3.2.1.1. Ant

Ant4 es una herramienta usada en ambientes de desarrollo software para la realización de tareas mecánicas y repetitivas, normalmente durante la fase de compilación y construcción. Esta herramienta, hecha en Java, tiene la ventaja de no depender de las órdenes de la línea de comandos o shell de cada sistema operativo, sino se basa en archivos de configuración XML y clases Java para la realización de las distintas tareas, siendo idónea como solución multi-plataforma.

4 Más información acerca de Ant, disponible en http://ant.apache.org/

Page 11: Integración continua en componentes EJB

www.osgg.net Página 11 de 17

3.2.1.2. Maven

Maven5 es una herramienta de código abierto para apoyar al proceso de construcción de proyectos Java empresariales (del tipo jar, ear, ejb, war). Esta herramienta usa un enfoque declarativo en el que se describe la estructura y contenido de un proyecto en vez de usar el enfoque basado en tareas que es usado por Ant. Algunas de las características de esta herramienta son:

Construcción, ejecución de pruebas y empaquetado de un proyecto con un solo comando.

Permite administrar las dependencias de un proyecto de forma eficiente. Permite unificar la estructura de los proyectos. Permite generar una página Web del proyecto con información general y con

reportes variados relacionados al proyecto. Define una guía de buenas prácticas de desarrollo.

El núcleo de un proyecto Maven es el denominado Project Object Model (POM),

que contiene la descripción detallada de un proyecto en particular, entre otras cosas se incluye información acerca de las versiones, gestión de la configuración, dependencias, recursos de aplicación, pruebas, estructura y miembros del equipo. El POM toma la forma de un fichero XML.

Los servidores de integración continua que se analizan a continuación pueden utilizar cualquiera de las dos herramientas antes descritas para llevar acabo la construcción de componentes EJB.

3.2.2. Servidores para el proceso de integración continua

En esta parte se presentan seis servidores de integración continua que pueden utilizarse para automatizar el proceso de construcción. A su vez se realiza un cuadro comparativo entre éstos. A continuación se describe de manera general cada unos de estos servidores.

3.2.2.1. AnthillPro

AnthillPro6 es un servidor de gestión de construcciones de tercera generación para equipos de desarrollo que usan plataformas Java, .NET o nativas. Construido alrededor de un motor de flujo de trabajo embebido y un motor de cómputo GRID. Esta herramienta hace posible definir y automatizar construcciones distribuidas, despliegues y gestión de artefactos. Tiene la capacidad de capturar artefactos construidos para su posterior uso en las fase de ciclo de vida.

5 Si desea más información acerca de Maven, consultar http://maven.apache.org/ 6 Más información en http://www.urbancode.com/html/default.html

Page 12: Integración continua en componentes EJB

www.osgg.net Página 12 de 17

3.2.2.2. Bamboo

Bamboo7 introduce el término de telemetría en las construcciones para ayudar a identificar y resaltar tendencias, patrones y relaciones entre construcciones. Por lo que esta herramienta no solo se enfoca en los resultados tras una construcción. Como parte integral esta herramienta ofrece:

Telemetría dinámica en tiempo real para ayudar a mejorar las construcciones futuras y existentes.

Retroalimentación instantánea a través de diversos sistemas de mensajería instantánea.

Características de colaboración.

3.2.2.3. Continuum

Contiuum8 es uno de los proyectos de Apache, la página oficial de este proyecto contiene poca información ya que este proyecto apenas inicia. Hace uso de un gestor de base de datos de código libre llamado Derby, tiene una alta integración con Maven.

3.2.2.4. Cruisecontrol

CruiseControl9 es un marco de trabajo que ayuda al proceso de integración continua. Éste incluye un conjunto de plugins para notificaciones por correo, integración con herramientas de construcción y varias herramientas para el control de versiones. A través de una interfaz Web se informa al usuario sobre las construcciones actuales y las pasadas.

3.2.2.5. Hudson

Hudson10 monitorea las ejecuciones de trabajos repetidos, tales como la construcción de un proyecto software o ejecuta trabajos a través de cron11. Las principales características de esta herramienta son:

La construcción y pruebas de proyectos software de manera continua. Monitorea las ejecuciones de las construcciones, notificando el estado de estas a los

desarrolladores a través del envío de correos.

3.2.2.6. TeamCity

TeamCity12 es un sistema distribuido de gestión de construcciones e integración de sistemas que ayuda a los equipos de desarrollo a monitorear el proceso de construcción de

7 Información referente a Bamboo disponible en http://www.atlassian.com/software/bamboo/ 8 Proyecto localizado en http://maven.apache.org/continuum/ 9 Más información consultar http://cruisecontrol.sourceforge.net/ 10 Disponible en https://hudson.dev.java.net/ 11 En el sistema operativo Unix, cron es un gestor regular de procesos en segundo plano (demonio) que ejecuta programas a intervalos regulares.

Page 13: Integración continua en componentes EJB

www.osgg.net Página 13 de 17

software. Esta herramienta permite conocer por ejemplo, cuando una construcción falla y exactamente que pieza de código origino el fallo por lo que se optimiza el proceso de detección de fallos durante la construcción.

3.2.3. Cuadro comparativo

A continuación se presenta un cuadro comparativo entre los servidores de integración continua antes descritos. La comparación se divide en nueve categorías que son, información del proyecto, soporte de servidores de control de versiones, gestión de la construcción, seguridad, notificaciones e interfaz Web, herramientas para construcción de proyectos, integración de otras herramientas e instalación y configuración. Cada una de estas categorías se compone de una serie de características que son comparadas entre los diferentes servidores de IC de acuerdo al siguiente criterio:

La característica se encuentra presente (++) La característica existe, pero contiene defectos o no ha sido lo suficientemente

probada (D) La característica se encuentra planeada para un futuro cercano (P) La característica no existe (--)

3.2.3.1. Información del proyecto.

En esta categoría se efectúa la comparación con respecto a la información de quién desarrolla el producto.

Característica AnthillPro Bamboo Continuum Cruisecontrol Hudson TeamCity Código abierto -- --, solo a

clientes ++ ++ ++ --

Lenguaje de implementación

Java Java Java Java Java Java

Gratuito --, gratis solo para proyectos

código abierto

--, gratis solo para proyectos

código abierto

++ ++ ++ --, cuentan con una edición gratuita

Seguimiento de asuntos

privado JIRA13 JIRA JIRA dev.java.net JIRA

Demostración en línea

a través de solicitud

++ ++ ++ ++ ++

3.2.3.2. Soporte de servidores de control de versiones

En esta categoría los seis servidores hacen uso de cualquiera de los dos sistemas de control de versiones.

Característica AnthillPro Bamboo Continuum Cruisecontrol Hudson TeamCity CVS ++ ++ ++ ++ ++ ++ Subversion ++ ++ ++ ++ ++ ++

12 Más información consultar http://www.jetbrains.com/teamcity/ 13 JIRA es una herramienta para el manejo y seguimiento de defectos y otros asunto en un proyecto software. Más información consultar http://www.atlassian.com/software/jira/

Page 14: Integración continua en componentes EJB

www.osgg.net Página 14 de 17

3.2.3.3. Gestión en la construcción

En esta categoría solo tres servidores tienen la funcionalidad de realizar construcciones distribuidas, Hudson es el único servidor de código abierto que por el momento permite dicha funcionalidad.

Característica AnthillPro Bamboo Continuum Cruisecontrol Hudson TeamCity Construcciones en paralelo

++ ++ ++ ++ ++ ++

Construcciones distribuidas

++ P P D ++ ++

Forzar construcción de forma manual

++ ++ ++ ++ ++ ++

Planificación de construcciones

++ ++ ++ ++ ++ ++

3.2.3.4. Seguridad

En esta categoría son pocos los productos que se interesan por la integración LDAP, Kerberos o Single Sign On (SSO).

Característica AnthillPro Bamboo Continuum Cruisecontrol Hudson TeamCity Autenticación de usuarios

++ ++ ++ ++ limitada ++

Integración LDAP ++ ++ P -- -- ++ Kerberos ++ -- -- -- -- -- SSO ++ ++ via

crowd14 -- -- -- --

3.2.3.5. Notificaciones

En esta categoría se evalúa las capacidades de notificación con las que cuentan los servidores.

Característica AnthillPro Bamboo Continuum Cruisecontrol Hudson TeamCity Email ++ ++ ++ ++ ++ ++ IRC -- -- ++ -- ++ -- Jabber ++ ++ ++ ++ ++ ++ RSS ++ ++ P ++ ++ ++ Yahoo messenger ++ -- P -- -- -- Msn messenger -- -- ++ -- -- --

3.2.3.6. Interfaz Web

En esta categoría se evalúa las actividades rutinarias que los usuarios pueden realizar tales como creación, modificación y borrado de proyectos entre otras más.

Característica AnthillPro Bamboo Continuum Cruisecontrol Hudson TeamCity

14 Crowd es una herramienta que permite el Single Sign On (SSO) basada en Web que simplifica el proceso de gestión de identidades. Para más información, consultar http://www.atlassian.com/software/crowd/

Page 15: Integración continua en componentes EJB

www.osgg.net Página 15 de 17

Ver cambios ++ ++ ++ -- ++ ++ Agregar nuevos proyectos

++ ++ ++ D ++ ++

Clonar proyectos ++ ++ -- -- ++ ++ Borrar proyectos ++ ++ ++ D ++ ++ Modificar proyectos

++ ++ ++ D ++ ++

Eliminación de construcciones

++ -- P ++ ++ ++

Pausar construcciones

++ ++ P ++ -- ++

Acceso a construcción de artefactos

++ ++ ++ ++ ++ ++

Gráficos con históricos

++ ++ P ++ ++ ++

Soporte multi-proyectos

++ ++ ++ ++ ++ ++

Vistas multi-proyectos

++ ++ ++ ++ ++ ++

3.2.3.7. Herramientas para construcción de proyectos

A excepción de Bamboo, los servidores evaluados utilizan comandos, scripts, Ant o Maven para la construcción de proyectos.

Característica AnthillPro Bamboo Continuum Cruisecontrol Hudson TeamCity Shell / Scripts de comandos

++ -- ++ ++ ++ ++

Ant ++ ++ ++ ++ ++ ++ Maven ++ ++ ++ ++ ++ ++

3.2.3.8. Integración con otras herramientas

En esta categoría se compara la integración con otro tipo de herramientas tales como componentes para seguimiento de defectos, integración con entornos de desarrollo, entre otros más.

Característica AnthillPro Bamboo Continuum Cruisecontrol Hudson TeamCity Bugzilla ++ -- -- -- -- ++ Jira ++ ++ -- -- ++ ++ JUnit result rendering

++ ++ P ++ ++ ++

Eclipse plugin ++ ++ P ++ ++ ++

Page 16: Integración continua en componentes EJB

www.osgg.net Página 16 de 17

3.2.3.9. Instalación y configuración

Finalmente, en esta categoría se presentan algunas características relacionadas con la instalación, medio de distribución, tipos de ficheros que usa para configurar el servidor, entre otras más. Característica AnthillPro Bamboo Continuum Cruisecontrol Hudson TeamCity

Instalador de Windows

++ ++ P -- ++ ++

Distribución auto contenida

-- ++ ++ ++ ++ ++

Plataforma de ejecución

JVM JVM JVM JVM JVM JVM

Plataforma de proyecto (Lo que puede construir)

Cualquier lenguaje

Java+Ant/Maven Cualquier lenguaje

Java+Ant/Maven Cualquier lenguaje

Cualquier lenguaje

Herramienta de construcción preferente

Cualquiera Cualquiera Maven Ant, Maven Cualquiera Cualquiera

Sin necesidad de modificar scripts de construcción

++ ++ ++ ++ ++ ++

Configuración de ficheros de texto

++, XML ++, XML -- ++, XML ++, XML ++, XML

4. Conclusiones

El uso de lenguajes formales para especificar la semántica en interfaces de los componentes software beneficia al proceso de integración de éstos, ya que quienes son responsables de integrarlos conocen el contrato que cada componente debe cumplir para su apropiado funcionamiento. El lenguaje declarativo OCL permite entre otras funciones, el especificar las invariantes, pre y poscondiciones sobre las interfaces de los componentes.

En el presente documento se presentó un proceso de integración para componentes EJB que en sus fases iniciales éste promueve la práctica de especificar la semántica en interfaces de los componentes con el objetivo de reducir el número de defectos producidos durante la integración de éstos. A la vez, se presentó un escenario tipico en el que se puede llevar acabo este proceso.

Finalmente se elaboró un cuadro comparativo sobre los distintos servidores de integración continua que pueden se usados en el proceso de integración de componentes EJB. En la evaluación se realizó un comparativo con respecto a una serie de características que están divididas en nueve categorías.

Algunas de las conclusiones que se obtuvieron tras la evaluación fueron, el servidor

Contiuum se encuentra en la etapa temprana de desarrollo ya que varias de las

Page 17: Integración continua en componentes EJB

www.osgg.net Página 17 de 17

características evaluadas se tienen contempladas desarrollarlas en un futuro cercano. Por su parte, Cruisecontrol que lleva ya tiempo en el mercado presenta una serie de características que aun no han sido lo suficientemente probadas, tal es el caso del manejo de construcciones distribuidas.

Los servidores AnthillPro, Bamboo y TeamCity poseen una mayor madurez, la

mayoría de las características se encuentran presentes en éstos, sin embargo cuentan con versiones gratuitas las cuales reducen el funcionamiento de algunas características. Finalmente, los dos proyectos más nuevos son Continuum y Hudson. El proyecto Continuum es apoyado por la comunidad Apache mientras que Hudson por la comunidad de desarrollo Java.net.

5. Referencias

[1] Fowler M. and Foemmel M., Continuous Integration.

http://www.martinfowler.com/articles/continuousIntegration.html. Accessed in January 2006.

[2] C. Szyperski. Component Software: Beyond Object-Oriented Programming. ACM Press / Addisson-Wesley, 1998.

[3] Linda Heaton. Object Constraint Language, v 2.0., OMG, April, 2007. [4] Rima Patel Sriganesh; Gerald Brose & Micah Silverman. Mastering Enterprise

JavaBeans 3.0. , New York, NY, USA, John Wiley & Sons, Inc., 2006. [5] John Cheesman & John Daniels. UML components: a simple process for specifying

component-based software. , Boston, MA, USA, Addison-Wesley Longman Publishing Co., Inc., 2000.

[6] Y. Liu & H. Cunningham. Software Component Specification Using Design by

Contract, Proceeding of the SouthEast Software Engineering Conference, Tennessee Valley Chapter, National Defense Industry Association,. , 2002. [7] Achim D. Brucker & Burkhart Wolff. Testing Distributed Component Based Systems

Using UML/OCL. Informatik 2001, Wien, November, Tagungsband der GI/ÖCG Jahrestagung, Volume 1, Number 157, Pages 608-614, 2001.