Depuis un peu plus d’un mois, Google a lancé un test grandeur nature (on parle de 100 000 bêta testeurs) de sa plate-forme de communication centralisée, Wave. Après une grande frénésie de chasse à l’invitation, le soufflet retombe peu à peu : on sent bien qu’il y a quelque chose à tirer de cet agrégat d’outils devenus ‘temps réel’, mais on ne sait pas encore quoi. On voit apparaître de nombreux prototypes (traduction temps réel, interfaçage avec des mobiles…), mais peu de choses très concrètes. Il faudra pour cela attendre d’atteindre une masse critique (si plusieurs entreprises décident par exemple de remplacer l’intégralité de leurs outils de communication par Wave) mais aussi compter sur la communauté pour explorer les possibilités d’extension de Wave et proposer des robots attractifs.

Malgré tout, l’outil de Google a attisé notre curiosité, principalement grâce à son architecture ouverte et à ses possibilités d’extension.

Trois protocoles, deux APIS

Google Wave Federation Protocol

C’est là tout l’intérêt et le cœur du produit de Google. En effet, grâce à ce nouveau protocole ouvert et standardisé, l’hébergement d’un serveur Wave peut se faire indépendamment de Google. Et c’est là le nerf de la guerre pour l’entreprise : contrairement à Google Docs, qui centralise les documents sur une plateforme hébergée chez l’éditeur, l’aspect ouvert du protocole de fédération entre serveurs Wave va permettre à chaque entreprise de garder la maîtrise sur ses Waves, et sur les documents qui les composent. Certains imaginent déjà la très belle utopie d’un client passant commande à son fournisseur via une Wave commune, gérant des processus complexes (passage de commande, envoi de devis automatisé, workflow humain de validation et facturation automatique…).

Si l’on s’intéresse d’un peu plus près à ce protocole, on constate qu’il s’agit d’une extension du protocole bien connu XMPP (précédemment nommé Jabber). Google s’est appuyé sur le mécanisme d’extension de ce protocole (XEP 114) pour renforcer en particulier la sécurisation des échanges inter-serveurs mais aussi l’authentification forte d’un utilisateur auprès de ses waves.

Schématiquement, ce protocole s’appuie sur des mécanismes de Gateway / Proxy. Chaque serveur possède une Gateway, qui s’occupe des modifications locales de chaque Wavelet hébergée. Cette Gateway pousse ensuite ces modifications vers les Proxys des autres serveurs participant à la Wave.

Ce protocole étant ouvert, vous pourrez trouver une documentation riche sur le site de Google, via le draft de spécifications et de nombreux white papers.

Et si vous voulez vous lancer dans l’expérience, Google propose, outre le serveur Wave servant à la bêta, un serveur prototype implémenté en Java.

Protocole client-serveur

Pour interagir avec une Wave, chaque participant doit s’équiper d’un client. Pour l’instant, il n’en existe qu’un seul, le client web créé par Google et disponible sur https://wave.google.com/wave/ (ou une des ses encapsulations, comme WaveBoard). Le protocole qui permet d’échanger avec le serveur Wave n’est pour l’instant pas encore spécifié, mais des tentatives en ce sens existent.

Le client web de Google est une application HTML 5, développée avec GWT. Il communique avec le serveur suivant un protocole GWT propriétaire, porté par HTTP.

L’espoir de standardisation du côté des clients est cependant tangible : la société ProcessOne a réalisé un client prototype basé sur XMPP.

API Robot et JSonRPC

Dernier protocole, et non des moindres, le protocole qui permet aux robots (pour les fans d’irc, on parle de bot) d’intervenir dans une Wave. Pour se faire, ils utilisent JSon-RPC, sur HTTP.
Ces robots fonctionnent sur une programmation événementielle. Ils sont donc à priori agnostiques vis à vis du langage. Il existe actuellement 2 API fournies par Google : une pour Java, que nous détaillerons dans un prochain article, et une pour Python.
Les robots peuvent interagir avec la Wave (ajout de participants, modification du contenu de la Wave, envois d’alertes) en étant déclenchés par des évènements internes à la Wave (arrivée d’un nouveau participant, publication de texte, déclenchement par mot clé).

API Gadget

Il existe une autre façon d’enrichir les fonctionnalités de la Wave : les gadgets. Les gadgets sont des briques de code (HTML + javascript), bien connus des utilisateurs de iGoogle, embarqués dans le client Wave. Ils sont similaires à ceux de l’API OpenSocial, même si curieusement celle-ci n’est pas officiellement compatible. La différence avec les gadgets statiques est que les gadgets Wave tirent profit de l’aspect ‘live’ de la Wave et peuvent interagir avec celle-ci. Ils comportent une gestion d’état, ont connaissance de l’utilisateur en cours de visualisation et des utilisateurs connectés et s’intègrent au mécanisme de playback.
Nous reviendrons là aussi plus en détail sur l’écriture de gadget.

Synthèse

Pour résumer ces différents protocoles, le plus simple est encore de les représenter sur un schéma.

source : J Aaron Farr

Avec des extensions correctement pensées et développées, Wave semble pouvoir être un énorme atout dans la communication interne de l’entreprise.
Alors, serez-vous les premiers à installer un serveur Wave en remplacement de votre bon vieil SMTP ?

La session Wicket initialement prévue Mardi matin ayant été annulée, j'ai assisté à la place à une présentation sur les effets Flex. Je pensais que je ne pouvais rien apprendre de plus à ce sujet, je me suis trompée : l'utilisation des effets a été simplifiée, et il est maintenant possible d'étendre les effets.

Qu'est ce qu'un effet ?

Flex 3

En Flex, il est possible de définir des effets pour des transitions ou lors du déclenchement d'un évènement (hide, show par exemple).
Nous allons reprendre l'exemple du Dissolve disponible sur le Flex 3 Component Explorer.
On commence par définir les effets :

Puis on indique au composant cible, l'effet qu'il doit utiliser lorsque l'on cache le label :

Dans Flex 3, il n'est pas possible de gérer des effets sur la valeur d'une propriété comme le texte ou la couleur par exemple. Les effets ne sont en effet applicables que sur les composants.

Flex 4

La nouveauté dans Flex 4 tient tout d'abord dans la définition d'une nouvelle super classe Animate qui vient remplacer TweenEffect. Cette nouvelle super classe fournit de nouvelles propriétés telles que easer, interpolator et motionPaths que nous verrons par la suite.

Dans cette nouvelle version, les effets sont plus flexibles et il est possible de :

• modifier la valeur des propriétés telles que le gradient d'une couleur ou la taille,
• régler la vitesse de l'effet, lui donner une accélération au début ou à la fin par exemple,
• déplacer plus facilement les composants lors d'un effet.

Les nouveaux effets

Les effets 3D

Parmi les nouveaux effets, voici probablement les plus impressionnants d'entre eux : les effets en trois dimensions. Grâce à Flash Player 10 qui est maintenant capable de représenter un objet 3D, on peut par exemple exécuter un effet de déplacement en profondeur ou une rotation.

La configuration des effets

Avec cette nouvelle super classe Animate viennent de nouvelles propriétés :

• easer : l'atténuation de l'effet (en quelque sorte une accélération ou décélération avec laquelle l'effet sera appliqué),
• interpolator : fonction utilisée par l'effet pour calculer les valeurs à prendre pour une propriété entre le début et la fin de cet effet,
• motionPaths : un vecteur contenant des objets MotionPath, chacun portant le nom et la valeur que la propriété peut prendre,
• repeatBehavior : permet de répéter l'effet.

Avec ces nouvelles fonctions, il est encore plus simple de réaliser des effets customisés comme par exemple un bouton qui s'enfonce lorsque l'on clique dessus, ou un changement de couleur lorsque le curseur pointe un composant. Maintenant à vous de laisser parler votre imagination.

Toujours sur le sulfureux sujet du Cloud Computing mais cette fois-ci côté PaaS (Platform as a Service), une session spéciale Google App Engine nous est proposée avec l'idée de développer une vraie application de gestion sur le cloud et de voir les difficultés rencontrées pendant le développement. Et pour corser le tout, 3 technos front-end seront en concurrence : Spring MVC, JSF 2.0 (très early adopter pour le coup) et GWT 1.7.

Le projet

Tout d'abord, la home page du projet Swag Swap se trouve à cette url. Elle regroupe toutes les informations utiles, les liens vers les différents projets par technos, un espace google-moderator pour poser des questions aux speakers (et réponses en live).

Fonctionnellement, le projet est un espace de vente d'objets divers et variés avec notation de ces objets, commentaires associés, etc. Côté administration, on pourra gérer les objets (ajouter, modifier ou supprimer) et avoir accès à d'autres fonctionnalités. On illustre ainsi GAE par un projet plus concret que le basique Helloworld. A gauche l'apparence de l'application GWT (single page interface) et à droite celle des applications Spring MVC et JSF 2.0 :

Fondamentaux

Avant de rentrer dans le vif du sujet, quelques rappels sur l'architecture de GAE nous sont faits. Ainsi, GAE est de type PaaS : aucune installation hardware ni d'infrastructure mainframe, tout est géré par Google qui hébergera notre application sur ses serveurs et la dimensionnera à l'infini si besoin (attention aux quotas ). La base de données utilisée est BigTable, base de données non relationnelle distribuée, scalable, transactionnelle et schema-less ; le tout accessible par les APIs JDO et JPA.

Les détails techniques sont tout de suite évoqués avec entre autres :

• des requêtes limitées à 30 secondes,
• pas de serveur push,
• pas de threads,
• un système de fichiers en lecture seule,
• des whitelisted classes (plusieurs classes du JDK non disponibles sous GAE),
• impossibilité de créer/mettre à jour plus d'une entité au sein d'une transaction.

Ces quelques lignes peuvent évidemment faire reculer violemment un développeur Java et c'est bien là l'idée de cette conférence : n'ayez pas peur ! La preuve : leurs applications fonctionnant sous GAE et sous 3 frameworks web différents ! Quelques adaptations sont néanmoins nécessaires.

Pour ceux qui souhaitent approfondir la persistance dans GAE,je vous renvois vers un précédent article qui traite parfaitement le sujet.

Implémentations

Côté architecture, on retrouve globalement ce que l'on connait déjà dans notre écosystème JEE à savoir :

• Spring 3.0,
• JDO,
• Une couche service partagée par toutes les applications,
• RESTful,
• Spring MVC / JSF 2.0 / GWT 1.7,
• Build, tests et déploiement avec Ant,
• Pour le debug, l'appengine development server pour SMVC et JSF et le Hosted Mode pour GWT,
• Gestion des projets avec google-code (issues, version control, release management).

Nous sommes donc en face d'une application 3-tiers standard. Les POJOs sont de simples POJO Spring. La couche DAO utilise un JdoTransactionManager mappé avec un PersistentManagerFactory connecté sur le datastore d'appengine (org.datanucleus.store.appengine.jdo.DatastoreJDOPersistenceManagerFactory).

La première chose qui saute aux yeux est bien sûr l'utilisation de JDO. Pourquoi ce choix (question du modérateur) ? Parce que la majorité des tutoriels s'appuie sur JDO. Il est tout à fait possible d'en trouver avec JPA mais ils sont globalement moins nombreux. D'où le choix de JDO. Avec toutes ces présentations Devoxx autour de JPA 2, cela surprend...

Nous nous retrouvons ensuite rapidement dans Eclipse avec de nombreux exemples de codes, d'injections, de configuration... La conférence prend rapidement un air de présentation de Spring MVC avec la configuration par annotations et entre autres les URI Templates de RESTful Spring MVC 3. Pour les habitués de Jersey, l'idée est la même (paramètres dans le path de l'URL) mais le nom des annotations change un peu. Voici un exemple d'utilisation :

Suivront ensuite quelques screenshots de l'utilisation de MemCache et d'envoi de mails avec Task Queue, la gestion de transactions, la gestion d'Entity Groups... Le tout est bien sûr testé unitairement. Nous passerons sur ces points, de nombreuses documentations existent un peu partout sur la toile.

Le tour complet est fait, mais maintenant on veut savoir...

Problèmes rencontrés

Bon alors, quels sont les problèmes que vous avez rencontrés ?

Et bien il y en aura eu, du simple à résoudre au plus complexe qui demande de bien écrire ses APIs ou de paramétrer légèrement sa configuration.

Côté back-end, la mise à jour d'une seule entité au sein d'une transaction peut évidemment poser de gros problèmes concernant l'insertion de nombreuses entités mais aussi concernant un rollback de transaction. Pas de réelle solution, à part programmer à la main un rollback sur des objets déjà commités.
Concernant l'impossibilité d'écrire sur le disque, la base de données contient un champs BLOB qui contiendra les images des articles à vendre.

Spring MVC a posé des soucis concernant quelques requêtes Ajax et surtout celles de rating qui requièrent un utilisateur logué. Dans ce cas, la page de connexion spéciale Google (au passage non configurable) apparaît et, une fois logué, la redirection se fait sans les paramètres d'URL. On perd donc le fait que l'on venait de voter pour un article ; nous avons donc cliqué dans le vide juste pour nous connecter.

Les gros problèmes concernant le frontend se sont plus focalisés sur JSF 2.0 (le pauvre...) avec quelques hacks autour de la classe WebConfiguration. Un problème s'est aussi posé concernant le state saving de JSF 2.0 côté serveur. Les scopes doivent être réduits à request et à view, le state doit être sérialisé dans le view scope et (enfin et non des moindre) RichFaces et ICEFaces ne peuvent pas être utilisés (whitelisted classes). Beaucoup de ralentisseurs donc mais qui n'ont pas empêché l'application d'être disponible et fonctionnelle à Devoxx.

Pour GWT, beaucoup de temps a aussi été investi pour brancher les services remotes sur Spring convenablement (avec P.G Taboada's AutoinjectingRemoteServiceServlet). Les problèmes majeurs rencontrés dans le développement de l'application GWT se situent au niveau de son protocole GWT-RPC et de l'impossibilité de sérialiser des types Text et Blob de BigTable. Gilead (anciennement Hibernate4GWT) aurait pu aider dans la gestion de ce mapping mais cela n'a pas fonctionné. La solution de contournement a donc été de créer des DTOs pour tous les spring beans ! De plus, ces DTOs, spécifiques à l'application ne sont pas compatible avec les tableaux SmartGWT. Il a donc fallu les copier dans les records SmartGWT... Tout fonctionne mais avec beaucoup de beans passe-plats, le tout n'étant pas très automatique.

Conclusion

Au final, l'application Spring MVC, couche service incluse, n'aura pris que 3 jours à être codée. Alors que pour JSF 2.0 et GWT 1.7, on est plutôt sur 2 semaines chacun et uniquement pour la partie frontend (couche service partagée). La rapidité d'écriture est donc clairement à l'avantage de Spring MVC (pour cette application). JSF 2.0 a été très retardé par ses incompatibilités avec GAE alors que GWT aura péché par sa difficulté d'intégration avec Spring, les problèmes liés aux échanges RPC et Gilead qui n'a pas fonctionné.

Que peut-on réellement en tirer ? Premièrement les 3 frameworks, même si ce fût dur, fonctionnement correctement sur GAE, si on fait abstraction des quelques Errors qui apparaissaient de temps à autre sur le grand écran. On pourra mettre ça sur le dos du wifi de Devoxx qui ne monte pas très bien en charge .

Parmi les liens utiles, on notera la recherche sur google de "Will it work on app engine" qui donne en premier résultat un site listant de manière assez complète les librairies et leur compatibilité sur GAE : http://groups.google.com/group/google-appengine-java/web/will-it-play-in-app-engine mais aussi le GAE Bar http://aralbalkan.com/1784.

Une des sessions très attendues de ce Devoxx 2009 (avec JEE6) est JSF 2.0. Beaucoup de spécificités de JSF premier du nom ont découragé de nombreux développeurs. De ce fait, JSF n'a pas très bonne réputation... Et il faut rattraper ça ! C'est en tout cas ce qui ressort des premiers slides de cette présentation avec l'accroche choc : JSF 2.0 : it is not only us, it is you too !

Car oui : JSF 2.0 annonce la couleur et souhaite faire participer la communauté. Dans cet esprit, les speakers nous présentent le topic twitter #jsf2next pour partager autour des évolutions futures de JSF, souhaitées ou non. Ils enchaînent ensuite avec un trombinoscope de toutes les personnes qui se trouvent derrière JSF 2.0 (on reconnaîtra quelques visages au passage) :

L'aspect communautaire sera rappelé tout au long de la session et on sent vraiment que JSF met le paquet pour être apprécié des développeurs. Les speakers insisteront beaucoup sur le tag JSF2.next avec des slides spécifiques pour donner quelques idées internes ou remontées par la communauté pour (déjà) améliorer JSF 2.0.

La présentation fût découpée en 3 parties : Vue, Contrôleur et Modèle (approximativement 1h pour chaque partie), ce qui nous donne ainsi un bon aperçu de tous les changements de chaque couche du MVC. Une session de BOF spéciale JSF 2.0, qui a eu lieu le soir même, apportera quelques précisions sur certaines fonctionnalités non évoquées lors de la conférence.

Vue

Premier rappel côté Vue et déjà quelques tacles à la gorge : JSP avec ses points faibles (dont certains sont assez discutables...) :

• la complexité de développer une librairie,
• l'état stateful des tags qui impose de faire des appels à release sur les objets tags pour les réinitialiser,
• l'obligation d'une phase de compilation lors du premier affichage,
• le mélange de la présentation avec la couche métier
• le fait que JSP soit orienté contenu (et non composant).

Facelets arrive ainsi avec ses XHTML tags, stateless par défaut, des librairies plus simples à développer, du templating et plus de compilation Java. Et, première bonne nouvelle pour les fans de Facelets, la librairie est incluse dans la spécification avec les mêmes fonctionnalités et quelques améliorations. Elle inclura aussi Gracelets (Groovy pour JSF / Facelets).
La présentation se focalise ensuite sur un des points noirs de JSF : la création de composant... Vous savez, les composants pour lesquels il faut coder un UIComponent, un Renderer, tag/tld, le (ugly) faces-config.xml...

La création de composants est simplifiée dans JSF 2.0 : soit en utilisant les annotations et le fichier taglibs.xml (configuration ainsi simplifiée) soit les Composite Components, une des grosses nouveautés de cette version. Nous avons ainsi les tags composite:interface et composite:implementation pour définir le composite et l'implémentation.

Ces composites sont accessibles directement dans la webapp ou dans un JAR, avec la possibilité d'ajouter des listeners et converters, de plugger un resource bundle...

L'Ajax n'est pas en reste avec un composant embarqué dans JSF 2.0 : jsf.ajax.request(), utilisable par le tag <f:ajax> qui peut-être soit nested soit wrapping.

Contrôleur

Comme la plupart des frameworks web du moment (Wicket pour ne citer que lui), JSF 2.0 pourra enfin se targuer de supporter... GET (pas de sarcasme svp ) ! La conséquence directe est que nous allons enfin pouvoir bookmarker nos URLs. Un exemple avant/après :

Côté événement, le nouveau SystemEvent fonctionne en mode publish/subscribe avec des événements de type PostAddToViewEvent (après la création du composant) et PreRenderViewEvent (avant le rendering du composant).

Une autre partie intéressante est la gestion des ressources dans l'application avec 2 possibilités de récupération selon que la ressource soit présente dans un dossier de la webapp ou dans un JAR :

Modèle

Pour la partie modèle, ce sera surtout une présentation des différentes technologies JEE 6 avec leur intégration dans JSF 2.0 : Managed Beans (partie de JSR-316), Contexts and Dependency Injection (JSR-299), Bean-Validation (JSR-303) et JAX-RS (JSR-311).

Outre les fameuses annotations @Inject (CDI) et @Named (EL), la présentation fera la part belle à Bean-Validation avec l'ajout d'une annotation au niveau de notre POJO qui validera côté Data, Business mais surtout, ce qui nous intéresse, Client.

On se retrouve donc avec les exemples suivants qui sont nativement gérés par JSF 2.0 dans nos pages JSF :

Il sera toutefois possible, côté JSF, de désactiver certaines validations, soit par paquet soit au cas par cas.

A noter une bonne gestion du null dans un champ (null ou String vide) avec la possibilité de valider ou non le champ si une annotation Bean-Validation est présente ou si le context-param suivant est présent :

Mais, il est aussi possible de forcer le champ vide à null avec le paramètre assez explicite suivant :

Dernier point abordé, la validation multiple avec plusieurs approches :

• Avant la construction du modèle avec un test de tous les champs sur un événement PostValidateEvent ;
• Après la construction du modèle avec Bean-Validation (mais un objet a déjà été construit... à vous de vous faire votre idée).

BOF

Au niveau des sujets esquivés en conférence, quid d'un projet comme Spring Web Flow pour la gestion d'un flow de page qui est supporté par Seam mais pas par JSF ? Une des réponses est que le projet est plutôt complexe et mériterait peut-être une spécification plus globale pour définir ce qu'est un flow de page, les événements autour de ce flow... Il n'en reste pas moins que JSF 2.0 supporte parfaitement le mode Stateless mais pour l'instant le Stateful ne l'est pas...

Au niveau des tags ajax embarqués, il devrait être assez simple de brancher un jQuery ou un Script.aculo.us sur JSF 2.0 et profiter d'une expérience Ajax complète. Reste à voir l'intégration avec des Composite Components.

Conclusion

Une présentation très rythmée avec beaucoup de slides (peut-être trop) qui ne laissent donc que très peu de temps pour la prise de note. Dommage car certains sujets, non évoqués dans cet article, auraient aussi mérité leur place. Mais ce n'est que partie remise pour un prochain article !

En tout cas, force est de constater que JSF 2.0 tend vraiment à une simplification d'utilisation, orienté annotation et zero-XML. Des Composite Component simples à écrire, une intégration gracieuse avec Bean-Validation... en bref, beaucoup de bons points !

Après un petit café revigorant, voici déjà venir les premières sessions de l'édition 2009 de Devoxx et, le sujet de cet article, Kanban in action par Olav Maassen.

Après un petit rappel sur les origines du mot (qui en kanji signifie kan=visuel et ban=tableau, carte, fiche), le deuxième slide donne le ton de cette conférence qui sera interactive (plusieurs travaux pratiques sur les 3h) avec une première question : donnez quelques exemples quotidiens de système Kanban. Plusieurs réponses affluent dont :

• le parking avec un flux de voitures entrantes bloqué si toutes places du parking sont pleines ;
• la toilette des enfants avec une baignoire qui ne contient qu'un enfant à la fois (dès qu'un enfant a terminé, l'autre prend sa place) ;
• le speaker retiendra Mac Donalds (et oui) avec la gestion du stock de burger disponible : une pancarte métallique qui, une fois déplacée au dessus des rails de burgers vides, signifie qu'un burger n'est plus disponible, il faut alors en produire.

Ces exemples tournent autour de 2 principes : la capacity constraint (par exemple une autoroute, toujours disponible mais dépendante du flux) et la non-instant availability (par exemple un ferry qui une fois en mer n'est plus disponible). Un des principes du Kanban est de rendre certaines choses visuelles : voir l'indisponibilité de hamburgers marqués par un token en est un bon exemple.

Les freins

La présentation se focalise ensuite sur les mauvaises pratiques de nos projets d'entreprise faisant que Kanban sera difficile à mettre en place.

Les projets avec deadline (surtout quand celle-ci se rapproche) ont fait débat dans la salle. Pour les conférenciers, les mauvais choix qui peuvent être faits par l'entreprise sont : le report du projet, engager plus de personnes ou faire beaucoup d'overtime Et quel que soit le cas, des choix malheureux risquent d'être faits : ne plus rédiger les spécifications, réduire voire supprimer les tests unitaires, privilégier la vitesse de production à la qualité du code (tout ceci dans un but de gain de temps) ! Vous l'aurez compris, et ce n'est pas forcément spécifique à Kanban, nous sommes ici en présence de mauvaises pratiques reconnues et difficilement récupérables par la suite.

Pour rester dans les mauvaises pratiques, Olav nous propose un TP, comment construire ou détruire la confiance dans une équipe. Cacher de l'information, manquer de confiance en l'équipe, ne pas donner de responsabilité à l'équipe... La destruction est assez facile à illustrer, la construction ressortira surtout de l'implication de l'équipe dans le projet et les décisions.

Une petite comparaison orale (pas de trace !) avec Scrum ou Lean nous permet de constater qu'il n'y a pas de planning poker ou de session d'estimation. En effet, cela ne représente pas une valeur fonctionnelle métier pour le client (<troll>c'est du temps perdu !</troll>). Au niveau des réunions, et plus particulièrement le stand-up meeting, les 3 questions habituelles de Scrum sont remplacées par un bref regard global sur le tableau afin de voir si tout se passe bien. En général, voir s'accumuler des post-it dans une colonne n'est pas bon signe et c'est ici que l'équipe intervient et que le stand-up devient plus animé.

Kanban à la rescousse !

Le décor est planté, la salle a les idées claires sur ce qui va, ne va pas ou peut encore être amélioré sur nos projets, il est grand temps de présenter formellement le sauveur Kanban (avec au passage un bon article de présentation sur InfoQ). Kanban insiste sur plusieurs points :

• la qualité,
• réduire le work in progress, livrer le plus possible,
• équilibrer demande / livraison,
• prioriser,
• réduire les variables et améliorer les processus.

Les étapes de mise en place sont résumées ainsi :

• s'accorder sur les objectifs,
• définir la value stream mapping (analyse des flux de besoins),
• définir des inputs de contrôle,
• définir le done,
• définir un set de tâches de travail,
• rencontrer les parties prenantes du projet (amont et aval),
• créer votre tableau Kanban (Kanban board) qu'il soit physique ou électronique (idéal pour les équipes distribuées).

A cela, il est possible d'ajouter différentes métriques telles que le Work In Progress, la qualité de code, la durée moyenne des tâches, le temps perdu (obstacles, bugs, manque d'information...).

Tout comme Scrum, Kanban arrive avec plusieurs bonnes pratiques mais ne pourra pas résoudre certaines lacunes comme un manque total de communication dans l'équipe, ou une organisation qui freine les changements... Dans un souci d'amélioration continue, Kanban propose plusieurs étapes afin de résoudre les fameux bottleneck du Lean (trouver la contrainte, définir une résolution possible, appliquer, trouver la contrainte suivante).

Conclusion

Tout ceci (qui ressortira plusieurs fois durant la présentation) a pour but d'obtenir les effets positifs suivants : confiance (Trust), travail d'équipe (Teamplay), transparence (Transparency).

Plusieurs questions sur la difficulté de mise en place de Kanban sont posées lors du Q&A de fin de session. Le speaker insiste sur le fait qu'en effet cela n'est pas trivial, mais les gains sur le long terme sont plus qu'avantageux.

Quelques liens pour approfondir ce sujet:

• http://www.agilemanagement.net
• http://www.channelkanban.com
• http://www.limitedwipsociety.org

Amazon Elastic Compute Cloud (aka EC2), et de manière générale les Amazon Web Services, ont attiré l'attention de nombreuses personnes pour la flexibilité de déploiement qu'ils permettent.

Cette plate-forme de Cloud Computing a recourt à la virtualisation pour créer à la demande des instances de serveurs directement utilisables. Il s'agit donc d'une approche totalement différente des hébergements traditionnels.

Lorsque l'on parle d'EC2, il est souvent question du déploiement de sites Web de type réseaux sociaux pouvant connaître de grands pics de trafic imprévisibles. On met alors en avant l'élasticité de configuration qu'apporte EC2, par définition. En revanche, il est rarement question des problématiques de haute disponibilité ou des bonnes pratiques à suivre pour les déploiements d'architectures multi-tiers classiques.
De même, au-delà de l'élasticité, les justifications du déploiement sur EC2 sont en général peu abordées.

Chris Richardson, créateur de CloudFoundry (récemment racheté par SpringSource), nous a offert une présentation très complète sur l'ensemble de ces sujets rarement abordés autour des Web Services d'Amazon.

Le choix d'EC2 pour le déploiement d'applications Web

Le déploiement d'une application Web sur EC2 se justifie par les avantages suivants :

• Mises en production simplifiées et moins sujettes aux erreurs humaines,
• Possibilité d'effectuer des snapshots de l'état d'un serveur à un instant donné, de le sauvegarder pour le restaurer plus tard en cas de défaillance,
• Réduction des tâches de maintenances par rapport à un hébergement interne à l'entreprise (cet avantage peut être invoqué pour tout type d'hébergement externalisé),
• Coût réduit dans certains cas.

Le système de facturation particulier d'Amazon fait que le coût total de possession peut être avantageux dans une configuration connaissant des pics de trafic importants.

La mise en production est quant à elle simplifiée par la possibilité d'effectuer un déploiement préliminaire sur un clone de l'environnement de production : on double alors le nombre d'instances utilisées. Une fois le déploiement terminé, testé, et validé, il suffit de diriger le trafic vers l'infrastructure clone puis d'éteindre l'infrastructure initiale. On reproduit ainsi le mécanisme de double buffer utilisé en programmation graphique.

En contrepartie, EC2 possède certaines limitations :

• Coût supérieur à un hébergement classique pour les instances utilisées 24x7,
• Impossible, actuellement de créer des instances de taille très importante (taille mémoire maximale de 68 Go, ce qui peut être limitant pour les très grosses bases de données),
• Absence de stockage à accès rapide : on ne trouve pas sur EC2 d'équivalent à RAID SAS / SCSI,
• EC2 ne dispose pas de la certification PCI requise pour les paiements électroniques.

Architecture haute disponibilité sur EC2

Les applications Web Java EE fonctionnant sur des middlewares comme Tomcat nécessitent un déploiement en cluster pour assurer leur haute disponibilité en cas de faille de l'un des nœuds. Pour des raisons de performance, de flexibilité de configuration, ou pour d'autres contraintes techniques (nécessité d'une gestion particulière des sticky sessions, gestion de la compression deflate/gzip, mise en cache, environnement Web hétérogène, ...), il est courant de mettre en place des serveurs frontaux Apache assurant un load balancing. Ces serveurs Apache sont alors eux-même précédés d'un load balancer afin d'exposer une IP unique aux visiteurs.

Chris Richardson nous montre alors que ce type de configuration est tout à fait réalisable avec l'infrastructure d'Amazon. Il prend alors la forme suivante :

Sur EC2, chacun des tiers de cette architecture soulève des problématiques distinctes.

Apache et load balancing

Amazon fournit un mécanisme de load balancing clé en main : l'Elastic Load Balancing. Ce répartiteur ne propose malheureusement pas d'affinité de session. Si une telle fonctionnalité est nécessaire pour le bon fonctionnement de l'application, il sera nécessaire d'avoir des serveurs Apache sur EC2 configurés avec mod_proxy en mode balancer. Ces serveurs seront alors accédés par Elastic Load Balancer.

Si l'on souhaite augmenter ou diminuer dynamiquement le nombre d'instances Tomcat utilisées, il est nécessaire de mettre à jour le balancer en amont pour le prévenir de ce changement de topologie. Une telle synergie existe nativement entre EC2 et Elastic Load Balancing, malheureusement ce n'est pas encore le cas avec Apache (le récent JBoss mod_cluster et les prochaines versions de mod_proxy_balancer améliorent la situation).

Tomcat

La couche applicative est susceptible de rencontrer des problèmes de compatibilité avec EC2. En effet la topologie réseau particulière d'EC2 rend le multicast impossible. Par conséquent, l'ensemble des frameworks utilisant le multicast pour découvrir leurs voisins ne pourront fonctionner.

Cette limitation peut être contournée, mais nécessite des développements dédiés. Il s'agit de mettre en place un registre en se basant sur les services d'AWS pour découvrir les instances démarrées ou en utilisant JGroups over TCP.

Le provisioning dynamique des instances EC2 dédiées aux serveurs applicatifs peut se faire via le mécanisme Amazon Auto Scaling (bêta). Là encore, des limitations doivent être prises en compte :

• Afin de déterminer si le nombre d'instances doit être augmenté ou réduit, Amazon Auto Scaling repose sur les web services Amazon CloudWatch qui retournent des métriques bas niveau sur les instances EC2 (CPU, mémoire, réseau, I/O). Il n'est pour le moment pas possible de suivre les métriques applicatives via JMX par exemple,
• Les instances doivent être capable de s'auto-configurer au démarrage pour offrir in fine un service Tomcat fonctionnel,
• Comme noté précédemment, les instances doivent s'enregistrer elles-même auprès des serveurs Apache.

MySQL

MySQL peut être déployé sur une instance EC2 sans difficulté. Le stockage peut se faire sur le disque local ou sur Amazon Elastic Block Storage (EBS) selon les besoins en latence ou en fiabilité avec des backups réguliers sur Amazon Simple Storage Service. Toutefois, afin de limiter les tâches d'administration qui peuvent aller à l'encontre de la logique d'externalisation, il est possible d'utiliser le très récent Amazon Relational Database Service.

Ce service offre un stockage MySQL dont l'administration est à la charge d'Amazon. Les bases de données MySQL sont alors stockées sur EBS.

Traitement de batchs

Si l'application Web déployée sur EC2 doit effectuer beaucoup de traitements lourds, il peut être souhaitable de dédier des instances à cette tâche. Ces workers recevront alors des tâches à traiter via une file SQS (Simple Queue Service).

Dans le cas où il serait intéressant de faire évoluer le nombre de workers dynamiquement, il est possible de démarrer de nouvelles instances et de les laisser consommer des tâches sur la file d'attente SQS.

Chris Richardson donnait ainsi l'exemple d'un site gérant des photos et ayant besoin de générer des aperçus après upload. Dans cette situation, il est intéressant d'adapter le nombre de workers à la charge du moment sujette à de fortes variations au cours de la journée. La figure suivante illustre cette configuration, les données d'entrée et de sortie du traitement étant ici stockées sur S3 :

Problématiques de sécurité

La sécurité est probablement la principale crainte avec le Cloud Computing. Avec AWS plusieurs solutions existent pour adresser cette problématique :

• Définir des security group réunissant l'ensemble des instances d'une même couche ; n'autoriser les communications qu'entre les groupes susceptibles de communiquer ensemble ainsi que les communications SSH provenant des équipes d'administration
• Renforcer au besoin cette stratégie par la mise en place de configurations IPTable locales

En outre, en raison de l'échelle mondiale d'Amazon, une difficulté supplémentaire est qu'il n'est pas possible de savoir dans quel pays sont stockées les données, ce qui peut être problématique dans certaines situations.

Un nouvel élément de l'offre Amazon pour satisfaire les besoins de sécurité de ses clients est le récent Amazon Virtual Private Cloud qui permet de connecter des serveurs Amazon EC2 directement au réseau privé d'une entreprise grâce à un VPN plutôt que de les connecter à l'Internet. On obtient alors une topologie similaire aux Wide Area Networks qui relient les différents continents dans les systèmes d'information des grandes multi-nationales.

Enfin, il est bon de noter qu'Amazon garantit que l'ensemble des données stockées sur les disques locaux seront effacées avant la ré-attribution de l'instance à un autre utilisateur.

Intégration des Amazon Web Services aux applications

Jusqu'ici il était question d'adapter EC2 aux principes d'architectures classiques. Chris Richardson insiste ensuite sur la possibilité de tirer parti des services proposés nativement par la plate-forme Amazon Web Services.

Stockage de fichiers avec S3

Les instances EC2 disposent toutes d'un stockage local. Toutefois, ce stockage est éphémère par nature puisqu'il est perdu dès que l'instance est éteinte (suite à une opération volontaire, ou à une défaillance matérielle).

Simple Storage Service (S3) fournit un service de stockage à distance dont la fiabilité est assurée par Amazon. Les opérations de création, lecture, écriture, et suppression se font par une API REST.

Dans ce contexte, les applications déployées sur Amazon EC2 ont intérêt à utiliser directement ces possibilités plutôt que de continuer à s'appuyer sur le stockage local en tablant sur sa fiabilité ou en laissant un script tiers assurer le backup régulier sur S3. On notera toutefois que S3 ne permet pas de reprendre un upload interrompu ce qui pourra se révéler gênant avec le transfert de gros fichiers.

L'API JetS3t permet d'accéder simplement à S3 depuis une application Java.

Persistance de données avec SimpleDB

Amazon Simple DB est une alternative intéressante au déploiement d'une base de données relationnelle telle que MySQL. Nous noterons que SimpleDB offre désormais le choix d'une localisation en Europe.

Il s'agit d'une base de données non relationnelle, sans schéma et adoptant les préceptes du NoSQL. Ainsi, il n'est pas possible d'effectuer des jointures, des transactions, ou de définir des verrous.

Les applications peuvent s'y intégrer en utilisant l'API SOAP ou REST. L'absence de jointure doit être comblée par une dé-normalisation et une duplication de certains éléments dans le modèle de données. Enfin, de par sa nature, il est préférable de paralléliser les lectures sur SimpleDB, afin de bénéficier d'une latence améliorée par rapport aux invocations en série.

Les applications Java peuvent utiliser Typica pour accéder à SimpleDB ou encore SimpleJPA qui propose une implémentation JPA pour SimpleDB.

Amélioration des performances avec CloudFront

CloudFront est la solution de Content Delivery Network (CDN) d'Amazon. Elle s'intègre naturellement avec S3 en permettant d'enregistrer simplement un bucket auprès de CloudFront afin que ce dernier assure la diffusion de son contenu.

CloudFront dispose de serveurs de proximité aux États-Unis, en Europe et en Asie.

La question du Platform as a Service (PaaS)

En fin de présentation, Chris Richardson aborde la question du Platform as a Service (PaaS). Google App Engine et Microsoft Azure proposent déjà des solutions intéressantes pour le déploiement d'application.

Il remarque par contre que ces systèmes ne sont pas très flexibles et imposent beaucoup de contraintes : limitation à 30 secondes pour une requête chez Google, fonctionnalités limitées rendant de nombreux frameworks incompatibles, ...

En toute logique, compte tenu de son affinité à CloudFoundry, il suggère alors de le considérer comme une opportunité afin de profiter de la plus grande flexibilité qu'il offre face à la solution de Google.

Conclusion

Chris Richardson nous a présenté ici l'ensemble des problématiques liées à une utilisation professionnelle et réaliste d'EC2 et d'AWS.

On ne peut que saluer l'orientation résolument ni commerciale ni élogieuse de son discours permettant de mieux saisir les enjeux d'EC2 pour l'entreprise.

Questionné au sujet des perspectives de résolutions des différents problèmes qu'il a pu décrire, Chris Richardson nous a fait remarquer que SpringSource était dans une situation confortable pour s'y attaquer puisqu'ils comptent dans leurs rangs des commiteurs Apache et Tomcat. Ainsi, on peut se laisser aller à imaginer un ensemble d'adaptations de mod_proxy ou de Tomcat pour mieux supporter l'infrastructure dynamique particulière d'EC2.

La première journée de Devoxx fut l'occasion pour Adobe de présenter lors de leur université leur nouvelle plateforme Flash. Pour cette présentation, quatre évangélistes Flex se sont relayés pour nous présenter ces différents produits Adobe :
- Christophe Coenraets
- Chet Haase qui travaillait anciennement sur JavaFX
- Serge Jespers
- Maarten Arten

La plateforme Flash : qu'est ce que c'est ?

Cette plateforme Flash est composée de :

• La gamme Creative Suite (avec Fireworks, Photoshop et Illustrator) destinée au designer.
• Flash Catalyst qui permettra de générer une application Flex à partir des maquettes réalisées avec les outils précédents.
• Flash Builder 4 pour le développement du reste de l'application et de son backend.

Flash Catalyst

Pour rappel Flash Catalyst est un outil permettant à partir d'un dessin réalisé avec les outils de la gamme Creative Suite de générer une véritable application Flex sans toucher à une ligne de code. Cet outil est capable de générer tous les composants graphiques disponibles dans Flex 4 et gèrent également les itemrenderer. Les effets et les transitions peuvent être également gérés avec cet outil. Lors de la session Tools In Action, une démonstration bluffante d'environ 30 minutes a été effectuée avec cet outil. Il y a cependant quelques conditions pour que la génération s'effectue au mieux :

• Penser à bien séparer ses filtres et à les nommer proprement. Ceci afin que l'intégrateur puisse plus aisément les récupérer et les convertir en composant Flex.
• L'intégrateur doit aussi bien nommer les composants une fois créés afin que le développeur puisse les exploiter plus facilement.

À la fin de cette courte session, nous avons pu voir le résultat : une application Flex reprenant la maquette de départ.

Flex 4

Cette nouvelle plateforme ne peut être utilisée qu'avec Flex 4. En effet, la nouvelle librairie de composants graphiques spark qui vient remplacer l'ancienne (que l'on nomme halo ou mx aussi) proposent de séparer l'aspect du composant de son comportement. Un billet a déjà été écrit à ce sujet. C'est ce qui permettra à Catalyst de générer l'aspect des composants. Le développeur quant à lui ne se préoccupera plus que des comportements du bouton tels que le traitement des données, la gestion des événements et le traitement avec le backend. Les composants peuvent également supporter les formes primitives (rectangles, ronds, carrés), les bitmaps, les textes riches et les vidéos. Autre nouveauté dans ce nouveau SDK, une nouvelle structure du code : les déclarations des HTTPService et autres RemoteObject s'effectuent dans les balises <fx:Declaration>.

Spring BlazeDS Integration

Parmi les nouveautés, nous noterons la présentation de Spring BlazeDS Integration. Avec moins de configuration que BlazeDS, il est possible de mettre en place plus facilement un backend utilisant Spring. Grâce à des annotations, il est maintenant plus simple d'exposer ses services à la partie cliente.

Exemple :

On expose contactService à la partie cliente. Côté Flex, il n'y aura plus qu'à simplement appeler ce service grâce au RemoteObject. Concernant le lien client-serveur, Christophe Coenraets soulève un point intéressant : actuellement il est impossible pour le compilateur Flex de reconnaître les services exposés côté serveur. Effectivement, à ce niveau là le compilateur doit croire le développeur et ne possède aucune réelle visibilité. C'est pour cela que dans Flash Builder 4 a été ajoutée la possibilité de réaliser de l'introspection sur les services exposés côté serveur. Fonctionnant avec BlazeDS, LiveCycle Data Service ES et AMF PHP, Flash Builder est donc maintenant capable de reconnaître ses services et de les importer côté client.

Model Driven Development dans FlashBuilder

Une autre nouveauté dans FlashBuilder 4 est une nouvelle vue nommée Data Models permettant de réaliser des modèles de données et de les générer autant côté client que côté Serveur. Cette partie sera davantage détaillée dans la session de Jeudi : Model Driven Development using Adobe Flash Builder 4 and LiveCycle Data Services ES.

La présentation était réussie et les démonstrations très bluffantes. Flash Catalyst semble mature et Flash Builder 4 répond mieux aux besoins des développeurs (il est enfin possible de faire un Generate getter/setter sur une propriété !). Mais on attend toujours la release qui est maintenant prévue pour mi-2010 voire même un peu après.

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

Actualité éditeurs / SSII

• Innovation permanente chez Google
• Java SE 5 en fin de vie, JDK 7 en approche

SOA

• 10 mythes au sujet des SOA

Evènements de notre communauté en France et à l'étranger

• Soirée Google au LyonJUG

Actualité éditeurs / SSII

Innovation permanente chez Google

Google est encore une fois au cœur de l'actualité cette semaine avec la mise à disposition d'un nouveau langage de programmation et d'un protocole destiné à remplacer HTTP.

Le langage Go est à la croisée de C, Java et Pascal et est annoncé comme ayant des performances proches du C. Go se distingue par le fait que son compilateur produise directement du code natif, et qu'il ne requiert donc pas de machine virtuelle. Il apporte toutefois un ramasse-miette et un ensemble d'abstractions permettant de simplifier la programmation parallèle.

Très rapidement, plusieurs opinions et résultats d'expérimentations sont apparus. Ainsi, Tim Yang montre les performances obtenues par une application serveur développée en Java (en utilisant Mina), C (avec Nginx) et Go. Les résultats qu'il obtient montre que Go est en retrait par rapport aux deux autres solutions. Ces résultats doivent toutefois être relativisés par la maturité acquise par le système d'entrée / sortie de la JVM, le design très performant offert par Mina, la réputation de performance de Nginx et enfin, bien sûr, par le stade embryonnaire de Go.

Google a également diffusé les spécifications de SPDY (prononcer Speedy), un protocole visant à remplacer HTTP. On le sait, HTTP n'est pas adapté au Web moderne. En particulier il n'est pas optimisé pour obtenir une latence minimale. SPDY ne redéfinit pas tout, il se base sur HTTP et y ajoute un ensemble de possibilités supplémentaires telles que la compression d'en-têtes, le multiplexage de flux ou encore la priorisation de requêtes.

Des tests sur le transport du contenu des sites Web les plus populaires, permettent à Google d'annoncer un gain moyen de 55%.

L'entreprise américaine continue donc d'impressionner par son innovation permanente, n'hésitant pas à remettre en cause régulièrement des technologies considérées comme incontournables.

Java SE 5 en fin de vie, JDK 7 en approche

Sur la page dédiée à J2SE 5.0, Sun notifie depuis début novembre les utilisateurs de l'arrivée en fin de vie (End of Service Life) de cette version de Java.

Arrivé il y a 5 ans, Java 5 avait constitué la mise à jour la plus importante de la plate-forme et de son langage depuis sa création. Son adoption en entreprise fut longue, mais s'est concrétisée au fil du temps. Ainsi aujourd'hui, on ne compte plus qu'une minorité de projets fonctionnant encore exclusivement avec la version 1.4 ou inférieure de Java.

Il en est tout autrement pour Java 6.0. En effet, contrairement à la version 5.0 dont l'adoption était indispensable pour profiter des technologies d'entreprise les plus récentes, les principales motivations pour passer à la version 6.0 concernent la JVM elle-même et les améliorations qu'elle a connue.

L'arrivée en EOSL pourrait accélérer les choses dans certaines entreprises, tandis que d'autres préfèreront se tourner vers l'offre Java for Business de Sun qui permet de continuer de bénéficier du support de l'éditeur.

Une autre possibilité pourrait se trouver dans l'arrivée de JDK 7. En effet, la roadmap du projet promet un début de phase Release Candidate débutant à la fin du premier trimestre 2010 pour une durée d'un à deux mois, ce qui permettrait donc l'arrivée d'une version finale dans 6 mois. Si la confiance dans les dates de finalisation annoncées de JDK 7 s'est évaporée au fil des reports successifs, la situation semble maintenant se stabiliser : Mark Reinhold vient d'annoncer la disponibilité de la M5 de JDK 7, en accord avec le calendrier prévisionnel de la roadmap. Quatre des fameuses évolutions du langage apportées par le projet Coin y sont implémentées et peuvent donc être d'ores et déjà testées.

SOA

10 mythes au sujet des SOA

Yefim Natis, de Gartner, a exposé durant l'évènement SOA in Action, dix mythes communs (et la réponse qu'il faut leur apporter) sur la mise en place d'une SOA.
Là où l'article porte à sourire, c'est que, pour une fois, la faute est partagée : cinq de ces mythes sont propagés par les fanatiques de la SOA, et sont mis en regard de cinq autres portés par les allergiques.

Pour les fanatiques, nous avons :

• Les services sont portés par l'IT et propagés vers les acteurs fonctionnels.
  Pour Yefim Natis, une SOA est un moyen pour l'IT de mieux comprendre et appréhender les problématiques métier.
• Les plate formes orientées services reposent sur des briques pré-fabriquées.
  Les SOA ne reposent pas uniquement sur des applications 'services', mais aussi sur des batchs et des applications héritées.
• Partager et réutiliser sont les principaux apports d'une SOA.
  C'est en effet un des bénéfices attendus, mais c'est loin d'être le seul. On peut citer : meilleure exploitation, meilleure montée en charge ...
• Mettre en place une SOA permet de s'abstenir de réaliser une phase d'intégration.
  Même si la SOA permet d'introduire une stabilité dans les interactions entre services, elle ne dispense pas de réaliser de vrais tests d'intégration, bien au contraire.
• Une SOA réduit les coûts du SI.
  Sur le long terme, peut être ... Mais dans un premier temps, une SOA peut s'avérer couteuse : nouvelle façon de penser, nouveaux outils, formations à prévoir...

Pour les allergiques, la liste est la suivante :

• Une SOA introduit une grande complexité et de nouveaux problèmes.
  La plupart des problèmes liés à la mise en place d'une SOA sont des problèmes existants partout ailleurs dans le monde de l'informatique distribuée. La mise en œuvre d'une SOA ne fait souvent que mettre en exergue des problèmes existants.
• SOA n'est pas nouveau, c'est juste un effet de mode.
  Il faut voir au delà de l'aspect technique : certes SOA repose sur les principes de l'informatique distribué, mais c'est l'ensemble de la démarche qui est nouvelle et qui a au moins l'avantage de crystaliser certaines bonnes pratiques.
• Une SOA est vouée à l'échec, parce que les Web Services sont un standard trop instable.
  SOA et SOAP sont deux choses complètement différentes. Les Web Services sont 'juste' un moyen d'exposer des services.
• Il est difficile de vendre une SOA, car les acteurs fonctionnels n'en voient pas les bénéfices.
  Certains bénéfices sont apparents de manières quasi instantanée (on pense aux indicateurs BAM), et les acteurs fonctionnels gagnent rapidement une nouvelle compréhension de leur environnement IT.
• SOA est déjà dépassé, il faut passer à la suite.
  Le challenge d'une SOA basique est en effet dépassé. Mais il reste de nombreux enjeux à adresser, notamment dans les architectures les plus complexes.

via InfoQ

Evènements de notre communauté en France et à l'étranger

Soirée Google au LyonJUG

Lundi 23 Novembre, le LyonJUG organise une soirée dédiée aux technologies Google. L'occasion de découvrir, démonstration à l'appui, Google Web Toolkit, Google App Engine, Android et le dernier né Google Wave. L'objectif est aussi de présenter l'architecture globale de ces produits pour mieux en saisir le fonctionnement et le but.
Pour faciliter l'organisation de la soirée dans les locaux d'EPITECH, vous devez vous inscrire ici.

Chez XebiaLabs, nous nous y connaissons en déploiement automatique d'applications Java EE. L'une des choses les plus surprenantes réside dans le fait que «les fournisseurs de serveurs d'application ne semblent pas faire partie des personnes qui maitrisent le mieux le déploiement d'applications».

Dans un article précédent, nous avons décrit ce que nous considérons comme le déploiement d'application J2EE global. Et force est de constater que:

• Déployer va bien au delà d'un simple déploiement d'un EAR ou d'un WAR.
• La plupart des applications ont également besoin d'autres artéfacts comme par exemple du contenu statique pour le serveur web ou encore des fichiers de configuration, utilisés par le code java, au démarrage.
• Il faut également configurer des ressources JEE comme des Datasources JDBC ou des composants JMS (Queues, Topics, Servers).
• A ceci s'ajoute, bien entendu, la configuration du middleware lui-même: création et configuration de clusters de serveurs d'application ou de virtual hosts d'un serveur Apache.
• L'ordre d'exécution des tâches est important afin de réduire (voire de prévenir) la coupure de service de l'application pendant le déploiement et d'en augmenter la vitesse.

Alors posons nous la question. Que nous proposent les fournisseurs de serveurs d'application dans ce domaine ?

Oracle WebLogic Server

Oracle WebLogic Server propose un concept de 'Deployment': c'est la chose que vous créez quand vous déployez un EAR, un WAR ou un EJB Jar. Sic ! Vous pouvez l'adapter à l'environnement en fournissant un plan de déploiement. Cependant, rien n'est proposé pour regrouper plusieurs artéfacts JEE dans un seul déploiement ou inclure la création de ressources JEE telle qu'une Datasource.

Dans WebLogic, il y a le concept de 'SubDeployement' mais étrangement il n'est pas corrélé à un déploiement. C'est un mécanisme utilisé pour cibler des parties d'un module JMS vers des serveurs JMS ou des serveurs WebLogic. L'artifice proposé par les modules JMS semble destiné seulement à regrouper des ressources JMS. Sans doute qu'un jour un développeur l'a initialement appelé Déploiement sans se souvenir que le concept existait déjà dans WebLogic et il l'a alors renommé SubDeployement. Bien sûr, tout ceci n'est que supputation!

WebLogic propose un grand nombre d'API pour le déploiement: l'historique weblogic.Deployer en ligne de commande, la tâche ANT wldeploy et le WebLogic Scripting Tools, WLST pour les intimes, basé sur Python. Ce dernier est, je pense, le plus complet. Grâce à sa représentation sous forme de système de fichier de la hiérarchie des MBeans, il fournit un moyen très intuitif d'accéder à l'information.

JBoss Application Server

Le déploiement dans JBoss est géré par le Virtual Deployment Framework. C'est un framework basé sur des MBeans qui permet à différents artéfacts (EARs, WARs, EJB JARs, RARs, SARs ...) et à différentes ressources (sources de données, paramètres JMS ...) d'être déployés sur JBoss. Tout ceci est géré par leurs deployers.

Cependant, la plupart des gens n'invoque pas ces deployers, ni même 'twiddle'. Ils préfèrent simplement déposer leurs artéfacts dans le répertoire deploy/ de leur serveur d'application Jboss, puis attendre que le Deployment Scanner le détecte. Ils vérifient ensuite dans le fichier de log que le déploiement est terminé.

Le souci avec cette méthode : le déploiement n'est pas une opération atomique. Quand on automatise un déploiement, on ne veut redémarrer le serveur web qu'après un déploiement réussi du nouveau WAR. Mais écrire un bout de code qui analyse les logs du serveur à la recherche d'un mot clé est tout simplement moche. Une alternative serait de positionner la propriété ScanEnabled du DeploymentScanner à false d'invoquer manuellement le deployer. Non seulement cela complexifie le code, mais il faut également prévoir la copie des fichiers dans le répertoire deploy du serveur JBoss.

Ainsi, il s'avère qu'avec JBoss Application Server, il est difficile d'intégrer des déploiements vers ses serveurs dans un scénario de déploiement plus global. RedHat doit corriger ce problème au plus vite pour que JBoss soit réellement prêt pour les entreprises.

IBM WebSphere Application Server

Et pour le gros monstre JEE de chez 'Big Blue' ? Il offre une façon polyvalente et transactionnelle pour déployer des applications et des ressources. Globalement, le langage de script wsadmin permet de contrôler tous les aspects de WebSphere. Par exemple, vous pouvez synchroniser des nœuds explicitement et l'invocation de la méthode (par Jython ou JACL) pour déployer l'application ne rendra la main que lorsque l'opération sera réalisée. Le côté négatif est qu'il est beaucoup plus lent que l'outil similaire WLST proposé par WebLogic (les nombreuses copies de documents XML à travers SOAP doivent y être pour quelque chose) et les API proposées sont plutôt complexes à manipuler (qui peut donner la différences entre un containment path, un configuration id et un object name?)

Bien que WAS ne propose pas de mécanismes pour regrouper les différents artéfacts et ressources liés à un même déploiement, sa nature transactionnelle permet de commiter les différents changements de configuration en une fois. Il peut même gérer la configuration des instances des serveurs IBM HTTP Server ou Apache HTTP Server .

Malgré une vitesse de déploiement lente, rien ne vaut la fiabilité des déploiements de WebSphere !

Conclusion

Les serveurs d'application fournissent chacun un niveau de support différent pour prendre en charge les déploiements des applications d'entreprise. Bien sûr, ils offrent tous le déploiement basique des artéfacts Java EE mais aucun d'entre eux ne propose de regrouper différents artéfacts en un seul déploiement ou de lier des ressources Java EE à ces artéfacts. WebLogic Server est le seul qui essaye de regrouper des ressources (JMS Modules et SubDeployment). Mais ces abstractions ne couvrent qu'une petite partie de toute l'étendue du déploiement Java EE.

La répétition et la prédiction sont très importantes pour une stratégie de déploiement réussie, ce qui peut expliquer la prévisibilité de WebSphere sur le marché. Et finalement, une bonne API est nécessaire pour automatiser votre processus de déploiement: WebLogic et WebSphere l'offrent, JBoss a un sérieux manque dans ce domaine (même avec twiddle !)

Les consultants de Xebia et l'ensemble des développeurs chez XebiaLabs ont quasiment tous écrit dans leurs expériences passées des tonnes de scripts pour automatiser des déploiements et ont dû batailler sur ces questions encore et encore. Nous avons développé Deployit afin de prendre en charge ces différences entre serveurs d'applications et parce que nous croyons que l'automatisation des déploiements est de la plus haute importance du fait du nombre croissant de déploiements dans les entreprises.

--
Traduction libre du billet «Do application server vendors really understand deployment? » publié par Vincent Partington.

Comme tout le monde le sait, Devoxx (anciennement JavaPolis) aura lieu la semaine prochaine à Anvers. Xebia y sera représenté.

Au fil des années, Devoxx s'est affirmée comme la seconde plus grosse conférence Java au monde après JavaOne, la première en Europe. Cette conférence se divise en deux parties : 2 jours d'universités constitués de présentations longues et complètes sur les principaux sujets, et 3 jours de sessions d'un format plus classique permettant de s'informer sur un plus grand nombre de sujets.

L'éco-système Java est dense et en perpétuelle évolution ; les innovations proviennent de toutes parts. Malgré les nombreux vecteurs d'informations à disposition pour rester au fait de l'actualité, une telle conférence reste une source de connaissances inégalée de par les présentations qu'elle offre, et les rencontres qu'elle permet. Et, bien au-delà de la récolte d'informations, c'est également le parfait endroit pour observer un climat et dégager des tendances.

Le programme de cette belle semaine, dont nous vous parlions il y a peu, est à la hauteur de ces attentes :

• Java EE 6, dont la finalisation est imminente, sera un des principaux sujets de Devoxx ; Antonio Goncalves et Roberto Chinnici en présenterons les enjeux et les nouveautés,
• Spring 3 arrive d'ici la fin de l'année, et sera présenté en détail,
• Le Cloud Computing est un sujet récurrent depuis quelques temps, il intrigue par ses promesses et par le flou qui l'entoure ; il en sera largement question à Anvers,
• La plateforme Flash avec Flash Catalyst et Flash Builder 4, qu'Adobe présente comme une évolution majeure notamment par la collaboration entre équipes de design et de développement qu'elle permet,
• HTML 5 qui s'annonce comme une technologie majeure pour les développements Web futurs

Tous ces sujets seront présentés par des acteurs très influents de la communauté.

Les journées s'annoncent donc très chargées et nous essaierons de partager autant d'informations que possible quotidiennement sur notre blog. Et comme pour Jazoon et SpringOne, le live se passera sur nos twitters : rmat0n, dijouxellene et mfiguiere ... et également sur Développez.com

Suite à vos retours nombreux, aux différents articles touchant à la sécurisation par SSL de Tomcat en production (Tomcat : Adresse IP de l'internaute, load balancer, reverse proxy et header HTTP X-Forwarded-For, Sécuriser Tomcat 5 derrière un proxy Apache 2 HTTPS), nous commençons une série sur Tomcat en production.
Dans ce premier article, nous abordons l'utilisation de SSL pour sécuriser les communications. Pourquoi utiliser SSL ? Comment SSL est-il intégré avec le moteur de Servlet ? Et surtout quelle configuration correspond à votre application, qu'elle soit hébergée sur un serveur Tomcat seul, avec un serveur Apache Httpd en frontal, avec un accélérateur SSL ou avec un load-balancer hardware.

Pourquoi utilisons nous SSL ? Qu'est ce qu'une communication sécurisée ?

Il est souvent nécessaire de protéger les accès à différents services d'une application web. C'est le cas par exemple des formulaires d'authentification. Il faut donc sécuriser tout ou partie des services de l'application. Mais qu'est-ce qu'une application sécurisée ? La sécurité informatique repose sur quatre grande règles: confidentialité, intégrité, disponibilité et non répudiation. Si votre application respecte ces 4 règles, alors elle est sécurisée.

La plupart du temps, SSL est utilisé pour adresser la confidentialité et l'intégrité des communications web échangées entre le client et le serveur. Schématiquement, SSL encapsule le protocole HTTP dans un canal sécurisé. Le canal utilise un chiffrage fort qui garantie la confidentialité de la communication. Pour garantir que les données ne sont ni modifiées ni rejouées par un tiers, SSL signe et numérote les messages échangés. De plus, SSL supporte l'utilisation de certificats qui vont permettre de garantir l'identité des interlocuteurs. S'il est possible d'utiliser un certificat client pour authentifier l'utilisateur, dans la grande majorité des cas, seul le serveur possède son certificat. La mise en place de certificats clients à grande échelle, via une PKI par exemple, est un sujet à part entière que nous n'aborderons pas ici.
Dans le schéma ci-dessous, les communications provenant d'Internet sont sécurisées grâce à l'utilisation de SSL. Les communications provenant des autres serveurs de la "zone de confiance" du data center n'utilisent pas SSL. Certains estiment que cette dispense vient du fait que tous les messages doivent passer en clair dans la zone de confiance pour que les outils de sécurité puissent surveiller tout ce qui transite ; d'autres avanceront que SSL est inutile car d'autres techniques de sécurisation sont utilisées (audit de la couche réseau, gestion des permissions sur les serveurs, etc). Quelle que soit la motivation, il est fréquent de se dispenser de SSL pour les communications internes ; cela simplifie le tuning et le dimensionnement de nos applications.

Comment savoir en Java si une requête HTTP est sécurisée ou utilise SSL ?

L'API Servlet offre une méthode générique ServletRequest.isSecure()" >ServletRequest.isSecure() qui indique si une requête a emprunté un canal sécurisé. Nous noterons que cette méthode est plus générique que l'utilisation spécifique de SSL et permet notamment d'identifier comme secure, bien que non SSL, une requête provenant, par exemple, du même data center. Une autre méthode plus spécifique mais souvent inutile si l'on repose sur ServletRequest.isSecure() est ServletRequest.getScheme() qui indique le protocole utilisé : http, https, etc

Comment forcer l'utilisation de communications sécurisées (SSL) en Java

Les frameworks web communément utilisés en Java permettent de forcer de façon déclarative l'utilisation d'un canal sécurisé (ie. https) pour les requêtes entrantes. Dans les faits, ils interdisent l'accès à la ressource via un canal non sécurisé en retournant l'erreur HTTP 403. Ils peuvent aussi forcer la redirection sur HTTPS.

Spring Security

Spring Security utilise l'attribut requires-channel="https" qui est hélas légèrement trompeur puisqu'il repose sur la méthode ServletRequest.isSecure() plutôt que sur ServletRequest.getScheme() et ne vérifie donc pas l'utilisation du protocole https mais le fait que la requête est secure pour le moteur de servlet.

Configuration Spring Security forçant SSL

API Servlet

L'API Servlet offre une approche déclarative similaire dans le fichier web.xml avec l'instruction <transport-guarantee>CONFIDENTIAL</transport-guarantee> qui repose elle aussi sur ServletRequest.isSecure().

Configuration web.xml forçant SSL

Comment transmettre au moteur de servlet l'information qu'une requête est sécurisée (SSL) ?

Puisqu'il existe deux ports standards respectivement réservés au HTTP et au HTTPS, le standard des serveurs J2EE est d'utiliser une approche multi-canaux dans laquelle un port est réservé au canal sécurisé via HTTPS et l'autre non sécurisé via HTTP.
Avec la généralisation des proxy, des load-balancers et des cartes accélératrices SSL, il est maintenant fréquent que les requêtes HTTPS soient décryptées bien avant les serveurs JavaEE sur lesquels elles arrivent en clair.

Il existe alors deux approches pour différencier les requêtes HTTP et HTTPS :

• S'inspirer de la différenciation de ports utilisés par HTTPS et HTTP en faisant emprunter des canaux différents aux requêtes sécurisées et non sécurisées, même après le décryptage des premières.
• S'inspirer de l'ajout par les proxys du header X-Forwarded-For pour propager l'adresse IP de l'appelant (cf Tomcat : Adresse IP de l'internaute, load balancer, reverse proxy et header Http X-Forwarded-For) et introduire un header X-Forwarded-Proto pour indiquer le protocole utilisé.

Configuration multi-canaux : utiliser des connecteurs/ports différents

L'approche historique de Tomcat pour différencier les requêtes qui sont entrées en HTTPS de celles qui sont entrées en HTTP est de définir plusieurs connecteurs. Cette approche permet aussi bien de gérer l'encryption SSL dans Tomcat que, depuis la version 6, de la faire en amont dans le serveur web ou un load balancer hardware par exemple. Dans ce deuxième cas, un connecteur est configuré pour recevoir des communications en HTTP tout en valorisant request.isSecure() à true et request.getScheme() à https.

Hélas, cette configuration rend la gestion de requêtes sécurisées non SSL (<Connector ... secure="true" scheme="http" />) très délicate, car la spécification Servlet stipule que le conteneur doit émettre un cookie de session 'secure' si la requête HTTP à l'occasion de laquelle la session a été créée est 'request.secure = true'.
Le problème vient du fait que des clients HTTP comme Jakarta Commons Http Client traitent automatiquement les connections non SSL comme non sécurisées et ne renvoient donc pas le cookie JSESSIONID pour les appels non SSL même si celui ci a été défini comme secure par le conteneur. La définition de requêtes comme sécurisée mais non SSL est alors incompatible avec l'utilisation de sessions http avec une erreur très difficile à diagnostiquer. Du fait de ce problème, nous ne traiterons pas dans ce billet de la configuration Tomcat multi-canaux pour gérer les requêtes sécurisées qui n'utilisent pas SSL.

Exemple de configuration Tomcat multi-connecteurs pour dissocier les requêtes HTTP de requêtes HTTPS :

Extrait de server.xml utilisant les attributs secure et scheme pour différencier les requêtes SSL

Configuration mono-canal avec header HTTP : utiliser le header X-Forwarded-Proto

Une autre approche, disponible dès le prochain Tomcat 6.0.21, est d'utiliser un header http pour indiquer si le protocole était http ou https. Ce header est communément nommé X-Forwarded-Proto: https|http (Microsoft Internet Security and Acceleration Server utilise Front-End-HTTPS:on|off). Ce header est souvent associé au header X-Forwarded-For déjà utilisé par les load balancers et proxys pour transmettre l'adresse IP de l'appelant.

Pour prévenir tout 'spoofing' des requêtes, il faut s'assurer que les points d'entrée HTTP/HTTPS de la plate-forme écrasent la valeur de ce header http X-Forwarded-Proto avec le protocole utilisé (http ou https) ; il s'agit de supprimer les headers nommés X-Forwarded-Proto s'ils existent et d'en insérer un nouveau ; omettre l'étape de suppression des headers X-Forwarded-Proto éventuellement existants serait une faille de sécurité.

Gestion du header X-Forwarded-Proto avec une valve Tomcat

La solution la plus simple pour gérer le header X-Forwarded-Proto sur un serveur Tomcat est de déclarer la valve RemoteIpValve dans le serveur Tomcat :

1. En attendant Tomcat 6.0.21 qui embarquera la RemoteIpValve, télécharger xebia-tomcat-extras-1.0.0.jar ou compiler RemoteIpValve.java et déployer le jar sous TOMCAT_HOME/lib.
2. Déclarer la RemoteIpValve (doc) dans server.xml. Cette valve doit être déclarée avant les autres valves qui s'appuient sur le protocole ou l'adresse IP de l'internaute. Il est possible de déclarer aussi la SecuredRemoteAddressValve (doc, également incluse dans xebia-tomcat-extras-1.0.0.jar) pour bénéficier du mécanisme de requête sécurisée non SSL :

Gestion de SSL et des communications sécurisées avec des valves Tomcat

Gestion du header X-Forwarded-Proto avec un filtre Servlet API

Si vous ne pouvez pas changer la configuration Tomcat ou si vous utilisez un autre moteur de servlet (Glassfish, Websphere, Weblogic, etc), il est possible de gérer le header X-Forwarded-For grâce à un Servlet Filter de l'application web :

1. Télécharger xebia-servlet-extras-1.0.1.jar, compiler XForwardedForFilter.java ou ajouter la dépendance maven fr.xebia.web.extras:xebia-servlet-extras:1.0.1 à votre pom.xml (doc).
2. Déclarer XForwardedFilter (doc) dans web.xml Cet filtre doit être déclaré avant les autres filtres qui s'appuient sur le protocole ou l'adresse IP de l'internaute. Il est possible de déclarer aussi le SecuredRemoteAddressFilter (doc, intégré dans xebia-servlet-extras-1.0.1.jar) pour gérer les requêtes sécurisées non SSL :

Gestion de SSL et des communications sécurisées avec des Servlet Filters

Mise en oeuvre multi-canaux et header X-Forwarded-Proto suivant les topologies Tomcat

Topologie Load Balancer Hardware Apache Httpd Tomcat

Il est très fréquent, lorsqu'une application web doit être hautement disponible, de faire précéder les serveurs web d'un Load Balancer Hardware qui devient alors un Single Point Of Failure extrêmement fiable. Nous prendrons pour ce paragraphe l'hypothèse que le load balancer hardware prend en charge l'encryption HTTPS.

Remarque SSL et load balancer

La pertinence de gérer SSL dans le load balancer est très discutée ; certains y sont farouchement opposés (cf loadbalancing.org), d'autres sont plus mesurés (c.f. HAProxy) et enfin les vendeurs de load balancers hardware y sont très favorables . Ce débat, qui porte aussi sur la pertinence de déléguer la compression (aka gzip ou deflate) au load balancer, dépasse le cadre de ce billet et le domaine de compétence des architectes applicatifs. Pour aller plus loin, nous vous recommandons Making applications scalable with Load Balancing de Willy Tarreau (HA Proxy).

Remarque Apache et mod_proxy_http

Nous utiliserons dans ce billet Apache Httpd en version 2.2.11 avec le connecteur mod_proxy_http / mod_proxy_balancer. Il serait également possible d'utiliser le protocole AJP (avec mod_jk, mod_proxy_ajp ou mod_cluster) ; nous expliquerons notre préférence pour mod_proxy_http dans un prochain billet.

Gestion du paramètre X-Forwarded-Proto dans les load balancers

L'utilisation du header X-Forwarded-Proto nécessite une configuration très simple : le load balancer valorise le header X-Forwarded-Proto, les serveurs web et Tomcat écoutent sur un seul port et la RemoteIpValve Tomcat (ou le XForwardedFilter) traite le header X-Forwarded-Proto pour valoriser request.isSecure() et request.getScheme() .

Note : cette approche permet très facilement de gérer les communications sécurisées non SSL en utilisant une SecuredRemoteAddressValve Tomcat (ou un SecuredRemoteAddressFilter) qui marquera request.isSecure() des requêtes non SSL émises depuis des plages d'adresses IP pré-déterminées.

Sur un F5 Big-IP, le header X-Forwarded-Proto sera défini grâce à une iRule de type :

Source : F5 DevCentral wiki - HTTP::header

Astuce Big-IP iRules: 'remove' versus 'replace'

Par rigueur, nous avons préféré utiliser HTTP::header remove puis HTTP::header insert plutôt que HTTP::header replace qui ne traite que la première occurence du header. Si une personne malveillante injecte plusieurs headers X-Forwarded-Proto, HTTP::header replace n'écrasera que la première occurence alors que le duo HTTP::header remove & HTTP::header insert les supprimera toutes avant d'en insérer une valide.

La configuration du serveur Http est alors triviale, il suffit d'écouter sur le seul port 80 et de transmettre au serveur Tomcat en passe plat.

Configuration Apache httpd.conf

Gestion multi-canaux depuis le load balancer

La configuration multi-canaux du load balancer nécessite une configuration plus lourde des serveurs Apache et Tomcat puisque le nombre de canaux (port d'écoute, etc) est doublé.

Configuration Apache httpd.conf multi canaux

Topologie Apache Httpd - Tomcat

Gestion du paramètre X-Forwarded-Proto dans Apache

Bien qu'il soit possible de décrypter SSL sur les serveur web Apache Httpd, nous préférons largement la déléguer au load balancer pour les raisons suivantes :

• Sécurité : la passphrase d'un certificat SSL est un secret très sensible qu'il est plus facile de gérer sur un nombre très limité de load balancers à l'accès très restreint plutôt que sur les serveurs web qui sont plus nombreux et sur lesquels de nombreuses équipes interviennent. Il est certes possible de protéger la passphrase d'un serveur Apache en limitant l'acccès au user root mais on voit souvent sur le terrain le user root de serveur web utilisé par beaucoup d'intervenants pour faciliter le travail au quotidien. Il est beaucoup plus simple de limiter les accès sur des serveurs ultra spécialisés comme les load balancers.
• Performance : HTTPS est très consommateur en CPU et son tuning est délicat (réutilisation des sessions SSL, etc). Pour plus de détails, Apache Con EU 2008 - Apache Performance Tuning par Sander Temme.
• Simplicité : grâce à l'utilisation d'un header X-Forwarded-Proto pour indiquer le protocole utilisé, la configuration du serveur se limite au seul port d'écoute 80.

Si vous avez malgré tout besoin de décrypter HTTPS dans les serveurs web, voici un exemple de configuration Apache Httpd.

Configuration Apache httpd.conf portant le header X-Forwarded-Proto

Remarque Apache Httpd : Il n'est pas possible de déclarer deux points de configuraiton pour un même <VirtualHost />, par conséquent, si votre configuration référence un fragment extra/httpd-ssl.conf pour gérer SSL, vous devez modifier ce fragment pour ajouter la directive RequestHeader set ..., plutôt que d'utiliser un fragment 'maison' extra/httpd-myconfig.conf.

Gestion multi-réseaux

La gestion multi-réseaux avec Apache n'est pas particulièrement compliquée mais introduit une duplication de code verbeux qu'il est agréable d'éviter car il faut déclarer deux balancers qui ne diffèrent que par leur port d'écoute.

Configuration Apache httpd.conf multi canaux

Tomcat seul

L'utilisation de Tomcat seul, sans serveur web ni load balancer en amont, simplifie le choix. Tomcat écoute à la fois en http et https (généralement respectivement les ports 80 et 443). Seule l'approche multi-connecteurs s'applique. La littérature regorge de mises en oeuvre de SSL avec Tomcat. Le principal point d'attention est la délégation de l'encryption SSL à OpenSSL grâce au connecteur APR (Http11AprConnector) plutôt que de reposer sur l'implémentation SSL des JVM (JSSE) qui est beaucoup moins performante.

Extrait de server.xml

Astuce : comment éviter de démarrer le serveur Tomcat avec les privilèges root ?

Sur les serveur Unix/Linux, écouter sur les ports <1024 requiert les privilèges root ; faire écouter un serveur Tomcat sur les ports 80 (http) et 443 (https) devient donc très délicat pour la sécurité de la plate-forme. Une astuce est d'utiliser iptables pour faire du port forwarding de 80 et 443 vers 8080 et 8443. Plus de détails dans Tomcat Wiki - How to run Tomcat without root priviledges? ou Rife - Installing Tomcat on port 80 with iptables.

Que choisir ? Multi-canaux ou header X-Forwarded-Proto ?

Si l'approche multi-canaux avec un premier connecteur pour les communications non http et un second pour les communications https/ssl a le mérite d'être l'approche "historique", elle présente les défauts de :

• ne pas gérer les communications sécurisées non http,
• complexifier sensiblement les configurations Apache Httpd et, dans une moindre mesure, Tomcat.

Notre préférence va à l'utilisation d'un header http X-Forwarded-Proto qui permet de simplifier les configurations Apache Httpd et Tomcat et aussi de permettre des communications sécurisées non SSL.

L'argument d'une complexification de la configuration Tomcat par l'ajout de la RemoteIpValve (ou du XForwardedFilter) est discutable puisque cette valve est la plupart du temps nécessaire pour gérer le header X-Forwarded-For qui permet d'obtenir l'adresse IP de l'internaute, élément important pour l'audit d'actions qui requièrent SSL.

Xebia et Jeff Sutherland (le père de la méthode Scrum) ont certifié plus de 100 ScrumMasters en 2008. Devant le succès de ce programme, nous avons décidé de le reconduire en 2009.

A votre tour, découvrez SCRUM ou valorisez votre expérience déjà acquise en devenant Certified Scrum Master (CSM) en assistant à cette formation unique en France par son contenu et la qualité de son animateur.

La prochaine session aura lieu les 3 et 4 décembre 2009 (inscription).

Pour vous inscrire vous pouvez aussi appeler le 06 09 69 05 49.

Cette formation de deux jours fournit aux stagiaires les principes fondamentaux de Scrum.

Des ateliers pratiques permettent de mettre la théorie en pratique. Les stagiaires gagneront une expérience pratique dans l'élaboration du Product et du Sprint Backlog, l'organisation des Daily Scrums, des Sprint Planning Meetings, la tenue du Burndown Chart.

Jeff fournit tout au long de cette formation des trucs et astuces, hérités d'une expérience unique en tant que père de la méthode ayant plus de 10 ans d'expérience sur Scrum.

Un abonnement d'un an à la Scrum Alliance est également inclus dans cette formation.

Retrouvez quelques retours sur les sessions organisées en 2008 :

• Par Nicolas Martignole : I'm now a Scrum Master.
• Par David Andriana : Formation Scrum Master à La Défense.
• Par Frédéric Doillon : Un américain à Paris.
• Par Samuel : Résumé de la formation Scrum.
• Par Fabrice Aimetti : Rétrospective Formation Certifiante Scrum Master.

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

Actualité éditeurs / SSII

• Subversion, le nouveau projet de la Fondation Apache
• MuleSoft annonce Mule Data Integrator
• Des nouvelles de Tomcat 7

RIA

• Atmosphere, atmosphere ?

Le coin de la technique

• Sortie de JRuby 1.4.0
• Le mouvement NoSQL divise et intrigue

Evènements de notre communauté en France et à l'étranger

• Soirées Google et Atmosphere au Paris JUG

Actualité éditeurs / SSII

Subversion, le nouveau projet de la Fondation Apache

C'est officiel, Subversion fait maintenant partie des projets de la fondation Apache. Avant de pouvoir devenir projet top-level, Subversion doit d'abord passer par l'incubateur. Durant cette période, CollabNet continuera d'héberger le projet sur http://subversion.tigris.org. De plus, les différents binaires continueront d'être publiés sur ce site au-delà de la période d'incubation. Nous sommes donc en droit de nous demander ce que cette nouvelle va finalement changer ?

Certains imaginent la refonte de Subversion pour lui ajouter des fonctionnalités de gestionnaire de sources distribué, comme GIT ou Mercurial. Il est pourtant difficile de croire à une telle transformation, Subversion étant connu comme le gestionnaire centralisé star du moment. Un tel virement de bord signifierait la fin de ce modèle centralisé.

D'autres perçoivent au contraire cette nouvelle comme une fierté personnelle et voient l'arrivée de Subversion dans l'ASF comme un aboutissement. Le projet est assez mature pour rentrer dans une nouvelle phase et Apache est la maison idéale pour le faire vivre sur le long terme tout en pérennisant la communauté.

Au final, la véritable réponse à cette question se situe probablement entre ces deux visions. Pourquoi le projet ne continuerait pas tout simplement à avancer sur le chemin qu'il suit depuis sa création ? Il lui reste du trajet à parcourir : performances, intégration avec les IDEs, outillage ...

MuleSoft annonce Mule Data Integrator

MuleSoft annonce aux abonnés de sa newsletter l'arrivée en version beta de Mule Data Integrator, un outil permettant de définir facilement des mappings de données de toutes formes (XML, JavaBeans, WSDL, base de données, fichier simple, ...). Ces modèles d'intégration de données peuvent ensuite être exploités directement par un transformer spécifique pour Mule ESB. L'outil se présente sous la forme d'une application Eclipse.

Il s'agit là d'une réponse à une problématique courante puisque Mule ESB simplifie l'intégration entre protocoles mais laisse au développer le soin d'apporter sa solution de transformation de données en se basant sur XSLT ou Java. On appréciera donc une telle possibilité offerte sur un ESB Open Source, même si aucun détail n'est pour le moment fourni quant à la licence pratiquée sur Mule Data Integrator.

Cette annonce fait suite à une activité très dense de l'éditeur ces derniers mois qui avait déjà créé la surprise avec iBeans et son offre Tcat Server. Fort de ce portfolio plus dense et plus riche, MuleSoft cherche donc à devenir un éditeur pour solutions d'entreprise à part entière, et non plus simplement l'entreprise derrière l'ESB à succès.

Des nouvelles de Tomcat 7

A l'occasion des festivités organisées à l'ApacheCon2009 pour les 10 ans d'Apache, les annonces furent nombreuses. Nous avons déjà parlé de l'arrivée du projet Subversion, dans le giron de la fondation. Outre l'utilisation par la maison blanche du projet Drupal, ce fût aussi l'occasion d'annoncer l'arrivée prochaine de Tomcat 7. Mark Thomas, interviewé par Dzone sur le sujet, parle d'une version alpha pour la fin de l'année. Voilà qui serait un beau cadeau de Noël pour la communauté. Dans l'interview, Mark revient sur les nouveautés attendues dans cette nouvelle version, le but principal étant bien sûr d'implémenter l'API Servlet 3.0. Tomcat supportera les web fragments et la déclaration dynamique de Servlet et Filter.

Côté sécurité, Mark annonce le SSL session tracking pour utiliser les identifiants de session SSL, une plus grande séparation des rôles utilisés pour l'administration (par script, par le web ou par JMX), et l'utilisation de jetons temporaires (nonce) en protection contre les attaques de type Cross Site Request Forgery. Une autre nouveauté majeure annoncée par Mark est la capacité de Tomcat 7 à être embarqué dans une application. Selon ses dires il suffit de 8 lignes de codes pour lancer Tomcat et configurer son application web.

Restent les logs asynchrones, l'ajout d'alias permettant d'héberger des répertoires du système de fichier hors du contexte standard de l'application, et de nouvelles protections contre les fuites mémoires. L'interview complète sur Dzone...

RIA

Atmosphere, atmosphere ?

Pas mal de buzz en ce moment autour du framework web Atmosphere (via TSS pour la sortie du produit en version 0.4) qui permet de créer des applications RESTful et Ajax Push/Comet.
Le framework supporte entre autres Java, JRuby, Groovy et Scala. Plusieurs exemples sont disponibles pour ce dernier avec notamment l'intégration d'Atmosphere avec Akka et Jersey (ici).

Au menu des nouveautés depuis la 0.3, une intégration avec Wicket et GWT, une intégration simplifiée avec des applications existantes (servlet based), le support des derniers protocoles bayeux, le support d'EJB 3.1, et OSGi ready ...

Si ce framework vous intéresse, allez donc faire un petit tour au Paris JUG !

Le coin de la technique

Sortie de JRuby 1.4.0

L'équipe du projet JRuby annonce une nouvelle version de l'interpréteur Ruby full-Java. Parmi les avancées :

• Compatibilité avec Ruby 1.8.7 patchlevel 174
• Nouveau parser YAML, portage complet de Syck!
• Meilleure intégration de Java, plus rapide
• Installeur Windows
• Avancée du support de Ruby 1.9
• 307 bugs corrigés depuis la version 1.3.1

Le support de Rails dans sa dernière version est pleinement assuré et les objectifs pour le futur sont axés sur le support complet de Ruby 1.9.

Le mouvement NoSQL divise et intrigue

Le nom NoSQL est apparu courant 2009 pour qualifier un mouvement initié depuis longtemps mais qui a pris une importance et une visibilité particulière ces derniers mois. Il regroupe l'ensemble des projets proposant une solution de persistance de données non relationnelle qui se caractérisent par un design favorisant la scalabilité et la flexibilité. On reconnaît dans ces deux caractéristiques les besoins du Web, dont les grands acteurs que sont Google, Amazon et Facebook ont joué un rôle important en apportant leur propre solution (respectivement BigTable, SimpleDB et Cassandra).

Remettre en question le stockage relationnel exclusif qui s'était imposé presque comme une évidence dans le monde de l'entreprise ne pouvait se faire sans initier de nombreux débats. La dernière intervention en date est celle de Michael Stonebraker qui critique vivement cette initiative en avançant :

• Le choix du NoSQL comme solution de persistance est en général amené par un besoin de performance et de flexibilité. Ces deux caractéristiques peuvent être assurée par les RDBMS traditionnelle par la mise en place de bonnes pratiques épaulées d'un éventuel sharding
• Les systèmes NoSQL souffrent eux aussi de certaines des problématiques des RDBMS et ne sont donc pas une solution parfaite
• L'utilisation de procédures stockées permet d'obtenir la performance voulue dans de nombreuse situations

Ces arguments, assez classiques à l'encontre du NoSQL, sont opposés à ceux mis en avant par Debasish Ghosh, l'auteur du prochain DSLs in action à paraître chez Manning :

• Le sharding, solution souvent mise en avant pour sauver la scalabilité des RDBMS, est une solution très lourde à mettre en place, qui évolue mal et qui est très intrusive dans la logique métier ; elle est appliquée à des systèmes qui n'ont pas été prévus pour une telle utilisation
• Le théorème CAP montre que seule une approche différente des RDBMS classiques permet d'obtenir les performances voulues
• Une coopération intéressante se met en place entre les projets NoSQL afin de permettre des interopérabilités (tel que Neo4j s'appuyant sur Cassandra ou Riak sur CouchDB)

La remise en question apportée par le NoSQL est forcément bénéfique et ne peut amener qu'une innovation. Si le mouvement est encore récent et qu'il doit gagner en maturité, il amènera probablement à se poser plus naturellement la question de la ou des meilleure(s) solution(s) de persistance pour les données d'une application ou d'un système d'information.

Evènements de notre communauté en France et à l'étranger

Soirées Google et Atmosphere au Paris JUG

Pour rebondir sur la news ci-dessus concernant le framework Atmosphere, le Paris JUG nous propose ce jeudi 12 novembre une soirée spéciale Atmosphere.
A l'heure où nous écrivons ces lignes, il reste encore quelques places donc c'est maintenant ou jamais pour vous inscrire !

Toujours par le Paris JUG, la deuxième soirée de la semaine, mardi 10 novembre, autour de Google Wave / Android / App Engine affiche complet :p !
La remise à disposition des places des personnes non présentes 5 minutes avant le début de la session reste envisageable mais l'abonnement à la newsletter / rss / autre reste quand même le meilleur moyen d'être averti à temps !

Xebia organise une formation d’optimisation des performances d’applications Java/J2EE avec Kirk Pepperdine, une première en France, entre le 18 et 21 janvier 2010.

Pour ceux qui ne le connaissent pas, Kirk Pepperdine dispose de plus de 15 ans d’expérience dans les technologies orientées objets et l’optimisation de la performance. Figure emblématique du monde Java et élu "Champion JAVA" en 2005, Kirk est reconnu comme le référent de l’optimisation de performance Java. Il est le DSI de Kodewerk Ltd et le principal contributeur de javaperformancetuning.com.

Cette formation approfondie de 4 jours permettra aux stagiaires d’obtenir les compétences nécessaires pour optimiser la performance de leurs applications Java/J2EE. Vous aborderez pendant cette formation tous les aspects de la performance :

• L’outillage nécessaire.
• Les méthodologies à appliquer.
• Les concepts d’architecture sous jacents à la performance.
• Les meilleures pratiques.
• Le benchmarking.
• La gestion de mémoire.

Si cette formation vous intéresse, n’hésitez pas à contacter Roderic Pratt au 06.09.69.05.49.

Comme l'année dernière, j'ai assisté ce mercredi 4 novembre aux rencontres Spring Paris. Cette journée est l'occasion de rencontrer des acteurs de renom de la communauté Spring venant présenter leurs solutions et partager leur vision de l'écosystème Java.

Les grands thèmes du jour :

• Présentation de Spring 3.0 et de la roadmap SpringSource.
• Amélioration de la productivité avec Spring ROO.
• Standardisation et positionnement stratégique et face à Java EE.
• Cloud Computing avec le nouveau mouvement lancé par le rachat de SpringSource par VMWare.

Dans ce cadre, j'ai eu l'occasion de mener une interview d'Arjen Poutsma en marge des présentations (merci Michael). Ce billet retrace ce que j'ai retenu de cet entretien.

Arjen Poutsma est le créateur de Spring WS, projet sur lequel il est d'ailleurs toujours largement impliqué. C'est également le second committeur Spring 3.0 avec Juergen Hoeller, qui était venu l'an passé pour présenter le sujet.

Toutes les nouveautés Spring 3.0 abordées lors de la conférence n'ont pas été traitées lors de l'entretien. Cet article n'a pas pour but de les cataloguer, même si certaines d'entre elles y sont abordées ...

Date de sortie de Spring 3.0 et le communiqué de presse récemment publié

À l'heure actuelle, le développement de l'ensemble des fonctionnalités que SpringSource voulait inclure dans Spring 3.0 est terminé, le code est complet et pleinement documenté. C'est Spring 3.0 RC1 est sortie en octobre.

Avant la sortie officielle prévue en décembre, une RC2 va sortir pour corriger les quelques jira restées ouvertes

Vous pouvez commander votre version Spring 3.0 pour Noël.

Spring 3.0, ce n'est pas un petit projet

Le projet est porté par Juergen Hoeller et Artjen Poutsma, qui en sont également les deux plus gros contributeurs. En plus de cela, de nombreux committeurs externes (environ 15 personnes) ont participé au projet, mais pas à plein temps. Le projet a commencé il y maintenant plus d'un an, ce n'est pas un petit projet. En plus des nouvelles fonctionnalités offertes par Spring 3.0, le gros du travail a résidé dans la réécriture et la simplification de Spring core. Un temps non négligeable a été passé pour aligner ou préparer les mises à jour des autres modules Spring. Un travail d'uniformisation des numéros de version est également en cours pour simplifier les interdépendances entre les différents projets. En effet, il devenait difficile de dire que Spring WS 1.5.8 est compatible avec Spring 2.5.x alors que la 1.5.9 n'est compatible qu'avec Spring 3.0. À l'image de Spring Sécurité, les principaux modules Spring devraient donc passer rapidement en 3.0.

Migrez à Spring 3.0 en 2 minutes chrono

Durant les présentations, Adrian Coyler et Arjen ont tous deux affirmé que Spring 3.0 était 100% rétro-compatible avec Spring 2.5. Arjen a même décrit le processus de migration comme une simple mise à jour de jars. Au-delà de la jolie phrase marketing qui fait sourire, un effort particulier a été apporté à la conservation de cette rétro-compatibilité. Les fonctionnalités Core restent complètement rétro-compatibles, voire inchangées. En revanche, si vous migrez un gros projet, vous tomberez probablement dans des cas d'utilisation spécifiques vous obligeant à modifier quelques petites choses. Difficile d'assurer que l'ensemble des cas d'utilisation sont rétro-compatibles (vu leur nombre), même si la plus grosse partie des ré-écritures concerne des classes de tambouille internes à Spring.

Message personnel pour Julien (Dubois) : Arjen m'a proposé d'offrir gracieusement tes services à mon client si la migration me prend plus d'une journée. On lance les paris ?

D'autre part, Spring prônant le pruning, certaines fonctionnalités deprecated vont être supprimées. On salue le choix de SpringSource d'alléger son framework et de tout faire pour ne pas traîner du code legacy sur plusieurs générations (contrairement à d'autres).

Spring 3.0 nécessite a minima un JDK 5. Un sondage à été réalisé lors de la présentation et seule une personne de l'assemblée déclarait toujours utiliser le JDK 1.4. Le timing semble plutôt bon, le JDK 5 de Sun étant déjà passé au statut end of life récemment.

Un Expression Langage intégré à Spring core, plus costaud qu'il en a l'air ...

L'une des grandes nouveautés de Spring 3.0 concerne la gestion d'un langage d'expression dans la déclaration des beans. Cette fonctionnalité est rendue possible par la modification du cœur de Spring. Si son utilisation reste pour le moment un peu timide, c'est l'une des briques nécessaires à certaines évolutions de modules annexes (Web). Il est vrai que nous ne sommes pas habitués à utiliser un tel mécanisme, le besoin peut même vous sembler limité, et pourtant ... C'est également ce que je m'étais dit lors de la présentation de Juergen il y a un an . Depuis, chez mon client, je me suis surpris à constater à plusieurs reprises que cette solution m'aurait été utile.

L'utilisation des EL++ dans la déclaration de vos beans (XML ou annotations) vous permet d'une part de simplifier votre configuration et d'éviter de dupliquer certaines constantes dans vos fichiers de configurations. Cela dit, ce qui est décrit comme constante peut à ce jour déjà être centralisé par l'intermédiaire de variables gérées par le PropertyPlaceholderConfigurer et remplacées à l'initialisation du contexte. L'utilisation des EL++ vous permet ce même résultat directement au runtime ! Différentes classes scopées 'prototype' peuvent donc être instanciées avec des paramètres différents.

La fonctionnalité vous permet d'accéder out-of-the-box à différents contextes : systemProperties, systemEnvironment, request, session ou à toute propriété de beans déclarés dans Spring. Notez qu'il est possible d'enrichir ceux-ci et d'y exposer vos propres contextes. Un mécanisme de SPI vous permet d'enrichir cette fonctionnalité et vous permet d'exposer vos propres contextes. A quoi cela sert il ? Il est par exemple possible, moyennant un peu de code, d'accéder via EL à une valeur stockée en base de données.

Le support REST, une surcouche à Spring MVC

Le support REST a été développé par Arjen, dans la mesure où il est également le fondateur de Spring WS. Nous aurions d'ailleurs pu penser qu'il se serait basé sur le fonctionnement de Spring WS pour réaliser cette fonctionnalité. Arjen m'a d'ailleurs dit avoir imaginé une telle solution avant de rebrousser chemin : le support de REST se rapproche beaucoup plus de Spring MVC que de Spring WS.

Le support REST de Spring 3.0 ne repose sur aucune implémentation existante. Ce n'est donc ni du RESTlet, ni du JAX-RS, c'est du 100% SpringSource et l'une des fonctionnalités proposées par Spring MVC.

Côté client, le nouveau RestTemplate vous permet d'accéder très facilement à n'importe quel service REST.

Les meta-annotations, c'est bien mais pas universel

Arjen a présenté le mécanisme de méta-annotation proposé dans Spring 3.0. Il s'agit d'offrir la possibilité de regrouper plusieurs annotations en une seule. Il est ainsi possible de regrouper certaines caractéristiques par type de composant. Voici l'exemple d'une annotation @MyKindOfComponent, qu'il est possible d'utiliser sur n'importe quelle classe. Celle ci possédera ainsi toutes les caractéristiques des différentes annotations.

Au delà de la tentative d'apaisement des anti-annotations, ce mécanisme peut vous permettre de tagger certains types de classes selon vos besoins. Vous pourrez ainsi facilement retrouver ces classes via un aspect posé sur votre annotation personnalisée.

Spring 3.1 sera pleinement compatible Java EE 6

L'annonce a été faite lors des conférences par Arjen, et modéré ensuite par Alexis Moussine-Pouchkine lors de sa présentation sur « Java EE vs Spring » qui espère que SpringSource implémentera a minima le profil Web des spécifications Java EE 6. Un subset de fonctionnalités sera choisi pour être intégré à Spring 3.1. Il s'agira des fonctionnalités qui ont un intérêt direct pour Spring. Il serait un peu farfelu de penser que Spring implémentera Java EE 6 dans son intégralité. La liste de ces fonctionnalités n'est d'ailleurs à ce jour pas fixée définitivement. Certaines comme JPA 2.0 et JSF 2.0 sont déjà compatibles et intégrées à Spring 3.0. Les autres attendront la prochaine release.

Cela mis à part, Arjen se dit intéressé par certaines fonctionnalités de Java EE 6. Une configuration de Spring MVC simplifiée par l'utilisation des Web Fragments de Servlet 3.0 est envisagée. L'autre fonctionnalité que j'ai évoquée est l'exécution asynchrone d'handlers Spring MVC : Arjen s'est montré également intéressé même s'il m'a dit qu'il existait déjà des moyens d'avoir un mécanisme similaire (j'ai cherché, mais pas trouvé...).

Pour finir, deux sujets un peu moins 'Spring 3.0' ...
Ayant effectué quelques applications Android, j'aurais aimé avoir une solution me permettant d'accéder le plus simplement possible à des services REST / MVC ... Du coup, je lui ai demandé si, en interne, ils étaient intéressés par cette petite communauté de développeurs, et s'ils avaient des idées pour faciliter la création d'applications Android. Evidemment, je n'attendais pas beaucoup de cette question ; la réponse a ressemblé à cela : un restTemplate côté Android ou une version light de Spring remoting est une bonne idée ... qu'il faudra creuser ... par vous-même

Enfin, l'interview s'est terminée par une question personnelle. Quel est, selon lui, le sujet le plus hype du moment : les langages de scripting sur JVM à la Groovy, les nouvelles techniques de concurrence avec les acteurs Scala, la modularisation et le rechargement d'applications, ou le Cloud Computing ... C'est ce dernier qui a sa préférence.

Merci à Arjen pour sa présentation et pour le temps consacré à l'interview.
Au plaisir de renouveler cela l'année prochaine.

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

Actualité éditeurs / SSII

• Amazon lance Relational Database Service
• Oracle tente de rassurer la communauté Sun
• Keynote de Rod Johnson à SpringOne/2GX 2009

Le coin de la technique

• Optimisez vos requêtes SQL
• Apache POI 3.5
• Interminables débats sur la mort de Java
• Une version de tcServer pour les développeurs

Evènements de notre communauté en France et à l'étranger

• Flex 4 chez les Tontons Flexeurs

Actualité éditeurs / SSII

Amazon lance Relational Database Service

Quelques mois après la disponibilité d'Amazon Elastic MapReduce, le libraire américain continue d'enrichir sa gamme de services de Cloud Computing en lançant Amazon Relational Database Service (RDS).

RDS offre une base de données MySQL sur une plate-forme dynamiquement provisionnable. Suivant la logique initiée avec ses autres services, la facturation est fonction de la consommation réelle, la gestion des instances se fait à l'aide d'un Web Service spécifique à RDS et leur monitoring est possible par CloudWatch.

Outre ces caractéristiques communes aux services d'Amazon, on retiendra principalement de RDS :

• Utilisation de MySQL 5.1 avec InnoDB,
• Offre de réplication prévue pour assurer la haute disponibilité, mais non disponible à ce jour,
• Système de gestion des backups.

Par ce service, Amazon déleste ses clients des principales tâches liées à l'administration d'une base de données relationnelle. Répondant ainsi à un besoin réel, on peut s'attendre à ce que ce service, s'inscrivant dans l'offre homogène d'Amazon, rencontre un succès commercial.

Plusieurs réactions et commentaires ont suivi cette annonce, on retiendra particulièrement l'observation de Krishnan Subramanian, sur le coup dur que constitue ce nouveau service pour FathomDB, une entreprise qui proposait un service d'hébergement MySQL sur EC2. Il remarque alors qu'il est délicat pour des startups de parier sur de tels services propriétaires.

Oracle tente de rassurer la communauté Sun

Depuis l'acquisition de Sun par Oracle en avril dernier, le futur de la stack Sun a fait l'objet de peu de communiqués. Quelques rumeurs ici ou là sur le futur de MySQL ont fait surface, après la disparition du lien permettant de télécharger les premières briques de MySQL 6. C'est peut-être pour couper court à ce genre de bruits de couloir qu'Oracle présente ses intentions sur la stack Sun via la mise à jour de sa FAQ . En résumé « on garde tout, et on en fait toujours plus » :

• Oracle dit vouloir passer plus de temps sur Solaris et Sparc que Sun ne l'a fait par le passé. La collaboration d'ingénieurs base de données Oracle et Sun ouvre d'ailleurs de nouvelles perspectives.
• Côté virtualisation, tous les produits Sun 'devraient' continuer à être développés : VDI, Secure Global Desktop, Sun Ray, and VirtualBox.
• Un alignement entre Oracle Weblogic Server et Glassfish Enterprise Server va être effectué. Glassfish reste l'implémentation de référence open source pour Java EE 6.
• Netbeans restera une solution alternative open source à Oracle JDeveloper et Oracle Enterprise Pack pour Eclipse.
• MySQL devrait être ajouté à la liste des bases de données de la suite Oracle au même titre que Berkeley DB, une base de données open source.

Comme vous pouvez le constater, rien de très précis, tout est au conditionnel. Le but est avant tout de ne surtout pas se mettre à dos les différentes communautés.

Keynote de Rod Johnson à SpringOne/2GX 2009

SpringSource est actuellement un des plus grands agitateurs de notre écosystème. Et donc quand Rod Johnson, le papa de Spring, vient donner un keynote en ouverture du plus gros évènements annuel de l'éditeur, on écoute avec attention. Grâce à InfoQ, il est possible de retrouver cette intervention en différé.
En résumé, pas grand chose de nouveau, mais Rod Johnson enfonce le clou sur les sujets que Spring met en avant depuis quelques mois déjà :

• Spring 3.0 : les nouvelles fonctionnalités, et les scénarios d'upgrade.
• Les languages dynamiques : Groovy et Grails, une fois encore à l'honneur
• Les outils destinés aux developpeurs: tcServer (voir par ailleurs), Spring Insight, SpringSource Tool Suite
• Les grandes manœuvre de l'éditeur : aquisition par VMWare (pas grand chose à se mettre sous la dent de ce coté là)
• Le futur de SpringSource : CloudFoundry et les Cloud d'entreprise en Java

En bref, un très bon résumé (pour ceux qui reviendraient de longues vacances) des changements qui nous attendent dans les mois à venir, impulsés par l'un des éditeurs les plus dynamiques du monde JEE.

Le coin de la technique

Optimisez vos requêtes SQL

Nous sommes tombés sur ce post qui nous propose 15 moyens pour optimiser vos requêtes SQL. Si quelques-unes d'entre elles vous paraitront être issues du bon sens commun, d'autres méritent le détour :

• Prenez le plus grand soin de vos index : Le contenu des index primaires se doit d'être le plus petit possible, les index uniques sont en règle générale plus performants.
• Recherchez par wildcard avec certaines précautions : Privilégiez l'utilisation de wildcard à l'utilisation de SUBSTR. Les wildcards postfixés sont plus performants que les wildcards préfixés. Dans la mesure du possible n'hésitez pas à n'indexer qu'une sous partie d'une chaîne de caractères plutôt que la chaîne dans son ensemble. En général utilisez les types de données les plus petits possibles.
• Simplifiez vos requêtes : Privilégiez l'utilisation de l'opérateur EXIST à une utilisation de COUNT. Limitez le nombre de lignes à retourner pour éviter la récupération complète d'une table. Utilisez des valeurs par défaut dans vos colonnes pour simplifier vos requêtes.
• Évitez les scans inutiles : Remplacer l'opérateur NOT d'une expression complexe par son inverse permet de ne pas évaluer l'intégralité de celle-ci. Transformez une sous-requête dans un IN par une sous-requête dans un FROM (et simulez ainsi une table virtuelle). Les UNION sont en principe plus efficaces que les OR car ils permettent d'optimiser l'utilisation des index.

Le tuning de requêtes SQL n'est pas simple, les commentaires sur le billet original en témoignent. Il dépend grandement de la base de données et de sa configuration. La base de données repose sur des statistiques pour savoir quand utiliser ses index. De ce fait, l'amélioration de la performance de vos requêtes commence le plus souvent par une analyse du plan d'exécution de celles-ci. Celui-ci vous permettra de trouver comment poser vos index. Enfin, certaines bases de données comme Oracle vous permettent d'agir directement sur son plan d'exécution à partir de votre requête, par l'intermédiaire de SQL HINT. A n'utiliser qu'en dernier recours

Apache POI 3.5

Du nouveau sur le support des documents Office 2007 en Java (sujet déjà abordé il y a un an) avec Apache POI qui est sorti il y a un mois en version finale 3.5 (via InfoQ). Parmi les nombreuses nouveautés, on retiendra surtout le support des fichiers .docx et .xlsx et plus globalement des documents Office 2007 (mais il aura fallu attendre un an entre la beta 3 et la version finale !).

Plusieurs librairies nous offrent déjà la possibilité de gérer nos fichiers Office 97-2003 (format Microsoft OLE2). Peu d'entre elles proposent la gestion des fichiers Office 2007 (format Microsoft Office Open XML ou OOXML) : par exemple Aspose.Word gère uniquement les fichiers Word 2007. Avec Apache POI 3.5, c'est toute la gamme de produits Office 2007 qui se trouve ainsi supportée.

Quelques modifications seront toutefois nécessaires dans votre code pour supporter ce nouveau format. En effet, le modèle org.apache.poi.hssf.usermodel.HSSF actuel reste compatible OLE2 mais ne supportera pas OOXML. Il faudra ainsi passer par le nouveau modèle org.apache.poi.ss.usermodel.HSSF pour bénéficier de ce support. Ce nouveau modèle s'appuyant fortement sur l'ancien, l'équipe précise que le switch ne devrait pas être trop ardu.

Le téléchargement se passe comme d'habitude sur les miroirs d'Apache.

Interminables débats sur la mort de Java

A chaque année ses raisons d'annoncer la mort de Java ; le débat n'est pas nouveau et les arguments se renouvellent depuis le début des années 2000 :

• Lourdeur de J2EE
• Complexité et densité de l'écosystème Java
• Manque d'intégration des solutions et les faiblesses du langage face au rival Microsoft .Net
• Inadaptation à la création d'interfaces pour le Web et pour les clients lourds
• Manque de productivité face aux nouveaux langages : Python, Ruby, ...

En 2009 l'argumentaire se tourne maintenant vers les langages alternatifs pour la JVM - principalement Groovy et Scala - et vers l'incertitude liée à la gouvernance de Java. Ainsi il y a quelque semaines, Stephen Colebourne postait un inquiétant graphique montrant l'évolution décroissante du nombre de JSR créées auprès du JCP au cours des années. Il se demandait alors si cela pouvait être pris comme une perte de vitesse ou comme un signe de maturité mais remarquait que l'innovation était maintenant principalement portée par les communautés Open Source.

Stephan Schmidt apportait, en septembre dernier, une analyse intéressante du débat sur la mort de Java. Il commençait par dissocier les 3 composantes de Java que sont le langage, la JVM et le JDK, chacun ayant une pérennité distincte. Il exposait alors différents points :

• La quantité d'offres d'emploi en Java reste constante comme le montre le graphe Indeed (devenant un classique en argumentaire).
• Avant la mort de Java, un successeur doit se distinguer. Or Ruby et Python ont peiné à faire leur place dans le monde de l'entreprise. Il reconnaît en revanche le positionnement appréciable de Groovy suite à sa prise de contrôle par SpringSource puis par VMWare et l'innovation intéressante portée par Scala.
• Java est toujours à même d'apporter les caractéristiques qui ont amené son succès : pas de pointeurs, gestion de la mémoire, orientation vers l'entreprise et Internet, gestion simple du parallélisme.
• C'est le monde de l'entreprise qui permet le succès d'un langage, or Java répond toujours à ses besoins même si le langage présente des défauts nuisant à la productivité.
• Java a perdu il y a bien longtemps le hype qui l'entourait, mais cela ne signifie pas pour autant sa mort.

A travers l'évolution du débat, un aspect majeur ressort : les critiques portent maintenant principalement sur le langage Java, la JVM étant reconnu pour ses qualités et la capitalisation qui s'est faite autour d'elle. Dès lors, la JVM se présente comme une plate-forme standard pour les développements, non sans rappeler le statut acquis par l'environnement x86 d'Intel des années auparavant.

La mort annoncée du langage Java au profit de langages alternatifs pour la JVM doit, quant à elle, probablement être modérée. En effet Java, fort de ce que Sun décrit comme la plus grosse communauté de développeurs au monde, n'est actuellement clairement pas menacé.

Une version de tcServer pour les développeurs

SpringSource vient d'annoncer la sortie prochaine (pour l'instant, une preview est téléchargeable) de tcServer Developer Edition. Que trouve t'on dans ce joli package ?

Côté serveur d'application, rien de nouveau, c'est toujours du 100% Tomcat.
C'est une fois de plus dans les à-côtés que tcServer se distingue, avec l'arrivée de Spring Insight. Spring Insight, c'est une console qui va vous permettre de surveiller ce qui se passe au cœur de votre application, à la fois en prenant un point de vue global, mais aussi en zoomant très précisément sur une requête HTTP donnée.

Et quoi de nouveau me direz vous ? Et bien, à vrai dire, pas de rupture technologique (plusieurs outils permettaient de réaliser des mesures comparables) mais une facilité d'intégration à votre application, sujet si cher à Spring. Tout se passe en AOP (rien à faire donc dans votre code), toutes les informations sont stockées en mémoire (pas de base de données, mais en contrepartie, une augmentation de la mémoire consommée par votre application) et les principaux frameworks du marché peuvent être scrutés en utilisant un mécanisme de plugin.
En revanche, Spring est très clair : il s'agit d'un outil de développement : son utilisation en production exposerait vos applications d'un point de vue sécurité.
Une fois de plus, SpringSource joue la carte du tout intégré et de la simplicité, et risque de séduire à la fois des développeurs et des Q&A un tant soit peu sensibles à la qualité intrinsèque d'une application.

Nous avons aimé :

• L'expressivité des métriques qui identifient les URL d'invocation, les principaux composants (actions Spring MVC, composants métier, etc), les transactions et les accès SGBD avec les requêtes SQL.
• La granularité macro qui est souvent plus facile à comprendre que les mesures ultra-détaillées que nous proposent les profilers java.

Notre souhait : l'intégration à l'environnement de développement et au code source de l'application en cliquant sur les graphes de Spring Insight.

Le screencast et la preview de tcServer Dev. se trouvent sur le blog de SpringSource.

Evènements de notre communauté en France et à l'étranger

Flex 4 chez les Tontons Flexeurs

Les tontons flexeurs, le rendez-vous incontournable des flexeurs et des autres, nous propose une nouvelle présentation qui portera sur les nouveautés de Flex 4.
Christophe Coenraets, évangéliste senior chez Adobe, nous présentera ainsi les nouveautés de LiveCycle Data Services 3, le Model-Driven Developpement avec FlashBuilder 4 et l'intégration de Flex avec Spring.
La présentation se déroulera le mardi 10 novembre de 14h à 16h. Les inscriptions se font comme d'habitude sur l'evenbrite.

Dans une architecture orientée service, le référentiel ou catalogue de services appartient à une famille de composants destinés à ce que l'on appelle généralement la gouvernance. La gouvernance est une notion évanescente, dont la définition fait l'objet d'âpres débats, mais qui, quelle que soit celle que l'on retient, renvoie au besoin de se doter d'outils et de procédures susceptibles d'assurer le contrôle de la complexité de l'architecture et d'en mesurer la consistance.

Le référentiel de service est un incontournable pour maîtriser les services.

Traditionnellement, et de façon macroscopique, un référentiel de services dans une architecture distribuée comprend deux grandes catégories de fonctionnalités :

• Les fonctions de registre qui visent à faciliter le fonctionnement de l'infrastructure de services :
• Contrôle d'accès.
• Correspondance entre les différents noms que peut porter chaque service dans les différents sous-systèmes.
• Localisation et routage.
• Transcodification et uniformisation des codes (y compris les codes erreurs).
• ...
• Les fonctions d'annuaire qui visent à consolider la connaissance métier :
• Etre la référence unique portant la connaissance des services de l'entreprise.
• Porter la connaissance des formats d'échanges.
• Distinguer les services qui nécessitent une réponse de ceux qui n'en attendent pas.
• Identifier l'appartenance fonctionnelle de chaque flux.
• Gérer les versions.
• ...

Les fonctions de registre sont destinées à l'exécution des services. Elles permettent aux consommateurs de services de localiser les fournisseurs (dans la version adéquate), d'identifier les modalités techniques de l'interaction, de valider les formats d'échange et de vérifier les politiques d'accès. Elles adressent aussi la dimension routage à savoir qu'à partir des informations de contexte, elles offrent la possibilité de déterminer le service cible, le mode d'accès (M.O.M., Web Services, ...), les ressources associées (nom de la file MQ, URL d'accès, etc.).
Ces fonctions de registre s'appuient le plus souvent sur le standard UDDI v3, et un ensemble de standards complémentaires pour les différentes métadonnées et stratégies (WSDL 1.1, SOAP w/wo Attachement 1.1, OASIS Web Service Security, XACML 1.0, SAML 2.0).

Les fonctions d'annuaire, quant à elles, offrent une large palette de fonctionnalités destinées aux personnels impliqués dans la mise en œuvre de la SOA : modélisation et structuration du référentiel, accès à la documentation des services, recherche, gestion du cycle de vie (éventuellement avec des processus d'approbation), analyse d'impact, reporting, etc. Ces fonctionnalités sont proposées au travers d'interfaces graphiques plus ou moins sophistiquées et ergonomiques.
Ces fonctions ne font pas l'objet de standards, et sont en conséquence un facteur de différenciation fort entre les offres logicielles.

Le référentiel assure donc la cohérence entre les différentes nomenclatures des applications.
Dans son acception classique, le référentiel doit être et rester l'unique point de référencement des services. Il constitue un composant central de l'architecture, et nécessite à ce titre des procédures de gestion et d'administration adaptées.

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

SOA

• SOA Manifesto : pragmatisme utopique ?
• WADL devient une Submission W3C

Le coin de la technique

• Play! Framework 1.0
• Mise à jour de VisualVM en 1.2
• Comment concevoir un datacenter, ... par Google
• Ca bouge dans la communauté Groovy/Grails
• Votre application web est elle vulnérable ?
• Artifactory : évolutions et mode SaaS

SOA

SOA Manifesto : pragmatisme utopique ?

La communauté SOA vient de publier son SOA Manifesto. Les valeurs sont très consensuelles, on pourrait même les trouver trop lisses quand on a vécu un naufrage SOA (avec l'oubli des objectifs métier, sa perfection naïve initiale, ses services faussement partagés qui finalement ne satisfont même pas le premier consommateur et autres ESB passe-plats).

Saluons tout de même cette initiative. SOA est une réalité. Les projets utopistes sont aujourd'hui minoritaires face à tous les projets qui intègrent des web services pour interconnecter les applications.
Le Manifeste SOA en français :
Valeur métier plutôt que stratégie technique,
Objectifs stratégiques plutôt que bénéfices spécifiques à un projet,
Interopérabilité intrinsèque plutôt qu'intégration propriétaire,
Services partagés plutôt qu'implémentation spécifique à un besoin particulier,
Flexibilité plutôt qu'optimisation,
Amélioration incrémentale plutôt que recherche de la perfection initiale.

Et rassurons-nous, ce n'est pas un manifesto qui empêchera les zélotes SOA de se déchirer. La guerre SOAP versus REST bat (toujours) son plein .

Ils parlent du SOA Manifesto : InfoQ SOA Manifesto, Stefan Tilkov's Weblog : Comments on SOA Manifesto.

Allez, je retourne à mes web services Contract First avec CXF .

WADL devient une Submission W3C

Marc Hadley, auteur de la spécification WADL et spec-lead de la JSR-311 (JAX-RS), a annoncé que WADL venait d'être accepté en tant que Submission W3C.

Cette spécification portée par Sun a pour but de définir un format XML de description de services REST. Il s'agit donc d'un équivalent à WSDL pour REST. Alors que REST-*, porté par JBoss, a récemment relancé le débat sur la tendance récurrente à vouloir intégrer dans REST les fonctionnalités des très controversés WS-*, la soumission de WADL au W3C fait réapparaître la question de l'intérêt de définir des contrats pour des services REST.

Joe Gregorio s'opposait vivement à l'initiative WADL il y a deux ans déjà. Il reprochait principalement :

• l'insuffisance de WADL pour définir élégamment tous les types de services REST
• la fragilité du client qui ne fonctionne plus lorsque le contrat change comme c'est déjà le cas avec WSDL
• le manque de réalisme de l'approche WADL2Java qui ne permettrait pas la pleine exploitation de REST. Il préférait donc une approche d'écriture du client REST manuelle, en se basant sur un socle commun.

Toutefois, l'approche "REST avec un contrat" est séduisante pour les applications d'entreprise dont les services sont souvent aussi nombreux que les consommateurs variés.
C'est dans cette logique que de nombreux projets lèvent les ambiguïtés de leurs services REST en préférant XSD à JSON. Les URL et paramètres d'appel restant alors décrits uniquement dans une documentation annexe.

Par ailleurs, on peut regretter que WADL n'ait pas mieux adressé que WSDL des problèmes aussi important que le versioning des services alors qu'un projet comme Apache Thrift a su être innovant sur le sujet.

La soumission de WADL au W3C n'implique donc pas forcément son succès à venir. La disponibilité en masse d'outils et de frameworks permettant de gérer ce format pourrait en revanche attirer une partie des adeptes de SOAP.

Le coin de la technique

Play! Framework 1.0

The Server Side nous annonce la sortie de Play! Framework en version 1.0.

Play! est un framework web de haute productivité (tout comme Grails ou Spring Roo) qui simplifie la création et le développement d'applications Web en langage Java. Ce framework full stack inclut tout une batterie de composants tels que Groovy (pour le templating), Apache Mina mais aussi Hibernate. Quant à l'architecture de vos projets Play!, elle sera de type RESTful.

Cette vidéo nous donne un bon aperçu du produit, surtout en ce qui concerne le fameux Fix the bug and hit reload ! c'est à dire pas de compilation, de déploiement ou de redémarrage serveur suite à la modification de vos classes Java, juste un rafraîchissement de votre navigateur pour voir vos modifications.

A noter que l'équipe travaille déjà sur la version 1.1 et, entre autres, sur le support de Scala

Pour les liens utiles, la documentation complète du produit se trouve sur cette page. Le téléchargement se passe par ici. Et, comme le rappelle TSS, n'oubliez pas la présentation Play! framework in practice à Devoxx, en tous cas nous y serons !

Mise à jour de VisualVM en 1.2

8 mois après la sortie de la version 1.1, l'équipe nous gratifie d'une nouvelle version de son outil de monitoring de JVM. Avec un passage de 1.1.1 à 1.2, il ne faut pas s'attendre à de grandes révolutions. Une liste de 31 bugs corrigés, suivie de quelques nouvelles fonctionnalités notables:

• Un sampling profiler CPU et mémoire
• Support de plusieurs instances de JStatd
• Amélioration de l'API de génération de graphes
• Sauvegarde d'un snapshot de l'application dans un fichier nps pouvant-être utilisé plus tard pour analyse

Nous vous passons les améliorations de GUI et le support des proxys qui peut toujours s'avérer utile pour les analyses à distance. La vraie grande nouveauté c'est le plugin permettant de profiler l'application par sampling. Il ne faut pas s'attendre à la précision des outils instrumentant l'application comme JXInsight. Cependant, cela permettra une analyse assez poussée sans impact sur les performances.

Comment concevoir un datacenter, ... par Google

Lors de la conférence Ladis 2009 (Large Scale Distributed Systems and Middleware), Jeff Dean, du groupe infrastructure chez Google, a présenté les manières de concevoir un système distribué.

Il passe en revue différentes problématiques :

• Infrastructure
• Stockage
• Clustering
• Échange de données sur le réseau
• Communication entre applications
• Construction d'application sur de telles infrastructures

Il est intéressant de voir les problématiques posées et les solutions proposées, sur des problématiques que nous avons trop tendance à oublier en tant que développeurs. Citons entre autres :

• Latence réseau : un critère important, car difficile à optimiser
• Bande passante du réseau
• Capacité de stockage (mémoire et disque)

Il est donc très important même pour un développeur d'avoir ces chiffres en tête.

Par retour d'expérience, Jeff Dean montre les joies d'interagir avec du matériel physique. Les applications ne doivent pas supposer que le matériel est infaillible, il y a différentes erreurs que nos applications doivent gérer. Quand on voit les nombres d'occurrences de ce type de problème et leur nature, leur gestion par l'application n'est pas aussi triviale qu'il y parait :

• Problème DNS
• Plantage de serveur
• Perte de connections
• ...

Cette présentation est très riche, et elle permet de voir les tenants et aboutissants d'une bonne infrastructure mais aussi les impacts que cela peut avoir dans nos développements de tous les jours.

Les contraintes que s'est imposé Google en terme de disponibilité, dimensionnement, ... ont amené plusieurs innovations technologiques en terme d'infrastructure qui ont des impacts sur le développement applicatif :

• Protocol Buffer
• MapReduce
• Google File System
• Big Table

Les lecteurs intéressés par les innovations mises en place par Google sur ses infrastructures noteront que Gregor Hohpe (auteur de Enterprise Integration Patterns) présentera à Devoxx une session Distributed Programming the Google Way.

Ca bouge dans la communauté Groovy/Grails

Pour commencer, on peut noter la longue présentation de Grails faite par Graeme Rocher sur InfoQ. Le "papa" de Grails revient sur de nombreux points relatifs à ce très bon framework permettant de créer des applications web rapidement en bénéficiant de la puissance de Java, Groovy, Hibernate, Spring...

Ensuite, et c'est la rançon du succès, il y a beaucoup de discussions et d'interrogations autour des besoins auxquels répondent Groovy et Grails. Sur son blog, Peter Delahunty précise par exemple que, pour lui, Grails n'est l'arme absolue que si on a une bonne connaissance des technologies sous-jacentes (Spring, Hibernate...). Il ne faut pas débuter par Grails sans s'attendre à bloquer sur des problèmes relatifs à ces technologies.

Cet article va dans le même sens et rappelle qu'à partir du moment où l'on parle de "la magie Groovy" il faut être conscient que des choses qui n'ont rien de magique (cela reste du code !) se passent. Les "dynamic finders", le MOP (Meta Object Protocol) et la magie des closures font rêver mais s'expliquent bel et bien ! Ensuite, il y est noté que la proximité de Groovy et Java fait que de nombreuses personnes pensent que l'on peut passer de Java à Groovy sans formation particulière. Si l'on ne comprend pas les principes de ces choses magiques et que l'on se contente de les accepter comme tels, on s'expose tôt ou tard à des retours de flamme sévères qui se matérialisent généralement sous la forme de StackTraces incompréhensibles. Enfin, le manque de support professionnel pour Groovy/Grails est évoqué. Sur ce point, je pense que l'auteur se trompe. On note en effet que Springsource semble fournir un support commercial pour ces technologies. Mais, il y a peu, Groovy et Grails n'étaient pas encore dans le giron de Springsource et l'on devait "se contenter" du support de la communauté. Néanmoins, celui-ci a toujours été assez réactif et de bon niveau.

Toujours concernant Groovy, on peut noter la version Community Edition de l'IDE IntelliJ, tout récemment publiée, semble bien lotie au niveau du support de ce langage. Malheureusement, le support de Grails, lui, n'est pas présent dans cette version.

Votre application web est elle vulnérable ?

Le Web Application Security Consortium (WASC) estime que 87% des applications de la toile sont vulnérables. Tout le monde ne peut pas s'offrir les services d'un expert en sécurité, et un développeur ne peut pas écrire du code sécurisé s'il ne connaît ou ne comprends pas les risques auxquels il s'expose. C'est pour cette raison que DeveloperWorks revient sur les principales failles de sécurité qui nous guettent, et quelques outils simples pour analyser notre code.
Les points de faiblesse les plus connus sont :

• le cross site scripting : le pirate injecte, via un autre site (de type forum par exemple), un script (de type javascript) vers le site visé. Ce script lui permet de récupérer des informations de connexion, des cookies...
• l'injection de SQL : le pirate saisit du code SQL dans un formulaire web. Celui-ci est poussé jusqu'à la base, exécuté et donne (le plus souvent) accès à la base 'en direct' au pirate (l'un des exemples le plus connus est l'injection de OR 1=1- dans un formulaire d'authentification, qui retourne alors toujours TRUE).

Et l'on reparle de l'OWASP, qui propose un outil open source pour détecter ces erreurs de conception : WebScarab. WebScarab s'utilise comme un proxy HTTP (qui se place entre votre browser et votre serveur d'applications, par simple redirection des ports). Ensuite, un simple fichier .txt permet d'injecter votre site avec quelques-uns des plus célèbres cas de cross site scripting ou d'injection SQL. Un autre outil open source est présenté, d'un fonctionnement similaire, Paros Proxy.
Reste ensuite à détecter les faux positifs, opération généralement manuelle.

On notera que la section Ressources de l'article original est richement fournie, et permet de réellement comprendre les risques auxquels sont exposées les applications accessibles sur internet.

Saurez-vous trouver les failles du site de test Webgoat ?

Artifactory : évolutions et mode SaaS

Artifactory est un repository Maven dont la principale particularité est de s'appuyer sur Java Content Repository (JCR) pour assurer le stockage des artefacts. Le choix de JCR plutôt qu'un simple système de fichiers n'avait pas fait l'unanimité car il rend les tâches courantes d'administration plus délicates. En effet, lorsque l'on veut supprimer, remplacer ou déplacer un ensemble d'artefacts, l'action est triviale lorsque le système de fichier est utilisé alors qu'elle devient plus complexe avec JCR, qui n'est pas aussi directement manipulable.

Conscient de ce problème JFrog, l'éditeur derrière Artifactory, a peu à peu intégré un certain nombre de fonctionnalités permettant d'effectuer ces tâches courantes d'administration des artefacts directement depuis l'interface Web. Ainsi, la dernière version du projet permet même le déplacement d'artefacts entre plusieurs repository.

Début septembre, JFrog a également lancé ArtifactoryOnline, un service d'hébergement de repository Maven Artifactory en mode SaaS (Software as a Service). Ce type d'offre répond clairement à un besoin puisque la présence d'un repository Maven est souhaitable pour de nombreux cas d'utilisation et que cette infrastructure nécessite du temps et du matériel dont ne disposent pas toujours les équipes de taille réduite.

Par ces innovations, le repository Maven de JFrog saura sûrement séduire les utilisateurs déçus par les solutions concurrentes que sont Nexus et Archiva.

Article mis à jour le 26/10/2009 à 21h25

Vous venez juste de boucler la première version de votre application, packagée par Maven. Vos intégrateurs ont préparé un environnement de recette et vous ont communiqué les informations de connexion à la console d'administration de votre serveur d'applications. Vous vous connectez, accédez aux fonctionnalités de déploiement et déployez le fichier EAR. Satisfait, vous démarrez votre navigateur pour vérifier que l'application tourne correctement. Mais quand vous essayez de charger la page, vous obtenez l'erreur DNS "Host not found". C'est donc le moment d'appeler un ami - l'administrateur de cette obscure infrastructure, qu'on appellera Michel. Michel est bien sûr très heureux d'ajouter un enregistrement DNS qui va permettre d'aller sur le serveur Apache à partir de l'URL www.app-in-dev.com. "Quoi ! Un serveur Apache ?" vous exclamez vous, "Mais ça devrait pointer vers notre serveur d'applications, pas du tout vers un quelconque serveur HTTP !".

Michel, qui a l'habitude de ce genre d'exclamation vis-à-vis de l'organisation des réseaux d'entreprise, explique calmement que toutes les requêtes partant d'un navigateur doivent d'abord passer par un serveur HTTP avant d'être redirigées vers le serveur d'applications. "Il est donc aussi nécessaire de configurer Apache !", dit-il. "Mais je développe une application Java, j'ai juste besoin de déployer sur un serveur d'applications et hop, terminé !" répondez vous. Et Michel d'expliquer sur un ton très sérieux : "Écoute fiston, appuyer sur le bouton de déploiement de ta console d'administration est juste une petite étape parmi toutes celles qui permettent de réaliser un vrai déploiement."

Rendre l'application accessible à l'utilisateur final

Avant de parler des différentes étapes du déploiement, il est important de comprendre quel est l'objectif d'un déploiement. De façon élémentaire, le but d'un déploiement est de "rendre une application, dans une version donnée, disponible pour les utilisateurs finaux". En d'autres termes, l'utilisateur ouvre son navigateur, tape www.app.com et voit l'application fonctionner.

Alors, que faut-il faire pour qu'une application fonctionne? Pour comprendre les composantes du déploiement, le plus simple est de suivre la requête depuis le navigateur de l'utilisateur à travers tous les composants matériels et logiciels par lesquels elle transite.
"La destination de la requête est tout d'abord résolue en s'adressant à un serveur DNS (ou à un mécanisme équivalent). La requête est alors routée vers sa destination ; elle est filtrée par un premier firewall, arrive sur le serveur HTTP chargé de la répartition de charge, traverse un nouveau firewall, atteint le serveur d'applications puis enfin l'application à proprement parler, exécutée sur le serveur, qui elle-même interroge une base de données pour récupérer les informations demandées par l'utilisateur."
Sur cet exemple simple, il y a au moins 5 composants en action pour rendre disponible l'application ; nous devons non seulement configurer ces 5 composants mais aussi y placer certaines données et s'assurer au besoin qu'ils (re-)démarrent dans un ordre correct.

Voici typiquement les étapes nécessaires au premier déploiement d'une telle application sur un environnement de production :

• (a) Exécuter les ordres SQL de création de tables sur la base de données
• (b) Configurer la source de données JDBC dans le serveur d'applications
• (c) Configurer les ports HTTP et les Virtual Hosts dans le serveur d'applications pour que l'application soit accessible par les requêtes HTTP
• (d) Installer l'application sur le serveur d'applications
• (e) Démarrer l'application
• (f) Configurer le firewall, en ouvrant les ports utiles à la communication entre le serveur HTTP et le serveur d'applications
• (g) Configurer le serveur HTTP, pour router vers le serveur d'applications les requêtes arrivant sur www.app.com et qui ne se terminent pas, par exemple, par .js, .html, .jpg
• (h) Déposer le contenu HTML statique (fichiers js, fichiers css, images, etc.) sur le serveur HTTP
• (i) (re-)Démarrer le serveur HTTP pour prendre en compte la nouvelle configuration
• (j) Configurer le firewall externe, pour permettre les accès de www.app.com vers le bon serveur HTTP

Bien sûr, dans un environnement plus complexe, on ajoute quelques étapes à la liste. Par exemple, dans un environnement clusterisé avec haute disponibilité, tout doit être fait au moins deux fois. Pour les déploiements de versions ultérieures de la même application, certaines étapes pourront de surcroît être négligées.

Des tâches nombreuses et variées

Les étapes décrites dans la section précédentes permettent de "mettre à disposition des utilisateurs" une application à l'architecture élémentaire. D'une façon plus générale, on peut distinguer plusieurs grandes catégories d'opérations à réaliser pour finaliser un déploiement :

• Installer l'application (Étape d)
  C'est la partie principale du déploiement, où la logique métier est installée sur le serveur, le plus souvent sous la forme d'un fichier EAR ou WAR.
• Configurer les ressources externes (Étape b)
  L'application peut avoir besoin d'interagir avec d'autres systèmes, comme une base de données, un mainframe ou un middleware de message. Les ressources externes sont le plus souvent utilisées par l'application pour obtenir ou diffuser des données. L'accès à ces ressources est généralement configuré au niveau du serveur d'applications.
• Configurer les composants intermédiaires (Étape a, c, f, g, h, j)
  Ce sont les composants qui permettent d'atteindre l'application, et de l'exécuter (par exemple, un cluster de serveurs d'applications, des instances de serveurs HTTP, des firewalls, etc.).
• Démarrer/Arrêter les composants (Étape e, i)
  Pour s'assurer que chaque composant fonctionne correctement, il peut être nécessaire de le (re-)démarrer.
• Et respecter l'ordre dans les points précédents

Pour être sûr que l'application démarre correctement, sans erreurs, un certain ordre doit être maintenu. Exemple : Si vous installez l'application (Étape d) et la démarrez avant d'avoir configuré la source de données (Étape b), l'application risque de ne pas se lancer correctement. Ceci devient encore plus important lorsque vous déployez une nouvelle version de votre application dans un environnement clusterisé.

Il y a une catégorie supplémentaire pour les organisations qui valident leurs applications successivement sur plusieurs environnements (Développement, Test, Intégration, Production) :

• Configurer l'application installée sur des environnements différents
  Un déploiement doit assurer la configuration spécifique à l'environnement. Exemple : Quand vous installez une application sur l'environnement de développement, il faut récupérer les données de la base de développement. De la même façon, pour l'environnement de tests, il est nécessaire d'avoir les données de tests et ainsi de suite.

L'EAR, la partie émergée de l'iceberg

Beaucoup pensent qu'installer un EAR sur un serveur d'applications équivaut à déployer l'application. Bien sûr, le bouton dans la console d'administration indique : "Déployer l'application", mais il ne s'agit que de la partie concernant le serveur d'applications à proprement parler ; cette vision étroite du déploiement n'est généralement opérationnelle que sur un environnement simplifié, comme celui de développement ou sur le poste de travail du développeur. Dès qu'une application doit être installée sur un environnement plus complexe, cette vision ne suffit plus et il devient nécessaire de réaliser un grand nombre d'opérations complémentaires pour véritablement "mettre l'application à disposition des utilisateurs".

Parce que de ce point de vue le déploiement n'est pas une opération triviale, beaucoup cherchent à l'automatiser.
Exécuter manuellement toutes les étapes est en effet à la fois complexe et risqué, particulièrement sur les environnements les plus critiques. Et ce, d'autant plus que, souvent, les responsabilités et les gouvernances de chaque module de l'infrastructure reposent entre les mains de personnes, d'équipes, voire de départements différents.
Malheureusement, cet effort d'automatisation aboutit souvent à un ou plusieurs jeux de scripts à la gouvernance floue et dont le coût de maintenance semble souvent prohibitif. Les solutions du marché n'abordent souvent qu'un sous-ensemble de la problématique (on pense à Phurnace ou BuildForge, qui restent concentrés sur le serveur d'applications, ou à d'autres solutions qui sont souvent de simples ordonnanceurs de scripts).
Avec les serveurs d'intégration continue, on peut mettre en œuvre des déploiements automatiques, qui permettent de tester la chaîne complète de la compilation jusqu'aux tests de charge (cf. Build Pipelines). Et si l'on veut aller encore plus loin, c'est-à-dire déployer automatiquement sur l'environnement de production, on peut se pencher sur le logiciel DeployIt, développé par mes collègues Hollandais.

Je parlerai, plus en détail, dans un prochain article du déploiement automatique et nous pourrons déterminer par nous-même si c'est une solution "Insane" comme le pense le livre blanc Enterprise CI Maturity Model de la société anthillpro ou une solution réelle pour améliorer la fiabilité comme le pense DeployIt.