[Tomcat] Tomcat関連のデザインパターンの分析

ファサードモード

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

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

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

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

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

写真1.ファサード図

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

Tomcat ファサードモードの例

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

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

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

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

オブザーバーモード

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

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

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

サブジェクトは抽象サブジェクトです。すべてのオブザーバーの参照を管理し、メイン イベントの操作を定義する責任があります。
ConcreteSubject 具体的なサブジェクト: 抽象サブジェクトのすべての定義済みインターフェースを実装し、変更されるとすべてのオブザーバーに通知します。
オブザーバー オブザーバー: トピックの変更について、対応する操作インターフェイスを監視します。

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() メソッドにあり、その実行プロセスは次のとおりです:

1. LifecycleBase の fireLifecycleEvent (LifecycleListener リスナー) メソッドを呼び出します。 LifecycleBase は、Lifecycle インターフェイスを実装する抽象クラスです。
LifecycleSupport の fireLifecycleEvent(String type, Object data) メソッドの呼び出しを続けます (登録されたリスナーの補助イベント通知クラスであり、継承することはできません。final を使用します)
イベント通知完了

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 のコンテナー設定は、エンジンからホスト、コンテキスト、ラッパーへのチェーンを介して渡されます。

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

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

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

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

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

次の場所に移動します:

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