XML versus Protocol Buffer

by Christian on 18 septembre, 2008

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.

Print Friendly
Signaler sur Twitter

{ 20 comments… read them below or add one }

Yves-Marie Pondaven septembre 18, 2008 à 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 !

Répondre

Christian septembre 18, 2008 à 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)

Répondre

Alex. septembre 18, 2008 à 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 ?

Répondre

Christian septembre 18, 2008 à 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

Répondre

Alain Pierrot septembre 18, 2008 à 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…

Répondre

Yves-Marie Pondaven septembre 19, 2008 à 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…

Répondre

philippe septembre 19, 2008 à 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.

Répondre

Jean-no septembre 19, 2008 à 5:11

J’aime bien, je trouve ça très lisible (par un humain, s’entend).

Répondre

Christian septembre 19, 2008 à 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.

Répondre

Alain Pierrot septembre 26, 2008 à 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

Répondre

Christian septembre 27, 2008 à 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…

Répondre

bobiciel septembre 29, 2008 à 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

Répondre

elazzouzi juillet 14, 2009 à 4:10

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?

Répondre

Dirty Harry juillet 14, 2009 à 5:54

@Christian JSON : pas forcement tributaire du Javascript… avec n’importe quel langage on peut imaginer le parser
comme Yaml finalement

Répondre

Damien B juillet 14, 2009 à 6:22

@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).

Répondre

Christian juillet 14, 2009 à 11:32

Merci pour ces précisions Damien

Répondre

elazzouzi juillet 15, 2009 à 12:18

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).

Répondre

Damien B juillet 15, 2009 à 11:11

@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.

Répondre

elazzouzi juillet 17, 2009 à 8:37

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.

Répondre

Albéric mai 20, 2010 à 1:53

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.

Répondre

Leave a Comment

{ 1 trackback }

Previous post:

Next post: