Anteriormente, en este mismo blog, ya he tratado esta parte de SOA que quizás no se le está dando la importancia que tiene. Me refiero al gobierno SOA que podeis ver aquí.

Cuando empecé a leer documentación sobre todo lo referente a la gobernanza de SOA me dio la sensación de que se usa a veces un lenguaje demasiado complejo para algo que es relativamente sencillo. Y es que en esencia, el gobierno SOA son unas mínimas normas y prácticas para poner orden en la anarquía en que puede desembocar un sistema T.I. basado en cientos o miles de servicios que se llaman entre sí, en los que unos se componente de otros más sencillos, que tienen un ciclo de vida, etc. etc.

El objetivo de esta entrada, por lo tanto, es tratar de una manera sencilla pará que sirve el gobierno SOA y también, por qué no, plantear una sencilla herramienta que nos permita gestionarlo de alguna manera. Está claro que es mejor tener una herramienta sencilla que no tener ninguna. Más adelante se verá claro el por que.

Este semana he estado poniendo en mi twitter algunas preguntas que me planteo en mi trabajo diario con la organización de los servicio se negocio de la empresa:

  1. ¿quien usa mi servicio? ¿a quién afecto si lo modifico?
  2. el servicio que necesito ¿ya existe?
  3. si el servicio que necesito ya existe pero necesito que se haga una modificación en él ¿a quién se lo pido?
  4. Por último, pero no menos importante: ¿mi servicio es útil para el resto de la organización?
El último punto es fácil de decir y muy difícil de llevar a la práctica. Y por una razón bastante fácil de entender: un servicio útil para el resto de la organización y por lo tanto reutilizable en el futuro es más caro (en términos de tiempo y dinero) de diseñar e implementar que un servicio que únicamente responde a mis propias necesidades. En un contexto típico de un proyecto, con la premura de tiempo y con un presupuesto ajustado, es muy difícil lograr esto. Este es uno de los mayores retos que tenemos para que SOA sea un exito en la organización.

La herramienta

En una organización que maneja cientos o miles de servicios, si queremos responder a las tres primeras preguntas, necesitamos una herramienta software que nos ayude en la tarea. Hay que tener en cuenta que seguramente tendremos un contexto con decenas de personas implicadas, e incluso varias empresas proveedoras que necesitan esa información.
Por supuesto, hay en el mercado (de los principales fabricantes como IBM y Oracle) herramientas de este tipo. Pero es que en ocasiones, la utilidad de una herramienta para nuestro caso particular no tiene que ir pareja a su precio o a su complejidad. En ocasiones, una herramienta sencilla es mejor.

En la figura anterior, vemos las entidades que mínimamente se necesitan para lograr la funcionalidad que necesitamos. he omitido en el diagrama los atributos de las clases por claridad.

  • Consumer: es el consumidor del servicio web. Típicamente es un frontal (Frontend) u otro servicio web. Está definida como una clase abstracta con dos especializaciones (Frontend y WebService)
  • WebService: es la clase principal. Aquí se recogerán los metadatos necesarios como el identificador del servicio, el responsable funcional del mismo, quizás también el responsable técnico.
  • Se establece una relación «invokes» entre el Consumer y el WebService. Es decir, un servicio puede invocar a otro. Por ejemplo un servicio compuesto, que integra otros dos servicios, aparecerá como que invoca a estos dos.
NOTA:  la parte que hace referencia a la seguridad (clase Security), lo veremos en una próxima entrada de este blog. 
Mediante la relación «invokes» se establecerán llamadas recursivas de unos servicios a otros en relación a los servicios compuestos que vayamos teniendo. 
Con este diagrama de clases que puede tener una traducción inmediata a un modelo de datos en una base de datos relacional, podemos hacer una sencilla aplicación que nos puede ayudar en gran medida (se puede hacer incluso con Microsoft Access).
  • ¿quién usa mi servicio?: Navegando por la relación invokes, de manera recursiva hacia atrás, podemos ver para un servicio quien lo está llamando. De este modo obtendremos un análisis de impacto de los servicios afectados por un posible cambio en un servicio concreto.
  • el servicio que necesito ¿ya existe?: Con los metadatos suficientes en la clase WebService podemos hacer una búsqueda y ver si el servicio ya existe. Esto se puede complicar si añadimos una clasificación con una taxonomía, búsqueda en texto libre, etc.
  • ¿a quíen le pido una modificación del servicio?: una vez localizado el servicio, se tiene la información de contacto en el atributo de responsable funcional. Únicamente habrá que pedirle a esta persona la modificación del servicio que necesito.

Conclusión

No descuidemos la parte del gobierno SOA que nos permite saber cuestiones tales como las planteadas en esta entrada. Si no, nos encontraremos con cientos de servicios sobre los que muy difícilmente podremos tener un mínimo control.
Comparte esta entrada:

Share