En varias entradas de este blog, por ejemplo ¿Cómo identificar los servicioso de negocio en SOA?, he tratado el tema de la identificación de servicios (o “levantamiento” como dicen algunos) en una organización. La razón de ello es que lo considero una de las tareas más importantes, y quizás la más difícil, que puede haber en la implantación de una arquitectura orientada a servicios.

Es por esto que no me resisto a sacar a colación este estupendo artículo, Ten ways to identify services, que trata precisamente este tema, haciéndose las típicas preguntas que a todos nos asaltan cuando estamos en esta situación: ¿el servicio es demasiado genérico? ¿demasiado específico? ¿de grano fino? ¿de grano grueso?.

Evidentemente, la identificación de un servicio tiene mucho de subjetivo o de intuición y es posible que dos personas ante una misma casuística de negocio obtengan dos servicios diferentes. Sin embargo, existen por supuesto varios consejos, reglas o recomendaciones que deberíamos seguir para llevar a a cabo esta tarea.

En el artículo que mencionaba antes, recomiendan antes de nada seguir estas tres reglas:

  1. Tener en cuenta los principios de SOA
  2. Encuadrar los servicios según su tipo, por ejemplo, servicios de negocio, servicios de proceso, servicios de aplicación, servicios de datos, etc.
  3. La consideración de que un servicio está bien identificado dependerá del perfil de quien lo haga, no es lo mismo una analista de negocio que un diseñador de procesos de negocio.

En cuanto a las maneras de identificación de los servicios propiamente dichas realiza unas reflexiones muy interesantes:

  • A partir de los procesos de negocio, por descomposición, se identifican los servicios necesarios. Esto tiene como ventaja que obviamente los servicios que creamos responden a una necesidad de negocio. Sin embargo se corre el peligro de que estos servicios se queden en el terreno de lo teórico, es decir, que sea muy difícil implementarlos en la realidad con la infraestructura disponible.
  • Partir del modelo de entidades de negocio. Esto suele provocar la aparición de servicios del tipo CRUD por lo que se recomienda establecer modelos de datos canónicos para estandarizar el intercambio de datos entre los servicios, aunque lo difícil por supuesto es consensuar este modelo de datos canónico.
  • Dirigido por objetivos de negocio (goal driven). En este caso se “traducen” a servicios directamente los objetivos o metas de la empresa. Por ejemplo, si una agencia de viajes tiene el objetivo de “vender billetes de bajo costo” entonces tendremos un servicio llamado “reservarBilleteConDescuento”.
    A favor tiene que obviamente se alinea con los objetivos de negocio al ser una derivada directa de los mismos. Por contra, este método tiene la inevitable subjetividad de definir los servicios a este nivel
  • Basados en componentes. Los componentes son piezas o módulos de software reutilizables con bajo acoplamiento y máxima cohesión interna por lo que son buenos candidatos para construir servicios a partir de ellos.
    Con esto se corre el peligro de que los componentes, que pueden estar hechos desde hace tiempo no encajen con a orientación a servicio o simplemente no respondan a la funcionalidad de negocio que se necesita.
  • Partir de lo existente (Bottom-up). Es la conocida técnica de partir de los servicios de bajo nivel ya existentes para ir combinándolos progresivamente para obtener servicios de más alto nivel que ya respondan a necesidades de negocio. A favor de forma de identificación está en que se reaprovechan el software actualmente existente en la empresa aunque se hace problématico el orientar los servicios resultantes a una verdadera orientación a servicios de negocio ya que el resultado normalmente son servicios muy específicos y poco reusables.
  • Análisis de las necesidades de la aplicación de frontal (frontend): analizando la aplicación web o de escritorio que sirve de interfaz con el usuario se puede ver rápidamente los servicios que necesita. Por ejemplo, si en una pantalla se listan los vuelos entre dos destinos, obviamente se necesitará un servicio en el que le pasas estos criterios y te devolverá un listado con la consulta que se necesita para presentar los datos al usuario.
    Sin embargo, este enfoque tiene un problema importante, estamos “acoplando” nuestros servicios a una aplicación de frontal cuando los servicios deben ser “agnósticos” sobre quién los invoca. Además casi con total seguridad, los servicios resultantes serán muy específicos para ese caso concreto de frontal.

Como conclusión vemos que existen varias técnicas o métodos para identificar servicios pero ninguno es perfecto. Hay que mentalizarse para no intentar buscar una solución definitiva al problema de la identificación de los servicios desde el primer momento sino realizar varias iteraciones de refinamiento. Esto es, en una primera pasada obtener una lista de de servicios “candidatos” que por descarte se irán reduciendo hasta obtener la lista final de lo que serán los servicios de negocio.

Por otra parte, lo que sería “la prueba del algodón”, si estamos definiendo servicios de negocio podríamos hacer el ejercicio de presentarle a un usuario de la aplicación (que se pega con ella todo los días) si entiende la identificación que hemos hecho del servicio. Es decir si en una agencia de viajes identificamos el servicio “desbloqueo de registros” seguramente no entenderá nada. Por el contrario si mostramos el servicio “reservarVuelo(Origen, Destino)” con toda seguridad, sin necesidad de conocimientos técnicos, sabrá perfectamente de qué estamos hablando y entonces habremos identificado realmente un servicio de negocio.