Oracle® Fusion Middleware Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発 12c (12.2.1.2.0) E82868-02 |
|
![]() 前 |
![]() 次 |
この章の内容は以下のとおりです。
Webアプリケーションには、サーブレット、JavaServer Pages (JSP)、JSPタグ・ライブラリなどのアプリケーションのリソースと、HTMLページや画像ファイルなどの静的リソースが組み込まれています。Webアプリケーションにより、アプリケーションにservice-ref (Webサービス)およびmessage-destination-ref (JMS宛先/キュー)が追加されます。また、Enterprise JavaBeans (EJB)などの外部リソースへのリンクも定義できます。
Java EEプログラミング・モデルでは、メタデータ・アノテーションを採用しています。これにより、コンテナ内でのアプリケーション・コンポーネントの動作や依存関係インジェクションのリクエスト方法などをJavaクラス自体の中で指定でき、アプリケーションの開発プロセスを簡略化できます。アノテーションは、エンタープライズ・アプリケーションの以前のバージョン(Java EE 1.4以前)で必要とされたデプロイメント記述子に代わるものです。
Java EEアノテーションの使用により、標準のapplication.xml
およびweb.xml
デプロイメント記述子は省略可能になりました。Java EEプログラミング・モデルでは、EJB、サーブレット、Webアプリケーション、JSPなどのWebコンテナに対してJDKアノテーション機能を採用しています。「Webコンポーネント用のWebLogicアノテーション」およびhttp://docs.oracle.com/javaee/7/api/
を参照してください。Java EE 7 Webアプリケーション・テクノロジの詳細は、http://www.oracle.com/technetwork/java/javaee/tech/index.html
を参照してください。
ただし、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つのサーブレットまたはJavaServer 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では、サーブレット3.1仕様(http://jcp.org/en/jsr/detail?id=340
)に定義されているように、HTTPサーブレットを完全にサポートしています。HTTPサーブレットは、Java EE規格の不可欠な部分です。
Java EEメタデータ・アノテーションを使用すれば、標準のweb.xml
デプロイメント記述子は省略可能です。サーブレット仕様では、サーブレット、フィルタ、リスナー、タグ・ハンドラなどの特定のWebコンポーネントでアノテーションを定義できると規定されています。アノテーションを使用すると、外部リソースに対する依存関係を宣言できます。コンテナはこれらのコンポーネントのアノテーションを検出し、コンポーネントのライフサイクル・メソッドが呼び出される前に必要な依存関係を注入します。「Webコンポーネント用のWebLogicアノテーション」を参照してください。
サーブレット仕様では、サーブレット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.3仕様(http://jcp.org/en/jsr/detail?id=245
)をサポートしています。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です。
Oracle Enterprise Pack for Eclipseは、OracleプラットフォームをターゲットにしたWebアプリケーション用の事前パッケージ・ツールを備えたEclipseベースの開発環境です。
どちらのツールも、高度なコード編集機能、コラボレーティブなチームワーク開発環境、ビジュアルな開発とデバッグ機能、および効率的なデプロイメント機能を備えています。
スケルトン・デプロイメント記述子を作成するときに、WebLogic Antユーティリティを使用できます。これらのユーティリティは、WebLogic Server配布キットとともに出荷されているJavaクラスです。ANTタスクによって、Webアプリケーションを含むディレクトリが調べられ、そのWebアプリケーションで検出されたファイルを基にデプロイメント記述子が作成されます。ANTユーティリティは、個別のWebアプリケーションに必要な構成やマッピングに関する情報をすべて備えているわけではないので、ANTユーティリティによって作成されるスケルトン・デプロイメント記述子は不完全なものです。ユーティリティがスケルトン・デプロイメント記述子を作成した後で、テキスト・エディタ、XMLエディタ、またはWebLogic Server管理コンソールを使ってデプロイメント記述子を編集し、Webアプリケーションの構成を完全なものにしてください。
Webアプリケーションにセキュリティを設定するには、Webアプリケーション内の特定のURLパターンへのアクセスを制限するか、またはサーブレット・コードをプログラミングすることでセキュリティの呼出しを使用します。
実行時には、ユーザー名とパスワードがWebアプリケーションに該当するセキュリティ・レルムを使用して認証されます。web.xml
または、WebアプリケーションのWebLogic Server管理コンソールを使用して作成された外部ポリシーで構成されているセキュリティ制約に従って、認可が確認されます。
実行時には、WebLogic Serverのアクティブなセキュリティ・レルムによって、Webアプリケーション・セキュリティ制約が指定のWebアプリケーション・リソースに適用されます。セキュリティ・レルムは複数の仮想ホスト間で共有されることに注意してください。
Webアプリケーションのセキュリティ構成の詳細な手順や例は、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』を参照してください。WebLogicセキュリティの詳細は、『WebLogicセキュリティ・サービスによるアプリケーションの開発』を参照してください。
『WebLogicセキュリティ・サービスによるアプリケーションの開発』では、Java Authentication Service Provider Interface for Containers (JASPIC)仕様(http://www.jcp.org/en/jsr/detail?id=196
)を使用して認証メカニズムを実装する方法についても説明しています。
WebServer
MBeanのMaxRequestParameterCount
属性を設定することで、HTTPリエスト内の過剰なパラメータによるWebLogic Serverドメインの過負荷を回避できます。この属性は、リクエスト内に許されるパラメータの数を制限します。MaxRequestParameterCount
のデフォルト値は10,000です。着信したHTTPリクエスト上のパラメータの数がMaxRequestParameterCount
属性に設定された最大数を超える場合、次のエラーがロギングされます。
<Error> <ServletContext> <BEA-000000> <Rejecting request since max request parameter limit exceeded 10000>
このパラメータは、WebServer
MBeanまたはVirtualHost
MBeanのいずれかに設定できます。WLSTオンラインを使用して、この属性を次の例に示すように設定します。
WebServer
MBeanを使用する場合
connect('<admin_user>','<admin_pwd>','<admin_url>') edit() startEdit() cd('Servers/<server_name>') cmo.getWebServer().setMaxRequestParameterCount(1000) save() activate() exit()
VirtualHost
MBeanを使用する場合
connect('<admin_user>','<admin_pwd>','<admin_url>') edit() startEdit() cd('VirtualHosts/<virtual_host>') cmo.setMaxRequestParameterCount(1000) save() activate() exit()
注意:
MaxRequestParameterCount
をWebAppContainer
MBeanに設定した場合、かわりに属性をWebServer
MBeanに設定することをお薦めします。
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://docs.oracle.com/javase/8/docs/technotes/guides/intl/encoding.doc.html
を参照してください。