Revue de Presse Xebia

Cassandra s’inspire de l’architecture de Google Big Table et Amazon Dynamo. Ces systèmes sont conçus pour être des solutions fortement scalables et aussi gérer des entrepôts de données importants, de l’ordre du petabyte (représente 10 puissance 15 soit un un million de milliards). Son architecture est semblable à un réseau P2P contrairement ou base de données classique (Oracle, MySQL, …) qui ont une architecture centralisée (sous forme de Cluster). Cette architecture permet de répartir la charge et de contourner des goulets d’étranglement de trafic de données.

L’avantage d’une telle architecture est d’être très scalable, et d’éviter les goulets d’étranglement de performance, au détriment de la cohérence de données.

Autant dire que les problématiques adressées par ces outils sont fortement critiques, mais seulement pour des systèmes d’information très particuliers.

Agilité

Les outils pour l’Agilité

Kent Beck (l’un des fondateurs d’XP) partage ses réflexions sur la relation entre les outils et l’Agilité.

Il constate que beaucoup de personnes font une mauvaise interprétation d’un des principes du manifeste agile : Privilégiez les personnes et leurs interactions plutôt que les processus et les outils. Cela ne signifie pas qu’il n’y a pas besoin d’outil ! Les outils sont indispensables et les méthodes agiles font émerger de nouveaux besoins. Les tests unitaires, la conception incrémentale, et l’intégration continue sont des exemples de changements qui accompagnent le développement agile. Kent prédit d’autres changements à venir :

Des transitions plus aisées entre les activités
Un plus grand périmètre pour les tests automatiques
La transparence
Une collaboration en temps réel

Une synthèse du livre blanc est disponible sur InfoQ et sur le blog de Claude Audry.

RIA

OSCON 2008 : Web framework of the future

Lors de la convention de l’Open Source à Portland (EU), Matt Raible a présenté Web framework of the future où sont comparés les frameworks suivants : Flex, GWT, GRails et Rails

Il propose deux ‘nouveaux’ pattern pour la conception des couches de présentation pour les applications SOA :

Le SOFEA se fonde sur trois principes fondamentaux :

AD : Application Download, décrit la manière dont la couche client est téléchargée du serveur chez l’utilisateur. Suivant le paramétrage du client (logiciel, sécurité, …) une certaine application sera téléchargée par le client
PF : Presentation Flow, décrit la manière dont la couche de présentation enchaîne les écrans et dont les données sont transmises d’écran en écran. La réalisation de ce principe doit être dirigée par la partie client et non service
DI : Data Interchange, décrit la manière dont la couche de présentation et la couche service s’échangent les données. La couche de présentation doit supporter les mêmes structures de données que la couche modèle

La tableau suivant liste quelques solutions pour implémenter les trois principes précédents avec deux modèles de client thin client, rich client :

Principe	thin client	rich client
Application Download	Cette opération est assurée par le conteneur de la partie cliente (navigateur web)	C’est une opération explicite, le client télécharge une application suivant le paramétrage du client (Flash/Java Web Start)
Presentation Flow	Une partie de la navigation peut être assurée par du Javascript côté client. Cependant, la grosse partie de la navigation est assurée côté serveur avec un framework	La navigation est gérée localement (sur le poste client) par l’application téléchargée. Sur cette partie client, le pattern MVC est envisageable
Data Interchange	Il n’y a pas de communication directe, elle est assurée par le conteneur de l’application serveur (serveur Web). Un modèle HTML/HTTP est utilisé pour s’échanger les données, elle suit la sémantique requête/réponse.	Une certain nombre de protocoles et de format d’échange de données peuvent être utilisés, dans la plupart des cas c’est du XML. Généralement, la sémantique utilisée est la requête/réponse mais elle peut aussi être une semantique peer-to-peer.

A l’instar du SOFEA, le SOUI se base sur un découplage net entre la couche de présentation et la couche service métier. La conception de la couche présentation est pilotée par la couche de service métier et non l’inverse.

Ces principes sont mis en oeuvre au travers de 3 frameworks :

Flex : pour la réalisation d’interface en Flash.
GWT : pour la réalisation d’interface en DHTML/Ajax, développée en Java. Cette technologie peut amener à des difficultés lors que l’on travaille sur du code source existant.
GRails (Rails) : pour la réalisation d’interface Web en suivant le pattern MVC. Le scaffolding apporte une mise en place des écrans rapide, mais supporte mal le REST.

Ces technologies sont assez différentes dans leur architecture et dans leur prise en compte de l’existant. Flex supporte bien le REST. Les technologies Rails (GRails, Ruby On Rails, Django) apportent de la productivité grâce à un langage dynamique et expressif, au scaffolding » >_scaffolding_, à l’active record » >_active record_, aux conventions de nommage, et au principe don’t repeat. GWT permet d’implémenter des applications Web riches en ayant peu de compétences Javacript, il suffit de bien maîtriser Java et CSS.

SOA

Succès des projets SOA : seulement 20% selon le Burton Group

Nous annoncions en Mars dernier le lancement du sondage du Burton Group sur le succès des projets SOA. Nous saluerons d’abord l’honnêteté de l’étude d’Anne Thomas Mannes qui reconnaît pas moins de 50% d’échecs complets.

Il ne faut pas pour autant condamner SOA dans son ensemble ; les piliers de cette démarche correspondent à des réalités des entreprises d’aujourd’hui. Certains principes comme le couplage lâche et la cohérence ne sont pas nouveaux et des idées comme la gouvernance des services et les Service Level Agreement qui vont avec, restent souvent des voeux pieux difficilement mis en oeuvre eu égard aux changements culturels qu’ils demandent.

Nous ne tirerons donc pas aujourd’hui sur l’ambulance. En plus des 10 pièges de la SOA dont nous avons déjà parlé ces dernières semaines, nous retiendrons que sur le fond, les échecs sont plus souvent dûs à un manque de vision métier et architecturale qu’un à problème d’implémentation technique.

Un point intéressant de l’étude du Burton Group : une culture purement projet, malgré ses vertus de mise en production à un prix et une date maitrisés, se marie mal à une démarche SOA. Le délai court et le périmètre étroit, clefs du succès d’un projet (ce que nous prônons), sont souvent incompatibles avec une architecture SOA qui demande une vision plus large des briques du SI et des retours sur investissements plus long.

Le coin de la technique

Interopérabilité OSGI et Java Module System

Plusieurs mois après l’annonce d’une éventuelle interopérabilité entre Java Module System et OSGI, le sujet est toujours en discussion au sein du groupe d’experts de la JSR-277. Sun semble un peu patauger dans la gadoue sur ces spécifications, il est vrai qu’il est difficile de contenter tout le monde sur un sujet ou chacun essaye d’imposer ses idées.

Et bien vous pouvez maintenant vous faire votre propre opinion, le sous-projet implémentant le draft de Java Module System inclus maintenant un repository OSGI. Le prototype est pour le moment uniquement compatible avec l’implémentation OSGI de la fondation Apache (Apache Felix). L’interopérabilité semble complètement transparente à l’utilisation, vous pouvez importer des modules OSGI de la même manière que vous importeriez des modules JAM (JAva Module). Si vous voulez essayer par vous-même un exemple complet est disponible sur le blog de Mandy Chung.

Nouvelle JSR : Post mortem JVM Diagnostics API

Les principaux outils de diagnostic (débuggeur, outils de trace, analyse de performance) permettent de surveiller le comportement de la JVM lorsqu’ils sont activés. Ce genre d’outils est très efficace quand les problèmes sont reproductibles et que le client est prêt à accepter le prix de cette reproduction. C’est pourtant en pratique pas toujours le cas : soit par ce que le bug est dû à un problème ponctuel, soit par ce que le coût de reproduction n’est pas acceptable. L’analyse rétrospective est compliquée et nous manquons d’outils permettant d’effectuer des analyses ‘post-mortem’.

La nouvelle JSR-326 : Post mortem JVM Diagnostics API voudrait pallier à ce manque en proposant un API permettant d’effectuer des analyses sur des artefacts générés à chaud par la JVM (HPROF ou autres… ).

Elle proposera :

un ensemble d’outils permettant de lire ces analyses
un moyen d’étendre ces outils
un moyen de standardiser la génération à la volée de ces artefacts

Alex Miller en a profité pour demander à Steve Poole (specifications leader de la JSR) si celle-ci à une chance d’arriver à temps pour le jdk7. La réponse évidement incertaine : toujours aucune date pour cette fameuse umbrella JSR devant officialiser le contenu de la prochaine version de Java…

Optimiser les performances de Java : rencontre avec Kirk Pepperdine

Dans cet article sur le Sun Developpper Network, Kirk Pepperdine revient sur ses expériences dans le domaine de la performance. Nous retiendrons les points suivants :

L’un des principaux écueils dans une analyse de performance est le manque de méthode avec un focus prématuré sur le code. La plupart des équipes plongent directement dans le code, au mépris d’informations plus globales sur le système. Pour améliorer ce point Kirk Pepperdine expose deux méthodes : la box et le mantra Ne devinez pas, mesurez
Plonger directement dans le code est d’ailleurs l’un des soucis majeurs que Kirk Pepperdine a rencontré au cours de sa carrière : aussi doué soit-il, un développeur ne parviendra pas à résoudre un problème de performance uniquement par la lecture du code ; la phase préliminaire de caractérisation du problème et d’identification du code en cause est primordiale.
L’un des facteurs de succès dans l’amélioration des performances est un code source simple et bien structuré. Un code simple (a.k.a. « dumb ») permet une meilleure analyse, aussi bien par des humains que par les optimiseurs de JVMs. De plus, un code complexe cache souvent des optimisations prématurées.
Un code bien structuré permet ajouts et remaniements qui sont souvent la clé de toute optimisation.
De manière générale, les grands principes agiles (couplage lâche, délégation, application des bons design patterns, bonne couverture de tests unitaires, builds automatisés) s’appliquent dans le cadre du tuning des performances.
Il faut se méfier des Performance Tips qui peuvent se révéler être des faux amis : une solution peut fonctionner dans un cas et s’avérer catastrophique dans une autre situation ou avec les versions suivantes d’une JVM.
La majorité des problèmes de performances se situent au niveau de la base de données et de la mémoire de la JVM.
Les principales mauvaises pratiques en ce qui concerne les liens entre programme Java et base de données sont :
     – Rendre son application résistante à l’introduction de caches (e.g. en mélangeant des accès jdbc au code métier)
     – Utiliser la base de données comme un mécanisme de lock distribué
     – Utiliser la base de données pour exécuter de la logique métier clef
     – Stocker des flux dénormalisés en base.
Le premier indice d’une sur-utilisation de la base est le nombre d’interactions entre celle-ci et l’application. La correction la plus triviale à cette erreur est d’ajouter un cache, ce qui sera beaucoup plus rapide et efficace que de tenter de réduire le nombre d’appels à la base.
Une autre astuce est de grouper au maximum les interactions application – base de données.
La gestion de la mémoire peut aujourd’hui reposer uniquement sur des outils efficaces :
     – Détection des fuites mémoire : Visual VM et Netbeans Generation
     – Objets ‘zombis’ : Netbeans Generation ou attendre le time out de ces objets
     – Un taux élévé de création d’objets. Cela entraîne généralement une Garbage Collection inefficace. Surveiller l’activité du GC permet donc de diagnostiquer ces problèmes (HPJMeter, Tagtraum, gchisto).
La majorité des problèmes de mémoire peuvent être réglés en jouant sur les Java Heap Size.
Une équipe stressée ne parviendra pas à traiter efficacement les problèmes. C’est pour cela qu’il est parfois bon d’envisager une correction ‘quick & dirty’ qui contente un maximum d’utilisateur, afin de faire baisser la pression sur les développeurs, pour pouvoir se poser et réfléchir à une solution à long terme.

M2Eclipse : Le nouvelle éditeur graphique de pom

Une nouvelle fonctionnalité vient de paraître dans la version 0.9.5 du plugin M2eclipse : l’éditeur graphique de fichier pom.xml. On peut remarquer que pour une première version, l’éditeur est déjà assez complet : la très grande majorité des paramètres configurables d’un pom sont présents et l’éditeur offre la complétion pour l’ajout de dépendances (déjà présent dans l’éditeur « source »).

Mais la fonctionnalité qui mérite le coup d’oeil est celle permettant d’afficher l’arbre de dépendance sous la forme d’un arbre. L’éditeur reprend le goal tree du maven-dependency-plugin en lui ajoutant la visualisation graphique qui le rend bien plus facile à utiliser que son rendu en ligne de commande. Pour vous en rendre compte, voyez plutôt les quelques captures d’écran disponibles. L’éditeur offre aussi une vue des dépendances sous la forme d’un graphe mais ce plugin relève encore du gadget, devant inutilisable sur des projets un peu conséquents.

M2Eclipse, en compétition avec Q4E pour devenir l’intégration officielle de Maven dans Eclipse (cf The Eclipse Integration for Apache Maven (IAM)), a fait de grands progrès depuis ses premières versions et si vous ne l’avez pas testé depuis longtemps, la dernière version mérite le coup d’œil …

Actualité éditeurs / SSII

Projet Cassandra : donation de Facebook à la communauté Open Source