SOA : Du composant au service : La composabilité

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 composabilité.

Un service doit être composable, c’est-à-dire être conçu de façon à participer à des compositions de services.

Ce huitième et dernier aspect constitue en quelque sorte l’aboutissement des sept précédents. En effet, l’ensemble des principes présentés dans cette série vise in fine à la réutilisation des services. Or, cette réutilisabilité n’a de sens que si les services sont effectivement réutilisés en prenant part à des compositions de services.

C’est grâce à la composabilité que sera mis en œuvre le principe de « separation of concerns » au sein d’une architecture orientée services. L’objectif est ici de déterminer la « bonne » granularité de services afin de décomposer la solution à un problème métier de haut niveau en un ensemble de « plus petites unités réutilisables » de traitement : les services.
L’idée est de pouvoir recomposer notre logique métier à l’infini au sein de processus ou de services composites de haut niveau.

La mise en œuvre de cet aspect dans une architecture de services pose donc le problème du bon niveau de granularité pour un service :

• Un service trop large ne pourra pas être réutilisé, car il implémente un enchainement de traitements qui n’ont, a priori, de sens que dans le contexte où le service a été écrit. Un service trop large n’est utilisable que par une seule (ou quelques) application(s).
• A l’opposé, un service trop fin ne sera pas réutilisé, car il implémente un traitement atomique qui n’apporte pas de valeur ajoutée. Un service trop fin propose un niveau de détail qui n’est pas pertinent d’un point de vue métier.

D’autre part, il faut garder à l’esprit que, d’un point de vue technique (runtime), un service ne sera composable que s’il est autonome et stateless (c’est-à-dire réutilisable).

Déterminer le niveau de granularité adéquat pour les services d’un écosystème est un exercice délicat, qui exige des connaissances (en grande partie métier), de l’expertise et l’expérimentation de différentes options.
La réussite de cet exercice permettra de maximiser la composabilité du portfolio de services, pré-requis indispensable à l’atteinte d’un des objectifs phares de la mise en œuvre d’une architecture à base de services : la réutilisation des services en vue de l’agilisation du SI, indispensable à la réduction du time-to-market, principal élément de ROI des SOA.