La perspectiva a un año. El pasado sábado 3 de octubre de 2009, mientras nuestro país se debatía con los nuevos impuestos y medidas de recorte de gastos (como la dada a conocer una semana después de esta reunión, el presidente Calderón liquidaba a Luz y Fuerza del Centro), Juanito tomaba protesta dos días antes, Oracle seguía sin un claro pronunciamiento oficial sobre el futuro de MySQL, Debian estaba a punto de lanzar su GNU/kFreeBSD como “estable”, Microsoft empezaba a generar ruido con soporte de versiones 128-bit para Windows 8 (y dejándolo lo suficientemente ambiguo para que pensemos en procesadores más que en el sistema de archivos), los debates entorno a OpenID corrían en extremos insospechados (encabezando la paranoia dichos argumentos) y el mundo giraba, se llevó a cabo la novena reunión de la comunidad de SpringHispano.org, grails.org.mx y JavaMexico.org. ¿Por qué menciono esas noticias aledañas? Porque en esta ocasión, todo el ruido (ensordecedor) del mundo ajeno al silicio se quedó corto con la envergadura de las charlas de esta ocasión: "Patrones de Integración Empresariales con Apache Camel", conducida por Domingo Suárez Torres e "Introducción a Griffon", brindada por Andrés Almiray, ambas revolucionarias en sus respectivos ámbitos.

Afortunadamente para quienes siguen paso a paso estas reseñas, están disponibles videograbaciones de estas conferencias. Empero, la primera charla comenzó a ser grabada ya iniciada. La primera charla comenzó enlistando bibliografía alrededor del tema. El Ing. Suárez definió como objetivo el comprender los beneficios de usar patrones para integrar aplicaciones con Apache Camel.

Se señaló que en 1979, el Arq. Christopher Alexander escribió “The Timeless Way of Building”, libro que explicaba la idea de patrones en arquitectura. En frase de su autor: “Un patrón es un proceso mediante el cual el orden de una construcción o una ciudad directamente desde la naturaleza interior de la gente; un proceso el cual trae orden desde sí mismos; no puede adquirirse, pero sucede por sí misma, si sólo la dejáramos.” Hacia 1977 había publicado el mismo autor “A Pattern Language: Towns, Buildings, Construction (Center for Environmental Structure Series)”, donde enlistaba que cada problema que ocurría había sucedido infinidad de veces y que casi siempre se solucionaba de igual manera, es decir, que podían obtenerse patrones de ellos. Estos dos libros se complementan con un tercero, “Notes on the Synthesis of Form” (1964), con las que se encamina el autor hacia una teoría de diseño, según la forma que se adapte al contexto de necesidades humanas y demandas. Muestra con estos libros que tal proceso adaptativo será exitoso sólo si procede de procesos divididos, atomizados y entendidos individualmente, en lugar de todo en una vez. Hacia 1987, Kent Beck, de Apple, y Ward Cunningham, de Tektronik, publican “Using Pattern Languages for Object-Oriented Programs”, en esta ocasión, completamente encaminado hacia las ciencias de la computación, y para 1994, “Design patterns” de Erich Gamma, Richard Helm, Ralph Johnson y John M. Vlissides, donde en una estructura muy simple se explican los patrones de diseño.

En contextos más específicos, los patrones de integración empresarial se aplican a diferentes plataformas. Las necesidades de integración son muy diversas, desde aplicaciones heredadas (legacy), variedad de plataformas y tecnologías, carencia de estándares bien definidos (cada profeedor incorporando su tecnología propia), aplicaciones de terceros ya implementadas (por ejemplo, de COI, la aplicación de contabilidad, a RP), e-Goverment o aplicaciones gubernamentales, sociedades comerciales o “biz 2 biz”, etcétera.

Las aplicaciones de integración son necesarias como puente entre aplicaciones distintas, traducen y adaptan tipos de datos, se encargan del medio de transporte así como del protocolo entre aplicaciones y agrega funcionalidades.

Por supuesto, en materia de integración existen alternativas propietarias, que dicho sea de paso, son de costo muy, muy alto, y al final quien lo implementa se debe enfrentar a la documentación, en mayor o menor grado amigable (dejémoslo así), así como algunas otras opciones libres, entre ellas: Apache ServiceMix (de la cual Camel es integrante), OpenESB, Mule o Fuse.

En cualquiera de los casos, partiendo de la premisa anteriormente expuesta, donde todos los problemas ya han sido resueltos, debe tenerse en cuenta que todos los patrones están construidos en diversos productos, sean propietarios o abiertos. En otras palabras, es necesario documentarse sobre dichos patrones, y esa fue la parte medular de esta exposición.

La recomendación del Ing. Suárez fue el libro “Enterprise Integation Patterns: Designing, Building, and Deploying Messaging Solutions” (2004), parte de la serie Addisson Wesley Signature, de Gregor Hohpe y Bobby Woolf. Este libro aborda tanto programación en Java como en .Net con referentcias para diseñar y construir aplicaciones de integración. Este volumen recopila 65 patrones, planteando a la mensajería asíncrona como piedra angular para la integración.

¿Por qué la mensajería? Porque permite la comunicación hacia aplicaciones de manera asíncrona, haciendo la información como un intercambio de mensajes sobre canales, canales que lo hacen confiable y durable, permitiéndose operaciones sin conexión, mejorando el uso de hilos y de manera transaccional, sin perder mensajes.

Este libro define una nomenclatura para identificar cada patrón para hacer diagramas complejos. El Ing. Suárez enumeró varios ejemplos y plantillas. Las ventajas de implementarlo es que las aplicaciones son sumamente escalables y desacoplables, facilitando las pruebas unitarias (unit testing), empero, como contras tiene la latencia contra el rendimiento (throughput), que deben hacerse pruebas de integración, que el desacoplamiento no siempre es lo más adecuado (puede perderse visión del proyecto, por eso es tan recomendable el uso de diagramas).

De lleno en el tema, Apache Camel implementa una gran cantidad de Patrones de Integración Emprsarial (EIP, por sus siglas en inglés), haciendo mención que los no implementados aún son expansiones que pueden descomponerse. La licencia Apache 2.0 ha resultado muy conveniente para las empresas, puede implementarse en un lenguaje de dominio específico sin mayor problema, compatible con XML (Spring o Google), hace DSL con Scala y, obviamente, es compatible con groovy.

¿Qué es lo que hace tan poderoso a Apache Camel? Que usa URIs para la integración, mediante el término de Endpoint, como llama a la entidad de software que responde a una dirección (por ejemplo www.serv.com:80). Entre los tipos de Endpoint, el Server Socket o el Client Socket, Web Socket, incluso un POJO. Esta abstracción es precisamente lo que lo hace tan poderoso. Los URIs son sencillas cadenas. El Framework sólo ve cadenas. Estos componentes tienen contextos (en terminología del Framework, “Camel Contexts”), que administran los ciclos de vida de los distintos componentes dentro de él, y entre las URI que crean cada componente, Camel soporta más de 70 “protocolos” (válgame la expresión): JMS, FTP, correo electrónico, archivos, Hibernate, HL7 (usado en medicina), e incluso personalizados.

En su uso, no es necesario programar, sencillamente hay que indicarle lectura y salida. De necesitar modificaciones adicionales, sólo se cambia en la declaración la parte a sustituirse, permitiendo agregar fácilmente objetos manejadores (handlers). En muchos casos sólo hay que definirse la regla de flujos.

Enseguida, el Ing. Suárez mostró un caso de estudio y estuvo hablando de su experiencia al respecto. Como conclusiones, señaló que de entre las posibilidades de integración había conocido anteriormente Spring Integration, por ejemplo, y hacia 2007 que nace Camel, lo encontró con muchas mayores posibilidades y mejor documentación. Si su necesidad va a un solo archivo, pensaría en Spring Batch, pero para más cosas, Apache Camel es la opción. Empero, antes de usar una herramienta así (en general), remitirse al libro de patrones e implementarlo a la propia manera es la recomendación. En todo caso, sería hilar la secuencia.

Si tiene la oportunidad de ver la videograbación del evento, esta última parte de la exposición, el código contante y sonante es extremadamente difícil de describir en unas cuantas líneas. Estuvo mostando características muy particulares y especiales con las que la imaginación voló a grandes alturas. Tan es así que este, quien escribe, sencillamente perdió cómo el Ing. Suárez hizo que el Framework realizara un diagrama del código que había ingresado: obtuvo un diagrama conforme iba fabricando.

El receso, como siempre, mucho muy nutrido merced de las posibilidades mostradas en la charla. En esta ocasión no detallaré este periodo para avanzar hacia la segunda ponencia, esperada por muchos (me incluyo): la Introducción a Griffon, por Andrés Almiray, algo así como escuchar “El Rey” en la voz del propio José Alfredo Jiménez, escuchar el desglose de la Teoría general de la relatividad de voz de Albert Einstein, a Auguste Comte sobre la filosofía positiva (o la sociología), o a Aki Maita de los Tamagotchi (1996).

Esta ponencia está en su totalidad videograbada para deleite de los asistentes y para terminar de convencer a quienes todavía no han ido a las reuniones. Querer es poder. Y no hay mejor tiempo que ahora. ¡Anímense!

¿Qué es Griffon? Es una amalgama de tecnología para hacer aplicaciones de escritorio, haciendo uso de groovy, grails y swing. Inició describiendo dichas tecnologías por separado.

Comenzó, para quienes no conocen el “groovy way” con dicha introducción. Para no hacer esta reseña todavía más larga, remito al novel al artículo http://grails.org.mx/codice/showContent/3 que enlista dicha comparativa.

Acto seguido, el Ing. Almiray habló de Swing y sus características: todo componente debe usarse en el EDT, siendo muy fácil de quebrar esa regla de oro. Cada cambio debe hacerse en la EDT principal. El uso de clases anónimas internas, y el código “un poquito” largo.

De groovy resaltó el uso de “closures” como ventaja. Enseguida, el “Binding” (ligadura o referencia a otro símbolo), sea explícita mediante un nodo bind, o implícita, en contexto. Groovy es mucho más corto. Toda sentencia del programa es una expresión, al ser más expresivo, es más fácil de leer. Groovy es multihilo, separa el código para la edición desde fuera.

SwingWorker (Java 5 ó 6) permite lanzar cómputo en el fondo y procesar el valor de resultado en el fondo: azúcar sintáctica para obtener elementos.

Sobre Grails, su propuesta de convención sobre configuración (evitando el doloroso XML) que tanto pie da a equivocaciones, el “no te repitas” (DRY, por sus siglas en inglés), el patrón MVC, que de seguirse reduce drásticamente el trabajo, la automatización de tareas repetitivas y el soporte de pruebas incluido.

De conocer Grails, poco más de la mitad del camino para usar Griffon está andado. Para muestra, un comando (o algunos):

$ griffon create-app
$ griffon run-app
$ griffon run-webstart
$ griffon run-applet

De manera similar a Grails, se arma un árbol de directorios listo para llenar con la lógica necesaria. Con atributos como @Bindable se añaden funcionalidades visibles a las clases Java. Por ahora los “closures” no tienen herencia, por eso se soportarán en Java 7.

Para configurar, simplemente hay que recordar, como llamó el Ing. Almiray, el ABC: A, aplication.groovy, B, builder, configurar lo que se desee, y C, configurar en tiempo de construcción.

En los ciclos de vida, se ofrecen 4 predeterminadamente y uno más en applets: Initialize (para el “look and feel” o conexión a bases de datos, por ejemplo), Startup (con el esqueleto armándose), Ready (con la cola vaciá en el EDT) y Shutdown (cuando está a punto de cerrar). En el caso del applet, el quinto es Stop.

Para no repetirse a uno mismo, Griffon propone el uso de un lenguaje dinámico (groovy) con “closures”/“blocks”, con propiedades tersas de sintaxis, con sintaxis por evento y sopoorte de anotaciones ricas. Entre las pruebas integradas, create-app agrega una prueba de integración por controlador (controller), para cada parte del MVC y con create-unit se añade una prueba nueva.

Sobre los agregados (plug-ins), de los más de 230 que ofrece Grails, Griffon, al momento de esta ponencia, tiene 27. Entre ellos FEST, interfaz fluida para pruebas en Swing, Codenarc para análisis estático, code-coverage para usar a Cobertura, Jdepend para métrica de paquetes, y más: Programación políglota (Scala, Clojure (muy bueno para concurrencia, usa LISP), JavaFX, componetes (SwingX, Jide, Flamingo, MacWidgets), Glitz (CSS, gfx, JGoobits forms, tridente (para animaciones y cosas bonitas), y todavía más (splash, wizard, installer, Gparallelizer, GSQL o groovy SQL) y algunos más ya en progreso.

Como recursos, la página del proyecto http://griffon.codehaus.org/, http://griffon.codehaus.org/Builders, http://griffon.codehaus.org/Plugins y http://groovy.dzone.com/ fueron la referencia. Adicionalmente, twitter: @theaviary, el libro Griffon in Action (marzo 2010) http://manning.com/almiray se proporcionaron como soporte.

Un dato a resalar, la presentación fue una aplicación realizada con Griffon. En ella se hicieron efectos entre las diapositivas y se corrió código “en caliente”. Por último, mostró el comando

$ griffon stats

con las particularidades del programa de la presentación. Enseguida, unas líneas de código para desplegar dos cubos rotando, uno mediante OpenGL, el segundo “rendereado” por software. Presentó a SwingPad y concluyó diciendo: Swing puede ser divertido y fácil. Griffon resuelve los problemas por Usted, y Grails es la mitad de la batalla.

Tras la exposición, el “padrino” de estas reuniones realizó preguntas para regalar playeras con el logo de SpringHispano, Grails.org.mx y SynergyJ. Tras ello, en el comedor siguió la charla sobre temas distintos, mientras degustamos menú en dos tiempos con frutas y una ensalada soberbia. Hubo muchas caras nuevas, dando pie a la dinámica repetida en algunas ocasiones anteriores donde se iban presentando los asistentes, y al final el padrino, Andrés Almiray junto a su esposa, dieron una felicitación al equipo detrás de estas reuniones por mantener e incrementar este esfuerzo, que muchos podemos constatar y que ha servido incluso como directriz para otros proyectos. ¡Enhorabuena SpringHispano, GrailsMX y JavaMéxico!