メッセージブローカーとESBの違い

Message BrokersとESB（stackoverflowでも）に関するさまざまな質問/記事を読みました。メッセージブローカーとESBの明確な境界の違いは何ですか？ここで私は製品、Websphere BrokerとMule ESBを比較しようとしています!!

まず、（任意のバージョンの）Webshere BrokerはESBですか？私たちのIBM製品担当者は、それがESBであると主張しています！

メッセージブローカーはHUB-SPOKEモデルで動作するという限られた情報しか教えてくれません。ただし、ESBはバスアーキテクチャで動作します。では、いったいどういう意味でしょうか。HUBに障害が発生した場合（私は推測できない）はブローカーが完全に失敗した場合よりも読んだことがあります。これはESBの場合ではありません（つまり、それらの人は言う）。ここで私が理解できないのは、「BUSが失敗した場合はどうなりますか？」

ESBとブローカーに関する通常のことは、ルーティング、変換、オーケストレーションなどを提供することです。そのため、これらの両方がこれを提供するのであれば、なぜ一方を他方よりも選択するのでしょうか。

紛争の別の領域は、変換に関するものです。ESBは、メッセージブローカーと比較して、異なる方法でそれを容易にしますか？私はこれについていくつかの洞察が本当に好きです。

次に、水平スケーリングについて説明します。誰が誰よりも優れていますか？または、どちらも複雑さ（またはその他の要因）の点で同等にスケーラブルです。もちろんコストに関しては、Webshpere Brokerが各ボックス（CPUはもちろん）ごとに課金します。市販のMULE ESBでもそれはできないと思います。コストの部分は別として、ESBスケーリングとMessage Brokerスケーリングの影響は何ですか。ESBでサービスレベルまでスケールアップできることを知っています。これはメッセージブローカーで可能ですか？

サービスバスなしで変換ブローカーを使用でき、その逆も可能です。特定の製品に関しては、それぞれが互いに補完し合う方法があるため、どちらか一方が純粋にどちらか一方だとは思いません。ある分野でより強い製品もあれば、別の分野でより強い製品もあります。おそらく、個々の問題を最もよくカバーする機能に基づいて選択を行う必要があります。

ブローカーは、変換チェーンを構築するための組み込みの「レゴブロック」をESB製品よりも優れている場合があります。ESBとしてサービスを開始したブローカーは、負荷がかかってクラッシュし、適切にスケーリングされない可能性があります。

一部のESBでは、ロジックの重大なエラーが発見されて修正されると、データベースの更新をロールバックし、キューを修正されたアプリケーションに再生できます。ほとんどのブローカーがそのレベルのトランザクションサポートを統合しているとは思いません。これがすべての「トランザクション」で機能するためには、RPCishの「データベースの更新」などではなく、ビジネスイベント（販売、更新、所有権の変更など）である必要があります。

免責事項：私はIBMコンサルタントであり、WebSphere ESBを専門としています。このコメントはいかなる公式の立場にも置かれていません。

ESBは、製品というよりはアーキテクチャパターンまたは概念であり、おおまかに言って、疎結合を設計するサービスベースの方法です。その定義は争われており、厳密に定められているわけではありません。一般に、ESBは関連のない（技術的な意味で）サービスのセットです。これらのサービスはインターフェースを公開し、他のサービスから消費します。一般に、ハブアンドスポークアーキテクチャはありませんが、存在する可能性があります。

IBMは確かに、WebSphere Message BrokerとWebSphere ESBの両方を、（DataPowerハードウェアアプライアンスとともに）ESBの構築を容易にする製品として販売しています。技術的なルーツは異なりますが、目的が重複しています。また、「ESB製品」としてブランド化されていない他の多くのものでESBを構築できないと言っているのではありません。

これですべての質問に答えられるわけではありませんが、うまくいけばIBMの部分に対処できます。

Message BrokerとESB（Enterprise Service Bus）の違いは、主に「バス」という単語です。

私にとって、メッセージブローカーは、ある構造から別の構造にデータを変換したり、コンテンツを変更したりする（通常は大きな）プロセスです。

アンESBは、そのうちの一つのメッセージ指向ミドルウェア（MOM）に加えて、追加のサービス、である可能性があり、メッセージブローカ。したがって、ESBはコンポーネントの1つとしてメッセージブローカーを含めることができます。バスは複数のプロセスで構成されます。それ以外の場合は、「バス」とは呼びません。バスの性質は、さまざまなタスクに対応する複数のコンポーネントがあり、それぞれがMOMを介して通信し、何らかの形式の「共通データ形式」を遵守していることです。バスは、MOM、データベースアダプター、メッセージブローカー、MOMブリッジなどにデータを送信するアプリケーションで構成されます。

分離は少し段階的ですが、メッセージブローカーアーキテクチャとバスの最大の違いは、粒度の違いです。アプリケーションA、B、..、Zといくつかのデータベースを統合することがタスクの場合は、すべての人と全員を接続する1つの大きなメッセージブローカーでこれを行うことができます。または、複数の小さなコンポーネントがほんの少しのタスクを引き継ぐESBを使用します。たとえば、あるアダプターがAに接続し、別のアダプターがBに接続します（ただし、変換は行いません）。それぞれが1つ（または複数）のメッセージブローカーにデータを送信します。それぞれを可能な限りシンプルに保つ必要があります。 「A」または「B」のデータモデルについて知る必要があります。優れたESBには、バス上に共通のデータ定義があり、個々のアプリケーションの「差異」から抽象化されている必要があります。

変換：ESBは、メッセージブローカーが付属していない限り、変換に役立ちません。しかし、優れた各ESBには、とにかくメッセージブローカーを含める必要があります。メッセージブローカーは、変換のバスのエキスパートでなければなりませんが、それ以外のことはできません。

水平方向のスケーリング：接続するものが3つしかない場合（今、そして永遠に）、本格的なESBを取得するのはおそらく価値のないことです。メッセージブローカーには、1つの大きなプロセスであるという利点があります。そこですべてを構成し、すべてのデータマッピング、フィルタリング、ルーティングを一元的に行うことができます。

ただし、接続するアプリケーションが30個ある場合、1つのメッセージブローカーが停止する可能性があります。もちろん、より多くのインスタンスを購入したり、冗長なものを実行したりすることもできますが、戦略を変更してジョブを「ローカライズ」する必要があります。各アプリケーションのアダプタ（それぞれが1つの小さなメッセージブローカインスタンスである可能性があります）は、抽象化された共通データモデル（たとえば、共有XSDを使用したXML）を生成または受信できる必要があります。変換タスク用の中央のメッセージブローカーも存在する可能性がありますが、そのインスタンスはデータモデルAまたはBを認識しない必要があります。したがって、ESBはすべてを中央の場所に保持するのではなく、処理をエキスパートコンポーネントに移動する必要があります。

私は数日前にUdi Dahanによるこの記事を読んだだけです。これは、私が感じていることの1つの根本的な違いをより明確に示すかもしれません。

http://www.udidahan.com/2011/03/24/bus-and-broker-pubsub-differences

引用：

特定のイベントタイプに対して単一のパブリッシャーしか存在できないというルールは、バスとブローカーを区別するものの1つですが、どちらも明らかに複数のサブスクライバーを持つことができます

...

残念ながら、Enterprise Service Busのバナーの下で販売されているブローカースタイルのテクノロジーは数多くあります。一部の製品は、集中型と分散型の両方で展開できる機能（「フェデレーション」モードまたは「埋め込み」モードと呼ばれることもあります）を備えていますが、多くの製品は「イベントタイプごとの単一の公開エンドポイント」ルールを適用しません。

この制約がないと、間違いを犯しやすくなります。

それが役に立てば幸い。

エンタープライズサービスバスは、ビジネスに3つの重要な価値を提供します。

1. トランザクションのコンテキストベースまたはコンテンツベースのルーティング。
2. あるメッセージドメインまたはトランスポートから別のメッセージドメインまたはトランスポートへの変換。
3. 多対多のサービス接続。

ESBはサービスの疎結合を提供し、サービスが最初に想定または開発されたときとはまったく異なるアプリケーションコンテキストにサービスを再構成できるようにし、アプリケーションを再コーディングする必要なしにアプリケーションの再利用を促進します。WebSphere Message Broker（または現在はIBM Integration Busと呼ばれています）は、Enterprise Service Busの代表的な例です。数行で大きな力をもたらす単純なコードの例については、http：//soabus.org/viewtopic.php？f = 3＆t = 13で私の投稿を表示できます 。IIBランタイム内の基本的な構成は、論理メッセージツリーと呼ばれます。（LMT）。開発者がやりたいことはすべて、LMTでのある種の操作です。ESQLは、開発者がLMTでこれらの操作を実行するために使用できる最も効率的な言語ですが、他の多くの言語（Java、PHP、Pythonなど）がサポートされています。ESBの開発の効率と使いやすさに近い他の製品はありません。これらのアプリケーションのコーディングの90％はノードをパレットにドラッグアンドドロップすることで行われるため、IBM Integration Busよりもアプリケーションが多くなっています。これにより、コーディングの10％だけがメッセージフロー開発者によって行われます。ちなみに、WebSphere ESBはIBMによって廃止されており、IBM Integration Busと競合する製品の多くは、数年前からそれらに新しい開発を見ていません。さまざまなESB製品オファリングのリストは、soabus.orgで確認できます。

IBMはそれ以来、ESBオファリングの名前を変更しているので、名前やベンダーについては触れません。

ESBを使用すると、複数のハードウェアおよびソフトウェアプラットフォーム間で異種のアプリケーション間でビジネス情報をやり取りできます。ESBは、アプリケーション接続ロジックを保持し、ビジネスロジックを最小限に抑えるミドルウェアレイヤーです。これにより、アプリケーションは、そこからのデータを必要とする他のN個のアプリケーションと対話する方法について接続ロジックを埋め込むことを心配することなく、最適な処理を実行できます。ESBアーキテクチャは、企業におけるポイントツーポイントのスパゲッティ混乱を解決しようとします。

ESBとMessage Brokerは互いに同義語のようなものですが、上記の応答の1つで、Messages Brokerパターンはより大きなESBドメインの一部であることが強調されています。ESBの「B」の文字は、コンピュータアーキテクチャのバス（ハードウェア）に似ています。マザーボード上またはコンピュータ内のバスは、コンピュータが機能するためのさまざまなコンポーネントを接続します。ESBは、企業内のさまざまなサービスを接続するソフトウェアベースのバスです。ハブアンドスポークは、ESBアーキテクチャでサポートされるパターンの1つです。モノリシックな世界では、各ベンダーは独自の高可用性展開アーキテクチャを備えており、ESBを確実に利用できます。ESBベンダーが最近提供しているのは、マイクロサービスベースの展開モデルであるか、iPAASと呼ばれる独自のクラウドでホストされています。したがって、これにより、バスが失敗したり、選択した配置モデルに基づいて一時的に自己回復して失敗したりすることがなくなります。マイクロサービスベースのデプロイメントまたはiPAASにより、ESBは自動スケーリング機能（水平または垂直）を備え、選択したベンダーに基づいて機能が異なります。

ESBが提供する非常に高レベルの機能については、次のリンクにアクセスできます=> https://en.wikipedia.org/wiki/Enterprise_service_bus