insideIT.fr : le blog des architectes IT de SFEIR

Plus tôt dans le mois eurent lieu les Rencontres Spring. Durant cet événement, Peter Cooper-Ellis, qui pour rappel est VP de SpringSource depuis juin 2008 après 10 ans chez BEA, nous a fait le plaisir de partager sa vision de l'état du marché des serveurs d'application. En résumé, la demande est à la simplicité et à la flexibilité, d'où l'offre SpringSource dm Server.
Dans l'article "Changes in the Application Server Market" qu'il vient de publier sur JavaLobby et que je vous recommande vivement, il précise la raison d'être de ce nouveau produit SpringSource en retracant l'historique des serveurs d'application.

Bonne lecture et bon weekend.

Troisième et dernier jour du symposium…je n’ai pas gagné l’iPod qui était en jeu, dommage, j’aurais pu tester GWT dessus ;)

On commence par une conférence de Geert Bevin: Boldly go where the Java language has never gone before. On le sait, Java ce n’est pas qu’un langage, c’est un langage, une JVM et une plateforme, qui ont chacun leurs points forts mais aussi leurs limites. Dès lors, l’idée, qui est à la mode ces derniers temps, c’est que l’on peut remplacer ou modifier un de ces composants pour “pousser l’enveloppe” lorsque les limites se font sentir.

Geert cite 4 exemples pour illustrer cette approche.

1. Terracotta: il s’agit d’une extension de la JVM qui facilite la scalabilité des applications, en permettant de mettre des JVM en cluster. Déclarativement, certains objets (“shared objects”) sont répliqués entre toutes les JVM, et accédés indifféremment (avec du lazy loading) par toutes les instances. On a ainsi étendu le comportement natif de la JVM.
2. RIFE continuations: déjà évoqué hier au sujet de Comet, il s’agit pour prendre une image de prendre une photo de l’état d’un thread, comme un “save game” (c’est l’image donnée par Geert). On peut à tout moment appeler pause(), ce qui crée une sauvegarde et rend la main immédiatement, puis reprendre à partir de n’importe quel état avec resume(). Les continuations sont organisées en arbre (parent = continuation à partir de laquelle on a restauré). Encore une fois, on change la sémantique habituelle de la JVM dans sa gestion des threads.
3. GWT: on ne présente plus GWT, Geert fait un rappel des principes de fonctionnement (translation Java->Javascript, mode hosted vs. compilé, debugging, etc.). Ici on a remplacé l’ensemble du stack Java par une plateforme web pure, et seul le développement utilise le stack Java standard. Un participant pose la question du JavaScript généré, et Geert dit que pour lui c’est un problème, car le JavaScript généré est illisible et impossible à débugger… je bondis intérieurement, et j’irai voir Geert à la fin pour lui expliquer que pour GWT, le browser est la plateforme, la lisibilité du JavaScript généré est aussi peu importante que la lisibilité du bytecode généré par le compilateur Java! Je ne pouvais pas laisser passer ça…
4. Android: la plateforme mobile de Google. Comme pour GWT, le développement et debugging se font en Java, avec les IDEs habituels, et un émulateur de la plateforme mobile (équivalent au mode hosted de GWT). En revanche pour le déploiement, le bytecode Java est converti en bytecode (.dex) pour la machine virtuelle Dalvik, qui est l’équivalent de la JVM.

On aurait pu multiplier les exemples, notamment les langages dynamiques qui fleurissent sur la JVM, mais le point est fait. A mon sens, ces multiples extensions et détournements sont plus des preuves de la puissance de Java que de sa faiblesse, car Java reste toujours au centre d’un écosystème qui est plus bouillonnant que jamais.

Deuxième conf: JCR: TheServerSide as a Content Application. David Neuscheler (days.com) introduit JCR, version 1.0 (JSR 170) et 2.0 (JSR 283), les diférentes fonctionnalités d’un système de CM, etc. Puis il fait une démo en prenant une page du site TheServerSide.com, et en la transformant en appli client JCR. Pour tout dire c’est un peu fastidieux, et d’où je suis on n'arrive pas à lire le code ! J'aurais peut-être dû choisir la conf sur MapReduce dans l'autre salle...

Dernière conf du matin, Michael Keith présente What's new in JPA 2.0. Les objectifs étaient multiples:

• standardiser les propriétés
• remplir les manques de l'ORM
• rendre la modélisation objet plus flexible
• fournir une abstraction du contrôle du cache
• contrôle du verrouillage (locking)
• fournir des "hooks" pour des frameworks propriétaires
• améliorations JPQL
• etc.

Je ne vais pas détailler les nouveautés, mais globalement il semble que le groupe de travail JPA a bien écouté les utilisateurs, et lorsque JPA 2.0 sera sorti, il sera difficile de justifier l'utilisation directe d'une API de persistence propriétaire.Au passage, la présentation a été agrémentée d'une page culturelle sur les oies du Canada...

Comme hier et avant-hier, déjeuner avec un lance-pierres... et en plus ils ont enlevé les machines à café !

L'après-midi commence avec Choosing a Web framework, par Shashank Tiwari. En fait de conseils pratiques, il s'agit d'une énumération de définitions, de généralités, de questions (quel problème résout un framework, quel problème crée-t-il?), tout ça pour finir par dire que toutes les raisons sont bonnes de choisir un framework, y compris parce qu'il est à la mode ou pour faire bien sur son CV !!! Au final si on est en recherche d'un framework, cette conférence ne fait qu'ajouter à la confusion et à l'incertitude. Ou comment gâcher un bon sujet.

Case Study: Better Software with the Spring portfolio, par Eberhard Wolff (SpringSource Allemagne). Pour info, SpringSource est la société qui emploie tous les committers de Spring, mais aussi certains de Tomcat et Apache. Spring, outre le framework bien connu, c'est aussi dynamic modules, batch, integration, webflow, etc.

On nous propose un cas de système de traitement de commande à architecturer autour de Spring. Le système peut recevoir des commandes par Web Services. La démarche classique est de définir une interface Java, implémentée par un POJO, et de générer le WSDL à partir de cette interface. Or cette démarche présente des inconvénients: le WSDL expose de facto l'interface d'une classe interne.. que se passe-t-il si le WSDL doit changer? D'autre part certains types communs en Java, comme Map, ne sont pas supportés en WSDL...Eberhard propose d'inverser la démarche: puisque le contrat avec les clients est le WSDL, on part du WSDL et on base le traitement d'une commande sur le schéma XML correspondant. Ansi on n'expose pas d'interface interne, on traite un objet Java généré à partir du message envoyé, via un système de mapping (JAXB/XStream). La logique est découplée de l'interface. La classe qui traite le message est un Endpoint qui est annoté via les annotations Spring. Eberhard en profite pour rappeler que Spring est trop souvent assimilé à XML, mais qu'on peut très bien faire du Spring sans XML (ou presque, soyons honnête..)

Pour rendre robuste le WebService, on peut aussi baser le traitement du message sur des expressions XPath. Ceci permet d'avoir un contrôle plus fin sur des messages qui seraient incomplets, et donc ne pourraient pas être mappés avec la solution précédente.

Eberhard introduit également les notions de pipes et filtres, qui sont des pipelines de traitement, supportés par Spring Integration, et configurables par XML (tiens donc).

Spring fournit également une approche à la notion de batch, mal résolue en Java; notamment le problème des redémarrages en cas d'interruption volontaire ou non. Un batch Spring c'est une série d'étapes, chaque étape lit quelque chose (un record dans une base probablement) et écrit quelque chose (résultat du traitement). Cette notion est supportée par Spring batch.

Dernière conf de la journée, et du symposium: Real GWT applications, par Jeff Dwyer. Une énième présentation rapide des principes de GWT, et une petite démo sur le site tocollege.net, dont une partie est réalisée en GWT. Jeff fait une petite séance rapide de live coding, et montre le débugging en mode hosted. Puis il insiste, un peu trop peut-être, sur les problèmes pour envoyer des objets métier au client provenant d'hibernate: les proxies dynamiques cassent le mécanisme de sérialisation GWT. Il existe des solutions: Hibernate4GWT et GWTHibernateFilter. Je lui ferai remarquer à la fin que ce n'est pas forcément la meilleure idée, et qu'avec Dozer il est facile de populer des objets spécialisés pour les transmette au client, car je n'ai pas forcément envie de voir mes objets métier transiter sur le fil, on ne sait jamais ce qui peut s'y trouver demain...

Jeff conseille judicieusement d'utiliser un pattern Command pour les communications du client. Il aborde la sécurité, notamment les attaques XSRF, et présente Goggle Gears pour les applis offline.

La présentation était un peu rapide, mais l'intérêt pour la techno est évident. J'espère que cette présentation (qui a été donnée deux fois lors du symposium suite à la forte demande !) y aura contribué.

Ouf, le marathon est fini ! Beaucoup de choses passionnantes ont été présentées, et on sent qu'on est à un tournant car pour ainsi dire "ça part dans tous les sens", l'écosystème Java, aux frontières autrefois bien nettes, commence à devenir une galaxie en expansion avec des projets qui poussent l'enveloppe et repoussent sans arrêt les limites, des polémiques (et encore, on n'a pas abordé les closures !). Le monde Java de demain sera certainement bien différent de celui d'aujourd'hui, mais Java en restera probablement le centre de gravité...

Il me reste à visiter Prague (superbe ville) et regarder les Turcs se qualifier sur l'écran géant au centre ville...