vendredi, décembre 31, 2010

Cités royales françaises à l'heure du Cloud


L'intérêt récent des architectes du cloud computing, essentiellement américains, pour les villes royales et historiques françaises est pour le moins singulier. La fondation Dojo, curatrice de la plateforme éponyme de bibliothèques de développement Javascript, proposait naguère le protocole de Bayeux pour les transmissions asynchrones de messages entre serveur et clients Web. Telle l'armure de la fameuse tapisserie, le protocole de Bayeux serait le bergame moderne de la narration de l'avènement du Cloud !

 



Bayeux

 



Bayeux propose un modèle publish and subscribe adapté aux protocoles de communication du Web (HTTP et dérivés). Ainsi un navigateur Web client commence par « s'abonner » à un ou plusieurs canaux de communication qui l'intéressent. Dans l'implémentation fournie par Dojo, le code Javascript suivant est exécuté par le navigateur au chargement de la page Web qui le contient :

 




<script type="text/javascript">
dojo.require("dojo.io.cometd");

cometd.init({}, "cometd");

cometd.subscribe("/hello/world", false, "publishHandler");

publishHandler = function(msg) {
alert(msg.data.test);
}
</script>


Les deux premières lignes du script chargent et initialisent la bibliothèque cometd qui implémente le protocole de Bayeux dans la plateforme Dojo. La ligne suivante abonne la page au canal /hello/world en déclarant la fonction à rappeler lorsqu'un message y circule, ici publishHandler définie ensuite.

 



Le message, quant à lui, peut être envoyé à l'initiative du client ou à l'initiative du serveur. Depuis la page Web client, par exemple :

 




<input
type="button"
onclick="cometd.publish('/hello/world', { test: 'hello world' } )"
value="Click Me!">
Message
</input>


La commande publish émet les données du second argument (au format JSON) sur le canal désigné par le premier argument.

 



Les messages peuvent également être émis depuis le serveur. Par exemple, dans une JSP le code suivant :

 




<%
Bayeux b = (Bayeux)getServletContext().getAttribute(Bayeux.DOJOX_COMETD_BAYEUX);
Channel c = b.getChannel("/hello/world",false);

Map<String,Object> message = new HashMap<String,Object>();
message.put("test", "Voici un message !");

c.publish( b.newClient("server_user",null),
message,
"new server message");
%>


Calais

 



Notre seconde étape du Tour de France des villégiatures du Cloud est Calais. OpenCalais pour être plus précis. Rien de plus naturel, penseriez-vous, après la tapisserie que de s'intéresser à la dentelle. Mais il est plutôt ici question de Web sémantique que des fuseaux et bobines des ourdisseurs, tullistes et autres wappeurs. OpenCalais crée automatiquement un graphe sémantique à partir du contenu, HTML, texte ou XML, qui lui est soumis. Le service OpenCalais en extrait les entités nommées, noms propres, noms de lieux, de sociétés, de livres etc. ainsi que les événements qui y sont mentionnés.

 



OpenCalais est de plus en plus utilisé par les fournisseurs de contenus et les éditeurs en ligne pour classer et catégoriser leurs publications. Ce service, tels les microformats, fait partie d'une nouvelle vague de produits et de services Web, comme ceux mis en ligne, par exemple, par Freebase, par Powerset acquis par Microsoft, par Evri acquéreur de Radar Networks/Twine, par Zemanta et par GetGlue qui tous proposent une alternative légère et pragmatique aux standards et protocoles du Web sémantique promus par le W3C — et fort énergiquement par Sir Tim Berners-Lee — considérés comme trop lourds à l'usage.

 



Le service OpenCalais offre des APIs complètes pour de nombreux langages de programmation mais peut tout aussi bien être mis en oeuvre via un simple formulaire HTML comme dans l'exemple suivant :

 




<form action="http://api.opencalais.com/enlighten/rest/"
method="post" accept-charset="utf-8">
licenseID: <input type="text" name="licenseID" />
<input type="submit" /><br />
content: <br />
<textarea rows="15" cols="80" name="content" ></textarea>
<br/>
paramsXML: <br />
<textarea rows="15" cols="80" name="paramsXML"/>
</textarea>
<br/>
</form>


Ce fragment HTML soumet le champ content à l'analyse OpenCalais, après vérification de l'identité (licenseID) du client du service.

 



Orléans

 



Si ce cheminement de traverse des belles provinces françaises donne à voir les monuments modernes du Cloud dans le temps même de leur élévation, c'est évidemment dans la ville royale d'Orléans que ces élans verront leur couronnement. C'est là, avec Orleans, que Microsoft Rex a un grain persistant. Et même plusieurs ! Des milliers...

 



Orleans est un framework de Microsoft Research pour construire des applications « client +  cloud » qui simplifie la prise en charge de la concurrence des processus inhérente au cloud computing et de l'hétérogénéité des terminaux (du PC au smartphone) qui les utilisent.

 



Le modèle de programmation proposé par Orléans fragmente une application cloud en grains. Le grain est une unité de persistance des données, d'isolement au sens transactionnel, et de distribution sur un réseau de datacenters. Les grains communiquent entre eux par envoi asynchrone de messages — évoquant ici le protocole de Bayeux. Ces messages déclenchent alors des opérations transactionnelles chez d'autres grains. Plusieurs instances du même grain peuvent être simultanément actives pour traiter en parallèle des appels en nombre au même service. Les grains d'Orléans rappellent donc les objets CORBA de l'OMG de jadis — les transactions en plus et la mémoire partagée en moins. Le fameux « passage à l'échelle », qui rappelle immanquablement l'épreuve de l'échelle, torture médiévale qui fut sûrement déjà pratiquée dans la ville royale, est assuré par l'activation à la demande des grains.

 



Une des particularités intéressantes du modèle de programmation d'Orléans est la gestion de la communication asynchrone par l'intermédiaire de « promesses » qui sont ultérieurement tenues ou rompues. (On voit que l'on reste dans la solennité requise d'une visite de la cité royale !) C'est une idée qui remonte aux travaux de Barbara Liskov et Liuba Shrira (1988).

 



Les promesses d'Orléans, comme celle de la Pucelle de la même ville, sont de deux types : promesse d'une continuation ultérieure du calcul en cours ou promesse d'une valeur finale de ce calcul ultérieur, AsyncCompletion et AsyncValue respectivement. Ces promesses types sont intégrées à la plateforme .NET. Deux exemples pour illustrer :

 




// La promesse de calculer la valeur de A
AsyncValue<int> intPromise = GetA();

try{
// Attente synchrone (bloquante) que la promesse soit tenue
int A = intPromise.GetValue();
}
catch( Exception exc ){
// Relaps ! La promesse a été rompue.
Console.WriteLine( "Honte et apostasie. A ne sera pas connu :" +
exc.Message );
}


Cet exemple élémentaire montre la mise en oeuvre synchrone d'une promesse, ici celle de recevoir une valeur entière à un instant ultérieur. L'appel GetValue est bloquant et attend la bonne fin du calcul de cette valeur. Avec une continuation, en revanche, on rend la communication complètement asynchrone :

 




// La promesse de calculer la valeur de A
AsyncValue<int> intPromise = GetA();

intPromise.ContinueWith(
(int A) => {
// Promesse tenue, on reçoit bien un entier
Console.WriteLine( "Résultat A = " + A.toString() );
},
(Exception exc) => {
// Promesse rompue ! Malheur et dévastation.
Console.WriteLine( "Erreur : " + exc.Message );
}
).Ignore();


Dans ce dernier cas, la promesse est associée à une continuation, c'est-à-dire une fonction exécutée lors de la notification ultérieure du résultat (un entier) ou de la rupture de la promesse. L'appel ContinueWith n'est pas bloquant et son résultat est ici ignoré.

 



La classe d'un grain implémente une ou plusieurs de ses interfaces (qui dérivent de l'interface IGrain). Toutes les méthodes et les propriétés d'une interface d'un grain sont soit de type AsyncCompletion soit de type AsyncValue, ce qui expose directement l'asynchronie des communications. En conséquence l'implémentation de ces méthodes doit renvoyer soit une valeur, qui sera convertie en promesse tenue par le runtime Orléans, soit une promesse obtenue de l'appel à un autre grain. Par exemple, une méthode d'un grain pour le calcul d'un produit de deux valeurs pourrait prendre les formes suivantes :

 




AsyncValue<int> Get_A_times_B(){
int x = this.A * this.B;
return x;
}


ou :

 




AsyncValue<int> Get_A_times_B(){
AsyncValue<int> p = grainVoisin.Get_A_times_B();
return p;
}


Le runtime d'Orléans se charge de l'initialisation, de la sauvegarde, de la réplication et de la migration des grains à l'exécution. Les politiques de persistance, d'initialisation, de réplication, etc. sont spécifiées par des annotations optionnelles ajoutées par le programmeur. Le runtime gère également la nature transactionnelle de l'exécution des méthodes granuleuses et la réconciliation des activations variées du même grain. (Joli petit problème de parcours de graphe élégamment résolu par les chercheurs de Microsoft.)

 



Après Bayeux et Calais, Orléans sera-t-elle la voie royale vers le cloud computing ? À l'époque de Jeanne d'Arc justement, s'apprêtait à régner le gentil dauphin Charles VII pour qui elle bouta les Anglais hors de France. Celui qu'on surnomma « le petit roi de Bourges » ne régnait plus que sur une partie de ce que fut le royaume. La populace le moquait alors en chantant le « carillon de Vendôme » sur l'air de l'angélus :

 




Mes amis,
Que reste-t-il
A ce dauphin si gentil ?
Orléans, Beaugency,
Notre-Dame de Cléry,
Vendôme, Vendôme !


Las ! Une roadmap technologique du XVème siècle ! Relevons enfin le défi du cloud computing français et, de crainte de voir l'envahisseur faire une percée d'Orléans à Vendôme, à nous de développer fièrement la plateforme cloud « Beaugency », les bibliothèques de programmation « collégiale Notre-Dame de Cléry », et l'infrastructure as a service « Vendôme » dans le style abbatial monumental !

 



Bonne et heureuse année de programmation cloud à tous les fidèles lecteurs d'ITR Manager.

 



lundi, décembre 13, 2010

Linked Data : Killer App du Cloud ?


Semantic Web Wars: Un nouvel espoir?

Dans un fameux article de Wired publié en août dernier, Chris Anderson, son éditeur en chef, et Michael Wolff, célèbre chroniqueur et récent biographe acerbe de Rupert Murdoch, pronostiquaient, tels l'oracle de Iolcos annonçant à Pelias qu'il périrait de la main d'un descendant d'Éole, rien moins que la fin du World Wide Web tels que nous le connaissons.

 



Les quatre cavaliers de cette Apocalypse 2.0, selon les prophètes Anderson-Wolff, sont déjà apparus au ciel crépusculaire : (i) la multiplication de services Internet dédiés (vidéo, téléchargement, musique, jeux, actualités) ne reposant pas sur le Web ; (ii) la prolifération des maintenant fameuses apps et de leurs hypermarchés, les App Stores, enclaves propriétaires d'une grande distribution insoluble dans la Toile ; (iii) l'émergence de nouveaux moguls des médias en ligne (Yuri Milner, Jack Ma) qui, modernes Citizens Kane à contre-courant des entrepreneurs du Web toujours shootés à l'utopie collectiviste du chaos qui s'auto-organise, implémentent, quant à eux, une stratégie traditionnelle du Big Is Beautiful, arc-boutée sur la reconquête de médias verticaux, intégrés, traditionnels, sur un Web qui les avait naguère désintermédiés et délinéarisés ; (iv) le constat, enfin, de l'échec à transformer le Web en un véritable format de média face au tsunami de la « démocratisation » du marketing (Google Adwords et Facebook Ads en tête) et à la déification de l'audience au détriment du contenu (Demand Media).

 



Mais les nerds, les geeks, et le plus glorieux d'entre eux, Sir Berners-Lee répliquent dans la plus pure tradition du grand spectacle StarWarsien : la contre-attaque est à lire dans le prestigieux Scientific American — dont la caution scientifique, avec une Science majuscule dans le titre, devrait certainement pulvériser l'impudent Wired comme un Alderaan sous le feu du (désormais dévoilé) LOIC. (Prendre note néanmoins pour M. Besson : rien à voir avec notre propre arme Web nationale de destruction massive, secrètement exfiltrée en territoire américain, Loïc Le Meur.)

 



Ce plaidoyer pour les standards ouverts du Web figure comme une leçon de storytelling à l'ère de la fiction transmedia contributive. Le récit est poignant et personnel : ce cri du coeur paternel « Le Web est physiquement né sur mon bureau, à Genève, en décembre 1990 » ouvre cet évangile néo-christique, Tim en Joseph et un cube NeXt Computer en Marie sans doute, pour conclure, quelques psaumes plus loin, sur l'apothéose imminente du HTML 5 et du Web Sémantique victorieux.

 



Au passage, notons un glissement subtil de terminologie dans la vulgate prosélyte du pape du W3C, le Semantic Web y devient subrepticement les Linked Data. La substitution de l'anglais vulgaire « les données reliées » à la noblesse toute cybernétique de l'adjectif « sémantique » est loin d'être neutre. Lorsque Sir Berners-Lee déclara le Web Sémantique (toujours S majuscule, notez bien) ouvert pour le business en 2008, après sept ans de gestation au W3C, les critiques fusèrent, portant sur la complexité des standards — fussent-ils ouverts —, comme RDF (Resource Description Framework) et ses ancillaires OWL (les abscons Ontology Languages), SKOS (l'oxymore Simple Knowledge Organisation System), RDFS (le métamodèle RDF Schema), ou SPARQL (la prosodie interrogative du Query Language for RDF). Des inquiétudes existentielles furent formulées sur la difficulté concomitante de leur implémentation : Fallait-il que les programmeurs Java devinssent linguistes de surcroît ?

 



L'insoutenable légèreté du Web

 



Et pourtant, en 2009 et en 2010, les premiers efforts de publication de données reliées ont vu le jour. Les gouvernements américain et britannique, par exemple, ont ouvert des sites Web où sont publiées des données d'État, dans un souci de transparence citoyenne (http://www.data.gov/ et http://data.gov.uk/), suivant les standards du Web Sémantique. (En France, on a préféré donner la priorité aux fort utiles Hadopi et Loppsi, comme il sied à la vision d'une République Démocratique des Données.) La BBC et le New York Times leur emboîtent aujourd'hui le pas, qui mettent progressivement à la disposition du public leurs données au format RDF.

 



En parallèle, des projets souvent associatifs, parfois commerciaux, ont été lancés pour faciliter à tout internaute la publication de données reliées. En Angleterre par exemple, Swirrl offre une véritable plateforme de publication RDF, Publish My Data, où l'on navigue, interroge et publie un corpus de données aux formats sémantiquement corrects aussi simplement que l'on poste un billet sur son blog. Factual, une startup de Los Angeles, qui vient de lever $25m auprès d'Andreesen-Horowitz et d'Index Ventures, non seulement collecte et fournit les données mais offre également les précieux protocoles et APIs (REST et Javascript) pour y bâtir ses propres applications. Sous nos cieux http://www.nosdonnees.fr/ veut apporter plus de visibilité aux données publiques librement accessibles à chacun.

 



Le cours de cette banalisation des données reliées ne va cependant pas sans son lot de questions techniques. Publier des Linked Data par conversion automatique de bases de données déjà structurées, histoire de gagner du temps par exemple, reste difficile et semblerait plutôt donner raison aux critiques de la première heure du Web Sémantique. La désambiguïsation automatique des entités, noms propres, marques, lieux et adresses, dates, etc. a heureusement fait de grand progrès depuis trente ans. Une solide tradition linguistique française, en particulier, a donné naissance à quelques jeunes pousses hexagonales tout à fait exemplaires sur ces sujets, comme nos familiers Sinequa, Kwaga, Arisem (absorbé par Thales au nom du « patriotisme économique »), le célébrissime Exalead (absorbé par Dassault Systèmes, sans mobile apparent !), Lingway (dont l'équipe fondatrice a oeuvré chez l'antique — pour ne rien dire du ballet GSI, Tecsi, ADP et Steria — pionnier ERLI devenu Lexiquest avant d'être absorbé, lui aussi, par SPSS en 2002 pour un montant hélas étique !), Datops (absorbé en 2006 par LexisNexis), Semio Corp. (absorbé en 2002 par Entrieva rebaptisé Lucid Media depuis, mais inspirateur aujourd'hui de HotGrinds) et bien d'autres encore qui ont réellement fait avancer les solutions techniques.

 



Alors que souvent les solutions de ces éditeurs s'appliquent spécifiquement à un usage donné : moteur de recherches général ou vertical, intelligence économique, traitement des courriers électroniques, estimation des opinions exprimées et e-reputation (ici comme d'ailleurs Evri qui a racheté Radar Networks de Nova Spivack, l'inventeur prodige de Twine, et sérieux concurrent du Stephen Wolfram de Mathematica et Wolfram Alpha au titre de mégalomane cérébral du Net), des nouveaux-venus comme Zemanta et Open Calais se réclament plus explicitement des Linked Data. (Tout ceci ne paraît pas étranger à la levée de fonds de $3m bouclée en exprès par Zemanta le mois dernier...)

 



La connotation communautaire, quant à elle, brille dans le projet DBpedia qui vise à une traduction ontologiquement durable de Wikipedia — à quand celle de Wikileaks, qu'on passe aux choses sérieuses ! Il y a également Freebase. On aborde ici la constitution, collective ou automatique, des liens entre entités RDF, qui représente la deuxième étape naturelle après leur collecte. Avec le développement de ces référentiels de liens de données, il devient en effet critique de simplifier, voire d'automatiser, la mise en relation d'entités et de classifications d'un domaine à l'autre (par exemple, seuls 20% à 30% des termes employés par la BBC dans ses efforts internes de publication se retrouvent dans le vocabulaire de DBpedia). Comme jadis à la Tour de Babel, la fragmentation des dialectes empêche le grand-oeuvre.

 



Json et les internautes

 



Même chez les techies le débat bout ! La plateforme PHP Silk Framework vise les Linked Data comme différentiateur, au lendemain du très bruyant rachat de Heroku (plateforme Ruby) par Salesforce ($212m en cash, une broutille pour Benioff !). Des voix s'élèvent pour des standards ouverts de Linked Data. En effet, à l'heure où les plus grands sites sociaux comme Twitter, FourSquare et Facebook abandonnent discrètement leur interface XML au profit d'APIs en Json, quel programmeur accepterait, sans déchoir, de défroisser le XML amalgamé au RDF par :

 




var tweet = rdf['http://itrmanager.org/tweet/12343'];
var user = rdf[tweet['http://itrmanager.org/property/userid']];
var geoenabled = user['http://itrmanager.org/property/geo_enabled'];
if( Boolean(geoenabled.value) ) {
// Enfin ! On a déterminé que la géolocalisation est présente...
}


alors que l'on rêve évidemment d'écrire l'infiniment plus élégant :

 




var u = tweet.user; if(u.geo_enabled){...}


par le déréférencement direct typique de Javascript dans toute sa gloire ! (Mais remplacez ici Javascript par votre langage de programmation préféré pour goûter la même amertume grammaticale.)

 



Même la proposition récente de Manu Sporny, JSON-LD, pour l'utilisation de Json comme espéranto des microformats, serait aussi à améliorer si l'on en juge par :

 




var tweet, user;
for(o in json_document) {
if(json_document[o]["@"] == 'http://itrmanager.org/tweet/12343')
tweet = json_document[o];
}
for(o in json_document) {
if(json_document[o]["@"] == tweet['twit:userid'])
user = json_document[o];
}
if(user['twit:geo_enabled']) {
// Nous y voilà à nouveau...
}


qui est bien comparable au fragment RDF/JSON précédent en termes de complexité et de désespoir syntaxique. La discussion sur ce sujet est donc à peine entamée et promet d'intéressants développements dans les mois à venir.

 



Mais au final les barrières ne sont peut-être pas seulement techniques. Pour que les entreprises et les organisations consentent à des investissements importants de temps et d'argent dans les technologies des Linked Data, elles doivent évidemment se convaincre du coût et de l'impact réel des problèmes que ces dernières permettent de résoudre. (De quoi le Web Sémantique est-il la solution ?) La difficulté de leur vendre le concept d'un format universel pour les données Web est amplifiée par l'existence antérieure de nombreux formats d'annotations autour des bases de données relationnelles et des tableurs dont la réutilisation les satisfait à peu près. Comment quantifier l'information et les connaissances qui seraient enfouies, trésors cachés, dans les yottaoctets de données qu'elles engrangent ? Et que dire des questions de confidentialité et de sécurité des données ? Les Linked Data exposent encore plus vivement les problèmes de contrôle et de confiance auquel Web et Cloud Computing sont déjà confrontés.

 



ShareThis