Les 10 pièges de la SOA : 09 – Le Versioning

De par leur implication dans des projets SOA (Service Oriented Architecture), les consultants de Xebia vivent de belles réussites. Mais ils rencontrent aussi un certain nombre de projets qui peinent ou qui sont en échec.
Afin de partager ces expériences, nos collègues hollandais, Gero Vermaas, Viktor Grgic, Rik de Groot et Vincent Partington déroulent une série de billets présentant les 10 pièges de la mise en œuvre d’une architecture orientée services (SOA). Comme toujours dans ce genre de « classement », cette liste n’est ni exhaustive ni définitive.

Le deuxième de ces pièges concerne le versioning et la gestion du cycle de vie des services qui constituent un mal grandissant s’ils ne sont pas correctement adressés dès le début.
En effet, une SOA (architecture orientée services) démarre en général simplement, avec un nombre raisonnable de services dans leur version nominale. Il est alors aisé de maintenir la cohérence de l’ensemble. Mais au cours du temps, de nouveaux services, ainsi que de nouvelles versions des services existants apparaissent. La complexité de l’ensemble croît ainsi très rapidement.
Une bonne gestion du cycle de vie des services et un outillage adapté permettent de garder le contrôle de cette complexité galopante.

Changements mineurs et majeurs

La mise en œuvre d’une SOA implique l’implémentation de services. Ces services sont initialement conçus dans un but précis. Les consommateurs de ces services utilisent les fonctionnalités qu’ils proposent comme prévu. Toutefois, au fil du temps, les services peuvent changer ou de nouvelles fonctionnalités peuvent s’avérer nécessaires. Quels seront alors les impacts sur les services, les consommateurs et l’infrastructure ?

Ces changements sont soit majeurs (passage d’une version 1.0 à une version 2.0), soit mineurs (passage d’une version 1.0 à une version 1.1). Il existe quatre typologies de changements (celles-ci pouvant être croisées) :

• Changement mineur d’interface : L’interface actuelle est étendue sans compromettre ni la fonctionnalité qu’elle expose ni son utilisation. Par exemple en ajoutant une nouvelle méthode avec de nouvelles fonctionnalités.
• Changement mineur de fonctionnalité : L’implémentation d’une fonctionnalité est modifiée sans que cela porte préjudice aux consommateurs. Par exemple une correction de bug sur la version courante.
• Changement majeur d’interface : L’interface courante est profondément modifiée interdisant toute rétro-compatibilité. Par exemple, en modifiant la signature des méthodes exposées.
• Changement majeur de fonctionnalité : Bien que l’interface reste la même, une fonctionnalité est profondément modifiée, affectant ainsi les consommateurs.

En général, une modification mineure n’a pas d’incidence sur les consommateurs. Ces consommateurs peuvent continuer à utiliser l’interface ou la fonctionnalité existante. Normalement, le service peut être remplacé par sa nouvelle version sans que l’ancienne soit maintenue en ligne. Il est toutefois souhaitable de procéder à des tests de non-régression. Il faut également s’assurer que la nouvelle fonctionnalité s’inscrive dans les exigences de SLA (Service Level Agreement).

Il y a par contre de grandes chances qu’une modification majeure affecte directement les consommateurs. Ainsi, l’ancienne version du service ne peut pas être remplacée par la nouvelle pour une (ou plusieurs) des raisons suivantes :

• Les consommateurs ne peuvent pas être mis à niveau dans les temps (modification majeure de l’interface).
• L’ancienne version de la fonctionnalité est toujours requise par un ou plusieurs consommateurs.
• Un ou plusieurs des consommateurs refusent de se mettre à niveau parce qu’ils ne souhaitent pas supporter le coût de cette mise à jour (En général, plus ils reculent plus ce coût sera élevé).

Dans ces cas de figure, deux versions du même service seront disponibles pour les consommateurs, bien que la fonctionnalité et/ou l’interface diffèrent. Lorsque plusieurs versions d’un service existent, la complexité de la SOA augmente. Même en limitant le nombre de versions en production pour un service, il est souvent coûteux de maintenir toutes les versions. Souvent, seul un support technique sera assuré sur l’ensemble des versions, alors que le support fonctionnel ne sera garanti que sur les dernières versions majeures.

Gouvernance et outillage

Les problèmes de versioning sont en règle générale dus à une mauvaise gouvernance. En pratique, les questions que pose le versioning sont :

• Quels consommateurs utilisent quelle version ?
• Quels consommateurs utilisent une ancienne version d’interface ? Combien de temps comptent-ils utiliser cette version ?
• Quelle est la période de support nécessaire pour une version ?
• Quels sont les impacts de la mise à jour ou de la suppression d’une version ?
• Les consommateurs sont-ils routés vers la « bonne » version ?

D’autre part, un manque d’outillage pour supporter cette gouvernance est également souvent à blâmer :

• Afin de garder une trace de tous les services et de leurs différentes versions, il est souhaitable de mettre en place un bon registre de services. Ce registre référence les services actifs ainsi que les consommateurs qui les utilisent.
• Des outils de type ESB peuvent jouer le rôle de proxy vers les différentes versions d’un service. La localisation des services est alors masquée aux consommateurs (principe de couplage lâche) et c’est l’ESB qui prend en charge le routage des invocations vers la version adéquate (Cf. « Cas d’utilisation d’un ESB (3/6) : Gestion de version« ).

Perspectives

Pour résumer, il est inévitable que les services d’une SOA évoluent au cours du temps. Il est par conséquent important d’être bien préparé à ces changements :

• Limitez le nombre de versions en production d’un service et gardez une trace de leur utilisation dans un registre.
• Mettez en place un tiers d’intermédiation afin de mettre en œuvre un couplage lâche entre les consommateurs et les services. Cela permet d’être plus flexible dans la gestion de plusieurs versions.

Traduction libre du billet « Top 10 SOA Pitfalls: #9 – Versioning » publié par Rik de Groot.