今さら人に訊けない JNDI: 第 2 回 「リソース参照って何ですか?」

第 2 回「リソース参照って何ですか?」

はじめに

みなさまこんにちは。暑い日が続きますがお元気でお過ごしでしょうか?
夏休みシーズンもすっかり過ぎてしまいましたが、社会復帰は順調でしょうか?
え?「『夏休み』って食べられる?」ですって?
おつかれさまです。今のお仕事/プロジェクト/その他もろもろが片付き次第、遅い夏休みをきっと取得できるようにお祈りしております。
さて、今回は何を書こうかいろいろ悩んだのですが、まずは WebSphere Application Server (以下 WAS) V5.x での複数サーバー構成における、JNDI ネームスペースのしくみから始めたいと思います。これがわからないことには、データソースなどのリソースや EJB ホームを lookup すると言っても、探しようがありませんからね。
で、ネームスペースのしくみが分かったところで、実際にデータソースの lookup をいろいろな方法でテストしてみたいと思います。
最後に、テストの結果を基に、どの場面でどの方法を用いるのがよいか、考察してみましょう。

おことわり

私自身、この連載のためにいろいろ調べたり書いたり動かしたりしているのですが、「JNDI ってちゃんとやろうとすると、難しいことがいっぱいあるみたいだな・・・」という気がしてきています。
そのようなわけで、これから WAS V5.x での JNDI についていろいろ調べたり書いたり動かしたりするわけですが、初めのうちは「厳密さ」を深く追求しません。また、すべての情報を網羅的に載せることもしません。まずは概要を理解して、「とりあえず」書いて動かすことができるようになることを目指していきます。
何もマニュアルを書こうとしているのではありませんし、初めから「難しいことをいっぱい」書いてしまうと、何が何だかわからなくなってしまいますからね・・・。 とはいえ、もちろん、必要なところはきっちり厳密にやっていきます。JNDI っていいかげんに扱っていると、簡単にトラブルの元になってしまいますので。
厳密で網羅的な情報が必要な方は、Infocenterを適宜参照して下さい。

前提条件

さて、これからいろいろ書いたり動かしたりしていくわけですが、記事中のサンプルを実際に動かすには、WAS V5.x Network Deployment の複数ノード構成やクラスターをセットアップすることができ、JDBC プロバイダーの設定やデータソースの作成、WebSphere Studio による Web アプリケーションや EJB の開発、WAS へのアプリケーションのインストールなど、基本的な作業ができることを前提とします。 これらの作業については、記事中で手順を詳しく説明しません。必要に応じて他の情報源を参照して下さい。


今回のテスト機の構成

さっそくですが、本題に入る前にテスト機の構成を説明します。
今回は複数サーバー構成ということで、2 台のサーバーを用意してセルを構成しています。
また、各サーバーに一つずつ、アプリケーション・サーバーを構成しています。
図にすると以下のようになります。

図 1. テスト機構成

今回もサンプルを用いていくつかテストを行いますが、ご自分でも試してみようと思われる方は、図を参考に同様の構成を作っておいて下さい (*)。 マシン名やノード名、サーバー名などの名前は図と同じである必要はありません。図と異なる名前を用いた場合は、以降の説明を適切に読み替えて下さい。

(*) WAS V5.1 (Base) は試用版をダウンロードできますが、WAS V5.1 ND は今のところ試用版の提供はされていません。


WAS V5.x の JNDI ネームスペースと記述のしかた

WAS V5.x の JNDI ネームスペースはセルを頂点とするツリー構造になっています。 つまり、WAS 管理モデルのセル−ノード−サーバーの関係と同様です。
例えば、図 1 に示す構成の JNDI ネームスペースを図にすると、以下のようになります。

図 2. 図 1 の場合の JNDI ネームスペース

JNDI 完全修飾名

この構成で、例えばノード was2 のアプリケーション・サーバーserver1 を示す JNDI 名はどのようになるのでしょうか?
JNDI 名は基本的に、コンテキスト名を上位のものから順に"/"で区切って並べれば OK です。
ただし、ノード・コンテキスト名の前には"nodes/"を入れることになっています。同様に、サーバー・コンテキスト名の前には"servers/"を入れる必要があります。
つまり、ノード was2 のアプリケーション・サーバーserver1 を示す JNDI 名は

was3Network/nodes/was2/servers/server1

のようになるわけです。
また、WAS V5.x では、セル名は"cell"で置き換えることができます。
つまり、上の例は

cell/nodes/was2/servers/server1

と記述しても同じ意味になります。
このように、セルレベルからコンテキスト名を順に記述したものを、JNDI「完全修飾名」 (または「コンパウンド (compound) 名」) といいます。
ちなみに、今回はありませんが、クラスターを構成した場合のクラスターの JNDI 名は

cell/clusters/<クラスター名>

となります。

JNDI シンプル名

え?「WAS で JNDI なら使ったことあるけど、cell/nodes/・・・なんて書いたことないよ?」ですって?古くから WAS をご利用下さいまして、ありがとうございます。
例えば、WAS V3.x でデータソースの JNDI 名といえば、"jdbc/NantokaDS"みたいな書き方をしていました。
この書き方は V5.x でも使うことができ、JNDI「シンプルネーム」とか「シンプル名」と呼ばれています。「単純名」とはあまり言わないみたいです。
lookup する側のアプリケーションが稼働するプロセス内でのみ有効な名前です。
シンプルネームは WAS V4 以降では推奨されていません。
なぜお勧めできないかは、後でサンプルコードを書いて動かしてみて、明らかにしていきましょう。

JNDI ENC 名

さて、WAS V4 以降では、データソースの lookup を行うのに、

DataSource ds = (DataSource) ictx.lookup("java:comp/env/jdbc/NantokaDS");

のような書き方が推奨されるようになりました。
このように"java:comp/env/"で始まる記述のしかたは、JNDI「ENC (Environment Naming Context:環境ネーミング・コンテキスト) 名」と呼ばれ、lookup する側の Web アプリケーション (*.war) や EJB-JAR (*.jar) 内でのみ有効なネームスペースに定義されます。 なぜ ENC 名が便利なのかについては、これもサンプルを動かしながら考えてみることにしましょう。


データソースを検索してみよう

では、そろそろいつものように、書いて動かしてみましょうか。
J2EE のアプリケーション・サーバーを使っていて、初めて JNDI を使うことといえば、おそらくデータソースの lookup ではないかと思います。
そこで、まずは有効範囲をノード was3 として JDBC プロバイダーを定義し、その JDBC プロバイダーを使用してデータソースを定義します。
そのデータソースを上に挙げた 3 通り、即ち

  • 完全修飾名
  • シンプル名
  • ENC 名

で検索してみましょう。

また、検索の際には、作成したアプリケーションを

  • JDBC プロバイダーの有効範囲内であるノード was3 の server1
  • JDBC プロバイダーの有効範囲外であるノード was2 の server1

にそれぞれインストール、稼働させて、その違いを観察してみましょう。

JDBC プロバイダーとデータソースの作成

では、検索されるデータソースを作成します。
が、まずはその前に、JDBC ドライバーを使用するために DBMS をインストールする必要があります。
使ってみたくなる EJB」の時には Oracle を使用しましたので、今回は DB2 を使ってみようと思います。製品をお持ちの方は CD-ROM から、お持ちでない方はこちらからトライアル版を入手し、インストールして下さい。
例によってダウンロード・サイトは英語で申し訳ないのですが、製品そのものは日本語化されていますのでご安心下さい。
Windows 版の場合、デフォルトのインストール・ディレクトリーは

C:\Program Files\IBM\SQLLIB

となっていますが、私はこれを C:\SQLLIB に変更しています。以後の説明もこの例に従います。他のディレクトリーにインストールした場合や他のプラットフォームの場合は、以後の説明を適切に読み替えて下さい。
今回は DB2 を was3 にのみインストールします。was2 では JDBC ドライバーのファイルだけが必要ですので、was3 の C:\SQLLIB\java 直下のファイル (サブディレクトリーは必要ありません) を was2 の同じディレクトリーにコピーしておきます。
インストールが完了したら、ファースト・ステップか db2sampl コマンドを用いて、サンプル・データベースを作成して下さい (*) 。

(*) サンプル・データベースは今回は使わないと思いますが、次回以降で使うかもしれませんので。

JDBC プロバイダーの設定

では、Web ブラウザーで管理コンソールを起動し、JDBC プロバイダーの作成を行います。
今回は有効範囲をノード was3 に設定します。
有効範囲の設定が済んだら、JDBC プロバイダーを新規作成します。JDBC プロバイダーの種類は DB2 Universal JDBC Driver Provider を選択します。
ここまでの作業は図を参考にして下さい。

図 3. JDBC プロバイダーの有効範囲
図 4. JDBC プロバイダーの選択

JAAS 認証エイリアスの作成

データソースの作成を行う前に、DB のユーザー名とパスワードをセットにした JAAS 認証エイリアスを作成します。
管理コンソール左側のナビゲーション・ツリーを「セキュリティー」 -> 「JAAS 構成」の順に展開し、「J2C 認証データ」を選択します。
「新規作成」ボタンを押して JAAS 認証エイリアスの作成を行い、作業内容を保管します。

データソースの作成

先に作成した JDBC プロバイダーを用いて、データソースを作成します。
JNDI 名は jdbc/sample とします。コンテナー管理パーシスタンスは今回は使用しませんが、連載の後の回で使うかもしれませんのでチェックしておきます。
コンテナー管理認証別名で、先に作成した JAAS 認証エイリアスを選択します。
OK を押し、作業内容を保存します。

テスト用サーブレットの開発

WAS 側の設定が済んだところで、テスト用のサーブレットを開発します。
この節の冒頭にも書きましたが、先に作成したデータソースをこのサーブレットで lookup してみるんでしたね。また、lookup の方法としてはシンプル名、完全修飾名、ENC 名の 3 通りを試してみることにしました。
仕様としては、3 通りのそれぞれで lookup を試み、成功/失敗のそれぞれで Web ブラウザーにメッセージを表示するようにします。
これを実装してみたのがサーブレット DSlookup.java です。WebSphere Studio などでコーディング、コンパイルを行って下さい。

package com.ibm.test.jndi.web;

import java.io.*;

import javax.naming.*;
import javax.servlet.*;
import javax.servlet.http.*;
import javax.sql.*;

public class DSlookup extends HttpServlet {
    DataSource ds = null;

    public void doGet(HttpServletRequest req, HttpServletResponse resp)
        throws ServletException, IOException {
            Context initCtx = null;
            PrintWriter pw = resp.getWriter();

            try {
                initCtx = new InitialContext();
                pw.println("Get initial context: success<br>");
            } catch (NamingException e) {
                e.printStackTrace();
                pw.println("Get initial context: fail<br>");
            }

            try {
                ds = (DataSource) initCtx.lookup("jdbc/sample");
                pw.println("jdbc/sample lookup: success<br>");
            } catch (NamingException e) {
                e.printStackTrace();
                pw.println("jdbc/sample lookup: fail<br>");
            }

            try {
                ds = (DataSource) initCtx.lookup("cell/nodes/was3/servers/server1/jdbc/sample");
                pw.println("cell/nodes/was3/servers/server1/jdbc/sample lookup: success<br>");
            } catch (NamingException e) {
                e.printStackTrace();
                pw.println("cell/nodes/was3/servers/server1/jdbc/sample lookup: fail<br>");
            }

            try {
                ds = (DataSource) initCtx.lookup("java:comp/env/jdbc/sample");
                pw.println("java:comp/env/jdbc/sample lookup: success<br>");
            } catch (NamingException e) {
                e.printStackTrace();
                pw.println("java:comp/env/jdbc/sample lookup: fail<br>");
            }

            pw.close();
    }

    public void init() throws ServletException {
        super.init();
    }
}

私は DSlookupWeb という名前で動的 Web プロジェクトを作成し、パッケージ com.ibm.test.jndi.web 内に DSlookup.java サーブレット (*) を作成しました。以後の説明もこの例に拠ります。
コードの説明は・・・今回は見たまんまですので、必要ありませんよね?
開発が済んだら、DSlookupWeb プロジェクトを、ファイル名を DSlookupWeb.war として war 形式でエクスポートしておきます。

(*) 今回はテストですので InitialContext の取得や lookup 操作を doGet() 内で行っていますが、これは通常のアプリケーションではパフォーマンス悪化の原因となる、よくないコーディングです。
JNDI での lookup は何度行っても (動的にバインディングが変更されない限り) 結果は同じですので、通常は init() 内で行うのが正しいコーディングです。

テスト・アプリケーションの配置

さて、コーディングとアプリケーションのエクスポートが済んだら、さっそく WAS に配置 (デプロイ) しましょう。
管理コンソール左側のナビゲーション・ツリーから「アプリケーション」 -> 「新規アプリケーションのインストール」をクリックします。
「パス」には先ほどエクスポートしておいた DSlookupWeb.war を指定し、「コンテキスト・ルート」には DSlookupWeb と記入して「次へ」をクリックします。
「アプリケーション・セキュリティー警告」が表示されますが、「継続」をクリックして下さい。
「ステップ 1」では「アプリケーション名」が DSlookupWeb_war になっていると思います。DSlookupWeb に修正 ("_war"を削除) して「次へ」をクリックします。
「ステップ 2」ではそのままで「次へ」をクリックします。
「ステップ 3」では、アプリケーションのマップ先となるアプリケーション・サーバーを選択します。まずは先ほどのデータソース定義の有効範囲内であるノード was3 の server1 にマップしてみます。
マップ先が

WebSphere:cell=was3Network, node=was3, server=server1

となっている (データソースを定義したノードにあるアプリケーション・サーバー) ことを確認 (図を参考にして下さい) して「次へ」をクリックします。
マップ先が違っている場合は、修正してから「次へ」をクリックします。

図 5. アプリケーションのマップ先サーバーの指定

「ステップ 4」では「インストール・オプションの要約」の内容を確認して「終了」をクリックします。
作業が完了したら、作業内容をマスター構成に忘れずに保管します。

アプリケーション・サーバーの起動

テスト・アプリケーションの配置が完了したので、配置先のアプリケーション・サーバーを起動します。
管理コンソールのナビゲーション・ツリーで「サーバー」 -> 「アプリケーション・サーバー」を選択し、DSlookupWeb を配置したアプリケーション・サーバー (この例ではノード was3 の server1) を起動します。
正常に起動した旨のメッセージが表示されたら、ナビゲーション・ツリーから「アプリケーション」 -> 「エンタープライズ・アプリケーション」をクリックし、DSlookupWeb アプリケーションが起動していることを確認します。

テスト・アプリケーションの起動

いよいよテスト・アプリケーションの起動です。
Web ブラウザーから http://was3:9080/DSlookupWeb/DSlookup を開きます (*)。
さて、結果は・・・

図 6. リソース参照なしでの DSlookup サーブレットの実行結果

あらら、一つ失敗してますね。
今回のデータソースの lookup は

  • シンプル名:成功
  • 完全修飾名:成功
  • ENC 名:失敗

という結果になりました。

では、なぜこのような結果になったかを考察してみましょう。

(*) ポート 9080 は server1 の HTTP トランスポート用のデフォルトのポート番号です。ポート 9080 で接続に失敗した場合は、アプリケーション・サーバーの HTTP トランスポートのポート番号を調べて (「サーバー」 -> 「アプリケーション・サーバー」 -> <サーバー名> -> 「Web コンテナー」 -> 「HTTP トランスポート」)、9080 の代わりにそのポートに接続してみて下さい。

dumpNameSpace ユーティリティー (*1)

考察を始める前に、「そもそも作成したデータソースは WAS の JNDI ネームスペースのどこにどのようにバインドされているのか」を知りたいですよね。
WAS には JNDI ネームスペースにバインドされたオブジェクト (コンテキストとバインディング) とリンクの一覧を表示するための dumpNameSpace.[bat|sh]コマンドが用意されています。
このコマンドを使用して、ノード was3 の server1 の持つネームサーバーの状況を確認してみましょう。
まずはこのコマンドが接続するネーミングサービス・プロバイダーのポート番号が必要です。
管理コンソールから「サーバー」 -> 「アプリケーション・サーバー」 -> <ノード was3 の server1> -> 「エンドポイント」 -> 「BOOTSTRAP_ADDRESS」の順にたどって、ORB ブートストラップのポート番号を調べます。

図 7. ブートストラップ・ポートの確認方法

ポート番号が分かったら、データソースを定義したノードで (*2)、<WAS_root>\bin\dumpNameSpace.bat を次のようにして起動します。

dumpNameSpace -port <ORB ブートストラップ・ポート番号> | more
図 8. dumpNameSpace ユーティリティーの実行結果

開始コンテキストが (最上位) =was3Network ですので、例えば

(最上位) /nodes

was3Network/nodes

となります。
また、8 番目に (最上位) /cell が was3Network へのリンクであるとありますね。完全修飾名の先頭のセル名は"cell"で置き換えられることを書きましたが、根拠はこれだったんですね。
さて、任意のキーを押して 1 画面ずつ先へスクロールし、データソースを定義した時に JNDI 名として与えた jdbc/sample を探してみましょう。

図 9. 図 8 の続き

図 9 の 33 番目 (皆さまの環境では異なる番号かもしれません) のエントリーに

(最上位) /nodes/was3/servers/server1/jdbc/sample

が見つかりました。
つまり、有効範囲を「(アプリケーション・サーバーを配下に持つ (*3) ) ノード」として作成した JDBC プロバイダーに定義したデータソースのバインディングは、そのノード内のアプリケーション・サーバーを示すコンテキストの直下に作成されることがわかります。
もしノード was3 に別のアプリケーション・サーバーserver2 がある場合、

(最上位) /nodes/was3/servers/server2/jdbc/sample

のバインディングも作成されることになります。

(*1) dumpNameSpace ユーティリティーについて詳しくはこちらを参照して下さい。

(*2) 他のノードで実行する場合は、-host オプションでデータソースを定義したノードを指定します。

(*3) デプロイメント・マネージャーを配下に持つノードでは cell/nodes/<ノード名>/servers/dmgr (または cell/deploymentManager) の直下に作成されます。これらのコンテキストは同じコンテキストにリンクされていますので、どちらの記述を用いても同じ意味です。

DSlookup サーブレットによるテスト結果の考察

以上のことがわかると、DSlookup サーブレットでのテスト結果の理由がわかってきます。
まず、シンプル名 jdbc/sample で lookup した場合についてですが、シンプル名はアプリケーションサーバー・プロセス内で有効です。
そうすると、ノード was3 のサーバーserver1 で実行されるアプリケーションにおいて、シンプル名 jdbc/sample で lookup した場合のフルコンテキストは

cell/nodes/was3/servers/server1/jdbc/sample

となり、先ほど dumpNameSpace ユーティリティーで確認した完全修飾名と一致します。

これが、DSlookup サーブレットにおいて、シンプル名 jdbc/sample での lookup が成功した理由です。 次に、完全修飾名での lookup が成功した理由ですが、これは当たり前ですね。ファイル名で言えばフルパス指定したのと同じですから、探し間違いようがありません。
最後に ENC 名 java:comp/env/jdbc/sample での lookup が失敗した理由について考えてみましょう。
そもそも ENC 名とは何だったかを思い出してみると、lookup する側のアプリケーション内でのみ有効な、ローカルなネームスペースに定義された名前でした。
データソースはアプリケーション内のリソースではありません (*)。そうであれば、ENC 名から、サーバー側のグローバルなネームスペースで定義されたリソースを指す、何らかの参照を持たせる必要があるはずです。
この参照が、J2EE 仕様で「リソース参照 (Resource Reference)」と呼ばれるしくみです。
では、WAS でリソース参照を用いて、ENC 名での lookup を行うにはどうすればよいのでしょうか・・・?

(*) サーバー側で定義するリソースですよね。

リソース参照の定義

リソース参照を定義するには、WAS に添付の AAT (Application Assembly Tool) を使用する方法と、WebSphere Studio の DD (Deployment Descriptor:配置記述子) エディターを使用する方法の 2 通りがあります。今回は後者の方法を紹介します。 Studio 上のプロジェクト・ナビゲーターで DSlookupWeb プロジェクトを展開し、「Web デプロイメント記述子」をダブルクリックします。
DD エディターが開きますので、「参照」タブをクリックし、開いた参照ページで「リソース」タブをクリックします。

図 10. WebSphere Studio DD エディターによるリソース参照の定義
図 11. 型の選択

最後に、「WebSphere バインディング」−「JNDI 名」欄にデータソースの JNDI 名の完全修飾名、即ち

cell/nodes/was3/servers/server1/jdbc/sample

と記入します。
リソース参照の定義は以上で完了です。Ctrl+S を押して作業内容を保存し (*)、DSlookupWeb プロジェクトを再びエクスポートしておきます。

(*) 興味のある方は「ソース」タブをクリックして、定義したリソース参照が web.xml にどのように反映されたか、確認してみて下さい。

リソース参照を定義した DSlookupWeb アプリケーションをデプロイする

では、リソース参照を定義した新しい DSlookupWeb アプリケーションを更新インストールします。
管理コンソールのナビゲーション・ツリーから「アプリケーション」を展開し、「エンタープライズ・アプリケーション」をクリックします。
既にインストールされている DSlookupWeb アプリケーションの左側にチェックを入れ、「更新」ボタンを押します。
次のページ「アプリケーション更新の準備」では、最初にインストールした時と同様に、DSlookupWeb.war のパスを指定し、コンテキスト・ルート DSlookupWeb を記入して「次へ」をクリックします。
次のページではそのままで「次へ」をクリックします。
「アプリケーション・セキュリティー警告」が出ますが、そのまま「継続」を押します。
「新規アプリケーションのインストール」−「ステップ 1」ではそのまま「次へ」を押して「ステップ 2」に移ります。
お? ステップ 2 は見たことがありませんね。Web アプリケーションにリソース参照を定義する前のデプロイ作業では、このような画面は表示されませんでした。

図 12. リソース参照をリソースにマップ

先ほど WebSphere Studio 上の DD エディターで定義した、リソース参照の内容が表示されています。ここで注目していただきたいのは、「JNDI 名」が書き換えられるようになっていることです。

ENC 名+リソース参照を利用することのメリット

lookup メソッドの引数に完全修飾名を直接記述すれば、リソース参照も不要で、目的のリソースを一発で指し示すことができ、一見すると便利な気がします。
ところが、アプリケーション開発時点 (コンパイル時点) で使用するリソースの JNDI 完全修飾名がわかっていなければならず、リソースの JNDI 名が変更になった場合はコードを書き換えて再コンパイルが必要になってしまいます。これでは使いづらいパッケージになってしまいますね。
完全修飾名はセルのトポロジーに依存しますし、また"was3"や"server1"のようにノード名やサーバー名に依存するコンテキスト名が含まれます。完全修飾名はアプリケーションを開発する時点で正確にわかっているとは限らないわけです。
一方、ENC 名とリソース参照を用いることにより、DD エディター上でリソース参照の作成さえしておけば、ENC 名からグローバル名への実際のマッピングは、アプリケーションのデプロイ時点で最終的に決定し、設定すればよいことになります。
これが、ENC 名とリソース参照を利用することのメリットです。

デプロイを完了して再びテストしてみる

ともあれ、今回は Studio 上の DD エディターでマッピングを記述してありますので、そのまま「次へ」をクリックします。
「ステップ 3」以降では変更すべき設定項目はありません。ステップ 5 で「終了」をクリックし、作業内容をマスター構成に保管します。
さて、今度はすべての lookup が成功するはずです。Web ブラウザーからもう一度、http://was3:9080/DSlookupWeb/DSlookup を開きます。

図 13. リソース参照定義後の DSlookup サーブレット実行結果

おおおおっ!今度は ENC 名での lookup も成功していますね!


さて、次回は・・・?

えーと、すみません。冒頭で「やる」と書きました、

作成したアプリケーションを
  • JDBC プロバイダーの有効範囲内であるノード was3 の server1
  • JDBC プロバイダーの有効範囲外であるノード was2 の server1
にそれぞれインストール、稼働させて、その違いを観察してみましょう。

の後者がまだ終わっていません。
が、連載一回分の量としてはちょっと多くなってしまいましたので、今回はここまでにしたいと思います。
今回試してみた前者のテストでは、完全修飾名での lookup が推奨されない理由と、ENC 名+リソース参照を利用することのメリットがわかりました。
JDBC プロバイダーの有効範囲外からの lookup は、次回のお楽しみにしたいと思います。
あとは・・・、EJB 参照やリソース環境参照の話題もありますし、第 1 回でちょっと触れた IIOP と絡めた話もありますし、JNDI って実は奥が深いですね・・・。
とりあえず、第 3 回はそんなところを考えています。全部いっぺんには書けませんけどね。なかなか息の長い連載になるかもしれません・・・。
話は逸れますが、連載第 1 回の読者の皆さまからのフィードバック (記事ページの一番下のフォームから送信できます) をたくさんいただきました。ありがとうございます。
正直なところ、連載開始前は「確かに JNDI って『今さら』だよなぁ。誰か読んでくれる人いるのかなぁ・・・。」と思っていましたので、大喜びしています。
しかも、「先週の人気記事 TOP5 」にも堂々のランクインですよ、本当にびっくりです。
では、次回もどうぞお楽しみに!

参考文献

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=WebSphere
ArticleID=329123
ArticleTitle=今さら人に訊けない JNDI: 第 2 回 「リソース参照って何ですか?」
publish-date=09082004