SOA

• Spring Integration et Apache Camel : 2 ESB lightweight en action

Le coin de la technique

• Impala, la modularité pour Spring sans OSGi
• La définition de DataSources dans JEE 6
• Les google-collections sont finales !
• Spring Roo en 1.0.0 pour terminer l'année

SOA

Spring Integration et Apache Camel : 2 ESB lightweight en action

La mouvance SOA a amené un certain nombre de produits classifiés comme ESB (Enterprise Service Bus) dont le but est de répondre aux problématiques d'intégration courantes en entreprise. Dans un premier temps, ces produits prenaient la forme de middlewares très lourds dont la mise en œuvre devait être justifiée par des besoins importants. Il y a deux ans, nous assistions à l'avènement d'ESB qualifiés de lightweight car ils prenaient la forme de frameworks moins gourmands en ressources et plus simples à utiliser. Spring Integration et Apache Camel sont les deux principales options à envisager en matière d'ESB léger.

C'est justement de l'utilisation de chacun de ces deux frameworks que discute l'article que vient de publier Biju Kunjummen. Il y propose une problématique d'intégration qui consiste en l'exposition d'un service qui, lorsqu'il est invoqué, entraîne l'invocation multiple d'un même service de bas niveau via l'utilisation d'un pattern splitter sur la requête et d'un pattern aggregator sur la réponse. Les deux frameworks offrent nativement ce type d'EIP (Enterprise Intergration Pattern).

Aucun favori ne se démarque clairement dans la comparaison entre ces deux implémentations : Spring Integration vient s'intégrer naturellement à l'Application Context de Spring en reprenant le même type de structure de définition XML, tandis qu'Apache Camel, bien qu'offrant également la possibilité d'une configuration XML, sera surtout apprécié pour son DSL Java permettant la définition des routes d'intégration.

Le lecteur intéressé par ces deux frameworks pourra se tourner, au-delà des documentations respectives, vers les deux livres en préparation chez l'éditeur Manning, Spring Integration in Action et Camel in Action, prévus pour l'été prochain.

Le coin de la technique

Impala, la modularité pour Spring sans OSGi

La modularité est un sujet porteur en ce moment, tant du côté du JDK avec Jigsaw, que du côté Java Entreprise avec OSGi dont le principal acteur actuellement est sans conteste SpringSource avec Spring Dynamic Modules et son serveur d'application associé Spring dm Server.

Phil Zoio a été interviewé il y a peu pour présenter le projet Open Source qu'il a fondé : Impala. Il s'agit d'une vision différente de la modularité pour applications d'entreprise. Ainsi, Impala repose sur Spring, tout comme Spring Dynamic Modules, mais contrairement à ce dernier, il n'utilise pas OSGi et adopte une stratégie radicalement différente : il constitue lui-même des modules encapsulant chacun un application context qui déclare un certain nombre de beans. La solution de modularité ainsi produite offre tout comme OSGi un fonctionnement dynamique permettant le chargement à chaud de nouveaux modules.

Dans un climat où beaucoup s'interrogent sur la potentielle lourdeur d'OSGi, ce type d'initiative proposant une solution alternative plus simple face au standard prend tout son sens et n'est pas sans rappeler l'offensive de Spring Framework lui-même, il y a quelques années, face au contesté standard EJB.

La définition de DataSources dans Java EE 6

Matt Corey poste cette semaine un article mettant en avant une facilité rarement (jamais ?) évoquée de Java EE 6 : la configuration des sources de données par annotation. En effet, si la nouvelle spécification de Sun est largement couverte depuis des mois, y compris sur notre blog, il est en général question des nouveautés qui retiennent le plus l'attention telles que les beans singletons d'EJB 3.1, l'API query builder de JPA 2.0 ou encore ses nouveaux modèles de composants.

En fait il s'agit d'une standardisation de la technique de configuration des sources de données dans les serveurs d'application Java EE. Cette définition était en effet jusqu'alors un détail d'implémentation des serveurs et n'était donc pas portable. Cette configuration peut donc maintenant se faire par l'annotation @DataSourceDefinition ce qui évite ainsi l'utilisation de XML et va donc dans le sens de la logique initiée depuis Java EE 5. L'exemple suivant permet de mieux se rendre compte de son utilisation :

Si tout le monde n'appréciera pas forcément d'avoir recours à une annotation pour ce type de configuration, les projets souhaitant distribuer des war ou ear portables qui se connectent à une base de données embarquée ou locale devraient en revanche y trouver leur compte.

Les google-collections sont finales !

Annoncée sur la users list du projet, l'API google-collections passe en version finale 1.0.
Pour ceux qui ne connaissent pas encore cette API de collections type-safe, rendez-vous sur cette page pour une introduction à la librairie.

La finalisation de Google Collections constitue un changement majeur dans l'environnement des développeurs Java. En effet Apache Commons Collections constituait jusqu'alors le principal complément à l'API de base du JDK. Or, la librairie de la fondation Apache est vieillissante et ne propose toujours pas les generics de Java 5. Google Collection se positionne donc ni plus ni moins que comme un remplaçant.

La FAQ répondra à bon nombre de questions que l'on peut se poser sur cette API notamment sur les raisons qui ont poussé Google à créer sa propre API plutôt que de contribuer à Commons Collections.

Enfin on notera que Google Collections sera intégré à Guava sous peu pour constituer la librairie d'extension du JDK de Google.

De par la nature de ces APIs, Google Collections et Guava peuvent également constituer un premier pas vers la programmation un peu plus orientée fonctionnelle. A ce sujet, il est aussi possible de regarder du côté de lambdaj, une API de parcours de collections sans boucle explicite. Et pour ceux qui souhaitent aller encore plus loin, rendez-vous sur functional.java ou  tournez vous vers la préparation des closures dans Java.

Spring Roo en 1.0.0 pour terminer l'année

Encore une release pour Spring pour clôturer en beauté l'année 2009. Bravo!
Spring Roo, 8 mois après sa première version alpha, vient de sortir en 1.0.0. Roo, en quelques mots, permet de développer des applications plus rapidement en générant et maintenant, tout au long des développements, une partie importante du code source (du POJO à la JSP).
Un effort a été mis sur la documentation qui a intégré un tutoriel et les commandes. La seule partie encore en travaux est le chapitre 3, celle qui concerne le fonctionnement interne de ROO. Cette partie permet entre autres d'avoir les bases pour développer des extensions.
En standard, Roo propose déjà des extensions, comme par exemple les fonctionnalités de sécurité, basées sur Spring Security et des flows avec Spring Webflow.

Spring Roo présente un formidable intérêt pédagogique, car il s'appuie systématiquement sur les toutes dernières versions des jars de Spring et d'Hibernate.
On peut par contre trouver peu commode son mécanisme interne qui se base sur la technologie AspectJ. Son principe est de générer les méthodes de classe en se basant sur des fichiers d'aspects. Jusqu'à présent, notre expérience avec Spring Roo a montré que cela ne fonctionnait pas de manière complètement transparente pour le développeur, même avec l'Eclipse de SpringSource (STS). Cette limitation pourra donc dissuader certaines équipes de partir sur un projet avec ROO tout au long des développements.

Voici sur Slideshare, les deux présentations mises en ligne par le leader du projet, Ben Alex:

• Introduction To Spring Roo 1.0.0
• Spring Roo 1.0.0 Technical Deep Dive

Actualité éditeurs / SSII

• SpringSource et Oracle ensemble pour l'OSGi d'entreprise

Le coin de la technique

• Lucene passe à Java 5
• Mark Reinhold justifie l'introduction des closures
• Patterns NoSQL

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

• Devoxx 2009 : le bilan

Actualité éditeurs / SSII

SpringSource et Oracle ensemble pour l'OSGi d'entreprise

Adrian Colyer, SpringSource, a annoncé la création d'un nouveau projet au sein de la fondation Eclipse : Gemini. Il s'agit d'un sous-projet d'Eclipse Runtime qui a pour but de réunir l'ensemble des implémentations de référence des spécifications OSGi liées au monde de l'entreprise. Il s'agit d'un effort commun de SpringSource et d'Oracle.

Deux composants fondamentaux sont apportés par SpringSource :

• Gemini Web Container : il permet le fonctionnement d'un conteneur de Servlets dans un environnement OSGi. Cette implémentation est actuellement utilisée dans SpringSource dm Server et est donc prévue pour fonctionner sur Tomcat. Mike Keith, Oracle, assure que l'adaptation pour Jetty arrivera par la suite grâce à une collaboration avec l'équipe de ce projet.
• Gemini Blueprint Service : il s'agit de Spring Dynamic Modules. Ce projet, qui a fortement inspiré la spécification du Blueprint Service intégré à OSGi 4.2, devient logiquement son implémentation de référence.

Il est important de noter qu'Adryan Colyer explique que SpringSource continuera désormais le développement de ces deux projets directement au sein de la fondation Eclipse et non plus en interne.

Oracle, pour sa part, apporte plusieurs implémentations de référence pour des RFC supplémentaires non intégrées à la spécification OSGi 4.2 : RFC 98 (transactions), RFC 122 (database access), RFC 139 (JMX integration), RFC 142 (JNDI integration), RFC 143 (JPA integration), RFC 146 (JCA integration).
Mike Keith indique qu'EclipseLink est à même de fonctionner correctement avec OSGi depuis longtemps, mais qu'il n'implémentait pas JPA lorsque cette intégration a été mise en œuvre au sein du projet. Par conséquent, une adaptation est nécessaire pour passer à la RFC 143, afin d'assurer une intégration JPA standard.

Alors que la spécification 4.2 a été finalisée il y a 2 mois, les implémentations de référence étaient toujours attendues. Cette réunification des implémentations liées a l'OSGi d'entreprise au sein d'un même projet Eclipse est une excellente nouvelle : elle met en avant la standardisation dont on pourra désormais bénéficier pour les développements intégrant OSGi dans les applications JEE. Mais cela suffira-t-il à démocratiser OSGi en entreprise ?!

Le coin de la technique

Lucene passe à Java 5

L'équipe du projet Lucene annonce la sortie de Lucene 3.0. Comme nous l'expliquions précedemment, cette version marque une évolution majeure puisqu'elle est la première a nécessiter Java 5.0 au minimum.

L'API bénéficie donc désormais de l'ensemble des améliorations du langage de Java 5.0 dont les generics, le varargs, les enums et l'autoboxing.

Tempérons cette annonce : l'API Lucene n'a pas été refondue, il ne s'agit que de quelques améliorations visant à la rendre type-safe. Citons par exemple :

• Apparition d'enums BooleanClause.Occur, Field.Index, Field.Store et Field.TermVector ; ces concepts étaient jusqu'alors représentées sous forme de constantes type-safe.
• La méthode getFields() de la classe Document retourne désormais une List<Fieldable> alors qu'elle retournait une simple List jusqu'alors.
• La classe Term implémente désormais Comparable<Term> et non plus simplement Comparable.

Ces changements légers décevront peut-être certains utilisateurs lassés par l'API vieillissante de Lucene, mais on appréciera toutefois la facilité de migration, puisqu'il s'agira la plupart du temps de supprimer quelques casts (l'équipe Lucene cite quelques cas à surveiller lors de la migration).

Cette nouvelle version, qui apporte par ailleurs quelques modifications mineures, conclut donc un cycle d'évolutions importantes sur le projet Lucene.

Mark Reinhold justifie l'introduction des closures

C'était l'Annonce de cette édition de Devoxx, l'apparition des closures en Java 7. Mark Reinhold revient, sur son blog, sur les raisons à l'origine de cette petite bombe.
Il justifie cette évolution majeure du langage par la nécessité pour Java de tirer partie des nouvelles générations de processeurs, multi-cœurs.
Jusqu'ici, pour exploiter cette puissance, il fallait utiliser des Parallel Array et tout le code inutile nécessaire à leur fonctionnement. Les closures permettent de supprimer ce code, et il est temps de les introduire en Java.
Java doit se concentrer sur deux fonctionnalités clés : la syntaxe littérale, et les fonctions typées. L'arrivée des closures requiert deux autres évolutions de Java : les conversions, et l'extensibilité des méthodes.
Il est temps pour Mark Reinhold d'oublier les querelles. Sun spécifiera et implémentera un premier jet des closures pour le JDK 7. Cela permettra une expérimentation à grande échelle, et si tout se passe bien, cela conduira à une JSR de modification du langage, qui pourra être incluse dans Java SE 7.
La tâche est immense et Mark Reinhold appelle bien évidement toutes les bonnes volontés à contribuer.

Bien au-delà de la manipulation du multi-threading, les closures pourraient permettre une simplification des APIs courantes. Cette perspective semble essentielle à Mark Reinhold qui ne pouvait attendre le JDK 8 pour une nouvelle tentative, dans 3 à 4 ans...

Patterns NoSQL

Nous vous parlions récemment dans une revue de presse et un article du mouvement NoSQL, qui se caractérise par "une absence de requête et par un relâchement des caractéristiques ACID propres aux RDBMS". Ricky Ho, architecte chez Adobe, revient sur son blog sur les caractéristiques communes de plusieurs technologies permettant de "faire du NoSQL", et extrait quelques patterns récurrents. Ne vous arrêtez pas à la mise en page étriquée de l'article, car la description est très complète. Ricky Ho y explore successivement:

• Les types de noeud possibles (physiques et virtuels) ainsi que leur fonctionnement.
• Le partitionnement des données.
• La réplication de ces données, ainsi que le maintien de leur consistance.
• La gestion des pannes.

On notera quand même que l'une des solutions retenue pour le stockage des données reste... une base de donnée relationnelle ! Humour mis à part, une telle formalisation de patterns est vraiment bienvenue dans un environnement aussi émergeant.

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

Devoxx 2009 : le bilan

Nous concluons aujourd'hui notre série de billets sur Devoxx 2009. Ces 5 jours passés à Anvers furent riches en informations et en rencontres et nous souhaitions vous les faire partager.

A l'heure du bilan, voici ce que nous retiendrons de cette édition :

• Les annonces concernant JDK 7, JEE 6 et Maven 3.0.
• Le succès de JEE 6 : toutes les sessions sur le sujet ont fait salle comble.
• La place réservée à la nouvelle plateforme Flash d'Adobe, présente au keynote et dans de nombreuses sessions ; il est intéressant de noter que cette place correspond exactement à celle occupée par JavaFX lors de la précédente édition.
• L'omniprésence de Scala ; au-delà des sessions qui lui étaient consacrées, il était cité dans beaucoup d'autres présentations lorsqu'il était question de DSL par exemple.
• L'intérêt persistant de la communauté pour le Cloud Computing. Ce nouveau concept a rencontré un large succès à Devoxx.

Pour rentrer plus en détails dans les enseignements de cette conférence, vous pouvez désormais retrouver l'intégralité de nos billets Devoxx :

• Devoxx - Jour 1 - Adobe University
• Devoxx - Jour 1 - Applications robustes avec Amazon EC2
• Devoxx - Jour 1 - Kanban in action
• Devoxx - Jour 1 - JSF 2
• Devoxx - Jour 1 - NoSQL avec HBase
• Devoxx - Jour 2 - Google App Engine
• Devoxx - Jour 2 - Les effets avec Flex 4
• Devoxx - Jour 2 - Hibernate Search
• Devoxx - Jour 2 - Java FX The developer guide
• Devoxx - Jour 2 - SOA en pratique
• Devoxx - Jour 2 - Scala Actors
• Devoxx - Jour 3 - Spring Actionscript
• Devoxx - Jour 3 - ScalaTest
• Devoxx - Jour 3 - La keynote
• Devoxx - Jour 3 - JEE6
• Devoxx - Jour 4 - Maven Reloaded
• Devoxx - Jour 4 - Java Performance Tuning
• Devoxx - Jour 4 - Intégration pour le Web avec iBeans
• Devoxx - Jour 5 - Projet Lombok

Actualité éditeurs / SSII

• Google lance son langage pour la JVM
• iBeans : la solution d'intégration pour applications Web de MuleSoft

Agilité

• Pair programming à distance sous Eclipse avec Saros

SOA

• L'initiative REST-* fait débat

Le coin de la technique

• OSGi 4.2
• Scala OSGi-fié
• Astuces de performance pour MySQL
• Enquête sur les temps de redémarrage des serveurs JEE
• Premiers pas avec memcached

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

• Soirée Tontons Flexeurs le 24 Septembre

Actualité éditeurs / SSII

Google lance son langage pour la JVM

Lors du JVM Language Summit de la semaine dernière, Google a présenté son nouveau langage pour la JVM appelé Noop. Le Wiki du projet et sa présentation permettent de faire le tour des spécificités de ce langage :

• Syntaxe prévue pour être facilement compréhensible par un développeur Java ou C++
• Pas de types primitifs, pas de classes ou méthodes statiques, variables non mutables par défaut, pas de syntaxe optionnelle, exceptions uniquement de type unchecked
• Librairie standard s'appuyant sur JodaTime, util.concurrent et Google Collections
• Support natif du concept d'injection de dépendances offert par Guice ou PicoContainer, un type est alors soit newable soit injectable
• Support natif des tests unitaires qui ont leur structure dédiée sans classes ni méthodes

Les réactions qui ont suivies cette annonce montrent en général un intérêt couplé à une réserve légitime due à l'état embryonnaire du projet. Ainsi l'analyse de Dominique de Vito s'inscrit dans ce schéma, tandis qu'Alexis Moussine-Pouchkine, Sun, explique à 01net qu'il trouve enrichissant la profusion de nouvelles idées mais que, selon lui, le langage Java restera malgré tout omniprésent pendant encore des années.

Reste que là où de nombreux nouveaux langages justifient leur existence par une syntaxe plus compacte, une nature dynamique ou encore des concepts élaborés, Noop semble adopter une approche plus pragmatique et plus proche des besoins quotidiens rencontrés en informatique de gestion. L'avenir nous dira si les apports de ce langage sont suffisants pour convaincre des équipes de le préférer à Java pour leurs développements.

iBeans : la solution d'intégration pour applications Web de MuleSoft

MuleSource, récemment renommé en MuleSoft lors du lancement de leur offre Tcat Server a récemment diffusé une première beta public d'un nouveau produit : Mule iBeans. Il s'agit d'une nouvelle solution d'intégration s'attaquant à un marché différent des ESB traditionnels. MuleSoft part en effet du constat que de nombreuses applications Web doivent s'intégrer avec diverses ressources distantes, mais ne peuvent s'appuyer sur un ESB qui constituerait une solution trop lourde. iBeans se positionne ainsi en tant que solution d'intégration pour applications Web. La nuance est légère par rapport aux ESB mais on constate clairement cette orientation dans la pratique : annotations, composants iBeans, injection de services type IoC avec un contexte request, ...

La particularité principale du projet est son modèle de composant iBeans. Il s'agit de composants similaires aux Beans Spring ou aux Session Beans EJB mais spécialisés dans l'accès à un service à distance. Ces composants utilisent certaines annotations de la récente JSR-330 (Dependency injection for Java) et peuvent s'intégrer facilement avec Spring, Struts et JSF.

MuleSoft propose parallèlement un projet nommé Community iBeans Proposals visant à regrouper les iBeans de la communauté pour intégrer les ressources les plus fréquentes.

iBeans répond à un besoin courant des applications Web. La réponse proposée par MuleSoft est élégante mais on pourra regretter l'apparition d'un modèle de composant supplémentaire disposant de son propre cycle de vie. Actuellement l'éditeur n'a pas communiqué sur son projet naissant en dehors de la page Wiki dédiée. Une recherche Google montre rapidement que la communication autour de ce projet est quasi inexistante. Toutefois, une session dédiée au sujet prévue pour Devoxx 2009 tend à nous faire penser que la célèbre conférence européenne pourrait bien servir de rampe de lancement au nouveau projet de MuleSoft.

Agilité

Pair programming à distance sous Eclipse avec Saros

L'université de Berlin propose depuis quelques temps un plugin Eclipse nommé Saros, offrant des fonctionnalités permettant le pair programming à distance grâce au protocole XMPP. Concrètement les possibilités sont :

• Reproduction ou synchronisation d'un projet Eclipse à distance via une connexion XMPP.
• Visualisation dans l'environnement de l'observer des classes ouvertes et de la classe en cours d'édition par le driver.
• Affichage en temps réel des modifications du code, et de la position du curseur et du texte sélectionné.
• Gestion expérimentale d'un mode multi-driver permettant de modifier le code à deux simultanément.
• Chat via une vue dédiée dans Eclipse

Un screencast est proposé sur le site du projet, celui-ci permet de se rendre compte des capacités du plugin.

Idéalement complété d'une conversation Skype, ce plugin trouvera sa place dans de nombreux scenarii allant du distributed pair programming à l'assistance d'un collègue situé à un autre étage.

SOA

L'initiative REST-* fait débat

JBoss vient de lancer le site REST-*.org hébergeant son initiative de standardisation de plusieurs services middleware traditionnels sur le modèle REST.

Actuellement deux drafts sont en cours de rédaction, l'un porte sur RESTful Messaging, l'autre sur RESTful Transactions. Ces deux spécifications visent à définir un ensemble d'URIs standards sur le modèle REST permettant d'exposer une ressource transactionnelle ou un broker de messages.

Très rapidement, de vives réactions sont apparues au sein de la communauté, principalement pour faire part de leur scepticisme quant à cette initiative, régulièrement comparée à la très lourde collections de spécifications WS-*, qui pourrait mettre à mal la simplicité unanimement reconnue du modèle REST. C'est ainsi le cas d'Anne Thomas Manes qui revient également sur les critiques de Bill Burke à l'égart de l'initiative RestMS qui existait déjà et qui pariait plutôt sur Atom et AMQP.

Bill Burke de son coté publie sur son blog un billet par jour depuis la publication sur le site REST-*.org, pour justifier ses choix et la légitimité du projet qu'il porte. Ses arguments portent principalement sur le fait qu'il existe une demande très forte de la communauté pour gérer les services de messaging et les transactions avec REST.

Le débat est compréhensible : la volonté d'exposer certaines ressources transactionnelles ou services de messaging s'inscrit dans les besoins courants des entreprises, tout comme les craintes de voir se reproduire les erreurs du passé sont légitimes. L'apport de cette initiative est donc probablement de porter sur le devant de la scène une réflexion sur un problème pourtant courant et déjà exposé par Leonard Richardson et Sam Ruby, il y a deux ans, dans leur livre majeur RESTful Web Services.

Le coin de la technique

OSGi 4.2

OSGi est sur le devant de la scène, d'InfoQ à OSGi Thoughts en passant par The Programming Delusion (BJ Hargrave, CTO de l'OSGi Alliance), depuis une petite semaine et pour cause : l'OSGi Alliance a sorti et mis à disposition le 16 septembre dernier les spécifications finales de la version 4.2 (téléchargeables ici).

Alex Blewitt nous résume la situation sur InfoQ. On retiendra qu'Equinox et Félix ont déjà commencé leur travail de compatibilité avec OSGi 4.2. Les spécifications étant désormais released, ce n'est qu'une question de temps avant que les projets affichent fièrement leur label OSGi 4.2 compliant.
On notera aussi une nouvelle méthode de lancement du runtime OSGi, le nouveau nom des Distributed OSGi qui deviennent les Remote Services (connexion de VMs OSGi), les Blueprint Services qui seront des services wired à la Spring, le concept de Bundle Tracker ou bien encore le mécanisme de permission sur une opération dans un bundle.

Pour la petite piqure de rappel, on pourra se tourner vers JavaLobby qui nous propose depuis quelques jours 2 tutoriaux HelloWorld sur OSGi, le premier avec Swing et le second avec Spring RC.
Et pour les plus nostalgiques, le Paris JUG sur OSGi, c'était (déjà) il y a 1 an...

Scala OSGi-fié

On reste dans les news OSGi avec un projet qui propose Scala 2.7.6 en version OSGi-fiée (vu ici).

Comme expliqué sur le GitHub du projet, Scala n'est pas (encore) packagé en bundle OSGi. Certes, le plugin Eclipse Scala IDE utilise un bundle OSGi qui embarque Scala mais celui-ci ne peut pas être utilisé de manière générale (manifest spécifique et toutes les librairies dans un seul jar).

scala-lang-osgi répond à ce besoin et fournit un bundle OSGi pour chaque librairie Scala. Le tout est disponible sur le repository maven scala-tools.org.

Astuces de performance pour MySQL

Même si nos ORMs préférés génèrent des requêtes optimisées à notre place, il arrive parfois que, pour des raisons de performances ou autres, l'on doive écrire certaines requêtes directement en SQL.
Le site Debian Admin (par Code Purity) référence à cette fin 84 astuces d'optimisations de performances pour MySQL.
Certes, la plupart des astuces de configuration de MySQL sont peut-être/certainement déjà mises en place par nos chers DBA. Mais on trouvera aussi une pléiade d'astuces concernant la requête elle-même : cela passe de la non utilisation du gourmand SELECT *, d'éviter au possible l'utilisation de DISTINCT (très consommateur), d'utiliser pour l'insertion des BATCH INSERT et REPLACE ou bien encore l'utilisation INET_ATON et INET_NTOA au lieu de CHAR et VARCHAR pour les adresses IP.
Pour le détail complet, rendez-vous directement sur le site de Debian Admin.

Enquête sur les temps de redémarrage des serveurs JEE

ZeroTurnAround, l'éditeur de JRebel, a mené (et continue même à collecter des données) une étude sur les temps de redémarrage / redéploiement des serveurs d'applications auprès des lecteurs de son blog (environ 700 personnes ont répondu).
Tout d'abord, passons sur la conclusion évidente de l'étude, vous avez besoin de JRebel, pour tenter de voir au delà de cette évidence marketing. On évitera aussi la polémique sur le rapprochement Conteneurs de Servlets / Serveurs d'applications.
On constate tout d'abord que la population fréquentant le blog de ZeroTurnAround (on a donc dès le début une information en partie biaisée) a une forte tendance à confier ses applications à une plate-forme basée sur Tomcat (JBoss + Tomcat), plutôt qu'aux historiques IBM et BEA Oracle. Là encore, étant donné la notoriété naissante de JRebel, au sein d'une communauté plutôt tournée vers l'open source, rien d'étonnant.

En revanche, il est intéressant de constater que les temps de redéploiement deviennent assez rapidement délirants, avec des serveurs qui en moyenne mettent entre 2 et 5 minutes à redémarrer, la palme de la lenteur revenant, on le savait déjà par expérience, aux gros serveurs monolithiques commerciaux. Alors, au-delà du constat qu'un développeur passe aujourd'hui une grande partie de son temps à attendre que son application se mette à jour sur son serveur d'applications, au-delà du fait que JRebel est une des manières d'adresser ce problème, nous nous posons la question suivante : est-il normal, pour un serveur d'applications, de mettre cinq minutes à redémarrer ?

L'actualité de cette revue de presse met en avant OSGI, qui sera certainement une des réponses apportées à cette explosion des temps de démarrage. Ce sont d'ailleurs les absents de cette étude qui porteront la première estocade : GlassFish 3.x et dmServer.

Premiers pas avec memcached

Dans le but de proposer une implémentation d'un système de cache pour Grails, James Goodwill, sur DeveloperWorks, propose, dans un premier temps, une découverte du système de cache distribué memcached.
Une mise en bouche qui permet de découvrir les bases de ce produit, avant de combiner ce cache avec Grails dans une seconde partie, qui, on l'espère, permettra d'optimiser les performances du plus célèbre des frameworks haute productivité.

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

Soirée Tontons Flexeurs le 24 Septembre

Suite des Tontons Flexeurs, après la très bonne soirée Flex et Java en entreprise, avec une nouvelle session ce jeudi 24 septembre. 2 invités de marque : Mike Chambers et Lee Brimelow qui nous feront une présentation d'Adobe AIR (techniques avancées de synchronisation de données, de manipulation de fichiers, possibilités d'intégration à la plateforme hôte...) et des nouvelles fonctionnalités des prochaines versions de AIR.

A l'heure où nous écrivons ces lignes, il reste encore quelques places disponibles donc rendez-vous sur le formulaire d'inscription de l'évènement.

RIA

• Vaadin 6
• Adaptateur Gilead pour GAE
• Une série d'annonces chez Adobe

Le coin de la technique

• Scalabilité avec Hibernate et Shards
• Jigsaw vs OSGi
• Pourquoi utiliser un portail ?
• Embarquer le Web dans Java avec JWebPane

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

• Xebia @ Jazoon 09

RIA

Vaadin 6

Au revoir IT Mill Toolkit et bienvenue à Vaadin (vu sur leur blog) !

Pour ceux qui ne le connaissent pas encore, Vaadin (anciennement IT Mill Toolkit) est un framework de développement d'applications RIA qui s'appuie sur GWT. Sa particularité est d'être runtime donc aucune compilation spécifique n'est demandée avant de packager la webapp (à l'inverse de GWT).

Simple changement de nom ? En tout cas très peu de changement côté API selon les auteurs du framework. Il faut plutôt se tourner vers l'outillage pour voir quelques nouveautés : un plugin eclipse (création de projets, de composants UI, de thèmes...) et, inclus dans le plugin, un éditeur WYSIWYG.

Côté liens utiles, l'habituel showcase, le livre et la comparaison maison avec les autres frameworks du marché (et la concurrence est rude dans le monde du RIA).

A noter que Vaadin sera présent à Jazoon pour une conférence sur RIA Security le mardi 23 juin à 15h (slides, projet et autres sur cette page).

Adaptateur Gilead pour GAE

Vous connaissez GWT, Gilead, et Google App Engine ? Et bien il ne reste plus qu'à mélanger tout ça et on obtient le Gilead GWT adapter for Google AppEngine (vu sur le GWT Blog).

Tout démarre d'un thread google groups avec comme point de départ la serialization exception lancée par les entités persistantes transférées vers GWT. Évidemment, la solution qui ressort très rapidement, outre l'utilisation de DTOs, est de passer par Gilead pour transformer nos entités persistantes en POJOs. Il suffit d'ajouter le jar adapter4appengine et de remplacer la classe PersistentRemoteService par EngineRemoteService dans vos remotes services. Dès lors, il sera possible d'envoyer ses entités persistantes vers le client GWT sans exceptions de sérialisation sur GAE.

1.0 M2 téléchargeable à cette url, documentation par ici. Attention toutefois, cette version n'est pas production ready.

Une série d'annonces chez Adobe

Après l'annonce de la sortie de la plateforme Flash il y a quelques semaines, voici une nouvelle série d'annonce de la part d'Adobe.

Pour commencer, deux news relayées par Andrew Twice dans InsideRIA.
La première concerne la sortie d'Adobe Table en version bêta. Cet outil permet de créer des feuilles de calcul, des plannings ou encore des listes de tâches en ligne:

• Les utilisateurs peuvent ajouter des données en même temps: les données sont mises à jour en temps réel pour tout le monde.
• Possibilité de savoir qui travaille sur Adobe Table.
• Création d'écrans communs et privés : les utilisateurs peuvent travailler de manière coopérative, et/ou créer des espaces privés pour ne garder que les informations importantes.
• Filtrage : les utilisateurs peuvent filtrer leurs données en temps réel.
• Tri.

Similaire à Google Document, cet outil a été développé sur la plateforme Flash et va continuer à évoluer. La démo se passe ici, la seule contrainte : avoir un compte Adobe.

La deuxième annonce concerne l'ouverture de la spécification de Real-Time Messaging Protocol (RTMP). Comme nous en avions parlé ici, la spécification a été publiée lundi dernier.

Enfin, Michael Chaize parle de la sortie de LiveCycle Data Services 3 en bêta. Disponible sur le labs d'Abobe, cette nouvelle version propose une meilleure qualité de service pour des applications dont la fiabilité est primordiale telles que les applications bancaires par exemple. Venant compléter la plateforme Flash (avec Flex 4 et Flash Builder 4), Adobe incite la communauté à faire ses retours sur le forum.

Le coin de la technique

Scalabilité avec Hibernate et Shards

Une session de QCon 2008, traitant de la scalabilité d'Hibernate, vient d'être mise en ligne. Présentée par Emmanuel Bernard, project lead d'Hibernate Search, et Max Ross, project lead d'Hibernate Shards, cette présentation offre une approche peu courante sur un problème pourtant récurrent.

Outre les classiques solutions permettant d'éviter certaines pertes de performance avec l'augmentation du volume traité, telles que la bonne gestion du cache, et les optimisations SQL, il a été question d'utiliser Hibernate Search et Hibernate Shards.

Hibernate Search est connu pour sa capacité à simplifier les recherches dans un ensemble d'entités grâce à l'utilisation de Lucene conjointement à la base de données. Emmanuel Bernard proposait ici de déléguer à Search certaines recherches qui s'avèrent très coûteuses à effectuer en base. Lucene étant placé sur une machine séparée, et pouvant même fonctionner en maître / esclave, il est ainsi possible d'obtenir une intéressante répartition de la charge.

Hibernate Shards, bien que plus ancien, est moins répandu du fait qu'aucune version finale n'a encore été produite. Il s'agit d'un module additionnel pour Hibernate permettant à une application de manipuler des données partitionnées sur plusieurs BDD. Le but étant d'encapsuler la conscience du partitionnement des données au sein de la couche Hibernate afin que l'application n'ait pas à gérer cette problématique. Les possibilités du framework sont intéressantes :

• La gestion correcte des Criterias sur des données partitionnées grâce à ShardedCriteria.
• Virtual Shards permettant de faire la distinction entre shard logique et shard physique et ainsi d'augmenter le nombre d'instances de base de données au fur et à mesure de l'augmentation des besoins.
• Generation d'IDs compatibles avec l'utilisation sous-jacente de plusieurs BDDs grâce à l'utilisation d'UUIDs.
• Gestion correcte de BDDs hétérogènes.

Ce sont finalement les fonctionnalités manquantes qui permettent de comprendre pourquoi Shards est toujours en version bêta. Max Ross s'est expliqué il y a plusieurs mois sur les problématiques rencontrées, de manière succincte sur un forum et plus longuement dans une interview. De nombreux défis restent ainsi à relever concernant la gestion correcte des agrégations dans les ShardedQuery et la fourniture d'outils d'aide au partitionnement et repartitionnement des données.
Max Ross est employé par Google et non par JBoss, tout comme les deux autres committers du projet (le code ayant été donné à JBoss par Google), et affirme ne disposer que de 20 % de son temps pour Shards. Ceci n'explique que partiellement le peu de commits sur le projet et ne nous rassure guère quant à sa finalisation prochaine.

Jigsaw vs OSGi

Sept mois après le démarrage du projet Jigsaw, sa légitimité n'est toujours pas reconnue face à OSGi qu'il est venu défier sur son propre terrain.

La semaine dernière JavaPosse diffusait une interview de Mark Reinhold et Alex Buckley, où ils ont pu présenter plus en détail leur vision de Jigsaw :

• Il a été conçu pour modulariser le JDK et est intégré au langage.
• Il ne repose pas sur une spécification car cela n'était pas possible compte tenu du calendrier de JDK 7. Il est donc à considérer comme un "détail d'implémentation" tout comme la gestion du classpath l'était dans les JVMs précédentes.
• Il n'est pas supposé entrer en concurrence avec OSGi, des outils permettant l'intégration entre modules Jigsaw et bundles OSGi étant prévus, mais non prioritaires.

Dans le même temps, Eric Newcomer (Co-Chair, Enterprise Expert Group de l'OSGi Alliance), postait une série de billets très virulents à l'égard du projet Jigsaw, reprochant principalement que Sun n'ait pas voulu se tourner vers OSGi, ne cherchant pas à combler les manques qu'il y trouvait, se tournant immédiatement vers une nouvelle technologie et ignorant donc les 10 années d'expérience acquises par OSGi.

En fait, il semble n'y avoir aucune justification technique permettant d'expliquer l'orientation de Sun vers Jigsaw plutôt que vers OSGi ou vers une évolution d'OSGi intégrée au langage. La véritable raison serait alors à chercher sur le plan politique : la modularisation est un concept important qui manque à Java actuellement et Sun ne pouvait probablement pas se permettre, pour l'ajout d'un tel concept, de s'appuyer sur une spécification émise en dehors du JCP sur lequel il a la gouvernance.

Pourquoi utiliser un portail ?

Le dernier podcast des Cast Codeurs était l'occasion d'une interview de Thomas Heute et Julien Viet sur les portails d'entreprise et sur le partenariat entre eXo et JBoss dont nous vous parlions la semaine dernière.

Les détails liés au partenariat ont déjà été largement couverts par la blogosphère, et c'est surtout le tour d'horizon du concept même de portail que l'on retiendra. Celui-ci reste en effet souvent un élément ambigu au sein de l'écosystème JEE.

Le rôle du portail est d'agréger plusieurs applications au sein d'une unique application Web. Ce besoin technique peut être atteint à plusieurs niveaux de l'architecture de l'application :

• Au niveau back-end, par agrégation de Web Service, se conformant ainsi à l'un des préceptes des SOAs.
• Au niveau applicatif, par l'utilisation d'un portail, ou d'une solution spécifique.
• Au niveau du navigateur Web, par l'utilisation de gadgets, en suivant le principe des Mashups.

En outre, il a également été question des problématiques d'intégration des frameworks Web aux portlets, de complexité éventuelle, et d'adaptation des technologies Web aux portlets. Déterminer si un portail doit être utilisé dans une architecture dépend alors du niveau de tolérance à ces problématiques.

Embarquer le Web dans Java avec JWebPane

Depuis plusieurs années, lorsque l'on veut afficher une page Web au sein d'une application Swing, il faut se tourner vers le composant Browser de la librairie Jdic. Ce composant utilise Embeddable Mozilla, et se présente sous la forme de code natif décliné pour chaque OS et d'un wrapper Java. Outre la nécessité de fournir une version spécifique à chaque OS, ce composant présente également l'inconvénient de mal s'intégrer aux applications Swing du fait de sa nature heavyweight. Pour rappel, un composant est dit heavyweight lorsqu'il est dessiné par l'environnement graphique du système d'exploitation ; à l'opposé il devient lightweight s'il est dessiné par l'application, ce qui est le cas de l'ensemble des composants Swing. Or, faire cohabiter les deux types de composants est délicat car n'étant pas dessinés au même moment, leur superposition est confuse et des chevauchements non contrôlables apparaissent.

Lors de JavaOne, Alexey Ushakov a fait la démonstration du composant JWebPane sur lequel il travaille actuellement et vient de poster des captures d'écrans. Contrairement à Jdic Browser, JWebPane se base sur le moteur WebKit pour effectuer le rendu HTML. Or celui-ci se caractérise par sa nature lightweight s'intégrant agréablement à Swing. La présentation d'Alex Ushakov permet également de constater que son composant est particulièrement riche en possibilité d'interactions et apporte un support pour d'éventuels plugins tels que Flash.

On ne peut qu'apprécier le choix de Sun de créer un composant pour Swing, réutilisable dans JavaFX, plutôt que de privilégier uniquement JavaFX comme cela est souvent le cas depuis son arrivée. L'intégration de JWebPane au JDK 7 est maintenant indispensable pour rendre ce composant réellement exploitable : se basant sur WebKit, il repose donc sur des librairies natives qu'il sera nécessaire de livrer avec les applications Java et seul l'intégration au JDK permettrait de l'éviter. Or, malgré les appels de la communauté, JWebPane reste pour le moment absent de la liste des features du JDK 7 et il est uniquement question d'une mise à disposition sur Java.net.

Actualité éditeurs / SSII

• Google App Engine pour Java et Groovy

SOA

• Le statut de JBI 2 en question

Mobilité

• Preview d'Android 1.5

Le coin de la technique

• Lucene continue d'innover
• ServiceMix 4 et son kernel OSGi

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

• Les Cast Codeurs, le podcast Java en Français

Actualité éditeurs / SSII

Google App Engine pour Java et Groovy

Google App Engine, solution de Cloud Computing proposée par Google supporte depuis la semaine dernière (en plus du langage Python disponible depuis un an) le langage Java. Cette solution permet dorénavant de déployer son application web à base de servlets (sous forme de war) sur un serveur virtuel hébergé sur l'infrastucture de production de Google (Google a donné la semaine dernière un compte Google App Engine Java aux 10 000 premiers inscrits).

Google met en avant les avantages suivants :

• La facilité d'utilisation via un SDK très documenté et des plugins Eclipse.
• La scalabilité gérée de manière transparente et automatique
• La fiabilité et la performance fournies par les infrastructures de Google
• Enfin, App Engine est gratuit si votre serveur n'excède les 500 Mo de stockage et 5 millions de page visualisées par mois

Google fait une entrée de manière fracassante dans le marché du cloud computing "Java" (Amazon EC2, etc.. ) et propose une offre séduisante où chacun peut créer, tester et déployer son application facilement. La création d'un projet App Engine sous Eclipse via le plugin est simple et le déploiement sur App Engine s'effectue en un seul clic.

Quelques liens utiles :

• vous pouvez trouver une description très complète de la solution (en Français) sur le blog de Frank Arnulfo
• David Gageot a mis en ligne une feuille Google Spreadsheet qui liste les librairies et frameworks Java supportés par Google App Engine
• Groovy est également supporté, retrouvez l'annonce sur le blog de Guillaume Laforge

SOA

Le statut de JBI 2 en question

La JSR-312 : Java Business Integration 2.0 (JBI) a été initiée début 2007 pour pallier les défauts de la première version de ce standard (JSR-208 : JBI). Cette dernière souffrait en effet de nombreuses critiques, portant principalement sur sa lourdeur excessive et son indépendance vis-à-vis des autres standards existants (SCA, EJB3, JAX-WS, ...).

Le projet était alors ambitieux mais la perspective d'un tel standard ne manquait pas d'intérêt. Toutefois, deux ans après sa création, le statut de cette JSR, tel qu'affiché sur sa page du JCP, reste toujours inchangé et la JSR est maintenant classée "inactive".
Ron Ten-Hove (co-spec lead de la JSR), vient toutefois d'apporter une information discrète quant à l'activité de l'Expert Group associé sur la mailing list du projet OpenESB. Il indique que le développement de la JSR n'est pas interrompu et que la classification d'inactivité est uniquement due à une nouvelle règle du JCP qui étiquette ainsi les JSRs dont le statut n'a pas évolué depuis 18 mois. Ceci ne refléterait donc pas le niveau d'activité au sein de l'Expert Group. Aucune date ni évolution de planning ne sont par contre indiquées.

Le standard JBI 1.0 est boudé par un grand nombre de produits commerciaux et Open Source qui préfèrent épouser la vague des "lightweight ESB" dont nous vous parlions déjà il y a un an. Toutefois l'arrivée tardive d'un standard faisant consensus n'est pas forcément un frein à son adoption comme l'a montré EJB 3 remplaçant avec succès ses très lourds prédécesseurs ; la voie reste donc ouverte pour JBI 2.0 et l'avenir nous dira si la tâche n'était pas trop lourde.

Mobilité

Preview d'Android 1.5

En attendant la sortie finale d'Android 1.5 (Cupcake) à la fin du mois, Android Developers Blog annonce la sortie d'une pré-version du SDK 1.5 pour les développeurs d'applications Android.
Parmi la liste complète des nouveautés d'Android 1.5, cette pré-version du SDK propose notamment:

• le clavier virtuel
• le développement de widgets pour l'écran d'accueil (à l'image de l'horloge ou du widget de recherche qui existent déjà dans Android)
• la fonctionnalité live folders
• la reconnaissance vocale

Ce nouveau SDK propose également une avancée intéressante : la possibilité de gérer plusieurs versions du SDK en parallèle, par exemple ici les versions 1.1 et 1.5. Les développeurs pourront donc tester leur application sur plusieurs environnements sans manipulations fastidieuses.
Afin de commencer à tester vos applications sur cette nouvelle version d'Android, vous pouvez télécharger ce SDK 1.5 en cliquant ici.

Le coin de la technique

Lucene continue d'innover

Le projet Apache Lucene reste une source d'innovation importante au fil des années. Il compte en effet huit sous-projets, chacun apportant son lot d'outils et d'APIs additionnelles permettant de mettre en œuvre un moteur de recherche toujours plus élaboré.Ces sous-projets vont parfois au-delà du simple environnement de Lucene, comme cela a été le cas avec Hadoop, qui gagne actuellement en popularité et dont le moteur MapReduce est réutilisé par de nombreux autres projets.

Dernière preuve en date de cette activité, le sous-projet Mahout, créé en Janvier 2009 et qui vient d'être annoncé en version 0.1, a pour but de fournir des implémentations d'algorithmes de machine learning, la plupart pouvant être distribués grâce à Hadoop. Ces algorithmes couvrent principalement :

• La classification et le clustering : permettent de catégoriser, tagger et séparer des données en groupes. Ainsi enrichies, ces données pourraient par exemple être plus facilement exploitables et accessibles par un moteur de recherche qui saurait exploiter ces informations lors de son processus d'indexation.
• Le collaborative filtering : permet de créer des systèmes d'associations d'objets par apprentissage, du type "les utilisateurs ayant acheté cet article ont également acheté ...". Cette fonctionnalité est offerte par le moteur Taste de Mahout.

Ces technologies sont actuellement plus proches du monde de la recherche que de celui de l'informatique de gestion en entreprise. Et c'est bien là que va résider tout le défit pour Mahout : parvenir à proposer une API simple et robuste pour offrir ces fonctionnalités à moindre coût aux applications d'entreprise. Actuellement peu courants, les cas d'utilisation pourraient se multiplier avec la mouvance globale vers les technologies Web 2.0 et autre concepts liés à l'intelligence collective.

ServiceMix 4 et son kernel OSGi

L'équipe de ServiceMix a profité de la conférence ApacheCon Europe 2009 pour annoncer la sortie de la version 4.0 finale de leur ESB.
Rod Biresch présentait en septembre dernier les principaux apports de cette nouvelle version, ce qui permettait alors de constater qu'il s'agissait avant tout d'une refonte de l'architecture du projet. Ainsi, alors que ServiceMix 3 gravitait principalement autour de son conteneur JBI, son successeur utilise désormais un kernel basé sur OSGi et secondé par un module Normalized Message Router (NMR). Il donne naissance à deux sous-projets distincts : ServiceMix Kernel et ServiceMix NMR.

Cette nouvelle architecture permet à ServiceMix de gagner en évolutivité et n'a qu'un impact limité pour les développeurs utilisant cet ESB. Ainsi, les composants développés pour ServiceMix 3.x restent compatibles avec cette nouvelle version, tel que l'on pouvait s'y attendre du fait de la conservation du standard JBI.

En outre, Guillaume Nodet (project lead de ServiceMix) nous apprend que le kernel de ServiceMix 4 attire d'autres projets de la fondation Apache (ActiveMQ, Directory et James) ce qui devrait conduire ServiceMix Kernel à devenir un sous-projet d'Apache Felix et à être, à priori, renommé pour l'occasion en Apache Karaf. OSGi continue ainsi de s'imposer massivement pour apporter la modularité dans les implémentations de conteneurs et middlewares Java, après avoir conquit le cœur de nombreux serveurs d'applications.

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

Les Cast Codeurs, le podcast Java en Français

A l'image du Java Posse anglo-saxon, Emmanuel Bernard (JBoss, Hibernate), Guillaume Laforge (SpringSource, Groovy), Antonio Goncalves (freelance, auteur, Paris JUG) et Vincent Massol (XWiki, Maven) lancent Les Cast Codeurs, podcast dédié aux nouvelles fraîches du monde Java, en Français !
Parmi les sujets discutés pendant cette première édition : Google App Engine, le rachat hypothétique de Sun par IBM ou Java EE 6 proposé en final draft.
On y entend beaucoup Emmanuel Bernard, beaucoup moins Vincent Massol, mais les propos et le format sont intéressants, longue vie aux Cast Codeurs !