ESB（エンタープライズ・サービス・バス）は、集中化されたソフトウェア・コンポーネントがアプリケーション間の統合を実行するアーキテクチャー・パターンです。データ・モデルの変換を実行し、接続性の処理、メッセージ・ルーティングの実行、通信プロトコルの変換、場合によっては複数のリクエストの構成を管理します。ESBは、これらの統合と変換を、新しいアプリケーションで再利用できるサービス・インターフェイスとして利用できるようにします。

ESBパターンは通常、最高の生産性を保証する特別に設計された統合ランタイムとツールセット（つまり、ESB製品）を使用して実装されます。

ESBは、1990年代後半に登場したソフトウェア・アーキテクチャーであるSOA（サービス指向アーキテクチャ ）の必須コンポーネントです。SOAは、サービス・インターフェイスを介してソフトウェア・コンポーネントを再利用可能にする方法を定義します。これらのサービスは通常、新しいアプリケーションでサービスによって実行される機能を複製することなく、新しいアプリケーションに迅速に組み込めるような方法で標準インターフェイス（Web サービス）を使用します。

SOA内の各サービスは、完全な個別のビジネス 機能 (例:お客様の信用度の確認、月々のローン支払いの計算、住宅ローンの申し込みの処理など）。サービス・インターフェースは疎結合を提供します。つまり、下位サービスがどのように機能するかをほとんどまたはまったく知らなくても呼び出すことができます。アプリケーション間の依存関係が軽減されます。サービス・インターフェースの背後にあるアプリケーションは、Java、Microsoft.Net、Cobol、またはその他のプログラミング言語で記述することができ、ベンダーによってパッケージ化されたエンタープライズ・アプリケーション（SAPなど）として提供されるか、SaaSアプリケーション（Salesforce CRMなど）として提供されるか、またはオープンソース・アプリケーションとして入手することができます。

サービス・インターフェースは、xml（拡張マークアップ言語）に基づく標準タグ構造であるWeb Service　Definition Language（WSDL）を使用して定義されることがよくあります。サービスは、SOAP（simple object access protocol）/HTTPやJSON/HTTPといった標準的な ネットワーク プロトコルを使って公開され、データの読み取りや変更のリクエストを送信します。サービス・ガバナンスは開発のライフサイクルを管理し、適切な段階でサービスはレジストリ（ ）に公開されます。これにより、ディベロッパーはサービスをすぐに見つけ、新しいアプリケーションやビジネス・プロセスを組み立てるために再利用することができる。

サービスは最初から構築することもできますが、多くの場合、従来の記録システムから機能を公開することによって作成されます。企業は、レガシー・システムの前に標準ベースのサービス・インターフェイスを提供するか、ESBを使用してアダプターまたはコネクター経由でレガシ・システムに直接接続するか、アプリケーションが独自のAPIを提供するかを選択できます。いずれの場合も、エンタープライズ・サービス・バスは、新しいアプリケーションをレガシー・インターフェースから保護します。ESB は、レガシー・システム・サービスに接続するために必要な変換とルーティングを実行します。

ESBアーキテクチャーを使用せずにSOAを実装することは可能ですが、これは単に多数のサービスを持つことと同じになります。各アプリケーション所有者は、必要なサービスに直接接続し、各サービス・インターフェースに合わせて必要なデータ変換を実行する必要があります。これは、たとえインターフェイスが再利用可能であっても、膨大な作業となり、各接続はポイント・ツー・ポイントであるため、将来的にはメンテナンスに重大な課題が生じます。

理論的には、一元化されたESBは、企業全体の通信、メッセージング、サービス間の統合を標準化し、劇的に簡素化する可能性をもたらします。ハードウェアとソフトウェアのコストを共有し、組み合わせて使用するために必要に応じてサーバーをプロビジョニングし、スケーラブルな集中ソリューションを提供できます。単一のスペシャリスト・チームに、統合の開発と維持を担当させる（必要に応じてトレーニングを受ける） ことができます。

ソフトウェア・アプリケーションはESBに接続（対話）するだけで、プロトコルの変換、メッセージのルーティング、必要に応じたデータ形式への変換を ESB に任せることで、トランザクションを実行するための相互運用性を提供します。エンタープライズ・サービス・バス・アーキテクチャー・アプローチは、アプリケーション統合、データ統合、およびビジネス・プロセスのサービス・オーケストレーション・スタイルの自動化のシナリオをサポートします。これにより、ディベロッパーは統合に費やす時間が大幅に短縮され、アプリケーションの提供と改善に多くの時間を集中できるようになります。また、これらの統合をプロジェクト間で再利用できるため、下流でさらに大きな生産性の向上とコスト削減が可能になる可能性がもたらされました。

しかし、ESBは多くの組織で導入に成功しましたが、他の多くの組織ではESBがボトルネックであるとみなされるようになりました。1つの統合に変更や機能強化を加えると、同じ統合を使用している他の部分が不安定になる可能性があります。ESBミドルウェアの更新は既存の統合に影響を与えることが多いため、更新を実行するには重要なテストが必要でした。ESBは一元管理されていたため、アプリケーション・チームはすぐに統合の順番待ちをすることになりました。統合の量が増えるにつれて、ESBサーバーの高可用性と災害復旧の実装のコストが増加しました。そして、企業横断的なプロジェクトであるESBは資金調達が困難であることが判明し、これらの技術的課題の解決がさらに困難になっています。

結局のところ、集中型ESBの保守、更新、スケーリングの課題は、ESBが、そしてSOAが意図していた生産性の向上そのものを遅らせ、イノベーションのペースアップを期待していた基幹業務チームをいらだたせるほど、圧倒的で高価であることが判明しました。

ESBの栄枯盛衰については、"ESBの運命"をご覧ください。

マイクロサービス・ アーキテクチャーは、単一のアプリケーションの内部を、独立して変更、拡張、管理できる小さな断片に分割することを可能にします。マイクロサービスは、 バーチャリゼーション、クラウドコンピューティング、アジャイル開発プラクティス、 DevOpsの台頭とともに登場し、勢いを増しました。このような状況において、マイクロサービスは次のことをもたらします。

• ディベロッパーがアプリケーションの残りの部分に触れたり「追いついたり」することなく、アプリケーションの一部に新しいテクノロジーを組み込めるようにすることで、ディベロッパーの俊敏性と生産性が向上します。
• 任意のコンポーネントを他のコンポーネントから独立して拡張できるようにすることで、よりシンプルでコスト効率の高い拡張性 を実現し、ワークロードの要求に可能な限り迅速に応答し、コンピューティング リソースを最も効率的に使用します。
• 1つのコンポーネントの障害が他のコンポーネントに影響を及ぼさず、各マイクロサービスが、他のコンポーネントを「最大公約数的な可用性」要件に縛られることなく、独自の可用性要件に従って実行できるため、より高い回復力を実現できます。

マイクロサービスがアプリケーション設計にもたらすのと同じ粒度を統合にももたらすことができ、同様のメリットが得られます。これが アジャイル統合の背景にある考え方であり、ESBを相互依存のない、きめ細かく分散化された統合コンポーネントに分割し、個々のアプリケーションチームが自ら所有し管理できるようにします。