JP2018507499A - サービス管理方法及び装置 - Google Patents

Abstract

本発明は、サービス管理用の方法及び装置を提供し、この場合に、方法は、アプリケーションによるリモートターゲットサービスの使用の人気を検出するステップと、人気が、予め設定された第一閾値に到達した際に、ターゲットサービスをアプリケーションにローカルに読込むステップと、を具備する。本発明は、分散システムの応答効率及び適応能力を改善する。

Description

本発明は、ネットワーク技術の分野に関し、且つ、更に詳しくは、サービス管理用の方法及び装置に関する。

分散システムは、全体システムによって制御された協働方式によって同一のタスクを実行する複数の相互接続された処理リソースから構成されたコンピュータシステムである。タスクの実行は、複数のアプリケーションシステム内の様々なサービスユニットを伴う場合があり、且つ、主にリモート呼出しを通じて、これらの小さなサービスユニット間において、情報のやり取りが実行される。但し、リモート呼出しは、大量の時間が消費されるという結果をもたらすことになり、且つ、分散システムが特定の規模に成長した際に、この部分の消費がシステムの応答効率を大幅に低下させることになる。関連技術によれば、リモート呼出しによって消費される時間を節約するべく、アプリケーション分析が実施される場合があり、且つ、物理的に集中化された方式により、サービス依存性の関係を有するアプリケーションシステムを配備することができるが、このような方法は、相対的に乏しい柔軟性及び適合性しか有しておらず、且つ、アプリケーションに対する変更が存在する際に、分析及び配備を再度実行する必要があり、その結果、サービスの費用が増大すると共に、その性能に影響が及ぶことにもなる。

以上の内容に鑑み、本発明は、分散システムの応答効率及び適応能力を改善するべく、サービス管理用の方法及び装置を提供する。

具体的には、本発明は、以下の技術的解決策を通じて実装される。
第一の態様によれば、サービス管理用の方法が提供され、方法は、
アプリケーションによるリモートターゲットサービスの使用の人気を検出するステップと、
人気が、予め設定された第一閾値に到達した際に、ターゲットサービスをアプリケーションにローカルに読込む（load）ステップと、
を有する。

第二の態様によれば、サービス管理用の装置が提供され、装置は、
アプリケーションによるリモートターゲットサービスの使用の人気を検出するように構成された人気検出モジュールと、
人気が、予め設定された第一閾値に到達したことを人気検出モジュールが検出した際に、ターゲットサービスをアプリケーションにローカルに読込むように構成された移動制御モジュールと、
を有する。

本発明によるサービス管理用の方法及び装置によれば、サービスの人気が、予め設定された閾値に到達した際に、そのサービスがアプリケーションにローカルにダウンロードされ、その結果、リモート呼出しとの関係において分散システムの応答効率及び適応的能力が改善される。

図１は、本発明の一実施形態による分散システムアーキテクチャを示す。 図２は、本発明の一実施形態によるサービス管理用の方法のフローチャートである。 図３は、本発明の一実施形態によるサービス管理用の装置の構造図を示す。 図４は、本発明の一実施形態によるサービス管理用の別の装置の構造図を示す。

図１は、任意選択の分散システムアーキテクチャを示している。システムは、複数の処理リソースを有しており、これらの処理リソースは、例えば、データストレージサーバやＪＡＶＡ仮想マシンなどであってもよい。様々なアプリケーションシステムのサービス及びデータは、上述の処理リソース内において分散されている。以下、本実施形態によるサービス管理用の方法において使用されているいくつかの概念について簡潔に説明することとする。

サービス及びアプリケーション：銀行におけるユーザによる口座の開設を一例として使用すれば（このアプリケーションは、一例に過ぎないことに留意されたい）、全体的な口座開設プロセスには、１．ユーザのＩＤ情報の検証と、２．不良な信用状態の記録が存在するかどうかの検証と、３．新しい口座情報のセットアップと、という三つのステップが必要であるものと考えられる。そして、「ＩＤ情報の検証」、「信用状態の記録の検証」、及び「新しい口座情報のセットアップ」のそれぞれは、「サービス」と呼称されてもよく、「ＩＤ情報の検証」のサービスは、恐らくは、公的なセキュリティ機関の「アプリケーション」システムによって提供されてもよいが、「信用状態の記録の検証」及び「新しい口座情報のセットアップ」のサービスは、銀行の「アプリケーション」システムによって提供される。ユーザによる口座開設要求との関係においては、銀行のアプリケーションシステムが、この要求を受け付け、且つ、次いで、第一の検証ステップを実行するべく、公的なセキュリティ機関のアプリケーションシステムによって提供されるサービスをリモートで呼び出し、その後に、全体的な口座開設プロセスを最終的に完了させるべく、第二ステップ及び第三ステップがローカルに呼び出されるものと簡単に記述することができる。この解決策によれば、我々は、サービス及び「サービス」の配備を分割するための方法として、「アプリケーション」を単純に解釈することが可能であり、一つの「アプリケーション」は、一つ以上の「サービス」をユーザ又はその他の「アプリケーション」に提供することができる。ユーザ要求を実装するためのプロセスにおいて、アプリケーションシステム間におけるサービス依存性は、本実施形態においては、「サービスを使用するアプリケーション」又は「サービスを呼び出すアプリケーション」と呼称される。

データソースにアクセスするサービス：サービスのロジック実装プロセスには、通常、データアクセスが伴っており、例えば、上述の例におけるＩＤ情報の検証は、データベースが、検証対象のＩＤ情報を保存しているかどうかを問い合わせるべく、ＩＤデータベースを使用するものと考えられ、これには、「ＩＤ情報の検証」サービスによる「ＩＤデータベース」データソースに対するアクセスが伴っている。サービスは、データアクセスが正常である際にのみ、正常に実行することができる。図１に示されているように、データソースは、データベースという「データソース」、ファイルシステムという「ファイルシステム」、或いは、高速キャッシュという「キャッシュ」からのものであってもよい。

ローカルサービス及びリモートサービス：ローカル及びリモートに関連し、これら二つの概念は、その物理的な意味の観点において解釈されてもよく、即ち、アプリケーションによって呼び出されるサービスは、そのサービスが、アプリケーションが配備されているリソース上に存在していない際には、リモートサービスであり、さもなければ、それは、ローカルサービスであり、上述の例においては、銀行のアプリケーションシステムが処理リソースＡ上において配備されており、公的なセキュリティ機関のアプリケーションシステムが処理リソースＢ上において配備されている場合には、「ＩＤ情報の検証」サービスは、銀行のアプリケーションシステムにとっては、リモートサービスとなり、且つ、その他の二つのサービスは、銀行のアプリケーションシステムに属していることから、ローカルサービスである。換言すれば、銀行のアプリケーションシステムが「新しい口座情報のセットアップ」サービスを呼び出した際に、このサービスロジックは、処理リソースＡ上において配備されており、且つ、リソースＡ上において直接的に呼び出すと共に実行することが可能であり、その結果、これは、ローカルサービスであるということになる。その一方で、呼び出される「ＩＤ情報の検証」サービスが属するパブリックセキュリティアプリケーションシステムは、別の処理リソースＢ上において配備されており、且つ、その結果、銀行のアプリケーションシステムは、ネットワークを介して、サービス呼出し要求を処理リソースＢ上のアプリケーションに送信する必要があり、且つ、リモートサービス呼出しである「ＩＤ情報の検証」サービスによる実行結果の返送を待つ必要がある。

リモートサービス呼出しが、ネットワーク送信及び待機のために時間の消費を結果的にもたらすことは、明らかである。アプリケーションがリモートサービスを頻繁に呼び出す際には、特に、アプリケーションの実行効率が大幅に影響を受けることになり、分散システムの応答効率を改善すると共にサービス呼出しの時間の消費を低減するべく、本実施形態におけるサービス管理用の方法が使用されることになる。更には、従来の方式においては、アプリケーションシステムを配備するべく、重要なサービス経路上のサービスと、依存先のサービスと、を手動で分析することが必要であり、この場合に、これらのサービスは、物理的に近傍において配置されている。この結果、サービス分析要員の要件は、相対的に厳しくなり、且つ、全体システムの配備、動作、及び維持について、複雑性が増大し、重要なサービス経路が変化したり、或いは、依存性関係が変化した際に、再配備が必要とされ、その結果、サービスの安定性に影響が及ぶことになる。更には、これは、非常に柔軟性が乏しく、且つ、乏しい適合性しか有していない。本実施形態におけるサービス管理用の方法は、アプリケーションによるサービス呼出しに対して柔軟に適合するための分散システムの適応能力を更に改善することになる。更には、物理的に近傍の配備との関係において、本実施形態は、「サービス」の移動の粒度を低下させており、これは、機器費用を低下させるために好ましい。

図１に示されているように、本実施形態は、分散システム内において、サービス管理用の装置を追加しており、装置は、人気検出モジュールと、移動制御モジュールと、を有し、この場合に、サービス管理用の装置は、図２に示されているサービス管理用の方法のフローを実行することが可能であり、方法は、以下のステップを有する、

２０１．アプリケーションによるリモートターゲットサービスの使用の人気を検出する。

例えば、このステップにおいて、これは、人気検出モジュールが、アプリケーションによるリモートターゲットサービスの使用の人気を検出するというものであってもよいであろう。サービス管理用の装置は、実際の実装において多数の情報を要約及び記録し得るグローバル管理装置と見なされ得ることに留意されたい。以下の表１は、いくつかの任意選択の記録情報を例示的に列挙している。

以下、上述の表１内の情報について説明するが、アプリケーション及びサービスについては上述されており、従って、再度の詳述は、省略する。サービスの実行は、支援のために、複数のサービスに依存している場合がある。本実施形態におけるサービス管理用の方法は、サービスの移動を伴っているが、すべてのサービスが移動され得るわけではない。

サービスの移動：図１の例を参照すれば、処理リソースＡ上のアプリケーションＹ１は、サービスＳ３を使用する必要があり、サービスＳ３のロジックは、処理リソースＢ上において保存されている。アプリケーションＹ１が、処理リソースＢ上のサービスＳ３を呼び出した場合に、これが、サービスのリモート呼出しである。サービスＳ３は、処理リソースＢから処理リソースＡに移動されてもよく、この場合に、移動は、サービスロジックの移動を意味している。上述のように、サービスの実行は、恐らくは、データソースに対するアクセスを伴い得る。その結果、サービスの完全な実行は、「ロジック」と「データ」という二つの部分を有するものと見なすことができる。本実施形態におけるサービスの移動は、ロジックの移動を意味しており、且つ、ターゲットサービスのロジックのセグメントの複写が移動される。即ち、処理リソースＡが、サービスＳ３のロジックの複写をも保存するように、サービスＳ３のロジックが、同時に処理リソースＡ上において保存される。その結果、サービスＳ３の論理フローを処理リソースＡにおいてローカルに実行することができる。これに加えて、サービスＳ３は、Ｙ２に属しており、且つ、Ｙ１によってのみ、使用されることに留意されたい。移動（移動は、サービスロジックを複写するプロセスであり、且つ、サービスロジックの複写が移動される）が発生した場合にも、サービスＳ３は、依然として、Ｙ２に属しており、これは、変化しない。

移動可能なサービス：上述のように、サービスの移動は、ロジック、即ち、サービスによって定義されている処理フローのロジック、の移動のみを意味している。従って、サービスが、アプリケーションに移動された（アプリケーションに対応した処理リソースに移動された）場合には、そのアプリケーションが、サービスの正常な実行が依存しているリソースにアクセスできることが必要とされる。例えば、サービスＳ５の正常な実行は、データソース（ＭｙＳＱＬ及びＭｅｍｃａｃｈｅ）にアクセスすることを必要としているが、アプリケーションＹ１は、このデータソースにアクセスすることができないとしよう。その結果、サービスＳ５がアプリケーションＹ１に移動された後に、サービスＳ５を正常に実行させることができず、従って、サービスＳ５は、アプリケーションＹ１との関係において移動可能ではない。

サービスがアプリケーションとの関係において移動可能なサービスとなるためには、アプリケーションが、サービスによって必要とされているデータソースにアクセスできることが必要とされており、且つ、当然のことながら、その他の条件が課される場合もある。例えば、サービスは、明瞭な論理境界を有する独立的なサービスであり、且つ、その他のサービスとの間に複雑な相互依存性を有しておらず、且つ、更には、サービスは、容易に移動され得るように、完全であり、且つ、小さい。更には、サービスが、相互依存性の状態を有していない無状態サービスであることが必要とされる場合もある。これらは、いずれも、サービスを移動が容易なものにするためのものである。更には、サービスがアプリケーションに移動された後に、サービスのアクセス可能性が影響を受けるかどうかを考慮することもできよう。例えば、サービスは、移動の前には、データソースにアクセスする際に高効率を有しているが、移動の後に、様々な理由から、アプリケーションのサービス要件がもはや充足されないような程度にまで、サービスの実行効率が低下する。その結果、このサービスは、移動に適しているとは考えられなくなろう。更には、移動は、ローカルサービスの場合には、不要であることから、移動可能なサービスは、通常、アプリケーションにとって、リモートサービスであることに留意されたい。

分散システムは、多くのアプリケーションを有することができる。このステップにおいては、サービス管理用の装置は、いずれのサービスがいずれのアプリケーションに移動可能であるのかをグローバルに管理することが可能であり、それぞれのアプリケーションがアクセス可能であるデータソースを管理することが可能であり、且つ、アプリケーションが、サービスによって必要とされているデータソースを有しているかどうかの判定を促進するべく、データソースの名称を統合することもできる。これに加えて、サービス管理用の装置は、アプリケーションによる移動可能なサービスの使用の人気、サービスがアプリケーションに読込まれているかどうか、並びに、サービスが更新されているかどうか、のような情報を更に要約することもできる。

アプリケーションによる移動可能なサービスの使用の人気：「人気」は、主には、アプリケーションによるサービスの使用の頻度を通知するべく、使用される。例えば、サービスは、アプリケーションにより、１時間以内において、５０回にわたって呼び出されるが、当然のことながら、人気を通知するべくいずれのタイプの計測基準が具体的に使用されるのかは、実際の状況に従って柔軟に判定されてもよい。本実施形態においては、第一閾値及び第二閾値が、人気について設定されてもよく、第一閾値は、第二閾値を上回っており、且つ、第一閾値は、主には、人気値が閾値に到達するか又はこれを上回った際に、アプリケーションによるサービスの使用が非常に頻繁であり、且つ、アプリケーションの実行効率が影響を受ける許容限度に到達したことを通知するべく、使用される。サービス移動を実行可能であり、従って、サービスがアプリケーションに読込まれた場合に、第二閾値は、主には、人気値がこの閾値に到達するか又はこれを下回った際に、アプリケーションが、現時点において、サービスをほとんど使用していないことを通知するべく、使用され、且つ、処理リソースを節約するべく、サービスの逆読込み（unloading）が実行されてもよい。

更には、頻繁な読込み及び逆読込みを回避するべく、上述の第一閾値と第二閾値の間に、中間値が設定されてもよい。例えば、第一閾値が１００回であり、第二閾値が２０回である場合に、８０回の中間値が、これらの二つの閾値の間に設定される。このような方式は、システムを不安定にする頻繁過ぎる読込み又は逆読込みを防止することになる。

アプリケーションへのサービスの読込み：アプリケーションへのサービスの読込みは、リモートサービスがアプリケーションにローカルに移動されたことを意味している。例えば、図１に示されているように、処理リソースＢ内のサービスＳ３は、アプリケーションＹ１が配置されている処理リソースＡに移動されており、これは、サービスＳ３がアプリケーションＹ１に読込まれたことを通知している。

サービス更新：分散システム内のサービスのロジックが、例えば、サービスの異なるバージョンを生成する場合があり、本実施形態におけるサービス管理用の装置は、サービスが更新されたかどうかを監視してもよく、更には、サービス管理用の装置によるリソースの消費を低減するべく、アプリケーションに読込まれたリモートサービスを監視するのみであってもよい。この理由は、サービス更新を監視する目的が、以下のようなものであるからである。即ち、アプリケーションに読込まれたサービスが更新された場合には、アプリケーション上の現時点のサービスは、使用不能な古いサービスとなり、且つ、古いサービスの逆読込みを迅速に実行し、且つ、新しいサービスを再度読込む必要があるからである。その結果、サービス管理用の装置は、アプリケーションに読込まれたサービスの状態を監視するのみであってもよい。

特定の実装形態においては、アプリケーションに読込まれたターゲットサービスが更新されたかどうかを監視するべく、状態監視モジュールが、サービス管理用の装置に追加されてもよい。図３を参照すれば、このようなケースにおいては、サービス管理用の装置は、人気検出モジュール３１と、移動制御モジュール３２と、状態監視モジュール３３と、を有することができる。

このステップにおいては、サービス管理用の装置の人気検出モジュールは、アプリケーションによるリモートターゲットサービスの使用の人気を検出することになり、且つ、特に、それぞれのアプリケーションによるリモートサービスの使用の人気を監視することになり、且つ、検出された人気に従って、２０２に進むことになる。

２０２．人気が、予め設定された第一閾値に到達した際に、ターゲットサービスをアプリケーションにローカルに読込む。

例えば、このステップにおいては、アプリケーションによるターゲットサービスの使用の人気が、予め設定された第一閾値に到達したことを人気検出モジュールが検出した際に、移動制御モジュールは、ターゲットサービスをアプリケーションにローカルに読込んでいる。任意選択により、処理リソースＡ上のアプリケーションＹ１による処理リソースＢ上のサービスＳ３の使用の人気が第一閾値に到達した場合に、移動制御モジュールは、サービスＳ３を処理リソースＢから処理リソースＡに移動することができるものと考えられる。更には、移動制御モジュールは、処理リソースＡ上において配置されてもよく、或いは、リモートサービスの読込み又は逆読込みを実行するのに専用のモジュールであってもよい。換言すれば、二つのモジュールが処理リソースＡ上において提供されてもよく、そのうちの一方は、ローカルサービスを管理するのに専用のモジュールであり、且つ、他方は、リモートサービスの読込み又は逆読込みを実行するのに専用のモジュールである（例えば、ＪＡＶＡ仮想マシンＪＶＭ上のリモートクラスローダ）。このような構成によれば、リモートサービスの管理が相対的に容易である。リモートサービスの読込み又は逆読込みを実行するニーズが存在している際に、移動制御モジュールが必要とするのは、人気検出モジュールによる通知のみである。

これに加えて、本実施形態におけるサービスの読込み及び逆読込みは、アプリケーションとは非同期状態において実行されてもよい。例えば、アプリケーションが、現時点において、サービスのリモート呼出しのプロセスの最中にあるが、アプリケーションによるサービスの使用の人気が第一閾値に到達したと判定されたとしよう。その結果、移動制御モジュールは、サービスの移動を実行するが、移動は、アプリケーションによる現時点の実行に対して影響を及ぼさない。アプリケーションは、依然として、今回は、リモートサービス呼出しモードに留まり、且つ、アプリケーションによる次の実行においてのみ、ローカルに読込まれたサービスを使用することになる。

更には、上述のように、人気検出モジュールは、ターゲットサービスがアプリケーションにローカルに読込まれた後にも、アプリケーションによるターゲットサービスの使用の人気の検出を継続する。人気が第二閾値に到達したことが検出された場合に、即ち、その後、アプリケーションが、ターゲットサービスの使用の相対的に低い頻度を有することになった場合に、移動制御モジュールは、処理リソースを節約するべく、アプリケーションからのターゲットサービスのローカルな逆読込みを実行してもよい。

更には、ターゲットサービスがアプリケーションにローカルに読込まれた後に、サービス管理用の装置の状態監視モジュールは、ターゲットサービスに対する更新を検出した際に、移動制御モジュールが、アプリケーション上のターゲットサービスのローカルな逆読込みを実行し、且つ、更新済みのターゲットサービスを読込むように、移動制御モジュールに通知してもよい。

リモートサービスがアプリケーションにローカルに読込まれた後に、サービス管理用の装置は、サービス呼出しモジュール３４を更に有することができる。図４に示されているように、アプリケーションを実行するべく使用された際に、サービス呼出しモジュール３４は、アプリケーションが、読込まれたターゲットサービスをローカルに保存しているかどうかを判定し、判定結果が、ターゲットサービスがローカルに保存されているというものであった場合には、アプリケーションを実行してリモート呼出しによる時間の消費を低減するべく、ローカルターゲットサービスを使用することが好ましいが、判定結果が、ターゲットサービスがローカルに保存されていないというものであった場合には、通常のリモート呼出しが使用される。

上述の実施形態から、サービス管理用の装置を分散システムに追加することにより、装置は、上述の実施形態におけるサービス管理用の方法を実装可能であることがわかる。アプリケーションによるリモートターゲットサービスの使用の人気が頻度閾値に到達した際に、リモートサービスは、アプリケーションにローカルに移動される。従来の方式との関係において、このような構成によれば、サービス管理用の装置は、サービスの使用頻度を自動的に判定することが可能であり、且つ、自動的なサービスの移動を実行することが可能であり、この結果、手動的な分析及び配備のための費用が節約され、且つ、サービス配備効率が改善される。このような自動的なサービスの判定及び移動の構成は、相対的に良好な柔軟性を有しており、且つ、アプリケーション実行の実際の状況に迅速に適合することができる。又、リモートサービスをアプリケーションにローカルに移動することにより、リモート呼出しによる時間の消費が回避され、且つ、分散システムの応答効率が改善される。これに加えて、本実施形態における方法は、サービスを分析の粒度として使用しており、その結果、アプリケーションの粒度を有する従来の集中化された配備との関係において、相対的に正確な移動の粒度が実現され、且つ、処理効率が改善される。

上述の説明は、本発明の好適な一実施形態であるに過ぎず、本発明を限定するべく、使用されてはならない。本発明の精神及び原理を逸脱することなしに実施されるすべての変更、均等な置換、又は改善は、本発明によって包含される。

Claims (10)

1. サービス管理用の方法であって、
   アプリケーションによるリモートターゲットサービスの使用の人気を検出するステップと、
   前記人気が、予め設定された第一閾値に到達した際に、前記ターゲットサービスを前記アプリケーションにローカルに読込むステップと、
   を具備する方法。
2. 前記ターゲットサービスを前記アプリケーションにローカルに読込む前記ステップの前に、前記方法は、
   前記ターゲットサービスが移動条件を充足していると判定するステップであって、前記移動条件は、前記アプリケーションが、前記ターゲットサービスによって必要とされているデータソースを具備しており、且つ、前記ターゲットサービスが独立したサービスである、ということを具備する、ステップ、
   を更に具備する、請求項１に記載の方法。
3. 前記ターゲットサービスを前記アプリケーションにローカルに読込む前記ステップの後に、前記方法は、
   前記人気が、予め設定された第二閾値に到達した際に、前記アプリケーションからの前記ターゲットサービスのローカルな逆読込みを実行するステップ、
   を更に具備する、請求項１に記載の方法。
4. 前記ターゲットサービスを前記アプリケーションにローカルに読込む前記ステップの後に、前記方法は、
   前記ターゲットサービスが更新されたと判定された際に、前記アプリケーションからの前記ターゲットサービスのローカルな逆読込みを実行するステップ、
   を更に具備する、請求項１に記載の方法。
5. 前記ターゲットサービスを前記アプリケーションにローカルに読込むステップの後に、前記方法は、
   前記アプリケーションを実行する際に、前記アプリケーションが前記読込まれたターゲットサービスをローカルに保存しているかどうかを判定するステップと、
   前記判定結果が、前記ターゲットサービスがローカルに保存されているというものである場合に、前記アプリケーションを実行するべく、前記ターゲットサービスを使用するステップと、
   を更に具備する、請求項１に記載の方法。
6. サービス管理用の装置であって、
   アプリケーションによるリモートターゲットサービスの使用の人気を検出するように構成された人気検出モジュールと、
   前記人気が、予め設定された第一閾値に到達したことを前記人気検出モジュールが検出した際に、前記ターゲットサービスを前記アプリケーションにローカルに読込むように構成された移動制御モジュールと、
   を具備する装置。
7. 前記人気検出モジュールは、前記ターゲットサービスが移動条件を充足していることを判定するように更に構成されており、前記移動条件は、前記アプリケーションが、前記ターゲットサービスによって必要とされているデータソースを具備しており、且つ、前記ターゲットサービスが独立的なサービスである、ということを具備する、請求項６に記載の装置。
8. 前記移動制御モジュールは、前記人気が、予め設定された第二閾値に到達したことを前記人気検出モジュールが検出した際に、前記アプリケーションからの前記ターゲットサービスのローカルな逆読込みを実行するように更に構成されている、請求項６に記載の装置。
9. 前記装置は、状態監視モジュールを更に具備し、
   前記状態監視モジュールは、前記ターゲットサービスに対する更新を監視するように更に構成されており、且つ、
   前記移動制御モジュールは、前記ターゲットサービスが更新されたと前記状態監視モジュールが判定した際に、前記アプリケーションからの前記ターゲットサービスのローカルな逆読込みを実行するように更に構成されている、
   請求項６に記載の装置。
10. 前記装置は、
    前記アプリケーションを実行する際に、前記アプリケーションが前記読込まれたターゲットサービスをローカルに保存しているかどうかを判定し、前記判定結果が、前記ターゲットサービスがローカルに保存されているというものであった場合に、前記アプリケーションを実行するべく、前記ターゲットサービスを使用するように構成されたサービス呼出しモジュール、
    を更に具備する、請求項６に記載の装置。

Images