La compréhension ESB

Cela va sembler un peu dur, mais fondamentalement, si vous aviez besoin d'un ESB, vous sauriez que vous aviez besoin d'un ESB.

Pour la majorité des cas d'utilisation, l'ESB est une solution à la recherche d'un problème. C'est une pile de logiciels sur conçus pour la plupart des scénarios. La plupart des gens ne font tout simplement pas assez de variété de traitement pour le justifier. Le " E "pour" Enterprise " est remarquable ici.

Dans un cas simple:

tail -F server.log | grep SEVERE >> severe.log

C'est un exemple trivial d'une instance d'un scénario ESB.

" Mais c'est juste un pipeline de commandes UNIX!"

Oui, exactement.

La partie " ESB "est le" | " et le ">> "

L'ESB est le temps d'exécution dans lequel vous pouvez lier des modules, surveiller le trafic, concevoir toutes sortes de scénarios loufoques comme des sorties de ventilateur et des jointures, etc. etc.

Les ESB sont remarquables pour avoir un tas de connecteurs pour lire un tas de sources et écrire un tas de destinations. Ils sont remarquables pour tisser des graphiques plus compliqués et des flux de travail pour le traitement en utilisant plutôt blocs logiques grossiers.

Mais ce que la plupart des gens font généralement est:

input -> DO_STUFF -> output

Avec un ESB, ils obtiennent:

ESB[input -> DO_STUFF -> output]

Dans la nature, la plupart des pipelines ne sont tout simplement pas si compliqués. Ils ont tendance à avoir une logique unique qui n'est pas réutilisable, et les gens ont tendance à la regrouper dans un seul module logique.

Eh bien, zut, vous pouvez le faire avec un script Perl.

Les pipelines longs dans les ESB ont tendance à être plus inefficaces qu'autrement. Avec beaucoup de regroupement de données dans et hors de générique modules (puisque vous utilisez rarement une charge utile binaire).

Donc, disons, CSV entre, convertit en XML, le traite, sort XML pour l'entrée dans une autre étape en tant que XML, qui le marshals, travaille dessus, le convertit en XML pour une autre étape. Rincez et répétez jusqu'à ce que le processeur atteigne 400% (FTW multicœur).

Alors quelqu'un vient avec "Hey, si je fais glisser un drop ces modules ensemble dans une seule routine, nous sautons tout ce junk XML!", et vous vous retrouvez avec " input - > DO_STUFF - > sortie".

Pour les grands systèmes, avec beaucoup de services Web qui doivent faire une intégration occasionnelle et ad hoc, ils peuvent être très bien. Si vous êtes dans une entreprise qui fait beaucoup, ils peuvent très bien fonctionner. Lorsque vous avez des dizaines de pipelines, ils peuvent vous aider avec l'aspect opérationnel de gestion.

Mais pour les pipelines compliqués, si vous avez beaucoup d'étapes, ce n'est peut-être pas une si bonne idée au-delà du prototypage, surtout s'il y a un volume réel impliqué. L'esprit, vous ne pouvez pas tout avoir le choix dépend des systèmes que vous intégrez.

Sinon, si vous avez une seule interface, vous devez vous lever then alors faites-le. Faites-le en Perl, en Java, en C#, dans n'importe quoi. Ne manquez pas et spool quelques 100MBs impairs d'infrastructure et de complexité que vous devez maintenant apprendre, maîtriser et maintenir.

Donc, encore une fois, si vous aviez besoin d'un ESB, vous le sauriez. Vraiment. Vous auriez n'importe quel système que vous avez construit ensemble de choses disparates, vous le combattriez, en parlant à des collègues à propos de la douleur que tout cela est, et vous tomberiez sur un lien vers un site vers un fournisseur et lisez un livre blanc et allez " C'est TOUT!", mais si vous ne l'avez pas encore fait, alors vous ne manquez rien.

Cela vous aidera à comprendre le concept d'ESB.

Un guide d'achat pour un Bus de service d'entreprise (ESB) Cela fournira une idée claire sur ESB.

"En matière d'intégration d'applications, l'Enterprise Service Bus (ESB) est la réponse unanime. Son architecture de solution exploite les services Web, la messagerie intermédiaire, le routage intelligent et la transformation. Compte tenu de l'étendue de ses fonctionnalités, la décision de savoir si votre organisation implémentera un ESB et si oui, lequel choisir est essentiel.

Cette session donnera un aperçu des facteurs clés qui doivent être pris en considération dont certains comprennent -

L'étape de technologie correcte à laquelle vous devriez regarder l'option d'utiliser un ESB Adaptation nécessaire de l'architecture existante La communauté environnante"

ESB est pour les cas où vous avez ce service Web et ce système de file d'attente et de fichiers dans le même système et que vous devez les intégrer. Un produit ESB résout généralement les problèmes suivants

1. Sécurité
2. Routage des messages
3. Orchestration (qui est le routage avancé des messages)
4. Transformation du protocole
5. Transformation de message
6. Surveillance
7. concours complet

Vous pouvez également faire tout cela avec d'autres outils et si vous en avez juste besoin ou deux de ces capacités, vous pouvez probablement faire sans et ESB (car il a introduit une complexité supplémentaire), mais lorsque vous avez besoin de plusieurs d'entre eux une solution intégrée sous la forme d'un ESB peut être une meilleure solution.

Comme l'a conclu @WillHartung, les ESB ont tendance à être correctement utilisées dans de grandes situations complexes. Et c'est pourquoi il s'appelle Enterprise Service Bus.

Maintenant, pour répondre réellement à votre question, ESBs typiquement:

• Communiquer sur plusieurs protocoles (par exemple HTTP, File d'attente de messages,etc.), pour l'entrée et la sortie

• Établir un format de message commun, et souvent traduire d'autres formats dans le format "canonique"

• Fournir un point de terminaison transparence (par exemple, vous envoyez un message au bus et obtenez une réponse, mais vous ne savez pas explicitement quel service, également connecté au bus, a traité votre demande.

• Fournir des capacités de surveillance et de gestion

• Faciliter la gestion des versions des services et des messages

• Renforcer la sécurité, en cas de besoin.

Donc, comme vous pouvez le voir, c'est pour faire beaucoup de communication point à point ("just do it") serait un énorme, pile ingérable de spaghettis. En effet, la plupart des endroits que j'ai vu SOA mis en œuvre, il remplace cet énorme tas de spaghettis qui existe déjà.

Un ESB est un bus de service d'entreprise, un fond de panier d'infrastructure si vous le souhaitez pour une architecture orientée service. Imaginez le chaos de centaines de services qui se réutilisent joyeusement. Comment gérer un tel environnement? Comment fournissez-vous un routage flexible et découplé entre vos services? Comment éviter l'architecture spaghetti point à point? Comment gérez-vous les transactions et la sécurité dans un paysage technologique hybride? Comment suivez vous où les messages sont dans des flux complexes sur plusieurs systèmes?

Vous utilisez un ESB.

Les ESB vous permettent généralement de concevoir des flux sur plusieurs systèmes dans un langage de configuration XML, vous offrant une multitude d'adaptateurs EIS, de plugins de transformation et de médiation, etc. Certains proposeront unE pour vous aider à concevoir des flux. Certains ESB sont très chers, d'autres sont open source.

Si vous voulez avoir une idée de ESB, consultez Mule ou WSO2, deux bons produits open source, ou même l'intégration Spring qui est un solution non clusterisée mais excellente pour découpler Java des points d'interface externe sous-jacents.