(57)【要約】【課題】ビジネス・プロセスによって使用されるファイルおよび他のリソースを自動的に発見し分類するための装置、システム、および方法を提供する。【解決手段】本発明は、ソフトウェア・アプリケーションの動作挙動を表すトレース・データを収集する監視モジュールを含む。分析モジュールは、トレース・データを分析してビジネス・プロセスに関連するリソースを発見する。決定モジュールは、ビジネス・プロセスに対応する論理アプリケーションを定義し、分析モジュールによって発見されたリソースを含む。論理アプリケーションは、ビジネス・ポリシーが論理アプリケーションの全体に容易に実装できるように自動的に定義される。ビジネス・プロセスのためのリソースの手動識別は、排除されるかまたは大幅に削減される。【選択図】図２
2008509494.tif 000002
【特許請求の範囲】
【請求項１】
ビジネス・プロセスによって使用されるリソースを自動的に発見し分類するための装置であって、ソフトウェア・アプリケーションの動作挙動を表すトレース・データを収集するように構成可能な監視モジュールと、前記トレース・データを分析して少なくとも１つの前記ソフトウェア・アプリケーションを含むビジネス・プロセスに関連するリソースを発見するように構成可能な分析モジュールと、前記発見されたリソースを含む論理アプリケーションを定義するように構成可能な決定モジュールとを含む装置。
【請求項２】
前記論理アプリケーションを修正して前記論理アプリケーション内にすでに含まれているリソースに関連するリソースを含めるように構成可能な修正モジュールをさらに含む、請求項１に記載の装置。
【請求項３】
前記論理アプリケーションが、発見されたリソースをユーザが追加または削除することができるように構成可能である、請求項１または請求項２に記載の装置。
【請求項４】
前記論理アプリケーションにビジネス・レベル・ポリシーを適用するように構成可能な管理モジュールをさらに含む、請求項１ないし３のいずれかに記載の装置。
【請求項５】
前記ビジネス・プロセスのための識別子を受け取るように構成可能なインタフェースをさらに含み、前記識別子が前記ビジネス・プロセスを実行するリソースに直接関係付けられ、前記監視モジュールが、前記ビジネス・プロセスが実行されるときに前記リソースに関係する前記トレース・データを収集するように構成可能であり、前記分析モジュールが、前記トレース・データを分析して前記識別子に関連する１つまたは複数のリソースを発見するように構成可能である、請求項１ないし４のいずれかに記載の装置。
【請求項６】
前記分析モジュールが、前記トレース・データをフィルタリングして結果セットを生成するように構成可能なクエリ・モジュールと、１つまたは複数のヒューリスティック・ルーチンを前記結果セットに適用して前記識別子に関連する１つまたは複数のリソースを発見するように構成可能な評価モジュールと、前記１つまたは複数のヒューリスティック・ルーチンに応答して１つまたは複数のリソースを発見するように構成可能な発見モジュールとをさらに含む、請求項５に記載の装置。
【請求項７】
前記決定モジュールが、ヒューリスティック・ルーチンに応答して１つまたは複数の発見されたリソースを追加する、請求項５に記載の装置。
【請求項８】
前記決定モジュールが、ヒューリスティック・ルーチンに応答して、ほぼ全ての使用可能なリソースを含む事前に定義されたスーパーセットから１つまたは複数のリソースを削除する、請求項５に記載の装置。
【請求項９】
前記監視モジュールが、１つまたは複数の活動モニタを開始するように構成可能な起動モジュールであって、各活動モニタがリソースに関係する特定の種類の活動を追跡するように構成可能な起動モジュールと、前記活動モニタを制御するように構成可能なコントローラと、特定の種類の活動を実施する前記リソースの使用に応答して、前記特定の種類の活動を記述する前記活動モニタからトレース・データを格納するように構成可能な記憶モジュールとをさらに含む、請求項５に記載の装置。
【請求項１０】
前記ビジネス・プロセスによって実行される特定の種類の活動を記述するトレース・データを求めてシステム情報をスキャンするスキャナをさらに含む、請求項９に記載の装置。
【請求項１１】
ビジネス・プロセスを実行する複数のインターネットワーク化されたコンピュータ・システムとともに使用される装置であって、前記監視モジュールが各コンピュータ・システム上に存在し、前記監視モジュールが、少なくとも１つのソフトウェア・アプリケーションによって実行される動作を表すトレース・データを収集するように構成可能であり、記憶モジュールが、前記監視モジュールからのトレース・データを収集し前記収集されたトレース・データをレポジトリに格納するように構成可能であり、前記分析モジュールが、前記収集されたトレース・データを分析して前記ソフトウェア・アプリケーションを含むビジネス・プロセスに関連するリソースを発見しかつ前記発見されたリソースを含む論理アプリケーションを定義するように構成可能であり、さらに前記インタフェースが前記分析モジュールと通信し、前記インタフェースが、グラフィカル・ユーザ・インタフェース（ＧＵＩ）を介してユーザと対話し、アプリケーション・プログラミング・インタフェース（ＡＰＩ）を介して他のソフトウェア・アプリケーションと対話するように構成可能である、請求項１ないし１０のいずれかに記載の装置。
【請求項１２】
前記インタフェースが、前記論理アプリケーションにビジネス・レベル・ポリシーを適用する他のソフトウェア・アプリケーションに前記論理アプリケーションを提供する、請求項１１に記載の装置。
【請求項１３】
ビジネス・プロセスによって使用されるリソースを自動的に発見し分類するシステムであって、プロセスの実行を管理するように構成可能なオペレーティング・システムと、動作中のプロセスに関する情報を提供するように構成可能なプロセス・マネージャと、ファイル活動情報を提供するように構成可能な入／出力（Ｉ／Ｏ）モジュールと、記憶装置に格納されたファイルを管理し前記ファイルについてのメタデータを提供するように構成可能なファイル・システムと、前記オペレーティング・システムの内部で、少なくとも１つのソフトウェア・アプリケーション実行中のトレース・データを収集するように構成可能な監視モジュールであって、前記プロセス・マネージャ、前記Ｉ／Ｏモジュール、および前記ファイル・システムの少なくとも１つと対話して前記ソフトウェア・アプリケーションの動作に直接関係付けられた前記トレース・データを収集する監視モジュールと、前記トレース・データを分析して前記ソフトウェア・アプリケーションを含むビジネス・プロセスに関連するリソースを発見し、前記発見されたリソースを含む論理アプリケーションを定義するように構成可能な分析モジュールとを含むシステム。
【請求項１４】
ビジネス・プロセスによって使用されるリソースを自動的に発見し分類する方法であって、ソフトウェア・アプリケーションの動作挙動を表すトレース・データを収集するステップと、前記トレース・データを分析して、少なくとも１つの前記ソフトウェア・アプリケーションを含むビジネス・プロセスに関連するリソースを発見するステップと、前記発見されたリソースを含む論理アプリケーションを定義するステップとを含む方法。
【請求項１５】
前記論理アプリケーションを修正して前記論理アプリケーション内にすでに含まれているリソースに関連するリソースを含めるステップをさらに含む、請求項１４に記載の方法。
【請求項１６】
前記論理アプリケーションが、発見されたリソースをユーザが追加または削除できるように構成可能である、請求項１４または請求項１５に記載の方法。
【請求項１７】
ビジネス・レベル・ポリシーを前記論理アプリケーションに適用するステップをさらに含む、請求項１４ないし１６のいずれかに記載の方法。
【請求項１８】
前記ビジネス・プロセスのための識別子を受け取るステップであって、前記識別子が前記ビジネス・プロセスを実行するリソースに直接関係付けられているステップと、前記ビジネス・プロセスの実行中にトレース・データを収集するステップであって、前記トレース・データが前記リソースに関係しているステップと、前記トレース・データを分析して前記識別子に関連する１つまたは複数のリソースを発見するステップとをさらに含む、請求項１４ないし１７のいずれかに記載の方法。
【請求項１９】
前記トレース・データを分析して前記識別子に関連する１つまたは複数のリソースを発見するステップが、前記トレース・データをフィルタリングして結果セットを生成するステップと、前記結果セットに１つまたは複数のヒューリスティック・ルーチンを適用して前記識別子に関連する１つまたは複数のリソースを発見するステップと、前記１つまたは複数のヒューリスティック・ルーチンに応答して１つまたは複数のリソースを発見するステップとをさらに含む、請求項１８に記載の方法。
【請求項２０】
ヒューリスティック・ルーチンに応答して、１つまたは複数の発見されたリソースを追加するステップをさらに含む、請求項１８に記載の方法。
【請求項２１】
ヒューリスティック・ルーチンに応答して、ほぼ全ての使用可能なリソースを含む事前に定義されたスーパーセットから１つまたは複数のリソースを削除するステップをさらに含む、請求項１８に記載の方法。
【請求項２２】
１つまたは複数の活動モニタを開始するステップであって、各活動モニタが、リソースに関係する特定の種類の活動を追跡するように構成可能であるステップと、前記活動モニタを制御するステップと、特定の種類の活動を実施する前記リソースの使用に応答して、前記特定の種類の活動を記述する前記活動モニタからトレース・データを格納するステップとをさらに含む、請求項１８に記載の方法。
【請求項２３】
前記ビジネス・プロセスによって実行される特定の種類の活動を記述するトレース・データを求めてシステム情報をスキャンするステップをさらに含む、請求項２２に記載の方法。
【請求項２４】
ビジネス・プロセスを実行する複数のインターネットワーク化されたコンピュータ・システムとともに使用される方法であって、少なくとも１つのソフトウェア・アプリケーションによって実行される動作を表すトレース・データを各コンピュータ・システム上で収集するステップと、前記収集されたトレース・データをレポジトリに格納するステップと、前記収集されたトレース・データを分析して前記ソフトウェア・アプリケーションを含むビジネス・プロセスに関連するリソースを発見し、前記発見されたリソースを含む論理アプリケーションを定義するステップと、グラフィカル・ユーザ・インタフェース（ＧＵＩ）を介してユーザと対話し、アプリケーション・プログラミング・インタフェース（ＡＰＩ）を介して他のソフトウェア・アプリケーションと対話するステップとをさらに含む、請求項１４ないし２３のいずれかに記載の方法。
【請求項２５】
前記論理アプリケーションにビジネス・レベル・ポリシーを適用する他のソフトウェア・アプリケーションに前記論理アプリケーションを提供するステップをさらに含む、請求項２４に記載の方法。
【請求項２６】
プログラムがコンピュータ上で実行されるときに、請求項１４ないし２５のいずれか一項に記載の全てのステップを実行するように構成されたプログラム・コード手段を含むコンピュータ・プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は企業向けコンピュータ・システムに関する。詳細には、本発明はビジネス・プロセスで使用されるリソースを自動的に発見し分類するための装置、システム、および方法に関する。
【背景技術】
【０００２】
コンピュータおよび情報技術は、その機能および複雑さにおいて進展と成長を続けている。詳細には、ソフトウェア・アプリケーションは、単一のモノリシック・プログラムから、単一のマシン上またはネットワーク上に分散された多数のコンピュータ・システム上で実行することができる数百から数千のオブジェクト指向コンポーネントに発展してきた。
【０００３】
コンピュータ・ソフトウェアおよびそれに関連するデータは一般に、ファイルなど何らかのフォーマットに従って構成された永続記憶装置に格納される。一般に、ファイルは直接アクセス記憶装置（ＤＡＳＤ、すなわち、いくつかのハード・ディスク）などの永続記憶装置に格納される。大規模データベース管理システムでさえ、何らかの形のファイルを使用してデータ、および場合によってはデータベース管理システムを実行するためのオブジェクト・コードを格納する。
【０００４】
事業主、経営幹部、経営者、管理者などは、費用効果の高い効率的な方法で製品またはサービス、あるいはその両方を提供することに専念する。これらの事業経営者は、ソフトウェア・アプリケーションが提供できる効率および利点を認識している。したがって、事業経営者は、事業が市場における競争力を維持することを保証するために、長期計画や方針決定にビジネス・ソフトウェア・アプリケーションを織り込む。
【０００５】
事業経営者らは、ソフトウェア・アプリケーションを定義するアーキテクチャやファイルなどの詳細に関心があるのではなく、ビジネス・プロセスに関心がある。ビジネス・プロセスは、事業によって提供される内部および外部サービスである。これらのビジネス・プロセスはますます、少なくとも部分的には１つまたは複数のソフトウェア・アプリケーションによって提供されるようになってきた。ビジネス・プロセスの一例は、従業員間の内部通信である。このビジネス・プロセスは、主に電子メール・ソフトウェア・アプリケーションによって実行されることが多い。電子メール・ソフトウェア・アプリケーションは、クライアント、サーバ、データベース管理システム（ＤＢＭＳ）など複数の個別に実行可能なソフトウェア・コンポーネントを含むことができる。
【０００６】
一般に、事業経営者は、どのようにビジネス・プロセスが実行されるかについての分かりにくく複雑な詳細に取り組むのではなくビジネス・プロセスに注目することにより、最も効果的に管理し指揮することができる。残念なことに、ビジネス・プロセス・ポリシーとその実行の間の関係は、特に大企業では不明確なことが多い。したがって、ビジネス・プロセス・ポリシーによって課される負担と期待される利益とを正確に比較することができるように、ビジネス・ポリシーの影響を調査し、明らかにする必要がある。このことは、ビジネス・ポリシーによって影響を受けるコンピュータ・システム、ファイル、およびサービスを識別しなければならないことを意味する場合がある。
【０００７】
図１は、ビジネス・プロセスを実装するための従来のシステム１００を示す。ビジネス・プロセスはどのようなビジネス・プロセスでもよい。ソフトウェア・アプリケーションを大量に利用するビジネス・プロセスの例には、自動応答電話システムまたはインターネット小売販売システム（ウェブ・ストアフロント）あるいはその両方、電子メール・システム、在庫管理システム、組立ライン制御システムなどがある。
【０００８】
一般に、ビジネス・プロセスは単純かつ明確に定義される。しかし、ビジネス・プロセスは、様々なベンダからの様々な実行可能ファイル、データ・ファイル、クライアント、サーバ、エージェント、デーモン／サービスなど多様な協働するソフトウェア・アプリケーションを使用して実行されることが多い。これらのソフトウェア・アプリケーションは一般に、複数のコンピュータ・プラットフォームに分散される。
【０００９】
例示のシステム１００にはＥコマース・ウェブサイトが示されており、クライアント１０２、ウェブ・サーバ１０４、アプリケーション・サーバ１０６、およびＤＢＭＳ１０８上で動作する各コンポーネントが示されている。システム１００の要件を満たすために、開発者は、ウェブ・サーバ１０４によって提供されるサーブレット１１０やアプレット１１２、アプリケーション・サーバ１０６上の１つまたは複数のビジネス・オブジェクト１１４、ならびにＤＢＭＳ１０８内の１つまたは複数のデータベース・テーブル１１６を作成する。これら個別のソフトウェア・コンポーネントは、連携しながらＥコマース・ウェブサイトを提供する。
【００１０】
上述のように、各ソフトウェア・コンポーネントは、実行可能なオブジェクト・コードを格納する１つまたは複数のファイル１１８からもたらされるか、またはそれらのファイル１１８を使用する。同様に、データ・ファイル１２０は、ソフトウェア・コンポーネントによって使用されるデータを格納する。データ・ファイル１２０は、構成設定、ユーザ・データ、システム・データ、データベース行や列などを格納することもできる。
【００１１】
同時に、これらのファイル１１８、１２０は、ビジネス・プロセスを実行するために必要なリソースを構成する。さらに、リソースは、グラフィカル・ユーザ・インタフェース（ＧＵＩ）のアイコンやグラフィックス、静的ウェブ・ページ、ウェブ・サービス、ウェブ・サーバ、汎用サーバ、およびＵＲＬ（Uniform Resource Locator）または他のアドレス指定方式を使用してアクセス可能な他の（ネットワーク化されたもしくは単独の）コンピュータ・システム上にある他のリソースを含むことができる。全体として、これら様々なリソースはすべて、ビジネス・プロセスのあらゆる態様を実装するために必要なものである。本明細書で使用される「リソース」とは、ビジネス・プロセスの諸機能を実行するための１つまたは複数のソフトウェア・アプリケーションおよびコンポーネントによって使用されるオブジェクト・コードまたはデータを含むすべてのファイルならびにソフトウェア・モジュールを意味する。
【００１２】
一般に、各ファイル１１８、１２０は、物理または仮想のデバイスまたはボリュームによって識別される記憶装置１２２ａ上に格納される。ファイル１１８、１２０は、各プラットフォーム１０４、１０６、１０８に対応する個別のファイル・システム（ＦＳ）１２４ａ〜ｃによって管理される。
【００１３】
経営者が、Ｅコマース・ウェブサイトに関するビジネス・レベル・ポリシー１２６を導入しようとしていると想定する。ポリシー１２６は、単に「週に１回、Ｅコマース・サイトをバックアップする」と述べるだけでもよい。もちろん、Ｅコマース・ウェブサイトに関して、他のビジネス・レベル・ポリシーを導入することもできる。例えば、負荷バランス・ポリシー、ソフトウェア移行ポリシー、ソフトウェア更新ポリシー、および他の同様のビジネス・ポリシーなどは、ビジネス・プロセス・レベルで各ビジネス・プロセスに対して定義することができる。
【００１４】
このようなビジネス・レベル・ポリシーは、明確かつ簡潔である。しかし、これらのポリシーの実行は、非常に労働集約的であり、間違いを生じやすく、かつ困難なことがあり得る。一般に、バックアップ・ポリシー１２６を実行するためには、２つの方法が存在する。第１の方法は、各デバイスまたはボリューム１２２ａ〜ｃ上のすべてのデータをバックアップすることである。しかし、このような方法は、デバイス１２２ａ〜ｃが複数のビジネス・プロセス間で共有されているときには、特定のビジネス・プロセスに関係のないファイルまでバックアップすることになる。いくつかの他のビジネス・ポリシーでは、ボリューム１２２ａ〜ｃ上にある他のビジネス・プロセスに関係する他のファイルのために、より頻繁なバックアップを必要とすることもある。その結果、ポリシーが競合し、無用なバックアップ記憶空間または複製バックアップ・データ、あるいはその両方が生じる可能性がある。さらに、デバイス１２２ａ〜ｃのフル・コピーを実行するのに必要な時間のため、他のビジネス・プロセスが妨げられ、プロセスが不必要に引き延ばされることもあり得る。
【００１５】
第２の方法は、デバイス１２２ａ〜ｃ上のどのファイルがビジネス・プロセスで使用されるか、またはそのビジネス・プロセスに関連しているか、またはそのビジネス・プロセスを含むかを識別する方法である。残念ながら、あるビジネス・プロセス、特に複数のシステム上に分散されたビジネス・プロセスで使用されるすべてのリソースを特定する自動のプロセスは存在しない。この手動のプロセスを支援するために、いくつかの論理的なルールを定義することができる。しかし、このようなルールは、その機能が固定でありかつ限定されていることが多く、正確にすべてのリソースを識別することはできない。例えば、このようなルールは、ビジネス・プロセスのめったに使用されない機能を実行する間の、ＵＲＬを用いたリモート・サーバ上のファイルへの参照を見逃す可能性が高い。あるいは、デバイス１２２ａ〜ｃは、特定のプロセスのためのソフトウェアおよびデータ・ファイル専用とすることもできる。しかし、この方法では、デバイス１２２ａ〜ｃ上に無駄な不使用空間が生じることがあり、分散システムではうまく使用できないこともある。
【００１６】
一般に、コンピュータ・システムの管理者は、ビジネス・レベル・ポリシー１２６を解釈し、そのポリシー１２６を実行するためにどのファイル１１８、１２０を含めるべきかを決定しなければならない。管理者は、様々なファイル・システム１２４ａ〜ｃを閲覧し、ユーザ・マニュアルを参照し、レジストリ・データベースを検索し、さらに管理者自身の経験および知識を利用して適切なファイル１１８，１２０のリストを生成することができる。
【００１７】
図１において、一実装１２８は、この手動の労働集約的で退屈なプロセスの結果を示す。このようなプロセスは、最初にリストを作成するためだけではなく、ビジネス・プロセスの様々なソフトウェア・コンポーネントが更新され修正されたときに絶えずリストを維持するためにも時間が必要なので、非常にコストがかかるものになる。さらに、手動のプロセスは、人為ミスの影響を受けやすい。管理者は、意図せずにいくつかのファイル１１８、１２０を除外してしまう可能性がある。
【００１８】
実装１２８は、オブジェクト・コード・ファイル１１８（すなわち、実行可能ファイルとも呼ばれるe-commerce.exe）およびデータ・ファイル１２０（すなわち、e-comdata1.db）の両方を含む。しかし、プロセスが手動であることおよび記憶空間の問題により、作業は、データ・ファイル１２０およびデータ特有のリソースに集中することができる。データ・ファイル１２０はさらに、データベース・ファイルなど非常に重要なデータ・ファイル１２０だけに限定することができる。したがって、実行可能ファイル、ユーザ構成ファイル、システム固有の設定ファイルなど他の重要なファイルは、実装１２８に含まれないことがある。あるいは、ワード・プロセッシング文書などのユーザ・データもまた除外されることがある。なぜならば、このようなデータはデバイス１２２ａ〜ｃ上の未知の位置または予測不能の位置に格納されるからである。
【００１９】
ビジネス・プロセスによって使用されるリソースを分類するための他の解決策には制限がある。１つの解決策は、インストールされる各アプリケーションに対して、そのアプリケーションがどのリソースを使用するかを中央レポジトリに通知することである。しかし、この解決策は、ソフトウェア・アプリケーションを作成し維持する開発者に、リソースを追跡しリストアップするという負担をかけることになる。この場合もやはり、開発者がいくつかのファイルをうっかりと除外する可能性がある。さらに、このような通知は一般に、インストールの間だけに行われる。したがって、その後に生成されるデータ・ファイルは、デバイス１２２ａ〜ｃ上の予測不能な位置に格納される可能性がある。
【００２０】
前述の議論から、ビジネス・プロセスによって使用されるファイルや他のリソースを自動的に発見し分類する装置、システム、および方法が必要とされていることは明白である。有利には、このような装置、システム、および方法は、ビジネス・レベル・ポリシーをビジネス・プロセスの全体に適用することができるように、ビジネス・プロセスによって使用されるほぼすべてのリソースを自動的に発見する。さらに、この装置、システム、および方法は、すべての適切なリソースが含まれることを保証するために、ヒューリスティック・ルーチンを適用する。さらに、あるビジネス・プロセスに関連すると識別された１組のリソースは、長期にわたるユーザ・ニーズやシステムの変更に対応するために修正可能である。
【発明の開示】
【発明が解決しようとする課題】
【００２１】
本発明は当技術分野の現状に対応して開発されたものであり、詳細には、ビジネス・プロセスによって使用されるファイルおよび他のリソースを自動的に発見し分類するための、まだ対処されていない当技術分野の問題およびニーズに対応して開発されたものである。したがって、本発明は、ビジネス・プロセスによって使用されるリソースを自動的に発見し分類するための装置、システム、および方法を提供するために開発されたものであり、当技術分野における上述の欠点の多くまたは全てを克服するものである。
【課題を解決するための手段】
【００２２】
第１の態様によれば、本発明は、ビジネス・プロセスによって使用されるリソースを自動的に発見し分類するための装置を提供する。この装置は、ソフトウェア・アプリケーションの動作挙動を表すトレース・データを収集するように構成可能な監視モジュールと、トレース・データを分析して少なくとも１つのソフトウェア・アプリケーションを含むビジネス・プロセスに関連するリソースを発見するように構成可能な分析モジュールと、発見されたリソースを含む論理アプリケーションを定義するように構成可能な決定モジュールとを含む。
【００２３】
第２の態様によれば、本発明は、ビジネス・プロセスによって使用されるリソースを自動的に発見し分類するためのシステムを提供する。このシステムは、プロセッサの実行を管理するように構成可能なオペレーティング・システムと、動作中のプロセスに関する情報を提供するように構成可能なプロセス・マネージャと、ファイル活動情報を提供するように構成可能な入出力（Ｉ／Ｏ）モジュールと、記憶装置に格納されたファイルを管理し、それらのファイルに関するメタデータを提供するように構成可能なファイル・システムと、オペレーティング・システムの内部で、少なくとも１つのソフトウェア・アプリケーション実行中のトレース・データを収集するように構成可能な監視モジュールであって、プロセス・マネージャ、Ｉ／Ｏモジュール、およびファイル・システムの少なくとも１つと対話して上記ソフトウェア・アプリケーションの動作に直接関係するトレース・データを収集する監視モジュールと、トレース・データを分析して上記ソフトウェア・アプリケーションを含むビジネス・プロセスに関連するリソースを発見し、発見されたリソースを含む論理アプリケーションを定義するように構成可能な分析モジュールとを含む。
【００２４】
第３の態様によれば、本発明はビジネス・プロセスによって使用されるリソースを自動的に発見し分類するための方法を提供する。この方法は、ソフトウェア・アプリケーションの動作挙動を表すトレース・データを収集するステップと、トレース・データを分析して少なくとも１つのソフトウェア・アプリケーションを含むビジネス・プロセスに関係するリソースを発見するステップと、発見されたリソースを含む論理アプリケーションを定義するステップとを含む。
【００２５】
第４の態様によれば、本発明はコンピュータ・プログラムを提供する。このコンピュータ・プログラムは、コンピュータ上で実行されるときに、ビジネス・プロセスによって使用されるリソースを自動的に発見し分類するための方法のステップを実行するように構成されたプログラム・コード手段を含む。
【００２６】
本発明による装置は、監視モジュール、分析モジュール、および決定モジュールを含む。監視モジュールは、ビジネス・プロセスに含まれる１つまたは複数のソフトウェア・アプリケーションの動作挙動を表すトレース・データを収集する。ソフトウェア・アプリケーションの実行中に収集できるトレース・データもあれば、ソフトウェア・アプリケーションが実行されているかどうかとは無関係に収集できるトレース・データもある。一実施形態では、監視モジュールは、コンピュータ・システムのすべてのソフトウェア・アプリケーションに関するトレース・データを収集する。
【００２７】
分析モジュールは、トレース・データを分析してビジネス・プロセスに関連するリソースを発見する。好ましくは、分析モジュールは、１つまたは複数のヒューリスティック・ルーチンを適用してリソースとビジネス・プロセスの間の直接および間接の関係を識別する。決定モジュールは、発見されたリソースを含む論理アプリケーションを定義する。好ましくは、論理アプリケーションはビジネス・プロセスに直接対応する。本明細書で使用される「論理アプリケーション」とは、ビジネス・プロセスに対して定義されたビジネス・レベルのサービスを提供するために必要な、すべてのファイルのセットおよび他のリソースを意味する。「アプリケーション」と結合された「論理的な」という用語は、単一のコンピュータ・システム内のソフトウェア・アプリケーションまたは複数のコンピュータ・システムに分散されたソフトウェア・アプリケーション、あるいはその両方を含むことが意図される。ただし、この解釈に限定されるものではない。一実施形態では、分析モジュールおよび決定モジュールは論理アプリケーション上で繰り返し動作して、適切なファイルのすべてが論理アプリケーションに含まれることを保証する。
【００２８】
いくつかの実施形態では、ビジネス・プロセスは、ソフトウェア・アプリケーションの識別子または特性によって識別される。識別子または特性は、インタフェースを介して提供することができる。識別子は、実行可能ファイルまたはデータ・ファイルの名前、動作プロセスの名前などを含むことができる。特性は、ソフトウェア・アプリケーションによって実行される周知の機能を含むことができる。好ましくは、機能は個々のビジネス・プロセスに特有のものである。例えば、ソフトウェア・アプリケーションは、特定のサーバまたはソフトウェア・モジュールと通信するために、周知のポート番号を使用してネットワーク通信を実行することができる。好ましくは、識別子または特性は、個々のビジネス・プロセスに対して一意であり、明確に定義可能である。
【００２９】
一実施形態では、監視モジュールおよび分析モジュールは、ある論理アプリケーションに属することがすでに識別されているリソースに関する情報を使用する。したがって、監視モジュールおよび分析モジュールは、識別子またはすでに識別されているリソースに関する情報、あるいはその両方を使用して、追加のリソースを繰り返し識別することができる。定義の後で、論理アプリケーションを管理モジュールに提供することができる。管理モジュールは、その論理アプリケーションにビジネス・レベル・ポリシーを適用する。
【００３０】
監視モジュールは、１つまたは複数の活動モニタを開始する起動モジュールを含むことができる。活動モニタは、リソースに関係する特定の種類の活動を追跡することができる。活動モニタは、ビジネス・プロセスの実行とは独立に、または同時に動作させることができる。監視モジュール内のコントローラは、活動モニタを制御することができる。監視モジュール内の記憶モジュールは、リソースに関する特定の種類の活動を記述するトレース・データを格納することができる。一実施形態では、監視モジュールは、ビジネス・プロセスによる特定の種類の活動を記述するトレース・データを求めてシステム情報をスキャンするスキャナを含む。監視モジュールは、分析モジュールと同時に、または別々に動作させることができる。
【００３１】
分析モジュールは、クエリ・モジュール、評価モジュール、および発見モジュールを含むことができる。一実施形態では、クエリ・モジュールは、一部には識別子に基づいてトレース・データをフィルタリングして結果セットを生成することができる。評価モジュールは、結果セットに１つまたは複数のヒューリスティック・ルーチンを適用して、識別子に関連する１つまたは複数のリソースを発見することができる。発見モジュールは、１つまたは複数のヒューリスティック・ルーチンの適用に応答して、１つまたは複数のリソースを発見する。
【００３２】
ビジネス・プロセスによって使用されるリソースを自動的に発見し分類するために、本発明による方法も提供される。一実施形態では、この方法は、ビジネス・プロセスに関する識別子を受け取るステップを含む。識別子は、ビジネス・プロセスを実行するリソースに直接関係する。次に、リソースに関係するトレース・データが収集され、ビジネス・プロセスを実行する１つまたは複数のソフトウェア・コンポーネントによって実行される動作を表す。あるいは、トレース・データは、コンピュータ・システムのリソースに関連するすべての動作について収集することもできる。トレース・データを分析して、（データ・マイニングと呼ばれるように）識別子に関連する１つまたは複数のリソースを発見する。最後に、１つまたは複数の発見されたリソースを含む論理アプリケーションが定義される。
【００３３】
本発明は、ビジネス・プロセスに対応する論理アプリケーションに関連して説明されるが、論理アプリケーションはビジネス・プロセスに限定されるものではないことに留意されたい。論理アプリケーションは、悪意のない（benign）目的または悪意のある（malicious）目的で使用されるソフトウェア・リソースの任意のセットに対応させることができる。例えば、本発明を使用して、スパイウェア、アドウェア、ウィルス、その他のソフトウェア・アプリケーションを定義する論理アプリケーションを識別することができる。本発明は、どのソフトウェア・リソースが使用されているのかを隠蔽しようするソフトウェア・アプリケーションのための論理アプリケーションを定義する際に特に有用なことがある。さらに、ビジネス・プロセスは、単一のソフトウェア・アプリケーションに対応させることもできる。
【００３４】
好ましくは、ビジネス・プロセスは、ユーザによって提供された、そのビジネス・プロセスのための識別子によって識別される。より好ましくは、ビジネス・レベル・ポリシーは、負荷バランス・ポリシー、ソフトウェア移行ポリシー、およびバックアップ・ポリシーを含むグループから選択されたポリシーである。さらに好ましくは、システム情報は、ファイル・システム情報、プロセス情報、ネットワーク情報、および入／出力（Ｉ／Ｏ）情報を含むグループから選択される。
【００３５】
好ましい実施形態では、システムはさらに、ユーザからビジネス・プロセスに関する識別子を受け取り、論理アプリケーションをユーザに提供するように構成されたグラフィカル・ユーザ・インタフェース（ＧＵＩ）を含む。好ましくは、監視モジュールはさらに、プロセス・モニタ、Ｉ／Ｏモニタ、ネットワーク・モニタ、およびファイル・システム・モニタを含む。より好ましくは、監視モジュールはさらに、複数のファイル・システムと対話するように構成される。さらに好ましくは、分析モジュールは、マークアップ言語データ構造内に論理アプリケーションを定義する。さらに好ましくは、発見されるリソースは、データ・ファイル、実行可能ファイル、およびサービス・アプリケーションを含むグループから選択されるリソースである。
【００３６】
本発明はまた、装置および方法に関連して上述したコンポーネントおよびステップと実質的に同一の機能を含むシステム、コンピュータ可読コード、および装置として構成された諸実施形態も含む。本発明の機能および利点は、以下の説明および添付の特許請求の範囲からより完全に明らかになるはずである。あるいは、本発明の機能および利点は、以下で説明する本発明を実践することによっても理解できるはずである。
【００３７】
本発明の利点が容易に理解されるように、上で概説した本発明のより詳細な説明は、添付の図面に示された具体的な実施形態を参照することによってなされる。これらの図面は本発明の代表的な実施形態を示したものに過ぎず、したがって本発明の範囲を限定するものと見なすべきではないこと、および添付の図面の使用により、本発明がより具体的かつ詳細に記述され説明されることを理解されたい。
【発明を実施するための最良の形態】
【００３８】
先に概説し本明細書の各図に示した本発明の各コンポーネントが多種多様な構成で配置し設計できることは、容易に理解されるであろう。したがって、各図に示された、本発明の装置、システム、および方法の諸実施形態についての以下のより詳細な説明は、特許請求の範囲に示された本発明の範囲を限定することを意図したものではなく、単に本発明の選択された実施形態を表したものである。
【００３９】
本明細書に記載された機能ユニットの多くは、特にそれらの実装の独立性をより強調するためにモジュールに分類されている。例えば、モジュールは、カスタムＶＬＳＩ回路またはゲート・アレイ、ならびに論理チップ、トランジスタ、または他のディスクリート部品など市販の半導体部品を含むハードウェア回路として実装することができる。モジュールはまた、ＦＰＧＡ（field programmable gate array）、ＰＡＬ（programmable array logic）、ＰＬＤ（programmablelogic device）などのプログラマブル・ハードウェア・デバイスの形で実装することもできる。
【００４０】
モジュールはさらに、様々な種類のプロセッサによって実行されるソフトウェアの形で実装することもできる。実行可能コードからなる識別されたモジュールは、例えばオブジェクト、プロシージャ、関数、その他の構成体として構成できる、コンピュータ命令からなる１つまたは複数の物理または論理ブロックを含むことができる。それにもかかわらず、識別されたモジュールの実行可能コードは物理的に同じ位置に配置する必要はなく、様々な位置に格納された異種の命令を含むことができる。これらの命令は、論理的に結合されたときにモジュールを構成し、モジュールの指示された目的を達成する。
【００４１】
実際、実行可能コードからなるモジュールは、単一の命令でも複数の命令でもよく、いくつかの異なるコード・セグメント上に、また様々なプログラム間に、またいくつかのメモリ素子にわたって分散させることができる。同様に、動作データを識別することもできる。動作データは、本明細書ではモジュールの内部に示されており、任意の適切な形式で実施すること、および任意の適切な種類のデータ構造内に構成することができる。動作データは、単一のデータ・セットとしてまとめることもできるし、様々な記憶装置上など様々な位置に分散させることもできる。また、動作データは、少なくともその一部は、システムまたはネットワーク上の単なる電子信号として存在することができる。
【００４２】
本明細書を通して、「選択された実施形態」、「一実施形態」、または「ある実施形態」とは、その実施形態に関連して記載された特定の機能、構造、または特性が、本発明の少なくとも１つの実施形態に含まれることを意味する。したがって、本明細書中の様々な場所に現れる「選択された実施形態において」、「一実施形態において」、または「ある実施形態において」という表現は、必ずしもすべて同一の実施形態に言及しているわけではない。
【００４３】
さらに、記載した機能、構造、または特性は、１つまたは複数の実施形態において任意の適切な方法で組み合わせることができる。以下の説明においては、本発明の諸実施形態についての十分な理解が得られるように、プログラム、ソフトウェア・モジュール、ユーザ選択、ユーザ・インタフェース、ネットワーク・トランザクション、データベース・クエリ、データベース構造、ハードウェア・モジュール、ハードウェア回路、ハードウェア・チップの例など、多くの個別の詳細が示されている。しかし、当業者ならば、本発明が、１つまたは複数の個別の詳細を用いることなしに実施できること、すなわち他の方法、コンポーネント、材料などを用いて実施できることが理解されよう。場合によっては、本発明の諸態様が曖昧になるのを避けるために、周知の構造、材料、または動作については図示していないか、または詳細には説明していない。
【００４４】
本発明の例示した実施形態は、図面を参照することによって最もよく理解できるはずである。全図面を通して、類似の部品には類似の番号が付されている。以下の説明は、例示のためだけのものであり、本明細書で主張する本発明に適合する装置、システム、およびプロセスについてのいくつかの選択された実施形態を示すことだけを意図したものである。
【００４５】
図２は、ビジネス・プロセスに対応させることができる論理アプリケーションによって使用されるファイルを自動的に発見し分類するように構成された装置２００の論理構成図を示す。ビジネス・プロセスは、協働して所望のビジネス・サービス（すなわち、電子メール・サービス、小売用ウェブ・ストアフロント、在庫管理など）を提供するように構成された様々なハードウェア・コンポーネントやソフトウェア・コンポーネントによって実行することができる。図面を見やすくするために、いくつかの周知のハードウェア・コンポーネントおよびソフトウェア・コンポーネントは、図２から省略されている。
【００４６】
装置２００はオペレーティング・システム２０２を含むことができる。オペレーティング・システム２０２は、ファイルＩ／Ｏモジュール２０４、ネットワークＩ／Ｏモジュール２０６、およびプロセス・マネージャ２０８によって一般的なコンピューティング・サービスを提供する。ファイルＩ／Ｏモジュール２０４は、ハード・ディスクなどの記憶装置２１２上に格納されたファイル２１０との間の低レベルのデータ読出しおよび書込みを管理する。もちろん、記憶装置２１２は、様々な種類のＤＡＳＤシステムなどの記憶サブシステムを含むこともできる。ネットワーク・モジュール２０６は、装置２００上で動作中のプロセス２１４ａ〜ｃと、ネットワークを介してアクセス可能な外部コンピュータ・システム（図示せず）との間のネットワーク通信を管理する。好ましくは、ファイルＩ／Ｏモジュール２０４およびネットワーク・モジュール２０６は、すべてのプロセス２１４ａ〜ｃによって使用されるようにオペレーティング・システム２０２によって提供される。あるいは、カスタムのファイルＩ／Ｏモジュール２０４およびネットワーク・モジュール２０６を作成することもできる。その場合、オペレーティング・システム２０２は、これらのモジュールを提供しないことになる。
【００４７】
オペレーティング・システム２０２は、プロセス２１４ａ〜ｃによる１つまたは複数のプロセッサ（図示せず）の使用をスケジューリングするプロセス・マネージャ２０８を含む。プロセス・マネージャ２０８は、プロセス２１４ａ〜ｃの実行に関するいくつかの情報を含む。一実施形態では、情報は、プロセスＩＤ、プロセス名、プロセス所有者（プロセスを開始したユーザ）、プロセス関係（あるプロセスが他の実行中のプロセスとどのように関係するか、すなわち子プロセス、親プロセス、兄弟プロセス）、使用中の他のリソース（オープン・ファイルまたはネットワーク・ポート）などを含む。
【００４８】
一般に、ビジネス・プロセスは、１つまたは複数の現在動作中のプロセス２１４ａ〜ｃによって定義される。各プロセス２１４ａ〜ｃは実行可能なファイル２１０、またはプロセス２１４ａ〜ｃを最初に生成した親プロセスを含む。プロセス・マネージャ２０８により提供される情報によって、動作中のプロセス２１４ａ〜ｃに対する元のファイル２１０の識別が可能になる。このことについては、以下でより詳細に論ずる。
【００４９】
いくつかの実施形態では、装置２００は、監視モジュール２１６、分析モジュール２１８、および決定モジュール２２０を含む。これらのモジュール２１６、２１８、２２０は協働して、ビジネス・プロセスに対応する論理アプリケーションを構成するリソースを動的に識別する。一般に、これらのリソースはファイル２１０である。あるいは、リソースは、ＵＲＬまたはＩＰアドレスなどのネットワーク・アドレスによって識別可能な他のソフトウェア・リソース（サーバ、デーモンなど）でもよい。
【００５０】
このように、論理アプリケーション（ビジネス・プロセス）に関するファイル２１０および他のリソースについての動作は、それらのリソースを手動で識別するという退屈で、労働集約的で、エラーを生じやすい処理なしに実行することができる。これらの動作は、バックアップ、回復、サーバ負荷管理、移行に対するポリシーなどのビジネス・レベル・ポリシーの実行を含む。
【００５１】
監視モジュール２１６は、プロセス・マネージャ２０８、ファイルＩ／Ｏモジュール２０４、およびネットワークＩ／Ｏモジュール２０６と通信してトレース・データを収集する。トレース・データとは、ソフトウェア・アプリケーションの動作挙動を示す任意のデータのことである（本明細書で使用される「アプリケーション」は単一のプロセスのことであり、「論理アプリケーション」は共にビジネス・プロセスを実行する１つまたは複数のプロセスの集りのことである）。トレース・データは、ソフトウェア・アプリケーションの実行中、またはソフトウェア・アプリケーションの最初の実行の後の、どちらででも識別可能である。トレース・データによっては、ソフトウェア・アプリケーションの最初のインストールの後に識別可能になるものもある。例えば、インストール・プログラムと呼ばれるソフトウェア・アプリケーションは、特定のディレクトリに新しいファイルを生成するだけでトレース・データを生成することができる。
【００５２】
好ましくは、監視モジュール２１６は、すべてのプロセス２１４ａ〜ｃに対するトレース・データを収集する。一実施形態では、監視モジュール２１６は、ビジネス・プロセスを実行するリソースに直接関係することが知られている識別子に基づいてトレース・データを収集する（このことは、以下でより詳細に論じる）。あるいは、監視モジュール２１６は、識別子に基づいて区別することなしに、装置２００のすべてのリソースに対するトレース・データを収集することもできる。
【００５３】
一実施形態では、監視モジュール２１６は、プロセス・マネージャ２０８と通信して現在動作中のプロセス２１４ａ〜ｃに関するトレース・データを収集する。収集されたトレース・データは、特定の時点で動作中のプロセス２１４ａ〜ｃを表す。動作中のプロセス２１４ａ〜ｃのセットは比較的頻繁に変化する可能性があるので、監視モジュール２１６は、プロセス・マネージャ２０８から定期的にトレース・データを収集することもできる。好ましくは、ユーザ設定可能な設定によって、監視モジュール２１６がプロセス・マネージャ２０８からいつトレース・データを収集するかを決定する。
【００５４】
監視モジュール２１６はまた、ファイルＩ／Ｏモジュール２０４およびネットワーク・モジュール２０６とも通信してトレース・データを収集する。ファイルＩ／Ｏモジュール２０４は、読出し、書込み、更新などのファイル・アクセス動作に関する情報を維持する。このファイルＩ／Ｏモジュール２０４から、監視モジュール２１６は、プロセス２１４ａ〜ｃの現在の実行およびプロセス２１４ａ〜ｃの動作履歴に関するトレース・データを収集する。
【００５５】
ファイルＩ／Ｏモジュール２０４から収集されたトレース・データは、ファイル名、ファイル・ディレクトリ構造、ファイル・サイズ、ファイル所有者／作成者、ファイル・アクセス権、ファイル作成日、ファイル修正日、ファイル・タイプ、ファイル・アクセス・タイムスタンプ、実行されたファイル操作の種類（読出し、書込み、更新）などの情報を含むことができる。一実施形態では、監視モジュール２１６はまた、動作中のプロセス２１４ａ〜ｃによってどのファイル２１０が現在オープンされているかを特定することもできる。いくつかの実施形態においては、監視モジュール２１６は、複数の記憶装置２１２にわたって、１つまたは複数のファイル・システムに対するトレース・データをファイルＩ／Ｏモジュール２０４から収集する。
【００５６】
上述のように、監視モジュール２１６は、ファイル・システムのすべてのファイル２１０に関するトレース・データ、または明らかに識別子に関係するファイルおよびディレクトリだけに関するトレース・データを収集することができる。識別子または論理アプリケーションに現在含まれているリソース、あるいはその両方を使用して、ファイル・システムからどのトレース・データを収集するかを決定することができる。
【００５７】
監視モジュール２１６は、プロセス２１４ａ〜ｃによるネットワーク活動に関連するトレース・データを、ネットワークＩ／Ｏモジュール２０６から収集する。いくつかのネットワーク活動は、特定のプロセス２１４ａ〜ｃまたはファイル２１０、あるいはその両方と明確に関連づけることができる。好ましくは、ネットワークＩ／Ｏモジュール２０６は、１つまたは複数のプロセス２１４ａ〜ｃと特定のネットワーク活動を関連づけるトレース・データを提供する。ネットワーク活動を実施するプロセス２１４ａ〜ｃが識別され、それによってそのプロセス２１４ａ〜ｃを開始したリソースも識別される。
【００５８】
ネットワークＩ／Ｏモジュール２０６からのトレース・データは、ネットワーク通信を実施するための特定のポートをどのプロセス２１４ａ〜ｃがオープンしたのかを指示することができる。監視モジュール２１６は、標準のネットワーク通信を実行するためにプロセス２１４ａ〜ｃによって使用される既定ポートのトレース・データを収集することができる。トレース・データは、ポート番号およびそのポートをオープンしたプロセス２１４ａ〜ｃを識別することができる。単一の、一意のプロセスだけが特定のネットワーク・ポートを使用していることが多い。
【００５９】
例えば、ポート８０番を介した通信を使用して装置２００上のウェブ・サーバを識別することができる。トレース・データから、ウェブ・サーバ・プロセスおよび実行可能ファイルを識別することができる。他の既定ポートには、ＦＴＰデータのための２０番、ＦＴＰ制御メッセージのための２１番、テルネットのための２３番、ドメイン・ネーム・サーバのための５３番、ＰＯＰ３電子メールのための１１０番などがある。ＵＵＮＩＸ（登録商標）（ＵＵＮＩＸ（登録商標）は米国および他の諸国におけるオープン・グループ（The Open Group）の登録商標である）やＬＩＮＵＸ（Ｌｉｎｕｘは米国または他の諸国あるいはその両方におけるリーナス・トーバルズ（LinusTorvalds）氏の商標である）など、いくつかのオペレーティング・システム２０２では、ネットワークＩ／Ｏトレース・データは別個のディレクトリに格納される。他のオペレーティング・システム２０２では、トレース・データは、バックグラウンドで動作しネットワーク・ポートを管理するサービスまたはデーモンを使用して収集される。
【００６０】
一実施形態では、監視モジュール２１６は、プロセス・マネージャ２０８、ファイルＩ／Ｏモジュール２０４、およびネットワークＩ／Ｏモジュール２０６と自立的に通信してトレース・データを収集する。前述のように、監視モジュール２１６は、様々なユーザ設定可能な定期サイクルに従って様々な種類のトレース・データを収集することができる。トレース・データを収集しないときは、監視モジュール２１６は、トレース・データの収集を再開するための時間が来るまで動作中のプロセスとして「スリープ」することができる。あるいは、監視モジュール２１６は、ユーザ・コマンドまたは他のプロセスからのコマンドに応答して実行することもできる。
【００６１】
監視モジュール２１６はトレース・データを収集し、好ましくは、そのトレース・データを共通形式にフォーマットする。一実施形態では、形式は１つまたは複数のＸＭＬファイルである。トレース・データは、記憶装置２１２上に格納すること、または後の再調査のためのデータベースなど中央レポジトリに送信することができる。
【００６２】
分析モジュール２１８は、トレース・データを分析してビジネス・プロセスに関連するリソースを発見する。トレース・データはビジネス・プロセスを実行するソフトウェア・コンポーネントの動作に従って収集されるので、トレース・データは、ビジネス・プロセスのサービスを実行するために必要なリソースを直接または間接に識別するものである。ビジネス・プロセスを含むリソースを識別することによって、そのビジネス・プロセス全体に対するビジネス管理ポリシーを実行することができる。このようにして、ビジネス・ポリシーを実装することがより簡単になり、コスト効率がより高くなる。
【００６３】
一実施形態では、分析モジュール２１８は、ヒューリスティック・ルーチンを適用して、特定の論理アプリケーションとその論理アプリケーションによって表されるビジネス・プロセスにどのリソースが関係している可能性が最も高いかを決定する。ヒューリスティック・ルーチンについては以下でより詳細に論じる。いくつかのヒューリスティック・ルーチンは、リソースと論理アプリケーションの関係を他のものよりも確実に立証する。一実施形態では、ユーザは、候補リソースが論理アプリケーション内に含まれるかどうかを判定するために使用される信頼水準を調整することができる。この信頼水準は、各ヒューリスティック・ルーチンごとに個別に、または分析モジュール２１８の全体に、あるいはその両方に対して調整することができる。
【００６４】
分析モジュール２１８は、発見されたリソースを決定モジュール２２０に提供し、決定モジュール２２０は発見されたリソースを含む論理アプリケーションを定義する。好ましくは、決定モジュール２２０は、リスト、テーブル、ソフトウェア・オブジェクト、データベース、テキストＸＭＬ（eXtended Markup Language）ファイルなどの構造２２２を定義して、発見されたリソースと特定の論理アプリケーションの間の関係を記録する。上述のように、論理アプリケーションは、特定のビジネス・プロセスのすべての態様を実行するために必要なリソースの集りである。
【００６５】
構造２２２は、論理アプリケーションの名前、および発見されたすべてのリソースのリストを含む。好ましくは、そのリソースを用いてビジネス・ポリシーを実行することができるように、発見された各リソースに関する十分な属性が含まれる。リソースの名前、位置、種類などの属性が提供される。
【００６６】
さらに、構造２２２には、ビジネス・プロセスによってリソースがどの程度の頻度で使用されるかを示す頻度等級（frequency rating）を含めることができる。いくつかのビジネス・プロセスでは、この頻度等級によってリソースの重要性を示すことができる。さらに、分析モジュール２１８によって決定された信頼値は、各リソースごとに格納することもできる。
【００６７】
信頼水準は、そのリソースが所与の論理アプリケーションに適切に関連づけられることを、分析モジュール２１８がどの程度の確からしさで決定したかを示すことができる。一実施形態では、この信頼水準は確率パーセンテージで表される。いくつかのリソースについては、構造２２２は、ビジネス・プロセスによって使用されるリソースであるが、分析モジュール２１８が直接アクセスすることができないリソースを含む、ＵＲＬまたはサーバ・ネームなどの情報を含むことができる。
【００６８】
好ましくは、分析モジュール２１８は、決定モジュール２２０と協働して、ビジネス・プロセスに対する識別子に基づいて論理アプリケーションを定義する。このように、分析モジュール２１８は、識別子を用いてトレース・データをフィルタリングして、対象となるビジネス・プロセスに直接関係するリソースを含む可能性がより高いセットにすることができる。あるいは、分析モジュール２１８は、既定の識別子を使用せずに、ある種のルーチンまたはアルゴリズムを使用して、関係性を示す明白な証拠に基づいてトレース・データの全体からいくつかの論理アプリケーションを提案することもできる。
【００６９】
ユーザ・インタフェース（ＵＩ）２２４を提供して、ユーザが分析モジュール２１８に識別子を提供できるようにすることができる。識別子２２６は、実行可能ファイルまたはデータ・ファイルのファイル・ネーム、動作中のプロセスのファイル・ネームまたはプロセスＩＤ、ポート番号、ディレクトリなど、いくつかの種類の識別子のうちの１つを含むことができる。識別子２２６によって識別されるリソースは、識別子２２６によって識別されるリソースがデフォルトで論理アプリケーションに含まれ、トレース・データを検索することによって発見される追加のリソースを追加するために使用されるときは、論理アプリケーションに対するシード・リソース（seed resource）と見なすことができる。
【００７０】
例えば、ユーザは、どのプロセスがデータベース・ファイル「Users.db」にアクセスしたかに従って論理アプリケーションを作成したいと望む場合がある。ＵＩ２２４を用いて、ユーザはファイル名users.dbを入力する。次に、分析モジュール２１８は、users.dbファイルをオープンまたはクローズしたプロセスのトレース・データを検索する。識別されたいずれかの候補リソースにヒューリスティック・ルーチンが適用され、リソースの結果セットがＵＩ２２４を用いてユーザに提示される。
【００７１】
結果セットは、構造２２２に含まれるものと同じ情報を含む。ＵＩ２２４により、ユーザは、いくつかのリソースを追加または削除することによって、論理アプリケーションの内容を修正することもできる。次に、ユーザは、修正された論理アプリケーションを人間が読める形のＸＭＬ構造２２２に格納することができる。さらに、ユーザは、ヒューリスティック・ルーチンおよび分析モジュール２１８の全体に対する信頼水準を調整することができる。
【００７２】
このようにして、装置２００により、ビジネス・プロセスに対応する論理アプリケーションの作成が可能になる。論理アプリケーションは、バックアップ、回復、移行などのビジネス・レベル・ポリシーを容易に実行することができる十分に詳細なレベルにまで、ビジネス・プロセスを実行するリソースに関する情報を追跡する。さらに、論理アプリケーションの定義は、ビジネス・プロセスを実行するサブシステムが更新され、置換され、修正されたときに、容易に調整し適合させることができる。論理アプリケーションは、ビジネス・データ、およびそのビジネス・データを操作するプロセス／実行可能ファイルを追跡する。このようにして、ビジネス・データは、コストがかかる変換やデータ抽出手続きなしで、後の使用のために完全にアーカイブ化することができる。
【００７３】
図３は、本発明の一実施形態をより詳細に示す図である。この実施形態は、図２に示した装置２００と類似している。詳細には、図示の実施形態は、監視モジュール３０２、分析モジュール３０４、決定モジュール３０６、およびインタフェース３０８を含む。
【００７４】
一実施形態では、監視モジュール３０２は、ビジネス・プロセスの実行中にトレース・データ３１０を収集する。言い換えると、監視モジュール３０２は、ビジネス・プロセスを実行するアプリケーションの動作中にトレース・データを収集する。しかし、監視モジュール３０２はまた、ビジネス・プロセスが実行されていない／動作していないときに、十分なトレース・データ３１０を収集することもできる。さらに、インタフェース３０８は、ビジネス・プロセスを実行するリソースを直接ビジネス・プロセスに関連づける識別子を受け取ることもできる。好ましくは、識別子はビジネス・プロセスに対して一意である。ただし、一意性は、必ずしも必要とされないことがある。この識別子は、分析モジュール３０４によってトレース・データ３１０を分析するときに使用することができる。
【００７５】
監視モジュール３０２は、起動モジュール３１２、コントローラ３１４、記憶モジュール３１６、およびスキャナ３１８を含む。起動モジュール３１２は、１つまたは複数の活動モニタ３２０を開始する。起動モジュール３１２は、監視モジュール３０２が開始されたか、あるいは各活動モニタ３２０または監視モジュール３０２の全体に対して定義された監視スケジュールに従って定期的に起動されたときに、活動モニタ３２０を起動することができる。
【００７６】
活動モニタ３２０は、リソースに関する特定の種類の活動を追跡するように構成された、ソフトウェア関数、スレッド、またはアプリケーションである。活動モニタは、図２に関連して説明したプロセス・マネージャ２０８、ファイルＩ／Ｏモジュール２０４、およびネットワークＩ／Ｏモジュール２０６など他のモジュールからトレース・データを収集することにより、直接または間接に活動を監視することによってトレース・データを収集することができる。
【００７７】
一実施形態では、各活動モニタ３２０は、特定の種類の活動に対するトレース・データを収集する。例えば、ファイルＩ／Ｏ活動モニタ３２０は、ファイルＩ／Ｏモジュール２０４と通信し、あらゆるファイルＩ／Ｏ動作、ならびにどのプロセスがファイルＩ／Ｏ要求を行なったか、どのような種類の要求を行なったか、いつ行なったかなどの状況情報を取り込むことができる。もちろん、ビジネス・プロセスによって実行される活動の種類に応じて、様々な他の種類の活動モニタを開始することができる。いくつかの活動モニタはリモート・プロシージャ・コール（ＲＰＣ）を追跡することができる。
【００７８】
一実施形態では、コントローラ３１４は活動モニタ３２０の動作を制御する。コントローラ３１４は、監視されるシステムのプロセッサを使用するために、活動モニタのスケジューリングの優先度を調整することができる。このようにして、コントローラ３１４により、監視を継続することおよび必要に応じて監視の影響を動的に調整することが可能になる。全体のシステム性能に対するコントローラ３１４の制御および影響は、好ましくはユーザによる設定が可能である。
【００７９】
記憶モジュール３１６は、活動モニタ３２０と対話して各個別の活動モニタ３２０によって収集されたトレース・データを収集し格納する。いくつかの実施形態においては、活動モニタ３２０が特定の種類の活動を実施するリソース（実行可能ファイル、データ・ファイル、またはソフトウェア・モジュール）を検出したときに、活動モニタ３２０は、その活動特有のトレース・データを記憶モジュール３１６に提供して格納する。
【００８０】
記憶モジュール３１６は、トレース・データを格納する前に、そのトレース・データに一般的なファーマットや編成を実施することができる。好ましくは、すべての活動モニタ３２０に対するトレース・データは、データベースまたはログ／トレース・ファイルなど中央レポジトリに格納される。
【００８１】
一般に、活動モニタ３２０は、ビジネス・プロセスの動作中に実行される動的活動を監視するが、スキャナ３１８は、ファイル・システム情報、プロセス情報、ネットワーク情報、Ｉ／Ｏ情報などの比較的静的なシステム情報からトレース・データを収集する。スキャナ３１８は、ビジネス・プロセスによって実行される特定の種類の活動を求めてシステム情報をスキャンする。
【００８２】
例えば、スキャナ３１８は、特定のリソースによって作成され／所有されるファイルを求めて１つまたは複数のファイル・システム・ディレクトリをスキャンすることができる。リソースは、ビジネス・プロセスを実行する論理アプリケーション３１９にそのリソースが属していることが分かるように、識別子によって名前を付けることができる。したがって、スキャナ３１８は、見つかった任意のトレース・データを記憶モジュール３１６に提供して格納することができる。
【００８３】
一実施形態では、監視モジュール３０２は、１組または１バッチ分のトレース・データ３１０を生成し、そのデータを分析モジュール３０４が後の時点で調査する（バッチ・モード）。あるいは、監視モジュール３０２がトレース・データ３１０のストリームを分析モジュール３０４に提供し、分析モジュール３０４が、トレース・データ３１０が提供された時点でそのトレース・データ３１０を分析することもできる（ストリーミング・モード）。どちらのモードも本発明の範囲に含まれるものと見なされる。
【００８４】
分析モジュール３０４は、クエリ・モジュール３２２、評価モジュール３２４、発見モジュール３２６、および修正モジュール３２８を含むことができる。評価モジュール３２４と発見モジュール３２６は、密接に連携して論理アプリケーション３１９に関連づけられる候補リソースを識別する。
【００８５】
評価モジュール３２４は、１つまたは複数のヒューリスティック・ルーチン３３０ａ〜ｆを１組のトレース・データ３１０に適用する。好ましくは、クエリ・モジュール３２２は、トレース・データ３１０をフィルタリングしてより小さな結果セットを生成する。あるいは、ヒューリスティック・ルーチン３３０ａ〜ｆは、使用可能なすべてのトレース・データ３１０に適用される。
【００８６】
フィルタリングには、ビジネス・プロセスに直接関係する識別子を含めることができる。識別子は、ファイル名などのリソース名でもよい。あるいは、フィルタリングを時間、活動種類、または他の適切な基準に基づいて実施して、トレース・データ３１０のサイズを削減することもできる。フィルタリングは一般的なものでも、特定のヒューリスティック・ルーチン３３０ａ〜ｆの固有の要件に基づくものでもよい。
【００８７】
一実施形態では、評価モジュール３２４は、識別子に基づいてヒューリスティック・ルーチン３３０ａ〜ｆを適用する。識別子は、トレース・データの分析を実施するための起点を提供する。一実施形態では、ビジネス・プロセスに関係することが知られている識別子は、対応する論理アプリケーション３１９に自動的に関係づけられる。識別子は、他のどのリソースが、やはりその論理アプリケーション３１９に関係しているかを特定するためのシード（seed）になる。識別子は、特定のビジネス・プロセスに関係することが知られている主要な実行可能ファイルのファイル名でもよい。
【００８８】
各ヒューリスティック・ルーチン３３０ａ〜ｆは、識別子、または識別子によって示されるソフトウェア・アプリケーションの特性に基づいてトレース・データを分析する。例えば、特性には、このソフトウェア・アプリケーションが常にポート８０番を介してネットワークＩ／Ｏを実行するという事実を含めることができる。識別子の例は、在庫管理システムが開始されるときに起動される最初のアプリケーションであるinventorystartup.exeなどである。
【００８９】
各ヒューリスティック・ルーチン３３０ａ〜ｆは、論理アプリケーション３１９のメンバに関係するトレース・データを分析することができる。ヒューリスティック・ルーチン３３０ａ〜ｆは、論理アプリケーション３１９のメンバを使用してトレース・データ３１０を調査するアルゴリズムである。ヒューリスティック・ルーチン３３０ａ〜ｆは、トレース・データ３１０が候補リソースと論理アプリケーション３１９のメンバとの間の関係の可能性を指示するような候補リソースを識別しようと努める。関係がヒューリスティックに決定されるので、ヒューリスティック・ルーチン３３０ａ〜ｆは、候補リソースが論理アプリケーション３１９に関係づけられる可能性を割り当てることになる。論理アプリケーション３１９に関するごくわずかな情報を想定すると、この決定は非常に複雑で困難なものである。したがって、可能な限り正確な決定を提供するために、様々な可能性を有する複数のヒューリスティック・ルーチンが適用される。
【００９０】
本明細書で使用される「ヒューリスティック」という用語は、「解が正しい可能性が高いかどうかは無視する問題解決のための技術であるが、通常は良好な解を生成する技術、またはより複雑な問題の解を包含するかもしくはそれと共通部分を持つより簡単な問題を解決する技術」を意味する（ウェブサイトwww.wikipedia.orgの定義を参照されたい）。
【００９１】
好ましい実施形態では、ヒューリスティック・ルーチン３３０ａ〜ｆの初期セットが提供される。また、ユーザは、ユーザ自身のヒューリスティック・ルーチン３３０ａ〜ｆを追加することが許されている。ヒューリスティック・ルーチン３３０ａ〜ｆは、発見モジュール３２６と協働する。ヒューリスティック・ルーチン３３０ａ〜ｆが論理アプリケーションに関連するリソースを識別した後で、発見モジュール３２６はリソースを発見し、リソースを論理アプリケーションに関係づける。
【００９２】
あるヒューリスティック・ルーチン３３０ａは、識別子によって識別されたアプリケーションの子アプリケーションによって使用されるすべてのリソースを識別する。他のヒューリスティック・ルーチン３３０ｂは、識別子によって識別されたリソースと同じディレクトリのすべてのリソースを識別する。他のヒューリスティック・ルーチン３３０ｃは、識別子によって識別されたリソースを格納するディレクトリとその親ディレクトリの使用挙動を分析して、サブ・ディレクトリまたは親ディレクトリ、およびそれらのすべての内容が論理アプリケーションと関係しているかどうかを識別する。
【００９３】
あるヒューリスティック・ルーチン３３０ｄは、識別子によって識別されたリソースがインストレーション・パッケージに属しているかどうかを判定し、属している場合には、インストレーション・パッケージ内のすべてのリソースがヒューリスティック・ルーチン３３０ｄを満たすものと見なす。他のヒューリスティック・ルーチン３３０ｅは、識別子によって識別されたリソースの実行開始時刻を中心とした時間窓内で使用されるリソースを調べる。時間窓内で使用されるリソースは、ヒューリスティック・ルーチン３３０ｅを満たすものである。最後に、あるヒューリスティック・ルーチン３３０ｆは、ユーザ定義のルールに適合するリソースによって満たすことができる。このルールは、コンピュータ施設に存在するサイト固有の手続きに基づいて、いくつかのリソースを包含または除外することができる。
【００９４】
一実施形態では、評価モジュール３２４は発見モジュール３２６と協働して、２つの異なる方法に従ってリソースを発見する。第１の方法は、積上げ方式（build-up scheme）と呼ばれている。この方式では、ヒューリスティック・ルーチン３３０ａ〜ｆは、論理アプリケーションを定義するセット内に現在存在するリソースのセットを増加させるように適用される。このように、識別子によって識別された初期リソースであるシードは、ヒューリスティック・ルーチン３３０ａ〜ｆが適用されたときに、関係するリソースからなるネットワークになる。この方式の使用は、ヒューリスティック・ルーチンが、関係するリソースの的を外さないという信頼を意味するが、いくつかのリソースが見落とされる可能性があるというリスクを冒すことになる。しかし、この方式は不要なリソースを排除することができる。
【００９５】
第２の方法は、切取り方式（whittle-down scheme）と呼ばれ、より確実な方式であるが、実際には論理アプリケーションと関係のないリソースを含む可能性がある。切取り方式は、論理アプリケーション、すなわちビジネス・プロセスを実行するコンピュータ・システムにアクセス可能な全てのリソースを表す事前に定義されたスーパーセットを含む論理アプリケーションから始める。次に、逆の操作を使用するヒューリスティック・ルーチン３３０ａ〜ｆが適用される。すなわち、事前に定義されたスーパーセットから、ヒューリスティック・ルーチン３３０ａ〜ｆを満たすリソースが除去される。
【００９６】
使用される方法にかかわらず、評価モジュール３２４は１組の候補リソースを生成し、それを修正モジュール３２８に送る。修正モジュール３２８は、その候補リソースを決定モジュール３０６に送り、決定モジュール３０６は、その候補リソースを論理アプリケーション３１９に定義されたセットに追加するか、またはそのセットから削除する。決定モジュール３０６は、修正モジュール３２８による指示通りに、論理アプリケーション３１９を定義および再定義する。
【００９７】
好ましくは、評価モジュール３２４は、論理アプリケーション３１９に現在含まれている各リソースにヒューリスティック・ルーチン３３０ａ〜ｆを適用するように構成される。したがって、修正モジュール３２８は、論理アプリケーション３１９に対して評価モジュール３２４を再実行すべきかどうかを判定することもできる。一実施形態では、修正モジュール３２８は、評価モジュール３２４の動作繰返しの間の論理アプリケーション３１９の変化についてのユーザ設定可能な割合に基づいて、そのような判定を実施することができる。あるいは、ユーザ設定可能な設定によって、事前に定義された繰返し回数を判定することもできる
【００９８】
このようにして、論理アプリケーション３１９は、最近に追加されたリソースと論理アプリケーション３１９にすでに存在しているリソースの間の関係に基づいて増大または縮小を続ける。繰返しの間に論理アプリケーション３１９がほとんど変化しなくなると、論理アプリケーションは安定したと言える。
【００９９】
論理アプリケーション３１９が完成した（安定したか、または必要な繰返し回数が完了した）と修正モジュール３２８が判定した後で、決定モジュール３０６はその論理アプリケーション３１９をインタフェース３０８に提供する。好ましくは、インタフェース３０８を使用することにより、ユーザは、グラフィカル・ユーザ・インタフェース３３２（ＧＵＩ）またはアプリケーション・プログラミング・インタフェース３３４（ＡＰＩ）のどちらかを使用して、論理アプリケーション３１９と対話することができる。
【０１００】
図４は、図３のインタフェース３０８の一実施形態をより詳細に示す。インタフェース３０８の使用により、論理アプリケーションの識別に関するパラメータを制御することが可能になる。ユーザは、論理アプリケーションがどのように定義されるかに影響を与える入力４０２を、直接提供することができる。このような入力４０２には、初期識別子、ヒューリスティック・ルーチン３３０ａ〜ｆ（図３参照）の閾値、論理アプリケーションを構築するために使用される方式（積上げ、または切取り）の選択、ヒューリスティック・ルーチン３３０の１つで使用されるユーザ定義によるルールなどを含めることができる。
【０１０１】
ユーザ入力４０２は、ＧＵＩ３３２によって提供することができる。ＧＵＩ３３２は、論理アプリケーションを編集できるようにするエディタ４０４を含むことができる。エディタ４０４は、論理アプリケーションの名前および他の詳細、ならびに論理アプリケーションに現在関係づけられているリソースのリストを提示することができる。次に、ユーザは、エディタ４０４を使用して、このリストにリソースを追加または削除することができる。
【０１０２】
論理アプリケーションは、定義された後で、フォーマッタ４０６を使用して様々なフォーマットで、インタフェース３０８からエクスポートすることができる。一実施形態では、フォーマッタ４０６は、１つまたは複数の論理アプリケーションおよびそれに関係するリソースを含む、人間が読める形のＸＭＬファイルを生成する。
【０１０３】
他のソフトウェア・アプリケーション４０８は、インタフェース３０８を使用して、それら他のソフトウェア・アプリケーション４０８で使用される論理アプリケーションを識別することができる。例えば、４０８での管理モジュールは、ＡＰＩ３３４の関数またはメソッドを呼び出して、論理アプリケーションを識別することができる。それに応答して、ＡＰＩ３３４は、提示されたフォーマットで論理アプリケーションの定義を提供する。
【０１０４】
次に、４０８での管理モジュールは、ビジネス・レベル・ポリシー４１０を論理アプリケーションに適用することができる。例えば、４０８での管理モジュールは、Tivoli storage manager（TivoliはＩＢＭ社の商標）を含むことができる。ＡＰＩ３３４によって提供される論理アプリケーションについて考えると、４０８でのストレージ・マネージャは論理アプリケーション全体にバックアップ・ポリシー４１０を適用することができる。このようにして、バックアップ・ポリシー４１０は、リソースに自動的に実装され、いくつかの記憶装置およびファイル・システムに広めることができる。本発明は、論理アプリケーションを自動的に識別するので、バックアップ・ポリシーを満たすことに関係するリソースを手動で識別する労働集約的でエラーを発生させやすいプロセスを回避することができる。
【０１０５】
もちろん、様々な他のソフトウェア・アプリケーション４０８により、ビジネス・プロセスを表す論理アプリケーションを使用して様々なビジネス・レベル・ポリシー４１０を実行することができる。例えば、いくつかのソフトウェア・アプリケーション４０８は、論理アプリケーションを使用して負荷バランス・ポリシー、ソフトウェア移行ポリシーなどを実行することができる。さらに、本発明により、リソースやサブコンポーネントが更新または置換されたときに、これらの論理アプリケーションを修正し、再定義することも可能になる。
【０１０６】
図５は、ビジネス・プロセスによって使用されるリソースを自動的に発見し、分類するための単一システム５００の一実施形態を示す。システム５００は、オペレーティング・システム５０２、プロセス・マネージャ５０４、およびＩ／Ｏモジュール５０６を含む。オペレーティング・システム５０２は、プロセスの実行を管理する。プロセス・マネージャ５０４は動作中のプロセスに関する情報を提供する。Ｉ／Ｏモジュール５０６は、ファイルの活動に関する情報を提供する。
【０１０７】
システム５００は、対応する記憶装置５１０ａ〜ｎを使用する複数のファイル・システム（ＦＳ）５０８ａ〜ｎを含むことができる。Ｉ／Ｏモジュール５０６は、すべてのファイル・システム５０８ａ〜ｎについてのファイル情報を提供することができる。
【０１０８】
監視モジュール５１２は、オペレーティング・システム５０２がソフトウェア・アプリケーションを実行している間のトレース・データ５１４を収集する。監視モジュール５１２は、プロセス・マネージャ５０４、Ｉ／Ｏモジュール５０６、およびファイル・システム５０８ａ〜ｎと対話してトレース・データ５１４を収集することができる。いくつかの種類のトレース・データ５１４を収集するために、監視モジュール５１２は、プロセス・モニタ５１６、Ｉ／Ｏモニタ５１８、ネットワーク・モニタ５２０、およびＦＳモニタ５２１を含むことができる。一実施形態では、モニタ５１６、５１８、５２０、５２１は、トレース・データ５１４を収集する際に図３に関して論じた活動モニタ３２０と実質的に同一の機能を実行する。
【０１０９】
監視モジュール５１２はトレース・データ５１４を分析モジュール５２２に提供し、分析モジュール５２２はトレース・データを分析してビジネス・プロセスに関連するリソースを発見する。分析モジュール５２２は、図３の実施形態で説明した分析モジュール３０４とほぼ同じ機能を果たす。分析モジュール５２２は、論理アプリケーション５２４を定義することもできる。論理アプリケーション５２４は、ＸＭＬなどのマークアップ言語データ構造の中に定義することができる。
【０１１０】
インタフェース５２６は、ＧＵＩ５２８を使用してユーザが論理アプリケーション５２４と対話することを可能にすることができる。別法または追加として、論理アプリケーション５２４は、ＡＰＩ５３０を介して他のソフトウェア・アプリケーション４０８（図４参照）に提供することもできる。
【０１１１】
システム５００は、単一システムにおけるビジネス・プロセスによって使用されるリソース（ファイル、ポートなど）を自動的に発見する。一般に、ビジネス・プロセスは、複数のソフトウェア・アプリケーションを使用して実装される。単一のソフトウェア・アプリケーションであっても、同一システム上の様々な既知および未知の場所に格納された多数のリソースを含むことがあり得る。システム５００は、ビジネス・プロセスに対応する論理アプリケーションを自動的に識別する。
【０１１２】
場合によっては、この論理アプリケーションは、単一のソフトウェア・アプリケーションに対応する。論理アプリケーションは自動的に発見されるので、操作は、サブシステムやサブモジュール独立にではなく、論理アプリケーションの全体に対して実施することができる。このような操作には、論理アプリケーションのアップグレード、論理アプリケーションの削除、論理アプリケーションのバックアップなどを含めることができる。
【０１１３】
図６は、ビジネス・プロセスに関係するリソースを自動的に発見し分類するためのシステム６００の一実施形態を示す。システム６００は、ビジネス・プロセスのための論理アプリケーションを定義し、論理アプリケーションは、複数のインターネットワーク化されたコンピュータ・システム６０２に広められる。言い換えると、ビジネス・プロセスに関連し、ビジネス・プロセスを実行するリソースは、いくつかの記憶装置６０４ａ〜ｅ上に格納することができる。このような環境では、リソースが広く分散されているので、ビジネス・プロセスを実行するすべてのリソースを手動で識別することは困難であり、エラーを発生させやすい。
【０１１４】
図６の実施形態では、本発明は、ビジネス・プロセスに関連するリソースを自動的に発見し分類する。詳細には、監視モジュール６０６ａ〜ｅは、ビジネス・プロセスの一部を実行する各コンピュータ・システム６０２ａ〜ｅ上で実行することができる。例えば、ウェブ・サーバ６０２ａは、インターネット６１０を介したクライアント６０８とのウェブ・インタフェースを実装することができる。いくつかのアプリケーション・サーバ６０２ｂ、６０２ｅはミドルウェア・ソフトウェア・モジュールを実行することができ、２つのデータベース管理システム（ＤＢＭＳ）６０２ｃ、６０２ｄはビジネス・プロセスのためのデータを処理することができる。コンピュータ・システム６０２ａ〜ｅは、Ｌｉｎｕｘ、Ｍａｃ、Ｗｉｎｄｏｗｓ(登録商標）、ｚ／ＯＳ（ｚ／ＯＳはＩＢＭ社の商標）など、様々なオペレーティング・システムを動作させることができる。
【０１１５】
好ましくは、各監視モジュール６０６ａ〜ｅは、そのホスト・コンピュータ・システム６０２ａ〜ｅ上でのソフトウェア・アプリケーションの動作を表すトレース・データを収集する。監視モジュール６０６ａ〜ｅは、ホスト・コンピュータ・システム６０２ａ〜ｅ上で動作するすべてのソフトウェア・アプリケーションに関するファイルＩ／Ｏ、ネットワーク、およびプロセスのすべての活動を監視して、ビジネス・プロセスに属する可能性があるすべてのリソースに対するトレース・データが収集されることを保証することができる。あるいは、監視モジュール６０６ａ〜ｅは、どのソフトウェア・アプリケーションを監視するかを決定する際に、より慎重に選択することもできる。
【０１１６】
記憶モジュール６１２は、１つのコンピュータ・システム６０２ｅ上で動作させることができる。記憶モジュール６１２は、各監視モジュール６０６ａ〜ｅと通信してトレース・データを収集することができる。記憶モジュール６１２は、監視モジュール６０６ａ〜ｅと定期的に連絡を取ることができる。あるいは、監視モジュール６０６ａ〜ｅは、ある量のトレース・データが収集された後、またはある一定の期間トレース・データが収集された後で、記憶モジュール６１２にトレース・データを送ることもできる。記憶モジュール６１２は、トレース・データを中央レポジトリ６１４に格納することができる。
【０１１７】
分析モジュール６１６は、好ましくは、記憶モジュール６１２と同一のコンピュータ・システム６０２ｅ上に存在し、レポジトリ６１４内のトレース・データを分析する。図６の実施形態の分析モジュール６１６は、図５の実施形態で説明した分析モジュール５２２とほぼ同様に機能する。１つの相違点は、トレース・データが、ホスト・コンピュータ・システム６０２ｅだけでなく、複数のコンピュータ・システム６０２ａ〜ｅからもたらされることである。
【０１１８】
ユーザは、ＧＵＩ６１８を使用して分析モジュールと６１６と対話することにより、インタフェース６２０を使用して論理アプリケーションを定義し修正することができる。好ましくは、ユーザは、論理アプリケーションを含むリソースのリストに含められる第１のリソースを識別するための識別子を提供する。別法または追加として、他のソフトウェア・アプリケーションは、ＡＰＩ６２２を使用して分析モジュール６１６と対話することもできる。
【０１１９】
記憶モジュール６１２、分析モジュール６１６、およびインタフェース・モジュール６２０は共に、監視モジュール６０６ａ〜ｅによって提供されるトレース・データに従って、ビジネス・プロセスで使用されるリソースを自動的に発見し分類するように構成されたサブシステム６２４内で協働する。システム６００は、論理アプリケーションが実際に使用するリソースによって論理アプリケーションを定義する。
【０１２０】
これらの論理アプリケーションをソフトウェア管理アプリケーションが使用して、各論理アプリケーションに全体としてビジネス・レベル・ポリシーを適用することができる。一般に、これらのリソースは、データ・ファイルと実行可能ファイルを含む。しかし、リソースは、ウェブ・サービス、サーバ、エージェント、デーモンなどのサービス・アプリケーションを含むこともでき、論理アプリケーションの一部が所望の機能を実行する際に利用することができる。
【０１２１】
図７は、ビジネス・プロセスによって使用されるリソースを自動的に発見し分類するための方法７００の流れ図を示す。方法７００は、７０２で、ビジネス・プロセスの識別子を受け取ることによって始まる。識別子は、ビジネス・プロセスと直接関連することが知られているリソースを識別する。リソースは、ビジネス・プロセスの少なくとも一部を実行する。
【０１２２】
論理アプリケーションは、少なくともこのリソースを含むように定義される。一例では、識別子は、ビジネス・プロセスを実行するために動作することが知られている実行可能ファイルのファイル名を含むことができる。上述のように、識別子はポート番号または他の特徴的な機能を含むことができる。
【０１２３】
別法または追加として、ビジネス・プロセスを実行するソフトウェア・アプリケーションの追跡可能な特性は、識別子を使用して識別可能にすることができる。例えば、識別子はデータ・ファイル名を含むことができる。方法７００を使用して、データ・ファイルに直接または間接にアクセスするすべてのリソースを含む論理アプリケーションを決定することができる。
【０１２４】
次に、リソースの特定の種類の活動を追跡するために、７０４で活動モニタを開始する。活動モニタは、図３に関連して説明した活動モニタ３２０とほぼ同じ機能を果たすことができる。ある活動モニタ３２０はファイルＩ／Ｏを追跡することができ、他の活動モニタはネットワーク通信を追跡することができ、さらに他の活動モニタは動作中のプロセスを追跡することができる。好ましくは、活動モニタ３２０は、識別子によって識別されるリソースによって実行される動作に限定されない。
【０１２５】
好ましくは、活動モニタ３２０が動作している間に、ビジネス・プロセスは、ビジネス・プロセスを実行するリソースによって実行された動作をコンピュータ・システムの挙動が含むように実行される。次に、７０６で、活動モニタ３２０によって定義されたトレース・データが収集される。さらに、トレース・データは、共通フォーマットの形に再構成またはフォーマット、あるいはその両方を実施することができる。次に、７０８で、結合されたトレース・データが格納される。いくつかの実施形態では、トレース・データは、中央レポジトリ６１４（図６参照）に格納される。
【０１２６】
ビジネス・プロセスを実行するソフトウェア・アプリケーションの動作中に収集されたトレース・データに加えて、７１０で、システム情報をスキャンしてトレース・データを求めることができる。例えば、ファイル・システムをスキャンして、ソフトウェア・アプリケーションの活動を示す生成タイムスタンプまたはアクセス・タイムスタンプ、あるいはその両方を含むファイルを求めることができる。このようなスキャンは、ファイル・システムの現在の状態のスナップショットを含むことができる。このような情報（トレース・データ）は、ビジネス・プロセスを実行する際のある種のリソースの挙動を識別するために後で使用することができる。
【０１２７】
システム情報は、リソースに関係する情報を含むことができる。例えば、システム情報は、ファイル・システムにおける、ディレクトリの内容ならびにファイルとディレクトリの間の関係を含むことができる。システム情報はまた、現在動作中のプロセスのリスト、ならびにプロセスと許可されたネットワーク活動および禁止されたネットワーク活動のログとの関係を含むこともできる。
【０１２８】
次に、識別子に関連するリソースを発見するために、ステップ７０２で提供された識別子を考慮して、７１２で、収集されたトレース・データが分析される。ある場合には、関連はファイル間に存在することがある。他の場合には、関連は、ファイルとあるポート番号に関するネットワーク活動との間に存在する。トレース・データ内で識別可能なリソースは、１つまたは複数のヒューリスティック・ルーチンに従って、識別子または論理アプリケーション内の他のリソース、あるいはその両方に関連すると判定される。好ましくは、発見されたリソースは、トレース・データが収集されたソフトウェア・アプリケーションを含むビジネス・プロセスに関連している。
【０１２９】
プロセス７００は、７１４で、識別子によって識別されたリソースから始めて論理アプリケーションを定義する。一実施形態では、分析ステップ７１２で、識別子によって識別されたリソースから始めて関係するリソースの集まりを作成する（積上げ方式）。新しいリソースが発見されたとき、７１４で、それらは論理アプリケーションに追加される。論理アプリケーションは、論理アプリケーションにすでに関連づけられているリソースに関連するリソースを含むように修正される。７１６で、新しいリソースが追加されていた場合は、プロセスは分析ステップ７１２に進み、新しく追加されたリソースに他のリソースが直接関係しているかどうかが判定される。新しいリソースが追加されていなかった場合は、プロセス７００を終了することができる。
【０１３０】
他の実施形態では、論理アプリケーションは、事前に定義されたスーパーセットを含むように定義される。スーパーセットは、コンピュータ・システムにアクセス可能なすべてのリソース（すなわち、接続されたファイル・システム内のすべてのファイル）を含む。次に、分析ステップ７１２はヒューリスティック・ルーチンを適用して、スーパーセットからどのリソースを削除すべきかを決定する（切取り方式）。リソースが削除された場合は、各追加の繰返しでリソースがほとんど削除されなくなるまで、分析ステップ７１２を繰り返すことができる。
【０１３１】
別法として、それ以上リソースが追加／削除されなくなるまで、または新しいリソースがほとんど追加／削除されなくなるまで分析ステップ７１２を繰り返すのではなく、プロセス７００は、所定のユーザ定義の繰返し回数だけ分析を繰り返すこともできる。当業者ならば、トレース・データの収集および格納に関するステップ７０４〜７１０が、識別子を受け取り、分析を実施するステップ７０２およびステップ７１２〜７１６と切り離して実施できることが理解されよう。したがって、方法７００は、図７に示された実施の順序に限定されるものではない。
【０１３２】
図８は、複数のネットワーク化されたコンピュータ・システムにおいて実行されるビジネス・プロセスによって使用されるリソースを、自動的に発見し分類するための方法８００の流れ図を示す。方法８００は、８０２で、ビジネス・プロセスの動作を監視することから始まる。一実施形態では、監視モジュール６０６ａ〜ｅは、ビジネス・プロセスを実行する各コンピュータ・システム上で動作する。
【０１３３】
次に、８０４で、好ましくは、監視モジュール６０６ａ〜ｅ（図６参照）によってトレース・データが収集される。監視モジュール６０６ａ〜ｅの使用により、ビジネス・プロセス実行中のコンピュータ・システムの動作へのオーバヘッドを最小にしながら、ビジネス・プロセスの挙動を追跡することが可能になる。監視モジュール６０６ａ〜ｅは、トレース・データを記憶モジュール６１２に提供して中央レポジトリ６１４に格納することができる。トレース・データは、インターネットワーク化された各コンピュータ・システム６０２ａ〜ｅ上のほぼ全てのプロセスの挙動についての履歴記録となる。
【０１３４】
次に、トレース・データを分析し、識別子（すなわち、ファイル名、ポート番号、プロセスＩＤなど）に関連するリソースを識別することによって、ビジネス・プロセスに関連するリソースを発見する。一実施形態では、いくつかのヒューリスティック・ルーチンを使用して、識別子および識別子によって識別されたリソースの特性を考慮しながらトレース・データを分析する。ヒューリスティック・ルーチンに従って、識別子およびヒューリスティック・ルーチンを用いて導かれた検索基準を使用して、８０６で、トレース・データを検索することができる。
【０１３５】
例えば、ヒューリスティック・ルーチンは、所定の時間後にアクセスされるリソースに基づくものでもよい。したがって、トレース・データは、８０６で、所定の時間後にアクセスされるリソースに対する追跡記録を含む検索基準を用いて検索することができる。あるいは、検索基準は、ファイル名などの識別子を含むだけのものでもよい。
【０１３６】
一般に、トレース・データの検索により、トレース記録を含む結果セットが生成される。いくつかの実施形態では、８０８で、結果セットにヒューリスティック・ルーチンを適用して、ヒューリスティック・ルーチンを満たすリソースを発見する。別法として、ヒューリスティック・ルーチンは、８０８で、すべてのトレース・データがスキャンされたときに適用することができる。他の代替実施形態では、ヒューリスティック・ルーチンの種類に応じて、トレース・データを繰り返しスキャンして、ヒューリスティック・ルーチンが適切に適用されトレース・データが完全に使用されたことを保証することができる。
【０１３７】
次に、積上げ方式では、８１０で、少なくとも１つのヒューリスティック・ルーチンを満たすリソースが論理アプリケーションに集められる。切取り方式では、８１０で、インターネットワーク化されたコンピュータ・システム６０２ａ〜ｅで使用できる全てのリソースのスーパーセットを含む論理アプリケーションから、少なくとも１つのヒューリスティック・ルーチンを満たすリソースが削除される。
【０１３８】
最後に、自動および手動のどちらの場合も、８１２で、ビジネス・レベル・ポリシーが論理アプリケーションに適用される。ビジネス・ポリシーの例には、トランザクション負荷バランス、データ回復またはソフトウェア回復あるいはその両方、ソフトウェア移行、バックアップなどがある。他のポリシーには、１つまたは複数のコンピュータ・システムにおける、ウィルスを含むリソースおよびウィルスによって変更されたリソースなどウィルス攻撃によって影響を受けたリソースを含む論理アプリケーションの識別などがある。
【０１３９】
当業者ならば、本発明によって提供される潜在的な利益を直ちに理解できるはずである。合法的ビジネス・プロセスまたは非合法的プロセスあるいはその両方、ならびに他の分散システムに対応する論理アプリケーションを自動的に識別する機能により、攻撃的および防御的ビジネス・ポリシーの実行が大いに簡素化される。
【０１４０】
要約すると、本発明は、ビジネス・プロセスまたは他の分散システムによって使用されるリソースを自動的に発見し分類するための装置、システム、および方法を提供する。リソースを識別する際に、広範なトレース・データが収集され複数の的確なヒューリスティック・ルーチンが使用されるので、本発明は非常に的確なものである。さらに、本発明は非常に柔軟に構成することができる。ユーザは、自動的に定義された論理アプリケーションを編集し、必要な場合にはヒューリスティック・ルールを定義し、かつ適用されるヒューリスティック・ルーチンの感度を調整することができる。このようにして、本発明は、関係する個々のビジネス・プロセスの重要性に応じて、より控えめに、またはより積極的に実施することができる。本発明はまた、他のソフトウェア管理システムと連携してビジネス・ポリシーの実装を容易にすることもできる。さらに、定義された論理アプリケーションは、より多くのトレース・データが使用できるようになったときに改良することもできる。このように、論理アプリケーションは、時間の経過にともなうビジネス・プロセスのサブコンポーネントの機能向上や変更に対応するように修正することができる。
【０１４１】
本発明は、その範囲を逸脱することなく、他の特定の形態で実施することができる。記載の実施形態は、あらゆる点において例示的なものであり限定的なものではないと見なすべきである。したがって、本発明の範囲は、前述の説明ではなく、添付の特許請求の範囲によって示される。特許請求の範囲の均等の意味および範囲に含まれるあらゆる変更は、その範囲の中に包含されるものとする。
【図面の簡単な説明】
【０１４２】
【図１】ビジネス・レベル・ポリシーを従来方式でどのように実装することができるかの一例を示す構成図である。
【図２】本発明による、論理アプリケーションによって使用されるリソースを自動的に発見し分類する装置の一実施形態を示す論理構成図である。
【図３】本発明の一実施形態のサブコンポーネントを詳細に示す構成図である。
【図４】ユーザと本発明のいくつかの実施形態とが対話できるようにするインタフェース・モジュールを示す概略構成図である。
【図５】本発明による単一システムを示す概略構成図である。
【図６】本発明によるネットワーク化されたシステムを示す概略構成図である。
【図７】ビジネス・プロセスによって使用されるリソースを自動的に発見し分類する方法を示す概略流れ図である。
【図８】ビジネス・プロセスによって使用されるリソースを自動的に発見し分類する代替方法を示す概略流れ図である。
【図１】
2008509494.tif 000003
【図２】
2008509494.tif 000004
【図３】
2008509494.tif 000005
【図４】
2008509494.tif 000006
【図５】
2008509494.tif 000007
【図６】
2008509494.tif 000008
【図７】
2008509494.tif 000009
【図８】
2008509494.tif 000010
【国際調査報告】
2008509494.tif 000011
2008509494.tif 000012
2008509494.tif 000013