JNDI(Java Naming and Directory Interface)

JNDI（Java Naming and Directory Interface）（※下書き中です）

JNDIとは、Javaにおけるネーミングサービス（名前付け）とディレクトリサービス（検索）を扱うためのインタフェースを規定したもの。

どこぞかしこでネーミングネーミングと言うので、ネーミング＝検索機能のようなイメージが植付けられてしまっていたけど、よくよく考えたらnaming＝名前付けだよなぁ。
それは置いといて、

JNDIの構成は、API(Application Programming Interface)とSPI(Service Provider Interface)から成る。

APIはアプリケーション実装者が使うインタフェース。
SPIはサービス提供者が使うインタフェース。
両者の間にはフレームワークなりアダプタなりが仲介する。

APIとSPIって語呂が似てるけど、
ProgrammingとProviderのところが違うよね。
どうせなら、Programmingに合わせてProvidingにするとか、ProgrammerとProviderにするとか。


回りくどい話はいいとして、本題に入る。

JNDIはオブジェクトと名前を紐付けて管理したり、名前からオブジェクトを検索できたりする。
例えばデータベースは、製品ごとにJDBCドライバが用意されている。
OracleとDB2では、それぞれ用意されているJDBCドライバが異なるので、ドライバのクラス名も当然異なってくる。

こんな感じ
　Class.forName("org.gjt.mm.mysql.Driver")

そうなると、Oracle用のソースコードと、DB2用のソースコードを用意しなければならなくなる。
じゃあクラス名だけ外部ファイルに定義しておけばいいじゃないか、って話になる。
でも、2つのドライバを同時にロードしたいときは？ってなるとそれぞれコードを書かなきゃいけなかったり、いろいろと面倒。いろいろ、のところは各自の経験からあれこれと想像頂きたい。

そこで、JNDIの出番ですよ。ドライバクラスを直接ロードするのではなく、DataSourceを取得する方法をとる。
どういうことかというと、JNDIを使って予めドライバクラスをJNDIネームスペース（※）に登録しておく。
（※名前付けしたオブジェクトを保管しておく領域をJNDIネームスペースという）
で、検索キー（名前）を使ってJNDIネームスペースを検索して、ドライバを取得する。
そうするとDataSourceというオブジェクトが取得できるから、これを使ってさらにConnectionが取得できたりする。
他にもJMSとかいろいろ。

あー、書いてるのめんどくさくなった。とっとと次いこう。

JNDIの使い方よくわからん。おまえ何ぞや。と、思ったわけです。
でも、おかげで、RMIで使ってたrmiregistryは何故立ち上げておく必要があるのか、ようやく理解しました。

JNDIはAPIとSPIからなるものです。そんだけです。だからJNDIを具現化して、JNDIが規定した機能を提供する人が必要です。その人は、アプリケーションサーバだったり、rmiregistryだったり、あるいはファイルシステムだったりします。


基本的な使い方は以下のとおり。

InitialContext context = new InitialContext();
Hoge hoge = (Hoge)context.lookup("ルックアップ名");

まずコンテキストを生成して、そのコンテキストを通して、ルックアップ（検索）を行う。
lookupの引数には、登録したオブジェクトに紐づく名前を指定する。
Hogeは予め登録しておいたオブジェクト。
これで欲しいオブジェクトのインスタンスが取得できた。

基本のスタイルはこれだけ。
でも、これがきっちり出来るようになるためには、JNDIの仕組みをしっかり理解しておかないといけない。
なぜなら、実際は各製品ごとにJNDIの設定を行う事になるから。そして製品ごとに設定の仕方が異なる。



ルックアップ名の定義場所

１．コンテナの配下で動くアプリケーション：web.xml
２．スタンドアローンで動くアプリケーション：application-client.xml

１．はサーブレットやWebアプリケーションやエンタープライズアプリケーション等でJNDIを使いたいときに使う。通常はこちらの方法をとる。
２．は、単独で稼動するアプリケーション（要はmainメソッドがあるようなやつ）がJNDIを使いたいときに使う。ただし、こちらの方法はあまりお勧めはしない。何故なら、ルックアップ名に紐づく定義が変更されると、クライアントアプリケーションの設定（application-client.xml)を変更しなければならないからだ。
つまり、サーバとクライアントが1:Nの関係になっているとして、1箇所直すのか、複数個所直すのか、という運用の話。

そうはいっても、２．を使わなきゃいけないときもある。
何故なら、JMSやらJDBCやらのクライアントアプリケーションが、常にアプリケーションサーバなどのコンテナ上で稼動しているとは限らないからだ。


JNDIの利用シーンとして、JDBCとJMSを使用するときにJNDIを利用するとどうなるか、サンプルコードを示す。

あと、LDAPとか、ファイルシステムとか、java:comp/envとかiiopとかrmi:とかなんとかかんとか。
あ、あとEJBも！

まとまらないので、一時中断。