パート 6. サーブレットコンテナ

この資料は「エンタープライズ開発入門」シリーズの一部です。以前の記事:

前回の記事では、サーブレットについて理解し、それを使用して Web アプリケーションを作成する方法を学びました。この楽しみの重要な部分であるサーブレットコンテナを詳しく見てみる時期が来ました。

サーブレットコンテナとは何ですか?

これはサーバー上で実行され、作成したサーブレットと対話できるプログラムです。つまり、Web アプリケーションをサーバー上で実行したい場合は、まずサーブレットコンテナをデプロイし、次にその中にサーブレットを配置します。ワークフローは単純です。クライアントがサーバーにアクセスすると、コンテナはそのリクエストを処理し、どのサーブレットで処理するかを決定し、リクエストを渡します。パート 6. サーブレットコンテナ - 2

サーブレットコンテナはどのように使用されますか?

リクエストのルーティングに加えて、サーブレットコンテナは他の機能も実行します。

JSP ファイルから HTML ページを動的に生成します。
HTTPS メッセージを暗号化/復号化します。
サーブレット管理のための制限されたアクセスを提供します。

一般的に、これはすべて良いことのように思えます。あとは、それをすべて実践する方法を考え出すだけです。まあ、何かの使い方を学ぶには、とにかく飛び込んで使ってみることです:)それでは、今日は練習してみます! 最も人気のあるサーブレットコンテナはApache Tomcatです。オープンソースであり、無料で使用できます。ここからお使いのオペレーティングシステム用の Tomcat をダウンロードして、「動作中の」コンテナーの操作を検討していきます。

Tomcatのインストールと起動

Tomcat をインストールするには、ダウンロードしたアーカイブを目的のディレクトリに解凍するだけです。
Tomcat を起動して実行するには Java バージョン 8 以降が必要であることに注意してください。JAVA_HOME 環境変数が JDK の現在のバージョンを参照していることを確認します。
次に、 Tomcat へのユーザーアクセスを構成する必要があります。これは、conf フォルダーにある tomcat-users.xml ファイルで行われます。

Tomcat には 4 つの事前設定された役割があります。
- manager-gui — グラフィカルインターフェイスおよびステータスページへのアクセス
- manager-script — テキストインターフェイスとステータスページへのアクセス
- manager-jmx — JMX およびステータスページへのアクセス
- manager-status — ステータスページへのアクセスのみ
<tomcat-users> タグ内で、これらのロールを明示的に指定し、ユーザーに割り当てます。
```
<role rolename="manager-gui"/>
<role rolename="manager-script"/>
<role rolename="manager-jmx"/>
<role rolename="manager-status"/>
<user username="user" password="password"
    roles="manager-gui, manager-script, manager-jmx, manager-status"/>
```
これですべてを起動する準備が整いました。
bin フォルダーで、startup.bat ファイル (Linux の場合は startup.sh) を実行します。
数秒後、ブラウザでリンクhttp://localhost:8080/を開きます。グラフィカルなダッシュボードが表示されます。

このようなメニューが表示されたら、Tomcat が実行されています。
実行されていない場合は、JAVA_HOME 環境変数と CATALINA_HOME 環境変数を手動で確認します。
- JAVA_HOME — これは Java 8 以降の現在のバージョンを参照する必要があります。
- CATALINA_BASE — これは Tomcat を参照するか、存在しない必要があります (Tomcat の別のバージョンを参照しないでください)。

Tomcat でのアプリケーションのデプロイ

Tomcat を起動できたので、そこにプロジェクトをデプロイします。前の記事のサーブレットを使用してみましょう。メインサーブレット:

import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.http.HttpSession;
import java.io.IOException;
import java.io.PrintWriter;

@WebServlet("/hello")
public class MainServlet extends HttpServlet {

   @Override
   protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws IOException {
       HttpSession session = req.getSession();
       Integer visitCounter = (Integer) session.getAttribute("visitCounter");
       if (visitCounter == null) {
           visitCounter = 1;
       } else {
           visitCounter++;
       }
       session.setAttribute("visitCounter", visitCounter);
       String username = req.getParameter("username");
       resp.setContentType("text/html");
       PrintWriter printWriter = resp.getWriter();
       if (username == null) {
           printWriter.write("Hello, Anonymous" + "");
       } else {
           printWriter.write("Hello, " + username + "");
       }
       printWriter.write("Page was visited " + visitCounter + " times.");
       printWriter.close();
   }
}

インデックスサーブレット:

import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;

@WebServlet("/")
public class IndexServlet extends HttpServlet {

   @Override
   protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws IOException {
       resp.sendRedirect(req.getContextPath() + "/hello");
   }
}

デプロイする前に、サーブレットを WAR ファイルにパッケージ化する必要があります。通常、これを行うには Maven が使用されますが、WAR ファイルを作成するには、すべてのサーブレットのマッピングを含む web.xml ファイルが必要です。新しい @WebServlet アノテーションを使用してサーブレットを作成したため、web.xml ファイルはありません。幸いなことに、IDEA は私たちの代わりにプロジェクトを WAR ファイルにラップするという面倒な作業を行ってくれます。これを行うには、プロジェクト構造を開きます (Ctrl+Shift+Alt+S) -> アーティファクト -> 目的の WAR ファイルを選択します -> 「プロジェクトのビルドに含める」の横のチェックボックスを選択します -> 「OK」をクリックします。パート 6. サーブレットコンテナ - 4

Ctrl+F9 キーの組み合わせを使用してプロジェクトをビルドしましょう。これで、WAR ファイルがターゲットディレクトリにあります。パート 6. サーブレットコンテナ - 5

このファイルの名前をもっと単純なもの (例: servlet.war) に変更し、より便利な場所 (例: C:\\my\\) に移動できます。コンテナに入れていきます。これを行うには 2 つの方法があります。

グラフィカルインターフェイスの使用

これを行うには、リンクhttp://localhost:8080/manager/htmlに従ってください。Tomcat はユーザー名とパスワードを要求する必要があります。

ここまで説明を進めてきた場合、ユーザー名は「user」、パスワードは「password」であることが分かります。

サインインに成功すると、Tomcat Web Application Manager が表示されます。「アプリケーション」セクションにはすでに 5 つのアプリケーションが含まれています。これらは、Tomcat の操作を容易にする Tomcat ユーティリティです。これらは将来削除される可能性があります。

以下は「デプロイ」セクションです。ここで、デプロイする WAR アーカイブを選択できます。パスとコンテキストを手動で入力してみましょう。

「デプロイ」をクリックすると、アプリケーションが「アプリケーション」セクションに表示されていることがわかります。
Tomcat のグラフィカルインターフェイスを使用すると、セッションを停止、再開、削除したり、セッションの長さを設定したりできます。デプロイ時に /demo コンテキストを指定しました。これは、アプリケーションがhttp://localhost:8080/demoを使用してアクセスされることを意味します。確認してください。すべてが機能するはずです。
ファイルシステム経由

この方法でアプリケーションをデプロイするには、Tomcat が解凍されたディレクトリを開く必要があります。次に、「webapps」フォルダーに移動します。ここには、すでに紹介したユーティリティがあります。

必要なのは、servlet.war ファイルをここに移動することだけです。

数秒待つと、新しい「サーブレット」フォルダーが表示されることがわかります。これは、アプリケーションがデプロイされたことを意味します。http://localhost:8080/manager/にあるアプリケーションマネージャーインターフェイスに移動します。ここでは、アプリケーションが /servlet コンテキストにデプロイされていることがわかります。

この方法でデプロイすると、デプロイされた WAR ファイルの名前に基づいてコンテキストが自動的に割り当てられます。コンテキストを変更するには、アプリケーションを含む新しく作成したフォルダーの名前を変更できますが、その前に WAR ファイルを削除する必要があります。それ以外の場合、Tomcat はアーカイブ名を使用してアプリケーションを再デプロイします。

ご覧のとおり、Tomcat でのアプリケーションのデプロイは、思っているよりもはるかに簡単です。しかし、他の機能も使いやすいです。確認しよう。

HTTP の代わりに HTTPS を使用する

覚えている方は、HTTP と HTTPS の違いについては別の記事で説明しました。HTTPS は HTTP と同じプロトコルですが、送信されるデータを暗号化します。クライアント側ではブラウザが暗号化を担当しますが、サーバー側で暗号化を提供する必要があります。Tomcat は HTTP リクエストを受け入れてルーティングするため、Tomcat に暗号化を委任するのは理にかなっています。これを行うには、次のことを行う必要があります。

自己署名証明書を生成する
追加のサーバー設定を行う

これを練習してみましょう。

証明書の生成

バージョンに関係なく、JDK には多数のユーティリティが含まれています。そのうちの 1 つはkeytoolです。これは、暗号化キーを生成および操作するためのツールです。これを使用するには、コマンドラインでC:\\Program Files\\Java\\jdk1.8.0_181\\binディレクトリに移動し、コマンドkeytool -genkey -alias tomcat -keyalg RSAを実行します。

keytool — コマンドラインオプションを使用して実行しているユーティリティの名前
-genkey — 新しいキーを生成することを示します
-alias tomcat — キーのエイリアスを作成する
-keyalg RSA — 鍵生成アルゴリズムとして RSA を選択します

コマンドを実行すると、ユーティリティはダイアログを開始します。パート 6. サーブレットコンテナ - 11

必要な情報を入力します。これで、ホームディレクトリ (Windows の場合、C:\\Users\\{username}\\.keystore) にキーストアが作成され、その中に Tomcat キーが作成されました。私たちは、ほとんどのブラウザーが問題を引き起こす単純な証明書を生成しました。このような証明書は商用アプリケーションには適していません。テスト目的でのみ使用できます。運用サーバーでは、証明機関 (例: https://letsencrypt.org/ ) からの証明書を使用する必要があります。

サーバーの構成

証明書の準備ができたので、サーバー設定、つまり SSL コネクタを調整する必要があります。これは、 apache-tomcat-9.0.30/conf/にある server.xml ファイルで行われます。その中には次のようなブロックがあります。

<Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol"
               maxThreads="150" SSLEnabled="true">
        <SSLHostConfig>
            <Certificate certificateKeystoreFile="conf/localhost-rsa.jks"
                         type="RSA" />
        </SSLHostConfig>
 </Connector>

そして、その隣に設定を置きます。

<Connector
       protocol="org.apache.coyote.http11.Http11NioProtocol"
       port="8443" maxThreads="200"
       scheme="https" secure="true" SSLEnabled="true"
       keystoreFile="C:\Users\user\.keystore" keystorePass="mypass"
       clientAuth="false" sslProtocol="TLS"/>

最新の値を keystoreFile パラメータと keystorePass パラメータに割り当て、ファイルを保存してから、shutdown.bat ファイルとstartup.bat ファイルを使用して Tomcat を再起動します。これで、サーバーは HTTPS リクエストを処理する準備が整いました。アドレスが少し変更されました: https://localhost:8443/demo/hello。リンクをクリックすると、証明書の信頼性に関する警告が表示されますが、これは驚くべきことではありません。先ほども述べたように、通常の証明書を取得するには、いずれかの認証局のサービスを利用する必要があります。しかし現時点では、アプリケーションが HTTPS プロトコルを使用して実行されるという目標は達成できました。これは重要です。

HTMLページを動的に生成する

ここで、サーブレットコンテナの概要を続けて、別の機能である HTML ページの動的生成を検討します。退屈な静的 HTML コードの代わりに、変数、ループ、配列、その他の言語構造を使用して Java コードを作成できる完璧な世界を想像してみてください。想像できましたか？良いニュースは、同様のものが存在するということです。悪いニュースは、この幻想を完全には実現していないことです。想像していない方のために説明しますが、これは JavaServer Pages (JSP) について話しています。一言で言えば、これは Java コードの一部を HTML ページに挿入できるテクノロジーです。確かに、この Java コードはクライアントに送信される前に HTML に変換されますが、その HTML はさまざまな要素を考慮して動的に生成されます。例えば、条件ステートメントを使用すると、条件に応じて異なるコンテンツを返すことができます。JSP ページの例:

<%@ page language="java"" %>
<html>
<head>
<title>JSP</title>
</head>

<body>
<%
String firstName="name";
String secondName="surname";

    if (firstName.equals("name")){
      out.print("Hello: "+firstName+"<br>");
    }

    if (firstName.equals("name") && secondName.equals("surname"))
    {
      out.print("Hello, my dear friend! <br>");
    }
    else
    {
      out.print("I don't know you. Go away! <br>");
    }
%>
</body>
</html>

JSP について詳しくは、こちらをご覧ください。。結局のところ、この記事は JSP についてではなく、サーブレットコンテナについて話したいのです。では、なぜ JSP について言及したのでしょうか? それは簡単です。サーブレットコンテナは、Java コードを JSP から HTML に変換するものです。サーブレットが応答として JSP コンテンツを返そうとすると、コンテナはそれを記録し、まずそのコンテンツをブラウザに適した HTML ページに変換してから、そのようなコンテンツをクライアントに送信します。現在、Thymeleaf、FreeMarket、Mustache など、JSP テクノロジに類似したテクノロジが多数存在します。それらはすべて同じように機能します。あなたの作品にどれを選ぶかは好みの問題です。これは、サーブレットコンテナの選択にも当てはまります。これらの例では、最も一般的なコンテナーである Tomcat を使用しましたが、プロジェクトによっては他のコンテナーを使用する場合もあります。最も人気のあるものを簡単に確認し、Tomcat との違いを検討することは価値があります。

Tomcatの代替品

GlassFishは、Oracle によって開発がサポートされているオープンソースコンテナです。

Tomcat とは異なり、これは本格的な Web サーバーであり、サーブレットに加えて、JavaEE フレームワークの他のコンポーネントと連携して動作できます。とはいえ、より多くのRAMを使用します。サーバーを微調整する際の柔軟性が高まるため、使用が複雑になります。JavaEEフレームワークでアプリケーションを開発する場合に使用する必要があります。
WildFly は、以前はJBossとして知られていました。これはオープンソースでもあります。Red Hat によって開発されました。この名前は、同社の別の製品である JBoss Enterprise Application Platform との混同を避けるために変更されました。

GlassFish と同様、WildFly は本格的な Web サーバーです。ちなみに、WildFly は内部的には Tomcat をサーブレットコンテナとして使用します。GlassFish とは異なり、WildFly はより軽量で、構成が簡単です。
Jetty は、これまでのものと同様、オープンソースです。エクリプスによって開発されました。

Tomcat と同様、これは単純なサーブレットコンテナであり、JavaEE フレームワークのすべてのコンポーネントはサポートされていません。同時に、より軽量になり、携帯電話でも実行できます。起動と停止が速く、拡張性も優れています。Tomcat とは異なり、小規模なコミュニティと知識ベースがあります。
WebLogic はライセンスを取得したソフトウェアであり、使用する前に購入する必要があります。オラクルに属します。

Tomcat よりもわずかに幅広い機能を備えています。FTP プロトコルで動作できます。ただし、アプリケーションの開発とテストにはそれほど柔軟性がありません。
WebSphere (正確には WebSphere Application Server) は有料のソフトウェアです。IBMによって開発されました。WildFly や GlassFish と同様、完全なアプリケーションサーバーです。しかし、より使いやすい設定インターフェイスと、高い動作信頼性を備えています。

欠点としては、大量のリソースを使用し、開始と停止に時間がかかるため、小規模なプロジェクトを開発する場合にはあまり便利ではありません。

適切なサーブレットコンテナまたはアプリケーションサーバーの選択は、特定のプロジェクトによって異なります。明らかな劣勢であっても優れた選択であることが判明するプロジェクトもありますが、最初は 1 つのサーブレットコンテナについて詳しく調査することが最善です。Tomcat はおそらくこの研究に最適な候補です。私たちはすでに研究の第一歩を踏み出しましたが、ここからはあなた次第です。「エンタープライズ開発入門」シリーズの最終記事では、MVC パターンについて説明します。パート 7. MVC (Model-View-Controller) パターンの紹介