ソフトウェア工学 において、サービス指向アーキテクチャ（SOA ）は、モノリシック設計ではなく個別のサービスに重点を置いたアーキテクチャスタイルです。[1] SOAはシステム統合に適しています。[2]その結果、ソフトウェア設計の分野でも適用され、ネットワーク上の通信プロトコルを介して、アプリケーションコンポーネントが他のコンポーネントにサービスを提供します。サービスとは、クレジットカードの明細書をオンラインで取得するなど、リモートからアクセスでき、独立して操作および更新できる個別の機能単位です。SOAは、ベンダー、製品、テクノロジーに依存しないことも意図しています。[3]

サービス指向とは、サービスとサービスに基づく開発、そしてサービスの成果について考える方法です。[1]

SOAの多くの定義の1つによれば、サービスには4つの特性がある。[4]

  1. 指定された結果を伴う繰り返し可能なビジネス アクティビティを論理的に表します。
  2. それは自己完結的です。
  3. これは消費者にとってブラックボックスであり、消費者がサービスの内部の仕組みを意識する必要はありません。
  4. 他のサービスから構成される場合もある。[5]

大規模なソフトウェアアプリケーションの機能を提供するために、異なるサービスをサービスメッシュとして連携させることができます[6] 。これはSOAとモジュール型プログラミングの原則を共有しています。サービス指向アーキテクチャは、分散され、個別に保守・展開されているソフトウェアコンポーネントを統合します。これは、ネットワーク、特にIPネットワークを介したコンポーネントの通信と連携を促進する技術と標準によって実現されます。

SOAは、ソフトウェアの実装と保守を簡素化することを目的とした、コンピュータプログラムの異なる部分間のインターフェースまたは通信プロトコルであるAPI（アプリケーション・プログラミング・インターフェース）の概念に関連しています。APIはサービスであり、SOAはそのサービスが動作できるようにするアーキテクチャと考えることができます。

サービス指向アーキテクチャとサービスベースアーキテクチャは異なるアーキテクチャスタイルであるため、混同しないように注意してください。[7]

概要

SOAでは、サービスは記述メタデータを用いてメッセージの受け渡し方法と解析方法を記述するプロトコルを使用します。このメタデータは、サービスの機能特性とサービス品質特性の両方を記述します。サービス指向アーキテクチャ（SOA）は、ユーザーが既存のサービスのみをアドホックに組み合わせることで、大規模な機能群を統合したアプリケーションを構築できるようにすることを目的としています。サービスは、ブラックボックスとして機能する基盤となる複雑さを抽象化し、リクエスタに対してシンプルなインターフェースを提供します。さらに、ユーザーはこれらの独立したサービスに、その内部実装を意識することなくアクセスできます。[8]

概念の定義

関連する流行語であるサービス指向は、サービス間の疎結合を促進します。SOAは機能を明確な単位、つまりサービスに分割し[9]、開発者はネットワーク経由でアクセスできるようにすることで、ユーザーがアプリケーションの開発においてそれらを組み合わせて再利用できるようにします。これらのサービスとそれに対応する消費者は、明確に定義された共有形式でデータを渡すか、2つ以上のサービス間のアクティビティを調整することで相互に通信します[10] 。

SOAは、分散コンピューティング[9] [11]やモジュールプログラミングという古い概念から、SOAを経てマッシュアップ、SaaS、クラウドコンピューティング（SOAの子孫と考える人もいる）の実践に至るまでの連続体の一部と見ることができます。[12]

原則

サービス指向アーキテクチャの正確な構成に関する業界標準は存在しませんが、多くの業界関係者が独自の原則を公開しています。これらの原則には、次のようなものがあります[13] [14] [15] 。

標準化されたサービス契約[16]
サービスは、特定のサービス セット内の1 つ以上のサービス記述ドキュメントによって集合的に定義される標準通信契約に準拠します。
サービス参照の自律性（疎結合の一側面）
サービス間の関係は、サービスが自身の存在を認識するだけのレベルまで最小限に抑えられます。
サービスロケーションの透明性（疎結合の一側面）
サービスは、それがどこに存在するかに関係なく、ネットワーク内のどこからでも呼び出すことができます。
サービス寿命
サービスは長期にわたって利用されることを想定して設計されるべきです。可能な限り、新機能を必要としないユーザーは、サービスの変更を強いられるべきではありません。今日サービスを利用すれば、明日も同じサービスを利用できるはずです。
サービスの抽象化
サービスはブラックボックスとして機能し、その内部ロジックは消費者から隠されています。
サービスの自律性
サービスは独立しており、デザイン時と実行時の観点から、カプセル化する機能を制御します。
サービスのステートレス性
サービスはステートレスです。つまり、要求された値を返すか例外を発行し、リソースの使用を最小限に抑えます。
サービスの粒度
サービスの規模と範囲が適切であることを保証するための原則。サービスがユーザーに提供する機能は、関連性のあるものでなければなりません。
サービスの正規化
サービスは冗長性を最小限に抑えるために分解または統合（正規化）されます。ただし、パフォーマンスの最適化、アクセス、集約が必要な場合は、この処理が行われない場合もあります。[17]
サービスの構成可能性
サービスを使用して他のサービスを構成することができます。
サービス検出
サービスには通信メタデータが補足されており、これによってサービスを効果的に検出および解釈できるようになります。
サービスの再利用性
コードの再利用を促進するために、ロジックはさまざまなサービスに分割されています。
サービスのカプセル化
当初 SOA で計画されていなかった多くのサービスが、カプセル化されるか、SOA の一部になる可能性があります。

パターン

各 SOA ビルディング ブロックは、次の 3 つの役割のいずれかを果たすことができます。

サービスプロバイダー
ウェブサービスを作成し、その情報をサービスレジストリに提供します。各プロバイダーは、どのサービスを公開するか、セキュリティと可用性のどちらを重視するか、サービスをいくらで提供するかなど、様々な「方法」と「理由」について議論します。プロバイダーはまた、特定のブローカーサービス[18]において、サービスをどのカテゴリーに分類するか、また、サービスを利用するためにどのような取引先契約が必要かを決定する必要があります。
サービスブローカー、サービスレジストリ、またはサービスリポジトリ
主な機能は、Webサービスに関する情報を潜在的なリクエスターに提供することです。ブローカーを実装する人が、そのスコープを決定します。パブリックブローカーはどこからでも利用可能ですが、プライベートブローカーは限られたユーザーのみ利用可能です。UDDIは、 Webサービスの検出機能を提供するための初期の試みでしたが、現在では積極的にサポートされていません。
サービス依頼者/消費者
ブローカーは、様々な検索操作を用いてブローカーレジストリ内のエントリを検索し、サービスプロバイダーにバインドして、そのWebサービスのいずれかを呼び出します。サービス利用者は、必要なサービスをブローカーに取り込み、それぞれのサービスにバインドして使用する必要があります。サービスが複数のサービスを提供している場合、複数のサービスにアクセスできます。

サービス消費者とサービス提供者の関係は、標準化されたサービス契約によって規定されており、[19]はビジネス部分、機能部分、技術部分から構成されています。

サービス構成パターンには、コレオグラフィーとオーケストレーションという2つの広範な高レベルアーキテクチャスタイルがあります。特定のアーキテクチャスタイルに縛られない低レベルのエンタープライズ統合パターンは、SOA設計において依然として関連性があり、適切です。[20] [21] [22]

実装アプローチ

サービス指向アーキテクチャは、ウェブサービスまたはマイクロサービスによって実装できます。[23]これは、機能的な構成要素を、プラットフォームやプログラミング言語に依存しない標準的なインターネットプロトコルを介してアクセスできるようにするためです。これらのサービスは、新しいアプリケーションを表す場合もあれば、既存のレガシーシステムをネットワーク対応にするためのラッパーとなる場合もあります。[24]

SOAの実装では、Webサービス標準が一般的に用いられます。SOAPはその一例であり、2003年にW3C [25] (World Wide Web Consortium)がバージョン1.2を勧告して以来、業界で広く受け入れられています。これらの標準（ Webサービス仕様とも呼ばれます）は、相互運用性の向上と、ベンダー独自のソフトウェアへのロックインからの保護も提供します。また、 Jini、CORBA、Internet Communications Engine、REST、gRPCなど、他のサービスベースの技術を用いてSOAを実装することも可能です。

アーキテクチャは特定のテクノロジーとは独立して動作できるため、次のような幅広いテクノロジーを使用して実装できます。

実装では、これらのプロトコルを1つ以上使用できます。例えば、SOAコンセプトに準拠したプロセス間で、定義済みのインターフェース仕様に従ってデータ通信を行うためにファイルシステムメカニズムを使用する場合があります。重要なのは、定義されたインターフェースを持つ独立したサービスです。これらのサービスは、呼び出し元のアプリケーションを事前に認識する必要もなく、アプリケーションもサービスが実際にどのようにタスクを実行するかを知る必要もなく、標準的な方法でタスクを実行するために呼び出されます。SOAは、疎結合かつ相互運用可能なサービスを組み合わせて構築されたアプリケーションの開発を可能にします。

これらのサービスは、基盤となるプラットフォームやプログラミング言語に依存しない正式な定義（または契約、例えばWSDL）に基づいて相互運用されます。インターフェース定義は、言語固有のサービスの実装を隠蔽します。そのため、SOAベースのシステムは、開発技術やプラットフォーム（Java、.NETなど）に依存せずに機能します。例えば、.NETプラットフォーム上で動作するC#で記述されたサービスと、Java EEプラットフォーム上で動作するJavaで記述されたサービスは、どちらも共通の複合アプリケーション（またはクライアント）で利用できます。どちらのプラットフォーム上で動作するアプリケーションも、再利用を容易にするWebサービスとして、もう一方のプラットフォーム上で動作するサービスを利用することができます。また、管理環境は、COBOLレガシーシステムをラップし、ソフトウェアサービスとして提供することもできます。[ 26]

BPELなどの高水準プログラミング言語や、 WS-CDL、WS-Coordinationなどの仕様は、きめ細かいサービスからより粗い粒度のビジネス サービスへのオーケストレーションを定義およびサポートする方法を提供することで、サービス概念を拡張します。アーキテクトは、これを複合アプリケーションやポータルに実装されたワークフローやビジネス プロセスに組み込むことができます。

サービス指向モデリングは、SOA実践者がサービス指向資産の概念化、分析、設計、構築を行うための様々な分野を規定するSOAフレームワークです。サービス指向モデリングフレームワーク（SOMF）は、モデリング言語と、サービス指向モデリングアプローチの成功に貢献する様々な要素を示す作業構造（「マップ」）を提供します。これは、サービス開発計画における「すべきこと」を特定する主要要素を示しています。このモデルにより、実践者はプロジェクト計画を策定し、サービス指向イニシアチブのマイルストーンを特定することができます。また、SOMFは、ビジネス組織とIT組織の連携を図るための共通のモデリング表記法も提供します。

SOAの要素、Dirk Krafzig、Karl Banke、Dirk Slama著[27]
SOAメタモデル、The Linthicum Group、2007

組織的なメリット

一部のエンタープライズアーキテクトは、SOAによって企業が変化する市場状況に迅速かつコスト効率よく対応できるようになると考えています。[28]このスタイルのアーキテクチャは、ミクロレベル（クラスレベル）ではなく、マクロレベル（サービスレベル）での再利用を促進します。また、既存のIT（レガシー）資産との相互接続と利用を簡素化することもできます。

SOAの考え方は、組織が問題を包括的に捉えられるというものです。企業はより包括的なコントロールが可能になります。理論的には、多数の開発者が自分の好きなツールセットを使うことはなくなり、むしろ企業内で定められた標準に従ってコーディングするようになります。また、ビジネス指向のインフラストラクチャをカプセル化した企業全体のSOAを開発することも可能です。SOAは、自動車の運転者に効率性を提供する高速道路システムに例えられることもあります。つまり、誰もが自動車を持っているにもかかわらず、高速道路がなければ、迅速かつ効率的に目的地に到着しようとする試みは、制限され、混乱をきたすということです。IBMのWebサービス担当副社長であるマイケル・リーボウ氏は、SOAは「高速道路を構築する」と述べています。[29]

ある意味、SOAは革命というよりも、アーキテクチャの進化と言えるかもしれません。SOAは、従来のソフトウェアアーキテクチャのベストプラクティスを多く取り入れています。例えば通信システムでは、ネットワーク内の他の機器と通信するために真に静的なバインディングを使用するソリューションの開発はほとんど行われていません。SOAアプローチを採用することで、このようなシステムは、明確に定義され、相互運用性の高いインターフェースの重要性を重視する立場を確立できます。SOAの前身としては、コンポーネントベースのソフトウェアエンジニアリングや、 CORBAに代表されるリモートオブジェクトのオブジェクト指向分析設計（OOAD）などがあります。

サービスは、正式に定義されたインターフェースを介してのみ利用可能な、独立した機能単位から構成されます。サービスは、容易に作成・改良できる一種の「ナノ企業」である場合もあります。また、下位のサービスが協調して機能する「巨大企業」である場合もあります。

サービスの実装を大規模なプロジェクトとは別のプロジェクトとして扱う理由は次のとおりです。

  1. 分離は、組織内で一般的に行われている大規模で進行の遅いプロジェクトとは独立して、迅速かつ独立してサービスを提供できるという概念をビジネスに浸透させます。ビジネスは、サービスを呼び出すシステムと簡素化されたユーザーインターフェースを理解し始めます。これはアジリティ（俊敏性）を促進します。つまり、ビジネスイノベーションを促進し、市場投入までの時間を短縮するのです。[30]
  2. 分離は、サービスとそれを利用しているプロジェクトの分離を促進します。これは、サービスがその利用者を意識することなく設計される限りにおいて、優れた設計を促進します。
  3. サービスのドキュメントとテスト成果物は、より大きなプロジェクトの詳細の中に埋め込まれません。これは、後でサービスを再利用する必要がある場合に重要です。

SOAは間接的にテストを簡素化することを約束します。サービスは自律的かつステートレスで、インターフェースが完全に文書化されており、実装の横断的な関心事とは切り離されています。組織が適切に定義されたテストデータを保有している場合、サービスの構築時にテストデータに反応する対応するスタブが構築されます。また、サービスに対して、回帰テスト、スクリプト、データ、レスポンスの完全なセットも取得されます。サービスは、呼び出すサービスに対応する既存のスタブを使用して、「ブラックボックス」としてテストできます。プリミティブサービスとスコープ外サービスをスタブとし、メッシュの残りの部分をフルサービスのテストデプロイメントとしてテスト環境を構築できます。各インターフェースは、独自の回帰テストドキュメントによって完全に文書化されているため、テストサービスにおける問題の特定が容易になります。テストは、テストサービスがドキュメントに従って動作することを検証するだけに進化し、環境内のすべてのサービスのドキュメントとテストケースのギャップを見つけます。冪等サービスのデータ状態の管理だけが複雑な点です。

サービスを実際に役立つレベルまで文書化する上で、例は役立つ場合があります。Java Community Process内のいくつかのAPIのドキュメントは良い例です。これらは網羅的であるため、スタッフは通常、重要なサブセットのみを使用します。JSR -89内の「ossjsa.pdf」ファイルは、そのようなファイルの例として挙げられます。[31]

批判

SOAはWebサービスと混同されてきましたが[32]、WebサービスはSOAスタイルを構成するパターンを実装するための選択肢の1つにすぎません。ネイティブ形式またはバイナリ形式のリモートプロシージャコール（RPC）がない場合、アプリケーションの実行速度が低下し、より多くの処理能力が必要になり、コストが増大する可能性があります。ほとんどの実装ではこれらのオーバーヘッドが発生しますが、SOAはリモートプロシージャコールやXMLまたはJSONによる変換に依存しない技術（Java Business Integration（JBI）、Windows Communication Foundation（WCF）、データ配信サービス（DDS）など）を使用して実装できます。同時に、新興のオープンソースXML解析技術（VTD-XMLなど）とさまざまなXML互換バイナリ形式は、SOAのパフォーマンスを大幅に向上させると期待されています。[33] [34] [35]

ステートフルサービスでは、コンシューマとプロバイダの両方が、コンシューマ固有のコンテキストを共有する必要があります。このコンテキストは、プロバイダとコンシューマ間で交換されるメッセージに含まれるか、またはメッセージによって参照されます。この制約には、サービスプロバイダが各コンシューマの共有コンテキストを保持する必要がある場合、サービスプロバイダ全体のスケーラビリティが低下する可能性があるという欠点があります。また、サービスプロバイダとコンシューマ間の結合度が高まり、サービスプロバイダの切り替えが困難になります。 [36]結局のところ、SOAサービスは、それが表すアプリケーションによって依然として制約が大きすぎると感じる批評家もいます。[37]

サービス指向アーキテクチャ（SOA）が直面する主要な課題は、メタデータの管理です。SOAに基づく環境には、タスクを実行するために相互に通信する多くのサービスが含まれます。設計上、複数のサービスが連携して動作することになるため、アプリケーションは数百万ものメッセージを生成する可能性があります。さらに、サービスが異なる組織や競合企業に属している場合もあり、大きな信頼の問題が生じます。そこで、SOAガバナンスが重要になります。[38]

SOAが直面するもう一つの大きな問題は、統一されたテストフレームワークの欠如です。サービス指向アーキテクチャにおけるこれらのサービスをテストするために必要な機能を提供するツールが存在しません。主な問題の原因は以下のとおりです。[39]

  • ソリューションの異質性と複雑性。
  • 自律サービスの統合により、テストの組み合わせが膨大になります。
  • さまざまな競合ベンダーのサービスを含める。
  • 新しい機能やサービスの提供により、プラットフォームは継続的に変化しています。

拡張機能とバリアント

イベント駆動型アーキテクチャ

アプリケーションプログラミングインターフェース

アプリケーション プログラミング インターフェイス (API) は、開発者が Web アプリケーションと対話できるフレームワークです。

ウェブ2.0

ティム・オライリーは、急速に成長しているWebベースのアプリケーション群を表現するために「 Web 2.0 」という用語を作り出した。 [40]広く取り上げられているトピックの一つに、Web 2.0とサービス指向アーキテクチャの関係がある。[どれ？ ]

SOAとは、アプリケーションロジックを統一的に定義されたインターフェースを持つサービスにカプセル化し、それらを検出メカニズムを通じて公開するという理念です。複雑さの隠蔽と再利用、そしてサービスの疎結合という概念は、研究者にSOAとWeb 2.0という2つの理念、そしてそれぞれの応用における類似点を深く掘り下げるきっかけを与えてきました。Web 2.0とSOAは大きく異なる要素を持っているため、「並列の理念」とはみなせないと主張する人もいますが、2つの概念は互いに補完し合い、Web 2.0をグローバルなSOAと見なす人もいます。[41]

Web 2.0とSOAの理念はそれぞれ異なるユーザーニーズに応えるため、設計や実際のアプリケーションで使用される技術にも違いが見られます。しかし、2008年時点では、ユースケースによってWeb 2.0とSOAの技術と原則を組み合わせる可能性が実証されています。[41]

マイクロサービス

マイクロサービスは、分散型ソフトウェアシステムの構築に使用されるサービス指向アーキテクチャの現代的な解釈です。マイクロサービスアーキテクチャ[42]におけるサービスは、ネットワークを介して相互に通信し、目標を達成するプロセスです。これらのサービスは、技術に依存しないプロトコル[43]を使用します。これにより、言語やフレームワークの選択がカプセル化され、サービス内部での選択が考慮されるようになります。マイクロサービスは、SOAの新しい実現・実装アプローチであり、2014年以降（DevOpsの導入後）に普及し、継続的デプロイメントなどのアジャイルプラクティスも重視されています。[44]

マイクロサービスには、一般的に合意された単一の定義はありません。文献には、以下の特徴と原則が記載されています。

  • きめ細かなインターフェース（独立して展開可能なサービスへ）
  • ビジネス駆動開発（例：ドメイン駆動設計）
  • 理想的なクラウドアプリケーションアーキテクチャ
  • 多言語プログラミングと永続性、
  • 軽量コンテナの展開、
  • 分散型継続的デリバリー、そして
  • 総合的なサービス監視を備えた DevOps。

インタラクティブアプリケーションのためのサービス指向アーキテクチャ

リアルタイムの応答時間を必要とするインタラクティブアプリケーション、例えば低遅延のインタラクティブ3Dアプリケーションでは、この種のアプリケーション特有のニーズに対応する特定のサービス指向アーキテクチャが採用されています。これには、例えば低遅延に最適化された分散コンピューティングと通信、そしてリソースとインスタンスの管理などが含まれます。[45] [46] [47]

参照

参考文献

  1. ^ ab 「SOAソースブック - SOAとは？」collaboration.opengroup.org . 2021年3月30日閲覧。
  2. ^ ソフトウェアアーキテクチャの基礎：エンジニアリングアプローチ. O'Reilly Media. 2020. ISBN 978-1492043454。
  3. ^ 「第1章 サービス指向アーキテクチャ（SOA）」。msdn.microsoft.com。2017年7月7日時点のオリジナルよりアーカイブ。 2016年9月21日閲覧。
  4. ^ 「サービス指向アーキテクチャ標準 - The Open Group」。www.opengroup.org。
  5. ^ 「SOAとは？」www.opengroup.org。2016年8月19日時点のオリジナルよりアーカイブ。2016年9月21日閲覧。
  6. ^ Velte, Anthony T. (2010).クラウドコンピューティング：実践的アプローチ. McGraw Hill. ISBN 978-0-07-162694-1。
  7. ^ ソフトウェアアーキテクチャの基礎：エンジニアリングアプローチ. O'Reilly Media. 2020. ISBN 978-1492043454。
  8. ^ 「サービス指向アーキテクチャへの移行 パート1」。2008年12月9日。2008年12月9日時点のオリジナルよりアーカイブ。 2016年9月21日閲覧。{{cite web}}: CS1 maint: bot: 元のURLステータス不明（リンク）
  9. ^ Michael Bell (2008). 「サービス指向モデリング入門」.サービス指向モデリング：サービス分析、設計、アーキテクチャ. Wiley & Sons. p. 3. ISBN 978-0-470-14111-3。
  10. ^ Michael Bell (2010). SOAモデリングパターン：サービス指向の検出と分析. Wiley & Sons. p. 390. ISBN 978-0-470-48197-4。
  11. ^ Thomas Erl (2005年6月).「原則について」 . Serviceorientation.org
  12. ^ 「Application Platform Strategies Blog: SOA is Dead; Long Live Services」. Apsblog.burtongroup.com. 2009年1月5日. 2009年1月15日時点のオリジナルよりアーカイブ。2012年8月13日閲覧。
  13. ^ Yvonne Balzer「SOAプロジェクト計画の改善」IBM、2004年7月16日
  14. ^ Microsoft Windows Communication Foundation チーム (2012). 「サービス指向設計の原則」. msdn.microsoft.com . 2012年9月3日閲覧。
  15. ^ SOA Systems Inc.の トーマス・エルルによる8つの具体的なサービス指向の原則
  16. ^ 「4.4 Webサービス契約技術の使用ガイドライン - Webサービス契約の解剖学」InformIT 2021年6月11日. 2021年9月9日閲覧。
  17. ^ Tony Shan (2004). 「サービス指向eBankingプラットフォームの構築」IEEE International Conference on Services Computing, 2004. (SCC 2004). Proceedings. 2004. pp.  237– 244. doi :10.1109/SCC.2004.1358011. ISBN 978-0-7695-2225-8. S2CID  13156128。2004
  18. ^ Duan, Yucong; Narendra, Nanjangud; Du, Wencai; Wang, Yongzhi; Zhou, Nianjun (2014). 「インターフェースの観点から見たクラウドサービスブローカリングの考察」2014 IEEE International Conference on Web Services . IEEE . pp.  329– 336. doi :10.1109/ICWS.2014.55. ISBN 978-1-4799-5054-6. S2CID  17957063。
  19. ^ Duan, Yucong (2012). 「サービス契約に関する調査」. 2012 第13回ACIS国際ソフトウェア工学・人工知能・ネットワーキング・並列/分散コンピューティング会議. IEEE . pp.  805– 810. doi :10.1109/SNPD.2012.22. ISBN 978-1-4673-2120-4. S2CID  1837914。
  20. ^ Olaf Zimmermann, Cesare Pautasso, Gregor Hohpe, Bobby Woolf (2016). 「エンタープライズ統合パターンの10年」. IEEEソフトウェア. 33 (1): 13– 19. doi : 10.1109/MS.2016.11 .{{cite journal}}: CS1 maint: 複数の名前: 著者リスト (リンク)
  21. ^ Rotem-Gal-Oz, Arnon (2012). SOAパターン. Manning Publications. ISBN 978-1933988269。
  22. ^ Julisch, Klaus; Suter, Christophe; Woitalla, Thomas; Zimmermann, Olaf (2011). 「設計によるコンプライアンス ― 監査人とITアーキテクトの間の溝を埋める」(PDF) . Computers & Security . 30 ( 6–7 ): 410– 426. CiteSeerX 10.1.1.390.3652 . doi :10.1016/j.cose.2011.03.005. 
  23. ^ Brandner, M.、Craes, M.、Oellermann, F.、Zimmermann, O.、金融業界における運用における Web サービス指向アーキテクチャ、Informatik-Spektrum 02/2004、Springer-Verlag、2004
  24. ^ "www.ibm.com". IBM . 2016年9月10日閲覧。
  25. ^ 「SOAP バージョン 1.2 の公開について (W3C)」. W3.org。 2003 年 6 月 24 日。2012 年8 月 13 日に取得。
  26. ^ 沖島 春昼 (2006). 「COBOL資産を活用したシステムアーキテクチャの事例研究」(PDF) .
  27. ^ エンタープライズSOA . プレンティスホール、2005
  28. ^ Christopher Koch A New Blueprint For The Enterprise Archived January 16, 2009, at the Wayback Machine、CIO Magazine、2005年3月1日
  29. ^ エリザベス・ミラード（2005年1月）「より良いプロセスの構築」『コンピュータユーザー』20ページ。
  30. ^ Brayan Zimmerli (2009年11月11日) SOAのビジネス上の利点、スイス北西部応用科学大学、ビジネススクール
  31. ^ “JSR-000089 OSS サービスアクティベーションAPI仕様1.0 最終リリース”. 2011年7月26日. 2011年7月26日時点のオリジナルよりアーカイブ。2024年5月18日閲覧。
  32. ^ Joe McKendrick. 「Bray氏：SOAは複雑すぎる。『ベンダーの戯言』に過ぎない」ZDNet.
  33. ^ Jimmy Zhang (2008年2月20日)「VTD-XMLによるXMLドキュメントのインデックス作成」Wayback Machineに2008年7月4日アーカイブ。XML Journal。
  34. ^ Jimmy Zhang (2008年8月5日)「i-Technologyの視点：バイナリXMLのパフォーマンスの悩み」Wayback Machineで2020年1月9日にアーカイブ。Microservices Journal。
  35. ^ Jimmy Zhang (2008 年 1 月 9 日)「Ximple による XML コンテンツの操作」2017 年 7 月 30 日アーカイブ、Wayback Machine。devx.com 。
  36. ^ 「SOAが持続可能なソフトウェアを実現できない理由」jpmorgenthal.com、2009年6月19日。 2009年6月27日閲覧。
  37. ^ 「SOAサービスは依然として、それが表すアプリケーションによって制約されすぎている」ZDNet 2009年6月27日2009年6月27日閲覧。
  38. ^ “Governance Layer”. www.opengroup.org . 2016年6月4日時点のオリジナルよりアーカイブ。 2016年9月22日閲覧。
  39. ^ 「サービス指向アーキテクチャを効率的にテストする方法 | WSO2 Inc」wso2.com . 2016年9月22日閲覧。
  40. ^ 「Web 2.0とは何か」ティム・オライリー、2005年9月30日。 2008年6月10日閲覧。
  41. ^ Christoph Schroth、Till Janner (2007). 「Web 2.0とSOA：サービスのインターネットを実現する統合概念」. IT Professional . 9 (3): 36– 41. Bibcode :2007ITPro...9c..36S. doi :10.1109/MITP.2007.60. S2CID  2859262. 2013年12月3日時点のオリジナルよりアーカイブ。 2008年2月23日閲覧。
  42. ^ ドラゴニ、ニコラ;ジャロレンツォ、サヴェリオ。アルベルト・リュッホ・ラフェンテ;マザラ、マヌエル。モンテジ、ファブリツィオ。ムスタフィン、ルスラン。サフィナ、ラリサ（2016）。 「マイクロサービス: 昨日、今日、そして明日」。arXiv : 1606.04036v1 [cs.SE]。
  43. ^ James LewisとMartin Fowler。「マイクロサービス」。
  44. ^ Balalaie, A.; Heydarnoori, A.; Jamshidi, P. (2016年5月1日). 「マイクロサービスアーキテクチャによるDevOpsの実現：クラウドネイティブアーキテクチャへの移行」(PDF) . IEEE Software . 33 (3): 42– 52. Bibcode :2016ISoft..33c..42B. doi :10.1109/MS.2016.64. hdl : 10044/1/40557 . ISSN  0740-7459. S2CID  18802650.
  45. ^ Frank Glinka、Allaithy Raed (2009). 「高度にインタラクティブな分散アプリケーションのためのサービス指向インターフェース」.ヨーロッパ並列処理会議. コンピュータサイエンス講義ノート. 第6043巻. pp.  266– 277. doi :10.1007/978-3-642-14122-5_31. ISBN 978-3-642-14121-8. 2021年2月9日閲覧。
  46. ^ Dieter Hildebrandt、Jan Klimke (2011). 「シンクライアント上での大規模3D都市モデルのサービス指向インタラクティブ3D可視化」COM.Geo '11: 第2回国際地理空間研究・応用コンピューティング会議議事録. p. 1. doi :10.1145/1999320.1999326. ISBN 9781450306812. S2CID  53246415 . 2021年2月9日閲覧.
  47. ^ Mahy Aly; Michael Franke (2016). 「最適化されたリソース共有によって実現されるサービス指向インタラクティブメディア（SOIM）エンジン」. 2016 IEEE Symposium on Service-Oriented System Engineering (SOSE). pp.  231– 237. doi :10.1109/SOSE.2016.47. hdl : 1854/LU-7215326 . ISBN 978-1-5090-2253-3. S2CID  9511734 . 2021年2月9日閲覧.
  • マウロ, クリスチャン; ライマイスター, ヤン・マルコ; クルクマー, ヘルムート (2010年1月). 「サービス指向デバイス統合 - SOA設計パターンの分析」(PDF) . 2010年第43回ハワイ国際システム科学会議. pp.  1– 10. doi :10.1109/HICSS.2010.336. ISBN 978-1-4244-5509-6. S2CID 457705. 2022年1月24日時点の オリジナル（PDF）からアーカイブ。 2021年9月21日閲覧。
ウィキメディア コモンズには、サービス指向アーキテクチャに関連するメディアがあります。
この記事を聞く（54分）
音声ウィキペディアアイコン
この音声ファイルは、2011 年 10 月 27 日付の記事の改訂版から作成されたもので、その後の編集は反映されていません。 （2011年10月27日）
（音声ヘルプ ·その他の音声記事）