エンタープライズ サービス バス (ESB)、.NET サービス バス (Windows Azure AppFabric サービス バス)、NServiceBus、RhinoServiceBus、MassTransit など。
これらの各テクノロジーに共通する点と共通しない点を理解しようとしています。
私は今日、.NET Service Bus に関する Juval Löwy のプレゼンテーションに出席しました。彼は、.NET Service Bus は ESB の貧弱なバージョンとして使用できると述べました。 ESB、他に真の ESB はありますか?
他のものが真の ESB である場合、.NET Service Bus とは対照的に、それらを真の ESB にするものは何ですか?
私は他のポスターに同意します。ESBはSOAに少し似ています。これは、満たす必要のある厳密な基準としてではなく、主にマーケティングのセールスポイントとして使用される一般的な定義です。
ウィキペディアから：
コメンテーターは、エンタープライズサービスバス（ESB）をアーキテクチャスタイル、ソフトウェア製品、またはソフトウェア製品のグループとして定義するかどうかについて意見が分かれています。ESBの使用は確かに特定のアーキテクチャへの準拠を意味しますが、「エンタープライズサービスバス」という用語はほとんどの場合、そのようなアーキテクチャを可能にするソフトウェアインフラストラクチャを意味し、本質的に、ESBはサービス指向アーキテクチャを実現するためのプラットフォームと見なされます。
ESBは、変換やルーティングなどのフロー関連の概念をサービス指向アーキテクチャーにもたらします。ESBは、エンドポイントの抽象化を提供することもできます。
用語としてのESBは、SonicSoftwareの技術エバンジェリストであるDaveChappel（および著者「EnterpriseServiceBus」-O'Reilly：2004年6月、ISBN 0-596-00675-6）によって造られたようです。私はこの本を読み、Chappellによるいくつかのセミナーに参加しましたが、この本自体は、製品Xが「真の」ESBであるかどうかを判断するのにあまり役立たないのではないかと思います。
一般に、メッセージベースのものを探す必要があります（これは、webMethodsのような他の企業が、よりWebサービス指向の製品にこの用語を使用している場合でも、明らかに本来の意図でした）。
アイデアは、ITインフラストラクチャ内のすべての「サービス」が相互にメッセージを送受信できるようにすることです。ESBはルーティングを提供し、インターフェイスエンドポイントを備えているため、元のアプリケーションが機能した場合（たとえば、HTTPポストを介してJSPページを呼び出すことにより）、メッセージを受信し、そのペイロードを使用してHTTPを介してポストすることができる小さなプログラムがあります。結果を解釈し、これらを使用してメッセージ応答を作成します。
基本的に、すべてにWebサービスを使用する代わりに、メッセージキューを使用し、ルーティングステーションを構築し、メッセージキューと他のシステム間のインターフェイスを使用することを想像してください。これはESBです。
これは長いですが、有益です：https ://gist.github.com/chitchcock/1281611
（Amazonが「すべてのAPI」ポリシーに移行した方法に関するSteve Yeggeの記事）。
ESB は技術用語というよりもマーケティング用語であることを理解する必要があると思います。多くのベンダーが、その旗印の下にテクノロジを提示しています。
注目すべきは、イベント ソースとシンクが連携するバス アーキテクチャ スタイルです。NServiceBus、RhinoServiceBus、および MassTransit には、イベントの発行とサブスクライブの概念が組み込まれていますが、.NET Service Bus にはありません。
上記の 3 つの違いは、機能よりも形式 (安定性、ドキュメント、コミュニティなど) にあります。
それが役立つことを願っています。