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.