SOA : Du composant au service : Le contrat standardisé

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 premier billet, nous nous attarderons sur la notion de contrat standardisé.

Qu’est-ce qu’un contrat de service ?

Le contrat de service définit un accord entre le fournisseur et le consommateur. Il est composé :

• D’un contrat syntaxique qui propose une représentation technique du service :
  Il constitue le contrat d’utilisation du service (son interface). Il présente le nom du traitement, ses paramètres d’entrée et de sortie et les contraintes structurelles (format et contrainte sur les données) qui s’y appliquent.
• D’un contrat sémantique qui fournit une description informelle du traitement :
  Il précise les règles et contraintes d’utilisation du service : La valorisation des messages de réponse (0 représente-t-il le résultat d’un calcul, une erreur, une interruption de service ?) ; Les exceptions ; les pré et post conditions techniques (ex. : volume des données échangées) ou métiers (ex. : écriture comptable équilibrée).
• D’un contrat de niveau de service (QoS & SLA) qui précise les engagements du service :
  Il spécifie par exemple le temps de réponse maximum attendu, les plages horaires d’accessibilité, le temps de reprise après interruption, les procédures mises en œuvre en cas de panne, les procédures de prise en charge du support, …

Par exemple, lorsqu’un service est implémenté sous forme de Web Service (nous parlons bien ici d’un exemple ; il ne faut pas confondre service et Web Service), son contrat est composé :

• D’une WSDL qui décrit les modalités d’accès au(x) service(s) :
  La WSDL fait partie du contrat syntaxique. Elle fournit l’interface du service.
• D’un ensemble de XSD qui définissent les types de données échangées par le service :
  Les XSD font partie du contrat syntaxique. Elles définissent les formats de données et les contraintes structurelles.
  Les XSD font également partie du contrat sémantique. En effet, la richesse des types et restrictions XSD permet d’auto-documenter les valeurs possibles et permet souvent d’éviter des quiproquos.
• D’un ensemble de policies qui définissent les règles d’utilisation du service :
  Les policies font parties du contrat sémantique. Les règles et contraintes qu’elles expriment adressent des domaines variés : Sécurité, encodage, langue, versioning, métiers, …
• De documentations complémentaires.
  Ces documentations complètent le contrat sémantique. C’est par exemple dans les spécifications que l’on décrira les pré et post condition d’utilisation du service (elles ne sont pas toutes implémentables sous forme de policy).
  Ces documentations constituent le contrat de niveau de service (QoS & SLA). Notons que l’on parle bien d’un contrat qui définit un ensemble d’indicateurs et de valeurs seuils. Il n’est pas question ici des moyens techniques à mettre en œuvre pour leur supervision (traces, alertes, …).

Standardiser pour faciliter la communication

Le contrat de service est donc une notion complexe qui ne se limite pas à la (simple) définition d’interfaces. Un contrat de service est constitué de nombreux éléments (techniques ou non) qui forment un fond documentaire pour lequel il est préférable (voire indispensable) de respecter un formalisme commun. L’utilisation de ce formalisme commun est le meilleur moyen de construire un modèle cohérent et donc facile à comprendre et à partager.

La notion de contrat de service standardisé ramène à celle de contract first qui est, comme nous l’évoquions dans notre billet sur l’interopérabilité des Web Services (sans, une fois de plus, limiter la notion de service à ceux-ci), la meilleure approche de conception de services (voire la seule valable ?). Dans cette approche, les contrats font l’objet de développements spécifiques en amont de l’implémentation de la logique du service. Le développement de ces contrats doit se faire suivant des règles de standardisation établies pour l’ensemble des services d’un même Système Technique.

Centraliser pour encourager la réutilisation

En plus de cadrer la définition des contrats (et donc de faciliter la communication), l’utilisation d’un formalisme commun et de règles de standardisations facilite la centralisation des éléments constituant les contrats. Cette centralisation encourage la réutilisation. Parmi les constituants des contrats de services, deux sont de particulièrement bons candidats à la réutilisation :

• Les règles d’utilisation (policies) :
  Les contraintes de sécurité, d’encodage, de versioning sont souvent communes à l’ensemble (ou à un sous-ensemble) des services d’un domaine. De la même façon, les règles métiers sont rarement applicables à un seul service.
• Les formats de données (XSDs) :
  Il est évident que les types et formats de données sont utilisés par plusieurs services. Ces derniers ont même vocation à être utilisés au-delà des services : les types et formats de données sont souvent les mêmes pour les invocations synchrones de service et pour les échanges asynchrones, par exemple au travers d’un bus.

Pour rendre possible leur réutilisation, il est indispensable de séparer les différents éléments du contrat de service. Plusieurs WSDL pourront ainsi appliquer les mêmes règles (policies) et manipuler les mêmes types de données (XSDs).

L’isolation des différents constituants du contrat de service en vue de leur réalisation est une bonne pratique qui tient du bon sens. Il n’est pourtant pas rare de voir des déclarations de type (XSDs) au sein d’une WSDL plutôt qu’un import. Cette approche est aussi aberrante que la re-déclaration en inner class de l’ensemble des types de données manipulés par un Bean (Cette pratique doit être restreinte à des cas bien spécifiques et constituer une exception).

Perspectives

La standardisation des contrats de service est donc un élément fondamental de la mise en œuvre d’architectures orientées services (SOA). En effet, la mise en place des bonnes pratiques évoquées dans ce billet offre des gains importants sur deux axes clés :

• Faciliter la communication et le partage de la connaissance :
  La définition d’un ensemble de principes communs de conception des contrats (ex. : conventions de nommage claires pour les entités, les attributs et les relations) permet d’aboutir à un modèle plus cohérent et donc plus facile à comprendre, partager, (ré)utiliser.
• Encourager la réutilisation :
  L’isolation et la centralisation des différents constituants des contrats de services facilitent indéniablement leur réutilisation.

Il ne faut pas perdre de vue que la définition de certains de ces éléments dépasse le simple cadre des contrats de service. Il est par exemple souhaitable que les types et formats de données manipulés par les services soient également utilisés au sein des flux d’intégration. Cette pratique, même si la définition d’un Modèle de Données Canonique reste un exercice difficile, est un gage sur le long terme de maintenabilité, de stabilité et de pérennité.