Revue de Presse Xebia

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

Actualité éditeurs / SSII

SpringSource lance CloudFoundry

SOA

David Chappell et Ted Neward : SOA est un échec … mais aussi un progrès

Le coin de la technique

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

Actualité éditeurs / SSII

SpringSource lance CloudFoundry

Rod Johnson l’annonçait jeudi dernier sur son blog, l’éditeur fait ses premiers pas dans le monde du cloud computing. Il s’agit en effet d’une interface web qui ne manque pas de rappeller Google App Engine permettant d’installer des applications Java sur le nuage. Dans cette première version, on nous propose de déployer des applications hébergées sur le fameux Spring Tc Server, avec out of the box, la supervision Hyperic, la possibilité d’utiliser une base de données MySQL, et évidemment le support de Grail, si cher à Rod.

Au menu, bien évidemment le support et la répartition automatique de la montée en charge. Pour le moment, le tout est déployé sur Amazon EC2, mais Rod espère bien le voir déployé prochainement sur vSphere (la solution de cloud computing de VMWare). Nous souhaitons longue vie à ce nouveau produit de SpringSource qui confirme une fois encore sa montée en puissance. Notez, tout de même pour information que c’est Chris Richardson et son équipe qui s’est chargé de la réalisation de CloudFoundry.

L’article de Cyrille Le Clerc sur SpringSource et Java Platform As A Service vous permettra d’y voir un peu plus clair sur la stratégie poursuivie par SpringSource.

SOA

David Chappell et Ted Neward : SOA est un échec … mais aussi un progrès

David Chappell a retrouvé une discussion qu’il a eu avec Ted Neward en 2008 sur SOA.

Au-delà de l’évocation des liens entre Service Oriented Architecture (SOA), Software as a Service (SaaS) et Cloud computing, nous retiendrons de cet échange : SOA a échoué à tenir sa double promesse « Réutilisation et agilité ».
L’agilité est une forme de réutilisation puisqu’elle permet de créer de nouveaux services en assemblant facilement des services existant. La réutilisation des services métiers a échoué, et par effet de bord, l’agilité n’a pas été obtenue. La réutilisation des services métiers est analogue à la réutilisation des objets métiers à la fin des années 90.
La cause de cet échec, pour SOA comme pour les objets métier, n’est pas technique mais principalement humaine. Les organisations n’ont pas créé les conditions pour inciter les équipes à partager leur travail ni à réutiliser le travail des autres (Cf. « Le syndrome Not Invented Here » et « Propriété des composants et Financement au projet« ).

En revanche, la réutilisation des objets techniques a réussi, les frameworks .Net et Java EE en sont des exemples. De plus, l’orienté objet a convaincu comme paradigme de programmation. Pour SOA, la réutilisation de services techniques comme la gestion de l’identité ou la couche d’accès aux données basiques fonctionne.

Il s’agit donc d’un échec du SOA tel qu’on nous l’a promis mais en revanche d’un succès de l’approche par service.

Pour ce qui est des ESB, il s’agit principalement d’un coup marketing des éditeurs de solutions d’intégrations mais aussi d’une évolution des paradigmes d’intégration : l’intégration par services à succédé à l’intégration par base de données.

Alors SOA est un échec ? Oui si l’on regarde les promesses initiales qui n’ont pas été tenues ; non si l’on voit les transformations orientées service qu’elle apporte.

Le coin de la technique

Acquisition d’Ehcache par Terracotta, nécessaire et suffisant ?

Le teaser largement propagé via Twitter et les différents blogs des acteurs de Terracotta est tombé. Terracotta a fait l’acquisition d’un des frameworks open-source les plus populaires du marché : Ehcache. Drôle de teasing, sous la forme d’un hash md5, pour une drôle d’annonce. Ce mariage ressemble plus à un arrangement entre amis qu’a un véritable rachat :

Ehcache et Terracotta fonctionnent conjointement depuis bien longtemps.
Ehcache est porté par une seule personne : Greg Luck.
La vente de support Ehcache ne fonctionne pas vraiment, dixit Greg Luck.
Le code source de Ehcache est très léger, et sa partie la plus complexe, le cache distribué, concurrence avec une grande simplicité Terracotta.

Alors, pourquoi avoir racheté Ehcache ?

Selon certains analystes, après le rachat de SpringSource, VMWare a la volonté d’élargir son portefeuille d’outils et de middleware Java, et Terracotta serait pressenti. C’est en tout cas l’hypothèse mise en avant par quelques gaillards de Terracotta (encore une fois, merci Twitter). Notre sentiment, trop de bruit pour que cela soit d’actualité. Par contre, il nous semble clair que Terracotta désire se faire racheter. Et pour cela, plusieurs problèmes doivent être réglés :

Malgré les différentes versions, Terracotta suscite des résistances, en cause son approche bas niveau (JVM / Bytecode) qui freine bon nombre d’utilisateurs. D’ailleurs, Terracotta ne fonctionne pas avec toutes les JVM.
L’utilisation de ce framework n’est pas transparente, quoi qu’en disent les documentations. Il est facile de se tromper sur le choix des objets à partager et les poses de lock. Tout cela fait qu’à l’utilisation, la mise en place de celui-ci est tout sauf triviale.

Et c’est là qu’Ehcache intervient !

Mis en lumière par le cache L2 d’hibernate, Ehcache fonctionne également avec d’autres produits star comme Spring, Alfresco et Liferay. Il est devenu l’une des apis de cache les plus utilisées par les développeurs. On parle de plusieurs centaines de milliers de projets utilisant celui-ci. Avec ce rachat, Terracotta espère se rapprocher davantage de cette communauté en s’appuyant sur la bonne image d’Ehcache pour rassurer les développeurs.
D’autre part, Terracotta gonfle sa stack logiciel et propose dans son portefeuille un mécanisme de cache distribué alternatif plus haut niveau.

Au final, petite annonce ? Pas si sûr ! Terracotta signe ici un joli coup de communication et se met dans les meilleures conditions en vue d’un éventuel prochain rachat.

ChromeDevTools

Pour ceux qui ne sont pas à l’aise avec le débogage Javascript par l’interface de Firebug ou tout simplement ceux qui souhaitent débugger intégralement leur application dans Eclipse, y compris le Javascript client, voici un petit outil (développé par Google) qui vous le permettra : le Google Chrome Dev Tools (par l’Eclipse Zone).

Le projet se compose du Chrome Dev Tools SDK, API Java permettant à une application en mode debug de communiquer avec le navigateur Google Chrome (localhost en TCP/IP) , et de l’Eclipse Debugger, le plugin Eclipse qui vous permettra de débugger votre application.

Ce dernier propose entre autres :

Breackpoints
Watches
Step in / over / into
Évaluation d’une sélection de texte
Évaluation sur mouse hover
Exceptions reportées dans la vue Error Log

Côté mise en place, il vous faudra au minimum, comme vous pouvez vous en doutez, un navigateur Google Chrome en version 3.0.189.0 (actuellement en beta) et un Eclipse 3.4.2. L’installation du plugin se fera par l’Update Site avec cette URL.
Il vous faudra ensuite lancer votre Chrome avec le paramètre --remote-shell-port=9222 (ou le port de votre choix) et définir, dans le menu Debug Configurations d’Eclipse, une nouvelle Chromium Javascript configuration avec le port spécifié pour Chrome. Et à partir de là, à vous les breakpoints et le debug de votre application dans Eclipse !

Pas de Swing Application Framework dans le JDK 7

Il y a quelques mois nous vous parlions de la disponibilité d’une roadmap détaillée pour le JDK 7. Elle incluait entre autre la JSR-296 (Swing Application Framework), une spécification destinée à simplifier le développement d’applications Swing grâce à :

Des annotations @Action pour déclarer les actions Swing plus facilement qu’en sous-classant AbstractAction puis en redéfinissant la méthode actionPerformed()
Gestion de l’enregistrement de l’état des fenêtres à la fermeture de l’application
Simplification de la gestion des ressources
Gestion du cycle de vie de l’application

Les apports sont intéressants car répondent bien aux réalités des projets Swing courants, mais n’y répondent que partiellement. En effet il aurait été interessant de voir se créer une synergie avec la JSR-330 (Dependency Injection for Java) afin d’apporter l’injection de dépendance aux applications client lourds. De plus, ce framework ne simplifie pas la définition des interfaces en Swing, opération se révélant souvent assez laborieuse en raison d’APIs vieillissantes et probablement trop bas niveau.

Alexander Potochkin nous apprend maintenant que cette JSR ne sera pas prête dans les temps pour la roadmap prévue et qu’en conséquence son intégration au JDK 7 est annulée. Dans ces conditions, les apports du JDK 7 à Swing seront quasi nuls, ce qui constituera une réponse bien peu satisfaisante aux débats ayant animé cette communauté il y a quelques mois.

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

Hadoop World 2009

La société Cloudera, spécialisée dans le support aux utilisateurs de Hadoop, a annoncé la première conférence mondiale consacré à Hadoop : Hadoop World. Cette conférence se tiendra à New-York City en octobre de cette année. Elle est soutenue par des sponsors de taille comme IBM, Intel et Yahoo.

Le nombre de candidat à la prise de parole est tellement important que l’agenda n’est pas encore fixé. Le thème sera « Hadoop is everywhere », on aura donc droit à des sujets aussi bien sur des applications utilisant déjà Hadoop, que sur les implications coté administration de parc.

Les inscriptions sont ouvertes …

Sortie le 30 septembre de Google Wave Preview

Présenté il y a quelques mois comme une évolution majeure de notre façon de communiquer en ligne, Google Wave sera bientôt disponible au public. 100 000 utilisateurs sont attendus une fois le service ouvert.

A l’heure actuelle, les développeurs qui ont pu testés ont eu de gros problèmes de disponibilité de la plateforme. Sur InfoQ, on apprend que pour le 30 septembre, l’objectif du responsable technique de Wave API, Douwe Osinga, est bien sûr d’améliorer la stabilité du système mais aussi d’ajouter des fonctionnalités à l’API. Par conséquent, il ne leur restait que peu de temps pour stabiliser le bac à sable.

Dans les nouvelles fonctionnalités, l’accent a été mis sur l’API liée aux robots qui est à présent ouverte. Grâce aux robots, on peut répondre de manière applicative à des évènement sur la wave, ce qui permet d’interagir avec les autres participants, ou d’échanger des informations avec des systèmes extérieurs.

Si vous souhaitez être averti de l’ouverture du service, inscrivez-vous. Vous pouvez même écrire un message d’encouragement à l’équipe de Google Wave. Ils en auront certainement besoin pendant le moins prochain…