Publié par
Il y a 8 années · 7 minutes · Java / JEE

Revue de Presse Xebia

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

SOA

Le coin de la technique

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:

Xebia France
Xebia est un cabinet de conseil international spécialisé dans les technologies Big Data, Web, les architectures Java et la mobilité dans des environnements agiles. Depuis plus de 11 ans nous avons la volonté de partager notre expertise et nos actualités à travers notre blog technique.

8 réflexions au sujet de « Revue de Presse Xebia »

  1. Publié par Sebastien, Il y a 8 années

    En ce qui concerne l’annotation @DataSourceDefinition, cette approche signifie-t-elle qu’il faille recompiler le code java afin de changer le mot de passe ?
    N’est ce alors pas une régression par rapport aux bons vieux fichiers properties, et d’une manière générale, à l’externalisation (hors du code java) des configurations ?

  2. Publié par Michael Figuiere, Il y a 8 années

    @Sebastien

    En effet cela nécessite une recompilation du code lors du changement des paramètres.

    Comme nous le mentionnions, cette annotation (qui n’est qu’une option de configuration parmi d’autres) ne trouvera pas sa place dans la plus grande majorité des applications d’entreprise qui nécessitent une configuration facilement accessible. En revanche, utilisée conjointement à une base de données embarquée (tests, applications standalone, …), cette annotation permettra une simplification du déploiement.

    Cordialement,
    Michael Figuière (Xebia)

  3. Publié par Michael, Il y a 8 années

    hello,
    quelle limitation avez-vous rencontré avec Spring Roo et AspectJ ? Je l’utilise pas mal et je trouve ça assez transparent. Mais bon, s’il y a des bugs on peut les corriger, il faut juste nous dire exactement ce qui ne va pas :).

  4. Publié par Tahiti, Il y a 8 années

    Je trouve dommage que Spring réinvente la roo.

  5. Publié par Dominique De Vito, Il y a 8 années

    Quand Spring Roo a été annoncé, je me suis amusé à imaginer que Roo soit couplé à Twitter; de sorte qu’il soit possible de twitter et que les tweets servent de lignes de commande pour Roo.

    Cela mènerait à un dev collaboratif amusant, mais sans plus (quoique peut être pour le e-learning), outre le fait, peut être de donner des idées à d’autres personnes…

  6. Publié par Jackie Brown, Il y a 8 années

    Concernant la configuration des sources de données via une annotation dans le code, il faut rappeler que définir l’environnement d’exécution est une prérogative du serveur d’application, pas de l’application elle-même.

  7. Publié par Stéphane, Il y a 8 années

    Ils devraient plutôt intensifier les efforts sur leur autre acquisition Groovy/Grails. Par exemple améliorer les performances de Groovy, enrichir le catalogue de plugins « officiels » Grails, pousser son passage à OSGI. En discutant un jour autour d’une bière avec Graeme et Guillaume il m’était apparu que ce projet Roo étant dans les cartons de Spring depuis bien longtemps et que le but avoué était la concurrence de Rails, Grails (0.x)…

    Enfin, la diversité a du bon :), j’espère voir d’étroites relations entre les 2 projets !

  8. Publié par Tahiti, Il y a 8 années

    Tout a fait d’accord avec Stéphane.

    J’ai plutôt l’impression qu’avec leur système de génération de code et leurs annotations ROO, cela ressemble a du seam/grails déguisé.
    Et effectivement, les raisons de basculer sur du grails quand on a presque du rails avec ROO deviennent plus limitées.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *