メッセージブローカーとESBの違い
メッセージブローカーとESBに関するさまざまな質問/記事（stackoverflowについても）を読みました。それでも、メッセージブローカーとESBの明確な違いを理解する手掛かりではありませんか？ここで、製品、Websphere Broker、Mule ESBを比較しようとしています!!
まず、（任意のバージョンの）Webshere BrokerはESBですか？私たちのIBM製品担当者は、それをESBであると主張しています（それについては驚きません）。
私の限られた情報は、メッセージブローカーがHUB-SPOKEモデルで動作することを教えてくれます。ただし、ESBはバスアーキテクチャで動作します。さて、一体どういう意味でしょうか？ HUBが失敗した場合（利用できないと思います）、ブローカーは完全に失敗します。これはESBの場合ではありません（そのため、彼らは言います）。ここで私が理解していないのは、「もしもBUSが失敗したら」ということです。
現在、ESBとブローカーに関する通常のことは、ルーティング、変換、オーケストレーションなどを提供することです。したがって、両方がこれを提供する場合、なぜ一方を選択するのでしょうか。
競合の別の領域は、変換に関するものです。 ESBは、メッセージブローカーと比較して異なる方法でそれを促進しますか？これに関する洞察が本当に欲しいです。
次に、水平スケーリングについて説明します。誰が誰よりも優れていますか？または、両方とも複雑さ（またはその他の要因）の点で等しくスケーラブルです。もちろんコスト面では、Webshpere Brokerは各ボックスに対して料金を請求します（各CPUは言うまでもありません）。私は、商用のミュールESBでさえそうしないと信じています。コストの部分は別として、ESBスケーリングとメッセージブローカースケーリングの意味は何ですか。 ESBでサービスレベルにスケールアップできることを知っています。これはメッセージブローカーで可能ですか？
サービスバスなしで変換ブローカーを使用でき、その逆も可能です。特定の製品に関しては、それぞれが互いに補完する方法があるため、どれも純粋にどちらか一方だとは思いません。製品によっては、ある領域でより強く、他の領域でより強いものがあります。おそらく、どの機能が個々の問題を最もよくカバーするかに基づいて選択する必要があります。
ブローカーには、ESB製品よりも、変換チェーンを構築するための組み込みの「レゴブロック」があります。 ESBとしてサービスを開始したブローカーは、負荷がかかって押しつぶされて拡張性が低下したり、堅牢なジャーナリングやジャーナルを処理するツールが不足したりする場合があります。
一部のESBでは、ロジックの重大なエラーが発見され修正された後、データベースの更新をロールバックし、キューを修正されたアプリケーションに再生できます。ほとんどのブローカーがそのレベルのトランザクションサポートを統合しているとは思わない。これがすべての「トランザクション」で機能するためには、RPCishの「データベースの更新」のようなものではなく、ビジネスイベント（販売、更新、所有権の変更など）でなければなりません。
免責事項：私はIBMコンサルタントであり、WebSphere ESBを専門としています。このコメントは公式には残されていません。
ESBは、製品というよりもアーキテクチャ上のパターンまたは概念です。広く言えば、疎結合をエンジニアリングするサービスベースの方法です。その定義は争われており、正確に定められているわけではありません。一般に、ESBは関連のない（技術的な意味での）サービスのセットです-それらはインターフェースを公開し、他のサービスからそれらを消費します。一般に、ハブアンドスポークアーキテクチャは含まれませんが、可能性はあります。
IBMは確かに、WebSphere Data BrokerとWebSphere ESBの両方を、（DataPowerハードウェアアプライアンスとともに）ESBを簡単に構築できる製品として販売しています。それらは異なる技術的ルーツを持っていますが、目的がいくらか重複しています。また、「ESB製品」としてブランド化されていない他の多くの要素を備えたESBを構築できないというわけではありません。
これですべての質問に答えられるわけではありませんが、うまくいけばIBMの部分に対処します。
メッセージブローカーとESBの違いは、主にWordの「バス」です。
私にとって、メッセージブローカーとは、ある構造から別の構造にデータを変換したり、コンテンツを変更したりする（通常は大きな）プロセスの1つです。
ESBはメッセージ指向ミドルウェア（MOM）と追加サービスであり、そのうちの1つはメッセージブローカーです。そのため、ESBはそのコンポーネントの1つとしてメッセージブローカーを含めることができます。バスは複数のプロセスで構成されます。そうでない場合、「バス」とは呼びません。バスの性質は、異なるタスクを処理する複数のコンポーネントがあり、各コンポーネントがMOMを介して通信し、何らかの形式の「共通データ形式」に準拠していることです。バスは、MOMにデータを送信するアプリケーション、データベースアダプター、メッセージブローカー、MOMブリッジなどで構成されます。
分離は少し段階的ですが、Message BrokerアーキテクチャとBusの最大の違いは、粒度です。タスクがアプリケーションA、B、..、Zといくつかのデータベースを統合することである場合、1人の大きなメッセージブローカーを使用してこれを行うことができます。または、複数の小さなコンポーネントがわずかなタスクを引き継ぐESBを使用します。たとえば、あるアダプターはAに接続し、別のアダプターはBに接続しますが（変換は行いません）、それぞれが1つ（またはそれ以上）のメッセージブローカーに送信します。 「A」または「B」のデータモデルについて知る必要はありません。優れたESBには、個々のアプリケーションの「差異」から抽象化された、バス上の共通データ定義が必要です。
変換：ESBは、メッセージブローカーが付属していない限り、変換に役立ちません。ただし、いずれの優れたESBにもメッセージブローカーを含める必要があります。メッセージブローカーは、変換のバスのエキスパートである必要がありますが、それ以外のことはありません。
水平スケーリング：接続するものが3つしかない場合（今と永遠）、おそらく本格的なESBを入手するだけの価値はありません。メッセージブローカーには、1つの大きなプロセスであるという利点があります。そこにすべてを構成し、すべてのデータマッピング、フィルタリング、およびルーティングのための中央の場所を持つことができます。
ただし、接続するアプリケーションが30個ある場合、1つのメッセージブローカーがおそらく停止します。もちろん、より多くのインスタンスを購入したり、冗長なものを実行したりできますが、戦略を変更してジョブを「ローカライズ」する必要があります。各アプリケーションのアダプター（それぞれ1つの小さなメッセージブローカーインスタンスである場合があります）は、抽象化された共通データモデル（たとえば、共有XSDを使用したXML）を生成および/または受信できる必要があります。変換タスク用の中央のメッセージブローカーも存在する可能性がありますが、そのインスタンスはデータモデルAまたはBを認識しないようにする必要があります。
数日前にUdi Dahanによるこの記事を読んだところ、根本的な違いの1つであると感じているものをより明確に理解できるかもしれません。
http://www.udidahan.com/2011/03/24/bus-and-broker-pubsub-differences
引用：
特定のイベントタイプに対して1つのパブリッシャーしか存在できないというルールは、バスとブローカーを区別するものの1つですが、どちらも明らかに複数のサブスクライバーを持つことができます
...
残念ながら、Enterprise Service Busの旗の下で販売されている多くのブローカースタイルの技術があります。一部の製品は、集中型と分散型の両方で展開できる機能（「フェデレーション」または「埋め込み」モードと呼ばれることもあります）がありますが、多くの製品は「イベントタイプごとの単一公開エンドポイント」ルールを実施しません。
この制約がなければ、間違いを犯すのは簡単すぎます。
それが役に立てば幸い。
Enterprise Service Busは、ビジネスに3つの重要な値を提供します。
- トランザクションのコンテキストベースまたはコンテンツベースのルーティング。
- あるメッセージドメインまたはトランスポートから別のメッセージドメインまたはトランスポートへの変換。
- 多対多のサービス接続。
ESBは、サービスの疎結合を提供し、サービスが最初に想定または開発されたときとはまったく異なるアプリケーションコンテキストにサービスを再構成し、アプリケーションを再コーディングする必要なくアプリケーションの再利用を促進します。 WebSphere Message Broker（または、現在IBM Integration Busと呼ばれています）は、Enterprise Service Busの代表的な例です。数行で大きな力を発揮するシンプルなコードの例については、私の投稿をご覧ください： http://soabus.org/viewtopic.php?f=3&t=1 IIBランタイム内の基本的な構造は、Logical Message Tree（LMT）と呼ばれます。開発者がやりたいことはすべて、LMTに対する何らかの操作です。 ESQLは、開発者がLMTでこれらの操作を実行するために使用できる最も効率的な言語です。ただし、他の多くの言語（Java、PHP、Pythonなど）がサポートされています。これらのアプリケーションのコーディングの90％がノードをパレットにドラッグアンドドロップすることで行われるため、IBM Integration Busよりもアプリケーションが多くなります。そのため、メッセージフロー開発者がコーディングの10％しか実行できません。ところで、IBMはWebSphere ESBを廃止しました。IBMIntegration Busの競合製品の多くは、ここ数年にわたって新しい開発が行われていません。さまざまなESB製品のリストは、soabus.orgで見ることができます。