SOA e Interoperabilidad

Este segundo principio SOA se enfoca en el acoplamiento, uno de los principales enemigos a derrotar mediante una estrategia SOA. Promueve, como objetivo de diseño de los contratos de los servicios, conseguir un débil 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 el mínimo acoplamiento entre los componentes internos del servicio: mensajes, reglas del negocio, procesos de negocio, posibles servicios de menor granularidad que lo componen, su implementación tecnológica, etc.

 

Más concretamente, 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.

 

Hay que dejar bien claro que no se habla de un bajo acoplamiento, sino 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 enlazados, dependientes y por tanto acoplados, la orientación a serviios 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 en su contrato.

 

Lograr un mínimo 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 TI con requerimientos de interoperabilidad, y es la principal consecuencia de la ausencia de gobernanza en el mapa de sistemas de una organización.

 

Pero el cescoplamiento que tenemos que perseguir tiene varias caras.

 

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.

 

Otro facor 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.

 

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 (mejor dicho: el abuso, porque a veces es necesario) 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 del sistema de información, dependa de la disponibilidad no sólo 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 se aligera poco el mapa de sistemas de la organización.