Tranquillement installé cette après midi à regarder mes mails en retard et autres trucs moins sérieux, et d'un seul coup un mail arrive me sortant brutalement de ma torpeur. Un client dont l'application est en production depuis des semaines m'explique que plus rien ne fonctionne. Tout de suite échanges de mails, échanges divers pour creuser et tenter d'avoir un début d'explication. Evidemment tout ça commence par la classique action du saint esprit puisque personne n'a touché a rien, et rapidement des produits de protection systèmes ont été modifiés, bref finalement on se rend compte que l'application qu'on est en train d'essayer de débugger est parfaitement opérationnelle. Quel est l'intérêt de parler de ce type d'événement si ce n'est que ça amène toute la difficulté de l'exploitation d'applications par un client. Celui-ci doit maintenir un système en condition opérationnelle, en n'ayant -et c'est bien légitime- pas forcement la pleine mesure des effets de bords des opérations qui sont à réaliser sur les serveurs. Pourquoi pas lui proposer alors de passer en mode SaaS de type Cloud Computing, on externalise toute l'application et le client se connecte à ses données depuis Internet. Tout ça n'est pas si simple, il  y a d'abord la réticence évidente et paradoxale d'un client d'une petite structure à envoyer ses données sur internet, a ne plus les posséder en interne chez lui. A ce premier point s'ajoute parfois l'aspect technique, parfois des applications fonctionnement bien en local, mais pas évident que ce soit aussi efficace à distance. De ces différentes interrogations, et assertions me vient une reflexion qui consiterait à déployer des conteneurs d'applications chez les clients et à les gérer à distance. Ainsi on isole l'application pour être certain qu'elle continue à s'executer dans un environnement intègre, on en assure la maintenance et les évolutions, et on a la certitude qu'il n'y a pas de problèmes 'étranges'. Concrêtement cette logique peut s'envisager au travers d'une infrastructure de virtualisation chez le client et ainsi permettre de faire converger les deux préocupations, celle du client de propriété de ses données, et par ailleurs celle de robustesse et d'indépendance. On pourrait qualifier ça de 'in house cloud computing', l'application s'exécute dans un conteneur virtualisé, et à partir de là le client accède à un service sans plus de dicernement. Le concept reste à expérimenter, donc à suivre...

J'étais ce matin à la conférence Aristote à l'école polytechnique, qui était sur le thème des outils de collaboration, notamment le toolkit Accessgrid. Cet outils développé à la base par Argonne National Laboratory de Chicago sous la direction du professeur Thomas D. Uram. C'est un projet de plus de 10 ans, dont la maturité à ce jour en fait une solution tout à fait viable pour de réelles applications. Le besoin de base était de permettre à des conférences de se repartir sur plusieurs campus universitaire, et ainsi d’éviter de longues heures de déplacements.

Le point central du produit est le concept de « venue » C'est en fait ni plus ni moins la ou les salles de réunion virtuelle, avec sur le serveur de venue la capacité à partager mettre en œuvre beaucoup de fonctionnalités complémentaires, dont par exemple la capacité à partager des documents, entre les participants. L'architecture de l'application utilise le multicast IP pour dispatcher les flux vidéo et données entre les les noeuds, le rôle du serveur se limitant à mettre en relation les différents nœuds voulant participer à une "venue". Le serveur de venue va pouvoir assurer la persistance de documents afin de permettre de retrouver à posteriori les données échangées, voir même l'enregistrement de la session. Dans le cas ou on met en place la fonctionnalité de Shared Application, l’affichage de la fenêtre sélectionnée est dispatché vers tous les utilisateurs.

Sont enregistrés auprès de accessgrid.org 235 nodes / 25 pays / 2 en France qui correspondent à des salles équipées pour faire des conférences. on est à peu près rendu à 13900 downloads sur win, 23000 sur linux, 4320 sur osx. Environ 1400 conférences on eu lieu à ce jour.

Le mieux reste à venir, tout est prévu pour pouvoir ajouter des applications facilement dans le framework, ces applications s’executent sur les clients. Le code pyton pour accéder à l’API est très simple, très facile à prendre en main. Les applications partagéees peuvent être au niveau de la venue, ou alors au niveau du client. Le toolkit peut permettre de créer de nouvelles applications de collaboration, ou alors d’intégrer une application existante vers un contexte collaboratif. Les technologies standard suivantes sont utilisées : Soap wsdl pour le remote calls, ftp pour les transsfert de fichier, le chat est réalisé en jabber/xmpp, rss pour publier les scheduling, le tout encapsulé en ssl pour la sécurité. Une communauté est très active pour ajouter de nouvelles fonctionnalités aussi diverse que l’intégration de la DV et l’HD, la création d’un client en JSR168. Paraview permet par exemple de dispatcher un stream video basé sur l’affichage d’une application, et ainsi permettre de partager en temps réel le contexte d’une application.

On parle plus tellement de videoconférence, mais vraiment de collaboration, tant l’infrastructure peut être mis en place instantanément. Notre propension à utiliser de tel outils peut vraiment décoler tant ça devient facile en termes d’infrastructure, et d’usage.

Les points forts à retenir sont les suivants :

• Scalabilité
• Free vs 10K or 100k solutions
• Commodité : utiliser votre matériel, quel que soit l'os, seul une webcam, un micro sans écho, et une connexion à internet sont nécessaires.
• Permet d’élargir le champs d’investigation en connectant plus de gens.

L’intervention du Pr Uram a été suivie d’une intervention de J. Bell depuis l’université du Queensland en Australie histoire de montrer la technologie à l’épreuve des faits, et cela a été vraiment concluant, ouvrant la porte à tout ce que nos esprit fertils pourront envisager.

Nokia qui viens de racheter 52% de Symbian pour la coquette somme de 264 Millions d'euros, va mettre l'OS sous licence opensource pour augmenter l'adhésion à cet OS. Cette démarche s'inscrit clairement dans un plan d'attaque contre Android. L'OS de Google pour téléphones portables, même si il est retardé, risque quand même de sérieusement boulverser le marché des smartphones. L'effet a été immédiat, de grand noms du marché du téléphone portable se sont ralliés à cette initiative. Aussi bien des opérateurs comme AT&T, DoCoMo, des constructeurs de téléphones tels Sony, Samsung, que des fabricants d'électronique comme STMicro se montrent intéressés. Ce qu'il y a de bien là dedans c'est pour la pérénité de la plateforme, son évolution et son ouverture, sachant qu'aussi bien technologiquement, qu'en termes de part de marché on part déjà d'assez haut. S60 représente déjà à peu près 6% de parts de marchés à ce jour. On ne se situe pas dans le cas de figure ou une technologie Open Source doit se hisser au milieux des leaders du marchés, Symbian part déjà de cette position. Là ou c'est un peu plus gênant c'est en terme d'émulation du marché, est ce qu'un regroupement de force ne risque t'il pas de figer un peu le marché et les autres initiatives ? Est ce que l'adhésion des constructeurs autour de Android ne va pas en souffrir ?