[Tomcat] Tomcat関連のデザインパターンの分析-＆＃＆チュートリアル-php.cn

ファサードモード

ファサードパターンは Tomcat の多くの場所で使用されます。この設計パターンは、リクエストと応答オブジェクトのカプセル化、標準ラッパーから ServletConfig へのカプセル化、ApplicationContext から ServletContext へのカプセル化などで使用されます。

ファサードデザインパターンの原則

このデザインパターンは非常に多くの機会に使用されていますが、このデザインパターンは一体何をするのでしょうか?名前が示すように、ある国の外務省のように、他者とのコミュニケーションを容易にするために何かをファサードにカプセル化することです。

この設計パターンは、大規模なシステムが複数のサブシステムで構成されている場合に主に使用されます。これらのサブシステムは相互に通信する必要がありますが、それ以外の場合は、サブシステムを分割する必要がありません。各サブシステムは、他のシステムにとって必要なデータをカプセル化し、このファサードを通じてデータにアクセスするためのファサードを設計します。これがファサードデザインパターンの目的です。

ファサードデザインパターンの模式図は以下の通りです。

写真1.ファサード図

クライアントはファサードで提供されるデータにのみアクセスできます。これがファサードデザインパターンの鍵となります。クライアントがどのようにファサードにアクセスするか、サブシステムがどのようにファサードを提供するかについては、ファサードデザインパターンは規定されていません。

Tomcat ファサードモードの例

Tomcat にはさまざまなコンポーネントがあり、各コンポーネントが相互にデータをやり取りする必要があるため、ファサードデザインパターンは Tomcat でよく使用されます。データを分離するためにファサードパターンを使用するのは良い方法です。

以下はリクエストで使用されたファサードデザインパターンです:

図 2. リクエストのファサードデザインパターンのクラス図

図からわかるように、HttpRequestFacade クラスは HttpRequest インターフェイスをカプセル化してデータを提供します。通常、カプセル化されたオブジェクトは、HttpRequest でのアクセス変更を防ぐために、プライベートまたは保護されたアクセス変更に設定されます。ファサードに直接アクセスできます。

オブザーバーモード

この設計パターンは、通常、イベントの発生前と後にいくつかの操作をトリガーする、パブリッシュ/サブスクライブパターンとも呼ばれます。

オブザーバーパターンの原則

オブザーバーモードの原理も非常にシンプルです。つまり、あなたが何かをしているとき、常に誰かがあなたの隣であなたを観察しています。あなたが興味のあることをすると、それに応じて他のことも実行します。ただし、あなたを見つめている人はあなたに登録しなければ通知できません。オブザーバーパターンには通常、次の役割が含まれます:

Tomcat のオブザーバーパターンの例

オブザーバーモードは、Tomcat の多くの場所でも使用されます。前述したコンポーネントのライフサイクルを制御するライフサイクルは、このモードの具体化であり、サーブレットインスタンス、セッション管理、コンテナーなどの作成に適用されます。以下では、主にライフサイクルの具体的な実装について説明します。

ライフサイクルのオブザーバーパターン構造図:

図3. ライフサイクルのオブザーバーパターン構造図

上記の構造図では、LifecycleListener は抽象オブザーバーを表しており、このメソッドはテーマが変更されたときに実行されるメソッドです。 ServerLifecycleListener は、特定のオブザーバーを表し、この特定のオブザーバーの特定の実装である LifecycleListener インターフェイスのメソッドを実装します。 Lifecycle インターフェースは、オブザーバーを管理するためのメソッドと、それが実行する必要があるその他のメソッドを定義する抽象的なサブジェクトを表します。 StandardServer は、抽象トピックのすべてのメソッドを実装する特定のトピックを表します。ここで、Tomcat はオブザーバーを拡張し、他の 2 つのクラス、LifecycleSupport と LifecycleEvent を追加しました。これらはオブザーバーの機能を拡張する補助クラスとして機能します。 LifecycleEvent を使用すると、イベントカテゴリを定義でき、異なるイベントを異なる方法で処理できるため、より柔軟になります。 LifecycleSupport クラスは、サブジェクトによる複数のオブザーバーの管理を表しており、この管理は一律に抽出され実装されます。後で変更する場合は、特定のトピックをすべて変更する必要はありません。オブザーバーに対する操作を LifecycleSupport クラスに委任します。これは、Observer パターンの改良版と考えることができます。

オブザーバーを呼び出すための LifecycleSupport のメソッドコードは次のとおりです:

リスト 1. LifecycleSupport の fireLifecycleEvent メソッド

リーリー

テーマはオブザーバーにどのように通知しますか?以下のコードを見てください:

リスト 2. コンテナー内の start メソッド

リーリー

Tomcat7 のコードのこの部分を見てみましょう。前の記事では、コンポーネントのライフサイクルはコンポーネントを含む親コンテナーによって管理され、サービスの起動プロセスはサーバーによって管理されると述べました。 Server インターフェイスのクラスは StandardServer クラスであり、startInernal() メソッドは StandardServer に実装されています。これは、Tomcat のサービスがすべて Lifecycle インターフェイスを実装しているため、StandServer によって管理されるサービスを周期的に開始するプロセスです。、それによって start() メソッド、startIntenal() が実行されます。メソッドは次のとおりです:

リーリー

これで、すべてのサービスが通知を受け取り、start メソッドを実行します。 Service の使用が許可されていない場合は、LifecycleException がスローされます。

stopIntenal() は、stop メソッドを実行するようにすべてのサービスに通知します。具体的な処理プロセスは startInternal() メソッドと似ています。

上記のコードリストの鍵は fireLifecycleEvent() メソッドにあり、その実行プロセスは次のとおりです:

LifecycleBase の fireLifecycleEvent (LifecycleListener リスナー) メソッドを呼び出します。 LifecycleBase は、Lifecycle インターフェイスを実装する抽象クラスです。

fireLifecycleEvent(String型, オブジェクトデータ)のメソッドは以下の通りです:

リーリー

そのため、特定のイベントの通知は、LifecycleListener インターフェースの lifecycleEvent メソッドによって完了します。各実装クラスは、さまざまな状況に応じてさまざまなイベントリスニングロジックを実装できます。

コマンドモード

先ほど、Tomcat の 2 つのコアコンポーネントであるコネクタとコンテナをいくつかに比較しました。男は受け付けた依頼をホステスに命令の形で手渡す。コネクタとコンテナに対応して、コネクタもコマンドモードでコンテナを呼び出します。

コマンドモードの原理

コマンドモードの主な機能は、コマンドをカプセル化し、コマンドを発行する責任とコマンドを実行する責任を分離することです。それは機能分業でもあります。異なるモジュールは、同じコマンドを異なる方法で解釈する可能性があります。

通常、次の役割が含まれるコマンドモードを次に示します:

クライアント: コマンドを作成し、受信者を決定します
コマンド: コマンドインターフェイスは抽象メソッドを定義します
ConcreteCommand: 受信者の対応する操作を呼び出す役割を担う特定のコマンド
Invoker requester: コマンドオブジェクトを呼び出してリクエストを実行する責任があります
受信者: リクエストの実装と実行を担当します

Tomcatのコマンドモードの例

Tomcat のコマンドモードは、コネクタコンポーネントとコンテナコンポーネントの間で反映されます。Tomcat はアプリケーションサーバーとして間違いなく多くのリクエストを受信し、これらのリクエストをどのように分散して実行するかが必要な機能です。

Tomcat がコマンドモードを実装する方法を見てみましょう。以下は Tomcat コマンドモードの構造図です。

図 4. Tomcat コマンドモードの構造図

抽象リクエスタとしての Connector、具象リクエスタとしての HttpConnector。コマンドとしての HttpProcessor。 Container はコマンドの抽象的な受信側として機能し、ContainerBase は具体的な受信側として機能します。クライアントはアプリケーションサーバーのサーバーコンポーネントです。サーバーは最初にコマンドリクエスター HttpConnector オブジェクトを作成し、次にコマンド HttpProcessor コマンドオブジェクトを作成します。次に、コマンドオブジェクトをコマンド受信者の ContainerBase コンテナに渡して、コマンドを処理します。コマンドは最終的に Tomcat のコンテナによって実行されます。コマンドはキューとして受信でき、コンテナーはさまざまな方法でリクエストを処理することもできます。たとえば、HTTP1.0 プロトコルと HTTP1.1 は異なる方法で処理されます。

責任連鎖モデル

Tomcat で最も簡単に発見できる設計パターンの 1 つは責任のチェーンです。この設計パターンは、Tomcat のコンテナ設計の基礎でもあり、このチェーンは常にリクエストを正しく渡します。リクエストの最終ハンドラー。

責任連鎖モデルの原則

責任チェーンモデルでは、多くのオブジェクトが次のオブジェクトへの参照を持ち、チェーンを形成するように接続され、チェーン上のオブジェクトがリクエストを処理するか、各オブジェクトがリクエストを処理して渡すことができるまで、リクエストがこのチェーンに渡されます。最終的にチェーン内のすべてのオブジェクトが処理されるまで、次のオブジェクトに進みます。このようにして、クライアントに影響を与えることなく、任意の処理ノードをチェーンに追加できます。

通常、責任連鎖モデルには次の役割が含まれます:

ハンドラー (抽象ハンドラー): リクエストを処理するためのインターフェースを定義します

ConcreteHandler (特定のハンドラー): リクエストを処理する、またはリクエストを次のパーティに渡す特定のクラス

この設計パターンは、Tomcat でほぼ完全に使用されています。Tomcat のコンテナー設定は、エンジンからホスト、コンテキスト、ラッパーへのチェーンを介して渡されます。

Tomcat の責任連鎖モデルのクラス構造図は次のとおりです:

図 5. Tomcat 責任連鎖モデルの構造図

上の図は基本的に、責任連鎖モデルを使用した 4 つのサブコンテナーのクラス構造図を示しています。責任連鎖モデルの対応する役割、コンテナーは抽象プロセッサーの役割を果たし、特定のプロセッサーはサブコンテナーによって演じられます。スタンダードエンジンなど。標準の責任連鎖とは異なり、ここでは Pipeline インターフェイスと Valve インターフェイスが紹介されています。彼らは何をしますか？

実際、Pipeline と Valve はこのチェーンの機能を拡張し、チェーンの下方送信中に外部介入を受け入れることができるようにしました。パイプラインは各サブコンテナーを接続するチューブで、内部で渡されるリクエストオブジェクトとレスポンスオブジェクトはチューブ内を流れる水のようなもので、バルブはこのチューブの小さな開口部で、内部の水に触れて追加の操作を行うことができます。物。

水が導かれて次のコンテナに流れなくなるのを防ぐために、パイプの各セクションの端には常にノードがあり、次のサブコンテナに確実に流れることができるようにするため、各コンテナには標準XXXバルブ。このような連鎖的な処理フローを伴う限り、これは学ぶ価値のあるモデルです。

次の場所に移動します:

以上が[Tomcat] Tomcat関連のデザインパターンの分析の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。