Publié par

Il y a 12 ans -

Temps de lecture 4 minutes

Spring Integration – L’avènement des ‘lightweight ESB’ ?

Une nouvelle approche des ESB

SpringSource vient d’annoncer le lancement de Spring Integration, une implémentation légère des Enterprise Integration Patterns. Le lendemain, le projet Apache ActiveMQ annonçait la sortie de sa version 5 qui ajoute le support de ces mêmes Enterprise Integration Patterns grâce à l’intégration d’Apache Camel, un framework léger de routage et de médiations utilisable soit par configuration XML Spring, soit par un Domain Specific Language (DSL) Java. Ces deux approches open source se caractérisent dans le monde des ESB par :

  • Une grande légèreté : on ne parle plus de conteneur, d’APIs sophistiquées de connecteurs, de registre de services, de structures de données complexes mais de simples messages composés d’un body souvent sous forme de Plain Old XML (POX) et de headers en mode clef/valeur.
  • L’éloignement des standards chers aux grand éditeurs (Java Business Integration – JBI et Service Component Architecture – SCA) pour se cantonner à des Plain Old Java Objects (POJO). On notera tout de même que ces nouveaux frameworks de routage utilisent massivement les API Java EE pour les connecteurs et les transactions (JDBC, JMS, JCA, JTA, etc).

Exemples de configuration de routes avec Apache Camel

Camel Route Configuration With Java DSL

from("file:src/data")
   .choice()
      .when(xpath("/person/city = 'London'"))
         .to("file:target/messages/uk")
      .otherwise()
         .to("file:target/messages/others");

Camel Route Configuration With Spring 2.0 XML Conf


   
      
         
         
            
               /person/city = 'London'
               
            
            
               
            
         
      
   

Une rupture radicale avec les précédents ESB ?

Plus qu’une rupture, cet allègement s’inscrit dans une tendance :

  • La vague POJO/POX a déjà déferlé sur l’informatique de gestion en Java (SpringFramework, etc) et on pouvait l’attendre sur les technologies d’intégration d’applications.
  • JBI 1.0 a rencontré un succès très limité et les travaux actuels sur la version 2.0 suscitent des doutes (cf InfoQ : JBI 2.0 at JavaOne) :
         – Apache ServiceMix se détache progressivement de son objectif initial de conteneur JBI pour devenir en version 4 un « lightweight SOA/ESB container based on OSGI ».
         – Mule ESB ne s’intéresse toujours pas à JBI (cf Mule and JBI).
  • La banalisation des connecteurs (JCA, JMS, SOAP, etc) et des conteneurs OSGI [1] (conteneur d’assemblage et d’exécution de composants) a permis de démocratiser le développement des ESB en laissant ces projets se concentrer sur les fonctionnalités de bus.
  • L’essor des Domain Specific Languages et la simplicité d’utilisation des configurations XML Spring 2 offrent des alternatives et un retour de balancier face à l’approche du « tout graphique » incarnée par BPEL.

Perspectives pour 2008

On peut attendre en 2008 des mouvements autour des lightweight integration frameworks et des standards :

  • Les Lightweight Enterprise Integration Patterns Frameworks vont progresser rapidement et garder leurs distances avec les standards JBI et SCA. Le premier enjeu sera de proposer un middleware d’exécution pour ces frameworks (middleware de message, application server, etc).
  • Mule ESB, l’ESB Open Source ‘historique’ devra rattraper son retard en offrant des fonctionnalités spécifiques aux Enterprise Integration Patterns.
  • Les grands éditeurs vont continuer leurs investissements sur leurs standards : IBM et BEA sur SCA, Sun sur JBI.
  • JBI 2.0 devra trancher deux questions très délicates :
         – Java Module System & Superpackage versus OSGI : Si les premiers sont le standard choisi par Sun, le deuxième, OSGI, fait l’unanimité dans la communauté des middlewares (commerciaux et open source) qui a déjà décidé de l’utiliser.
         – SCA : risquer la marginalisation en ignorant ce standard qui rassemble tous les grands de l’Enterprise Java [2] ou le rejoindre quitte à se faire absorber.

Ressources

[1] OSGI est déjà utilisé par Websphere ESB, intégrable dans Spring avec Spring Dynamic Modules for OSGi(tm) Service Platforms, prévu dans ServiceMix 4, planifié pour Mule ESB après la v2.
[2] IBM, BEA, Oracle, SAP, etc

Publié par

Publié par Cyrille Le Clerc

CTO de Xebia, Cyrille est aussi committer sur le projet Apache CXF. Après être récemment intervenu sur les sites web et les plateformes de web service à fort traffic d'opérateurs de télécommunication, Cyrille est actuellement responsable de la mise en place d'une grille de données inter-continentale pour une grande institution financière française. Après 7 ans chez IBM Global Services et 5 ans chez Xebia, Cyrille a une expérience variée allant du monde commercial aux écosystèmes Open Source dans des approches aussi bien très cadrées et contractuelles que légères et agiles. Cyrille est aussi blogger sur blog.xebia.fr et speaker dans des conférences (In Memory Data Grids & NoSQL, applications prêtes pour la production, etc).

Commentaire

Laisser un commentaire

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

Nous recrutons

Être un Xebian, c'est faire partie d'un groupe de passionnés ; C'est l'opportunité de travailler et de partager avec des pairs parmi les plus talentueux.