この章では、Tomcat がどのように構成されているか（アーキテクチャ）を理解し、各構成ファイルの役割について学習します。また、構成ファイルを設定するためのGUIの管理ツールの使用方法についても学習します。アプリケーション･サーバーが持つ機能として、データソースとセッション管理についての概念を学習します。

Webアプリケーションによるサービスを提供するにあたっては、Webアプリケーション・サーバー以外の複数のサービス、HTTPサーバーやデータベース・サーバーと連携することが一般的です。また、Webアプリケーション・サーバーであるTomcatの中でもさまざまな機能が連携して、ブラウザからのリクエストに対するサービスを提供しています。この章では、Tomcatがさまざまな機能を提供するコンポーネントについて学習していきます。

Tomcatはネストされた複数のコンポーネントからなり、トップレベル・コンポーネント、コネクタ、コンテナ、ネスト化コンポーネントに分類されます。コンポーネントのいくつかはトップレベル・コンポーネントと呼ばれ、階層の一番上位に位置します。また、コンテナと呼ばれるコンポーネントは、他のコンポーネントの入れ物となります。 自分自身は他のコンポーネントの入れ物とは成り得ず、コンテナ内に入ることだけができるコンポーネントをネスト化コンポーネントと呼びます。

トップレベルコンポーネントは、階層構造からなるコンポーネントの最上位に来るコンポーネントです。

■Server：Webアプリケーション・サーバーのインスタンスで、Tomcat自身です。　停止リクエストを受け付けるポートを所有しており、サーバーのシャットダウンに使用されます。このポートへのアクセスは、Tomcatを実行しているコンピュータからしか行えません。ファイルの中に記述できるServerは１つだけです。

■Service：1つのエンジン（コンテナ）に接続されるすべてのコネクタをあらわしたものです。　コネクタは特定のプロトコルによって特定のポートに到着したリクエストを受け付け、処理を行うエンジンに引き渡します。 そのため、Serviceには1つ以上のConnector要素と1つ以上のEngine要素が必要です。

■コネクタ（Connector）：コネクタはWeb アプリケーションとクライアントの橋渡しを行います。　コネクタはクライアントからのリクエストを受け取り、サーバーのポートへ送ります。デフォルトのコネクタはCoyoteで、HTTP 1.1をサポートし、ブラウザとの直接的な接続を行います。コネクタには、上図のようないくつかの種類があります。

ここでは、他のコンポーネントの入れ物ともなるコンテナ・コンポーネントについて学習します。

■Engine：リクエストを処理するコンポーネントです。　EngineはHTTPヘッダをチェックして、どの仮想ホストまたはContextにリクエストを渡すか判別します。 HTTPサーバーにJavaサーブレットのサポートを提供するよう設定している場合は、HTTPサーバーがリクエストの正しい宛先を判別します。

■Host：Apacheの仮想ホストと似た機能を持っており、リクエストの処理を行うホストを表現したものです。　1つのEngine上で複数のホストを使用することを可能とします。仮想ホストとは、複数ドメインに対するサービス要求を単一のサーバーで対処する機能です。 Apacheの仮想ホストでは、名前ベースまたはIPベースの仮想ホストで識別されますが、Tomcat での仮想ホストはFQDN（完全修飾ホスト名）によって識別されます。 そのため、Hostの設定では、ホスト名を決定します。このホスト名は、DNSやhostsファイルで名前解決される必要があります。

■Context：Webアプリケーション（warファイル）は、コンテキストとも呼ばれます。　Webアプリケーションを設定するには、Engine/Hostに知らせる必要があります。動的なリロードを可能にしておけば、クラスが変更されるたびにリロードされ、最新のWebアプリケーションが実行されます。

■レルム：セキュリティを提供するもので、ユーザー認証と許可を管理します。レルムはEngine全体に対して適用されます。レルム方式とは認証を行う際のユーザー、パスワード、ロール情報にアクセスする際のアクセス方法で、JDBC経由やJNDI経由などのいくつかの方法がありますが、デフォルトではtomcat-users.xmlファイルの情報をメモリに格納して使用します。ロール（役割）はユーザーをグループ化するものです。管理者は各リソースにアクセスできるロールを設定します。

■バルブ：バルブはリクエストをインターセプトし、事前処理するためのコンポーネントです。　 Server上のすべてのHostへのログインの単一化（シングル・サインオン）に使われたり、リクエストのパターン、クライアントのIPアドレス、サーバーの使用パターン(ピーク・トラフィック、帯域の使用、単位時間当たりの平均リクエスト数）などをログに出力するのに使われます。

Tomcatの設定は、server.xmlというファイルに記述されています。server.xmlファイルを変更した場合は、Tomcatを再起動することにより反映されます。< Server >要素の下に< Service >要素が、< Service >要素の下に< Connector >要素と< Engine >要素が、 < Engine >要素の下に< Realm >と< Host >要素が定義されています。 < Connector >と< Realm >以外はname属性があり、名前がつけられています。< Host >要素にはデフォルトでlocalhostが登録されています。任意の新しいホストを登録することもできます。

コネクション・プーリングとは、データベースへの接続（コネクション）を保持（プール）しておくことです。 一般的なアプリケーションでは、データベースに対してリクエストがあるたびに接続を確立します。 リクエストごとにコネクションの確立・切断をしていると時間がかかり、コネクション数が増えた場合にパフォーマンスの低下や、 システムの安定性にも影響が出る可能性があります。コネクションを管理するクラスがあらかじめ設定された数のコネクションを確立し、 Webアプリケーションからの要求によってコネクションを貸し出し、Webアプリケーションはデータベース処理が終わったらコネクションを管理クラスに返します。

データソース(DataSource) とは、プログラムとデータベースへの接続との間のインタフェースで、データベースへの接続を取得するために使用されます。 データソースを取得するには通常JNDI（Java Naming Directory Interface）を使用します。データソースを使用して取得できるのは、Connectionオブジェクトです。

Javaプログラムからデータベースに接続する方法は2種類あります。 従来から使用されているJDBCのDriverManagerを使用する方法と、JDBC 2.0から使用できるようになったDataSourceを使った方法の2つです。データベースにアクセスするたびにDriverManagerで接続するのは非常に効率が悪くなります。 パフォーマンスを向上させるためには、コネクション･プールを利用します。コネクション･プールの利用には、データソースを使用します。

DriverManagerの場合、データベース接続に必要なデータベース・ドライバやURLなどの情報をプログラム内に記述します。そのため、データベースが変更された場合、プログラムの変更を伴います。データソースの場合、プログラムにはデータベースに対する論理的な名前を記述し、実際に必要なデータベースの情報はxmlファイルに記述します。したがって、データベースが変更された場合でも、プログラムの変更は必要なく、xmlファイルのデータベース情報を変更することにより対応できます。

DriverManager接続では、使用するデータベースの環境が変更されると、データベースにアクセスするプログラムの記述も変更しなければなりません。たとえば、テスト環境と本番環境では使用するデータベースが異なりますから、データベースのurlは変更しなければなりませんし、接続するユーザーやパスワードも異なるでしょう。もしデータベース製品も異なるのであれば、データベース・ドライバの変更も必要になります。

データソースを使用する場合、データベースへの接続はTomcatが行います。データソースを利用するには、JNDIサービスが動いているサーバーが必要です。TomcatにはJNDIサービスの機能があるので、それを利用します。JNDIのリソースの設定は、Tomcatのserver.xmlに< Resource >要素として記述します。ここで設定するJNDI上のリソース名をグローバル名といいます。

Webアプリケーション側では、データソースを使用してデータベースに接続するサーブレット等を作成します。 データソースはJNDIルックアップで取得できます。ルックアップの引数には、

java:comp/env/ローカル・リソース名

を指定します。このjava:comp/envで始まる名前をローカル名といいます。

この2つを結びつけるのが、リソースリンクとなります。 リソースリンクはXMLファイルで、ローカル名とグローバル名のマッピングを行います。使用するデータベースの変更の際には、新しいデータベース用にデータソースの定義をserver.xmlに行い、 リソースリンク・ファイル上のグローバル名を新しいデータベースのデータソースに変更することにより、Webアプリケーション側のローカル名の変更を行うことなく、アクセスするデータベースが切り替わります。Webアプリケーション側で変更をすると、プログラムのコンパイルとパッケージングおよびTomcatへの再デプロイが必要となります。

■JNDI：Javaでネーミング・サービス、ディレクトリ・サービスを利用できるようにするAPI　ネーミング・サービスとは、文字列で表現される名前と特定のオブジェクトとを関連づけるサービスで、論理名（JNDI名）を指定すると、それに対応するオブジェクトを得ることができます。ディレクトリ・サービスとは、各オブジェクトが属性を持つことができ、属性による検索をサポートするサービスで、JNDIのサービスを利用してDataSourceを取得しますが、他にもJMS（Java Message Service）の管理オブジェクトやEJB（Tomcatでは使用不可）などを取得する際にも用いられます。

0. サーバーの構成ファイルからJNDI名とリソースの情報を取得して、DataSource/JMS/EJBオブジェクトを生成し、JNDIがJNDI名とオブジェクトを紐付ける1. Javaプログラムは、JNDIに対してJNDI名に対応するリソースを問い合わせる2. JNDIは、JNDI名に対するリソースをJavaプログラムに返す3. Javaプログラムは、2.で取得したリソースに対して操作を行う

■JNDIを利用するメリット：リソースを、JNDIを用いてJavaのプログラムからJNDI名で呼び出しを行うことによって、リソースの実体をJavaのプログラムから隔離することができます。このことにより、環境の変化（DBの変更など）によってJavaプログラムを変更する必要がなくなり、アプリケーションのポータビリティが向上すると言えます。