¿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!






















Comentarios

  1. Respuestas
    1. Que tal Marco. Muchas gracias. Un saludo!

      Eliminar
  2. Hola Sandra.
    Ultimamente ya no te veo por aquí, espero que sigas posteando.

    ResponderEliminar
    Respuestas
    1. Hola Freddy,

      Acá sigo, desafortunadamente ocupada hasta el full, ya sabes proyectos absorventes, cursos, planes, etc.

      Pero no me olvido de este post. Estoy preparando un curso básico de SOA para impartirlo a algunos de mis clientes y colegas, muy pronto pondré el temario para ir descubriendo poco a poco los que son de interés público y postearlos.

      Te agradezco la atención, un saludo!

      Eliminar
  3. Respuestas
    1. Gracias a ti Alejof por tu comentario y tu tiempo para leerlo.

      Saludos!

      Eliminar
  4. Hola Sandy, no me queda claro que es lo que hay dentro del BUS, una base de datos con la información? archivos XML con la informacion? Ojala me puedas aclarar la duda. Saludos y excelente post.

    ResponderEliminar
    Respuestas
    1. Hola Raúl.

      No me queda claro a que información te refieres. Dentro del bus no hay una base de datos, en el caso de la SOA Suite de Oracle existe una pero para soportar la operación de la plataforma y para compartir recursos entre proyectos (MDS) pero nadamás. El Bus es un medio por el cual se intercambian mensajes (peticiones a Servicios), pero no se guardan datos (ni deberían) de sesión, de usuarios, etc. Es únicamente un proxy que puede tener reglas de enrutamiento, transformación, validación de mensajes de entrada y salida y algunos flujos y operacioens simples.

      Espero que esto responda tu pregunta.

      Saludos

      Eliminar
    2. Si se usa el JMS Reporting en los proyectos (elemento Reportado), entonces si se usa BD y por ende si es posible ver dicha información que requieras de tus flujos en consola web de OSB y bajo otras consideraciones más.

      Eliminar
  5. Hola, muy buen post.
    Ahora estoy trabajando con OSB y necesito conectar mi aplicación móvil que hice con PhoneGap al bus pero no se como, me puedes ayudar, por favor!!!!. Antes la aplicación se conectaba a unos servicios web en asp.net y lo hacia a través de ajax, será que puedo conectarme al el osb con ajax?.
    Muchas gracias!! espero tu respuesta.

    ResponderEliminar
    Respuestas
    1. Hola María Isabel!

      Definitivamente puedes invocar servicios web que estén en OSB usando ajax, dada la naturaleza de tu aplicación móvil, se sugiere que éstos sean de tipo REST, si tienes la versión 12c esto es muy sencillo, si no, tendrías que implementar varias cosas para convertir los mensajes y protocolo.

      Más allá de eso, sería bueno entender porqué quieres ahora usar OSB en vez de ir directamente a tus servicios asp.net. Cuál es tu requerimiento, lineamiento o etc para justificar OSB? Recuerda que las arquitecturas SOA deben tener un sentido más allá de solo una imposición o adopción de herramientas/plataformas.

      Saludos!

      Eliminar
    2. Hola Sandy, Buen día.

      Actualmenete me encuentro realizando un trabajo instrumental de grado en una empresa. Una de las principales razones para usar el OSB es por la virtualización de los servicios que requiere dicha empresa. Te agradeciería mucho si me puedes ayudar con el problema, eso es lo único que le falta a mi proyecto, que la aplicación consuma los servicios del osb. La versión que uso es 11g.
      Será que me podrías explicar como hago en esa versión para trabajo los servicios tipo REST y hacer lo que mencionas, por favor y muchas gracias!!
      Por otro lado quiero agradecerte, tus post me han ayudado mucho a lo largo de todo mi proyecto, la verdad es que son excelentes, te felicito!!!

      Eliminar
    3. Buen día!

      Ok, entiendo... aquí puedes encontrar el tutorial para hacer la conversión de SOAP a REST y los puedas usar en tu aplicación

      https://desarrolloconsoa.blogspot.mx/2013/07/conversion-de-servicios-soap-restjson.html

      Espero te sirva. De igual forma, si te es posible aconsejarles hacer el upgrade a la versión 12, será mucho más fácil esto y otras cosas que tengan que resolver más adelante.

      Saludos!

      Eliminar
    4. Hola buen día. Muchas gracias por responder, intentaré hacerlo y probar si me funciona. Aunque tengo una duda si no hago la transformación e intento consumir los servicios del bus como SOAP, ¿La invocación desde el ajax igual me deberia funcionar?. Es que estuve intentando consumir dichos servicios desde ajax y no obtuve ninguna respuesta a cambio, el código que utilice fue este:

      conectar = function () {
      var datos = ''
      + ''
      + ''
      + ''+$('#usuario').val()+''
      + '' + $('#clave').val() + ''
      + ''
      + ''
      + '';
      $.ajax({
      url: "http://10.0.0.191:7001/OSBCapled/Proxy_Services/AutenticacionWS",
      type: "POST",
      crossDomain: true,
      data: datos,
      cache: false,
      dataType: "xml",
      contentType: "text/xml",
      success: function (data) {
      alert(data.responseText);
      },
      error: function (data) {

      alert("Error: ");

      },
      });
      }
      La url, es la del osb.

      Además necesito que me devuelva la respuesta en xml, no se si algo estoy haciendo mal, porque no me devuelve nada.

      Eliminar
  6. Hola buen día.
    Muchas gracias por la ayuda ofrecida!!

    Hice lo que dice el post pero al intentar llamar al OSB desde ajax me sale este error: "Not connect: Verify Network". Platicando en otros foros me dicen que es porque tengo que habilitar CORS. ¿Eso es cierto?, ¿Es necesario?, ¿Y si es necesario, Cómo habilito CORS en weblogic?.

    Muchas gracias, por tu tiempo y dedicación!!!

    ResponderEliminar
  7. Buenos días Sandy, en mi empresa se quiere implementar la política de que todas las integraciones entre aplicaciones se hagan por medio del Bus SWO2, pero quisiera saber en qué caso es recomendable usar un Bus y en qué caso no. También me gustaría saber si tú en tus experiencias has encontrado si esto tiene alguna afectación en el rendimiento de las integraciones.

    Agradezco tu respuesta... Saludos!

    ResponderEliminar
    Respuestas
    1. Hola, disculpa por el tiempo de respuesta.

      Mira, en mi opinión usar el Bus te brinda ciertas ventajas de abstracción, estandarización, centralización, etc. Pero también es una capa donde, dependiendo de las capacidades de tu herramienta, puedes agregar seguridad a tus servicios, políticas, restricciones de contratos, transformación de protocolos, entre otras cosas, dado que realiza las funciones de un proxy, éste cumple con dicha función, proteger a tus servicios implementados en otras plataformas, lenguajes, servidores, aplicaciones, etc y no solo se limita a ser una capa de integración.

      Si tus necesidades actuales no lo justifican, debes pensar en un futuro a mediano plazo, las tendencias de aplicaciones móviles y multicanal, son muy demandantes en cuestiones de seguridad y protocolos, lo que antes tenías en aplicaciones autocontenidas por medio de servidores, en ambientes de servicios distribuidos tienes que implementarlo manualmente, aquí es donde el Bus juega un papel muy relevante.

      En lo personal creo que no hay forma de decir cuando si y cuando no, a menos que se analice bien el negocio y la funcionalidad, pero lo que si te puedo decir es que no estoy de acuerdo con que los servicios sean expuestos de forma vulnerable, incluso si tienes una DMZ, red privada y canales seguros, siempre habrá forma de invocarlos por clientes externos a tus apps (SOAP UI por ejemplo), y brincarte ciertos mecanismos de autenticación y/o suplantación de identidad, si usas un Bus robusto, podrías protegerlos de estos gaps por ejemplo.

      Espero que esto te ayude un poco.

      Saludos!

      Eliminar
  8. Buenos días Sandy, en mi empresa se quiere implementar la política de que todas las integraciones entre aplicaciones se hagan por medio del Bus SWO2, pero quisiera saber en qué caso es recomendable usar un Bus y en qué caso no. También me gustaría saber si tú en tus experiencias has encontrado si esto tiene alguna afectación en el rendimiento de las integraciones.

    Agradezco tu respuesta... Saludos!

    ResponderEliminar
  9. Excelente Post, muy entendible, felicidades !

    ResponderEliminar
  10. Hola Sandra, gran facilidad para exponer conceptos, gracias.
    Estoy aprendiendo y quisiera hacerte algunas preguntas.
    - Entre dos Web Services que comunican sin ESB la conexión es punto a punto, si por el contrario, en medio de los dos servicios instalo un software que funcione como Services Registry para la discovery de los servicios obtengo dinamismo , bajo acoplamiento y escalabilidad, porque el servicio A no conoce directamente el sevicio B, el servicio A le pide al Service Registry la dirección y puerto del Servicio B. En este tipo de escenario que tipo de concepto ESB me estoy perdiendo? puedo obtener una arquitectura SOA sin el ESB?.
    - Si uso un ESB entre Web Services, los mensajes viajan físicamente a través del ESB o el ESB funciona solamente como Service Registry?. Si los datos viajan a través del ESB podemos afirmar que aumenta la latencia?
    - Porque centralizar la seguridad en el ESB no es mas adecuado que cada End Point de un Web Services gestione la seguridad de acceso a sus propios recursos? Por ejemplo si tengo un Web Service que usa el standar JWT, no comprendo porque agregar un layer adicional (ESB) que aumente la complejidad.
    - Cuando intento aferrar mejor el concepto de que es un ESB no logro evitar de asociarlo a un message broker, cuales son las reales diferencias?

    Gracias por el tiempo que puedas dedicar a responderme.

    ResponderEliminar

Publicar un comentario

Entradas más populares de este blog

OWSM and WS-Security: Username Token Authentication for SOAP and REST Services in OSB 12c.