分散型AISは日常の現実となっています。 多くの企業AISは分散データベースを使用しています。 データ分散と分散データの管理の方法、システムのスケーラビリティを保証するアーキテクチャアプローチ、多層クライアントサーバーアーキテクチャの原則の実装、および中間層のアーキテクチャが検討されています。

モバイルアーキテクチャは実際に適用され始めています。 これは、データベースシステムとWebアプリケーションの両方に当てはまります。

ピアツーピアアーキテクチャに基づいて分散システムを構築するアプローチが復活しています。分散システムで今日支配的なクライアントサーバーアーキテクチャとは異なり、ネットワーク内の相互作用するパーティの役割は固定されていません。 これらは、ネットワークの状況、ノードのワークロードに応じて割り当てられます。

通信技術の集中的な開発に関連して、モバイルAISは活発に開発されています。 それらを作成するための技術的手段とソフトウェアが開発されました。 これは、モバイルデータベースシステムの開発につながりました。 多くの研究チームは、そのようなシステムの特定の機能について研究を行い、さまざまなプロトタイプを作成しています。 Javaテクノロジは、モバイルソフトウェア開発の重要なツールになっています。

ワイヤレスアプリケーションプロトコル（WAP）標準が作成されており、一部の携帯電話モデルですでにサポートされています。 WAPとXMLに基づいて、W3Cはワイヤレス通信用のマークアップ言語であるWML（Wireless Markup Language）を開発しました。

AISの開発では、メタデータにより多くの注意が払われてきました。 ここでは、メタデータの表示を標準化することと、システムでのサポートを確保することの2つの方向で手順を実行します。

AISは、メタデータ（さまざまな種類のメタデータリポジトリ）を表示するためのさまざまな方法と手段を使用します。 この分野での統合の欠如は、アプリケーションのモビリティ、情報リソースと情報技術の再利用と統合、およびAISリエンジニアリングの問題の解決を大幅に複雑にします。

これらの困難を克服するために、さまざまな情報技術に焦点を当てたメタデータ標準の開発が積極的に進められています。 この分野では、メタデータの表示とAISでのメタデータの交換を定義する、国際、国内、および業界の標準がすでに多数存在します。 それらのいくつかはすでに事実上の標準のステータスを取得しています。 ここでは、それらの中で最も重要なものだけに言及することに限定します。

おそらく、このカテゴリの最初の事実上の標準は、ネットワーク化されたデータベースのCODASYLデータ記述言語でした。 次の標準に名前を付ける必要があります。いわゆる情報スキーマの定義を含む、リレーショナルデータベースのSQLクエリ言語の標準-リレーショナルデータベーススキーマの表現のセット。 オブジェクトスキーマリポジトリインターフェイスを記述するODMGオブジェクトデータベース標準コンポーネント。 組織の情報リソースのディレクトリを作成および維持するためのシステムを説明する国際標準IRDS（情報リソース辞書システム）。

次に、OMGコンソーシアムによって開発されたデータウェアハウスメタデータを表すためのCommon Warehouse Metamodel（CWM）標準について言及する必要があります。これは、MDC（Meta Data Coalition）コンソーシアムによって以前に作成された幅広い目的のOIM（Open Information Model）標準に基づいています。 。

Webテクノロジープラットフォーム用の新しいXMLには、メタデータ表示標準も含まれています。 メタデータのサポートは、Webの最も重要な革新の1つであり、情報リソースを管理するためのテクノロジーを根本的に変えています。 メタデータのサポートは元々データベーステクノロジで必要でしたが、メタデータは第1世代のWebではサポートされていませんでした。

Webメタデータ標準には、あるタイプのXMLドキュメントの論理構造を記述するために使用されるXML言語のサブセットが含まれています。 この記述はDTD（文書型定義）と呼ばれます。 さらに、XMLプラットフォームには、XMLドキュメントを記述するためのより高度な機能を提供するXMLスキーマ標準が含まれています。 Resource Definition Framework（RDF）標準は、XMLドキュメントのコンテンツを記述するための単純な知識表現言語を定義します。 最後に、新しいOWL（Ontology Web Language）標準は、セマンティックWebの正式なオントロジー記述言語を定義します。

CASEビジュアルオブジェクト分析および設計ツールのメタデータ表現を提供する統一モデリング言語（UML）標準は、OMGコンソーシアムによって開発されました。 この言語は、多くのCASEソフトウェア製品でサポートされています。 OMGは、UMLを使用してCASEツール間でメタデータを交換するためのXMLメタデータ交換（XMI）標準も作成しました。

ここでは、さまざまな性質のドキュメントのコンテンツを記述するためのメタデータ要素のセットであるダブリンコア（DC）標準についても言及する必要があります。 この標準はすぐに人気を博し、特にWeb環境で広く使用されています（セクション3.3を参照）。

AISのメタデータを表示するための既存の標準の開発と新しい標準の作成に関する作業は継続されています。 問題の規格に関するより詳細な情報は、百科事典にあります。

コンピュータサイエンスの分野で有名な専門家E.タネンバウムによると、一般的に受け入れられていると同時に、分散システムの厳密な定義はありません。 一部のウィットは、分散型はそのようなものであると主張しています コンピューティングシステム、ユーザーがこれまで疑うことさえなかったコンピューターの故障が、すべての作業の終了につながる。 残念ながら、分散コンピューティングシステムの大部分はこの定義を満たしていますが、正式には、固有の脆弱性のあるシステムのみを指します（ 単一障害点).

多くの場合、分散システムを定義するときは、その機能を複数のコンピューターに分割することに焦点が当てられます。 このアプローチでは、すべてが配布されます コンピューティングシステムデータ処理が2台以上のコンピューターに分割されている場合。 E. Tanenbaumの定義に基づいて、やや狭く分散されたシステムは、通信チャネルによって接続された独立したコンピューターのセットとして定義できます。これは、一部のソフトウェアのユーザーの観点からは、単一の全体のように見えます。

分散システムを定義するこのアプローチには、欠点があります。 たとえば、そのような分散システムで使用されるすべてのもの ソフトウェア単一のコンピューターで動作する可能性がありますが、上記の定義の観点から、そのようなシステムは配布されなくなります。 したがって、分散システムの概念は、おそらくそのようなシステムを形成するソフトウェアの分析に基づいている必要があります。

2つのエンティティの相互作用を説明するための基礎として、一方の当事者（クライアント）が他方の当事者（サーバー）に要求を送信することによってデータの交換を開始する、クライアント/サーバー相互作用の一般的なモデルを検討してください。 サーバーは要求を処理し、必要に応じてクライアントに応答を送信します（図1.1）。

米。 1.1。

クライアント/サーバーモデルのフレームワーク内の相互作用は、クライアントがサーバーが要求を処理するのを待っているときの同期、またはクライアントがサーバーに要求を送信してサーバーの要求を待たずに実行を継続する非同期のいずれかです。応答。 クライアントとサーバーのモデルは、さまざまな相互作用を説明するための基礎として使用できます。 このコースでは、分散システムを形成するソフトウェアの構成要素の相互作用が重要です。

米。 1.2。

現代の概念に従って、次の論理レベルに分割できる特定の典型的なアプリケーションについて考えてみます（図1.2）。 ユーザーインターフェース（PI）、アプリケーションロジック（LP）、およびデータアクセス（DD）、データベース（DB）との連携。 システムユーザーはユーザーインターフェイスを介してシステムユーザーと対話し、データベースはアプリケーションドメインを説明するデータを格納し、アプリケーションロジックレイヤーはに関連するすべてのアルゴリズムを実装します。 サブジェクトエリア.

実際には、システムのさまざまなユーザーが通常同じデータにアクセスすることに関心があるため、このようなシステムの機能を複数のコンピューター間で最も簡単に分離するのは、アプリケーションの1つのサーバー部分間でアプリケーションの論理層を分離することです。 、データへのアクセスを担当し、複数のコンピューターにあるクライアントパーツ。ユーザーインターフェイスを実装します。 アプリケーションロジックは、サーバー、クライアントに割り当てることも、それらの間で共有することもできます（図1.3）。

米。 1.3。

この原則に基づいて構築されたアプリケーションのアーキテクチャは、クライアントサーバーまたは2層と呼ばれます。 実際には、このようなシステムは分散システムとして分類されないことがよくありますが、正式には分散システムの最も単純な代表と見なすことができます。

クライアント/サーバーアーキテクチャの開発は3層アーキテクチャであり、ユーザーインターフェイス、アプリケーションロジック、およびデータアクセスは、独立したコンピューターで実行できるシステムの独立したコンポーネントに分離されています（図1.4）。

米。 1.4。

このようなシステムでのユーザーの要求は、システムのクライアント部分、アプリケーションロジックサーバー、およびデータベースサーバーによって順番に処理されます。 ただし、分散システムは通常、3層システムよりも複雑なアーキテクチャを備えたシステムとして理解されます。

前の章では、共有メモリ、共有カーネルデータ構造、およびプロセスが呼び出される共有プールを備えた密結合マルチプロセッサシステムについて説明しました。 ただし、多くの場合、リソース共有の目的で、動作環境および動作条件から自律するようにプロセッサを割り当てることが望ましいです。 たとえば、パーソナルコンピュータのユーザーが、より大きなマシンにあるファイルにアクセスする必要があるが、同時にパーソナルコンピュータの制御を維持するとします。 uucpなどの一部のプログラムは、ネットワークファイル転送やその他のネットワーク機能をサポートしていますが、ユーザーはネットワークを使用していることを認識しているため、それらの使用はユーザーから隠されません。 さらに、テキストエディタのようなプログラムは、通常のファイルのように、削除されたファイルでは機能しないことに注意してください。 ユーザーは、UNIXシステム機能の標準セットを持っている必要があり、潜在的なパフォーマンスのボトルネックは別として、マシンの境界を越えていると感じてはなりません。 したがって、たとえば、リモートマシン上のファイルで開いたり読み取ったりするシステム機能の作業は、ローカルシステムに属するファイルでの作業と同じである必要があります。

分散システムアーキテクチャを図13.1に示します。 図に示されている各コンピュータは、CPU、メモリ、および周辺機器で構成される自己完結型のユニットです。 コンピューターにローカルファイルシステムがなくても、モデルは壊れません。他のマシンと通信するには周辺機器が必要であり、モデルに属するすべてのファイルを別のコンピューターに配置できます。 各マシンで使用可能な物理メモリは、他のマシンで実行されているプロセスから独立しています。 この点で、分散システムは、前の章で説明した密結合マルチプロセッサシステムとは異なります。 したがって、各マシンのシステムのコアは、分散環境の外部動作条件とは無関係に機能します。

図13.1 分散アーキテクチャシステムモデル

文献に詳しく説明されている分散システムは、従来、次のカテゴリに分類されます。

ペリフェラルシステム。これは、強い共通性を持ち、1台の（通常はより大きな）マシンに関連付けられているマシンのグループです。 周辺機器プロセッサは、負荷を中央処理装置と共有し、オペレーティングシステムへのすべての呼び出しを中央処理装置に転送します。 周辺システムの目標は、ネットワーク全体のパフォーマンスを向上させ、UNIXオペレーティング環境の単一のプロセスにプロセッサを割り当てる機能を提供することです。 システムは別のモジュールとして起動します。 分散システムの他のモデルとは異なり、周辺システムには、プロセスのディスパッチとローカルメモリの割り当てに関連する場合を除いて、実際の自律性はありません。

ライブラリ内のリモートファイルの名前によるリモート通信を可能にする「Newcastle」などの分散システム（名前は「TheNewcastleConnection」の記事から取得されます-を参照）。 削除されたファイルには、検索パスに特殊文字またはファイルシステムルートの前にあるオプションの名前コンポーネントを含むBOM（識別名）があります。 このメソッドの実装には、システムカーネルへの変更が含まれないため、この章で説明する他のメソッドよりも単純ですが、柔軟性は低くなります。

分散システムは完全に透過的であり、他のマシンにあるファイルを参照するには、標準の識別名で十分です。 これらのファイルを削除済みとして認識するのはカーネル次第です。 複合名で指定されたファイル検索パスは、ファイルシステムがディスクにマウントされたときにそのようなポイントがいくつ形成されても、マウントポイントでマシンの境界を越えます。

この章では、各モデルのアーキテクチャについて説明します。 提供されるすべての情報は、特定の開発の結果に基づくのではなく、さまざまな技術記事に公開されている情報に基づいています。 これは、プロトコルモジュールとデバイスドライバがアドレス指定、ルーティング、フロー制御、およびエラーの検出と修正を担当していることを前提としています。つまり、各モデルは使用されているネットワークから独立していることを前提としています。 次のセクションで示す周辺システムのシステム機能の使用例は、ニューカッスルのようなシステムや完全に透過的なシステムでも同様に機能します。これについては後で説明します。 したがって、一度詳細に検討し、他のタイプのシステムに関するセクションでは、主にこれらのモデルを他のすべてのモデルと区別する機能に焦点を当てます。

13.1ペリフェラルプロセッサ

周辺システムのアーキテクチャを図13.2に示します。 この構成の目標は、実行中のプロセスをCPUと周辺機器プロセッサ間で再割り当てすることにより、ネットワーク全体のパフォーマンスを向上させることです。 各周辺機器プロセッサには、中央処理装置と通信するために必要なもの以外に、自由に使用できる他のローカル周辺機器はありません。 ファイルシステムとすべてのデバイスは、中央処理装置が自由に使用できます。 すべてのユーザープロセスがペリフェラルプロセッサで実行され、ペリフェラルプロセッサ間を移動しないと仮定します。 プロセッサに転送されると、完了するまでプロセッサに残ります。 周辺機器プロセッサには、システムへのローカルコール、割り込み管理、メモリ割り当て、ネットワークプロトコル、および中央処理装置との通信用のデバイスドライバを処理するように設計されたオペレーティングシステムのライトバージョンが含まれています。

システムが中央処理装置で初期化されると、コアは通信回線を介して各周辺処理装置にローカルオペレーティングシステムをロードします。 周辺で実行されているプロセスはすべて、中央処理装置に属する衛星プロセスに関連付けられています（を参照）。 周辺プロセッサで実行されているプロセスが中央処理装置のサービスのみを必要とするシステム機能を呼び出すと、周辺プロセスはその衛星と通信し、要求は処理のために中央処理装置に送信されます。 衛星プロセスはシステム機能を実行し、結果を周辺プロセッサに送り返します。 周辺プロセスとそのサテライトの関係は、第11章で詳細に説明したクライアントサーバー関係に似ています。周辺プロセスは、ファイルシステムでの作業機能をサポートするサテライトのクライアントとして機能します。 この場合、リモートサーバープロセスにはクライアントが1つしかありません。 セクション13.4では、複数のクライアントを持つサーバープロセスについて説明します。

図13.2 周辺システムの構成

図13.3。 メッセージ形式

周辺プロセスがローカルで処理できるシステム関数を呼び出す場合、カーネルはサテライトプロセスに要求を送信する必要はありません。 したがって、たとえば、追加のメモリを取得するために、プロセスはローカル実行のためにsbrk関数を呼び出すことができます。 ただし、ファイルを開くなど、中央処理装置のサービスが必要な場合、カーネルは、呼び出された関数に渡されたパラメーターとプロセス実行条件に関する情報を、サテライトプロセスに送信されるメッセージにエンコードします（図13.3）。 メッセージには、システム機能がクライアントに代わってサテライトプロセスによって実行されることを示す記号、機能に渡されるパラメータ、およびプロセス実行環境に関するデータ（たとえば、ユーザーおよびグループの識別コード）が含まれます。機能ごとに異なります。 メッセージの残りの部分は可変長データです（たとえば、複合ファイル名または書き込み機能で書き込まれるデータ）。

サテライトプロセスは、ペリフェラルプロセスからの要求を待ちます。 要求を受信すると、メッセージをデコードし、システム機能のタイプを判別して実行し、その結果を周辺プロセスに送信される応答に変換します。 応答には、システム関数の実行結果に加えて、エラーメッセージ（存在する場合）、信号番号、およびファイルから読み取られた情報などを含む可変長データ配列が含まれます。 周辺プロセスは、応答が受信されるまで中断され、応答を受信した後、復号化して結果をユーザーに送信します。 これは、オペレーティングシステムへの呼び出しを処理するための一般的なスキームです。 それでは、個々の機能のより詳細な考察に移りましょう。

周辺システムがどのように機能するかを説明するために、getppid、open、write、fork、exit、signalなどのいくつかの関数を検討してください。 getppid関数は、ペリフェラルとCPUの間で交換される単純な要求および応答フォームを処理するため、非常に単純です。 周辺プロセッサのコアは、符号付きのメッセージを生成します。このメッセージから、要求された関数はgetppid関数であることがわかり、中央処理装置に要求が送信されます。 中央処理装置の衛星プロセスは、周辺処理装置からメッセージを読み取り、システム機能のタイプを復号化して実行し、その親の識別子を取得します。 次に、応答を生成し、通信回線のもう一方の端にある保留中の周辺プロセスに渡します。 周辺プロセッサは応答を受信すると、getppidシステム関数を呼び出したプロセスに応答を渡します。 周辺プロセスがデータ（親のプロセスIDなど）をローカルメモリに格納している場合、そのコンパニオンと通信する必要はまったくありません。

オープンシステム関数が呼び出されると、ペリフェラルプロセスは、ファイル名やその他のパラメータを含むメッセージをコンパニオンに送信します。 成功した場合、コンパニオンプロセスは、インデックスとエントリポイントをファイルテーブルに割り当て、そのスペースのユーザーファイル記述子テーブルにエントリを割り当て、ファイル記述子を周辺プロセスに返します。 この間ずっと、通信回線のもう一方の端で、周辺プロセスは応答を待っています。 彼は、開いているファイルに関する情報を格納するための構造を自由に使用できません。 openによって返される記述子は、ユーザーファイル記述子テーブルのコンパニオンプロセスのエントリへのポインタです。 関数を実行した結果を図13.4に示します。

図13.4。 周辺プロセスからopen関数を呼び出す

システム関数writeが呼び出されると、ペリフェラルプロセッサは、書き込み関数の符号、ファイル記述子、および書き込まれるデータの量で構成されるメッセージを生成します。 次に、周辺プロセスの空間から、通信回線を介してデータを衛星プロセスにコピーします。 サテライトプロセスは、受信したメッセージを復号化し、通信回線からデータを読み取り、対応するファイルに書き込みます（メッセージに含まれる記述子は、ファイルテーブル内のインデックスとレコードのポインタとして使用されます） ）; これらのアクションはすべて中央処理装置で実行されます。 作業の最後に、サテライトプロセスは、メッセージの受信を確認し、ファイルに正常にコピーされたデータのバイト数を含むメッセージをペリフェラルプロセスに送信します。 読み取り操作も同様です。 衛星は、実際に読み取られたバイト数を周辺プロセスに通知します（端末またはチャネルからデータを読み取る場合、この数は、要求で指定された量と常に一致するとは限りません）。 いずれかの機能を実行するには、送信されるデータの量とネットワークパケットのサイズによって決まる、ネットワークを介して情報メッセージを複数回送信する必要がある場合があります。

CPUでの実行中に変更する必要がある唯一の機能は、フォークシステム機能です。 プロセスがCPUでこの関数を実行すると、カーネルはその周辺プロセッサを選択し、特別なプロセス（サーバー）にメッセージを送信して、現在のプロセスのアンロードを開始することをサーバーに通知します。 サーバーが要求を受け入れたとすると、カーネルはforkを使用して新しい周辺プロセスを作成し、プロセステーブルエントリとアドレス空間を割り当てます。 中央処理装置は、フォーク機能を呼び出したプロセスのコピーを周辺機器プロセッサにアンロードし、新しく割り当てられたアドレス空間を上書きし、ローカル衛星を生成して新しい周辺機器プロセスと通信し、メッセージを周辺機器に送信して、のプログラムカウンターを初期化します。新しいプロセス。 （CPU上の）サテライトプロセスは、フォークを呼び出したプロセスの子孫です。 周辺プロセスは、技術的にはサーバープロセスの子孫ですが、論理的には、フォーク関数を呼び出したプロセスの子孫です。 フォークが完了すると、サーバープロセスは子と論理的に接続されません。 サーバーの唯一の仕事は、子のアンロードを支援することです。 システムコンポーネント間の強力な接続（ペリフェラルプロセッサには自律性がありません）により、ペリフェラルプロセスとサテライトプロセスは同じ識別コードを持ちます。 プロセス間の関係を図13.5に示します。実線は親子関係を示し、点線はピア間の関係を示します。

図13.5。 CPUでフォーク機能を実行する

プロセスがペリフェラルプロセッサでフォーク機能を実行すると、CPU上のサテライトにメッセージが送信され、CPUが上記の一連のアクション全体を実行します。 サテライトは、新しいペリフェラルプロセッサを選択し、古いプロセスのイメージをアンロードするために必要な準備を行います。サテライトは、親ペリフェラルプロセスにイメージを読み取る要求を送信し、それに応答して、要求されたデータの転送がもう一方の端で開始されます。通信チャネルの。 衛星は送信された画像を読み取り、それを周辺の子孫に上書きします。 イメージのアンロードが終了すると、サテライトプロセスはフォークしてCPU上に子を作成し、プログラムカウンターの値を周辺の子に渡して、周辺の子が実行を開始する場所を認識できるようにします。 明らかに、コンパニオンプロセスの子が親としてペリフェラルの子に割り当てられているとよいでしょうが、この場合、生成されたプロセスは、作成されたプロセッサだけでなく、他のペリフェラルプロセッサでも実行できます。 フォーク機能終了時のプロセス間の関係を図13.6に示します。 周辺プロセスが作業を終了すると、対応するメッセージを衛星プロセスに送信し、それも終了します。 コンパニオンプロセスはシャットダウンを開始できません。

図13.6。 周辺プロセッサでフォーク機能を実行する

マルチプロセッサシステムとユニプロセッサシステムの両方で、プロセスは同じ方法で信号に応答する必要があります。プロセスは、信号をチェックする前にシステム機能の実行を完了するか、逆に、信号を受信するとすぐに中断状態を終了し、これが彼が一時停止された優先順位と一致する場合、システム機能の作業を突然中断します。 衛星プロセスは周辺プロセスに代わってシステム機能を実行するため、周辺プロセスと連携して信号に応答する必要があります。 ユニプロセッサシステムで、シグナルによってプロセスが機能を中止した場合、マルチプロセッサシステムのコンパニオンプロセスも同じように動作する必要があります。 信号が終了機能を使用してプロセスに作業を終了するように促す場合についても同じことが言えます。周辺プロセスが終了し、対応するメッセージを衛星プロセスに送信します。衛星プロセスももちろん終了します。

周辺プロセスが信号システム関数を呼び出すと、現在の情報がローカルテーブルに保存され、指定された信号を受信するか無視するかを通知するメッセージが衛星に送信されます。 衛星プロセスは、信号を傍受するかデフォルトのアクションを傍受するかを気にしません。 シグナルに対するプロセスの反応は、3つの要因に依存します（図13.7）：プロセスがシステム機能を実行している間にシグナルが到着するかどうか、シグナルを無視するためにシグナル機能を使用して指示が行われるかどうか、シグナルが同じ周辺プロセッサまたは他のプロセッサ。 さまざまな可能性の検討に移りましょう。

sighandleアルゴリズム/ *信号処理アルゴリズム* /

if（現在のプロセスが誰かの仲間であるかプロトタイプを持っている）

if（シグナルは無視されます）

if（システム機能の実行中に信号が来た）

衛星プロセスの前に信号を置きます。

周辺プロセスにシグナルメッセージを送信します。

else（/ *周辺プロセス* /

/ *システム機能の実行中に信号を受信したかどうか* /

衛星プロセスに信号を送信します。

アルゴリズムsatellite_end_of_syscall / *周辺プロセスによって呼び出されたシステム関数の終了* /

入力情報：不在

インプリント：なし

if（システム機能の実行中に割り込みを受信した）

割り込みメッセージ、信号を周辺プロセスに送信します。

else / *システム機能の実行は中断されませんでした* /

応答の送信：信号の到着を示すフラグを有効にします。

図13.7。 周辺システムでの信号処理

衛星プロセスがその代わりにシステム機能を実行している間に、周辺プロセスがその作業を一時停止したと仮定します。 信号が他の場所で発生した場合、衛星プロセスは周辺プロセスよりも早く信号を検出します。 3つのケースが考えられます。

1.何らかのイベントを待っている間に、サテライトプロセスがサスペンド状態にならず、シグナルを受信するとサテライトプロセスが終了する場合、サテライトプロセスはシステム機能を最後まで実行し、実行結果をペリフェラルプロセスに送信して表示します。どの信号を受信したか。

2.プロセスがこのタイプの信号を無視するように指示された場合、衛星はlongjmpによって中断状態を終了することなく、システム関数実行アルゴリズムに従い続けます。 周辺プロセスに送信される応答では、シグナル受信メッセージはありません。

3.信号を受信すると、衛星プロセスがシステム機能の実行を（longjmpによって）中断した場合、衛星プロセスはこれを周辺プロセスに通知し、信号番号を通知します。

周辺プロセスは、受信した応答で信号の受信に関する情報を探し、存在する場合は、システム機能を終了する前に信号を処理します。 したがって、マルチプロセッサシステムでのプロセスの動作は、ユニプロセッサシステムでの動作と完全に一致します。つまり、カーネルモードを終了せずに終了するか、カスタム信号処理関数を呼び出すか、信号を無視してシステム関数を正常に完了します。

図13.8。 システム機能の実行中の割り込み

たとえば、周辺プロセスが中央処理装置に接続された端末から読み取り関数を呼び出し、衛星プロセスが関数を実行している間、その作業を一時停止するとします（図13.8）。 ユーザーがブレークキーを押すと、CPUコアは衛星プロセスに信号を送信します。 衛星が一時停止状態にあり、端末からのデータの一部を待っている場合、衛星はすぐにこの状態を終了し、読み取り機能を終了します。 衛星は、周辺プロセスからの要求に応答して、割り込みに対応するエラーコードと信号番号を提供します。 周辺プロセスは応答を分析し、メッセージが割り込みが到着したことを示しているので、信号をそれ自体に送信します。 読み取り機能を終了する前に、ペリフェラルコアはシグナリングをチェックし、衛星プロセスからの割り込み信号を検出して、通常どおりに処理します。 割り込み信号を受信した結果、ペリフェラルプロセスがexit関数を使用して作業を終了した場合、この関数はサテライトプロセスの強制終了を処理します。 周辺プロセスが割り込み信号をインターセプトすると、ユーザー定義のシグナル処理関数を呼び出し、読み取り関数を終了するとエラーコードをユーザーに返します。 一方、衛星が周辺プロセスに代わって統計システム機能を実行する場合、信号を受信して​​も実行を中断しません（統計機能はリソース待機時間が限られているため、一時停止を終了することが保証されています） ）。 衛星は機能の実行を完了し、信号番号を周辺プロセスに返します。 周辺プロセスはそれ自体に信号を送信し、システム機能の終了時にそれを受信します。

システム機能の実行中に周辺プロセッサで信号が発生した場合、周辺プロセスは、衛星プロセスからすぐに制御に戻るか、衛星プロセスが無期限に一時停止状態になるかについて暗闇になります。 周辺プロセスは、信号の発生を通知する特別なメッセージを衛星に送信します。 CPUのコアはメッセージを復号化し、衛星に信号を送信します。信号の受信に対する反応については、前の段落で説明します（関数の実行の異常終了またはその完了）。 衛星がシステム機能の実行でビジーであり、通信回線からデータを読み取っていないため、周辺プロセスは衛星に直接メッセージを送信できません。

読んだ例を参照すると、周辺プロセスは、そのコンパニオンが端末からの入力を待っているのか、他のアクションを実行しているのかを認識していないことに注意してください。 周辺プロセスは信号メッセージを衛星に送信します。衛星が中断可能な優先度で一時停止状態にある場合、衛星はすぐにこの状態を終了し、システム機能を終了します。 それ以外の場合、関数は正常に完了するまで繰り越されます。

最後に、システム機能の実行に関連付けられていない時間に信号が到着した場合を考えてみます。 信号が別のプロセッサで発信された場合、衛星は最初にそれを受信し、信号が周辺プロセスに関係するかどうかに関係なく、周辺プロセスに信号メッセージを送信します。 周辺コアはメッセージを復号化し、プロセスに信号を送信します。プロセスは通常の方法でそれに反応します。 信号が周辺プロセッサで発信された場合、プロセスは衛星のサービスに頼ることなく標準のアクションを実行します。

周辺プロセスが他の周辺プロセスに信号を送信すると、kill呼び出しメッセージがエンコードされ、サテライトプロセスに送信されます。サテライトプロセスは、呼び出された関数をローカルで実行します。 信号の対象となるプロセスの一部が他の周辺プロセッサにある場合、それらの衛星は信号を受信します（そして上記のようにそれに反応します）。

13.2通信タイプのニューキャッスル

前のセクションでは、周辺プロセッサで発生するファイル管理サブシステムの機能へのすべての呼び出しをリモート（中央）プロセッサに送信することを特徴とする、密結合システムのタイプについて検討しました。 次に、他のマシンにあるファイルを呼び出すマシンで構成される、接続が弱いシステムについて検討します。 たとえば、パーソナルコンピュータとワークステーションのネットワークでは、ユーザーは大規模なマシンにあるファイルにアクセスすることがよくあります。 次の2つのセクションでは、すべてのシステム機能がローカルサブシステムで実行されるシステム構成について説明しますが、同時に、他のマシンにあるファイルに（ファイル管理サブシステムの機能を介して）アクセスすることもできます。

これらのシステムは、次の2つのパスのいずれかを使用して、削除されたファイルを識別します。 一部のシステムでは、特殊文字が複合ファイル名に追加されます。この文字の前にある名前コンポーネントはマシンを識別し、残りの名前はそのマシン上のファイルです。 だから、例えば、識別名

"sftig！/ fs1 / mjb / rje"

マシン「sftig」上のファイル「/ fs1 / mjb / rje」を識別します。 このファイル識別スキームは、UNIXライクなシステム間でファイルを転送するためのuucp規則に従います。 別のスキームでは、削除されたファイルは、名前に特別なプレフィックスを追加することによって識別されます。次に例を示します。

/../sftig/fs1/mjb/rje

ここで、「/../」はファイルが削除されたことを示すプレフィックスです。 ファイル名の2番目のコンポーネントは、リモートマシンの名前です。 このスキームは、使い慣れたUNIXファイル名構文を使用するため、最初のスキームとは異なり、ユーザープログラムは、通常とは異なる構造の名前の使用に適応する必要はありません（を参照）。

図13.9。 ファイルサーバー（プロセッサ）へのリクエストの作成

このセクションの残りの部分では、カーネルが削除されたファイルの認識に関与しない、Newcastleリンクを使用するシステムのモデルについて説明します。 この関数は、標準Cライブラリのサブルーチンに完全に割り当てられています。この場合、サブルーチンはシステムインターフェイスの役割を果たします。 これらのルーチンは、ファイル名の最初のコンポーネントを分析します。これには、説明されている両方の識別方法で、ファイルのリモート性の兆候が含まれています。 これは、ライブラリルーチンがファイル名を解析しないルーチンからの逸脱です。 図13.9は、ファイルサーバーへの要求がどのように作成されるかを示しています。 ファイルがローカルの場合、ローカルシステムカーネルは要求を通常どおり処理します。 反対の場合を考えてみましょう。

開く（ "/../ sftig / fs1 / mjb / rje / file"、O_RDONLY）;

Cライブラリのopenサブルーチンは、識別されたファイル名の最初の2つのコンポーネントを解析し、リモートマシン「sftig」でファイルを検索することを認識しています。 プロセスが以前に特定のマシンと接続していたかどうかに関する情報を取得するために、サブルーチンはこの事実を記憶する特別な構造を開始し、否定的な回答の場合は、リモートマシンで実行されているファイルサーバーとの接続を確立します。 プロセスがリモート処理の最初の要求を作成するとき、リモートサーバーは要求を確認し、必要に応じて、ユーザーとグループの識別コードのフィールドに記録し、クライアントプロセスに代わって動作するサテライトプロセスを作成します。

クライアントの要求を満たすには、サテライトはリモートマシン上でクライアントと同じファイル権限を持っている必要があります。 つまり、ユーザー「mjb」は、リモートファイルとローカルファイルの両方に対して同じアクセス権を持っている必要があります。 残念ながら、「mjb」クライアント識別コードがリモートマシン上の別のクライアントの識別コードと一致する可能性があります。 したがって、ネットワーク上で実行されているマシンのシステム管理者は、各ユーザーにネットワーク全体に固有の識別コードが割り当てられていることを確認するか、ネットワークサービス要求の作成時にコード変換を実行する必要があります。 これが行われない場合、コンパニオンプロセスは、リモートマシン上の別のクライアントの権限を持ちます。

よりデリケートな問題は、リモートファイルの操作に関連してスーパーユーザー権限を取得することです。 一方では、スーパーユーザークライアントは、リモートシステムのセキュリティ制御を誤解させないように、リモートシステムに対して同じ権限を持ってはなりません。 一方、一部のプログラムは、スーパーユーザー権限が付与されていない場合、単に機能しません。 このようなプログラムの例は、新しいディレクトリを作成するmkdirプログラム（第7章を参照）です。 スーパーユーザー権限は削除時に有効ではないため、リモートシステムはクライアントが新しいディレクトリを作成することを許可しません。 リモートディレクトリの作成の問題は、ユーザーに必要なすべての接続を自動的に確立する機能を拡張する方向にシステム関数mkdirを改訂する重大な理由として機能します。 ただし、setuidプログラム（mkdirプログラムなど）がリモートファイルに対するスーパーユーザー特権を取得することは、依然として一般的な問題です。 おそらく、この問題の最善の解決策は、リモートスーパーユーザーによるファイルへのアクセスを説明するファイルに追加の特性を設定することです。 残念ながら、これには（新しいフィールドの追加に関して）ディスクインデックス構造の変更が必要になり、既存のシステムで混乱が生じすぎます。

オープンサブルーチンが成功すると、ローカルライブラリは、ネットワークノードのアドレス、サテライトプロセスのプロセスID、ファイル記述子、およびその他の同様の情報を含むユーザーアクセス可能な構造に、これに関する対応するメモを残します。 ライブラリルーチンの読み取りと書き込みは、ファイル記述子に基づいて、ファイルが削除されているかどうかを判断し、削除されている場合は、衛星にメッセージを送信します。 クライアントプロセスは、リモートマシンのサービスを必要とするシステム機能にアクセスするすべての場合に、そのコンパニオンと対話します。 プロセスが同じリモートマシンにある2つのファイルにアクセスする場合、1つのサテライトを使用しますが、ファイルが異なるマシンにある場合、2つのサテライトがすでに使用されています（各マシンに1つ）。 2つのプロセスがリモートマシン上のファイルにアクセスする場合にも、2つの衛星が使用されます。 衛星を介してシステム機能を呼び出すことにより、プロセスは、周辺プロセッサを備えたシステムのメッセージ構造に含まれるものと同様に、機能番号、検索パスの名前、およびその他の必要な情報を含むメッセージを生成します。

現在のディレクトリで操作を実行するためのメカニズムはより複雑です。 プロセスが現在のディレクトリとしてリモートディレクトリを選択すると、ライブラリルーチンはサテライトにメッセージを送信します。これにより、現在のディレクトリが変更され、ルーチンはディレクトリが削除されたことを記憶します。 検索パス名がスラッシュ（/）以​​外の文字で始まる場合はすべて、サブルーチンは名前をリモートマシンに送信し、そこでサテライトプロセスが現在のディレクトリから名前をルーティングします。 現在のディレクトリがローカルの場合、ルーチンは単に検索パス名をローカルシステムカーネルに渡します。 リモートディレクトリのシステムchroot関数も同様ですが、ローカルカーネルでは見過ごされます。 厳密に言えば、ライブラリのみが実行を記録するため、プロセスはこの操作を無視できます。

プロセスがforkを呼び出すと、適切なライブラリルーチンが各衛星にメッセージを送信します。 サテライトプロセスは分岐し、子IDを親クライアントに送信します。 クライアントプロセスは、フォークシステム関数を実行します。この関数は、生成した子に制御を移します。 ローカルの子は、ライブラリルーチンによってアドレスが保存されているリモートのサテライトの子と対話しています。 フォーク機能のこの解釈により、衛星プロセスが開いているファイルと現在のディレクトリを簡単に制御できるようになります。 リモートファイルを処理するプロセスが終了すると（exit関数を呼び出すことにより）、サブルーチンはすべてのリモートサテライトにメッセージを送信し、メッセージを受信したときに同じことを実行します。 演習では、execおよびexitシステム関数の実装の特定の側面について説明します。

Newcastleリンクの利点は、システムカーネルに変更を加えることなく、リモートファイルへのプロセスのアクセスが透過的になる（ユーザーには見えない）ことです。 ただし、この開発にはいくつかの欠点があります。 まず、実装中にシステムパフォーマンスが低下する可能性があります。 拡張Cライブラリを使用しているため、プロセスがリモートファイルにアクセスしなくても、各プロセスで使用されるメモリのサイズが大きくなります。 ライブラリはカーネル関数を複製し、より多くのメモリスペースを必要とします。 プロセスのサイズを大きくすると、起動期間が長くなり、メモリリソースの競合が増える可能性があり、タスクのアンロードとページングをより頻繁に行うための条件が作成されます。 カーネルへの各呼び出しの期間が長くなるため、ローカルリクエストの実行速度が遅くなり、リモートリクエストの処理も遅くなる可能性があり、ネットワーク経由でリクエストを送信するコストが高くなります。 ユーザーレベルでのリモートリクエストの追加処理により、コンテキストスイッチ、アンロード、およびスワッピング操作の数が増加します。 最後に、リモートファイルにアクセスするには、新しいライブラリを使用してプログラムを再コンパイルする必要があります。 古いプログラムと提供されたオブジェクトモジュールは、それなしではリモートファイルを操作できません。 これらの欠点はすべて、次のセクションで説明するシステムにはありません。

13.3「透明な」分散ファイルシステム

「透過的割り当て」という用語は、あるファイルシステムから別のファイルシステムに切り替えてマウントポイントを通過するときと同じように、あるマシンのユーザーがマシンの境界を越えていることに気付かずに別のマシンのファイルにアクセスできることを意味します。 プロセスがリモートマシンにあるファイルを参照するための名前は、ローカルファイルの名前と似ています。それらには、特徴的な文字はありません。 図13.10に示す構成では、マシンBに属するディレクトリ "/ usr / src"はマシンAに属するディレクトリ "/ usr / src"に "マウント"されています。同じシステムソースコードで、従来は "/ usr / src "ディレクトリ。 マシンAで実行されているユーザーは、ファイル名を書き込む通常の構文（たとえば、「/ usr / src / cmd / login.c」）を使用してマシンBにあるファイルにアクセスでき、カーネル自体がファイルがリモートかローカルかを決定します。 。 マシンBで実行されているユーザーはローカルファイルにアクセスできますが（マシンAのユーザーが同じファイルにアクセスできることに気づいていません）、マシンAにあるファイルにはアクセスできません。もちろん、他のオプションも可能です。特に、すべてのリモートシステムがローカルシステムのルートにマウントされているため、ユーザーはすべてのシステム上のすべてのファイルにアクセスできます。

図13.10。 リモートマウント後のファイルシステム

ローカルファイルシステムのマウントとリモートファイルシステムへのアクセスの許可の類似点により、マウント機能をリモートファイルシステムに適合させることができました。 この場合、カーネルには拡張フォーマットのマウントテーブルがあります。 カーネルはマウント機能を実行して、リモートマシンとのネットワーク接続を整理し、この接続を特徴付ける情報をマウントテーブルに格納します。

興味深い問題は、「..」を含むパス名に関係しています。 プロセスがリモートファイルシステムから現在のディレクトリを作成する場合、名前に「..」文字を使用すると、現在のディレクトリより上のファイルにアクセスするのではなく、プロセスがローカルファイルシステムに戻る可能性が高くなります。 再び図13.10に戻ると、リモートファイルシステムにある現在のディレクトリ「/ usr / src / cmd」を以前に選択したマシンAに属するプロセスが、コマンドを実行することに注意してください。

現在のディレクトリは、マシンBではなくマシンAのルートディレクトリになります。リモートシステムのカーネルのnameiアルゴリズムは、文字「..」のシーケンスを受信した後、呼び出し元のプロセスがクライアントプロセスのエージェントであるかどうかを確認します。 、および設定されている場合は、クライアントが現在の作業ディレクトリをリモートファイルシステムのルートとして扱っているかどうかを設定します。

リモートマシンとの通信は、リモートプロシージャコールまたはリモートシステム関数コールの2つの形式のいずれかを取ります。 最初の形式では、インデックスを処理する各カーネルプロシージャは、インデックスがリモートファイルを指しているかどうかを確認し、指している場合は、指定された操作を実行するようにリモートマシンに要求を送信します。 このスキームは、第5章の最後の部分で説明する、さまざまなタイプのファイルシステムのサポートの抽象的な構造に自然に適合します。したがって、リモートファイルにアクセスすると、ネットワークを介して複数のメッセージの送信を開始できます。ネットワークで受け入れられる待機時間を考慮して、ファイルに対する暗黙の操作の数と、それに対応する要求への応答時間の増加によって決定されます。 リモート操作の各セットには、少なくともインデックスロック、参照カウントなどのアクションが含まれます。モデルを改善するために、複数の操作を1つのクエリ（メッセージ）に結合し、最も重要なデータ（cm）をバッファリングすることに関連するさまざまな最適化ソリューションが提案されました。 ）。

図13.11。 リモートファイルを開く

リモートファイル「/usr/src/cmd/login.c」を開くプロセスについて考えてみます。ここで、「src」はマウントポイントです。 （namei-igetスキームを使用して）ファイル名を解析することにより、カーネルはファイルが削除されたことを検出し、ロックされたインデックスを取得するための要求をホストマシンに送信します。 目的の回答を受け取ると、ローカルカーネルはリモートファイルに対応するインデックスのコピーをメモリに作成します。 次に、カーネルは、リモートマシンに別のメッセージを送信することにより、ファイルへの必要なアクセス権（読み取りなど）を確認します。 オープンアルゴリズムは、アルゴリズムが完了してインデックスが解放されるまで、第5章で概説されている計画に従って、必要に応じてリモートマシンにメッセージを送信し続けます。 オープンアルゴリズムの完了時のカーネルデータ構造間の関係を図13.11に示します。

クライアントが読み取りシステム関数を呼び出すと、クライアントカーネルはローカルインデックスをロックし、リモートインデックスのロック、読み取り要求を発行し、データをローカルメモリにコピーし、リモートインデックスを解放する要求を発行し、ローカルインデックスを解放します。 。 このスキームは、既存のユニプロセッサカーネルのセマンティクスと一致していますが、ネットワークの使用頻度（各システム関数への複数の呼び出し）により、システム全体のパフォーマンスが低下します。 ただし、ネットワーク上のメッセージのフローを減らすために、複数の操作を1つの要求に組み合わせることができます。 読み取り関数を使用した例では、クライアントはサーバーに1つの一般的な「読み取り」要求を送信でき、サーバー自体が実行時にインデックスを取得して解放することを決定します。 ネットワークトラフィックの削減は、リモートバッファーを使用することでも実現できますが（前述のとおり）、これらのバッファーを使用するシステムファイル機能が正しく実行されるように注意する必要があります。

リモートマシンとの通信の2番目の形式（リモートシステム関数の呼び出し）では、ローカルカーネルは、システム関数がリモートファイルに関連していることを検出し、呼び出しで指定されたパラメーターをリモートシステムに送信します。リモートシステムは、関数を実行し、結果をクライアントに返します。 クライアントマシンは、関数の実行結果を受け取り、呼び出し状態を終了します。 ほとんどのシステム機能は、1つのネットワーク要求のみを使用して実行でき、妥当な時間後に応答を受信しますが、すべての機能がこのモデルに適合するわけではありません。 したがって、たとえば、特定の信号を受信すると、カーネルは「コア」と呼ばれるプロセス用のファイルを作成します（第7章）。 このファイルの作成は特定のシステム機能に関連付けられていませんが、ファイルの作成、アクセス許可の確認、一連の書き込みの実行など、いくつかの操作を実行することになります。

オープンシステム機能の場合、リモートマシンに送信された機能の実行要求には、リモートファイルを区別する検索パス名コンポーネントを除いた後に残ったファイル名の部分と、さまざまなフラグが含まれます。 ファイル「/usr/src/cmd/login.c」を開く前の例では、カーネルは「cmd /login.c」という名前をリモートマシンに送信します。 このメッセージには、リモートマシンでファイルのアクセス許可を確認するために必要な、ユーザーやグループの識別コードなどの資格情報も含まれています。 オープン機能が成功したことを示す応答をリモートマシンから受信すると、ローカルカーネルはローカルマシンのメモリに空きインデックスをフェッチし、それをリモートファイルインデックスとしてマークし、リモートマシンとリモートインデックスに関する情報を格納します。ファイルテーブルに新しいエントリを定期的に割り当てます。 リモートマシンの実際のインデックスと比較すると、ローカルマシンが所有するインデックスは正式であり、モデルの構成に違反しません。これは、リモートプロシージャを呼び出すときに使用される構成とほぼ同じです（図13.11）。 プロセスによって呼び出された関数が記述子によってリモートファイルにアクセスする場合、ローカルカーネルは（ローカル）インデックスからファイルがリモートであることを認識し、呼び出された関数を含む要求を作成して、リモートマシンに送信します。 リクエストには、サテライトプロセスがリモートファイル自体を識別できるリモートインデックスへのポインタが含まれています。

システム関数の実行結果を受け取ったカーネルは、特別なプログラムのサービスを利用してそれを処理できます（完了すると、カーネルは関数の処理を終了します）。これは、結果のローカル処理がユニプロセッサシステムで使用されるためです。複数のプロセッサを搭載したシステムに常に適しているとは限りません。 その結果、リモートシステム機能の実行をサポートすることを目的として、システムアルゴリズムのセマンティクスを変更することができます。 ただし、同時に、メッセージの最小フローがネットワーク内を循環し、着信要求に対するシステムの最小応答時間を確保します。

13.4転送プロセスのない分散モデル

透過分散システムで転送プロセス（サテライトプロセス）を使用すると、削除されたファイルを追跡しやすくなりますが、リモートシステムのプロセステーブルは、ほとんどの時間アイドル状態のサテライトプロセスで過負荷になります。 他のスキームでは、特別なサーバープロセスを使用してリモートリクエストを処理します（およびを参照）。 リモートシステムには、着信リモート要求を処理するために時々割り当てるサーバープロセスのセット（プール）があります。 要求を処理した後、サーバープロセスはプールに戻り、他の要求を処理する準備ができた状態になります。 サーバーは、複数のプロセスからの要求を一度に処理できるため、2つの呼び出し間でユーザーコンテキストを保存しません。 したがって、クライアントプロセスから到着する各メッセージには、その実行環境に関する情報、つまり、ユーザー識別コード、現在のディレクトリ、シグナルなどの機能が含まれている必要があります。

プロセスがリモートファイルを開くと、リモートカーネルはファイルへの後続のリンクにインデックスを割り当てます。 ローカルマシンは、カスタムファイル記述子テーブル、ファイルテーブル、および通常のレコードセットを持つインデックステーブルを維持し、インデックステーブルエントリはリモートマシンとリモートインデックスを識別します。 システム機能（読み取りなど）がファイル記述子を使用する場合、カーネルは以前に割り当てられたリモートインデックスを指すメッセージを送信し、プロセス関連の情報（ユーザー識別コード、最大ファイルサイズなど）を転送します。サーバープロセスを自由に使用できる場合、クライアントとの対話は前述の形式を取りますが、クライアントとサーバー間の接続は、システム機能の期間中のみ確立されます。

衛星プロセスの代わりにサーバーを使用すると、データトラフィック、信号、およびリモートデバイスの管理がより困難になる可能性があります。 十分な数のサーバーがない場合のリモートマシンへの多数の要求は、キューに入れる必要があります。 これには、メインネットワークで使用されているものよりも上位のプロトコルが必要です。 一方、衛星モデルでは、すべてのクライアント要求が同期的に処理されるため、過飽和が解消されます。 クライアントは、最大で1つの要求を保留にすることができます。

サーバーを使用する場合、リモートマシンは機能の実行を提供する適切なサーバーを検索する必要があるため、システム機能の実行を中断する信号の処理も複雑になります。 すべてのサーバーがビジー状態であるために、システム機能の要求が処理を保留している可能性もあります。 サーバーがシステム機能の結果を呼び出しプロセスに返し、サーバーの応答にネットワークを介した対応するシグナリングメッセージの送信が含まれる場合にも、競合が発生する条件が発生します。 リモートシステムがメッセージを認識し、必要に応じてサーバープロセスを終了できるように、各メッセージにマークを付ける必要があります。 衛星を使用する場合、クライアントの要求の履行を処理するプロセスが自動的に識別され、信号が到着した場合、要求が処理されたかどうかを確認することは難しくありません。

最後に、クライアントによって呼び出されたシステム関数によってサーバーが無期限に一時停止した場合（たとえば、リモート端末からデータを読み取る場合）、サーバーは他の要求を処理してサーバープールを解放できません。 複数のプロセスが一度にリモートデバイスにアクセスし、サーバーの数が上から制限されている場合、かなり具体的なボトルネックがあります。 サテライトは各クライアントプロセスに割り当てられるため、これはサテライトでは発生しません。 リモートデバイスにサーバーを使用する際の別の問題については、演習13.14で説明します。

サテライトプロセスの使用が提供する利点にもかかわらず、実際にはプロセステーブルへの無料エントリの必要性が非常に深刻になるため、ほとんどの場合、サーバープロセスのサービスは依然としてリモートリクエストの処理に使用されます。

図13.12。 カーネルレベルでのリモートファイルとの相互作用の概念図

13.5結論

この章では、リモートファイルシステムをローカルファイルシステムの拡張として扱い、リモートマシンにあるファイルを操作するための3つのスキームについて検討しました。 これらのレイアウト間のアーキテクチャの違いを図13.12に示します。 これらはすべて、前の章で説明したマルチプロセッサシステムとは異なり、ここでのプロセッサは物理メモリを共有しません。 周辺プロセッサシステムは、中央処理装置のファイルリソースを共有する密結合されたプロセッサのセットで構成されています。 Newcastleタイプの接続は、リモートファイルへの非表示（「透過的」）アクセスを提供しますが、オペレーティングシステムカーネルではなく、特別なCライブラリを使用します。 このため、このタイプのリンクを使用する予定のすべてのプログラムを再コンパイルする必要があります。これは、一般に、このスキームの重大な欠点です。 ファイルの遠隔性は、ファイルが置かれているマシンを説明する特別な文字シーケンスを使用して示されます。これは、プログラムの移植性を制限するもう1つの要因です。

透過分散システムでは、マウントシステム機能の変更を使用してリモートファイルにアクセスします。 ローカルシステムのインデックスはリモートファイルとしてマークされ、ローカルカーネルは、要求されたシステム機能、そのパラメータ、およびリモートインデックスを説明するメッセージをリモートシステムに送信します。 「透過的」分散システムでの通信は、リモートプロシージャへの呼び出し（インデックスに関連付けられた操作のリストを含むメッセージがリモートマシンに送信される）の形式と呼び出しの形式の2つの形式でサポートされます。リモートシステム機能へ（メッセージは要求された機能を説明します）。 この章の最後の部分では、衛星プロセスとサーバーを使用したリモートリクエストの処理に関連する問題について説明します。

13.6演習

* 1。 周辺プロセッサーを備えたシステムでの出口システム機能の実装について説明してください。 この場合と、キャッチされていない信号を受信して​​プロセスが終了する場合の違いは何ですか？ カーネルはメモリの内容をどのようにダンプする必要がありますか？

2.プロセスはSIGKILLシグナルを無視できません。 プロセスがそのような信号を受信したときに周辺システムで何が起こるかを説明します。

* 3。 周辺プロセッサを搭載したシステムでのexecシステム関数の実装について説明します。

* 4。 全体的な負荷のバランスを取るために、中央処理装置は周辺プロセッサ間でプロセスをどのように分散する必要がありますか？

* 5。 周辺プロセッサにオフロードされたすべてのプロセスを収容するのに十分なメモリがない場合はどうなりますか？ ネットワーク内のプロセスのアンロードとスワッピングはどのように行う必要がありますか？

6.ファイル名に特別なプレフィックスが見つかった場合に、リモートファイルサーバーへのリクエストが送信されるシステムについて考えてみます。 プロセスにexecl（ "/../ sftig / bin / sh"、 "sh"、0）;を呼び出させます。 実行可能ファイルはリモートマシン上にありますが、ローカルシステム上で実行されている必要があります。 リモートモジュールがローカルシステムにどのように移行されるかを説明します。

7.管理者がNewcastleのような接続で既存のシステムに新しいマシンを追加する必要がある場合、これについてCライブラリモジュールに通知する最良の方法は何ですか？

*8。 exec関数の実行中に、カーネルは、リモートファイルへのリンクを追跡するためにNewcastleリンクによって使用されるライブラリテーブルを含む、プロセスのアドレス空間を上書きします。 関数の実行後、プロセスは古い記述子によってこれらのファイルにアクセスする機能を保持する必要があります。 この点の実装について説明してください。

*九。 セクション13.2に示すように、Newcastle接続のあるシステムでexitシステム関数を呼び出すと、コンパニオンプロセスにメッセージが送信され、コンパニオンプロセスが強制的に終了します。 これは、ライブラリルーチンのレベルで行われます。 ローカルプロセスがカーネルモードで終了するように指示するシグナルを受信するとどうなりますか？

*十。 Newcastleリンクのあるシステムでは、名前の前に特別なプレフィックスを付けることでリモートファイルが識別されますが、ファイル名コンポーネントとして「..」（親ディレクトリ）を指定したユーザーは、リモートマウントポイントをどのように通過できますか？

11.第7章から、さまざまなシグナルによってプロセスがメモリの内容を現在のディレクトリにダンプすることがわかります。 現在のディレクトリがリモートファイルシステムからのものである場合はどうなりますか？ システムがニューカッスルのような関係を使用している場合、どのような答えを出しますか？

* 12。 すべての衛星またはサーバープロセスがシステムから削除された場合、ローカルプロセスにどのような影響がありますか？

* 13。 透過的な分散システムにリンクアルゴリズムを実装する方法を検討してください。そのパラメーターは、2つのリモートファイル名と、いくつかの内部読み取り操作の実行に関連付けられたexecアルゴリズムにすることができます。 リモートプロシージャコールとリモートシステム関数コールの2つの形式の通信について考えてみます。

* 14。 デバイスにアクセスすると、サーバープロセスは一時停止状態になり、デバイスドライバーによってそこから取り出されます。 当然、サーバーの数が制限されている場合、システムはローカルマシンの要求を満たすことができなくなります。 デバイス関連のI / Oが完了するのを待っている間、すべてのサーバープロセスが中断されるわけではないという信頼できるスキームを考え出します。 すべてのサーバーがビジー状態の間、システム機能は終了しません。

図13.13。 ターミナルサーバーの構成

* 15。 ユーザーがシステムにログインすると、端末回線の規律には、端末がプロセスのグループをリードするオペレーター端末であるという情報が格納されます。 このため、ユーザーがターミナルキーボードの「ブレーク」キーを押すと、グループ内のすべてのプロセスが割り込み信号を受信します。 すべての端末が1台のマシンに物理的に接続されているが、ユーザー登録は他のマシンに論理的に実装されているシステム構成を考えてみます（図13.13）。 いずれの場合も、システムはリモート端末のgettyプロセスを作成します。 リモートシステムへの要求が一連のサーバープロセスによって処理される場合、openプロシージャが実行されると、サーバーは接続の待機を停止することに注意してください。 open関数が完了すると、サーバーはサーバープールに戻り、端末への接続を切断します。 同じグループに含まれるプロセスのアドレスに送信される「ブレーク」キーを押すことによって、割り込み信号はどのようにトリガーされますか？

* 16。 メモリの共有は、ローカルマシンに固有の機能です。 論理的な観点から、物理メモリの共通領域（ローカルまたはリモート）の割り当ては、異なるマシンに属するプロセスに対して実行できます。 この点の実装について説明してください。

* 17。 第9章で説明されているプロセスページングおよびページングアルゴリズムは、ローカルページャーの使用を前提としています。 リモートオフロードデバイスをサポートできるようにするには、これらのアルゴリズムにどのような変更を加える必要がありますか？

* 18。 リモートマシン（またはネットワーク）で致命的なクラッシュが発生し、ローカルネットワーク層プロトコルがこの事実を記録するとします。 リモートサーバーに要求を行うローカルシステムの回復スキームを開発します。 さらに、クライアントとの接続を失ったサーバーシステムの回復スキームを開発します。

* 19。 プロセスがリモートファイルにアクセスすると、プロセスがファイルを検索するために複数のマシンをトラバースする可能性があります。 例として「/ usr / src / uts / 3b2 / os」という名前を取ります。ここで、「/ usr」はマシンAに属するディレクトリ、「/ usr / src」はマシンBのルートのマウントポイントです。 / usr / src / uts / 3b2 "は、マシンCのルートのマウントポイントです。複数のマシンを通過して最終的な宛先に到達することをマルチホップと呼びます。 ただし、マシンAとマシンCの間に直接ネットワーク接続がある場合、マシンBを介してデータを送信することは非効率的です。 Newcastle接続を備えたシステムおよび「透過的」分散システムでの「マルチショッピング」の実装の機能について説明します。

現在、商用目的で開発されたISはすべて分散アーキテクチャを備えています。これは、グローバルおよび/またはローカルエリアネットワークの使用を意味します。

歴史的に、ファイルサーバーアーキテクチャは、そのロジックが単純であり、すでに使用されているISをそのようなアーキテクチャに転送するのが最も簡単であるため、最初に普及しました。 次に、サーバークライアントアーキテクチャに変換されました。これは、論理的な継続として解釈できます。 グローバルネットワークインターネットで使用されている最新のシステムは、主に分散オブジェクトのアーキテクチャに関連しています（図を参照）。 III‑15 )

ISは、次のコンポーネントで構成されていると想像できます（図III-16）。

III.03.2。 ファイルサーバーアプリケーション。

これは歴史的に最初の分散アーキテクチャです（図III-17）。 それは非常に単純に構成されています。サーバー上にはデータのみがあり、それ以外はすべてクライアントマシンに属しています。 ローカルネットワークは非常に安価であり、このようなアーキテクチャではアプリケーションソフトウェアが自律的であるため、今日ではこのようなアーキテクチャがよく使用されています。 これは、データファイルのみがサーバー上に配置されるクライアントサーバーアーキテクチャの変形であると言えます。 異なるパーソナルコンピュータは、共通のデータストアを介してのみ相互作用するため、1台のコンピュータ用に作成されたプログラムは、このようなアーキテクチャに適応するのが最も簡単です。

長所：

ファイルサーバーアーキテクチャの長所：

整理のしやすさ;

整合性と信頼性を維持するためにデータベースに必要な要件と矛盾しません。

ネットワークの混雑;

リクエストに対する予測できない応答。

これらの欠点は、データベースへの要求がネットワークを介した大量の情報の転送につながるという事実によって説明されます。 たとえば、テーブルから1つまたは複数の行を選択するには、テーブル全体がクライアントマシンにダウンロードされ、DBMSはすでにそこで選択しています。 重要なネットワークトラフィックは、データベースへのリモートアクセスの編成に特に関係しています。

III.03.2。 bクライアントサーバーアプリケーション。

この場合、サーバーとクライアントの間で責任が分散されます。 それらがどのように分離されているかに応じて区別します 太いと シン・クライアント.

シンクライアントモデルでは、すべてのアプリケーション作業とデータ管理はサーバー上で行われます。 これらのシステムのユーザーインターフェイスはパーソナルコンピュータに「移行」し、ソフトウェアアプリケーション自体がサーバーの機能を実行します。 すべてのアプリケーションプロセスを実行し、データを管理します。 シンクライアントモデルは、クライアントがコンピューターまたはワークステーションである場合にも実装できます。 ネットワークデバイスは、インターネットブラウザとシステム内に実装されたユーザーインターフェイスを実行します。

主要 欠陥シンクライアントモデル-サーバーとネットワークの負荷が高い。 すべての計算はサーバー上で実行されます。これにより、クライアントとサーバー間のネットワークトラフィックが大幅に増加する可能性があります。 現代のコンピューターには十分な計算能力がありますが、銀行のモデル/シンクライアントでは実際には使用されていません

対照的に、シッククライアントモデルはローカルマシンの処理能力を使用します。アプリケーション自体はクライアントコンピューターに配置されます。 このタイプのアーキテクチャの例は、ATMがクライアントであり、サーバーが顧客アカウントデータベースにサービスを提供する中央コンピューターであるATMシステムです。

III.03.2。 c2層および3層のクライアントサーバーアーキテクチャ。

上記で説明したアーキテクチャはすべて2層です。 これらは、クライアントレベルとサーバーレベルを区別します。 厳密に言えば、ICは3つの論理レベルで構成されています。

・ユーザーレベル。

アプリケーションレベル：

・データ層。

したがって、2層のみが関与する2層モデルでは、シンクライアントモデルを選択した場合はスケーラビリティとパフォーマンスの問題が発生し、シッククライアントモデルを選択した場合はシステム管理の問題が発生します。 これらの問題は、2つのレベルがサーバーである3つのレベルで構成されるモデルを適用することで回避できます（図III-21）。

データサーバー

実際、アプリケーションサーバーとデータサーバーは同じマシン上に配置できますが、相互に機能を実行することはできません。 3層モデルの良いところは、アプリケーションの実行とデータ管理を論理的に分離していることです。

表III-5さまざまなタイプのアーキテクチャの適用

建築	応用
2層シンクライアント	1アプリケーションの実行とデータ管理を分離することが推奨されないレガシーシステム。 2データ管理をほとんど行わずに集中的なアプリケーションを計算します。 3大量のデータがあり、計算が少ないアプリケーション。
2層シッククライアント	1ユーザーが集中的なデータ処理、つまりデータの視覚化を必要とするアプリケーション。 2適切に管理されたシステム環境に適用される、比較的一定のユーザー機能のセットを持つアプリケーション。
3層サーバークライアント	1セルと数千のクライアントを備えた大規模なアプリケーション2データと処理方法の両方が頻繁に変更されるアプリケーション。 3複数のソースからのデータを統合するアプリケーション。

このモデルは多くの種類のアプリケーションに適していますが、サービスを提供する場所を決定し、スケーラビリティのサポートを提供し、新しい顧客を接続するためのツールを開発する必要があるIS開発者を制限します。

III.03.2。 d分散オブジェクトアーキテクチャ。

より一般的なアプローチは、オブジェクトが主要なコンポーネントである分散オブジェクトアーキテクチャによって提供されます。 それらは、インターフェースを介して一連のサービスを提供します。 他のオブジェクトは、クライアントとサーバーを区別せずにリクエストを送信します。 オブジェクトは、ネットワーク内のさまざまなコンピューターに配置でき、システムバスと同様にミドルウェアを介して対話できます。これにより、さまざまなデバイスを接続し、ハードウェアデバイス間の通信をサポートできます。

…

ODBCドライバーマネージャー

ドライバー1

ドライバーK

DB 1

DB K

SQLの操作

…

ODBCアーキテクチャには次のコンポーネントが含まれます。

1.アプリケーション（例：IS）。 タスクを実行します。データソースへの接続を要求し、SQLクエリをデータソースに送信し、SQLクエリのストレージ領域と形式を記述し、エラーを処理してユーザーに通知し、トランザクションをコミットまたはロールバックし、への接続を要求します。情報源。

2.デバイスマネージャー。 アプリケーションの要求に応じてドライバーをロードし、すべてのアプリケーションに単一のインターフェイスを提供します。ODBC管理者インターフェイスは同じであり、アプリケーションが対話するDBMSに関係ありません。 Microsoftが提供するDriverManagerは、ダイナミックロードライブラリ（DLL）です。

3.ドライバーはDBMSに依存します。 ODBCドライバーは、ODBC関数を実装し、データソースと対話するダイナミックリンクライブラリ（DLL）です。 ドライバーは、DBMSに固有の関数（DBMSに従って要求を変更できます）の要求を処理し、その結果をアプリケーションに返すプログラムです。 ODBCテクノロジーをサポートするすべてのDBMSは、アプリケーション開発者にそのDBMSのドライバーを提供する必要があります。

4.データソースには、ユーザーが指定した制御情報、データソースに関する情報が含まれており、特定のDBMSにアクセスするために使用されます。 この場合、OSとネットワークプラットフォームの手段が使用されます。

動的モデル

このモデルは多くの側面を想定しており、UMLでは少なくとも5つの図が使用されています。ppを参照してください。 2.04.2-2.04.5。

管理の側面を考慮してください。 ガバナンスモデルは、構造モデルを補完します。

システムの構造がどのように記述されていても、それは一連の構造単位（関数またはオブジェクト）で構成されます。 それらが全体として機能するためには、それらを制御する必要があり、静的ダイアグラムには制御情報がありません。 制御モデルは、システム間の制御フローを設計します。

ソフトウェアシステムには、主に2つのタイプの制御があります。

1.集中管理。

2.イベントベースの管理。

一元管理には次のようなものがあります。

· 階層的-「コールリターン」の原則に基づいて（これが教育プログラムが最も頻繁に機能する方法です）

· ディスパッチャモデルこれは並列システムに使用されます。

V ディスパッチャモデルシステムのコンポーネントの1つがディスパッチャであると想定されています。 システムの起動とシャットダウンの両方、およびシステム内の残りのプロセスの調整を管理します。 プロセスは互いに並行して実行できます。 プロセスとは、現在実行中のプログラム、サブシステム、またはプロシージャーを指します。 このモデルは、制御プログラムがいくつかの状態変数に応じて（オペレーターを介して）個々のサブシステムを呼び出すシーケンシャルシステムにも適用できます。 場合).

イベント管理管理を担当するサブルーチンがないことを前提としています。 制御は、マウスボタンを押す、キーボードを押す、センサーの読み取り値を変更する、タイマーの読み取り値を変更するなどの外部イベントによって実行されます。 各外部イベントはエンコードされ、イベントキューに配置されます。 キュー内のイベントへのリアクションが提供されると、プロシージャ（サブルーチン）が呼び出され、このイベントへのリアクションが実行されます。 システムが反応するイベントは、他のサブシステムまたはシステムの外部環境のいずれかで発生する可能性があります。

このような管理の例は、Windowsでのアプリケーションの編成です。

前述のすべての構造モデルは、集中管理またはイベントベースの管理を使用して実装できます。

ユーザーインターフェース

インターフェースモデルを開発するときは、設計されたソフトウェアのタスクだけでなく、情報の知覚に関連する脳の機能も考慮に入れる必要があります。

III.03.4。 情報の知覚と処理に関連する人の精神物理学的特性。

従来は知覚のプロセッサと呼ぶことができる脳の部分は、意識の関与なしに常に、入ってくる情報を処理し、過去の経験と比較して保存します。

視覚的なイメージが私たちの注意を引くとき、私たちが興味を持っている情報は短期記憶に到着します。 私たちの注意が引き付けられなかった場合、ストレージ内の情報は消え、次の部分に置き換えられます。

いつでも注意の焦点を一点に固定できるので、複数の状況を同時に追跡する必要が生じた場合、焦点は追跡されたオブジェクトから別のオブジェクトに移動します。 同時に、注意が散らばり、細部が見落とされる可能性があります。 知覚が主に動機に基づいていることも重要です。

フレームを変更すると、脳はしばらくブロックされます。脳は新しい画像をマスターし、最も重要な詳細を強調します。 つまり、ユーザーからの迅速な対応が必要な場合は、写真を急に変更しないでください。

短期記憶は、人の情報処理システムのボトルネックです。 その容量は7±2の接続されていないオブジェクトです。 未請求の情報は30秒以内に保存されます。 私たちにとって重要な情報を忘れないようにするために、私たちは通常、それを自分自身に繰り返し、短期記憶の情報を更新します。 したがって、インターフェースを設計する際には、圧倒的多数が、たとえば、別の画面で5桁を超える数字を覚えて入力することが難しいと感じることに留意する必要があります。

長期記憶の容量と保存時間は無制限ですが、情報へのアクセスは簡単ではありません。 長期記憶から情報を抽出するためのメカニズムは、本質的に連想的です。 情報の記憶を改善するために、それはメモリがすでに保存しているデータに結び付けられており、簡単に取得できます。 長期記憶へのアクセスは難しいので、ユーザーが情報を覚えているのではなく、ユーザーがそれを認識することを期待することをお勧めします。

III.03.4。 bインターフェースを評価するための基本的な基準

主要なソフトウェア開発会社によって実施された多数の調査および調査は、ユーザーがインターフェースを重視していることを示しています。

1）習得と記憶のしやすさ-具体的には、習得の時間と情報と記憶の保存期間を見積もります。

2）システムを使用したときに結果を達成する速度。これは、マウスによって入力または選択されたコマンドと設定の数によって決まります。

3）システムの操作に対する主観的な満足度（使いやすさ、疲労感など）。

さらに、常に同じパッケージを使用するプロのユーザーの場合、2番目と3番目の基準がすぐに最初になります。また、ソフトウェアを定期的に使用し、比較的単純なタスク（1番目と3番目）を実行する非プロのユーザーの場合も同様です。

この観点から、今日、プロのユーザーにとっての最良の特徴は、無料のナビゲーションを備えたインターフェースであり、プロ以外のユーザーにとっては、ダイレクトマニピュレーションインターフェースです。 ファイルコピー操作を実行するとき、他のすべてが同じである場合、ほとんどの専門家はFarのようなシェルを使用し、非専門家はWindowsの「ドラッグアンドドロップ」を使用することに長い間注目されてきました。

III.03.4。 cユーザーインターフェイスの種類

次のタイプのユーザーインターフェイスが区別されます。

原生的

無料ナビゲーション

直接操作。

インターフェースは原始的です

原生的これは、ユーザーとの対話を整理するインターフェイスと呼ばれ、コンソールモードで使用されます。 データが提供するシーケンシャルプロセスからの唯一の逸脱は、複数のデータセットをループすることです。

メニューインターフェイス。

プリミティブインターフェイスとは異なり、ユーザーはプログラムによって表示される特別なリストから操作を選択できます。 これらのインターフェースは、ユーザーが決定する一連のアクションである、多くの作業シナリオの実装を前提としています。 メニューのツリーのような構成は、2つ以上のレベルのメニューでアイテムを見つけるのが難しいことを示唆しています。

（サイト資料http://se.math.spbu.ru）

序章。

今日では、事実上すべての大規模なソフトウェアシステムが配布されています。 分散システム-情報処理を1台のコンピューターに集中させるのではなく、複数のコンピューターに分散させるシステム。 一般的なソフトウェア設計と多くの共通点がある分散システムの設計では、考慮すべきいくつかの詳細がまだあります。

分散システムには6つの主な特徴があります。

1. リソースの共有。 分散システムでは、ハードウェア（ハードドライブ、プリンター）とソフトウェア（ファイル、コンパイラ）の両方のリソースを共有できます。
2. 開放性。これは、新しいリソースを追加することによってシステムを拡張する機能です。
3. 並列処理。分散システムでは、ネットワーク上の異なるコンピューター上で複数のプロセスを同時に実行できます。 これらのプロセスは、実行中に相互作用できます。
4. スケーラビリティ . 下 スケーラビリティ新しいプロパティとメソッドを追加する可能性が理解されています。
5. フォールトトレランス。 複数のコンピューターが存在することにより、情報の複製が可能になり、一部のハードウェアおよびソフトウェアのエラーに対する耐性が得られます。 分散システムは、エラーが発生した場合に部分的な機能をサポートできます。 システムの完全な障害は、ネットワークエラーでのみ発生します。
6. 透明性。ユーザーにはシステム内のリソースへのフルアクセスが提供され、同時にシステム全体のリソースの分散に関する情報はユーザーから隠されます。

分散システムには、いくつかの欠点もあります。

1. 複雑..。 一般に、分散システムの特性を理解して評価することははるかに困難であり、設計、テスト、および保守することもより困難です。 また、システムパフォーマンスは、個々のプロセッサではなく、ネットワークの速度に依存します。 リソースの再割り当てにより、システムの速度が大幅に変わる可能性があります。
2. 安全..。 通常、システムには複数の異なるマシンからアクセスでき、ネットワーク上のメッセージを監視および傍受できます。 したがって、分散システムでは、セキュリティを維持することははるかに困難です。
3. 可制御性..。 システムは、さまざまなバージョンのオペレーティングシステムをインストールできるさまざまなタイプのコンピューターで構成できます。 あるマシンでのエラーは、予測できない方法で他のマシンに伝播する可能性があります。
4. 予測不可能性 ..。 一部のイベントに対する分散システムの反応は予測不可能であり、システムの全負荷、その組織、およびネットワーク負荷に依存します。 これらのパラメータは常に変化する可能性があるため、リクエストへの応答時間は時間と大幅に異なる場合があります。

これらの欠点から、分散システムを設計するときに、開発者が考慮しなければならない多くの問題が発生することがわかります。

1. リソースの識別 ..。 分散システムのリソースは異なるコンピューターに配置されているため、ユーザーが必要なリソースに簡単にアクセスして参照できるように、リソース命名システムを検討する必要があります。 例として、Webページの名前を定義するURL（Uniform Resource Locator）システムがあります。
2. コミュニケーション..。 インターネットの普遍的な操作性と、ほとんどの分散システムのインターネットでのTCP / IPプロトコルの効率的な実装は、コンピューター間の通信を整理する最も効果的な方法の例です。 ただし、特別な性能や信頼性が要求される場合は、専用のツールを使用することができます。
3. システムサービス品質 ..。 このパラメーターは、パフォーマンス、正常性、および信頼性を反映しています。 プロセス、リソース、ハードウェアの分散、システムの適応性など、多くの要因がサービス品質に影響を与えます。
4. ソフトウェアアーキテクチャ ..。 ソフトウェアアーキテクチャは、システムのコンポーネント間でのシステム機能の分散、およびプロセッサ間でのこれらのコンポーネントの分散を記述します。 高品質のシステムサービスを維持する必要がある場合は、適切なアーキテクチャを選択することが重要です。

分散システム設計者にとっての課題は、分散システムに必要なすべての特性を提供するソフトウェアとハ​​ードウェアを設計することです。 これには、さまざまな分散システムアーキテクチャの長所と短所を知る必要があります。 分散システムアーキテクチャには3つのタイプがあります。

1. クライアント/サーバーアーキテクチャ ..。 このモデルでは、システムはサーバーからクライアントに提供される一連のサービスと考えることができます。 このようなシステムでは、サーバーとクライアントは互いに大きく異なります。
2. 3層アーキテクチャ ..。 このモデルでは、サーバーはクライアントに直接サービスを提供するのではなく、ビジネスロジックサーバーを介してサービスを提供します。

最初の2つのモデルについては何度も言われていますが、3番目のモデルについて詳しく見ていきましょう。

1. 分散オブジェクトアーキテクチャ ..。 この場合、サーバーとクライアントの間に違いはなく、システムは相互作用するオブジェクトのセットと考えることができますが、その場所は実際には重要ではありません。 サービスプロバイダーとそのユーザーの間に区別はありません。

このアーキテクチャは今日広く使用されており、 Webサービスアーキテクチャ。 Webサービスは、インターネット経由でアクセス可能で、いくつかのサービスを提供するアプリケーションであり、その形式はプロバイダー（ユニバーサルデータ形式-XMLが使用されているため）および操作のプラットフォームに依存しません。 現在、分散オブジェクトシステムの概念をサポートする3つの異なるテクノロジーがあります。 これらは、EJB、CORBA、およびDCOMテクノロジです。

まず、XMLの一般的な内容について簡単に説明します。 XMLは、Webサービスを提供するために使用される一般的なデータ形式です。 Webサービスは、オープンスタンダードとプロトコル（SOAP、UDDI、WSDL）に基づいています。

1. SOAP（ W3Cによって開発されたSimpleObject Access Protocolは、Webサービスへの要求の形式を定義します。 Webサービスとそのユーザー間のメッセージは、いわゆるSOAPエンベロープ（XMLエンベロープとも呼ばれる）にパッケージ化されます。 メッセージ自体には、何らかのアクションを実行するための要求、またはこのアクションの結果である応答のいずれかを含めることができます。
2. WSDL（Webサービス記述言語）。WebサービスインターフェイスはWSDLドキュメントで説明されています（WSDLはXMLのサブセットです）。 開発者は、サービスをデプロイする前に、WSDL言語で説明を作成し、Webサービスのアドレス、サポートされているプロトコル、許可される操作のリスト、および要求と応答の形式を指定します。
3. UDDI（Universal Description、Discovery and Integration）-インターネットWebサービス検索プロトコル（ http://www.uddi.org/). これは、Webサービスプロバイダーがサービスを登録し、開発者がアプリケーションに含める必要のあるサービスを見つけるビジネスレジストリです。

話からすると、Webサービスが最良で競合のないソリューションであるように思われるかもしれません。唯一の問題は、開発ツールの選択です。 しかし、そうではありません。 Webサービスに代わるものとして、WWWの作成者であるTimBerners-Leeが5年前に話したセマンティックWebがあります。

Webサービスの目標がアプリケーション間の通信を容易にすることである場合、セマンティックWebは、はるかに複雑な問題を解決するように設計されています。メタデータメカニズムを使用して、Web上で見つけることができる情報の価値の効率を高めます。 これは、ドキュメント指向のアプローチを放棄して、オブジェクト指向のアプローチを優先することで実現できます。

参考文献

1. サマービルI.ソフトウェアエンジニアリング。
2. Dranitsa A.Javaと.NET。 -「Computerra」、＃516。
3. インターネットリソース。