JP5847744B2

JP5847744B2 - 処理装置、分散処理方法および分散処理プログラム

Info

Publication number: JP5847744B2
Application number: JP2013035768A
Authority: JP
Inventors: 将司外山; 一深千葉; 千智富田; 駿介車谷
Original assignee: Nippon Telegraph and Telephone Corp; NTT Inc USA
Current assignee: NTT Inc; NTT Inc USA
Priority date: 2013-02-26
Filing date: 2013-02-26
Publication date: 2016-01-27
Anticipated expiration: 2033-02-26
Also published as: JP2014164567A

Description

本発明は、処理装置、分散処理方法および分散処理プログラムに関する。

従来より、実行中のアプリケーションのバックグラウンド処理については実施されており、モバイル端末などの端末上で動作するアプリケーション（以下、「モバイル端末向けアプリ」と記す）においても、様々なバックグラウンド処理が実現可能となっている（例えば、非特許文献１参照）。

例えば、モバイル端末向けアプリを動作させるオペレーティング・システム（以下「モバイルＯＳ」と記載する）の代表であるAndroid（登録商標）においては、Serviceとういうコンポーネントにモバイル端末向けアプリのバックグランド処理が実装されており、アプリのＧＵＩ操作（Activity）が停止した後もバックグラウンドで処理を継続できる仕組みとなる。

江川崇、竹端進、山田暁通、麻野耕一、山岡敏夫、藤井大助、藤田泰介、佐野徹郎 "Google Androidプログラミング入門"、163ページ、アスキー・メディアワークス、ISBN:4048679562、2009年7月1日

しかしながら、モバイル端末にインストールしたアプリケーションの増加と伴に、実行される様々なバックグラウンド処理も増加することになり、これらのバックグラウンド処理の増加が、端末の処理速度の低下などに影響を与えるという問題を生じさせている。この問題は、性能の高くないモバイル端末においてはより顕著である。このため、利用者が意識することなく端末における処理速度を向上させることが課題となる。

そこで、この発明は、上述した従来技術の課題を解決するためになされたものであり、端末における処理速度を向上させることを目的とする。

上述した課題を解決し、目的を達成するために、本発明に係る処理装置は、ユーザインタフェースに係る処理を実行する第１のコンポーネントと内部処理を実行する第２のコンポーネントとが分離して実装されているアプリケーションを実行する処理装置において、前記処理装置によって実行された処理のメソッド、または、該処理装置とネットワークを介して接続され前記第２のコンポーネントに相当するコンポーネントを実装したサーバによって実行された処理のメソッドを記憶するキューと、前記第１のコンポーネントから前記第２のコンポーネントに対する呼出しがあったときに、通信の状況に応じて、前記第２のコンポーネントの処理を前記処理装置において実行するか、前記サーバにおいて実行するかを判断し、前記判断の結果に応じて、前記呼出しの呼出し先を前記処理装置と前記サーバとの間で切り替える切替部と、前記切替部によって呼出し先が前記処理装置に切り替えられた場合には、前記キューに記憶されたメソッドのうち、前記処理装置において未実行のメソッドを実行させるように制御し、前記切替部によって呼出し先がサーバに切り替えられた場合には、前記キューに記憶されたメソッドのうち、前記サーバにおいて未実行のメソッドを実行させるように制御する制御部と、前記処理装置または前記サーバにより前記コンポーネントの処理が実行された後、実行した処理のメソッドを前記キューに格納する格納部と、を有することを特徴とする。

また、本発明に係る分散処理方法は、ユーザインタフェースに係る処理を実行する第１のコンポーネントと内部処理を実行する第２のコンポーネントとが分離して実装されているアプリケーションを実行する処理装置において実行される分散処理方法であって、前記処理装置は、前記処理装置によって実行された処理のメソッド、または、該処理装置とネットワークを介して接続され前記第２のコンポーネントに相当するコンポーネントを実装したサーバによって実行された処理のメソッドを記憶するキューを備え、前記第１のコンポーネントから前記第２のコンポーネントに対する呼出しがあったときに、通信の状況に応じて、前記第２のコンポーネントの処理を前記処理装置において実行するか、前記サーバにおいて実行するかを判断し、前記判断の結果に応じて、前記呼出しの呼出し先を前記処理装置と前記サーバとの間で切り替える切替工程と、前記切替工程によって呼出し先が前記処理装置に切り替えられた場合には、前記キューに記憶されたメソッドのうち、前記処理装置において未実行のメソッドを実行させるように制御し、前記切替工程によって呼出し先がサーバに切り替えられた場合には、前記キューに記憶されたメソッドのうち、前記サーバにおいて未実行のメソッドを実行させるように制御する制御工程と、前記処理装置または前記サーバにより前記コンポーネントの処理が実行された後、実行した処理のメソッドを前記キューに格納する格納工程と、を含んだことを特徴とする。

また、本発明に係る分散処理プログラムは、ユーザインタフェースに係る処理を実行する第１のコンポーネントと内部処理を実行する第２のコンポーネントとが分離して実装されているアプリケーションを実行する処理装置において実行し、前記第２のコンポーネントに相当するコンポーネントを実装したサーバに対してネットワークを介して接続したコンピュータに、前記第１のコンポーネントから前記第２のコンポーネントに対する呼出しがあったときに、通信の状況に応じて、前記第２のコンポーネントの処理を前記処理装置において実行するか、前記サーバにおいて実行するかを判断し、前記判断の結果に応じて、前記呼出しの呼出し先を前記処理装置と前記サーバとの間で切り替える切替ステップと、前記切替ステップによって呼出し先が前記処理装置に切り替えられた場合には、前記処理装置によって実行された処理のメソッド、または、前記サーバによって実行された処理のメソッドを記憶するキューに記憶されたメソッドのうち、前記処理装置において未実行のメソッドを実行させるように制御し、前記切替ステップによって呼出し先がサーバに切り替えられた場合には、前記キューに記憶されたメソッドのうち、前記サーバにおいて未実行のメソッドを実行させるように制御する制御ステップと、前記処理装置または前記サーバにより前記コンポーネントの処理が実行された後、実行した処理のメソッドを前記キューに格納する格納ステップと、を実行させることを特徴とする。

実施形態に係る処理装置、分散処理方法および分散処理プログラムは、端末における処理速度を向上させ、通信環境の状況に応じてアプリケーションの分散処理環境を制御する仕組みを提供することが可能となる。

図１は、第一の実施形態に係るシステムの構成の一例を示す図である。図２は、第一の実施形態に係るモバイル端末およびサーバの構成を説明するための図である。図３は、従来のモバイル端末のアプリケーションの構成例を示す図である。図４は、第一の実施形態に係るモバイル端末のアプリケーションの構成例を示す図である。図５は、第一の実施形態に係るモバイル端末およびサーバの実装例を説明する図である。図６は、従来のアプリケーション実行時の処理手順を示すシーケンス図である。図７は、第一の実施形態に係るモバイル端末のアプリケーション実行処理の処理手順を示すシーケンス図である。図８は、従来のコールバックによる実行処理の処理手順を示すシーケンス図である。図９は、第一の実施形態に係るモバイル端末のコールバックによる実行処理の処理手順を示すシーケンス図である。図１０は、分散処理プログラムを実行するコンピュータを示す図である。

以下に添付図面を参照して、この発明に係る処理装置、分散処理方法および分散処理プログラムの実施形態を詳細に説明する。なお、この実施形態によりこの発明が限定されるものではない。

［第一の実施形態］
以下の実施形態では、第一の実施形態に係るシステムの構成、および影響評価装置による処理の流れを順に説明し、最後に第一の実施形態による効果を説明する。図１は、第一の実施形態に係るシステムの構成の一例を示す図である。第一の実施形態に係るシステムは、ネットワーク１０、複数のモバイル端末２０および複数のサーバ３０を有する。また、各モバイル端末２０および各サーバ３０は、ネットワーク１０を介して接続される。

ここでネットワーク１０とは、例えば、３Ｇ（3rd Generation）や、ＬＴＥ（Long Term Evolution）、ＷｉＦｉ（Wireless Fidelity）などである。また、モバイル端末２０は、例えば、携帯電話、ＰＨＳ（Personal Handyphone System）、ＰＤＡ（Personal Digital Assistant）、タブレットＰＣ（Personal Computer）等、インターネットに接続して、問い合わせサーバや他のユーザ端末との間で情報を送受信できるものであれば、任意の装置であってよい。また、モバイル端末に限定されず、家庭またはオフィスに設置されたコンピュータを使用してもよい。

ネットワーク１０に対し、１または複数のモバイル端末２０と１または複数のサーバ３０が接続している。各モバイル端末２０は、リチウムイオン電池などの二次電池で駆動され有線または無線によってネットワーク１０に接続する物理デバイスである。サーバ３０は、例えば、クラウド基盤上のものとして構成することができる。本実施形態では、モバイル端末２０におけるアプリケーション（ＡＰ）のバックグラウンド処理をサーバ３０上で実行させることにより、分散処理を実現している。

本実施形態においては、モバイル端末２０のアプリケーションとして、ＭＶＣ（モデル・ビュー・コントロール；ＭＶＣ）などのデザインパターンにより、ユーザインタフェース（ビュー及びコントロール）のコンポーネントと内部処理（モデル）のコンポーネントが容易に分割可能なものであるとする。ここでは、モバイル端末２０にある既存実行環境を本発明に基づいて改造し、サーバ３０にも同等な実行環境を導入し、モバイル端末２０のアプリケーションをサーバ３０の環境にもインストールして実行できるようにしている。

また、例えば、モバイル端末２０は、携帯電話、ＰＨＳ（Personal Handyphone System）、ＰＤＡ（Personal Digital Assistant）、タブレットＰＣ（Personal Computer）等、インターネットに接続して、問い合わせサーバや他のユーザ端末との間で情報を送受信できるものであれば、任意の装置であってよい。また、モバイル端末に限定されず、家庭またはオフィスに設置されたコンピュータを使用してもよい。なお、各モバイル端末２０および各サーバ３０における通信は、無線通信に限定されるものではなく、有線通信であってもよい。

図２は、本実施形態におけるモバイル端末２０とサーバ３０の論理的な構成を示している。モバイル端末２０において、モバイルＯＳによって実現される実行環境２１が設けられており、実行環境２１の上位にアプリケーション２２が位置する。この実行環境２１における機能として、切替部２１ａ、制御部２１ｂおよび格納部２１ｃが設けられている。

切替部２１ａは、ユーザインタフェースのコンポーネントから内部処理のコンポーネントに対する呼出しがあったときに、通信の状況に応じて、内部処理のコンポーネントの処理をモバイル端末２０において実行するか、サーバ３０において実行するかを判断し、判断の結果に応じて、呼出しの呼出し先をモバイル端末２０とサーバ３０との間で切り替える。

例えば、切替部２１ａは、例えば、通信速度や電波強度を測定したり、通信可能か通信不可能かを識別する情報を外部から取得したりすることで、通信の状況を推定する。そして、切替部２１ａは、推定した通信の状況に応じて、呼出しの呼出し先をモバイル端末２０とサーバ３０との間で切り替える。例えば、切替部２１ａは、通信可能であれば、呼出しの呼出し先をサーバ３０に切り替え、通信不可能であれば、呼出しの呼出し先をモバイル端末２０に切り替える。また、切替部２１ａは、通信速度が所定の閾値以上であれば、呼出しの呼出し先をサーバ３０に切り替え、通信速度が所定の閾値以下であれば、呼出しの呼出し先をモバイル端末２０に切り替える。

制御部２１ｂは、切替部２１ａによって呼出し先がモバイル端末２０に切り替えられた場合には、キュー２５に記憶されたメソッドのうち、モバイル端末２０において未実行のメソッドを実行させるように制御し、切替部２１ａによって呼出し先がサーバ３０に切り替えられた場合には、キュー２５に記憶されたメソッドのうち、サーバ３０において未実行のメソッドを実行させるように制御する。

格納部２１ｃは、自装置またはサーバ３０によりコンポーネントの処理が実行された後、実行したコンポーネントの処理のメソッドをキュー２５に格納する。また、格納部２１ｃは、実行した処理のメソッドとともに、該メソッドを実行したのがモバイル端末２０であるのかサーバ３０であるのかを示す情報を格納する。

アプリケーション２２は、ＭＶＣのデザインパターンによるものであって、ビュー及びコントロールのコンポーネントとモデルのコンポーネントから構成されている。また、実行環境２１の下位には、ハードウェアコンポーネントとして、ＧＰＳ（全地球測位システム；Global Positioning System）センサや電池残量計、加速度センサなどの各種のセンサ２３と、アプリケーション２２の実行に関連したデータ等を格納するストレージ（記憶装置）２４とが設けられている。

ストレージ２４は、例えば、フラッシュメモリを有するメモリカードなどによって構成される。同様にサーバ３０には、そのＯＳによって実現される実行環境３１が設けられており、実行環境３１の上位に、モバイル端末２０のアプリケーション２２と同等のアプリケーション３２が位置する。実行環境２１の下位には、ハードウェアコンポーネントとしてセンサをシミュレートする仮想センサ３３と、アプリケーション３２の実行に関連したデータ等を格納するストレージ（記憶装置）３４とが設けられている。ストレージ３４は、例えば、ＨＤＤ（ハードディスク装置）によって構成される。

従来のモバイル端末では、その実行環境に、アプリケーションにおけるビュー及びコントロールのコンポーネントからモデルのコンポーネントへの関数呼出し（あるいはメソッド呼出し）及びプロセス間通信の機能が設けられている。本実施形態では、モバイル端末２０の実行環境２１におけるこの機能に、呼出し先（及び通信先）を動的に切り替える仕組みである切替部２１ａを追加する。具体的には、呼出し先（及び通信先）を動的に切り替える切替部２１ａは、モバイル端末２０の通信環境の状況に応じて、モデル関数の呼出先（及び通信先）を動的に切り替える。ここで、端末の無線通信状況としては、例えば、通信可能・不可能の識別等のほか回線の通信速度や電波強度などが挙げられる。

また、モバイル端末２０は、呼び出し先を切り替える際に、呼び出されるモデル関数と引数を順番に保存しておくキュー２５を有する。このキュー２５をアプリケーション特性に応じて利用することでサーバ３０とモバイル端末２０のどちらで実行しても同じ結果が得られるようになる。ここでアプリケーション特性としては、コールバックを利用するかどうか、モデルが内部に状態を持つ（保持する）か、モデル（内部処理）の設定などが考えられる。

また、呼び出し先を切り替える処理は、処理を実行するたびに決定する。そして、サーバ３０側で処理すると決まった場合には、呼出し先をサーバ３０側のモデルに指定し、サーバ３０側で当該モデルを処理させる。この時、キュー２５にたまっている処理があればそれらを先に呼び出してからキュー２５内の処理を実行する。また、モバイル端末２０で処理すると決まった場合には、呼出し先をモバイル端末２０側のモデルに指定し、ローカルで処理させることによって、オフラインでもアプリの実行を可能とする。

次に、モバイル端末２０における実行環境２１を構成するモバイルＯＳがＡｎｄｒｏｉｄ（登録商標）ＯＳである場合を例に挙げて、従来のアプリケーション構成の具体例を説明する。図３においては、この場合のモバイルＯＳ上で動作する従来のアプリケーションの構成を示している。ここではＡｎｄｒｏｉｄＯＳを前提としているから、アプリケーション２２は、ビュー及びコントロールに相当しユーザインタフェースを担当するActivityコンポーネントと、モデルに相当しバックグラウンド処理を担当するServiceコンポーネントから構成される。

Ａｎｄｒｏｉｄアプリでは、Activityがビュー・コントロールに相当し、Serviceがモデルのコンポーネントに相当する。また、Activityは、ユーザインタフェース処理を分担し、Serviceはバックグラウンド処理を分担する。また、Activityは、カーネル２６にあるBinder Driverにより、呼び出し先のServiceの機能を定義するインタフェースとバインドする。

また、実行環境としてのカーネル２６には、メソッド呼出し（例えばActivityコンポーネントからServiceコンポーネントの呼出し）及びプロセス間通信を実行するBinder Driverが設けられている。なお、図３及びそれ以降の図面において、モバイル端末２０のカーネル２６の中にセンサ２３及びストレージ２４が設けられ、カーネル３６の中に仮想センサ３３及びストレージ３４が設けられているように記載されているが、これらは、カーネルの中に物理デバイスとしてのセンサ、仮想センサ及びストレージが設けられていることを意味するのではなく、カーネルを介してセンサ、仮想センサ及びストレージにアクセスできることを意味している。

次に、図４を用いて、本実施形態に係るモバイル端末２０およびサーバ３０のアプリケーション構成の具体例を説明する。図４に示すように、本実施形態に係るモバイル端末２０でのカーネル２６におけるBinder Driverを本発明の分散実行方法に適合するように改造し、サーバ３０においてモバイル端末２０と同等な、改造したBinder Driverを備えたＯＳの環境を導入する。また、モバイル端末２０にあるアプリケーション２２と同じアプリケーション３２をサーバ３０の環境にもインストールする。

本来、同じアプリケーションのActivityコンポーネントとServiceコンポーネントとは同一の端末に存在することが前提されているが、上述のように改造したBinder Driverにより、インターネットなどのネットワークを経由してモバイル端末２０のActivityをサーバ３０のServiceにバインドさせることを可能とする。モバイル端末２０のBinder Driverは、メソッド呼出しの呼出し先を切り替える切替部２１ａとして機能する。さらに、モバイル端末２０とサーバ３０との間でストレージ２４、３４を同期させ、センサ情報も同期させることにより、サーバ３０においてモバイル端末２０のコンテキストを把握、利用することを可能とする。これらによって、サーバ３０側のServiceコンポーネントは、モバイル端末２０のServiceコンポーネントと同等な実行結果を得ることができる。

図５においては、モバイル端末２０とサーバ３０との間でストレージ２４、３４の同期を実現するための既存技術によるソフトウェアの実装例を示している。モバイル端末２０もサーバ３０も、ソフトウェア階層として、カーネル２６、３６の上にライブラリがあり、ライブラリの上にアプリケーション２２、３２が位置している。なお、モバイル端末２０においてライブラリには、汎用のライブラリｌｉｂｃとキャッシュ動作を実現する独自のライブラリＥＣＳが含まれている。

カーネル２６には、ファイル関係の機能として、ＶＦＳ（仮想ファイルシステム；Virtual File System）とＬｉｎｕｘ（登録商標）の１モジュールであるＦｕｓｅ(Filesystem in Userspace)が実装されている。アプリケーション２２は、ファイルアクセスに際しては、ファイルＡＰＩによりＶＦＳにアクセスする。このアクセスは、ＶＦＳからＦｕｓｅを介してライブラリに送られ、その結果、ライブラリを介して、モバイル端末２０のストレージ２４とサーバ３０のストレージ３４との間で、ストレージの同期が達成される。ここで示す例では、ローカルキャッシュとＮＦＳ（ネットワークファイルシステム；Network File System）とを組み合わせたファイルシステムを構築することで、ＳＱＬｉｔｅなどのアプリケーション特有ファイルについてのストレージ同期を実現している。ここに示したもの以外にも、ローカルのストレージとリモートのストレージとを同期させる手法として数多くのものが知られているから、それらの手法を用いてストレージ２４、３４を同期させるようにしてもよい。

図６に示す処理では、改造を行っていない従来のBinder Driverを用いた場合の処理を示している。Activityは、従来のAndroidと同じくContextというオブジェクトにサービスの利用を要求し（ステップＳ１０１）、サービスを呼び出すためのハンドラーを取得する（ステップＳ１０２）。

Activityは、Binder Driver経由でServiceのメソッドを呼び出す（ステップ１０３）。Binder Driverは、呼出命令をServiceにリレーし（ステップ１０４）、Serviceの実行結果を取得して（ステップ１０５）、それをActivityに返す（ステップ１０６）。

次に、第一の実施形態に係るモバイル端末２０のアプリケーション実行処理について説明する。図７は、第一の実施形態に係るモバイル端末２０のアプリケーション実行処理の処理手順を示すシーケンス図である。図７においては、改造されたBinder Driverを用いた場合の処理を示している。

図７に示すように、Activityは、従来のAndroidと同じくContextというオブジェクトにサービスの利用を要求し（ステップＳ２０１）、サービスを呼び出すためのハンドラーを取得する（ステップＳ２０２）。そして、Activityは、Binder Driver経由でServiceのメソッドを呼び出す（ステップ２０３）。このとき、Binder Driverは、通信状況を評価し、サーバ３０側で処理するべきかどうか判断する（ステップＳ２０４）。

ステップＳ２０４において、Binder Driverは、サーバ３０で処理するべきと判断した場合、モバイル端末２０で実行されていない呼び出しがあるかをキュー２５に確認し（ステップＳ２０５）、メソッド（以下、事前実行メソッドという）の応答を受信する（ステップＳ２０６）。そして、呼び出しがある場合は、まずその事前実行メソッドの呼び出しを行い（ステップＳ２０７）、呼出命令をサーバ３０にあるServiceにリレーする（ステップＳ２０８）。そして、サーバ３０のServiceは、Binder Driverを介してモバイル端末２０のBinder Driverに実行結果を返す（ステップＳ２０９、２１０）。ここで、モバイル端末２０では、サーバ３０のServiceの実行結果を破棄する。

その後、サーバ３０は、事前実行メソッドの呼び出しがキュー２５になかった場合と同様に、モバイル端末２０で処理すべきと判断された呼び出しを、従来のBinder Driverの機能と同じく、呼出命令を端末にあるServiceにリレーし（ステップＳ２１１）、サーバ３０にあるServiceは、Binder Driverを介してモバイル端末２０のServiceの実行結果を返す（ステップＳ２１２、２１３）。

また、ステップＳ２０４において、モバイル端末２０で処理するべきと判断した場合、モバイル端末２０で実行されていない呼び出しがあるかをキュー２５に確認し（ステップＳ２１４）、事前実行メソッドの応答を受信する（ステップＳ２１５）。この結果、呼び出しがある場合は、まずその事前呼び出しを実行し（ステップＳ２１６）、実行結果をBinder Driverに返す（ステップＳ２１７）。ここで、モバイル端末２０では、実行結果を破棄する。つまり、モバイル端末２０での実行の場合及びサーバ３０での実行の場合とも、キュー２５に蓄積された事前呼び出しの実行結果については、すでに結果を受け取っているものであるため、取得された実行結果はそれぞれ破棄してもよい。

その後、事前実行メソッドの呼び出しがキュー２５になかった場合と同様に、モバイル端末２０で処理すべきと判断された呼び出しを、従来のBinder Driverの機能と同じく、呼出命令をモバイル端末２０にあるServiceにリレーし（ステップＳ２１８）、Serviceの実行結果をBinder Driverに返す（ステップＳ２１９、Ｓ２２０）。

その後、Binder Driverは、今回実行された呼び出しについて、所定の条件に基づいて、キュー２５に保存するか否かを判定する（ステップＳ２２１）。例えば、Binder Driverは、キュー２５に入れる条件として、メソッドが、アプリケーションの設定を置くもの、アプリケーションが内部で状態を持つもの、コールバック関数を登録するもののいずれかに該当するか判定する。

この結果、キュー２５に保存すると判定した場合には、メソッドをキュー２５に入れて（ステップＳ２２２）、実行結果をActivityに返す。つまり、上記の条件にマッチするメソッドのみをキュー２５に格納することで、呼び出し場所がモバイル端末２０またはサーバ３０に切り替えられた場合であっても実行結果が変わってしまうことを防止しつつ、アプリケーションの効率性を向上させることができる。例えば、アプリケーションが内部で状態を持つものについては、呼び出し場所が変更になると、処理結果が変わってしまうため、過程をキュー２５に入れておくことで呼び出し場所が変更されても同じ実行結果を得ることができるようにする。なお、処理を簡潔化するために、上記の判定処理を省略し、全てのメソッドをキュー２５に入れてもよい。

また、ステップＳ２２２の処理において、キュー２５には、今回実行されたメソッドとともに、該メソッドをモバイル端末２０またはサーバ３０のいずれが実行したかを示す処理対象情報を格納する。つまり、上記の事前実行メソッドの呼び出し（ステップＳ２０７、２１６）時において、キュー２５に記憶されたメソッドが、モバイル端末２０またはサーバ３０側で未実行であるかを、この処理対象情報から判断できるようにしている。一方、ステップＳ２２２において、キュー２５に保存しないと判定した場合には、メソッドをキュー２５に入れずに、実行結果をActivityに返す（ステップＳ２２３）。

また、上記の説明では、ActivityがBinder Driver経由でServiceのメソッドを呼び出した際に、Binder Driverが、通信状況を評価してサーバ３０側で処理するべきと判断した場合に、サーバ３０がキュー２５に格納されたメソッドを実行する場合について説明した。しかし、これに限定されるものではなく、キュー２５に格納されたメソッドについて、特にサーバ３０で実行されるものについては、ネットワーク状態が変更された際に実行しておくことが考えられる。例えば、主なケースとしては、サーバ３０は、ネットワーク断の際において、キュー２５に入れられたものを、ネットワーク１０がつながった際に実行するようにしてもよい。

また、次に、図８および図９を用いて、コールバックを利用した実行について説明する。コールバックを利用した実行とは、主に時間がかかる処理や非同期に結果が返されることを想定する呼び出しに対し、呼び出し元が生成したオブジェクトを事前に保存し、呼び出しの際には同オブジェクトを介して非同期結果を返却する実行方法の１つである。

まず、図８を用いて、従来のコールバックオブジェクトを利用した呼出の例について説明する。図８に示すように、Activityは、従来のAndroidと同じくContextというオブジェクトにサービスの利用を要求し（ステップＳ３０１）、Serviceを呼び出すためのハンドラーを取得する（ステップＳ３０２）。

そして、Activityは、コールバックオブジェクトの登録をServiceに要求する（ステップＳ３０３）。そして、Serviceは、コールバックオブジェクトをメモリに格納する（ステップＳ３０４）。Activityは、コールバック利用メソッドの呼出しを行う（ステップＳ３０５）。そして、Serviceは、受付応答をActivityに返す（ステップＳ３０６）。

その後、Serviceは、実際に処理を行った後、処理結果をコールバック利用メソッドに通知し（ステップＳ３０７）、コールバックメソッドを介してActivityに実行結果を返す（ステップＳ３０８）。

次に、図９を用いて、本実施形態におけるコールバックオブジェクトを利用した呼出の例について説明する。なお、図９では、コールバックオブジェクトの登録時は通信断（オフライン）、呼び出しの際は通信ありで、オフロードする場合の事例であることを前提に説明する。図９に示すように、まずActivityは、従来のAndroidと同じくContextというオブジェクトにサービスの利用を要求し（ステップＳ４０１）、Serviceを呼び出すためのハンドラーを取得する（ステップＳ４０２）。

そして、Activityは、コールバックオブジェクトの登録をBinder Driverに要求する（ステップＳ４０３）。そして、Binder Driverは、Serviceに要求するとともに（ステップＳ４０４）、キュー２５にコールバックオブジェクトを登録する（ステップＳ４０５）。そして、Serviceは、コールバックオブジェクトをメモリに格納する（ステップＳ４０６）。つまり、コールバックオブジェクトの登録時は、通信断のためコールバックオブジェクトをサーバ３０側に登録できないことから、モバイル端末２０でコールバックオブジェクトの登録を実行する。このとき、メソッドの種類がコールバックオブジェクトを含むことから、上記したようにキュー２５にも保存する。

次にServiceのメソッドに対する呼び出しがかかると（ステップＳ４０７）、サーバ３０側で処理をすべきか判断し（ステップＳ４０８）、この時は通信があるためサーバ３０での実行と決まる。その際に、Binder Driverは、まずキュー２５の事前実行メソッドを確認し（ステップＳ４０９）、コールバック登録の応答を受け付けて、先ほどモバイル端末２０のキュー２５に登録したコールバックオブジェクトの登録メソッドを抽出する（ステップＳ４１０）。そして、モバイル端末２０のBinder Driverは、まずコールバックオブジェクトの登録をサーバ３０側のBinder Driverに行い（ステップＳ４１１）、呼出命令をサーバ３０にあるServiceにリレーする（ステップＳ４１２）。

そして、サーバ３０のServiceは、Binder Driverを介してモバイル端末２０のBinder Driverに登録結果を返すとともに（ステップＳ４１３、Ｓ４１４）、メモリにコールバックオブジェクトを登録する（ステップＳ４１５）。続いて、モバイル端末２０のServiceは、コールバック利用メソッドの呼び出しを行い、サーバ３０側のBinder Driverを介してServiceにリレーする（ステップＳ４１６）。

そして、サーバ３０のServiceは、Binder Driverを介して受付応答をモバイル端末２０のBinder Driverに返す（ステップＳ４１７、４１８）。その後、サーバ３０側のServiceは、実際に処理を行った後、処理結果をコールバック利用メソッドに通知し（ステップＳ４１９）、コールバックメソッドを介してActivityに実行結果を返す（ステップＳ４２０〜４２３）。

[第一の実施形態の効果]
上述してきたように、第一の実施形態にかかるモバイル端末２０は、ユーザインタフェースのコンポーネントから内部処理のコンポーネントに対する呼出しがあったときに、通信の状況に応じて、内部処理のコンポーネントの処理をモバイル端末２０において実行するか、サーバ３０において実行するかを判断し、判断の結果に応じて、呼出しの呼出し先をモバイル端末２０とサーバ３０との間で切り替える。そして、モバイル端末２０は、呼出し先がモバイル端末２０に切り替えられた場合には、キュー２５に記憶されたメソッドのうち、モバイル端末２０において未実行のメソッドを実行させるように制御し、切替部２１ａによって呼出し先がサーバ３０に切り替えられた場合には、キュー２５に記憶されたメソッドのうち、サーバ３０において未実行のメソッドを実行させるように制御する。そして、モバイル端末２０またはサーバ３０によりコンポーネントの処理が実行された後、実行したコンポーネントの処理のメソッドをキュー２５に格納する。これにより、通信環境の状況に応じてアプリケーションの分散処理環境を制御する仕組みを提供することが可能となる。

また、モバイル端末内部で動作しているサービスを通信環境の状況に応じて動的にクラウド等のサーバ３０側で実行させるような切替の制御を行うことができる。これにより、サーバの豊富なリソース（回線・メモリ等）を用いることで高速化を実現することが可能となる。また、キュー２５を利用することで、呼び出し場所が変わることによる実行結果が変わってしまうことを防止することできる。さらに、実行環境の切替による処理の中断、処理結果の中間状態のリセット等が発生せず、切替えて利用する複数の実行環境のシームレス化を実現することが可能である。

特に、Androidサービスなどモバイル環境下においてモバイル端末２０で無線通信を行うような場合は、モバイル端末２０の性能や無線通信環境の制約の影響を受けやすいため、端末通信状態に応じてクラウド側で動作させることによって上記のとおり、モバイル端末以上の処理性能を実行環境の切替を意識せずに得ることができる。

［システム構成］
また、本実施形態において説明した各処理の内、自動的に行われるものとして説明した処理の全部又は一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部又は一部を公知の方法で自動的に行うこともできる。この他、上述文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。

また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部又は一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的又は物理的に分散・統合して構成することができる。

［プログラム］
図１０は、開示の技術に係る分散処理プログラムによる情報処理がコンピュータを用いて具体的に実現されることを示す図である。図１０に例示するように、コンピュータ１０００は、例えば、メモリ１０１０と、ＣＰＵ（Central Processing Unit）１０２０と、ハードディスクドライブインタフェース１０３０と、ディスクドライブインタフェース１０４０と、シリアルポートインタフェース１０５０と、ビデオアダプタ１０６０と、ネットワークインタフェース１０７０とを有する。コンピュータ１０００の各部はバス１０８０によって接続される。

メモリ１０１０は、図１０に例示するように、ＲＯＭ１０１１及びＲＡＭ１０１２を含む。ＲＯＭ１０１１は、例えば、ＢＩＯＳ（Basic Input Output System）等のブートプログラムを記憶する。ハードディスクドライブインタフェース１０３０は、図１０に例示するように、ハードディスクドライブ１０３１に接続される。ディスクドライブインタフェース１０４０は、図１０に例示するように、ディスクドライブ１０４１に接続される。例えば磁気ディスクや光ディスク等の着脱可能な記憶媒体が、ディスクドライブ１０４１に挿入される。シリアルポートインタフェース１０５０は、図１０に例示するように、例えばマウス１０５１、キーボード１０５２に接続される。ビデオアダプタ１０６０は、図１０に例示するように、例えばディスプレイ１０６１に接続される。

ここで、図１０に例示するように、ハードディスクドライブ１０３１は、例えば、ＯＳ１０９１、アプリケーションプログラム１０９２、プログラムモジュール１０９３、プログラムデータ１０９４を記憶する。すなわち、開示の技術に係る分散処理プログラムは、コンピュータによって実行される指令が記述されたプログラムモジュール１０９３として、例えばハードディスクドライブ１０３１に記憶される。

また、分散処理プログラムによる情報処理に用いられるデータは、プログラムデータ１０９４として、例えばハードディスクドライブ１０３１に記憶される。そして、ＣＰＵ１０２０が、ハードディスクドライブ１０３１に記憶されたプログラムモジュール１０９３やプログラムデータ１０９４を必要に応じてＲＡＭ１０１２に読み出し、各種の手順を実行する。

なお、分散処理プログラムに係るプログラムモジュール１０９３やプログラムデータ１０９４は、ハードディスクドライブ１０３１に記憶される場合に限られない。例えば、プログラムモジュール１０９３やプログラムデータ１０９４は、着脱可能な記憶媒体に記憶されても良い。この場合、ＣＰＵ１０２０は、ディスクドライブなどの着脱可能な記憶媒体を介してデータを読み出す。また、同様に、分散処理プログラムに係るプログラムモジュール１０９３やプログラムデータ１０９４は、ネットワーク（ＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）等）を介して接続された他のコンピュータに記憶されても良い。この場合、ＣＰＵ１０２０は、ネットワークインタフェースを介して他のコンピュータにアクセスすることで各種データを読み出す。

［その他］
なお、本実施形態で説明した分散処理プログラムは、インターネットなどのネットワークを介して配布することができる。また、制御プログラムは、ハードディスク、フレキシブルディスク（ＦＤ）、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤなどのコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行することもできる。

１０ネットワーク
２０モバイル端末
２１、３１実行環境
２１ａ切替部
２１ｂ制御部
２１ｃ格納部
２２、３２アプリケーション
２３センサ
２４、３４ストレージ
３０サーバ
３３仮想センサ

Claims

ユーザインタフェースに係る処理を実行する第１のコンポーネントと内部処理を実行する第２のコンポーネントとが分離して実装されているアプリケーションを実行する処理装置において、
前記処理装置によって実行された処理のメソッド、または、該処理装置とネットワークを介して接続され前記第２のコンポーネントに相当するコンポーネントを実装したサーバによって実行された処理のメソッドを記憶するキューと、
前記第１のコンポーネントから前記第２のコンポーネントに対する呼出しがあったときに、通信の状況に応じて、前記第２のコンポーネントの処理を前記処理装置において実行するか、前記サーバにおいて実行するかを判断し、前記判断の結果に応じて、前記呼出しの呼出し先を前記処理装置と前記サーバとの間で切り替える切替部と、
前記切替部によって呼出し先が前記処理装置に切り替えられた場合には、前記キューに記憶されたメソッドのうち、前記処理装置において未実行のメソッドを実行させるように制御し、前記切替部によって呼出し先がサーバに切り替えられた場合には、前記キューに記憶されたメソッドのうち、前記サーバにおいて未実行のメソッドを実行させるように制御する制御部と、
前記処理装置または前記サーバにより前記コンポーネントの処理が実行された後、実行した処理のメソッドを前記キューに格納する格納部と、
を有することを特徴とする処理装置。
アプリケーションの実行に係るデータを記憶するストレージと、
前記処理装置のストレージと前記サーバのストレージとの間でデータを同期させる同期部と、
をさらに備えることを特徴とする請求項１に記載の処理装置。
前記切替部は、通信速度に関する情報、電波強度に関する情報、通信可能か通信不可能かを識別する識別情報のいずれか一つまたは複数を取得し、取得した情報を用いて、通信の状況を推定し、該通信の状況に応じて、前記第２のコンポーネントの処理を前記処理装置において実行するか、前記サーバにおいて実行するかを判断することを特徴とする請求項１または２に記載の処理装置。
前記格納部は、前記実行した処理のメソッドが、アプリケーションの設定を置くもの、アプリケーションが内部で状態を持つもの、コールバック関数を登録するもののいずれかに該当するか判定し、該当すると判定した場合には、前記メソッドを前記キューに格納することを特徴とする請求項１〜３のいずれか一つに記載の処理装置。
前記格納部は、実行した処理のメソッドとともに、該メソッドを実行したのが前記処理装置であるのか前記サーバであるのかを示す情報を格納することを特徴とする請求項１〜４のいずれか一つに記載の処理装置。
ユーザインタフェースに係る処理を実行する第１のコンポーネントと内部処理を実行する第２のコンポーネントとが分離して実装されているアプリケーションを実行する処理装置において実行される分散処理方法であって、
前記処理装置は、前記処理装置によって実行された処理のメソッド、または、該処理装置とネットワークを介して接続され前記第２のコンポーネントに相当するコンポーネントを実装したサーバによって実行された処理のメソッドを記憶するキューを備え、
前記第１のコンポーネントから前記第２のコンポーネントに対する呼出しがあったときに、通信の状況に応じて、前記第２のコンポーネントの処理を前記処理装置において実行するか、前記サーバにおいて実行するかを判断し、前記判断の結果に応じて、前記呼出しの呼出し先を前記処理装置と前記サーバとの間で切り替える切替工程と、
前記切替工程によって呼出し先が前記処理装置に切り替えられた場合には、前記キューに記憶されたメソッドのうち、前記処理装置において未実行のメソッドを実行させるように制御し、前記切替工程によって呼出し先がサーバに切り替えられた場合には、前記キューに記憶されたメソッドのうち、前記サーバにおいて未実行のメソッドを実行させるように制御する制御工程と、
前記処理装置または前記サーバにより前記コンポーネントの処理が実行された後、実行した処理のメソッドを前記キューに格納する格納工程と、
を含んだことを特徴とする分散処理方法。
ユーザインタフェースに係る処理を実行する第１のコンポーネントと内部処理を実行する第２のコンポーネントとが分離して実装されているアプリケーションを実行する処理装置において実行し、前記第２のコンポーネントに相当するコンポーネントを実装したサーバに対してネットワークを介して接続したコンピュータに、
前記第１のコンポーネントから前記第２のコンポーネントに対する呼出しがあったときに、通信の状況に応じて、前記第２のコンポーネントの処理を前記処理装置において実行するか、前記サーバにおいて実行するかを判断し、前記判断の結果に応じて、前記呼出しの呼出し先を前記処理装置と前記サーバとの間で切り替える切替ステップと、
前記切替ステップによって呼出し先が前記処理装置に切り替えられた場合には、前記処理装置によって実行された処理のメソッド、または、前記サーバによって実行された処理のメソッドを記憶するキューに記憶されたメソッドのうち、前記処理装置において未実行のメソッドを実行させるように制御し、前記切替ステップによって呼出し先がサーバに切り替えられた場合には、前記キューに記憶されたメソッドのうち、前記サーバにおいて未実行のメソッドを実行させるように制御する制御ステップと、
前記処理装置または前記サーバにより前記コンポーネントの処理が実行された後、実行した処理のメソッドを前記キューに格納する格納ステップと、
を実行させることを特徴とする分散処理プログラム。