|
|
WebOTX Manual V10.1 (第7版) 目次を表示 |
|
|
|
WebOTX Manual V10.1 (第7版) 目次を表示 |
アプリケーションサーバでのWeb 層では、World Wide Web 上で活用されるコンテンツやアプリケーション のビジネスロジックを生成します。この章では、WebOTX の機能階層の中で、特にWeb 層に含まれる、 HTTP サーバとWeb コンテナが提供する機能について説明します。
インターネットの普及とともにWorld Wide Web (WWW)技術は急激に進展しています。当初、WWW は情報 共有・情報発信を目的とした静的なコンテンツ配布が中心でしたが、今日では顧客との新しいチャネル や企業間取引き、外出する営業マンのアクセスポイントなどの動的なコンテンツを使った業務システムと して利用されています。アプリケーションサーバは、動的コンテンツを効率良く生成・処理する基盤として 発展してきました。
従来、企業内の業務システムで多く使われてきたクライアント・サーバシステムはサーバコンピュータの 負荷をクライアントにオフロードし、高い操作性を提供するというメリットがありましたが、技術変化が激し い今日では、クライアントのハードウェア・ソフトウェアの頻繁な入れ替えによるTotal Cost of Ownership (TCO) の増大という新たな問題を発生させました。そのため、WWW 技術をクライアント通信に利用する WebComputing をベースとした業務システムの再構築が行われるようになっています。
HTTPサーバは Web システムの中核を成し、クライアント上のWeb ブラウザからHTTP リクエストを受信し 応答を返却するソフトウェアです。 静的なHTML に対しては単独でWeb サービスを提供することができます。WebOTX では HTTPサーバとして、Java ベースのHTTP サーバと、Apache Software Foundation のApache HTTP Server 2.4 をベースとした、WebOTX Webサーバをバンドルしています。これらのHTTPサーバは、 Secure Socket Layer (SSL) 3.0 およびTransport Layer Security (TLS) 1.0/1.1/1.2 をサポートしており、インターネットを使った安全な通信を提供します。 他にも次に示すWeb サーバを利用することができます。
| Web サーバ | Windows | HP-UX | Linux |
|---|---|---|---|
| Microsoft Internet Information Server (IIS) | 7.0, 7.5, 8.0, 8.5, 10.0 | - | - |
| Apache HTTP Server | 2.4.29 以上 | 2.4.29 以上 | 2.4.29 以上 |
WebOTX が対象とするクライアントは、World Wide Web のブラウザ(以下Web ブラウザと呼びます)のThin クライアント、Web ブラウザ内で動作するApplet クライアント、Web ブラウザと独立して動作するRich クラ イアントがあります。
Web ブラウザは、Hyper Text Transfer Protocol (HTTP) やSecure Sockets Layer (SSL) で暗号化されたHTTPS プロトコルを使って、HTTP サーバと通信を行います。HTTP プロトコルやHTTPS プロトコルでは、 Uniform Resource Locators (URL) を使って、世界で一意のサーバ上の資源にアクセスします。URL は 次のフォーマットを持っています。
スキーム://ホストアドレス［:ポート］/ホスト内資源アドレス
スキームはHTTP プロトコルなら「http」、HTTPS プロトコルなら「https」を指定します。
ホストアドレスはIP アドレスまたはホスト名を指定します。ポートはプロトコルごとの既定値として http は80、https は443と決まっています。ホスト内資源アドレスはホスト内で資源を特定するために使 用されるもので一般的にはファイルのディレクトリパスを指定します。
ポートを分けることで、1台のサーバマシン上で本番用、テスト用のように複数のWeb サーバを起動する ことができます。また、既定値以外のポートを使うことで一般の人からは発見しにくいWeb サーバを運用 することもできます。逆にApplication Service Provider (ASP) やInternet Service Provider (ISP) のよう に1台のサーバマシンで複数のホストアドレスを提供したいという考え方があります。数千、数万の企業 に対してデータセンタでWeb サーバを提供するとしても、サーバ台数をそれだけ用意するのは困難で す。このような場合、仮想IP アドレスを使って、1つのWeb サーバが複数のホストサーバの振りをして動 作します。
負荷分散装置を使った場合には別の概念の仮想IP アドレスが出現します。HTTP サーバの可用性を高 めるためにも、スケーラビリティを高めるためにもHTTP サーバを複数台用意して負荷分散を行い、ブラ ウザからは1つのサーバのように見せることは良く行われている技術です。この場合、各HTTP サーバ マシンの実際のIP アドレス(実IP)に対して、負荷分散装置が外に向けて見せるIP アドレスを仮想IP ア ドレスと呼びます。
Web コンテナは、Web アプリケーションである Servlet/JSP を動作させるための実行基盤です。Web アプリケーションは、Web コンテナの提供する各種機能を使って、 クライアントからの入力データを解析し動的な HTML を生成するサーバサイドの Java アプリケーションです 2層のモデルでは Web アプリケーションはプレゼンテーション層からアプリケーション層（ビジネスロジック層） までを実現します。3 層モデルではプレゼンテーション層のみを実現します。
WebOTX の Web コンテナは、この Web アプリケーションの実行環境に加えて、Web コンテナの運用管理を行う機能を提供します。 WebOTX の提供する Web コンテナは、Tomcat 8.5 をベースに以下の機能を独自に強化しています。
Web コンテナに求められるのは何より性能です。Servlet/JSP の互換性を維持しつつ、可能な限り の性能向上を図っています。
トラフィックの増大に対応するために Web サーバマシンをクラスタ化することができます。クラスタ上 の Web コンテナ間でセッション情報とセッション情報に格納されたデータの共有を行うことで、セション 情報にアクセスする Servlet/JSP をどのクラスタ上でも動作させることができます。
Web ブラウザからドメインの管理ができる運用管理ツールです。次のような操作が行えます。
HTTP/HTTPS プロトコルではWeb ブラウザからの要求とサーバからの応答が一組で動作し、明確なセッ ションという概念がありません。 一方、業務システムではクライアントとの複数回の通信の中で状態を変更して業務を遂行していくスタイルが一般的です。 そのため HTTP/HTTPS プロトコル上で論理的なセッションを管理する必要性が出てきました。
HTTP/HTTPS プロトコルのセッション管理は、Cookie、URL Rewriting、Hidden TAG を使うのが一般的です。 これらは論理セッションであり、解放プロトコルが存在しません。 上位でログオフを作る、またはタイムアウトでセッションの消滅を行うことになります。 ログオフ操作は永久に行われないかもしれませんので、業務要件に合わせて、タイムアウト時間を設定し、 資源の解放漏れがおこらないようにする必要があります。
Web コンテナでは、Web コンテナとしてのセッション管理に Cookie を利用するか、 URL Rewriting を利用するかを選択できます。 この選択は、Webコンテナの「運用管理コンソール」でおこないます。Web サーバは、 Web コンテナの設定した Cookie もしくは URL の値を Web ブラウザに引き継ぎ、 Web ブラウザから送信されたデータとともに Cookie もしくは URL の値を Web コンテナに引き渡します。 これらの値は Web コンテナ上で動作する Web アプリケーションから参照することもできます。 また、Web アプリケーションで独自の ID を設定することもできます。
Web クライアントが携帯電話などの場合、Cookie を処理することができません。この場合には、URL Rewriting を利用するか、Hidden TAG を利用することになります。
Servlet/JSP の特定は URL により行われます。 業務システムでは静的なメニューページやログインServlet から順番にターゲット業務を行う Servlet へと遷移していくのが一般的です。 WebOTX では アプリケーション単位の閉塞・閉塞解除機能を提供しています。 Servlet/JSP を動的に置換すると後続の Servlet/JSP との間で矛盾を起こすことがありえますが、 この機能を使えば処理中のトランザクションがなくなった時点で、 安全に Web アプリケーションの置換を行うことができます。
負荷分散装置 (サーバスイッチ等) を用いて、複数のWeb サーバをクラスタ化し、Web アプリケーション で買い物かごのようにセッション情報を管理するシステムに対応します。Web アプリケーションへの特別 なコーディングなしで、Web サーバのクラスタ化に対応ができます。
この場合、Web アプリケーションでセッションオブジェクトに保存する情報は、シリアライズ可能なオブジェ クトになります。また、Web アプリケーションが Web サーバのクラスタ化に対応していることを示すために、 配備記述子（web.xml）に<distributable>要素の指定をします。
セッション情報のサーバ間共有に関しての詳細は「 セッションレプリケーション」を参照してください。
通常、BASIC 認証や FORM 認証では、クライアントからユーザ名とパスワードを受け取り、 認証処理を行います。 しかし、場合によっては、Servlet/JSP のプログラムで認証をするほうが便利なことがあります。
Servlet/JSP のプログラムでユーザ名とパスワードを指定し、認証 API を呼び出すことにより、BASIC 認 証および FORM 認証を行うことができます。
Web コンテナは、WebOTX の各エディションによって 2 つの異なる機能構造を持っています。
1 つは、Webコンテナが 1 つのJava 仮想マシン上で動作する機能構造で、もう 1 つは、
Web コンテナが WebOTX アプリケーションサーバへのプラグインとして動作する機能構造です。
前者はアプリケーションをエージェントプロセスに配備した場合に機能し、
後者はアプリケーションをプロセスグループに配備した場合に機能します。
WebOTX の各エディションのサポート状況は下表のようになっています。
| エディション | アプリケーションをエージェントプロセスに配備 | アプリケーションをプロセスグループに配備 |
|---|---|---|
| WebOTX Application Server Express | ||
| WebOTX Application Server Standard |
これは、Webコンテナを運用管理エージェントの Java VM プロセス(エージェントプロセス)で 動作させるもので、Java EE 技術をベースにした Web ベースのシステムを迅速に開発・運用することができます。 EJB を利用しない Web アプリケーションを動作させるのであれば、 アプリケーションをプロセスグループに配備した場合よりも高速に動作します。また、メモリ消費量も削減されます。 その反面、システム障害に対する多重化のような高度な機能を持ちません。
これは、Web コンテナを TP モニタ内に配置して複数の Java VM プロセスで多重化し TPモニタで制御するもので、高い信頼性が要求される基幹業務システムを構築することができます。 Web アプリケーションから EJB を利用する形態の Java EE アプリケーションであれば、 Web コンテナと EJB コンテナが同一の Java VM 上で動作するので、高速に動作します。 またこの場合、WebOTX システムを載せたマシンを複数台クラスタ構成で構築したより 高信頼・高可用性のある運用をサポートします。
HTTPサーバに組み込まれたWebサーバプラグインがHTTPサーバに届いたサーブレットへのリクエストを処理するために、リクエストデータをWebコンテナに転送します。 HTTPサーバとWebコンテナはそれぞれ別々のホスト上で動作させることが可能なため、運用者に分かりやすいようHTTPサーバとWebコンテナの構成形態を『トポロジ』と定義しています。トポロジには以下の2種類があります。
それぞれのトポロジについて以下に説明します。
HTTPサーバとWebコンテナが同じホスト上に存在する場合は共存トポロジです。
下記の図の実線と点線は連携相手を示したもので、実線はドメイン作成完了直後から、点線はドメイン作成完了後に設定を変更する事で、連携可能になる事を示します。この関係線に沿った構成であれば共存トポロジです。
HTTPサーバとWebコンテナが別のホストに分かれて存在する場合は分離トポロジです。
下記の図の実線と点線は連携相手を示したもので、実線はドメイン作成完了直後または初期設定ツールによる初期設定直後から、点線は初期設定後に設定を変更する事で、連携可能になる事を示します。この関係線に沿った構成であれば分離トポロジです。
