Lors d’un post précédent, j’avais parlé des EIPs (Enterprise Integration Patterns) en expliquant qu’il s’agissait de Patterns permettant de normaliser les échanges de messages dans un système asynchrone.
Dans cet article, je vais tenter de présenter succinctement deux de ses implémentations : Spring Integration et [Apache Camel](https://camel.apache.org/.
En fait, pour être plus précis, je vais plutôt tenter de présenter la vision que j’en ai ainsi que la façon dont je les ai compris.
Dans des posts précédents (ici et là), j’avais parlé d’une façon d’utiliser maven 2 pour fournir, entre autre, une solution pour accélérer le déploiement d’applications web avec Cargo. Cependant, afin d’optimiser le temps de développement, il est préférable, plutôt que d’avoir à redéployer l’application web à chaque modification de son contenu (que ce soit sa vue, son contrôleur ou son modèle) ou de ses librairies tierces (ce qui est connu pour être un anti-pattern), de n’avoir pas à le faire mais d’avoir plutôt un mécanisme permettant de prendre les modifications à chaud afin de pouvoir tester le plus rapidement possible.
Au cours de certaines missions, je suis arrivé à un constat qui était que le processus de génération d’un livrable était souvent délaissé au profit de l’effort de développement de l’application.
C’est vrai qu’il peut être concevable qu’il ne s’agit que de la dernière étape d’un processus de développement, cependant, avec l’introduction de cycles courts (agilité, …), pouvoir fournir rapidement un livrable de qualité au client est primordial.
Dans un post précédent, j’avais parler de la façon dont j’avais en place maven dans un processus d’usine logicielle.
Juste une petite réflexion que je trouve pas mal et que je ne fais que retranscrire puisque c'est [Yukihiro Matsumoto](http://en.wikipedia.org/wiki/Yukihiro_Matsumoto) (M. Ruby) lors de sa présentation au salon Linux Open Source de mars 2009 (oui, oui, je sais, ça date un peu...) qui l'a tenue. Il nous a expliqué ce qui l’avait amené à créer le langage Ruby : écrire du code dans un langage qui correspond à notre façon de penser; mais il a aussi tenté de nous démontrer pourquoi on devrait utiliser Ruby (chose difficile devant un public de Javaistes…) : utiliser Ruby fluidifierait notre façon de penser.
Ce post présente les ouvrages (techniques) que je recommande vivement... cependant, certaines références ne sont plus disponibles puisque l'éditeur O'Reilly a décidé de fermer sa branche française... dommage... mais les éditions anglaises sont toujours là! # A lire absoluement ## Apache Maven de N. De Loof et A. Héritier chez Pearson Ce livre, qui ne se veut pas une bible maven, raconte la mise en place de maven avec un modèle "
Cet article présente la mise en œuvre que j’ai appliquée lors de la mise en place d’un environnement de développement devant s’interfacer, dans une démarche pseudo-agile, avec des outils d’intégration continue.
Il présentera, dans un premier temps, le contexte et les problématiques puis, dans un second temps, comment j’ai tenté de répondre à ces problématiques que ce soit d’un point de vue méthodologique que d’un point de vue technique. Bien sûr, les choix et les implémentations utilisés sont discutables, mais c’est aussi pour cela que j’ai créé ce blog (afin de faire partager mon expérience et d’avoir un retour) ;-)
Dans l’article sur JBI, j’ai mentionné à de nombreuses reprises le terme EIP. Cet article revient sur cette notion que je considère comme étant très importante surtout lorsque l’on doit jongler avec des messages asynchrones.
En fait, les EIP (Enterprise Integration Patterns) sont issus de l’excellent livre éponyme de G. Hohpe et B. Woolf chez Addisson Wesley. Ne pouvant que vous recommandez sa lecture si vous trempez dans cette problématique, cet article ne sera qu’une brève introduction à son contenu (il fait quand même plus de 600 pages, donc je ne vais pas prétendre le résumer… ;-)).
Voilà mon premier article. Il a pour objectif de présenter JBI (Java Business Service) aussi connue sous le doux nom de JSR 208 (Java Specification Release).
Pourquoi un article sur JBI? Vous pouvez vous demander pourquoi un article sur JBI? Les réponses sont simples : j’aime bien cette spécification et je trouve qu’elle a du potentiel et qu’elle est sous exploitée.
Bien sûr, me direz-vous, en tant qu’utilisateur d’un PEtALS ou ServiceMix, pourquoi devrais-je comprendre la technologie sous-jacente?
