Riesgos de los DSL

El año pasado leí este articulo sobre los riesgos de crear un "external DSL" propio.  El articulo menciona el costo de mantener código no trivial como un riesgo importante y eso me hace sentido porque ya ocurrió antes, con los frameworks Java.  

Conozco algunas empresas que crearon en casa sus framework web, de persistencia o de DI en lugar de usar alternativas open source conocidas.  Ahora, estas empresas tienen que

• capacitar sus empleados en el uso de estos framework y me imagino que para estos empleados no le agrega valor mencionar este conocimiento en su curriculum.
  
• hacer evolucionar el framework con las tendencias nuevas como por ejemplo el uso de anotación y programación genérica,
• al revés, dejar de mantener el framework y no aprovechar las ventajas de las tendencias nuevas ante-mencionadas.
• migrar el código para usar framework más conocidos.

Estos mismos problemas existen también en el mundo de los DSL.  Para mitigarlos, el autor del articulo propone desarrollarlos en modalidad Open Source o desarrollarlos con una comunidad de empresa que comparten el mismo dominio de negocio.  En los comentarios del articulo y en este otro más antiguo se recomienda que el DSL sea bien acotado (no más de 1 día de aprendizaje) y estático (sin cambios futuros).

Me parece super razonable.

De desktop a Web RIA

Cuando empece mi ultimo proyecto nunca pensé que iba a terminar haciéndolo como una aplicación web.  El sistema se parece a un cajero automático: es un PC, una impresora y una pantalla touchscreen instalados en un rack cerrado.  El usuario selecciona algunos datos, la aplicación se conecta a algunos sensores e imprime una etiqueta adhesiva con códigos de barra. 

Mi primera opción fue usar Java y la API Swing para crear una aplicación desktop convencional.  Alcance a desarrollar un prototipo inicial con Matisse de Netbeans y empece a actualizar mis conocimientos de Java2D para usar la impresora.  Mi única preocupación era hacer botones y labeles grandes para que el usuario los pueda seleccionar sin problema.  

Cuando llego el primer diseño de la interfaz al usuario, empece a cambiar de opinión.  Los botones no se parecen en nada a los de Swing, de Windows o de ningún sistema operativo conocido: sus bordes se mezclan poco a poco con el fondo de la pantalla en un efecto tipo anti-aliasing.  Al disparar un botón, ejecuta una animación que se parece a un destello de luz.  Pensé que iba a tener que crear mi propio renderer de Swing y eso me sonó como complicado.  

Además, habría tenido que ubicar los distintos elementos con una precisión de pixel porque el fondo no es de un solo color, sino una trama de grises oscuros: un pixel de error y se pierde el efecto de anti-aliasing.  O sea, tenia que decir chao a los layout de Java/AWT,  Eso me sonó como mucho trabajo.

Finalmente, un nuevo requerimiento funcional hacia muy probable la necesidad de recibir un archivo vía HTTP  Tenia que integrar un servidor web dentro de la aplicación desktop.

Entonces, surgió la posibilidad de hacerlo como una aplicación web.  Por el tipo de UI, era obvia la solución: una aplicación web RIA con javascript con jQuery en el browser y el soporte AJAX de Lift en el servidor.  

Comentarios

No lamente el cambio, porque pude solicitar la entrega del diseño UI en HTML, jpeg, GIF y CSS: el diseñador se llevo la tarea de colocar todo pixel a pixel.  Incluso, logre liberarme de Java2D para la impresión: en su reemplazo use la API Java iText y una plantilla PDF que me entrego el mismo diseñador de la UI.  Con eso pude imprimir a través del plug-in Adobe Reader en el browser en lugar de controlar yo mismo la impresión.

Cada vez me gusta más jQuery.  Recomiendo a los que quieren aprender Lift, aprender a usar bien jQuery (o Yahoo UI el otro framework javascript soportado por Lift).  De esta forma, es fácil prototipear en HTML, Javascript y luego pasar a código Scala/Lift en el servidor si es necesario.

Este proyecto me permitió profundizar el soporte AJAX de Lift, el cual es muy bueno.  El código quedó modular y re-utilizable: pude crear varios componentes de negocio, como una pre-visualización HTML de la impresión y un teclado numérico touchscreen, que re-utilice tal cual entre varias paginas.  Se que hacer lo mismo con Servlet/JSP, Struts, JSF es casi imposible.  Lift es realmente una mejora significativa.

También Scala salio muy bien.  El hecho de poder llamar directamente a las API's de Java y instalarse sobre cualquier servidor de aplicación Java es realmente una ventaja enorme sobre otros lenguajes.  Por ejemplo, pude usar Apache iText (para PDF), Apache POI (para Excel) y la API Socket de Java para conectarme con los sensores.  

Microsoft da lecciones de Open

Genial...   Steve Ballmer se dio un gusto bien merecido porque pudo criticar una empresa que es mucho menos Open que Microsoft. Esta empresa es Apple y el ataque es contra el iPhone.

Hay que recordar que luego de estar completamente cerrado, el Apple iPhone ahora tiene un SDK para aplicaciones de terceros.  Pero, la licencia esta hecha para prohibir maquinas virtuales tipo Java. .Net y Flash.   

Y lo más grave es que Apple mantiene un control casi dictatorial sobre las aplicaciones que se pueden descargar: decide en forma unilateral y sin justificación previa retirar una aplicación de su sitio de descarga.   No solamente puede hacerlo, lo hizo.

¡Vamos MS!  ¡Los amo de nuevo! 

Resolviendo confusiones con los ESB

wikipedia no viene mucho al rescate para explicar lo que es un ESB: "There is some disagreement on whether an enterprise service bus is an architectural style, a software product, or a group of software products.". Claro como agua del Mapocho.

Gracias a una evaluación de varios productos que declaran ser de tipo ESB pude empezar a resolver varias inquietudes. Estos productos son Sun , Apache ServiceMix , Oracle ESB/SOA Suite y Spring Integration .

Confusión #1: ¿que provee un ESB?

ServiceMix y Sun OpenESB implementan JBI y son relativamente cercanos. JBI define:

• un bus donde fluyen mensajes "normalizados" (llamado "canonical" en otros productos),

• adaptadores (bindings components en JBI) que suben o sacan mensajes del bus,

• una forma de conectar al bus paquetes de software llamados Service Engine o SE que proveen la funcionalidad realmente interesante.

JBI no define ninguna lista de Service Engine pero ServiceMix y OpenESB ofrecen soluciones parecidas:

• enrutamiento, filtro, transformación de mensajes, lo que antiguamente se llamaba brokering de mensaje,

• gestión de proceso de negocio (workflow o BPM)

• motor de reglas,

• procesamiento grupal de mensajes (CEP),

Los ESB tipo JBI pueden ejecutar lógica de negocio, como workllow, CEP y lógica de integración más tradicional como transformación de mensaje. Eso los distingue de los productos EAI donde se recomendaba no tener lógica de negocio en el bus: el workflow y el EAI eran 2 motores apartes.

Spring Integration, obviamente no implementa JBI, y parece solamente definir servicios de integración (adaptadores + brokering) como los EAI antiguos.

Oracle tiene otra división: su ESB es parte de su SOA Suite, la cual incluye BPM (Oracle BPEL) para lógica de negocio, pero no incluye Oracle CEP.

Entonces, lo que esta en común entre estos cuatros fabricantes (Apache, Sun, Spring, Oracle) son los adaptadores, el bus donde fluyen mensajes normalizados (o "canonical") y servicios de brokering. Algunas soluciones ESB pueden considerar conectar al bus servicios que implementan lógica de negocio como BPM o CEP. Otras soluciones ofrecen estas funcionalidades aparte.

La confusión era valida y sigue vigente.

Confusión #2: ¿ESB es indispensable para implementar una solución SOA ?

Creo que esta confusión viene del mundo SOA, donde después de tantos años, nadie esta de acuerdo en definir SOA. Todavía no tengo claro la respuesta a esta segunda confusión pero ya no me preocupa tanto desde que hay reportes de vez en más alarmistas sobre el futuro de SOA. SOA puede desaparecer, igual tendremos que comunicar sistemas entre si y construir flujos de negocio. Lo que ofrece estos productos ESB seguirá relevante por muchos años.

Confusión #3: ¿En que se distingue la arquitectura de un ESB de un EAI?

Hace poco tiempo atrás habria respondido que:

• proveen basicamente los mismos servicios,

• los ESB se basan en tecnologías estandares como XML, XSL, BPEL, JMS, JCA.

• Los ESB usan una topología más distribuida, que los EAI. Los EAI usan la topologia estrella donde todo converge a su bus y toda la integración se realiza en un par de servidores.

Por lo visto, el primer punto depende del proveedor del ESB, porque algunos ofrecen funciones de workflow/BPM que estaban separadas en la epoca EAI.

El segundo punto es correcto con la incarnación actual de los ESB. Apuesto si, que XML va a ser un poco menos usado.

El tercer punto, también depende del proveedor. La tendencia actual es modularizar el ESB de tal forma de poder configurarlo de distintas formas: desde una API dentro de una aplicación Java o como un motor sobre el cual desplegar aplicaciones. OSGI es el método usado para modularizar en ServiceMix, OpenESB versión Fuji y Spring Integration. En el caso de Oracle, la configuración natural seria estrella, principalmente por el costo en licencia y en recursos (CPU, memoria) de instalarlo en forma distribuida.

Confusión #4: ¿JBI es un estándar relevante?

Me gustan los estándares, pero si ningún proveedor importante los implementa no sirven de mucho. IBM nunca soporto JBI y tampoco Weblogic. Oracle lo soporto al principio pero no paso nada concreto. Sun  parecía muy solo con el tema JBI y lo habría dado por muerto.

No obstante, hay ahora 2 implementaciones Open Source de JBI, la de Sun, OpenESB y la del grupo Apache/IONA, ServiceMix. El estándar tiene un efecto bastante positivo: la compatibilidad. Un ejemplo, es que se puede correr Apache Camel, el cual es el broker de ServiceMix, como un Service Engine de OpenESB. Si logran intercambiar más adaptadores (Bindings Components en JBI) y otros Service Engine, se puede crear un mercado interesante.

Finalmente, el estándar en si es bueno porque es claro y acotado. Se puede criticar que es más orientado a fabricantes de soluciones de integración y BPM que para el programador. Creo que es una ventaja, porque todavía no esta definido cuales son las mejores soluciones, lenguajes, patrones, técnicas de programación, interfaz de diseño, para cada Service Engine. Por ejemplo, habrían podido obligar el uso de BPEL para un Service Engine de BPM: me alegro que no lo hayan hecho.

Confusión #5: ¿BPEL sirve de algo?

Siempre me resulto estredamente curioso que un lenguaje hecho para BPM no tenga capacidad de incluir tareas humanas: no conozco a ningún proceso de negocio donde un humano no tenga que intervenir. Casi seguro que el más automatizado de los procesos tiene condiciones de borde como errores, excepciones donde un humano tiene que hacer algo. No haber incluido este tema desde la versión 1.0, me parece muy poco serio. De hecho, la adopción fue muy lenta en los motores de workflow y muchas veces es solamente para cumplir con decir “cumplimos con el estándar pero recomendamos usar otra solucion” como por ejemplo jBOSS jBPM.

Al mismo tiempo, veía más adopción por proveedores de brokering de mensajes (EAI tradicional), a pesar que la literatura no recomienda usar BPEL para eso. De hecho, la versión actual de OpenESB usa BPEL para rutear mensajes/tareas. Al parecer pasa lo mismo con Oracle ESB donde para hacer ruteo algo complejo hay que usar BPEL.

Mi impresión es que BPEL quedo entre medio de 2 mundos y no hace ninguna cosa bien. Además viene con todo la herencia XML donde no se puede hacer nada simple.

Veo que Sun opina lo mismo, porque en su versión Fuji, han creado un DSL llamado Integration Flow Lenguage que reemplaza BPEL como ruteador de mensajes.

Confusión #6: ¿Los ESB se justifican fácilmente?

Las herramientas EAI eran muy costosas en licencia, tiempo de aprendizaje y puesta en marcha. Se necesitaba un volumen importante de sistemas a integrar para justificar la inversión.

Los ESB usan estándares y algunos son OpenSource gratuitos. Eso reduce significativamente la barrera de adopción. No obstante no la elimina por completo.

He usado productos que requieren una curva de aprendizaje similar. Tanto Magnolia como Web CMS y Alfresco como CMS de gestión documental, me demandaron 3 semanas para ser relativamente eficaz. Al hacer la primera página Web con Magnolia, recupere esta inversión. Al hacer el primer flujo de aprobación documental con Alfresco  también. Eso era debido que implementar desde cero estas funcionalidades me habría requerido bastante más esfuerzo.

No pasa lo mismo con un ESB: yo puedo fácilmente usar Java EE para leer archivos, transformar formatos, conectarme a bases de datos y colas de mensajes. Para que sea rentable el aprendizaje debe haber más de una necesidad de integración. La barrera esta bajando pero sigue vigente.

¿Como convencer que es tiempo usar Scala en lugar de Java?

Argumente en una entrada previa que se vienen nuevos tipos de aplicaciones que van a requerir cambios de arquitectura de software, o sea, cambios en los lenguajes y los middleware como servidores de aplicación y bases de datos.  Tengo la suerte ahora de participar en un proyecto asi: es de tipo CEP (Complex Event Processing) y podre usar Scala DSL de Apache Camel.

Esta bien, pero no es suficiente.  Quiero también usar Scala en proyectos web más tradicionales, porque no es todos los días que tengo la suerte de participar en proyectos realmente innovadores.  Por ejemplo, ahora mismo, estoy terminando un proyecto con J2EE 1.,4, Struts y EJB 2.0 para un cliente bastante conservador.  Pensando en este proyecto y el tipo de profesionales con los cuales tuve que interractuar, tengo que aprender a convencer que es el momento de mirar soluciones no 100% basadas en Java y JEE.  

Buscando lo que dicen los pundits en internet me encontré con este articulo de Bruce Eckel.cuyas conclusiones me hacen sentido: 

• Java llego en una etapa donde agregar nueva sintaxis como "closure", va a costar de vez en más . "...the adoption of new Java versions and features is going to continue to slow"
  
• La JVM y sus toneladas de bibliotecas van a ser heredadas por otros lenguajes. "The JVM will be the most important legacy that Java contributes to the computing world. "
• Scala y Groovy estan al acecho para re-utilizar la JVM y sus bibliotecas. "...Scala and Groovy (which play well with Java right out of the box)..."
  
• Hay Java para rato.   "Java itself will continue to be a core workhorse, just as C++ has been..."

No obstante, no estoy completamente de acuerdo en como Bruce fundamenta estas conclusiones. El hace una serie de criticas sobre Java y el rol que cumple Sun de las cuales algunas no son 100% justificadas o otras no son tan graves.

• el mensaje principal es que no se puede confiar en una organización con fines de lucro.  Es probable que si no había existido la necesidad de contrarrestar el dominio que tenia Microsoft sobre los desarrolladores, Sun no habría regalado su lenguaje e IBM no lo habría adoptado con tanta facilidad.   Entonces, compro este argumento pero solamente en parte, porque:
• existe muchos contra-ejemplo de lenguajes que no fueron apoyados por grandes empresas y que tampoco llegaron a un buen destino.  Perl es el primero que me viene en la mente.
  
• esta en las manos de los desarrolladores hacerse desear por las grandes empresas de TI.  Mientras no exista una sola tecnología dominante y que exista competencia por conquistar nuestro interés, estamos bien.

• no haber incluido closure y programación genérica desde el principio.  A mi, me parece una buena decisión de Sun haber aprovechado el boom de la internet.  Un año más tarde habría pasado la vieja, nadie habría sabido de Java y capaz que estaríamos criticando Visual Basic.

• haber mantenido compatibilidad hacia atrás cuando implementaron la programación genérica.  Me parece super razonable la decisión de Sun. Además, la programación genérica es muy practica para usos simples y la eche de menos en mi proyecto J2EE 1.4.

• No se cumplió a 100% el WORA (la portabilidad del binario Java).  Mi experiencia es que un proyecto razonablemente bien hecho es super portable.  En eso, Java esta muy encima de cualquier otra tecnología, incluyendo estándares como SQL, HTML, CSS y Javascript. 

• Implementación en Java de algunas funciones en punto flotante en lugar de usar el coprocesador.  OK, quizás para algunas rutinas matemáticas afecta un poco pero, la semana pasada vi una demo de un software de predicción estadístico con visualización en 3D. Estoy seguro que este software usa muchos cálculos en punto flotante y estaba hecho en Java/Eclipse RCP.  Al agua el argumento excepto para aplicaciones realmente fuera de lo común.

• Finalmente, Bruce termina argumentando que Python es la raja.  Quizás tenga razón, pero Python es más antiguo que Java y solamente orientado al objeto.  Yo creo que se necesita ideas realmente nuevas como la fusión de la programación funcional y la orientación al objeto para realmente dar un salto interesante.

Entonces, no me queda más que buscar otros argumentos.  Parece que va a ser difícil.

Evolución de los servidores de aplicación

Un tipo de SpringSource tiene un articulo muy interesante sobre la evolución de los servidores de aplicación.  SpringSource tiene un talento para hacerme reaccionar en forma negativa y no tengo una admiración incondicional por Rod Johnson .  Entonces, si estoy recomendando leer este articulo es porque lo encuentro realmente bueno.

Antes de propagandar su propia solución, el autor llega a la siguiente conclusión:

A new breed of application server is emerging. This new application server has a small, in-memory footprint. It starts fast and runs fast. It has a highly modular architecture and it can host a variety of services and domain-specific containers. It can respond to directives from a "grid controller" and it can provision, deploy, start, stop and tear down services on the fly. It runs efficiently in an elastic topology that may span heterogeneous physical hardware and virtualized hardware.  

En español:

• los servidores de aplicación se usan ahora para algo más que aplicaciones web dinámicas.  Por ejemplo, algunos productos ESB se montan sobre un servidor JEE para usar el manejo de transacción, la gestión de conexiones SQL/colas JMS, la administración vía JMX/consola Web, etc.  Estos ESB se programan con lenguajes no Java como BPEL, XPath, XSL o algún lenguaje de enrutamiento y enriquecimiento de mensajes propio.
• Un cluster con un número constante de servidores ya no es suficiente.  Se necesita soluciones "elásticas" donde una aplicación puede desplegarse automáticamente sobre nuevos nodos cuando crece su uso y decrece su SLA.  Al contrario, cuando baja el acceso a la aplicación, el sistema controlador de la grilla desactiva la aplicación para dejar más recursos a las demás.

Todo bien, pero no puedo dejar de criticar un poco el articulo, para no perder mi costumbre cuando se trata de SpringSource.

• habría sido bueno que el escritor diga desde el principio que trabaja para SpringSource.  Al principio, creí que era otro apostole de Rod, porque usaba el argumento liviano versus pesado de una forma super marketera.
• a pesar que estoy 1000% de acuerdo que la suite IBM Webpshere es la campeón de la pesadez. hay que señalar que lo que esta logrando SpringSource ahora, IBM lo tiene desde hace 3 años con productos como Webpshere ESB y Websphere XD.  Algunas veces, el pesado le gana al liviano y me parece suicidio dejar 3 años de ventaja a la fuerza de venta de IBM.

El futuro de las bases de datos SQL

Martin Fowler opina que vamos a ver cambios en el mercado de bases de datos.  Ver también el reporte en Infoq.

Su argumento central es que no necesitamos más a las bases de datos para integrar la información de una empresa.  Eso se debe que existen otras tecnologías (XML, Web Service, REST, JMS) que facilitan la integración entre aplicaciones y reemplazan a SQL.  

Es cierto que era una practica en la época cliente-servidor tratar de consolidar todas las tablas en un solo motor de base de datos, porque facilitaba hacer joins entre las tablas de las distintas aplicaciones.  La otra opción era conectar varios motores entre si, con facilidades de store-procedure remotos y SELECT remotos.  El hecho de tener un lenguaje estándar como SQL hacia fácil estos tipos de solución.  Entonces, para variar Martin tiene un buen punto,

La lógica de negocio se fue de los motores SQL hacia los servidores de aplicaciones y como lo menciona Martin la capa de integración también.  Hay una oportunidad de mirar por el lado para ver si hay algo mejor que SQL en algunos casos: SQL ya no manda el mundo TI como solía hacerlo.