strategy-791200_640

Uno de los aspectos en los que tenemos que poner especial interés es en la estrategia de versionado de los servicios que queremos seguir. Contrariamente a lo que se suele ocurrir con el desarrollo de una aplicación web, es posible que tengamos más de una versión de un servicio simultáneamente en producción.

Esto, obviamente, significa que puede haber consumidores del mismo servicio que utilizan diferentes versiones del mismo con lo esto conlleva en cuanto a la gestión de su ciclo de vida.

Así pues, tenemos mínimamente que pensar sobre como vamos a gestionar las versiones del servicio y para ello debemos tener una estrategia definida. Debemos pensar primeramente cuando surge una nueva versión y también cuando se debe retirar una versión de producción.

¿Qué debemos tener en cuenta?

Hay cuatro conceptos que debemos tener claros en la empresa. Y cuando digo claros, quiero decir que es conveniente tener una definición por escrito que todo el mundo pueda leer y comprender. Aunque en un principio son conceptos sencillos veremos que muchas veces es realmente complicado “cerrar” su defnición.

Cambio compatible vs Cambio incompatible

Entendemos por cambio compatible aquel que podemos realizar sin “romper” nada. Es decir, sin que los consumidores actuales dejen de funcionar u tengan un mal funcionamiento. El problema con el que nos encontramos a menudo es ¿Cómo sabemos si un cambio es compatible?

Si estamos hablando de servicios SOAP, se suele aceptar por ejemplo, que añadir una nueva operación al servicio es un cambio totalmente compatible ya que los antigos consumidores ni siquiera tienen que saber que existe. Los nuevos consumidores, lo pueden usar tranquilamente y el servicio en el servidor es perfectamente capaz de responder a las invocaciones a las antiguas operaciones y a las nuevas.

Sin embargo, cuando hablamos de introducir por ejemplo un nuevo campo de salida. Es decir, un nuevo campo que antes no devolvíamos y que ahora incorporamos a la respuesta, por ejemplo, un simple campo de hora en la que se informa de la hora en la que se ha procesado el mensaje. ¿Esto es compatible?.

El problema que tiene SOA es que no tenemos por qué saber nada de los consumidores. Al tener un bajo acoplamiento, los consumidores pueden haber sido escritos en casi cualquier lenguaje y correr sobre cualquier middleware y sistema operativo. Así pues ¿podemos estar seguros de que añadir un parámetro más en la respuesta es seguro y compatible? Pues me temo que no, que no podemos estar seguros al 100%.

Algunas utilidades de generación de clientes o proxies, se ejecutan prácticamente en su totalidad en runtime. Así que es posible que cuando se analice el WSDL con el nuevo parámetro o incluso cuando se haga el parsing del SOAP de respuesta, y se haga un mapeo de los campos de salida, no concuerde excatamente con el mensaje que teníamos antes y se produzca un error de ejecución. Parece un poco rebuscado, pero puede darse el caso…

Compatiblidad hacia atrás y compatibilidad hacia adelante

La compatibilidad hacia atrás es precisamente la garantía de que todo cambio que habamos no vamos a afectar negativamente a los consumidores que ya teníamos.

El concepto de compatiblidad hacia adelante es un poco más etéreo. Viene a decir que vamos a poder dar soporte a futuros consumidores, por lo que vamos a ser capaces de adaptarnos a como los consumidores van a evolucionar con el tiempo.

En la práctica esto se puede traducir en algunas acciones concretas y sencillas. Por ejemplo:

  • El servidor puede ignorar cualquier información que no entiende. Esta es la estrategia que sigue por ejemplo HTML, cuando no entiende un tag, lo ignora simplemente.
  • Cuando se invoca a una operación que no existe en SOAP, se puede devolver un mensaje de “operación no soportada” para que el consumidor sea capaz de recuperarse del error sin que se rompa nada. En REST por ejemplo, esto mismo se logra con una redirección HTTP Code 302 del servicio que ya no existe al nuevo servicio.

Estrategias de versionado

Se suele contemplar tres posibles estrategias:

  1. Estricta
    Cualquier cambio compatible o no compatible produce una nueva versión del contrato del servicio. Aquí no soportamos si compatiblidad hacia atrás ni hacia adelante.
    Este modo tiene una alta severidad e impacto en el gobierno SOA mientras que la complejidad de su aplicación es baja.
  2. Flexible
    Cualquier cambio incompatible produce una nueva versión. Se mantiene la compatibilidad hacia atrás pero no hacia adelante.
    Tanto su severidad, impacto y complejidad se considera de un nivel medio.
  3. “suelto” o “libre” (loose)
    Lo mismo que el anterior pero añadimos también la compatiblidad hacia adelante.
    Tiene una baja severidad y un alto impacto en el govierno y complejidad.

Una estrategia completa

Teniendo lo anterior en cuenta, si queremos tener una estrategia completa de vesionado y que no nos demos una sorpresa después, debemos tener al menos cubiertos los siguientes aspectos relacionados con el versionado:

  1. Estrategia de versionado del servicio.
    Los servicios en el mismo inventario deben ser versionados de una manera consistente siguiendo una de las estrategias indicadas: estricta, flexible o libre.
  2. Reglas de versionado de las SLA
    No hay que olvidarse de que un servicio no es sólo el contrato del mismo, puede llevar aparejados otros compromisos en cuanto a la disponbilidad, calidad del servicio, coste, etc.
  3. Notificación del retiro de un servicio
    ¿Cómo vamos a organizar la comunicación del retiro de una versión a los consumidores? ¿Cuanto tiempo vamos a dejar el servicio en producción para que se adapten estos consumidores a la nueva versión¿

Conclusión

El versionado de un servicio es lo suficientemente importante para no dejarlo a la improvisación y lidiar con ello según vayan llegando los problemas. Debemos pensar en ello antes y tener unas reglas claras por escrito y a disposición de la comunidad… y feliz versionado 😉