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

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02Addressing or allocation; Relocation
    • G06F12/08Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/12Replacement control
    • G06F12/121Replacement control using replacement algorithms
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22Indexing; Data structures therefor; Storage structures
    • G06F16/2228Indexing structures
    • G06F16/2246Trees, 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

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

Description

本開示は、概してディレクトリデータサービスに関し、詳細にはディレクトリサーバーを統合するための技法に関する。
ディレクトリデータサービスは、ユーザー認証、メッセージ配送、およびグループポリシーの適用を含む様々なクライアントおよびアプリケーションにディレクトリデータを提供し得る。ディレクトリデータサービスは、例えば企業クラスのメッセージングセキュリティなど、高スループットが重要である複数の用途を果たし得る。アプリケーションおよび/またはディレクトリデータサービスは、キャッシュされたディレクトリデータを使用して性能を高め、ディレクトリサーバーにかかる負荷を減らす。ただし、キャッシュされたディレクトリデータは、ディレクトリサーバーに周期的に問い合わせることによってリフレッシュされないと、「陳腐化」、すなわち古くなり得る。キャッシュされたディレクトリデータを更新すると、多量のキャッシュデータが周期的に更新されるため、ディレクトリサーバーに大きな負担がかかり、大幅な性能の低下が生じ得る。性能の低下により、ひいては、ディレクトリデータサービスを使用するクライアントおよびアプリケーションに影響が及び得る。
上記内容から、現在のディレクトリサーバー統合技術に関わる重大な課題および欠点が存在し得るものと理解され得る。
ディレクトリサーバーを統合するための技法が開示される。特定の一例示的実施形態において、技法は、複数のキャッシュディレクトリエントリの許容期限の範囲を決定する1つまたはそれ以上のパラメータを設定することと、電子記憶装置で、ディレクトリサーバーからキャッシュディレクトリエントリを作成することと、キャッシュディレクトリエントリに作成時刻を割り当てることと、許容期限の範囲内でキャッシュディレクトリエントリの期限を決定する少なくとも1つのランダム値をキャッシュディレクトリエントリに、割り当てることと、を含む、ディレクトリサーバーを統合するための方法として実現されてよく、キャッシュディレクトリエントリの期限を複数のキャッシュディレクトリエントリの許容期限の範囲内でランダム化することにより、ある時点においてキャッシュメモリとディレクトリサーバーとの間で必要とされる同期の量が減少する。
この特定の例示的実施形態の他の態様によれば、キャッシュディレクトリエントリの許容期限の範囲を決定する1つまたはそれ以上のパラメータは、最大生存時間パラメータと最小生存時間パラメータとを備え得る。
この特定の例示的実施形態のさらなる態様によれば、キャッシュディレクトリエントリの許容期限の範囲を決定する1つまたはそれ以上のパラメータは、生存時間パラメータと生存時間分散パラメータとを備え得る。
この特定の例示的実施形態のさらなる態様によれば、技法は、ディレクトリエントリを求めるリクエストを受信することと、作成時刻と少なくとも1つのランダム値とに少なくとも部分的に基づいて、対応するディレクトリエントリの期限が切れているかどうかを判断することと、ディレクトリエントリの期限が切れている場合に、ディレクトリサーバーにディレクトリエントリをリクエストすることと、をさらに含み得る。
この特定の例示的実施形態のさらなる態様によれば、技法は、ディレクトリサーバーにアクセスできないと判断することと、リクエストを受けて、対応する期限切れのキャッシュディレクトリエントリを提供することと、をさらに含み得る。
この特定の例示的実施形態のさらなる態様によれば、技法は、ディレクトリエントリがキャッシュされているどうかを判断することと、ディレクトリエントリがキャッシュされていない場合に、ディレクトリサーバーにディレクトリエントリをリクエストすることと、をさらに含み得る。
この特定の例示的実施形態のさらなる態様によれば、技法は、ディレクトリサーバーからのレスポンスを受信することと、ディレクトリサーバーからのレスポンスに少なくとも部分的に基づいてデータ整合エラーを検出することと、データ整合エラー情報を格納したアラートを管理者に提供することと、をさらに含み得る。
この特定の例示的実施形態のさらなる態様によれば、ディレクトリサーバーは、LDAP対応ディレクトリサーバーを備え得る。
この特定の例示的実施形態のさらなる態様によれば、リクエストは、ディレクトリサーバーのホストとは別のゲートウェイ機器を備え得る電子デバイスから受信され得る。
この特定の例示的実施形態のさらなる態様によれば、リクエストは、ディレクトリサーバーのホストとは別の複数のゲートウェイ機器間のホスト共有キャッシュを備える電子デバイスから受信され得る。
この特定の例示的実施形態のさらなる態様によれば、リクエストは、1つまたはそれ以上のキャッシュディレクトリエントリを使用して、ユーザー認証、受信者の妥当性検証、アドレス解決、およびメッセージルーティングのうちの少なくとも1つを提供する電子デバイスを備える電子デバイスから受信され得る。
この特定の例示的実施形態のさらなる態様によれば、技法は、少なくとも1つのプロセッサに、方法を実行するためのコンピュータ処理を実行するように命令するために、少なくとも1つのプロセッサによって読み取り可能に構成されたコンピュータプログラム命令を記憶するための少なくとも1つのプロセッサ読み取り可能な記憶媒体として実現され得る。
別の特定の例示的実施形態において、技法は、少なくとも1つのプロセッサ読み取り可能な媒体を備える、ディレクトリサーバーを統合するための製品として実現され得る。命令は、少なくとも1つの媒体に記憶されてよく、命令は、少なくとも1つのプロセッサによって少なくとも1つの媒体から読み取り可能であるように、かつ、それによって少なくとも1つのプロセッサに、複数のキャッシュディレクトリエントリの許容期限の範囲を決定する1つまたはそれ以上のパラメータを設定し、電子記憶装置で、キャッシュディレクトリエントリをディレクトリサーバーから作成し、キャッシュディレクトリエントリに作成時刻を割り当て、キャッシュディレクトリエントリの期限を許容期限の範囲内で決定少なくとも1つのランダム値をキャッシュディレクトリエントリに割り当てるように動作させるように構成されており、複数のキャッシュディレクトリエントリの許容期限の範囲内でキャッシュディレクトリエントリの期限をランダム化することにより、ある時点においてキャッシュメモリとディレクトリサーバーとの間で必要とされる同期の量が減少する。
さらに別の特定の例示的実施形態において、技法は、ネットワークに通信可能に連結された1つまたはそれ以上のプロセッサを備える、ディレクトリサーバーを統合するためのシステムとして実現されてよく、1つまたはそれ以上のプロセッサは、複数のキャッシュディレクトリエントリの許容期限の範囲を決定する1つまたはそれ以上のパラメータを設定し、キャッシュディレクトリエントリをディレクトリサーバーから作成し、キャッシュディレクトリエントリに作成時刻を割り当て、キャッシュディレクトリエントリの期限を許容期限の範囲内で決定する少なくとも1つのランダム値をキャッシュディレクトリエントリに割り当てるように構成されており、複数のキャッシュディレクトリエントリの許容期限の範囲内でキャッシュディレクトリエントリの期限をランダム化することにより、ある時点においてキャッシュメモリとディレクトリサーバーとの間で必要とされる同期の量が減少する。
この特定の追加例示的実施形態の他の態様によれば、キャッシュディレクトリエントリの許容期限の範囲を決定する1つまたはそれ以上のパラメータは、最大生存時間パラメータと最小生存時間パラメータとを備え得る。
この特定の追加例示的実施形態のさらなる態様によれば、キャッシュディレクトリエントリの許容期限の範囲を決定する1つまたはそれ以上のパラメータは、生存時間パラメータと生存時間分散パラメータとを備え得る。
この特定の例示的実施形態のさらなる態様によれば、1つまたはそれ以上のプロセッサは、ディレクトリエントリのリクエストを受信し、作成時刻と少なくとも1つのランダム値とに少なくとも部分的に基づいて、対応するディレクトリエントリの期限が切れているかどうかを判断し、ディレクトリエントリの期限が切れている場合に、ディレクトリサーバーにディレクトリエントリをリクエストするようにさらに構成され得る。
この特定の例示的実施形態のさらなる態様によれば、1つまたはそれ以上のプロセッサは、ディレクトリサーバーにアクセスできないと判断し、リクエストに対して、対応する期限切れのキャッシュディレクトリエントリを提供するようにさらに構成され得る。
この特定の例示的実施形態のさらなる態様によれば、1つまたはそれ以上のプロセッサは、ディレクトリエントリがキャッシュされているどうかを判断し、ディレクトリエントリがキャッシュされていない場合に、ディレクトリサーバーにディレクトリエントリをリクエストするようにさらに構成され得る。
この特定の例示的実施形態のさらなる態様によれば、1つまたはそれ以上のプロセッサは、ディレクトリデータサービスのホストとは別のゲートウェイ機器の一部を備え得る。
この特定の例示的実施形態のさらなる態様によれば、1つまたはそれ以上のプロセッサは、1つまたはそれ以上のキャッシュディレクトリエントリを使用して、ユーザー認証、受信者の妥当性検証、アドレス解決、およびメッセージルーティングのうちの少なくとも1つを提供するようにさらに構成され得る。
さらに別の特定の例示的実施形態において、技法は、ディレクトリサーバーにディレクトリエントリをリクエストすることと、プロセッサを使用して、ディレクトリサーバーからのレスポンスに少なくとも部分的に基づいてデータ整合エラーを検出することと、データ整合エラー情報を格納したアラートを管理者に提供することと、を含む、ディレクトリサーバーを統合するための方法として実現され得る。
この特定の例示的実施形態のさらなる態様によれば、データ整合エラーは、電子メールアドレスの重複、ユーザー名の重複、行方不明または無効な属性データ、および循環グループ関係のうちの少なくとも1つを含み得る。
これより、本開示について、添付の図面に示す本開示の例示的実施形態を参照しながら、さらに詳しく説明する。本開示について、例示的実施形態を参照しながら以下説明するが、本開示はこれらの実施形態に制限されないことを理解すべきである。本明細書の教示にアクセスできる当業者であれば、さらなる実施態様、変更態様、および実施形態、さらには、本明細書に記載されている本開示の範囲内であり、かつ本開示が大きな有用性を持つであろう他の使用分野を認識するであろう。
本開示について十分な理解を促すために、添付の図面を参照する。図面中、同様の要素は同様の番号で参照されている。これらの図面は、本開示を制限するものと解釈されるべきなく、例示のみを意図するものである。
本開示の一実施形態にかかる、ディレクトリサーバーを統合するためのネットワークアーキテクチャを表すブロック図を示す。 本開示の一実施形態にかかるコンピュータシステムのブロック図を表す。 本開示の一実施形態にかかる、ディレクトリサーバーを統合するためのモジュールを示す。 本開示の一実施形態にかかる、ディレクトリサーバーを統合するための方法を表す。 本開示の一実施形態にかかる、ディレクトリサーバーを統合するための方法を表す。 本開示の一実施形態にかかる、ディレクトリデータサービスのキャッシュパラメータを設定するためのインターフェースを表す。 本開示の一実施形態にかかる、ディレクトリデータサービスのキャッシュパラメータを設定するためのインターフェースを表す。 本開示の一実施形態にかかる、クエリフィルタトークンを使用してディレクトリエントリを一致させる方法を表す。
図1は、本開示の一実施形態にかかる、ディレクトリサーバーを統合するためのネットワークアーキテクチャ100を表すブロック図を示す。図1は、ネットワークアーキテクチャ100の簡略図であり、表されていない追加要素を含み得る。ネットワークアーキテクチャ100は、クライアントシステム110、120および130に加え、ディレクトリサーバー140(1)−(N)およびネットワークデバイス170(1)−(N)も含み得る(そのうちの1つまたはそれ以上が、図2に示すコンピュータシステム200を使用して実装され得る)。クライアントシステム110、120および130は、ネットワーク150に通信可能に連結され得る。ディレクトリサーバー140(1)−(N)は、記憶デバイス160(1)−(N)に通信可能に連結され得る。ネットワークデバイス170(1)−(N)は、管理モジュール(例えばディレクトリデータサービス154)を格納し得る。
図2のコンピュータシステム200を参照すると、クライアントシステム110、120および130のうちの1つまたはそれ以上からネットワーク150への接続を提供するために、モデム247、ネットワークインターフェース248、またはその他何らかの方法が使用され得る。クライアントシステム110、120および130は、例えば、ライトウェイトディレクトリアクセスプロトコル(LDAP)クライアントまたは他のクライアントソフトウェアを使用して、ディレクトリサーバー140(1)−(N)にある情報にアクセス可能であり得る。かかるクライアントにより、クライアントシステム110、120および130が、ディレクトリサーバー140(1)−(N)か、あるいは記憶デバイス160(1)−(N)のうちの1つによってホストされるデータにアクセスでき得る。
ネットワーク150および/または180は、ローカルエリアネットワーク(LAN)、ワイドエリアネットワーク(WAN)、インターネット、セルラー方式ネットワーク、衛星ネットワーク、または、クライアント110、120、130、ディレクトリサーバー140(1)−(N)、およびネットワーク150および/または180に通信可能に連結された他のデバイスとの間での通信を許可する別のネットワークであり得る。ネットワーク150および/または180は、スタンドアロンネットワークとして、あるいは互いに協同して動作する上記例示的なタイプのネットワークのうちの1つまたは任意の数をさらに含み得る。ネットワーク150および/または180は、通信可能に連結された1つまたはそれ以上のクライアントまたはサーバーのうちの1つまたはそれ以上のプロトコルを利用し得る。ネットワーク150および/または180は、ネットワークデバイスのうちの1つまたはそれ以上のプロトコルと他のプロトコルとの間での変換を行い得る。ネットワーク150および180は、単一のネットワークとして各々表されているが、1つまたはそれ以上の実施形態によれば、ネットワーク150および/または180が複数の相互接続されたネットワークを備え得ることが理解されるべきである。
記憶デバイス160(1)−(N)は、ネットワークアクセス可能記憶装置であってよく、ディレクトリサーバー140(1)−(N)に対してローカル、リモート、またはそれらの組み合わせであってもよい。記憶デバイス160(1)−(N)は、低価格ディスクの冗長配列(「RAID」)、磁気テープ、ディスク、記憶装置エリアネットワーク(「SAN」)、インターネット小型コンピュータシステムインターフェース(「iSCSI」) SAN、ファイバチャネルSAN、共通インターネットファイルシステム(「CIFS」)、ネットワーク接続型記憶装置(「NAS」)、ネットワークファイルシステム(「NFS」)、光学ベース記憶装置、または他のコンピュータアクセス可能記憶装置を利用してもよい。記憶デバイス160(1)−(N)は、バックアップまたはアーカイブ目的で使用されてもよい。
いくつかの実施形態によれば、クライアント110、120、および130は、スマートフォン、PDA、デスクトップコンピュータ、ラップトップコンピュータ、サーバー、他のコンピュータ、またはネットワーク150に無線または有線接続経由で連結された他のデバイスであり得る。クライアント110、120、および130は、ユーザー入力、データベース、ファイル、ウェブサービス、および/またはアプリケーションプログラミングインターフェースからデータを受信し得る。
ディレクトリサーバー140(1)−(N)は、例えば、Microsoft(登録商標) Active Directory(登録商標)サーバー、IBM(登録商標) Lotus(登録商標) Domino(登録商標)サーバー、Sun(登録商標)ディレクトリサーバー、LDAP対応ディレクトリサーバー、データベースサーバー、1つまたはそれ以上のフラットファイルまたは他のデータ構造を格納するサーバー(例えばXML)、あるいはネットワーク150に通信可能に連結された他のデバイスなどのディレクトリサーバー実施態様の1つまたはそれ以上のホストであり得る。ディレクトリサーバー140(1)−(N)は、アプリケーションデータ、バックアップデータ、または他のデータを記憶するための記憶デバイス160(1)−(N)のうちの1つまたはそれ以上を利用し得る。ディレクトリサーバー140(1)−(N)のうちの1つまたはそれ以上は、アプリケーションサーバーなど、クライアント110、120、および130に対するデータリクエストを処理し得るホストであり得る。
いくつかの実施形態によれば、ネットワーク180は、インターネットを表し得る。そしてネットワークデバイス170は、企業WANまたはLANであり得るネットワーク150とネットワーク180との間の多量のデータトラフィックを扱うデバイスであり得る。例えば、ネットワークデバイス170のうちの1つまたはそれ以上は、メールゲートウェイ、ウェブゲートウェイ、あるいは、ユーザー認証および/または認可、識別情報管理、受信者の妥当性検証、アドレス解決、メッセージルーティング、アクセス制御、または他のアプリケーション挙動のためにディレクトリデータサービスを使用する別の機器またはアプリケーションであり得る。非制限的な例として、ネットワークデバイス170のうちの1つまたはそれ以上が、Symantec(登録商標) Brightmail(登録商標) Gateway、Symantec(登録商標) Web Gateway、Symantec(登録商標) Data Loss Prevention Host、Symantec(登録商標) Endpoint Protection Application、またはBrightmail(登録商標) Message Filterであり得る。ネットワークデバイス170のうちの1つまたはそれ以上は、ディレクトリデータサービス154を使用して、1つまたはそれ以上のディレクトリサーバーからのキャッシュデータを管理する。いくつかの実施形態によれば、各ネットワークデバイス170は、自身のデータをキャッシュし得る。1つまたはそれ以上の実施形態によれば、キャッシュデータは、ネットワークデバイス170のうちの2つまたはそれ以上の間で共有され得る。例えば、ネットワークデバイス170(1)は、複数のBrightmail Gatewayスキャナのコントロールセンターホストであり得る。コントロールセンターホストは、Brightmail Gatewayスキャナであり得る複数の他のネットワークデバイス170間で共有されるキャッシュディレクトリサービスデータを含み得る。キャッシュデータは、ネットワークデバイス170に記憶され得るか、あるいはネットワークデバイス170に通信可能に連結された電子記憶装置に記憶され得る。
ディレクトリデータサービス154は、ネットワークデバイスの構成要素、モジュール、あるいは、ディレクトリデータキャッシュ動作を管理するために統合されたハードウェアおよびソフトウェアの別の組み合わせであり得る。いくつかの実施形態によれば、ディレクトリデータサービス154は、高スループット処理用のディレクトリデータサービスを使用して、ゲートウェイ機器あるいは別の装置またはアプリケーションとのディレクトリ統合を行うための統一サービス指向アーキテクチャを提供し得る。
ディレクトリデータサービス154は、例えばディレクトリサーバー140(1)などのディレクトリサーバーからキャッシュデータを管理できるようにし得る。ディレクトリデータサービス154は、ディレクトリデータのリクエストも管理し得る。データをキャッシュすることにより、メールゲートウェイなどのネットワークデバイスの動作が高速化され得るし、1つまたはそれ以上のディレクトリサーバー140からの負担が軽減され得る。ただし、初期キャッシュをビルドすると、負荷が大きくなる可能性がある。1つまたはそれ以上の実施形態によれば、ディレクトリデータサービス154は、ネットワークデバイスによって使用される前に、キャッシュされたディレクトリデータを事前に読み込み得る。キャッシュデータは、(例えば、ディレクトリサーバーで行われた可能性のあるディレクトリデータに対する変更を省略するなど)「陳腐化」しないように周期的にリフレッシュされる必要があり得る。多数のキャッシュエントリは、同時に、あるいは同じ短時間内に作成され得る。同じ生存時間(TTL)、またはキャッシュエントリの期限切れを決定する他の同様の設定を用いて多数のキャッシュエントリを設定すると、短時間に多数のキャッシュエントリをリフレッシュするために、ディレクトリサーバーに多数のクエリが出される可能性がある。この好ましくない挙動は、ディレクトリサーバーおよび/またはディレクトリサーバーを使用するアプリケーションまたはデバイスにおけるスパイク、性能障害、あるいは他の好ましくない挙動の原因となり得る。
本開示の1つまたはそれ以上の実施形態によれば、同じ時点で多数のキャッシュエントリがディレクトリサーバーにリフレッシュリクエスト(例えば、LDAP対応ディレクトリサーバーに対するLDAPクエリ)に課せられることのないように、キャッシュエントリの期限(例えばTTL設定)は多様であり得る。例えば、複数のキャッシュディレクトリエントリの許容期限の範囲を決定する1つまたはそれ以上のパラメータが、管理者によって設定され得る。ディレクトリデータサービス154は、ユーザーインターフェースを提供し得るし、かつ/または設定されたパラメータを受容し得る。ディレクトリデータサービスからキャッシュディレクトリエントリが作成されると、そのエントリは、ディレクトリデータサービス154によって作成時刻が割り当てられ得る。キャッシュディレクトリエントリは、ディレクトリデータサービス154によって1つまたはそれ以上のランダム値が割り当てられ得る。1つまたはそれ以上のランダム値は、キャッシュディレクトリエントリの期限(例えば生存時間(TTL))を許容期限の範囲内で決定し得る。複数のキャッシュディレクトリエントリの許容期限の範囲内でキャッシュディレクトリエントリの期限をランダム化することにより、ある時点でネットワークデバイス170のキャッシュメモリとディレクトリサーバー140との間で必要とされる同期の量(例えばリフレッシュリクエスト)が減少し得る。そのため、キャッシュエントリは、ディレクトリサーバーでパフォーマンススパイクまたは他の性能低下が起こらないように、TTL設定を、許容される生存時間設定の範囲全体に分散させ得る。
いくつかの実施形態によれば、管理者または他のユーザーは、最大生存時間パラメータおよび最小生存時間パラメータを設定することによってキャッシュディレクトリエントリの許容期限の範囲を決定してもよい。キャッシュエントリは、最大生存時間パラメータおよび最小生存時間パラメータによって決定される範囲内で期限満了日または生存時間設定が割り当てられ得る。生存時間設定は、キャッシュディレクトリエントリの作成時に設定されてもよい。他の実施形態によれば、管理者または他のユーザーは、生存時間パラメータおよび生存時間分散パラメータを設定することによってキャッシュディレクトリエントリの許容期限の範囲を決定してもよい。生存時間分散パラメータは、キャッシュディレクトリエントリが生存時間パラメータから変動し得る最大量を決定し得る。例えば、生存時間分散パラメータは、パーセンテージ(例えば0%と100%との間のパーセンテージ)で表され得る。生存時間分散パラメータは、小数に変換され、1から減算され、その後TTLによって乗算されて最小TTLを決定し得る。次に生存時間分散パラメータは、小数に変換され、1に加算され、その後TTLによって乗算されて最大TTLを決定し得る。他の方法およびパラメータは、個々のキャッシュエントリのTTL設定を分散させる生存時間設定の範囲を特定または決定する目的で使用され得る。いくつかの実施形態によれば、TTL範囲、TTL、またはTTL分散は、1つまたはそれ以上の要因に基づいて増減し得る。例えば、TTLおよび/またはTTLの範囲は、キャッシュサイズ、ディレクトリサーバーの負荷または他の要因に基づいて増減し得る。ディレクトリデータソースは、特定のディレクトリサーバーに接続し、問い合わせる方法を指定し得るディレクトリデータサービス(DDS)の構成であり得る。1つまたはそれ以上の実施形態によれば、TTL範囲は、ディレクトリデータソースに基づいて異なり得る。例えば、キャッシュの一部分が第1のディレクトリデータソースと関連付けられており、第2のキャッシュの一部分が第2のディレクトリデータソースと関連付けられている場合、異なる部分には異なるTTL範囲が割り当てられ得る。
いくつかの実施形態によれば、キャッシュエントリの期限が切れたかどうかは、キャッシュエントリの作成時刻からの経過時間を計算し、その経過時間をエントリの生存時間(TTL)と比較することによって判断され得る。例えば、経過時間は次式で計算され得る。
elapsed=(currentTime−creationTime)×1000;//秒
上述のとおり、キャッシュエントリのTTLを計算する目的で使用されるいくつかの異なるアルゴリズムが存在し得る。例えば、エントリの生存時間(entryTTL)は次式で計算され得る。
entryTTL=minTTL+((maxTTL−minTTL)×(ttlSpreadFactor/100.0));//秒
ttlSpreadFactorは、0と100(両端値を含む)間のランダム数(例えば50)であり得る。MinTTLは、キャッシュエントリの最小生存時間を表し、最大TTLはエントリの最大生存時間を表し得る。したがって、MinTTLおよびMaxTTLは許容範囲を判断し得る。そしてttlSpreadfactorは、その範囲に沿ってキャッシュエントリを分散させる目的で使用されるランダム数であり得る。
経過時間およびキャッシュエントリの生存時間が決定されたら、期限の判断は以下のようになり得る。
isExpired=(elapsed>entryTTL)
キャッシュエントリの期限が切れている場合には、ディレクトリデータサービス154が、ディレクトリサーバーに問い合わせること(例えば、LDAP対応ディレクトリサーバーに対するLDAPクエリ)によってキャッシュエントリのリフレッシュを試行し得る。キャッシュエントリは、キャッシュで受信され、新たに設定された作成時刻と新たに計算されたTTLとを用いて更新または作成され得る。
いくつかの実施形態によれば、キャッシュディレクトリエントリの期限が切れており、対応するディレクトリサーバーが利用できない場合、キャッシュディレクトリエントリは、たとえ期限が切れていても、リクエストを受けて提供され得る。ディレクトリサーバーが別のディレクトリサーバー(例えば、同じディレクトリエントリを含むディレクトリサーバー)に対して冗長である場合には、ディレクトリサーバーに対するクエリが第1のサーバーから第2のサーバーにフェイルオーバーされ得る。例えば、冗長ディレクトリサーバーにフェイルオーバーするには、ラウンドロビンDNS(ドメイン名サーバー)方式が使用され得る。いくつかの実施形態によれば、ロードバランシングおよび/またはフェイルオーバーは、ディレクトリサーバー(例えばLDAP)ティアで実施され得る。1つまたはそれ以上の実施形態によれば、データアクセスの失敗(例えば、ネットワークの問題や、ディレクトリサーバーの停止)が発生したときに、ディレクトリデータサービス154は、キャッシュが利用可能であれば、キャッシュからのデータで以てリクエストにサービスする。このため、サイズ限度を超えない限り、データソースキャッシュからデータが削除されることはない。例えば、いくつかのデータアクセスの失敗が短時間で検出された場合に開始し得る高速フェイルオーバーモードが存在し得る。このモードでは、キャッシュデータが利用可能であれば、期限が切れているかどうかに関係なく、データソースに直ちにキャッシュデータにサービスし得るか、あるいは、データアクセスコールのオーバーヘッドを受けることなく、直ちに失敗させて例外処理(例えばDataAccessUnavailableException)を実行し得る。これにより、ディレクトリデータサービス154は、ディレクトリサーバーのリソースが利用できない場合でも高スループットを維持することができ得る。一実施形態によれば、ディレクトリデータサービス154の高速フェイルオーバー構成は、以下のように実装され得る。
データアクセスの失敗が120秒間で5回検出されたら、300秒間の高速フェイルオーバーに切り替わる。特定のリクエストについて、フェイルオーバー先のキャッシュデータが存在しない場合、ディレクトリデータサービス(DDS)コールが一時エラーで失敗し得る。受信者の妥当性検証の場合、かかる一時エラーはSMTP(シンプルメールトランスファープロトコル)エラーとなる可能性があり、上流の送信者にそのメッセージを再試行するように命令し得る。他の機能の場合、これらのエラーにより、メッセージが各種内部MTA(メッセージトランスファーエージェント)キューに残る可能性があり、そこで再試行され得る。
いくつかの実施形態によれば、キャッシュデータは、冗長ディレクトリデータソースに優先し得る。ディレクトリデータソースとキャッシュとの間での優先順位は設定可能であってよい。例えば、SourceAおよびSourceBという2つの同一の受信者妥当性検証ソースを用いてシステムが構成された場合を考えてみる。ここではSourceAがクエリ順序における最初のソースである。通常の状況下では、有効な受信者に対してSourceAだけが問い合わせられ得る。早期終了およびスティッキーリフレッシュにより、それらの受信者がSourceBにアクセスしないようにし得る。早期終了とは、検索結果の一意性を検証することなく、複数のデータソースを用いて構成されたディレクトリデータサービスに対する検索を終了することであり得る(例えば、受信者の妥当性検証の場合、リクエストされたディレクトリエントリが見つかる最初のデータソースで検索が停止し得る)。スティッキーリフレッシュとは、キャッシュ内のディレクトリエントリが特定のデータソースと関連付けられており、ディレクトリエントリの期限が切れたときに、ディレクトリデータサービスが、そのデータソースからのディレクトリエントリのリフレッシュを試行するように定義された設定のことであり得る(例えば、ディレクトリエントリが同じデータソースからリフレッシュされ得る限り、システム内の他のデータソースは問い合わせられない)。通常の状況下では、無効な受信者に対して両方のソースが問い合わせられ得る。SourceAが停止している場合には、キャッシュされた有効な受信者に対してSourceAのキャッシュからサービスされ得るため、SourceBが参照されない場合がある。SourceAが停止している場合、キャッシュされていない有効な受信者はSourceBからサービスされ得る。スティッキーリフレッシュにより、キャッシュされていない有効な受信者はその後もSourceBからサービスされ得る。SourceAが停止している場合、キャッシュされているが期限が切れていない無効な受信者は、通常の状況下と同様に扱われ得る。SourceAが停止している場合、キャッシュされた無効な受信者、あるいはキャッシュされているが期限が切れている無効な受信者は、リクエスタに後で再試行するように命令するエラーをもたらし得る。2つのディレクトリデータソースは、冗長あるいは非連結であり得るため、受信者は、停止中のディレクトリデータソース(例えばソースA)で有効であり、他のどのソースにも見つからない場合でも無効でない可能性がある。
いくつかの実施形態によれば、SourceBが停止している場合には、キャッシュされた有効な受信者がSourceAのキャッシュからサービスされ得るため、SourceBが参照されない場合がある。SourceBが停止している場合、キャッシュされていない有効な受信者はSourceAからサービスされ得る。早期終了およびスティッキーリフレッシュにより、キャッシュされていない有効な受信者はその後もSourceAからサービスを提供され得る。SourceBが停止している場合、キャッシュされているが期限が切れていない無効な受信者は、通常の状況下と同様に扱われ得る。
SourceBが停止している場合、キャッシュされた無効な受信者、あるいはキャッシュされているが期限が切れている無効な受信者は、リクエスタに後で再試行するように命じるエラーをもたらし得る。
ディレクトリデータソースが停止していても、利用可能であれば、キャッシュデータにフェイルオーバーし得る。ディレクトリデータサービス154は、データアクセスエラーを記録して、データアクセスアラートを生成し得る。ただし、ディレクトリデータサービス154は、引き続き他のデータソースを検索してもよい。一意のエントリが健全なソースのうちの1つに見つかれば、そのコールは成功する可能性があり、スティッキーリフレッシュは、そのエントリを求める以降の要求をそのソースに向け得る。1つより多くのエントリが見つかった場合には、重複エラーが記録され得る。そして、ディレクトリデータサービス154は、データ整合アラートを生成し得る。一致するエントリが見つからない場合には、リクエストが一時エラーで失敗し、再試行され得る。
いくつかの実施形態によれば、ディレクトリデータサービス154は、1つまたはそれ以上のデータ整合エラーまたは他のエラーを検出し得る。そして、そのエラーと関連付けられた記録および/またはアラート通知を提供し得る。例えば、ディレクトリデータサービス154は、処理中にデータエラーに遭遇し得る。そしてエラーを記録し、かつ/またはアラートを管理者に提供し得る。検出されたエラーは、非制限的な例として、電子メールアドレスの重複、ユーザー名重複、行方不明または無効な属性データ(例えば、行方不明の電子メールアドレス、無効な電子メールアドレスフォーマット、存在しないエントリを参照しているグループメンバーシップ属性、および下位および上位グループメンバーシップ属性の不整合値)、および循環グループ関係を含み得る。ディレクトリデータサービス154は、各種ディレクトリデータと統合し得る。例えば、ディレクトリデータサービス154は、LDAPディレクトリ、SQLデータベース、および/またはフラットファイルを格納しているサーバーであり得るディレクトリサーバー140(1)...(N)にアクセスし得る。ディレクトリデータサービス154は、電子メールアドレスまたは他のデータを探すディレクトリサーバー(例えばLDAPクエリ)にアクセスし得る。受信したデータに基づいて、ディレクトリデータサービス154はデータ整合エラーを検出し得る。受信した電子メールアドレスが、単一のデータソースに、または複数のデータソースにまたがって存在する複数のディレクトリエントリに対応し得るか、あるいはユーザー名が、単一のデータソースに、または複数のデータソースにまたがって存在する複数のディレクトリエントリに対応し得る。いくつかの実施形態によれば、データ整合エラーに加え、ディレクトリデータサービス154によって扱われる他のエラーとしては、ディレクトリデータアクセスエラー(例えば、LDAPサーバーからデータを読み込めなかった)、過小データソースキャッシュエラー(例えば、データソースキャッシュまたはキャッシュインデックスが、リクエストされたメモリ内データのすべてを保持できるだけの大きさがないことを示している)、および/またはデータ複製エラー(データ複製動作が失敗したことを示している)を含み得る。
ディレクトリデータサービス154は、ディレクトリサーバーデータアクセスアラートを提供し得る。このタイプのアラートは、ディレクトリデータサービス154がディレクトリサーバー(例えばLDAPサーバー)からデータを読み込めない場合にトリガーされ得る。これは、様々な理由で起こり得る。いくつかの例は、LDAPサーバーの停止、ネットワークインフラストラクチャの問題、DNSの問題、ファイアウォールルールのブロックリクエスト、不良データソース管理バインド証明書、および/またはLDAP検索タイムアウトを含み得る。
ディレクトリデータサービス154によって扱われる他のアラートは、ディレクトリサーバーデータ整合アラートを含み得る。このタイプのアラートは、リクエストが正常に実行されるのを妨げるディレクトリデータに関する問題をディレクトリデータサービス154が検出したときにトリガーされ得る。リクエストの失敗に至らないデータ整合の問題は、ディレクトリデータサービス154によって「警告」レベルで記録され得るため、アラートをトリガーしない場合がある。受信者の妥当性検証について、受信者アドレスでの検索に対して複数のエントリ(単一のデータソース内に、あるいは複数のソースにまたがって存在)が返された場合、このイベントは、ディレクトリデータサービス154によって「情報」レベルで記録され得るため、アラートが生成されない場合がある。複製された受信者は、受信者の妥当性検証機能上、有効であるとみなされ得る。
以下のデータ整合エラーは、アラートをトリガーし得る。
電子メールアドレス(単一のデータソース内に、あるいは複数のソースにまたがって存在)での検索に対して1つより多くのエントリが返される。
ユーザー名(単一のデータソース内に、あるいは複数のソースにまたがって存在)での検索に対して1つより多くのエントリが返される。
以下のデータ整合問題は、ディレクトリデータサービス154によって「警告」レベルで記録され得るため、アラートをトリガーしない場合がある。循環グループ参照、無効なグループメンバーシップ属性値、行方不明のプライマリ電子メール属性値、および/または電子メールアドレス値の無効フォーマット。
循環グループ参照は、ディレクトリサーバーがグループメンバーシップを判断するために上から下へとトラバースしているときにディレクトリデータサービス154によって認識され得る。例えば、グループAがグループBのメンバーであり、グループBがグループAのメンバーである場合に、ディレクトリデータサービス154がこれを検出してエラーを記録し得る。グループの関係は、多数のレベルに及び深いネスト構造になっていることがあるために、循環グループ参照がいくつか下のレベルで発生し得る。例えば、グループが上位から下位にA〜Eのネスト構造になっていると仮定すると、グループBがグループEのメンバーである可能性があり、循環グループ参照をもたらし得る。いくつかの実施形態によれば、ツリー(すなわちグループ)の特定ノードが以前にアクセスされていると判断し得る再帰的ツリートラバースアルゴリズムが使用され得る。これが循環グループ参照を表し得る。循環グループ参照は、データソース(例えば単一のディレクトリサーバー)で、あるいはデータソースにまたがって検出され得る。
ディレクトリデータサービス154は、DDSキャッシュサイズアラートを提供し得る。このタイプのアラートは、ディレクトリデータサービス154が、データアクセス層から取り出された新規エントリ用のスペースを確保するために、期限が切れる前にキャッシュエントリを追い出すときにトリガーされ得る。管理者は、アラートおよびログステートメントを参照して適切な措置をとり得る。例示的なアラートは以下を含む。
Entry Cache
修復方法:キャッシュサイズを増やす。
Recipient Ref Cache(電子メールアドレスに関するキャッシュインデックス)
修復方法:キャッシュインデックスサイズ乗数(すなわち、キャッシュインデックスサイズ=(N×キャッシュサイズ)と設定するパラメータNなど、キャッシュインデックスのサイズを決定するパラメータ)を増やす。
User Ref Cache(ユーザー名に関するキャッシュインデックス)
修復方法:キャッシュインデックスサイズ乗数を増やす。
アラートファイルが、ホスト、特定タイプのアラート条件、およびトリガー事象の時期を伝達し得る。アラートテキストは、管理者に、システムログファイルを参照して追加診断情報を確認するよう促し得る。これにより、開発への影響を抑えつつ、アラート機能の変更または拡張が可能となり得る。
生成されたアラート電子メールは、以下の情報を含み得る。
アラートイベントのタイムスタンプ、
アラートイベントのホスト識別子、
アラートイベント(例えばディレクトリデータサービス154)を生成した構成要素、および
所定のディレクトリデータサービスステータスコードに対応するローカライズされたメッセージ。
ステータスコードは大雑把である可能性があり、特定のコードに至る可能性のある多数の潜在的なエラー状況が存在し得る。アラートメカニズムは、特定ホスト上のDDSインスタンスが特定時期にリクエストを処理できなかったことを単に伝えるだけであり得る。そして根本原因についての詳細な情報はログを参照するように管理者に示し得る。
DDSデータアクセスアラート、DDSデータ整合アラート、DDSキャッシュサイズアラート、ユーザー設定複製アラート、または他のタイプのアラートのうちの1つまたはそれ以上のサブタイプを使用可能または使用不可にするためのユーザーインターフェース要素(例えばチェックボックス)が存在してもよい。
ディレクトリデータサービス154は、1つまたはそれ以上のデータ整合エラーまたは他のエラーを記録し得る。そしてアラートが別のメカニズムによって生成され得る。例えば、ディレクトリデータサービス154は、ディスク上、あるいは他の電子ストレージにアラートファイルを作成し得る。アラートファイルは、タイムスタンプと、アラート条件のタイプを表す識別子とを格納し得る。ネットワークデバイス170上で実行中のプロセスまたはエージェントが、周期的にアラートファイルをポーリングし、アラートメタデータを処理し、1人またはそれ以上のユーザー(例えば、登録されたシステム管理者)にアラート電子メールを送り得る。他の通信チャネルが、SMSテキストメッセージ、ボイスメール、および/またはウェブページ投稿などをユーザーに通知する目的で使用され得る。いくつかの実施形態によれば、ディレクトリデータサービス154は、追加プロセスまたはエージェントを使用せずに直接アラートを送り得る。1つまたはそれ以上の実施形態によれば、ディレクトリデータサービス154または別のプロセスが、インターフェースを使用して(例えば、SNMP、Windows System Event、またはカスタムIPC(プロセス間通信)を介して)アラートを送り得る。
ディレクトリデータサービス154によるデータ整合エラーの検出およびシステム管理者への迅速なアラート通知により、システムの性能低下または故障が起きる前にシステム管理者が問題に対処することを可能にし得る。
図2は、本開示の一実施形態にかかるコンピュータシステム200のブロック図を表す。コンピュータシステム200は、本開示にかかる技法を実施するのに適している。コンピュータシステム200は、中央プロセッサ214など、コンピュータシステム210の主要サブシステムを相互接続し得るバス212と、システムメモリ217(例えば、RAM(ランダムアクセスメモリ)、ROM(読み出し専用メモリ、フラッシュRAMなど)と、入出力(I/O)コントローラ218と、音声出力インターフェース222を介するスピーカシステム220などの外部のオーディオデバイスと、ディスプレイアダプタ226を介するディスプレイスクリーン224などの外部デバイスと、シリアルポート228および230と、キーボード232(キーボードコントローラ233を介して仲介)と、記憶装置インターフェース234と、フロッピーディスク238を受容するように動作可能なフロッピーディスクドライブ237と、ファイバチャネルネットワーク290と接続するように動作可能なホストバスアダプタ(HBA)インターフェースカード235Aと、SCSIバス239に接続するように動作可能なホストバスアダプタ(HBA)インターフェースカード235Bと、光学ディスク242を受容するように動作可能な光学ディスクドライブ240と、を備え得る。また、マウス246(または他のポイントアンドクリックデバイス、シリアルポート228を介してバス212に連結)と、モデム247(シリアルポート230を介してバス212に連結)と、ネットワークインターフェース248(バス212に直接連結)と、電源マネージャ250と、バッテリ252と、も備え得る。
バス212は、上記のとおり、中央プロセッサ214とシステムメモリ217との間でのデータ通信を可能にする。システムメモリ217は、読み出し専用メモリ(ROM)またはフラッシュメモリ(どちらも図示せず)と、ランダムアクセスメモリ(RAM)(図示せず)とを含み得る。RAMは、オペレーティングシステムおよびアプリケーションプログラムが読み込まれ得るメインメモリであり得る。ROMまたはフラッシュメモリは、他のコードと共に、周辺構成要素との相互動作など、基本的なハードウェア動作を制御する基本入出力システム(BIOS)を格納することができる。コンピュータシステム210に存在するアプリケーションは、ハードディスクドライブ(例えば固定ディスク244)、光学ドライブ(例えば光学ドライブ240)、フロッピーディスクユニット237、または他の記憶媒体など、コンピュータ読み取り可能な媒体に記憶され、かかる媒体を介してアクセスされ得る。例えば、ディレクトリデータサービス154は、システムメモリ217に存在し得る。
記憶装置インターフェース234は、コンピュータシステム210の他の記憶装置インターフェースと同様、固定ディスクドライブ244など、情報を記憶および/または取得するための標準的なコンピュータ読み取り可能な媒体に接続することができる。固定ディスクドライブ244は、コンピュータシステム210の一部であってよく、あるいは別々になっており、他のインターフェースシステムを通じてアクセスされるようになっていてもよい。モデム247は、電話リンク経由でリモートサーバーとの、あるいはインターネットサービスプロバイダ(ISP)経由でインターネットとの直接接続を提供し得る。ネットワークインターフェース248は、POP(通信アクセスポイント)を経由するインターネットとの直接ネットワークリンクを介してリモートサーバーとの直接接続を提供し得る。ネットワークインターフェース248は、デジタルセルラー方式電話接続、セルラー方式デジタルパケットデータ(CDPD)接続、デジタル衛星データ接続などを含む無線技法を用いてかかる接続を提供してもよい。
その他多くの装置またはサブシステム(明示せず)が、同様の方法(例えば、文書スキャナ、デジタルカメラなど)で接続されてもよい。逆に言えば、本開示を実施するのに、図2に示す装置のすべてが存在する必要はない。これらの装置およびサブシステムは、図2に示すものとは別の方法で相互接続することもできる。本開示を実装するコードは、システムメモリ217、固定ディスク244、光学ディスク242、またはフロッピーディスク238のうちの1つまたはそれ以上などのコンピュータ読み取り可能な記憶媒体に記憶され得る。本開示を実装するコードは、1つまたはそれ以上のインターフェースを介して受信され、メモリに記憶され得る。コンピュータシステム210に設けられるオペレーティングシステムは、MS−DOS(登録商標)、MS−WINDOWS(登録商標)、OS/2(登録商標)、OS X(登録商標)、UNIX(登録商標)、Linux(登録商標)、または別の公知のオペレーティングシステムであり得る。
電源マネージャ250は、バッテリ252の電力レベルを監視し得る。電源マネージャ250は、電力レベルを判断できるようにするための1つまたはそれ以上のAPI(アプリケーションプログラミングインターフェース)、コンピュータシステム200がシャットダウンするまでの残り時間窓、電力消費率、コンピュータシステムが電源(例えばAC電源)かバッテリのどちらで稼働しているかを示すインジケータ、または他の電力関連情報を提供し得る。いくつかの実施形態によれば、電源マネージャ250のAPIは、リモートアクセスが可能(例えば、ネットワーク接続経由でリモートバックアップ管理モジュールにアクセス可能)であり得る。いくつかの実施形態によれば、バッテリ252は、コンピュータシステム200に対してローカルまたはリモートに位置する無停電電源装置(UPS)であり得る。かかる実施形態では、電源マネージャ250がUPSの電力レベルに関する情報を提供し得る。
図3を参照すると、本開示の一実施形態にかかるディレクトリデータサービスモジュール154が示されている。図示のとおり、ディレクトリデータサービスモジュール154は、ディレクトリデータサービス(DDS)キャッシュ管理モジュール312、ディレクトリデータサービス整合管理モジュール314、ディレクトリデータサービスグループメンバーシップ管理モジュール316、ディレクトリデータサービスクエリ一般化モジュール318、およびエラー記録およびレポートモジュール320を含む1つまたはそれ以上の構成要素を格納し得る。
下記の記述は、ネットワーク要素、コンピュータ、および/または1つまたはそれ以上のモジュールを含み得る、ディレクトリサーバーを統合するためシステムおよび方法の構成要素について記載している。本明細書で使用されるとおり、「モジュール」という用語は、計算ソフトウェア、ファームウェア、ハードウェア、および/またはそれらの各種組み合わせを言及するものと理解され得る。ただし、モジュールは、ハードウェアやファームウェアに実装されたり、プロセッサ読み取り可能な記録可能記憶媒体に記録されたりすることのないソフトウェアと解釈されるべきでない(すなわち、モジュール自体はソフトウェアでない)。なお、モジュールは例示的なものである。モジュールは、各種アプリケーションをサポートするために組み合わせ、統合、分離、および/または複製され得る。また、本明細書において特定のモジュールで実行中であると記載されている機能は、1つまたはそれ以上の他のモジュールで、および/または特定のモジュールで実行され得る機能の代わりに、あるいはその機能に加えて1つまたはそれ以上の他のデバイスによって実行され得る。さらに、モジュールは、互いにローカルであり、かつ/またはリモートである複数のデバイスまたは他の構成要素にまたがって実装され得る。加えて、モジュールは、あるデバイスから移動させて別の装置に追加してもよく、かつ/または両方のデバイスに含まれてもよい。
ディレクトリデータサービス(DDS)キャッシュ管理モジュール312は、キャッシュ管理のうちの1つまたはそれ以上の態様を扱い得る。例えば、DDSキャッシュ管理モジュール312は、TTL設定、TTL範囲、または他のキャッシュ期限パラメータを受信、計算、および/または設定し得る。DDSキャッシュ管理モジュール312は、1つまたはそれ以上のTTLパラメータ、キャッシュエントリの作成時刻、作成時刻からの経過時間、および/または他の要因に基づいてキャッシュエントリを期限切れにする時期を判断し得る。DDSキャッシュ管理モジュール312は、データソースキャッシュおよびキャッシュインデックスのキャッシュサイズ限度およびキャッシュエントリ追い出しポリシーを確立し得る。キャッシュインデックスサイズは、1つまたはそれ以上のパラメータ(例えば、キャッシュインデックスのサイズを、関連付けられたデータソースキャッシュの単純な倍数と定め得るキャッシュインデックス乗数パラメータ)によって判断され得る。
DDSキャッシュ管理モジュール312は、1つまたはそれ以上の設定および/または検出された状況に基づいてフェイルオーバー挙動を判断し得る。DDSキャッシュ管理モジュール312は、データソースおよび/またはキャッシュ間での優先順位の設定を受信、設定、および/または実施し得る。
ディレクトリデータサービス整合管理モジュール314は、1つまたはそれ以上のデータ整合エラーまたは他のエラーを検出し得る。そして、そのエラーと関連付けられた記録またはアラート通知を提供し得る。例えば、ディレクトリデータサービス整合管理モジュール314は、処理中にデータエラーに遭遇し得る。そしてエラーを記録し、かつ/またはアラートを管理者に提供し得る。検出されたエラーは、非制限的な例として、電子メールアドレスの重複、ユーザー名重複、行方不明または無効な属性データ(例えば、行方不明の電子メールアドレス、無効な電子メールアドレスフォーマット、存在しないエントリを参照しているグループメンバーシップ属性、および下位および上位グループメンバーシップ属性の不整合値)、および循環グループ関係を含み得る。ディレクトリデータサービス整合管理モジュール314は、各種ディレクトリデータと統合し得る。例えば、ディレクトリデータサービス整合管理モジュール314は、LDAPディレクトリ、SQLデータベース、および/またはフラットファイルを格納しているサーバーであり得るディレクトリサーバー140(1)...(N)にアクセスし得る。ディレクトリデータサービス整合管理モジュール314は、ディレクトリエントリまたは他のデータを探すディレクトリサーバーに(例えばLDAPクエリ経由で)アクセスし得る。受信したデータに基づいて、ディレクトリデータサービス整合管理モジュール314はデータ整合エラーを検出し得る。例えば、電子メールアドレスまたはユーザー名での検索は、単一のデータソースにある複数のディレクトリエントリに対応し得る。もしくは、ユーザー名が、単一のデータソースにある、あるいは複数のデータソースにまたがる複数のディレクトリエントリに対応し得る。いくつかの実施形態によれば、データ整合エラーに加えて、ディレクトリデータサービス整合管理モジュール314によって認識される他のエラーは、ディレクトリデータアクセスエラー(例えば、LDAPサーバーからデータを読み込めなかった)、過小データソースキャッシュエラー(例えば、データソースキャッシュまたはキャッシュインデックスが、リクエストされたメモリ内データのすべてを保持できるだけの大きさがないことを示している)、および/またはデータ複製エラー(データ複製動作が失敗したことを示している)を含み得る。
循環グループ参照は、ディレクトリサーバーがグループメンバーシップを判断するために上から下へとトラバースしているときにディレクトリデータサービス整合管理モジュール314によって認識され得る。例えば、グループAがグループBのメンバーであり、グループBがグループAのメンバーである場合に、ディレクトリデータサービス整合管理モジュール314がこれを検出してエラーを記録し得る。グループの関係は、多数のレベルに深いネスト構造になっていることがあるために、循環グループ参照がいくつか下のレベルで発生し得る。例えば、グループが上位から下位にA〜Eのネスト構造になっていると仮定すると、グループBがグループEのメンバーである可能性があり、循環グループ参照をもたらし得る。いくつかの実施形態によれば、ツリー(すなわちグループ)の特定ノードが以前にアクセスされていると判断し得る再帰的ツリートラバースアルゴリズムが使用され得る。これが循環グループ参照を表し得る。循環グループ参照は、単一のデータソース内、あるいは複数のデータソースにまたがって検出され得る。
ディレクトリデータサービス整合管理モジュール314は、1つまたはそれ以上のデータ整合エラーまたは他のエラーを記録し得る。そしてアラートが別のメカニズムによって生成され得る。例えば、ディレクトリデータサービス整合管理モジュール314は、ディスク上、あるいは他の電子ストレージにアラートファイルを作成し得る。アラートファイルは、タイムスタンプと、アラート条件のタイプを表す識別子を格納し得る。ネットワークデバイス170上で実行中のプロセスまたはエージェントが、周期的にアラートファイルをポーリングし、アラートメタデータを処理し、1人またはそれ以上のユーザー(例えば、登録されたシステム管理者)にアラート電子メールを送り得る。他の通信チャネルが、SMSテキストメッセージ、ボイスメール、および/またはウェブページ投稿などをユーザーに通知する目的で使用され得る。いくつかの実施形態によれば、ディレクトリデータサービス154は、別のプロセスまたはエージェントを使用せずに直接アラートを送ってもよい。1つまたはそれ以上の実施形態によれば、ディレクトリデータサービス整合管理モジュール314または別のプロセス、構成要素、あるいはモジュールが、インターフェースを使用して(例えば、SNMP、Windows System Event、またはカスタムIPC(プロセス間通信)を介して)アラートを送ってもよい。
ディレクトリデータサービス整合管理モジュール314によるデータ整合エラーの検出およびシステム管理者への迅速なアラート通知により、システムの性能低下または故障が起きる前にシステム管理者が問題に対処することを可能にし得る。
ディレクトリデータサービスグループメンバーシップ管理モジュール316は、グループのメンバーを特定するために、1つまたはそれ以上のディレクトリデータソースをトラバースし得る。ディレクトリデータサービスグループメンバーシップ管理モジュール316は、上位グループメンバーシップ、下位グループメンバーシップ、またはそれらの両方を解決し得る。
ディレクトリデータサービスクエリ一般化モジュール318により、ディレクトリサーバーに対するクエリ(例えばLDAPクエリ)が、クエリフィルタトークンまたは他のメカニズムを使用して、電子メールエイリアスの一致を含むがこれに限定されない様々なディレクトリ検索基準を規定できるようになり得る。クエリフィルタトークンとエイリアスとの一致については、図8と関連させて、以下でさらに詳述されている。
エラー記録およびレポートモジュール320は、ディレクトリサーバーを統合に関連するログ、レポート、または他の情報を生成し得る。
図4を参照すると、本開示の一実施形態にかかるディレクトリサーバーを統合するための方法400が示されている。図4は、ディレクトリサーバー統合を高レベルで表している。例えば、エントリがディレクトリサーバーに存在するかどうかを判断するためのテストなど、他の要素が追加されてもよい。ブロック402で、方法400が開始され得る。
ブロック404で、方法によって生存時間範囲が割り当てられ得る。生存時間範囲は、管理者により、1つまたはそれ以上のパラメータを使用して指定され得る。いくつかの実施形態によれば、管理者または他のユーザーは、最大生存時間パラメータおよび最小生存時間パラメータを設定することにより、キャッシュディレクトリエントリの許容期限の範囲を決定してもよい。キャッシュエントリは、最大生存時間パラメータおよび最小生存時間パラメータによって決定される範囲内で期限満了日または生存時間設定が割り当てられ得る。生存時間設定は、キャッシュディレクトリエントリの作成時に設定されてもよい。他の実施形態によれば、管理者または他のユーザーは、生存時間パラメータおよび生存時間分散パラメータを設定することによってキャッシュディレクトリエントリの許容期限の範囲を決定してもよい。生存時間分散パラメータは、キャッシュされたディレクトリが生存時間パラメータから変動し得る最大量を決定し得る。例えば、生存時間分散パラメータは、パーセンテージ(例えば0%と100%との間のパーセンテージ)で表され得る。生存時間分散パラメータは、小数に変換され、1から減算され、その後TTLによって乗算されて最小TTLを決定し得る。次に生存時間分散パラメータは、小数に変換され、1に加算され、その後TTLによって乗算されて最大TTLを決定し得る。他の方法およびパラメータは、個々のキャッシュエントリのTTL設定を分散させる生存時間設定の範囲を特定または決定する目的で使用され得る。
ブロック406で、ディレクトリエントリのリクエストが受信され得る。例えば、ゲートウェイが、受信者の妥当性検証、メッセージルーティング、認証、ポリシーの適用、疑わしいスパム電子メールの隔離、または他の目的でディレクトリデータをリクエストし得る。
ブロック408で、リクエストされたディレクトリエントリがキャッシュされたかどうかが判断され得る。リクエストされたディレクトリエントリがキャッシュされている場合には、方法がブロック410で続行し得る。リクエストされたディレクトリエントリがキャッシュされていない場合には、方法がブロック414で続行し得る。
ブロック410で、方法410により、エントリの期限が切れているかどうかが判断され得る。いくつかの実施形態によれば、キャッシュエントリの期限が切れているかどうかは、キャッシュエントリの作成時刻からの経過時間を計算し、キャッシュディレクトリエントリの経過時間を生存時間設定と比較することによって判断され得る。キャッシュエントリのTTLを計算する目的で使用されるいくつかの異なるアルゴリズムが存在し得る。例えば、エントリの生存時間(entryTTL)は次式で計算され得る。
entryTTL=minTTL+((maxTTL−minTTL)×(ttlSpreadFactor/100.0));//秒
ttlSpreadFactorは、0と100(両端値を含む)間のランダム数(例えば50)であり得る。MinTTLは、キャッシュエントリの最小生存時間を表し、最大TTLはエントリの最大生存時間を表し得る。したがって、MinTTLおよびMaxTTLは許容範囲を判断し得る。そしてttlSpreadfactorは、その範囲に沿ってキャッシュエントリを分散させる目的で使用されるランダム数であり得る。
ブロック412で、キャッシュエントリの期限が切れていない場合には、リクエストに対応するためにキャッシュされたエントリ情報が提供され得る。
ブロック414で、ディレクトリサーバーにアクセス可能かどうかが判断され得る。ディレクトリサーバーにアクセス可能である場合、方法はブロック416で続行し得る。ディレクトリサーバーにアクセス可能でない場合、方法はブロック424で終了し得る。いくつかの実施形態(点線によって明示)によれば、ディレクトリサーバーにアクセス可能でない場合には、キャッシュされたエントリ情報がブロック412で提供され得る。例えば、図1に関して上記のとおり、いくつかのデータアクセスの失敗が短時間で検出された場合に開始し得る高速フェイルオーバーモードが存在し得る。このモードでは、キャッシュデータが利用可能であれば、期限が切れているかどうかに関係なく、データソースに直ちにキャッシュデータにサービスし得るか、あるいは、データアクセスコールのオーバーヘッドを受けることなく、直ちに失敗させて例外処理(例えばDataAccessUnavailableException)を実行し得る。
ブロック416で、ディレクトリサーバーまたはソースからディレクトリエントリが取り出され、キャッシュディレクトリエントリが作成され得る。
ブロック418で、キャッシュディレクトリエントリに作成時刻が割り当てられ得る。
ブロック420で、キャッシュディレクトリエントリの生存時間(TTL)を判断し得るキャッシュディレクトリエントリに絶対ランダム値が割り当てられ得る。ランダム値は、管理者によって指定された範囲内でTTLを割り当て得る。いくつかの実施形態によれば、ランダム値を割り当てる他の方法が使用されてもよい。図5に関して後述するとおり、生存時間(TTL)分布係数が使用されもよい。
ブロック422で、リクエストを受けてディレクトリエントリ情報が返され得る。
ブロック424で、方法400が終了し得る。
図5を参照すると、本開示の一実施形態にかかるディレクトリサーバーを統合するための方法500が示されている。ブロック502で、方法500が、ディレクトリオブジェクトのリクエストから開始され得る。
ブロック504で、リクエストがLDAP識別名(DN)(例えば、「userid=jmsmith、dc=domain、dc=com」)で検索しているかどうかが判断され得る。リクエストが識別名を使用して検索している場合、方法はブロック528で続行し得る。リクエストが別の属性(例えば、電子メールアドレス「jsmith@domain.com」またはユーザー名「jsmith」)を使用して検索している場合、方法はブロック506で続行し得る。
ブロック506で、識別名以外の属性を使用して検索するためにキャッシュインデックスが使用され得る。
ブロック508で、エントリがキャッシュインデックスに見つかったかどうかが判断され得る。対応するエントリが見つかった場合、方法はブロック522で続行し得る。見つからなかった場合、方法はブロック510で続行し得る。
ブロック510で、特定されたキャッシュインデックスキーに対応する属性値によってディレクトリサーバーが検索され得る。
ブロック512で、特定されたキャッシュインデックスエントリキーを使用してディレクトリエントリが見つかった場合、方法はブロック524で続行し得る。見つからなかった場合、方法はブロック514で続行し得る。
ブロック514で、キャッシュインデックスのオブジェクト参照が作成され得る。
ブロック516で、キャッシュインデックスのオブジェクト参照に作成時刻が割り当てられ得る。
ブロック518で、キャッシュインデックスオブジェクトに生存時間(TTL)分布係数が割り当てられ得る。TTL分布係数は、ランダム数(例えば0〜100(両端値を含む))であってよく、以降、TTL値の指定許容範囲内でキャッシュインデックスオブジェクトのTTLを判断する目的で使用され得る。いくつかの実施形態によれば、ランダム値を割り当てる他の方法が使用されてもよい。例えば、図4に関して上記のとおり、絶対ランダム数が使用されてもよい。
ブロック520で、オブジェクト参照がキャッシュインデックスに記憶され得る。
ブロック522で、キャッシュインデックスで特定されたエントリの期限が切れているかどうかが判断され得る。エントリの期限が切れている場合、方法はブロック510で続行し得る。キャッシュインデックスにおける特定されたエントリの期限が切れていない場合、方法はブロック528で続行し得る。
ブロック524で、エントリがディレクトリサーバーで見つからない場合には、対応するオブジェクトがキャッシュインデックスから削除されてもよい。
ブロック526で、エントリ不検出メッセージが返され得る。
ブロック528で、識別名を使用してエントリキャッシュが検索され得る。
ブロック530で、エントリが見つかったかどうかが判断され得る。エントリキャッシュにエントリが見つかった場合、方法500はブロック532で続行し得る。エントリが見つからなかった場合、方法500はブロック534で続行し得る。
ブロック532で、エントリの期限が切れたかどうか判断するために、特定されたディレクトリキャッシュエントリがテストされ得る。上記のとおり、期限切れかどうかは、TTL分布係数、作成日、および作成日からの経過時間を含む1つまたはそれ以上の属性または設定を使用して判断され得る。キャッシュディレクトリエントリの期限が切れた場合、方法500はブロック534で続行し得る。キャッシュディレクトリエントリの期限が切れていない場合、方法はブロック548で続行し得る。
ブロック534で、識別名(DN)を使用してディレクトリサーバーが検索され得る。
ブロック536で、リクエストされたオブジェクトに一致するディレクトリエントリがディレクトリサーバーに見つかったかどうかが判断され得る。ディレクトリエントリが見つかった場合、方法はブロック540で続行し得る。エントリが見つからなかった場合、方法500はブロック538で続行し得る。
ブロック538で、対応するオブジェクトがエントリキャッシュから削除され得る。
ブロック540で、対応するディレクトリキャッシュエントリが作成され得る。
ブロック542で、キャッシュディレクトリエントリに作成時刻が割り当てられ得る。
ブロック544で、エントリキャッシュオブジェクトに生存時間(TTL)分布係数が割り当てられ得る。TTL分布係数は、ランダム数(例えば、0〜100(両端値を含む))であってよく、以降、生存値の許容範囲の範囲内でエントリキャッシュオブジェクトのTTLを判断する目的で使用され得る。いくつかの実施形態によれば、ランダム値を割り当てる他の方法が使用されてもよい。例えば、図4に関して上記のとおり、絶対ランダム数が使用されてもよい。
ブロック546で、ディレクトリエントリオブジェクトがキャッシュに記憶され得る。
ブロック548で、方法が終了し得る。
図6A、図6B、および図6Cを参照すると、本開示の一実施形態にかかるディレクトリデータサービスのキャッシュパラメータを設定するためのインターフェースが表されている。キャッシュエントリ期限をランダム化するための様々な方法が使用され得る。例えば、図5に関して上記のとおり、正規化されたTTLSpreadFactorにキャッシュエントリが割り当てられ得る。TTLSpreadFactorは、他のパラメータ(例えば、MinTTLパラメータおよびmaxTTLパラメータ)が変更されたときにキャッシュエントリのTTLを適切に増大低減し得る。他の実施形態は、作成時刻にキャッシュエントリに割り当てられた絶対ランダムTTLを使用し得る。この割り当ては、指定(例えば、minTTLパラメータおよびmaxTTLパラメータによって指定)された範囲内である。別の実施形態は、ディレクトリオブジェクトがキャッシュからリクエストされるたびに計算され得るランダムなキャッシュエントリのTTLを使用し得る。キャッシュエントリのTTLをランダム化する他の変型例が可能であり、考慮される。
いくつかの実施形態によれば、管理者または他のユーザーは、最大生存時間パラメータおよび最小生存時間パラメータを設定することにより、キャッシュディレクトリエントリの許容期限の範囲を決定してもよい。例えば、図6Aに示すとおり、43200秒の最小生存時間パラメータが指定され得る。129600秒という最大生存時間パラメータの設定例も図6Aも示されている。最小生存時間パラメータ設定は、キャッシュをリフレッシュするための負荷とディレクトリエントリの陳腐化とをトレードオフする目的で管理者によって決定され得る。キャッシュエントリは、最大生存時間パラメータおよび最小生存時間パラメータによって決定される範囲内で期限満了日または生存時間設定が割り当てられ得る。生存時間設定は、キャッシュディレクトリエントリの作成時に設定されてもよい。他の実施形態によれば、管理者または他のユーザーが、生存時間パラメータおよび生存時間分散パラメータを設定することによってキャッシュディレクトリエントリの許容期限の範囲を決定してもよい。生存時間分散パラメータは、キャッシュされたディレクトリが生存時間パラメータから変動し得る最大量を決定し得る。例えば、生存時間分散パラメータは、パーセンテージ(例えば0%と100%との間のパーセンテージ)で表され得る。図6Bに示すとおり、TTLパラメータは86400秒に設定され、TTL分散パラメータは50%に設定される。生存時間分散パラメータは、小数に変換され、1から減算され、その後TTLによって乗算されて最小TTLを決定し得る。次に生存時間分散パラメータは、小数に変換され、1に加算され、その後TTLによって乗算されて最大TTLを決定し得る。他の方法およびパラメータは、個々のキャッシュエントリのTTL設定を分散させる生存時間設定の範囲を特定または決定する目的で使用され得る。いくつかの実施形態によれば、TTL範囲、TTL、またはTTL分散は、1つまたはそれ以上の要因に基づいて増減し得る。例えば、TTLおよび/またはTTLの範囲は、キャッシュサイズ、ディレクトリサーバーの負荷または他の要因に基づいて増減し得る。1つまたはそれ以上の実施形態によれば、TTL範囲は、ディレクトリデータソースに基づいて異なり得る。例えば、キャッシュの一部分が第1のディレクトリデータソースと関連付けられており、第2のキャッシュの一部分が第2のディレクトリデータソースと関連付けられている場合、異なる部分には異なるTTL範囲が割り当てられ得る。
図7A、図7B、および図7Cを参照すると、本開示の一実施形態にかかるディレクトリデータサービスのキャッシュパラメータを設定するためのインターフェースが示されている。
いくつかの実施形態によれば、キャッシュエントリの期限が切れたかどうかは、キャッシュエントリの作成時刻からの経過時間を計算し、その経過時間をエントリの生存時間(TTL)と比較することによって判断され得る。図7Aに示すとおり、例示的なキャッシュディレクトリエントリの作成タイムスタンプが、1267158467763のミリ秒(MS)であり得る。タイムスタンプは、キャッシュディレクトリエントリの作成時にシステム時刻を取得するために、オペレーティングシステムAPIを使用して作成され得る。キャッシュディレクトリエントリの作成時にランダムに割り当てられた可能性のあるTTL分布係数は、39であり得る。上述のとおり、キャッシュエントリのTTLを計算する目的で使用されるいくつかの異なるアルゴリズムが存在し得る。例えば、エントリの生存時間(entryTTL)は次式で計算され得る。
entryTTL=minTTL+((maxTTL−minTTL)×(ttlSpreadFactor/100.0));//秒
ttlSpreadFactorは、0と100(両端値を含む)間のランダム数(例えば39)であり得る。MinTTLはキャッシュエントリの最小生存時間を表し得る。そしてMaxTTLはエントリの最大生存時間を表し得る。したがって、MinTTLおよびMaxTTLは許容範囲を判断し得る。そしてttlSpreadfactorは、その範囲に沿ってキャッシュエントリを分散させる目的で使用されるランダム数であり得る。
図7Bで指定された例示的なTTL範囲と図7Aで指定された例示的なTTL分布係数とを使用して、キャッシュエントリの生存時間(TTL)が次式で計算され得る。
ENTRY TTL=43200+((129600−43200))×(39/100)=76896秒
図7Aで指定された例示的なTTL範囲と図7Cで指定された例示的なTTL分布係数とを使用して、キャッシュエントリの生存時間(TTL)が次式で計算され得る。
ENTRY TTL=86400+((259200−86400))×(39/100)=153792秒
正規化されたTTL分布係数を割り当てることにより、MinTTLおよび/またはMaxTTLが改変されたときにエントリのTTL値が自然に増減し得る。
経過時間は、1つまたはそれ以上のアルゴリズムによって計算され得る。例えば、経過時間は次式で計算され得る。
elapsed=(currentTime−creationTime)×1000;//秒
経過時間およびキャッシュエントリの生存時間が決定されたら、期限の判断は次式によって行われ得る。
isExpired=(elapsed>entryTTL)
例示的実施形態によれば、ディレクトリデータサービス(DDS)統合は、DDSビジネスロジック層を使用して実施され得る。DDSビジネスロジック層は、以下の部分で構成され得る。
DDS APIロック層:この層は、DDSクライアントリクエストの処理中にシステムがシャットダウン、再起動、あるいは他の形で停止することのないようにし得る。この層は、サーバーの再初期化をクライアントリクエストの処理と同期させることもある。この層は、ロック機能を伴うDDS APIを実装し、1つまたはそれ以上のリクエストをDDS API層に移譲し得る。
ビジネスコンポーネント層:この層は、ディレクトリ機能およびサーバーの再初期化を実施し得る。この層は、データアクセス、キャッシュ、および構成層を使用して、クライアントリクエストに対応する。この層は、構成層を使用してサーバーの再初期化を実行する。この層は、キャッシュおよびデータアクセス層にサーバーの再初期化を通知する。
キャッシュ層:この層は、メモリにおけるディレクトリモデルオブジェクトのキャッシュ保存を担い得る。ディレクトリモデルオブジェクトは、ユーザー、グループ、および/または配布リストなどのディレクトリエントリを表し得る。モデルオブジェクトは、ルックアップ電子メールアドレスおよびユニーク識別子(UID)など、1つまたはそれ以上の電子メールアドレスによってインデックス化され得る。認証機能の場合、ユーザーオブジェクトは、ユーザー名およびUIDによってインデックス化され得る。存在しないディレクトリオブジェクトへの参照は、ネガティブキャッシュに記憶され得る。モデルオブジェクト内に格納されているUIDは、メモリ消費を減らすためにプールされ得る。
構成層:この層は、ディスクから構成ファイル(例えば、ddsConfig.xml、userprefs.xmlおよびbmiconfig.xml)を解析し得る。これらのファイルは、構成オブジェクトに変換され、メモリに記憶され得る。DDSconfigオブジェクトは、データソース情報を格納しており、主にデータアクセス層によって使用され得る。このオブジェクトは、データソースマッピングに対するキャッシュ設定およびキャッシュプロファイルも格納しており、これらはキャッシュおよびビジネスコンポーネント層によって使用され得る。UserPreferencesおよびPolicyConfigオブジェクトは、アドレス解決リクエストを処理する際に使用され得る。
DDS APIロック層は、クライアントリクエストの処理をサーバーの再初期化と同期させ得る。ただし、エンジンからDDSに渡されたプロファイルIDの有効性を確保するために、コントロールセンターが、エンジンの再初期化をDDSの再初期化と同期させてもよい。
ビジネス層クラス
DDS APIロック層
ConcurrentDDS:このクラスは、DirectoryDataServiceインターフェースを実装し、サーバーの再初期化をクライアントリクエストの処理と同期させるための読み出し/書き込みロックを使用し得る。書き込みロックが取得されない限り、読み出しロックは複数のクライアントリクエストによって同時に保持され得る。書き込みロックは排他的であってもよく、サーバーが起動したときに取得されてもよい。リーダーがアクティブであり、ライターがロックに入った場合には、そのライターが書き込みロックを取得し、解放するまで、以降のリーダーに読み出しロックが付与されることはない。このクラスの単一インスタンスは、Springフレームワークによってインスタンス生成され得る。インスタンスは、DirectoryDataServiceインターフェースを実装するオブジェクトによって初期化される必要があり得る。
ビジネスコンポーネント層
AuthenticationManager:このシングルトンは、認証機能タイプ関連のディレクトリ機能を実装し得る。そして、隔離エンドユーザーのログインを実行する。テストメソッドが利用可能であり得る。
QuarantineResolutionManager:このシングルトンは、隔離アドレス解決機能タイプ関連のディレクトリ機能を実装し得る。そして、隔離アドレス解決を実行する。テストメソッドが利用可能であり得る。
RecipientValidationManager:このシングルトンは、受信者の妥当性検証機能タイプ関連のディレクトリ機能を実装し得る。このシングルトンは、MTAによる受信者の妥当性検証を実行する。テストメソッドが利用可能であり得る。
RoutingManager:このシングルトンは、ルーティング機能タイプ関連のディレクトリ機能を実装し得る。そして、代替メールホストおよび代替アドレス情報を回送するMTAを取得する。テストメソッドが利用可能であり得る。
AddressResolutionManager:このシングルトンは、アドレス解決機能タイプ関連のディレクトリ機能を実装し得る。そして、エンジンアドレス解決と、「全グループ」機能を実行する。テストメソッドが利用可能であり得る。
ResolvedAddress:この転送オブジェクトは、エンジンアドレス解決を受けて返され得る。そして、RecipientモデルオブジェクトおよびResolvedRecipientオブジェクトのリストへのアクセスを提供する。
ResolvedRecipient:この転送オブジェクトは、Recipientモデルオブジェクト、受信者がメンバーとして属するGroupモデルオブジェクトおよびDistributionListモデルオブジェクト、ならびに受信者と関連付けられたユーザー設定xmlへのアクセスを提供し得る。
DirectoryDataServer:このシングルトンは、サーバーの初期化を実行し得る。このシングルトンは、新たに読み込む構成ファイルが存在することを構成層に通知する。このシングルトンは、キャッシュ層、ビジネス層、およびデータアクセス層に新しいDDSConfigオブジェクトを渡す。これらの層は、古いDDSConfigオブジェクトを新しいものと比較することによって構成上の変更を検出し得る。
EntryStore:このクラスは、EntryCacheおよびEntryDAOのインスタンスをラップし得る。このクラスは、TTLロジックの実施中に、キャッシュされたオブジェクトへのアクセスを提供する。このクラスの1つのインスタンスは、データソース機能ごとに作成され得る。
EntryStoreFactory:このシングルトンは、DDSConfigにおけるデータソース機能ごとにEntryStoreオブジェクトを作成し得る。EntryStoreは、データソースIDと機能タイプとによって検索され得る。このシングルトンは、サーバーが再初期化されると、新しいDDSConfigオブジェクトによって通知され得る。
EntryMart:このクラスは、プロファイルにマッピングされ、EntryStoreオブジェクトの配列を格納し得る。このクラスは、自身の主な機能として、EntryStoreオブジェクトに対するキャッシュ優先検索を実行する。
EntryMartFactory:このシングルトンは、DDSConfigにおけるプロファイルごとにEntryMartオブジェクトを作成し得る。EntryMartは、プロファイルIDによって検索され得る。このシングルトンは、サーバーが再初期化されると、新しいDDSConfigオブジェクトによって通知され得る。
構成層
DDSConfigFactory:このシングルトンは、サーバーの起動および再初期化時に、ddsConfig.xmlファイルを解析してDDSConfigオブジェクトにし得る。ファイルの最終変更日が不変であれば、そのファイルが改めて読み込まれることはない。
DDSConfig:ddsConfig.xmlファイルの内容を表し得る構成オブジェクト。
PolicyConfigFactory:このシングルトンは、サーバーの起動および再初期化時に、bmiconfig.xmlファイルを解析してPolicyConfigオブジェクトにし得る。ファイルの最終変更日が不変であれば、そのファイルが改めて読み込まれることはない。
PolicyConfig:bmiconfig.xmlファイル内の任意のグループポリシーにマッピングされ得るディレクトリグループUIDを格納している構成オブジェクト。
UserPreferencesFactory:このシングルトンは、サーバーの起動および再初期化時に、userprefs.xmlファイルを解析してUserPreferencesオブジェクトにし得る。ファイルの最終変更日が不変であれば、そのファイルが改めて読み込まれることはない。
UserPreferences:userprefs.xmlファイルの内容を表す構成オブジェクト。各ユーザーのユーザー設定xmlストリングは、base64で符号化され得る。
キャッシュ層
Entry:このインターフェースは、1つまたはそれ以上のディレクトリオブジェクトをモデル化し得る。このインターフェースは、UID(すなわちDN)およびmemberOf属性へのアクセスを提供し得る。
Recipient:このインターフェースは、プライマリ配送可能アドレスを有するディレクトリオブジェクトをモデル化し得る。このインターフェースは、Entryインターフェースを拡張し得ることに加え、プライマリ配送可能アドレス、エイリアスアドレス、および他のカスタム属性へのアクセスを提供する。
RecipientRef:このクラスは、電子メールアドレスによってRecipientオブジェクトを参照する方法を提供し得る。参照は、UIDによってRecipientオブジェクトを参照する。
InvalidRecipient:このクラスは、存在しないディレクトリオブジェクトに対する参照(電子メールアドレス)を保持し得る。この参照はネガティブキャッシュエントリであり、ネガティブキャッシング目的で使用され得る。
MemberList:このインターフェースは、メンバーのリストを含むディレクトリオブジェクトをモデル化し得る。このインターフェースは、Entryインターフェースを拡張し、メンバーリストへのアクセスを提供する。
User:このクラスは、ディレクトリユーザーオブジェクトをモデル化し得る。このクラスは、そして、Recipientインターフェースを実装する。
UserRef:このクラスは、ユーザー名によってユーザーオブジェクトを参照する方法を提供し得る。UIDによってUserオブジェクトを参照する。
Group:このクラスは、ディレクトリグループオブジェクトをモデル化し得る。このクラスは、MemberListインターフェースを実装する。このクラスは、グループ名(例えばcn)へのアクセスを提供する。
DistributionList:このクラスは、プライマリ配送可能アドレスを有するディレクトリグループオブジェクトをモデル化し得る。このクラスは、RecipientおよびMemberListインターフェースを実装する。
Attribute:このクラスは、ルーティングディレクトリ機能によって使用されるオブジェクトなど、ユーザーおよびグループディレクトリオブジェクトに関するカスタム属性へのアクセスを提供し得る。
EntryCache:このインターフェースは、キャッシュからEntry、RecipientRef、UserRefおよびInvalidRecipientオブジェクトを取得、追加、および削除するのに必要な動作を定め得る。このインターフェースは、キャッシュサイズの設定やキャッシュエントリのパージなどの実行時キャッシュ管理動作のセットも定め得る。
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();
}
LRUEntryCache:このクラスは、EntryCacheインターフェースを実装し得る。このクラスは、Entry、RecipientRef、UserRef、およびInvalidRecipientオブジェクトをメモリにキャッシュする。このクラスの1つのインスタンスは、データソース機能ごとに作成され得る。そして、アクセス順を保持するLinkedHashMapを使用して、EntryオブジェクトをUIDによってインデックス化する。RecipientRefオブジェクトは、アクセス順を保持する別々のLinkedHashMapにおいて、ルックアップアドレスによってインデックス化され得る。UserRefオブジェクトは、アクセス順を保持する別々のLinkedHashMapにおいて、ユーザー名によってインデックス化され得る。InvalidRecipientオブジェクトも、別々のアクセス順を保持する別々のマップにおいて、ルックアップアドレスによってインデックス化され得る。マップ上での最大サイズを超えた場合には、使用時期が最も古いエントリがマップから削除され得る。キャッシュされたモデルオブジェクトは、UID(すなわちDN)によって他のディレクトリオブジェクトを参照し、メモリ使用を減らすために、これらのUIDはInternPoolを使用してプールされ得る。キャッシュごとに1つのInternPoolインスタンスが存在し得る。
InternPool:このクラスは、文字列プールであり得る。このクラスは、WeakHashMapを使用してStringオブジェクトをインデックス化する。参照されなくなると、自身のエントリは自動的にガベージコレクションされる。
EntryCacheFactory:このシングルトンは、DDSConfigにおけるデータソース機能ごとにLRUEntryCacheオブジェクトを作成し得る。EntryCacheは、データソースIDと機能タイプとによって検索され得る。このクラスは、現在のDDSConfigオブジェクトの参照を常に維持し得る。このシングルトンは、サーバーが再初期化されると、新しいDDSConfigオブジェクトによって通知され得る。キャッシュインスタンスは、現在の構成を新しい構成と比較するによって無効化され得る。
キャッシュデザイン
キャッシュデザインは、1つまたはそれ以上の要因の影響を受ける。まず、TTL(生存時間)を超えているキャッシュエントリと関連付けられたデータソース接続が停止している場合には、それらのキャッシュエントリが使用されるはずである。したがって、期限の切れたキャッシュデータが事前に削除されることはない。エントリが新しいバージョンと交換されるか、キャッシュサイズの超過を理由にエントリが追い出されるか、どちらかが起こるまでキャッシュエントリはキャッシュで留まり得る。2番目に、単一コピーのディレクトリオブジェクトだけがキャッシュされる必要がある。これは、キャッシュを同一ディレクトリオブジェクトの異なるバージョンで満たすのを防ぐためである。また、これにより、ディレクトリオブジェクトの取得方法(ユニークID、プライマリ配送可能アドレス、エイリアスアドレス、ルックアップアドレス、またはユーザー名)に関係なく、確実に同一バージョンが返され得る。
デフォルトでは、EntryCacheFactoryシングルトンインスタンスは、サーバーシャットダウン時にデフォルトのjavaシリアル化を用いてディスクにシリアル化され得る。シリアル化されたインスタンスは、サーバー起動時にメモリに読み込まれ得る。これにより、メモリキャッシュ内のすべてが、サーバーを再起動しても保たれ得る。ObjectOutputStreamを使用して、単一のオブジェクトに対する複数の参照が参照共有メカニズムを用いて符号化されてもよく、それにより、オブジェクトのグラフを、オリジナルが記述されたときと同じ形状に復元することができる。換言すれば、プールされた文字列が、逆シリアル化後も引き続きプールされ得る。メモリのフットプリントは、逆シリアル化後も増えない。シリアル化されたjavaオブジェクトはクラスバージョンの変更に敏感なので、ソフトウェアの更新後は、シリアル化されたキャッシュデータが無視され得る。
下記の表1は、例示的なLRUEntryCacheの例示的な内容を示す。
文字列プール
キャッシュ内のUIDは、メモリ消費を減らすためにInternPoolを使用してプールされ得る。以下の実施例が示すとおり、大きく節約できる可能性がある。
想定事例:
10万ユーザー
5万dlist
各dlistに200ユーザー
各DN文字列は50バイト
文字列プールを使用しなければ、すべてのDN文字列の合計サイズは以下のようになり得る。
10万×50+5万×50+5万*200×50=500万+250万+5億=5億750万
文字列プールを使用すれば、すべてのDN文字列の合計サイズは以下のようになり得る。
10万×50+5万×50=500万+250万=750万
ディレクトリオブジェクトおよびTTL
ビジネスコンポーネント層は、キャッシュされたディレクトリオブジェクトにTTLを適用し得る。作成時刻(ミリ秒)は、各モデルオブジェクト(User、DistributionList、Group、RecipientRef、UserRef、およびInvalidRecipient)で設定された後に、キャッシュに追加され得る。作成時刻は、取得されると、オブジェクトの期限が切れたかどうかを判断するために、現在の時刻と比較され得る。オブジェクトの期限が切れた場合には、データソースからオブジェクトのリフレッシュが試行され得る。データソース接続の失敗が発生した場合には、期限の切れたオブジェクトが代わりに使用され得る。
多数のキャッシュオブジェクトが同時に期限切れになるのを防ぐために、各オブジェクトでTTL分布係数が設定された後にキャッシュに追加され得る。TTL分布係数は、最小TTLと最大TTLとの間の101個の別個の値の範囲内でTTLをランダム化する目的で使用され得る。オブジェクトの期限は、次式で計算され得る。
expirationTime=creationTime+minTTL+((maxTTL−minTTL)×(TTLSpreadFactor/100.00))
式中、creationTimeは秒、minTTLは最小生存時間(秒)、maxTTLは最大生存時間(秒)、TTLSpreadFactorは0と100との間(両端値を含む)のランダムに選ばれた数であり得る。例えば、最小TTLが43200秒(12時間)、最大TTLが129600秒(36時間)である場合、キャッシュオブジェクトは、それらのttlSpreadFactor値によって決定されるとおり、12時間と36時間との間で期限が切れ得る。TTLSpreadFactorは、無効な受信者に適用されることはない。
システムクロックが変更されると、すでにキャッシュにあるオブジェクトの期限が変更に応じて増減し得る。
実施例1:以下の実施例は、EntryオブジェクトのTTL確認を示す。
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;
}
実施例2:以下の実施例は、RecipientRefオブジェクトのTTL確認を示す。
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;
}
ディレクトリ機能
すべてのディレクトリ機能に共通するタスクは、プロファイルと関連付けられたキャッシュおよびデータソースの中から受信者を見つけることであり得る。キャッシュ優先検索アルゴリズム、およびアルゴリズムと各ディレクトリ機能との関係について以下説明する。
キャッシュ優先検索
キャッシュ優先検索アルゴリズムはまず、キャッシュインスタンスから受信者を検索し、受信者が見つかるか、検索するキャッシュがなくなるまで続けられる。受信者がキャッシュに見つからない場合には、次に、ネガティブキャッシュエントリを持たないデータソースから受信者を検索する。受信者が1つのデータソースに見つかった場合には、関連付けられたキャッシュにその受信者を追加する。受信者が一意でない場合には、エラーを返す。受信者がどのデータソースにも見つからない場合には、各キャッシュにネガティブキャッシュエントリを追加する。このロジックにより、ルックアップアドレスがすべてのデータソースで確実に一意となり得る。
受信者の妥当性検証
この受信者検索は、「キャッシュ優先」検索であり得る。ただし、ルックアップアドレスが一意でない場合に、エラーではなく真が返され得る。
アドレス解決
アドレス解決は、受信者の「キャッシュ優先」検索から始まり得る。その後、受信者を格納しているデータソースを使用して、その受信者の下位受信者を再帰的に取り出す。受信者本人または下位受信者のいずれかがユーザーまたは空の配布リストである場合には、そのリストをユーザー目標のリストに追加する。次に、ユーザー目標ごとに、グループメンバーシップを入力する。グループメンバーシップは、バックグラウンドスレッドでビルドされ得る。
メッセージルーティング
この受信者検索は、「キャッシュ優先」検索であり得る。
隔離認証
隔離認証は、ユーザーの「キャッシュ優先」検索から始まる。ユーザーが見つかると、関連付けられたデータソースと照合してユーザーを認証する。
隔離アドレス解決
この受信者検索は、「キャッシュ優先」検索であり得る。
ルックアップアドレスおよびユーザー名の一意性
ルックアップアドレスおよびユーザー名の一意性は、データアクセス層およびビジネス層で実施され得る。以下の概説が該当し得る。
「キャッシュ優先」検索アルゴリズムにより、プロファイル内のすべてのデータソースでのルックアップアドレスおよびユーザー名の一意性が確保される。
キャッシュオブジェクトが、ルックアップアドレスまたはユーザー名によってインデックス化され得るが、プロファイル内のデータソース全体での一意性がテストされていない属性値によってインデックス化されることはない。
キャッシュオブジェクトは、キャッシュに存在する限り、一意性が再テストされることはない。これは、キャッシュオブジェクトが自身のTTLを超えた場合でも当てはまり得る。
新しいデータソースが既存のプロファイルに追加されると、新しいデータソースの前に作成されたキャッシュエントリが、新たに追加されたデータソースと照合して一意性をテストされることはない。
キャッシュの無効化
以下が変わると、キャッシュが無効化され得る。
/ddsConfig/dataSources/dataSourceLDAP/directoryType
/ddsConfig/dataSources/dataSourceLDAP/servers/server/hosts//*
/ddsConfig/dataSources/dataSourceLDAP/servers/server/port
/ddsConfig/dataSources/dataSourceLDAP/functions//*
LDAP接続の失敗が発生した場合には、自身のTTLを超えているキャッシュされたディレクトリオブジェクトが維持され得る。
循環グループおよび配布リストのメンバーシップ参照によって循環処理が生じることはない。これは、アドレス解決だけに該当し得る。無限再帰を防ぐために、アクセスされたノードのリストが使用され得る。トラバースされるネスト構造のグループの数に制限が存在することはない。
キャッシュエントリの設定可能生存時間(TTL)機能
キャッシュされたディレクトリオブジェクトの最小および最大TTLは、ディレクトリデータソースごとに設定可能であり得る。
設定可能なキャッシュサイズ(エントリの数)
キャッシュサイズは、関連付けられたキャッシュインデックスサイズとして、ディレクトリデータソースごとに設定可能であり得る。
オンディマンドによるキャッシュパージ
各ディレクトリデータソースのキャッシュは、コントロールセンターの管理者によって個々にクリアすることができる。
図8は、本開示の一実施形態にかかる、クエリフィルタトークンを使用してディレクトリエントリを一致させる方法を示す。いくつかの実施形態によれば、ディレクトリサーバーへの問い合わせ時に、クエリフィルタトークンが使用され得る。クエリフィルタトークンにより、トークンが、対応するパラメータトークンの実行時に代用されるクエリにおいて、パラメータのプレースホルダとして動作できる可能性がある。例えば、クエリフィルタトークンは以下を含み得る。
%sトークンは、完全電子メールアドレスを問い合わせるクエリにおけるプレースホルダであり得る。%uトークンは、電子メールアドレスのローカル部分を問い合わせるクエリにおけるプレースホルダであり得る。%dトークンは、電子メールアドレスのドメイン部分を問い合わせるクエリにおけるプレースホルダであり得る。%nトークンは、完全名を問い合わせるクエリにおけるプレースホルダであり得る。完全名は、電子メールアドレスのローカル部を取り出し、ピリオドおよびアンダースコアをスペースに置き換えることによって導出され得る。
1つまたはそれ以上のタイプのメールサーバーの管理者は、「メール」属性値に加え、自身の名前および/または名字、あるいはそれらのいくつかの組み合わせに基づいて、自身のサーバーを、ユーザーの電子メールも受け入れるように構成し得る。
想定するエントリ例:
dn: CN=John Bigboote, O=sfdom1
givenname: John
objectclass: dominoPerson
uid: JBigboote_uid
uid: JBigboote_uid2@eng.symantec.com
mail: john.bigboote.mail@eng.symantec.com
cn: John Bigboote
sn: Bigboote
eng.symantec.comおよびaliasdomain.comのメールを受信するように構成されたメールサーバーは、以下のうちの1つまたはそれ以上を無効な受信者と認識するように構成され得る。
john@aliasdomain.com
john@eng.symantec.com
bigboote@aliasdomain.com
bigboote@eng.symantec.com
jbigboote_uid@aliasdomain.com
jbigboote_uid@eng.symantec.com
jbigboote_uid2@eng.symantec.com
john.bigboote.mail@eng.symantec.com
john.bigboote.mail@aliasdomain.com
john.bigboote@aliasdomain.com
john.bigboote@eng.symantec.com
john_bigboote@aliasdomain.com
john_bigboote@eng.symantec.com
メールサーバー管理者は、これらのエイリアス(例えば、「メール」属性値をユーザーの唯一の配送可能なアドレスとみなすなど)をサポートしないように自身のサーバーを構成し得るので、自身のディレクトリサーバークエリを、これらの各種アドレス形態を包含あるいは除外するように構成することも可能であり得る。大規模なメールサーバー展開では、「uid」および「メール」属性値だけを配送可能なアドレスとして使用し得る。かかる構成は、上記実施例に続いて、以下のアドレスをサポートする。
jbigboote_uid@aliasdomain.com
jbigboote_uid@eng.symantec.com
jbigboote_uid2@eng.symantec.com
john.bigboote.mail@eng.symantec.com
john.bigboote.mail@aliasdomain.com
いくつかの実施形態によれば、これらのうちの1つまたはそれ以上を捕捉する目的でクエリフィルタが使用され得る。
(|(mail=%s)(uid=%s)(uid=%u))
管理者がユーザーの完全名へのエイリアス化を許容するようにしている場合には、クエリを以下のように変更することができる。
(|(mail=%s)(uid=%s)(uid=%u)(cn=%n))
なお、ここでは、電子メールアドレスのローカル部におけるピリオドまたはアンダーラインを表すホワイトスペースの代用となり得る%nトークンが使用され、その結果、john.bigboote@eng.symantec.comまたはjohn_bigboote@eng.symantec.comは(cn=john bigboote)となる。
管理者が、ユーザーの名前および名字へのエイリアス化も許容している場合には、クエリが以下のように変更され得る。
(|(mail=%s)(uid=%s)(uid=%u)(cn=%n)(givenName=%u)(sn=%u))
名前および名字のエイリアス化が許容されていると、同じ名前および/または名字を有する2つ以上のユーザーエントリ間で名前空間の「衝突」が発生する可能性がはるかに高まり得る。たとえば、仮想的なディレクトリサーバーが次のようなエントリも格納している場合、
dn: CN=John Whorfin, O=sfdom1
givenname: John

cn: John Whorfin
sn: Whorfin
受信者を一意に特定できないというテキストメッセージを伴う5xxエラーをSMTPクライアントに返すことにより、SMTPサーバー自体がjohn@aliasdomain.comへの配送試行を扱い得る。ディレクトリデータサービスLDAPクエリが2つのエントリ(givenName=john)を返し得るので、この状況は、上記のデータ整合エラーとして扱われ得る。
図8に示すとおり、例示的な完全なアドレス、電子メールアドレスのローカル部分、対応する完全名、および例示的なクエリが、要素802に表されている。例示的なディレクトリエントリが、要素806に表されている。ディレクトリサーバーによっては(例えばIBM Lotus Domino)、ディレクトリエントリの複数の電子メールエイリアスをサポートするものもある。要素804に示すとおり、要素806に列記されているディレクトリエントリに対して、複数の電子メールエイリアスがサポートされ得る。要素808および810に示すとおり、「john_smith@domain.com」の電子メールアドレスの妥当性を検証するためにクエリが受信された場合には、トークン%sおよび%uを使用したディレクトリサーバークエリがディレクトリエントリを見つけることはない。ただし、要素812および814に表すとおり、完全名で問い合わせるために%nトークンが使用された場合には、一致が見つかり得る。%nトークンは、電子メールアドレスのローカル部におけるピリオドまたはアンダースコアをスペースで置き換えて、問い合わせ用の完全名を導出する。
この時点で、上記の本開示にかかるディレクトリサーバーを統合が、ある程度までの入力データの処理と出力データの生成とを概して含むということに注意すべきである。この入力データ処理および出力データ生成は、ハードウェアまたはソフトウェアで実施され得る。例えば、上記の本開示にかかるディレクトリサーバー統合と関連付けられた機能を実行するために、ディレクトリデータサービス、または同様の回路あるいは関連する回路で、特定の電子構成要素が用いられ得る。あるいは、命令に従って動作する1つまたはそれ以上のプロセッサが、上記の本開示にかかるディレクトリサーバーを統合と関連付けられた機能を実行し得る。このような場合、かかる命令が1つまたはそれ以上のプロセッサ読み取り可能な記憶媒体(例えば、磁気ディスクまたは他の記憶媒体)に記憶され得るか、あるいは1つまたはそれ以上の搬送波に組み入れられた1つまたはそれ以上の信号を介して1つまたはそれ以上のプロセッサに送信され得ることは、本開示の範囲内である。
本開示は、本明細書に記載されている具体的な実施形態によって範囲が制限されるものではない。実際、上記の記載内容および添付の図面から、本明細書に記載されている実施形態に加え、本開示の他の各種実施形態および変型例が当業者にとって明らかであろう。そのため、かかる他の実施形態および変型例は、本開示の範囲内に収まるものと意図される。さらに、本開示について、特定の目的のための特定の環境における特定の実施態様という文脈で本明細書に記載してきたが、当業者であれば、その有用性がそれに制限されず、本開示が任意の数の目的のために任意の数の環境で有益に実施され得ることを認識するであろう。したがって、以下に述べる請求項は、本明細書に記載されている本開示の全幅および精神を鑑みて解釈されるべきである。

Claims (15)

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