BT

Diffuser les Connaissances et l'Innovation dans le Développement Logiciel d'Entreprise

Contribuez

Sujets

Sélectionner votre région

Accueil InfoQ Articles Choisir le bon ESB pour vos besoins en intégration

Choisir le bon ESB pour vos besoins en intégration

Favoris

Différentes applications au sein d'une entreprise et entre différentes entreprises ont besoin de communiquer les unes avec les autres. L'Enterprise Service Bus (ESB) a été créé comme un outil pour faciliter l'intégration des applications. Mais qu'est-ce qu'un ESB ? Quand est-ce qu'une suite d'intégration est plus utile ? Et quel produit est le plus adapté pour le prochain projet ? Cet article explique pourquoi il n'y a pas de solution miracle et pourquoi un ESB peut être aussi un mauvais choix. Sélectionner le bon produit est essentiel pour réussir un projet.

Définition du terme "Enterprise Service Bus"

De nombreux produits de différents éditeurs incluent "Enterprise Service Bus" dans leur nom. Malheureusement, il n'existe pas de définition standard du terme. Les produits offrent donc de nombreuses fonctionnalités différentes. Le terme ESB devrait toujours être clairement défini avant d'être utilisé. Dans la suite de l'article, un ESB est défini comme un produit logiciel qui aide le développeur dans l'intégration des applications et qui fournit l'infrastructure nécessaire pour mettre en oeuvre le routage, la conversion, et d'autres dispositifs d'intégration. Sur une échelle de complexité en intégration : un ESB se situe habituellement entre un framework et une suite alternative à l'intégration d'applications, comme le montre l'image suivante :

img1

Figure 1: Alternatives pour l'intégration d'applications

Après avoir défini le terme ESB, la prochaine section explique quand un ESB doit être utilisé, et quand un framework d’intégration ou une suite d’intégration est un meilleur choix.

Framework d’intégration

Un framework permet de mettre en place un Pattern d’Intégration d'Entreprise (EIP, http://www.eaipatterns.com), comme Splitter ou Content Based Router, afin d'intégrer des applications d'une façon standard. L'utilisation des APIs standards pour intégrer les produits diminue nettement les efforts d'implémentations et le code source est plus facile à comprendre pour les autres développeurs. Un framework est parfaitement adapté pour intégrer différentes applications qui ont des protocoles et des technologies différentes. Et les concepts comme les endpoints, les producteurs, les consommateurs et les EIP sont utilisés pour créer la logique d’intégration. L'automatisation des tests, même implicitement pris en charge, utilise les mêmes concepts.

Un framework est constitué de différents éléments provenant de librairies ordinaires. Il est donc compatible avec n'importe quel environnent de développement, même un éditeur de texte classique.

Apache Camel et Spring Integration sont des exemples connus de frameworks venant de l’environnent Java et NServiceBus pour .NET.

Avec un framework l'équipe de développement est plus ou moins seule responsable du succès du projet, et le support commercial est généralement non disponible. Des outils sont également disponibles en partie, et ne conviennent pas forcement à des déploiements sur des "missions critiques". Le reste de cet article est donc consacré aux ESB et aux suites, qui sont souvent un meilleur choix face à un framework.

Enterprise Service Bus

Comme un framework, un ESB est utilisé pour intégrer des applications. Il est d’ailleurs basé implicitement sur un framework. Néanmoins, c'est un produit beaucoup plus puissant. Contrairement à un framework et en plus des fonctionnalités basiques pour l'intégration d'applications, un ESB est un outil puissant pour le déploiement, l'administration et le monitoring au runtime. En outre, pour implémenter divers scénarios d'intégration des éditeurs graphiques peuvent être utilisés. Le "drag and drop" sert à modeliser la logique d'intégration, et le code source correspondant est généré automatiquement. Un support commercial complète souvent l'ESB.

Le net avantage des ESBs sur l'utilisation d'un framework pur, est un meilleur outillage, qui réduit le coût et la complexité de manière significative. Les problématiques d'intégrations sont résolues à un niveau supérieur d'abstraction.

Suite d'intégration

Une suite offre toutes les fonctionnalités d'un ESB, avec de nombreuses autres incluses telles que le Business Process Management (BPM), le Business Activity Monitoring, le Master Data Management, ou un Repository. Si certaines de ces fonctionnalités supplémentaires sont nécessaires en plus de l'intégration pure, l'utilisation d'une suite est donc conseillée. L'intégration complète peut donc être réalisée avec une seule stack logicielle.
Les différences entre un framework, un ESB et une suite sont, espérons-le, maintenant clarifiées. Nous verrons aussi comment sélectionner le bon ESB ou la bonne suite.

Critère de comparaison

Note : Nous ne fournirons pas de matrice qui compare tous les produits disponibles concernant différents critères. Du point du vue de l'auteur, il n'est guère possible de créer une matrice correcte et utile car les produits proposent un trop grand nombre (souvent différents) de fonctionnalités et concepts. De plus, la liste des fonctionnalités change pratiquement chaque jour dans le monde de l'informatique.
Par conséquent, il est conseillé de pré-définir les besoins, puis d'évaluer les produits qui conviennent le mieux. Les solutions propriétaires sont souvent très semblables, ainsi que leurs principaux concurrents open source qui présentent des caractéristiques similaires. Il est donc logique au début de chercher à savoir si une solution propriétaire ou open source est le meilleur choix.
Pour prendre cette décision, vous devriez utiliser les critères suivants :

  • Facilité d'utilisation : L'installation est-elle compliquée ? Combien d'outils sont nécessaires ? Le développement est-il intuitif ?
  • Maintenabilité : Comment s'administre le produit ? Existe-t-il une interface graphique pour le monitoring ?
  • Communauté : Y a-t-il des forums publics actifs ou des listes de diffusion ? Y a-t-il de nombreux articles, tutoriels, et vidéos disponibles ? Est-ce que le produit est supporté par plusieurs entreprises ?
  • Support d'entreprise : Quelles sont les options de support proposées ("heure de bureau", "24/7", hotline, email, sur place) ? Les accords de niveau de service peuvent-ils être garantis. Est-ce que le support est dans votre langue ?
  • Efficacité : Est-ce que toutes les fonctionnalités requises sont proposées ?
  • Flexibilité : Peut-on personnaliser les fonctionnalités du produit pour répondre aux besoins ?
  • Extensibilité : Est-il possible d'étendre le produit ? Le produit et ses interfaces sont-ils basés sur des standards ?
  • Connecteurs : Y a-t-il des adaptateurs disponbiles pour toutes les technologies ? Y a-t-il des adaptateurs pour les produits B2B comme SAP ou Salesforce ? Est-il facile de construire ses propres adaptateurs ?
  • Coût : Quel est le coût total (coût total d’exploration) du produit - y compris l'entretien, les produits auxiliaires, les connecteurs, etc ?
  • Licence : Quel est la licence ou le modèle de souscription utilisé ? Que se passe-t-il lorsque les besoins évoluent (plus de serveurs, plus de CPUs, passage aux machines virtuelles, etc) ? Les mises à jours sont-elles gratuites ? Les downgrades sont-elles possibles ? Les coûts sont-il "prévisibles", la liste des prix est-elle compréhensible ?

Le tableau 1 compare les avantages et les inconvénients des ESBs entre des suites propriétaires et des solutions open source du même type (vert = correct, jaune = moyen, rouge = mauvais). La conclusion concernant les différences est la suivante : les solutions propriétaires proposent généralement plus fonctionnalités et un support plus "puissant". Cependant, la question demeure, "Sont-ils vraiment nécessaires ?". N'oubliez pas que les efforts, la complexité et les coût sont proportionnellement plus élevés. Les produits open source se démarquent avec une utilisation plus facile, une plus grande flexibilité, une extensibilité facile et des coûts inférieurs.

Critère Propriétaire Open Source
Facilité d'utilisation Installation très complexe (besoin de consultants !?), "l'enfer de l'outil" Installation en un clic (également pour Mac dans certains cas), utilisation possible après quelques minutes, plate-forme unifiée
Maintenabilité et monitoring Outils puissant (ex. pour l'administration et le monitoring), l'analyse du code source n'est pas nécessaire, refactoring via GUI Outils moins puissant (ex. pour l'administration et le monitoring, l'intégration d'autres produits provenant d'autre fournisseurs est parfois nécessaire), l'analyse du code source n'est pas nécessaire, refactoring via GUI
Communauté Support payant, forums (mais pas de véritable communauté qui aide) Basé sur des projets open source, amènent leurs propres communautés
Support d'entreprise Support d'entreprise 24/7, SLAs personnelles, déploiement sur des milliers de serveurs Support d'entreprise 24/7, moins de garanties sur un support propriétaire, possible besoin de support et de consultants locaux
Fonctionnalités Fonctionnalités d'intégration + bien d'autres (BAM, CEP, EDA, etc.) Fonctionnalités d'intégration + un peu plus
Flexibilité (Demande de changement + attente longue + payant) OU (payer très cher pour l'avoir très vite) Open source, changer ce que vous voulez
Extensibilité Faites-le-vous-même (difficile) ou payant Basé sur des standards, standard de facto
Connecteurs Adaptateurs pour les technologies et les produits business Adaptateurs pour les technologies et les produits business
Prix TRES CHERS (et plus encore) MOINS CHERS
Licence Liste de prix complexe, tout est payant (mise à jour, migration vers VM, autre...) Modèle d'abonnement, mises à jours incluses, coûts prédictifs, possibilité de downgrade

Tableau 1: Avantages et inconvénients des produits propriétaires et open source

Produit alternatifs

Après l'explication des principales différences entre les produits propriétaires et open source, certains produits sont spécifiquement présentés dans la suite. Ainsi, un survol des différentes options disponibles sera donné, y compris un petit aperçu pratique.

Presque tous les vendeurs de produit d'intégration propriétaires, comme IBM et Oracle, proposent une solution pour chaque fonctionnalité. En ce qui concerne les alternatives open source, en particulier la plateforme unifiée de Talend et la plateforme WSO2 méritent d'être mentionnées, car elles proposent également des suites complètes. De plus, plusieurs de ces alternatives se concentrent uniquement sur l'ESB. Les plus importantes sont sans doute Mule ESB et Fuse ESB.

Oracle Service Bus / Fusion Middleware

L'ESB d'Oracle est Oracle Service Bus. C'est un composant d'Oracle Fusion Middleware (OMF), qui, selon la définition de cet article est une suite d'intégration. Elle possède beaucoup d'autres produits, comme par exemple, la suite SOA, Coherence, Complex Event Processing, BPEL Process Manager, Enterprise Messaging Service, Service Registry, et bien plus encore.

Il n'y a probablement plus aucune fonctionnalité qui ne soit pas fournie par la suite d'Oracle. L'outil est très puissant et stable. Des éditeurs graphiques existent pour la plupart des produits. Un support est également pour les plus convenables SLA. Si cette puissance et les SLAs sont vraiment nécessaires, Oracle est un bon choix. Cette puissance a un prix bien sûr. Et la grande complexité des produits ne doit pas être sous-estimée. De plus, il faut savoir que les licences sont très chères, que le coût du support est élevé, et que la tarification n'est pas transparente.

OFM est basé sur des standards comme Java EE, BPEL, SOAP, or SCA. Les produits sont propriétaires et proviennent de multiples acquisitions d'Oracle. Par conséquent, différentes bases de code sont utilisées, et ces différents produits nécessitent souvent l'utilisation de différents outils de développement. La somme des téléchargements peut rapidement dépasser 20Go. L'installation est fastidieuse et peut parfois prendre plusieurs jours - même pour une simple installation sur un ordinateur portable. Les produits sont plutôt lourds et les ressources nécessaires à l'exécution sont très élevées.

Parallèlement, si vous remplacez "Oracle" avec "IBM" et "Fusion Middleware" avec "WebSphere" le contenu de cette section serait presque le même. À l'exception que IBM a trois différents ESB dans son portefeuille : Message Broker, ESB et DataPower SOA Appliances. Il y a aussi Tibco, Microsoft et SAP qui jouent un rôle important dans le marché des ESBs propriétaires et des suites d'intégration.

En conclusion de cette section, on peut remarquer que les suites d'intégration propriétaires peuvent offrir presque toutes les fonctionnalités imaginables et couvrent la quasi-totalité des SLAs. Cependant, dans la plupart des projets une bonne partie de ces fonctionnalités ou de ces SLAs ne sont pas nécessaires. Dans ce cas, assurez-vous d'évaluer les alternatives open source. Les plus importantes sont décrites dans les sections suivantes.

Mule ESB

Mule ESB est l'un des premiers succès open source des ESBs. Il a beaucoup de qualités communes avec les autres ESBs open source et avec les autres mentionnés précédemment. Celui-ci comprend une installation très simple et intuitive ("un seul clic"), un outillage basé sur Eclipse. Habituellement, les ESBs open source sont des solutions très légères et extensibles. En dehors de la version open source gratuite, une version d'entreprise commerciale est disponible. Elle offre des fonctionnalités en plus et un support supplémentaire pour le produit.

Pour ceux qui ne le savent pas encore, il convient de rappeler que "open source" ne signifie pas "gratuit". Même les vendeurs de logiciels open source doivent gagner de l'argent et ne peuvent pas développer des produits et offrir un support le tout gratuitement. Toutefois, les prix sont beaucoup plus accessibles et ne reposent pas sur des listes de prix obscures comme la plupart des produits propriétaires. Néanmoins, la version open source peut être utilisée (même en production) sans aucun frais de licence. Cependant la version open source sert souvent à simplement tester ou à ce faire une idée du concept et permet de se mettre à niveau plus tard vers la version entreprise qui a des fonctionnalités et un support supplémentaires.

Comme son nom l'indique, Mule ESB est un pur ESB. Ses avantages importants, face aux frameworks comme Apache Camel ou Spring Integration, sont les éditeurs graphiques qui permettent une mise en oeuvre efficace des scénarios d'intégration, ainsi que les connecteurs disponibles pour des produits B2B comme SAP ou Salesforce. Toutefois, les fonctionnalités d'une suite sont manquantes dans Mule ESB. Pour ces cas d'utilisation, l'ESB doit être combiné avec des produits provenant d'autres fournisseurs. La petite communauté, le modèle de licence restrictif et l'accès limité au code source sont les aspects négatifs de Mule ESB. Les concurrents ont des avantages significatifs à ce sujet.

Fuse ESB

Fuse ESB est un pur ESB comme Mule ESB, sans une suite. Il est basé sur des standards de l'intégration tels que Apache CXF et Apache Camel. En conséquence, une grande communauté est assurée à la base. L'environnement de développement est basé sur Eclipse et est très intuitif.

Fuse ESB faisait partie de FuseSource. Mais, FuseSource a récemment été acquis par Red Hat et appartient désormais à la division de JBoss. Fuse ESB figure dans la road map actuelle et continuera d'être supporté. Il sera intégré dans la plateforme JBoss Enterprise SOA - tout comme la solution BPM Polymita également acquise. Il y a encore du chemin à faire pour avoir une suite unifiée, puisque l'intégration de FuseSource et de Polymita prendra encore quelques mois, et qu'avec JBoss ESB, Switchyard et Fuse ESB, 3 autres produits doivent aussi être mergés en un seul. Sur ce sujet, d'autres éditeurs open source sont bien meilleurs.

Talend ESB / Unified Platform

Talend ESB fait partie de la suite de Talend. Talend ESB peut-être utilisé indépendamment ou en combinaison avec d'autres composants de la plateforme unifiée de Talend. Tous les composants sont open source et disponibles gratuitement. La version entreprise offre des fonctionnalités supplémentaires et du support. La différence avec les produits propriétaires, c'est que tous les composants sont basés sur la même base de code et le même outillage de partout. L'utilisation de différents domaines tels que l'ESB, le BPM, l'ETL, le MDM, etc. se fait couramment et ils ne sont pas séparés dans des projets.

Tous les outils de la suite Talend sont basés sur Eclipse. On profite donc du "look and feel" et l'utilisation intuitive d'Eclipse. Talend dispose d'un designer visuel pour toutes les parties du produits et utilise une approche "zero-coding". Cela permet une mise en oeuvre efficace des scénarios d'intégration. Bien sûr, il est toujours possible d'écrire et d'intégrer une logique personnalisée, via des classes Java (POJO) ou en utilisant différents langages de scripting.

Tout comme Fuse ESB, Talend ESB est basé sur plusieurs standards de l'intégration tels que Apache Camel, Apache CXF, Apache Karaf, et Apache Zookeeper. En plus des connecteurs pour Apache Camel, et pour des technologies comme JMS, HTTP ou FTP, il dispose aussi d'adaptateurs B2B pour Alfresco, Jasper, SAP, Salesforce ou d'autres systèmes. Les 500 connecteurs ou plus sont sont inclus par défaut. De ce fait, c'est que l'IDE de Talend a des exigences matérielles plus élevées que ses concurrents. Il est donc déconseillé d'installer Talend sur un ordinateur portable trop faible. L'absence de la fonctionnalité SOA governance est aussi un autre inconvénient. Mais elle est prévue dans les prochaines versions.

WSO2 ESB / Platform

WSO2 est un éditeur relativement inconnu. Toutefois WSO2 propose toute la gamme des composants d'une suite dont Business Process Server, Business Rules Server, Business Activity Monitor ou Governance Registry. L'ensemble de la plateforme WSO2 peut être installé très facilement et offre un IDE léger basé sur Eclipse. Comme Talend et FuseSource, WSO2 utilise aussi principalement des projets open sources dans ses composants comme Apache Synapse (ESB léger), Axis (Web Service Implementation) ou ODE (Businnes Process Engine).

En plus de Talend, WSO2 est le seul éditeur qui offre une gamme complète qui repose sur une seule base de code et un environnement de développement unique. Par conséquent, rien n'oppose un processus de développement itératif, en commençant par un petit couple de fonctionnalités, puis en ajouter étape par étape. Une de ses faiblesse est son interface graphique. Il prend en charge tous les composants de la plateforme, mais il n'est pas aussi intuitif à utiliser que ses concurrents.

La suite d'intégration “Do it yourself”  ?

Avertissement pour la conclusion : Combiner plusieurs framework ou plusieurs produits pour construire une suite d'intégration est généralement inutilement coûteux et conduit à de nombreux pièges. Étant donné que plusieurs solutions existent déjà, il est fortement déconseillé d'en créer une à partir de différents éléments. Du "Glue code" doit être écrit, testé et des corrections de bugs sont à faire, surtout qu'il n'y a pas de contact spécifique en cas de problèmes. Les vendeurs s'en remettent souvent aux autres vendeurs, c'est à dire, si vous essayer de combiner un ESB avec une solution de BPM d'un autre vendeur, qui appelez vous si un problème survient ? Alors pourquoi s'infliger tous ces problèmes alors que d'autres personnes les ont déjà pris en charge dans une solution entière (également open source).

Conclusion

Il n'y pas de solution miracle pour résoudre les problèmes d'intégration. Tout d'abord, une décision doit être prise pour savoir un framework est suffisant. Soyez conscient que la plupart du code source doit être écrit par vous-même, et que les outils et le support sont rares. Sinon, un ESB est le meilleur choix. Toutefois, si plus tard les fonctionnalité supplémentaires d'une suite sont nécessaires, il serait préférable d'utiliser l'ESB dans une suite d'intégration dès le début. This secures sustainability without any problems and additional expense for the combination of multiple products. Cela sécurise sans aucun problème les dépenses supplémentaires lors de la combinaison de plusieurs produits.

Si un ESB ou une suite d'intégration doit être utilisé, il faut décider si un produit propriétaire ou open source est le meilleur choix. Les solutions propriétaires fournissent toutes les fonctionnalités possibles et un support de qualité. Par contre, ils entraînent des coûts plus élevés et une plus grande complexité. Au contraire, les solutions open source sont moins cheres, flexible et facile d'utilisation. Une fois cette question réglée, une liste peut-être créée pour évaluer les solutions de rechange en détail. Il est fortement recommandé d'effectuer des prototypes de test avant de prendre une décision finale. Assurez-vous que votre équipe développe elle-même le prototype (de la première installation au déploiement final et au monitoring), et pas seulement les consultants de l'éditeur. Votre équipe devra installer seule le produit dans le futur, et corriger les problèmes d'intégration indépendamment de tous consultants qui pourraient ne pas être disponibles.

A propros de l'auteur

Kai Wähner est Consultant Senior chez Talend. Il se concentre sur des domaines tels que Java EE, SOA, Cloud Computing, BPM, Big Data, et Enterprise Architecture Management. Merci de donner un feedback via email (kontakt@kai-waehner.de), Twitter (@KaiWaehner) ou sur les réseaux sociaux (LinkedIn / Xing).

Evaluer cet article

Pertinence
Style

Contenu Éducatif

BT