Published by

Il y a 12 ans -

Temps de lecture 7 minutes

SOA : Du composant au service : Le contrat standardisé

composant-service
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é.

Published by

Commentaire

6 réponses pour " SOA : Du composant au service : Le contrat standardisé "

  1. Published by , Il y a 12 ans

    Bonjour,

    Concernant la définition des caractéristiques d’un Service, il serait bon de citer la référence de Thomas Erl (SOA Principles of Service Design), puisqu’il me semble fort qu’il s’agit de la source de ces 8 aspects que vous comptez explorer dans cette série.

  2. Published by , Il y a 12 ans

    On m’a recommandé le bouquin par ailleurs, je ferai donc un effort pour le lire ; mais je dois avouer mon scepticisme… La réutilisation des schémas au travers de plusieurs services est un absolu que je n’ai jamais vu atteint : les frontières organisationnelles sont bien plus fortes (et on n’aborde pas ici les problèmes de couplage que cela induit).

    Idem pour la « découvrabilité » : 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 (note : je ne tiens pas à déclencher de polémique sur le rôle ou l’absence d’urbanistes ou d’architectes dans l’entreprise !).

    Le terme « abstraction » est aussi mal choisi : ça reflète mal la qualité de l’interface d’un service (ok pour le juste nécessaire, mais ce n’est pas suffisant).

    La définition de stateless est aussi ambigu : qu’un service soit sans état est un impératif : mais je ne comprend pas le devoir de minimiser la consommation de ressources […] ?

    Enfin, les contrats sont souvent des contrats clients : quid des contrats fournisseur ? Jamais abordés, et pourtant, il est indispensable qu’un fournisseur puisse connaître ses clients et maîtrise leurs consommations (parce qu’un SLA — individuel — dépend quand même souvent de la charge — globale).

    Bref, il me semble donc que le propos du livre est très académique, et élude les questions difficiles. Mais je ne cherche qu’à être convaincu !

  3. Published by , Il y a 12 ans

    @christophe
    le livre le plus abouti de Thomas Erl sur SOA, qui tire les meilleures leçons des expériences SOA de ces dernières annéesme semble être le plus récent (Dev 2008) , « SOA Design patterns »; les autres livres SOA de la même série sont plus conceptuels et prêtent plus le flanc aux reproches du type « Bruno » ci-dessus

    @Bruno
    réutilisation des schémas: il s’agit de réutiliser des schémas d’échange de services, à ne pas confondre avec les schémas de l’éventuel référentiel de schémas de données de l’entreprise; les premiers sont « a minima » et extensibles, les seconds sont nécessairement exhaustifs et plus difficiles à gérer. Donc le challenge est moindre.
    Du moins, c’est ce qu’on espère :-)

    Dans SOA Design patterns, dans un souci de réalisme je pense:
    – il y a nombre de patterns pour les services stateful
    – la découvrabilité est reléguée aux espoirs inaboutis

  4. Published by , Il y a 12 ans

    Concernant la prose de Thomas Erl :
    Le livre « SOA Design Patterns » est en effet plus récent et donc (à priori) plus réfléchi / abouti. Il couvre en tout cas un spectre bien plus large que « SOA Principles of Service Design ». Mais la liste d’aspects caractérisant un service proposée dans cet ouvrage me semble une bonne base pour cette série de billet dont l’objectif principal est de débroussailler les définitions que l’on place généralement derrière le terme « service ».

    Concernant la réutilisation de schéma :
    La réutilisation de schéma, constitue en effet un objectif qui est rarement atteint (mais qui l’est, même partiellement, dans pas mal de SI).
    On retombe dans les mêmes travers qui mènent à la duplication de code ou à l’écriture en N exemplaires de la même fonctionnalité. C’est le syndrome « Not Invented Here ».
    Concernant les problèmes de couplage induit par la réutilisation de schémas, la mise en place de versionning sur ces schémas permet de prévenir pas mal de problèmes.

    Concernant la découvrabilité :
    La découvrabilité des services est en effet, dans sa partie runtime, un espoir inabouti. Il n’en reste pas moins qu’un service doit être découvrable au moment de la conception d’une application composite qui peut potentiellement en avoir l’utilité. Cette découvrabilité passe, par exemple, par la création d’un référentiel documentaire dont la première brique peut se limiter, par exemple, à la mise en place d’un wiki.
    En ce qui concerne le droit à utiliser un service, on retombe dans les travers liés à la propriété des composants et au financement au projet.

    Pour les autres points, nous aurons l’occasion d’y revenir dans cette série (Prochain billet prévu le 19 mars).

  5. Published by , Il y a 8 ans

    salut j’ai à réaliser un service web offrant les opérations :d’ajout et de recherche de docs mais je ne sais pas comment ecrire un contrat wsdl merci

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Nous recrutons

Être un Sapient, c'est faire partie d'un groupe de passionnés ; C'est l'opportunité de travailler et de partager avec des pairs parmi les plus talentueux.