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.
Autres notes similaires :
- Sacrées Logiques Descriptives, on n’a décidément pas fini d’en parler !
Et ce pour plusieurs raisons :
D’abord parce que le Web Sémantique, les Ontologies et la norme OWL reposent sur ces logiques descriptives ...
- J’ai déjà parlé de la confusion entre les logiques fermées et les logiques ouvertes sur lesquelles reposent les ontologies. Il faut y ajouter celle fréquemment faite entre XML (arbre) et OWL (graphe). Un arbre est un graphe pour lequel il n...
- Une introduction n’est pas, disait Heidegger, quelque chose de général qui vous laisserait au pas de la porte d’une question. Non, une introduction se doit de vous introduire au coeur même du problème. C’est dans l’introductio...
Tags: Web-Sémantique, XML
septembre 18th, 2008 at 8:59
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 !
septembre 18th, 2008 at 10:37
Ah ah
- Si tu le compresses et qu’il faut le décompresser pour l’utiliser tu va perdre en rapidité d’exécution, non ?
- « John Doe» comme çà et alors tu perds la structure, autant envoyer un fichier txt.
- xml et xpath n’est apparemment pas intéressant car pour Google les classes d’accès de Protocol Buffer sont plus intéressant du point du vue du programmeur (dans un certain contexte qui est celui de Google bien sûr)
septembre 18th, 2008 at 10:47
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 ?
septembre 18th, 2008 at 11:17
ben avec Json t’es tributaire de Javascript, là non.
Et comme Protocol Buffer sembler exploser les perfs Json c’est plutôt Json qui serait menacé que XML
septembre 18th, 2008 at 11:29
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…
septembre 19th, 2008 at 8:28
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…
septembre 19th, 2008 at 10:33
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.
septembre 19th, 2008 at 5:11
J’aime bien, je trouve ça très lisible (par un humain, s’entend).
septembre 19th, 2008 at 7:58
[...] 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 [...]
septembre 19th, 2008 at 11:37
philippe : bonne synthèse.
Cela dit je ne crois pas que l’on perde en mécanisme de validation puisque l’on ne perd pas de temps avec le parsing de validation inhérent au XML.
septembre 26th, 2008 at 3:50
Voir à ce sujet la discussion entre Andrew Savikas (TOC) et bowerbird et l’idée de ‘markdown’ :
Why you should care about XML
septembre 27th, 2008 at 7:07
@ Alain : bien sûr dans le publishing la question n’est pas la même.
Faudrait vraiment avoir une idée derrière la tête pour le préférer à du XML…
septembre 29th, 2008 at 12:51
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