Nueva canción: Java EE 5!

Roumen ha publicado una canción sobre Java EE 5. A little bit of injection in your life!

(via Erik)

Ladies and gentlemen, this is Java EE 5!

One, two, three, four, five
There's a technology I use day and night
For my application with a web frontend
They told me to use .Net
But I really don´t wanna

So many bugs I fixed last week.
My code is neat and talk is a cheap
I like Glassfish, JSF, persistence API
And as I continue you know they´re gettin´ sweeter

So what can I do I really beg you my Lord
To me codin' it´s just like a sport
All the bad code from the past, let me dump it
Please set in the trumpet

A little bit of injection in my life
A little bit of persistence by my side
A little bit of NetBeans is all I need
A little bit of EJB's what I see
A little bit of standards in the sun
A little bit of XML all night long
A little bit web services here I am
A little bit of code makes me real man

This is Java EE 5!

Jump up and down and move your code around
Shake your head to the sound bury bad code under ground
Move one step left and one step right
One to the front and one to the side
Refactor it once and refactor it twice
If it looks like this you're doin´ it right

A little bit of injection in my life
A little bit of persistence by my side
A little bit of NetBeans is all I need
A little bit of EJB's is what I see
A little bit of standards in the sun
A little bit of XML all night long
A little bit web services here I am
A little bit of code makes me real man

This is Java EE 5!

BeanFlow, lightweight workflows de la forma fácil

Utilizar BPEL para resolver workflows es una forma de hacerlo, pero ciertamente no la mas fácil. BeanFlow pretende orquestar eventos encadenando métodos de beans y manteniendo la lógica en ellos.
Lo único que hay que hacer es definir una clase heredada de Workflow con enums (java 5) como posibles pasos del workflow e implementar un método por cada enum.

Ejemplo (de los fuentes de BeanFlow):

package org.apache.servicemix.beanflow;
public class SimpleWorkflow extends Workflow {

  public static enum Step {
    stepA, stepB, stepC, stop
  };

  public SimpleWorkflow() {
    super(Step.stepA);
  }

  // Workflow steps
  // -------------------------------------------------------------------------
  public Step stepA() {
    return Step.stepB;
  }
  
  public Step stepB() {
    return Step.stepC;
  }
  
  public Step stepC() {
    return Step.stop;
  }
}

En este ejemplo, el contructor define que cuando comienza el workflow se inicializa en el paso A (stepA), y en cada uno de los pasos (métodos que comenzan con "step" igual que el enum "Step"), se devuelve el siguiente paso a ejecutar.

Este sencillo workflow puede ser lanzado luego instanciándolo y ejecutando el método "start":

package org.apache.servicemix.beanflow;

import org.apache.servicemix.beanflow.util.ActivityTestSupport;

public class SimpleWorkflowTest extends ActivityTestSupport {

  public void testWorkflow() throws Exception {
    SimpleWorkflow workflow = new SimpleWorkflow();
    workflow.start();

    Thread.sleep(2000);

    assertStopped(workflow);
  }
}

Por supuesto no todo termina allí, ya que BeanFlow provee mecanismos para hacer workflows paralelos, joins, detener worflows iniciados o saber el estado de un workflow.
Y todo en menos de 30 clases.

Spring del.icio.us

Aquellos que alguna vez caen por este blog, saben que Spring está entre mis preferidos a la hora de programar. Es por ello que quiero compartir mi lista de artículos sobre el tema:

http://del.icio.us/ncornag/spring

y su feed rss:

http://del.icio.us/rss/ncornag/spring

Proxies a DAOs para Spring e iBatis

DaoZero es una implementación mediante proxies de Spring y basado en iBatis para facilitar la comunicación con la base de datos mediante el patrón DAO.

Servicios declarativos de cache

En el artículo Declarative Caching Services for Spring, Alex Ruiz nos muestra como utilizar diferentes proveedores de cache con los Spring Modules de Spring 2.0

Hibernate Annotations

Introducción

Uno de los problemas mas frecuentes al trabajar con Hibernate, es la generación de los mapping files. (archivos .hbm.xml). Hay varias opciones para generarlos, desde escribirlos a mano hasta usar varios de los generadores automáticos. La manera mas usual es usar Xdoclet, algo que a mi particularmente nunca me gustó, ya que agrega un paso mas a la compilación, obligándome a usar Ant todo el tiempo, y no es algo que me parezca muy productivo. Además Xdoclet 1 no es del todo compatible con Hibernate 3 (la solución sería usar Xdoclet2, pero yo nunca lo probé). Hay otras opciones también, como algunos plugins para Eclipse, pero tampoco me terminaron de convencer.

Presentando Hibernate Annotations

Hibernate Annotations es un proyecto paralelo de Hibernate, a fin de proveer compatibilidad con la nueva especificación de EJB3.
Junto con otro proyecto, HibernateEntityManager , la gente de Hibernate planea tener un framework 100% compatible con EJB3, sin necesidad de un application server.
La especificación de EJB3 aún no esta completa, pero esta muy avanzada, y es de esperar que si hay algunos cambios, sean menores. Igualmente no es necesario usar EntityManager para aprovechar las anotaciones.
EJB3, aunque inspirado en Hibernate, no provee toda la funcionalidad de éste, por lo que Hibernate Annotations ofrece unas extensiones (en el paquete hibernate-annotations.jar) para lograr la misma funcionalidad que con los mappings files, pero es de suponer que esta compatibilidad sera alcanzada recién en la versión definitiva (actualmente esta disponible la 3.1beta8).
Además, Hibernate Annotations es compatible con los mappings, por lo que ambos pueden convivir en una misma aplicación, de forma que se puede ir migrando una aplicación de a poco (por supuesto cada clase individual debe estar mapeada de una u otra manera, no se pueden combinar los dos estilos en una misma clase).

Para los que no estén familiarizados con java annotations, les recomiendo que lean algún artículo en internet, como por ejemplo este.

Cuando se usa Hibernate Annotations, no significa que Hibernate va a crear los mapping files por sí mismo, y luego los va a leer y procesar. Hibernate toma las clases que tiene declaradas en el hibernate.cfg.xml, y lee las anotaciones directamente desde los archivos .class, generando así los mappings en memora en tiempo de ejecución.

Una gran ventaja de usar Hibernate Annotations es que todos los IDE modernos (Eclipse, IntelliJ, etc.), tienen soporte para anotaciones en el editor. Esto significa que es posible usar todas las funciones de los IDE (auto completar, refactoring, etc.) también con las anotaciones.

Por otra parte, todos los atributos de las anotaciones son tipos java (String, int, boolean, etc.), con lo que se reduce aún mas la posibilidad de errores.

Instalación

Es tan simple como agregar los jar (hibernate-annotations.jar y ejb3-persistence.jar) provistos en la distribución al classpath. También, donde sea que se defina el sessionFactory, hay que usar la clase AnnotationConfiguration en vez de Configuration (si se esta usando Spring, se debe usar AnnotationSessionFactoryBean en lugar de LocalSessionFactoryBean).
Por ultimo, en el archivo hibernate.cfg.xml hay que indicar que clases van a ser persistentes, de manera similar a cuando definíamos los mappings:
<mapping class="test.Cliente"/>

Hibernate Annotations requiere Hibernate 3.1.1 o superior.

Breve introducción a las Hibernate Annotations

Esto no pretende ser ni un tutorial ni una referencia completa a Hibernate Annotations, sino simplemente un pantallazo sobre su utilización. Para mas información y detalles, consulten la documentación en el sitio de Hibernate.
Otra de las grandes ventajas de usar annotations, es que podemos ir escribiendo los mapeos a medida que vamos escribiendo nuestra clase. Además, como la especificación provee defaults para casi todas las annotations, en principio hacer que una clase sea persistente es tan simple como agregar una sola anotación:

@Entity
public class Persona {
...
public String getNombre() {
 ...
}
}

En este caso, la clase mapearia a una tabla en la BD llamada cliente, con un campo de tipo texto llamado nombre.
Por supuesto nunca tendremos tanta suerte, y siempre será necesario agregar algo mas para que las clases mapeen correctamente a la tablas.

Por ejemplo, para que la tabla se llame “PERSONAS”, podemos agregar la siguiente anotación a la clase:

@Table(name=”PERSONAS”)

Todas la propiedades de la clase que tengan un getter van a ser persistentes por default (excepto las marcadas con static o transient), lo que equivaldría a usar la anotación @Basic;

@Basic
public Date getFechaDeNacimiento() {
...
}

Si queremos que algún campo no sea persistente, lo marcamos con @Transient:

@Transient
public int getEdad() {
 ...
}

Finalmente, si queremos cambiar alguna de las características de la columna en la BD, podemos usar @Column:

@Column(name=”documento”, unique=true, nullable=false, length=10)
public String getNroDocumento() {
 ...
}

Veamos ahora como mapear algunas asociaciones, empezando por la mas simple @OneToOne:

@Entity
public Class Persona {

 @OneToOne(cascade=CascadeType.All)
 public Direccion getDireccion() {
  ...
 }
}

@Entity
public Class Direccion {
 ...
}

Noten como puede especificar el tipo de cascada que quiero. La columna que relacione las dos tablas en la BD se llamará por default direccion_id, en base a la concatenación del nombre de la relación mas underscore, mas el nombre de la primary key de la clase contenida. En caso de querer usar otro nombre de columna, se puede usar @JoinColumn.
Esta es una asociación unidireccional, si quisiera que fuera bidireccional, agrego en la clase Direccion:

@OneToOne(mappedBy=”direccion”)
public Persona getPersona() {
 ...
}

En vez de repetir el mapeo, simplemente lo especificamos con mappedBy, Hibernate busca el mapeo que se hizo en otro extremo de la asociación y sabe que es la asociación inversa.

Si una empresa tiene muchas personas, uso @ManyToOne:

@Entity
public Class Persona {

 @ManyToOne()
 @JoinColumn(name=”empresa_id”)
 public Empresa getEmpresa() {
  ...
 }
}

@Entity
public Class Empresa {
 ...
}

Para el caso de colecciones (por ejemplo si una persona tiene mas de una dirección), se usa @OneToMany/@ManyToOne o @ManyToMany:

@Entity
public Class Persona {

 @OneToMany(mappedBy=”persona”)
 public List<Direccion> getDirecciones() {
  ...
 }
}

@Entity
public Class Direccion {

 @ManyToOne
 public Persona getPersona() {
  ...
 }
}

Si usamos colecciones genéricas, Hibernate deduce cual es el otro extremo de la asociación y no es necesario indicarlo. En el caso que no usemos genéricas, o bien usemos interfaces, debemos indicar explícitamente hacia adonde apunta la asociación mediante el atributo targetEntity.

Desventajas de Hibernate Annotations

• La especificación no es definitiva: esto implica que aun puede haber cambios a las anotaciones, y en caso de que eso suceda, habrá que modificarlas en nuestras clases. Igualmente, creo que a esta altura, los cambios serian mínimos y no costaría mucho realizarlos.
  
• Requiere JVM 1.5: Las anotaciones es una característica del JDK 1.5. Esto no es un problema en un proyecto nuevo, pero si se quiere migrar código preexistente, puede que instalar JVM 1.5 en un entorno de producción sea un problema y no se pueda realizar fácilmente.
  
• No todas las posibilidades de Hibernate están soportadas: Hay algunos mapeos que se pueden hacer en los mapping files que no se pueden hacer con anotaciones (por ejemplo ciertos mapeos con Maps, o OneToMany/ManyToOne bidireccional con una tabla intermedia), pero esto es probablemente una situacion temporaria hasta que haya una versióndefinitiva de Hibernate Annotations (la gente de Hibernate apunta a que sea 100% compatible con mapping files).
  

Conclusión

Hibernate Annotations es una excelente adición a Hibernate, y si no tienen problemas con las desventajas enunciadas anteriormente, en mi opinión es el camino a seguir.

Particularmente acabo de migrar una aplicación mediana (30 entidades) a Hibernate Annotations con un excelente resultado. Además, trabajar con anotaciones me resultó muy cómodo, mas fácil y mas intuitivo que con los mapping files o que con Xdoclet.

Performance Testing con JUnitPerf

Una forma muy recomendable de probar la performance de nuestra aplicación es comprobar la performance de los mismos componentes a los cuales les generamos un test unitario (generalmente con JUnit). Si además estas pruebas son también junits, podremos agregarlas al conjunto de pruebas que hacemos continuamente en nuestra aplicación, ya sea manualmente al desarrollar o mediante un continuous build server (por ejemplo CruiseControl).
Todo esto lo podremos lograr con JUnitPerf, una colección de decoradores para medir la performance de tests JUnit.

Por ejemplo, si tenemos un JUnit SimpleTest con el método testAnything:

public class SimpleTest extends TestCase {
    ...
    public void testAnything() throws Exception {
        ...
    }
}

podemos hacer una clase de test que pruebe la performance del método testAnything creando un nuevo JUnit y utilizando los decoradores de JUnitPerf:

public class SimpleResponseTimeTest {
    public static Test suite() {
        long maxTime = 500;
        Test test = new SimpleTest("testAnything");
        Test timedTest = new TimedTest(test, maxTime);
        return timedTest; 
    }
    public static void main(String args[]) {
        junit.textui.TestRunner.run(suite());
    }
}

En este caso el test fallará si dura mas de 0,5 segundos.

También podemos medir la performance simulando una carga de usuarios concurrentes, como en este ejemplo:

public class SimpleLoadTest {
    public static Test suite() {
        long maxTime = 500;
        int concurrentUsers = 5;
        Test test = new SimpleTest("testAnything");
        Test timedTest = new TimedTest(test, maxTime);
        Test loadTest = new LoadTest(timedTest, concurrentUsers);
        return loadTest;
    }
    public static void main(String args[]) {
        junit.textui.TestRunner.run(suite());
    }
}

A las clases LoadTest y TimerTest se le puede pasar también una instancia de RepeatedTest, para medir no sólo una ejecución del test sinó varias, por ejemplo:

public class SimpleLoadTest {
    public static Test suite() {
        int users = 10;
        int iterations = 20;
        Timer timer = new ConstantTimer(500);
        Test test = new SimpleTest("testAnything");
        Test repeatedTest = new RepeatedTest(test, iterations);
        Test loadTest = new LoadTest(repeatedTest, users, timer);
        return loadTest;
    }
    public static void main(String args[]) {
        junit.textui.TestRunner.run(suite());
    }
}

Para mas opciones sobre la herramienta, no queda mas que visitar la web de JUnitPerf, o este otro artículo: Continuous Performance Testing With JUnitPerf.