Calidad, Auditoria, Capacitación & Certificación

Tel.: 2525 5583

Análisis orientado a servicios

By Andrés Hevia

customer-563967_640

 

 

 

 

 

El análisis orientado a servicios es, quizás, uno de los grandes desconocidos en la adopción de SOA. Para los que no están acostumbrados a abordar un proyecto SOA, y se basan en su conocimiento de un análisis digamos que tradicional, este uno de los aspectos que les cuesta más habituarse.

Por supuesto, el análisis orientado a servicios tiene unas particularidades que hay que tener muy en cuenta: desde las fases del mismo, los productos a obtener hasta la forma de hacerlo.

Pasos en el análisis SOA

La fase de analísis SOA se puede en tres pasos consecutivos:

  1. Definición del alcance del análisis
  2. Identificar los sistemas existentes
  3. Modelar los servicios candidatos

Realmente, los dos pasos primeros son una preparación para el tercero, donde se recoge información para poder hacer el modelado de los servicios.

Definición del alcance del análisis

Como es sabido, un servicio tienen que aportar un valor de negocio. Es decir, tiene que hacer que hacer algo que responda a un requerimiento de negocio. Obviamente, para hacer esto, lo primero que tenemos que hacer es obtener estos requerimientos.

Idealmente, los requerimientos deben estar totalmente definidos, ser coherentes, completos, etc. etc. Claro que tampoco deberemos sorprendernos cuando no sea así (esto es habitual en el desarrollo de software).

Sin embargo, en el caso de los servicios, tenemos un factor que tener en cuenta: cuando se libera un servicio, lo hacemos con un contrato cerrado. Si un cambio de un requerimiento o la aparición de uno nuevo implica el cambio en el contrato del servicio (por ejemplo, un nuevo parámetro de entrada o de salida del servicio) nos encontraremos con un problema.

Y es que los cambios internos en la lógica de negocio, quizás los podamos asumir sin afectar a los consumidores del servicio, pero los cambios en el contrato son harina de otro costal.

Dependiendo de la importancia del cambio y de la tecnología que empleamos para implementar este servicio puede implicar el que tengamos que hacer una nueva versión del mismo.

Así pues, ojo con los cambios en los requerimientos que puedan afectar al contrato.

Así pues, en defintivia, el objetivo de este paso del análisis sería tener claro qué es lo que vamos a hacer y, muy importante, qué es lo que no vamos a hacer.

Identificar los sistemas existentes

Lo ideal sería desarrolar una nueva solución software a partir de cero. Por desgracia, esto no se da casi nunca. Así pues, tendremos que lidiar con los sistemas y aplicaciones existenes.

Muchas de estas aplicaciones serán sistemas legados implementados en tecnologías muy viejas o directamente obsoletas que fueron diseñados en modo silo. Esta lógica de negocio no orientada servicios deberá ser recubierta con un servicio y dependerá de cada caso concreto.

En este caso uno de los aspectos que tenemos que cuidar es analizar la autonomía y abstracción de los mismos:

  • Autonomía: seguramente, tratándose de lógicas o programas que llevan años usándose, el servicio que hagamos será una de las formas de acceder a esta lógica y los datos que maneja. Quiero decir con esto que no se van a sustituir las formas de acceder a la lógica por la invocación al nuevo servicio que la recubre (ojalá). Por lo tanto, el servicio carecerá total o parcialmente del principio de Autonomía de SOA y esto puede afectar desde al rendimiento del servicio a la coherencia de los datos.
  • Abstracción: mediante el principio de abstracción nos aseguramos que los detalles internos del servicio trascienden lo menos posible a los consumidores. Una mala práctica habitual en la envoltura de una lógica de negocio ya existente es que los detalles de la implementación de la misma (como la nomenclatura de los campos del interfaz) se exponen tal cual al cliente. Esto se debe evitar totalmente, aunque por supuesto, nos obligará a invertir más esfuerzo.

Modelar los servicios candidatos

Este paso es realmente donde se hacen cosas de SOA. En los pasos anteriores únicamente hemos recopilado información para acometer este.

Según la teoría de los libros de Thomas Erl, este paso se compone a su vez de 12 pasos, aunque por resumir, lo he dejado en 9:

  1. Descomponer los procesos de negocio. Es decir, tomar la documentación existente del proceso de negocio y descomponerlo de la forma más granular posible. Normalmente hay diferencia en el nivel de granularidad en el que está definido el proceso y el que necesitamos para el análisis de los servicios. Por ejemplo, si un paso del proceso es algo tan simple como “informar al usuario de la oferta X” quizás tengamos que descomponerlo en varios pasos como podrían ser:
    • Obtener el email del usuario a partir de su identificador
    • Generar el documento con la oferta
    • Actualizar el contador de ofertas para ese usuario
    • Enviar oferta
    • Etc, etc.
  2. Eliminar aquellos pasos no susceptibles de ser un servicio. Por ejemplo, tareas manuales que no se van a automatizar
  3. Identificar servicios agnósticos candidatos
    • Los servicios candidatos son aquellos que finalmente serán un servicio o tal vez no. Quizás en una fase posterior se eliminen o se fusionen con otros para implementar un único servicio
  4. Identificar lógica específica del proceso
    • A diferencia de los servicios agnósticos, estos no son reutilizables y tienen sentido únicamente en el contexto de este proceso específico.
    • Definen reglas de negocio especificas del proceso, logicas condicional (de bifurcación en el flujo del proceso, secuencias de invocaciones a servicios, etc.)
  5. Aplicación de los principios de orientación de servicios: reutilización, autonomía, descubrimiento, …
  6. Identificar los escenarios más comunes que pueden darse dentro de los límites del proceso de negocio, incluyendo aquellos escenarios de error
  7. Analizar los requerimientos del proceso. Esto implica que debemos fijarnos en este momento en aquellos requerimientos que no son de negocio, si no más bien técnicos. Por ejemplo, enviar un mensaje SMS al cliente nos indicará la necesidad de un servicio técnico que utilize un operador de telefonía para enviar un SMS (no implementa una lógica de negocio).
  8. Revisar las composiciones de servicios candidatas. En este paso, se revisan los escenarios definidos anteriormente para ver si finalmente se consolidan las composiciones de servicios identificadas. Típicamente un escenario se implementará mediante la composición u orquestación de servicios.
  9. Revisar las capacidades de los servicios y su agrupamiento. Las capacidades de los servicios se suelen traducir como métodos u operaciones de los servicios. Según lsa normas de análisis y diseño de la empresa el modo de agrupar estas capacidades puede variar. Desde el extremo de tener una sola capacidad (operación) por servicio hasta tener un servicio con las capacidades relacionadas. Por ejemplo un servicio que gestiona la entidad Cliente podrá tener “crearCliente”, “borrarCliente”, “promocionarCliente”, etc. etc.

Source:: Pensando En SOA