Avantages d'un bus de service d'entreprise

les ESB sont un bon moyen d'implémenter Enterprise Integration Patterns.

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'ancrer les services dans cette architecture afin qu'ils peut écouter des messages, traiter des messages et générer des messages (Endpoints de messages, adaptateurs de canaux, etc.).
• vous pouvez vouloir un conteneur géré pour déployer ces divers composants dans (Par exemple ServiceMix, Mule)
• vous pouvez vouloir un certain nombre de composants pré-construits et d'adaptateurs dans divers protocoles (par exemple ServiceMix, Mule et Camel ont beaucoup de composants pré-construits).
• vous pouvez avoir besoin de flux de travail de longue durée. La gestion des processus d'affaires est souvent fourni à côté d'un ESB (Apache ODE se branche dans un certain nombre D'ESBs Open Source).

solutions de rechange à l'ESB

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

• pour fournir des services distribués, les gens utilisent souvent des serveurs d'applications qui exposent les services via un protocole RPC de 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 une serveur.
• pour répondre à des protocoles spécifiques, vous pouvez juste construire un client qui répond à ce protocole par exemple en écrivant une application qui écoute les e-mails en utilisant JavaMail ou une qui écoute XMPP en utilisant Smack. Si votre problème est limité à un ou deux protocoles, il ne vaut peut-être pas la peine de faire appel à une ESB complète.

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

cela dépendra de L'ESB que vous sélectionnez, bien que que la plupart des bons sont conçus pour faire appel à toutes sortes de protocoles ainsi que des pojos hôtes, il n'y a pas grand chose que vous devriez faire 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 un tutoriel.

Trois avantages clés:

• un bus fournit un moyen pour les points terminaux de se connecter les uns aux autres sans avoir à parler directement entre eux. simplifie les communications pour les points terminaux comme ils doivent seulement se conformer à une interface de communication standard, le bus. (C'est avec toutes les techniques de bus, et pas seulement l'ESBs)
• un ESB fournit un seul endroit pour obtenir quelques paramètres clés de fin de point: la fréquence, la disponibilité, et performance.
• une ESB a tendance à fournir plus d'une interface de communication. Cependant, un développeur doit seulement choisir le plus facile à obtenir et de recevoir les données de l'autobus.

cependant, assurez-vous que ceux-ci fourniront la valeur de l'entreprise pour votre situation. Avoir un ESB ajoute encore une autre complexité à votre entreprise. Idéalement, vous ne devriez pas choisir cette fonction sur quelques applications, mais l'ensemble de l'organisation. Il devrait y avoir seulement cluster production ESB pour l'organisation.

Solutions:

• connectez les choses directement entre elles, surtout si les protocoles de communication sont les mêmes. Cela est bon pour les groupes d'applications simples et ne nécessite pas trop de réflexion. Toutefois, à mesure que votre nombre d'applications augmente, il devient difficile de maintenir les interconnexions.
• une autre solution est la mise en oeuvre du MQ. Ce qui vous donnera un façon de transférer les données sans avoir interconnexions complexes, mais alors vous êtes obligé d'utiliser un seul canal de communication. Heureusement pour Java, ils ont la norme JMS.

aspect pratique:

j'ai indiqué les alternatives possibles. Ils peuvent sembler mauvais au début, mais ce n'est pas pour dire que vous ne pouvez pas commencer de cette façon. J'écris personnellement des choses pour parler directement à la télécommande sans passer par un ESB pour m'assurer que ça marche sans trop m'inquiéter les questions d'intégration.

si vous n'avez pas D'ESB, je vous suggère D'essayer Mule pour le 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 s'assurer que nous gardons les vendeurs honnête et pour s'assurer que vos développeurs sont conformes aux normes empêchant le verrouillage de fournisseur par inadvertance.

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

en plus des sites déjà mentionnés. Vous devriez lire cet article sur "Ne pas utiliser un ESB sauf si vous devez absolument". Il a été écrit par le CTO de MuleSource, l'un des logiciels libres les plus populaires de L'ESB. Ce n'est pas vraiment une réponse à votre question, mais plutôt de faire un point pour vous demander "ai-je besoin d'un ESB?"

il y a un 3 décent partie de la série chez IBM concernant ESB qui est plutôt axée sur le concept et agnostic vendeur (pour la plupart). J'ai trouvé beaucoup de bonnes choses sur ESB en fouillant le site D'IBM. Il ya aussi quelques informations décentes et des vidéos et des trucs à la BizTalk site.

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

un bus de services d'entreprise (ESB) est une architecture logicielle pour middleware qui fournit des services fondamentaux pour des architectures plus complexes. Par exemple, une ESB incorpore les caractéristiques nécessaires à la mise en œuvre d'une architecture axée sur le service (AAS). D'une manière générale, on peut considérer qu'une ESB est un mécanisme qui gère l'accès aux applications et aux services (en particulier les versions existantes) pour présenter une interface unique, simple et cohérente aux utilisateurs finaux par L'entremise du web ou des formulaires côté client. frontal.

essentiellement, ESB fait pour les services et applications distribués hétérogènes back-end et distribués hétérogènes utilisateurs front-end et les consommateurs d'information ce middleware est vraiment censé faire: cacher la complexité, simplifier l'accès, permettre aux développeurs d'utiliser des formes génériques, canoniques de requête, d'accès et d'interaction, Gérer les détails complexes en arrière-plan. La clé de l'attrait de L'ESB, et peut-être aussi de son succès futur, réside dans sa capacité à soutenir les intégration des services et des applications en fonction des exigences opérationnelles, et non pas en fonction 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 une ESB rapide, légère, 100% open source, et conviviale distribuée sous la licence logicielle Apache v2.0. WSO2 ESB permet les administrateurs de système et les développeurs pour configurer commodément le routage de message, la médiation, la transformation, la journalisation, l'ordonnancement des tâches, le basculement, l'équilibrage de charge, et plus encore. 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. La durée D'exécution ESB est conçue pour être complètement asynchrone, non-bloquante et en continu sur la base de la Synapse D'Apache la médiation du moteur.

WSO2 ESB est développé en complément de la plateforme 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 des composants optionnels (add-ons) que vous pouvez installer dans L'ESB, et vous pouvez facilement supprimer les fonctionnalités qui ne sont pas nécessaires dans votre environnement, vous permettant ainsi de entièrement personnaliser et adapter WSO2 ESB pour répondre à votre SOA exacte besoin.

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 fabriquées sur mesure, d'autres sont acquises de tiers, et certaines peuvent être une combinaison des deux et peuvent fonctionner dans différents environnements de système.

WSO2 ESB est une ESB à part entière, prête 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 en OSGi bundle.

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 tout simplement un Framework D'intégration (comme Apache Camel). Je discute également les différences entre open source et ESBS propriétaires.

regardez 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 habituellement utilisé dans les architectures distribuées SOA, qui semblent être un mot à la mode de nos jours. Avant de vous lancer dans L'ESB, permettez-moi de vous rappeler la première loi de Martin Fowler sur la distribution des systèmes:

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

" ma première loi de conception D'objet distribué: ne distribuez pas vos objets (à partir de P of EAA.)

Le chapitre correspondant est disponible en ligne."

quand vous construisez un nouveau système, l'aspect le plus important est qu'il est à l'épreuve du futur, ce qui signifie une évolutivité et une maintenabilité faciles. Si vous construisez votre système autour du concept de services détachés avec un contrat défini statique distribué dans un environnement réseauté, vous pouvez "cacher" l'architecture que vous voulez pour ce service particulier, parce que les interfaces sont toujours là.

ESB est étroitement liée pour asyn systèmes de messagerie, donc avant de commencer à sauter dans ce genre de mise en œuvre, sachez qu'une architecture ne doit pas être homogène, c'est-à-dire tous les services être mis en œuvre de la même façon, ne pas commencer la plus grande erreur qui est de distribuer votre système dès le début, vous ne devriez distribuer que comme vous avez besoin d'échelle, pas avant main. Ce que vous devez vous assurer cependant, est que vos services devraient être en mesure d'être facilement distribués si le besoin se présente, sans rupture de contrats ce qui signifierait des changements pour les clients de ce service.

en ce qui concerne les avantages de L'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'une ESB peut être trouvé ici:

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

les pros principaux sont grossièrement énuméré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 point à point est mauvais, mais en quelque sorte point à point et de L'ESB est bon.

d'Abord, permettez-moi de m'expliquer SOA. 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 soustrait ses détails de mise en œuvre des clients.

L'AAS pourrait finir en désordre si chaque composante faisait directement appel aux services. Par conséquent, il a des questions communes suivantes.

• Comment trouvez-vous quels services sont utilisés et quels sont pas?
• comment trouvez-vous les clients qui utilisent un service particulier?
• comment déployer les mises à jour d'un service ou exposer les nouvelles versions aux services existants sans les interrompre?
• comment prendre en charge la rétrocompatibilité pour les clients plus âgés qui invoquent des interfaces de service plus anciennes
• comment procédez-vous à l'enregistrement, à la vérification, à l'application de la sécurité, etc., dans tous les services pour le trafic interne et externe?

ESB est le solution pour les problèmes ci-dessus. ESB...

• Aide apporte dans l'ordre
• Peut appliquer strictement les politiques de l'entreprise
  • p. ex. sécurité, étranglement, vérification, etc. appliqués de façon uniforme
• virtualise les paramètres de service
  • faciliter la mise en 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 peut être trouvé ici. Notez qu'ils proviennent du site développeur D'AdroitLogic et sont strictement couplés avec UltraESB, ESB D'AdroitLogic.