Qu'est-ce qu'un ESB et à quoi sert-il?

Lors d'un emploi précédent, on parlait beaucoup de «Enterprise Service Bus» (ESB). J'ai lu des parties d'un livre conceptuel à ce sujet, mais je n'ai jamais vraiment compris comment vous alliez l'implémenter / l'intégrer en termes concrets. Je connais SOA / queuing / directory services / etc. mais je ne comprends pas ce qu'est exactement un ESB.

Est-ce une chose concrète (service / serveur / courtier / etc.) que vous y connectiez toutes vos applications de différentes manières, ou est-ce plus simplement une manière conceptuelle de concevoir des systèmes?

Toute explication ou lien vers de bons exemples serait grandement apprécié. Merci.

C'est un concept d'abstraction de niveau assez élevé. Le concept central est que l'ESB fournit le middleware et les interfaces qui permettent aux entreprises de connecter leurs applications sans écrire de code.

Cela pourrait inclure une médiation pour réconcilier des protocoles, des données et des interactions incompatibles.

L'idée d'un bus central sur lequel tout passe donne l'occasion de couches supplémentaires d'abstraction. En utilisant les normes de l'industrie pour «brancher» d'autres applications, clients, etc. dans ce bus, il est relativement facile de connecter de nouveaux services, sources de données, clients aux besoins disparates.

Implémentations réelles

En ce qui concerne les implémentations réelles, c'est le domaine des très grandes entreprises de soutien aux entreprises. Bien qu'il soit très à la mode, l'objectif est un idéal qui, à un petit niveau, peut être compris par comparaison avec Internet:

Similitude avec Internet

Un grand bus de communication avec des utilisations et des données très différentes, mais tous exécutant des protocoles standardisés.

On peut, en fait, écrire un connecteur HTTP vers FTP qui permettrait aux navigateurs d'accéder aux sites FTP sans invoquer un client FTP (généralement intégré au navigateur maintenant).

Mashups

Les mashups démontrent une mise en œuvre intéressante - prenez des données sur les itinéraires de bus de l'autorité de San Francisco, une carte de Google et des emplacements de bars à sushis de Yahoo avec des évaluations et exécutez une requête simple qui vous donne le bar à sushi le plus proche, en le pondérant de manière à ce que vous soyez prêt à voyager un peu plus loin pour un meilleur bar.

Tous les services complètement différents, incompatibles par eux-mêmes, mais utilisant des connecteurs standard (yahoo pipes, par exemple), ils peuvent être rassemblés en un tout cohérent et utile.

-Adam

Clause de non-responsabilité: Je travaille pour IBM et je consulte WebSphere ESB, un produit IBM conçu pour créer des ESB avec. Ce qui suit sont mes opinions et ne reflètent pas nécessairement la position d'IBM.

Un ESB est malheureusement différent pour différentes personnes.

Pour moi, un ESB est une technologie que vous pouvez insérer dans une architecture SOA (Service-Oriented Architecture), vous permettant de connecter des systèmes disparates entre eux. Il remplit souvent les fonctions de transformation de protocole, de modification de message, de routage, de journalisation, en tant que passerelle de sécurité, etc. Par exemple, vous pouvez utiliser un ESB pour exposer un service auparavant uniquement disponible en tant que service Web en tant que service basé sur JMS.

À cet égard, les implémentations d'ESB (ou pour être plus précis, les logiciels vendus pour construire des ESB avec - comme celui que je consulte) sont souvent technologiquement similaires à ce que l'on appelait autrefois un courtier de messagerie ou de mise en file d'attente, bien que le but soit quelque peu différent. , parce que (comme les acronymes l'impliquent) il est orienté autour des services plutôt que de déplacer des messages d'un endroit à un autre. L'importance technologique de la distinction est une question d'opinion.

Mon expérience avec l'ESB commercial est que c'est une technologie exagérée et coûteuse qui crée autant de problèmes qu'elle en résout. L'ESB reliera les nouveaux systèmes et l'héritage, les messages passeront au-dessus du bus et tout pourra communiquer avec tout le reste de manière transparente. Ajoutez de la résilience, de l'orchestration et vous disposez d'un logiciel d'application d'entreprise très puissant.

Le problème survient lorsque vous essayez de les utiliser pour de vrai, la surcharge d'écriture pour le bus, la création des structures de message, etc., peut surpasser les avantages. En tant qu'élément coûteux, l'ESB est considéré comme la panacée pour tous les problèmes technologiques, ce qui n'est pas le cas, trop de temps est passé sur le bus et non sur les applications / données connectées. Il arrive souvent que plusieurs normes concurrentes se battent pour la suprématie dans la même organisation, menant aux silos classiques dominés par la technologie que ces systèmes devraient en fait résoudre.

À mon humble avis, il est de loin préférable d'utiliser créer un petit nombre d'interfaces spécifiques, en utilisant généralement des services Web entre uniquement les systèmes qui en ont besoin.

C'est fondamentalement une manière conceptuelle de concevoir un système - les éditeurs de logiciels essaient de vous vendre plus en collant l'autocollant «ESB» dessus et les gestionnaires aiment parce qu'un ESB a l'air bien d'un «niveau supérieur».

Un ESB est essentiellement un MOM (middleware orienté message) avec un modèle de données supplémentaire et une gestion de la définition de la structure. Vous avez une définition de données commune pour toutes les applications et adaptateurs sur ce bus (peut être XML avec un XSD partagé). Tout ce qui se connecte DOIT envoyer ses informations conformément à cette définition de données. L'ESB prend en charge le chargement, le partage et la gestion des versions de cette définition de données commune. Lors de la connexion d'un nouveau composant à un ESB, vous pouvez vous attendre à plus de «compatibilité» dès la sortie de la boîte que lors de la connexion à un MOM. Chaque composant sur ce bus est conceptuellement traité comme une «ressource» - il y a donc une abstraction supplémentaire introduite pour découpler l'expéditeur du récepteur.

Exemple: disons que vous voulez connecter l'application A à l'application B dans un middleware orienté message standard, prenons JMS. Vous discutez avec vos collègues travaillant sur l'application B, convenez d'un sujet, d'un type de message et de champs et envoyez-le (pseudo code): sendJms ("TRADE.MSFT", {MapMessage trader = "pete" price = 101.4 vol = 100})

Si vous faites la même chose dans une architecture orientée services, vous devez

1. installer un logiciel supplémentaire
2. apprenez beaucoup de nouveaux concepts
3. définir votre nouveau composant Java dans l'interface d'administration de l'ESB
4. implémenter certaines interfaces contrôlées par l'ESB
5. sendJms (getDestination (), {MapMessage trader = "pete" price = 101.4 vol = 100}) - notez que la destination est injectée depuis l'ESB

La première fois, c'est probablement un peu douloureux, mais je suppose que vous pouvez vous y habituer, tout comme vous pouvez vous habituer aux EJB ;-)

Vous pourriez dire qu'un système MOM est «non typé» (structure dynamique) tandis qu'un ESB est «typé» (structure statique). Les compromis entre la messagerie brute et ESB sont similaires à d'autres choix non typés / typés:

• REST vs SOAP
• XML non validé vs XML validé avec un XSD
• Groovy contre Java
• langage interprété vs langage compilé

Pour les petits projets, il est agréable de hacher rapidement les fonctionnalités (par exemple le code Groovy) mais pour les projets plus importants, il est bon d'avoir un débogueur (par exemple Java), d'être averti à l'avance lorsque les choses se cassent et d'avoir un standard pour les personnes avant de s'engager dans le projet.

Donc, si votre projet souffre d'un trop grand nombre de personnes qui cassent le système en enregistrant des modifications non validées, passez à plus de structure (ESB au lieu de MOM). Si vos projets souffrent de ne pas faire suffisamment de choses à temps, choisissez la solution la plus simple et non typée. Si c'est les deux, faites appel à un consultant (je plaisante ;-)

Eh bien, cela dépend de qui vous demandez ... Beaucoup diraient que c'est un morceau de "middleware" qui relie divers morceaux de "logique métier" ensemble pour éliminer le codage de la messagerie entre ces modules. Je pense que c'est une définition assez générale, mais je suis sûr que vous y êtes déjà arrivé via Wikipédia et ainsi de suite.

Ceux qui voudraient que le grand ESB sauve le monde le voient tel qu'il est le plus souvent présenté, un hub pour tout faire. La plupart des implémentations ESB s'efforcent d'encapsuler toutes les tâches répétitives que nous voyons dans les logiciels d'entreprise. Cela signifie que la plupart des ESB prennent en charge le transfert de données, la sécurité, la journalisation, la traduction de protocoles, les systèmes d'événements, l'exposition des API via des services Web, etc.

Je pense que c'est aussi clair que possible ... J'espère que ça aide.

Jetez un œil à ma présentation " Spoiled for Choice - Comment choisir le bon ESB ".

J'explique quand utiliser un ESB, une suite d'intégration ou simplement un framework d'intégration (comme Apache Camel). Je discute également des différences entre les ESB open source et propriétaires.

Au-delà de la définition standard que vous pouvez obtenir sur Wikipedia . Je trouve que c'est un excellent outil pour connecter un tas de systèmes hérités sur plusieurs plates-formes et technologies. C'est également un bon outil pour créer des flux de travail distribués et des systèmes de gestion d'état (tels que le grand livre général).

Cependant, sa maintenance et son extension sont assez coûteuses, complexes et peu pratiques, ce qui en fait un mauvais choix technologique en tant qu'outil général pour la mise à l'échelle de vos applications.