Según cuenta, lo principal es mantener una taxonomía simple basada en 4 tipos de servicios básicos que solo debería extenderse según las necesidades de cada empresa y siempre de una manera muy justificada y como medio para asegurar el entendimiento de todas las partes (negocio, técnicos, etc…).

Los tipos básicos son:

Servicios de Negocio : Servicios core de la empresa y del negocio, identificados por usuarios normalmente no técnicos y que cuando se coreografían representan casos de uso o escenarios de usuario. Se implementan con un lenguaje de definición de contrato (WSDL normalmente) y se nombran por alguno de los típicos verbos CRUD (Create, Read, Update y Delete). Un ejemplo sería, “recuperarCliente”.

Servicios de Empresa : Son servicios que implementan servicios de negocio (relaciones 1 a N o N a N). Identificados normalmente por Arquitectos IT son producto de orquestación de servicios. Además, para la transformación de los modelos de datos entre los servicios de empresa y los de negocio, se utilizan transformadores (como XSLT) normalmente en un bus de servicios. Un ejemplo sería “calcularCreditoBancario”.

Servicios de Aplicación : Servicios dentro del contexto de las aplicaciones (y que por tanto no se comparten al mismo nivel que los servicios de empresa o de negocio), que representan funciones específicas como validaciones o transferencias de datos. Son identificados por los desarrolladores de las aplicaciones. Un ejemplo sería “añadirDireccion”.

Servicios de Infraestructura : Servicios que dan soporte a nivel de toda la empresa, tales como logging, auditoría, seguridad… Normalmente son identificados por los desarrolladores de las aplicaciones o equipos de soporte a infraestructuras. Un ejemplo sería “escribeLog”.

Podeis leer todo el artículo aquí.

Normalmente, muchos de los errores más comunes en proyectos SOA, tienen como solución la aplicación de una buena ejecución de gobernabilidad en la arquitectura:

• Centralización de la información de los servicios: A medida que nuestra arquitectura crece y crece, el número de servicios puede llegar a ser inmanejable. Es frustrante que una de las máximas en SOA sea la reutilización de los servicios que se van desarrollando; y una y otra vez vemos como se rehacen y duplican los mismos desarrollos por equipos y departamentos distintos que no tienen conocimiento del total de los servicios existentes en la empresa y por tanto de las funcionalidades disponibles.

  La solución a este problema pasa por la utilización de un registro y repositorio de servicios; tan importante como necesario para centralizar toda la información existente. Así, gracias a ello, podremos rápidamente ver toda la colección de servicios que nos son accesibles, cual es su funcionalidad, como se pueden utilizar, etc…

• Buenas prácticas de diseño: A menudo se crean servicios y más servicios; y uno de los principales problemas que nos encontramos es que en el momento en que se diseñaron no se pensaron para ser reutilizados más allá del ambito para el que fueron creados. Eso a menudo provoca que la reutilización sea bastante compleja o que haya que rediseñarlos o modificarlos para hacerlos más reutilizables.

  El problema de la remodelación de servicios radica principalmente en que suele venir acompañado de un impacto a los clientes del mismo que ya los estén utilizando y por tanto la modificación de estos (como si de una cadena se tratara). Por ello; es importante aplicar buenas prácticas de reutilización a la hora de construir servicios de tal manera que sean totalmente susceptibles de ser utilizados por cualquier cliente potencial.
  Además; es sumamente importante que los desarrollos estén probados correctamente a todos los niveles (funcionalidad, seguridad, etc..) y que cumplan políticas de interoperabilidad (WS-I) para la aceptación de los mismos en el sistema de gobernabilidad de la arquitectura.

• Explotación correcta de los servicios: Cuando los servicios llegan a sistemas de producción; a menudo no hay un control exhausto o correcto que indique el uso de los mismos.
  Es importante la utilización de herramientas de monitorización que nos permitan tener controlados en todo momento los servicios que están siendo utilizados; asi como los clientes que están teniendo, etc… a fin de poder dimensionarlos correctamente y permitir que puedan ejecutarse sin provocar cuellos de botella.
• Despliegues controlados / mantenimientos de versiones: El número creciente de versiones, dependencias, etc… hace que a veces halla problemas a la hora de desplegar y redesplegar nuevos desarrollos o correcciones de los ya existentes.
  Por ello, es importante controlar las versiones y las dependencias que se van creando; para que si algo sale mal, cuestiones tan importantes como un rollback de la instalación, sea rápido, fácil y sencillo. Iniciativas como OSGi posiblemente serán muy importantes en el futuro ya que solucionarán bastantes de estos problemas.

La gobernabilidad en SOA es muy importante. Preguntas como

• ¿Qué ocurre si se cambia un servicio?
• ¿Cómo se puede asegurar la calidad de un servicio?
• ¿Cómo podemos asegurar que un servicio (nuevo o existente) cumple con las políticas de calidad y de seguridad establecidas por la empresa?
• ¿Cómo podemos asegurar el rendimiento y los SLA de los servicios?

deben ser cotestadas con un Plan de Gobernabilidad SOA.

A priori puede resultar una pregunta dificil de responder; pero lo que sí que tiene que quedar claro es que se trata de uno de los puntos más importantes a tener en cuenta a la hora de emprender un proyecto SOA.

Normalmente, gobernabilidad no es solo un conjunto de tecnologías que te permiten llevar a cabo satisfactoriamente una arquitectura SOA. Suele ser un conjunto de herramientas en conjunto con diversas metodologías, guías y buenas prácticas.

Cuando hablamos de gobernabilidad, no podemos dejar de hablar de Gestión y Registro de Servicios. Los registros UDDI han evolucionado en la mayoría de los fabricantes, hasta ofrecer auténticas herramientas de gestión y organización de servicios. Muchos de ellos tienen un elemento central que suele ser un registro UDDI, pero generalmente suelen ser mucho más que eso: registro de servicios, políticas de gestión, de seguridad, ciclos de vida, repositorios de información de todo tipo asociada a los servicios, etc…
Y asociado a esos registros de servicios, tenemos que hablar de un concepto importante que es el de los ciclos de vida asociados (no solo a los servicios sino también a toda la arquitectura): normalmente evidenciaremos 4 fases en ese ciclo: Análisis, Diseño, Desarrollo y Medida (o Monitorización).

• Análisis: Comprende normalmente la fase de análisis de la organización o empresa objeto de la Arquitectura SOA. Es importante analizar no solo lo existente sino también lo que se va a construir. Es necesario identificar como está estructurada la empresa, las areas existentes y como se encuentra definida la organización. Es en este punto donde debemos definir un Plan de Gobernabilidad correcto y adecuado a las necesidades (que podrá, no obstante, ser modificado a futuro si encontramos dicha necesidad).
• Diseño: Una vez que se ha identificado la oportunidad para construir una Arquitectura SOA debemos definir los distintos niveles que serán necesarios, la gente que va a estar involucrada y en que medida. Puede ser interesante definir un grupo de gente encargada de asegurar la excelencia en la calidad de la gobernabilidad planteada (Governance Excellence Team). Habrá que, además, identificar como se va a organizar los departamentos de IT y otros con respecto a un proyecto de estas características.
• Desarrollo: Será el momento de poner en funcionamiento lo diseñado en las fases previas. Habrá que poner en funcionamiento las distintas políticas que aseguren la calidad de los desarrollos. En este punto es donde, a muy nivel técnico, deben registrarse los servicios y hacerse disponibles según los propios ciclos de vida de aceptación para el resto de usuarios. Aquí es donde debemos sacar todo el rendimiento a las herramientas tecnológicas que nos permitirán llevar a cabo una gobernabilidad de la arquitectura de manera correcta (principalmente gracias a repositorios (que no registros) de servicios).
• Medida: La monitorización y visión del funcionamiento de la arquitectura nos permitirá determinar los fallos o carencias que tiene y ofrecer una remodelación de los diseños iniciales. El cumplimiento de los niveles establecidos, SLA’s, etc.. nos permitirá ver que se está haciendo bien y que se está haciendo mal. Este punto es en el cual se cierra el ciclo de vida y se permite el aseguramiento de la calidad por el refuerzo de la misma.

La Gobernabilidad en SOA es un tema importante debido principalmente a la interdependencia de los sistemas involucrados: existen múltiples propietarios, múltiples políticas, etc… y ello conlleva generalmente que cada “incidencia” de reutilización pueda provocar dependencias adicionales.

Herramientas tecnológicas de apoyo a la Gobernabilidad SOA:

• Repositorios de Servicios: Suelen ser componentes basados en registros UDDI, pero que hoy en día van mucho más alla. Normalmente permiten almacenar servicios para ser disponibles en la propia arquitectura SOA siguiendo un modelo de publicación, descubrimiento y subscripción. Su forma de exponer los servicios se basa en los WSDL, lo que permite tener definido cualquier servicio, principalmente a través de un ESB o Bus de Servicios (al que normalmente va conectado el Repositorio de Servicios).
  Gracias a un repositorio de servicios vamos a disponer de todos los servicios organizados y facilmente accesibles para ser reutilizados. Estas herramientas suelen disponer de numerosas capacidades como ciclos de vida de aceptación de los propios servicios, monitorización de los mismos para ver su uso, capacidades de alerta de cambios a todos los suscriptores, identificación de los desarrolladores de los servicios, elementos de definición adicionales, etc…
• Monitorización: Normalmente son herramientas que permiten monitorizar el consumo de los servicios existentes. De esta manera podemos ver si se están utilizando adecuadamente, cuales son más críticos, tiempos de respuestas, etc…
  Gracias a estas herramientas podremos medir los distintos indicadores, SLA’s y demás mediciones necesarias para ver si se está asegurando los niveles mínimos de calidad establecidos. En caso de que no fuera así, se tomarán las medidas oportunas para solucionarlo.
• Seguridad: Existen herramientas específicas para definir los distintos niveles de seguridad de nuestra arquitectura y por tanto tener siempre identificados los servicios dentro de dichos niveles. Podremos añadir seguridad adicional a la existente por los propios servicios y así tener identificado en todo momento quién accede y como accede a los servicios.