SOA : Du composant au service : Sans état (Stateless)

Comme son nom le suggère, l’élément clé de SOA (Service Oriented Architecture) est le Service. Il est pourtant difficile de faire le consensus autour de la notion de service et il est souvent difficile de répondre à cette simple question « Qu’est-ce qu’un service ? ». Ce sujet débouche invariablement sur, au choix : Un blanc ; Une réponse alambiquée et incertaine ; Une discussion enflammée (ou un débat stérile).

On pourrait proposer la définition suivante : « Un Service est un composant logiciel distribué, exposant les fonctionnalités à forte valeur ajoutée d’un domaine métier ». Malheureusement, les définitions aussi courtes (bien qu’exactes) sont nécessairement incomplètes et amènent un florilège de questions.

Pour répondre plus précisément à la question, nous vous proposons de passer en revue les huit aspects qui caractérisent un service :

• Contrat standardisé : L’ensemble des services d’un même Système Technique sont exposés au travers de contrats respectant les mêmes règles de standardisation.
• Couplage lâche : Le contrat d’un service doit imposer un couplage lâche de ses clients.
• Abstraction : Le contrat d’un service ne doit contenir que les informations essentielles à son invocation. Seules ces informations doivent être publiées.
• Réutilisabilité : Un service exprime une logique agnostique et peut ainsi être positionné comme une ressource réutilisable.
• Autonomie : Un service doit exercer un contrôle fort sur son environnement d’exécution sous-jacent. Plus ce contrôle est fort, plus l’exécution d’un service est prédictible.
• Stateless (sans état) : Un service doit minimiser la consommation de ressources en déléguant la gestion des informations d’état quand cela est nécessaire.
• Découvrabilité : Un service est complété par un ensemble de métas données de communication au travers desquelles il peut être découvert et interprété de façon effective.
• Composabilité : Un service doit être conçu de façon à participer à des compositions de services.

Ces 8 aspects sont issus du livre « SOA Principles of Service Design » de Thomas Erl, également auteur du site SOA Principles.

Dans ce billet, nous nous attarderons sur la notion de « statelessness« .

Comme nous l’avons expliqué dans le précédent billet de cette série : Mettre l’emphase sur la réutilisabilité des services commence par la fourniture de services proposant une logique réutilisable, mais implique également que l’implémentation de cette logique soit effectivement réutilisable une fois déployée.
Dans une optique de sollicitation massive, il est important de concevoir l’implémentation des services en prêtant tout particulièrement attention à la concurrence d’accès. Les accès concurrents à un service ne doivent en aucun cas modifier son comportement, sa fiabilité ou ses performances. En d’autres termes, un service doit respecter son contrat (et ses SLAs), quel que soit le volume de sollicitations auquel il est soumis : Un service doit être prédictible.
Afin de garantir cette prédictibilité dans le cadre d’accès concurrents, deux principes doivent être appliqués lors de l’élaboration des services :

• Un service doit (au maximum) être autonome.
• Un service doit être sans état.

Ces deux aspects sont fortement liés : Le principe d’autonomie des services implique que le comportement d’un service ne dépende pas du contexte dans lequel il est invoqué (contexte fonctionnel ou contexte technique). Dans cette optique, intégrer de la gestion d’états au sein de nos services est un non sens.

D’une manière plus générale, la gestion d’états (d’informations de contexte) au sein d’un service pose des problèmes :

• De compréhension et de maintenabilité :
  La gestion d’états va sensiblement augmenter la complexité cyclomatique de l’implémentation et donc rendre difficile sa lecture, sa documentation, sa testabilité (plus cette complexité cyclomatique est élevée, plus il est difficile d’obtenir une couverture de code acceptable), … Dans le cadre d’une composition de services, la complexité du composé étant directement liée à celle de ses composants, la complexité des services de plus haut niveau peut donc rapidement devenir ingérable.
• De réutilisation :
  La gestion d’états au sein du service brouille la lisibilité de son contrat puisque l’adaptation de son comportement en fonction de son état ne transparaît pas dans son contrat. Or la lisibilité et la transparence des contrats de service sont des facteurs clés de la réutilisation des services.
  D’autre part, l’utilisation d’états au sein d’un service présuppose souvent l’utilisation de ce service au sein d’un enchaînement d’invocations défini à l’avance. Il sera donc difficile de réutiliser le service au sein d’une autre orchestration ou composition.
• De performances : car la gestion des état est consommatrice de ressources systèmes, notamment en terme de stockage de ces états (en mémoire ou sur disque).

On préférera donc la conception et l’implémentation de services stateless. La responsabilité de la gestion d’états sera alors déléguée aux utilisateurs (consommateurs) des services : compositions, orchestrations, processus, … Ce transfert de responsabilité (déléguer la gestion d’états au client) rejoint les principes d’une approche REST des services.