Le tour des ESB en 10 questions

par Karim BEN OTHMAN et Sylvain FAGNENT:

Sylvain : Karim, bonjour

Karim : Bonjour.

Sylvain : Ton expérience de l’intégration à Octo te place en référant sur le sujet et moi qui le suis d’un peu plus loin désormais, j’ai des questions autour des MOM, de l’open source et plus récemment des ESB. Tu peux m’aider à y voir plus clair?

Karim : Poses tes questions, on va bien voir ce que je peux faire

Sylvain : Alors sans gant, ma première question sera directe « Il y a 4 ou 5 ans on se posait la question de savoir s’il fallait un EAI ou pas. Aujourd’hui la question s’est transformé en : « Faut-il un ESB ? » Ton avis ?

Karim : Je ne pense pas que les besoins métiers d’intégration ont énormément évolué sur les 5 dernières années. Ce qui a évolué depuis, ce sont les concepts architecturaux (ex SOA, EDA, MDM, REST, etc.) et les standards technologiques qui ont vu le jour (SCA, JBI, WSDL et la stack WS-*).

Il est vrai que les EAI ne proposaient pas de réponses « Out of the Box » autour de ces concepts et technologies. Tous les éditeurs ont fait énormément d’effort pour combler ces lacunes, quitte à commercialiser des solutions parfois inachevées. Les solutions, historiquement connues sous le buzzword « EAI » se sont toutes transformées en solution ESB aujourd’hui.

Donc c’est normal que cette question demeure d’actualité.

Alors pour répondre à ta question, ça dépend du nombre d’échanges à implémenter. Pour une dizaine ou une vingtaine d’échanges, ça ne vaut vraiment pas la peine. La mise en place de telles solutions coûte chère. Plus? On se pose des questions, et la mise en œuvre d’un ESB trouve pleinement son sens. J’ai mis en place et je croise chez nos clients des solutions qui font tourner entre 300 et 400 flux en production.

Sylvain : Qu’apporte un ESB/EAI?

Karim C’est une question qui revient souvent. J’ai déjà abordé ce sujet dans un précédent article: "Architecture à base de médiateur":

En résumé, l’ESB : - joue le rôle de conciliateur entre applications en garantissant un couplage lâche entre elles - homogénéise l’implémentation des échanges (même technologie, mêmes normes, même conception, etc.) - peut être considéré comme passerelle vers la rationalisation des échanges à moyen et long termes - se positionne comme solution unique d’intégration entre les applications. On ne se repose plus de questions à chaque nouveau besoin d’échange.

Sylvain: Depuis quelques années on assiste à l'émergence de plusieurs solutions Open Source, alors : "ESB open source" ou "ESB éditeur"?

Karim: En termes de fonctionnalités, aujourd’hui les 2 solutions se valent. En termes d’outillage en développement (IDE, utilitaires d’aide au développement, etc.), exploitation (administration, déploiement, supervision), aussi en termes d’intégration des différentes briques (le MOM avec BPEL ou IEP, les connecteurs avec les composants de traitement, l’invocation de service, l’exposition de service, etc.), les solutions éditeurs ont une longueur d’avance. Avec les solutions open source, une phase plus ou moins conséquente d’industrialisation et d’intégration des différentes briques est nécessaire.

Sylvain : Quels sont les ESB Open Source qui ont retenu ton attention?

Karim : Il est vrai que plusieurs solutions ont vu le jour depuis quelques années. Entre temps, pas mal de fusions/acquisitions ont eu lieu. Au final, je peux citer parmi ceux qui se distinguent : GlassFish ESB, Mule, Fuse ESB (à base de ServiceMix) enfin JBossESB

Sylvain : Il est rare de parler des ESB sans parler des MOM (Message Driven Middleware). Alors, « MOM open source ou MOM d’éditeur »?

Karim : Je préfère les MOM open source pour leur respect des standards JMS. Généralement les MOM éditeurs sont moins standardisés en termes d’implémentation et utilisent des classes spécifiques au produit. Cela implique l’embarquement de librairies (jar) par chaque client interagissant avec le MOM. Je te laisse imaginer l’impact derrière si cette librairie subit une évolution ou un correctif.

Cela dit, les MOM open source sont moins outillés à la base mais sont compatibles avec toute solution d’administration et de supervision se basant sur les standards (notamment JMX). Donc il y a un minimum de coût d’intégration à prévoir pour outiller le MOM open source et le rendre exploitable.

Sylvain : Dans les solutions MOM open source à regarder de près, qu’est ce que tu préconises ?

Karim : Parmi les MOM open source qui sont en train de faire leurs preuves, je cite, OpenMQ (connu aussi sous le nom JavaMQ) et ActiveMQ. OpenMQ est porté par Sun Microsystems (aujourd’hui Oracle suite au rachat) et embarqué dans ses solutions d’intégration, notamment, Java CAPS 6 et GlassFish ESB. ActiveMQ est une solution soutenue par la fondation Apache.

Sylvain: Quel est ton avis sur une solution standalone vs déployée sur un Serveur d’application (MOM ou ESB)

Karim : Tu parles bien des solutions "déployables" à la fois en standalone et sur serveur d'application?

Sylvain: Oui

Karim : Le déploiement en standalone est utile pour un déploiement distribué de la solution. Chaque composant standalone est vu comme un agent (par sa légèreté) "déployable" sur les serveurs physiques applicatifs, au plus proche des applications.

Le déploiement sur un serveur d’application est nécessaire pour un déploiement centralisé et monolithique. On bénéficie alors des apports techniques à la haute disponibilité et la montée en charge.

Sylvain : J’ai une colle pour toi car celle-ci revient souvent à mes oreilles : « MQ Series ou JMS ? »

Karim : MQ Series est la solution de messaging de référence qui a fait ses preuves depuis longtemps. Malheureusement, ses coûts de licences demeurent relativement élevés et la solution demande des compétences spécifiques. Généralement les DSI qui s’orientent vers ce choix acquièrent des licences globales entreprise pour un déploiement sans contrainte.

Un point important est quand même à rappeler, peu de solutions ESB Open Source proposent des connecteurs vers ce type de MOM alors que la plupart des solutions ESB des éditeurs le font.

Sylvain : J’ai un cas plus subtil : penses-tu que la mise en place de MQ est plus aisée et coûte moins chère (build/run) que l'ESB TIBCO déjà présent chez mon client ?

Karim : Non je ne pense pas. Tibco est une solution bien intégrée et performante. Par contre je suis bien incapable d’aller plus loin dans la réponse sans te poser à mon tour des questions : quelles briques de Tibco a-t-il, et quelles versions ? Sont-elles maîtrisées en interne par l’équipe de développement et d’exploitation? Ce sont des éléments importants pour je puisse répondre plus en détail à ta question.

Sylvain : Ah j’oubliais, quid de la réutilisation des services dans l’ESB ?

Karim : L’ESB, en le considérant comme façade aux applications exposant des services, aide à la réutilisation des services. Je peux citer quelques exemples: - L’ESB pour gérer la problématique de versioning des services: lien - L’ESB en tant que façade pour les systèmes mainframes exposant déjà des services: lien

Sans oublier le fait qu’il est important de prendre quelques précautions au moment de la conception des services: démarche pour réaliser des services durables

Karim: J’espère avoir répondu à une grande partie de tes questions.

Sylvain: Ecoute je me suis remis au goût du jour avec des idées claires et synthétiques dans ma tête.