JP4727954B2 - クライアントサーバ型分散システムで用いられる方法、サーバ、およびクライアント - Google Patents

Description

本発明は、同期通信するクライアントサーバ型分散システムで用いられる方法、サーバ、およびクライアントに関し、より特定的には、クライアントがサーバに対してサーバ機能の呼び出しを開始した時点から、サーバ機能が終了したことの通知が戻るまでのターンアラウンド時間の短縮化を図る方法、サーバ、およびクライアントに関する。

コンピュータなどの情報処理端末を用いたクライアントサーバ型分散システムに関する従来の同期通信において、クライアントは、サーバに対して、サーバ機能を呼び出す。サーバは、呼び出されたサーバ機能の処理を実行し、処理が終了したら、クライアントに終了した旨を返す。

図１３は、このような従来の同期通信方法におけるサーバとクライアントとの処理の流れを示すシーケンス図である。図１３において、クライアントで処理動作が可能となるタイミングは、斜線で表されている。クライアントは、サーバに対してサーバ機能を呼び出す。クライアントは、サーバからサーバ機能の実行が完了した旨の通知があるまでは、処理を行うことができない。このように、クライアントがサーバ機能を呼び出してからサーバ機能の完了が通知されるまでの時間をターンアラウンド時間という。ターンアラウンド時間の間は、クライアントは処理を行うことができないので、ターンアラウンド時間を短縮する技術、つまり、クライアントでの待機状態を短縮する技術が提案されている（たとえば、特許文献１参照）。

図１４は、特許文献１に記載されている従来の同期通信方法の流れを示すシーケンス図である。図１４において、クライアントは、クライアント側の処理を実行してサーバ機能を呼び出すためのクライアント指令部と、サーバとの間の通信を行う通信制御部とから構成される。クライアント指令部は、サーバ機能を呼び出す必要が生じた場合、通信制御部に対して、サーバ機能の呼び出しを要求する。それに応じて、通信制御部は、即時に、サーバ機能の呼び出しに失敗した旨の完了通知をクライアント指令部に返す。それと当時に、通信制御部は、サーバに対して、サーバ機能の実行を要求するための要求メッセージを非同期通信で送信する。当該要求メッセージを受信したサーバは、要求されたサーバ機能の処理を実行する。サーバは、サーバ機能の処理が終了したら、クライアントに対して、終了メッセージを送信する。クライアントの通信制御部は、サーバから送信された終了メッセージの内容を保持する。通信制御部は、クライアント指令部から再度サーバ機能の呼び出しが要求されると、保持している終了メッセージの内容に基づいて、クライアント指令部に対してサーバ機能の完了を通知する。

このように、特許文献１に記載の同期通信方法を用いれば、クライアントのターンアラウンド時間の短縮化を図ることができる。
特開平９−３３０２８７号公報

しかし、上記従来の同期通信方法において、通信制御部は、クライアント指令部に対して、サーバ機能の実行に失敗した旨の完了通知を即時に返すので、クライアントにおけるターンアラウンド時間は短縮されるものの、サーバ機能の完了通知がクライアント指令部に返された時点では、実際のサーバ機能の呼び出しは行われていない。従って、クライアント指令部によって、最低でも２回のサーバ機能の呼び出しが行われないと、サーバ機能の呼び出しの処理結果が確認できないという問題があった。

また、サーバ機能の処理が完了するタイミングが不明であるため、クライアントは、サーバからの終了メッセージを受信する前に、２回目のサーバ機能の呼び出しを実行する可能性があり、不要な処理が発生するという問題があった。

それゆえ、本発明の目的は、サーバ機能の処理がサーバによって実行される場合、クライアントによってサーバ機能の呼び出しが複数回行われることなく、サーバ機能の呼び出しを開始した時点からサーバ機能が終了した旨の通知を受けるまでのターンアラウンド期間を短縮することができるクライアントサーバ型システムの同期通信方法、サーバ、およびクライアントを提供することである。

上記課題を解決するために、本発明は、以下のような特徴を有する。本発明は、クライアントがサーバに対して所望のサーバ機能を呼び出し、呼び出されたサーバ機能に対応する処理をサーバが実行するクライアントサーバ型分散システムにおいて用いられる方法であって、サーバ機能に対応する処理の一部であって、クライアントが必要とする最低限の情報を得るまでの処理を前処理として登録するステップと、サーバ機能に対応する処理の一部であって、前処理の後に実行すべき処理を後処理として登録するステップと、登録されている前処理と、登録されている後処理と、サーバ機能を示すサーバ機能識別子とを対応付けるステップとを備える。

これにより、サーバ機能に対応する処理が前処理と後処理とに分けられることとなる。

好ましくは、さらに、クライアントが、所望のサーバ機能の呼び出しを要求するために、当該所望のサーバ機能を示すサーバ機能識別子が含まれる要求メッセージをサーバに対して送信するステップと、サーバがクライアントから送信されてくる要求メッセージを受信するステップと、要求メッセージに含まれるサーバ機能識別子に対応付けられた前処理をサーバが実行するステップと、前処理の実行結果をサーバが得るステップと、得られた前処理の実行結果が含まれる終了メッセージをサーバがクライアントに対して送信するステップと、終了メッセージの送信後に、要求メッセージに含まれるサーバ機能識別子に対応付けられた後処理をサーバが実行するステップと、終了メッセージを受信したクライアントが前処理の実行結果に基づいた処理を実行するステップとを備えるとよい。

これにより、前処理が実行されたタイミングで、クライアントに対して終了メッセージが返されることとなる。前処理によって、クライアントにおいて最低限必要な情報が得られるので、クライアントは、当該終了メッセージを受信した後、処理を継続することができる。したがって、ターンアラウンド時間が短縮されることになる。また、サーバは、前処理の後、後処理を実行することとなるので、所望のサーバ機能が呼び出されたこととなる。

好ましくは、さらに、サーバが後処理の実行結果を得るステップと、後処理の実行結果が含まれる後処理結果メッセージをクライアントにサーバが送信するステップと、後処理結果メッセージを受信したクライアントが後処理の実行結果に基づいた処理を実行するステップとを備えるとよい。

これにより、後処理の実行結果がクライアントに通知されることとなるので、クライアントは、後処理の実行結果に基づいて、所望の処理を実行することができる。

好ましくは、さらに、サーバ機能の呼び出しを取り消すためのキャンセル指示があった場合、クライアントが、当該キャンセル指示に基づいて、サーバ機能の呼び出しを取り消すか否かを判定するための条件を予め登録しておくステップと、キャンセル指示があった場合、当該キャンセル指示に従ってサーバ機能の呼び出しを取り消すか否かをクライアントが判定するステップと、取り消すと判定した場合、サーバ機能の呼び出しをクライアントが取り消すステップとを備えるとよい。

これにより、サーバ機能の呼び出しを取り消すことができるので、不要なサーバ機能の呼び出しを行った場合などのターンアラウンド時間を短縮することができる。

また、本発明は、クライアントから呼び出されたサーバ機能を実行するためのサーバであって、サーバ機能に対応する処理の一部であって、クライアントが必要とする最低限の情報を得るまでの処理を前処理として登録する前処理登録部と、サーバ機能に対応する処理の一部であって、前処理の後に実行すべき処理を後処理として登録する後処理登録部と、登録されている前処理と、登録されている後処理と、サーバ機能を示すサーバ機能識別子とを対応付けるサーバ機能対応付け部とを備える。

好ましくは、さらに、クライアントが所望するサーバ機能を示すサーバ機能識別子が含まれる要求メッセージをクライアントから受信する受信部と、要求メッセージに含まれるサーバ機能識別子に対応付けられた前処理を実行して、実行結果を出力する前処理実行部と、前処理実行部が出力した前処理の実行結果が含まれる終了メッセージをクライアントに対して送信する送信部と、終了メッセージの送信後に、要求メッセージに含まれるサーバ機能識別子に対応付けられた後処理を実行する後処理実行部とを備えるとよい。

好ましくは、後処理実行部は、後処理の実行結果を出力し、送信部は、後処理実行部が出力した後処理の実行結果が含まれる後処理結果メッセージをクライアントに送信するとよい。

また、本発明は、サーバに対して、所望のサーバ機能を呼び出すためのクライアントであって、所望のサーバ機能の呼び出しを要求するために、当該所望のサーバ機能を示すサーバ機能識別子が含まれる要求メッセージをサーバに対して送信する送信部と、要求メッセージに含まれるサーバ機能識別子に対応付けられた前処理のサーバによる実行結果が含まれる終了メッセージをサーバから受信する受信部と、受信部が受信した前処理の実行結果に基づいた処理を実行する制御部とを備え、サーバ機能を示すサーバ機能識別子には、当該サーバ機能に対応する処理の一部であって、クライアントが必要とする最低限の情報を得るまでの処理が前処理として対応付けられており、さらに、サーバ機能に対応する処理の一部であって、前処理の後に実行すべき処理が後処理として対応付けられている。

好ましくは、サーバは、後処理の実行結果が含まれる後処理結果メッセージをクライアントに対して送信し、受信部は、サーバから送信される後処理結果メッセージを受信し、制御部は、受信した後処理結果メッセージに含まれる後処理の実行結果に基づいた処理を実行するとよい。

好ましくは、さらに、サーバ機能の呼び出しを取り消すためのキャンセル指示があった場合、当該キャンセル指示に基づいて、サーバ機能の呼び出しを取り消すか否かを判定するための条件を予め登録しておく取消条件登録部を備え、制御部は、キャンセル指示があった場合、取消条件登録部に登録されている条件に基づいて、サーバ機能の呼び出しを取り消すか否かを判定し、取り消すと判定した場合、サーバ機能の呼び出しを取り消すとよい。

このように、本発明によれば、サーバ機能に対応する処理が前処理と後処理とに分けられることとなり、前処理が実行されたタイミングで、クライアントに対して終了メッセージが返されることとなる。前処理によって、クライアントにおいて最低限必要な情報が得られるので、クライアントは、当該終了メッセージを受信した後、処理を継続することができる。したがって、ターンアラウンド時間が短縮されることになる。また、サーバは、前処理の後、後処理を実行することとなるので、所望のサーバ機能が呼び出されたこととなる。

以下、本発明の実施形態について、図面を参照しながら説明する。

（第１の実施形態）
図１は、本発明の第１の実施形態に係るクライアントサーバ型システムの構成の一例を示すブロック図である。

図１において、クライアントサーバ型システムは、クライアント１０ａと、サーバ１０ｂとを備える。クライアント１０ａとサーバ１０ｂとは、通信可能である。ここでは、クライアント１０ａがサーバ１０ｂに対して、サーバ１０ｂ上で処理実行するサーバ機能の呼び出しを同期通信で行うクライアントサーバ型システムを示している。

なお、クライアント１０ａとサーバ１０ｂとが別々の装置であるとした場合、クライアント１０ａとサーバ１０ｂとは、たとえば、ブルートゥースや無線ＬＡＮ、赤外線などの無線による無線通信、もしくはＩＳＤＮや、ＡＤＳＬ、シリアルケーブル、パラレルケーブルなどの有線通信によって、相互に通信する。また、クライアント１０ａとサーバ１０ｂとを同一デバイス内に設けた場合、クライアント１０ａとサーバ１０ｂとは、プロセスや、タスク、スレッド上で通信を行う。なお、図１において、クライアント１０ａおよびサーバ１０ｂは、一つずつであるとしたが、クライアント１０ａが複数あってもよいし、サーバ１０ｂが複数あってもよい。

クライアント１０ａは、クライアント指令部１０４と、通信制御部１１２とを含む。クライアント指令部１０４は、クライアント側の処理を実行し、当該処理に応じて、サーバ機能の呼び出しを行う。通信制御部１１２は、クライアント指令部１０４とサーバ１０ｂとの間の通信を制御する。

通信制御部１１２は、同期通信部１０５と、非同期通信送信部１０６と、非同期通信受信部１１１とを有する。同期通信部１０５は、クライアント指令部１０４からのサーバ機能の呼び出しを同期通信で受け付け、非同期通信送信部１０６にサーバ機能の呼び出し要求を通知する。また、同期通信部１０５は、非同期通信受信部１１１から送られてくるサーバからの終了メッセージを受信し、クライアント指令部１０４にサーバ機能の終了を通知する。非同期通信送信部１０６は、同期通信部１０５からの呼び出し要求を受け取り、サーバに対して要求メッセージを非同期通信で送信する。非同期通信受信部１１１は、サーバからの終了メッセージを受信し、同期通信部１０５に完了を通知する。

サーバ１０ｂは、サーバ指令部１００と、前処理登録部１０１と、後処理登録部１０２と、サーバ機能対応付け部１０３と、非同期通信受信部１０７と、前処理実行部１０８と、非同期通信送信部１０９と、後処理実行部１１０とを含む。

前処理登録部１０１は、前処理を登録する。ここで、前処理とは、クライアント１０ａから呼び出されたサーバ機能に対応する処理の一部であって、クライアント１０ａが必要とする最低限の情報を得るまでの処理のことをいう。サーバ１０ｂは、前処理による実行結果を前処理以後の処理（後述の後処理）を実行する前に、クライアント１０ａに送信する。

後処理登録部１０２は、後処理を登録する。ここで、後処理とは、クライアント１０ａから呼び出されたサーバ機能に対応する処理の一部であって、前処理による実行結果をサーバ１０ｂがクライアント１０ａに送信した後に実行すべき処理、すなわち、サーバ機能に対応する処理から前処理を除いた処理のことをいう。

前処理および後処理の例については、後述の実施例で説明する。

サーバ指令部１００は、サーバの操作者の指示に応じて、前処理または後処理の登録を前処理登録部１０１または後処理登録部１０２に要求する。なお、サーバ指令部１００は、接続されるクライアントからの指示に応じて、前処理および後処理の登録を前処理登録部１０１および後処理登録部１０２に要求してもよいし、サーバ１０ｂ上で実行されているアプリケーションからの指示に応じて、前処理および後処理の登録を前処理登録部１０１および後処理登録部１０２に要求してもよい。

サーバ機能対応付け部１０３は、前処理登録部１０１および後処理登録部１０２からの指示に応じて、サーバ機能、前処理、および後処理を対応付けたテーブルを作成して保持する。図２は、サーバ機能対応付け部１０３に保持されているサーバ機能、前処理、および後処理を対応付けたテーブルの一例を示す図である。図２に示すように、サーバ機能対応付け部１０３は、サーバ機能を表す識別子（以下、サーバ機能識別子という）に対応する前処理および後処理をテーブルとして登録している。図２に示す例では、サーバ機能Ａの前処理として前処理１が登録され、サーバ機能Ａの後処理として後処理２が登録されている。また、サーバ機能Ｂの前処理として前処理２が登録され、サーバ機能Ｂの後処理として後処理１が登録されている。さらに、サーバ機能Ｃの前処理として前処理３が登録されている。このようなテーブルがサーバ機能対応付け部１０３に登録されている場合、たとえば、サーバ機能Ａがクライアント１０ａから要求された場合、サーバ１０ｂは、前処理１を実行した後、その実行結果をクライアント１０ａに送信し、その後、後処理２を実行する。

非同期通信受信部１０７は、サーバ機能の呼び出しの要求メッセージをクライアント１０ａから受信して、サーバ機能対応付け部１０３に渡す。サーバ機能対応付け部１０３は、前処理実行部１０８に対して、前処理の実行を要求する。前処理実行部１０８は、サーバ機能対応付け部１０３からの要求に応じて、前処理を実行し、その実行結果をサーバ機能対応付け部１０３に返す。サーバ機能対応付け部１０３は、前処理実行部１０８から返ってくる前処理の実行結果に基づいて終了メッセージを作成し非同期通信送信部１０９に渡す。非同期通信送信部１０９は、前処理の実行結果に基づく終了メッセージを、非同期通信でクライアント１０ａに送信する。サーバ機能対応付け部１０３は、前処理の実行結果に基づく終了メッセージを非同期通信送信部１０９に渡した後、呼び出しがあったサーバ機能に対応する後処理を後処理実行部１１０に実行させる。後処理実行部１１０は、サーバ機能対応付け部１０３からの要求に応じて、後処理を実行する。

図３は、第１の実施形態に係るクライアントサーバ型システムにおけるサーバ１０ｂとクライアント１０ａとの間の処理の概要を説明するためのシーケンス図である。以下、図３を参照しながら、第１の実施形態に係るクライアントサーバ型システムにおけるサーバ１０ｂとクライアント１０ａとの間の処理の概要を説明する。

クライアント１０ａにおいて、クライアント指令部１０４がサーバ機能の呼び出しを要求した場合、通信制御部１１２は、サーバ１０ｂに対してサーバ機能を呼び出す旨の要求メッセージを非同期通信で送信する。

当該要求メッセージを受信したサーバ１０ｂは、要求されたサーバ機能に対応する前処理のみを実行し、前処理が終了したら、クライアント１０ａに対して、終了メッセージを送信して、前処理の実行結果を通知する。その後、サーバ１０ｂは、後処理を実行する。

クライアント１０ａの通信制御部１１２は、サーバ１０ｂからの終了メッセージを受信すると、クライアント指令部１０４にサーバ機能の呼び出しが完了した旨を通知する。これによって、クライアント指令部１０４は、前処理の実行結果を受け取ることができる。

図４は、本発明の第１の実施形態に係るクライアントサーバ型システム全体の動作の詳細を示すフローチャートである。以下、図４を参照しながら、第１の実施形態に係るクライアントサーバ型システム全体の動作の詳細について説明する。図４において、ステップＳ２０１〜Ｓ２０３は、サーバ１０ｂの動作を示す。ステップＳ２０４〜Ｓ２０５は、クライアント１０ａの動作を示す。ステップＳ２０６〜Ｓ２１０は、サーバ１０ｂの動作を示す。ステップＳ２１１〜Ｓ２１２は、クライアント１０ａの動作を示す。

まず、サーバ１０ｂの前処理登録部１０１は、サーバ指令部１００からの前処理登録要求を受け付け、登録処理を行う（ステップＳ２０１）。次に、後処理登録部１０２は、サーバ指令部１００からの後処理登録要求を受け付け、登録処理を行う（ステップＳ２０２）。なお、ここでは、ステップＳ２０１およびステップＳ２０２の各登録要求はサーバ指令部１００によって行われることとしたが、クライアント１０ａのクライアント指令部１０４からの登録要求をサーバ１０ｂが受け取り、当該登録要求が前処理登録部１０１および後処理登録部１０２に通知されることよって、登録処理が行われてもよい。なお、ステップＳ２０１およびステップＳ２０２が行われるタイミングは、サーバの操作者からの指示があったときでもよいし、接続されるクライアントからの指示があったときでもよいし、サーバ１０ｂ上で実行されているアプリケーションからの指示があったときでもよい。

次に、サーバ機能対応付け部１０３は、登録された前処理および後処理を、サーバ機能識別子と対応付けて保存する（ステップＳ２０３）。なお、ここでは、サーバ機能対応付け部１０３は、前処理および後処理の登録後に、まとめてサーバ機能識別子との対応付けを行うとしたが、ステップＳ２０１およびステップＳ２０２の各処理登録の時点で、サーバ機能識別子との対応付けを行ってもよい。

クライアント１０ａのクライアント指令部１０４によって特定のサーバ機能の呼び出し要求があった場合、同期通信部１０５は、当該呼び出し要求を同期通信で受け付ける（ステップＳ２０４）。このサーバ機能の呼び出し要求には、要求するサーバ機能のサーバ機能識別子、送信元情報、送信先情報、前処理実行時に必要なデータ、後処理実行時に必要なデータ等、サーバ機能の呼び出しに必要な情報と非同期通信により同期通信を実現するために必要な宛先情報とが含まれている。

次に、サーバ機能の呼び出し要求を受信した同期通信部１０５は、サーバ機能を呼び出すための要求メッセージを、非同期通信送信部１０６に非同期通信でサーバ１０ｂ宛に送信させる（ステップＳ２０５）。

次に、サーバ１０ｂの非同期通信受信部１０７は、クライアント１０ａからの要求メッセージを受信する（ステップＳ２０６）。

次に、サーバ機能対応付け部１０３は、保持しているテーブルを参照して、受信した要求メッセージに含まれるサーバ機能識別子に対応する前処理を決定し、前処理実行部１０８に、当該対応付けられた前処理を実行させる（ステップＳ２０７）。なお、ステップＳ２０７において、ステップＳ２０６で受信した要求メッセージの中に前処理実行時に必要なデータが含まれていれば、前処理実行部１０８は、当該データを用いて前処理を実行する。

次に、前処理実行部１０８は、ステップＳ２０７で実行した前処理の実行結果をサーバ機能対応付け部１０３に出力する（ステップＳ２０８）。

次に、サーバ機能対応付け部１０３は、前処理実行部１０８から得た実行結果を非同期通信送信部１０９に渡し、当該実行結果を含む終了メッセージを非同期通信送信部１０９に作成させ、クライアント１０ａに対して非同期通信で終了メッセージを送信させる（ステップＳ２０９）。終了メッセージには、前処理の実行結果の他、送信元情報、送信先情報など、サーバ機能要求が完了したことを告げるために必要な情報が含まれている。なお、送信先となるクライアント１０ａの宛先は、要求メッセージに含まれている送信元情報に基づいて決定される。

ステップＳ２０９で終了メッセージを送信させた後、サーバ機能対応付け部１０３は、サーバ機能識別子に対応する後処理を決定し、当該後処理を後処理実行部１１０に実行させる（ステップＳ２１０）。なお、ステップＳ２１０において、ステップＳ２０６で受信した要求メッセージの中に後処理実行時に必要なデータが含まれていれば、後処理実行部１１０は、当該データを用いて後処理を実行する。

一方、クライアント１０ａにおいて、非同期通信受信部１１１は、サーバ１０ｂからの終了メッセージを受信し、同期通信部１０５に通知する（ステップＳ２１１）。

それに応じて、同期通信部１０５は、クライアント指令部１０４に対して、サーバ機能の呼び出しが完了した旨を通知する（ステップＳ２１２）。なお、当該完了通知には、終了メッセージに含まれている前処理の実行結果が含まれている。この通知を受信したクライアント指令部１０４は、所望の処理を継続する。

このように、第１の実施形態によれば、サーバ１０ｂは、サーバ機能に対応する処理を前処理と後処理とに分割して登録し、クライアント１０ａからサーバ機能の実行が要求された場合、当該サーバ機能に対応する前処理を実行し、前処理の実行が終了したら、終了メッセージをクライアント１０ａに送信する。したがって、サーバ機能に対応する全ての処理（すなわち、前処理および後処理）が実行される前に、クライアント１０ａは、終了メッセージを受信して、所望の処理を実行することができるので、サーバ機能に対応する処理が全て実行された後に終了メッセージがクライアント１０ａに送信され所望の処理が実行される場合に比べて、ターンアラウンド時間は短縮されることとなる。また、クライアント１０ａは、サーバ機能の呼び出しを一回だけ行うだけで、サーバ機能に対応する最低限必要な処理が完了する時点を認識することができるので、サーバ機能の呼び出しを複数回行わなくてもよい。

なお、図４に示したフローチャートでは、前処理の登録（ステップＳ２０１）、後処理の登録（ステップＳ２０２）、および対応付けの処理（ステップＳ２０３）は、ステップＳ２０４以降の処理と一連に行われるように記載した。しかし、これらの処理は、典型的には、ステップＳ２０４以降の処理とは独立して、予め行われる。

なお、第１の実施形態において、クライアント１０ａからの要求メッセージをサーバ１０ｂが受信するステップＳ２０６の時点において、前処理を登録するステップＳ２０１が予め行なわれていない場合、サーバ１０ｂは、前処理を実行するステップＳ２０７および前処理の実行結果を出力するステップＳ２０８を行わずに、ステップＳ２０９で前処理の実行結果を含まない終了メッセージを送信すればよい。

なお、第１の実施形態において、たとえば、図２に示すサーバ機能Ｃのように、クライアント１０ａからの要求メッセージを受信するステップＳ２０６の時点で、後処理を登録するステップＳ２０２が予め行なわれていない場合、サーバ１０ｂは、後処理を実行するステップＳ２０８を行わない。つまり、ステップＳ２０１に示す前処理の登録、およびステップＳ２０２における後処理の登録が、両方行われることは必須ではない。

（第１の実施形態の変形例）
なお、上記第１の実施形態では、後処理実行部１１０における後処理の実行が終了した後の動作については、特に規定しなかった。しかし、第１の実施形態の変形例として、サーバ１０ｂは、後処理の実行結果をクライアント１０ａに伝えるようにしてもよい。

図５は、後処理の実行結果も得ることができるクライアントサーバ型システム全体の動作の詳細を示すフローチャートである。以下、図５を参照しながら、後処理の実行結果も得ることができるクライアントサーバ型システム全体の動作の詳細について説明する。なお、図５において、図４に示したクライアントサーバ型システム全体の動作と同様の動作を示すステップについては、同一のステップ番号を付し、説明を省略することとする。図５において、ステップＳ４０１〜Ｓ４０２は、サーバ１０ｂの動作を示す。すなわち、サーバ１０ｂは、ステップＳ２１０を実行した後、ステップＳ４０１〜Ｓ４０２を実行する。ステップＳ４０３〜Ｓ４０４は、クライアント１０ａの動作を示す。

ステップＳ２１０での後処理の実行を終えたサーバ１０ｂの後処理実行部１１０は、後処理の実行結果をサーバ機能対応付け部１０３に出力する（ステップＳ４０１）。

次に、サーバ機能対応付け部１０３は、非同期通信送信部１０９に対して、後処理の実行結果を渡し、当該実行結果を含む後処理結果メッセージを作成させて、クライアント１０ａに非同期通信で当該後処理結果メッセージを送信させる（ステップＳ４０２）。後処理結果メッセージには、後処理実行結果の他、送信元情報、送信先情報など、サーバ機能呼び出しに対するサーバでの全ての処理が完了したことを告げるために必要な情報が含まれている。なお、送信先となるクライアント１０ａの宛先は、要求メッセージに含まれる送信元情報に基づいて決定される。

次に、クライアント１０ａの非同期通信受信部１１１は、サーバ１０ｂからの後処理結果メッセージを受信する（ステップＳ４０３）。

次に、同期通信部１０５は、クライアント指令部１０４に対して、受信した後処理結果メッセージに含まれる後処理実行結果を通知し、サーバ機能呼び出しに対するサーバでの全ての処理が完了した旨を通知する（ステップＳ４０４）。これに応じて、クライアント指令部１０４は、後処理実行結果に基づいて、所望の処理を継続する。

これにより、クライアントは、後処理の実行結果を取得することができ、サーバ機能の呼び出しに対するサーバでの全ての処理が完了したことを知ることができる。

（第２の実施形態）
本発明の第２の実施形態では、第１の実施形態に示す機能に加え、クライアントは、終了メッセージのみでなく、サーバ機能の呼び出しが取り消されたこと示すキャンセルメッセージを処理できるようにする。キャンセルメッセージを受信したクライアントは、サーバ機能の呼び出しを取り消す。以下、第２の実施形態について、図面を参照しながら説明する。

図６は、本発明の第２の実施形態に係るクライアントサーバ型システムの全体構成の一例を示すブロック図である。図６において、図１に示す構成要素と同様の機能を有する構成要素については、同一の参照符号を付し、説明を省略する。

図６において、第２の実施形態に係るクライアント１０ｃは、クライアント指令部１０４ｃと、通信制御部５０２とを含む。通信制御部５０２は、同期通信部１０５ｃと、非同期通信送信部１０６と、非同期通信受信部１１１ｃと、取消条件登録部５０１とを有する。

取消条件登録部５０１は、キャンセルメッセージに含まれる情報に基づいて、サーバ機能呼び出しを取り消すか否かを判定する条件を登録する。

図７は、第２の実施形態に係るクライアントサーバ型システム全体の動作を示すフローチャートである。以下、図７を参照しながら、クライアントによる終了メッセージ待ちの状態を取り消す動作について説明する。なお、図７において、図４に示す動作と同様の動作については、同一のステップ番号を付し、説明を省略する。

クライアント指令部１０４ｃは、クライアント１０ｃがキャンセルメッセージを受信したときに当該キャンセルメッセージに基づいてサーバ機能の呼び出しを取り消すか否かを判定するための条件を、取消条件登録部５０１に予め登録する（ステップＳ６０１）。なお、ステップＳ６０１の動作は、ステップＳ２０１、Ｓ２０２、Ｓ２０３、Ｓ２０４の動作の前後のどのタイミングで行ってもよいし、これらの動作とは全く独立して予め行われてもよい。

ステップＳ６０２において、クライアント１０ｃの非同期通信受信部１１１ｃは、サーバ１０ｂからの終了メッセージ、またはキャンセルメッセージを受信する。なお、ステップＳ６０２において非同期通信受信部１１１ｃが受信するメッセージは、サーバ１０ｂがステップＳ２０９で送信した終了メッセージ、クライアント指令部１０４ｃが送信したキャンセルメッセージ、また、別のクライアント５０ａが送信したキャンセルメッセージのいずれかである。

次に、非同期通信受信部１１１ｃは、ステップＳ６０２で受信したメッセージがキャンセルメッセージであるかそれとも終了メッセージであるかを判別する（ステップＳ６０３）。終了メッセージである場合、クライアント１０ｃは、ステップＳ２１２の動作に進む。

一方、キャンセルメッセージである場合、非同期通信受信部１１１ｃは、ステップＳ６０１で登録した取消条件登録部５０１に登録されている判定条件に基づいて、サーバ機能の呼び出しを取り消すか否かを判定する（ステップＳ６０４）。

ステップＳ６０４においてサーバ機能の呼び出しを取り消すと判定した場合、非同期通信受信部１１１ｃは、サーバ機能の呼び出しを取り消したことを同期通信部１０５ｃへ通知する。それに応じて、同期通信部１０５ｃは、サーバ機能の呼び出しを取り消した旨をクライアント指令部１０４ｃに通知する（ステップＳ６０５）。これによって、クライアント指令部１０４ｃは、同期リターン待ち受け状態から抜ける。一方、ステップＳ６０４においてサーバ機能の呼び出しを取り消さないと判定した場合、非同期通信受信部１１１ｃは、ステップＳ６０２の動作に戻り、メッセージの受信を再開する。

このように、第２の実施形態によれば、クライアント１０ｃの通信制御部５０２は、終了メッセージ以外にキャンセルメッセージを受信することができ、キャンセルメッセージを受信した場合にサーバ機能の呼び出し処理を取り消すか否かを判定するための条件を登録しておくことができる。通信制御部５０２は、キャンセルメッセージを受信した場合、上記条件に基づいて、サーバ機能の呼び出し処理を取り消するか否かを判定する。取り消すと判定した場合、クライアントサーバ機能の呼び出しは途中で取り消されることとなる。したがって、ターンアラウンド時間が短縮されることとなる。

なお、クライアント１０ｃは、サーバ機能の呼び出しを取り消した後、サーバ１０ｂから終了メッセージが送信されてきた場合、当該終了メッセージを破棄してもよい。

（第２の実施形態の変形例１）
なお、キャンセルメッセージを受信したためにサーバ機能の呼び出しを取り消したクライアント１０ｃの非同期通信送信部１０６は、要求メッセージだけでなく、サーバ機能の呼び出しが取り消されたことを示すクライアントサーバキャンセルメッセージをサーバ１０ｂに送信してもよい。このとき、サーバ１０ｂの非同期通信受信部１０７は、非同期通信送信部１０６から送られてくるメッセージとして、要求メッセージだけでなく、クライアントサーバキャンセルメッセージも受信するとよい。非同期通信受信部１０７によってクライアントサーバキャンセルメッセージが受信された場合、サーバ１０ｂは、サーバ機能の実行を中断または終了して、サーバ機能の呼び出しに対する応答を、クライアント１０ｃに送信しないようにするとよい。この動作の詳細を図８に示す。

図８は、サーバ機能の呼び出しを取り消した旨をクライアントがサーバに通知する場合のクライアントサーバ型システム全体の動作を示すフローチャートである。以下、図８を参照しながら、クライアントがサーバ機能の呼び出しを取り消した場合のクライアントサーバ型システム全体の動作について説明する。図８において、図７と同様の動作を示すステップについては、同一のステップ番号を付し、説明を省略する。

ステップＳ６０４においてサーバ機能の呼び出しを取り消すと判定した場合、非同期通信受信部１１１ｃは、同期通信部１０５ｃにサーバ機能の呼び出しを取り消した旨を通知する（ステップＳ６０５）。それに応じて、同期通信部１０５ｃは、非同期通信送信部１０６に対して、クライアントサーバキャンセルメッセージをサーバ１０ｂへ送信させる（ステップＳ７０１）。

サーバ１０ｂは、前処理の実行結果を出力した（ステップＳ２０８）後、クライアント１０ｃからのクライアントサーバキャンセルメッセージを受信したか否かを判断する（ステップＳ７０２）。ステップＳ７０２において、クライアントサーバキャンセルメッセージを受信していないと判断した場合、サーバ１０ｂは、ステップＳ２０９の動作に進む。一方、クライアントサーバキャンセルメッセージを受信していると判断した場合、サーバ１０ｂは、ステップＳ２０９およびステップＳ２１０の動作を行わずに、クライアント１０ｃからの新たな要求メッセージを受信するステップＳ２０６の動作に進み、サーバ機能の実行を中断または終了する。

上記方法によれば、クライアントサーバキャンセルメッセージがクライアント１０ｃからサーバ１０ｂに送信された場合、サーバ１０ｂは、サーバ機能の呼び出しに対する応答をクライアント１０ｃに送信しなくても済む。すなわち、サーバ１０ｂは、前処理を実行した後、前処理の実行結果をクライアント１０ｃに通知しない。また、サーバ１０ｂは、ステップＳ２０２で後処理が登録されていたとしても、必要なくなった後処理を実行しなくてもよくなる。

（第２の実施形態の変形例２）
なお、上記では、クライアント１０ｃがキャンセルメッセージを受信した場合、クライアント１０ｃの非同期通信送信部１０６は、サーバ機能の呼び出しを取り消し、サーバ１０ｃに対してクライアントサーバキャンセルメッセージを送信することとしたが、クライアントサーバキャンセルメッセージを送信したクライアント１０ｃの非同期通信送信部１０６は、中断したサーバ機能の実行を再開させるための再開メッセージを送信してもよい。このとき、サーバ１０ｂの非同期通信受信部１０７は、要求メッセージ、クライアントサーバキャンセルメッセージだけでなく、再開メッセージも受信することができる。クライアント１０ｃによって中断したサーバ機能の実行を再開する旨の再開メッセージがサーバ１０ｂに通知されることによって、サーバ１０ｂは、クライアントサーバキャンセルメッセージが送られてきたために実行しなかった後処理を実行して中断したサーバ機能の実行を再開することができる。この動作の詳細を図９に示す。

図９は、再開メッセージをクライアントがサーバに通知する場合のクライアントサーバ型システム全体の動作を示すフローチャートである。以下、図９を参照しながら、再開メッセージをクライアントがサーバに通知する場合のクライアントサーバ型システム全体の動作について説明する。図９において、図８と同様の動作を示すステップについては、同一のステップ番号を付し、説明を省略する。

ステップＳ７０１において、クライアント１０ｃがクライアントサーバキャンセルメッセージをサーバ１０ｂに送信した後、クライアント指令部１０４ｃは、中断したサーバ機能の実行を再開する旨の再開メッセージをサーバ１０ｂへ送信すべきか否かを判断する（ステップＳ８０１）。再開メッセージを送信する場合、クライアント指令部１０４ｃは、同期通信部１０５ｃおよび非同期通信送信部１０６に再開メッセージをサーバ１０ｂ宛に送信させる（ステップＳ８０２）。なお、ステップＳ８０１の動作は、ステップＳ７０１の動作の後であるならば、任意のタイミングで行われてよい。

サーバ１０ｂは、ステップＳ２０５の後、要求メッセージまたは再開メッセージをクライアント１０ｃから受信する（ステップＳ８０３）。

次に、サーバ１０ｂは、ステップＳ８０３で受信したメッセージが要求メッセージであるかそれとも再開メッセージであるかを判断する（ステップＳ８０４）。要求メッセージであると判断した場合、サーバ１０ｂは、ステップＳ２０７の動作に進む。一方、再開メッセージであると判断した場合、サーバ１０ｂは、ステップＳ２１０の動作に進んで、後処理を実行する。

上記方法によれば、クライアントサーバキャンセルメッセージがあった後、再開メッセージがクライアント１０ｃからサーバ１０ｂに送信された場合、サーバ１０ｂは、サーバ機能の呼び出しが取り消された時点で実行されなかった後処理を実行することとなる。したがって、中断したサーバ機能の実行を再開させることができる。

次に、サーバ機能、前処理、および後処理について具体例を示して、本発明の実施例について説明する。

（第１の実施例）
本発明の第１の実施例は、サーバとして画像デコードサーバを用いる場合のクライアントサーバ型システムである。

従来、クライアントがサーバに対して、サーバ機能として、画像のデコード処理を要求していた場合、サーバでの画像のデコード処理が終わった後、サーバがクライアントに対してデコードの結果を送信して制御を戻すようにしていた。しかし、このような処理の流れでは、クライアントでのレイアウト表示が遅延してしまう。そこで、本発明の第１の実施例に係る画像デコードサーバは、画像のデコード処理の内、画像のサイズを取得するための処理を前処理として登録し、画像をデコードするための処理を後処理として登録しておく。これによって、レイアウト表示の遅延を解消することができる。ここでの前処理では、クライアント側で最低限必要な情報として、デコード後の画像のサイズに関する情報を得ていることとなる。

図１０は、第１の実施例に係るクライアントサーバ型システムにおける処理の流れを模式的に示すシーケンス図である。図１０に示すように、クライアントは、ＵＲＬを選択した場合（ステップＳ１）、当該ＵＲＬで示される画像データを画像デコードサーバに送信して、サーバ機能として、画像のデコードを要求する（ステップＳ２）。

それに応じて、画像デコードサーバは、前処理として、送信された画像データから画像サイズを取得し（ステップＳ３）、当該画像サイズを前処理の実行結果としてクライアントに送信する（ステップＳ４）。

クライアントは、画像サイズであるレイアウト情報を待つ（ステップＳ５）。画像サイズが送られてきたら、クライアントは、当該画像サイズに基づいて、画像が埋め込まれる領域を白地にして、レイアウト表示する（ステップＳ６）。

画像デコードサーバは、前処理の後、後処理として、画像のデコードを実行する（ステップＳ７）。後処理が終了したら、画像デコードサーバは、後処理結果として、デコードした画像をクライアントに通知する（ステップＳ８）。

それに応じて、クライアントは、白地にしていた領域に送られてきた画像を表示する（ステップＳ９）。

このように、第１の実施例では、クライアントがレイアウト表示を行う場合に最低限必要な画像のサイズに関する情報のみを前処理で先に取得しておいて、サーバがクライアントに送信する。その後、画像のデコードが後処理として実行されて、デコードされた画像がサーバからクライアントに送信される。これによって、クライアントは、サーバのデコード処理が完了するのを待つことなく、レイアウト処理を開始することができる。

（第２の実施例）
本発明の第２の実施例は、サーバとして文字変換用かな漢サーバを用いる場合のクライアントサーバ型システムである。

従来、クライアントが漢字候補を指定した時点で、サーバが予測データの取得処理を行おうとする場合、当該取得処理に時間がかかるので、クライアントでの予測データの表示に時間がかかる。一方、予測データ表示にかかるレスポンスを向上するために、サーバに対してクライアントが候補取得要求する際に、予測データの取得もまとめて要求しようとすると、クライアントによる候補表示に時間がかかる。そこで、本発明の第２の実施例に係る文字変換用かな漢サーバは、文字変換の処理の内、候補を抽出するための処理を前処理として登録し、予測データを取得するための処理を後処理として登録しておく。ここでの前処理では、クライアント側で最低限必要な情報として、文字変換候補に関する情報を得ていることとなる。

図１１は、第２の実施例に係るクライアントサーバ型システムにおける処理の流れを模式的に示すシーケンス図である。図１１に示すように、クライアントは、かなを入力した場合（ステップＳ１１）、変換候補の取得を文字変換用かな漢サーバに要求する（ステップＳ１２）。

それに応じて、文字変換用かな漢サーバは、前処理として、送信されてきたかなに対応する変換候補を抽出し（ステップＳ１３）、当該変換候補を前処理の実行結果としてクライアントに送信する（ステップＳ１４）。

クライアントは、文字変換用かな漢サーバから変換候補が通知されるまで、処理を待つ（ステップＳ１５）。変換候補が送られてきたら、クライアントは、当該変換候補を表示する（ステップＳ１６）。次に、クライアントは、当該変換候補の中から、一つを選んで、決定した結果を通知する（ステップＳ１７）。ここでは、「犬」が選ばれたとする。

文字変換用かな漢サーバは、前処理の後、後処理として、変換候補に対応する予測データを整理しておく（ステップＳ１８）。たとえば、「狗」が選ばれたら、「と遊ぶ」を予測データとし、「犬」が選ばれたら、「が嫌い」、「の名前」を予測データとして抽出して整理しておく。ここでは、「犬」が選ばれたので、文字変換用かな漢サーバは、後処理結果として、「犬」に対応する予測データをクライアントに通知する（ステップＳ１９）。

それに応じて、クライアントは、通知されてきた予測データを表示する（ステップＳ２０）。

このように、第２の実施例では、変換候補の抽出処理を前処理とし、予測データの整理処理を後処理と設定し、変換処理の抽出処理が終了した時点で、サーバは、クライアントに制御を戻る。したがって、クライアントによる変換候補の表示と、サーバによる予測データの整理とが並行に実行されることとなるので、漢字候補を指定した時点での予測データの表示に係るレスポンス時間を短縮することができる。

（第３の実施例）
本発明の第３の実施例は、サーバとして動画アプリサーバを用いる場合のクライアントサーバ型システムである。

第３の実施例において、アクティブ状態といった場合、アプリケーションが操作対象になっている状態のことを示す。インアクティブ状態といった場合、アプリケーションが操作対象になっていない状態のことを示す。第３の実施例で用いられるアプリケーションは、常駐アプリであってもよいし、非常駐アプリであってもよい。ここで、常駐アプリとは、インアクティブ要求の後に、動作したままインアクティブ状態になるアプリケーションのことをいう。非常駐アプリとは、インアクティブ要求があった場合に完全に停止するアプリケーションのことをいう。以下の説明において、各アプリケーションは、常駐アプリであるとする。

携帯電話等のモバイル端末において、電話アプリは、電話通話要求を受け付けると、着メロを鳴らして、ユーザに対して、着信があった旨を伝える。動画アプリサーバは、音声付きの動画を再生する。通常、モバイル端末では、同時に二つ以上の音声を出力することができないので、競合調停アプリが、アプリケーション（例えば、電話アプリと動画アプリサーバ）間の競合を判定し、各アプリケーションをアクティブ状態からインアクティブ状態に遷移する。従来、動画アプリサーバがアクティブ状態のときに、着信があった場合、電話アプリは、競合調停アプリに対して、電話アプリをアクティブ状態にするよう要求する。次に、競合調停アプリは、動画アプリサーバに対して、動画アプリをインアクティブ状態にするように要求する。インアクティブ要求に対して、動画アプリサーバは、動画と一緒に音声を停止させ、途中情報を保存した後、動画アプリがインアクティブになった旨を競合調停アプリに返す。それに応じて、競合調停アプリは、電話アプリをアクティブにしてよい旨を電話アプリに返す。そして、電話アプリは、着メロを開始する。したがって、従来の方法では、動画アプリによって、途中情報が保存されるまで、電話アプリは、着メロを開始するのを待たなければならなかった。よって、ターンアラウンド期間が長かった。

そこで、本発明の第３の実施例に係る動画アプリは、インアクティブ要求があった場合、動画アプリをインアクティブにする処理の内、動画および音声を停止するための処理を前処理として登録し、動画アプリの途中情報をファイルとして保存する処理を後処理として登録しておくこととする。

図１２は、第３の実施例に係るクライアントサーバ型システムにおける処理の流れを模式的に示す図である。図１２に示すように、電話アプリは、インアクティブ状態であるときに（ステップＳ２１）、着信通知（ステップＳ２２）があったとする。これに応じて、電話アプリは、電話アプリをアクティブ状態にしてもよいか否かを判断させるための要求を同期通信で競合調停アプリに伝え（ステップＳ２３）、同期リターン待ちとなる（ステップＳ３５）。

イベント待ち（ステップＳ２４）であった競合調停アプリは、これに応じて、動画アプリをインアクティブ状態にするための要求を同期通信で動画アプリサーバに伝え（ステップＳ２５）、同期リターン待ち（ステップＳ３１）となる。

アクティブ状態（ステップＳ２６）であった動画アプリサーバは、前処理として、実行中の動画および音声を停止させて（ステップＳ２７）、インアクティブ状態となる（ステップＳ２８）。次に、動画アプリサーバは、動画アプリサーバがインアクティブ状態になった旨のＯＫ通知を競合調停アプリに伝える（ステップＳ２９）。その後、動画アプリサーバは、後処理として、動画アプリの途中情報をファイルとして保存する（ステップＳ３０）。途中情報としては、停止した時点に関する情報や、動画の表示位置、色調整情報等である。これらの途中情報をファイルとして保存しておくことによって、動画アプリサーバは、動画表示を再生させるとき、途中から動画を再生させることができる。

同期リターン待ち（ステップＳ３１）であった競合調停アプリは、動画アプリサーバからのＯＫ通知を受信すると、同期リターン待ちを解除し（ステップＳ３２）、電話アプリをアクティブにしてもよい旨のＯＫ通知を電話アプリに伝え（ステップＳ３３）、イベント待ちとなる（ステップＳ３４）。

競合調停サーバからのＯＫ通知に応じて、電話アプリは、同期リターン待ち（ステップＳ３５）から、アクティブ状態となって（ステップＳ３６）、電話アプリの着メロを開始する（ステップＳ３７）。これによって、音声の競合が発生しないこととなる。

このように、第３の実施例では、音声の競合は発生しない最低限の処理を前処理として登録し、動画を再度再生するために準備しておく処理を後処理として登録しておくことによって、電話アプリおよび競合調停アプリでのターンアラウンド期間を短縮することができる。

このように、本発明に係るクライアントサーバ型システムで用いられる方法、サーバ、およびクライアントは、同期通信によるクライアントのサーバ機能要求を開始した時点からサーバ機能終了通知までのターンアラウンド時間を短縮することができるので、携帯電話やＰＤＡなどハードウェア性能が低い機器やシステムなどに有用である。

本発明の第１の実施形態に係るクライアントサーバ型システムの構成の一例を示すブロック図 サーバ機能対応付け部１０３に保持されているサーバ機能、前処理、および後処理を対応付けたテーブルの一例を示す図 第１の実施形態に係るクライアントサーバ型システムにおけるサーバ１０ｂとクライアント１０ａとの間の処理の概要を説明するためのシーケンス図 本発明の第１の実施形態に係るクライアントサーバ型システム全体の動作の詳細を示すフローチャート 後処理の実行結果も得ることができるクライアントサーバ型システム全体の動作の詳細を示すフローチャート 本発明の第２の実施形態に係るクライアントサーバ型システムの全体構成の一例を示すブロック図 第２の実施形態に係るクライアントサーバ型システム全体の動作を示すフローチャート サーバ機能の呼び出しを取り消した旨をクライアントがサーバに通知する場合のクライアントサーバ型システム全体の動作を示すフローチャート 再開メッセージをクライアントがサーバに通知する場合のクライアントサーバ型システム全体の動作を示すフローチャート 第１の実施例に係るクライアントサーバ型システムにおける処理の流れを模式的に示すシーケンス図 第２の実施例に係るクライアントサーバ型システムにおける処理の流れを模式的に示すシーケンス図 第３の実施例に係るクライアントサーバ型システムにおける処理の流れを模式的に示すシーケンス図 従来の同期通信方法におけるサーバとクライアントとの処理の流れを示すシーケンス図 特許文献１に記載されている従来の同期通信方法の流れを示すシーケンス図

符号の説明

１０ａ，１０ｃ，５０ａ クライアント
１０ｂ サーバ
１００ サーバ指令部
１０１ 前処理登録部
１０２ 後処理登録部
１０３ サーバ機能対応付け部
１０４，１０４ｃ クライアント指令部
１０５，１０５ｃ 同期通信部
１０６ 非同期通信送信部
１０７ 非同期通信受信部
１０８ 前処理実行部
１０９ 非同期通信送信部
１１０ 後処理実行部
１１１，１１１ｃ 非同期通信受信部
１１２ 通信制御部
５０１ 取消条件登録部
５０２ 通信制御部

Claims (2)

1. クライアントコンピュータがサーバコンピュータに対して所望のサーバ機能を呼び出し、呼び出された前記サーバ機能に対応する処理を前記サーバコンピュータが実行するクライアントサーバ型分散システムにおいて用いられる方法であって、
   前記サーバ機能に対応する処理の一部であり、前記クライアントコンピュータに通知すべき実行結果を得るまでの処理を前記サーバコンピュータが前処理として登録するステップと、
   前記サーバ機能に対応する処理の一部であり、前記クライアントコンピュータに実行結果を通知する必要がない前記サーバコンピュータの処理であって、前記前処理の後に実行すべき処理を前記サーバコンピュータが後処理として登録するステップと、
   前記サーバコンピュータが、登録されている前記前処理と、登録されている前記後処理と、前記サーバ機能を示すサーバ機能識別子とを対応付けたテーブルに保持するステップと、
   前記クライアントコンピュータが、所望のサーバ機能の呼び出しを要求するために、当該所望のサーバ機能を示すサーバ機能識別子が含まれる要求メッセージを前記サーバコンピュータに対して送信するステップと、
   前記サーバコンピュータが前記クライアントコンピュータから送信されてくる前記要求メッセージを受信するステップと、
   前記サーバコンピュータが保持するテーブルの中から、前記要求メッセージに含まれる前記サーバ機能識別子に対応付けられた前処理を決定し、前記決定した前処理を前記サーバコンピュータが実行するステップと、
   前記サーバコンピュータが実行した前記前処理の実行結果を含む終了メッセージを前記サーバコンピュータが前記クライアントコンピュータに対して送信するステップと、
   前記終了メッセージの送信後に、前記サーバコンピュータが保持するテーブルの中から、前記要求メッセージに含まれる前記サーバ機能識別子に対応付けられた後処理を決定し、前記決定した後処理を前記サーバコンピュータが実行するステップと、
   前記終了メッセージを受信した前記クライアントコンピュータが前記前処理の実行結果に基づいた処理を実行するステップとを備え、
   前記サーバコンピュータは、前記後処理の実行結果を前記クライアントコンピュータに通知しないことを特徴とする、方法。
2. クライアントコンピュータから呼び出されたサーバ機能を実行するためのサーバコンピュータであって、
   前記サーバ機能に対応する処理の一部であり、前記クライアントコンピュータに通知すべき実行結果を得るまでの処理を前処理として登録する前処理登録部と、
   前記サーバ機能に対応する処理の一部であり、前記クライアントコンピュータに実行結果を通知する必要がない前記サーバコンピュータの処理であって、前記前処理の後に実行すべき処理を後処理として登録する後処理登録部と、
   登録されている前記前処理と、登録されている前記後処理と、前記サーバ機能を示すサーバ機能識別子とを対応付けたテーブルに保持するサーバ機能対応付け部と、
   前記クライアントコンピュータが所望するサーバ機能を示すサーバ機能識別子が含まれる要求メッセージを前記クライアントコンピュータから受信する受信部と、
   前記テーブルの中から、前記要求メッセージに含まれる前記サーバ機能識別子に対応付けられた前処理を決定し、前記決定した前処理を実行して、実行結果を出力する前処理実行部と、
   前記前処理実行部が出力した前記前処理の実行結果を含む終了メッセージを前記クライアントコンピュータに対して送信する送信部と、
   前記終了メッセージの送信後に、前記テーブルの中から、前記要求メッセージに含まれる前記サーバ機能識別子に対応付けられた後処理を決定し、前記決定した後処理を実行して、実行結果を出力する後処理実行部とを備え、
   前記後処理の実行結果を前記クライアントコンピュータに通知しないことを特徴とする、サーバコンピュータ。

Images