JP2014215672A - 仮想Ｗｅｂサーバプログラム及び機能代行方法 - Google Patents

Abstract

【課題】ＯＳ及びＷｅｂブラウザに依存しない、高度な機能を有するＷｅｂアプリケーションの実行を実現すること。【解決手段】仮想Ｗｅｂサーバプログラム１００により実現される仮想Ｗｅｂサーバ１は、ＯＳ機能を実行する機能モジュールをＷｅｂＡＰＩの識別情報と対応付けて予め格納する格納部１０と、Ｗｅｂアプリケーション２からＷｅｂＡＰＩを介してＯＳ機能の実行要求を取得する取得部１１と、取得部１１によって取得された実行要求に含まれるＷｅｂＡＰＩの識別情報を抽出し、抽出したＷｅｂＡＰＩの識別情報と対応付いて格納部１０によって格納された機能モジュールを実行する実行部１２と、実行部１２による実行結果を、取得部１１によって取得された実行要求の取得元であるＷｅｂアプリケーション２に出力する出力部１３と、を備える。【選択図】図３

Description

本発明は、仮想Ｗｅｂサーバプログラム及び機能代行方法に関する。

現在、スマートフォン等のマルチＯＳ（Operating System）環境でのアプリケーション開発のスピード向上やコスト削減のために、ＨＴＭＬ５によるＷｅｂアプリケーションの実現が行われている。ここで、ＨＴＭＬ５とは、ウェブ上のドキュメントを記述するためのマークアップ言語であるＨＴＭＬ（HyperText Markup Language）の第５版である。また、Ｗｅｂアプリケーションとは、ＨＴＭＬ５やＪａｖａＳｃｒｉｐｔ（登録商標）等のＷｅｂ標準技術で実現された、表現力豊か（リッチ）なアプリケーション（Ｗｅｂコンテンツ）である。

例えば、下記特許文献１では、ＨＴＭＬ５に対応したブラウザとＨＴＭＬファイルの組み合わせにて、原画像を色変換して高速表示する機能が開示されている。

特開２０１３−５９１１０号公報

図１に、ＯＳであるＡｎｄｒｏｉｄ（登録商標）上で実現された、２パターンのＷｅｂアプリケーションの全体アーキテクチャの一例を示す。なお、図１に示す各パターンのアーキテクチャは、スマートフォン、タブレット、ＰＣ（Personal Computer）等のコンピュータ装置上にて実現される。また、図１に示す各パターンのアーキテクチャは階層構造で表現されており、上位の階層ほど、抽象的で論理的にインターネットユーザやアプリケーションに近い機能を提供し、下位の階層ほど、より具体的で論理的に物理媒体に近い機能を提供する。

まず、図１（ａ）及び（ｂ）において共通的な下位４階層について最下位層から上位階層に向かって順に説明する。最下位層はデバイス層であり、例えばスマートフォンの構成要素であるディスプレイやスピーカ等の物理的なデバイスに対応する。続くＬｉｎｕｘ（登録商標）カーネル層、ライブラリ層及びアプリケーションフレームワーク層は、それぞれＡｎｄｒｏｉｄ（登録商標）が提供する機能の層である。Ｌｉｎｕｘ（登録商標）カーネル層は、例えば、セキュリティ、メモリやプロセスの管理、ネットワークスタック及びドライバモデル等の基本機能を提供する。また、ライブラリ層は、例えば、Ｃ言語またはＣ＋＋言語のライブラリを含む。なお、ライブラリ層は、アプリケーションの実行環境であるＤａｌｖｉｋ（登録商標）を含む。また、アプリケーションフレームワーク層は、例えば、アプリケーションのライフサイクルを管理するフレームワーク等、Ａｎｄｒｏｉｄ（登録商標）アプリケーション開発者にとって有用な、再利用可能なフレームワークを提供する。

図１（ａ）は、アプリ一体型Ｗｅｂアプリケーションのアーキテクチャ図である。図１（ａ）において、アプリケーションフレームワーク層の上で、Ａｎｄｒｏｉｄ（登録商標）アプリケーション開発者等が作成した、ＷｅｂＶｉｅｗを利用したアプリケーションが実行されている。ここでＷｅｂＶｉｅｗとは、Ｗｅｂコンテンツをアプリケーション上で読み込み、アプリケーション上のコンテンツとして利用する仕組みであり、下位層のアプリケーションフレームワーク層に依存する。そして、ＷｅｂＶｉｅｗを利用したアプリケーション上で、ＨＴＭＬ５やＪａｖａＳｃｒｉｐｔ（登録商標）で実現されたＷｅｂアプリケーションが実行されている。なお、ＷｅｂＶｉｅｗを利用したアプリケーションとその上で実行されているＷｅｂアプリケーションとをまとめて、Ａｎｄｒｏｉｄ（登録商標）アプリと呼ぶ。

アプリ一体型Ｗｅｂアプリケーションでは、ＷｅｂアプリケーションのＪａｖａＳｃｒｉｐｔ（登録商標）から、ＷｅｂＶｉｅｗを介して、アプリケーションフレームワーク層等が提供するＡＰＩ（Application Programming Interface）を呼び出すことができるため、当該ＡＰＩが提供する範囲内の豊富な機能を利用することができる。しかしながら、当該ＡＰＩはＯＳ依存のため、アプリ一体型Ｗｅｂアプリケーションでは、マルチＯＳ環境でのアプリケーション開発を行うことはできない。

図１（ｂ）は、ブラウザ型Ｗｅｂアプリケーションのアーキテクチャ図である。図１（ｂ）において、アプリケーションフレームワーク層の上ではブラウザアプリケーションであるＷｅｂブラウザが起動しており、Ｗｅｂブラウザ上で、ＨＴＭＬ５やＪａｖａＳｃｒｉｐｔ（登録商標）で実現されたＷｅｂアプリケーションが実行されている。なお、当該Ｗｅｂアプリケーションは、Ｗｅｂブラウザ上にて実行されているため、Ｗｅｂサイトとして捉えることもできる。

ブラウザ型Ｗｅｂアプリケーションは、Ｗｅｂブラウザのみで動作する、すなわち、Ｗｅｂの標準的な技術のみで動作するため、開発スピード及び開発コストを削減することができる。また、ブラウザ型Ｗｅｂアプリケーションは、Ｗｅｂサイトとして動作させることができるため、ポータルサイトからの一貫したサービス提供を行うこともできる。しかしながら、ブラウザ型Ｗｅｂアプリケーションは、Ｗｅｂブラウザのみで動作するため、ＷｅｂブラウザにおけるＨＴＭＬ５ ＡＰＩの実装状況の違いや、Ｗｅｂブラウザのセキュリティの設定の違いにより、利用できる機能にばらつきがある。そのため、ブラウザ型Ｗｅｂアプリケーションは、Ｗｅｂブラウザ依存となる可能性もある。また、ブラウザ型Ｗｅｂアプリケーションでは、利用できるＨＴＭＬ５ ＡＰＩは限られ、デバイス制御やファイルアクセス等の高度な機能を実現すること、すなわちネイティブアプリケーション相当の機能を実現することは難しい。

そこで、本発明は、かかる課題に鑑みて為されたものであり、ＯＳ及びＷｅｂブラウザに依存しない、高度な機能を有するＷｅｂアプリケーションの実行を実現することができる仮想Ｗｅｂサーバプログラム及び機能代行方法を提供することを目的とする。

上記課題を解決するため、本発明の仮想Ｗｅｂサーバプログラムは、ＯＳ上で動作しているＷｅｂブラウザが実行するＷｅｂアプリケーションに対し、Ｗｅｂアクセスが可能なインタフェースであるＷｅｂＡＰＩを介して、ＯＳが提供する機能であるＯＳ機能の実行を代行する仮想Ｗｅｂサーバを実現する仮想Ｗｅｂサーバプログラムであって、コンピュータを、ＯＳ機能を実行する機能モジュールをＷｅｂＡＰＩの識別情報と対応付けて予め格納する格納手段と、ＷｅｂアプリケーションからＷｅｂＡＰＩを介してＯＳ機能の実行要求を取得する取得手段と、取得手段によって取得された実行要求に含まれるＷｅｂＡＰＩの識別情報を抽出し、抽出したＷｅｂＡＰＩの識別情報と対応付いて格納手段によって格納された機能モジュールを実行する実行手段と、実行手段による実行結果を、取得手段によって取得された実行要求の取得元であるＷｅｂアプリケーションに出力する出力手段、として機能させる。

このような仮想Ｗｅｂサーバプログラムにより実現された仮想Ｗｅｂサーバによれば、Ｗｅｂアプリケーションは、ＯＳ機能を実行し、実行結果を得ることができる。すなわち、Ｗｅｂアプリケーションは、Ｗｅｂブラウザ上にて実行可能な機能以外のＯＳ機能を実行することができる。例えば、仮想Ｗｅｂサーバがデバイス制御やファイルアクセスを実現する機能モジュールを格納している場合、Ｗｅｂアプリケーションは、デバイス制御やファイルアクセスを実現することができ、ネイティブアプリケーション相当の機能を実現することできる。また、Ｗｅｂアプリケーションは、ＷｅｂＡＰＩを介してＯＳ機能を実行するため、標準的なＷｅｂブラウザが備えるＷｅｂアクセス機能でＯＳ機能を実行することができる、すなわち、ＯＳ及びＷｅｂブラウザに依存せずにＯＳ機能を実行することができる。以上の通り、このような仮想Ｗｅｂサーバによれば、ＯＳ及びＷｅｂブラウザに依存しない、高度な機能を有するＷｅｂアプリケーションの実行を実現することができる。

また、本発明の仮想Ｗｅｂサーバプログラムにおいて、コンピュータを、ＷｅｂＡＰＩを介して起動要求又は停止要求を取得し、取得した要求に基づいて仮想Ｗｅｂサーバの起動又は停止を行う制御手段、としてさらに機能させることが好ましい。かかる構成を採れば、標準的なＷｅｂブラウザが備えるＷｅｂアクセス機能を用いて、仮想Ｗｅｂサーバプログラムにより実現される仮想Ｗｅｂサーバの起動及び停止が行えるため、Ｗｅｂブラウザにおける一般的なプラグインと同様の動作を実現することができ、それゆえにユーザの利便性が向上すると共に、仮想Ｗｅｂサーバの配布コストも低減することができる。

ところで、本発明は、上記のように装置の発明として記述できる他に、以下のように方法の発明としても記述することができる。これはカテゴリが異なるだけで、実質的に同一の発明であり、同様の作用及び効果を奏する。

即ち、本発明に係る機能代行方法は、ＯＳ上で動作しているＷｅｂブラウザが実行するＷｅｂアプリケーションに対し、Ｗｅｂアクセスが可能なインタフェースであるＷｅｂＡＰＩを介して、ＯＳが提供する機能であるＯＳ機能の実行を代行する仮想Ｗｅｂサーバであって、ＯＳ機能を実行する機能モジュールをＷｅｂＡＰＩの識別情報と対応付けて予め格納する格納手段を備える仮想Ｗｅｂサーバによる機能代行方法であって、ＷｅｂアプリケーションからＷｅｂＡＰＩを介してＯＳ機能の実行要求を取得する取得ステップと、取得ステップにおいて取得された実行要求に含まれるＷｅｂＡＰＩの識別情報を抽出し、抽出したＷｅｂＡＰＩの識別情報と対応付いて格納手段によって格納された機能モジュールを実行する実行ステップと、実行ステップにおける実行結果を、取得ステップにおいて取得された実行要求の取得元であるＷｅｂアプリケーションに出力する出力ステップと、を含む。

本発明によれば、ＯＳ及びＷｅｂブラウザに依存しない、高度な機能を有するＷｅｂアプリケーションの実行を実現することができる。

Ａｎｄｒｏｉｄ（登録商標）上で実現された、２パターンのＷｅｂアプリケーションの全体アーキテクチャの一例を示す図である。 Ａｎｄｒｏｉｄ（登録商標）上で実現された本発明の第１実施形態に係る仮想Ｗｅｂサーバプログラムにより実現された仮想Ｗｅｂサーバの全体アーキテクチャを示す図である。 本発明の第１実施形態に係る仮想Ｗｅｂサーバプログラムにより実現された仮想Ｗｅｂサーバの機能ブロック図である。 本発明の実施形態に係る仮想Ｗｅｂサーバプログラムのモジュール構成図である。 本発明の実施形態に係る仮想Ｗｅｂサーバプログラムにより実現された仮想Ｗｅｂサーバで実行される処理（機能代行方法）を示すフローチャートである。 Ａｎｄｒｏｉｄ（登録商標）上で実現された本発明の第２実施形態に係る仮想Ｗｅｂサーバプログラムにより実現された仮想Ｗｅｂサーバの全体アーキテクチャを示す図である。 本発明の実施形態に係る仮想Ｗｅｂサーバプログラムにより実現された仮想Ｗｅｂサーバに関するプラグイン処理を示すフローチャートである。

以下、図面とともに本発明による仮想Ｗｅｂサーバプログラム及び機能代行方法の好適な実施形態について詳細に説明する。なお、図面の説明においては同一要素には同一符号を付し、重複する説明を省略する。

［第１実施形態］
まず、本発明の第１実施形態に係る仮想Ｗｅｂサーバプログラム１００を実行することによりコンピュータ上で実現される仮想Ｗｅｂサーバ１について説明する。図２は、Ａｎｄｒｏｉｄ（登録商標）上で実現された仮想Ｗｅｂサーバプログラム１００により実現された仮想Ｗｅｂサーバ１の全体アーキテクチャを示す図であり、図１（ｂ）で示したブラウザ型Ｗｅｂアプリケーションに対して仮想Ｗｅｂサーバ１を適用した状況を示す。以降、図２を用いて仮想Ｗｅｂサーバ１の動作の概要について説明する。なお、図２に示すアーキテクチャの構成要素のうち、図１を用いて説明した構成要素の説明は省略する。

仮想Ｗｅｂサーバ１は、Ｗｅｂアプリケーションに対し、Ｗｅｂアクセスが可能なインタフェースであるＷｅｂＡＰＩを介して、Ａｎｄｒｏｉｄ（登録商標）のアプリケーションフレームワーク層が提供する機能であるＯＳ機能の実行を代行する擬似的（仮想的）なＷｅｂサーバである。仮想Ｗｅｂサーバ１は、ＯＳから独立した、Ａｎｄｒｏｉｄ（登録商標）アプリケーションとして動作する。

図２に示す（ブラウザ型）Ｗｅｂアプリケーションは、ＨＴＭＬ５ ＡＰＩ等の標準で定義されている機能を実行する一方、仮想Ｗｅｂサーバ１が提供するＷｅｂＡＰＩを実行することができる。ＷｅｂアプリケーションがＷｅｂＡＰＩを実行する際、Ｗｅｂブラウザが、ライブラリ層やＬｉｎｕｘ（登録商標）カーネル層に含まれるＩＰネットワーク層を介して仮想Ｗｅｂサーバ１にＷｅｂアクセスを行い、ＷｅｂＡＰＩを実行する。このように、Ｗｅｂアプリケーションによる仮想Ｗｅｂサーバ１が提供するＷｅｂＡＰＩの実行は、一般的なＷｅｂブラウザが備えるＷｅｂアクセス機能を利用して行われる。なお、図２ではＷｅｂアプリケーションは１つのみが実行されているが、同時に複数のＷｅｂアプリケーションが実行されていてもよい。

仮想Ｗｅｂサーバ１は、Ｗｅｂアプリケーション（Ｗｅｂブラウザ）からＷｅｂＡＰＩが実行されると、対応する、アプリケーションフレームワーク層が提供するＯＳ機能を実行し、実行結果を、ＷｅｂＡＰＩの実行の戻り値としてＷｅｂアプリケーションに返却する。

続いて、仮想Ｗｅｂサーバプログラム１００により実現された仮想Ｗｅｂサーバ１の機能の詳細について説明する。図３は、仮想Ｗｅｂサーバ１の機能ブロック図である。図３に示す通り、仮想Ｗｅｂサーバ１は、格納部１０（格納手段）、取得部１１（取得手段）、実行部１２（実行手段）、出力部１３（出力手段）及び制御部１４（制御手段）を含んで構成される。

図３に示す仮想Ｗｅｂサーバ１の各機能ブロックの機能は、仮想Ｗｅｂサーバ１が動作するデバイスが備えるＣＰＵ、ＲＡＭ等のハードウェア上に仮想Ｗｅｂサーバプログラム１００（後述）を読み込ませることにより、ＣＰＵの制御のもとで入出力装置、通信モジュール、及び補助記憶装置を動作させるとともに、ＲＡＭにおけるデータの読み出し及び書き込みを行うことで実現される。

以下、図３に示す仮想Ｗｅｂサーバ１の各機能ブロックについて説明する。

格納部１０は、ＯＳ機能を実行する機能モジュールをＷｅｂＡＰＩの識別情報と対応付けて予め格納する。例えば、格納部１０は、ＯＳ機能であるファイルアクセスを実行するファイルアクセス機能モジュールを、ＷｅｂＡＰＩの識別情報であるＡＰＩ名“fileAccess”と対応付けて格納する。なお、機能モジュールは、単機能であってもよいし、機能群をまとめたものであってもよい。

取得部１１は、Ｗｅｂアプリケーション２からＷｅｂＡＰＩを介してＯＳ機能の実行要求を取得する。具体的には、Ｗｅｂアプリケーション２が実行要求をＷｅｂブラウザ３に送信し、当該送信された実行要求をＷｅｂブラウザ３がＩＰネットワーク層を介して仮想Ｗｅｂサーバ１のＷｅｂＡＰＩ宛に送信し、当該送信された実行要求を取得部１１が取得する。実行要求の具体例としては、ＵＲＬ文字列“http://localhost:8765/api/fileAccess?para1=fileName&para2=true”が挙げられる。ここで、“http://localhost:8765”は仮想Ｗｅｂサーバ１のネットワーク上でのアドレス（ローカルホストのポート番号８７６５番）を示し、“fileAccess”はＷｅｂＡＰＩの識別情報（関数名）を示し、“fileName”及び“true”はそれぞれ“fileAccess”が示すＷｅｂＡＰＩを呼び出す際の引数を示す。

実行部１２は、取得部１１によって取得された実行要求に含まれるＷｅｂＡＰＩの識別情報を抽出し、抽出したＷｅｂＡＰＩの識別情報と対応付いて格納部１０によって格納された機能モジュールを実行する。例えば、上記の例で言えば、実行部１２は、ＷｅｂＡＰＩの識別情報である“fileAccess”を抽出し、“fileAccess”と対応付いて格納部１０によって格納されたファイルアクセス機能モジュールを取得し、当該モジュールを実行する。

出力部１３は、実行部１２による実行結果を、取得部１１によって取得された実行要求の取得元であるＷｅｂアプリケーション２に出力する。例えば、上記の例で言えば、出力部１３は、ファイルアクセス機能モジュールの実行結果である、ファイル名が“fileName”のファイルのデータを、Ｗｅｂアプリケーション２に出力する。

制御部１４は、ＷｅｂＡＰＩを介して起動要求又は停止要求を取得し、取得した要求に基づいて仮想Ｗｅｂサーバ１の起動又は停止を行う。例えば、制御部１４は、Ｗｅｂアプリケーション２から起動要求であるＵＲＬ文字列“http://localhost:8765/api/command=start”を取得すると、仮想Ｗｅｂサーバ１の起動を行う。また例えば、制御部１４は、Ｗｅｂアプリケーション２から停止要求であるＵＲＬ文字列“http://localhost:8765/api/command=stop”を取得すると、仮想Ｗｅｂサーバ１の停止を行う。なお、仮想Ｗｅｂサーバ１は、制御部１４を備えなくてもよい。

引き続いて、上述した一連の仮想Ｗｅｂサーバ１による処理をコンピュータに実行させるための仮想Ｗｅｂサーバプログラム１００を説明する。図４に示すように、仮想Ｗｅｂサーバプログラム１００は、コンピュータに挿入されてアクセスされる、あるいはコンピュータが備える記録媒体５０に形成されたプログラム格納領域５１内に格納される。より具体的には、仮想Ｗｅｂサーバプログラム１００は、仮想Ｗｅｂサーバ１を実現するデバイスが備える記録媒体５０に形成されたプログラム格納領域５１内に格納される。

仮想Ｗｅｂサーバプログラム１００は、格納モジュール１０１と、取得モジュール１０２と、実行モジュール１０３と、出力モジュール１０４と、制御モジュール１０５とを備えて構成される。格納モジュール１０１と、取得モジュール１０２と、実行モジュール１０３と、出力モジュール１０４と、制御モジュール１０５とを実行させることにより実現される機能は、上述した仮想Ｗｅｂサーバ１の格納部１０と、取得部１１と、実行部１２と、出力部１３と、制御部１４との機能とそれぞれ同様である。

なお、仮想Ｗｅｂサーバプログラム１００は、その一部若しくは全部が、通信回線等の伝送媒体を介して伝送され、他の機器により受信されて記録（インストールを含む）される構成としてもよい。また、仮想Ｗｅｂサーバプログラム１００の各モジュールは、１つのコンピュータでなく、複数のコンピュータのいずれかにインストールされてもよい。その場合、当該複数のコンピュータによるコンピュータシステムよって上述した一連の仮想Ｗｅｂサーバプログラム１００の処理が行われる。

続いて、図５に示すシーケンス図を用いて、本実施形態に係る仮想Ｗｅｂサーバプログラム１００により実現される仮想Ｗｅｂサーバ１における機能代行方法の処理について説明する。

まず、Ｗｅｂアプリケーション２において、ＯＳ機能の実行要求が仮想Ｗｅｂサーバ１に送信される（ステップＳ１）。次に、仮想Ｗｅｂサーバ１において、取得部１１により、ステップＳ１にて送信されたＯＳ機能の実行要求が取得される（ステップＳ２、取得ステップ）。次に、実行部１２により、ステップＳ２にて取得されたＯＳ機能の実行要求に含まれるＷｅｂＡＰＩの識別情報が抽出され、抽出されたＷｅｂＡＰＩの識別情報と対応付いて格納部１０によって格納された機能モジュールが実行される（ステップＳ３、実行ステップ）。次に、出力部１３により、ステップＳ３における実行結果が、Ｗｅｂアプリケーション２に出力される（ステップＳ４、出力ステップ）。次に、Ｗｅｂアプリケーション２において、ステップＳ４にて出力された実行結果が受信される（ステップＳ５）。

次に、本実施形態のように構成された仮想Ｗｅｂサーバプログラム１００により実現される仮想Ｗｅｂサーバ１の作用効果について説明する。

本実施形態の仮想Ｗｅｂサーバ１によれば、Ｗｅｂアプリケーション２は、ＯＳ機能を実行し、実行結果を得ることができる。すなわち、Ｗｅｂアプリケーション２は、Ｗｅｂブラウザ３上にて実行可能な機能以外のＯＳ機能を実行することができる。例えば、仮想Ｗｅｂサーバ１がデバイス制御やファイルアクセスを実現する機能モジュールを格納している場合、Ｗｅｂアプリケーション２は、デバイス制御やファイルアクセスを実現することができ、ネイティブアプリケーション相当の機能を実現することできる。また、Ｗｅｂアプリケーション２は、ＷｅｂＡＰＩを介してＯＳ機能を実行するため、標準的なＷｅｂブラウザ３が備えるＷｅｂアクセス機能でＯＳ機能を実行することができる、すなわち、ＯＳ及びＷｅｂブラウザ３に依存せずにＯＳ機能を実行することができる。以上の通り、このような仮想Ｗｅｂサーバ１によれば、ＯＳ及びＷｅｂブラウザ３に依存しない、高度な機能を有するＷｅｂアプリケーションの実行を実現することができる。

また、本実施形態の仮想Ｗｅｂサーバ１は、制御部１４を備えることで、標準的なＷｅｂブラウザ３が備えるＷｅｂアクセス機能を用いて、仮想Ｗｅｂサーバ１の起動及び停止が行えるため、Ｗｅｂブラウザ３における一般的なプラグインと同様の動作を実現することができ、それゆえにユーザの利便性が向上すると共に、仮想Ｗｅｂサーバ１の配布コストも低減することができる。

以上の通り、本実施形態の仮想Ｗｅｂサーバプログラム１００により実現される仮想Ｗｅｂサーバ１は、スマートフォン等のコンピュータ内に仮想的なＷｅｂ環境を構築し、Ｗｅｂブラウザ３から利用できない機能をローカルで動作するＷｅｂＡＰＩ化することで、ＯＳやデバイスに依存しない、Ｗｅｂブラウザ３上でのリッチコンテンツを実現する。また、デバイスの差異をＷｅｂＡＰＩとして吸収した上でＷｅｂアプリケーション２から用いることで、個別の作りこみや互換性の問題の解消が実現できる。

また、本実施形態の仮想Ｗｅｂサーバ１によれば、Ｗｅｂブラウザ３からデバイス制御やファイルアクセスができる。また、Ｗｅｂアプリケーション２について、ＯＳ依存が少ない開発ができる。また、Ｗｅｂアプリケーション２について、ローカル機能とクラウド機能を同じ画面で融合させることができる。

また、本実施形態の仮想Ｗｅｂサーバ１は、ＯＳから独立しているため、ＯＳとして作り込む必要がなく、あらゆる既存ＯＳと共存することができる。また、図２の通り、既存のアーキテクチャを修正することなく、容易に追加及び共存することができる。また、仮想Ｗｅｂサーバ１は、Ａｎｄｒｏｉｄ（登録商標）アプリケーションとして動作するため、ユーザは仮想Ｗｅｂサーバ１を通常のアプリケーションと同様に容易にインストール及び利用することができる。

［第２実施形態］
次に、本発明の第２実施形態に係る仮想Ｗｅｂサーバプログラム１００ａを実行することによりコンピュータ上で実現される仮想Ｗｅｂサーバ１ａについて説明する。図６は、Ａｎｄｒｏｉｄ（登録商標）上で実行された仮想Ｗｅｂサーバプログラム１００ａにより実現された仮想Ｗｅｂサーバ１ａの全体アーキテクチャを示す図であり、図１（ｂ）で示したブラウザ型Ｗｅｂアプリケーションに対して仮想Ｗｅｂサーバ１ａを適用した状況を示す。以降、図６を用いて仮想Ｗｅｂサーバ１ａの動作の概要について説明する。なお、図６に示すアーキテクチャの構成要素のうち、図２を用いて説明した構成要素の説明は省略し、Ｗｅｂサーバプログラム１００ａ及び仮想Ｗｅｂサーバ１ａについてはそれぞれ仮想Ｗｅｂサーバプログラム１００及び仮想Ｗｅｂサーバ１との差分についてのみ説明する。なお、仮想Ｗｅｂサーバプログラム１００ａの機能モジュールは、図４に示した仮想Ｗｅｂサーバプログラム１００の機能モジュールと同様であり、仮想Ｗｅｂサーバ１ａの機能ブロックは、図３に示した仮想Ｗｅｂサーバ１の機能ブロックと同様である。

図６において、仮想Ｗｅｂサーバ１ａは、Ｌｉｎｕｘ（登録商標）カーネル層の上で実行されるシステムサービスとして実現される。このように、仮想Ｗｅｂサーバ１又は仮想Ｗｅｂサーバ１ａは、ＩＰネットワーク層を経由してアクセスされるため、アーキテクチャ上、どの層に実現されてもよい。

第１実施形態に係る仮想Ｗｅｂサーバ１は、アプリケーションフレームワーク層の上でＡｎｄｒｏｉｄ（登録商標）アプリケーションとして実現されているため、ＯＳ機能は、アプリケーションフレームワーク層が提供するＯＳ機能に制限される。一方、本第２実施形態に係る仮想Ｗｅｂサーバ１ａは、Ｌｉｎｕｘ（登録商標）カーネル層の上でシステムサービスとして実現されているため、ＯＳ機能として、Ｌｉｎｕｘ（登録商標）カーネル層が提供する豊富はＯＳ機能を利用することができる。

なお、本第２実施形態及び第１実施形態では、ＯＳとしてＡｎｄｒｏｉｄ（登録商標）を用いて説明しているが、これに限らず、仮想Ｗｅｂサーバプログラム１００により実現される仮想Ｗｅｂサーバ１は、他のＯＳに対しても適用することができる。

＜プラグイン動作＞
次に、第１実施形態に係る仮想Ｗｅｂサーバ１のプラグイン動作について説明する。仮想Ｗｅｂサーバ１は、前述の制御部１４を備えることでプラグイン動作を実現することができる。図７に示すシーケンス図を用いて、プラグイン動作の処理について説明する。なお、本プラグイン動作は、第２実施形態に係る仮想Ｗｅｂサーバ１ａについても同様に実現可能である。

まず、Ｗｅｂブラウザ３により、ネットワーク通信が可能か否かが判定される（ステップＳ１０）。ステップＳ１０にて、ネットワーク通信が可能であると判定された場合、ユーザは、接続サイトやソーシャルボタンを利用して仮想Ｗｅｂサーバ１に接続を試みる（ステップＳ１１）。ステップＳ１０にて、ネットワーク通信が可能でないと判定された場合、ユーザは、ブックマークレットを利用して仮想Ｗｅｂサーバ１に接続を試みる（ステップＳ１２）。

ステップＳ１１及びステップＳ１２に続き、Ｗｅｂブラウザ３により、仮想Ｗｅｂサーバ１に接続可能か否かが判定される（ステップＳ１３）。ステップＳ１３にて、仮想Ｗｅｂサーバ１に接続可能であると判定された場合、Ｗｅｂアプリケーション２から仮想Ｗｅｂサーバ１を利用する（ステップＳ１４）。ステップＳ１３にて、仮想Ｗｅｂサーバ１に接続可能でないと判定された場合、ユーザは、ＵＲＬスキームを利用して仮想Ｗｅｂサーバ１の起動を試みる（ステップＳ１５）。例えば、“localwebapi”という独自に定義したＵＲＬスキームを利用して、ローカルホストのポート番号８７６５番で待ち受けている仮想Ｗｅｂサーバ１の起動を試みる場合、Ｗｅｂブラウザ３を用いて“localwebapi://localhost:8765”のアドレスに接続する。

Ｓ１５に続き、Ｗｅｂブラウザ３により、仮想Ｗｅｂサーバ１に接続可能か否かが判定される（ステップＳ１６）。ステップＳ１６にて、仮想Ｗｅｂサーバ１に接続可能であると判定された場合、前述のステップＳ１４に移る。ステップＳ１６にて、仮想Ｗｅｂサーバ１に接続可能でないと判定された場合、Ｗｅｂブラウザ３により、ブラウザプラグインのような使い勝手で、ユーザは仮想Ｗｅｂサーバ１のダウンロード先に誘導され、ユーザは誘導に従い仮想Ｗｅｂサーバ１をインストールし（ステップＳ１７）、ステップＳ１３に戻る。

以上の通り、第１実施形態に係る仮想Ｗｅｂサーバ１は、制御部１４を備えることで、Ｗｅｂの標準的な仕組みのみで、ＯＳやＷｅｂブラウザ３に依存せずに、例えばＦｌａｓｈ（登録商標）のようなプラグイン動作を実現することができる。また、このように、Ｗｅｂブラウザ３から仮想Ｗｅｂサーバ１をプラグイン的に使うことで、高度なＷｅｂアプリケーション２（Ｗｅｂコンテンツ）を実現することができる。

＜スマートデバイスの統合管理＞
次に、第１実施形態に係る仮想Ｗｅｂサーバ１を利用したスマートデバイスの統合管理について説明する。ここで、スマートデバイスとは、様々なアプリケーションが実現できる単機能デバイスやセンサー機器のことである。機器によって搭載されている機能が異なり、それぞれ独自のライブラリやフレームワークが用意されている。スマートフォン等から様々なスマートデバイスを利用する場合、同様の機能をもったデバイスでもメーカーによって仕様が異なり、それぞれのデバイスのライブラリやフレームワークを利用して個別にアプリケーションを作りこむ必要がある。スマートデバイスの連携も独自の仕様や、新たに規格化されて古いデバイスでは利用できない仕組みにより実現される場合が多い。

スマートデバイスの統合管理に仮想Ｗｅｂサーバ１を利用すれば、例えば、デバイスごとに異なる仕様を仮想Ｗｅｂサーバ１が提供するＷｅｂＡＰＩとして整理することで、デバイスの差異を吸収し、従来では実現できなかったＷｅｂブラウザ３からのスマートデバイス利用を実現することができる。すなわち、仮想Ｗｅｂサーバ１を利用することで、仕様の異なるスマートデバイス群を統合的に取り扱える。

１…仮想Ｗｅｂサーバ、２…Ｗｅｂアプリケーション、３…Ｗｅｂブラウザ、１０…格納部、１１…取得部、１２…実行部、１３…出力部、１４…制御部、５０…記憶媒体、５１…プログラム格納領域、１００…仮想Ｗｅｂサーバプログラム、１０１…格納モジュール、１０２…取得モジュール、１０３…実行モジュール、１０４…出力制御モジュール、１０５…制御モジュール。

Claims (3)

1. ＯＳ（オペレーティングシステム）上で動作しているＷｅｂブラウザが実行するＷｅｂアプリケーションに対し、Ｗｅｂアクセスが可能なインタフェースであるＷｅｂＡＰＩ（Application Programming Interface）を介して、ＯＳが提供する機能であるＯＳ機能の実行を代行する仮想Ｗｅｂサーバを実現する仮想Ｗｅｂサーバプログラムであって、コンピュータを、
   ＯＳ機能を実行する機能モジュールをＷｅｂＡＰＩの識別情報と対応付けて予め格納する格納手段と、
   ＷｅｂアプリケーションからＷｅｂＡＰＩを介してＯＳ機能の実行要求を取得する取得手段と、
   前記取得手段によって取得された実行要求に含まれるＷｅｂＡＰＩの識別情報を抽出し、抽出したＷｅｂＡＰＩの識別情報と対応付いて前記格納手段によって格納された機能モジュールを実行する実行手段と、
   前記実行手段による実行結果を、前記取得手段によって取得された実行要求の取得元であるＷｅｂアプリケーションに出力する出力手段、
   として機能させるための仮想Ｗｅｂサーバプログラム。
2. コンピュータを、
   ＷｅｂＡＰＩを介して起動要求又は停止要求を取得し、取得した要求に基づいて仮想Ｗｅｂサーバの起動又は停止を行う制御手段、
   としてさらに機能させるための請求項１に記載の仮想Ｗｅｂサーバプログラム。
3. ＯＳ（オペレーティングシステム）上で動作しているＷｅｂブラウザが実行するＷｅｂアプリケーションに対し、Ｗｅｂアクセスが可能なインタフェースであるＷｅｂＡＰＩ（Application Programming Interface）を介して、ＯＳが提供する機能であるＯＳ機能の実行を代行する仮想Ｗｅｂサーバであって、ＯＳ機能を実行する機能モジュールをＷｅｂＡＰＩの識別情報と対応付けて予め格納する格納手段を備える仮想Ｗｅｂサーバによる機能代行方法であって、
   ＷｅｂアプリケーションからＷｅｂＡＰＩを介してＯＳ機能の実行要求を取得する取得ステップと、
   前記取得ステップにおいて取得された実行要求に含まれるＷｅｂＡＰＩの識別情報を抽出し、抽出したＷｅｂＡＰＩの識別情報と対応付いて前記格納手段によって格納された機能モジュールを実行する実行ステップと、
   前記実行ステップにおける実行結果を、前記取得ステップにおいて取得された実行要求の取得元であるＷｅｂアプリケーションに出力する出力ステップと、
   を含む機能代行方法。
   

Images