Gouvernance SOA : lachez tout !

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

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 contrat last sont à proscrire.

À l’inverse, les approches contrat 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.

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.