データソースにJNDIを使用する理由
データベース/ JMSなどのサービスを公開するためにJNDIが好ましい方法である理由を説明できる人はいますか？
私が出くわしたすべての投稿は、特定のドライバーマネージャーを読み込む必要がない、接続プーリングなどのメリットがあるが、プロパティファイルでドライバーマネージャーを指定してリフレクションを使用することで簡単に達成できる利点について説明しています。
接続プーリングは、適切な実装をスプリングなどを介してアプリケーションBeanに配線することでも実現できます。
では、なぜJNDIを使用したほうが良いのでしょうか？
開発から統合、テストから実稼働まで、環境間でアプリケーションを移動する必要がある場合、JNDIは非常に優れています。同じJNDI名を使用するように各アプリサーバーを構成すると、各環境で異なるデータベースを使用でき、コードを変更する必要がありません。 WARファイルを選択して、新しい環境にドロップするだけです。
この答えを判断する際に知っておくべき重要な他の仮定を以下に示します。
- ログへの読み取り専用アクセスを除き、コードがデプロイされているサーバーにはまったくアクセスできません。
- コードを記述してパッケージ化する人は、サーバーを構成および管理する人とは異なります。
- PRODへの旅でWARファイルが開始されると、最初に戻らずに再度変更することはできません。 WARが変更された場合、テストサーバーでQAが行ったテストはすべてやり直す必要があります。
おそらく、ローカルデスクトップでコードを作成し、実稼働環境に直接展開する開発者は1人であるため、このメリットはありません。
「優先」メカニズムは、管理および構成を行う人が優先するメカニズムだと思います。 duffymoが指摘したように、構成が展開可能なアーティファクトの外部にあることが重要ですが、それ以外の場合は何でもいいと思います。システム管理者がGUIを使用してJDNIエントリを設定することを好む場合は、クールです。彼/彼女がcsshとviでプロパティファイルを編集することを好むなら、クールです。アプリの開発と設定/デプロイの両方を担当している場合、それはほとんどあなたの呼び出しです。個人的には、アーティファクト内に可能な限り多くの実装を保持するのが好きです。つまり、データソースとドライバーもそこに存在します。
代替案に対するJNDIの技術的な利点について質問している場合、それがあるかどうかはわかりませんが、質問を明確にすることをお勧めします。
他の人が述べたように、JNDIの大部分はサービスの場所の検索に使用されますが、主にDBのようなリソースに使用されます。
最も厄介なのは、JavaのLDAP APIがJNDI APIでもあることです。 LDAPを使用する場合、抽象化は非常に複雑です。 JNDIには、単一障害点になる場合があるという欠点もあります。
ホスト名のエイリアスを使用すると、JNDIのほとんどの機能を簡単に実現できます。それは、MYRESOURCEが127.0.0.1内の/etc/hosts（またはenvの場所）を指すエイリアスを作成することです。次に、アプリケーションの構成で、ホスト名としてMYRESOURCEを使用します（たとえば、jdbc URLで）。
次に、アプリケーションを実稼働環境に移動するときに、実稼働環境の/etc/hostsファイルを変更して、MYRESOURCEが実稼働リソース/サービス（prodデータベースサーバーなど）を指すようにします。
上記は、他の言語（Ruby、python）で動作する、よりポータブルで小さなフットプリントの命名ディレクトリです。また、REST services。のようなJNDIでは通常行われないことでも動作します。唯一の迷惑なことは、サーバーホストファイルを更新する必要があることですが、これはSSHスクリプトで自動化できます。
プロパティファイルに対するJNDIの本当の利点は、クラスター環境にデプロイするときに得られます。プロパティファイルを使用すると、サーバーインスタンスの一部が異なる値を持つ可能性が残ります。 JNDIを使用すると、同じ値がドメインコントローラーによってすべてのクラスター化されたサーバーにプッシュされ、同じプロパティファイルをすべてのサーバーにコピーする必要がなくなります（おそらくサーバー/アプリを再起動します）。
JNDIが役立つ別の領域：
It abstractsリソースの検索。通常、JNDI設定はアプリケーションサーバー上のXMLファイルに保存されますが、保存する必要はありません。たとえば、構成をLDAPサーバーに保存して、集中管理を容易にすることができます。
実行するアプリケーションがJNDIを使用して必要なものを検索する場合、構成ファイルからLDAPサーバーの使用に切り替えることができますアプリケーションを変更せずに。各アプリケーションが、ハードコーディングされた名前のプロパティファイルを期待している場合、あなたは運が悪いです。本番環境で多数のアプリケーションを使用している企業を想像してください。すべてを変更することは重大な問題です。
つまり、JNDIは主に次のような複雑な展開シナリオに適しています。
- 多くのアプリケーションサーバー（クラスター化されている可能性があります）
- 多くの異なるアプリケーション
- 集中構成
- さまざまなサーバーステージ（テスト、実稼働）
そのため、最初は過剰に見えるかもしれませんが、これらのシナリオでは非常に便利です。もちろん、DB接続の標準化された構成など、小規模な展開にもいくつかの利点が適用されます。