サービス指向アーキテクチャー(SOA)とは
アプリケーションの開発と統合の進化において重要な段階である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つです。

関連ソリューション
IBM Cloud Pak® for Integration

アプリケーション、サービス、データを、市場で最も包括的な統合プラットフォームであるIBM Cloud Pak for Integrationで連携できます。

IBM Cloud Pak® for Integrationの詳細はこちら
IBM® App Connect

アプリケーションおよびデータを、AIで自動化された強力なアプリケーション統合ソフトウェアで連携できます。

IBM® App Connectを検討する
IBM API Connect®

IBM API Connect®は、直感的な体験を活用することによって、APIの作成、管理、保護、ソーシャル化、および収益化を一貫して行えるようにする、セキュアなAPI管理です。

Explore IBM API Connect®の詳細はこちら
参考情報 SOAとマイクロサービスの違いとは

SOA(サービス指向アーキテクチャー)の基本とマイクロサービスの基本、それらの違い、およびお客様の状況にどちらのアプローチが最適であるのかについてご説明します。

IBM Applicationモダナイゼーション・フィールド・ガイド

このガイドでは、アプリケーションのモダナイゼーションを加速し、開発者の生産性を上げ、運用上の効率性と標準化を向上させる方法についてご説明します。

エンタープライズ・サービス・バス(ESB)とは

ESB(SOAの必須コンポーネント)、ESBが提供するメリット、およびESBがマイクロサービス・アーキテクチャーにどのように関連しているかについて詳しくご説明します。

詳細情報はこちら

IBM Cloud Pak® for Integrationは、エンタープライズ統合のさまざまなスタイル全体にわたり、自動化された閉ループのライフサイクルを提供するハイブリッドの統合ソリューションです。それを使用することにより、顧客、サプライヤー、およびパートナーとの新しい対話チャネルを開きます。

IBM Cloud Pak® for Integrationの詳細を見る