Oracle® Fusion Middleware Oracle WebLogic Server Webアプリケーション、サーブレット、JSP の開発 11g リリース1 (10.3.5) B60993-03 |
|
前 |
次 |
次の項では、WebLogic Server Webアプリケーション、サーブレット、およびJavaServer Page (JSP)の概要を説明します。
Webアプリケーションには、サーブレット、JavaServer Pages (JSP)、JSPタグ・ライブラリなどのアプリケーションのリソースと、HTMLページや画像ファイルなどの静的リソースが組み込まれています。Webアプリケーションにより、アプリケーションにservice-ref (Webサービス)およびmessage-destination-ref (JMS送り先/キュー)が追加されます。また、Enterprise JavaBeans (EJB)などの外部リソースへのリンクも定義できます。
Java Platform, Enterprise Edition (Java EE)バージョン5.0プログラミング・モデル(http://java.sun.com/javaee/reference/
を参照)の重要な点は、メタデータ・アノテーションが導入されたことです。アノテーションを使用すると、コンテナ内でのアプリケーション・コンポーネントの動作、依存関係インジェクションのリクエスト方法などをJavaクラス自体の中で指定でき、アプリケーションの開発プロセスを簡略化できます。アノテーションは、エンタープライズ・アプリケーションの以前のバージョン(J2EE 1.4以前)で必要とされたデプロイメント記述子に代わるものです。
Java EEアノテーションの使用により、標準のapplication.xml
およびweb.xml
デプロイメント記述子は省略可能になりました。Java EEプログラミング・モデルでは、EJB、サーブレット、Webアプリケーション、JSPなどのWebコンテナに対してJDK 5.0アノテーション機能を採用しています。第8章「Webコンポーネント用のWebLogicアノテーション」およびhttp://java.sun.com/javaee/5/docs/api/
を参照してください。
ただし、WebLogic ServerにデプロイされるWebアプリケーションは、標準のJava EEデプロイメント記述子ファイルとWebLogic固有のデプロイメント記述子ファイルを引続き使用して、それらのリソースと操作属性を定義できます。
JSPとHTTPサーブレットは、WebLogic Serverで使用可能なすべてのサービスとAPIにアクセスできます。これらのサービスには、EJB、Java Database Connectivity (JDBC)によるデータベース接続、Java Messaging Service (JMS)、XMLなどがあります。
Webアーカイブ(WARファイル)には、Webアプリケーションを構成するファイルが格納されます。WARファイルは、1つまたは複数のWebLogic Serverインスタンスに1つの単位としてデプロイされます。WebLogic ServerにデプロイされるWARファイルには、常に次のファイルが含まれます。
1つのサーブレットまたはJava Server Page (JSP)、およびヘルパー・クラス。
(オプション) web.xml
デプロイメント記述子(WARファイルの内容を記述するJava EE標準のXMLドキュメント)。
weblogic.xml
デプロイメント記述子(Webアプリケーション用のWebLogic Server固有の要素が格納されるXMLドキュメント)。
WARファイルには、HTMLページまたはXMLページ、およびそれらに付属する画像やマルチメディア・ファイルなどのサポート・ファイルを含めることもできます。
WARファイルは、単独でデプロイすることも、他のアプリケーション・コンポーネントとともにエンタープライズ・アプリケーション・アーカイブ(EARファイル)にパッケージ化することもできます。単独でデプロイする場合、アーカイブは.war
拡張子で終わる必要があります。EARファイルにデプロイする場合、アーカイブは.ear
拡張子で終わる必要があります。
スタンドアロンWebアプリケーションは、エンタープライズ・アプリケーションの一部としてパッケージ化およびデプロイすることをお薦めします。これは、アプリケーションの移行、追加、および変更を容易に行うことができるベスト・プラクティスです。また、アプリケーションをエンタープライズ・アプリケーションの一部としてパッケージ化することにより、分割開発ディレクトリ構造を活用できます。この構造には、従来の単一ディレクトリ構造に比べて多くの利点があります。
注意: ディレクトリを展開形式(非アーカイブ形式)でデプロイする場合は、ディレクトリに.ear 、.jar などの名前を付けないでください。アーカイブ形式の詳細は、「Webアプリケーション開発者向けツール」を参照してください。 |
サーブレットとは、Javaに対応したサーバーで実行されるJavaクラスです。HTTPサーブレットは、HTTPリクエストを処理し、通常はHTMLページの形式でHTTPレスポンスを送信する特殊なサーブレットです。WebLogic HTTPサーブレットの最も一般的な使用方法は、クライアント側のプレゼンテーションに標準的なWebブラウザを使い、WebLogic Serverではサーバー側のプロセスとしてビジネス・ロジックを処理する、対話型アプリケーションを作成することです。WebLogic HTTPサーブレットは、データベース、Enterprise JavaBeans、メッセージングAPI、HTTPセッションなどのWebLogic Serverの機能にアクセスできます。
WebLogic Serverでは、Servlet 2.5仕様(http://java.sun.com/products/servlet/index.jsp
)に定義されているように、HTTPサーブレットを完全にサポートしています。HTTPサーブレットは、Java EE規格の不可欠な部分です。
Java EEメタデータ・アノテーションの使用により、標準のweb.xml
デプロイメント記述子は省略可能になりました。Servlet 2.5仕様では、サーブレット、フィルタ、リスナー、タグ・ハンドラなどの特定のWebコンポーネントでアノテーションを定義できると規定されています。アノテーションを使用すると、外部リソースに対する依存関係を宣言できます。コンテナはこれらのコンポーネントのアノテーションを検出し、コンポーネントのライフサイクル・メソッドが呼び出される前に必要な依存関係を注入します。第8章「WebコンポーネントのWebLogicアノテーション」を参照してください。
Servlet 2.5仕様は、サーブレットAPIの実装と、エンタープライズ・アプリケーションでのサーブレットのデプロイ方法を定義しています。WebLogic ServerなどJava EE準拠のサーバーでサーブレットをデプロイするには、エンタープライズ・アプリケーションを構成するサーブレットなどのリソースをWebアプリケーションという1つの単位にパッケージ化します。Webアプリケーションでは、リソースを格納する特定のディレクトリ構造と、これらのリソースが対話する方法や、クライアントによるアプリケーションへのアクセス方法を定義する、デプロイメント記述子を利用します。「Webアプリケーション・コンテナ」を参照してください。
HTMLフォームを使用してエンドユーザーの入力を取得し、その入力に応答するHTMLページを表示する、動的なWebページを作成。たとえば、オンライン・ショッピング・カート、金融サービス、パーソナライズされたコンテンツなどに使用できます。
オンライン会議などのコラボレーション・システムを作成。
WebLogic Serverで実行されるサーブレットを使用することで、様々なAPIや機能にアクセス。例:
セッション・トラッキング - Webサイトで複数のWebページにわたるユーザーの動きを追跡できます。この機能は、ショッピング・カートを使用するeコマース・サイトなどのWebサイトをサポートします。WebLogic Serverはデータベースへのセッション永続性をサポートしており、サーバーのダウンタイム中のフェイルオーバー、およびクラスタリングされたサーバー間のセッションの共有を提供します。詳細は、「サーブレットからのセッション・トラッキング」を参照してください。
JDBCドライバ - JDBCドライバにより、基本的なデータベース・アクセスが提供されます。WebLogic Serverの複数層JDBC実装により、接続プール、サーバー側のデータ・キャッシュ、およびトランザクションを利用できます。詳細は、「データベースへのアクセス」を参照してください。
Enterprise JavaBeans - サーブレットでEnterprise JavaBeans (EJB)を使用して、セッション、データベースのデータ、その他の機能をカプセル化できます。「外部EJBの参照」、「ejb-ref*要素についての詳細」および「アプリケーション・スコープのEJBの参照」を参照してください。
Java Messaging Service (JMS) - サーブレットは、JMSを使用して他のサーブレットやJavaプログラムとメッセージを交換できます。『Oracle WebLogic Server JMSのプログラミング』を参照してください。
Java JDK API - サーブレットでは、標準的なJava JDK APIを使用できます。
リクエストの転送 - サーブレットでは、リクエストを別のサーブレットまたは別のリソースに転送できます。「リクエストの転送」を参照してください。
任意のJava EE準拠のサーブレット・エンジン用に作成されたサーブレットをWebLogic Serverに簡単にデプロイ。
以下に、サーブレット開発に関連するいくつかの要点を挙げます。
HTTPサーブレットのプログラマは、標準Java APIであるjavax.servlet.http
を利用して対話型のアプリケーションを作成します。
HTTPサーブレットはHTTPヘッダーを読み取り、HTMLコードを書き出してブラウザ・クライアントへレスポンスを送り出すことができます。
サーブレットは、Webアプリケーションの一部としてWebLogic Serverにデプロイされます。Webアプリケーションとは、サーブレット・クラス、JavaServer Pages (JSP)、静的なHTMLページ、画像、セキュリティなどのアプリケーション・コンポーネントをグループ化したものです。
JavaServer Pages (JSP)は、JavaをHTMLと組み合わせてWebページで動的コンテンツを提供するための仕様です。動的コンテンツを作成する場合、JSPではHTMLページに直接Javaコードを埋め込むことができるのに対し、HTTPサーブレットではHTMLをJavaコードに埋め込むので、JSPの方がHTTPサーブレットよりコーディングが容易です。
JSPは、JavaコードをWebページに埋め込むことができる拡張HTMLで記述されたWebページです。JSPでは、HTMLに似たタグを使用して、taglib
と呼ばれるカスタムJavaクラスを呼び出すことができます。WebLogicのappc
コンパイラ(weblogic.appc
)では、JSPの生成と記述子の検証が行われます。また、JSPをWEB-INF/classes/
ディレクトリ内にプリコンパイルするか、WEB-INF/lib/
の下でJARファイルとしてプリコンパイルし、サーブレット・クラスをWebアーカイブにパッケージ化して、サーバー内でのコンパイルを回避することも可能です。サーブレットおよびJSPでは、Webアプリケーションとともにデプロイするヘルパー・クラスがさらに必要な場合があります。
JSPを使用すると、Webページの動的コンテンツとその表現方法を分離できます。これにより、ページの視覚デザインを担当するHTML開発者と、動的コンテンツを作成するソフトウェアの開発を担当するJava開発者という2種類の開発者の要望に応えます。
WebLogic JSPでは、JSP 2.1仕様(http://java.sun.com/products/jsp/
)をサポートしています。Java EEの主要なテーマは、開発の容易さです。プラットフォームのWeb層では、以下の2つの点で開発の容易さが大幅に向上しています。1つめは、プラットフォームにJavaServer Pages Standard Tag Library (JSTL)技術とJavaServer Faces技術が組み込まれていることです。2つめは、Java EEでのWebアプリケーション開発を非常に容易にする以下のような機能がすべてのWeb層技術で提供されることです。
新しい式言語(EL)構文。これにより、式の評価を遅延できるようになり、式を使用してデータを取得および設定したりメソッドを呼び出したりできるようになりました。さらに、式によって参照される変数やプロパティの解決がカスタマイズしやすくなりました。
アノテーションを介したリソース注入のサポート。これにより、リソースや環境データへのアクセスの構成が簡略化されました。
JavaServer Faces技術タグとJavaServer Pages (JSP)ソフトウェア・コードとの緊密な連携。
JSPはJava EE標準の一部であるので、WebLogic Serverを含む様々なプラットフォームでJSPをデプロイすることが可能です。さらに、サード・パーティ・ベンダーやアプリケーション開発者は、動的コンテンツを構成するためにJSPページから参照できるカスタムJSPタグを定義したり、JavaBeanコンポーネントを配布したりできます。
JavaとHTMLを組み合わせてWebページで動的なコンテンツを提供します。
HTMLに似たタグを使用して、taglib
と呼ばれるカスタムJavaクラスを呼び出します。
HTTPサーブレット(HTMLをJavaコード内に埋め込む)とは対照的に、HTMLページにJavaコードを直接埋め込みます。
Webページで動的コンテンツを表現要素から分離します。
WebLogic Serverは、次の順序でJSPリクエストを処理します。
ブラウザが、.jsp
ファイルをWebLogic Serverにリクエストします。
WebLogic Serverがリクエストを読み取ります。
WebLogic Serverは、JSPコンパイラを使ってJSPをjavax.servlet.jsp.JspPage
インタフェースを実装するサーブレット・クラスに変換します。JSPファイルは、ページが初めてリクエストされたとき、あるいは、JSPファイルが変更されたときなど、必要な場合にのみコンパイルされます。そうでない場合、以前に編集されたJSPサーブレット・クラスが再利用されるので、次のレスポンスは非常に高速になります。
生成されたJspPage
サーブレット・クラスが呼び出され、ブラウザからのリクエストを処理します。
また、ブラウザからリクエストせずに直接JSPコンパイラを呼び出すこともできます。詳細は、「WebLogic JSPコンパイラの使用方法」を参照してください。
JSPコンパイラはまずJavaサーブレットを作成するので、コンパイラが生成するJavaファイルを見ることもでき、生成されたJspPage
サーブレット・クラスをHTTPサーブレットとして登録することもできます。「サーブレット」を参照してください。
Oracleは、サーブレット、JSP、JSFベースのWebアプリケーションを容易に作成、テスト/デバッグ、およびデプロイできるいくつかのツールを提供しています。
Oracle JDeveloperは、Oracle Fusion Middleware製品の統合開発環境を提供するエンタープライズIDEです。詳細は、http://www.oracle.com/technology/products/jdev/index.html
を参照してください。
Oracle Enterprise Pack for Eclipseは、OracleプラットフォームをターゲットにしたWebアプリケーション用の事前パッケージ・ツールを備えたEclipseベースの開発環境です。詳細は、http://www.oracle.com/technology/products/enterprise-pack-for-eclipse/index.html
を参照してください。
どちらのツールも、高度なコード編集機能、コラボレーティブなチームワーク開発環境、ビジュアルな開発とデバッグ機能、および効率的なデプロイメント機能を備えています。
スケルトン・デプロイメント記述子を作成するときに、WebLogic Antユーティリティを使用できます。これらのユーティリティは、WebLogic Server配布キットとともに出荷されているJavaクラスです。ANTタスクによって、Webアプリケーションを含むディレクトリが調べられ、そのWebアプリケーションで検出されたファイルを基にデプロイメント記述子が作成されます。ANTユーティリティは、個別のWebアプリケーションに必要な構成やマッピングに関する情報をすべて備えているわけではないので、ANTユーティリティによって作成されるスケルトン・デプロイメント記述子は不完全なものです。ユーティリティがスケルトン・デプロイメント記述子を作成した後で、テキスト・エディタ、XMLエディタ、または管理コンソールを使ってデプロイメント記述子を編集し、Webアプリケーションの構成を完全なものにしてください。
Webアプリケーションにセキュリティを設定するには、Webアプリケーション内の特定のURLパターンへのアクセスを制限するか、またはサーブレット・コードをプログラミングすることでセキュリティの呼出しを使用します。
実行時には、ユーザー名とパスワードがWebアプリケーションに該当するセキュリティ・レルムを使用して認証されます。web.xml
または、Webアプリケーションの管理コンソールを使用して作成された外部ポリシーで構成されているセキュリティ制約にしたがって、認可が確認されます。
実行時には、WebLogic Serverのアクティブなセキュリティ・レルムによって、Webアプリケーション・セキュリティ制約が指定のWebアプリケーション・リソースに適用されます。セキュリティ・レルムは複数の仮想ホスト間で共有されることに注意してください。
Webアプリケーションのセキュリティ構成の詳しい手順や例は、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』を参照してください。WebLogicセキュリティの詳細は、『Oracle WebLogic Serverセキュリティのプログラミング』を参照してください。
HttpSessionがサーブレットで生成されると、一意のIDと関連付けられます。ブラウザは、このセッションIDをそのリクエストに付与し、サーバーが再びセッション・データを見つけられるようにする必要があります。
「セッション固定」と呼ばれる種類の攻撃を回避するため、ログイン時にユーザーのセッションIDを変更する必要があります。これを実行するには、login
メソッドを呼び出した後、weblogic.servlet.security.ServletAuthentication
のgenerateNewSessionID
メソッドを呼び出します。
generateNewSessionID
メソッドは、現在のすべてのセッション情報を完全に別のセッションIDに移動し、当該セッションを新しいIDに関連付けます。
注意: セッション自体に変更はなく、その識別子のみが変更されます。 |
レガシー・アプリケーションは、ログイン前後に残っている同一のセッションIDに依存する可能性があります。generateNewSessionID
を呼び出すと、このようなアプリケーションが壊れてしまいます。このような依存関係はアプリケーションに構築しないことをお薦めします。ただし、構築する場合またはこの種類のレガシー・アプリケーションを処理する場合は、SSLを使用してアプリケーションに対するすべてのアクセスを保護することをお薦めします。
デフォルトでは、WebLogicコンテナはプログラム以外によるログインのIDを自動的に再生成します。
generateNewSessionID
メソッドに関する追加情報は、ServletAuthentication
を参照してください。
Webアプリケーション上のリクエストが別の場所にリダイレクトされる場合、レスポンス用に生成されるLocationヘッダーには、そのリクエストに格納されているHostヘッダーがデフォルトで使用されます。Hostヘッダーには、別のホスト名や別のパラメータを格納してなりすますことができるため、この動作を悪用して、サード・パーティに対してリダイレクト攻撃をしかけることができます。
こうした危険を回避するため、FrontendHost
属性をWebServerMBeanまたはClusterMBeanで設定し、すべてのリダイレクトURLの送信先ホストを指定します。レスポンスのLocationヘッダーではFrontendHost
属性で指定したホストが使用され、元のリクエストに格納されていたホスト情報は使用されません。
詳細は、Oracle WebLogic Server MBean リファレンスのFrontendHost
を参照してください。
Platform for Privacy Preferences (P3P)は、Webサイトにおいて機械可読形式の構文によるプライバシ・ポリシーを公開できる方法を提供します。WebLogic Server Webアプリケーション・コンテナは、P3Pをサポートできます。
p3p.xml
ファイルの場所をブラウザに伝える方法は3つあります。
ポリシー参照ファイルを「周知の場所(well-known location)」(サイト上の場所/w3c/p3p.xml
)に置きます。
Webサイトからの各レスポンスに、ポリシー参照ファイルの場所を示す特別なHTTPヘッダーを追加します。
サイト上の各HTMLページ内にポリシー参照ファイルへのリンクを設けます。
詳細は、http://www.w3.org/TR/p3pdeployment#Locating_PRF
を参照してください。
Linuxブラウザで特殊文字を表示するには、JVMのfile.encoding
システム・プロパティをISO8859_1
に設定します。たとえば、java -Dfile.encoding=ISO8859_1 weblogic.Server
のように指定します。詳細なリストについては、http://java.sun.com/javase/6/docs/technotes/guides/intl/encoding.doc.html
を参照してください。