vhe74′Stuff

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.

Aptana jusqu’alors connu pour ses outils de développement web javascript et rails, vient de lancer en beta sa plate-forme de déploiement de type Cloud Computing. Le principe est assez simple, après avoir créer localement votre application, l’avoir testée, etc on l’envoie directement depuis l’IDE vers le “Cloud”. C’est là que cette notion de cloud est intéressante, puisque on va juste spécifier une quantité de ressources à allouer, un niveau de service, et quelques options de configuration. La tarification mensuelle est donc facteur de tous ces éléments, et on a globalement à peu près tout ce qu’il faut pour déployer une application. L’allocation d’une configuration minimale de 256 Mo de mémoire et de 5 Go de disque coûte à peu près 30$ par mois.   Dougal Matthews à testé la plate-forme en question, je vous invite à aller voir son post.

Ici volontairement je vais pas parler de langage mais plutôt de plate-forme, quand on commence à parler d’une application. Les langages vont se caractériser par plusieurs point que sont leur complexité, le spectre fonctionnel couvert (éventuellement par des frameworks disponibles), et leur facilitée de mise en oeuvre. Comme beaucoup de monde j’utilise depuis la nuit des temps des outils basés sur du php pour mes plate-formes (wordpress, dotclear, frontaux d’accès à des bases de données… ), j’ai utilisé de manière ponctuelle Ruby-on-rails, et maintenant je m’aperçois que python est de plus en plus utilisé. L’une des différences ente ces approches est principalement due au fait que d’un coté on a des langages simples plus ou moins généralistes et que de l’autre on se retrouve avec des frameworks complet beaucoup plus rigides.

Le PHP à plusieurs avantages, c’est un langage qui est dédié à la création de pages web. Ceci permet une grande souplesse dans la création sur un mode itératif, mais a comme corollaire de permettre de rendre le produit rapidement non maintenable. En effet cette approche ne favorise pas la séparation des éléments d’interface des éléments de code, a moins là aussi de mettre en oeuvre un framework. Les expériences que j’ai pu avoir de reprise de code après de longue périodes de production ont été assez dramatiques.Un autre avantage de PHP c’est son universalité, qui permet de facilement déployer les pages sur des hébergements simples. Bref PHP c’est idéal pour les petits projets, même si de grosses infrastructures l’utilisent.

RUBY ON RAILS est un framework complet construit autour du langage ruby. ce framework a comme gros avantages de facilement séparer la logique, du contenu, et de la présentation. En effet tout est formalisé au travers d’une architecture Model/Vue/Controller. Cette structuration apporte un indéniable confort dans le développement, permet de facilement structurer le développement en équipe, et apporte une capacité de maintenance du code incomparable. On retrouve un peut la démarche qu’on a par ailleurs avec une architecture J2EE, tout en étant plus abordable quand même. ROR permet une rapidité de création incomparable tant qu’on reste dans les limites du framework. Si on s’intéresse à des architecture de type interfaces riches (Flex, Air, Sylverlight), alors le découplage logique / présentation présente un intérêt non négligeable. Le gros défaut de ROR est qu’aujourd’hui les compétences sur le sujet sont assez limitées, et que lorsque la phase de maquette est terminée il faut déployer obligatoirement sur une infrastructure de type dédiée donc nécessairement avec une charge d’administration plus élevée.

Récemment je me suis intéressé  à Python, ayant vu que c’était le langage utilisé par Google pour son app engine, j’ai un peu plus creusé sur ce sujet. Aujourd’hui chez Google trois langages sont utilisés : C++, Java, Python. Python sert aussi bien en interne, qu’en externe pour réaliser toutes les chaînes de traitement, réaliser tout le packaging d’application, etc… Bref on est en présence d’un langage relativement structuré, donc suffisamment directif pour permettre de produire avec une certaine qualité, et d’être suffisamment versatile en termes d’usages. Il y a une communauté, et des sources d’informations importantes autour de ce langage, et le dernier point, et pas des moindres, c’est la disponibilité en offres d’hébergement, qui peut donc en faire une plate-forme non négligeable pour déployer des applications de taille moyenne.

Même si aucun choix sur ce sujet ne peut être définitif, je pense qu’il y a des pistes intéressantes à surveiller.