ESBは、SOAルーティング、メッセージ変換、プロトコルブリッジングなどのソリューションで使用される従来のミドルウェアです。APIGatewayと呼ばれるミドルウェアソリューションの新しいカテゴリは、現在いくつかのベンダーによって提供されています。 RESTおよびSOAP組織が公に提供するサービスにアクセスする中心点として説明されています。ただし、API Gatewayソリューションは、典型的なESB機能のサブセットを提供するようです。
それでは、ESBとAPI Gatewayの違いは何ですか?いつどちらを使用すればよいですか?
APIゲートウェイは通常、Webサービスのプロキシとして機能し、次のような興味深い値を提供します。ロギング、SOAPサービスをRESTサービスのように呼び出し可能にする、デバッグヘルプ、トレース、など... APIゲートウェイは、消費者とサービスの間に位置するため、トラフィックを簡単にキャプチャして、このようなことを実行できます。
エンタープライズサービスバス(nServiceBusなど)は、メッセージングプロトコル(RabbitMQなど)の上に配置され、基本的なメッセージングまたはpub-subに付属していない機能(または実装が困難な機能)を提供するように設計されています:データベースに保存された永続メッセージ、再試行ロジック、リスナーのカプセル化、メッセージをサブスクライブする簡単な方法、およびサガ。 ESBを使用せずにメッセージングプロトコルを使用できますが、その逆はできません。たとえば、 nServiceBus を使用せずに RabbitMQ を使用できます。
APIゲートウェイとESBはどちらもサービスプロキシを提供できるため、2つのツールの仲介機能と変換機能のみを考慮すると、それらは同一に見える場合があります。私にとってのAPIゲートウェイの主な違いは、それが育まれた特定の目的にあります。 APIゲートウェイは、変換およびいくつかのルーティング機能を提供することとは別に、自身が前面にあるリソースへのエントリポイントとして機能できる必要があります。さらに、アクセス制御と調整の側面を他の特殊なコンポーネントに委任できる必要があり、それらを利用して、望ましい動作を保証できるはずです。 APIゲートウェイはAPI管理ソリューションの一部として提供されるため、これらの機能はすべてOOTBでサポートされます。
ESBおよびその他の外部コンポーネントまたはソフトウェアを使用して、サービスプロキシに対して同様の動作を実現できる場合があります。ただし、ESBはより広範な統合要件を満たすために使用されることを意図しており、API管理のユースケースに特化していないため、それを実現するのは非常に困難です。