- 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. - 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 - 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á. - 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. - 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. - 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. - 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… - 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?
Deja una respuesta