08/10/2008

Stratégie de gestion de version des web services (part 1)

1 - Stratégie de gestion de version des web services
Dans ce post nous essayons de définir une stratégie de gestion de version des web services.

Cette analyse ce base sur :
* Le point de vue de l’utilisateur de web service (ou consommateur), et ses attentes en terme de gestion de version.
* Le point de vue du fournisseur de web service, concernant sa capacité à maintenir opérationnelle une version, et plus particulièrement les événements possibles dans le cycle de vie d’une application (ici ) et les conséquences de ces événements sur les web services en terme de version.

1.1 - Le point de vue de l’utilisateur (consommateur) des web services

Tout d’abord le lecteur doit comprendre le point de vue de l’utilisateur d’un web service en termes de gestion de version.

Pour celui-ci la version d’un web service lui indique s’il existe des changements qui impactent son application et plus particulièrement le code de son application. Dans ce cas il devra réaliser des changements dans son application pour utiliser cette version de web service.

En revanche l’utilisateur d’un web service dans une version particulière s’attend ce que celui-ci soit immuable dans le temps, il s’agit de la notion de contrat de service.

Le contrat de service d’un web service s’engage à ne pas réaliser de changement sur :
* Les messages de requête
* Les messages de réponse
* Le nom des opérations disponibles sur un service
* Le nom du service lui-même
* La localisation du service
* La définition fonctionnelle d’une opération d’un web service
* La définition fonctionnelle du web service

Du point de vue de l’utilisateur d’un web service, si un changement dans le contrat de service se produit, il doit donner lieu à une nouvelle version du web service.

Lors du déploiement d’une nouvelle version (n+1) d’un web service, celle-ci ne doit en aucun cas impacter la version courante (n) du web service. Ceci pour garantir tous simplement que les applications développées sur la base de la version n du web service continuent de fonctionner normalement.

Les responsables des applications en interface avec un web service doivent être informés de l’existence d’une nouvelle version. Il sera alors de leur responsabilité de décider des actions à entreprendre du point de vue de leur application. Les actions possibles sont a priori :
* Continuer à utiliser la version n du web service. Dans ce cas le responsable de l’application doit valider la durée de vie de celle-ci auprès du fournisseur de service.
* Planifier une migration vers la nouvelle version n+1
* Dans certains cas le responsable d’application peut décider de continuer à utiliser la version n du web service pour une partie de son application, et la version n+1 pour une autre partie. Ce cas peut se produire sur une application de taille importante composée de plusieurs modules dont les plannings de livraison sont très étalés dans le temps.

Du point de vue de l’utilisateur d’un web service exposé par une application, le changement de version de l’application n’est pas une cause de changement de version des web services. Ce qui peut amener a des subtilités de gestion de version avec par exemple une application en version 10 qui exposerait un web service en version 1, ou même l’inverse…

Une autre subtilité de l’approche par contrat de service est la correction d’un bug. Imaginons un web service qui expose une opération dont le résultat est faux. Le responsable de l’application qui fournit le web service réalise la correction de l’anomalie, et la met en service. Du point de vue de l’utilisateur du web service, celui-ci n’a pas changé de version (le contrat n’étant pas modifié) aucune modification ne sera nécessaire dans son application, mais les résultats seront justes. Ceci fait apparaitre la différence entre la gestion de version d’un web service (caractérisé par le WSDL et le contrat de service) et la gestion de version de l’implémentation d’un web service qui est caractérisée par la version des composants logiciel utilisés pour exposer un service dans une version donnée. La gestion de version de l’implémentation d’un web service ne doit pas être visible du consommateur, contrairement à la gestion de version du web service.

1.2 - Le point de vue du fournisseur des web service

Du point de vue du fournisseur de web service la gestion de version d’un web service consiste principalement à assurer :

* La gestion de version du contrat de service du web service, c'est-à-dire de mettre à disposition des consommateurs les moyens nécessaires pour identifier de manière unique :
- la documentation technique et/ou fonctionnelle,
- la localisation du service,
- la version du service
- la politique de gestion de l’obsolescence, qui doit identifier la manière dont les services mis à disposition dans une version donnée deviennent obsolètes, et ne seront plus maintenus. La conséquence directe pour le consommateur étant l’indisponibilité du service.


* La gestion de version de l’implémentation d’un web service, consiste à identifier tous les éléments et moyens nécessaires au fonctionnement et à la maintenance d’un service dans une version donnée. Il s’agit principalement des éléments suivants :
- Les composants matériels (serveur, infrastructure, etc.)
- Les composants logiciels de type COTS comme par exemple le système d’exploitation, le compilateur, le serveur web, et la base de données.
- Les composants logiciels développés sur mesure comme les codes sources, les librairies, et les fichiers de configuration

La notion de maintenance dans le temps d’un service ne doit pas être prise à la légère. Il est effectivement très difficile d’intervenir en TMA sur un service développé il y a 3 ou 4 ans si la gestion de l’obsolescence n’a pas était prise en compte dans la gestion de version de celui-ci. Par exemple comment retrouver la version X d’un compilateur, ou comment installer de nos jours un poste de développement avec Windows NT 4.

1.3 - Les événements du cycle de vie logiciel et leurs conséquences sur la gestion de version d’un web service

Durant le cycle de vie d’un logiciel un certain nombre d’événements peuvent ce produire. Certains de ces événements peuvent avoir des effets directs ou indirects sur la gestion de version d’un web service. Nous avons identifié ici un certain nombre d’événements classiques, puis pour chacun d’eux nous essayons d’identifier les conséquences en terme de gestion de version.

Voici la liste des événements (probablement non exhaustive) que nous avons identifiés :
* Correction de bug dans le fonctionnement de l’application
* Correction de bug dans le fonctionnement interne d’un web service
* Ajout d’une nouvelle opération
* Ajout d’un nouveau type
* Ajout d’un nouveau web service
* Changement de version de l’application sans impact sur les contrats de service
* Changement de version de l’application avec impact sur les contrats de service
* Evolution de la définition fonctionnelle d’un web service
* Evolution de la définition fonctionnelle d’une opération d’un web service
* Changement d’un type de retour d’une opération
* Changement d’un type utilisé en paramètre d’une opération
* Evolution du modèle de données de l’application
* Suppression d’une opération
* Suppression d’un type
* Suppression d’un web service

1.3.1 - Correction de bug dans le fonctionnement de l’application

La correction d’un bug dans l’application ne doit pas être visible d’un point de vue du consommateur du service. Il n’y a donc pas de changement de version (voir également le cas 1.3.6).

Il faut toutefois prendre les mesures nécessaires pour s’assurer que la correction effectuée n’aura pas d’effet indirect sur le fonctionnement du service.

Changement de version : NON

1.3.2 - Correction de bug dans le fonctionnement interne d’un web service

La correction d’un bug dans le fonctionnement interne d’un web service correspond typiquement à la correction d’un résultat rendu par une opération.
Ce type de correction ne doit pas donner lieu à une nouvelle version du service car du point de vue du consommateur le contrat de service n’a pas changé. En l’occurrence il est plutôt devenu juste, en se sens que l’opération répond après correction aux objectifs fonctionnels attendus de celle-ci.

Le fait que la version du service ne change pas, n’implique pas que les consommateurs ne soient pas au courant de la correction de l’anomalie. Il est donc important que l’équipe projet communique sur le changement apporté, et sur les conséquences possibles.

Changement de version : NON

1.3.3 - Ajout d’une nouvelle opération

L’ajout d’une nouvelle opération sur un web service n’implique pas d’un point de vue technique de changement dans le code client existant. Effectivement le code client continue de fonctionner sans avoir connaissance de la nouvelle opération. Comme il n’a pas connaissance de cette nouvelle opération il ne peut pas l’utiliser. S’il désire utiliser cette nouvelle opération alors le code client devra être modifié.
Il est donc techniquement possible de déployer une nouvelle opération sans donner lieu à une nouvelle version.

Pour être puriste, l’ajout d’une nouvelle opération sur un web service constitue une évolution de la définition fonctionnelle d’un web service (voir cas 1.3.8), et donc doit être considéré comme une nouvelle version.

Changement de version : OUI/NON

1.3.4 - Ajout d’un nouveau type

L’ajout d’un nouveau type est lié à l’ajout d’une nouvelle opération. Il reprend donc les éléments cités pour le cas 1.3.3.

Ce nouveau type ne doit pas être utilisé dans des opérations existantes sinon il provoque le cas 1.3.10 ou le cas 1.3.11

Changement de version : OUI/NON

1.3.5 - Ajout d’un nouveau web service

L’ajout d’un nouveau web service n’implique pas d’un point de vue technique de changement dans le code client existant. Effectivement le code client continue de fonctionner sans avoir connaissance de ce nouveau web service. Comme il n’a pas connaissance de ce nouveau web service il ne peut pas l’utiliser. S’il désire utiliser ce nouveau web service alors le code client devra être modifié.
Il est donc techniquement possible de déployer un nouveau web service sans donner lieu à une nouvelle version.

Pour être puriste, l’ajout d’un nouveau web service constitue une évolution de la définition fonctionnelle des web services d’un système (voir cas 1.3.8), et donc doit être considéré comme une nouvelle version.

Changement de version : NON

1.3.6 - Changement de version de l’application sans impact sur les contrats de service

Dans le cas d’un déploiement d’une nouvelle version de l’application et si les modifications n’ont pas d’impact sur les web services, il ne doit pas y avoir changement de version des web services.

Ce qui provoquera une différence de version entre la version de l’application en cours d’exploitation et la version des web services.

L’équipe projet doit prendre les mesures nécessaires pour s’assurer que les changements apportés aux composants logiciels n’ont pas d’impact sur le fonctionnement des web service qui utilisent ces mêmes composants. Effectivement la modification des composants logiciels de l’application peut entrainer la nécessité de modifier le code d’implémentation des web services, mais de doit pas changer le comportement fonctionnel du web service.

Changement de version : NON

1.3.7 - Changement de version de l’application avec impact sur les contrats de service

Lorsque les changements survenus dans l’application sont nombreux ou fondateurs, il est certain que leurs conséquences seront la création d’une nouvelle version de web services.

Dans ce cas il est important de prendre des mesures pour être capable de maintenir en exploitation la version n-1 des web services.

Ces mesures peuvent être très couteuses en temps, voir même impossible. Par exemple comment maintenir la disponibilité d’une donnée exposée par le web service si celle-ci n’existe plus dans le modèle de données de l’application ?

Changement de version : OUI

1.3.8 - Evolution de la définition fonctionnelle d’un web service

Une évolution fonctionnelle d’un web service implique nécessairement un changement de version car il y a changement dans le contrat de service.

Changement de version : OUI

1.3.9 - Evolution de la définition fonctionnelle d’une opération d’un web service

Une évolution fonctionnelle d’une opération d’un web service implique nécessairement un changement de version car il y a changement dans le contrat de service.

Changement de version : OUI

1.3.10 - Changement d’un type de retour d’une opération

Un changement dans un type de retour d’une opération implique nécessairement un changement de version car il y a changement dans le contrat de service.

Changement de version : OUI

1.3.11 - Changement d’un type utilisé en paramètre d’une opération

Un changement dans un type utilisé comme paramètre d’une opération implique nécessairement un changement de version car il y a changement dans le contrat de service.

Changement de version : OUI

1.3.12 - Evolution du modèle de données de l’application

Si une évolution du modèle de données se produit, et si ce changement est visible dans les types utilisés par un web service alors il doit y avoir un changement de version.

Si l’évolution du modèle de données n’est pas visible alors, il n’est pas nécessaire de faire un changement de version.

Changement de version : OUI/NON


1.3.13 - Suppression d’une opération

La suppression d’une opération sur un web service est équivalente au 1.3.8.

Changement de version : cf. 1.3.8

1.3.14 - Suppression d’un type

La suppression d’un type sur un web service est équivalente au 1.3.8.

Changement de version : cf 1.3.8

1.3.15 - Suppression d’un web service

La suppression d’un type sur un web service est équivalente au 1.3.8.

Changement de version : cf 1.3.8

2 - Implémentation par le projet de la gestion de version des web services

La gestion de version des web services de est basée sur des mécanismes simples. En résumé la version d’un web service est identifiée par l’élément targetNamespace du contrat du web service [AGARWAL] [SUBBU1] [SUBBU2].
Chaque version des web services est déployée sur un site web.
Il existera donc à terme plusieurs sites web hébergeant les web services de dans différentes versions. Ce Mécanisme permet de garantir aux applications clientes consommatrices leur fonctionnement, indépendamment des évolutions des web service de .

A aujourd’hui, il n’a pas été défini combien de versions seront maintenues dans le temps, ou quel sera l’événement déclencheur de l’abandon d’une version, ni même s’il un tel événement existera un jour.

Il est certain que le nombre de versions maintenues devra être limité. En conséquence les applications clientes consommatrices devront évoluer d’une version x.x supprimée à la dernière version disponible.

2.1 - Identification d’une version de web services

L’identification de la version d’un web service est disponible dans l’élément targetNamespace du WSDL.

La codification retenue est la suivante : http://ws.lde:82/WebService/vX.m
avec :
v : une constante caractère pour identifier la version ici ‘v’ pour version
X : est le numéro de version majeur
m : est le numéro de version mineur.

Voici un exemple de WSDL où la version des web services est identifiée comme étant la version 3.2.








2.2 - Localisation d’une version des web services

Le targetNameSpace est également utilisé pour définir l’URL de déploiement d’une version donnée des web services de .

Dans l’exemple ci-dessus le targetNameSpace est défini ainsi :
targetNamespace="http://ws.lde:82/WebService/v3.2"

En conséquence, le fichier WSDL qui contient cette définition indique :
1. qu’il s’agit de la version V3.2 des web service
2. que l’URL racine des web services de cette version est : http://ws.lde:82/WebService/v3.2

Les URLs des web services sont donc : http://ws.lde:82/WebService/v3.2/Test.asmx

2.3 - Règles de gestion de version des web services

Les règles de gestion de version des web services de ont été définies à partir de l’analyse menée précédemment. Celles-ci sont présentées dans le tableau présenté ci-après :

R1
Un changement du contrat de service d’un web service implique un changement de version du web service, et R0 doit être appliquée.

R2
Un changement de version du web service implique la création d’un site web dédié au support de ce web service dans cette version, et R0 doit être appliqué.
Les versions précédentes du web service restent disponibles sur leur propre site web.

R3
Une correction d’anomalie dans l’application n’implique pas de changement de version du web service. Sauf si la correction a un impact direct sur le fonctionnement du web service.

R4
Une correction d’anomalie dans un web service n’implique pas de changement de version du web service, sauf si la correction implique R1.

R5
Une nouvelle version de l’application n’implique pas un changement de version du web service, sauf si la nouvelle version implique R1.

R6
Le changement du modèle de données n’implique pas un changement de version du web service, sauf si le changement du modèle de données est visible dans les messages de données, ce qui revient à l’application de la règle R1.


3 – Document de référence


AGARWAL
Versioning of web service interface, Anamika Agarwal, 06/04
Cette thèse présente de manière exhaustive la problématique de la gestion de web services.
http://dspace.mit.edu/bitstream/handle/1721.1/28630/58917752.pdf;jsessionid=97E53C5C1D2CC9381C2F724FDF6B874C?sequence=1

SUBBU1
Web services versionning part 1
Web services versionning part1
http://www.subbu.org/blog/2004/12/web-services-versioning-part-1

SUBBU2
Web services versionning part 2
Web services versionning part2
http://www.subbu.org/blog/2005/08/web-services-versioning-part-2

Aucun commentaire: