SOA : Du composant au service : Le couplage lâche

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 couplage lâche.

Comme nous l’expliquions dans notre livre blanc « Comprendre et savoir utiliser un ESB dans une SOA« , la formalisation du paradigme SOA a clairement eu le mérite de replacer le métier au centre de l’architecture du SI. Mais SOA reste aussi un projet d’intégration à grande échelle. Il est dès lors primordial d’éviter les chausse-trappes des grands projets d’architectures distribuées ou intégrées, et en particulier le couplage technique et fonctionnel entre consommateurs et fournisseurs de services.
Le couplage technique impose au consommateur de connaître le protocole d’échange du fournisseur. À grande échelle, un tel couplage complique, voire interdit l’évolution du socle technique, et risque de figer le SI dans une inertie sclérosante.
À la fois plus subtil et plus pernicieux, le couplage fonctionnel impose au client de connaître le format d’échange du fournisseur. Toute évolution du fournisseur a un impact potentiel sur chacun de ses consommateurs. Mal gérée, cette dépendance peut conduire à de véritables verrous fonctionnels dans le Système d’Informations – interdisant toute évolution ou, plus sûrement, augmentant de façon exponentielle le coût de ces évolutions.

L’implémentation d’un service dépend de son environnement

C’est une évidence, la logique d’un service est, par nature, fortement liée à son environnement :

• Tout d’abord, la logique d’un service est directement dépendante de son implémentation (1). Cette implémentation s’appuie sur un ensemble de ressources qui constituent l’environnement d’implémentation du service. La logique d’un service est donc couplée à ces ressources.
• De la même façon, la logique d’un service est fortement liée aux technologies sur lesquelles son implémentation s’adosse (2).
• D’autre part, dans le cadre de services composites, la logique d’un service est également dépendante des services qui le composent (3).
• Enfin, le contrat de service ainsi que sa logique peuvent être couplés aux processus qui les utilisent (4).

Ces couplages sont inévitables.

Le couplage Contrat / Service

Le contrat d’un service et sa logique peuvent être couplés de deux façons différentes :

• Couplage du contrat de service vers la logique d’implémentation du service (B) :
  Un tel couplage résulte d’une approche contract last lors du design du service (le contrat dérive de l’implémentation). Cette approche, nous allons le voir, est à proscrire car elle induit un couplage du contrat avec l’environnement du service.
• Couplage de la logique du service au contrat (A) :
  Ce couplage dénote une approche contract first dans la conception du service (le contrat est écrit préalablement à l’implémentation du service). Cette approche est toujours préférable et le couplage du service vers son contrat est considéré comme un couplage positif.

Établir la dépendance dans le bon sens

Les consommateurs d’un service sont liés au contrat de ce dernier, et ne doivent être liés qu’à celui-ci (Pas au service lui-même). C’est ce que l’on appelle le couplage lâche.
Or, si le contrat est couplé avec la logique du service (B), les consommateurs vont hériter par transitivité de l’ensemble des dépendances de la logique du service avec son environnement. Nous nous retrouvons donc avec des consommateurs qui sont fortement couplés au service.

C’est pourquoi il est préférable d’établir le couplage du service vers son contrat (A).

Perspectives

Les équipes en charge de la conception des consommateurs ne sont pas nécessairement au courant du couplage du contrat à la logique (B). Ainsi, une telle situation aboutit à un ensemble de couplages non désirés et ignorés des consommateurs à l’environnement du service.
La prolifération de tels couplages est catastrophique car ils fragilisent et rendent moins flexible l’ensemble de l’architecture de service (SOA). C’est pourquoi, les approches contract last sont à proscrire.
À l’inverse, les approches contract first sont à encourager car elles permettent d’imposer (via le contrat) un couplage lâche des clients au service, permettant ainsi l’évolution des implémentations sans impact sur les consommateurs.