Revue de Presse Xebia

La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.

Actualité éditeurs / SSII

• Sortie officielle de SpringSource dmServer

Agilité

• Sprint zéro
• Méthodes agiles et développement de Google Chrome

RIA

• Framework RIA : où en est-on?

Le coin de la technique

• EJB 3.1 se dévoile
• Pour l’amélioration de la qualité, gérez vos dépendances
• Les dessous d’InfoQ

Actualité éditeurs / SSII

Sortie officielle de SpringSource dmServer

L’actualité SpringSource ne faiblit pas, à chaque semaine son annonce. Après les vif remous engendrés par la nouvelle politique de maintenance et l’arrivée de Rob Bearden à SpringSource de la semaine dernière, au programme cette semaine, une nouvelle un peu plus technique : l’arrivée en GA (General Availibility) de son serveur d’applications OSGI ‘dmServer’.

Il s’agit en fait de la sortie officielle de son produit anciennement appelé S2AP (SpringSource Application Platform) annoncé depuis mai dernier dont les versions bêta se sont succédées cet été. Le produit a été renommé en dmServer lors de l’arrivée de la RC2 en Septembre dernier, S2AP existe toujours comme terme plus générique. Il désigne ce serveur d’applications dmServer ET son ensemble d’outils, de services et de supports : SpringSource Enterprise

Pour revenir à la sortie de dmServer, celui-ci se présente comme un serveur d’applications modulaire basé sur OSGI dont voici les principaux bénéfices :

• pour le développeur, l’approche modulaire permet d’améliorer la réutilisation du code et de faciliter le développement itératif sans trop dépendre d’un serveur d’applications particulier
• pour la production, dmServer propose des fonctionnalités de mises à jour applicatives et serveur automatisées, une compatibilité avec des environnements grid et virtualisés et une meilleure utilisation des ressources. Embarquant Tomcat, il reste également compatible avec les anciennes applications Web.

Pour terminer les nouveautés SpringSource, notons également la sortie de Spring Security 2.0.4 disponible en téléchargement, il s’agit de la première release post 3 mois Open Source de SpringSource depuis qu’ils ont annoncé qu’ils arrêtaient d’en faire :-)

Agilité

Sprint zéro

Dans ces articles de Claude Aubry et de Mark Levison, ceux-ci nous expliquent en quoi consiste ce sprint. Il contient entre autres en la définition backlog initial, la définition des users stories, la priorisation des items… Mais ce sprint est aussi consacré à la mise en place des environnements de travail, à la définition d’architectures (si celles-ci ne sont pas définies), à la mise en place d’un prototype…
La difficulté est que ce sprint n’a pas vraiment de durée, mais il est judicieux de la maintenir la plus courte possible, car rien n’est produit au final (pas de produit utilisable à la fin, pas de mesure de la vélocité…).
Alors peut-on parler effectivement de Sprint zéro (et donc intégré à Scrum) ou bien de phase préparatoire ? Le débat est ouvert.

Méthodes agiles et développement de Google Chrome

Darin Fisher, membre de l’équipe de développement de Chrome, expose sur SearchSoftwareQuality.com les grands principes qui ont prévalus pour le développement du navigateur de Google.
Même si le décor est planté dès la première phrase (« Nous n’avons pas spécifiquement utilisé la méthodologie Agile, nous avons juste fait appel à notre bon sens »), il est intéressant de voir que la méthodologie Agile et le bon sens selon l’équipe de développement de Google Chrome ont de nombreux points communs:

• Les équipes étaient auto organisées, chacun décidant des taches qu’il accomplirait.
• Le développement était organisé en sprints (longs) d’un trimestre, mais une version stable était mise à disposition des utilisateurs toutes les semaines.
• Le pilotage était réalisé via une liste de fonctionnalités (précises et minimalistes) ordonnée (incontournable, secondaire…), enrichie par les retours des utilisateurs (via une mailing list interne).
• Une grande partie du test a été automatisée.
• Dans une certaine limite, le développement a pu être distribué.

Google n’a visiblement pas systématisé son usage, mais utilise déjà Scrum sur certains projets, en particulier pour le développement de sa « cash machine », Adsense…
Jeff Sutherland a récemment donné une conférence sur Scrum dans les locaux de Google NYC

RIA

Framework RIA : où en est-on?

Il y a quelques jours, nous vous proposions un point sur les frameworks RIA à la suite d’un contest : Xebia RIA Contest.

Glen Lipka, designer Web, propose aussi un point sur l’état des frameworks RIA : RIA frameworks. Il est intéressant de comparer les deux points de vue, si nous sommes spécialistes Java (Xebia), Glen Lipka est designer Web.

Il existe d’autres comparatifs : par exemple JSF matrix qui compare différentes technologies Ajax qui peuvent être utiliser avec JSF.

Etant donné le profil technique de Glen Lipka, il a une préférence pour le framework JQuery. Il est vrai que JQuery apporte une solution simple et élégante au développement JavaScript :

• Syntaxe élégante et fonction utilitaire (appel ajax, effet ergonomique, …)
• Simplification de la manipulation de l’arbre DOM et de la gestion des événements DOM
• Système de plugin pour étendre le comportement de JQuery : manipulation en Ajax de formulaire, composants graphiques (Carrousel, animation, …)

JQuery est un bon compromis entre simplicité et puissance. Au prix d’une complexité supérieure, Ext-JS s’annonce comme une solution plus complète. Il existe d’ailleurs une version Ext-JS pour GWT : Ext-GWT. Il faut néanmoins une licence commerciale pour les applications propriétaires.

Il y a d’autres concurrents de qualité :

• Yahoo UI Library
• Dojo toolkit mais reste assez complexe
• OpenLazlo mais il est architecturalement compliqué et sa syntaxe freine aussi bien les Java-istes que les développeurs Web
• Technologies Rails : Ruby On Rails (ROR), Grails (Groovy) ou encore Django (Python) se base sur des concepts très pragrammatiques (« convention over configuration« , « don’t repeat yourself« )

Il y en a de toutes les couleurs dans les frameworks RIA :

• Avec/sans développement JavaScript
• Pour designer ou autre
• Dans des langages interprétés ou compilés (voir même intermédiaires comme GWT)
• Dans des technologies inexplorées (Ruby, Groovy, Python)

Le choix est difficile mais les solutions s’orientent vers :

• Un modèle de programmation simple et productif (selon les compétences des utilisateurs, c’est un point difficile car on est à cheval sur deux domaines (vastes) de compétences, le développement Web et le développement d’applications de gestion)
• Richesse des composants graphiques (qui est par exemple le point fort de Flex)
• L’intégration avec l’existant qui est souvent négligé dans les solutions comme le montre Ruby On Rails ou Grails même si elles ont un modèle de programmation très intéressant, ou à moindre mesure GWT.

Liens connexes :

• Discussions de cet article sur TSS : The Server Side

Le coin de la technique

EJB 3.1 se dévoile

Un peu plus d’un an après le lancement de la réflexion sur l’évolution des EJB 3.0, de nouvelles spécifications viennent d’être rendues publiques.
Toujours dans la droite ligne d’une simplification de l’utilisation des EJB, voici un aperçu des nouveautés les plus attrayantes :

• Les EJB locaux ne nécessitent plus l’utilisation d’une interface, une simple classe concrète suffit.
• Un sous ensemble allégé, les « EJB Lite » directement déployables dans un war (sont notamment exclus les Message Driven Beans, l’exposition Web Services et le remoting RMI/IIOP).
• Un nouveau type d’EJB Session vient de naître: le type Singleton, qui rappelle beaucoup les singletons Spring.
• Un mécanisme d’événement pour lancer des traitements au démarrage et à l’arrêt du conteneur EJB.
• Pour simplifier les tests unitaires, on peut désormais exécuter un conteneur d’EJB dans une simple JVM sans nécessiter de serveur d’application.
• Un accès JNDI global permet d’accéder aux EJB sans besoin de spécifier un descripteur de déploiement.
• Un EJB peut être invoqué de manière asynchrone.

Dans les spécifications de Java EE 6, il est souhaité que la réduction des « lourdeurs » de l’API EJB soit faite de la manière la plus douce pour les développeurs. Cette publication va dans ce sens, dans le sens d’une facilité d’utilisation qui s’approche du framework Spring.
Pour tout savoir sur cette publication, il faut consulter la JSR-318 et pour mieux comprendre, par l’exemple, la présentation de Kenneth Saks avère très utile.

Pour l’amélioration de la qualité, gérez vos dépendances

Kevlin Henney présente dans l’article Manage component dependencies for improved system quality un autre aspect de la QoS en développement logiciel qui est : la gestion des dépendances.

La gestion des dépendances permet de réaliser une application plus modulaire, donc moins monolithique. Quelques bonnes pratiques à suivre :

• Structurer le logiciel sous forme de module cohérent, défini, suffisant et distinct (Separation of Concern (Dijkstra))
• Identifier les impacts lorsqu’un module est modifié, et donc de mieux analyser les coûts et risques d’une modification sur l’ensemble du logiciel
• Mettre en place de bonnes pratiques de conception :
• Open Closed Principle (OCP) : Un module doit être ouvert aux extensions mais fermé aux modifications.
• Inversion Of Control (IOC) : Permettre l’isolation des modules. Les modules de haut niveau ne doivent pas dépendre de modules de bas niveau.
• Acyclic Dependencies Principle (ADP) : Le graphe des dépendances doit former un graphe acyclique.
• Stable Dependencies Principle (SDP), Stable abstractions Principe (SAP) : Un module doit dépendre de modules plus stables que lui, les modules les plus stables sont les plus abstraits.

Actuellement, il existe des outils pour gérer les dépendances au niveau librairie (Maven2, Ivy), pour réaliser une application modulaire, on applique une solution packaging.

Il existe d’autres types de solution : OSGi et Java Module (JSR 277). Dans ce cas, c’est une infrastructure de modules qui est utilisée pour exécuter les différents modules et former une application.

Pour le développement d’applications modulaires, il n’ y a pas encore de solution technique miracle, elle se repose fortement sur la bonne conception fonctionnelle et technique : la mise en oeuvre des principes avancés de conception objet.

Liens connexes :

• Design-up : Principes avancés de conception objet (PDF) : explication des principes OCP, IOC, ADP, SDP, SAP, …

Les dessous d’InfoQ

Alexandru Popescu, architecte en chef du site InfoQ, dévoile l’architecture du célèbre site d’information, qui culmine à plus de 300 000 visiteurs uniques par mois. De ce vidcast, nous retiendrons :

• InfoQ est une entreprise virtuelle, et elle utilise les méthodologies Agile pour son développement (dont un backlog long de sept pages, ce qui nous promet de très nombreuses évolutions)
• InfoQ est un CMS complet et fait maison. Le site est découpé comme une application trois tiers classique. Les API ‘utilisateur’ et ‘auteur’ sont quasi identiques et sont séparées durant la phase de build.
• L’application repose sur WebWork et DWR pour la navigation. Une API spécifique redirige la requête vers le framework ad-hoc (WebWork pour les requêtes classiques, DWR pour les requêtes Ajax). Cette API a été reversée dans le repository de DWR, et peut être utilisée avec Struts 2 par exemple.
• Au niveau Service, on a majoritairement du Spring ‘classique’
• Au niveau persistance, un mécanisme original, puisqu’InfoQ s’appuie à la fois sur Hibernate et JCR. C’est d’ailleurs le seul regret d’Alexandru Popescu, ne pas avoir une API de haut niveau qui permet à ses développeurs de s’affranchir du mode de stockage.
• Toute cette architecture repose sur une base MySql distribuée (une instance en lecture écriture, plusieurs autres instances en lecture seule). Les problèmes et temps de réplication sont insignifiants, et les performances d’un Hibernate ‘de base’ (requêtes non optimisées) suffisent à servir du contenu à tous les visiteurs.
• Dernier point, plus technique, le caching : un cache à 2 niveaux a été élaboré. Le premier, basique, utilise le cache d’Hibernate (ainsi que l’ensemble des mécanismes du framework, comme le lazy loading). Le second est un cache spécifique d’objets agrégés depuis les différentes sources de données (on n’en saura pas plus…)

En outre, dans l’interview, Alexandru Popescu aborde les problématiques de streaming. Nous vous invitons à consulter l’intégralité de ce vidcast, servie par InfoQ lui-même.