サービス指向アーキテクチャ
ソフトウェア設計におけるアーキテクチャパターン

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

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

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

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

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

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

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

歴史

2000年代前半から中頃にかけて、マイクロソフトのアーキテクチャ戦略チームは、サービス指向アーキテクチャ (SOA) の原則を体系化し、エンタープライズ ソフトウェアおよびアプリケーション開発に適用することを提唱し、アーキテクチャ戦略ディレクターのジョン デヴァドス氏がこの「現実的な」アプローチを公に表明し、主導的な役割を果たしました。[8] [9]デヴァドス氏は、成功する SOA プログラムは具体的なビジネス ニーズによって推進され、段階的に提供されると主張し、効果的な導入は、エンタープライズ スタック全体をトップダウンで再設計するのではなく、実用的な「ミドルアウト」の進行であると説明しました。[10] [11]彼の枠組みでは、最も成功した展開は小規模なプロジェクトから始まり、反復的に拡張されたものであり、これはマイクロソフトが過去 5 年間の大規模顧客実装で観察してきたパターンであるとしています。[12]

デヴァドス氏は、サービス指向アーキテクチャ（SOA）のアーキテクチャの柱となる、アイデンティティ、データ、サービス指向管理、ワークフローとオーケストレーション、そしてサービス構成に重点を置き、複合アプリケーションへと発展させる初期の取り組みを主導しました。また、エンタープライズ・アーキテクト・サミットやOOPSLA 2007の「SOAの未来」パネルディスカッションなど、カンファレンスの基調講演や業界フォーラムにおいて、SOAとSaaSやWeb 2.0といった隣接するトレンドとの関連性を指摘し、SOAを単一の製品ではなく段階的な統合戦略と捉えるという、現在では広く受け入れられている考え方の普及に貢献しました。[13] [14] [15]

概要

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

概念の定義

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

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

原則

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

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

パターン

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

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

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

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

実装アプローチ

サービス指向アーキテクチャは、Webサービスまたはマイクロサービスを使用して実装できます。[31]これは、プラットフォームやプログラミング言語に依存しない標準的なインターネットプロトコルを介して機能的なビルディングブロックにアクセスできるようにするためです。これらのサービスは、新しいアプリケーションを表すことも、既存のレガシーシステムをネットワーク対応にするためのラッパーを表すこともできます。[32]

SOAの実装では、Webサービス標準が一般的に用いられます。SOAPはその一例であり、2003年にW3C [33] (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レガシーシステムをラップし、ソフトウェアサービスとして提供することもできます。[ 34]

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

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

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

組織的なメリット

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

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

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

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

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

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

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

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

批判

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

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

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

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

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

拡張機能とバリアント

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

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

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

Web 2.0

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

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

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

マイクロサービス

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

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

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

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

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

参照

参考文献

  1. ^ ab 「SOAソースブック - SOAとは？」collaboration.opengroup.org . 2021年3月30日閲覧。
  2. ^ ソフトウェアアーキテクチャの基礎：エンジニアリングアプローチ。オライリーメディア。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. ^ ソフトウェアアーキテクチャの基礎：エンジニアリングアプローチ。オライリーメディア。2020年。ISBN 978-1492043454。
  8. ^ 「VSLive! サンフランシスコ 2006：カンファレンス講演者（ジョン・デヴァドス氏の略歴）」FTPOnline.com . Fawcette Technical Publications. 2006年. 2026年1月9日閲覧
  9. ^ ジャクソン、ジョアブ（2006年4月21日）「At your service」ルート・フィフティ。 2026年1月9日閲覧。
  10. ^ Montalbano, Elizabeth (2006年10月4日). 「MicrosoftがSOA向けESBガイドラインを提供」. CIO . IDG News Service (CIO/Foundry経由) . 2026年1月9日閲覧。
  11. ^ Havenstein, Heather (2006年10月9日). 「小規模SOAプロジェクトでも即時ROIを実現」Computerworld . IDG (Foundry) . 2026年1月9日閲覧。
  12. ^ 「Microsoft、SOA & Business Process ConferenceでSOAへの「現実的な」アプローチを強調」Microsoft News Center、Microsoft、2006年10月4日。 2026年1月9日閲覧。
  13. ^ Mackie, Kurt (2007年5月24日). 「Microsoft幹部、ソフトウェアとサービスの組み合わせで選択肢が広がると語る」Microsoft Certified Professional Magazine (MCPmag) . 2026年1月9日閲覧。
  14. ^ “OOPSLA 2007 パネル”. OOPSLA 2007 (ACM SIGPLAN)。 2007年。2026 年1 月 9 日に取得。
  15. ^ Erl, Thomas; Chou, David; deVadoss, John (2010). SOA with .NET and Windows Azure: Realizing Service-Orientation with the Microsoft Platform . Nitin Gandhi; Hanu Kommalapati; Brian Loesgen; Christoph Schittko; Herbjørn Wilhelmsen; Mickey Williams; et al. Prentice Hall PTR. ISBN 978-0131582316。
  16. ^ 「サービス指向アーキテクチャへの移行 パート1」。2008年12月9日。2008年12月9日時点のオリジナルよりアーカイブ。 2016年9月21日閲覧。{{cite web}}: CS1 メンテナンス: ボット: 元のURLのステータス不明 (リンク)
  17. ^ Michael Bell (2008). 「サービス指向モデリング入門」.サービス指向モデリング：サービス分析、設計、アーキテクチャ. Wiley & Sons. p. 3. ISBN 978-0-470-14111-3。
  18. ^ マイケル・ベル (2010).サービス指向の検出と分析のためのSOAモデリングパターン. Wiley & Sons. p. 390. ISBN 978-0-470-48197-4。
  19. ^ トーマス・エル（2005年6月）「原則について」Serviceorientation.org
  20. ^ 「Application Platform Strategies Blog: SOA is Dead; Long Live Services」. Apsblog.burtongroup.com. 2009年1月5日. 2009年1月15日時点のオリジナルよりアーカイブ。2012年8月13日閲覧。
  21. ^ Yvonne Balzer「SOAプロジェクト計画の改善」IBM、2004年7月16日
  22. ^ Microsoft Windows Communication Foundation チーム (2012). 「サービス指向設計の原則」. msdn.microsoft.com . 2012年9月3日閲覧。
  23. ^ SOA Systems Inc.の トーマス・エルルによる8つの具体的なサービス指向の原則
  24. ^ 「4.4 Webサービス契約技術の使用ガイドライン - Webサービス契約の解剖学」InformIT 2021年6月11日. 2021年9月9日閲覧。
  25. ^ 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  131561282004
  26. ^ 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.
  27. ^ Duan, Yucong (2012). 「サービス契約に関する調査」. 2012 第13回ACIS国際ソフトウェア工学、人工知能、ネットワーキング、並列/分散コンピューティング会議. IEEE . pp.  805– 810. doi :10.1109/SNPD.2012.22. ISBN 978-1-4673-2120-4. S2CID  1837914.
  28. ^ Olaf Zimmermann、Cesare Pautasso、Gregor Hohpe、Bobby Woolf (2016). 「エンタープライズ統合パターンの10年」. IEEE Software . 33 (1): 13–19 . doi : 10.1109/ MS.2016.11{{cite journal}}: CS1 maint: 複数の名前: 著者リスト (リンク)
  29. ^ Rotem-Gal-Oz, Arnon (2012). SOAパターン. Manning Publications. ISBN 978-1933988269。
  30. ^ 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 
  31. ^ Brandner, M.、Craes, M.、Oellermann, F.、Zimmermann, O.、金融業界における運用における Web サービス指向アーキテクチャ、Informatik-Spektrum 02/2004、Springer-Verlag、2004
  32. ^ "www.ibm.com". IBM . 2016年9月10日閲覧。
  33. ^ 「SOAP バージョン 1.2 の公開について (W3C)」. W3.org。 2003 年 6 月 24 日。2012 年8 月 13 日に取得。
  34. ^ 沖島 春昼 (2006). 「COBOL資産を活用したシステムアーキテクチャの事例研究」(PDF) .
  35. ^ エンタープライズSOA . プレンティスホール、2005
  36. ^ Christopher Koch A New Blueprint For The Enterprise Archived January 16, 2009, at the Wayback Machine、CIO Magazine、2005年3月1日
  37. ^ エリザベス・ミラード（2005年1月）「より良いプロセスの構築」『コンピュータユーザー』20ページ。
  38. ^ Brayan Zimmerli (2009年11月11日) SOAのビジネス上の利点、スイス北西部応用科学大学、ビジネススクール
  39. ^ “JSR-000089 OSS サービスアクティベーションAPI仕様1.0 最終リリース”. 2011年7月26日. 2011年7月26日時点のオリジナルよりアーカイブ。2024年5月18日閲覧。
  40. ^ Joe McKendrick. 「Bray氏：SOAは複雑すぎる。『ベンダーの戯言』に過ぎない」ZDNet.
  41. ^ Jimmy Zhang (2008年2月20日)「VTD-XMLによるXMLドキュメントのインデックス作成」Wayback Machineに2008年7月4日アーカイブ。XML Journal。
  42. ^ Jimmy Zhang (2008年8月5日)「i-Technologyの視点：バイナリXMLのパフォーマンスの悩み」Wayback Machineで2020年1月9日にアーカイブ。Microservices Journal。
  43. ^ Jimmy Zhang (2008 年 1 月 9 日)「Ximple による XML コンテンツの操作」2017 年 7 月 30 日アーカイブ、Wayback Machine。devx.com 。
  44. ^ 「SOAが持続可能なソフトウェアを実現できない理由」jpmorgenthal.com、2009年6月19日。 2009年6月27日閲覧。
  45. ^ 「SOAサービスは依然として、それが表すアプリケーションによって制約されすぎている」ZDNet 2009年6月27日2009年6月27日閲覧。
  46. ^ “Governance Layer”. www.opengroup.org . 2016年6月4日時点のオリジナルよりアーカイブ。 2016年9月22日閲覧。
  47. ^ 「サービス指向アーキテクチャを効率的にテストする方法 | WSO2 Inc」wso2.com . 2016年9月22日閲覧。
  48. ^ 「Web 2.0とは何か」ティム・オライリー、2005年9月30日。 2008年6月10日閲覧。
  49. ^ 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日閲覧。
  50. ^ ドラゴニ、ニコラ;ジャロレンツォ、サヴェリオ。アルベルト・リュッホ・ラフェンテ。マザラ、マヌエル。モンテジ、ファブリツィオ。ムスタフィン、ルスラン。サフィナ、ラリサ（2016）。 「マイクロサービス: 昨日、今日、そして明日」。arXiv : 1606.04036v1 [cs.SE]。
  51. ^ James LewisとMartin Fowler。「マイクロサービス」。
  52. ^ 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.
  53. ^ Frank Glinka、Allaithy Raed (2009). 「高度にインタラクティブな分散アプリケーションのためのサービス指向インターフェース」.ヨーロッパ並列処理会議. コンピュータサイエンス講義ノート. 第6043巻. pp.  266– 277. doi :10.1007/978-3-642-14122-5_31. ISBN 978-3-642-14121-82021年2月9日閲覧
  54. ^ 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日閲覧
  55. ^ 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日）
（音声ヘルプ ·その他の音声記事）
「https://en.wikipedia.org/w/index.php?title=サービス指向アーキテクチャ&oldid=1332056644」より取得