Bajo acoplamiento de Servicios

por

Principio SOA 2 – Los Contratos de Servicios imponen a los consumidores requisitos de bajo acoplamiento, y ellos mismos estan desacoplados de su entorno

 

Este segundo principio SOA pone el foco en el acoplamiento, uno de los principales enemigos a derrotar mediante una estrategia SOA. El objetivo es lograr un bajo acoplamiento, lo más bajo posible, y a menudo hablaremos de desacoplamiento.

 

Bajo acoplamiento.

En su enunciado promueve, como objetivo de diseño de los contratos de los servicios, conseguir un bajo acoplamiento a dos niveles:

  • Hacia fuera del servicio, con los sistemas consumidores del servicio. Es decir, que ante posibles modificaciones en el diseño del servicio, los sistemas consumidores se vean impactados lo mínimo posible.
  • Internamente, donde debe mantenerse la mínima dependencia entre los componentes internos del servicio: mensajes, reglas de negocio, procesos de negocio, posibles servicios de menor granularidad que lo componen, su implementación tecnológica, etc.

 

En concreto, la segunda parte de este principio me parece fundamental: establece el desacoplamiento total entre el servicio y el entorno que le rodea, lo cual permite al servicio desacoplar entre sí los sistemas que se integran.

 

Ojo porque no hablamos de bajo acoplamiento, hablamos de acoplamiento cero. Esto no es más que la consagración en los principios SOA de una de las premisas básicas de SOA:

  • frente al enfoque tradicional de integración de sistemas, donde los sistemas implicados tienen que conocerse para resolver esa integración, quedando por este motivo acoplados, la orientación a servicios rompe esa dependencia y establece una frontera que debe ser infranqueable entre los sistemas afectados, a los que ya no les interesa en absoluto ningún detalle del otro sistema, sino únicamente los detalles de la interfaz que le ofrece el servicio SOA en su Contrato de Servicio.

 

Lograr un bajo acoplamiento es un factor crítico para el éxito de una estrategia SOA. En este problema radica una buena parte del encarecimiento de los proyectos TIC con requerimientos de interoperabilidad, y es la principal consecuencia de una débil gobernanza en el mapa de sistemas de una organización.

 

Pero el desacoplamiento que tenemos que perseguir tiene varias caras.

 

Desacoplamiento tecnológico.

Aparte del desacoplamiento entre el servicio y su entorno, que viene a ser abogar por el encapsulamiento de los servicios, ni más ni menos, está también el desacoplamiento tecnológico. Esto significa que debemos ser capaces de publicar cualquier servicio a cualquier sistema de información, sea cual sea su tecnología.

 

Evidentemente hay ciertas limitaciones, pero la estrategia SOA tiene que tender puentes, facilitar la integración de todos los sistemas participantes con el menor impacto posible. Y ocurre a menudo (más de lo que pensamos), que los sistemas existentes tienen una tecnología muy antigua, o muy rígida, o simplemente no disponen de capacidad para migrar a otra tecnología más reciente. Para esto están indicados los muchos adaptadores que deben incorporar de fábrica los ESB.

Pero en el diseño y construcción de los servicios debemos ser conscientes de este tema, y usar tecnologías abiertas (XML, XSLT, etc), y evitar diseños condicionados por peculiaridades demasiado específicas de alguna tecnología concreta.

 

Desacoplamiento en la mensajería.

Otro factor que incide directamente en lograr el menor acoplamiento es el uso de los estándares para definir la mensajería.

 

Si algo bueno tienen los estándares es que definen con precisión universal un esquema, que sirve como una interfaz que todo el mundo puede usar, sin importar ninguna consideración tecnológica.

 

Si no se usan los estándares, si caemos en la definición de mensajería propietaria, estamos aceptando un cierto nivel de acoplamiento a nivel de mensajería, que también hay que evitar.

 

Desacoplamiento transaccional.

Otro tipo de acoplamiento mucho más sutil y que no siempre puede evitarse es el acoplamiento transaccional. Con esto nos referimos al efecto que provoca el uso sistemático de la sincronía entre extremos.

 

Cuando un servicio se define como síncrono entre extremos, como por ejemplo los servicios de consulta-respuesta, podemos estar cumpliendo todos los principios SOA conocidos pero estaremos haciendo que nuestro usuario, el usuario de nuestro sistema de información, dependa de la disponibilidad no solo de este sistema que está usando, sino también de aquel que debe responder a la consulta en un determinado momento y en un tiempo aceptable en términos de rendimiento.

Además, estos casos siguen siendo integraciones punto a punto, con lo que aligeramos muy poco el mapa de sistemas de la organización.

 

Frente a este patrón, se debe promover el uso de servicios asíncronos entre extremos, y para ello la orientación a eventos (EDA) de la que hemos hablado varias veces en este blog es el enfoque correcto.

 

Este enfoque a menudo supone un cambio bastante radical de enfoque en los sistemas de información que proveen y consumen estos servicios, puesto que los primeros están acostumbrados a ser consultados, y los segundos están acostumbrados a no incluir cierta información en su modelo de datos, y buscarla afuera mediante el correspondiente servicio.

 

Sin embargo, esto obedece en realidad a una mala práctica derivada quizá de los tiempos en que el almacenamiento era caro y se promovía insistentemente el evitar la redundancia de información. Hoy en día el contexto es totalmente diferente y lo correcto es que si un sistema de información en su modelo de datos necesita información de una determinada entidad, lo que no puede hacer es dejar de incluir dicha entidad en su modelo.

Al no hacerlo, deben consultarla en aquel otro sistema de información que mantiene el negocio relativo a esa entidad, y de esta forma caemos en la trampa del acoplamiento a nivel transaccional, como mínimo, y también a nivel de modelo de datos, que es aún peor.

Si por el contrario incluyo en mi modelo todas las entidades que responden a mis requisitos, puedo plantear una arquitectura de suscripción pasiva a los eventos relacionados con esa entidad, para que sean dichos eventos desencadenados por el sistema responsable del negocio de dicha entidad, los que me envíen la información a mantener en mi modelo de datos.

 

De esta forma no dependo del otro sistema, mi usuario tiene la información disponible y actualizada, y los tiempos de respuesta son óptimos.

 

En definitiva, este segundo principio SOA incide en el desacoplamiento como un objetivo de diseño fundamental que debe estar en la mente de todos los arquitectos SOA (consultores, analistas, desarrolladores, etc).

Supone un factor crítico de éxito que incide directamente en el retorno de la inversión de la estrategia SOA, puesto que permite la liberación de los sistemas de información de la organización para poder evolucionar de forma independiente, manteniendo todas las necesidades de interoperabilidad cubiertas por la capa de servicios estándar encapsulados publicados en el ESB.

 

Te puede interesar

1 Comentario

  1. JughauttAduff

    Precisely every legacy and new-look IT vendor has its own settle on making the entire details center more programmable via software and less dependent on specialized, proprietary and expensive hardware.

    Responder

Enviar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Sigueme en las redes

Share This