SOA : Du composant au service : L’autonomie

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 d’autonomie.

Comme nous l’avons vu dans le précédent billet de cette série : La réutilisabilité des services constitue une des pierres angulaires de la mise en œuvre d’une architecture orientée service. En effet, la mise en œuvre d’une SOA vise, entre autres, à éviter le gaspillage des ressources en éliminant les redondances inhérentes au modèle en silo. D’autre part, la réutilisation est une condition première de l’agilisation du SI indispensable à la réduction du time-to-market, principal élément de ROI des SOA.
Mettre l’emphase sur la réutilisabilité des services commence bien sûr par la fourniture de services proposant une logique réutilisable, mais cela implique également que l’implémentation de cette logique soit effectivement réutilisable une fois déployée. La confrontation au monde réel est souvent douloureuse.
En effet, le modèle SOA pousse à maximiser les possibilités de réutilisation des services produits. Les services identifiés comme réutilisables sont ainsi mis à disposition d’un large spectre de services composites, de processus, d’applications, … Au fil du temps, de tels services ont donc vocation à prendre part à un nombre croissant de compositions, d’orchestrations, de workflow, …
Dans cette optique de sollicitation massive, il est donc 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), quelque 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. En attendant le billet consacré à la notion de « statelessness des services », je vous invite à relire l’article Service Stateful vs. Service Stateless.

Afin que les services s’acquittent au mieux de leurs engagements (comportement, fiabilité, performances, …), ils doivent exercer un contrôle fort sur leur environnement d’exécution et sur les ressources qui sous-tendent leur implémentation. L’autonomie d’un service traduit la mesure du degré de contrôle qu’un service exerce sur son environnement. Plus un service à de contrôle sur son environnement (plus il est autonome), plus son comportement au runtime sera prévisible.
Lors de la décomposition des fonctions du SI en inventaire de services, il est souhaitable de définir les membres de ce registre comme des blocs indépendants. C’est donc un haut niveau d’autonomie individuelle des services qui est visé. Réduire l’accès partagé aux ressources d’un service et augmenter le niveau d’isolation physique des services sont deux leviers permettant d’augmenter cette capacité des services à fonctionner de façon autonome.

Tous les services d’un inventaire ne pourront évidement pas offrir un contrôle complet sur leur environnement. C’est pourquoi Thomas Erl propose de distinguer deux niveaux basiques d’autonomie :

• L’autonomie de niveau service : Les frontières des services entrant dans cette catégorie sont clairement définies et les services sont indépendants les uns des autres, mais il se peut que ces services partagent encore certaines ressources sur lesquelles ils s’appuient. Par exemple, un service d’encapsulation d’un système legacy, même s’il régit ce système partage cette ressource avec ses autres clients.
• L’autonomie pure : La logique sous-jacente au service et les ressources qu’il utilise sont la propriété du service et sous son contrôle exclusif. C’est le niveau d’autonomie que l’on pourra atteindre lors de la création de « nouveaux » services quand la logique sous-jacente est construite spécifiquement pour supporter le service.

La mise en œuvre d’une SOA se faisant, dans la grande majorité des cas, au sein d’un existant avec lequel il faut vivre pendant longtemps (la refonte de tout ou partie du SI en mode big-bang est trop coûteuse et trop risquée), un inventaire de services offrant exclusivement des services d’ un niveau d’autonomie pure reste un objectif difficilement atteignable. C’est pourtant cet objectif qu’il faut viser car un tel inventaire de service permet d’adresser nos préoccupations de monté en charge et de concurrence d’accès.

La mise en œuvre du principe d’autonomie est donc extrêmement importante car elle détermine dans quel mesure les autres principes peuvent être mis en application dans le monde réel (nos environnements de production) en favorisant la fiabilité et la prédictibilité des services.