(57)【要約】【課題】  緊急性の高いメッセージを早く受信でき、緊急性の低いメッセージの送信をキャンセルして採用するよりも、緊急性の低いメッセージの送信時間を短縮させる。【解決手段】  メッセージを送受信する通信システムにおいて、メッセージは、当該メッセージを伝送するプロトコルで処理される情報を含むヘッダを有し、送信側で、メッセージの優先度を前記ヘッダに含めて送信する。受信側で、そのメッセージのヘッダに含まれている優先度に応じて、当該メッセージの受信を制御する。そして、第一のメッセージを受信中に、送信側から該第一のメッセージよりも優先度の高い第二のメッセージが送信された場合、当該第二のメッセージを優先的に受信するように制御する。【選択図】      図３
2010041117.tif 000002
【特許請求の範囲】
【請求項１】
メッセージを送受信する通信システムの制御方法であって、
前記メッセージは、当該メッセージを伝送するプロトコルで処理される情報を含むヘッダを有し、
送信側で、前記メッセージの優先度を前記ヘッダに含めて送信する送信工程と、
受信側で、前記メッセージのヘッダに含まれている優先度に応じて、当該メッセージの受信を制御する制御工程とを有し、
前記制御工程では、第一のメッセージを受信中に、該第一のメッセージよりも優先度の高い第二のメッセージが送信された場合、当該第二のメッセージを優先的に受信するように制御することを特徴とする通信システムの制御方法。
【請求項２】
前記制御工程では、第一のメッセージを受信中に、該第一のメッセージよりも優先度の高い第二のメッセージが送信された場合、前記第一のメッセージより先に前記第二のメッセージの受信が完了するように制御することを特徴とする請求項１に記載の通信システムの制御方法。
【請求項３】
前記制御工程では、第一のメッセージを受信中に、該第一のメッセージよりも優先度の高い第二のメッセージが送信された場合、前記第一のメッセージの未受信のデータ量と前記第二のメッセージのデータ量に基づいて、前記第一のメッセージより先に前記第二のメッセージの受信が完了するように制御することを特徴とする請求項１に記載の通信システムの制御方法。
【請求項４】
前記制御工程では、前記第一のメッセージを読み込む読み込み速度を低減させて、前記第二のメッセージを優先的に受信するように制御することを特徴とする請求項１に記載の通信システムの制御方法。
【請求項５】
前記制御工程では、前記第一のメッセージを読み込む間隔を長くすることで、前記読み込み速度を低減させることを特徴とする請求項２に記載の通信システムの制御方法。
【請求項６】
前記制御工程では、前記第一のメッセージを読み込む１回の読み込み量を少なくすることで、前記読み込み速度を低減させることを特徴とする請求項２に記載の通信システムの制御方法。
【請求項７】
メッセージを受信する受信装置であって、
当該メッセージを受信する受信手段と、
当該メッセージを伝送するプロトコルで処理される情報を含むヘッダに設定される優先度に応じて、当該メッセージの受信を制御する制御手段とを有し、
前記制御手段は、第一のメッセージを受信中に、該第一のメッセージよりも高い優先度が設定された第二のメッセージが受信された場合、当該第二のメッセージを優先的に受信するように前記受信手段を制御することを特徴とする受信装置。
【請求項８】
前記制御手段は、第一のメッセージを受信中に、該第一のメッセージよりも優先度の高い第二のメッセージが受信された場合、前記第一のメッセージより先に前記第二のメッセージの受信が完了するように前記受信手段を制御することを特徴とする請求項７に記載の受信装置。
【請求項９】
前記制御手段は、第一のメッセージを受信中に、該第一のメッセージよりも優先度の高い第二のメッセージが送信された場合、前記第一のメッセージの未受信のデータ量と前記第二のメッセージのデータ量に基づいて、前記第一のメッセージより先に前記第二のメッセージの受信が完了するように前記受信手段を制御することを特徴とする請求項７に記載の受信装置。
【請求項１０】
コンピュータを、請求項７乃至９の何れか一項に記載の受信装置として機能させるためのプログラム。
【請求項１１】
請求項１０に記載のプログラムを記録したコンピュータ読み取り可能な記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、メッセージを送受信する通信システムの制御方法及びメッセージを受信する受信装置に関するものである。
【背景技術】
【０００２】
近年、コンピュータネットワークの普及に伴い、様々なサービスがコンピュータネットワークを介して提供されている。現在、とりわけ世界的に注目され、利用されている技術として、Ｗｅｂサービス関連技術が挙げられる。Ｗｅｂサービスとは、ＨＴＴＰに代表される様々な通信プロトコルを利用して、人間の手を介さすにコンピュータ同士がデータを動的に交換する仕組みである。Ｗｅｂサービスでは、クライアント及びサーバ間における通信プロトコル上をＳＯＡＰメッセージが流れることにより、様々なコンピュータ機器や組み込み機器などが情報を受け取ることができる。
【０００３】
Ｗｅｂサービスを利用することで、テキストだけでなく、画像などの大容量のデータを含むＳＯＡＰメッセージを交換することも可能である。ＳＯＡＰメッセージを受け付けるサービスを公開しているサーバに対して、クライアントが大容量のＳＯＡＰメッセージを送信した場合、ＳＯＡＰメッセージの送信が終了するまでには時間がかかる。
【０００４】
そのため、大容量のＳＯＡＰメッセージを送信中に、緊急性の高いＳＯＡＰメッセージをサーバ側に先に受信してもらいたい場合、緊急性の高いＳＯＡＰメッセージを優先して先に送信させる制御の仕組みが必要である。
【０００５】
クライアント及びサーバ間における優先順位を制御する技術としては、ネットワーク上を流れるＩＰパケット毎に優先度を与えることで、ＩＰパケットレベルで優先順位を制御する技術がある。この優先順位制御技術は、クライアント及びサーバ間にＩＰパケットの優先度を解釈し、優先度の高いパケットを送信する中継装置を設置することで実現される（例えば、特許文献１参照）。
【特許文献１】特開２００３−２０９５７３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかしながら、上記優先順位制御技術では、アプリケーションで設定した優先度をＩＰパケットの優先度に変換させる独自の装置やクライアント及びサーバ間にＩＰパケットの優先度を制御する独自の中継装置が必要である。
【０００７】
本来、Ｗｅｂサービスでは、ネットワーク層やトランスポート層には非依存な仕様にもかかわらず、上記優先順位制御技術を使用した場合、必ずＩＰパケットを制御する装置とセットで使用しなければならない。
【０００８】
そのため、ＳＯＡＰメッセージレベルの処理を行う装置を、ネットワークからＳＯＡＰメッセージを受信し、ストリームとして処理可能とする汎用的なサーブレットコンテナ上で動かすなどが困難になり、装置自体の汎用性が低下する。
【０００９】
また、ネットワーク層やトランスポート層に依存しない処理で、緊急性の高いＳＯＡＰメッセージを優先して先に送信させるには、送信中の緊急性の低いＳＯＡＰメッセージを１度キャンセルさせるしかなかった。そのため、再度キャンセルしたＳＯＡＰメッセージを送信するには、最初から送信を開始しなければならず、送信が完了するまで、より時間がかかってしまうという問題があった。
【００１０】
ここでは、ＳＯＡＰを例に説明したが、ＳＯＡＰ以外のメッセージング技術、例えば、ＸＭＬ−ＲＰＣ（Remote Procedure Call）などにおいても、同様である。
【００１１】
本発明は、緊急性の高いメッセージを早く受信でき、緊急性の低いメッセージの送信をキャンセルして採用するよりも、緊急性の低いメッセージの送信時間を短縮させることを目的とする。
【課題を解決するための手段】
【００１２】
本発明は、メッセージを送受信する通信システムの制御方法であって、
前記メッセージは、当該メッセージを伝送するプロトコルで処理される情報を含むヘッダを有し、
送信側で、前記メッセージの優先度を前記ヘッダに含めて送信する送信工程と、
受信側で、前記メッセージのヘッダに含まれている優先度に応じて、当該メッセージの受信を制御する制御工程とを有し、
前記制御工程では、第一のメッセージを受信中に、該第一のメッセージよりも優先度の高い第二のメッセージが送信された場合、当該第二のメッセージを優先的に受信するように制御することを特徴とする。
【００１３】
また、本発明は、メッセージを受信する受信装置であって、
当該メッセージを受信する受信手段と、
当該メッセージを伝送するプロトコルで処理される情報を含むヘッダに設定される優先度に応じて、当該メッセージの受信を制御する制御手段とを有し、
前記制御手段は、第一のメッセージを受信中に、該第一のメッセージよりも高い優先度が設定された第二のメッセージが受信された場合、当該第二のメッセージを優先的に受信するように前記受信手段を制御することを特徴とする。
【発明の効果】
【００１４】
本発明によれば、緊急性の高いメッセージを早く受信でき、緊急性の低いメッセージの送信をキャンセルして採用するよりも、緊急性の低いメッセージの送信時間を短縮させることが可能となる。
【発明を実施するための最良の形態】
【００１５】
以下、図面を参照しながら発明を実施するための最良の形態について詳細に説明する。
【００１６】
本実施形態では、送信側と受信側との間でメッセージを送受信する通信システムとしてクライアントサーバシステムを例に説明する。また、クライアントのアプリケーションが送信したストリームのメッセージに対してサーバがそのメッセージに対応するサービスを提供する場合を説明する。
【００１７】
まず、クライアント及びサーバ間において、受信中のメッセージよりも、優先度が高いメッセージが送信された場合に、優先度の高いメッセージを先に受信するように制御する優先順位制御部の概要を説明する。
【００１８】
図１は、本実施形態におけるクライアントサーバシステムの構成を示す図である。図１において、１００及び１０１は優先順位制御部であり、ＳＯＡＰメッセージに設定された優先度に応じて、そのＳＯＡＰメッセージの受信を制御する。１０２はクライアント側の装置（クライアント）であり、１０３はサーバ側の装置（サーバ）である。
【００１９】
尚、ここではＳＯＡＰメッセージを例に説明するが、送受信されるメッセージは、ＳＯＡＰ以外のメッセージ、例えばＸＭＬ−ＲＰＣ（Remote Procedure Call）のメッセージなどでも良い。ＸＭＬ−ＲＰＣでは、リクエストヘッダにＨＴＴＰヘッダ、リクエストのボディにＸＭＬ文書という構成からなるメッセージが送受信される。
【００２０】
優先順位制御部１００、１０１は、クライアントとしての機能と、サーバとしての機能を兼ね備えたものであり、図１では、便宜的に区別して示しているが、同一のものである。優先順位制御部１００、１０１が設置される機器としては、例えばコピー、スキャン、プリントなどの複数の機能を有する複合機であっても良く、またパーソナルコンピュータであっても良い。
【００２１】
クライアント１０２には、優先順位制御部１００を利用してサーバ側のＷｅｂサービスにアクセスするアプリケーション１０４がインストールされている。そして、このアプリケーション１０４からの指示１０５により、優先順位制御部１００が対応するプロトコルバインディングヘッダを含むＳＯＡＰメッセージ１０６を生成し、サーバ１０３側に送信する。送信されたＳＯＡＰメッセージ１０６は、ネットワーク上でストリーム１０７として流れ、サーバ１０３に設置されたサーブレットコンテナ１０８がＳＯＡＰメッセージの先頭のデータから受け取りを開始する。ここで、プロトコルバインディングヘッダは、ＳＯＡＰメッセージを伝送するプロトコル（例えば、ＨＴＴＰ）で処理される情報を含むヘッダである。
【００２２】
次に、サーバ１０３の優先順位制御部１０１がサーブレットコンテナ１０８からプロトコルバインディングヘッダの情報１０９を取得し、またストリーム１１０としてＳＯＡＰメッセージを取得する。サーバ１０３は、プロトコルバインディングヘッダの情報１０９から、受信したメッセージがＳＯＡＰメッセージであることを、アプリケーション層であるＨＴＴＰのレベルにおいて判断できる。そして、ＳＯＡＰメッセージ全体の取得が終了すると、ＳＯＡＰメッセージをサービスロジック１１１へバインディングする。一方、ＳＯＡＰメッセージを受信したサービスロジック１１１は、アプリケーション１０４から指示されたサービスの処理を実行する。
【００２３】
ここで、クライアント側で緊急性の低いＳＯＡＰメッセージの送信をキャンセルすることなく、緊急性の高いＳＯＡＰメッセージを優先的にサーバ側へ送信する優先順位制御部１００、１０１の処理を説明する。
【００２４】
まず、クライアント１０２のアプリケーション１０４が、ＳＯＡＰメッセージ１０６を送信中に、緊急性の高いＳＯＡＰメッセージ１１４をサーバ１０３へ優先的に送信させたい旨を優先順位制御部１００に指示する（１１２）。優先順位制御部１００は、ＳＯＡＰメッセージ１１４のプロトコルバインディングヘッダに、拡張ヘッダとして優先度を設定できるようにし、緊急性が高いことを示すように優先度の値を高く設定する（１１３）。プロトコルバインディングヘッダとしては、例えばＨＴＴＰヘッダが挙げられ、ＨＴＴＰヘッダでは、任意のヘッダを定義して送信することが可能である。
【００２５】
ＨＴＴＰの仕様では、ユーザが任意のヘッダとその値を設定することが許されている。したがって、受信したＨＴＴＰヘッダを解析する側では、解析できないヘッダがあれば、それは無視する。
【００２６】
よって、ヘッダに優先度など独自のヘッダをいれたメッセージを送ったとしても、相手が解釈できなければ、相手は通常のメッセージの処理を行えばよく、処理を続行することが可能である。
【００２７】
逆にプロトコルバインディングヘッダではなく、例えばメッセージのボディ部分にあたるＳＯＡＰ文書内に優先度を入れてしまうと、場合によってはそれを受信した相手側でＳＯＡＰ文書の解析時に不具合を起こす可能性もある。
【００２８】
また、ヘッダ部分に優先度を入れる方が、ヘッダ部分は、情報量が少ないので、受信側の解析処理の負荷がかからず、ボディ部のＳＯＡＰ文書の受信速度のコントロール処理及び優先処理をより早く開始できる。したがって、緊急性の高いメッセージを早く受信できる。
【００２９】
ＳＯＡＰメッセージ１１４は、ネットワーク上でストリーム１１５として流れ、サーバ１０３のサーブレットコンテナ１０８が受信する。次に、優先順位制御部１０１がサーブレットコンテナ１０８からＳＯＡＰメッセージのプロトコルバインディングヘッダの情報１１６を取得する。そして、優先順位制御部１０１は取得したプロトコルバインディングヘッダの優先度の値と、先に受信中のＳＯＡＰメッセージ１０６の優先度の値とを比較し、ＳＯＡＰメッセージ１１４の優先度が高いと判断する。
【００３０】
次に、優先度の高いＳＯＡＰメッセージ１１４を先に取得完了させるためには、優先度の低いＳＯＡＰメッセージ１０６の読み込み速度をどれくらい低減させればよいかを算出する。算出した結果に基づいて、先に受信中のＳＯＡＰメッセージ１０６の読み込み速度を低減させる（１１８）。そして、ストリーム１１９としてＳＯＡＰメッセージ１１４を取得し、ＳＯＡＰメッセージ１１４の取得が全て終了すると、サービスロジック１１１へバインディングする。
【００３１】
このように、ＳＯＡＰメッセージ１０６の送信をキャンセルすることなく、緊急性の高いＳＯＡＰメッセージ１１４を先にサーバ１０３へ送信させることが可能となる。
【００３２】
ここで、プロトコルバインディングヘッダを含むＳＯＡＰメッセージを、図２を用いて具体的に説明する。
【００３３】
図２は、プロトコルバインディングヘッダを含むＳＯＡＰメッセージの一例を示す図である。２０１はプロトコルバインディングヘッダを含むＳＯＡＰメッセージ全体であり、プロトコルバインディングヘッダ部２０２とメッセージのボディ部２０３とで構成されている。本実施形態では、プロトコルとしてＨＴＴＰを例に説明する。
【００３４】
プロトコルバインディングヘッダ部２０２は、ＳＯＡＰメッセージを伝送するプロトコル（例えば、ＨＴＴＰ）で処理される情報を含むヘッダ部２０２を有する。ここで、プロトコルバインディングヘッダ部２０２では、Content-TypeやContent-LengthなどのＨＴＴＰの仕様に基づいたヘッダ情報を記載している。このヘッダ部２０２には、上述の優先順位制御に必要な優先度を示すPriorityヘッダ２０４が拡張ヘッダとして追加されている。ＨＴＴＰヘッダは、任意のヘッダを定義して送信することが可能であるため、このような記述ができる。
【００３５】
サーバ１０３の優先順位制御部１０１は、この拡張ヘッダの値から優先度を判断する。図２では、「Priority:1」として、数値で優先度を示しているが、この記述に限定されるものではない。即ち、クライアント側とサーバ側とで合意した数値ではない他の仕様にも対応可能である。
【００３６】
ＳＯＡＰメッセージが大容量になるパターンとして、バイナリデータがＳＯＡＰメッセージ内に埋め込まれていることが想定される。その例を示したのが２０５であり、２０５では、バイナリデータがＢａｓｅ６４に変換された状態で埋め込まれている。２０５では、途中の情報を省略しているが、本来は、バイナリデータのサイズが大きければ、ＳＯＡＰメッセージ自体も大容量となり、読み込みに時間を要する。
【００３７】
上述したように、ＳＯＡＰメッセージ１０６を送信中に、緊急性の高いＳＯＡＰメッセージ１１４を送信したくなった時点で、まだ途中の部分２０６までしかサーバ１０３側で読み込めてないという状態が発生する。そのため、従来は、ＳＯＡＰメッセージ１０６の送信を一旦キャンセルするしかなかった。
【００３８】
次に、上述のＳＯＡＰメッセージ１０６の送信をキャンセルすることなく緊急性の高いＳＯＡＰメッセージ１１４を送信する際の優先順位制御部１００、１０１の具体的な処理内容を、図３を用いて説明する。
【００３９】
図３は、本実施形態における優先順位制御部の構成の一例を示す図である。図３では、図１と同じものには同じ符号を付し、その説明は省略する。
【００４０】
まず、クライアント側で、アプリケーション１０４が優先順位制御部１００の優先順位設定処理部３０１に送信しようとしているＳＯＡＰメッセージの優先度を通知する。一方、優先順位設定処理部３０１は、通知された優先度をプロトコルバインディングヘッダの拡張ヘッダの値として設定する。そして、拡張ヘッダとして優先度を設定したプロトコルバインディングヘッダを含むＳＯＡＰメッセージ１１４を生成し、メッセージ送信処理部３０２からネットワーク３０３上に流す。
【００４１】
次に、サーバ側では、クライアント側が先に送信していたＳＯＡＰメッセージ１０６をサーブレットコンテナ１０８からメッセージ読み込み処理部３０４が読み込み中であるとする。ここで、ＳＯＡＰメッセージ１１４をサーブレットコンテナ１０８が受信し、プロトコルバインディングヘッダ読み込み処理部３０５が、そのＳＯＡＰメッセージ１１４のプロトコルバインディングヘッダの情報を読み込む。
【００４２】
そして、優先順位解析処理部３０６がプロトコルバインディングヘッダの情報から拡張ヘッダに設定されている優先度の情報を取得し、ＳＯＡＰメッセージ１０６の優先度の情報と比較する。比較した結果、既に読み込み中のＳＯＡＰメッセージ１０６よりも、受信したＳＯＡＰメッセージ１１４の読み込みを優先すると判断する。判断した結果、ストリーム読み込み制御算出処理部３０７が、読み込んだヘッダの情報からＳＯＡＰメッセージ１１４に関する情報を取得する。ここで、ＳＯＡＰメッセージ１１４に関する情報とは、例えばＳＯＡＰメッセージ１１４の全体サイズなどである。
【００４３】
また、優先順位解析処理部３０６から比較結果を受け取り、メッセージ読み込み処理部３０４から、既に読み込み中のＳＯＡＰメッセージ１０６に関する情報を取得する。このＳＯＡＰメッセージ１０６に関する情報とは、例えばＳＯＡＰメッセージ１０６のうち、まだ読み込んでない部分がどのくらい残っているかなどを示す情報である。
【００４４】
そして、ストリーム読み込み制御算出処理部３０７はＳＯＡＰメッセージ１１４を優先して読み込むために、ＳＯＡＰメッセージ１０６の読み込み速度をどの程度低減させれば良いかを解析し、制御情報を算出する。
【００４５】
次に、メッセージ読み込み処理部３０４がストリーム読み込み制御算出処理部３０７から算出された制御情報に応じて、ＳＯＡＰメッセージ１０６の読み込み速度を低減させてＳＯＡＰメッセージ１１４を先に読み込む。その後、ＳＯＡＰメッセージ１１４の読み込みが終了すると、ＳＯＡＰメッセージ１１４の情報をサービスロジック１１１にバインドする。そして、読み込み速度を低減させたＳＯＡＰメッセージ１０６の読み込みが終了すると、ＳＯＡＰメッセージ１１４と同様に、サービスロジック１１１へバインドする。
【００４６】
次に、サーバ１０３の優先順位制御部１０１におけるストリーム読み込み制御算出処理部３０７の具体的な処理内容を、図４及び図５を用いて説明する。
【００４７】
図４は、本実施形態における優先順位制御を開始する時点での具体的な数値を示す図である。また、図５は、ストリーム読み込み制御算出処理部の処理を示すフローチャートである。
【００４８】
図４において、４０１はサーバ１０３の処理能力を示す数値の一例である。ここでは、ストリームからメッセージを読み込む速度として1000［byte/s］が、またストリームからメッセージを１度に読み込むバッファサイズとして1000［byte］が記憶される。４０２は各メッセージの情報であり、メッセージの全体サイズ、受信済みサイズ、優先度の数値が記憶される。
【００４９】
図５に示すステップＳ５０１で、ストリーム読み込み制御算出処理部３０７は優先順位解析処理部３０６が解析した結果を取得する。各メッセージの情報４０２から、優先度の数値はそれぞれ、第一受信メッセージが“１”、第二受信メッセージが“１０”となり、第二受信メッセージの方が優先度が高いという結果になる。
【００５０】
次に、ステップＳ５０２で、プロトコルバインディングヘッダ読み込み処理部３０５が読み込んだプロトコルバインディングヘッダの情報から、第一及び第二受信メッセージの全体サイズ（データ量）を取得する。各メッセージの情報４０２から、全体のサイズはそれぞれ、第一受信メッセージが20000［byte］、第二受信メッセージは、40000［byte］となる。
【００５１】
次に、ステップＳ５０３で、受信中の第一受信メッセージをどれくらい既に受信し終わっているかを示す受信済みサイズ（データ量）を取得する。各メッセージの情報４０２から、第一受信メッセージの受信済みサイズは10000［byte］となる。
【００５２】
次に、ステップＳ５０４で、第一受信メッセージの受信してない残りの部分を受信するために、どのくらいの時間がかかるかを算出する。この例では、受信してない残りの部分（未受信のデータ量）は全体のサイズから受信済みサイズを引いた値、即ち、20000−10000＝10000［byte］となる。また、ストリームからメッセージを読み込む速度は、1000［byte/s］に設定されているので、受信してない残りの部分を読み込むのに必要な時間は、以下の計算により１０秒となる。
【００５３】
10000［byte］÷1000［byte/s］＝10［s］
次に、ステップＳ５０５で、第二受信メッセージを全て受信するための時間を算出する。各メッセージの情報４０２から、ストリームからメッセージを読み込む速度は、1000［byte/s］に設定されているので、以下の計算により４０秒となる。
【００５４】
40000［byte］÷1000［byte/s］＝40［s］
そして、ステップＳ５０６で、優先順位の比較結果と、計算結果とから、メッセージをストリームから１度に読み込む間隔毎に設定する読み込み待機時間を算出する。例えば、取得した優先順位の比較結果から、まず第一受信メッセージよりも第二受信メッセージの方を優先的に受信しなければならないと判断する。そして、第二受信メッセージの方を第一受信メッセージより先に受信し終わるためには、第一受信メッセージの読み込み速度をどのくらい遅くすればよいかを解析する。
【００５５】
即ち、第一受信メッセージのストリームから１度に読み込む間隔毎に設定する読み込み待機時間をどの程度にすれば良いかを解析する。この例では、ストリームからメッセージを１度に読み込むバッファサイズは1000［byte］である。そのため、第一受信メッセージの受信してないサイズである10000［byte］を読み込むためには、以下の計算により10回ループする必要がある。
【００５６】
10000［byte］÷1000［byte］＝10［回］
以上の結果をまとめると、第一受信メッセージの未受信部分を読み込む時間が１０秒、読み込むために処理をループさせる回数は１０回、第二受信メッセージを受信し終わる時間が４０秒となる。これらの結果から、最終的な算出値である、読み込み待機時間（waittime）は以下の計算式により、３秒と算出される。
【００５７】
10［s］＋waittime×10［回］＞40［s］
Waittime＞3［s］
よって、１回のループ毎に、読み込み待機時間（waittime）として３秒より大きい値を設定すれば、第一受信メッセージの未受信部分よりも先に第二受信メッセージの読み込みを終了させることができる。
【００５８】
以上の処理内容を踏まえ、第一受信メッセージをＳＯＡＰメッセージ１０６とし、第二受信メッセージをＳＯＡＰメッセージ１１４とする。
【００５９】
尚、本実施形態では、ストリームから第一のメッセージを読み込む間隔を読み込み待機時間だけ長くすることで第一のメッセージの読み込み速度を低減させる方法を説明したが、本発明はこの方法に限定されるものではない。
【００６０】
例えば、ストリームから第一のメッセージを読み込む１回の読み込み量（バイト数）を少なくして第一のメッセージの読み込み速度を低減させても良い。この方法によっても、上述した方法と同様に、第二のメッセージを優先的に受信することができる。
【００６１】
本実施形態によれば、ＨＴＴＰなどのアプリケーション層で優先順位制御を行うことで、ネットワーク層やトランスポート層に依存することなく装置自体の汎用性を高めることができる。
【００６２】
また、送信側で第一のメッセージの送信をキャンセルすることなく、受信側で緊急性の高い第二のメッセージを優先的に受信することが可能となる。
【００６３】
［他の実施形態］
次に、本実施形態におけるクライアント１０２及びサーバ１０３として、情報処理装置（コンピュータ）を使用することも可能である。
【００６４】
図６は、クライアント又はサーバとして機能する情報処理装置の構成の一例を示す図である。上述した実施形態の機能を実現するソフトウェアを実行する情報処理装置のハードウェア構成の一例を示している。
【００６５】
情報処理装置は、ハードウェア構成として入力装置６０１と、表示装置６０２と、記憶媒体ドライブ装置６０３と、ＲＯＭ６０５と、ＲＡＭ６０６と、ＣＰＵ又はＭＰＵ６０７と、インターフェース装置６０８と、ＨＤ（ハードディスク）６０９とを含む。入力装置６０１は、情報処理装置の操作者（オペレータ）が操作するキーボード及びマウスなどで構成され、情報処理装置に各種操作情報などを入力するのに用いられる。表示装置６０２は、情報処理装置の操作者が利用するディスプレイなどで構成され、各種情報（又は画面）などを表示するのに用いられる。
【００６６】
インターフェース装置６０８は、情報処理装置をネットワークなどに接続するインターフェースである。上述した処理などに係るプログラムは、例えばＣＤ−ＲＯＭなどの記憶媒体６０４によって情報処理装置に提供されるか、ネットワークなどを通じてダウンロードされる。記憶媒体６０４は、記憶媒体ドライブ装置６０３にセットされ、プログラムが記憶媒体６０４から記憶媒体ドライブ装置６０３を介してＨＤ６０９にインストールされる。
【００６７】
ＲＯＭ６０５は情報処理装置の電源投入時に最初に読み込まれるプログラムなどを格納する。ＲＡＭ６０６は、情報処理装置のメインメモリである。ＣＰＵ６０７は、ＨＤ６０９よりプログラムを読み出して、ＲＡＭ６０６に格納し、プログラムを実行することで、前述の処理内容を実現したりする。ＨＤ６０９は、プログラム以外に、例えばＷＥＢサービスフロー記述文書、ＷＥＢサービスインターフェース記述文書などを格納する。
【００６８】
このプログラムコードを供給するための記録媒体として、例えばフレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭなどを用いることができる。
【００６９】
また、コンピュータが読出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、次の場合も含まれることは言うまでもない。即ち、プログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）などが実際の処理の一部又は全部を行い、その処理により前述した実施形態の機能が実現される場合である。
【００７０】
更に、コンピュータ読み取り可能な記録媒体から読出されたプログラムがコンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれる。その後、そのプログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部又は全部を行い、その処理により、前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【図面の簡単な説明】
【００７１】
【図１】本実施形態におけるクライアントサーバシステムの構成を示す図である。
【図２】プロトコルバインディングヘッダを含むＳＯＡＰメッセージの一例を示す図である。
【図３】本実施形態における優先順位制御部の構成の一例を示す図である。
【図４】本実施形態における優先順位制御を開始する時点での具体的な数値を示す図である。
【図５】ストリーム読み込み制御算出処理部の処理を示すフローチャートである。
【図６】クライアント又はサーバとして機能する情報処理装置の構成の一例を示す図である。
【符号の説明】
【００７２】
１００  優先順位制御部
１０１  優先順位制御部
１０２  クライアント
１０３  サーバ
１０４  アプリケーション
１０６  ＳＯＡＰメッセージ
１０８  サーブレットコンテナ
１１１  サービスロジック
１１４  ＳＯＡＰメッセージ
【図１】
2010041117.tif 000003
【図２】
2010041117.tif 000004
【図３】
2010041117.tif 000005
【図４】
2010041117.tif 000006
【図５】
2010041117.tif 000007
【図６】
2010041117.tif 000008