Protocol Buffers

Google a mis a disposition récemment, un outil utilisé en interne : les "Protocol Buffers".

Ces "Protocol Buffers" sont la solution maison de Google "indépendante de la plateforme, indépendante du langage et extensible" pour sérialiser/désérialiser des données structurées.

Il faut d'abord définir un protocole - c'est-à-dire la manière dont les données sont structurées - dans un fichier avec l'extension .proto. Puis ce fichier .proto est compilé avec l'outil protoc pour générer un format binaire compact et le code source dans le langage adéquat (Java, Python et C++ pour l'instant) pour lire et écrire dans fichiers dans ce format de manière transparente.

Les données dans le fichier de protocole sont typées : sont disponibles des types simples génériques correspondant aux types simples des langages cibles. Et il est également possible de définir des nouveaux types dans le fichier de protocole.

Les "Protocol Buffers" semblent pour l'instant être utilisés principalement avec du RPC (Remote Procedure Call) ou pour stocker des données structurées simples.

En fait par rapport à XML, l'avantage des "Protocol Buffers" est d'être un format compact dont le traitement est rapide et facile (comparée à la manipulation d'arbres DOM en XML). Par contre, les "Protocol Buffers" ne sont pas conçus pour des données structurées complexes, dans lesquelles la structure est elle-même significative, comme par exemple une structure décrivant un document.

Si dans la petite vidéo qui suit, une comparaison des "Protocol Buffers" est effectuée avec XML et IDL/Corba (les "Protocol Buffers" sont un outil de sérialisation/desérialisation utilisable dans du RPC mais ne sont pas une solution de RPC), il n'y a pas de comparaison avec JSON et YAML. Ces 2 formats sont beaucoup plus compacts que XML mais le sont moins qu'un format binaire, mais reste par contre "lisible par un être humain".

Enfin, un aspect mis en avant et qui semble en effet un point important c'est l'extensibilité des données mises en oeuvre par les "Protocol Buffers". En effet, il semble possible de faire évoluer le format du protocole, en ajoutant des nouveaux champs par exemple, sans pour autant gêner les applications qui utiliseraient l'ancien format. Bien sûr, il faut voir jusqu'à quel point on peut faire évoluer un protocole sans que cela est d'impact sur l'existant.



Encore un outil de Google pour les développeurs même si ces derniers doivent d'abord déterminer si cela peut convenir à leur besoin. Cependant cela peut être une solution de sérialisation/déserialisation séduisante et dans tous les cas à étudier. Surtout qu'il va certainement rapidement y avoir des bindings ou des mises en oeuvre pour d'autres langages que Python, Java et C++.

Site des "Protocol Buffers" : http://code.google.com/apis/protocolbuffers/

Better Web Application Framework

Dans la vidéo qui suit, est effectuée une comparaison entre J2EE, Ruby On Rails, Zope/Plone, Turbogears et Django.
Au travers de 2 exemples - d'abord un simple "Hello World" puis une application de suivi de temps ("Time Tracking Web App") - la comparaison porte sur le nombre de ligne de code produites, le nombre de fichiers de configurations à renseigner, le temps global mis pour réaliser l'application concernée, le nombre d'erreurs et de problèmes rencontrés.

Dans le cas du premier exemple (le "Hello World") sont comparés l'utilisation de Servlet, l'utilisation de JSP, RoR, Zope, Turbogears et Django.

Avec le deuxième exemple, la comparaison porte sur une première solution "partiellement J2EE" (Servlet + JSP + Hibernate), une solution purement J2EE (avec des EJB), Zope/Plone, RoR, Turbogears et Django.

J'ai trouvé cette vidéo intéressante et enrichissante pour se faire une idée sur les autres technologies pour le développement Web quand on n'a pas eu le temps de regarder et qu'on n'a que la possibilité de travailler avec des Frameworks Java pour le développement Web.

J'ai néanmoins étéun peu surpris qu'il n'y ait aucun framework PHP qui fassent parties de la comparaison (CakePHP par exemple) et que les solutions Java ne s'appuie que sur du J2EE pur et dur sans utiliser des frameworks Web (Struts, JSF ou Wicket par exemple). De plus, si Zope/Plone sort a priori grand vainqueur de la comparaison, je ne suis pas persuadé que le critère intégration avec l'existant dont il est fait mention au début de la présentation soit vraiment respecté... ceci étant je ne connais pas vraiment cette technologie.

Dans tous les cas, si comme dans toutes comparaisons de ce type, il y a probablement un certain biais, il est clair que J2EE peut-être très lourd et ne permet pas une productivité optimale.

Quant aux EJB, cela me fait penser à des discussions avec plusieurs collègues : on leur préfère souvent des solutions légères du type Spring et ils sont en fait assez peut utiliser. Les EJB3 semblent plus faciles à mettre en oeuvre mais pour l'instant beaucoup de projets n'ont pas encore migré vers J2EE 5.



Les 2 articles qui suivent sont cités dans la présentation, j'ai mis les liens ci-après :

• Making Mistakes with XML
• EJB's 101 Damnations

En relation avec le dernier lien un (vieil) article The Death of EJB As We Know It?.