Messages et services

D’abord trois définitions, pas précises mais qui donnent une idée :

Ma thèse : ce qu’on appelle “services” (SOAP, REST, CORBA,…) est un certain type de messages. Messages et services ne sont donc pas deux groupes qu’on pourrait opposer.

Voilà ce que j’entends parfois autour de moi :

Voila la réalité

Exemples :

D’ailleurs il est tout à fait possible d’utiliser une file de message pour faire de l’appel de service : IBM MQ peut ainsi exposer du SOAP et est utilisé de cette manière dans de nombreuses organisations comme des banques, c’est d’ailleurs une des manières historiques d’exposer des services.

Mon hypothèse : l’utilisation du mot “services” tire son origine des web services, c’est-à-dire des services SOAP. SOAP est une manière d’exposer des appels synchrones entre un service exposant et un service consommateur. SOAP et les pratiques qui l’accompagnaient promettait de nombreux avantages et du coup “service” s’est implanté comme dénomination comme s’il était différent du mode messages.

(Pour être tout à fait précis : même si dans les fait SOAP est surtout utilisé en mode synchrone, la spécification lui permet d’être synchrone ou asynchrone, une spécification définit même comment faire du SOAP via SMTP.)

Une caractéristique des services qui n’est pas pas partagée par tous les systèmes de messages est le fait que l’intermédiaire entre l’exposant et le consommateur ne stocke pas de messages de manière résiliente : si certaines technologies de message peuvent faire de la persistance pour pallier des redémarrages, toutes ne le font pas comme par exemple ZeroMQ ou Redis.

Dans les systèmes de messages, l’intermédiaire est souvent visible, par exemple sous la forme d’un composant supplémentaire à déployer, alors que les appels de service peuvent se faire sans intermédiaire, par exemple par appels HTTP directs entre serveurs. On peut penser qu’il s’agit là d’un critère séparant les deux groupes. Mais dans les systèmes en production, les services utilisent souvent des proxys qui peuvent s’occuper de la gestion des droits ou du monitoring .

Une autre différence est le mode de communication, soit en mode procédure “fais moi ça” soit en mode notification “ceci est arrivé”, cela structure le format et le contenu qui est transmis, il y a des habitudes et certaines approches fonctionnent mieux avec un ou l’autre mode, mais il n’y a pas de séparation “dure”.

Il faut faire une différence entre le service rendu par un outil et son implémentation. Même si l’un peut avoir une influence sur l’autre, il ne faut pas les confondre. Par exemple le fait qu’un système de communication rendant un service synchrone soit une surcouche d’un système asynchrone ne le rend pas faussement synchrone, ou ne diminue en rien ses qualités : par exemple TCP/IP est un système de message asynchrones, sur lequel fonctionne REST qui est un système synchrone.

Du point de vue strict, très peu de systèmes sont réellement synchrones “du haut en bas” dans un système informatique classique comprenant plusieurs machines.

De même il faut différencier les acquittements techniques validant que les données sont bien arrivées à destination, d’une réponse métier.

Pour autant, le mot “service” n’est pas à jeter à la poubelle, car il définit un cas d’usage — la communication synchrone en point à point — qui peut s’avérer utile dans un SI. De même je ne vous conseille pas d’utiliser des bus de message classiques pour ce besoin : ce n’est pas parce qu’il s’agit d’une possibilité valide que c’est celle-là qu’il faut choisir.

Mon avis est qu’il ne faut pas confondre cas d’usage, protocoles et technologies d’implémentation, même si les trois sont liés : plutôt que de se dire “pour l’archi de mon SI j’ai une boite qui s’appelle service et une boite message, et tous mes échanges entre systèmes doit rentrer dans une des deux boites”, réfléchissez à vos besoins et essayez de les adresser.