"複数のアイデンティティマネージャIMノードからの既存のアイデンティティ管理情報を結合するステップと、前記複数のIMノードからの前記結合された情報を提示するステップと、前記アイデンティティ管理情報を変更するためのプロビジョニングリクエストを受信するステップと、複数の別々のサブリクエストを形成するために、前記プロビジョニングリクエストを分解するステップと、前記サブリクエストを処理する1つ以上のIMノードを特定するステップと、前記サブリクエストを、前記1つ以上のIMノードに並行して発行するステップと、前記サブリクエストそれぞれのステータスを、当該サブリクエストを処理している前記1つ以上のIMノードそれぞれから受信するステップと、前記受信されたステータスを結合するステップと、前記結合されたステータスを、前記プロビジョニングリクエストのステータスとして返すステップと、を含む方法。少なくとも1つのIMノードが利用不可能であると判断し、前記リクエストを、後で提出するためにキューに入れるステップをさらに含む、請求項1に記載の方法。前記プロビジョニングリクエストは、アカウントまたはアクセスの作成、アカウントの修正、アカウントの一時停止、アカウントの回復、アカウントまたはアクセスの削除、未処理のtodo項目の承認または拒否、未処理のtodo項目についてのより多くの情報の提供、および未処理のリクエストの中断のうちの1つを実行することである、請求項1に記載の方法。前記アイデンティティ管理情報に関するクエリであって、アカウント情報、リクエスト情報、およびtodo情報のうちの1つに関する、前記クエリを受信するステップと、前記クエリを処理する1つ以上のIMノードを特定するステップと、前記受信されたクエリを、複数の別々のサブクエリを形成するために分解するステップと、前記サブクエリを、前記1つ以上のIMノードに並行して発行するステップと、前記1つ以上のIMノードから結果を受信するステップと、前記受信された結果を結合するステップと、前記結合された結果を返すステップと、をさらに含む、請求項1に記載の方法。メインのIMノードを、他のIMノードを発見するために検索するステップと、前記IMノードそれぞれに、当該IMノードによってサポートされているサービスのリストを取得するべく問い合わせを行うステップと、サービストポロジを作成するために、ノードを意識したサービスオブジェクトスタブを作成するステップと、をさらに含む、請求項1に記載の方法。アイデンティティ情報を見るためのリクエストをユーザから受信するステップと、メインのIMノードから前記アイデンティティ情報を読み出すステップと、前記アイデンティティ情報に対する変更を、前記ユーザから受信するステップと、前記変更を前記メインのIMノードに提出するステップであって、前記メインのIMノードは、前記変更を他のIMノードに発行し、前記メインのIMノード上のノーティファイアモジュールは、オブジェクトスタブに関する通知パケットを発行する、前記ステップと、前記通知パケットの受信に応答して、ディレクトリサーバ内の前記オブジェクトスタブを更新するステップと、をさらに含む、請求項1に記載の方法。アイデンティティ情報に対する変更を、アイデンティティフィードから受信するステップと、メインのIMノードにて前記変更を加えるステップであって、前記メインのIMノードは、前記変更を他のIMノードに発行し、前記メインのIMノード上のノーティファイアモジュールは、オブジェクトスタブに関する通知パケットを発行する、前記ステップと、前記通知パケットの受信に応答して、ディレクトリサーバ内の前記オブジェクトスタブを更新するステップと、をさらに含む、請求項1に記載の方法。請求項1~7の何れか1つに記載の方法の各ステップをコンピュータに実行させる、コンピュータプログラム。プロセッサと、前記プロセッサに連結され、動作を実行する、アイデンティティマネージャの分散型トポロジイネーブラDTEIMシステムと、を含むシステムであって、前記動作は、複数のアイデンティティマネージャIMノードからの既存のアイデンティティ管理情報を結合すること、前記複数のIMノードからの前記結合された情報を提示すること、前記アイデンティティ管理情報を変更するためのプロビジョニングリクエストを受信すること、複数の別々のサブリクエストを形成するために、前記プロビジョニングリクエストを分解すること、前記サブリクエストを処理する1つ以上のIMノードを特定すること、前記サブリクエストを、前記1つ以上のIMノードに並行して発行すること、前記サブリクエストそれぞれのステータスを、当該サブリクエストを処理している前記1つ以上のIMノードそれぞれから受信すること、前記受信されたステータスを結合すること、および前記結合されたステータスを、前記プロビジョニングリクエストのステータスとして返すこと、を含む、システム。前記プロビジョニングリクエストは、アカウントまたはアクセスの作成、アカウントの修正、アカウントの一時停止、アカウントの回復、アカウントまたはアクセスの削除、未処理のtodo項目の承認または拒否、未処理のtodo項目についてのより多くの情報の提供、および未処理のリクエストの中断のうちの1つを実行することである、請求項9に記載のシステム。前記動作は、前記アイデンティティ管理情報に関するクエリであって、アカウント情報、リクエスト情報、およびtodo情報のうちの1つに関する、前記クエリを受信すること、前記クエリを処理する1つ以上のIMノードを特定すること、前記受信されたクエリを、複数の別々のサブクエリを形成するために分解すること、前記サブクエリを、前記1つ以上のIMノードに並行して発行すること、前記1つ以上のIMノードから結果を受信すること、前記受信された結果を結合すること、および前記結合された結果を返すこと、をさらに含む、請求項9に記載のシステム。前記動作は、メインのIMノードを、他のIMノードを発見するために検索すること、前記IMノードそれぞれに、当該IMノードによってサポートされているサービスのリストを取得するべく問い合わせを行うこと、およびサービストポロジを作成するために、ノードを意識したサービスオブジェクトスタブを作成すること、をさらに含む、請求項9に記載のシステム。前記動作は、アイデンティティ情報を見るためのリクエストをユーザから受信すること、メインのIMノードから前記アイデンティティ情報を読み出すこと、前記アイデンティティ情報に対する変更を、前記ユーザから受信すること、前記変更を前記メインのIMノードに提出することであって、前記メインのIMノードは、前記変更を他のIMノードに発行し、前記メインのIMノード上のノーティファイアモジュールは、オブジェクトスタブに関する通知パケットを発行する、前記提出すること、および前記通知パケットの受信に応答して、ディレクトリサーバ内の前記オブジェクトスタブを更新すること、をさらに含む、請求項9に記載のシステム。前記動作は、アイデンティティ情報に対する変更を、アイデンティティフィードから受信すること、メインのIMノードにて前記変更を加えることであって、前記メインのIMノードは、前記変更を他のIMノードに発行し、前記メインのIMノード上のノーティファイアモジュールは、オブジェクトスタブに関する通知パケットを発行する、前記加えること、および前記通知パケットの受信に応答して、ディレクトリサーバ内の前記オブジェクトスタブを更新すること、をさらに含む、請求項9に記載のシステム。これらの要求は、従来のIMシステムにおける運用上の課題を提示する。例えば、従来のIMシステムでは、何万ものサービスの調整負荷およびスケジューリングを管理する要求、これらのサービスのIM設定タスクを分散させる必要性、およびIM機能性全体を停止することなくシステムメンテナンスアクティビティのローリングスケジュールを提供する必要性が、難題となっている。従来のIMシステムには、パフォーマンスを改善してフェイルオーバを提供するためにクラスタに展開され得るものもあるが、従来のIMシステムは、非常に大規模な構成において、メンテナンスもしくはアップグレード期間も、調整負荷管理に対する制御も、または分散化されたアドミニストレーションおよびメンテナンスも提供しない。したがって、非常に大規模な実装における既存のIMソリューションには欠点がある。例えば、クラスタにノードを追加することによる拡張性がもたらされ得るが、このソリューションは、単一のデータリポジトリというボトルネックをかかえると考えられる。さらに、機能停止またはメンテナンス期間が、IMインフラストラクチャ全体を停止させることもある。さらに、設定タスクは、単一のアプリケーション上で管理および実装され、設定負荷が一点に置かれる。複数のアイデンティティマネージャIMノードからの既存のアイデンティティ管理情報を結合する方法、コンピュータプログラム、およびシステムが提供される。複数のIMノードからの結合された情報が提示される。アイデンティティ管理情報を変更するプロビジョニングリクエストprovisioningrequestが受信される。プロビジョニングリクエストは、複数の別々のサブリクエストを形成するために分解される。サブリクエストを処理するために1つ以上のIMノードが特定される。サブリクエストは、並行して該1つ以上のIMノードに発行issueされる。サブリクエストそれぞれのステータスが、当該サブリクエストを処理している該1つ以上のIMノードそれぞれから受信される。受信されたステータスが結合される。結合されたステータスが、プロビジョニングリクエストのステータスとして返される。以下、図面を参照する。図面では、同じ参照番号は、全体にわたって対応する部分を表す。以下の記載では、添付の図面を参照する。図面は、本願明細書の一部を構成し、本発明のいくつかの実施形態を示す。当然のことながら、本発明の範囲から逸脱することなく、他の実施形態が利用されても、構造および動作上の変更が加えられてもよい。実施形態は、アイデンティティマネージャIMノードの展開に、分散型アプローチを取り入れる。分散型アプローチは、複数のIMノードの上に、アイデンティティマネージャの分散型トポロジイネーブラDTEIMノードすなわち管理ノードを提供して、複数のIMノード例えば数百または数千のサービスをホストしているにわたってサービス作業負荷を分割することに基づく。実施形態は、エンタープライズの複数のIMノードにまたがるユーザのアイデンティティおよびアカウント情報の結合された管理およびビューのために、DTEIMノードを提供する一方で、IMノードの設定およびアドミニストレーションタスクを分散化する。DTEIMノードは、ユーザリクエストを適切なIMノードへルーティングする。続いて、DTEIMノードは、種々のIMノードから受信される情報を結合して、この結合された情報をエンドユーザに提示する。様々な実施形態において、ユーザという用語は、人間であるユーザ、コンピュータプログラム、ハードウェアデバイスなどを表し得る。図1は、特定の実施形態によるシステムアーキテクチャを示す。アイデンティティマネージャの分散型トポロジイネーブラDTEIMノード100は、DTEIMサーバ110およびDTEIMディレクトリサーバ140を含む。DTEIMサーバ110は、DTEIMエンジン120を含む。DTEIMノード100は、アイデンティティマネージャIMノード150のネットワークに連結されている。特定の実施形態では、IMノード150は、IMシステムと呼ばれることもある。特定の実施形態では、DTEIMアーキテクチャという用語は、各DTEIMコンポーネントを含む、抽象的なDTEIMインフラストラクチャ全体を指す。特定の実施形態では、DTEIMトポロジという用語は、DTEIMエンジン120に制御されているIMノード150のコレクションを指す。実施形態は、アイデンティティ情報およびサービスを複数のIMノード150にわたって分散させることによって、非常に大きなIM実装における、徐々に拡張可能なソリューションを提供する。特定の実施形態では、IM実装は、IMノードのハードウェア/ソフトウェアのサイズではなく、ユーザ、サービスなどの数を含む、IMソリューションのサイズに関係する。特定の実施形態では、DTEIMサーバDTEIMサーバ110などにてDTEIMエンジン120を使用することで、以下が提供される。IMノード150をサービスのサブセット専用とすることによる改善されたパフォーマンス。すなわち、各IMノード150は、サービスのサブセットをホストする。さらに、各IMノード150は、人員peopleのサブセットを有してもよい。追加のエンドポイントを追跡するために、新たなサービスが取り入れられるときにIMノード150を追加することによる改善された拡張性。1つのIMノード150上でのモノリシックな設定ではなく、複数のIMノード150にわたる分散化アドミニストレーションおよび設定。種々のIMノード150が種々のプラットフォーム上にあることを可能にし、さらに種々のIMバージョンも可能にする、異種DTEIM機能。DTEIMエンジン120が、IMノード150に対してバージョンを意識した動作を実行する。IMインフラストラクチャ全体をシャットダウンさせることなく、メンテナンスおよびアップグレードを個々のIMノード150上で実行可能である。IMの抽象化を可能にする。IMレイヤの上にあるDTEIMレイヤを、ユーザリクエストの処理のために使用可能である。IMノード150および各IMノード150上のサービスを発見する機能を含む。外部のアプリケーションがDTEIMエンジン120とインターフェイスをとることを可能にするDTEIMモデルアプリケーションプログラミングインターフェイスAPIを含む。DTEIMエンジン120と、IMノード150との間で、ウェブサービスベースの通信を使用する。エンドユーザベースの機能性をDTEIMエンジン120上で提供する。アドミニストレータ機能性は、分散化され、IMノード150上で実行される。DTEIMエンジン120により、非常に大規模なユーザおよびサービスベースに徐々に拡張可能なソリューションを提供するための分散型IMアーキテクチャが存在する。特定の実施形態では、DTEIMトポロジは、DTEIMサーバ110を介してアクセスされる疎結合IMノード150から成る。特定の実施形態では、DTEIMエンジン120は、複合型のリバースプロキシサーバ兼情報応答結合器として機能上動く、JAVAR2プラットフォームエンタープライズエディションJ2EEJAVAR2Platform,EnterpriseEditionRアプリケーションとしてもよい。DTEIMエンジン120は、1つ以上のターゲットサービスに基づき、多数のIMメンバノードのうちの1つにユーザリクエストを分散させ例えばスプレーsprayし、アイデンティティマネージャ情報および複数のIMノードからのエンドユーザへの応答を結合する。JAVAおよびJ2EEは、米国、その他の国々、または両方における、SunMicrosystemsの商標である。DTEIMエンジン120は、DTEIMサービスを提供し、API実装を提供する。APIは、種々のIMノード150からのユーザ情報を結合し、ウェブサービスインターフェイスを使用してIMノード150と通信し、IMノード150におけるサービスを発見し、サービス対IMノードのマッピングを維持し、IMセルフサービス機能と似た機能性を提供し、ローカルDTEIMサーバを利用してノード、個人およびアカウントの関係を得る。DTEIMエンジン120は、種々のIMからの応答を結合して、エンドユーザに提示する。DTEIMエンジン120はさらに、分散型IMAPIDTEIMAPIモジュールをホストし、これは、カスタムユーザインターフェイスUIを提供するために外部のウェブアプリケーションによって使用されること、またはJAVARクライアントによって呼び出されることが可能である。下記で、DTEIMユーザインターフェイスUIウェブアプリケーションが、DTEIM機能およびAPIの使用法を説明するために提供されており、これを、カスタムUIをセットアップするためのベースとして使用することができる。特定の実施形態において、DTEIMアーキテクチャは:個々のIMノード150が、サービスのサブセット用に指定されるようにし、したがって、サービス境界に基づき負荷を分散させる。IMプラットフォームの異種混合を可能にし、その結果IMノード150は、様々なオペレーティングシステム上に展開され得る例えば、WINDOWSRオペレーティングシステム、UNIXRオペレーティングシステム、LINUXRオペレーティングシステム、またはこれらの任意の混合。WINDOWSRは、米国、その他の国々、または両方における、MicrosoftCorporationの商標である。UNIXRは、米国、その他の国々、または両方における、TheOpenGroupの商標である。LINUXRは、米国、その他の国々、または両方における、LinusTorvaldsの商標である。すなわち、IMノード150は、複数のプラットフォームおよび複数のIMバージョンにわたる、異種のものでもよい。IMバージョンの異種混合を可能にし、ノードの機能を判断するために各IMノード150のバージョンを認識する。IM機能性全体に影響することなく、個々のIMノード150がアップグレードまたはパッチ適用可能なように、時間差またはローリングアップグレードおよびメンテナンス機能を可能にする。新たに定義されたIMノード150上のサービスを発見する。新たなサービスが展開されるときに新たなIMノードをDTEIMアーキテクチャに追加できるように、分散型のサービスモデルを使用して徐々にスケーリングすることを可能にする。第1のIMノード150を、DTEIMアーキテクチャにマイグレートできる。さらに、このためにマイグレーションツールが提供される。サービス定義およびポリシに関して、各IMノード150上のサービスのサブセットを設定する別々のアドミニストレータにより、アドミニストレーションを分散化する。すべてのIMノード150にわたって何らかの共通情報を維持する。IM-IMアダプタを活用して、参加しているIMノード150に個人オブジェクトを分散させる。DTEIMトポロジは、独立して管理される疎結合IMノード150から成るため、このDTEIMトポロジは、個々のIMノード150のローカルのIMオブジェクトが、DTEIMトポロジへの負担とはならずに、IMノード150自体において設定および管理されることを可能にする。DTEIMサーバ110の焦点は、DTEIMエンジン120を使用して、DTEIMアーキテクチャ中でエンドユーザサービスを提供することである。DTEIMアーキテクチャは、高度の分散化を提供し、その一方でエンドユーザは、複数のIMノード150にわたる分散型サービスの統一ビューを得る。DTEIMアーキテクチャはさらに、IMノード150が種々の個人集団を有することを可能にし、DTEIMアーキテクチャは、複数のIMノード150にわたるユーザのフットプリントfootprintを記録する例えば、ユーザが参加するIMノード150。DTEIMアーキテクチャDTEIMアーキテクチャは、1つ以上の独立したIMメンバノードと対話するグローバルDTEIM管理ノードDTEIMサーバおよびDTEIMディレクトリサーバから成る。DTEIM管理ノードは、複数のIMノード150からのアイデンティティ管理データを、ユーザに提示するために結合し、ユーザからリクエストを受信し、リクエストを、そのリクエストのターゲットを担当する1つ以上のメンバIMノード150へルーティングする。メンバIMノード150はそれぞれ、この分散型システムが管理するサービスのサブセットを担当する、完全にクラスタ化されたIMノード150とすることができる。DTEIMUIアプリケーションも、高スループットをもたらしフェイルオーバを提供するためにクラスタ化されることが可能である。DTEIMノード100は、IMノード情報を管理し、リクエストをルーティングし、結果を結合し、ユーザインターフェイスの開発のためのAPIを提示する機能を提供する。特定の実施形態では、DTEIMノード100は、ローカルのライトウェイトディレクトリアクセスプロトコルLDAPデータストアまたはLDAPディレクトリサーバを使用して、設定情報と、エンティティオブジェクトのオブジェクトスタブとを保持し、オブジェクトスタブは、当該エンティティオブジェクトの分散した位置をポイントする。オブジェクトスタブは、人員すなわち人員スタブ、アカウントすなわちアカウントスタブ、サービスすなわちサービススタブなどに関するとよい。各オブジェクトスタブは、IMノード150に記憶されている完全なエンティティオブジェクト人員、アカウント、サービスなどに関するをポイントする。IMノード150のうちの1つは、メイン人員ノードとして指定される。DTEIMノード100をバイパスして、このメイン人員ノードに、アイデンティティ/人材HR:HumanResourceフィードが入力されるとよい。IM-IMアダプタは、メインのIMノード150から他のIMノード150へ、ポリシ設定を用いて個人オブジェクトを分散させるために活用される。すなわち、各IMノード150は、メインのIMノード150からIM-IMアダプタを介してアイデンティティフィードを得る。子IMノード150はそれぞれ、メインのIMノード150内の管理対象プラットフォームのように見える。IMポリシおよび自動エンタイトルメントentitlementが、個人基準に基づき個人オブジェクトを子IMノードに分散させるよう設定されるとよい。特定の実施形態では、IM-IMアダプタは、標準のアダプタフレームワークを使用する。特定の実施形態では、DTEIMノードは、IMAPIのウェブサービスベースの抽象化を使用することによって、IMノードと通信する。例えば、DTEIMノードは、ユーザリクエストを、ウェブサービスインターフェイス上で適切なIMノードへルーティングする。DTEIM分散は、各IMノードの前方にインストールされたIMウェブサービスコネクタを含む。これは、IMノードと通信するときのIMAPIおよびウェブサービスバージョン依存をなくし、ライトウェイトで標準の通信の、ハイパーテキスト転送プロトコルHTTP:HyperTextTransferProtocolベースのプロトコルを、他のプロトコル例えば、IMAPIによって使用される、JAVARリモートメソッド呼び出しRMI:RemoteMethodInvocationインターフェイスオーバインターネットインターOrbプロトコルIIOP:InternetInter-OrbProtocolRMIオーバIIOPとも呼ばれるの代わりに提供する。IMノード上で独立して、またはDTEIMノードから開始された動作の結果として生じる個人およびアカウント変更については、DTEIMインフラストラクチャの一部としてIMノード上にインストールされているDTEIMノーティファイアモジュールnotifiermoduleを介してDTEIMノードに通知が返される。DTEIMノーティファイアモジュールは、IMノードからDTEIMノードへの通信に、ウェブサービスベースの通信を使用する。図2は、特定の実施形態によるDTEIMアーキテクチャを示す。図2では、DTEIMアーキテクチャのアーキテクチャ上のコンポーネントは、DTEIMレイヤ200にあるDTEIMサーバ110およびDTEIMディレクトリサーバ140、ならびにIMレイヤ250の各IMノード260a、260b、...260nにそれぞれあるDTEIMノーティファイアモジュール230a、230b、...230nから成る。DTEIMサーバ110にあるDTEIMリスナは、各DTEIMノーティファイアモジュール230a、230b、...230nからの通知をリッスンする。図2の例では、DTEIMレイヤは、DTEIMサーバ110で実行されているDTEIMエンジン120から成る。特定の実施形態では、DTEIMエンジン120は、J2EERアプリケーションであり、DTEIMディレクトリサーバ140は、LDAPデータストアまたはLDAPディレクトリサーバである。DTEIMLDAPデータストアは、複数のDTEIMノードにわたるすべてのサービスおよびアカウントのサービスオブジェクトおよびアカウントオブジェクトのオブジェクトスタブを含む。LDAPデータストアはさらに、メインのIMノード260a上の個人オブジェクトをポイントするオブジェクトスタブを含む。DTEIMLDAPデータストアは、ルックアップ用のオブジェクトスタブのステージングリポジトリである。DTEIM構成およびIMトポロジも、LDAPデータストアに記憶される。DTEIMエンジン120は、個人情報を、メインのIMノード260aから読み出すスタブリファレンスをたどって。次に、変更がメインのIMノード260aに再び書き込まれ、メインのIMノード260aは、その変更を参加しているIMノード260b...260nに、IM-IMアダプタ272b...272nを介して分散させる。DTEIMエンジン120は、アカウントスタブリファレンスをたどることによって、アカウントオブジェクトを読み出して更新する。DTEIMエンジン120は、他のオブジェクトを、参加しているIMノード260a、260b、...260nから並行して読み出す。したがって、オブジェクトを読み出す時間は、単一の任意のIMから読み出すのにかかる最も長い時間と同じ長さである。メインのIMノード260aは、アイデンティティリポジトリ、さらに任意選択でサービスのサブセットをホストすることもできる。アイデンティティリポジトリは、個人エンティティのコレクションを記憶する。IMレイヤ250は、1つ以上のIMノード260a、260b、...260nから成る。IMノード260a、260b、...260nは、地理的に離れていてもよい。各IMノード260a、260b、...260nは、それぞれ、IMサーバ262a、262b、...262n、IMディレクトリサーバ264a、264b、...264n、IMデータベース266a、266b、...266n、IMウェブサービス268a、268b...268n、およびエンドポイント270a、270b、...270nを含む。IMノードの1つであるIMノード260aは、メインのIMノードとして指定され、IMデータベース266aまたは他のデータストアにおいてすべてのアイデンティティを維持する。アイデンティティフィードは、メインのIMノード260a上でアイデンティティフィード210を介して実行される。他のIMノード260b...260nはそれぞれ、IM-IMアダプタ272b...272nを含む。DTEIMノーティファイアモジュール230a、230b、...230nは、ワークフロープロキシモジュールであり、それぞれ各IMノード260a、260b、...260nにインストールされ、DTEIMエンジン120に、個人およびアカウントオブジェクト作成または削除について通知する。この通知は、IMウェブサービス268a、268b、...268nを介して送信されてもよい。各IMノード260a、260b、...260nは、DTEIMエンジン120に、アカウントおよび個人変更を、ウェブサービスインターフェイスを使用して、ノーティファイアモジュールを介して通知する。例えば、エンティティオブジェクトの追加および削除が通知される。特定の実施形態では、一時停止/回復以外の属性変更は通知されない。IMウェブサービスは、IMAPIのウェブサービスラッパwebserviceswrapperと表現することもできる。DTEIMアーキテクチャは、IMウェブサービス268a、268b、...268nのIMAPIウェブサービスラッパを活用してIMノード260a、260b、...260nと通信し、標準のIM-IMアダプタ272b...272nを活用して個人情報をIMノード260a、260b、...260nに分散させる。図2では、DTEIMエンジン120は、IMノード260a、260b、...260nを管理する。ノード-1は、メインのIMノード260aであり、サービスのサブセットを管理する。ノード-2およびノード-nは、その個別のサービスのサブセットを管理するIMノード260b、260nである。各IMノード260a、260b、...260nは、IMプラットフォームに対するDTEIMエンジン120による呼び出しをリッスンするIMウェブサービス268a、268b、...268nを有する。特定の実施形態では、DTEIMエンジン120は、標準のハイパーテキスト転送プロトコルセキュアHTTP/S:HyperTextTransferProtocolSecureまたはシンプルオブジェクトアクセスプロトコルSOAP:SimpleObjectAccessProtocoloverHTTPSによってIMウェブサービス268a、268b、...268nと通信する。IMウェブサービス268a、268b、...268nは、内部でIMAPIを使用して呼び出しを処理し、ウェブサービス応答を返送するとよい。非JAVARクライアント例えば、.netクライアントも、IMノード260a、260b、...260nと通信できる。IMAPIの複雑さは、ウェブサービス機能APIによって抽象化される。マスタ-子またはピアツーピアDTEIMトポロジは、マスタ-子トポロジまたはピアツーピアトポロジのいずれかとして構成可能である。ピアツーピアトポロジでは、各IMノードが、信頼できるソースからの独立したアイデンティティフィードを有する。異なるIMノードの共通の個人は、同じ固有の識別属性を1つ以上有する。図2は、マスタ-子トポロジを示す。マスタ-子トポロジでは、IMノードのうちの1つであるIMノード260aが、メインすなわち、マスタのIMノードとして指定され、エンタープライズ内のすべての人員が、アイデンティティフィード210例えば、信頼できるソースからのを介してメインのIMノードにおいてポピュレートされる。特定の実施形態では、メインのIMノード260a上の人員は、メインのIMノード260aにおける役割role割り当てまたは手動リクエストによって、IM-IMアダプタ272b...272nを介して他のIMノード260b...260nにプロビジョニングされる。マスタ-子トポロジでは、ユーザが、同じ認証情報を用いてIMノード260a、260b、...260nのいずれかにおいて認証されることが可能なように、各IMノード260a、260b、...260nが共通の認証プロバイダを使用すると、DTEIMエンジン120は想定する。このタイプの認証は、典型的には、エンタープライズディレクトリなどの外部の認証リポジトリを使用して実現される。特定の代わりの実施形態では、DTEIMエンジン120およびIMノードが、シングルサインオンSSO:SingleSignOn機能を提供するアクセス制御製品を活用し、認証がアクセス制御製品に委任されてもよい。エンドユーザは、IMノード260a、260b、...260nに対して使用し得るのと同じ認証を用いて、DTEIMエンジン120にログオンする例えば、シンプル認証、シングルサインオンSSO、クライアント証明書による認証など。DTEIMエンジン120は、メインのIMノード260aに対し認証を行うまたはセッションを確立する。特定の実施形態では、エンドユーザは、メインのIMノード260a上およびユーザがアカウントを管理したいその他任意のIMノード260b、...260n上にIMアカウントを有する。個人修正エンドユーザによる個人修正リクエストは、DTEIMエンジン120によって、メインのIMノード260aから処理される。そこでリクエストが実行された後、IM-IMアダプタ272b...272nフレームワークが、影響を受けるIMノード260a、260b、...260nに変更を分散させる例えば、スプレーする。個人がIMノード260a、260b、...260nに追加されるか、またはそこから消去されると、そのIMノード260a、260b、...260n上のDTEIMノーティファイアモジュール230a、230b、...230nがDTEIMエンジン120に通知し、DTEIMエンジン120は、IMノード260a、260b、...260n上の該個人のオブジェクトを参照するオブジェクトスタブを、DTEIMディレクトリサーバ140に追加するか、またはそこから消去する。特定の実施形態では、特定のIMノード260a、260b、...260n上でのみ個人修正がある。そのような実施形態では、IM-IMアダプタ272b...272nを使用して、各IMノード260a、260b、...260nが、メインのIMノード260a上のサービスとして表される。IMノード260a、260b、...260n上のユーザの個人オブジェクトは、アイデンティティアカウントとして表される。DTEIMエンジン120を使用して、ユーザは、任意のIMノードからのアイデンティティアカウントを選ぶことによってこのアカウントを管理できる。アカウントおよびパスワード管理DTEIMエンジン120は、個人によって所有されているすべてのアカウントのオブジェクトスタブを維持する。IMノード260a、260b、...260n上のDTEIMノーティファイアモジュール230a、230b、...230nは、アカウントオブジェクト作成および削除通知をDTEIMエンジン120に送信する。DTEIMエンジン120は、一度にユーザが、すべてのIMノード260a、260b、...260n上のアカウント、または選択的に1つのIMノード260a、260b、...260n上のアカウントを管理することを許可する。1つ以上のサービスに関するプロビジョニングリクエストがDTEIMエンジン120に提出されると、DTEIMエンジン120は、そのサービスを管理するIMノード260a、260b、...260nを判断し、このアカウントリクエストを、このサービスを担当するIMノード260a、260b、...260nへルーティングする。特定の実施形態では、サービスは、エンドポイントすなわち、IMノードによって管理されるシステムを表すものとして表現することもできる。そこでリクエストが実行された後、DTEIMノーティファイアモジュール230a、230b、...230nは、通知をDTEIMエンジン120に送信し、DTEIMエンジン120は、アカウントスタブをDTEIMディレクトリサーバ140内に作成する。特定の実施形態では、IMノード260a、260b、...260n内のアカウントオブジェクトに対する単純な属性変更は、DTEIMディレクトリサーバ140上のDTEIMオブジェクトスタブに返送されず、そのため、それらがDTEIM-IMトラフィックを増大させることはない。ユーザが既存のアカウントを閲覧または修正したい場合、DTEIMエンジン120は、アカウントスタブを展開してIMノード260a、260b、...260nにアクセスすることにより、アカウント情報をエンドユーザに対してレンダリングする。DTEIMエンジン120は、パスワード変更リクエストを、ターゲットIMノード260a、260b、...260nに並行して分散させる例えば、スプレーする。ユーザにとって便利なように、DTEIMエンジン120は、パスワード変更リクエスト内のターゲットアカウントが複数のIMノード260a、260b、...260n上にあれば、パスワードルールをIMノード260a、260b、...260nにわたって結合する。アクセス情報は、参加しているIMノード260a、260b、...260nから並行して読み出される。アクセスは、読み出し、プロビジョニング、または消去されることが可能である。リクエストおよび割り当て管理DTEIMエンジン120は、ユーザが参加しているすべてのIMノード260a、260b、...260nから並行してリクエスト情報または割り当て情報assignmentinformationを得る。特定の実施形態では、DTEIMエンジン120は、ユーザが参加していないIMノード260a、260b、...260nには接続しない。複数のIMノード260a、260b、...260nからのリクエストまたは割り当てが並行して読み出されるため、読み出すための時間は、任意の1つのIMノード260a、260b、...260nから読み出すのにかかる最も長い時間と同じだけの長さであるプラス小さなスレッド管理オーバーヘッド。さらに、割り当て項目は、IMノード260a、260b、...260nにわたって単一のアクションでまとめて実行されてもよい。割り当て項目は、参加者に関するtodo項目と表現することもできる例えば、別のユーザに関するプロビジョニングリクエストの未処理の承認/拒否項目、プロビジョニングリクエストについてより多くの情報を提供する未処理のリクエスト、など。IMノードアドミニストレーション特定の実施形態では、DTEIMアーキテクチャは、IMノードの非常に緩やかな結合を可能にするため、DTEIMレイヤ200では、何らのポリシ、役割、または他の設定項目も、定義または設定されない。IMアドミニストレータ例えば、システムアドミニストレータまたは他のユーザは、IMノード260a、260b、...260nを、アイデンティティ管理の現在の機能を使用して設定する。特定の実施形態では、設定ステップの多くは、任意のIMノードに対して実行され得るように実行されるとよい。この設定には、以下が含まれる:パスワードチャレンジ設定。これは、マスタ-子トポロジのメインのIMノード260a上で設定される。個人ワークフローカスタマイズは、メインのIMノード260a上で設定される。個人ワークフローカスタマイズは、他のIMノード260b...260nのローカルのオブジェクトにアクセスするカスタム動作ワークフローが当該IMノード260b...260n上で必要であれば、任意選択で当該IMノード260b...260n上で設定可能である。サービスプロファイルは、それに関するサービスをホストするIMノード260a、260b、...260n上にインストールされる。プロビジョニングポリシは、ターゲットサービスをホストするIMノード260a、260b、...260n上で定義される。特定の実施形態では、プロビジョニングポリシは、当該IMノード260a、260b、...260nでホストされていないサービスはターゲットにしない。特定の実施形態では、別々のプロビジョニングポリシが別々のIMノード260a、260b、...260n上で設定されてもよい。特定の実施形態では、サービス選択ポリシの複数のターゲットが、同じIMノード260a、260b、...260n上にある。IMアカウントすなわち、システムユーザオブジェクトが、メインのIMノード260a、およびユーザが管理する必要があるすべてのIMノード260b...260n上にプロビジョニングされる。エンタイトルメントワークフローは、そのエンタイトルメントをターゲットとするプロビジョニングポリシを保持するIMノード260a、260b、...260n上で定義される。エンタイトルメントは、エンドポイント上にuseridを有するための、個人の権限と表現することもできる。エンタイトルメントワークフローは、個人がエンドポイント上でuseridを得る権限を与えられている場合に、その個人がそのエンドポイント上でuseridの作成または修正をリクエストすると実行される。パスワードおよびアイデンティティポリシは、ターゲットサービスをホストするIMノード260a、260b、...260n上で定義される。グローバルすべてのサービスパスワードまたはアイデンティティポリシが必要であれば、グローバルパスワードが、メインのIMノード260a上、さらに他のIMノード260b...260n上で定義される。DTEIMアドミニストレーション機能が、グローバルパスワードおよびアイデンティティポリシを、すべてのIMノード260a、260b、...260nに対して複製する。パスワード編集およびパスワード同期機能は、IMノード260a、260b、...260nにわたって全く同じに定義されるが、これは、DTEIMエンジン120が、プロビジョニングリクエストをIMノード260a、260b、...260nに送る前にそれらを必要とするためである。パスワードインターセプトエージェントが、DTEIMレイヤ200にてサポートされてもよい。この機能性は、パスワード同期のために有用である。DTEIMアーキテクチャのさらなる詳細DTEIMエンジン120は、エンドユーザ機能性を提供する。特定の実施形態では、分散化のために、アドミニストレーション上のタスクおよび設定タスクは、IMノード260a、260b、...260n上で実行される。特定の実施形態では、IMノード260a、260b、...260n内で、通知のポストオフィスコンソリデーションpostofficeconsolidationが行われる。ポストオフィスは、同じユーザへの頻繁な複数の電子メール通知を1つに結合して電子メールトラフィックを削減する、電子メール通知コンソリデーション機能と表現することもできる。ポストオフィスコンソリデーションは、IMノードの機能であってもよく、DTEIMエンジン120によって直接影響されない。特定の実施形態では、プロビジョニングポリシは、異なるIMノード260a、260b、...260nのサービスをターゲットとせず、各IMノード260a、260b、...260nにおいて別々のプロビジョニングポリシが設定される。特定の実施形態では、すべてのサービスインスタンスが同じIMノード260a、260b、...260nになければ、パスワードおよびアイデンティティポリシは、サービスプロファイルをターゲットとしない。特定の代わりの実施形態では、すべてのサービスインスタンスが同じIMノード260a、260b、...260nになく、相反するポリシに関する混乱を避けるためにポリシが各IMノード260a、260b、...260n上で同一であれば、パスワードおよびアイデンティティポリシはサービスプロファイルをターゲットとする。特定の実施形態では、アカウント関係を含む個人アクセス制御項目ACIs:AccessControlItemsが、そのアカウントに関するサービスをホストするIMノード260a、260b、...260n上でセットアップされる。ACIは、IMデータに誰がどの程度アクセスできるかを制御する。データが、同じノード上にない複数のアカウントから参照される一部の実施形態では、個人ACIフィルタオプションは使用されない。特定の実施形態では、カスタムワークフローは、当該IMノード260a、260b、...260n上でホストされていないサービスを参照するための動作アクティビティを使用しない。カスタムワークフローは、サービスおよび関係のあるオブジェクトをホストする1つ以上のIMノード260a、260b、...260n上で作成される。特定の実施形態では、サービスは、同じノード内の他のサービスを必須として列挙してもよい。DTEIMリファレンスユーザインターフェイスUIDTEIMリファレンスUIは、エンドユーザUIである。DTEIMリファレンスUIは、セルフサービスユーザ機能を提供するすなわち、アドミニストレーションタスクがローカルIMノード上に分散化される。DTEIMリファレンスUIは、DTEIM機能性を示すためにDTEIMエンジン120とともに提供される。特定の実施形態では、DTEIMリファレンスUIは、DTEIMAPIのリファレンス実装である。DTEIMリファレンスUIは、DTEIMAPIの利用法を示す。様々な実施形態において、他のUIが、DTEIMAPIに対して書かれることができ、または、DTEIMリファレンスUIが、組織の要求に従ってUIを供給するための基礎として使用されることができる。特定の実施形態では、DTEIMリファレンスUIは、ビューの処理にJAVARサーバフェイシズJSF:JAVARServerFacesを使用し、IMノードとの通信にDTEIMAPIを使用する。DTEIMリファレンスUIは、DTEIMリファレンスUIをカスタマイズするのに使用可能なソースコードおよびJAVARドキュメンテーションを含む。DTEIMリファレンスUIの機能性は、エンドユーザがIMUI内で見ることになる機能性に基づく。DTEIMエンジン120は、エンドユーザ機能を対象としているため、DTEIMリファレンスUIは、アドミニストレーション上の機能は含まない。DTEIMアーキテクチャでは、アドミニストレーション上の機能は分散化され、アドミニストレータによってIMノード上で直接実行される。インストール後、DTEIMリファレンスUIは、特定の位置または統一資源位置指定子URL:UniformResourceLocator例えばhttp://hostName:portNumber/DTEIM/index.htmlへとナビゲートすることによってアクセス可能である。以下のスクリーンショットは、DTEIMリファレンスUIスクリーンの一部を示す。図3は、特定の実施形態による例示としてのDTEIMログインスクリーン300を示す。ログイン機能は、メインのIMノードに対するユーザ認証を行う。パスワードチャレンジも、メインのIMノードに対して認証が行われる。認証は、例えば、シンプル認証、シングルサインオンSSO、クライアント証明書による認証などを使用してもよい。図4は、特定の実施形態による、UIスクリーン400内の例示としてのDTEIMホームページを示す。DTEIMホームページは、ユーザのIMアクティビティおよびアカウントの概要を示す。ログインしたユーザのフットプリントが示されている。特定の実施形態では、ユーザは1つ以上のIMノードに存在してもよい。DTEIMホームページは、アカウントおよび未処理の項目を示す。図5は、特定の実施形態による、UIスクリーン500内の例示としてのDTEIMアドミニストレーションページを示す。DTEIMアドミニストレーションページは、分散型トポロジに参加しているすべてのIMノードを列挙する。IMノードは、非アクティブにセットされることが可能であり、DTEIMエンジン120は、そのIMノードをIM動作から除外するか、またはそのIMノードが再アクティブ化されるまで動作を遅延させる。DTEIMアドミニストレーションページは、ノードのリストの設定を可能にする。1つ以上のノードが、メンテナンスのために非アクティブ化され得る例えば、redノードは非アクティブであり、そのredノードのテストボタンは選択できない。図6は、特定の実施形態による、UIスクリーン600内のグローバルIMからトポロジをインポート機能の選択を示す。グローバルIMからトポロジをインポート機能は、DTEIMトポロジ全体をメインのIMノードから自動的にインポートする。DTEIMは、IM-IMアダプタプロファイルのサービスインスタンスを使用して、それらをDTEIM内のIMノードとしてインポートする。ノード問い合わせ機能InterrogateNodefunctionは、ノードのIMサービス、ならびにIMバージョンおよびフィックスパックレベルを問い合わせる。サービスのオブジェクトスタブは、DTEIMLDAPデータストアに記憶されている。IMバージョンレベルは、ノード上での実行が可能である後の機能を決定する。図7は、特定の実施形態による、UIスクリーン700内のノードサービス閲覧タブの選択を示す。ノードサービス閲覧タブは、IMノードのいずれかのサービスを示すIMノード問い合わせ機能を介して各IMノードに問い合わせることにより、DTEIMエンジン120により認識されている。ノードサービス閲覧タブは、IMノード上で利用可能なサービスを示す。DTEIMエンジン120は、ローカルデータストアを有し、これをDTEIMエンジン120が、IMノード問い合わせ動作中にIMノードのサービスによりポピュレートする。図8は、特定の実施形態による、UIスクリーン800内のDTEIMアドミンメニューおよびIMノード追加タブの選択を示す。一部の図面では、選択されているオプションが点線で示されている例えば、図8のDTEIMアドミン。IMノード追加タブにより、新たなIMノードをDTEIM構成に手動で追加できる。特定の実施形態では、IMノードがDTEIMアーキテクチャに追加される前に、IMソフトウェアがIMノード上にインストールされる。新たなIMノードの追加は、DTEIMノードアーティファクトすなわち、ノーティファイアモジュールおよびIM-IMアダプタのインストールを伴うこともある。図9は、特定の実施形態による、UIスクリーン900内のパーソナル情報管理メニューおよびパーソナル情報タブの選択を示す。パーソナル情報管理メニューは、メインのIMノードから個人情報を読み出す。DTEIMエンジン120は、このIMUIに似た個人情報を表示する。IMにおける個人フォーム変更は、リアルタイムでDTEIMエンジン120によって追跡される。パーソナル情報タブは、IMフォーム定義を使用してレンダリングされてもよい。図10は、特定の実施形態による、UIスクリーン1000内のアカウント管理メニューの選択を示す。アカウント管理スクリーンは、すべてのIMノードにわたるすべてのアカウントを結合し、それらをエンドユーザに示す。ユーザが、ダウンしている非アクティブIMノード上にアカウントを保持する場合、そのアカウントは列挙されるが、IM動作からは除外されるか、または遅延させられる。アカウントは、1つ以上のIMノードから選択されてもよい。図11は、特定の実施形態による、UIスクリーン1100内の新アカウント追加メニューの選択を示す。DTEIMエンジン120は、ユーザがアカウントをリクエストできる、権限を与えられているサービスすべてを列挙する。権限を与えられているサービスのリストは、ユーザがフットプリントを有するすべてのIMノードから結合される。DTEIMエンジン120はさらに、サービスが存在するノードと、ノードのIMバージョンとを列挙する。特定の実施形態では、サービスは、WINDOWSRサービスまたはLINUXRサービスとしてもよい。図12は、特定の実施形態による、UIスクリーン1200内のアクセス管理メニューの選択を示す。アクセス管理機能は、ユーザによって保持されているアクセスを示す。リストは、IMノードから読み出され得る。これは、新たなアクセスのプロビジョニングをサポートする。アクセスは、エンドポイント上の既存のuseridに加えて、より粒度の細かいアクセスレベルの論理的プロビジョニングを意味するIM用語と表現することもできる。図13は、特定の実施形態による、UIスクリーン1300内のパスワード管理メニューの選択を示す。パスワード管理機能により、ユーザは、1つ以上のアカウントに対しパスワードをセットできる。DTEIMエンジン120は、パスワードルールを各IMノードにわたって結合し、パスワードの妥当性を確保する。複数のIMノードにわたるアカウントに対してユーザがパスワード変更を提出すると、DTEIMエンジン120は、リクエストを、IMノード毎にサブリクエストに分解し、別々のIMノードに対するパスワード変更動作を提出する。さらに、DTEIMエンジン120は、この複数のIMノードにわたってパスワードルールをマージしてもよい。図14は、特定の実施形態による、UIスクリーン1400内のリクエスト管理ページを示す。リクエスト管理ページは、完了した、または未処理のリクエストを読み出すために使用され得、未処理のリクエストは、複数のIMノードにわたって中断されることもできる。図15は、特定の実施形態による、UIスクリーン1500内のToDo項目管理ページを示す。ToDo項目管理ページは、個々の項目、ならびにグループ化された項目を提供し、複数のIMノードにわたる一括承認および拒否を提供する。DTEIMエンジン120は、IMノード毎に承認および拒否動作を分解し、それらを別々のIMノードに並行して提出する。図16は、特定の実施形態による、UIスクリーン1600内のグループ化された再認証リクエストのレビューページを示す。グループ化された再認証リクエストのレビューページは、一括承認/拒否の例を提供している。DTEIMAPIDTEIMエンジン120は、DTEIMエンジン120と通信するためにカスタムユーザインターフェイスまたはJavaクライアントアプリケーションによる使用が可能なAPIを提供する。DTEIMリファレンスUIは、DTEIMAPIを使用する外部アプリケーションの例である。DTEIMAPIは、JAVARベースとしてもよい。DTEIMAPIは、トポロジ透過APIを提供する。DTEIMAPIを用いると、クライアントは、IMノードの分散を意識する必要がない。DTEIMAPIは、セルフサービス機能を提供する。DTEIMAPIは、DTEIMエンジン120と通信するために、カスタムUIまたはJAVARクライアントアプリケーションによって使用可能である。DTEIMデータサービスAPIDTEIMデータサービスAPIは、DTEIMLDAPデータストア内のDTEIMデータオブジェクトを表し、エンティティおよび検索動作を提供する。DTEIMプロバイダAPIDTEIMプロバイダAPIは、DTEIM動作へのアクセスを提供する。DTEIMプロバイダAPIは、エンドユーザ機能性の提供に限られる。特定の実施形態では、DTEIMプロバイダAPIは、アドミニストレーション上の機能性および設定機能性は提供しない。特定の実施形態では、DTEIMプロバイダAPIは、以下のプロバイダから成る:アカウントサービスプロバイダ-アカウントおよびアクセスに関係するAPIを提供する。認証プロバイダ-認証およびセッションに関係するAPIを提供する。フォームプロバイダ-フォームを得て構文解析するためのAPIを提供する。Orgorganizational:組織コンテナサービスプロバイダ-組織コンテナをトラバースするAPI。個人サービスプロバイダ-IM個人に関係するAPIを提供。リクエストサービスプロバイダ-エンドユーザの範囲のリクエストに関係するAPIを提供する。役割サービスプロバイダ-エンドユーザの範囲の組織役割に関係するAPIを提供する。サービスサービスプロバイダ-IMサービスに関係するAPIを提供する。システムユーザプロバイダ-システムユーザIMサービスアカウントに関係するAPIを提供する。ToDoProvider-割り当ておよびIMtodoに関係するAPIを提供する。DTEIMノードはさらに、DTEIMアドミニストレーションおよび認証のためにエンタープライズJAVARビーンEJB:EnterpriseJAVARBeanレイヤインターフェイスを提供する:認証マネージャ-認証に関係する機能を管理する認証プロバイダのEJBラッパ。スタブマネージャ-DTEIMディレクトリサーバ内のスタブを管理する。DTEIMAPIの使用例本願明細書の例は、DTEIMAPIの説明に役立つものであり、DTEIMAPI全体の例の包括的なリストではない。図17は、特定の実施形態による、認証のためにDTEIMAPIを使用する例であるコードスニペット1700を示す。図18は、特定の実施形態による、DTEIMLDAPデータストアからユーザのアカウントスタブおよびアカウントデータを読み出すためにDTEIMデータサービスAPIを使用する例であるコードスニペット1800を示す。これらのアカウントスタブは、種々のIMノードにわたってアカウントデータを備えるアカウントをポイントする。図19は、特定の実施形態による、アカウントスタブを読み出すためにDTEIMデータサービスAPIを使用する例であるコードスニペット1900を示す。図20は、特定の実施形態による、アカウントの更新または作成の例であるコードスニペット2000を示す。図21は、特定の実施形態による、アカウントのユーザの、権限を与えられたサービスを読み出す例であるコードスニペット2100を示す。このDTEIMAPI呼び出しは、ユーザがアカウントを得る資格を有するサービス複数のIMノードにわたるの統合されたリストをもたらす。図22は、特定の実施形態による、個人のポピュレートされたフォームを得る例であるコードスニペット2200を示す。DTEIMエンジン120は、個人に関してポピュレートされたフォームを含むDTEIMFormオブジェクトを提供する。DTEIMFormオブジェクトは、DTEIMFormTabオブジェクトを含み、そのそれぞれが、DTEIMFormElementオブジェクトを含む。各DTEIMFormElementは、属性名、値、およびフォーマット情報を含む。DTEIMエンジン120は、フォーム構成要素内の制御をサポートする検索制御、検索一致、ドロップダウンリストなど。これらの特性は、J2EEビュー技術を使用するフォームのレンダリングを制御するために使用可能である。DTEIMリファレンスUIは、JAVARサーバフェイシズJSFおよびフェイスレットを使用して、メタフォーム構成要素タグを定義し、DTEIMFormElementオブジェクトをレンダリングのために渡す。図23は、特定の実施形態による、パスワードルールを得る例であるコードスニペット2300を示す。DTEIMエンジン120は、1つ以上のアカウントのパスワードルールを得るためのAPIを提供する。これらのアカウントが種々のIMノード上の複数のサービス上でホストされていれば、DTEIMエンジン120は、パスワードルールを返す前に、各ノードにわたってルールをマージする。図24は、特定の実施形態による、パスワード変更の例であるコードスニペット2400を示す。DTEIMエンジン120は、パスワード変更リクエストを提出する前に新たなパスワードが妥当かどうか確認するためのAPIを提供する。これは、複数のサービス/ノードにわたってパスワードを変更するときに役立ち、無効なパスワードによるリクエストの失敗を防止する。パスワード検証中に生成されたオブジェクトは、nodeAwareAccountMOsコレクションにおけるパスワード変更中に再利用される。図25は、特定の実施形態による、参加しているIMノードからtodo項目のリストを得る例であるコードスニペット2500を示す。DTEIMLDAPデータストア図26は、特定の実施形態によるDTEIMLDAPデータストア2600を示す。図27、28、および29は、特定の実施形態によるスキーマ2700、2710、2720を示す。図30は、特定の実施形態によるユーザインターフェイス2800内のアカウントスタブの例を示す。nodeglobalid属性は、もとのアカウントオブジェクトの相対識別名RDN:RelativeDistinguishedNameであり、オブジェクトのもとのRDNを使用し、そのRDNに、At<nodeId>のサフィックスを付けることによって、一意性を確保するためにDTEIMエンジン120によって生成される。アカウントスタブは、useridすなわちUID以外には何らのアカウント特有属性も含まない。特定の実施形態では、DTEIMエンジン120は、メインのIMノード上のIMアカウントのみを追跡するため、IMサービスアカウントはノードサフィックスを含まない。図31は、特定の実施形態によるユーザインターフェイス2900内の個人スタブの例を示す。nodeglobalid属性は、個人オブジェクトのRDNであり、オブジェクトのもとのRDNを使用し、そのRDNに、At<nodeId>のサフィックスを付けることによって、一意性を確保するためにDTEIMエンジン120によって生成される。特定の実施形態では、ウェブサービスは、IMノードと同一場所に配置されたウェブアプリケーションとして実行される。ウェブサービスは、単純なクライアントおよびデータモデルを使用するとよい。ウェブサービス記述言語WSDL:WebServicesDescriptionLanguageファイルを、ウェブサービスクライアントおよびデータモデルを生成するために使用可能である。WSDLは、非JAVARクライアントを生成するために使用されてもよい。さらに、特定の実施形態では、事前生成されたJAVARクライアントが提供される。ウェブサービスは、セッション識別子ID:identifierを確立することによってスレッド会話を提供する。図32は、特定の実施形態によるウェブサービスアーキテクチャ3000を示す。特定の実施形態では、コンソールアプリケーションは、JAVARコンソールアプリケーションである。特定の実施形態では、アプリケーションサーバは、WEBSPHERERアプリケーションサーバである。WEBSPHEREは、米国、その他の国々、または両方における、インターナショナルビジネスマシーンズIBM:InternationalBusinessMachinesコーポレーションの商標である。特定の実施形態では、ウェブサービススイートは、機能的に独立したサービスから成り、単一のプロキシファサードを備える:セッションサービスアカウントサービスフォームサービス組織コンテナサービスパスワードサービスリクエストサービス役割サービスサービスサービスすなわち、IMサービスを制御するウェブサービス。データ検索サービスシステムユーザサービスToDoサービスアクセスサービスプロビジョニングポリシサービスIMサービス結合された単一のプロキシサービス特定の実施形態では、事前生成されたウェブサービスクライアントが、ウェブサービスファクトリクラスを提供する。ウェブサービスファクトリは、各ウェブサービスを公開し、クライアントがサービスアドレスを判断する必要性をなくす。ウェブサービスファクトリは、IMウェブサービスの任意のもののインスタンスを提供することができる。ウェブサービスの取得は、機能的に単純である例えば、webServiceFactory.getWSPaswordService。図33は、特定の実施形態による、IMノードに対し認証を行ってユーザの個人オブジェクトを取得するために、ウェブサービスを使用する例であるコードスニペット3100を示す。図34は、特定の実施形態による、IMノードトポロジを発見するためにDTEIMエンジン120によって実行される論理をフロー図で示す。図34では、DTEIMエンジン120は、設定タスクを実行しており、発見されたノードおよびサービスをLDAP内に記憶している。制御は、ブロック3200にて始まり、DTEIMアドミニストレータが、メインのIMノードから設定を開始する。ブロック3202において、DTEIMエンジン120は、メインのIMノードを、他のIMノードを発見するために検索する。ブロック3204において、DTEIMエンジン120は、各IMノードに、当該IMノードによってサポートされているサービスのリストを取得するべく問い合わせを行う。ブロック3206において、DTEIMエンジン120は、複数のIMノードに対する並行したサブクエリを使用して、ユーザクエリを処理する。並行したユーザクエリの処理のさらなる詳細は、図39、40を参照して記載する。ブロック3208において、DTEIMエンジン120は、ノードを意識したnodeawareサービスオブジェクトスタブをDTEIMLDAPディレクトリサーバ内に作成して、サービストポロジを作成する。図35は、特定の実施形態による、ユーザによって開始された変更に関する各IMノード上のアイデンティティ情報の同期のためにDTEIMエンジン120によって実行される論理をフロー図で示す。制御は、ブロック3300にて始まり、ユーザが、DTEIMエンジン120内のアイデンティティ個人情報を見ることをリクエストする。ブロック3302において、DTEIMエンジン120は、メインのIMノードから個人情報を読み出す。ブロック3304において、ユーザは、個人属性において、追加/修正/削除/一時停止/回復の変更を加え例えば、情報を追加/修正/削除/一時停止/回復する、個人修正リクエストをDTEIMエンジン120に提出する。ブロック3306において、DTEIMエンジン120は、個人修正リクエストを、メインのIMノードにウェブサービスによって提出する。ブロック3306から、処理は、ブロック3308および3312の両方に進む。ブロック3308では、メインのIMノードが、IM-IMアダプタを使用して、個人修正を参加しているすべてのIMノードに送信する。ブロック3310において、個人修正を受信する各IMノードが、当該IMノードにある情報を更新する。さらに、個人変更を受信する各IMノードが、追加/削除/一時停止/回復リクエストをDTEIMエンジン120にルーティングする。ブロック3312では、メインのIMノード上のDTEIMノーティファイアモジュールが、個人追加/削除/一時停止/回復の通知パケットを作成し、ノードidを追加し、オブジェクトスタブをDTEIMエンジン120にウェブサービスによって送信する。ブロック3314において、DTEIMエンジン120は通知を受信する。ブロック3316において、DTEIMエンジン120は、ノードidを備える個人オブジェクトスタブの追加/削除/一時停止/回復を、DTEIMLDAPディレクトリサーバに対し行う。図36は、特定の実施形態による、アイデンティティフィードを介して開始された変更に関する各IMノード上のアイデンティティ情報の同期のためにDTEIMエンジン120によって実行される論理をフロー図で示す。制御は、ブロック3400にて始まり、ユーザ例えば、顧客が、メインのIMノードへのアイデンティティフィードを設定する。ブロック3402において、メインのIMノードは、このアイデンティティフィードに従い、個人追加/修正/削除/一時停止/回復の変更を複数加える。ブロック3402から、処理はブロック3404および3408の両方に続く。追加/削除/一時停止/回復リクエストは、DTEIMエンジン120および他のIMノード両方へルーティングされる。一方、属性修正は他のIMノードへルーティングされるが、これらの通知がDTEIMエンジン120に返される必要はない。ブロック3404では、メインのIMノードが、IM-IMアダプタを使用して、個人変更を参加しているすべてのIMノードに送信する。ブロック3406において、個人変更を受信する各IMノードが、当該IMノードにある情報を更新する。さらに、個人変更を受信する各IMノードが、追加/削除/一時停止/回復リクエストをDTEIMエンジン120にルーティングする。ブロック3408では、メインのIMノード上のDTEIMノーティファイアモジュールが、個人追加/削除/一時停止/回復のための通知パケットを作成し、ノードidを追加し、オブジェクトスタブをDTEIMエンジン120にウェブサービスによって送信する。ブロック3410において、DTEIMエンジンは通知を受信する。ブロック3412において、DTEIMエンジン120は、ノードidを備える個人オブジェクトスタブの追加/一時停止/回復/削除を、DTEIMLDAPディレクトリサーバに対し行う。図37、38は、特定の実施形態による、複数のIMノードからのIM情報を結合するようDTEIMエンジン120によって実行される論理をフロー図で示す。図37、38は1つの図を表す。制御は、ブロック3500にて図37始まり、ユーザが、DTEIMエンジン120へのログインをリクエストする。ブロック3502において、DTEIMエンジン120は、企業リポジトリに対してユーザ認証を行う。特定の実施形態では、ユーザがuseridおよびパスワードを提供し、これらが企業リポジトリに対する認証のために使用される。ブロック3504において、DTEIMエンジン120は、IMトポロジ上のユーザのフットプリントをDTEIMLDAPから得てオブジェクトスタブを調べてそのユーザがプロビジョニングされているIMノードを発見することによって、認証情報キャッシュを作成する。例えば、20のIMノードが存在し、ユーザが5つのIMノードに参加する場合、認証情報キャッシュは、その5つのIMノードのうちの任意のものと通信するために使用される認証情報を記憶するために使用され得る。ブロック3506において、DTEIMエンジン120は、ユーザのノードを意識したアカウントオブジェクトスタブを、DTEIMLDAPディレクトリサーバから読み出す。ブロック3506から図37、処理はブロック3508に続く図38。ブロック3508において、DTEIMエンジン120は、ユーザが、リクエストデータのクエリを行ったかどうかを判断する。そうであれば、処理はブロック3510に続き、そうでなければ、処理はブロック3512に続く。ブロック3510において、DTEIMエンジン120は、複数のIMノードに対する並行したサブクエリを使用して、クエリを処理する。並行したクエリの処理のさらなる詳細は、図39、40を参照して記載する。ブロック3510から、処理はブロック3512に続く。ブロック3512において、DTEIMエンジン120は、ユーザがtodoデータのクエリを行ったかどうかを判断する。そうであれば、処理はブロック3514に続き、そうでなければ、処理はブロック3516に続く。ブロック3514において、DTEIMエンジン120は、複数のIMノードに対する並行したサブクエリを使用して、クエリを処理する。並行したクエリの処理のさらなる詳細は、図39、40を参照して記載する。ブロック3514から、処理はブロック3516に続く。ブロック3516において、DTEIMエンジン120は、ユーザがクエリを行ったものであるとよい任意のリクエストおよびtodoデータと結合されたノードを意識したアカウントデータをユーザに返して、複数のIMノードからの結合された情報をユーザに提示する。したがって、ユーザがリクエストまたはtodoデータを要求していなければ、ユーザは、複数のIMノードからのアカウントデータを受信する。なお、ユーザがリクエストもしくはtodoデータまたはその両方を要求した場合、ユーザは、複数のIMノードからの、結合されたアカウントデータと、リクエストもしくはtodoデータまたはその両方とを受信する。DTEIMエンジン120は、既存のアイデンティティ管理情報を、このユーザが当該情報の提示以前にアクセスを許可されている複数のIMノードから取得し、結合した。図39、40は、特定の実施形態による、複数のIMノードに並行して情報に関するクエリを発行するようDTEIMエンジン120によって実行される論理をフロー図で示す。図39、40は1つの図を表す。制御はブロック3600にて始まり図39、DTEIMエンジン120が、ユーザのフットプリントを使用して、クエリを行うIMノードセットを構築し、クエリをサブクエリに分解し、サブクエリをIMノードセットの各IMノードに並行して発行する。特定の代わりの実施形態では、サブクエリは、各IMノードに送信される完全なクエリであってもよい。具体的には、各IMノード例えば、IMノード1、IMノード2、...IMノードNに関して、ブロック3620~3628図40の処理が並行して実行される。ブロック3620において、DTEIMエンジン120は、IMノードXXは任意のIMノード、1、2、...Nがアクティブであるかどうかを判断する。そうであれば、処理はブロック3624に続き、そうでなければ、処理はブロック3622に続く。ブロック3622において、DTEIMエンジン120は、IMノードXダウン結果を追加する。特定の実施形態では、ダウン結果は、IMノードはダウン/到達不可能エラーメッセージを示す。ブロック3622から、処理はブロック3608に続く図39。ブロック3624では、DTEIMエンジン120は、IMノードXの認証情報が、認証情報キャッシュにおいて入手可能かどうかを判断する。そうであれば、処理はブロック3628に続き、そうでなければ、処理はブロック3626に続く。ブロック3626において、DTEIMエンジン120は、IMノードX上の認証情報を認証し、認証情報を認証情報キャッシュに記憶する。ブロック3626から、処理はブロック3628に続く。ブロック3628において、DTEIMエンジン120は、サブクエリを非同期的にIMノードXに発行する。ブロック3628から図40、処理はブロック3608に続く図39。ブロック3608において、DTEIMエンジン120は、IMノードが応答するにつれて、サブクエリ結果を非同期的に結合する。ブロック3610において、DTEIMエンジン120は、結合されたノードを意識した結果セットを返す。図41は、特定の実施形態による、ユーザリクエストの処理のためにDTEIMエンジン120によって実行される論理をフロー図で示す。制御は、ブロック3700にて始まり、DTEIMエンジン120が、ユーザからプロビジョニングリクエストを受信する。プロビジョニングリクエストは、情報を変更するリクエストである例えば、アカウント追加/アカウント修正/パスワード変更/アカウント削除/アカウント一時停止/アカウント情報回復。ブロック3702において、DTEIMエンジン120は、プロビジョニングリクエストデータを、ノードを意識したDTEIMリクエストデータからIMノードid毎に分解する。特定の実施形態では、リクエストデータが、リクエストのコンテキストデータであり、DTEIMエンジン120が、IMノードアウェアネスを挿入する。ブロック3704において、DTEIMエンジン120は、ノードid毎のリクエストデータをノードマップにまとめる。ブロック3706において、DTEIMエンジンは、並行したサブリクエストを発行する。並行したリクエストの処理のさらなる詳細は、図42、43を参照して記載する。ブロック3708において、DTEIMエンジン120は、プロビジョニングリクエストステータス例えば、完了、失敗などをユーザに返す。図42、43は、特定の実施形態による、変更のリクエストを並行して発行するようDTEIMエンジン120によって実行される論理をフロー図で示す。図42、43は1つの図を表す。制御は、ブロック3800にて始まり、DTEIMエンジンが、リクエストノードマップを使用して、ターゲットとするIMノードセットを構築し、プロビジョニングリクエストをサブリクエストに分解し、サブリクエストをIMノードセットの各IMノードに発行する。特定の代わりの実施形態では、サブリクエストは、各IMノードに送信される完全なプロビジョニングリクエストであってもよい。具体的には、各IMノード例えば、IMノード1、IMノード2、...IMノードNに関して、ブロック3820~3828図43の処理は、並行して実行される。ブロック3820において、DTEIMエンジン120は、IMノードXXは任意のIMノード、1、2、...Nがアクティブであるかどうかを判断する。そうであれば、処理はブロック3824に続き、そうでなければ、処理はブロック3822に続く。ブロック3822において、DTEIMエンジン120は、サブリクエストをIMノードXに遅延提出するために、キューに入れる。ブロック3822から、処理はブロック3808に続き図42、サブリクエストの遅延ステータスを示す。ブロック3824では、DTEIMエンジン120は、IMノードXの認証情報が、認証情報キャッシュにおいて入手可能かどうかを判断する。そうであれば、処理はブロック3828に続き、そうでなければ、処理はブロック3826に続く。ブロック3826において、DTEIMエンジン120は、IMノードX上の認証情報を認証し、認証情報を認証情報キャッシュに記憶する。ブロック3826から、処理はブロック3828に続く。ブロック3828において、DTEIMエンジン120は、サブリクエストを非同期的にIMノードXに提出する。ブロック3828から図43、処理はブロック3808に続く図42。ブロック3808において、DTEIMエンジン120は、IMノードが応答するにつれて非同期的に、サブリクエストステータスを結合して、プロビジョニングリクエストステータスを形成する。ブロック3810において、DTEIMエンジン120は、結合されたノードを意識したステータスを返す。図44は、特定の実施形態による、IMノードに直接追加されたユーザアカウントに関してDTEIMエンジン120によって実行される論理をフロー図で示す。制御は、ブロック3900にて始まり、IMノードXが、個人Pに関して、新たなアカウントuseridUをサービスS上に追加する。ブロック3902において、IMノードX上のDTEIMノーティファイアモジュールは、オブジェクトスタブを作成し、ノードidを追加し、オブジェクトスタブをDTEIMエンジン120にウェブサービスによって送信する。ブロック3904において、DTEIMエンジン120は通知を受信する。ブロック3906において、DTEIMエンジン120は、個人Pに関して、ノードidXおよびサービスSを備えるオブジェクトスタブUをDTEIMLDAPディレクトリサーバに追加する。図45は、特定の実施形態による、IMノード上で直接行われたアカウント修正またはパスワード変更に関してDTEIMエンジン120によって実行される論理をフロー図で示す。制御は、ブロック4000にて始まり、IMノードXが、個人Pに関して、サービスS上のuseridUに関する既存のアカウントを修正するか、またはパスワードを変更する。ブロック4002において、DTEIMLDAPディレクトリサーバは既にアカウントスタブを有するため、IMノードX上のDTEIMノーティファイアモジュールは、通知をDTEIMエンジン120に送信しない。すなわち、特定の実施形態では、DTEIMLDAPディレクトリサーバは、アカウントパスワードを記憶しない。ブロック4004において、DTEIMエンジン120は、既存のアカウントの修正またはパスワードの変更に応答して、何の修正も加えない。図46は、特定の実施形態による、IMノード上のアカウント一時停止に関してDTEIMエンジン120によって実行される論理をフロー図で示す。制御は、ブロック4100にて始まり、IMノードXは、個人Pに関して、サービスS上のアカウントuseridUを一時停止する。ブロック4102において、IMノードX上のDTEIMノーティファイアモジュールは、オブジェクトスタブを一時停止するための修正パケットを作成し、ノードidを追加し、修正パケットをDTEIMエンジン120にウェブサービスによって送信する。ブロック4104において、DTEIMエンジン120は通知を受信する。ブロック4106において、DTEIMエンジン120は、オブジェクトスタブUを修正し、ステータスを一時停止中に変更する。図47は、特定の実施形態による、IMノード上のアカウント回復に関してDTEIMエンジン120によって実行される論理をフロー図で示す。制御は、ブロック4200にて始まり、IMノードXが、個人Pに関して、サービスS上のアカウントuseridUを回復する。ブロック4202において、IMノードX上のDTEIMノーティファイアモジュールは、オブジェクトスタブを回復するための修正パケットを作成し、ノードidを追加し、修正パケットをDTEIMエンジン120にウェブサービスによって送信する。ブロック4204において、DTEIMエンジン120は通知を受信する。ブロック4206において、DTEIMエンジン120は、オブジェクトスタブUを修正し、ステータスを回復済みに変更する。図48は、特定の実施形態による、IMノード上のアカウント削除に関してDTEIMエンジン120によって実行される論理をフロー図で示す。制御は、ブロック4300にて始まり、IMノードXが、個人Pに関して、サービスS上のアカウントuseridUを削除する。ブロック4302において、IMノードX上のDTEIMノーティファイアモジュールは、オブジェクトスタブを削除するための修正パケットを作成し、ノードidを追加し、修正パケットをDTEIMエンジン120にウェブサービスによって送信する。ブロック4304において、DTEIMエンジン120は通知を受信する。ブロック4306において、DTEIMエンジン120は、オブジェクトスタブUを削除済みとしてマークする。したがって、DTEIMアーキテクチャは、非常に大きなアイデンティティ管理実装に使用され得る。DTEIMアーキテクチャは、アイデンティティ管理を分散型のトポロジで展開することによって、アイデンティティ管理を徐々に拡張可能にする。DTEIMアーキテクチャは、IMインフラストラクチャの時間差メンテナンスを可能にすることによって可用性を高め、パフォーマンスを改善し、IMの異種バージョンをサポートし、アドミニストレーションを分散化する。分散化モデルは、管理可能性および作業負荷の分散を改善する。DTEIMアーキテクチャは、システムアイデンティティを、分散型IMノードを使用して追跡する。各IMノードは、他のIMノードと協働して、拡張可能/分散型の様式でネットワークアーキテクチャに対する設定を行うことを可能にする。DTEIMアーキテクチャは、局所的なアドミニストレーションならびに集中したアイデンティティおよびアカウント運用を可能にする。DTEIMアーキテクチャは、集団例えば、孤立したラボのサブセットにそれ1つのためのプロビジョニングを提供できる。DTEIMアーキテクチャを用いると、より多くのサービスが展開されるにつれてより多くのIMノードが追加されることもできる。個々のIMが、サービスおよび調整の、それ自体のサブセットを処理するため、パフォーマンスボトルネックが回避される。追加の実施形態の詳細当業者であれば当然のことであるが、本発明の側面は、システム、方法またはコンピュータプログラム製品として具現化され得る。したがって、本発明の側面は、完全にハードウェアの実施形態、完全にソフトウェアの実施形態ファームウェア、常駐ソフトウェア、マイクロコードなどを含む、または本願明細書においてすべて概して回路、モジュールもしくはシステムと呼ばれ得る、ソフトウェアおよびハードウェアの側面を兼ね備えた実施形態の形態をとってもよい。さらに、本発明の側面は、コンピュータ可読プログラムコードが具現化された1つ以上のコンピュータ可読媒体単数または複数において具現化されたコンピュータプログラム製品の形態をとることもできる。1つ以上のコンピュータ可読媒体単数または複数の任意の組み合わせが利用され得る。コンピュータ可読媒体は、コンピュータ可読信号媒体またはコンピュータ可読ストレージ媒体とされ得る。コンピュータ可読ストレージ媒体は、例えば、限定はされないが、電子、磁気、光学、電磁気、赤外線、もしくは半導体システム、装置、もしくはデバイス、または前述のものの任意の適切な組み合わせとすることもできる。コンピュータ可読ストレージ媒体のより具体的な例包括的でないリストには、1つ以上のワイヤを有する電気的接続、ポータブルコンピュータディスケット、ハードディスク、ランダムアクセスメモリRAM:randomaccessmemory、読み取り専用メモリROM:read-onlymemory、消去可能プログラム可能読み取り専用メモリEPROMerasableprogrammableread-onlymemoryまたはフラッシュメモリ、光ファイバ、ポータブルコンパクトディスク読み取り専用メモリCD-ROM:compactdiscread-onlymemory、光学式ストレージデバイス、磁気ストレージデバイス、ソリッドステートメモリ、磁気テープ、または前述のものの任意の適切な組み合わせが含まれるであろう。この文書の文脈では、コンピュータ可読ストレージ媒体は、命令実行システム、装置もしくはデバイスによって、またはそれに関連して使用されるプログラムを含むこと、または記憶することができる任意の有形の媒体であればよい。コンピュータ可読信号媒体は、例えば、ベースバンドに、または搬送波の一部として、コンピュータ可読プログラムコードが具現化された伝播データ信号を含み得る。そのような伝播信号は、電磁気、光学、またはその任意の適切な組み合わせを含むがこれらに限定はされない、様々な形態のいずれかをとってよい。コンピュータ可読信号媒体は、コンピュータ可読ストレージ媒体でなく、命令実行システム、装置もしくはデバイスによって、またはそれに関連して使用されるプログラムを伝達すること、伝播させること、または搬送することができる、任意のコンピュータ可読媒体としてよい。コンピュータ可読媒体上に具現化されたプログラムコードは、無線、有線、光ファイバケーブル、RFなど、または前述のものの任意の適切な組み合わせを含むがこれらに限定はされない、任意の適切な媒体を使用して送られてもよい。本発明の側面の動作を実行するコンピュータプログラムコードは、JavaR、SmalltalkR、Cまたは同様のものなどのオブジェクト指向プログラミング言語、およびCプログラミング言語もしくは同様のプログラミング言語などの従来の手続きプログラミング言語を含む、1つ以上のプログラミング言語の任意の組み合わせで書かれていてよい。プログラムコードは、スタンドアロンソフトウェアパッケージとして、完全にユーザのコンピュータ上で実行されること、部分的にユーザのコンピュータ上で実行されること、または部分的にユーザのコンピュータ上で、かつ部分的にリモートコンピュータ上で実行されること、または完全にリモートコンピュータもしくはサーバ上で実行されることもできる。後者のシナリオでは、ローカルエリアネットワークLAN:localareanetwork、もしくは広域ネットワークWAN:wideareanetworkを含む任意のタイプのネットワークを介してリモートコンピュータがユーザのコンピュータに接続されてもよく、または、外部コンピュータに接続されてもよい例えば、インターネットサービスプロバイダを使用しインターネットを介して。本発明の実施形態の側面について、本発明の実施形態による方法、装置システムおよびコンピュータプログラム製品のフローチャート図もしくはブロック図またはその両方を参照して以下に記載する。当然のことながら、フローチャート図もしくはブロック図またはその両方の各ブロック、およびフローチャート図もしくはブロック図またはその両方の複数ブロックの組み合わせは、コンピュータプログラム命令により実装可能である。当該コンピュータプログラム命令が、マシーンを生じるよう、汎用コンピュータ、専用コンピュータ、またはその他のプログラム可能データ処理装置のプロセッサに提供されて、この命令が、コンピュータまたはその他のプログラム可能データ処理装置のプロセッサを用いて実行されて、フローチャートもしくはブロック図またはその両方のブロックもしくは複数ブロックにおいて指定された機能/動作を実装する手段を作り出すようにすることもできる。さらに、特定の形で機能するようコンピュータ、その他のプログラム可能データ処理装置、またはその他のデバイスに指示することができる当該コンピュータプログラム命令は、コンピュータ可読媒体に記憶されて、コンピュータ可読媒体に記憶されたこの命令が、フローチャートもしくはブロック図またはその両方のブロックもしくは複数ブロックにおいて指定された機能/動作を実装する命令を含む製品を生じるようにすることもできる。さらに、コンピュータプログラム命令は、コンピュータ、その他のプログラム可能データ処理装置、またはその他のデバイスにロードされて、コンピュータ、その他のプログラム可能装置、またはその他のデバイス上で一連の動作処理例えば動作またはステップが実行されるようにしてコンピュータに実装されるプロセスを生じさせ、コンピュータまたはその他のプログラム可能装置上で実行される命令が、フローチャートもしくはブロック図またはその両方のブロックもしくは複数ブロックにおいて指定された機能/動作を実装するためのプロセスを提供するようにすることもできる。記載された動作を実装するコードはさらに、ハードウェア論理または回路例えば集積回路チップ、プログラマブルゲートアレイPGA:ProgrammableGateArray、特定用途向け集積回路ASIC:ApplicationSpecificIntegratedCircuitなどにおいて実装され得る。ハードウェア論理は、動作を実行するようプロセッサに連結されてもよい。DTEIMエンジン120は、ハードウェア例えば、ハードウェア論理もしくは回路、ソフトウェア、またはハードウェアとソフトウェアとの組み合わせとして実装されてよい。図49は、特定の実施形態により使用され得るコンピュータアーキテクチャ4400を示す。DTEIMサーバもしくはIMノードまたはその両方は、コンピュータアーキテクチャ4400を実装してもよい。コンピュータアーキテクチャ4400は、プログラムコードの記憶もしくは実行またはその両方に適しており、システムバス4420を介してメモリ要素4404に直接または間接的に連結された少なくとも1つのプロセッサ4402を含む。メモリ要素4404は、プログラムコードを実際に実行する間に用いられるローカルメモリ、大容量ストレージ、および、実行中にコードが大容量ストレージから読み出されなければならない回数を減らすために少なくとも一部のプログラムコードの一時的なストレージとなるキャッシュメモリを含み得る。メモリ要素4404は、オペレーティングシステム4405および1つ以上のコンピュータプログラム4406を含む。入出力I/O:input/outputデバイス4412、4414限定はされないが、キーボード、ディスプレイ、ポインティングデバイスなどを含むは、直接、または介在するI/Oコントローラ4410を介して、システムに連結され得る。ネットワークアダプタ4408もシステムに連結されて、データ処理システムが、他のデータ処理システムまたはリモートプリンタまたはストレージデバイスに、介在するプライベートまたはパブリックネットワークを介して連結された状態となることを可能にしてもよい。モデム、ケーブルモデム、およびイーサネットカードが、現在利用可能なタイプのネットワークアダプタ4408のごく一部である。コンピュータアーキテクチャ4400は、ストレージ4416例えば、磁気ディスクドライブ、光ディスクドライブ、テープドライブなどの不揮発性ストレージエリアに連結されてもよい。ストレージ4416は、内部ストレージデバイス、または接続されたストレージもしくはネットワークアクセス可能ストレージを含んでもよい。ストレージ4416内のコンピュータプログラム4406が、メモリ要素4404にロードされて、プロセッサ4402によって、当技術分野で既知の方法で実行されてもよい。コンピュータアーキテクチャ4400は、示されているよりも少ないコンポーネントを含んでも、本願明細書に示されていない追加のコンポーネントを含んでも、または示されたコンポーネントおよび追加のコンポーネントの何らかの組み合わせを含んでもよい。コンピュータアーキテクチャ4400は、メインフレーム、サーバ、パーソナルコンピュータ、ワークステーション、ラップトップ、ハンドヘルドコンピュータ、電話デバイス、ネットワークアプライアンス、仮想化デバイス、ストレージコントローラなど、当技術分野で既知の任意のコンピューティングデバイスを含み得る。各図面のフローチャートおよびブロック図は、本発明の様々な実施形態によるシステム、方法およびコンピュータプログラム製品の考えられる実装のアーキテクチャ、機能性および動作を示す。この関連で、フローチャートまたはブロック図内の各ブロックは、指定の論理機能単数または複数を実装する1つ以上の実行可能命令を含むモジュール、セグメント、またはコードの一部を表現することもできる。なお、さらに、いくつかの代わりの実装では、ブロック内に示されている機能が、図面に示されているのとは異なる順序で生じてもよい。例えば、関連する機能性次第で、連続して示されている2つのブロックが実際には事実上同時に実行されてもよく、または、各ブロックが逆順で実行されることがあってもよい。なお、さらに、ブロック図もしくはフローチャート図またはその両方の各ブロック、およびブロック図もしくはフローチャート図またはその両方の複数ブロックの組み合わせは、指定の機能もしくは動作を実行する専用ハードウェアベースシステム、または専用ハードウェアおよびコンピュータ命令の組み合わせにより実装することができる。本願明細書で使用される専門用語は、特定の実施形態を説明するためのものでしかなく、本発明の限定となることは目的としていない。本願明細書で使用される、単数形a、anおよびtheは、文脈によりそうでないことが明確に示されていない限り、複数形も含むものとする。さらに、当然のことながら、含むもしくは含んでいるまたはその両方の用語は、本明細書で使用されるとき、記載された機能、完全体、ステップ、動作、構成要素、もしくはコンポーネント、またはそのいずれかの組み合わせの存在を指定するが、1つ以上の他の機能、完全体、ステップ、動作、構成要素、コンポーネント、もしくはそのグループ、またはそのいずれかの組み合わせの存在または追加を除外するものではない。以下の特許請求の範囲のミーンズまたはステッププラスファンクション構成要素すべての対応する構造、材料、動作、および等価物は、明確に請求されている他の請求される構成要素とともに機能を実行する任意の構造、材料、または動作を含むものとする。本発明の実施形態の記載は、例証および説明のために提示されたものであるが、包括的であることも、開示された形態の発明に限定されることも目的としていない。当業者には、本発明の範囲および意図から逸脱することのない、多数の変更および変形が明らかであろう。実施形態は、本発明の原理および実際の応用を最もよく説明して、当業者が、意図される特定の用途に適する様々な変更を用いた様々な実施形態に関して、本発明を理解できるように選ばれ、記載された。本発明の実施形態の前述の説明は、例証および説明のために提示された。包括的であること、または開示された厳密な形に実施形態を限定することを目的としたものではない。上記の教示を踏まえ、多数の変更および変形が可能である。実施形態の範囲は、この詳細な説明ではなく、本願明細書に添付されている特許請求の範囲によって定められるものとする。上記の明細事項、例、およびデータは、実施形態の構成の製造および使用の、全面的な説明を提供する。多数の実施形態が、本発明の意図および範囲から逸脱することなく構成され得るため、その実施形態は、以下に添付された特許請求の範囲または後に提出される任意の特許請求の範囲、およびその等価物に属する。"