サービス指向アーキテクチャー（SOA）とは

SOAにより、アプリケーション開発者は、過去には既存の機能を再開発したり複製したり、既存の機能と接続したり相互運用性を提供したりする方法を知る必要があったアプリケーション開発者のタスクを排除することができます。

SOA内の各サービスは、完全な個別のビジネス機能（例：顧客信用調査、月々のローン支払いの計算、住宅ローンの申し込みの処理など）を実行するために必要なコードとデータを具体化したものです。サービス・インターフェースは疎結合を提供します。つまり、下位サービスがどのように機能するかをほとんどまたはまったく知らなくても呼び出すことができ、アプリケーション間の依存関係が軽減されます。

このインターフェースは、サービスプロバイダーとサービス消費者の間のサービス契約です。サービス・インターフェースの背後にあるアプリケーションは、Java、Microsoft.Net、Cobol、またはその他のプログラミング言語で記述することができ、ベンダーによってパッケージ化されたソフトウェア・アプリケーション（SAPなど）として提供されるか、SaaSアプリケーション（Salesforce CRMなど）として提供されるか、またはオープンソース・アプリケーションとして入手することができます。

サービス・インターフェースは、xml（拡張マークアップ言語）に基づく標準タグ構造であるWeb Service Definition Language（WSDL）を使用して定義されることがよくあります。

サービスは、シンプル・オブジェクト・アクセス・プロトコル (SOAP)/HTTP や Restful HTTP (JSON/HTTP) などの標準ネットワークプロトコルを使用して公開され、データの読み取りまたは変更の要求を送信します。サービス・ガバナンスは開発のライフサイクルを管理し、適切な段階でサービスはレジストリに公開されます。これにより、開発者はサービスをすぐに見つけ、新しいアプリケーションやビジネス・プロセスを組み立てるために再利用することができます。

これらのサービスは最初から構築することもできますが、多くの場合、レガシー・システムの記録機能をサービス・インターフェイスとして公開することによって作成されます。

このように、SOAは、過去数十年間におけるアプリケーション開発と統合の進化において重要な段階となっています。1990 年代後半に SOA が登場する前は、アプリケーションを別のシステムに格納されているデータや機能に接続するには、ポイントツーポイント統合が必要でした。つまり、開発者は新しい開発プロジェクトごとに、その統合の一部または全体を再作成する必要がありました。これらの機能を SOA サービスを通じて公開することで、開発者は既存の機能を簡単に再利用し、SOA ESB アーキテクチャを通じて接続できるようになりました (以下を参照)。

SOA と、最近のマイクロサービス・アーキテクチャには多くの共通語 (「サービス」と「アーキテクチャ」) がありますが、両者の関連は緩く、実際にはこの記事の後半で説明するように、異なるスコープで動作します。

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

ESBは、これらの統合と変換を、新しいアプリケーションで再利用できるサービス・インターフェイスとして利用できるようにします。ESBパターンは通常、最高の生産性を保証する特別に設計された統合ランタイムとツールセットを使用して実装されます。

ESBを使用せずにSOAを実装することは可能ですが、これは単に多数のサービスを持つことと同じになります。各アプリケーション所有者は、必要なサービスに直接接続し、各サービス・インターフェースに合わせて必要なデータ変換を実行する必要があります。

これは、たとえインターフェイスが再利用可能であっても、膨大な作業となり、各接続はポイント・ツー・ポイントであるため、将来的にはメンテナンスに重大な課題が生じます。実際、ESBは最終的にはSOA実装の事実上の要素と見なされるため、この2つの用語は同義語として使用されることもあって、混乱を招いていました。

それ以前のアーキテクチャーと比較して、SOAは企業に次のような大きなメリットをもたらしました。

• ビジネスの俊敏性を高め、市場投入までの時間を短縮：再利用性が鍵となります。新しい開発プロジェクトごとに書き換えて再統合するのではなく、再利用可能なサービス、つまりビルディング・ブロックからアプリケーションを組み立てる効率により、開発者は新しいビジネス・チャンスに対応してアプリケーションをより迅速に構築できるようになります。
  サービス指向アーキテクチャー・アプローチは、アプリケーションの連携、データ統合、およびビジネス・プロセスまたはワークフローの統合のオートメーションのシナリオをサポートします。これにより、開発者は統合に費やす時間が大幅に短縮され、アプリケーションの提供と改善に多くの時間を集中できるため、ソフトウェアの設計と開発がスピードアップします。
• 新しい市場でレガシー機能を活用する能力： しっかりと作られたSOAにより、開発者は1つのコンピューティング・プラットフォームまたは環境に「ロック」された機能を簡単に採用し、それを新しい環境や市場に拡張することができます。たとえば、多くの企業はSOAを使用して、メインフレームベースの財務システムの機能を新しいWebアプリケーションに公開しています。これにより、顧客は、これまで企業の従業員やビジネス・パートナーと直接やり取りすることでしかアクセスできなかったプロセスや情報を利用できるようになります。
• ビジネスとITの連携の向上： SOAでは、サービスをビジネス用語（例：「保険の見積もりの生成」や「資本設備のROIの計算」など）で定義できます。これにより、ビジネス・アナリストは、サービスを使用することで定義されるビジネス・プロセスの範囲やプロセスを変更したことのビジネスへの影響など、重要な洞察について開発者とより効果的に連携できるようになり、より良い成果につながります。

2010年までに、ほぼすべての業種・業務の大手企業でSOAの導入が本格的に進みました。例：

Delaware Electric社は、以前は相互に通信できなかったシステムを統合するためにSOAを採用した結果、開発効率が向上し、州が義務付けた5年間の電力料金凍結中、組織が存続するのを助けました。

Cisco は、SOA を採用し、注文プロセスを Cisco の部門、買収先、ビジネス・パートナーが各自のWeb サイトに組み込むことができるサービスとして公開することにより、すべての製品とチャネルにわたって製品注文エクスペリエンスの一貫性を確保しました。

フィラデルフィアの Independence Blue Cross (IBC) は、患者データを扱うさまざまな関係者 (IBC カスタマー・サービス エージェント、医師のオフィス、IBC Web サイト ユーザー) が同じデータ ソース (「信頼できる唯一の情報源」) を使用して作業できるようにするために、SOA を実装しました。

専門家は、SOA とマイクロサービスを比較し、両者の関係の微妙な点を定義するために、数千ページの印刷物やデジタル ページを作成しました。この記事の目的において、この2つの主な違いはコンポーネントの組み合わせと使用範囲です。

つまり、SOAは統合アーキテクチャー・スタイルであり、企業全体にわたる概念です。これにより、既存のアプリケーションを疎結合インターフェイス上で公開できるようになり、それぞれがビジネス機能に対応し、拡張された企業の一部にあるアプリケーションが他のアプリケーションで機能を再利用できるようになります。

マイクロサービス・アーキテクチャーは、アプリケーション・アーキテクチャースタイルであり、アプリケーションを範囲とした概念です。これにより、単一のアプリケーションの内部を、独立して変更、拡張、管理できる小さな断片に分割できるようになります。アプリケーションがどのように相互に通信するかは定義されていません。そのため、SOAが提供するサービス・インターフェイスのエンタープライズ範囲に戻ります。

マイクロサービス・アーキテクチャーは、仮想化、クラウド・コンピューティング、アジャイル開発プラクティス、DevOpsの台頭とともに登場し、勢いを増しました。これらの状況におけるマイクロサービスの利点のほとんどは、コンポーネントの分離から生まれます。これにより、次のことが簡素化および改善されます。

• 開発者の俊敏性と生産性： マイクロサービスにより、開発者はアプリケーションの他の部分に影響を与えることなく、アプリケーションの一部に新しいテクノロジーを組み込むことができます。どのコンポーネントも他のコンポーネントとは独立して変更、テスト、デプロイができるため、反復サイクルが短縮されます。
• 拡張性： マイクロサービスはクラウドの拡張性を最大限に活用できます。どのコンポーネントも他のコンポーネントとは独立して拡張できるため、ワークロードの要求に可能な限り迅速に応答し、コンピューティング・リソースを最も効率的に使用できます。
• レジリエンス：また、分離のおかげで、マイクロサービスの障害が他のマイクロサービスに影響を与えることはありません。また、各マイクロサービスは、他のコンポーネントやアプリケーション全体を最大公約数的な可用性要件に縛られることなく、独自の可用性要件に従って動作できます。

SOA とマイクロサービスの違いについて詳しくは、 「SOA とマイクロサービス: 違いは何ですか?」を参照してください。

マイクロサービス・アーキテクチャーがアプリケーション設計に俊敏性、拡張性、レジリエンスの向上をもたらす可能性があるのと同じように、同じ手法を統合にも適用できます。

これが重要なのは、時間が経つにつれて、高度に集中化されたESBパターンと、それに関連する統合スペシャリストの集中チームがボトルネックになる可能性があるためです。マイクロサービスの原則を取り入れることで、ESBをよりきめ細かく分散化された統合に分割できる可能性があります。これは、アジャイル統合の根底にある前提の 1 つです。