Message Oriented Middleware (MoM) Vs. Bus de service d'entreprise (ESB)

Question

Je viens d'un fond de MoM. Je pense que je comprends conceptuellement ESB. Cependant, je ne suis pas trop sûr des différences pratiques entre les deux lorsqu'il s'agit de choisir un choix architectural.

Voici ce que je veux savoir

1) Tous les bons liens en ligne qui peuvent m'aider à cet égard.

2) Quelqu'un peut-il me dire où il est logique d’utiliser l’une sur l’autre?

Toute aide serait utile.

Answer 1

La messagerie a tendance à se concentrer sur l’échange fiable de messages sur un réseau; Utilisation de files d'attente en tant qu'équilibreur de charge fiable et de rubriques pour implémenter la publication et l'abonnement.

Un ESB a généralement tendance à ajouter différentes fonctionnalités au-delà de la messagerie, telles que l'orchestration, le routage, la transformation et la médiation.

Je vous conseillerais de vous renseigner sur les Modèles d'intégration d'entreprise qui donnent un aperçu des modèles courants Vous aurez tendance à utiliser dans les problèmes d’intégration qui sont tous basés sur un bus de messages (même s’ils peuvent également être utilisés avec d’autres technologies de réseau).

Par exemple, en utilisant l'open source; Apache ActiveMQ fournit un échange fiable de messages faiblement couplé. Ensuite, vous pouvez utiliser Apache Camel pour implémenter le Modèles d'intégration d'entreprise pour le routage intelligent, la transformation, l'orchestration, travailler avec d'autres technologies , etc.>

Answer 2

Je mets les solutions MOM et les solutions ESB sur deux plans distincts.

Je considère MOM comme un élément constitutif des solutions ESB. En fait, les solutions ESB atteignent leurs propres capacités de couplage et de communication asynchrone, utilisant simplement le paradigme offert par la mise en œuvre spécifique de MOM.

Par conséquent, les MOM représentent des solutions pour la distribution de données / d'événements au niveau personnalisé de la qualité de service (en fonction de l'implémentation spécifique du fournisseur). Les ESB représentent plutôt des solutions offrant des fonctionnalités permettant de réaliser des orchestrations complexes dans un scénario SOA (lorsque plusieurs fournisseurs proposent leurs services). et de multiples consommateurs intéressés par la consommation des services offerts par les premiers).

Les orchestrations complexes impliquent une communication entre les systèmes existants, chacun possédant sa propre représentation de domaine de données (règles et services sur des données spécifiques) et son propre paradigme de communication (un consommateur interagit avec l'ESB via CORBA, un autre utilisant WS, etc. sur).

Il est clair que ESB représente une solution architecturale plus complexe visant à fournir l'abstraction de bus de données (tels que les bus électroniques que chacun possède dans son propre ordinateur), capable de connecter une multitude de des fournisseurs de services à une pléthore mal définie de consommateurs de services, cachant l’hétérogénéité dans (i) la représentation des données et (ii) la communication.

Désolé pour le long post, mais les concepts sont complexes et il est très difficile d’être efficace dans une déclaration courte.

Answer 3

Un ESB est généralement une couche qui route, enregistre, transforme et exécute d'autres fonctions "techniques" (c'est-à-dire non commerciales) sur des messages. Il peut traiter des messages provenant d'un système de messagerie (tel que quelque chose basé sur JMS) ou fonctionner avec d'autres types de messages (tels que des services Web basés sur SOAP). À cet égard, il est plus général que MoM.

Clause de non-responsabilité: je suis un consultant IBM WebSphere - bien que je ne contribue pas ici à titre officiel.

Answer 4

ESB avec les services Web sous sa forme véritable fournit un couplage lâche entre applications en transmettant les données par l’intermédiaire des éléments du message.

MOM fournit non seulement le couplage en vrac d’application, mais aussi le traitement du couplage en vrac.

ESB intègre des fonctionnalités supplémentaires prenant en charge une approche centrée sur la gouvernance.

Les deux peuvent être utilisés indépendamment ou ensemble, selon le scénario.

Answer 5

IBM et Oracle sont certifiés SOA. Étant donné qu'ils sont les leaders du marché (Magic Quadrant de Gartner), je voudrais savoir comment ils définissent la SOA et les ESB (ainsi que la méthodologie et les composants nécessaires pour prendre en charge la SOA, tels que la gouvernance, les registres, etc.)

Answer 6

EBS est encore un autre mot à la mode, tout comme SOA 2.0.

Vous pouvez facilement implémenter un système ESB avec des services Web normaux avec une file d'attente derrière eux. Vous pouvez avoir un routage des messages et / ou une orchestration avec SOA 1.0 (Tibco, BizzTalk), une chose n'arrête pas vraiment l'autre. Plus important encore, c'est la sémantique donnée aux messages échangés dans le système qui joue un rôle important, dans ce cas les événements. Les messages en tant qu’événements déclenchent un événement survenu dans votre système. Le contexte est donc différent.