FuseSource Community Day – Intégration Open Source et messagerie avec FuseESB/Apache ServiceMix

Cette session a été présentée par Guillaume Nodet (@gnodet) qui, pour ceux qui l’ignoreraient, est commiteur actif sur les projets ServiceMix, Camel, CXF, Karaf, ActiveMQ et j’en passe…
Pendant cette session, Guillaume nous a conté l’histoire de ServiceMix en expliquant pourquoi entre la version 3 et 4 de ce dernier, il s’était éloigné de la spécification JBI (Java Business IntegrationJSR 208).
Suite à cela, Guillaume nous a expliqué ce qu’était ServiceMix 4, à savoir un conteneur basé sur OSGi (et plus particulièrement Apache Karaf) ayant comme objectif de permettre le déploiement de solutions utilisant Apache Camel ou Apache CXF.

Il a ensuite expliqué le choix d’un conteneur OSGi puisque ce dernier permet de couvrir les points suivants :

  • gestion des dépendances (ie. gestion des versions, du conflit de dépendance et des problématique de classloader),
  • gestion du comportement dynamique (afin de permettre un arrêt/démarrage/chargement/déchargement des composants et services et leur mise à jour et/ou remplacement),
  • gestion de la modularité des composants (pour rappel, la JVM ne permet pas encore la gestion de la modularité entre packages et ne propose pas non plus la notion de version).

Le but de ServiceMix 4 est donc d’offrir un conteneur d’exécution basé sur la JVM pour répondre aux problématiques d’intégration et plus précisément pour les architectures SOA.
Ainsi, ServiceMix, en fournissant une approche uniforme pour la prise en compte des “common cross-functional patterns“, propose le support de :

  • une intégration des flux suivant les principes des EIPs (avec Apache Camel),
  • un support des web services SOAP et REST (avec Apache CXF),
  • un support de l’orchestration des processus métiers (avec Apache ODE qui est un moteur BPEL),
  • un système de messagerie fiable (avec Apache ActiveMQ),
  • et, cerise sur le gâteau, les couches d’administration et de supervision inhérentes à ce type de conteneur (avec le support de JMX, une console web et FuseHQ).

En fait, Guillaume a expliqué qu’il était possible de déployer presque tout dans ServiceMix 4 (à savoir, jar, war, bundle OSGi et configuration Spring) mais qu’il valait mieux s’orienter vers les bundles OSGi pour toutes les problématiques de routage, d’intégration ou logique métier.
Enfin, Guillaume nous a présenté la possibilité d’utiliser un descriptif de provisionnement qui, sous format XML, permettent de décrire un plan de déploiement (ce qui, dans le monde JBI, pourrait être assimilé au service assembly) qui a même la possibilité d’aller chercher ses ressources dans un repository Maven.

Conclusion

Guillaume nous a gratifié d’une présentation très intéressante sur ServiceMix (mais également sur ActiveMQ et CXF (qui ne sont pas retranscrites ici)) qui m’a permis d’avoir une meilleure compréhension de la direction vers laquelle s’orientait ServiceMix ainsi que de voir ses cas d’usage ainsi que ses killer-features. C’est vrai que coté utilisateur, cela ne révolutionnera pas notre vie mais, à mon sens, ServiceMix se présente comme une très bonne alternative aux serveurs d’applications dans un contexte SOA.
Cette présentation m’a aussi permis de mieux appréhender la frontière qu’il existait entre Apache Camel et Apache ServiceMix, à savoir que ServiceMix devrait être vu plus comme un conteneur alors qu’Apache Camel devrait être vu plus comme un framework de médiation.

Nombre de vue : 38

AJOUTER UN COMMENTAIRE