Duchess France
A Duchess Community Blog for France

Devoxx est une conférence européenne indépendante qui porte sur les technologies Java/JVM . Organisée en Belgique, à Anvers, elle nous permettra d’entendre du 15 au 19 novembre 2010 des speakers de haut niveau. Un peu moins de 3000 développeurs venant de plus de 40 pays différents s’y retrouvent chaque année.

Les conférences

Les University Days.

Les 2 premiers jours sont appelés les University Days. On y retrouve principalement des ‘University Talks’, des conférences de 3 heures qui abordent un sujet en profondeur. Il y a à chaque fois plusieurs conférences sur un même créneau horaire. Les sujets sont variés, la plupart sont techniques. Ainsi, on retrouve des sujets :

• sur le langage comme Java EE6 par Antonio Goncalves et Alexis Moussine-Pouchkine ou What’s new in Hibernate – a JPA 2 perspective par Emmanuel Bernard
• autour de tout ce qui est Desktop/Mobile comme Dive into Android de Romain Guy
• sur d’autres langages tournant sur la JVM (Groovy,Scala) comme Groovy/Gaelyk/GAE de Guillaume Laforge
• sur le Cloud/NoSQL
• également des sujets sur la méthodologie (Productive Programmer).

Chacun peut participer à 2 sessions de 3 heures par jour, une le matin et l’autre en début d’après midi. Ensuite, place aux ‘Tools in action’. Ce sont des petites sessions de 30 minutes qui permettent aux speakers de nous faire découvrir un outil auquel ils ont participé. Les sujets sont variés, d’une présentation de spring developer tools (que j’apprécie énormément au quotidien), à visual VM (outil de monitoring) en passant par Apache Mahout.
Entre 19 et 22h, ont lieu des BOF (Bird-of-a-Feather) qui diffèrent beaucoup de tous les autres types de conférences.
Elles réunissent peu de personnes et sont beaucoup plus informelles. Elles sont généralement menées par un ou deux speakers de manière libre. Parfois, il y a une brève présentation puis des questions, parfois ce sont des discussions ouvertes sur un sujet précis. Actuellement, le planning n’est pas finalisé sur les BOFs.

Les Conference Days

Pour les 3 jours suivants, du mercredi au vendredi, le format diffère. Les conférences  ne sont plus de 3 heures mais d’une heure : cela permet de voir bien plus de sujets différents mais de manière un peu plus superficielle. Les sujets là encore tournent autour des mêmes thèmes dans 5 salles différentes. Les sessions ‘Tools in action’ disparaissent au profit des Quickies, qui durent 15 minutes pendant la pause déjeuner.

Duchess à Devoxx

Les duchess seront présentes toute la semaine à Devoxx et plusieurs nationalités seront présentes (France, Belgique, Hollande …). Le jeudi soir, les Duchess organiseront une BoF pour discuter en petits groupes (6) autour de sujets choisis sur le thème ‘Les femmes dans l’informatique‘.

Ce que j’aime à Devoxx

Pour un prix raisonnable, Devoxx apparait comme un des principaux rendez-vous européen. Les speakers y sont accessibles et l’organisation bien rodée. En une semaine, cela permet d’améliorer fortement sa ‘culture générale Java’, surtout si l’on est débutant. Anvers n’est qu’à deux heures de Paris en Thalys, les hôtels y sont à un prix abordable. Bref, pour un investissement moyen, cela permet vraiment de progresser au niveau technique et de rencontrer énormément de monde, ce qui est toujours un avantage. Certaines SSII l’ont bien compris et y envoient chaque année plusieurs consultants.  Ceux qui n’ont pas une entreprise pour les y envoyer peuvent tout à fait se le permettre au niveau financier. Les conférences sont bien sûr des endroits où l’on apprend beaucoup, mais toutes les discussions ‘off’ pendant la pause déjeuner ou autour d’une bière le soir permettent d’avoir des retours d’expérience très intéressants.

Infos Pratiques

Au niveau de la gestion à proprement parler, pour ceux qui assiste aux University Days, deux possibilités : soit dormir sur place le dimanche soir, soit il est tout à fait possible de prendre l’un des premiers Thalys, de passer à l’hôtel si celui ci est proche de la gare et en ne perdant pas de temps de prendre le tramway pour assister aux premières sessions.
Pour les hôtels, les français semblent se regrouper cette année à deux endroits différents : l’Agora (qui devient à partir d’octobre le ‘all seasons Antwerpen City Center’) et le Park Inn qui sont tous les deux placés juste à côté de la gare. Il vaut mieux éviter de prendre les hôtels qui semblent plus proche de la salle pour deux raisons : ils sont mal desservis en transport en commun et cela veut dire également que vous ferez le chemin seul le soir et le matin.
L’année dernière, le petit déjeuner était compris dans la conférence, tout comme le repas du midi.
Au niveau du train du retour pour le vendredi, beaucoup prennent les thalys de 14h30 ou de 15h30, et certains y restent le week end pour découvrir la Belgique !

Cet article a été rédigé par Katia Aresti, relecture et corrections par Claude Falguière

Après l’introduction NoSQL une petite pause et la rencontre avec les habitués du JUG, des discussions intéressantes, questions et réponses non formulées et un joli buffet. Après cette demi-heure, on est monté pour la deuxième partie de la conférence : le retour d’expérience de Steven Noels dans l’utilisation de NoSQL pour l’implémentation d’un CMS (Content Management System).

ALM : Annonce d’un nouveau User Group Parisien

Lucian Precup - Photo : Claude Falguière

Lucian Precup nous a présenté le groupe “ALM France” – Application Lifecycle Management. La soirée d’ouverture aura lieu le 30 septembre prochain à 18h30.
ALM a pour objectif de promouvoir la gestion du cycle de vie des applications et les outils associés. Cette discipline recouvre de nombreux aspects comme la conception, la gestion des exigences, l’architecture, la gouvernance des processus, la gestion de projet, les outils, l’assurance qualité, la gestion des configurations, le déploiement, l’exploitation et la prise en compte de l’expérience utilisateur.

ALM privilégiera le partage d’expériences concrètes sur tous ces domaines, afin de permettre à chacun de bénéficier des meilleures pratiques du terrain.
Pour en savoir plus : http://blog.alm-france.org/

Après ce moment publicitaire, la conférence de Steven Noel a commencé.

CMS on top of NoSQL

Steven Noels

Steven Noels - Photo : Claude Falguière

Steven Noels est le co-fondateur de Outerthought. Ils développent des applications scalables de management de contenu et publishing avec les technologies Java, REST et maintenant aussi NoSQL.

Steven est un speaker renommé sur les thèmes du management de contenu, NoSQL et l’Open Source en général. Outerthought offre un catalogue de produits développés en open source basés sur les solutions open source existantes :
- Daisy, content-and knowledge management : http://ww.daisycms.org

- Lily, scalable store and research :  http://www.lilycms.org

- Kauri, REST centric internet application developement : http://www.kauriproject.org

Il a été invité au Paris JUG pour partager un retour d’expérience avec NoSQL : le développement du produit Lily, un dépôt de contenu sur Apache HBase.

CMS (Content Management System) : Daisy

Daisy est un petit système de management de contenus (similaire à Alfresco). L’image ci-dessous illustre l’architecture technique classique d’un CMS :

Architecture type d'un CMS

Pourquoi autant de cache ?

Principalement pour éviter d’aller en base. La lecture et l’écriture vers la base de données relationnelle est coûteuse.

Avec Daisy, Steven Noels et son équipe sont arrivés aux limites de la scalabilité :

• Capable de bien ingérer des documents de 100 Ko, mais atteint ses limites avec des Mo
• Problèmes avec les caches : l’empilement de caches ayant des durées différentes est complexe à gérer.

Et derrière cette problématique de scalabilité :

• L’existence de trois sources de données : MySQL, Lucene (moteur de recherche de texte) et le système de fichiers
• Le mélange des résultats de la recherche sur les trois sources de données est réalisé dans le code de l’application et en mémoire
• Les transactions et les opérations “set” sont ainsi très difficiles

Finalement Lucene ne permet pas de gérer la fonction “failover”. Ils ont trouvé des solutions pour réaliser du master/slave mais ce n’était pas très satisfaisant.

L’équipe a donc commencé à réfléchir à leur nouveau besoin :

• Ajouter des stockages de données et de scaler dynamiquement
• Avoir une véritable architecture de données distribuée

Solution 1 : Déléguer encore plus sur la base de données relationnelle

La première solution à laquelle ils ont réfléchi passait par l’utilisation d’encore plus de base de données relationnelles. Ainsi, les caractéristiques de l’architecture cible imaginée peut se résumer à la liste suivante :

• Ajouter plus de bases MySQL, et avec encore plus de maîtrise de MySQL pour gérer la réplication.
• Encore plus de bases de données autour, avec des systèmes master/slave
• ESB (Enterprise Service Bus) pour communiquer et synchroniser les instances
• RMI et JMS sur JDBC
• RAC sur Oracle pour gérer la distribution (“Real Application Clusters”)
• ouch !!

Le design était une usine à gaz. Non seulement l’architecture devenait ultra complexe, mais générait également des arbitrages financiers : les licences d’oracle, par exemple, sont vendues par CPU. La quantité d’argent à payer pour avoir N bases de données est extrêmement élevée.

Définitivement, aller vers cette solution c’était partir vers une catastrophe en terme de satisfaction d’utilisateur par rapport au budget.

Heureusement, l’explosion de NoSQL est arrivée à ce moment précis !

Solution 2 : NoSQL

La persistance polyglotte, “la tour de babel”.  Apparemment une nouvelle technologie émergente couvrait les besoins auxquels on a fait référence : scalabilité dynamique, performance avec des gros volumes de données et l’architecture distribuée.

L’offre étant assez riche – Cassandra, MongoDB, CouchDB, Redis, Riak, HBase… – quelle solution choisir ?

Clé/Valeur ?  Document ?  Colonne ?  Graphe ?

Lorsqu’on est confronté à un défi tel que celui là, le plus important est de faire les bons choix pour le problème précis. Aujourd’hui on dispose de beaucoup de choix mais toutes les bases ne sont pas adaptées à tous les usages. Certaines ne scalent pas, certaines nécessitent des compétences dans des langages peu répandus (Erlang) etc. Il faut faire aussi attention au marketing (qui finance la solution ? est-elle vraiment NoSQL ?).

L’équipe a donc décrit une série de pré-requis initiaux qu’on résume ci-dessous :

• Scalabilité automatique de gros volumes de données
• Tolérance aux erreurs : réplication et récupération automatique des instances en erreur
• Un modèle de données flexible
• Efficacité dans l’accès aléatoire aux données
• Open Source : l’équipe pourra s’investir dans le développement de la base NoSQL et d’y intégrer plus facilement des fonctionnalités inexistantes dont le nouveau CMS aurait besoin
• Préférence pour le langage java

Après cette première réflexion, ils ont constaté qu’en plus des pré-requis déjà cités, les points suivants étaient aussi très importants :

• Cohérence : surtout pas se retrouver avec deux versions du document en conflit sur une même ligne de donnée
• Atomicité : transactions unitaires par ligne de donnée
• Si possible, intégration avec Map/Reduce : ce que facilite, par exemple, la gestion des index dans la recherche full-text

Pourquoi “Apache HBase” ?

HBase suit un modèle de données Column, très flexible, avec lequel on peut garder toutes les versions d’un document. La solution offre la possibilité de ranger les données permettant la création d’index scalables, ainsi qu’un espace HDFS pour stocker les blobs. De plus, elle s’appuie sur l’implémentation Open Source de Google : BigTable. Entre autres caractéristiques techniques, HBase offre l’intégration avec Hadoop MapReduce et des API’s Java, REST, Thrift, Ruby Shell, Java M/R.

Enfin Steven a ajouté aussi que l’équipe se sentait à l’aise avec l’utilisation de la licence Apache et avec la communauté déjà très familière pour eux.

Contenu est synonyme de recherche

Grâce à HBase, ils ont trouvé le dépôt de données qu’ils recherchaient. Or, contenu est aussi synonyme de recherche ! Ils utilisaient le produit Lucene, mais le cadre avait complétement changé car la recherche devait tenir compte de la scalabilité dynamique.

Un CMS se compose de deux types de recherche :

• Structurée, ou recherche logique (basée sur des types string, nombres, logique)
• Récupération de données (full-text search) reposant sur de la numération

En partant de l’idée des Index Datastore de  Google App Engine l’équipe a développé la librairie HBase Indexing Library, et pour implémenter la méthode de recherche dont ils avaient besoin, ils se sont fait aider par le framework SOLR qui appartient aussi au projet Lucene.

La dernière étape était de pouvoir mettre à jour les index de données de HBase pour bien les connecter avec la recherche SOLR. Il fallait impérativement une méthode fiable de copie dans un environnement distribué.  Finalement WAL/Queue a été choisi comme solution pour  l’ensemble de garanties qu’il fournit dans la synchronisation de données.

Le résultat final est Lily :

• Modèle de données flexible
• HBase comme base de données NoSQL
• Indexé. Recherche avec SOLR
• Utilisation du mécanisme WAL/Queue implémenté en HBase
• Basé sur leur produit Kauri à l’exécution
• Communication Client/Serveur via Avro (et une interface REST interfacée avec JSON)

Steven a conclu en disant qu’ils ont réussi quelque chose qui leur plaît beaucoup et qu’ils sont très satisfaits des résultats.

Vous pouvez télécharger le guide d’apprentissage (architecture, modelé, API, Javadoc) – www.lilycms.org.  La release complète de Lily sera aussi distribuée fin octobre 2010.

Conclusion

Si votre architecture de données est correcte avec un seul CPU et une seule RAM, vous n’avez pas (encore) besoin de NoSQL. NoSQL sert principalement à couvrir le besoin d’une architecture distribuée et de haute disponibilité.

Mais si vous constatez que NoSQL est la solution à vos problématiques de distribution, scalabilité et performance sur des gros volumes de données, vous devrez donc faire le bon choix. Il faut surtout éviter de succomber aux sirènes du marketing, ou de faire un choix basé sur le “buzz”. Steven Noels et son équipe ont choisi HBase juste 2 mois avant le hype de Cassandra, mais si au départ Cassandra est plus simple, HBase est plus configurable.

Utiliser une base NoSQL implique de mettre les mains dans le code pour constater que la base fait vraiment ce qu’on dit qu’elle fait. Le choix est un risque ! Rappelez-vous que le choix le moins amusant peut être aussi le meilleur.

Pour en savoir plus :

Devoxx !

Vous y retrouverez des speakers comme Tom White (Cloudera/Hadoop O’Reilly author), Jonathan Ellis (Cassandra), Michael Stack (HBase), des conférences dédiés aux produits comme MongoDB, Voldemort et Elastic Search et cas d’applications pratiques sur Twitter, Facebook et Adobe

Troisième mi-temps

3ème mi temps

De retour au Vavin, la fin de la soirée agréable et amusante comme toujours. Des conversations intéressants et retrouver encore quelques têtes.

Quelques personnes, comme d’habitude ont encore continué vers la quatrième mi-temps !

Et voilà, c’est tout !

Rendez-vous au prochain Paris JUG !!!

Article précédent : Introduction NoSQL

Cet article a été co-rédigé par Claude Falguière et Katia Aresti

Mardi 14 Septembre 2010, Paris. L’ambiance de la rentrée se respire partout. Le retour à la normalité Parisienne. Et avec cette normalité…  le retour du Paris JUG ! Et avec le Paris JUG, n’oublions pas notre Avant JUG au café Vavin.

L’Avant JUG

L’avant JUG a été très sympa comme toujours. Quelques nouvelles têtes qui viennent pour la première fois au Paris JUG, et quelques garçons qui viennent découvrir finalement ce qu’est l’avant JUG : la possibilité de parler de façon décontractée  autour d’un verre du sujet de la soirée ou bien d’autre chose. De quoi a-t-on parlé ? Essentiellement de la conférence Devoxx qui a lieu dans deux mois. On a partagé nos envies et notre enthousiasme pour y aller.

Vers 19:10 on est parti tous ensemble aux locaux de l’ISEP.

Présentation de Startup Weekend

Sacha Bostoni - Photo: Claude Falguière

Sacha Bostoni nous a expliqué ce qu’est le Startup Weekend. On ne rentrera pas dans le détail car il existe déjà un post dédié (post startup weekend).

Comme promis, la main innocente de Laure a tiré au sort l’entrée gratuite offerte par Startup Weekend à Duchess France. Si vous êtes intéressés pour y assister, adressez-vous au groupe google duchessfr pour obtenir des entrées à prix réduit.

Nicolas Martignole nous a également rapidement présenté la conférence Soft Shake qui aura lieu le pour la première fois le 18 octobre à Genève. Cette conférence veut réunir les thèmes Agilité, Java et iPhone dans la même conférence. On vous en reparlera.

Une fois ces présentations finies, tout le monde arrivé et installé, la première partie de la conférence peut commencer :

Qu’est-ce que c’est NoSQL ?

Introduction à NoSQL

Depuis quelque temps on entend par ci et par là le mot “NoSQL” sans vraiment trop savoir ce que c’est. Ceux qui sont intéressés par la conférence Devoxx ont déjà constaté la quantité de sujets dédiés au Cloud/NoSQL cette année. Après tout le buzz autour de ce mot, Olivier Mallasi et Michaël Figuière nous ont fait finalement découvrir cette nouvelle technologie émergente en pleine expansion.

Michaël Figuière à gauche et Olivier Malassi - Photo: Claude Falguière

Les deux protagonistes de cette première partie de soirée ont réalisé un travail énorme pour enfin partager leur connaissances aux JUGs en France :

Olivier , consultant chez OCTO, créateur du NoSQL User Group Parisien début d’année 2010. Il est très expérimenté aux sein des systèmes d’information qui gèrent des grosses volumétries de données critiques.

Michaël, consultant chez Xebia, créateur du NoSQL Summer Group à Paris. Groupe dénommé  “underground” dont les participants se sont réunis pendant tout l’été au moins une fois par semaine pour travailler sur le sujet. Il est très expérimenté au sein des projets de fort trafic et de grosse charge.

Est-ce la fin… du langage SQL ?  des SGBDR ? des transactions ACID ?

Derrière le sigle NoSQL se cache aussi le phrase : Not Only SQL. Le NoSql est un ensemble de technologies apparues depuis deux ans environ qui regroupe des bases de données qui proposent des alternatives au SGBD relationnels. Ce n’est pas un remplacement des systèmes de gestion de bases de données existants, mais chacun de ces systèmes a un atout qui le rend intéressant dans certains contextes.

Ces bases sont toutes différentes mais dans l’ensemble elles proposent des solutions qui répondent à des problématiques de gestion de gros volumes, de disponibilité, de souplesse et d’élasticité. Il s’agit d’un écosystème riche et complexe qui sont déjà présent en production.

Origines

La croissance des entreprises Google et Amazon a finalement généré d’énormes besoins que les systèmes de base de données classiques n’arrivent plus à traiter : une performance extraordinaire pour des volumes de données monstrueux, disponibilité 24 /24, résilience et scalabilité horizontale.

Ces deux sociétés avaient des besoins radicalement différents ce qui illustre bien la diversité du NoSQL :

Google étant un moteur de recherche mondial, avait le besoin de stocker toutes les applications web de la planète et de faire tourner de puissants batch d’indexation. Il a donc développé Map/Reduce, basé sur BigTable . Leur système permet de couvrir des besoins énormes de lecture ainsi que l’agrégation de gros volumes des données.

Dans la même période, Amazon, la boutique en ligne mondiale, était arrivé au limite de la scalabilité qu’un système classique pouvait le fournir.  Amazon a besoin d’un stockage totalement disponible en écriture particulièrement dans le processus d’achat : l’utilisateur a besoin d’une disponibilité totale lors de la commande, et du paiement. Une fois le paiement réalisé, on est plus à la seconde prêt et on peut se permettre de décaler tout ce qui est reporting etc.  Pour couvrir leur besoin, Amazon a développé Dynamo : un système qui permet moins de 40 minutes d’indisponibilité par/an, ainsi que d’obtenir un débit et une disponibilité plus importante en écriture.

Finalement des entreprises comme Facebook, LinkedIn ou Twitter sont arrivées à la même conclusion.

Une importante offre Open Source apparaît : MongoDB, Voldemort, Cassandra etc. Chaque solution offre une stratégie de stockage différente.

Et Oracle ? Oracle travaille sur des solutions Data Grid, avec lequel on obtient des caractéristiques similaires pour un prix beaucoup plus élevé.

Passons à regarder un extrait de l’offre opensource existant.

Types de bases NoSQL

- Bases graphe

Leur modèle de représentation des données repose sur la notion de noeuds et de relation entre noeuds et de propriétés qui leur sont attachées. Ce sont des modèles très répandus dans le traitement des données de réseaux sociaux (l’utilisateur, ses amis, ses messages). Elles sont aussi en phase avec les outils du web sémantique (RDF, SparlQL).

Le principal représentant est Neo4J.

- Clé valeur

Ce sont des hashmaps distribuées. Ce modèle est très simple et les implémentations sont très nombreuses. On trouve principalement Voldemort crée par LinkedIn et Riak

- Bases colonne

Ce sont aussi des sortes de hashmap. Ce modèle ressemble un peu à une table relationnelle à première vue, mais une ligne peut avoir un nombre quelconque de “colonnes” qui sont en fait représentées par une série de couples clé-valeur. Elles permettent d’avoir une représentation plus flexible des données attachées à une entité. La base la plus connue dans cette catégorie est Cassandra

- Bases document

Ce sont encore des hashmaps où la valeur associée à une clé est un document soit XML soit JSON. Leur intérêt est de pouvoir retrouver avec une seule clé tout un ensemble d’informations structurées de manière hiérarchique : un utilisateur, ses statuts, ses messages. L’équivalent en relationnel impliquerait beaucoup de jointures. On trouve principalement MongoDB et CouchDB

Indépendamment de la stratégie de stockage de la base, un langage commun de requêtes – un équivalent SQL – n’existe pas encore. La programmation est encore assez lourde, et il n’existe pas encore d’outils équivalents aux ORM. N’oublions pas que c’est une technologie émergente, et MongoDB par exemple permet de faire quelque chose ressemblant à un ORM, mais Cassandra est loin encore de là.

Au delà des modèles de données spécialisés pour optimiser certains types d’opérations, ces bases partagent des caractéristiques d’architecture. NoSQL est un changement de paradigme :

• Table de hachage distribué
• Relâchement d’ACID

Qu’est-ce que c’est la “Table de hachage distribuée” ?

Elles utilisent en général la distribution des requêtes et des données sur plusieurs instances. Des mécanismes de hachage répartissent ces données sur un ensemble d’instances satisfaisant pour garantir la disponibilité. Ce type d’architecture leur donne de bonnes caractéristiques de scalabilité.

Transactions ACID : Comment se passent-elles avec NoSQL ?

(C)onsistance

” The consistency property ensures that the database remains in a consistent state; more precisely, it says that any transaction will take the database from one consistent state to another consistent state.”

Les bases NoSql appliquent généralement un principe d’eventual consistency (cohérence in-fine) qui relaxe une partie des règles. Dans ce modèle, les données sont redondantes, elles sont écrites sur plusieurs instances et lues sur plusieurs instances. Il appartient au développeur de définir pour chaque type d’usage le degré de fiabilité qu’il attend. De la même manière que les développeurs sur base de données relationnelles ont appris à régler le niveau d’isolation, ils vont devoir apprendre à travailler avec la redondance.

Pour assurer la consistance des données, on va partir d’une formule “magique” :

• N = Nombre de répliquas que l’on veut sur notre cluster
• R = Nombre de réponses en lecture à attendre
• W = Nombre de confirmation d’écriture qu’on va attendre

Il faut simplement que R + W > N : un recouvrement entre le nombre total d’instances en lecture et en écriture.

Afin d’illustrer la formule graphiquement :

Cas 1 :  R+W < N

Raté !

La consistance n’est pas assurée !

Cas 2 :  R+W = N

Raté !

La consistance n’est pas assurée !

Cas 3 :  R+W > N

On a gagné !

La durabilité est assurée au moins sur l’instance 2 !

En partant de la formule de base à respecter, on jouera avec les coefficients pour trouver le meilleur compromis adapté à notre système.

Lors de la ronde questions/réponses, deux questions intéressantes ont été évoquées à ce sujet :

Si les répliquas sont des entités physiques, et les valeurs R et W sont configurés par programmation… Comment est-il possible d’ajouter des répliquas dynamiquement ?

Réponse : Toutes les solutions NoSQL ne sont capables d’ajouter des répliquas dynamiquement; mais Cassandra par exemple dispose d’une configuration qui s’appelle “Quorum” : plutôt que de définir R et W, le client peut indiquer qu’il veut le quorum soit atteint (la moitié des instances +1)

Que se passe-t-il si on a deux écritures à la suite et les données ne sont pas cohérentes ?

Réponse : La plupart des bases NoSql implémentent une gestion de la concurrence basée sur un timestamp. Lors de la lecture seule la donnée la plus récente est conservée. Voldemort implémente aussi un système intéressant nommé Vector Clock.

(D)urabilité

“Durability is the ability of the DBMS to recover the committed transaction updates against any kind of system failure (hardware or software)”

Elles peuvent également avoir une interprétation différente de la durabilité. Pour une base de données relationnelle, la donnée persiste quand elle est écrite dans le journal sur disque. Pour les bases NoSql la situation varie. Certaines bases  appliquent les mêmes règles, d’autres vont se baser sur des journaux mémoire, d’autres encore travaillent essentiellement en mémoire comme Redis.

(A)Tomicite et (I)solation

“Atomicity requires that database modifications must follow an “all or nothing” rule”

“Isolation refers to the requirement that other operations cannot access data that has been modified during a transaction that has not yet completed.”

L’atomicité et l’isolation sont des concepts difficiles à transposer lorsqu’ils impliquent des relations entre données qui sont distribuées sur des instances dont le nombre est variable et qui pourraient éventuellement ne plus pouvoir communiquer.

Points positifs/négatifs

Les caractéristiques techniques que ces bases ont choisi d’implémenter leur donnent un avantage sur les aspect suivants :

• Gérer plus de volume, les données peuvent être déployées sur plusieurs instances ;
• Avoir une meilleure disponibilité en écriture, essentiellement en se passant du transactionnel qui crée des points de contention ;
• Une meilleure tolérance aux pannes partielles (les partitionnements réseaux), la redondance des données fait qu’il existe statistiquement la donnée sur la branche qui reste accessible, l’écriture reste possible sur les nœuds accessibles et la resynchronisation se fera plus tard ;
• L’élasticité, sur la plupart des systèmes le nombre d’instances peut varier dynamiquement et la base sait se rééquilibrer sur les nœuds ;
• Conserver des bonnes performances sur de très gros volumes ;
• Permettent une modélisation plus souple (en particulier le mode colonne qui permet par exemple d’utiliser une variable comme nom de colonne) ou plus immédiatement utilisable (graphes, document JSON) ;
• La flexibilité de la modélisation permet aussi de gérer plus facilement les évolutions de structures de données.

La contrepartie est un coût de développement et des impacts structurels au sein des équipes de production :

• Les API sont très simples, souvent très basiques et limitées à un PUT, GET, DELETE ;
• Le code client doit prendre en charge des éléments cachés par les couches SQL liés à l’organisation des données et la gestion de la redondance ;
• Il n’existe pas d’outils équivalents aux ORM qui rendent transparente la base de données ;
• Il n’existe pas un langage commun (similaire à SQL), tout est dépendant de la solution choisie. Mais des ‘langages’ communs par famille de base de données pourrait apparaître ;
• Dans la mesure où on ne peut pas faire de jointure après coup, tout repose sur une bonne organisation des données et un travail important sur les clés ;
• Pour les productions aussi le NoSql est un changement de paradigme : il demande des compétences différentes de celles des DBA. Ce sont souvent des outils qui tournent dans des JVM et nécessitent une bonne compréhension de la  distribution ;
• La sécurité sur les bases NoSql est un sujet qui n’est pas vraiment traité pour l’instant. Il n’y a pas d’accès restreint par exemple.

Conclusion

Au delà du buzz, NoSQL est une technologie émergente à surveiller. Cherche-t-elle à remplacer les systèmes classiques ? NoSQL challenge 40 années de stockage de données, mais la réponse est non.

On va de plus en plus vers la souplesse, la disponibilité totale des applications, l’élasticité, et le stockage de données devient de plus en plus importante. Est ce que les applications que l’on réalise au quotidien en auront besoin ? Pour le moment pas vraiment, mais Michael constate que la possibilité crée le besoin, et que des demandes auparavant inimaginables voient le jour.

A retenir : NoSQL est déjà en production et la performance est excellente. Or vous ne devriez pas choisir NoSQL uniquement pour la performance pure sur une instance, mais plutôt pour le besoin de distribution de données et de disponibilité.

Retour d’expérience : CMS on top of NoSQL par Steven Noels

C’est un grand jour aujourd’hui. Six mois après la création de Duchess France une antenne se crée à Lyon à l’initiative d’Agnès Crepet.

Qu’est ce qu’une antenne de JDuchess ? En bien on ne sait pas encore très bien Depuis la création de notre groupe nous savons quelles idées nous voulons défendre mais les actions se sont construites au fur et à mesure, au fil des rencontres et des discussions avec des femmes et aussi des hommes qui ont voulu agir.

Alors pourquoi forcer les choses pour les antennes? Agnès a des idées d’articles. Elle sera également sur place pour représenter JDuchess auprès de la communauté Java locale, nous signaler les événements intéressants dans la région de Lyon, rencontrer d’autres personnes et réfléchir avec elles à de nouvelles actions.

Donc voilà nous sommes très fières que d’autres veuillent suivre ce mouvement et nous souhaitons beaucoup de réussite à Agnès. Et aussi beaucoup de courage car nous savons à quel point aller vers les gens pour les convaincre, faire des retours sur les événements, rédiger des articles techniques demande d’énergie et de temps. Nous lui souhaitons de réunir un groupe autour d’elle parce que c’est plus fun et plus intéressant de réaliser des actions ensemble.

Elle aura besoin de vous sur Lyon, de femmes développeurs, architectes, enseignants en informatique, et d’hommes aussi, pour relayer les messages et participer à des groupes de travail et à l’organisation d’événements. Et bien sûr nous serons là pour l’aider et mettre à disposition les moyens techniques de JDuchess, le blog, les mailing lists, le calendrier.

Agnès fera une présentation ce soir au Lyon JUG et ce sera une occasion de prendre contact. Si vous n’avez pas pu vous libérer, vous pouvez aussi vous signaler auprès d’elle en réponse à cet article ou en rejoignant Duchess France sur le Google group Duchessfr. Vous aurez l’occasion de vous présenter et de rejoindre la communauté lyonnaise.

Et si vous n’êtes pas sur Lyon ? Rien de vous empêche d’apporter votre soutien   Mais si vous voulez aller plus loin et tenter l’aventure, vous pouvez nous contacter ou simplement tester l’idée à la suite de cet article. Et qui sait,  peut être trouver des compagnons d’aventure pour se lancer.

eXo Social, an OpenSocial implementation– Tugdual Grall et Jérémi Joslin
par Audrey Neveu

Faisant suite à la création de GateIn, développé avec les équipes de JBoss, eXo Platform a présenté en mai dernier eXo Social 1.0, une implémentation de OpenSocial permettant d’ajouter du contenu orienté réseaux sociaux à votre portail d’entreprise.

Qu’est ce qu’OpenSocial ?

OpenSocial est un ensemble d’API développées par Google destinées au développement d’applications de réseau interopérables.

Un réseau social pourrait se résumer en 3 points :

• mon identité : qui suis-je ?
• mes relations : qui est-ce que je connais ?
• mes activités : quoi de neuf ?

Ces 3 points vont aboutir à la nécessité de créer diverses applications pour la gestion de document par exemple, ou encore la création de groupe, les forums de discussion, les messages, etc …

La plupart des API existantes sont en JavaScript, REST pour le transfert et RPC. Pour la partie visuelle il s’agit essentiellement de gadgets en HTML à la iGoogle. Les conteneurs open sociaux sont déjà nombreux compte tenu de l’explosion du nombre de réseaux sociaux et de leur fréquentation.

Le cas eXo Social

eXo Social a pour vocation de permettre le développement d’applications de réseaux sociaux pour un portail d’entreprise, en se basant sur l’intranet existant par exemple. Pour l’entreprise, c’est la possibilité d’avoir des gadgets pour gérer l’activité, tout en modérant leur visibilité avec une gestion des droits par utilisateur.

Au sein d’Exo, le choix a été fait de se baser sur Apache Shindig, qui est considéré comme l’implémentation de référence d’OpenSocial, pour l’intégrer au coeur de la plateforme GateIn. La plateforme apporte déjà le support pour les gadgets , le tout étant intégré au modèle de stockage (JCR) et de sécurité de GateIn.

En pratique

Un gadget ce n’est rien d’autre que du xml avec des portions HTML, CSS, et JavaScript, intégré dans la page via une iframe. Chaque gadget étant parfaitement indépendant, le coût d’affichage d’un gadget ne pénalise pas les autres et il en va de même pour une possible erreur de développement. Contrairement aux portlets qui sont une technologie serveur, les gadgets sont une technologie cliente reposant sur les API JavaScript OpenSocial et eXo Social. Il ne s’agit que d’une page html avec de l’ajax. L’utilisation sous-jacente de REST permet de mettre à disposition l’information rapidement, le tout formant une application réactive, riche et dynamique.

Chaque gadget est éditable facilement, via un IDE en ligne développé par eXo et basé sur GWT. Grâce à l’utilisation d’une registry (JCR), il est ainsi possible de prévisualiser le gadget, de le versionner ou de faire un revert, puis de le mettre à disposition des utilisateurs. L’authentification quant à elle repose sur oAuth, un protocole de propagation d’identité. Aucune information personnelle n’est envoyée, c’est un token d’accès renvoyé par le provider qui permet l’accès aux données.

JSF 2– Damien Gouyette (présentation)
par Ellène Dijoux

Damien Gouyette, auteur du blog C’est pas dur, nous présente au travers d’un cas concret l’utilisation de JSF 2. Son projet disponible sur github est un projet de blog réalisé avec JSF 2.

Le rendu visuel avec Facelets

JSF est un framework orienté composant, et pour réaliser son projet il a utilisé Facelets pour la vue. Facelets permet de réaliser le templating des pages et des composants. Il a été utile pour le découpage et l’organisation des composants du blog. Il évite l’apparition des classes Java dans les pages JSP et participe au respect du pattern MVC (Modèle Vue Contrôleur).

Le traitement

L’annotation @ManagedBean permet d’identifier la classe qui réalise le traitement, plusieurs annotations sont disponibles pour définir le cycle de vie des Managed Beans : @ApplicationScoped, @SessionScoped, @ViewScoped, @RequestScoped, @NoneScoped.

La navigation

Aves JSF 2, il n’est plus nécessaire de définir et maintenir le verbeux faces-config.xml. Le ManagedBean peut maintenant retourner une valeur qui sera considérée comme étant le nom de la page sans l’extension. S’il ne trouve pas de fichier par défaut, il se conforme aux règles de navigation définies. Un autre souci auquel nous pouvons être confrontés avec JSF est la double validation de formulaire, le problème peut être résolu en passant par la méthode GET. Les URLs peuvent être bookmarkables grâce à trois composants : <h:link />, <h:button />, <h:viewParam/>.

Validation

Grâce à Hibernate Validator, la définition des contraintes sur les champs ne se fait qu’à un seul endroit. Il est possible de valider des adresses email, la taille d’un texte, …

Requête Ajax

La balise <f:ajax /> permet de définir une requête Ajax avec les attributs :

• execute qui a plusieurs valeurs possibles : @all, @none, @form, @this ;
• render qui indique les composants à soumettre côté serveur.

Composant composite

Le composant composite permet de créer ses propres composants réutilisables. Pour son projet de blog, Damien a créé un composant Twitter. Pour ce faire, il définit des ressources statiques tel qu’un twitter.xhtml où le code du composant est défini avec sa CSS et ses images. On utilise ensuite les balises  <cc:interface /> et <cc:attribute /> pour définir les paramètres d’entrée à fournir au composite que l’on pourra utiliser lors de l’appel au composant. On peut ensuite associer du code métier à notre composant. Le principe est simple : créer une classe java respectant la même hiérarchie que le composant XHTML. Par exemple pour un composant mycomponents/Twitlistjava, on crée une classe mycomponents. Twitlistjava qui implémente l’interface NamingContainer.

Outils

Pour développer en JSF 2 actuellement, plusieurs librairies de composants sont à notre disposition : RichFaces 4.0 M2, IcesFaces 2.0 béta 1, PrimeFaces 2.0 … Les serveurs d’application disponibles sont : Glassfish, Tomcat, JBoss et Jetty. Pour développer, vous aurez à votre disposition NetBeans 6.9, Eclipse, JBoss Tools et IntelliJ IDEA.

Synthèse

Parmi les nouvelles fonctionnalités, nous avons maintenant :

• Ajax inclus et optimisé ;
• les profils d’utilisation ;
• externalisation des ressources statiques ;
• 2 nouveaux scopes : ViewScope et FlashScope ;
• le support du GET en plus du POST.

On peut aussi noter les améliorations suivantes :

• le développement de composant plus facilement ;
• la navigation n’est plus aussi lourde à définir (plus de faces-context.xml) ;
• la configuration XML est maintenant remplacée par des annotations.

Le MDA en 2010 – Une vision pragmatique nommée Acceleo– Jérôme Benois (présentation)
par Audrey Neveu

Le but de cette session était de nous présenter l’historique et les apports de la démarche MDA et comment la mettre en oeuvre simplement avec eclipse.

Qu’est ce que le MDA ?

Le Model Driven Architecture voit le jour début 2000, partant du constat qu’à cette époque 2 projets sur 3 sont en dépassement significatif de coût et/ou de délai. La DSI s’interroge sur la façon de diminuer ces coûts, sur la possibilité de capitaliser le savoir faire de ses équipes etc … en bref comment produire mieux avec les mêmes équipes ?

La nécessité de passer par des modèles pour monter en abstraction et mieux communiquer entre les équipes métiers et IT se fait sentir, et UML est retenu pour supporter tout cela.

Plusieurs phases s’enchaînent dans le MDA, chacune s’appuyant sur une partie des modèles proposés par UML :

• Recueil des besoins / exigences : livrable = CIM. Le Computation Independant Model va se baser sur les exigences du système et va pour cela avoir recours aux use case diagrams et autres sequence diagrams.
• Analyse : PIM ou Platform Independant Model (Class diagram, Activity Diagram, State Chart Diagram, Sequence Diagram)
• Conception : PSM (Class diagram, Component Diagram, Deployment Diagram) considérations techniques proches de la plateforme
• Implémentation : le code.

Et Acceleo dans tout ça ?

Acceleo est un générateur de code basé sur OMG MOF To Text Language, développé par Obeo, partenaire de longue date d’Eclipse, qui permet de traduire rapidement le modèle en code.

Il dispose notamment de modules qui lui permettent de générer du code dans de nombreux langages (java, .c#, Php, Python …). Chaque module est lui même composé de plusieurs templates paramétrant la génération du code, comme par exemple le template generateEntity.

Entièrement intégré à Eclipse, il a l’avantage certain de laisser aux développeurs les facilités auxquelles il est habitué : auto complétion et coloration du code par exemple.

Après la génération du code vient le cycle de maintenance et la génération incrémentale. Celle ci peut se faire de deux façons :

• le “User-Code Pattern” consiste à laisser le développeur coder librement entre marqueurs.
• le “Generation Gap Pattern” consiste à avoir deux sources folders pour séparer le code généré du code non géré

Le constat après plusieurs années de développement

Côté avantages, amélioration de la productivité et meilleure agilité technique et fonctionnelle sont au rendez vous, mais de nombreux inconvénients ont tout de même été relevés, parmi lesquels :

• la difficulté à maintenir en cohérence les différents modèles
• le risque de désynchronisation entre le modèle et le code
• l’intégrisme du tout modèle : il n’est pas possible de modéliser l’algorithmie par exemple
• la lourdeur des outils et des standards UML
• la déconnexion des générateurs en maintenance

Les leçons tirées de cette expérience

Tout d’abord que l’UML est un langage riche pour représenter le modèle, mais peut être un peu trop. Il existe des diagrammes pour représenter quasiment tout, du modèle aux étapes de développement. Or les diagrammes du PSM par exemple, peuvent rapidement devenir redondant avec le code source. D’où l’envie de privilégier le DSL (Domain Specific Language) que notre speaker résume ainsi : un vocabulaire précis et concis pour une problématique précise. En effet en DSL, tout est centré sur un problème technique ou métier bien particulier.

Autre point important, le modèle doit rester un support de communication et un outil de productivité. Autrement dit les équipes doivent communiquer entre elles : métier et développement doivent interagir fortement afin d’être sûres que chaque partie a bien compris la problématique posée.

Et enfin, garder les générateurs connectés en maintenance et ne pas oublier les bonnes pratiques d’ingénierie (tests automatisés, utilisation de svn/git, build automatique et reproductible, intégration continue, qualimétrie, etc …).

Le futur du MDA : l’ingénierie des modèles

On parle donc désormais d’Ingénierie Dirigée par les Modèles (IDM ou MDE : Model Driven Engineering). La version 2.0 de l’approche MDA se nomme MDD (Model Driven Development), aussi appelé MDSD (Model-Driven Software Development). Côté outils on s’appuie toujours sur la plateforme d’Eclipse. Grâce à Eclipse Modeling Project et son écosystème riche proposant à la fois des outils de développement à partir du modèle (UML entre autre) :

• Transformation du modèle (Modele To Modele ou Modele To Text)
• Représentation graphique du modèle (Concrete Syntax Development)
• Modélisation et génération facilitée du code (Abstract Syntax Development).

Mettre en oeuvre une démarche modèle pragmatique

Fort de ces constats, reprenons les différentes étapes du MDA pour les faire évoluer :

• CIM et PIM (recueil des besoins / exigences et analyses) deviennent des DSL
• l’architecture cible est décrite par les générateurs de code (conception)
• le PSM est remplacé par le code lui même

La démarche recommandée par Jérôme pour cela est :

• identifier le vocabulaire échangé avec le métier
• le définir clairement
• le définir en code

Pour manipuler ce vocabulaire l’API EMF Java va nous permettre de construire des outils et de faire des imports depuis des sources d’informations existantes.

Pour le construire en revanche, nous disposons de XText, un framework de développement de DSL textuel basé, qui offre de nombreuses fonctionnalités telles que la complétion, la validation, des fonctions d’édition, etc …

Il nous faut ensuite passer du DSL au DSM. DMS est la représentation graphique du modèle. A l’aide d’un framework de notre choix qui sera basé sur Eclipse GMF, nous profiterons d’un environnement dédié, simple à paramétrer pour obtenir des diagrammes de qualité.

Du DSM au point de vue !

L’enjeu du MDA étant de faciliter le dialogue entre les équipes métier et technique comme nous l’avons vu plus haut, le DSM – graphiques – doit être là pour permettre à chacun de retrouver “son point de vue”, tout en dépassant les représentations “sectaires” : l’IT d’un côté, le métier de l’autre. Autrement dit, on doit tendre vers un modèle unique mais abordable par tous.

Conclusion

Pour Jérôme DSL + DSM + Acceleo = approche modèle efficace. Si la théorie est facile à croire, sans pratique il est difficile de se faire un réel avis sur cette autre façon d’envisager la conception.

Session de rentrée pour le Lyon JUG le 21 septembre, avec au programme une soirée consacrée aux nouveaux systèmes de gestion de configuration décentralisée : GIT et Mercurial. Et attention, cette soirée sera aussi l’occasion de lancer l’antenne lyonnaise de JDuchess.
Un peu de teasing sur cette soirée… Pour vous donner envie de venir, nous avons posé quelques questions aux speakers de la soirée, Loïc Frering et Sébastien Deleuze…

Agnès : Alors, en quelques mots, comment peut-on définir les systèmes de gestion de version décentralisés? Quelles sont les grandes différences avec les systèmes centralisés tels que SVN?

Loïc et Sébastien : Les systèmes de gestion de versions décentralisés permettent à chaque contributeur de disposer de la totalité du dépôt dans une copie locale, sans être dépendant d’un serveur central. Chaque copie d’un dépôt contient donc l’historique complet du projet qui peut être manipulé localement.
En conséquence, les DVCS sont beaucoup plus performants que les systèmes centralisés pour les opérations telles que le clone (copie d’un dépôt distant), la manipulation de branches ou la recherche dans l’historique qui ne nécessitent plus de communication avec un serveur central : plus besoin de réseau pour pouvoir travailler.
Autre spécificité, il est maintenant possible de mettre en place des workflows de travail entre collaborateurs bien plus évolués. Il est en effet très simple de se synchroniser avec n’importe quel dépôt distant via des pull et push.
Ces nouveaux systèmes sont également bien plus efficaces par leur mécanique de stockage : Git et Mercurial stockent des fichiers entiers au lieu d’une suite infinie de diff, ce qui accélère grandement la manipulation d’historique et la reconstitution de révision.
Enfin, contrairement aux systèmes centralisés, la création et le merge de branches sont enfin utilisables facilement. Ceci favorise le développement dans des branches isolées de plusieurs sujets en parallèle. Il est aussi possible de mettre en place différentes stratégies de gestion des branches évoluées, avec des branches dédiées par exemple aux ajouts de fonctionnalités ou correction de bugs, alors que d’autres reflètent l’état de différents environnements : qualification, production.

Agnès : Les DVCS ont un fort succès dans le monde des logiciels libres. En quoi se prêtent-ils mieux aux pratiques des développeurs des logiciels libres? Permettent-ils d’être plus “agiles”?

Loïc et Sébastien : Effectivement, de plus en plus de logiciels libres migrent vers des DVCS, nous identifions trois principales raisons :

Agnès : Parmi les avantages des DVCS souvent mis en avant, il y a la facilité de faire des branches, et plus particulièrement de merger. Par quelle “magie” les DVCS opèrent-ils pour rendre les merges plus simples?

Loïc et Sébastien : Les DVCS ont en grande partie dédramatisé le processus de merge en le rendant bien plus puissant et intelligent pour que le maximum soit fait automatiquement.
Soulignons plus particulièrement que dans les DVCS :

Agnès : Vous allez comparer dans votre présentation Mercurial à Git. D’autres DVCS existent (Bazaar, etc.) : parmi les outsiders, Fossil et le tout nouveau Veracity de SourceGear, des DVCS avec bug-tracking intégré pour l’un et base de donnée distribuée pour l’autre. Vous paraissent-ils prometteurs?

Loïc et Sébastien : Voici notre avis sur les outsiders.

Inscription et informations pratiques sur la soirée sur la page officielle du Lyon JUG