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

サービス指向アーキテクチャ(SOA)は、ソフトウェアアプリケーションを作成する際に、再利用性とビジネスの俊敏性を向上させ、非機能要件(セキュリティ、拡張性、パフォーマンスなど)を確実に満たすことを目的としたアプローチです。

SOAには3つの働きがあり、各コンポーネントがそれを1つずつ担います。サービスプロバイダは、Webサービスを作成して関連する情報をサービスレジストリ(ブローカー)に提供し、次回以降検出・再利用できるようにします。サービスリクエスタは、ブローカー経由で必要なサービスを探し、それをサービスプロバイダに関連付けて必要な機能を呼び出せるようにします。

SOA誕生の背景

SOAは、多くのIT環境でソフトウェア開発が複雑化・低速化し、その結果、デリバリーの遅延や予算超過が常態化するようになったことを受け、今世紀初めに登場しました。当時、完成したアプリケーションは依存関係が多く、変更やアップグレードが難しいものでした。更新を行うとアプリケーションの別の部分に予想外の(悪い)影響が生じる可能性があるため、変更を実装する際は大量のテストを行わざるを得ず、非常に時間がかかっていました。

SOAでは、アプリケーションを開発する際に1つのモノリシックなエンティティとして作成するのではなく、管理のしやすい小さな要素(サービス)に分けることを目指しました。ここでいう「サービス」は、完全体のアプリケーションではありません。自由に組み合わせてアプリケーションを作成するためのコンポーネントです。SOAには、コンポーネントを作成し、組み合わせて十分な機能を持つアプリケーションを作成する際の指針となる設計原則がいくつかあります。

サービスとは

サービスには様々な定義がありますが、中でもOpen Groupの定義が秀逸なので紹介しましょう。

  1. 所定の結果をもたらす個別のビジネスアクティビティである。
  2. おおむね自己完結している。
  3. ユーザーにとっては「ブラックボックス」である。つまり、サービスの内部動作をユーザーが理解する必要がない。
  4. 他のサービスを含む(または完全に他のサービスで構成される)ことがある。

サービス同士は一般的に疎結合であり、多くの場合、アプリケーションに含まれる他のサービスからは独立しています。つまり、先ほど説明したような影響の「連鎖」を起こすことなく、簡単に変更できます。また、アプリケーションの別の部分で同じ機能が必要になった場合、同じサービスを再利用することもできます。

サービス指向アーキテクチャのメリット

SOAの一番のメリットは、この記事の冒頭で説明したようなフラストレーションの多くを解消できることです。エンタープライズソフトウェアの開発に伴うコストや複雑さを大幅に減らすことができるのです。また、新しいアプリケーションの作成・デプロイや既存アプリケーションのアップグレードを、非常に高速に行えるようになります。SOAを導入すると、ビジネス部門のニーズに対するIT部門の対応力が高まるため、組織としての俊敏性も大きく向上します。

マイクロサービスとサービス指向アーキテクチャの違い

マイクロサービスはクラウドネイティブであり、非常に高い俊敏性を実現し、ソフトウェアを極めて自律的に開発できるようにします。2つのアプローチは似ており、再利用性や俊敏性の推進という目的も共通していますが、スコープが異なります。SOAは、エンタープライズというコンテキストと様々なアプリケーションでの利用という側面からサービスを考えます。一方、マイクロサービスはアプリケーション自体のアーキテクチャに注目したものです。

マイクロサービスは多くの点でSOAの進化版と考えることができます。SOAでもすでにモジュールアプローチが採用されていますが、マイクロサービスにはそれ以外にも様々な改良が加えられています。だからといってこれが万能の解決策というわけではありません。また、すべての組織が本格的なマイクロサービスアーキテクチャを導入できる体制にあるかというとそうでもありません。このトピックの詳細については、「Microservices Architecture in OutSystems(OutSystemsのマイクロサービスアーキテクチャ)」のドキュメントをご覧ください。

OutSystemsはサービス指向アーキテクチャを推進しているか

この問いに対する答えは「推進している」となります。OutSystemsは、前述したエンタープライズソフトウェアの開発に伴う問題に対処するために誕生しました。優れた俊敏性、再利用性、市場リリースの高速化を実現するという目標も、SOAと同じです。SOA環境と同様に、適切に管理され簡単に検出できるサービスを使用して、完全な機能を備え、非機能要件を満たすアプリケーションをデリバリーできます。

OutSystemsと他のサービス指向アーキテクチャの違い

フェラーリは自動車ですが、自動車ならどれでもフェラーリというわけではありません。それと同じで、OutSystemsユーザーが作成したアプリケーションはいずれもSOAになりますが、すべてのSOAがOutSystemsと同じ特性を備えているわけではありません。違いは主に2つあります。

1. プラットフォームとツールキット

SOAベンダーの多くはサービスを作成するためのツールやストラクチャを提供しています。しかし、これに知的財産は含まれないため、サービス自体はすべて社内の人材で作成する必要があります。OutSystemsでは、プラットフォーム内の各コンポーネントにビジネスロジックが含まれているため、アプリケーション開発を高速化できます。コンポーネントを変更すると、そのコンポーネントが使用されている各インスタンスに変更が自動的に反映されるため、調整を加えたアプリケーションを数時間でデプロイすることができます。プラットフォームであるOutSystemsは、サービスのデプロイ、ディスカバリ、ガバナンス、サービス変更時の影響分析を大幅に自動化します。これはアジリティの向上に欠かせません。

2. ビジュアル開発とオブジェクト指向

SOAの多くはオブジェクト指向です。つまり、アーキテクチャのすべての要素をオブジェクトとして表し、それらを使用してサービスを作成します。オブジェクトを使用すると一からコーディングするよりはずっと速く作業が進みますが、開発者をしっかりトレーニングする必要があることに変わりはありません。OutSystemsでは、アプリケーションを視覚的に抽象化することで、「ドラッグ&ドロップ」方式での開発が可能です。反復的な作業の多くはバックグラウンドで自動的に処理されるため、開発者の生産性が大幅に向上します。

また、ビジュアルプログラミングを使用しているため、他の部門のユーザーでも使いこなすことができます。開発者リソースが希少かつ報酬も高騰している中、コーディングの知識を持たないユーザーをわずか数か月で開発の素養を持つ人材に育てることもできます。

OutSystemsアプリケーションのアーキテクチャの詳細については、「Application Architecture: Best Practices for Future-Proofing Your Apps(アプリケーションアーキテクチャ: 将来的にも有効なアプリに関するベストプラクティス)」をご覧ください。