この記事は検証可能な参考文献や出典が全く示されていないか、不十分です。出典を追加して記事の信頼性向上にご協力ください。（このテンプレートの使い方）
出典検索?: "サービス指向アーキテクチャ" ? ニュース ・ 書籍 ・ スカラー ・ 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の技術的な一要素にすぎない。Webサービスを利用しただけで、SOAであると言うことはない。

Webサービスにおいては、以下の三つが基本的な技術要素とされている。これらはいずれも、メッセージや定義の記述にXMLを使用している。

SOAP : サービス間の呼び出し、応答のプロトコル（下位プロトコルとしてHTTPなどを使用する。HTTP以外のプロトコルも使用可能ではあるものの、ファイアウォールをまたぐシステム連携においては困難が伴う。ほとんどの製品実装はHTTPを基本としている）。

WSDL (Web Services Description Language) : SOAPによるサービスの呼び出し、応答のインタフェースなどを定義する言語。

UDDI (Universal Description, Discovery, and Integration) : WSDLで記述されたサービスの情報を登録、検索可能とする技術（UDDI自体もWebサービスとして提供されており、SOAPによって呼び出し、応答を行う）。

これらに加え、多数のサービス間の複雑な連携を設計するための技術仕様として、BPEL (Business Process Execution Language) やBPMN (Business Process Modeling Notation) が登場している。また、その設計したサービス連携を実行するための技術として、ESB (Enterprise Service Bus) が登場している。

BPELは、業務処理のプロセス（サービスを連携する順序やルール）を記述する言語である（これもXMLを使用している）。サービスの連携について記述すると同時に、個々のサービスのインタフェースを記述したWSDL形式のデータも指定する。BPELとWSDLによって、サービス連携の記述と個々のサービスとを分離させた上での、柔軟で容易な疎結合が可能となる（とされている）。BPEL形式の記述に従ってサービスの連携を実行するソフトウェアはBPELエンジンと呼ばれる。

BPMNは、業務処理のプロセス（サービスを連携する順序やルール）を図として記述するための可視化表記法である。BPMNを用いて作成した図は、BPEL形式の記述へ変換することが可能である。そのような変換を自動化するツールも提供されている。

ESBは、サービス間をつなぐ中継バスとしての役目を担う技術あるいはその実装製品を指す言葉である。サービスを1対1で直接P2P接続する場合と比べて、ESBを使用すれば、多数のサービス間接続を集中して管理、監視できるようになる。複数のESBを接続して連携させ、ルーティングやプロトコル変換などの役割を持たせることも可能である。

BPMN、BPEL、ESBや、それらの基礎となるWebサービスを完全に活用できている状態においては、BPMN形式のビジュアルな図を描くだけでシステム連携が可能となり、その図を描き換えるだけで業務処理の変更に対応できる（とされている）。

なお、個々のサービス（ソフトウェア）の実装においては、任意の技術を使用可能である。ただし、WebサービスあるいはSOAの製品実装においては、Java あるいは .NET の使用が先行している。既存の技術（たとえばメインフレーム系の技術）を使用しているシステムをサービスとして活用する場合、そのインタフェースの作成にはJavaなどを使用するのが通常である（こうした手法はレガシーラッピングと呼ばれる）。
代表的な関連ソフトウエア

liferay（オープンソース ポータルフレームワーク）

⇒IBM Websphere

⇒SOPERA ASF Community Edition / Enterprise Edition

⇒SoftwareAG webMethods

⇒富士通 GLOVIA smart

⇒フィオラノ ソフトウェア Fiorano SOA Platform

⇒レッドハット JBoss Enterprise SOA Platform