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) :
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.
- 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.
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.
"Le contentement apporte le bonheur, même dans la pauvreté. Le mécontentment apporte la pauvreté même dans la richesse."
A découvrir aussi
- Gouvernance SOA : la phase de Run Time
- Un bon contrat, n'est pas un contrat signé mais un contrat standardisé
- Faites vos gammes : les design patterns de la gouvernance SOA
Retour aux articles de la catégorie Gouvernance SOA -
⨯
Inscrivez-vous au site
Soyez prévenu par email des prochaines mises à jour
Rejoignez les 811 autres membres