"ディレクトリサーバーを統合するための方法であって、複数のキャッシュディレクトリエントリの許容期限の範囲を決定する1つまたはそれ以上のパラメータを設定することと、電子記憶装置において、ディレクトリサーバーからキャッシュディレクトリエントリを作成することと、前記キャッシュディレクトリエントリに作成時刻を割り当てることと、前記許容期限の範囲内で前記キャッシュディレクトリエントリの期限を決定する少なくとも1つのランダム値を前記キャッシュディレクトリエントリに割り当てることであって、複数のキャッシュディレクトリエントリの前記許容期限の範囲内で前記キャッシュディレクトリエントリの前記期限をランダム化することにより、ある時点においてキャッシュメモリと前記ディレクトリサーバーとの間で必要とされる同期の量が減少することと、を含む、方法。キャッシュディレクトリエントリの許容期限の範囲を決定する前記1つまたはそれ以上のパラメータが、最大生存時間パラメータと最小生存時間パラメータとを備える、請求項1に記載の方法。キャッシュディレクトリエントリの許容期限の範囲を決定する前記1つまたはそれ以上のパラメータが、生存時間パラメータと生存時間分散パラメータとを備える、請求項1に記載の方法。ディレクトリエントリを求めるリクエストを受信することと、前記作成時刻と前記少なくとも1つのランダム値とに少なくとも部分的に基づいて、対応するディレクトリエントリの期限が切れたかどうかを判断することと、前記ディレクトリエントリの期限が切れている場合に、前記ディレクトリサーバーから前記ディレクトリエントリをリクエストすることと、をさらに含む、請求項1に記載の方法。前記ディレクトリサーバーにアクセスできないと判断することと、前記リクエストを受けて、前記対応する期限切れのキャッシュディレクトリエントリを提供することと、をさらに含む、請求項4に記載の方法。前記ディレクトリエントリがキャッシュされているかどうかを判断することと、前記ディレクトリエントリがキャッシュされていない場合に、前記ディレクトリサーバーから前記ディレクトリエントリをリクエストすることと、をさらに含む、請求項4に記載の方法。前記ディレクトリサーバーからのレスポンスを受信することと、前記ディレクトリサーバーからの前記レスポンスに少なくとも部分的に基づいてデータ整合エラーを検出することと、データ整合エラー情報を格納したアラートを管理者に提供することと、をさらに含む、請求項4に記載の方法。前記ディレクトリサーバーがLDAP対応ディレクトリサーバーを備える、請求項1に記載の方法。前記リクエストが、前記ディレクトリサーバーのホストとは別のゲートウェイ機器を備える電子デバイスから受信される、請求項4に記載の方法。前記リクエストが、前記ディレクトリサーバーのホストとは別の複数のゲートウェイ機器の間にホスト共有キャッシュを備える電子デバイスから受信される、請求項4に記載の方法。前記リクエストが、1つまたはそれ以上のキャッシュディレクトリエントリを使用して、ユーザー認証、受信者の妥当性検証、アドレス解決、およびメッセージルーティングのうちの少なくとも1つを提供する電子デバイスを備える電子デバイスから受信される、請求項4に記載の方法。請求項1に記載の方法を実行するためのコンピュータ処理を実行するように少なくとも1つのプロセッサに命令するための前記少なくとも1つのプロセッサによって読み取り可能であるように構成されたコンピュータプログラム命令を記憶するための少なくとも1つのプロセッサ読み取り可能な記憶媒体。ディレクトリサーバーを統合するための製品であって、少なくとも1つのプロセッサ読み取り可能な媒体と、前記少なくとも1つの媒体に記憶された命令と、を備え、前記命令が、少なくとも1つのプロセッサによって前記少なくとも1つの媒体から読み取り可能であるように構成されており、それにより、前記少なくとも1つのプロセッサに、複数のキャッシュディレクトリエントリの許容期限の範囲を決定する1つまたはそれ以上のパラメータを設定し、電子記憶装置において、ディレクトリサーバーからキャッシュディレクトリエントリを作成し、前記キャッシュディレクトリエントリに作成時刻を割り当て、前記許容期限の範囲内で前記キャッシュディレクトリエントリの期限を決定する少なくとも1つのランダム値を前記キャッシュディレクトリエントリに割り当て、複数のキャッシュディレクトリエントリの前記許容期限の範囲内で前記キャッシュディレクトリエントリの前記期限をランダム化することにより、ある時点においてキャッシュメモリと前記ディレクトリサーバーとの間で必要とされる同期の量が減少するように動作させる製品。ディレクトリサーバーを統合するためのシステムであって、ネットワークに通信可能に連結された1つまたはそれ以上のプロセッサであって、前記1つまたはそれ以上のプロセッサが、複数のキャッシュディレクトリエントリの許容期限の範囲を決定する1つまたはそれ以上のパラメータを設定し、ディレクトリサーバーからキャッシュディレクトリエントリを作成し、前記キャッシュディレクトリエントリに作成時刻を割り当て、前記許容期限の範囲内で前記キャッシュディレクトリエントリの期限を決定する少なくとも1つのランダム値を前記キャッシュディレクトリエントリに割り当て、複数のキャッシュディレクトリエントリの前記許容期限の範囲内で前記キャッシュディレクトリエントリの前記期限をランダム化することにより、ある時点においてキャッシュメモリと前記ディレクトリサーバーとの間で必要とされる同期の量が減少するように構成されている1つまたはそれ以上のプロセッサを備える、システム。前記1つまたはそれ以上のプロセッサが、ディレクトリエントリを求めるリクエストを受信し、前記作成時刻と前記少なくとも1つのランダム値とに少なくとも部分的に基づいて、対応するディレクトリエントリの期限が切れたかどうかを判断し、前記ディレクトリエントリの期限が切れている場合に、前記ディレクトリサーバーから前記ディレクトリエントリをリクエストするようにさらに構成されている、請求項14に記載のシステム。ディレクトリサーバーを統合するための技法が開示される。特定の一例示的実施形態において、技法は、複数のキャッシュディレクトリエントリの許容期限の範囲を決定する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に加え、ディレクトリサーバー1401-Nおよびネットワークデバイス1701-Nも含み得るそのうちの1つまたはそれ以上が、図2に示すコンピュータシステム200を使用して実装され得る。クライアントシステム110、120および130は、ネットワーク150に通信可能に連結され得る。ディレクトリサーバー1401-Nは、記憶デバイス1601-Nに通信可能に連結され得る。ネットワークデバイス1701-Nは、管理モジュール例えばディレクトリデータサービス154を格納し得る。図2のコンピュータシステム200を参照すると、クライアントシステム110、120および130のうちの1つまたはそれ以上からネットワーク150への接続を提供するために、モデム247、ネットワークインターフェース248、またはその他何らかの方法が使用され得る。クライアントシステム110、120および130は、例えば、ライトウェイトディレクトリアクセスプロトコルLDAPクライアントまたは他のクライアントソフトウェアを使用して、ディレクトリサーバー1401-Nにある情報にアクセス可能であり得る。かかるクライアントにより、クライアントシステム110、120および130が、ディレクトリサーバー1401-Nか、あるいは記憶デバイス1601-Nのうちの1つによってホストされるデータにアクセスでき得る。ネットワーク150および/または180は、ローカルエリアネットワークLAN、ワイドエリアネットワークWAN、インターネット、セルラー方式ネットワーク、衛星ネットワーク、または、クライアント110、120、130、ディレクトリサーバー1401-N、およびネットワーク150および/または180に通信可能に連結された他のデバイスとの間での通信を許可する別のネットワークであり得る。ネットワーク150および/または180は、スタンドアロンネットワークとして、あるいは互いに協同して動作する上記例示的なタイプのネットワークのうちの1つまたは任意の数をさらに含み得る。ネットワーク150および/または180は、通信可能に連結された1つまたはそれ以上のクライアントまたはサーバーのうちの1つまたはそれ以上のプロトコルを利用し得る。ネットワーク150および/または180は、ネットワークデバイスのうちの1つまたはそれ以上のプロトコルと他のプロトコルとの間での変換を行い得る。ネットワーク150および180は、単一のネットワークとして各々表されているが、1つまたはそれ以上の実施形態によれば、ネットワーク150および/または180が複数の相互接続されたネットワークを備え得ることが理解されるべきである。記憶デバイス1601-Nは、ネットワークアクセス可能記憶装置であってよく、ディレクトリサーバー1401-Nに対してローカル、リモート、またはそれらの組み合わせであってもよい。記憶デバイス1601-Nは、低価格ディスクの冗長配列RAID、磁気テープ、ディスク、記憶装置エリアネットワークSAN、インターネット小型コンピュータシステムインターフェースiSCSISAN、ファイバチャネルSAN、共通インターネットファイルシステムCIFS、ネットワーク接続型記憶装置NAS、ネットワークファイルシステムNFS、光学ベース記憶装置、または他のコンピュータアクセス可能記憶装置を利用してもよい。記憶デバイス1601-Nは、バックアップまたはアーカイブ目的で使用されてもよい。いくつかの実施形態によれば、クライアント110、120、および130は、スマートフォン、PDA、デスクトップコンピュータ、ラップトップコンピュータ、サーバー、他のコンピュータ、またはネットワーク150に無線または有線接続経由で連結された他のデバイスであり得る。クライアント110、120、および130は、ユーザー入力、データベース、ファイル、ウェブサービス、および/またはアプリケーションプログラミングインターフェースからデータを受信し得る。ディレクトリサーバー1401-Nは、例えば、Microsoft登録商標ActiveDirectory登録商標サーバー、IBM登録商標Lotus登録商標Domino登録商標サーバー、Sun登録商標ディレクトリサーバー、LDAP対応ディレクトリサーバー、データベースサーバー、1つまたはそれ以上のフラットファイルまたは他のデータ構造を格納するサーバー例えばXML、あるいはネットワーク150に通信可能に連結された他のデバイスなどのディレクトリサーバー実施態様の1つまたはそれ以上のホストであり得る。ディレクトリサーバー1401-Nは、アプリケーションデータ、バックアップデータ、または他のデータを記憶するための記憶デバイス1601-Nのうちの1つまたはそれ以上を利用し得る。ディレクトリサーバー1401-Nのうちの1つまたはそれ以上は、アプリケーションサーバーなど、クライアント110、120、および130に対するデータリクエストを処理し得るホストであり得る。いくつかの実施形態によれば、ネットワーク180は、インターネットを表し得る。そしてネットワークデバイス170は、企業WANまたはLANであり得るネットワーク150とネットワーク180との間の多量のデータトラフィックを扱うデバイスであり得る。例えば、ネットワークデバイス170のうちの1つまたはそれ以上は、メールゲートウェイ、ウェブゲートウェイ、あるいは、ユーザー認証および/または認可、識別情報管理、受信者の妥当性検証、アドレス解決、メッセージルーティング、アクセス制御、または他のアプリケーション挙動のためにディレクトリデータサービスを使用する別の機器またはアプリケーションであり得る。非制限的な例として、ネットワークデバイス170のうちの1つまたはそれ以上が、Symantec登録商標Brightmail登録商標Gateway、Symantec登録商標WebGateway、Symantec登録商標DataLossPreventionHost、Symantec登録商標EndpointProtectionApplication、またはBrightmail登録商標MessageFilterであり得る。ネットワークデバイス170のうちの1つまたはそれ以上は、ディレクトリデータサービス154を使用して、1つまたはそれ以上のディレクトリサーバーからのキャッシュデータを管理する。いくつかの実施形態によれば、各ネットワークデバイス170は、自身のデータをキャッシュし得る。1つまたはそれ以上の実施形態によれば、キャッシュデータは、ネットワークデバイス170のうちの2つまたはそれ以上の間で共有され得る。例えば、ネットワークデバイス1701は、複数のBrightmailGatewayスキャナのコントロールセンターホストであり得る。コントロールセンターホストは、BrightmailGatewayスキャナであり得る複数の他のネットワークデバイス170間で共有されるキャッシュディレクトリサービスデータを含み得る。キャッシュデータは、ネットワークデバイス170に記憶され得るか、あるいはネットワークデバイス170に通信可能に連結された電子記憶装置に記憶され得る。ディレクトリデータサービス154は、ネットワークデバイスの構成要素、モジュール、あるいは、ディレクトリデータキャッシュ動作を管理するために統合されたハードウェアおよびソフトウェアの別の組み合わせであり得る。いくつかの実施形態によれば、ディレクトリデータサービス154は、高スループット処理用のディレクトリデータサービスを使用して、ゲートウェイ機器あるいは別の装置またはアプリケーションとのディレクトリ統合を行うための統一サービス指向アーキテクチャを提供し得る。ディレクトリデータサービス154は、例えばディレクトリサーバー1401などのディレクトリサーバーからキャッシュデータを管理できるようにし得る。ディレクトリデータサービス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=minTTLmaxTTL-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データベース、および/またはフラットファイルを格納しているサーバーであり得るディレクトリサーバー1401...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が、データアクセス層から取り出された新規エントリ用のスペースを確保するために、期限が切れる前にキャッシュエントリを追い出すときにトリガーされ得る。管理者は、アラートおよびログステートメントを参照して適切な措置をとり得る。例示的なアラートは以下を含む。EntryCache修復方法:キャッシュサイズを増やす。RecipientRefCache電子メールアドレスに関するキャッシュインデックス修復方法:キャッシュインデックスサイズ乗数すなわち、キャッシュインデックスサイズ=N×キャッシュサイズと設定するパラメータNなど、キャッシュインデックスのサイズを決定するパラメータを増やす。UserRefCacheユーザー名に関するキャッシュインデックス修復方法:キャッシュインデックスサイズ乗数を増やす。アラートファイルが、ホスト、特定タイプのアラート条件、およびトリガー事象の時期を伝達し得る。アラートテキストは、管理者に、システムログファイルを参照して追加診断情報を確認するよう促し得る。これにより、開発への影響を抑えつつ、アラート機能の変更または拡張が可能となり得る。生成されたアラート電子メールは、以下の情報を含み得る。アラートイベントのタイムスタンプ、アラートイベントのホスト識別子、アラートイベント例えばディレクトリデータサービス154を生成した構成要素、および所定のディレクトリデータサービスステータスコードに対応するローカライズされたメッセージ。ステータスコードは大雑把である可能性があり、特定のコードに至る可能性のある多数の潜在的なエラー状況が存在し得る。アラートメカニズムは、特定ホスト上のDDSインスタンスが特定時期にリクエストを処理できなかったことを単に伝えるだけであり得る。そして根本原因についての詳細な情報はログを参照するように管理者に示し得る。DDSデータアクセスアラート、DDSデータ整合アラート、DDSキャッシュサイズアラート、ユーザー設定複製アラート、または他のタイプのアラートのうちの1つまたはそれ以上のサブタイプを使用可能または使用不可にするためのユーザーインターフェース要素例えばチェックボックスが存在してもよい。ディレクトリデータサービス154は、1つまたはそれ以上のデータ整合エラーまたは他のエラーを記録し得る。そしてアラートが別のメカニズムによって生成され得る。例えば、ディレクトリデータサービス154は、ディスク上、あるいは他の電子ストレージにアラートファイルを作成し得る。アラートファイルは、タイムスタンプと、アラート条件のタイプを表す識別子とを格納し得る。ネットワークデバイス170上で実行中のプロセスまたはエージェントが、周期的にアラートファイルをポーリングし、アラートメタデータを処理し、1人またはそれ以上のユーザー例えば、登録されたシステム管理者にアラート電子メールを送り得る。他の通信チャネルが、SMSテキストメッセージ、ボイスメール、および/またはウェブページ投稿などをユーザーに通知する目的で使用され得る。いくつかの実施形態によれば、ディレクトリデータサービス154は、追加プロセスまたはエージェントを使用せずに直接アラートを送り得る。1つまたはそれ以上の実施形態によれば、ディレクトリデータサービス154または別のプロセスが、インターフェースを使用して例えば、SNMP、WindowsSystemEvent、またはカスタム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登録商標、OSX登録商標、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データベース、および/またはフラットファイルを格納しているサーバーであり得るディレクトリサーバー1401...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、WindowsSystemEvent、またはカスタム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=minTTLmaxTTL-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で続行し得る。リクエストが別の属性例えば、電子メールアドレスjsmithdomain.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=minTTLmaxTTL-minTTL×ttlSpreadFactor/100.0;//秒ttlSpreadFactorは、0と100両端値を含む間のランダム数例えば39であり得る。MinTTLはキャッシュエントリの最小生存時間を表し得る。そしてMaxTTLはエントリの最大生存時間を表し得る。したがって、MinTTLおよびMaxTTLは許容範囲を判断し得る。そしてttlSpreadfactorは、その範囲に沿ってキャッシュエントリを分散させる目的で使用されるランダム数であり得る。図7Bで指定された例示的なTTL範囲と図7Aで指定された例示的なTTL分布係数とを使用して、キャッシュエントリの生存時間TTLが次式で計算され得る。ENTRYTTL=43200129600-43200×39/100=76896秒図7Aで指定された例示的なTTL範囲と図7Cで指定された例示的なTTL分布係数とを使用して、キャッシュエントリの生存時間TTLが次式で計算され得る。ENTRYTTL=86400259200-86400×39/100=153792秒正規化されたTTL分布係数を割り当てることにより、MinTTLおよび/またはMaxTTLが改変されたときにエントリのTTL値が自然に増減し得る。経過時間は、1つまたはそれ以上のアルゴリズムによって計算され得る。例えば、経過時間は次式で計算され得る。elapsed=currentTime-creationTime×1000;//秒経過時間およびキャッシュエントリの生存時間が決定されたら、期限の判断は次式によって行われ得る。isExpired=elapsed>entryTTL例示的実施形態によれば、ディレクトリデータサービスDDS統合は、DDSビジネスロジック層を使用して実施され得る。DDSビジネスロジック層は、以下の部分で構成され得る。DDSAPIロック層:この層は、DDSクライアントリクエストの処理中にシステムがシャットダウン、再起動、あるいは他の形で停止することのないようにし得る。この層は、サーバーの再初期化をクライアントリクエストの処理と同期させることもある。この層は、ロック機能を伴うDDSAPIを実装し、1つまたはそれ以上のリクエストをDDSAPI層に移譲し得る。ビジネスコンポーネント層:この層は、ディレクトリ機能およびサーバーの再初期化を実施し得る。この層は、データアクセス、キャッシュ、および構成層を使用して、クライアントリクエストに対応する。この層は、構成層を使用してサーバーの再初期化を実行する。この層は、キャッシュおよびデータアクセス層にサーバーの再初期化を通知する。キャッシュ層:この層は、メモリにおけるディレクトリモデルオブジェクトのキャッシュ保存を担い得る。ディレクトリモデルオブジェクトは、ユーザー、グループ、および/または配布リストなどのディレクトリエントリを表し得る。モデルオブジェクトは、ルックアップ電子メールアドレスおよびユニーク識別子UIDなど、1つまたはそれ以上の電子メールアドレスによってインデックス化され得る。認証機能の場合、ユーザーオブジェクトは、ユーザー名およびUIDによってインデックス化され得る。存在しないディレクトリオブジェクトへの参照は、ネガティブキャッシュに記憶され得る。モデルオブジェクト内に格納されているUIDは、メモリ消費を減らすためにプールされ得る。構成層:この層は、ディスクから構成ファイル例えば、ddsConfig.xml、userprefs.xmlおよびbmiconfig.xmlを解析し得る。これらのファイルは、構成オブジェクトに変換され、メモリに記憶され得る。DDSconfigオブジェクトは、データソース情報を格納しており、主にデータアクセス層によって使用され得る。このオブジェクトは、データソースマッピングに対するキャッシュ設定およびキャッシュプロファイルも格納しており、これらはキャッシュおよびビジネスコンポーネント層によって使用され得る。UserPreferencesおよびPolicyConfigオブジェクトは、アドレス解決リクエストを処理する際に使用され得る。DDSAPIロック層は、クライアントリクエストの処理をサーバーの再初期化と同期させ得る。ただし、エンジンからDDSに渡されたプロファイルIDの有効性を確保するために、コントロールセンターが、エンジンの再初期化をDDSの再初期化と同期させてもよい。ビジネス層クラスDDSAPIロック層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オブジェクトを取得、追加、および削除するのに必要な動作を定め得る。このインターフェースは、キャッシュサイズの設定やキャッシュエントリのパージなどの実行時キャッシュ管理動作のセットも定め得る。publicinterfaceEntryCachepublicEntrygetEntrypublicvoidaddEntrypublicEntryremoveEntrypublicvoidsetMaxEntriespublicRecipientRefgetRecipientRefpublicvoidaddRecipientRefpublicRecipientRefremoveRecipientRefpublicvoidsetMaxRecipientRefspublicUserRefgetUserRefpublicvoidaddUserRefpublicUserRefremoveUserRefpublicvoidsetMaxUserRefspublicInvalidRecipientgetInvalidRecipientpublicvoidaddInvalidRecipientpublicInvalidRecipientremoveInvalidRecipientpublicvoidsetMaxInvalidRecipientspublicvoidpurgeLRUEntryCache:このクラスは、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万×505万×505万200×50=500万250万5億=5億750万文字列プールを使用すれば、すべてのDN文字列の合計サイズは以下のようになり得る。10万×505万×50=500万250万=750万ディレクトリオブジェクトおよびTTLビジネスコンポーネント層は、キャッシュされたディレクトリオブジェクトにTTLを適用し得る。作成時刻ミリ秒は、各モデルオブジェクトUser、DistributionList、Group、RecipientRef、UserRef、およびInvalidRecipientで設定された後に、キャッシュに追加され得る。作成時刻は、取得されると、オブジェクトの期限が切れたかどうかを判断するために、現在の時刻と比較され得る。オブジェクトの期限が切れた場合には、データソースからオブジェクトのリフレッシュが試行され得る。データソース接続の失敗が発生した場合には、期限の切れたオブジェクトが代わりに使用され得る。多数のキャッシュオブジェクトが同時に期限切れになるのを防ぐために、各オブジェクトでTTL分布係数が設定された後にキャッシュに追加され得る。TTL分布係数は、最小TTLと最大TTLとの間の101個の別個の値の範囲内でTTLをランダム化する目的で使用され得る。オブジェクトの期限は、次式で計算され得る。expirationTime=creationTimeminTTLmaxTTL-minTTL×TTLSpreadFactor/100.00式中、creationTimeは秒、minTTLは最小生存時間秒、maxTTLは最大生存時間秒、TTLSpreadFactorは0と100との間両端値を含むのランダムに選ばれた数であり得る。例えば、最小TTLが43200秒12時間、最大TTLが129600秒36時間である場合、キャッシュオブジェクトは、それらのttlSpreadFactor値によって決定されるとおり、12時間と36時間との間で期限が切れ得る。TTLSpreadFactorは、無効な受信者に適用されることはない。システムクロックが変更されると、すでにキャッシュにあるオブジェクトの期限が変更に応じて増減し得る。実施例1:以下の実施例は、EntryオブジェクトのTTL確認を示す。publicEntrygetEntrythrowsDataAccessExceptionEntryentrycachegetEntryiftryentrysourcegetByUniqueIdgetentryfromdatasourceifaddEntryelsecacheremoveEntrycatchlogwarnreturnentry実施例2:以下の実施例は、RecipientRefオブジェクトのTTL確認を示す。publicRecipientgetRecipientthrowsDataAccessExceptionRecipientrcptnullRecipientRefrefcachegetRecipientRefififtryrcptsourcegetByEmailgetentryfromdatasourceifaddRecipientelsecacheremoveRecipientRefcatchlogwarnrcptgetRecipientelsercptgetRecipientreturnrcptprivateRecipientgetRecipientEntryentrycachegetEntryifreturnentryreturnnullディレクトリ機能すべてのディレクトリ機能に共通するタスクは、プロファイルと関連付けられたキャッシュおよびデータソースの中から受信者を見つけることであり得る。キャッシュ優先検索アルゴリズム、およびアルゴリズムと各ディレクトリ機能との関係について以下説明する。キャッシュ優先検索キャッシュ優先検索アルゴリズムはまず、キャッシュインスタンスから受信者を検索し、受信者が見つかるか、検索するキャッシュがなくなるまで続けられる。受信者がキャッシュに見つからない場合には、次に、ネガティブキャッシュエントリを持たないデータソースから受信者を検索する。受信者が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=JohnBigboote,O=sfdom1givenname:Johnobjectclass:dominoPersonuid:JBigboote_uiduid:JBigboote_uid2eng.symantec.commail:john.bigboote.maileng.symantec.comcn:JohnBigbootesn:Bigbooteeng.symantec.comおよびaliasdomain.comのメールを受信するように構成されたメールサーバーは、以下のうちの1つまたはそれ以上を無効な受信者と認識するように構成され得る。johnaliasdomain.comjohneng.symantec.combigbootealiasdomain.combigbooteeng.symantec.comjbigboote_uidaliasdomain.comjbigboote_uideng.symantec.comjbigboote_uid2eng.symantec.comjohn.bigboote.maileng.symantec.comjohn.bigboote.mailaliasdomain.comjohn.bigbootealiasdomain.comjohn.bigbooteeng.symantec.comjohn_bigbootealiasdomain.comjohn_bigbooteeng.symantec.comメールサーバー管理者は、これらのエイリアス例えば、メール属性値をユーザーの唯一の配送可能なアドレスとみなすなどをサポートしないように自身のサーバーを構成し得るので、自身のディレクトリサーバークエリを、これらの各種アドレス形態を包含あるいは除外するように構成することも可能であり得る。大規模なメールサーバー展開では、uidおよびメール属性値だけを配送可能なアドレスとして使用し得る。かかる構成は、上記実施例に続いて、以下のアドレスをサポートする。jbigboote_uidaliasdomain.comjbigboote_uideng.symantec.comjbigboote_uid2eng.symantec.comjohn.bigboote.maileng.symantec.comjohn.bigboote.mailaliasdomain.comいくつかの実施形態によれば、これらのうちの1つまたはそれ以上を捕捉する目的でクエリフィルタが使用され得る。|mail=suid=suid=u管理者がユーザーの完全名へのエイリアス化を許容するようにしている場合には、クエリを以下のように変更することができる。|mail=suid=suid=ucn=nなお、ここでは、電子メールアドレスのローカル部におけるピリオドまたはアンダーラインを表すホワイトスペースの代用となり得るnトークンが使用され、その結果、john.bigbooteeng.symantec.comまたはjohn_bigbooteeng.symantec.comはcn=johnbigbooteとなる。管理者が、ユーザーの名前および名字へのエイリアス化も許容している場合には、クエリが以下のように変更され得る。|mail=suid=suid=ucn=ngivenName=usn=u名前および名字のエイリアス化が許容されていると、同じ名前および/または名字を有する2つ以上のユーザーエントリ間で名前空間の衝突が発生する可能性がはるかに高まり得る。たとえば、仮想的なディレクトリサーバーが次のようなエントリも格納している場合、dn:CN=JohnWhorfin,O=sfdom1givenname:John...cn:JohnWhorfinsn:Whorfin受信者を一意に特定できないというテキストメッセージを伴う5xxエラーをSMTPクライアントに返すことにより、SMTPサーバー自体がjohnaliasdomain.comへの配送試行を扱い得る。ディレクトリデータサービスLDAPクエリが2つのエントリgivenName=johnを返し得るので、この状況は、上記のデータ整合エラーとして扱われ得る。図8に示すとおり、例示的な完全なアドレス、電子メールアドレスのローカル部分、対応する完全名、および例示的なクエリが、要素802に表されている。例示的なディレクトリエントリが、要素806に表されている。ディレクトリサーバーによっては例えばIBMLotusDomino、ディレクトリエントリの複数の電子メールエイリアスをサポートするものもある。要素804に示すとおり、要素806に列記されているディレクトリエントリに対して、複数の電子メールエイリアスがサポートされ得る。要素808および810に示すとおり、john_smithdomain.comの電子メールアドレスの妥当性を検証するためにクエリが受信された場合には、トークンsおよびuを使用したディレクトリサーバークエリがディレクトリエントリを見つけることはない。ただし、要素812および814に表すとおり、完全名で問い合わせるためにnトークンが使用された場合には、一致が見つかり得る。nトークンは、電子メールアドレスのローカル部におけるピリオドまたはアンダースコアをスペースで置き換えて、問い合わせ用の完全名を導出する。この時点で、上記の本開示にかかるディレクトリサーバーを統合が、ある程度までの入力データの処理と出力データの生成とを概して含むということに注意すべきである。この入力データ処理および出力データ生成は、ハードウェアまたはソフトウェアで実施され得る。例えば、上記の本開示にかかるディレクトリサーバー統合と関連付けられた機能を実行するために、ディレクトリデータサービス、または同様の回路あるいは関連する回路で、特定の電子構成要素が用いられ得る。あるいは、命令に従って動作する1つまたはそれ以上のプロセッサが、上記の本開示にかかるディレクトリサーバーを統合と関連付けられた機能を実行し得る。このような場合、かかる命令が1つまたはそれ以上のプロセッサ読み取り可能な記憶媒体例えば、磁気ディスクまたは他の記憶媒体に記憶され得るか、あるいは1つまたはそれ以上の搬送波に組み入れられた1つまたはそれ以上の信号を介して1つまたはそれ以上のプロセッサに送信され得ることは、本開示の範囲内である。本開示は、本明細書に記載されている具体的な実施形態によって範囲が制限されるものではない。実際、上記の記載内容および添付の図面から、本明細書に記載されている実施形態に加え、本開示の他の各種実施形態および変型例が当業者にとって明らかであろう。そのため、かかる他の実施形態および変型例は、本開示の範囲内に収まるものと意図される。さらに、本開示について、特定の目的のための特定の環境における特定の実施態様という文脈で本明細書に記載してきたが、当業者であれば、その有用性がそれに制限されず、本開示が任意の数の目的のために任意の数の環境で有益に実施され得ることを認識するであろう。したがって、以下に述べる請求項は、本明細書に記載されている本開示の全幅および精神を鑑みて解釈されるべきである。"