Pearl Echo 何故クライエント(エージェント)-サーバ型か

クライエント(エージェント)-サーバ型アーキテクチャは、一台以上のサーバを配置し、管理/可視化対象のクライエントにエージェントをインストールする。各エージェントは、リクエストをサーバに送信する。

サーバは通常受動的で、例えば、既存のユーザに関する許容される インターネット アクセス ルールのリスト、あるいはユーザのインターネット活動を表す キャプチャ データの受信、保存等、エージェントからのリクエストを待つ。リクエストを受け取ると、リクエストを処理し、エージェントに返信する。エージェントは能動的で、サーバにリクエストを送信し、サーバからの返信を処理する。

処理負荷はクライエントに分散されるため、一般的に分散アーキテクチャに行き着く。例えば、エージェントは、クライエントでのwebリクエストを分析し、サーバから受け取った インターネット アクセス ルールに基づいて、ユーザにデータを渡すかどうかの決断を下す。

クライエント-サーバの用語は、ネットワーク上のPCに関して、1980年代に最初に使われた。クライエント-サーバの ソフトウェア アーキテクチャは、多用途、メッセージ ベース、モジュール的インフラストラクチャで、有用性、柔軟性、相互運用性、拡張性を向上させることを目的としている。

企業情報管理の運用の中で、インタネット コンテンツへのユーザのリクエストは、リクエストが インターネット サーバに送られる時、エージェントにより、ローカル、リアルタイムに監視、分析される。コンテンツがアクセスされるかどうかの決断は、ユーザのところで行われる。webサイトのアクセス、メールのコンテンツ、IMのペイロード等のトランザクションが立ち入り禁止と判断されると、エージェントは、リクエストのトランザクションを止め、インターネット アプリケーションに、アクセスが拒否されたとのメッセージを即時に返す。

クライエント(エージェント)-サーバ型アーキテクチャの長所は、拡張性、サーバへの限られた処理要求である。さらに、ローカルな環境を経ての通信の経路切替え無しで、リモート、モバイル ユーザのリアルタイムな管理/可視化を提供する。エージェントがクライエント上にいるため、WiFiホットスポット、モデム接続経由のようなネットワーク外の手段での インターネット アクセスにより、企業情報ソリューションを蝕むことは不可能である。

分散型設計の必然として、クライエント(エージェント)-サーバの実装は、ボトルネック性能問題に悩まされることが無い。

インターネット利用管理は、Pass-Through(プロクシ)型、Pass-By(スニッファ)型アーキテクチャでの実現例があるが、様々な問題を抱えている。特に、在宅勤務者、移動中の営業マン等、企業ネットワーク外の リモート ユーザの管理は、クライエント(エージェント)-サーバ型でなければ実現できない。

結論として、クライエント(エージェント)-サーバ型は、他のアーキテクチャでの全ての課題を解決している。

問合せ


【開発元】Pearl Software, Inc http://www.pearlsoftware.com/
【輸入元】先端技術研究所 http://www.ART-Sentan.co.jp/ KHB16427@nifty.ne.jp 045-978-1292