20 novembre 2009
Imprimer ce billet

Pourquoi tant de vagues autour de Google Wave ?


Depuis un peu plus d’un mois, Google a lancé un test grandeur nature (on parle de 100 000 bêta testeurs) de sa plate-forme de communication centralisée, Wave. Après une grande frénésie de chasse à l’invitation, le soufflet retombe peu à peu : on sent bien qu’il y a quelque chose à tirer de cet agrégat d’outils devenus ‘temps réel’, mais on ne sait pas encore quoi. On voit apparaître de nombreux prototypes (traduction temps réel, interfaçage avec des mobiles…), mais peu de choses très concrètes. Il faudra pour cela attendre d’atteindre une masse critique (si plusieurs entreprises décident par exemple de remplacer l’intégralité de leurs outils de communication par Wave) mais aussi compter sur la communauté pour explorer les possibilités d’extension de Wave et proposer des robots attractifs.

Malgré tout, l’outil de Google a attisé notre curiosité, principalement grâce à son architecture ouverte et à ses possibilités d’extension.

Trois protocoles, deux APIS

Google Wave Federation Protocol

C’est là tout l’intérêt et le cœur du produit de Google. En effet, grâce à ce nouveau protocole ouvert et standardisé, l’hébergement d’un serveur Wave peut se faire indépendamment de Google. Et c’est là le nerf de la guerre pour l’entreprise : contrairement à Google Docs, qui centralise les documents sur une plateforme hébergée chez l’éditeur, l’aspect ouvert du protocole de fédération entre serveurs Wave va permettre à chaque entreprise de garder la maîtrise sur ses Waves, et sur les documents qui les composent. Certains imaginent déjà la très belle utopie d’un client passant commande à son fournisseur via une Wave commune, gérant des processus complexes (passage de commande, envoi de devis automatisé, workflow humain de validation et facturation automatique…).

Si l’on s’intéresse d’un peu plus près à ce protocole, on constate qu’il s’agit d’une extension du protocole bien connu XMPP (précédemment nommé Jabber). Google s’est appuyé sur le mécanisme d’extension de ce protocole (XEP 114) pour renforcer en particulier la sécurisation des échanges inter-serveurs mais aussi l’authentification forte d’un utilisateur auprès de ses waves.

Schématiquement, ce protocole s’appuie sur des mécanismes de Gateway / Proxy. Chaque serveur possède une Gateway, qui s’occupe des modifications locales de chaque Wavelet hébergée. Cette Gateway pousse ensuite ces modifications vers les Proxys des autres serveurs participant à la Wave.

Ce protocole étant ouvert, vous pourrez trouver une documentation riche sur le site de Google, via le draft de spécifications et de nombreux white papers.

Et si vous voulez vous lancer dans l’expérience, Google propose, outre le serveur Wave servant à la bêta, un serveur prototype implémenté en Java.

Protocole client-serveur

Pour interagir avec une Wave, chaque participant doit s’équiper d’un client. Pour l’instant, il n’en existe qu’un seul, le client web créé par Google et disponible sur https://wave.google.com/wave/ (ou une des ses encapsulations, comme WaveBoard). Le protocole qui permet d’échanger avec le serveur Wave n’est pour l’instant pas encore spécifié, mais des tentatives en ce sens existent.

Le client web de Google est une application HTML 5, développée avec GWT. Il communique avec le serveur suivant un protocole GWT propriétaire, porté par HTTP.

L’espoir de standardisation du côté des clients est cependant tangible : la société ProcessOne a réalisé un client prototype basé sur XMPP.

API Robot et JSonRPC

Dernier protocole, et non des moindres, le protocole qui permet aux robots (pour les fans d’irc, on parle de bot) d’intervenir dans une Wave. Pour se faire, ils utilisent JSon-RPC, sur HTTP.
Ces robots fonctionnent sur une programmation événementielle. Ils sont donc à priori agnostiques vis à vis du langage. Il existe actuellement 2 API fournies par Google : une pour Java, que nous détaillerons dans un prochain article, et une pour Python.
Les robots peuvent interagir avec la Wave (ajout de participants, modification du contenu de la Wave, envois d’alertes) en étant déclenchés par des évènements internes à la Wave (arrivée d’un nouveau participant, publication de texte, déclenchement par mot clé).

API Gadget

Il existe une autre façon d’enrichir les fonctionnalités de la Wave : les gadgets. Les gadgets sont des briques de code (HTML + javascript), bien connus des utilisateurs de iGoogle, embarqués dans le client Wave. Ils sont similaires à ceux de l’API OpenSocial, même si curieusement celle-ci n’est pas officiellement compatible. La différence avec les gadgets statiques est que les gadgets Wave tirent profit de l’aspect ‘live’ de la Wave et peuvent interagir avec celle-ci. Ils comportent une gestion d’état, ont connaissance de l’utilisateur en cours de visualisation et des utilisateurs connectés et s’intègrent au mécanisme de playback.
Nous reviendrons là aussi plus en détail sur l’écriture de gadget.

Synthèse

Pour résumer ces différents protocoles, le plus simple est encore de les représenter sur un schéma.

source : J Aaron Farr

Avec des extensions correctement pensées et développées, Wave semble pouvoir être un énorme atout dans la communication interne de l’entreprise.
Alors, serez-vous les premiers à installer un serveur Wave en remplacement de votre bon vieil SMTP ?

Mots-clefs :,