L’objectif de cet article n’est pas de faire une présentation détaillée de SOA : je rencontrerais quelques difficultés à rester concis ! Dans les projets sur lesquels je travaille, je constate des omissions et confusions récurrentes autour de la notion de contrat de service. L’objet de cette brève est de lever le doute autour de cette notion qui est au cœur des démarches SOA.

Sur la notion de service

La définition de la notion de service fait rarement l’unanimité est c’est là le point de départ des incompréhensions autour de SOA. Je choisirai donc ici une définition que je rencontre souvent :

« un service est un ensemble d’opérations mises à disposition par un fournisseur à l’attention d’un consommateur. Ce fournisseur exécute les traitements invoqués par le client consommateur »

Cette définition présente plusieurs lacunes. Celle qui m’intéresse dans le cadre de cet article est l’absence de référence à la notion de contrat de service. En effet, dans le cadre d’une démarche SOA, la notion de service n’est pas dissociable de la notion de contrat de service car il est nécessaire de formaliser le lien entre fournisseur et consommateur pour faciliter la mise en œuvre du service et sa réutilisation.

Soyons plus optimiste, on trouve parfois dans les définitions de la notion de service une référence à cette notion de contrat de service, formulée de la manière suivante :

« le contrat de service décrit les opérations invocables du service »

Cette définition floue est heureusement parfois complétée par des précisions intéressantes :

« le contrat de service décrit les opérations invocables du service, c’est-à-dire la signature de ces opérations et les protocoles réseau utilisables »

Cette dernière définition a beau être plus claire, elle n’en est pas pour autant complète.

Sur la notion de contrat de service

La notion de contrat de service est – et doit être – bien plus précise. En fait, la signature des opérations et les protocoles réseau ne sont que deux aspects d’un contrat. J’aime assez la décomposition suivante d’un contrat, en cinq aspects :

• Sémantique : signification des opérations et de leurs valeurs de retours, pré-conditions, post-conditions…
• Syntaxe : nom et signature des opérations, c’est-à-dire format des paramètres en entrée et en sortie
• Protocoles réseau : ensemble des protocoles réseau utilisables pour invoquer les opérations
• Protocole de conversation : ordre dans lequel les opérations doivent être invoquées
• Niveau de qualité : Qualité de Service (QoS) et Service Level Agreement (SLA), c’est-à-dire garanties en matière de sécurité, fiabilité, disponibilité, performance…

Maintenant que nous avons clarifié la composition d’un contrat de service, qu’en fait-on ?

Sur la formalisation du contrat de service

Un contrat de service peut être formalisé. Un formalisme commun facilite la mise en place et la réutilisation de services. Il existe différentes formes de formalisation et toutes ne sont pas standardisées mais certaines permettent d’automatiser la prise en charge d’un ou plusieurs aspects du contrat. Par exemple :

• Syntaxe et Protocoles réseau : la formalisation de ces aspects peut être exploitée pour générer les stubs côté client. C’est le cas du WSDL pour les Web Services WS-* ou du WADL pour les Web Services REST (enfin, pour ceux qui ne sont pas contre l’utilisation du WADL dans REST, mais ceci est un autre débat !)
• Protocole de conversation : le BPM, grâce à la formalisation standard BPEL, est un excellent exemple d’exploitation automatisée de cet aspect

Notons que les ESB permettent d’exploiter de manière automatisée l’ensemble de la formalisation de contrats, même si l’aspect Niveau de qualité (voir par exemple les couches concernées de la stack WS-*) est plus difficile à exploiter de manière automatisée et l’aspect Sémantique (voir par exemple UDDI) l’est encore plus.