Espacio SOA

Con este primer post, pretendo empezar una colección de artículos con patrones de uso para distintas herramientas, tecnologías y estándares relacionadas con el mundo SOA y BPM. Espero que sean de vuestro interés y todos podamos aprender un poco más; por ello agradecería cualquier participación con experiencias reales, opiniones, ideas y cualquier comentario que permita enriquecer dichos posts.

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)