メッセージ ブローカーと ESB に関するさまざまな質問や記事 (stackoverflow も) を調べました。それでも、メッセージ ブローカーと ESB の明確な違いが何なのかわかりません。現在、Websphere Broker と Mule ESB という製品を比較しようとしています。
まず、Webshere Broker (どのバージョンでも) は ESB ですか? IBM 製品担当者は、これが ESB であると主張しています (これには驚きません)。
私の限られた情報によると、メッセージ ブローカーは HUB-SPOKE モデルで動作します。しかし、ESB はバス アーキテクチャで動作します。これはいったい何を意味するのでしょうか。ハブに障害が発生すると (おそらく使用不可)、ブローカーも完全に機能しなくなると読んだことがあります。ESB の場合はそうではありません (そう言っている人たち)。ここで理解できないのは、「バスに障害が発生した場合」です。
ESB とブローカーに関する一般的なことは、ルーティング、変換、オーケストレーションなどを提供することです。両方がこれを提供しているのであれば、どちらか一方を選択する理由はありません。
もう一つの矛盾点は、変換に関するものです。ESB はメッセージ ブローカーと比べて、異なる方法で変換を促進するのでしょうか? これについて、ぜひご意見をお聞かせください。
さて、水平スケーリングについてです。どちらが優れているでしょうか。あるいは、複雑さ (またはその他の要因) の点では、どちらも同じようにスケーラブルでしょうか。もちろん、コスト面では、Webshpere Broker はボックスごとに (CPU ごとには言うまでもなく) 課金します。商用の MULE ESB でも、そのようなことはしないと思います。コストの部分はさておき、ESB スケーリングと Message Broker スケーリングにはどのような意味があるのでしょうか。たまたま、ESB でサービス レベルまでスケールアップできることを知っています。これは Message Broker で可能ですか。
ベストアンサー1
サービス バスなしで変換ブローカーを使用することもできますし、その逆も可能です。特定の製品に関しては、それぞれが互いを補完し合うため、どちらか一方だけに限定されることはないと思います。ある製品は 1 つの領域に強く、他の製品は別の領域に強いということがあります。おそらく、個々の問題を最もよくカバーする機能に基づいて選択を行う必要があるでしょう。
ブローカーには、ESB 製品よりも変換チェーンを構築するための優れた組み込みの「レゴ ブロック」がある場合があります。ESB としてサービスに投入されたブローカーは、負荷がかかりすぎて適切に拡張できないか、堅牢なジャーナリングとジャーナルを処理するツールが不足している可能性があります。
一部の ESB では、ロジックの重大なエラーが発見され修正されると、データベースの更新をロールバックし、キューを修正されたアプリケーションに再生することができます。ほとんどのブローカーがそのレベルのトランザクション サポートを統合しているとは思いません。これが機能するには、RPC のような「データベースの更新」ではなく、ビジネス イベント (販売、更新、所有権の変更など) が「トランザクション」である必要があります。