(57)【特許請求の範囲】
【請求項１】
プラグインを実行する方法であって、
実行されるプラグインの安定性レベルを取得することと、
少なくとも部分的に前記安定性レベルに基づいて、利用可能な複数のプラグイン実行モードから選択される、プラグイン実行モードを決定することと、
前記決定されたプラグイン実行モードに従って、前記プラグインを実行することと、を備える方法。
【請求項２】
請求項１に記載の方法において、前記プラグインの安定性レベルは、記憶場所から取得される、方法。
【請求項３】
請求項１に記載の方法において、前記複数のプラグイン実行モードは、利用可能な複数のプラグイン安定性レベルに対応している、方法。
【請求項４】
請求項１に記載の方法において、
前記複数のプラグイン実行モードは、複数のローダ・プロセスに対応しており、
前記決定されたプラグイン実行モードに従う前記プラグインの実行は、前記複数のローダ・プロセスのうち、前記決定されたプラグイン実行モードに対応するローダ・プロセスを起動させて、前記プラグインをロードすることを含む、方法。
【請求項５】
請求項４に記載の方法において、前記プラグインの安定性レベルが安定である場合には、前記ローダ・プロセスは共有ローダ・プロセスである、方法。
【請求項６】
請求項４に記載の方法において、前記プラグインの安定性レベルが普通である場合には、前記ローダ・プロセスは独立ローダ・プロセスである、方法。
【請求項７】
請求項４に記載の方法において、前記プラグインの安定性レベルが不安定である場合には、前記方法は、前記プラグインの実行を停止させることをさらに備える、方法。
【請求項８】
請求項４に記載の方法において、前記プラグインの安定性レベルが不安定である場合には、前記方法は、前記プラグインの異常情報を取得および保存することをさらに備える、方法。
【請求項９】
請求項８に記載の方法において、前記異常情報は、前記プラグインの異常動作の理由と、前記プラグインのプラグイン情報とを含む、方法。
【請求項１０】
請求項１に記載の方法はさらに、前記プラグインの安定性レベルを調整することを備える、方法。
【請求項１１】
請求項１０に記載の方法において、前記プラグインの安定性レベルの調整は、
前記プラグインが所定期間の間に異常動作した回数を決定することと、
前記プラグインが所定期間の間に異常動作した回数の前記決定に少なくとも部分的に基づいて、前記プラグインの安定性レベルを調整することと、を含む、方法。
【請求項１２】
プラグインを実行するシステムであって、
１つまたは複数のプロセッサであって、
実行されるプラグインの安定性レベルを取得し、
少なくとも部分的に前記安定性レベルに基づいて、利用可能な複数のプラグイン実行モードから選択される、プラグイン実行モードを決定し、
前記決定されたプラグイン実行モードに従って、前記プラグインを実行するように構成されている、プロセッサと、
前記１つまたは複数のプロセッサに結合された１つまたは複数のメモリであって、前記１つまたは複数のプロセッサに命令を提供するように構成されているメモリと、を備えるシステム。
【請求項１３】
請求項１２に記載のシステムにおいて、前記プラグインの安定性レベルは、記憶場所から取得される、システム。
【請求項１４】
請求項１２に記載のシステムにおいて、前記複数のプラグイン実行モードは、利用可能な複数のプラグイン安定性レベルに対応している、システム。
【請求項１５】
請求項１２に記載のシステムにおいて、
前記複数のプラグイン実行モードは、複数のローダ・プロセスに対応しており、
前記決定されたプラグイン実行モードに従う前記プラグインの実行は、前記複数のローダ・プロセスのうち、前記決定されたプラグイン実行モードに対応するローダ・プロセスを起動させて、前記プラグインをロードすることを含む、システム。
【請求項１６】
請求項１５に記載のシステムにおいて、前記プラグインの安定性レベルが安定である場合には、前記ローダ・プロセスは共有ローダ・プロセスである、システム。
【請求項１７】
請求項１５に記載のシステムにおいて、前記プラグインの安定性レベルが普通である場合には、前記ローダ・プロセスは独立ローダ・プロセスである、システム。
【請求項１８】
請求項１５に記載のシステムにおいて、前記プラグインの安定性レベルが不安定である場合には、前記１つまたは複数のプロセッサは、さらに、前記プラグインの実行を停止させるように構成されている、システム。
【請求項１９】
請求項１５に記載のシステムにおいて、前記プラグインの安定性レベルが不安定である場合には、前記１つまたは複数のプロセッサは、さらに、前記プラグインの異常情報を取得および保存するように構成されている、システム。
【請求項２０】
請求項１２に記載のシステムにおいて、前記１つまたは複数のプロセッサは、さらに、前記プラグインの安定性レベルを調整するように構成されている、システム。
【請求項２１】
請求項２０に記載のシステムにおいて、前記プラグインの安定性レベルの調整は、
前記プラグインが所定期間の間に異常動作した回数を決定することと、
前記プラグインが所定期間の間に異常動作した回数の前記決定に少なくとも部分的に基づいて、前記プラグインの安定性レベルを調整することと、を備えている、システム。
【請求項２２】
プラグインを実行するためのコンピュータプログラムであって、
実行されるプラグインの安定性レベルを取得するための機能と、
少なくとも部分的に前記安定性レベルに基づいて、利用可能な複数のプラグイン実行モードから選択される、プラグイン実行モードを決定するための機能と、
前記決定されたプラグイン実行モードに従って、前記プラグインを実行するための機能とをコンピュータによって実現させるコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
［関連出願の相互参照］
本出願は、あらゆる目的のために参照により本明細書に組み込まれる、２００９年３月３１日に出願された、発明の名称を「ＭＥＴＨＯＤ， ＤＥＶＩＣＥ ＡＮＤ ＳＹＳＴＥＭ ＦＯＲ ＲＵＮＮＩＮＧ Ａ ＰＬＵＧＩＮ（プラグインを実行する方法、デバイスおよびシステム）」とする中国特許出願番号２００９１０１２９１８７．４の優先権を主張する。
【０００２】
本発明は、コンピューティングの分野に関し、特に、プラグインを実行する技術に関するものである。
【背景技術】
【０００３】
（アドオン、アドイン、スナップイン、または拡張機能とも呼ばれる）プラグインは、一般的に、ウェブブラウザなどのコア・アプリケーションと相互作用して、必要に応じて特定の機能を提供するコンピュータプログラムである。最近のネットワーク化されたコンピュータ環境において、プラグインは、コア・アプリケーションの機能を拡張するためにしばしば用いられる。
【０００４】
現在のところ、プラグインは、通常、つぎのようなプラグイン実行モードで実行されている。
【０００５】
１）プラグインとコア・アプリケーションとが、同一のプロセスで実行される。このモードでは、プラグインのサポートシステムは簡単なものであって、プラグインとコア・アプリケーションとの間の相互作用効率が高い。しかしながら、プラグインとコア・アプリケーションとが同一のプロセスで実行されるため、プラグインで一旦問題が生じると、それによって直接、コア・アプリケーションの異常動作あるいはクラッシュが引き起こされる。また、コア・アプリケーションは、様々なモジュールを含んでいることがあるので、問題が発生しているモジュールまたはプラグインを明確に特定することが難しい。
【０００６】
２）プラグインは、コア・アプリケーションが実行されるプロセスとは別に実行され、各プラグインは個別のプロセスを占有する。これによりコア・アプリケーションにプラグインによる影響が及ぶことを防いでいる。プラグインの数が多い場合には、クライアントのシステム資源の多くが消費されて、これが応答速度の低下およびユーザエクスペリエンスの低下につながる可能性がある。
【０００７】
３）プラグインは、コア・アプリケーションが実行されるプロセスとは別に実行され、全てのプラグインが特定のプロセスで実行される。このモードでは、クライアントのシステム資源は節約されるかもしれないが、あるプラグインが異常動作をすると、それによって全てのプラグインが使用不可能または異常となる場合がある。また、問題が発生しているプラグインを明確に特定することが難しい。
【０００８】
プラグイン開発者の数および品質管理がそれほど厳しくないことから考えて、多くの場合プラグインは、コア・アプリケーションよりも多くのバグを含んでいる。従って、上記モード１またはモード３を採用した場合、コア・アプリケーションあるいは全てのプラグインの動作が、１つのプラグインの不安定な実行によって異常をきたし得る。しかし、それと同時に、クライアントの資源は制限されていることがよくあり、このため、上記のモード２を採用した場合、消費されるクライアント資源が多くなりすぎて、パフォーマンスが低下する傾向となる。
【０００９】
本発明の種々の実施形態は、以下の詳細な説明および添付の図面において開示される。
【図面の簡単な説明】
【００１０】
【図１Ａ】図１Ａは、プラグインを実行するための環境の一実施形態を示すブロック図である。
【００１１】
【図１Ｂ】図１Ｂは、プラグイン実行プロセスの一実施形態を示すフローチャートである。
【００１２】
【図２】図２は、プラグイン実行プロセスの別の実施形態を示すフローチャートである。
【００１３】
【図３】図３は、異常情報を記録するプロセスの一実施形態を示すフローチャートである。
【００１４】
【図４】図４は、プラグインの安定性レベルを周期的に調整するプロセスの一実施形態を示すフローチャートである。
【００１５】
【図５】図５は、プラグインを実行するように構成されたクライアントシステムの一実施形態を示すブロック図である。
【００１６】
【図６】図６は、プラグインを実行するシステムの一実施形態を示すブロック図である。
【発明を実施するための形態】
【００１７】
本発明は、数多くの方法で実施することが可能であり、それには、プロセス、装置、システム、組成物、コンピュータ読み取り可能な記憶媒体上で実現されるコンピュータプログラム・プロダクトとしての実施、および／または、プロセッサに結合されたメモリに記憶された命令および／またはそれにより提供される命令を実行するように構成されたプロセッサなど、プロセッサとしての実施が含まれる。本明細書では、このような実施の形態、あるいは本発明が取り得るその他の形態を、技術と呼ぶ場合がある。一般的に、開示されるプロセスのステップの順序は、発明の範囲内で変更することができる。特に明記しない限り、タスクを実行するように構成されたものとして記載されるプロセッサまたはメモリなどのコンポーネントは、所与の時間に一時的にそのタスクを実行するように構成された汎用コンポーネント、あるいはそのタスクを実行するように作製された専用コンポーネントとして実現することができる。本明細書において用いられる場合の「プロセッサ」という用語は、コンピュータプログラム命令などのデータを処理するように構成された１つまたは複数のデバイス、回路、および／または処理コアを指している。
【００１８】
本発明の１つまたは複数の実施形態についての詳細な説明が、以下で、本発明の原理を示す添付図面と共に提供される。本発明は、それらの実施形態に関連させて説明されるが、本発明は、いずれの実施形態にも限定されるものではない。本発明の範囲は、請求項によってのみ限定されるものであり、本発明は、多くの代替案、変形、および等価物を包含している。発明についての完全な理解を与えるため、様々な具体的詳細が以下の説明において記載される。これらの詳細は、例示目的で提供されるものであり、本発明は、これら特定の詳細の一部または全部を省いて、請求項に基づき実施することができる。明確にする目的で、発明が不必要に不明瞭になることがないよう、本発明に関連する技術分野で知られている技術的事項については詳細に記載していない。
【００１９】
図１Ａは、プラグインを実行するための環境の実施形態を示すブロック図である。システム１５０は、コア・アプリケーションおよびそのプラグインを実行することができる機器である。システム１５０は、例えば、１つまたは複数のメモリにより提供される命令を実行するように構成された１つまたは複数のプロセッサを含む、パーソナルコンピュータ、モバイル機器、またはそれに類するものである。システム１５０において、コア・アプリケーション１５２が、プロセッサにより実行される。プラグイン・マネジャ１５６は、実施形態によってコア・アプリケーションの一部、あるいはコア・アプリケーションとやり取りする別個のプロセスとすることができるものであって、これはプラグイン１５４を起動して、プラグインとコア・アプリケーションとの間の相互作用を調整する。以下でより詳細に説明するように、プラグイン１５４は、その安定性レベルひいては実行モードに応じて、コア・アプリケーションと同一のプロセスで、あるいは別個のプロセスで、動作するものとすることができる。プラグイン・マネジャ１５６は、プラグイン安定性情報データベース１５８にアクセスすることができ、そのデータベースは、システム１５０と同じ機器上またはサーバなど別の機器上にあるものとすることができる。プラグインの動作具合を利用して、プラグイン安定性情報が生成され、これがデータベース１５８に記録される。
【００２０】
図１Ｂは、プラグイン実行プロセスの一実施形態を示すフローチャートである。プロセス１００は、１５０のようなシステム上で実行することができる。
【００２１】
ステップ１０２において、実行されるプラグインの安定性レベルが取得される。この例では、実行されるプラグインの安定性レベルは、データベースに保存されているプラグイン安定性レベル情報から得ることができ、そのデータベースは、コア・アプリケーションおよびプラグインのサーバ上にあるもの、あるいはコア・アプリケーションを実行するクライアント機器上にローカルに存在するものとすることができる。
【００２２】
この例では、プラグインの安定性レベルは、所定期間の間のプラグインの実行状態の観測に基づいて決定される。その情報は、１５８のようなデータベースに記録される。一部の実施形態では、３つの安定性レベル、すなわち、安定、普通、および不安定が用いられる。プラグインの安定性レベルを決定するための、上限閾値および下限閾値が設定される。異常の頻度、すなわち、所定期間の間に（プラグイン・マネジャ、オペレーティングシステム、またはその他の適当な監視プログラム／デバイスにより検出される）プラグインの実行が異常となる回数が、上限閾値以上であると、プラグインの安定性レベルが不安定と判断される。異常の頻度が下限閾値以下であると、プラグインの安定性レベルは安定と判断される。そして、異常の頻度が下限閾値と上限閾値との間にあると、プラグインの安定性レベルは普通と判断される。一部の実施形態では、２つのみの安定性レベル、すなわち安定と普通が用いられる。この場合、１つのみの閾値を用いる。異常の頻度が閾値よりも大きいと、プラグインの安定性レベルは普通であり、そうでないと安定である。一部の実施形態では、４つの安定性レベル、すなわち、安定、比較的安定、普通、および不安定が用いられる。この場合は、３つの閾値を用いる。従って、異常の頻度が第１の閾値以上であると、プラグインの安定性レベルは不安定であり、異常の頻度が第２の閾値以上であって第１の閾値未満であると、プラグインの安定性レベルは普通であり、異常の頻度が第３の閾値以上であって第２の閾値未満であると、プラグインの安定性レベルは比較的安定であり、異常の頻度が第３の閾値未満であると、プラグインの安定性レベルは安定である。他の実施形態では、安定性レベルおよび閾値の数は、その実施の形態に応じて変更することができる。
【００２３】
ここで、プラグインと安定性レベルとの間の対応関係は、例えば、プラグイン・マネジャにより設定されるものとすることができ、また、実行されるプラグインの安定性レベルは、実行されるプラグインの識別情報が特定された後に取得されるものとすることができる。
【００２４】
ステップ１０４において、プラグインの実行モードが、少なくとも部分的にその安定性レベルに基づいて決定される。ここで、プラグイン実行モードは、複数の利用可能な実行モードから選択される。一部の実施形態では、利用可能な実行モードと、可能性のあるそれぞれの安定性レベルとの間の関係のマッピングのために、マッピングテーブルなどが用いられる。マッピングテーブルに基づいて決定された安定性モードを用いて、適当なプラグイン実行モードが選択される。安定性レベルと実行モードとの間の対応関係は、クライアント機器あるいはサーバにおいて、予め決定されて記憶されている。
【００２５】
一部の実施形態では、プラグイン安定性レベルの異なるプラグインをロードし、実行するために、複数のローダ・プロセスを利用可能である。ローダ・プロセスは、コア・アプリケーションにより、あるいはオペレーティングシステム内の他のプログラムにより起動することができる実行可能プログラムである。タイプの異なるローダ・プロセスには、共有ローダ・プロセスと独立ローダ・プロセスが含まれる。共有ローダ・プロセスでは、複数のプラグインを実行することができ、独立ローダ・プロセスでは、１つのみのプラグインを実行することができる。
【００２６】
安定性レベルとプラグイン実行モードとの間の例となる関係は、つぎのようなものである。プラグインの安定性レベルが安定である場合には、プラグイン実行モードにより、プラグインは、消費資源量を削減するように共有ローダ・プロセスで実行される。安定性レベルが普通である場合は、プラグイン実行モードにより、独立ローダ・プロセスが起動されて、プラグインは独立ローダ・プロセスで実行される。安定性レベルが普通であるプラグインを、独立ローダ・プロセスで実行することで、プラグインの実行中に生じる問題がコア・アプリケーションに影響を及ぼしたり不安定にさせたりすることを防止して、これにより全体としてのパフォーマンスおよび安定性を向上させている。安定性レベルが不安定である場合は、プラグイン実行モードにより、プラグインの実行が停止されるか、あるいは動作の停止についてユーザに通知して、プラグインの実行を継続するかどうかユーザに決定させる。ユーザが続行することを選択すると、独立ローダが起動されて、プラグインが実行される。それ以外の場合は、プラグインの実行が停止される。
【００２７】
一部の実施形態では、安定性レベルには、さらに、比較的安定のレベルが含まれる。安定性レベルが比較的安定である場合、プラグイン実行モードにより、プラグインは、共有ローダ・プロセスで実行される。様々な実施形態により、比較的安定したレベルの場合の共有ローダは、安定したレベルに対応する共有ローダと同一のものとすることも、別の共有ローダとすることもできる。
【００２８】
ステップ１０６では、ステップ１０２で決定されたプラグイン実行モードに従って、プラグインが実行される。
【００２９】
プラグインは、その実行中に異常動作をすることがある。それは、例えば、クラッシュであったり、メモリの不足であったり、あるいはその他の性能問題が生じることがある。このため、プロセス１００は、そのような異常動作に対処するためのステップをオプションで含んでいる。図示の例では、ステップ１０８において、プラグインの実行が異常である場合には、ステップ１１０において、プラグインの異常実行についての情報が取得され、ステップ１１２において、異常情報が記憶される。異常情報は、例えば、異常の理由と、実行されたプラグインについてのプラグイン情報とを含んでいる。異常の理由には、例えば、ローダ・プロセスのクラッシュ、プラグイン実行スレッドの予期せぬ終了、プラグインによるメモリまたはプロセッサ・サイクルの過剰消費などが含まれる。プラグイン情報には、例えば、プラグインの識別子情報、名前、バージョンなどが含まれる。
【００３０】
一部の実施形態では、クライアント、サーバ、あるいはシステムのその他の部分、あるいはそれらの組み合わせが、プラグイン実行の異常情報に基づいて、プラグイン安定性レベルを自動的に決定し、それを周期的に調整するように構成されている。つまり、クライアントまたはサーバが、保存されている異常情報を用いて、規定の期間にプラグインが異常となる回数を特定して、プラグインが異常動作した回数に応じてプラグインの安定性レベルを調整するものとすることができる。一部の実施形態では、所定期間の後に、その時間中にプラグインが異常動作した回数が特定される。その数が閾値を超えた場合には、プラグインの安定性レベルが自動的に調整される。異常発生回数は、次のサイクルに備えて０にリセットされる。一部の実施形態では、プラグインの安定性レベルは、手動で調整される。つまり、システム管理者が、一定時間内のプラグインの実行状態を観測し、一定時間内にプラグインが異常となる回数が所定値を超えた場合は、プラグインの安定性レベルを変更してもよい。
【００３１】
クライアント上で実行されているネットワーク・ツールのプラグイン実行プロセスは、ネットワーク・ツールのコア・アプリケーションにより、あるいはクライアントにおける他のプログラムにより、管理され得る。ここで、この実施形態において、コア・アプリケーションは、ネットワーク・ツールのコアサービスを提供するのみならず、プラグインを管理するプログラムをも含んでいる。ローダ・プロセスは、クライアントにおいて独立した実行可能プログラムであり、コア・アプリケーションもまた、ローディング・プロセスたり得る。
【００３２】
図２は、プラグイン実行プロセスの別の実施形態を示すフローチャートである。プロセス２００は、１５０のようなシステム上で実行することができる。
【００３３】
ステップ２０１において、実行されるプラグインの安定性レベルが取得される。この例では、コア・アプリケーションが、実行されるプラグインの安定性レベルの取得をサーバに要求すると、サーバは、識別子情報などのプラグイン情報を取得して、その識別子情報を用いてプラグインの安定性レベルを照会し、保存されているプラグインとその安定性レベルのマッピング情報に基づいて、照会した安定性レベルをコア・アプリケーションに返して、プラグインの実行回数を１だけ増加させる。この例では、可能性のある安定性レベルは、安定、普通、および不安定である。
【００３４】
一部の実施形態では、コア・アプリケーションは、実行されるプラグインの安定性レベルをローカルクライアントから取得する。クライアントは、実行されるプラグインの安定性レベルをプラグイン情報のデータベースで照会し、照会した安定性レベルをコア・アプリケーションに返して、プラグインの実行回数を１だけインクリメントする。
【００３５】
ステップ２０２において、実行されるプラグインの安定性レベルが決定される。安定性レベルが安定である場合には、制御はステップ２０３に移行し、安定性レベルが普通である場合には、制御はステップ２０６に移行し、安定性レベルが不安定である場合には、制御はステップ２０７に移行する。
【００３６】
ステップ２０３では、現行の共有ローダ・プロセスが既に存在するか否か判断される。共有ローダ・プロセスが存在する場合は、制御はステップ２０５に移行し、共有ローダ・プロセスが存在しない場合は、制御はステップ２０４に移行する。ステップ２０４では、共有ローダ・プロセスが起動される。ステップ２０５では、実行されるプラグインが、その共有ローダ・プロセスによりロードされる。ステップ２０６では、安定性レベルが普通であるプラグインのための独立ローディング・プロセスが起動されて、そのローディング・プロセスで、プラグインが実行される。ステップ２０７で、プラグインの実行が終了する。
【００３７】
この例では、共有ローダ・プロセスがない場合には、共有ローダ・プロセスがステップ２０４で起動される。ここで、コア・アプリケーションを、共有ローダとして直接用いることもでき、安定していると判断されるプラグインは、コア・アプリケーションと同一のプロセスで実行することもできる。
【００３８】
一部の実施形態では、プラグインの実行が異常になると、クライアントが、さらにプラグインの異常情報を取得して、その異常情報を保存し、および／または、それをサーバへ送信するものとすることができる。プラグインは、全て、ローダ・プロセスで実行されるので、プラグインの実行が異常になると、ローダ・プロセスも異常となる。このため、一部の実施形態においては、クライアントは、ローダ・プロセスの異常情報を取得して、その異常情報を保存し、さらにオプションとしてそれをサーバに送信する。
【００３９】
図３は、異常情報を記録するプロセスの一実施形態を示すフローチャートである。プロセス３００は、１５０のようなシステム上で実行することができる。
【００４０】
ステップ３０１において、ローダ・プロセスの異常情報が取得される。ローダ・プロセスが独立ローダ・プロセスである場合、異常情報は、異常の理由と、その独立ローダ・プロセスで実行されているプラグインのプラグイン情報とを含んでいる。ローダ・プロセスが共有ローダ・プロセスである場合、異常情報は、異常の理由と、その共有ローダ・プロセスで実行されている全てのプラグインのプラグイン情報とを含んでいる。異常情報は、さらに、ローダ・プロセスの異常コンテキストを含むものであってもよい。ここで、異常コンテキストには、ローダ・プロセスのメモリイメージなどの技術情報、関数スタックコンテキスト、ローダ・プロセスにロードされているプラグインなどが含まれる。さらに、そのコンテキストに対応する時点、ローダ・プロセスで実行されているプラグイン、現在実行されている命令などを取得することもできる。
【００４１】
クライアントは、ローダ・プロセスの異常の理由を検出により取得することができる。異常の理由は、ローダ・プロセスのクラッシュ、プラグイン実行スレッドの予期せぬ終了、または、プラグインによる長い間のメモリまたはプロセッサ資源の過剰な消費とすることができる。ここで、ローダ・プロセスは、セルフチェックにより異常の理由を特定することができ、あるいは、異常の理由は、クライアントの他のチェックプログラムでローダ・プロセスを検出することにより特定され得る。
【００４２】
また、クライアントは、ローダ・プロセスの異常情報を、周期的なハートビート・レポートの形で取得することもできる。すなわち、ローダ・プロセスが、いわゆるハートビートというメッセージを周期的にコア・アプリケーションに送信し、クライアントのコア・アプリケーションが、一定の時間、ローダ・プロセスのハートビート・レポートを受信しないと、それはローダ・プロセスが異常となることを示している。
【００４３】
ステップ３０２において、異常情報が保存される。一部の実施形態では、その情報はクライアントからサーバに送信される。一部の実施形態では、その情報はローカルに保存される。
【００４４】
異常情報の収集の後に、プラグイン安定性レベルは、収集された異常情報に基づいて周期的に調整され得る。図４は、プラグインの安定性レベルを周期的に調整するプロセスの一実施形態を示すフローチャートである。このプロセスは、１５０のようなシステム上で実行することができる。この例では、プラグインが再起動されるたびに、何らかの問題が発生すると仮定し、従って異常動作を示す傾向にあるとする。この場合、ある期間中にプラグインが使用される回数が、プラグインの安定性レベルを測定するために利用される。
【００４５】
ステップ４０１において、プラグインが所定期間の間に使用される回数が取得される。例えば、プラグインが、ひと月で１２０回実行されたと判断される。一部の実施形態では、クライアントがサーバにアクセスして特定のプラグインの安定性レベルを取得するたびに、サーバは、プラグインの使用回数を１だけインクリメントする。このようにして、一定の時間で各プラグインが使用される回数が、保存される。一部の実施形態では、クライアントがプラグインの安定性レベルをローカルに取得するたびに、プラグインの使用回数が１でインクリメントされる。このように、クライアントも、所定期間での各プラグインの使用回数を保存し得る。
【００４６】
ステップ４０２において、取得した使用回数が所定の閾値と比較される。取得した使用回数が、所定の閾値以上である場合には、安定性レベルを調整するため、制御がステップ４０３に移行する。そうでない場合は、プラグインの使用率が高くなく、安定性レベルを調整する必要がないので、プロセスは、それ以上のアクションを起こすことなく終了する。
【００４７】
ステップ４０３では、異常情報に基づき、プラグインが異常動作する回数が保存される。クライアントまたはサーバによって各回ごとに取得される異常情報は、プラグイン情報を含んでいる。従って、所定期間の間にプラグインが異常動作する回数（例えば、ひと月で異常が３０回発生したなど）は、プラグイン情報を調べることにより特定することができる。
【００４８】
ステップ４０４において、プラグインの安定性レベルは、プラグインが使用される回数とプラグインが異常動作した回数とに応じて調整される。一例では、３つの安定性レベル、すなわち、安定、普通、および不安定が用いられる。上限閾値および下限閾値が設定される。プラグインが異常動作した回数をプラグインが使用される回数で除算して得られる値が上限閾値以上である場合は、プラグインの安定性レベルは不安定であり、異常が発生した回数をプラグインが使用される回数で除算して得られる値が下限閾値以下である場合は、プラグインの安定性レベルは安定であり、異常回数を使用回数で除算して得られる値が下限閾値と上限閾値の間にある場合は、プラグインの安定性レベルは普通である。例えば、プラグインの初期安定性レベルは普通であって、ひと月といった現行の調整期間における使用回数が１２０回であり、異常回数が３０回である。上限閾値が２０％であり、下限閾値が５％である場合、３０／１２０＝２５％が、２０％という閾値よりも大きいので、プラグインの安定性レベルは不安定として調整される。
【００４９】
他の実施形態では、異なる数の安定性レベルを使用することができる。例えば、一部の実施形態では、２つのみの安定性レベル、すなわち安定および普通を使用し、１つのみの閾値が設定される必要がある。異常回数を使用回数で除算して得られる値が閾値よりも大きい場合は、プラグインの安定性レベルは普通であり、そうでない場合は、安定である。また、安定、比較的安定、普通、および不安定と設定される４つの安定性レベルとすることもでき、この場合、３つの閾値が、それぞれ大きい閾値のものから小さいものまで、第１の閾値、第２の閾値、および第３の閾値として設定される必要がある。この場合、異常回数を使用回数で除算して得られる値が第１の閾値以上であると、プラグインの安定性レベルは不安定であり、異常回数を使用回数で除算して得られる値が第２の閾値以上であり第１の閾値未満である場合は、プラグインの安定性レベルは普通であり、異常回数を使用回数で除算して得られる値が第３の閾値以上であり第２の閾値未満である場合は、プラグインの安定性レベルは比較的安定であり、異常回数を使用回数で除算して得られる値が第３の閾値未満である場合は、プラグインの安定性レベルは安定である。
【００５０】
ステップ４０５において、使用回数および異常回数がリセットされる。一部の実施形態では、これらの数を追跡するために用いられるカウンタが、次の調整サイクルに備えてクリアされる。
【００５１】
一部の実施形態では、いくつかのプラグイン安定性レベルと複数の共有ローダ・プロセスとが用いられる。例えば、いくつかの安定性レベル、すなわち、安定、比較的安定、普通、および不安定が用いられる。安定であると判断された全てのプラグインは、１つの共有ローダ・プロセスで実行され、比較的安定であると判断された全てのプラグインは、別の１つの共有ローダ・プロセスで実行される。従って、取得された安定性レベルが安定である場合は、それに対応するプラグイン実行モードにより、プラグインは第１の共有ローダ・プロセスで実行され、取得された安定性レベルが比較的安定である場合は、それに対応するプラグイン実行モードにより、プラグインは第２の共有ローダ・プロセスで実行され、取得された安定性レベルが普通である場合は、それに対応するプラグイン実行モードにより独立ローダ・プロセスが起動されて、これによりプラグインが実行され、取得された安定性レベルが不安定である場合は、それに対応するプラグイン実行モードにより、プラグインの実行が停止される。安定性レベルとプラグイン実行モードとの間の対応関係は保存される。
【００５２】
図５は、プラグインを実行するように構成されたクライアントシステムの一実施形態を示すブロック図である。このシステムは、第１の取得ユニット５１０と、記憶ユニット５２０と、第１の決定ユニット５３０と、実行ユニット５４０とを備えている。この例および以下の例では、システムに含まれるユニットおよびサブユニットは、１つまたは複数のプロセッサ上で実行されるソフトウェア・コンポーネントとして、プログラマブル・ロジック・デバイスおよび／または特定の機能を実行するように設計された特定用途向け集積回路（Ａｐｐｌｉｃａｔｉｏｎ  Ｓｐｅｃｉｆｉｃ  Ｉｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉｔｓ）などのハードウェアとして、あるいはそれらの組み合わせにより、実現することができる。一部の実施形態では、ユニットおよびサブユニットは、ソフトウェア・プロダクトの形態で実現することができ、これらは不揮発性記憶媒体（光ディスク、フラッシュ記憶装置、モバイル・ハードディスクなど）に記憶することが可能であって、本発明の実施形態に記載した方法をコンピュータ機器（パーソナルコンピュータ、サーバ、ネットワーク装置など）に実行させるための多くの命令を含むものである。システムに含まれるユニットおよびサブユニットは、単一の機器で、あるいは複数の機器に分散させて、実現することができる。
【００５３】
第１の取得ユニット５１０は、実行されるプラグインの安定性レベルを取得するように構成されている。記憶ユニット５２０は、安定性レベルと実行モードとの間の対応関係を保存するように構成されている。
【００５４】
第１の決定ユニット５３０は、記憶ユニット５２０に保存されている安定性レベルと実行モードとの間の対応関係に基づいて、取得された安定性レベルに対応するプラグイン実行モードを決定するように構成されている。
【００５５】
実行ユニット５４０は、実行されることになっているプラグインを、決定されたプラグイン実行モードに従って実行するように構成されている。
【００５６】
一部の実施形態では、上記ユニットの各々は、クライアントにおける独立したプログラムである。一部の実施形態では、第１の取得ユニット５１０、記憶ユニット５２０、および第１の決定ユニット５３０の機能は、コア・アプリケーションにより実行され、実行ユニット５４０の機能は、ローダ・プロセスにより実行される。
【００５７】
クライアントは、第２の取得ユニットをさらに備えており、これは、プラグインの異常動作の理由とプラグイン情報とを含む、プラグイン実行の異常情報を取得するように構成されている。記憶ユニット５２０は、さらに異常情報を記憶するように構成されている。
【００５８】
こうして、一定時間が開始されると、クライアントは、記憶ユニットに保存されている異常情報に基づいて、一定時間内にプラグインが異常となる回数を決定し、異常回数に応じて、プラグインの安定性レベルを調整する。具体的には、クライアントは、一定時間内での使用回数が閾値を超えるプラグインのプラグイン情報を取得して、情報を取得したプラグインが一定時間内に異常となる回数を、保存されている異常情報に基づいて決定し、その異常回数に応じてプラグインの安定性レベル調整し、そして、異常回数および使用回数をリセットするものとすることができる。
【００５９】
一部の実施形態では、クライアントは、第２の取得ユニットにより取得される異常情報を送信するように構成された送信ユニットをさらに備え得る。
【００６０】
本願の一実施形態では、実行されるプラグインの安定性レベルを、サーバに保存されているプラグイン安定性レベルから取得するようにすることができる。図６は、プラグインを実行するシステムの一実施形態を示すブロック図である。この例では、システムは、クライアント１００とサーバ２００とを含んでいる。
【００６１】
クライアント１００は、実行されるプラグインの安定性レベルを、サーバ２００に保存されているプラグイン安定性レベルから取得し、取得した安定性レベルに対応するプラグイン実行モードを、保存されている安定性レベルと実行モードとの間の対応関係に基づいて決定し、そして、実行されることになっているプラグインを、決定されたプラグイン実行モードに従って実行するように構成されている。サーバ２００は、プラグイン安定性レベルを保存するように構成されている。
【００６２】
図示のように、クライアント１００は、第１の取得ユニット１１０と、記憶ユニット１２０と、第１の決定ユニット１３０と、実行ユニット１４０とを備えており、第１の取得ユニット１１０は、実行されるプラグインの安定性レベルを取得するように構成されている。記憶ユニット１２０は、安定性レベルと実行モードとの間の対応関係を保存するように構成されている。
【００６３】
第１の決定ユニット１３０は、取得した安定性レベルに対応するプラグイン実行モードを、記憶ユニット１２０に保存されている安定性レベルと実行モードとの対応関係に基づいて決定するように構成されている。
【００６４】
実行ユニット１４０は、実行されることになっているプラグインを、決定されたプラグイン実行モードに従って実行するように構成されている。クライアント１００は、プラグイン実行の異常情報を取得するように構成された第２の取得ユニット１５０をさらに備えており、そして、記憶ユニット１２０は、その異常情報をさらに記憶するように構成されている。
【００６５】
クライアント１００によるプラグインの実行が異常になると、クライアント１００はさらに送信ユニット１６０を備えているので、これがプラグインの異常情報を取得して、サーバ２００にその異常情報を送信するように構成されており、その場合の異常情報は、異常動作の理由とプラグインのプラグイン情報とを含んでいる。
【００６６】
また、サーバ２００は、記憶ユニット２１０を備えており、これはプラグイン安定性レベルを保存するだけではなく、さらに異常情報を受信および保存するように構成されている。サーバ２００は、さらに調整ユニット２２０を備えており、これは、所定期間の経過後に、記憶ユニット２１０に保存されている異常情報に基づいて、一定時間内にプラグインが異常となる回数を特定し、その回数に応じてプラグインの安定性レベルを調整するように構成されている。
【００６７】
様々な実施形態で、実行されるプラグインの安定性レベルを取得し、取得した安定性レベルに対応するプラグイン実行モードを、保存されている安定性レベルと実行モードとの間の対応関係に基づいて決定し、そして、実行されることになっているプラグインを、決定されたプラグイン実行モードに従って実行する。このようにして、安定性レベルの異なるプラグインを異なるローダ・プロセスで実行することが可能であり、プラグインの不安定性に起因してコア・アプリケーションが機能停止する状況が回避される場合があり、ネットワーク・ツールの安定性を向上することができる。安定性の高いプラグイン、および安定性レベルが同じプラグインを、１つの共有ローダで実行することにより、クライアントのシステム資源を節約することができ、さらに、クライアントシステムの安定性を向上させることができる。また、プラグインの異常情報を収集して、プラグインの安定性レベルを動的に調整することにより、不安定なプラグインは排除することができ、これによりユーザエクスペリエンスを向上することができる。
【００６８】
当然のことながら、本発明は、本発明の趣旨および範囲から逸脱することなく、当業者により様々に変形および変更されることが可能である。従って、本発明に対するそれらの変形および変更が、本発明の特許請求の範囲およびその等価物の範囲内である場合は、本発明は、そのような変形および変更を全て含むものとする。
【００６９】
上記の実施形態は、明確な理解を目的として、ある程度詳細に記載したが、本発明は、提示した詳細に限定されるものではない。本発明を実施する多くの代替の方法がある。開示された実施形態は、例示であって、限定するものではない。
適用例１：プラグインを実行する方法であって、実行されるプラグインの安定性レベルを取得することと、少なくとも部分的に前記安定性レベルに基づいて、利用可能な複数のプラグイン実行モードから選択される、プラグイン実行モードを決定することと、前記決定されたプラグイン実行モードに従って、前記プラグインを実行することと、を備える方法。
適用例２：適用例１に記載の方法において、前記プラグインの安定性レベルは、記憶場所から取得される、方法。
適用例３：適用例１に記載の方法において、前記複数のプラグイン実行モードは、利用可能な複数のプラグイン安定性レベルに対応している、方法。
適用例４：適用例１に記載の方法において、前記複数のプラグイン実行モードは、複数のローダ・プロセスに対応しており、前記決定されたプラグイン実行モードに従う前記プラグインの実行は、前記複数のローダ・プロセスのうち、前記決定されたプラグイン実行モードに対応するローダ・プロセスを起動させて、前記プラグインをロードすることを含む、方法。
適用例５：適用例４に記載の方法において、前記プラグインの安定性レベルが安定である場合には、前記ローダ・プロセスは共有ローダ・プロセスである、方法。
適用例６：適用例４に記載の方法において、前記プラグインの安定性レベルが普通である場合には、前記ローダ・プロセスは独立ローダ・プロセスである、方法。
適用例７：適用例４に記載の方法において、前記プラグインの安定性レベルが不安定である場合には、前記方法は、前記プラグインの実行を停止させることをさらに備える、方法。
適用例８：適用例４に記載の方法において、前記プラグインの安定性レベルが不安定である場合には、前記方法は、前記プラグインの異常情報を取得および保存することをさらに備える、方法。
適用例９：適用例８に記載の方法において、前記異常情報は、前記プラグインの異常動作の理由と、前記プラグインのプラグイン情報とを含む、方法。
適用例１０：適用例１に記載の方法はさらに、前記プラグインの安定性レベルを調整することを備える、方法。
適用例１１：適用例１０に記載の方法において、前記プラグインの安定性レベルの調整は、前記プラグインが所定期間の間に異常動作した回数を決定することと、前記プラグインが所定期間の間に異常動作した回数の前記決定に少なくとも部分的に基づいて、前記プラグインの安定性レベルを調整することと、を含む、方法。
適用例１２：プラグインを実行するシステムであって、１つまたは複数のプロセッサであって、実行されるプラグインの安定性レベルを取得し、少なくとも部分的に前記安定性レベルに基づいて、利用可能な複数のプラグイン実行モードから選択される、プラグイン実行モードを決定し、前記決定されたプラグイン実行モードに従って、前記プラグインを実行するように構成されている、プロセッサと、前記１つまたは複数のプロセッサに結合された１つまたは複数のメモリであって、前記１つまたは複数のプロセッサに命令を提供するように構成されているメモリと、を備えるシステム。
適用例１３：適用例１２に記載のシステムにおいて、前記プラグインの安定性レベルは、記憶場所から取得される、システム。
適用例１４：適用例１２に記載のシステムにおいて、前記複数のプラグイン実行モードは、利用可能な複数のプラグイン安定性レベルに対応している、システム。
適用例１５：適用例１２に記載のシステムにおいて、
前記複数のプラグイン実行モードは、複数のローダ・プロセスに対応しており、前記決定されたプラグイン実行モードに従う前記プラグインの実行は、前記複数のローダ・プロセスのうち、前記決定されたプラグイン実行モードに対応するローダ・プロセスを起動させて、前記プラグインをロードすることを含む、システム。
適用例１６：適用例１５に記載のシステムにおいて、前記プラグインの安定性レベルが安定である場合には、前記ローダ・プロセスは共有ローダ・プロセスである、システム。
適用例１７：適用例１５に記載のシステムにおいて、前記プラグインの安定性レベルが普通である場合には、前記ローダ・プロセスは独立ローダ・プロセスである、システム。
適用例１８：適用例１５に記載のシステムにおいて、前記プラグインの安定性レベルが不安定である場合には、前記１つまたは複数のプロセッサは、さらに、前記プラグインの実行を停止させるように構成されている、システム。
適用例１９：適用例１５に記載のシステムにおいて、前記プラグインの安定性レベルが不安定である場合には、前記１つまたは複数のプロセッサは、さらに、前記プラグインの異常情報を取得および保存するように構成されている、システム。
適用例２０：適用例１２に記載のシステムにおいて、前記１つまたは複数のプロセッサは、さらに、前記プラグインの安定性レベルを調整するように構成されている、システム。
適用例２１：適用例２０に記載のシステムにおいて、前記プラグインの安定性レベルの調整は、前記プラグインが所定期間の間に異常動作した回数を決定することと、前記プラグインが所定期間の間に異常動作した回数の前記決定に少なくとも部分的に基づいて、前記プラグインの安定性レベルを調整することと、を備えている、システム。
適用例２２：プラグインを実行するためのコンピュータプログラム・プロダクトであって、前記コンピュータプログラム・プロダクトはコンピュータ読み取り可能な記憶媒体に埋め込まれ、実行されるプラグインの安定性レベルを取得し、少なくとも部分的に前記安定性レベルに基づいて、利用可能な複数のプラグイン実行モードから選択される、プラグイン実行モードを決定し、前記決定されたプラグイン実行モードに従って、前記プラグインを実行するためのコンピュータ命令を含む、コンピュータプログラム・プロダクト。
【図１Ａ】
0005523550.tif 000002
【図１Ｂ】
0005523550.tif 000003
【図２】
0005523550.tif 000004
【図３】
0005523550.tif 000005
【図４】
0005523550.tif 000006
【図５】
0005523550.tif 000007
【図６】
0005523550.tif 000008