Muy interesante el artículo de WSO2 “Practical SOA for the Solution Architect“. Aunque es un documento de veinte y tantas páginas, ellos mismos se han encargado de resumirlo.

Y a decir verdad, el resumen está muy bien por dos razones además de la brevedad: la claridad de la explicación (no es muy común un documento de este tipo) y las ideas que expone (de esas que piensas que son de perogrullo pero que es conveniente resaltar).

Su principal argumento es que el arquitecto de la solución debe considerar dos capas en su diseño: una capa de tecnología y otra capa de datos. Estas dos capas deben estar claramente separadas.

¿El motivo? Pues que si sólo nos ocupamos de la tecnología el diseño de los datos o el vocabulario que usamos en los servicios de la empresa, tendrán un alto grado de acoplamiento. Característica que precisamente es lo que queremos evitar con SOA.

¿Y qué entendemos por una capa tecnológica? Pues básicamente la que contiene estos tres componentes:

  1. El contenedor de servicios. Es el que “alberga” la lógica de negocio del servicio que hemos implementado.
    Es decir, nuestro software no “flota” en el servidor sino que “vive” dentro de un contenedor que le proporciona funcionalidades básicas como la seguridad, la gestión del ciclo de vida del propio servicio (creación y eliminación de instancias del servicio), etc.
  2. El broker. Es lo que podríamos entender como el bus de servicios (ESB). Es decir, es un middleware que nos permite adaptar el protocolo usado por el consumidor del servicio a los que necesitan los backends de negocio. Por ejemplo, el cliente puede usar REST para invocar al servicio, y éste necesitar invocar a una transacción COBOL.
    Además de los protocolos, también transforma el formato y estructura de los datos y por último oculta la localización física del servicio y otros detalles tecnológicos que el cliente no tiene por qué conocer.
  3. El coordinador de procesos. Es el que se corresponde con un servidor de procesos. Es decir, un middleware que es capaz de coordinar diferentes tareas, ejecutarlas en el orden correcto, mantener el control del flujo de la ejecución, etc. etc.

En cuanto a la capa de datos, estos son los principios que habría que aplicarle:

  1. Identificar y eliminar dependencias innecesarias.
  2. Identificar dependencias implícitas y hacerlas explícitas. Las dependencias deben constituir auténticos contratos entre los diferentes sistemas, por ello debemos sacar a la luz este tipo de dependencia.
  3. Asegurar la mínima asociación entre los datos que se intercambian en los mensajes de los servicios y los datos del dominio de negocio.
    Evidentemente ambos conjuntos de datos están relacionados. No tiene sentido tener un servicio para dar de alta a un cliente con unos datos que no tienen nada que ver con los datos que guardamos en la base de datos de la aplicación.
  4. Elige un nivel medio de granularidad para los modelos de datos del dominio.
    No es necesario que pensemos en un vocabulario universal para toda la organización. Sería un trabajo demasiado complicado que se llevaría gran parte de nuestro tiempo y energía. Es mejor tener una solución intermedia y aprovechar la capacidad del broker para la transformación de los datos entre estos y el modelo de dominio.

En definitiva, unos principios sencillos que debemos tener en cuenta en nuestros servicios.

Comparte este artículo:
Share

Anuncios