BEA ホーム | 製品 | dev2dev | support | askBEA
 ドキュメントのダウンロード   サイト マップ   Glossary 
検索
e-docs > WebLogic Server > WebLogic Server アプレット ユーザーズ ガイド > WebLogic Server でのアプレットの使用

WebLogic Server アプレット ユーザーズ ガイド

 Previous Next Contents PDF で侮ｦ  

WebLogic Server でのアプレットの使用

 

はじめに

BEA は、限られたケースでのみアプレットの使用をサポートしています。このマニュアルでは、アプレットの使用を検討する上で役立つその他のオプションも示します。また、BEA が推奨するベスト プラクティス以外の方法で WebLogic Server とアプレットを使用するユーザのために、Sun のサイトへのリンクを示してあります。

 

アプレットの動作と仕組み

この節では、アプレットの機能について簡単に説明します。詳細については、Sun の Java Web サイトのApplets を参照してください。

アプレットは、次のように、<APPLET> タグを使用して HTML ページに埋め込まれます。 

  <APPLET CODE="HelloWorld.class"
          CODEBASE="/bea_wls_internal/classes/" WIDTH=150 HEIGHT=25>
  </APPLET>

Web ブラウザは、<APPLET> タグを含む HTML ページを要求する場合、CODE 属性によって指定されているメイン アプレット クラスの検索を試みます。Web ブラウザは CODEBASE 属性によって指定された URL からそのクラスを要求します。アプレットが使用する他のクラスは、CODEBASE によって指定された URL から要求されます。

アプレットをテストするときには、Web ブラウザのクラスパスにアプレット クラスが指定されていないことに注意する必要があります。ブラウザが要求したクラスを HTTP サーバから取得できない場合、そのローカル パスを検索します。このため、アプレットのデプロイメントを適切にコンフィグレーションしたかのように感じられます。これは、アプレットがローカル ホスト マシン上で動作するからです。しかし、要求したアプレット クラスを Web サーバにすべてデプロイしていない場合、誰かがリモート クライアントからアプレットを使おうとしても、そのアプレットは実行できません。

 

どのような状況で使用するのか

BEA では、J2EE プラットフォームの一部である HTTP サーブレットおよび JavaServer Pages（JSP）を利用したサーバサイド アプリケーションの使用をサポートしています。新しいアプリケーションを開発する前に、サーブレットまたは JSP の使用を検討することをお勧めします。一般に、サーブレットと JSP を使用する一連の対話型 Web ページを適切に作成すると、Web サイトの速度と信頼性が向上します。現在アプレットを使用している場合、Java Web Start を使用してそのほとんどを Java アプリケーションに変換し、引き続き WebLogic Server を使用できます。詳細については、Sun の Java Web Start サイトを参照してください。

アプレットは、WebLogic で実行されている分散アプリケーションの一部として、Web ブラウザのクライアントサイド インタフェースの対話性を高めるために使用できます。グラフィックの情報を時間の経過と共に更新する必要がある場合、アプレットは最良の方法です。アプレットには、ソフトウェアを配布することなく安全なクライアントサイド コードを実行できるというメリットがあります。

アプレットは、ページ機能の拡張に使用できます。たとえば、ステートレスなクリック/応答型のアプリケーション（ナビゲーション バー、コンソールなど）、あるいはポーリング アプリケーション（株価表示など）で使用可能です。

WebLogic Server の Web プレゼンテーション-ベスト プラクティス

次の表に、WebLogic Server を使用するときに推奨される、Web プレゼンテーションの BEA ベスト プラクティスを示します。

表1-1

目的とする作業 . .

アプレットのメリット/デメリット

推奨される方法 . .

データベースへの接続

Web ブラウザ JVM によって課せられる制限、および互換性を保持するためのコスト。

サーブレットと JSP

スレッドの管理

スレッドの ContextClassloader の制限によって、アプレットで例外が発生する可能性がある。

サーブレットと JSP

GUI の強化

GUI の強化についてはアプレットが最適であるが、ブラウザによってアプレットの処理が異なるので注意が必要。

アプリケーションと Java WebStart

アプレットおよび WebLogic Server でテストされたブラウザとプラグインの詳細については、「動作確認状況」ページの「WebLogic Server でのアプレットのブラウザ サポート」を参照してください。

アプレットの使用に関する確認済みの制限

この節では、アプレットを使用するデメリット、およびアプレットの使用に関する 2 つの確認済みの制限について説明します。

アプレットを使用するデメリット

アプレットを使用するデメリットは次のとおりです。

アプレットからの EJB へのアクセス

別のアプリケーションでデプロイされた EJB にアクセスするアプレットをWeb アプリケーションで使用する場合には、Web アプリケーションの一部として EJB スタブを含める必要があります。そのためには、ejbc で -disableHotCodeGen オプションを使用してスタブを生成し、Web アプリケーションの一部として EJB スタブをパッケージ化します。

スタブが Web アプリケーションの一部として含まれていない場合、アプレットが EJB にアクセスしようとすると ClassNotFoundException が生成されます。

ClassNotFoundException

イベント処理スレッドの ContextClassloader は、ライフサイクル メソッドを実行するスレッドの ContextClassloader とは異なります。CODEBASE からロードしたクラスに関する情報を保持するのは、ライフサイクル メソッドを実行する ContextClassloader だけです。

アプレットのライフサイクル メソッド（init、start、stop、destroy）を実行するスレッド以外のスレッドで initialContext を取得しようとすると、以下の状況で ClassNotFoundException が送出される可能性があります。

ClassCastException

アプレットで WebLogic Server クライアントがクラスローダから一部のリソース情報を取得しようとするときに cache タグと codebase=/bea_wls_internal/classes タグが一緒に使用されると、ClassCastException が送出される可能性があります。

この問題を避けるには、次のことに注意します。

この制限の詳細については、http://developer.java.sun.com/developer/bugParade/bugs/4648591.html を参照してください。

 

Java Plug-in の使い方

BEA は、常にアプレット用の Java Plug-in を使用することをお勧めします。

Sun は、アプレットがブラウザのデフォルト仮想マシンではなく標準 Java 実行時環境（JRE）内で動作するためのブラウザ プラグインを提供しています。このため、プラグインをサポートするブラウザで一貫性が保証されます。つまり、アプレットの互換性と信頼性が保証されます。また、プラグインを使用すると、クライアント マシンでどの JRE が使用されているのかを簡単に調べることができます。

Java Plug-in は、WebLogic Server と通信する必要があるアプレットに不可欠の互換性を実現します。ほとんどの場合、クライアントの Java 仮想マシン（JVM）のバージョンはサーバの JVM と一致する必要があります。このため、サーバで Java 1.3 が実行されている場合、Java Plug-in 1.3 を使用する必要があります。

詳細については、Sun の Java Plug-in ホームページを参照してください。Java Plug-in は、Internet Explorer または Netscape ブラウザのネイティブ プラグインです。プラグインを必要とするページに最初にアクセスすると、メッセージが表示されて Sun の Web サイトに移動し、そこからプラグインがダウンロードされます。プラグインは、一度ダウンロードするだけで済みます。プラグインは Sun の特定の JRE の安定したリリース上でアプレットを実行しますが、それでもアプレットは通常のアプレットのようにブラウザ内で実行できます。

このプラグインを HTML ページに埋め込むのは、複雑な作業です。Internet Explorer と Netscape は異なる構文を使用するからです。Sun の Web サイトには、両方の構文フォーマットを同じ HTML ファイルに変換する方法が公開されています。また、既存の <APPLET> タグを自動的に変換する HTML コンバータをダウンロードできます。この解決策は非常に巧妙ですが、不自然で管理が困難です。このため、より優れた解決策として JavaServer Pages の使用を検討することをお勧めします。

JSP では、<jsp:plugin> タグを使用して、JSP によって生成された Web ページにアプレットを組み込みます。生成されたサーブレットは、クライアントの Web ブラウザのタイプを検出し、適切なプラグイン タグを応答として送信します。詳細については、『WebLogic JSP プログラマーズ ガイド』を参照してください。

アプレットの JVM の要件は、スタンドアロン クライアントの JVM の要件と同じです。WebLogic 6.1 サーバに対して、スタンドアロン クライアントを 1.3 JVM で実行する必要がある場合は、アプレット クライアントも 1.3 プラグインで実行しなければなりません。

アプレットがプラグイン対応アプレットに変換されると、次のようになります。

<HTML>
<HEAD><TITLE>Title of Applet page</TITLE></HEAD>
<BODY>
<OBJECT
CLASSID="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93"
WIDTH = 600
HEIGHT = 350
CODEBASE="http://java.sun.com/products/plugin/1.3/jinstall-13-win 32.cab#Version=1,3,0,0">
<PARAM NAME = CODE VALUE = "Applet1.class">
<PARAM NAME = CODEBASE VALUE = "/bea_wls_internal/classes/DefaultWebApp@DefaultWebApp/">
<PARAM NAME = ARCHIVE VALUE = "weblogic.jar">
<PARAM NAME="type" VALUE="application/x-java-applet;version=1.3">
<PARAM NAME="scriptable" VALUE="false">
<COMMENT>
<EMBED type="application/x-java-applet;version=1.3"
CODE = "Applet1.class"
CODEBASE = "/bea_wls_internal/classes/DefaultWebApp@DefaultWebApp/"
ARCHIVE = "weblogic.jar"
WIDTH = 600
HEIGHT = 350
scriptable=false
pluginspage="http://java.sun.com/products/plugin/1.3/plugin-insta ll.html";>
<NOEMBED>
</COMMENT>
alt="Your browser understands the &lt;APPLET&gt; tag but isn't running the applet, for some reason."
Your browser is completely ignoring the &lt;APPLET&gt; tag!
</NOEMBED>
</EMBED>
</OBJECT>
</BODY>
</HTML>

CODEBASE 属性

<APPLET> タグで CODEBASE 属性を使用すると、アプレットの Java クラス ファイルの検索先となる URL を指定できます。CODEBASE タグがない場合、Web ブラウザは <APPLET> タグが埋め込まれている HTML ファイルと同じディレクトリ内で必要なクラスを検索します。CODEBASE を使用すると、サイトの HTML コンテンツとは別個に 1 つのディレクトリを作成し、そのディレクトリにクラス ファイルを格納できるようになります。

多くの場合、WebLogic Server と一緒に動作するアプレットでは WebLogic クラスが必要となります。このため、CODEBASE 属性を使用して、ブラウザが WebLogic から必要なクラスをロードできるようにすると便利です。WebLogic は、/classes にマップされる特別なサーブレットを自動的に提供します。このサーブレットは、WebLogic Server のクラスパスからクラスを提供します。このサーブレットは、仮想サーブレット名「classes」としてデフォルトで登録されています。CODEBASE を以下のような URL に設定したとします。 

  CODEBASE="http://www.weblogic.com/bea_wls_internal/classes/"

または

  CODEBASE="/bea_wls_internal/classes/"

この場合、WebLogic Server はサーブレットを起動します。このサーブレットは、WebLogic Server のクラスパスから必要なクラスを検索します。

ClasspathServlet による CLASSPATH からのリソースの提供については、『Web アプリケーションのアセンブルとコンフィグレーション』の「Web アプリケーション コンポーネントのコンフィグレーション」を参照してください。

CODEBASE=/bea_wls_internal/classes/ の場合、アプレットに必要なクラスはシステム クラスパスになければなりません。

CODEBASE=/bea_wls_internal/classes/DefaultWebApp@DefaultWebApp の場合、アプレットに必要なクラスは applications/DefaultWebApp/WEB-INF/classes ディレクトリ、またはシステム クラスパスになければなりません。

CODE 属性

<APPLET> タグには、メイン アプレット クラス ファイルの完全なパッケージ名を指定する CODE 属性が含まれていなければなりません。CODE の最後の拡張子「.class」は省略可能です。たとえば、GraphApplet を使用する場合、<APPLET> タグは次のようになります。

  <APPLET CODE="GraphApplet"
          CODEBASE="/bea_wls_internal/classes/appName@componentName" >

ここで appName はアプリケーションの名前、componentName は Web アプリケーションの名前です。

<APPLET> タグと CODEBASE の詳細については、JavaSoft の Java チュートリアルの「Overview of Applets」を参照してください。

 

トラブルシューティングとパフォーマンス

以下のトピックでは、トラブルシューティングとパフォーマンスの問題について説明します。

アプレットのトラブルシューティング

ここでは、アプレットを使用するときに直面するいくつかのシナリオを示します。

アプレットがブラウザで動作しない

WebLogic JDBC をアプレットで使用して、DBMS からデータを取得しています。ローカル マシンで Sun Appletviewer を使用してクラスを実行する場合は、何の問題もありません。しかし、Netscape ブラウザでアプレットを実行しようとすると、アプレットに接続できません。

アプレットが Appletviewer で動作するのにブラウザでは動作しない場合、Netscape セキュリティ制限に違反している可能性があります。このような場合、アプレットはそのロード元以外のマシンに対するソケットを開くことができません。この問題を解決するには、DBMS と同一ホストのアプレット コードを使用する必要があります。

注意: アプレットの CODEBASE で使用する IP 名フォーマットと WebLogic Server に接続するために使用する URL は正確に一致する必要があります。一方でドット表記を使用し、他方でドメイン名を使用することはできません。

ClassFormatError

ClassFormatError を取得した場合、HTTP サーバのコンフィグレーションに問題がある場合があります。WebLogic またはアプレット クラスを HTTP サーバの適切なディレクトリに配置していないか、またはAPPLET タグ内の CODEBASE または CODE を間違って指定している可能性があります。次に、例を 2 つ示します。

Web アプリケーション MyWar にアプレットを配置したとします。この Web アプリケーションがアプリケーション MyEar の一部である場合、CODEBASE は次のようになります。

CODEBASE=http://host:port/bea_wls_internal/classes/MyEar@MyWar/

または

CODEBASE=/bea_wls_internal/classes/MyEar@MyWar/

この CODEBASE によって、すべてのクラスおよびリソース ファイルが Web アプリケーション MyWar からダウンロードされます。JPG ファイル、JAR ファイルなどのすべてのリソース ファイルを、特定の Web アプリケーションの WebApplicationRoot（この場合は MyWar のルート ディレクトリ）にまとめておきます。

CODE=com.myapp.MyApplet という属性を含むアプレットの CODEBASE をテストする場合は、http://server:host/CODEBASEvalue/com/myapp/MyApplet.class などの URL を指定して、ブラウザ ウィンドウからアクセスしてみます。このクラスのダウンロード ウィンドウが表示されるはずです。表示されない場合は、サーバの Web アプリケーションに関するコンフィグレーションを修正する必要があります。

詳細については、『WebLogic HTTP サーブレット プログラマーズ ガイド』を参照してください。

ローカル環境でのテスト

WebLogic Server と Netscape Communicator 4.x を同じホスト上で実行する場合、Communicator を実行するシェルの環境から CLASSPATH を削除する必要があります。セキュリティ上の理由により、Netscape Communicator は標準クラスの悪意ある変更を避けるためにローカル CLASSPATH からクラスをロードしません。ブラウザの実行時にローカル CLASSPATH を削除すると、Netscape は WebLogic Server の CLASSPATH からクラスをロードします。

その場合でも、WebLogic を起動するシェルに CLASSPATH を設定する必要があります。WebLogic では、使用する環境に CLASSPATH を設定せず、WebLogic を実行するシェルに CLASSPATH を適切に設定することをお勧めします。

アプリケーション全体を開発する前に、アプレットでプロトタイプ アプリケーションをテストすることをお勧めします。WebLogic Server サイドでは解決できない問題点をテストします。これらの問題はアプレット プラグインへの依存に起因するものだからです。このテストは以下のような対象について行うことをお勧めします。

ローカル開発環境からの移動

アプレットをローカル環境から移動する場合、WebLogic クラスとアプレット クラスを Web サーバ上の適切な場所にインストールしたかどうかを確認する必要があります。

WebLogic 配布キットをインストールしたマシン上でアプレットを実行する場合、これによって CODEBASE に関する問題が隠されてしまう場合があります。アプレットは、最初にローカル CLASSPATH の WebLogic クラスを検索します。クラスを適切にインストールしなかったため、HTTP サーバからアプレットが提供されない場合でも、アプレットはデフォルトでローカル CLASSPATH を検索して動作するので、この問題は表面化しません。HTTP コンフィグレーションを正確にテストするには、ローカル CLASSPATH で一時的に WebLogic クラスの名前を変更するか、別のマシンからアプレットを試す必要があります。

アーカイブによるアプレットの高速化

WebLogic には、HTML サーバ ログをスキャンし、アプレットのクラスの zip ファイルを作成してファイルのダウンロードを高速化するためのユーティリティが用意されています。さらに高速な手段は、可能な限りアプレットで JDBC を使用せず、DBMS データをサーブレットから HTML 形式で取得することです。サーブレットは、アプレットに代わってクエリを実行し、ワークスペースからデータを取得して HTML として提供します。このデータを非同期に維持する WebLogic プロセスと連携することにより、アプリケーションのパフォーマンスが向上します。

アプレットが実行前に数多くのファイルをダウンロードしなければならない場合、HTML ページの APPLET タグの中で ARCHIVE パラメータを使用することで、これを高速化できます。複数のアプレットに関する典型的な問題は、ブラウザがアプレット内で使用されているファイルごとに別個の HTTP 接続を確立しなければならないことです。接続を確立するのに数秒かかる場合もあり、ファイル自体のダウンロード時間より長くなることもあります。ARCHIVE パラメータを使用すると、これらのクラスを 1 個の .jar ファイル（Microsoft Internet Explorer の場合は .cab ファイル）にまとめることができます。このファイルは、単一の HTTP 接続でダウンロードできます。.jar ファイルは圧縮可能なので（.cab ファイルは常に圧縮される）、ダウンロード時間がさらに短縮します。

注意: Appletviewer、Netscape Navigator（3.0 以降のみ）、および HotJava ブラウザを使用するときの手順は、Microsoft Internet Explorer（4.0 以降のみ）で使用する手順とは異なります。完全な互換性を実現するために、両方の方法を組み合わせることができます。

 

Back to Top Previous Next