• 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 »

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é

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…

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

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 ? »

• 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 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

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