Se encuentra en:
Política de Versionado
PAUT-0030 (Pauta)
- Área: Integración
- Tipo de pauta: Directriz
- Carácter de la pauta: Obligatoria
La gestión de versiones en Servicios Web es fundamental para garantizar un funcionamiento correcto al hacer uso de ellos.
| Tipo | Trazabilidad | Pauta |
|---|---|---|
| RPC | - | El elemento empleado para dirigir la política de versionado es el namespace del servicio, al cual se le dotará de un número de versión |
| SOA | SIN | Esta aproximación sería similar a la del modelo RPC. El namespace del servicio incluirá un número de versión, el cual no variará ante los cambios con compatibilidad hacia atrás, y que se incrementaría en caso contrario. |
| SOA | CON | En esta aproximación se asignará un namespace con versión al Servicio Web. A diferencia de los casos anteriores, este namespace sólo será empleado para definir al servicio, no será reutilizado por otros elementos como los types, bindigs, etc. Al igual que en los otros casos, cuando se produzca un cambio que implique perdida en la compatibilidad hacia atrás, el número de versión del servicio se incrementará para obligar así a regenerar las interfaces en los consumidores del servicio. |
| REST | - | Sin recomendación para el mantenimiento de la versión |
Introducción
Al igual que cualquier otro componente software, los Servicios Webs no son elementos inmutables en el tiempo, sino que están sujetos a cambios a lo largo de toda su vida. El componente distribuido de los Servicios Web hace que los cambios en su interfaz puedan repercutir en los consumidores, obligándoles incluso a reimplementar su interfaz con el servicio. Todo esto marca la necesidad de definir una política de versionado dentro de los Servicios Webs, que aborde la creación de reglas que regulen el versionado de los Servicios Web y sus componentes.
El versionado dentro de los Servicios Webs es un tema abierto en la actualidad pero no nuevo, como lo muestran las numerosas especificaciones y recomendaciones que abordan los problemas de versionado dentro de los Servicios Webs, XMLs y Esquemas.
Toda política de versionado de Servicios Webs debe identificar los tipos de cambios que se realizan en un servicio y tener en cuenta el impacto de los mismo. Los cambios normalmente se agrupan en; cambios con compatibilidad hacía atrás y sin compatibilidad hacia atrás.
Los cambios con compatibilidad hacia atrás, son cambios en el Servicio Web que no "rompen" el servicio y que por tanto, no obliga a reimplementar los consumidores de dicho servicio. Ejemplos de estos cambios son:
- Inclusión de nuevas operaciones.
- Inclusión de nuevos tipos dentro del esquema.
Los cambios sin compatiblidad hacia atrás, son cambios que si "rompen" el servicio y que por tanto, obligan a reimplementar los consumidores de dicho servicio. Ejemplos de estos cambios son:
- Eliminación de una operación.
- Renombrado de una operación.
- Cambio en los parámetros de una operación.
- Cambios en un tipo de datos existente dentro del esquema.
Definición de la Política
MADEJA permite la creación de servicios Webs según tres modelos: RPC, SOA y REST. Las políticas de versionado variarán en cada caso para adaptarse a las posibilidades que proporciona cada modelo.
Política de Versionado en RPC
En el modelo RPC, los elementos que definen un Servicio Web, están todos incluidos dento de un WSDL generado por el framework, lo que dificulta la personalización del mismo.
En este caso, el elemento empleado para dirigir la política de versionado es el namespace del servicio, al cual se le dotará de un número de versión (major.minor).
En el caso de que se produzca un cambio en la interfaz del servicio y se mantenga la compatibilidad hacia atrás, el namespace del servicio no se cambiará.
En caso que se produzca un cambio que si afecte a la compatibilidad hacia atrás de servicio, se deberá incrementar el número de versión del namespace, lo que "romperá" a los consumidores del servicio, obligándoles a reimplementar su interfaz con él.
La ventaja de esta política de versionado es su facilidad de implementación. Por contra, su principal desventaja es que la solución no permite registrar los cambios producidos dentro de la interfaz de Servicio Web, es decir no hay trazabilidad en los cambios.
Política de Versionado en SOA
Al contrario que en el modelo RPC en el modelo de mensajes (SOA), el WSDL se crea a mano y es fácilmente personalizable, lo que posibilita un gran número de posibilidades a la hora de definir la política de versionado.
En este apartado se dan dos políticas a elección de la Dirección de Proyecto, una sin capacidad de trazabilidad de los cambios y de fácil adopción, y otra con capacidad de trazabilidad ante cambios pero de mayor complejidad.
Aproximación SIN Trazabilidad
Esta aproximación sería similar a la del modelo RPC. El namespace del servicio incluirá un número de versión (major.minor), el cual no variará ante los cambios con compatibilidad hacia atrás, y que se incrementaría en caso contrario.
En esta aproximación todos los elementos del wsdl (bindings, types, etc) estarán definidos bajo el mismo namespace del servicio.
Si el servicio se compone de varios ficheros (xsds, wsdls, etc), estos incluirán el numero de versión del servicio.
Aproximación CON Trazabilidad
En esta aproximación se asignará un namespace con versión (major.minor) al Servicio Web. A diferencia de los casos anteriores, este namespace sólo será empleado para definir al servicio, no será reutilizado por otros elementos como los types, bindigs, etc. Al igual que en los otros casos, cuando se produzca un cambio que implique perdida en la compatibilidad hacia atrás, el número de versión del servicio se incrementará para obligar así a regenerar las interfaces en los consumidores del servicio.
A cada tipo de elemento incluido dentro del WSDL (types, bindings, interfaces) se le asignará un namespace propio con un número de versión independiente. A diferencia de los casos anteriores, estos namespaces podrán usar en su número de versión los tres digitos ((major.minor.revision).
La siguiente tabla incluye la recomendación de namespaces para cada elemento.
| Elemento | Namespace | Comentarios |
|---|---|---|
| Servicio Web | urn:juntadeandalucia:(consejería):(aplicación):(servicio -opc):(version) | - |
| Bindings | urn:juntadeandalucia:(consejería):(aplicación):(servicio -opc):bind:(version) | - |
| Tipos | urn:juntadeandalucia:(consejería):(aplicación):(servicio -opc):type:(nombre esquema -opc):(version) | - |
| Interfaz | urn:juntadeandalucia:(consejería):(aplicación):(servicio -opc):intf:(version) | - |
Cada vez que un elemento nuevo se añada al servicio, los elementos antiguos se mantendrán en su correspondiente namespace y los nuevos incluirán en su namespace el número de versión actualizada.
Por ejemplo, si se añade dos nuevas interfaces, el wsdl incluiría a las anteriores en el mismo espacio de nombre
urn:juntadeandalucia:cica:APLICACION:SERVICIO:intf:v1.0.0
e incluiría a las nuevas en un nuevo espacio de nombres actualizado,
urn:juntadeandalucia:cica:APLICACION:SERVICIO:intf:v1.0.1
de esta forma es posible tracear los cambios realizados dentro del WSDL.
Si el cambio dentro del WSDL implica un cambio dentro de un elemento existente, se incrementará la versión del namespace al que pertenece el elemento modificado. El cambio de versión del namespace también afectará a todos los elementos que comparten el mismo namespace que el elemento modificado. Ya que el cambio de un elemento es un cambio que rompe con la compatibilidad del servicio, el namespace del servicio deberá incrementarse también para notificar este hecho.
Si la definición del servicio se ha dividido en varios archivos, cada archivo deberá contener el número de versión del tipo de componente incluido.
Por ejemplo, el archivo interfaz.wsdl, incluye interfaces de la versión 1.0, el nombre del fichero se debería renombrar a interfaz_v1.0.wsdl
