Lu sur Silicon.fr :
Les « Protocol Buffers » sont distribués sous licence Apache 2.0 par Google. Ils permettent de structurer l’information qui circule entre des serveurs ou des applications. La compagnie voit en cette technologie une alternative au XML, qu’elle juge inadapté pour un usage à grande échelle.
Après avoir parcouru la doc de ce nouveau format d’échange, voici ce qu’on peut en dire :
Taille des messages
Protocol buffer est beaucoup moins verbeux qu’XML, les messages ainsi échangés seront de ce fait beaucoup plus légers.
Par exemple une personne en XML serait décrite de la façon suivante :
<person>
<name>John Doe</name>
<email>jdoe@example.com</email>
</person>
Alors qu’en protocol buffer on aurait :
person {
name: “John Doe”
email: “jdoe@example.com”
}
DTD
La définition du format se baserait sur un fichier .proto qui fait office de DTD pour valider la cohérence du message mais aussi pour générer l’api cliente
Par exemple le person.proto suivant permetrrait de définir le format et les règles de validation des messages :
message Person {
required string name = 1;
required int32 id = 2;
optional string email = 3;
enum PhoneType {
MOBILE = 0;
HOME = 1;
WORK = 2;
}
message PhoneNumber {
required string number = 1;
optional PhoneType type = 2 [default = HOME];
}
repeated PhoneNumber phone = 4;
}
Compiler
La particularité de protocol buffer est d’utiliser une api standardisée pour encoder / décoder les messages. Les utilisateurs de castor pour le XML ne seront pas dépaysés.
L’inconvénient est qu’on est obligé de compiler et générer les classes correspondantes au .proto qu’on veut utiliser.
L’avantage c’est que les compileurs Java, C++, et Python sont fournit par google. Un autre avantage et non des moindres c’est qu’on est sure lors de la génération d’un message que celui-ci est valide. Alors qu’avec du XML on peut très bien produire des messages non valides qui seront déclarés ensuite comme tels lors de leur validation… ou pas. Autre avantage de la compilation : la vitesse de traitement, en effet, une fois compilée, les classes qui manipulent les fichiers d’interchange sont plus rapides car elles savent exactement où les infos se trouvent alors qu’un parseur XML doit parcourir l’ensemble du fichier pour ensuite pouvoir accéder à son conetnu.
Performances et conclusions
Bref voilà un nouveau projet très intéressant proposé à la communauté par google d’autant que sa maturité est avérée puisqu’utilisé comme format d’interchange au sein des serveurs googles pour gérer les indexs du moteur de recherche numéro 1 dans le monde.
A mon avis, le seul frein à l’adoption de ce nouveau format est le déploiement très large actuellement de XML notamment dans les bus ESB et dans les applications SOA. Cependant, la généralisation de ces bus de données tant à montrer la faiblesse de XML notamment au niveau de la taille des interchanges qui engorge littéralement ses canaux. Il se pourrait donc que les entreprises qui souhaitent optimiser leurs échanges décident petit à petit de migrer vers des bus de données protocol buffers qui devraient apporter les mêmes sécurités tout en étant plus simple à manipuler et moins coûteux en quantité d’information.
Pour en savoir plus : le site de Protocol Buffers
Je ne résiste pas au fait de l’annoncer en direct : Google annonce son service de navigation pour Android 2.0.
Comme rien ne mérite plus actuellement d’être blogué, je me lance dans un billet synthétique pour ou contre.
Commentaires récents