SOA : Du composant au service : La réutilisabilité

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 réutilisabilité.

La réutilisabilité des services (et plus largement des ressources du SI) 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 (et donc la réutilisabilité) 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.

La production de services réutilisables passe par la combinaison des processus d’ingénierie logicielle traditionnels et des processus de production industrielle à destination de la consommation de masse. En effet, même si les méthodologues n’ont de cesse de proposer un mode de production standard des projets informatiques, force est de constater que le cycle de production d’un projet informatique lui est souvent spécifique. Les logiciels ainsi produits sont destinés à un usage précis au sein du SI et proposent un potentiel de réutilisabilité quasi nul. A l’inverse, les chaines de production pour l’industrie de masse visent à la production de produits génériques et standardisés offrant un fort potentiel de réutilisabilité.
L’objectif est de produire un registre de services offrant un très fort potentiel de réutilisabilité et qui soit effectivement réutilisé (cette deuxième partie étant souvent plus difficile).

Pour ce faire, il est essentiel de mettre en application le concept de centralisation de la logique métier qui veut que chaque fonction logique offerte par le SI ne soit accessible que par un seul point d’entrée (1) : le service qui l’implémente. Cette approche est indispensable au positionnement des services comme ressources réutilisables au sein de l’entreprise.

La combinaison de la centralisation des contrats de service (qui garantie qu’un consommateur n’a accès au service que par son contrat (2)) et de cette centralisation de la logique métier permet d’obtenir un inventaire de services hautement normalisé. La standardisation de cet inventaire est essentielle pour maximiser la réutilisabilité (et la réutilisation) des services disponibles au sein de l’entreprise. Elle facilitera également le couplage lâche des consommateurs aux services.

Ainsi, les processus organisationnels de production logiciels doivent êtres revus pour garantir la centralisation de la logique métier. Lors de la conception d’un processus ou d’un service composite, ces processus organisationnels doivent inclure systématiquement une recherche dans l’inventaire des services existants. Si la logique métier recherchée existe déjà dans cet inventaire, le service qui l’implémente doit être réutilisé. Dans le cas contraire, son implémentation doit être faite sous forme de service avec une vision élargie (plus large que sa simple utilisation dans le cadre du processus concerné).
C’est pourquoi, comme nous l’expliquions dans « Mise en œuvre d’une SOA : Les clés du succès« , la mise en place d’une SOA est un effort (une initiative) qui doit être mené de façon transverse. Elle ne peut pas être traitée projet par projet.

Le principal frein à la réutilisation des services est la résistance au changement et les guerres de chapelle.
Comme le faisait remarquer Bruno en commentaire au billet « SOA : Du composant au service : Le contrat standardisé« , « dans une organisation multi-partite on n’utilise pas un service parce qu’il existe, mais parce qu’on en a le droit ; et ce droit est donné par un/des urbanistes qui gèrent de facto les mises en relation. ». C’est en effet le cas dans certaines organisations. On retombe ici dans les travers liés à la propriété des composants et au financement au projet.
C’est malheureusement pour cela que dans de nombreuses structures (notamment les plus larges), la réutilisation effective des services reste un vœu pieux.