SOA está basado en estándares. Un ESB soporta estándares basados en la integración de sistemas distribuidos. Un ESB debe ser más distribuido que un broker EAI que centraliza la integración de distintos sistemas utilizando adaptadores propietarios y flujos de mensajes. Además, un ESB debe ser un intermediario de servicios que posibilita un conjunto de patrones tales como enrutado de mensajes y transformaciones de esquemas.

Los EAI suelen tener una arquitectura hub-and-spoke. Los ESB (salvo los que han evolucionado como tal a partir de un EAI) buscan un modelo federado donde multiples nodos tienen el conocimiento sobre como enrutar y transformar los mensajes.

¿Qué os parece? ¿Estais de acuerdo?

Además, por parte de Oracle se continuará dando soporte a los productos de BEA que estén adquiridos, sin obligación de migración de los mismos por parte de los clientes.

Lo primero que resulta de esta fusión, es el Oracle Technology Network, resultado de las comunidades online de Bea (Dev2Dev) y de Oracle (Oracle Java Developer Community).

A nivel de productos, Oracle va a buscar completar una suite lo más extensa y perfecta posible en lugar de una estrategia de productos separados.

1. A nivel de SOA, según el Roadmap del producto, se distinguen 3 categorías:
   • Productos estratégicos : Productos de Bea que serán integrados directamente en Oracle Fusion Middleware, en un periodo máximo de 12-18 meses. Aquí se incluyen :
     • Oracle Data Integrator para integración de datos y ETL batch.
     • Oracle Service Bus, que unifica AquaLogic Service Bus y Oracle Enterprise Service Bus.
     • Oracle BPEL Process Manager para orquestación de servicios e infraestructura de composición de aplicaciones.
     • Oracle Complex Event Processor para procesamiento de eventos en memoria, integrado con WebLogic Event Server
     • Oracle Business Activity Monitoring (BAM) para monitorización de eventos de negocio y KPIs de procesos.
   • Productos a continuar y converger : Productos de Bea que serán rediseñados e incrementados para integrar con la suite de Oracle en un desarrollo continuo y mantenimiento por al menos 9 años. Aquí se incluyen :
     • BEA Weblogic Integration que convergerá en Oracle BPEL Process Manager
   • Productos a mantener : Productos de Bea que se continuarán manteniendo por un periodo de 5 años pero que no se busca integrar en la suite de Fusion. Aquí se incluyen :
     • BEA Cyclone
     • BEA RFID Server
2. A nivel de BPM, se intentará dar soporte tanto a BPEL para la ejecución, como BPMN para el modelado. Según Oracle hay 4 tipos de procesos de negocio : centrados en sistema, en tareas humanas, en documentos y en decisiones. Este punto es muy importante, ya que en el caso del BPM la estrategia a seguir en cuanto a la gama de productos de ambas plataformas, será la siguiente:
   • Productos estratégicos :
     • Oracle BPA Designer para modelado y simulación de procesos
     • BEA AL-BPM Designer para modelado iterativo de procesos
     • Oracle BPM, que convergerá como resultado de BEA AquaLogic BPM y Oracle BPEL Process Manager en un único motor de ejecución
     • Oracle Document Capture & Imaging para captura de documentos y workflows documentales con integración ERP
     • Oracle Business Rules como motor de reglas de negocio.
     • Oracle Business Activity Monitoring (como BAM)
     • Oracle WebCenter como interfaz de portal para visualizar la composición de procesos.
3. A nivel de Portales y Enterprise 2.0 tenemos por parte de Bea los productos de Aqualogic UI y Weblogic Portal. La convergencia en este caso será la siguiente:
   • Productos estratégicos :
     • Oracle Universal Content Management como repositorio de gestión de contenidos, seguridad, publicación, imagenes, registros y archivo.
     • Oracle WebCenter Framework para desarrollo de portal y servicios Enterprise 2.0
     • Oracle WebCenter Spaces & Suite como entorno de portal empaquetado con servicios de computación social.
     • BEA Ensemble para ensamblado de portales ligeros basados en REST.
     • BEA Pathways para analisis de interacciones sociales.
   • Productos a continuar y converger :
     • BEA WebLogic Portal que será integrado en el Framework WebCenter.
     • BEA AquaLogic User Interaction (AL-UI) que será integrado en el WebCenter Spaces & Suite
   • Productos a mantener :
     • BEA Commerce Services
     • BEA Collabra
4. A nivel de Gobernabilidad SOA la estrategia de conversión será la siguiente:
   • Productos estratégicos :
     • BEA AquaLogic Enterprise Repository para capturar, compartir y gestionar el cambio de elementos SOA a través de su ciclo de vida.
     • Oracle Service Registry para el UDDI
     • Oracle Web Services Manager para seguridad y gestión de políticas QOS en servicios.
     • EM Service Level Management Pack como consola de gestión para los niveles de tiempo de respuesta de los servicios y la disponibilidad de los mismos.
     • EM SOA Management Pack como consola de gestión para monitorización, traceo y gestión del cambio SOA.
   • Productos a mantener :
     • BEA AquaLogic Services Manager

Podeis oir el webcast del evento en inglés, directamente en la página de Oracle, obtener más información de los productos en la página de Fusion Middleware o simplemente esperar al 8 de Julio, que será cuando se anuncie el roadmap aquí en España.

Fuentes :

BPMS Watch
Column 2 by Sandy Kemsley
BEA Welcome and Oracle’s Middleware Strategy Briefing

Cada una de las 2 aproximaciones tiene sus ventajas y desventajas:

• Si dejamos que cada departamento implemente su propio ESB; estaremos dando libertad para que cada uno adopte la solución que quiera; no obstante la comunicación entre varios dominios tendrá que ser establecida de manera explícita.
• Por el contrario, si utilizamos un único ESB; el control del mismo será único y todos los departamentos tendrán mayor rigidez a la hora de realizar sus integraciones o desarrollos; y además la comunicacion entre servicios interdepartamentales será casi nativo a la propia topología de un esb único.

En cualquier caso, el utilizar un único ESB no implica una anarquia en la utilización de servicios y la "no existencia" de bordes o límites entre departamentos. Normalmente, una aproximación de ESB único implica la creación de dominios y subdominios que establecen los límites del conjunto de servicios que expongan (tendremos servicios públicos a todos los dominios del ESB y privados para el propio dominio).

Cuando utilizamos registros de servicios, en el caso de ESB unificados, la sincronización entre registros (en caso de que existan varias instancias) es propia de este tipo de topologías. Si hablamos de buses diferentes; tiene que existir un proceso externo de sincronización (cuando sea necesario) o al menos el conocimiento de la existencia de diferentes registros (en un intento de favorecer la publicación y suscripción a servicios empresariales, para así buscar la reutilización como fin último de nuestros registros).
Incluso, cuando tratamos temas como el de la gobernabilidad es muy importante tener constancia de todos los posibles ESB que estemos utilizando (un cambio en un servicio de un ESB debe ser notificado a cualquier consumidor de otro ESB que pueda referenciarlo). Es por ello importante, definir los modelos de gobernabilidad que van a utilizarse, para asegurar siempre la consistencia y el conocimiento de la información que manejan.

A la hora de orquestar servicios con, por ejemplo, un motor BPEL, este necesita tener puntos de acceso a los servicios que utilice en cada uno de los buses de servicios que desee conectarse. Puede ocurrir, por ejemplo, que el motor BPEL esté integrado en el propio ESB (como por ejemplo ocurre en la especificación JBI en algunos casos) y eso facilite la orquestacion de servicios en un mismo ESB (en el caso de utilizar varios ESB, se deberán establecer gateways de comunicación entre ellos).
A raiz de esa comunicación entre buses es importante tener en cuenta la fiabilidad de las comunicaciones, ya que de utilizar buses independientes se deberán establecer métodos de comunicación que aseguren la fiabilidad de los mismos (siempre que sean necesarios y un simple protocolo http, por ejemplo, no sea suficiente).

La administración y la monitorización (BAM) en casos de buses unificados se simplifica ya que las consolas de administración están unificadas y, en el caso del BAM, la explotación de datos es más directa y fácil que cuando tenemos varios ESB’s separados.

Sea como sea, e independientemente de la solución escogida; hay que tener en cuenta siempre estos factores; ya que normalmente cuando nuestra arquitectura SOA crece, es importante tener siempre el control de todos ellos de la manera más simple y fiable posible.

¿Qué creeis? ¿Es mejor una aproximación topológica de un ESB unificado o una topología de diversos ESB’s departamentales? ¿Qué experiencias prácticas teneis al respecto?

[Recuerda que puedes plantear cualquier duda nueva o abrir cualquier tema de discusión en el nuevo Foro de Espacio SOA]

Dependiendo de las necesidades que tengamos de comunicación (sincronía vs. asincronía; comunicación 1 a 1, 1 a N o N a N; mensajes erroneos o correctos; mensajería por eventos, etc…) vamos a definir la forma de intercambio de los mensajes entre las distintas aplicaciones / sistemas de nuestra arquitectura.

Petición / Respuesta (Request / Response)

Es la más utilizadas de todas las formas de intercambios de mensajes (también llamada Request / Reply). Básicamente, consiste en la petición por parte de un cliente a un proveedor de un servicio y la espera de la respuesta en un tiempo determinado.
La principal característica de este patrón de mensajería es que resulta síncrono y bloqueante, por lo que durante el tiempo de ejecución del servicio, el cliente queda bloqueado a la espera. De hecho, es útil el manejo de timeouts para manejar la situación en que no haya respuesta por parte del servidor.
Este tipo de mensajería es el indicado para la petición de ejecución de servicios que suelen ser rápidos o cuando del lado del cliente no se puede seguir la ejecución por necesitar obligatoriamente la respuesta del servidor.
Desde el punto de vista del cliente, es una llamada de tipo RPC (Remote Procedure Call), ya que es bloqueante hasta la llegada de la respuesta.
El protocolo de comunicación más utilizado para este tipo de mensajería es HTTP.

Sólo Petición (One-Way)

Es un tipo de mensajería asíncrono y no bloqueante. Suele utilizarse cuando el cliente no necesita la respuesta inmediata por parte del servidor y puede seguir ejecutándose. En estos casos puede utilizarse tanto HTTP (sin respuesta) como JMS (quizá más apropiado) para la implementación de este tipo de mensajería (también pueden utilizarse otros protocolos como FTP, SMTP, etc…)
En este punto, es importante diferenciar entre Petición / Respuesta y One-way en ambos sentidos.
En el primero de los casos, implica un bloqueo por parte del cliente a la espera de la respuesta del servidor.
En el segundo de los casos, la Petición / Respuesta se implementa como dos llamadas one-way asíncronas, por lo que durante el tiempo de ejecución del servicio, el cliente no queda bloqueado y puede ejecutar otra lógica diferente. De hecho, esta segunda forma requiere que el cliente sea a la vez consumidor y proveedor (ya que necesita implementar algúna forma de binding para ser invocado por parte del servidor en la respuesta). Esta opción es bastante útil cuando se realiza una comunicación con un servidor del que se necesita la respuesta, pero dada la duración de ejecución del mismo, el cliente puede aprovechar para realizar otras tareas programadas. El protocolo de comunicación más utilizado para este tipo de mensajería es JMS por sus características asíncronas.

Request / Callback

Es un tipo de mensajería request / response asíncrona. Normalmente, el cliente puede realizar una invocación al proveedor del servicio y seguir ejecutando otro código. La diferencia con la petición one-way en ambos sentidos, radica en que en la petición, se pasa la información del callback o manejador de la respuesta. Es decir, a nivel del cliente existe una parte que es la encargada de realizar la petición al servicio y otra parte que es la encargada de manejar la respuesta.
La principal complejidad de este patrón de mensajería consiste en que la función de callback debe ser capaz de manejar el contexto o la información de instancia para correlacionar los mensajes de respuesta correctamente con los de la petición.

Publicación / Suscripción (Publish / Subscribe)

Cuando se realiza una petición que no necesita de una respuesta, suele utilizarse el patrón de mensajería conocido como publicación / suscripción. A diferencia del patrón one-way, con Publish / Subscribe se permite la comunicación 1 a N entre el cliente y los distintos consumidores de los mensajes (que se "suscriben" a la publicación del mensaje en cuestión).
Este tipo de mensajería suelen ser implementados por medio de protocolos JMS, que permiten la asincronía y la persistencia de mensajes hasta su procesamiento.
Un ejemplo de Publicación / Suscripción sería la notificación que hace un sistema a otros N sistemas de un cambio en el primero (con un modelo Request / Response o One-Way implicaría notificar 1 a 1 a los sistemas implicados; mientras que con el patrón Publish / Subscribe se puede realizar en un solo paso).

Mensajes de Error (Fault Messages)

Normalmente, en los casos de comunicación que hemos descrito anteriormente, admitimos que los mensajes enviados son correctos y que contienen la información necesaria para su ejecución satisfactoria.
No obstante, a veces, es necesario definir como se realiza el intercambio de mensajes para resultados incorrectos o no esperados.
En el caso de mensajería Petición / Respuesta, la información que devuelve el proveedor del servicio puede ser la de un mensaje de error. En estos casos, la forma en que está definido el mensaje es dependiente del protocolo o el formato a utilizar. Por ejemplo, si utilizamos SOAP como medio de mensajería, se puede definir (aparte del formato de mensaje de la respuesta correcta) un formato para SOAP-Fault como mensajería para casos de excepciones.
En el caso de mensajería asíncrona, la respuesta de un mensaje con excepción puede resultar más complicada, ya que el envío de una petición no implica la llegada de una respuesta. Por ello, se suelen utilizar colas JMS como protocolo de comunicación asíncrona, ya que nos permite implementar medios de asegurar la recepción/envio de los mensajes por medio de reintentos y persistencia de los mismos en las colas.

EDA (Event-Driven Architecture)

La mensajería por eventos, es un tipo de mensajería que se ha puesto de moda con lo que ha venido a llamarse EDA o la evolución de SOA. Consiste basicamente en "automatizar" la generación de mensajes y el envío de los mismos por medio de eventos (que ocurren cuando se produce un cambio en el sistema generador de los mismos, por un timer que se ejecuta cada cierto tiempo, etc…).
Normalmente, un proceso de negocio orquesta la comunicación con los distintos sistemas/aplicaciones implicadas definiendo el orden en que se ejecutan y como se produce la mensajería o comunicación con los mismos.
Con EDA, esa orquestación queda asumida por los propios procesos de cada sistema o aplicación. Es decir, los servicios de negocio que permiten la integración con los sistemas finales tienen un tiempo de ejecución y además, definen cual es el siguiente servicio a ejecutarse en esa "cadena de eventos" que conforman los procesos en una arquitectura EDA.

Links interesantes:

SOAP Version 1.2 Part 1: Messaging Framework
Web Services Message Exchange Patterns
Message Exchange Pattern Wikipedia Definition
Message Exchange Pattern

El primero de estos artículos va a tratar sobre el ESB, cómo usarlo, sus aplicaciones reales más comunes, etc…

Comenzemos pues, definiendo el ESB como un elemento de integración que combina mensajería, servicios web, transformación de datos, enrutación, políticas de seguridad, etc… y que permite la interacción entre diversas aplicaciones o sistemas de una Architectura Empresarial.
El ESB se ha convertido en una de las partes más importantes de una Arquitectura SOA ya que se presenta como el "pegamento" multiprotocolo y multipropósito para dicha arquitectura.

Las aplicaciones y características más comunes del ESB son las siguientes:

Enrutación basada en contenido:

Generalmente, el ESB cumple un cometido de enrutación entre sistemas o aplicaciones. Esa enrutación o decisión del punto final (endpoint) que debe invocarse se puede hacer en función del contenido del mensaje. Para ello, el mensaje en cuestión debe llevar información asociada que permita determinar el endpoint en cuestión (es lo que suele llamarse metadatos o metainformación del mensaje).

Por ejemplo, podemos hacer una invocación a un servicio web u otro por medio de sus endpoints (esto es, las url’s de invocación de los servicios) en función de algún parámetro del mensaje.
El caso práctico más común, es un mensaje con información sobre concesión de un préstamo de dinero para el sector bancario. La decisión de aceptación del préstamo puede definirse como automática para cantidades por debajo de un umbral o manuales si se supera dicho límite. El ESB sería capaz de analizar dicha cantidad (sería información inclusa en el mensaje) e invocar un servicio web de resolución automática o manual según el caso que esté manejando.

Transformación de mensajes:

La mayoría de los ESB suelen incorporar motores de transformación y parseadores de mensajes que permiten y facilitan la transformación de los mismos. La manera más común suele ser por medio de un fichero XSLT de Transformación de mensajes, aunque algunas herramientas utilizan otros sistemas, incluso propietarios.

Por ejemplo, disponemos de un modelo de datos común de nuestra arquitectura y queremos invocar un servicio web con un modelo de datos particular y único. El ESB nos permite realizar la transformación del mensaje de un modelo a otro por medio de un fichero XSLT (o cualquier otro sistema que utilice) y así desacoplar completamente la implementación de uno y otro. De esta manera, un futuro cambio de uno u otro modelo, solo debería, en principio, aceptar a la transformación del mensaje, nunca a las implementaciones de ambos modelos involucrados.

Configuración y no codificación:

Una de las cosas más ventajosas de un ESB es que suele realizarse todo por medio de configuración y no codificación. Independientemente del producto que estemos utilizando (hoy en día la mayoría incluyen IDE’s gráficos que facilitan la configuración de los elementos del ESB; aunque algunos pueden necesitar de configuración por medio de ficheros y manualmente) suele ser suficiente con la configuración de los componentes del ESB que vayamos a utilizar. No suele necesitarse la codificación, lo que limita el número de errores y da fiabilidad al bus que se monte.
No obstante, si fuera necesario, la codificación (sea por medio de Java, .NET, o cualquier otro lenguaje) suele ser posible para casos concretos en que los componentes del ESB manejado no implementen o faciliten la configuración deseada.

Proxy de Servicios:

Una de las mayores ventajas del ESB es la de crear una capa de proxy por encima del servicio. Ello, nos permite abstraer su implementación (que al final, puede ser como una caja negra, de la que solo disponemos la interfaz, normalmente su WSDL) y añadirle información o requisitos para su ejecución.

El caso más práctico sería el de un servicio web con dos operaciones. Una de ellas, permite la consulta online en una base de datos de libros. La otra operación permite la compra de un libro y por tanto requiere del manejo de información confidencial como puede ser una tarjeta de crédito.
El ESB nos permite generar un proxy por encima de dicho servicio y dar lugar a dos nuevos servicios (que serán los que realmente se permitan invocar a traves de aplicaciones cliente). Uno de los dos proxy’s podría ser el servicio con la operación de consulta (sin requisito adicional). El otro servicio podría resultar en un proxy con requisito de seguridad añadido sobre la operación del servicio original. El proxy podría ser requerído para su invocación, por ejemplo, por medio de HTTPS que llamaría finalmente a la operación del servicio original no securizada.

Conversión de protocolos:

Como ya hemos comentado, una de las características del ESB es su funcionalidad multiprotocolo. Esto es, que permite la conexión a distintas aplicaciones o sistemas por medio de numerosos protocolos. Además, suelen incorporar la posibilidad de añadir conectores a todo tipo de aplicaciones que pueden ser desarrollados por el mismo fabricante del ESB, por terceros o incluso por el propio desarrollador a través de un API estandarizada.

El ejemplo más práctico sería un servicio web por HTTP, al que se le quiere dar fiabilidad por medio de mensajería JMS. El ESB sería el encargado de exponer el servicio de manera fiable a través de un proveedor de JMS y luego realizar la conversión de protocolo necesaria para la invocación via HTTP.

Auditorías y Logs de Mensajes:

Otra característica importante del ESB es su función como auditor de mensajería y "logado" de mensajes. La comunicación de información a través del ESB nos permite centralizar sistemas de log y persistencia de información susceptible de ser auditada. Además, luego con herramientas de BAM o incluso Business Intelligence pueden explotarse dichos datos y realizar monitorizaciones exhaustivas que permitan la optimización del ESB, la Arquitectura SOA y en definitiva el negocio de la empresa.

Manejo de Excepciones:

Generalmente los servicios web tienen un comportamiento de respuesta correcta y en algunos casos pueden devolver excepciones de manera controlada (o no). El ESB nos permite gestionar las excepciones de una manera estandarizada (por ejemplo SOAP Fault) y realizar las correcciones oportunas al ocurrir dichos errores.

El ejemplo más práctico consistiría en definir un modelo estándar de nuestra arquitectura para el manejo de excepciones. Por medio del ESB podríamos tratar cualquier tipo de error (independientemente del protocolo o el modelo de datos de los servicios involucrados) de una manera común a todo nuestro entorno y así poder unificar criterios, facilitar la internacionalización de mensajes de error, etc…

Securización de Servicios:

Los servicios que suelen integrarse por medio de un ESB pueden o no estar securizados. A veces, la información es necesaria de securizarse en mayor o menor medida dependiendo del cliente externo que vaya a utilizarla. Por medio del ESB se pueden definir políticas de seguridad para los servicios y establecer más o menos requisitos para la invocación / ejecución de los mismos.

El ejemplo práctico consistiría en securizar con SSL un servicio sin seguridad (por ejemplo, un servicio adaptado de un sistema legado que carece de elementos securizantes) por medio de certificados digitales.

Acceso a Repositorio de Servicios:

Un Repositorio de Servicios (no confundir con UDDI) nos permite acceder a metainformación de los servicios integrados que facilita el control de los mismos y el poder aplicar políticas y condiciones de una manera centralizada y jerarquizada (entre muchas otras características, muy ligadas a veces con la gobernabilidad de la arquitectura).

Un ejemplo práctico consistiría en resolver de manera dinámica los endpoints de invocacion de los servicios por medio del acceso a un repositorio de servicios que nos diera dicha información en tiempo de ejecución. De esta manera, por ejemplo, cambiar a la invocación de un servicio en pruebas u otro de respaldo, sería automático por medio de configuración del propio repositorio.

Validación, Enriquecimiento, Transformación y Operación de Mensajes:

Se puede decir, que estas son las 4 características estrella de un ESB:

Validación de la información, de los mensajes entrantes, sobre los que se pueden aplicar distintas condiciones y verificaciones que hagan cumplir los requisitos establecidos.
Enriquecimiento de los mensajes, posiblidad de añadir información o metainformación adicional para cumplir las necesidades de integración en cada momento.
Transformación de los mensajes, normalmente entre los diversos modelos de datos del conjunto de servicios y aplicaciones a integrar.
Operación de los mensajes o enrutación en función de directivas preestablecidas o a partir de metainformación inclusa en la propia comunicación.

Estas son solo algunas de las principales características y usos de un ESB. Dependiendo del producto que vayamos a utilizar será más o menos fuerte en ciertas cosas u otras.

¿Qué otras experiencias reales teneis con ESB’s? ¿Veis que falte algo? ¿Cuál es el producto del mercado que creeis mejor se adapta a vuestras necesidades o que cumple en mayor medida con estos requisitos?

Links interesantes:

ESB Integration Patterns by Dave Chappel
Patterns: Implementing an SOA using an Enterprise Service Bus
Patterns: Integrating Enterprise Service Buses in a Service-Oriented Architecture
Application Integration::Broker application pattern::Runtime patterns
Enterprise Service Bus (O’Reilly Safari Books Online)
ESB Patterns that "Click" (The Art and Science of Being an I/T Architect)

Ando metido en un proyecto personal de estos que llaman ahora "Web 2.0" y en una primera instancia el uso que voy a dar al bus de servicios es para integrar numerosos servicios web.
Mis necesidades iniciales son transformación de datos y conversión de protocolos (a futuro posiblemente necesite orquestar servicios, por lo que bpel como lenguaje será perfecto ya que JBI puede incluir un componente específico para ello). Y todo esto para cientos de servicios web a integrar… creo que un ESB llena a la perfección mis requisitos.

Siempre he tenido que trabajar con ESB’s comerciales y nunca me había puesto a mirar detenidamente las diferencias entre los Open Source del mercado. El caso es que me propuse realizar una pequeña prueba para ver cual escogía (partiendo de dos esquemas XSD de datos y un XSLT de tranformación, utilizar un componente JBI de conversión de datos para hacerlo funcionar).

Creo que me voy a quedar con Open ESB. Me ha parecido el más rápido e intuitivo de instalar/configurar/implementar (partiendo de cero) para una pequeña prueba de transformación de datos con XSLT. Y además, me apetece probar GlassFish y NetBeans (vienen en el mismo paquete). Acostumbrado a los JBoss/Weblogic y a Eclipse quiero probar la "gran alternativa" de la cual he leido muy buenas críticas.

¿Habéis trabajado vosotros con alguno de estos ESB? ¿Qué os han parecido? Cualquier ayuda/consejo será agradecida