XML versus Protocol Buffer
La nouvelle ne m’aurait pas effleurée si un Googler (membre du Conseil d’Adminsitration d’Ars Industrialis par ailleurs) ne m’en avait parlé. La nouvelle en question c’est la mise à disposition de Protocol Buffer par Google.
C’est quoi « Protocol Buffer » ? C’est le mécanisme qu’utilise en interne Google pour sérialiser des données structurées lors d’échanges entre des systèmes ou des applicatifs.
Mais aujourd’hui on fait çà en XML non ? Exact, mais la majorité des développeurs, surtout quand il s’agit ne s’agit pas de systèmes documentaires, n’ont jamais vraiment aimé XML.
Pourquoi ? « Trop verbeux » disent-ils.
C’est aussi l’avis des ingénieurs de Google qui ont mis au point ce mécanisme pour sérialiser les données qui s’échangent sous forme de message entre des applications de leur système d’information. Le principal avantage est le gain de temps, bien sûr ce gain de temps dans le traitement d’un message en « Protocol Buffer » est de l’ordre de la nano seconde, mais on sait que quand on a les infrastructures de Google, les nano-secondes ont tendance à se multiplier de manière exponentielle, d’où l’intérêt d’avoir des messages compilés, puisque c’est ce que propose Protocol Buffer.
Parlant d’optimisation, voici les chiffres qu’avance Google sur la base de l’exemple suivant en comparant Protocol Buffer et XML (ma traduction) :
Les Protocoles Buffers sont :
- plus simples
- de taille 3 à 10 fois plus petits
- 20 à 100 fois plus rapides
- moins ambigus
- génèrent des classes d’accès plus faciles à manipuler en programmation
Par exemple, si vous souhaitez modéliser une person
avec un name
et un email
. En XML, aurez :
<person> <name>John Doe</name> <email>jdoe@example.com</email> </person>
Alors que le message correspondant en protocol buffer (avec le protocole buffer au format texte) est :
# Textual representation of a protocol buffer. # This is *not* the binary format used on the wire. person { name: "John Doe" email: "jdoe@example.com" }
Quand ce message est encodé au format binaire il aura une taille de 28 bytes et sera parsé en 100-200 nanosecondes. La version XML fait 69 bytes sans les espaces vides, et sera parsée en 5 000 à 10 0000 nanosecondes.
Bien sûr, ces chiffres ne deviennent significatifs que sur des architectures traitant des volumes importants et/ou nombreux, et où la rapidité de traitement est critique. Par ailleurs, Google précise bien que XML garde tout son sens dans un environnement documentaire avec des langages à balises comme pour l’HTML, et où il est important d’avoir du contenu self-descriptif puisque le sens d’un message en protocole buffer (l’équivalent de sa DTD) est à part, dans le fichier ayant l’extension .proto.
M’est d’avis que, là où il y a besoin de performance et qu’il y a de la donnée structurée, Protocol Buffer va vite décoller y compris dans l’environnement web sémantique qui lui aussi travaille sur des volumes importants et structurés. Inutile donc de craindre que Protocol Buffer fasse de l’ombre au web sémantique sous prétexte qu’il remplace le XML, puisque le web sémantique n’a rien à voir avec XML qui n’est qu’une sérialisation possible parmi d’autres.
Sur la page de présentation de Protocol Buffer vous trouverez tout ce qu’il faut : tutotrial, guides et APIs.
A première vue, ça ressemble un peu à du JSON non ? (qui est d’ailleurs déjà pas mal utilisé au niveau WS pour faire transiter les résultats de requêtes SPARQL). Tu vois quelle différence entre ces deux sérialisations ?
[Reply]
Mmh, exemple peu probant tel quel, à partir d’éléments terminaux. La syntaxe formelle mériterait d’être évaluée de près, et lorsqu’une recherche chez Google, pour un projet Open Source, ne m’y amène pas vite, mais me propose cette citation de DiBona (Google’s program manager for open source) :
« ..encodes almost any sort of structured information »
j’ai quelques voyants qui clignotent du côté du rouge.
Ce que j’imagine à partir de l’exemple pourrait bien être aussi agréable à relire et déboguer que du lisp…
[Reply]
non regarde bien mon html je ne perd pas la structure !
faut juste mettre ces données comme on utilise les microformats !
en plus faire du json pressupose que tu n’as pas besoin de faire de manipulation xml ensuite car sinon la conversion coute cher à faire…
[Reply]
Protocol Buffer n’est pas un concurrent direct de XML. On gagne au niveau des performances mais on perd en souplesse et en puissance.
On perd en souplesse car c’est moins structurant que XML. On perd en puissance car on perd toute la famille de technologie XSL qui se greffe à XML. On perd également tous les mécanismes de validation XML qui sont très puissants aussi pour la gestion des erreurs.
Après l’utilisartion de Protocol Buffer peut se comprendre dans un contexte où les perfs sont un élément critique et où l’on a pas trop besoin de structure.
[Reply]
J’aime bien, je trouve ça très lisible (par un humain, s’entend).
[Reply]
[…] de recherche et de l’expérience d’utilisation de notre service…“.(source : XML versus Protocol Buffer) XML versus Protocol Buffers : Protocol Buffer est un mécanisme utilisé en interne Google pour […]
Voir à ce sujet la discussion entre Andrew Savikas (TOC) et bowerbird et l’idée de ‘markdown’ :
Why you should care about XML
[Reply]
je ne vois vraiment pas ce qu’apporte cette syntaxe par rapport à la forme xml suivante :
Sous forme d’attributs, le seul caractère supplémentaire par rapport à protocol-buffer est le / final !
Sous cette forme, on conserve la possibilité d’utiliser tous les outils xml pour valider et transformer. Et l’encodage binaire est tout aussi réalisable et performante qu’avec protocol-buffer
(http://code.google.com/apis/protocolbuffers/docs/encoding.html)
Attention à comparer ce qui est comparable. Concernant les performances annoncées, il s’agit du parsing de la forme binaire, donc incomparable à de l’xml ascii (ni du protocol-buffer ascii d’ailleurs !).
Bob
[Reply]
Bonjour,
Je suis en train de faire une étude de faisabilité sur l’utilisation de Protocol Buffers pour manipuler des méta-modèles en mode web (Modélisation sur une infrastructure web), Eclipse Modeling Framework permet de générer des classes java permettant de manipuler un méta-modèle, est ce que P.B peut être une solution qui remplace EMF? quel sont les pertes dans ce cas?
[Reply]
@Christian JSON : pas forcement tributaire du Javascript… avec n’importe quel langage on peut imaginer le parser
comme Yaml finalement
[Reply]
@elazzouzi
EMF permet de gérer des modèles et des outils associés (éditeurs de documents basés sur ces modèles sous forme de plugin Eclipse par exemple), ainsi que de participer à l’écosystème Eclipse (par exemple GEF travaille sur des modèles définis dans EMF) ou tout simplement en déploiement OSGi.
ProtocolBuffer de l’autre côté (ou Thrift d’ailleurs) n’a aucune prétention dans une forme de communication autre que de machine à machine. Il n’y a pas d’outillage associé, pas plus que de moyen d’exprimer de contraintes en-dehors du typage simple des données (pas de restriction définissable sur les plages de valeur, etc).
[Reply]
Merci pour votre réponse. Et le but pour le cas précis que j’ai annoncé précédement c’est la sérialisation structurée des données tout en ayant un gain de performance par rapport à XML. par exemple pour représenter un diagramme de classe UML, ca sera simplement un message de la forme
message class{
required string calssName = 1;
required string calssId = 2;
enum AttributeType {
STRING = 0;
INTEGER = 1;
FLOAT = 2;
…..
}
message Attribute{
required string arrtibuteName = 1;
required AttributeType arrtibuteType = 2;
optional string defaultValue = 3 ;
…..
}
repeated Attribute attributes= 3;
……
}
Et apres bénificier du gain en performance pour faire transiter des messages de ce type sur le réseau vue que l’application s’exécute sur le web (c’est une application de modélisation en ligne et collaborative).
[Reply]
@elazzouzi
Ha, j’aurais dû me douter que « méta-modèle » était une référence directe à UML. Dans un cas comme ça, nous avons utiliser Thrift sur un projet. Pour la communication serveur / serveur (ou en roundtrip par le client avec valeur opaque) on utilisait le message au format binaire. Pour la communication serveur / client, l’encodeur Thrift sait aussi encoder en JSON (sur les mêmes structures de données). Etant donné que ça doit être consommé par du Javascript, je ne suis pas sûr que ça vaille la peine de le garder en binaire.
[Reply]
Oui j’ai regardé le principe de Thrift, c’est une piste intéressante, je vais faire le test. Merci beaucoup pour vos réponses.
[Reply]
Je pense que le xml a l’avantage d’être plus clair que protocol buffer pour la simple raison que l’on est vite perdu à la fermeture de beaucoup de crochets alors que la fermeture d’une balise est explicite. Protocol buffer est par contre bien plus ordinateur. pourquoi ne pas compiler le XML comme si c’était du protocol buffer? La syntaxe ne me parrait pas rédibitoire.
[Reply]
sur le nombre d’octets il faut voir ca une fois compressé … le xml se compresse très bien !
ton xml personne peut etre mis comme ca : John Doe
et avec xml tu as xsl et xpath qui viennent derrière…
bien pratique !
[Reply]