Qu'est-ce qu'un ESB et à quoi sert-il?
Lors d'un emploi précédent, il y avait beaucoup de discussions sur "Enterprise Service Bus" (ESB). J'ai lu des parties d'un livre conceptuel à ce sujet, mais je n'ai jamais vraiment compris comment vous pourriez l'implémenter/l'intégrer en termes concrets. Je connais SOA/queuing/directory services/etc. mais je ne comprends pas exactement ce qu'est un ESB.
Est-ce une chose concrète (service/serveur/courtier/etc.) Que vous y connectiez simplement toutes vos applications de différentes manières, ou s'agit-il plutôt d'une manière conceptuelle de concevoir des systèmes?
Toutes explications ou liens vers de bons exemples seraient grandement appréciés. Merci.
C'est un concept d'abstraction 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 la médiation pour réconcilier les protocoles, les données et les interactions incompatibles.
L'idée d'un bus central sur lequel tout passe donne la possibilité de couches d'abstraction supplémentaires. L'utilisation des normes de l'industrie pour "brancher" d'autres applications, clients et autres dans ce bus permet de connecter relativement facilement de nouveaux services, sources de données et 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 support 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écutent 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 à sushi de yahoo avec des notes et exécutez une requête simple qui vous donne le bar à sushi le plus proche, en le pondérant pour que vous soyez prêt à voyager un peu plus loin pour un meilleur bar.
Tous des services complètement différents, incompatibles en eux-mêmes, mais en utilisant des connecteurs standard (yahoo pipes, par exemple), ils peuvent être rassemblés en un ensemble cohérent et utile.
-Adam
Avertissement: je travaille pour IBM et je consulte sur WebSphere ESB, un produit IBM conçu pour créer des ESB avec. Voici mes opinions et ne reflètent pas nécessairement la position d'IBM.
Un ESB est différent pour différentes personnes, malheureusement.
Pour moi, un ESB est une technologie que vous pouvez insérer dans une SOA (architecture orientée services), vous permettant de connecter des systèmes disparates entre eux. Il remplit souvent les fonctions de transformation de protocole, de message modification, routage, journalisation, fonction de 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 JMS.
À cet égard, les implémentations ESB (ou pour être plus précis, les logiciels vendus pour construire des ESB avec - tels que ceux que je consulte) sont souvent technologiquement similaires à ce qui était connu auparavant comme un courtier de messagerie ou de file d'attente, bien que le but soit quelque peu différent. , car (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.
D'après mon expérience avec ESB commercial, 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 voleront au-dessus du bus et tout pourra parler à 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 et ainsi de suite, peut surpondérer 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 est souvent vrai que plusieurs normes concurrentes se battront pour la suprématie dans la même organisation, menant aux silos classiques dominés par la technologie que ces systèmes devraient réellement réparer.
À mon humble avis, il est bien préférable d'utiliser pour créer un petit nombre d'interfaces spécifiques, en utilisant généralement des services Web uniquement entre ceux qui en ont besoin.
C'est essentiellement une façon conceptuelle de concevoir un système - les éditeurs de logiciels essaient de vous vendre davantage 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 définition de 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 conformes à 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. Lorsque vous connectez un nouveau composant à un ESB, vous pouvez vous attendre à plus de "compatibilité" hors de la boîte que lors de la connexion à un MOM. Chaque composant de ce bus est conceptuellement traité comme une "ressource" - il y a donc une abstraction supplémentaire introduite pour dissocier l'émetteur du récepteur.
Exemple: supposons que vous souhaitiez connecter l'application A à l'application B dans un middleware orienté message standard, prenons JMS. Vous parlez à vos collègues travaillant sur l'application B, vous vous accordez sur un sujet, un type de message et des champs et vous l'envoyez (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
- installer un logiciel supplémentaire
- apprendre beaucoup de nouveaux concepts
- définir votre nouveau composant Java dans l'interface d'administration de l'ESB
- implémenter certaines interfaces contrôlées par l'ESB
- 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 ;-)
On pourrait 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 grands projets, il est bon d'avoir un débogueur (par exemple Java), d'être averti à l'avance lorsque les choses se cassent et d'avoir une norme pour les personnes avant ils s'engagent dans le projet.
Donc, si votre projet souffre d'un trop grand nombre de personnes qui cassent le système en archivant des modifications non validées - passez à plus de structure (ESB plutôt que 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 - obtenez un consultant (je plaisante ;-)
Eh bien, cela dépend de qui vous demandez ... Beaucoup diraient que c'est un morceau de "middleware" qui relie différents 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à parvenu via Wikipedia et ainsi de suite.
Ceux qui voudraient que le grand ESB sauve le monde le voient comme il est le plus souvent présenté, une plaque tournante 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 s'occupent du transfert de données, de la sécurité, de la journalisation, de la traduction des protocoles, des systèmes d'événements, de l'exposition des API via les services Web, etc.
Je pense que c'est aussi clair que possible ... J'espère que ça aide.
Jetez un oeil à 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 cadre d'intégration (comme Apache Camel). Je discute également des différences entre les ESB open source et propriétaires.
Au-delà d'une définition standard, vous pouvez obtenir de 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 workflows distribués et des systèmes de gestion d'état (tels que le grand livre).
Cependant, il est plutôt coûteux, complexe et peu pratique à entretenir et à étendre, ce qui en fait un mauvais choix technologique en tant qu'outil à usage général pour faire évoluer vos applications.