Loading article…
ソフトウェア工学 において、サービス指向アーキテクチャ( SOA ) は、モノリシック設計ではなく個別のサービスに重点を置いたアーキテクチャスタイルです。[1] SOA はシステム統合に適しています。[2]その結果、ネットワーク上の通信プロトコルを介してアプリケーションコンポーネントによって他のコンポーネントにサービスが提供されるソフトウェア設計の分野にも適用されます。サービスとは、オンラインでクレジットカードの明細書を取得するなど、リモートからアクセスでき、独立して操作および更新できる個別の機能単位です。SOA は、ベンダー、製品、テクノロジーから独立していることも意図しています。[3]
サービス指向とは、サービスとサービスベースの開発、そしてサービスの成果に関する考え方です。[1]
SOAの多くの定義の1つによれば、サービスには4つの特性がある。[4]
- 指定された結果を伴う反復可能なビジネス アクティビティを論理的に表します。
- それは自己完結的です。
- これは消費者にとってブラックボックスであり、消費者はサービスの内部の仕組みを意識する必要はありません。
- 他のサービスから構成される場合もある。[5]
さまざまなサービスをサービスメッシュとして連携させて使用することで、大規模なソフトウェアアプリケーションの機能を提供することができます。 [6]これは、SOAがモジュールプログラミングと共有する原則です。サービス指向アーキテクチャは、分散され、個別に保守および展開されたソフトウェアコンポーネントを統合します。これは、ネットワーク、特にIPネットワーク上でのコンポーネントの通信と連携を容易にするテクノロジと標準によって実現されます。
SOA は、ソフトウェアの実装と保守を簡素化することを目的とした、コンピュータ プログラムのさまざまな部分間のインターフェイスまたは通信プロトコルである API (アプリケーション プログラミング インターフェイス)の概念に関連しています。APIはサービスであり、SOA はサービスが動作できるようにするアーキテクチャであると考えられます。
サービス指向アーキテクチャとサービスベースアーキテクチャは2つの異なるアーキテクチャスタイルであるため、混同しないように注意してください。[7]
概要
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 サービスの 1 つを呼び出します。サービス コンシューマーは、必要なサービスをブローカーに取り込み、それぞれのサービスにバインドしてから使用する必要があります。サービスが複数のサービスを提供している場合は、複数のサービスにアクセスできます。
サービス消費者とサービス提供者の関係は、標準化されたサービス契約[19]によって規定されており、これにはビジネス部分、機能部分、技術部分が含まれます。
サービス構成パターンには、コレオグラフィーとオーケストレーションという2つの広範な高レベルのアーキテクチャスタイルがあります。特定のアーキテクチャスタイルに縛られない低レベルのエンタープライズ統合パターンは、SOA設計において引き続き関連性があり適格です。[20] [21] [22]
実装アプローチ
サービス指向アーキテクチャは、ウェブサービスまたはマイクロサービスで実装できます。[23]これは、プラットフォームやプログラミング言語に依存しない標準のインターネットプロトコルを介して機能ビルディングブロックにアクセスできるようにするためです。これらのサービスは、新しいアプリケーションを表すことも、既存のレガシーシステムをネットワーク対応にするためのラッパーを表すこともできます。[24]
実装者は一般的に、Webサービス標準を使用してSOAを構築します。1つの例はSOAPで、2003年にW3C [25] (World Wide Web Consortium)からバージョン1.2が推奨されて以来、業界で広く受け入れられています。これらの標準( Webサービス仕様とも呼ばれる)は、相互運用性を高め、ベンダー独自のソフトウェアへのロックインからの保護も提供します。ただし、 Jini、CORBA、インターネット通信エンジン、REST、gRPCなど、他のサービスベースのテクノロジーを使用してSOAを実装することもできます。
アーキテクチャは特定のテクノロジーに依存せずに動作できるため、次のような幅広いテクノロジーを使用して実装できます。
- WSDL とSOAPに基づくWeb サービス
- メッセージング（ActiveMQ、JMS、RabbitMQ など）
- RESTful HTTP、表現状態転送（REST）は独自の制約ベースのアーキテクチャスタイルを構成します。
- データ配信サービス(DDS)
- OPC-UA
- インターネット通信エンジン
- WCF (Microsoft の Web サービスの実装。WCF の一部)
- アパッチスリフト
- GRPC とは
- ソーサー
実装では、これらのプロトコルの 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 は企業が変化する市場状況に、より迅速かつコスト効率よく対応することを可能にすると考えています。[28]このスタイルのアーキテクチャは、ミクロレベル (クラス) ではなく、マクロレベル (サービス) での再利用を促進します。また、既存の IT (レガシー) 資産との相互接続と使用を簡素化することもできます。
SOA では、組織が問題を総合的に見ることができるという考え方です。ビジネスはより全体的な制御権を持ちます。理論的には、開発者が自分の好きなツール セットを何でも使うということはありません。むしろ、ビジネス内で設定された標準に従ってコーディングすることになります。また、ビジネス指向のインフラストラクチャをカプセル化した企業全体の SOA を開発することもできます。SOA は、自動車のドライバーに効率を提供する高速道路システムとして例えられることもあります。つまり、誰もが自動車を持っていても、高速道路がどこにもなければ、どこにでも迅速かつ効率的に到着しようとする試みは制限され、混乱するということです。IBM の Web サービス担当副社長 Michael Liebow 氏は、SOA は「高速道路を構築する」と述べています。[29]
ある意味、SOA は革命というよりはむしろアーキテクチャの進化とみなすことができます。SOA は以前のソフトウェア アーキテクチャのベスト プラクティスの多くを取り入れています。たとえば、通信システムでは、ネットワーク内の他の機器と通信するために完全に静的なバインディングを使用するソリューションの開発はほとんど行われていません。SOA アプローチを採用することで、そのようなシステムは明確に定義され、相互運用性の高いインターフェイスの重要性を強調する立場に立つことができます。SOA の先行例としては、コンポーネント ベースのソフトウェア エンジニアリングや、 CORBAなどのリモート オブジェクトのオブジェクト指向分析および設計 (OOAD)などがあります。
サービスは、正式に定義されたインターフェースを介してのみ利用可能な機能のスタンドアロン ユニットで構成されます。サービスは、簡単に作成および改善できる、ある種の「ナノ企業」である可能性があります。また、サービスは、従属サービスの調整された作業として構築された「巨大企業」である可能性もあります。
サービスの実装を大規模なプロジェクトとは別のプロジェクトとして扱う理由は次のとおりです。
- 分離により、サービスは組織内で一般的な大規模で動きの遅いプロジェクトから独立して迅速に提供できるという概念がビジネスに促進されます。ビジネスは、サービスを呼び出すシステムと簡素化されたユーザーインターフェイスを理解し始めます。これは俊敏性を推進します。つまり、ビジネスイノベーションを促進し、市場投入までの時間を短縮します。[30]
- 分離により、サービスと消費プロジェクトの分離が促進されます。これにより、サービスが消費者を知らなくても設計される限り、優れた設計が促進されます。
- サービスのドキュメントとテスト成果物は、より大きなプロジェクトの詳細内に埋め込まれません。これは、後でサービスを再利用する必要がある場合に重要です。
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 ガバナンスが重要になります。[38]
SOAが直面するもう一つの大きな問題は、統一されたテストフレームワークの欠如である。サービス指向アーキテクチャにおけるこれらのサービスをテストするために必要な機能を提供するツールが存在しない。主な問題の原因は以下の通りである。[39]
- ソリューションの異質性と複雑さ。
- 自律サービスの統合により、テストの組み合わせが膨大になります。
- さまざまな競合ベンダーからのサービスを含める。
- 新しい機能やサービスが利用可能になるため、プラットフォームは継続的に変化します。
拡張機能とバリアント
イベント駆動型アーキテクチャ
アプリケーションプログラミングインターフェース
アプリケーション プログラミング インターフェイス (API) は、開発者が Web アプリケーションと対話できるフレームワークです。
ウェブ2.0
ティム・オライリーは、急速に成長しているウェブベースのアプリケーション群を表現するために「 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]
参照
- アプリケーションプログラミングインターフェース
- 疎結合
- OASIS SOA 参照モデル
- サービス粒度の原則
- SOAガバナンス
- ソフトウェアアーキテクチャ
- サービス指向通信(SOC)
- サービス指向のアプリケーション開発
- サービス指向分散アプリケーション
- Webアプリケーション記述言語
参考文献
- ^ ab 「SOAソースブック - SOAとは?」。collaboration.opengroup.org 。 2021年3月30日閲覧。
- ^ ソフトウェアアーキテクチャの基礎：エンジニアリングアプローチ。オライリーメディア。2020年。ISBN 978-1492043454。
- ^ 「第 1 章: サービス指向アーキテクチャ (SOA)」。msdn.microsoft.com。2017年 7 月 7 日時点のオリジナルよりアーカイブ。2016 年9 月 21 日閲覧。
- ^ 「サービス指向アーキテクチャ標準 - The Open Group」。www.opengroup.org。
- ^ 「SOA とは何か?」www.opengroup.org。2016 年 8 月 19 日時点のオリジナルよりアーカイブ。2016 年9 月 21 日閲覧。
- ^ Velte, Anthony T. (2010).クラウドコンピューティング: 実践的アプローチ. McGraw Hill. ISBN 978-0-07-162694-1。
- ^ ソフトウェアアーキテクチャの基礎：エンジニアリングアプローチ。オライリーメディア。2020年。ISBN 978-1492043454。
- ^ 「サービス指向アーキテクチャへの移行、パート 1」。2008 年 12 月 9 日。2008 年 12 月 9 日時点のオリジナルよりアーカイブ。2016年9 月 21 日閲覧。
{{cite web}}: CS1 maint: bot: 元の URL ステータス不明 (リンク) - ^ ab Michael Bell (2008)。 「サービス指向モデリング入門」。サービス指向モデリング: サービス分析、設計、アーキテクチャ。Wiley & Sons。p. 3。ISBN 978-0-470-14111-3。
- ^ Michael Bell (2010)。SOAモデリング パターン: サービス指向の検出と分析。Wiley & Sons。p. 390。ISBN 978-0-470-48197-4。
- ^ Thomas Erl (2005 年 6 月)。原則について。Serviceorientation.org
- ^ 「Application Platform Strategies Blog: SOA is Dead; Long Live Services」。Apsblog.burtongroup.com。2009 年 1 月 5 日。2009 年 1 月 15 日時点のオリジナルよりアーカイブ。2012年8 月 13 日閲覧。
- ^ Yvonne Balzer SOA プロジェクト計画の改善、IBM、2004 年 7 月 16 日
- ^ Microsoft Windows Communication Foundation チーム (2012)。「サービス指向設計の原則」。msdn.microsoft.com。2012年9 月 3 日閲覧。
- ^ SOA Systems Inc.の Thomas Erlによる8つの具体的なサービス指向の原則
- ^ 「4.4 Web サービス コントラクト テクノロジの使用に関するガイドライン - Web サービス コントラクトの構造」。InformIT。2021年 6 月 11 日。2021 年9 月 9 日に閲覧。
- ^ Tony Shan (2004)。「サービス指向の eBanking プラットフォームの構築」。IEEE国際サービスコンピューティング会議、2004 年 (SCC 2004)。議事録。2004 年。pp . 237–244。doi :10.1109/ SCC.2004.1358011。ISBN 978-0-7695-2225-8.S2CID 13156128 。2004
- ^ Duan, Yucong; Narendra, Nanjangud; Du, Wencai; Wang, Yongzhi; Zhou, Nianjun (2014 ) 。 「インターフェースの観点から見たクラウド サービス ブローカリングの検討」。2014 IEEE国際 Web サービス会議。IEEE。pp . 329–336。doi :10.1109/ICWS.2014.55。ISBN 978-1-4799-5054-6. S2CID 17957063。
- ^ Duan, Yucong (2012). 「サービス契約に関する調査」。2012第 13 回ACIS国際ソフトウェア工学、人工知能、ネットワーク、並列/分散コンピューティング会議。IEEE。pp . 805–810。doi :10.1109 / SNPD.2012.22。ISBN 978-1-4673-2120-4. S2CID 1837914。
- ^ 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: 複数の名前: 著者リスト (リンク) - ^ Rotem-Gal-Oz, Arnon (2012). SOA パターン. Manning Publications. ISBN 978-1933988269。
- ^ 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.
- ^ Brandner, M.、Craes, M.、Oellermann, F.、Zimmermann, O.、金融業界における運用における Web サービス指向アーキテクチャ、Informatik-Spektrum 02/2004、Springer-Verlag、2004
- ^ "www.ibm.com". IBM . 2016年9月10日閲覧。
- ^ 「SOAP バージョン 1.2 の公開について (W3C)」. W3.org。 2003 年 6 月 24 日。2012 年8 月 13 日に取得。
- ^ 沖島晴昼 (2006). 「COBOL資産を活用したシステム構築事例」(PDF) .
- ^ エンタープライズ SOA . Prentice Hall、2005
- ^ Christopher Koch 企業のための新たな青写真 2009年1月16日アーカイブ、Wayback Machine、CIO Magazine、2005年3月1日
- ^ Elizabeth Millard (2005 年 1 月)。「より良いプロセスの構築」。Computer User。20ページ。
- ^ Brayan Zimmerli (2009 年 11 月 11 日) SOA のビジネス上の利点、スイス北西部応用科学大学、ビジネス スクール
- ^ 「JSR-000089 OSS サービス アクティベーション API 仕様 1.0 最終リリース」。2011 年 7 月 26 日。2011 年 7 月 26 日時点のオリジナルよりアーカイブ。2024年5 月 18 日閲覧。
- ^ Joe McKendrick. 「Bray: SOA は複雑すぎる。『単なるベンダーの BS』」ZDNet。
- ^ Jimmy Zhang (2008 年 2 月 20 日)「VTD-XMLによる XML ドキュメントのインデックス作成」 Wayback Machineに 2008 年 7 月 4 日にアーカイブ。XML Journal。
- ^ Jimmy Zhang (2008 年 8 月 5 日)「i-Technology の視点: バイナリ XML のパフォーマンスの悩み」Wayback Machineに 2020 年 1 月 9 日にアーカイブ。Microservices Journal。
- ^ Jimmy Zhang (2008 年 1 月 9 日)「Ximple による XML コンテンツの操作」2017 年 7 月 30 日アーカイブ、Wayback Machine。devx.com 。
- ^ 「SOA が持続可能なソフトウェアを実現できない理由」jpmorgenthal.com。2009 年 6 月 19 日。2009年6 月 27 日閲覧。
- ^ 「SOA サービスは、依然として、それが表すアプリケーションによって制約されすぎている」ZDNet 2009 年 6 月 27 日2009 年6 月 27 日閲覧。
- ^ 「ガバナンスレイヤー」www.opengroup.org。2016年6月4日時点のオリジナルよりアーカイブ。2016年9月22日閲覧。
- ^ 「サービス指向アーキテクチャを効率的にテストする方法 | WSO2 Inc」wso2.com 。 2016 年9 月 22 日閲覧。
- ^ 「Web 2.0 とは何か」。ティム・オライリー。2005 年 9 月 30 日。2008 年6 月 10 日閲覧。
- ^ Christoph Schroth、Till Janner (2007)。「Web 2.0 と SOA : サービスのインターネットを実現する統合概念」。IT Professional。9 ( 3): 36–41。doi : 10.1109 /MITP.2007.60。S2CID 2859262。2013 年 12 月 3 日時点のオリジナルよりアーカイブ。2008 年2 月 23 日閲覧。
- ^ ドラゴニ、ニコラ;ジャロレンツォ、サヴェリオ。アルベルト・リュッホ・ラフェンテ;マザラ、マヌエル。モンテジ、ファブリツィオ。ムスタフィン、ルスラン。サフィーナ、ラリサ（2016）。 「マイクロサービス: 昨日、今日、そして明日」。arXiv : 1606.04036v1 [cs.SE]。
- ^ James Lewis と Martin Fowler。「マイクロサービス」。
- ^ Balalaie, A.; Heydarnoori, A.; Jamshidi, P. (2016 年 5 月 1 日)。「マイクロサービス アーキテクチャが DevOps を実現する: クラウド ネイティブ アーキテクチャへの移行」( PDF )。IEEEソフトウェア。33 (3): 42–52。doi : 10.1109 /MS.2016.64。hdl : 10044/1 / 40557。ISSN 0740-7459。S2CID 18802650 。
- ^ 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日閲覧。
- ^ 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日閲覧。
- ^ Mahy Aly、Michael Franke (2016)。「最適化さ れたリソース共有によって実現されるサービス指向インタラクティブ メディア (SOIM) エンジン」。2016 IEEE サービス指向システム エンジニアリング (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日閲覧。
- Mauro, Christian; Leimeister , Jan Marco; Krcmar, Helmut (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日閲覧。
ウィキメディア・コモンズには、サービス指向アーキテクチャに関連するメディアがあります。
