Google Chrome OS

Es la noticia de la semana, Google lanza en un año más un sistema operativo para netbook y desktop. De todos los artículos, blogs y conversaciones en foros que salieron, este análisis es el que más me hizo sentido. Para tener una perspectiva más critica y además muy divertida, este blog es imperdible.

No me queda más que algunos pensamientos sueltos.

• Google la lleva. Este anuncio creo una tempestad de comentarios y análisis. Solamente Apple logra tener tanto impacto con sus anuncios.

• Google empieza a usar la estrategia M$ de anunciar sus productos con bastante anticipación. Eso me hace pensar que más que el producto en si, buscan mandar mensajes al mercado.

• Los mensajes que yo recibo son:
• la web lo es todo. Cualquier solución tiene que ser web compatible.(HTML, CSS, javascript y algunos plugins)
• el desktop como plataforma de desarrollo esta muerto. Me refiero a las API AWT/Swing/SWT de java, Qt/Gtk de los desktop LInux y las API's de Windows
• si los competidores se estancan, como lo hizo M$ con IE 6 o ofrecen soluciones propietarias como Adobe/Flash, M$/Silverlight, Sun/JavaFX, Google esta dispuesto a remecer el statu quo y forzar la evolución de los estándares abiertos haciendo regalos.

• Google busca tener un control sobre el cliente para presionar a su competencia. Creo que busca lo mismo que lo que hizo Apple con su iPhone.donde niega licencias a fabricantes de maquinas virtuales como el flash de Adobe, M$ .Net y Sun Java. Apple tiene el control de lo que es multi-plataforma (web) y lo que no. Google busca lo mismo.

• El negocio de Google depende que la web siga una plataforma abierta y no puede permitir que un solo proveedor tenga el control del cliente. Es suficiente recordar M$ con sus Windows cliente, los cuales le permitió ganar terreno en el servidor (OS, base de datos, servidor de correo, etc).

De mi punto de vista, Google es amigo de las tecnologías estandarizadas, no por buena onda sino por razones de negocio. Da lo mismo, confió en lo que hace Google.

Google Wave es la raja

No soy adicto al facebook, no tengo cuenta en Twitter, pero creo que ya estoy totalmente vendido a Wave.

Simplemente genial.

Oracle vs todos los demases

No me apasiona mucho la guerra de los Desktop OS pero si la guerra de los RIA.

En el último JavaOne, el dueño de Oracle, Larry Elison, subió al escenario y declaro su respaldo a JavaFX, la solución RIA de Sun. Pidió al grupo OpenOffice que empiece a usarla y que Sun fabrique algunos netbooks usando esta tecnología.

Eso es muy interesante por varias razones:

• JavaFX es más una tecnología para consumidor final que para empresas. Si Oracle vende ahora principalmente software para empresa. interpreto entonces que están muy interesados en este mercado también.

• Haber nombrado JavaFX y OpenOffice en una misma frase, es como una declaración de guerra a Microsoft. ¡Vamos por Silverlight y la suite Office!
  

• Al mismo tiempo, nombro a Google como una empresa "amiga". Claro, Google trabaja bastante con Java, pero "a su manera":
  

• Su SO Android para smartphone (y netbooks) usa el lenguaje Java pero tiene su propia maquina virtual.
  
• La solución RIA de Google, GWT, consiste en Javascript en el browser generado desde código Java.

Entonces, si Oracle quiere entrar en el mercado del consumidor final con su compra de JavaFX, no veo como puede hacerlo haciendo competencia solamente a MS y no a Google.

Se ve muy entretenido.

Claramente Windows Vista es mejor que XP

Claro, tengo mi propia estadística para afirmar eso. Mis últimos laptop venían con Windows pre-instalado y tengo como política aguantar este SO hasta que no se pueda trabajar más con el. Cuando el sistema se hace enfermo de lento, migro a Linux: Kubuntu ahora, Mandrake y RedHat en el pasado.

Antes de MS Vista, tuve dos Windows XP y se demoraron 9 meses promedio para comerse toda la maquina. Vista me duro 1 año 3 meses. En los últimos dos meses empezaba a ponerse bastante lento y la instalación del Norton 360 lo remato: se demora 15 minutos ahora para abrir un browser. Como sea, Vista se demoro 4 meses más que XP para ser insoportable. Claramente, es mejor.

Entonces volví a Kubuntu como SO Desktop después de más de un año. Los Linux totalmente gratuitos siguen llenos de pequeños detalles que los hacen no recomendables para usuarios finales, como por ejemplo, el manejo de las redes wifi, el hecho de no poder tocar MP3 a la primera. Además, como instale un SO 64bits, me trae nuevos problemas como correr Oracle Express que es 32bits.

Todavía no tengo explicación de porque mis Windows terminan super lentos. No es un problema de fragmentación de disco porque Linux lee a plena velocidad las mismas particiones NTFS.

Finalmente, yo pensaba que la guerra de los SO Desktop había terminada hace rato, que Windows había ganado el mercado masivo y que los otros SO se quedaban con nichos como el MAC OS para diseñadores y Linux para algunos profesionales TI. No es tan así, porque el mercado de los netbooks ha sacudido un poco el statu quo. MS tuvo que hacer rebajas importantes sobre sus licencias para eliminar Linux y muchos fabricantes hablan de usar Android (el SO para smartphone de Google) en sus Netbooks.

En todo caso, la guerra de los SO Desktop no me apasiona mucho. Encuentro una perdida de tiempo increíble administrar un PC. A esta altura, deberían estar funcionando a la perfección y para siempre.

¿Adios a los teclados, los ratones y las pantallas?

Poco a poco, las computadoras reconocen nuestro lenguaje corporal y reaccionan en función de eso.

Este vídeo muestra lo que viene en un futuro no tan distante. Impresionante.

Oracle compra Sun

Es la noticia del año, Oracle le gano a IBM y logra un acuerdo de compra de Sun.

Ya declare mi simpatía por Sun y me da algo de tristeza que termine siendo comprado. Me alegra un poco que el comprador sea Oracle, y no IBM , porque Oracle tiene mucho menos traslape de productos, partiendo por el hardware y el sistema operativo.  Incluso, Oracle no tiene una estrategia de productos Open Source como la tiene IBM.  Entonces los software Open Source de Sun pueden llegar a complementar la oferta de Oracle: mismo tipo de software pero para distintos tipos de clientes o proyectos.

Ahora viene el tiempo de tratar de adivinar lo que va a pasar, que productos de Sun van a quedar y cual va a ser la estrategia de Oracle.  Apuesto que:

• Oracle no va a vender el negocio de hardware de Sun.  Primero porque le permite entrar a competir con IBM de igual a igual.  Además, Larry Elison se ha declarado escéptico con el cloud computing y creo que van a ofrecer appliance "a la carta" para competir con este fenómeno.  O sea, el cliente escoge módulos de EBS. configuran el volumen de transacción y el SLA deseados y recibe un servidor listo para trabajar.  Algo así como Dell lo hace para PC.

• Solaris es critico para la explosión de los multi-core.  Yo creo que Linux va a hacer agua y MS esta arreglando WIndows recién con su versión 7 eliminando los cuellos de botella.  La escalabilidad de Solaris ya es archi probada.

• MySQL y Glassfish van a seguir siendo desarrollado.  Los van a ofrecer cuando necesitarán reducir costos.

• Java no va a tener mayor cambio.

• No creo que Netbeans sobreviva.  Oracle ya tiene jDevelopper e hizo sus plug-ins compatibles con Eclipse.  

• Creo que OpenESB va a morir también.

• No tengo ninguna idea de lo que pasará con Open Office.

Tendré que esperar un buen rato para ver cuanto me equivoque porque Oracle soporta los productos que compra durante mucho tiempo.  Paciencia....

Microsoft al rescate

En mi búsqueda de convencer clientes conservadores que es tiempo de usar nuevos lenguajes como Scala y nuevos framework como Lift , me encontré con el caso particular de los "clientes MS".   Algunos de estos usan Visual Basic, T-SQL y programación estructurada.  En primera instancia, descarte por completo tratar de convencer este tipo de cliente: lograr que adopten, programación Orientada al Objeto, programación Funcional y un servidor de aplicación Java me pareció una tarea casi imposible. 

No obstante, lo estoy repensando porque MS demostró algo que estos clientes entienden muy bien:

• una maquina virtual puede/debe soportar múltiples lenguajes,
• se usa el lenguaje más apropiado a cada problema y a la capacidad del grupo de desarrollo,
• si se usa un solo set de API's, es relativamente fácil pasar de un lenguaje a otro.

Si se compara con el mundo Java: a pesar que la JVM soporta hace rato múltiples lenguajes, la tradición es que todo se programa en Java y se cambia la API/framework según el problema a resolver o la capacidad del grupo de desarrollo.  Entonces, hay una barrera que se tiene que romper en Java y que no existe en el mundo .Net.

Además, MS esta bastante activa con los lenguajes funcionales y los posiciona como solución a la crisis del multi-core.  El creador de F# habla bien de Scala  y Haskell sigue siendo una referencia para el control de los efectos colaterales con su soporte STM 

En resumen, MS esta demostrando porque se requiere un cambio de paradigma y que este cambio puede ser incremental sobre su maquina virtual (con F# y Haskell).  Voy a usar estos mismos argumentos, cambiando la CLR de .Net por la JVM de Java, F#/Haskell por Scala y STM por la API Actor.  

Fácil.

Ahora si, hablare de SUN e IBM

Supongo que ya todos saben que IBM estaría evaluando la compra de SUN: la noticia ha generado una avalancha de artículos, entrada de foros y blog que son difíciles de ignorar. 

Aquí va mi opinión sobre el tema:

• no entiendo exactamente lo que puede ganar IBM porque hay un traslape enorme entre los productos de estas empresas.  ¿Cual es el interés?, ¿Es para ganar los clientes? ¿Es para adquirir algunas propiedades intelectuales como Java, diseño de los procesadores?  ¿Es para bloquear una compra por parte de CISCO?

• Se lo que nosotros como clientes perderíamos: competencia.  Si IBM compra SUN tenemos un proveedor menos en todos los productos que ambos comparten.   Además se pierde un proveedor bastante competitivo: SUN se ha caracterizado por escoger tecnologías abiertas: UNIX, TCP-IP, Java, base de datos y ahora desarrollo Open Source.  

• No creo que haya efectos notables sobre Java.  Ni positivos, ni negativos.
• varios de los productos de IBM están basados en Java: IBM tiene que cuidar Java y su ecosistema.
• Java es bastante maduro, su tasa de innovación seguirá bajando independiente de esta compra.
• Sería una pena ver desaparecer Netbeans o Glassfish: tendría que acostumbrarme a Eclipse y jBoss, los cuales no son mis preferidos pero no sería un desastre
  
• El mundo Java es altamente competitivo, hay más de 3 proveedores en cada uno de los productos importantes (como por ejemplo, la JVM, los servidores de aplicación y los IDE).  Java aguanta tranquilamente una fusión más.

En fin, prefiero que SUN siga como esta, una empresa independiente e innovadora.

Hoy, no hablare de SUN y de IBM

Que pena que soy ateo.  No tengo a quien rezar.

RIA y framework web

Son dos temas que toque antes por separado.  En el tema RIA, aposte que Javascript iba a ser la tecnología dominante en el browser (sobre Adobe Flash/Flex, MS Silverlight y Java/JavaFX).  En el tema de los framework web, observe que la guerra no esta terminada y declare mi preferencia por Lift .

Ahora, estoy seguro que los temas RIA y framework web son indivisibles, porque:

• no creo en una solución 100% browser.  Eso seria programar Javascript en el browser, llamando interfaces Web Service o RESt en el servidor que retornen XML o JSON.  Javascript es mucho más potente de lo que pensaba pero nunca tanto.

• ya no creo en una solución 100% servidor, como por ejemplo:
• un framework basado en componentes que se inicializan vía tags o programación Java y que generan mágicamente el HTML, CSS y Javascript cliente
  
• un compilador de Java a Javascript como el GWT de Google o un compilador de XML a Javascript como el OpenLaszlo .

Entonces, creo que el framework web debe permitir programar en Javascript en el browser con la opción de interactuar con el Javascript generado por el, como por ejemplo ser notificado de algún evento y procesarlo localmente (sin necesidad de ir al servidor)  Además, tiene que darme la opción de llamar código de negocio en el servidor desde Javascript mio en el browser.

Para mi, es un cambio importante, porque si había escrito sobre este tema hace 1 año, habría dicho sin vacilar que confiaría todo la generación del javascript a un framework como JSF o Wicket argumentando que "menos javascript veo mejor me porto".  Fiel a este concepto, cuando empece a trabajar con Lift, implemente un wrapper de Flot para implementar el código Javascript una sola vez y re-utilizarlo como un widget. Ahora que termine mi último proyecto, me doy cuenta que mezcle sin asco javascript en el browser con javascript generado por las API's de Lift y lo encuentro perfectamente normal.  Hasta lo encuentro elegante.

Con la luz de esta revelación, voy a revisar los framework que conozco y ver como resisten.

Lift

Si llegue a esta conclusión, es porque Lift me permitió esta mezcla y me convencí que no era una abominación. 

Una vez que entendí como funciona jQuery y el soporte AJAX de Lift es muy fácil intercambiar código javascript en el browser versus código Scala/Lift que genera javascript.  Con un poquito más de esfuerzo se puede hacer comunicar estos códigos entre si.  Cabe notar que Lift soporta Yahoo UI también y debe ser relativamente fácil (pero tedioso) soportar otras bibliotecas javascript.

Creo que David Pollak tuvo una muy buena idea usar un framework conocido: 

• ahora es fácil crear código que encapsula los widget de jQuery.  Lift puede aprovechar las mejoras en jQuery como jQuery UI.
  
• como jQuery y Yahoo UI son populares, tienen buen soporte y documentación.  El grupo de Lift puede ahorrar este esfuerzo.

Lo único que puedo criticar a Lift es que es relativamente de bajo nivel: hay que entender como funcionan las cosas por debajo para ser eficiente.  Lift esta en su versión 1.0, tiene tiempo para desarrollar algo un poco más abstracto (lo cual es posible porque el "bajo nivel" esta bien hecho).

Wicket

En comparación Wicket usa su propia API javascript.  Hasta lo que se, no hay documentación y puntos de interfaz para conectar código Javascript propio  

Es relativamente normal, ya que Wicket tiene una filosofía orientado a programación Java: los componentes se crean y asemblan vía código Java en el servidor.  Es entonces cada componente que es responsable generar el código javascript que el requiere.

JSF

Pasa lo mismo con JSF, con los agravantes:

• es bastante difícil crear componentes propios,
• algunas bibliotecas JSF que soportan AJAX intervienen el ciclo de vida del procesamiento de la pagina para retornar el código AJAX.  Eso crea incompatibilidades entre las soluciones.
• la configuración vía tags es generalmente inflexible.

Cabe notar que la idea de escribir este entrada de blog, me llego leyendo esta entrevista donde un fabricante de componentes JSF afirma que:

"A new feature in our latest edition is a JavaScript eventing model. In the past, the focus of our product was to keep the JavaScript engine under the covers, and to provide only limited access points to it. Our customers had been telling us to open that [event model] up so that they can plug in JavaScript and Ajax calls pretty much anywhere. In response to those requests, we enabled over 200 event attributes across our components."

Leyendo eso, me di cuenta que eso estaba haciendo con Lift y que era entonces un punto a su favor.  Tenia que documentarlo.

Struts

Supongo que el abuelo de los framework web hace completamente agua con AJAX.

Servlet/JSP

Podría ser una solución para código Javascript 100% cliente.  No es lo que busco.

Voy a tener que comparar Lift con RoR o Grails o Django porque parece que los framework web Java llegaron a su máxima capacidad  Nota: es un buen argumento para convencer que es tiempo de mirar otras soluciones que java. 

¿Qué es mejor que un DSL interno?

Un DSL interno basado en Scala 

A pesar de ser static typing su sintaxis le permite crear DSL internos tan legibles que los posibles con Ruby.  Scala la lleva.

Reflexiones sobre internal vs external DSL

Me toco durante Diciembre evaluar 3 formas de implementar ruteo y transformación de mensajes usando Sun OpenESB .  Sun provee 3 formas distintas de hacerlo:

• con la versión de producción actual:
• usando BPEL y llamadas a servicios vía WSDL para operaciones más complejas.
• usando Apache Camel dentro de OpenESB
• con la versión en desarrollo, llamada fuji, usando el Integration Flow Language (IFL).

IFL es un DSL externo y Camel usa DSL internos basados en Java , Spring-XML o Scala .  Comparando las soluciones pude hacerme una opinión sobre el DSL interno vs externo.

Primero algunos comentarios

• XML es un pésimo lenguaje para definir un DSL.  Una de las gracias de un DSL es que debe ser fácilmente legible y XML no permite eso porque agrega mucha sintaxis que no aportan nada para un ojo humano.

• IFL como DSL externo esta bien construido: 
• la sintaxis es super simple porque no tiene todos los adornos del lenguaje subyacente que hacen ilegibles un DSL sobre XML y que molestan en caso de Java..  
• Sun no incluyo en IFL sintaxis para programación más compleja, como por ejemplo para enriquecer un mensaje. En su lugar permite encapsular código jRuby que puede llamar a servicio Java vía Web Service.  El defecto de esta solución es que requiere usar muchos lenguajes distintos (IFL, Ruby, WSDL, Java).

• Camel usa 3 tipos de DSL internos:
• sobre Spring-XML: es ilegible.
• sobre Java: Java tiene una sintaxis inflexible para ser usado como base de un DSL interno:  principalmente el uso del punto y de los paréntesis para llamar a métodos   
• sobre Scala: creo que es un buen ejemplo de lo potente de la sintaxis Scala

• Los DSL internos de Camel basados sobre Java o Scala, permiten llamar todas las bibliotecas del lenguaje sin pasar por una interfaz WSDL o un lenguaje de scripting.  Es una ventaja considerable para anticiparse a la necesidad de crear extensiones.

Mi posición sobre interno vs externo

Los ESB son un ejemplo donde hay que pensar de antemano en como crear extensiones.  Es entonces, un buen caso de uso para probar lo potente del concepto DSL.

Por su simplicidad, me parece correcta la solución de DSL interno de Apache Camel.  Como el ESB va a ser configurado por un programador, la poca sintaxis Scala necesaria (como la definición de paquete y los import) no molesta mucho.

Si tuviera que implementar un DSL, mi primera opción sería entonces un DSL interno.

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.