JProfiler

Esta nueva versión incluye:

1. Error en el cliente Java connection.setRequestProperty(“Content-Type”, “text/xml; charset=UTF-8″);
2. Reconexión a la BD cuando el servidor se cae y se vuelve a levantar

Estamos en el año 2003 y se están empezando a poner de moda los “servicios web”. Al fin y al cabo, los servicios Web son algo que ya estábamos haciendo nosotros desde que éramos capaces de serializar en XML. Javier F. Mejuto me enseñó un día una pequeña aplicación en Flash que se comunicaba con el servidor invocando “servicios”. Esto nos produjo una pequeña revolución interna: se acabaron las páginas JSP que van circulando parámetros entre cliente y servidor (el cual almacena el estado) y que complican enormemento el diseño y sobre todo la implementación de las aplicaciones Web. Es una época en que las aplicaciones Web dominan (no es posible ya volver a las aplicaciones de escritorio). Pero los profesionales del software seguimos empeñados en que la comunicación con el servidor no puede ser a través de cookies, paso de parámetros en la URL y otros malabares parecidos. La idea de hacer aplicaciones con Flash que invocan servicios es lo más parecido a una aplicación de escritorio, pero siendo también aplicación Web. Parece que se podían cumplir nuestros sueños.

No tuve que pensarlo mucho, además de modelar objetos y navegación, Frawa tenía que ser capaz de modelar servicios, más aún, servicios Web, o sea, operaciones que reciben como entrada un XML y dan como salida otro XML. Rápidamente definí un nuevo metamodelo para los servicios (tengo que reconocer que éste fue muy sencillo, ya que una operación sólo necesita definir los parámetros de entrada y los de salida, y para esto podía utilizar el modelo de objetos que ya tenía Frawa). Dicho y hecho, en poco tiempo Frawa era capaz de generar automáticamente un servlet que procesaba las operaciones de un servicio Web. En aquellos días, SOAP todavía no estaba muy extendido, así que decidí utilizar el protocolo XMLRPC, a sabiendas de que algún día futuro habría que cambiarlo. La primera demostración real de funcionamiento fue con un proyecto para Telefónica Soluciones. Tenían una empresa que les había hecho un sistema en Visual Basic para configurar ofertas y tenía que enviarnos esas ofertas a un sistema nuestro escrito en Java. La solución, muy sencilla, les damos un servicio Web, les indicamos el XML que nos tienen que enviar y listo. Y así, en pocos días conseguimos integrar dos aplicaciones que no tienen nada que ver. Y todo funcionó.

Con los servicios Web empecé a interesarme por la generación de código también para los clientes. O sea, lo que siempre se ha conocido como stubs, y que permite a las aplicaciones invocar servicios olvidándose de toda la problemática del middleware (XML, sockets, URLs, etc). Me decidí a generar automáticamente clases Java que permitían invocar los servicios Web como si fueran subrutinas normales, con unos parámetros de entrada y unos valores de retorno. Estos stubs permitían comunicar aplicaciones Web, invocándose unas a otras a través de los servicios.

Pero el gran reto estaba por llegar, había que conseguir hacer aplicaciones Web cuyos clientes invocaran servicios (lo que hoy conocemos todos como AJAX). El problema es que Javascript no estaba “muy preparado” para esto. Así que tomamos la decisión de generar stubs en Flash en el lenguaje ActionScript. Esto fue una revolución, un producto como Flash utilizado habitualmente para hacer presentaciones y películas, queríamos utilizarlo para hacer aplicaciones interactivas. Pero no es tan descabellado, ya que Flash incluye un conjunto de widgets de interfaz de usuario que permiten diseñar e implementar aplicaciones. Si además le unimos la capacidad de estas aplicaciones de invocar servicios, podemos desarrollar aplicaciones muy similares a las aplicaciones de escritorio, pero WEB !!! O sea, nada de instalar, nada de una plataforma y S.O. específico, actualizaciones on-line… Pues así Frawa permitió este tipo de aplicaciones (estamos a finales del año 2003). La puesta de largo de todo esto llegó cuando RRHH de la Corporación de Telefónica nos pidió un sistema para la gestión del talento. Nos arriesgamos y nos pusimos a implementarlo con Flash y con servicios Web. Nuestro jefe Manolo González fue el que más animó la decisión. Y todo salió bien…

A partir de aquí, Frawa se consolidó como un “producto” dentro de nuestra división en Telefónica I+D, y empezamos a utilizarlo en todos los sistemas.

La historia sigue…

La idea de Frawa surgió en el año 1997 tras una conversación entre José Antonio Quiles Follana (yo) y Mariano Rico Almodóvar. Fue entonces cuando se nos ocurrió la idea de generar código fuente basándonos en alguna descripción del mismo. Mariano me convenció de que se podían generar automáticamente ficheros C++ que correspondieran a una definición de datos.

Lo primero que hice fue un generador de clases de datos C++ que tuvieran una serie de atributos (definidos en un fichero de texto). La clase generada tenía los métodos get y set correspondientes, constructor de copia, etc. Esto nos ahorraba un esfuerzo considerable de codificación, pero sobre todo, uniformizaba los ficheros de código fuente. El fichero de definición de las clases era muy sencillo, en formato texto, donde se definía el nombre de la clase, cada uno de sus atributos y el tipo.

Cuando se me planteó el problema de enviar datos serializados entre dos máquinas, me dí cuenta de que era un problema farragoso con muchos chequeos y comprobaciones que hacían casi ilegible el código fuente. Era muy fácil equivocarse al codificar. Además, cuando había que modificar algún atributo de una clase, la modificación de las rutinas de serialización y deserialización se convertía en una tarea de chinos. Entonces ya lo tenía muy claro: el código de esas rutinas debe generarse automáticamente. Cogí el generador de clases que había hecho y le añadí la generación automática de dos rutinas, una para serializar y otra para deserializar. Fue entonces cuando me dí cuenta de la potencia de la herramienta que estaba desarrollando. Se acabaron los fallos de codificación en la serialización de datos, y cuando detectaba algún fallo, sólo tenía que cambiar el programa generador de código (que todavía no tenía nombre) y volver a generar para arreglar los fallos en todas las clases de forma casi instantánea.

En el año 1999 empezamos a utilizar Java en mi grupo de trabajo. Java ya incluía la serialización automática de sus objetos, con lo cual, abandoné momentáneamente mi “fabuloso” generador de código.

Sin embargo, en el año 2000 apareció un nuevo lenguaje: XML. Fue algo que a todos nos sorprendió por su versatilidad y a mí concretamente por el hecho de que venía con un parser genérico que me parseaba cualquier XML! Para mí, que nunca he entendido muy bien lex y yacc, esto era algo fabuloso. Tenía un lenguaje con el que podía modelar casi cualquier cosa, y parsearlo era inmediato. Se me ocurrió que estaría muy bien que los propios objetos Java supieran serializarse a XML (y deserializarse a partir de XML, claro). Pero esta labor no era nada sencilla, así que retomé mi antiguo generador automático de clases C++ y lo modifiqué para generar código Java incluyendo rutinas de serialización y deserialización XML. Muchos me preguntaban para qué serializar a XML si los objetos Java ya saben serializarse a otro formato. Yo lo tenía muy claro: la serialización Java es propia (no propietaria) de Java. O sea, sólo permite comunicar dos procesos Java. Pero, ¿y si quiero comunicar un proceso C++ con un proceso Java? Yo lo tenía muy claro: la solución es XML, que es muy sencillo de generar y parsear en cualquier lenguaje de programación.

Poco después, entré en el mundo de las aplicaciones Web con Java: los servlets, las páginas JSP… y sobre todo el “Model 2″ (página invoca acción con parámetros, acción ejecuta lógica de negocio, acción genera datos de salida, la página pinta los datos de salida, y así sucesivamente). Cuando ya habíamos desarrollado unas cuantas aplicaciones Web siguiendo el modelo 2, me dí cuenta de los problemas que surgían inevitablemente: casi toda la comunicación entre páginas y acciones se basaba en cadenas de caracteres, o sea, que el compilador no interviene para detectar si una página está invocando con los parámetros adecuados a una acción, o si una acción está pasando el tipo de datos adecuado a una página. Todo eso se convertía en un “infierno” en cuanto la aplicación pasaba de 20 ó 30 páginas. Y los quebraderos de cabeza que nos daba la modificación de algún parámetro de alguna página nunca se nos van a  olvidar…

Entonces se me volví a sacar del cajón el generador automático de código, pero ahora con una idea más ambiciosa (era el año 2003). Ya no sólo quería modelar simples objetos con atributos, sino una aplicación entera. Lo hablé con Mariano Rico y al final lo vimos viable. El primer problema que había que afrontar es el formato de los ficheros. Una aplicación ya no se podía modelar tan fácilmente con un simple fichero de texto. Entonces Pablo Peña me sugirió utilizar XML como formato de almacenamiento. La idea era genial, porque es un  formato eXtensible y porque no teníamos que sufrir más con el parseo del fichero (para mí esto era lo peor). Tras algunos días (y noches) dándole vueltas, se me ocurrió un meta-modelo relativamente sencillo: tenemos dos tipos de entidades, páginas y acciones. Cada acción recibe unos parámetros de entrada (en la URL) y cada página recibe unos datos para pintar (objetos Java). Además, una página puede invocar una o más acciones y cada acción puede redirigir a una o más páginas. Con este modelo, plasmado en XML, fuimos capaces de modelar (valga la redundancia) una aplicación Web. Y la verdad es que este meta-modelo no se ha modificado desde entonces…

El generador de código se reformó completamente, tomando como entrada un fichero XML con las entidades de la aplicación (aproveché también para modelar con XML los objetos). Se generaba un servlet que hacía las veces de controlador, chequeaba que cada acción recibía los parámetros adecuados (definidos en el modelo), que cada página recibía los datos necesarios para pintar. Cada día íbamos incorporando más y más funcionalidades (páginas JSP de prueba, chequeo de argumentos con javascript, etc…), sin tocar el modelo, sólo extrayendo más código fuente de este modelo.

Pablo Peña, un experimentado programador de interfaces de usuario con swing se ofreció para hacer un IDE que permitiera crear los ficheros XML sin tener que editarlos a mano (labor que en alguna ocasión daba lugar a errores). Fue la primera interfaz de usuario para nuestro generador de código. Teníamos que pensar un nombre para todo esto y se nos ocurrió “FRAmework for Web Applications”, o sea, FRAWA. En esto de poner nombres siempre fue muy ocurrente Mariano Rico.

Pero la historia no termina aquí, más bien comienza…

Seguiré contando esta historia en una segunda parte.

La última versión es la 1.2.43 

• Generación de código GWT para componentes de UI
•  Diseño de interfaz de usuario de los componentes (mediante árbol)
• WSDL con soporte para excepciones