JP2008502067A - コンピュータ装置においてプラグイン・コード・モジュールを選択する方法 - Google Patents

Abstract

コンピュータ装置上のアプリケーションにより実行されるプラグインは、利用可能な複数のプラグインに対して、各プラグインが先のプラグインよりアプリケーションにより要求された基準に適合するかを連続して問い合わせることをサーバが繰り返すように構成することにより選択される。基準に最も適合するプラグインは、アプリケーションにより実行される。

Description

本発明は、コンピュータ装置を動作させる方法に関し、特に、装置が多くのプラグインのうち装置上の要求アプリケーションにより特定される属性に最も適合するプラグインを得ることができるように装置を動作させる方法に関する。

本明細書において使用される用語「コンピュータ装置」は、任意の形態のコンピュータ装置を含むように広範囲に解釈され、任意の形態のデータ記録装置、ハンドヘルドコンピュータ及びパーソナルコンピュータを含む任意の種類又は形態のコンピュータ、並びに、単一装置内で通信、画像の記録と再生との少なくともいずれか、及び演算機能性を組み合わせた移動電話、スマートフォン、通信機及び他の形態の無線／有線情報装置を含む任意の形態の通信装置を含む。

プラグインは、実行時にプラグインをロード又は呼び出し可能な疎結合アプリケーションに対して特定のサービスを提供する実行可能コードの置換可能な項目として定義される。プラグインは、通常、ダイナミック・リンク・ライブラリ（ＤＬＬ）又は同様の種類のモジュールとしてロードされる。それらモジュールは、個別のプロセスとして生成及び実行されてもよいが、それらモジュールを呼び出すアプリケーションと同じプロセス空間内で実行する。

プラグインは、多くのオペレーティングシステムにおいて広く使用され、また、多くのアプリケーションにより広く使用される。この技術の主な利点は以下の通りである：
・新しい機能が要求された時にプラグインモジュールを追加又は置換できるため、プラグインを使用できるアプリケーションは本質的に拡張可能である。
・プラグインの動作コードは、要望に応じてのみアプリケーションによりロードされるため、プログラムによるデバイスメモリの要求量が少なくなり、起動が迅速になる。

この技術は、特許文献１（Eolas特許として周知である）の主題であったMicrosoft Internet Explorer及びNetscape等のウェブブラウザにおけるプラグインの一般的な組込みを通して、コンピュータ装置の殆どのユーザによく知られている。プラグインの使用を示す最も一般的なものには、ブラウザ内でＪａｖａ（登録商標）アプレットを実行する基本原理の他に、ブラウザアプリケーションがプラグインに依存して特定の種類のコンテンツを提供することがある。マルチメディアファイルに関連してプラグインを使用することは、特に一般に普及している。

プラグインは、定義上、プラグインをロードするアプリケーションに本質的に依存しないため、プラグイン技術を使用する全てのシステムは、アプリケーションに対して、利用可能なプラグインを認識させるとともに、それらプラグインをロード又は呼び出す方法を知らせる機構を提供する必要がある。

MicrosoftのＯＬＥ技術のみに依存するWindows（登録商標）アプリケーションにより使用される機構のような初期の機構は、プラグイン名及びその位置に対するハードコーディングされたリンクを必要とした。これは、プラグインの置換のみを可能にし、別のプラグインコンポーネントの追加を可能にするためにホストアプリケーションの更新を必要とするため、満足のいくものではなかった。

次の機構は、プラグインの名前及び位置をレジストリ又はプラグイン・データベースに格納する。これは、柔軟性（flexibility）があり拡張可能であるため、名前のハードコーディングより優れていると考えられる。柔軟性を最大限にするとともに、同じプラグインが異なるアプリケーションにより使用されるように、そのようなレジストリ又はデータベースは、通常、アプリケーション別のものではなくシステム全体にわたるものである。従って、アプリケーションと共通のサービスを提供するプラグインとの間に１つ以上の中間層が提供されるのが一般的である。共通のサービスは、以下のことを含む。
・アプリケーションに対する適切な登録プラグインの位置。
・可能なプラグイン候補のうち呼び出されるべきプラグインを決定する。
・アプリケーションの代わりにプラグインをインスタンス化する。

Microsoftのコンポーネント・オブジェクト・モデル（ＣＯＭ）は、これを行なう周知の方法の１つである。この方法により、オペレーティングシステムは、レジストリにおいてプラグインモジュールの位置を特定し、インスタンス化を処理し、さらに呼び出しをアプリケーションからプラグイン・インスタンスにリダイレクト（redirect）する中間層を提供する。ＣＯＭは、ソフトウェア製造業者が既存のアプリケーションの再構築を必要とせずに新しいアクセサリを既存のアプリケーションにプラグインできるように開発された。従って、ＣＯＭコンポーネントは、ローカル・インプロセス（local in-process）ＤＬＬであってもリモートサーバ実行ファイルであっても、交換可能なプラグインとして設計されるべきである。

Sun Microsystemsの特許文献２において、「プログラムオブジェクトを発見及び結合するためのシステム及び方法（A System and Method for discovering and binding a program object）」が説明される。これにより、中間層は、レジストリを使用してプラグインを発見及びインスタンス化し、アプリケーションがプラグインと直接通信できるようにインスタンスに対する参照をアプリケーションに返す。

このようなシステム全体にわたる機構は、アプリケーション別のプラグイン・マネージャ等のより一般的ではない中間レベルと組み合わされるか、あるいは複数の同時アプリケーションを提供するためにプラグインが使用されることを可能にする専用サーバと組み合わされることが多い。

現在の技術に対する１つの課題は、多くのプラグイン候補が存在する場合、最適なプラグインを選択することは高度な技術的処理であり、それは、最適な選択を行なうために潜在的に複雑な意思決定機能又はアルゴリズムを必要とすることである。

そのような決定を行なう中間層に基づく任意の方法は、可能性として複雑な状態情報を維持するとともに、専門情報（specialised information）に関係することを必要とする。中間層がどの程度一般的であるかに依存して、全ての種類の既存のプラグインに対するルーチンを含むことにより不必要に肥大化したコードを得る可能性がある。これは、アーキテクチャに関して、プラグインの位置の特定及びインスタンス化等の共通のサービスを提供することに限定するべきである一般的なサービス層の役割と相反する。従って、全ての種類の中間層は、中間層が作成された時に認識されていなかった新しい種類のプラグインに対処するには不十分であろう。

これらの問題を示す１つの特定の例は、移動電話等の無線情報装置の位置情報サービス（ＬＢＳ：Location Based Services）の実現例である。ＬＢＳは、位置に基づく情報、位置による課金、緊急サービス及び位置追跡を含む。これらの全ての特徴は、どこに存在することができるかを知らせることができる（ポジショニング：positioning）移動電話に依存する。しかし、ポジショニング情報を取得する多くの異なる方法が存在する。最も広く認識されるシステムは、全地球測位システム（ＧＰＳ）を使用する。セルの三角測量等の別の技術も使用されるが、それら技術のうちの多くはネットワークに基づく技術である。ポジショニング情報を取得するために利用可能な方法は、今後拡張すると考えられている。例えば、欧州のガリレオプロジェクトは、最終的にはＧＰＳに代わるシステムを提供するだろう。

アプリケーションがポジショニング情報を取得するために任意の方法を使用できるようにするＬＢＳを実現するプラグイン設計は、非常に適切であり、重大な利点を提供することを当業者は認識するだろう。これは、以下の理由による：
・上述の全てのポジショニング技術は、同一の情報の種類を提供する。
・これらは、同じアプリケーション・プログラミング・インタフェース（ＡＰＩ）に正確に適合(conform)するように作成することができる。
・一般に、アプリケーションは、これらのうちのいずれかのみを使用する必要がある。

しかし、位置を取得する上記技術は、精度、必要な電力、ユーザに対するコスト、及び位置測位情報取得時間など、非常に異なる特性を有する。従って、呼び出す技術を選択することは、多くの要因に依存する複雑な技術である。プラグインを呼び出す中間層は、それら要因を全て考慮することはできない。最悪の場合、ポジショニング情報を取得する方法について適切な決定を行なえないため、単純な「最終適合」機構を使用することになり、それにより、適切なＡＰＩに適合する最後にインストールされた適合するプラグインがインスタンス化される。

特定の状況に対して特定のプラグインを選択することが好都合となる十分に異なる方法で特定のタスクを実行できる利用可能な複数のプラグインを装置が有する状況において、使用されるべきプラグインを自動的に判定する柔軟性のある拡張可能な方法は、現在存在しないことは明らかである。
米国特許第５，８３８，９０６号公報 国際公開第００／６７１１４号パンフレット

従って、本発明の目的は、コンピュータ装置においてプラグインを選択するための改良された方法を提供することである。

本発明の第１の側面によれば、コンピュータ装置上で実行するソフトウェア・アプリケーションがコード・モジュールの集合のうち最適なコード・モジュールを実行させることを可能にする方法であって、
ａ）前記最適なコード・モジュールが有するべき特性又はプロパティを識別する工程と、
ｂ）直接又は１つ以上の中間層を介して、前記特性又はプロパティを機能的に互換性のある可能なコード・モジュールの各々に渡す工程と、
ｃ）前記コード・モジュールを使用して、前記コード・モジュールが前記特性又はプロパティにどの程度適合するかの決定論的計算をそれぞれ実行し、前記ソフトウェア・アプリケーション又は中間層に数値のスコアの結果を返す工程と、
ｄ）前記ソフトウェア・アプリケーションにより直接に、又は、中間層により実行されるインスタンス化を介して、最良のスコアを有するモジュールを実行する工程と、を備える方法が提供される。

本発明の第２の側面によれば、第１の側面の方法に従って動作するように構成されるコンピュータ装置が提供される。

本発明の第３の側面によれば、第１の側面の方法に従って第２の側面によるコンピュータ装置を動作させるオペレーティングシステムが提供される。

LondonのSymbian Software Ltdにより作成された移動電話用のSymbian OS（商標）オペレーティングシステムは、１９９７年の最初のリリース以来、プラグインを広範囲にわたり使用してきた。プラグインは、従来、上述の中間層の種類によりロードされるポリモーフィック（polymorphic：多形の）ＤＬＬに基づいていたが、自身のプロセス空間で実行する実行ファイルとして実現することが多く提案されつつある。本発明は、いずれの種類のプラグインに対しても適用可能である。

本明細書で説明される本発明は、ＬＢＳに関して先に概要を説明した問題の解決方法を説明するが、本発明に基づく原理が可能なプラグイン間で選択を行なう必要のある任意の状況に同等に適用可能であることは、当業者には容易に理解されるだろう。従って、ＬＢＳの例は、例示する目的で使用されるものであり、他の分野において本発明の範囲又は適用性を限定するものとして解釈されるべきではない。同様に、当業者には明らかであるように、本明細書において説明されるようなSymbian OS（商標）オペレーティングシステムは、例示する目的で使用されるものであり、他のオペレーティングシステムに対して本発明の範囲又は適用性を限定するものとして解釈されるべきではない。

Symbian OS（商標）オペレーティングシステムの位置情報サービス・ポジショニング・サブシステムは、クライアント／サーバ・フレームワーク・アーキテクチャを採用し、複数のクライアント（アプリケーション）が複数のロケーション技術から装置の位置の周期的な更新データを検索できるようにする。

このアーキテクチャは、技術非依存であり、一貫したアプリケーション・プログラム・インタフェース（ＡＰＩ）を介してアクセスされる、シングルトン（singleton）・ロケーション・サーバを含む。ＡＰＩは、上述した任意の方法に適切な技術非依存の抽象層を提供する。

サーバは、ロケーション技術別のモジュールに対するアクセス権を管理する。モジュールは、プラグインとして実現される。モジュールは、オペレーティングシステムに動的に追加又はオペレーティングシステムから動的に除去され、クライアント・アプリケーションが知る必要なくロケーション・サーバにより検出されて使用される。

クライアントがロケーション・サーバに接続する場合、クライアントは、使用されるロケーション技術の所望のプロパティ又は必要とするプロパティを特定するために基準オブジェクトを提供できる。それら基準オブジェクトは、抽象ＡＰＩにおいて特定され、水平精度、垂直精度又は初期測位時間等のサービス品質（ＱｏＳ）パラメータを特定することを可能にする。費用及び電力消費等のアプリケーションにとって関心のある可能性がある他のパラメータも更に特定される。

本発明を使用して、ロケーション・サーバは、利用可能な複数のプラグインに対して、各プラグインが先のプラグインよりクライアントにより特定された基準に適合するかを連続して問い合わせることを繰り返す。ロケーション・サーバ自体は、「より適切である／適切でない」の結果がプラグインからプラグインへ搬送される方法を知らない。

本願において説明された方法は、プラグインが特定のＱｏＳ基準にどの程度適合するかを反映するスコアの決定論的（deterministic）計算を実行できる各プラグインに基づく。この計算では、各プラグインが知る「次の測位までの時間」等の属性の現在の値を使用する。計算は決定論的であり、各プラグインは適正さを保証するために同じルールに従い、正確な決定が常に行なわれる。最終的な選択を行なう多くの異なるアルゴリズム又は方法が可能である。その例は以下の通りである：。

１．サーバコンポーネントは、各プラグインをクエリして、最大の（すなわち、最も適合する）スコアを返すプラグインを常に監視し、全てのプラグインがクエリされると、最大のスコアを有するプラグインを選択する。

２．サーバコンポーネントは、各プラグインを順にクエリし、その時点までの最大のスコアを各プラグインに渡す。プラグインがそのスコアに「勝つ」ことができない場合、プラグインは、自身を考慮すべきものから除去する。プラグインがそのスコアに勝つ場合、プラグインは、最大のスコアを有することをサーバに知らせる。

これらの方法のうち第１の方法は、サーバコンポーネントによるある限定された意思決定を必要とし、第２の方法は、サーバが全く関係しないような意思決定を真に受け継ぐものである。しかし、本発明は、これら２つの方法に限定されず、当業者が考案する任意のアルゴリズムと協働するだろう。

本発明は、スコアを計算する（すなわち、決定論的計算に対する発行されたルールに従う）時に正常に挙動するプラグインに依存する。全ての場合において、呼び出すプラグインが適切に挙動することをアプリケーションが信頼する必要があるため、これは、関係する原理が不足するとは考えられず、追加の危険性もない。しかし、プラグインがよく考慮されずに信頼されるべきではないと決定された場合、プラグインがインストールされる時、テストされる時、検証（verify）される時、又は署名される時等、適切な時点で各プラグインの挙動をチェックすることが依然として可能である。あるいは、アプリケーションは、ウォッチドッグ（watchdog）又は他の機構により、実行時にプラグインの挙動の動的なチェックを実行してもよい。

本発明は、以下の利点を提供すると考えられる：
・アプリケーションが同等のサービスを提供する複数のプラグインを利用できる場合、本発明は、全てのアーキテクチャに適用可能である。
・本発明は、アプリケーション及びオペレーティングシステムのプラグインアーキテクチャの全ての中間レベルにおいて、潜在的に複雑な意思決定機能の必要性をなくす。
・本発明は、プラグインの選択を最適化する役割がプラグイン自体に効果的に渡される方法を説明する。
・本発明は、中間層とそれらが提供するプラグインモジュールとの間の不必要な依存性の発生を回避することにより、適切な設計を実現する。

本発明は、要求アプリケーションにより特定される所望のプロパティの集合に最も適合するプラグインを利用可能なプラグインの集合から得ることを可能にする方法及び装置を特定する。

プラグインの集合の各メンバ（member）は、所望のプロパティの集合にどの程度適合するかの決定論的計算を実行し、数字のスコアの結果を返すように要求される。

これにより、装置を制御するソフトウェアの任意の他の部分による明らかな介入又はソフトウェアの任意の他の部分における意思決定機能を必要とせずに最適なモジュールを選択できる。

本発明は、特定の実施形態を参照して説明されたが、添付の請求の範囲により規定されるように、本発明の範囲から逸脱せずに変更が行なわれてもよいことが理解されるだろう。

Claims (12)

1. コンピュータ装置上で実行するソフトウェア・アプリケーションがコード・モジュールの集合のうち最適なコード・モジュールを実行させることを可能にする方法であって、
   ａ）前記最適なコード・モジュールが有するべき特性又はプロパティを識別する工程と、
   ｂ）直接又は１つ以上の中間層を介して、前記特性又はプロパティを機能的に互換性のある可能なコード・モジュールの各々に渡す工程と、
   ｃ）前記コード・モジュールを使用して、前記コード・モジュールが前記特性又はプロパティにどの程度適合するかの決定論的計算をそれぞれ実行し、前記ソフトウェア・アプリケーション又は中間層に数値のスコアの結果を返す工程と、
   ｄ）前記ソフトウェア・アプリケーションにより直接に、又は、中間層により実行されるインスタンス化を介して、最良のスコアを有するモジュールを実行する工程と、を備える方法。
2. 前記最適なコード・モジュールは、前記ソフトウェア・アプリケーションと同じプロセスにおいて実行される請求項１記載の方法。
3. 前記最適なコード・モジュールは、中間層と同じプロセスにおいて実行される請求項１記載の方法。
4. 前記最適なコード・モジュールは、自身のプロセスにおいて実行される請求項１記載の方法。
5. 前記モジュールが中間層により実行される場合、前記中間層はシングルトン・サーバを備える請求項１から４のいずれか１項に記載の方法。
6. 前記コード・モジュールは、前記コンピュータ装置に動的に追加されうるか又は前記コンピュータ装置から動的に除去されうるプラグインと、前記ソフトウェア・アプリケーションが前記モジュールの存在又は位置を知ることなく前記中間層により動的に検出されうるプラグインと、の少なくともいずれかから構成される請求項１から５のいずれか１項に記載の方法。
7. １つ以上のコード・モジュールの実行を要求し、前記中間層及び前記コード・モジュールの各々に渡すために、識別された特性又はプロパティを単一オブジェクトへ収集することによって、前記コンピュータ装置において、前記特性又はプロパティは、前記ソフトウェア・アプリケーション又は他のエンティティにより少なくとも部分的に識別される、請求項１から６のいずれか１項に記載の方法。
8. 前記最良のスコアを有する前記コード・モジュールは、
   ａ）機能的に互換性のある独立したコード・モジュールの集合から各メンバをクエリし、各々に対するスコアを記録することと、
   ｂ）あるいは、ゼロの高いスコアから開始して現在の最大のスコアをコード・モジュールの集合の各メンバに渡し、各メンバに対するスコアが前記現在の最大のスコアより良いかをクエリすることと、
   のいずれかによって識別される、請求項１から７のいずれか１項に記載の方法。
9. コード・モジュールが前記特性又はプロパティに対して適合するか否かを判定するのに使用されるアルゴリズムに対する前記モジュールの挙動は、前記モジュールが前記コンピュータ装置にインストールされた時に検証されるか、あるいはインストール前に信頼機関により検証される、請求項１から８のいずれか１項に記載の方法。
10. 前記コード・モジュールは、位置に基づくサービスを可能にするための、ポジショニング技術又はアルゴリズムを実現するのに使用される請求項１から９のいずれか１項に記載の方法。
11. 請求項１から１０のいずれか１項に記載の方法に従って動作するように構成されるコンピュータ装置。
12. 請求項１から１０のいずれか１項に記載の方法に従ってコンピュータ装置を動作させる前記コンピュータ装置のためのオペレーティングシステム。