blog de ezamudio

Normalmente uso Axis2 para crear mis clientes de web services; es bastante sencillo ya que solamente hay que ejecutar el script wsdl2java pasando el WSDL del web service y se genera una clase que contiene todo lo necesario para invocar los métodos publicados en el servicio.

Recientemente, me topé con un web service que en pruebas funcionó muy bien pero resulta que en producción había que activar SSL (o sea en el URL en vez de solamente ) y además tuve que implementar un esquema muy poco usual (aunque sea un estándar): autenticación de cliente con PKI (Public Key Infrastructure - Infraestructura de Llave Pública).

El funcionamiento de SSL por lo general es que solamente el servidor se autentica con el cliente, y luego el cliente se autentica de alguna forma específica a la aplicación. La manera en que funciona la autenticación del servidor en una conexión SSL es via PKI; el servidor utiliza un certificado X509 que contiene su información, una fecha de expiración, una llave pública (RSA por lo general) y algunos datos del emisor de dicho certificado. En PKI se maneja el concepto de cadena de confianza, que consiste en que para poder aceptar el certificado de alguien más como válido, es necesario conocer al emisor o emisores de dicho certificado, hasta llegar al certificado raíz; si todos son considerados válidos y conocidos por el cliente, entonces se puede considerar válido el certificado del servidor.

Entre las clases de Java existe una que se llama ThreadLocal, en el paquete base  . Esta clase puede ser muy útil para optimizar recursos en ambientes concurrentes, ya que su función es guardar una variable asociada con un Thread.

De este modo, podemos tener un componente en nuestra aplicación que si necesita manejar algún tipo de estado por cada Thread que ejecuta alguno de sus métodos, se pueden usar variables ThreadLocal, y en casa hilo que se ejecuta, éstas variables tendrán un valor distinto.

La clase es genérica, lo cual nos permite indicar el tipo de variable que queremos guardar, sin necesidad de estar haciendo casts posteriormente.

Este mes fue liberada la versión 1.6.1 del framework SLF4J, del cual ya hablé en un post anterior. Solamente quiero hacer notar una de las mayores diferencias con las versiones anteriores (esto que voy a mencionar fue introducido en la 1.6.0 pero yo apenas me di cuenta):

Los métodos trace, debug, warn, info, etc tenían varias versiones: la que recibe un solo objeto, la que recibe 2, la que recibe un arreglo de objetos y la que recibe un Throwable. Anteriormente, esta última versión era la única que imprimía el stack trace del Throwable, cosa que ya todos sabemos que puede ser muy útil. El problema era si queríamos imprimir algunos otros datos en el mensaje de la excepción; la única opción era usar   o concatenar cadenas con el "+" (muy ineficiente). Pero ahora, las versiones que reciben 2 objetos y un arreglo de objetos, detectan si el último objeto recibido es un Throwable y entonces imprimen el stack trace. Esto es muy útil porque ahora podemos convertir una invocación al logger de este tipo:

Recientemente, durante el SpringIO, estaba ayudando a montar algunos carteles para el evento; mientras veía la agilidad (o falta de la misma) que tenemos los programadores para armar un simple cartel, me vino a la mente ese viejo chiste de cuántos programadores se necesitan para cambiar un foco. La respuesta original es ninguno, es problema de hardware  . Pero ese día empezamos a proponer variantes a la respuesta, enfocándonos en las distintas metodologías de desarrollo, y quisiera explayarme en algunas de ellas. Así pues:

¿Cuántos programadores se necesitan para cambiar un foco?

Pues bien, hace poco el buen rugi (o @rugi si prefieren) publicó una liga a un framework para RIAs (Rich Internet Applications), llamado Vaadin, preguntando si alguien lo conocía o lo había usado. Yo jamás había oído hablar de él, así que me puse a revisarlo y después de ver el video introductorio me dio bastante curiosidad, así que ya me puse a programar algunas cosas con esto.

El desarrollo con Vaadin se centra en hacer aplicaciones solamente programando en Java; no es necesario manejar Javascript ni HTML para la mayoría de las cosas. Se pueden desarrollar componentes propios, basados en los componentes existentes de Vaadin, que van desde botones, etiquetas, ligas y campos de texto hasta formas completas, campos para captura de fecha, notificaciones de errores, árboles jerárquicos, etc.

En la primera parte vimos ya cómo se almacenan nodos y sus relaciones en una base de datos de Neo4J. En esta segunda parte veremos cómo hacer búsquedas sobre los nodos, basados en las relaciones que hay.

A estas alturas es importante mencionar que las relaciones en Neo4J son unidireccionales; van de un nodo a otro. Pero no es necesario crear relaciones en el sentido opuesto si no es necesario, ya que se pueden buscar las relaciones indicando el sentido de las mismas. Para esto hay que considerar que la dirección se define desde el nodo que estamos utilizando.

El movimiento NoSQL, que ha tomado algo de fuerza en los últimos dos años, propone utilizar bases de datos diferentes a las relacionales, ya sea bases de datos orientadas a columnas en vez de a tuplas, o a documentos, etc. Entre las implementaciones que se pueden usar hoy en día tenemos HBase, Cassandra, Hypertable, CouchDB y una interesante, que además está hecha en Java: Neo4J.

Más allá de la discusión filosófica en torno a la validez de esta propuesta de NoSQL, implementaciones comerciales, aplicaciones prácticas, etc, quiero enfocarme a hablar un poco de Neo4J y la manera en que almacena datos.

En ocasiones anteriores he hablado de este tema, someramente, pero en esta ocasión quiero ya ahondar un poco más y hablar de un par de implementaciones de este mecanismo.

"Pool" en inglés no solamente significa piscina, sino también se usa para describir un conjunto de elementos disponibles para ser utilizados de alguna forma. Un pool de conexiones a base de datos es un mecanismo para optimizar el desempeño de una aplicación así como la utilización de recursos, teniendo varias conexiones ya establecidas al RDBMS, las cuales pueden ser utilizadas por cualquier proceso que las necesite.

Esto significa que en vez de que un componente establezca su propia conexión, la toma del pool y al final cuando ya no la necesita, la devuelve al pool. Hay incluso maneras transparentes de lograr esto, utilizando una implementación especial de DataSource, la cual cuando se le pide una conexión, tome una del pool, y dicha conexión se devuelva al pool cuando se invoque   (en vez de cerrarse físicamente).

En esta ocasión quiero describir un proceso un tanto complicado, que puede servirle a alguien tal vez, si se encuentran en la necesidad de hacer algo locochón como lo que tuve que hacer yo.

En términos generales, me encontré en la necesidad de agregar anotaciones a clases, en tiempo de ejecución. Es decir, una clase que no tiene ciertas anotaciones, porque no fue compilada así, necesita que se las agreguemos a la hora de correr una aplicación. Esto fue posible gracias a Javassist, una biblioteca de software libre que sirve precisamente para transformar clases en tiempo de ejecución, pero aún así el código y la manera de hacerlo es algo complejo.

Primero que nada, necesitamos el JAR donde se encuentra la clase que queremos modificar. Dependiendo del tipo de aplicación, la manera de obtener el JAR va a variar, pero lo importante aquí es que tengamos al final un InputStream del cual vamos a leer la clase. Una vez que tenemos el InputStream, debemos ir leyendo del JAR hasta obtener el archivo que queremos (un .class).

Recientemente actualicé una aplicación que utiliza Spring 2.5, para que utilice Spring 3.0 y quiero compartir algunos detalles de esta experiencia. No quiero decir que esta es la manera de actualizar pero pues espero le sirva a alguien y si hay mejores maneras también las puedan poner aquí como comentarios.

Primero que nada, quiero mencionar que los proyectos que actualicé no utilizan Maven ni Ivy ni nada por el estilo; de ahí la complejidad y la mención en mi blog; si fuera con Maven sería más sencillo y no habría tanto problema.

El primer cambio que noté con Spring 3.0 es que ya no existe un JAR grande (como era spring-2.5.6.jar por ejemplo) sino que ahora hay varios JARs, uno por módulo, y la nomenclatura se complicó un poco, por ejemplo  .