JP2011109254A

JP2011109254A - イベント取得制御方法、イベント要求装置、及び、サービス実行装置

Info

Publication number: JP2011109254A
Application number: JP2009260107A
Authority: JP
Inventors: Junichi Kodama; 淳一児玉
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2009-11-13
Filing date: 2009-11-13
Publication date: 2011-06-02
Anticipated expiration: 2029-11-13
Also published as: US8719387B2; JP5441631B2; US20110119362A1; CN102065074A; CN102065074B

Abstract

【課題】サービスで発生するイベントをポーリングで取得するシステムにおいて、ポーリングによるイベント取得のリアルタイム性を維持しつつ、負荷を軽減する。
【解決手段】サービス実行装置２０５がサービスの実行を要求するための入力中である場合は、サービス実行装置２０５がサービスの実行を要求するための入力中でない場合よりも、イベント取得装置２１６がイベントの取得を要求する間隔を短くする。
【選択図】図２

Description

本発明は、イベントの取得を制御する制御方法、イベントの取得を要求する要求装置、及び、サービスを実行する実行装置に関する。

クライアント同士でイベントを共有するネットワークシステムがある。例えば、クライアントがネットワークを介して接続されたサーバ上のサービスを実行し、サービスで発生したイベントを他のクライアントがサーバから取得する。その際、イベントの取得を行うクライアントは、ポーリングすなわち定期的にサーバに問い合わせを行うことによって所望のイベントを取得する。

従来、ポーリングによってデータを取得する際、データ取得のリアルタイム性を高めるためにはサーバへの問い合わせを短い間隔で行う必要があるが、それによって通信負荷が増大してしまうという問題があった。このような問題を解決するために、例えば、サーバがクライアントの通信記録に基づいて次のポーリングに好適な時間を算出し、クライアントに通知するといった試みがなされている（特許文献１）。

特開２００４−０８０１８７号公報

従来の方法は、サーバまたはクライアントにおいてあらかじめ登録されているスケジュールや通信状態といったシステム管理情報に基づいてポーリング間隔もしくはポーリング時間を決定している。しかしながら、ユーザが操作を行うことによって処理が開始された場合には、従来の方法ではユーザの操作に応じてポーリング制御を対応させることはできないという課題があった。

本発明は上述した問題を解決するためになされたものであり、ポーリングのリアルタイム性および負荷軽減を実現することを目的とする。

上記目的を達成するために、本発明のイベント取得制御方法は、サービスの実行を要求する要求装置からネットワークを介して要求されたサービスを実行し、サービスの実行により発生したイベントの取得を要求するイベント要求装置に前記ネットワークを介して要求されたイベントを通知するネットワークシステムにおけるイベント取得制御方法であって、前記要求装置がサービスの実行を要求するための入力中であるか、判断手段が判断し、前記要求装置がサービスの実行を要求するための入力中であると判断した場合は、前記要求装置がサービスの実行を要求するための入力中でないと判断した場合よりも、前記イベント要求装置がイベントの取得を要求する間隔を、間隔設定手段が短く設定することを特徴とする。

本発明によれば、サービスにおいて発生するイベント取得のためのポーリングを実行する際に、リアルタイム性確保のための負荷を軽減することが可能となる。

本発明の実施形態に係るイベント共有システムのハードウェア構成を示す図である。本発明の実施形態１に係るイベント共有システムのソフトウェア構成を示す図である。サービス実行装置及びサービス管理装置において管理される情報の一例を示す図である。本発明の実施形態に係るシステムにおける各装置間での処理の流れを示す図である。本発明の実施形態１に係るイベント共有システムにおいて、サービス実行装置がサービス管理装置に送信するメッセージの一例を示す図である。本発明の実施形態１及び２に係るイベント共有システムにおいて、サービス管理装置がイベント取得装置からのポーリングに対して返答するメッセージの一例を示す図である。サービス実行装置における操作状態設定処理を示すフローチャートである。サービス管理装置における操作状態設定処理を示すフローチャートである。本発明の実施形態１においてイベント取得装置がポーリング頻度を設定する際の処理を示すフローチャートである。本発明の実施形態３に係るイベント共有システムのソフトウェア構成を示す図である。本発明の実施形態３においてイベント取得装置がポーリング頻度を設定する際に使用するポーリング間隔設定テーブルを示す図である。

図１は、本発明の実施形態に係るネットワークシステムのハードウェア構成を示すブロック図である。ネットワーク１００を介し、クライアント装置１０１とサーバ装置１０２が接続されている。ネットワーク１００は、メッセージを通信できれば、どのような形態でもよく、例えばインターネット、ＷＡＮ、ＬＡＮなどである。

クライアント装置１０１は、制御部１０３、通信部１０４、記憶部１０５、ユーザ操作部１０６、表示部１０７を備える。クライアント装置１０１は、サーバ装置１０２上のサービスを実行するサービス実行側と、サービスで発生したイベントをサーバ装置１０２から取得するイベント取得側のどちらにもなり得る。

制御部１０３は、クライアント装置１０１における各処理部の処理を実行する。通信部１０４は、ネットワーク１００を使用して通信するためのインタフェースを含み、サーバ装置１０２との通信を制御する。記憶部１０５は、クライアント装置１０１における各処理部の作業領域やデータの格納場所となる記憶装置である。ユーザ操作部１０６は、ユーザからの操作を受信するための入力装置であり、例えばマウスやキーボード等である。表示部１０７は、クライアント装置１０１の処理結果を画面表示するための出力装置であり、例えば液晶ディスプレイ等である。

サーバ装置１０２は、制御部１０８、記憶部１０９、通信部１１０を備える。制御部１０８は、サーバ装置１０２における各処理部の処理を実行する。記憶部１０９は、サーバ装置１０２における各処理部の作業領域やデータの格納場所となる記憶装置である。通信部１１０は、ネットワーク１００を使用して通信するためのインタフェースを含み、クライアント装置１０１との通信を制御する。

図２は、本発明の第一の実施形態に係るネットワークシステムのソフトウェア構成を示す図である。サービス実行クライアント２０１、イベント取得クライアント２０３は、図１のクライアント装置１０１のソフトウェア構成を示し、サーバ２０２は、図１のサーバ装置１０２のソフトウェア構成を示す。サービス実行クライアント２０１、サーバ２０２、イベント取得クライアント２０３は、ネットワーク１００を介して接続される。

サービス実行クライアント２０１、イベント取得クライアント２０３は、クライアント装置１０１の制御部１０３が記憶部１０５に記憶されたプログラムを実行することにより実現される。また、サーバ２０２は、サーバ装置１０２の制御部１０８が記憶部１０９に記憶されたプログラムを実行することにより実現される。制御部１０３、１０８は、コンピュータである。記憶部１０５、１０９は、制御部１０３、１０８が読出すことができるように、図２を実現するためのプログラムを記憶している。サービス実行クライアント２０１がサーバ２０２上のサービスを実行することによってイベントが発生し、そのイベントをイベント取得クライアント２０３がポーリングで取得する。

なお、図１の同一のクライアント装置内にサービス実行クライアント２０１およびイベント取得クライアント２０３の両方が存在していてもよい。例えば、図１のネットワーク１００に接続された複数のクライアント装置１０１は、サービス実行クライアント２０１とイベント取得クライアント２０３の両方を備える。

複数のクライアント装置１０１のうち、サーバ２０２のサービス２０８の実行を要求するクライアント装置１０１がサービス実行クライアント２０１として動作する。そして、ネットワーク１００に接続された複数のクライアント装置１０１がイベント取得クライアント２０３として動作する。サービス実行クライアントとして動作するクライアント装置１０１は、イベント取得クライアント２０３としても動作し、サーバ２０２で発生したイベントを取得する。

サービス実行装置２０５は、サービスの実行を要求する要求装置である。サービス管理装置２０９は、サービス実行装置２０５からネットワーク１００を介して要求されたサービスを実行するサービス実行装置である。また、イベント取得装置２１６は、サービスの実行により発生したイベントの取得を要求するイベント要求装置である。サービス管理装置２０９は、イベント取得装置２１６にネットワーク１００を介して要求されたイベントを通知する。サービス実行装置２０５、サービス管理装置２０９、イベント取得装置２１６は、ネットワーク１００に接続される。イベント取得装置２１６からネットワーク１００を介して要求されたイベントをイベント取得装置２１６にネットワーク１００を介して通知する。

サービス２０８は、例えば、議事録作成サービスであり、サービス実行クライアント２０１のアプリケーション２０４は、例えば、議事録入力アプリケーションである。また、イベント取得クライアント２０３のアプリケーション２１５は、議事録表示アプリケーションである。議事録入力アプリケーションと議事録表示アプリケーションは、同一の議事録アプリケーションが実現する機能として構成してもよい。

図２を参照して、本実施形態のイベント取得制御方法を説明する。

サービス実行クライアント２０１は、アプリケーション２０４へのユーザ操作に応じてサーバ２０２上のサービスを実行するサービス実行装置２０５を備える。サービス実行装置２０５では、サービス実行のためのユーザ操作の入力を受信するユーザ操作受信部２０６が、現在の（ユーザ）操作状態が入力処理中か入力待機中かをアプリケーションごとに判断する。

ユーザ操作受信部２０６は、図１のユーザ操作部１０６からのユーザ操作を受信する。当該操作状態が入力処理中の場合には、入力処理中であることを、リクエスト通知部２０７を通じて定期的にサーバ２０２に通知する。入力処理中とはアプリケーションに対してサービス実行のためのユーザ操作が行われている状態を指し、入力待機中とはユーザ操作が行われていない状態を指す。

サービス実行のリクエストメッセージを通知するリクエスト通知部２０７は、アプリケーション２０４へのサービス実行のためのユーザ操作が確定されると、サービス実行リクエストをサーバ２０２に通知する。リクエスト通知部２０７は、サービス実行リクエストを図１の通信部１０４を介してサーバ２０２に通知する。

操作状態を判断するユーザ操作受信部２０６が管理する情報は、例えば、図３（Ａ）に示すように、登録アプリケーション３０１ごとの、利用サービス情報３０２、最終入力受信時間情報３０３、操作状態３０４である。この情報は図１の記憶部１０５に格納される。登録アプリケーション３０１は、当該サービス実行クライアントにインストールされ、サービス実行装置２０５に登録されているアプリケーション２０４についての情報である。

利用サービス情報３０２は、アプリケーション２０４が利用するサービスについての情報である。最終入力受信時間情報３０３は、アプリケーション２０４を使用するユーザがサービスを実行するために行った操作の入力を受信した最終時間についての情報である。操作状態３０４は、ユーザ操作受信部２０６が判断した操作状態についての情報である。

サーバ２０２は、サービス実行クライアント２０１からのサービス実行リクエストに応じてサービス２０８を実行するサービス管理装置２０９を備える。サービス管理装置２０９では、リクエスト受信部２１０がサービス実行クライアント２０１からのサービス実行リクエストを受信し、サービス実行部２１１に対応するサービスの実行を指示する。また、リクエスト受信部２１０は、サービス実行クライアント２０１から受信した操作状態を（サービス状態）管理部２１２に通知する。リクエスト受信部２１０は、サービス実行クライアント２０１からの情報を、通信部１１０を介して受信する。

サービス実行部２１１は、リクエスト受信部２１０からの指示に応じてサービス２０８を実行し、実行の結果生じたイベント情報をデータ記憶部２１３に格納し管理する。データ記憶部２１３は、図１の記憶部１０９内に設けられる。

管理部２１２は、リクエスト受信部２１０から通知される操作状態に応じて、現在の操作状態が実行処理中か実行待機中かをサービスごとに設定する。現在の操作状態は、図１の記憶部１０９内に設定される。実行処理中とは当該サービスに対し入力処理中のサービス実行クライアントが存在する状態を指し、実行待機中とはそうでない状態を指す。入力処理中とは、サービス２０８に対して通知するデータをユーザが入力している状態である。このユーザから入力されたデータは、ユーザ操作受信部２０６で受信される。

管理部２１２は、サービス実行装置２０５がサービスの実行を要求するための入力中であるか判断し、サービスの実行を要求するための入力中であると判断すると、そのサービスの操作状態を実行処理中に設定する。管理部２１２は、サービスを利用しているクライアントを管理し、さらに、クライアントごとに、入力中であるか、待機中であるか管理する。

イベント取得クライアント２０３からのイベント取得のためのポーリングは、ポーリング受信部２１４が受信する。ポーリング受信部２１４は、ポーリングを図１の通信部１１０を介して受信する。ポーリング受信部２１４は、ポーリングを受信すると、サービス実行部２１１が管理するイベント情報、管理部２１２が管理する操作状態を取得し、それらの情報をメッセージに付加して応答する。

サービス管理装置２０９は、この操作状態により、イベント取得クライアント２０３のポーリング間隔を設定する。サービス実行装置２０５がサービスの実行を要求するための入力中であると判断した場合は、サービス実行装置２０５がサービスの実行を要求するための入力中でないと判断した場合よりも、イベント取得装置２１６がイベントの取得を要求する間隔を短く設定する。

サービス２０８が議事録作成サービスであり、イベント取得クライアント２０３のアプリケーション２１５が議事録表示アプリケーションである場合は、以下のような動作が行われる。すなわち、ポーリング受信部２１４は、イベント取得クライアント２０３からポーリングを受信する。すると、ポーリング受信部２１４は、イベント取得クライアント２０３が議事録表示アプリケーションで表示すべき議事録と、サービス実行クライアント２０１の操作状態をイベント取得クライアント２０３に送信する。議事録表示アプリケーションで表示すべき議事録は、イベント情報である。

操作状態を判断する管理部２１２が管理する情報は、例えば、登録サービス４０１ごとの、図３（Ｂ）に示す情報である。すなわち、利用クライアント情報４０２、最終通知受信時間情報４０３、クライアント操作状態情報４０４、操作状態４０５である。

登録サービス４０１は、当該サーバにデプロイされ、サービス管理装置２０９に登録されているサービス２０８についての情報である。利用クライアント情報４０２は、サービス２０８を利用するサービス実行クライアント２０１についての情報である。最終通知受信時間情報４０３は、サービス２０８を使用するサービス実行クライアント２０１からの操作状態の通知メッセージを受信した最終時間についての情報である。クライアント操作状態情報４０４は、各クライアントの操作状態についての情報である。操作状態４０５は、管理部２１２が判断した操作状態についての情報である。

本形態では、実行可能なサービス２０８は、ネットワーク１００上に複数存在する。この場合、管理部２１２は、サービス実行装置２０５が実行を要求するための入力中であるか、サービスごとに判断する。サービス実行装置２０５がサービスの実行を要求するための入力中であると判断したサービスの実行により発生したイベントの取得を要求する間隔を、入力中でないと判断した場合よりも、管理部２１２は短く設定する。

また、図３（Ｂ）の場合、サービス実行クライアント２０１（または要求装置であるサービス実行装置２０５）がネットワーク１００上に複数存在する。このような場合、サービス管理装置２０９は、複数のサービス実行装置２０５の少なくとも１つがサービスの実行を要求するための入力中であるか判断する。そして、複数のサービス実行装置２０５の少なくとも１つが入力中であると判断した場合は、サービス実行装置２０５の全てがサービスの実行を要求するための入力中でないと判断した場合よりも、サービス管理装置２０９は、イベント取得装置２１６がイベントの取得を要求する間隔を、短く設定する。

イベント取得クライアント２０３は、ポーリングでサーバ２０２からイベントを取得し、アプリケーション２１５に通知するイベント取得装置２１６を備える。イベント取得装置２１６では、ポーリング実行部２１７がポーリング頻度決定部２１８の決定したポーリング頻度に従ってサーバ２０２に対してポーリングを行い、サーバ２０２上のサービスで発生したイベントを取得する。ポーリング実行部２１７は、図１の通信部１０４を介してポーリングの実行及びイベントの取得を行う。ポーリング実行部２１７は、ポーリングの返答メッセージに付加されたイベント情報をアプリケーション２１５に通知し、操作状態をポーリング頻度決定部２１８に通知する。

ポーリング頻度決定部２１８は、通知された操作状態を基にポーリング頻度を設定する。すなわち、ポーリング頻度決定部２１８は、サービス実行装置２０５がサービスの実行を要求するための入力中であるか判断する。そして、ポーリング頻度決定部２１８は、サービス実行装置２０５がサービスの実行を要求するための入力中であると判断した場合は、入力中でないと判断した場合よりも、イベントの取得を要求する間隔を短く設定する。なお、イベント取得装置２１６は、サービス実行装置２０５から要求されたサービスをサービス管理装置２０９が実行することにより発生したイベントの取得を要求するイベント要求装置である。

ポーリング実行部２１７は、ポーリング頻度決定部２１８が設定したポーリング頻度に応じてポーリング間隔を制御する。すなわち、ポーリング頻度が高いサービスに対してポーリング間隔を短くし、ポーリング頻度が低いサービスに対してポーリング間隔を長くする。この制御では、複数のサービスのそれぞれに対するポーリング間隔は独立に設定される。ポーリング頻度が高いサービスに対するポーリング頻度は、例えば、０．１秒間隔であり、ポーリング頻度が低いサービスに対するポーリング頻度は、例えば、１０秒間隔である。

また、ポーリング実行部２１７は、ポーリング頻度に応じてポーリング割り当てを制御する。すなわち、ポーリング頻度が高いサービスに対して割り当てを多くし、ポーリング頻度が低いサービスに対して割り当てを少なくする。この制御では、所定の間隔（例えば、０．０４秒間隔）で、複数のサービスのいずれかに対し、ポーリングを行う。そして、どのサービスにポーリングを行うか決定する際に、ポーリング頻度の高いサービスを優先する。すなわち、サービス実行装置２０５が実行を要求するための入力中であると判断したサービスの実行により発生したイベントの取得を要求する頻度を、入力中でないと判断したサービスの実行により発生したイベントの取得を要求する頻度よりも、管理部２１２は高く設定する。

実施においては、上述の制御のいずれか一つあるいは二つを組み合わせて使用する。例えば、ポーリング頻度が高いサービスが１つまたは２つであれば、前者の制御を、ポーリング頻度が高いサービスが３つ以上であれば、後者の制御を行う。

図４は、本発明の実施形態に係るネットワークシステムにおける各装置間での処理の流れを示す図である。なお、サービス実行装置２０５は、サービスの実行を要求する要求装置である。サービス管理装置２０９は、サービス実行装置２０５からネットワーク１００を介して要求されたサービスを実行するサービス実行装置である。また、イベント取得装置２１６は、サービスの実行により発生したイベントの取得を要求するイベント要求装置である。

イベント取得装置２１６を備えるイベント取得クライアント２０３は、サービスで発生したイベントを取得するために、サービス管理装置２０９を備えるサーバ２０２に定期的にポーリングを行う（Ｌ５０１）。このポーリングの頻度は低く（例えば１０秒）設定されているものとする。

サーバ２０２は、ポーリングを受信すると、通知するイベント情報、操作状態を返答するが、通知するイベントがない場合には操作状態のみをメッセージに含める。なお、現時点においては操作状態が入力処理中のクライアントが存在しないため、サービスの操作状態は実行待機中であるとする（Ｌ５０２）。なお、操作状態が実行待機中であるサービスのポーリング頻度は、低く設定されたままにする。

サービス実行装置２０５を備えるサービス実行クライアント２０１が、サービス実行のためのユーザ操作の入力を受信する（Ｌ５０３）。サービス実行クライアント２０１は、対象となるサービスに対して操作状態が入力処理中であることをリクエスト通知部２０７からサーバ２０２に通知する（Ｌ５０４）。

通知を受信したサーバ２０２は、当該サービスの操作状態を実行処理中に設定する。すなわち、管理部２１２は、サービス実行装置２０５がサービスの実行を要求するための入力中であるか判断する。入力中であると判断すると、そのサービスの操作状態を実行処理中に設定する。

サービス実行クライアント２０１は、操作状態が入力処理中である間は、定期的にサーバ２０２に操作状態（入力処理中）を通知する（不図示）。サービス管理装置２０９は、クライアントがサービスの利用を開始すると、管理部２１２により、そのクライアントがそのサービスを利用していること、及び、そのクライアントの操作状態を管理する。

イベント取得クライアント２０３は、サーバ２０２にポーリングを行う（Ｌ５０５）。サーバ２０２は、ポーリングに対して操作状態を含むメッセージを返答する（Ｌ５０６）。返答メッセージを受信したイベント取得クライアント２０３は、操作状態が実行処理中であるサービスのポーリング頻度を高く（例えば０．１秒）設定する（Ｌ５０７）。サービス実行装置２０５がサービスの実行を要求するための入力中であると判断した場合は、サービス実行装置２０５がサービスの実行を要求するための入力中でないと判断した場合よりも、イベント取得装置２１６がイベントの取得を要求する間隔を短く設定する。

サービス実行クライアント２０１でサービス実行のためのユーザ操作が確定する（Ｌ５０８）。サービス実行クライアント２０１は、サービス実行リクエストをサーバ２０２に通知する。（Ｌ５０９）。サービス実行リクエストを受信したサーバ２０２は、対応するサービスを実行し、それによりイベントが発生する。イベント取得クライアント２０３は、サーバ２０２にポーリングを行う（Ｌ５１０）。このポーリングは、Ｌ５０７で高く設定されたポーリング頻度で行われる。サーバ２０２は、ポーリングに対してイベント情報を含めたメッセージを返答する（Ｌ５１１）。

サーバ２０２は、実行したサービスの結果を必要があればサービス実行クライアント２０１に返す（不図示）。

図５は、サービス実行装置２０５がサービス管理装置２０９に送信するメッセージがＳＯＡＰメッセージである場合の一例を示した図である。ＳＯＡＰメッセージ６０１は、ヘッダ部６０２およびボディ部６０３から構成される。ヘッダ部６０２は、ポーリング情報６０４を含む。ポーリング情報６０４は、サービス実行クライアント２０１におけるサービス実行のための操作状態を表す情報であり、例えば、サービス識別子６０５および当該サービスに対する操作状態６０６を含む。なお、この例ではボディ部６０３にサービス実行リクエストが含まれているが、操作状態のみを通知する場合には、ボディ部６０３は空でもよい。

図６（Ａ）は、サービス管理装置２０９がイベント取得装置２１６に送信するメッセージがＳＯＡＰメッセージである場合の一例を示した図である。ＳＯＡＰメッセージ７０１は、ヘッダ部７０２およびボディ部７０３から構成される。ヘッダ部７０２は、ポーリング情報７０４を含む。ポーリング情報７０４は、サーバ２０２におけるサービスの操作状態を表す情報であり、例えば、サービス識別子７０５および当該サービスの操作状態７０６を含む。なお、この例ではボディ部７０３にイベント情報が含まれているが、通知するイベントがなく操作状態のみを通知する場合には、ボディ部７０３は空でもよい。

図７は、サービス実行装置２０５における操作状態設定処理を示すフローチャートである。

まず、サービス実行装置２０５は、アプリケーション２０４に対するサービス実行のためのユーザ操作の入力を受信する（Ｓ８０１）。対応するサービスの操作状態（図３（Ａ））を入力処理中に設定する（Ｓ８０２）。その後、定期的に（例えば、１分毎）、前回のユーザ操作の入力を受信してから設定時間が経過したか否かを判定する（Ｓ８０３）。Ｓ８０３において設定時間が経過していると判定された場合には、操作状態を入力待機中に戻す（Ｓ８０４）。

一方、Ｓ８０３において設定時間が経過していないと判定された場合には、操作状態を入力処理中のまま変更せずに、再び一定時間後にＳ８０３の判定を行う。この設定時間の計時中に、アプリケーション２０４に対するサービス実行のためのユーザ操作の入力が受信されると、その入力から設定時間の経過を計時する。

このような操作状態設定処理方法により、ユーザがサービス実行のための操作を行っている間は、操作状態が入力処理中に保たれることになる。サービス実行装置２０５は、サービス管理装置２０９へ操作状態の通知メッセージを、Ｓ８０３の判定が行われる度に送信する。また、この送信は、別途設定された間隔に従って送信してもよい。

図８は、サービス管理装置２０９における操作状態設定処理を示すフローチャートである。

まず、サービス管理装置２０９は、サービス実行装置２０５からサービスごとの操作状態の通知メッセージを受信する（Ｓ９０１）。受信した通知メッセージに応じて、当該サービス実行装置の操作状態がサービス実行のための入力処理中か否かの判定する（Ｓ９０２）。すなわち、管理部２１２は、サービス実行装置２０５がサービスの実行を要求するための入力中であるか判断する（判断手順）。Ｓ９０２において操作状態が入力処理中であると通知されたサービスに対しては、当該サービスの操作状態（図３（Ｂ））を実行処理中に設定する（Ｓ９０３）。

その後、定期的に、操作状態が入力処理中である通知メッセージの前回の受信から設定時間が経過したか否かを判定する（Ｓ９０４）。Ｓ９０４において設定時間が経過していると判定された場合には、操作状態を実行待機中に戻す（Ｓ９０５）。この設定時間（例えば２分）は、サービス実行装置２０５がサービス実行のための入力処理中であることを通知するメッセージを送信する間隔（例えば１分）より長く設定される。

一方、Ｓ９０４において設定時間が経過していないと判定された場合には、操作状態を実行処理中のまま変更せずに、再び一定時間後にＳ９０４の判定を行う。

また、Ｓ９０２において操作状態が入力待機中であると通知されたサービスについては、当該サービスに対する操作状態が入力処理中となっているクライアントが他に存在するか否かの判定を行う（Ｓ９０６）。Ｓ９０６において対象クライアントが存在する場合には、操作状態は実行処理中となっている状態のまま変更せずに、Ｓ９０４の処理を実施する。一方、Ｓ９０６において対象クライアントが存在しない場合には、Ｓ９０５の処理を実施し、操作状態を実行待機中に戻す。

このような操作状態設定処理方法により、ユーザがサービス実行のための操作を行っているクライアントが存在する間は、当該サービスの操作状態が実行処理中に保たれることになる。

ポーリング受信部２１４は、イベント取得装置２１６からのポーリングに応じて、イベント及び操作状態をイベント取得装置２１６に送信する。操作状態は、サービス実行装置２０５がサービスの実行を要求するための入力中であるか否かを示す。サービス管理装置２０９は、この操作状態をイベント取得装置２１６に設定することにより、イベント取得装置２１６が行うポーリングの間隔を指示する（指示手順）。サービスを実行するための入力中の場合には、入力中でない場合より、ポーリング間隔が短くなるように間隔設定される。

図９は、本発明の第一の実施形態においてイベント取得装置２１６がポーリング頻度を設定する際の処理を示すフローチャートである。

まず、イベント取得装置２１６は、サービス管理装置２０９へのポーリングの返答メッセージとして操作状態を含むポーリング情報を取得する（Ｓ１００１）。取得したポーリング情報を基に各サービスの操作状態を判断する（Ｓ１００２）（判断手順）。Ｓ１００２において操作状態が実行処理中のサービスに対してはポーリング頻度を高く設定する（Ｓ１００３）。一方、Ｓ１００２において操作状態が実行待機中のサービスに対してはポーリング頻度を低く設定する（Ｓ１００４）（間隔を短縮する短縮手順）。

すなわち、ポーリング頻度決定部２１８は、サービス実行装置２０５がサービスの実行を要求するための入力中であるか判断する。そして、ポーリング頻度決定部２１８は、サービス実行装置２０５がサービスの実行を要求するための入力中であると判断した場合は、入力中でないと判断した場合よりも、イベントの取得を要求する間隔を短く設定する。

次に、本発明の第二の実施形態について説明する。第一の実施形態においては、イベント取得クライアント２０３で操作状態を基にポーリング頻度を決定する場合を示した。本実施形態においては、サーバ２０２で操作状態を基にポーリング頻度を設定し、ポーリング情報としてイベント取得クライアント２０３に通知する場合を示す。

本発明の第二の実施形態に係るイベント共有システムのソフトウェア構成を説明する。なお、本システムのハードウェア構成は、図１と共通である。

サービス管理装置２０９の管理部２１２は、ポーリング頻度の算出を行う。管理部２１２は、管理部２１２が管理する操作状態を基にポーリング頻度を算出する。ポーリング受信部２１４は、管理部２１２からポーリング頻度情報を取得し、イベント取得装置２１６からのポーリングに対してそのポーリング頻度情報を付加したメッセージを応答する。ポーリング実行部２１７は受信したポーリング頻度情報に応じてポーリングを実行する。

サービス実行装置２０５は、サービスの実行を要求する要求装置である。サービス管理装置２０９は、サービス実行装置２０５からネットワーク１００を介して要求されたサービスを実行するサービス実行装置である。イベント取得装置２１６は、サービスの実行により発生したイベントの取得を要求するイベント要求装置である。また、サービス管理装置２０９は、イベント取得装置２１６にネットワーク１００を介して要求されたイベントを通知する。

サービス状態管理部２１２は、サービス実行装置２０５がサービスの実行を要求するための入力中であるか判断する。そして、サービス実行装置２０５がサービスの実行を要求するための入力中であると判断した場合は、入力中でないと判断した場合よりも、イベント取得装置２１６がイベントの取得を要求する間隔を短くするように、イベント取得装置２１６に指示する。

図６（Ｂ）は、本発明の第二の実施形態に係るイベント共有システムにおいて、サービス管理装置２０９がイベント取得装置２１６に送信するメッセージがＳＯＡＰメッセージである場合の一例を示した図である。ポーリング情報７０４は、例えば、サービス識別子７０５に対応するサービスへのポーリング間隔情報１２０１を含む。

次に、本発明の第三の実施形態について説明する。第一および第二の実施形態においては、操作状態のみを基にポーリング頻度を決定する場合を示した。本実施形態においては、操作状態の他に、イベント取得装置における操作状態、サービス優先度、サーバでの通信負荷状態等の情報を基にポーリング頻度を設定する場合を示す。本形態におけるイベント取得制御方法を説明する。

図１０は、本発明の第三の実施形態に係るイベント共有システムのソフトウェア構成を示す図である。なお、本システムのハードウェア構成は、図１と共通である。

サービス管理装置２０９の管理部２１２は、通信負荷算出部１３０１を備える。通信負荷算出部１３０１は、サービス管理装置２０９におけるポーリングによる通信負荷状態を管理する。通信負荷状態は、通信データ量などにより定まる。ポーリング受信部２１４は、ポーリングを受信すると、サービス実行部２１１が管理するイベント情報、管理部２１２が管理する操作状態および通信負荷状態を取得し、それらの情報をメッセージに付加して応答する。

イベント取得装置２１６は、クライアント状態管理部１３０２を備える。クライアント状態管理部１３０２は、操作状態管理部１３０３、アプリ優先度管理部１３０４を備える。操作状態管理部１３０３は、イベント取得のための現在の操作状態が取得処理中か取得待機中かをアプリケーションごとに管理する。取得処理中とはアプリケーションに対してイベント取得のためのユーザ操作が行われている状態を指し、取得待機中とはユーザ操作が行われていない状態を指す。例えば、取得処理中は、サービス２０８から取得したデータを表示するアプリケーションをユーザがアクティブにしている状態である。アプリ優先度管理部１３０４は、サービスへのイベント取得に係る優先度設定をアプリケーションごとに管理する。

ポーリング頻度決定部２１８は、サービス管理装置２０９から通知された操作状態および通信負荷状態、クライアント状態管理部１３０２が管理する操作状態およびアプリ優先度を基にポーリング頻度を決定する。

すなわち、サービス実行装置２０５は、サービスの実行を要求する要求装置である。サービス管理装置２０９は、サービス実行装置２０５から要求されたサービスを実行するサービス実行装置である。イベント取得装置２１６は、サービス管理装置２０９によるサービスの実行により発生したイベントの取得をネットワーク１００を介して要求するイベント要求装置である。

ポーリング頻度決定部２１８は、サービス実行装置２０５がサービスの実行を要求するための入力中であるか判断する。そして、サービス実行装置２０５がサービスの実行を要求するための入力中であると判断した場合は、入力中でないと判断した場合よりも、イベントの取得を要求する間隔を、ポーリング頻度決定部２１８が短く設定する。

あるいは、入力中であると判断したサービスの実行により発生したイベントの取得を要求する頻度を、入力中でないと判断したサービスの実行により発生したイベントの取得を要求する頻度よりも、ポーリング頻度決定部２１８が高く設定する。

図１１は、本発明の第三の実施形態においてイベント取得装置２１６が、ポーリング頻度を設定する際に使用するポーリング頻度設定テーブルを示す図である。ポーリング頻度は、操作状態、イベント取得クライアント２０３における操作状態、サービス優先度に応じて設定される。操作状態１４０１が実行処理中、操作状態１４０２が取得処理中、サービス優先度１４０３が高優先度の場合に、もっとも高いポーリング頻度Ｔ０１でポーリングを実施する。一方、操作状態１４０１が実行待機中、操作状態１４０２が取得待機中、サービス優先度１４０３が低優先度の場合に、もっとも低いポーリング頻度Ｔ１２でポーリングを実施する。

図１１では操作状態１４０１、イベント取得クライアント２０３における操作状態１４０２、サービス優先度１４０３に応じたポーリング頻度決定テーブルを示した。本実施例においては、これらに加えてサービス管理装置２０９から通知される通信負荷情報に応じて、通信負荷が高い場合はポーリング頻度を低く、通信負荷が低い場合はポーリング頻度を高く調整してもよい。

本実施形態においては、サービス管理装置２０９に当該サーバに係る状態を管理する管理部２１２を備え、イベント取得装置２１６に当該クライアントに係る状態を管理するクライアント状態管理部１３０２を備える例を示した。それにより、サービス実行のための操作状態をより有効に使用してポーリング頻度を決定する。なお、ポーリング頻度決定部２１８は、管理部２１２およびクライアント状態管理部１３０２が管理する任意の情報でポーリング頻度を決定可能であり、本実施例で説明した情報に限らなくてもよい。

（その他の実施例）
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

２０１サービス実行クライアント
２０２サーバ
２０３イベント取得クライアント

Claims

サービスの実行を要求する要求装置からネットワークを介して要求されたサービスを実行し、サービスの実行により発生したイベントの取得を要求するイベント要求装置に前記ネットワークを介して要求されたイベントを通知するネットワークシステムにおけるイベント取得制御方法であって、
前記要求装置がサービスの実行を要求するための入力中であるか、判断手段が判断し、
前記要求装置がサービスの実行を要求するための入力中であると判断した場合は、前記要求装置がサービスの実行を要求するための入力中でないと判断した場合よりも、前記イベント要求装置がイベントの取得を要求する間隔を、間隔設定手段が短く設定することを特徴とするイベント取得制御方法。
前記要求装置が前記ネットワーク上に複数存在する場合、前記複数の要求装置の少なくとも１つがサービスの実行を要求するための入力中であるか、前記判断手段が判断し、前記複数の要求装置の少なくとも１つがサービスの実行を要求するための入力中であると判断した場合は、前記要求装置の全てがサービスの実行を要求するための入力中でないと判断した場合よりも、前記イベント要求装置がイベントの取得を要求する間隔を、前記間隔設定手段が短く設定することを特徴とする請求項１記載のイベント取得制御方法。
実行可能なサービスが複数存在する場合、前記要求装置が実行を要求するための入力中であるか、前記判断手段がサービスごとに判断し、前記要求装置がサービスの実行を要求するための入力中であると判断したサービスの実行により発生したイベントの取得を要求する間隔を、前記要求装置が当該サービスの実行を要求するための入力中でないと判断した場合よりも、前記間隔設定手段が短く設定することを特徴とする請求項１記載のイベント取得制御方法。
サービスの実行を要求する要求装置からのネットワークを介した要求により複数のサービスを実行し、複数のサービスのそれぞれを実行することにより発生したイベントをイベント要求装置からの前記ネットワークを介した要求により前記イベント要求装置に通知するネットワークシステムにおけるイベント取得制御方法であって、
前記要求装置が実行を要求するための入力中であるか、判断手段が複数のサービスのそれぞれについて判断し、
前記要求装置が実行を要求するための入力中であると判断したサービスの実行により発生したイベントの取得を要求する頻度を、前記要求装置が実行を要求するための入力中でないと判断したサービスの実行により発生したイベントの取得を要求する頻度よりも、頻度設定手段が高く設定することを特徴とするイベント取得制御方法。
サービスの実行を要求する要求装置から要求されたサービスを実行するサービス実行装置によるサービスの実行により発生したイベントの取得をネットワークを介して要求するイベント要求装置におけるイベント取得制御方法であって、
前記要求装置がサービスの実行を要求するための入力中であるか、判断手段が判断し、
前記要求装置がサービスの実行を要求するための入力中であると判断した場合は、前記要求装置がサービスの実行を要求するための入力中でないと判断した場合よりも、イベントの取得を要求する間隔を、間隔設定手段が短く設定することを特徴とするイベント取得制御方法。
サービスの実行を要求する要求装置からの要求により複数のサービスのそれぞれをサービス実行装置が実行することにより発生したイベントをネットワークを介して要求するイベント要求装置におけるイベント取得制御方法であって、
前記要求装置が実行を要求するための入力中であるか、判断手段が複数のサービスのそれぞれについて判断し、
前記要求装置が実行を要求するための入力中であると判断したサービスの実行により発生したイベントの取得を要求する頻度を、前記要求装置が実行を要求するための入力中でないと判断したサービスの実行により発生したイベントの取得を要求する頻度よりも、頻度設定手段が高く設定することを特徴とするイベント取得制御方法。
サービスの実行を要求する要求装置からネットワークを介して要求されたサービスを実行し、サービスの実行により発生したイベントの取得を要求するイベント要求装置に前記ネットワークを介して要求されたイベントを通知するサービス実行装置におけるイベント取得制御方法であって、
前記要求装置がサービスの実行を要求するための入力中であるか、判断手段が判断し、
前記要求装置がサービスの実行を要求するための入力中であると判断した場合は、前記要求装置がサービスの実行を要求するための入力中でないと判断した場合よりも、前記イベント要求装置がイベントの取得を要求する間隔を短くするように、指示手段が前記イベント要求装置に指示することを特徴とするイベント取得制御方法。
要求装置から要求されたサービスをサービス実行装置が実行することにより発生したイベントの取得を要求するイベント要求装置であって、
前記要求装置がサービスの実行を要求するための入力中であるか、判断する判断手段と、
前記要求装置がサービスの実行を要求するための入力中であると判断した場合は、前記要求装置がサービスの実行を要求するための入力中でないと判断した場合よりも、イベントの取得を要求する間隔を短縮する短縮手段とを有することを特徴とするイベント要求装置。
サービスの実行を要求する要求装置からネットワークを介して要求されたサービスを実行し、サービスの実行により発生したイベントの取得を要求するイベント要求装置に前記ネットワークを介して要求されたイベントを通知するサービス実行装置であって、
前記要求装置がサービスの実行を要求するための入力中であるか、判断する判断手段と、
前記要求装置がサービスの実行を要求するための入力中であると判断した場合は、前記要求装置がサービスの実行を要求するための入力中でないと判断した場合よりも、前記イベント要求装置がイベントの取得を要求する間隔を短くするように、前記イベント要求装置に指示する指示手段とを有することを特徴とするサービス実行装置。
要求装置から要求されたサービスをサービス実行装置が実行することにより発生したイベントの取得を要求するコンピュータに、
前記要求装置がサービスの実行を要求するための入力中であるか判断する判断手順と、
前記要求装置がサービスの実行を要求するための入力中であると判断した場合は、前記要求装置がサービスの実行を要求するための入力中でないと判断した場合よりも、イベントの取得を要求する間隔を短縮する短縮手順とを実行させることを特徴とするプログラム。
サービスの実行を要求する要求装置からネットワークを介して要求されたサービスを実行し、サービスの実行により発生したイベントの取得を要求するイベント要求装置に前記ネットワークを介して要求されたイベントを通知するコンピュータに、
前記要求装置がサービスの実行を要求するための入力中であるか、判断する判断手順と、
前記要求装置がサービスの実行を要求するための入力中であると判断した場合は、前記要求装置がサービスの実行を要求するための入力中でないと判断した場合よりも、前記イベント要求装置がイベントの取得を要求する間隔を短くするように、前記イベント要求装置に指示する指示手順とを実行させることを特徴とするプログラム。