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.
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.
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.
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. Message Filter Figura A.2.2 - Recipient List 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.
21 Content Filter Figura A.2.4 - Data Enricher Usamos este patrón cuando sólo nos interesa parte de la información contenida en un mensaje. Otros patrones Figura A.2.5 - Content Filter 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.