capilla sixtina
Está claro que para que una aplicación o solución de negocio se pueda considerar como SOA, debería cumplir los 8 principios definidos por la Thomas Erl y compañia. Sobre este tema, ya dediqué hace tiempo, una entrada esto en el blog.
Si recordamos un poco y vemos estos principios, en mayor o menor medida, todos son importantes. Y si pensamos en ellos desde el punto de vista del desacoplamiento:
  1. Contratos de servicio estandarizados
    Por un lado define el contrato, la interfaz del servicio, que nos permite entre otras cosas que un servicio funcione como una caja negra sin preocuparnos de cómo esté implementado internamente. Ademas estos contratos están estandarizados, es decir, están realizados con un lenguaje común (unos tipos de datos comunes) a los servicios del mismo dominio de negocio que permite evitar las transformaciones entre los mismos en las llamadas entre servicios.
  2. Servicios con bajo acoplamiento
    Los servicios dependen lo mínimo posible los unos de los otros. Incluso un cliente puede estar implementado en un lenguaje y ejecutarse sobre una máquina con un sistema operativo, sobre un servidor de aplicaciones, y en una máquina totalmente diferente a donde se ejecuta el servicio
  3. Abstracción
    Aquí se pone el énfasis en ocultar los detalles internos de la implementación del servicio, para que podamos evolucionarlo libremente sin afectar a los clientes. Evidentemente  cuando más «abstraido» esté un servicio, más desacoplado estará.
  4. Reusabilidad
    Es una de las justificaciones de SOA más importante, mediante la reutilización, logramos entre otras cosas, reducir el coste del desarrollo.
    Podemos decir que cuanto más desacoplado esté un servicio, más fácil será reutilizarlo.
  5. Autonomía
    Este concepto siempre me ha resultado un poco difuso. Digamos que hace hincapié en que el servicio tiene control, o conocimiento, sobre el entorno en el que se ejecuta.
  6. Sin estado
    Este característica va más encaminada hacia el rendimiento y la escalabilidad del servicio. También, indirectamente, puede afectar al desacoplamiento ya que normalmente para mantener la sesión o el estado, el cliente tiene que guardar y enviar repetidamente un identificador o token de sesión y eso «acopla» bastante.
  7. Capacidad de descubrimiento
    Si no somos capaces de saber que existe el servicio que necesitamos, difícilmente vamos a poder reutilizarlo. No parece que haya una relación directa con el desacoplamiento en este caso…
  8. Composición
    La capacidad, muy importante, de que un servicio se pueda combinar con otros para crear un servicio de más alto nivel. Es decir, no programamos nuevas lógicas si no que juntamos servicios ya existentes.
    Parece claro que para que podamos componer servicios junto otros, éstos deberían estar suficiente «separados» o desacoplados del resto. 

En conclusión

En definitiva y respondiendo a la pregunta del título, creo que la característica de desacoplamiento es la más importante de todas ellas, o mejor dicho, la más crítica. El resto de principios tiene relación con éste o dependen en mayor o menor medida.

Y creo que la mejor de prueba de esto, aunque no totalmente científica, parte de la experiencia. Si nos ponemos en la situación de trasformar un sistema no SOA en otro orientado a servicios… podremos lidiar quizás con la falta de contratos (se puede crear), con la capacidad de descubrimiento (se puede hacer un inventario de servicios), etc etc. pero si el sistema está altamente acoplado en sus módulos y lógicas de negocio… es virtualmente imposible transformarlo a SOA. ¿O a ti no te ha pasado con algún proyecto?