Les architectes et les développeurs, en ne s'intéressant pas au besoin de définir des protocoles d'interaction au sein de leurs domaines, passent régulièrement à côté d'opportunités d'introduire de la stabilité dans leurs systèmes. Récemment, InfoQ a envoyé à Martin Thompson, expert en informatique haute-performance, une série de questions portant sur la conception de protocoles ainsi que sur son projet, Simple Binary Encoding (SBE).
InfoQ : Qu'est-ce qu'un protocole, dans le domaine de l'informatique et des systèmes ?
Un protocole est un ensemble convenu d'interactions gouvernées par des règles. Un exemple simple, utilisé couramment, est celui du fichier. Le protocole pour interagir avec un fichier consiste en une action "ouvrir", suivie par zéro ou plusieurs actions "lire" ou "écrire", suivies par une action "fermer". Le protocole ne définit pas seulement les actions qui peuvent être effectuées, il définit surtout un ensemble de règles qui gouvernent l'ordonnancement possible et valide de ces actions. Dans l'exemple du fichier, il n'est pas possible de lire, écrire ou fermer un fichier qui n'a pas été encore ouvert.
Dans le domaine de la conception de systèmes, on entend souvent parler d'API ; c'est une image incomplète de la façon dont on est censé utiliser un sytème. Si plus de personnes publiaient les protocoles d'interaction avec leurs APIs, alors les systèmes seraient plus utilisables.
Malheureusement, notre industrie souffre d'une utilisation très pauvre de la terminologie. Mais connaissant l'immaturité de notre industrie, ce n'est pas une surprise. Peut-être devrions-nous considérer que nous vivons en informatique dans l'âge de l'alchimie et qu'au fil du temps, nous gagnerons en maturité pour une meilleure maîtrise des pratiques et une meilleure compréhension. Donc, souvent, les gens emploient improprement le terme "protocole" pour désigner d'autres choses, souvent tangentielles. Par exemple, le populaire Google Protocol Buffers (GBP) est en réalité un codec, bien que beaucoup le qualifient de protocole. On voit cela aussi avec XML, parfois appelé protocole alors qu'il est utilisé en tant que grammaire ou encodage. Les séquences de messages, gouvernées par des règles d'ordonnancement pour constituer un protocole, sont encodées en ASCII ou en binaire par un codec. GBP et SBE sont des codecs. SMTP est un ensemble de messages organisé en un protocole pour interagir avec un serveur de courrier.
InfoQ : Donc les protocoles sont plus que des patterns de handshake ou de sérialisation ?
Les protocoles gouvernent toutes les interactions pour s'assurer qu'un système n'entre pas dans un état incohérent. S'ils sont bien conçus, ils peuvent être très flexibles, offrir une grande affordance et permettre beaucoup de choses. Nous utilisons des protocoles tout le temps dans notre vie de tous les jours. Sans protocoles, nous tomberions dans le chaos. Sans protocoles, nous ne serions pas capables de réaliser collectivement de grandes choses. Même l'humble fourmi peut accomplir des choses exceptionnelles en colonie en suivant des protocoles simples.
InfoQ : Quand on écrit du code, il y a des protocoles autour de nous, TCP, FTP, HTTP, etc. Généralement, nous fournissons nos solutions plusieurs niveaux au dessus de ces protocoles. Est-ce qu'il y a des bénéfices à comprendre comment ces niveaux fonctionnent ? Ou est-ce qu'une approche "boite noire" est suffisante ?
Cela aide de comprendre les couches de technologies sur lesquelles nos applications reposent. Il n'est pas nécessaire de connaître chaque niveau dans les moindres détails, à moins que cela soit celui sur lequel vous travaillez ou que vous soyez simplement passionné et que vous ayez envie de comprendre et d'apprendre de ce que font les autres. Cependant, on peut tirer grand bénéfice de la compréhension de ce que chaque couche a à offrir et des principales caractéristiques fonctionnelles de chacune d'elles, afin que notre logiciel de plus haut niveau vive en harmonie avec les couches les plus basses, plutôt que de vivre malgré elles. J'aime appeler cela Mechanical Sympathy.
Une bonne façon de comprendre les couches de communication est le modèle OSI (Open Systems Interconnection). Nos applications sont généralement au niveau 7. Nous avons souvent besoin d'implémenter des protocoles au niveau application pour assurer la cohérence applicative. Par exemple, on peut vouloir ajouter un nombre séquentiel à toutes les transactions entre des applications interconnectées pour permettre de détecter des pertes de communication ou permettre de travailler de façon déconnectée. Le protocole FIX (Financial Instruments Exchange) possède un tel mécanisme de séquencement de messages. Les gens qui ont conçu ce protocole n'ont pas respecté le modèle OSI (ou n'en avaient pas connaissance peut-être). Le résultat, c'est qu'ils ont confondu le protocole niveau session avec le protocole niveau application, ce qui a rendu beaucoup plus difficile le rétablissement de panne et le support de clusters résilients. Cet exemple illustre comment le défaut de compréhension des piles de communication peut résulter en des systèmes plus complexes, moins robustes et moins performants qu'ils auraient pu l'être.
InfoQ : Quand devrions-nous envisager d'écrire nos propres protocoles ?
Nous concevons des protocoles tout le temps. On devrait y porter plus attention lorsque l'on s'intéresse aux patterns d'interaction. Ils vont de pair avec les machines à état. Il est impressionnant de voir combien une API peut être améliorée lorsque l'on s'arrête, que l'on regarde tous les patterns d'interaction possibles et qu'on les documente sous forme de protocole. Appeler une méthode d'un objet revient simplement à lui passer un message, bien que cela soit fait de façon très couplée dans la plupart des langages. Lorsque l'on choisit une approche plus découplée, les messages deviennent des concepts de premier rang et peuvent vraiment gagner à être organisés sous forme de protocole. Documenter nos protocoles aide à les affiner et à rendre le système plus aisément compréhensible.
InfoQ : SBE est-il un outil pour générer des protocoles efficaces ?
SBE est un codec qui permet un encodage et un décodage très efficace des messages qui constituent nos protocoles. Souvent, les gens ne découplent pas suffisamment leurs systèmes car l'encodage et le décodage peut peser très lourd, en fonction de l'implémentation des codecs. SBE descend le prix de l'encodage et du décodage d'un message à celui de l'accès à des champs d'objets C++ ou Java. De plus, SBE est sans allocation, ce qui fait qu'il n'a pas d'impact sur les garbage collectors. Ayant eu à profiler de nombreux systèmes du monde réel, je me suis rendu compte que l'encodage et le décodage, ainsi que le garbage résultant, étaient l'un des 3 goulets d'étranglement dont on avait le plus à souffrir.
La conception et l'implémentation de protocoles ne sont pas réservées aux architectes système et aux développeurs bas-niveau. Introduire des protocoles bien pensés dans un système, à ses points d'interaction peut apporter de nombreux bénéfices, notamment de la stabilisation et une réduction des cas d'exception. Qu'ils soient utilisés implicitement dans une couche basse, comme avec TCP, ou à travers un ensemble explicite d'instructions publiées au sein des équipes de développement, les protocoles montrent l'intention de l'auteur du système et permettent aux participants d'une transaction de respecter fidèlement cette intention.