(57)【特許請求の範囲】
【請求項１】
ネットワーク景観において複数の互いに接続されたエンティティを発見するステップと、
前記エンティティのサブセットを自動的に集約してビジネス参加者にし、前記集約することは、少なくとも1つの規則ベースのアルゴリズムに従って実行されるステップと、
前記ビジネス参加者を含むビジネスプロセス景観を生成するステップとを備える、コンピュータが実施する方法であって、
前記ビジネスプロセス景観において前記ビジネス参加者に集約された前記エンティティの前記サブセット内の１つの前記エンティティは、システムであり、
ネットワーク景観内において複数の互いに接続されたエンティティを前記発見するステップは、
前記ビジネスプロセス景観において、前記ビジネス参加者に集約された前記エンティティの前記サブセットについての情報を発見するステップであって、前記ビジネス参加者に集約された前記エンティティの前記サブセットについての、発見された前記情報は、複数のソースモデルと前記システムの複数の異なる表現を含み、ここで、
ビジネス参加者に前記エンティティのサブセットを前記自動的に集約するステップは、
前記少なくとも１つの規則ベースのアルゴリズムに従って、前記ソースモデルにわたって類似性検出および関係特定を実行するステップを含む、
方法。
【請求項２】
前記エンティティの少なくともいくつかは、(i)ビジネスアプリケーション、(ii)ビジネスシステム、(iii)ファイルシステム、(iv)データベース管理システム、または(v)企業リソース計画システムの少なくとも1つに関連する請求項1に記載の方法。
【請求項３】
前記発見するステップは、着信呼構成情報および発信呼構成情報を分析するステップを備える請求項1に記載の方法。
【請求項４】
前記発見するステップは、運用者から受け取られた情報に少なくとも部分的に基づく請求項3に記載の方法。
【請求項５】
前記集約するステップは、合致分析、類似性分析、または関係分析に少なくとも部分的に基づく請求項1に記載の方法。
【請求項６】
前記集約するステップは、運用者から受け取られた情報に少なくとも部分的に基づく請求項5に記載の方法。
【請求項７】
前記アルゴリズムは、ヒューリスティクアルゴリズムを備える請求項1に記載の方法。
【請求項８】
前記アルゴリズムは、(i)アプリケーションシステム概要、(ii)製品バージョン、(iii)接続情報、(iv)ミドルウェアシステム上、またはアプリケーションシステム上で実行されている統合、(v)インタフェース、(vi)統合プロセスモデル、(vii)運用データ、(viii)ビジネスプロセス記述、(ix)ビジネス役割およびビジネス参加者、(x)ビジネス対話、または(xi)ビジネス協力に少なくとも部分的に基づく請求項1に記載の方法。
【請求項９】
前記発見するステップおよび前記集約するステップは、実質的にリアルタイムで実行される請求項1に記載の方法。
【請求項１０】
前記発見するステップおよび前記集約するステップは、実質的に連続的なプロセスを備える請求項1に記載の方法。
【請求項１１】
前記発見するステップおよび前記集約するステップの少なくともいずれかは、アプリケーションプログラミングインタフェースを介して入手可能なメタモデルおよび運用データを表すソースモデルに基づく請求項1に記載の方法。
【請求項１２】
前記アプリケーションプログラミングインタフェースは、(i)アプリケーションシステムまたは(ii)統合バスの少なくともいずれかに関連する請求項11に記載の方法。
【請求項１３】
互いに接続されたシステムの景観において複数の一意のホストおよびシステムを識別するステップと、
ソースモデルに基づいて、各システムに向かう着信呼、および各システムからの発信呼を特定するステップと、
発信呼に基づいて、各システムからのメッセージフローを特定するステップと、
着信呼に基づいて、各システムに向かうメッセージフローを特定するステップと、
前記システムに関する呼グラフをマージして、前記景観のビジネスプロセスネットワークを作成するステップと、
前記ビジネスプロセスネットワークに関するメッセージフロー、アプリケーションコンテンツ、および統合コンテンツを結び付けるステップと、
ビジネスプロセス景観においてビジネス参加者に集約されたエンティティのサブセット内の１つの前記エンティティは、システムであり、
ネットワーク景観内において複数の互いに接続されたエンティティを発見するステップは、
前記ビジネスプロセス景観において、前記ビジネス参加者に集約された前記エンティティの前記サブセットについての情報を発見するステップであって、前記ビジネス参加者に集約された前記エンティティの前記サブセットについての、発見された前記情報は、複数のソースモデルと前記システムの複数の異なる表現を含み、ここで、
ビジネス参加者に前記エンティティのサブセットを自動的に集約するステップは、
前記少なくとも１つの規則ベースのアルゴリズムに従って、前記ソースモデルにわたって類似性検出および関係特定を実行するステップと、
を備える方法を実行するようにコンピュータによって実行可能なプログラムコードを格納している一時的でないコンピュータ可読媒体。
【請求項１４】
前記識別するステップは、ソースモデルに関連する請求項13に記載の媒体。
【請求項１５】
着信呼を前記特定するステップは、着信呼構成情報に少なくとも部分的に基づく請求項13に記載の媒体。
【請求項１６】
ネットワーク景観において複数の互いに接続されたエンティティを発見するネットワークサービス層プラットフォームと、
前記エンティティのサブセットを自動的に集約してビジネス参加者にし、前記集約することは、少なくとも1つの規則ベースのアルゴリズムに従って実行されるネットワーク集約層プラットフォームと、を備え、
ビジネスプロセス景観において前記ビジネス参加者に集約された前記エンティティの前記サブセット内の１つの前記エンティティは、システムであり、
ネットワーク景観内において複数の互いに接続されたエンティティを前記発見することは、
前記ビジネスプロセス景観において、前記ビジネス参加者に集約された前記エンティティの前記サブセットについての情報を発見することであって、前記ビジネス参加者に集約された前記エンティティの前記サブセットについての、発見された前記情報は、複数のソースモデルと前記システムの複数の異なる表現を含み、ここで、
ビジネス参加者に前記エンティティのサブセットを前記自動的に集約することは、
前記少なくとも１つの規則ベースのアルゴリズムに従って、前記ソースモデルにわたって類似性検出および関係特定を実行することを含む、
ネットワーク管理サーバ。
【請求項１７】
ネットワークソース層プラットフォームは、(i)探査-分析サービス、(ii)統合モデル展開サービス、(iii)ソース読み取りエージェント、(iv)ソース書き込みエージェント、または(v)ソースモデルの少なくとも1つをさらに含む請求項16に記載のネットワーク管理サーバ。
【請求項１８】
前記ネットワーク集約層プラットフォームは、(i)集約されるネットワークモデル、または(ii)コンソリデータの少なくともいずれかをさらに含む請求項16に記載のネットワーク管理サーバ。
【請求項１９】
前記ビジネス参加者を含むビジネスプロセス景観を表示するグラフィカルユーザインタフェースを提供するネットワーク統合モデル層プラットフォームをさらに備える請求項16に記載のネットワーク管理サーバ。
【請求項２０】
前記ネットワーク統合モデル層プラットフォームは、(i)運用リンカ、(ii)シミュレータおよびオプティマイザ、または(iii)富化-統合モデル構成要素の少なくとも1つを含む請求項19に記載のネットワーク管理サーバ。
【発明の詳細な説明】
【技術分野】
【０００１】
いくつかの実施形態は、ビジネスネットワーク管理に関する。より具体的には、いくつかの実施形態は、互いに統合された、システムおよびアプリケーションの統合ネットワークを作成し、さらにビジネスプロセスの見地からそれらのシステムおよびアプリケーションの間の対話を記述する、複数のソースからのデータおよびメタデータの発見および/または集約に関連する。
【背景技術】
【０００２】
企業内の統合開発は、既存のアプリケーション、システム、および/またはインタフェースを理解して、一貫性のある仕方でそれらのアプリケーション、システム、および/またはインタフェースの間の通信を円滑にすることを要求する可能性がある。例えば、統合ミドルウェアアプリケーションは、「A2A」(アプリケーションツーアプリケーション)統合、「B2B」(ビジネスツービジネス)統合、および/または「EDI」(電子データ交換)通信を可能にすることができる。これらのミドルウェアアプリケーションは、アプリケーションに、「SOA」(サービス指向アーキテクチャ)原理および「EDA」(イベント駆動アーキテクチャ)原理を実施させることが可能であり、さらに企業内の様々なアプリケーションにまたがるビジネスプロセスを調整するのを助けることが可能である。一部の顧客景観において、そのようなタスクを実行している複数のソフトウェアインスタンス(複数のソフトウェアベンダからの)が存在する可能性もある。これらのソフトウェアインスタンスは、例えば、中央ハブとして展開されること、またはアプリケーションシステム内に埋め込まれることも可能である。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
統合開発を円滑にするのを助けるのに、ネットワークは、ミドルウェアアプリケーションを介するシステムおよびアプリケーションの間の統合とともに、顧客の景観（landscape）におけるシステムおよびアプリケーション(それらのシステムおよびアプリケーションの様々な表現を含む)を記述することによって計画策定されることが可能である。しかし、そのようなネットワーク計画図またはネットワーク景観を作成することは、時間がかかり、誤りが生じやすいプロセスであり得る。例えば、統合ミドルウェアアプリケーションは、技術の見地とビジネスの見地の両方から、その景観の正確な眺望をもたらさない可能性がある。そのような眺望は、そのネットワークを運用する際に役立つだけでなく、そのネットワークの将来の変更および/または拡張を実施するのに必要とされる可能性もある。
【課題を解決するための手段】
【０００４】
したがって、ビジネスプロセス景観を自動的に、効率的に決定するための方法および機構が、本明細書で説明されるいくつかの実施形態に従って与えられることが可能である。
【図面の簡単な説明】
【０００５】
【図１】一部の実施形態によるビジネスネットワーク管理景観を示すブロック図である。
【図２】一部の実施形態によるビジネスネットワーク管理景観を示す図である。
【図３】一部の実施形態によるネットワークを探査することができるネットワーク管理サーバを含むシステムを示すブロック図である。
【図４】一部の実施形態によるビジネスネットワーク管理プロセスを示す流れ図である。
【図５】一部の実施形態による集約されるネットワークモデルを示す図である。
【図６】一部の実施形態による集約されるネットワークモデルの別のレベルを示す図である。
【図７】一部の実施形態による集約プロセスを示す流れ図である。
【図８】一部の実施形態によるシステムに関連する発信呼および着信呼を示すグラフである。
【図９】一部の実施形態によるシステムからの発信呼を示すグラフである。
【図１０】一部の実施形態により通信しているシステムを示すグラフである。
【図１１】一部の実施形態によるシステムに関連するマージされたグラフである。
【発明を実施するための形態】
【０００６】
企業内の統合開発は、既存のアプリケーション、システム、および/またはインタフェースを理解して、一貫性のある仕方でそれらのアプリケーション、システム、および/またはインタフェースの間の通信を円滑にすることを要求する可能性がある。例えば、統合ミドルウェアアプリケーションは、A2A統合、B2B統合、および/またはEDI通信を可能にすることができる。これらのミドルウェアアプリケーションは、アプリケーションに、SOA原理およびEDA原理を実施させることが可能であり、さらに企業内の様々なアプリケーションにまたがるビジネスプロセスを調整するのを助けることが可能である。一部の顧客景観において、そのようなタスクを実行している複数のソフトウェアインスタンス(複数のソフトウェアベンダからの)が存在する可能性もある。これらのソフトウェアインスタンスは、例えば、中央ハブとして展開されること、またはアプリケーションシステム内に埋め込まれることも可能である。
【０００７】
統合開発を円滑にするのを助けるのに、ネットワークは、ミドルウェアアプリケーションを介するシステムおよびアプリケーションの間の統合とともに、顧客の景観におけるシステムおよびアプリケーション(それらのシステムおよびアプリケーションの様々な表現を含む)を記述することによって計画策定されることが可能である。例えば、図1は、一部の実施形態によるビジネスネットワーク管理景観100のブロック図である。景観100は、いくつかの互いに接続されたシステム110を含む。システム110は、例えば、互いに通信するビジネスアプリケーションおよび/またはサーバを備えることが可能である。システム110のサブセット120、130、140は、ビジネスの点で一緒にグループ化されることが可能であることに留意されたい。例えば、1つのサブセット120が、本部ビジネスプロセスに関連する一方で、別のサブセット130が、流通センタプロセスに関連する。
【０００８】
しかし、そのようなネットワーク計画図またはネットワーク景観100を作成することは、時間がかかり、誤りが生じやすいプロセスであり得る。例えば、統合ミドルウェアアプリケーションは、技術の見地とビジネスの見地の両方から、その景観の正確な眺望をもたらさない可能性がある。そのような眺望は、そのネットワークを運用する際に役立つだけでなく、そのネットワークの将来の変更および/または拡張を実施するのに必要とされる可能性もある。
【０００９】
一部の実施形態によれば、統合ネットワークについての情報が、様々なタイプの既存の(さらに実行中の)生産的システム(例えば、アプリケーションおよび/またはミドルウェア)から求められ、企業の日々のビジネスプロセスに対して最新であるネットワークの眺望が、実質的にリアルタイムで構築されることが可能である。統合ネットワークは、例えば、物理的ハードウェアシステム上で実行されているビジネスアプリケーションを介して互いに対話しているビジネス参加者のネットワークと定義されることが可能である。例えば、図2は、一部の実施形態による、3名のビジネス参加者220、230、240(例えば、図1のサブセット120、130、140にそれぞれ対応する)を含むビジネスネットワーク管理景観200を示す。
【００１０】
一部の実施形態によれば、そのような統合ネットワークは、既存のアプリケーションおよび/またはミドルウェアシステムにおいて入手可能な情報に基づいて、顧客景観に関して自動的に構築されることが可能である。この情報は、例えば、アプリケーションシステム概観(例えば、アプリケーションサーバまたはデータベースに関連する)、製品バージョン、接続情報、ミドルウェアシステム上、またはアプリケーションシステム上で実行されている統合、インタフェース、統合プロセスモデル、運用データ、ビジネスプロセス記述、ビジネス役割およびビジネス参加者、ビジネス対話、および/またはビジネス協力のうちいくつか、またはすべてを含むことが可能である。
【００１１】
実施形態は、情報の以上の例に限定されないことに留意されたい。さらに、一部の実施形態において、いくらかの運用者介入が許されることが可能である。つまり、ネットワーク景観は、運用者が情報のいくらか(例えば、システム名およびシステムエイリアス)を供給する場合でさえ、「自動的に」決定されることが可能である。同一の情報が複数の表現を有する(例えば、異なるドメインにおけるその情報の用法のため)場合、アプリケーションおよびシステムの多様性が要因である可能性があることに留意されたい。例えば、或るシステムについての情報が、アプリケーションおよびミドルウェアシステムにおいて1つの表現を有することが可能であり、IT動作に関して別の表現を有することが可能であり、さらにプロセスモデリングに関する参加者としてさらに別の表現を有することが可能である。
【００１２】
さらに、様々なツールが、ネットワーク景観を構築するのに使用されることが可能なメタ情報を供給することが可能であることに留意されたい。例えば、システム管理ツール、IT運用ツール、監視-IT運用ツール、根本原因分析-事象管理ツールがそれぞれ、監視データおよび運用データを収集して、管理者にシステムを解決させ、運用させることが可能である。これらのツールは、ランタイムエージェントを介して、メタデータおよび運用データを読み取る、または特定のアプリケーションまたはシステムを監視するいくらかの限定された発見様の能力を有することが可能である。また、統合ミドルウェア(例えば、企業アプリケーション統合、企業サービスバス、および/またはSOAアプリケーション)が、コンテンツ開発およびコンテンツ運用のための設計ツールおよび管理ツールを有することも可能である。これらのツールは、メタデータを作成すること、および/または既存の情報のいくらかの発見を円滑にすることも可能である。
【００１３】
本明細書で与えられる一部の実施形態は、発見プロセス中にソースデータを、様々なソースシステムとは独立に、共通の表現にする。次に、規則ベースのアルゴリズムのセットが、集約プロセスにおいて実行されて、この情報の間の類似性および関係が識別されることが可能である。これらのプロセスは、一部の実施形態により、実質的にリアルタイムで実行されることが可能である。任意の所与の時点で、統合ネットワークは、情報ソースの或る特定の状態のスナップショットを表すことが可能であるものの、発見プロセスおよび集約プロセスは、時とともに継続的に実行されることが可能である(統合ネットワークは、ソースが追加される、取り除かれる、または変更されるにつれ、常に進化している可能性があるので)。
【００１４】
ビジネスネットワーク管理の目標は、統合開発の端から端までのライフサイクルを容易化すること、およびより高速な実行のために異なる情報上の協力を許すことを含む。したがって、有用なネットワーク景観は、アプリケーションおよび統合バス/企業サービスバスを有する顧客景観の一般化された眺望を反映することが可能である。さらに、このネットワークの眺望は、ネットワークの可視性および透明性を確実にするように自動的に構築されるとともに、現実の生産システムに合わせてライブ更新される必要がある可能性がある。
【００１５】
ネットワークを発見するプロセスは、集約される情報モデルおよびソース情報モデル、ならびに情報の分析を使用してシステム景観を探査して、情報内の類似性および関係を見出すことができる。ネットワークの探査は、統合技術が、アプリケーション間の仲介役をする(さらに、このため、アプリケーションの統合エンドポイントについてのメタデータを有する)と、統合技術から始まることが可能である。プロキシおよび接続を有するアプリケーションの場合、情報は、接続およびインタフェースの詳細、および/または運用データを含むことが可能である。プロキシ、接続、および仲介を有するアプリケーションの場合、情報は、接続およびインタフェースの詳細、マッピング、ルーティング、および/または運用データを含むことが可能である。スタンドアロンの企業サービスバスまたは統合サーバの場合、情報は、接続およびインタフェースの詳細、マッピング、ルーティング、システム中心プロセス、および/または運用データを含むことが可能である。スタンドアロンの企業サービスバスまたは統合サーバに接続されたアプリケーションの場合、情報は、接続データおよび/または運用データを含むことが可能である。B2Bゲートウェイの場合、情報は、接続およびインタフェースの詳細、マッピング、ルーティング、システム中心プロセス、および/または運用データを含むことが可能である。会社のビジネスパートナにおいて実行されるB2Bゲートウェイに接続されたアプリケーションの場合、情報は、接続データおよび/または運用データを含むことが可能である。
【００１６】
情報は、ネットワーク景観を決定するように分析されることが可能である。例えば、図3は、一部の実施形態によるネットワーク320を探査することが可能なネットワーク管理サーバ310を含むシステム300のブロック図である。ネットワーク管理サーバ310は、ネットワーク320における様々なシステムから情報を受信することが可能である。例えば、ネットワーク管理サーバ310は、「HTTP」(ハイパーテキストトランスポートプロトコル)通信、または他の任意のタイプのデータ交換を介して、遠隔システムから入力レコードをインポートすることが可能である。ネットワーク320におけるネットワーク管理サーバ310および/またはシステムは、例えば、PC(パーソナルコンピュータ)、サーバ、および/または移動デバイスに関連することが可能である。
【００１７】
図3は、一部の実施形態による論理アーキテクチャを表し、実際の実施例は、他の仕方で構成されたさらなる構成要素、または異なる構成要素を含むことも可能であることに留意されたい。さらに、本明細書で説明される各システムは、任意の数の他の公共ネットワークおよび/またはプライベートネットワークを介して通信状態にある任意の数のデバイスによって実施されることが可能である。デバイスの2つ以上が、互いに遠隔に配置されることが可能であり、さらに任意の知られている様態のネットワークおよび/または専用接続を介して、互いに通信することが可能である。さらに、各デバイスは、本明細書で説明される機能、および他の任意の機能を提供するのに適した任意の数のハードウェア要素および/またはソフトウェア要素を備えることが可能である。他のトポロジが、他の実施形態と併せて使用されることも可能である。
【００１８】
本明細書で説明されるすべてのシステムおよびプロセスは、1つまたは複数のコンピュータ可読媒体上に格納されたプログラムコードとして実現されることが可能である。そのような媒体は、例えば、フロッピー（登録商標）ディスク、CD-ROM、DVD-ROM、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」(Solution Manager) (登録商標)および「SLD」(System Landscape Directory)(登録商標)、ヒューレットパッカード社からのOpen View(登録商標)、IBM社からのTivoli(登録商標)、コンピュータアソシエーツ社からのUnicenter(登録商標)、およびマイクロソフト社からの「SMS」(System Management Server)(登録商標)である。物理的ホストは、例えば、遠隔管理のために、システム管理ソフトウェアに登録されることが可能である。一部の事例において、システム管理ソフトウェアは、アダプタを介してホスト情報およびシステム情報の読み取りおよび書き込みを行うAPIを提供することが可能であり、さらにソース読み取りエージェントが、ホスト情報およびシステム情報をフェッチし、この情報をソースモデルとして格納することができることが可能である。
【００３６】
ホストおよびシステムは、様々な仕方で様々なソースモデルにおいて表されることが可能であり、その結果、一意のホストおよびシステムのリストが、集約されたネットワークモデル内で作成されることが可能である。ホストまたはシステムに関する単一の全般的に適用可能な識別スキームが存在して、時を経ても安定している識別子は全く存在しないことが可能である(例えば、時とともに、1つのDNSホスト名に異なるIPアドレスが使用されることも可能であり、さらに同一のIPアドレスに異なるホスト名が使用されることも可能である)ことに留意されたい。このため、実施形態は、可能なすべての識別子のセットにわたって等価クラスを使用してホストおよびシステムを識別することが可能である。各等価クラスの要素は、同一のホストまたはシステムを識別することが知られているすべての識別子を備えることが可能である。例えば、IPアドレス「10.66.145.51」、DNS名「vml2171.wdf.sap.corp」、およびSAP名「BXI」によって識別されるホストが存在することも可能である。その場合、このホストを識別する等価クラスは、3つすべての識別子を含むことが可能であり、この3つの識別子のうち1つに対するいずれのリファレンスも、その特定のホストを識別することが可能である。等価クラスは、時を経ても安定していることはない可能性があるが、等価クラスの要素の少なくとも1つが、別の1つが変化する際に変化しないことが可能である。このようにして、定常的ではあるが、漸進的な変化が存在する状況で、相当な期間にわたって同一性が保たれることが可能である。
【００３７】
ソースモデルは、フェッチされ、ネットワークソース層内に保たれて、ソースモデルの中の特定のインスタンスの一意の識別を許すことが可能であることに留意されたい。ネットワークソース層の中にソースモデルのコピーを保持することは、ホスト識別子および/またはシステムシステムに対するリファレンスを探索する、それらのソースモデルに対する効率的なクエリを許すことも可能である。或る特定の発見された情報の系統を特定するのに、その発見された情報に、元の情報を含むソースモデルを参照する識別子で注釈が付けられることが可能である。
【００３８】
新たに発見された情報を追加するプロセスと、古くなった情報を除去するプロセスは、連続的であることが可能である。いずれの情報が妥当であるか(およびいずれの情報がもはや妥当でないか)を特定するため、発見されたそれぞれの情報にタイムスタンプで注釈が付けられる。低位の層(例えば、ソースモデルまたは集約されるモデル)に関する情報として、モデルから情報を除去する際、上位の層に関するその情報(例えば、集約されるモデル)が依然として参照されているか否かが考慮されることが可能である。例えば、或るホストまたはシステムがもはや存在しないと判定された場合、その情報は、その情報がもはや参照されなくなるまで、それでも保持される(さらに利用できないという印が付けられる)必要がある可能性がある。
【００３９】
集約アルゴリズムを作成するのに、規則ベースのアプローチが実施されることが可能である。このアプローチにおいて、発見された情報は、事実のセットによって記述されることが可能であり、さらに集約アルゴリズムは、規則のセットとして記述されることが可能である。規則は、例えば、集約されるネットワークモデルに最終的につながる発見された事実から、新たな事実を導き出すことが可能である。
【００４０】
一意のホストおよびシステムを識別するのに、ネットワーク発見は、以下の述語に関する事実をもたらすことが可能である(発見によってもたらされるすべての述語には、「_disc」というサフィックスが付けられる)、すなわち、
「host_disc(hostId, URI)」は、hostId(例えば、IPアドレス)を、当該のホストについての情報を含むソースモデルを参照する識別子に関係付けることが可能である。また、マシンの同質のクラスタが、一部の実施形態によれば、1つのホストと考えられることも可能である。発見された異なるシステムからのソースモデルは、同一の物理的ホストについて、異なるhostId(例えば、別のIPアドレスまたはDNS名)を使用し、異なる情報をもたらす可能性もあることに留意されたい。
「same_host_disc(hostId1, hostId2)」は、同一の物理的ホストを参照する2つのhostId(例えば、IPアドレスとDNS名)を結び付けることが可能である。
「system_disc(systemId, URI)」は、systemIdを、システムについての情報を含むソースモデルを参照する「URI」(ユニフォームリソースロケータ)などの識別子に関係付けることが可能である。本明細書で説明される「システム」とは、例えば、アプリケーションまたは統合システム/フローであることも可能な論理エンティティを指すことが可能である。ホストに関しては、発見された異なるシステムからのソースモデルは、同一のシステムについて、異なるsystemIdを使用し、異なる情報をもたらす可能性もある。
「same_system_disc(systemId1, systemId2)」は、同一のシステムを参照する2つのsystemIdを結び付けることが可能である。
「runs_on_disc(systemId, hostId)」は、システムを、ホストに結び付けることが可能であり、システムはそのホスト上で実行される。一部の実施形態によれば、複数のシステムが1つのホスト上で実行されることが可能であるが、システムが、複数のホスト上で実行されることは可能でないことに留意されたい。
【００４１】
S704で、システムに向かう着信呼、およびシステムからの発信呼が、ソースモデルに基づいて特定されることが可能である。ソースモデルに基づいて、ホスト識別子およびシステム識別子を識別することが可能であり、さらに着信呼構成および/または発信呼構成についてクエリを行い、識別することも可能であることに留意されたい。システムに向かう多くの着信呼に関して、着信呼構成が与えられることが可能である(例えば、送信側チャネルまたはウェブサービスエンドポイント構成などの)。システムからの各発信呼に関して、着呼側システムに向かうメッセージフローを開始する発信呼構成(例えば、受信側チャネル、ウェブサービス宛先、およびウェブサービス論理ポート構成)を保持することが必要である可能性がある。一部の事例において、機能が遠隔対応であること以外に要求される着信呼構成は、全く存在しないことが可能である。この状況において、その特定のシステムから取得されるソースモデルの中で構成は、全く検出されない可能性がある。
【００４２】
S704の実行は、一部の実施形態による図8に示されるグラフ800のような、特定のシステムidに関する発信呼-着信呼グラフをもたらすことが可能である。この例において、S1は、他のシステム820からの着信呼を受信する「システムid」に関連するシステム810であり、他のシステム830に発信呼を供給する。
【００４３】
着信呼構成および発信呼構成に関して、ネットワークソース層は、以下の事実をもたらすことが可能である。すなわち、
「incoming_disc(systemId, URI)」は、systemIdを、識別されたシステムに関する着信構成についての詳細な情報を取得するのに使用され得るURIに関係付けることが可能である。
「outgoing_disc(systemId, URI)」は、systemIdを、識別されたシステムに関する発信構成についての詳細な情報を取得するのに使用され得るURIに関係付けることが可能である(incoming_discと同様に)。
【００４４】
図7を再び参照すると、S706で、システムからのメッセージフローが、発信呼に基づいて特定されることが可能である。つまり、発信呼は、特定のシステムに対して行われることが可能であり、対応する呼構成は、受信側ホストまたは受信側システムの識別子を含むことが可能である。利用可能な場合、次に、これらの識別子が、S702で特定された識別子と照合される。利用できない場合(利用可能な識別子が存在しない場合)、これらの呼構成が、S708で代わりに使用されることが可能である。S706の結果、図9に示されるグラフ900のような呼グラフが生成されることが可能である(例えば、発信呼が通信しているシステムを追加することによるシステムの呼グラフの拡張)。つまり、図8のグラフ800は、発信呼構成情報に基づいて、システムS2からS5を含むように拡大されている(図9に破線の矢印で示されるとおり)。
【００４５】
受信者に発信呼構成を関係付けるのに、ネットワークソース層が、以下の事実をもたらすことが可能である。すなわち、
「receiver_disc(URI, systemId)」は、発信構成に関するURIを、受信側システムを識別するsystemIdに関係付けることが可能である(さらに、このsystemIdは、与えられた構成から抽出されることが可能である)。
「receiver_host_disc(URI, hostId)」は、発信構成に関するURIを、受信側ホストを識別するhostIdに関係付けることが可能である。このことは、receiver_discと同様であることが可能である。しかし、一部の発信構成(例えば、ウェブサービスに関する)は、受信側ホストを指定するだけなので、受信側システムは、必ずしも直接に特定されるわけではない可能性がある。発呼側システムと着呼側システムの間の通信は、「メッセージフロー」と呼ばれることが可能である。発信呼構成が受信者の識別子を含む場合、この発信呼構成を識別するURIをともに参照する対応するoutgoing_disc事実およびreceiver_disc事実が存在することが可能である。したがって、メッセージフローは、URIに関するこれらの事実を合わせることによって特定されることが可能である。
「message_flow(systemIdSender, systemIdReceiver)」および「message_flow_host(hostIdSender, hostIdReceiver)」は、システムとホストの間のメッセージフローを特定することが可能である。システム間のメッセージフローは、例えば、呼構成のURIを使用して特定されることが可能である。
【００４６】
S708で、システムに向かうメッセージフローが、着信呼に基づいて特定されることが可能である。着信呼構成は、ときとして、特定の送信側ホストまたは送信側システムを識別することも可能であることに留意されたい。利用可能な場合、そのような識別子は、S702で特定された識別子と照合されることが可能である。発信構成の中で受信者を見出すことは一般的である可能性があるが、着信構成の中で特定の送信者が指定されることは、それほど一般的ではない可能性がある。したがって、着信/送信者ペアより多くの発信/受信者ペアが発見されるものと予期されることが可能である。S708は、図10のグラフ1000によって示されるとおり、受信される着信呼の送信元であるシステムを追加することによるシステムの呼グラフの拡張であることが可能である。つまり、グラフ1000は、着信呼構成情報に基づいて、現在ではシステムS4およびS5を含むように拡張されている(図10の破線の矢印で示されるとおり)。
【００４７】
着信呼構成を送信者に関係付けるのに、ネットワークソース層は、以下の事実をもたらすことが可能である。すなわち、
「sender_disc(URI, systemId)」は、着信構成に関するURIを、送信側システムを識別するsystemIdに関係付けることが可能である。
【００４８】
S706と同様に、着信呼構成が送信者の識別子を含む場合、この着信呼構成を識別するURIをともに参照する対応するincoming_disc事実およびsender_disc事実が存在することが可能である。したがって、メッセージフローは、URIに関するこれらの事実を合わせることによって特定されることが可能である。
【００４９】
S710で、システムに関する呼グラフが、ネットワークを形成するようにマージされることが可能である。S702からS708は、一意のホストおよびシステムを識別しており、さらに発見された単一のシステムに関する利用可能な情報から導き出されることが可能なメッセージフローを特定していることに留意されたい。ホストとシステムの間のより多くのメッセージフローを特定するのに、発見された様々なシステムからの既に識別されている着信呼構成および発信呼構成がマッチングされることが可能である。このことは、例えば、適合するプロトコルをマッチングすること、適合するメッセージタイプをマッチングすることなどによって行われることが可能である。
【００５０】
一部の事例において、着信呼構成は、既に識別されている発信呼構成と合致しない可能性がある(例えば、ウェブサービスエンドポイントが、アプリケーションシステム上で構成されているが、景観におけるシステムのいずれの上にも対応するウェブサービス宛先を有さない、あるいはデータベースアダプタが、データベースからデータを読み取るために統合バス上に構成されていることが可能であるが、この読み取り動作のために、データベース自体がインストールされているシステム上に特定の構成が全く存在しない)。また、対応する着信呼構成が全く特定され得ない既存の発信呼構成が存在する可能性もある。そのような構成は、一部の実施形態により、集約されるモデルの中に留まることが可能である。新たなメッセージフローを特定した後、グラフの間で新たなリンクが作成されることが可能である。これらの新たなリンク、および保持される「リンクされていない」構成は、図11に示されるビジネスプロセス景観全体のグラフ1100のようなグラフをもたらすことが可能である。
【００５１】
S712で、メッセージフローは、アプリケーションコンテンツおよび統合コンテンツにリンクされることが可能である。ホストおよびシステムを有する発信呼構成および着信呼構成は、ネットワークの眺望をもたらすことが可能である。しかし、これらのメッセージフローは、ホストとシステムの間の通信だけしか含まないことが可能である。また、発信呼構成および着信呼構成は、システム上に展開され、システム上で実行されるアプリケーションコンテンツおよび統合コンテンツに対するリンクを有することも可能である。このため、S712が、ホストおよびシステムの内部で、このリンクを特定することが可能である。システムのカテゴリは、ソースモデルを特定することが可能であり、このため、特定され得るリンクを定義することが可能である。
【００５２】
例えば、アプリケーションホストおよびアプリケーションシステムの場合、S712は、特定の発信呼構成および着信呼構成に関して、特定のアプリケーションプロキシに至るリンク、そのプロキシを経由するリンク、アプリケーション自体に至るリンクを特定することが可能である。この特定は、特定のホストが、同時に実行されている複数のアプリケーションを有する可能性があるため、役立つ可能性があることに留意されたい。さらに、アプリケーションの本来的な構造に依存して、発信呼をトリガするプロセスステップが存在する可能性がある一方で、他のステップは、着信呼(これらの着信呼は、可能な場合、アプリケーションソースモデル、ならびにログおよび/またはトレースなどの運用データに基づいて、やはり分析されることが可能である)を受信する。
【００５３】
統合バス/企業サービスバス/B2Bゲートウェイの場合、S712は、特定の着信呼構成に関して、特定の発信呼構成または発信呼構成のセットに至るリンクを特定することが可能である。このことは、例えば、統合バスがメッセージを受信した際に、統合バス上で展開される、構成される、または実行される統合プロセスまたは統合フローに変換される。この場合も、統合コンテンツソースモデル、ならびにログやトレースなどの運用データに依存して、統合バスを通るメッセージのパスをたどることが可能であり得る。この分析は、例えば、着信呼を発信呼に結び付け、さらに可能な限り中間の詳細を特定する。
【００５４】
このため、実施形態は、IT管理者とビジネス参加者の両方に役立つことが可能である効率的な自動的ネットワーク景観をもたらすことが可能である。
【００５５】
実施形態は、本明細書において単に例示の目的で説明されている。この説明から、実施形態は、説明される実施形態に限定されず、添付の特許請求の範囲の趣旨および範囲によってだけ限定される変形形態および代替形態で実施されることが可能であることが、当業者には認識されよう。
【符号の説明】
【００５６】
100  ビジネスネットワーク管理景観
110、300  システム
220、230、240  ビジネス参加者
310  ネットワーク管理サーバ
320  ネットワーク
330  ネットワークソース層
340  ネットワーク集約層
350  ネットワーク統合モデル層
【図１】
0005964027.tif 000002
【図２】
0005964027.tif 000003
【図３】
0005964027.tif 000004
【図４】
0005964027.tif 000005
【図５】
0005964027.tif 000006
【図６】
0005964027.tif 000007
【図７】
0005964027.tif 000008
【図８】
0005964027.tif 000009
【図９】
0005964027.tif 000010
【図１０】
0005964027.tif 000011
【図１１】
0005964027.tif 000012