Ir a Tecsisa.com
8may/10

¿Por qué un Enterprise Service Bus (ESB)?

Se ha hablado mucho en los últimos años sobre los ESB, los web services y el fenómeno SOA en general. Gartner pronosticó que SOA sería usado en más del 80% de los procesos de negocio y aplicaciones críticas que se desarrollen en 2010. Estamos en 2010 y mi percepción es que, al menos en España, aún no hemos llegado a esos porcentajes en lo que se refiere al despliegue de soluciones SOA. Lo que sí es cierto sin embargo es que el ascenso de SOA y los ESB como solución tecnológica parece imparable en la mayoría de organizaciones y sectores.

Cuando una tecnología o un cierto paradigma se pone de moda, como ocurre con SOA, tenemos que mantenernos alerta ante la tentación de aplicarlo sin más en el contexto de mi negocio sin preguntarnos si es realmente lo que necesitamos. SOA implica analizar globalmente las necesidades del negocio para dar una respuesta tecnológica coordinada, reutilizable y que permita por tanto ahorrar en costes de desarrollo. Implica pensar en la evolución tecnológica de mi organización en el medio y largo plazo evaluando cuáles son mis necesidades de negocio actuales y cuáles serán en los próximos 10 o 20 años. Si nuestra única preocupación es el corto plazo, probablemente debamos considerar enfoques de desarrollo más tradicionales, que aunque resulten menos escalables, nos darán una respuesta rápida a los retos de hoy.

Enterprise Application Integration

Dicho esto, hay que hacer notar que la complejidad de las organizaciones es cada vez mayor. Caminamos hacia un modelo de organización sin barreras que se comunica a través de distintos canales de información y datos sobre un conjunto heterogéneo de sistemas de información operacionales que deben permanecer integrados para dar una respuesta conjunta a las demandas del negocio. No obstante, cada departamento o equipo de trabajo debe poder evolucionar tecnológicamente acorde a sus propias necesidades sin limitaciones impuestas por la visión integrada de la organización. Los responsables de sistemas de información deben pues asumir que es necesario mantener intacto el doble compromiso de evolución tecnológica para el negocio y la integración de los sistemas.

No es posible tener un único super-sistema operacional, pero igualmente, los sistemas no pueden permanecer aislados. Necesitan por un lado ser autónomos y por otro lado permanecer federados. Pensemos por ejemplo en el negocio sobre Internet o cloud computing. Es verdad que hoy en día es posible comunicar espacios de trabajo sobre redes WAN o VPN pero cada vez es más necesario poder establecer dichas comunicaciones más allá del firewall por ejemplo con partners o proveedores. Para un administrador de sistemas puede resultar un verdadero reto pasar a través del firewall cualquier protocolo y formato. Ante este escenario, se demandan nuevas soluciones tecnológicas que permitan la ubicuidad del negocio sin comprometer cuestiones como la seguridad o la calidad del servicio (QoS).

La competitividad y los nuevos retos del negocio hacen indispensable la innovación tecnológica. La innovación se traduce en la proliferación de sistemas de información que a menudo degenera en un estado de entropía tecnológica. La respuesta ante dicha entropía no puede ser la renuncia a la innovación sino que debe dar pie a abordar seriamente el problema de la integración de los nuevos sistemas con los sistemas legados, lo que se denomina comúnmente EAI o Enterprise Application Integration.

El EAI es el intercambio sin restricciones de datos y  procesos de negocio entre cualquier aplicación y fuente de datos existente en la empresa. A un nivel básico, las arquitecturas de integración inicialmente implementadas en la empresa han sido:

  • Punto a Punto: cada par de sistemas se integran atendiendo únicamente a sus requerimientos particulares. FTP, RMI o Remoting han sido protocolos típicamente empleados en llevar a cabo este tipo de integración.
  • Base de Datos: a un nivel muy simple, una base de datos puede establecerse como unidad central de intercambio de datos entre sistemas e implementar por tanto un modelo de integración básica.

Estas dos arquitecturas, probablemente por su simplicidad y bajo coste aparente, siguen siendo hoy día la respuesta mayoritaria al problema de la integración en la empresa. Sin embargo, a medida que la complejidad tecnológica aumenta y las integraciones punto a punto se suceden, se evidencia una necesidad de mantenerlas controladas, administradas y gestionar su aprovisionamiento. Para atender a esta necesidad, se han sucedido nuevas respuestas al problema de la integración necesariamente más sofisticadas y ambiciosas:

  • Hub-and-Spoke: todos los sistemas se conectan a un punto central o hub como en el caso de Microsoft BizTalk. A diferencia de la integración punto a punto, los sistemas se conectan al hub a través de conectores ligeros muy independientes de la tecnología particular de cada solución. El problema es que este punto central se convierte en extremadamente importante para la organización. Un fallo en el hub podría comprometer todos los procesos de negocio de la empresa.
  • Enterprise Message Bus o broker de mensajes: en este caso no hay un punto central sino que los conectores están desacoplados gracias al intercambio de mensajes a través de un broker como el de IBM Websphere MQ (WMQ), Microsoft MSMQ o Apache ActiveMQ.

Enterprise Service Bus

Finalmente, comentaremos la arquitectura que se está imponiendo y que podría decirse resulta la más fiel implementación de SOA: el ESB o Enterprise Service Bus.

Un ESB parte de la idea de desacoplamiento introducido por el broker de mensajes incorporando una definición abierta de la forma de integración entre consumidores y publicadores de servicios. Un ESB usa WSDL y XML, estándares abiertos e interoperables, sobre una capa de transporte, típicamente HTTP. De esta manera los conectores no definen la implementación sino la capa de transporte y una interfaz de servicio. En el caso de un broker de mensajes los consumidores y publicadores de servicios asumen cierto conocimiento sobre los tipos de mensajes intercambiados y la tecnología empleada como es el caso de JMS o MSMQ.

Por consiguiente, un ESB puede distribuirse a lo largo de la organización, no necesitando un punto central de integración, y permitiendo la interoperabilidad entre sistemas implementados en las más diversas tecnologías. Las características básicas que debe presentar un ESB son las siguientes:

  • Enrutamiento y redireccionamiento de mensajes.
  • Estilo de comunicación síncrono y asíncrono.
  • Multiplicidad de tipos de transporte y protocolos de enlace.
  • Transformación de contenido y traducción de mensajes.
  • Orquestación y coreografía de procesos de negocio.
  • Procesamiento de eventos.
  • Presencia de adaptadores a múltiples plataformas.
  • Herramientas de diseño de la integración, de implementación y despliegue.
  • Características de garantia de la calidad del servicio (QoS), como transaccionalidad, seguridad y persistencia.
  • Auditoría, registro y métricas.
  • Gestión y monitorización.

Como ejemplos de ESBs podemos nombrar Sonic ESB, Oracle Enterprise Service Bus,  como ESBs comerciales, y Apache ServiceMix o Mule como implementaciones open source. El caso de ServiceMix es especialmente interesante por su alto grado de adecuación a estándares, sumando a los propios de un ESB como XML y WSDL, otros propios del universo Java como JBI (Java Business Integration) y OSGi.

Conclusión

La necesidad de un ESB surge de la complejidad de las organizaciones que deben coordinar e integrar sus procesos de negocio, sistemas operacionales y datos sin renunciar a la innovación tecnológica imprescindible para ser competitivos. Un ESB es la implementación de SOA, una arquitectura que permite mantener integrados los sistemas, nuevos y legados, en un estilo completamente distribuido e interoperable.

avatar

Acerca de

Juan José Vázquez es arquitecto de software y consultor en nuevas tecnologías, principalmente en el área de SOA y tecnologías open-source. Desde 2005 es socio de Tecsisa.
Comentarios (39) Trackbacks (4)
  1. Tengo algunas dudas que deseo compartir:

    1- Es necesario que las aplicaciones esten enfrascadas en una arquitectura orientada a servicios para que conectarlas al esb?
    2- Las aplicaciones se conectan al ESB a traves de los servicios web que ellas exponen?
    3- En caso de que una aplicacion no exponga sus funcionalidades a traves de servicios web, como se podria conectar al bus?

  2. Hola Dalila,

    Un ESB típicamente dispone de un amplio rango de conectores dependientes de la capa de transporte pero no de la capa de servicio. Esto te permite conectar tus aplicaciones y servicios a través de HTTP, JMS, File, FTP, SNMP, Jabber, etc.

    La forma más eficiente de conectar un sistema legado con el ESB suele ser la publicación de algún web service, o bien, a través de mensajería asíncrona sobre un broker de mensajes. Sin embargo, puede llegar a ser tan simple como que tu aplicación deje un fichero plano en una cierta ubicación monitorizada por el ESB. FTP podría ser también la opción en el caso de que tu aplicación no exponga web services.

    Si no tienes forma de evolucionar tu aplicación para hacer posible la integración, siempre es posible crear un servicio web, publicado en el ESB y que acceda a la base de datos de tu aplicación.

    Por último, para el caso de grandes sistemas legados, ERPs o CRMs, los ESB suelen permitir conectar a ellos a través de JCA.

    Espero haberte ayudado.

    Saludos,

    Juanjo.

  3. Muy buenos artículos. Estoy usando JBossESB, ¿alguna opinión sobre el mismo?

  4. Hola Gorlok,

    En el mundo open source JBossESB es una muy buena opción con una comunidad activa e interesante. Quizá se echa de menos la adecuación al estándar JBI, característica que sí está presente en Apache ServiceMix y Glassfish ESB, y que permite la reutilización de componentes independientemente del ESB concreto que se utilice.

    Tengo entendido que está en el roadmap de nuevas características.

    Saludos,

    Juanjo.

  5. Pero… GlassFishESB sigue vivo?…lo digo porque desde que Oracle adquirió Sun la página del proyecto Fuji está muuuuuy parada :-|… hace como tres meses que iba a salir la esperada versión 3.0 del GlassFishESB y no hay indicios de vida en las webs de GF.

  6. Hola Pablo,

    Efectivamente el futuro de Glassfish ESB está comprometido desde la compra por parte de Oracle. Es de esperar que Oracle centre sus esfuerzos en la Oracle SOA Suite pudiendo incorporar algunas de las ideas valiosas del proyecto Glassfish. Por otra parte, al tratarse de un proyecto open source, la supervivencia del proyecto depende de la comunidad de desarrolladores. Esperemos que así sea.

    Afortunadamente existen otras posibilidades interesantes en el mundo de los ESB open source como Apache ServiceMix y Mule.

    Saludos,

    Juanjo.

  7. Muchas gracias Juan José por aclarar lo del GlassFish…tenían buena pinta las versiones 2.x… y dudo que veamos la luz de la 3 algún día… una pena. Eso sí la verdad es que GF era bastante “monstruo” a la hora de consumir recursos, la última implantación que hice empezaba en los 200Mg y llegaba sin motivo aparente a lo 600Mg en un día (y sólo tenía desplegados un par de servicios!!!!).

    Después de mi terrible decepción con el GF he estado trasteando con el Mule… y la verdad es que tiene una pinta increíble… no sé si lo conoces, lo has usado o evaluado… creo detectar que te decantas mas por el ServiceMix… y me gustaría saber qué opinión tienes del Mule (sobretodo… los puntos negros :-) ).

  8. Mule se está convirtiendo efectivamente en una de las opciones preferidas en el mundo de los ESB open source. Frente a ServiceMix, creo que cuenta con la ventaja de tener una mejor documentación oficial y un sitio web más orientado al marketing de producto. Por otro lado, me parece una desventaja que no esté sujeto al estándar JBI, como sí lo está ServiceMix, y por tanto pueda promocionar en cierto sentido el caos en los componentes y mensajes que se desplieguen sobre la plataforma.

    Tienes razón en que me decanto más por ServiceMix por su alta adecuación a estándares, por su agilidad y ligereza, y por la altísima calidad del código y en general de la solución tecnológica.

    Me consta que el equipo de desarrollo va a centrarse para la próxima versión en mejorar la documentación y las capacidades de despliegue en entornos heterogéneos.

  9. Que ESB es mas eficiente que otro o mas completo? en cuanto a características? ya que si bien hay un montón de características básicas, algunos deben cumplirlas a mayor cabalidad, existe algún tipo de ranking asociado o siempre depende del problema a resolver?.
    Saludos!

  10. Mauricio, el tema de la eficiencia es un topic complejo y depende de muchos factores sobre todo si hablamos de proyectos de integración. Normalmente los criterios utilizados para estudiar la eficiencia en un ESB van en la línea de medir el número de mensajes que es capaz de procesar, pero como podrás entender, depende mucho de las condiciones de contorno.

    Por otra parte, las soluciones basadas en un ESB dependen mucho también del broker de mensajes que se utilice y en gran medida el rendimiento general de la solución depende de este factor.

  11. Juan José, me gustaría saber como se podría implementar ESB en una arquitectura logica de tres capas (presentación, negocios, datos), he visto información donde la capa de negocios se “transforma” en SOA donde contrendría el ESB y la capa de aplicación en la cual irían los servicios necesarios, quedando la suiguiente arquitectura: presentación, ESB, aplicación y la capa de datos, me gustaría saber tu opión acerca de lo comentado anteriormente y que me pudieras guiar según tus conocimientos en el tema.

    Muchas gracias

  12. Hola Juanjo, gracias por la explicación, ya entendi todo lo relacionado con el ESB, pero cual es la principal diferencia entre el EAI y el ESB??
    Porque a mi entender tanto el EAI como el ESB son tecnologias de integración de aplicaciones, el ESB permite integrarlas a traves de estandares y el EAI no lo hace también.

    Espero que me puedas ayudar con esta inquietud.

    Saludos Dalila

  13. Hola Juan,

    Realmente la división típica en 3 capas lógicas, presentación, lógica de negocio y acceso a datos, es independiente de usar un ESB e incluso de seguir un enfoque SOA. Es decir, en una arquitectura SOA efectivamente podrías tener servicios dedicados de presentación, lógica de negocio o acceso a datos, pero también podrías tener servicios que cubrieran más de una capa e incluso las 3. La clave está en escoger la granularidad adecuada para tus servicios.

    Dicho esto, personalmente la arquitectura que más me gusta contendría los siguientes elementos:

    * Servicios de presentación: pueden o no “vivir” en el ESB y típicamente seguirían un enfoque RESTful intercambiando XML o JSON.

    * Servicios de negocio: estarían alojados en el ESB y deberían seguir un enfoque SOAP para garantizar que tenemos disponible todo el arsenal de extensiones WS-*.

    * Servicios de datos: en principio no me gusta la idea de tener servicios de datos accesibles desde el exterior del ESB. No obstante, si tu ESB soporta el estándar OSGi por ejemplo, puedes crear servicios OSGi para el acceso a los datos. Estos servicios serían accesibles sólo desde el interior del ESB y no externamente.

    Por otra parte, la coreografía u orquestación de servicios que tuvieras que hacer se desarrollaría en el ESB e involucraría servicios de negocio que a su vez harían uso de los servicios OSGi de acceso a datos.

    Espero que te ayude en algo mi respuesta.

    Saludos,

    Juanjo

  14. Hola Dalila,

    La integración de aplicaciones empresariales (EAI) es más una necesidad que una tecnología. Un ESB sin embargo sí es una tecnología que permite implementar soluciones con arquitecturas orientadas a servicios (SOA).

    En relación con EAI, un ESB permite satisfacer las necesidades de integración de aplicaciones en una organización, pero no sólo éso. Un ESB permite también la coreografía y orquestación de procesos de negocio (BPEL) es un entorno altamente distribuido.

    Es decir con un ESB puedes tener EAI y mucho más. La confusión de relacionar EAI con una tecnología proviene de la generación anterior de productos de integración de sistemas que se autodenominaban como “productos EAI”.

  15. Hola Juanjo, muchas gracias por la explicación anterior pero para adoptar en una empresa una solución EAI es necesario preparar las aplicaciones existentes para que hablen entre ellas, es decir, prepararlas para que puedan establecer una comunicacion mediante mensajes???
    Porque actualmente se tienen aplicaciones que no se comunican y es necesario establecer esa comunicacion para responder a determinados procesos de negocios, pero como hago para que una aplicacion que ya esta desarrollada se pueda comunicar con otra en una solucion EAI mediante mensajes????

    Espero que hayas entendido la duda que tengo y que me puedas ayudar a resolverla.

    Saludos Dalila

  16. Hola juan josé,
    Para ti cuales son los requerimientos mas importantes que se necesitan a la hora de escoger un ESB open source?

    Muchas Gracias

    Egael

  17. Hola Dalila,

    En una arquitectura de integración orientada a mensajería asíncrona, pueden establecerse básicamente dos patrones: la integración punto a punto y el patrón publish/subscribe.

    En el primer caso un cliente escribe un mensaje en una cola especialmente destinado para un servidor. El servidor procesa el mensaje y típicamente escribe un mensaje de respuesta en la misma cola u otra destinado al cliente que originó la petición.

    En el segundo caso, un cliente escribe un mensaje en un cola (en este caso se suele denominar topic) y varios “suscriptores” reciben dicho mensaje publicando o no una respuesta.

    Como puedes comprobar, en ambos casos tanto clientes como servidores deben tener la capacidad de escribir y leer mensajes de colas y topics. Por ejemplo, en Java esto se realiza haciendo uso uso del api de JMS. Si tus aplicaciones no poseen esta característica deben adaptarse para hacer posible este tipo de integración.

    Espero que te sirva de ayuda.

    Saludos,

    Juanjo.

  18. Hola egael,

    Como comento en el post, existe un conjunto de características básicas que debe cumplir un ESB. En el caso los ESB open source, es deseable que cumplan la mayor parte de estas características, y las que falten deberían ser compensadas bien con otras herramientas, open source o no, o bien por desarrollos propios.

    Sumado a esto, es importante valorar el prestigio de la comunidad de desarrolladores que sustenta el proyecto, por ejemplo la Apache Software Foundation es sinónimo de calidad. Por otra parte, hay que tener en cuenta si existen empresas que puedan dar soporte del ESB. Esto es especialmente importante en ámbitos corporativos. Por último, es aconsejable no embarcarse en proyectos clave para el negocio con las primeras versiones de un producto. En caso de duda, hacer un piloto con una aplicación pequeña con pocos requerimientos y casos de uso.

    Saludos,

    Juanjo.

  19. Hola Juanjo, ya entendi lo de las colas y los topics, pero en tu respuesta me dices que si mis aplicaciones no poseen la característica para enviar y recibir mensajes, entonces es necesario adaptarlas para hacer posible este tipo de integración. Mi pregunta es, como adapto las aplicaciones tanto adquiridas por terceros como las implementadas por mi para enviar y recibir mensajes??

  20. Hola Dalila,

    Para responder a tu pregunta necesitaría conocer más detalles sobre la tecnología con la que están desarrolladas las aplicaciones que deseas integrar: Java, .NET, legacy, etc.

    Saludos,

    Juanjo

  21. Hola Juanjo, tengo aplicaciones desarrolladas en java, .Net y también tengo aplicaciones legadas. Cómo las preparo para que puedan enviar o recibir mensajes o es que el software EAI que adquiera ya brinda la posibilidad de preparar las aplicaciones para este tema de los mensajes.
    Te hago estas preguntas porque estoy haciendo una tesis referente al tema de EAI y necesito dejar claras muchas cosas para el momento de defender que todo pueda quedar bien explicado y sin dudas. Además que tengo que hacer un caso de estudio donde se refleje la integración de varias aplicaciones.

    Gracias de antemano

  22. Dalila, mejor dile a Juan Jose q te haga tu tesis y le das una lana.

  23. Hola amigo:
    Me gustaría reutilizar un pequeño ESB para instalarlo en mi escuela porque hay muchas aplicaciones dependientes de servicios publicados en direcciones diferentes, me pudiera recomendar algún ESB que yo pueda utilizar para organizar y orquestar todos estos servicios, muchas gracias de antemano, salu2.

  24. Amigos, mi pregunta es: Microsoft BizTalk 2009 o 2010 es un ESB?. y cual ESB es bueno para aplicaciones .Net.

  25. Hola Juan, me gustaría compartir unas inquietududes con usted, tengo un sistema que accede a datos a través de EJB y las aplicaciones acceden a estos EJB a traves de ws y estoy pensando introducir un ESB para direccionar estos ws y así establecer la comunicación con el contenedor de ejbs, además necesitaría mantener transaccionalidad de webservice delegando esta funcionalidad al ESB y no al servicio web, ¿me podría indicar decir los ESBs más adecuados para esto que le comento y además soporten el estandar OSGI?

    Gracias y un saludo.

  26. Hola juan , me gustaria saber como puedo publicar un servicio web en Oracle service Bus

  27. Que tal Juan, interesante post, que me podrias decir de BiztTalk? Muy particularmente me gustaria conocer tu opinon sobre que tan robusto y potente es, asi como su nivel de concurrencia soportada?

    Gracias

  28. Estoy haciendo una asignatura que habla del ESB. Como no soy un entendido del tema me he dirigido a Wikipedia pero no me he enterado de nada. He leido tu articulo y sigo igual. Me lo puedes explicar para tontos y con algún ejemplo?
    Gracias.

  29. Hola,
    Una consulta, estoy usando el Oracle Soa Suite y necesito saber si es posible ,manejar transaccionalmente el proceso en un ESB. Si ocurre un error debería efectuar un rollback a los sistemas afectados, es posible esa funcionalidad?

    Gracias,

  30. Que tal Juan Jose:

    Por lo que entiendo de lo que es un ESB es un conglomerado defuncionalidades, por ejemplo en el caso de IBM seria “IBM – WebSphere Application Server – Software”, “WebSphere Process Server – IBM” y “IBM – WebSphere Message Broker – Software”, que esto al final dan como resultado un ESB, ¿Es correcto esto que estoy diciendno?

    Saludos.

  31. Buenas!!

    Simplemente preguntarte que opinión te merece WSO2 ESB, he estado realizando pruebas y tiene muy buena pinta, sobre todo la facilidad que ofrece su consola de administración.

  32. Hola Buenas tardes,

    una consulta, cuál podría ser la influencia en el acoplamiento de la arquitectura de las técnicas de integración?

    Gracias

  33. Hola,

    Les recomiendo GreenVulcano ESB: gratis, fácil y completo.
    http://www.greenvulcano.com

  34. Hola Juan,

    Se puede usar el Apache ServiceMix en empresas bancarias. Sè que se utiliza con frecuencia tecnologia de IBM. Se Podria proponer el ServiceMix como soluciòn?

    Saludos

  35. Hola…
    Suponga que entidades externas (consumidores de servicio fuera del ambito de la empresa) quieren consumir servicios del ESB de la empresa ABC… ¿Ellos , las entidades externas, deberian consumir los servicios haciendo llamadas directas al ESB de ABC?

  36. hola,

    Alguien ha trabajado integración de SAP con sistemas legados? que herramientas han utilizado? PI sería una opción del mismo fabricante ? como se compará con estas otras herramientas del mercado por ejemplo con Apache Service Mix ?

    gracias
    Martha

  37. Estimado.
    Primeramente muy buen aporte sobre el Uso de ESB y felicitaciones por el blog. Tengo dos preguntas si yo utilizo un esb y se supone que todos los servicios estan alojados ahi en el caso de Web Services yo tengo que hacer clientes apuntando a los servicios del ESB?.

    Y la otra en este caso en ESB que se va a utilizar es JBOSS FUSE adicionalmente se necesita otro servidor de aplicaciones para alojar la aplicación WEB que consumira los servicios del ESB es decir en total srian 2 1 del ESB y otro para la aplicacion que consume?

    De antemano gracias

  38. se murio juanjo XD


Deja un comentario