Download artículo - osgg.net

Integración continua en
componentes EJB
Omar Salvador Gómez Gómez
Enero 2008
versión 1.0
$
$
'"%"
!##
"##$$
#'"%#
&*& '%% +(&%) "
www.osgg.net
Página 1 de 17
Tabla de Contenido
1. INTRODUCCIÓN Y DEFINICIÓN DEL PROBLEMA .......................................... 3
2. TRABAJO PREVIO...................................................................................................... 3
2.1. INTEGRACIÓN CONTINUA ........................................................................................... 3
2.2. INTEGRACIÓN DE COMPONENTES ............................................................................... 4
2.3. COMPONENTES EJB................................................................................................... 5
2.3.1. INTRODUCCIÓN ....................................................................................................... 5
2.3.2. ¿QUÉ ES UN ENTERPRISE BEAN?.............................................................................. 6
2.3.3. TIPOS DE ENTERPRISE BEANS .................................................................................. 6
2.3.4. ENTERPRISE BEANS DE SESIÓN ................................................................................ 6
2.3.5. BEANS DIRIGIDOS POR MENSAJES............................................................................ 7
2.3.6. CONTENIDO DE UN ENTERPRISE BEAN ..................................................................... 7
3. SOLUCIÓN PROPUESTA........................................................................................... 8
3.1. PROCESO DE INTEGRACIÓN CONTINUA DE COMPONENTES EJB .................................. 8
3.1.1. ESPECIFICACIÓN E IMPLEMENTACIÓN DE COMPONENTES ........................................ 8
3.1.2. VERIFICACIÓN DE COMPONENTES ........................................................................... 8
3.1.3. INTEGRACIÓN DE COMPONENTES ............................................................................ 9
3.1.4. VERIFICACIÓN DE INTEGRACIÓN ............................................................................. 9
3.1.5. ENVÍO DE COMPONENTES AL REPOSITORIO CENTRAL .............................................. 9
3.1.6. CONSTRUCCIÓN Y DESPLIEGUE ............................................................................... 9
3.2. ANÁLISIS DE HERRAMIENTAS PARA INTEGRACIÓN DE COMPONENTES EJB .............. 10
3.2.1. HERRAMIENTAS PARA EL PROCESO DE CONSTRUCCIÓN ........................................ 10
3.2.1.1. ANT ................................................................................................................... 10
3.2.1.2. MAVEN .............................................................................................................. 11
3.2.2. SERVIDORES PARA EL PROCESO DE INTEGRACIÓN CONTINUA ............................... 11
3.2.2.1. ANTHILLPRO ..................................................................................................... 11
3.2.2.2. BAMBOO ............................................................................................................ 12
3.2.2.3. CONTINUUM ...................................................................................................... 12
3.2.2.4. CRUISECONTROL ............................................................................................... 12
3.2.2.5. HUDSON ............................................................................................................ 12
3.2.2.6. TEAMCITY ......................................................................................................... 12
3.2.3. CUADRO COMPARATIVO ....................................................................................... 13
3.2.3.1. INFORMACIÓN DEL PROYECTO. .......................................................................... 13
3.2.3.2. SOPORTE DE SERVIDORES DE CONTROL DE VERSIONES ...................................... 13
3.2.3.3. GESTIÓN EN LA CONSTRUCCIÓN......................................................................... 14
3.2.3.4. SEGURIDAD ....................................................................................................... 14
3.2.3.5. NOTIFICACIONES ............................................................................................... 14
3.2.3.6. INTERFAZ WEB .................................................................................................. 14
3.2.3.7. HERRAMIENTAS PARA CONSTRUCCIÓN DE PROYECTOS ...................................... 15
3.2.3.8. INTEGRACIÓN CON OTRAS HERRAMIENTAS ........................................................ 15
3.2.3.9. INSTALACIÓN Y CONFIGURACIÓN....................................................................... 16
4. CONCLUSIONES ....................................................................................................... 16
5. REFERENCIAS........................................................................................................... 17
www.osgg.net
Página 2 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.
www.osgg.net
Página 3 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.
www.osgg.net
Página 4 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
www.osgg.net
Página 5 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
Sesión
Dirigido por mensajes
Propósito
Realizan una tarea para un cliente; opcionalmente
pueden implementar un servicio Web.
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.
www.osgg.net
Página 6 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
JAR 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.
1
Estructura física de un EJB
1
Un fichero JAR(Java ARchive) es un fichero que contiene varios ficheros compresos dentro de éste.
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.
2
www.osgg.net
Página 7 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.
www.osgg.net
Página 8 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/
www.osgg.net
Página 9 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/
www.osgg.net
Página 10 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
6
Si desea más información acerca de Maven, consultar http://maven.apache.org/
Más información en http://www.urbancode.com/html/default.html
www.osgg.net
Página 11 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/
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.
8
www.osgg.net
Página 12 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
Código abierto
AnthillPro
--
Lenguaje de
implementación
Gratuito
Seguimiento de
asuntos
Demostración en
línea
Continuum
++
Cruisecontrol
++
Hudson
++
TeamCity
--
Java
Bamboo
--, solo a
clientes
Java
Java
Java
Java
Java
--, gratis
solo para
proyectos
código
abierto
privado
--, gratis
solo para
proyectos
código
abierto
JIRA13
++
++
++
--, cuentan
con una
edición
gratuita
JIRA
JIRA
dev.java.net
JIRA
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
CVS
Subversion
AnthillPro
++
++
Bamboo
++
++
Continuum
++
++
Cruisecontrol
++
++
Hudson
++
++
TeamCity
++
++
12
Más información consultar http://www.jetbrains.com/teamcity/
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/
13
www.osgg.net
Página 13 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
Construcciones en
paralelo
Construcciones
distribuidas
Forzar
construcción de
forma manual
Planificación de
construcciones
AnthillPro
++
Bamboo
++
Continuum
++
Cruisecontrol
++
Hudson
++
TeamCity
++
++
P
P
D
++
++
++
++
++
++
++
++
++
++
++
++
++
++
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
Autenticación de
usuarios
Integración LDAP
Kerberos
SSO
AnthillPro
++
Bamboo
++
Continuum
++
Cruisecontrol
++
Hudson
limitada
TeamCity
++
++
++
++
++
-++ via
crowd14
P
---
----
----
++
---
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
Email
IRC
Jabber
RSS
Yahoo messenger
Msn messenger
AnthillPro
++
-++
++
++
--
Bamboo
++
-++
++
---
Continuum
++
++
++
P
P
++
Cruisecontrol
++
-++
++
---
Hudson
++
++
++
++
---
TeamCity
++
-++
++
---
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/
www.osgg.net
Página 14 de 17
Ver cambios
Agregar nuevos
proyectos
Clonar proyectos
Borrar proyectos
Modificar
proyectos
Eliminación de
construcciones
Pausar
construcciones
Acceso a
construcción de
artefactos
Gráficos con
históricos
Soporte multiproyectos
Vistas multiproyectos
++
++
++
++
++
++
-D
++
++
++
++
++
++
++
++
++
++
-++
++
-D
D
++
++
++
++
++
++
++
--
P
++
++
++
++
++
P
++
--
++
++
++
++
++
++
++
++
++
P
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
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
Shell / Scripts de
comandos
Ant
Maven
AnthillPro
++
Bamboo
--
Continuum
++
Cruisecontrol
++
Hudson
++
TeamCity
++
++
++
++
++
++
++
++
++
++
++
++
++
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
Bugzilla
Jira
JUnit result
rendering
Eclipse plugin
AnthillPro
++
++
++
Bamboo
-++
++
Continuum
--P
Cruisecontrol
--++
Hudson
-++
++
TeamCity
++
++
++
++
++
P
++
++
++
www.osgg.net
Página 15 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
Instalador de
Windows
Distribución
auto contenida
Plataforma de
ejecución
Plataforma de
proyecto (Lo
que puede
construir)
Herramienta
de
construcción
preferente
Sin necesidad
de modificar
scripts de
construcción
Configuración
de ficheros de
texto
AnthillPro
++
Bamboo
++
Continuum
P
Cruisecontrol
--
Hudson
++
TeamCity
++
--
++
++
++
++
++
JVM
JVM
JVM
JVM
JVM
JVM
Cualquier
lenguaje
Java+Ant/Maven
Cualquier
lenguaje
Java+Ant/Maven
Cualquier
lenguaje
Cualquier
lenguaje
Cualquiera
Cualquiera
Maven
Ant, Maven
Cualquiera
Cualquiera
++
++
++
++
++
++
++, 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
www.osgg.net
Página 16 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.
www.osgg.net
Página 17 de 17