ネットワーク景観において複数の互いに接続されたエンティティを発見するステップと、前記エンティティのサブセットを自動的に集約してビジネス参加者にし、前記集約することは、少なくとも1つの規則ベースのアルゴリズムに従って実行されるステップと、前記ビジネス参加者を含むビジネスプロセス景観を生成するステップとを備えるコンピュータによって実施される方法。前記エンティティの少なくともいくつかは、ビジネスアプリケーション、ビジネスシステム、ファイルシステム、データベース管理システム、または企業リソース計画システムの少なくとも1つに関連する請求項1に記載の方法。前記発見するステップは、着信呼構成情報および発信呼構成情報を分析するステップを備える請求項1に記載の方法。前記発見するステップは、運用者から受け取られた情報に少なくとも部分的に基づく請求項3に記載の方法。前記集約するステップは、合致分析、類似性分析、または関係分析に少なくとも部分的に基づく請求項1に記載の方法。前記集約するステップは、運用者から受け取られた情報に少なくとも部分的に基づく請求項5に記載の方法。前記アルゴリズムは、ヒューリスティクアルゴリズムを備える請求項1に記載の方法。前記アルゴリズムは、アプリケーションシステム概要、製品バージョン、接続情報、ミドルウェアシステム上、またはアプリケーションシステム上で実行されている統合、インタフェース、統合プロセスモデル、運用データ、ビジネスプロセス記述、ビジネス役割およびビジネス参加者、ビジネス対話、またはビジネス協力に少なくとも部分的に基づく請求項1に記載の方法。前記発見するステップおよび前記集約するステップは、実質的にリアルタイムで実行される請求項1に記載の方法。前記発見するステップおよび前記集約するステップは、実質的に連続的なプロセスを備える請求項1に記載の方法。前記発見するステップおよび前記集約するステップの少なくともいずれかは、アプリケーションプログラミングインタフェースを介して入手可能なメタモデルおよび運用データを表すソースモデルに基づく請求項1に記載の方法。前記アプリケーションプログラミングインタフェースは、アプリケーションシステムまたは統合バスの少なくともいずれかに関連する請求項11に記載の方法。互いに接続されたシステムの景観において複数の一意のホストおよびシステムを識別するステップと、ソースモデルに基づいて、各システムに向かう着信呼、および各システムからの発信呼を特定するステップと、発信呼に基づいて、各システムからのメッセージフローを特定するステップと、着信呼に基づいて、各システムに向かうメッセージフローを特定するステップと、前記システムに関する呼グラフをマージして、前記景観のビジネスプロセスネットワークを作成するステップと、前記ビジネスプロセスネットワークに関するメッセージフロー、アプリケーションコンテンツ、および統合コンテンツを結び付けるステップとを備える方法を実行するようにコンピュータによって実行可能なプログラムコードを格納している一時的でないコンピュータ可読媒体。前記識別するステップは、ソースモデルに関連する請求項13に記載の媒体。着信呼を前記特定するステップは、着信呼構成情報に少なくとも部分的に基づく請求項13に記載の媒体。ネットワーク景観において複数の互いに接続されたエンティティを発見するネットワークサービス層プラットフォームと、前記エンティティのサブセットを自動的に集約してビジネス参加者にし、前記集約することは、少なくとも1つの規則ベースのアルゴリズムに従って実行されるネットワーク集約層プラットフォームとを備えるネットワーク管理サーバ。ネットワークソース層プラットフォームは、探査分析サービス、統合モデル展開サービス、ソース読み取りエージェント、ソース書き込みエージェント、またはソースモデルの少なくとも1つをさらに含む請求項16に記載のネットワーク管理サーバ。前記ネットワーク集約層プラットフォームは、集約されるネットワークモデル、またはコンソリデータの少なくともいずれかをさらに含む請求項16に記載のネットワーク管理サーバ。前記ビジネス参加者を含むビジネスプロセス景観を表示するグラフィカルユーザインタフェースを提供するネットワーク統合モデル層プラットフォームをさらに備える請求項16に記載のネットワーク管理サーバ。前記ネットワーク統合モデル層プラットフォームは、運用リンカ、シミュレータおよびオプティマイザ、または富化統合モデル構成要素の少なくとも1つを含む請求項19に記載のネットワーク管理サーバ。統合開発を円滑にするのを助けるのに、ネットワークは、ミドルウェアアプリケーションを介するシステムおよびアプリケーションの間の統合とともに、顧客の景観landscapeにおけるシステムおよびアプリケーションを記述することによって計画策定されることが可能である。しかし、そのようなネットワーク計画図またはネットワーク景観を作成することは、時間がかかり、誤りが生じやすいプロセスであり得る。例えば、統合ミドルウェアアプリケーションは、技術の見地とビジネスの見地の両方から、その景観の正確な眺望をもたらさない可能性がある。そのような眺望は、そのネットワークを運用する際に役立つだけでなく、そのネットワークの将来の変更およびまたは拡張を実施するのに必要とされる可能性もある。したがって、ビジネスプロセス景観を自動的に、効率的に決定するための方法および機構が、本明細書で説明されるいくつかの実施形態に従って与えられることが可能である。企業内の統合開発は、既存のアプリケーション、システム、およびまたはインタフェースを理解して、一貫性のある仕方でそれらのアプリケーション、システム、およびまたはインタフェースの間の通信を円滑にすることを要求する可能性がある。例えば、統合ミドルウェアアプリケーションは、A2A統合、B2B統合、およびまたはEDI通信を可能にすることができる。これらのミドルウェアアプリケーションは、アプリケーションに、SOA原理およびEDA原理を実施させることが可能であり、さらに企業内の様々なアプリケーションにまたがるビジネスプロセスを調整するのを助けることが可能である。一部の顧客景観において、そのようなタスクを実行している複数のソフトウェアインスタンスが存在する可能性もある。これらのソフトウェアインスタンスは、例えば、中央ハブとして展開されること、またはアプリケーションシステム内に埋め込まれることも可能である。統合開発を円滑にするのを助けるのに、ネットワークは、ミドルウェアアプリケーションを介するシステムおよびアプリケーションの間の統合とともに、顧客の景観におけるシステムおよびアプリケーションを記述することによって計画策定されることが可能である。例えば、図1は、一部の実施形態によるビジネスネットワーク管理景観100のブロック図である。景観100は、いくつかの互いに接続されたシステム110を含む。システム110は、例えば、互いに通信するビジネスアプリケーションおよびまたはサーバを備えることが可能である。システム110のサブセット120、130、140は、ビジネスの点で一緒にグループ化されることが可能であることに留意されたい。例えば、1つのサブセット120が、本部ビジネスプロセスに関連する一方で、別のサブセット130が、流通センタプロセスに関連する。しかし、そのようなネットワーク計画図またはネットワーク景観100を作成することは、時間がかかり、誤りが生じやすいプロセスであり得る。例えば、統合ミドルウェアアプリケーションは、技術の見地とビジネスの見地の両方から、その景観の正確な眺望をもたらさない可能性がある。そのような眺望は、そのネットワークを運用する際に役立つだけでなく、そのネットワークの将来の変更およびまたは拡張を実施するのに必要とされる可能性もある。一部の実施形態によれば、統合ネットワークについての情報が、様々なタイプの既存の生産的システムから求められ、企業の日々のビジネスプロセスに対して最新であるネットワークの眺望が、実質的にリアルタイムで構築されることが可能である。統合ネットワークは、例えば、物理的ハードウェアシステム上で実行されているビジネスアプリケーションを介して互いに対話しているビジネス参加者のネットワークと定義されることが可能である。例えば、図2は、一部の実施形態による、3名のビジネス参加者220、230、240を含むビジネスネットワーク管理景観200を示す。一部の実施形態によれば、そのような統合ネットワークは、既存のアプリケーションおよびまたはミドルウェアシステムにおいて入手可能な情報に基づいて、顧客景観に関して自動的に構築されることが可能である。この情報は、例えば、アプリケーションシステム概観、製品バージョン、接続情報、ミドルウェアシステム上、またはアプリケーションシステム上で実行されている統合、インタフェース、統合プロセスモデル、運用データ、ビジネスプロセス記述、ビジネス役割およびビジネス参加者、ビジネス対話、およびまたはビジネス協力のうちいくつか、またはすべてを含むことが可能である。実施形態は、情報の以上の例に限定されないことに留意されたい。さらに、一部の実施形態において、いくらかの運用者介入が許されることが可能である。つまり、ネットワーク景観は、運用者が情報のいくらかを供給する場合でさえ、自動的に決定されることが可能である。同一の情報が複数の表現を有する場合、アプリケーションおよびシステムの多様性が要因である可能性があることに留意されたい。例えば、或るシステムについての情報が、アプリケーションおよびミドルウェアシステムにおいて1つの表現を有することが可能であり、IT動作に関して別の表現を有することが可能であり、さらにプロセスモデリングに関する参加者としてさらに別の表現を有することが可能である。さらに、様々なツールが、ネットワーク景観を構築するのに使用されることが可能なメタ情報を供給することが可能であることに留意されたい。例えば、システム管理ツール、IT運用ツール、監視IT運用ツール、根本原因分析事象管理ツールがそれぞれ、監視データおよび運用データを収集して、管理者にシステムを解決させ、運用させることが可能である。これらのツールは、ランタイムエージェントを介して、メタデータおよび運用データを読み取る、または特定のアプリケーションまたはシステムを監視するいくらかの限定された発見様の能力を有することが可能である。また、統合ミドルウェアが、コンテンツ開発およびコンテンツ運用のための設計ツールおよび管理ツールを有することも可能である。これらのツールは、メタデータを作成すること、およびまたは既存の情報のいくらかの発見を円滑にすることも可能である。本明細書で与えられる一部の実施形態は、発見プロセス中にソースデータを、様々なソースシステムとは独立に、共通の表現にする。次に、規則ベースのアルゴリズムのセットが、集約プロセスにおいて実行されて、この情報の間の類似性および関係が識別されることが可能である。これらのプロセスは、一部の実施形態により、実質的にリアルタイムで実行されることが可能である。任意の所与の時点で、統合ネットワークは、情報ソースの或る特定の状態のスナップショットを表すことが可能であるものの、発見プロセスおよび集約プロセスは、時とともに継続的に実行されることが可能である。ビジネスネットワーク管理の目標は、統合開発の端から端までのライフサイクルを容易化すること、およびより高速な実行のために異なる情報上の協力を許すことを含む。したがって、有用なネットワーク景観は、アプリケーションおよび統合バス企業サービスバスを有する顧客景観の一般化された眺望を反映することが可能である。さらに、このネットワークの眺望は、ネットワークの可視性および透明性を確実にするように自動的に構築されるとともに、現実の生産システムに合わせてライブ更新される必要がある可能性がある。ネットワークを発見するプロセスは、集約される情報モデルおよびソース情報モデル、ならびに情報の分析を使用してシステム景観を探査して、情報内の類似性および関係を見出すことができる。ネットワークの探査は、統合技術が、アプリケーション間の仲介役をすると、統合技術から始まることが可能である。プロキシおよび接続を有するアプリケーションの場合、情報は、接続およびインタフェースの詳細、およびまたは運用データを含むことが可能である。プロキシ、接続、および仲介を有するアプリケーションの場合、情報は、接続およびインタフェースの詳細、マッピング、ルーティング、およびまたは運用データを含むことが可能である。スタンドアロンの企業サービスバスまたは統合サーバの場合、情報は、接続およびインタフェースの詳細、マッピング、ルーティング、システム中心プロセス、およびまたは運用データを含むことが可能である。スタンドアロンの企業サービスバスまたは統合サーバに接続されたアプリケーションの場合、情報は、接続データおよびまたは運用データを含むことが可能である。B2Bゲートウェイの場合、情報は、接続およびインタフェースの詳細、マッピング、ルーティング、システム中心プロセス、およびまたは運用データを含むことが可能である。会社のビジネスパートナにおいて実行されるB2Bゲートウェイに接続されたアプリケーションの場合、情報は、接続データおよびまたは運用データを含むことが可能である。情報は、ネットワーク景観を決定するように分析されることが可能である。例えば、図3は、一部の実施形態によるネットワーク320を探査することが可能なネットワーク管理サーバ310を含むシステム300のブロック図である。ネットワーク管理サーバ310は、ネットワーク320における様々なシステムから情報を受信することが可能である。例えば、ネットワーク管理サーバ310は、HTTP通信、または他の任意のタイプのデータ交換を介して、遠隔システムから入力レコードをインポートすることが可能である。ネットワーク320におけるネットワーク管理サーバ310およびまたはシステムは、例えば、PC、サーバ、およびまたは移動デバイスに関連することが可能である。図3は、一部の実施形態による論理アーキテクチャを表し、実際の実施例は、他の仕方で構成されたさらなる構成要素、または異なる構成要素を含むことも可能であることに留意されたい。さらに、本明細書で説明される各システムは、任意の数の他の公共ネットワークおよびまたはプライベートネットワークを介して通信状態にある任意の数のデバイスによって実施されることが可能である。デバイスの2つ以上が、互いに遠隔に配置されることが可能であり、さらに任意の知られている様態のネットワークおよびまたは専用接続を介して、互いに通信することが可能である。さらに、各デバイスは、本明細書で説明される機能、および他の任意の機能を提供するのに適した任意の数のハードウェア要素およびまたはソフトウェア要素を備えることが可能である。他のトポロジが、他の実施形態と併せて使用されることも可能である。本明細書で説明されるすべてのシステムおよびプロセスは、1つまたは複数のコンピュータ可読媒体上に格納されたプログラムコードとして実現されることが可能である。そのような媒体は、例えば、フロッピー登録商標ディスク、CDROM、DVDROM、Zipディスク、磁気テープ、およびソリッドステートRAMストレージユニットまたはソリッドステートROMストレージユニットを含むことが可能である。したがって、実施形態は、ハードウェアおよびソフトウェアのいずれの特定の組合せにも限定されない。ネットワーク管理サーバ310におけるネットワークソース層330は、ネットワーク320におけるシステムと通信し、ソースモデルストレージ、ソース読み取りエージェント、ソース書き込みエージェント、探査分析サービス、およびまたは統合モデル展開サービスを提供することが可能である。ネットワークソース層330は、アプリケーションシステムおよび統合バスの公開APIを介してアクセス可能なメタモデルおよび運用データを表すことが可能である。ソースモデルは、システムの特定のカテゴリを可能な限り正確に記述することが可能であり、さらに対応するシステムに再び書き込むためのデータモデルであることも可能である。ソースモデルは、一部の態様によれば、ビジネスネットワーク管理の使用事例に関係のある情報のセットだけを記述し、さらに特定のシステムの完全なモデル概観は提供しない可能性がある。ソースモデルは、例えば、特定のシステムタイプ、および特定のシステムカテゴリに関して開発されたエクストラクタを使用する探査プロセスを介して、作成されることも可能である。また、ネットワークソース層330は、新たなソースモデルをつなぐ拡張ポイントを提供することも可能である。特定のシステムタイプ、および特定のシステムカテゴリに関して、ソースモデルは、特定のシステムの全包括的な眺望をもたらす一次データソースおよび二次データソースと呼ばれる複数のデータソースからの情報を要求する可能性がある。探査プロセスは、特定のシステム、および特定のカテゴリに関する一次データソースを抽出することが可能であり、さらに適宜、ソースモデルを埋めるように二次データソースを収集することも可能である。二次データソースは、例えば、ログ、監視データ、設計時メタデータなどを含むことが可能である。ネットワークの眺望を構築するために、ネットワークに参加している一意の物理的システムのリストが保持される必要もある可能性があり、さらにシステム自体、およびシステム上で実行されているソフトウェアバージョンが、ソースモデルを形成する。ソースモデルは、より高速なアクセスを許し、さらにシステムに対する繰り返しの呼び戻しを回避するように永続させられることが可能である。ネットワーク管理サーバ310におけるネットワーク集約層340が、集約するネットワークモデルストレージおよびまたは集約されるネットワークモデルストレージを含むことが可能である。ネットワーク集約層340は、ネットワークの全体的な物理的一眺望を表すことが可能である。探査の後、情報の分析が、互いに統合されるシステム上に展開されたアプリケーションおよび統合バスを有するネットワークの実際の眺望を構築する合致、類似性、および関係を見出すように実行されることが可能である。分析の理由は、例えば、ネットワークの自動的で、正確な眺望に変換されない可能性がある、ソースモデルの冗長性および矛盾のためであることが可能である。分析の目的は、システム間の統合フローを識別することであることが可能であり、したがって、全包括的なネットワーク眺望を作成することであることが可能である。例えば、ネットワーク内の或る特定のシステムに通信しているシステムのセットが、異なる名前、および異なる識別子を介して接続の詳細を保持する可能性がある。そのような情報の分析は、ネットワーク内の他のシステムからその特定のシステムに至る一意の統合フローのリストをもたらすことが可能である。集約されるネットワークモデルは、ソースモデルの分析に基づくアルゴリズムによって作成されることが可能である。これらのアルゴリズムは、複数のソースモデルにわたって類似性検出および関係特定を実行することができ、さらにパターンマッチングおよびパターン認識のオントロジ、分類法、および概念に基づくセマンティクスに依拠することができる。一部の事例において、さらなるデータが、分析プロセスのために追加される必要がある可能性がある。ネットワーク管理サーバ310におけるネットワーク統合モデル層350が、富化統合モデル構成要素、運用リンカ、およびまたはシミュレータおよびオプティマイザを含むことが可能である。ネットワーク統合モデル層350は、例えば、ビジネス景観にアクセスする、さらにまたはビジネス景観を調整するのに使用されることが可能なGUIを提供することが可能である。ネットワーク集約層340を再び参照して、ソースモデルと呼ばれる、ネットワーク上で発見可能である情報のセットは、アプリケーションおよびまたは統合システムに基づくことが可能であることに留意されたい。アプリケーションに関するソースモデルは、顧客景観における生産的企業アプリケーションを表すことが可能であり、さらにハードウェアシステム、およびアプリケーションのバージョンについての情報を含むことが可能である。また、アプリケーションが、プロキシ、インタフェース、イベント、タイプ、構成、およびまたは運用データのような統合関連のアプリケーションメタデータを含むことも可能である。やはり発見されることが可能な、さらなるメタデータデータは、統合の参加者の役割をしている企業アプリケーションに関して、データモデル、統合モデル、通信プロトコル、統合要件、およびまたは運用データを含む。プロセスの参加者の役割をしている企業アプリケーションに関して、発見されることが可能な、さらなるメタデータデータは、データモデル、基準データ、アプリケーションロジックおよびアプリケーション条件、状態遷移情報、ワークフロー、およびまたは運用データを含む。統合のためのソースモデルは、統合バスシステム自体を表すことが可能である。そのようなソースモデルは、メッセージンググリッドおよび統合パイプラインデータを含むハードウェアシステムについての詳細を含むことが可能である。統合バス自体、インタフェース、イベント、およびタイプ、ならびにマッピングおよびルーティングを含む統合モデル、通信プロトコル、統合要件、監視ログやアラートなどの運用データ、システム中心モデル、およびまたは統合コンテンツのバージョンを含むことが可能であることに留意されたい。図4は、一部の実施形態によるビジネスネットワーク管理プロセス400の流れ図である。本明細書で説明されるすべてのプロセスは、ハードウェアおよびまたはソフトウェアの任意の組合せによって実行されることが可能であることに留意されたい。これらのプロセスは、実体のある媒体上に格納され、さらに本明細書で説明される機能をもたらすようにコンピュータによって実行可能であるプログラムコードとして実現されることが可能である。さらに、本明細書で説明される流れ図は、それらのステップの固定の順序を暗示することはなく、本発明の実施形態は、実施可能である任意の順序で実施され得ることに留意されたい。S402で、ネットワーク景観における複数の互いに接続されたエンティティが発見される。例えば、複数のシステムが、本明細書で説明される実施形態のいずれに従って発見されることも可能である。S404で、これらのエンティティのサブセットが集約されてビジネス参加者になり、集約することは、少なくとも1つの規則ベースのアルゴリズムに従って実行される。一部の実施形態によれば、このビジネス参加者を含むビジネスプロセス景観が生成されることが可能である。一部の実施形態によれば、エンティティのサブセットを集約してビジネス参加者にすることは、1つまたは複数のビジネス事実に基づいて実行される。本明細書で説明される事実という用語は、例えば、統合アルゴリズムに関係があることが可能な属性の重要なセットを指すことが可能である。一部の実施形態によれば、事実は、ソースからの関係のある特性に基づいて識別されることが可能である。事実は、運用者によって特定された、または明確に指定された機械であることも可能であることに留意されたい。例として、事実は、アプリケーションのシステムインスタンス名を表すことも可能であり、さらに運用者が、別々の情報ソースにおいて保持される異なる論理システムインスタンス名が実際には、アプリケーションの同一のシステムインスタンスを指すことを識別することも可能である。S404で実行される集約は、1つまたは複数の情報モデルの知識に基づいて、規則の特定のセットを適用することが可能である。これらの規則は、統合ネットワークまたは統合景観を作成するように事実に適用されることが可能である。一部の実施形態によれば、これらの規則は、特定の情報ソースに関するアルゴリズムによって定義され、さらにまたは運用者によって供給されることも可能である。アルゴリズムは、発見および集約のために各情報ソースに関するエージェントの概念を有して設計されることが可能である。エージェントは、複数の情報ソースにわたって共有されることも、共有されないことも可能であり、さらに統合ネットワークの生成を円滑にすることが可能である。また、アルゴリズムは、元の情報ソースに対するリファレンスを保持して、元の情報ソースを使用した掘り下げ、検証、訂正、表示、およびまたは他の任意のタスクを許すことも可能である。また、アルゴリズムは、アプリケーションに向かう着信通信、アプリケーションからネットワーク内の外部パートナに向かう発信通信、およびまたはビジネスアプリケーションに直接にリンクされていない物理リソースに向かう着信通信などの、統合ネットワークにおけるダングリングリファレンスを扱うようにヒューリスティクスを適用することも可能である。一部の実施形態によれば、アルゴリズムは、フォールトトレラントであることが可能であり、さらにまたは発見ステップ中、および集約プロセス中の誤り処理のために様々なセマンティクスを適用することが可能である。アルゴリズムは、景観に関するネットワークモデルの作成をもたらすことが可能である。例えば、図5が、一部の実施形態による集約されるネットワークモデル500の第1のレベルの眺望を示す。この例において、参加者510が、ホスト520から情報を受信することが可能である。この情報は、例えば、メッセージフロー550を介して通信する着信呼構成530および発信呼構成540に関連することが可能である。景観における実際の物理的ホスト520は、参加者510に関連することが可能であり、さらに実際の物理的ホスト520によって提供される、または呼び出されるインタフェースが見出されることが可能であることに留意されたい。ホスト520自体、カテゴリに関連することが可能であり、さらにそれらのカテゴリに依存して、ホスト520は、アプリケーションおよび統合ロジックに関連することも可能である。例えば、図6は、一部の実施形態による集約されるネットワークモデル600の別のレベルを示す。前述の場合と同様に、参加者610が、ホスト620から情報を受信することが可能である。この情報は、例えば、メッセージフロー650を介して通信する着信呼構成630および発信呼構成640に関連することが可能である。モデル600のこのレベルによれば、参加者610は、統合プロセスおよびまたはフロー624、およびビジネスアプリケーション626に関連する情報をシステム622から受信することも可能である。集約に関して、アプリケーションおよびまたは統合ロジックは、システムという用語を使用して統一されることが可能である。図6のモデル600に示される集約のレベルは、インタフェースを提供する、さらにまたは消費するホスト620上に展開されたシステムを追加することによって、モデル500を拡張することに留意されたい。集約されるネットワークモデルを作成するためのアルゴリズムは、一部の実施形態によれば、複数のステップで実行されることが可能である。さらに、アルゴリズムは、特定のソースモデルとは無関係であるとともに、ネットワークにおいていずれのホスト、およびいずれのネットワークが利用可能であるかにかかわらず、ネットワークの眺望を作成することが可能である。また、コンソリデータは、アルゴリズムのステップを調整して、実行して、さらに分析の相当な部分を、ソースモデルと対話する特定の探査分析構成要素に委任することも可能である。図7は、一部の実施形態による、例えば、図3のネットワーク管理サーバ310によって実行されることが可能な集約プロセス700の流れ図である。S402で、景観における一意のホストおよびシステムが識別されることが可能である。ネットワークは、顧客景観において実行されている物理的ホストに基づくことが可能であることに留意されたい。物理的ホストは、例えば、ホスト名またはIPアドレスなどの異なる識別子を使用して識別されてもよい。ホスト上で実行される論理エンティティは、システムと呼ばれることが可能である。ホスト情報およびまたはシステム情報自体は、複数のソースからフェッチされ、さらにまたは様々なソースモデルの中に格納されることが可能である。そのようなソースの例が、SAP社からのSMSYおよびSLD、ヒューレットパッカード社からのOpenView、IBM社からのTivoli、コンピュータアソシエーツ社からのUnicenter、およびマイクロソフト社からのSMSである。物理的ホストは、例えば、遠隔管理のために、システム管理ソフトウェアに登録されることが可能である。一部の事例において、システム管理ソフトウェアは、アダプタを介してホスト情報およびシステム情報の読み取りおよび書き込みを行うAPIを提供することが可能であり、さらにソース読み取りエージェントが、ホスト情報およびシステム情報をフェッチし、この情報をソースモデルとして格納することができることが可能である。ホストおよびシステムは、様々な仕方で様々なソースモデルにおいて表されることが可能であり、その結果、一意のホストおよびシステムのリストが、集約されたネットワークモデル内で作成されることが可能である。ホストまたはシステムに関する単一の全般的に適用可能な識別スキームが存在して、時を経ても安定している識別子は全く存在しないことが可能であることに留意されたい。このため、実施形態は、可能なすべての識別子のセットにわたって等価クラスを使用してホストおよびシステムを識別することが可能である。各等価クラスの要素は、同一のホストまたはシステムを識別することが知られているすべての識別子を備えることが可能である。例えば、IPアドレス106614551、DNS名vml2171wdfsapcorp、およびSAP名BXIによって識別されるホストが存在することも可能である。その場合、このホストを識別する等価クラスは、3つすべての識別子を含むことが可能であり、この3つの識別子のうち1つに対するいずれのリファレンスも、その特定のホストを識別することが可能である。等価クラスは、時を経ても安定していることはない可能性があるが、等価クラスの要素の少なくとも1つが、別の1つが変化する際に変化しないことが可能である。このようにして、定常的ではあるが、漸進的な変化が存在する状況で、相当な期間にわたって同一性が保たれることが可能である。ソースモデルは、フェッチされ、ネットワークソース層内に保たれて、ソースモデルの中の特定のインスタンスの一意の識別を許すことが可能であることに留意されたい。ネットワークソース層の中にソースモデルのコピーを保持することは、ホスト識別子およびまたはシステムシステムに対するリファレンスを探索する、それらのソースモデルに対する効率的なクエリを許すことも可能である。或る特定の発見された情報の系統を特定するのに、その発見された情報に、元の情報を含むソースモデルを参照する識別子で注釈が付けられることが可能である。新たに発見された情報を追加するプロセスと、古くなった情報を除去するプロセスは、連続的であることが可能である。いずれの情報が妥当であるかを特定するため、発見されたそれぞれの情報にタイムスタンプで注釈が付けられる。低位の層に関する情報として、モデルから情報を除去する際、上位の層に関するその情報が依然として参照されているか否かが考慮されることが可能である。例えば、或るホストまたはシステムがもはや存在しないと判定された場合、その情報は、その情報がもはや参照されなくなるまで、それでも保持される必要がある可能性がある。集約アルゴリズムを作成するのに、規則ベースのアプローチが実施されることが可能である。このアプローチにおいて、発見された情報は、事実のセットによって記述されることが可能であり、さらに集約アルゴリズムは、規則のセットとして記述されることが可能である。規則は、例えば、集約されるネットワークモデルに最終的につながる発見された事実から、新たな事実を導き出すことが可能である。一意のホストおよびシステムを識別するのに、ネットワーク発見は、以下の述語に関する事実をもたらすことが可能である、すなわち、hostdiscは、hostIdを、当該のホストについての情報を含むソースモデルを参照する識別子に関係付けることが可能である。また、マシンの同質のクラスタが、一部の実施形態によれば、1つのホストと考えられることも可能である。発見された異なるシステムからのソースモデルは、同一の物理的ホストについて、異なるhostIdを使用し、異なる情報をもたらす可能性もあることに留意されたい。samehostdiscは、同一の物理的ホストを参照する2つのhostIdを結び付けることが可能である。systemdiscは、systemIdを、システムについての情報を含むソースモデルを参照するURIなどの識別子に関係付けることが可能である。本明細書で説明されるシステムとは、例えば、アプリケーションまたは統合システムフローであることも可能な論理エンティティを指すことが可能である。ホストに関しては、発見された異なるシステムからのソースモデルは、同一のシステムについて、異なるsystemIdを使用し、異なる情報をもたらす可能性もある。samesystemdiscは、同一のシステムを参照する2つのsystemIdを結び付けることが可能である。runsondiscは、システムを、ホストに結び付けることが可能であり、システムはそのホスト上で実行される。一部の実施形態によれば、複数のシステムが1つのホスト上で実行されることが可能であるが、システムが、複数のホスト上で実行されることは可能でないことに留意されたい。S704で、システムに向かう着信呼、およびシステムからの発信呼が、ソースモデルに基づいて特定されることが可能である。ソースモデルに基づいて、ホスト識別子およびシステム識別子を識別することが可能であり、さらに着信呼構成およびまたは発信呼構成についてクエリを行い、識別することも可能であることに留意されたい。システムに向かう多くの着信呼に関して、着信呼構成が与えられることが可能である。システムからの各発信呼に関して、着呼側システムに向かうメッセージフローを開始する発信呼構成を保持することが必要である可能性がある。一部の事例において、機能が遠隔対応であること以外に要求される着信呼構成は、全く存在しないことが可能である。この状況において、その特定のシステムから取得されるソースモデルの中で構成は、全く検出されない可能性がある。S704の実行は、一部の実施形態による図8に示されるグラフ800のような、特定のシステムidに関する発信呼着信呼グラフをもたらすことが可能である。この例において、S1は、他のシステム820からの着信呼を受信するシステムidに関連するシステム810であり、他のシステム830に発信呼を供給する。着信呼構成および発信呼構成に関して、ネットワークソース層は、以下の事実をもたらすことが可能である。すなわち、incomingdiscは、systemIdを、識別されたシステムに関する着信構成についての詳細な情報を取得するのに使用され得るURIに関係付けることが可能である。outgoingdiscは、systemIdを、識別されたシステムに関する発信構成についての詳細な情報を取得するのに使用され得るURIに関係付けることが可能である。図7を再び参照すると、S706で、システムからのメッセージフローが、発信呼に基づいて特定されることが可能である。つまり、発信呼は、特定のシステムに対して行われることが可能であり、対応する呼構成は、受信側ホストまたは受信側システムの識別子を含むことが可能である。利用可能な場合、次に、これらの識別子が、S702で特定された識別子と照合される。利用できない場合、これらの呼構成が、S708で代わりに使用されることが可能である。S706の結果、図9に示されるグラフ900のような呼グラフが生成されることが可能である。つまり、図8のグラフ800は、発信呼構成情報に基づいて、システムS2からS5を含むように拡大されている。受信者に発信呼構成を関係付けるのに、ネットワークソース層が、以下の事実をもたらすことが可能である。すなわち、receiverdiscは、発信構成に関するURIを、受信側システムを識別するsystemIdに関係付けることが可能である。receiverhostdiscは、発信構成に関するURIを、受信側ホストを識別するhostIdに関係付けることが可能である。このことは、receiverdiscと同様であることが可能である。しかし、一部の発信構成は、受信側ホストを指定するだけなので、受信側システムは、必ずしも直接に特定されるわけではない可能性がある。発呼側システムと着呼側システムの間の通信は、メッセージフローと呼ばれることが可能である。発信呼構成が受信者の識別子を含む場合、この発信呼構成を識別するURIをともに参照する対応するoutgoingdisc事実およびreceiverdisc事実が存在することが可能である。したがって、メッセージフローは、URIに関するこれらの事実を合わせることによって特定されることが可能である。messageflowおよびmessageflowhostは、システムとホストの間のメッセージフローを特定することが可能である。システム間のメッセージフローは、例えば、呼構成のURIを使用して特定されることが可能である。S708で、システムに向かうメッセージフローが、着信呼に基づいて特定されることが可能である。着信呼構成は、ときとして、特定の送信側ホストまたは送信側システムを識別することも可能であることに留意されたい。利用可能な場合、そのような識別子は、S702で特定された識別子と照合されることが可能である。発信構成の中で受信者を見出すことは一般的である可能性があるが、着信構成の中で特定の送信者が指定されることは、それほど一般的ではない可能性がある。したがって、着信送信者ペアより多くの発信受信者ペアが発見されるものと予期されることが可能である。S708は、図10のグラフ1000によって示されるとおり、受信される着信呼の送信元であるシステムを追加することによるシステムの呼グラフの拡張であることが可能である。つまり、グラフ1000は、着信呼構成情報に基づいて、現在ではシステムS4およびS5を含むように拡張されている。着信呼構成を送信者に関係付けるのに、ネットワークソース層は、以下の事実をもたらすことが可能である。すなわち、senderdiscは、着信構成に関するURIを、送信側システムを識別するsystemIdに関係付けることが可能である。S706と同様に、着信呼構成が送信者の識別子を含む場合、この着信呼構成を識別するURIをともに参照する対応するincomingdisc事実およびsenderdisc事実が存在することが可能である。したがって、メッセージフローは、URIに関するこれらの事実を合わせることによって特定されることが可能である。S710で、システムに関する呼グラフが、ネットワークを形成するようにマージされることが可能である。S702からS708は、一意のホストおよびシステムを識別しており、さらに発見された単一のシステムに関する利用可能な情報から導き出されることが可能なメッセージフローを特定していることに留意されたい。ホストとシステムの間のより多くのメッセージフローを特定するのに、発見された様々なシステムからの既に識別されている着信呼構成および発信呼構成がマッチングされることが可能である。このことは、例えば、適合するプロトコルをマッチングすること、適合するメッセージタイプをマッチングすることなどによって行われることが可能である。一部の事例において、着信呼構成は、既に識別されている発信呼構成と合致しない可能性がある。また、対応する着信呼構成が全く特定され得ない既存の発信呼構成が存在する可能性もある。そのような構成は、一部の実施形態により、集約されるモデルの中に留まることが可能である。新たなメッセージフローを特定した後、グラフの間で新たなリンクが作成されることが可能である。これらの新たなリンク、および保持されるリンクされていない構成は、図11に示されるビジネスプロセス景観全体のグラフ1100のようなグラフをもたらすことが可能である。S712で、メッセージフローは、アプリケーションコンテンツおよび統合コンテンツにリンクされることが可能である。ホストおよびシステムを有する発信呼構成および着信呼構成は、ネットワークの眺望をもたらすことが可能である。しかし、これらのメッセージフローは、ホストとシステムの間の通信だけしか含まないことが可能である。また、発信呼構成および着信呼構成は、システム上に展開され、システム上で実行されるアプリケーションコンテンツおよび統合コンテンツに対するリンクを有することも可能である。このため、S712が、ホストおよびシステムの内部で、このリンクを特定することが可能である。システムのカテゴリは、ソースモデルを特定することが可能であり、このため、特定され得るリンクを定義することが可能である。例えば、アプリケーションホストおよびアプリケーションシステムの場合、S712は、特定の発信呼構成および着信呼構成に関して、特定のアプリケーションプロキシに至るリンク、そのプロキシを経由するリンク、アプリケーション自体に至るリンクを特定することが可能である。この特定は、特定のホストが、同時に実行されている複数のアプリケーションを有する可能性があるため、役立つ可能性があることに留意されたい。さらに、アプリケーションの本来的な構造に依存して、発信呼をトリガするプロセスステップが存在する可能性がある一方で、他のステップは、着信呼を受信する。統合バス企業サービスバスB2Bゲートウェイの場合、S712は、特定の着信呼構成に関して、特定の発信呼構成または発信呼構成のセットに至るリンクを特定することが可能である。このことは、例えば、統合バスがメッセージを受信した際に、統合バス上で展開される、構成される、または実行される統合プロセスまたは統合フローに変換される。この場合も、統合コンテンツソースモデル、ならびにログやトレースなどの運用データに依存して、統合バスを通るメッセージのパスをたどることが可能であり得る。この分析は、例えば、着信呼を発信呼に結び付け、さらに可能な限り中間の詳細を特定する。このため、実施形態は、IT管理者とビジネス参加者の両方に役立つことが可能である効率的な自動的ネットワーク景観をもたらすことが可能である。実施形態は、本明細書において単に例示の目的で説明されている。この説明から、実施形態は、説明される実施形態に限定されず、添付の特許請求の範囲の趣旨および範囲によってだけ限定される変形形態および代替形態で実施されることが可能であることが、当業者には認識されよう。