Revue de Presse Xebia

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

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 :

@DataSourceDefinition (
className="org.apache.derby.jdbc.ClientDataSource",
name="java:global/jdbc/AppDB",
serverName="localhost",
portNumber=1527,
user="user",
password="password",
databaseName="dev-db"
)
public class Config {
...
}

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