この記事は検証可能な参考文献や出典が全く示されていないか、不十分です。出典を追加して記事の信頼性向上にご協力ください。（このテンプレートの使い方）
出典検索?: "サービス指向アーキテクチャ" ? ニュース ・ 書籍 ・ スカラー ・ CiNii ・ J-STAGE ・ NDL ・ dlib.jp ・ ジャパンサーチ ・ TWL（2022年12月）

ソフトウェア工学において、サービス指向アーキテクチャ（サービスしこうアーキテクチャ、Service-oriented architecture、SOA, 「エスオーエイ」あるいは「ソーア」と発音）とは、大規模なコンピュータ・システムを構築する際の概念あるいは手法の一つで、業務上の一処理に相当するソフトウェアの機能をサービスと見立て、そのサービスをネットワーク上で連携させてシステムの全体を構築していくことを指す言葉である。業務処理の変化をシステムの変更に素早く反映させたいという需要に応えうるものとして、2004年頃からIT業界において注目を集めている。2009年頃からクラウドコンピューティングの台頭とともに、その必要性が再認識されるようになってきている。[1]
必要条件

SOAに必要とされている条件は、次のような事柄である。

業務上の一処理に相当する単位でソフトウェアが構成されていること。SOAにおけるサービスとは、その構成単位のことである。プログラム上の部品ではなく、たとえば「決済する」「在庫状況を照会する」などの単位で一つのサービスとすることが求められる。どの程度の規模（粒度）を一つのサービスとするのが良いかについては様々な議論がある。

オープンで標準化されている技術仕様を用いてサービスのインタフェースが定義され、それに従った呼び出し、応答が可能であること。その技術的基盤として、Webサービスの使用が事実上必須となっている（Webサービスについては後述）。

サービスをネットワーク上で連携させてシステムの全体を素早く構築できること。この段階にいたるまでには、先の二つの条件が必須となる。さらに、サービスを単位として業務処理の流れを記述する技術や、その記述通りにシステム連携を実行する技術も必要となる。

経緯

SOAに通じる考え方や技術は古くから存在している。オブジェクト指向やコンポーネント指向は、決められたインタフェースに従ってソフトウェアの一部分をカプセル化、部品化し、それを組み合わせて全体を構成するという考え方を基本としている。また、分散オブジェクト、メッセージング、EAI (Enterprise Application Integration) などの技術を使用し、ネットワークを介してソフトウェアを連携（疎結合）させるといったことは、大規模なシステムにおいてはすでにある程度実施されている。

ただし、オブジェクト指向やコンポーネント指向においては、主にプログラム上の部品をソフトウェアの構成単位としており、業務処理の変化をシステムの変更に素早く反映させたいという視点においては単位が小さすぎる、とされている（もっとも、単位の大きさ（粒度）は元来任意であり、オブジェクト指向やコンポーネント指向における部品の粒度を業務処理のそれに合わせたものがSOAにおけるサービスであると捉えることもできる）。

また、従来のシステム連携技術は、特定のソフトウェア基盤の使用を前提としている、あるいは連携させるために必要な作業や手順が煩雑である。こうしたことから、システム連携のスピードやコストにおける問題点が指摘されていた。このような問題を解決するための技術あるいは概念として、2000年頃からWebサービスが提唱されている。

ただし当初のWebサービスは、現在のSOAと同様の構想がすでに提唱されてはいたものの、実装技術としてはWebを介したソフトウェアの連携自体に主眼が置かれていた。また、連携する個々のソフトウェア（サービス）をシステム全体の中でどのように位置づけるのか（サービスの粒度の目安を何に置くのか）、多数のサービスを連携させる複雑なトランザクション処理などをどのように設計、実装するのかといった事柄が、課題として残されていた。その後、Webサービスの概念や技術の拡張に伴い、2004年頃から、「Webサービス」に代わって「SOA」がキーワードとして注目されるようになった。

これらの課題の対策としてポートレットフレームワークが注目されている。オブジェクト指向やコンポーネント指向は基本的ＩＴ部品の再利用を考えている場合が多い。ポートレットフレームワークの場合は、エンドユーザが直接利用するwebページ上の機能の再利用を目指している。また、オブジェクトやコンポーネントをエンドユーザが利用する場合は別にプログラムを必要としたため、ユーザと開発者の考えに差異がある場合があった。ポートレットフレームワークの場合は、ユーザが要求する機能毎をプラグインで実装する。プラグインにはWebページに配置できる複数のポートレットを含むことができる。

オブジェクト及びコンポーネントと異なりプラグイン毎にアプリケーションサーバに追加／変更／削除できる。なお、インストールされているプラグインに含まれるポートレットをエンドユーザがドラッグ・アンド・ドロップ処理でWebページに配置することができる。即ち、エンドユーザが利用するビジネス機能をWebページに配置して利用することができる。

なお、ポートレット毎に表示、エンティティ・インターフェース、ビジネスロジックが含まれている。そのため、技術により非依存である。例えば、JSFで作成したポートレットとSpringFrameworkで作成したポートレットを一つのWebページに配置することもできる。なお、PHPで作成されたポートレットと同様な機能をもつJavaのポートレットで置き換えることもできる。

ポートレット間通信はJava API, Java RMI, Web Service, JSONなどで行うことができる。これらのプロトコル用のAPIはポートレットフレームワークが同じ機能なものを提供する。

オープンソース・ポートレットフレームワークの例としてLiferayが挙げられる。
技術的基盤

現在提唱されているSOAが前提とするシステム連携用の技術的基盤は、ほとんどの場合Webサービスである。Webサービスは、XMLやHTTPなどのインターネット標準技術を元にしており、SOAの実現に必要な事柄を技術的に支えている。純粋な概念的議論をするならば、SOAを実現する技術をWebサービスに限定する必要はない。しかし、ESBのような技術を利用せずに、SOAの実現に必要なインタフェースの標準化や製品実装の進んでいない業界動向からかんがみて、Webサービスの使用が事実上必須の状況となっている。ただし、Webサービスは単にSOAの技術的な一要素にすぎない。