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


5. インタフェースの概要

JNDI API は、4 つのパッケージに組み込まれています。

JNDI サービスプロバイダインタフェースが組み込まれているパッケージは 1 つだけです。

以降の節では、JNDI API の概要について説明します。API についての詳細は、対応する javadoc ドキュメントを参照してください。

5.1 ネーミングパッケージ -- javax.naming 1

(例外クラスは示していません)

5.1.1 コンテキスト

Context は、ネーミングコンテキストを指定するコアインタフェースです。名前とオブジェクトのバインディングの追加、特定の名前にバインドされたオブジェクトのルックアップ、バインディングの一覧表示、名前とオブジェクトのバインディングの削除、同じ型のサブコンテキストの作成と破棄など、基本操作を定義します。

public interface Context {
    public Object lookup(Name name) throws NamingException;
    public void bind(Name name, Object obj) throws NamingException;
    public void rebind(Name name, Object obj) throws NamingException;
    public void unbind(Name name) throws NamingException;
    public void rename(Name old, Name new) throws NamingException;
    public NamingEnumeration listBindings(Name name) throws NamingException;
    ...
    public Context createSubcontext(Name name) throws NamingException;
    public void destroySubcontext(Name name) throws NamingException;
    ...
};

Context 内のすべてのネーミングメソッドには、名前を引数として指定します。その名前が暗黙的に解決されると、Context オブジェクトが取り出されます。 メソッドに定義した操作は、その Context オブジェクトで実行されます。名前が空 ("") の場合は、そのコンテキストで直接実行されます。オブジェクトの名前を複合名にして、オブジェクトの参照で使用される名前空間の配置を反映することができます。クライアントは、ネームサービスの実装には公開されません。また、新しい型のネームサービスを導入するときに、アプリケーションを変更したり、実行中のアプリケーションを中断する必要はありません。

 

5.1.2 初期コンテキスト

JNDI で使用される名前は、すべてコンテキストに対する相対名です。「絶対名」という概念はありません。アプリケーションは、InitialContext クラスの最初のコンテキストを取得したときにブートストラップします。

public class InitialContext implements Context {
    public InitialContext()...;
    ...
}

初期コンテキストには、いくつかのネーミングシステムで使用されている共用コンテキストに、クライアントを接続するためのさまざまなバインディングが含まれています。 たとえば、URL の名前空間、DNS のルートなどが含まれます。

 

5.1.3 名前

Name インタフェースは、汎用名を表現します。 汎用名とは、順番に並べられたコンポーネントのシーケンスのことです。Name 引数を指定する各 Context メソッドには、String としてその名前を受け取るメソッドが存在します。Name を指定するメソッドは、名前の合成、コンポーネントの比較など、名前を操作するアプリケーションで有用です。String を指定するメソッドは、名前の読み込み、対応するオブジェクトのルックアップなど、単純な処理を行うアプリケーションでより有用です。String 型の名前パラメータには、複合名を使用します。Name パラメータでも、複合名を使用できます。

CompositeName クラスは、複数の名前空間の名前 (基本名または複合名) のシーケンスを表現します。Context クラスのメソッドに渡される Name パラメータが CompositeName のインスタンスの場合は、その名前は複合名です。

Context クラスのメソッドに渡された Name パラメータが CompositeName のインスタンスでない場合は、その名前は複合名で、CompoundName クラスまたはその他の実装クラスで構成されています。CompoundName クラスは、1 つの名前空間の階層名です。コンテキストの名前パーサは、特定のコンテキストに関連付けられた構文に基づいて、複合名を操作するときに使用します。

public interface Context {
    ...
    public NameParser getNameParser(Name name) throws NamingException;
    ...
}

このコンテキストの構文に基づいて名前を操作するアプリケーションの例として、名前空間のブラウザがあります。その他のほとんどのアプリケーションでは、文字列または複合名が使用されます。

 

5.1.4 バインディング

Context.lookup() は、使用頻度がもっとも高い操作です。このコンテキストの実装は、Java アプリケーションに必要なクラスのオブジェクトを返すことができます。たとえば、クライアントからプリンタの名前を使用して、対応する Printer オブジェクトをルックアップし、直接そのプリンタに印刷するには、次のようにします。

Printer printer = (Printer) ctx.lookup("treekiller");
printer.print(report);

Context.listBindings() は、名前とオブジェクトのバインディングの列挙を返します。 各バインディングは、Binding クラスのオブジェクトを使用して表現します。バインディングは、バインドされたオブジェクトの名前、オブジェクトのクラスの名前、およびオブジェクト自体で構成されます。

Context.list() メソッドは、listBindings() に類似していますが、NameClassPair オブジェクトの列挙を返す点が異なります。NameClassPair には、オブジェクトの名前およびそのオブジェクトのクラスの名前が含まれています。list() メソッドは、コンテキスト内でバインドされているオブジェクトの情報を検索するアプリケーション (ブラウザなどの) で使用します。 ただし、この場合、実オブジェクトのすべてが処理されるわけではありません。listBindings() を使用すると、すべての情報が返されますが、かなり時間がかかります。

public class NameClassPair ... {
    public String getName() ...;
    public String getClassName() ...;
    ...
}
public class Binding extends NameClassPair {
    public Object getObject() ...;
    ...
}

5.1.5 参照

Context の実装ごとに、異なる種類のオブジェクトをネイティブにバインドすることができます。Reference クラスは、使用頻度の高いオブジェクトで、汎用的に使用されるコンテキスト実装ではすべてサポートする必要があります。ディレクトリの外部のオブジェクトは、参照によって表現されます。参照を使用すれば、JNDI クライアントから、X.500 などのネームサービスまたはディレクトリサービスに対して、事実上任意のクラスのオブジェクトをバインドすることができます。 Java プログラミング言語で作成されたオブジェクトが、そのサービスでネイティブにサポートされている必要はありません。

Context.lookup()Binding.getObject() などの操作から Reference オブジェクトが返された場合は、JNDI では、参照が表現しているオブジェクトに変換してから、クライアントに返します。特に、特定のネーミングシステムの Context を表現する参照が、別のネーミングシステム内の名前にバインドされているときに、この処理が発生します。参照によって、複数の互いに依存しないネームサービスが結合され、JNDI の複合名前空間が構築されます。この機構についての詳細は、JNDI SPI のドキュメントを参照してください。

オブジェクトを参照によって表現するには、Referenceable インタフェースが実装されていなければなりません。このクラスの getReference() メソッドによって、オブジェクトの参照が返されます。このオブジェクトが任意のコンテキストの名前にバインドされているときに、そのオブジェクトをネイティブに格納できない場合は、コンテキスト実装ではその参照を配下のシステムに格納します。

各参照には、参照が表現するオブジェクトのクラスの名前、およびオブジェクトのクラスファイルの位置 (通常は URL) が含まれています。また、RefAddr クラスのオブジェクトのシーケンスが含まれています。各 RefAddr には、「型」の文字列、およびアドレス指定データが含まれています。 アドレス指定データは通常、文字列またはバイト配列です。

LinkRef クラスと呼ばれる特別な Reference クラスは、「シンボリック」リンクを JNDI 名前空間に追加するときに使用します。このクラスには、JNDI オブジェクトの名前が含まれています。シンボリックリンクは、デフォルトでは、JNDI の名前が解決されたときに評価されます。

 

5.1.6 照会

一部のネームサービスおよびディレクトリサービスでは、「照会 (referral)」という概念がサポートされており、クライアントの要求をほかのサーバにリダイレクトすることができます。JNDI クライアントでは、その照会の自動的な追跡、無視、または手動処理を要求できます。

abstract クラス ReferralException を使用して、照会を表現します。

public abstract class ReferralException extends NamingException {
    public abstract Context getReferralContext() throws NamingException;
    ...
    public abstract Object getReferralInfo();
    public abstract void retryReferral();
    public abstract boolean skipReferral();
}

照会が検出された場合、照会を無視しないで自動的に評価するようにクライアントが要求しているときは、ReferralException がスローされます。getReferralInfo() メソッドを使用すると、照会のリダイレクト先の情報がサービスプロバイダに適した形式で返されます。アプリケーションでは、この情報を検査する必要はありませんが、照会に従うかどうかをユーザが決定できるように、その情報を提示することはできます。skipReferral() メソッドを使用すると、アプリケーションでは、照会が破棄され、存在する場合は次の照会が処理されます。

アプリケーションで操作を継続する場合は、元のメソッドに渡された引数を使用して、照会コンテキストでメソッドを再度呼び出します。

 

5.2 ディレクトリパッケージ -- javax.naming.directory 2

 

(例外クラスは示していません)

5.2.1 ディレクトリオブジェクト

DirContext インタフェースを使用して、ディレクトリオブジェクトに関連付けられた属性の検査および更新を行うメソッドを定義すると、ディレクトリの機能を有効にできます。

public interface DirContext extends Context {
    public Attributes getAttributes(Name name)
		 throws NamingException;
    public Attributes getAttributes(Name name, String[] attrIds)
		 throws NamingException;
    ...
    public void modifyAttributes(Name name, int modOp, Attributes attrs)
		 throws NamingException;
    public void modifyAttributes(Name name, ModificationItem[] mods)
		 throws NamingException;
    ...
}

ディレクトリに対して getAttributes() 操作を実行すると、属性の一部またはすべてが返されます。属性が変更するには、2 つの形式の modifyAttributes() を使用します。どちらの形式の場合も、次のいずれかの「変更操作」が使用されます。

ADD_ATTRIBUTE
REPLACE_ATTRIBUTE
REMOVE_ATTRIBUTE

ADD_ATTRIBUTE 操作では、属性がすでに存在している場合は、値が追加されます。 REPLACE_ATTRIBUTE 操作では、任意の既存の値が破棄されます。最初の形式の modifyAttributes() では、属性セットの各要素に対して特定の操作が実行されます。2 番目の形式の modifyAttributes() では、ModificationItem クラスのオブジェクトの配列を受け取ります。

public class ModificationItem {
    public ModificationItem(int modOp, Attribute attr) ...;
    ...
}

各操作は、対応する属性に対して、指定された順序で実行されます。可能な場合は、コンテキスト実装では、modifyAttributes() の各呼び出しは、不可分な操作として実行してください。

5.2.2 属性

ディレクトリオブジェクトには、0 個以上の Attribute オブジェクトが含まれています。各属性は、文字列の識別子で識別されます。 また、任意の型の値を 0 個以上指定できます。

public interface Attribute ... {
    ...
    public String getID();
    public Object get(int n) throws NamingException;
    public boolean isOrdered();
    public NamingEnumeration getAll()
           throws NamingException;
    ...
}

属性の値を順序付けるかどうかは、任意に指定できます。値を順序付けていない場合は、重複は許可されません。値を順序付けた場合は、重複が許可されます。

属性をコレクションにグループ化するときは、Attributes インタフェースを使用します。

public interface Attributes ... {
    ...
    public Attribute get(String attrID);
    public NamingEnumeration getIDs();
    public NamingEnumeration getAll();
    public Attribute put(Attribute attr);
    public Attribute remove(String attrID);
    ...
}

JNDI では、BasicAttribute および BasicAttributes という 2 つのインタフェースの実装が提供されます。サービスプロバイダおよびアプリケーションでは、独自の実装を使用できます。

属性またはその値の追加または削除など、Attributes および Attribute を更新しても、ディレクトリの属性またはその値は変更されません。ディレクトリへの変更は、DirContext.modifyAttributes() を使用しない限り、有効にはなりません。

 

5.2.3 ネーミングコンテキストとしてのディレクトリオブジェクト

DirContext インタフェースが Context インタフェースを継承した場合は、ネーミングコンテキストとして動作します。つまり、任意のディレクトリオブジェクトからネーミングコンテキストを提供できます。さまざまなユーザ情報を保持しているディレクトリオブジェクトは、プリンタ、ファイルシステム、カレンダなど、個人にかかわるリソースの本来のネーミングコンテキストにもなります。

ハイブリッド操作では、1 つの不可分操作内で、特定のネーミング操作およびディレクトリ操作が実行されます。

public interface DirContext extends Context {
    ...
    public void bind(Name name, Object obj, Attributes attrs)
           throws NamingException;
    ...
}

rebind() および createSubcontext() もハイブリッド操作として使用できます。 これらのメソッドには、Attributes 引数を追加することができます。

5.2.4 初期コンテキスト

ディレクトリ操作を実行しているアプリケーションで初期コンテキストを作成するときは、javax.naming.InitialContext 以外に InitialDirContext を使用することもできます。

public class InitialDirContext 
       extends InitialContext implements DirContext {
    public InitialDirContext() ...;
    ...
}

この場合、初期コンテキスト上で、Context または DirContext インタフェースの任意のメソッドを呼び出すことができます。

5.2.5 検索

DirContext インタフェースでは、コンテンツベースのディレクトリ検索がサポートされています。もっとも単純で使用頻度の高い使用法は、アプリケーションで照合のための属性セットを指定する方法です。 多くの場合、属性には特定の値を指定します。この場合、DirContext.search() メソッドがそのディレクトリオブジェクト上で呼び出され、一致したディレクトリオブジェクトと要求した属性が返されます。

public interface DirContext extends Context {
    ...
    public NamingEnumeration search(Name name, Attributes matchingAttributes)
		 throws NamingException;
    public NamingEnumeration search(Name name,
                                    Attributes matchingAttributes,
                                    String[] attributesToReturn)
		 throws NamingException;
    ...
}

検索結果は、SearchResult クラスのオブジェクトの列挙を含む NamingEnumeration として返されます。

public class SearchResult extends Binding {
    ...
    public Attributes getAttributes() ...;
}

より詳細に検索する方法として、検索フィルタを指定したり、検索の範囲、結果の最大サイズなどの制御情報を指定する方法があります。検索フィルタには、LDAP について規定されている Internet RFC 2254 に準拠した構文を指定します。SearchControls 引数には、検索範囲などを指定します。検索範囲には、ディレクトリ階層内の単一ディレクトリオブジェクト、すべての子、またはすべての子孫を含めることができます。

public interface DirContext extends Context {
    ...
    public NamingEnumeration search(Name name, 
                                    String filter,
                                    SearchControls ctls)
           throws NamingException;
 
    public NamingEnumeration search(Name name,
                                    String filter,
                                    Object[] filterArgs,
                                    SearchControls ctls)
 		throws NamingException;
   	...
}

5.2.6 スキーマ

スキーマには、名前空間の構造および名前空間に格納されている属性を定義するための規則を作成します。スキーマは、名前空間全体に対して単一のスキーマを作成することもできますが、属性ごとに詳細に作成することもできます。

スキーマは情報のツリーとして表現できます。 このため、JNDI ですでに定義されているネーミングインタフェースおよびディレクトリインタフェースは、簡単にツリーで表現できます。名前空間のスキーマからアプリケーションに対して統一した方法でアクセスできる、強力な機能です。たとえば、ブラウザからスキーマツリーの情報にアクセスするときは、ディレクトリオブジェクトにアクセスするときと同じ方法で行うことができます。

アプリケーションでは、配下のコンテキスト実装に適切なサポートが提供されている場合は、ディレクトリオブジェクトに関連付けられたスキーマを取得することができます。

ディレクトリオブジェクトに関連付けられたスキーマツリーのルートを取得するときは、DirContext.getSchema() を使用します。ルートの下位には、「ClassDefinition」、「AttributeDefinition」、「SyntaxDefinition」などの子が存在し、さまざまな種類の定義が記述されています。スキーマのルートおよびその子孫は、DirContext 型のオブジェクトです。DirContext.getSchemaClassDefinition() メソッドを使用すると、特定のディレクトリオブジェクトのクラス記述が含まれる DirContext が返されます。

public interface DirContext extends Context {
	...
	public DirContext getSchema(Name name)
		throws NamingException;

	public DirContext getSchemaClassDefinition(Name name)
		throws NamingException;
	...
}

属性に関連付けられているスキーマには、Attribute.getAttributeDefinition() および getAttributeSyntaxDefinition() メソッドを使用してアクセスできます。

public interface Attribute ... {
    ...
    public DirContext getAttributeDefinition() throws NamingException;
    public DirContext getAttributeSyntaxDefinition() 
    throws NamingException;
    ...
}

ディレクトリのスキーマへのマッピングの例は、スキーマ情報にアクセスするための個々の関連性について示しています。

ディレクトリのスキーマへのマッピングの例

 

5.3 イベントパッケージ -- javax.naming.event 3

javax.naming.event パッケージには、ネームサービスおよびディレクトリサービスでイベント通知をサポートするためのクラスおよびインタフェースが含まれています。

 

5.3.1 ネーミングイベント

NamingEvent は、ネームサービスまたはディレクトリサービスによって生成されるイベントを表現します。

public class NamingEvent extends java.util.EventObject {
    ...
    public int getType();
    public Binding getOldBinding();
    public Binding getNewBinding();
    ...
}

イベントの型によって、イベントの種類を識別できます。NamingEvent クラスには、次の 4 つの種類のイベントが定義されています。

  1. OBJECT_ADDED
  2. OBJECT_REMOVED
  3. OBJECT_RENAMED
  4. OBJECT_CHANGED

これらの種類は、次の 2 つのカテゴリに分類できます。

NamingEvent には、イベントの種類以外に、変更前後のオブジェクトの情報など、変更に関するその他の情報も含まれています。

 

5.3.2 ネーミングリスナー

「ネーミングリスナー」は、NamingEvent に登録されるオブジェクトです。このオブジェクトは、NamingListener インタフェースによって表現されます。NamingEvent の各カテゴリは、対応する NamingListener のサブタイプによって処理されます。NamespaceChangeListener インタフェースは、名前空間の変更によって影響されるリスナーを表現します。 ObjectChangeListener インタフェースは、オブジェクトの内容の変更によって影響されるリスナーを表現します。リスナーの実装には、関連するイベントの種類に応じて、これらのインタフェースのどちらかまたは両方が実装されます。

 

5.3.3 イベントの登録と登録解除

EventContext および EventDirContext インタフェースは、それぞれ Context および DirContext インタフェースから継承されており、イベントの登録および登録解除を行います。

public interface EventContext extends Context {
    ...
    public void addNamingListener(Name target,
                                  int scope,
                                  NamingListener l)
           throws NamingException;
    public void removeNamingListener(NamingListener l)
           throws NamingException;
    public boolean targetMustExist()
           throws NamingException;
}

addNamingListener() には、対応する Context インタフェースのメソッドと同様に、String 型の名前引数を受け取るオーバーロードがあります。名前パラメータは、「ターゲット」として参照されます。スコープパラメータには、ターゲットのオブジェクトに登録するか、ターゲットのコンテキストの直下の子に登録するか、ターゲットのオブジェクトをルートとするサブツリー全体に登録するかを指定します。

存在しないターゲットに対象を登録することもできますが、サービスプロバイダおよび配下のプロトコルまたはサービスのサポート範囲に制限されます。アプリケーションでは、targetMustExist() メソッドを使用して、存在しないターゲットの登録が EventContext でサポートされているかどうかを検査することができます。

public interface EventDirContext extends EventContext, DirContext {
    public void addNamingListener(Name target,
                                  String filter, 
                                  SearchControls ctls, 
                                  NamingListener l)
                throws NamingException;
    public void addNamingListener(Name target,
                                  String filter,
                                  Object[] filterArgs,
                                  SearchControls ctls,
                                  NamingListener l)
                throws NamingException;
    ...
}

EventDirContext インタフェースは、EventContext および DirContext インタフェースの拡張です。 リスナーは、検索フィルタ (Internet RFC 2254) で識別されるオブジェクトに対象を登録できます。

addNamingListener() メソッドには、対応する DirContext インタフェースのメソッドと同様に、String 型の名前の引数を受け取るオーバーロードがあります。

EventContext または EventDirContext インスタンスは、内部で addNamingListener() メソッドを呼び出しており、生成される (可能性のある) イベントの「イベントソース」になります。登録されたリスナーから getSource() または getEventContext()NamingEvent 上で呼び出された場合は、EventContext または EventDirContext インスタンスが返されます。

たとえば、リスナーが次の登録を行います。

NamespaceChangeListener listener = ...;
src.addNamingListener("x", SUBTREE_SCOPE, listener);

次に、「x/y」という名前のオブジェクトが削除されると、listener には対応する NamingEvent (evt) が配布されます。 この NamingEvent には、イベントソースとして src が含まれていなければなりません。次のどちらの形式でもかまいません。

evt.getEventContext() == src
evt.getOldBinding().getName().equals("x/y")

5.3.4 例外の処理

リスナーがコンテキストにイベントを登録するときは、イベントの生成に必要な情報を収集するために、コンテキストの内部で処理を行う必要がある場合があります。たとえば、サーバ上の変更の対象を登録し、最終的にイベントに変換するには、コンテキストからサーバに要求を発行する必要があります。エラーが発生したためイベントの情報を収集できない場合は、リスナーにはイベントの通知は行われません。このようなエラーが発生した場合は、NamingExceptionEvent が投げられ、リスナーに通知されます。 また、リスナーの登録は自動的に解除されます。

ベースとなる NamingListener インタフェースに namingExceptionThrown() メソッドを定義すると、このようなエラーがリスナーに通知されます。

public interface NamingListener extends java.util.EventListener {
    public void namingExceptionThrown(NamingExceptionEvent evt);
}

5.4 LDAP パッケージ -- javax.naming.ldap 4

 

javax.naming.ldap パッケージには、LDAP v3 固有の機能を使用するためのクラスおよびインタフェースが含まれています。 この機能は、より汎用的な javax.naming.directory パッケージには含まれていません。現状では、LDAP を使用している JNDI アプリケーションの大半は、javax.naming.directory パッケージで十分であり、そもそも javax.naming.ldap パッケージを使用する必要がありません。このパッケージは、拡張操作、コントロール、または要求されていない通知を使用するアプリケーションで、主に使用します。

5.4.1 拡張操作

LDAP v3 プロトコル (Internet RFC 2251) には、検索および変更などの明確に定義された操作以外に、LDAP クライアントと LDAP サーバ間で未定義の操作を転送する方法も指定されています。この未定義の操作は、「拡張操作」と呼ばれます。拡張操作は、IETF などの標準化機構またはベンダーによって定義されます。

LdapContext インタフェースには、拡張操作を実行するためのメソッドが定義されています。

public interface LdapContext extends DirContext {
    public ExtendedResponse extendedOperation(ExtendedRequest request)
           throws NamingException;
    ...
}

ExtendedRequest インタフェースは拡張操作の引数を、ExtendedResponse インタフェースは拡張操作の結果をそれぞれ表現します。ExtendedRequest または ExtendedResponse は、拡張操作を識別する識別子、および ASN.1 BER 方式で符号化された要求および応答が含まれるバイト配列で構成されます。

アプリケーションでは、通常、ExtendedRequest および ExtendedResponse インタフェースは直接処理されません。代わりに、これらのインタフェースを実装しているクラスが処理されます。これらのクラスは、IETF によって標準化された拡張操作のレパートリの一部として取得しますが、ベンダー固有の拡張操作の場合はディレクトリベンダーから取得します。要求クラスには、型保証された簡単な方法で引数を受け取るコンストラクタが必要です。 また、応答クラスには、同様の方法で応答のデータを取得するアクセスメソッドが必要です。要求および応答クラスでは、BER 値の符号化および復号化が行われます。

たとえば、LDAP サーバで、拡張操作として時刻の取得がサポートされていると想定します。サーバから、GetTimeRequestGetTimeResponse などのクラスが提供されるので、アプリケーションではこの機能を次の方法で使用することができます。

GetTimeResponse resp =
   (GetTimeResponse)lctx.extendedOperation(new GetTimeRequest());
long time = resp.getTime();

 

5.4.2 コントロール

LDAP v3 プロトコル (Internet RFC 2251) を使用すれば、未定義の修飾子を追加して、任意の要求または応答を拡張できます。この修飾子は、「コントロール」と呼ばれます。要求と共に送信されるコントロールは、「要求コントロール」 と呼ばれます、応答と共に送信されるコントロールは、「応答コントロール」と呼ばれます。コントロールは、IETF などの標準化機構またはベンダーによって定義されます。要求コントロールと応答コントロールを対応付ける必要はありません。

JNDI では、要求コントロールは、次の 2 つのカテゴリに分類されます。

接続要求コントロールは、LDAP サーバとの接続の確立または再確立を行うときに使用します。コンテキスト要求コントロールは、接続以外のすべての LDAP 操作を LDAP サーバに送信するときに使用します。2 種類のコントロールを使用するのは、JNDI が高レベルの API で、接続を直接処理できないためです。必要な接続は、サービスプロバイダで管理されます。このため、1 つの接続が複数のコンテキストインスタンスで共有されることがあります。 サービスプロバイダでは、独自のアルゴリズムを使用して、接続およびネットワークの状態を保持することができます。この場合、コンテキストインスタンス上でメソッドが呼び出されたときに、サービスプロバイダは、対応する LDAP 操作以外に、接続の管理が必要になることがあります。接続を管理する場合は接続要求コントロールを使用しますが、通常の LDAP 操作の場合はコンテキスト要求コントロールを使用します。

LdapContext インタフェースには、コントロールを処理するメソッドが定義されています。

public interface LdapContext extends DirContext { 
    public void reconnect(Control[] connCtls) throws NamingException; 
    public Control[] getConnectControls() throws NamingException; 
    ... 
    public LdapContext newInstance(Control[] reqCtls)
           throws NamingException; 
    public void setRequestControls(Control[] reqCtls) 
           throws NamingException; 
    public Control[] getRequestControls() throws NamingException; 
    ... 
    public Control[] getResponseControls() throws NamingException; 
}

Control インタフェースは、コントロールを表現します。このインタフェースには、コントロールを識別する識別子、および ASN.1 BER 方式で符号化されたコントロールの内容が含まれるバイト配列で構成されます。

接続要求コントロールは、初期コンテキストコンストラクタによって初期化され、コンテキストから派生したコンテキストに継承されます。コンテキストの接続要求コントロールを変更するには、reconnect() を使用します。コンテキストの接続要求コントロールを取得するには、getConnectControls() を使用します。

コンテキスト要求コントロールを初期化するには、newInstance() を使用します。 変更するときは、setRequestControls() を使用します。 newInstance() は、マルチスレッドアクセスを行う目的で、コンテキストの新しいインスタンスを生成するときに使用する簡易メソッドです。たとえば、複数のスレッドで個別のコンテキスト要求コントロールを使用する場合は、スレッドごとにこのメソッドを使用して、コンテキストの独自のコピーの取得、およびコンテキスト要求コントロールの設定と取得を行うことができます。 このとき、ほかのスレッドと同期化する必要はありません。

接続要求コントロールと異なり、コンテキスト要求コントロールは、コンテキストから派生したコンテキストインスタンスには継承されません。派生したコンテキストインスタンスは、コンテキスト要求コントロールを使用しないで初期化されます。派生したコンテキストインスタンスの要求コントロールは、setRequestControls() を使用して明示的に設定しなければなりません。コンテキストのコンテキスト要求コントロールを取得するには、getRequestControls() を使用します。

 

5.4.3 初期コンテキスト

LDAP 拡張操作またはコントロールを実行しているアプリケーションで初期コンテキストを作成するには、javax.naming.InitialContext または javax.naming.directory.InitialDirContext の代わりに、InitialLdapContext を使用します。

public class InitialLdapContext extends InitialDirContext implements LdapContext { 
    public InitialDirContext() ...; 
    public InitialDirContext(Hashtable env, Control[] connCtls) ...; 
}

初期化が完了したら、初期コンテキストで ContextDirContext、または LdapContext インタフェースの任意のメソッドを呼び出すことができます。connCtls 引数を受け取るコンストラクタを使用すれば、LDAP サーバとの接続を確立するときに使用するコントロールをアプリケーションから指定できます。

 

5.4.4 要求されていない通知

LDAP v3 プロトコルには、クライアントとサーバ間の通常の要求および応答型の対話以外に、「要求されていない通知」を指定できます。 要求されていない通知とは、サーバからクライアントに非同期に送信されるメッセージのことで、クライアント要求に対する応答ではありません。

JNDI では、javax.naming.event パッケージに統合されたイベントモデルを使用して、任意通知をサポートしています。JNDI には、UnsolicitedNotificationEvent クラスと対応する UnsolicitedNotificationListener インタフェースが定義されています。UnsolicitedNotificationEvent を受信するようにアプリケーションを登録するには、UnsolicitedNotificationListenerEventContext.addNamingListener() に渡します。


1. クラスの図の凡例は、「付録 C」 を参照してください。

2. クラスの図の凡例は、「付録 C」 を参照してください。

3. クラスの図の凡例は、「付録 C」 を参照してください。

4. クラスの図の凡例は、「付録 C」 を参照してください。


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