Avantages d'un bus de service d'entreprise

Les ESB sont un bon moyen d'implémenterModèles d'intégration d'entreprise .

Types de problèmes qu'un ESB aide à résoudre

• Vous avez un certain nombre de protocoles que vous souhaitez normaliser en un seul protocole (par exemple FTP, email, SOAP, XMPP, etc. à un système de messagerie) par exemple ActiveMQ. Cela vous permet de découpler l'implémentation des services du protocole.
• Vous voulez un moyen cohérent d'accrocher les services dans cette architecture afin qu'ils puissent écouter les messages, traiter les messages et générer des messages (Points de terminaison de message,Adaptateurs de canal, etc.).
• Vous pouvez vouloir un conteneur géré pour déployer ces différents composants dans (par exemple ServiceMix, Mule)
• Vous voudrez peut-être un certain nombre de composants et d'adaptateurs prédéfinis dans divers protocoles (par exemple ServiceMix, Mule et Camel ont beaucoup de composants prédéfinis).
• Vous pouvez avoir besoin de flux de travail longs. La gestion des processus métier est souvent quelque chose qui est fourni à côté d'un ESB (Apache ODE se branche sur un certain nombre d'ESB Open Source).

Alternatives à un ESB

Les alternatives dépendent vraiment du problème que vous essayez de résoudre.

• Pour fournir des services distribués, les gens utilisent souvent des serveurs d'applications exposant des services via un protocole RPC point à point (comme les EJBs sur RMI ou les services Web sur HTTP). Donc, plutôt que de mettre un message sur un "bus", un client appelle directement un serveur.
• Pour répondre à des protocoles spécifiques, vous pouvez simplement créez un client qui répond à ce protocole, par exemple en écrivant une application qui écoute les e-mails à l'aide de JavaMail ou une application qui écoute XMPP à l'aide de Smack. Si votre problème est limité à un ou deux protocoles, il peut ne pas être utile d'apporter un ESB complet.

Ce que vous devez faire en tant que développeur pour construire des systèmes compatibles ESB

Cela dépendra de l'ESB que vous sélectionnez, bien que étant donné que la plupart des bons sont conçus pour appeler dans toutes sortes de protocoles en tant que POJOs hôte, il n'y a pas grand-chose dont vous devriez avoir besoin pour construire des systèmes compatibles ESB. Cela vaut la peine d'essayer de rendre votre code asynchrone.

Pour des exemples, Apache Camel a probablement la configuration la plus succincte, voici untutorial .

Trois avantages clés:

• Un bus fournit un moyen pour les points d'extrémité de se connecter les uns aux autres sans avoir à se parler directement. Il simplifie les communications pour les points finaux car ils ne doivent se conformer qu'à une interface de communication standard, le bus. (C'est avec n'importe quel bus technique, pas seulement ESBs)
• Un ESB fournit un single place pour obtenir des métriques clés de point final: fréquence, disponibilité et performances.
• Un ESB tend à fournir plus d'une interface de communication. Cependant, un développeur n'a qu'à choisir le plus facile pour obtenir et recevoir les données du bus.

Cependant, assurez-vous que ceux-ci fournirontune valeur commerciale pour votre situation. Avoir un ESB ajoute encore une complexité supplémentaire à votre entreprise. Idéalement, vous ne devriez pas choisir cela en fonction de quelques applications, mais de l'ensemble de l'organisation. Il ne devrait y avoir que un cluster ESB de production pour le organisation.

Alternatives:

• Il suffit de connecter les choses les unes aux autres directement, surtout si les protocoles de communication sont les mêmes. C'est bon pour les clusters d'applications simples et ne nécessite pas trop de réflexion. Cependant, à mesure que votre nombre d'applications augmente, le maintien des interconnexions devient difficile.
• Une autre alternative est une implémentation MQ. Cela vous fournira un moyen de pousser les données sans avoir d'interconnexions complexes, mais alors vous êtes obligé d'utiliser un seul canal de communication. Heureusement pour Java, ils ont la norme JMS.

Praticité:

J'ai énoncé les alternatives possibles. Ils peuvent sembler moche au début, mais cela ne veut pas dire que vous ne pouvez pas commencer de cette façon. Personnellement, j'écris des choses pour parler directement à la télécommande sans passer par un ESB pour m'assurer que cela fonctionne sans trop me soucier des problèmes d'intégration.

Si vous n'avez pas d'ESB, je vous suggère d'essayer Mule pour développement et WebSphere ESB pour le test et la production. J'ai tendance à utiliser deux produits qui sont censés suivre les normes pour nous assurer que nous gardons les fournisseurs honnêtes et pour nous assurer que vos développeurs sont conformes aux normes empêchant le verrouillage par inadvertance des fournisseurs.

En fin de compte, répondez simplement à la question suivante: est-ce que le temps d'ajouter le peu de complexité pour simplifier d'autres complexités que votre entreprise vaut le coût à long terme?

En plus des sites déjà mentionnés. Vous devriez lire cet article sur " N'utilisez pas d'ESB sauf si vous devez absolument". Il a été écrit par le directeur technique de MuleSource, l'un des ESB open source les plus populaires disponibles. Pas exactement une réponse à votre question, plus de faire un point pour vous demander "Ai-je besoin d'un ESB"?

Il existe unesérie décente en 3 parties chez IBM concernant ESB qui est assez orientée concept et agnostique (pour la plupart). J'ai trouvé beaucoup de bonnes choses sur ESB en fouillant le site d'IBM. Il y a aussi des informations décentes et des vidéos et des trucs sur le Site BizTalk.

Découvrez ce Hanselminutes podcast. Il répond à quelques questions que vous devriez vraiment vous poser avant de mettre en œuvre un bus de service.

Un bus de service d'entreprise (ESB) est une architecture logicielle pour middleware qui fournit des services fondamentaux pour des architectures plus complexes. Par exemple, un ESB intègre les fonctionnalités requises pour implémenter une architecture orientée service (SOA). Dans un sens général, un ESB peut être considéré comme un mécanisme qui gère l'accès aux applications et aux services (en particulier les versions héritées) pour présenter une interface unique, simple et cohérente aux utilisateurs finaux via le Web ou les formulaires côté client frontal.

En substance, ESB fait pour les services et applications back-end hétérogènes distribués et les utilisateurs frontaux hétérogènes distribués et les consommateurs d'informations ce que le middleware est vraiment censé faire: masquer la complexité, simplifier l'accès, permettre aux développeurs d'utiliser des formes génériques et canoniques de requête, d'accès et d'interaction, en gérant les détails complexes en arrière-plan. La clé de l'attrait d'ESB, et peut-être aussi de son succès futur, réside dans sa capacité à soutenir incrémentale l'intégration des services et des applications dépend des exigences de l'entreprise et non de la technologie disponible.

Http://searchsoa.techtarget.com/definition/enterprise-service-bus

WSO2 Bus de service d'entreprise (Produit)

WSO2 Enterprise Service Bus (ESB) 4.7.0 documentation! WSO2 ESB est un ESB rapide, léger, 100% open source et convivial distribué sous la licence Apache Software License v2.0. WSO2 ESB permet aux administrateurs système et les développeurs peuvent facilement configurer le routage des messages, la médiation, la transformation, la journalisation, la planification des tâches, le basculement, l'équilibrage de charge, etc. Il prend en charge les modèles d'intégration d'entreprise (EIPs) les plus couramment utilisés et permet la commutation de transport, le concours complet, la médiation basée sur les règles et la médiation basée sur les priorités pour les exigences d'intégration avancées. Le runtime ESB est conçu pour être complètement asynchrone, non bloquant et en streaming basé sur le moteur de médiation Apache Synapse.

WSO2 ESB est développé au - dessus de la plate-forme révolutionnaire WSO2 Carbon, un framework basé sur OSGi qui fournit une modularité transparente à votre SOA via la componentisation. Il comprend de nombreuses fonctionnalités et composants optionnels (add-ons) que vous pouvez installer dans l'ESB, et vous pouvez facilement supprimer les fonctionnalités non requises dans votre environnement, vous permettant ainsi de personnaliser et d'adapter entièrement WSO2 ESB pour répondre à vos besoins SOA exacts.

L'Architecture L'infrastructure d'application sur les entreprises peut être intrinsèquement complexe, comprenant des centaines d'applications avec une sémantique complètement différente. Certaines de ces applications sont construites sur mesure, certaines sont acquises auprès de tiers, et certains peuvent être une combinaison des deux et peut fonctionner dans différents environnements de système.

L'intégration entre ces applications hétérogènes est vitale pour l'entreprise. Différents services peuvent utiliser différents formats de données et protocoles de communication. Les emplacements physiques des services peuvent changer arbitrairement. Toutes ces contraintes signifient que vos applications sont toujours étroitement couplées. Un ESB peut être utilisé pour desserrer ces accouplements entre différents services et consommateurs de services.

WSO2 ESB est un ESB à part entière, prêt pour l'entreprise. Il est construit sur le projet Apache Synapse, qui est construit en utilisant le projet Apache Axis2. Tous les composants sont construits sous forme de bundles OSGi.

Jetez un oeil à ma présentation "L'embarras du choix - Comment choisir le bon ESB ".

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

Jetez un oeil à http://www.windowsazure.com/en-us/develop/java/how-to-guides/service-bus-queues/et http://www.windowsazure.com/en-us/develop/java/how-to-guides/service-bus-topics / Ce sont de bonnes choses.

La première question que vous devez vous poser est: pourquoi avez-vous besoin d'un ESB?

ESB est généralement utilisé dans les architectures distribuées Event SOA, qui semblent être un mot à la mode de nos jours. Avant de vous lancer dans ESB, permettez-moi de vous rappeler la Première loi de Martin Fowler sur les systèmes de distribution:

Http://martinfowler.com/bliki/FirstLaw.html

"Ma première Loi de Conception d'objets Distribués: Ne distribuez pas vos objets (À partir de P de EAA).

Le chapitre pertinent est disponible en ligne."

Lorsque vous construisez un nouveau système, l'aspect le plus important est qu'il est à l'épreuve du temps, ce qui signifie une évolutivité et une maintenabilité faciles. Si vous construisez votre système autour du concept de services perdus avec un contrat défini statique distribué dans un environnement en réseau, vous pouvez "masquer" l'architecture que vous souhaitez pour ce service particulier, car les interfaces sont toujours là.

ESB est proche des systèmes de messagerie asyn, donc avant de commencer à sauter dans ce genre d'implémentation, sachez qu'une architecture ne doit pas nécessairement être homogène, c'est-à-dire que tous les services doivent être implémentés de la même manière, ne commencez pas la plus grosse erreur qui consiste à distribuer votre système dès le début, vous ne devez distribuer que lorsque vous avez besoin d'évoluer, pas avant la main. Ce que vous devez vous assurer cependant, c'est que vos services devraient pouvoir être facilement distribués en cas de besoin, sans rompre aucun contrat, ce qui signifierait des changements pour les clients service.

Quant aux avantages d'ESB, ils sont les mêmes que SOA, ESB ajoute le contexte des opérations de messages (événements) asyn.

Un très bref aperçu des avantages d'un ESB peut être trouvé ici:

Http://javaenterpriseworld.blogspot.de/2014/02/benefits-of-esb.html

Les principaux pro sont grossièrement listés...

Il n'y a aucune raison d'utiliser un ESB. Ne pas le faire. La complexité inutile. Pourquoi passer par un intermédiaire, vous pouvez aller directement? Les gens de l'ESB vous diront que point à point est mauvais, mais que point à point vers et depuis l'ESB est bon.

Permettez-moi d'abord d'expliquerSOA . Il s'agit de construire une architecture comme un ensemble de modules logiciels réutilisables exposés comme des "Services" avec des interfaces bien définies. Les services facilitent le couplage lâche et résume ses détails de mise en œuvre des clients.

SOA pourrait finir en désordre si chaque composant appelait directement les services. Par conséquent, il a des problèmes communs suivants.

• Comment trouvez-vous quels services sont utilisés et lesquels ne le sont pas?
• Comment trouvez-vous le clients utilisant un service particulier?
• Comment déployez-vous les mises à jour d'un service ou exposez-vous de nouvelles versions à des services existants sans interruption?
• Comment prenez-vous en charge la rétrocompatibilité pour les clients plus anciens invoquant des interfaces de service plus anciennes
• Comment effectuez-vous la journalisation, l'audit, l'application de la sécurité, etc. sur tous les services pour le trafic interne / externe?

Le ESB est la solution aux problèmes ci-dessus. ESB {

• Aide apporte commande
• Peut appliquer strictement les politiques de l'entreprise
  • par exemple, sécurité, limitation, audit, etc. appliqués de manière cohérente
• Virtualise les points de terminaison de service
  • Faciliter la gestion des versions, les mises à jour flexibles, l'équilibrage HA / Charge, etc.
• Effectuer le routage, la médiation, la transformation, etc

Quelques exemples de cas d'utilisation peuvent être trouvés ici. Notez qu'ils proviennent du site développeur d'AdroitLogic et strictement couplés à UltraESB, L'ESB d'AdroitLogic.