En el día a día de nuestro trabajo, en el diseño y construcción de los servicios SOA, nos encontramos con un problema recurrente que ya he tratado parcialmente en otras entradas de este blog pero creo que es importante volver a hablar de él. Es una cuestión que puede parecer poco importante en un principio pero que en realidad puede decidir el fracaso o el éxito de un proyecto SOA: me refiero a la propiedad de los servicios y por derivación, de la propiedad de los datos.
Empezando por el final, la propiedad de los datos, se considera una buena practica que los datos persistentes que maneja un servicio (normalmente tablas en base de datos) estén encapsulados y que únicamente la lógica de ese servicio pueda leer o modificar esos datos (la encapsulación es un concepto ampliamente arraigado en la orientación a objetos). Con esto se consigue que las tablas sean privadas y que pueda ser cambiadas sin miedo a que los clientes de la lógica puedan verse afectados.  Además la lógica del servicio velará por la integridad de los datos. De otra manera, si cualquiera puede modificar un registro de nuestra tabla sin invocar nuestro servicio, ¿Quien garantiza la consistencia de los datos?

En teoría todos estos conceptos están claros, pero, ¿que pasa con los datos que son “de todos” o “de nadie” (según se mire)? Y con esto me refiero por ejemplo a listas o catálogos que usa toda la empresa, tipo “lista de países” o “lista de provincias”. Lo que podemos encontrarnos es que estos datos “no pertenecen a nadie”:

  • ¿Entonces quien hace el servicio para acceder a esos datos?
  • ¿Quien invierte su tiempo y dinero en desarrollar estos servicios y mantenerlos?

Una opción bastante practica es que sea el departamento de Arquitectura (como departamento “cross” a toda la organización) el que se encargue de esto ya que tienen un aspecto mas técnico y menos de negocio.Y todo esto nos lleva al segundo aspecto,

la propiedad de los servicios

A veces necesitamos acceder a datos que no son de nuestra propiedad y por desgracia, no existe un servicio de negocio que nos proporcione la lógica necesaria para acceder a esta funcionalidad. Obviamente el servicio tendría que desarrollarlo el propietario de los servicios pero no puede hacerlo ¿Quien lo hace enconces? Una posible solución seria que este servicio lo construyese el primero en necesitarlo, pero este planteamiento también conlleva varios problemas.

Y ¿qué es un propietario de servicio? el propietario es que proporciona el servicio a múltiples clientes y es el responsable de diseñar, desarrollar, desplegar y mantener este servicio. A menudo es una tarea “ingrata”, ya que en una empresa dividida por áreas y departamentos, puede ocurrir que el presupuesto de una de estas áreas tenga que sufragar un servicio que después lo usarán “otros”. Aunque esto no debería preocuparnos, a fin de cuentas, esto es SOA ¿no? Sin duda, nosotros también nos beneficiaremos de los servicios de otras áreas.

Como comentaba en el día a día aparecen muchas situaciones relativas a la propiedad que hay que resolver para implantar una arquitectura orientada a servicios. De esto tendría que ocuparse el gobierno o la gobernanza SOA. La falta de un modelo claro aceptado y ampliamente adoptado de propiedad de los servicio y los datos puede ser una causa del fracaso de la implantación de SOA en una organización.

Comparte esta entrada…

Share

Anuncios