SOA : Du composant au service : La découvrabilité

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 « découvrabilité« .

Nous l’avons dit et répété tout au long 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.

Le positionnement des services comme ressources réutilisables au sein de l’entreprise passe par :

• La prédictibilité des services proposés (ce qui implique que les services soient autonomes et sans état).
• La découvrabilité des services existants.

Écartons tout de suite le mythe de la découvrabilité au runtime qui reste un espoir inabouti (ou une promesse non tenue) : Un service répondant aux besoins et contraintes d’un consommateur potentiel ne peut être identifié que par un acteur humain. Nous parlons donc bien ici de découverte des services en phase de conception.

Cette découvrabilité des services existants passe par la mise en œuvre d’un repository de services qui vient outiller l’inventaire des services disponibles. Ce repository stocke l’ensemble des métadonnées nécessaires à :

• La recherche des services de l’inventaire.
• La récupération de l’ensemble des artefacts relatifs aux services de l’inventaire (Spécifications, SLAs, Policies, Schémas XML, WSDL, Interfaces, …).

Remarque : Attention à ne pas confondre le repository de services avec un registre de services qui a lui la responsabilité de référencer pour le runtime les endpoints (points d’accès physiques) des services déployés.

Ainsi, le concepteur d’un consommateur de service (Service composé, application composite, orchestration, processus, …) pourra s’appuyer sur ce repository de la façon suivante :

• Le concepteur recherche dans le repository un service possédant les fonctionnalités dont il a besoin (1).
• En se basant sur les métadonnées contenues dans le repository, le concepteur est capable de découvrir et d’identifier un service potentiellement capable de répondre à ces besoins (2).
• le concepteur peut alors accéder au contrat du service : syntaxique, sémantique et de niveau de service (3). il est alors capable, en se basant sur les différents artefacts constituant le contrat du service (spécifications, SLAs, policies, syntaxe, …), de déterminer si le service découvert correspond bien à ces attentes.

Afin qu’il remplisse au mieux son rôle, les fonctionnalités attendues d’un repository de service sont :

• Le catalogage des services, de leurs métadonnées et des artéfacts relatifs à ces services.
• La validation des services et artéfacts catalogués vis-à-vis des standards de l’entreprise.
• La gestion des dépendances entre les services et les artéfacts.
• Le versioning des services et de leurs différents artéfacts.
• La gouvernance de la publication au sein du repository.
• Le support d’un large panel de type d’artéfacts.

Le repository de services constitue donc un outillage indispensable à la découvrabilité de l’inventaire des services. Il permet une gestion centralisée de l’ensemble des données relatives aux services, devenant ainsi un des éléments centraux autour desquels s’articulera la gouvernance SOA.