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