davidmarco.es

Feeds RSS

programacion@davidmarco.es (David Marco) — Thu, 01 Jul 2010 02:00:00 +0200

Como anuncié hace unos dias en el blog, he estado preparando un sistema de feeds RSS para que podáis seguir más facilmente la actividad de la web. He tenido que actualizar la aplicación Spring MVC con la que gestiono el blog para que permitiera la publicación de las entradas también en formato RSS, publicación que es llevada a cabo en última instancia a traves de una sencilla clase (menos de 25 lineas de código) escrita en Groovy. Podéis suscribiros al blog a traves de la url http://www.davidmarco.es/rss/blog.xml, o pinchando en el icono que encontrareis en la barra de direcciones de vuestro navegador. Por último, pero no por ello menos importante, quiero agradecer a Felix Ernesto Orduz la idea, hace ya muchas semanas, de este feed RSS.

Introducción a Groovy (I)

programacion@davidmarco.es (David Marco) — Thu, 01 Jul 2010 13:14:07 +0200

Con este entrega comienza una serie de artículos de introducción a Groovy, paso previo a la próxima publicación del tutorial de Grails. El tutorial estará formado por lo siguientes capítulos (podrían ser más en el futuro):

1. Introducción a Groovy, reglas y características básicas del lenguaje
2. Strings, GStrings y Closures
3. Rangos y Colecciones
4. POGO's
5. Metaprogramación
6. Usando el API (manejo de archivos, manejo de xml, groovelets)

Para poder seguir el tutorial es necesario tener instalado Groovy en tu equipo, misión que puedes llevar a cabo de forma sencilla siguiendo los pasos del siguiente anexo. Podrás acceder al resto de artículos de esta serie desde la pagina de tutoriales.

1.1 PERSPECTIVA GENERAL
Groovy es un lenguaje dinámico, orientado a objetos, muy intimamente ligado a Java. EL 99% del código Java existente puede ser compilado mediante groovy, y el 100% del código Groovy es convertido en bytecode Java, y ejecutado en tu JVM de manera natural. Groovy simplifica la sintaxis de Java hasta lo realmente necesario para expresar lo que queremos hacer, y ademas añade una serie de metodos tremendamente utiles al JDK, convirtiendo multitud de tareas en un placer.

1.2 SINTAXIS
La sintaxis de Groovy es una especie de código Java minimalista, eliminando la mayor parte del código "innecesario" (por innecesario nos referimos al código que no es estrictamente necesario para ejecutar la acción que deseamos). Esto, que a priori podria parecernos una dificultad, haciendonos pensar que tenemos que aprender un nuevo lenguaje, no lo es, pues como se ha mencionado en la sección 1.1 casi todo el código Java puede ser compilado con Groovy. De esta manera, podemos introducirnos en Groovy poco a poco, utilizando su sintaxis exclusiva mientras la vamos aprendiendo y la sintaxis de Java el resto del tiempo. Esto es válido en una misma clase o método, de manera que la curva de aprendizaje del lenguaje es muy suave. Veamos un ejemplo



println "¡Hola Mundo!"

El código de arriba podria considerarse el ejemplo más simple de Groovy. Esa unica linea muestra por pantalla el mensaje "¡Hola Mundo!". No necesitamos escribir una clase contenedora, ni un método public static void main(String[] args) que rodee el código (llamaremos a esto un script). No hay llamada a System.out, hemos ignorado los paréntesis en la llamada al método println así como el punto y coma al final de la linea. Aquí es donde estriba la sencillez de Groovy: reduciendo el código a lo estrictamente necesario. Si deseamos escribir los paréntesis, el punto y coma o ambos, podemos hacerlo: el código seguira funcionando.

1.3 SCRIPTS
Existen diversas maneras de ejecutar código Groovy. Una de ellas es mediante scripts. Puedes escribir el código de la sección 1.2 en un archivo con extensión .groovy (p.e. holamundo.groovy) y ejecutarlo desde linea de comandos así:

    groovy holamundo.groovy

Esto compilará el archivo en bytecode Java y sera ejecutado "al vuelo" en memoria. Este archivo será una clase con un metodo main, dentro del cual se insertará el contenido del script que este fuera de cualquier metodo, más los métodos del script que se insertarán dentro de la propia clase.

1.4 GROOVY SHELL
Una segunda opción para ejecutar codigo Groovy es mediante groovy shell. Para lanzar el groovy shell escribimos en la linea de comandos:

    groovysh

Hecho esto, el prompt cambiara y podremos escribir código directamente en él. Para obtener ayuda, podemos escribir lo suguiente una vez que estamos dentro del shell:

    help

Una caracteristica interesante del shell es que mantiene un historial de todos los comandos que hemos introducido anteriormente, incluso aquellos de una ejecucíon anterior del shell. Para movernos por ese historial, podemos usar las flechas arriba-abajo del cursor de nuestro teclado.

Es necesario mencionar que el shell debe ser utilizado para ejecutar pequeños scripts, ya que algunas caracteristicas mas complejas del lenguage aún no están soportadas. Utilizalo como una manera rapida de probar un trozo de código que, tal vez, estas escribiendo dentro de tu IDE favorito.

1.5 GROOVY CONSOLE
Una opcion mas potente para ejecutar código Groovy es mediante la consola de Groovy. Esta consola funciona en modo grafico y permite opciones mas potentes que el shell, como guardar y cargar archivos, opciones de edición de texto, etc. Para lanzar la consola de Groovy ejecuta lo siguiente desde la linea de comandos:

    groovyconsole

La consola no padece de las limitaciones del shell a la hora de ejecutar ciertas características complejas del lenguaje. Mi recomendación es que sigas todos los ejemplos restantes del tutorial desde la consola, a menos que se especifique lo contrario.

1.6 COMPILAR ARCHIVOS
Todo archivo .groovy, ya contenga una clase o un script, puede ser compilado en un archivo .class. Este archivo es una clase Java normal que, por tanto, puede ser cargada desde Java y Groovy como cualquier otra clase. Realicemos un sencillo ejemplo para comprobarlo. Compila el archivo que hemos escrito en la sección 1.3 de la siguiente manera:

    groovyc holamundo.groovy

Si miramos en el sistema de archivos, veremos que junto al archivo 'holamundo.groovy' también aparece el recién creado archivo 'holamundo.class'. Ahora crea un script nuevo, en un fichero llamado 'ejecutor.groovy' y escribe dentro de él lo siguiente:



holamundo hm = new holamundo()

hm.main()

println "este es otro archivo"

Si ahora ejecutamos este archivo desde linea de comandos:

    groovy ejecutor.groovy

Obtenemos la siguiente salida:

    ¡Hola Mundo!
    este es otro archivo

Como puedes ver, hemos instanciado una clase que fué escrita y compilada en Groovy, resultando en una clase Java normal.

1.7 IMPORTACIONES AUTOMATICAS
Groovy importa por defecto varios paquetes y clases, de manera que pueden ser utilizados inmediatamente sin necesidad de escribir sus correspondientes sentencias import. Dichos paquetes y clases son:

    - groovy.lang
    - groovy.util
    - java.lang
    - java.util
    - java.net
    - java.io

    - java.math.BigInteger
    - java.math.BigDecimal



1.8 PUNTO Y COMA OPCIONAL
Como ya hemos visto en los ejemplos anteriores, el caracter de punto y coma al final de cada linea es opcional. Solo debe ser usado al escribir varias sentencias en una única linea:

println "primera sentencia"; println "segunda sentencia"

1.9 PARÉNTESIS OPCIONAL
El caracter de paréntesis para llamar a un metodo con argumentos también es opcional.



void metodo(String s1, String s2) {

    println s1 + s2

}



metodo "uno", "dos"

Los paréntesis si que son obligatorios cuando se llama a un método sin argumentos (ya que el compilador no podria saber si es un metodo o una variable lo que estamos llamando).

1.10 RETURN OPCIONAL
La sentencia return al final de un método también es opcional en Groovy. Si se omite, el resultado devuelto por su última linea será implícitamente su valor de retorno (esto también aplica a scripts, que como vimos en el punto 1.3, en tiempo de ejecución son convertidos en una clase que se ejecuta en memoria):



void cuadrado(int numero) {

    println "devolviendo cuadrado de " + numero

    numero*numero

}

El método anterior, cuando es ejecutado, escribe un mensaje por la salida estandar y devuelve el cuadrado del número pasado como argumento. La sentecia return solo es necesario cuando, por ejemplo, necesitemos devolver un valor dentro de un bucle o un bloque switch En caso de que la última sentencia de un método o script no devuelva ningún valor (por ejemplo una sentencia println o la llamada a un método void), se devolverá null.

1.11 DECLARACION DE TIPOS OPCIONAL
En Groovy no tenemos que declarar el tipo de una variable cuando le asignamos un valor. Esto es debido a la naturaleza dinamica de Groovy, en contra de Java que es un lenguaje fuertemente tipado (o estático).



x = "Esto es un String"

println x.class

x = 12

println x.class

La variable x, que no ha sido declarada previamente en el código, es inicializada con un String primero y con un entero después. Las sentencias println demuestran esto mostrando por pantalla el tipo actual de la variable después de cada asignación. Esta naturaleza dinámica es conocida como 'duck typing', un término que significaria algo como 'escritura de pato', y proviene de un dicho inglés que dice que si anda como un pato, come como un pato y hace ruido como un pato, seguramente es un pato. En nuestro caso, si una variable contiene un String y se comporta como tal, entonces es un String (aunque no hayamos definido su tipo).

El código anterior, que funciona bien en scripts, no puede ser usado dentro de una clase: o declaramos el tipo explicitamente (String o int) o declaramos la variable con def:



class MiClase {

    def x = "Esto es un String"

        

    void metodo() {

        println x.class        

        x = 12

        println x.class

    }

}



new MiClase().metodo()

Mi recomendación es utilizar siempre def, incluso en scripts, puesto que así podemos determinar en que momento se crea la variable y en que momento se le esta reasignando un valor diferente.

1.12 MANEJO DE EXCEPCIONES
En Groovy todas las excepciones son de tipo no chequeadas, por lo que no tenemos que declararlas ni capturarlas. Esto nos da la liberad de manejarlas solo cuando creamos necesario hacerlo, en contra del sistema de manejo de excepciones en Java donde el compilador nos obliga a hacerlo siempre que un metodo declare lanzar una excepción de tipo chequeada. Veamos un ejemplo:



FileReader fr = new FileReader("actividad.log")

En el ejemplo anterior, si el archivo 'actividad.log' no existe se lanzará una excepción del tipo FileNotFoundException. Pero imaginemos que esa linea se llama desde una aplicación donde ese archivo siempre existe (porque se ha creado 5 lineas de código antes o porque al iniciar la aplicación se crea automáticamente), o que estamos llamando a un archivo del sistema operativo que, de igual manera, debe estar siempre presente en disco. En estos dos casos los bloques try-catch solo añaden "ruido" al código, pues son a todas luces innecesarios. Groovy nos permite no declarar ni capturar cualquier excepcion, sea del tipo que sea. Por supuesto que, cuando no podamos asegurar que una excepción no va a ser lanzada, deberemos gestionarla correctamente. Dejame recordarte que, sobre todo en una aplicación seria, NUNCA debes capturar una excepción en un bloque catch vacio, pues tu aplicación podria estar funcionando mal y no ser consciente de ello.

1.13 SOBRECARGA DE OPERADORES
Groovy permite la sobrecarga de operadores, de manera que podemos definir un método (dentro de una de nuestras clases) que será llamado al usar cierto operador. La manera mas sencilla de entenderlo es, como siempre, viendo un ejemplo:



class MiInteger {

    private int valor = 0;

       

    public MiInteger(int valor) {

        this.valor = valor

    }

     

    public int plus(MiInteger otro) {

        valor + otro.valor

    }

}



def mc1 = new MiInteger(8)

def mc2 = new MiInteger(7)

println mc1 + mc2

El ejemplo anterior es una clase wrapper simplificada de Integer. En su interior hay un método llamado plus() el cual sobrecarga el operador + (caracter más). Debajo de la definición de la clase hemos instanciado dos objetos de dicha clase y los hemos "sumado" con el citado operador +. El resultado ha sido la llamada al método plus(), el cual ha devuelto la suma de los valores contenidos en ambas instancias (recuerda que la última linea de un método es implícitamente una sentencia return. Puedes encontrar una lista con todos los operadores que pueden ser sobrecargados y sus métodos correspondientes aquí.

1.14 REFERENCIACIÓN SEGURA
El operador de referenciación segura (?) evita que se lance la temida excepción de tipo NullPointerException cuando llamamos a un método en un objeto con valor null. En su lugar, la llamada al método devolverá null:



MiInteger mi

mi?.plus(new MiInteger(10))

El código anterior declara una instancia de la clase MiInteger y llama a su método plus() usando el operador de referenciación segura (el caracter de interrogación) antes del punto. Al ejecutar el código, obtenemos que la llamada al método devuelve null en lugar de lanzar una excepción NullPointerException.

El operador de referenciación segura puede ser encadenado tantas veces se desee:



empresa?.getEmpleado()?.getSueldo()?.getSalarioBase()

1.15 AUTOBOXING
En Groovy, TODO es un objeto. Incluso los tipos primitivos son tratados como objetos. Mira el siguiente código:



println println 2.floatValue()

El código anterior llama al método floatValue() que está presente en la clase Integer, a pesar de que 2 es un tipo primitivo. La razón de este comportamiento tan sorprendente como potente es que Groovy convierte (cuando es necesario) cualquier variable de tipo primitivo en su correspondiente clase wrapper.

1.16 DECIMALES
En Groovy, todas las expresiones numéricas con decimales son por defecto de tipo BigDecimal:



println 0.91.class

Si ejecutas el código anterior, verás que la expresión decimal 0.91 es una instancia de la clase BigDecimal. Este comportamiento del lenguaje esta destinado a evitar la inexactitud de las clases Float y Double. Aunque dichas clases siguen estando disponibles, evidentemente deben ser instanciadas explícitamente:



println new Double(0.91).class

1.17 VERDADERO Y FALSO
En Java, solamente true puede ser verdadero y solamente false puede ser falso. En Groovy el concepto de verdadero y falso ha sido extendido a multitud de situaciones más, siempre con la intención de simplificar el código y hacerlo tremendamente expresivo. Siempre que se evalue un valor cero, null, un String vacío, una coleccion vacía, un array de longitud cero o un StringBuilder/StringBuffer vacío, se obtendrá false. En cualquier otra situación, se obtendrá true. Esto nos permite, por ejemplo, lo siguiente:



def lista = []

// ...

if(lista) {

    println "ArrayList con elementos"

} else {

    println "ArrayList vacio"

}

La primera linea del código anterior declara un ArrayList vacío, y despues de varias lineas que no mostramos (que podrían añadir o eliminar objetos del ArrayList) se llama a una sentencia if pasandole como condición booleana la lista previamente creada. Si la lista contiene elementos, el bloque if será alcanzado; en caso contrario se ejecutará el bloque else.

En el próximo capítulo veremos como trabajar con cadenas de texto en Groovy, lo que nos permitirá introducir la clase GString (Groovy Strings) y los Heredocs. A continuación nos introduciremos en el concepto de Closure, una de las caracteristicas del lenguaje más potentes y totalmente necesaria para poder seguir con el resto del tutorial (ademas de elevar nuestro código hasta cotas inimaginables). Hasta entonces, ¡saludos!.

Introducción a Groovy (II)

programacion@davidmarco.es (David Marco) — Thu, 01 Jul 2010 13:17:40 +0200

En esta segunda entrega del tutorial de introducción a Groovy vamos a ver como trabajar con cadenas de texto, así como el concepto de Closure. En la primera entrega vimos las características más basicas del lenguaje, así como las reglas de sintaxis. Esta entrega es una continuacíon de la anterior, pues muestra caracteristicas del lenguaje que son comunmente utilizadas.

2.1 TIPOS DE CADENAS DE TEXTO
Groovy soporta de forma nativa tres tipos de cadenas de texto: Strings, GStrings y Heredocs. Cual usar en cada momento es una decisión que surgirá de las necesidades de nuestro código, aunque en última instancia todas ellas son intercambiales por cualquier otra.

2.2 STRINGS
Un String en Groovy es similar a un String en Java, con la particularidad de que puede ser construido usando tanto comillas simples como dobles:



def cadena1 = "Esto es válido en Java y Groovy"

def cadena2 = 'Esto es válido solo en Groovy'



println cadena1.class

println cadena2.class

Si observamos la salida de ambas sentencias println veremos que las dos variables definidas previamente, cadena1 y cadena2, son de tipo java.lang.String. Un tipo de comillado puede contener al otro en su interior, sin necesidad de (aunque está permitido) escapar el comillado interior:



def cadena3 = "Hola 'Usuario'"

def cadena4 = 'Hola "Usuario"'

2.3 GSTRINGS
GStrings (o Groovy Strings) es una cadena de texto que contiene expresiones embebidas. Un GStrings solo puede ser construido con comillas dobles o triples (las cuales veremos en el apartado 2.4). Veamos un ejemplo simple:



def saldo = 1821.14

println "El saldo es de ${saldo} euros"

En el código anterior, vemos que dentro de la cadena de texto pasada a println hemos insertado la variable saldo como si fuera parte de la propia cadena de texto. Esta inserción se hace dentro del operador ${} y es evaluada en tiempo de ejecución. Como se indicaba en el párrafo anterior, podemos insertar cualquier expresión dentro de un GString:



def saldo = 1821.14

def mensaje = "El saldo a fecha ${new Date()} es de ${saldo} euros"

println mensaje

Es evidente que el código anterior es mucho mas natural, tanto al escribirlo como al leerlo, que su homologo en Java (el cual necesitaria unir cada parte de texto con cada expresión mediante el operador +). Es importante tener siempre presente que un GString no es un String, y que usarlos en combinación puede producir resultados inesperados:



def str = "abc"

def gstr = "${str}"



println str.equals(gstr)

println str.equals(gstr.toString())

La primera sentencia println devuelve false, ya que ambas clases implementan sus métodos equals y hashCode de forma diferente. El mismo problema puede surgir (y surgirá) si mezclamos String's y GString's en sitios tales como las claves de un Map. Una forma de solventar este problema es invocar el método toString() en el objeto GString, como puede verse en la segunda sentencia println del código anterior (la cual SI devuelve true pues ambos objetos a comparar ahora si son del mismo tipo).

2.4 HEREDOCS
El último tipo de cadena de texto soportado en Groovy es el Heredoc, el cual se forma con tres comillas simples o dobles:



println """Esto es un Heredoc"""

Los Heredoc's nos permiten tanto almacenar cadenas de texto multilinea en una única variable como mezclar comillas simples y dobles en su interior sin necesidad de escaparlas:



def multilinea = """

Primera linea

Segunda linea

Tercera linea con "comillas dobles" y 'comillas simples'

"""

println multilinea

Por las dos características arriba mencionadas, los Heredocs son tremendamente útiles para almacenar XML y HTML en una variable. Los Heredocs formados con comillas dobles permiten insertar cualquier expresión, resultando en un GString multilinea. Realmente los Heredocs no son un tipo (de ahí que no aparece su nombre en otra fuente, como ocurre por ejemplo con los String's y GString's), sino más bien una caracteristica del lenguaje para escribir cadenas multilinea. Esto podemos comprobarlo de la siguiente manera:



println '''heredoc con comillas simples'''.class

println """heredoc con comillas dobles""".class

println """heredoc con comillas dobles y expresión embebida: ${new Date()}""".class

Las dos primeras sentencias println del código anterior devuelven java.lang.String como tipo del heredoc, mientras que la tercera expresión devuelve org.codehaus.groovy.runtime.GStringImpl, ya que detecta la expresión embebida y automaticamente trata la cadena como si fuera un GString.

2.5 CLOSURES
Los closures son una de las caracteristicas mas potentes del Groovy, y para aquellos que solo han trabajado con Java tal vez la más dificil de comprender y utilizar correctamente (en otros lenguajes hay construcciones comparables a los closures de Groovy). Empecemos con su definición: un closure es un bloque de código autónomo (fuera de cualquier clase) que puede ser definido y usado en puntos distintos. Veamos el ejemplo más simple posible:



def saludar = { println '¡Hola Mundo de los Closures!' }

En el código anterior se define un closure, siempre entre llaves, y se asigna a una variable llamada saludar. Para ejecutar este closure podemos invocarlo como si fuera un método (a efectos practicos lo es):



saludar()

Un closure puede aceptar parametros:



def saludar2 = { println "¡Hola ${it}!" }

saludar2 "David"

En el ejemplo anterior, utilizamos dentro del closure la variable it, la cual es implícita para todos los closures que no definen ningun parametro. Para cerrar el círculo y entender que significa esto, declaremos un closure con parametros explícitos:



def saludar3 = { nombre ->

    println "¡Hola ${nombre}!"

}



saludar3 "David"

En este último ejemplo, al contrario del anterior, hemos definido un parámetro explícito llamado nombre que sustituye a it y hace el código más legible y consonante con su función final (saludar usando un nombre). Este parámetro debe declararse antes del código del closure y separarse de este con los caracteres ->. Por supuesto, podemos declarar más de un parámetro para un closure:



def saludar4 = { nombre, apellido ->

    println "¡Hola ${nombre} ${apellido}!"

}

saludar4 "David", "Marco"

Recuerda que, como se explicó en el punto 1.9 del capítulo anterior, Groovy permite omitir los parentesis al llamar a una función a la que le pasamos argumentos (y tal como hemos dicho unos parrafos mas arriba los closures son a efectos practicos funciones) de ahí que la llamada a los closures saludar2, saludar3 y saludar4 puedan parecer un poco extrañas.

2.6 CURRYING
Currying es una técnica que nos permite pre-cargar valores en los parámetros de un closure. Veamos un ejemplo:



def saludar5 = { nombre -> println "¡Hola ${nombre}!" }

def anonimo = saludar5.curry("Anonimo")

anonimo()

En el ejemplo anterior hemos pre-cargado el valor "Anonimo" para el unico parametro del closure saludar5, y el closure resultante lo hemos almacenado en la variable anonimo. A continuación hemos llamado a dicho closure, resultando en una llamada equivalente a:



saludar5 "Anonimo"

Este ejemplo, tan simple como estúpido (espero que estés de acuerdo conmigo) no muestra la verdadera potencia del currying; su unica misión es mostrarnos el concepto de la manera más simple posible. Ahora es el momento de ver algo más práctico:



def multiplicar = { valor1, valor2 ->

    valor1 * valor2

}

def doble = multiplicar.curry(2)

def triple = multiplicar.curry(3)



println doble(7)

println triple(7)

El currying muestra toda su potencia cuando trabajamos con múltiples parametros, ya que nos permite pre-cargar valores que serán siempre los mismos para una determinada función y pasar el resto en tiempo de ejecución. En el ejemplo anterior, hemos creado dos closures, doble y triple que hacen currying sobre el closure multiplicar, pre-cargando los valores 2 y 3 respectivamente en su parametro más a la izquierda, valor1. Así, al llamar a doble(7) y triple(7) lo que hacemos es asignar el valor 7 al primer parametro sin definir de multiplicar, en nuestro caso valor2 (ya que, vuelvo a insistir, valor1 fue asignado con un valor por defecto al hacer currying).

2.7 CLOSURES COMO PARAMETROS
Una de las caracteristicas más potentes de los closures es que pueden ser utilizadas como argumentos de una función:



def repetirClosure(int numRepeticiones, Closure closure) {

    for(int i = 0; i < numRepeticiones; i++) {

        closure.call(i)

    }

}



def closure = { println it }

repetirClosure(5, closure)

En el ejemplo anterior, hemos definido un método (repetirClosure) que acepta como parámetro un closure. Dentro de dicho método, invocamos el closure dentro de un bucle mediante el método call(), al cual podemos pasarle cualquier parámetro que sera enviado directamente al closure (esto es equivalente a ejecutar el closure directamente, como hemos hecho hasta ahora, pero necesario cuando trabajamos con un objeto Closure en lugar de con la propia definición del closure). A continuación, y ya fuera de la definición del método, definimos un closure y se lo pasamos al metodo recién definido. Por otro lado, cuando el parámetro que acepta el closure es el situado más a la derecha en la definición del método (como ocurre en nuestro caso) podemos pasar el closure de la siguiente manera:



repetirClosure(5) { println it }

Esta última sintaxis la veremos de forma intensiva en el capitulo 3 cuando trabajemos con Rangos y Colecciones.

Los closures permiten hacer cosas muchisimo más complejas (y por supuesto utiles) que las aquí mostradas, pero todo lo que necesitamos saber para continuar con el tutorial se encuentra en este capítulo. Es importante que escribas tus propios closures para ganar confianza con esta potentisima herramienta del lenguaje, y que busques información adicional a la aquí descrita si quieres explorar/explotar todas sus caracteristicas. En el próximo capítulo veremos que son los Rangos, y como Groovy ha simplificado el uso de Colecciones respecto a Java. Hasta entonces, ¡feliz currying!.

Introducción a Groovy (III)

programacion@davidmarco.es (David Marco) — Mon, 12 Jul 2010 22:32:21 +0200

En los capítulos 1 y 2 del tutorial de Groovy vimos los conceptos básicos del lenguage, asi como algunas estructuras de datos. En esta tercera entrega vamos a ver dos tipos nativos del lenguaje: Rangos y Colecciones.

3.1 RANGOS
Los rangos son un tipo de datos nativo, derivado de List, que nos permite definir una lista de valores secuenciales. Veamos el ejemplo mas simple:



def rango = 1..5

def rango = 1..<5

El primer rango arriba definido es una lista con los valores del 1 al 5, ambos inclusive. El segundo rango contiene una lista con los valores del 1 al 4, pues el último valor ha sido excluido. Ahora que sabemos como definir un rango, podemos iterarlo llamando al método each(), el cual acepta un closure como argumento (recuerda que si el único o último parámetro de un método es un closure, podemos definir dicho closure a continuación de la llamada al método):



rango.each {

    println it

}

En el código anterior, iteramos a través del rango imprimiendo cada uno de sus valores. Si no vamos a reusar el rango, podemos definirlo "al vuelo", insertandolo entre parentesis:



(1..5).each {

    println it

}

Una forma alternativa de iterar a través de los valores de un rango es mediante un bucle for:



for(int contador in 1..5) {

    println contador

}

Además de each(), los rangos disponen de una serie de atributos y métodos que podemos llamar en nuestra aplicación:



def rango = 5..10

println rango.from

println rango.to

println rango.contains(4)

println rango.size()

println rango.get(3)

println rango[3]

El atributo from devuelve el valor de inicio del rango, mientras que el atributo to devuelve el último valor. El método contains() devuelve true si su argumento está incluido en el rango, y size() devuelve el tamaño del rango. Por último, podemos obtener el valor almacenado en un índice del rango (recuerda que es una lista) mediante el método get(indice) o mediante notación de arrays (rango[indice]). Otra opción permitida por un rango es la de invertirlo, gracias al método reverse():



def rango = 10..15

def inverso = rango.reverse()

inverso.each {

    println it

}

Hasta ahora hemos utilizado rangos que contenian valores enteros; sin embargo, cualquier clase que implemente el interface Comparable, así como los métodos next() y previous, puede ser usado como valor de un rango. Este es el caso, por ejemplo, de Date():



def hoy = new Date()

def dentroDeSieteDias = hoy + 7

(hoy..dentroDeSieteDias).each { dia ->

    println dia

}

Otro ejemplo de clase soportada en rangos es String:



('a'..'z').each { letra ->

    println letra

}

Los rangos ofrecen mucho mas de lo aquí explicado, y como siempre te invito a que visites la documentación oficial de Groovy. Pero antes de terminar esta sección, veamos un último ejemplo que seguro te resulta util en el futuro: rangos como valores de comparación en un bucle switch:



def sueldo = 1700;

switch(sueldo) {

    case 600..<1200:

        println 'nivel 1'

        break

    case 1200..<1800:

        println 'nivel 2'

        break

    case 1800..<2400:

        println 'nivel 3'

        break

}

El código es, sin duda, autoexplicativo.

3.2 COLECCIONES
Groovy ofrece soporte nativo para colecciones de tipo List y Map, así como conversión explícita de listas en colecciones de tipo Set y Queue. Veamos uno por uno estos tipos.

3.3 LISTAS
Las listas son colecciones secuenciales cuyos elementos pueden ser accedidos mediante un índice. Veamos como crear una lista vacia en Groovy:



def lista = []

println lista.class

El código anterior define una lista sin elementos y la almacena en la variable lista. A continuación imprime su tipo (ArrayList en mi versión de Groovy, 1.7.2). Es posible insertar elementos en la lista en el momento de su creación:



def paises = ["España", "Mexico"]

println paises.size()

En el código anterior hemos definido una lista con dos elementos de tipo String. A continuación hemos llamado al método size() que nos devuelve el número de elementos de una lista. Ahora es el momento de añadir elementos a una lista previamente creada. Las dos maneras mas comunes de hacerlo son a traves del operador 'leftshift' (<<, un operador sobrecargado como se explicó en la sección 1.13) y del metodo add() del interface List, como habriamos hecho hasta ahora en Java:



paises << "Argentina"

paises.add("Ecuador")

println paises

Las dos primeras lineas del código anterior añaden un String cada a la lista paises. Ahora podemos obtener cualquier objeto de la lista por medio de su índice numérico, y también de dos maneras: mediante notación de arrays y mediante el método getAt():



def pais = paises[0]

def otroPais = paises.getAt(1)

Recuerda que las posiciones de una lista están basadas en índice cero: el primer elemento está en la posición 0, el segundo elemento en la posición 1, etc. La notación de arrays nos permite, además de sobreescribir el valor de una posición, insertar un nuevo elemento en una posición explícita, añadiendo valores null en todas las posiciones intermedias:



paises[3] = "Colombia"

paises[6] = "Ecuador"

El código anterior sobreescribe la posición número 3 con el valor Colombia, y a continuación define en la posición 6 el valor Ecuador. Las posiciones 4 y 5, las cuales aún no han podido ser definidas pero deben existir para mantener la secuencialidad, son 'rellenadas' con valores null; así mantenemos intacto el índice de la lista. Tras ejecutar el código anterior: nuestra lista de paises quedara de la siguiente manera:

[España, Mexico, Argentina, Colombia, null, null, Ecuador]

Otra opción necesaria en una colección es la de eliminar objetos, operación que podemos llevar a cabo mediante el método remove(), el cual admite como argumento tanto el índice de la posición como el objeto a eliminar, y devuelve el valor eliminado:



def eliminado1 = paises.remove(6)

def eliminado2 = paises.remove("Ecuador")

Ambas lineas del código anterior realizar la misma operación para los valores concretos de nuestra lista: eliminar la posición 6 / eliminar el valor "Ecuador". Es importante que tengas en cuenta que si eliminamos por índice, y este no existe, obtendremos una excepción de tipo NullPointerException. Si eliminamos pasando un objeto que no existe obtendremos como resultado null, pero sin que se lance ninguna excepción. Antes de continuar vamos a eliminar los dos valores null que están embebidos en nuestra lista:



2.times {

    paises.remove(null)

}

El código anterior ejecuta el método times de la clase Number (y por tanto heredado por Integer). Este método ejecuta el closure pasado como argumento tantas veces como el valor de la variable donde es invocado, en nuestro caso 2.

Una tercera manera de eliminar un elemento de una lista es mediante el método pop(), el cual devuelve y a elimina el último elemento de la lista (no el último elemento añadido, que podría haber sido insertado a traves de notación de arrays en medio de la lista, si no el elemento que tiene el índice más alto). Este método permite tratar una lista como una cola LIFO (Last In, First Out - El último en entrar, el primero en salir) aunque, como veremos después, existe una manera más adecuada de crear colas de datos:



def eliminado = paises.pop()

println eliminado

println paises

Ahora el contenido de nuestra lista será el siguiente:

[España, Mexico, Argentina, Colombia]

Veamos ahora como iterar a través de los elementos de una lista:



paises.each {

    println it.toUpperCase()

}

En el código anterior hemos llamado al método each(), el cual acepta un closure que es ejecutado por cada elemento de la lista. Dentro del closure hemos imprimido en mayúsculas cada elemento (recuerda que está lista contiene elementos de tipo String). Como explicamos en la sección 2.5, podemos utilizar una variable definida por nosotros cuando el closure acepta un unico parametro, sustituyendo así a la variable explicita it y haciendo el código más expresivo:



paises.each { pais ->

    println pais.toUpperCase()

}

Una segunda manera de iterar una lista es mediante el método eachWithIndex, el cual acepta un closure con dos parámetros: uno para el valor de cada elemento iterado y otro para almacenar su posición (o número de iteración):



paises.eachWithIndex { pais, indice ->

    println "${pais} se encuentra en la posición ${indice}"

}

Existe una forma alternativa de iteración, que ejecuta una acción en cada elemento de la lista y devuelve una nueva lista conteniendo el resultado de dichas ejecuciones. Esto es llevado a cabo mediante el método collect():



def paisesMayusculas = paises.collect { pais ->

    pais.toUpperCase()

}

En el código anterior, hemos creado una nueva lista, llamada paisesMayusculas que contiene el resultado de convertir en mayusculas todos los valores de la lista paises:

[ESPAÑA, MEXICO, ARGENTINA, COLOMBIA]

En determinadas ocasiones, necesitamos ordenar una lista de manera natural, esto es, en base a los objetos que están contenidos en ella. Por ejemplo, para nuestra lista conteniendo objetos String la ordenación natural sería la alfabética:



paises.sort()

El fragmento de código anterior ordena la lista paises, modificando la lista original y dejando sus elementos (del tipo String) en orden alfabético):

[Argentina, Colombia, España, Mexico]

Otro método de utilidad es reverse() el cual devuelve una lista en sentido inverso, pero sin modificar la lista original. Por tanto, para capturar la nueva lista debemos asignarla a una variable:



def paisesInvertidos = paises.reverse()

Groovy nos permite añadir/sustraer una lista a/de otra mediante los operadores += y -=. Veamos un ejemplo:



def pares = [2, 4, 6, 8]

def impares = [1, 3, 5, 7, 9]

pares += impares

pares.sort()

pares -= impares

Las dos primeras lineas del código anterior crean dos listas, una conteniendo números pares y otra conteniendo números impares. A continuación, en la tercera linea, añadimos la lista de números impares a la lista de números pares, y en la cuarta linea ordenamos la nueva lista mixta con sort() (como la lista contiene números enteros, la ordenación se realiza por valor numérico, esto es: 1, 2, 3, 4, ...). En la quinta y última linea, eliminamos de la lista ordenada todos los valores de la lista de números impares, dejandola evidentemente solo con los valores pares originales.

Otro método de gran utilidad es join(), el cual une los valores de una lista en una cadena de texto:



def letras = ['a', 'b', 'c']

println letras.join()

println letras.join("-")

La primera llamada a join devuelve una cadena de texto conteniendo el valor abc, mientras que la segunda llamada devuelve también una cadena de texto pero, esta vez, con los valores de la lista separados por el String que hemos pasado como argumento; en nuestro caso, en el que hemos pasado como argumento un caracter de guión, el resultado es a-b-c. Ninguno de las versiones de join() modifica la lista original.

Groovy añade todavía más métodos de utilidad en las listas: max() y min, por ejemplo, devuelven los valores máximo y mínimo contenidos en una lista (como siempre, el concepto de máximo, mínimo, ordenación, etc. está relacionado con el tipo de objeto que almacena la lista):



println letras.max()

println letras.min()

En el código anterior, el método max() devuelve el valor c, ya que la ordenación de cadenas de texto en Java establece que c es un caracter 'mayor' que a o b. De igual manera, en la siguiente lista conteniendo números flotantes, el valor máximo corresponderia a 4.71 y el valor mínimo a 0.02:



def flotantes = [2.08, 0.02, 4.71, 3.99, 1.99]

println flotantes.max()

println flotantes.min()

Como puedes ver, el soporte de listas en Groovy es tremendamente util a la vez que sencillo. Aquí solo se han explicado algunos metodos de los muchos que provee el API, así que te recomiendo que estudies la documentación para encontrar información adicional.

3.4 ARRAYS, SET's Y COLAS
Por defecto, todas las listas en Groovy son implementaciones de la clase ArrayList. Sin embargo, podemos coaccionar al lenguaje para que convierta una lista en una implementación de Set (en la versión 1.7.2 HashSet), de Queue (LinkedList) o en un array:



def setPaises = paises as Set

def colaPaises = paises as Queue

def arrayPaises = paises as String[]

println setPaises.class

println colaPaises.class

println arrayPaises.class

También podemos aplicar la sintaxis anterior en el momento de la creación de la colección, para así trabajar con el tipo deseado desde el primer momento:



def paises = ["España", "Mexico"] as Set

Y por supuesto, podemos seguir instanciando nuestras colecciones mediante la antigua sintaxis de Java. Recuerda que el 99% del código Java es código Groovy válido:



Set lhs = new LinkedHashSet();

3.5 MAPS
Los mapas son colecciones de valores que pueden ser referidas por una clave, o lo que es lo mismo, una colección de parejas clave-valor. Groovy ofrece soporte nativo también para mapas, con una sixtaxis que en gran medida es muy similar a la de las listas:



def mapa = [:]

El código anterior crea un mapa vacio, en el cual podemos, por supuesto, ir añadiendo parejas clave-valor (posteriormente veremos como). Si deseas inicializar un mapa con valores predefinidos:



def capitales = ['España':'Madrid', 'Mexico':'Mexico D.F.']

El código anterior define un mapa con 2 parejas clave-valor en su interior. Veamos ahora como realizar algunas operaciones básicas con mapas:



capitales.get('España')

capitales.España

capitales['España']

Las tres lineas de código anterior realizan la misma tarea, obtener un valor a partir de su clave. La primera utiliza el método get(clave) para obtener el valor asociado a dicha clave. La segunda linea utiliza la notacion de puntos, en la forma mapa.clave. La última versión utiliza la notación de arrays. Cual uses depende en gran medida de tus preferencias. Es importante subrayar que cuando utilices notación de puntos debes encerrar entre comillas el nombre de las claves que contengan ciertos caracteres especiales, por ejemplo, un caracter de punto:



def datos = ['correo.electronico', 'programacion@davidmarco.es']

println datos.'correo.electronico'

El mapa definido en el código anterior contiene una clave que contiene un caracter de punto, de manera que al usar notación de puntos debemos encerrar el nombre de la clave entre comillas (tanto comillas simples como dobles están permitidas). Si no lo hacemos, obtendremos un error de compilación, ya que al haber más de un punto este no sabría donde comienza el nombre de la clave. Veamos ahora como añadir elementos a un mapa:



capitales.put('Argentina', 'Buenos Aires')

capitales.Argentina = 'Buenos Aires'

capitales['Argentina'] = 'Buenos Aires'

Las tres lineas de código anterior insertan una nueva pareja clave-valor en el mapa capitales. Al igual que al obtener un valor, cuando insertamos mediante notación de puntos un valor que contiene un punto mediante debemos encerrar la clave entre comillas. La última operación básica que nos queda es la de borrar una pareja clave-valor mediante el método remove(clave):



capitales.remove('Argentina')

La forma de iterar las parejas clave-valor de un mapa es tan sencilla como en una lista:



capitales.each {

    println it

}

El código anterior obtendria las parejas como tales. Si deseamos acceder a las claves y valores de forma independiente tenemos dos opciones: la primera consiste en usar los atributos key y/o value de la variable que almacena la pareja en cada iteración:



capitales.each {

    println it.key

}

La segunda manera consiste en pasar como parámetro a each() un closure con dos variables, la primera de ellas haciendo referencia a la clave correspondiente y la segunda a su valor:



capitales.each { pais, capital ->

    println "La capital de ${pais} es ${capital}"

}

Otros muchos métodos que vimos en la sección 3.3 (LISTAS) también están disponibles para mapas, como son collect() y sort(). Otros tienen una sintaxis ligeramente diferente (como reverseEach(Closure) en lugar de reverse()). Visita el API de Groovy para ver todos los métodos disponibles en Map. Otras operaciones, como adición y sustraccion entre mapas estan, también soportadas, aunque de nuevo de una manera un tanto diferente a como las realizabamos con listas. Por ejemplo, la adición de una lista a otra funciona de manera igual, mediante el operador +=:



def angloParlantes = ['EEUU':'Washington', 'Reino Unido':'Londres']

capitales += angloParlantes

Sin embargo, la sustracción mediante el operador -= no está soportada en mapas, por lo que hay que realizar un poco de trabajo extra para llevar a cabo esta operación:



angloParlantes.each {

    capitales.remove(it.key)

}

En el código anterior iteramos a traves del mapa que queremos eliminar, seleccionamos cada uno de las claves, y se las pasamos al método remove del mapa del cual queremos sustraer los valores.

Antes de terminar esta sección vamos a ver cuatro nuevos métodos. Los dos primeros métodos son keySet() y values(). El primero devuelve una lista con todas las claves de un mapa, mientras que el segundo devuelve una lista conteniendo todos los valores de un mapa:



def paises = capitales.keySet()

El código anterior almacenaria en la variable paises una lista con las claves del mapa capitales:

[España, Mexico, Argentina]

Por ultimo, los métodos containsKey() y containsValue() devuelven true o false dependiendo de si el mapa donde los llamemos contiene cierta clave o cierto valor:



println capitales.containsKey('España')

println capitales.containsValue('Roma')

Para el código anterior, la primera linea devolverá true mientras que la segunda devolverá false.

En este capítulo hemos visto diversos tipos de colecciones, como rangos, listas y mapas. El API de estos objetos es mucho mas amplio de lo que, por motivos de espacio, podemos (y tal vez debemos) mostrar aquí. Sin embargo, con lo aquí citado podemos comenzar a trabajar comodamente con todos estos tipos de colecciones. En posteriores capítulos las veremos y usaremos de estas y otras maneras. En el próximo capítulo veremos como trabajar con POGO's, el equivalente "Grooviano" del clasico POJO. Hasta entonces, ¡un saludo!.

Introducción a Groovy (IV)

programacion@davidmarco.es (David Marco) — Sat, 31 Jul 2010 15:10:58 +0200

En esta cuarta entrega del tutorial de introducción a Groovy vamos a ver que son y como funcionan los POGO's (Plain Old Groovy Objects). Los POGO's son el sustituto natural de Groovy a los POJO's de Java, tomando toda la funcionalidad y potencia de Groovy para construir objetos.

4.1 POGO's
Los POGO's, al igual que los POJO's en Java, son clases simples que no dependen de un framework en especial (cita de la Wikipedia). Esto es, clases que no heredan ni implementan ninguna clase/interface de un API en concreto y externo a nuestra aplicación, y que por tanto pueden ser reusados una y otra vez entre aplicaciones. Este concepto de reuso de clases es uno de los pilares básicos de la programación orientada a objetos. A efectos practicos, un POGO es una clase normal y corriente:



class Libro {

    String titulo

    String autor

    int numPaginas

}

La clase del código anterior define un libro con tres atributos que pueden ser leidos/escritos directamente, ya que Groovy generará los métodos getter/setter por nosotros en tiempo de compilación. Es más, a pesar de que dichos métodos estarán disponibles cuando compilemos y llamemos a la clase, podemos llamar a los atributos directamente por su nombre:



def libro = new Libro()

libro.titulo = "Introducción a Groovy"

libro.autor = "David Marco"

libro.numPaginas = 0

Esta sintaxis, basada en la notación de puntos (objeto.atributo) es también válida para leer valores:



println libro.titulo

4.2 GETTERS Y SETTERS
En ciertas ocasiones, sin embargo, debemos controlar como se almacenan y leen los valores de los atributos. Nada tan sencillo como sobreescribir el getter/setter correspondiente:



class Libro {

    String titulo

    String autor

    int numPaginas

    

    String getTitulo() {

        return titulo.toUpperCase()

    }

}



def libro = new Libro()

libro.titulo = "Introducción a Groovy"

libro.autor = "David Marco"

libro.numPaginas = 0



println libro.titulo

En la definición de la clase Libro del código anterior hemos proporcionado explícitamente un método setter para el atributo titulo, de manera que todas las llamadas a libro.titulo serán redirigidas a través de este método customizado. Es probable que hayas notado algo rato en la definición del método anterior (vuelve atrás y miralo bien...). ¿Ya? Como seguramente has observado, el método no es público, y la norma general es que los métodos getter/setter (sobre todo los getter) sean public, ya que de otra manera nuestra clase sería muy poco usable. Esto nos lleva al siguiente punto de este artículo.

4.3 NIVELES DE ACCESO
En Groovy prima en cierta manera el concepto de Convención sobre Configuración, esto es, que la sintaxis más simple refleja el comportamiento mas común de un componente. Lo vimos en el punto anterior con los getters y setters por defecto y tambíén aplica de la siguiente manera a los niveles de acceso por defecto en POGO's:

    - Todas las clases son públicas por defecto
    - Todos los métodos son públicos por defecto
    - Todos los atributos son privados por defecto

Estas reglas, sin embargo, conllevan ciertas matizaciones que debemos comprender. Veamos un ejemplo:



class Libro {

    String titulo

    String autor

    private int numPaginas

}

En el ejemplo anterior, hemos definido explícitamente el atributo numPaginas como privado. Esto indica al compilador que no debe generar métodos getter/setter para este atributo, de manera que el atributo no será visible de ninguna manera para un cliente Java. Y digo solamente clientes Java porque Groovy puede seguir accediendo al atributo, para leerlo y escribirlo. Esto es debido a que Groovy tiene ciertos privilegios al usar otro código Groovy, llamemoslo Despotismo Groovy. Incluso aunque proporcionemos métodos setter/getter privados para ese atributo, ¡Groovy podrá seguir accediendo a el!. Un efecto secundario de este comportamiento es que el nivel de visibilidad default-package (el que se venia aplicando hasta ahora en Java a todo método, campo y clase interna sin un nivel de visibilidad concreto) no existe en Groovy. No voy a discutir aquí los motivos por los que el lenguaje funciona de esta manera ni mucho menos a opinar al respecto, ambos temas caen fuera de los propositos de este tutorial. Sin embargo, debes tener muy presente este comportamiento cuando uses el lenguaje. Y como he dicho antes, desde Java el código se comportará como lo ha venido haciendo hasta ahora, respetando los niveles de acceso (que para eso están ahí), por lo que aún puedes controlar la visibilidad de los miembros de una clase escrita en Groovy (salvo el ya mencionado package-default que deja de existir) desde Java.

Un privilegio extra de Groovy es que puede leer y escribir un atributo directamente, sin pasar por el método getter/setter correspondiente (sea este generado implícitamente por el compilador o explícitamente por nosotros):



println libro.@titulo

En la sentencia anterior hemos utilizado el caracter @ para indicar que debemos acceder a la variable titulo directamente.

Por último, y aunque no está relacionado con la discusión sobre niveles de acceso, vamos a ver una tercera manera de leer y escribir atributos en un POGO:



def libro = new Libro()

libro.setProperty('titulo', 'Introducción a Groovy')

println libro.getProperty('titulo')

La sintaxis anterior puede resultar muy útil en ciertos casos, por ejemplo cuando no disponemos en tiempo de compilación de los nombres de los atributos que tenemos que llamar, pero si en tiempo de ejecución.

4.4 CONSTRUCTORES
Groovy nos ofrece una sintaxis especial para crear on POGO en una única linea:



def libro = new Libro(titulo:'Introducción a Groovy', autor:'David Marco', numPaginas:0)

Si recuerdas el capítulo 3, verás que los valores que se han pasado al constructor son en realizad una estructura de tipo Map. Por tanto, también podemos pasar al constructor un mapa previamente definido:



def mapa = [titulo:'Introducción a Grails', autor:'David Marco', numPaginas:0]

def libroGrails = new Libro(mapa)



println mapa.titulo

Pero, ¡aún hay más! Esta sintaxis es válida incluso para crear un POJO (un objeto Java), así que nos podemos beneficiar de ella cuando estemos usando objetos creados en Java. Ahora es el momento de preguntarnos: ¿Estamos obligados a pasar todos los atributos de un objeto al construir dicho objeto?. La respuesta es NO:



def libro = new Libro(titulo:'Introducción a Groovy')

El resto de los atributos pueden ser establecidos en cualquier momento posterior a la creación del objeto y de cualquiera de las maneras que hemos visto hasta ahora. Así de simple. Esto nos lleva a otra pregunta: ¿Debemos pasar los atributos en algún tipo de orden? La respuesta es, de nuevo NO, cualquier orden es valido.

Otra poderosa característica de los constructores en Groovy es que podemos proporcionar a cualquier atributo un valor por defecto si ninguno es proporcionado:



class Libro {

    String titulo

    String autor

    int numPaginas

    

    Libro(int numPaginas, String titulo='Sin título', String autor='Sin autor') {

        this.titulo = titulo

        this.autor = autor

        this.numPaginas = numPaginas;

    }

}



def libro = new Libro(10)

println libro.titulo

En el ejemplo anterior, se ha definido un constructor que además de inicializar los valores de los atributos de la clase, declara dos de ellos como opcionales dandoles un valor por defecto (titulo y autor). Por tanto, si instanciamos un objeto Libro y no proporcionamos los parámetros que corresponden a dichos atributos opcionales, se tomarán sus valores por defecto. Además, en la declaración del constructor, los parámetros opcionales deben aparecer después de los parámetros obligatorios para ese constructor. A la hora de diseñar el constructor debes ordenar cuidadosamente los parámetros opcionales, de manera que los que tienen más posibilidad de ser proporcionados deben aparecer primero (aunque esta anticipación al uso de la clase no es siempre posible). Nuestra nueva clase Libro es perfecta para mostrarnos este asunto:



def libro = new Libro(0, 'David Marco')

println libro.titulo

Mira bien el código anterior: ¿Que atributo estamos ajustando con el parámetro 'David Marco'? ¿titulo o autor (recuerda que ambos son String y ambos son opcionales)?. En este caso concreto, es titulo, aunque mi ingenua intención era ajustar el atributo autor, y por tanto he construido un objeto que, cuando sea usado, no se comportará como yo espero. Piensa cuidadosamente en el orden de los parámetros opcionales y, más aún, usalos con mucho cuidado y en situaciones donde realmente son necesarios y/o útiles.

Con este consejo termina la cuarta entrega del tutorial de introduccíón a Groovy (un poquito más corto de lo habitual, pero espero que igual de interesante). En la próxima entrega abordaremos la Metaprogramación en Groovy, un estilo de programar realmente increible. ¡Hasta pronto!

Introducción a Groovy (V)

programacion@davidmarco.es (David Marco) — Thu, 05 Aug 2010 15:04:32 +0200

En esta quinta entrega del tutorial de Groovy, vamos a ver el concepto de Metaprogramación. Mediante metaprogramación podemos escribir código que genera o modifica otro código, por ejemplo otros programas, o incluso a si mismos (esto es, código que tiene la habilidad de cambiar su comportamiento en tiempo de ejecución). Esto nos puede permitir, entre otras cosas, a manejar situaciones que no estaban previstas cuando se escribió el código, y sin necesidad de recompilar.

5.1 UN POCO DE REFLEXIÓN
La metaprogramación en Groovy, al igual que en Java, se basa en la capacidad del lenguaje llamada Reflexión. Mediante reflexión podemos conocer los miembros de una clase:



String.interfaces.each { println it }

String.constructors.each { println it }

String.methods.each { println it }

Cada una de las lineas del código anterior muestran los interfaces que implementa una clase, sus constructores y sus métodos, respectivamente. Para los dos últimos casos, se muestran solo los miembros públicos (public). Así mismo, todo objeto en Groovy tiene un método getClass() que devuelve el objeto Class asociado a su clase. Recuerda que podemos invocar la propiedad de una clase mediante su metodo getter, o directamente por su nombre (el getter es llamado en este caso implícitamente):



println String.class

Y hablando de propiedades, veamos como mostrar todas las propiedades de un objeto:



def s = new String("cadena de texto")

s.properties.each { propiedad ->

    println propiedad

}

El ejemplo anterior nos muestra que todo objeto String contiene tres propiedades: class (la cual vimos en acción en el ejemplo anterior), bytes (un array de bytes que contiene el valor del String) y empty que como su nombre indica contiene un valor true en caso de que la cadena de texto tenga longitud cero y false en caso contrario. Ten presente que todas las propiedades de un objeto son deducidas por medio sus métodos getter/setter.

5.2 METACLASS
Toda clase Groovy dispone de un miembro llamado metaClass. Este miembro nos permite, entre otras cosas, comprobar si la clase dispone de una propiedad concreta gracias a su método hasProperty():



class Articulo {

    String descripcion

    double precio

}



def boligrafo = new Articulo(descripcion:"Boligrafo negro", precio:0.45)

if(boligrafo.metaClass.hasProperty(boligrafo, "precio")) {

    // hacer algo

}

Así mismo, también podemos comprobar la existencia de un método con respondsTo():



if(boligrafo.metaClass.respondsTo(boligrafo, "getDescripcion")) {

    // hacer algo

}

5.3 EJECUTANDO UN MÉTODO MEDIANTE GSTRING's
Una manera alternativa de invocar un método dinámicamente es construyendo la llamada con un objeto GString:



def nombreDelMetodo = "getPrecio"

boligrafo."${nombreDelMetodo}"()

En la llamada al código anterior, cuando se ejecute el programa se sustituirá la expresión ${nombreDelMetodo} por su valor, produciendo así la llamada a getPrecio() en el objeto boligrafo.

5.4 PUNTEROS
En el capítulo 4 vimos como acceder directamente al valor de una variable (a una propiedad) mediante el operador @. Este 'acceso directo' se llama puntero:



println boligrafo.@precio

De manera parecida, mediante el operador &, podemos crear un puntero a un método:



def lista = []

def insertar = lista.&add

insertar "valor1"

insertar "valor2"

En el código anterior, hemos creado un puntero (o alias) al método add() del objeto lista y lo hemos asignado a la variable insertar. Desde ese momento, podemos ejecutar comandos como insertar "valor1" y sería equivalente a ejecutar lista.add("valor1"). Esto puede ser muy intuitivo de usar para alguien que no entiende sobre programación en general y Groovy en particular. Esto es, hemos creado un DSL (Domain Specific Language - Lenguaje Especifico de Dominio). Un DSL es un lenguaje que se adapta al dominio al cual se refiere y aplica (por ejemplo el lenguaje jurídico para la jurisprudencia), etc. Así podemos crear un lenguaje fácil de usar, ya que su sintaxis refleja la terminología del problema que se quiere resolver.

5.5 EXPANDO
Un objeto Expando es como un objeto en blanco, al cual podemos añadir métodos y propiedades 'a la carta', y además de la forma más sencilla posible: dandoles un valor. Veamos un ejemplo:



def posicion = new Expando()

posicion.latitud = 15.47

posicion.longitud = -3.11

En el código anterior, hemos definido un objeto Expando llamado posicion al cual le hemos proporcionado un valor para cada una de las propiedades longitud y longitud, propiedades que al no existir anteriormente para este Expando han sido automáticamente. Dichas propiedades pueden ser después leidas como en un objeto normal. Pero vayamos un poquito más allá, vamos a definir un método para nuestro expando:



posicion.diferencia = { nuevaLatitud, nuevaLongitud ->

    """

    Existe una diferencia de:

        LATITUD: ${posicion.latitud - nuevaLatitud}

        LONGITUD: ${posicion.longitud - nuevaLongitud}

    

    con respecto al la posición anterior: ${posicion.latitud} ${posicion.longitud}

    """

}

Para definir un metodo simplemente tenemos que definir su nombre (evidentemente) y asignarle un closure. En el código anterior, dicho closure contiene un Heredoc donde se realizan algunos calculos con las variables pasadas como argumento y las que ya contenia el Expando, devolviendose finalmente una cadena de texto (recuerda que los Heredoc son cadenas de texto multilinea, y que al ser la última (y única) sentencia del closure es también su valor de retorno implícito). Ahora, podemos llamar al siguiente código:



posicion.diferencia(10.0, 1.0)

Como puedes ver, Expando es una herramienta tremendamente potente para crear nuevos objetos, y, como veremos un poco más adelante en este mismo artículo, para ayudarnos en nuestro camino a través de la metaprogramación.

5.6 PROPIEDADES DINÁMICAS
Aunque la clase Expando nos permite añadir propiedades de manera dinámica a un objeto de su mismo tipo, ¿que ocurre cuando queremos disponer de dicho dinamismo en nuestras propias clases? Groovy, como siempre, al rescate:



class Articulo {

    String descripcion

    double precio

    def propiedades = [:]

    

    void setProperty(String nombre, Object valor) {

        propiedades[nombre] = valor

    }

    

    Object getProperty(String nombre) {

        propiedades[nombre]

    }

}

Groovy nos permite definir los métodos getProperty() y setProperty(), y el truco consiste en almacenar los valores pasados a setProperty() en un objeto Map (al que hemos llamado propiedades) para poder ser después leidos. Con esta infraestructura, ya podemos leer y escribir nuevas propiedades dinámicamente en nuestra clase Articulo:



def articulo = new Articulo()

articulo.codigoEAN = 84123445593

println articulo.codigoEAN

Cuando nuestro código llama a getCodigoEAN() la llamada es 'redirigida' internamente mediante getProperty('codigoEAN'), con total transparencia para nosotros y sin necesidad de que, en tiempo de compilación, exista esta propiedad ni sus correspondientes getters/setters. Un efecto secundario de definir propiedades dinámicas para una clase es que la lectura de una propiedad aún no definida (y por tanto inexistente) devolverá un valor null, en lugar de lanzar una excepción (un comportamiento en cierto modo parecido al producido por el operador de referenciación segura, como vimos en el punto 1.14, pero aplicado a propiedades en lugar de a objetos).

5.7 INTERCEPTANDO LLAMADAS A MÉTODOS
Groovy nos permite interceptar las llamadas a métodos que no existen:



class Articulo {

    String descripcion

    double precio

    

    Object invokeMethod(String nombre, Object args) {

        println "Invocado método ${nombre}() con los argumentos ${args}"

    }

}



def articulo = new Articulo()

articulo.operacionInexistente('abc', 123, true)

En la clase anterior hemos definido el método invokeMethod(), el cual interceptará las llamadas a cualquier método no definido. Un efecto secundario de este comportamiento es que en tiempo de ejecución no se producirá una excepción informando de la no-existencia de dicho método. Sin embargo, la finalidad de invokeMethod() no es evitar este tipo de errores (ni debería serlo) si no, por ejemplo, la construcción de clases con un comportamiento totalmente dinámico, como constructores de XML y HTML (en los que los nombres de los métodos que pasemos pueden ser usados para darles nombre a los nodos XML-HTML del documento que estamos construyendo, y el cuerpo de cada método ser interpretado como un subnodo que será procesado de la misma manera).

Si lo que deseamos es interceptar las llamadas a métodos que si existen, además de definir el método invokeMethod() nuestra clase debe implementar la interface GroovyInterceptable. Dentro de invokeMethod() tenemos que obtener el método interceptado (a traves de su metamétodo) e invocarlo:



def invokeMethod(String nombre, args) {     

        def metaMetodo = Articulo.metaClass.getMetaMethod(nombre, args)

        metaMetodo.invoke(this, args)

    }

Esto nos permite realizar algunas cosas interesante, como implementar un around-advice al mas puro estilo de la Programación Orientada a Aspectos:



class SimpleLogger {

    def logInicio(String metodo, args) {

        println "Iniciado el método ${metodo}() con los argumentos ${args}"

    }

    

    def logFin(String metodo, resultado) {

        println "$Finalizando el método ${metodo}() con el resultado ${resultado}"

    }

}



class Articulo implements GroovyInterceptable {

    String descripcion

    double precio

    SimpleLogger logger

    

    void añadirDescuento(double porcentajeDescuento){

        precio = (precio * (100 - porcentajeDescuento) / 100)

    }



    def invokeMethod(String nombre, args) {     

        logger.logInicio(nombre, args) 

        def metaMetodo = Articulo.metaClass.getMetaMethod(nombre, args)

        def resultado = metaMetodo.invoke(this, args)

        logger.logFin(nombre, resultado)

    }

}



def logger = new SimpleLogger()

def articulo = new Articulo(descripcion:'Libreta', precio:1.40)

articulo.logger = logger



articulo.añadirDescuento(15)

println articulo.precio

El código anterior define una sencilla clase de logging con dos métodos que muestran por pantalla información sobre el inicio o fin de un método. Ambos métodos son llamados en la primera y última linea dentro de invokeMethod(), de manera que cada vez que llamemos a un método de la clase Articulo se mostrará el mensaje correspondiente a su inicio y fin. Un tercera opción sería disponer de un método para loggear cualquier excepción que se produzca, pero este pequeño ejercicio lo dejo para tí. Una pregunta que podrías estar planteandote ahora es: ¿que ocurre si, con el código anterior, invocamos un método que no existe (como en nuestro primer ejemplo de este punto)? Pues que la variable metaMetodo contendrá un valor null (ya que getMetaMethod() no va a encontrar dicho método al no existir), y por tanto metaMetodo.invoke(this, args) producirá una excepción de tipo NullPointerException. La manera de evitar esto es tan simple como hacer uso del operador de referenciación segura:



def resultado = metaMetodo?.invoke(this, args)

Con la inclusion del operador de referenciación segura nuestra pequeña clase es capaz de interceptar las llamadas a TODOS sus métodos, existan o no:



articulo.noExiste()

5.8 CATEGORÍAS
Groovy permite la adición de nueva funcionalidad a una clase de la que, por ejemplo, no disponemos del código fuente. Esto es posible a traves de una Categoría, la cual implementa los métodos que deseamos añadir a dicha clase. Veamos un ejemplo aplicado a Articulo:



class Articulo {

    String descripcion

    double precio

}



class ArticuloExtras {

    static double conImpuestos(Articulo articulo) {

        return articulo.precio * 1.18

    }

}



Articulo articulo = new Articulo(descripcion:'Grapadora', precio:4.50)

use(ArticuloExtras) {

    articulo.conImpuestos()

}

En el código anterior definimos una categoría llamada ArticuloExtras que define un método extra para la clase Articulo. Los metodos que deseamos añadir deben seguir la siguiente estructura:

static tipoDeRetorno nombre(ClaseDeDestino, argumento1, argumento2, ...)

Finalmente, aplicamos la categoría dentro de un bloque use, el cual requiere como parámetro el nombre de la categoría a usar. También podemos indicar más de una categoría dentro de un bloque use separando sus nombres con comas. Recuerda que los nuevos métodos solo estarán disponibles dentro del bloque use.

5.9 EXPANDOMETACLASS
El concepto de ExpandoMetaClass combina los conceptos de metaClass y Expando, permitiendo así añadir métodos a un cualquier clase. El concepto es el mismo que ya hemos aplicado con las Categorias, solo que esta vez los métodos están disponibles a nivel global, sin necesidad de ceñirnos a un bloque concreto. Un ejemplo típico del uso de ExpandoMetaClass es el siguiente:



Integer.metaClass.numeroAleatorio = {

    def random = new Random()

    random.nextInt(delegate.intValue())

}



50.numeroAleatorio()

El el código anterior añadimos el método numeroAleatorio() al objeto metaClass de la clase Integer, asignandole un closure que contiene el cuerpo del método. La primera linea dentro del closure define un objeto Random y lo asigna a una variable. Es en la segunda linea de código donde se genera la magia: llamamos al método Random.nextInt() pasandole como parámetro el propio objeto donde se está realizando la llamada a numeroAleatorio(), esto es, delegate (en este caso concreto será una instancia de Intgeger), y a continuación se llama a su método intValue() que devuelve un int en lugar del Integer original. Puesto que la capacidad de Java de hacer autoboxing y autounboxing tambíen está disponible en Groovy, podemos escribir el código de la siguiente manera:



random.nextInt(delegate)

Lo importante es que tengas presente que delegate hace referencia al objeto 'delegado', el objeto que estará disponible en tiempo de ejecución y desde el que se ejecutara el bloque de código con el que estamos tratando. Otro objeto que podemos alcanzar desde dentro del closure es el propio closure, en este caso con la palabra this. Espero que resulte sencillo de comprender (yo tuve mis problemas en su momento, aunque no lo parezca por su sencillez).

Hay todavía mucho que decir sobre metaprogramación, sobre todo ver ejemplos más complejos que los aquí mostrados, pero todos los temas estan tratados y dejo en tu mano profundizar más en el tema. La metaprogramación puede ser dificil de entender para los que venimos de lenguajes estáticos como Java, donde apenas se hace uso de las librerias de reflexión (si alguien las usa habitualmente que me perdone por ese comentario) y todo se deja más bien atado en tiempo de compilación. Sea como sea, la metaprogramación nos permite hacer cosas realmente increibles, y nunca esta de más tener unos conocimientos básicos sobre ella. En el próximo capítulo de este tutorial (que tal vez sean dos o más por su longitud) se verá como usar el lenguaje para tareas cotidianas, como parsear y generar XML, leer y escribir archivos, y algunos temas más; en resumen, un 'manos a la obra' con todo lo que hemos aprendido hasta ahora y algunas cositas nuevas.

Spring Expression Language

programacion@davidmarco.es (David Marco) — Fri, 20 Aug 2010 23:05:21 +0200

Desde la versión 3.0, Spring ofrece un lenguaje dinámico llamado Spring Expression Language (SpEL). SpEL permite la consulta y manipulación de objetos en tiempo real (de manera similar a Expression Language en JSP/JSF) además de otras interesantes características como la invocación de metodos. SpringSource Tool Suite (una variación de Eclipse altamente customizada para trabajar con Spring) provee soporte para SpEL, permitiendo autocompletado de expresiones además de otras caracteristicas realmente útiles para trabajar con el lenguaje. SpEL puede ser utilizado:

    - de forma nativa en una aplicación Spring (insertado en archivos XML o anotaciones)
    - a través de un parser, creando explicitamente toda la infraestructura necesaria para interpretarlo

REQUISITOS
Si usas Maven en tus proyectos, la única dependencia necesaria para usar empezar a usar SpEL es:

<dependency>
     <groupId>org.springframework</groupId>
     <artifactId>spring-context</artifactId>
     <version>3.0.3.RELEASE</version>
</dependency>

Si deseas gestionar tus librerías sin Maven, además de todos los JAR's necesarios para levantar una aplicación Spring 3.0 (org.springframework.context-3.0.X.RELEASE.jar, org.springframework.beans-3.0.X.RELEASE.jar, ...) necesitas incluir en tu classpath el siguiente JAR que encontrarás en el directorio dist de tu distribución de Spring 3:

org.springframework.expression-3.0.X.RELEASE.jar


SINTAXIS
La sintaxis de SpEL toma la siguiente forma cuando es usada de forma nativa:



#{EXPRESION}

Cuando la expresión es usada por un parser, debemos omitir el caracter de almohadilla y la pareja de llaves:



EXPRESION

A lo largo de este artículo, al introducir cada tipo de expresión se utilizara la primera versión, de manera que se enfatice su naturaleza y se diferencie más facilmente del resto del contenido. Solo cuando una expresión se utilice a través de un parser se utilizará la versión correspondiente, sin almohadilla ni llaves.

CONSTRUYENDO EXPRESIONES (1ª PARTE)
Comencemos viendo los tipos mas básicos de expresión para realizar una toma de contacto con el lenguaje, de manera que en las dos próximas secciones (SPEL DE FORMA NATIVA y SPEL A TRAVES DE UN PARSER) entendamos el 100% del código y no nos perdamos. El primer tipo de expresión que vamos a ver, y la más simple, es la de tipo literal:



#{12.7}

La expresión anterior es un literal del número flotante 12.7. Otro tipo de literal frecuentemente utilizado es la cadena de texto:



#{'Hola SpEL'}

Como puedes ver, las expresiones literales de tipo cadena de texto son construidas dentro una pareja de comillas simples. Ambas expresiones literales devuelven 'literalmente' su valor (de ahi su nombre).

El siguiente tipo de expresión es la de tipo booleano:



#{7 > 9}

El significado de la expresión anterior es totalmente obvio, y el resultado devuelto al evaluar la expresión sería false.

La siguiente de la lista es la llamada 'expresión estandar', la cual nos permite acceder a las propiedades de un bean o javabean mediante notación de puntos:



#{usuario.nombre}

La expresión anterior devolverá el valor de la propiedad nombre del bean llamado usuario que, evidentemente, debera estar registrado dentro del contexto de la aplicación Spring actual. Si lo que queremos es evaluar un bean en si mismo, nada tan facil como usar su nombre como expresión:



#{usuario}

Antes de continuar viendo más tipos de expresiones, veamos como y donde pueden ser usadas. Esto, además de completar el binomio 'sintaxis-uso' te permitirá experimentar con las expresiones mientras continuas leyendo el artículo.

SPEL DE FORMA NATIVA
Como se indicó al inicio de este artículo, SpEL puede ser usado de forma nativa en una aplicación Spring 3.0 mediante anotaciones o en archivos de configuración XML. Veamos algunos ejemplos:



class Login {

    @Value("#{usuario.nombre}")

    private String nombreUsuario;

    

    // ...

}

La anotación @Value puede ser aplicada tanto en variables como metodos setter, así como en parámetros de un método o constructor. El valor devuelto por la expresion será el valor por defecto del campo donde se aplique, en el caso del ejemplo anterior la variable nombreUsuario. Para que Spring pueda detectar la presencia de la anotación @Value en nuestras clases debemos activar la configuración mediante anotaciones en el fichero de configuración de Spring:



<beans xmlns="http://www.springframework.org/schema/beans"

    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

    xmlns:context="http://www.springframework.org/schema/context"

    xsi:schemaLocation="http://www.springframework.org/schema/beans

        http://www.springframework.org/schema/beans/spring-beans-3.0.xsd

        http://www.springframework.org/schema/context

        http://www.springframework.org/schema/context/spring-context-3.0.xsd">

        

    <context:annotation-config />

Para usar la misma expresión en un archivo de configuración de Spring 3.0:



<bean class="Login" id="login">

    <property name="nombreUsuario" value="#{usuario.nombre} />

</bean>

El resultado es el mismo que al utilizar la anotación @Value.

SPEL A TRAVES DE UN PARSER
SpEl puede ser usado fuera de un archivo XML o anotación @Value mediante un parser. Este parser requiere el ensamblaje de cierta infraestructura:



ExpressionParser parser = new SpelExpressionParser();

Expression expresion = parser.parseExpression("'Hola SpEL'");

String nombreUsuario = expresion.getValue(String.class);

El código anterior es bastante simple. Primero crea un parser de la clase SpelExpressionParser. A continuación crea una expresión llamando al método parseExpression(EXPRESION) del recien creado parser. Por último, obtenemos el resultado de la evaluación de la expresión a traves del objeto expresion. Cuando la expresión hace referencia a un objeto, debemos crear un contexto de ejecución para dicho objeto:



Usuario usuario = new Usuario("David Marco");

EvaluationContext contexto = new StandardEvaluationContext(usuario);

ExpressionParser parser = new SpelExpressionParser();

Expression expresion = parser.parseExpression("nombre");

String nombreUsuario = expresion.getValue(contexto, String.class);

En el ejemplo anterior hemos creado un objeto usuario así como un contexto de evaluación para dicho objeto. En el momento de crear la expresión, solo indicamos la propiedad que queremos evaluar del objeto que hemos pasado al contexto (en lugar del binomio 'objeto.propiedad' que se utilizaría con la anotación @Value o en un archivo de configuración XML). Finalmente, pasamos el contexto de evaluación a expresion.getValue() de manera que la expresión (la propiedad nombre) es aplicada contra el contexto (el objeto usuario) resultando en la evaluación de usuario.nombre. En caso de que el contexto de evaluación tienda a cambiar entre ejecuciones es preferible sustituir el contexto de evaluación que hemos creado explicitamente por el objeto que subyace a dicho contexto, y Spring creará por nosotros un nuevo contexto de evaluación en cada llamada a getValue():



List<Usuario> usuarios = new ArrayList<Usuario>();

// Inicializar la lista de usuarios

ExpresionParser parser = new SpelExpressionParser();

Expression expresion = parser.parseExpression("nombre");

for(Usuario usuario: usuarios) {

    String nombreUsuario = expresion.getValue(usuario, String.class);

}

CONSTRUYENDO EXPRESIONES (2ª PARTE)
Ahora que ya hemos visto como y donde podemos escribir expresiones, sigamos viendo más tipos. Empecemos con las expresiones de clase:



#{T(java.lang.Math)}

El caracter T indica que queremos actuar sobre el tipo de una clase (en nuestro caso java.lang.Math), en lugar de sobre una instancia. Una vez obtenido el tipo, podemos asignarlo a una variable mediante @Value, XML o con el parser. También podemos actuar sobre el tipo devuelto por la expresión llamando a cualquiera de sus métodos estáticos dentro de la expresión:



#{T(java.lang.Math).random()}

SpEL nos permite definir expresiones para gestionar colecciones. Para acceder a un array o a un objeto de tipo List:



#{empresa.empleados[1]}

El acceso a listas y arrays se realiza mediante su índice, puesto que son colecciones indizadas. El acceso a una colección de tipo Map se realiza, como ya habras imaginado, mediante sus claves:



#{empresa.telefonosDepartamentos['Ventas']}

En ambos casos, se utiliza la notación de corchetes ya sea para obtener el índice en array y listas como la clave en mapas.

El siguiente tipo de expresión es la invocación de un método. Lo vimos en acción anteriormente al invocar random() en una expresión de clase, pero por su importancia merece un nuevo ejemplo:



#{'Hola SpEL'.toUpperCase()}

La expresión anterior es muy interesante, consistiendo en la invocación de un método sobre una expresión literal. Por supuesto, dicha invocación de método puede realizarse sobre cualquier expresión, clase, u objeto.

SpEL nos permite invocar el constructor de una clase con el siguiente tipo de expresión:



#{new Date()}

El siguiente tipo de expresión de nuestra lista es la expresión con operador ternario, que funciona exactamente igual de como lo haría en Java:



#{usuario.edad > 18 ? true : false}

Recuerda que cuando evaluamos una expresión sobre un objeto, y utilizamos el parser, omitimos el nombre del objeto puesto que dicho objeto ha sido o será pasado como contexto de evaluación:



Usuario usuario = new Usuario("David Marco", 30");

ExpressionParser parser = new SpelExpressionParser();        

Expression expresion = parser.parseExpression("edad > 18 ? true : false");

Boolean mayorDeEdad = expresion.getValue(usuario, Boolean.class);

System.out.println("Es mayor de edad? " + mayorEdad);

También podemos hacer referencia al contexto de evaluación mediante una expresión de variable:



Expression expresion = parser.parseExpression("#this.edad > 18 ? true : false");

En la expresión anterior, #this hace referencia al objeto que conforma el contexto actual de evaluación, en nuestro caso usuario.

Los dos últimos tipos de expresión que vamos a mostrar en este artículo estan relacionadas con la manipulación de colecciones. La primera es proyección de colección:



#{usuarios.![nombre]}

En la expresión anterior, usuarios es una coleccion que contiene objetos de tipo Usuario. Una vez evaluada la expresión, el resultado devuelto es una lista que contiene los nombres (mediante la propiedad nombre) de todos los usuarios de la primera lista. El segundo tipo de expresión para manipular colecciones es selección de colección:



#{usuarios.?[nombre.startsWith('D')]}

Selección de colección permite, como muy bien expresa la sintaxis anterior, filtrar los objetos de una colección (usuarios y devolver una nueva colección que contiene solo aquellos objetos que cumplian las condiciones de filtrado.

CONCLUSIONES
Como puedes ver, Spring Expression Language provee un lenguaje rico y dinámico que te permitirá configurar los beans de tu aplicación Spring 3.0 de manera aún más flexible que en versiones anteriores, además de proveer un lenguaje de scripting que puedes usar dentro de tus clases a traves del parser.

Integración de Eclipse y SpringSource Tool Suite

programacion@davidmarco.es (David Marco) — Thu, 30 Sep 2010 19:24:31 +0200

SpringSource Tool Suite (STS) es un IDE basado en la versión Java EE de Eclipse, pero altamente customizado para trabajar con Spring Framework. Entre las características más destacadas que STS proporciona se encuentran:

    - soporte para Spring 3
    - asistentes para la creación de proyectos Spring
    - herramientas para la gestión de beans
    - editores gráficos de archivos de configuración de Spring
    - herramientas de desarrollo para Spring Web Flow y Spring Batch

STS puede descargarse desde aquí como un IDE completo, pero también puede integrarse sobre una instalación previa de Eclipse. Sobre esta última opción trata este artículo.

INSTALANDO ECLIPSE
Lo primero que necesitamos es tener Eclipse instalado en nuestro equipo. La versión que vamos a utilizar es la última en el momento de escribir este artículo: Eclipse IDE 3.6 for Java EE Developers (nombre en clave Helios), la cual incluye todas las dependencias necesarias para instalar STS. También se dan las instrucciones necesarias para Eclipse 3.5 (Galileo). Los pasos para instalar STS en otras versiones de Eclipse pueden ser diferentes, por lo que no puedo garantizar que este artículo sea 100% funcional para dichas versiones.

PREPARANDO ECLIPSE
Ya dentro del IDE, el primer paso es desactivar todas sitios desde los que Eclipse puede descargar actualizaciones y nuevo software. Desde la barra de menús del IDE accede a:

    Windows > Preferences > Install/Update > Available Software Sites

Desactiva todas los sitios de descarga que se encuentren activados desmarcando su casilla correspondiente. Comprueba que el status de cada uno de ellos ha cambiado de Enabled (Activado) a Disabled (Desactivado). No cierres esta ventana aún.

El siguiente paso es configurar los sitios de descarga específicos de STS. La manera más simple es descargando un fichero XML donde se encuentra dicha configuración. Descarga y guarda en tu equipo el archivo correspondiente a tu versión de Eclipse:

    http://dist.springsource.com/snapshot/TOOLS/composite/e3.6/bookmarks.xml    (para Eclipse 3.6)
    http://dist.springsource.com/snapshot/TOOLS/composite/e3.5/bookmarks.xml    (para Eclipse 3.5)

Ahora es el momento de volver a la pantalla de configuración de sitios de descarga, que aún deberias tener abierta. Si la has cerrado, recuerda que puedes volver a ella desde:

    Windows > Preferences > Install/Update > Available Software Sites

Pulsa el botón 'Import' y selecciona el archivo XML previamente descargado. Verás que aparecen dos nuevos sitios de descarga, y que ambos han sido automáticamente activados (Enabled). De manera adicional, uno de los sitios de descarga de Eclipse también ha sido activado automáticamente. En total, deberemos tener exactamente tres sitios de descarga activados (si estas utilizando Eclipse 3.5 verás que cambia 'Helios' por 'Galileo', así como los números de versión):

    - Helios
    - SpringSource Update Site for Eclipse 3.6 (Snapshot)
    - SpringSource Update Site for Eclipse 3.6 (Snapshot, Dependencies)

Pulsa OK para guardar los cambios.

INSTALANDO STS
El último paso es instalar los componentes que conforman STS. Para ello, accede al gestor de instalación de nuevo software de Eclipse:

    Help > Install New Software

En el menú desplegable superior selecciona el sitio:

    Work with > SpringSource Update Site for Eclipse 3.6 (Snapshot)

Ahora te aparecerán los componentes que están disponibles desde el sitio seleccionado. Que componentes seleccionar y cuales no es una decisión que dejo en tus manos. Hay quienes prefieren instalarlos todos, y hay quienes (como en mi caso) siempre customizan la instalación, de manera que solamente se instalen los componentes necesarios para una determinada tarea. Además, siempre puedes entrar al gestor de instalación de nuevo software y seleccionar componentes que aún no has instalado. Como guía, estos son los componentes que yo he seleccionado (ten presente que algunos de ellos son obligatorios):

    - Core / Spring IDE (COMPLETO)
    - Core / STS (COMPLETO)
    - Extensions (Incubation) / Spring IDE (COMPLETO)
    - Extensions / Spring IDE (PARCIAL)
        - Grails Support
        - Maven Support
        - Runtime Error Analysis Support
    - Integrations / Spring IDE (COMPLETO)
    - Resources / Spring IDE (COMPLETO)

Una vez seleccionados los componentes a instalar, pulsamos 'Next' y llegamos a la ventana donde se muestran los detalles de la instalación que estamos a punto de realizar. Volvemos a pulsar 'Next', aceptamos las condiciones de la licencia marcando la casilla 'I accept the terms...' y pulsamos 'Finish'.

Si has realizado los pasos correctamente, verás como se abre una ventana donde se muestra la descarga e instalación de los componentes seleccionados (operación que suele durar varios minutos). Durante el proceso de descarga/instalación aparecerá una ventana con una alerta de seguridad (Security Warning), donde se nos informa que se está instalando software sin firmar; pulsa OK para continuar con la instalación. Finalmente, aparecerá una nueva ventana donde se nos informa que debemos reiniciar Eclipse para que los cambios tomen efecto. Por tanto, pulsamos 'Restart Now' para reiniciar (asegúrate de haber guardado todo el trabajo que pudieras haber estado realizando antes de instalar STS) o 'Not Now' si deseamos reiniciar más tarde.

DESACTIVANDO EL DASHBOARD
Una vez instalado STS y reiniciado Eclipse, veremos que al cargar el IDE nos aparece el Dashboard de STS. El dashboard (o tablero de mandos) es una ventana en la que:

    - podemos gestionar proyectos Spring
    - se muestran actualizaciones de STS
    - se muestran feeds de notícias que son actualizadas períodicamente
    - se pueden instalar nuevas extensiones para STS (plug-ins, soporte para otros lenguajes de programación, ...)

Para mantener el IDE lo más limpio posible y acelerar el arranque de Eclipse, recomiendo desactivar el dashboard. Lo primero es ir a la configuración del dashboard:

    Window > Preferences > Spring > Dashboard

Una vez alli, desactiva la casilla 'Show Dashboard On Startup'. Pulsa OK y de nuevo en la pantalla principal de Eclipse cierra el dashboard si aún continua abierto (pulsando sobre la X de la pestaña superior). La próxima vez que inicies Eclipse el dashboard no aparecerá. Si en algún momento deseas mostrarlo, nada tan simple como ir a:

    Help > Dashboard



UN EJEMPLO SIMPLE
La mejor manera de explicar que es y que ofrece STS es, como no, mediante un ejemplo muy sencillo. Vamos a crear un proyecto Spring y a continuacion su archivo de configuración. Para crear el proyecto Spring:

    File > New > Other > Spring > Spring Project

Le damos un nombre al proyecto y pulsamos 'Finish'. Ahora, en la ventana del 'Project Explorer', expandimos el recien creado proyecto, pulsamos con el boton derecho del ratón sobre la carpeta 'src' y seleccionamos:

    New > Other > Spring > Spring Bean Configuration File

Pulsamos 'Next', le damos un nombre al archivo de configuración (no olvides incluir la extensión XML o STS no sabrá gestionarlo) y pulsamos 'Finish'. El nuevo archivo de configuración se abrirá, y mediante sus pestañas inferiores (Source, Namespaces, ...) podremos gestionar el código fuente XML, los namespaces incluidos, crear nuevos beans mediante un asistente, ver representaciones gráficas de los beans así como sus relaciones, etc.



RESUMEN
SpringSource Tool Suite es una fantástica herramienta que te ayudará a manejar de manera muy potente tus proyectos Spring, con multitud de asistentes, editores, opciones y configuraciones. Aquellos que trabajan con Spring encontrarán en SpringSource Tool Suite un entorno desde el que desarrollar más eficazmente sus aplicaciones Spring, sin olvidar que también trae soporte para otras tecnologías como Groovy, Grails, OGSI, y más.

Sigueme también en Twitter

programacion@davidmarco.es (David Marco) — Fri, 14 Oct 2010 22:30:00 +0200

Desde ahora podeis seguir la actividad de la web a través de Twitter, accediendo a la dirección http://twitter.com/davidmarcoes.

¡Os espero!

Primer año de davidmarco.es

programacion@davidmarco.es (David Marco) — Mon, 20 Dec 2010 12:05:00 +0100

Hoy se cumple un año desde la puesta en marcha de la web. Las más de 187.000 visitas y 560.000 páginas vistas desde 42 paises distintos dan sentido al humilde esfuerzo con el que empecé esta aventura, a mi misión primera y última: compartir mis conocimientos con el resto de la comunidad, al tiempo que aprendo de ella. Las traducciones a Español de los tutoriales de Spring e Hibernate han tenido una aceptación extraordinaria, además de servir de base para diferentes modificaciones que algunos habéis realizado de ellos. También ha tenido gran acogida mi blog personal, dentro del cual he publicado los tutoriales de JPA, Groovy, y diversos artículos relacionados con Java.

Los cientos de correos que he recibido agradeciendo mi trabajo han sido un gran motor para seguir adelante. Muchos de vosotros me habeís pedido también ayuda por email, ayuda que no siempre es facil de proporcionar pues cada problema que os surge con un proyecto concreto es un mundo. De cualquier modo, he contestado a todos y cada uno de los correos sin escatimar tiempo ni esfuerzo, y os invito a que os sigáis poniendo en contacto conmigo siempre que lo consideréis oportuno.

Para este nuevo año espero poder escribir mejores artículos y, espero (aunque no sean tan importante), en mayor cantidad. Algunos ya están planificados (como un tutorial de EJB 3.1 que algunos me habéis solicitado y que comenzaré a escribir en Febrero) y otros irán surgiendo sobre la marcha. También tengo en mente algunas modificaciones en la presentación de la página (como el prometido sistema de búsqueda de contenido que hace tiempo que debería de estar en marcha), y tal vez un lavado de cara a la presentacion visual.

No hay nada que me motive más que saber que aún quedan muchas cosas por hacer, tener delante un largo camino para unos pies que no se van a rendir porque disfrutan a cada paso que dan, por duro que sea. Un año de gracias a todos, y feliz 2011.

David Marco.

Usando buenos nombres

programacion@davidmarco.es (David Marco) — Fri, 04 Feb 2011 22:45:46 +0100

Actualmente me encuentro leyendo una joya de la literatura informática de los últimos años, Clean Code: A Handbook of Agile Software Craftsmanship, de Robert C. Martin. Sin enrollarme demasiado, el libro muestra como mejorar nuestro código (y como no empeorarlo) siguiendo algunas técnicas que, en los dos últimas decadas, han demostrado ser efectivas para mantener un proyecto de software funcionando de la mejor manera posible durante el mayor tiempo posible.

Este artículo trata sobre una de esas técnicas, una tan sencilla como poderosa, y que podemos empezar a aplicar desde ya a todo el código que pase por nuestras manos: usar buenos nombres. Vamos al lio.

INTRODUCCIÓN: ¿POR QUE USAR BUENOS NOMBRES?
Usar buenos nombres es esencial para mantener el código legible. Como programadores, pasamos más tiempo leyendo código (propio y ajeno) que escribiéndolo (según algunos estudios ¡en un ratio de 10:1!); toda nueva funcionalidad se basa en funcionalidad anterior, y si esa funcionalidad anterior no es legible nuestra tarea se ralentizará y, en el peor de los casos, puede convertirse en una pesadilla. Más aún, prácticamente todo tiene un nombre (constantes, variables, métodos, clases, paquetes, ...) así que entidades bien definidas con un nombre apropiado y no ambiguo nos harán el trabajo mucho más sencillo. Usar buenos nombres nos va a ayudar a desarrollar más rápido, cometer/producir menos errores, y sobre todo a ser profesionales y sinceros con nuestro trabajo. Comencemos con las reglas.

TEN CUIDADO AL ELEGIR LOS NOMBRES Y CAMBIALOS CUANDO ENCUENTRES UNO MEJOR
Sin llegar a convertir esta regla en una obsesión, pues puede haber más de una manera igual de adecuada de nombrar una entidad, es la base de todo lo que se va a exponer. Debes aceptar esta regla de manera natural y acometerla sin poner excusas. La forma de llevarla a cabo está explicada en el resto de reglas.

NOMBRANDO CLASES
Clases y objetos deben ser nombrados usando sustantivos como Cliente, Usuario y Empleado.

NOMBRANDO MÉTODOS
Métodos deben ser nombrados usando verbos o frases con verbos como pagarSalario, borrarArchivo, etc. Métodos que actuan como accesores según el estandar Javabean deben seguir las reglas típicas (getXxx, setXxx, isXxx).

USA NOMBRES QUE REVELEN UNA INTENCIÓN
El nombre de una variable, un método, o una clase debe decir porqué existe, que hace, y que representa, respectivamente. Si una variable, clase o método necesita un comentario que responda a una de esas tres cuestiones es que su nombre no está revelando su intención:



int dias; // dias transcurridos desde la última comprobación

El código anterior es ambiguo, y esa variable usada 100 lineas más abajo no nos estará diciendo quien es, porqué está ahí y porqué debe ser usada de la forma en que lo está siendo. Lo más probable es que tengamos que retroceder buscando el lugar donde ha sido declarada (y tal vez viendo cómo ha sido usada anteriormente) para responder a las tres preguntas anteriores. Una manera mucho más correcta de declararla sería así:



int diasDesdeUltimaComprobacion;

Ahora, la misma variable leida las mismas 100 lineas más abajo expresa claramente su razón de ser y la del código que la usa.

EVITA LA DESINFORMACIÓN
La desinformación oscurece el código, llevandote a seguir falsas pistas y a perderte entre ellas. No uses nombres del tipo usuariosList para un objeto que no represente realmente una colección de tipo List (mejor usa conjuntoDeUsuarios o aún mejor usuarios).

Otra fuente de desinformación resulta de nombres muy largos y muy similares:



public class ControladorParaManejoEficienteDeEntradas { }

public class ControladorParaGuardadoEficienteDeEntradas { }

Para este último caso no hay solución sencilla (ambas clases están nombradas de manera adecuada) y lo mejor es tener presente la similaridad de sus nombres, prestando atención a si estamos usando la clase adecuada en cada momento.

Un caso extremo de desinformación se produce al usar los caracteres l (ele minúscula) y O (o mayúscula), que son fácilmente confundidos por 1 (uno) y 0 (cero).

REALIZA DISTINCIONES DE SIGNIFICADO
Que el compilador entienda y compile todo el código que le proporcionamos no nos convierte en buenos programadores. Una de mis citas favoritas sobre programación (y que tengo pinchada en la pared delante de mi) es de Martin Fowler y dice lo siguiente:

"Any fool can write code that a computer can understand. Good programmers write code that humans can understand."

Que traducido viene a decir:

"Cualquier tonto puede escribir código que un ordenador puede entender. Los buenos programadores escriben código que los seres humanos pueden entender."

Que nuestro compilador entienda la diferencia inherente entre dos variables array1 y array2 no le va a importar lo más mínimo a quien, seis meses después de haber sido escritas, tenga que usarlas (y ese alguien podriamos ser nosotros) y no sepa por donde empezar porque sus nombres no significan nada. Ese dia seremos maldecidos:



void copiarCaracteres(char[] array1, char[] array2) {

    for(int i = 0; i < array1.length; i++) {

        array2[i] = array1[i];

    }

}

Aunque el método anterior tiene un nombre adecuado, el algoritmo que contiene en su interior es confuso. Y si en lugar de contener solamente 2 lineas de código tuviera 20, sería un caos. La solución es hacer una distinción de significado entre los nombres de los argumentos del método, renombrandolos para que tengan un significado explícito y claro:



void copiarCaracteres(char[] origen, char[] destino) {

    for(int i = 0; i < origen.length; i++) {

        destino[i] = origen[i];

    }

}

Otra fuente de indistinción de significado nace del uso de ciertas palabras en los nombres que damos a una entidad. ¿Acaso no resultan tremendamente similares en significado las variables cliente y clienteInfo? ¿Que representa cada una de ellas cuando ambas aparecen en el mismo contexto? Por este motivo, palabras como info y datos deben ser evitadas.

USA NOMBRE PRONUNCIABLES
Imagina el siguiente ejemplo:



Date genAmdhms() { }

El ejemplo anterior es un caso claro, tal vez un poco extremo (aunque recuerdo haber hecho cosas no mucho mejores en algunos proyectos...), de nombre impronunciable, y está relacionado con una de las primeras reglas que vimos: USA NOMBRES QUE REVELEN UNA INTENCIÓN. Probablemente el método vaya acompañado de un comentario que clarifique cual es su función, ya que de otra manera sería prácticamente imposible deducir cual es esta (función que, dicho sea de paso, es generar el año, mes, dia, hora, minuto, y segundo actual). ¿Acaso no habría sido más sencillo hacer lo siguiente?:



Date generarTimestamp() { }

Otro problema que surje al usar nombres impronunciables aparece cuando tenemos que comunicarnos verbalmente con un compañero o socio. Imagínate por un momento la siguiente conversación:

Durante la última batería de tests ha aparecido un bug que apunta al método gen a eme de ache eme ese, ¿puedes echarle un vistazo?

Creo que las palabras sobran.

USA NOMBRES QUE PUEDAN SER BUSCADOS
Nombres con un solo carácter (o extremadamente cortos) y el uso de literales numéricos sufren de un mal común: son difíciles de buscar. El el primer caso (nombres con un solo carácter) su uso debería ser reducido a métodos más bien cortos y algunos casos especiales (por ejemplo la famosa variable i dentro de un bucle for) y nunca en ningún otro lugar. Una variable llamada e para representar a un Empleado es una atrocidad que no debes cometer jamás. En el segundo caso (literales numéricos) deberían ser sustituidos por constantes con un nombre bien definido. Veamos un ejemplo:



if(empleado.getHorasTrabajadasUltimaSemana() > 40) {

    pagarHorasExtra(empleado);

}

En el método anterior, se está usando un literal numérico (40) donde debería utilizarse una constante con un nombre bien definido. Si en el futuro decidimos que las horas base por semana deben ser 35 en lugar de 40, nos veremos obligados a buscar cada linea donde aparece el valor 40 (problema 1: es dificil de buscar) y determinar en cada una de ellas si dicho valor 40 hace referencia a las horas trabajadas, puesto que si hace referencia a otro contexto (por ejemplo el número máximo de empleados por departamento) y lo cambiamos por error, estaremos introduciendo un bug que será dificil de encontrar cuando la aplicación comience a funcionar mal (problema 2: propensión a introducir errores). La solución ya se ha mencionado dos veces: declarar una constante con un nombre adecuado:



final static int HORAS_BASE_POR_SEMANA = 40;

...

if(empleado.getHorasTrabajadasUltimaSemana() > HORAS_BASE_POR_SEMANA) {

    pagarHorasExtra(empleado);

}

Ojala algún dia a todos nos paguen las horas extra con la misma facilidad :)

ELIGE UNA ÚNICA PALABRA POR CADA CONCEPTO
Elige una palabra para cada concepto abstracto y úsala siempre. Imagina tres clases, cada una con un método que obtiene información de forma similar desde una base de datos. En la primera clase el método se llama leerDatosDesdeBBDD, en la segunda obtenerDatosDesdeBBDD y en la tercera recuperarDatosDesdeBBDD. Esto solo puede crear confusión, además de ser muy poco elegante.

Quiero reconocer que este error (o más exactamente violación de buenas prácticas) lo he cometido a menudo en el pasado, por ejemplo diseñando una interface DAO con métodos llamados leerXxx, leerYyy, ... y una interface de servicio con métodos llamados obtenerXxx, obtenerYyy, ... . Esta última interface se limitaba a llamar a los métodos del DAO, y a pesar de trabajar conectadas, cada una utilizaba su propia nomenclatura, resultando en código feo y muy poco estético.

Quienquiera que lea código de este tipo se empezará a hacer preguntas totalmente innecesarias como ¿que diferencia hay entre leer datos y recuperar datos? ¿Lee desde un archivo y recupera desde una base de datos? ¿O lee desde una base de datos y recupera desde un archivo? Entonces tendrá que revisar código fuente, documentación y/o especificaciones para descubrir que ambos métodos hacen lo mismo, aunque han sido nombrados según convenciones diferentes. El código debe ser (dentro de sus/nuestras posibilidades) como la prosa, como un libro que cuenta una historía que puedes comprender frase a frase. Nunca como una adivinanza ni como un juego de palabras. No dejes nada al azar.

EVITA USAR LA MISMA PALABRA PARA DOS CONCEPTOS
Esta regla es hermana de la regla anterior. Imagina otras tres clases, cada una con un método llamado añadir. En la primera clase, dicho método añade un registro a una base de datos, en la segunda añade un objeto a un array, y en la tercera añade una cadena de texto a otra previamente almacenada en una variable. Esos tres métodos, si son utilizados "cara a cara" en una misma aplicación (como la interface de servicio y la interface DAO de la regla anterior) producirán confusión al lector, ya que los tres se llaman igual pero hacen cosas completamente distintas (ten presente que intento hacer una distinción sutil del que hace y no del cómo lo hace, siguiendo el más que importante principio de encapsulación). La solución a este problema es ser consistente con los nombres que usamos, o en su defecto o imposibilidad, usar nombres apropiados:



class SimpleDao {

    void añadirRegistroEnBBDD(Registro registro) { }

}

Facil, ¿verdad?.

USA NOMBRES QUE REFLEJEN LA SOLUCIÓN
Quien lee tu código es también programador, por lo debes usar terminos que reflejen la solución que estás usando. Un ejemplo visto anteriormente es usuariosList, que rápidamente se interpreta como una colección de tipo List que contiene usuarios. Quienquiera que tenga que usar dicha variable tendrá conciencia inmediata de que es y cómo debe usarla. Otro ejemplo de nombre que refleja la solución que está tratando sería UsuarioFacade: una clase que implementa el patrón de diseño Facade. Es más fácil nombrar bien una entidad que acompañarla con un comentario de 15 palabras.

USA NOMBRES QUE REFLEJEN EL DOMINIO
Esta regla complementa a la anterior. Cuando tratamos problemas de un dominio especifico, debemos usar nombres que reflejen ese dominio. Un método actualizarInventario está hablando sobre algo llamado inventario, que es parte del dominio de la aplicación que estamos escribiendo. Esto nos va a ayudar tanto a escribir el código necesario para implementar el método (puesto que el nombre deja claro el que) como a entender su función cuando sea usado o leido por nosotros mismos o por otro programador.

AÑADE UN CONTEXTO
La última regla, añade un contexto, nos puede ayudar en ciertos momentos a evitar ambigüedades y por tanto confusión. Imagina que tenemos un conjunto de variables llamadas calle, numero, ciudad y codigoPostal. Todas ellas, cuando se usan conjuntamente, reflejan claramente que estamos tratando con una dirección postal y que sus nombres son perfectamente válidos. Sin embargo, ¿que ocurre si una de ellas, por ejemplo numero, es usada de manera independiente dentro de un método? Para el lector de dicho método, numero puede significar un montón de cosas, o tal vez no significar nada, convirtiendo el método o ciertas partes de él en (como dije unas reglas más arriba) una adivinanza: sabemos el que, pero no sabemos el porqué. Esto no es código legible.

Existen dos soluciones a este problema. La primera es añadir un prefijo a las variables, lo que les proporciona un contexto y elimina de un plumazo cualquier ambigüedad presente y futura:



String direccionCalle;

String direccionNumero;

String direccionCiudad;

String direccionCodigoPostal;

La segunda solución, y en cualquier lenguaje orientado a objetos la preferida, es crear una clase que sea en si misma el contexto:



public class Direccion {

    String calle;

    String numero;

    String ciudad;

    String codigoPostal;

    

    // getters y setters

}

De esta manera dejamos de llamar a numero para llamar a direccion.getNumero(), provocando que el significado de la antes ambigua variable se descubra ahora por si mismo.

RESUMEN
Todo el código que no es legible y claro en sus intenciones es dicifil de entender y de mantener. Programar debe ser un placer, dentro de su dificultad y otras peculiaridades que no vienen a cuento, y nunca una pesadilla. El código debe fluir, y ningún programador desea ahogarse en un rio desbordado de dificultades. Usar buenos nombres en clases, métodos, variables, etc. es una muy buena manera de empezar a mejorar nuestro código, ayudándonos a nosotros mismos y ayudando también a otros. Y además, es tremendamente sencillo (dentro de su dificultad y otras peculiaridades que no vienen a cuento, again). Te animo a que adoptes los principios que se han expuesto en este artículo; si no te gustan siempre puedes volver a tu estilo habitual, pero lo más posible es que una vez los pruebes y veas como crece la calidad de tu trabajo, nunca des marcha atrás.

SOBRE EL LIBRO CLEAN CODE: A HANDBOOK OF AGILE SOFTWARE CRAFTMANSHIP
Este artículo está basado en los apuntes que he ido tomando al leer el libro Clean Code: A Handbook of Agile Software Craftsmanship, de Robert C. Martin (más precisamente el capítulo 2: Meaningful Names). La mayoría de los principios que se han expuesto los he venido usando desde mucho antes de tener en mis manos el libro, pues no son desconocidos para la mayoría.

Este artículo no es una traducción ni tampoco un resumen del libro, es una recopilación y traslación de algunas reglas que en él se exponen, escritas por mi con mis propias palabras. Unos pocos fragmentos de código son muy similares a los que aparecen en la obra mientras que la mayoría son mios; así mismo, unas pocas frases me han inspirado por su simplicidad y energía, y las he incluido en el texto (siempre evitando la literalidad). No pretendo con esto quitarle a Robert C. Martin el enorme mérito que merece, pues este artículo es hijo de su obra, ni tampoco colgarmelo yo, pues la forma en como lo he escrito (el nombre de los principios y, salvo excepciones, el orden en que son presentados) está inspirada sin recelos en las páginas de dicha obra. Os recomiendo que os hagaís con ella, personalmente me parece una lectura tremendamente recomendable, divertida e inspiradora, escrita en un inglés muy fácil de leer.

Introducción a EJB 3.1 (I)

programacion@davidmarco.es (David Marco) — Tue, 08 Mar 2011 23:05:40 +0100

Con este artículo comienza un tutorial que describe el estandar EJB 3.1 de manera introductoria. El tutorial contiene tanto material teórico como práctico, de manera que según se vayan introduciendo nuevos conceptos se irán reflejando en código. Es muy recomendable que antes de seguir leyendo visites el siguiente anexo donde se explica como poner en marcha un entorno de desarrollo compatible con EJB 3.1, de manera que puedas seguir todos los ejemplos que se van a presentar en el tutorial, así como desarrollar los tuyos propios.

La siguiente lista muestra el contenido de los primeros 6 artículos de los que constará el tutorial. Esta lista se actualizará si se publica contenido adicional:

    - 1. Introducción a EJB y primer ejemplo
    - 2. Stateless Session Beans y Stateful Session Beans
    - 3. Singletons y Message-Driven Beans
    - 4. Persistencia
    - 5. Servicios que ofrece el contenedor (1ª parte)
    - 6. Servicios que ofrece el contenedor (2ª parte)

Con todo esto dicho, ¡comencemos!

1.1 ¿QUE SON LOS ENTERPRISE JAVABEANS?
EJB (Enterprise JavaBeans) es un modelo de programación que nos permite construir aplicaciones Java mediante objetos ligeros (como POJO's). Cuando construimos una aplicación, son muchas las responsabilidades que se deben tener en cuenta, como la seguridad, transaccionalidad, concurrencia, etc. El estandar EJB nos permite centrarnos en el código de la lógica de negocio del problema que deseamos solucionar y deja el resto de responsabilidades al contenedor de aplicaciones donde se ejecutará la aplicación.

1.2 EL CONTENEDOR DE APLICACIONES
Un contenedor de aplicaciones es un entorno (en si mismo no es más que una aplicación) que provee los servicios comunes a la aplicacion que deseamos ejecutar, gestionándolos por nosotros. Dichos servicios incluyen la creación/mantenimiento/destrucción de nuestros objetos de negocio, así como los servicios mencionados en el punto anterior, entre otros. Aunque el contenedor es responsable de la gestión y uso de dichos recursos/servicios, podemos interacturar con él para que nuestra aplicación haga uso de los servicios que se ofrecen (normalmente mediante metadados, como se verá a lo largo del tutorial).

Una vez escrita nuestra aplicación EJB, podemos desplegarla en cualquier contenedor compatible con EJB, beneficiandonos de toda el trabajo tras bastidores que el contenedor gestiona por nosotros. De esta manera la lógica de negocio se mantiene independiente de otro código que pueda ser necesario, resultando en código que es más fácil de escribir y mantener (además de ahorrarnos mucho trabajo).

1.3 LA ESPECIFICACIÓN EJB 3.1
La especificación EJB 3.1 es parte de la plataforma JavaEE 6, desarrollada y mantenida por Sun Microsystems (ahora parte de Oracle Corporation). JavaEE 6 provee diversas API's para la construcción de aplicaciones empresariales, entre ellas EJB, JPA, JMS, y JAX-WS. Cada una de ellas se centra en un area específica, resolviendo así problemas concretos. Además, cada API/especificación está preparada para funcionar en compañia de las demás de forma nativa, y por tanto en su conjunto son una solución perfectamente válida para desarrollar una aplicación end-to-end (de principio a fin).

Desde la versión 3.0, EJB no impone ninguna restricción ni obligación a nuestros objetos de negocio de implementar una API en concreto. Dicho de otro modo, podemos escribir dichos objetos de negocio usando POJO's, facilitando entre otras cosas la reutilización de componentes y la tarea de testearlos.

Como se ha dicho, los POJO's son faciles de testear (siempre que estén bien diseñados). Al final de este primer artículo se verá un sencillo ejemplo de programación de un EJB mediante Test-Driven Development (Desarrollo Dirigido por Tests). TDD es una metodología de desarrollo en la cual cada bloque de código está respaldado por uno o más tests que han sido escritos con anterioridad. De manera muy resumida, TDD nos permite enfocar de manera efectiva el problema que deseamos resolver de la siguiente manera:

    - Escribimos un test que define que queremos hacer.
    - Ejecutamos el test y este falla (puesto que aún no hay lógica de negocio, o lo que es lo mismo, como queremos hacerlo).
    - Escribimos la lógica de negocio que hace pasar el test (la solución más simple posible).
    - Mejoramos la lógica de negocio gradualmente, ejecutando el test después de cada mejora para verificar que no hemos roto nada.

Escribir el test antes que la lógica de negocio y mantenerlo lo más simple posible nos obliga a escribir código independiente de otro código, con responsabilidades bien definidas (en resumen, buen código). Usado de forma correcta, TDD permite crear sistemas que son escalables, y con niveles de bugs muy bajos. TDD es un tema tan amplio en si mismo que no tiene cabida en este tutorial (a excepción del citado ejemplo que veremos al final del artículo y que servirá solamente para demostrar que el modelo EJB es un buen modelo de programación), y en el que te animo que profundices si no lo conoces; las ventajas que ofrece para escribir código de calidad son muchas, independientemente del uso de EJB o no.

Por otro lado, el uso de POJO's para encapsular nuestra lógica de negocio nos proporciona un modelo simple que es altamente reutilizable (recuerda que la reutilización de clases es un concepto básico y esencial en programación orientada a objetos). Debes tener en cuenta que un POJO no actuará como un componente EJB hasta que haya sido empaquetado, desplegado en un contenedor EJB y accedido por dicho contenedor (por ejemplo a petición de un usuario). Una vez que un POJO definido como EJB haya sido desplegado en el contenedor, se convertirá en uno de los tres siguientes componentes (dependiendo del como lo hayamos definido):

    - Session Bean
    - Message-Driven Bean
    - Entity Bean

Veamos una breve descripción de cada tipo de componente (en capítulos posteriores se explicará cada tipo de componente con más detalle).

1.4 SESSION BEANS
Los Session Beans (Beans de Sesión) son los componentes que contienen la lógica de negocio que requieren los clientes de nuestra aplicación. Son accedidos a través de un proxy (también llamado vista, término que utilizaré en adelante) tras realizar una solicitud al contenedor. Tras dicha solicitud, el cliente obtiene una vista del Session Bean, pero no el Session Bean real. Esto permite al contenedor realizar ciertas operaciones sobre el Session Bean real de forma transparente para el cliente (como gestionar su ciclo de vida, solicitar una instancia a otro contenedor trabajando en paralelo, etc).

Los componentes Session Bean pueden ser de tres tipos:

    - Stateless Session Beans
    - Stateful Session Beans
    - Singletons

Stateless Session Beans (SLSB - Beans de Sesión sin Estado) son componentes que no requieren mantener un estado entre diferentes invocaciones. Un cliente debe asumir que diferentes solicitudes al contenedor de un mismo SLSB pueden devolver vistas a objetos diferentes. Dicho de otra manera, un SLSB puede ser compartido (y probablemente lo será) entre varios clientes. Por todo esto, los SLSB son creados y destruidos a discrección del contenedor, y puesto que no mantienen estado son muy eficientes a nivel de uso de memoria y recursos en el servidor.

Stateful Session Beans (SFSB - Beans de Sesión con Estado), al contrario que SLSB, si que mantienen estado entre distintas invocaciones realizadas por el mismo cliente. Esto permite crear un estado conversacional (como el carrito de la compra en una tienda online, que mantiene los objetos que hemos añadido mientras navegamos por las diferentes páginas), de manera que acciones llevadas a cabo en invocaciones anteriores son tenidas en cuenta en acciones posteriores. Un SFSB es creado justo antes de la primera invocación de un cliente, mantenido ligado a ese cliente, y destruido cuando el cliente invoque un método en el SFSB que esté marcado como finalizador (también puede ser destruido por timeout de sesión). Son menos eficientes a nivel de uso de memoria y recursos en el servidor que los SLSB.

Los Singleton son un nuevo tipo de Session Bean introducido en EJB 3.1. Un Singleton es un componente que puede ser compartido por muchos clientes, de manera que una y solo una instancia es creada. A nivel de eficiencia en uso de memoria y recursos son indiscutíblemente los mejores, aunque su uso está restringido a resolver ciertos problemas muy específicos.

1.5 MESSAGE-DRIVEN BEANS
Message-Driven Beans (MDB - Beans Dirigidos por Mensajes) son componentes de tipo listener que actuan de forma asíncrona. Su misión es la de consumir mensajes (por ejemplo eventos que se producen en la aplicación), los cuales pueden gestionar directamente o enviar (derivar) a otro componente. Los MDB actuan sobre un proveedor de mensajería, por ejemplo Java Messaging System (JMS es además soportado de forma implícita por la especificacion EJB).

Al igual que los Stateless Session Beans, los Message-Driven Beans no mantienen estado entre invocaciones.

1.6 ENTITY BEANS
Los Entity Beans (EB - Beans de Entidad) son representaciones de datos almacenados en una base de datos, siempre en forma de POJO's. El encargado de gestionar los EB es EntityManager, un servicio que es suministrado por el contenedor y que está incluido en la especificación Java Persistence API (JPA - API de Persistencia en Java). JPA es parte de EJB desde la versión 3.0 de esta última. Para saber más sobre JPA, puedes visitar un tutorial anterior publicado en esta misma web en la siguiente dirección.

Al contrario que los Session Beans y los Message-Driven Beans, los Entity Beans no son componentes del lado del servidor. En otras palabras, no trabajamos con una vista del componente, si no con el componente real.

1.6 EJB Y TEST-DRIVEN DEVELOPMENT
Para terminar este primer artículo, dejemos de lado la teoría y escribamos una sencilla aplicación EJB para ir abriendo el apetito. Para poder seguir este y futuros ejemplos, debes tener en marcha un entorno compatible con EJB 3.1 (aunque la mayoría de los ejemplos, incluido este, funcionarán en un contenedor compatible con EJB 3.0). Por otro lado, todo el código se ajusta al estandard EJB 3.1 (no se usarán extensiones exclusivas de un contenedor concreto). Sin embargo, ten presente que las indicaciones relativas a la creación del proyecto, despliegue, y ejecución de los ejemplos estarán condicionadas por el entorno concreto que se ha puesto en marcha mediante el anexo que acompaña este tutorial; si tu entorno es diferente, ciertas acciones (como los opciones de menús a ejecutar en tu IDE) serán otras.

Como se ha indicado en el punto 1.3, este ejemplo de desarrollará de manera puntual mediante Test-Driven Development. En los próximos artículos solo se mostrará código EJB, que es al fin y al cabo el tema a tratar en este turorial. Así mismo, los pasos para crear un proyecto o como desplegarlo en el contenedor EJB se omitirán en artículos posteriores.

Para comenzar inicia Eclipse (si aún no lo has hecho) y crea un nuevo proyecto EJB:

    File > New > EJB Project

Dale un nombre al nuevo proyecto y asegúrate tanto de seleccionar en el desplegable 'Target runtime' un contenedor compatible con EJB como de seleccionar la versión 3.1 en el desplegable 'EJB module version'. Haz click en el botón 'Finish' para crear el proyecto.

Ahora es el momento de crear un test que defina y respalde nuestro primer EJB. Lo primero es crear una carpeta dentro del proyecto donde almacenaremos todos los tests que escribamos. En la pestaña 'Project Explorer' haz click con el botón derecho sobre el proyecto EJB y selecciona:

    New > Source Folder

Introduce el nombre del directorio en el campo 'Folder name' (utiliza un nombre descriptivo, como 'tests') y haz click en el botón 'Finish'. Si expandes el proyecto EJB (con la flecha negra que hay a la izquierda del nombre) verás que el nuevo directorio se ha creado correctamente. Ahora vamos a crear la clase donde escribiremos los tests para nuestro EJB. Haz click con el botón derecho sobre el directorio de tests y selecciona:

    New > Other

En la ventana que te aparecerá selecciona:

    Java > JUnit > JUnit Test Case

En la ventana de creación de un test de JUnit selecciona la opción 'New JUnit 4 test', introduce el nombre del paquete donde deseas alojar la clase en el campo 'Package' (muy recomendado) y escribe un nombre para la clase de tests. En mi caso, el nombre del paquete será 'es.davidmarco.ejb.slsb' y el nombre de la clase de tests
'PrimerEJBTest'. Haz click en el botón 'Finish'; si es el primer tests que escribes para el proyecto (como es nuestro caso) aparecerá una ventana donde Eclipse nos informa que la librería JUnit no está incluida en el classpath. Seleccionamos la opción 'Perform the following action: Add JUnit4 library to the build path' (Realizar la siguiente acción: añadir la libreria JUnit 4 al path de construcción) y haz click en el botón 'OK'. Hecho esto, ya podemos escribir nuestro primer (y de momento único) test:



package es.davidmarco.ejb.slsb;



import org.junit.Test;

import static org.junit.Assert.*;



public class PrimerEJBTest {

    @Test

    public void testSaluda() {

        PrimerEJB ejb = new PrimerEJB();

        assertEquals("Hola usuario", ejb.saluda("usuario"));

    }

}

El test (un método que debe ser void, no aceptar parámetros, y estar anotado con la anotación de JUnit @Test) declara las intenciones (el contrato) del código que estamos diseñando: crear un objeto de la clase PrimerEJB con un método saluda() que acepte un argumento de tipo String y devuelva un mensaje con el formato 'Hola argumento'. Aquí empezamos a ver las ventajas de EJB: podemos testear nuestro código de negocio directamente, sin tener que desplegar el componente EJB en un contenedor y entonces hacer una llamada a este, con toda la parafernalia que esto requiere.

Y ahora si (por fin) vamos a escribir nuestro primer EJB. Nuestra clase de negocio ira en un paquete con el mismo nombre que el utilizado para almacenar las clase de tests, pero en una carpeta diferente. De esta manera mantenemos ambos tipos de clases separadas físicamente en disco (por motivos de organización y por claridad), pero accesibles gracias a que virtualmente pertenecen al mismo paquete, y por tanto entre ellos hay visibilidad de tipo package-default (esto puede resultarnos útil si necesitamos, por ejemplo, acceder desde la clase de tests a métodos en las respectivas clases de negocio que han sido declarados como 'protected'). En la pestaña 'Project Explorer' haz click con el botón derecho en la carpeta 'ejbModule' (la carpeta por defecto que crea Eclipse en un proyecto EJB para almacenar nuestras clases) y selecciona:

New > Class

Introduce en el campo 'Package' el nombre del paquete donde vamos a almacenar la clase de negocio (en mi caso 'es.davidmarco.ejb.slsb') y en el campo 'Name' el nombre de la clase de negocio; para este último caso es conveniente usar el nombre de la clase de tests sin el sufijo 'Test' (en mi caso 'PrimerEJB') de manera que podamos asociar visualmente en el explorador del IDE cada clase de negocio ('Xxx') con su clase de tests ('XxxTest'). Haz click en el botón 'Finish' para crear la clase de negocio y añade la lógica de negocio (comienza con la solución mas simple posible):



package es.davidmarco.ejb.slsb;



public class PrimerEJB {

    public String saluda(String nombre) {

        return null;

    }

}

Si en este punto ejecutamos el test que hemos escrito (haciendo click con el botón derecho sobre el editor donde tenemos el código del test y seleccionando 'Run As > JUnit Test') este fallará (verás una barra de color rojo que indica que al menos un tests no ha pasado correctamente). Si observas la ventana 'Failure trace' (seguimiento de fallos) de la pestaña de resultados de JUnit, verás un mensaje que, traducido a español, indica que se esperaba como respuesta 'Hola Usuario' pero se recibió 'null'. Debajo de este mensaje puedes ver la pila de llamadas que ha generado el error, en nuestro caso ha sido la función estática AssertEquals de JUnit. Volvamos al editor donde tenemos la clase de negocio y arreglemos el código que está fallando:



package es.davidmarco.ejb.slsb;



public class PrimerEJB {

    public String saluda(String nombre) {

        return "Hola usuario";

    }

}

Si ahora ejecutamos el test, veremos en la pestaña de JUnit que la barra es ahora de color verde, lo cual indica que todos los tests se han ejecutado sin fallos (la ventana 'Failure Trace' esta ahora vacía, evidentemente). Ahora decidimos que, cuando un cliente pase un argumento de tipo null a nuestra función, esta deberá devolver un saludo por defecto. Renombremos el nombre del primer test que hemos escrito y escribamos un segundo test que pruebe esta nueva condición (desde ahora y hasta el final de esta sección omitiré en ambas clases las sentencias package e import por claridad):



public class PrimerEJBTest {

    @Test

    public void testSaludaConNombre() {

        PrimerEJB ejb = new PrimerEJB();

        assertEquals("Hola usuario", ejb.saluda("usuario"));

    }

    

    @Test

    public void testSaludaConNull() {

        PrimerEJB ejb = new PrimerEJB();

        assertEquals("Hola desconocido", ejb.saluda(null));

    }

}

Como se dijo previamente, mediante TDD estamos dejando claras las intenciones de nuestro código antes incluso de escribirlo, como se puede ver en el segundo tests. En él, esperamos recibir como respuesta la cadena de texto 'Hola desconocido' cuando invoquemos el método saluda() con un argumento de tipo null. Y mientras tanto, el primer test (que hemos renombrado para darle más claridad y expresividad a nuestros tests) debe seguir pasando, por supuesto. Ejecutamos los tests ('Run As > JUnit Test') y el nuevo test que hemos escrito falla (podemos ver en la ventana a la izquierda de la pestaña de JUnit el/los test/s que ha/n fallado marcados con una cruz blanca sobre fondo azul). Volvamos al editor donde estamos escribiendo la lógica de negocio e implementemos la nueva funcionalidad:



public class PrimerEJB {

    public String saluda(String nombre) {

        if(nombre == null) {

            return "Hola desconocido";

        }

        

        return "Hola usuario";

    }

}

Ahora ambos tests pasan. Para terminar, ¿que ocurriría si en lugar de la cadena de texto 'usuario' pasamos al método saluda() una cadena de texto distinta?. Añadamos un test que pruebe esta condición:



public class PrimerEJBTest {

    @Test

    public void testSaludaConNombre() {

        PrimerEJB ejb = new PrimerEJB();

        assertEquals("Hola usuario", ejb.saluda("usuario"));

    }

    

    @Test

    public void testSaludaConOtroNombre() {

        PrimerEJB ejb = new PrimerEJB();

        assertEquals("Hola Pedro", ejb.saluda("Pedro"));

    }

    

    @Test

    public void testSaludaConNull() {

        PrimerEJB ejb = new PrimerEJB();

        assertEquals("Hola desconocido", ejb.saluda(null));

    }

}

Este último test demuestra, al ejecutarse y fallar, que nuestra lógica de negocio contiene un bug: siempre que invocamos el método saluda() con un parámetro de tipo String (diferente de null) obtenemos la cadena de texto 'Hola usuario', ignorando así el parametro que le hemos pasado. He aquí otra ventaja más que surje del uso de TDD: descubrir bugs lo antes posible. Cuanto más tiempo tardemos en descubrir un bug, más dificil nos resultará encontrarlo y solucionarlo. Vamos a resolver este último error en nuestra lógica de negocio:



public class PrimerEJB {

    public String saluda(String nombre) {

        if(nombre == null) {

            return "Hola desconocido";

        }

        

        return "Hola " + nombre;

    }

}

Ahora todos los tests pasan. Aunque aún nos quedaría la tarea de refactorizar los tres métodos de tests (hay código redundante en todos ellos) y tal vez añadir algún test más (o eliminar...), vamos a dejar las cosas aquí. TDD es un tema demasiado amplio y complejo que está fuera del propósito de este tutorial. Aunque este ejemplo ha sido extremadamente simple/tonto/llamalo-como-quieras, nos ha servido para demostrar lo facil que es diseñar un componente EJB paso a paso y libre de errores. Nadie quiere software que falle, y por tanto debes tomarte la tarea de testear el código que escribes muy en serio. Test-Driven Development es una manera muy sencilla y divertida de diseñar software de calidad.

1.7 DESPLEGANDO NUESTRO PRIMER EJB
Hasta ahora hemos tratado la clase PrimerEJB como si fuera un componente EJB. Pero lo cierto es que no es así (en otras palabras, te he mentido, aunque espero que puedas perdonarme...). Para que nuestro POJO sea reconocido por nuestro contenedor como un componente EJB verdadero tenemos que decirle que lo es:



package es.davidmarco.ejb.slsb;



import javax.ejb.Stateless;



@Stateless

public class PrimerEJB {

    // ...

}

La anotación @Stateless define nuestro POJO como un Session Bean de tipo Stateless y una vez desplegado en un contenedor EJB, este lo reconocerá como un componente EJB que podremos usar. ¡Así de simple!. Sin embargo, debemos añadir una segunda anotación a nuestro (ahora si) componente EJB:



package es.davidmarco.ejb.slsb;



import javax.ejb.Remote;

import javax.ejb.Stateless;



@Remote

@Stateless

public class PrimerEJB {

    public String saluda(String nombre) {

        if(nombre == null) {

            return "Hola desconocido";

        }

        

        return "Hola " + nombre;

    }

}

La anotación @Remote permite a nuestro EJB ser invocado remotamente (esto es, desde fuera del contenedor). Si omitimos esta anotación, el EJB sería considerado como 'Local' (concepto que veremos en el próximo artículo) y solo podría ser invocado por otros componentes ejecutandose dentro del mismo contenedor. Nosotros la hemos incluido pues en la próxima sección vamos a escribir un cliente Java externo al contenedor que solicitará a este el componente que estamos diseñado. De manera adicional, todos los componentes que sean de tipo remoto (como este) deben extender una interface (o de lo contrario se producirá un error durante el despliegue):



package es.davidmarco.ejb.slsb;



public interface MiInterfaceEJB {

    public String saluda(String nombre);

}

Por último modificamos nuestro EJB para que implemente la interface y el despliegue sea correcto:



@Remote

@Stateless

public class PrimerEJB implements MiInterfaceEJB {

    // ...

}

La necesidad de una interface para componentes de tipo remoto, aunque que a priori pueda parecer una restricción (o una limitación), es necesaria para que el contenedor pueda construir la vista/proxy que será enviada a los clientes remotos (externos al contenedor) por motivos que no vienen al caso. Además, se considera una buena práctica que nuestras clases y métodos de negocio se construyan sobre interfaces: de esta manera los clientes que usan nuestro código trabajan con la interface, ignorando la implementación concreta. De esta manera podemos cambiar dicha implementación en el futuro sin romper el código de nuestros clientes.

Ahora ya podemos desplegar nuestra primera aplicación EJB en el contenedor. En la pestaña 'Project Explorer' haz click con el botón derecho sobre el nombre del proyecto, y selecciona:

    Run As > Run on Server

Durante el primer despliegue nos aparecerá una ventana donde podemos seleccionar el servidor donde deseamos realizar el despliegue (aparecerá por defecto el que definimos al crear el proyecto). Seleccionamos la casilla 'Always use this server when running this project' (Usar siempre este servidor cuando se ejecute este proyecto) y hacemos click en el botón 'Finish'. La pestaña 'Console' se volverá activa y en ella veremos multitud de información relativa al proceso de arranque del servidor (puesto que no estaba arrancado). Tras unos momentos (30-40 segundos en mi equipo) el contenedor se habra levantado, y con él nuestra aplicación EJB. Entre los últimos mensajes de arranque del servidor puedes ver los siguientes:

    PrimerEJB/remote - EJB3.x Default Remote Business Interface
    PrimerEJB/remote-es.davidmarco.ejb.slsb.InterfaceEJB - EJB3.x Remote Business Interface

Esas dos lineas nos indican dos referencia JNDI válidas al componente EJB que hemos desplegado, y las necesitaremos cuando escribamos el cliente para que el contenedor nos devuelva el objeto correcto.

Antes de finalizar esta sección, veamos un último asunto relativo al despliegue. Una vez que ya tenemos desplegada nuestra aplicación en JBoss, si realizamos un cambio en nuestra lógica de negocio y deseamos volver a desplegar la aplicación en el contenedor, debemos hacerlo desde la pestaña 'Servers' de Eclipse (y no desde la pestaña 'Project Explorer' como hicimos la primera vez que desplegamos la aplicación). Para ello, primero abrimos la pestaña 'Servers' si no es visible en el Workbench de Eclipse:

    Window > Show Views > Servers

Si miramos a la recién abierta pestaña 'Servers' veremos la instancia de JBoss asociada a nuestro proyecto, y junto a ella una flecha. Pinchamos en esta flecha para expandir el servidor y veremos nuestro proyecto EJB. Hacemos click con el botón derecho sobre el nombre del proyecto y seleccionamos 'Full Publish'. En unos segundos nuestro proyecto estará re-desplegado (puedes ver el proceso en la pestaña 'Console').

Por otro lado, cuando iniciemos el IDE y queramos acceder a una aplicación desplegada con anterioridad (por ejemplo desde un cliente como el que vamos a construir en la próxima sección) debemos iniciar primero el servidor, evidentemente. Para ello, haz click con el botón derecho sobre el nombre del servidor en la pestaña 'Servers' y selecciona 'Start'.

1.8 EL CLIENTE JAVA
Ahora es el momento de escribir el cliente Java, el cual va a hacer una solicitud al contenedor mediante JNDI para obtener el Stateless Session Bean que hemos creado en la sección 1.6 y desplegado en la sección 1.7. Con esto veremos como el contenedor gestiona todo el ciclo de vida de una aplicación EJB así como de sus componentes, mientras los clientes solo tienen que preocuparse de solicitar el componente que necesiten y usarlo. Lo primero es crear un nuevo proyecto Java:

    File > New > Other

Seleccionamos 'Java Project', hacemos click en 'Next', le damos un nombre al proyecto y hacemos click en 'Finish'. En la pestaña 'Project Explorer' expandimos el proyecto pinchando en la flecha que aparece a la izquierda de su nombre y en la carpeta 'src' creamos un nuevo paquete (muy recomendado) haciendo click con el botón derecho y seleccionando:

    New > Package

Le damos un nombre al paquete (en mi caso 'es.davidmarco.ejb.cliente') y hacemos click en 'Finish'. Volvemos a hacer click con el botón derecho sobre el paquete recién creado y seleccionamos:

    New > Class

En la ventana que nos aparecerá le damos un nombre a la clase (en mi caso 'Cliente') y marcamos la casilla 'public static void main(String[] args)' para que nos cree un método main() automáticamente, y hacemos click en el botón 'Finish'.

Antes de mostrar el código del cliente es preciso mencionar que para ejecutarlo se necesitan ciertas librerias que, por motivos de simplicidad, vamos a obtener del primer proyecto (la aplicación EJB). Para ello, en la pestaña 'Project Explorer' haz click con el botón derecho sobre el nombre del proyecto que hace de cliente y selecciona:

    Build Path > Configure Build Path

En la ventana que se abrirá seleccionamos la pestaña 'Projects', hacemos click en el botón 'Add', y marcamos la casilla correspondiente al proyecto donde está la aplicación EJB que hemos desplegado (y que, repito, contiene todas las librerias que necesita el cliente). Para finalizar, hacemos click en el botón 'OK', y de nuevo hacemos click en el botón 'OK'. El código del cliente es el siguiente:



package es.davidmarco.ejb.cliente;



import java.util.Properties;

import javax.naming.Context;

import javax.naming.InitialContext;

import javax.naming.NamingException;

import es.davidmarco.ejb.slsb.MiInterfaceEJB;



public class Cliente {

    

    private static final String JNDI_PRIMER_EJB = "PrimerEJB/remote";



    public static void main(String[] args) throws NamingException {

        Properties properties = new Properties();

        properties.put("java.naming.factory.initial", "org.jnp.interfaces.NamingContextFactory");

        properties.put("java.naming.factory.url.pkgs", "org.jboss.naming:org.jnp.interfaces");

        properties.put("java.naming.provider.url", "jnp://localhost:1099");

        Context context = new InitialContext(properties);

        

        MiInterfaceEJB bean = (MiInterfaceEJB) context.lookup(JNDI_PRIMER_EJB);

        String respuesta = bean.saluda("Cliente Java");

        System.out.println(respuesta);

    }

}

El cliente contiene una constante llamada JNDI_PRIMER_EJB a la que le hemos dado el valor de la referencia JNDI a nuestro componente (recuerda que este valor nos los dio el contenedor cuando desplegó la aplicación, como vimos al final de la sección 1.7). Dentro del método main() creamos un objeto de propiedades, introducimos los valores necesarios para acceder al contexto del contenedor EJB, y creamos dicho contexto mediante un objeto InitialContext y el objeto de propiedades que acabamos de crear y configurar.

A continuación viene lo realmente interesante: no obtenemos un objeto de tipo InterfaceEJB mediante el constructor new (como haríamos en una aplicación Java normal), si no que se lo solicitamos al contenedor EJB a traves del método lookup() del contexto que acabamos de crear. A este método le hemos pasado el nombre de la referencia JNDI del componente que queremos obtener. Recuerda que cuando solicitamos al contenedor un componente de tipo Session Bean (ya sea Stateless, Stateful, o Singleton) lo que obtenemos no es una instancia del componente EJB (en nuestro caso PrimerEJB), si no una vista (un objeto proxy) que sabe como alcanzar el objeto real dentro del contenedor.

Una vez que tenemos la vista podemos ejecutar cualquiera de los métodos que definimos en su interface asociada (MiInterfaceEJB). Para ejecutar el cliente nada tan sencillo como hacer click con el botón derecho sobre el editor donde lo tenemos y seleccionar:

Run As > Java Application

En la pestaña 'Console' aparecera el resultado de la ejecución del cliente. A modo de experimento puedes cambiar la invocación al método saluda(), pasarle un valor null en lugar de una cadena de texto, volver a ejecutar el cliente, y ver la respuesta del componente EJB.

1.9 RESUMEN
Este primer artículo del tutorial de introducción a EJB 3.1 ha sido muy fructífero. En el hemos visto de manera superficial los conceptos básicos de la especificación EJB, una breve introducción al contenedor EJB, los tipos de componentes que podemos producir, un sencillo ejemplo de Test-Driven Development + EJB, la forma de desplegar dicho ejemplo en un contenedor compatible con EJB, y como acceder al componente (a través del contenedor) desde un cliente Java.

En el próximo artículo veremos en profundidad dos de los tres tipos de componentes de tipo Session Bean: Stateless Session Beans y Stateful Session Beans. Hasta entonces, ¡felices despliegues!.

Introducción a EJB 3.1 (II)

programacion@davidmarco.es (David Marco) — Fri, 18 Mar 2011 11:55:00 +0100

En el artículo anterior del tutorial de EJB 3.1 vimos de manera superficial que representa la especificación EJB, que es un contenedor, los tipos de componentes dentro de una aplicación EJB, y por último un sencillo ejemplo de desarrollo de una aplicación EJB 3.1 mediante Test-Driven Development. En este segundo artículo vamos a empezar a profundizar en algunos de esos temas, viendo dos de los tres tipos de Session Beans: Stateless y Stateful. Sin embargo, antes es necesario comprender algunos conceptos relacionados con la tecnología EJB, como el funcionamiento del pool, el uso de metadatos, componentes locales vs componentes remotos, inyección de dependencias, y contexto de sesión dentro de una aplicación EJB. Comencemos.

2.1 METADATOS
Como vimos en la primer artículo del tutorial, para declararar nuestros POJO's como verdaderos componentes EJB necesitamos usar metadatos. Estos metadatos pueden ser de dos tipos:

    - Anotaciones
    - XML

El uso de anotaciones es, a priori, el más sencillo y expresivo. Esta forma de aplicar información a nuestros componentes está disponible en la plataforma JavaEE desde su versión 5, y por tanto disponible también en JavaEE 6 (plataforma de la cual forma parte la especificación EJB 3.1). El único punto en contra del uso de anotaciones es que, si deseamos cambiar el comportamiento de un componente, debemos recompilar nuestro código (ya que la anotación acompaña al código Java). Por motivos de simplicidad, esta será la forma de metadatos que se utilizará durante todo el tutorial. Puedes consultar la referencia completa (en inglés) de las anotaciones soportadas en la especificación EJB 3.0 en la siguiente dirección.

El uso de XML para añadir metadatos a nuestro código es la forma heredada de versiones anteriores de la especificación JavaEE. Para ello, debemos incluir un archivo llamado ejb-jar.xml dentro del directorio META-INF del archivo jar/ear a desplegar. La ventaja del uso de XML como fuente de metadatos reside en que no es necesario recompilar nuestro código para cambiar el comportamiento de nuestros componentes, con todas las ventajas que esto puede suponer una vez que un proyecto se encuentra en producción. De manera adicional, al encontrarse los metadatos en un archivo externo, nuestro código Java no contiene ningún tipo de información relativa a la especificación EJB, y por tanto es más portable. Por contra, además de tener que mantener dos fuentes de información a la vez (el código Java y el archivo XML), el propio archivo XML puede ser dificil de mantener y entender cuando alcanza cierta longitud y complejidad. En este tutorial no se verán ejemplos de metadados en XML por motivos de simplicidad, aunque si deseas ampliar información puedes visitar el capítulo 19 de la especificación EJB 3.1, la cual puedes descargar desde la siguiente dirección.

Por último, debes tener muy presente que los metadatos en formato XML sobreescriben cualquier comportamiento ya expresado mediante anotaciones, siempre que ambos hagan referencia a un mismo componente. Por ello, una combinación de ambos tipos de metadatos sería perfectamente legal, aunque salvo honrosas excepciones, poco recomendable (puede inducir a la confusión, y por tanto a cometer errores).

2.2 EL POOL
Un pool es, expresado de forma básica, un almacén de objetos. El contenedor EJB mantiene uno o varios pools donde almacena componentes que están listos para ser servidos a un cliente que los solicite. De esta manera, el contenedor gestiona la creación, mantenimiento, y destrucción de componentes en segundo plano y de manera transparente a la aplicación EJB (mejorando así el rendimiento de esta última y de sus clientes).

Cuando un cliente obtiene una referencia, ya sea local (mediante @EJB, como veremos en la sección 2.5), o remota (mediante JNDI, como vimos en el ejemplo al final del artículo anterior), esta no apunta a ninguna instancia del componente en cuestión. Solamente cuando se invoca un método en dicha referencia, el contenedor extrae una instancia del pool y la asigna a dicha referencia, de manera que la invocación pueda tener efecto.

El comportamiento de multitud de aspectos del pool es configurable, aunque en este tutorial no necesitamos hacerlo en ningún momento. Los detalles concretos del funcionamiento del pool es algo que tampoco necesitamos saber de antemano para seguir el tutorial; cuando se necesite comprender un aspecto concreto de dicho funcionamiento, se explicará en la sección correspondiente.

2.3 LOCAL VS REMOTO
Como se explicó muy brevemente en el primer artículo del tutorial, un Session Bean puede ser declarado de tipo local o remoto. Un Session Bean declarado como local estará destinado a servir solicitudes de otros componentes dentro de la misma Java Virtual Machine (JVM - Máquina Virtual Java) donde está desplegado (dicho con otras palabras, dentro del contenedor donde se ejecuta la aplicación). El contenedor pasará la referencia que apunta al objeto en cuestión al cliente, pues dentro de la misma JVM está referencia es válida. Por contra, un Session Bean declarado como remoto está destinado a servir peticiones de clientes externos al propio contenedor (como vimos en el ejemplo al final del artículo anterior). En este caso, lo que se pasa es una copia del objeto en cuestión, pues para una JVM externa no tendrá ningun sentido una referencia a un objeto que no se encuentre en ella misma. Recuerda que esa copia no es una copia del componente EJB (una instancia del POJO desplegado en el contenedor), si no una vista/proxy que sabe como acceder a través de una red al objeto real.

La especificación EJB no permite que la interface (en el sentido de contrato) de un Session Bean sea declarada local y remota al mismo tiempo. Por tanto, lo siguiente no es válido y producirá un error al ser desplegado:



@Local

@Remote

@Stateless

public class MiBean implements MiInterfaceRemote {

    // esta clase produce un error al desplegar

}

En el ejemplo anterior, la clase MiBean actua como interface local y remota al mismo tiempo, lo cual no está permitido. Sin embargo, lo siguiente si que es válido:



@Local

public interface MiBeanLocalInterface {

    // declaración de métodos locales

}



@Remote

public interface MiBeanRemoteInterface {

    // declaración de métodos remotos

}



@Stateless

public class MiBean implements MiBeanLocalInterface, MiBeanRemoteInterface {

    // implementación de métodos locales y remotos

}

En el ejemplo anterior, declaramos una interface local y otra remota, y las implementamos en un Session Bean de tipo Stateless. De esta manera, el Session Bean podrá servir solicitudes de ambos tipos (cada una a través de la interface correspondiente). Otra forma de expresar lo mismo sería de la siguiente manera:



public interface MiBeanLocalInterface {}



public interface MiBeanRemoteInterface {}



@Local(PrimerBeanLocalInterface.class)

@Remote(PrimerBeanRemoteInterface.class)

@Stateless

public class MiBean implements MiBeanRemoteInterface {}

En el ejemplo anterior, hemos eliminado las anotaciones en las interfaces y las hemos aplicado a la clase MiBean. Añadiendo los argumentos correspondientes en @Local y @Remote le indicamos al contenedor que interface actuará como local y cual como remota. Seguimos teniendo que implementar la interface remota en la declaración de la clase (implements MiBeanRemoteInterface), pues como se vio en el artículo anterior, todo Session Bean declarado como remoto necesita implementar una interface de manera obligatoria (dicha interface es necesaria para la creación del proxy/vista).

Por supuesto también podemos aprovechar las características de polimorfismo y herencia en Java para crear nuestros componentes:



public interface MiInterfaceBase {

    // contrato general para todas las interfaces que hereden de esta

}



public interface MiInterfaceLocal extends MiInterfaceBase {

    // contrato concreto para acceso local

}



public interface InterfaceRemote extends MiInterfaceBase {

    // contrato concreto para acceso remoto

}



public abstract class MiBeanBase implements MiInterfaceBase {

    // implementación general para todas las clases que hereden de esta

}



@Stateless

@Local(MiInterfaceLocal.class)

public class MiBeanLocal extends MiBeanBase implements MiInterfaceLocal {

    // implementación concreta para acceso local

}



@Stateless

@Remote(MiInterfaceRemote.class)

public class MiBeanRemote extends MiBeanBase implements MiInterfaceRemote {

    // implementación concreta para acceso remoto

}

En este tutorial los ejemplos se mantendrán siempre lo más simple posibles, pues a efectos lectivos toda la parafernalia del ejemplo anterior no es necesaria (de hecho es contraproducente). El aspecto clave a recordar estriba en no declarar una misma interface (repito, en el sentido de contrato) de tipo local y remota al mismo tiempo.

2.4 EJB CONTEXT Y SESSION CONTEXT
A veces, necesitamos acceder al contexto de ejecución del componente que se está usando. EJBContext (Contexto de EJB) es una interface que provee acceso al contexto de ejecución asociado a cada instancia de un componente EJB. A través de él podemos acceder, por ejemplo, al servicio de seguridad: imaginemos que invocamos un método en un Session Bean dentro de una aplicación donde hay restricciones de seguridad, de manera que el Session Bean necesita comprobar si el cliente que lo está invocándo está autorizado o no a hacerlo. A través del contexto de ejecución de dicho Session Bean podemos acceder al servicio de seguridad y realizar dicha comprobación. Otros ejemplos del uso del contexto de ejecución son el acceso a transacciones, u obtener el Timer Service (Servicio de Reloj, necesario para programar eventos mediante unidades de tiempo, como veremos en un artículo posterior).

SessionContext (Contexto de Sesión) es una interface que implementa EJBContext, añadiendo métodos que permiten el uso de servicios adicionales. A través de él podemos, por ejemplo, obtener una referencia al Session Bean actual para poder pasarla a otro Session Bean como argumento de un método; esto es necesario, pues el contenedor no permite pasar el Session Bean actual usando una referencia de tipo this (los detalles de porqué esto es así no son necesarios para entender el material, y por tanto los omito). Podemos acceder al contexto de sesión asociado a la instancia del componente actual mediante inyección de dependencia (asunto que se explicará en la sección 2.5):



@Local

@Stateless

public class MiBean {

    @Resource

    private SessionContext contexto;



    // ...

}

Mediante la anotación @Resource (Recurso) indicamos al contenedor que debe inyectar el contexto de sesión asociado a dicha instancia en la variable contexto (cuando veamos el ciclo de vida de los componentes EJB se verá cómo y cuándo se realiza esta operación). Otra manera de acceder al contexto de sesión es usando la misma anotación, pero sobre un método setter que siga el estandar JavaBean (no confundir con Enterprise JavaBean):



@Local

@Stateless

public class MiBean {

    private SessionContext contexto;

    

    @Resource

    public void setContexto(SessionContext contexto) {

        this.contexto = contexto;

    }



    // ...

}

Puesto que SessionContext extiende EJBContext, podemos acceder a ambas interfaces desde la primera. Es muy importante que tengas presente que ciertos métodos en EJBContext están marcados como deprecated, y además lanzarán una excepción de tipo RuntimeException si son invocados. Te recomiendo que, por este motivo, consultes la API de EJBContext en la siguiente dirección.

2.5 INYECCIÓN DE DEPENDENCIAS
La inyección de dependencias (Dependency Injection) es un proceso por el cual el contenedor puede inyectar en un componente recursos que son necesarios. Un ejemplo de inyección de dependencia lo vimos en la sección anterior, donde usamos la anotación @Resource para inyectar una instancia de SessionContext en un SLSB. Otro ejemplo de inyección de dependencia surje cuando uno de nuestros componentes necesita de otro componente:



@Stateless

public class UnComponente {

    private OtroComponente dependencia;

    

    public String metodo() {

        return dependencia.otroMetodo();

    }

}

En el ejemplo anterior, el Session Bean UnComponente requiere otro Session Bean de tipo OtroComponente. Puesto que, como ya se ha explicado, el contenedor EJB gestiona el ciclo de vida de todos los componentes (toda la aplicación EJB funciona en un entorno gestionado), una instanciación del tipo new OtroComponente() sería incorrecta (esta instancia no tendría, por ejemplo, un contexto de sesión asociado, pues ha sido inicializada manualmente). La solución consiste en informar al contenedor de dicha dependencia mediante la anotación @EJB, dejando así en sus manos esta tarea:



@Local

@Stateless(name="otroComponente")

public class OtroComponente {

    public String otroMetodo() { 

        // ... 

    }

}



@Stateless

public class UnComponente {

    @EJB(beanName="otroComponente")

    private OtroComponente dependencia;

    

    public String metodo() {

        return dependencia.otroMetodo();

    }

}

Gracias a la anotación @EJB el contenedor sabe que componente instanciar, inicializar, y finalmente inyectar en la variable dependencia. En el ejemplo anterior, se registra un Session Bean con nombre otroComponente (gracias a @Stateless(name="otroComponente")), el cual puede ser accedido mediante inyección de dependencia gracias a @EJB(beanName="otroComponente").

La inyección de dependencias es una poderosa carecterística de EJB que libera al programador de muchas responsabilidades, ademas de resultar en código poco acoplado y apto para unit testing (entre otras buenas cualidades). Puedes encontrar más información sobre la anotación @EJB en la aquí y sobre la anotación @Resource aquí (ambas páginas en inglés).



2.6 COMPONENTES DEL LADO DEL SERVIDOR
La primera pregunta que nos debemos hacer es: ¿Que es un componente del lado del servidor?. No es ni más ni menos que un componente que es gestionado de manera integra por el contenedor. Esto es, el cliente del componente no interacciona con el componente en si, si no con una representación (referencia/proxy/vista) del componente real. Los componentes del lado del servidor son dos:

    - Todos los Session Bean (Stateless, Stateful, y Singleton)
    - Message-Driven Beans

En este artículo veremos los dos primeros tipos de Session Beans, y dejaremos el componente Singleton y los Message-Driven Beans para el próximo artículo. Ahora otra buena pregunta sería: ¿Que NO es un componente del lado del servidor? La respuesta es: Entity Beans (EB - entidades). Los EB viajan entre el cliente y el servidor siendo siempre la representación del mismo objeto Java en ambos lados. Todo lo relacionado con EB se tratará en el capítulo relacionado con persistencia (si estás interesado en este tema puedes visitar un tutorial sobre Java Persistent API (JPA - API de Persistencia en Java) publicado en esta misma web en la siguiente dirección).

2.7 STATELESS SESSION BEANS: CONCEPTOS BÁSICOS
Como vimos brevemente en el primer artículo del tutorial, los Stateless Session Bean (SLSB - Session Bean Sin Estado) son aquellos que no mantienen estado entre diferentes invocaciones de sus métodos. Podriamos considerar cada método dentro de un SLSB como un servicio en si mismo, que realiza una tarea y devuelve un resultado (puede no hacerlo) sin depender de invocaciones anteriores o posteriores sobre él mismo o sobre otro método. Debido a este comportamiento, el contenedor puede utilizar un número relativamente bajo de SLSB's para servir llamadas de muchos clientes (ya que ninguno de estos clientes estará asociado a un SLSB en concreto), y por ello son muy eficientes. El hecho de no mantener un estado entre invocaciones los hace aún más eficientes.

Es importante destacar que un SLSB si puede mantener un estado interno, aunque este no debe escapar nunca hacia el cliente. Un ejemplo de este estado interno sería una variable que almacenara el número de veces que una instancia en concreto ha sido invocada: un cliente que dependa del valor de esta variable podría obtener un resultado distinto en cada llamada al SLSB, ya que el contenedor no garantiza devolver la misma instancia al mismo cliente. La regla es: si un SLSB mantiene estado, este debe ser interno (invisible para el cliente).

2.8 STATELESS SESSION BEANS: EL CICLO DE VIDA
El ciclo de vida de un componente describe los distintos estados (gestionados íntegramente por el contenedor) por los que puede pasar cada instancia del componente desde que es creada hasta que es destruida. Para los SLSB, este ciclo de vida es muy simple y consta únicamente de dos estados (incluyo el término original en inglés):

    - No existe (Does not exists)
    - Preparado en pool (Method-ready pool)

El primer estado, no existe, es autoexplicativo: la instancia del SLSB no ha sido creada aún. El segundo estado, Preparado en pool, representa una instancia del SLSB que ha sido instanciada y construida por el contenedor, y se encuentra en el pool lista para recibir invocaciones por parte de un cliente (cuando esta invocación sucede, la instancia es extraida el pool y asociada a una referencia que es pasada al cliente). A este estado se llega durante el arranque del contenedor (el pool es poblado con cierto número de instancias), y cuando no existan suficientes instancias en el pool para servir llamadas de clientes (y por tanto se deban crear más). En resumen, siempre que una nueva instancia del SLSB sea creada.

Durante la transición entre el primer estado y el segundo, el contenedor realizará tres operaciones (en este orden):

    - Instanciación del SLSB
    - Inyección de cualquier recurso necesario y de dependencias
    - Ejecución de un método dentro del SLSB marcado con la anotación @PostConstruct, si existe

La instanciación del SLSB se lleva a cabo mediante reflexión, a traves de Class.newInstance(). Por tanto, el SLSB debe tener un constructor por defecto (sin argumentos), ya sea de forma implícita o explícita.

La inyección de recursos y de dependencias se vio en las secciones 2.4 y 2.5, donde se utilizaron las anotaciones @Resource y @EJB para tales efectos. Estos y otros recursos son inyectados en el SLSB de forma automática por el contenedor durante esta operación. De manera adicional, cada vez que un SLSB sea invocado por un nuevo cliente, todos los recursos son inyectados de nuevo.

Por último, el contenedor ejecutará un método dentro del SLSB que esté anotado con @PostConstruct (Post construcción), si existe. Esta anotación declara dicho método (que puede ser uno y solo uno) como un método callback, esto es, un método que reacciona ante cierto evento (en este caso, a la construcción de la instancia, como su propio nombre indica). Dentro de este método tenemos la oportunidad de adquirir recursos adicionales necesarios para el SLSB, como una conexión de red o de base de datos. Este método debe ser void, no aceptar parámetros, y no lanzar ninguna excepción de tipo checked. Al contrario que la inyección de recursos, la ejecución del método @PostConstruct se ejecuta una y solo una vez (al final de la instanciación del componente).

Cuando el contenedor no necesita una instancia de SLSB, ya sea porque decide reducir el número de instancias en el pool, o porque se está produciendo un shutdown del servidor, se realiza una transición en sentido inverso: del estado preparado en pool al estado no existe. Durante esta transición se ejecutará, si existe, un método anotado con @PreDestroy (Pre destrucción), el cual es también un método callback, y el cual nos da la oportunidad de liberar cualquier recurso adquirido durante la construcción de la instancia (adquisición que hicimos en @PostConstruct). Al igual que ocurría con @PostConstruct, un método anotado con @PreDestroy es opcional, debe ser void, no aceptar parámetros, no lanzar ninguna excepción de tipo checked, solo puede ser usado en un único método, y es ejecutado una y solo una vez (durante la destrucción de la instancia).

2.9 STATELESS SESSION BEANS: UN SENCILLO EJEMPLO
Supongamos que estamos desarrollando una aplicación de banca, y entre otras cosas necesitamos escribir código que represente los conceptos de ingreso, retirada, y transferencia de efectivo. Estos tres conceptos son operaciones que no requieren mantener un estado dentro de la aplicación (esto es, una vez invocadas y terminadas no dependen de otras operaciones) y por tanto son excelentes candidatas para ser representadas mediante un Session Bean de tipo Stateless. Como ya hemos visto en multitud de ejemplos, para declarar un Session Bean de tipo Stateless utilizamos la anotación @Stateless (se omiten otras anotaciones como @Remote o @Local, así como todo código no estrictamente necesario para explicar el tema tratado; desde este momento se dará por hecho esto en la mayoría de los ejemplos que veamos):



package es.davidmarco.ejb.slsb;



import javax.ejb.Stateless;

import es.davidmarco.ejb.modelo.Cuenta;



@Stateless

public class OperacionesConEfectivo {

    public void ingresarEfectivo(Cuenta cuenta, double cantidad) {

        // ingresar cantidad en cuenta

    }



    public void retirarEfectivo(Cuenta cuenta, double cantidad) {

        //retirar cantidad de cuenta

    }



    public void transferirEfectivo(Cuenta cuentaOrigen, Cuenta cuentaDestino, double cantidad) {

        // transferir cantidad de cuenta origen a cuenta destino

    }

}

La clase Cuenta representa una cuenta bancaria, y teóricamente lo representaríamos mediante un componente de tipo Entity Bean (Bean de Entidad), los cuales veremos en el cuarto artículo de este tutorial. Lo realmente importante del ejemplo anterior es el concepto de operaciones que no requieren estado, y por tanto pueden ser representadas mediante Session Beans de tipo Stateless.

2.10 STATEFUL SESSION BEANS: CONCEPTOS BÁSICOS
Al contrario que los Session Bean de tipo Stateless, los Stateful Session Bean (SFSB - Session Bean con Estado) mantienen estado entre distintas invocaciones de un mismo cliente. Podríamos considerar un SFSB como una extensión del cliente en el contenedor, ya que cada SFSB está dedicado de manera exclusiva a un único cliente durante todo su ciclo de vida. Otra diferencia entre SLSB y SFSB es que estos últimos no son almacenados en un pool, pues no son reusados, como veremos en la sección 2.11 cuando expliquemos su ciclo de vida.

¿A que nos referimos cuando decimos que un SFSB mantiene un estado? La cuestión es simple: un SFSB almacena información a consecuencia de las operaciones que realiza en él su cliente asociado, y dicha información (estado) debe estar disponible en invocaciones posteriores. De esta manera, un SFSB puede realizar una acción compleja mediante multiples invocaciones. Un ejemplo muy común es el carrito de la compra de una tienda online; añadimos y eliminamos artículos del carrito en diferentes invocaciones, lo cual sería imposible de realizar con un SLSB.

A pesar de mantener estado, un SFSB no es persistente, de manera que dicho estado se pierde cuando la sesión del cliente asociado termina. Su misión es servir como lógica de negocio (misión de todos los Session Bean) y nada más. Para persistir dicha información deberemos usar otro tipo de componente EJB (Entity Bean) el cual veremos en el artículo sobre persistencia.

2.11 STATEFUL SESSION BEANS: EL CICLO DE VIDA
El ciclo de vida de un SFSB es ligeramente más complejo que el de su hermano pequeño SLSB, y consta de tres estados:

    - No existe (Does not exists)
    - Preparado (Method-ready)
    - Pasivo (Passive)

El primer estado, no existe, es similar al de un SLSB: la instancia del SFSB no ha sido creada aún. El segundo estado, preparado, representa una instancia del SFSB que ha sido construida e inicializada, y está lista para servir llamadas de su cliente asociado (recuerda que esta asociación perdura durante toda la vida del SFSB). El tercer estado, pasivo, representa un SFSB que, después de un periodo de inactividad, es persistido temporalmente para liberar recursos del servidor.

Durante la transición entre el primer estado y el segundo, el contenedor realizará las siguientes tres operaciones:

    - Instanciación del SFSB
    - Inyección de cualquier recurso necesario y de dependencias, y asociación con el cliente
    - Ejecución de un método dentro del SFSB marcado con la anotación @PostConstruct, si existe

La instanciación del SFSB se lleva a cabo mediante reflexión, a traves de Class.newInstance(). Por tanto, el SFSB debe tener un constructor por defecto (sin argumentos), ya sea de forma implícita o explícita.

La inyección de recursos y de dependencias se vio en las secciones 2.4 y 2.5, donde se utilizaron las anotaciones @Resource y @EJB para tales efectos. Estos y otros recursos son inyectados en el SFSB de forma automática por el contenedor durante esta operación. Una vez finaliza la inyección de recursos y dependencias, el SFSB es asociado al cliente que ha generado su creación.

Por último, el contenedor ejecutará un método dentro del SFSB que esté anotado con @PostConstruct (Post construcción), si existe. Esta anotación declara dicho método (que puede ser uno y solo uno) como un método callback, esto es, un método que reacciona ante cierto evento (en este caso, a la construcción de la instancia, como su propio nombre indica). Al igual que con un SLSB, la función de este método es adquirir recursos adicionales que sean necesarios para el SFSB, como una conexión de red o de base de datos. Y también al igual que su homónimo en un SLSB, este método debe ser void, no aceptar parámetros, no lanzar ninguna excepción de tipo checked, y no ser static ni final. La ejecución del método @PostConstruct se ejecuta una y solo una vez, al final de la instanciación del componente. En este momento, el SFSB ya se encuentra en el estado preparado, y procede a servir la llamada del cliente que ha generado la creación de la instancia.

Por último, un SFSB en estado preparado puede realizar una transición a cualquiera de los otros dos estados de su ciclo de vida: no existe o pasivo. La transición al estado no existe ocurre cuando:

    - El cliente ejecuta un método dentro del SFSB anotado con @Remove
    - El SFSB sobrepasa un periodo de inactividad establecido (timeout)

En el primer caso, la ejecución de un método anotado con @Remove informa al contenedor que el cliente ha terminado de usar su SFSB asociado y, por tanto, dicha instancia ya no es necesaria. En este momento la instancia es desasociada de su contexto de sesión y eliminada. Este método no es de tipo callback (como @PostConstruct o @PreDestroy), pues no reacciona a un evento, si no que es ejecutado explicitamente por el cliente. En el segundo caso (timeout), el SFSB ha sobrepasado un periodo de tiempo establecido y el contenedor decide eliminarlo, previa ejecución de un método (uno y solo uno) anotado con @PreDestroy, y con iguales reglas que en su homónimo en SLSB: opcional, void, sin parámetros, sin excepciones de tipo checked, no static, y no final.

Por otro lado, la transición al estado pasivo se produce cuando el contenedor decide liberar recursos, persistiendo de manera temporal el estado del SFSB. La pasivación y posterior activación de un SFSB requiere una sección exclusiva que veremos enseguida.

Por finalizar con el ciclo de vida de un componente SFSB, ten presente que si este lanza una excepción de sistema (cualquiera de tipo unchecked cuya definición no esté anotada con @ApplicationException), se producirá una transición al estado no existe sin llamar a su método @PreDestroy. Este comportamiento no está muy bien comprendido entre cierta parte de la comunidad, pues a todas luces no parece muy correcto, pero es así y debes tenerlo en cuenta.

2.12 STATEFUL SESSION BEANS: PASIVACIÓN Y ACTIVACIÓN
Durante la vida de un SFSB, el contenedor puede decidir liberar recursos persistiendo de manera temporal el estado de dicho SFSB, liberando de esta manera memoria del sistema (u otros recursos). A esto lo llamamos pasivación. Si durante la pasivación el cliente realiza una llamada al SFSB, el contenedor recreará en memoria la instancia persistida y procedera con dicha llamada; a esto lo llamamos activación. Todo el ciclo de activación-pasivación puede ocurrir múltiples veces en la vida de un SFSB, o ninguna en absoluto. Sea como sea, es un proceso gestionado por el contenedor y totalmente transparence al cliente, el cual no sabe en ningún momento si se ha producido una pasivación o activación del SFSB asociado a su sesión.

No toda la información (estado) almacenada en un SFSB puede ser persistida. Los siguientes tipos son pasivados por defecto:

    - Todos los tipos primitivos
    - Objetos que implementan la interface Serializable
    - Referencias a factorias de recursos gestionados por el contenedor (como javax.sql.DataSource)
    - Referencias a otros componentes EJB
    - javax.ejb.SessionContext
    - javax.jta.UserTransaction
    - javax.naming.Context
    - javax.persistence.EntityManager
    - javax.persistence.EntityManagerFactory

Para todos los demás tipos, la especificación EJB nos proporciona dos métodos callback para controlar la pasivación-activación de un SFSB cuando existen datos que no deben/pueden ser persistidos: @PrePassivate (Pre-pasivación) y @PostActivate (Post-activación). Ambas anotaciones son aplicadas en métodos dedicados a controlar cada uno de los procesos, según corresponda (en la sección 2.13 veremos un ejemplo de un SFSB con métodos de pasivación y activación).

@PrePassivate nos permite anotar un método (opcional) que deje el SFSB es un estado adecuado para su pasivación. Puesto que la pasivación se lleva a cabo mediante serialización, todas las referencias a objetos no serializables deben ser puestas a null. Otra operacion llevada a cabo mediante @PrePassivate es la liberación de recursos que no pertenezcan a la lista anterior. Una vez ejecutado el método @PrePassivate, el SFSB es serializado y persistido temporalmente (tal vez en disco, en una cache, etc; esto es decisión de cada implementación de EJB). Es importante tener en cuenta que si un SFSB en estado pasivo sobrepasa un periodo de inactividad establecido (timeout), el contenedor eliminará la instancia persistida sin ejecutar su método @PreDestroy.

Si durante la pasivación el cliente asociado realiza una llamada al SFSB, el contenedor realizará la activación del componente, deserializando la instancia desde el lugar donde se encuentra persistida, restaurándola al estado anterior a producirse la pasivación (inyección del contexto de sesión, inyección de referencias a otros componentes EJB, etc), y ejecutando un método anotado con @PostActivate (también opcional). En este método podemos inicializar todos los objetos no serializables a unos valores adecuados (no debes confiar en los valores por defecto que el contenedor da a objetos no serializables, pues entre implementaciones pueden ser diferentes), así como restaurar cualquier recurso necesario para el correcto funcionamiento del SFSB. Una vez que la activación ha concluido, el SFSB puede gestionar la llamada del cliente que generó dicha activación.

Tanto @PrePassivate como @PostActivate deben seguir las siguientes reglas:

    - El tipo de retorno debe ser void
    - No puede aceptar ningún parámetro
    - No puede lanzar ninguna excepción de tipo checked
    - No puede ser static ni final

Estas reglas son las que se han aplicado a todos los métodos callback vistos hasta ahora, por lo que una vez aprendidas podrás aplicarlas fácilmente cuando escribas cualquier método callback.



2.13 STATEFUL SESSION BEANS: UN EJEMPLO SENCILLO
Supongamos que estamos diseñando una aplicación de tienda online, con un carrito de la compra donde los clientes pueden añadir artículos, eliminarlos, vaciar el carrito, o realizar un pedido. Puesto que cada una de estas operaciones se lleva a cabo de manera independiente a las demas, pero los cambios de cada una de ellas pueden afectar al resto, necesitamos mantener un estado entre distintas invocaciones, y por tanto un componente Session Bean de tipo Stateful. Para declarar un SFSB usamos la anotación @Stateful y hacemos que la clase en cuestión implemente la interface Serializable (puesto que es este el mecanismo que utilizará el contenedor para la pasivación-activación). El ejemplo, como siempre, es una estructura básica sin apenas implementación: el objetivo del ejemplo es únicamente mostrar donde encaja cada pieza:



package es.davidmarco.ejb.sfsb;



import java.io.Serializable;

import java.util.HashMap;

import java.util.Map;

import javax.annotation.PostConstruct;

import javax.annotation.PreDestroy;

import javax.ejb.PostActivate;

import javax.ejb.PrePassivate;

import javax.ejb.Remove;

import javax.ejb.Stateful;

import es.davidmarco.ejb.modelo.Articulo;

import es.davidmarco.ejb.util.BaseDeDatos;



@Stateful

public class Carrito implements Serializable {

    private Map articulosEnCarrito = new HashMap();

    private BaseDeDatos bbdd;

    

    public void añadirArticulo(Articulo articulo, int cantidad) { 

        // añadir la cantidad de cierto artículo al carrito

    }

    

    public void eliminarArticulo(Articulo articulo, int cantidad) { 

        // eliminar la cantidad de cierto artículo del carrito

    }

    

    public void vaciarCarrito() { 

        // vaciar el carrito

    }

    

    @Remove

    public void finalizarCompra() {

        // procesar el pedido

    }

    

    @PostConstruct

    @PostActivate

    private void inicializar() {

        // obtener conexión con la base de datos

    }

    

    @PrePassivate

    @PreDestroy

    private void detener() {

        // liberar conexión con la base de datos

    }

}

Como puedes ver, la clase Carrito está anotada con @Stateful y marcada como Serializable. Dentro de ella tenemos dos campos: artículosEnCarrito, donde se almacena el estado requerido para el correcto funcionamiento del proceso de compra (HashMap es de tipo Serializable y por tanto es persistida de forma automática en caso de pasivación), y BaseDeDatos, que es una clase ficticia que supuestamente nos permite realizar operaciones sobre una base de datos, pero no puede ser pasivada (supongamos que mantiene una conexión con una base de datos real que no puede permanecer abierta durante la pasivación).

Dentro de la clase, los cuatro primeros métodos nos permiten realizar operaciones de lógica de negocio, como añadir cierta cantidad de cierto artículo al carrito, vaciar el carrito completamente, o procesar el pedido una vez añadidos los artículos deseados. El cuarto método (finalizarCompra), de manera adicional, indica al contenedor que hemos terminado de trabajar con el componente SFSB y que por tanto puede eliminarlo (gracias a la anotación @Remove). Estos cuatro métodos son la interface que mostramos al cliente, y por tanto todos ellos son declarados public.

Los dos últimos métodos (inicializar y detener) se encargar de obtener y liberar recursos en momentos clave del ciclo de vida del SFSB. Fíjate como @PostConstruct y @PostActivate anotan el mismo método, pues todas las operaciones que hay en él son comunes a los procesos de construcción del SFSB y una posible activación posterior. De igual manera, @PrePassivate y @PreDestroy acompañan al mismo método, por el mismo motivo. Ambos métodos, de tipo callback, son gestionados por el contenedor en base a eventos, y por tanto el cliente del SFSB no necesita saber de su existencia (nosotros los hemos declarado private, aunque cualquier nivel de visibilidad está permitido).

2.14 RESUMEN
En este segundo artículo del tutorial de EJB hemos visto conceptos relacionados con la tecnología EJB, como la definición del pool, local vs remoto, metadatos, inyección de dependencias, y contexto de sesión. Ademas, hemos visto en cierta profundidad los dos tipos de Session Bean más comunes: Stateless y Stateful.

En el próximo artículo veremos el tercer y último tipo de Session Bean (Singleton) así como un nuevo tipo de componente: Message-Driven Beans. Hasta entonces, ¡feliz inyección de dependencias!

Introducción a EJB 3.1 (III)

programacion@davidmarco.es (David Marco) — Mon, 28 Mar 2011 22:11:52 +0200

En el artículo anterior vimos algunos conceptos comunes a los componentes de una aplicación EJB, como el contexto de sesión, o la diferencia entre remoto y local. Además, vimos en cierta profundidad los dos tipos de Session Bean más comunes en una aplicación EJB: Stateless y Stateful. En este artículo vamos a ver el último tipo de Session Bean (Singleton Session Bean), dos conceptos aplicables a todos los Session Bean y que son nuevos en la especificación EJB 3.1 (vista sin interface y llamadas asíncronas), y finalmente un nuevo tipo de componente: Message-Driven Bean. Comencemos.

3.1 SINGLETON SESSION BEANS: CONCEPTOS BÁSICOS
El Singleton Session Bean (no existe una traducción literal de la palabra Singleton, pero viene a expresar el concepto de instancia única; desde ahora nos referiremos a este componente como Singleton a secas) es un nuevo tipo de Session Bean introducido en la especificación EJB 3.1. Este componente expresa claramente el patrón de diseño Singleton definido por Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides en su libro Design Patterns: Elements of Reusable Object Oriented Software. Este patrón de diseño garantiza que de una clase dada solamente pueda crearse una instancia, con un punto de acceso global para acceder a dicha instancia. La naturaleza única de un componente Singleton conlleva un alto rendimiento dentro del contenedor para este tipo de Session Bean.

Es importante tener en cuenta la sutil diferencia entre un componente de tipo Singleton y cualquiera de los otros dos tipos de Session Bean (SLSB y SFSB): cuando un cliente hace una llamada a un método de un SLSB o SFSB, puesto que la instancia del Session Bean está asociada a ese cliente en concreto (durante la invocación del metodo para un SLSB, y durante toda la duración de la sesión para un SFSB), un único thread (hilo de ejecución) es capaz de acceder a dicho método, y por tanto el componente es seguro en terminos de multi-threading (ejecución de múltiples hilos). Sin embargo, cuando trabajamos con un Singleton, multiples llamadas en paralelo pueden estar produciendose en un momento dado a su única instancia, y por tanto el componente debe garantizar que un hilo de ejecución no está interfiriendo con otro hilo de ejecución, produciendo resultados incorrectos. Dicho de otra manera, un componente Singleton debe ser concurrente;

3.2 SINGLETON SESSION BEANS: CONCURRENCIA BÁSICA
Debido a la naturaleza de los Session Bean de tipo Singleton, tenemos que tener muy claros ciertos aspectos al diseñar este tipo de componente. Veamos un ejemplo de una clase donde no tenemos en cuenta la cuestión de concurrencia:



class ClaseNoConcurrente {

    private int numeroDeInvocacionesDeEstaInstancia = 0;

    

    public int metodoUno() {

        // lógica de negocio

        return numeroDeEjecuciones++;

    }

    

    public int metodoDos() {

        // lógica de negocio

        return numeroDeEjecuciones++;

    }

}

En la clase del ejemplo anterior, no se ha tenido en cuenta el aspecto de concurrencia (lo cual, dependiendo de las especificaciones del problema de negocio que queremos resolver, puede ser perfectamente legal). Una consecuencia de esto es que, cuando intervienen múltiples hilos de ejecución en paralelo, una llamada al cualquiera de los métodos metodoXxx puede devolver un resultado incorrecto. Veamos una posibilidad (entre muchas permitidas por la JVM) de la ejecución de esta clase por varios clientes:

    1. Un cliente C-1 llama a metodoUno()
    2. El cliente C-1 obtiene el valor 1 para el número de ejecuciones
    3. Un cliente C-2 llama a metodoUno()
    4. Un cliente C-3 llama a metodoDos()
    6. El cliente C-3 obtiene el valor 2 para el número de ejecuciones
    7. El cliente C-2 obtiene el valor 2 para el número de ejecuciones

¿Que ha ocurrido en el ejemplo anterior? El cliente C-2 cree que los métodos metodoXxx han sido invocados dos veces (punto 7), cuando en realidad se han invocado tres veces (puntos 1, 3, y 4). Esto es debido a que la operación numeroDeEjecuciones++ no es atómica: cuando el código Java es convertido en código de bytes (.class), dicha operación se compone de muchas otras, de manera que la JVM puede para el hilo actual en mitad del incremento y dar tiempo de ejecución a otro hilo. Incluso aunque la operación fuera atómica, la JVM podría seguir deteniendo un hilo durante la lógica de negocio (antes de realizar el incremento), dando tiempo de ejecución a otro hilo y produciendo de nuevo resultados incorrectos. Puesto que un Singleton es compartido por muchos clientes (accedido por muchos hilos de ejecución) este comportamiento no es aceptable: el Singleton debe ser concurrente.

La especificación EJB 3.1 nos permite controlar la concurrencia de un Singleton de dos maneras:

    - Concurrencia Gestionada por el Contenedor (CMC - Contained-Managed Concurrency)
    - Concurrencia Gestionada por el Bean (BMC - Bean-Managed Concurrency)

Veamos cada una de ellas con cierto detalle.

3.3 SINGLETON SESSION BEANS: CONTAINED-MANAGED CONCURRENCY
Mediante CMC, el contenedor es responsable de gestionar toda la concurrencia en el Singleton mediante metadatos, liberando así al programador de la tarea de escribir código concurrente. Por defecto, todos los componentes Singleton son gestionados por el contenedor, aunque podemos especificarlo de manera explicita mediante la anotación @ConcurrencyManagement:



import javax.ejb.ConcurrencyManagement;

import javax.ejb.ConcurrencyManagementType;

import javax.ejb.Singleton;



@Singleton

@ConcurrencyManagement(ConcurrencyManagementType.CONTAINER)

class MiSingleton { 

    // ...

}

En el ejemplo anterior hemos definido un componente Singleton mediante la anotación @Singleton, y hemos indicado al contenedor de forma explícita que gestione por nosotros la concurrencia del componente mediante CMC (aunque, repito, este comportamiento es el ofrecido por defecto para todos los Singleton). Cuando usamos CMC, todos los métodos de la clase tienen por defecto un bloqueo de tipo write (escritura). Este bloqueo es de utilidad cuando uno o varios métodos deben ser accedidos de manera secuencial (hasta que uno no termine, otro no puede comenzar) para evitar que se obtengan resultados incorrectos. Este acceso secuencial es necesario en casos como el del ejemplo de la sección 3.2, en el que varios métodos escribían sobre el valor de una variable que después era devuelta al cliente. Como se puede deducir del comportamiento del bloqueo write, este afecta a todo el objeto, y no a métodos concretos (todos los métodos write del mismo Singleton deben compartir un único bloqueo).

Por otro lado, cuando un método realiza solo operaciones de tipo read (lectura), de manera que no se altera el estado del componente, podemos indicarle al contenedor que no bloquee ninguna invocación a dicho método. De esta manera, el método pueda ser accedido por múltiples hilos de ejecución simultaneamente (puesto que no modificamos el estado del componente, el acceso en paralelo es seguro). Tenemos que indicar que un método es de tipo read mediante la anotación @Lock:



import javax.ejb.Lock;

import javax.ejb.LockType;



// ...

 

@Lock(LockType.READ)

public String metodo() {

    // ...

}

Aunque, como ya se ha dicho, el tipo de bloqueo write se aplica por defecto, podemos expresarlo de forma explícita mediante @Lock(LockType.WRITE). Otra opción que nos brinda CMC es la liberación de un bloqueo automáticamente si este no ocurre tras un tiempo preestablecido (timeout):



import java.util.concurrent.TimeUnit;

import javax.ejb.AccessTimeout;



// ...



@AccessTimeout(value=5, unit=TimeUnit.SECONDS)

public String metodo() {

    // ...

}

3.4 SINGLETON SESSION BEANS: BEAN-MANAGED CONCURRENCY
En ocasiones, la concurrencia gestionada por el contenedor no es suficiente (tal vez no nos permite definir con suficiente detalle la manera en la que necesitamos que funcione la concurrencia de nuestra aplicación, por ejemplo). Bean-Managed Concurrency (BMC - Concurrencia Gestionada por el Bean) deja en manos del programador toda la gestión de la concurrencia. Esto puede realizarse utilizando bloques synchronized, variables atómicas como java.util.concurrent.atomic.AtomicInteger, etc. Podemos indicar que la concurrencia de un componente Singleton será gestionada íntegramente por el programador mediante la anotación @ConcurrencyManagement (la cual usamos en la sección anterior para declarar explícitamente el comportamiento contrario, CMC):



import javax.ejb.ConcurrencyManagement;

import javax.ejb.ConcurrencyManagementType;

import javax.ejb.Singleton;



@Singleton

@ConcurrencyManagement(ConcurrencyManagementType.BEAN)

class OtraClaseConcurrente {

    // Gestión explícita de la concurrencia

}

La concurrencia en Java es un tema largo y complejo que no puede ser tratado en este tutorial. Un buen lugar para empezar (en inglés) es The Java Tutorials. Estoy seguro que existen otras buenas fuentes de información en español, y si estás interesado tu buscador favorito te llevará hasta ellas.

3.5 SINGLETON SESSION BEANS: EL CICLO DE VIDA
El ciclo de vida de un Singleton muy parecido al de un SLSB, pues como en este último se compone de los dos mismos estados:

- No Existe (Does not exists)
- Preparado (Method-ready)

La diferencia estriba en cuando se crea la única instancia del componente Singleton (tras el despliegue de la aplicación o tras la primera invocación al componente), y en su duración (a lo largo de toda la vida de la aplicación, esto es, hasta que la aplicación sea replegada o el servidor sea parado). Evidentemente, solo el primer comportamiento (el momento de creación) puede ser customizado, y para ello la especificación EJB nos ofrece, como siempre, metadatos. Aunque el contenedor puede decidir inicializar la única instancia de un Singleton en el momento que considere más oportuno, podemos forzar que dicho proceso ocurra durante el despliegue mediante la anotación @Startup:



import javax.ejb.Singleton;

import javax.ejb.Startup;



@Singleton

@Startup

public class MiSingleton {

    // ...

}

El código anterior fuerza al contenedor a crear la única instancia de MiSingleton en el momento del despliegue de la aplicación EJB de la que forma parte. Esto comportamiento es llamado eager initialization (inicialización temprana). Ahora supongamos que un Singleton debe ser inicializado antes que otro Singleton (tal vez este último necesite poner la aplicación en cierto estado necesario para el correcto funcionamiento del primero): podemos indicar esta dependencia en el orden de inicialización mediante la anotación @DependsOn:



@Singleton

public class MiSingletonA {

    // ...

}



@Singleton

@DependsOn("MiSingletonA")

public class MiSingletonB {

    // ...

}

En el ejemplo anterior, indicamos al contenedor que en el momento de inicializar la única instancia de MiSingletonB, MiSingletonA debe haber sido inicializado. De esta manera, el contenedor forzará la inicialización del Singleton dependiente si aún no se ha producido. Este comportamiento es totalmente ajeno al uso u omisión de @Startup: si un Singleton depende de otro, este último se creará antes que el primero.

Para terminar con el ciclo de vida de los componentes Singleton, indicar que, al igual que con los componentes SLSB y SFSB, disponemos de las anotaciones @PostConstruct y @PreDestroy para responder a los eventos de creación y destrucción (respectivamente) del componente:



@Singleton

public class MiSingletonA {

    @PostConstruct

    public void inicializar() {

        // Cualquier operación/es necesaria/s para la creación del componente,

        // como obtención de recursos

    }

    

    @PreDestroy

    public void detener() {

        // Cualquier operación/es necesaria/s antes de la destrucción del componente,

        // como liberación de recursos

    }

    

    // lógica de negocio del Singleton

}

3.6 SINGLETON SESSION BEANS: UN EJEMPLO SENCILLO
La utilidad del componente Singleton está limitada a ciertos problemas de negocio que podemos (o debemos) resolver mediante una única instancia de un objeto. Ejemplos válidos de componentes Singleton serían gestores de ventanas, sistemas de ficheros, colas de impresión, caches, etc. Para nuestro ejemplo de Singleton vamos a desarrollar un sistema de logging, el cual debe ser accedido por toda la aplicación a través de una única instancia:



package es.davidmarco.ejb.singleton;



import java.io.FileWriter;

import java.io.IOException;

import java.text.SimpleDateFormat;

import java.util.Date;

import javax.annotation.PostConstruct;

import javax.annotation.PreDestroy;

import javax.ejb.Lock;

import javax.ejb.LockType;

import javax.ejb.Singleton;



@Singleton

public class SistemaDeLog {

    private FileWriter writer;



    private enum Nivel {

        DEBUG, INFO, ERROR

    }



    @PostConstruct

    protected void inicializar() throws IOException {

        writer = new FileWriter("aplicacion.log", true);

    }

    

    @PreDestroy

    protected void detener() throws IOException {

        writer.flush();

        writer.close();

    }



    @Lock(LockType.WRITE)

    public void debug(String mensaje) {

        escribirMensajeEnArchivo(Nivel.DEBUG, mensaje);

    }



    @Lock(LockType.WRITE)

    public void info(String mensaje) {

        escribirMensajeEnArchivo(Nivel.INFO, mensaje);

    }



    @Lock(LockType.WRITE)

    public void error(String mensaje) {

        escribirMensajeEnArchivo(Nivel.ERROR, mensaje);

    }



    private void escribirMensajeEnArchivo(Nivel nivel, String mensaje) {

        String cabecera = generarCabecera(nivel);

        try {

            writer.write(cabecera + mensaje + "\n");

        } catch (IOException ioe) {

            throw new RuntimeException(ioe);

        }

    }

    

    private String generarCabecera(Nivel nivel) {

        String fechaMasHoraActual = new SimpleDateFormat("dd/MM/yyyy HH:mm:ss").format(new Date());

        StringBuilder cabecera = new StringBuilder();

        cabecera.append("[");

        cabecera.append(nivel.name());

        cabecera.append("] ");

        cabecera.append(fechaMasHoraActual);

        cabecera.append(" - ");

        

        return cabecera.toString();

    }

}

El ejemplo anterior, aunque más desarrollado que los vistos hasta ahora (es completamente funcional), sigue siendo un ejemplo de juguete; sin embargo, es bastante interesante para explicar el componente Singleton. Existen verdaderos frameworks de logging que puedes (¡y debes!) usar en tus aplicaciones.

Las primero que nos interesa del ejemplo son los métodos callback @PostConstruct y @PreDestroy. En ellos se obtiene y libera (respectivamente) un recurso dado, en nuestro caso el acceso a un fichero en disco. Esto nos muestra la utilidad del componente Singleton: únicamente una instancia debe crear, editar, y finalmente cerrar el mismo fichero en disco. Y esta única instancia es la que obtendrán todos los clientes del Singleton. Ambos métodos se han marcado con visibilidad protected para facilitar la tarea de testing (y por un motivo adicional que se explicará en la próxima sección).

Lo segundo que nos interesa del ejemplo son los tres métodos que se exponen al cliente: debug, info, y error. A traves de ellos el cliente puede realizar las operaciones de logging. Los tres han sido marcados como métodos write mediante @Lock(LockType.WRITE), y aunque este comportamiento es definido por defecto para todos los métodos de un Singleton (y por tanto la anotación es redundante), se han incluido para diferenciarlos del resto (siempre es aconsejable escribir código expresivo).

Por último, los métodos de utilidad escribirMensajeEnArchivo y generarCabecera son métodos de utilidad usados por la lógica de negocio de nuestro componente.

3.7 SESSION BEANS EN GENERAL: NO-INTERFACE VIEW
Como se indicó en la sección anterior, el ejemplo del sistema de logging es completamente funcional. Sin embargo, el componente no ha sido declarado local ni remoto (ejemplos anteriores omitían este aspecto intencionadamente para mantener el código simple). En este momento es preciso introducir el concepto de vista sin interface.

Una vista sin interface (no-interface view) es una variación del concepto de componente local, e introducida en la especificación EJB 3.1. Como su nombre indica, se trata de un componente que no está anotado con @Local ni @Remote, ni implementa ninguna interface de negocio donde se hayan aplicado cualquiera de las anotaciones anteriores. Si no implementamos ninguna interface de negocio, ¿como sabe el contenedor que métodos del componente debe exponer a sus clientes? La respuesta es sencilla: todos aquellos declarados public, incluyendo los de sus superclases y los de tipo callback (en el ejemplo de la sección anterior hemos declarado los métodos callback con un nivel de visibilidad menor a public precisamente para evitar que sean expuestos). Aunque a efectos prácticos un componente de este tipo es tratado como uno local, puedes encontrar los detalles concretos sobre la vista sin interface en la especificación EJB 3.1.

3.8 SESSION BEANS EN GENERAL: LLAMADAS ASÍNCRONAS
Otra de las novedades de la especificación EJB 3.1 es la posibilidad de llamar a los métodos de nuestros Session Bean de forma asíncrona. Hasta ahora, todas las llamadas que hemos realizado han sido sincronas, de manera que los clientes deben esperar hasta que el método invocado termine de ejecutarse para seguir ejecutando el resto de sus sentencias. Este es el comportamiento normal cuando invocamos un método en Java. Sin embargo, cuando realizamos una llamada asíncrona, el flujo de ejecución vuelve automáticamente a la aplicación que realiza la llamada, sin esperar el resultado de la llamada. Más tarde, podemos comprobar dicho resultado si existe y lo necesitamos.

Las llamadas asíncronas son de gran utilidad en situaciones en las que un método realiza una operación que necesita un tiempo considerable para completarse, y no deseamos bloquear al cliente mientras dicha operación se realiza. Veamos primero el ejemplo más sencillo posible de llamada asíncrona:



package es.davidmarco.ejb.slsb;



import javax.ejb.Asynchronous;

import javax.ejb.Stateless;



@Stateless

public class ClaseAsincrona {

    

    @Asynchronous

    public void metodoLento() {

        try {

            Thread.sleep(15000);

        } catch(InterruptedException ie) {

            throw new RuntimeException(ie);

        }

    }

}

En el ejemplo anterior, hemos declarado el método metodoLento() como un método asíncrono mediante la anotación @Asynchronous. Dicha anotación puede ser aplicada también a nivel de clase, en cuya caso todos los métodos de negocio (los declarados en una interface local, en una interface remota, o los de visibilidad public en una vista sin interface) serán considerados como asíncronos. Dentro del método hemos simulado un proceso relativamente largo deteniendo durante quince segundos el hilo de ejecución que está procesando la instancia del SLSB. Cualquier cliente que llame a este método no tendrá que esperar esos quince segundos, ya que nada más realizar la llamada le será devuelto en control de ejecución, sin esperar a que el método asíncrono termine. Este comportamiento se conoce como fire-and-forget (disparar y olvidar).

Otra posibilidad es que necesitemos el resultado de una invocación asíncrona. Supongamos que necesitamos un método que realiza un cálculo intensivo y, cuando finalmente obtiene el resultado, lo devuelve en una variable de tipo Double. La manera de declarar dicho método sería similar a esta:



import java.util.concurrent.Future;

import javax.ejb.AsyncResult;

import javax.ejb.Asynchronous;



// ...



@Asynchronous

public Future metodoLentoConResultado() {        

    try {

        Thread.sleep(15000);

            

        return new AsyncResult(Math.PI);

    } catch(InterruptedException ie) {

        throw new RuntimeException(ie);

    }

}

Como puedes ver, el método metodoLentoConResultado() devuelve un objeto de tipo Future (más concretamente de su implementación AsyncResult) parametizado a Double. Es sobre este objeto Future sobre el que el cliente deberá comprobar si el método asíncrono ha terminado su ejecución, para obtener a continuación su resultado:



import java.util.concurrent.ExecutionException;

import java.util.concurrent.Future;

import javax.naming.NamingException;



// ...



Future resultado = bean.metodoLentoConResultado();

System.out.println("Método asíncrono invocado");

System.out.println("Realizando otras tareas mientras se ejecuta el método asíncrono...");

// ...

    

while(true) {

    if(!resultado.isDone()) {

        Thread.sleep(2000);

    } else {

        System.out.println("Método asincrono devuelve el resultado " + resultado.get());

        break;

    }

}

El ejemplo anterior es parte de un cliente del SLSB asíncrono. En el, en un momento dado, se llama al método asíncrono, asignando el objeto Future devuelto por dicho método en una variable. En este momento el resultado no está listo (recuerda que tardará quince segundos en producirse), pero el control de la ejecución del cliente continua sin esperar. Más adelante el cliente comprueba si el resultado está finalmente disponible mediante el método isDone() de la clase Future. Cuando esto ocurra, podemos obtener nuestro ansiado resultado mediante el método get() (también de la clase Future), el cual devuelve un objeto del mismo tipo al que usamos para parametizar la respuesta del método asíncrono (en nuestro caso, un objeto Double). Es importante tener presente que el método get() bloquea el hilo de ejecución del cliente hasta que el resultado esté listo, de manera que podemos omitir por completo el bucle while:



Future resultado = bean.metodoLentoConResultado();

System.out.println("Método asíncrono invocado");

System.out.println("Realizando otras tareas mientras se ejecuta el método asíncrono...");

// ...

System.out.println("Método asíncrono devuelve resultado " + resultado.get());

La interface Future incluye otros métodos con los que podemos cancelar la ejecución del método asíncrono, o comprobar si dicha ejecución ha sido cancelada por el contenedor (por ejemplo en caso de excepción). Es recomendable que visites la API de Future si vas a trabajar con ella.

Antes de terminar con los métodos asíncronos, quiero hacer constar que en la implementación del contenedor EJB que estamos usando en este tutorial (JBoss 6.0.0 Final) las llamadas asíncronas aún no están completamente implementadas (el hilo de ejecución del cliente se bloquea al llamar al método asíncrono hasta que este ha terminado de ejecutarse; en otras palabras, las llamadas asíncronas se comportan como llamadas síncronas). En otros contenedores compatibles con EJB 3.1, como Glassfish v3, el comportamiento de las llamadas asíncronas si es el correcto (no lo he probado personalmente, pero así aparece indicado por usuarios de ambos servidores).

3.9 SESSION BEANS EN GENERAL: RESUMEN
Con esta sección terminamos de ver los componentes de tipo Session Bean, que son aquellos que contienen la lógica de negocio de una aplicación EJB que puede ser invocada por los clientes de dicha aplicación (ya sea en cualquiera de sus tres variaciones: Stateless, Stateful, o Singleton). Ahora es el momento de pasar a un nuevo tipo de componente con una misión totalmente diferente: Message-Driven Beans.

3.10 MESSAGE-DRIVEN BEANS: CONCEPTOS BÁSICOS
Los componentes de tipo Message-Driven Bean (MDB - Bean Dirigido por Mensajes) son componentes asíncronos de tipo listener (oyente). Un MDB no es más que un componente que espera a que se le envie un mensaje, y realiza cierta acción cuando finalmente recibe dicho mensaje (el MDB escucha por si alguien le llama, de ahí su nombre). Algunas propiedades de los componentes MDB son:

    - No mantienen estado
    - Son gestionados por el contenedor (transacciones, seguridad, concurrencia, etc)
    - Son clases puras que no implementan interfaces de negocio (puesto que son invocados por un cliente)

Los componentes MDB forman parte de un sistema de mensajería, el cual se compone de los siguientes subsistemas:

    Cliente (Productor) ---> Broker ---> Cliente (Consumidor) ---> Message-Driven Bean

En lo que refiere a este tutorial, el cliente consumidor será el propio contenedor EJB, el cual distribuirá los mensajes que consuma a los MDB correspondientes.

Los tres primeros subsistemas (clientes y broker) forman parte del servicio de mensajería, que en la especificación EJB es gestionado por defecto mediante JMS. En este momento es preciso desviarnos del camino para explicar con un mínimo de detalle que es y cómo funciona JMS.

3.11 JAVA MESSAGE SERVICE: CONCEPTOS BÁSICOS
Java Message Service (JMS - Servicio de Mensajería en Java) es una API neutral que puede ser usada para acceder a sistemas de mensajería. Todos los contenedores EJB 3.x deben proporcionar un proveedor de JMS (el cual define su propia implementación de la API), de manera que podamos trabajar con mensajes sin necesidad de añadir librerías externas. Puesto que esta API es neutral, podemos cambiar en cualquier momento el proveedor JMS por uno que se adecue más a nuestras necesidades (o incluso usar un sistema de mensajería diferente a JMS).

Una aplicación JMS se compone, generalmente, de múltiples clientes JMS y un único proveedor JMS. Un cliente JMS puede ser de dos tipos:

    - Productor: su misión es enviar mensajes
    - Consumidor: su misión es recibir mensajes

Por otro lado, la misión del proveedor JMS es dirigir y enviar los mensajes que le llegan a traves de un broker (esto es algo bastante más complejo, pero por simplicidad vamos a pensar que tenemos un subsistema llamado broker donde se almacenan los mensajes enviados hasta que son servidos a todos sus consumidores). JMS proporciona un tipo de mensajería asíncrona: los clientes JMS envían mensajes a traves del broker sin esperar una respuesta. Es responsabilidad del broker hacer llegar el mesaje a los clientes JMS que deban consumir el mensaje. De esta manera JMS proporciona un sistema de comunicación muy poco acoplado, pues el productor y el consumidor no saben el uno del otro en ningún momento.

3.12 JAVA MESSAGE SERVICE: MODELOS DE MENSAJERÍA
JMS proporciona dos modelos de mensajería, los cuales nos permiten definir el comportamiento de nuestro sistema de mensajería:

    - Publicar y Suscribir (pub/sub - Publish and Subscribe)
    - Punto a Punto (p2p - Point to Point)

En el modelo pub/sub, un cliente JMS de tipo productor publicasus mensajes en un canal virtual llamado topic (tema). A su vez, uno o varios clientes JMS de tipo consumidor se suscriben a dicho topic si desean recibir los mensajes que en él se publiquen. Si un suscriptor decide desconectarse del topic y más tarde reconectarse, recibirá todos los mensajes publicados durante su ausencia (aunque este comportamiento es configurable). Por todo esto, el modelo pub/sub es de tipo uno-a-muchos (un productor, muchos consumidores).

En el modelo p2p, un cliente JMS de tipo productor publica sus mensajes en un canal virtual llamado queue (cola). De manera similar al modelo pub/sub, pueden existir multiples consumidores conectados al queue. Sin embargo, el queue no enviará automáticamente los mensajes que le lleguen a todos los consumidores, si no que son estos últimos los que deben solicitarlos al queue. De manera adicional, solo un consumidor consumirá cada mensaje publicado: el primero en solicitarlo. Cuando esto ocurra, el mensaje se borrará del queue, y el resto de consumidores no será siquiera consciente de la anterior existencia del mensaje. Por todo esto, el modelo p2p es de tipo uno-a-uno (un productor, un consumidor).

En versiones anteriores a JMS 1.1 cada uno de estos modelos usaba su propio conjunto de interfaces y clases para para el envio y recepción de mensajes. Desde la citada versión de JMS, sin embargo, está disponible una API unificada que es válida para ambos modelos de mensajería.

Ahora es el momento de volver al camino que dejamos dos secciones atrás, y seguir con nuestros amados componentes MDB.

3.13 MESSAGE-DRIVEN BEANS: EL CICLO DE VIDA
Tal como vimos en la sección 3.10, los componentes MDB no mantienen estado entre invocaciones (son stateless, pero no confundir con los componentes SLSB). Por tanto, su ciclo de vida es similar a los SLSB, constando de dos estados:

    - No existe (Does not exists)
    - Preparado en pool (Method-ready pool)

Un MDB en el primer estado es aquel que no ha sido creada aún, y por tanto no existe en memoria. Un MDB en el segundo estado representa una instancia que ha sido instanciada e inicializada por el contenedor. Se llega a este estado cuando se inicia el servidor (que puede decidir crear cierto número de instancias del MDB para procesar mensajes), o cuando el número de instancias en el pool sea insuficiente para atender todos los mensajes que se estén recibiendo. La especificación EJB no fuerza a que exista un pool de MDB's, de manera que una implementación concreta de contenedor EJB ppdría decidir crear una instancia cada vez que se reciba un mensaje (y eliminar esta instancia al terminar de procesar el mensaje) en lugar de mantener un pool de instancias ya preparadas. Este último aspecto, sea como sea, no nos afecta como programadores (al diseñar un MDB) ni como clientes; la forma en que sea gestionada nuestra aplicación es, a priori, responsabilidad exclusiva del contenedor.

Durante la transición entre el primer estado y el segundo, el contenedor realizará tres operaciones (en este orden):

    - Instanciación del MDB
    - Inyección de cualquier recurso necesario y de dependencias
    - Ejecución de un método dentro del MDB marcado con la anotación @PostConstruct, si existe

La instanciación del MDB se lleva a cabo mediante reflexión, a traves de Class.newInstance(). Por tanto, el MDB debe tener un constructor por defecto (sin argumentos), ya sea de forma implícita o explícita.

Durante la inyección de dependencias, el contenedor inyectará automáticamente cualquier recurso necesario para el MDB en base a los metadatos que hayamos proporcionado (como una anotación @MessageDrivenContext, o una entrada en el descriptor XML de EJB). De manera adicional, cada vez que un MDB procese un nuevo mensaje, todas las dependencias se inyectarán de nuevo.

Por último, el contenedor ejecutará, si existe, un método dentro del MDB anotado con @PostConstruct (Post construcción). En este método podemos obtener recursos adicionales necesarios para el MDB (como conexiones de red, etc), recursos que permanecerán abiertos hasta la destrucción del MDB. Las reglas de declaración de los métodos callback como @PostConstruct se vieron una y otra vez en el artículo anterior.

Cuando el contenedor no necesita una instancia del MDB (ya sea porque decide reducir el número de instancias en el pool, o porque se esta produciendo un shutdown del servidor), se realiza una transición en sentido inverso: del estado preparado en pool al estado no existe. Durante esta transición se ejecutará, si existe, un método anotado con @PreDestroy (Pre destrucción), donde podemos liberar los recursos adquiridos en @PostConstruct. Es importante tener presente que dentro del método @PreDestroy todavía tenemos acceso al contexto del MDB (lo mismo es válido para todos los Session Bean).

3.14 MESSAGE-DRIVEN BEANS: DEFINICIÓN
Como ya hemos visto, los componentes de tipo MDB tienen como misión procesar mensajes enviados de forma asíncrona. Aunque todo contenedor compatible EJB 3.x debe incluir una implementación de JMS (de manera que tengamos un servicio de mensajería on the box), MDB puede trabajar con otros servicios de mensajería diferentes. En este tutorial solo se usará JMS como servicio de mensajería (afectando este hecho, por ejemplo, a la interface que debe implementar el MDB, como veremos en el próximo párrafo).

Todo MDB debe implementar la interface javax.jms.MessageListener, la cual define el método onMessage(). Es dentro de este método donde se desarrolla toda la acción cuando el MDB procesa un mensaje, como veremos en el ejemplo de la próxima sección. De manera adicional, debemos indicar al contenedor que nuestra clase es un componente MDB. Para ello, utilizamos la anotación @MessageDriven:



package es.davidmarco.ejb.mdb;



import javax.ejb.MessageDriven;

import javax.jms.Message;

import javax.jms.MessageListener;



@MessageDriven()

public class PrimerMDB implements MessageListener {

    public void onMessage(Message message) {

        // procesar el mensaje

    }

}

El ejemplo anterior aún no es funcional (producirá un error de despliegue), ya que el MDB necesita saber el tipo de canal virtual (topic/queue) al que debe conectarse, así como el nombre de dicho canal virtual. Esta información forma parte de la configuración del MDB, configuración que proporcionamos al componente a través del atributo activationConfig (configuración de activación) de la anteriormente vista anotación @MessageDriven:



@MessageDriven(activationConfig={

        @ActivationConfigProperty(propertyName="destinationType", propertyValue="javax.jms.Topic"),

        @ActivationConfigProperty(propertyName="destination", propertyValue="topic/MiTopic")})

public class PrimerMDB implements MessageListener {

    // ...

}

En el ejemplo anterior, hemos proporcionado al MDB la configuración necesaria mediante un array de anotaciones @ActivationConfigProperty. Cada una de estas anotaciones contiene dos atributos: propertyName y propertyValue, en los cuales indicamos parejas nombre-de-la-propiedad/valor-de-la-propiedad, respectivamente. Volviendo a nuestro último ejemplo, hemos configurado el MDB con las siguientes propiedades:

    - El tipo de canal virtual al que el MDB se conectará (javax.jms.Topic)
    - El nombre JNDI del canal virtual al que el MDB se conectará (topic/MiTopic).

Otra opción de configuración bastante interesante (aunque opcional) es la duración de la subscripción:



@ActivationConfigProperty(propertyName="subscriptionDurability", propertyValue="Durable")

Añadiendo la anotación anterior al array de propiedades de configuración del MDB, nuestro componente recibirá todos los mensajes que se envien a su canal virtual mientras el contenedor EJB (y por tanto el propio componente MDB) esté offline. Esta situación puede ocurrir durante un shutdown del servidor, un problema de conectividad por red, etc. En otras palabras, el mensaje estará disponible hasta que todos sus suscriptores de tipo durable lo hayan recibido y procesado. La opción contraria se aplica cambiando el valor del atributo propertyValue a NonDurable (no durable). La durabilidad de los mensajes solo afecta a los componentes MDB que trabajan con topics (modelo pub/sub), pues en un canal de tipo queue no tiene ningún sentido almacenar un mensaje para componentes MDB offline (en cuanto un MDB este online y lo consuma, el mensaje se eliminará).

Al igual que los componentes Session Bean, los componentes MDB funcionan dentro de un contexto de ejecución. Y por tanto, al igual que los componentes Session Bean, nuestros MDB pueden acceder a su contexto de ejecución si necesitan comunicarse con el contenedor:



import javax.annotation.Resource;

import javax.ejb.MessageDriven;

import javax.ejb.MessageDrivenContext;



@MessageDriven(/*...*/)

public class PrimerMDB implements MessageListener {

    @Resource 

    private MessageDrivenContext context;

    

    // ...

}

En el ejemplo anterior indicamos al contenedor que inyecte una instancia de MessageDrivenContext mediante la anotación @Resource. MessageDrivenContext extiende la interface EJBContext, sin añadir ningún método. Solamente los métodos transaccionales son útiles al MDB, como se verá cuando trabajemos con transacciones en artículos posteriores. El resto de métodos de la interface lanzará una excepción si son invocados, ya que no tiene sentido que un MDB pueda, por ejemplo, acceder al servicio de seguridad.

Por otro lado, un MDB también puede referenciar un Session Bean para realizar el procesamiento del mensaje (mediante la anotación @EJB, sección 2.5 del artículo anterior), así como enviar él mismo sus propios mensajes mediante JMS (al final de la próxima sección veremos un ejemplo de un MDB procesando mensajes, y a su vez enviando nuevos mensajes que serán procesador por otro MDB).

3.15 MESSAGE-DRIVEN BEANS: UN SENCILLO EJEMPLO
Ya hemos visto como los servicios de mensajería asíncronos desacoplan de forma completa al productor de un mensaje de su/s receptor/es: ninguno de ellos es consciente de la parte contraria. Esto debido a que, entre ellos, existe un broker donde se realiza todo el proceso de almacenaje (ya sea en canales virtuales de tipo topic o queue) y reparto de los mensajes que se reciben.

El ejemplo que vamos a ver consta de tres partes:

    - Creación de un canal virtual
    - Creación de un componente MDB para consumir mensajes
    - Creación de un cliente para enviar mensajes mediante JMS

El primer paso lógico es crear un canal virtual donde poder enviar mensajes (un topic para modelos pub/sub o un queue para modelos p2p). En JBoss 6.0.0 Final (el servidor de aplicaciones que instalamos en el anexo que acompaña este tutorial), el proveedor JMS incorporado es HornetQ 2.1.2 Final. Para declarar un canal virtual de tipo topic, edita el archivo llamado hornetq-jms.xml del directorio server/default/deploy/hornetq/ de tu instalación de JBoss y añade lo siguiente (default es la configuración por defecto al crear el servidor en Eclipse; si seleccionaste otra configuración, modifica la ruta anterior a la que corresponda):



<configuration xmlns="urn:hornetq"

            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

            xsi:schemaLocation="urn:hornetq /schema/hornetq-jms.xsd">

            

    <!-- ... -->

   

   <topic name="PrimerTopic">

        <entry name="/topic/PrimerTopic" />

    </topic>



</configuration>

En el archivo XML anterior hemos definido un canal virtual de tipo topic (mediante el elemento <topic>) con nombre PrimerTopic, y lo hemos asociado a la dirección JNDI /topic/PrimerTopic (es necesario reiniciar JBoss si se encuentra levantado). La forma de configurar un canal virtual puede ser diferente entre distintos contenedores (incluso entre distintas implementaciones de un mismo contenedor), por lo que si estás usando un servidor de aplicaciones diferente a JBoss 6.0.0 Final o un proveedor JMS diferente a HornetQ 2.1.2 Final, quizá necesites revisar la documentación correspondiente para declarar el canal virtual.

Aunque este ejemplo se basará en un canal virtual de tipo topic, puedes declarar un queue (para montar un modelo de mensajería p2p) de la siguiente manera:



<configuration xmlns="urn:hornetq"

            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

            xsi:schemaLocation="urn:hornetq /schema/hornetq-jms.xsd">

            

    <!-- ... -->

   

   <queue name="PrimerQueue">

        <entry name="/queue/PrimerQueue" />

    </queue>



</configuration>

El siguiente paso lógico sería escribir un componente MDB que procese los mensajes del topic. Para ello, necesitamos crear un proyecto EJB en Eclipse y declarar una clase como la siguiente:



package es.davidmarco.ejb.mdb;



import javax.ejb.ActivationConfigProperty;

import javax.ejb.MessageDriven;

import javax.jms.JMSException;

import javax.jms.Message;

import javax.jms.MessageListener;

import javax.jms.TextMessage;



@MessageDriven(activationConfig={

        @ActivationConfigProperty(propertyName="destinationType", propertyValue="javax.jms.Topic"),

        @ActivationConfigProperty(propertyName="destination", propertyValue="topic/PrimerTopic")})

public class PrimerMDB implements MessageListener {

    

    @Override

    public void onMessage(Message message) {

        if(message instanceof TextMessage) {

            try {

                String contenidoDelMensaje = ((TextMessage)message).getText();

                System.out.println("PrimerMDB ha procesado el mensaje: " + contenidoDelMensaje);

            } catch (JMSException jmse) {

                throw new RuntimeException("Error al procesar un mensaje");

            }            

        }

    }

}

En el ejemplo anterior declaramos un componente MDB (con la anotación @MessageDriven), lo configuramos para actuar como consumidor de los mensajes del topic registrado con dirección JNDI topic/PrimerTopic (con las anotaciones @ActivationConfigProperty), y finalmente añadimos dentro del método onMessage() la lógica que procesará los mensajes. Recuerda que este método es el único declarado en la interface MessageListener, la cual deben implementar todos los MDB basados en JMS.

Es interesante explicar con un mínimo detalle las operaciones que se realizan dentro de nuestro método onMessage. Este método requiere un parámetro de tipo javax.jms.Message, que es una interface base de la cual extienden otras interfaces más específicas. Una de esas subinterfaces es TextMessage, la cual provee de métodos para trabajar con mensajes cuyo contenido es texto. Por tanto, este MDB está diseñado para recibir mensajes desde el topic asociado, y procesarlos si son de tipo TextMessage (en caso afirmativo, se imprime en el log del servidor el contenido del mensaje). Si durante dicho procesamiento se produce un error, el MDB lanzará una excepción. Lo ideal es que el topic asociado solo reciba este tipo de mensajes, y que mensajes con otro tipo de contenido sean almacenados en otros canales virtuales (de esta manera no se crearán instancias que finalmente no procesarán el mensaje).

Tras desplegar el proyecto EJB con nuestro primer componente MDB, el último paso lógico sería crear un cliente JMS que produjera mensajes y los enviara al topic. Este cliente podría ser, por ejemplo, un proyecto Java normal y corriente. Puesto que necesitamos las librerias de JMS (las cuales son parte de EJB 3.x), debemos incluirlas al crear nuestro proyecto. La forma más sencilla sería pulsando Next en la pantalla de creación del proyecto Java en Eclipse, seleccionando la pestaña Libraries y añadiendo las librerias del servidor JBoss:

Add Library > Server Runtime > Botón Next > JBoss 6.0 Runtime > Botón Finish > Botón Finish

Ahora ya estamos listos para escribir el cliente productor JMS:



package es.davidmarco.ejb.cliente;



import java.util.Properties;

import javax.jms.Connection;

import javax.jms.ConnectionFactory;

import javax.jms.JMSException;

import javax.jms.MessageProducer;

import javax.jms.Session;

import javax.jms.TextMessage;

import javax.jms.Topic;

import javax.naming.Context;

import javax.naming.InitialContext;

import javax.naming.NamingException;



public class ClienteJMS {

    public static void main(String[] args) throws NamingException, JMSException {

        Properties propiedades = new Properties();

        propiedades.put("java.naming.factory.initial", "org.jnp.interfaces.NamingContextFactory");

        propiedades.put("java.naming.factory.url.pkgs", "org.jboss.naming:org.jnp.interfaces");

        propiedades.put("java.naming.provider.url", "jnp://localhost:1099");     

        

        Context contexto = new InitialContext(propiedades);

        ConnectionFactory factoria = (ConnectionFactory)contexto.lookup("ConnectionFactory");

        

        Topic topic = (Topic)contexto.lookup("topic/PrimerTopic");

        Connection conexion = factoria.createConnection();

        Session sesion = conexion.createSession(false, Session.AUTO_ACKNOWLEDGE);

        MessageProducer productor = sesion.createProducer(topic);

        conexion.start();

        

        TextMessage mensajeDeTexto = sesion.createTextMessage("Mensaje enviado desde Java");

        productor.send(mensajeDeTexto);

        

        conexion.close();

    }

}

En nuestro cliente JMS externo al contenedor lo primero que hacemos es crear un objeto de propiedades con los valores necesarios para conectar con el contenedor EJB (como hicimos en el cliente del primer artículo). A continuación creamos un contexto de ejecución desde el que poder acceder al contenedor, y mediante JNDI obtenemos un objeto factoría ConnectionFactory, a través del cual podremos realizar conexiones para el envío de mensajes.

Ahora viene la parte interesante: creamos un objeto Topic que está asociado al canal virtual que hemos declarado en el primer paso lógico de esta sección (mediante su dirección JNDI), creamos una conexión con el broker mediante el objeto factoría, iniciamos una nueva sesión dentro de la conexión recién creada, creamos un objeto MessageProducer asociado al objeto Topic, iniciamos la conexión para poder enviar un mensaje, creamos un mensaje de tipo texto, lo enviamos, y finalmente cerramos la conexión.

Al ejecutar el cliente, el mensaje se enviará al topic, y puesto que existen clientes consumidores asociados a ese topic, el contenedor EJB consumirá el mensaje, extraerá del pool MDB una instancia del componente MDB (o creará la instancia en el aire; a nosotros nos es indiferente), y le pasará el mensaje al método onMessage() de dicha instancia para que procese el mensaje. Si, tras ejecutar el cliente JMS, miras la pestaña Console de Eclipse, verás el mensaje imprimido en el log de JBoss (tal como se definió al escribir el método onMessage).

¿Recuerdas el sencillo esquema de la sección 3.10?:

    Cliente (Productor) ---> Broker ---> Cliente (Consumidor) ---> Message-Driven Bean

    - El cliente Java es el cliente productor
    - JMS (más concretamente su implementación HornetQ) es el broker
    - El contenedor EJB es el cliente consumidor
    - Una instancia MDB es quien procesa el mensaje

Lo interesante de un servicio de mensajería es que el cliente productor no sabe quien consumirá su mensaje, ni como lo hará. Podría ser un MDB, o podría ser otro componente en nada relacionado con la especificación EJB (tal vez ejecutándose en una máquina remota con un sistema operativo distinto).

Por último, veamos como hacer que un MDB sea también productor:



package es.davidmarco.ejb.mdb;



import javax.annotation.Resource;

import javax.ejb.ActivationConfigProperty;

import javax.ejb.MessageDriven;

import javax.ejb.MessageDrivenContext;

import javax.jms.Connection;

import javax.jms.ConnectionFactory;

import javax.jms.JMSException;

import javax.jms.Message;

import javax.jms.MessageListener;

import javax.jms.MessageProducer;

import javax.jms.Session;

import javax.jms.TextMessage;

import javax.jms.Topic;



@MessageDriven(activationConfig={

        @ActivationConfigProperty(propertyName="destinationType", propertyValue="javax.jms.Topic"),

        @ActivationConfigProperty(propertyName="destination", propertyValue="topic/PrimerTopic")})

public class PrimerMDB implements MessageListener {

    

    @Resource

    private MessageDrivenContext contexto;

    

    @Override

    public void onMessage(Message message) {

        if(message instanceof TextMessage) {

            try {

                String contenidoDelMensaje = ((TextMessage)message).getText();

                System.out.println("PrimerMDB ha procesado el mensaje: " + contenidoDelMensaje);

                

                enviarMensaje("Mensaje enviado desde MDB");

            } catch (JMSException jmse) {

                throw new RuntimeException("Error al procesar un mensaje");

            }            

        }

    }

    

    private void enviarMensaje(String mensaje) throws JMSException {    

        contexto.lookup("ConnectionFactory");

        ConnectionFactory factoria = (ConnectionFactory)contexto.lookup("ConnectionFactory");

        Topic topic = (Topic)contexto.lookup("topic/SegundoTopic");

        Connection conexion = factoria.createConnection();

        Session sesion = conexion.createSession(false, Session.AUTO_ACKNOWLEDGE);

        MessageProducer productor = sesion.createProducer(topic);

        conexion.start();

        

        TextMessage mensajeDeTexto = sesion.createTextMessage(mensaje);

        productor.send(mensajeDeTexto);

        

        conexion.close();

    }

}

En el ejemplo anterior, dentro del método onMessage() se llama a un método de utilidad que envia un nuevo mensaje a un segundo topic (que debemos haber declarado con anterioridad, por supuesto). La única diferencia entre el código del método de utilidad y el método main() del cliente Java es que, puesto que el primero se está ejecutando dentro del contenedor EJB, podemos obtener el contexto de ejecución mediante inyección de dependencia, evitando así la necesidad de crear el objeto de propiedades y conectar por red al contenedor (lo cual sería bastante absurdo).

Ahora podemos declarar un segundo MDB que procese los mensajes del segundo topic:



package es.davidmarco.ejb.mdb;



import javax.ejb.ActivationConfigProperty;

import javax.ejb.MessageDriven;

import javax.jms.JMSException;

import javax.jms.Message;

import javax.jms.MessageListener;

import javax.jms.TextMessage;



@MessageDriven(activationConfig={

        @ActivationConfigProperty(propertyName="destinationType", propertyValue="javax.jms.Topic"),

        @ActivationConfigProperty(propertyName="destination", propertyValue="topic/SegundoTopic")})

public class SegundoMDB implements MessageListener {

    

    @Override

    public void onMessage(Message message) {

        if(message instanceof TextMessage) {

            try {

                String contenidoDelMensaje = ((TextMessage)message).getText();

                System.out.println("SegundoMDB ha procesado el mensaje: " + contenidoDelMensaje);

            } catch (JMSException jmse) {

                throw new RuntimeException("Error al procesar un mensaje");

            }            

        }

    }

}

Cuando PrimerMDB reciba un mensaje, la consola de JBoss (pestaña Console de Eclipse) mostrará como ambos MDB han procesado los mensajes de sus topics correspondientes:

    19:00:47,453 INFO [STDOUT] PrimerMDB ha procesado el mensaje: Mensaje enviado desde Java
    19:00:47,475 INFO [STDOUT] SegundoMDB ha procesado el mensaje: Mensaje enviado desde MDB


3.16 RESUMEN
En este tercer artículo del tutorial de EJB hemos terminado de ver los componentes de lado del servidor, además de algunas características interesantes que son nuevas en la especificación EJB 3.1: llamadas asíncronas y vista sin interface (ambas son aplicables a componentes Session Bean, pero no a Message-Driven Beans). En el próximo artículo veremos como integrar persistencia mediante Java Persistence API (JPA - API de persistencia en Java) con una aplicación EJB 3.1, en gran medida mediante ejemplos prácticos. En ningún caso se explicará a fondo JPA (ni que es, ni como funciona), así que si no conoces este framework te aconsejo que visites el tutorial de cuatro artículos sobre JPA que se encuentra publicado en esta misma web.

Revisión del tutorial de introducción a JPA

programacion@davidmarco.es (David Marco) — Fri, 01 Apr 2011 20:32:48 +0200

Hace ya algún tiempo que publiqué en el blog el tutorial de JPA (14 meses para ser más exactos), y por ser aquellos los primeros artículos técnicos que escribí y publiqué, llevaban consigo la impronta del escritor novato. Hoy, después de haber escrito algunos artículos más, mi estilo es en cierto modo diferente, para mi gusto un poquito mejor, y tal vez ahora me veo capaz de expresar los mismos conceptos de forma más simple y comprensible, lo que yo llamo más fácil de leer.

El proposito de todo este rollo (que no creo que os importe demasiado) es que, aprovechando que el tutorial de EJB 3.1 se encuentra en plena efervescencia, y sobre todo que el último de sus artículos publicado hasta ahora termina haciendo un guiño (por no decir un grito) al tutorial de JPA, he revisado, reescrito, y corregido este último, acciones que, una vez concluidas, he comprobado que eran realmente necesarias. Como siempre espero que disfrutéis del material revisado, tanto aquellos que ya lo hicieron en su momento, como los que lo tengan ante si por primera vez.

Introducción a EJB 3.1 (IV)

programacion@davidmarco.es (David Marco) — Thu, 07 Apr 2011 17:48:14 +0200

En los artículos anteriores del tutorial de introducción a EJB 3.1, hemos visto como declarar y trabajar con componentes de lado del servidor (Session Beans y Message-Driven Beans). El último componente que nos queda por ver es Entity Beans (EB - Beans de Entidad; a partir de ahora nos referiremos a ellos como entidades).

4.1 ENTIDADES: CONCEPTOS BÁSICOS
Las entidades, a diferencia del resto de componentes EJB, son objetos Java reales que son manejados entre componentes (o entre un cliente y un componente) en su forma original, nunca a través de proxys/vistas. Podemos crearlos con sentencias new, pasarlos como parámetros a un Session Bean, etc. Pero el verdadero valor de las entidades reside en que su estado puede ser almacenado en una base de datos, y más tarde recuperado en un nuevo objeto del tipo correspondiente. De manera adicional, los cambios que realicemos en el estado de una entidad serán sincronizados con la información que tenemos almacenada en la base de datos.

Aunque las entidades se consideran componentes EJB, hasta la version JavaEE 1.4 pertenecían a una especificación independiente llamada Java Persistence API (JPA - API de Persistencia en Java). Fue a partir de la versión 5 de JavaEE que la especificación EJB absorvió a la especificación JPA. Sin embargo, podemos trabajar con entidades en una aplicación no-EJB, aunque, tras bambalinas, se seguirán ejecutando dentro de un contenedor EJB. Desde ahora usaremos el término aplicación JPA para referirnos a aplicaciones que realizan persistencia, y el término aplicación EJB cuando exista integración de ambas tecnologías.

En este artículo no vamos a tratar en profundidad la especificación JPA (ni la declaración ni el uso de entidades), si no como integrarla con una aplicación EJB 3.1. Si no conoces JPA, es prácticamente obligatorio que visites el tutorial de JPA publicado en este mismo blog, de manera que puedas comprender todo el material que sigue a continuación.

4.2 ENTIDADES: EL CICLO DE VIDA
Como ya se ha mencionado, las entidades no son objetos del lado del servidor. Sin embargo, cuando son usadas dentro del contexto de un contenedor EJB, se convierten en objetos gestionados (gracias al servicio de persistencia, el cual es controlado mediante la interface EntityManager). Esto nos lleva a los dos únicos estados de una entidad cuando se encuentra en el contexto de un contenedor EJB:

- Gestionada (Attached)
- No gestionada (Detached)

En el primer estado, la entidad se encuentra gestionada por el servicio de persistencia: cualquier cambio que realicemos en su estado se verá reflejado en la base de datos subyacente. En el segundo estado, la entidad es un objeto Java regular, y cualquier cambio que realicemos en su estado no será sincronizado con la base de datos subyacente. En este último estado, la entidad puede ser, por ejemplo, enviada a traves de una red (mediante serialización).

4.3 ENTIDADES: UNIDAD DE PERSISTENCIA
Una unidad de persistencia (persistence unit) representa un conjunto de entidades que pueden ser mapeadas a una base de datos, así como la información necesaria para que la aplicación JPA pueda acceder a dicha base de datos. Se define mediante un archivo llamado persistence.xml, el cual debe acompañar a la aplicación donde se realizan las tareas de persistencia (recuerda que puede ser una aplicación EJB o una aplicación Java normal):



<?xml version="1.0" encoding="UTF-8"?>

<persistence xmlns="http://java.sun.com/xml/ns/persistence"

             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

             xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd"

             version="2.0">

    <persistence-unit name="introduccionEJB">

    

        <!-- configuración de acceso a la base de datos -->

        <!-- lista de entidades que pueden ser mapeadas -->



    </persistence-unit>

</persistence>

Podemos definir más de una unidad de persistencia por aplicación, declarando cada una de ellas mediante el elemento XML <persistence-unit>. Cada unidad de persistencia debe seguir estas dos reglas:

    - Debe proporcionar un nombre (identidad) a través del cual pueda ser llamado
    - Debe conectar a una sola fuente de datos (data source)

Dependiendo del tipo de paquete que estemos construyendo (EAR, JAR, etc), el archivo persistence.xml deberá encontrarse en una localización u otra. En la sección 4.6 veremos un ejemplo completo de este archivo, así como la información necesaria para su correcto despliegue dentro de una aplicación EJB.

4.4 ENTIDADES: CONTEXTO DE PERSISTENCIA
Otro concepto que tenemos que tener claro es el de contexto de persistencia. Un contexto de persistencia representa un conjunto de instancias de entidades que se encuentran gestionadas en un momento dado. Existen dos tipos de contextos de persistencia:

    - Limitados a una transacción (Transaction-scoped)
    - Extendidos (Extended)

Cuando trabajamos dentro de un contexto de persistencia limitado a una transancción, todas las entidades gestionadas pasarán a estar no gestionadas cuando dicha transacción finalice. Dicho con otras palabras, los cambios realizados tras finalizar la transacción no serán sincronizados con la base de datos.

Cuando trabajamos dentro de un contexto de persistencia extendido, las cosas funcionan de manera diferente: el contexto de persistencia sobrevivirá a la transacción donde se ejecuta, de manera que los cambios que realicemos en el estado de las entidades gestionadas por el contexto de persistencia se sincronizarán con la base de datos en el momento en que entremos en una nueva transacción. Este comportamiento es útil cuando trabajamos con SFSB, pues permite mantener un estado conversacional y mantener nuestras entidades sincronizadas.

4.5 ENTIDADES: ENTITY MANAGER
Mediante la interface EntityManager (Gestor de entidades) tenemos acceso al servicio de persistencia de nuestro contenedor. Podemos obtener una instancia de EntityManager en nuestros componentes EJB mediante inyección de dependencias:



import javax.ejb.Stateless;

import javax.persistence.EntityManager;

import javax.persistence.PersistenceContext;



@Stateless

public class MiSlsb {



    @PersistenceContext(unitName="introduccionEJB")

    private EntityManager em;

    

    // operaciones del SLSB

}

El ejemplo anterior inyecta una instancia de EntityManager en el SLSB mediante la anotación @PersistenceContext. A esta anotación hay que proporcionarle como atributo el nombre de la unidad de persistencia que EntityManager usará para realizar la persistencia (y que hemos definido en el archivo persistence.xml). Con los metadatos proporcionados obtendremos por defecto un contexto de persistencia limitado a una transacción (ver sección anterior); si deseamos obtener un contexto de persistencia extendido (solo válido en SFSB por su naturaleza conversacional), debemos añadir el atributo type con el valor correspondiente para este comportamiento:



import javax.persistence.PersistenceContextType;



// ...



@PersistenceContext(unitName="introduccionEJB", type=PersistenceContextType.EXTENDED)

private EntityManager em;

En lo que se refiere a este tutorial, la integración de EJB con JPA termina aquí. Por tanto, podemos pasar a ver un ejemplo donde conectaremos todas las piezas para realizar persistencia mediante EJB 3.1.

4.6 ENTIDADES: UN SENCILLO EJEMPLO
Veamos un sencillo ejemplo de un componente EJB realizando persistencia sobre una base de datos. Al igual que algunos ejemplos anteriores, este consta de varias partes:

    - Una fuente de datos (data source) donde realizar la persistencia
    - Una aplicación EJB donde se realiza las acciones de persistencia
    - Un cliente EJB desde el que intercambiar entidades con la aplicación EJB

Nuestro primer paso va a ser definir una fuente de datos que conectará nuestro contenedor EJB con nuestra base de datos. Siguiendo el entorno de desarrollo configurado en el anexo que acompaña este tutorial, escribimos un archivo llamado derby-ds.xml y lo guardamos en el directorio server\default\deploy de nuestra instalación de JBoss:



<?xml version="1.0" encoding="UTF-8"?>

<datasources>

   <local-tx-datasource>

      <jndi-name>DerbyDS</jndi-name>

      <connection-url>jdbc:derby://localhost:1527/introduccionEJB;create=true</connection-url>

      <driver-class>org.apache.derby.jdbc.ClientDataSource40</driver-class>

      <user-name></user-name>

      <password></password>

   </local-tx-datasource>

</datasources>

En el archivo XML anterior definimos una fuente de datos (data source) limitado a transacciones locales, esto es, dentro del propio contenedor (existe otro ambito de ejecución de una transacción llamado extendido, capaz de realizar su trabajo a través de múltiples contenedores). A esta fuente de datos le hemos dado un nombre JNDI desde la que poder invocarla, así como los parámetros de conexión con nuestra base de datos subyacente (url, usuario, y password). Si JBoss 6.0.0 Final está arrancado, nada más guardar el archivo anterior la fuente de datos será activada y se producirá la conexión con Derby, así que deberás tener la base de datos iniciada o se producirá un error; nosotros vamos a considerar que en este preciso momento tanto JBoss como Derby están parados.

El siguiente paso es crear un proyecto EJB 3.1 en Eclipse, y continuación levantar la base de datos Derby desde el propio IDE. Para ello, haz click con el botón derecho sobre el nombre del proyecto EJB en la pestaña Proyect Explorer y selecciona:

    Apache Derby > Add Apache Derby nature

La operación anterior añade a nuestro proyecto las librerias del servidor embebido Derby, de manera que podamos conectar con él. A continuación levantamos la base de datos haciendo click con el botón derecho sobre el nombre del proyecto EJB en la pestaña Proyect Explorer y seleccionando:

    Apache Derby > Start Derby Network Server

Nos aparecerá una ventana donde se nos informa que la base de datos está siendo levantada, haz click en el botón OK para finalizar este proceso. En un entorno en producción, todas estas operaciones serían innecesarias, pues teóricamente tendríamos una base de datos externa funcionando de manera continua.

Ahora vamos a crear un componente SLSB remoto, de manera que podamos llamarlo desde un cliente Java normal. Como recordarás, un componente remoto requiere de manera obligatoria implementar una interface:



package es.davidmarco.ejb.slsb;



import es.davidmarco.ejb.entidad.Cuenta;



public interface OperacionesConCuentas {

    public void crearCuenta(Cuenta cuenta);    

    public Cuenta obtenerCuenta(Long id);

    public void borrarCuenta(Cuenta cuenta);

}

Ahora ya podemos implementar el componente remoto:



package es.davidmarco.ejb.slsb;



import javax.ejb.Remote;

import javax.ejb.Stateless;

import javax.persistence.EntityManager;

import javax.persistence.PersistenceContext;

import es.davidmarco.ejb.entidad.Cuenta;



@Remote

@Stateless

public class OperacionesConCuentasRemote implements OperacionesConCuentas {



    @PersistenceContext(unitName="introduccionEJB")

    private EntityManager em;

    

    @Override

    public void crearCuenta(Cuenta nuevaCuenta) {

        em.persist(nuevaCuenta);

    }



    @Override

    public Cuenta obtenerCuenta(Long id) {

        return em.find(Cuenta.class, id);

    }



    @Override

    public void borrarCuenta(Cuenta cuenta) {

        em.remove(cuenta);        

    }

}

El componente anterior es extremadamente sencillo: en él se inyecta una instancia de EntityManager, la cual es usada en los métodos del Session Bean para realizar las tareas de persistencia. Estos métodos usan como parámetros o tipos de retorno instancias de la clase Cuenta (la cual define cuentas bancarias) y que será nuestra entidad:



package es.davidmarco.ejb.entidad;



import java.io.Serializable;



import javax.persistence.Entity;

import javax.persistence.GeneratedValue;

import javax.persistence.Id;



@Entity

public class Cuenta implements Serializable {

    private static final long serialVersionUID = 1L;

    

    @Id

    @GeneratedValue

    private Long id;

    private String numeroDeCuenta;

    private String nombreDelTitular;

    private Double saldo;







    public Long getId() {

        return id;

    }



    public void setId(Long id) {

        this.id = id;

    }



    public String getNumeroDeCuenta() {

        return numeroDeCuenta;

    }



    public void setNumeroDeCuenta(String numeroDeCuenta) {

        this.numeroDeCuenta = numeroDeCuenta;

    }



    public String getNombreDelTitular() {

        return nombreDelTitular;

    }



    public void setNombreDelTitular(String nombreDelTitular) {

        this.nombreDelTitular = nombreDelTitular;

    }



    public Double getSaldo() {

        return saldo;

    }



    public void setSaldo(Double saldo) {

        this.saldo = saldo;

    }



    public void aumentarSaldo(Double cantidad) {

        saldo += cantidad;

    }



    public void reducirSaldo(Double cantidad) {

        saldo -= cantidad;

    }

}

Algunos detalles de la entidad definida en el ejemplo anterior merecen una pequeña explicación: para empezar, nuestra entidad implementa la interface Serializable, necesaría cuando nuestra entidad va a viajar a través de una red (en nuestro caso entre el cliente Java y el contenedor EJB). Dentro de la entidad definimos 4 propiedades: una para la identidad de la entidad, y tres para representar su estado (numeroDeCuenta, nombreDelTitular, y saldo), más sus correspondientes métodos getter/setter. De manera adicional, hemos añadido algunas operaciones de lógica de negocio (aumentarSaldo() y reducirSaldo) dentro de la entidad; es una buena práctica que las operaciones relacionadas con cuentas estén dentro de la clase que representa dichas cuentas.

Ahora que tenemos un componente EJB y una entidad, vamos a crear la unidad de persistencía asociada a la fuente de datos y nuestra entidad. Crea un archivo llamado persistence.xml en el directorio META-INF del proyecto EJB:



<?xml version="1.0" encoding="UTF-8"?>

<persistence xmlns="http://java.sun.com/xml/ns/persistence"

             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

             xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd"

             version="2.0">

    <persistence-unit name="introduccionEJB" transaction-type="JTA">

        <provider>org.hibernate.ejb.HibernatePersistence</provider>        

        <jta-data-source>java:/DerbyDS</jta-data-source>

        <class>es.davidmarco.ejb.entidad.Cuenta</class>

        

        <properties>

            <property name="hibernate.dialect"  value="org.hibernate.dialect.DerbyDialect" />

            <property name="hibernate.hbm2ddl.auto" value="update"/>

        </properties>

    </persistence-unit>

</persistence>

En el archivo XML anterior hemos declarado una unidad de persistencia con nombre introduccionEJB (que fue el que usamos como parámetro de la anotación @PersistenceContext en el componente SLSB que definimos previamente), así como transacciones de tipo JTA (gestionadas por el contenedor; los tipos de transacción se explicaron en las secciones 3.2 y 3.3 del tercer artículo del tutorial de JPA).

Ya dentro de la declaración de la unidad de persistencia, hemos declarado el proveedor de persistencia que usaremos (HibernatePersistence), la dirección JNDI de la fuente de datos que declaramos en el archivo derby-ds.xml, y las entidades que gestionaremos en esta unidad de persistencia (en nuestro caso solamente Cuenta). Por último, hemos configurado algunos detalles relativos a la fuente de datos dentro del elemento <properties>: el dialecto que usará el contenedor para construir sentencias SQL adecuadas a nuestra base de datos, y la creación automática de los esquemas necesarios en base a los metadatos de nuestras entidades (de esta manera nos evitamos crear manualmente tanto las tablas como sus columnas, incluyendo la definición del tipo de dato de cada columna, restricciones de cada columna, etc). Ahora ya podemos desplegar la aplicación EJB en el contenedor.

El último paso necesario para probar nuestro ejemplo es crear un cliente Java que pasará una instancia ya inicializada de la entidad Cliente al componente EJB. Para ello, y para mantener las cosas sencillas, creamos un proyecto Java en Eclipse y le añadimos las librerias del proyecto EJB haciendo click con el botón derecho del ratón en el nombre del proyecto Java y seleccionando:

Build Path > Configure Build Path

En la ventana que nos aparece, vamos a la pestaña Proyects, hacemos click en el botón Add, seleccionamos el proyecto EJB donde esta nuestro componente SLSB y nuestra entidad, hacemos click en el botón OK, y de nuevo hacemos click en el botón OK. Ahora ya podemos escribir el cliente:



package es.davidmarco.ejb.cliente;



import java.util.Properties;

import javax.naming.Context;

import javax.naming.InitialContext;

import javax.naming.NamingException;

import es.davidmarco.ejb.entidad.Cuenta;

import es.davidmarco.ejb.slsb.OperacionesConCuentas;



public class Cliente {

    private static final String JNDI_BEAN = "OperacionesConCuentasRemote/remote";



    public static void main(String[] args) throws NamingException {

        Properties properties = new Properties();

        properties.put("java.naming.factory.initial", "org.jnp.interfaces.NamingContextFactory");

        properties.put("java.naming.factory.url.pkgs", "org.jboss.naming:org.jnp.interfaces");

        properties.put("java.naming.provider.url", "jnp://localhost:1099");

        Context context = new InitialContext(properties);

        

        Cuenta cuenta = new Cuenta();        

        cuenta.setNumeroDeCuenta("0000-0001");

        cuenta.setNombreDelTitular("Nuevo cliente");

        cuenta.setSaldo(2500D); */

        

        OperacionesConCuentas occ = (OperacionesConCuentas)context.lookup(JNDI_BEAN);

        occ.crearCuenta(cuenta);

    }

}

En el ejemplo anterior, creamos e inicializamos una cuenta, obtenemos un proxy/vista al componente EJB, e invocamos su método crearCuenta() pasándole como parámetro la cuenta. Esta entidad será serializada, viajará a traves de la red hasta el contenedor, será deserializada, y dentro del componente EJB será persistida en la base de datos. Podemos comprobarlo ejecutando una sentencia SQL contra la base de datos: para ello, haz click con el botón derecho sobre el nombre del proyecto EJB en la pestaña Proyect Explorer y selecciona:

    Apache Derby > ij (Interactive SQL)

La consola de ij se abrirá en la pestaña Console de Eclipse, y desde el prompt de ij nos conectamos a la base de datos mediante el comando:

    connect 'jdbc:derby://localhost:1527/introduccionEJB;'

Cuando la conexión se realice, volveremos a ver el prompt de ij. Ahora ya podemos realizar la consulta SQL mediante el comando:

    select * from cuenta;

La consola de ij nos mostrará un registro en la tabla Cuenta:

    1    |Nuevo cliente    |0000-0001    |2500.0

Esto demuestra que nuestra entidad (un POJO Java) ha sido almacenado en una base de datos relacional (tablas y columnas) de manera transparente para nosotros. Misión cumplida. Si deseáramos realizar el proceso inverso (obtener un objeto Java desde la información almacenada en la base de datos):



// ...



public class Cliente {

    private static final String JNDI_BEAN = "OperacionesConCuentasRemote/remote";



    public static void main(String[] args) throws NamingException {

        Properties properties = new Properties();

        properties.put("java.naming.factory.initial", "org.jnp.interfaces.NamingContextFactory");

        properties.put("java.naming.factory.url.pkgs", "org.jboss.naming:org.jnp.interfaces");

        properties.put("java.naming.provider.url", "jnp://localhost:1099");

        Context context = new InitialContext(properties);

        

        // Cuenta cuenta = new Cuenta();        

        // cuenta.setNumeroDeCuenta("0000-0001");

        // cuenta.setNombreDelTitular("Nuevo cliente");

        // cuenta.setSaldo(2500D); */

        

        OperacionesConCuentas occ = (OperacionesConCuentas)context.lookup(JNDI_BEAN);

        // occ.crearCuenta(cuenta);

        Cuenta cuenta = occ.obtenerCuenta(1L);

        System.out.println("Titular de la cuenta " 

                + cuenta.getNumeroDeCuenta() 

                + " con saldo " 

                + cuenta.getSaldo() 

                + ": " 

                + cuenta.getNombreDelTitular());

    }

}

En el ejemplo anterior, hemos comentado las lineas que crean y persisten un cliente (de otra manera se insertará un nuevo registro con los misma información en la base de datos pero con ID con valor 2), y en su lugar hemos llamado al método obtenerCuenta() del SLSB, para así obtener una cuenta desde la base de datos en base a su ID. Si una cuenta con ese ID no existe, obtendremos como respuesta un valor null. Te invito a que, a modo de práctica, elimines de la base de datos la cuenta que hemos creado llamando al método borrarCuenta() del SLSB; para verificarlo, una vez hayas ejecutado esta operación vuelve a realizar la consulta SQL contra la base de datos a través de la consola de ij:

select * from cuenta;

Si has realizado correctamente el ejercicio, la tabla Cuenta no deberá mostrar ninguna entidad (salvo que hayas insertado entidades adicionales).

4.7 RESUMEN
Como hemos visto en este artículo, podemos realizar persistencia de manera extremadamente sencilla en nuestras aplicaciones EJB. Las entidades son simples POJO's, la configuración con la base de datos se configura mediante archivos XML, y en nuestros componentes EJB solo tenemos que inyectar una unidad de persistencia y ejecutar sus métodos.

En este punto ya hemos visto todos los componentes EJB (Session Beans, Message-Driven Beans, y Entities). Los dos próximos artículos estarán dedicados a los diversos servicios que ofrece el contenedor, servicios que nuestros componentes pueden usar para realizar taréas más complejas (y que son necesarias en aplicaciones reales).

Cliente EJB para Glassfish v3

programacion@davidmarco.es (David Marco) — Wed, 20 Apr 2011 14:34:36 +0200

Para todos aquellos que estáis siguiendo el tutorial de introducción a EJB 3.1, pero habéis decidido usar Glassfish v3 como servidor de aplicaciones (en lugar de JBoss 6), aquí tenéis el código necesario para configurar el cliente Java que conecta con el contenedor EJB:



Properties props = new Properties();

props.setProperty("java.naming.factory.initial", "com.sun.enterprise.naming.SerialInitContextFactory");

props.setProperty("java.naming.factory.url.pkgs", "com.sun.enterprise.naming");

props.setProperty("java.naming.factory.state", "com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl");

 

// Opcional. Por defecto es localhost. Solo es necesario si el servidor se está ejecutando en una máquina distinta 

props.setProperty("org.omg.CORBA.ORBInitialHost", "localhost");

 

// Opcional. Por defecto es 3700. Solo es necesario si el puerto ORB es diferente de 3700    

props.setProperty("org.omg.CORBA.ORBInitialPort", "3700");



Context ic = new InitialContext(props);

De manera adicional, la aplicación cliente puede necesitar que el módulo gf-client.jar se encuentre en el classpath (puedes encontrar dicho módulo en el directorio glassfish\modules de tu instalación de Glassfish v3).

Muchísimas gracias a Antonio Querol por ponerse en contacto conmigo y compartir esta información.

Retomando el blog

programacion@davidmarco.es (David Marco) — Tue, 21 Feb 2012 19:14:50 +0100

Para los que seguís mi blog, os será evidente que hace mucho tiempo que no publico nada; compromisos laborales y personales me tienen atado 24 horas al día, 7 días a la semana, dejándome apenas tiempo para sentarme delante del PC y escribir cualquiera de los muchos artículos que tengo en mente (o simplemente pendiente, como las dos últimas entregas del tutorial de EJB 3.1...).

Puesto que sois muchos los que me animáis a través de correo electrónico a continuar publicando contenido (y por ello os doy las gracias), en los próximos días volveré a la carga con nuevos artículos. Espero poder encontrar desde este mismo instante el tiempo suficiente para escribir tres artículos de cierta dimensión cada dos meses, como mínimo (y creedme que haré todo lo posible por llevarlo a cabo).

Por descontado, toda sugerencia sobre nuevos artículos será bienvenida, por lo que os animo a poneros en contacto conmigo al respecto como habéis hecho hasta ahora. Un saludo y hasta muy pronto.

Lazy Fetch en JPA

programacion@davidmarco.es (David Marco) — Thu, 23 Feb 2012 23:53:08 +0100

Una de las características que ofrecen JPA (entre otros frameworks de mapeo relacional de objetos) que más puede beneficiarnos cuando la entendemos y aplicamos de forma correcta, y que más quebraderos de cabeza provoca a quienes están empezando, es Lazy Fetch. Aunque ya hemos hablado con anterioridad de forma superficial sobre Lazy Fetch durante el tutorial de JPA publicado en esta misma web, debido a la cantidad de personas que se ponen en contacto conmigo al respecto y por la satisfacción inherente de entender un poco mejor una importante caracteristica del lenguaje, he considerado interesante escribir un pequeño artículo donde se analice con cierta profundidad qué es, cómo funciona, y cómo podemos beneficiarnos (además de cómo evitar errores típicos) de Lazy Fetch . Comencemos.

LAZY FETCH, A.K.A. LECTURA DEMORADA
El termino Lazy Fetch, que traducido literalmente significa obtención perezosa (aunque yo prefiero entenderlo como lectura demorada), viene a reflejar la característica de JPA que permite que, cuando existen relaciones entre distintas entidades, las que son dependientes de otras no sean inicializadas con sus valores almacenados en base de datos hasta que no sean explícitamente accedidas (leidas). Toda esta verborrea se entiende mejor con un sencillo ejemplo:



@Entity

public class Factura {

    // ...

}



@Entity

public class Proveedor {

    // ...



    @OneToMany

    private List facturas;

}

En el ejemplo anterior, tenemos una entidad contenedora (Proveedor) que contiene una relación uno-a-muchos (@OneToMany) con otra entidad, Facturas a través de un objeto List. Hasta aquí todo es bastante simple, por lo que... ¡compliquémoslo!

Imaginemos que cada proveedor concreto suele tener multitud de facturas asociadas (algo bastante habitual), aunque gran parte de las consultas a la entidad Proveedor no están accediendo en ningún momento a dichas facturas; cada obtención de un proveedor desde base de datos supondría realizar diferentes subconsultas para inicializar todas sus facturas, de manera que estaríamos incurriendo en una sobrecarga innecesaria de los recursos del sistema (esto en un ejemplo de juguete como el nuestro no es apreciable ni notorio, pero en un sistema real que esté recibiendo miles o decenas de miles de peticiones por minuto (por poner una cifra) puede sobrecargar y hasta agotar los recursos de la red, procesadores, ram, base de datos, etc...).

Por este motivo, JPA permite marcar una relación entre entidades como Lazy, de manera que la inicialización desde base de datos de los objetos afectados es retrasada hasta que éstos son explicitamente requeridos por código cliente.

¿QUIÉN ES LAZY?
Por defecto, de los cuatro tipos de relación entre entidades permitidos en JPA (@OneToOne, @OneToMany, @ManyToOne y @ManyToMany) sólo dos son de tipo Lazy: @OneToMany y <@ManyToMany. Esto tiene mucho sentido, pues son estos dos tipos los que a más objetos conectan en el otro lado de la relación. Al ser el comportamiento por defecto, no debemos hacer nada para declarar estas relaciones como Lazy (es su comportamiento implícito).

El resto de relaciones no-Lazy (@ManyToOne y @OneToOne) deben ser marcadas explícitamente como Lazy si queremos que se comporten de dicha manera:



@Entity

public class Empleado {

    // ...



    @OneToOne(fetch=FetchType.LAZY)

    private Direccion direccion;

}

EL GRAN PROBLEMA
Una vez una entidad contenedora ha sido desconectada (dettached) del gestor de persistencia (por ejemplo al enviarla de vuelta al código cliente que la solicitó), esta se enviará tal como esté en ese momento sin importar en que estado estén sus relaciones que hayan sido marcadas como Lazy. Si una relación ha sido inicializada antes de desconectar la entidad del gestor de persistencia, podremos acceder a sus valores de forma normal; en caso contrario, la relación no apuntará a ningún objeto, y por tanto obtendremos un error al intentar manejarla:



@Stateless

public class ClaseDelLadoServidor {

    // ...

    

    public Proveedor obtenerProveedor(Long proveedorId) {

        // Conectamos con BBDD y obtenemos la entidad a devolver

        

        return proveedor;        // Supongamos que en este momento la colección facturas

                                // no ha sido inicializada aún

    }

}



public class ClaseDelLadoCliente {

    public void procesarFacturas(long proveedorId) {

        Proveedor proveedor = claseLadoServidor.obtenerProveedor(proveedorId);

        for(Factura factura : proveedor.getFacturas()) {

            // Procesar cada factura

        }

    }

}

En el ejemplo anterior, la simple llamada a getFacturas() en la clase del lado del cliente provocaría una excepción que, dependiendo de tu proveedor de persistencia (en mi caso es EclipseLink) se parecerá más o menos a esto:



Exception in thread "main" Local Exception Stack: 

Exception [EclipseLink-7242] (Eclipse Persistence Services - 2.0.1.v20100213-r6600): org.eclipse.persistence.exceptions.ValidationException

Exception Description: An attempt was made to traverse a relationship using indirection that had a null Session.  This often occurs when an entity with an uninstantiated LAZY relationship is serialized and that lazy relationship is traversed after serialization.  To avoid this issue, instantiate the LAZY relationship prior to serialization.

    at org.eclipse.persistence.exceptions.ValidationException.instantiatingValueholderWithNullSession(ValidationException.java:979)

    at org.eclipse.persistence.internal.indirection.UnitOfWorkValueHolder.instantiate(UnitOfWorkValueHolder.java:219)

    at org.eclipse.persistence.internal.indirection.DatabaseValueHolder.getValue(DatabaseValueHolder.java:83)

    at org.eclipse.persistence.indirection.IndirectList.buildDelegate(IndirectList.java:237)

    at org.eclipse.persistence.indirection.IndirectList.getDelegate(IndirectList.java:397)

    at org.eclipse.persistence.indirection.IndirectList.size(IndirectList.java:726)

    at es.davidmarco.ejb.lazyloading.standaloneclient.LazyLoadingClient.main(LazyLoadingClient.java:43)

El mensaje principal que se informa en el error es el siguiente:

Ha sido realizado un intento de recorrer una relación mediante indirección que tenía una sesión null. Esto ocurre a menudo cuando una entidad que contiene una relación Lazy sin inicializar es serializada y dicha relación es recorrida después de la serialización. Para evitar este problema, inicializa la relación Lazy de forma previa a la serialización.

Los primeros de la clase se estarán preguntando: ¿cómo es posible que nuestro cliente, que posiblemente se esté ejecutando fuera de un contenedor de aplicaciones, tal vez incluso en otra máquina funcionando bajo una JVM distinta, esté lanzando una excepción JPA en lugar de algo como la archimalvada NullPointerException? El proveedor de persistencia puede hacer esto de algunas maneras, como devolviendo objetos proxy que envuelven al objeto original, o manipulando el código de bytes, entre otras. No voy a profundizar en este asunto pues no nos afecta de forma directa, pero tenlo simple presente de manera que, cuando suceda, sepas lo que está ocurriendo.

LA GRAN SOLUCIÓN
Es un poco atrevido pensar en que existe una gran solución a nuestro gran problema, pues primero deberíamos preguntarnos si éste es realmente tal; hasta ahora lo hemos llamado así por el simple hecho de que a todos (al menos a todos los que hemos trabajado con JPA) nos ha ocurrido en alguna ocasión, sobre todo al principio, y los sentimientos que produce van desde "chocante" hasta "desconcertante" (sobre todo si no sabemos que está ocurriendo y, todavía peor, tampoco porqué). Lo cierto es que no es ningún problema, y tal como hemos dicho anteriormente, Lazy Fetch trata simple y llanamente de eso: enviar la información necesaria, y omitir el resto hasta que sea explicitamente accedida.

Una solución par evitar enviar a un cliente relaciones no inicializadas es definirlas explícitamente como no-lazy (o dicho de forma más correcta, Eager):



@Entity

public class Empleado {

    // ...



    @ManyToMany(fetch=FetchType.EAGER)

    private List proyectos;

}

También podemos inicializar implícitamente las entidades asociadas a través de algún mecanismo del lenguaje:



@Stateless

public class ClaseDelLadoServidor {

    // ...

    

    public Proveedor obtenerProveedor(Long proveedorId) {

        // Conectamos con BBDD y obtenemos la entidad a devolver

        

        facturas.size();        // Inicializa la relación al completo. No usar para inicializar de

                                // forma explícita, en su lugar usar fetch=FetchType.EAGER.

        

        return proveedor;

    }

}

Para no violar el cometido principal de Lazy, sólo debemos inicializar una relación (ya sea de forma explícita o implícita) en escenarios como los siguientes:

    - Cuando conocemos de antemano que los clientes de nuestra entidad van a acceder a el/los miembros de la relación después de que esta sea desconectada del contexto de persistencia.

    - Cuando, a pesar de mantenernos aún dentro de una transacción, sabemos que se van a producir multitud de llamadas a los elementos referenciados en la relación (cada una de ellas realizando sus peticiones a base de datos de forma exclusiva e independiente de las demas), de manera que el coste total va a terminar siendo mayor que si hubiéramos inicializado la relación en el momento de la inicializar la entidad contenedora.

Evidentemente, estas situaciones no son faciles de preveer en la mayoría de los casos, más aún cuando no tenemos control sobre el código cliente. Éste último, si está bajo nuestro control, no debe hacer llamadas a relaciones no inicializadas (evidentemente). En caso de no conocer de antemano si una relación ha sido inicializada, debemos manejar un posible error mediante tratamiento de excepciones (esto es, capturándo la excepción e inicializando la relación dentro del bloque catch). Al margen del tratamiento de excepciones, si deseamos acceder a una relación que sabemos que no está inicializada, deberemos gestionarlo a través de lógica de negocio adicional (podemos enviar la entidad contenedora de vuelta al servidor de aplicaciones para que sea refrescada con la información ausente y devuelta de nuevo al cliente, solicitar sólo las entidades contenidas en la relación a traves de algún valor de la entidad contenedora que permita identificarlas, etc...). Esta lógica adicional estará integrada en el lado del servidor, pues es allí donde tenemos acceso al contexto de persistencia.

MOJÁNDONOS LOS PIES
Es importante entender que ocurre entre bambalinas cuando tratamos con relaciones de tipo Lazy, por lo que vamos a sumergirnos un poco (aunque muy poco) en la forma en que esto ocurre dentro de JPA. Todas (repito, todas) las operaciones de persistencia JPA se producen dentro de una transacción. Tarde o temprano, toda transacción finaliza, y en ese momento todas las entidades involucradas son desconectadas del contexto de persistencia, dejando de estar gestionadas por EntityManager.

En el ejemplo de la sección anterior, la clase ClaseDelLadoServidor ha sido marcada como @Stateless, de manera que ya sea mediante persistencia manejada por el contenedor (JTA) o controlada manualmente (RESOURCE-LOCAL), en el momento de terminar la ejecución del método se debe dar por terminada la transacción. Es en este momento cuando la entidad puede ser devuelta al cliente que la solicitó.

En el caso de estar trabajando con componentes de tipo @Statefull, podemos mantener una transacción por un periodo de tiempo mayor al de una única invocación a cualquiera de los métodos del componente, por lo que la entidad y sus relaciones pueden permanecer gestionadas por un tiempo mayor al de una única invocación a cualquiera de los métodos del componente (esto implica que cualquier acceso a una relación no inicializada se trataría de forma transparente para nosotros).

Al trabajar con relaciones Lazy, debemos usar siempre interfaces (como List o Map) en lugar de implementaciones concretas (como ArrayList o HashMap): esto, además de ser una las grandes-reglas/buenas-prácticas cuando utilizamos un lenguaje orientado a objetos como Java, va a permitir al proveedor de persistencia usar sus propias implementaciones lo que a su vez nos permitirá a nosotros beneficiarnos de la magia de Lazy Fetch.

LA OTRA CARA DE LA MONEDA
El comportamiento opuesto a Lazy Fetch, como vimos en un ejemplo anterior, es Eager Fetch (el término puede traducirse literalmente como obtención impaciente, pero yo, de nuevo, prefiero entenderlo como inicialización temprana). Cuando una relación es de tipo Eager, o es marcada con este comportamiento de forma explícita, ésta es inicializada en el mismo instante en que lo es su entidad contenedora. Esto conlleva cero problemas para el código cliente, pues a efectos prácticos estamos en la misma situación que cuando trabajamos con POJOs en un entorno de no-persistencia (se aplican las reglas de construcción típicas del class loader). Tan simple como eso.

USO Y ABUSO
Lazy Fetch tiene un cometido concreto, y esto por si sólo ya es motivo para su existencia. El coste de crear objetos puede ser inmenso si todas las relaciones dentro de una entidad (relaciones que a su vez pueden contener sus propias relaciones, y así indefinidamente) fueran iniciadas en cascada desde el momento de creación de la entidad contenedora original. Otra situación en la cual Lazy Fetch es sumamente útil es cuando definimos una relación con objetos de gran tamaño (como BLOBs y CLOBs). Esta clase de relaciones suelen definirse como Lazy y, en caso de ser necesario el/los objeto/s referenciados, accedidos mediante lógica adicional. Todo esto representa el buen uso de Lazy Fetch.

Por supuesto podemos inicializar explícitamente todas las relaciones como Eager y olvidarnos de todo lo demás, y esto representa el mal uso de la arquitectura. Tarde o temprano terminaremos incurriendo en costes extra, ya que entre todos los objetos que estaremos inicializando, multitud de ellos serán accedidos en muy raras ocasiones (o incluso ninguna).

En este punto, y a pesar del gran problema que tuvimos unas secciones más atrás, podríamos pensar que "Lazy Fetch es un mecanismo mejor que Eager Fetch"; nada más lejos de la realidad, pues podemos terminar cometiendo un pecado distinto pero igual de grave, el de marcar toda relación viviente como Lazy: puesto que ninguna relación estará inicializada dentro de la entidad contenedora, todos y cada una de los accesos que realicemos sobre ellas conllevará el coste extra de una nueva petición a base de datos, situándonos de nuevo frente a posibles futuros problemas de agotamiento de recursos.

La solución, como casi siempre, se encuentra en encontrar el equilibrio (en nuestro caso determinar que componentes deben ser Lazy y cuales Eager). Si bien esto es algo que no puede ser definido con exactitud en el momento de iniciar el desarrollo de una aplicación, lo será en mayor o menor medida durante su periodo de vida (en parte gracias a herramientas externas y en parte gracias al propio comportamiento y/o respuesta de la aplicación ante situaciones de estress).

RESUMEN
Esto es todo lo que necesitas saber para, si no ser el gran Gurú de Lazy Fetch, si al menos saber en cierto detalle qué es y cómo funciona. Puedes encontrar información adicional en esta misma web sobre persistencia en general y JPA en particular aquí y aquí. Saludos.

Cambio de alojamiento externo

programacion@davidmarco.es (David Marco) — Sun, 04 Mar 2012 20:28:59 +0100

Desde este momento, los tutoriales en versión PDF de Spring MVC e Hibernate, así como el proyecto para eclipse del primero, se mueven desde el servicio de almacenamiento externo 4Shared a Dropbox. Este último, además de ofrecer descargas simultaneas, mantener la misma url al subir nuevas versiones y carecer de tiempo de espera, requiere menos mantenimiento por mi parte. Las nuevas direcciones son las siguientes:

Tutorial de Spring MVC: http://dl.dropbox.com/u/42898825/davidmarco.es/SpringMVC.pdf
Tutorial de Hibernate: http://dl.dropbox.com/u/42898825/davidmarco.es/Hibernate.pdf
Proyecto para eclipse (Spring MVC): http://dl.dropbox.com/u/42898825/davidmarco.es/springapp.rar

Como consecuencia de este cambio, dentro de 60 días dejaré de dar soporte a mi cuenta de 4Shared, por lo que los citados archivos sólo estarán accesibles desde las nuevas direcciones.

Estoy seguro que este cambio supondrá una mejora para todos, y como siempre os invito a que me enviéis vuestro feedback. Por último, recordaros que las versiones html siguen siendo accesibles desde la habitual página de tutoriales.

Cambio de alojamiento externo

programacion@davidmarco.es (David Marco) — Sun, 04 Mar 2012 20:29:21 +0100