レベル: 中級 馬場 剛, WebSphereテクニカル・セールス,
IBM
2004年 11月 17日 第3回「リソース参照再び」
はじめに
みなさまこんにちは。
すっかり秋らしくなってきましたが、いかがお過ごしでしょうか？
私は食欲の秋まっしぐら、順調に肥えてきております（*）。きのこご飯も炊きましたし、やっぱりこう寒くなってくると、これからの季節は鍋ですよね。
キムチ鍋もいいですし、カキ鍋、鶏の水炊き、うーん、今週末は何にしようかな。
鍋はやっぱり、最後に残った鍋汁（なべつゆ）で作る雑炊がおいしいですよね。材料の出汁が出ていて、そりゃあもう最高です！
・・・おっと、暴走しすぎました。食欲の話は置いておいて、本題に入りましょう。
今回はまず、前回の記事で作成したテストアプリケーションを使って、JDBCプロバイダーの有効範囲外からのlookupをしてみるんでしたね。
あとは・・・、EJB参照の話をちょっとだけして、それから・・・、どうしようかな・・・？？
|
（*）ざっと先月比+3kgってところですかね・・・。このままのペースではどう考えてもマズい状況です。
|
JDBCプロバイダー有効範囲外からのlookup
さて、前回の続きから始めましょう。
前回は作成したDSlookupWebアプリケーションを、ノードwas3のサーバーserver1で稼働させたところで終わりました。
今回はDSlookupWebアプリケーションをノードwas2のサーバーserver1で動かしてみます。検索対象のデータソースjdbc/sampleは、有効範囲をノードwas3として作成したJDBCプロバイダーの下に作成しました。ですので、これでDSlookupWebはJDBCプロバイダーの有効範囲外のアプリケーション・サーバーで稼働することになります。
DSlookupWebアプリケーションを配置しなおす
前回のおさらいが済んだところで、さっそくDSlookupWebをノードwas2のサーバーserver1へ配置しなおして、稼働させてみましょう。
既に配置されたアプリケーションの配置先を変更するのは非常に簡単です。
管理コンソールのナビゲーション・ツリーから「アプリケーション」を展開し、「エンタープライズ・アプリケーション」をクリックします。配置されているエンタープライズ・アプリケーションの一覧が表示されますので、DSlookupWebをクリックします。
図1：配置されているエンタープライズ・アプリケーションの一覧
DSlookupWebアプリケーションのプロパティーが表示されます。右側のプロパティー・ペインをずっと下へスクロールさせます。「追加プロパティー」の最後に「モジュールをアプリケーション・サーバーにマップ」が現れますのでクリックして進みます。
図2：DSlookupWebアプリケーションの追加プロパティー
「アプリケーション・サーバーの選択」に進みます。
「クラスターおよびサーバー」から
WebSphere: cell=was3Network, node=was2, server=server1
を選択し、モジュールDSlookupWebの左のチェックボックスをチェックして「適用」ボタンを押します。最後に「OK」を押すと完了です。
図3：アプリケーションの配置先アプリケーション・サーバーの選択
管理コンソール上部のメッセージにしたがって、変更をマスター構成に保管します。
JDBCプロバイダー有効範囲外からデータソースをlookupしてみる
配置先を変更したアプリケーションは停止させられていますので、始動しておきます。
先ほどの手順と同様に、ナビゲーション・ツリーから「アプリケーション」->「エンタープライズ・アプリケーション」の順にたどります。
エンタープライズ・アプリケーションの一覧が表示されますので、DSlookupWebアプリケーションの左のチェックボックスをチェックし、「始動」ボタンを押します。
あ、ノードwas3のサーバーserver1は起動してありますか？起動していないと、アプリケーションの起動に失敗してしまいます。
さて、DSlookupWebの起動がうまくいったら、さっそくDSlookupサーブレットを実行してみましょう。
Webブラウザから
http://was2:9080/DSlookupWeb/DSlookup
へアクセスします。
さて、どうなるでしょう・・・？ 前回の記事を理解できた方なら、結果は予想がつきますよね？？
リソースの有効範囲外からのlookup実行結果と考察
では、まずは実行結果を見てみましょう。
図4：ノードwas2サーバーserver1上でのDSlookupの実行結果
いかがですか？予想通りの結果だったでしょうか？
シンプル名jdbc/sampleは、アプリケーション・サーバーのプロセス内でのみ有効な名前でした。アプリケーションが稼働しているのはノードwas2のサーバーserver1、JDBCプロバイダーの有効範囲はノードwas3（の下にあるアプリケーション・サーバー）ですから、lookupはできないはずです。
このように、lookup()メソッドの引数にシンプル名を直接記述してしまうと、今回のようにアプリケーションの配置先を変更した場合、または検索対象のリソースの配置先が変更になった場合でも、検索を成功させるにはソースコードを書き換えて再コンパイルするしかなくなってしまいます。
完全修飾名でのlookupが成功するのは、前回のテストの時と同じ理由ですね。ただし、この場合も、リソースの配置先が変更になった場合には、シンプル名の場合と同様、ソースコードを書き換えて再コンパイルが必要になってしまいます。
ENC名でのlookupに成功するのは、ENC名から（完全修飾名で記述された）グローバル名へのリソース参照が正しく作成されているためであり、前回のテスト結果と同様です。
結果として、lookup()メソッドの引数にはENC名を用い、リソース参照で完全修飾名を使用して参照先のリソースを記述しておくことが、もっとも推奨される方法ということになります。この場合、今回のテストのようにアプリケーションの配置先が変更になった場合でも、アプリケーションやリソース参照の変更は必要ありません。また、リソースの配置先が変更になった場合には、リソース参照だけを変更すればよいことになります。いずれの場合でも、ソースコードを書き換えて再コンパイルを行う必要はありません。
次はEJB参照の話かな、と思ったのですが・・・
さて、リソース参照の話はこのくらいにしようと思います。 JNDIの「xxx参照」のうち、リソース参照の次によく利用されるのはEJB参照ではないかと思います。というわけで、EJB参照の話をしようと思ったのですが・・・
EJB参照の使い方は、以前に担当していた連載の「使ってみたくなるEJB」で既にご紹介済みでした。第5回「WebコンポーネントとEJBを接続しよう」で、サーブレットからEJBホーム・インターフェイスを取得する方法を解説しており、サーブレットEmpControllerのソースコードとEJB参照の作成方法を書きました。
ですので、EJB参照につきましてはそちらをご参照いただければと思います。
当の記事の中ではENC名を使用することの意味、メリットについては解説しておりません（*）が、基本的にはこれまで書いてきたリソース参照の場合と同様です。
もし、「あれじゃ分からん。もういっぺん、ちゃんとEJB参照を説明せんかい！」と思われた方は、このページの一番下のフォームからフィードバックいただければと思います。
|
（*）「使ってみたくなるEJB」を書いていた頃はまさに、第1回の冒頭でも書いたように「何となく」JNDIを使っていたんですよね・・・。
|
あれ？今回はもう終わり？
ちょうど区切りがいいところですので、今回の記事はここまでにしようと思います。
いつもよりかなり短い （*） ですが、次の話を始めてしまうと、きっととても長～くなってしまいますので・・・。
基本的なところはだいたい書けた気がしますので、あとはリソース環境参照と、RMI-IIOPの話くらいでしょうか。
IIOPと言えばインターオペラビリティー関係、WAS V3.5やV4とV5.xのように、WASのバージョンをまたいでのEJBの lookupですとか、WAS以外のクライアントからのlookupもどうしようかな、と思っています。この辺はなかなか難しそうですので、私もきちんと勉強しないと書けません。リクエストが多かったら頑張って書こうかな、と思っています。
|
（*）というより、私の場合はいつもが長すぎなんですよね。いつも「区切りのいいところまで書いてしまおう」と思って、結局、とても長くなってしまうんです・・・。
|
参考文献
著者について  | | | 馬場 剛, WebSphereテクニカル・セールス, IBM |
記事の評価
| 
