En los últimos anos se han abordado diversos estudios  y artículos encaminados a establecer la importancia del Gobierno SOA [1], [2]. Y es que el concepto de  gobierno es tan antiguo como la propia civilización. Por ejemplo, el objetivo del gobierno de la nación, es establecer los canales de responsabilidad así como las medidas, políticas y mecanismos de control para llevar a cabo decisiones de estado. Por su parte, el gobierno corporativo de una empresa establece canales de responsabilidad en base a cargos así como políticas y normas para llevar a cabo las decisiones dentro de la companía.
En cuanto al Gobierno IT, establece los roles, mecanismos y políticas para medir y controlar las decisiones relacionadas con tecnologías de la información que se producen en una empresa. Por lo tanto, podemos definir el Gobierno SOA como "la extensión del Gobierno IT focalizada en el ciclo de vida de servicios con el objetivo de definir las políticas de desarrollo y ejecución de proyectos relacionados con arquitecturas orientadas a servicios"

2. Herramientas para el Gobierno SOA

La definición anterior de Gobierno SOA, si bien puede ser comúnmente aceptada por la industria, es algo abstracta para poder definir las características que debe proporcionar una herramienta que ayude a implantar un Gobierno SOA.

Existe la convención de dividir el Gobierno, y por lo tanto las herramientas utilizadas, en dos fases del ciclo de vida de una solución SOA: las herramientas en tiempo de diseno (DTG - Design Time Governance Tools) y las herramientas en tiempo de ejecución (RTG - Run Time Governance Tools). Las DTG tienen por principal objetivo la gestión de los artefactos y el ciclo de vida de los servicios (utilizando por ejemplo registros y repositorios) mientras que las RTG son las encargadas de garantizar la ejecución y el correcto funcionamiento de los servicios (por ejemplo conforme a las políticas y SLA definidos) así como el proporcionar métricas de comportamiento (utilizando cuadros de mando - BAM). En este sentido, las preguntas a responder en este artículo son claras:

Los diversos estudios sobre Gobierno SOA realizados por analistas como Gartner [3] o Forrester [4] evalúan la oferta de los principales proveedores desde un punto de vista principalmente comercial (estrategia de ventas, cuota de de mercado, oferta de productos, coste de la solución,  etc.) para determinar qué companías son líderes y visionarias en Gobierno SOA (ver figura 1) pero sin analizar en profundidad las herramientas propias de cada companía y obviando aspectos tecnológicos fundamentales para seleccionar una herramienta u otra.

Basándonos en estos estudios y en otras publicaciones [5], [6], [7], hemos definido aquellas características o funcionalidades que debe proporcionar una herramienta de Gobierno SOA para implantar en todo, o en parte, los distintos elementos de Gobierno. Las funcionalidades identificadas se han clasificado en tres grandes grupos:

Los grupos 1 y 2 corresponden a características de herramientas de Gobierno en tiempo de diseno mientras que el grupo 3 corresponde a funcionalidad identificada en herramientas en tiempo de ejecución.

Fig. 1. Cuadrante Mágico SOA Governance Fuente: Gartner Marzo 2009

Basándonos en la clasificación anterior, algunas características o funcionalidades que hemos identificado que debería implementar una herramienta de Gobierno SOA son las siguientes:

Asimismo, desde el punto de vista comercial, creemos que se deben tener en cuentas otros criterios, a saber:

Hemos evaluado el grado de cumplimiento de los criterios anteriores en las dos principales herramientas Open Source para el Gobierno SOA: la herramienta de Gobierno SOA conocida como Mule Galaxy (en adelante Galaxy) en su versión Community Edition 1.5.3 [8] y la herramienta WSO2 Governance Registry (en adelante G-Reg) en su versión 3.0 [9].
La primera beta de Galaxy (1.0-beta1) salió a la luz en Enero de 2008, anunciándose como la primera herramienta Open Source para el Gobierno SOA. Tras varias releases de la versión en estado beta, la versión 1.0. se publicó en Junio de 2008. Desde ese momento se han publicado varias revisiones, hasta llegar a la versión 1.5.3 publicada en Abril de 2009, y que ha sido la versión utilizada en la evaluación.
Hasta la aparición de Galaxy, las herramientas de Gobierno SOA Open Source se habían centrado en proporcionar un repositorio de servicios. Galaxy pretendía ir más allá, proporcionando funcionalidades adicionales para la gestión del Gobierno SOA.
En Julio de 2009, la companía WS02 ha contraatacado liberando la versión 3.0 de WS02 Registry, a la cual se le ha cambiado el nombre a WS02 Governance Registry (G-Reg) ya que anade nueva funcionalidad relacionada con el ciclo de vida de los servicios, la administración de políticas y la monitorización.
La evaluación realizada ha consistido en la descarga e instalación de las versiones seleccionadas y la realización de una prueba de concepto que nos permitiera evaluar cada funcionalidad identificada. Dicha evaluación se resume en la tabla 1 y se  describe en detalle en los siguientes apartados.

4.1. Registro y Repositorio

      Implementar un registro de artefactos. Galaxy no sólo permite el registro de servicios, sino de los siguientes artefactos:

Galaxy también permite registrar otros tipos de artefactos aunque no tenga soporte directo para los mismos. También facilita la extensión del sistema para anadir soporte específico a nuevas tipologías de artefactos. Un ejemplo de esta nueva tipología de artefactos podría ser la documentación asociada a un servicio web (soporte incluido únicamente en la edición Enterprise).
Por su parte, G-Reg permite registrar y acceder de una forma cómoda a Servicios, Políticas, WSDL y Esquemas XSD. El registro de los servicios se realiza bien a través de un formulario o de una forma más cómoda importando el WSDL asociado. Asimismo permite el registro de otros tipos de recursos (texto plano, URLs, links simbólicos) o incluso recursos registrados en otros repositorios. La herramienta posee un método para definir tipos de recursos de forma que se puedan clasificar y agilizar el alta de los artefactos.

Acceso programático al registro. Galaxy permite acceder de forma programática a la herramienta de tres formas: mediante el uso de scripts Groovy, mediante el HTTP AtomPub API y mediante el API Java de Galaxy. Los scripts Groovy deben ser ejecutados desde la consola de administración de la herramienta. El API HTTP AtomPub está basado en un servicio RESTful que expone Galaxy para la interacción con clientes de la herramienta. El API de Galaxy da acceso a toda la herramienta. Está ideado para la extensión de la misma y para su integración con otras herramientas. A diferencia del acceso AtomPub, el API de Galaxy obliga a utilizar sus librerías (ficheros jar) por lo que su uso está reservado a aplicaciones Java. Una ventaja es que al ser Galaxy una aplicación Spring resulta sencillo incrustar Galaxy o usar sus capacidades dentro de otra aplicación. En la siguiente figura se muestra cómo se accedería al Galaxy desde una aplicación Spring.

Fig. 2. Acceso a Galaxy desde una aplicación con Spring

G-Reg dispone de un API Java propio para el acceso a todos los elementos del repositorio. A su vez, este API se encuentra expuesto como servicio web. También proporciona distintos mecanismos para extender la funcionalidad de la herramienta como son handlers (permite ejecutar lógica extra asociada a  la ocurrencia de eventos),  filters  (asocia los tipos de recursos a los handlers) y aspects (lógica extra a invocar por el usuario).

Anadir información adicional (metadatos) a los servicios registrados. Galaxy permite anadir metainformación a los artefactos registrados. Esta metainformación organizada en forma de propiedades, puede ser personalizada modificando las incluidas en la distribución original así como anadiendo nuevas propiedades para adaptar el sistema a las necesidades de la organización. Esta adaptación permite que un artefacto disponga de metadatos globales, con un único valor en un momento determinado, y metadatos versionados, con un valor distinto por cada versión de un artefacto.
Por su parte, G-Reg también permite anadir metainformación a todos los artefactos registrados en forma de descripción textual, comentarios e incluso propiedades a medida.

Dependencia entre servicios. Galaxy detecta y maneja la dependencia directa entre artefactos. En el caso de documentos WSDL, localiza las etiquetas import y crea una dependencia entre el artefacto del documento WSDL y los elementos referenciados en dichas etiquetas. Estos elementos serán habitualmente esquemas XSD. Es posible también anadir una dependencia de forma manual, las cuales, tienden a cubrir la relación funcional entre artefactos, esta relación no la puede detectar ni tratar directamente la herramienta, mientras que la dependencia inferida por Galaxy cubre la relación técnica entre artefactos.
Por su parte, G-Reg al registrar un documento WSDL o XSD, importa todos los documentos relacionados generando las dependencias entre ellos. Asimismo, también permite anadir dependencias entre otros artefactos de forma manual e incluso asociaciones, donde la dependencia no está ligada a un recurso sino a un tipo.

Organizar el conjunto de servicios. Galaxy maneja el concepto de espacio de trabajo (workspace). Dentro de cada workspace, los artefactos se organizan por su tipología. La información mostrada por cada artefacto depende del tipo del mismo existiendo una propiedad que está presente en todos ellos: la versión. Es posible anadir vistas personalizadas que pueden incluir diversos criterios de selección que pueden ser especificados utilizando un asistente o bien introducirlos directamente a través del Galaxy Query Language (GQL). El GQL es un lenguaje similar a SQL como se aprecia en la sentencia de la figura 3.

Fig. 3. Ejemplo de GQL

G-Reg utiliza el concepto de colección  como una agrupación de recursos. Además proporciona mecanismos para poder clasificar los servicios a través de etiquetas o incluso dándoles una puntuación.

Búsquedas en el repositorio. Haciendo uso de las vistas, Galaxy permite localizar los artefactos con relativa facilidad. Además es posible anadir y gestionar índices para facilitar la búsqueda de servicios. Sin embargo, esta funcionalidad está disponible tan sólo en la edición Enterprise de la herramienta.

Por su parte, G-Reg suministra vistas específicas para los servicios, políticas y documentos WSDL/XSD proporcionando además una ventana de búsqueda avanzada que permite localizar artefactos a partir de múltiples criterios (etiquetas, comentarios, fechas de creación-actualización, etc.). La figura 4  muestra dicha ventana.

Fig. 4. Búsqueda de artefactos en G-Reg

4.1. Gestión del Ciclo de Vida de los Servicios

Gestionar el ciclo básico de servicios. Galaxy soporta el ciclo de vida  básico de un servicio, el cual incluye las fases habituales del desarrollo de un servicio. Las definidas por defecto son: Created, Developed, Tested, Production, Retired. Tanto las fases como su secuencia son modificables de forma que podemos adaptar y personalizar este workflow a nuestras necesidades.
En G-Reg la gestión del ciclo de vida es similar siendo las fases por defecto: Initialize, Designed, Created, Tested, Deployed, Deprecated.

Integrar un workflow que permita la promoción de los servicios. Galaxy integra un workflow (que puede ser modificado) que permite la promoción de los servicios, esto es que permite la aprobación por parte de un arquitecto SOA del paso de un servicio de diseno a desarrollo, de desarrollo a pruebas, etc. Sin embargo, a pesar de poder anadir nuevos roles a usuarios e incluso utilizar LDAP para la autenticación, no es posible indicar a la herramienta que algunas transiciones requieren de un perfil de usuario concreto. En este sentido Galaxy resulta incompleto.

G-Reg permite definir, para cada fase del workflow, las listas de chequeo de forma que sólo se puedan promocionar los servicios cuando se cumplen todas las condiciones. Dichas listas de chequeo son fácilmente configurables. En cuanto a la gestión de usuarios, implementa mecanismos basados en roles y permisos para el acceso a la distinta funcionalidad de la herramienta. No obstante, en las pruebas realizadas hemos comprobado que el nivel de granularidad no es el adecuado, por ejemplo: no se pueden tener perfiles que únicamente promocionen los servicios de una fase a otra. Igualmente hemos detectado algunos errores en la gestión de permisos.

Administrar versiones de los servicios. Galaxy gestiona adecuadamente el versionado de artefactos. Crear una nueva versión resulta sencillo. Es posible marcar la versión anterior como deshabilitada. En el caso de documentos WSDL es posible especificar una política de compatibilidad con versiones anteriores, de forma que la herramienta nos avisa si una nueva versión del documento resultara incompatible con la versión anterior. Como ejemplo de la validación mencionada, en la figura 5 se muestra el mensaje de error de Galaxy cuando intentamos registrar una nueva versión de un servicio sin una de las operaciones de la versión anterior.

Fig. 5. Gestión y control de distintas versiones de un servicio web en Galaxy

G-Reg también permite la gestión de versiones de servicios asignando automáticamente una nueva versión cada vez que se realiza una modificación. Senalar que utiliza un mecanismo de auto-incremento para el identificador de las versiones que es común para todos los artefactos, algo que sin duda no ayuda a su identificación y trazabilidad.

Ejecución de pruebas de servicios. Galaxy no tiene soporte para la ejecución de pruebas de servicios. A pesar de esta limitación, es posible anadir trabajos planificados para la ejecución desde la herramienta. Con este mecanismo, e implementando clases ad-hoc, se podría automatizar la ejecución de pruebas de servicios. También es muy sencillo integrar Galaxy con Mule ESB con lo que podríamos tener servicios de pruebas de servicios dentro del ESB e invocarlos de forma planificada desde Galaxy.

G-Reg tampoco tiene soporte para la ejecución de pruebas de servicios, aplicando los mismos comentarios que para Galaxy (es decir, se podría integrar con WSO2 Web Services Application Server - WSAS).

4.3. Políticas, Métricas, Monitorización y Configuración

Implementación de diversas políticas estándares. Galaxy incluye algunas políticas en su distribución. Una de ellas es la que obliga, si se activa dicha política, a que los documentos WSDL cumplan la especificación WS-I Basic Profile 1.1. Otra política asociada a los documentos WSDL es la relativa a la compatibilidad entre versiones de este tipo de artefactos. También permite establecer qué políticas entran en acción según la fase del ciclo de vida de los servicios.

En cuanto a G-Reg, durante la importación de WSDL y esquemas, a pesar de mostrar un mensaje indicando al usuario que se están realizando validaciones en el WSDL hemos podido comprobar que no avisa de errores en los mismos.

Adición y configuración de nuevas políticas. Galaxy permite anadir nuevas políticas de forma programática (no desde la consola de administración), proporcionando un API para el desarrollo de políticas personalizadas.
G-Reg por su parte, sí permite anadir nuevas políticas desde la propia consola, lo que hace más fácil su uso. Sin embargo, según las pruebas realizadas, no parece que las tenga en cuenta a la hora de anadir nuevos servicios al registro.

Métricas para monitorizar los servicios en ejecución. Galaxy conoce el estado de los servicios tan sólo como consecuencia de la modificación de la fase en la que se encuentran y no como resultado de ninguna prueba de ejecución o similar. Es el único indicador que se muestra en la herramienta. No obstante, Galaxy contiene un API relativo a eventos que permite registrar una traza de la actividad de la herramienta. Este API facilita el registro de listeners lo que nos permite reaccionar ante cualquier evento generado en el motor de la herramienta. Los listeners pueden registrarse indicando su forma de ejecución: síncrona y asíncrona.
G-Reg sí proporciona métricas interesantes relacionadas con la ejecución de los servicios como 'Mensajes recibidos en el último minuto',  'Numero de llamadas en las últimas 24 horas', 'Tiempos medios, máximo y mínimo de ejecución' o incluso métricas de seguridad (autenticaciones erróneas) así como un gráfico donde aparece el estado, según el ciclo de vida, de los servicios registrados.

Interfaz gráfica amigable para las métricas de monitorización. Galaxy no proporciona ninguna interfaz gráfica específica para métricas ya que no las contempla como tal. La companía tenía pensado incluir en su roadmap [10] el lanzamiento de Mule Saturn, una herramienta BAM para la monitorización de su infraestructura SOA (ESB y Galaxy) aunque dicho producto finalmente no ha salido a la luz.
G-Reg sí proporciona un  cuadro de mando que permite monitorizar gráficamente las métricas identificadas anteriormente. La consola es atractiva al estar implementada con portlets utilizando la especificación 'Google Gadget'. La figura 6 muestra dicho cuadro de mando. En su contra, dicha consola únicamente es capaz de monitorizar los servicios ejecutados dentro del propio contenedor de WS02 (WSO2 Web Services Application Server - WSAS). Lógicamente, es el propio contenedor el que mediante notificaciones alimenta los indicadores que se muestran en la consola.
Una mejor opción sería que esta herramienta actuara como un proxy ubicado entre los clientes y los proveedores de servicios de manera que, sin necesidad de modificar los servicios, por tanto de forma no intrusiva, fuera capaz de detectar y medir la actividad de los mismos. Esta opción daría mayor flexibilidad no obligando a utilizar un servidor concreto ni obligando a la modificación de los servicios para realizar las notificaciones oportunas a la herramienta BAM.

Notificar la ocurrencia de distintos eventos. Galaxy permite la sindicación (RSS) relativa a tres niveles: workspace, artefacto y comentarios. La sindicación de cada workspace notifica el alta o baja de artefactos. La sindicación de cada artefacto notifica cualquier modificación sobre el mismo, incluido su versionado. La sindicación de comentarios es global, cualquier comentario anadido a cualquier artefacto de cualquier workspace provocará una nueva entrada RSS. Aunque Galaxy registra todos los cambios realizados sobre un artefacto, el RSS tan sólo muestra el versionado y el momento en el que se ejecuta una modificación sobre el mismo.
G-Reg incluye una herramienta para la gestión de notificaciones sobre eventos producidos tanto a nivel de artefacto o de colección. Los mecanismos de notificación incluyen  el envío por email (a un usuario o a un grupo), así como la generación y envío texto plano/HTML o mensajes SOAP. Entre los tipos de eventos, además de la creación/modificación/borrado de elementos se incluye el cambio de estado dentro del ciclo de vida. También es posible sindicarse a través de RSS a los recursos registrados en la herramienta.

Fig. 6. Cuadro de Mando BAM de G-Reg

Una comparativa final de ambas herramientas se recoge en la tabla 1.

4.4 Criterios comerciales

Edición Community vs Edición Enterprise. La existencia de una edición para la comunidad open source y una edición empresarial es un criterio a tener muy en cuenta a la hora de decidirse por una herramienta. Como en una buena parte de las herramientas disponibles para la comunidad Open Source, Galaxy tiene un "hermano mayor" en forma de edición Enterprise, que soporta algunas características que se echan de menos en la edición Community y otras que sin ser indispensables pueden resultar interesantes.  Algunas características únicamente recogidas en la versión Enterprise son workspaces remotos (repositorios federados), el balanceo de carga y alta disponibilidad y como no, una mayor y mejor documentación del producto. En el caso de  G-Reg no se dispone de Edición Enterprise.
La tabla 2 recoge la evaluación de ambas herramientas con respecto a los restantes criterios comerciales identificados:

La industria está de acuerdo en afirmar que las companías fallarán en la implantación de SOA si no implementan de forma efectiva un Gobierno SOA. La complejidad en la implantación de un proyecto SOA ya no está en el modelo tecnológico, donde afortunadamente se han desarrollado muchos estándares - tal vez demasiados - y soluciones, sino en facilitar a los departamentos de TI la gestión integral del ciclo de vida de los servicios y la implantación de las políticas establecidas.

Se hace por lo tanto indispensable,  además de un correcto enfoque metodológico, el poder contar con herramientas útiles para la implantación de todo, o de al menos parte, de los objetivos que establece un Gobierno SOA.

Como podemos imaginar, no es posible disponer de una única herramienta que proporcione todas las características necesarias para el Gobierno SOA. En este artículo se ha definido un conjunto de características técnicas y criterios comerciales para la selección de herramientas de Gobierno, distinguiendo los criterios de herramientas en tiempo de diseno (DTG) y en tiempo de ejecución (RTG).

A pesar de esta separación hemos seleccionado dos herramientas Open Source que declaran abiertamente cumplir con las características de herramientas DTG y RTG, Mule Galaxy 1.5 Community Edition y WS02 Governace Registry 3.0.
La evaluación realizada llega a la conclusión de que ninguna herramienta cumple totalmente con la funcionalidad que se espera de una herramienta de Gobierno, siendo ambas soluciones consideradas como "adecuadas" para comenzar a implantar un Gobierno SOA aunque insuficientes. Al ser ambas herramientas Open Source -y gratuitas en su versión Community- nos permite "aligerar" el presupuesto de los proyectos SOA en los actuales tiempos de crisis como los que vivimos. 

Las características definidas deben entenderse como la "mínima" funcionalidad que un equipo de arquitectura, desarrollo o de explotación en un proyecto SOA "espera" que sean cubiertas por una herramienta de Gobierno. El trabajo futuro puede centrarse en anadir nuevas características a partir de la experiencia de uso de las herramientas en proyectos reales (por ejemplo rendimiento o incluso usabilidad), complementarlas con otros criterios basados en modelos de calidad así como anadir métricas e indicadores para la evaluación objetiva de los criterios definidos.

Asimismo sería interesante poder evaluar las características identificadas en herramientas comerciales declaradas independientes del proveedor de infraestructura SOA (ESB/motor BPM) como son las soluciones de AmberPoint [11] o Actional [12].

Referencias

[1] Bastida, Leire. "Gobierno SOA: Elemento Clave en la Integración de Negocio y Tecnología", JSWEB'08, Sevilla, Octubre 2008
[2] Cámara, Javier. "Recomendaciones para la adopción de SOA" JSWEB'08, Octubre 2008
[3] Gartner. "Magic Quadrant for Integrated SOA Governance Technology Sets", Research ID Number: G00166481, Marzo 2009
[4] Forrester. "The Forrester WaveT: SOA Service Life-Cycle Management, Q1 2008", The Forrester Wave, Enero 2008
[5] Hariharan. "SOA Life-Cycle Vs Mule Galaxy", Toolbox for IT, May 2009
[6] Join Deepal Jayasinghe, "Open Source Competition - Mule Galaxy vs WSO2 Registry",  WSO2 Portal, Julio 2008
[7] Gerardo Porras Cedeno, "SOA Governance", Radar IT, Abril 2008
[8] Mule Galaxy, www.mulesource.org/display/GALAXY/Home
[9] WS02, Open Source SOA Company, http://wso2.org
[10] Brajeshwar Oinam, "Mule Galaxy: Mule Source's Open Source SOA", brajeshwar.com, Octubre 2008
[11] Amberpoint,  http://www.amberpoint.com/
[12] Actional, http://www.actional.com/solutions/soa-governance/