Un mes más tarde, entre vacaciones y otras historias, pero aqui siguen. Siguiente “capítulo” de los EJB: Message Driven Beans.

5. Mesage Driven Beans

Los siguientes beans a tratar son los Message Driven Beans (MBD), unos beans con una estrecha relación con JMS (Java Messaging Service). De hecho la mayoría de los MBD son consumidores de mensajes JMS. Dado que para trabajar con ellos se usan clases de la API JMS, antes de entrar en los MBD propiamente dichos haré una breve introducción a JMS.

5.1 Mensajería

En JEE el concepto de mensajería se refiere a la comunicación con poco acoplamiento entre emisor y receptor y totalmente asíncrona. Se podría definir su comportamiento como buzón de voz, donde un emisor deja un mensaje para que un receptor lo recoja cuando pueda. En terminología JEE tenemos un producer (emisor) que almacena un mensaje en un destino, un almacen específico. Posteriormente un consumer (receptor) comprueba si hay algún mensaje para él en el destino.

Existen diferentes modelos de mensajería. Un modelo se define por la forma en que se comunican los producers y los consumers:
- point-to-point (punto a punto): el mensaje va de un emisor A a un receptor B, quedando almacenado en una cola (queue). La cola no garantiza el orden de entrega de los mensajes (sí, mala elección del nombre). Si existe más de un receptor potencial se elige uno de forma aleatoria. Una vez entregado el mensaje desaparece de la cola. La analogía sería un mensaje en una botella, lanzada al mar (queue) que es recibida por alguien desconocido en una playa. Toda persona en la playa es un posible receptor pero no sabemos quién la recibirá.
- publish-subscriber: lo más parecido a publicar algo en un chat. El emisor (publisher) envía el mensaje a un “topic”, un almacen temático de mensajes. Los multiples receptores (subscribers) que estén conectados en ese momento reciben el mensaje. Una vez enviado el mensaje se pierde.

Hay más modelos de mensajería en JMS, algunos de ellos variaciones de los expuestos con derecho a respuesta por parte del receptor, pero estos dos son los que se usan con MDB.

5.2 Java Messaging System

La API JMS es para la mensajería lo que JDBC es para las bases de datos. Proporciona un accesso simple y uniforme a los servicios de mensajería y es soportado por la mayoría de sistemas. Un ejemplo de código para ver cómo funciona:

Ejemplo(código correspondiente a diversas partes de una clase):
@Resource(name=”jms/QueueConnectionFactory)
private ConnectionFactory connFactory;

@Resource(name=”jms/ShippingQueue”)
private Destination destination;

Connection connection = connFactory.createConnection();
Session session = connection.createSession(true, Session.AUTO_ACKNOWLEDGE);

MessageProducer producer = session.createProducer(destination);

ObjectMessage message = session.createObjectMessage();
//crear objeto a enviar aquí
….
message.setObject(shipping);

producer.send(message);

session.close();
connection.close();

El código es bastante autoexplicativo. Las variables “connFactory” y “destination” definen las bases de la comunicación, el origen del emisor y el destino del mensaje, en este caso una queue. Las anotaciones indican a JEE la dirección JNDI. La ConnectionFactory es usada para crear objetos de conexión, que crean objetos de sesión (una sesión de mensajería entre emisor y destino) y estos crean el “Producer”, el emisor en si. El objeto “ObjectMessage” es el mensaje que enviaremos, al que agregamos un objeto con los datos a transmitir. Posteriormente mandamos el mensaje mediante el producer, y cerramos las conexiones al haber terminado el trabajo.

Hay más detalles, como el hecho de que la sesión sea transaccional en este ejemplo (el “true” de “createSession”) y que debido a ello no enviaremos el mensaje hasta cerrar la sesión (session.close()), pero son aspectos que se salen del objetivo de mostrar un ejemplo de envio de mensajes. Para obtener documentación exhaustiva visita http://java.sun.com/products/jms/docs.html

5.3 Message Driven Beans

Los MDB están pensados para consumir los mensajes creados usando JMS. De hecho son más potentes, usando JCA (Java EE Connector Arquitecture) pueden recibir mensajes de cualquier EIS (Enterprise Information Service) lo que los hace muy versátiles y facilita la integración con sistemas obsolescentes. Pero la mayoría de las veces los usareis para recibir mensajes desde JMS.

Ejemplo(POJO):
@MessageDriven(
name=”ShippingRequestProcessor”,
activationConfig={
@ActivationConfigProperty(
propertyName=”destinationType”,
propertyValue=”javax.jms.Queue”),
@ActivationConfigProperty(
propertyName=”connectionFactoryJndiName”,
propertyValue=”jms/QueueConnectionFactory”),
@ActivationConfigProperty(
propertyName=”destinationName”,
propertyValue=”jms/ShippingQueue”),
}
)
public class ShippingRequestMDB implements MessageListener{
private java.sql.Connection connection;
private DataSource dataSource;

@Resource
private MessageDrivenContext context;

@Resource(name=”jdbc/TurtleDS”)
public void setDataSource(DataSource datasource){
this.datasource = datasource;
}

@PostConstruct
public void initialize(){
try{
connection = dataSource.getConnection();
}catch(SQLException e){
e.printStackTrace();
}
}

@PreDestroy
public void cleanup(){
try{
connection.close();
}catch(SQLException e){
e.printStackTrace();
}
}

public void onMessage(Message message){
try{
ObjectMessage objectMessage = (objectMessage) message;
ShippingRequest shipRequest = (ShippingRequest) objectMessage.getObject();
}catch(SQLException e){
e.printStackTrace();
context.setRollBackOnly();
}
}

}

Como se puede apreciar la principal diferencia con un Session Bean esta en la anotación inicial, más compleja. La complejidad adicional es debido a que la anotación además de definir el nombre indica a que “almacén” estamos escuchando, en este caso una Queue. El resto del código es muy similar. La clase implementa la inteface MessageListener de la API JMS, para indicar que recibiremos mensajes. Se usa inyección de dependencias para crear un contexto (MessageDrivenContext) y dar acceso a unos recursos JNDI (la conexión al datasource). Tenemos dos métodos para ejecutar en el ciclo de vida del bean, uno después de construir el objeto (initialize) y otro antes de destruirlo (cleanup). Y por último un método exigido por la interficie (onMessage) que contiene la lógica de negocio del bean.

Sobre las propiedades de la anotacion ActivationConfigProperty, cada una indica un parámetro de configuración. Exiten las siguientes:
- destinationType: indica el tipo de almacén (Queue, Topic)
- connectionFactoryJndiName: indica la factoría de conexiones JMS que usará el MDB
- destinationName: dirección del almacén (jndi)
- acknowledgeMode: cómo se indica al almacén que hemos procesado el mensaje para que lo borre. Hay dos valores: AUTO_ACKNOWLEDGE (por defecto, lo hace solo) y DUPS_OK_ACKNOWLEDGE (como auto pero menos riguroso, permite la existencia de envíos duplicados)
- subscriptionDurability: sólo para Topics, puede ser “non_durable” (default) o “durable”. En el segundo caso el mensaje no se borra hasta que tod subscriptor del tipo “durable” lo ha leído, aunque no estuviera online en el momento de su emisión.
- messageSelector: permite filtrar los mensajes que consume nuestro MDB

5.4 Ciclo de vida

Ahora que ya hemos visto como funcionan los MDB es hora de explicar brevemente su ciclo de vida. El ciclo de vida de los MDB tiene tan sólo 3 fases: no existe, desocupado y ocupado. Un bean en estado “no existe” no ha sido instanciado por el contenedor. Una vez instanciado pasa a la fase “desocupado” donde espera un mensaje. Cuando lo recibe, pasa a la fase “ocupado” mientras lo procesa. Una vez lo ha procesado vuelve a la fase “desocupado”. Si se necesita liberar recursos en el contenedor los beans de la fase “desocupado” pueden ser destruidos e ir a la fase “no existe”.

El control de estas fases del ciclo se hace mediante dos callback: @PostConstruct y @PreDestroy. El primero se ejecuta cuando el bean llega a la fase “desocupado” por primera vez. El segundo cuando estamos a punto de volver a la fase “no existe”.

5.5 Enviar mensajes desde MDB

Una situación muy común es que un MDB reciba un mensaje y durante el proceso ocurra un error que hay que notificar al emisor. Dado que la comunicación es asíncrona, la única forma de asegurarnos que recibe la notificación es enviar un mensaje desde el MDB al emisor. Para enviar un mensaje simplemente usamos el código del punto 5.2 embebido dentro del MDB. Hay que tener en cuenta que esto penaliza el rendimiento de los MDB. Si la situación es muy común pued eser más recomendable usar una comunicación síncrona como SOAP o RMI para aprovechar el canal establecido entre emisor y receptor.

La noticia tiene un mes, pero toca comentarla brevemente: IcedTea ha pasado el estricto test TCK de Java (Java Test Compatibility Kit). Este test verifica que IcedTea aporta las APIs de Java 6 con el comportamiento que se espera de ellas. Es decir, que actúa exactamente igual (bugs aparte) a otra implementación de la JVM, como la de Sun.

Esto convierte a IcedTea en la primera Java Virtual Machine 100% open-source (OpenJDK no era 100% opensource al pasar los tests IcedTea debido a unas API de audio). Esto es importante, pero cobra más importancia cuando vemos que el creador de IcedTea es Red Hat, propietaria de JBoss. Espero grandes mejoras en el rendimiento de JBoss en el futuro

Una situación común en las empresas de software es vender la personalización de un producto. Es decir, tu me pides una configuración concreta de Alfresco con ciertas funciones extras, yo te lo hago y te cobro un pellizco por ello. Todos contentos. Menos el programador. Porqué? Por los dolores de cabeza que obtiene a raíz del “merging”.

Al personalizar los productos tienes dos ramas de código en el repositorio: una contiene el código fuente de la aplicación mientras que la otra contiene el código personalizado. Si personalizas la aplicación para varias empresas, tendrás una rama con el código de la aplicación y varias con el código personalizado para los diversos clientes. Todo funciona hasta que llegas a trabajar y lees en la lista de correo del producto que han arreglado un agujero de seguridad importante. Toca actualizar el código, lo que implica actualizar las personalizaciones, es decir, hacer un merge del código viejo y el que corrige el bug.

La tarea en sí no es difícil, simplemente copias la nueva versión del fichero, recompilas y haces un deploy de la aplicación. Pero la ley de Muprhy se cumple y has de realizar el merge sobre un fichero que has modificado por petición del cliente. Esto lo complica un poco, ya que has de realizar un merge manual, aunque en Linux puedes usar herramientas como Meld o en Windows Araxis Merge. Haces merge de las partes que interesan, y repites el proceso: compilar, deploy.

El problema es cuando no tienes un cliente, sino 50. Y no es un solo cambio, sino una “release” de bug fixes como les ha pasado a los chicos encargados de Moodle en mi trabajo: 557 bugs resueltos. A actualizar más de 50 clientes. Y como bien dice Murphy, muchos cambios en ficheros personalizados. Una pesadilla, resuelta en unas 5 horas gracias a nuestro Tech Leader y el tiempo que dedico a principios del presente 2008 a reestructurar la forma de trabajar con Moodle. Como lo ha hecho? Bienvenidos al “Unified Diff“.

Unified Diff

El “Unified Diff” es un formato usado por el comando “diff” de Linux que marca las diferencias entre dos ficheros como cambios que hay que realizar sobre el primero para que sea idéntico al segundo. Un ejemplo es:

--- original timestamp
+++ new timestamp
@@ -1,3 +1,9 @@
+This is an important
-notice! It should
(....)

Las 2 primeras líneas (las que empiezan por — y +++) marcan el fichero origen y el modificado. La línea de las @ indica las líneas a cambiar. Las líneas inferiores marcan líneas a agregar (empiezan con ‘+’) o a eliminar (empiezan con ‘-’).

El formato es fácilmente comprensible para un humano pero a la vez puede ser interpretado por una máquina sin problemas. Esto, junto al contexto que se incluye en el “diff” (no lo muestro) permite identificar fácilmente que partes del fichero han de ser modificadas.

Como se realizan los diff?

En Linux existe la instrucción “diff” que crea la salida unificada. La instrucción es compleja, pero la parte que nos interesa es:

diff -Naur origen destino > file.patch

Este comando crea un fichero (file.patch) que contiene las diferencias expresadas en formato unificado. Tan simple como esto. Podéis ver la salida directamente ejecutando:

diff -Naur origen destino

Hay un detalle a tener en cuenta: para evitar problemas los diff han de realizarse siempre relativos a una estructura de directorios idéntica, respetando los mismos niveles en el árbol de ficheros. Esto quiere decir que si tenemos un fichero en “/tmp/a.file”, realizar un diff contra un fichero en “/home/user/a2.file” puede crear problemas. Para que no los hubiera, deberiamos hacer el diff de “/tmp/a.file2 contra “/user/a2.file”.

Como los “path” de los ficheros son relativos a donde ejecutamos el comando diff, lo más normal es tener 2 directorios con la misma estructura interna (llamemosles origen y destino) y ejecutar diff desde el directorio que los contiene.

Aplicar los parches

Aplicar un parche es sencillo. Primero nos hemos de situar en la raíz de la estructura de directorios que contiene los ficheros a modificar. Esto es importante ya que al crear el fichero “patch” se ha almacenado una ruta relativa al fichero a modificar, y si lo ejecutamos desde otro punto recibiremos un error. Una vez en el directorio adecuado, ejecutamos:

cat file.patch | patch -p1

Esto aplicará el parche sobre el fichero adecuado, obteniendo la información de “file.patch”. En caso de que hubiera un error se nos mostrará por pantalla. Los errores suelen darse por “patch” creados de forma incorrecta. En unos pocos casos el programa puede ser incapaz de aplicar los cambios debido a que el fichero destino ha sido modificado de forma masiva, en este caso tendremos que aplicar el cambio a mano.

Una vez tenemos los parches, lo mejor es almacenarlos en el repositorio en lugar del código modificado. Esto nos permitirá aplicarlos a nuevas revisiones del código original de forma rápida y simple, ahorrando trabajo a los desarrolladores.

La clave: automatización

Hasta aquí el proceso de generar y almacenar los diff resulta más complicado que el proceso estándard de hacer commit del código sobre el svn. Y aplicar los parches no parece muy cómodo tampoco, aunque reduce el tiempo necesario para actualizar el codigo. Si da más trabajo, donde está la grácia? Pues en que el proceso es fácilmente automatizable. Una vez tenemos los patch, podemos crear un script (por ejemplo con Ruby) que recoja los patchs de nuestro repositorio y los aplique sobre un fragmento de codigo, dejandolo listo para ponerlo en producción.

Si lo convertimos en el escenario que he mencionado al inicio, con un código tan cambiado, podemos ejecutar un script que para cada cliente obtenga los parches de nuestro repositorio y los aplique a una cópia del código. De hecho el mismo script peude encargarse de obtener el código del repositório remoto del producto y una vez hayamos aplicado los parches (sin errores), poner ese código en producción. Acabamos de evitar un trabajo muy engorroso y que consume mucho tiempo, de una forma bien fácil.

Contrapartidas

El principal problema está en acostumbrarse a trabajar de esta forma. Supone algunos pasos extras que aunque se pueden automatizar, no resultan cómodos. Obviamente no es un sistema perfecto, sólo sirve para mantenimiento dentro de una misma versión, sin grandes cambios en los formatos de los ficheros. Y a veces podeis tener cambios muy grandes en un solo fichero, lo que producirá errores en el “patch” correspondiente. En estos casos es recomendable generar un nuevo “patch” y se pierde algo de tiempo en ello. Pero en general facilita mucho la vida y es un sistema que funciona independientemente del lenguaje o repositorio usado.

La virtualización es un mercado en esa fase en que ya no es una tecnología novedosa, es útil, y varias empresas quieren parte del pastel del grande: VMWare. En InfoQ han publicado que una de las compañía más famosas en el ramo de virtualización, y seguramente la que más ha aportado al campo, cambia de CEO en un momento en que nuevos jugadores entran en el mercado. Comentan que parece un movimiento más político que no por estrategia del negocio (y las acciones han bajado un 30% como resultado).

El anterior CEO era a su vez el fundador. Veremos que pasos toma la empresa en el futuro.

Vía los compartidos de Google Reader (gracias chicos!) he dado con este artículo de Expansión. El tema es más que conocido, y no dice nada nuevo. Lo triste es que a estas alturas, no hayan aprendido nada. Sigo en contacto con gente de mis anteriores empresas y sé los problemas que tienen para reclutar gente. No sera la primera vez que me han dicho si quería volver, pero cuando preguntas las condiciones, no han mejorado en nada. No se como se atreven a quejarse…

Spin es una novela de Robert Charles Wilson, que gano en 2006 (año de su publicación), el premio Hugo. Y merecidamente.

Sin previo aviso, la Tierra es envuelta por una membrana artificial que la aísla del resto del universo. Esa membrana filtra los objetos que pueden entrar y salir de la atmósfera y sitúa el planeta en un plano temporal diferente, donde cada segundo de la Tierra son 3.17 días en el exterior. La novela sigue las consecuencias de este fenómeno sobre la gente de una Tierra condenada, una población que sabe que debido a la membrana el Sol ya no existirá en 50 años. Quien ha creado la membrana? Con qué objetivo? Que destino espera a la humanidad?

Lo interesante de la novela es que pertenece a ese género que usa la ciencia ficción como excusa para plantear situaciones y reacciones muy humanas. Mediante explicaciones técnicas bastante buenas, con pocas licencias fantásticas además del Spin en sí. Además mezcla la visión histórica, el relato de lo que sucedió, con lo que sucede. Estos “flashbacks” dan unos cambios de ritmos que hacen la novela más amena, ya que mientras estás en una época te preguntas que pasará en la otra (aunque recibas algunas pistas en el camino).

La novela tiene una semi-continuación, Axis, situada en el mismo universo pero que no sigue la trama de Spin. Ya está reservada

Hoy en día la palabra “virtualización” es uno de los hypes de las IT. Parece la “silve bullet” de los administradores de sistemas: más seguridad, menos costes, CPD más pequeños, ahorro energético… todo muy bonito. Aquí hay un artículo (vía InfoQ) que comenta los pros y las contras de la virtualización. No es oro todo lo que reluce.

La tendencia actual de los procesadores es añadir núcleos. Tenemos dual-core, quad-core, y pronto veremos 8-core o lo que quieran inventar. Esto ha sido una forma de mantener la “Ley de Moore” ya que era extremadamente difícil crear nuevos procesadores más potentes, y tampoco era tan necesario. Dadas las aplicaciones que un usuario normal puede ejecutar en su día a día, poseer varios procesadores para repartir la carga de los múltiples procesos es mejor que tener un sólo procesador muy potente.

Claro que este cambio implica que los programadores han de adaptarse a un nuevo paradigma, donde es importante programar la aplicación para que aproveche los múltiples núcleos, fomentando el paralelismo de tareas. Esta forma de trabajar era importante en aplicaciones de servidor, pero al menos en Java los propios contenedores (JBoss, BEA, etc) gestionaban de forma transparente los threads relacionados con J2EE. Con los nuevos procesadores esta metodología se ha extendido al escritorio, donde el uso adecuado de threads mejora la experiencia del usuario.

Las optimizaciones en paralelismo han llegado a los lenguajes de programación y con Java 6 SUN ha intentado mejorar el sistema de threads de Java. En InfoQ han escrito dos artículos estudiando las mejoras introducidas. Como resumen rápido para los impacientes, si queréis aprovechar mejor los threads usad Java 6 y actualizad la JVM constantemente.

Una de las formas más fáciles de progresar en tu carrera profesional es ir saltando de empresa cada cierto tiempo, buscando una posición mejor con su correspondiente aumento. Especialmente interesante si estás en empresas que tienen la subida 0% como constante y cuyo concepto de carrera profesional es hacer lo mismo durante 10 años.

Cuando cambias de trabajo pasas por todo un ritual: entrevistas técnicas, de recursos humanos, test de conocimiento, dinámicas de grupo, etc. Cada uno exige una preparación específica, pero sin duda la más propensa a fallos es la entrevista con recursos humanos, plagada de preguntas “trampa” y el nerviosismo de no saber si estás respondiendo de forma “correcta”.

En el Blog Salmón han publicado unos artículos con preguntas que te pueden hacer, preguntas que debes hacer y preguntas sobre tu futuro jefe. No garantizan el éxito pero ir preparado siempre ayuda.

Aunque algunos ya la conoceréis, os adjunto un link a Java Source. Se trata de un recopilatorio de aplicaciones “open source” clasificadas por categorías, desde Ajax a herramientas XML. Es una buena forma de encontrar herramientas que resuelvan nuestras necesidades o de descubrir proyectos muy interesantes como Kbee.

Un detalle a destacar es que para cada proyecto además del enlace a la web y a la licencia que usa, muestra un listado de proyectos alternativos, lo que facilita la búsqueda de alternativas.