¿Qué es un Enterprise Service Bus y por qué usarlo?

¿Qué tal?

El tema a tratar el día de hoy es sumamente importante, intentaré explicar la definición de un Enterprise Service Bus, así como las ventajas y desventajas de usarlo. Este post es complemento de uno anterior, Entendiendo SOA desde cero puesto que está muy relacionado con los ejemplos que puse en él.

La respuesta a la pregunta ¿qué es un ESB? nos conduce directamente a los patrones de diseño, ya que el ESB es la puesta en práctica de un conjunto de patrones de diseño que interactúan para formar el denominado Compound Pattern.

Dicho de otra manera, un ESB es una aplicación de software diseñada de acuerdo a un conjunto de patrones predeterminados, su función principal es ser un mediador entre diferentes aplicaciones para que éstas puedan comunicarse entre sí, sin tener que hacerlo directamente, envolviendo la complejidad que dicha comunicación involucre.

Veámoslo con un ejemplo muy básico. En la imagen se muestra un conjunto de aplicaciones, en este caso, una Aplicación Java, una aplicación .NET, un servicio web programado con BPEL y una Aplicación Legada. El requerimiento de negocio implica que entre ellas se comuniquen de la siguiente manera:

• La Aplicación Java requiere información de la Aplicación .NET y del Sistema Legado.
• La Aplicación .NET requiere información de la Aplicación Java, del servicio web BPEL y del Sistema Legado.
• El servicio web BPEL requiere información de la Aplicación Java y del Sistema Legado.

Al ver este panorama nos damos cuenta de varios posibles puntos de conflicto, el primero es que las relaciones directas entre las aplicaciones son un tanto complejas, lo que puede generar una gran cantidad de código para manejar las invocaciones necesarias en cada aplicación. Entre más aplicaciones y más relaciones existan entre ellas, mayor será la complejidad y dependencia. Con ello promovemos los diseños rígidos, poco flexibles a los cambios y difíciles de mantener, por ende estamos fomentando el Alto Acoplamiento entre aplicaciones.

Otro punto puede ser que no todas las aplicaciones soporten la comunicación con las demás, por ejemplo, si el Sistema Legado es una aplicación Siebel, Peoplesoft o alguna otra, pudiera ser que una de las aplicaciones no tiene forma de comunicarse con ella y sería necesario construir un adaptador intermedio para lograr el objetivo.

Otro aspecto vital en el intercambio de mensajes entre aplicaciones es la seguridad de la información, si alguna de las partes involucradas no soporta los estándares de seguridad o en su defecto, requiere algunos aspectos particulares que las otras no puedan proveer, existe una disparidad que pudiera generar problemas severos de comunicación o bien de vulnerabilidad.

Otra desventaja es que si aumenta la complejidad o la diversidad de las operaciones y componentes que usan las aplicaciones, es probable que se conviertan en pequeños monstruos en los que después difícilmente se mantenga el control, o peor aún, que el lenguaje o la tecnología que usen no sean lo suficientemente robustos como para cubrir los requerimientos de funcionalidad.

Otro parámetro sumamente importante en el diseño de las arquitecturas es el Performance. Dado que los recursos de infraestructura designados a cada aplicación fueron planeados conforme a los requerimientos iniciales, en ocasiones es muy complejo reajustarlos para cubrir la demanda adicional que genera la interacción con otras aplicaciones.

En fin, la lista es larga y creo que con esos ejemplos nos quedan claras las desventajas de usar este modelo de interacción.

Ahora veamos una mejor implementación de la solución, agreguemos un elemento mediador entre las aplicaciones que sea el único punto de interacción y que se encargue de Abstraer la complejidad del intercambio de información: un ESB.



De entrada, podemos identificar que la interacción se simplifica y que las relaciones que existían antes en cada aplicación ahora se encapsulan en esta "caja negra" volviéndolas transparentes para éstas.

Otro punto a favor es que al centralizar la Orquestación de las invocaciones, estamos promoviendo el Bajo Acoplamiento, la Flexibilidad, la Reusabilidad y por consecuencia facilitamos el Mantenimiento.

Un ESB además de jugar un papel de intermediario, debe proveer una serie de componentes de integración, de uso común y estandarizados, listos para usarse en poco tiempo, lo que reduce significativamente los tiempos de implementación.

Creo que estos puntos responden la pregunta ¿por qué usar un ESB? pero si con eso no es suficiente, continuemos con cuestiones un poco más técnicas de los beneficios de usarlo.

Este blog está enfocado a los productos de Oracle, por lo tanto mencionaré las características, buenas y malas, del ESB propio de Oracle (OSB) de acuerdo a lo mencionado en el White Paper y la opinión de los expertos, así como en mi propia experiencia.

Empecemos con las características y bondades que ofrece el producto:

1. De acuerdo a Gartner, el OSB está ubicado en la posición número 1 del mercado. Los expertos opinan que es la mejor herramienta del sector, en lo personal sólo he trabajado con dos y sin duda el OSB es más robusto.
2. Reduce los tiempos de implementación, lo que impacta directamente en el tiempo de entrega. En lo personal me parece (en la mayoría de los casos) que es más rápido desarrollar en OSB que en otros lenguajes, el secreto de la agilidad para esta herramienta, como para cualquier otro lenguaje, es conocerla y dominarla.
3. Está diseñado para conectar, mediar, y manejar las interacciones entre servicios heterogéneos, aplicaciones legadas e instancias de múltiples ESB.
4. La consola de administración del OSB proporciona una herramienta web de control, monitoreo e implementación, lo que facilita estas tareas ya que no es necesario instalar ningún producto adicional y se puede realizar desde cualquier lugar con acceso a la red. Esta puede ser una gran ventaja, aunque la infraestructura no siempre juega a nuestro favor.
5. Provee un plugin para Eclipse con el fin de evitar el uso de la consola de administración para desarrollar.
6. Soporta alto rendimiento o Performance y Escalabilidad ilimitada. Es aquí donde se facilita el proceso de agregar software para soportar mayor volumen sin tener que modificar otras capas.
7. Provee un mecanismo configurable de caché, lo que ayuda a eliminar invocaciones innecesarias a servicios web, disminuyendo tiempos de respuesta y tráfico de red.
8. Soporta el estilo de servicios REST, ya sea para crearlos completamente con ésta arquitectura o transformar servicios SOAP existentes. Si les interesa como realizar dicha transformación, en este post explico los pasos para hacerlo.
9. Tiene la habilidad de procesar mensajes de gran tamaño, aplicando técnicas tales como el  Preprocess Parsing o Split.
10. Transformación de datos de manera dinámica usando estándares como XSLT, XML, XQuery y XPath.
11. Virtualización de servicios.
12. Soporta balanceo de carga. Si se tienen disponibles varios endpoins de un mismo servicio web, es posible agregarlos y especificar el algoritmo de distribución de carga en el Business Service. Detecta automáticamente cuando ocurre una falla en uno de ellos y lo elimina de la lista para evitar invocaciones a un url no disponible. Esto es muy útil si no se dispone de un balanceador aparte.
13. Soporte de protocolos HTTP, HTTPS, JCA, JMS, SB y WS.
14. Provee una serie de adaptadores listos para usarse, compatibles con el estándar JCA 1.5, mismos que encapsulan la complejidad de la integración de aplicaciones específicas, tales como bases de datos, sistemas legados, aplicaciones empaquetadas, mainframes, ERP, CRM, Archivos, FTP, Socket, JMS, MQ, entre otros. En mi opinión siempre es grato no tener que desarrollar adaptadores para cada sistema, la implementación se agiliza en gran medida.
15. Soporte para diversos encodings, como por ejemplo UTF-8, ISO 8859-1, etc. Es muy sencillo cambiar el encoding de cada servicio, incluso, es posible invocar un servicio con cierta codificación y exponerlo con una diferente.
16. Provee autenticación básica, autenticación usando certificados, autenticación en el header del mensaje o autenticación personalizada, además soporta los estándares de seguridad WS-RM y WS-Security.
17. Provee los algoritmos de selección Transport Header, SOAPAction Header, WS-Addressing, SOAP Header y SOAP Body Type para determinar la operación que se ejecutará.
18. Además de la forma estándar de comunicación de mensajes entre WebServices (WSDL), el OSB provee varios tipos de mensajes no XML de fuentes de datos como Archivos, EJB, FTP, MQ, JMS y Tuxedo.
19. Se alinea al modelo de gobierno SOA al proveer diversas capacidades, mencionadas en esta lista, además de la integración con Oracle Web Services Manager, Oracle Enterprise Repository, Oracle Service Registry y Oracle Enterprise Manager SOA Management Pack. Realiza la sincronización automática de los servicios en el Repository.
20. Incorporación de bajo riesgo a ambientes en la nube.

Bien, pues como verán, es una muy buena lista de monerías de la herramienta. Sin embrago, como en cualquier lenguaje, herramienta, arquitectura o framework, no todo es color de rosa. Así que no podemos dejar pasar de largo las implicaciones de su uso en el mundo real, y con base en mi experiencia puedo mencionar las siguientes:

1. La forma de desarrollo puede ser complicada si hay muchas personas involucradas y sobre todo si trabajan de forma colaborativa en un mismo proyecto o recurso. 
2. No provee un mecanismo de control de versiones (al menos hasta la versión 11g), lo cual implica que se tenga que realizar de forma externa y usando herramientas independientes. Es muy fácil arruinar los proyectos y si no se tienen respaldos, se pueden generar grandes pérdidas de tiempo y dinero.
3. El desarrollo de flujos en la consola de administración, en ocasiones, se torna frustrante por varios factores, uno de ellos es que un usuario solo puede abrir una sesión de edición a la vez, otro factor es que teniendo una sesión de edición abierta, no es posible probar los recursos usando la facilidad que provee la consola, entre otros pequeños detalles. Algunos de estos se mitigan usando el plugin de Eclipse, sin embargo instalarlo no es tarea fácil. Si les interesa como instalar la SOA Suite con el plugin para Eclipse, pueden checar este post donde explico el procedimiento. O bien, este otro post con ejemplos de uso una vez instalado.
4. Como toda herramienta en el mercado, está diseñada de cierta forma y tomando en cuenta requerimientos estándar del mercado, lo que se traduce en poca o nula flexibilidad para los casos no estandarizados o fuera del target.
5. Es una herramienta propiedad de un vendedor de tamaño mundial, lo que la convierte en un producto no accesible para todas las empresas por cuestiones de precio, infraestructura y requerimientos para su uso.
6. La expectativa de su uso es enorme y muchas veces irreal, debido a las promesas de los vendedores o el poco entendimiento de su funcionalidad. Los clientes creen que será fácil o que resolverá todos los problemas de manera transparente. La experiencia de quien diseña e implementa las soluciones determina, en gran medida, la complejidad y se define si se explotan a favor del proyecto todas las bondades que provee la herramienta, siendo a veces, sujeto de malas interpretaciones el desempeño, a causa de un mal diseño.
7. Las integraciones con otros productos de Oracle es relativamente sencilla, si el objetivo es integrarlo con productos de diferentes vendedores, es probable que se torne muy complicado o incluso no viable.

Creo que con estos puntos basta para dar un panorama un poco más amplio del uso de un Enterprise Service Bus. En lo particular, soy y siempre he sido, partidaria de lenguajes más abiertos como java, y si me preguntan hay ocasiones durante el desarrollo usando OSB, que preferiría resolver los problemas usando puro java, y otras donde definitivamente amo el OSB y no lo cambio. Pero más allá de mi humilde opinión, en definitiva es una buena práctica usar arquitecturas estandarizadas y robustas, no solo por implementar buenas prácticas o por moda, sino porque el desarrollo se ve beneficiado al disminuir tiempos.

Espero que esta explicación sea de utilidad.

¡Nos leemos la próxima vez!