SOA(サービス指向アーキテクチャー)

menu icon

SOA(サービス指向アーキテクチャー)

アプリケーションの開発と統合の進化における重要な段階である SOA(サービス指向アーキテクチャー)について説明します。

SOA(Service-Oriented Architecture:サービス指向アーキテクチャー)とは

SOA(サービス指向アーキテクチャー)は、サービス・インターフェースを介してソフトウェア・コンポーネントを再使用可能にする方法を定義します。 これらのインターフェースは、大掛かりな統合を毎回実行することなく新しいアプリケーションに迅速に組み込むことができるように、共通の通信標準を利用しています。

SOAの各サービスは、完全に個別のビジネス機能(顧客の与信の確認、月々のローンの支払いの計算、または住宅ローン申請の処理など)を実行するために必要なコードとデータを統合します。 サービス・インターフェースは疎結合を提供します。つまり、統合がどのように実装されているかについての知識がほとんど、またはまったくなくても、サービス・インターフェースを呼び出すことができます。 これらのサービスは、データの読み取りや変更の要求を送信するために、SOAP(Simple Object Access Protocol)/HTTPまたはJSON/HTTPなどの標準ネットワーク・プロトコルを使用して公開されています。 これらのサービスは、開発者がすばやく見つけて再利用し、新しいアプリケーションを組み立てられるように公開されています。

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

このように、SOAは、過去20~30年にわたるアプリケーションの開発と統合の進化における重要な段階を示しています。 1990年代後半のSOA登場前、別のシステムに収容されているデータや機能にアプリケーションを接続することは、開発者が新規の開発プロジェクトごとに一部または全部を再作成しなければならない、複雑なPoint-to-Point 統合を必要としていました。 SOAを介してそれらの機能を公開することにより、毎回緊密な統合を再度作成する必要がなくなります。

なお、SOAとさらに新しいマイクロサービス・アーキテクチャーには多くの共通する用語がありますが、これらは多少関連しているだけであり、実際には、この記事で後述するように、異なる範囲で利用されていることに注意してください。

ESBとは

ESB(エンタープライズ・サービス・バス)は、一元化されたコンポーネントがバックエンド・システムへの統合を実行してから、それらの統合をサービス・インターフェースとして使用できるようにするパターンです。 データ・モデル、緊密な接続、ルーティング、複数の要求の潜在的な構成の変換を実行し、これらを単一のサービス・インターフェースとして使用可能な状態にし、新しいアプリケーションが再利用できるようにします。 ESBパターンは通常、特別に設計された統合ランタイムと上記の機能に適したツールを使用して実装され、可能な限り最大の生産性を確保します。

理論的には、ESBを使用せずにSOAを実装することができますが、アプリケーション所有者は、それぞれにサービス・インターフェースを公開する独自の方法を見つける必要があります。これは、(インターフェースが最終的に再使用可能である場合でも)多くの作業を必要とし、将来的に重大な保守の課題の原因となります。 実際には、ESBはSOA実装の事実上の要素と考えられており、この2つの用語は、時には同義語として使用され、混乱を生じさせています。

ESBの詳細については、「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つです。

SOAとIBM Cloud

お客様の会社がITインフラストラクチャーをハイブリッドクラウド・アプローチにシフトする際に、SOAに基づくワークロードを含め、さまざまなワークロードをより軽量で柔軟なクラウド導入モデルに変換する可能性が高くなります。 IBMは、SOAの先駆者の1社であり、IBM Cloudのオファリングとサービスは、お客様の既存のSOA投資を活用し、クラウドに拡張することができます。

詳細情報はこちら:

SOAは、重要なアプリケーションやデータベースがどこにあるかに関係なく、さまざまなチャネルでサービスを利用可能にできるようにします。これは、お客様の組織がクラウド・ジャーニーにおいてアプリケーションをモダナイズするときに、投資を活用するのに役立ちます。

今すぐIBM Cloudアカウントを始めましょう。