(57)【要約】      （修正有）【課題】サービスを実行した結果を効率よく利用する通信装置及びその処理方法を提供する。【解決手段】通信装置が他の装置からサービスの実行を要求するメッセージを受信し、受信されたメッセージのサービスを実行中に、他の装置とのコネクションが切断された場合、そのサービスを実行した結果をその情報と共に保存する。そして、受信されたメッセージにその保存された情報が付与されていた場合、その情報と共に保存された実行結果を他の装置へ送信する。【選択図】図２
2010277433.tif 000002
【特許請求の範囲】
【請求項１】
他の装置とネットワークを介してメッセージを送受信する通信装置であって、
前記他の装置からサービスの実行を要求するメッセージを受信する受信手段と、
前記受信されたメッセージのサービスを実行中に前記他の装置とのコネクションが切断された場合、当該サービスを実行した結果を前記メッセージを識別するための情報と共に保存する保存手段と、
前記受信手段により受信されたメッセージに前記保存手段に保存された前記情報が付与されていた場合、前記情報と共に保存された実行結果を前記他の装置へ送信する送信手段と、
を有することを特徴とする通信装置。
【請求項２】
前記送信手段は、前記情報と共に保存された実行結果を前記他の装置へ送信した場合には当該情報と実行結果とを削除することを特徴とする請求項１に記載の通信装置。
【請求項３】
前記保存手段は、前記情報と共に保存された実行結果の保存期間を管理し、特定の保存期間が過ぎた場合、その情報と実行結果とを削除することを特徴とする請求項１又は２に記載の通信装置。
【請求項４】
前記情報が付与されていないメッセージのサービスを実行中に前記他の装置とのコネクションが切断された場合は、当該サービスの実行を中断することを特徴とする請求項１に記載の通信装置。
【請求項５】
他の装置とネットワークを介してメッセージを送受信する通信装置の処理方法であって、
受信手段が、前記他の装置からサービスの実行を要求するメッセージを受信する受信工程と、
保存手段が、前記受信されたメッセージのサービスを実行中に前記他の装置とのコネクションが切断された場合、当該サービスを実行した結果を前記メッセージを識別するための情報と共に保存する保存工程と、
送信手段が、前記受信工程において受信されたメッセージに前記保存工程において保存された前記情報が付与されていた場合、前記情報と共に保存された実行結果を前記他の装置へ送信する送信工程と、
を有することを特徴とする通信装置の処理方法。
【請求項６】
コンピュータを請求項１乃至４の何れか１項に記載された通信装置の各手段として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、他の装置とネットワークを介してメッセージを送受信する通信装置及びその処理方法に関する。
【背景技術】
【０００２】
近年、ネットワークを介して複数の装置同士がデータのやり取りを行うWebサービス技術を用いたＰＣや機器の連携が一般的に行われている。サービスは、クライアントからのサービスの実行を要求するリクエストメッセージを受信し、サービスロジックを実行して、実行結果を含んだレスポンスメッセージをクライアントに送信する。サービスがリクエストメッセージを受信した後に、ネットワーク障害やタイムアウト、及び、クライアントのキャンセルにより、コネクションが切断された場合、サービス側では、サービスロジックの実行処理を途中で止められない。通常、サービスロジックの実行が終了し、レスポンスメッセージを書き出そうとして、コネクションの切断に気づき、処理を終了する。そのため、せっかく作成したレスポンスメッセージが無駄になってしまう。
そこで、先行技術には、ウェブ・サービス要求を受信したことに応答して、ウェブ・サービス・コントローラが制御し、サービスロジックを実行せずにキャッシュしたものを使用できるようにした特許がある（参考文献１参照）。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００７−２００３１１
【発明の概要】
【発明が解決しようとする課題】
【０００４】
特許文献１の場合、どのような場合でもキャッシュを使用するが、すべての情報をキャッシュしておくことは難しい。また、Webサービスのオペレーション呼び出しの場合、同じ呼び出しであっても、毎回同じ実行結果が返るとは限らない。例えば、申請書類などのファイルのダウンロードをするようなサービスの場合を考える。申請書類には、複数人が閲覧及び、承認印などの処理を加える。そのため、同じファイル名であっても、呼び出したタイミングによって、申請書類の情報が異なっている。つまり、一度呼び出したサービスの実行結果をキャッシュしておくことには何の意味もないのである。
【０００５】
また、まったくキャッシュしておくことができない場合もある。その場合、非常に処理が重いサービスロジックの実行処理は無駄となってしまう。そこで、キャッシュをしない場合でも、コネクションの切断時に、非常に処理が重いようなサービスロジックの実行処理を途中で中断できる仕組みが必要である。
【０００６】
本発明は、サービスを実行した結果を効率よく利用する通信装置及びその処理方法を提供する。
【課題を解決するための手段】
【０００７】
本発明は、他の装置とネットワークを介してメッセージを送受信する通信装置であって、
前記他の装置からサービスの実行を要求するメッセージを受信する受信手段と、
前記受信されたメッセージのサービスを実行中に前記他の装置とのコネクションが切断された場合、当該サービスを実行した結果を前記メッセージを識別するための情報と共に保存する保存手段と、
前記受信手段により受信されたメッセージに前記保存手段に保存された前記情報が付与されていた場合、前記情報と共に保存された実行結果を前記他の装置へ送信する送信手段と、
を有することを特徴とする。
【発明の効果】
【０００８】
本発明によれば、サービスを実行した結果を効率よく利用することができる。
【図面の簡単な説明】
【０００９】
【図１】本実施形態における通信装置のハードウェア構成の一例を示す図。
【図２】本実施形態における通信装置のソフトウェア構成の一例を示す図。
【図３】識別ＩＤが付与されていないリクエストメッセージの場合の処理を示す図。
【図４】識別ＩＤが付与されたリクエストメッセージの場合の処理を示す図。
【図５】識別ＩＤのみのリクエストメッセージの場合の処理を示す図。
【図６】データベースに保持される情報の一例を示す図。
【図７】本実施形態における通信装置の処理を示すフローチャート。
【図８】保存期間を過ぎたデータを削除する処理を示すフローチャート。
【発明を実施するための形態】
【００１０】
以下、図面を参照しながら発明を実施するための形態について詳細に説明する。まず、本実施形態における通信装置のハードウェア構成の一例を、図１を用いて説明する。尚、本実施形態では、通信装置として、他の装置からの、サービス要求に応じて、サービスを実行し、実行結果（応答）を他の装置へ返送するサービス装置を例に説明する。
【００１１】
図１において、他の装置１０１は、ネットワーク１１３を介してサービス装置（通信装置）１０２とメッセージを授受する、サービスを利用する側の装置（コンピュータ）である。サービス装置１０２は、ＣＰＵ１０３、メモリ１０４、ＨＤ（ハードディスク）装置１０５、表示ボード１０６、周辺コントローラ１０７、ネットワークＩ／Ｆ１０８を備える。ＣＰＵ１０３は、プログラムに従ってサービス装置１０２の各処理部の処理を実行する。プログラムはＨＤ装置１０５やメモリ１０４に格納されており、ＣＰＵ１０３がプログラムを実行時にＲＡＭに読み込まれる。メモリ１０４はプログラムや制御データを格納するＲＯＭとＣＰＵ１０３の作業領域としてのＲＡＭを含み、更にＸＭＬの要素やオブジェクトも格納される。また、プログラムはコンピュータを通信装置として機能させるためのものである。
【００１２】
ＨＤ装置１０５はハードディスクへのアクセスを制御するインタフェースを含み、各種データを記憶する。表示ボード１０６はディスプレイ装置１０９を接続するためのインタフェースを含み、サービス装置１０２の状態や処理結果をディスプレイ装置１０９に表示させる。周辺コントローラ１０７はマウス１１０やキーボード１１１を接続するためのインタフェースを含み、サービス装置１０２への指示や各種入力を制御する。ネットワークＩ／Ｆ１０８はネットワーク１１３との間で通信するためのインタフェースを含み、他の装置１０１との通信を制御する。
【００１３】
システムバス１１２は上述の各部を接続する。ネットワーク１１３は他の装置１０１とサービス装置１０２がメッセージを通信できればどのような形態でもよく、例えばインターネット、ＷＡＮ、ＬＡＮなどである。また、通信プロトコルも特定のプロトコルに限るものではない。
【００１４】
次に、サービス装置１０２のソフトウェア構成の一例を、図２を用いて説明する。他の装置１０１からサービスの実行を要求するメッセージとしてリクエストメッセージ２０１が送信されると、メッセージ受信部２０２がそのリクエストメッセージ２０１を受信する。ここで、他の装置１０１とサービス装置１０２とのコネクションが切断されていないか否かはコネクション切断検知部２０３が検知する。コネクションが切断されていなければ、メッセージ解析部２０４がそのリクエストメッセージ２０１を解析し、何のサービスの呼び出しかを判断する。また、メッセージ解析部２０４はリクエストメッセージ２０１に、メッセージを識別するための情報として識別ＩＤが含まれているか否かも判断する。
【００１５】
次に、メッセージ解析部２０４で呼び出すサービスが特定されると、サービスロジック制御部２０５がサービスロジック２０６の呼び出しを行う。また、コネクション切断検知部２０３が切断を検知した場合は、リクエストメッセージ２０１に識別ＩＤが付与されていない場合、サービスロジック２０６の処理を中断させる。サービスロジック２０６は、サービスロジック制御部２０５によってサービスの実行及び実行の中断が行われる。
【００１６】
サービスロジック制御部２０５によるサービスの実行が終了すると、メッセージ作成部２０７がサービスロジック２０６の実行結果に基づいて他の装置１０１に返信するレスポンスメッセージ２０９を作成する。そして、メッセージ送信部２０８が他の装置１０１にサービスの実行結果を表すメッセージとして、レスポンスメッセージ２０９を送信する。また、レスポンスメッセージ２０９は、サービスの実行に失敗した場合、失敗した情報を表すメッセージとなる。
【００１７】
他の装置１０１とのコネクションの切断により、メッセージを送信できなかった場合、未送信メッセージ管理部２１０がデータベース２１１に未送信のレスポンスメッセージを保持する。これは、他の装置１０１からのリクエストメッセージ２０１に識別ＩＤが付与されていた場合に行われ、識別ＩＤとレスポンスメッセージ２０９を紐付けて保持する。また、未送信メッセージ管理部２１０は再び、同じ識別ＩＤを持つリクエストメッセージ２０１が他の装置１０１から送信された場合、既に紐付けされたレスポンスメッセージをメッセージ送信部２０８に渡す。データベース２１１は、未送信メッセージ管理部２１０が情報を格納する格納先であり、ＨＤ装置１０５に含まれる。
【００１８】
次に、本実施形態におけるサービス装置の特徴的な処理を、図３乃至図８を用いて説明する。まず、識別ＩＤが付与されていないリクエストメッセージをやり取りする具体例を図３に示す。リクエストメッセージ３０１は、他の装置１０１がgetDataオペレーションを呼び出す際に送信される具体例である。リクエストメッセージ３０１には、識別ＩＤが付与されていない。サービス装置１０２では、このリクエストメッセージ３０１を受信し、具体的なサービスロジック３０２を実行する。そのサービスロジック３０２を実行した結果として、具体的なレスポンスメッセージ３０３が作成される。しかし、このサービスロジック３０２の処理を実行中にコネクションが切断された場合、リクエストメッセージ３０１に識別ＩＤが付与されていないため、サービスロジック３０２の実行を中断する。従って、この場合、レスポンスメッセージ３０３は作成されない。
【００１９】
次に、識別ＩＤが付与されたリクエストメッセージをやり取りする具体例を図４に示す。リクエストメッセージ４０１は、他の装置１０１がgetDataオペレーションを呼び出す際に送信される具体例である。リクエストメッセージ４０１には、識別ＩＤ「１０００２０」が付与されている。この識別ＩＤは初めてのアクセスであるため、データベース２１１には、紐付けされたレスポンスメッセージ３０３は存在しない。そのため、サービス装置１０２は、サービスロジック３０２の実行を行い、レスポンスメッセージ３０３の作成を行う。このサービスロジック３０２の実行結果として、具体的なレスポンスメッセージ３０３が作成される。ここで、サービスロジック３０２の処理を実行中にコネクションが切断された場合、このリクエストメッセージ４０１には識別ＩＤが付与されているため、サービスロジック３０２の実行を最後まで行う。そして、レスポンスメッセージ３０３を作成し、識別ＩＤ「１０００２０」と紐付けして保持しておく。再度、リクエストメッセージ４０１が他の装置１０１から送信されると、識別ＩＤ「１０００２０」に紐付けされたレスポンスメッセージ３０３が存在するため、サービスロジック３０２を実行せずに、そのメッセージを送信する。そして、識別ＩＤ「１０００２０」と紐付けされたレスポンスメッセージ３０３の情報をデータベース２１１から削除する。
【００２０】
また、サービスロジック３０２の処理を実行中にコネクションが切断されなかった場合は、サービスロジック３０２を実行して作成したレスポンスメッセージ３０３を他の装置１０１にそのまま送信する。
【００２１】
ここで、他の装置１０１から識別ＩＤのみが送信された場合に、装置間で送受信されるメッセージを図５に示す。識別ＩＤの情報だけをもつリクエストメッセージ５０１が送信される。サービス装置１０２では、送信された識別ＩＤ「１０００２０」に紐付けされたレスポンスメッセージが格納されているか否かを判断する。判断した結果、紐付けされたメッセージ３０３が存在すれば、図４と同様にそのメッセージを送信し、格納されているメッセージの情報をデータベース２１１から削除する。しかし、紐付けされたメッセージ３０３が存在しなかった場合、識別ＩＤのみで実行するサービスが不明なため、フォルトのメッセージを具体的なレスポンスメッセージ５０２として作成する。このサービス実行に失敗したことを表すレスポンスメッセージ５０２が他の装置１０１に送信される。
【００２２】
上述したサービス装置１０２におけるデータベース２１１が保持する情報の一例を図６に示す。図４に示すリクエストメッセージ４０１のサービスを実行処理中にコネクションが切断された場合、識別ＩＤ「１０００２０」がレスポンスメッセージと共に格納される（６０１）。この例では、識別ＩＤ「１００１２０」もレスポンスメッセージと共に格納されている（６０２）。また、この例では、他に、保存期間が記述してある。６０１では残り６０分となっており、６０２では残り１２０分となっている。これは、サービス装置１０２のデータベース２１１において、データを保存しておく期間を設けた例である。
【００２３】
他の装置１０１がサービスの実行要求を行った場合に、コネクションが切断される可能性は、二つある。一つは、ネットワーク障害やタイムアウトなどによる、他の装置１０１が意図していない切断である。この場合、他の装置１０１がリトライを行う可能性が高い。しかし、他の装置１０１が何らかの理由により、意図的に切断を行う場合もある。この場合、後で実行する可能性もあるが、実行を行わない場合もある。そのため、二度とリトライが発生しないようなメッセージが存在してしまう。二度とアクセスされないメッセージをいつまでもデータベースに保管しておくのは、よくないので、ある一定の保存期間を設けるのが望ましい。
【００２４】
この保存期間は、サービス装置１０２の作成者が自由に設定するか、他の装置１０１からのリクエストメッセージに情報として付与されても良い。この保存期間を過ぎたデータは削除するが、削除された後にその識別ＩＤでリクエストメッセージを送信してきた場合、図４に示すように、サービスのメッセージを含んでいれば、サービスロジックの実行が行われるので問題ない。但し、図５に示すように、識別ＩＤのみのリクエストメッセージの場合は、フォルトレスポンスメッセージが返ることになる。
【００２５】
次に、本実施形態におけるサービス装置１０２の処理を、図７に示すフローチャートを用いて説明する。メッセージ受信部２０２が他の装置１０１から送られてきたリクエストメッセージ２０１を受信する（Ｓ７０１）。次に、コネクション切断検知部２０３がコネクションが切断されていないかを常に監視する（Ｓ７０２）。切断を検知した場合には、すぐにメッセージ受信部２０２に知らせる。通知された情報は、その他の全ての処理部に伝えられる。
【００２６】
次に、メッセージ解析部２０４がリクエストメッセージ２０１に識別ＩＤが付与されているか否かを判定する（Ｓ７０３）。判定した結果、リクエストメッセージ２０１に識別ＩＤが付与されていなければ（Ｓ７０３でＮＯ）、呼び出すサービスを特定し（Ｓ７０４）、処理がサービスロジック制御部２０５へ移る。サービスロジック制御部２０５では、メッセージ解析部２０４が特定したサービスに基づいてサービスロジック２０６を実行する（Ｓ７０５）。リクエストメッセージ２０１が上述したgetDataオペレーションを呼び出すリクエストメッセージ３０１の場合は、サービスロジック３０２が実行される。
【００２７】
ここで、サービスロジック２０６の実行中に、コネクション切断検知部２０３がコネクションの切断を検知しなければ（Ｓ７０６でＮＯ）、メッセージ作成部２０７がサービスロジックの結果を含むレスポンスメッセージ２０９を作成する（Ｓ７０７）。次に、メッセージ送信部２０８が、作成されたレスポンスメッセージ２０９を他の装置１０１に送信し（Ｓ７０８）、この処理を終了する。
【００２８】
一方、コネクション切断検知部２０３がコネクションの切断を検知すると（Ｓ７０６でＹＥＳ）、サービスロジック制御部２０５はサービスロジック２０６の実行を中断し（Ｓ７０９）、この処理を終了する。このサービスロジックの中断方法については、いくつか方法が考えられる。例えば、スレッドを別にしてサービスロジックの実行を行っておき、中断を検知すると、スレッドを止める。或いは、サービスロジックにキャンセルメソッドを用意しておき、そのメソッドを呼び出すなどである。尚、中断方法は、どのように実装されていても構わない。
【００２９】
また、メッセージ解析部２０４が、上述のリクエストメッセージ４０１のように、識別ＩＤが付与されているリクエストメッセージであると判定すると（Ｓ７０３でＹＥＳ）、処理が未送信メッセージ管理部２１０へ移る。未送信メッセージ管理部２１０では、識別ＩＤ「１０００２０」に対応するレスポンスメッセージがデータベース２１１に存在するか否かを判定する（Ｓ７１０）。判定した結果、識別ＩＤ「１０００２０」が付与されたリクエストメッセージを初めて受信したのであれば、データベース２１１には存在しない（Ｓ７１０でＮＯ）。そこで、メッセージ解析部２０４がそのメッセージを解析し、何のサービスの呼び出しかを特定する（Ｓ７１１）。尚、リクエストメッセージ４０１の場合、サービス呼び出しの情報が含まれているので、何の呼び出しかを特定することが可能である（Ｓ７１１でＹＥＳ）。リクエストメッセージ４０１は、getDataオペレーションを呼び出すリクエストメッセージである。
【００３０】
次に、サービスロジック制御部２０５が、メッセージ解析部２０４が特定したサービスに基づいてサービスロジック２０６を実行する（Ｓ７１２）。この場合、上述したサービスロジック３０２が実行される。次に、メッセージ作成部２０７がサービスロジック２０６の結果を含むレスポンスメッセージ２０９を作成する（Ｓ７１３）。次に、コネクション切断検知部２０３がコネクションの切断を検知していなければ（Ｓ７１４でＮＯ）、メッセージ送信部２０８は、作成されたレスポンスメッセージ２０９を他の装置１０１に送信し（Ｓ７１５）、この処理を終了する。
【００３１】
一方、コネクション切断検知部２０３が、サービスロジックの実行中にコネクションの切断を検知していた場合（Ｓ７１４でＹＥＳ）、未送信メッセージ管理部２１０に処理が移る。未送信メッセージ管理部２１０がデータベース２１１に識別ＩＤ「１０００２０」と作成したレスポンスメッセージ３０３を紐付けて６０１のように保存し（Ｓ７１６）、この処理を終了する。
【００３２】
また、上述したＳ７１０で、未送信メッセージ管理部２１０が、データベース２１１に識別ＩＤ「１０００２０」に対応するレスポンスメッセージが存在すると判定した場合、処理がメッセージ送信部２０８へ移る。ここで、メッセージ送信部２０８は、その紐付けされたレスポンスメッセージを他の装置１０１に送信する（Ｓ７１７）。そして、データベース２１１から送信が終了したレスポンスメッセージに対応する情報（６０１）を削除し（Ｓ７１８）、この処理を終了する。
【００３３】
また、上述したＳ７１１で、メッセージ解析部２０４がリクエストメッセージ２０１を解析し、何の呼び出しかを特定できない場合は、処理がメッセージ作成部２０７へ移る。具体的には、データベース２１１の保存期間が切れてデータが削除されていた場合、そもそも識別ＩＤがでたらめだった場合、識別ＩＤに対応するレスポンスメッセージが存在しない場合などが特定できない場合である。これらの場合、メッセージ作成部２０７では、フォルト情報を含むレスポンスメッセージを作成する（Ｓ７１９）。具体的には、図５に示すレスポンスメッセージ５０２が作成される。
【００３４】
次に、コネクション切断検知部２０３がコネクションの切断を検知していなければ（Ｓ７２０でＮＯ）、メッセージ送信部２０８が、作成されたレスポンスメッセージ５０２を他の装置１０１に送信し（Ｓ７１５）、この処理を終了する。しかし、コネクション切断検知部２０３がコネクションの切断を検知していれば（Ｓ７２０でＹＥＳ）、そのまま、この処理を終了する。また、作成したフォルトのメッセージはデータベース２１１に保存しない。
【００３５】
ここで、サービス装置１０２の未送信メッセージ管理部２１０がデータベース２１１の保存期間を過ぎたデータを削除する処理を、図８に示すフローチャートを用いて説明する。例えば、データベース２１１の保存期間が残り０分になっていた場合、そのデータは、データベース２１１から削除される。削除するタイミングとして、この例では、他の装置１０１からリクエストメッセージ２０１を受信した場合とする。また、この処理は、他の装置１０１からリクエストメッセージ２０１を受信した場合に、削除するデータがあるか否かを確認するので、Ｓ７０１とＳ７０２の処理の間で行われる。
【００３６】
まず、メッセージ受信部２０２がリクエストメッセージ２０１を受信し（Ｓ７０１）、未送信メッセージ管理部２１０がデータベース２１１に保存期間が過ぎたデータが存在するか否かを調べる（Ｓ８０１）。ここで、保存期間を過ぎたデータが存在しない場合（Ｓ８０１でＮＯ）は、そのまま、処理がコネクション切断検知部２０３へ移る。一方、保存期間が残り０分になっていた場合など、保存期間を過ぎたデータが存在すれば（Ｓ８０１でＹＥＳ）、そのデータを削除する（Ｓ８０２）。そして、処理がコネクション切断検知部２０３へ移る。
【００３７】
尚、データを削除するタイミングは、これだけに限らず、他の場合でも良い。例えば、メッセージ送信部２０８がレスポンスメッセージ２０９を送信した後、削除しても良い。また、処理のタイミングではなく、データベース２１１を常に監視し、保存期間が過ぎたデータを即座に検知して削除するようにしても良い。
【００３８】
以上のように、サービス装置１０２におけるこの処理を利用して、サービスを利用する他の装置１０１が効率的にデータを取得することも可能となる。例えば、他の装置１０１は識別ＩＤを付与したリクエストメッセージ４０１をサービス装置１０２に送信する。サービス装置１０２で実行されるサービスロジック３０２が、非常に重い処理であることがわかっていれば、他の装置１０１は意図的にコネクションを切断する。そして、しばらく経ってから、再び、リクエストメッセージ４０１をサービス装置１０２に送信する。これにより、サービス装置１０２では、既にサービスロジック３０２の実行が終了しており、レスポンスメッセージ３０３がデータベース２１１に保存されている。従って、他の装置１０１に対して、すぐにレスポンスメッセージが送信される。
【００３９】
このようにすることで、他の装置１０１は、サービス装置１０２からのレスポンスメッセージを取得するために、ずっとコネクションを維持しておく必要がない。サービス装置１０２が処理を行っている間に、他の処理をすることも可能であり、コネクションを長くキープしてタイムアウトが発生してしまうという問題も解消される。
【００４０】
本実施形態によれば、サービスにおいて、サービスロジックの実行を必要最低限に抑えることができ、メモリが少ない組込み機器での負荷を軽減することが可能となる。
【図１】
2010277433.tif 000003
【図２】
2010277433.tif 000004
【図３】
2010277433.tif 000005
【図４】
2010277433.tif 000006
【図５】
2010277433.tif 000007
【図６】
2010277433.tif 000008
【図７】
2010277433.tif 000009
【図８】
2010277433.tif 000010