Revue de presse Xebia

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

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.