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アーキテクチャーなしで SOA を実装することは可能ですが、それではサービスを単に数多く所有していることと同じになってしまいます。 各アプリケーションのオーナーは、必要なあらゆるサービスに直接接続し、各サービス・インターフェースを満たすために必要な データ変換 を実行する必要があります。 これには多くの作業が必要となり(インターフェースが再使用可能になる場合も)、各接続が2地点間であるため、将来的には保守に関する重大な課題が生じることになります。 実際には ESB は結局のところ、 SOA 実装の事実上の要素と見なされ、2つの用語は同義語として使われることもあり、混乱を招いています。
SOAに先行するアーキテクチャーと比較して、 SOA は企業に以下のような大きなメリットを提供します。
2010年までに、 SOA の実装は、事実上すべての業界の大手企業で本格的に実施されました。 例えば、以下のようなものがあります。
SOAと マイクロサービスを比較し、互いの関係性の機微を定義するために、専門家たちはこれまで 書籍とデジタル文書で数千ページを費やしてきました。 この記事の主旨として、これら2つの主な違いは、次の通りコンポーネントの結合度と使用範囲にあります。
マイクロサービス ・アーキテクチャー は、 仮想化 、クラウド・コンピューティング、アジャイル開発プラクティス、および DevOpsの台頭とともに出現し、勢いを増しました。 こうした状況における マイクロサービス のメリットのほとんどは、コンポーネントを分離することで得られます。その分離は、次の内容を簡素化し、改善します。
SOA と マイクロサービスの違いをさらに深く理解するには、「SOA と マイクロサービス:その違いとは」をご参照ください。
マイクロサービス ・アーキテクチャー に、アプリケーション設計における俊敏性、 拡張性、レジリエンスを向上できる潜在性があることと同様に、これらの同じ手法を統合にも適用することができます。 これが重要である理由は、時間の経過とともに、過度に一元化された ESB パターンとそれに関連する統合スペシャリストの一元化されたチームがボトルネックになる可能性があるためです。 マイクロサービス の原則を借用することで、 ESB をより細かく分割し、分散型の統合に変えることができます。 これは アジャイル統合を支える大前提の1つです。
アプリケーション、サービス、データを、市場で最も包括的な統合プラットフォームであるIBM Cloud Pak for Integrationで連携できます。
アプリケーションおよびデータを、AIで自動化された強力なアプリケーション統合ソフトウェアで連携できます。
IBM API Connect®は、直感的な体験を活用することによって、APIの作成、管理、保護、ソーシャル化、および収益化を一貫して行えるようにする、セキュアなAPI管理です。
SOA(サービス指向アーキテクチャー)の基本とマイクロサービスの基本、それらの違い、およびお客様の状況にどちらのアプローチが最適であるのかについてご説明します。
このガイドでは、アプリケーションのモダナイゼーションを加速し、開発者の生産性を上げ、運用上の効率性と標準化を向上させる方法についてご説明します。
ESB(SOAの必須コンポーネント)、ESBが提供するメリット、およびESBがマイクロサービス・アーキテクチャーにどのように関連しているかについて詳しくご説明します。