APROXIMACIÓN A SOA: EL ESB 17

2. APROXIMACIÓN A SOA: EL ESB

Uno de los desafíos que uno puede encontrarse a la hora de considerar la

integración entre servicios es la administración de todas las conexiones. Si se tienen
interfaces punto a punto y algo cambia en un servicio, todos los servicios
consumidores necesitan ser modificados. El servicio consumidor debe ser consciente
del protocolo que usa el servicio invocado, además del formato del mensaje y la
localización del servicio. Esto hace que haya una fuerte asociación entre servicios
consumidores y proveedores.

Esto es lo que se conoce como el ‘problema de conexión MxN’. El número de

conexiones crece exponencialmente por cada aplicación que se añade, a medida que
cada aplicación se conecta a una nueva aplicación.

El concepto del ESB ha sido introducido para lidiar con estos problemas [2]. El
ESB se coloca entre los servicios consumidores y los servicios que invocan. Usando este
modelo, cada aplicación se conecta solo una vez a una infraestructura troncal común:
el bus. Esto reduce al mínimo las conexiones y proporciona una ubicación centralizada
para su administración y para la gestión de sistemas integrados y arquitecturas.

Para gestionar la complejidad de cómo un servicio cliente se conecta y se

comunica con el proveedor del servicio, la SOA precisa de una infraestructura troncal
capaz de ir más allá de la mensajería distribuida tradicional para proveer
transformación compleja, enrutamiento y conectividad acoplada libremente en un
entorno TI heterogéneo, independientemente de las plataformas usadas. Esta
infraestructura troncal fiable proporciona un bus de servicios a escala empresarial, el
ESB.

Hay que destacar que implementar un ESB no significa implementar SOA, pues
ESB se centra en la integración de sistemas y SOA trata de contratos y reutilización de
sistemas.

La integración de sistemas es una parte importante, pero SOA va más allá como
ya se ha visto. El uso de un ESB no quiere decir que se tenga SOA. Lograr SOA
dependerá de la forma en que se modele y conciba a nuestros sistemas. Pero el ESB
será un componente importante en la solución SOA, porque toda integración de
sistemas pasará a través de él.

2.1. CAPACIDADES DE UN ESB

Cada una de las siguientes características es un elemento esencial para la

integración de una SOA. Juntos, estos elementos resuelven los problemas a los que se
enfrentan los clientes y los proveedores de servicios en un entorno SOA.

ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA

 APROXIMACIÓN A SOA: EL ESB 18

Endpoint

Los servicios consumidores hacen llamadas a un servicio a través del ESB en

lugar de llamar al servicio proveedor directamente. De esta manera un servicio
proveedor puede ser remplazado por otro sin la necesidad de cambiar cada servicio
consumidor para reflejar la nueva dirección. Sólo el ESB sabe exactamente qué servicio
proveedor es invocado, mientras los consumidores se limitan a dejar la invocación al
ESB. A esto se le llama virtualización de servicios.

Enrutado de servicios

A veces el enrutado es más específico: el servicio al que irá destinado la

petición es elegido según el contenido del mensaje de petición del consumidor. Esto es
lo que se denomina enrutado basado en contenido.

Transformación

Los proveedores y los consumidores no siempre hablan el mismo lenguaje.

Normalmente no usan los mismos protocolos ni los mismos formatos de mensaje. El
ESB puede transformar una petición al formato y/o protocolo soportado por el servicio
y hacer la operación inversa antes de mandar la respuesta de vuelta al consumidor. Los
mensajes dentro del ESB están basados en el CDM (Canonical Data Model); los
mensajes son transformados al CDM al entrar al ESB y pueden necesitar ser
transformados a otros formatos cuando viajan fuera del ESB.

Un elemento interesante en la transformación es el enriquecimiento de los

mensajes. El resultado de esta transformación no es únicamente la misma información
en una estructura diferente de mensaje, sino que puede añadirse información
adicional a esos mensajes.

Validación

El ESB puede validar peticiones antes de que sean mandadas al servicio

proveedor así como las respuestas dadas por los proveedores.

Auditoría

El ESB puede logear peticiones y respuestas con propósitos de auditoría y

mandar alertas cuando se produzcan unas determinadas condiciones.

Paso de mensajes

En lugar de llamar a un servicio, una aplicación puede mandar mensajes y

comunicarse asíncronamente con otras aplicaciones. El ESB puede dar garantía del
envío y persistencia de los mensajes.

ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA

 APROXIMACIÓN A SOA: EL ESB 19

Adaptación síncrona/asíncrona

Un ESB puede exponer servicios con una interfaz tanto asíncrona como
síncrona. Sin tener en cuenta la naturaleza del servicio proveedor que necesita ser
invocado, el ESB puede adaptarlos de síncrono a asíncrono y viceversa. Esto permite
otro importante tipo de desacoplo: el proveedor no necesita estar disponible al mismo
tiempo que el consumidor, y el consumidor no necesita esperar a la respuesta del
servicio que invoca.

Composición

Un ESB puede ser usado para agregar el resultado de varios servicios en una
única respuesta al servicio que las invocó, consiguiendo así la publicación de un nuevo
servicio compuesto. El anteriormente comentado enriquecimiento puede verse como
un caso especial de composición.

Un ESB también tiene la capacidad de mediar entre diferentes protocolos de

seguridad.

Ahora bien, para resolver todos estos problemas de integración se definieron

los llamados Enterprise Integration Patterns (EIP). Estos patrones identifican estos
problemas de integración presentando una manera unificada de resolverlos sin entrar
en el detalle de su implementación. En la siguiente sección veremos algunos de los
patrones de mayor interés.

2.2. ENTERPRISE INTEGRATION PATTERNS

Según el artículo de Gregor Hohpe “Enterprise Integration Patterns” [3], se

pueden agrupar los EIP en varias categorías, las cuales se verán a continuación.

Patrones de enrutado de mensajes

Estos patrones versan sobre mecanismos para dirigir mensajes desde un

transmisor hasta el receptor correcto. A continuación veremos algunos de ellos.

 Content-Based Router

Este patrón permite enrutar mensajes a determinados destinos en función del

contenido de los mensajes.

ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA

 APROXIMACIÓN A SOA: EL ESB 20

Figura A.2.1 - Content-Based Router

 Recipient List

Este es un patrón que permite enrutar mensajes a un número de receptores

especificados de forma dinámica.

Figura A.2.2 - Recipient List

 Message Filter

Como su nombre indica este patrón sirve para hacer un filtrado de los mensajes.

Figura A.2.3 - Message Filter

Patrones de transformación de mensajes

Estos patrones cambian el contenido de información de un mensaje. En muchos

casos, se necesita modificar el formato de un mensaje debido a las diferentes
necesidades del sistema del transmisor y del receptor. La información puede ser
añadida, extraída o simplemente reorganizada. Estas tareas son ejecutadas por los
transformadores de mensajes. Veamos algunos de ellos.

 Data Enricher

Este es el patrón empleado cuando queremos añadir información adicional a

los mensajes.

ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA

 APROXIMACIÓN A SOA: EL ESB 21

Figura A.2.4 - Data Enricher

 Content Filter

Usamos este patrón cuando sólo nos interesa parte de la información

contenida en un mensaje.

Figura A.2.5 - Content Filter

Otros patrones

Hay patrones que no pueden identificarse en ninguno de los anteriores dos

grupos. Son sobre todo patrones dedicados al mantenimiento del sistema de mensajes.

 Wire Tap

Permite obtener una copia del mensaje y enrutarlo a otra localización mientras
que el mensaje original continúa en su ruta.

Figura A.2.6 - Wire Tap

Hasta ahora se está hablando de temas puramente teóricos. Pero todo esto hay
que acabar implementándolo. Y, ¿cómo llevar a cabo la implementación de SOA, el ESB
y los EIP? En el siguiente capítulo se verán las tecnologías y especificaciones usadas
para tal fin, así como otras tecnologías que aunque no relacionadas directamente con
SOA han sido necesarias para la elaboración del proyecto.
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA