JP2013525920A - ディレクトリサーバーを統合するための技法 - Google Patents

ディレクトリサーバーを統合するための技法 Download PDF

Info

Publication number
JP2013525920A
JP2013525920A JP2013508144A JP2013508144A JP2013525920A JP 2013525920 A JP2013525920 A JP 2013525920A JP 2013508144 A JP2013508144 A JP 2013508144A JP 2013508144 A JP2013508144 A JP 2013508144A JP 2013525920 A JP2013525920 A JP 2013525920A
Authority
JP
Japan
Prior art keywords
directory
cache
entry
server
directory entry
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2013508144A
Other languages
English (en)
Other versions
JP5726290B2 (ja
Inventor
モバラック・アイマン
モーサー・ナサン
ジャマート・チャド
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
NortonLifeLock Inc
Original Assignee
Symantec Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Symantec Corp filed Critical Symantec Corp
Publication of JP2013525920A publication Critical patent/JP2013525920A/ja
Application granted granted Critical
Publication of JP5726290B2 publication Critical patent/JP5726290B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/12—Replacement control
    • G06F12/121—Replacement control using replacement algorithms
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22—Indexing; Data structures therefor; Storage structures
    • G06F16/2228—Indexing structures
    • G06F16/2246—Trees, e.g. B+trees

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

ディレクトリサーバーを統合するための技法が開示される。特定の一例示的実施形態において、技法は、キャッシュされた複数のディレクトリエントリの許容期限の範囲を決定する１つまたはそれ以上パラメータを設定することと、電子記憶装置において、ディレクトリサーバーからキャッシュディレクトリエントリを作成することと、キャッシュディレクトリエントリに作成時刻を割り当てることと、キャッシュディレクトリエントリに少なくとも１つのランダム値を割り当てることと、を含むディレクトリサーバーを統合するための方法として実現されてよく、このランダム値は、許容期限の範囲内で、キャッシュディレクトリエントリの期限切れ時期を判断し、キャッシュディレクトリエントリの期限切れ時期を複数のキャッシュディレクトリエントリの許容期限の範囲内でランダム化することにより、ある時点においてキャッシュメモリとディレクトリサーバーとの間で必要とされる同期の量が減少する。

Description

本開示は、概してディレクトリデータサービスに関し、詳細にはディレクトリサーバーを統合するための技法に関する。
ディレクトリデータサービスは、ユーザー認証、メッセージ配送、およびグループポリシーの適用を含む様々なクライアントおよびアプリケーションにディレクトリデータを提供し得る。ディレクトリデータサービスは、例えば企業クラスのメッセージングセキュリティなど、高スループットが重要である複数の用途を果たし得る。アプリケーションおよび／またはディレクトリデータサービスは、キャッシュされたディレクトリデータを使用して性能を高め、ディレクトリサーバーにかかる負荷を減らす。ただし、キャッシュされたディレクトリデータは、ディレクトリサーバーに周期的に問い合わせることによってリフレッシュされないと、「陳腐化」、すなわち古くなり得る。キャッシュされたディレクトリデータを更新すると、多量のキャッシュデータが周期的に更新されるため、ディレクトリサーバーに大きな負担がかかり、大幅な性能の低下が生じ得る。性能の低下により、ひいては、ディレクトリデータサービスを使用するクライアントおよびアプリケーションに影響が及び得る。
上記内容から、現在のディレクトリサーバー統合技術に関わる重大な課題および欠点が存在し得るものと理解され得る。
ディレクトリサーバーを統合するための技法が開示される。特定の一例示的実施形態において、技法は、複数のキャッシュディレクトリエントリの許容期限の範囲を決定する１つまたはそれ以上のパラメータを設定することと、電子記憶装置で、ディレクトリサーバーからキャッシュディレクトリエントリを作成することと、キャッシュディレクトリエントリに作成時刻を割り当てることと、許容期限の範囲内でキャッシュディレクトリエントリの期限を決定する少なくとも１つのランダム値をキャッシュディレクトリエントリに、割り当てることと、を含む、ディレクトリサーバーを統合するための方法として実現されてよく、キャッシュディレクトリエントリの期限を複数のキャッシュディレクトリエントリの許容期限の範囲内でランダム化することにより、ある時点においてキャッシュメモリとディレクトリサーバーとの間で必要とされる同期の量が減少する。
この特定の例示的実施形態の他の態様によれば、キャッシュディレクトリエントリの許容期限の範囲を決定する１つまたはそれ以上のパラメータは、最大生存時間パラメータと最小生存時間パラメータとを備え得る。
この特定の例示的実施形態のさらなる態様によれば、キャッシュディレクトリエントリの許容期限の範囲を決定する１つまたはそれ以上のパラメータは、生存時間パラメータと生存時間分散パラメータとを備え得る。
この特定の例示的実施形態のさらなる態様によれば、技法は、ディレクトリエントリを求めるリクエストを受信することと、作成時刻と少なくとも１つのランダム値とに少なくとも部分的に基づいて、対応するディレクトリエントリの期限が切れているかどうかを判断することと、ディレクトリエントリの期限が切れている場合に、ディレクトリサーバーにディレクトリエントリをリクエストすることと、をさらに含み得る。
この特定の例示的実施形態のさらなる態様によれば、技法は、ディレクトリサーバーにアクセスできないと判断することと、リクエストを受けて、対応する期限切れのキャッシュディレクトリエントリを提供することと、をさらに含み得る。
この特定の例示的実施形態のさらなる態様によれば、技法は、ディレクトリエントリがキャッシュされているどうかを判断することと、ディレクトリエントリがキャッシュされていない場合に、ディレクトリサーバーにディレクトリエントリをリクエストすることと、をさらに含み得る。
この特定の例示的実施形態のさらなる態様によれば、技法は、ディレクトリサーバーからのレスポンスを受信することと、ディレクトリサーバーからのレスポンスに少なくとも部分的に基づいてデータ整合エラーを検出することと、データ整合エラー情報を格納したアラートを管理者に提供することと、をさらに含み得る。
この特定の例示的実施形態のさらなる態様によれば、ディレクトリサーバーは、ＬＤＡＰ対応ディレクトリサーバーを備え得る。
この特定の例示的実施形態のさらなる態様によれば、リクエストは、ディレクトリサーバーのホストとは別のゲートウェイ機器を備え得る電子デバイスから受信され得る。
この特定の例示的実施形態のさらなる態様によれば、リクエストは、ディレクトリサーバーのホストとは別の複数のゲートウェイ機器間のホスト共有キャッシュを備える電子デバイスから受信され得る。
この特定の例示的実施形態のさらなる態様によれば、リクエストは、１つまたはそれ以上のキャッシュディレクトリエントリを使用して、ユーザー認証、受信者の妥当性検証、アドレス解決、およびメッセージルーティングのうちの少なくとも１つを提供する電子デバイスを備える電子デバイスから受信され得る。
この特定の例示的実施形態のさらなる態様によれば、技法は、少なくとも１つのプロセッサに、方法を実行するためのコンピュータ処理を実行するように命令するために、少なくとも１つのプロセッサによって読み取り可能に構成されたコンピュータプログラム命令を記憶するための少なくとも１つのプロセッサ読み取り可能な記憶媒体として実現され得る。
別の特定の例示的実施形態において、技法は、少なくとも１つのプロセッサ読み取り可能な媒体を備える、ディレクトリサーバーを統合するための製品として実現され得る。命令は、少なくとも１つの媒体に記憶されてよく、命令は、少なくとも１つのプロセッサによって少なくとも１つの媒体から読み取り可能であるように、かつ、それによって少なくとも１つのプロセッサに、複数のキャッシュディレクトリエントリの許容期限の範囲を決定する１つまたはそれ以上のパラメータを設定し、電子記憶装置で、キャッシュディレクトリエントリをディレクトリサーバーから作成し、キャッシュディレクトリエントリに作成時刻を割り当て、キャッシュディレクトリエントリの期限を許容期限の範囲内で決定少なくとも１つのランダム値をキャッシュディレクトリエントリに割り当てるように動作させるように構成されており、複数のキャッシュディレクトリエントリの許容期限の範囲内でキャッシュディレクトリエントリの期限をランダム化することにより、ある時点においてキャッシュメモリとディレクトリサーバーとの間で必要とされる同期の量が減少する。
さらに別の特定の例示的実施形態において、技法は、ネットワークに通信可能に連結された１つまたはそれ以上のプロセッサを備える、ディレクトリサーバーを統合するためのシステムとして実現されてよく、１つまたはそれ以上のプロセッサは、複数のキャッシュディレクトリエントリの許容期限の範囲を決定する１つまたはそれ以上のパラメータを設定し、キャッシュディレクトリエントリをディレクトリサーバーから作成し、キャッシュディレクトリエントリに作成時刻を割り当て、キャッシュディレクトリエントリの期限を許容期限の範囲内で決定する少なくとも１つのランダム値をキャッシュディレクトリエントリに割り当てるように構成されており、複数のキャッシュディレクトリエントリの許容期限の範囲内でキャッシュディレクトリエントリの期限をランダム化することにより、ある時点においてキャッシュメモリとディレクトリサーバーとの間で必要とされる同期の量が減少する。
この特定の追加例示的実施形態の他の態様によれば、キャッシュディレクトリエントリの許容期限の範囲を決定する１つまたはそれ以上のパラメータは、最大生存時間パラメータと最小生存時間パラメータとを備え得る。
この特定の追加例示的実施形態のさらなる態様によれば、キャッシュディレクトリエントリの許容期限の範囲を決定する１つまたはそれ以上のパラメータは、生存時間パラメータと生存時間分散パラメータとを備え得る。
この特定の例示的実施形態のさらなる態様によれば、１つまたはそれ以上のプロセッサは、ディレクトリエントリのリクエストを受信し、作成時刻と少なくとも１つのランダム値とに少なくとも部分的に基づいて、対応するディレクトリエントリの期限が切れているかどうかを判断し、ディレクトリエントリの期限が切れている場合に、ディレクトリサーバーにディレクトリエントリをリクエストするようにさらに構成され得る。
この特定の例示的実施形態のさらなる態様によれば、１つまたはそれ以上のプロセッサは、ディレクトリサーバーにアクセスできないと判断し、リクエストに対して、対応する期限切れのキャッシュディレクトリエントリを提供するようにさらに構成され得る。
この特定の例示的実施形態のさらなる態様によれば、１つまたはそれ以上のプロセッサは、ディレクトリエントリがキャッシュされているどうかを判断し、ディレクトリエントリがキャッシュされていない場合に、ディレクトリサーバーにディレクトリエントリをリクエストするようにさらに構成され得る。
この特定の例示的実施形態のさらなる態様によれば、１つまたはそれ以上のプロセッサは、ディレクトリデータサービスのホストとは別のゲートウェイ機器の一部を備え得る。
この特定の例示的実施形態のさらなる態様によれば、１つまたはそれ以上のプロセッサは、１つまたはそれ以上のキャッシュディレクトリエントリを使用して、ユーザー認証、受信者の妥当性検証、アドレス解決、およびメッセージルーティングのうちの少なくとも１つを提供するようにさらに構成され得る。
さらに別の特定の例示的実施形態において、技法は、ディレクトリサーバーにディレクトリエントリをリクエストすることと、プロセッサを使用して、ディレクトリサーバーからのレスポンスに少なくとも部分的に基づいてデータ整合エラーを検出することと、データ整合エラー情報を格納したアラートを管理者に提供することと、を含む、ディレクトリサーバーを統合するための方法として実現され得る。
この特定の例示的実施形態のさらなる態様によれば、データ整合エラーは、電子メールアドレスの重複、ユーザー名の重複、行方不明または無効な属性データ、および循環グループ関係のうちの少なくとも１つを含み得る。
これより、本開示について、添付の図面に示す本開示の例示的実施形態を参照しながら、さらに詳しく説明する。本開示について、例示的実施形態を参照しながら以下説明するが、本開示はこれらの実施形態に制限されないことを理解すべきである。本明細書の教示にアクセスできる当業者であれば、さらなる実施態様、変更態様、および実施形態、さらには、本明細書に記載されている本開示の範囲内であり、かつ本開示が大きな有用性を持つであろう他の使用分野を認識するであろう。
本開示について十分な理解を促すために、添付の図面を参照する。図面中、同様の要素は同様の番号で参照されている。これらの図面は、本開示を制限するものと解釈されるべきなく、例示のみを意図するものである。
本開示の一実施形態にかかる、ディレクトリサーバーを統合するためのネットワークアーキテクチャを表すブロック図を示す。 本開示の一実施形態にかかるコンピュータシステムのブロック図を表す。 本開示の一実施形態にかかる、ディレクトリサーバーを統合するためのモジュールを示す。 本開示の一実施形態にかかる、ディレクトリサーバーを統合するための方法を表す。 本開示の一実施形態にかかる、ディレクトリサーバーを統合するための方法を表す。 本開示の一実施形態にかかる、ディレクトリデータサービスのキャッシュパラメータを設定するためのインターフェースを表す。 本開示の一実施形態にかかる、ディレクトリデータサービスのキャッシュパラメータを設定するためのインターフェースを表す。 本開示の一実施形態にかかる、クエリフィルタトークンを使用してディレクトリエントリを一致させる方法を表す。
図１は、本開示の一実施形態にかかる、ディレクトリサーバーを統合するためのネットワークアーキテクチャ１００を表すブロック図を示す。図１は、ネットワークアーキテクチャ１００の簡略図であり、表されていない追加要素を含み得る。ネットワークアーキテクチャ１００は、クライアントシステム１１０、１２０および１３０に加え、ディレクトリサーバー１４０（１）−（Ｎ）およびネットワークデバイス１７０（１）−（Ｎ）も含み得る（そのうちの１つまたはそれ以上が、図２に示すコンピュータシステム２００を使用して実装され得る）。クライアントシステム１１０、１２０および１３０は、ネットワーク１５０に通信可能に連結され得る。ディレクトリサーバー１４０（１）−（Ｎ）は、記憶デバイス１６０（１）−（Ｎ）に通信可能に連結され得る。ネットワークデバイス１７０（１）−（Ｎ）は、管理モジュール（例えばディレクトリデータサービス１５４）を格納し得る。
図２のコンピュータシステム２００を参照すると、クライアントシステム１１０、１２０および１３０のうちの１つまたはそれ以上からネットワーク１５０への接続を提供するために、モデム２４７、ネットワークインターフェース２４８、またはその他何らかの方法が使用され得る。クライアントシステム１１０、１２０および１３０は、例えば、ライトウェイトディレクトリアクセスプロトコル（ＬＤＡＰ）クライアントまたは他のクライアントソフトウェアを使用して、ディレクトリサーバー１４０（１）−（Ｎ）にある情報にアクセス可能であり得る。かかるクライアントにより、クライアントシステム１１０、１２０および１３０が、ディレクトリサーバー１４０（１）−（Ｎ）か、あるいは記憶デバイス１６０（１）−（Ｎ）のうちの１つによってホストされるデータにアクセスでき得る。
ネットワーク１５０および／または１８０は、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、インターネット、セルラー方式ネットワーク、衛星ネットワーク、または、クライアント１１０、１２０、１３０、ディレクトリサーバー１４０（１）−（Ｎ）、およびネットワーク１５０および／または１８０に通信可能に連結された他のデバイスとの間での通信を許可する別のネットワークであり得る。ネットワーク１５０および／または１８０は、スタンドアロンネットワークとして、あるいは互いに協同して動作する上記例示的なタイプのネットワークのうちの１つまたは任意の数をさらに含み得る。ネットワーク１５０および／または１８０は、通信可能に連結された１つまたはそれ以上のクライアントまたはサーバーのうちの１つまたはそれ以上のプロトコルを利用し得る。ネットワーク１５０および／または１８０は、ネットワークデバイスのうちの１つまたはそれ以上のプロトコルと他のプロトコルとの間での変換を行い得る。ネットワーク１５０および１８０は、単一のネットワークとして各々表されているが、１つまたはそれ以上の実施形態によれば、ネットワーク１５０および／または１８０が複数の相互接続されたネットワークを備え得ることが理解されるべきである。
記憶デバイス１６０（１）−（Ｎ）は、ネットワークアクセス可能記憶装置であってよく、ディレクトリサーバー１４０（１）−（Ｎ）に対してローカル、リモート、またはそれらの組み合わせであってもよい。記憶デバイス１６０（１）−（Ｎ）は、低価格ディスクの冗長配列（「ＲＡＩＤ」）、磁気テープ、ディスク、記憶装置エリアネットワーク（「ＳＡＮ」）、インターネット小型コンピュータシステムインターフェース（「ｉＳＣＳＩ」） ＳＡＮ、ファイバチャネルＳＡＮ、共通インターネットファイルシステム（「ＣＩＦＳ」）、ネットワーク接続型記憶装置（「ＮＡＳ」）、ネットワークファイルシステム（「ＮＦＳ」）、光学ベース記憶装置、または他のコンピュータアクセス可能記憶装置を利用してもよい。記憶デバイス１６０（１）−（Ｎ）は、バックアップまたはアーカイブ目的で使用されてもよい。
いくつかの実施形態によれば、クライアント１１０、１２０、および１３０は、スマートフォン、ＰＤＡ、デスクトップコンピュータ、ラップトップコンピュータ、サーバー、他のコンピュータ、またはネットワーク１５０に無線または有線接続経由で連結された他のデバイスであり得る。クライアント１１０、１２０、および１３０は、ユーザー入力、データベース、ファイル、ウェブサービス、および／またはアプリケーションプログラミングインターフェースからデータを受信し得る。
ディレクトリサーバー１４０（１）−（Ｎ）は、例えば、Ｍｉｃｒｏｓｏｆｔ（登録商標） Ａｃｔｉｖｅ Ｄｉｒｅｃｔｏｒｙ（登録商標）サーバー、ＩＢＭ（登録商標） Ｌｏｔｕｓ（登録商標） Ｄｏｍｉｎｏ（登録商標）サーバー、Ｓｕｎ（登録商標）ディレクトリサーバー、ＬＤＡＰ対応ディレクトリサーバー、データベースサーバー、１つまたはそれ以上のフラットファイルまたは他のデータ構造を格納するサーバー（例えばＸＭＬ）、あるいはネットワーク１５０に通信可能に連結された他のデバイスなどのディレクトリサーバー実施態様の１つまたはそれ以上のホストであり得る。ディレクトリサーバー１４０（１）−（Ｎ）は、アプリケーションデータ、バックアップデータ、または他のデータを記憶するための記憶デバイス１６０（１）−（Ｎ）のうちの１つまたはそれ以上を利用し得る。ディレクトリサーバー１４０（１）−（Ｎ）のうちの１つまたはそれ以上は、アプリケーションサーバーなど、クライアント１１０、１２０、および１３０に対するデータリクエストを処理し得るホストであり得る。
いくつかの実施形態によれば、ネットワーク１８０は、インターネットを表し得る。そしてネットワークデバイス１７０は、企業ＷＡＮまたはＬＡＮであり得るネットワーク１５０とネットワーク１８０との間の多量のデータトラフィックを扱うデバイスであり得る。例えば、ネットワークデバイス１７０のうちの１つまたはそれ以上は、メールゲートウェイ、ウェブゲートウェイ、あるいは、ユーザー認証および／または認可、識別情報管理、受信者の妥当性検証、アドレス解決、メッセージルーティング、アクセス制御、または他のアプリケーション挙動のためにディレクトリデータサービスを使用する別の機器またはアプリケーションであり得る。非制限的な例として、ネットワークデバイス１７０のうちの１つまたはそれ以上が、Ｓｙｍａｎｔｅｃ（登録商標） Ｂｒｉｇｈｔｍａｉｌ（登録商標） Ｇａｔｅｗａｙ、Ｓｙｍａｎｔｅｃ（登録商標） Ｗｅｂ Ｇａｔｅｗａｙ、Ｓｙｍａｎｔｅｃ（登録商標） Ｄａｔａ Ｌｏｓｓ Ｐｒｅｖｅｎｔｉｏｎ Ｈｏｓｔ、Ｓｙｍａｎｔｅｃ（登録商標） Ｅｎｄｐｏｉｎｔ Ｐｒｏｔｅｃｔｉｏｎ Ａｐｐｌｉｃａｔｉｏｎ、またはＢｒｉｇｈｔｍａｉｌ（登録商標） Ｍｅｓｓａｇｅ Ｆｉｌｔｅｒであり得る。ネットワークデバイス１７０のうちの１つまたはそれ以上は、ディレクトリデータサービス１５４を使用して、１つまたはそれ以上のディレクトリサーバーからのキャッシュデータを管理する。いくつかの実施形態によれば、各ネットワークデバイス１７０は、自身のデータをキャッシュし得る。１つまたはそれ以上の実施形態によれば、キャッシュデータは、ネットワークデバイス１７０のうちの２つまたはそれ以上の間で共有され得る。例えば、ネットワークデバイス１７０（１）は、複数のＢｒｉｇｈｔｍａｉｌ Ｇａｔｅｗａｙスキャナのコントロールセンターホストであり得る。コントロールセンターホストは、Ｂｒｉｇｈｔｍａｉｌ Ｇａｔｅｗａｙスキャナであり得る複数の他のネットワークデバイス１７０間で共有されるキャッシュディレクトリサービスデータを含み得る。キャッシュデータは、ネットワークデバイス１７０に記憶され得るか、あるいはネットワークデバイス１７０に通信可能に連結された電子記憶装置に記憶され得る。
ディレクトリデータサービス１５４は、ネットワークデバイスの構成要素、モジュール、あるいは、ディレクトリデータキャッシュ動作を管理するために統合されたハードウェアおよびソフトウェアの別の組み合わせであり得る。いくつかの実施形態によれば、ディレクトリデータサービス１５４は、高スループット処理用のディレクトリデータサービスを使用して、ゲートウェイ機器あるいは別の装置またはアプリケーションとのディレクトリ統合を行うための統一サービス指向アーキテクチャを提供し得る。
ディレクトリデータサービス１５４は、例えばディレクトリサーバー１４０（１）などのディレクトリサーバーからキャッシュデータを管理できるようにし得る。ディレクトリデータサービス１５４は、ディレクトリデータのリクエストも管理し得る。データをキャッシュすることにより、メールゲートウェイなどのネットワークデバイスの動作が高速化され得るし、１つまたはそれ以上のディレクトリサーバー１４０からの負担が軽減され得る。ただし、初期キャッシュをビルドすると、負荷が大きくなる可能性がある。１つまたはそれ以上の実施形態によれば、ディレクトリデータサービス１５４は、ネットワークデバイスによって使用される前に、キャッシュされたディレクトリデータを事前に読み込み得る。キャッシュデータは、（例えば、ディレクトリサーバーで行われた可能性のあるディレクトリデータに対する変更を省略するなど）「陳腐化」しないように周期的にリフレッシュされる必要があり得る。多数のキャッシュエントリは、同時に、あるいは同じ短時間内に作成され得る。同じ生存時間（ＴＴＬ）、またはキャッシュエントリの期限切れを決定する他の同様の設定を用いて多数のキャッシュエントリを設定すると、短時間に多数のキャッシュエントリをリフレッシュするために、ディレクトリサーバーに多数のクエリが出される可能性がある。この好ましくない挙動は、ディレクトリサーバーおよび／またはディレクトリサーバーを使用するアプリケーションまたはデバイスにおけるスパイク、性能障害、あるいは他の好ましくない挙動の原因となり得る。
本開示の１つまたはそれ以上の実施形態によれば、同じ時点で多数のキャッシュエントリがディレクトリサーバーにリフレッシュリクエスト（例えば、ＬＤＡＰ対応ディレクトリサーバーに対するＬＤＡＰクエリ）に課せられることのないように、キャッシュエントリの期限（例えばＴＴＬ設定）は多様であり得る。例えば、複数のキャッシュディレクトリエントリの許容期限の範囲を決定する１つまたはそれ以上のパラメータが、管理者によって設定され得る。ディレクトリデータサービス１５４は、ユーザーインターフェースを提供し得るし、かつ／または設定されたパラメータを受容し得る。ディレクトリデータサービスからキャッシュディレクトリエントリが作成されると、そのエントリは、ディレクトリデータサービス１５４によって作成時刻が割り当てられ得る。キャッシュディレクトリエントリは、ディレクトリデータサービス１５４によって１つまたはそれ以上のランダム値が割り当てられ得る。１つまたはそれ以上のランダム値は、キャッシュディレクトリエントリの期限（例えば生存時間（ＴＴＬ））を許容期限の範囲内で決定し得る。複数のキャッシュディレクトリエントリの許容期限の範囲内でキャッシュディレクトリエントリの期限をランダム化することにより、ある時点でネットワークデバイス１７０のキャッシュメモリとディレクトリサーバー１４０との間で必要とされる同期の量（例えばリフレッシュリクエスト）が減少し得る。そのため、キャッシュエントリは、ディレクトリサーバーでパフォーマンススパイクまたは他の性能低下が起こらないように、ＴＴＬ設定を、許容される生存時間設定の範囲全体に分散させ得る。
いくつかの実施形態によれば、管理者または他のユーザーは、最大生存時間パラメータおよび最小生存時間パラメータを設定することによってキャッシュディレクトリエントリの許容期限の範囲を決定してもよい。キャッシュエントリは、最大生存時間パラメータおよび最小生存時間パラメータによって決定される範囲内で期限満了日または生存時間設定が割り当てられ得る。生存時間設定は、キャッシュディレクトリエントリの作成時に設定されてもよい。他の実施形態によれば、管理者または他のユーザーは、生存時間パラメータおよび生存時間分散パラメータを設定することによってキャッシュディレクトリエントリの許容期限の範囲を決定してもよい。生存時間分散パラメータは、キャッシュディレクトリエントリが生存時間パラメータから変動し得る最大量を決定し得る。例えば、生存時間分散パラメータは、パーセンテージ（例えば０％と１００％との間のパーセンテージ）で表され得る。生存時間分散パラメータは、小数に変換され、１から減算され、その後ＴＴＬによって乗算されて最小ＴＴＬを決定し得る。次に生存時間分散パラメータは、小数に変換され、１に加算され、その後ＴＴＬによって乗算されて最大ＴＴＬを決定し得る。他の方法およびパラメータは、個々のキャッシュエントリのＴＴＬ設定を分散させる生存時間設定の範囲を特定または決定する目的で使用され得る。いくつかの実施形態によれば、ＴＴＬ範囲、ＴＴＬ、またはＴＴＬ分散は、１つまたはそれ以上の要因に基づいて増減し得る。例えば、ＴＴＬおよび／またはＴＴＬの範囲は、キャッシュサイズ、ディレクトリサーバーの負荷または他の要因に基づいて増減し得る。ディレクトリデータソースは、特定のディレクトリサーバーに接続し、問い合わせる方法を指定し得るディレクトリデータサービス（ＤＤＳ）の構成であり得る。１つまたはそれ以上の実施形態によれば、ＴＴＬ範囲は、ディレクトリデータソースに基づいて異なり得る。例えば、キャッシュの一部分が第１のディレクトリデータソースと関連付けられており、第２のキャッシュの一部分が第２のディレクトリデータソースと関連付けられている場合、異なる部分には異なるＴＴＬ範囲が割り当てられ得る。
いくつかの実施形態によれば、キャッシュエントリの期限が切れたかどうかは、キャッシュエントリの作成時刻からの経過時間を計算し、その経過時間をエントリの生存時間（ＴＴＬ）と比較することによって判断され得る。例えば、経過時間は次式で計算され得る。
ｅｌａｐｓｅｄ＝（ｃｕｒｒｅｎｔＴｉｍｅ−ｃｒｅａｔｉｏｎＴｉｍｅ）×１０００；／／秒
上述のとおり、キャッシュエントリのＴＴＬを計算する目的で使用されるいくつかの異なるアルゴリズムが存在し得る。例えば、エントリの生存時間（ｅｎｔｒｙＴＴＬ）は次式で計算され得る。
ｅｎｔｒｙＴＴＬ＝ｍｉｎＴＴＬ＋（（ｍａｘＴＴＬ−ｍｉｎＴＴＬ）×（ｔｔｌＳｐｒｅａｄＦａｃｔｏｒ／１００．０））；／／秒
ｔｔｌＳｐｒｅａｄＦａｃｔｏｒは、０と１００（両端値を含む）間のランダム数（例えば５０）であり得る。ＭｉｎＴＴＬは、キャッシュエントリの最小生存時間を表し、最大ＴＴＬはエントリの最大生存時間を表し得る。したがって、ＭｉｎＴＴＬおよびＭａｘＴＴＬは許容範囲を判断し得る。そしてｔｔｌＳｐｒｅａｄｆａｃｔｏｒは、その範囲に沿ってキャッシュエントリを分散させる目的で使用されるランダム数であり得る。
経過時間およびキャッシュエントリの生存時間が決定されたら、期限の判断は以下のようになり得る。
ｉｓＥｘｐｉｒｅｄ＝（ｅｌａｐｓｅｄ＞ｅｎｔｒｙＴＴＬ）
キャッシュエントリの期限が切れている場合には、ディレクトリデータサービス１５４が、ディレクトリサーバーに問い合わせること（例えば、ＬＤＡＰ対応ディレクトリサーバーに対するＬＤＡＰクエリ）によってキャッシュエントリのリフレッシュを試行し得る。キャッシュエントリは、キャッシュで受信され、新たに設定された作成時刻と新たに計算されたＴＴＬとを用いて更新または作成され得る。
いくつかの実施形態によれば、キャッシュディレクトリエントリの期限が切れており、対応するディレクトリサーバーが利用できない場合、キャッシュディレクトリエントリは、たとえ期限が切れていても、リクエストを受けて提供され得る。ディレクトリサーバーが別のディレクトリサーバー（例えば、同じディレクトリエントリを含むディレクトリサーバー）に対して冗長である場合には、ディレクトリサーバーに対するクエリが第１のサーバーから第２のサーバーにフェイルオーバーされ得る。例えば、冗長ディレクトリサーバーにフェイルオーバーするには、ラウンドロビンＤＮＳ（ドメイン名サーバー）方式が使用され得る。いくつかの実施形態によれば、ロードバランシングおよび／またはフェイルオーバーは、ディレクトリサーバー（例えばＬＤＡＰ）ティアで実施され得る。１つまたはそれ以上の実施形態によれば、データアクセスの失敗（例えば、ネットワークの問題や、ディレクトリサーバーの停止）が発生したときに、ディレクトリデータサービス１５４は、キャッシュが利用可能であれば、キャッシュからのデータで以てリクエストにサービスする。このため、サイズ限度を超えない限り、データソースキャッシュからデータが削除されることはない。例えば、いくつかのデータアクセスの失敗が短時間で検出された場合に開始し得る高速フェイルオーバーモードが存在し得る。このモードでは、キャッシュデータが利用可能であれば、期限が切れているかどうかに関係なく、データソースに直ちにキャッシュデータにサービスし得るか、あるいは、データアクセスコールのオーバーヘッドを受けることなく、直ちに失敗させて例外処理（例えばＤａｔａＡｃｃｅｓｓＵｎａｖａｉｌａｂｌｅＥｘｃｅｐｔｉｏｎ）を実行し得る。これにより、ディレクトリデータサービス１５４は、ディレクトリサーバーのリソースが利用できない場合でも高スループットを維持することができ得る。一実施形態によれば、ディレクトリデータサービス１５４の高速フェイルオーバー構成は、以下のように実装され得る。
データアクセスの失敗が１２０秒間で５回検出されたら、３００秒間の高速フェイルオーバーに切り替わる。特定のリクエストについて、フェイルオーバー先のキャッシュデータが存在しない場合、ディレクトリデータサービス（ＤＤＳ）コールが一時エラーで失敗し得る。受信者の妥当性検証の場合、かかる一時エラーはＳＭＴＰ（シンプルメールトランスファープロトコル）エラーとなる可能性があり、上流の送信者にそのメッセージを再試行するように命令し得る。他の機能の場合、これらのエラーにより、メッセージが各種内部ＭＴＡ（メッセージトランスファーエージェント）キューに残る可能性があり、そこで再試行され得る。
いくつかの実施形態によれば、キャッシュデータは、冗長ディレクトリデータソースに優先し得る。ディレクトリデータソースとキャッシュとの間での優先順位は設定可能であってよい。例えば、ＳｏｕｒｃｅＡおよびＳｏｕｒｃｅＢという２つの同一の受信者妥当性検証ソースを用いてシステムが構成された場合を考えてみる。ここではＳｏｕｒｃｅＡがクエリ順序における最初のソースである。通常の状況下では、有効な受信者に対してＳｏｕｒｃｅＡだけが問い合わせられ得る。早期終了およびスティッキーリフレッシュにより、それらの受信者がＳｏｕｒｃｅＢにアクセスしないようにし得る。早期終了とは、検索結果の一意性を検証することなく、複数のデータソースを用いて構成されたディレクトリデータサービスに対する検索を終了することであり得る（例えば、受信者の妥当性検証の場合、リクエストされたディレクトリエントリが見つかる最初のデータソースで検索が停止し得る）。スティッキーリフレッシュとは、キャッシュ内のディレクトリエントリが特定のデータソースと関連付けられており、ディレクトリエントリの期限が切れたときに、ディレクトリデータサービスが、そのデータソースからのディレクトリエントリのリフレッシュを試行するように定義された設定のことであり得る（例えば、ディレクトリエントリが同じデータソースからリフレッシュされ得る限り、システム内の他のデータソースは問い合わせられない）。通常の状況下では、無効な受信者に対して両方のソースが問い合わせられ得る。ＳｏｕｒｃｅＡが停止している場合には、キャッシュされた有効な受信者に対してＳｏｕｒｃｅＡのキャッシュからサービスされ得るため、ＳｏｕｒｃｅＢが参照されない場合がある。ＳｏｕｒｃｅＡが停止している場合、キャッシュされていない有効な受信者はＳｏｕｒｃｅＢからサービスされ得る。スティッキーリフレッシュにより、キャッシュされていない有効な受信者はその後もＳｏｕｒｃｅＢからサービスされ得る。ＳｏｕｒｃｅＡが停止している場合、キャッシュされているが期限が切れていない無効な受信者は、通常の状況下と同様に扱われ得る。ＳｏｕｒｃｅＡが停止している場合、キャッシュされた無効な受信者、あるいはキャッシュされているが期限が切れている無効な受信者は、リクエスタに後で再試行するように命令するエラーをもたらし得る。２つのディレクトリデータソースは、冗長あるいは非連結であり得るため、受信者は、停止中のディレクトリデータソース（例えばソースＡ）で有効であり、他のどのソースにも見つからない場合でも無効でない可能性がある。
いくつかの実施形態によれば、ＳｏｕｒｃｅＢが停止している場合には、キャッシュされた有効な受信者がＳｏｕｒｃｅＡのキャッシュからサービスされ得るため、ＳｏｕｒｃｅＢが参照されない場合がある。ＳｏｕｒｃｅＢが停止している場合、キャッシュされていない有効な受信者はＳｏｕｒｃｅＡからサービスされ得る。早期終了およびスティッキーリフレッシュにより、キャッシュされていない有効な受信者はその後もＳｏｕｒｃｅＡからサービスを提供され得る。ＳｏｕｒｃｅＢが停止している場合、キャッシュされているが期限が切れていない無効な受信者は、通常の状況下と同様に扱われ得る。
ＳｏｕｒｃｅＢが停止している場合、キャッシュされた無効な受信者、あるいはキャッシュされているが期限が切れている無効な受信者は、リクエスタに後で再試行するように命じるエラーをもたらし得る。
ディレクトリデータソースが停止していても、利用可能であれば、キャッシュデータにフェイルオーバーし得る。ディレクトリデータサービス１５４は、データアクセスエラーを記録して、データアクセスアラートを生成し得る。ただし、ディレクトリデータサービス１５４は、引き続き他のデータソースを検索してもよい。一意のエントリが健全なソースのうちの１つに見つかれば、そのコールは成功する可能性があり、スティッキーリフレッシュは、そのエントリを求める以降の要求をそのソースに向け得る。１つより多くのエントリが見つかった場合には、重複エラーが記録され得る。そして、ディレクトリデータサービス１５４は、データ整合アラートを生成し得る。一致するエントリが見つからない場合には、リクエストが一時エラーで失敗し、再試行され得る。
いくつかの実施形態によれば、ディレクトリデータサービス１５４は、１つまたはそれ以上のデータ整合エラーまたは他のエラーを検出し得る。そして、そのエラーと関連付けられた記録および／またはアラート通知を提供し得る。例えば、ディレクトリデータサービス１５４は、処理中にデータエラーに遭遇し得る。そしてエラーを記録し、かつ／またはアラートを管理者に提供し得る。検出されたエラーは、非制限的な例として、電子メールアドレスの重複、ユーザー名重複、行方不明または無効な属性データ（例えば、行方不明の電子メールアドレス、無効な電子メールアドレスフォーマット、存在しないエントリを参照しているグループメンバーシップ属性、および下位および上位グループメンバーシップ属性の不整合値）、および循環グループ関係を含み得る。ディレクトリデータサービス１５４は、各種ディレクトリデータと統合し得る。例えば、ディレクトリデータサービス１５４は、ＬＤＡＰディレクトリ、ＳＱＬデータベース、および／またはフラットファイルを格納しているサーバーであり得るディレクトリサーバー１４０（１）．．．（Ｎ）にアクセスし得る。ディレクトリデータサービス１５４は、電子メールアドレスまたは他のデータを探すディレクトリサーバー（例えばＬＤＡＰクエリ）にアクセスし得る。受信したデータに基づいて、ディレクトリデータサービス１５４はデータ整合エラーを検出し得る。受信した電子メールアドレスが、単一のデータソースに、または複数のデータソースにまたがって存在する複数のディレクトリエントリに対応し得るか、あるいはユーザー名が、単一のデータソースに、または複数のデータソースにまたがって存在する複数のディレクトリエントリに対応し得る。いくつかの実施形態によれば、データ整合エラーに加え、ディレクトリデータサービス１５４によって扱われる他のエラーとしては、ディレクトリデータアクセスエラー（例えば、ＬＤＡＰサーバーからデータを読み込めなかった）、過小データソースキャッシュエラー（例えば、データソースキャッシュまたはキャッシュインデックスが、リクエストされたメモリ内データのすべてを保持できるだけの大きさがないことを示している）、および／またはデータ複製エラー（データ複製動作が失敗したことを示している）を含み得る。
ディレクトリデータサービス１５４は、ディレクトリサーバーデータアクセスアラートを提供し得る。このタイプのアラートは、ディレクトリデータサービス１５４がディレクトリサーバー（例えばＬＤＡＰサーバー）からデータを読み込めない場合にトリガーされ得る。これは、様々な理由で起こり得る。いくつかの例は、ＬＤＡＰサーバーの停止、ネットワークインフラストラクチャの問題、ＤＮＳの問題、ファイアウォールルールのブロックリクエスト、不良データソース管理バインド証明書、および／またはＬＤＡＰ検索タイムアウトを含み得る。
ディレクトリデータサービス１５４によって扱われる他のアラートは、ディレクトリサーバーデータ整合アラートを含み得る。このタイプのアラートは、リクエストが正常に実行されるのを妨げるディレクトリデータに関する問題をディレクトリデータサービス１５４が検出したときにトリガーされ得る。リクエストの失敗に至らないデータ整合の問題は、ディレクトリデータサービス１５４によって「警告」レベルで記録され得るため、アラートをトリガーしない場合がある。受信者の妥当性検証について、受信者アドレスでの検索に対して複数のエントリ（単一のデータソース内に、あるいは複数のソースにまたがって存在）が返された場合、このイベントは、ディレクトリデータサービス１５４によって「情報」レベルで記録され得るため、アラートが生成されない場合がある。複製された受信者は、受信者の妥当性検証機能上、有効であるとみなされ得る。
以下のデータ整合エラーは、アラートをトリガーし得る。
電子メールアドレス（単一のデータソース内に、あるいは複数のソースにまたがって存在）での検索に対して１つより多くのエントリが返される。
ユーザー名（単一のデータソース内に、あるいは複数のソースにまたがって存在）での検索に対して１つより多くのエントリが返される。
以下のデータ整合問題は、ディレクトリデータサービス１５４によって「警告」レベルで記録され得るため、アラートをトリガーしない場合がある。循環グループ参照、無効なグループメンバーシップ属性値、行方不明のプライマリ電子メール属性値、および／または電子メールアドレス値の無効フォーマット。
循環グループ参照は、ディレクトリサーバーがグループメンバーシップを判断するために上から下へとトラバースしているときにディレクトリデータサービス１５４によって認識され得る。例えば、グループＡがグループＢのメンバーであり、グループＢがグループＡのメンバーである場合に、ディレクトリデータサービス１５４がこれを検出してエラーを記録し得る。グループの関係は、多数のレベルに及び深いネスト構造になっていることがあるために、循環グループ参照がいくつか下のレベルで発生し得る。例えば、グループが上位から下位にＡ〜Ｅのネスト構造になっていると仮定すると、グループＢがグループＥのメンバーである可能性があり、循環グループ参照をもたらし得る。いくつかの実施形態によれば、ツリー（すなわちグループ）の特定ノードが以前にアクセスされていると判断し得る再帰的ツリートラバースアルゴリズムが使用され得る。これが循環グループ参照を表し得る。循環グループ参照は、データソース（例えば単一のディレクトリサーバー）で、あるいはデータソースにまたがって検出され得る。
ディレクトリデータサービス１５４は、ＤＤＳキャッシュサイズアラートを提供し得る。このタイプのアラートは、ディレクトリデータサービス１５４が、データアクセス層から取り出された新規エントリ用のスペースを確保するために、期限が切れる前にキャッシュエントリを追い出すときにトリガーされ得る。管理者は、アラートおよびログステートメントを参照して適切な措置をとり得る。例示的なアラートは以下を含む。
Ｅｎｔｒｙ Ｃａｃｈｅ
修復方法：キャッシュサイズを増やす。
Ｒｅｃｉｐｉｅｎｔ Ｒｅｆ Ｃａｃｈｅ（電子メールアドレスに関するキャッシュインデックス）
修復方法：キャッシュインデックスサイズ乗数（すなわち、キャッシュインデックスサイズ＝（Ｎ×キャッシュサイズ）と設定するパラメータＮなど、キャッシュインデックスのサイズを決定するパラメータ）を増やす。
Ｕｓｅｒ Ｒｅｆ Ｃａｃｈｅ（ユーザー名に関するキャッシュインデックス）
修復方法：キャッシュインデックスサイズ乗数を増やす。
アラートファイルが、ホスト、特定タイプのアラート条件、およびトリガー事象の時期を伝達し得る。アラートテキストは、管理者に、システムログファイルを参照して追加診断情報を確認するよう促し得る。これにより、開発への影響を抑えつつ、アラート機能の変更または拡張が可能となり得る。
生成されたアラート電子メールは、以下の情報を含み得る。
アラートイベントのタイムスタンプ、
アラートイベントのホスト識別子、
アラートイベント（例えばディレクトリデータサービス１５４）を生成した構成要素、および
所定のディレクトリデータサービスステータスコードに対応するローカライズされたメッセージ。
ステータスコードは大雑把である可能性があり、特定のコードに至る可能性のある多数の潜在的なエラー状況が存在し得る。アラートメカニズムは、特定ホスト上のＤＤＳインスタンスが特定時期にリクエストを処理できなかったことを単に伝えるだけであり得る。そして根本原因についての詳細な情報はログを参照するように管理者に示し得る。
ＤＤＳデータアクセスアラート、ＤＤＳデータ整合アラート、ＤＤＳキャッシュサイズアラート、ユーザー設定複製アラート、または他のタイプのアラートのうちの１つまたはそれ以上のサブタイプを使用可能または使用不可にするためのユーザーインターフェース要素（例えばチェックボックス）が存在してもよい。
ディレクトリデータサービス１５４は、１つまたはそれ以上のデータ整合エラーまたは他のエラーを記録し得る。そしてアラートが別のメカニズムによって生成され得る。例えば、ディレクトリデータサービス１５４は、ディスク上、あるいは他の電子ストレージにアラートファイルを作成し得る。アラートファイルは、タイムスタンプと、アラート条件のタイプを表す識別子とを格納し得る。ネットワークデバイス１７０上で実行中のプロセスまたはエージェントが、周期的にアラートファイルをポーリングし、アラートメタデータを処理し、１人またはそれ以上のユーザー（例えば、登録されたシステム管理者）にアラート電子メールを送り得る。他の通信チャネルが、ＳＭＳテキストメッセージ、ボイスメール、および／またはウェブページ投稿などをユーザーに通知する目的で使用され得る。いくつかの実施形態によれば、ディレクトリデータサービス１５４は、追加プロセスまたはエージェントを使用せずに直接アラートを送り得る。１つまたはそれ以上の実施形態によれば、ディレクトリデータサービス１５４または別のプロセスが、インターフェースを使用して（例えば、ＳＮＭＰ、Ｗｉｎｄｏｗｓ Ｓｙｓｔｅｍ Ｅｖｅｎｔ、またはカスタムＩＰＣ（プロセス間通信）を介して）アラートを送り得る。
ディレクトリデータサービス１５４によるデータ整合エラーの検出およびシステム管理者への迅速なアラート通知により、システムの性能低下または故障が起きる前にシステム管理者が問題に対処することを可能にし得る。
図２は、本開示の一実施形態にかかるコンピュータシステム２００のブロック図を表す。コンピュータシステム２００は、本開示にかかる技法を実施するのに適している。コンピュータシステム２００は、中央プロセッサ２１４など、コンピュータシステム２１０の主要サブシステムを相互接続し得るバス２１２と、システムメモリ２１７（例えば、ＲＡＭ（ランダムアクセスメモリ）、ＲＯＭ（読み出し専用メモリ、フラッシュＲＡＭなど）と、入出力（Ｉ／Ｏ）コントローラ２１８と、音声出力インターフェース２２２を介するスピーカシステム２２０などの外部のオーディオデバイスと、ディスプレイアダプタ２２６を介するディスプレイスクリーン２２４などの外部デバイスと、シリアルポート２２８および２３０と、キーボード２３２（キーボードコントローラ２３３を介して仲介）と、記憶装置インターフェース２３４と、フロッピーディスク２３８を受容するように動作可能なフロッピーディスクドライブ２３７と、ファイバチャネルネットワーク２９０と接続するように動作可能なホストバスアダプタ（ＨＢＡ）インターフェースカード２３５Ａと、ＳＣＳＩバス２３９に接続するように動作可能なホストバスアダプタ（ＨＢＡ）インターフェースカード２３５Ｂと、光学ディスク２４２を受容するように動作可能な光学ディスクドライブ２４０と、を備え得る。また、マウス２４６（または他のポイントアンドクリックデバイス、シリアルポート２２８を介してバス２１２に連結）と、モデム２４７（シリアルポート２３０を介してバス２１２に連結）と、ネットワークインターフェース２４８（バス２１２に直接連結）と、電源マネージャ２５０と、バッテリ２５２と、も備え得る。
バス２１２は、上記のとおり、中央プロセッサ２１４とシステムメモリ２１７との間でのデータ通信を可能にする。システムメモリ２１７は、読み出し専用メモリ（ＲＯＭ）またはフラッシュメモリ（どちらも図示せず）と、ランダムアクセスメモリ（ＲＡＭ）（図示せず）とを含み得る。ＲＡＭは、オペレーティングシステムおよびアプリケーションプログラムが読み込まれ得るメインメモリであり得る。ＲＯＭまたはフラッシュメモリは、他のコードと共に、周辺構成要素との相互動作など、基本的なハードウェア動作を制御する基本入出力システム（ＢＩＯＳ）を格納することができる。コンピュータシステム２１０に存在するアプリケーションは、ハードディスクドライブ（例えば固定ディスク２４４）、光学ドライブ（例えば光学ドライブ２４０）、フロッピーディスクユニット２３７、または他の記憶媒体など、コンピュータ読み取り可能な媒体に記憶され、かかる媒体を介してアクセスされ得る。例えば、ディレクトリデータサービス１５４は、システムメモリ２１７に存在し得る。
記憶装置インターフェース２３４は、コンピュータシステム２１０の他の記憶装置インターフェースと同様、固定ディスクドライブ２４４など、情報を記憶および／または取得するための標準的なコンピュータ読み取り可能な媒体に接続することができる。固定ディスクドライブ２４４は、コンピュータシステム２１０の一部であってよく、あるいは別々になっており、他のインターフェースシステムを通じてアクセスされるようになっていてもよい。モデム２４７は、電話リンク経由でリモートサーバーとの、あるいはインターネットサービスプロバイダ（ＩＳＰ）経由でインターネットとの直接接続を提供し得る。ネットワークインターフェース２４８は、ＰＯＰ（通信アクセスポイント）を経由するインターネットとの直接ネットワークリンクを介してリモートサーバーとの直接接続を提供し得る。ネットワークインターフェース２４８は、デジタルセルラー方式電話接続、セルラー方式デジタルパケットデータ（ＣＤＰＤ）接続、デジタル衛星データ接続などを含む無線技法を用いてかかる接続を提供してもよい。
その他多くの装置またはサブシステム（明示せず）が、同様の方法（例えば、文書スキャナ、デジタルカメラなど）で接続されてもよい。逆に言えば、本開示を実施するのに、図２に示す装置のすべてが存在する必要はない。これらの装置およびサブシステムは、図２に示すものとは別の方法で相互接続することもできる。本開示を実装するコードは、システムメモリ２１７、固定ディスク２４４、光学ディスク２４２、またはフロッピーディスク２３８のうちの１つまたはそれ以上などのコンピュータ読み取り可能な記憶媒体に記憶され得る。本開示を実装するコードは、１つまたはそれ以上のインターフェースを介して受信され、メモリに記憶され得る。コンピュータシステム２１０に設けられるオペレーティングシステムは、ＭＳ−ＤＯＳ（登録商標）、ＭＳ−ＷＩＮＤＯＷＳ（登録商標）、ＯＳ／２（登録商標）、ＯＳ Ｘ（登録商標）、ＵＮＩＸ（登録商標）、Ｌｉｎｕｘ（登録商標）、または別の公知のオペレーティングシステムであり得る。
電源マネージャ２５０は、バッテリ２５２の電力レベルを監視し得る。電源マネージャ２５０は、電力レベルを判断できるようにするための１つまたはそれ以上のＡＰＩ（アプリケーションプログラミングインターフェース）、コンピュータシステム２００がシャットダウンするまでの残り時間窓、電力消費率、コンピュータシステムが電源（例えばＡＣ電源）かバッテリのどちらで稼働しているかを示すインジケータ、または他の電力関連情報を提供し得る。いくつかの実施形態によれば、電源マネージャ２５０のＡＰＩは、リモートアクセスが可能（例えば、ネットワーク接続経由でリモートバックアップ管理モジュールにアクセス可能）であり得る。いくつかの実施形態によれば、バッテリ２５２は、コンピュータシステム２００に対してローカルまたはリモートに位置する無停電電源装置（ＵＰＳ）であり得る。かかる実施形態では、電源マネージャ２５０がＵＰＳの電力レベルに関する情報を提供し得る。
図３を参照すると、本開示の一実施形態にかかるディレクトリデータサービスモジュール１５４が示されている。図示のとおり、ディレクトリデータサービスモジュール１５４は、ディレクトリデータサービス（ＤＤＳ）キャッシュ管理モジュール３１２、ディレクトリデータサービス整合管理モジュール３１４、ディレクトリデータサービスグループメンバーシップ管理モジュール３１６、ディレクトリデータサービスクエリ一般化モジュール３１８、およびエラー記録およびレポートモジュール３２０を含む１つまたはそれ以上の構成要素を格納し得る。
下記の記述は、ネットワーク要素、コンピュータ、および／または１つまたはそれ以上のモジュールを含み得る、ディレクトリサーバーを統合するためシステムおよび方法の構成要素について記載している。本明細書で使用されるとおり、「モジュール」という用語は、計算ソフトウェア、ファームウェア、ハードウェア、および／またはそれらの各種組み合わせを言及するものと理解され得る。ただし、モジュールは、ハードウェアやファームウェアに実装されたり、プロセッサ読み取り可能な記録可能記憶媒体に記録されたりすることのないソフトウェアと解釈されるべきでない（すなわち、モジュール自体はソフトウェアでない）。なお、モジュールは例示的なものである。モジュールは、各種アプリケーションをサポートするために組み合わせ、統合、分離、および／または複製され得る。また、本明細書において特定のモジュールで実行中であると記載されている機能は、１つまたはそれ以上の他のモジュールで、および／または特定のモジュールで実行され得る機能の代わりに、あるいはその機能に加えて１つまたはそれ以上の他のデバイスによって実行され得る。さらに、モジュールは、互いにローカルであり、かつ／またはリモートである複数のデバイスまたは他の構成要素にまたがって実装され得る。加えて、モジュールは、あるデバイスから移動させて別の装置に追加してもよく、かつ／または両方のデバイスに含まれてもよい。
ディレクトリデータサービス（ＤＤＳ）キャッシュ管理モジュール３１２は、キャッシュ管理のうちの１つまたはそれ以上の態様を扱い得る。例えば、ＤＤＳキャッシュ管理モジュール３１２は、ＴＴＬ設定、ＴＴＬ範囲、または他のキャッシュ期限パラメータを受信、計算、および／または設定し得る。ＤＤＳキャッシュ管理モジュール３１２は、１つまたはそれ以上のＴＴＬパラメータ、キャッシュエントリの作成時刻、作成時刻からの経過時間、および／または他の要因に基づいてキャッシュエントリを期限切れにする時期を判断し得る。ＤＤＳキャッシュ管理モジュール３１２は、データソースキャッシュおよびキャッシュインデックスのキャッシュサイズ限度およびキャッシュエントリ追い出しポリシーを確立し得る。キャッシュインデックスサイズは、１つまたはそれ以上のパラメータ（例えば、キャッシュインデックスのサイズを、関連付けられたデータソースキャッシュの単純な倍数と定め得るキャッシュインデックス乗数パラメータ）によって判断され得る。
ＤＤＳキャッシュ管理モジュール３１２は、１つまたはそれ以上の設定および／または検出された状況に基づいてフェイルオーバー挙動を判断し得る。ＤＤＳキャッシュ管理モジュール３１２は、データソースおよび／またはキャッシュ間での優先順位の設定を受信、設定、および／または実施し得る。
ディレクトリデータサービス整合管理モジュール３１４は、１つまたはそれ以上のデータ整合エラーまたは他のエラーを検出し得る。そして、そのエラーと関連付けられた記録またはアラート通知を提供し得る。例えば、ディレクトリデータサービス整合管理モジュール３１４は、処理中にデータエラーに遭遇し得る。そしてエラーを記録し、かつ／またはアラートを管理者に提供し得る。検出されたエラーは、非制限的な例として、電子メールアドレスの重複、ユーザー名重複、行方不明または無効な属性データ（例えば、行方不明の電子メールアドレス、無効な電子メールアドレスフォーマット、存在しないエントリを参照しているグループメンバーシップ属性、および下位および上位グループメンバーシップ属性の不整合値）、および循環グループ関係を含み得る。ディレクトリデータサービス整合管理モジュール３１４は、各種ディレクトリデータと統合し得る。例えば、ディレクトリデータサービス整合管理モジュール３１４は、ＬＤＡＰディレクトリ、ＳＱＬデータベース、および／またはフラットファイルを格納しているサーバーであり得るディレクトリサーバー１４０（１）．．．（Ｎ）にアクセスし得る。ディレクトリデータサービス整合管理モジュール３１４は、ディレクトリエントリまたは他のデータを探すディレクトリサーバーに（例えばＬＤＡＰクエリ経由で）アクセスし得る。受信したデータに基づいて、ディレクトリデータサービス整合管理モジュール３１４はデータ整合エラーを検出し得る。例えば、電子メールアドレスまたはユーザー名での検索は、単一のデータソースにある複数のディレクトリエントリに対応し得る。もしくは、ユーザー名が、単一のデータソースにある、あるいは複数のデータソースにまたがる複数のディレクトリエントリに対応し得る。いくつかの実施形態によれば、データ整合エラーに加えて、ディレクトリデータサービス整合管理モジュール３１４によって認識される他のエラーは、ディレクトリデータアクセスエラー（例えば、ＬＤＡＰサーバーからデータを読み込めなかった）、過小データソースキャッシュエラー（例えば、データソースキャッシュまたはキャッシュインデックスが、リクエストされたメモリ内データのすべてを保持できるだけの大きさがないことを示している）、および／またはデータ複製エラー（データ複製動作が失敗したことを示している）を含み得る。
循環グループ参照は、ディレクトリサーバーがグループメンバーシップを判断するために上から下へとトラバースしているときにディレクトリデータサービス整合管理モジュール３１４によって認識され得る。例えば、グループＡがグループＢのメンバーであり、グループＢがグループＡのメンバーである場合に、ディレクトリデータサービス整合管理モジュール３１４がこれを検出してエラーを記録し得る。グループの関係は、多数のレベルに深いネスト構造になっていることがあるために、循環グループ参照がいくつか下のレベルで発生し得る。例えば、グループが上位から下位にＡ〜Ｅのネスト構造になっていると仮定すると、グループＢがグループＥのメンバーである可能性があり、循環グループ参照をもたらし得る。いくつかの実施形態によれば、ツリー（すなわちグループ）の特定ノードが以前にアクセスされていると判断し得る再帰的ツリートラバースアルゴリズムが使用され得る。これが循環グループ参照を表し得る。循環グループ参照は、単一のデータソース内、あるいは複数のデータソースにまたがって検出され得る。
ディレクトリデータサービス整合管理モジュール３１４は、１つまたはそれ以上のデータ整合エラーまたは他のエラーを記録し得る。そしてアラートが別のメカニズムによって生成され得る。例えば、ディレクトリデータサービス整合管理モジュール３１４は、ディスク上、あるいは他の電子ストレージにアラートファイルを作成し得る。アラートファイルは、タイムスタンプと、アラート条件のタイプを表す識別子を格納し得る。ネットワークデバイス１７０上で実行中のプロセスまたはエージェントが、周期的にアラートファイルをポーリングし、アラートメタデータを処理し、１人またはそれ以上のユーザー（例えば、登録されたシステム管理者）にアラート電子メールを送り得る。他の通信チャネルが、ＳＭＳテキストメッセージ、ボイスメール、および／またはウェブページ投稿などをユーザーに通知する目的で使用され得る。いくつかの実施形態によれば、ディレクトリデータサービス１５４は、別のプロセスまたはエージェントを使用せずに直接アラートを送ってもよい。１つまたはそれ以上の実施形態によれば、ディレクトリデータサービス整合管理モジュール３１４または別のプロセス、構成要素、あるいはモジュールが、インターフェースを使用して（例えば、ＳＮＭＰ、Ｗｉｎｄｏｗｓ Ｓｙｓｔｅｍ Ｅｖｅｎｔ、またはカスタムＩＰＣ（プロセス間通信）を介して）アラートを送ってもよい。
ディレクトリデータサービス整合管理モジュール３１４によるデータ整合エラーの検出およびシステム管理者への迅速なアラート通知により、システムの性能低下または故障が起きる前にシステム管理者が問題に対処することを可能にし得る。
ディレクトリデータサービスグループメンバーシップ管理モジュール３１６は、グループのメンバーを特定するために、１つまたはそれ以上のディレクトリデータソースをトラバースし得る。ディレクトリデータサービスグループメンバーシップ管理モジュール３１６は、上位グループメンバーシップ、下位グループメンバーシップ、またはそれらの両方を解決し得る。
ディレクトリデータサービスクエリ一般化モジュール３１８により、ディレクトリサーバーに対するクエリ（例えばＬＤＡＰクエリ）が、クエリフィルタトークンまたは他のメカニズムを使用して、電子メールエイリアスの一致を含むがこれに限定されない様々なディレクトリ検索基準を規定できるようになり得る。クエリフィルタトークンとエイリアスとの一致については、図８と関連させて、以下でさらに詳述されている。
エラー記録およびレポートモジュール３２０は、ディレクトリサーバーを統合に関連するログ、レポート、または他の情報を生成し得る。
図４を参照すると、本開示の一実施形態にかかるディレクトリサーバーを統合するための方法４００が示されている。図４は、ディレクトリサーバー統合を高レベルで表している。例えば、エントリがディレクトリサーバーに存在するかどうかを判断するためのテストなど、他の要素が追加されてもよい。ブロック４０２で、方法４００が開始され得る。
ブロック４０４で、方法によって生存時間範囲が割り当てられ得る。生存時間範囲は、管理者により、１つまたはそれ以上のパラメータを使用して指定され得る。いくつかの実施形態によれば、管理者または他のユーザーは、最大生存時間パラメータおよび最小生存時間パラメータを設定することにより、キャッシュディレクトリエントリの許容期限の範囲を決定してもよい。キャッシュエントリは、最大生存時間パラメータおよび最小生存時間パラメータによって決定される範囲内で期限満了日または生存時間設定が割り当てられ得る。生存時間設定は、キャッシュディレクトリエントリの作成時に設定されてもよい。他の実施形態によれば、管理者または他のユーザーは、生存時間パラメータおよび生存時間分散パラメータを設定することによってキャッシュディレクトリエントリの許容期限の範囲を決定してもよい。生存時間分散パラメータは、キャッシュされたディレクトリが生存時間パラメータから変動し得る最大量を決定し得る。例えば、生存時間分散パラメータは、パーセンテージ（例えば０％と１００％との間のパーセンテージ）で表され得る。生存時間分散パラメータは、小数に変換され、１から減算され、その後ＴＴＬによって乗算されて最小ＴＴＬを決定し得る。次に生存時間分散パラメータは、小数に変換され、１に加算され、その後ＴＴＬによって乗算されて最大ＴＴＬを決定し得る。他の方法およびパラメータは、個々のキャッシュエントリのＴＴＬ設定を分散させる生存時間設定の範囲を特定または決定する目的で使用され得る。
ブロック４０６で、ディレクトリエントリのリクエストが受信され得る。例えば、ゲートウェイが、受信者の妥当性検証、メッセージルーティング、認証、ポリシーの適用、疑わしいスパム電子メールの隔離、または他の目的でディレクトリデータをリクエストし得る。
ブロック４０８で、リクエストされたディレクトリエントリがキャッシュされたかどうかが判断され得る。リクエストされたディレクトリエントリがキャッシュされている場合には、方法がブロック４１０で続行し得る。リクエストされたディレクトリエントリがキャッシュされていない場合には、方法がブロック４１４で続行し得る。
ブロック４１０で、方法４１０により、エントリの期限が切れているかどうかが判断され得る。いくつかの実施形態によれば、キャッシュエントリの期限が切れているかどうかは、キャッシュエントリの作成時刻からの経過時間を計算し、キャッシュディレクトリエントリの経過時間を生存時間設定と比較することによって判断され得る。キャッシュエントリのＴＴＬを計算する目的で使用されるいくつかの異なるアルゴリズムが存在し得る。例えば、エントリの生存時間（ｅｎｔｒｙＴＴＬ）は次式で計算され得る。
ｅｎｔｒｙＴＴＬ＝ｍｉｎＴＴＬ＋（（ｍａｘＴＴＬ−ｍｉｎＴＴＬ）×（ｔｔｌＳｐｒｅａｄＦａｃｔｏｒ／１００．０））；／／秒
ｔｔｌＳｐｒｅａｄＦａｃｔｏｒは、０と１００（両端値を含む）間のランダム数（例えば５０）であり得る。ＭｉｎＴＴＬは、キャッシュエントリの最小生存時間を表し、最大ＴＴＬはエントリの最大生存時間を表し得る。したがって、ＭｉｎＴＴＬおよびＭａｘＴＴＬは許容範囲を判断し得る。そしてｔｔｌＳｐｒｅａｄｆａｃｔｏｒは、その範囲に沿ってキャッシュエントリを分散させる目的で使用されるランダム数であり得る。
ブロック４１２で、キャッシュエントリの期限が切れていない場合には、リクエストに対応するためにキャッシュされたエントリ情報が提供され得る。
ブロック４１４で、ディレクトリサーバーにアクセス可能かどうかが判断され得る。ディレクトリサーバーにアクセス可能である場合、方法はブロック４１６で続行し得る。ディレクトリサーバーにアクセス可能でない場合、方法はブロック４２４で終了し得る。いくつかの実施形態（点線によって明示）によれば、ディレクトリサーバーにアクセス可能でない場合には、キャッシュされたエントリ情報がブロック４１２で提供され得る。例えば、図１に関して上記のとおり、いくつかのデータアクセスの失敗が短時間で検出された場合に開始し得る高速フェイルオーバーモードが存在し得る。このモードでは、キャッシュデータが利用可能であれば、期限が切れているかどうかに関係なく、データソースに直ちにキャッシュデータにサービスし得るか、あるいは、データアクセスコールのオーバーヘッドを受けることなく、直ちに失敗させて例外処理（例えばＤａｔａＡｃｃｅｓｓＵｎａｖａｉｌａｂｌｅＥｘｃｅｐｔｉｏｎ）を実行し得る。
ブロック４１６で、ディレクトリサーバーまたはソースからディレクトリエントリが取り出され、キャッシュディレクトリエントリが作成され得る。
ブロック４１８で、キャッシュディレクトリエントリに作成時刻が割り当てられ得る。
ブロック４２０で、キャッシュディレクトリエントリの生存時間（ＴＴＬ）を判断し得るキャッシュディレクトリエントリに絶対ランダム値が割り当てられ得る。ランダム値は、管理者によって指定された範囲内でＴＴＬを割り当て得る。いくつかの実施形態によれば、ランダム値を割り当てる他の方法が使用されてもよい。図５に関して後述するとおり、生存時間（ＴＴＬ）分布係数が使用されもよい。
ブロック４２２で、リクエストを受けてディレクトリエントリ情報が返され得る。
ブロック４２４で、方法４００が終了し得る。
図５を参照すると、本開示の一実施形態にかかるディレクトリサーバーを統合するための方法５００が示されている。ブロック５０２で、方法５００が、ディレクトリオブジェクトのリクエストから開始され得る。
ブロック５０４で、リクエストがＬＤＡＰ識別名（ＤＮ）（例えば、「ｕｓｅｒｉｄ＝ｊｍｓｍｉｔｈ、ｄｃ＝ｄｏｍａｉｎ、ｄｃ＝ｃｏｍ」）で検索しているかどうかが判断され得る。リクエストが識別名を使用して検索している場合、方法はブロック５２８で続行し得る。リクエストが別の属性（例えば、電子メールアドレス「ｊｓｍｉｔｈ＠ｄｏｍａｉｎ．ｃｏｍ」またはユーザー名「ｊｓｍｉｔｈ」）を使用して検索している場合、方法はブロック５０６で続行し得る。
ブロック５０６で、識別名以外の属性を使用して検索するためにキャッシュインデックスが使用され得る。
ブロック５０８で、エントリがキャッシュインデックスに見つかったかどうかが判断され得る。対応するエントリが見つかった場合、方法はブロック５２２で続行し得る。見つからなかった場合、方法はブロック５１０で続行し得る。
ブロック５１０で、特定されたキャッシュインデックスキーに対応する属性値によってディレクトリサーバーが検索され得る。
ブロック５１２で、特定されたキャッシュインデックスエントリキーを使用してディレクトリエントリが見つかった場合、方法はブロック５２４で続行し得る。見つからなかった場合、方法はブロック５１４で続行し得る。
ブロック５１４で、キャッシュインデックスのオブジェクト参照が作成され得る。
ブロック５１６で、キャッシュインデックスのオブジェクト参照に作成時刻が割り当てられ得る。
ブロック５１８で、キャッシュインデックスオブジェクトに生存時間（ＴＴＬ）分布係数が割り当てられ得る。ＴＴＬ分布係数は、ランダム数（例えば０〜１００（両端値を含む））であってよく、以降、ＴＴＬ値の指定許容範囲内でキャッシュインデックスオブジェクトのＴＴＬを判断する目的で使用され得る。いくつかの実施形態によれば、ランダム値を割り当てる他の方法が使用されてもよい。例えば、図４に関して上記のとおり、絶対ランダム数が使用されてもよい。
ブロック５２０で、オブジェクト参照がキャッシュインデックスに記憶され得る。
ブロック５２２で、キャッシュインデックスで特定されたエントリの期限が切れているかどうかが判断され得る。エントリの期限が切れている場合、方法はブロック５１０で続行し得る。キャッシュインデックスにおける特定されたエントリの期限が切れていない場合、方法はブロック５２８で続行し得る。
ブロック５２４で、エントリがディレクトリサーバーで見つからない場合には、対応するオブジェクトがキャッシュインデックスから削除されてもよい。
ブロック５２６で、エントリ不検出メッセージが返され得る。
ブロック５２８で、識別名を使用してエントリキャッシュが検索され得る。
ブロック５３０で、エントリが見つかったかどうかが判断され得る。エントリキャッシュにエントリが見つかった場合、方法５００はブロック５３２で続行し得る。エントリが見つからなかった場合、方法５００はブロック５３４で続行し得る。
ブロック５３２で、エントリの期限が切れたかどうか判断するために、特定されたディレクトリキャッシュエントリがテストされ得る。上記のとおり、期限切れかどうかは、ＴＴＬ分布係数、作成日、および作成日からの経過時間を含む１つまたはそれ以上の属性または設定を使用して判断され得る。キャッシュディレクトリエントリの期限が切れた場合、方法５００はブロック５３４で続行し得る。キャッシュディレクトリエントリの期限が切れていない場合、方法はブロック５４８で続行し得る。
ブロック５３４で、識別名（ＤＮ）を使用してディレクトリサーバーが検索され得る。
ブロック５３６で、リクエストされたオブジェクトに一致するディレクトリエントリがディレクトリサーバーに見つかったかどうかが判断され得る。ディレクトリエントリが見つかった場合、方法はブロック５４０で続行し得る。エントリが見つからなかった場合、方法５００はブロック５３８で続行し得る。
ブロック５３８で、対応するオブジェクトがエントリキャッシュから削除され得る。
ブロック５４０で、対応するディレクトリキャッシュエントリが作成され得る。
ブロック５４２で、キャッシュディレクトリエントリに作成時刻が割り当てられ得る。
ブロック５４４で、エントリキャッシュオブジェクトに生存時間（ＴＴＬ）分布係数が割り当てられ得る。ＴＴＬ分布係数は、ランダム数（例えば、０〜１００（両端値を含む））であってよく、以降、生存値の許容範囲の範囲内でエントリキャッシュオブジェクトのＴＴＬを判断する目的で使用され得る。いくつかの実施形態によれば、ランダム値を割り当てる他の方法が使用されてもよい。例えば、図４に関して上記のとおり、絶対ランダム数が使用されてもよい。
ブロック５４６で、ディレクトリエントリオブジェクトがキャッシュに記憶され得る。
ブロック５４８で、方法が終了し得る。
図６Ａ、図６Ｂ、および図６Ｃを参照すると、本開示の一実施形態にかかるディレクトリデータサービスのキャッシュパラメータを設定するためのインターフェースが表されている。キャッシュエントリ期限をランダム化するための様々な方法が使用され得る。例えば、図５に関して上記のとおり、正規化されたＴＴＬＳｐｒｅａｄＦａｃｔｏｒにキャッシュエントリが割り当てられ得る。ＴＴＬＳｐｒｅａｄＦａｃｔｏｒは、他のパラメータ（例えば、ＭｉｎＴＴＬパラメータおよびｍａｘＴＴＬパラメータ）が変更されたときにキャッシュエントリのＴＴＬを適切に増大低減し得る。他の実施形態は、作成時刻にキャッシュエントリに割り当てられた絶対ランダムＴＴＬを使用し得る。この割り当ては、指定（例えば、ｍｉｎＴＴＬパラメータおよびｍａｘＴＴＬパラメータによって指定）された範囲内である。別の実施形態は、ディレクトリオブジェクトがキャッシュからリクエストされるたびに計算され得るランダムなキャッシュエントリのＴＴＬを使用し得る。キャッシュエントリのＴＴＬをランダム化する他の変型例が可能であり、考慮される。
いくつかの実施形態によれば、管理者または他のユーザーは、最大生存時間パラメータおよび最小生存時間パラメータを設定することにより、キャッシュディレクトリエントリの許容期限の範囲を決定してもよい。例えば、図６Ａに示すとおり、４３２００秒の最小生存時間パラメータが指定され得る。１２９６００秒という最大生存時間パラメータの設定例も図６Ａも示されている。最小生存時間パラメータ設定は、キャッシュをリフレッシュするための負荷とディレクトリエントリの陳腐化とをトレードオフする目的で管理者によって決定され得る。キャッシュエントリは、最大生存時間パラメータおよび最小生存時間パラメータによって決定される範囲内で期限満了日または生存時間設定が割り当てられ得る。生存時間設定は、キャッシュディレクトリエントリの作成時に設定されてもよい。他の実施形態によれば、管理者または他のユーザーが、生存時間パラメータおよび生存時間分散パラメータを設定することによってキャッシュディレクトリエントリの許容期限の範囲を決定してもよい。生存時間分散パラメータは、キャッシュされたディレクトリが生存時間パラメータから変動し得る最大量を決定し得る。例えば、生存時間分散パラメータは、パーセンテージ（例えば０％と１００％との間のパーセンテージ）で表され得る。図６Ｂに示すとおり、ＴＴＬパラメータは８６４００秒に設定され、ＴＴＬ分散パラメータは５０％に設定される。生存時間分散パラメータは、小数に変換され、１から減算され、その後ＴＴＬによって乗算されて最小ＴＴＬを決定し得る。次に生存時間分散パラメータは、小数に変換され、１に加算され、その後ＴＴＬによって乗算されて最大ＴＴＬを決定し得る。他の方法およびパラメータは、個々のキャッシュエントリのＴＴＬ設定を分散させる生存時間設定の範囲を特定または決定する目的で使用され得る。いくつかの実施形態によれば、ＴＴＬ範囲、ＴＴＬ、またはＴＴＬ分散は、１つまたはそれ以上の要因に基づいて増減し得る。例えば、ＴＴＬおよび／またはＴＴＬの範囲は、キャッシュサイズ、ディレクトリサーバーの負荷または他の要因に基づいて増減し得る。１つまたはそれ以上の実施形態によれば、ＴＴＬ範囲は、ディレクトリデータソースに基づいて異なり得る。例えば、キャッシュの一部分が第１のディレクトリデータソースと関連付けられており、第２のキャッシュの一部分が第２のディレクトリデータソースと関連付けられている場合、異なる部分には異なるＴＴＬ範囲が割り当てられ得る。
図７Ａ、図７Ｂ、および図７Ｃを参照すると、本開示の一実施形態にかかるディレクトリデータサービスのキャッシュパラメータを設定するためのインターフェースが示されている。
いくつかの実施形態によれば、キャッシュエントリの期限が切れたかどうかは、キャッシュエントリの作成時刻からの経過時間を計算し、その経過時間をエントリの生存時間（ＴＴＬ）と比較することによって判断され得る。図７Ａに示すとおり、例示的なキャッシュディレクトリエントリの作成タイムスタンプが、１２６７１５８４６７７６３のミリ秒（ＭＳ）であり得る。タイムスタンプは、キャッシュディレクトリエントリの作成時にシステム時刻を取得するために、オペレーティングシステムＡＰＩを使用して作成され得る。キャッシュディレクトリエントリの作成時にランダムに割り当てられた可能性のあるＴＴＬ分布係数は、３９であり得る。上述のとおり、キャッシュエントリのＴＴＬを計算する目的で使用されるいくつかの異なるアルゴリズムが存在し得る。例えば、エントリの生存時間（ｅｎｔｒｙＴＴＬ）は次式で計算され得る。
ｅｎｔｒｙＴＴＬ＝ｍｉｎＴＴＬ＋（（ｍａｘＴＴＬ−ｍｉｎＴＴＬ）×（ｔｔｌＳｐｒｅａｄＦａｃｔｏｒ／１００．０））；／／秒
ｔｔｌＳｐｒｅａｄＦａｃｔｏｒは、０と１００（両端値を含む）間のランダム数（例えば３９）であり得る。ＭｉｎＴＴＬはキャッシュエントリの最小生存時間を表し得る。そしてＭａｘＴＴＬはエントリの最大生存時間を表し得る。したがって、ＭｉｎＴＴＬおよびＭａｘＴＴＬは許容範囲を判断し得る。そしてｔｔｌＳｐｒｅａｄｆａｃｔｏｒは、その範囲に沿ってキャッシュエントリを分散させる目的で使用されるランダム数であり得る。
図７Ｂで指定された例示的なＴＴＬ範囲と図７Ａで指定された例示的なＴＴＬ分布係数とを使用して、キャッシュエントリの生存時間（ＴＴＬ）が次式で計算され得る。
ＥＮＴＲＹ ＴＴＬ＝４３２００＋（（１２９６００−４３２００））×（３９／１００）＝７６８９６秒
図７Ａで指定された例示的なＴＴＬ範囲と図７Ｃで指定された例示的なＴＴＬ分布係数とを使用して、キャッシュエントリの生存時間（ＴＴＬ）が次式で計算され得る。
ＥＮＴＲＹ ＴＴＬ＝８６４００＋（（２５９２００−８６４００））×（３９／１００）＝１５３７９２秒
正規化されたＴＴＬ分布係数を割り当てることにより、ＭｉｎＴＴＬおよび／またはＭａｘＴＴＬが改変されたときにエントリのＴＴＬ値が自然に増減し得る。
経過時間は、１つまたはそれ以上のアルゴリズムによって計算され得る。例えば、経過時間は次式で計算され得る。
ｅｌａｐｓｅｄ＝（ｃｕｒｒｅｎｔＴｉｍｅ−ｃｒｅａｔｉｏｎＴｉｍｅ）×１０００；／／秒
経過時間およびキャッシュエントリの生存時間が決定されたら、期限の判断は次式によって行われ得る。
ｉｓＥｘｐｉｒｅｄ＝（ｅｌａｐｓｅｄ＞ｅｎｔｒｙＴＴＬ）
例示的実施形態によれば、ディレクトリデータサービス（ＤＤＳ）統合は、ＤＤＳビジネスロジック層を使用して実施され得る。ＤＤＳビジネスロジック層は、以下の部分で構成され得る。
ＤＤＳ ＡＰＩロック層：この層は、ＤＤＳクライアントリクエストの処理中にシステムがシャットダウン、再起動、あるいは他の形で停止することのないようにし得る。この層は、サーバーの再初期化をクライアントリクエストの処理と同期させることもある。この層は、ロック機能を伴うＤＤＳ ＡＰＩを実装し、１つまたはそれ以上のリクエストをＤＤＳ ＡＰＩ層に移譲し得る。
ビジネスコンポーネント層：この層は、ディレクトリ機能およびサーバーの再初期化を実施し得る。この層は、データアクセス、キャッシュ、および構成層を使用して、クライアントリクエストに対応する。この層は、構成層を使用してサーバーの再初期化を実行する。この層は、キャッシュおよびデータアクセス層にサーバーの再初期化を通知する。
キャッシュ層：この層は、メモリにおけるディレクトリモデルオブジェクトのキャッシュ保存を担い得る。ディレクトリモデルオブジェクトは、ユーザー、グループ、および／または配布リストなどのディレクトリエントリを表し得る。モデルオブジェクトは、ルックアップ電子メールアドレスおよびユニーク識別子（ＵＩＤ）など、１つまたはそれ以上の電子メールアドレスによってインデックス化され得る。認証機能の場合、ユーザーオブジェクトは、ユーザー名およびＵＩＤによってインデックス化され得る。存在しないディレクトリオブジェクトへの参照は、ネガティブキャッシュに記憶され得る。モデルオブジェクト内に格納されているＵＩＤは、メモリ消費を減らすためにプールされ得る。
構成層：この層は、ディスクから構成ファイル（例えば、ｄｄｓＣｏｎｆｉｇ．ｘｍｌ、ｕｓｅｒｐｒｅｆｓ．ｘｍｌおよびｂｍｉｃｏｎｆｉｇ．ｘｍｌ）を解析し得る。これらのファイルは、構成オブジェクトに変換され、メモリに記憶され得る。ＤＤＳｃｏｎｆｉｇオブジェクトは、データソース情報を格納しており、主にデータアクセス層によって使用され得る。このオブジェクトは、データソースマッピングに対するキャッシュ設定およびキャッシュプロファイルも格納しており、これらはキャッシュおよびビジネスコンポーネント層によって使用され得る。ＵｓｅｒＰｒｅｆｅｒｅｎｃｅｓおよびＰｏｌｉｃｙＣｏｎｆｉｇオブジェクトは、アドレス解決リクエストを処理する際に使用され得る。
ＤＤＳ ＡＰＩロック層は、クライアントリクエストの処理をサーバーの再初期化と同期させ得る。ただし、エンジンからＤＤＳに渡されたプロファイルＩＤの有効性を確保するために、コントロールセンターが、エンジンの再初期化をＤＤＳの再初期化と同期させてもよい。
ビジネス層クラス
ＤＤＳ ＡＰＩロック層
ＣｏｎｃｕｒｒｅｎｔＤＤＳ：このクラスは、ＤｉｒｅｃｔｏｒｙＤａｔａＳｅｒｖｉｃｅインターフェースを実装し、サーバーの再初期化をクライアントリクエストの処理と同期させるための読み出し／書き込みロックを使用し得る。書き込みロックが取得されない限り、読み出しロックは複数のクライアントリクエストによって同時に保持され得る。書き込みロックは排他的であってもよく、サーバーが起動したときに取得されてもよい。リーダーがアクティブであり、ライターがロックに入った場合には、そのライターが書き込みロックを取得し、解放するまで、以降のリーダーに読み出しロックが付与されることはない。このクラスの単一インスタンスは、Ｓｐｒｉｎｇフレームワークによってインスタンス生成され得る。インスタンスは、ＤｉｒｅｃｔｏｒｙＤａｔａＳｅｒｖｉｃｅインターフェースを実装するオブジェクトによって初期化される必要があり得る。
ビジネスコンポーネント層
ＡｕｔｈｅｎｔｉｃａｔｉｏｎＭａｎａｇｅｒ：このシングルトンは、認証機能タイプ関連のディレクトリ機能を実装し得る。そして、隔離エンドユーザーのログインを実行する。テストメソッドが利用可能であり得る。
ＱｕａｒａｎｔｉｎｅＲｅｓｏｌｕｔｉｏｎＭａｎａｇｅｒ：このシングルトンは、隔離アドレス解決機能タイプ関連のディレクトリ機能を実装し得る。そして、隔離アドレス解決を実行する。テストメソッドが利用可能であり得る。
ＲｅｃｉｐｉｅｎｔＶａｌｉｄａｔｉｏｎＭａｎａｇｅｒ：このシングルトンは、受信者の妥当性検証機能タイプ関連のディレクトリ機能を実装し得る。このシングルトンは、ＭＴＡによる受信者の妥当性検証を実行する。テストメソッドが利用可能であり得る。
ＲｏｕｔｉｎｇＭａｎａｇｅｒ：このシングルトンは、ルーティング機能タイプ関連のディレクトリ機能を実装し得る。そして、代替メールホストおよび代替アドレス情報を回送するＭＴＡを取得する。テストメソッドが利用可能であり得る。
ＡｄｄｒｅｓｓＲｅｓｏｌｕｔｉｏｎＭａｎａｇｅｒ：このシングルトンは、アドレス解決機能タイプ関連のディレクトリ機能を実装し得る。そして、エンジンアドレス解決と、「全グループ」機能を実行する。テストメソッドが利用可能であり得る。
ＲｅｓｏｌｖｅｄＡｄｄｒｅｓｓ：この転送オブジェクトは、エンジンアドレス解決を受けて返され得る。そして、ＲｅｃｉｐｉｅｎｔモデルオブジェクトおよびＲｅｓｏｌｖｅｄＲｅｃｉｐｉｅｎｔオブジェクトのリストへのアクセスを提供する。
ＲｅｓｏｌｖｅｄＲｅｃｉｐｉｅｎｔ：この転送オブジェクトは、Ｒｅｃｉｐｉｅｎｔモデルオブジェクト、受信者がメンバーとして属するＧｒｏｕｐモデルオブジェクトおよびＤｉｓｔｒｉｂｕｔｉｏｎＬｉｓｔモデルオブジェクト、ならびに受信者と関連付けられたユーザー設定ｘｍｌへのアクセスを提供し得る。
ＤｉｒｅｃｔｏｒｙＤａｔａＳｅｒｖｅｒ：このシングルトンは、サーバーの初期化を実行し得る。このシングルトンは、新たに読み込む構成ファイルが存在することを構成層に通知する。このシングルトンは、キャッシュ層、ビジネス層、およびデータアクセス層に新しいＤＤＳＣｏｎｆｉｇオブジェクトを渡す。これらの層は、古いＤＤＳＣｏｎｆｉｇオブジェクトを新しいものと比較することによって構成上の変更を検出し得る。
ＥｎｔｒｙＳｔｏｒｅ：このクラスは、ＥｎｔｒｙＣａｃｈｅおよびＥｎｔｒｙＤＡＯのインスタンスをラップし得る。このクラスは、ＴＴＬロジックの実施中に、キャッシュされたオブジェクトへのアクセスを提供する。このクラスの１つのインスタンスは、データソース機能ごとに作成され得る。
ＥｎｔｒｙＳｔｏｒｅＦａｃｔｏｒｙ：このシングルトンは、ＤＤＳＣｏｎｆｉｇにおけるデータソース機能ごとにＥｎｔｒｙＳｔｏｒｅオブジェクトを作成し得る。ＥｎｔｒｙＳｔｏｒｅは、データソースＩＤと機能タイプとによって検索され得る。このシングルトンは、サーバーが再初期化されると、新しいＤＤＳＣｏｎｆｉｇオブジェクトによって通知され得る。
ＥｎｔｒｙＭａｒｔ：このクラスは、プロファイルにマッピングされ、ＥｎｔｒｙＳｔｏｒｅオブジェクトの配列を格納し得る。このクラスは、自身の主な機能として、ＥｎｔｒｙＳｔｏｒｅオブジェクトに対するキャッシュ優先検索を実行する。
ＥｎｔｒｙＭａｒｔＦａｃｔｏｒｙ：このシングルトンは、ＤＤＳＣｏｎｆｉｇにおけるプロファイルごとにＥｎｔｒｙＭａｒｔオブジェクトを作成し得る。ＥｎｔｒｙＭａｒｔは、プロファイルＩＤによって検索され得る。このシングルトンは、サーバーが再初期化されると、新しいＤＤＳＣｏｎｆｉｇオブジェクトによって通知され得る。
構成層
ＤＤＳＣｏｎｆｉｇＦａｃｔｏｒｙ：このシングルトンは、サーバーの起動および再初期化時に、ｄｄｓＣｏｎｆｉｇ．ｘｍｌファイルを解析してＤＤＳＣｏｎｆｉｇオブジェクトにし得る。ファイルの最終変更日が不変であれば、そのファイルが改めて読み込まれることはない。
ＤＤＳＣｏｎｆｉｇ：ｄｄｓＣｏｎｆｉｇ．ｘｍｌファイルの内容を表し得る構成オブジェクト。
ＰｏｌｉｃｙＣｏｎｆｉｇＦａｃｔｏｒｙ：このシングルトンは、サーバーの起動および再初期化時に、ｂｍｉｃｏｎｆｉｇ．ｘｍｌファイルを解析してＰｏｌｉｃｙＣｏｎｆｉｇオブジェクトにし得る。ファイルの最終変更日が不変であれば、そのファイルが改めて読み込まれることはない。
ＰｏｌｉｃｙＣｏｎｆｉｇ：ｂｍｉｃｏｎｆｉｇ．ｘｍｌファイル内の任意のグループポリシーにマッピングされ得るディレクトリグループＵＩＤを格納している構成オブジェクト。
ＵｓｅｒＰｒｅｆｅｒｅｎｃｅｓＦａｃｔｏｒｙ：このシングルトンは、サーバーの起動および再初期化時に、ｕｓｅｒｐｒｅｆｓ．ｘｍｌファイルを解析してＵｓｅｒＰｒｅｆｅｒｅｎｃｅｓオブジェクトにし得る。ファイルの最終変更日が不変であれば、そのファイルが改めて読み込まれることはない。
ＵｓｅｒＰｒｅｆｅｒｅｎｃｅｓ：ｕｓｅｒｐｒｅｆｓ．ｘｍｌファイルの内容を表す構成オブジェクト。各ユーザーのユーザー設定ｘｍｌストリングは、ｂａｓｅ６４で符号化され得る。
キャッシュ層
Ｅｎｔｒｙ：このインターフェースは、１つまたはそれ以上のディレクトリオブジェクトをモデル化し得る。このインターフェースは、ＵＩＤ（すなわちＤＮ）およびｍｅｍｂｅｒＯｆ属性へのアクセスを提供し得る。
Ｒｅｃｉｐｉｅｎｔ：このインターフェースは、プライマリ配送可能アドレスを有するディレクトリオブジェクトをモデル化し得る。このインターフェースは、Ｅｎｔｒｙインターフェースを拡張し得ることに加え、プライマリ配送可能アドレス、エイリアスアドレス、および他のカスタム属性へのアクセスを提供する。
ＲｅｃｉｐｉｅｎｔＲｅｆ：このクラスは、電子メールアドレスによってＲｅｃｉｐｉｅｎｔオブジェクトを参照する方法を提供し得る。参照は、ＵＩＤによってＲｅｃｉｐｉｅｎｔオブジェクトを参照する。
ＩｎｖａｌｉｄＲｅｃｉｐｉｅｎｔ：このクラスは、存在しないディレクトリオブジェクトに対する参照（電子メールアドレス）を保持し得る。この参照はネガティブキャッシュエントリであり、ネガティブキャッシング目的で使用され得る。
ＭｅｍｂｅｒＬｉｓｔ：このインターフェースは、メンバーのリストを含むディレクトリオブジェクトをモデル化し得る。このインターフェースは、Ｅｎｔｒｙインターフェースを拡張し、メンバーリストへのアクセスを提供する。
Ｕｓｅｒ：このクラスは、ディレクトリユーザーオブジェクトをモデル化し得る。このクラスは、そして、Ｒｅｃｉｐｉｅｎｔインターフェースを実装する。
ＵｓｅｒＲｅｆ：このクラスは、ユーザー名によってユーザーオブジェクトを参照する方法を提供し得る。ＵＩＤによってＵｓｅｒオブジェクトを参照する。
Ｇｒｏｕｐ：このクラスは、ディレクトリグループオブジェクトをモデル化し得る。このクラスは、ＭｅｍｂｅｒＬｉｓｔインターフェースを実装する。このクラスは、グループ名（例えばｃｎ）へのアクセスを提供する。
ＤｉｓｔｒｉｂｕｔｉｏｎＬｉｓｔ：このクラスは、プライマリ配送可能アドレスを有するディレクトリグループオブジェクトをモデル化し得る。このクラスは、ＲｅｃｉｐｉｅｎｔおよびＭｅｍｂｅｒＬｉｓｔインターフェースを実装する。
Ａｔｔｒｉｂｕｔｅ：このクラスは、ルーティングディレクトリ機能によって使用されるオブジェクトなど、ユーザーおよびグループディレクトリオブジェクトに関するカスタム属性へのアクセスを提供し得る。
ＥｎｔｒｙＣａｃｈｅ：このインターフェースは、キャッシュからＥｎｔｒｙ、ＲｅｃｉｐｉｅｎｔＲｅｆ、ＵｓｅｒＲｅｆおよびＩｎｖａｌｉｄＲｅｃｉｐｉｅｎｔオブジェクトを取得、追加、および削除するのに必要な動作を定め得る。このインターフェースは、キャッシュサイズの設定やキャッシュエントリのパージなどの実行時キャッシュ管理動作のセットも定め得る。
public interface EntryCache
{
public Entry getEntry(String uniqueId);
public void addEntry(Entry entry);
public Entry removeEntry(String uniqueId);
public void setMaxEntries(int maxEntries);

public RecipientRef getRecipientRef(String
emailAddress);
public void addRecipientRef(RecipientRef ref);
public RecipientRef removeRecipientRef(String
emailAddress);
public void setMaxRecipientRefs(int maxRecipientRefs);

public UserRef getUserRef(String userName);
public void addUserRef(UserRef ref);
public UserRef removeUserRef(String userName);
public void setMaxUserRefs(int
maxUserRefs);
public InvalidRecipient
getInvalidRecipient(String emailAddress);
public void addInvalidRecipient(InvalidRecipient
rcpt);
public InvalidRecipient removeInvalidRecipient(String
emailAddress);
public void setMaxInvalidRecipients(int
maxInvalidRecipients);

public void purge();
}
ＬＲＵＥｎｔｒｙＣａｃｈｅ：このクラスは、ＥｎｔｒｙＣａｃｈｅインターフェースを実装し得る。このクラスは、Ｅｎｔｒｙ、ＲｅｃｉｐｉｅｎｔＲｅｆ、ＵｓｅｒＲｅｆ、およびＩｎｖａｌｉｄＲｅｃｉｐｉｅｎｔオブジェクトをメモリにキャッシュする。このクラスの１つのインスタンスは、データソース機能ごとに作成され得る。そして、アクセス順を保持するＬｉｎｋｅｄＨａｓｈＭａｐを使用して、ＥｎｔｒｙオブジェクトをＵＩＤによってインデックス化する。ＲｅｃｉｐｉｅｎｔＲｅｆオブジェクトは、アクセス順を保持する別々のＬｉｎｋｅｄＨａｓｈＭａｐにおいて、ルックアップアドレスによってインデックス化され得る。ＵｓｅｒＲｅｆオブジェクトは、アクセス順を保持する別々のＬｉｎｋｅｄＨａｓｈＭａｐにおいて、ユーザー名によってインデックス化され得る。ＩｎｖａｌｉｄＲｅｃｉｐｉｅｎｔオブジェクトも、別々のアクセス順を保持する別々のマップにおいて、ルックアップアドレスによってインデックス化され得る。マップ上での最大サイズを超えた場合には、使用時期が最も古いエントリがマップから削除され得る。キャッシュされたモデルオブジェクトは、ＵＩＤ（すなわちＤＮ）によって他のディレクトリオブジェクトを参照し、メモリ使用を減らすために、これらのＵＩＤはＩｎｔｅｒｎＰｏｏｌを使用してプールされ得る。キャッシュごとに１つのＩｎｔｅｒｎＰｏｏｌインスタンスが存在し得る。
ＩｎｔｅｒｎＰｏｏｌ：このクラスは、文字列プールであり得る。このクラスは、ＷｅａｋＨａｓｈＭａｐを使用してＳｔｒｉｎｇオブジェクトをインデックス化する。参照されなくなると、自身のエントリは自動的にガベージコレクションされる。
ＥｎｔｒｙＣａｃｈｅＦａｃｔｏｒｙ：このシングルトンは、ＤＤＳＣｏｎｆｉｇにおけるデータソース機能ごとにＬＲＵＥｎｔｒｙＣａｃｈｅオブジェクトを作成し得る。ＥｎｔｒｙＣａｃｈｅは、データソースＩＤと機能タイプとによって検索され得る。このクラスは、現在のＤＤＳＣｏｎｆｉｇオブジェクトの参照を常に維持し得る。このシングルトンは、サーバーが再初期化されると、新しいＤＤＳＣｏｎｆｉｇオブジェクトによって通知され得る。キャッシュインスタンスは、現在の構成を新しい構成と比較するによって無効化され得る。
キャッシュデザイン
キャッシュデザインは、１つまたはそれ以上の要因の影響を受ける。まず、ＴＴＬ（生存時間）を超えているキャッシュエントリと関連付けられたデータソース接続が停止している場合には、それらのキャッシュエントリが使用されるはずである。したがって、期限の切れたキャッシュデータが事前に削除されることはない。エントリが新しいバージョンと交換されるか、キャッシュサイズの超過を理由にエントリが追い出されるか、どちらかが起こるまでキャッシュエントリはキャッシュで留まり得る。２番目に、単一コピーのディレクトリオブジェクトだけがキャッシュされる必要がある。これは、キャッシュを同一ディレクトリオブジェクトの異なるバージョンで満たすのを防ぐためである。また、これにより、ディレクトリオブジェクトの取得方法（ユニークＩＤ、プライマリ配送可能アドレス、エイリアスアドレス、ルックアップアドレス、またはユーザー名）に関係なく、確実に同一バージョンが返され得る。
デフォルトでは、ＥｎｔｒｙＣａｃｈｅＦａｃｔｏｒｙシングルトンインスタンスは、サーバーシャットダウン時にデフォルトのｊａｖａシリアル化を用いてディスクにシリアル化され得る。シリアル化されたインスタンスは、サーバー起動時にメモリに読み込まれ得る。これにより、メモリキャッシュ内のすべてが、サーバーを再起動しても保たれ得る。ＯｂｊｅｃｔＯｕｔｐｕｔＳｔｒｅａｍを使用して、単一のオブジェクトに対する複数の参照が参照共有メカニズムを用いて符号化されてもよく、それにより、オブジェクトのグラフを、オリジナルが記述されたときと同じ形状に復元することができる。換言すれば、プールされた文字列が、逆シリアル化後も引き続きプールされ得る。メモリのフットプリントは、逆シリアル化後も増えない。シリアル化されたｊａｖａオブジェクトはクラスバージョンの変更に敏感なので、ソフトウェアの更新後は、シリアル化されたキャッシュデータが無視され得る。
下記の表１は、例示的なＬＲＵＥｎｔｒｙＣａｃｈｅの例示的な内容を示す。
文字列プール
キャッシュ内のＵＩＤは、メモリ消費を減らすためにＩｎｔｅｒｎＰｏｏｌを使用してプールされ得る。以下の実施例が示すとおり、大きく節約できる可能性がある。
想定事例：
１０万ユーザー
５万ｄｌｉｓｔ
各ｄｌｉｓｔに２００ユーザー
各ＤＮ文字列は５０バイト
文字列プールを使用しなければ、すべてのＤＮ文字列の合計サイズは以下のようになり得る。
１０万×５０＋５万×５０＋５万＊２００×５０＝５００万＋２５０万＋５億＝５億７５０万
文字列プールを使用すれば、すべてのＤＮ文字列の合計サイズは以下のようになり得る。
１０万×５０＋５万×５０＝５００万＋２５０万＝７５０万
ディレクトリオブジェクトおよびＴＴＬ
ビジネスコンポーネント層は、キャッシュされたディレクトリオブジェクトにＴＴＬを適用し得る。作成時刻（ミリ秒）は、各モデルオブジェクト（Ｕｓｅｒ、ＤｉｓｔｒｉｂｕｔｉｏｎＬｉｓｔ、Ｇｒｏｕｐ、ＲｅｃｉｐｉｅｎｔＲｅｆ、ＵｓｅｒＲｅｆ、およびＩｎｖａｌｉｄＲｅｃｉｐｉｅｎｔ）で設定された後に、キャッシュに追加され得る。作成時刻は、取得されると、オブジェクトの期限が切れたかどうかを判断するために、現在の時刻と比較され得る。オブジェクトの期限が切れた場合には、データソースからオブジェクトのリフレッシュが試行され得る。データソース接続の失敗が発生した場合には、期限の切れたオブジェクトが代わりに使用され得る。
多数のキャッシュオブジェクトが同時に期限切れになるのを防ぐために、各オブジェクトでＴＴＬ分布係数が設定された後にキャッシュに追加され得る。ＴＴＬ分布係数は、最小ＴＴＬと最大ＴＴＬとの間の１０１個の別個の値の範囲内でＴＴＬをランダム化する目的で使用され得る。オブジェクトの期限は、次式で計算され得る。
ｅｘｐｉｒａｔｉｏｎＴｉｍｅ＝ｃｒｅａｔｉｏｎＴｉｍｅ＋ｍｉｎＴＴＬ＋（（ｍａｘＴＴＬ−ｍｉｎＴＴＬ）×（ＴＴＬＳｐｒｅａｄＦａｃｔｏｒ／１００．００））
式中、ｃｒｅａｔｉｏｎＴｉｍｅは秒、ｍｉｎＴＴＬは最小生存時間（秒）、ｍａｘＴＴＬは最大生存時間（秒）、ＴＴＬＳｐｒｅａｄＦａｃｔｏｒは０と１００との間（両端値を含む）のランダムに選ばれた数であり得る。例えば、最小ＴＴＬが４３２００秒（１２時間）、最大ＴＴＬが１２９６００秒（３６時間）である場合、キャッシュオブジェクトは、それらのｔｔｌＳｐｒｅａｄＦａｃｔｏｒ値によって決定されるとおり、１２時間と３６時間との間で期限が切れ得る。ＴＴＬＳｐｒｅａｄＦａｃｔｏｒは、無効な受信者に適用されることはない。
システムクロックが変更されると、すでにキャッシュにあるオブジェクトの期限が変更に応じて増減し得る。
実施例１：以下の実施例は、ＥｎｔｒｙオブジェクトのＴＴＬ確認を示す。
public Entry getEntry(String uniqueId) throws
DataAccessException
{
Entry entry=cache.getEntry(uniqueId);
if(entry != null &&
isStale(entry))
{
try
{

entry=source.getByUniqueId(uniqueId); // get entry from data source
if(entry != null)
{

addEntry(entry);

}
else
{

cache.removeEntry(uniqueId);
}
}

catch(DataAccessTransientException e)
{

log.warn("using stale cache entry" + entry, e);
}
}
return entry;
}
実施例２：以下の実施例は、ＲｅｃｉｐｉｅｎｔＲｅｆオブジェクトのＴＴＬ確認を示す。
public Recipient getRecipient(String emailAddress)
throws DataAccessException
{
Recipient rcpt=null;

RecipientRef
ref=cache.getRecipientRef(emailAddress);
if(ref != null)
{
if(isStale(ref))
{
try
{

rcpt=source.getByEmail(emailAddress); // get entry from data source

if(rcpt != null)
{

addRecipient(emailAddress, rcpt);
}
else
{

cache.removeRecipientRef(emailAddress);
}
}
catch(DataAccessTransientException
e)
{

log.warn("using stale cache entry "+ ref, e);

rcpt=getRecipient(ref);
}
}
else
{

rcpt=getRecipient(ref);
}
}
return rcpt;
}

private Recipient getRecipient(RecipientRef ref)
{
Entry
entry=cache.getEntry(ref.getUniqueId());
if(entry instanceof Recipient)
{
return (Recipient) entry;
}
return null;
}
ディレクトリ機能
すべてのディレクトリ機能に共通するタスクは、プロファイルと関連付けられたキャッシュおよびデータソースの中から受信者を見つけることであり得る。キャッシュ優先検索アルゴリズム、およびアルゴリズムと各ディレクトリ機能との関係について以下説明する。
キャッシュ優先検索
キャッシュ優先検索アルゴリズムはまず、キャッシュインスタンスから受信者を検索し、受信者が見つかるか、検索するキャッシュがなくなるまで続けられる。受信者がキャッシュに見つからない場合には、次に、ネガティブキャッシュエントリを持たないデータソースから受信者を検索する。受信者が１つのデータソースに見つかった場合には、関連付けられたキャッシュにその受信者を追加する。受信者が一意でない場合には、エラーを返す。受信者がどのデータソースにも見つからない場合には、各キャッシュにネガティブキャッシュエントリを追加する。このロジックにより、ルックアップアドレスがすべてのデータソースで確実に一意となり得る。
受信者の妥当性検証
この受信者検索は、「キャッシュ優先」検索であり得る。ただし、ルックアップアドレスが一意でない場合に、エラーではなく真が返され得る。
アドレス解決
アドレス解決は、受信者の「キャッシュ優先」検索から始まり得る。その後、受信者を格納しているデータソースを使用して、その受信者の下位受信者を再帰的に取り出す。受信者本人または下位受信者のいずれかがユーザーまたは空の配布リストである場合には、そのリストをユーザー目標のリストに追加する。次に、ユーザー目標ごとに、グループメンバーシップを入力する。グループメンバーシップは、バックグラウンドスレッドでビルドされ得る。
メッセージルーティング
この受信者検索は、「キャッシュ優先」検索であり得る。
隔離認証
隔離認証は、ユーザーの「キャッシュ優先」検索から始まる。ユーザーが見つかると、関連付けられたデータソースと照合してユーザーを認証する。
隔離アドレス解決
この受信者検索は、「キャッシュ優先」検索であり得る。
ルックアップアドレスおよびユーザー名の一意性
ルックアップアドレスおよびユーザー名の一意性は、データアクセス層およびビジネス層で実施され得る。以下の概説が該当し得る。
「キャッシュ優先」検索アルゴリズムにより、プロファイル内のすべてのデータソースでのルックアップアドレスおよびユーザー名の一意性が確保される。
キャッシュオブジェクトが、ルックアップアドレスまたはユーザー名によってインデックス化され得るが、プロファイル内のデータソース全体での一意性がテストされていない属性値によってインデックス化されることはない。
キャッシュオブジェクトは、キャッシュに存在する限り、一意性が再テストされることはない。これは、キャッシュオブジェクトが自身のＴＴＬを超えた場合でも当てはまり得る。
新しいデータソースが既存のプロファイルに追加されると、新しいデータソースの前に作成されたキャッシュエントリが、新たに追加されたデータソースと照合して一意性をテストされることはない。
キャッシュの無効化
以下が変わると、キャッシュが無効化され得る。
／ｄｄｓＣｏｎｆｉｇ／ｄａｔａＳｏｕｒｃｅｓ／ｄａｔａＳｏｕｒｃｅＬＤＡＰ／ｄｉｒｅｃｔｏｒｙＴｙｐｅ
／ｄｄｓＣｏｎｆｉｇ／ｄａｔａＳｏｕｒｃｅｓ／ｄａｔａＳｏｕｒｃｅＬＤＡＰ／ｓｅｒｖｅｒｓ／ｓｅｒｖｅｒ／ｈｏｓｔｓ／／＊
／ｄｄｓＣｏｎｆｉｇ／ｄａｔａＳｏｕｒｃｅｓ／ｄａｔａＳｏｕｒｃｅＬＤＡＰ／ｓｅｒｖｅｒｓ／ｓｅｒｖｅｒ／ｐｏｒｔ
／ｄｄｓＣｏｎｆｉｇ／ｄａｔａＳｏｕｒｃｅｓ／ｄａｔａＳｏｕｒｃｅＬＤＡＰ／ｆｕｎｃｔｉｏｎｓ／／＊
ＬＤＡＰ接続の失敗が発生した場合には、自身のＴＴＬを超えているキャッシュされたディレクトリオブジェクトが維持され得る。
循環グループおよび配布リストのメンバーシップ参照によって循環処理が生じることはない。これは、アドレス解決だけに該当し得る。無限再帰を防ぐために、アクセスされたノードのリストが使用され得る。トラバースされるネスト構造のグループの数に制限が存在することはない。
キャッシュエントリの設定可能生存時間（ＴＴＬ）機能
キャッシュされたディレクトリオブジェクトの最小および最大ＴＴＬは、ディレクトリデータソースごとに設定可能であり得る。
設定可能なキャッシュサイズ（エントリの数）
キャッシュサイズは、関連付けられたキャッシュインデックスサイズとして、ディレクトリデータソースごとに設定可能であり得る。
オンディマンドによるキャッシュパージ
各ディレクトリデータソースのキャッシュは、コントロールセンターの管理者によって個々にクリアすることができる。
図８は、本開示の一実施形態にかかる、クエリフィルタトークンを使用してディレクトリエントリを一致させる方法を示す。いくつかの実施形態によれば、ディレクトリサーバーへの問い合わせ時に、クエリフィルタトークンが使用され得る。クエリフィルタトークンにより、トークンが、対応するパラメータトークンの実行時に代用されるクエリにおいて、パラメータのプレースホルダとして動作できる可能性がある。例えば、クエリフィルタトークンは以下を含み得る。
％ｓトークンは、完全電子メールアドレスを問い合わせるクエリにおけるプレースホルダであり得る。％ｕトークンは、電子メールアドレスのローカル部分を問い合わせるクエリにおけるプレースホルダであり得る。％ｄトークンは、電子メールアドレスのドメイン部分を問い合わせるクエリにおけるプレースホルダであり得る。％ｎトークンは、完全名を問い合わせるクエリにおけるプレースホルダであり得る。完全名は、電子メールアドレスのローカル部を取り出し、ピリオドおよびアンダースコアをスペースに置き換えることによって導出され得る。
１つまたはそれ以上のタイプのメールサーバーの管理者は、「メール」属性値に加え、自身の名前および／または名字、あるいはそれらのいくつかの組み合わせに基づいて、自身のサーバーを、ユーザーの電子メールも受け入れるように構成し得る。
想定するエントリ例：
ｄｎ： ＣＮ＝Ｊｏｈｎ Ｂｉｇｂｏｏｔｅ， Ｏ＝ｓｆｄｏｍ１
ｇｉｖｅｎｎａｍｅ： Ｊｏｈｎ
ｏｂｊｅｃｔｃｌａｓｓ： ｄｏｍｉｎｏＰｅｒｓｏｎ
ｕｉｄ： ＪＢｉｇｂｏｏｔｅ＿ｕｉｄ
ｕｉｄ： ＪＢｉｇｂｏｏｔｅ＿ｕｉｄ２＠ｅｎｇ．ｓｙｍａｎｔｅｃ．ｃｏｍ
ｍａｉｌ： ｊｏｈｎ．ｂｉｇｂｏｏｔｅ．ｍａｉｌ＠ｅｎｇ．ｓｙｍａｎｔｅｃ．ｃｏｍ
ｃｎ： Ｊｏｈｎ Ｂｉｇｂｏｏｔｅ
ｓｎ： Ｂｉｇｂｏｏｔｅ
ｅｎｇ．ｓｙｍａｎｔｅｃ．ｃｏｍおよびａｌｉａｓｄｏｍａｉｎ．ｃｏｍのメールを受信するように構成されたメールサーバーは、以下のうちの１つまたはそれ以上を無効な受信者と認識するように構成され得る。
ｊｏｈｎ＠ａｌｉａｓｄｏｍａｉｎ．ｃｏｍ
ｊｏｈｎ＠ｅｎｇ．ｓｙｍａｎｔｅｃ．ｃｏｍ
ｂｉｇｂｏｏｔｅ＠ａｌｉａｓｄｏｍａｉｎ．ｃｏｍ
ｂｉｇｂｏｏｔｅ＠ｅｎｇ．ｓｙｍａｎｔｅｃ．ｃｏｍ
ｊｂｉｇｂｏｏｔｅ＿ｕｉｄ＠ａｌｉａｓｄｏｍａｉｎ．ｃｏｍ
ｊｂｉｇｂｏｏｔｅ＿ｕｉｄ＠ｅｎｇ．ｓｙｍａｎｔｅｃ．ｃｏｍ
ｊｂｉｇｂｏｏｔｅ＿ｕｉｄ２＠ｅｎｇ．ｓｙｍａｎｔｅｃ．ｃｏｍ
ｊｏｈｎ．ｂｉｇｂｏｏｔｅ．ｍａｉｌ＠ｅｎｇ．ｓｙｍａｎｔｅｃ．ｃｏｍ
ｊｏｈｎ．ｂｉｇｂｏｏｔｅ．ｍａｉｌ＠ａｌｉａｓｄｏｍａｉｎ．ｃｏｍ
ｊｏｈｎ．ｂｉｇｂｏｏｔｅ＠ａｌｉａｓｄｏｍａｉｎ．ｃｏｍ
ｊｏｈｎ．ｂｉｇｂｏｏｔｅ＠ｅｎｇ．ｓｙｍａｎｔｅｃ．ｃｏｍ
ｊｏｈｎ＿ｂｉｇｂｏｏｔｅ＠ａｌｉａｓｄｏｍａｉｎ．ｃｏｍ
ｊｏｈｎ＿ｂｉｇｂｏｏｔｅ＠ｅｎｇ．ｓｙｍａｎｔｅｃ．ｃｏｍ
メールサーバー管理者は、これらのエイリアス（例えば、「メール」属性値をユーザーの唯一の配送可能なアドレスとみなすなど）をサポートしないように自身のサーバーを構成し得るので、自身のディレクトリサーバークエリを、これらの各種アドレス形態を包含あるいは除外するように構成することも可能であり得る。大規模なメールサーバー展開では、「ｕｉｄ」および「メール」属性値だけを配送可能なアドレスとして使用し得る。かかる構成は、上記実施例に続いて、以下のアドレスをサポートする。
ｊｂｉｇｂｏｏｔｅ＿ｕｉｄ＠ａｌｉａｓｄｏｍａｉｎ．ｃｏｍ
ｊｂｉｇｂｏｏｔｅ＿ｕｉｄ＠ｅｎｇ．ｓｙｍａｎｔｅｃ．ｃｏｍ
ｊｂｉｇｂｏｏｔｅ＿ｕｉｄ２＠ｅｎｇ．ｓｙｍａｎｔｅｃ．ｃｏｍ
ｊｏｈｎ．ｂｉｇｂｏｏｔｅ．ｍａｉｌ＠ｅｎｇ．ｓｙｍａｎｔｅｃ．ｃｏｍ
ｊｏｈｎ．ｂｉｇｂｏｏｔｅ．ｍａｉｌ＠ａｌｉａｓｄｏｍａｉｎ．ｃｏｍ
いくつかの実施形態によれば、これらのうちの１つまたはそれ以上を捕捉する目的でクエリフィルタが使用され得る。
（｜（ｍａｉｌ＝％ｓ）（ｕｉｄ＝％ｓ）（ｕｉｄ＝％ｕ））
管理者がユーザーの完全名へのエイリアス化を許容するようにしている場合には、クエリを以下のように変更することができる。
（｜（ｍａｉｌ＝％ｓ）（ｕｉｄ＝％ｓ）（ｕｉｄ＝％ｕ）（ｃｎ＝％ｎ））
なお、ここでは、電子メールアドレスのローカル部におけるピリオドまたはアンダーラインを表すホワイトスペースの代用となり得る％ｎトークンが使用され、その結果、ｊｏｈｎ．ｂｉｇｂｏｏｔｅ＠ｅｎｇ．ｓｙｍａｎｔｅｃ．ｃｏｍまたはｊｏｈｎ＿ｂｉｇｂｏｏｔｅ＠ｅｎｇ．ｓｙｍａｎｔｅｃ．ｃｏｍは（ｃｎ＝ｊｏｈｎ ｂｉｇｂｏｏｔｅ）となる。
管理者が、ユーザーの名前および名字へのエイリアス化も許容している場合には、クエリが以下のように変更され得る。
（｜（ｍａｉｌ＝％ｓ）（ｕｉｄ＝％ｓ）（ｕｉｄ＝％ｕ）（ｃｎ＝％ｎ）（ｇｉｖｅｎＮａｍｅ＝％ｕ）（ｓｎ＝％ｕ））
名前および名字のエイリアス化が許容されていると、同じ名前および／または名字を有する２つ以上のユーザーエントリ間で名前空間の「衝突」が発生する可能性がはるかに高まり得る。たとえば、仮想的なディレクトリサーバーが次のようなエントリも格納している場合、
ｄｎ： ＣＮ＝Ｊｏｈｎ Ｗｈｏｒｆｉｎ， Ｏ＝ｓｆｄｏｍ１
ｇｉｖｅｎｎａｍｅ： Ｊｏｈｎ
…
ｃｎ： Ｊｏｈｎ Ｗｈｏｒｆｉｎ
ｓｎ： Ｗｈｏｒｆｉｎ
受信者を一意に特定できないというテキストメッセージを伴う５ｘｘエラーをＳＭＴＰクライアントに返すことにより、ＳＭＴＰサーバー自体がｊｏｈｎ＠ａｌｉａｓｄｏｍａｉｎ．ｃｏｍへの配送試行を扱い得る。ディレクトリデータサービスＬＤＡＰクエリが２つのエントリ（ｇｉｖｅｎＮａｍｅ＝ｊｏｈｎ）を返し得るので、この状況は、上記のデータ整合エラーとして扱われ得る。
図８に示すとおり、例示的な完全なアドレス、電子メールアドレスのローカル部分、対応する完全名、および例示的なクエリが、要素８０２に表されている。例示的なディレクトリエントリが、要素８０６に表されている。ディレクトリサーバーによっては（例えばＩＢＭ Ｌｏｔｕｓ Ｄｏｍｉｎｏ）、ディレクトリエントリの複数の電子メールエイリアスをサポートするものもある。要素８０４に示すとおり、要素８０６に列記されているディレクトリエントリに対して、複数の電子メールエイリアスがサポートされ得る。要素８０８および８１０に示すとおり、「ｊｏｈｎ＿ｓｍｉｔｈ＠ｄｏｍａｉｎ．ｃｏｍ」の電子メールアドレスの妥当性を検証するためにクエリが受信された場合には、トークン％ｓおよび％ｕを使用したディレクトリサーバークエリがディレクトリエントリを見つけることはない。ただし、要素８１２および８１４に表すとおり、完全名で問い合わせるために％ｎトークンが使用された場合には、一致が見つかり得る。％ｎトークンは、電子メールアドレスのローカル部におけるピリオドまたはアンダースコアをスペースで置き換えて、問い合わせ用の完全名を導出する。
この時点で、上記の本開示にかかるディレクトリサーバーを統合が、ある程度までの入力データの処理と出力データの生成とを概して含むということに注意すべきである。この入力データ処理および出力データ生成は、ハードウェアまたはソフトウェアで実施され得る。例えば、上記の本開示にかかるディレクトリサーバー統合と関連付けられた機能を実行するために、ディレクトリデータサービス、または同様の回路あるいは関連する回路で、特定の電子構成要素が用いられ得る。あるいは、命令に従って動作する１つまたはそれ以上のプロセッサが、上記の本開示にかかるディレクトリサーバーを統合と関連付けられた機能を実行し得る。このような場合、かかる命令が１つまたはそれ以上のプロセッサ読み取り可能な記憶媒体（例えば、磁気ディスクまたは他の記憶媒体）に記憶され得るか、あるいは１つまたはそれ以上の搬送波に組み入れられた１つまたはそれ以上の信号を介して１つまたはそれ以上のプロセッサに送信され得ることは、本開示の範囲内である。
本開示は、本明細書に記載されている具体的な実施形態によって範囲が制限されるものではない。実際、上記の記載内容および添付の図面から、本明細書に記載されている実施形態に加え、本開示の他の各種実施形態および変型例が当業者にとって明らかであろう。そのため、かかる他の実施形態および変型例は、本開示の範囲内に収まるものと意図される。さらに、本開示について、特定の目的のための特定の環境における特定の実施態様という文脈で本明細書に記載してきたが、当業者であれば、その有用性がそれに制限されず、本開示が任意の数の目的のために任意の数の環境で有益に実施され得ることを認識するであろう。したがって、以下に述べる請求項は、本明細書に記載されている本開示の全幅および精神を鑑みて解釈されるべきである。

Claims (15)

  1. ディレクトリサーバーを統合するための方法であって、
    複数のキャッシュディレクトリエントリの許容期限の範囲を決定する１つまたはそれ以上のパラメータを設定することと、
    電子記憶装置において、ディレクトリサーバーからキャッシュディレクトリエントリを作成することと、
    前記キャッシュディレクトリエントリに作成時刻を割り当てることと、
    前記許容期限の範囲内で前記キャッシュディレクトリエントリの期限を決定する少なくとも１つのランダム値を前記キャッシュディレクトリエントリに割り当てることであって、複数のキャッシュディレクトリエントリの前記許容期限の範囲内で前記キャッシュディレクトリエントリの前記期限をランダム化することにより、ある時点においてキャッシュメモリと前記ディレクトリサーバーとの間で必要とされる同期の量が減少することと、
    を含む、方法。
  2. キャッシュディレクトリエントリの許容期限の範囲を決定する前記１つまたはそれ以上のパラメータが、最大生存時間パラメータと最小生存時間パラメータとを備える、請求項１に記載の方法。
  3. キャッシュディレクトリエントリの許容期限の範囲を決定する前記１つまたはそれ以上のパラメータが、生存時間パラメータと生存時間分散パラメータとを備える、請求項１に記載の方法。
  4. ディレクトリエントリを求めるリクエストを受信することと、
    前記作成時刻と前記少なくとも１つのランダム値とに少なくとも部分的に基づいて、対応するディレクトリエントリの期限が切れたかどうかを判断することと、
    前記ディレクトリエントリの期限が切れている場合に、前記ディレクトリサーバーから前記ディレクトリエントリをリクエストすることと、
    をさらに含む、請求項１に記載の方法。
  5. 前記ディレクトリサーバーにアクセスできないと判断することと、
    前記リクエストを受けて、前記対応する期限切れのキャッシュディレクトリエントリを提供することと、
    をさらに含む、請求項４に記載の方法。
  6. 前記ディレクトリエントリがキャッシュされているかどうかを判断することと、
    前記ディレクトリエントリがキャッシュされていない場合に、前記ディレクトリサーバーから前記ディレクトリエントリをリクエストすることと、
    をさらに含む、請求項４に記載の方法。
  7. 前記ディレクトリサーバーからのレスポンスを受信することと、
    前記ディレクトリサーバーからの前記レスポンスに少なくとも部分的に基づいてデータ整合エラーを検出することと、
    データ整合エラー情報を格納したアラートを管理者に提供することと、
    をさらに含む、請求項４に記載の方法。
  8. 前記ディレクトリサーバーがＬＤＡＰ対応ディレクトリサーバーを備える、請求項１に記載の方法。
  9. 前記リクエストが、前記ディレクトリサーバーのホストとは別のゲートウェイ機器を備える電子デバイスから受信される、請求項４に記載の方法。
  10. 前記リクエストが、前記ディレクトリサーバーのホストとは別の複数のゲートウェイ機器の間にホスト共有キャッシュを備える電子デバイスから受信される、請求項４に記載の方法。
  11. 前記リクエストが、１つまたはそれ以上のキャッシュディレクトリエントリを使用して、ユーザー認証、受信者の妥当性検証、アドレス解決、およびメッセージルーティングのうちの少なくとも１つを提供する電子デバイスを備える電子デバイスから受信される、請求項４に記載の方法。
  12. 請求項１に記載の方法を実行するためのコンピュータ処理を実行するように少なくとも１つのプロセッサに命令するための前記少なくとも１つのプロセッサによって読み取り可能であるように構成されたコンピュータプログラム命令を記憶するための少なくとも１つのプロセッサ読み取り可能な記憶媒体。
  13. ディレクトリサーバーを統合するための製品であって、
    少なくとも１つのプロセッサ読み取り可能な媒体と、
    前記少なくとも１つの媒体に記憶された命令と、
    を備え、前記命令が、少なくとも１つのプロセッサによって前記少なくとも１つの媒体から読み取り可能であるように構成されており、それにより、前記少なくとも１つのプロセッサに、
    複数のキャッシュディレクトリエントリの許容期限の範囲を決定する１つまたはそれ以上のパラメータを設定し、
    電子記憶装置において、ディレクトリサーバーからキャッシュディレクトリエントリを作成し、
    前記キャッシュディレクトリエントリに作成時刻を割り当て、
    前記許容期限の範囲内で前記キャッシュディレクトリエントリの期限を決定する少なくとも１つのランダム値を前記キャッシュディレクトリエントリに割り当て、複数のキャッシュディレクトリエントリの前記許容期限の範囲内で前記キャッシュディレクトリエントリの前記期限をランダム化することにより、ある時点においてキャッシュメモリと前記ディレクトリサーバーとの間で必要とされる同期の量が減少する
    ように動作させる製品。
  14. ディレクトリサーバーを統合するためのシステムであって、
    ネットワークに通信可能に連結された１つまたはそれ以上のプロセッサであって、前記１つまたはそれ以上のプロセッサが、
    複数のキャッシュディレクトリエントリの許容期限の範囲を決定する１つまたはそれ以上のパラメータを設定し、
    ディレクトリサーバーからキャッシュディレクトリエントリを作成し、
    前記キャッシュディレクトリエントリに作成時刻を割り当て、
    前記許容期限の範囲内で前記キャッシュディレクトリエントリの期限を決定する少なくとも１つのランダム値を前記キャッシュディレクトリエントリに割り当て、複数のキャッシュディレクトリエントリの前記許容期限の範囲内で前記キャッシュディレクトリエントリの前記期限をランダム化することにより、ある時点においてキャッシュメモリと前記ディレクトリサーバーとの間で必要とされる同期の量が減少する
    ように構成されている１つまたはそれ以上のプロセッサを備える、システム。
  15. 前記１つまたはそれ以上のプロセッサが、
    ディレクトリエントリを求めるリクエストを受信し、
    前記作成時刻と前記少なくとも１つのランダム値とに少なくとも部分的に基づいて、対応するディレクトリエントリの期限が切れたかどうかを判断し、
    前記ディレクトリエントリの期限が切れている場合に、前記ディレクトリサーバーから前記ディレクトリエントリをリクエストする
    ようにさらに構成されている、請求項１４に記載のシステム。
JP2013508144A 2010-04-27 2011-04-26 ディレクトリサーバーを統合するための技法 Active JP5726290B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US12/768,364 2010-04-27
US12/768,364 US8209491B2 (en) 2010-04-27 2010-04-27 Techniques for directory server integration
PCT/US2011/033874 WO2011139664A1 (en) 2010-04-27 2011-04-26 Techniques for directory server integration

Publications (2)

Publication Number Publication Date
JP2013525920A true JP2013525920A (ja) 2013-06-20
JP5726290B2 JP5726290B2 (ja) 2015-05-27

Family

ID=44121042

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2013508144A Active JP5726290B2 (ja) 2010-04-27 2011-04-26 ディレクトリサーバーを統合するための技法

Country Status (4)

Country Link
US (2) US8209491B2 (ja)
EP (1) EP2564330B1 (ja)
JP (1) JP5726290B2 (ja)
WO (1) WO2011139664A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2016177551A (ja) * 2015-03-20 2016-10-06 株式会社リコー 出力装置、プログラム、出力システム及び出力方法

Families Citing this family (114)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8311058B2 (en) 2008-05-10 2012-11-13 Vantrix Corporation Modular transcoding pipeline
US8347386B2 (en) 2008-10-21 2013-01-01 Lookout, Inc. System and method for server-coupled malware prevention
US8108933B2 (en) 2008-10-21 2012-01-31 Lookout, Inc. System and method for attack and malware prevention
US9235704B2 (en) 2008-10-21 2016-01-12 Lookout, Inc. System and method for a scanning API
US9781148B2 (en) 2008-10-21 2017-10-03 Lookout, Inc. Methods and systems for sharing risk responses between collections of mobile communications devices
US9367680B2 (en) 2008-10-21 2016-06-14 Lookout, Inc. System and method for mobile communication device application advisement
US8984628B2 (en) 2008-10-21 2015-03-17 Lookout, Inc. System and method for adverse mobile application identification
US8533844B2 (en) 2008-10-21 2013-09-10 Lookout, Inc. System and method for security data collection and analysis
US9043919B2 (en) 2008-10-21 2015-05-26 Lookout, Inc. Crawling multiple markets and correlating
US8087067B2 (en) 2008-10-21 2011-12-27 Lookout, Inc. Secure mobile platform system
US8467768B2 (en) 2009-02-17 2013-06-18 Lookout, Inc. System and method for remotely securing or recovering a mobile device
US9955352B2 (en) 2009-02-17 2018-04-24 Lookout, Inc. Methods and systems for addressing mobile communications devices that are lost or stolen but not yet reported as such
US8538815B2 (en) 2009-02-17 2013-09-17 Lookout, Inc. System and method for mobile device replacement
CN102771080B (zh) 2009-12-01 2016-03-16 万特里克斯公司 使用缓存的高效媒体传送的系统和方法
US8290900B2 (en) * 2010-04-24 2012-10-16 Research In Motion Limited Apparatus, and associated method, for synchronizing directory services
US9686228B2 (en) 2010-09-29 2017-06-20 International Business Machines Corporation Integrated just-in-time synchronization
US9219706B2 (en) * 2010-09-29 2015-12-22 International Business Machines Corporation Just-in-time wrapper synchronization
US9311495B2 (en) * 2010-12-09 2016-04-12 International Business Machines Corporation Method and apparatus for associating data loss protection (DLP) policies with endpoints
US8762795B2 (en) * 2010-12-17 2014-06-24 Microsoft Corporation Alerting recipients to errors occurring when accessing external services
US8589406B2 (en) * 2011-03-03 2013-11-19 Hewlett-Packard Development Company, L.P. Deduplication while rebuilding indexes
US8738765B2 (en) 2011-06-14 2014-05-27 Lookout, Inc. Mobile device DNS optimization
US10684989B2 (en) * 2011-06-15 2020-06-16 Microsoft Technology Licensing, Llc Two-phase eviction process for file handle caches
US10460004B1 (en) 2011-06-24 2019-10-29 Amazon Technologies, Inc. Load regulation using dynamically determined time to live values
US9369307B2 (en) 2011-07-12 2016-06-14 Bank Of America Corporation Optimized service integration
US8719919B2 (en) 2011-07-12 2014-05-06 Bank Of America Corporation Service mediation framework
US9015320B2 (en) 2011-07-12 2015-04-21 Bank Of America Corporation Dynamic provisioning of service requests
US8788881B2 (en) 2011-08-17 2014-07-22 Lookout, Inc. System and method for mobile device push communications
US8918602B2 (en) * 2011-09-19 2014-12-23 International Business Machines Corporation Dynamically altering time to live values in a data cache
CN103152317B (zh) * 2011-12-07 2016-07-06 金蝶软件（中国）有限公司 动态验证方法及装置
US20130276069A1 (en) * 2012-03-22 2013-10-17 Socialogue, Inc. Internet identity management
JPWO2013172405A1 (ja) * 2012-05-17 2016-01-12 日本電気株式会社 ストレージシステムおよびデータアクセス方法
US9589129B2 (en) 2012-06-05 2017-03-07 Lookout, Inc. Determining source of side-loaded software
US9407443B2 (en) 2012-06-05 2016-08-02 Lookout, Inc. Component analysis of software applications on computing devices
WO2014011376A1 (en) * 2012-07-12 2014-01-16 Bank Of America Corporation Optimized service integration
ES2441490B1 (es) * 2012-08-02 2015-04-13 Telefónica, S.A. Método y sistema de almacenamiento en caché de web para una red de distribución de contenido (cdn)
US9112922B2 (en) * 2012-08-28 2015-08-18 Vantrix Corporation Method and system for self-tuning cache management
US8655307B1 (en) 2012-10-26 2014-02-18 Lookout, Inc. System and method for developing, updating, and using user device behavioral context models to modify user, device, and application state, settings and behavior for enhanced user security
US9208215B2 (en) 2012-12-27 2015-12-08 Lookout, Inc. User classification based on data gathered from a computing device
US9374369B2 (en) 2012-12-28 2016-06-21 Lookout, Inc. Multi-factor authentication and comprehensive login system for client-server networks
US8855599B2 (en) 2012-12-31 2014-10-07 Lookout, Inc. Method and apparatus for auxiliary communications with mobile communications device
US9424409B2 (en) 2013-01-10 2016-08-23 Lookout, Inc. Method and system for protecting privacy and enhancing security on an electronic device
US9642008B2 (en) 2013-10-25 2017-05-02 Lookout, Inc. System and method for creating and assigning a policy for a mobile communications device based on personal data
US10122747B2 (en) 2013-12-06 2018-11-06 Lookout, Inc. Response generation after distributed monitoring and evaluation of multiple devices
US9753796B2 (en) 2013-12-06 2017-09-05 Lookout, Inc. Distributed monitoring, evaluation, and response for multiple devices
US10360159B1 (en) * 2013-12-12 2019-07-23 Groupon, Inc. System, method, apparatus, and computer program product for providing a cache mechanism
CN104317737A (zh) * 2014-10-10 2015-01-28 浪潮集团有限公司 一种不需要硬件支持实现基于程序同步点高速缓存一致性的方法
EP3289510B1 (en) 2015-05-01 2020-06-17 Lookout Inc. Determining source of side-loaded software
US10798167B2 (en) * 2015-11-25 2020-10-06 International Business Machines Corporation Storage enhanced intelligent pre-seeding of information
US9838377B1 (en) 2016-05-11 2017-12-05 Oracle International Corporation Task segregation in a multi-tenant identity and data security management cloud service
US10454940B2 (en) 2016-05-11 2019-10-22 Oracle International Corporation Identity cloud service authorization model
US9838376B1 (en) 2016-05-11 2017-12-05 Oracle International Corporation Microservices based multi-tenant identity and data security management cloud service
US9781122B1 (en) 2016-05-11 2017-10-03 Oracle International Corporation Multi-tenant identity and data security management cloud service
US10341410B2 (en) 2016-05-11 2019-07-02 Oracle International Corporation Security tokens for a multi-tenant identity and data security management cloud service
US10581820B2 (en) * 2016-05-11 2020-03-03 Oracle International Corporation Key generation and rollover
US10425386B2 (en) 2016-05-11 2019-09-24 Oracle International Corporation Policy enforcement point for a multi-tenant identity and data security management cloud service
US10878079B2 (en) 2016-05-11 2020-12-29 Oracle International Corporation Identity cloud service authorization model with dynamic roles and scopes
US10089025B1 (en) 2016-06-29 2018-10-02 EMC IP Holding Company LLC Bloom filters in a flash memory
US10037164B1 (en) 2016-06-29 2018-07-31 EMC IP Holding Company LLC Flash interface for processing datasets
US10261704B1 (en) 2016-06-29 2019-04-16 EMC IP Holding Company LLC Linked lists in flash memory
US10331561B1 (en) * 2016-06-29 2019-06-25 Emc Corporation Systems and methods for rebuilding a cache index
US10055351B1 (en) 2016-06-29 2018-08-21 EMC IP Holding Company LLC Low-overhead index for a flash cache
US10146438B1 (en) 2016-06-29 2018-12-04 EMC IP Holding Company LLC Additive library for data structures in a flash memory
US10255061B2 (en) 2016-08-05 2019-04-09 Oracle International Corporation Zero down time upgrade for a multi-tenant identity and data security management cloud service
US10263947B2 (en) 2016-08-05 2019-04-16 Oracle International Corporation LDAP to SCIM proxy service
US10530578B2 (en) 2016-08-05 2020-01-07 Oracle International Corporation Key store service
US10735394B2 (en) 2016-08-05 2020-08-04 Oracle International Corporation Caching framework for a multi-tenant identity and data security management cloud service
US10585682B2 (en) 2016-08-05 2020-03-10 Oracle International Corporation Tenant self-service troubleshooting for a multi-tenant identity and data security management cloud service
US10516672B2 (en) 2016-08-05 2019-12-24 Oracle International Corporation Service discovery for a multi-tenant identity and data security management cloud service
US10505941B2 (en) 2016-08-05 2019-12-10 Oracle International Corporation Virtual directory system for LDAP to SCIM proxy service
US10484382B2 (en) 2016-08-31 2019-11-19 Oracle International Corporation Data management for a multi-tenant identity cloud service
CN106131246B (zh) * 2016-09-05 2019-06-21 用友优普信息技术有限公司 Dns解析记录的切换方法及装置
US10594684B2 (en) 2016-09-14 2020-03-17 Oracle International Corporation Generating derived credentials for a multi-tenant identity cloud service
US10846390B2 (en) 2016-09-14 2020-11-24 Oracle International Corporation Single sign-on functionality for a multi-tenant identity and data security management cloud service
US10511589B2 (en) 2016-09-14 2019-12-17 Oracle International Corporation Single logout functionality for a multi-tenant identity and data security management cloud service
US10791087B2 (en) 2016-09-16 2020-09-29 Oracle International Corporation SCIM to LDAP mapping using subtype attributes
US10445395B2 (en) 2016-09-16 2019-10-15 Oracle International Corporation Cookie based state propagation for a multi-tenant identity cloud service
US10341354B2 (en) 2016-09-16 2019-07-02 Oracle International Corporation Distributed high availability agent architecture
JP7018437B2 (ja) 2016-09-16 2022-02-10 オラクル・インターナショナル・コーポレイション マルチテナントアイデンティティおよびデータセキュリティ管理クラウドサービスのためのテナントおよびサービス管理
US10567364B2 (en) 2016-09-16 2020-02-18 Oracle International Corporation Preserving LDAP hierarchy in a SCIM directory using special marker groups
US10484243B2 (en) 2016-09-16 2019-11-19 Oracle International Corporation Application management for a multi-tenant identity cloud service
US10904074B2 (en) 2016-09-17 2021-01-26 Oracle International Corporation Composite event handler for a multi-tenant identity cloud service
US10261836B2 (en) 2017-03-21 2019-04-16 Oracle International Corporation Dynamic dispatching of workloads spanning heterogeneous services
US10454915B2 (en) 2017-05-18 2019-10-22 Oracle International Corporation User authentication using kerberos with identity cloud service
US10218697B2 (en) 2017-06-09 2019-02-26 Lookout, Inc. Use of device risk evaluation to manage access to services
US10348858B2 (en) 2017-09-15 2019-07-09 Oracle International Corporation Dynamic message queues for a microservice based cloud service
US10831789B2 (en) 2017-09-27 2020-11-10 Oracle International Corporation Reference attribute query processing for a multi-tenant cloud service
US11271969B2 (en) 2017-09-28 2022-03-08 Oracle International Corporation Rest-based declarative policy management
US10834137B2 (en) 2017-09-28 2020-11-10 Oracle International Corporation Rest-based declarative policy management
US10705823B2 (en) 2017-09-29 2020-07-07 Oracle International Corporation Application templates and upgrade framework for a multi-tenant identity cloud service
US10715564B2 (en) 2018-01-29 2020-07-14 Oracle International Corporation Dynamic client registration for an identity cloud service
US10931656B2 (en) 2018-03-27 2021-02-23 Oracle International Corporation Cross-region trust for a multi-tenant identity cloud service
US11165634B2 (en) 2018-04-02 2021-11-02 Oracle International Corporation Data replication conflict detection and resolution for a multi-tenant identity cloud service
US10798165B2 (en) 2018-04-02 2020-10-06 Oracle International Corporation Tenant data comparison for a multi-tenant identity cloud service
US11258775B2 (en) 2018-04-04 2022-02-22 Oracle International Corporation Local write for a multi-tenant identity cloud service
US11012444B2 (en) 2018-06-25 2021-05-18 Oracle International Corporation Declarative third party identity provider integration for a multi-tenant identity cloud service
US10764273B2 (en) 2018-06-28 2020-09-01 Oracle International Corporation Session synchronization across multiple devices in an identity cloud service
US11693835B2 (en) 2018-10-17 2023-07-04 Oracle International Corporation Dynamic database schema allocation on tenant onboarding for a multi-tenant identity cloud service
US11321187B2 (en) 2018-10-19 2022-05-03 Oracle International Corporation Assured lazy rollback for a multi-tenant identity cloud service
US11470176B2 (en) * 2019-01-29 2022-10-11 Cisco Technology, Inc. Efficient and flexible load-balancing for clusters of caches under latency constraint
US11651357B2 (en) 2019-02-01 2023-05-16 Oracle International Corporation Multifactor authentication without a user footprint
US11061929B2 (en) 2019-02-08 2021-07-13 Oracle International Corporation Replication of resource type and schema metadata for a multi-tenant identity cloud service
US11321343B2 (en) 2019-02-19 2022-05-03 Oracle International Corporation Tenant replication bootstrap for a multi-tenant identity cloud service
US11669321B2 (en) 2019-02-20 2023-06-06 Oracle International Corporation Automated database upgrade for a multi-tenant identity cloud service
US11423111B2 (en) 2019-02-25 2022-08-23 Oracle International Corporation Client API for rest based endpoints for a multi-tenant identify cloud service
US11792226B2 (en) 2019-02-25 2023-10-17 Oracle International Corporation Automatic api document generation from scim metadata
US10754559B1 (en) * 2019-03-08 2020-08-25 EMC IP Holding Company LLC Active-active storage clustering with clock synchronization
US11870770B2 (en) 2019-09-13 2024-01-09 Oracle International Corporation Multi-tenant identity cloud service with on-premise authentication integration
US11687378B2 (en) 2019-09-13 2023-06-27 Oracle International Corporation Multi-tenant identity cloud service with on-premise authentication integration and bridge high availability
CN111046070B (zh) * 2019-11-21 2023-08-18 深圳前海环融联易信息科技服务有限公司 一种智能缓存数据方法、装置、计算机设备及存储介质
US11611548B2 (en) 2019-11-22 2023-03-21 Oracle International Corporation Bulk multifactor authentication enrollment
US11778025B1 (en) * 2020-03-25 2023-10-03 Amazon Technologies, Inc. Cross-region directory service
CN113537734B (zh) * 2021-06-28 2023-02-03 国网福建省电力有限公司经济技术研究院 基于最大相关最小冗余的能源数据应用目录提取方法
CN113467896A (zh) * 2021-07-28 2021-10-01 咪咕数字传媒有限公司 一种集群服务的限流方法、装置、计算设备和存储介质
US11768767B2 (en) 2021-10-29 2023-09-26 Micro Focus Llc Opaque object caching

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0822410A (ja) * 1994-07-05 1996-01-23 Toshiba Corp 分散ディレクトリシステムを実現する情報処理装置及び方法
JPH10124372A (ja) * 1996-10-18 1998-05-15 Nippon Telegr & Teleph Corp <Ntt> 自律キャッシュ制御システム
US20040267876A1 (en) * 2003-06-30 2004-12-30 Microsoft Corporation Ad-hoc service discovery protocol
JP2005032150A (ja) * 2003-07-10 2005-02-03 Ntt Comware Corp Ｗｅｂサービス提供サーバ、その方法及びプログラム
JP2008198158A (ja) * 2007-02-16 2008-08-28 Rakuten Inc 情報提供システム、情報提供装置、適正判定情報生成方法及び適正判定情報生成処理プログラム
JP2010501941A (ja) * 2006-08-21 2010-01-21 アマゾン テクノロジーズ インコーポレーテッド キャッシュ・エントリの一致性検索のための確率テクニック

Family Cites Families (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5590320A (en) * 1994-09-14 1996-12-31 Smart Storage, Inc. Computer file directory system
US5608892A (en) * 1995-06-09 1997-03-04 Alantec Corporation Active cache for a microprocessor
US5778395A (en) * 1995-10-23 1998-07-07 Stac, Inc. System for backing up files from disk volumes on multiple nodes of a computer network
GB2311880A (en) * 1996-04-03 1997-10-08 Advanced Risc Mach Ltd Partitioned cache memory
US5974507A (en) * 1997-04-14 1999-10-26 International Business Machines Corporation Optimizing a cache eviction mechanism by selectively introducing different levels of randomness into a replacement algorithm
US6092149A (en) * 1997-05-28 2000-07-18 Western Digital Corporation Disk drive cache system using a dynamic priority sequential stream of data segments continuously adapted according to prefetched sequential random, and repeating types of accesses
US6026445A (en) * 1997-11-17 2000-02-15 International Business Machines Corporation System and method for saving and reusing recently acquired name to address mappings
US6272593B1 (en) * 1998-04-10 2001-08-07 Microsoft Corporation Dynamic network cache directories
US6487547B1 (en) * 1999-01-29 2002-11-26 Oracle Corporation Database appliance comprising hardware and software bundle configured for specific database applications
US6839739B2 (en) * 1999-02-09 2005-01-04 Hewlett-Packard Development Company, L.P. Computer architecture with caching of history counters for dynamic page placement
WO2000057315A2 (en) 1999-03-25 2000-09-28 Microsoft Corporation Extended file system
US6754696B1 (en) * 1999-03-25 2004-06-22 Micosoft Corporation Extended file system
EP1139232B1 (en) * 2000-03-30 2003-06-04 INTERSHOP Software Entwicklungs GmbH Cache time determination
WO2003001413A1 (en) * 2001-06-22 2003-01-03 Nosa Omoigui System and method for knowledge retrieval, management, delivery and presentation
US7065558B2 (en) * 2002-02-22 2006-06-20 Microsoft Corporation Opportunistic directory cache and method of serving target directory information in a network environment
US7069389B2 (en) * 2003-11-26 2006-06-27 Microsoft Corporation Lazy flushing of translation lookaside buffers
US8739274B2 (en) * 2004-06-30 2014-05-27 Citrix Systems, Inc. Method and device for performing integrated caching in a data communication network
US7996644B2 (en) * 2004-12-29 2011-08-09 Intel Corporation Fair sharing of a cache in a multi-core/multi-threaded processor by dynamically partitioning of the cache
US20060179174A1 (en) * 2005-02-02 2006-08-10 Bockhaus John W Method and system for preventing cache lines from being flushed until data stored therein is used
US7555608B2 (en) * 2006-02-13 2009-06-30 Intel Corporation Techniques to manage a flow cache
US7555597B2 (en) * 2006-09-08 2009-06-30 Intel Corporation Direct cache access in multiple core processors
US8185694B2 (en) * 2008-07-25 2012-05-22 International Business Machines Corporation Testing real page number bits in a cache directory
US8108197B2 (en) * 2008-12-04 2012-01-31 International Business Machines Corporation Method to verify an implemented coherency algorithm of a multi processor environment
US8271737B2 (en) * 2009-05-27 2012-09-18 Spansion Llc Cache auto-flush in a solid state memory device

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0822410A (ja) * 1994-07-05 1996-01-23 Toshiba Corp 分散ディレクトリシステムを実現する情報処理装置及び方法
JPH10124372A (ja) * 1996-10-18 1998-05-15 Nippon Telegr & Teleph Corp <Ntt> 自律キャッシュ制御システム
US20040267876A1 (en) * 2003-06-30 2004-12-30 Microsoft Corporation Ad-hoc service discovery protocol
JP2005032150A (ja) * 2003-07-10 2005-02-03 Ntt Comware Corp Ｗｅｂサービス提供サーバ、その方法及びプログラム
JP2010501941A (ja) * 2006-08-21 2010-01-21 アマゾン テクノロジーズ インコーポレーテッド キャッシュ・エントリの一致性検索のための確率テクニック
JP2008198158A (ja) * 2007-02-16 2008-08-28 Rakuten Inc 情報提供システム、情報提供装置、適正判定情報生成方法及び適正判定情報生成処理プログラム

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2016177551A (ja) * 2015-03-20 2016-10-06 株式会社リコー 出力装置、プログラム、出力システム及び出力方法

Also Published As

Publication number Publication date
EP2564330A1 (en) 2013-03-06
US20110264865A1 (en) 2011-10-27
WO2011139664A1 (en) 2011-11-10
US8209491B2 (en) 2012-06-26
JP5726290B2 (ja) 2015-05-27
US20120191918A1 (en) 2012-07-26
EP2564330B1 (en) 2018-02-14
US8370580B2 (en) 2013-02-05

Similar Documents

Publication Publication Date Title
JP5726290B2 (ja) ディレクトリサーバーを統合するための技法
JP5675963B2 (ja) ディレクトリデータを解決するための技法
US11895188B2 (en) Distributed storage system with web services client interface
US20210224233A1 (en) Method using access information in a distributed file server virtual machine (fsvm) architecture, including web access
US8862644B2 (en) Data distribution system
US8775373B1 (en) Deleting content in a distributed computing environment
US20080033966A1 (en) System and method for recovery detection in a distributed directory service
US9009196B2 (en) Discovery and client routing to database nodes
US20070234331A1 (en) Targeted automatic patch retrieval
US8417679B1 (en) Fast storage writes
US20230237170A1 (en) Consistent access control lists across file servers for local users in a distributed file server environment
JP2004531817A (ja) クラスタ化コンピュータ・システムにおけるグループ・アクセス専用化
US12095852B2 (en) Scalable processing of domain name system queries for a global server load balancing service
Jang NFS and DFS A Functional Comparison

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20140206

RD02 Notification of acceptance of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7422

Effective date: 20140206

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20140612

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20140819

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20141114

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20150303

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20150331

R150 Certificate of patent or registration of utility model

Ref document number: 5726290

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

S111 Request for change of ownership or part of ownership

Free format text: JAPANESE INTERMEDIATE CODE: R313113

S531 Written request for registration of change of domicile

Free format text: JAPANESE INTERMEDIATE CODE: R313531

S533 Written request for registration of change of name

Free format text: JAPANESE INTERMEDIATE CODE: R313533

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250