Second jour à JavaOne

A nouveau une longue journée... on n'a qu'une envie, celle de profiter de tout ces intervenants et il faudrait se diviser en 15 pour y arriver ! Les choix de sessions se font donc malheureusement au détriment d'autres, probablement aussi intéressantes.

La "general session" du matin était présentée par Oracle, qui a commencé par annoncer la bienvenue aux équipe de BEA, récemment acquises. Les 5 grands principes sur lesquels Oracle met le focus sont SOA, Event Driven Business, Rich "2.0" Application et le GridConputing.
Les démonstrations mettaient en avant leur IDE, outil de RAD ou les palettes de composants donnent le vertige tellement il y en a, avec des options à n'en plus finir ! Ils intègrent également un composeur de services SCA et un orchestrateur BPEL graphique. La dernière démo mettait en oeuvre le serveur GridComputing de BEA avec l'utilisation de leur JVM JRockit "Real Time" et de son Garbage Collector deterministic, permettant de ne pas "bloquer" la JVM durant son exécution.

J'ai ensuite enchaîné par une session technique sur la réalisation d'une Appliance créée à partir d'OpenSolaris et GlassFish. Le but était de réaliser un "boitier" permettant de déployer et faire fonctionner une application web sans aucun talent d'administrateur. Cet appliance était administrable par un écran LDC de 20 lignes et une demi-douzaine de boutons. Pas très convainquant pour ma part, n'étant pas convaincu qu'il existe réellement une cible pour ce genre de serveur... L'intérêt était plutôt dans les features d'OpenSolaris comme le système de fichier ZFS ou le manager de service SMF.

Ensuite une session "Modularity in Java". JAM signifie JAva Module et instaure le mot clef "module" agissant comme un modificateur de visibilité (tel public ou protected) au sein d'un module. Il est vrai qu'aujourd'hui, lorsque l'on développe un composant logiciel (pour ne pas dire module) si des méthodes ou attributs doivent être appelée entre des packages différents, ils doivent être déclarés public. Alors que ce ne sont pas forcément des entités que l'on souhaite exposer à l'utilisateur du composant.
Un module possède des meta-données contenues dans un fichier module-info.java, composé d'annotations. on peut ainsi déclarer une version, importer d'autres modules, créer des dépendances inter-modules ou encore définir une classe d'initialisation.
Un nouvel outil, jam, sera disponible (similaire à l'outil jar).
Les dépendances intermodules sont gérés par la JVM au runtime, et sont gérés dans des classloader différents, où chaque classloader est managé par celui du module dont il dépend. On peut voir ainsi plusieurs versions d'un même module cohabiter dans une même JVM car ils ont été requis par 2 modules différents. On évite ainsi les classiques problèmes de version de JAR (qui n'a jamais eu de problème de version de parseur XML ?!?)
Le système de module JAM, par son API d'accès au repository de module, promet de récupérer et gérer les modules quelques soient le gestionnaire de module sous-jacent (OSGi par exemple). A voir en pratique...

L'après-midi débuta par une session sur JPA 2.0, assez décevante puisqu'on a eu droit à une simple énumération des nouvelles (et parfois anciennes !) annotations et leur fonction.
Pour rappel, l'implémentation de référence est EclipseLink.

J'ai poursuivi par une session sur l'asynchronicité avec les WebServices. Sujet intéressant qui abordait les problématiques côté client et côté serveur.
L'API JAXWS 2.X permet les appels asynchrones au niveau du client par la déclaration d'une méthode de callback.
La partie serveur peut etre assurée par l'utilisation de WS-Adressing, qui permet de définir au sein de l'enveloppe du WebService les données supplémentaire comme reply-to et fault-to pour que le serveur sache "où" répondre une fois que le traitement est fini, et le champ relates-to
qui contient l'identifiant du message d'origine, permettant au client de savoir à quelle précédente requête correspond la réponse qu'il reçoit.

J'ai assisté ensuite à une session très bien menée sur JMX (et ce n'est pas seulement parceque l'un des 2 speaker était français ;-) ) qui, après avoir présenté l'intérêt de JMX et ses nouveauté en version 2, a été l'occasion d'une démo très parlante et instructive.
Cette démonstration mettait en scène un logiciel de poker, qui exposé son état et des événements via JMX. Les 2 speaker ont "joué" en direct pour cette démo et le commencement de la partie en mettant leur lunettes noires a fait son petit effet :-).
Au niveau interopérabilité, la prochaine avancée est l'exposition et le management de ces MBean via des WebService. La démo présentait le fonctionnement réel avec les outils de management de Microsoft et un script VB.Net pour automatiser le tout.
Du travail bien préparé !

Pour finir la journée, j'ai assisté à BOF d'une heure chacune. La première était.... bof.... sur EJB3.1 à laquelle ils ne se sont contenté que de répondre à des questions. Et les questions n'ont tourné autour que d'un thème ou presque : la gestion des appel asynchrones avec les EJB (je ne pense pas personnellement que ce soit dans le scope des EJB de gérer cela... d'autres technologies sont bien plus à même d'y répondre).
Le second BOF était sur JMS, JBI et les transactions. JMS ne propageant pas les transaction, JBI adresse ce point. Le NMR (Normalize Messsage Router) assure les transaction XA (2 phase commit). BPEL quand à lui répond à la problématique de transaction sur traitements asynchrones ou traitements longs, par la gestion des compensation.
Avec cette solution, toutes les actions exécutées sont directement commitées, les actions de compensations sont exécutées si un événement d'erreur est déclenché. Le mécanisme de compensation a pour but d'exécutée les actions nécessaire au retour à l'état initial.
Et pour finir, le dernier BOF fut un retour d'expérience sur la mise en pratique d'un SOA au sein d'une entreprise ayant un système legacy important et vieillissant (cas classique s'il en est !).
Il était là plus question de méthodologie et d'approche que de technique pure. Bien plus instructif ! Le choix des objectifs, de la roadmap, de la définition de ce qu'est un bon projet pilote (must create business value but not too much ! has a limited scope, useful but not mission critical, ...). Et le maître mot que devrait mettre en pratique tout bon DSI : have an easy exit strategy ! Car si le projet ne fonctionne pas comme espéré, dans les délais prévus...... on connait la suite !


That's all folks (for today at least !)