JP5744717B2 - ディレクトリへのアクセスのための方法及びデバイス - Google Patents

Description

本発明は、請求項１のプリアンブルに従う方法に関する。本発明を具現化したデバイス及びソフトウェアプログラムも説明される。

ディレクトリは、論理的且つ階層的な方法で組織されたオブジェクトのセットである。ディレクトリの一般的な例は電話帳（テレフォンディレクトリ）であり、これは、アルファベット順に組織された、例えば人又は組織の一連の名前から構成され、各名前には、住所及び電話番号が添付されている。データが階層的なツリー様の構造で表現されるという事実に起因して、ディレクトリは、エントリのツリーとして見なされ、また、ディレクトリ情報ツリー又は単にディレクトリツリーとしても見なされる。ディレクトリ内のデータは、ディレクトリサービスによって管理可能である。

Lightweight Directory Access Protocol（ＬＤＡＰ）のようなアプリケーションプログラムを利用して、ディレクトリにおける修正及びクエリ（問合せ）を実行することができる。ＬＤＡＰは、一般的にＴＣＰ／ＩＰとして知られているTransmission Control Protocol（ＴＣＰ）及びInternet Protocol（ＩＰ）上で動作する、ディレクトリサービスのプロトコルである。ＬＤＡＰは、クライアント−サーバ・モデルに基づいており、クライアントはＬＤＡＰサーバに対してＴＣＰ接続を行い、ＴＣＰ接続上で、要求を送信し応答を受信する。１以上のＬＤＡＰサーバが、ＬＤＡＰディレクトリを成すデータを含む。分散ディレクトリの場合、クライアントがどのＬＤＡＰサーバに接続しているかに関わらず、クライアントはディレクトリに関する同一のビューを持つ。即ち、或るＬＤＡＰサーバに対して提示される名前は、別のＬＤＡＰサーバ上にあるかもしれない同一のエントリを参照する。

ＬＤＡＰディレクトリサービスモデルは、エントリに基づく。エントリは属性の集合であり、この集合は、識別名(distinguished name)と呼ばれる名前を持ち、この名前はエントリを一意に参照する。エントリの属性の各々は、タイプと１以上の値とを持つ。タイプは一般的に、コモンネームに対する”ｃｎ”やＥメールアドレスに対する”ｍａｉｌ”のような、ニーモニック文字列である。値は、属性タイプに依存する。ＬＤＡＰにおいて、ディレクトリのエントリは、階層的なツリー様の構造に整理され、この構造は、例えば地理上の又は組織上の境界を反映することができる。

ＬＤＡＰは、ディレクトリに対する問い合わせ及び更新のための動作を規定する。例えば、ディレクトリに対してエントリを追加及び削除するための動作、既存のエントリを変更するための動作、及びエントリの名前を変更するための動作が提供される。ＬＤＡＰは、ディレクトリ内の情報を検索するために最もよく利用される。ＬＤＡＰの検索動作により、ディレクトリの一部から、検索フィルタによって指定される基準に合致するエントリを検索することができる。次いで、基準に合致するエントリから情報を要求することができる。

"The C LDAP Application Program Interface, draft-ietf-ldapext-ldap-c-api-05.txt, 2000"に記載されている、ＬＤＡＰクライアントのソースコードのインタフェースの仕様は、ＬＤＡＰアプリケーション・プログラム・インタフェース（ＡＰＩ）上に２種類の動作を規定しており、２グループの関数呼び出し（それぞれ、「非同期」関数呼び出し、及び「同期」関数呼び出しと名付けられている）のプロビジョニングによって説明される。同期関数呼び出しは、ディレクトリに対して要求を行うアプリケーション（例えば、コンピュータプログラム）をブロックし、ＬＤＡＰサーバが要求に対してサービス提供して結果を返すまでそのアプリケーションに制御を戻さない（リターンしない）。他方、非同期関数は、ＬＤＡＰクライアントが要求を処理するとすぐにアプリケーションに制御を戻し、そして、アプリケーションは自分の動作を継続することができる。

短時間に多数の要求を処理しなければならないアプリケーションが存在する。通信アプリケーションの例では、多数の検索要求に対してサービス提供しなければならない場合が存在する。同期関数及び非同期関数の動作は共に、そのような場合に、要求されるスループットを達成することができないので、問題がある。この２種類の関数のどちらが利用される場合であっても、次の要求が送信可能になるためにはその前に、最初に各要求の処理が、プロセスにおいてアクティブな全てのプロトコルレイヤ（ＬＤＡＰ，ＴＣＰ／ＩＰ）によって完了される必要があるので、要求されるスループットを達成できないことが発生する。非同期の場合は更に、サーバから来る要求であってフェッチする必要がある要求がいつ存在するかを判定するためのチェックを、アプリケーションが定期的に実行する必要がある。

本発明の目的は、上述の欠点を除去し、ディレクトリにアクセスするための有利な方法を提供することである。

本発明によれば、請求項１に記載の方法が実行される。更に、本発明は、更なる独立請求項に記載のデバイス及びプログラムに具現化される。本発明の諸実施形態は、従属請求項に記載される。

アプリケーションによってディレクトリ内の情報にアクセスするための方法が提案される。関数ライブラリが、サーバから前記情報をフェッチするための前記アプリケーションからの第１の要求を処理する。前記第１の要求が、クライアントモジュールによって前記関数ライブラリから前記サーバへ転送される。更に、前記第１の要求が前記サーバへ転送される際に、前記関数ライブラリから前記アプリケーション及び前記サーバへ要求識別子が送信される。前記アプリケーションによって行われた前記第１の要求に対する前記サーバからの応答信号が受信される。前記応答信号は、前記クライアントによって前記サーバへ送信された前記要求識別子と同一の応答識別子を含む。次いで、前記第１の要求に対して前記応答を照合するために前記応答識別子がチェックされ、前記アプリケーションは、前記応答信号をデコードするために前記関数ライブラリから関数を呼び出す。最後に、前記関数ライブラリから前記アプリケーションへ前記デコードされた応答信号が返される。

更に、本発明は、ディレクトリ内の情報にアクセスするためのデバイスに具現化することができる。前記デバイスは、少なくとも１つのアプリケーションを実行し情報の第１の要求をサーバへ送信するように構成される処理ユニットと、前記アプリケーションからの前記第１の要求を処理するための少なくとも１つの関数を含む関数ライブラリユニットと、を備える。前記デバイスは更に、前記アプリケーションから前記サーバへ前記第１の要求を転送するクライアントモジュールを備える。前記関数ライブラリユニットは更に、前記第１の要求に対して要求識別子を割り当てる手段と、前記サーバへの前記第１の要求が転送される際に前記要求識別子を前記アプリケーションへ転送するように構成されるインタフェースと、前記第１の要求に対する、前記処理ユニットによって受信される応答信号をデコードする、デコーダと、を備える。前記処理ユニットは、応答識別子を含む応答信号を前記サーバから受信するように構成されるインタフェースと、前記要求識別子を格納するメモリと、前記第１の要求に対する前記応答信号を照合するために、前記応答識別子と前記要求識別子とを比較するように構成される比較ユニットと、を備える。

本発明の方法はプログラムに具現化することも可能であり、このプログラムは例えば、信号のシーケンスとして、データキャリア（担持体）に格納したり、デバイスの処理システムにロードしたりすることができる。

提案される方法及びデバイスにより、大量の検索要求に対してサービス提供する際の低い性能を回避して、ディレクトリに対する有利なアクセスを行うことが可能になる。

本発明の前述の、及びその他の目的、特徴、及び利点は、添付の図面に示されるような好適な実施形態に関する以下の説明において、一層明らかになるであろう。

ＬＤＡＰクライアントに関する高レベルの描写を示す。 先行技術のＬＤＡＰクライアントにおける同期動作モードを示す。 先行技術のＬＤＡＰクライアントにおける非同期動作モードを示す。 ブロッキング非同期対話(interaction)のシグナリング図を示す。 非ブロッキング非同期対話のシグナリング図を示す。 提案される方法を実行するように構成されるデバイスを示す。

以下では、ＬＤＡＰへの応用に言及して本発明を説明する。しかしながら、提案される方法はＬＤＡＰには限定されず、他のディレクトリアクセスプロトコルにおいても利用可能である。

図１は、ＬＤＡＰクライアントのアーキテクチャに関する高レベルの描写を示す。１以上のアプリケーション１００（例えば、コンピュータプログラム）は、ＬＤＡＰプロトコルのメカニズムを実装するＬＤＡＰクライアントモジュール１０４と通信する。ＬＤＡＰクライアントモジュールは、アプリケーションに代わってリモートサーバと更に通信するために、ＴＣＰ／ＩＰスタック１０６と通信する。アプリケーションは、ＬＤＡＰ機能の一部としてアプリケーションに備えられているＬＤＡＰユーザライブラリ１０２という手段を介して、ＬＤＡＰクライアントモジュールと通信する。ＬＤＡＰユーザライブラリは、ＬＤＡＰサービスを開発し実装するために使用されるサブプログラムの集合である。ＬＤＡＰ ＡＰＩにより、アプリケーションとＬＤＡＰクライアントモジュールとの間の通信のための関数呼び出しを提供するＬＤＡＰユーザライブラリに対するアクセスが可能になる。

図２ａは、先行技術のＬＤＡＰクライアント２００における同期動作モードの高レベルのビューを示す。同期動作では、ディレクトリに対して要求２０４を行うアプリケーションは、ＬＤＡＰサーバ２０２が要求に対してサービス提供して結果２０６を返すまで、更なる動作ができないようにブロックされる。その後、アプリケーションの更なる動作が再開される。これが意味することは、以前の要求に対してサービス提供されて結果がアプリケーションに対して返されるまで、アプリケーションは別のタスクを実行したり更にリクエストを送信したりするためにステップｎ＋１に進むことができないということである。

図２ｂは、先行技術のＬＤＡＰクライアント２００における非同期動作モードの概要を示す。非同期動作では、ＬＤＡＰサーバ２０２が要求を処理するとすぐに、非同期関数はアプリケーションの更なる動作を許可する。このようにして、要求がＬＤＡＰサーバへ送信（２１２）されるとすぐに、アプリケーションは更なるステップｎ＋ｍへと継続して別のタスクを実行することができる。応答２１４を受信するために、アプリケーションは、サーバから応答が到着したか否かを判定するための定期的なチェックを実行する必要がある。

図３は、非同期動作モードの動作に関するシグナリング図を示す。アプリケーション３１０は、ユーザライブラリ３１２の中の非同期関数を呼び出す（３１６）。次にライブラリは、信号３１８を割り当て、ＬＤＡＰクライアントモジュール３１４に対して要求を送信する。要求が送信されると、ライブラリは、アプリケーションからの更なる要求をブロックする（３２４）。要求の処理が終了すると、サーバからＬＤＡＰクライアントモジュールへと応答信号が送信され、ＬＤＡＰクライアントモジュールは更に、応答信号３２０をライブラリへ送信する。応答信号はライブラリによってデコードされ（３２６）、続いて、関数呼び出しのリターン３２２によって動作の結果がアプリケーションに返される。その間、アプリケーションはブロックされる。この理由により、ここに記載されるモードはブロッキング非同期動作モードと呼ばれ、関数はブロッキング非同期関数と呼ばれる。

上述のいずれのモードにおいても、要求を行うアプリケーションは、以前の要求に対してサービス提供されるまで新たな要求を送信することができない。しかしながら、同期動作ではアプリケーションは更なるタスクを実行できないようにブロックされるのに対して非同期動作ではアプリケーションは自由に更なるタスクを実行できるので、２つの動作モード間には相違点が存在する。いずれの動作モードでも以前の要求に対してサービス提供されるまでは更なる要求を送信できないという事実は、多数の要求に対してサービス提供するというニーズが存在する場合に制約をもたらす。例えば通信アプリケーションにおいて短時間に多くの要求に対してサービス提供する必要がある場合のＬＤＡＰ機能を可能にするために、新しいグループの非ブロッキングの真に非同期の関数呼び出しを提案する。これはＬＤＡＰクライアントの非同期動作モードにおいて使用される非同期関数呼び出しに基づいており、フェッチする必要のある結果がサーバから来た時を判定するためのチェックを定期的に実行する必要がない。提案される関数呼び出しにより、以前の要求に対してサービス提供される前にアプリケーションが更なる要求を行うことが可能になる。先行技術に見られる非同期動作モードと比べて、より多くの数の要求に対してサービス提供することができる。

提案される非ブロッキング非同期対話モードの動作の実施形態を図４のシグナリング図に示す。アプリケーション４１０は、ユーザライブラリ４１２の中の非ブロッキング非同期関数を呼び出す（４１６）ことにより、要求を行う。次にユーザライブラリ４１２は信号４１８を割り当て、ＬＤＡＰクライアントモジュール４１４に対して要求識別子と共に要求を送信する。関数呼び出しは、要求識別子を伴ってアプリケーションへ返される（４２０）。この要求識別子は、ＬＤＡＰクライアントモジュールからサーバへも送信される。要求識別子は、ユーザライブラリからＬＤＡＰクライアントモジュールへ送信される要求の同定を提供し、特定の要求に関する情報（例えば、ＬＤＡＰクライアントとの通信セッションに対する要求の関係）を含むことができる。ＬＤＡＰサーバは、アプリケーションによって行われた要求を処理した後に、応答識別子と共に応答信号をＬＤＡＰクライアントへ送信し、ＬＤＡＰクライアントは更に応答信号４２２をアプリケーションへ送信する。応答信号は、アプリケーションによって行われた要求に対する回答を含む。応答識別子は、クライアントモジュールによってサーバへ送信された要求識別子と同一である。アプリケーションが信号キューの中に応答信号を受信する場合に特に、アプリケーションは、フェッチする必要のある結果がサーバから来た時を判定するためのチェックを定期的に実行する必要がない。信号キューは、アプリケーションが対話するプロセスからアプリケーションが受信する信号にとっての入力点である。応答信号は、アプリケーションの信号処理コードによって処理される。信号処理コードは、応答信号を分析し、これを解釈しようとする。応答信号の分析及び解釈により、アプリケーションは、応答信号をＬＤＡＰクライアントモジュールとの対話に関係するものとして認識することができる。例えば、要求識別子は、この関係を認識するために利用可能である。識別子は、ＬＤＡＰクライアントを起源とする信号を意味するラベルを含むことができる。ＬＤＡＰサーバから来る信号は全てエンコードされているので、アプリケーションはその内容を読むことができない。この理由により、アプリケーションは、信号の内容をデコードする（４３２）ために、ＬＤＡＰユーザライブラリの関数を呼び出す（４２４）。これに続いて、ライブラリは動作の結果をアプリケーションに返す（４２６）。この結果は、アプリケーションによって行われた要求に対する返答である。

一実施形態では、アプリケーションによって行われた要求とアプリケーションに対して返される対応する要求識別子との関連付けを、アプリケーションによって格納する（４２８）ことができる。関連付けは、ＬＤＡＰサーバから送信された応答をアプリケーションによって行われた要求と照合する（４３０）ために使用可能である。

他の実施形態では、ＬＤＡＰ関数ライブラリは、アプリケーションによって行われる更なる要求の非ブロッキング非同期処理を可能にする関数を含む。

本発明は、上述の方法の何らかの実施形態を実行するように構成可能なデバイス５００に具現化することもできる。そのようなデバイスの実施形態を図５に示す。このデバイスは、処理ユニット５０２を備える。処理ユニット５０２は、通信インタフェース５０８経由でサーバに対して情報の要求を送信するアプリケーションを実行するように構成される。処理ユニット５０２は、応答識別子を伴う応答信号をサーバから受信するようにも構成される。処理ユニットは、要求識別子を格納するように構成されるメモリ５０６、及び、比較器５０４も備える。比較器５０４は、格納されている要求識別子を受信した応答識別子と比較することにより、アプリケーションによって行われた要求に対して応答を照合するように構成される。

デバイスは、アプリケーションからの情報要求に対してサービス提供するための関数を処理ユニットに提供するように構成される、関数ライブラリユニット５１０も備える。関数ライブラリは、処理ユニットから受信した要求に対して要求識別子を割り当てるように構成される割り当てユニット５１２も含む。処理ユニットとの通信は、通信インタフェース５１６経由で実行される。デコーダ５１４は、処理ユニットから関数ライブラリへ転送される応答信号をデコードするように構成される。エンコードされた応答信号は、線５２０によって示すように、アプリケーションによって行われた要求に対する、処理ユニット５０２へ転送される応答である。

デバイスは、アプリケーションからの要求をサーバへ転送し、サーバからの応答を関数ライブラリユニット又は処理ユニットへ送信するように構成される、ＬＤＡＰクライアントモジュール５１８も備える。

処理ユニット、関数ライブラリユニット、クライアントモジュール、及びサーバの間の通信は、矢印５２２によって示される。

上述のデバイスのエレメントは、ハードウェア、ソフトウェア、又はこれらの任意の組み合わせにより、実装可能である。

上述の実施形態は、本発明の目的を立派に達成する。しかしながら、理解されるであろうこととして、当業者は、本発明の範囲から逸脱すること無しに変更を行うことができる。本発明の範囲は、請求項によってのみ限定される。

Claims (9)

1. アプリケーション（４１０）によってディレクトリ内の情報にアクセスするための方法であって、
   関数ライブラリ（４１２）が、サーバから前記情報をフェッチするための前記アプリケーションからの第１の要求を処理し、
   前記第１の要求が、クライアントモジュール（４１４）によって前記関数ライブラリ（４１２）から前記サーバへ転送され、
   前記方法は更に、
   前記第１の要求が前記サーバへ転送される際に、前記関数ライブラリから前記アプリケーションへ要求識別子（４２０）を送信するステップと、
   前記アプリケーションによって、前記第１の要求に対する前記サーバからの応答信号（４２２）であって、応答識別子を含む応答信号（４２２）を、前記関数ライブラリを介さずに受信するステップと、
   前記第１の要求に対して前記応答信号（４２２）を照合するために、前記応答識別子と前記要求識別子とを比較するステップと、
   前記アプリケーションによって、前記関数ライブラリから前記応答信号をデコードするための関数を呼び出すステップ（４２４）と、
   前記関数ライブラリから前記アプリケーションへ前記デコードされた応答信号を返すステップ（４２６）と、
   を含む
   ことを特徴とする方法。
2. 前記アプリケーション（４１０）は、前記要求識別子と前記第１の要求との関連付けを格納し、
   前記関連付けは、前記第１の要求に対して前記応答信号を照合するために使用される
   ことを特徴とする請求項１に記載の方法。
3. 前記関数ライブラリ（４１２）は、前記アプリケーションからの更なる要求の非同期処理のための少なくとも１つの関数を含む
   ことを特徴とする請求項１又は２に記載の方法。
4. 前記応答信号（４２２）は、前記アプリケーションの信号キューの中に受信される
   ことを特徴とする請求項１乃至３のいずれか１項に記載の方法。
5. 前記ディレクトリは、複数のエントリを含み、エントリは属性の集合を含む
   ことを特徴とする請求項１乃至４のいずれか１項に記載の方法。
6. 前記ディレクトリは複数のサーバに亘って分散している
   ことを特徴とする請求項１乃至５のいずれか１項に記載の方法。
7. 前記要求識別子は、前記クライアントモジュール（５１８）から前記サーバへ送信され、
   前記応答信号（４２２）の中の前記応答識別子は、前記要求識別子である
   ことを特徴とする請求項１乃至６のいずれか１項に記載の方法。
8. ディレクトリ内の情報にアクセスするためのデバイスであって、
   情報の第１の要求をサーバへ送信するように構成される少なくとも１つのアプリケーション（１００）を実行するように構成される処理ユニット（５０２）と、
   前記アプリケーションからの前記第１の要求を処理するための少なくとも１つの関数を含む関数ライブラリユニット（５１０）と、
   前記アプリケーションから前記サーバへ前記第１の要求を転送するクライアントモジュール（５１８）と、
   を備え、
   前記関数ライブラリユニット（５１０）は、
   前記第１の要求に対して要求識別子を割り当てる手段（５１２）と、
   前記サーバへの前記第１の要求が転送される際に前記要求識別子を前記アプリケーションへ転送するように構成されるインタフェース（５１６）と、
   前記第１の要求に対する、前記処理ユニット（５０２）によって受信される応答信号をデコードする、デコーダ（５１４）と、
   を備え、
   前記処理ユニット（５０２）は、
   応答識別子を含む応答信号を、前記関数ライブラリユニットを介さずに前記サーバから受信するように構成されるインタフェース（５０８）と、
   前記要求識別子を格納するメモリ（５０６）と、
   前記第１の要求に対する前記応答信号を照合するために、前記応答識別子と前記要求識別子とを比較するように構成される比較ユニット（５０４）と、
   を備える
   ことを特徴とするデバイス。
9. デバイスの処理システムにロードされると当該デバイスに請求項１乃至７のいずれか１項に記載の方法を実行させる命令を含む、プログラム。

Images