bridge

Siguiendo un poco con la línea del post anterior sobre recomendaciones para aplicar SOA en la empresa, quería dedicar éste a repasar brevemente los patrones de diseño en el ámbito de la integración que debemos tener en cuenta en primer lugar.

¿Por que necesitamos patrones de diseño?

Par ello, creo que el primer paso es hacernos una pregunta, que, aunque parezca una pregunta obvia, debemos hacérnosla. ¿Por qué necesitamos la integración? La respuesta es simple y compleja a la vez, porque:

las aplicaciones de negocio no pueden vivir solas, en aislamiento.

En el pasado, cuando muchas de estas aplicaciones se diseñaron, tal vez era factible el hecho de funcionar como un silo, sin comunicación con las demás. Pero hoy en día, es imposible.

Necesitamos que las aplicaciones se comuniquen entre sí por necesidades de negocio. Como las aplicaciones son heterogéneas, con tecnología diferentes, es necesario disponer de una forma de diseñar aplicaciones estándar, reconocida por la comunidad de arquitectos como las mejores prácticas para este cometido. Estas mejores prácticas se plasman en los llamados patrones de diseño.

Estos patrones son “recetas” ya probadas para la solución de una determinada problemática. Así, cada patrón incorpora la experiencia acumulada por desarrolladores y arquitectos expertos que han pasado anteriormente por la misma situación. Por lo tanto, se suele decir que los patrones no se inventan, más bien se “descubren” a partir de una problemática de negocio.

Además de constituir una solución a una situación determinada, los patrones de diseño tienen un gran valor como lenguaje común entre arquitectos y desarrolladores. En una situación compleja, es infinitamente más sencillo referirnos a tal o cual patrón que explicar con palabras toda la solución completa.

Y si hablamos de patrones de diseño de integración, el más importante en mi opinión es el de Bus.

Patrón de diseño de BUS

Antes de entrar en listado de patrones a aplicar, por su importancia, es conveniente detenernos a ver uno en profundidad: el patrón de BUS.

El objetivo primordial del patrón de BUS es lograr el desacoplamiento entre los dos extremos de la comunicación. ¿Cómo se logra esto? Pues interponiendo otro elemento (un “tercero”) entre la comunicación de las dos partes, como si fuera un intermediario.

La mejor manera de entender esto es un con ejemplo de la vida cotidiana. Cuando un usuario del teléfono llama a otro usuario no se establece una conexión directa entre uno y otro. Dicho en otro sentido, no hay un “cable” que vaya de la casa del primer usuario directamente hasta el segundo. En lugar de esto, desde casa se establece una conexión con la central telefónica y desde ahí al otro usuario. La central actúa como un intermediario para “desacoplar” a los dos usuarios

¿Cuándo necesitamos un Bus?

  • Cuando tenemos numerosos puntos de integración
  • Necesidad de crecimiento de la arquitectura
  • Existe más de un protocolo de comunicación
  • Requerimientos de mediación entre dos extremos (transformación de los datos por ejemplo)
  • Escalabilidad, gestión, monitoreo, transformación y seguridad

¿Qué ventajas tiene introducir un intermediario entre las dos partes?

Pues son muchas y muy importantes:

  • Desacoplamiento: en un escenario típico de fuerte acoplamiento tenemos toda una red de conexiones punto a punto entre las mismas. Con el uso de un patrón bus que desacople a las aplicaciones tendremos un esquema similar a este: Las aplicaciones no se relacionan directamente entre sí.
    En lugar de esto, se “conectan” al bus haciendo posible que se comuniquen entre sí de una manera centralizada y fácilmente gestionable.
  • Adaptación de protocolo y formato: mediante el bus de integración, al ser una pieza intermedia que se coloca entre el cliente del servicio y el proveedor del mismo, puede realizar el trabajo de adaptación de formatos de datos y protocolos. Imaginemos por ejemplo que el cliente sólo puedo enviar ficheros planos con campos de longitud constante mediante el protocolo FTP, sin embargo, el destinatario sólo entiende de ficheros XML a través de una conexión con al base de datos. Es necesario por lo tanto transformar los datos del fichero y el protocolo: esto lo hará el bus de una manera estándar y mucho más fácilmente que una implementación ad-hoc por cada caso.
  • Enrutador basado en contenido: es posible en función de uno o varios parámetros de entrada invocar a una lógica u otra. Transformación de mensajes. Es posible que la lógica de negocio a la que hay que invocar en última instancia necesite cierto tipo de parámetros especiales que no queremos exponer al cliente. También es posible que esta lógica se tenga que invocar bajo otro protocolo (por ejemplo una transacción CICS en el HOST o mediante un mensaje RMI/IIOP si invocamos a un EJB). Mediante esta mediación es posible proporcionar al cliente un interfaz limpio (con los tipos de parámetros estándar) y con un protocolo ampliamente adoptado (SOAP sobre HTTP)
  • Configuración y no programación: normalmente los ESB se acompañan de herramientas de desarrollo que hacen énfasis en reducir lo máximo posible la codificación. En su lugar, proporcionan un entorno visual en el que las tareas o acciones a realizar (como una transformación de parámetros) se representan con cajas unidas por flechas que indican el flujo de los datos.
  • Capa de abstracción de servicios: esta característica hace referencia a la ventaja que otorga el hecho de tener una capa intermedia que te oculte el servicio final.
    Por ejemplo es posible que este servicio tenga un grano demasiado fino para ser consumido por un cliente (por ejemplo una pantalla). Con esta a capa es posible modificar o adaptar este servicio de manera que sea realmente útil y sea “usable” por el cliente Auditorias y logs Con el uso de un ESB, todas las invocaciones a las lógicas de negocio pasan por un sólo sitio.
    Por lo tanto es posible implantar una herramienta de monitorización y/o establecer un componente que escriba logs o trazas. De esta manera podremos saber a qué servicios se está llamando, quién lo hace y con qué frecuencia.
  • Control de errores: cada backend tendrá su propia manera de representar un error. Con la capa ESB de integración es posible tener un punto centralizado donde gestionar estos errores y además proporcionar al cliente un interfaz único de estos errores (mediante la transformación del error que viene del backend).
  • Securización: podemos establecer un modo de securización común y homogéneo para los diferentes backends que pueden tener una securización muy diferente.
  • Registro de servicios: acompañado del uso de ESB se tiene un registro de servicios (UDDI). Este registro contendrá el descriptor de despliegue del mismo (WSDL) y sobre todo el endpoint o punto de acceso del servicio (la URL donde hay que invocar el mismo). Con esto logramos independizar la localización física de la máquina donde se ejecuta el servicio (podremos cambiarlo sin que el cliente se entere).
  • Validación, enriquecimiento: el ESB proporciona API y funcionalidades de validación de los mensajes (comprueba que los parámetros de entrada son correctos) y también puede enriquecer el mensaje. Por ejemplo, si la lógica necesita tres parámetros y uno de ellos es la fecha del sistema, se puede exponer un servicio al cliente con solo dos parámetros y este tercero se añadirá en el ESB antes de ejecutar la lógica. Con esto, podemos exponer servicios más simples y por lo tanto más fáciles de usar al cliente.

Como vemos un ESB tiene un gran trabajo por delante… es uno de los puntos a tener muy en cuenta en una arquitectura SOA.

Por último, creo que es necesario recordar que el ESB no es un producto ni un middleware… es un patrón de diseño (como dice el título del post), y en la empresa podemos implementar esta patrón de muchas maneras. De nosotros depende utilizar la correcta y la que mejor se ajuste a las necesidades y circunstancias de nuestra empresa.