Sé que todos tendréis vuestras propias preferencias y que, seguramente, podréis ayudarme a encontrar esa joyita oculta entre las toneladas de información que proporciona el Builder. Después del documento, os explicaré con qué criterios ha sido construido… y que significan todos los símbolos y anotaciones manuscritas :)

La agenda está construida con las siguientes pautas:

• He intentado que haya una mezcla entre ponencias puramente técnicas y las más orientadas a negocio.
• También hay un equilibrio entre ponencias sobre tecnologías y productos que utiliza mi compañía actualmente (nubes privadas de EMC) y los que quiero conocer de primera mano como Lift
• He priorizado siempre los paneles y charlas, frente a las presentaciones de “siéntate, cállate y trágate mi Powerpoint”
• Por motivos evidentes, he eliminado cualquier ponencia impartida por gente de Google

Revisando la agenda, me doy cuenta de que hay una clara orientación a dos temas principales y… contradictorios entre sí: Cloud Computing y tunning de la JVM, que refleja un poco la esquizofrénica realidad que estamos viviendo actualmente.

Habréis observado que hay un montón de cruces y rayas. Os explicaré que significa cada cosa:

• Las cruces significan que hay algún evento que, por alguna extraña razón que no he logrado comprender, el Builder no lista. Por ejemplo, todas las Keynotes o presentaciones principales de Primo Larry
• Las rayitas sobre alguna de las ponencias quieren decir que es improbable que pueda asistir porque coinciden con algún evento o compromiso. El lunes, por ejemplo, es difícil que pueda asistir al taller de Play si quiero pasarme por la OTN Night a conocer a alguno de mis compañeros del metal, antes de salir corriendo a la cena organizada por la delegación para España y Portugal de Oracle
• En la parte inferior del documento, tenéis recopilados los eventos que no salen listados por el Builder y que completan la agenda. A la izquierda, presentaciones. A la derecha, los eventos vespertinos de networking

En cualquier caso y aunque me prometí el año pasado que no volvería a pegarme semejante paliza, me han vuelto a salir jornadas maratonianas de 8h a 22h. No sé de dónde voy a sacar tiempo para hacer de reportero dicharachero ni, como me ha advertido el gran Carlos Sánchez, darme cuenta de que “lo más interesante de la javaOne, ocurre en las fiestas de las noches“.

Artículos relacionados:

1. javaOne 2010 David Bonilla se va de vacaciones pagadas a San Francisco...
2. ¿Habrá JavaOne en 2010? Uno de los principales damnificados de la fusión entre Oracle...

Y, sin embargo, lo es. El modo en el que Glassfish trabaja con logs es peculiar y guarda algún oscuro secreto.  Sólo te pido dos cosas:

1. 1. Cinco minutos de tu tiempo para que juzgues si lo he conseguido.
   2. Que, para vivir una experiencia completa, escuches la canción ‘Old Souls‘ de la banda sonora de Origen mientras lees el artículo.

Lo peor que te puede pasar es que salgas de aquí aprendiendo algo nuevo y, por supuesto, siempre puedes tirarme tomates virtuales en los comentarios del artículo.  ¿Te animas?

EL MISTERIO DE LAS TRAZAS INEXPLICABLES

Como parte de mi asedio y conquista al entorno de trabajo de STORETTO, comencé a estudiar nuestro sistema de traza y la configuración del mismo. Parecía algo relativamente sencillo (una configuración típica de log4j) Sin embargo, algo no encajaba. Ni las trazas aparecían por donde debían ni tenían el formato que queríamos. Nada se parecía ni remotamente a lo que teníamos configurado.

Tampoco entendía por qué el equipo de STORETTO había configurado el sistema de log4j habitual de la compañía mediante una variable de sistema, en vez de colocar el fichero de configuración en el classpath de la aplicación.

¿Qué estaba pasando? ¿Era todo esto real o era un sueño? ¿Estaba soñando dentro de un sueño? ¿Cómo distinguir la realidad del sueño?

Como en el anterior caso de las JSPX desestructuradas, yo tenía un poco más de tiempo disponible que el equipo para comprender qué estábamos haciendo y por qué lo estábamos haciendo. Lo que averigüé fue SORPRENDENTE.

FRAMEWORK DE LOGGING DE GLASSFISH

Antes de nada, era importante conocer qué sistema de registro de trazas utiliza Glassfish y cómo funciona el mismo.

He resumido todo lo que se necesita saber en un par de párrafos:

Glassfish utiliza para su sistema de trazas la implementación por defecto de la especificación JSR-047, una API de logging, y recomienda el uso de la misma, aunque permite el uso de otras como Apache Commons Logging o log4j.

El uso de la API de logging del JDK implica varias cosas a tener en cuenta:

1. Se basa en un sistema de Handlers, clases que heredan de java.util.logging.Handler y que son los que encapsulan tanto la lógica de publicación de trazas como la configuración de las mismas.
2. Estableciendo un level o nivel por Handler podemos establecer el nivel mínimo de traza que queremos que recoja el HANDLER. Estableciendo un nivel determinado se recogerán todas las trazas de ese nivel y de los niveles superiores jerárquicamente (para conocer más sobre los nieles de traza, pinchar aquí). También se puede establecer el nivel mínimo de traza por paquete de clases, independientemente del nivel implementado por paquete (se usará la configuración más restrictiva)
3. Además del nivel, se puede establecer un control secundario y opcional sobre lo que se registra o no, mediante la asignación de un filtro o Filter (clase que hereda de java.util.logging.Filter) a un Handler. Un Filter, básicamente, implementa un método isLoggeable que devuelve un booleano que indica si un log se debe trazar o no.
4. Si se quiere formatear las trazas generadas con alguna estructura especifica, se debe implementar un Formatter (clase que herede java.util.logging.Formatter) y asignarlo al Handler deseado.
5. Toda esta configuración se hace a través de un fichero denominado logging.properties

La primera diferencia que chocará a todos los que venimos de usar log4j es que todo se configura programándolo. Es decir, no tienes una manera de poder configurar de forma flexible el formato de tus trazas. Si quieres un Formatter que saque el patrón de tu traza de un fichero de propiedades, vas a tener que programártelo.

TRABAJANDO CON LOG4J

¿Son mis logs reales o sólo un sueño?

Para trabajar con log4j en Glassfish v2 se recomendaba configurar la librería de traza como librería del sistema para evitar problemas con el classloading pero esto ya no puede hacerse con Glassfish v3 así que la solución pasa por indicar al servidor la ruta del fichero de configuración de log4j.

En log4j se configuran Appender (el equivalente de los Handler en JSR-047) El Appender típico que todo el mundo utiliza al desarrollar es el org.apache.log4j.ConsoleAppender, que publica los logs en la salida por defecto de System.out.

El problema es que las trazas no salen por la consola habitual que esperamos todos los programadores sino en un fichero server.log que se encuentra en la ruta /midominio/logs/.

Eso es bastante fácil de explicar porque  ese fichero es la salida por defecto del servidor, así que, ésa es su consola.

Lo que no tiene ni pies ni cabeza es que nuestras trazas salgan con el formato de las trazas de la API de logging de JDK o, más exactamente, envueltas por su formato, puesto que nuestro traza aparece… pero sólo como parte del mensaje de la traza de logging del JDK.

Bueno… podemos pensar que, de alguna manera, el sistema está ignorando nuestra configuración de log4j. Sin embargo, si configuramos cualquier otro Appender, por ejemplo uno que publique en un fichero inception.log, log4j funciona PERFECTAMENTE.

¿Entonces? ¿Qué está pasando? ¿Por qué salen todas mis trazas rodeadas de almohadillas ‘#’  y con un retorno de carro cuando las publico por consola?

LA SOLUCIÓN AL MISTERIO

No, no estamos soñando. Nuestras trazas son reales y nuestra configuración también. No estamos haciendo nada mal. Simplemente, alguien ha estado jugando con nosotros. Alguien ha estado haciendo trampas.

Glassfish, utiliza una implementación propia y sobrescrita del objeto System cuyo método out devuelve un PrintWriter que redirige todas las salidas al sistema de logging del servidor. Probadlo, hacer un System.out.println en una clase desplegada en Glassfish. No sólo aparecerá en la salida por defecto -server.log- sino que, además, aparecerá con el formato específico del sistema de logging.

Lo más grave de todo esto es que System es una clase final. Es decir, que no puede ser extendida, precisamente para evitar lo que Glassfish ha conseguido: que nuestro código tenga un comportamiento extraño y nos desconcierte. Que nos tengamos que frotar los ojos para comprobar que no estamos soñando.

De acuerdo, Glassfish nos ha engañado pero ahora, después de leer este artículo sabemos cómo vencerlo:

• ¿Queremos modificar el formato de las trazas del servidor? Implementaremos nuestro propio Formatter y se lo asignaremos al ConsoleHandler del fichero logging.properties
• ¿Queremos que nuestras propias trazas no se mezclen con las del servidor? Nos olvidaremos de utilizar el ConsoleAppender
• ¿Queremos que sólo nuestras trazas de error salgan en la salida por defecto del servidor? Podremos utilizar un ConsoleAppender y configurarlo en nuestro log4j.properties para que sólo registre trazas de nivel ERROR o superiores (recordad que sea cual sea el nivel de traza de log4j, la salida se publicará en System.out y el logging de JAVA las publicará por defecto como trazas de nivel INFO)

Glassfish ha luchado contra nosotros y ha perdido, por lo menos a nivel de logging. Nosotros le dominamos. No él, a nosotros. Y, desde luego, no estamos soñando… ¿o sí?

BONILINKS:

• Gente despotricando sobre el tweaking de System de Glassfish
• Gente flipando con el comportamiento de System.out
• La fuente del UniformLogFormatter (o el origen del formato de traza infernal de Glassfish)
• Información Oficial de Glassfish sobre configuración de logging, donde se les olvida comentar lo del asuntillo del System.out…
• Información para entender lo básico de la API Java Logging

Artículos relacionados:

1. Transacciones y bloqueos en Glassfish v3 con EJB3.1 y JPA2 (III) Tercera parte del tutorial sobre como utilizar transacciones y bloqueos...
2. Transacciones y bloqueos en Glassfish v3 con EJB3.1 y JPA2 (II) Segunda parte del tutorial sobre como utilizar transacciones y bloqueos...
3. Transacciones y bloqueos en Glassfish v3 con EJB3.1 y JPA2 (I) Un sencillo tutorial sobre como utilizar transacciones y bloqueos con...

Sé que soy un privilegiado por disfrutar del apoyo de Sixservix para volver a asistir a la conferencia. Un apoyo que, desgraciadamente, es difícil de encontrar en el sector de las TI en España y América latina. Pero, en cualquier caso, conozco gente que, aún pudiendo asistir, ni siquiera se lo ha planteado; bien por desconocimiento del evento en sí, bien por antiguas y falsas creencias o leyendas. Así que, permitidme que os explique qué espero encontrar allí, qué pienso hacer y cómo pretendo hacerlo. Ojalá que, cuando acabéis de leer este artículo, todos estéis deseando acompañarme. Si no este año, quizás el siguiente.

UNA CIUDAD. UNA SEMANA. TRES CONFERENCIAS

Ya comenté el año pasado como la javaOne cumplía con las 3 Bs: bueno, bonito y barato. Este año, después de unos meses de incertidumbre en los que ni siquiera sabiamos si iba a celebrarse, nos encontramos con que Oracle, el nuevo amo y señor de Java, ha montado la mundial. No sólo sigue celebrándola sino que ha decidido juntarla con Develop, su conferencia de desarrolladores,  y OpenWorld, su evento más orientado a tíos-que-manejan-la-pasta y cuellocorbatas.

La primera consecuencia de todo esto es que San Francisco va a estallar. Si a los 15.ooo asistentes de la javaOne les sumas los 43.ooo trolorolos que asistieron a la OpenWorld del año pasado y reservaron 81.000 habitaciones de hotel, te encuentras con que es más facil conseguir batir el récord olímpico de petanca que conseguir una habitación de hotel económica en la ciudad del Golden Gate.

La segunda consecuencia es que, durante una semana, San Francisco probablemente disfrute del mayor número de técnicos y desarrolladores reunidos de la historia. Porque, a la tremenda horda invasora, hay que sumar la población local de tipejos que desarrollan cosas como Twitter, Google o cacharros como los de Apple o Hewlett-Packard.

En definitiva, 2.150 sesiones condensadas en una sóla ciudad y una sóla semana. La posibilidad de asistir a charlas de cualquier tecnología o lenguaje que se te pueda ocurrir impartidas por los mejores: sus creadores. Y, por supuesto, la posibilidad de conocerlos.

No hay nada ni remotamente parecido en el mundo de las tecnologías de la información. Ni en tamaño ni en posibilidades. Ni para aprender, ni para hacer networking. Nada se acerca a lo que va a verse en esta JavaOne.

LA MISIÓN: LIARLA PARDA

¿Y qué espero este año de la javaOne? ¿Qué pretendo hacer allí? Evidentemente, dar un paso más en mi plan secreto para dominar el mundo y, de paso, aprender todo lo que pueda, conocer gente interesante y divertirme. Voy a intentar resumir en 6 puntos mis expectativas:

• APRENDER MUCHO. Sí, es verdad que con Internet no hace falta asistir físicamente a una conferencia para aprender cualquier conocimiento pero, sinceramente, ¿cuántos de nosotros tenemos tiempo en nuestro día a día para ponernos a leer complejos tutoriales o sumergirnos en vídeos y vídeos de charlas y ponencias? La javaOne permite que durante una semana, nos aislemos de todo y de todos y nos dediquemos a lo que más nos gusta: aprender.
• HACER NETWORKING. Sí, networking, pero del de verdad. Espero conocer a mucha gente-que-de-verdad-hace-cosas como los denomina Alberto Molpeceres. Todo lo contrario a los eventos de tipo “reinventa Internet” que han crecido como setas en mi país.
• CREAR COMUNIDAD. El año pasado constaté que los hispanohablantes éramos más de los que cualquiera pudiera creer pero, al contrario que los brasileños, nos falta marketing. Espero que en esta javaOne se oiga el castellano más que nunca. Por mí no va a quedar.
• COMUNICAR, COMUNICAR, COMUNICAR. Si el año pasado perdí horas de sueño haciendo las crónicas del día para javaHispano, este año el trabajo se multiplica. No sólo intentaré enviar las crónicas diarias, sino que podréis leer la versión gamberra y desenfadada de las mismas en este blog. Además, nuestras cuentas de twitter echarán humo, por supuesto y, como gran novedad… MEGATÓN: intentaré retrasmitir al más puro estilo reportero dicharachero mediante screencast. Eso, si consigo averiguar cómo funciona la cámara que me regaló Jeroclo por mi cumpleaños.
• COMER PATO LAQUEADO EN CHINATOWN. Una sana costumbre que instauramos Álvaro Hernandez y yo el año pasado y a la que esperemos que se sumen los nuevos fichajes de este año: Erick Camacho, compañero del metal en javaHispano, y Jeroclo, el espartano, amigo, camarada y socio, en representación de Funius. Por supuesto, habrá que ir a disfrutar del brunch del domingo al Top of the Mark y seguro que caerá más de una porción de tarta en el Cheesecake Factory de Union Square. Al fin y al cabo, las tradiciones están para respetarlas, ¿no? :P

BONILLA 3.0

Este año todo ha cambiado, TODO es diferente. Y no sólo hablo de la compra de SUN por parte de Oracle, sino de cambios a nivel personal y profesional que, en parte, han sido motivados o acelerados por mi visita a la última edición. Apenas me reconozco cuando pienso en el Bonilla que asistió a la edición del año pasado.

Hace un año, este blog no existia. Hace un año, no conocía a toda la gente interesante que me ha enriquecido en los últimos 365 días. Hace un año, ni siquiera estaba viviendo con mi novia, que en menos de 3 meses se convertirá en mi mujer. Hace  un año, no tenía cuenta en Twitter. Hace un año, España ni siquiera soñaba con ser campeona del mundo. Hace un año, no era ágil. Pero, sobre todo, hace un año, no tenía tan claro como ahora qué es lo que quiero hacer y cómo lo quiero hacer.

La asistencia a la javaOne del año pasado consiguió que me enamorara definitivamente de mi profesión. Que me diera cuenta de que las cosas que no me gustaban de ella no tenían que ver con LO QUE hacía sino con CÓMO lo hacía. Hace un año, vi que había otro modo de hacer las cosas y que te podías ganar muy bien la vida haciéndolas.

Al acudir a la javaOne, pude conocer a gente que estaba a años luz de mi círculo de influencia, como Kohsuke Kawaguchi o Vinicius Senger, tuve la posibilidad de acercarme a tecnologías y proyectos antes de que se difundieran en España y demostrarme a mí mismo que puedo defenderme con mi inglés en Estados Unidos, Albacete o Sebastopol.

Hace algunos años, perdí 25 kg y cambié de estilo de vida. Mis amigos se sorprendieron tanto que bromeaban llamándome “David 2.0“. Durante este año, creo que he cambiado tanto que he pasado a la siguiente release y puedo considerarme “Bonilla 3.0“.

No, no me he vuelto loco. No creo que la javaOne me haya cambiado la vida pero, sí estoy seguro de que sirvió como trigger para ayudarme a reconocer qué es lo que quería hacer con mi trabajo y mi profesión y comenzara a dar los pasos necesarios para lograrlo.

CONCLUSIONES

Un año más, debo agradecer la confianza y soporte de Sixservix que me va a permitir asistir a la conferencía. Además, Jeroclo, Erick y un servidor viajamos a la conferencia con entradas gratuitas de bloggers por deferencia de Oracle en general y su Directora de Comunicación para España y Portugal en particular, Mildred Laya, que nos ha hecho sentirnos “importantes” aunque sepamos que no lo somos.

Al que sea mal pensado y crea que nos hemos vendido a Oracle, decirle que no sabe de lo que habla. Yo no podría venderme jamás a Oracle. Todo el mundo sabe que Microsoft paga mucho más.

Al que haya llegado hasta aquí y vaya a ir a la javaOne, animarle a que se ponga en contacto conmigo a través del formulario de contacto de este blog. Cuantos más seamos, mejor, más ruido haremos y mejor nos lo pasaremos.

Si, por el contrario, aún no tienes entrada, te recuerdo que el periodo de early bird o precio reducido ha sido prorrogado hasta el 30 de julio. Aún estás a tiempo de animarte y venirte a San Francisco. Te costará bastate menos que cualquier curso de formación de alto nivel de una semana que puedas tomar en España.

En cualquier caso, y como a veces pido a los amigos, difundid la palabra de Bo: retwittead, reenviad o mandad por correo este artículo. Que no haya ni un sólo hispanohablante que vaya a la javaOne y no se una a nuestra Spanish Armada. Este año, vamos a por todas y aquí te lo contaremos.

Artículos relacionados:

1. Mi agenda para la javaOne 2010 Esta es mi agenda preliminar para la edición 2010 de...
2. ¿Habrá JavaOne en 2010? Uno de los principales damnificados de la fusión entre Oracle...

Todo esta introducción, sólo es una excusa para presentaros el mejor vídeo sobre java que se ha hecho nunca. Cuando digo nunca es NUNCA. Simplemente, IMPRESCINDIBLE. Disfrutadlo…

Pinche aquí para ver el vídeo

Es el impresionante trailer que ha creado la gente de JavaZone, una conferencia de desarrolladores celebrada en Escandinavia con más de 2300 entradas vendidas.

Dedicado a la gente de AltNetHispano -que tan bien lo están haciendo- en general y a Amalia Hernandez en particular.

(Visto en Meneame, donde los comentarios demuestran que, desgraciadamente, aún hay gente que cree que hay lenguajes buenos y malos, no buenos o malos programadores…)

PEDAZO DE DISCLAIMER:

Este vídeo me llegó el fin de semana pasada e inmediatamente redacté este post como boniartículo humorístico para el siguiente viernes. Cuando vi que ya lo habían publicado en su cuenta de twitter gente como Dani Latorre, Erick Camacho o Sergi Almar también lo hice en la mía pero, mantuve la publicación del artículo para el siguiente viernes.

Después vi que el vídeo había corrido como la espuma por Internet y que hasta Abraham había hecho referencia al mismo en javaHispano. Aún así, lo mantuve. Primero porque soy un cabezón :) y, segundo, porque quiero creer -ayudado por las estadísticas de Google Analytics- que no todo el mundo que me lee viene de jH  (“sólo” un 14,16%…).

Hoy, al repasar el artículo por última vez, me he alegrado profundamente de haber esperado hasta el viernes para publicarlo porque, lo que se dice modula completamente el “polémico” artículo del miércoles y me ha animado a escribir este disclaimer.

Aún así, puede haber algún bocachancla que diga que este artículo es oportunista y se ha escrito posteriormente. Lo estoy esperando. Menos mal que el bendito sistema de gestión de Wordpress guarda un histórico de cambios con hora y fecha…

Un saludo a todos y que viva .NET, Java, Ruby y Fortran. Como he dicho muchas veces, tenemos la profesión más bonita del mundo. Da igual el lenguaje que utilicemos…

PS: Una última mención de agradecimiento a Jorge Rubira que encontró una versión alternativa del vídeo después de que lo hubieran retirado de YouTube.

He de reconocer que, hasta hace poco, era un relativo fanboy de java pero, cada día soy más agnóstico respecto al lenguaje y me interesa más el producto; lo que, traducido a cristiano, significa que me da igual como esté hecho algo, lo importante es las funcionalidades que implemente y, por supuesto, que esté bien hecho.

Y en este estado de las cosas, ha caído en mis manos una maravillosa presentación de Jeffrey Zhao titulada “Porque Java apesta y C# mola”. El texto es imprescindible, lo mires por donde lo mires. No sólo porque supone una comparativa técnica y científica que rebosa calidad por todos los lados, sino porque detrás de un título de apariencia troll, se esconde una reflexión realista y desapasionada en la que no se aprecia fanatismo alguno.

Pero lo más importante de todo es que Jeffrey Zhao SE MOJA. Es de agradecer que alguien tome posición, la argumente y sea lo suficientemente valiente como para hacerla pública y, a lo torero, pedir réplica a la misma con la frase “contacta conmigo, muéstrame tu idea… y pruébala” proporcionando su blog, correo y cuenta de twitter. Ahí es nada.

Por si fuera poco, las diapositivas están salpicadas de frases memorables y un fino humor que es difícil de encontrar en un texto técnico. Me ha encantado la reflexión “si la JVM es la máquina, los byte codes son el código máquina y programar en Java… es como programar en ensamblador ¿De verdad quieres programar en ensamblador?”. Sencillamente, brillante.

El texto finaliza con una reflexión: ni siquiera nos pide que cambiemos de plataforma, entendiendo como plataforma la JVM, sino que pregunta ¿Por qué no utilizar otros lenguajes más poderosos a nivel de sintaxis y que se pueden utilizar dentro de la JVM como Scala, Ruby (JRuby) o Python (Jhyton)?

Qué grande es Jeffrey Zhao y qué grande es esta presentación. Tengo el orgullo de presentárosla aquí:

La conclusión a la que llego después de haber leído la presentación es que Jeffrey, como tantos otros, no nos está pidiendo a los que venimos del mundo Java que abandonemos la JVM ni la potencia de todo el mundo de librerías que hay detrás de ella, sino que probemos otros lenguajes que se pueden ejecutar en la misma.

¿Realmente merece la pena hacerlo cuando desgraciadamente hay un alto porcentaje de programadores a los que les suena a chino la mayoría de las cosas de las que habla Jeffrey? Bueno… depende. Si formas parte de una maligna megacorporación, puede que no, pero, si eres miembro de un pequeño y altamente productivo equipo de desarrollo…, a lo mejor el hecho de utilizar un lenguaje donde poder ordenar un array pasando la lógica de ordenación como parámetro, en vez de implementando una clase Comparator, marca la diferencia.

Voy a echarle un vistazo a Scala…

Artículos relacionados:

1. Gestión de memoria en Java Hace poco me llegó un correo de un compañero del...

Mientras que en la primera entrega dejamos configurado el servidor y en la segunda configuramos el proyecto en Netbeans, en esta estudiaremos directamente el código que nos permitirá trabajar con transacciones y bloqueos.

Nuestro proyecto web va a ser más simple que el asa de un cubo. Constará de un servlet escrito “a pelo Capello” denominado RenombraServlet, un EJB Stateless llamado ActualizaCliente , dos EJBs de sesión tan míseros que no merecen ni ser mencionados, aunque nos ayudaran a probar como conseguir transacciones y bloqueos pesimistas, y optimistas con EJB3.1; y, por último, dos EJBs de entidad – Customer y Order- que facilitan el mapeo entre la base de datos y nuestra aplicación.

¿Qué hace nuestra aplicación? Sencillo. Cuando se invoque el servlet se buscará al cliente con ID = 1. Si no existe, nos crearemos un cliente llamado “José María Arranz”, si existe, lo renombraremos dos veces por código aunque podremos comprobar que, en el mejor de los casos, sólo se modificará el nombre del cliente una única vez.

Una vez descritos de forma genérica la aplicación y su funcionamiento, os presentaré las clases una a una y, finalmente, os explicaré cómo se consiguen transacciones y bloqueos con las mismas.

1. EL SERVLET Y EL EJB RENOMBRADOR

La clase RenombraServlet.java es el punto de acceso de la aplicación. Por obra y gracia de la especificación 3.0 de servlets se autoconfigura con una ruta de acceso /RenombraServlet, así que ya sabéis, para acceder a la aplicación vía el servletcito:  http://tuhost:tupuerto/tucontexto/RenombraServlet

Una cosa importante a tener en cuenta es que se puede invocar al método con un parámetro opcional lock que te permitirá hacer renombrados con distintos bloqueos y que os explicaré más adelante.

Así, por ejemplo, si invocáis al servlet con el parámetro lock con valor 1 (http://tuhost:tupuerto/tucontexto/RenombraServlet?lock=1), estaréis renombrando al cliente “José María Arranz” con un bloqueo pesimista con un NOWAIT como una casa de grande.

Básicamente, es un servlet corriente y moliente que escribe HTML directamente en  la HttpServletResponse para ir mostrando los resultados del renombrado o de los errores del mismo por navegador y facilitar la comprobación  del correcto funcionamiento de la aplicación.

Llama a un EJB llamado Renombrador.java que es una clase absurda. lamentable y claramente prescindible pero, que he creado para que veáis que un EJB puede ser cualquier cosa a la que le claves la anotación correspondiente. Renombrador se limitará a devolver un nuevo nombre para el cliente que estará compuesto con los milisegundos de la fecha del sistema (sí, lo di todo por destacar al menos en originalidad).

Una vez que haya obtenido el nuevo nombre para el cliente, se invocará el método renombra del EJB ActualizaCliente.java que, sorprenderos, actualizará el nombre del cliente.

package com.six.test;

import java.io.IOException;
import java.io.PrintWriter;
import javax.ejb.EJB;
import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

/**
 * Servlet de todo a 100 que sirve como ruinosa fachada para nuestros EJBs
 * @author McGyver
 */
@WebServlet(name = "RenombraServlet", urlPatterns = {"/RenombraServlet"})
public class RenombraServlet extends HttpServlet {

    @EJB
    private Renombrador bean;
    @EJB
    private ActualizaCliente session;

    /** 
     * Procesa peticiones HTTP de tipo <code>GET</code> y <code>POST</code>.
     * @param request Servlet request
     * @param response Servlet response
     * @throws ServletException si existe algún error en el funcionamiento del Servlet
     * @throws IOException si existe algún error de escritura/lectura
     */
    protected void processRequest(HttpServletRequest request, HttpServletResponse response)
            throws ServletException, IOException {
        response.setContentType("text/html;charset=UTF-8");
        PrintWriter out = response.getWriter();
        try {
            String nuevo_nombre = bean.renombra();
            
            // Este operador ternario esta dedicado, con amor, a Xavi Gost (@XaV1uzz)
            int tipoBloqueo =
                    esUnNumero(request.getParameter("lock")) ?
                        Integer.parseInt(request.getParameter("lock")) : 0;

            out.println("<html>");
            out.println("<head>");
            out.println("<title>Renombrando a un Cliente</title>");
            out.println("</head>");
            out.println("<body>");
            out.println("<h1>Servlet " + request.getContextPath() + "/RenombraServlet - " + nuevo_nombre + "</h1>");
            out.println("<br/>");
            try {
                session.renombra(nuevo_nombre, tipoBloqueo);
                out.println("<p>Renombrado correcto</p>");
            } catch (Throwable e) {
                out.println("<p>Upps !!!: " + e + "</p>");
                out.println("<p>");
                e.printStackTrace(out);
                out.println("</p>");
            }
            out.println("</body>");
            out.println("</html>");

        } finally {
            out.close();
        }
    }

    /**
     * Metodo estupido que he creado para no tener que importar ni una
     * libreria de Commons de Apache. Reinventing the rueda !!!
     * @param texto la cadena de texto de la que queremos averiguar si es un número
     * @return true si el texto expresa un número
     */
    private boolean esUnNumero(String texto) {
        boolean respuesta = false;
        try {
            if (texto != null) {
                Integer.parseInt(texto);
                respuesta = true;
            }

        } catch (NumberFormatException ex) {
            // Este catch vacio se vende como espacio patrocinado
            // Anunciante, si quiere exponer sus productos aquí
            // contacte con david@sixservix.com
        }
        return respuesta;
    }

    // <editor-fold defaultstate="collapsed" desc="HttpServlet methods. Click on the + sign on the left to edit the code.">
    /** 
     * Handles the HTTP <code>GET</code> method.
     * @param request servlet request
     * @param response servlet response
     * @throws ServletException if a servlet-specific error occurs
     * @throws IOException if an I/O error occurs
     */
    @Override
    protected void doGet(HttpServletRequest request, HttpServletResponse response)
            throws ServletException, IOException {
        processRequest(request, response);
    }

    /** 
     * Handles the HTTP <code>POST</code> method.
     * @param request servlet request
     * @param response servlet response
     * @throws ServletException if a servlet-specific error occurs
     * @throws IOException if an I/O error occurs
     */
    @Override
    protected void doPost(HttpServletRequest request, HttpServletResponse response)
            throws ServletException, IOException {
        processRequest(request, response);
    }

    /** 
     * Returns a short description of the servlet.
     * @return a String containing servlet description
     */
    @Override
    public String getServletInfo() {
        return "Short description";
    }// </editor-fold>
}

El sofisticadísimo renombrador:

package com.six.test;

import javax.ejb.Stateless;

/**
 * Esta clase es tan tonta que me da verguenza
 * @author david
 */
@Stateless
public class Renombrador {
    public String renombra(){
        return "Nuevo nombre del Cliente: " + System.currentTimeMillis();
    }
}

2. EL EJB ACTUALIZADOR: BLOQUEOS

El EJB ActualizaCliente.java contiene todo lo que necesitáis saber para crear bloqueos optimistas, pesimistas con NOWAIT y pesimistas con un WAIT determinado.

El método principal es renombra(String nombre, int tipoBloqueo) y, a partir de ahí, podéis ver todo el proceso.

Lo primero que se hace en el método es invocar al método secundario getQuery(int tipoBloqueo) que devolverá una Query con el tipo de bloqueo seleccionado:

• Si habéis invocado a RenombraServlet.java sin parámetros o con el parámetro lock con valor 0, estaréis creando una Query con bloqueos optimistas (te deja consultar una tupla de una tabla de base de datos y sólo te provocará error si actualizas esa tupla después de que haya sido actualizada previamente por otra transacción entre el momento en el que consultaste la tupla y actualizaste -error en em.flush()-)
• Si habéis invocado a RenombraServlet.java con el parámetro lock con valor 1, estaréis creando una Query con bloqueos pesimistas NO WAIT o “sin espera” (sólo permite que una transacción consulte una tupla determinada de una tabla de base de datos y lanzará error si intentas consultar la misma tupla antes de que acabe la primera transacción -error en q.getSingleResult()-)
• Si habéis invocado a RenombraServlet.java con el parámetro lock con valor 2, estaréis creando una Query con bloqueos pesimistas WAIT o “con espera” (sólo permite que una transacción consulte una tupla determinada de una tabla de base de datos y lanzará error si intentas consultar la misma tupla antes de que acabe la primera transacción y en  n segundos no finaliza la misma -error en q.getSingleResult()-). En esta aplicación, la espera o WAIT está configurada para durar dos segundos.

Podéis probar los bloqueos depurando la aplicación y accediendo a la misma desde dos navegadores. Si ponéis un punto de interrupción justo en la línea donde se invoca q.getSingleResult(), con un primer hilo invocáis el método y pausáis la aplicación, cuando hagáis lo mismo con el segundo hilo veréis como la aplicación lanza un error si habéis utilizado un bloqueo pesimista -inmediatamente si es de tipo NOWAIT y después de n segundos en el caso del WAIT- y como continúa en el caso de que utilicéis los bloqueos optimistas.

Poned otro punto de interrupción en la línea em.flush(), veréis que el hilo de bloqueo pesimista que consiga llegar hasta dicho punto lo superará sin problemas. Por el contrario, en el caso de los bloqueos optimistas, el primer hilo que invoque el método, persistirá sin problemas y el segundo lanzará un OptimisticLockException que os dejará sentados en la silla con cara de asno esloveno.

package com.six.test;

import javax.persistence.EntityManager;
import javax.persistence.Query;

import com.six.model.entity.*;
import javax.ejb.EJB;
import javax.ejb.Stateless;
import javax.ejb.TransactionAttribute;
import javax.ejb.TransactionAttributeType;
import javax.persistence.NoResultException;
import javax.persistence.PersistenceContext;
import org.eclipse.persistence.config.PessimisticLock;
import org.eclipse.persistence.config.QueryHints;

/**
 * @author Spiderman
 */
@Stateless
@TransactionAttribute(TransactionAttributeType.REQUIRED)
public class ActualizaCliente {
    
    private static final int CUSTOMER_ID = 1;
    private static final int SECONDS_WAIT = 2;
    
    @PersistenceContext
    private EntityManager em;

    @EJB
    private NOActualizaCliente sc2;

    public ActualizaCliente() {        
    }

    public void renombra(String nombre, int tipoBloqueo) throws Throwable {
        

        try {
            Query q = getQuery(tipoBloqueo);
            Customer c = (Customer) q.getSingleResult();
            System.out.println("El nombre del Cliente es: " + c.getName());

            if (c == null) {
                // Crea un nuevo Cliente
                Customer customer0 = new Customer();
                customer0.setId(CUSTOMER_ID);
                customer0.setName("Jose María Arranz");

                // Persiste el cliente
                em.persist(customer0);

                // Crea 2 nuevas ordenes
                Order order1 = new Order();
                order1.setId(100);
                order1.setAddress("C/ACDC 14. Leganes, España");

                Order order2 = new Order();
                order2.setId(200);
                order2.setAddress("129 James Gosling Ave. San Francisco, USA");


                /**
                 * Asociación de las ordenes con el cliente. La asociación
                 * debe estar configurada en ambos lados de la relación: en
                 * la parte del Cliente para que las ordenes se persistan
                 * cuando la transaccion se comitee, y en el lado de las
                 * ordenes para configurar la relación.
                 */
                customer0.getOrders().add(order1);
                order1.setCustomer(customer0);

                customer0.getOrders().add(order2);
                order2.setCustomer(customer0);
            } else {
                sc2.renombra(c);
                c.setName(nombre);
                em.flush();
                System.out.println("El nombre del Cliente es: " + c.getName());
            }

        } catch (Throwable e) {
            System.out.println("ERROR: " + e.getMessage());
            throw e;
        }

    }

    private Query getQuery(int tipoBloqueo) {
        
        // Por defecto, se utiliza el bloqueo optimista.
        // Si se actualiza despues de otra actualización OptimisticLock Exception
        Query q = em.createNamedQuery("Customer.findById");
        q.setParameter("id", CUSTOMER_ID);
        switch(tipoBloqueo) {
            case 1:
                // Bloqueo pesimista con no wait
                q.setHint(QueryHints.PESSIMISTIC_LOCK, PessimisticLock.LockNoWait);
                System.out.println("Bloqueos Pesimistas con NOWAIT !!!");
                break;
            case 2:
                 //Bloqueo pesimista con wait de 2 segundos
                q.setHint(QueryHints.PESSIMISTIC_LOCK, PessimisticLock.Lock);
                q.setHint(QueryHints.JDBC_TIMEOUT, SECONDS_WAIT);
                System.out.println("Bloqueos Pesimistas con WAIT de " + SECONDS_WAIT + " segundos !!!");
                break;
            default:
                System.out.println("Bloqueos Optimistas !!!");
                break;
        }               
        return q;
    }

    private Customer findCustomer(Integer id) {
        Customer customer = null;
        Query q = em.createQuery("select c from Customer c where c.id = :id");
        q.setParameter("id", id);
        try {
            customer = (Customer) q.getSingleResult();
        } catch (NoResultException e) {
        }
        System.out.println(customer == null ? "Customer nulo " : "Customer " + customer.getName());
        return customer;

    }

}

3. EL EJB NO ACTUALIZADOR: TRANSACCIONES

Si con la clase ActualizaCliente.java hemos aprendido como se utilizan bloqueos de todo tipo con EJB3.1 y el comportamiento de cada uno de los mismos, con el EJB NOActualizaCliente.java comprenderemos cómo se manejan transacciones a través de invocaciones e invocaciones de EJBs.

Los EJBs nos proporcionan una transaccionalidad inmediata en cada uno de sus métodos, sin embargo, puede que tengamos lógica de negocio que necesite ser invocada con transaccionalidad dispersada por varias clases y métodos. ¿Cómo podemos conservar nuestras preciosas transacciones ACID a través de toda la maraña de invocaciones?

La sencillez de gestión de transacciones con JPA es inversamente proporcional a la corrección con que la gente las utiliza.

La clase NOActualizaCliente.java se llama así porque realmente jamás actualizará la base de datos. ¿Por qué, si se modifica un objeto mapeado directamente con una tupla en una tabla, y se persiste mediante em.persist() y em.flush()? Pues muy sencillo: por la configuración de transacciones dentro de la clase.

Si os fijáis bien, la clase se declara con una configuración global de transacciones:

@TransactionAttribute(TransactionAttributeType.REQUIRED)

Esta configuración se aplica a TODOS los métodos de la clase y, básicamente implica dos cosas:

• Si el método se invoca dentro de una transacción, se utiliza dicha transacción
• Si el método no se invoca dentro de una transacción, se crea una que se cerrará con la finalización del mismo

Sin embargo, puede que queramos que nuestro método tenga una configuración de transaccionalidad especifica y diferente del resto de los métodos de la clase ¿Cómo podemos conseguirlo? Proporcionando dicha configuración especifica mediante la misma anotación, pero a nivel de método:

 @TransactionAttribute(TransactionAttributeType.MANDATORY)

La configuración de transaccionalidad MANDATORY es ligeramente distinta a la de REQUIRED porque esta configuración implica que el método debe ser invocado dentro de una transacción y, si no es así, se lanza un error.  Si intentaramos invocar este método directamente desde nuestro Servlet, el error que obtendrías sería de proporciones bíblicas.

¿Quiere decir esto que no podremos invocarlo jamás desde un servlet? Pues… no. Podemos crear transacciones de forma manual, aunque seguro, seguro, seguro que el contenedor las gestiona mejor que nosotros… o al menos que yo.

Al utilizar la configuración MANDATORY me he asegurado que la lógica de este método siempre sea invocada dentro de una transacción. Como el método renombra() de NOActualizaCliente.java se invoca desde el método renombra() de la clase ActualizaCliente.java e, inmediatamente después, se vuelve a actualizar desde ese método el objeto actualizado por el primero, la actualización de la clase NOActualizaCliente.java jamás se hará efectiva en la base de datos.

¿Por qué? Porque estamos dentro de una transacción y, hasta que la misma no finalice, no se harán efectivos ninguno de los cambios realizados a nivel de código. La finalización del método renombra() de NOActualizaCliente.java no implica la finalización de ninguna transacción y, por tanto, no implica persistencia de los datos.

package com.six.test;

import javax.persistence.EntityManager;

import com.six.model.entity.*;
import javax.ejb.Stateless;
import javax.ejb.TransactionAttribute;
import javax.ejb.TransactionAttributeType;
import javax.persistence.PersistenceContext;


/**
 * @author Hulk
 */
@Stateless
@TransactionAttribute(TransactionAttributeType.REQUIRED)
public class NOActualizaCliente {
    
    @PersistenceContext
    private EntityManager em;

    public NOActualizaCliente() {        
    }

    /**
     * Este método sirve para comprobar que las transacciones 
     * funcionan con llamadas a varios métodos puesto que hasta que el método
     * que la invoca no hace el flush, los cambios no llegan a Base de Datos
     * @param c un Cliente de toda la vida
     */
    @TransactionAttribute(TransactionAttributeType.MANDATORY)
    public void renombra(Customer c) {

        try {
            c.setName("Esto JAMÁS deberia ir a base de datos");
            em.persist(c);
            em.flush();
            System.out.println("El nombre del Cliente es: " + c.getName());
        } catch (Throwable e) {
            System.out.println("ERROR: " + e.getMessage());
        }

    }
 
}

Para finalizar, os copio los EJBs de tipo Entity que soportan el mapeo entre los objetos de la aplicación y la base de datos.

Customer:

package com.six.model.entity;

import java.io.Serializable;
import javax.persistence.*;
import static javax.persistence.CascadeType.*;

import java.util.Collection;
import java.util.ArrayList;


@Entity
@NamedQueries({
    @NamedQuery(name = "Customer.findById", query = "SELECT u FROM Customer u WHERE u.id = :id")})
public class Customer implements Serializable {

    private int id;
    private String name;
    private Collection<Order> orders = new ArrayList<Order>();
    private int version;

    @Id
    public int getId() {
        return id;
    }

    public void setId(int id) {
        this.id = id;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    @OneToMany(cascade=ALL, mappedBy="customer")
    public Collection<Order> getOrders() {
        return orders;
    }

    public void setOrders(Collection<Order> newValue) {
        this.orders = newValue;
    }

    @Version
    public int getVersion() {
        return version;
    }

    public void setVersion(int version) {
        this.version = version;
    }

}

Order:

package com.six.model.entity;

import javax.persistence.*;

@Entity
@Table(name="ORDER_TABLE")
public class Order {

    private int id;
    private String address;
    private Customer customer;

    @Id
    @Column(name="ORDER_ID")
    public int getId() {
        return id;
    }

    public void setId(int id) {
        this.id = id;
    }

    @Column(name="SHIPPING_ADDRESS")
    public String getAddress() {
        return address;
    }

    public void setAddress(String address) {
        this.address = address;
    }

    @ManyToOne()
    @JoinColumn(name="CUSTOMER_ID")
    public Customer getCustomer() {
        return customer;
    }

    public void setCustomer(Customer customer) {
        this.customer = customer;
    }
}

Espero que después de este tutorial de todo a cien, al menos tengáis claro que SE PUEDEN conseguir bloqueos de todo tipo y transacciones ACID con EJB3.1 y JPA2 (recordar, JPA1 sólo soportaba las optimistas). Ahora tenéis el poder suficiente para hacer lo que os dé la gana con vuestras transacciones y bloqueos; y, como decía el filósofo más importante del siglo XX, el Tío Ben de Peter Parker/Spiderman “un gran poder implica una gran responsabilidad”. Espero que todo esto os sea útil y os haya ahorrado algunas horas de I+D.

Peter, no la cagues con las transacciones…

Pinche aquí para ver el vídeo

DISCLAIMER:

• Ningún gatito resultó herido en la realización de este tutorial
• Debo agradecer a Alberto Peña (aka @plagelao) el conocimiento, uso y disfrute de los Gist de de GitHub con los que se comparte el código de este ejemplo.
• Si quieres el código de esta aplicación y todos sus ficheros de configuración, mándame un correo y por un módico precio llegaremos a un acuerdo. Si lo pides por favor, puede que te salga gratis (gracias a Sixservix)

Artículos relacionados:

1. Arquitectura de logging en Glassfish Aprende como funciona el sistema de registro o logging en...
2. Transacciones y bloqueos en Glassfish v3 con EJB3.1 y JPA2 (II) Segunda parte del tutorial sobre como utilizar transacciones y bloqueos...
3. Transacciones y bloqueos en Glassfish v3 con EJB3.1 y JPA2 (I) Un sencillo tutorial sobre como utilizar transacciones y bloqueos con...

Continuo con mi proyecto de mega-artículo-tutorial-taladro sobre transacciones y bloqueos con JPA2 y EJB 3.1 en Glassfish v3.

En el artículo anterior, aprendimos a configurar base de datos y servidor para poder llevar a cabo este tutorial. En esta nueva entrega, aprenderemos a configurar nuestra aplicación para que pueda trabajar con estas tecnologías.

3. CREANDO NUESTRO PROYECTO EN EL IDE

Yo he utilizado Netbeans 6.8 como IDE para crear este ejemplo. No porque crea que sea el mejor entorno de trabajo, ni porque sea un fan de los productos de Oracle/SUN, sino porque es el que mejor integración nativa trae de serie con Glassfish v3. Bajo mi modesta experiencia -y llevo unos cuantos años en esto- el Servidor de Aplicaciones elegido puede condicionar totalmente vuestra arquitectura; y la integración, gestión y depuración del mismo, la elección de un IDE u otro. Podéis seguir este tutorial aunque utilicéis otro IDE, sólo tenéis que adaptar lo que se vaya haciendo a las peculiaridades de vuestro entorno de trabajo.

Para crear nuestro proyecto utilizaremos el wizard que se lanza desde la siguiente ruta de menú:

File >> New Project >> Java Web >> Web Application.

Se desplegará una primera interfaz donde se indicará el nombre del proyecto:

Interfaz de creación de proyecto (pulsa sobre la imagen para verla grandota)

La siguiente interfaz sirve para especificar el servidor con el que trabajará el proyecto, la versión de java utilizada y el contexto web que lo lanzará. Si sois unos vagos -como yo- habréis utilizado el Glassfish v3 que instala NetBeans para configurarlo como explique en el anterior artículo. Si, por el contrario, os dado por innovar, coleccionais todas las versiones del servidor o, en definitiva, os gusta hacer las cosas bien, puede que tengáis que añadir otro contexto de servidor mediante el botón “Add”. Aquí tenéis mi configuración:

Configurando sel servidor, versión de java y contexto

La siguiente y última interfaz nos interrogará para saber si queremos incluir algún framework de trabajo como, por ejemplo, JSF en nuestro proyecto. Le diremos que “de momento, no gracias“. Bastante tenemos con nuestras transacciones (vamos por dos artículos… y lo que nos queda).

Una vez apretemos el botón de ‘Finish‘ habremos creado un esqueleto de proyecto donde se incluyen las librerías del JDK 1.6, de Glassfih v3 y, para pruebas, JUnit y el contexto embebido de Glassfsh.

4. CREANDO UNA UNIDAD DE PERSISTENCIA

Creado el proyecto, aparecerá en el explorador de la izquierda del interfaz un icono muy pituco que representa una bola del mundo (o algo así). Si pulsáis sobre el mismo con el botón derecho del ratón y seguís la siguiente ruta de menú New >> Persistence Unit, accederéis a un nuevo mundo de poder y sabiduría… y al wizard de creación de unidades de persistencia.

El wizard de creación de Unidades de Persistencia

Aquí tenemos que pararnos durante un rato y explicar que es cada cosa y porque se elige una opción u otra. Al menos, si queremos enterarnos minimamente de que es cada cosa en vez de seguir el tutorial cual robots.

¿Sabemos lo que es una Unidad de Persistencia? Si, la respuesta es “si”, podéis pasar al siguiente párrafo. En caso contrario, os diré que el concepto de unidad de persistencia o persistence unit fue introducido por JPA1 y sirve para definir el conjunto de clases de entidad -que representan entidades de una base de datos- que serán gestionadas por nuestro contexto de persistencia o, lo que es lo mismo, los polvos mágicos que conseguirán que, al crear un objeto de tipo com.six.Boniato y persistirlo, se cree un nuevo registro en la tabla Boniato de nuestra Base de Datos. Además, contiene un  conjunto de metadatos que configuran el trabajo con dichos datos. Esos metadatos pueden incluir desde el nivel de traza con el que deseamos tracear el trabajo del motor de persistencia hasta los datos necesarios para crear una conexión directa a la base de datos y hacer que nuestra aplicación no dependa del registro de un datasource en el servidor de aplicaciones.

Las unidades de persistencia y sus atributos se definen en el fichero persistence.xml. Puede que hayais oído que este fichero se coloca en el directorio /META-INF de nuestra aplicación. Bueno, pues si pero no. No está de más leernos lo que nos dice la propia SUN sobre el tema. Son cuatro reglas, pero nos puede evitar numerosas y crípticas com.boni.CascotazoException con trazas similares al comportamiento de Matrix.

Lo primero que pide el wizard es un nombre con el que identificar a nuestra unidad de persistencia. Si sólo tenemos configurada una única unidad de persistencia, se seleccionará la misma como unidad por defecto. Si tenemos más de una -por ejemplo, una para desarrollo y otro para pruebas en un entorno de integración- podremos utilizar una u otra identificándolas a partir de su nombre.

Lo siguiente que pide el wizard es el proveedor de persistencia o Persistence Provider. Básicamente, la implementación de la API de JPA que deseamos utilizar. NetBeans incluye varias implementaciones pero, si queréis utilizar JPA2, la única opción que podéis elegir es EclipseLink.

El tercer dato que pide el wizard es la fuente de datos o Data Source con el que va a trabajar la Unidad de Persistencia. Podéis dejar vacío este campo y crear la unidad de persistencia sin Data Source asociado pero yo no os lo recomiendo. Eso obligaría a registrar en el fichero persistence.xml todas las propiedades -especificas para cada proveedor de persistencia- necesarias para crear localmente el Data Source y, lo que es peor, el tipo de transacciones siempre debería ser RESOURCE_LOCAL, no JTA. ¿Es eso malo? No tiene porque serlo, pero ¿por que restringir vuestra libertad de opción?.

Si aún así, queréis hacerlo, aquí tenéis dos buenos ejemplos de como hacerlo.

En el caso de que me hagáis caso y decidáis utilizar un Data Source, recordad que vais a desarrollar una aplicación para desplegar en el Glassfish v3 que configurasteis en el artículo anterior. El Data Source de JPA se corresponde con el Recurso JDBC de Glassfish. Yo configuré mi recurso con el nombre global JNDI jdbc/states, así que este es el nombre con el que voy a registrar mi Data Source en mi unidad de persistencia. Cuando despliegue la aplicación en Glassfish, el acceso a datos estará configurado automáticamente.

También podéis recrear el Data Source en NetBeans ¿Para qué? Para poder crear clases de entidad a partir de tablas, mediante wizards del IDE; validar que vuestro modelo se ajuste a vuestras clases, etc. Tener el Data Source de vuestro servidor de aplicaciones configurado en el IDE es guayabero, guayabero y, encima, bastante sencillo de implementar hasta bajo nivel, la conexión física. Os dejo una ruta gráfica:

Como configurar un Data Source en NetBeans

Una vez creado (o no) el Data Source de la Unidad de Persistencia, encontramos en el wizard un checkbox que permite indicar si se desea trabajar con o sin JTA, o lo que es lo mismo, si queremos que el contenedor gestione las transacciones por nosotros o queremos meter mano y configurarlas a pelo Capello. La elección es vuestra pero, personalmente, me fio bastante mas del contenedor que de mi mismo. De hecho, me fio bastante mas de que el Atleti gane 10 años seguidos la Champions League de que yo no me deje alguna transaccion abierta donde no deba.

La gestión local de transacciones sólo se recomienda en casos muy específicos, donde se desea tener control de transaccionalidad intra-método de EJB.

Dependiendo de vuestra elección, se creará un jta-data-source, para trabajar con Data Sources gestionados con JTA, o un  non-jta-data-source, para los Data Sources que no trabajen con JTA.

La última opción que presenta el wizard es la estrategia de creación de tablas. Dependiendo de la estrategia seleccionada, el IDE intentará o no crear las tablas en vuestra base de datos si no las encuentra.

Finalmente, la configuración de mi wizard queda tal que así:

El New Persistence Unit wizard

Una vez creada la Unidad de Persistencia, estamos preparados para crear código con JPA2, JTA, transacciones, bloqueos y hasta tirabuzones triples… pero eso lo veremos en la siguiente entrega.

De nuevo, nos hemos ido hasta cerca de las 1500 palabras, sobrepasando con mucho el máximo deseable para un artículo en un blog. Así pues, os emplazo a una tercera y espero que definitiva entrega… si aún os siguen quedando ganas de trabajar con EJB3.1 y JPA2 :)

DISCLAIMER

No tengo mucho feedback sobre esta serie de artículos, exceptuando las del ya mítico Dr. Arranz y mis secuaces tuiteros. Una sensación de tostón técnico invade todo mi ser, así que, si tienes algún consejo o sugerencia para mejorar la tercera entrega, no dudes en hacérmelo saber.

Artículos relacionados:

1. Arquitectura de logging en Glassfish Aprende como funciona el sistema de registro o logging en...
2. Transacciones y bloqueos en Glassfish v3 con EJB3.1 y JPA2 (III) Tercera parte del tutorial sobre como utilizar transacciones y bloqueos...
3. Transacciones y bloqueos en Glassfish v3 con EJB3.1 y JPA2 (I) Un sencillo tutorial sobre como utilizar transacciones y bloqueos con...

No me gusta tener que partir los artículos pero, la verdad es que está quedando francamente largo y corría el riesgo de convertirse en un ladrillo infumable.

La teoría dice que el código proporcionado en este tutorial debería funcionar en cualquier servidor de aplicaciones compatible con Java EE6 y con cualquier implementación de JPA2, pero la teoría también decía que en Irak había armas de destrucción masiva… y aún las están buscando.

Glassfish v3 y Netbeans 6.8 -el IDE mejor integrado con este servidor de aplicaciones- tienen soporte nativo de EclipseLink, la implementación de referencia de JPA2 y vástago hipermineralizado y supervitaminado de Oracle Toplink.

Hay otras implementaciones de JPA2, como la de Hibernate 3.5 -lanzada el 31 de marzo de este año- o la de openJPA 2 -lanzada el 22 de abril-, pero como habéis podido comprobar son versiones muy recientes, no maduras y que pueden funcionar como los pimientos de Padrón: a veces si y a veces non.

1. CREANDO NUESTRA BASE DE DATOS DE PRUEBAS

Lo primero que debemos hacer es montar una pequeña base de datos con la que trabajará nuestro prototipo. Vamos a crear una típica estructura cabecera-lineas, donde un cliente puede tener de 0 a n pedidos asociados, teniendo en cuenta que un pedido puede crearse sin asociar a ningún cliente:

¿Que porqué le he puesto esos nombroncios a las tablas? Pues porque así los debí encontrar en alguno de las decenas de ejemplos que he visto para destilar este tutorial y así se quedaron.

En cualquier caso, en este enlace tenéis el script SQL necesario para crear las tablas, tal y como yo las he creado. He generado el script haciendo ingeniera inversa con nuestra base de datos -una vez más, vaguería pura- pero debe funcionar as-is, o con pequeños cambios, en cualquier base de datos.

2. INSTALANDO Y CONFIGURANDO GLASSFISH

No voy a perder ni un instante en explicaros como instalar Glassfish. Primero, porque es más sencillo que el asa de un cubo y, segundo; porque si yo he sido capaz de leer y comprender este pequeño ladrillete de 32 páginas, cualquiera podéis hacerlo.

Una vez instalado el Glassfish v3 y creada nuestra base de datos, tenemos que configurar un Data Source o fuente de datos que nos permita acceder y modificar la estructura creada en el punto anterior, siguiendo los siguientes pasos:

• Cargar la librería JDBC de acceso a nuestra base de datos en el classpath de Glassfish: Para hacerlo, debemos copiar el jar de la librería en la siguiente ruta /instalación de glassfish/domains/dominio que vayamos a utilizar (normalmente, domain1)/lib. En mi caso en concreto, con Glassfish instalado en Windows, la ruta es “c:\Archivos de programa\sges-v3\glassfish\domains\domain1\lib\” y ahi he copiado la librería JDBC especifica para bases de datos Oracle:  ojdbc14_g.jar.
• Crear un nuevo conjunto de conexiones o Connection Pool en el servidor: a través de la dirección http://localhost:4848 podréis acceder a la consola de administración de Glassfish. Si navegáis por el árbol de opciones hasta Recursos >> JDBC >> Conjunto de Conexiones, veréis algunos creados por defecto en el servidor y podréis crear uno mediante el botón ‘Nuevo’. Al crear un nuevo conjunto de conexiones, nos preguntará por la Base de Datos con la que vamos a trabajar, básicamente, para que no tengamos que configurar a manubrio la clase de implementación de la interfaz java.sql.Driver. También nos pedirá que indiquemos el tipo de recurso JDBC que deseamos crear. En el segundo paso de la creación, se indica la configuración propiamente dicha, desde el número de conexiones a el host, usuario y password de la base de datos en si. Pero lo realmente importante, es la configuración de la transaccionalidad del DataSource. Para no eternizarnos explicando parámetro a parámetro lo que hay que poner, os pongo una copia de mi DataSource, configurada para una base de datos Oracle, que está en un host denominado NEDWARD (por NED FLANDERS)

Pulsa sobre la imagen para verla grandota

Pulsa en la imagen para que se vea grandota

• Por último, tendréis que crear un Recurso JDBC que no es, ni mas ni menos, que un envoltorio que pondrá Glassfish sobre vuestro conjunto de conexiones y al que daréis un nombre JNDI con el que lo identificareis en vuestras aplicaciones. Os muestro, de nuevo, mi interfaz de configuración, donde he creado un Recurso JDBC con el nombre JNDI jdbc/states.

Pulsa en la imagen para que se vea grande como Australia

Con esto hemos acabado toda la configuración de Glassfish que necesitamos para ejecutar este ejemplo. A partir de ahora, es cuando viene el caviar… :)

Permaneced atentos a la segunda parte del artículo.

Artículos relacionados:

1. Arquitectura de logging en Glassfish Aprende como funciona el sistema de registro o logging en...
2. Transacciones y bloqueos en Glassfish v3 con EJB3.1 y JPA2 (III) Tercera parte del tutorial sobre como utilizar transacciones y bloqueos...
3. Transacciones y bloqueos en Glassfish v3 con EJB3.1 y JPA2 (II) Segunda parte del tutorial sobre como utilizar transacciones y bloqueos...

Gosling se une a una larga y creciente lista de notables ex-empleados de SUN, que han renunciado a su puesto desde que Oracle la comprara en enero y que incluye a personalidades como el CEO Jhonathan Schwartz; el co-inventor del lenguaje XML, Tim Bray; el creador de Hudson, Kohsuke Kawaguchi; o el responsable de open source, Simon Phipps.

La marcha de Gosling y sus compañeros supone un duro golpe para la comunidad de desarrollo que ha crecido alrededor del lenguaje java, aunque técnicos como Jerónimo López crean que “para el sector, todo esto que está pasando es positivo. El panorama se llenará de nuevas empresas repletas de gente con muchas ideas, que podrán desarrollar/explorar con aún más libertad que cuando estaban en SUN. Seguro que muchas de esas ideas impulsarán/crearán áreas nuevas“.

Además, aunque algunos crean que los resultados de Oracle y sus ventas no se verán afectadas por la marcha de Gosling, como Abraham Otero que comenta en javaHispano “… las ‘empresas serias’ ni sabían quién era el ‘hippie’ ese  de Gosling…“, la pregunta que debemos hacernos todos y, especialmente, los accionistas de Oracle es: ¿vale más o menos Oracle sin todos estos técnicos dentro de ella? Si la valoración de una empresa se basa no sólo en sus activos financieros sino en su posibilidad de generar beneficios en un futuro, ¿se verá penalizada la valoración de Oracle en bolsa? ¿Se reducirá su capacidad de desarrollar nuevos productos y tecnologías?

Aunque no suelo ser un buen oráculo, pronostiqué deserciones masivas de técnicos en antiguos artículos y en el podcast de javaHispano donde comentamos la compra de SUN por parte de Oracle. SUN ya no es la compañía que atraía y contrataba a los mejores técnicos.

¿A dónde llevará todo esto? Nadie puede pronosticarlo, pero sí podemos asegurar que el panorama de java y su ecosistema va a cambiar radicalmente.

Artículos relacionados:

1. Compartiendo mesa y mantel con Oracle Ayer acudí a un encuentro de bloggers organizado por Oracle...

Si eres un desarrollador y piensas “A mí plin Paquirrín. Eso no tiene nada que ver conmigo“, disculpa si te lo digo con crudeza: eres un looser. Saca durante un instante la cabeza de Hibernate y Spring porque te están impidiendo ver el sol :).

Twitter no es sólo una página güel, no es sólo un “Facebook pero en pequeño” ni la última tontuna de los modernos de turno. Twitter es una plataforma y, como tal, debes aprender a desarrollar para ella. Porque nunca sabes cuándo te puede venir bien utilizarla y porque, créeme, a tus clientes les puede parecer más o menos interesante que utilices Toplink, Hibernate o SQL con escoplo y martillo, pero es probable que alguno te pida algo para Twitter. ¿Quieres quedar como un zocolotroco desfasado o como un gurú del Interné? Invertir 5 minutos en la lectura de este articulo separa una cosa de la otra.

¿UNA PLATAFORMA?

Si amigo, Twitter  es una plataforma. Y ¿por qué es una plataforma? Porque te proporciona una completa API REST para que utilices todos los servicios que ofrece desde tu propia aplicación de una forma sencilla y gratuita.

Ésta es la clave del éxito de páginas como Twitter o Facebook, su espíritu de auténticas plataformas donde terceros desarrollen sus propias aplicaciones.

Sí, twitter es una plataforma, pero NO de este tipo...

Sí, Facebook está muy bien, pero ¿alguien puede imaginárselo sin los cientos de juegos del tipo “¿Quien es el más listo de tus amigos?” o “El Granjero que llevas dentro”? ¿Y sin las miles de aplicaciones para enviar osos amorosos o bocatas de calamares a tus amigos? La genialidad de Twitter y Facebook es conseguir que terceros desarrollen, sin coste alguno para ellos, y hagan crecer y enriquezcan la plataforma. ¿Que esos terceros también se lucran? “Genial”, piensan ellos, así ganamos todos.

Por poneros un ejemplo de lo que NO es una plataforma, tenemos a nuestro propio clon local y reggaetonero de Facebook: el Tuenti. No hay un enlace a “Desarrolladores” o a “API” en la web de Tuenti. Ellos se lo guisan y ellos se lo comen. Vale, veremos como les va, pero, de momento, van cuesta abajo y sin frenos.

VALE ¿CÓMO EMPEZAMOS?

Lo primero que tienes que hacer es dar de alta una cuenta en Twitter. ¿Por qué? Porque con esa cuenta podrás registrar tus aplicaciones. Necesitamos registrar las aplicaciones en Twitter para utilizar OAuth como medio de autenticación.

La verdad, podríamos pasar del OAuth para hacer nuestra primera aplicación, pero ya que nos ponemos a juguetear con Twitter, mejor aún si aprendemos algo nuevo y ¡Carambolas! ¡El OAUth mola! :)

Key y Secret de Oauth que se obtiene al registrar la aplicación

Hablar de OAuth no es el objetivo de este post, pero lo describiré de un modo breve. Básicamente, el método de autenticación OAuth se basa en que, el usuario no se autentica en tu web mediante usuario y contraseña sino que lo hace en la plataforma que gestione la autenticación (por ejemplo, Twitter) y ésta te da un token de autenticación que es el que tu guardas y utilizas para comunicarte en el futuro con dicha plataforma.

Evidentemente, ese token vale para y SÓLO para tu aplicación. Ahí está el truco. Y, para que la plataforma sepa qué aplicación es la que está requiriendo autenticación, te proporciona unas claves que tú envías cuando haces las llamadas de validación de claves. Twitter, al registrar una aplicación, te da las claves necesarias para  trabajar con OAuth desde tu aplicación.

Ah, una última cosa: como desarrolladores, Twitter nos asigna una serie de cuotas para el uso de sus servicios (recordemos, gratuitos). En concreto, 150 llamadas a la API por hora y por IP/Cuenta de Usuario.

Si nos hemos emocionado con todo esto de las plataformas y tenemos pensado desarrollar La Madre de todas las Aplicaciones de Twitter, podemos solicitar en este enlace que nos amplíen la cuota hasta 10.000 llamadas a la hora, pero, de momento, no creo que sea necesario.

Ahora sí, tenemos todo lo que hay que tener para empezar a desarrollar nuestra primera aplicación para Twitter.

MANOS A LA OBRA

Como hemos comentado antes, la API para trabajar con Twitter es una API REST. Si no sabes lo que es REST, aquí tienes un excelente artículo :P sobre el tema, pero, en cualquier caso, no te preocupes. No te hace falta saber absolutamente nada de REST porque utilizaremos uno de los envoltorios Java que ya están creados. Si eres capaz de invocar un System.out.println(), serás capaz de trabajar con esta API.

En la propia página de librerías Twitter tienes un montón de frameworks ordenados por lenguaje. Voy a centrarme en las opciones que hay para Java, el lenguaje que utilizo y amo, y dentro de éstas, en Twitter4j. Más que nada, porque es la que mejor diseño y documentación tiene.

Vamos a ir describiendo, paso por paso, cómo crear nuestra aplicación java/twitter:

1. Descargamos la librería de la web de Twitter4j. En un fichero zip, encontraremos tanto la librería en sí como el resto de librerías que necesita para funcionar y, si lo preferimos, un fichero pom de Maven con todas las dependencias.
2. Instalamos el conjunto de librerías, tanto Twitter4j como aquellas de las que depende, haciéndolas accesibles a nuestro classpath
3. Nos crearemos la clase BoniTwitterTest donde copiaremos el siguiente código:

[java autolinks="false" classname="BoniTwitterTest" collapse="true" firstline="1" gutter="true" htmlscript="false" light="false" padlinenumbers="false" smarttabs="true" tabsize="4" toolbar="true"]

import twitter4j.Twitter;
import twitter4j.TwitterException;
import twitter4j.Status;
import twitter4j.http.RequestToken;
import twitter4j.http.AccessToken;

import java.io.BufferedReader;
import java.io.InputStreamReader;
import java.util.Hashtable;

public class BoniTwitterTest {

private static Hashtable<String, AccessToken> almacen = new Hashtable<String, AccessToken>();

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

BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
while (true) {
Twitter twitter = getTwitter();
System.out.println("Introduzca su nombre de usuario:");
String usuario = br.readLine();
AccessToken accessToken = almacen.get(usuario);
while (accessToken == null) {
RequestToken requestToken = twitter.getOAuthRequestToken();
System.out.println("Visita la siguiente página web y autoriza el acceso a tu cuenta:");
System.out.println(requestToken.getAuthorizationURL());
System.out.print("Una vez visitada, introduce el PIN y pulsa enter:");
String pin = br.readLine();
try {
if (pin.length() > 0) {
accessToken = twitter.getOAuthAccessToken(requestToken, pin);
} else {
accessToken = requestToken.getAccessToken();
}
// Se guarda el token de autenticación para utilizar en un futuro
storeAccessToken(usuario, accessToken);
} catch (TwitterException te) {
if (401 == te.getStatusCode()) {
System.out.println("No ha sido posible obtener el token de autentiación");
} else {
te.printStackTrace();
}
twitter = getTwitter();
}
} // FIN del bucle WHILE que asegura la autenticación
twitter.setOAuthAccessToken(accessToken);
System.out.println("Introduzca su nuevo estado de Twitter o NADA si desea salir y pulse ENTER:");
String status = br.readLine();
if (status == null || status.length() == 0) {
System.out.println("Gracias por usar la aplicación. Adios !!!");
System.exit(0);
} else {
Status tstatus = twitter.updateStatus(status);
System.out.println("Se ha actualizado con exito el estado a [" + tstatus.getText() + "]");
}

} // FIN del bucle WHILE principal de la aplicación

}

/**
* Este metodo nos devolvera una instancia del objeto Twitter con la OAuyth Key y el OAuth Secret configurados
* @return una instancia del objeto Twitter
*/
private static Twitter getTwitter() {
Twitter twitter = new Twitter();
twitter.setOAuthConsumer("OAuth Key", "OAuth Secret");
return twitter;
}

/**
* Guarda el token de autenticación de un usuario en una Hashtable
* @param usuario el ID de usuario que servira como clave de guardado
* @param at el token de autenticación
*/
private static void storeAccessToken(String usuario, AccessToken at) {
System.out.println("USUARIO TWITTER " + usuario);
System.out.println("TOKEN " + at.getToken());
System.out.println("TOKEN SECRET " + at.getTokenSecret());
almacen.put(usuario, at);
}

}[/java]

4. Tenéis que sustituir las cadenas de texto  ‘OAuth Key‘ y ‘OAuth Secret‘ por las claves que os haya proporcionado Twitter al registrar vuestra aplicación.
5. ¿Que qué hace este código? Pues, básicamente, comprobar si tenéis el token de validación de un usuario en el sistema y, si no lo tenéis, pediros que visitéis una web para obtener un código o PIN de autorización que demuestre que el usuario ha autorizado a tu aplicación a acceder a la API de Twitter en su nombre.
   

   Ésta es la web en la que el usuario autoriza o no a tu aplicación para trabajar en tu nombre en Twitter

   

   Éste es el PIN que te proporciona Twitter para que introduzcas en tu aplicación

6. Una vez que introduces el PIN, obtienes el token de autenticación y ya puedes solicitar los servicios de Twitter en nombre del usuario autenticado.
7. Nuestra pequeña aplicación, se limitará a solicitarnos el status con el que queremos actualizar la cuenta de Twitter del usuario autenticado.
8. Si actualizamos el status con la frase ‘Actualizando el Estado de Twitter desde mi propia aplicación Java‘ podremos comprobar como en la cuenta de Twitter del usuario -en este caso, yo- el estado se ha modificado:
   

   Fijaos en que pone que el estado se ha modificado desde 'Prueba David' el nombre de mi aplicación registrada

Si accedéis a la API de Twitter desde una aplicación web, podréis redirigir el flujo de la aplicación a la página de autenticación y configurar dicha página para que invoque una de vuestras páginas mediante callback. Mola ¿verdad? Se autentican en Twitter y continúan en tu aplicación proporcionándote el PIN de autenticación de paso.

Evidentemente esta aplicación es una chorrez como un piano, pero es un ejemplo claro y sencillo sobre cómo registrar una aplicación en Twitter, cómo autenticar a un usuario mediante OAuth y cómo manejar su pool de servicios en nombre de ese usuario. A partir de aquí, enriquecer y hacer crecer esta mini aplicación, depende de vosotros. Seguro que se os ocurren un montón de ideas, simplemente estudiando las posibilidades de la API, pero os voy a proponer algo: ¿No creéis que sería interesante para un departamento de marketing una aplicación que buscara menciones de los productos de una compañía en los tweets de la gente y que guardara los IDs de la gente para, posteriormente mandarles tweets de respuesta con ofertas o comunicados? Yo, al menos, conozco a más de un gurú del marketing muuuy interesado :)

Espero que este humilde tutorial os haya servido de ayuda y os anime a crear la nueva killer application de esa pequeña gran plataforma llamada Twitter.

Algunos links de interés

API REST DE TWITTER: http://apiwiki.twitter.com/Twitter-API-Documentation

API JAVA TWITTER4J: http://yusuke.homeip.net/twitter4j/en/javadoc/index.html

Tradicionalmente, la javaOne ha sido la plataforma principal de SUN para difundir y expandir el lenguaje java y sus tecnologías asociadas. Sin embargo, la incertidumbre en la que están envueltos todos los proyectos y actividades de la compañía de Santa Clara desde que comenzó el proceso de adquisición por parte de Oracle, también ha atrapado a la conferencia, que tiene un incierto futuro. Por eso, muchos se preguntan: “¿Habrá una javaOne este año?“.

Poco o nada se sabe de la javaOne de 2010, pero, la semana pasada, confeccionando un calendario de eventos para la planificación del próximo año,  conseguí encontrar algo de información.

En la web del Moscone Center, el centro de conferencias de San Francisco donde se celebra la javaOne, aparece listado como evento confirmado del 22 al 25 de junio de 2010. Además, sigue existiendo una web no oficial donde, aquellos que deseen postularse como ponentes pueden mandar sus presentaciones técnicas. En esta web, las fechas que se ofrecen son del 21 al 24 de junio.

¿Significa esto que se confirma la celebración de la javaOne? Pues… NO. El Moscone Center debe reservarse con hasta 18 meses de antelación. Lo único que demuestra todo esto es que, hoy por hoy, SUN no ha cancelado la conferencia.

Con los chicos de Nosys, en la calle Lombard, el último día en San Francisco

En la web hay opiniones para todos los gustos: algunos creen que la javaOne va a seguir, otros piensan que se fusionará con el evento Oracle Open World y, los más pesimistas, temen que desaparezca.

Del mismo modo, la javaOne tiene detractores y partidarios. Entre los primeros, se encuentran todos aquellos que creen que una conferencia off-line de esa magnitud es un anacronismo en la actualidad, cuando toda la información está disponible en la red. Entre los segundos, me encuentro yo mismo, que puedo aportar mi experiencia como asistente en la pasada edición.

Efectivamente, aunque la teoría dice que nada o poco se puede aprender que no se encuentre ya en la red, la realidad es muy distinta. La javaOne es una oportunidad magnífica para tomarte un descanso de tu día a día y dedicarte en exclusiva, durante una semana, a aprender, renovar tus conocimientos y empaparte del mundo java.

Además, la javaOne te permite conocer en persona a muchos de los miembros de la comunidad java que habitualmente  sigues o lees. Puedes leer páginas y páginas sobre closures en java, pero no es comparable al placer de hacerlo rodeado de colegas, tomando unas cervezas en el Oso Sediento a los pies del Moscone Center. La javaOne es algo diferente.

Si alguno tiene pensado asistir a la edición del próximo año, podéis poneros en contacto conmigo a través de este formulario. A ver si, entre todos, conseguimos arrebatar a los brasileños el título de nacionalidad latina más organizada… y ruidosa :)

Si el año pasado, la experiencia fue increíble, no me puedo ni imaginar como sería teniendo cerca a gente como Rubirator, el Profesor Arranz, Jeroclo el espartano, Beto Vilches y tantos otros…

Artículos relacionados:

1. Mi agenda para la javaOne 2010 Esta es mi agenda preliminar para la edición 2010 de...
2. javaOne 2010 David Bonilla se va de vacaciones pagadas a San Francisco...

Madre mía… madre mía ¿Pero qué es eso de closures? Aunque los chicos de Groovy y Ruby que están en la onda y dominan el flow saben de que va el tema, a los arcaicos programadores-integristas de java, seguidores -como yo- de la Iglesia de San James Gosling de los Últimos Días, nos debería sonar a chino mandarino. En cualquier caso, debe de ser algo im-por-tan-tí-si-mo porque tiene a toda la comunidad revolucionada y hace que el mismísimo Abraham Otero de jH publique la noticia con nada menos que tres admiraciones !!! Habrá que investigarlo.

Pues bien, las closures son, ni más ni menos, que bloques de código que, una vez definidos, puedes asignar a una  o más variables y ejecutar posteriormente. Por supuesto, estos bloques pueden recibir parámetros.

Antes de nada, hay que reconocer que la frase anterior es bastante densa, así que vamos a parar un momento para ver un código de ejemplo que nos ayude a comprenderla. De todos los ejemplos del mundo mundial de la vida vital que he podido encontrar en la red sobre closures, este pedazo de javascript me parece el más sencillo y aclaratorio:

function localise(greeting) {

return function(name) { alert(greeting + ‘ ‘ + name };

}

var english = localise(‘Hello’);

var french = localise(‘Bonjour’);

english(‘kartik’);                                 // alert box with “Hello kartik”

french(‘kartik’)                                   // alert box with “Bonjour kartik”

Se que más de uno estará pensando “¿y para qué quiero yo utilizar esta memez?” No os quedéis en la superficie, pensad en las posibilidades. Por ejemplo, utilizad esas variables que apuntan a bloques de código como parámetros de un segundo método.

login(name, password, english) // Devuelve un saludo en inglés si el usuario se autentica

Si alguno se ha quedado con cara de Bugs Bunny y farfullando un “¿esto es todo amigos?” que no se preocupe porque, realmente, esto es todo amigos. Ni el mundo se va acabar ni de repente se van a resolver de forma mágica todos vuestros problemas. Vuestro Jefe de Proyecto no va a estar más contento porque las utilicéis, vuestra empresa no os va a pagar más y, desde luego, no vais a tener más éxito con las mujeres, pero puede que os permitan desarrollar vuestro trabajo mejor y más rápido.

Las closures son una herramienta más, que le da más potencia al lenguaje. Ni más, ni menos.

¿Qué se os ocurren mil y una formas de hacer lo mismo con otras herramientas de java como las clases internas o las interfaces? Pues, también. Pero no hay que ser más papistas que el Papa. El propio Gosling escribió en su blog que java no es algo que deba permanecer inmutable sino un lenguaje vivo que va evolucionando y reconoce que las closures se quedaron fuera de las primeras versiones más por problemas de tiempos que por otra cosa.

Le podemos dar más vueltas y buscar una explicación más exhaustiva o hablar sobre la posibilidad de utilizar variables locales que toman valor en la definición de la closure y no en la ejecución, pero no es el objetivo de este artículo.

Por último, advertiros de que podéis sorprenderos con un batiburrillo de siglas asociadas a esto de las closures como BGGA o CICE. No os preocupéis, solo sirven para identificar las propuestas de implementación que ha hecho determinada gente. Así, por ejemplo, BGGA surge de los apellidos del grupo de amigos que se reúnen para tomar cervezas y hablar de closures (Gilad Bracha, Neal Gafter, James Gosling y Peter von der Ahé).

Las closures llegarán con java 7. Bienvenidas sean, las estamos esperando.

RECURSOS

Closures en Groovy: http://groovy.codehaus.org/Closures

Excelente articulo sobre el tema en Javaworld: http://bit.ly/29e6Ih

A James Gosling le gustan las closures: http://blogs.sun.com/jag/entry/closures

Otro sitio donde explican las closures de forma sencilla: http://bit.ly/1txbqG

Última Propuesta BGGA: http://www.javac.info/

Independientemente de las características de los dos productos, para mi es un ejemplo de comparativa perfecta: tabulada, clara, concisa, con anotaciones aclaratorias y un escueto resumen final, donde el autor “se moja” eligiendo una de las dos soluciones y razonando su elección. Impecable.

http://www.bigbeeconsultants.co.uk/cruise-control-vs-hudson

Otra comparativa muy buena, con una tabla no tan completa , pero… en español :)

http://xnoccio.com/372-conclusiones-finales-eligiendo-nuestro-entorno-de-integracion-continua-v/

]]> http://sixservix.com/blog/david/2009/11/19/cruisevshudson/feed/ 0 http://sixservix.com/blog/david/2009/09/30/explicando-rest-a-mam/ http://sixservix.com/blog/david/2009/09/30/explicando-rest-a-mam/#comments Wed, 30 Sep 2009 05:30:14 +0000 David Bonilla http://sixservix.com/blog/david/?p=186 Si mamá, desde hace ya un buen tiempo, cuando vienes a visitarme a casa, no paras de leer en la pantalla de mi ordenador, en los papeles que tengo por ahí sueltos,  eso de REST. Y como no acabas de creerte que el término no tiene nada que ver con colchones, voy a intentar explicártelo.

Puedes encontrar artículos en la web que describen REST en castellano de pe a pa, e incluso completísimos tutoriales sobre como montar tu primera aplicación REST con java, pero quizás todo sea demasiado teórico y complejo para alguien que, como tú, busca una primera aproximación y no tiene porqué tener necesariamente mucha idea de Web Services, SOA o HTTP. Voy a intentar explicártelo muy claro y con ejemplos, como a ti te gusta.

Tranquila mamá, no te sientas mal por no tener muy claro esos conceptos. Hay muchos arquitectos de software y desarrolladores que tampoco los tienen. A lo mejor a ellos también les interesaría escuchar todo esto que te cuento. Es fácil, creo que en menos de 5 minutos tú y ellos os habréis hecho con ello.

Lo primero que tienes que tener claro es que REST no es una tecnología sino una arquitectura. Para que lo entiendas, no es algo que solucione cosas sino una forma de diseñar algo que solucione cosas. ¿Y qué tiene de especial esta arquitectura para que todo el mundo hable de ella? Intentaré explicártelo.

1. Diseñas tu aplicación exponiendo recursos no funcionalidades. Sí, ya no programo páginas web que tengan direcciones como www.mipagina.com/crearCosa o www.mipagina.com/consultarCosa. Ahora sólo tengo www.mipagina.com/cosas o www.mipagina.com/cosas/12345/atributos. Sí te das cuenta, es como si tuviera mis recursos ordenados en directorios. Y sí, sé lo que te estás preguntando: si sólo hay un www.mipagina.com/cosas ¿cómo sé si mis usuarios intentan crear una cosa o simplemente consultarla? Ahora te explico, ten un poco de paciencia.
2. Utiliza los métodos del protocolo HTTP de manera explicita. HTTP es un protocolo de comunicación que hace que Internet funcione. ¿No te has dado cuenta de que cuando escribes una dirección en el navegador pone http:// por delante de la dirección? Bueno, pues eso es porque te estás comunicando mediante ese protocolo. Lo que no tanta gente sabe, incluidos muchos programadores, es que el protocolo HTTP tiene un montón de métodos definidos en su especificación: GET, POST, PUT, DELETE… y que cada uno de ellos tiene un propósito específico aunque, a veces, te reconozco que los desarrolladores nos lo saltamos a la torera.  No te suena de nada ¿verdad? Eso es porque la mayoría de los navegadores utilizan el método GET por defecto en las peticiones HTTP, excepto que le indiquemos especificamente otra cosa en nuestras páginas web. Así , cuando escribimos el nombre de una página en la barra de direcciones de un navegador, la invocamos con el método GET. ¿Que por qué te he soltado este ladrillo que no te interesa? Espera un poco, ya verás como todo empieza a encajar.
3. Mapea los métodos del protocolo HTTP a las operaciones a realizar sobre un recurso. Fíjate que bueno, si te conectas a un recurso -una página web, para que lo entiendas- invocando el método GET, por ejemplo, yo sé que es lo que quieres porque el método GET se utiliza para consultar un recurso. Del mismo modo, al resto de los métodos principales de HTTP se les mapea una operación específica. Así, POST se utiliza para crear un recurso, PUT para actualizarlo y DELETE para borrarlo, evidentemente. Si, por ejemplo, solicitas la página  www.mipagina.com/cosas con el parámetro id=2345 y el método GET, mi aplicación REST te devolverá la cosa con id=2345. Sin embargo, si repites la misma solicitud con el mismo parámetro pero con el método DELETE lo que  conseguirás es borrar la cosa con id=2345.  ¡Tacháaan! ¿A que ahora parece todo más claro?
4. Transfiere XML, JSON o XTHML. No te voy a calentar la cabeza mamá explicándote qué es cada cosa. Confía en mi. Basta con que sepas que son cosas que se pueden consumir e interpretar desde un navegador y convertir en una de esas bonitas páginas web que tanto te gustan. Sólo para que lo sepas, cuando te digo que te devuelve una cosa, me refiero a que te devuelve algo como esto:

<cosa>

    <id>2345</id>

    <nombre>cosa misteriosa</nombre>

</cosa>

Sé que tendrás algunas dudas. Creo que podré adivinar alguna de ellas :)

• ¿Cómo le indico eso del id? ¿Sólo puedo mandar un parámetro? Y lo de los métodos HTTP ¿Cómo se cambian? Bueno, a ver, el id es un parámetro que envías en tu petición. Y, claro, puedes mandar todos los que quieras. Si lo piensas bien, cuando rellenas un formulario en una página web no estás haciendo más que mandar un montón de parámetros -uno por cada campo del formulario- sin límite alguno. Usando REST no haces mas que navegar así que, SÍ, puedes enviar lo que quieras. Respecto a lo de cambiar el método HTTP a utilizar bueno… eso no es tan sencillo. No vas a poder hacerlo directamente desde tu navegador pero, los programadores de páginas HTML sí tienen la posibilidad de hacerlo. Si llegas a una página web diseñada para utilizar con una aplicación REST y, por ejemplo, ves un botón “Eliminar Cosa“, seguro que vas a hacer una petición con el método DELETE
• ¿Y si no le paso ningún parámetro? No pasa nada. Si, por ejemplo, haces una petición GET a www.mipagina.com/cosas sin pasar ningún parámetro, probablemente conseguirás que una aplicación REST te devuelva un montón de enlaces a todas las cosas que esten relacionadas con dicho recurso. Por ejemplo, una lista de cosas (www.mipagina.com/cosas/0001, www.mipagina.com/cosas/0002…). Si lo piensas bien todo lo que te devuelve son a su vez enlaces REST que puedes reutilizar haciendo nueva petición con el método que te interese contra dichos enlaces. ¡Genial! ¿Verdad?
• ¿Y todos los recursos implementan todos los métodos? Pues, realmente NO. De hecho, hay otro método de HTTP, OPTIONS, cuya finalidad es obtener una lista de los métodos soportados por un recurso. A lo mejor, el programador de una aplicación REST quiere permitirte consultar una determinado información pero no quiere que la actualices.
• Y entonces ¿cualquiera puede borrar cosas de tu aplicación? No. Puedes identificar a tus usuarios con los métodos de autenticación que te proporciona cualquier servidor HTTP o incluso utilizar cosas más sofisticadas.  No te preocupes, puedes conseguir que sólo acceda a tu aplicación REST quien tú quieras.

Como ya te he dicho REST sólo es una arquitectura, no una tecnología. Tienes que evaluar bien si te interesa o no utilizarla. Si te interesa conocer cuáles son algunas de sus ventajas, te explicaré alguna de las más importantes:

• El método HTTP GET y el cacheo. Muchos proxies y firewalls -ordenadores que gestionan una red- suelen cachear las peticiones GET. Que, ¿qué es eso de cachear? Pues guardarse una copia de la página que solicitas con tu método GET y, si otro ordenador de tu misma red solicita la misma página, devolver esa copia mucho más rápido que si tuviera que obtener la página de nuevo.
• No utiliza estado de sesión. A ver como te explico esto… ¿recuerdas cuando me pediste que te enseñara a comprar por Internet y estuvimos comprando libros? Esos libros se iban acumulando en un carrito de la compra y, al final, pagamos con tarjeta de crédito. Bueno, ese carrito de la compra existía porque la página web nos identificó durante toda nuestra sesión de trabajo y, es genial. Lo que pasa es que, al final, somos muchos los que compramos libros y eso puede acabar sobrecargando los servidores donde se alojan las páginas web. Cuando 5 están comprando libros no hay problema pero, cuando son 5000… la cosa cambia. El hecho de que REST no mantenga estado de sesión quiere decir que en nuestras peticiones de recursos y en las respuestas del servidor tiene que viajar toda la información necesaria. Nada se guarda en la memoria del servidor.
• Puedes distribuir una API completa de tu aplicación en un fichero de javascript. Mmmm… para que lo entiendas de una forma sencilla ¿conoces Facebook, no?. Bueno, pues lo bueno de  Facebook, lo que ha hecho que triunfe tanto es que ha posibilitado que terceros creen aplicaciones y las incrusten en la página. Casi todas esas aplicaciones te permiten interactuar con tus contactos de Facebook, pero dichas aplicaciones no tienen acceso directo a la BBDD de la página web, sino a una API, un conjunto de utilidades, que proporciona Facebook y que permiten acceder, por ejemplo, a los amigos del usuario que está ejecutando la aplicación. Créeme, eso es una aplicación REST como una casa. ¿Te imaginas que Facebook tuviera que distribuir por ahí la ruta de acceso a su BBDD? ¿Te imaginas los problemas de seguridad y escalabilidad que supondría?

En fin mamá, que REST está muy bien, pero es una manera más de solucionar las cosas, ni más ni menos. Por ejemplo, no tengo muy claro que fuera la arquitectura más adecuada para ese ejemplo que te he puesto del carrito de la compra, aunque sí para muchos otros supuestos.

La gente está muy ilusionada con el tema, sobre todo como una apuesta para conseguir de una manera sencilla, rápida y flexible la interoperabilidad entre distintas aplicaciones escritas en distintos lenguajes. Antes todo el mundo pensaba que los webservices eran el único medio válido para conseguir esto de una manera eficiente pero, ahora, hay bastante gente que lo pone en duda porque, la verdad, la especificación donde te explica cómo implementarte por entero un webservice, cómo publicarlo y cómo consumirlo es… un poco dura y pffff… ¡no creo que consiguiera explicártela en 5 minutos como he hecho con esto del REST! Y eso es lo bueno de esta arquitectura. Mamá, si tú has conseguido entenderlo, creo que cualquier desarrollador lo hará.

]]> http://sixservix.com/blog/david/2009/09/30/explicando-rest-a-mam/feed/ 4 http://sixservix.com/blog/david/2009/09/16/escuela-de-groovy/ http://sixservix.com/blog/david/2009/09/16/escuela-de-groovy/#comments Wed, 16 Sep 2009 14:42:10 +0000 David Bonilla http://sixservix.com/blog/david/?p=246 Hace unos días, durante una escala en el aeropuerto de Bangkok, tuve un interesante debate con Alberto Vilches sobre la adopción de groovy en el mundo del desarrollo de software corporativo en el que estoy inmerso. Al entusiasmo jedi de Alberto se contraponía mi escepticismo desde el punto de vista de la gestión, el lado oscuro de la fuerza. Nadie discute lo bueno de groovy ni todo lo que aporta pero ¿tiene cabida en proyectos de tamaño medio y grande? ¿De verdad Grails vale para algo más que hacer webs sencillitas del tipo “Recauchutados López”? ¿Hay una oferta suficiente de personal formado? ¿La libertad que da no puede implicar agujeros del tamaño de Oceanía en proyectos de 20 a 25 programadores con un índice de rotación alto? ¿Qué le aportará a mi equipo de desarrollo? ¿Cuál será el retorno de inversión que obtendré por formar a un técnico en este lenguaje en vez de certificarle en JBoss, por ejemplo? Nuestro avión llegó antes de que llegáramos a alguna conclusión.

Para obtener respuesta a todas estas preguntas nace Escuela de Groovy la iniciativa impulsada por Nacho Brito y Álvaro Sánchez-Mariscal para introducir groovy en el mundo empresarial. El próximo 25 de septiembre se celebrará su puesta de largo en La Catedral, el centro de Madrid on Rails.

Al frente de Salenda e ImaginaWorks, Álvaro y Nacho han sido unos de los máximos impulsores de groovy en España y han celebrado múltiples cursos y ponencias gratuitas con el ánimo de formar a la comunidad y extender el uso del lenguaje entre la comunidad de desarrolladores Java. Escuela de Groovy recoge estos esfuerzos y los potencia mediante servicios de evangelización, oficina técnica, desarrollo y formación a medida, con el objetivo de convertirse en el referente de groovy en este país.

Le deseo a Escuela de Groovy un futuro lleno de éxitos, no sólo por su apoyo a las metodologías ágiles y las tecnologías abiertas y por el trabajo de Álvaro y Nacho a lo largo de estos años sino, sobre todo, por el  esfuerzo, valor e iniciativa que supone emprender en estos tiempos (y en estos parajes).

Si deseas asistir a su presentación y aprender más sobre las posibilidades de groovy en el mundo de la empresa, puedes apuntarte aquí: