Desarrollo Ágil en J2EE con herramientas

OpenSource

Jose Marı́a Alvarez Rodriguez

Resumen En este artı́culo se introducirán distintas herramientas y tec-

nologı́as OpenSource que pueden ser utilizadas en una arquitectura J2EE
para permitir un desarrollo ágil y eficaz.

1. Introducción

En primer lugar, cabe justificar el tı́tulo de la ponencia para situarnos en el

contexto en el que vamos a actuar con las distintas tecnologı́as y herramientas.

1.1. Desarrollo Ágil

Se suele utilizar esta denominación a un modelo de desarrollo de software

que propone una serie de buenas prácticas o guı́a a utilizar en el desarrollo de
un producto software, estas prácticas, también están estrechamente ligadas con
eXtreme Programming, diseño de patrones, refactoring,etc., y por lo tanto con
autores referentes como Kent Beck y Martin Fowler.
Entre estas buenas prácticas cabe destacar:

Satisfacer al cliente con entregas del producto cada poco tiempo, facilitando
ası́ la integración del producto y la calidad del mismo.
Un cambio de requisitos del cliente no debe suponer un problema en el
desarrollo.
Fijar la entrega de tareas en un plazo de tiempo determinado, dos semanas,
dos meses,etc.
Comunicación continua entre clientes y desarrolladores.
Las reuniones se deben realizar en persona para facilitar la comunicación,
esta es la mejor manera para extraer la información necesaria para realizar
un desarrollo de acuerdo con las expectativas del cliente.
La primera medida de progreso es el software ya realizado.
Los procesos ágiles promueven la supervivencia del desarrollo, debe existir
buen ambiente entre clientes, desarrolladores y sponsors.
La continua atención a calidad técnica y un buen diseño permiten la agilidad
en el desarrollo.
Simplicidad.
etc.
 En definitiva, un proceso de desarrollo ágil implica que se debe integrar nues-
tra solución de forma continua satisfaciendo al cliente desde el primer momento,
consiguiendo productos ya totalmente funcionales desde el principio y lo más
importante, cambios en los requisitos del cliente no deberı́an afectar en exceso
al desarrollo que ya tenemos. El cliente necesita realimentación de lo que va exi-
giendo, por ello, contar con herramientas que favorezcan el desarrollo ágil parece
esencial.
Una vez situados en lo que podemos entender como desarrollo ágil vamos a
centrarnos en J2EE que es el entorno que vamos a fijar para la aplicación de estas
prácticas y por lo tanto las herramientas que presentemos serán de aplicación
para esta plataforma.

1.2. J2EE
J2EE es una plataforma creada por Sun en el año 1997, para el desarrollo
de aplicaciones distribuidas orientadas principalmente a la empresa. En el de-
sarrollo empresarial se ponen de manifiesto ciertos requisitos esenciales, no tan
crı́ticos en otras aplicaciones, que debe cumplir un desarrollo y que con J2EE po-
demos conseguir utilizando principalmente software libre, entre estos requisitos
se pueden nombrar los siguientes:
Escalabilidad, tanto horizontal como vertical
Fiabilidad
Facilidad de mantenimiento
Seguridad
Rendimiento
Extensibilidad
Flexibilidad
El objetivo final será conseguir la máxima productividad de los desarrolla-
dores, por ello el uso de herramientas que en esta plataforma nos permitan un
desarrollo ágil resultará relevante para el triunfo de nuestro producto.
El uso de J2EE nos ofrece múltiples ventajas:
Es una especificación que se puede utilizar en distinas plataformas.
Control por JCP, es un conjunto de grandes empresas que se encarga de la
correcta evolución de la plataforma, entre ellas podemos incluir: Sun, IBM,
Oracle, HP, etc.
Soluciones libres, ya que existen numerosos frameworks, y Apis Open Source
para el desarrollo en este entorno.
Asegurar la competencia, con productos de distintos precios y calidad.
No obstante, no son todo ventajas, también existen una serie de inconvenien-
tes:
Dependencia de un único lenguaje.
Complejidad que dificulta su adopción por los desarrolladores menos expe-
rimentados.
 Muchos modelos de desarrollo, frameworks y Apis que pueden confudir a
nuestros desarrolladores.
Hay que distinguir entre los estándares de iure y de facto.
En concreto, podemos dividir la definición de J2EE en dos partes:
JSR: Java Specification Request, sirve para solicitar que una tecnologı́a sea
incluı́da en la especificación de J2EE, se presenta la propuesta y queda a
expensas de la aprobación, si se aprueba debe quedar totalmente definida y
el equipo encargado de su desarrollo además debe proporcionar un test de
compatibilidad y una implementación de referencia.
JCP: Java Community Process, Conjunto de empresas formando un organismo
que se encargan del control de J2EE, de esta manera se evita que pueda
ser criticada por pertenecer sólo a Sun. La forma de entrar es a través de
una cuota anual, no obstante presenta diferentes restricciones desde el punto
de vista del software libre (patentes, licencias propietarias y potestades su-
periores de Sun), a lo largo de distintas versiones fueron corregidas gracias
principalmente al impulso de Apache.
En conclusión, desde el punto de vista teórico J2EE es una especificación de
especificaciones para distintos conceptos: XML, Servicios Web, Ejb,etc. También
contamos con un conjunto de buenas prácticas o guı́as que se denominan J2EE
Blueprints.
Una vez que ya hemos establecido teóricamente la definición de J2EE, em-
pezaremos definiendo el modelo de capas que propone, con la posibilidad de
variación según la complejidad y las necesidades que tengamos, de todas formas
generalizando podemos realizar la siguiente separación de capas:
Cliente: Aquı́ se sitúan los distintos clientes de nuestra aplicación, normalmente
un interfaz de usuario.
Presentación: Contiene la lógica de interacción entre usuario y aplicación.
Controla la interacción entre usuario y lógica de negocio utilizando distintas
vistas.
Lógica de Negocio: Código que realiza las funcionalidades que ofrece nuestra
aplicación, aquı́ es dónde se pone de manifiesto la necesidad de fácil mante-
nimiento y extensibilidad.
Integración: Comunicación con otros subsistemas, como motores de bases de
datos, de reglas, etc. Es importante la necesidad de que en esta capa se
puedan añadir nuevas fuentes con cierta facilidad. Deberemos garantizar
acceso transparente a las fuentes de información, con el uso de por ejemplo
el patrón de diseño DAO (Data Access Object).
Sistemas de información: Son las fuentes de información: bases de datos, fi-
cheros, etc.
En los siguientes apartados veremos las necesidades, problemas y posibilida-
des de estas capas, para finalizar examinando las herramientas que nos permiten
el desarrollo de estas capas de manera sencilla y rápida, con el objetivo de obte-
ner la máxima productividad.
1.3. Herramientas OpenSource

Las crı́ticas sobre la plataforma Java en cuanto a su consideración de software

libre no ha impedido que hayan proliferado numerosos proyectos entorno a esta
plataforma que se han realizado con licencias puramente de software libre. La
mayorı́a de estos proyectos proporcionan herramientas con una amplia asentación
en el desarrollo de aplicaciones en J2EE.
No cabe duda, que en los dı́as que corren J2EE se ha convertido en el refe-
rente para el desarrollo empresarial, el uso de herramientas OpenSource reduce
increiblemente el tiempo de desarrollo de la aplicación proporcionando una gran
productividad.
Productos como JBoss han conseguido introducirse en el mercado de servi-
dores de aplicaciones, aunque todavı́a queda mucho mejorar, la tendencia hacia
al uso de herramientas y productos OS es creciente, por lo que afrontar un pro-
yecto asentando las bases en un conjunto de herramientas como Xdoclet, Ant,
Junit, etc. conseguirá aplicaciones de calidad en un menor tiempo, con lo que las
empresas se darán cuenta de las ventajas del desarrollo basado en herramientas
OpenSource, centrando esfuerzo y dinero en el desarrollo de aplicaciones ajusta-
das a las necesidades del cliente y no en la adquisición de software propietario.

2. Necesidades, Posibilidades y Problemas

2.1. Capa Cliente

En esta capa podemos encontranos con distintos tipos de cliente:

Aplicaciones de escritorio
Navegadores web
Aplicaciones para dispositivos móviles

La elección de nuestro tipo de cliente tiene caracter estratégico, si utiliza-

mos una aplicación de escritorio, ésta se encargará de la lógica de presentación
mientras que si utilizamos un navegador web promovemos la interoperabilidad
de multidispositivo y será el contenedor web de ocuparse de la presentación.
Una diferencia fundamental entre ambos casos viene dada por la comunica-
ción que se establece entre la presentación y la aplicación propiamente dicha, en
aplicaciones de escritorio normalmente se realizará a través de interfaces remo-
tos, mientras que en aplicaciones que estén del lado del servidor la comunicación
podrı́a ser local, teniendo al contenedor web y el servidor de aplicaciones en la
misma máquina.
Otro problema que podemos encontrar es el uso de terceras partes, en apli-
caciones de escritorio probablemente necesitemos instalar estas terceras partes,
mientras que si lo hacemos todo del lado del servidor ya irán incluidas, des-
preocupándonos ası́ de qué terceras partes deben situarse en cada uno de los
lados.
 Para aplicaciones dedicadas a dispositivos móviles podemos utilizar J2ME,
pero parece más conveniente desarrollar la parte del cliente para que sea vi-
sualizada a través de un navegador, creando ası́ una solución homogénea con
independencia de dispositivo.
También existen otras posibilidades para el cliente, ya que podrı́a ser por
ejemplo una aplicación creada mediante XUL (XML User Interface).

2.2. Capa Presentación

En esta capa, situaremos al encargado de controlar la generación de la vista de
nuestra aplicación. Deberá proveer de los componentes adecuados para obtener
datos del cliente y para solicitar a la capa de negocio las operaciones que ofrece
nuestra aplicación.
También suele ser frecuente realizar en esta capa funciones de validación de
datos, registro de actuaciones y gestión de sesión de usuarios.
El estándar establecido para esta capa es el patrón de diseño arquitectónico
MVC (Model, View, Controller), existen distintos frameworks que implementan
este patrón definiendo las distintas partes:
Modelo: Componente en el cual se almacenará la información sobre los datos
obtenidos del cliente.
Vista: Representación visual de datos del modelo y de las operaciones realizadas
en la capa de negocio.
Controlador: Encargado de gestionar la interacción entre el modelo y las vis-
tas.
El uso de este patrón implica una serie de ventajas como: separación de res-
ponsabilidades, gestión de diferentes vistas, posibilidad de test de funcionalidad
separada.
Dependiendo de nuestra capa cliente tenemos diferentes frameworks y Apis
que implementan este patrón, aunque nos centraremos principalmente en fra-
meworks web dejando un poco a una lado las aplicaciones de escritorio (Swing)
y de dispositivos móviles.
Normalmente, utilizaremos un framework web que implemente MVC, no tie-
ne mucho sentido desarrollar nuestro propio framework ya que estamos perdiendo
tiempo en resolver un problema que no nos compete. Las posibilidades que tene-
mos en este sentido son varias como: Struts (Servlets y Jsp), Java Server Faces
(Creación de interfaces desde el servidor).
En la actualidad, está ampliamente asentado el framework Struts que imple-
menta el MVC, se base en conjunto de bibliotecas que proporcionan diferentes
servicios, no tan sólo modelo, vista y control, sino otras como validaciones de
datos introducidos por el usuario, composición de páginas mediante Tiles, tags
para generar la presentación, seguridad, posibilidad de uso de filtros, etc.
Resumiendo el controlador está implementado a través de un servlet Action-
Servlet, que utiliza distintos modelos a través de ActionForm’s y que genera
distintas vistas de presentación mediante composición de páginas Jsp (Tiles) y
tags (Taglibs) que generan contenido.
 El principal problema de este framework y en adelante de todas las tec-
nologı́as que comentemos, es la dificultad de configuración que conllevan para
desarrolladores noveles. La configuración normalmente se realiza a través de fi-
cheros XML, en el caso de Struts (struts-config.xml, tiles-defs.xml,etc.) en el cual
situamos la descripción de los action, global-forwards, forms, resources, etc., pe-
ro no tenemos manera de gestionarlos de manera automática, por lo que cada
vez que añadamos funcionalidad deberemos modificarlos a mano, esto resulta
un poco rudimentario y no demasiado profesional, además no se asegura que lo
hagamos bien y no tenemos modo de probarlo hasta que lo ejecutemos.
Los problemas por lo tanto, vienen desde el punto de vista de la configuración
de la tecnologı́a, pruebas y gestión/mantenimiento de ficheros de configuración.
Aunque esto pueda parecer un problema de resolución trivial, no es ası́, ya que
es conveniente situarse en un contexto en el cual tengamos múltiples acciones,
formularios, tags, etc. que no seria raro en cualquier aplicación empresarial de
cierta envergadura.
Surge la necesidad de herramientas que nos solucionen estos problemas de
forma transparente, ya que no tiene mucho sentido que para añadir una vista o
generar una nueva acción debamos no sólo programar, sino recorrer una serie de
ficheros (¿nos acordamos de todas las modificaciones a realizar y en qué ficheros?)
para poder utilizarla, realizar este proceso manualmente es bastante pesado y
ralentiza el desarrollo de la aplicación cliente y de la presentación.

2.3. Capa de Lógica de Negocio

Esta capa es el núcleo de nuestra aplicación, en el cual se representan nuestras
entidades, relaciones y reglas que implementarán nuestros procesos de negocio.
Las posibilidades que tenemos para implementar la lógica de negocio son
variadas:
Pojos: Estamos ante Plain Old Java ObjectS, ampliamente utilizados en ante-
riores aplicaciones que seguı́an una arquitectura cliente-servidor. Se trata de
objetos normales Java que contienen procesos de negocio o bien representan
entidades, esto implica que podemos incluirlos en la misma capa.
Las principales ventajas que conllevan el uso de esta alternativa, es que esto
objetos son muy ligeros, no añaden sobrecarga (seguridad, transacciones,
sesiones, etc.), y su implementación es muy sencilla y rápida (productividad
alta de desarrolladores), por otro lado no ofrecen tanta funcionalidad como
los Ejb’s (escalibilidad, seguridad,etc.), no obstante como siempre deberemos
situarnos en el contexto de nuestra aplicación, y si los Pojos ofrecen una
solución buena no existe inconveniente en utilizarlos.
Ejb’s : Es un componente que agrupa funcionalidades para una aplicación y
que puede ser desplegado en un servidor de aplicaciones.
La arquitectura que proponen los Ejb’s es complicada, y se escapa de los ob-
jetivos de este documento, por lo tanto simplemente haremos una descripción
somera de los tipos y su funcionamiento básico, para acabar definiendo pro-
blemas de alto nivel que encontramos en su creación, gestión y despliegue o
activación en un servidor de aplicaciones.
 Los tipos de Ejb que podemos utilizar son los siguientes:
Sesión-(Session Beans) con estado (Statefull) o sin estado (Stateless),
se utiliza para la implementación de lógica de negocio, se utilizan en
arquitecturas orientadas a servicios SOA. El tipo de estado depende de
si se guarda el estado de conexión entre el bean y las peticiones. Ej:
podrı́an guardar la sesión de un usuario o bien la podemos guardar en
el cliente con un objeto HttpSession.
Mensaje-(Message Driven Beans), se utilizan para servicios de mensa-
jerı́a, probablemente más conocidas como colas de mensajes.
Entidad-(Entity Beans) Bean Managed Persistence o Container Mana-
ged Persistence, dependiendo de si la persistencia de entidades es mane-
jada por el bean o por el contenedor, es decir, se encargan la persistencia
de las entidades de negocio, se utilizan en la capa de integración.
Sin entrar en más detalles, podemos ver los Ejb’s como componentes que
proporcionan unos servicios, que se encuentran en un servidor de aplicaciones
identificados por un determinado procedimiento y con los cuales nos podemos
comunicar a través de unos protocolos.
Los principales problemas que presenta el uso de Ejb’s vienen en general,
descritos por estos aspectos:
Solución compleja.
Es necesario definir un nombre y las operaciones que realizan para su
despliegue en un contenedor.
Se deben generar fachadas de acceso remoto y locales.
La activación de los Ejb’s varia de un contenedor a otro.
De nuevo nos encontramos ante una tecnologı́a que requiere una alta confi-
guración a través de ficheros XML, que puede variar y en la cual debemos
generar interfaces de acceso. Esto nos invita a pensar que hacerlo a mano
puede resultar muy costoso, por lo que disponer de una herramienta que nos
resuelva estos problemas con generación de código automático, en la cual
nosotros tan sólo guiemos la generación, agilizarı́a bastante el uso de esta
tecnologı́a.
También existe la posibilidad de ofrecer nuestros Ejb’s como servicios web,
tiene sentido sobre todo en los de Sesión y Mensaje, de esta manera ofertamos
el mismo servicio con dos vistas distintas, implementándolo sólo una vez sin
replicar código.
Servicios Web: Son servicios expuestos en una determinada dirección de In-
ternet, que ofrecen distintas funciones de nuestra aplicación a través del
protocolo SOAP. Los servicios web facilitan la interoperabilidad de aplica-
ciones desarrolladas en distintas plataformas como .Net o J2EE, es decir,
podemos tener programas cliente que utilicen los servicios web desarrollados
en plataformas que contengan un motor de SOAP.
Las funciones realizadas por un servicio web se describen a través de un
fichero XML con el lenguaje WSDL, esta descripción se puede realizar a
partir de nuestras interfaces de negocio o bien a mano para despues generar
las interfaces.
 De cualquier manera, es necesario herramientas que nos generen los stubs
(tuberı́as) para poder utilizar el servicio web, que no deja de ser un recurso
externo al cual podemos acceder a través un nombre (URL), estos stubs nos
permitirán conectarnos al servicio, y poder utilizarlo de manera transparente.
En el cliente, podremos realizar distintas funciones atacando un Ejb, Pojo o
un servicio web.
La importancia de los servicios web queda patente con el incipiente uso de ar-
quitectura orientadas a servicio (SOA) que proveen servicios con una funcio-
nalidad determinada y atómica, por lo tanto es fundamental poder exportar
nuestras funciones mediante servicios web, para que mediante coreografı́a
de servicios podamos realizar una aplicación basada en la reutilización de
recursos ya disponibles, sin perder tiempo en volver hacer algo que ya ha
realizado una determinada empresa. Todo ello implica que se deba poder
exportar funcionalidades de nuestra aplicación con cierta sencillez, sin que
ello requiera un esfuerzo extra para los desarrolladores, por ello en un en-
torno J2EE se puede utilizar Axis, motor de SOAP del proyecto Apache.
Normalmente los servidores de aplicación también ofrecen su propio motor
de SOAP.
Los problemas que encontramos en el uso de esta tecnologı́a son similiares a
los anteriores:
Ficheros de configuración en XML.
Generación de descriptores de los servicios en XML.
Ficheros de despliegue.
Uso de los servicios a través de interfaces que podrı́an ser automática-
mente generadas.

2.4. Capa de Integración

En esta capa, la principal preocupación viene determinada por la tecnologı́a
a utilizar para manejar la persistencia, en J2EE tenemos varias posibilidades:
Jdbc: Es una opción bastante sencilla y adoptada para manejar la persistencia,
se suele utilizar cuando hemos planteado en nuestra aplicación el uso Pojo’s
o Beans de entidad con persistencia manejada por el bean.
Se caracteriza por ser una opción muy ligera, además es bastante conocida
por muchos desarrolladores.
El problema viene cuando tenemos que acceder a los datos, que lo debemos
hacer de forma manual, pero no obstante este problema se puede solventar
con un buen diseño basado en el patrón DAO. De esta manera conseguiremos
acceso a datos de forma transparente independientemente de la fuente del
recurso.
Motores de persistencia: Frameworks de mapeo de objetos, son útiles y bas-
tante utilizados, pero de nuevo nos encontramos ante una nueva tecnologı́a
cuya adopción puede traer problemas con los desarrolladores.
La ventaja de estos sistemas reside en la posibilidad de definir el esquema de
persistencia mediante XML y por lo tanto puede ser procesado de manera
 automática, aunque la gestión de estos ficheros no es sencilla y puede resultar
problemática, si la realizamos manualmente, en el momento en el que la
aplicación crezca .
Uno de los motores utilizados, es Hibernate, aunque existen otros como Cas-
tor, TopLink, etc.
Entity Beans: BMP, la persistencia la maneja el Bean de entidad y es el desa-
rrollador quien implementa las operaciones CRUD (create, retrieve, update,
delete) de las entidades.
CMP, las operaciones CRUD son manejadas por el contenedor, se puede
configurar el contenedor para la carga, cacheado de entidades, etc., pero
debemos realizar esta configuración correctamente, para ello se dispone de
herramientas que favorecen la generación de código de estas operaciones
facilitando el desarrollo.

2.5. Capa de Sistemas de Información

Son las fuentes de información de nuestra aplicación, pueden ser variadas

dependiendo de su objetivo y antigüedad, podemos encontrarnos:

Servicios Web
Ficheros
Sistemas Sap

Esta capa pueden existir fuentes de información externas, el principal pro-

blema reside en la conexión a estas fuentes de una forma homogénea de ahı́ la
necesidad de una capa de integración.

2.6. Transversal

A lo largo de todas las capas surgen una serie de necesidades que se mantienen
constantes, entre ellas podemos nombrar las siguientes:

Necesidad de generación código de manera automática.

Gestión y mantenimiento de ficheros de configuración.
Sistemas de registro de las acciones realizadas.
Pruebas.
etc.

Estas necesidades nos obligan a realizar un diseño de la aplicación siguiendo

de la manera más correcta posible las especificaciones de J2EE y aplicando
técnicas, como patrones de diseño, para poder conseguir un modelo flexible,
escalable, extensible y que se pueda probar y trazar con cierta facilidad. De esta
manera podremos ampliar nuestra aplicación, servicios e información de manera
sencilla y rápida, consiguiendo el tiempo de desarrollo se centre en la calidad y no
en la depuración de errores por factores externos como ficheros de configuración
corruptos.
3. Herramientas a evaluación

3.1. Xdoclet

Xdoclet es un framework Java para la generación de código en las distintas

capas de nuestra aplicación. Es por definición extensible y se basa en el uso de
metadatos y atributos, que una vez que son procesados por las distintas tareas
que ofrece, generan código de forma automática.
La generación de código puede ser de dos tipos:

Pasiva: Se realiza una sóla vez y despues es el desarrollador el encargado de

mantenerlo. Esta opción por lo tanto no resulta tan atractiva en el desarrollo
de un proyecto ya que al final somos los desarrolladores de mantener y probar
el código, Xdoclet, en este sentido sólo nos genera esqueletos.
Activa: El código se genera siempre que se lo indiquemos y no es modificado
por el programador, esto favorece la integración y la separación entre código
generado y manual, de tal manera que podemos tener perfectamente definido
el lugar de nuestro código. El programador simplemente utiliza el código que
se genera, lógicamente la configuración del tipo de generación y el objetivo
de la misma son fijadas por el programador.

Como habı́amos comentado Xdoclet se base en el uso de metadatos mar-

cados a través de tags en nuestro código fuente para la generación de código
automático, los ámbitos de aplicación son diversos y con múltiples objetivos.
Los metadatos utilizados son emplazados en bloques de comentarios del tipo
Javadoc, no obstante existen una serie de consideraciones que es importante
conocer a la hora de usar los metadatos:

Los metadatos siempre se refieren a clases ya existentes, no podemos generar

código sobre código ya generado, bueno en realidad si se podrı́a pero no tiene
sentido.
Los metadatos siempre son relativos al código en el que se encuentran, es
decir, no tenemos por un lado las clases a procesar y por otro los metadatos
asociados.
Tanto los metadatos, tags y el código generado son legibles para ser leı́dos
por humanos, es decir, no se genera por ejemplo código tipo Yacc o Lex.
Los metadatos utilizados para una generación de código determinada, puede
ser utilizada para otra tarea, por ejemplo generar descriptores de Ejb’s e
interfaces locales y remotas del mismo conjunto de clases.

La generación de código de forma automática supone un adelanto impor-

tante, ya que existen plantillas para la creación de una serie de ficheros, parece
ineficiente hacerlo a mano, además del coste adicional que esto puede presen-
tar en el desarrollo tanto en tiempo como en dinero. Existen una serie de casos
genéricos en los cuales el código es repetido, la opción “cutre” serı́a hacer copiar
y pegar cambiando los nombres, pero esto es una chapuza si nos situamos en un
ambiente empresarial, los casos aludidos podrı́an ser los siguientes:
 Despliegue de componentes y ficheros de configuración, ejemplo ficheros de
configuración para Struts y despliegue de Ejb’s o Servicios Web en un servi-
dor de aplicaciones.
Sistemas construı́dos siguiendo un determinado modelo de negocio, todos
tendrán un determinado modo de nombrado, de registro,etc.
Aplicaciones multicapa, la forma correcta de comunicación entre capas es
a través de interfaces, una vez que definamos una, las demás deberán ser
iguales para los objetos que las utilicen, por lo que no tiene sentido crear el
mismo código una y otra vez con la única difencia del lado en el que se sitúa.
Componentes que hacen un uso intensivo de interfaces, tanto las interfaces
como las clases que las implementan siguen un determinado patrón de lla-
madas que se puede formalizar, un ejemplo claro se puede ver en los objetos
de delegación.

La decisión del uso de Xdoclet, siempre quedará en las manos del Jefe del
proyecto que será el encargado de decidir si merece la pena utilizar un tiempo
en la implantación de Xdoclet (como ir en moto) o bien seguir utilizando con-
figuraciones y generación de código manual (como ir en bicicleta), este tipo de
decisiones puede llevar al triunfo de una aplicación o no.
También es importante contemplar que la generación de código es una he-
rramienta potente, pero previamente a su uso resulta útil conocer como se harı́a
a mano, es decir generar el fichero de configuración de un conjunto de actions
Struts resulta muy pesado pero es conveniente conocer como se realiza para a
partir de ahı́ ya poder automatizar el proceso.
En nuestro caso de estudio de aplicaciones multicapa J2EE la generación de
código Xdoclet la podemos realizar en las siguientes partes:

Capa presentación y cliente: Genera ficheros de configuración de Struts, tag

libraries, servlets.
Capa de negocio: Descriptores e interfaces de Ejb’s. Descriptores de Servicios
Web.
Capa de integración: Ficheros de mapeo de objetos de negocio, por ejemplo
para Hibernate.
Otros: Son múltiples las opciones dependiendo de la tecnologı́a, servidor de
aplicaciones, etc.

En conclusión, Xdoclet es una herramienta muy potente que fomenta al máxi-

mo el desarrollo ágil y eficaz de aplicaciones, además podemos extender su fun-
cionalidad con nuestras propias plantillas (ficheros XDT) para generar código
a medida, si a todo esto le sumamos que la ejecución la realizamos a través de
tareas Ant, conseguimos un nı́vel de calidad muy importante en el desarrollo del
proyecto.
No obstante, no todo son ventajas, podemos realizarnos las siguientes pre-
guntas sobre el código generado:

Fiabilidad, sigue una serie de estándares y especificaciones muy estrictas, si

existen fallos probablemente sea por nuestra culpa.
 Test, el código se puede probar como si lo hubieramos creado nosotros mis-
mos.
Como buena práctica podemos indicar que el código generado se debe situar
en un directorio creado para esa función, no es conveniente utilizar los mismos
directorios para código generado que para código automático, por la naturaleza
dinámica del código generado.

3.2. Axis
Axis es un motor de SOAP para aplicaciones Java realizado por Apache, que
nos da el soporte necesario para el desarrollo de servicios web en la plataforma
J2EE tanto desde el punto de vista del cliente como del servidor.
Además, en sus últimas versiones Axis incluye una serie de caracterı́sticas
que hacen más atractivo su uso:
Mini servidor stand alone.
Servlet de administración de los servicios web desplegados.
Soporte para WSDL.
Generador de clases Java a partir de ficheros WSDL.
Ejemplos.
Monitor TCP/IP.
Integración mediante tareas Ant.
Las ventajas de uso de Axis para la generación de servicios se manifiestan en
los siguientes puntos:
Utilización de parsers Sax para el procesamiento de XML, incrementando
por tanto la velocidad.
Flexibilidad, el desarrollador puede “pinchar” el funcionamiento del servicio
web en distintas partes.
Estabilidad, compatibilidad hacia atrás con versiones anteriores.
Framework orientado a la reutilización, permite el uso de componentes ya
creados, como pueden ser Ejb’s para ofrecer funcionalidad tipo servicio web.
Framework para el transporte sobre TCP/IP y con distintos protocolos como
SMTP, FTP, orientado a mensajes, etc.
Invocación dinámica de servicios web.
Todas estas caracterı́sticas convierten a Axis en el referente para para el
desarrollo de servicios web en J2EE, no obstante, normalmente los servidores de
aplicaciones suelen disponer de sus propias herramientas para el desarrollo de
servicios web, pero en algunos casos pueden tener problemas de integración con
clientes que no sean puramente Java.
Existen también una serie de inconvenientes en el uso de Axis, que se refieren
principalemente al mapeo de objetos, es necesario que realicemos el mapeo ma-
nualmente de los objetos (no simples) que formen parte del servicio, en los arrays
se debe indicar manualmente como se realiza la serialización y deserialización, el
transporte de algunos tipos como Document no es trivial y no se puede hacer de
manera directa, las Collection de Java tampoco se pueden enviar, esto se debe
a que es un tipo abstracto, de todas formas el uso de Axis está justificado por
sus ventajas.
Axis, se configura a través de una serie de ficheros XML que con la ayuda de
Xdoclet podemos realizar sin mayor problema.
La importancia de Axis queda de manifiesto en el momento actual de la arqui-
tectura software (a nı́vel industrial), en la cual se apuesta por una arquitectura
orientada a servicios (SOA-no sólo son servicios web, servicios multimedia,etc.),
por ello contar en nuestro desarrollo de una herramienta que permita exportar
la funcionalidad de nuestra aplicación a través de servicios web sin tener por ello
un extra de esfuerzo, resulta una decisión estratégica importante que fomenta la
interoperabilidad base de SOA.

3.3. Ant

Ant es una herramienta Java utilizada para la gestión de proyectos de una

manera automatizada, es muy útil debido a la necesidad de herramientas de
desarrollo que gestionen los aspectos relacionados con:

Compilación de los programas, gestión del classpath.

Automatización de las pruebas.
Generación de documentación.
Ejecución de tareas de terceros.

En muchos casos existen entornos de desarrollo integrados que nos ofrecen

estas posibilidades, pero a cambio de tiempo y dinero que en la mayorı́a de los
casos no hay ni lo uno ni lo otro.
Se podrı́a decir que es una herramienta “make” pero con un sinfı́n más de
opciones, en la cual se han buscado tres factores:

Simplicidad
Entendible para los nuevos usuarios
Extensible

El uso de la utilización de Ant está enclavado dentro del modelo de proceso

software denominado Extreme programming.
Ant se ejecuta a través de un fichero XML (build.xml)en el cual indicamos
las distintas acciones u objetivos que hay que realizar para construir el proyecto.
La estructura de este fichero es la siguiente:

Project: Define una serie de objetivos de alto nivel, uno sólo por script.
Property: De esta forma definimos distintas variables que podemos utilizar en
todo el fichero de construcción.
Target: Tareas a ejecutar para conseguir un objetivo, como puede ser la gene-
ración de documentación, varias por script.
Task: Cada paso de ejecución.
 Tareas incorporadas
Ant Echo AntCall Exec
AntStructure ExecOn Apply Fail
Available Filter Chmod FixCRLF
Copy GenKey Cvs Get
Delete Gunzip Gzip Property
Jar Replace Java Rmic
Javac SignJar Javadoc Sql
Mail Style Mkdir Tar
Move Taskdef Patch Touch
Tstamp Unjar Untar Unwar
Unzip Uptodate War Zip
Tareas opcionales
Antlr JunitReport Cab Native2Ascii
Depend PropertyFile FTP RenameExtension
JavaCC Script Javah Sound
JJTree StyleBook Jlink Telnet
Junit Test
Cuadro 1. Tareas Ant.

A continuación se presenta una tabla con algunas de las tareas que nos per-
mite ejecutar Ant:
Es conveniente utilizar Ant por razones como las siguientes:

Sintaxis XML.
Estilo declarativo.
Rapidez de ejecución.
Conjunción de varias tareas.
Posibilidad de múltiples tareas y comandos.
Creación de nuestras propias tareas.
Script de despliegue de las aplicaciones desarrolladas.
Gestión del classpath.
Multiplataforma, basada en Java.
Rapidez.
Compilación, empaquetamiento y despliegue de aplicaciones y componentes
Ejb.

La principal desventaja, como siempre llega con la necesidad de tener que

aprender nuevas cosas y tener interés por utilizar herramientas libres y amplia-
mente configurables.
Para la gestión de proyectos Java de cierta envergadura de manera seria
y profesional es conveniente utilizar herramientas como Ant, que nos facilitan
muchas tareas que a veces requieren bastante trabajo, de ahı́ que la elección
de Ant como herramienta de gestión de proyectos J2EE queda perfectamente
justificada. Además, las herramientas utilizadas en J2EE (Xdoclet, Junit, Axis,
etc.) suelen incluir tareas de Ant integradas, y este comportamiento es habitual
en las terceras partes que podamos utilizar.
Ant no es la única herramienta de este estilo, sino que existen otras como:
Jam, Amber o Cons. También existen herramientas de nivel superior que utilizan
internamente Ant, como es Maven.
Una buena práctica en el uso de Ant es la de configurar distintas propiedades
a través de ficheros properties de Java, de esta manera conseguimos desacoplar
los valores de las propiedades del script que las utiliza, de la misma manera
podemos definir inclusiones de un script en otros modularizando la construcción
de las distintas partes de nuestra aplicación.

3.4. Log4j

Log4j es un herramienta Java que permite el registro y traza de las acciones

realizadas en todas las partes de la aplicación.
La necesidad de uso de Log4j parte por la complejidad inherente de las aplica-
ciones J2EE, caracterizadas por distintos hilos de ejecución, múltiples usuarios,
imposibilidad de imprimir el resultado de la traza,etc.
Esta herramienta permite una gestión de la aplicación proponiendo para ello
una serie de nı́veles de registro, jerarquizados:

Debug: Mensajes de depuración sólo para etapa de desarrollo.

Info: Mensajes de información de paso por distintas partes de la aplicación.
Warn: Alertas no crı́ticas en la aplicación.
Error: Errores producidos que interesa guardar, debidos especialmente a con-
figuraciones erróneas.
Fatal: Errores crı́ticos que pueden provocar el fallo del sistema.

La idea de niveles parte de configurar los mensajes de nuestra aplicación depen-

diendo del estado en el que se encuentre: desarrollo, depuración, producción, de
esta manera fijaremos un determinado nivel de traza y todos los mensajes lanza-
dos por niveles inferiores serán registrados: Ej: Nivel Debug, se registran todos
los mensajes de todos los niveles. Además existen otros niveles como Level.All o
Level.Off que des/habilitan todos los registros.
La configuración de log4j se realiza a través de ficheros de propiedades (log4j.properties)
o bien a través de un fichero Xml (log4j.xml), dependiendo de la parte a trazar
se utilizará uno u otro.
Log4j cuenta con tres elementos básicos:

Appenders: Son las distintas salidas a las que podemos enviar los mensajes
generados, podemos encontrar una serie de ellos ya definidos para la consola,
ficheros de texto, formato HTML, o bien direccionarlos a un servidor de log.
En cualquier caso, podemos configurar la salida, a través de layouts, con la
información que deseamos como: hora, mensaje, quién lo lanza, etc.
Layouts: Son los encargados de formatear los mensajes. Tenemos layouts para
Html o XML.
Loggers: Se encargan de generar los mensajes, a través de la configuración
definimos como se tratarán los mensajes de una clase o paquete, es decir su
layout y appender, con solicitar para una determinada un logger (instancia
de Logger) ya podremos utilizar la biblioteca de registro.

Como podemos ver, se pueden combinar distintos appenders, layouts y di-

ferentes loggers dependiendo de la clase o paquete en el que nos encontramos,
estas posibilidades resultan de gran utilidad para ası́ poder liberarnos de los
incordiosos “System.out”.
Una ventaja adicional de esta biblioteca de registro es la posibilidad de de-
finir nuestros propios appenders. El uso de esta biblioteca está perfectamente
demostrado, ya que la mayorı́a de proyectos de Apache y muchas aplicaciones lo
utilizan.

3.5. Junit

Junit es una herramienta Java para la realización de pruebas unitarias de

programas, se trata de realizar test de pruebas que se ejecutan realizando un
registro de los resultados obtenidos.
De nuevo estamos ante una herramienta Open Source y enclavados dentro de
patrones de diseño y Extreme Programming, el gran éxito de esta herramienta
se debe a su facilidad de uso en comparación con el trabajo que realiza.
Aunque en principio el código de Junit deberı́a ser sencillo esta diseñado para
poder ser ampliado y ha sido ideado utilizando diversos patrones de diseño de
una complejidad en algunos casos elevada.
Para poder hacer que las pruebas resulten en cierta medida sencillas está di-
señado por una jerarquı́a de clases relacionadas entre sı́, lo que permite que se
puedan realizar pruebas de los distintos métodos de una clase.
En conclusión, nos encontramos ante un herramienta poderosa para la realiza-
ción de pruebas y cuyo uso no merece una pericia especial por parte del usuario,
con esta herramienta y Ant podemos realizar una combinación con múltiples
beneficios a nuestros proyectos en todos los sentidos.
La realización de las pruebas de los programas normalmente resultan costo-
sas temporalmente y muchas veces no se guardan ni se documentan, con esta
herramienta conseguimos que la prueba de programas rebaje su coste además de
liberarnos de una parte de la construcción de programas que en muchos casos
resulta pesada y poco eficiente.
Por todo esto, con Junit se sube un nivel de calidad en el test de los progra-
mas, entendiendo por calidad en el test como una mejora en la realización de
las pruebas en cuanto a casos contemplados, número de pruebas, registro de las
pruebas y facilidad de uso.
Las ventajas como ha quedado patente son las siguientes:

Facilidad de uso.
Creación de conjuntos de pruebas para una clase.
Combinación con otras herramientas como Ant.
 Código libre.
Bien documentado.
Pruebas a diferentes niveles y capas.
Extensible.
Además su combinación con Ant hace que el desarrollo de proyectos J2EE
se haga más liviano, rápido y eficiente, asegurando además un cierto nivel de
calidad.
Existen extensiones de Junit que nos permiten realizar pruebas en las distin-
tas capas de nuestra aplicación, siempre y cuando hayamos seguido un diseño
apropiado, de esta manera existen frameworks basados en Junit para probar:
XmlUnit, para documentos XML.
DbUnit, para probar el estado de la base de datos.
Mockrunner.
MockEjb.
EasyMock, para generar las clases que basadas en nuestras interfaces de
negocio nos permitan probar los servicios y funcionalidad de la aplicación.
Cactus, para pruebas unitarias del lado del servidor.
HttpUnit, para peticiones a la aplicación como cliente.
StrutsTestCase, para actions de Struts (mappings, form bean,etc).
JunitPerf, para objetos decorator.
JWebUnit, para probar la navegación de la aplicación.

3.6. A tener en cuenta

Además de estas herramientas existen muchas otras, dependiento de su ámbi-
to de aplicación, también hay frameworks integrados que ya incluyen todo lo
necesario para comenzar un desarrollo en J2EE. Entre estas herramientas y fra-
meworks podemos citar los siguientes:
Spring Framework, ya incluye una gran parte de las herramientas necesarias
para J2EE.
Hibernate, motor de mapeo de objetos.
Maven, gestor de proyectos de alto nivel.
JSTL, biblioteca de tags para presentación.
Xerces, parsers de XML utilizados internamente por múltiples herramientas.
Xalan, motor de XSLT.
Jasper Reports, generación de informes.
Portlets, para la generación de portales corporativos.
Commons, conjunto de utilidades como ftp, wget, etc.
También cabe comentar los servidores de aplicaciones más utilizados, por
desgracia no todos son libres, es más cuestan bastante dinero:
Jboss, libre.
JoNas, libre.
Oc4j de Oracle.
 WebLogic de Bea.
WebSphere de Ibm.
Existen frameworks generales para la generación de código basada en mode-
los siguiendo especificaciones como MDA (Model Driven Arquitecture) o MDD
(Model Driven Development), como AndroMDA que generan código a partir
de un determinado modelo para las distintas capas, aunque esto se escapa de
los objetivos de este artı́culo conviene mencionarlo para tener consciencia en el
ámbito del desarrollo ágil.

3.7. Caracterı́sticas comunes

A lo largo de las páginas anteriores hemos comentado las caracterı́sticas teóri-
cas de algunas de las herramientas de uso general en desarrollos J2EE que po-
tencian un desarrollo ágil y de calidad, se puede sacar factor común a algunas
de estas caracterı́sticas:
Configuración a través de ficheros XML.
Posibilidad de ejecución a través de tareas de Ant.
Extensibilidad.
La configuración se realiza añadiendo al classpath de la aplicación los ficheros
jar de cada herramienta.
Buena documentación.
Licencias tipo Lgpl, Apache Software Foundation, etc.

4. Conclusiones
Tras esta presentación teórica de algunas caracterı́sticas y herramientas uti-
lizadas en J2EE podemos decir que:
J2EE conlleva un desarrollo complejo.
Existen múltiples herramientas y tecnologı́as, tenemos que saber elegir aque-
llas que necesitemos, potenciando la productividad de nuestros desarrolla-
dores.
Necesidad de pruebas de las diferentes partes de la aplicación, para poder
asegurar cierta calidad.
Exportar nuestra funcionalidad con diferentes vistas.

Los beneficios que obtenemos unidos al desarrollo ágil, también son múltiples:
Potenziación del software libre.
Cualidades de J2EE: escalibilidad, flexibilidad,etc.
Interoperabilidad.
Centramos esfuerzo en el desarrollo y no en generar documentación para
productos obsoletos.
Seguridad.
Calidad del producto final.
Robustez.
Referencias
1. C. Bauer and G. King. Hibernate In Action. Manning, 2005.
2. S. Bayern. Jstl In Action. Manning, 2003.
3. J. C. Deepak Alur and D. Malks. Core J2EE Patterns. Prentice Hall, 2003.
4. N. Ford. Art of Java Web Development: Struts, Tapestry, Junit, Axis,... Manning,
2004.
5. D. M. Geary. Core J2EE Patterns. Prentice Hall, 2004.
6. E. Hatcher and S. Loughran. Java Development with Ant. Manning, 2003.
7. T. Husted et al. Struts In Action. Manning, 2003.
8. V. Massol and T. Husted. Junit In Action. Manning, 2004.
9. B. G. Sullins and M. B. Whipple. Ejb Cookbook. Manning, 2003.
10. C. Walls and N. Richards. Xdoclet In Action. Manning, 2004.