以下、図面を参照しつつ、本発明の実施の形態について説明する。以下の説明では、同一の部品には同一の符号を付してある。それらの名称および機能も同じである。したがって、それらについての詳細な説明は繰り返さない。
また、以下では、常時接続の一例として、WebSocketプロトコルを利用した通信について説明する。しかしながら、アプリケーションサーバから任意のタイミングでクライアントにデータをプッシュできればよく、本発明はWebSocketプロトコルを利用する常時接続に限定されるものではない。
<第1の実施の形態>
<ネットワークシステムの全体構成>
まず、本実施の形態にかかるネットワークシステム1の全体構成について説明する。図1は、本実施の形態にかかるネットワークシステム1の全体構成を示すイメージ図である。
図1を参照して、ネットワークシステム1は、住居またはオフィスなどに配置される複数の家電100A,100Bと、ネットワークを介して家電100A,100Bと接続される常時接続サーバ200と、家電100A,100Bに関する様々なサービスを提供する複数のアプリケーションサーバ300A,300Bとを含む。家電としては、たとえば、掃除機100A、エアコン100B、テレビ、洗濯機、冷蔵庫、炊飯器、空気清浄器、床暖房、IH(Induction Heating)クッキングヒーター、などが挙げられる。さらに、家電は、住居内またはオフィス内の通信機器であればよく、たとえば、パーソナルコンピュータ、テレビ以外のAV機器、インターホンシステムなどを含んでもよい。また、常時接続サーバ200とアプリケーションサーバ300とは、家電と同じ住居内、オフィス内、ビル内、会社あるいは学校の構内に存在するサーバなどを含んでもよい。
また、家電と各サーバ間は、光ファイバ等の回線を経由し、途中に、光回線終端装置、無線LAN通信を行うためのアクセスポイント、ルータ等が接続されてもよい。家電は、ネットワークに接続する手段として、IEEE802.11a/b/g/n/acなどの無線LAN通信、あるいは、有線LANなどが用いられるが、接続方法はこれらに限定されるものではない。
そして、本実施の形態においては、掃除機100Aおよびエアコン100Bが、常時接続サーバ200と常時接続される。これによって、掃除機用のアプリケーションサーバ300Aは、常時接続サーバ200を介して任意のタイミングで掃除機100Aにデータをプッシュ送信することができる。同様に、エアコン用のアプリケーションサーバ300Bは、常時接続サーバ200を介して任意のタイミングでエアコン100Bにデータをプッシュ送信することができる。
すなわち、本実施形態にかかるネットワークシステム1では、多数の家電の各々が、自身に適したサービスを提供するアプリケーションサーバの全てと、直接的に常時接続する必要がない。また、逆に、複数のアプリケーションサーバの各々が、対応する家電の全てと、直接的に常時接続する必要がない。
なお、本実施の形態においては、常時接続サーバ200とアプリケーションサーバ300A,300Bとが別々のコンピュータである。換言すれば、常時接続サーバ200において、家電と常時接続するためのサービスプログラムが稼働する。そして、アプリケーションサーバ300A,300Bにおいて、家電に情報を送信することによって家電を制御するためのサービスプログラムや、家電からの情報を取得することによって当該情報を他の電子機器で利用するためのサービスプログラムなどが稼働する。
しかしながら、他の実施の形態として後述するように、1つのアプリケーションサーバが複数のアプリケーションサービスプログラムを搭載してもよい。また、常時接続サーバとアプリケーションサーバとが同一のコンピュータであってもよい。たとえば、1つのコンピュータ、すなわち装置としてのサーバが、家電と常時接続するための通信サービスプログラムと、家電を制御するためのアプリケーションサービスプログラムとを搭載してもよい。
<ネットワークシステムの動作概要>
次に、本実施の形態にかかるネットワークシステム1の動作概要について説明する。なお、以下では、掃除機100A、エアコン100Bなどの家電を総称して、クライアント100ともいう。また、以下では、掃除機用のアプリケーションサーバ300Aおよびエアコン用のアプリケーションサーバ300Bなどの各種のサービスをクライアント100およびユーザなどに提供するためのアプリケーションサーバを総称して、アプリケーションサーバ300ともいう。
<常時接続開始時の動作概要>
まず、ネットワークシステム1における常時接続開始時の動作概要について説明する。図2は、本実施の形態にかかるネットワークシステム1における常時接続開始時の動作概要を示す第1のイメージ図である。図3は、本実施の形態にかかるネットワークシステム1における常時接続開始時の動作概要を示す第2のイメージ図である。
図2を参照して、クライアント100は、HTTPプロトコルを使用して、アプリケーションサーバ300に認証情報を要求する。すると、アプリケーションサーバ300は、認証情報を生成し、HTTPプロトコルを使用して、クライアント100に認証情報を送信する。アプリケーションサーバ300は、常時接続サーバ200にも認証情報を送信する。
図3を参照して、クライアント100は、HTTPプロトコルを使用して、認証情報に基づいて常時接続サーバ200に常時接続の開始を要求する。常時接続サーバ200は、クライアント100からの認証情報とアプリケーションサーバ300からの認証情報とに基づいて、クライアント100の認証処理を行う。認証に成功すると、常時接続サーバ200は、WebSocketプロトコルを使用して、クライアント100との常時接続を確立する。常時接続サーバ200は、クライアント100とサーバ300間のWebSocket接続を一意に特定するための接続IDを作成し、接続IDをアプリケーションサーバ300に通知する。これによって、アプリケーションサーバ300は、接続IDに基づいて、常時接続サーバ200を介して、クライアント100に情報をプッシュすることが可能になる。
<アプリケーションサーバからの接続確認時の動作概要>
次に、アプリケーションサーバ300からの接続確認時の動作概要について説明する。図4は、本実施の形態にかかるネットワークシステム1におけるアプリケーションサーバ300からの接続確認時の動作概要を示すイメージ図である。
図4を参照して、アプリケーションサーバ300は、常時接続サーバ200にクライアント100との常時接続が有効であるか否か(たとえば、クライアント100や常時接続サーバ200が正常に動作しているか否か)についての接続確認(生死確認)を要求する。常時接続サーバ200は、当該要求に応じて、WebSocketプロトコルを使用して、クライアント100に接続確認データを送信する。
クライアント100は、接続確認データを受信したときに、WebSocketプロトコルを使用して、常時接続サーバ200に結果通知データを送信する。常時接続サーバ200は、結果通知データを受信した場合、クライアント100との常時接続が有効である旨をアプリケーションサーバ300に送信する。一方、常時接続サーバ200は、結果通知データを受信しなかった場合、クライアント100との常時接続が無効である旨をアプリケーションサーバ300に送信する。
このような構成は、以下のように利用される。たとえば、アプリケーションサーバ300は、スマートフォン500からの何らかの命令を受け付けた際あるいはスマートフォン500に命令を受け付ける画面が表示される際に、常時接続サーバ200に接続確認を要求する。そして、アプリケーションサーバ300は、常時接続が有効である場合に限り、家電に対する命令の受付を続行する。一方、常時接続が有効でない場合、スマートフォン500を介してユーザに命令を実行できない旨を通知する。
<クライアントからの接続確認時の動作概要>
次に、クライアント100からの接続確認時の動作概要について説明する。図5は、本実施の形態にかかるネットワークシステム1におけるクライアント100からの接続確認時の動作概要を示すイメージ図である。
図5を参照して、クライアント100は、常時接続サーバ200に常時接続が有効であるか否かを調べるために、WebSocketプロトコルを使用して、常時接続サーバ200に接続確認データを送信する。常時接続サーバ200は、接続確認データを受信できたときに、WebSocketプロトコルを使用して、クライアント100に結果通知データを送信する。このとき、常時接続サーバ200は、クライアント100との常時接続が有効である旨をアプリケーションサーバ300にも送信する。
<アプリケーションサーバからの通常の情報プッシュ時の動作概要>
次に、アプリケーションサーバ300からクライアント100への通常の情報プッシュ時の動作概要について説明する。図6は、本実施の形態にかかるネットワークシステム1におけるアプリケーションサーバ300からの通常の情報プッシュ時の動作概要を示すイメージ図である。
図6を参照して、アプリケーションサーバ300は、クライアント100を特定するための接続IDとクライアント100に送信するためのデータ本体とを、常時接続サーバ200に送信する。常時接続サーバ200は、当該データ本体が所定のデータ量よりも大きいか否かを判断する。常時接続サーバ200は、当該データ本体が所定のデータ量以下である場合、WebSocketプロトコルを使用して、データ本体と今回のデータ送信を特定するためのトランザクションIDとを、接続IDに対応するクライアント100に送信する。
クライアント100は、データ本体を受信すると、WebSocketプロトコルを使用して、当該データ本体を受信したことを示す結果情報と上記のトランザクションIDとを常時接続サーバ200に送信する。常時接続サーバ200は、受信した結果情報とトランザクションIDとに基づいて、データ送信の結果をアプリケーションサーバ300に通知する。
<アプリケーションサーバからの大容量の情報プッシュ時の動作概要>
次に、アプリケーションサーバ300からクライアント100への大容量の情報プッシュ時の動作概要について説明する。図7は、本実施の形態にかかるネットワークシステム1におけるアプリケーションサーバ300からの大容量の情報プッシュ時の動作概要を示すイメージ図である。なお、より詳細には、常時接続による通信を大容量ファイルが占有することを防ぎ、常時接続に関するネットワークリソースの負荷を軽減するために、以下のような機能を有する。
図7を参照して、アプリケーションサーバ300は、クライアント100を特定するための接続IDとクライアント100に送信するためのデータ本体とを、常時接続サーバ200に送信する。常時接続サーバ200は、当該データ本体が所定のデータ量よりも大きいか否かを判断する。常時接続サーバ200は、当該データ本体が所定のデータ量よりも大きい場合、WebSocketプロトコルを使用して、データの取得方法を示すURL情報と今回のデータ送信を特定するためのトランザクションIDとを、接続IDに対応するクライアント100に送信する。
クライアント100は、URL情報とトランザクションIDとを受信すると、HTTPプロトコルを使用して、常時接続サーバ200にトランザクションIDを送信する。常時接続サーバ200は、トランザクションIDに基づいて、クライアント100にデータ本体を送信する。クライアント100は、URL情報に対応する格納場所からデータ本体をダウンロードすると、データ本体を受信したことを示す結果情報と上記のトランザクションIDとを常時接続サーバ200に送信する。常時接続サーバ200は、受信した結果情報とトランザクションIDとに基づいて、データ送信の結果をアプリケーションサーバ300に通知する。
なお、常時接続サーバ200の代わりに、アプリケーションサーバ300が、データの容量に関する上記の判断を行っても良い。この場合は、データの容量が所定値よりも大きい場合に、アプリケーションサーバ300が、常時接続サーバ200を介してクライアント100にURL情報を送信する。クライアント100は、URL情報に基づいて、HTTPプロトコルを利用して、常時接続サーバ200かアプリケーションサーバ300からデータをダウンロードする。
<クライアントからの通常の情報プッシュ時の動作概要>
次に、クライアント100からの通常の情報プッシュ時の動作概要について説明する。図8は、本実施の形態にかかるネットワークシステム1におけるクライアント100からの通常の情報プッシュ時の動作概要を示すイメージ図である。
図8を参照して、クライアント100は、送信すべきデータ本体が所定のデータ量よりも大きいか否かを判断する。当該データ本体が所定のデータ量以下である場合、クライアント100は、送信すべきアプリケーションサーバ300を特定するためのサービスIDと、データ本体と、今回のデータ送信を特定するためのトランザクションIDとを、WebSocketプロトコルを使用して常時接続サーバ200に送信する。
常時接続サーバ200は、サービスIDに対応するアプリケーションサーバ300Bに、当該データ本体とクライアント100に対応する接続IDとを送信する。アプリケーションサーバ300Bは、データ本体を受信すると、接続IDに対応づけて当該データ本体を記憶する。アプリケーションサーバ300Bは、データ本体を受信した旨を示す結果通知を常時接続サーバ200に送信する。常時接続サーバ200は、結果通知に応じて、WebSocketプロトコルを使用して、トランザクションIDと送信結果とをクライアント100に送信する。
<クライアントからの大容量の情報プッシュ時の動作概要>
次に、クライアント100からの大容量の情報プッシュ時の動作概要について説明する。図9は、本実施の形態にかかるネットワークシステム1におけるクライアント100からの大容量の情報プッシュ時の動作概要を示すイメージ図である。
図9を参照して、クライアント100は、送信すべきデータ本体が所定のデータ量よりも大きいか否かを判断する。当該データ本体が所定のデータ量よりも大きい場合、クライアント100は、送信すべきアプリケーションサーバ300を特定するためのサービスIDと、データ量と、今回のデータ送信を特定するためのトランザクションIDとを、WebSocketプロトコルを使用して常時接続サーバ200に送信する。
常時接続サーバ200は、WebSocketプロトコルを使用して、クライアント100に、トランザクションIDとデータのアップロード先とを通知する。クライアント100は、HTTPプロトコルを使用して、トランザクションIDに基づいてデータ本体をアップロード先にアップロードする。
常時接続サーバ200は、アップロードが完了すると、サービスIDに対応するアプリケーションサーバ300Bに、当該データ本体とクライアント100に対応する接続IDとを送信する。アプリケーションサーバ300Bは、データ本体を受信すると、接続IDに対応づけて当該データ本体を記憶する。アプリケーションサーバ300Bは、データ本体を受信した旨を示す結果通知を常時接続サーバ200に送信する。常時接続サーバ200は、結果通知に応じて、WebSocketプロトコルを使用して、トランザクションIDと送信結果とをクライアント100に送信する。
上記の複数の動作概要に示した通り、本実施の形態にかかるネットワークシステム1では、クライアント100に接続IDが付与されるため、当該接続IDに基づいて、アプリケーションサーバ300からのデータを、選択された1つのクライアント100にプッシュすることが可能となる。
また、本実施の形態にかかるネットワークシステム1では、クライアント100とアプリケーションサーバ300とか常時接続サーバ200を介して常時接続されている。このため、ブラウザとしてのクライアントとサービスプログラムとしてのアプリケーションサーバとの組み合わせ毎にWebSocketによる常時接続状態を確立する必要がない。よって、ネットワークシステム1にかかる負荷を従来よりも低減させることができる。
また、本実施の形態にかかるネットワークシステム1では、クライアント100および常時接続サーバ200が、送信されるデータの容量でプロトコルを切り替えるため、WebSocketプロトコルによる通信経路が一部のデータの送受信によって占有される可能性を低減することができる。すなわち、WebSocketプロトコルを利用した他のデータの送受信が行えなくなる可能性を低減することができる。
以下、このような機能を実現するためのネットワークシステム1の各部の具体的な構成について詳述する。
<ネットワークシステム1>
まず、本実施の形態にかかるネットワークシステム1全体の通信構成について説明する。図10は、本実施の形態にかかるネットワークシステム1全体の通信構成を示すブロック図である。
図10を参照して、クライアント100は、HTTPプロトコルを使用して常時接続サーバ200およびアプリケーションサーバ300と通信することができるし、WebSocketプロトコルを使用して常時接続サーバ200と常時接続することもできる。より詳細には、クライアント100は、後述するクライアントAPP110AとクライアントAPI110Bとを搭載する。クライアントAPP110Aは、クライアント100の各部を制御する。クライアントAPI110Bは、後述する通信インターフェイスを介して、HTTPプロトコルを使用して通信したり、HTTPプロトコル上で利用されるWebSocketプロトコルを使用して通信したりする。
なお、本実施形態にかかる構成は、HTTP/WebSocketプロトコルの他に、SSLで通信路を暗号化できるHTTPS/WSSプロトコルでも利用可能である。すなわち、本実施形態にかかるネットワークシステム1は、HTTPS/WSSプロトコルを利用するシステムにも適応できる。
常時接続サーバ200は、WebSocketプロトコルを使用してクライアント100との常時接続通信を制御するためのプログラムとしてのWSサーバ(すなわち、ソフトウェアとしての常時接続サーバ)210Aを含む。常時接続サーバ200は、他のプロトコルを使用して、他のデータベース450にもアクセスすることができる。なお、本実施の形態においては、常時接続サーバ200は、HTTPプロトコルを使用して、アプリケーションサーバ300に任意のタイミングでデータを送信できる。
本実施の形態にかかるネットワークシステム1は、複数のアプリケーションサーバ300A,300Bを含む。複数のアプリケーションサーバ300A,300Bの各々は、クライアント100やスマートフォン500などにサービスを提供するプログラムとしてのサーバAPP(すなわち、ソフトウェアとしてのアプリケーションサーバ)310AとHTTPプロトコルを利用して常時接続サーバ200と通信するためのサーバAPI310Bとを搭載する。
たとえば、ネットワークシステム1は、掃除機100Aを制御するためのアプリケーションサーバ300Aと、エアコン100Bを制御するためのアプリケーションサーバ300Bなどを含む。複数のアプリケーションサーバ300A,300Bの各々は、HTTPプロトコルを使用して、常時接続サーバ200、他のデータベース、スマートフォン500などと通信することができる。そして、本実施の形態においては、アプリケーションサーバ300A,300Bは、HTTPプロトコルを使用して、常時接続サーバ200に任意のタイミングでデータを送信できる。
<クライアント100のハードウェア構成>
次に、クライアント100のハードウェア構成の一態様について説明する。図11は、本実施の形態にかかるクライアント100のハードウェア構成を表わすブロック図である。
図11を参照して、クライアント100は、主たる構成要素として、CPU110と、メモリ120と、入出力部130と、家電制御回路150と、通信インターフェイス160とを含む。
CPU110は、メモリ120あるいは外部の記憶媒体に記憶されているプログラムを実行することによって、クライアント100の各部を制御する。より詳細には、CPU110は、後述するAPPデータに基づいてクライアントAPP110A(図16〜図24を参照。)として動作するとともに、後述するAPIデータに基づいてクライアントAPI110B(図16〜図24を参照。)として動作する。
メモリ120は、各種のRAM(Random Access Memory)、各種のROM(Read-Only Memory)や、フラッシュメモリーなどによって実現される。なお、メモリ120は、インターフェイスを介して利用される、USB(Universal Serial Bus)(登録商標)メモリ、CD(Compact Disc)、DVD(Digital Versatile Disk)、メモリカード、ハードディスク、IC(Integrated Circuit)カード、光カード、マスクROM、EPROM(Erasable Programmable Read Only Memory)、EEPROM(Electronically Erasable Programmable Read-Only Memory)などの記憶媒体などによっても実現される。
メモリ120は、CPU110によって実行されるプログラムや、CPU110によるプログラムの実行により生成されたデータ、入出力部130を介して入力されたデータ、掃除機またはエアコンなどのようなクライアントとして動作するAPP(Application software)データ、クライアントAPPとデータをやり取りしながら常時接続サーバ200と通信するためのAPI(Application Programming Interface)データを記憶する。具体的には、メモリ120は、常時接続サーバの接続先、アプリケーションサーバ接続先、サービス識別コード、サービス認証トークン、接続ID、クライアント識別IDなどを記憶する。
入出力部130は、ユーザからの命令を受け付けて、当該命令をCPU110に入力する。また、入出力部130は、CPU110からの信号に基づいて、文字や画像を出力する。
家電制御回路150は、CPU110からの信号に基づいて、家電としてのクライアントの各部(モータなど)を制御する。
通信インターフェイス160は、IEEE802.11a/b/g/n/acなどの無線LAN通信、ZigBee(登録商標)、BlueTooth(登録商標)、あるいは、イーサネット(登録商標)などの有線LANなどの通信モジュールによって実現される。通信インターフェイス160は、有線通信あるいは無線通信によって他の装置との間でデータをやり取りする。CPU110は、通信インターフェイス160を介して、他の装置からプログラム、制御命令、画像データ、テキストデータなどを受信したり、他の装置にテキストデータ、画像データなどを送信したりする。
<常時接続サーバ200のハードウェア構成>
次に、常時接続サーバ200のハードウェア構成の一態様について説明する。図12は、本実施の形態にかかる常時接続サーバ200のハードウェア構成を表わすブロック図である。なお、常時接続サーバ200は、apache、tomcat、mysqlなど、一般的なサーバモジュールで担保できる機能は標準的に利用可能である。
図12を参照して、常時接続サーバ200は、主たる構成要素として、CPU210と、メモリ220と、入出力部230と、通信インターフェイス260とを含む。常時接続サーバ200のハードウェア構成は、クライアント100のハードウェア構成と比較して、家電の各部を制御するための家電制御回路150を有さない点、CPU210の動作、メモリ220に格納されているデータに関して異なる。以下では、CPU210の動作とメモリ220が記憶するデータとについて説明するものとし、その他のハードウェア構成については説明を繰り返さない。
CPU210は、メモリ220あるいは外部の記憶媒体に記憶されているプログラムを実行することによって、常時接続サーバ200の各部を制御する。具体的には、CPU210は、メモリ220に記憶されているプログラムを実行することによって、WSサーバ210A(図16〜図24を参照。)として動作する。
メモリ220は、CPU210によって実行されるプログラムや、CPU210によるプログラムの実行により生成されたデータ、入出力部230を介して入力されたデータ、サービスID、サービス名、アプリケーションサーバ300の接続先URL、サービス認証トークン生成情報、認証情報(ワンタイムキー)、接続IDなどを記憶する。
<アプリケーションサーバ300のハードウェア構成>
次に、アプリケーションサーバ300のハードウェア構成の一態様について説明する。図13は、本実施の形態にかかるアプリケーションサーバ300のハードウェア構成を表わすブロック図である。なお、アプリケーションサーバ300は、apache、tomcat、mysqlなど、一般的なサーバモジュールで担保できる機能は標準的に利用可能である。
図13を参照して、アプリケーションサーバ300は、主たる構成要素として、CPU310と、メモリ320と、入出力部330と、通信インターフェイス360とを含む。アプリケーションサーバ300のハードウェア構成は、クライアント100のハードウェア構成と比較して、家電の各部を制御するための家電制御回路150を有さない点、CPU310の動作、メモリ320に格納されているデータに関して異なる。よって、以下では、CPU310の動作と、メモリ320が記憶するデータとについて説明するものとし、その他のハードウェア構成については説明を繰り返さない。
CPU310は、メモリ320あるいは外部の記憶媒体に記憶されているプログラムを実行することによって、アプリケーションサーバ300の各部を制御する。具体的には、CPU310は、メモリ320に記憶されているプログラムを実行することによって、後述するAPPデータに基づいてサーバAPP310A(図16〜図24を参照。)として動作するとともに、後述するAPIデータに基づいてサーバAPI310B(図16〜図24を参照。)として動作する。
メモリ320は、CPU310によって実行されるプログラムや、CPU310によるプログラムの実行により生成されたデータ、入出力部330を介して入力されたデータ、アプリケーションサーバ300として動作するAPPデータ、サーバAPPとデータをやり取りしながら常時接続サーバ200と通信するためのAPIデータを記憶する。具体的には、メモリ320は、常時接続サーバのURL、サービスIDとサービス認証トークン、認証情報(ワンタイムキー)生成情報、接続IDなどを記憶する。
<スマートフォン500のハードウェア構成>
次に、スマートフォン500のハードウェア構成の一態様について説明する。図14は、本実施の形態にかかるスマートフォン500のハードウェア構成を表わすブロック図である。
図14を参照して、スマートフォン500は、主たる構成要素として、CPU510と、メモリ520と、ボタン530と、ディスプレイ540と、通信インターフェイス560とを含む。スマートフォン500のハードウェア構成は、クライアント100のハードウェア構成と比較して、家電の各部を制御するための家電制御回路150を有さない点、CPU510の動作、メモリ320に格納されているデータに関して異なる。よって、ここでは、ハードウェア構成の各部については説明を繰り返さない。なお、近年はボタン530とディスプレイ540の代わりにタッチパネルが利用されることが多い。
<常時接続に関する装置間のデータのやり取り>
次に、本実施の形態にかかるネットワークシステム1における常時接続に関する装置間のデータのやり取りの概要について説明する。なお、図15は、本実施の形態にかかるネットワークシステム1における常時接続に関する装置間のデータのやり取りの処理手順を示すシーケンス図である。
図15を参照して、クライアント100は、HTTPプロトコルを使用して、アプリケーションサーバ300に認証情報を要求する(ステップS002)。このとき、クライアント100は、アプリケーションサーバ300に、認証に利用されるクライアントIDを送信する。アプリケーションサーバ300は、当該要求に応じてHTTPプロトコルを使用してクライアント100に認証情報を送信する(ステップS004)。
アプリケーションサーバ300は、常時接続サーバ200にも認証情報を送信する(ステップS006)。常時接続サーバ200は、アプリケーションサーバ300から受信した認証情報を保存する(ステップS008)。
クライアント100と常時接続サーバ200とは、HTTPプロトコルを使用して、WebSocketを利用した常時接続状態を確立する(ステップS010、ステップS012)。具体的には、クライアント100は、HTTPプロトコルを使用して、常時接続サーバ200にハンドシェイク要求を送る。常時接続サーバ200は、ハンドシェイク応答を返す。これによって、クライアント100と常時接続サーバ200との間で、WebSocketプロトコルによる常時接続が有効になる。
クライアント100は、認証情報を常時接続サーバ200に送信する(ステップS014)。常時接続サーバ200は、クライアント100からの認証情報と予め保存している認証情報とに基づいて、クライアント100を認証する(ステップS016)。認証に成功すると、常時接続サーバ200は、アプリケーションサーバ300がクライアント100を識別するための接続IDを発行する(ステップS018)。すなわち、常時接続サーバ200は、常時接続中のクライアント100と接続IDとの対応関係を、接続状態管理情報として記憶する。クライアント100は、接続IDを受信して、記憶する(ステップS020)。アプリケーションサーバ300も、接続IDを受信して、記憶する(ステップS022)。
その後、アプリケーションサーバ300は、必要に応じて、データ本体と送り先のクライアント100を特定するための接続IDとを常時接続サーバ200に送信する(ステップS032)。常時接続サーバ200は、アプリケーションサーバ300からデータ本体と接続IDとを受信する(ステップS034)。常時接続サーバ200は、接続状態管理情報を参照して、接続IDに基づいてクライアント100を特定する(ステップS036)。
常時接続サーバ200は、WebSocketプロトコルを使用して、特定されたクライアント100にデータ本体を送信する(ステップS038)。クライアント100は、データ本体を受信する(ステップS040)。クライアント100は、WebSocketプロトコルを使用して、受信結果を常時接続サーバ200に送信する(ステップS042)。常時接続サーバ200は、受信結果を受信すると、当該受信結果をアプリケーションサーバ300に送信する(ステップS044)。アプリケーションサーバ300は、受信結果を受信する(ステップS046)。
以下では、本実施の形態にかかるネットワークシステム1における各処理手順についてより詳細に説明する。なお、上述したように、図10と図11を参照して、クライアントAPP110Aは、クライアント100のCPU110がプログラムを実行することによって実現されるものであって、クライアント100としての動作を制御する。クライアントAPI110Bは、クライアント100のCPU110がプログラムを実行することによって実現されるものであって、通信インターフェイス160を使用しながらHTTPプロトコルおよびWebSocketプロトコルを使用して常時接続サーバ200と通信する。
また、図10と図13を参照して、サーバAPP310Aは、アプリケーションサーバ300のCPU310がプログラムを実行することによって実現されるものであって、アプリケーションサービスプログラムとして動作する。サーバAPI310Bは、アプリケーションサーバ300のCPU310がプログラムを実行することによって実現されるものであって、通信インターフェイス360を使用しながら常時接続サーバ200と通信する。
また、図10と図12を参照して、WSサーバ210Aは、常時接続サーバ200のCPU210がプログラムを実行することによって実現されるものである。WSサーバ210Aは、通信インターフェイス260を使用しながらHTTPプロトコルを使用してアプリケーションサーバ300と通信する。さらに、本実施形態においては、WSサーバ210Aは、通信インターフェイス260を使用しながらHTTPプロトコルおよびWebSocketプロトコルを使用してクライアント100と通信する。
<常時接続開始時の処理手順の詳細>
次に、本実施の形態にかかるネットワークシステム1における常時接続開始時の処理手順の詳細について説明する。図16は、本実施の形態にかかるネットワークシステム1における常時接続開始時の処理手順の詳細を示すシーケンス図である。
図16を参照して、クライアントAPP110Aは、アプリケーションサーバ300との常時接続を開始するための要求を、クライアントAPI110Bに受け渡す(ステップS102)。このとき、クライアントAPP110Aは、クライアントAPI110BにクライアントIDを受け渡す。
クライアントAPI110Bは、通信インターフェイス160を介してHTTPプロトコルを使用して、アプリケーションサーバ300に、クライアントIDを送るとともに認証情報を要求する(ステップS104)。なお、クライアントAPPまたはクライアントAPI110Bは、サービスの認証に必要な情報も引数として、アプリケーションサーバ300に送信する(ステップS106)。
サーバAPI310Bは、クライアントIDと当該要求とを受信すると、認証情報を生成する(ステップS108)。サーバAPI310Bは、サーバAPP310Aに接続開始を通知する(ステップS110)。サーバAPI310Bは、サーバAPP310Aから接続を許可する返答を受け取ると(ステップS114)、通信インターフェイス360を介して常時接続サーバ200に認証情報を送信する(ステップS116)。WSサーバ210Aは、認証情報をメモリ120に格納する(ステップS118)。サーバAPI310Bは、通信インターフェイス260を介して、認証情報をクライアント100に送信する(ステップS120)。
クライアントAPI110Bは、通信インターフェイス160を介して、HTTPプロトコルを使用して、常時接続サーバ200にハンドシェイク要求を送信する(ステップS122)。WSサーバ210Aは、通信インターフェイス260を介して、ハンドシェイク応答をクライアント100に返す(ステップS124)。これによって、クライアント100と常時接続サーバ200とのWebSocketプロトコルによる常時接続が開始される。
クライアントAPI110Bは、通信インターフェイス160を介して、WebSocketプロトコルを使用して、常時接続サーバ200に認証情報を送信する(ステップS126)。WSサーバ210Aは、先にアプリケーションサーバ300から受信していた認証情報と今回クライアント100から受信した認証情報とに基づいてクライアント100を認証する(ステップS128)。
認証に成功すると、WSサーバ210Aは、接続IDを発行する(ステップS130)。WSサーバ210Aは、通信インターフェイス260を介して、接続確立状況としてクライアント100の接続IDをアプリケーションサーバ300に送信する(ステップS132)。サーバAPI310Bは、接続IDをメモリ320に記憶する(ステップS134)。サーバAPI310Bは、接続確立状況をサーバAPP310Aに通知する(ステップS136)。サーバAPI310Bは、認証情報を削除する(ステップS138)。
WSサーバ210Aは、通信インターフェイス260を介して、WebSocketプロトコルを使用して、認証要求の応答として接続IDをクライアント100に返信する(ステップS144)。クライアントAPI110Bは、接続IDを記憶する。
クライアントAPI110Bは、通信インターフェイス160を介して、WebSocketプロトコルを使用して、接続確認を要求する(ステップS146)。WSサーバ210Aは、当該要求を受信すると、通信インターフェイス260を介して、WebSocketプロトコルを使用して、接続確認に対して応答する(ステップS148)。クライアントAPI110Bは、当該応答に応じて、クライアントAPP100Aに常時接続が開始された旨を通知する(ステップS150)。
<クライアントからの常時接続切断時の処理手順の詳細>
次に、本実施の形態にかかるネットワークシステム1におけるクライアントからの常時接続切断時の処理手順の詳細について説明する。図17は、本実施の形態にかかるネットワークシステム1におけるクライアントからの常時接続切断時の処理手順の詳細をシーケンス図である。
図17を参照して、クライアントAPP110Aは、アプリケーションサーバ300との常時接続を切断するための要求を、クライアントAPI110Bに受け渡す(ステップS202)。このとき、クライアント100は、クライアントAPI110Bに接続IDも受け渡す。
クライアントAPI110Bは、通信インターフェイス160を介してWebSocketプロトコルを使用して、常時接続サーバ200に、常時接続の切断を要求する(ステップS204)。WSサーバ210Aは、通信インターフェイス260を介して、WebSocketプロトコルを使用して、常時接続の切断を了解する(ステップS206)。
クライアントAPI110Bは、常時接続サーバ200との常時接続を終了し、常時接続サーバ200とのTCPの通信も終了する(ステップS208)。クライアントAPI110Bは、常時接続を終了した旨をクライアントAPP100Aに通知する(ステップS210)。
WSサーバ210Aは、クライアント100との常時接続を終了し、クライアント100とのTCPの通信も終了する(ステップS212)。WSサーバ210Aは、通信インターフェイス260を介して、アプリケーションサーバ300に常時接続を切断した旨を通知する(ステップS214)。
サーバAPI310Bは、当該通知を受けてサーバAPP310Aにクライアント100との常時接続が終了した旨を通知する(ステップS218)。具体的には、サーバAPI310Bは、常時接続が終了したクライアント100に対応する接続IDをサーバAPP310Aに受け渡す。
<アプリケーションサーバからの常時接続切断時の処理手順の詳細>
次に、本実施の形態にかかるネットワークシステム1におけるアプリケーションサーバ300からの常時接続切断時の処理手順の詳細について説明する。なお、アプリケーションサーバ300は、プログラムのバージョンアップをする時およびトラブルに対するメンテナンス時などに、クライアント100との常時接続を切断する場合がある。図18は、本実施の形態にかかるネットワークシステム1におけるアプリケーションサーバ300からの常時接続切断時の処理手順の詳細をシーケンス図である。
図18を参照して、サーバAPP310Aは、クライアント100との常時接続を切断するための要求を、サーバAPI310Bに受け渡す(ステップS302)。このとき、サーバAPP310Aは、サーバAPI310Bに対象となるクライアント100の接続IDも受け渡す。
サーバAPI310Bは、通信インターフェイス360を介して、常時接続サーバ200に、クライアント100との常時接続の切断を要求する(ステップS304)。WSサーバ210Aは、通信インターフェイス260を介して、常時接続の切断を了解する。サーバAPI310Bは、クライアント100との常時接続が終了した旨をサーバAPP310Aに通知する(ステップS306)。
WSサーバ210Aは、通信インターフェイス260を介して、WebSocketプロトコルを使用して、クライアント100に常時接続の切断を要求する(ステップS310)。クライアントAPI110Bは、当該要求に応じて、クライアントAPP100Aに常時接続の切断を通知する(ステップS312)。クライアントAPI110Bは、常時接続サーバ200との常時接続を終了し、常時接続サーバ200とのTCPの通信も終了する(ステップS316)。
WSサーバ210Aは、クライアント100との常時接続を終了し、クライアント100とのTCPの通信も終了する(ステップS318)。WSサーバ210Aは、通信インターフェイス260を介して、クライアント100との常時接続の切断が完了した旨を通知する(ステップS320)。
サーバAPI310Bは、当該通知に基づいて、メモリ320に記憶されている接続状態管理情報からクライアント100の接続IDを削除する(ステップS322)。サーバAPI310Bは、切断処理が完了した旨をサーバAPP310Aに通知する(ステップS324)。
<クライアントからの接続確認時の処理手順の詳細>
次に、本実施の形態にかかるネットワークシステム1におけるクライアント100からの接続確認時の処理手順の詳細について説明する。なお、クライアント100は、一定期間常時接続によるデータの受信を行わなかった場合およびユーザから常時接続機能をOFFする指示を受け付けた場合などに、アプリケーションサーバ300との常時接続を切断する場合がある。図19は、本実施の形態にかかるネットワークシステム1におけるクライアント100からの接続確認時の処理手順の詳細をシーケンス図である。
図19を参照して、クライアントAPP100Aは、クライアントAPI110Bに、常時接続サーバ200との接続確認を要求する(ステップS402)。クライアントAPI110Bは、通信インターフェイス160を介して、WebSocketプロトコルを使用して、常時接続サーバ200に接続確認要求(ping)を送信する(ステップS404)。
WSサーバ210Aは、接続確認要求(ping)と受信すると、通信インターフェイス260を介してクライアント100に接続確認応答(pong)送信する(ステップS406)。クライアントAPI110Bは、接続状態の判定結果をクライアントAPP100Aに通知する(ステップS408)。
なお、常時接続サーバ200から接続確認応答(pong)が返信されてこない場合は、クライアントAPI110Bは、自動再接続フラグを確認し、常時接続を要求するための処理を呼び出す(ステップS412)。その後、ネットワークシステム1は、常時接続を開始するときと同じ処理を実行する(図15および図16を参照。)。
<アプリケーションサーバからの接続確認時の処理手順の詳細>
次に、本実施の形態にかかるネットワークシステム1におけるアプリケーションサーバ300からの接続確認時の処理手順の詳細について説明する。図20は、本実施の形態にかかるネットワークシステム1におけるアプリケーションサーバ300からの接続確認時の処理手順の詳細をシーケンス図である。
図20を参照して、サーバAPP310Aは、サーバAPI310Bに、常時接続サーバ200とクライアント100との接続確認を要求する(ステップS502)。サーバAPI310Bは、通信インターフェイス360を介して、常時接続サーバ200にクライアント100との接続確認を要求する(ステップS504)。
WSサーバ210Aは、通信インターフェイス260を介して、WebSocketプロトコルを使用して、クライアント100に接続確認要求(ping)を送信する(ステップS506)。クライアントAPI110Bは、接続確認要求(ping)と受信すると、通信インターフェイス260を介して、WebSocketプロトコルを使用して常時接続サーバ200に接続確認応答(pong)送信する(ステップS508)。
WSサーバ210Aは、接続確認応答(pong)を受信すると、接続状態情報を作成する(ステップS510)。WSサーバ210Aは、通信インターフェイス260を介して、接続状態情報をアプリケーションサーバ300に送信する(ステップS512)。サーバAPI310Bは、接続状態情報をサーバAPP310Aに受け渡す(ステップS514)。
<アプリケーションサーバからの通常のデータプッシュ時の処理手順の詳細>
次に、本実施の形態にかかるネットワークシステム1におけるアプリケーションサーバ300からのデータプッシュ時の処理手順の詳細について説明する。より詳細には、以下では、本実施の形態にかかるネットワークシステム1におけるアプリケーションサーバ300からの通常の(小容量の)データプッシュ時の処理手順の詳細と大容量のデータプッシュ時の処理手順の詳細とに分けて説明する。
なお、アプリケーションサーバ300から送信される小容量のデータの例としては、コマンドなどのテキストファイル、小さいサイズの画像/音声/動画ファイル(再生すべきコンテンツで、容量の小さいもの)などが挙げられる。一方、アプリケーションサーバ300から送信される大容量のデータの例としては、大きいサイズの画像/音声/動画ファイルなどが挙げられる。
まずは、本実施の形態にかかるネットワークシステム1におけるアプリケーションサーバ300からのデータプッシュ時の処理手順の詳細について説明する。図21は、本実施の形態にかかるネットワークシステム1におけるアプリケーションサーバ300からの通常のデータプッシュ時の処理手順の詳細をシーケンス図である。
図21を参照して、サーバAPP310Aは、サーバAPI310Bに、データプッシュを要求する(ステップS602)。具体的には、サーバAPP310Aは、サーバAPI310Bに、クライアント100を特定するための接続IDと、データ本体と、アプリケーションを特定するためのデータとを受け渡す。サーバAPI310Bは、トランザクションIDを発行する(ステップS604)。
サーバAPI310Bは、WSデータ構造を判定する(ステップS606)。図25は、本実施形態にかかるWSデータの構造を示すイメージ図である。図25に示すように、WSデータ1000は、たとえば、type"sendbin_"(8bytes)、トランザクションID、データレングス、データ名、アプリ定義データレングス、アプリ定義データ、データレングス、データ本体などを含む。本実施の形態においては、サーバAPI310Bは、データ本体の容量が所定値より大きいか否かを判断する。あるいは、サーバAPI310Bは、クライアント100に送信すべきデータ全体の容量が、所定値より大きいか否かを判断する。ここでは、データ量が所定値以下である場合について説明する。
サーバAPI310Bは、常時接続サーバ200にデータプッシュを要求する(ステップS608)。具体的には、サーバAPI310Bは、通信インターフェイス360を介して常時接続サーバ200に、接続IDと、トランザクションIDと、WSデータ種別と、データ本体と、アプリケーションを特定するためのデータとを送信する。
WSサーバ210Aは、アプリケーションサーバ300からのデータを受信して、当該データをWebSocketプロトコルに対応したデータに構成しなおす(ステップS610)。WSサーバ210Aは、通信インターフェイス260を介して、WebSocketプロトコルを使用して、接続IDと、トランザクションIDと、WSデータ種別と、データ本体と、アプリケーションを特定するためのデータとをクライアント100に送信する(ステップS612)。
クライアントAPI110Bは、通信インターフェイス160を介して、WebSocketプロトコルを使用して、常時接続サーバ200からデータを受信する。クライアントAPI110Bは、受信したWSデータを解析する(ステップS614)。クライアントAPI110Bは、受信したデータをクライアントAPP100Aに受け渡す(ステップS616)。
クライアントAPI110Bは、通信インターフェイス160を介して、WebSocketプロトコルを使用して、トランザクションIDを含むデータを送信することによって、データ本体がクライアント100に届いた旨を常時接続サーバ200に通知する。WSサーバ210Aは、通信インターフェイス260を介して、トランザクションIDを含むデータを送信することによって、データ本体がクライアント100に届いた旨をアプリケーションサーバ300に通知する(ステップS620)。
<アプリケーションサーバからの大容量のデータプッシュ時の処理手順の詳細>
次に、本実施の形態にかかるネットワークシステム1におけるアプリケーションサーバ300からの大容量のデータプッシュ時の処理手順の詳細について説明する。図22は、本実施の形態にかかるネットワークシステム1におけるアプリケーションサーバ300からの大容量のデータプッシュ時の処理手順の詳細をシーケンス図である。
図22を参照して、サーバAPP310Aは、サーバAPI310Bに、データプッシュを要求する(ステップS702)。具体的には、サーバAPP310Aは、サーバAPI310Bに、クライアント100を特定するための接続IDと、データ本体と、アプリケーションを特定するためのデータとを受け渡す。サーバAPI310Bは、トランザクションIDを発行する(ステップS704)。
サーバAPI310Bは、WSデータ構造を判定する(ステップS706)。本実施の形態においては、サーバAPI310Bは、データ本体の容量が所定値より大きいか否かを判断する。あるいは、サーバAPI310Bは、クライアント100に送信すべきデータ全体の容量が、所定値より大きいか否かを判断する。ここでは、データ量が所定値より大きい場合について説明する。
サーバAPI310Bは、常時接続サーバ200にデータプッシュを要求する(ステップS708)。具体的には、サーバAPI310Bは、通信インターフェイス360を介して常時接続サーバ200に、接続IDと、トランザクションIDと、URL情報と、WSデータ種別と、アプリケーションを特定するためのデータと、結果通知フラグとを送信する。このとき、サーバAPI310Bは、サーバAPP310AにもトランザクションIDを受け渡す(ステップS710)。
WSサーバ210Aは、アプリケーションサーバ300からのデータを受信して、当該データをWebSocketプロトコルに対応したデータに構成しなおす(ステップS712)。WSサーバ210Aは、通信インターフェイス260を介して、WebSocketプロトコルを使用して、接続IDと、トランザクションIDと、URL情報と、WSデータ種別と、アプリケーションを特定するためのデータと、結果通知フラグとをクライアント100に送信する(ステップS714)。
クライアントAPI110Bは、通信インターフェイス160を介して、WebSocketプロトコルを使用して、常時接続サーバ200からデータを受信する。クライアントAPI110Bは、受信したデータを解析する(ステップS716)。
クライアントAPI110Bは、通信インターフェイス160を介して、HTTPプロトコルを使用して、受信したURL情報とトランザクションIDに基づいてアプリケーションサーバ300にデータを要求する(ステップS718)。サーバAPI310Bは、当該要求に応じて、クライアント100に送信すべきデータを組み立てる(ステップS720)。サーバAPI310Bは、通信インターフェイス360を介して、HTTPプロトコルを使用して、データ本体をクライアント100に送信する(ステップS722)。すなわち、クライアントAPI110Bは、通信インターフェイス260を介して、HTTPプロトコルを使用して、URLが示すアプリケーションサーバ300の格納場所からデータをダウンロードする。
クライアントAPI110Bは、受信したデータを解析する(ステップS724)。クライアントAPI110Bは、受信したデータをクライアントAPP100Aに受け渡す(ステップS726)。クライアントAPI110Bは、結果通知フラグを確認する(ステップS728)。
クライアントAPI110Bは、通信インターフェイス160を介して、HTTPプロトコルを使用して、アプリケーションサーバ300にクライアントにデータが届いた旨を通知する(ステップS732)。具体的には、クライアントAPI110Bは、トランザクションIDとデータプッシュ結果ステータスとをアプリケーションサーバ300に送信する。WSサーバ210Aは、トランザクションIDとデータプッシュ結果ステータスとをサーバAPP310Aに受け渡す(ステップS734)。
なお、ここでは、図21および図22を参照して、アプリケーションサーバ300がデータの大きさを判断する構成について説明したが、図6および図7に示したように、常時接続サーバ200が当該判断を行う構成であってもよい。
また、ここでは、図22を参照して、クライアント100が大容量のデータをアプリケーションサーバ300からダウンロードする構成について説明したが、図7に示したように、クライアント100は当該データを常時接続サーバ200からダウンロードしても良い。つまり、先に、アプリケーションサーバ300が常時接続サーバ200にデータを送信し、その後にクライアント100から常時接続サーバ200からデータをダウンロードする構成であってもよい。
<クライアントからの通常のデータプッシュ時の処理手順の詳細>
次に、本実施の形態にかかるネットワークシステム1におけるクライアント100からのデータプッシュ時の処理手順の詳細について説明する。より詳細には、以下では、本実施の形態にかかるネットワークシステム1におけるクライアント100からの通常の(小容量の)データプッシュ時の処理手順の詳細と大容量のデータプッシュ時の処理手順の詳細とに分けて説明する。
なお、クライアント100から送信される小容量のデータの例としては、日時ログなどのテキストファイル、小さいサイズの画像/音声/動画ファイル(カメラ画像とか、音声認識に利用する音声とか)などが挙げられる。一方、アプリケーションサーバ300から送信される大容量のデータの例としては、数日間以上の大量ログなどのテキストファイル、大きいサイズの画像/音声/動画ファイルなどが挙げられる。
まずは、本実施の形態にかかるネットワークシステム1におけるクライアント100からの通常のデータプッシュ時の処理手順の詳細について説明する。図23は、本実施の形態にかかるネットワークシステム1におけるクライアント100からの通常のデータプッシュ時の処理手順の詳細をシーケンス図である。
図23を参照して、クライアントAPP110Aは、クライアントAPI110Bに、データプッシュを要求する(ステップS802)。具体的には、クライアントAPP110Aは、クライアントAPI110Bに、自身を特定するための接続IDと、データ本体と、アプリケーションを特定するためのデータとを受け渡す。サーバAPI310Bは、トランザクションIDを発行する(ステップS804)。
クライアントAPI110Bは、WSデータ構造を判定する(ステップS806)。本実施の形態においては、クライアントAPI110Bは、データ本体の容量が所定値より大きいか否かを判断する。あるいは、クライアントAPI110Bは、常時接続サーバ200に送信すべきデータ全体の容量が、所定値より大きいか否かを判断する。ここでは、データ量が所定値以下である場合について説明する。
クライアントAPI110Bは、接続IDと、トランザクションIDと、WSデータ種別と、データ本体と、アプリケーションを特定するためのデータと含むWSデータをWebSocketプロトコルに対応したデータに構成しなおす(ステップS808)。クライアントAPI110Bは、通信インターフェイス160を介して、WebSocketプロトコルを使用して、組み立てたWSデータを常時接続サーバ200に送信する(ステップS810)。
WSサーバ210Aは、WSデータから接続IDを取得する(ステップS812)。WSサーバ210Aは、受信したWSデータを解析する(ステップS814)。WSサーバ210Aは、通信インターフェイス260を介して、クライアント100からのデータを送信する(ステップS816)。より詳細には、WSサーバ210Aは、通信インターフェイス160を介して、HTTPプロトコルを利用して、クライアント100の接続IDと、データ本体と、アプリケーションを特定するためのデータとをアプリケーションサーバ300に送信する。
サーバAPI310Bは、受信したデータをサーバAPP310Aに受け渡す(ステップS818)。サーバAPI310Bは、通信インターフェイス360を介して、トランザクションIDを含むデータを送信することによって、データ本体がアプリケーションサーバ300に届いた旨を常時接続サーバ200に通知する(ステップS822)。WSサーバ210Aは、通信インターフェイス360を介して、WebSocketプロトコルを使用して、トランザクションIDを含むデータを送信することによって、データ本体がアプリケーションサーバ300に届いた旨を通知する。
<クライアントからの大容量のデータプッシュ時の処理手順の詳細>
次に、本実施の形態にかかるネットワークシステム1におけるクライアント100からの大容量のデータプッシュ時の処理手順の詳細について説明する。図24は、本実施の形態にかかるネットワークシステム1におけるクライアント100からの大容量のデータプッシュ時の処理手順の詳細をシーケンス図である。
図24を参照して、クライアントAPP110Aは、クライアントAPI110Bに、データプッシュを要求する(ステップS902)。具体的には、クライアントAPP110Aは、クライアントAPI110Bに、クライアント100を特定するための接続IDと、データ本体と、アプリケーションを特定するためのデータとを受け渡す。クライアントAPI110Bは、トランザクションIDを発行する(ステップS904)。
クライアントAPI110Bは、WSデータ構造を判定する(ステップS906)。本実施の形態においては、クライアントAPI110Bは、データ本体の容量が所定値より大きいか否かを判断する。あるいは、クライアントAPI110Bは、常時接続サーバ200に送信すべきデータ全体の容量が、所定値より大きいか否かを判断する。ここでは、データ量が所定値より大きい場合について説明する。
クライアントAPI110Bは、接続IDと、トランザクションIDと、WSデータ種別と、アプリケーションを特定するためのデータと、データの容量とを含むWSデータをWebSocketプロトコルに対応したデータに構成しなおす(ステップS908)。クライアントAPI110Bは、通信インターフェイス160を介して、WebSocketプロトコルを使用して、組み立てたWSデータを常時接続サーバ200に送信する(ステップS910)。
WSサーバ210Aは、WSサーバ210Aは、受信したWSデータから接続IDを取得する(ステップS912)。WSサーバ210Aは、受信したWSデータを解析する(ステップS914)。WSサーバ210Aは、通信インターフェイス260を介して、データ本体の送信先のURLをアプリケーションサーバ300に要求する(ステップS916)。具体的には、WSサーバ210Aは、通信インターフェイス260を介して、接続IDと、アプリ定義データと、トランザクションIDとをアプリケーションサーバ300に送信する。
サーバAPI310Bは、常時接続サーバ200からの要求に応じて、アップロード用のURLを発行する(ステップS918)。サーバAPI310Bは、通信インターフェイス360を介して、常時接続サーバ200にクライアント100へのデータプッシュを要求する(ステップS920)。具体的には、サーバAPI310Bは、通信インターフェイス360を介して、HTTPプロトコルを利用して、接続IDと、トランザクションIDと、送信先URLと、WSデータ種別と、アプリケーションを特定するための情報とを常時接続サーバ200に送信する。
WSサーバ210Aは、アプリケーションサーバ300から受信した情報に基づいて、WebSocketプロトコルに対応したデータを組み立てる(ステップS922)。WSサーバ210Aは、通信インターフェイス260を介して、WebSocketプロトコルを使用して、WSデータをクライアント100に送信する(ステップS924)。
クライアントAPI110Bは、WSデータを解析する(ステップS926)。クライアントAPI110Bは、データ本体に基づいて送信用(アップロード用)のデータを組み立てる(ステップS928)。クライアントAPI110Bは、URL情報に基づいて、通信インターフェイス160を介して、HTTPプロトコルを使用して、アプリケーションサーバ300にデータ本体とトランザクションIDとをアップロードする(ステップS930)。
サーバAPI310Bは、受信したデータを解析する(ステップS932)。サーバAPI310Bは、トランザクションIDとデータ本体とを取得する(ステップS934)。サーバAPI310Bは、接続IDと、データ本体と、アプリケーションを特定するための情報とをサーバAPP310Aに受け渡す(ステップS936)。
サーバAPI310Bは、通信インターフェイス360を介して、トランザクションIDを含むデータを送信することによって、データ本体がアプリケーションサーバ300に届いた旨を常時接続サーバ200に通知する。WSサーバ210Aは、通信インターフェイス260を介して、WebSocketプロトコルを使用して、トランザクションIDを含むデータを送信することによって、データ本体がアプリケーションサーバ300に届いた旨を通知する(ステップS940)。
なお、ここでは、図24を参照して、クライアント100が大容量のデータをアプリケーションサーバ300にアップロードする構成について説明したが、図9に示したように、クライアント100は当該データを常時接続サーバ200にアップロードしても良い。そして、常時接続サーバ200が、アプリケーションサーバ300にデータを送信しても良い。
以上、ネットワークシステム1における各種の詳細な処理手順を説明した。本実施の形態にかかるネットワークシステム1では、接続IDに基づいて、アプリケーションサーバ300からのデータを、選択された1つのクライアント100にプッシュすることが可能となる。また、常時接続サーバ200を介して、クライアント100とアプリケーションサーバ300とがデータをプッシュし合うので、ネットワークシステムにかかる負荷を従来よりも低減させることができる。さらに、送信されるデータの容量でプロトコルを切り替えるため、一部のデータ送受信によってWebSocketプロトコルを使用する通信が占有される可能性を低減し、WebSocketプロトコルを使用する他のデータの送受信が行えなくなる可能性を低減することができる。
<第2の実施の形態>
次に、第2の実施の形態について説明する。上述の第1の実施の形態にかかるネットワークシステム1では、クライアント100および常時接続サーバ200の少なくともいずれかが、通常のHTTPプロトコルとWebSocketプロトコルとを使い分けていた。より詳細には、クライアント100および常時接続サーバ200の少なくともいずれかが、送信されるデータの容量が所定値よりも大きい場合には、HTTPプロトコルを使用してデータを送受信し、送信されるデータの容量が所定値以下である場合には、WebSocketプロトコルを使用してデータを送受信するものであった。
しかしながら、本実施の形態においては、データの容量ではなく、通信速度に基づいて適切なプロトコルを判断するものである。なお、アプリケーションサーバ300から送信されるデータのうちで早い通信速度を必要とするものは、たとえば、即時にコマンドを発行する必要のあるコマンドデータ(エアコン電源ON/OFFなど)、即時に再生が必要な画像/音声/動画ファイル(緊急なメッセージ例えば緊急地震速報など)などが挙げられる。一方、クライアント100から送信されるデータのうちで早い通信速度が必要とされる場合としては、たとえば、画像や音声などを即時に端末(スマートフォン)側などで再生する必要がある場合などが挙げられる。
以下、詳細に説明する。まず、図21のステップS606および図22のステップS706において、本実施の形態においては、サーバAPI310Bは、現在のWebSocketプロトコルに係る通信速度が所定値より遅いか否かを判断する。あるいは、サーバAPI310Bは、対象となるデータをWebSocketプロトコルで送信した場合における通信速度が所定値より遅いか否かを判断する。
具体的には、サーバAPI310Bは、通信インターフェイス360を介して、クライアント100に速度確認用の信号(ping)を送信し、応答信号(pong)が返ってくるまでの時間を計測することによって、通信速度を計算することができる。あるいは、サーバAPI310Bは、WSサーバ210Aに、同様の方法で通信速度を計算させても良い。
なお、ステップS608以降は、通信速度が所定値以上場合についての説明である。ステップS708以降は、通信速度が所定値より遅い場合についての説明である。
同様に、図23のステップS806および図24のステップS906において、本実施の形態においては、クライアントAPI110Bは、現在のWebSocketプロトコルに係る通信速度が所定値より遅いか否かを判断する。あるいは、クライアントAPI110Bは、対象となるデータをWebSocketプロトコルで送信した場合における通信速度が所定値より遅いか否かを判断する。
なお、ステップS808以降は、通信速度が所定値以上である場合についての説明である。ステップS908以降は、通信速度が所定値より遅い場合についての説明である。
ここでは、アプリケーションサーバ300が上記の判断する構成について説明したが、図6および図7と同様に、常時接続サーバ200が当該判断を行う構成であってもよい。
<第3の実施の形態>
さらに、プロトコルの選択方法に関して、第3の実施の形態について説明する。本実施の形態においては、送信時間に基づいて適切なプロトコルを判断するものである。以下、詳細に説明する。
まず、図21のステップS606および図22のステップS706において、本実施の形態においては、サーバAPI310Bは、対象となるデータをWebSocketプロトコルで送信した場合における送信時間が所定値より長いか否かを判断する。ステップS608以降は、送信時間が所定値以下である場合についての説明である。ステップS708以降は、送信時間が所定値より長い場合についての説明である。
同様に、図23のステップS806および図24のステップS906において、本実施の形態においては、クライアントAPI110Bは、対象となるデータをWebSocketプロトコルで送信した場合における送信時間が所定値より長いか否かを判断する。ステップS808以降は、送信時間が所定値以下である場合についての説明である。ステップS908以降は、送信時間が所定値より長い場合についての説明である。
ここでは、アプリケーションサーバ300が上記の判断する構成について説明したが、図6および図7と同様に、常時接続サーバ200が当該判断を行う構成であってもよい。
<第4の実施の形態>
さらに、プロトコルの選択方法に関して、第4の実施の形態について説明する。本実施の形態においては、WebSocketプロトコルに基づくデータの送受信の頻度に基づいて適切なプロトコルを判断するものである。なお、アプリケーションサーバ300から送信されるデータのうちで送受信の頻度が高いものとしては、たとえば、生死確認用のデータなどが挙げられる。一方、クライアント100から送信されるデータのうちで送受信の頻度が高いものとしては、たとえば、生死確認用のデータおよびログアップデータなどが挙げられる。
以下、詳細に説明する。まず、図21のステップS606および図22のステップS706において、本実施の形態においては、サーバAPI310Bは、WebSocketプロトコルを使用したデータの送受信の頻度が所定値よりも多いか否かを判断する。たとえば、サーバAPI310Bは、常時接続サーバ200とクライアント100との間で、1分当たりのWebSocketプロトコルを使用したデータの送受信の回数を計測する。あるいは、サーバAPI310Bは、常時接続サーバ200とクライアント100との間で、1分当たりのWebSocketプロトコルを使用したデータの送受信の回数をWSサーバ210Aから取得する。ステップS608以降は、当該回数が所定値以下である場合についての説明である。ステップS708以降は、当該回数が所定値より多い場合についての説明である。
同様に、図23のステップS806および図24のステップS906において、本実施の形態においては、クライアントAPI110Bは、WebSocketプロトコルを使用したデータの送受信の頻度が所定値よりも多いか否かを判断する。たとえば、クライアント100は、常時接続サーバ200とクライアント100との間で、1分当たりのWebSocketプロトコルを使用したデータの送受信の回数を計測する。クライアント100は、当該回数が所定値より多いか否かを判断する。ステップS808以降は、当該回数が所定値以下である場合についての説明である。ステップS908以降は、当該回数が所定値より多い場合についての説明である。
ここでは、アプリケーションサーバ300が上記の判断する構成について説明したが、図6および図7と同様に、常時接続サーバ200が当該判断を行う構成であってもよい。
<第5の実施の形態>
次に、第5の実施の形態について説明する。上述の第1から第4の実施の形態にかかるネットワークシステム1では、常時接続サーバ200が、クライアント100とのデータ送受信を制御するWSサーバ210Aの機能を有し、アプリケーションサーバ300の各々が、プログラムとしてのサーバAPP310Aの機能や認証情報を生成するサーバAPI310Bの機能を搭載するものであった。
しかしながら、本実施の形態においては、認証情報を生成する機能210Bを常時接続サーバ200が有するものである。図26は、第5の実施の形態にかかるネットワークシステム1の通信構成を示すイメージ図である。
<第6の実施の形態>
さらに、第6の実施の形態について説明する。本実施の形態においては、アプリケーションサーバ300Uが、WSサーバ310Wの機能と、認証情報を生成する機能310Zと、2つのサーバAPP310A,310Aの機能とを有する。図27は、第7の実施の形態にかかるネットワークシステム1の通信構成を示すイメージ図である。なお、本実施の形態にかかるネットワークシステム1においては、クライアント100に関する構成が第1の実施の形態とそれと同様であるため、クライアント100の構成については説明を繰り返さない。
図27を参照して、アプリケーションサーバ300Uは、WebSocketプロトコルを使用した通信を制御するプログラムとしてのWSサーバ310Wの機能と、認証情報を生成する機能310Zと、第1のサービスプログラムとしてのサーバAPP310Aの機能と、第2のサービスプログラムとしてのAPP310Aの機能とを有する。複数のサーバAPP310A,310Aの各々は、HTTPプロトコルを使用して、他のデータベース、スマートフォン500などと通信することができる。そして、サーバAPP310A,310Aは、WSサーバ310Wを介して、WebSocketプロトコルを使用して、クライアント100に情報をプッシュ送信することができる。
<第7の実施の形態>
さらに、第7の実施の形態について説明する。本実施の形態においては、第5および第6の実施の形態とは逆に、WSサーバの機能と、認証情報を生成する機能と、2つのサーバAPPの機能とが、バラバラに別のコンピュータに搭載される。図28は、第8の実施の形態にかかるネットワークシステム1の通信構成を示すイメージ図である。
図28を参照して、クライアント100は、HTTPプロトコルを使用して常時接続サーバ200T、認証情報生成サーバ200U、アプリケーションサーバ300A,300Bと通信することができるし、WebSocketプロトコルを使用して常時接続サーバ200Tと常時接続することもできる。より詳細には、クライアント100は、クライアントAPP110AとクライアントAPI110Bとを搭載する。クライアントAPP110Aは、クライアント100の各部を制御する。クライアントAPI110Bは、通信インターフェイス160を介して、HTTPプロトコルを使用して通信したり、HTTPプロトコル上で利用されるWebSocketプロトコルを使用して通信したりする。
常時接続サーバ200Tは、WebSocketプロトコルを使用してクライアント100との常時接続通信を制御するためのプログラムとしてのWSサーバ210Aを搭載する。常時接続サーバ200Tは、HTTPプロトコルを使用して、他のデータベース450にもアクセスすることができる。
認証情報生成サーバ200Uは、HTTPプロトコルを使用して複数のアプリケーションサーバ300との通信を制御する。本実施の形態においては、常時接続サーバ200Tは、HTTPプロトコルを使用して、認証情報生成サーバ200Uを介して、アプリケーションサーバ300A,300Bに任意のタイミングでデータを送信できる。
本実施の形態にかかるネットワークシステム1は、複数のアプリケーションサーバ300A,300Bを含む。複数のアプリケーションサーバ300A,300Bの各々は、クライアント100やスマートフォン500などにサービスを提供するプログラムとしてのサーバAPP310AとHTTPプロトコルを利用して常時接続サーバ200と通信するためのサーバAPI310Bとを搭載する。
たとえば、ネットワークシステム1は、掃除機100Aを制御するためのアプリケーションサーバ300Aと、エアコン100Bを制御するためのアプリケーションサーバ300Bなどを含む。複数のアプリケーションサーバ300A,300Bの各々は、HTTPプロトコルを使用して、常時接続サーバ200、他のデータベース、スマートフォン500などと通信することができる。そして、本実施の形態においては、アプリケーションサーバ300A,300Bは、HTTPプロトコルを使用して、常時接続サーバ200に任意のタイミングでデータを送信できる。
<第8の実施の形態>
上述した第1から第4の実施の形態においては、WebSocketプロトコルを利用してデータを送信するか、HTTPプロトコルを利用してデータを送信するかの判断するための基準が1種類であった。しかしながら、クライアント100、常時接続サーバ200、アプリケーションサーバ300は、2つ以上の基準に基づいて判断しても良い。以下では、説明のために、クライアント100、常時接続サーバ200、アプリケーションサーバ300を総称してコンピュータともいう。
たとえば、コンピュータは、第1の実施の形態の基準と第2の実施の形態の基準とに基づいて判断してもよい。そして、第1の実施の形態に関する条件を満たし、かつ、第2の実施の形態に関する条件を満たした場合に、コンピュータが、HTTPプロトコルを利用してデータをアップロードまたはダウンロードしても良い。あるいは、第1の実施の形態に関する条件および第2の実施の形態に関する条件のうちの少なくとも1つを満たした場合に、コンピュータが、HTTPプロトコルを利用してデータをアップロードまたはダウンロードしても良い。
同様に、コンピュータは、第1の実施の形態の基準と第3の実施の形態の基準とに基づいて判断してもよいし、第1の実施の形態の基準と第4の実施の形態の基準とに基づいて判断してもよいし、第2の実施の形態の基準と第3の実施の形態の基準とに基づいて判断してもよいし、第2の実施の形態の基準と第4の実施の形態の基準とに基づいて判断してもよいし、第3の実施の形態の基準と第5の実施の形態の基準とに基づいて判断してもよい。さらに、コンピュータは、3つ以上の基準に基づいて判断してもよい。そして、全ての条件を満たした場合、あるいは一部の条件を満たした場合に、コンピュータが、HTTPプロトコルを利用してデータをアップロードまたはダウンロードしても良い。
<その他の応用例>
本発明は、システム或いは装置にプログラムを供給することによって達成される場合にも適用できることはいうまでもない。そして、本発明を達成するためのソフトウェアによって表されるプログラムを格納した記憶媒体(あるいはメモリ)を、システム或いは装置に供給し、そのシステム或いは装置のコンピュータ(又はCPUやMPU)が記憶媒体に格納されたプログラムコードを読出し実行することによっても、本発明の効果を享受することが可能となる。
この場合、記憶媒体から読出されたプログラムコード自体が前述した実施の形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。
また、コンピュータが読出したプログラムコードを実行することにより、前述した実施の形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼動しているOS(オペレーティングシステム)などが実際の処理の一部または全部を行い、その処理によって前述した実施の形態の機能が実現される場合も含まれることは言うまでもない。
さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わる他の記憶媒体に書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるCPUなどが実際の処理の一部または全部を行い、その処理によって前述した実施の形態の機能が実現される場合も含まれることは言うまでもない。
今回開示された実施の形態はすべての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は、上記した説明ではなく、特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。