Un servicio, como cualquier software, tiene un ciclo de vida definido, desde su análisis hasta su retirada de producción. Sin embargo, un servicio no es exactamente igual que un programa tradicional, y su ciclo de vida tiene también algunas diferencias.
No es mi intención hablar de metodología. Hay muchos libros sobre esto. Sin embargo, me gusta ser práctico y en mi opinión, el ciclo de vida de un servicio web debería ser algo parecido a esto:
- Identificación del servicio
En esta etapa se identifica la necesidad de un nuevo servicio para responder a un requerimiento de negocio. Se registra el nombre del servicio y una descripción de su funcionalidad.
Un servicio debe responder a una necesidad de negocio, así que la identificación del mismo debería hacerlo un analista funcional o incluso alguien de negocio. - Análisis orientado a servicios
Se realiza el análisis del servicio con arreglo a la metodología de desarrollo (que estará orientada obviamente a servicios). Entre otras cosas hay que ver si responde a una necesidad de negocio, si es reutilizable, si no está construido ya, etc. ec. - Definición técnica del contrato
Se define el contrato del servicio, con su interfaz de entrada/salida. En el caso de un servicio web, sería el fichero WSDL.
Todavía no está implementado, pero sin embargo ya es utilizable: con el WSDL por ejemplo, se puede hacer un servicio dummy generado por una herramienta que puede servir por ejemplo, para desarrollar le interfaz gráfico de una aplicación que llama a este servicio. - Validación del servicio
En esta etapa, el rol designado por el gobierno SOA, validará el servicio según esté bien definido, no exista ya y el servicio sea reutilizable. - Diseño
Diseño técnico de la implementación del servicio y depende de la arquitectura de desarrollo empleada - Construcción.
Desarrollo del servicio con la herramienta de desarrollo y el framework de desarrollo.
Gracias a que tenemos el contrato, la construcción de la parte cliente y de la parte servidora se puede “desacoplar“, incluso hacerla equipos diferentes en un momento diferente. - Pruebas de integración
Pruebas de integración con otros servicios. En el ambiente local de desarrollo se usarán servicios dummies para simular la llamada a los servicios reales.
Estas pruebas en SOA pueden ser un verdadero dolor de cabeza. - Producción
El servicio se pone en producción (tras pasar por los diferentes entornos de desarrollo y preproducción). En esta etapa, el servicio recibe las invocaciones de sus clientes. - En retiro
El servicio se marca para su retirada. Aunque sigue en producción, este es el tiempo que tienen los clientes para adaptarse a su retiro (por ejemplo 6 meses). Normalmente, esto significará que tiene que invocar a una nueva versión del servicio. - Retirado
El servicio finalmente deja de estar en producción. Los clientes ya se tienen que haber adaptado para no invocarlo.
¿Echais en falta algún estado más? ¿Os sobra alguno?
16/10/2013 at 20:52
Excelente artículo Andrés!!!
Personalmente echo en falta la parte del mantenimiento del servicio. ¿Qué ocurre cuando es necesario cambiar el contrato del servicio como añadir una nueva operación o modificar los parámetros de entrada o salida de alguna ya existente? ¿Cómo gestionamos los avisos a los consumidores de dicho servicio sobre este cambio? ¿Se deben mantener o no diferentes versiones del servicio en producción en función del periodo de adaptación de los consumidores?
Saludos.
17/10/2013 at 09:34
Hola Miguel:
Como bien comentas, el mantenimiento del servicio es un aspecto clave en SOA. Por resumir, habría que mantener más de una versión del mismo servicio en producción si se aplica un cambio que es incompatible hacia atrás. Si el fin de la nueva versión es sustituir a la primera, habría que dar un tiempo a los clientes para que se adapten al cambio, por lo que es imprescindible avisarles. Ya existen herramientas en el mercado en este sentido, donde el cliente se suscribe a un servicio y es avisado de cualquier cambio en éste.
Lo difícil en este caso es saber cuando un cambio es compatible hacia atrás. Por ejemplo se suele aceptar como un cambio de este tipo cuando se añade una nueva operación al servicio.
Saludos
25/10/2013 at 18:55
Andrés. En el ciclo de vida del servicio que herramienta de alm nos podria ayudar para automatizar esto.?
Tipo Rational de ibm
25/10/2013 at 19:21
El ALM sirve para automatizar la la compilación, test, empaquetado e incluso el despliegue del software. El servicio al fin y al cabo es un software que hay que desarrollar. Por otra parte una opción open source basada en Jenkins o Hudson puede ser perfectamente válida.
19/11/2014 at 17:41
Hol Andrés, muy bueno tu blog.
Personalmente pienso que antes de la definición técnica del contrato, debe existir la validación de gobierno para comprobar si el servicio es nuevo o reutilizado.
Adicional, me gustaría saber si tienes material o documentación adicional sobre el ciclo de vida de un servicio que me puedas proporcionar.
Gracias.
20/11/2014 at 19:49
Hola:
Gracias.
Precisamente lo que dices que hay que hacer antes de la definición técnica del contrato se indica en el punto anterior (Análisis Orientado a Servicios) donde se mira si el servicio ya está construido…
Sobre lo de la documentación adicional, mándame un email a andres.hevia@gmail.com y lo hablamos.
Saludos
23/08/2016 at 15:42
Andrés, pregunta, estas etapas de ciclo de vida son obtenidas en base a tu experiencia o corresponden a definición de alguna arquitectura de referencia ??
Gracias!
23/08/2016 at 16:29
Hola. Pues creo que una mezcla de las dos cosas. Puedes ver algo de documentación al respecto en los temas de governance en SOASCHOOL.
23/08/2016 at 19:32
🙂 gracias nuevamente!
05/05/2018 at 23:07
me podría ayudar en como debemos aplicar el ciclo de servicio
06/05/2018 at 09:16
Hola. Pues es una gran pregunta… 😉
Lo que se suele hacer es nombrar un grupo responsable del gobierno SOA que sea el que valide los servicios y los pueda cambiar de fase. Por ejemplo, que no se pueda desplegar sin su aprobación.
Aquí puedes ver las fases y los roles que intervienen.
Espero que te sirva como comienzo.
Saludos