|
|
以下の節では、WebLogic Server Web アプリケーション、サーブレット、および Java Server Page (JSP) の概要を説明します。
Web アプリケーションには、サーブレット、JavaServer Pages (JSP)、JSP タグ ライブラリなどのアプリケーションのリソースと、HTML ページや画像ファイルなどの静的リソースが組み込まれています。Web アプリケーションにより、アプリケーションに service-ref (Web サービス) および message-destination-ref (JMS 送り先/キュー) が追加されます。また、エンタープライズ JavaBean (EJB) などの外部リソースへのリンクも定義できます。
WebLogic Server にデプロイされる Web アプリケーションは、標準の J2EE デプロイメント記述子ファイルと WebLogic 固有のデプロイメント記述子ファイルを使用してそれらのリソースと操作属性を定義します。
JSP と HTTP サーブレットは、WebLogic Server で使用可能なすべてのサービスと API にアクセスできます。これらのサービスには、EJB、Java Database Connectivity (JDBC) によるデータベース接続、Java Messaging Service (JMS)、XML などがあります。
Web アーカイブ (WAR ファイル) には、Web アプリケーションを構成するファイルが格納されます。WAR ファイルは、1 つまたは複数の WebLogic Server インスタンスにユニットとしてデプロイされます。WebLogic Server にデプロイされる WAR ファイルには、常に次のファイルが含まれます。
WAR ファイルは、単独でデプロイすることも、他のアプリケーション コンポーネントと一緒にエンタープライズ アプリケーション アーカイブ (EAR ファイル) にパッケージ化することもできます。単独でデプロイする場合、アーカイブは .war 拡張子で終わる必要があります。EAR ファイルに含めてデプロイする場合、アーカイブは .ear 拡張子で終わる必要があります。
スタンドアロン Web アプリケーションは、エンタープライズ アプリケーションの一部としてパッケージ化およびデプロイすることをお勧めします。これは、アプリケーションの移行、追加、および変更を容易に行うことができるベスト プラクティスです。また、アプリケーションをエンタープライズ アプリケーションの一部としてパッケージ化することにより、分割開発ディレクトリ構造を活用できます。この構造には、従来の単一ディレクトリ構造に比べて多くの利点があります。
| 注意 : | ディレクトリを展開形式 (非アーカイブ形式) でデプロイする場合は、ディレクトリに .ear、.jar などの名前を付けないでください。アーカイブ形式の詳細については、「Web アプリケーション開発者向けツール」を参照してください。 |
サーブレットとは、Java に対応したサーバで実行される Java クラスです。HTTP サーブレットは、HTTP リクエストを処理し、通常は HTML ページの形式で HTTP 応答を送信する特殊なサーブレットです。WebLogic HTTP サーブレットの最も一般的な使い方は、クライアントサイドのプレゼンテーションに標準的な Web ブラウザを使い、WebLogic Server ではサーバサイドのプロセスとしてビジネス ロジックを処理する、対話型アプリケーションを作成することです。WebLogic HTTP サーブレットは、データベース、エンタープライズ JavaBeans、メッセージング API、HTTP セッションなどの WebLogic Server の機能にアクセスできます。
WebLogic Server は、Sun Microsystems のサーブレット 2.4 仕様で定義されている HTTP サーブレットを完全にサポートしています。HTTP サーブレットは、Java 2 Enterprise Edition (J2EE) 規格の不可欠な部分です。
以下に、サーブレット開発に関連するいくつかの要点を挙げます。
javax.servlet.http を利用して対話型のアプリケーションを作成する。
Java 2 Platform, Enterprise Edition の一部であるサーブレット 2.4 仕様は、サーブレット API の実装と、エンタープライズ アプリケーションでのサーブレットのデプロイ方法を定義しています。WebLogic Server など J2EE 準拠のサーバでサーブレットをデプロイするには、エンタープライズ アプリケーションを構成するサーブレットなどのリソースを Web アプリケーションという 1 つの単位にパッケージ化します。Web アプリケーションでは、リソースを格納する特定のディレクトリ構造と、これらのリソースが対話する方法や、クライアントによるアプリケーションへのアクセス方法を定義する、デプロイメント記述子を利用します。「Web アプリケーション コンテナ」を参照してください。
Java Server Pages (JSP) は、Java コードを Web ページに埋め込むことができる拡張 HTML で記述された Web ページです。JSP では、HTML に似たタグを使用して、taglib と呼ばれるカスタム Java クラスを呼び出すことができます。WebLogic の appc コンパイラ (weblogic.appc) では、JSP の生成と記述子の検証が行われます。また、JSP を WEB-INF/classes/ ディレクトリ内にプリコンパイルするか、WEB-INF/lib/ の下で JAR ファイルとしてプリコンパイルし、サーブレット クラスを Web アーカイブにパッケージ化して、サーバ内でのコンパイルを回避することも可能です。サーブレットおよび JSP では、アプリケーションと共にデプロイするヘルパー クラスがさらに必要な場合があります。
JSP は、Java を HTML と組み合わせて Web ページで動的コンテンツを提供するための Sun Microsystems の仕様です。動的コンテンツを作成する場合、JSP では HTML ページに直接 Java コードを埋め込むことができるのに対し、HTTP サーブレットでは HTML を Java コードに埋め込むので、JSP の方が HTTP サーブレットよりコーディングが容易です。JSP は、Java 2 Enterprise Edition (J2EE) の一部です。
JSP を使用すると、Web ページから動的コンテンツなどの表現要素を分離することができます。そのために、ページのグラフィック設計を担当する HTML 開発者と、動的コンテンツを構成するソフトウェア開発を担当する Java 開発者という 2 種類の開発者の要求を満たします。
JSP は J2EE 標準の一部であるので、WebLogic Server を含むさまざまなプラットフォームで JSP をデプロイすることが可能です。さらに、サードパーティ ベンダやアプリケーション開発者は、動的コンテンツを構成するために JSP ページから参照できるカスタム JSP タグを定義したり、JavaBean コンポーネントを配布したりできます。
WebLogic Server は、次の順序で JSP リクエストを処理します。
.jsp ファイルを WebLogic Server に要求します。 javax.servlet.jsp.JspPage を実装するサーブレット クラスに変換します。JSP ファイルは、ページが初めて要求されたとき、あるいは、JSP ファイルが変更されたときなど、必要な場合にだけコンパイルされます。通常は、以前に編集された JSP サーブレット クラスが再利用されるので、以降の応答は非常に高速です。JspPage サーブレット クラスが呼び出され、ブラウザからのリクエストを処理します。
また、ブラウザから要求せずに直接 JSP コンパイラを呼び出すこともできます。詳細については、「WebLogic JSP コンパイラの使い方」を参照してください。
JSP コンパイラはまず Java サーブレットを作成するので、コンパイラが生成する Java ファイルを見ることもできますし、生成された JspPage サーブレット クラスを HTTP サーブレットとして登録することもできます。「サーブレット」を参照してください。
BEA WebLogic JSP は、Sun Microsystems の JSP 2.0 仕様をサポートしています。JSP 2.0 では、カスタム JSP タグ拡張の定義がサポートされています。
BEA では、Web アプリケーションの作成とコンフィグレーションを支援するツールを提供しています。これらについては、以下の節で説明します。
スケルトン デプロイメント記述子を作成するときに、WebLogic Ant ユーティリティを使用できます。ANT ユーティリティは WebLogic Server 配布キットと共に出荷されている Java クラスです。ANT タスクによって、Web アプリケーションを含むディレクトリが調べられ、その Web アプリケーションで検出されたファイルを基にデプロイメント記述子が作成されます。ANT ユーティリティは、個別の Web アプリケーションに必要なコンフィグレーションやマッピングに関する情報をすべて備えているわけではないので、ANT ユーティリティによって作成されるスケルトン デプロイメント記述子は不完全なものです。ANT ユーティリティがスケルトン デプロイメント記述子を作成した後で、テキスト エディタ、XML エディタ、または Administration Console を使ってデプロイメント記述子を編集し、Web アプリケーションのコンフィグレーションを完全なものにしてください。
DTD 検証機能を備えたエンタープライズ レベルの IDE、または XML ファイルの編集をサポートするその他の開発ツールを使用できます。
Web アプリケーションにセキュリティを設定するには、Web アプリケーション内の特定の URL パターンへのアクセスを制限するか、またはサーブレット コードをプログラミングすることでセキュリティの呼び出しを使用します。
実行時には、ユーザ名とパスワードが、Web アプリケーションに該当するセキュリティ レルムを使用して認証されます。
web.xml または、Web アプリケーションの Administration Console を使用して作成された外部ポリシーでコンフィグレーションされているセキュリティ制約に従って、認可が確認されます。
実行時には、WebLogic Server のアクティブなセキュリティ レルムによって、Web アプリケーション セキュリティ制約が指定の Web アプリケーション リソースに適用されます。セキュリティ レルムは複数の仮想ホスト間で共有されることに注意してください。
Web アプリケーションのセキュリティ コンフィグレーションの詳しい手順や例については、『ロールおよびポリシーによる WebLogic リソースの保護』を参照してください。WebLogic セキュリティの詳細については、『WebLogic Security プログラマーズ ガイド』を参照してください。
Platform for Privacy Preferences (P3P) は、Web サイトにおいて機械可読形式の構文によるプライバシ ポリシーを公開できる方法を提供します。WebLogic Server Web アプリケーション コンテナは、P3P をサポートできます。
p3p.xml ファイルの場所をブラウザに伝える方法は 3 つあります。
詳細については、http://www.w3.org/TR/p3pdeployment#Locating_PRF を参照してください。
Linux ブラウザで特殊文字を表示するには、JVM の file.encoding システム プロパティを ISO8859_1 に設定します。たとえば、java -Dfile.encoding=ISO8859_1 weblogic.Server のように指定します。詳細なリストについては、Sun の J2SE 1.4.2 の「Supported Encodings」を参照してください。
  
|
