Coulouris は、分散システムを「コンピュータ ネットワーク内に存在するハードウェアおよび/またはソフトウェア コンポーネントがメッセージを交換することによって通信し、その動作を調整するシステム」と定義しました。
この概念は、いくつかの要因により近年一般的になりました。分散システムの発展を促進した最初の要因は、高速ローカルネットワークの出現でした。もう 1 つの重要な要素は、パーソナル コンピュータの性能における技術的進歩と、分散アプリケーションをサポートするソフトウェアの開発でした。分散システムは、Web とインターネットの概念に関連付けられています。 Web の進化と、新しい領域、インタラクション、ニーズ、アプリケーションの出現に伴い、Web 2.0 の概念が出現します。この用語は 2004 年にティム・オライリーによって作られ、ユーザー コミュニティと、コラボレーションとアジャイルを促進するソーシャル ネットワーク、ブログ、ウィキ、フォークソノミーなどの特別な範囲のサービスに基づく Web の歴史の第 2 世代を指します。ユーザー間の情報交換。
サービス指向 (SOA) とみなされる最初のアーキテクチャは、CORBA (Common Object Request Broker Architecture) に基づいていました。CORBA は、アーキテクチャのさまざまな要素を相互接続してサービスを構築するための抽象化層として機能しました。その他の初期のテクノロジには、DCOM (分散コンポーネント オブジェクト モデル) または RPC (リモート プロシージャ プロトコル) がありました。 Web 上で分散システムを効率的に設計および実装する必要があるため、開発自体 (パフォーマンス、ユーザー エクスペリエンスなど) に焦点を当てたものや、サービスの再利用性と互換性に基づいた補完的なものなど、いくつかの課題が生じます。これらのニーズから、さまざまなユーザーを情報サーバーに相互接続するための標準化されたメカニズムを提供する Web サービスが生まれます。
サービス指向のアーキテクチャ
SOA (サービス指向アーキテクチャ) によれば、これらはビジネス要件をサポートするためのサービスの使用を定義するソフトウェア アーキテクチャであり、その目的はソフトウェア エージェント間の結合を最小限に抑えることです。サービスは、サービス消費者が望む最終結果を達成するためにサービスプロバイダーによって実行される作業単位です。サービスプロバイダーとサービスコンシューマーはどちらも、ソフトウェアエージェントが果たす役割であり、その所有者ではありません。一般的な意味では、サービス指向アーキテクチャは、企業がさまざまなプロセスを組織して利用できるようにすることを目的としたソフトウェア ソリューションです。 SOA を使用すると、ソフトウェア アプリケーションは機能やプロセスの巨大なブロックではなくなります。代わりに、これらのアプリケーションは組み立てられたモジュール式サービスで構成されています。サービスは単純なソフトウェア機能 (CD の再生のキャンセルなど) であることに注意してください。オペレーティング システム、プラットフォーム、プログラミング言語、地理的な場所に関係なく、あらゆるシステムでオンデマンドで実行できます。
SOA の革新的な点は、古くから存在する概念そのものではなく、それが WWW (World Wide Web) を通じて実装できるという事実です。 Web ページが任意のプラットフォームに読み込まれるのと同様に、Web サービスは、次を使用して構築されているため、プラットフォームに関係なく同様に動作します。
普遍的な標準。
SOA のアイデアは、データとその処理の関係を示唆するオブジェクト指向プログラミングに直接由来しています。したがって、基盤となるプラットフォームやプログラミング言語から独立したインターフェイスを通じてサービスを正式に定義します。これらのインターフェイスは実装の特殊性を隠しているため、インターフェイスから独立しています。 開発者とプログラミング言語。これらのアーキテクチャを通じて、ビジネス ロジックを反映すると同時に、異なる独自システムやサードパーティ システム間の相互作用を容易にする、拡張性の高いシステムを設計および実装することができます。私たちが誰かに仕事をしてもらいたい理由は、彼らが専門家だからです。一般に、サービスを使用する方が、自分で行うよりも安価で効果的です。したがって、私たちのほとんどは、すべての分野の専門家になることはできないことを理解しています。同じルールがソフトウェア システムの構築にも適用できます。
インターフェイスは非常に重要であり、インターフェイスが明確に定義されていない場合、または機能しない場合、システムは機能しません。より多くのインターフェイスを統合するとコストがかかり、分散アプリケーションでエラーが発生する可能性も高くなります。リモート インターフェイスは、ほとんどの分散アプリケーションの中で最も遅い部分です。これらすべてを考慮すると、アプリケーションごとに新しいインターフェイスを構築するのではなく、すべてのアプリケーションで汎用インターフェイスを再利用する方が合理的です。
したがって、使用できる汎用インターフェイスが少数しかないため、メッセージにアプリケーション固有のセマンティクスを含める必要があります。インターフェイスを介してあらゆる種類のメッセージを送信できますが、アーキテクチャがサービス指向であると言うためには、いくつかのルールに従う必要があります。
– まず、サービスプロバイダーが問題を解決する責任があるため、メッセージは教訓的なものではなく、説明的なものである必要があります。たとえば、レストランに行ってウェイターに飲みたいものや好みを伝えるのと似ていますが、料理人に料理の作り方を逐一説明する必要はありません。
‐ 第二に、サービスプロバイダーのメッセージが関係者全員が理解できる形式、構造、語彙で書かれていない場合、サービスプロバイダーはあなたのリクエストを理解することができません。したがって、メッセージの語彙と構造を制限することは、
効果的なコミュニケーションに必要です。メッセージが限定されているほど、理解しやすくなります。
‐ 第三に、拡張の可能性は非常に重要です。世界は常に変化しており、ソフトウェアが存在する環境も同様です。これらの変更には、システム ソフトウェア、消費者への対応する変更が必要です。 サービス、プロバイダー、およびそれらが交換するメッセージの概要。メッセージが拡張可能でない場合、コンシューマーとプロバイダーはサービスの特定のバージョンにロックされます。制約と拡張性は深い関係にあり、両方が必要であり、一方を増やすことは他方を減らすことを意味します。理想は正しいバランスを達成することです。
– 第 4 に、SOA には、消費者が求めるサービスのコンテキスト内でサービス プロバイダーを発見できるメカニズムが必要です。このメカニズムは柔軟である必要があり、集中型のレジストリであってはなりません。
‐ 5 番目、ステートレス サービス: コンシューマがプロバイダに送信する各メッセージには、プロバイダがメッセージを処理するために必要なすべての情報が含まれている必要があります。この制限により、サービス プロバイダーはリクエスト間の状態情報を保存する必要がなくなるため、サービス プロバイダーのスケーラビリティが向上します。それぞれの要望に汎用的に対応できるため、「量産サービス」と言えます。この制限により、どの監視ソフトウェアでも独立したリクエストを検査してその意図を抽出できるため、可視性も向上します。また、中間状態がないため、部分的な障害からの回復も容易になり、サービスの信頼性が高まります。
‐ 6 番目、冪等リクエスト (変更を行わない): ソフトウェア エージェントが受信した重複したリクエストは、単一のリクエストと同じ効果があります。この要件により、プロバイダーと消費者は、システムの全体的な信頼性を向上させることができます。 サービスで、障害が発生した場合はリクエストを繰り返すだけです。
したがって、SOA はツールではなく、より動的で依存性の低い新しいアプリケーションを構築するための一連の標準であると言えます。 SOA は、異なるサービス間のビジネス ロジックや情報への体系的な方法でのアクセスを容易にし、複数のリモート サービスを調整して 1 つのサービスを形成することもできます。大多数の この定義は、サービス指向アーキテクチャの実装における Web サービスの使用を識別します (次の章で説明します)。ただし、他のサービスベースのテクノロジーを使用して実装することもできます。