Agenda :

• Rappel de l’offre mobilité OCTO
• Les tablettes : quels usages pour quels enjeux ?
• Les tablettes : quels impacts sur le SI ?
• Table ronde : retours d’expérience d’Arval, Corsairfly, Axa et BNP Paribas Fortis
• Questions/réponses

Rappel de l’offre mobilité OCTO :

OCTO travaille sur la mobilité depuis 3 ans avec une équipe capable d’adresser les projets de l’idée au store (ergonomes, designers, développeurs, experts, architectes) qui permet d’accompagner au mieux ses clients.

OCTO met le focus sur deux types d’activités :

• Le conseil (réfléchir à l’évolution du SI des clients : quelle stratégie mobile ? pour quels usages ? quelle cible ? quels terminaux ? quels impacts sur le SI ?…)
• La réalisation (les applications sont réalisées de bout en bout soit « clé en main », soit en coréalisation avec nos  clients ; et un réel travail sur l’intégration de ces applications dans le SI est mené (questions autour de la performance, comment sécuriser l’application, la distribuer ?…)

En complément, OCTO propose à ses clients une solution pour distribuer leurs applications en interne, sous forme d’un store privé sur le Cloud : Appaloosa (lien).

Les tablettes : quels usages pour quels enjeux ?

Il s’est vendu cette année plus de tablettes (1,45 millions) que de PC de bureau (1,24 millions) pour les particuliers. 2012 laisse présager 3 millions de tablettes vendues, donc de se rapprocher des ventes de portables (4 millions en 2011)

Pourquoi cet engouement et notamment par les usagers en entreprise ?

Les tablettes présentent de nombreux avantages :

• Taille : – de 1kg ; -1 cm d’épaisseur donc faciles à emporter partout avec soi pour une réunion, un briefing, …
• Praticité (facilement ouvertes, immédiatement allumées, ergonomiques et intuitives)
• Autonomie de 10h
• Prix attractif (– de 500€ neuf et 350€ / an) c’est moins cher pour une entreprise qu’un PC portable
• Connectivité au réseau : 49% des tablettes sont équipées du wifi et de la 3G et peuvent donc être connectées en permanence avec le SI
• Géo localisation (utile pour les commerciaux par exemple : quels sont mes clients proximité ?)
• Stabilité des produits, soit moins d’activité de formation et de help desk

En moyenne les utilisateurs utilisent une tablette plus de 90 minutes quotidiennement : dans le salon le soir, le matin au petit-déjeuner, lors de temps d’attente ou avant de dormir. Ce sont des moments privilégiés pour capter l’attention de l’utilisateur.

L’utilisateur type de la tablette est un homme, d’environ 35 ans, aisé et plutôt geek.

Un support qui capte l’attention, un utilisateur aisé, c’est une excellente opportunité pour capter le consommateur et pour diffuser ses services en B2C. Ainsi, en quelques mois la SNCF a écoulé plus de 100 000 billets par le biais de son application iPad, en valeur c’est 15% de ses ventes sur applications mobiles.

Le marché des particuliers est donc lancé mais on assiste également à une véritable percée sur le marché professionnel :

• 60% des utilisateurs de tablette l’utilisent sur leur lieu de travail
• pour 24% d’entre eux, les iPad sont fournis en entreprise
• et 14% n’utilisent plus leur PC

En effet le PC fait « écran » entre l’utilisateur et les autres, alors que l’on ne peut pas cacher derrière une tablette. Elle redéfinit les contours des usages en entreprise : elle devient un outil propice au partage, à la collaboration là où le PC se cantonne désormais à un outil personnel d’analyse, de réflexion et de production.

Quelques exemples d’utilisation en contexte professionnel :

• La borne interactive CLINIQUE pour les vendeuses : pédagogie avec le client, renforcement de l’engagement du client par rapport à la marque, collecte de données (ex : recommandations faites en magasin…)
• Remplacement des caisses traditionnelles par des tablettes (aux US).
• Impact dans le secteur médical également : visites pré/post opératoires facilitées (informations sur le patient, visualisation des IRM, radios… possibilité de partager avec le patient sur l’opération qui va être menée…)
• Les tablettes deviennent utiles dans des contextes de maintenance de réseaux d’électricité, de canalisations (tablette facilement transportable, géolocalisation, facile de checker des problèmes, envoi de rapports immédiats…)
• Indicateurs de pilotage (la plupart ont une application sur les stores)

Pour tous ces usages la connexion au SI est primordiale.

Les tablettes : quels impacts sur le SI ?

La volonté du top management de moderniser les processus métiers existants et d’intégrer de nouveaux outils  aura un véritable impact sur la conception de nos SI. Regardons ce que changent les tablettes en comparaison des smartphones et des projets sur un PC traditionnel.

Les tablettes sont-elles équivalentes aux smartphones ?

• Ils sont identiques au point de vue matériel
• Pas de nouveauté non plus concernant le développement d’applications

La révolution se trouve en fait  dans le type de projets réalisés. Le périmètre métier n’est plus aussi restreint qu’avec les smartphones (les équipes sont plus larges, les durées de projet plus longues).

Un accent particulier doit être mis sur la qualité, le design et la conception. Une plus grande liberté est rendue possible grâce aux écrans plus grands des tablettes ; écrans conçus comme un mashup.

Il existe des  enjeux propres aux tablettes :

• Un enjeu de montée en charge (cumul de données)
• Un enjeu de mise en cache
• Une attention particulière doit être portée sur le fait de ne pas trop multiplier les services proposés et de les maîtriser

En conclusion : on assiste à une montée en puissance de nouveaux canaux  (webapps HTML5, tablettes, smartphones, demain télés connectées, réfrigérateurs….) et il est impératif de garder la maîtrise du SI par rapport à tous ces nouveaux besoins.

 Table ronde : retours d’expérience de Arval, Corsairfly, Axa et BNP Paribas Fortis

• Question 1 : En quoi consiste le projet ?

Arval : Sébastien Somchit, Head of Interactive Marketing

Le projet a été lancé mi 2011 et est parti d’une question posée : comment améliorer les relations commerciales ? L’iPad s’est présenté comme un élément efficace face aux clients (accès de qualité à une librairie master de docs références, de façon sécurisée et dans un univers brandé Arval).

Fortis : Yvan Pirenne, Manager Internet & Mobile Banking

L’application easy banking  a pour but la gestion quotidienne sur mobile des opérations bancaires..

Axa : Guillaume Lemêle, Directeur Conseil & Services Distribution Internet & Marketing

L’application a pour but d’aider les commerciaux à la vente d’assurance (ou de banque) sur le terrain : documents facilement à portée de main, mise en gestion automatique.

Corsairfly : Antoine De Kerviler, DSI

L’application doit répondre à un enjeu de reporting pour le personnel navigant. Il fallait 15 à 20 jours pour reporter un problème sur un vol. Le but est maintenant de remonter les informations en 24h et de les traiter grâce à une description catégorisée.

• Question 2 : Pourquoi avez-vous tous choisi l’iPad ?

Fortis : Très bon marketing Apple (affinité au produit) et les critères de sécurité !

Arval et Corsairfly : des tests ont été menés et l’iPad a répondu aux attentes.

Axa : le parc applicatif est énorme et la communauté de développeurs est très importante.

•  Question 3 : Quels sont les enjeux de remplacement en interne des PC par les iPad ?

Axa : à terme un remplacement est envisagé (gain de temps et de praticité en épargnant sur les papiers, les temps de remplissage, de saisie post remplissage…)

Fortis : un remplacement de processus très lourds est envisagé (photocopies, tris, rangements…)

• Question 4 : Les clients sont-ils satisfaits ?

Axa : Un plan B papier est toujours envisageable si le commercial se heurte à la réticence d’un client. Mais dans l’ensemble ils sont majoritairement ok pour jouer le jeu et franchir le pas du numérique.

Fortis : ils semblent satisfaits et les gains escomptés sont à mesurer dans deux types d’action : le conseil et les transactions.

• Question 5 : Question de la sécurité des données clients ?

Axa : Les données collectées ne sont pas gardées sur l’iPad mais sur le Cloud et un outil de MDM est présent pour protéger ces données.

• Question 6 : vie privée/vie public : vous n’avez pas peur que vos salariés jouent avec ?

Corsairfly : Une liberté assez grande est laissée aux employés pour jouer, tester et s’approprier l’iPad mais un focus est fait sur l’importance de respecter la loi et de faire attention aux vols (aéroport, personnel navigant).

• Question 7 : Si l’on se place d’un point de vue RH, comment est géré et perçu l’intégration de ces outils en interne ?

Arval : l’iPad reste un élément statutaire à ce jour. Tout le monde n’en a pas dans l’entreprise mais ça ne durera surement pas à long terme.

Axa : l’iPad est un élément motivant pour les commerciaux : perçu comme un signe de reconnaissance. Mais c’est un outil dont la valeur est intégrée à l’entreprise et qui n’est en aucun cas personnel.

• Question 8 : Question autour de la conduite du changement dans l’entreprise ?

Arval : c’est un projet pilote donc pour le moment les commerciaux sont formés  Il faudra ensuite s’adapter (question autour du bring your own device, systématisation… ?)

Corsairfly : il sera démontré individuellement que l’iPad est générateur de valeur

Fortis : il y aura des changements au niveau réseau. Les employés sont les meilleurs ambassadeurs de ce produit (mais il est essentiel de le maîtriser avant d’en être capable donc un effort sur la formation doit être fait)

Axa : il y a 4500 commerciaux et tout va tourner autour de l’iPad. Les applications doivent donc être faciles d’utilisation ; permettant ainsi d’éviter des formations longues, nombreuses et coûteuses.

• Question 9 : Combien coûte un tel projet ?

AXA : plusieurs millions d’euros.

Fortis : Le gros du budget est parti dans couche de services, interaction avec le SI.

Corsairfly : 60K tout compris pour l’application métier + 350 € par an de TCO pour l’iPad

• Question 10 : Quels sont les défauts de l’iPad ?

Arval : C’est un outil qui n’est pas conçu à l’origine pour du B2B. Peu de productivité et de compatibilité avec Office. On doit adapter les documents à la tablette.

Corsairfly : Les processus d’Apple sont compliqués : difficile d’avoir un contrat, difficulté liée au déploiement, aux numéros de carte de crédit, etc.

Fortis : l’inaccessibilité et la rigidité d’Apple. Nous avons eu de nombreux problèmes pour obtenir une licence, une application en accord avec nos brief et sans beaucoup de possibilités pour interagir.

• Question 11 : Quels sont les conseils de chacun pour bien mener de tels projets ?

Fortis : toujours garder l’œil sur le produit final.

Arval : avoir une vision claire de l’objectif à atteindre et intégrer toutes les fonctions clés au projet (IT notamment pour les questions sécurité, synchronisation, data… et le marketing).

Corsairfly : Tester en conditions réelles ! Ce qui permettra un REX des personnes concernées.

Axa : c’est une opportunité pour les DSI de porter l’innovation. Il ne faut pas avoir peur de se tromper, le projet sera enrichi avec les retours d’usage.

Suggestion d'articles :

1. Petit-déjeuner OCTO – Tablettes : passons à l’ère du post-PC le 26 janvier
2. Petit déjeuner mobilité – iPad, iPhone Android en banque et assurance, préparez-vous au coup d’après !
3. CR du petit-déjeuner organisé par OCTO et Quartet FS « L’analyse décisionnelle en temps réel Convergence entre Big Data et Complex Event Processing »

Depuis trois ans maintenant, NoSQL remet en question le monde centralisé des RDBMS. Les espaces de stockage distribués ne sont pour autant pas nouveaux et les banques, les plateformes de jeux utilisent des « grilles de données » pour adresser leurs enjeux de débit et de latence.

Quels sont les points communs? les principales différences entre les univers NoSQL et « data grids »?

Lire la suite…

Suggestion d'articles :

1. Vers des API haut niveau pour Java et NoSQL avec Spring Data
2. Petit-déjeuner NoSQL : « l’Extreme Transaction Processing » devient une réalité
3. Vidéo du petit-déjeuner NoSQL : « l’Extreme Transaction Processing » devient une réalité

Tous les navigateurs acceptent HTML5 et CSS3 mais tous ne comprennent pas leurs nouvelles fonctionnalités. L’usage de nouveaux attributs HTML5 ou de nouvelles propriétés CSS3 ne bloquera pas votre navigateur, ce dernier les ignora tout simplement. Un avantage indéniable qui nous permet d’utiliser dès aujourd’hui HTML5 et CSS3 même si certains de nos utilisateurs ne disposent pas encore de navigateurs les supportant. Comme je le précisais dans l’article Osez renoncer aux vieux navigateurs, il ne faut pas avoir peur d’utiliser des fonctionnalités HTML5 et CSS3 car des comportements dégradés natifs existent. Quels sont les comportements dégradés natifs acceptables ? Comment profiter d’une fonctionnalité HTML5 ou CSS3 si son comportement dégradé n’est pas acceptable ? Comment pallier l’absence de support des nouvelles API JavaScript si le navigateur ne les possède pas ?

Les comportements dégradés natifs

Des comportements dégradés existent nativement pour la majorité des nouveautés HTML5 et CSS3 lorsque celles-ci ne sont pas supportées par le navigateur. Prenons deux exemples pour illustrer comment les vieux navigateurs se comportent.

HTML5

Certaines fonctionnalités HTML5 sont des évolutions de fonctionnalités existantes, c’est notamment le cas pour les formulaires. Prenons l’exemple des nouveaux types de champs de saisie qui permettent de spécifier un champ de saisie en tant que champ de saisie e-mail, téléphone, date, etc. Cette spécification permet d’avoir un clavier spécifique sur les mobiles et une validation adéquate coté navigateur. Ci-dessous un exemple d’un champ de saisie de type email sur Firefox pour Android 4.

Code original :

1

<input type="email">

Code compris par un navigateur ne supportant pas les formulaires HTML5 :

1

<input type="text">

Si le navigateur ne comprends pas le type (email dans notre cas), le type par défaut utilisé sera text. Votre formulaire sera donc totalement fonctionnel sur un ancien navigateur, votre utilisateur ne bénéficiera pas d’un clavier spécifique ni de la validation coté client mais il pourra soumettre le formulaire. Tout le monde peut utiliser votre formulaire et vos utilisateurs qui utilisent un navigateur récent bénéficieront de fonctionnalités intéressantes sans la moindre charge de développement.

CSS3

On bénéficie également de ces comportements natifs sur les CSS3.

Si vous voyez les coins arrondis, vous êtes un utilisateur génial qui utilise un navigateur récent. Sinon mettez à jour votre navigateur.

Style original :

1
2
3
4
5
6

.boite-arrondie {
  border-radius: 5px;
  padding: 5px;
  background: #ddd;
  border: 2px solid #777;
}

Style utilisé par un navigateur ne supportant pas la propriété CSS3 border-radius :

1
2
3
4
5

.boite-arrondie {
  padding: 5px;
  background: #ddd;
  border: 2px solid #777;
}

Si une propriété n’est pas comprise, elle est tout simplement ignorée par le navigateur et les coins sont rectangulaires. Sans les CSS3, il nous faudrait 1 à 6 images afin de reproduire ce rendu, ce qui en terme de performance n’est pas anodin ni en terme de complexité de code ajouté. Est-ce inacceptable de se priver des coins arrondis sur les anciens navigateurs ? Est-ce pertinent de passer du temps et augmenter la complexité du code ? Il est important de se poser ces questions pour les nouvelles fonctionnalités CSS3 qui vous intéressent.

Ce comportement est notamment très utilisé par les navigateurs qui préfixent les propriétés lorsque l’implémentation n’est pas finale. L’utilisation des préfixes sur certaines propriétés n’est pas utile lorsque les navigateurs supportent la propriété sans préfixe depuis plusieurs versions. Des sites comme Can I Use et CSS3 Generator vous permettront de voir si les préfixes sont indispensables. Ils sont inutiles pour border-radius mais impératifs pour les gradients :

1
2
3
4
5
6
7

.fond-degrade {
  background: -moz-linear-gradient(top, #1e5799 0%, #7db9e8 100%);
  background: -webkit-linear-gradient(top, #1e5799 0%,#7db9e8 100%);
  background: -o-linear-gradient(top, #1e5799 0%,#7db9e8 100%);
  background: -ms-linear-gradient(top, #1e5799 0%,#7db9e8 100%);
  background: linear-gradient(top, #1e5799 0%,#7db9e8 100%);
}

Et si ce comportement dégradé n’est pas acceptable ?

Il peut arriver que le comportement dégradé ne soit pas acceptable et qu’il faille envisager une autre solution. Une approche pourrait être de s’interdire d’utiliser une nouvelle fonctionnalité car 30% des navigateurs de vos utilisateurs ne la supportent pas. Une mauvaise approche car on nivelle par le bas et on se prive de fonctionnalités intéressantes pour l’utilisateur et le développeur. L’utilisateur profite d’une meilleure expérience utilisateur. Le développeur simplifie et réduit son code car une partie est implémentée par le navigateur.

L’approche Graceful degradation

L’approche Graceful degradation consiste à profiter des nouvelles fonctionnalités et proposer une solution de contournement lorsqu’elles ne sont pas disponibles. Pour cela, la librairie JavaScript Modernizr expose de nombreuses méthodes permettant de détecter le support d’une fonctionnalité  HTML5 ou CSS3. On peut ainsi utiliser un Polyfill ou encore, si on décide de ne pas implémenter du tout cette fonctionnalité dans ce cas, alerter l’utilisateur que la fonctionnalité n’est pas disponible. Un Polyfill est un plugin qui fournit une fonctionnalité que le navigateur devrait posséder nativement. Une longue liste de Polyfill est référencée sur GitHub par Modernizr. Ci-dessous un exemple de champ de saisie textuel avec le nouvel attribut placeholder (texte d’aide dans le champ de saisie lorsque celui-ci est vide).

Code HTML :

1

<input type="text" placeholder="exemple de placeholder" />

Code JavaScript permettant de gérer le non support de l’attribut placeholder :

1
2
3
4
5

// si le navigateur ne supporte pas placeholder
if (!Modernizr.input.placeholder) {
  // ajout du comportement avec un plugin jQuery
  $('input[placeholder]').placeholder();
}

L’avantage de cette technique est d’isoler le code lié à la solution de contournement. Ceci nous permettra de le supprimer sans crainte lorsque vos utilisateurs n’utiliseront plus de navigateurs ne supportant pas cet attribut.

L’utilisation de la cascade pour les CSS

En CSS3, certaines propriétés ont de nouvelles valeurs possibles. Il est alors possible de définir deux fois une propriété avec deux valeurs différentes. Prenons par exemple une boite avec un fond semi-transparent :

Si votre navigateur est récent, le fond de ce paragraphe est vert et transparent. Sinon il est rouge vif.

1
2
3
4

.fond-avec-transparence {
  background-color: #ff0000;
  background-color: rgba(0,255,0,0.5);
}

Les navigateurs ne supportant pas CSS3 ne comprendront que la première valeur donc le fond sera rouge. Quant aux navigateurs supportant CSS3, ils comprendront les deux valeurs. Ils appliqueront donc la dernière valeur rencontrée pour la propriété ce qui nous donnera un fond vert avec une transparence de 50%.

Des comportements dégradés pour les nouvelles APIs ?

HTML5 apporte de nouvelles APIs JavaScript (Web Storage, Geolocation, etc.). Ces APIs sont directement utilisables sans import puisque exposées par le navigateur. Des erreurs JavaScript seront donc levées si vous les utilisez alors que votre navigateur ne les possède pas. Aucun comportement dégradé n’existe par défaut, c’est à vous de tester la disponibilité de ces APIs avant de les utiliser. Comme pour les balises HTML5 ou le CSS3, Modernizr permet de tester facilement la disponibilité de ces nouvelles API pour proposer une solution alternative ou non. Un exemple ci-dessous avec l’API localStorage :

1
2
3
4
5

// si le navigateur supporte le localStorage
if (Modernizr.localstorage) {
  // stockage d'une valeur dans le Web Storage local
  localStorage.setItem("clé", "valeur");
}

Aucune raison de ne plus utiliser HTML5 et CSS3

Des solutions existent pour pallier l’absence de support HTML5, parfois simple et fiable, parfois trop complexe ou trop impactant sur les performances du client. C’est un choix à prendre sur la solution de contournement lorsque vous décidez d’utiliser HTML5 et CSS3. Le site HTML5 Please pourra vous aider à prendre ces décisions en vous donnant le support des fonctionnalités et en vous conseillant sur leur utilisation. D’après les statistiques de StatCounter du mois de janvier, près de 70% des français utilisent un navigateur récent qui supporte relativement bien HTML5 et CSS3. Profitez des nouvelles fonctionnalités HTML5 et CSS3, des comportements dégradés natifs et ne prévoyez de solution alternative que si c’est indispensable.

Suggestion d'articles :

1. Osez renoncer aux vieux navigateurs
2. OCTO à Paris Web 2010 pour un atelier HTML5
3. HTML5, offline et sécurité

Le modèle relationnel est né à une époque où l’espace était rare, et fut donc conçu pour minimiser le niveau de redondance des données: il était plus économique de stocker une indirection vers une chaine de caractères que de stocker cette chaine deux fois.
Aujourd’hui, cette contrainte d’espace ne tient plus. On achète un Teraoctet pour 100 dollars, la RAM est abondante, et les disques flash aux performances élevées vont bientôt rejoindre le prix des disques durs rotatifs.

Deux limitations fondamentales du stockage ont donc disparu: le coût de la redondance et le coût de la non-localité pour le traitement de structures de données complexes. Il est maintenant possible de concevoir de nouvelles bases de données plus riches et plus sûres.

Update in place is a poison apple.
- Jim Gray, Turing Award 1998

Le choix d’une base de données mutables n’est plus optimal. Les bases de données purement fonctionnelles n’existent pas encore, mais je pense que les utilisateurs de bases de données auraient déjà intérêt à envisager le stockage read-only et le versioning manuel.

Que veut-on dire par « base de données mutables »? Il s’agit d’une BDD dans laquelle chaque donnée peut être modifiée à tout moment, et dans laquelle on ne garde pas l’historique de ses modifications. Les modifications sont faites « sur place », de manière destructive.

Que veut-on dire par « base de données purement fonctionnelle »? Il s’agirait d’une BDD dans laquelle chaque structure de donnée serait purement fonctionnelle, c’est-à-dire immuable par défaut et ne ferait référence qu’à des données immuables. Pour prendre une analogie programmatique, cette BDD serait une interface vers des snapshots versionnés. Une sorte de Git!

Vers une implémentation plus adaptée

Les données d’une BDD méritent un traitement différencié en fonction de leurs patterns d’usage. Pourquoi par exemple, chez un grand opérateur téléphonique, devrait-on utiliser le même objet « table » pour référencer les monnaies, gérer la liste des clients et la liste des appels? Examinons leurs particularités. A partir de ces trois exemples simplifiés nous allons inférer plusieurs mécanismes fondamentaux d’une base de données purement fonctionnelle.

La liste de référence des monnaies est peu volumineuse. Elle est mise à jour quelques fois par an, tout au plus.
La liste des clients de l’opérateur est moyennement volumineuse. Elle est mise à jour quotidiennement, avec quelques ajouts, suppressions et modifications aléatoires.
La liste des appels est très volumineuse. Elle est mise à jour quotidiennement, mais seulement en insertion.

Nous avons donc au moins trois cas d’usage très différents. Or dans une BDD classique, ces trois données sont stockées de la même manière, c’est-à-dire sous la forme de listes mutables et indexées.
Beaucoup d’effort a été investi pour améliorer les performances de ces tables avec le matériel donné, mais les solutions proposées sont encore très génériques.

Revenons à nos trois données. Il est possible de les implémenter autrement, en faisant appel à trois types d’objets:

• Des listes immuables (de type homogène, et implémentées par exemple par des hashtables sur la clef primaire)
• Des deltas sur ces listes
• Quelques métadonnées peu volumineuses qui serviront à articuler l’ensemble.

La table des monnaies est l’exemple typique d’une liste simple et immuable. La liste d’aujourd’hui s’appelle la ‘v1′. Si demain une union monétaire est créée en Amérique du sud, nous créerons une copie modifiée qui s’appellera la ‘v2′. Pour des raisons de performance, la v1 et la v2 devront être copiées intégralement sur tous les noeuds de la base de données. La performance en update de cette implémentation est médiocre, mais toutes les lectures pourront être faites sans aucun mécanisme de synchronisation.

La table des clients est un peu plus volatile. Tous les jours quelques clients arrivent ou s’en vont, et quelques clients existants peuvent modifier leur adresse postale. Nous pouvons stocker la liste des clients comme une liste immuable ‘v1′, accompagnée par une séquence chronologique de deltas. D’ici à quelques mois, l’accumulation des deltas commencera à affecter la vitesse de lecture: il faudra alors matérialiser la liste, la nommer ‘v287′ et archiver la v1. Dans le cas d’une machine seule, nous retrouvons presque exactement la manière dont Git stocke son historique. Dans le cas d’un cluster, il est bien sûr préférable de partitionner/sharder cette liste sur tous les nœuds.
Selon quelle politique va-t-on vouloir archiver une version, la compresser ou la supprimer? Et selon quelles modalités? Chaque utilisateur doit prendre cette décision en fonction de ses besoins métier. Il est agréable, en tout cas, de remarquer que le Data Lifecycle Management est offert sur un plateau par les BDD fonctionnelles.

La table des appels téléphoniques est différente. Chaque jour elle reçoit des milliers de nouvelles lignes, lesquelles sont parfaitement indépendantes des lignes antérieures. Cette liste est segmentable par journée, et chacun des segments quotidiens est une liste immuable. Nous devrions en plus partitionner chaque segment de manière à coller à la liste des clients: l’ID du client devient alors la clef de partitionnement des appels téléphoniques.

En résumé, à travers ces mécanismes de mise à jour, on accepte de consommer un peu plus d’espace disque, et de réduire la localité des données (car une nouvelle version ne sera probablement pas écrite à côté de l’ancienne). Tout cela pour garder une information plus riche.
Remarquez bien que ces trois idées de versioning s’appliquent aussi bien à l’implémentation d’une nouvelle base de données qu’à une implémentation manuelle, basée sur les outils d’aujourd’hui.

Conséquences

Voilà pour les bases. Observons maintenant les conséquences positives de ces nouveaux choix d’implémentation.

Il devient possible par exemple:

• d’attribuer un identifiant unique à une version complète de la BDD, donc d’exécuter des requêtes de lecture sur une version du passé
• d’effectuer un rollback à tout moment, en reprenant une ancienne version. Pas besoin d’attendre des heures pour recharger!
• de paralléliser le requêtage à l’infini (car les listes immuables et les deltas sont triviaux à copier)
• de hasher cryptographiquement le contenu (à la Git), pour un usage légal ou contractuel
• de connaitre la séquence des processus qui ont fait évoluer la base ou une ligne en particulier
• de diminuer le coût du backup et du Plan de Reprise d’Activité. Réaliser trois copies vers des disques sur étagère coûte peu (car les deltas sont copiables via des écritures non-aléatoires, donc rapides, et sans consommer de CPU)
• de cacher le résultat de toute sorte de traitements, à la manière de vues matérialisées (filtrage, agrégation..)
• de stocker dans la même BDD des objets classiques relationnels, et des objets plus variés (key-value store..)

En l’absence d’ « état global », nous offrons aux processus d’alimentation et d’interrogation de la BDD tous les bénéfices de la programmation purement fonctionnelle. Ces processus deviennent référentiellement transparents (donc sans effet de bord), d’où une meilleure lisibilité pour les équipes de développement et de maintenance, et une diminution du risque d’erreur. De plus, nous avons la garantie que l’ordre d’exécution des processus n’a plus aucune importance.
La qualité de transparence référentielle nous aide aussi à implémenter proprement le pattern Command-Query Separation (CQS), qui conseille de séparer les processus de requêtage des processus d’écriture. Les nombreux « lecteurs » opèrent sur des données immuables, éventuellement disséminées dans un cluster, alors que le processus « modificateur » agit sur les données de référence pour leurs ajouter des deltas.

Quelles sont les contreparties? Il devient plus couteux de réaliser de nombreuses modifications aléatoires sur une grande table. Une BDD purement fonctionnelle ne serait donc pas adaptée à la table d’inventaire d’Amazon, même si l’usage de disques SSD permettrait d’annuler une grande partie de la dégradation de performance.

Remarquez encore une fois qu’une grande partie de ces bénéfices/contreparties s’applique telle quelle dans le cas d’un versioning manuel.

Conclusion

Le choix historique d’implémenter les BDD à l’aide de données mutables n’est plus optimal. Le besoin de protéger les mises à jour dans un environnement concurrent nuit à la scalabilité, et l’absence d’historique et de points de retour rend toute manipulation périlleuse.
Une base de données purement fonctionnelle serait intrinsèquement plus sûre, et offrirait une meilleure scalabilité pour de nombreuses applications. En outre, ses besoins seraient tout à fait compatibles avec les bénéfices des disques flash.
Mon pari est qu’une telle base de données va réellement exister dans les années à venir. Le monde académique en parle depuis les années 80; voir notamment la thèse de Phil Trinder qui avait déjà identifié les conséquences de la transparence référentielle dans les bases de données, puis ouvert la voie vers le requêtage monadique (LINQ) avec ses collègues de l’université de Glasgow. Il ne lui manquait que du matériel plus performant.
Aujourd’hui, la startup RethinkDB et la base in-memory HANA utilisent déjà une partie de cette technologie et atteignent de belles performances.
En attendant l’arrivée et la maturation de ces nouveaux outils, il est déjà possible d’enrichir manuellement nos BDD pour bénéficier, en partie, de leurs avantages.

Bibliographie

http://www-03.ibm.com/ibm/history/exhibits/storage/storage_3330.html (Histoire du disque dur IBM 3330)
http://www.hpl.hp.com/techreports/Compaq-DEC/SRC-TN-1997-018.pdf (Génèse du SQL)
www.cs.ox.ac.uk/files/3404/PRG82.pdf: Phil Trinder « A functional database »
http://www.quora.com/What-would-be-the-main-advantages-of-a-(purely-)-functional-database
http://nathanmarz.com/blog/how-to-beat-the-cap-theorem.html
http://research.microsoft.com/~gray/papers/theTransactionConcept.pdf (Implémentations d’une transaction)

Suggestion d'articles :

1. Outiller un audit de base de données
2. Industrialisation des développements : automatisez votre base de données
3. Des alternatives aux bases de données relationnelles…

La délégation de tâches en asynchrone est un moyen efficace d’alléger la charge que subissent nos systèmes. En effet, de nombreux cas d’utilisation ne nécessitent pas d’être exécutés de façon synchrone lorsqu’un utilisateur effectue une action ou qu’un événement extérieur intervient.

Par exemple, lorsqu’il n’est pas nécessaire de restituer la dernière version des données et que le traitement avant restitution est coûteux en ressources, il est possible de renvoyer des données préalablement mises en cache et de déporter en asynchrone une tâche de rafraîchissement de ce cache.

Un autre exemple concerne les systèmes qui mêlent des requêtes fortement consommatrices en ressources (CPU, mémoire, …) et des requêtes peu consommatrices pour lesquelles on va vouloir garantir une latence faible même lorsque des requêtes consommatrices sont en cours de traitement. Pour cela, déléguer les traitements coûteux à des workers via une file de messages peut aider à garantir des temps de réponse faibles pour les autres requêtes. Cette séparation est d’autant plus importante sur des systèmes qui s’appuient sur des technologies monothreadées telles que Ruby ou NodeJS (ce dernier a néanmoins l’avantage de ne pas consommer de ressources/process lorsqu’il effectue des I/O).

Pour résoudre cette problématique de délégation de tâches, on utilise habituellement une solution comme ActiveMQ ou RabbitMQ. Seulement, lorsqu’il est nécessaire :

• d’être tolérant à la panne
• d’être scalable que ce soit en ajoutant des publishers (qui soumettent les tâches asynchrones) ou des workers (qui consomment et exécutent ces tâches)
• de pouvoir intégrer des systèmes hétérogènes s’exécutant sur différentes plateformes (Java, Ruby, NodeJS, C, …)

aucune de ces deux solutions ne permet de satisfaire l’ensemble de ces critères. Cet article présente une solution possible à base de ZeroMQ, écrite en NodeJS et utilisée pour traiter les deux exemples précédents.

ZeroMQ : Super sockets

ZeroMQ est une bibliothèque réseau écrite en C++ et qui offre des bindings dans de nombreux langages. Elle procure une couche d’abstraction au-dessus des sockets TCP classiques pour ajouter quelques fonctionnalités :

• une communication par message. Contrairement à TCP ou UDP, un message est reçu dans son intégralité ou n’est pas reçu du tout, jamais partiellement. En effet, lorsqu’on utilise des sockets TCP, pour réceptionner des données, il est nécessaire de déterminer la taille des messages ou de rechercher un délimiteur. ZeroMQ le fait pour nous, il nous renvoie le message dans sa globalité. Les messages ZeroMQ sont composés de frames qui permettent de segmenter les informations passées.
• la gestion des reconnexions lors d’une coupure.
• la gestion d’une file de messages au niveau de la socket. Ainsi, lors de la perte d’une connexion, aucun message ne sera perdu, ZeroMQ se chargera de transmettre les messages en file d’attente lorsque la connexion aura été ré-établie. ZeroMQ offre ainsi la possibilité de créer un système de messagerie sans broker en connectant les éléments du système en peer-to-peer. La notion de broker pourra toutefois être réintroduite suivant les besoins.
• l’abstraction du protocole de transport des messages:
  • TCP pour une communication sur le réseau,
  • PGM pour une communication en multicast sur le réseau,
  • IPC pour une communication inter-process au sein d’un même hôte,
  • INPROC, pour une communication au sein d’un même processus (entre plusieurs threads par exemple).
• le support de différents patterns de communication suivant l’association des types de sockets ZeroMQ :
  • PUB-SUB : l’association des sockets PUB et SUB permet de distribuer des messages d’un publisher (socket PUB) vers N consommateurs (socket SUB) qui reçoivent tous les mêmes messages,
  • REQ-REP : le pattern classique de requête/réponse (1 publisher, 1 consommateur),
  • PUSH-PULL : la socket de type PUSH distribue les messages en round-robin dans la file de messages des sockets de type PULL connectées : 1 publisher et N consommateurs qui se répartissent la consommation des messages.

Pour utiliser ces patterns de communication, une socket ZeroMQ est capable de se connecter à plusieurs autres sockets ZeroMQ. Le comportement lors de l’envoi d’un message sur une socket ZeroMQ connectée à plusieurs sockets dépendra du type de cette socket.

Délégation de tâches scalable et tolérante à la panne

Bien que ZeroMQ fonctionne sans broker, il peut être nécessaire de réintroduire dans l’architecture un élément de ce type afin de limiter le nombre de connexions réseau. Par exemple, dans une architecture de délégation de tâches, avec 100 publishers et 100 workers, sans broker, il faudra établir 10 000 connexions (100 publishers * 100 workers) qui risquent d’engorger le réseau. Avec 2 brokers (pour supporter la panne de l’un d’entre eux), il faudra 400 connexions (100 publishers * 2 brokers + 100 workers * 2 brokers).

ZeroMQ propose 2 autres types de sockets qui permettent notamment le routage de messages :

• ROUTER : cette socket ajoute aux messages entrant l’identifiant de la socket ZeroMQ source dans une nouvelle frame qui devient la première frame du message. Ensuite, elle utilise cet identifiant des messages sortants (en supprimant la première frame du message) pour sélectionner la socket destination du message (si elle est connectée bien sûr). En modifiant cette frame, nous sommes capables de personnaliser le routage des messages sortants via cette socket. L’identifiant d’une socket peut être spécifié à la création sinon il sera généré aléatoirement par ZeroMQ.
• DEALER : cette socket permet de recevoir et envoyer des messages (contrairement à la socket PUSH qui peut seulement en envoyer). L’envoi de messages se faisant en round-robin aux sockets connectées.

Avec ces différents types de sockets nous pouvons les assembler de la façon suivante pour obtenir notre système de délégation de tâches asynchrones avec les caractéristiques suivantes :

• chaque publisher peut publier une tâche sur n’importe quel broker,
• chaque worker peut récupérer une tâche et publier le résultat sur n’importe quel broker,
• les brokers sont capables de router le résultat d’une tâche vers le publisher qui l’a publiée.

NB : Nous utilisons ici 3 brokers, pour éviter que les workers envoient systématiquement le même type de message au même broker (ce qui aurait été le cas avec 2 brokers car le worker envoie alternativement un message READY et un message RESULT).

Cette architecture permet de supporter la perte de n’importe quel composant mais aussi d’ajouter des publishers, des brokers ou des workers suivant la charge de tâches à traiter.

• En utilisant une socket de type DEALER du côté des publishers, celle-ci étant connectée à tous les brokers, les messages sont envoyés en round-robin (par ZeroMQ) vers les brokers (étapes 1, 2 et 3 à partir des publishers). Si un broker venait à disparaitre, la socket DEALER continuerait à dialoguer avec les brokers restants et lorsque le broker perdu serait de nouveau accessible, ZeroMQ se chargera de se reconnecter sur ce broker qui réintègrera alors le cycle de round-robin d’envoi de messages.
  Les messages envoyés ne contiennent qu’une seule frame contenant les données de la tâche à exécuter :Code du Publisher :

  1
  2
  3
  4
  5
  6
  7
  8
  

  var broker = zeromq.createSocket('dealer');
  ["tcp://broker1:5555",
   "tcp://broker2:5555",
   "tcp://broker3:5555"].forEach(function(address) {
    broker.connect(address);
  });
  ...
  broker.send("task data");

• Les messages provenant des publishers sont reçus sur une socket ROUTER sur un des brokers. Celle-ci ajoute une frame contenant l’identifiant de la socket DEALER du publisher qui a envoyé le message. Ceci permettra, si le message est envoyé via une socket ROUTER connectée à ce publisher, de router le message vers le bon publisher.
  Le broker a la charge de gérer une file de messages en mémoire, dans un fichier ou dans une base de données selon les besoins (garantie de ne pas perdre de message, performances, …).
  Les messages traités par le broker contiennent donc 2 frames :Code du broker :

  1
  2
  3
  4
  5
  6
  7
  8
  9
  10
  

  var publishers = zeromq.createSocket('router');
  publishers.on('message', function() {
    // Process messages from publishers
    var publisher_id = arguments[0],
        task_data = arguments[1];
   
    // Store in a queue
    ...
  });
  publishers.bindSync("tcp://*:5555");

• Du côté workers, ces derniers se connectent à tous les brokers via une socket DEALER. Ils envoient un message de type READY (en utilisant une frame) pour récupérer une tâche disponible sur les brokers (étapes 1 et 4 à partir des workers). Le type du message est géré dans le code applicatif et non pas par ZeroMQ. Il permet au code applicatif du broker de différencier les messages en provenance des workers :
  • READY pour préciser que le worker est prêt à traiter une tâche,
  • RESULT pour préciser que le message contient le résultat d’une tâche qui devra être transmis au publisher ayant publié la tâche.

  En utilisant une socket DEALER, les messages seront donc alternativement envoyés sur l’un ou l’autre des brokers et la socket gérera la perte d’un broker.
  Le message envoyé par un worker pour récupérer une tâche ressemble donc à :

  Le code du worker :

  1
  2
  3
  4
  5
  6
  7
  8
  

  var broker = zeromq.createSocket('dealer');
  broker.on('message', function() {...});
  ["tcp://broker1:5555",
   "tcp://broker2:5555",
   "tcp://broker3:5555"].forEach(function(address) {
    broker.connect(address);
  });
  broker.send(READY);

• De la même manière que du côté publisher, un message READY se verra ajouter une frame contenant l’identifiant du worker qui l’a envoyé par la socket ROUTER du broker :
• Avec un message contenant une tâche à exécuter (provenant d’un publisher) et d’un message READY (provenant d’un worker disponible), le broker peut constituer un message contenant la tâche en plaçant l’identifiant d’un worker disponible dans la première frame afin que le message soit routé vers ce worker par la socket ROUTER (qui supprimera au passage cette première frame):Le code du broker devient alors :

  1
  2
  3
  4
  5
  6
  7
  8
  9
  10
  11
  12
  13
  

  var workers = zeromq.createSocket('router');
  workers.on('message', function() {
    // Process messages from workers
    var worker_id = arguments[0],
        message_type = arguments[1]; // READY
   
    if (message_type == READY) {
      // dequeue tasks
      var task, publisher_id = ...;
      workers.send(worker_id, publisher_id, task);
    }
  });
  workers.bindSync("tcp://*:5555");

• Le worker (celui qui a envoyé un message READY) reçoit alors le message (étape 2 à partir du broker1) suivant contenant la tâche à exécuter :Le handler de réception d’un message sur le worker :

  1
  2
  3
  4
  5
  6
  7
  

  broker.on('message', function() {
    // Process task messages from broker
    var publisher_id = arguments[0],
        task_data = arguments[1];
    // process task
    ...
  });

Cette architecture permet aux workers de renvoyer une réponse au publisher si l’on veut par exemple que le publisher réponde de façon synchrone sans pour autant accaparer le CPU et bloquer les requêtes suivantes (cas de NodeJS ici). Le cheminement inverse s’effectue alors de la façon suivante :

• Le worker envoie un message contenant le résultat via sa socket DEALER vers les brokers (toujours en round-robin et suivant la disponibilité de ces derniers) en utilisant une frame pour spécifier un type de message RESULT (étape 3 à partir des workers) :Code du handler de traitement des messages par un worker :

  1
  2
  3
  4
  5
  6
  7
  8
  9
  10
  11
  12
  

  broker.on('message', function() {
    // Process task messages from broker
    var publisher_id = arguments[0],
        task_data = arguments[1];
    // process task
    ...
   
    // Send a result to the publisher
    broker.send(RESULT, publisher_id, result);
    // Send READY message to get a new task
    broker.send(READY);
  });

• Un des brokers reçoit le message via sa socket ROUTER qui ajoute une frame avec l’identifiant du worker. Dans ce cas-ci, l’identifiant nous sera inutile.L’identifiant du publisher à l’origine de la tâche étant toujours présent dans le message, il est possible de lui envoyer le message suivant sur la socket ROUTER sur laquelle sont connectés les publishers. La socket routera alors le message vers le bon publisher :

  Le handler des messages en provenance des workers devient alors :

  1
  2
  3
  4
  5
  6
  7
  8
  9
  10
  11
  12
  13
  14
  15
  

  workers.on('message', function() {
    // Process messages from workers
    var worker_id = arguments[0],
        message_type = arguments[1], // READY or RESULT
        publisher_id = arguments[2],
        result = arguments[3];
   
    if (message_type == READY) {
      // dequeue tasks
      var task, publisher_id = ...;
      workers.send(worker_id, publisher_id, task);
    } else if (message_type == RESULT) {
      publishers.send(publisher_id, result);
    }
  });

• le publisher reçoit alors le message contenant le résultat sur sa socket DEALER (étape 4 à partir du broker2) :Le handler de messages d’un publisher :

  1
  2
  3
  4
  5
  

  broker.on('message', function() {
    // Process messages from broker
    var result = arguments[0];
    ...
  });

Conclusion

Comme nous avons pu le constater, ZeroMQ permet d’élaborer une solution adaptée à ses besoins en combinant les différents types de sockets disponibles (d’autres exemples sont accessibles dans le guide ZeroMQ). Cette souplesse vient tout de même au prix d’une certaine complexité puisqu’il faut élaborer son propre protocole (en utilisant les frames des messages ZeroMQ) et traiter quelques sujets qui n’ont pas été abordés dans cet article comme la gestion des timeouts. Par exemple, lorsqu’un broker reçoit avec succès un message READY mais ne peut répondre au worker en raison d’une coupure réseau ou d’un crash du broker, dans ce cas là, sans timeout, le worker pourrait attendre indéfiniment que le broker lui renvoie une tâche à exécuter.
ZeroMQ offre aussi de très bons résultats concernant les performances, que ce soit la latence ou le débit de transmission des messages. Ceci en fait une bonne solution pour les systèmes devant traiter de gros volumes de messages (en nombre ou en taille). Il est cependant moins adapté lorsque l’on ne peut pas se permettre de perdre des messages : dans l’exemple de cet article, la file de messages est n’est pas persisté sur le broker et ZeroMQ ne gère pas de transaction; un message envoyé aux brokers n’est donc pas garantir d’atteindre un worker ou un publisher si un broker crash.

Suggestion d'articles :

1. Créer un cluster ActiveMQ hautement disponible
2. Le push web vu par Diffusion – Partie 1
3. Le push web avec Pusher

Un précédent article a exposé les grands principes de la sérialisation avec Thrift et Procotol Buffers. Ces deux frameworks promettent notamment une représentation des messages optimisée en termes de taille, ce qui est avéré dans le benchmark JVM Serializers : Thrift et Protocol Buffers y obtiennent une réduction de taille du message de 73% par rapport à la sérialisation native Java. Ce benchmark regroupe par ailleurs de nombreux autres frameworks de sérialisation du monde Java, mais se limite toutefois à l’utilisation d’un unique message de test.

Le présent article analyse l’influence de la structure (nombre et taille des objets, complexité de la grappe) sur la compacité du message sérialisé pour Thrift et Protocol Buffers. La comparaison est réalisée en Java, son protocole de sérialisation standard servant de référence.

Conditions du test

Afin d’évaluer diverses structures de messages, le prototype utilise une structure arborescente. Traditionnellement, ce type de structure est récursif. Cependant, il n’est pas compatible avec la limitation de Thrift sur la déclaration avancée abordée dans le précédent article.
La profondeur a donc été arbitrairement limitée au niveau 6, soit 127 nœuds au maximum pour un arbre binaire complet. Il y a un type différent par profondeur, de Node0 pour la racine à Node6 pour les feuilles les plus basses. Les arbres générés le sont selon trois paramètres :

• le nombre total de nœuds, qui permet de faire varier le nombre d’objets du message,
• la cardinalité des fratries , qui joue sur la complexité : plus cette cardinalité est faible pour un nombre de nœuds donné, plus les fratries sont petites et nombreuses, donc plus le message est complexe,
• et la taille des nœuds, qui est fonction du champ « description ». Son contenu est une chaîne de caractères différente pour chacun d’eux et générée par décalage des valeurs Unicode des caractères.

La construction des arbres se fait récursivement et équitablement entre les fils d’un nœud. Ci-dessous trois exemples d’arbre à 5 nœuds avec, de gauche à droite, des tailles de fratries de 1, 2 et 3. Les numéros sont présents à titre indicatif et indiquent l’ordre de création des nœuds par l’algorithme de construction.

Les déclarations dans les IDLs Thrift IDL et Protocol Buffers language sont disponibles en fin d’article. Les versions utilisées sont 0.8.0 pour Thrift, 2.4.1 pour Protocol Buffers et HotSpot 1.6.0_29 pour la JVM.

Impact du nombre d’objets du message

Dans un premier temps, la complexité est fixée au minimum :

• La longueur des descriptions de chaque nœud est constante (32 caractères),
• le nombre de nœuds est variable,
• la structure choisie est le 1024-tree qui équivaut à un arbre à deux niveaux dans cette étude.

En effet, si la cardinalité des fratries est supérieure au nombre de nœuds n, on obtient un arbre à deux niveaux, une racine Node0 et n-1 enfants Node1. Les 1024-trees de cet article ont tous cette structure car n est toujours inférieur à 1024.

Tracer la taille du message sérialisé en fonction du nombre de nœuds donne le graphe suivant :

Aussi bien sur cet histogramme que sur les suivants, une barre plus basse correspond systématiquement à un meilleur résultat et l’ordre des barres (de gauche à droite) correspond à celui de la légende (de haut en bas).
Sur ce premier graphique, on retrouve un constat du benchmark Java Serializers, mais dans un contexte de message plus complexe : Thrift et protobuf ont des performances très proches.

Le graphique ci-dessous rapporte leurs résultats à ceux de la sérialisation Java. On constate que leur avantage en termes de taille de message s’amenuise à mesure que l’arbre grossit.

Sur le graphique suivant, on observe que la taille moyenne d’un nœud décroît rapidement pour la sérialisation Java. En effet, le protocole de sérialisation Java ajoute aux informations du message lui-même la description des classes sérialisées. Ce surcoût, important pour un petit message, devient négligeable pour des messages constitués de nombreux objets du même type.

Les protocoles de protobuf et Thrift, quant à eux, contiennent très peu d’information de structure : uniquement un identifiant de champ et un type. Ainsi ils voient la taille moyenne d’un nœud croître légèrement, car les listes d’enfants augmentent en nombre et taille quand l’arbre grossit.

Impact de la taille des objets

Pour ce second test, on fige la structure du message pour mesurer l’influence de la quantité d’information contenue dans chaque nœud :

• Un 1024-tree est considéré comme dans le test précédent,
• sa taille est fixée à 31 nœuds,
• la taille du champ « description » est utilisé comme variable.

Les résultats concernant la taille du message sont similaires au test précédent, Thrift et protobuf sont très proches et font mieux que la sérialisation Java surtout pour de petits objets.

Figer la structure du message montre que la différence de taille par rapport au protocole de sérialisation Java est quasi-constante. Ceci est dû au fait que protobuf et Thrift n’apportent aucun gain notable lorsqu’on fait varier la taille de la chaîne de caractères.
En effet, les trois protocoles en jeu la sérialisent sous forme de chaîne en UTF8 précédée de sa longueur. La différence est que le protocole Java utilise 2 octets pour la longueur des chaînes de moins de 2^16 caractères, tandis que les deux frameworks ont recours à un varint. Le saut entre 64 et 128 caractères est dû au fait que le format varint n’utilise qu’un octet pour coder les entiers entre 0 et 127, puis deux de 128 à 2^14.

Impact de la structure du message

Pour évaluer l’influence de la structure du message :

• la description de chaque nœud est fixée à 32 caractères,
• le nombre de nœuds est variable,
• la cardinalité des fratries prend trois valeurs : 2, 4 et 1024.

Par exemple, voici les trois variations considérées de l’arbre à 7 nœuds :

Le graphique qui suit recense les tailles des messages sérialisés.

Pour tous les protocoles de sérialisation, le comportement est similaire : plus de complexité conduit à un message sérialisé moins compact.
Cela est dû au fait que plus de complexité se traduit par un plus grand nombre de listes de noeuds-enfants. Cependant, la variation reste négligeable (environ 1%) pour Thrift et protobuf.

Le protocole de sérialisation Java est lui plus fortement influencé (jusqu’à 13%). En effet la quantité d’information utilisée par les descripteurs de classes est liée au nombre de types de classes mises en jeu. Plus les fratries sont grandes, moins on utilise de classes différentes. Par exemple, pour 63 nœuds, le 2-tree utilise toutes les classes de Node0 à Node5, le 4-tree s’arrête à Node3, et le 1024-tree à Node1.
Le résultat particulièrement bon du 2-tree de taille 127 est lié au fait que Node6 n’a pas de liste d’enfants et est donc plus compact que les autres types de Nodes. Dans cet arbre, la majorité des nœuds (64) est de type Node6.

Les tailles moyennes par nœud sont représentées dans l’histogramme ci-dessous :

L’évolution est conforme aux observations du premier test : l’écart entre Java et les deux frameworks s’amenuise lorsqu’on augmente la taille du graphe sans pour autant être négligeable.

En traçant le gain apporté par les deux frameworks par rapport à la sérialisation Java on obtient :

Par exemple, en considérant le message du 4-tree à 63 nœuds et un système devant soutenir une charge de 10000 requêtes/s, le remplacement de la sérialisation Java par Thrift permet de diminuer le besoin de bande passante de 75.45 Mo/s à 40.68Mo/s, soit un gain de 46%.

Conclusion

Cet article a présenté une comparaison portant sur la taille de sérialisation avec des messages complexes. Par rapport au benchmark JVM-serializers, l’avantage de Thrift et protobuf sur la sérialisation native Java est moins décisif en termes de compacité, même s’il reste intéressant.

La taille du message sérialisé par Thrift ou Protocol Buffers n’est pas influencée par la structure même du message. C’est surtout son volume qui a un impact : les deux frameworks offrent une sérialisation bien plus compacte que celle de Java surtout sur de petits messages. Cette observation rejoint le fait que Protocol Buffers n’est pas particulièrement adapté aux volumes de données importants.

Il faut rappeler qu’employer la sérialisation native Java comme référence n’est légitime que parce que cet article se limite aux protocoles de sérialisation. Thrift et Protocol Buffers offrent d’autres avantages tels l’interopérabilité avec plusieurs langages et la compatibilité ascendante et descendante des messages. Ils sont abordés dans l’article précédent.

Pour aller plus loin, on pourrait analyser les temps de sérialisation, l’empreinte mémoire, l’intégration aux processus de build…

Annexes

Voici la déclaration des objets en Thrift IDL : tree.thrift

namespace java com.octo.example.serialization.model.thrift

enum RoomType {
        SINGLE =0,
        DOUBLE =1,
        SUITE =2
}
struct Node6 {
    1: optional i32 number,
    2: optional bool even,
    3: optional double rate,
    4: optional RoomType type,
    5: optional string description,
}
struct Node5 {
    1: optional i32 number,
    2: optional bool even,
    3: optional double rate,
    4: optional RoomType type,
    5: optional string description,
    6: list children,
}
[...]

et ainsi de suite jusqu’au Node0, qui correspond la racine de l’arbre. L’ordre employé évite le recours à la déclaration avancée.

Ci-dessous, l’équivalent en Protocol Buffers language : tree.proto

package serialization;

option java_package = "com.octo.example.serialization.model";
option java_outer_classname = "LimitedTreeProto";

enum RoomType {
    SINGLE =0;
    DOUBLE =1;
    SUITE =2;
}
message Node0 {
    optional int32 number =1;
    optional bool even =2;
    optional double rate =3;
    optional RoomType type =4;
    optional string description = 5;
    repeated Node1 children = 6;
}
[...]
message Node6 {
    optional int32 number =1;
    optional bool even =2;
    optional double rate =3;
    optional RoomType type =4;
    optional string description = 5;
}

L’ordre des nœuds plus naturel est supporté par le compilateur Protobuf.

Suggestion d'articles :

1. Sérialisation : Thrift et Protocol Buffers, principes et aperçu
2. Socle technique des applications Java EE : dans le WAR ou dans le serveur ?
3. Les nouveautés du langage dans Java 7

Suite de notre cycle d’ateliers dédiés aux praticiens agiles, avec une nouvelle session au format Open Space le 14 Février de 14h à 18h dans les locaux d’OCTO. 3 bonnes raisons d’y participer :

 

1.Un rendez-vous dédié aux acteurs des DSI :

Le calendrier IT agile est déjà plutôt chargé, mais il se compose pour majeure partie de rendez-vous réservés aux « experts » de l’agile : gourous, coachs, formateurs, etc. Aucun n’est dédié à ceux qui font au quotidien, c’est à dire aux équipes internes au sein des DSI. Or Product Owner, ScrumMaster, MOA, Tech Lead, PMO, tous sont confrontés à des problématiques récurrentes au sein de leurs projets agiles.

 

2.De nouvelles pistes pour continuer à progresser :

L’objectif des Open Spaces est de partager entre pairs vos questions, vos problématiques, vos doutes, vos convictions et vos retours d’expérience :

• Comment intégrer les équipes UX ou Webdesign dans le process agile ?
• Comment donner de la visibilité à long terme à sa hiérarchie ?
• Comment diffuser la culture de l’amélioration continue ?
• Comment garantir le pérennité des rituels ?
• Comment mieux coopérer avec les équipes d’exploitation ?

Après plusieurs mois, voire plusieurs années de pratiques agiles au sein de ses équipes, il est primordial de lever de temps en temps la tête du guidon et de considérer au-dehors les choix que d’autres ont faits.

 

3.Un support illustré retraçant les échanges :

Comme lors de la première session cet automne, Véronique Olivier-Martin revient pour capter la substantifique moelle de nos échanges et la restituer sous forme d’illustrations sur une fresque murale véléda. Chaque participant repartira avec une version numérisée du croquis d’ensemble retraçant l’évolution des échanges au fil de la session et quelques zooms en bonus sur les croquis les plus percutants !

 

A l’issue de cet atelier, vous aurez pu :

• Proposer des sujets au coeur de vos problématiques et les traiter avec vos pairs sous d’autres angles
• Partager votre propre expérience d’agiliste sur des questions que se posent d’autres praticiens, au sein d’autres organisations
• Découvrir des pratiques agiles, des process et des organisations en place dans d’autres DSI
• Etendre votre réseau au sein de la communauté agile

Animateurs :

Christophe Thibaut & Mathieu Gandin : Consultants Seniors et Coachs Agile OCTO

Progamme :

• 14h : Accueil
• 14h00-14h15 : proposition des sujets
• 14h15-17h45 : Open Space ( 2 à 3 sessions d’ateliers suivis de restitutions)
• 17h45-18h : Restitution finale

Cliquez ici pour vous inscrire à l’Open Space du 14 Février

Suggestion d'articles :

1. Retour sur la première session Open Space praticiens agiles
2. Open Space pour les praticiens agiles le 24 novembre chez OCTO
3. Open Space « La Pilule Rouge – Comment faciliter la collaboration distante dans nos organisations ? »

Agenda :

• Introduction aux enjeux d’analyse de données en temps réel
• Présentation des architectures d’analyse de données
• Présentation de la solution Open Source ESPER
• Présentation de la solution ActivePivot Sentinel (Quartet FS)
• Questions/Réponses

Définition : « Un système d’analyse de données temps réel est un système évènementiel disponible, scalable et stable capable de prendre des décisions (actions) avec une latence inférieure à 100ms »

100ms est l’ordre de grandeur retenu lorsque l’on parle de « temps réel ». Cette valeur permet de prendre les décisions dans un temps adapté au business.

Quelles différences avec l’analyse traditionnelle ?

• Les systèmes décisionnels sont construits sur des mécanismes qui imposent la duplication des données… donc avec un temps de latence importants.
• Notion de reporting opérationnel c’est à dire sur des données vivantes : on dépasse rapidement les 1000 TPS (transactions par secondes), ce qui est une limite au-delà de laquelle la latence des SGBDR explose (source : TPC.org).
• La prise de décision ne peut pas être prise dans la zone de stockage à cause de la latence, mais doit l’être idéalement en amont (à l’extérieur) pour une meilleure réactivité.

Quels intérêts pour les entreprises ?

Les entreprises sont déjà aujourd’hui confrontées aux problématiques de volumétrie. A cela s’y ajoute 3 nouveaux facteurs majeurs entraînant toujours plus de données dans nos systèmes :

• Une multiplication des appareils connectés, entraînant une augmentation des évènements qui devront être traités, et l’augmentation des sources d’évènements
• Une fusion des poches d’utilisateurs et une augmentation de leur nombre.
• Une forte volatilité du trafic (pic de connexion / utilisation) qui suit le rythme du métier (ex : saisonnalités dans le e-Commerce).

Pourquoi CEP ?

Définition : Le  Complex Event Processing (CEP) est une technique permettant de manipuler des événements au fur et à mesure de leur prise en compte, d’identifier des relations entre ces événements (corrélation, causalité, patterns), et d’en tirer de l’information sous forme de nouveaux événements dits « dérivés » ou « complexes ».

Le CEP apparaît être une opportunité pour l’analyse et la prise de décision en temps réel là ou même le stockage sur cache/grille de données seul peut montrer ses limites :

• la synchronisation cache/stock sur disque devient un problème sur de gros volumes de données
• Le décisionnel implique des requêtes complexes sur des volumes de données importants

Pourquoi faire converger Big Data et CEP ?

• Pour mieux tirer profit de l’augmentation des volumes de données : les SI ont besoin d’infos de plus en plus détaillées.
• Pour permettre des analyses de plus en plus complexes (systèmes de scoring, détection de comportement, machine learning…).
• Pour traiter efficacement de nouvelles sources de données (sociales, peu structurées…)
• Pour permettre, et c’est un point fondamental, de faire des expérimentations (ie. pouvoir interroger le système, découvrir de nouvelles règles, les tester, les mettre en place et les adapter si besoin).

L’intérêt principal du CEP réside dans le traitement en mémoire de l’événement avant son stockage, afin de conserver une forte réactivité.

Détails sur l’analyse en temps réel :

• Traitement évènementiel à faible latence
• Traitement en mémoire
• Fonctionnalités de traitement des évènements (jointure de flux corrélés, pattern matching, règles)
• Historisation des évènements traités
• Simulation sur des données historiques (backtesting)
• Des IHM sont présentes et répondent aux questions des données historiques et des données en temps réel (que s’est-il passé/que se passe-t-il ?). Permet de visualiser et d’explorer les données
• Il existe des IHM d’édition des règles utilisable directement par les métier / les analystes et sans besoin de développements particuliers.

Enjeux de l’analyse en temps réel :

• Latence
• Débit
• Consommation de mémoire
• Répartition sur plusieurs nœuds
• Reprise sur panne
• Initialisation à partir de l’historique
• Richesse des interfaces pour l’analyse des données temps-réel et historique
• Possibilité de modifier facilement les règles d’analyse et de les valider rapidement

L’approche peut se faire par :

• des outils de pur CEP : (ex : Streambase, Tibco Business Events, Microsoft StreamInsight, ESPER…) : particulièrement performants sur l’analyse des évènements sur des échelles de temps courtes, il faudra leur adjoindre des systèmes de stockage des données historiques, et d’IHM évoluée
• des outils de datagrid : (ex : SQLFire, GigaSpaces) : très adapté au stockage à fort débit d’écriture, et fournissant des possibilités de traitement des données à chaud (type trigger), ces outils devront être secondés d’IHM évoluées pour répondre au besoin
• des outils OLAP en mémoire : (ex QuartetFS) : outils très adaptés au cas des analyses multidimensionnelles en temps-réel

Démo ESPER (moteur CEP Java) : nous ne sommes pas en mesure de vous proposer les vidéos aujourd’hui ; nous vous proposons de retrouver les démos en vidéos plus tard.

Démo ActivePivot Sentinel : nous ne sommes pas en mesure de vous proposer les vidéos aujourd’hui ; nous vous proposons de retrouver les démos en vidéos plus tard.

Suggestion d'articles :

1. L’analyse décisionnelle en temps réel Convergence entre Big Data et Complex Event Processing
2. OCTO organise un petit-déjeuner sur le thème « Usability » le 09 octobre à Paris
3. Vidéo du petit-déjeuner « Comment bâtir votre Cloud ? » organisé par OCTO Technology

Une date à retenir ? Oui !  Le mardi 31/01/2012 pour nous faire part de vos idées sur les sujets IT, techniques, métiers ou liés aux aspects managériaux de la DSI !

Pas d’idée de session ? Aucun problème ! Vous pouvez élire votre session préférée en votant pour elle !  D’ailleurs vous pouvez aussi la partager  pour augmenter le nombre de vote !

Pour rappel : la qualité du résumé de session proposé (fond et forme) sera le critère de sélection principal pour l’équipe USI. Merci donc d’en tenir compte lors du remplissage de ce formulaire.

L’équipe programme étudiera toutes les propositions et sélectionnera les sessions qui lui paraîtront les plus intéressantes. Vous serez peut-être invité à venir présenter votre session lors d’une journée dédiée : mi février et nous informerons de notre décision finale fin mars 2012.

Cliquez ici pour soumettre votre session à l’USI

On attend vos candidatures avec impatience !

 

Suggestion d'articles :

1. Appel à candidature : proposez votre session à USI 2012 !
2. Avez vous la culture Cloud ? sur tv4it.net
3. Derniers jours pour profiter de votre place USI 2011 à -20%, les 28&29 juin prochains !

OCTO organise le mardi 07 février 2012 à partir de 8h45 un petit-déjeuner gratuit, aux Salons Wagram  « L’agilité à grande échelle » : retour d’expérience en partenariat avec Strator.

 

Un projet de développement logiciel impliquant 80 personnes, distribuées sur 9 équipes réparties dans 4 pays.
Un produit devant soutenir une activité de plus de 5 000 000 de transactions de vente par jour.
Une première mise en production au bout de 6 mois.
Et de nouvelles fonctionnalités tous les deux mois.

 

Qui a dit que l’agile n’était pas adapté aux gros projets ?

Strator et OCTO Technology se proposent de partager avec vous un retour d’expérience sur la mise en place de méthodes agiles à large échelle : feature-teams, communautés de pratique, interactions avec des équipes off-shore, livraisons fréquentes et mises en production par un simple clic, prise de décisions collaboratives…

A l’issue de ce séminaire nous aurons partagé avec vous :

• Nos Do’s & Don’t à propos des méthodes agiles lorsqu’elles sont appliquées à de gros projets
• Les modèles d’organisation que nous avons mis en oeuvre
• Nos meilleures pratiques pour diriger des équipes projets géographiquement distribuées
• Les outils et les compétences clés pour démarrer un tel projet

 

Ce petit-déjeuner s’adresse aux :

• DSI
• Chefs de projets
• Responsables Innovation / e-business / Internet
• Responsables MOA / MOE
• Architectes

 

Intervenant(s) :
Philippe Chevalier – Strator, Directeur Technique
Hervé Lourdin – OCTO, Delivery Manager
Mathieu Despriee – OCTO, Manager

 

Ce petit-déjeuner est à destination de nos clients et prospects en priorité.

Cliquez ici pour vous inscrire au petit-déjeuner : Agilité

Suggestion d'articles :

1. Vidéo du petit-déjeuner « Comment bâtir votre Cloud ? » organisé par OCTO Technology
2. OCTO organise un petit-déjeuner Gestion des Identités le 27 janvier – Témoignage d’Air Liquide
3. OCTO organise un petit-déjeuner sur l’agilité, jeudi 12 novembre

 

Pour la troisième fois cette semaine, Edouard, votre Product Owner, vous a demandé sur quoi vous pouviez vous engager pour cette itération ?

Vous souhaitez annoncer à Sophie du Marketing dans combien de temps votre fonctionnalité principale sera réalisée, mais vos indicateurs actuels vous donnent le vertige ?

Lors du sprint planning, 10 écrans ont dû être estimés. Vous êtes dubitatif : quel écran doit porter le coût de développement du premier ?

Dans un autre registre, vous démarrez un projet Agile sur un lourd existant. Comment concilier le manque de tests unitaire avec des itérations rapides ?

L’équipe mainframe n’est pas Agile, et demande des commandes trois mois à l’avance. Est il possible de faire de l’Agile dans ces conditions ?

Je suis manager. Avant, je rédigeais des plannings, et j’attribuais des tâches à chacun. Quel sera mon rôle dans la nouvelle organisation ?

Vous avez envie d’en parler, venez le mardi 31 janvier à l’Apéro Agile dans les locaux d’OCTO !

Autours d’un verre, nous discuterons de pilotage, d’intéractions avec des projets non agiles, ainsi que de postes et de carrière. Nous parlerons de pratiques, de techniques, et de vos réussites.

Que vos équipes soient déjà Agiles, que vous soyez vous même praticien de longue date, ou que vous souhaitiez vous mettre à l’Agile prochainement, venez partager avec d’autres pratiquants vos problèmes du quotidien afin de les résoudre ensemble.

L’inscription est ouverte aux 20 premiers : http://aperoagile2.eventbrite.com/

Edit : Je suis impressionné ! Les 20 places sont parties en une soirée ! Du coup, j’ai ouvert une liste d’attente. Inscrivez vous si vous le souhaitez, vous serez contactés en cas de désistement.

Derrière cette formulation humoristique se cache un des fondements de l’industrialisation des développements : le fait de pouvoir tester de manière automatisée tout ou partie d’un système informatique.

Aussi bien dans les architectures complexes que dans les applications les plus simples, il est pertinent de pouvoir tester un composant logiciel unitairement (indépendamment des autres composants duquel il dépend) : les dépendances sont donc « mockées » ou simulées en français.

Il est aussi nécessaire de pouvoir créer un contexte favorable au scénario de test en injectant un jeu de données particulier via un automate de tests ou un injecteur.

Le développement d’applications Kinect n’échappe pas à cette nécessité. Voici comment simuler une Kinect avec la librairie MocKinect.

Ras la Kinect

Pour rappel, la Kinect est un périphérique composé de capteurs optiques (video couleur et infrarouge) permettant de capturer une vue en relief des éléments entrant dans son champ de vision. Le SDK (kit de développement) Kinect intègre une fonctionnalité d’analyse de l’image et de reconnaissance de forme humaine qui génère un « pseudo-squelette ».

Capture des flux venant des capteurs

Flux video

Flux infrarouge

Squelette reconnu

Pour plus d’informations sur le fonctionnement de la Kinect, consultez l’article Kinect : un tour d’horizon tout naturellement.

La détection de mouvement se basant sur des seuils et des distances, il faut souvent travailler par ajustements successifs. Tester un scénario d’utilisation Kinect est d’autant plus long et fastidieux pour un développeur qu’il lui faut :

• Ajuster le code et lancer l’application
• Se lever et se mettre en position face à la Kinect
• Effectuer le ou les mouvements
• (éventuellement se rendre compte qu’il a oublié d’enlever un breakpoint dans le code)
• Vérifier le comportement de l’application
• Constater le bogue
• S’asseoir
• Ajuster le code puis lancer l’application
• Se lever et se mettre en position face à la Kinect
• Et ainsi de suite…

Même si ce type d’exercice est bon pour la santé, cela ne vaut pas une activité sportive au grand air et cela impacte fortement la productivité.

Avec MocKinect, je m’en mock de la Kinect

Pour faciliter mon travail, j’ai développé la librairie MocKinect (http://mockinect.codeplex.com/) qui contrairement à son nom n’est pas un mock mais un injecteur (on ne peut pas toujours résister à un mot-valise).

MocKinect permet d’enregistrer les flux bruts venant des capteurs de la Kinect et de le stocker pour les rejouer ultérieurement.
La librairie s’utilise en deux temps :

• Se lever et s’enregistrer en train de faire les gestes qui devront être utilisés dans l’application
• S’asseoir pour coder et tester en rejouant la scène enregistrée autant de fois que nécessaire

Une fois les enregistrements effectués, il est possible d’utiliser MocKinect SANS Kinect. Vous pouvez ainsi intégrer les tests Kinect dans une usine d’intégration continue et même contrôler leur exécution avec des outils de tests fonctionnels tels que FitNesse ou GreenPepper.

MocKonception

Pour favoriser l’utilisation de cette librairie, j’ai voulu limiter les freins inhérents à l’intégration de nouveaux frameworks en suivant ces deux principes :

• Avoir un coût d’intégration quasi nul sur le code de l’application
• Avoir un impact minimum sur les performances en exécution

Pour cela, j’ai opté pour une solution utilisant l’encapsulation. MocKinect est donc composé d’un ensemble de classes reprenant les prototypes des classes du SDK Kinect de Microsoft. Pour l’utiliser, il suffit de remplacer la directive d’inclusion du SDK par celle de MocKinect.

Remplacez:

1

using Microsoft.Research.Kinect ;

Par:

1

using MocKinect;

Le déclenchement d’un enregistrement ou d’une injection s’effectue par l’appel à la méthode SetMode.

1
2
3

// Mode proxy
kinectRuntime.SetMode(MocKinectMode.Reality);
// L'application reçoit les informations issues des capteurs de la Kinect

1
2
3
4

// Enregistrement
kinectRuntime.SetMode(MocKinectMode.Record, "SwipeGesture");
// L'application reçoit les informations issues des capteurs de la Kinect
// Ces informations sont en même temps enregistrées dans le fichier SwipeGesture

1
2
3
4

// Injection
kinectRuntime.SetMode(MocKinectMode.Replay, "PinchGesture");
// La véritable Kinect est désactivée
// Les flux précédemment enregistrés dans le fichier PinchGesture sont lus et injecter dans l'application

L’impact sur les performances est assez faible et peut être réduit en optimisant la gestion du tampon (buffer) d’enregistrement des flux. Une application recevant 25 images Kinect par seconde peut voir ce débit réduit à 20 images par seconde en utilisant MocKinect.

Appel à MocKontribution

MocKinect est encore en version bêta et beaucoup de fonctionnalités peuvent être rajoutées pour améliorer la productivité des développeurs d’applications Kinect.
Parmi celles-ci :

• Mocker plusieurs Kinects simultanément
• Gérer l’enregistrement et l’injection des données de squelettes
• Compresser les données issues de l’enregistrement
• Améliorer la compatibilité avec les modes évènementiels et par échantillonnage

N’hésitez pas à partager vos recommandations ou m’indiquer votre envie d’être contributeur afin de mener ce projet à bien.

Dans la même veine, la Kinect Toolbox de David Catuhe permet d’enregistrer/rejouer un squelette et fournit de plus un socle de reconnaissance de mouvements (Gestures)

Kinews de dernière minute

Au moment de l’écriture de cet article, Microsoft a annoncé la sortie officielle de la Kinect For Windows. Ce périphérique est similaire à la Kinect pour Xbox mais sera dédié à un usage PC. Cette nouvelle Kinect apportera un gain de performance et de précision, elle pourra gérer le « near-mode » (objet à 50 cm des capteurs). Son SDK intégrera la reconnaissance de mouvements types et permettra probablement la détection précise des doigts de la main.
Rendez-vous le 1er février lors de la mise sur le marché de ce nouveau périphérique et les 7-8-9 février pour la conférence Microsoft TechDays.

Suggestion d'articles :

1. Kinect: un tour d’horizon tout naturellement
2. Quoi de neuf avec la Kinect ?

Introduction

Depuis que les sites web sont devenus des applications riches, le besoin de push s’est largement manifesté. Il est présent sur des sites de mails, de feeds d’information, de partage de documents, de réservation de billets avec choix des places… Le push web permet de notifier le client d’une certaine information directement depuis le serveur, sans nécessiter de recharger la page du client. C’est typiquement un paradigme qu’on peut utiliser sur un site de messagerie instantanée.

Plusieurs technologies permettent d’implémenter ce genre de comportement, les plus connues étant probablement les WebSockets, les server-sent events (tous deux inclus dans les spécifications HTML5), ou encore le long polling, du web pull simulant du web push, utile sur certains navigateurs des moins récents.

Pusher Le produit

Un précédent article posté sur ce blog présentait le push web implémenté avec Diffusion (article en 2 parties). Nous allons présenter dans cet article une autre solution reposant sur la technologie WebSockets : Pusher.

Pusher se compose d’une API développée pour plusieurs langages (Ruby, Ruby on Rails, PHP, et ASP .Net) et d’une Infrastructure as a Service hébergée sur Amazon EC2, ce qui lui confère une scalabilité appréciable. Toute l’infrastructure gérant les connexions WebSockets et les canaux côté serveur est implémentée par la plateforme cloud Pusher. Il se distigue en cela d’autres frameworks tels socket.io qui implémentent uniquement la technologie WebSocket avec de nombreux fallbacks en cas d’incompatibilité, mais laissent la main à l’utilisateur sur la mise en place de l’infrastructure.

D’autre part, la PaaS Heroku ne supportant pas la technologie WebSocket, Pusher propose un add-on permettant son utilisation sur la plateforme de déploiement.

Mise en pratique Canal Public

Sans plus attendre, passons à la pratique en mettant en place un site de messagerie instantanée, illustration typique de push web. Cet exemple permettra à la fois de transmettre des messages à tous les utilisateurs connectés, mais aussi d’afficher la liste de tous les utilisateurs présents. La compréhension de cette article implique des connaissances basiques en Ruby on Rails et en javascript, notamment jQuery. Vous pouvez d’ores et déjà trouver une démonstration de l’application finale ici (attention, rendu minimaliste !). Les credentials à utiliser sont test@pusher-chat-example.com/tester et test2@pusher-chat-example.com/tester. Tout le code est disponible sur github.

Au préalable, nous avons déjà mis en place un site développé en Ruby on Rails, déployé sur Heroku, et équipé de l’add-on Pusher. La librairie javascript jQuery est également ajoutée au projet. Enfin, le projet est configuré pour utiliser la gem pusher.

Le site dispose d’une page d’accueil et  d’une page d’authentification. Tout utilisateur accédant à la page d’accueil est déjà authentifié. La page d’accueil sera celle où nous créerons le service de messagerie instantanée.

Pour commencer, nous devons inclure dans notre page le fichier de l’API javascript de Pusher. On ajoute donc la ligne suivante dans le fichier html de la page d’accueil.

index.html.erb :

<%= javascript_include_tag "http://js.pusher.com/1.11/pusher.min.js" %>

Lors de l’ajout de l’add-on pusher depuis Heroku, un compte Pusher nous a été attribué.  Depuis ce compte, nous pouvons récupérer des informations d’identification pour le développement et pour la production. Ajoutons ces informations dans les fichiers appropriés :

config/environments/development.rb :

Pusher.app_id =  '13342'
Pusher.key    = 'd8d6a55bc5e7ffb81f0e'
Pusher.secret = 'my-development-secret-key'

config/environments/production.rb :

Pusher.app_id = '13341'
Pusher.key    = '6c786501a9b463e4465d'
Pusher.secret = 'my-production-secret-key'

Notre projet est à présent correctement paramétré pour utiliser Pusher. Nous pouvons désormais créer une fonction javascript d’initialisation qui s’abonne à un canal de push que l’on appelle « instant-messaging-channel » et ouvre une connexion sur ce canal vers la plateforme cloud de Pusher. L’application est identifiée auprès de Pusher par l’API key. La fonction d’initialisation est appelée au chargement de la page.

application.js :

function subscribeToPush() {
  var pusher = new Pusher('d8d6a55bc5e7ffb81f0e');
  var channel = pusher.subscribe('instant-messaging-channel');
}

Pour l’instant, la clé de l’API est écrite en dur dans le code.

D’autre part, côté html, nous ajoutons un formulaire depuis lequel nous pourrons poster un nouveau message aux destinataires, ainsi qu’un peu de code « cosmétique ».

index.html.erb :

<h1>Messagerie Instantanée</h1>
<div id="instant-messaging" data-pusher-key="<%=Pusher.key%>">
  <%= form_tag "home/send_message", :remote => true do %>
    <%= text_field_tag "message" %>
    <%= submit_tag "Envoyer" %>
  <% end %>
</div>

On constate qu’un attribut data de la balise div permet de communiquer la clé de l’API Pusher au javascript. Cela nous permet de récupérer la clé de développement ou de production via jQuery. On peut ainsi modifier la fonction javascript comme suit.

application.js :

function subscribeToPush() {
  var pusher = new Pusher(jQuery('#instant-messaging').attr('data-pusher-key'));
  var channel = pusher.subscribe('instant-messaging-channel');
}

Lorsqu’on poste un nouveau message par le formulaire, on souhaite maintenant qu’il soit diffusé sur  le canal et dispatché entre les différents abonnés du canal. L’action appelée par la soumission du formulaire est l’action send_message du contrôleur home. Dans cette action, on récupère le contenu du message posté par le formulaire, et on le diffuse sur le canal « instant-messaging-channel ». On définit l’évènement que l’on souhaite diffuser à travers ce canal comme du type « new-message ». Les données associées à l’évènement envoyé sont un hash qui contient ici le message posté avec :message comme clé. On répond ensuite par un header http de code 200.

home_controller.rb :

def send_message
  message = params[:message]
  Pusher['instant-messaging-channel'].trigger('new-message', {:message => message}) unless message.blank?
  head :ok
end

Ca n’est pas encore visualisable, mais croyez moi sur parole, nous diffusons à présent un évènement sur notre canal « instant-messaging-channel » chaque fois que nous cliquons sur le bouton d’envoi, et tous les abonnés de ce canal le reçoivent. L’évènement, comme l’indique le schéma présenté plus haut, est envoyé depuis le serveur de l’application (en l’occurrence, le serveur Heroku) vers la plateforme Pusher. Cette dernière le redistribue alors vers tous les clients ayant ouvert une connexion avec la même clé d’API Pusher et le même nom de canal.

Il nous reste maintenant à capter l’évènement poussé sur le client et à le traiter. Pour cela, nous allons ajouter un callback à notre canal. Celui-ci sera appelé chaque fois qu’un évènement de type « new-message » sera poussé sur le canal « instant-messaging-channel ». Nous utiliserons pour ça la fonction bind() de l’API javascript de Pusher. Dans notre application de messagerie instantanée simple, le traitement du callback sera de récupérer les données associées à l’événement, c’est-à-dire le hash envoyé depuis le contrôleur, et de les afficher les uns à la suite des autres. Donc, dans notre méthode d’abonnement au canal, nous ajoutons les lignes ci-dessous.

application.js :

function subscribeToPush() {
  var pusher = new Pusher(jQuery('#instant-messaging').attr('data-pusher-key'));
  var channel = pusher.subscribe('instant-messaging-channel');
  channel.bind('new-message', function(data) {
    jQuery('#instant-messaging').append(data.message + "<br />");
  });
}

Et voilà ! comme disent les américains. Vous avez à présent une application de messagerie instantanée, minimaliste certes, mais fonctionnelle. Pour la tester en local, il suffit de s’y connecter depuis plusieurs navigateurs différents. Nous pourrions à présent ajouter devant chaque message l’e-mail de son auteur très facilement. Il suffirait d’ajouter la paire clé/valeur e-mail dans les données associées à l’événement « new-message » lors de son envoi, et de récupérer ce nouveau paramètre à la réception de l’événement pour l’afficher à l’endroit qui convient. Le canal utilisé ici est un canal dit public, et son principe reste très simple.

Canal Présence

Nous allons à présent voir comment connaître en temps réel la liste des différents utilisateurs connectés au service de messagerie en utilisant un canal de présence. Le principe ici est globalement similaire à celui du canal public, mais il s’en distingue par quelques subtilités ayant leur importance.

L’idée est la suivante. Lorsqu’un client se connecte à Pusher, un token unique pour l’utilisateur et l’application est généré et lui est attribué. Lorsque ce même client souhaite s’abonner à un canal de présence (ou à un canal privé, dont le fonctionnement est sensiblement identique), l’API envoie d’abord une requête au serveur de l’application pour savoir si l’accès lui est autorisé. Le serveur peut déterminer l’autorisation d’accès grâce au nom du canal qui est transmis en paramètre. Le cas échéant, le service d’autorisation retourne avant tout une clé d’authentification. Cette clé permettra ensuite à Pusher de déterminer que l’utilisateur a bien accès au canal. D’autre part, le service retourne également certaines informations concernant l’utilisateur : un id obligatoire, d’une part, et toutes les informations que l’on souhaiterait voir transiter dans le canal de présence d’autre part (e-mail, statut, IP,…). Le message ainsi retourné ressemble à cela :

{"auth" => "d8d6a55bc5e7ffb81f0e:0d355103f73ba4de6a6f56975d3261bcea", "channel_data" => "{"user_id":4, "user_info":{"email":"mark.zuckerberg@gmail.com", "ip":"127.0.0.1"}}"}

Le schéma suivant illustre ce processus :

Maintenant que le principe est clair, passons à la pratique. On va donc commencer par définir auprès de l’API Pusher l’url sur laquelle il doit authentifier l’utilisateur. On ajoute dans la méthode subscribeToPush() :

application.js :

Pusher.channel_auth_endpoint = 'home/authenticate'

On demande ensuite un abonnement au canal présence (dont l’identifiant doit impérativement commencer par ‘presence’) :

applicaton.js :

var presence_channel = pusher.subscribe('presence-instant-messaging-channel');

Mais toute tentative d’abonnement à ce canal fera appel au service d’authentification que nous n’avons pas encore implémenté. Il faut donc ajouter l’action authenticate dans le contrôleur home.

def authenticate
  if user_signed_in?
    response = Pusher[params[:channel_name]].authenticate(params[:socket_id], {:user_id => current_user.id, :user_info => { :email => current_user.email}})
    render :json => response
  else
    render :text => "Not authorized", :status => '403'
  end
end

Ici, nous vérifions simplement que l’utilisateur s’est bien connecté au site, mais les contrôles pourraient être plus poussés et personnalisés, puisque l’identifiant du canal (« presence-instant-messaging-channel ») est passé dans les paramètres. La seule information pertinente que nous souhaitons envoyer à propos de l’utilisateur est son e-mail.

Les canaux de présence répondent par défaut à 4 évènements déclenchés par Pusher :

• « pusher:subscription_succeeded » : envoyé quand l’abonnement a réussi. Une liste d’informations des membres connectés à ce même canal est envoyée conjointement à l’évènement.
• « pusher:subscription_error » : envoyé si une erreur est survenue pendant l’abonnement. Le code http de l’erreur est associé à l’événement.
• « pusher:member_added » : envoyé lorsqu’un nouveau membre s’abonne au canal. Les informations du membre sont envoyées conjointement à l’événement.
• « pusher:member_removed » : envoyé lorsqu’un utilisateur s’est désabonné du canal. Les informations du membre sont envoyées conjointement à l’événement.

Dans les évènements décrits ci-dessus, les informations associées aux membres sont celles-là mêmes que l’on renvoie dans le service d’authentification.

Dans le cadre de notre application de messagerie instantanée, nous souhaitons afficher en temps réel la liste des utilisateurs présents sur le chat. Pour être à jour dans le liste, nous devons donc écouter les évènements « pusher:subscription_succeeded », « pusher:member_added » et « pusher:member_removed ».

Côté javascript, nous ajoutons donc les bind() suivants sur ces évènements :

application.js :

presence_channel.bind('pusher:subscription_succeeded', function(members){
  members.each(function(member) {
    jQuery('#members-list').append("<div id='member_" + member.id + "'>" + member.info.email + "</div><br />");
  });
});

presence_channel.bind('pusher:member_added', function(member) {
  jQuery('#members-list').append("<div id='member_" + member.id + "'>" + member.info.email + "</div><br />");
});

presence_channel.bind('pusher:member_removed', function(member) {
  jQuery('#member_' + member.id).remove();
});

Côté html, nous créons un div d’identifiant « members-list » destiné à accueillir les e-mails des utilisateurs connectés.

Ainsi, à l’établissement de l’abonnement au canal de présence, nous récupérons la liste des utilisateurs déjà présents, et affichons leurs e-mails. D’autre part, chaque fois qu’un utilisateur s’abonne ou se désabonne, nous ajoutons ou retirons son e-mail de la liste.

Limitations

Comme on vient de le voir le service de push web proposé par Pusher permet de mettre en place la technologie WebSocket au sein de son application de façon simple, rapide, et sécurisée si nécessaire. Cependant, Pusher souffre de quelques limitations.

Tout d’abord, si le protocole WebSocket est à présent largement supporté par les navigateurs récents, ce n’est pas le cas pour tous (voir ici la liste des navigateurs supportant le protocole). De plus, même si certaines anciennes versions de browsers sont compatibles, elles désactivent par défaut le support WebSockets à cause d’une faille de sécurité (décrite ici) antérieure à l’actuelle spécification du protocole. Heureusement, Pusher, dans son infinie sagesse, a automatiquement recours à un workaround dans le cas des navigateurs incompatibles. En effet, l’API fait alors appel à une émulation de WebSocket en Flash. Ici encore, cela impose qu’un plugin Flash soit installé sur le navigateur. Si ces limitations peuvent présenter un problème sur certaines infrastructures vieillissantes, elles sont toutefois vouées à disparaître.

De même, toujours en relation avec la technologie WebSocket, celle-ci peut connaître des dysfonctionnements si la connexion passe par un proxy. En effet, celui-ci, si il est configuré dans ce sens, peut parfois interrompre la connexion établie et empêcher le bon déroulement du push.

Ensuite, comme tous les services hébergés sur le cloud, tous vos messages passeront par Pusher, avec les craintes de confidentialité que ça peut susciter. Cette inquiétude est inhérente au cloud, et rien n’empêche de chiffrer ses messages avant de les transmettre. Il existe d’ailleurs une alternative à la plateforme Pusher avec le projet open source Slanger qui implémente le même protocole et permet d’internaliser la transmissions des messages WebSockets.

Enfin, Pusher est bien entendu payant si l’on va au-delà du simple test. Il propose plusieurs programmes allant de 19$/mois pour 100 connexions concurrentes et 200 000 messages/jour jusqu’à 199$/mois pour 5000 connexions concurrentes et 10 millions de messages/jour. La version de test permet toutefois de s’amuser suffisamment puisqu’elle permet 20 connexions concurrentes et 100 000 messages/jour.

 

Suggestion d'articles :

1. Envoyez des notifications push à vos applications Android avec C2DM
2. Le push web vu par Diffusion – Partie 2
3. Le push web vu par Diffusion – Partie 1

La sérialisation est une des bases de la transmission de données entre systèmes. Certains langages proposent d’ailleurs une méthode de sérialisation en standard, qui leur est souvent propre.

L’interopérabilité entre systèmes hétérogènes nécessite que le format de sérialisation soit compréhensible par différents langages et plates-formes. De nombreux standards utilisent le mécanisme d’IDL (Interface Description Language) pour répondre à ce besoin : ASN.1, CORBA ou encore SOAP.

Depuis quelques années, de nouveaux frameworks basés sur un IDL ont vu le jour pour l’interopérabilité de technologies hétérogènes dans une optique d’économie de bande passante. Parmi eux, on trouve Thrift et Protocol Buffers. Ce premier article présente les deux frameworks sous l’angle de la sérialisation des messages et détaille leur utilisation en Java.

Historique et objectifs

Thrift et Protocol Buffers (abrégé en protobuf) ont en commun d’avoir été développés par des acteurs majeurs du Web. Thrift a été initialement développé par Facebook, et est désormais en incubation chez Apache suite à son passage en open source. Protocol Buffers a commencé comme framework interne chez Google, où son utilisation est majoritaire. L’ouverture de son code source s’est faite après une remise à plat nommée Proto2.

Afin de s’affranchir des barrières de langages, ces deux frameworks reposent sur des mécanismes classiques :

• un IDL pour décrire les structures de données,
• une génération statique du code de sérialisation dans divers langages de programmation,
• un protocole de sérialisation, c’est-à-dire une méthode de représentation des messages.

On peut par exemple générer du code permettant l’échange de messages entre Java et C++ :

Cet article se focalise en priorité sur le protocole de sérialisation, qu’il convient de distinguer du protocole de transport. Ce dernier correspond au support véhiculant le message sérialisé suivant le protocole de sérialisation.

Pourquoi de nouveaux protocoles de sérialisation ?

Protobuf se limite au protocole de sérialisation, et est donc similaire à la CDR de CORBA ou à ASN.1 associé à un encodeur : il s’agit uniquement de représenter un message sous forme sérialisée.
Thrift y ajoute des implémentations de RPC en mode client/serveur sur plusieurs protocoles de transport (HTTP, Socket, File…). Leurs fonctionnalités sont limitées par rapport à ce que propose CORBA par exemple : Thrift ne propose pas de gestion des transactions, de reprise sur erreur ou de fonctionnalités d’annuaire.

Les principes de Thrift et Protocol Buffers ne sont donc pas nouveaux. Ces deux frameworks ont néanmoins deux avantages majeurs pour les contextes de haute disponibilité et forte scalabilité, tels ceux de Google ou Facebook :

• Compatibilité ascendante/descendante : permet de faire évoluer l’interface sans nécessiter de redéploiement immédiat de toutes les applications concernées
• Taille de message et temps de sérialisation/désérialisation optimisés : permettent de minimiser les besoins de bande passante et de temps de traitement. Le champ d’utilisation peut de plus être étendu à la persistance de données.

L’argument de compacité du message est uniquement valable si on emploie le protocole de sérialisation binaire de Protobuf et le protocole compact de Thrift, car ils permettent une optimisation de la taille du message à l’octet près.
Par exemple, les deux sérialisent une chaîne de caractères en la faisant précéder par sa longueur, à l’instar de CDR. Mais ils codent cette longueur avec un varint, qui est plus compact que l’entier sur 32 bits employé par CDR.

IDL et interfaces

Thrift et Protobuf se ressemblent énormément en pratique. L’IDL du premier s’appelle Thrift IDL, celui du second se nomme simplement protocol buffer language. Les deux frameworks supportent la plupart des types de données courants, le détail est disponible ici pour Thrift et là pour Protobuf.

L’exemple considéré est l’objet Node dont une version en Java est la suivante :

package com.octo.example.serialization.model;

public class Node implements Serializable {
    private Integer mNumber;
    private boolean mEven;
    private Double mRate;
    private RoomType mType;
    private String mDescription;
[...]
}

Il contient quelques membres de types différents, dont une énumération ; les accesseurs ont été omis par concision.

Voici le descripteur équivalent en Thrift IDL : tree.thrift

namespace java com.octo.example.serialization.model.thrift
enum RoomType {
        SINGLE =0,
        DOUBLE =1,
        SUITE =2
}
struct Node {
    1: optional i32 number,
    2: optional bool even,
    3: optional double rate,
    4: optional RoomType type = RoomType.SINGLE,
    5: optional string description
}

La première ligne permet de spécifier le package Java auquel appartiendra le code généré par le compilateur Thrift. L’énumération RoomType associe une constante numérique à chaque valeur possible. Puis notre objet Node lui-même est défini.
En Thrift IDL, chaque champ est défini par

• un identifiant unique
• suivi de l’indication s’il est optionnel ou non (optional/mandatory),
• puis son type,
• son nom
• et une valeur par défaut précédée du signe = si nécessaire.

Le message est donc sérialisé sous forme clef-valeur, avec l’identifiant unique comme clef. La valeur contient le type puis la valeur elle-même. Voici à fins d’illustration ce que donne la struct Node sérialisée avec le protocole de sérialisation TJSONProtocol de Thrift :

{
  "1":{
    "i32":0
  },
  "2":{
    "tf":1
  },
  "3":{
    "dbl":0.0
  },
  "4":{
    "i32":0
  },
  "5":{
    "str":"Lorem ipsum dolor sit amet, cons"
  }
}

Voici le pendant en Protocol Buffers language : tree.proto

package serialization;
option java_package = "com.octo.example.serialization.model";
option java_outer_classname = "TreeProto";
enum RoomType {
    SINGLE =0;
    DOUBLE =1;
    SUITE =2;
}
message Node {
    optional int32 number =1;
    optional bool even =2;
    optional double rate =3;
    optional RoomType type =4 [default = SINGLE];
    optional string description = 5;
}

La première ligne correspond au package protobuf, ce qui permet d’éviter les conflits lors d’imports de fichiers .proto externes par exemple. Les deux lignes suivantes sont des options propres à la génération de code Java ; il s’agit du nom de package et du nom de la classe générée par protoc.
La déclaration d’un champ se fait de manière similaire à celle de Thrift :

• l’indication si le champs est optionnel (optional) ou non (required),
• puis son type,
• son nom,
• son identifiant unique précédé du signe =
• suivi d’une valeur par défaut si nécessaire.

La sérialisation suit le même principe que celle de Thrift : le message est sérialisé en clef-valeur avec l’identifiant unique comme clef. Le détail de l’encodage binaire est fourni ici.

Versioning et évolution de l’interface

La compatibilité ascendante/descendante des messages nécessite de respecter certaines règles afin d’être garantie. Ces dernières sont similaires pour les deux frameworks.
La pierre angulaire de la compatibilité est l’identifiant unique associé aux champs. La principale règle de désérialisation est que tout champ d’identifiant inconnu est ignoré. Il reste néanmoins conservé dans le message car il peut être utile à d’autres versions de l’interface.

Les règles à respecter lors de l’évolution des interface sont les suivantes

• les identifiants de champs doivent être invariants
• tout champ ajouté dans une nouvelle version doit être optionnel, sous peine de ne plus pouvoir lire les messages issus d’anciennes versions
• les valeurs par défaut ne doivent en général pas être modifiées. En effet, elles ne sont pas transmises dans le message sérialisé, mais assignées par le code de désérialisation
• tout champ obligatoire doit être présent dans toutes les versions de l’interface, passées ou futures.

A ces règles protobuf ajoute

• des compatiblités entre types, par exemple entre uint32 et bool,
• un mécanisme d’extension afin de réserver des plages d’identifiants pour une utilisation future, pour de l’héritage par exemple.

Génération du code

L’étape suivante consiste à générer le code correspondant aux objets et interfaces définies ci-dessus. Le compilateur Thrift est utilisé de la manière suivante :

thrift -v --gen java -o . tree.thrift

Le code généré est placé dans un sous-répertoire gen-java, avec autant de fichiers-classes que de structs et énumérations :

gen-java
└── com
    └── octo
        └── example
            └── serialization
                └── model
                    └── thrift
                        ├── Node.java
                        └── RoomType.java

Pour Protobuf, le principe reste le même, même si la ligne de commande change un peu :

protoc -I=project/root/ --java-out=. tree.proto

Dans ce cas un unique fichier est généré, contenant l’ensemble des messages sous forme de classes internes

java
└── com
    └── octo
        └── example
            └── serialization
                └── model
                    └── TreeProto.java

Cas particulier : déclaration avancée et récursion

Le but initial de l’exemple était de sérialiser un arbre constitué de nœuds. Or Thrift ne supporte pas la déclaration avancée, donc les structures récursives. Cette limitation est explicite dans le white paper de Thrift :

Due to inherent complexities and potential for circular dependencies, we explicitly disallow forward declaration. Two Thrift structs cannot each contain an instance of the other.

Par exemple, le compilateur Thrift bloque sur deux erreurs lors du parsing de la struct suivante :

namespace java com.octo.example.serialization.model.thrift
struct InvalidNode {
    1: optional i32 number,
    2: optional bool even,
    3: optional double rate,
    4: optional RoomType type = RoomType.SINGLE,
    5: optional string description,
    6: list<InvalidNode> children
}
enum RoomType {
        SINGLE =0,
        DOUBLE =1,
        SUITE =2
}

La première est à la ligne 6 : Type « RoomType » has not been defined, et la seconde à la ligne 8 : Type « Node » has not been defined.

Protobuf n’a pas cette limitation et compile donc sans erreur un .proto équivalent. La classe chargée de la sérialisation, CodedInputStream propose une sécurité sur le niveau de récursion. La limite par défaut est de 64, et peut être modifiée via la méthode setRecursionLimit.

Conversion modèle applicatif – objets sérialisables

Si l’applicatif utilise déjà un modèle d’objets existants, des méthodes de conversion entre ce modèle et les objets sérialisables doivent être développées. Ni Thrift ni protobuf ne proposent de moyen d’automatiser ou de générer ce code de conversion. Afin d’éviter ce surcoût, il est préférable de manipuler directement les objets sérialisables générés à l’étape précédente quand cela est possible.

Dans l’exemple, l’objet de départ Node est un simple POJO, la conversion a donc été codée manuellement dans des classes dédiées à la sérialisation. Les objets générés par Thrift exposent des accesseurs pour chacun des champs :

package com.octo.example.serialization.serializers.tree;

public class ThriftTreeSerializer {
[...]
    public com.octo.example.serialization.model.thrift.Node convertToSerializable(Node pNode) {
        com.octo.example.serialization.model.thrift.Node vNode = new com.octo.example.serialization.model.thrift.Node();
        vNode.setNumber(pNode.getNumber());
        vNode.setRate(pNode.getRate());
        vNode.setType(RoomType.valueOf(pNode.getType().toString()));
        vNode.setDescription(pNode.getDescription());
        vNode.setEven(pNode.isEven());
        for (Node vChild : pNode.getChildren()) {
            vNode.addToChildren(convertToNode1(vChild));
        }
        return vNode;
    }
}

Protobuf utilise des messages immuables et le pattern builder :

package com.octo.example.serialization.serializers.tree;

public class ProtoBufTreeSerializer {
[...]
    public com.octo.example.serialization.model.LimitedTreeProto.Node convertToSerializable(Node pNode) {
        com.octo.example.serialization.model.LimitedTreeProto.Node.Builder vBuilder = com.octo.example.serialization.model.LimitedTreeProto.Node.newBuilder()
        .setNumber(pNode.getNumber())
        .setRate(pNode.getRate())
        .setType(LimitedTreeProto.RoomType.valueOf(pNode.getType().toString()))
        .setDescription(pNode.getDescription())
        .setEven(pNode.isEven());
        for (Node vNode : pNode.getChildren()) {
            vBuilder.addChildren(convertToNode1(vNode));
        }
        return vBuilder.build();
    }
}

Une autre méthode consiste à faire implémenter l’interface Externalizable aux objets du modèle applicatif. Cela permet d’utiliser l’un des deux frameworks tout en maintenant la compatibilité avec les API de sérialisation Java standards. Cependant, l’utilisation du protocole de sérialisation de Java augmente la taille du message, notamment à cause la présence des noms de classes complets.
Sur un court message, le surcoût est rédhibitoire. À titre d’exemple, le même Node pèse 49 octets s’il est sérialisé par protobuf directement, et 118 octets si on utilise protobuf via Externalizable.writeExternal.

Sérialisation en pratique

Thrift propose plusieurs protocoles de sérialisation à choisir parmi les implémentations de TProtocol fournies, dont deux binaires :

• TBinaryProtocol : code chaque champ est sous la forme longeur puis valeur binaire,
• TCompactProtocol : produit un message plus compact grâce à des optimisations, dont l’utilisation systématique de varints.

Ce dernier est préférable et globalement équivalent à celui de protobuf. Voici un exemple de classe de sérialisation avec Thrift

package com.octo.example.serialization.serializers.tree;
import com.octo.example.serialization.model.thrift.Node;
[...]
public class ThriftTreeSerializer {
    public byte[] serialize(Node Object) throws Exception {
        TSerializer serializer = new TSerializer(new TCompactProtocol.Factory());
        return serializer.serialize(Object);
    }
    public Node deserialize(byte[] pMessage) throws Exception {
        TDeserializer deserializer = new TDeserializer(new TCompactProtocol.Factory());
        Node vRoot = new Node();
        deserializer.deserialize(vRoot, pMessage);
        return vRoot;
    }
[...]
}

Protobuf lui ne propose nativement qu’un protocole binaire. Des extensions permettent le support d’autres protocoles de sérialisation, par exemple protobuf-java-format qui sérialise en JSON, XML ou HTML.
La classe de sérialisation équivalente en protobuf :

package com.octo.example.serialization.serializers.tree;
import com.octo.example.serialization.model.LimitedTreeProto.Node;
[...]
public class ProtoBufTreeSerializer {
    public byte[] serialize(Node object) throws Exception {
        return object.toByteArray();
    }
    public Node deserialize(byte[] message) throws Exception {
        CodedInputStream vStream = CodedInputStream.newInstance(message);
        return Node.parseFrom(vStream);
    }
[...]
}

Conclusion

Thrift et Protocol Buffers sont deux frameworks qui n’innovent pas sur le principe. Les deux frameworks sont relativement similaires et répondent surtout aux besoins des sociétés qui les ont créées, Facebook et Google. Elles ont revisité les mécanismes classiques d’interopérabilité via un IDL, en mettant l’accent sur les performances et la compatibilité ascendante et descendante, deux caractéristiques cruciales dans leur contexte. Ces frameworks proposent principalement de la sérialisation, avec en sus une implémentation RPC simple pour Thrift.

Du fait de la génération statique de code et de la nécessité potentielle de développer des méthodes de conversion, leur utilisation peut s’avérer coûteuse à mettre en œuvre. Comme beaucoup d’outils spécialisés, il vaut donc mieux avoir un besoin avéré de leurs avantages et bien évaluer leurs limitations avant d’envisager leur utilisation.

D’autres frameworks de sérialisation utilisent des principes différents de ceux de Thrift et Protocol Buffers. Apache Avro notamment, qui repose sur la présence systématique de l’interface dans le format sérialisé. Cela lui permet de rendre la génération de code optionnelle et de se passer d’identifiants uniques de champs.

Thrift et Protocol Buffers obtiennent des performances équivalentes dans un benchmark regroupant plusieurs sérialiseurs Java. Ce benchmark se limite toutefois à l’utilisation d’un unique message. Dans un prochain article, les deux frameworks seront comparés en termes de compacité de la sérialisation avec une structure de message variable.

Références

Les versions utilisées pour cet article sont la 0.8.0 pour Thrift et la 2.4.1 pour Protocol Buffers. Les liens suivants sont en anglais.

• Documentation officielle de Protocol Buffers : complète et didactique.
• Thrift : the missing guide, plus clair et détaillé que le très léger Wiki officiel de Thrift.
• Thrift white paper
• Java serializers benchmark : comparaison souvent remise à jour des performances d’un grand nombre de couples sérialiseurs/protocoles.
• Thrift vs Protocol Buffers : comparaison des deux projets d’un point de vue global (documentation, qualité de code, fonctionnalités, performances…)

Suggestion d'articles :

1. Thrift et Protocol Buffers : compacité du message sérialisé dans le monde Java
2. Des principes (ou quelques idées…) REST et du Mashup

OCTO organise le jeudi 26 janvier 2012 à partir de 8h45 un petit-déjeuner gratuit, à Eurosites George V  « Tablettes : passons à l’ère du post-PC ».

Avec la participation de BNP Paribas Fortis, ARVAL et AXA.

Pour vous inscrire cliquez ici . Découvrez le descriptif de l’évènement et les intervenants dans ce billet.

En moins de 2 ans les tablettes se sont imposées partout. Elles ont cannibalisé le marché du PC et tué celui du netbook !
Internet, mails, réseaux sociaux, actualités ou jeux. Ceux qui ont essayée la tablette l’ont adoptée.

Rapidité, légèreté, simplicité, autonomie et prix sont au coeur de ce succès.

Vos entreprises ont l’opportunité d’épouser cette révolution et de faire évoluer leurs métiers, services et applications en tirant pleinement partie des tablettes. Les exemples ne manquent pas : outils d’aide à la vente, applications RH, bureau mobile, contrôle qualité in situ, documentation ou encore formation.

Et vous, quels usages faites ou ferez-vous des tablettes ?

OCTO Technology vous propose d’échanger, avec ses clients, autour des enjeux que représentent les tablettes en entreprise :

- Quelles applications métiers sur tablette ?
- Comment dégager du ROI ?
- Quelles sont les différences avec un développement smartphone ?
- Pouvez-vous faire confiance à une tablette comme outil de travail ?
- Comment sécuriser les applications et les données de votre entreprise ?

Rejoignez la révolution le 26 Janvier 2012 au Georges V de 9h à 11h

A l’issue de ce petit-déjeuner vous aurez découvert :

• Les initiatives actuelles et à venir dans les grandes entreprises
• Les usages innovants dans les différents départements (RH, commercial, opérationnel)
• Les enjeux d’ergonomie et d’intégration dans le SI
• Des retours d’expérience concrets et significatifs expliqués par leurs responsables

Ce petit-déjeuner sera présenté par :

Intervenants keynote :
- Jean-François Grang – OCTO Technology
- Olivier Martin – OCTO Technology

Intervenants table ronde :

- Antoine De Kerviler – Corsairfly – DSI
- Yvan Pirenne – BNP Paribas Fortis – Manager Internet & Mobile Banking
- Sebastien Somchit – ARVAL – Head of Interactive Marketing
- Guillaume Lemêle – AXA France Services – Directeur Conseil & Services Distribution Internet & Marketing
- Eric Biernat (animateur) – OCTO Technology

 

Ce petit-déjeuner est à destination de nos clients et prospects en priorité.

Cliquez ici pour vous inscrire au petit-déjeuner : Tablettes

Suggestion d'articles :

1. OCTO organise un petit-déjeuner Gestion des Identités le 27 janvier – Témoignage d’Air Liquide
2. Vidéo du petit-déjeuner « Comment bâtir votre Cloud ? » organisé par OCTO Technology
3. Vidéo du petit-déjeuner « MapReduce -La révolution dans l’analyse des BigData » organisé par OCTO

Chers lecteurs, tous les OCTOs vous souhaitent une belle et heureuse année 2012 ! Nous espérons qu’elle sera remplie de  projets ambitieux, d’échanges, de bonheur et de réussite !

Et surtout merci de nous faire part de vos avis, vos envies et vos remarques. C’est grâce à vous  que nous prenons toujours plaisir à alimenter le blog  d’articles , de prises de position et des sujets de « geeks » et de « boss » qui nous passionnent.

Une occasion pour nous de vous faire partager la carte de voeux OCTO édition 2012 ! Oui, en 2012 nous changerons notre logo. Nouvelle année, nouveau logo mais toujours OCTO ! 

 

 

Suggestion d'articles :

1. Appel à candidature : proposez votre session à USI 2012 !
2. OCTO Technology accompagne Corsairfly, filiale du groupe TUI TRAVEL, dans l’évolution de son système d’information à horizon 2012
3. Ouverture des inscriptions USI 2012

Jeudi 15 décembre, OCTO organisait un petit-déjeuner NoSQL : « l’Extreme Transaction Processing, devient une réalité ».

Aujourd’hui, la multiplication des systèmes connectés à Internet (smartphone, tablette, TV connectée, véhicule connecté) et l’émergence des nouveaux flux de données issus notamment du web social (Facebook commerce, mobile-to-mobile, etc) vont pousser un peu plus les Systèmes d’Information vers l’Extreme Transaction Processing (XTP).

(Pour plus d’informations sur le contenu, veuillez cliquer ici)

Grâce à la vidéo de l’évènement disponible sur You Tube, vous pouvez découvrir les divers points abordés lors de ce Petit-Déjeuner, à savoir :

• les concepts et les opportunités métiers autour de l’ »Extreme Transaction Processing« 
• les enjeux d’architecture et d’exploitation
• les fonctionnalités et l’implémentation faite par les solutions VMware Gemfire et SQLFire

Pour tout autre renseignement, contactez nous sur : contact@octo.com

  Cliquez sur l’image pour lancer la vidéo  

Suggestion d'articles :

1. Petit-déjeuner NoSQL : « l’Extreme Transaction Processing » devient une réalité
2. Vidéo du petit-déjeuner « Comment bâtir votre Cloud ? » organisé par OCTO Technology
3. Vidéo du petit-déjeuner « MapReduce -La révolution dans l’analyse des BigData » organisé par OCTO

OCTO organise le  jeudi 12 janvier 2012 à partir de 8h45 un petit-déjeuner gratuit Big Data & CEP : « L’analyse décisionnelle en temps réel : Convergence entre Big Data et Complex Event Processing », à Eurosites George V.

Pour vous inscrire cliquez ici . Découvrez le descriptif de l’évènement et les intervenants dans ce billet.

Le pilotage des activités opérationnelles devrait pouvoir se faire au rythme du business et avec une connaissance précise de son état courant.

La lutte contre la fraude, l’analyse des parcours clients en temps réel ou le suivi des liquidités permettent d’améliorer vos profits et demandent une analyse complexe instantanée sur d’importants volumes d’évènements.

Ces nouveaux usages en matière d’analyse des flux de données introduisent de nouveaux défis techniques et d’architecture des SI : comment faire converger analyse temps réel et gestion de volume de données important ?

Les évolutions des marchés du Décisionnel et du CEP permettent d’y apporter aujourd’hui des réponses concrètes. Des solutions sont déjà opérationnelles dans différents secteurs : finance, telecoms, logistique, e-commerce, …

OCTO Technology et Quartet FS  vous proposent de découvrir les nouvelles opportunités métiers liées à ces évolutions technologiques, positionner ces nouvelles architectures dans vos SI et les possibilités de ActivePivot Sentinel.

A l’issue de ce séminaire, vous aurez découvert :

• Les enjeux d’architecture de l’analyse de données en temps réel
• Le nouveau panorama des solutions capables d’y répondre
• Les fonctionnalités du produit ActivePivot Sentinel

Ce petit-déjeuner sera présenté par :

Julien CABOT, OCTO, Associé
Olivier MALLASSI, OCTO, Architecte Senior
Romain COLLE, Quartet Financial Systems, Senior R&D Engineer

Cliquez ici pour vous inscrire au petit-déjeuner : Big Data & CEP

Suggestion d'articles :

1. Complex Event Processing
2. Complex Event Processing (CEP), de quoi s’agit-il?
3. Complex Event Processing avec Esper

L’année dernière USI vous a proposé plus de 40 sessions. Mais le programme USI ne se fait pas sans vous, alors si vous avez une idée de session n’hésitez pas à nous la soumettre et/ou venez voter pour vos sessions favorites !

Proposez votre session !

Leader d’opinion, porte-parole de sujets IT, super geek, manager ou partie prenante de la DSI… le formulaire pour proposer votre session est en ligne et ce jusqu’au 31/01/2012. Profitez-en !

L’équipe USI déterminera, après étude de votre proposition, la durée de votre session, qui sera de 40 ou de 20 minutes. Pour rappel, le premier critère de sélection de l’équipe USI sera la qualité du résumé de session proposé (fond et forme). Merci donc d’en tenir compte lors du remplissage de ce formulaire.

L’équipe programme étudiera toutes les propositions et sélectionnera les sessions qui lui paraîtront les plus intéressantes. Vous serez peut-être invité à venir présenter votre session lors d’une journée dédiée : mi février et nous informerons de notre décision finale fin mars 2012.

500 personnes, opérationnels ou managers dans la DSI ou les directions métiers, sont attendus pour cette nouvelle édition. Une belle audience donc  pour votre présentation et rencontrer vos pairs ! N’hésitez plus !

Cliquez ici pour soumettre votre session à l’USI

Votez pour vos sessions préférées

Nous vous invitons à venir consulter toutes les sessions qui seront proposées cette année et de votre celles que vous préférez et que vous aimeriez voir à USI 2012.

Ou parlez-en tout simplement…

Même si vous ne proposez pas de session vous avez peut-être dans votre entourage une personne qui le peut et que vous jugez pertinente.  Alors  n’hésitez pas ! Et partagez l’info !

A vos candidatures donc et merci !

L’équipe USI

Suggestion d'articles :

1. Ouverture des inscriptions USI 2012
2. Session OCTO aux TechDays 2011
3. Code et diapos de la session Spring et TDD du ParisJUG

Les connections réseaux sont une source fréquente de lenteur des applications mobiles. Remplacer 10 téléchargements de 1Mo par 1 de 10Mo peut améliorer le fonctionnement de votre application.

L’utilitaire unix Tar permet justement de regrouper des fichiers en un seul package. Malheureusement aucune implémentation sous iOS de tar n’est satisfaisante : trop lourde et surdimensionnée par rapport aux besoins d’une simple application.

Pourtant une librairie qui décompresserait simplement des fichier tar n’est pas trop compliquée à développer.

La suite en anglais: http://blog.octo.com/en/untar-on-ios-the-pragmatic-way/

Suggestion d'articles :

1. Une approche de la qualité logicielle…
2. 5 minutes pour : Monter en complexité, Approche TDD / Tests en PHP, PHP & Ajax
3. Libérez la touche F1 sous Internet Explorer