目次 | 前の項目 | 次の項目 JNDI API


2. 目標と設計方針

API の設計は、次の原則および方針に従って行いました。

2.1 一貫性のあるわかりやすい設計を行う

可能な場合は常に、Java 開発環境のほかの部分で使用されている、既存のコンポーネントを使用しています。この原則に従うことにより、JNDI と Java プラットフォームの既存のコアクラスとの間の一貫性が維持されるだけでなく、クラスの無駄な増加を抑えられます。

Java プログラミング言語はオブジェクト指向言語であるため、単純でわかりやすい API を設計できます。 このため、ディレクトリサービス機能は、基本的なネームサービス機能から無理なく拡張することができます。

2.2 使用する機能だけに集中する

API は階層構造になっているので、アプリケーションを作成するときに、特定のディレクトリサービス機能だけを使用する場合は、高度な機能についての知識は必要ありません。高度な機能は上位の階層に配置することによって、下位の階層は単純になっており、共通の機能を表すようになっています。

2.3 一般的なディレクトリサービス、ネームサービス、およびプロトコルにまたがって実装できる

この方針は、次の 2 つの点で重要です。1 つ目は、Java アプリケーションから、DNS、NDS、NIS (YP)、X.500、LDAP などの既存のさまざまなネームサービスおよびディレクトリサービスの情報を利用できることです。2 つ目は、任意の実装固有の機能だけを API に持たせることができることです。

複数のネームサービスおよびディレクトリサービスに対して統一されたインタフェースが提供されていますが、特定のサービス固有の機能にアクセスすることもできます。統合された API は、一般的なサービスを使用するように設計されていますが、配下のネームサービスまたはディレクトリサービスの明示的な情報を使用しているアプリケーションも使用できます。この場合、API が使用されている共通部分を共有することもできます。これは、共通して使用されるクラスを共有しながら、必要な独自の機能をサブクラス化によって追加しているアプリケーションの場合と類似しています。

2.4 シームレスな統合

シームレスな統合は、重要な方針です。 シームレスな統合によって、インストール済みのマシンの中で使用されているさまざまなディレクトリサービスおよびネームサービスをサポートできるだけでなく、新しい Java アプリケーションおよびサービスを開発するときに、統一した方式で独自の名前空間およびディレクトリオブジェクトをエクスポートすることができます。

また、アプリケーションからさまざまな実装を選択できるようにし、使用する実装を固定させないようにしました。たとえば、thin クライアントの場合は、特定のネームサービスおよびディレクトリサービスへのアクセスを 1 台のサーバに委託した、プロキシ型のプロトコルが適しています。パフォーマンスが重要でリソースが豊富なクライアントの場合は、さまざまなサーバに直接アクセスする実装が適しています。しかし、アプリケーションでは、これらの実装は選択しません。実装は実行時に選択します。

 

2.5 業界をリードする標準をサポートする

Lightweight Directory Access Protocol (インターネット RFC 2251) が、プロトコルレベルのディレクトリアクセスの標準として普及しつつあります。主要なディレクトリベンダーの製品では、すべてこのプロトコルがサポートされています。JNDI を使用しているアプリケーションでは、Lightweight Directory Access Protocol のすべての機能にアクセスできなければなりません。可能な場合 JNDI は、Lightweight Directory Access Protocol に定義済みの規約 (検索クエリーおよびフィルタの仕様など) もサポートしてください。


目次 | 前の項目 | 次の項目
Copyright ©1997-1999 Sun Microsystems, Inc. All Rights Reserved.