レベル: 中級 Willy Farrell, e-business Architect, IBM, Software Group
2002年 10月 01日 今回の記事では、非同期メッセージング・サポートをEnterprise JavaBeansアプリケーションに提供する方法について説明します。このアプリケーションは、WebSphere Application Server Version 4.xでサポートされていないメッセージ・ドリブンBeanによく似たものです。サンプル・コードとそれに関する説明が示され、コードのデプロイとアプリケーション・サーバーの構成のための手順が段階を追って示されています。この記事で使用されているソフトウェアはすべてダウンロードできます。
この記事の第2回では、WebSphere Application Serverのトランザクション処理機能を使用して、JMSメッセージ処理とデータベース・アクセスをトランザクションの単一作業内で実行する方法について説明します。
はじめに
以前に、
2回シリーズの記事
で、IBMのJava Message Service (JMS) 開発用ツールであるWebSphere MQとWebSphere Studio Application Developer (Application Developer) の入手、インストール、構成方法について説明しました。これらの記事では、ポイント・ツー・ポイント (P2P) ドメインと、パブリッシュとサブスクライブ (pub/sub) ドメインの両方についてJMSプログラムを作成する手順とサンプル・コードを示しました。
クライアントとサーバーで異なるトランスポート機構を使用するようWebSphere MQを構成する手順やリモート・キューイングを構成する手順も、こうした構成でサンプル・コードを実行する手順とともに示しました。
2回目の記事
の最後のセクションでは、WebアプリケーションでのJMSの使用について説明しました。
これらの記事で取り上げなかったトピックに関して、質問のメールを数多くいただきました。とりわけ話題となった2つのトピックは、WebSphere Application Server (Application Server) 内のWebSphere MQに関するものでした。寄せられた質問は次のようなものです。
- Application Server内のプロセスをどのように設定すれば、キューをモニターして着信メッセージをEnterprise JavaBeans (EJB) コンポーネントに送ることができるのか。
- EJBコンポーネント内のJMSコードは、特にデータベース・アクセスに関連してApplication Serverのトランザクション処理機能をどのように利用できるのか。
今回の記事では1番目の質問について取り上げ、2番目の質問については次回の記事で取り上げることにします。この記事の手順は、WebSphere MQとApplication Developerに関する以前の2つの記事のすべての手順を実行していることを前提にしているわけではありません。ただし、予備知識が必要です。少なくとも以前の記事をお読みになり、WebSphere MQ、JavaとJMS用のWebSphere MQクラス、WebSphere Studio Application Developerをインストールしていることを前提にしています (ソフトウェアへのリンクについては参考文献を参照)。
また、上記のツールが、以前の記事で指定されたディレクトリーにインストールされていることも前提としているので、そうでない場合は、ご自分の環境に合わせてこの記事の手順を実行してください。
バージョンについて
読者の中には、私が以前の記事で使用したのとは異なるバージョンのソフトウェアを使用して問題が発生したことを報告した方がいました。トライアル・バージョンではなくより新しいバージョンのApplication Developerを購入してインストールした方もいます。私の記事の発表後に、JavaとJMS用のWebSphere MQクラスの新しいバージョンが利用できるようになったこと、さらにWebSphere MQそのものの新しいバージョンがリリースされたことなどがその理由です。
急速に成長するテクノロジーのこのような時代に、こうした記事にとってバージョンは常に問題になるでしょう。私は、皆さんが、私とまったく同じバージョンのソフトウェアをご使用の場合は、すべての説明が望ましい結果を提供するよう非常に注意しています。しかし、参照されているソフトウェアの異なるバージョンを使用してエラーが発生した場合には、その理由は、おそらく指示に従わなかったからではないでしょう。それはおそらくバージョンの問題です。あきらめたり、私のことを誤った手順を示した愚かなやつなどと思ったりせずに、私までご連絡ください。私か他の者が問題の修正方法を知っている可能性が大いにあるからです。
例:WebSphere MQに関する以前の記事の発表後、JMSプログラムのクラスパスで必要な追加のJARファイルが含まれた、JavaとJMS用のWebSphere MQクラスのより新しいバージョンがリリースされました。記事の手順に従った場合、このJARファイルがないとNoClassDefFoundError 例外が発生します。問題について説明し、修正方法を示したファイルが利用可能です。さらに、新しいバージョン用に更新された構成ファイルも提供されています (参考文献を参照)。そういうわけで、ソフトウェアの異なるバージョンを使用して問題があった場合には、私までご連絡ください。
サンプル・コードと構成ファイルのインストール
ここで、サンプル・コードと構成ファイルをダウンロードし、インストールしてください。後で各ファイルを使用するときに、そのファイルと内容について詳しく説明したいと思います。
まず、コードをダウンロードして、構成ファイルを適切なWebSphere MQフォルダーにコピーします。
- サンプル・コードと構成ファイルをダウンロードする。このファイルの名前はi-mqejb1.zipです。
- zipファイルをシステムのC:\ フォルダーに解凍する。解凍時にフォルダー名を変更しないでください。そうすると、システムにC:\MQEJB1フォルダーが作成され、その中にサンプル・コードや構成ファイルが保存されることになります。
- C:\MQEJB1\JMSAdmin.fscontext.configをC:\WSMQ\Java\binにコピーする。
- C:\MQEJB1\setenv.batをC:\WSMQ\Java\binにコピーする。
- C:\MQEJB1\setup.svcをC:\WSMQ\Java\binにコピーする。
Application Developerへのサンプル・コードのインポート
次に、サンプル・コードをApplication Developerにインポートし、コードを保持するプロジェクトを作成します。
-
Start メニューからApplication Developerを起動する。これ以降は、Application Developerが実行されているものとして手順を説明します。
- メニューからFile>Import... を選択する。
-
EAR file を選択し、Next をクリックする。
-
EAR file フィールドに
C:\MQEJB1\mqejbs.ear とタイプする。
-
Enterprise application project name: フィールドに
MQEJBsEAR とタイプする。Finish をクリックする。
- Tasksビューに2つの警告メッセージが表示されますが、これらは無視してください。
- Javaパースペクティブを開く。
- Packagesビュー内を右クリックし、New>Other... を選択する。
- 左側ペインでJava を選択し、右側ペインでJava Project を選択して、Next をクリックする。
-
Project name: フィールドに
MQSamples とタイプし、Next をクリックする。
-
Projects タブをクリックし、MQEJBsにチェックを入れる。そうすると、このプロジェクトのビルド・クラスパスにMQEJBsプロジェクトが追加されます。
-
Libraries タブをクリックし、Add External Jars... をクリックする。
- C:\WSMQ\Java\libに移動し、com.ibm.mq.jar、com.ibm.mqjms.jar、connector.jarを選択して、Open をクリックする。これらのJARファイルには、このプロジェクトに使用されているJavaとJMS用のWebSphere MQクラスが含まれています。
-
Add External Jars... をクリックして、C:\WSAD\plugins\com.ibm.etools.websphere.runtime\libに移動し、ivjejb35.jar、j2ee.jar、runtime.jar、websphere.jarを選択して、Open をクリックする。ivjejb35.jarにはEJB Access Beans (詳細については後で説明します) 用のクラスが含まれており、j2ee.jarにはJMSインターフェースが、runtime.jarにはServerListenerインターフェース (後で説明) が、またwebsphere.jarにはCustomServiceインターフェース (後で説明) が含まれています。
-
Finish をクリックする。
- MQSamplesプロジェクトを右クリックし、New>Package... を選択する。
-
Package: フィールドに
com.ibm.ssya.mq.customservice とタイプし、Finish をクリックする。
- com.ibm.ssya.mq.customserviceパッケージを選択する。
- メニューからFile>Import... を選択する。
-
File system を選択し、Next をクリックする。
- ディレクトリーをC:\MQEJB1にする。
- 左側ペインでMQEJB1を選択し (チェックは入れない)、右側ペインでJMSCustomService.javaにチェックを入れ、Finish をクリックする。
 |
メッセージ・ドリブンBeanのシミュレート
EJB Version 2.0は、メッセージ・ドリブンBean (MDB) と呼ばれるエンタープライズBeanを導入しました。MDBは、キューに到着したJMSメッセージに応答できる非クライアントBeanで、EJBアプリケーションに非同期通知メカニズムを提供します。EJB Version 2.0は、Java 2 Enterprise Edition (J2EE) Version 1.3の一部です。
WebSphere Application Server Advanced Edition Version 4.xは、J2EE Version 1.3をサポートしていません (Application Server Version 5.xはサポートする予定です)。そのかわりJ2EE Version 1.2と、当然ながらMDBを持たないEJB Version 1.1をサポートしています。私はよく、「Application Server 5.xがリリースされるまで、少なくともApplication Server 4.xでMDBをシミュレートする何らかの方法があるか」という質問を受けます。その答えは、キューに到着するメッセージを受け取るためにリスナーを設定し、そうしたメッセージをステートレス・セッションBeanに送り、処理することです。リスナーは、セッションBeanが配置されるアプリケーション・サーバーによって開始、停止されるのが理想的です。しかし、これが少し厄介な点なのです。
Application Server 4.xは、com.ibm.websphere.runtime.CustomService インターフェースを提供します。これを実装すると、「サーバーの起動時とシャットダウン時に実行されるフック・ポイントを定義する」 (ドキュメンテーションを引用) ことができます。しかし、ドキュメンテーションを読み進むと、このインターフェースの制限が指摘されており、私たちの目的にはふさわしくありません。カスタム・サービス・クラスは、Java Naming and Directory Interface (JNDI) ネーム・サーバーが初期化される前に呼び出され、J2EE呼び出し (EJBコンポーネントの呼び出しなど) は許可されません。しかし、私たちが求めている機能を提供するために使用できる別のインターフェースがあります。
com.ibm.ws.event.ServerListener インターフェースはCustomService インターフェースと連動させると、起動やシャットダウンなど、サーバーのライフサイクルの特定のステップの開始または終了を通知するアプリケーション・サーバーのイベント・メッセージを受け取るクラスを作成できます。キューにリスナーを設定することにより、アプリケーション・サーバーが起動を完了すると、MDBをシミュレートする機能を提供できます。ServerListener インターフェースは文書化されていないため、Application Serverの将来のバージョン (Version 5.xなど) にはないかもしれません。だからといって、慌てる必要はありません。Application Serverの将来のバージョンではMDBの完全なサポートが提供され、予備の手段としてServerListener を使用する必要はなくなります。
JMSCustomServiceクラス
サンプル・コードで提供されているJMSCustomService クラスは、着信メッセージを受け取り、それをEJBコンポーネントに送るクラスです。このクラスのさまざまな部分を見てみましょう。まずはクラス宣言から始めます。
JMSCustomServiceクラス宣言
public class JMSCustomService
implements CustomService, ServerListener, MessageListener {
|
JMSCustomService は、次の3つのインターフェースを実装します。
-
CustomService
- アプリケーション・サーバーに登録できる
-
ServerListener
- サーバーからイベント・メッセージを受け取る
-
MessageListener
- JMSから非同期メッセージを受け取ることができる
CustomService インターフェースには、initialize() とshutdown() の2つのメソッドが必要です。initialize() は、アプリケーション・サーバーのライフサイクルの初期、つまり起動時に呼び出され、その名前のとおり、オブジェクトに必要な初期化を行えます。shutdown() は、ご想像のように、サーバーのシャットダウン時に呼び出され、オブジェクトに必要な後片付けを行えます。JMSCustomService のこれらのメソッドを見てみましょう。
initialize() メソッドとshutdown() メソッド
public void initialize(Properties properties) throws Exception {
queueConnectionFactoryName = properties.getProperty(QUEUE_CONNECTION_FACTORY);
queueName = properties.getProperty(QUEUE);
}
public void shutdown() throws Exception {
if (connection != null)
connection.close();
}
|
initialize() メソッドにはProperties オブジェクトがパラメーターとして渡されます。このオブジェクトにはCustomService の初期設定値がセットされています。JMSCustomService では、JMS処理に使用されるQueueConnectionFactory とQueue のJNDI名の2つがプロパティーとして渡されます。値をプロパティーに割り当てる方法については後で説明します。
JMSCustomService のshutdown() メソッドは、作成されたQueueConnection オブジェクトをクローズするだけです。
ServerListener インターフェースに必要なメソッドは数多くありますが、ここではserverStarted() メソッドについてのみ取り上げます。これは、すべての起動処理が終了するとアプリケーション・サーバーによって呼び出されます。JMSCustomService のserverStarted() メソッドを以下に示します。
serverStarted() メソッド
public void serverStarted(ServerEvent event) {
try {
messageEJBFactory = new MessageEJBFactory();
Context context = new InitialContext();
QueueConnectionFactory factory =
(QueueConnectionFactory) context.lookup(queueConnectionFactoryName);
queue = (Queue) context.lookup(queueName);
connection = factory.createQueueConnection();
session =
connection.createQueueSession(false, Session.AUTO_ACKNOWLEDGE);
receiver = session.createReceiver(queue);
receiver.setMessageListener(this);
connection.start();
} catch (Throwable t) {
t.printStackTrace();
}
}
|
serverStarted() の最初の行はステートレス・セッションBean用のEJBファクトリーを作成するもので、これがMDBをシミュレートします。EJBファクトリーは、EJBコンポーネントのホーム・インターフェース・メソッドにシンプルなアクセスを提供するJavaBeansコンポーネントです。EJBファクトリーは、Application DeveloperでAccess Beansテクノロジーの一部として提供されます。
このコードの残りは、簡単なJMS処理です。
- JNDIから
QueueConnectionFactory とQueue を検索し、
-
QueueConnection を作成し、
-
QueueSession を作成し、
-
QueueReceiver を作成し、
-
QueueReceiver のMessageListener を設定して、
-
QueueConnection を起動し、メッセージ・フローを開始します。
この時点で、Queue で受け取られたメッセージは、以下に示すようにJMSCustomService のonMessage() メソッドに渡されます。
onMessage() メソッド
public void onMessage(Message message) {
try {
MessageEJB receiver = messageEJBFactory.create();
receiver.onMessage(message);
receiver.remove();
} catch (Throwable t) {
t.printStackTrace();
}
}
|
まず、serverStarted() でインスタンス化されたEJBファクトリーによってMessageEJB が作成されます。MessageEJB は、MDBをシミュレートするために使用されているステートレス・セッションBeanです。次に、MessageEJB のonMessage() メソッドが呼び出され、受け取られたメッセージをここで渡します。その後、MessageEJB インスタンスは削除されます。
JMSCustomService のコードはあまり複雑ではありません。initialize() でプロパティーを取得し、EJBファクトリーを取得して、serverStarted() でJMS処理用の標準設定を行い、onMessage() でEJBコンポーネントにメッセージを渡します。
MessageEJBセッションBean
では、MessageEJB のコードについて調べてみましょう。まず、以下のリモート・インターフェースを見てみます。
MessageEJBリモート・インターフェース
public interface MessageEJB extends EJBObject, EJBMessageReceiver {
}
|
ここではおかしな点が2つあると思われます。まず、このファイルにはメソッドの宣言がありません。2つめは、おそらく皆さんは、MessageEJB がJMSのMessageListener インターフェースを継承すると思われていたでしょう。この2つの点には関係があります。
MessageListener インターフェースには、JMSMessage をパラメーターとして受け取るonMessage() メソッドがあります。しかし、MessageListener のonMessage() メソッドは、EJBコンポーネントのリモート・インターフェースには適していません。なぜなら、このメソッドは、リモート・インターフェース・メソッドに必要なRemoteException をスローしないからです。これを解決するために、サンプル・コードは、特別に作成されたインターフェースを使用して、この問題に対処しています。以下に示されているEJBMessageReceiver は、EJBコンポーネントのリモート・インターフェースによって使用できるonMessage() メソッドを提供するために私が作成したインターフェースです。
EJBMessageReceiverインターフェース
public interface EJBMessageReceiver {
public void onMessage(Message message)
throws JMSException, RemoteException;
}
|
このインターフェースを使用することによって、MessageEJB にメソッドの宣言がない理由も説明できます。EJBMessageReceiver インターフェースにはonMessage() の宣言が含まれているのです。
Application Developerでは、onMessage() メソッドに関して、Message パラメーターがSerializable でなければならないことを示す警告メッセージに注意してください。JMS APIではMessage はSerializable を宣言しませんが、WebSphere MQなどのMessage のほとんどのベンダー実装は直列化可能であるので、警告は無視しても問題ありません。
では、エンタープライズBeanそのものについて見ることにしましょう。MessageEJBBean クラスのonMessage() とejbCreate() という2つのメソッドについて取り上げます。
JMS処理を行うために、以下に示されているejbCreate() では、ローカル環境を使用してJMSの管理オブジェクトを検索しています。こうしたリソースの参照は、EJBコンポーネントのデプロイメント記述子で設定されています。EJB EditorでMQEJBsプロジェクトを開くと、これらのリソース参照が宣言されている場所が表示されます。EJB Extension EditorでMQEJBsプロジェクトを開くと、リソース参照が、管理オブジェクト用に実際のJNDI名にバインドされている場所が表示されます。
ejbCreate() メソッド
public void ejbCreate() throws CreateException {
try {
Context context = new InitialContext();
Context environment = (Context) context.lookup("java:comp/env");
factory =
(QueueConnectionFactory) environment.lookup(QUEUE_CONNECTION_FACTORY);
queue = (Queue) environment.lookup(QUEUE);
} catch (NamingException ne) {
throw new CreateException(ne.getMessage());
}
}
|
以下のように、MessageEJBBean のonMessage() メソッドは、JMSCustomService によって呼び出され、着信メッセージを処理するために次のキューに渡しています。
onMessage() メソッド
public void onMessage(Message message) throws JMSException {
QueueConnection connection = factory.createQueueConnection();
QueueSession session =
connection.createQueueSession(false, Session.AUTO_ACKNOWLEDGE);
QueueSender sender = session.createSender(queue);
sender.send(
session.createTextMessage(((TextMessage) message).getText()));
connection.close();
}
|
ここでは、ejbCreate() で取得した管理オブジェクトは標準JMSの設定を行うのに使用され、受け取られたメッセージのテキストは別のキューに送られます。これは単なるサンプル・コードなので、メッセージが受信され、それが処理されたことを簡単にデモンストレーションするために、別のキューへメッセージを送信する例を示しましたが、実際のアプリケーションのonMessage() メソッドでは、必要とされるどのような処理でも行うことができます。
WebSphere MQオブジェクトの定義
JMSCustomService クラスとMessageEJB コンポーネントについて説明してきたので、ここではそれらをApplication Developerでテストすることができます (もちろん、いくつかの設定の後で)。まず、アプリケーションがアクセスするWebSphere MQオブジェクトを定義する必要があります。着信メッセージ用のキュー・マネージャーとキュー、および発信メッセージ用の2つめのキュー・マネージャーとキューを定義します。
- StartメニューからMQSeries Explorerを起動する。これ以降は、MQSeries Explorerが実行されているものとして手順を説明します。
-
Queue Managers フォルダーを右クリックし、New>Queue Manager を選択する。
-
Queue Manager: フィールドに
QM1 とタイプする。
-
Dead Letter Queue: フィールドに、
SYSTEM.DEAD.LETTER.QUEUE とタイプする (大文字であることが重要)。
-
Next を3回クリックし、Finish をクリックする。
- Queue Managersの横にある+ 記号をクリックする。
- QM1の横にある+ 記号をクリックする。
-
Queues フォルダーを右クリックし、New>Local Queue を選択する。
-
Queue Name: フィールドに
Q1 とタイプする。OK をクリックする。
-
Queue Managers フォルダーを右クリックし、New>Queue Manager を選択する。
-
Queue Manager: フィールドに
QM2 とタイプする。
-
Dead Letter Queue: フィールドに、
SYSTEM.DEAD.LETTER.QUEUE とタイプする (大文字であることが重要)。
-
Next を3回クリックする。
-
Listen on port number: フィールドに
1415 とタイプし、Finish をクリックする。
- QM2の横にある+ 記号をクリックする。
-
Queues フォルダーを右クリックし、New>Local Queue を選択する。
-
Queue Name: フィールドに
Q2 とタイプする。OK をクリックする。
構成ファイル
これで、管理オブジェクトを作成し、それらをJNDIネームスペースにバインドすることができます。それを行うために使用するファイルを見てみましょう。まず、以下のJMSAdmin.fscontext.configから始めます。
JMSAdmin.fscontext.config
#
# This is the default configuration file for the MQSeries Classes for
# Java Message Service Administration Tool.
#
# The following line specifies which JNDI service provider is in use.
# It currently indicates an LDAP service provider. If a different
# service provider is used, this line should be commented out and the
# appropriate one should be uncommented.
#
#INITIAL_CONTEXT_FACTORY=com.sun.jndi.ldap.LdapCtxFactory
INITIAL_CONTEXT_FACTORY=com.sun.jndi.fscontext.RefFSContextFactory
#INITIAL_CONTEXT_FACTORY=com.ibm.ejs.ns.jndi.CNInitialContextFactory
#INITIAL_CONTEXT_FACTORY=com.ibm.websphere.naming.WsnInitialContextFactory
#
# The following line specifies the URL of the service provider's initial
# context. It currently refers to an LDAP root context. Examples of a
# file system URL and WebSphere's JNDI namespace are also shown,
# commented out.
#
#PROVIDER_URL=ldap://polaris/o=ibm,c=us
PROVIDER_URL=file:/C:/MQEJB1
#PROVIDER_URL=iiop://localhost/
#
# The following line specifies the security authentication model in use,
# and may be 'none' (for anonymous authentication), 'simple', or
# 'CRAM_MD5'.
#
SECURITY_AUTHENTICATION=none
#
# If you don't have SECURITY_AUTHENTICATION=none, then JMSAdmin will
# prompt you for the User DN and password. If you want to bypass these
# prompts then you can specify one or both of the values here. Since
# the password here is in cleartext this is not normally recommended
# except for testing. You should replace these values with your own.
#
#PROVIDER_USERDN=cn=Manager,o=ibm,c=uk
#PROVIDER_PASSWORD=secret
#
#
# The following line determines whether to use an InitialDirContext, or an
# InitialContext. Takes value of TRUE or FALSE.
#USE_INITIAL_DIR_CONTEXT=TRUE
#
# The following line specifies a prefix to add to names when carrying
# out operations such as lookup/bind.
#NAME_PREFIX=cn=
#
# The following line specifies a marker at which names will be truncated
# when viewing the contents of the Context.
#NAME_READABILITY_MARKER=..
#
# The three standard types of InitialContextFactory have the following
# defaults;
# Note that these defaults will be set automatically if the flags are
# not present, but will be overridden by including the flags.
#
# LDAP FSCONTEXT WEBSPHERE
# ------------------------------------------------------------------------------
# USE_INITIAL_DIR_CONTEXT TRUE FALSE FALSE
# NAME_PREFIX cn= omitted omitted
# NAME_READABILITY_MARKER omitted omitted ..
#
|
このファイルは、JMSの管理オブジェクトを作成し、それらをJNDIにバインドするために使用されるJMSAdminプログラムの構成を設定するために使用されます。この記事のサンプル・コードでは、Application DeveloperのWebSphere Test Environmentによって提供されるJNDIネーミング・サーバーではなく、MA88によって提供されるファイル・ベースのネーミング・サーバーを使用することにします。WebSphere Test Environmentは、呼び出し間でJMSAdminによってバインドされたオブジェクトを保持しないので、制限のないこのネーミング・サーバーの使用が必要です。バインディング情報は、サンプル・コードをシステムに解凍したときに作成されたディレクトリーに保存されることに注意してください。
では、以下のsetenv.batを見てみましょう。
setenv.bat
@echo off
set MQ_JAVA_INSTALL_PATH=c:\wsmq\java
@rem Java runtime
set JAVA_HOME=C:\WSAD\plugins\com.ibm.etools.server.jdk\jre\bin
@rem MQ JMS
set MQ=%MQ%;%MQ_JAVA_INSTALL_PATH%\lib
set MQ=%MQ%;%MQ_JAVA_INSTALL_PATH%\lib\com.ibm.mq.jar
set MQ=%MQ%;%MQ_JAVA_INSTALL_PATH%\lib\com.ibm.mqjms.jar
set MQ=%MQ%;%MQ_JAVA_INSTALL_PATH%\lib\jms.jar
set MQ=%MQ%;%MQ_JAVA_INSTALL_PATH%\lib\connector.jar
set MQ=%MQ%;%MQ_JAVA_INSTALL_PATH%\lib\fscontext.jar
set MQ=%MQ%;%MQ_JAVA_INSTALL_PATH%\lib\providerutil.jar
set CLASSPATH=%MQ%;%CLASSPATH%
set PATH=%JAVA_HOME%;%MQ_JAVA_INSTALL_PATH%\lib;%PATH%;
|
setenv.batは、JMSAdminが適切に機能するために必要な環境変数を設定します。ご覧のように、このバッチファイルは、WebSphere Test Environment Java Runtime Environment (JRE) を使用するようにJMSAdminを設定し、すべての必要な .jarファイルをクラスパスに置きます。
最後に、setup.svcという構成ファイルについて見てみます。
setup.svc
def ctx(mq)
chg ctx(mq)
def qcf(MyQCF) qmgr(QM1)
def q(MyQueue) qmgr(QM1) queue(Q1)
def qcf(AnotherQCF) qmgr(QM2)
def q(AnotherQueue) qmgr(QM2) queue(Q2)
end
|
このスクリプトは、MQSeries Explorerで作成したキュー・マネージャーとキューに対応する管理オブジェクトを作成し、それらをmq コンテキストに置きます。
管理オブジェクトの作成
これで、スクリプト・ファイルを使用して、構成コマンドを実行するだけで、管理オブジェクトを作成することができます。デフォルトのJMSAdmin構成ファイルを使用していないので、-cfg フラグを使用して、JMSAdmin.fscontext.configに構成情報が含まれていることを示さなければなりません。
- コマンド・プロンプトを開く。
- ディレクトリーをC:\WSMQ\Java\binに変更する。
-
setenv とタイプして、Enter を押す。
-
JMSAdmin<setup.svc -cfg JMSAdmin.fscontext.config とタイプして、Enter を押す。
WebSphereテスト・サーバーの定義
次に、カスタム・サービスとEJBコンポーネントを実行するために、Application Developerでサーバーを作成し、構成する必要があります。
- Application DeveloperでServerパースペクティブを開く。
- Navigatorビューを右クリックし、New>Server Project を選択する。
-
Project name: フィールドに
ServerProject とタイプし、Finish をクリックする。
- ServerProjectを右クリックし、New>Server Instance and Configuration を選択する。
-
Server name: フィールドに
TestServer とタイプする。
- WebSphere 4.0 Test EnvironmentとしてServer instance type: を選択する。
-
Finish をクリックする。
- Server Configurationビューで、Server Configurationsの下のTestServerをダブルクリックする。
-
Enable administration client にチェックを入れる。
-
Ctrl-S を押して、構成を保存する。
- Serversビューで、TestServerを右クリックし、Start を選択する。
- "Server Default Server open for e-business" というメッセージが表示されるのを待って次に進む。
サーバーでのJMSプロバイダーの構成
次のステップでは、サーバー管理コンソールを使用して、アプリケーション・サーバー内でJMSプロバイダーを構成します。WebSphere MQをそのJMSプロバイダーとして使用するようサーバーを構成して、カスタム・サービスとEJBコンポーネントによってアクセスされるJMS ConnectionFactoryオブジェクトとJMS Destinationオブジェクトを定義します。
- Serversビューで、TestServer を右クリックし、Run administrative client を選択する。
- Login画面でSubmit をクリックする。
-
Resources の横にある+ 記号をクリックする。
-
JMS Providers をクリックする。
-
New をクリックする。
-
Resource Provider Type: フィールドに
IBM MQSeries (Local WebSphere Naming Context) が設定されていることを確認し、Next をクリックする。
-
Server Class Path フィールドで、Server Class Path テキスト・フィールドに下記エントリーすべてを1行でタイプする。
-
C:\WSMQ\Java\lib;
-
C:\WSMQ\Java\lib\com.ibm.mq.jar;
-
C:\WSMQ\Java\lib\com.ibm.mqjms.jar;
-
C:\WSMQ\Java\lib\connector.jar;
-
C:\WSMQ\Java\lib\fscontext.jar;
-
C:\WSMQ\Java\lib\providerutil.jar
これにより、サーバーでWebSphere MQ Javaクラスが利用できるようになります。
-
Name: フィールドを
WebSphere MQ に変更する。
-
Description: フィールドを
WebSphere MQ using the file-based naming server に変更する。
-
External Initial Context Factory: フィールドを
com.sun.jndi.fscontext.RefFSContextFactory に変更する。
-
External Provider URL: フィールドを
file:/C:/MQEJB1 に変更する。
-
OK をクリックする。
- JMS Providersの横にある+ 記号をクリックする。
- WebSphere MQの横にある+ 記号をクリックする。
-
JMS Destinations をクリックする。
-
New をクリックする。
-
Name: フィールドに
MyQueue とタイプする。
-
JNDI Name: フィールドを
jms/MyQueue に変更する。
-
Destination Type: フィールドに
QUEUE を設定する。
-
External JNDI Name: フィールドに
mq\MyQueue とタイプする。(スラッシュ "/" ではなく、逆スラッシュ "\" を使用することに注意してください。ファイル・ベースのネーミング・サーバーを使用しているので、オペレーティング・システムの区切り文字を使用しなければなりません。)
-
OK をクリックする。
-
New をクリックする。
-
Name: フィールドに
AnotherQueue とタイプする。
-
JNDI Name: フィールドを
jms/AnotherQueue に変更する。
-
Destination Type: フィールドに
QUEUE を設定する。
-
External JNDI Name: フィールドに
mq\AnotherQueue とタイプする。(スラッシュ "/" ではなく、逆スラッシュ "\" を使用することに注意。)
-
OK をクリックする。
-
JMS Connection Factories をクリックする。
-
New をクリックする。
-
Name: フィールドに
MyQCF とタイプする。
-
JNDI Name: フィールドを
jms/MyQCF に変更する。
-
External JNDI Name: フィールドを
mq\MyQCF に変更する。(スラッシュ "/" ではなく、逆スラッシュ "\" を使用することに注意。)
-
Connection Type: フィールドに
QUEUE を設定する。
-
OK をクリックする。
-
New をクリックする。
-
Name: フィールドに
AnotherQCF とタイプする。
-
JNDI Name: フィールドを
jms/AnotherQCF に変更する。
-
External JNDI Name: フィールドを
mq\AnotherQCF に変更する。(スラッシュ "/" ではなく、逆スラッシュ "\" を使用することに注意。)
-
Connection Type: フィールドに
QUEUE を設定する。
-
OK をクリックする。
|
カスタム・サービスの構成
では、JMSCustomService クラスをカスタム・サービスとして使用するよう、アプリケーション・サーバーを構成しましょう。
- 管理コンソールのWebブラウザーでNodes の横にある+ 記号をクリックする。
-
localhost の横にある+ 記号をクリックする。
-
Application Servers の横にある+ 記号をクリックする。
-
Resources の横にある+ 記号をクリックする。
-
Default Server の横にある+ 記号をクリックする。
-
Custom Services をクリックする。
-
New をクリックする。
-
Display Name: フィールドに
JMS Custom Service とタイプする。
-
Enable ボックスにチェックを入れる。
-
Classname: フィールドに、
com.ibm.ssya.mq.customservice.JMSCustomService とタイプする。
-
Classpath: フィールドで、Classpath: テキスト・フィールドに下記エントリーすべてを1行でタイプする。
-
C:\WSMQ\Java\lib;
-
C:\WSMQ\Java\lib\com.ibm.mq.jar;
-
C:\WSMQ\Java\lib\com.ibm.mqjms.jar;
-
C:\WSMQ\Java\lib\connector.jar;
-
C:\WSAD\workspace\MQSamples;
-
C:\MQEJB1\MessageEJB_classes.jar
この最後のJARファイルには、MessageEJB用のホーム・インターフェースとリモート・インターフェース、MessageEJB用のEJBファクトリー・クラスが含まれています。
-
OK をクリックする。
-
JMS Custom Service をクリックする。
-
Dynamic Properties をクリックする。
-
New をクリックする。
-
Name: フィールドに
queueConnectionFactory とタイプする。
-
Value: フィールドに
jms/MyQCF とタイプする。
-
OK をクリックする。
-
New をクリックする。
-
Name: フィールドに
queue とタイプする。
-
Value: フィールドに
jms/MyQueue とタイプする。
-
OK をクリックする。
- もう一度OK をクリックする。
- もう一度OK をクリックする。
- Webブラウザーの上部にあるメニュー・バーでSave をクリックする。
-
OK をクリックし、構成を保存する。
- Webブラウザーの上部のメニュー・バーでExit をクリックする。
- Webブラウザーの横にあるX をクリックして、Webブラウザーを閉じる。
- ServersビューでTestServer を右クリックし、Stop を選択する。
注:MessageEJB_classes.jarが機能するためには、JMSCustomService のクラスパスに、ホーム・インターフェースとリモート・インターフェース、EJBファクトリー・クラスだけが設定されていることが必要です。EJBコンポーネントの他のクラス、特に生成されたクラスを含めると、クラスローダーの問題が発生し、EJBコンポーネントへのリモート呼び出しが機能しなくなります。
カスタム・サービスのテスト
これで、カスタム・サービスをテストする準備ができました。ただし、最後に1つ設定のステップがあります--テスト・サーバーで実行するためにEJBコンポーネントを割り当てることが必要です。それを行って、サーバーが起動すると、MQSeries Explorerを使用して、キュー・マネージャーQM1のQ1にテスト・メッセージを置くことができます。すべてが正常に機能すると、キュー・マネージャーQM2のQ2にメッセージが表示されます。
- Server Configurationビューで、Server Configurationsの下のTestServerを右クリックし、Add Project>MQEJBsEARを選択する。
- ServersビューでTestServerを右クリックし、Start を選択する。
- "Server Default Server open for e-business" というメッセージが表示されるのを待って次に進む。
- MQSeries ExplorerでQ1を右クリックし、Put Test Message.. を選択する。
-
Message Data: フィールドにテキストをタイプし、OK をクリックする。
- Q1をダブルクリックすると、作成したテスト・メッセージがキューにないことが表示されます。
- Q2をダブルクリックすると、テスト・メッセージが現在そのキューにあることが表示されます。
- テストが終了したら、必ずTestServerを停止してください。
まとめ
WebSphere Application Server 4.xでEJBアプリケーションに非同期メッセージング機能を提供するのは非常に簡単です。文書化されていないServerListener インターフェース以外は、コードは非常に簡単です。WebSphere Application Server Advanced Edition Version 4.0.3でこのコードをテストしましたが、以下の点を除いて、Application DeveloperのWebSphere Test Environmentの場合と同じように機能しました。
-
mq コンテキストでも、JMS管理によるオブジェクトをApplication Server JNDIネームスペースにバインドした。
- Application Serverのインストール時にデフォルトで作成されるIBM MQSeries JMSプロバイダーを使用した。
- IBM MQSeries JMSプロバイダーではJMS Connection Factory
AnotherQCF のみを定義し、IBM MQSeries JMSプロバイダーではAnotherQueue のみを定義した。
- カスタム・サービス用に
queueConnectionFactory パラメーターの値をmq/MyQCF に変更し、queue パラメーターの値をmq/MyQueue に変更した。
次回予告
次回の記事では、WebSphere Application Serverのトランザクション処理機能を使用して、JMSメッセージング処理とデータベース・アクセスを同じトランザクションの一部として実行する方法について説明します。
ダウンロード | ファイル名 | サイズ | ダウンロード形式 |
|---|
| i-mqejb1.zip | | HTTP |
参考文献
著者について | 
| | Willy Farrellは、IBMのビジネス・パートナーへの教育、補助、相談を行う組織であるIBM Developer Relations Technical Consulting (別名The DragonSlayers) に勤務しています。1981年以来、生活の糧としてコンピューター・プログラミングに従事し、1996年にJavaを使い始め、1998年にIBMに入社しました。Willyは特に、Java 2 Programmer、WebSphere Application Server Enterprise Developer、WebSphere Studio Application Developer Solution Developer、MQSeries Solutions Expert、およびIBM e-business Solution Technologistといった技術認定証を取得しています。 |
記事の評価
| 
