| Oracle® Fusion Middleware Oracle WebLogic Server Web アプリケーション、サーブレット、JSP の開発 11g リリース 1 (10.3.1) B55521-01 |
|
 戻る |
 次へ |
| Oracle® Fusion Middleware Oracle WebLogic Server Web アプリケーション、サーブレット、JSP の開発 11g リリース 1 (10.3.1) B55521-01 |
|
戻る |
次へ |
以下の節では、WebLogic Server Web アプリケーション、サーブレット、および JavaServer Page (JSP) の概要を説明します。
Web アプリケーションには、サーブレット、JavaServer Pages (JSP)、JSP タグ ライブラリなどのアプリケーションのリソースと、HTML ページや画像ファイルなどの静的リソースが組み込まれています。Web アプリケーションにより、アプリケーションに service-ref (Web サービス) および message-destination-ref (JMS 送り先/キュー) が追加されます。また、エンタープライズ JavaBean (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 アノテーション機能を採用しています。「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 サーブレットは、データベース、エンタープライズ JavaBean、メッセージング API、HTTP セッションなどの WebLogic Server の機能にアクセスできます。
WebLogic Server では、Sun Microsystems の Servlet 2.5 仕様 (http://java.sun.com/products/servlet/index.jsp) に定義されているように、HTTP サーブレットを完全にサポートしています。HTTP サーブレットは、Java EE 規格の不可欠な部分です。
Java EE メタデータ アノテーションの使用により、標準の web.xml デプロイメント記述子は省略可能になりました。Servlet 2.5 仕様では、サーブレット、フィルタ、リスナ、タグ ハンドラなどの特定の Web コンポーネントでアノテーションを定義できると規定されています。アノテーションを使用すると、外部リソースに対する依存性を宣言できます。コンテナはこれらのコンポーネントのアノテーションを検出し、コンポーネントのライフサイクル メソッドが呼び出される前に必要な依存性を注入します。「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 ドライバ (Oracle のドライバを含む) - JDBC ドライバにより、基本的なデータベース アクセスが提供されます。WebLogic Server の多層 JDBC 実装により、接続プール、サーバサイドのデータ キャッシュ、およびトランザクションを利用できます。詳細については、「データベースへのアクセス」を参照してください。
エンタープライズ JavaBean - サーブレットでエンタープライズ JavaBean (EJB) を使用して、セッション、データベースのデータ、その他の機能をカプセル化できます。「外部 EJB の参照」、「ejb-ref* 要素についての詳細」および「アプリケーション スコープの EJB の参照」を参照してください。
Java Messaging Service (JMS) - JMS を使用して、他のサーブレットや Java プログラムとメッセージを交換できます。『Oracle Fusion Middleware 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 ページで動的コンテンツを提供するための Sun Microsystems の仕様です。動的コンテンツを作成する場合、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 では、Sun Microsystems の 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 ユーティリティを使用できます。ANT ユーティリティは WebLogic Server 配布キットと共に出荷されている Java クラスです。ANT タスクによって、Web アプリケーションを含むディレクトリが調べられ、その Web アプリケーションで検出されたファイルを基にデプロイメント記述子が作成されます。ANT ユーティリティは、個別の Web アプリケーションに必要なコンフィグレーションやマッピングに関する情報をすべて備えているわけではないので、ANT ユーティリティによって作成されるスケルトン デプロイメント記述子は不完全なものです。ANT ユーティリティがスケルトン デプロイメント記述子を作成した後で、テキスト エディタ、XML エディタ、または Administration Console を使ってデプロイメント記述子を編集し、Web アプリケーションのコンフィグレーションを完全なものにしてください。
Web アプリケーションにセキュリティを設定するには、Web アプリケーション内の特定の URL パターンへのアクセスを制限するか、またはサーブレット コードをプログラミングすることでセキュリティの呼び出しを使用します。
実行時には、ユーザ名とパスワードが、Web アプリケーションに該当するセキュリティ レルムを使用して認証されます。web.xml または、Web アプリケーションの Administration Console を使用して作成された外部ポリシーでコンフィグレーションされているセキュリティ制約に従って、認可が確認されます。
実行時には、WebLogic Server のアクティブなセキュリティ レルムによって、Web アプリケーション セキュリティ制約が指定の Web アプリケーション リソースに適用されます。セキュリティ レルムは複数の仮想ホスト間で共有されることに注意してください。
Web アプリケーションのセキュリティ コンフィグレーションの詳しい手順や例については、『Oracle Fusion Middleware Oracle WebLogic Server ロールおよびポリシーによるリソースの保護』を参照してください。WebLogic セキュリティの詳細については、『Oracle Fusion Middleware Oracle WebLogic Server Security プログラマーズ ガイド』を参照してください。
Web アプリケーション上の要求が別の場所にリダイレクトされる場合、応答用に生成される Location ヘッダには、その要求に格納されている Host ヘッダがデフォルトで使用されます。Host ヘッダには、別のホスト名や別のパラメータを格納してなりすますことができるため、この動作を悪用して、サード パーティに対してリダイレクト攻撃をしかけることができます。
こうした危険を回避するため、FrontendHost 属性を WebServerMBean または ClusterMBean で設定し、すべてのリダイレクト URL の送信先ホストを指定します。応答の Location ヘッダでは FrontendHost 属性で指定したホストが使用され、元の要求に格納されていたホスト情報は使用されません。
詳細については、『Oracle Fusion Middleware Oracle WebLogic Server MBean Reference』の「FrontendHost」を参照してください。
Platform for Privacy Preferences (P3P) は、Web サイトにおいて機械可読形式の構文によるプライバシ ポリシーを公開できる方法を提供します。WebLogic Server Web アプリケーション コンテナは、P3P をサポートできます。
p3p.xml ファイルの場所をブラウザに伝える方法は 3 つあります。
「よく知られている場所」(サイト上の場所 /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 を参照してください。
