目次 | 前へ | 次へ

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

JNDI API は、次の 4 つのパッケージに含まれています。

JNDI サービスプロバイダインタフェースは、次の 1 つのパッケージに含まれています。

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

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

javax.naming パッケージ。この図の説明は、API ドキュメントに記載されています。

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

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 オブジェクトに対して実行されます。この名前が空 ("") である場合、その操作はコンテキスト自体で直接実行されます。オブジェクトの名前を合成名にして、オブジェクトの参照で使用される名前空間の配置を反映できます。クライアントは、ネームサービスの実装には公開されません。また、新しい型のネームサービスを導入するときに、アプリケーションを変更したり、実行中のアプリケーションを中断する必要はありません。

 

5.1.2 初期コンテキスト

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

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

初期コンテキストには、クライアントを、URL の名前空間や DNS のルートなどの 1 つまたは複数のネーミングシステムの役立つ共有コンテキストに接続するさまざまなバインディングが含まれています。

 

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

各参照には、それが表すオブジェクトのクラスの名前が含まれている可能性があり、またそのオブジェクトのクラスファイルを見つけることのできる位置 (通常は URL) も含まれている可能性があります。さらに、参照には、RefAddr クラスのオブジェクトのシーケンスが含まれています。各 RefAddr には、さらに「型」の文字列と何らかのアドレス指定データ (一般には、文字列またはバイト配列) が含まれています。

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

 

5.1.6 照会

一部のネームサービスまたはディレクトリサービスは、クライアントの要求を別のサーバーにリダイレクトするための照会の概念をサポートしています。JNDI クライアントでは、その照会の自動的な追跡、無視、または手動処理を要求できます。

抽象クラス 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

 

javax.naming.directory パッケージ。

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

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 番目の形式は、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 は、便宜上、2 つのインタフェース BasicAttributeBasicAttributes のための実装を提供します。サービスプロバイダおよびアプリケーションでは、独自の実装を使用できます。

AttributesAttribute への更新 (属性またはその値の追加や削除など) を行なっても、ディレクトリ内の対応する表現には影響を与えないことに注意してください。ディレクトリへの更新を有効にできるのは、DirContext.modifyAttributes() を使用した場合だけです。

 

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

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

ハイブリッド操作では、特定のネーミングおよびディレクトリ操作を 1 つの原子的操作で実行します。

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

提供されるその他のハイブリッド操作には、追加の Attributes 引数を受け入れる rebind()createSubcontext() があります。

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 パッケージ。この図の説明は、API ドキュメントに記載されています。

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;
}

対応する Context インタフェース内のメソッドと同様に、addNamingListener() には、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 インタフェースでは、リスナーが検索フィルタ (インターネット RFC 2254) を使用して識別されたオブジェクトを対象として登録できるようにするために、EventContext および DirContext インタフェースを拡張します。

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

addNamingListener() メソッドが呼び出された EventContext/EventDirContext インスタンスは、生成されている (可能性のある) イベントのイベントソースです。登録されたリスナーが NamingEventgetSource() または getEventContext() を呼び出した場合、この EventContext/EventDirContext インスタンスが返されます。

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

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

そのあと、「x/y」という名前のオブジェクトが削除された場合、listener に配信される対応する NamingEvent (evt) には、そのイベントソースとして 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 パッケージ。この図の説明は、API ドキュメントに記載されています。

 

javax.naming.ldap パッケージには、より汎用的な javax.naming.directory パッケージではまだサポートされていない LDAP v3 固有の機能を使用するためのクラスとインタフェースが含まれています。実際、LDAP を使用するほとんどの JNDI アプリケーションは javax.naming.directory パッケージで十分なので、このパッケージを使用する必要はありません。このパッケージは、拡張操作、コントロール、または非要請通知を使用するアプリケーションで、主に使用します。

5.4.1 拡張操作

検索や変更などの適切に定義された操作の指定に加えて、LDAP v3 プロトコル (インターネット RFC 2251) は、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 サーバーが「時間取得」の拡張操作をサポートしているとします。LDAP サーバーは、アプリケーションがこの機能を使用できるように GetTimeRequestGetTimeResponse などのクラスを指定します。アプリケーションはこれらのクラスを次のように使います。

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

 

5.4.2 コントロール

LDAP v3 プロトコル (インターネット 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 パッケージに組み込まれたイベントモデルを使用して非要請通知をサポートします。ここでは、UnsolicitedNotificationEvent クラスとそれに対応する UnsolicitedNotificationListener インタフェースが定義されます。UnsolicitedNotificationEvent を受信するようにアプリケーションを登録するには、UnsolicitedNotificationListenerEventContext.addNamingListener() に指定します。


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

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

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

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

目次 | 前へ | 次へ


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