WebLogic Server アプリケーションの開発
|
 |
 |
|
以下の節では、WebLogic Server でのプログラミングに関連する、さらなるトピックを説明します。
一般に、コンパイラは情報をある形式から別の形式に変換します。従来、これにはユーザが読めるソースからマシンが読める形式への情報の変換が含まれます。たとえば、javac コンパイラは、.java ファイルを .class ファイルに変換し、appc コンパイラは EJB および JSP をデプロイのために生成します。
また、特に開発環境においては、アプリケーションを構築するために実行する必要があるさまざまなコンパイル処理を自動化する、Ant タスクを使用して、WebLogic Server 固有のアプリケーションのコンパイル (または構築) を簡略化することもできます。「Ant タスクを使用してのコンパイル スクリプトの作成」を参照してください。
Sun Microsystems の javac コンパイラは、Java プログラミング言語で記述されたクラスおよびインタフェースの定義を読み取り、バイトコード クラス ファイルにコンパイルします。「javac - Java Programming Language Compiler」を参照してください。
BEA では、javac コンパイラを呼び出す wlcompile Ant タスクを提供しています。「wlcompile Ant タスク」を参照してください。
JSP およびコンテナ固有の EJB クラスを生成してデプロイするには、weblogic.appc コンパイラを使用します。appc コンパイラはまた、記述子が、個々のモジュール レベルとアプリケーション レベルの両方で現在の仕様に準拠しているかどうかも検証します。アプリケーション レベルのチェックでは、個別のモジュールに対するアプリケーション レベルのデプロイメント記述子のチェックと、モジュール全体の検証チェックが行われます。
appc コンパイラは、記述子で見つかった警告やエラーをすべて報告し、関連のモジュールをすべて EAR ファイルにコンパイルします。このファイルは、WebLogic Server にデプロイできます。
prompt>java weblogic.appc [オプション] <ear、jar、war ファイルまたはディレクトリ>
|
|
|
|
|
|
コンパイルの方法としては、Apache Ant が好適です。Ant は、Java ベースの構築ツールです。Ant の利点の 1 つは、これがシェルベースのコマンドではなく、Java クラスで拡張されていることです。もう 1 つの利点は、Ant がクロスプラットフォーム ツールであるということです。開発者は、eXtensible Markup Language (XML) で、Ant によるスクリプトを作成します。XML タグは構築ターゲット、ターゲット間の依存性、およびターゲットを構築するための実行タスクを定義します。Ant ライブラリは WebLogic Server に付属していて、製品パッケージから Java アプリケーションを簡単に構築できるようになっています。
Ant を使用するには、まず samples\domains\examples ディレクトリにある setExamplesEnv.cmd (Windows) または setExamplesEnv.sh (UNIX) コマンドを実行して、環境を設定する必要があります。
ant の機能の包括的な説明については、「http://jakarta.apache.org/ant/manual/index.html」を参照してください。
クロスプラットフォーム スクリプトをコンパイルする Ant の使い方、または Ant によって処理可能な XML スクリプトを作成するクロスプラットフォーム スクリプトの使い方については、以下のような任意の WebLogic Server サンプルを参照してください。
samples\domains\examples\ejb20\basic\beanManaged\build.xml
また、Ant を使ってサンプルを構築する方法を説明した、次の WebLogic Server ドキュメントを参照してください。
samples\server\examples\src\examples\examples.html
wlcompile Ant タスクは、javac コンパイラを呼び出して、エンタープライズ アプリケーションの Java ファイルを分割開発ディレクトリ構造にコンパイルするために使用します。詳細については、「WebLogic Server アプリケーションの作成」の「wlcompile を使用したアプリケーションのコンパイル」を参照してください。
wlappc Ant タスクは、appc コンパイラを呼び出すのに使用します。appc コンパイラは JSP およびコンテナ固有の EJB クラスを生成してデプロイします。
表 3-2 には、wlappc に固有の Ant タスク オプションが記載されています。ほとんどの部分については、これらのオプションは weblogic.appc のオプションと同じです。しかし、いくつか異なる点もあります。
注意 : weblogic.appc オプションのリストについては、「appc コンパイラ」を参照してください。
|
|
|
|
|
|
wlappc Ant タスクを使用するための基本的な構文では、送り先ソース ディレクトリの場所を決定します。このディレクトリには、wlappc でコンパイルするファイルが格納されます。
<wlappc source="${dest.dir}" />
以下は、表 3-2 の 2 つのオプション (idle および idleOrverWrite) を呼び出す wlappc Ant タスク コマンドの例です。
<wlappc source="${dest.dir}"idl="true" idlOrverWrite="true" />
appc と wlappc では、構文にいくらかの違いがあります。appc の場合、コマンド内に存在するフラグは boolean です。wlappc の場合、コマンド内にフラグが存在するということは、引数が必要であることを意味します。
以下はそれを説明するための、同一コマンドの例です。1 つ目が appc コマンド、2 つ目が wlappc コマンドです。
java weblogic.appc -idl foo.ear
<wlappc source="${dest.dir}" idl="true"/>
ほとんどの WebLogic サービスは J2EE 仕様に基づいており、標準 J2EE パッケージを通じてアクセスします。WebLogic サービスを使用するプログラムのコンパイルに必要な Sun、WebLogic、およびその他の Java クラスは、インストールした WebLogic Server の lib ディレクトリの weblogic.jar ファイルにパッケージ化されます。weblogic.jar ファイル以外にも、以下のものをコンパイラの CLASSPATH に組み込みます。
lib\tools.jar ファイル、または使用する Java 開発キットに必要なその他の標準 Java クラス。
WebLogic Server は高度なマルチスレッド アプリケーション サーバであり、ホストしているモジュールのリソースの割り当て、同時実行性、およびスレッドの同期化を慎重に管理します。WebLogic Server のアーキテクチャを最大限に活用するには、標準 J2EE API を使用して作成したアプリケーション モジュールを構築する必要があります。
通常、サーバサイド モジュールで新たなスレッドの作成が必要にならないアプリケーション設計をします。
このような警告にもかかわらず、スレッドの作成が適切な状況もあります。たとえば、複数のリポジトリを検索して、結合された結果セットを返すアプリケーションの場合、メイン クライアント スレッドを同期的に使用する代わりに、各リポジトリの新しいスレッドを非同期的に使用して検索を実行すると、より速く結果が返されることがあります。
アプリケーション コードでのスレッドの使用を決定したら、アプリケーションが作成するスレッドの数を制限できるようにスレッド プールを作成します。JDBC 接続プールのように、指定した数のスレッドをプールに割り当て、実行可能なクラスのプールから利用できるスレッドを取得します。プール内のすべてのスレッドが使用中の場合は、スレッドが戻されるまで待機します。スレッド プールを使用すると、パフォーマンスの問題を回避し、WebLogic Server の実行スレッドとアプリケーションの間のスレッドの割り当ても最適化できます。
スレッドでデッドロックが発生しそうな場所を把握しておき、デッドロックが発生したら確実に処理します。設計を慎重に見直して、スレッドがセキュリティ システムを危険にさらすことのないようにしておきます。
WebLogic Server スレッドとの望ましくない対話を避けるには、WebLogic Server モジュールの中でスレッドの呼び出しを使用しないようにします。たとえば、作成するスレッドからは、エンタープライズ Bean やサーブレットを使用しないでください。アプリケーション スレッドは、TCP/IP 接続による外部サービス、またはファイルの適切なロックや読み書きを行う外部サービスとの対話のような、独立していて分離されたタスクに使用するのが最適です。存続期間が短く、1 つの目的を実行して終了する (スレッドをプールに返す) スレッドの方が、他のスレッドと競合しません。
WebLogic Server 上にデプロイされているアプリケーションにパッケージ化されるモジュール内に、デーモン スレッドを作成しないようにしてください。サーブレットなどのアプリケーション モジュール内にデーモン スレッドを作成すると、元のデプロイメント内に作成されたデーモンが実行中のままになるので、アプリケーションを再デプロイできなくなります。
障害のポイントにクライアントを追加して、負荷が次第に大きくなるような状況でマルチスレッドのコードをテストします。アプリケーションのパフォーマンスと WebLogic Server の動作を監視し、プロダクション環境で障害が発生しないことを確認しておきます。
スレッド内に InitialContext を作成する場合は、必ず InitialContext を明示的に閉じて、リソースをすぐに解放し、メモリ リークを回避してください。詳細については、『WebLogic JNDI プログラマーズ ガイド』の「コンテキストのクローズ」を参照してください。
WebLogic Server には Sun Microsystems の JavaMail API バージョン 1.1.3 参照実装が含まれています。JavaMail API を使用すると、WebLogic Server アプリケーションに電子メール機能を追加できます。JavaMail を使用すると、自社ネットワークまたはインターネット上の IMAP (Internet Message Access Protocol) 対応および SMTP (Simple Mail Transfer Protocol) 対応のメール サーバに Java アプリケーションからアクセスできます。JavaMail はメール サーバ機能を持っていないので、JavaMail を使用するにはメール サーバが必要です。
JavaMail API の使い方について詳細に説明したドキュメントは、Sun の Web サイトにある「JavaMail のページ」で入手できます。ここでは、WebLogic Server 環境で JavaMail を使用する方法について説明しています。
weblogic.jar ファイルには、Sun の javax.mail と javax.mail.internet のパッケージが入っており、また、weblogic.jar には、JavaMail で必要な JAF (Java Activation Framework) パッケージも含まれています。
javax.mail パッケージには、Internet Message Access Protocol (IMAP) および Simple Mail Transfer Protocol (SMTP) メール サーバのプロバイダが含まれています。Sun には、JavaMail 用に独自の POP3 プロバイダがあります。これは、weblogic.jar には含まれていません。使用する場合は、Sun からその POP3 プロバイダをダウンロードし、WebLogic Server のクラスパスに追加できます。
JavaMail は、システムのメール転送機能を定義するコンフィグレーション ファイルに依存します。weblogic.jar ファイルには、Sun の標準コンフィグレーション ファイルが入っています。このファイルにより、IMAP および SMTP メール サーバが JavaMail 向けに使用可能になり、JavaMail が処理できるデフォルトのメッセージ タイプが定義されます。
JavaMail を拡張してサポートする転送、プロトコル、およびメッセージのタイプを追加する場合を除いて、JavaMail コンフィグレーション ファイルを変更する必要はありません。JavaMail を拡張する場合は、Sun の Web サイトから JavaMail をダウンロードして、Sun の拡張を追加する手順に従います。次に、拡張した JavaMail パッケージを weblogic.jar の前の WebLogic Server クラスパスに追加します。
WebLogic Server で使用するために JavaMail をコンフィグレーションするには、WebLogic Server Administration Console でメール セッションを作成します。これにより、あらかじめコンフィグレーションしておくセッション プロパティを使用して、サーバサイド モジュールとアプリケーションで JNDI を用いて JavaMail サービスにアクセスできるようになります。たとえば、メール セッションを作成すると、メール ホスト、転送および格納プロトコル、デフォルトのメール ユーザを Administration Console で指定できるため、JavaMail を使用するモジュールでこれらのプロパティを設定する必要はありません。WebLogic Server は単一のセッション オブジェクトを作成し、JNDI を通じてそのオブジェクトを必要とするすべてのモジュールで利用できるようにするため、多数の電子メール ユーザを持つアプリケーションではメリットが得られます。
javax.mail.Session オブジェクトをルック アップします。Properties オブジェクトを作成すると、コード内でオーバーライドできます。「JavaMail を使用したメッセージの送信」を参照してください。メール セッション オブジェクトを JNDI でルックアップした後、Properties オブジェクトを使用して Session.getInstance() メソッドを呼び出し、カスタマイズしたセッションを取得します。
WebLogic Server モジュール内から JavaMail を使用してメッセージを送信する手順は次のとおりです。
import java.util.*;
import javax.activation.*;
import javax.mail.*;
import javax.mail.internet.*;
import javax.naming.*;
InitialContext ic = new InitialContext();
Session session = (Session) ic.lookup("myMailSession");
Properties オブジェクトを作成してオーバーライドするプロパティに追加します。getInstance() を呼び出して、新しいプロパティの新しいセッション オブジェクトを取得します。Properties props = new Properties();
props.put("mail.transport.protocol", "smtp");
props.put("mail.smtp.host", "mailhost");
// HTML フォームからのメール アドレスを発信元アドレスに使用する
props.put("mail.from", emailAddress);
Session session2 = session.getInstance(props);
Message msg = new MimeMessage(session2);
msg.setFrom();
msg.setRecipients(Message.RecipientType.TO,
InternetAddress.parse(to, false));
msg.setSubject(subject);
msg.setSentDate(new Date());
// コンテンツは、本文が 1 つある MIME マルチパート メッセージに
// 格納される
MimeBodyPart mbp = new MimeBodyPart();
mbp.setText(messageTxt);
Multipart mp = new MimeMultipart();
mp.addBodyPart(mbp);
msg.setContent(mp);
Transport.send(msg);
JNDI ルックアップでは、エラーが発生すると NamingException 例外が送出されます。JavaMail では、転送クラスの特定またはメール ホストとの通信に失敗した場合に MessagingException が送出されます。コードを try ブロックの中に配置し、これらの例外を捕捉するようにしておきます。
JavaMail API を使用すると、メッセージ ストアに接続できます。メッセージ ストアは IMAP サーバまたは POP3 サーバとなります。メッセージはフォルダに保存されます。IMAP の場合、メッセージ フォルダはメール サーバ上に格納されます。メッセージ フォルダには、受信したメッセージが入るフォルダとアーカイブされたメッセージが入るフォルダがあります。POP3 の場合は、メッセージの到着時にメッセージを保存するフォルダをサーバが提供します。クライアントは、POP3 サーバに接続するときに、メッセージを取得してクライアントのメッセージ ストアに転送します。
フォルダは、ディスクのディレクトリと同じような階層構造になっています。フォルダにはメッセージまたは他のフォルダを格納できます。デフォルトのフォルダは構造の最上位にあります。特別なフォルダ名である INBOX は、ユーザのプライマリ フォルダのことを指し、デフォルト フォルダの内部にあります。受信したメールを読み込むには、ストアからデフォルト フォルダを取得して、次にデフォルト フォルダから INBOX フォルダを取得します。
API では、指定した数または範囲のメッセージを読み取る、またはメッセージの特定の部分をあらかじめ取り出してフォルダのキャッシュに入れるなど、メッセージの読み込みについて複数のオプションを提供しています。詳細については、JavaMail API を参照してください。
WebLogic Server モジュール内から POP3 サーバで受信したメッセージを読み込む手順は次のとおりです。
import java.util.*;
import javax.activation.*;
import javax.mail.*;
import javax.mail.internet.*;
import javax.naming.*;
InitialContext ic = new InitialContext();
Session session = (Session) ic.lookup("myMailSession");
Properties オブジェクトを作成してオーバーライドするプロパティに追加します。getInstance() を呼び出して、新しいプロパティの新しいセッション オブジェクトを取得します。Properties props = new Properties();
props.put("mail.store.protocol", "pop3");
props.put("mail.pop3.host", "mailhost");
Session session2 = session.getInstance(props);
Store オブジェクトを取得し、connect() メソッドを呼び出してメール サーバに接続します。接続の認証を行うには、接続メソッドでメールホスト、ユーザ名、およびパスワードを提供する必要があります。Store store = session.getStore();
store.connect(mailhost, username, password);
Folder folder = store.getDefaultFolder();
folder = folder.getFolder("INBOX");
Message[] messages = folder.getMessages();
IMAP サーバからのメッセージの読み込みは、POP3 サーバからのメッセージの読み込みと同様です。ただし IMAP の場合は、フォルダを作成および操作し、フォルダ間でメッセージを転送するメソッドが JavaMail API で提供されています。IMAP サーバを使用すると、POP3 サーバを使用する場合よりも少ないコードで、多機能な Web ベースのメール クライアントを実装できます。POP3 では、おそらくデータベースまたはフォルダを表すためのファイル システムを使用して、WebLogic Server からメッセージ ストアを管理するコードを記述する必要があります。
WebLogic Server のクラスタにデプロイされる JSP およびサーブレットは、セッション データを保持するために特定の要件に従う必要があります。詳細については、『WebLogic Server クラスタ ユーザーズ ガイド』の「HTTP セッション ステートのレプリケーションに関する必要条件」を参照してください。
WebLogic Server クラスタでデプロイされる EJB には、EJB のタイプに基づく制約があります。クラスタ内のさまざまな EJB タイプの機能については、『WebLogic エンタープライズ JavaBeans (EJB) プログラマーズ ガイド』の「信頼性と可用性の機能」を参照してください。EJB は、EJB デプロイメント記述子でプロパティを設定することでクラスタにデプロイできます。
EJB またはカスタム RMI オブジェクトを開発する場合は、『WebLogic JNDI プログラマーズ ガイド』の「クラスタ環境での WebLogic JNDI の使い方」を参照して、クラスタ化されたオブジェクトの JNDI ツリーへのバインドについて理解してください。
|
|
|