目次 | 前へ | 次へ

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 アプリケーションやサービスのプログラマが独自の名前空間とディレクトリオブジェクトを統一された方法でエクスポートできるという理由からも重要です。

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

 

2.5 主要な業界標準のサポート

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

目次 | 前へ | 次へ


Copyright © 1993, 2013, Oracle and/or its affiliates. All rights reserved.