Quelques retours sur Google Protocol Buffers
Vous connaissez tous XML et JSON (le format d’échange javascript) pour les formats d’échange de données sur Internet. Non content de ceux déjà existants, mais surtout pour des besoins sur mesure, Google nous en introduit aujourd’hui un nouveau : Protocol Buffers. Après quelques heures de tests en utilisant la version Java, voici donc quelques retours sur son utilisation.
Tout d’abord pourquoi un nouveau protocole d’échange alors qu’ils en existent déjà pléthore ? Tout le monde utilise en général les Web Service/REST avec XML/JSON pour communiquer entre système, cependant :
- SOAP est un protocole plutôt lourd, il faut créer ou remonter complètement la pile du protocole ce qui a tendance à être assez lourd pour le serveur,
- XML est verbeux et assez lourd pour passer sur un réseau,
- XML est souvent long à parser, surtout en cas de schémas XML multiples et de structure complexe,
- le XML n’est pas adapté pour échanger des objets sur un réseau (on parlera de sérialisation XML dans ce cas) car beaucoup trop verbeux,
- JSON est plus adapté pour échanger des objets car moins verbeux que XML mais reste propre à Javascript.
Google qui a des besoins assez conséquents d’échange entre ses serveurs et ses systèmes – il est assez simple de se l’imaginer – doit utiliser un protocole qui :
- est petit et économe en termes de bande passante,
- qui se parse rapidement pour “encoder” puis retrouver rapidement ses données,
- est orienté protocole et non contenu.
Protocol Buffers s’utilise de la façon suivante : vous définissez la structure de votre protocole (un fichier avec une extension .proto) et vous générez les classes dans la technologie que vous souhaitez (pour le moment C++, Java et Python). Un peu à la manière d’un stub ou d’un client proxy pour web service, vous avez une définition/contrat et vous en générez un client consommateur. A ce titre Protocol Buffers peut-être assimilé à une technique de génération de protocoles personnalisés. Néanmoins, voici des chiffres qui devraient vous faire réfléchir sur ce celui-ci.
Après quelques heures à faire d’amusement avec Java et PB, voici mon ressenti :
- Général :
- A utiliser uniquement si vous avez un flux d’échange de données objet important, qui ne nécessite pas de structuration XML (validation, requêtage et transformation XSLT),
- Garder JSON, WS & co pour l’échange de données dans les projets de tous les jours,
- +
- Une rapidité de parsing “hallucinante” (si si),
- Une économie de bande passante conséquente,
- Rapidité d’élaboration d’un protocole simple ou complexe,
- Compatibilité des anciennes versions du protocole,
- -
- Pour le moment, manque d’interopérabilité sur les plateformes (C++/Java/Python seulement) et documentation à parfaire,
- Pas de générateur .NET – rien d’étonnant jusque là pour un projet Google – et n’étant pas un fan du C++, je ne m’amuserais pas à modifier le générateur ... (même si j’avoue avoir essayer de modifier un source Java pour le mettre en C#),
- Quelques limitations quand à la mise en place de sous-structure dynamique – on parle bien d’un mode “sérialisation orienté objet”
De ce que j’en déduis après quelques heures d’utilisation, Protocol Buffers fait partie de ces formats/techniques de sérialisation et de définition de protocole comme il n’en existait pas vraiment auparavant et qui manque cruellement encore sur le marché (même si WCF apporte un niveau de facilité et de productivité jamais atteint au niveau de l’échange de données). Un retour plutôt positif en attendant que les choses évoluent ... si elles évoluent.
Les liens :
Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :
