ESBは、ルーティング、メッセージ変換、プロトコルブリッジングなどのSOAソリューションで使用される伝統的なミドルウェアです。 APIゲートウェイと呼ばれるミドルウェアソリューションの新しいカテゴリが、現在、複数のベンダーによって提供されています。これらのソリューションは、一般に、組織が公開して提供するRESTおよびSOAPサービスにアクセスするための中心的なポイントとして記述されています。しかし、API Gatewayソリューションは、典型的なESB機能のサブセットを提供するようです。API GatewayとESBの違いは何ですか？
ESBとAPIゲートウェイの違いは何ですか？どちらを使うべきですか？
APIゲートウェイは、通常、Webサービスのプロキシとして機能し、ロギング、RESTサービスと同様に呼び出し可能なSOAPサービス、デバッグヘルプ、トレースなどを提供します。APIゲートウェイ消費者とあなたのサービスの間に座っているので、簡単にトラフィックを取得してこの種のことを行うことができます。
エンタープライズサービスバス（nServiceBusなど）は、メッセージングプロトコル（RabbitMQなど）の上に置かれて、基本的なメッセージングまたはパブリッシャの機能に付属していない機能（または実装が難しい機能）データベースに格納された永続メッセージ、リトライロジック、リスナのカプセル化、メッセージへの簡単な購読方法、およびサガなどがあります。 ESBを使用せずにメッセージングプロトコルを使用できますが、それ以外の方法は使用できません。たとえば、nServiceBusを使用せずにRabbitMQを使用できます。
APIゲートウェイとESBの両方がサービスプロキシを処理できるため、2つのツールのメディエーション機能とトランスフォーメーション機能のみを考慮すれば、同じように見える場合があります。私にとってAPIゲートウェイの主な違いは、それが飼育される特定の目的にあります。 APIゲートウェイは、変換といくつかのルーティング機能を提供することとは別に、その前にあるリソースへのエントリポイントとして機能することができなければなりません。さらに、アクセス制御とスロットリングの側面を他の特殊なコンポーネントに委任できる必要があり、それを利用して、望ましい動作を保証できるはずです。 APIゲートウェイはAPI管理ソリューションの一部として提供されるため、これらの機能はすべてOOTBでサポートされます。
ESBや他の外部コンポーネントやソフトウェアを使用してサービスプロキシで同様の動作を実現することができます。しかし、ESBはより広範な統合要件を満たすために使用されるものであり、API管理に特化していないため、それらを実現するユースケースははるかに難しくなります。
サービスバスは、必ずしもメッセージング実装の上に座る必要はありません。それはかなりオーバーロードされた言葉です。 – JoG
確かに...しかし、問題はメッセージングではなく、ESBのことを具体的に指していました。 –