Il y a 13 ans -
Temps de lecture 4 minutes
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 ?
Publié par Pablo Lopez
Pablo est directeur technique chez Xebia et formateur Hadoop certifié par Cloudera au sein de Xebia Training .
Commentaire
3 réponses pour " Pourquoi tant de vagues autour de Google Wave ? "
Published by Dominique De Vito , Il y a 13 ans
Remplacer SMTP par Wave ? A mon avis, ils ne jouent pas dans la même cours.
Wave me semble plus un outil de collaboration qu’un outil de communication: http://www.jroller.com/dmdevito/entry/google_wave_more_a_collaboration
Donc, Wave devrait être utilisé bien plus comme un outil de collaboration avant même de pouvoir espérer détrôner SMTP. Par ex, il pourrait être utilisé pour créer une forge extensible, plus adaptée aux développeurs que les forges actuelles : http://www.jroller.com/dmdevito/entry/google_wave_or_wikis_could
Bref, vu que Wave est par nature flexible et extensible, on devrait voir apparaitre différents patterns de mise en oeuvre de Wave, pour la collaboration.
On commence à en voir :
http://www.lemondeinformatique.fr/actualites/lire-sap-et-salesforcecom-montrent-des-applications-exploitant-google-wave-29211.html
ou
http://lifehacker.com/5381219/
Published by Thibaud Vibes , Il y a 13 ans
Article intéressant. Je suis sceptique quant au chiffre des 100 000 béta testeur parce que j’ai un compte…(j’ai du mal à croire d’être autant privilégié :-)
Depuis je me demande à quoi peut servir Wave et là ce matin j’étais au téléphone avec une hotline avec des gens pas très compétents a qui j’essayais d’expliquer un problème d’architecture réseau (peut être aussi que je suis pas très compétent dans mes explications…). Et là je me suis dit : Si je pouvais créer une wave pour échanger avec le type au bout du fil je pourrais :
– Partager mon schémas de réseau
– Il pourrait corriger les points qui vont pas
– Il pourrait inviter une (ou plusieurs) personnes plus compétentes à participer à la résolution de mon problème
– Je paierais pas la communication téléphonique :-)
– Etre averti quand le problème serait identifié (je suis pas obligé de rester tout le temps sur la wave)…
C’est cette vidéo qui m’a fait penser à ça : http://www.youtube.com/watch?v=FaNhXPSCQWo
Je pense qu’on va bientôt voir apparaître des tas d’usages.
Published by Fabien , Il y a 13 ans
Je suis assez d’accord pour dire que Google Wave est plus un outil de collaboration qu’un outil de communication.
Dans mon entreprise, nous avons tous un compte Google Wave (au même titre que l’entreprise a un compte Google Apps).
Et au final, si on s’est servi de wave au début pour communiquer (je dirais plus pour découvrir), au fur et à mesure, nous nous en sommes servis uniquement pour collaborer :
– rédaction collaborative de billets de blog
– brainstorming sur des points de réflexion et d’organisation
– on a notamment organisé notre venue à DEVOXX ainsi
Par ailleurs, pour ce qui est de l’utilisation en tant qu’outil interne à l’entreprise, nous avons développé un embryon de gadget permettant de traiter le (mini) workflow de validation de congé. Pour l’instant, ça n’est qu’un gadget test, mais effectivement, comme le dit votre article, il se peut qu’un certain nombre d’applications internes d’entreprise, ayant plus ou moins un lien avec des besoins de workflow naissent en entreprise.
A suivre…