###
  • インターネット
  • プログラム
  • ゲーム
  • 問題点
  • ウィンドウズ
  • ソーシャルメディア
  • アンドロイド
  • iOS

    • マルチユーザー データベースを実装するときに使用されるさまざまなアーキテクチャ ソリューション。 サブサブディレクトリの概要

    30.07.2019 モバイルインターネット

    ユーザーの準備

    保護

    サーバー要件

    共有リソース

    ピアツーピア ネットワークでは、各コンピュータは次のことを行う必要があります。

    · コンピューティング リソースのほとんどを提供する ローカルユーザー（このコンピュータの前に座っている人に）

    · リモート ユーザーのリソースへのアクセス (ネットワーク経由でサーバーにアクセス) をサポートするには、追加のコンピューティング リソースを接続します。

    サーバーベースのネットワークでは、ネットワーク上のすべてのクライアントからの要求を処理する必要があるため、より強力なサーバーが必要です。

    基本的な保護には、ディレクトリなどの共有リソースのパスワードの設定が含まれます。 ピアツーピア ネットワークのセキュリティを集中管理することは非常に困難です。これは、各ユーザーがセキュリティを個別にインストールし、「共有」リソースが中央サーバーだけでなくすべてのコンピュータに存在する可能性があるためです。 この状況はネットワーク全体に深刻な脅威をもたらし、一部のユーザーは保護をまったくインストールしない可能性があります。 プライバシーの問題が根本的に重要である場合は、サーバーベースのネットワークを選択することをお勧めします。

    ピアツーピア ネットワークでは、各コンピュータがクライアントとサーバーの両方として機能するため、ユーザーはコンピュータのユーザーと管理者の両方として機能するための十分な知識を持っている必要があります。

    トピック5.2。ネットワークOS。 クライアントサーバー

    クライアントサーバー(クライアントサーバー) - コンピューティングまたは ネットワークアーキテクチャ、どのタスクまたは ネットワーク負荷サーバーと呼ばれるサービスプロバイダー (サービス) とクライアントと呼ばれるサービス顧客の間で分散されます。 多くの場合、クライアントとサーバーはコンピュータ ネットワークを通じて対話し、異なる場合があります。 物理デバイス、およびソフトウェア。

    マルチレベルのクライアント/サーバー アーキテクチャは、データ処理機能が 1 つ以上の個別のサーバーで実行されるクライアント/サーバー アーキテクチャの一種です。 これにより、データの保存、処理、表示の機能を分離して、より多くの作業を行うことができます。 有効活用サーバーとクライアントの機能。

    マルチレベル アーキテクチャの特殊なケース:

    · 3 層アーキテクチャ

    ・専用サーバーネットワーク

    · 専用サーバー ネットワーク (クライアント/サーバー ネットワーク) は、ネットワーク デバイスが 1 つ以上のサーバーによって集中管理され制御されるローカル エリア ネットワーク (LAN) です。 個々のワークステーションまたはクライアント (PC など) は、サーバー経由でネットワーク リソースにアクセスする必要があります。

    ネットワークオペレーティングシステム- コンピュータネットワークで動作するための機能が組み込まれたオペレーティングシステム。 そのような機会には次のようなものがあります。

    ・ サポート ネットワーク機器

    · ネットワークプロトコルのサポート

    · ルーティングプロトコルのサポート

    · フィルタリングのサポート ネットワークトラフィック

    · ネットワーク経由でのプリンタ、ディスクなどのリモート リソースへのアクセスのサポート

    システム内の可用性 ネットワークサービス許可する リモートユーザーコンピューターリソースを使用する

    ネットワーク オペレーティング システムの例:

    ノベル・ネットウェア

    · マイクロソフトウィンドウズ(95、NT、XP、Vista、セブン)

    ・ 様々な UNIXシステム、Solaris、FreeBSD など

    ・各種GNU/Linuxシステム

    ZyXELのZyNOS

    最新のネットワーク オペレーティング システム (UNIX、WIN2000、NOWELL NW) は OSI モデルの完全なプロトコル スタックを実装しているため、UNIX はプロトコル スタック (TCP/IP、NW LINK、NET BIOS) をサポートしています。 Nowell NW は IPX/SPX プロトコル スタックをサポートしており、Apple Mac は独自のプロトコル セットを使用します。

    メーカーに関係なく、すべてのネットワーク オペレーティング システムは次の機能を実行します。

    1. ネットワークノード (クライアントとサーバー) 間の機能の分散。

    2.サポート 通信プロトコル;

    3. ネットワーク ファイル システムのサポート。

    4. データ保護。

    すべてのネットワーク オペレーティング システムは、次の 2 つのタイプに分類できます。

    1. ピアツーピアまたはピアツーピア ネットワーク (それぞれ)。 Windowsの例 9倍;

    2. 専用サーバーをベースとしたネットワーク。

    K1。ピアツーピア ネットワークでは、すべての PC が同等の権限を持ちますが、ネットワーク内にはクライアントとサーバーも存在します。 通常、ユーザーが希望する場合は、各 PC をサーバー モードに切り替えることができます (共有リソースが割り当てられます)。

    ピアツーピア ネットワーク OS には、信頼できるパフォーマンスとセキュリティが欠けています。 ネットワーク上で10～15台の場合に使用します。 ピアツーピア ネットワークの例は、Win94/98/OS/2/LANtastic です。

    K2。このネットワークには常にメイン PC、つまり特別に最適化されたサーバーが存在します。 高速処理多くのクライアント (約 100) からのリクエストに対応し、ファイルとディレクトリの保護を管理します。 で 大規模なネットワーク別々のサーバーが割り当てられます 個別のアプリケーション(WEBサーバー、ファイルサーバー、プリントサーバー、DBサーバー、 メールサーバー)

    サーバ ソフトウェア高い複雑さ、信頼性、パフォーマンスが特徴です。 さまざまなプラットフォームで機能します。

    異なる OS – Unix、Win 2000Server、NovellNetWare

    どの OS のクライアント ソフトウェアでも、ユーザーのリクエストをローカルの場所からリダイレクトできます。 必要なリソースを備えた PC からサーバーへ。 これは特別なリダイレクタ (インターセプタ) を使用して行われ、リクエストをインターセプトし、リクエストをローカル PC で実行するかサーバーで実行するかを決定します。

    リダイレクタの構造:

    講義2

    モダンな ソフトウェアアプリケーションそして情報システムは、「アーキテクチャ」という用語が適用されても驚くべきことではないほどの発展レベルに達しています。 効率的かつ確実に機能する情報システムを有能に構築することは、最新の多機能ビルの設計と建設ほど簡単ではありません。

    「情報システム アーキテクチャ」に関しては、通常、定義が不足することはありません。 そのような定義を集めた Web サイトもあります。

    さまざまな情報源から得られた「情報システム アーキテクチャ」の定義を考えてみましょう。

    · 建築 システムの組織構造です。

    · 情報システムのアーキテクチャ – 情報システムのモデル、構造、実行される機能、およびコンポーネントの相互接続を定義する概念。

    · 建築 - これはシステムの基本的な構成であり、コンポーネント、コンポーネント間の関係、および環境との関係、およびシステムの設計と開発を決定する原則に具体化されています。

    · 建築 ソフトウェア システムの構成、システムを組み立てる一連の構造要素とそのインターフェイス、およびこれらの要素間の相互作用によって決定される動作、要素を徐々に大きなサブシステムに配置することに関する重要な決定のセットです。そして、この組織を方向付けるアーキテクチャのスタイル、つまり要素とそのインターフェイス、インタラクション、レイアウトです。

    · プログラムアーキテクチャまたは コンピューターシステム - これはシステムの構造であり、プログラム要素、これらの要素の外部から見えるプロパティ、および要素間の接続が含まれます。

    · 建築 組織の構造とそれに関連するシステムの動作です。 アーキテクチャは、インターフェイス、パーツを接続する接続、およびパーツを組み立てるための条件を通じて相互作用するパーツに再帰的に分解できます。 インターフェイスを介して対話する部分には、クラス、コンポーネント、サブシステムが含まれます。

    · システムまたはシステムのセットのソフトウェア アーキテクチャ プログラム構造と、システムを構成する構造間の相互作用に関するすべての重要な設計上の決定で構成されます。 設計上の決定により、システムが成功するためにサポートする必要がある一連の望ましいプロパティが提供されます。 設計ソリューションは、システム開発、サポート、保守のための概念的なフレームワークを提供します。

    定義は多少異なりますが、かなりの類似性が見られます。 たとえば、ほとんどの定義では、アーキテクチャは構造と動作にのみ関係しており、 重要な決定、アーキテクチャ スタイルに対応する場合があり、利害関係者とその環境の影響を受け、論理的推論に基づいて決定を実装します。



    ソフトウェア システムのアーキテクチャとは、以下に関する一連の決定を意味します。

    · ソフトウェア システムの構成。

    · システムを構成する構造要素とそのインターフェイスの選択。

    · 他の要素との相互作用におけるこれらの要素の動作。

    · これらの要素をサブシステムに結合する。

    · アーキテクチャ スタイル。システムの論理的および物理的構成を決定します。静的要素と動的要素、それらのインターフェイス、およびそれらを組み合わせる方法です。

    ソフトウェア システムのアーキテクチャには、その構造的および動作的側面だけでなく、その使用規則と他のシステムとの統合、機能、パフォーマンス、柔軟性、信頼性、再利用性、完全性、経済的および技術的制限、およびユーザー インターフェイスの問題も含まれます。 。

    ソフトウェア システムが発展するにつれて、単一のシステムを構築するために相互の統合がますます重要になります。 情報空間企業。 上記の定義からわかるように、統合とは 最も重要な要素建築。

    正しく信頼性の高いアーキテクチャを構築し、ソフトウェア システムの統合を適切に設計するには、次の事項に厳密に従う必要があります。 現代の標準これらの地域では。 これがなければ、進化できず、IT ユーザーの増大するニーズを満たすことができないアーキテクチャを作成してしまう可能性があります。 この領域の標準セッターは次のとおりです。 国際機関 SEI（ソフトウェアエンジニアリング協会）、WWW（コンソーシアム）として 世界的に Web)、OMG (オブジェクト管理グループ)、Java Developers Organization - JCP (Java Community Process)、IEEE (電気電子学会) など。

    アーキテクチャに従ってソフトウェア システムを分類してみましょう。

    · 集中型アーキテクチャ。

    · ファイルサーバーアーキテクチャ。

    · 2 層のクライアント/サーバー アーキテクチャ。

    · 多層クライアント/サーバー アーキテクチャ。

    ・ 建築 分散システム;

    · Web アプリケーション アーキテクチャ。

    ・ サービス指向アーキテクチャー。

    他の分類と同様に、次の点に注意してください。 この分類情報システムのアーキテクチャは完全に厳格ではありません。 特定の情報システムのアーキテクチャでは、多くの場合、いくつかの一般的なアーキテクチャ上の決定の影響が見られます。

    DBの場所いわゆる データベースアーキテクチャ、データベースは次のように分かれています。

    ・ 地元;

    · リモート。

    ローカル データベースで操作を実行するには、いわゆるローカル アプリケーションが開発および使用され、リモート データベースでの操作には、クライアント/サーバー アプリケーションが使用されます。

    データベースの場所は、このデータベースに含まれるデータを処理するアプリケーションの開発に大きな影響を与えます。

    ローカル データベースは、その上で実行されているアプリケーションと同じコンピュータ上に配置されます。 この場合、情報システムには、 地元の建築(図1)。 データベースの操作は、原則としてシングルユーザー モードで行われます。 必要に応じて、同じデータに同時にアクセスする別のアプリケーションをコンピュータ上で実行できます。 運転用 共有データベースに必要な 特別な手段制御と保護。 これらのツールは、たとえば、アプリケーションが別のアプリケーションによって編集されているレコードを変更しようとする場合に必要になることがあります。 各タイプのデータベースは独自の方法でこのような制御を実装しており、通常はアクセス制御ツールが組み込まれています。

    ネットワーク上のローカル データベースを使用する場合、そのデータベースへのマルチユーザー アクセスを組織することができます。 この場合、データベース ファイルと、データベース ファイルと連動するように設計されたアプリケーションはネットワーク サーバー上に配置されます。 各ユーザーはサーバー上にあるこのアプリケーションを自分のコンピュータから実行し、アプリケーションのコピーが起動されます。 ローカル データベースを使用するためのこのネットワーク オプションは、 ファイルサーバーのアーキテクチャ。 ファイル サーバー アーキテクチャを備えたアプリケーションは、ネットワーク上の各コンピュータに記録することもできます。この場合、アプリケーションは 別のコンピューター共通データベースの場所を知っておく必要があります (図 2)。

    それぞれのデータを操作する場合 ユーザーのコンピュータネットワークでは、データベースのローカル コピーが使用されます。 このコピーは、サーバー上のデータベースに含まれるデータで定期的に更新されます。

    ファイル サーバー アーキテクチャは通常、ユーザー数が少ないネットワークで使用され、Paradoc や dBase などの個人用 DBMS がその実装に適しています。 このアーキテクチャの利点は、実装が容易であることと、アプリケーションが実際には 1 人のユーザー向けに開発され、ネットワーク上のどのコンピュータにインストールされているかに依存しないことです。

    このアーキテクチャの利点:

    · データを操作するマルチユーザー モード。

    · 集中アクセス制御の利便性。

    · 開発コストが低い。

    · 開発スピードが速い。

    ・ ない 高価ソフトウェアのアップデートと変更。

    ただし、ファイル サーバー アーキテクチャには重大な欠点もあります。

    1. ユーザーはデータベースのローカル コピーを使用して作業します。このコピー内のデータは、テーブルへのリクエストごとに更新されます。 この場合、サーバーから送信されます。 新しいコピーデータが要求されるテーブル全体。 したがって、ユーザーが少数のテーブル レコードのみを必要とする場合、テーブル全体がサーバーからネットワーク経由で送信されます。 ネットワーク上で大量の冗長な情報が流通することにより、ネットワークの負荷が急激に増大し、それに伴ってネットワークの速度や情報システム全体のパフォーマンスが低下します。

    2. 各コンピュータにはデータベースの独自のコピーがあるため、あるユーザーがデータベースに加えた変更は、しばらくの間他のユーザーには知られません。 したがって、それは必要です 継続的な更新 DB。 さらに、別のユーザーが編集したテーブル内のレコードをロックするため、個々のユーザーの作業を同期する必要があります。

    3. データベースは次を使用して管理されます。 さまざまなコンピュータしたがって、アクセス制御を組織化し、機密性を維持し、データベースの整合性を維持することは非常に困難です。

    一般に、コンピュータと情報システムの一部であるプログラムは同等ではありません。 彼らの中にはリソースを所有している人もいます ( ファイルシステム、プロセッサ、プリンタ、データベースなど）、他の人はこれらのリソースにアクセスすることができます。

    リモート データベースがネットワーク サーバー コンピュータ上にあり、このデータベースと連携するアプリケーションがユーザーのコンピュータ上にある場合、 このアーキテクチャは「クライアントサーバー」と呼ばれます(図3、図4)。 このアーキテクチャでは、情報システムはサーバーとデータベース クライアントという異種の部分に分割されます。 サーバー コンピューターはクライアントとは別に配置されているため、リモート サーバーと呼ばれます。

    サーバ– これは DBMS 自体です。 データ定義、データ処理、データ保護、データ整合性の維持など、DBMS のすべての基本機能をサポートします。

    クライアントユーザーのアプリケーションです。 データを受信するために、クライアントはリクエストを生成し、データベースをホストするリモート サーバーに送信します。 リクエストは SQL 言語で生成されます。これは、使用時にサーバーにアクセスする標準的な手段です。 リレーショナルモデルデータ。 リクエストを受信した後、リモート サーバーはそのリクエストを SQL サーバー (データベース サーバー) に送信します。SQL サーバーはリモート データベースを管理し、リクエストが確実に実行され、その結果がクライアントに返されるようにする特別なプログラムです。

    したがって、クライアント/サーバー アーキテクチャでは、クライアントはデータの要求を送信し、実際に要求されたデータのみを受信します。 すべてのリクエスト処理はリモート サーバー上で実行されます。 このアーキテクチャには次の利点があります。

    1. 必要な情報だけがネットワーク内を流通するようになるため、ネットワークの負荷が軽減されます。

    2. すべてのクライアントからの要求の処理がサーバー上の単一プログラムによって実行されるため、情報セキュリティが強化されます。 サーバーは、すべてのユーザーに共通のデータベース使用規則を確立し、データへのクライアント アクセス モードを制御し、特に、異なるユーザーによる 1 つのレコードの同時変更を禁止します。

    3. データベース制御およびデータベースへのアクセス制御に関連するコードが存在しないため、クライアント アプリケーションの複雑さが軽減されます。

    このアーキテクチャの欠点は次のとおりです。

    · サーバー障害により全体が停止する可能性があります コンピュータネットワーク;

    · このシステムの管理には資格のある専門家が必要です。

    · 機器のコストが高い。

    · アプリケーションのビジネス ロジックはクライアント ソフトウェアに残ります。

    クライアント/サーバー アーキテクチャを実装するには、通常、Oracle や Microsoft などのマルチユーザー DBMS が使用されます。 SQLサーバー。 このような DBMS は、組織や企業向けの情報システムを構築できるため、産業用とも呼ばれます。 多数のユーザー。

    3層アーキテクチャ– クライアント、アプリケーション サーバー (クライアント アプリケーションが接続される)、およびデータベース サーバー (アプリケーション サーバーが連携する) という 3 つのコンポーネントの存在を前提とするソフトウェア パッケージのアーキテクチャ モデル。

    3 レベル クライアントサーバーアーキテクチャ 90 年代半ばに開発され始め、分離を実現します。 アプリケーションレベルデータ管理から。 別々のものは分離されます プログラムレベル、アプリケーションのアプリケーション ロジックに重点を置いています。 ミドルウェア プログラムは特別なアプリケーション サーバーの制御下で実行できますが、そのようなプログラムは通常の Web サーバーの制御下で実行することもできます。 最後に、データ管理はデータサーバーによって実行されます。

    クライアント (クライアント層) は、によって提供される複合体のインターフェイス (通常はグラフィカル) コンポーネントです。 エンドユーザー。 このレベルは、(セキュリティとスケーラビリティの要件に従って) データベースと直接接続する必要はなく、(スケーラビリティの要件に従って) コア ビジネス ロジックをロードし、(信頼性の要件に従って) アプリケーションの状態を保存する必要があります。 通常、最も単純なビジネス ロジックのみがこのレベルに転送されます。認可インターフェイス、暗号化アルゴリズム、入力された値の有効性と形式への準拠のチェック、端末にすでにロードされているデータの単純な操作 (値の並べ替え、グループ化、カウント) です。

    アプリケーション サーバー (中間層、接着層) は 2 番目のレベルにあり、ビジネス ロジックのほとんどがここに集中します。 その外側には、クライアント (端末) にエクスポートされたフラグメントと、データベースに埋め込まれたロジックの要素 (ストアド プロシージャとトリガー) のみが残ります。 実装 このコンポーネントのミドルウェアによって提供されます。 アプリケーション サーバーは、追加のインスタンスを追加することでソフトウェア パッケージのパフォーマンスの水平スケーリングを保証し、ソフトウェアを変更する必要がないように設計されています。 プログラムコードアプリケーション。

    データベース サーバー (データ層) はデータ ストレージを提供し、別のレベルに配置されます。通常、データベース管理システムによって実装されます。このコンポーネントへの接続はアプリケーション サーバー レベルからのみ提供されます。

    最も単純な構成では、すべてのコンポーネントまたは一部のコンポーネントを 1 つのコンピューティング ノード上に組み合わせることができます。 実稼働構成では、原則として、データベース サーバーまたはデータベース サーバーのクラスターに専用のコンピューティング ノードが使用され、アプリケーション サーバーには、クライアント (端末) が直接接続される専用のコンピューティング ノードのグループが使用されます。

    クライアントサーバーと比較したり、 ファイルサーバーのアーキテクチャ 3 レベルのアーキテクチャは、一般に、より優れたスケーラビリティ (アプリケーション サーバーの水平スケーラビリティと接続の多重化により)、より優れた構成可能性 (レベル間の分離により) を提供します。 十分な機会セキュリティと耐障害性を確保します。 さらに、データベース サーバーへの直接接続を使用するクライアント/サーバー アプリケーションと比較して、クライアントとサーバーの間の通信チャネルの速度と安定性の要件は、 サーバー部分。 Web ブラウザまたはシン クライアントからアクセスできるアプリケーションの実装には、通常、3 層アーキテクチャでのソフトウェア パッケージの展開が含まれます。 この場合、通常は 3 レベルのアプリケーションの開発になります。 ソフトウェアシステムよりも難しい クライアントサーバーアプリケーション、追加のミドルウェアの存在により、そのような複合体の管理に追加のコストがかかる可能性があります。

    特定のネットワーク サービスにアクセスするには、その機能が「厚さ」の概念によって特徴付けられるクライアントが使用されます。 これは、クライアントが使用できるハードウェア構成とソフトウェアを定義します。 考えられる境界値を考えてみましょう。

    シン・クライアント。 この用語は、Web インターフェイス経由で必要なネットワーク アプリケーションを実行するためにのみ十分なコンピューティング リソースを持つクライアントを定義します。 このようなアプリケーションのユーザー インターフェイスは静的 HTML を使用して形成され (JavaScript の実行は提供されません)、すべてのアプリケーション ロジックはサーバー上で実行されます。

    シン クライアントが動作するには、Web ブラウザを起動する機能を提供するだけで十分です。Web ブラウザのウィンドウですべてのアクションが実行されます。 このため、Web ブラウザは「ユニバーサル クライアント」と呼ばれることがあります。

    「太った」クライアント。 これは ワークステーションまたは パソコン、独自のディスクを実行 オペレーティング·システム必要なソフトウェアのセットがあること。 に ネットワークサーバー「太った」クライアントは主に次の目的で来ます 追加サービス(たとえば、Web サーバーや企業データベースへのアクセス)。

    「シック」クライアントは、ローカル OS で実行されるクライアント ネットワーク アプリケーションも意味します。 このようなアプリケーションは、データ プレゼンテーション コンポーネント (OS グラフィカル ユーザー インターフェイス) とアプリケーション コンポーネント (クライアント コンピューターの計算能力) を組み合わせます。

    解決策に向けて 列挙された問題マルチレベル (3 レベル以上) のクライアント/サーバー アーキテクチャが使用されます。

    このようなアーキテクチャは、データ処理モジュールをよりインテリジェントに分散します。 ケースは 1 つ以上の別個のサーバーで実行されます。 これら ソフトウェアモジュールユーザーとのインターフェースとしてはサーバー、データベースサーバーとしてはクライアントの機能を実行します。 さらに、異なるアプリケーション サーバーが相互に通信して、システムをより正確に分割できます。 ファンクションブロック特定の役割を果たします。

    たとえば、人事管理に必要なすべての機能を実行する人事管理サーバーを選択できます。 別のデータベースを関連付けることにより、このサーバーのすべての実装詳細をユーザーから非表示にし、その公開機能のみにアクセスできるようにすることができます。 さらに、このようなシステムは、ユーザーが Web にアクセスするための HTML フォームを開発するのが簡単であるため、Web に適応させるのが非常に簡単です。 特定の機能すべてのデータよりもデータベース。

    で 3層アーキテクチャクライアントはデータ処理機能で過負荷になることはありませんが、アプリケーション サーバーからの情報を表示するシステムとして主な役割を果たします。 このようなインターフェイスは次を使用して実装できます。 標準的な手段 Web テクノロジー - ブラウザ、CGI、Java。 これにより、クライアントとアプリケーション サーバー間で転送されるデータ量が削減され、電話回線などの低速回線でもクライアント コンピュータが接続できるようになります。 さらに、クライアント側は非常に単純なので、ほとんどの場合、ユニバーサル ブラウザを使用して実装されます。ただし、それでも変更する必要がある場合は、この手順をすばやく簡単に実行できます。 3 層のクライアント/サーバー アーキテクチャでは、ユーザー権限をより正確に割り当てることができます。これは、ユーザーがデータベース自体へのアクセス権ではなく、アプリケーション サーバーの特定の機能へのアクセス権を受け取るためです。 これにより、(従来のアーキテクチャと比較して) 意図的な攻撃だけでなく、担当者の誤った行為からもシステムのセキュリティが強化されます。

    例として、さまざまな部分が互いに離れた複数のサーバー上で実行されるシステムを考えてみましょう。 開発者がシステムの新しいバージョンを受け取ったと仮定します。これをインストールするには、2 レベルのアーキテクチャですべてのシステム モジュールを同時に変更する必要があります。 これが行われていない場合、開発者は通常、そのようなシステムの使用を期待していないため、古いクライアントと新しいサーバーの相互作用により、予期せぬ結果が生じる可能性があります。 3 層アーキテクチャでは、状況は単純化されます。 実際、アプリケーション サーバーとデータ ストレージ サーバーを変更すると (通常、両方とも近くにあるため、これは同時に行うのが簡単です)、利用可能なサービスのセットが即座に変更されます。 したがって、サーバー部分とクライアント部分のバージョン間の不一致によるエラーの可能性は大幅に減少します。 入っている場合 新しいバージョンいずれかのサービスが消滅した場合、そのサービスを提供していたインターフェイス要素は、 古いシステム、それらは単に機能しません。 サービスのアルゴリズムが変更されている場合は、古いインターフェースでも正しく動作します。

    マルチレベルのクライアント/サーバー システムは、非常に簡単に Web テクノロジに移行できます。これを行うには、クライアント部分をユニバーサルまたは専用のブラウザに置き換え、アプリケーション サーバーを Web サーバーで補完するだけで十分です。 小さなプログラムサーバープロシージャの呼び出し。 これらのプログラムの開発には、Common Gateway Interface (CGI) とより最新の Java テクノロジの両方を使用できます。

    3 レベル システムでは、アプリケーション サーバーとデータベースの間の通信チャネルを通じて非常に多くの情報が送信されることにも注意してください。 ただし、通信が行われるため、計算が遅くなるわけではありません。 指定された要素より高速な回線が利用できるようになります。 通常、両方のサーバーが同じ敷地内に配置されているため、これには最小限の労力で済みます。 したがって、システムの全体的なパフォーマンスが向上します。2 つの異なるサーバーが 1 つのタスクで動作し、それらの間の通信を最小限のコストで最速の回線を介して実行できるようになります。 確かに、共同計算の一貫性という問題があり、トランザクション マネージャー (マルチレベル システムの新しい要素) はこの問題を解決する必要があります。

    DB、構造上 言語 SQLクエリ (Structured Query Language)、リレーショナル データベースの世界における業界標準です。 リモートサーバーリクエストを受け入れ、SQL データベース サーバーに転送します。 SQLサーバー - 特別番組、リモートデータベースを管理します。 SQL サーバーは、リクエストの解釈、データベース内でのリクエストの実行、リクエストの結果の生成、およびクライアント アプリケーションへの配信を行います。 この場合、クライアント コンピュータのリソースは関与しません。 身体的パフォーマンスリクエスト; クライアント コンピュータは、サーバー データベースにリクエストを送信して結果を受信するだけで、その後、必要に応じてそれを解釈してユーザーに表示します。 リクエストの結果はクライアント アプリケーションに送信されるため、クライアントが必要とするデータのみがネットワークを介して「移動」します。 その結果、ネットワークの負荷が軽減されます。 リクエストはデータが保存されている場所 (サーバー) で実行されるため、大量のデータをバッチで送信する必要はありません。 さらに、SQL Server は、可能であれば、受信したクエリを最適化して、クエリが実行されるようにします。 最低時間最小のオーバーヘッド [[3.2]、[3.3]]。 システムを図に示します。 3.3.

    これらすべてにより、システムのパフォーマンスが向上し、要求結果を待つ時間が短縮されます。 サーバーによってクエリが実行されると、データ整合性ルールがサーバー上のデータベースに定義され、このデータベースを使用するすべてのアプリケーションで同じであるため、データ セキュリティの度合いが大幅に向上します。 これにより、整合性を維持するために矛盾するルールを定義する可能性が排除されます。 SQL サーバーがサポートする強力なトランザクション エンジンにより、異なるユーザーによる同じデータへの同時変更を防ぐことができ、異常終了したデータベースに変更を加えたときに元の値にロールバックする機能が提供されます [[3.2]、[ 3.3]]。


    米。 3.3.クライアントサーバーアーキテクチャ

    • 存在する ローカルネットワークは複数のクライアント コンピューターで構成されており、各コンピューターにはデータベースを操作するためのクライアント アプリケーションがインストールされています。
    • ユーザーは各クライアント コンピューターでアプリケーションを実行できます。 アプリケーションが提供するユーザー インターフェイスを使用して、サーバー上にある DBMS への呼び出しを開始し、情報を取得/更新します。 通信に使用される 特殊な言語 SQL クエリ、つまり リクエスト テキストのみがネットワークを介してクライアントからサーバーに送信されます。
    • DBMS はサーバー上にあるデータへの呼び出しを開始します。その結果、すべてのデータ処理がサーバー上で実行され、要求の結果のみがクライアント コンピューターにコピーされます。 したがって、DBMS は結果をアプリケーションに返します。

    サーバーとクライアント間の機能の分離がどのようなものかを見てみましょう。

    • クライアント アプリケーションの機能:
      • サーバーにリクエストを送信します。
      • サーバーから受信したクエリ結果の解釈。
      • 結果を何らかの形式 (ユーザー インターフェイス) でユーザーに提示します。
    • サーバー側の機能:
      • クライアント アプリケーションからのリクエストを受信します。
      • リクエストの解釈。
      • データベースクエリの最適化と実行。
      • 結果をクライアント アプリケーションに送信します。
      • セキュリティシステムとアクセス制御を確保します。
      • データベースの整合性管理。
      • マルチユーザー動作モードの安定性の実装。

    いわゆる「産業用」DBMS は、クライアント/サーバー アーキテクチャで動作します。 中・中規模の情報システムの運用を保証できるのがこのクラスのDBMSであるため、産業用と呼ばれています。 大企業、組織、銀行。 産業用 DBMS のカテゴリには、MS SQL Server、Oracle、Gupta、Informix、Sybase、DB2、InterBase およびその他多数が含まれます [[3.2]]。

    原則として、SQL サーバーは個々の従業員または従業員のグループ (SQL サーバー管理者) によって保守されます。 データベースの物理的特性を管理し、最適化、構成、および 再定義さまざまなデータベース コンポーネント、新しいデータベースの作成、既存のデータベースの変更などを行い、さまざまなユーザーに特権 (特定のデータベースや SQL サーバーへの一定レベルのアクセス許可) を発行します [[3.2]]。

    ファイル サーバー アーキテクチャと比較したこのアーキテクチャの主な利点を見てみましょう。

    • ネットワークトラフィックが大幅に削減されます。
    • クライアント アプリケーションの複雑さが軽減され (負荷のほとんどがサーバー部分にかかる)、その結果、クライアント コンピューターのハードウェア容量の要件が軽減されます。
    • 特別なソフトウェア ツールである SQL サーバーの存在により、設計およびプログラミングのタスクの重要な部分がすでに解決されているという事実が得られます。
    • データベースの整合性とセキュリティが大幅に向上します。

    デメリットとしては、ハードウェアの財務コストが高くなることが挙げられます。 ソフトウェアまた、多数のクライアント コンピュータが異なる場所に配置されているため、すべてのクライアント コンピュータでクライアント アプリケーションをタイムリーに更新することが困難になるという事実もあります。 それにもかかわらず、クライアント/サーバー アーキテクチャは実際に十分に機能していることが証明されており、現時点では、このアーキテクチャに従って構築された多数のデータベースが存在し、動作しています。

    3.4. 3 層 (多層) クライアント/サーバー アーキテクチャ。

    3 リンク (場合によってはマルチリンク) 建築(N 層または複数の 3層アーキテクチャ? ビジネス ロジックが変更された場合でも、クライアント アプリケーションを変更してすべてのユーザーに対して更新する必要はなくなりました。 さらに、ユーザー機器の要件も可能な限り軽減されます。

    結果として、作品は次のように構成されます。

    • ファイルのセットの形式のデータベースは、特別な専用コンピュータ (ネットワーク サーバー) のハード ドライブ上にあります。
    • DBMS もネットワーク サーバー上にあります。
    • ビジネス分析ソフトウェア (ビジネス ロジック) が配置される特別な専用のアプリケーション サーバーがあります [[3.1]]。
    • 多数のクライアント コンピュータがあり、それぞれにいわゆる「 シン・クライアント」は、ユーザー インターフェイスを実装するクライアント アプリケーションです。
    • 各クライアント コンピュータ上で、ユーザーはアプリケーション (シン クライアント) を実行する機会があります。 アプリケーションが提供するユーザー インターフェイスを使用して、アプリケーション サーバー上にあるビジネス インテリジェンス ソフトウェアへの呼び出しを開始します。
    • アプリケーション サーバーはユーザー要件を分析し、データベースへのクエリを生成します。 通信には、特別なクエリ言語 SQL が使用されます。 リクエスト テキストのみがネットワークを介してアプリケーション サーバーからデータベース サーバーに送信されます。
    • DBMS は、サーバー上にあるデータベースの物理構造に関するすべての情報をその内部にカプセル化します。
    • DBMS はサーバー上にあるデータへの呼び出しを開始し、その結果、クエリの結果がアプリケーション サーバーにコピーされます。
    • アプリケーション サーバーは結果をクライアント アプリケーション (ユーザー) に返します。
    • アプリケーションは、ユーザー インターフェイスを使用して、クエリの結果を表示します。

    クライアントサーバー技術は「クジラ」の 1 つと考えられています 現代世界コンピューターネットワーク。 しかし、それが開発された問題は過去のものになりつつあります。 新しいタスクとテクノロジには、クライアント/サーバー システムの原理を再考する必要があります。 そのうちの 1 つ テクノロジーワールドワイドウェブ。 Web テクノロジーは、クライアント/サーバー アーキテクチャの発展です。 1 つのクライアントで多数のサーバーに接続できます。 情報システムには、インターフェイスに加えて、データ処理とストレージのレベルも必要です。 インターネット開発者にとっての問題は、Web の作業をデータベースなどのシステムの他の要素と調整することです。 の一つ 有望な方法この問題に対する解決策は、マルチレベルのクライアント/サーバー システムです。

    古典的なシステムクライアント/サーバーは、要求/応答スキーム (2 レベルのアーキテクチャ) に従って動作します。 クライアントが実行します アクティブな機能(リクエスト)、サーバーはそれらに受動的に応答します。


    どのような情報システムにも、少なくとも 3 つの機能部分 (データ ストレージ、データ処理、ユーザー インターフェイスのモジュール) が必要です。

    これらの各部分は、他の 2 つの部分とは独立して実装できます。

    例えば 。 データの保存と処理に使用するプログラムを変更せずに、同じデータを表、グラフ、またはヒストグラムの形式で表示するようにユーザー インターフェイスを変更できます。 データの表示プログラムや保存プログラムを変更せずに、全文検索アルゴリズムを変更することで処理プログラムを変更できます。 データの表示および処理を行うプログラムを変更せずに、別のファイル システムに切り替えることで、データを保存するソフトウェアを変更できます。

    古典的なクライアント/サーバー アーキテクチャでは、アプリケーションの 3 つの主要な部分が 2 つの部分に分散されます。 物理モジュール。 通常、データ ストレージ ソフトウェアはサーバー (/: データベース サーバー) に配置され、ユーザー インターフェイスはクライアント側にありますが、データ処理はクライアント部分とサーバー部分の間で分散する必要があります。 これがこのアーキテクチャの主な欠点です。 データ処理アルゴリズムを分割するには、システムの両方の部分の動作を同期する必要があります。 矛盾を避けるために さまざまな要素アーキテクチャは、クライアント側 (シック クライアント) またはサーバー (シン クライアント、または 2.5 層クライアント/サーバー) の 2 つの部分のいずれかでデータ処理を実行しようとします。 各アプローチには次のような欠点があります。 最初のケースではネットワークが不当に過負荷になっているため、 生の（冗長）データを送信するため、システムのサポートや変更がより困難になります。計算アルゴリズムの置き換えやエラーの修正には、すべてのインターフェイス プログラムを同時に完全に置き換える必要があり、そうしないとデータの不整合が発生するからです。 2番目の場合, すべての情報処理がサーバー上で実行される場合、組み込みプロシージャの記述とそのデバッグの問題が発生します (記述は宣言的であり、ステップバイステップのデバッグができません)。 また、サーバー上で情報処理を行うシステムは、他のプラットフォームに移行することは絶対に不可能です。

    最も現代的な手段 急速な発展さまざまなデータベースで動作するアプリケーション (RAD) は、最初のモデル (「シック」クライアント) を実装し、次を介してデータベース サーバーとのインターフェイスを提供します。 SQL言語.. このオプションには、上記の欠点に加えて、 低レベル安全。

    例えば。 銀行システムでは、すべてのオペレーターが会計システムのメインテーブルに書き込む権利を持っています。 さらに、データベース サーバーへのアクセスには特殊なクライアント ソフトウェアが使用されるため、このシステムを Web テクノロジに移行することはほとんど不可能です。

    上で説明したモデルの欠点:

    1.「ファット」クライアント

    F 管理の複雑さ。

    F ソフトウェアのアップデートが困難なため、 その交換はシステム全体で同時に実行する必要があります。

    F アクセスがアクションではなくテーブルによって制限されるため、権限の配分が複雑になります。

    F 未処理データの送信によるネットワークの輻輳。

    F 防御が弱いデータ。

    2.「ファット」サーバー

    PL/SQL 言語はそのようなソフトウェアの開発には適しておらず、デバッグ ツールもないため、実装はより複雑になります。

    ð PL/SQL 言語のプログラムのパフォーマンスは他の言語よりも低く、これは重要な点です。 複雑なシステム;

    ð DBMS 言語で書かれたプログラムは確実に動作しないため、データベース サーバー全体の障害につながる可能性があります。

    この方法で作成されたプログラムは、他のシステムやプラットフォームにはまったく移植できません。

    これらの問題を解決するには、マルチレベル (3 つ以上) のクライアント/サーバー モデルが使用されます。

    多層アーキテクチャ client-server - 1 つ以上の個別のサーバー上で実行されるデータ処理モジュールをよりインテリジェントに分散します。

    これらのソフトウェアモジュールは機能を実行します サーバーユーザーとのインターフェースや、 クライアント- データベースサーバー用。 さらに、異なるアプリケーション サーバーが相互に通信して、システムを特定の役割を実行する機能単位により正確に分割できます。

    例えば。人事管理に必要なすべての機能を実行する人事管理サーバーを選択できます。 別のデータベースを関連付けることにより、このサーバーのすべての実装詳細をユーザーから隠し、パブリックにアクセスできる機能のみにアクセスできるようにすることができます。 このようなシステムは Web に適応しやすいため、 すべてのデータにアクセスするよりも、特定のデータベース機能にユーザーがアクセスするための HTML フォームを開発する方が簡単です。

    3 層モデルでは、シン クライアントはデータ処理機能で過負荷になることはありませんが、アプリケーション サーバーからの情報を表示するシステムの主な役割を果たします。 (このインターフェイスは、ブラウザ、CGI、Java などの標準的な Web テクノロジ ツールを使用して実装されます)。 これにより、クライアントとアプリケーション サーバー間で転送されるデータ量が削減され、低速な電話回線を使用するクライアントでも接続できるようになります。

    3 レベルのクライアント/サーバー モデルを使用すると、ユーザー権限をより正確に割り当てることができます。ユーザーはデータベース自体に対する権限ではなく、アプリケーション サーバーの特定の機能に対する権限を受け取るため、システムのセキュリティが向上します。

    マルチレベルのクライアント/サーバー システムは、Web テクノロジーに簡単に移行できます。これを行うには、クライアント部分をユニバーサル ブラウザーに置き換え、アプリケーション サーバーを Web サーバーと小規模なサーバー プロシージャ コール プログラムで補完するだけで十分です。 3 レベルのシステムでは、アプリケーション サーバーとデータベース間の通信チャネルを通じて大量の情報が送信されますが、これらの要素の通信にはより高速な回線が使用されるため、計算が遅くなることはありません。 両方のサーバーが同じ敷地内にあるため、コストが低くなります。 しかし、これは共同計算の一貫性の問題を引き起こし、マルチレベル システムの新しい要素であるトランザクション マネージャーはこの問題を解決する必要があります。

    トランザクションマネージャー

    MT- 1 つのアプリケーション サーバーが複数のデータベース サーバーと同時に通信できるようにします。 Oracle サーバーには分散トランザクションを実行するためのメカニズムが備わっていますが、ユーザーが情報の一部を Oracle データベースに、一部を Informix データベースに、そして一部を テキストファイル、それならMTなしではやっていけません。 MT は、分散された異種操作を管理し、情報システムのさまざまなコンポーネントの動作を調整するために使用されます。 複雑なソフトウェアには MT の使用が必要です。

    例えば。 銀行システム文書表現のさまざまな変換を実行する必要があります。 データベースと通常のファイルの両方に保存されているデータを同時に処理します。これらは MT が実行するのに役立つ機能です。

    MT は、情報システムのさまざまなコンポーネントの動作を調整するために使用できるプログラムまたはプログラムのセットです。

    論理的には、MT はいくつかの部分に分かれています。

    · 通信マネージャー (情報システムのコンポーネント間のメッセージ交換を制御します。

    · トランザクション マネージャー (分散操作を管理)。

    · ログ マネージャー (分散操作の復元とロールバックを監視)。

    · ロックマネージャー (提供 正しいアクセス共有データに）。

    通常、M 通信は M 認可と結合され、M トランザクションは M ロックおよびシステム レコードと結合されます。 さらに、そのような M が配信パッケージに含まれることはほとんどありません。その機能 (記録の保持、リソースの配布、操作の制御) は通常、データベース自体 (Oracle など) によって実行されるからです。

    新しいオブジェクト指向テクノロジ (CORBA、DCOM など) がこの分野に登場したため、M 通信では大きな変化が起こりました。 マルチレベルのクライアント/サーバー モデルにより、大幅に簡素化できます。 分散コンピューティングにより、信頼性が高まるだけでなく、より手頃な価格になります。

    4.4. プロセスメールシステム­ -

    これは情報の保証された配信であり、アプリケーション統合の手段です。

    情報システムの設計では、システム アナリストは次の問題の解決策を迫られます。

    ð 分散システム。

    ð さまざまなアプリケーションの統合。

    ð 管理が簡単。

    現代のコンピュータはほとんどが分散型であるため、そのようなシステムの個々の部分間の対話方法を選択するという問題が生じます。 複数の情報システムを統合するには統合ソリューションが必要です 大量異種アプリケーション。 このような (統合された) システムは、結合されたサブシステムのすべての機能を備え、シンプルさと使いやすさを維持する必要があります。 この問題は次を使用して解決できます 技術的なメールシステム(STP)。

    「テクノロジーメール」という用語は、アプリケーション間のやり取りを指すのに使用されます (「電子メール」は人間間のやり取りです)。 発信された情報技術的なものであり、その形成と伝達は人間の関与なし、または最小限の関与で実行できます。

    テクノロジーメールシステムには次の 2 つが含まれます。 違う方法最新の分散システムで使用される相互作用。

    1 つは接続の概念に基づいており (図 1)、もう 1 つはメッセージングの概念に基づいています。

    1


    図1。 接続指向の対話メカニズム

    アプリケーション間の対話プロセスと接続確立の使用は、次の 3 つのフェーズに分けることができます。

    1. 接続の確立。

    2. 情報の転送。

    3. 接続を閉じます。

    このような相互作用には、3 つのフェーズすべての接続とアプリケーションの同時操作が必要ですが、常に可能であるとは限りません。

    メッセージングの原理に基づいて構築されたシステムは、対話中にメッセージ キュー テクノロジを使用します (図 2)。

    図2. メッセージキューイングテクノロジーを使用したアプリケーション通信

    情報を交換するアプリケーションは、情報を相互に直接アドレス指定するのではなく、アプリケーションに関連付けられたメッセージ キューにアドレス指定します。 アプリケーションとキュー間の接続は、原則としてオンライン モードで行われるため、接続の確立にかかる時間が回避されます。 制御ソフトウェアは、アプリケーションと同じマシン上に配置することも、専用サーバーに配置することもできます。 メッセージ キュー テクノロジを使用するシステムは、接続確立システムとは異なり、対話プロセス中の永続的な接続や、対話するアプリケーションの同時操作を必要としません。 これらの特性により、柔軟性があり、さまざまな用途に適しています。

    技術的なメール システムの多用途性により、次のような作業が可能になります。 異質な (動作するさまざまなソフトウェアおよびハードウェア プラットフォーム 個々のコンポーネント STP、およびシステム構造で使用されるさまざまな接続方法と対話プロトコル。 異種混合は、STP のサーバー部分とクライアント部分を分離することによって実現されます。 クライアント部分にはほとんど機能がなく、さまざまなプラットフォームに移植できます。 したがって、STP の運用には追加の設備コストは必要ありません。システムは、 既存の手段(ハードウェアとソフトウェアの両方、および既存のデータ伝送チャネルへ) 交換する必要はありません。

    STP を使用する利点:

    Ø メッセージ配信の保証。 メッセージ キュー サーバー

    障害が発生した場合に配信を確実にする方法を決定する 個々の部品システム: 再送信、代替ルートの検索、または他の方法の使用。 STP はアプリケーション間の情報交換を提供するため、メッセージが配信されなかったという事実は追跡され、処理される必要があります（これとは対照的に） Eメール、メッセージが配信されない場合、ユーザーは自分で修正措置を講じる必要があります)。

    Ø 情報の転送中にアプリケーションがブロックされることはありません。 メッセージ キューのテクノロジが導入され、メッセージ配信を担当する TP システムのサーバー部分が割り当てられます。 ブロッキングがないため、アプリケーションのダウンタイムが短縮されます。

    Ø 送信時にメッセージの優先順位とオプションを設定する機能。 優先順位を使用すると、複数の並列メッセージ パッシング システムを実装できます。 ただし、優先度の低いメッセージは、優先度の高いメッセージの配信には影響を与えません。 これは、大規模なシステムの設計と構成だけでなく、システムの管理にもプラスの効果をもたらします。

    Ø ハードウェアとソフトウェアの両方の最新化が可能な異種環境での情報交換の可能性。