SOA（Service-Oriented Architecture：サービス指向アーキテクチャー）とは

SOAとは

SOA（サービス指向アーキテクチャー）は、サービス・インターフェースを介してソフトウェア・コンポーネントを再使用可能にする方法を定義します。サービスには、共通のインターフェース標準とアーキテクチャー・パターンが使用されているため、新しいアプリケーションにサービスを迅速に組み込むことができます。それによってアプリケーション開発者は、以前は既存の機能を再開発または複製し、既存のさまざまな機能を使用した相互運用性をつなげるまたは実現する方法を熟知する必要がありましたが、そのようなタスクをなくすことが可能になります。

SOA の各サービスは、完全な個別のビジネス機能（顧客の与信の確認、毎月のローン支払いの計算、住宅ローン申請の処理など）を実行するために必要なコードと データ の統合を具体化します。サービス・インターフェースは、 サービス が表面下でどのように導入されるのかに関する知識をほとんどまたは一切必要としない疎結合を実現することで、アプリケーション間の依存関係を軽減します。

このインターフェースは、サービス・プロバイダーとサービス・コンシューマーの間のサービス契約になります。サービス・インターフェースの背後にある各アプリケーションは、 Java、 Microsoft で書き込むことができます。Net、Cobol、またはその他のプログラミング言語は、ベンダーによるソフトウェア・アプリケーション（SAPなど）のパッケージとして、または SaaS アプリケーション（Salesforce CRMなど）として提供されるか、オープンソースのアプリケーションとして取得することができます。サービス・インターフェースの定義には、多くの場合において XML （Extensible Markup Language）に基づく標準のタグ構造である Webサービス定義言語（WSDL）が使用されています。

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

これらのサービスはゼロから構築することもできますが、多くの場合、従来のSoR （Systems of Record：定型業務処理システム）の機能をサービス・インターフェースとして公開することによって作成されます。

このように、 SOA は、過去20から30年にわたるアプリケーションの開発と統合の進化において重要な段階を示しています。 1990年代後半に SOA が登場する以前は、アプリケーションを別のシステムに収容されているデータや機能に接続するためには、開発者がPoint-to-Pointに対して複雑な統合を行う必要がありました。さらにその統合は新規の開発プロジェクトごとに、一部またはすべてを再度作成する必要がありました。開発者は、それらの機能が SOA サービスを通じて公開されることにより、既存の機能を簡単に再利用し、SOA ESB アーキテクチャー （下記参照）を介して接続できるようになりました。

SOA、およびさらに新しいさまざまなマイクロサービスのアーキテクチャーには、一般的な言葉（「サービス」や「アーキテクチャー」など）が数多く含まれていますが、それら自体の関連性はあまりなく、実際には本文書で後述するように、異なる領域で運用されていることにご留意ください。

ESBとは

ESB （エンタープライズ・サービス・バス）は、集中型のソフトウェア・コンポーネントがアプリケーション間の統合を実行するアーキテクチャー・パターンです。データ・モデルの変換、コネクティビティーの処理、メッセージ送信の処理、ルーティングの実行および通信プロトコルの変換を行います。また、複数の要求の構成を管理する場合があります。 ESB は、これらの統合や変換を、新しいアプリケーションで再利用するためのサービス・インターフェースとして利用できるようにすることができます。 ESB パターンは、通常、可能な限り最高の生産性を保証するよう特別に設計された統合ランタイムとツールセットを使用して実装されます。

ESBアーキテクチャーなしで SOA を実装することは可能ですが、それではサービスを単に数多く所有していることと同じになってしまいます。各アプリケーションのオーナーは、必要なあらゆるサービスに直接接続し、各サービス・インターフェースを満たすために必要なデータ変換を実行する必要があります。これには多くの作業が必要となり（インターフェースが再使用可能になる場合も）、各接続が2地点間であるため、将来的には保守に関する重大な課題が生じることになります。実際には ESB は結局のところ、 SOA 実装の事実上の要素と見なされ、2つの用語は同義語として使われることもあり、混乱を招いています。

ESBについての詳細はこちら

SOAのメリット

SOAに先行するアーキテクチャーと比較して、 SOA は企業に以下のような大きなメリットを提供します。

高いビジネスの俊敏性（製品化までの時間がより短く）： 再利用性が鍵です。再利用可能なサービスのアプリケーションを組み合わせること（つまり新しい開発プロジェクトごとにリライトや再統合するのではなく、ブロックを構築すること）によって、開発者は新たなビジネスへの対応を迅速化してアプリケーションを構築できます。サービス指向アーキテクチャーのアプローチは、アプリケーション統合、データ統合、およびビジネス・プロセスまたはワークフローのサービス・オーケストレーション・スタイルの自動化のシナリオをサポートします。これによって開発者の統合にかかる時間が劇的に減り、 アプリケーションの配信と 改善により多くの時間をかけられるようになり、ソフトウェア設計とソフトウェア開発が加速します。
新しい市場で従来の機能を活用できる性能： 精巧な SOA により、開発者は1つのコンパチューティン・プラットフォームまたはコンピューティング環境で「ロック」されている機能を容易に取得して、それを新しい環境や市場に拡張できます。例えば、多くの企業は SOA を使用して、メインフレーム・ベースの金融システムから新しい Webアプリケーションに機能を公開しています。これにより、以前はそれらの企業の従業員またはビジネス・パートナーとの直接のやり取りを通じてのみアクセスできたプロセスや情報に、顧客が自らアクセスできるようになります。
ビジネス部門とIT部門のコラボレーションの改善： SOAでは、サービスはビジネス用語（「保険見積もりの作成」または「資本設備ROIの計算」など）で定義することができます。これにより、ビジネス・アナリストは、重要な洞察（サービスを使って定義されたビジネス・プロセスの範囲や、プロセス変更のビジネス上の影響など）について、開発者とより効果的に連携できます。そのため、より良い結果を得ることができます。

SOAの例

2010年までに、 SOA の実装は、事実上すべての業界の大手企業で本格的に実施されました。例えば、以下のようなものがあります。

Delaware Electric社は以前は相互に通信していなかったシステムを統合するために SOA に目を向けました。その結果、開発効率が向上し、州が義務付けた5年間の電気料金の凍結中に支払い能力を維持することに役立ちました。
Cisco社は、すべての製品とチャネル全体にわたって製品の注文体験を確実に一貫性のあるものにするために SOA を採用し、自社の各部門、買収企業、ビジネス・パートナーがそれぞれの Webサイトに組み込むことができるサービスとして、注文プロセスを公開しました。
フィラデルフィアのIndependence Blue Cross（IBC）社は、 SOA を実装して、患者データを扱うさまざまな関係部門や施設（IBC社の顧客サービス代理店、診療所、IBC社のWebサイト・ユーザー）が確実に同じデータ・ソース（「信頼できる唯一のソース」）で作業できるようにしました。

SOAとマイクロサービスの比較

SOAとマイクロサービスを比較し、互いの関係性の機微を定義するために、専門家たちはこれまで書籍とデジタル文書で数千ページを費やしてきました。この記事の主旨として、これら2つの主な違いは、次の通りコンポーネントの結合度と使用範囲にあります。

SOA はアーキテクチャー・スタイルおよびエンタープライズ規模の概念を統合したものです。既存のアプリケーションを、それぞれが1つのビジネス機能に対応する疎結合インターフェースに公開することができます。これにより、拡張されたエンタープライズの一部のアプリケーションは、他のアプリケーションの機能を再利用できるようになります。
マイクロサービス・アーキテクチャーはアプリケーションのアーキテクチャー・スタイル、およびアプリケーションを対象範囲とする概念です。これにより、単一のアプリケーションの内部を独立した変更、拡張、管理が可能な小さな部分に分割することができます。これは、アプリケーションが相互に通信する方法を定義しません。そのため、 SOAによって提供されるサービス・インターフェイスのエンタープライズの範囲に戻ります。

マイクロサービス・アーキテクチャーは、仮想化、クラウド・コンピューティング、アジャイル開発プラクティス、および DevOpsの台頭とともに出現し、勢いを増しました。こうした状況におけるマイクロサービスのメリットのほとんどは、コンポーネントを分離することで得られます。その分離は、次の内容を簡素化し、改善します。

開発者の俊敏性と生産性： マイクロサービスにより、開発者はアプリケーションのその他の部分に影響を与えることなく、アプリケーションの一部を新しい技術に組み込めるようになります。他のコンポーネントから独立して、任意のコンポーネントを変更、テスト、導入することができ、反復サイクルを高速化できます。
拡張性： マイクロサービスは、クラウドの拡張性を最大限に活用することができます。どのコンポーネントも他のコンポーネントから独立して拡張できるため、ワークロードの要求に可能な限り迅速に対応し、コンピューティング・リソースを最も効率的に使用できます。
レジリエンス： ここでも分離のおかげで、1つのマイクロサービスの障害が他のサービスに影響することはありません。また、各マイクロサービスは、他のコンポーネントやアプリケーション全体を最大の共通の可用性要件に委ねることなく、独自の可用性要件に対応できます。

SOA とマイクロサービスの違いをさらに深く理解するには、「SOA とマイクロサービス：その違いとは」をご参照ください。

マイクロサービス・アーキテクチャーに、アプリケーション設計における俊敏性、拡張性、レジリエンスを向上できる潜在性があることと同様に、これらの同じ手法を統合にも適用することができます。これが重要である理由は、時間の経過とともに、過度に一元化された ESB パターンとそれに関連する統合スペシャリストの一元化されたチームがボトルネックになる可能性があるためです。マイクロサービスの原則を借用することで、 ESB をより細かく分割し、分散型の統合に変えることができます。これはアジャイル統合を支える大前提の1つです。