JP2004139586A - 仲介装置、通信システム、仲介装置の制御方法、プログラム及び記録媒体 - Google Patents
仲介装置、通信システム、仲介装置の制御方法、プログラム及び記録媒体 Download PDFInfo
- Publication number
- JP2004139586A JP2004139586A JP2003332572A JP2003332572A JP2004139586A JP 2004139586 A JP2004139586 A JP 2004139586A JP 2003332572 A JP2003332572 A JP 2003332572A JP 2003332572 A JP2003332572 A JP 2003332572A JP 2004139586 A JP2004139586 A JP 2004139586A
- Authority
- JP
- Japan
- Prior art keywords
- request
- communication
- response
- soap
- communication device
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Information Transfer Between Computers (AREA)
- Computer And Data Communications (AREA)
- Facsimiles In General (AREA)
Abstract
【課題】 ある通信装置が複数の通信装置に動作要求を送信してその動作要求に対する動作応答を受け取るような通信システムを構成する場合において、通信の効率を上げる。
【解決手段】 管理装置102と複数の画像形成装置100との間の通信を仲介する仲介装置101が、各画像形成装置100から、管理装置102からの動作要求に対する動作応答を受信し、その受信した各動作応答を一括して通信要求として管理装置102に送信する。また、その通信要求に対する通信応答として、管理装置102から画像形成装置100宛ての動作要求を複数の一括して受信し、受信した各動作要求を、動作要求毎に分割し、各動作要求に含まれる宛先情報に従って宛先となる画像形成装置100に送信する。
【選択図】 図3
【解決手段】 管理装置102と複数の画像形成装置100との間の通信を仲介する仲介装置101が、各画像形成装置100から、管理装置102からの動作要求に対する動作応答を受信し、その受信した各動作応答を一括して通信要求として管理装置102に送信する。また、その通信要求に対する通信応答として、管理装置102から画像形成装置100宛ての動作要求を複数の一括して受信し、受信した各動作要求を、動作要求毎に分割し、各動作要求に含まれる宛先情報に従って宛先となる画像形成装置100に送信する。
【選択図】 図3
Description
この発明は、第1の通信装置と複数の第2の通信装置との間の通信を仲介する仲介装置、このような仲介装置と上記第1の通信装置と上記複数の第2の通信装置とを備える通信システム、このような仲介装置の制御方法、コンピュータをこのような仲介装置として機能させるためのプログラム、およびこのようなプログラムを記録したコンピュータ読み取り可能な記録媒体に関する。
従来から、通信装置をネットワークを介して接続した通信システムにおいて、通信装置同士で互いにメッセージを交換させることにより、通信相手の装置に対して通知や要求を行わせることが行われている。そして、このようなシステムにおいて、ある装置から別の装置に動作要求としてコマンドを送信して動作を実行させ、送信相手から動作の実行結果を動作応答として返信させることも行われている。
このような技術は、例えば特許文献1に開示されており、この文献には、リモートプロセッサがローカルプロセッサに対して実行されるべきコマンドを指示するメッセージを送信し、そのコマンドに対する応答を受信することが記載されている。
また、この文献には、ローカルプロセッサがファイアウォールの内側に配置されている場合において、ローカルプロセッサからファイアウォールの外側のリモートプロセッサに通信要求を送信し、リモートプロセッサがこの通信要求に対する応答としてローカルプロセッサに対してコマンドを送信するようにすることにより、ファイアウォールの外側から内側に向けてコマンドを送信できるようにする技術も開示されている。
特開2001−273211号公報
また、この文献には、ローカルプロセッサがファイアウォールの内側に配置されている場合において、ローカルプロセッサからファイアウォールの外側のリモートプロセッサに通信要求を送信し、リモートプロセッサがこの通信要求に対する応答としてローカルプロセッサに対してコマンドを送信するようにすることにより、ファイアウォールの外側から内側に向けてコマンドを送信できるようにする技術も開示されている。
また、このような動作要求に関する技術は、通信装置に接続された装置の動作を遠隔制御するシステムにも適用することができる。特許文献2には、ブラインド及び照明を操作する機能を有する遠隔被操作装置に、ユーザからの操作を受け付ける機能を有する遠隔操作装置からコマンドを送信してブラインド及び照明を操作させる遠隔操作システムにこのような技術を適用した例が記載されている。ただし、この文献には、コマンドに対する応答を送信する点は示されていない。
特開2002−135858号公報
ところで、複数の通信装置間でメッセージを交換する場合において、1つの通信装置が、複数の通信装置に対してコマンドを送信する場合が考えられる。そして、このような場合、コマンドを受け付けた各通信装置には、それぞれコマンドの送信元に対してコマンドの実行結果を返すことが求められている。
従来、このような動作を行う場合には、コマンドの宛先となる通信装置と個別に通信を行い、宛先毎にコマンドを送信するようにしていた。また、コマンド応答を受信する際にも、コマンドを送信した各通信装置と個別に通信を行ってコマンド応答を受信するようにしていた。
従来、このような動作を行う場合には、コマンドの宛先となる通信装置と個別に通信を行い、宛先毎にコマンドを送信するようにしていた。また、コマンド応答を受信する際にも、コマンドを送信した各通信装置と個別に通信を行ってコマンド応答を受信するようにしていた。
しかし、このような方式では、当然のことながら、コマンドやコマンド応答を送受信する度に、コマンドの宛先毎にそれぞれ別々に通信のコネクションを確立する必要がある。従って、通信のオーバーヘッドが大きくなり、効率性の点で問題があった。
現状では、ネットワークを介した通信をダイヤルアップ接続で行う環境もまだ多く残っており、このような環境においては上記の点が特に問題となる。このような環境では、コネクションの確立に数十秒単位の時間を要することもあり、またコネクションを確立する毎に料金を課金されるので、コネクションを確立する回数が増加するとコストアップにつながるためである。
現状では、ネットワークを介した通信をダイヤルアップ接続で行う環境もまだ多く残っており、このような環境においては上記の点が特に問題となる。このような環境では、コネクションの確立に数十秒単位の時間を要することもあり、またコネクションを確立する毎に料金を課金されるので、コネクションを確立する回数が増加するとコストアップにつながるためである。
この発明は、このような問題を解決し、ある通信装置が複数の通信装置に動作要求を送信してその動作要求に対する動作応答を受け取る場合において、効率よく通信を行うことができるようにすることを目的とする。
上記の目的を達成するため、この発明の仲介装置は、第1の通信装置と複数の第2の通信装置との間の通信を仲介し、上記第1の通信装置に対して通信要求を送信し、上記第1の通信装置からその通信要求に対する通信応答を受信する仲介装置において、上記各第2の通信装置から、上記第1の通信装置からの動作要求に対する動作応答を受信する個別受信手段と、その個別受信手段が受信した各動作応答を上記通信要求として一括して上記第1の通信装置に送信する一括送信手段と、その通信要求に対する通信応答として、上記第1の通信装置から、上記第2の通信装置宛ての複数の動作要求を一括して受信する一括受信手段と、その受信手段が受信した各動作要求を、その各動作要求に含まれる宛先情報に従って宛先となる第2の通信装置に送信する個別送信手段とを設けたものである。
このような仲介装置において、上記動作要求及び動作応答をそれぞれ、形式を変更せずに複数結合して転送可能な1つのメッセージを生成することができる形式で表現し、また複数結合された状態では形式を変更せずに分割して転送可能な個々の動作要求及び動作応答に戻すことができる形式で表現するとよい。
さらに、上記一括送信手段が上記第1の通信装置に対して定期的に通信要求を送信するようにするとよい。
さらにまた、仲介装置自身宛ての動作要求に係る動作を実行し、実行結果としてその動作要求に対する動作応答を生成する手段を設け、上記一括送信手段を、上記個別受信手段が受信した各動作応答に加え、上記第1の通信装置からの仲介装置自身宛ての動作要求に対する動作応答も上記通信要求として一括して上記第1の通信装置に送信する手段とし、上記一括受信手段を、その通信要求に対する通信応答として、上記第1の通信装置から、上記第2の通信装置宛ての動作要求に加え、仲介装置自身宛ての動作要求も一括して受信する手段とするとよい。
さらに、上記一括送信手段が上記第1の通信装置に対して定期的に通信要求を送信するようにするとよい。
さらにまた、仲介装置自身宛ての動作要求に係る動作を実行し、実行結果としてその動作要求に対する動作応答を生成する手段を設け、上記一括送信手段を、上記個別受信手段が受信した各動作応答に加え、上記第1の通信装置からの仲介装置自身宛ての動作要求に対する動作応答も上記通信要求として一括して上記第1の通信装置に送信する手段とし、上記一括受信手段を、その通信要求に対する通信応答として、上記第1の通信装置から、上記第2の通信装置宛ての動作要求に加え、仲介装置自身宛ての動作要求も一括して受信する手段とするとよい。
また、この発明は、第1の通信装置と複数の第2の通信装置との間の通信を仲介し、上記第1の通信装置に対して通信要求を送信し、上記第1の通信装置からその通信要求に対する通信応答を受信する仲介装置において、上記第1の通信装置からの上記第2の通信装置宛ての動作要求と、その動作要求に対する動作応答とを記憶する記憶手段と、上記動作応答を上記記憶手段から読み出す収集手段と、上記第1の通信装置に対して、上記収集手段が読み出した複数の動作応答を上記通信要求として一括して送信する一括送信手段と、その通信要求に対する通信応答として、上記第1の通信装置から、複数の上記動作要求を一括して受信する一括受信手段と、その一括受信手段が受信した各動作要求を、動作要求毎に分割して上記記憶手段に記憶させる分配手段と、上記各第2の通信装置から、上記動作応答を受信すると共に、受信した動作応答を、その動作応答と対応する動作要求と関連付けて上記記憶手段に記憶させる個別受信手段と、上記動作要求を上記記憶手段から読み出すと共に、読み出した各動作要求を、その動作要求に含まれる宛先情報に従って宛先となる第2の通信装置に送信する個別送信手段とを設けた仲介装置も提供する。
また、この発明は、第1の通信装置と複数の第2の通信装置との間の通信を仲介し、上記第1の通信装置に対してHTTPリクエストを送信し、上記第1の通信装置からそのHTTPリクエストに対するHTTPレスポンスを受信する仲介装置において、上記各第2の通信装置から、上記第1の通信装置からのSOAPリクエストに対するSOAPレスポンスを受信する個別受信手段と、その個別受信手段が受信した各SOAPレスポンスを1つのHTTPリクエストに記載して上記第1の通信装置に送信する一括送信手段と、そのHTTPリクエストに対するHTTPレスポンスとして、上記第1の通信装置から、上記第2の通信装置宛ての複数のSOAPリクエストを1つのHTTPレスポンスに記載した状態で受信する一括受信手段と、その受信手段が受信した各SOAPリクエストを、その各SOAPリクエストに含まれる宛先情報に従って宛先となる第2の通信装置に送信する個別送信手段とを設けた仲介装置も提供する。
このような仲介装置において、上記SOAPリクエスト及びSOAPレスポンスをそれぞれ、形式を変更せずに複数結合して転送可能な1つのメッセージを生成することができる形式で表現し、また複数結合された状態では形式を変更せずに分割して転送可能な個々のSOAPリクエスト及びSOAPレスポンスに戻すことができる形式で表現するようにするとよい。
さらに、上記一括送信手段が上記第1の通信装置に対して定期的にHTTPリクエストを送信するようにするとよい。
さらにまた、仲介装置自身宛てのSOAPリクエストによって要求された動作を実行し、そのSOAPリクエストに対するSOAPレスポンスに記載すべき実行結果を生成する手段を設け、上記一括送信手段を、上記個別受信手段が受信した各SOAPレスポンスに加え、上記第1の通信装置からの仲介装置自身宛てのSOAPリクエストに対するSOAPレスポンスも1つのHTTPリクエストに記載して上記第1の通信装置に送信する手段とし、上記一括受信手段を、そのHTTPリクエストに対するHTTPレスポンスとして、上記第1の通信装置から、上記第2の通信装置宛てのSOAPリクエストに加え、仲介装置自身宛てのSOAPリクエストも1つのHTTPレスポンスに記載した状態で受信する手段とするとよい。
さらに、上記一括送信手段が上記第1の通信装置に対して定期的にHTTPリクエストを送信するようにするとよい。
さらにまた、仲介装置自身宛てのSOAPリクエストによって要求された動作を実行し、そのSOAPリクエストに対するSOAPレスポンスに記載すべき実行結果を生成する手段を設け、上記一括送信手段を、上記個別受信手段が受信した各SOAPレスポンスに加え、上記第1の通信装置からの仲介装置自身宛てのSOAPリクエストに対するSOAPレスポンスも1つのHTTPリクエストに記載して上記第1の通信装置に送信する手段とし、上記一括受信手段を、そのHTTPリクエストに対するHTTPレスポンスとして、上記第1の通信装置から、上記第2の通信装置宛てのSOAPリクエストに加え、仲介装置自身宛てのSOAPリクエストも1つのHTTPレスポンスに記載した状態で受信する手段とするとよい。
さらにまた、この発明は、第1の通信装置と複数の第2の通信装置との間の通信を仲介し、上記第1の通信装置に対してHTTPリクエストを送信し、上記第1の通信装置からそのHTTPリクエストに対するHTTPレスポンスを受信する仲介装置において、上記第1の通信装置からの上記第2の通信装置宛ての動作要求と、その動作要求に対する動作応答とを記憶する記憶手段と、上記動作応答を上記記憶手段から読み出す収集手段と、上記第1の通信装置に対して、上記収集手段が読み出した動作応答の内容を記載した複数のSOAPレスポンスを1つのHTTPリクエストに記載して送信する一括送信手段と、そのHTTPリクエストに対するHTTPレスポンスとして、上記第1の通信装置から、上記動作要求の内容を記載した複数のSOAPリクエストを1つのHTTPレスポンスに記載した状態で受信する一括受信手段と、その一括受信手段が受信した各SOAPリクエストに記載された動作要求の内容を、動作要求毎に分割して上記記憶手段に記憶させる分配手段と、上記各第2の通信装置から、上記動作応答の内容を記載したSOAPレスポンスを受信すると共に、受信したSOAPレスポンスに記載された動作応答の内容を、その動作応答と対応する動作要求と関連付けて上記記憶手段に記憶させる個別受信手段と、上記動作要求を上記記憶手段から読み出すと共に、読み出した各動作要求の内容を記載したSOAPリクエストを、その動作要求に含まれる宛先情報に従って宛先となる第2の通信装置に送信する個別送信手段とを設けたことを特徴とする仲介装置も提供する。
また、この発明の通信システムは、第1の通信装置と、複数の第2の通信装置と、その第1の通信装置と各第2の通信装置との間の通信を仲介する仲介装置とを備え、上記仲介装置が、上記第1の通信装置に対して通信要求を送信し、上記第1の通信装置からその通信要求に対する通信応答を受信する通信システムにおいて、上記第1の通信装置と上記仲介装置との間の通信経路を、上記仲介装置側から通信要求を発した場合のみ通信可能な通信経路とし、上記仲介装置と上記各第2の通信装置との間の通信経路を、上記仲介装置と上記第2の通信装置のどちらから通信要求を行っても通信可能な通信経路とし、上記仲介装置に、上記各第2の通信装置から、上記第1の通信装置からの動作要求に対する動作応答を受信する個別受信手段と、その個別受信手段が受信した各動作応答を上記通信要求として一括して上記第1の通信装置に送信する一括送信手段と、その通信要求に対する通信応答として、上記第1の通信装置から、上記第2の通信装置宛ての複数の動作要求を一括して受信する一括受信手段と、その受信手段が受信した各動作要求を、その各動作要求に含まれる宛先情報に従って宛先となる第2の通信装置に送信する個別送信手段とを設け、上記第1の通信装置に、上記第2の通信装置宛ての動作要求に対する動作応答を上記通信要求として複数一括して上記仲介装置から受信する受信手段と、その通信要求に対する通信応答として、上記第2の通信装置宛ての複数の動作要求を一括して上記仲介装置に送信する送信手段とを設け、上記各第2の通信装置に、上記第1の通信装置からのその第2の通信装置宛ての動作要求を上記仲介装置から受信する受信手段と、その手段が受信した動作要求に係る動作を実行し、実行結果としてその動作要求に対する動作応答を生成する手段と、その手段が生成した動作応答を上記仲介装置に送信する送信手段とを設けたものである。
このような通信システムにおいて、上記動作要求及び動作応答をそれぞれ、形式を変更せずに複数結合して転送可能な1つのメッセージを生成することができる形式で表現し、また複数結合された状態では形式を変更せずに分割して転送可能な個々の動作要求及び動作応答に戻すことができる形式で表現するようにするとよい。
さらに、上記仲介装置において、上記一括送信手段が上記第1の通信装置に対して定期的に通信要求を送信するようにするとよい。
さらにまた、上記仲介装置に、仲介装置自身宛ての動作要求に係る動作を実行し、実行結果としてその動作要求に対する動作応答を生成する手段を設け、その仲介装置において、上記一括送信手段を、上記個別受信手段が受信した各動作応答に加え、上記第1の通信装置からの仲介装置自身宛ての動作要求に対する動作応答も上記通信要求として一括して上記第1の通信装置に送信する手段とし、上記一括受信手段を、その通信要求に対する通信応答として、上記第1の通信装置から、上記第2の通信装置宛ての動作要求に加え、仲介装置自身宛ての動作要求も一括して受信する手段とし、上記第1の通信装置において、上記受信手段を、上記第2の通信装置宛ての動作要求に対する動作応答に加え、上記仲介装置宛ての動作要求に対する動作応答も上記通信要求として一括して上記仲介装置から受信する手段とし、上記送信手段を、その通信要求に対する通信応答として、上記第2の通信装置宛ての動作要求に加え、上記仲介装置宛ての動作要求も一括して上記仲介装置に送信する手段とするとよい。
さらに、上記仲介装置において、上記一括送信手段が上記第1の通信装置に対して定期的に通信要求を送信するようにするとよい。
さらにまた、上記仲介装置に、仲介装置自身宛ての動作要求に係る動作を実行し、実行結果としてその動作要求に対する動作応答を生成する手段を設け、その仲介装置において、上記一括送信手段を、上記個別受信手段が受信した各動作応答に加え、上記第1の通信装置からの仲介装置自身宛ての動作要求に対する動作応答も上記通信要求として一括して上記第1の通信装置に送信する手段とし、上記一括受信手段を、その通信要求に対する通信応答として、上記第1の通信装置から、上記第2の通信装置宛ての動作要求に加え、仲介装置自身宛ての動作要求も一括して受信する手段とし、上記第1の通信装置において、上記受信手段を、上記第2の通信装置宛ての動作要求に対する動作応答に加え、上記仲介装置宛ての動作要求に対する動作応答も上記通信要求として一括して上記仲介装置から受信する手段とし、上記送信手段を、その通信要求に対する通信応答として、上記第2の通信装置宛ての動作要求に加え、上記仲介装置宛ての動作要求も一括して上記仲介装置に送信する手段とするとよい。
また、この発明は、第1の通信装置と、複数の第2の通信装置と、その第1の通信装置と各第2の通信装置との間の通信を仲介する仲介装置とを備え、上記仲介装置が、上記第1の通信装置に対して通信要求を送信し、上記第1の通信装置からその通信要求に対する通信応答を受信する通信システムにおいて、上記第1の通信装置と上記仲介装置との間の通信経路を、上記仲介装置側から通信要求を発した場合のみ通信可能な通信経路とし、上記仲介装置と上記各第2の通信装置との間の通信経路を、上記仲介装置と上記第2の通信装置のどちらから通信要求を行っても通信可能な通信経路とし、上記仲介装置に、上記第1の通信装置からの上記第2の通信装置宛ての動作要求と、その動作要求に対する動作応答とを記憶する記憶手段と、上記動作応答を上記記憶手段から読み出す収集手段と、上記第1の通信装置に対して、上記収集手段が読み出した複数の動作応答を上記通信要求として一括して送信する一括送信手段と、その通信要求に対する通信応答として、上記第1の通信装置から、複数の上記動作要求を一括して受信する一括受信手段と、その一括受信手段が受信した各動作要求を、動作要求毎に分割して上記記憶手段に記憶させる分配手段と、上記各第2の通信装置から、上記動作応答を受信すると共に、受信した動作応答を、その動作応答と対応する動作要求と関連付けて上記記憶手段に記憶させる個別受信手段と、上記動作要求を上記記憶手段から読み出すと共に、読み出した各動作要求を、その動作要求に含まれる宛先情報に従って宛先となる第2の通信装置に送信する個別送信手段とを設け、上記第1の通信装置に、上記動作要求と上記動作応答とを記憶する記憶手段と、上記動作要求を生成して上記記憶手段に記憶させる要求生成手段と、上記仲介装置から、上記動作応答を上記通信要求として複数一括して受信する受信手段と、その受信手段が受信した各動作応答を、それぞれの動作応答と対応する動作要求と関連付けて上記第2の記憶手段に記憶させる分配手段と、上記動作要求を上記記憶手段から読み出す収集手段と、上記受信手段が受信した通信要求に対する通信応答として、上記仲介装置に対して、上記収集手段が読み出した複数の動作要求を一括して送信する送信手段とを設け、上記各第2の通信装置に、上記動作要求を上記仲介装置から受信する受信手段と、その手段が受信した動作要求に係る動作を実行し、実行結果としてその動作要求に対する動作応答を生成する手段と、その手段が生成した動作応答を上記仲介装置に送信する送信手段とを設けた通信システムも提供する。
また、この発明は、第1の通信装置と、複数の第2の通信装置と、その第1の通信装置と各第2の通信装置との間の通信を仲介する仲介装置とを備え、上記仲介装置が、上記第1の通信装置に対してHTTPリクエストを送信し、上記第1の通信装置からそのHTTPリクエストに対するHTTPレスポンスを受信する通信システムにおいて、上記第1の通信装置と上記仲介装置との間の通信経路を、HTTPを用いた通信については、上記仲介装置側からHTTPリクエストを送信した場合のみ通信可能な通信経路とし、上記仲介装置と上記各第2の通信装置との間の通信経路を、上記仲介装置と上記第2の通信装置のどちらからHTTPリクエストを送信しても通信可能な通信経路とし、上記仲介装置に、上記各第2の通信装置から、上記第1の通信装置からのSOAPリクエストに対するSOAPレスポンスを受信する個別受信手段と、その個別受信手段が受信した各SOAPレスポンスを1つのHTTPリクエストに記載して上記第1の通信装置に送信する一括送信手段と、そのHTTPリクエストに対するHTTPレスポンスとして、上記第1の通信装置から、上記第2の通信装置宛ての複数のSOAPリクエストを1つのHTTPレスポンスに記載した状態で受信する一括受信手段と、その受信手段が受信した各SOAPリクエストを、その各SOAPリクエストに含まれる宛先情報に従って宛先となる第2の通信装置に送信する個別送信手段とを設け、上記第1の通信装置に、上記第2の通信装置宛てのSOAPリクエストに対するSOAPレスポンスを複数1つのHTTPリクエストに記載した状態で上記仲介装置から受信する受信手段と、そのHTTPリクエストに対するHTTPレスポンスとして、上記第2の通信装置宛ての複数のSOAPリクエストを1つのHTTPレスポンスに記載して上記仲介装置に送信する送信手段とを設け、上記各第2の通信装置に、上記第1の通信装置からのその第2の通信装置宛てのSOAPリクエストを上記仲介装置から受信する受信手段と、その手段が受信したSOAPリクエストによって要求された動作を実行し、そのSOAPリクエストに対するSOAPレスポンスに記載すべき実行結果を生成する手段と、その手段が生成した実行結果を、上記SOAPリクエストに対するSOAPレスポンスに記載して上記仲介装置に送信する送信手段とを設けた通信システムも提供する。
このような通信システムにおいて、上記SOAPリクエスト及びSOAPレスポンスをそれぞれ、形式を変更せずに複数結合して転送可能な1つのメッセージを生成することができる形式で表現し、また複数結合された状態では形式を変更せずに分割して転送可能な個々のSOAPリクエスト及びSOAPレスポンスに戻すことができる形式で表現するようにするとよい。
さらに、上記仲介装置において、上記一括送信手段が上記第1の通信装置に対して定期的にHTTPリクエストを送信するようするとよい。
さらにまた、上記仲介装置に、仲介装置自身宛てのSOAPリクエストによって要求された動作を実行し、そのSOAPリクエストに対するSOAPレスポンスに記載すべき実行結果を生成する手段を設け、その仲介装置において、上記一括送信手段を、上記個別受信手段が受信した各SOAPレスポンスに加え、上記第1の通信装置からの仲介装置自身宛てのSOAPリクエストに対するSOAPレスポンスも1つのHTTPリクエストに記載して上記第1の通信装置に送信する手段とし、上記一括受信手段を、そのHTTPリクエストに対するHTTPレスポンスとして、上記第1の通信装置から、上記第2の通信装置宛てのSOAPリクエストに加え、仲介装置自身宛てのSOAPリクエストも1つのHTTPレスポンスに記載した状態で受信する手段とし、上記第1の通信装置において、上記受信手段を、上記第2の通信装置宛てのSOAPリクエストに対するSOAPレスポンスに加え、上記仲介装置宛てのSOAPリクエストに対するSOAPレスポンスも1つのHTTPリクエストに記載した状態で上記仲介装置から受信する手段とし、上記送信手段を、そのHTTPリクエストに対するHTTPレスポンスとして、上記第2の通信装置宛てのSOAPリクエストに加え、上記仲介装置宛てのSOAPリクエストも1つのHTTPレスポンスに記載して上記仲介装置に送信する手段とするとよい。
さらに、上記仲介装置において、上記一括送信手段が上記第1の通信装置に対して定期的にHTTPリクエストを送信するようするとよい。
さらにまた、上記仲介装置に、仲介装置自身宛てのSOAPリクエストによって要求された動作を実行し、そのSOAPリクエストに対するSOAPレスポンスに記載すべき実行結果を生成する手段を設け、その仲介装置において、上記一括送信手段を、上記個別受信手段が受信した各SOAPレスポンスに加え、上記第1の通信装置からの仲介装置自身宛てのSOAPリクエストに対するSOAPレスポンスも1つのHTTPリクエストに記載して上記第1の通信装置に送信する手段とし、上記一括受信手段を、そのHTTPリクエストに対するHTTPレスポンスとして、上記第1の通信装置から、上記第2の通信装置宛てのSOAPリクエストに加え、仲介装置自身宛てのSOAPリクエストも1つのHTTPレスポンスに記載した状態で受信する手段とし、上記第1の通信装置において、上記受信手段を、上記第2の通信装置宛てのSOAPリクエストに対するSOAPレスポンスに加え、上記仲介装置宛てのSOAPリクエストに対するSOAPレスポンスも1つのHTTPリクエストに記載した状態で上記仲介装置から受信する手段とし、上記送信手段を、そのHTTPリクエストに対するHTTPレスポンスとして、上記第2の通信装置宛てのSOAPリクエストに加え、上記仲介装置宛てのSOAPリクエストも1つのHTTPレスポンスに記載して上記仲介装置に送信する手段とするとよい。
さらにまた、この発明は、第1の通信装置と、複数の第2の通信装置と、その第1の通信装置と各第2の通信装置との間の通信を仲介する仲介装置とを備え、上記仲介装置が、上記第1の通信装置に対してHTTPリクエストを送信し、上記第1の通信装置からそのHTTPリクエストに対するHTTPレスポンスを受信する通信システムにおいて、上記第1の通信装置と上記仲介装置との間の通信経路を、HTTPを用いた通信については、上記仲介装置側からHTTPリクエストを送信した場合のみ通信可能な通信経路とし、上記仲介装置と上記各第2の通信装置との間の通信経路を、上記仲介装置と上記第2の通信装置のどちらからHTTPリクエストを送信しても通信可能な通信経路とし、上記仲介装置に、上記第1の通信装置からの上記第2の通信装置宛ての動作要求と、その動作要求に対する動作応答とを記憶する記憶手段と、上記動作応答を上記記憶手段から読み出す収集手段と、上記第1の通信装置に対して、上記収集手段が読み出した動作応答の内容を記載した複数のSOAPレスポンスを1つのHTTPリクエストに記載して送信する一括送信手段と、そのHTTPリクエストに対するHTTPレスポンスとして、上記第1の通信装置から、上記動作要求の内容を記載した複数のSOAPリクエストを1つのHTTPレスポンスに記載した状態で受信する一括受信手段と、その一括受信手段が受信した各SOAPリクエストに記載された動作要求の内容を、動作要求毎に分割して上記記憶手段に記憶させる分配手段と、上記各第2の通信装置から、上記動作応答の内容を記載したSOAPレスポンスを受信すると共に、受信したSOAPレスポンスに記載された動作応答の内容を、その動作応答と対応する動作要求と関連付けて上記記憶手段に記憶させる個別受信手段と、上記動作要求を上記記憶手段から読み出すと共に、読み出した各動作要求の内容を記載したSOAPリクエストを、その動作要求に含まれる宛先情報に従って宛先となる第2の通信装置に送信する個別送信手段とを設け、上記第1の通信装置に、上記動作要求と上記動作応答とを記憶する記憶手段と、上記動作要求を生成して上記記憶手段に記憶させる要求生成手段と、上記仲介装置から、上記動作応答の内容を記載したSOAPレスポンスを複数1つのHTTPリクエストに記載した状態で受信する受信手段と、上記受信手段が受信したSOAPレスポンスに記載された各動作応答の内容を、それぞれの動作応答と対応する動作要求と関連付けて上記記憶手段に記憶させる分配手段と、上記動作要求を上記記憶手段から読み出す収集手段と、上記受信手段が受信したHTTPリクエストに対するHTTPレスポンスとして、上記仲介装置に対して、上記収集手段が読み出した動作要求の内容を記載した複数のSOAPリクエストを1つのHTTPレスポンスに記載して送信する送信手段とを設け、上記各第2の通信装置に、上記第1の通信装置からのその第2の通信装置宛てのSOAPリクエストを上記仲介装置から受信する受信手段と、その手段が受信したSOAPリクエストによって要求された動作を実行し、そのSOAPリクエストに対するSOAPレスポンスに記載すべき実行結果を生成する手段と、その手段が生成した実行結果を、上記SOAPリクエストに対するSOAPレスポンスに記載して上記仲介装置に送信する送信手段とを設けた通信システムも提供する。
また、この発明の仲介装置の制御方法は、第1の通信装置と複数の第2の通信装置との間の通信を仲介し、上記第1の通信装置に対して通信要求を送信し、上記第1の通信装置からその通信要求に対する通信応答を受信する仲介装置の制御方法において、上記各第2の通信装置から、上記第1の通信装置からの動作要求に対する動作応答を受信する個別受信手順と、その個別受信手順で受信した各動作応答を上記通信要求として一括して上記第1の通信装置に送信する一括送信手順と、その通信要求に対する通信応答として、上記第1の通信装置から、上記第2の通信装置宛ての複数の動作要求を一括して受信する一括受信手順と、その受信手順で受信した各動作要求を、その各動作要求に含まれる宛先情報に従って宛先となる第2の通信装置に送信する個別送信手順とを上記仲介装置に実行させるようにしたものである。
このような仲介装置の制御方法において、上記動作要求及び動作応答をそれぞれ、形式を変更せずに複数結合して転送可能な1つのメッセージを生成することができる形式で表現し、また複数結合された状態では形式を変更せずに分割して転送可能な個々の動作要求及び動作応答に戻すことができる形式で表現するようにするとよい。
さらに、上記仲介装置に、上記第1の通信装置に対して定期的に通信要求を送信させるようにするとよい。
さらにまた、仲介装置自身宛ての動作要求に係る動作を実行し、実行結果としてその動作要求に対する動作応答を生成する手順をさらに上記仲介装置に実行させ、上記一括送信手順において、上記個別受信手段が受信した各動作応答に加え、上記第1の通信装置からの仲介装置自身宛ての動作要求に対する動作応答も上記通信要求として一括して上記第1の通信装置に送信するようにし、上記一括受信手順において、その通信要求に対する通信応答として、上記第1の通信装置から、上記第2の通信装置宛ての動作要求に加え、仲介装置自身宛ての動作要求も一括して受信するようにするとよい。
さらに、上記仲介装置に、上記第1の通信装置に対して定期的に通信要求を送信させるようにするとよい。
さらにまた、仲介装置自身宛ての動作要求に係る動作を実行し、実行結果としてその動作要求に対する動作応答を生成する手順をさらに上記仲介装置に実行させ、上記一括送信手順において、上記個別受信手段が受信した各動作応答に加え、上記第1の通信装置からの仲介装置自身宛ての動作要求に対する動作応答も上記通信要求として一括して上記第1の通信装置に送信するようにし、上記一括受信手順において、その通信要求に対する通信応答として、上記第1の通信装置から、上記第2の通信装置宛ての動作要求に加え、仲介装置自身宛ての動作要求も一括して受信するようにするとよい。
また、この発明は、第1の通信装置と複数の第2の通信装置との間の通信を仲介し、上記第1の通信装置に対して通信要求を送信し、上記第1の通信装置からその通信要求に対する通信応答を受信する仲介装置の制御方法において、上記第1の通信装置からの上記第2の通信装置宛ての動作要求と、その動作要求に対する動作応答とを記憶する記憶領域を設ける手順と、上記動作応答を上記記憶領域から読み出す収集手順と、上記第1の通信装置に対して、上記収集手順で読み出した複数の動作応答を上記通信要求として一括して送信する一括送信手順と、その通信要求に対する通信応答として、上記第1の通信装置から、複数の上記動作要求を一括して受信する一括受信手順と、その一括受信手順で受信した各動作要求を、動作要求毎に分割して上記第1の記憶領域に記憶させる分配手順と、上記各第2の通信装置から、上記動作応答を受信すると共に、受信した動作応答を、その動作応答と対応する動作要求と関連付けて上記記憶領域に記憶させる個別受信手順と、上記動作要求を上記第1の記憶領域から読み出すと共に、読み出した各動作要求を、その動作要求に含まれる宛先情報に従って宛先となる第2の通信装置に送信する個別送信手順とを上記仲介装置に実行させるようにした仲介装置の制御方法も提供する。
また、この発明は、第1の通信装置と複数の第2の通信装置との間の通信を仲介し、上記第1の通信装置に対してHTTPリクエストを送信し、上記第1の通信装置からそのHTTPリクエストに対するHTTPレスポンスを受信する仲介装置の制御方法において、上記各第2の通信装置から、上記第1の通信装置からのSOAPリクエストに対するSOAPレスポンスを受信する個別受信手順と、その個別受信手順で受信した各SOAPレスポンスを1つのHTTPリクエストに記載して上記第1の通信装置に送信する一括送信手順と、そのHTTPリクエストに対するHTTPレスポンスとして、上記第1の通信装置から、上記第2の通信装置宛ての複数のSOAPリクエストを1つのHTTPレスポンスに記載した状態で受信する一括受信手順と、その受信手順で受信した各SOAPリクエストを、その各SOAPリクエストに含まれる宛先情報に従って宛先となる第2の通信装置に送信する個別送信手順とを上記仲介装置に実行させるようにした仲介装置の制御方法も提供する。
このような仲介装置の制御方法において、上記SOAPリクエスト及びSOAPレスポンスをそれぞれ、形式を変更せずに複数結合して転送可能な1つのメッセージを生成することができる形式で表現し、また複数結合された状態では形式を変更せずに分割して転送可能な個々のSOAPリクエスト及びSOAPレスポンスに戻すことができる形式で表現するようにするとよい。
さらに、上記仲介装置に、上記第1の通信装置に対して定期的にHTTPリクエストを送信させるようにするとよい。
さらにまた、仲介装置自身宛てのSOAPリクエストによって要求された動作を実行し、そのSOAPリクエストに対するSOAPレスポンスに記載すべき実行結果を生成する手順をさらに上記仲介装置に実行させ、上記一括送信手順において、上記個別受信手段が受信した各SOAPレスポンスに加え、上記第1の通信装置からの仲介装置自身宛てのSOAPリクエストに対するSOAPレスポンスも1つのHTTPリクエストに記載して上記第1の通信装置に送信するようにし、上記一括受信手順において、そのHTTPリクエストに対するHTTPレスポンスとして、上記第1の通信装置から、上記第2の通信装置宛てのSOAPリクエストに加え、仲介装置自身宛てのSOAPリクエストも1つのHTTPレスポンスに記載した状態で受信するようにするとよい。
さらに、上記仲介装置に、上記第1の通信装置に対して定期的にHTTPリクエストを送信させるようにするとよい。
さらにまた、仲介装置自身宛てのSOAPリクエストによって要求された動作を実行し、そのSOAPリクエストに対するSOAPレスポンスに記載すべき実行結果を生成する手順をさらに上記仲介装置に実行させ、上記一括送信手順において、上記個別受信手段が受信した各SOAPレスポンスに加え、上記第1の通信装置からの仲介装置自身宛てのSOAPリクエストに対するSOAPレスポンスも1つのHTTPリクエストに記載して上記第1の通信装置に送信するようにし、上記一括受信手順において、そのHTTPリクエストに対するHTTPレスポンスとして、上記第1の通信装置から、上記第2の通信装置宛てのSOAPリクエストに加え、仲介装置自身宛てのSOAPリクエストも1つのHTTPレスポンスに記載した状態で受信するようにするとよい。
さらにまた、この発明は、第1の通信装置と複数の第2の通信装置との間の通信を仲介し、上記第1の通信装置に対してHTTPリクエストを送信し、上記第1の通信装置からそのHTTPリクエストに対するHTTPレスポンスを受信する仲介装置の制御方法において、上記第1の通信装置からの上記第2の通信装置宛ての動作要求と、その動作要求に対する動作応答とを記憶する記憶領域を設ける手順と、上記動作応答を上記記憶領域から読み出す収集手順と、上記第1の通信装置に対して、上記収集手順で読み出した動作応答の内容を記載した複数のSOAPレスポンスを1つのHTTPリクエストに記載して送信する一括送信手順と、そのHTTPリクエストに対するHTTPレスポンスとして、上記第1の通信装置から、上記動作要求の内容を記載した複数のSOAPリクエストを1つのHTTPレスポンスに記載した状態で受信する一括受信手順と、その一括受信手順で受信した各SOAPリクエストに記載された動作要求の内容を、動作要求毎に分割して上記記憶領域に記憶させる分配手順と、上記各第2の通信装置から、上記動作応答の内容を記載したSOAPレスポンスを受信すると共に、受信したSOAPレスポンスに記載された動作応答の内容を、その動作応答と対応する動作要求と関連付けて上記記憶領域に記憶させる個別受信手順と、上記動作要求を上記記憶領域から読み出すと共に、読み出した各動作要求の内容を記載したSOAPリクエストを、その動作要求に含まれる宛先情報に従って宛先となる第2の通信装置に送信する個別送信手順とを上記仲介装置に実行させるようにした仲介装置の制御方法も提供する。
また、この発明のプログラムは、コンピュータを、第1の通信装置と複数の第2の通信装置との間の通信を仲介し、上記第1の通信装置に対して通信要求を送信し、上記第1の通信装置からその通信要求に対する通信応答を受信する仲介装置として機能させるためのプログラムにおいて、上記コンピュータを、上記各第2の通信装置から、上記第1の通信装置からの動作要求に対する動作応答を受信する個別受信手段と、その個別受信手段が受信した各動作応答を上記通信要求として一括して上記第1の通信装置に送信する一括送信手段と、その通信要求に対する通信応答として、上記第1の通信装置から、上記第2の通信装置宛ての複数の動作要求を一括して受信する一括受信手段と、その受信手段が受信した各動作要求を、その各動作要求に含まれる宛先情報に従って宛先となる第2の通信装置に送信する個別送信手段として機能させるためのプログラムである。
このようなプログラムにおいて上記動作要求及び動作応答をそれぞれ、形式を変更せずに複数結合して転送可能な1つのメッセージを生成することができる形式で表現し、また複数結合された状態では形式を変更せずに分割して転送可能な個々の動作要求及び動作応答に戻すことができる形式で表現するようにしたことを特徴とするプログラム。
さらに、上記一括送信手段に、上記第1の通信装置に対して定期的に通信要求を送信する機能を設けるとよい。
さらにまた、上記コンピュータを、上記仲介装置宛ての動作要求に係る動作を実行し、実行結果としてその動作要求に対する動作応答を生成する手段として機能させるためのプログラムを含め、上記一括送信手段の機能を、上記個別受信手段が受信した各動作応答に加え、上記第1の通信装置からの上記仲介装置宛ての動作要求に対する動作応答も上記通信要求として一括して上記第1の通信装置に送信する機能とし、上記一括受信手段の機能を、その通信要求に対する通信応答として、上記第1の通信装置から、上記第2の通信装置宛ての動作要求に加え、上記仲介装置宛ての動作要求も一括して受信する機能とするとよい。
さらに、上記一括送信手段に、上記第1の通信装置に対して定期的に通信要求を送信する機能を設けるとよい。
さらにまた、上記コンピュータを、上記仲介装置宛ての動作要求に係る動作を実行し、実行結果としてその動作要求に対する動作応答を生成する手段として機能させるためのプログラムを含め、上記一括送信手段の機能を、上記個別受信手段が受信した各動作応答に加え、上記第1の通信装置からの上記仲介装置宛ての動作要求に対する動作応答も上記通信要求として一括して上記第1の通信装置に送信する機能とし、上記一括受信手段の機能を、その通信要求に対する通信応答として、上記第1の通信装置から、上記第2の通信装置宛ての動作要求に加え、上記仲介装置宛ての動作要求も一括して受信する機能とするとよい。
また、この発明は、コンピュータを、第1の通信装置と複数の第2の通信装置との間の通信を仲介し、上記第1の通信装置に対して通信要求を送信し、上記第1の通信装置からその通信要求に対する通信応答を受信する仲介装置として機能させるためのプログラムにおいて、上記コンピュータを、上記第1の通信装置からの上記第2の通信装置宛ての動作要求と、その動作要求に対する動作応答とを記憶する記憶手段と、上記動作応答を上記記憶手段から読み出す収集手段と、上記第1の通信装置に対して、上記収集手段が読み出した複数の動作応答を上記通信要求として一括して送信する一括送信手段と、その通信要求に対する通信応答として、上記第1の通信装置から、複数の上記動作要求を一括して受信する一括受信手段と、その一括受信手段が受信した各動作要求を、動作要求毎に分割して上記記憶手段に記憶させる分配手段と、上記各第2の通信装置から、上記動作応答を受信すると共に、受信した動作応答を、その動作応答と対応する動作要求と関連付けて上記記憶手段に記憶させる個別受信手段と、上記動作要求を上記記憶手段から読み出すと共に、読み出した各動作要求を、その動作要求に含まれる宛先情報に従って宛先となる第2の通信装置に送信する個別送信手段として機能させるためのプログラムも提供する。
また、この発明は、コンピュータを、第1の通信装置と複数の第2の通信装置との間の通信を仲介し、上記第1の通信装置に対してHTTPリクエストを送信し、上記第1の通信装置からそのHTTPリクエストに対するHTTPレスポンスを受信する仲介装置として機能させるためのプログラムにおいて、上記コンピュータを、上記各第2の通信装置から、上記第1の通信装置からのSOAPリクエストに対するSOAPレスポンスを受信する個別受信手段と、その個別受信手段が受信した各SOAPレスポンスを1つのHTTPリクエストに記載して上記第1の通信装置に送信する一括送信手段と、そのHTTPリクエストに対するHTTPレスポンスとして、上記第1の通信装置から、上記第2の通信装置宛ての複数のSOAPリクエストを1つのHTTPレスポンスに記載した状態で受信する一括受信手段と、その受信手段が受信した各SOAPリクエストを、その各SOAPリクエストに含まれる宛先情報に従って宛先となる第2の通信装置に送信する個別送信手段として機能させるためのプログラムも提供する。
このようなプログラムにおいて、上記SOAPリクエスト及びSOAPレスポンスをそれぞれ、形式を変更せずに複数結合して転送可能な1つのメッセージを生成することができる形式で表現し、また複数結合された状態では形式を変更せずに分割して転送可能な個々のSOAPリクエスト及びSOAPレスポンスに戻すことができる形式で表現するようにするとよい。
さらに、上記一括送信手段に、上記第1の通信装置に対して定期的にHTTPリクエストを送信する機能を設けるとよい。
さらにまた、上記コンピュータを、上記仲介装置宛てのSOAPリクエストによって要求された動作を実行し、そのSOAPリクエストに対するSOAPレスポンスに記載すべき実行結果を生成する手段として機能させるためのプログラムを含め、上記一括送信手段の機能を、上記個別受信手段が受信した各SOAPレスポンスに加え、上記第1の通信装置からの上記仲介装置宛てのSOAPリクエストに対するSOAPレスポンスも1つのHTTPリクエストに記載して上記第1の通信装置に送信する機能とし、上記一括受信手段の機能を、そのHTTPリクエストに対するHTTPレスポンスとして、上記第1の通信装置から、上記第2の通信装置宛てのSOAPリクエストに加え、上記仲介装置宛てのSOAPリクエストも1つのHTTPレスポンスに記載した状態で受信する機能とするとよい。
さらに、上記一括送信手段に、上記第1の通信装置に対して定期的にHTTPリクエストを送信する機能を設けるとよい。
さらにまた、上記コンピュータを、上記仲介装置宛てのSOAPリクエストによって要求された動作を実行し、そのSOAPリクエストに対するSOAPレスポンスに記載すべき実行結果を生成する手段として機能させるためのプログラムを含め、上記一括送信手段の機能を、上記個別受信手段が受信した各SOAPレスポンスに加え、上記第1の通信装置からの上記仲介装置宛てのSOAPリクエストに対するSOAPレスポンスも1つのHTTPリクエストに記載して上記第1の通信装置に送信する機能とし、上記一括受信手段の機能を、そのHTTPリクエストに対するHTTPレスポンスとして、上記第1の通信装置から、上記第2の通信装置宛てのSOAPリクエストに加え、上記仲介装置宛てのSOAPリクエストも1つのHTTPレスポンスに記載した状態で受信する機能とするとよい。
さらにまた、この発明は、コンピュータを、第1の通信装置と複数の第2の通信装置との間の通信を仲介し、上記第1の通信装置に対してHTTPリクエストを送信し、上記第1の通信装置からそのHTTPリクエストに対するHTTPレスポンスを受信する仲介装置として機能させるためのプログラムにおいて、上記コンピュータを、上記第1の通信装置からの上記第2の通信装置宛ての動作要求と、その動作要求に対する動作応答とを記憶する記憶手段と、上記動作応答を上記記憶手段から読み出す収集手段と、上記第1の通信装置に対して、上記収集手段が読み出した動作応答の内容を記載した複数のSOAPレスポンスを1つのHTTPリクエストに記載して送信する一括送信手段と、そのHTTPリクエストに対するHTTPレスポンスとして、上記第1の通信装置から、上記動作要求の内容を記載した複数のSOAPリクエストを1つのHTTPレスポンスに記載した状態で受信する一括受信手段と、その一括受信手段が受信した各SOAPリクエストに記載された動作要求の内容を、動作要求毎に分割して上記記憶手段に記憶させる分配手段と、上記各第2の通信装置から、上記動作応答の内容を記載したSOAPレスポンスを受信すると共に、受信したSOAPレスポンスに記載された動作応答の内容を、その動作応答と対応する動作要求と関連付けて上記記憶手段に記憶させる個別受信手段と、上記動作要求を上記記憶手段から読み出すと共に、読み出した各動作要求の内容を記載したSOAPリクエストを、その動作要求に含まれる宛先情報に従って宛先となる第2の通信装置に送信する個別送信手段として機能させるためのプログラムも提供する。
また、この発明の記録媒体は、上記のいずれかのプログラムを記録したコンピュータ読み取り可能な記録媒体である。
以上のようなこの発明の仲介装置、通信システム、又は仲介装置の制御方法によれば、ある通信装置が複数の通信装置に動作要求を送信してその動作要求に対する動作応答を受け取るような通信システムを構成する場合において、通信装置間の通信を適切に仲介することにより、通信の効率を上げることができる。また、この発明のプログラムによれば、コンピュータを上記の仲介装置として機能させてその特徴を実現し、同様な効果を得ることができる。この発明の記録媒体によれば、上記のプログラムを記憶していないコンピュータにそのプログラムを読み出させて実行させ、上記の効果を得ることができる。
以下、この発明を実施するための最良の形態について、図面を参照して説明する。
〔第1の実施形態〕
まず、この発明の仲介装置及びその仲介装置を用いて構成した通信システムの第1の実施形態について説明する。図1は、その通信システムの構成を示すブロック図である。
図1に示すように、この通信システムは、第1の通信装置である管理装置102と、第2の通信装置である複数の被管理装置10と、これらの間の通信を仲介する仲介装置101及び被管理仲介装置101を備える。そして、このうち仲介装置101,被管理仲介装置110及び被管理装置10をユーザ側の設置環境に配置し、これらと管理装置102とがインターネット103を介して通信可能な構成としている。そして、管理装置102が各被管理装置10と通信を行って各被管理装置10を集中的に遠隔管理する遠隔管理システムを構成している。
〔第1の実施形態〕
まず、この発明の仲介装置及びその仲介装置を用いて構成した通信システムの第1の実施形態について説明する。図1は、その通信システムの構成を示すブロック図である。
図1に示すように、この通信システムは、第1の通信装置である管理装置102と、第2の通信装置である複数の被管理装置10と、これらの間の通信を仲介する仲介装置101及び被管理仲介装置101を備える。そして、このうち仲介装置101,被管理仲介装置110及び被管理装置10をユーザ側の設置環境に配置し、これらと管理装置102とがインターネット103を介して通信可能な構成としている。そして、管理装置102が各被管理装置10と通信を行って各被管理装置10を集中的に遠隔管理する遠隔管理システムを構成している。
なお、被管理装置10としては、種々の電子装置に通信機能を設けた通信装置が考えられ、例えば、プリンタ,FAX装置,デジタル複写機,スキャナ装置,デジタル複合機等の画像処理装置や、ネットワーク家電,自動販売機,医療機器,電源装置,空調システム,ガス・水道・電気等の計量システム等に通信機能を持たせた通信装置が考えられる。
ところで、この通信システムにおいて、各設置環境内の仲介装置101と被管理装置10および被管理仲介装置110は、互いにLAN(ローカルエリアネットワーク)によって接続し、これを介して通信可能としている。そして、セキュリティ面を考慮し、ファイアウォール104を介してLANをインターネット103に接続している。
ところで、この通信システムにおいて、各設置環境内の仲介装置101と被管理装置10および被管理仲介装置110は、互いにLAN(ローカルエリアネットワーク)によって接続し、これを介して通信可能としている。そして、セキュリティ面を考慮し、ファイアウォール104を介してLANをインターネット103に接続している。
ここで、ファイアウォール104は通常は外部からの通信要求を遮断するよう設定されているため、管理装置102は、HTTP(Hyper Text Transfer Protocol)リクエストのような通信要求を送信するだけではファイアウォール104の内側の被管理装置10に情報を送信することができない。従って、管理装置102と被管理装置10とが情報を授受するためには、特殊なプロトコルを採用する必要があるが、各被管理装置10をこのプロトコルに対応させるためには、手間やコストがかかる。そこで、被管理装置10には一般的な通信プロトコルを採用してLAN内での(ファイアウォールを挟まない)通信のみに対応させる一方、上記の特殊なプロトコルに対応した仲介装置101を設け、管理装置102と被管理装置10の間の通信を仲介させることにより、特殊なプロトコルに対応していない被管理装置10と管理装置102との間での情報の授受を可能としている。
なお、仲介装置101と被管理装置10との接続は、LANに限らず、RS−485規格等に準拠したシリアル接続や、SCSI(Small Computer System Interface)規格等に準拠したパラレル接続等によって行ってもよい。例えばRS−485規格の場合には、仲介装置101に直列に5台までの被管理装置10を接続することができる。
また、これらの仲介装置101、被管理装置10及び被管理仲介装置110は、その利用環境に応じて多様な階層構造を成す。
また、これらの仲介装置101、被管理装置10及び被管理仲介装置110は、その利用環境に応じて多様な階層構造を成す。
例えば、図1に示す設置環境Aでは、管理装置102とHTTPによる直接的なコネクションを確立できる仲介装置101aが、被管理装置10a及び10bを従える単純な階層構造になっているが、同図に示す設置環境Bでは、4台の被管理装置10を設置するため、1台の仲介装置101を設置しただけでは負荷が大きくなる。そのため、管理装置102とHTTPによる直接的なコネクションを確立できる仲介装置101bが、被管理装置10c及び10dだけでなく、他の仲介装置として被管理仲介装置110を従え、この被管理仲介装置110が被管理装置10e及び10fを更に従えるという階層構造を形成している。この場合、被管理装置10e及び10fを遠隔管理するために管理装置102から発せられた情報は、仲介装置101bとその下位のノードである被管理仲介装置110とを経由して、被管理装置10e又は10fに到達することになる。
また、このような通信システムにおいて、仲介装置101は、これに接続された被管理装置10の制御管理のためのアプリケーションプログラムを実装している。管理装置102は、各仲介装置101の制御管理、更にはこの仲介装置101を介した被管理装置10及び被管理仲介装置110の制御管理を行うためのアプリケーションプログラムを実装している。そして、被管理装置10も含め、この遠隔管理システムにおけるこれら各ノードは、RPC(remote procedure call)により、相互の実装するアプリケーションプログラムのメソッドに対する処理の依頼である「動作要求」を送信し、この依頼された処理の結果である「動作応答」を取得することができるようになっている。
即ち、管理装置102は、被管理装置10や仲介装置101への動作要求(以下、管理装置側動作要求という)を生成してこれを被管理装置10や仲介装置101へ引き渡し、この動作要求に対する動作応答を取得できる一方で、被管理装置10は、管理装置102への動作要求(以下、被管理装置側要求という)を生成してこれを管理装置102へ引き渡し、この動作要求に対する動作応答を取得できるようになっている。また、仲介装置101も、管理装置102への動作要求(以下、仲介装置側要求という)を生成してこれを管理装置102へ引き渡し、この動作要求に対する動作応答を取得できるようになっている。
なお、ここではメソッドを、入力と出力の形式を規定した論理的な関数として定義するものとする。そしてこの場合、動作要求はこの関数を呼び出す関数呼び出し(Procedure Call)となり、動作応答はその関数呼び出しによって呼び出された関数の実行結果となる。動作要求による要求の内容には、意味のある実行結果を伴わない通知も含まれる。
図2に、これらの動作要求と動作応答の関係を示す。なお、この図においてはファイアウォール104の存在は考慮していない。
図2(A)は、被管理装置10で管理装置102に対する動作要求が発生したケースである。このケースでは、被管理装置10が被管理装置側動作要求aを生成し、これを仲介装置101を経由して受け取った管理装置102がこの動作要求に対する動作応答aを返すというモデルになる。また、図に示す仲介装置101が複数であるケースも想定できる(例えば被管理装置が図1に示した被管理装置10e又は10fの場合)。なお、被管理装置側動作要求aは、管理装置102に送信される動作要求であるから、管理装置「宛て」の動作要求と言うことができる。
図2(A)は、被管理装置10で管理装置102に対する動作要求が発生したケースである。このケースでは、被管理装置10が被管理装置側動作要求aを生成し、これを仲介装置101を経由して受け取った管理装置102がこの動作要求に対する動作応答aを返すというモデルになる。また、図に示す仲介装置101が複数であるケースも想定できる(例えば被管理装置が図1に示した被管理装置10e又は10fの場合)。なお、被管理装置側動作要求aは、管理装置102に送信される動作要求であるから、管理装置「宛て」の動作要求と言うことができる。
また、図2(A)では、応答aだけでなく遅延通知a′を返信するケースも表記している。これは管理装置102が、接続してきた仲介装置101から被管理装置側動作要求aを受け取って、これとの接続中にその動作要求に対する応答を返せないと判断したときには、応答が遅延する旨を通知して一旦接続状態を切断し、後の接続の際に上記動作要求に対する応答を改めて引き渡す構成になっているためである。
図2(B)は、仲介装置101で管理装置102に対する動作要求が発生したケースである。このケースでは、仲介装置101が、例えば、仲介装置側動作要求bを生成し、これを受け取った管理装置102が、その動作要求に対する動作応答bを返すというモデルになる。なお、図2(B)のケースでも、応答を即座に返せないときに遅延通知b′を返すことは図2(A)のケースと同様である。
図2(C)は、管理装置102で、被管理装置10に対する動作要求が発生したケースである。このケースでは、管理装置102が管理装置側動作要求cを生成し、これを仲介装置101を経由して受け取った被管理装置10が、その動作要求に対する動作応答cを返すというモデルになる。なお、被管理装置10が使用する一般的な通信プロトコルは、遅延通知を返す機能を有していないが、仲介装置101が代わって遅延通知を行うことは考えられる(図示は省略した)。
図2(D)は、管理装置102で仲介装置101に対する動作要求が発生したケースである。このケースでは、管理装置102が管理装置側動作要求dを生成し、これを受け取った仲介装置101が、その動作要求に対する動作応答dを返すというモデルになる。なお、図2(D)のケースでは、図2(A)のケースと同様に、応答を即座に返せないときに遅延通知d′を返す。
なお、ここではRPCによる引数並びに戻り値の受け渡しのプロトコルとしてSOAP(Simple Object Access Protocol)を採用し、上記の動作要求や動作応答は、ここではSOAPメッセージとして記載するようにしている。
なお、ここではRPCによる引数並びに戻り値の受け渡しのプロトコルとしてSOAP(Simple Object Access Protocol)を採用し、上記の動作要求や動作応答は、ここではSOAPメッセージとして記載するようにしている。
この発明の特徴は、このように管理装置102のような通信装置が被管理装置10のような複数の通信相手との間で互いに動作要求及び受信した動作要求に対する動作応答を送受信する場合において、その送受信を仲介する仲介装置を設け、その仲介装置が、上記通信装置から各通信相手に宛てた動作要求や動作応答を一括して受信すると共にこれを分割して各宛先に転送し、また上記通信相手から上記通信装置に宛てた動作要求や動作応答を収集すると共にこれらを一括して上記通信装置に転送するようにする点である。ここで、動作要求は上記通信装置からのみ送信し、上記通信相手はこの動作要求に対する動作応答のみを上記通信装置に送信する構成であっても、この発明を適用することができる。
そして、実際に動作要求や動作応答を転送するための通信プロトコルとしては、システムの構成に合わせて適当なものを採用することができ、例えばHTTP(HyperText Transfer Protocol)やSMTP(Simple Mail Transfer Protocol)を採用することができる。ここでは、通信プロトコルにHTTPを採用する場合の実施形態を示しており、SMTPを採用する場合については後の実施形態で説明する。
まず、この第1の実施形態について、より具体的な実施例を用いて説明する。
まず、この第1の実施形態について、より具体的な実施例を用いて説明する。
〔第1の実施例:図3乃至図41〕
ここでは、図1に示した通信システムのより具体的な実施例として、第1の通信装置である管理装置によってそれぞれ第2の通信装置である複数の画像形成装置の遠隔管理を行い、これらの装置間の通信をこの発明の仲介装置によって仲介する遠隔管理システムについて説明する。図3は、その遠隔管理システムの構成の一例を示す概念図であるが、被管理装置10を画像形成装置100に変更した点が図1と相違するのみであるので、システムの全体構成についての説明は省略する。
画像形成装置100は、コピー、ファクシミリ、スキャナ等の機能及び外部装置と通信を行う機能を備えたデジタル複合機であり、それらの機能に係るサービスを提供するためのアプリケーションプログラムを実装しているものである。
ここでは、図1に示した通信システムのより具体的な実施例として、第1の通信装置である管理装置によってそれぞれ第2の通信装置である複数の画像形成装置の遠隔管理を行い、これらの装置間の通信をこの発明の仲介装置によって仲介する遠隔管理システムについて説明する。図3は、その遠隔管理システムの構成の一例を示す概念図であるが、被管理装置10を画像形成装置100に変更した点が図1と相違するのみであるので、システムの全体構成についての説明は省略する。
画像形成装置100は、コピー、ファクシミリ、スキャナ等の機能及び外部装置と通信を行う機能を備えたデジタル複合機であり、それらの機能に係るサービスを提供するためのアプリケーションプログラムを実装しているものである。
また、図1に示した通信システムの場合と同様に、仲介装置101は、これに接続された画像形成装置100の制御管理のためのアプリケーションプログラムを実装している。管理装置102は、各仲介装置101の制御管理、更にはこの仲介装置101を介した画像形成装置100及び被管理仲介装置110の制御管理を行うためのアプリケーションプログラムを実装している。そして、RPC(remote procedure call)により、相互の実装するアプリケーションプログラムのメソッドに対する処理の依頼である「動作要求」を送信し、この依頼された処理の結果である「動作応答」を取得することができるようになっている。
図4に、これらの動作要求と動作応答の関係を示す。なお、この図においてもファイアウォール104の存在は考慮していない。
図4(A)は、画像形成装置100で管理装置102に対する動作要求が発生したケースである。このケースでは、画像形成装置100が画像形成装置側動作要求a(第2の動作要求に該当する。以下、「画像機器コマンド」とも呼ぶ)を生成し、これを仲介装置101を経由して受け取った管理装置102がこのコマンドに対する動作応答a(第2の動作応答に該当する。以下、「コマンド応答」あるいは単に「応答」とも呼ぶ)を返すというモデルになる。また、図に示す仲介装置101が複数であるケースも想定できる。なお、応答を即座に返せないときに遅延通知a′を返信することは、図2(A)のケースと同様である。
ただし、画像形成装置100は遅延通知に対応していないため、遅延通知a′の送信は仲介装置101までとして、所定時間内に画像形成装置100に動作応答aを返せない場合には処理をタイムアウトさせるようにしている。
図4(A)は、画像形成装置100で管理装置102に対する動作要求が発生したケースである。このケースでは、画像形成装置100が画像形成装置側動作要求a(第2の動作要求に該当する。以下、「画像機器コマンド」とも呼ぶ)を生成し、これを仲介装置101を経由して受け取った管理装置102がこのコマンドに対する動作応答a(第2の動作応答に該当する。以下、「コマンド応答」あるいは単に「応答」とも呼ぶ)を返すというモデルになる。また、図に示す仲介装置101が複数であるケースも想定できる。なお、応答を即座に返せないときに遅延通知a′を返信することは、図2(A)のケースと同様である。
ただし、画像形成装置100は遅延通知に対応していないため、遅延通知a′の送信は仲介装置101までとして、所定時間内に画像形成装置100に動作応答aを返せない場合には処理をタイムアウトさせるようにしている。
図4(B)は、仲介装置101で管理装置102に対する動作要求が発生したケースである。このケースでは、仲介装置101が、例えば、仲介装置側動作要求b(以下、「仲介装置コマンド」とも呼ぶ)を生成し、これを受け取った管理装置102が、そのコマンドに対する動作応答bを返すというモデルになる。応答を即座に返せないときに遅延通知b′を返すことは、図2(A)のケースと同様である。
図4(C)は、管理装置102で、画像形成装置100に対する動作要求が発生したケースである。このケースでは、管理装置102が管理装置側動作要求c(第1の動作要求に該当する。以下、「管理装置コマンド」とも呼ぶ)を生成し、これを仲介装置101を経由して受け取った画像形成装置100が、その動作要求に対する動作応答c(第1の動作応答に該当する)を返すというモデルになる。なお、画像形成装置100が遅延通知を返す機能を有していないことは、図2(C)のケースと同様である。
図4(D)は、管理装置102で仲介装置101に対する動作要求が発生したケースである。このケースでは、管理装置102が管理装置側動作要求(管理装置コマンド)dを生成し、これを受け取った仲介装置101が、そのコマンドに対する動作応答dを返すというモデルになる。なお、図4(D)のケースでは、図2(A)のケースと同様に、応答を即座に返せないときに遅延通知d′を返す。
このように、動作要求及び動作応答は、RPCのレベルでは、画像形成装置100と管理装置102との間及び仲介装置101と管理装置102との間で対称に取り扱われるものである。しかし、通信のレベルでは対称ではない。
このように、動作要求及び動作応答は、RPCのレベルでは、画像形成装置100と管理装置102との間及び仲介装置101と管理装置102との間で対称に取り扱われるものである。しかし、通信のレベルでは対称ではない。
次に、この通信システムにおける通信シーケンスについて説明する。
まず、図5に画像形成装置と仲介装置との間の通信シーケンスの例を示す。
この図に示すように、画像形成装置100と仲介装置101とは、通信要求であるHTTPリクエストと、その通信要求に対する通信応答であるHTTPリクエストとを、互いに送受信することによって通信を行っている。そして、画像形成装置100と仲介装置101との間にはファイアウォールがないため、画像形成装置100と仲介装置101のどちらがHTTPリクエストを送信しても(通信サーバとして機能しても)通信を行うことができる。例えば、仲介装置101が送信したHTTPリクエストXに対して画像形成装置100がHTTPレスポンスXを返すこともできるし、画像形成装置100が送信したHTTPリクエストZに対して仲介装置101がHTTPレスポンスZを返すこともできるという具合である。
まず、図5に画像形成装置と仲介装置との間の通信シーケンスの例を示す。
この図に示すように、画像形成装置100と仲介装置101とは、通信要求であるHTTPリクエストと、その通信要求に対する通信応答であるHTTPリクエストとを、互いに送受信することによって通信を行っている。そして、画像形成装置100と仲介装置101との間にはファイアウォールがないため、画像形成装置100と仲介装置101のどちらがHTTPリクエストを送信しても(通信サーバとして機能しても)通信を行うことができる。例えば、仲介装置101が送信したHTTPリクエストXに対して画像形成装置100がHTTPレスポンスXを返すこともできるし、画像形成装置100が送信したHTTPリクエストZに対して仲介装置101がHTTPレスポンスZを返すこともできるという具合である。
また、上述したように、画像形成装置100は、管理装置コマンドを仲介装置101を経由して受け取るが、この場合、仲介装置101がHTTPリクエストに管理装置コマンドを記載して画像形成装置100に送信する(HTTPリクエストX,Y)。そして、画像形成装置100は、この管理装置コマンドに対する応答を、そのHTTPリクエストに対するHTTPレスポンスに記載して送信する(HTTPレスポンスX,Y)。
また、逆に画像形成装置100が画像機器コマンドを仲介装置101を介して管理装置102に送信する場合には、画像形成装置100がHTTPリクエストに画像機器コマンドを記載して仲介装置101に送信し(HTTPリクエストZ)、仲介装置101は、この画像機器コマンドに対する応答を、そのHTTPリクエストに対するHTTPレスポンスに記載して送信する(HTTPレスポンスZ)。
また、逆に画像形成装置100が画像機器コマンドを仲介装置101を介して管理装置102に送信する場合には、画像形成装置100がHTTPリクエストに画像機器コマンドを記載して仲介装置101に送信し(HTTPリクエストZ)、仲介装置101は、この画像機器コマンドに対する応答を、そのHTTPリクエストに対するHTTPレスポンスに記載して送信する(HTTPレスポンスZ)。
なお、後者の場合には、仲介装置101が管理装置102に画像機器コマンドを転送し、処理を実行させて応答を受け取るまでに時間がかかることも考えられるので、以下のような手順とすることも考えられる。
すなわち、画像形成装置100がHTTPリクエストに画像機器コマンドを記載して仲介装置101に送信し(HTTPリクエストZ′)、これに対して仲介装置101はHTTPレスポンスにコマンドの受付通知を記載して返信し(HTTPレスポンスZ)、コマンドを管理装置102に転送して応答を待つ。そして、画像機器コマンドに対する応答を管理装置102から受信すると、これをHTTPリクエストに記載して画像形成装置100に送信する(HTTPリクエストW)。これによって画像形成装置100は画像機器コマンドに対する応答を取得でき、HTTPレスポンスに応答の受信通知を記載して返信する(HTTPレスポンスW)、という手順である。
しかし、以下の説明においては、上記のHTTPレスポンスZに応答を記載する手順を採用した場合について説明する。
すなわち、画像形成装置100がHTTPリクエストに画像機器コマンドを記載して仲介装置101に送信し(HTTPリクエストZ′)、これに対して仲介装置101はHTTPレスポンスにコマンドの受付通知を記載して返信し(HTTPレスポンスZ)、コマンドを管理装置102に転送して応答を待つ。そして、画像機器コマンドに対する応答を管理装置102から受信すると、これをHTTPリクエストに記載して画像形成装置100に送信する(HTTPリクエストW)。これによって画像形成装置100は画像機器コマンドに対する応答を取得でき、HTTPレスポンスに応答の受信通知を記載して返信する(HTTPレスポンスW)、という手順である。
しかし、以下の説明においては、上記のHTTPレスポンスZに応答を記載する手順を採用した場合について説明する。
次に、図6に仲介装置と管理装置との間の通信シーケンスの例を示す。
仲介装置101と管理装置102との間には、ファイアウォール104があるため、この図に示すように、通信は常に、仲介装置101から通信要求としてHTTPリクエストを管理装置102に送信し、管理装置102からこの通信要求に対する通信応答としてHTTPレスポンスを仲介装置101に返すという手順で行われる。例えば仲介装置101が送信したHTTPリクエストXに対して管理装置102がHTTPレスポンスXを返し、同じくHTTPリクエストYに対してHTTPレスポンスYを返すという具合である。
仲介装置101と管理装置102との間には、ファイアウォール104があるため、この図に示すように、通信は常に、仲介装置101から通信要求としてHTTPリクエストを管理装置102に送信し、管理装置102からこの通信要求に対する通信応答としてHTTPレスポンスを仲介装置101に返すという手順で行われる。例えば仲介装置101が送信したHTTPリクエストXに対して管理装置102がHTTPレスポンスXを返し、同じくHTTPリクエストYに対してHTTPレスポンスYを返すという具合である。
そして、HTTPリクエストには、仲介装置101からの管理装置102宛ての動作要求である仲介装置コマンドと、画像形成装置100からの管理装置102宛ての動作要求である画像機器コマンドと、管理装置102から仲介装置101に送信されてきた管理装置コマンドに対する応答(コマンド応答)と、管理装置102から画像形成装置100に送信されてきた管理装置コマンドに対する応答とを記載して送信するようにしている。また、HTTPレスポンスには、管理装置102からの仲介装置101宛て又は画像形成装置100宛ての動作要求である管理装置コマンドと、仲介装置101からの管理装置102宛ての動作要求である仲介装置コマンドに対する応答と、画像形成装置100からの管理装置102宛ての動作要求である画像機器コマンドに対する応答とを記載して送信するようにしている。なお、遅延通知を送信する場合には、上記コマンド応答に代えて遅延通知を記載してもよい。
例えば画像機器コマンドA及び仲介装置コマンドBは、HTTPリクエストXに記載して転送し、コマンド応答あるいは遅延通知をそのHTTPリクエストXと対応するHTTPレスポンスXに記載して転送することができる。しかし、管理装置コマンドC及びDについては、HTTPリクエストXと対応するHTTPレスポンスXに記載して転送し、そのコマンド応答あるいは遅延通知は次のHTTPリクエストであるHTTPリクエストYに記載して転送することになる。
ここで、画像機器宛ての管理装置コマンドDに対して仲介装置101が返す遅延通知は、画像形成装置100が生成したものではなく、後述するように、仲介装置101が生成したものである。
ここで、画像機器宛ての管理装置コマンドDに対して仲介装置101が返す遅延通知は、画像形成装置100が生成したものではなく、後述するように、仲介装置101が生成したものである。
また、上述した図4(A)又は(B)のケースでは、仲介装置101が、画像機器コマンドを取得するか仲介装置コマンドを生成した後直ちに管理装置102とコネクションを確立し、HTTPリクエストにこれを含めて引き渡すことができるが、図4(C)又は(D)のケースでは、仲介装置101側に設置されたファイアウォール104が管理装置102からのHTTPリクエストを遮断するため、管理装置102側から仲介装置101へアクセスして管理装置コマンドを直ちに引き渡すことができないことになる。
なお、画像機器コマンド、仲介装置コマンド及び管理装置コマンドに対する応答をそれぞれ任意の数ずつ(0でもよい)1つのHTTPリクエストに記載することができ、管理装置コマンド及び、画像機器コマンドや仲介装置コマンドに対する応答を、それぞれ任意の数ずつ(0でもよい)1つのHTTPレスポンスに記載することができる。そして、1つのHTTPリクエスト又はHTTPレスポンスに記載した内容は、論理的に一括して転送する。
そして、このように、宛先や送信元の異なる動作要求や動作応答を一括して転送することにより、必要な情報を転送するために必要なコネクションの回数を減らし、オーバーヘッドを低減して通信の効率化を図っている。
そして、このように、宛先や送信元の異なる動作要求や動作応答を一括して転送することにより、必要な情報を転送するために必要なコネクションの回数を減らし、オーバーヘッドを低減して通信の効率化を図っている。
図7に仲介装置と管理装置との間の別の通信シーケンスの例を示す。
説明のため、図6には極めて単純なシーケンス例を示したが、図7には、各HTTPリクエストやHTTPレスポンスに記載するコマンドやコマンド応答の数が一定でない例を示している。
また、コマンドに対して遅延通知を送信した場合に、次の送信機会の時点で応答を返す必要もない。例えば、図7に示す仲介装置コマンドBのように、遅延通知を記載したHTTPレスポンスX′の次のHTTPレスポンスY′に記載して応答を返さず、図示しないさらに後のHTTPレスポンス応答を返すようにしてもよい。
もちろん画像機器コマンドについても同様であり、遅延通知を記載したHTTPリクエストの次のHTTPリクエストにそのコマンドに対する応答を記載する必要はない。そして、さらに後のHTTPリクエストに記載して転送すればよい。
説明のため、図6には極めて単純なシーケンス例を示したが、図7には、各HTTPリクエストやHTTPレスポンスに記載するコマンドやコマンド応答の数が一定でない例を示している。
また、コマンドに対して遅延通知を送信した場合に、次の送信機会の時点で応答を返す必要もない。例えば、図7に示す仲介装置コマンドBのように、遅延通知を記載したHTTPレスポンスX′の次のHTTPレスポンスY′に記載して応答を返さず、図示しないさらに後のHTTPレスポンス応答を返すようにしてもよい。
もちろん画像機器コマンドについても同様であり、遅延通知を記載したHTTPリクエストの次のHTTPリクエストにそのコマンドに対する応答を記載する必要はない。そして、さらに後のHTTPリクエストに記載して転送すればよい。
ところで、各コマンド及びコマンド応答は、それぞれ独立して生成され、また処理に供されるべきものであるから、仲介装置101と管理装置102との間で上記のような一括転送を行うためには、転送前にこれらのコマンドやコマンド応答を結合し、また転送後に分離する処理が必要となる。次に、各装置のハードウェア構成と共に、このような処理を行うための機能構成及びその処理の手順について説明する。
まず、図8に管理装置のハードウェア構成の概略を示す。
図8は、管理装置102の概略構成例を示すブロック図である。
この管理装置102は、モデム121,通信端末122,プロキシ(Proxy)サーバ123,操作者端末124,データベース125,制御装置126等からなる。
モデム121は、公衆回線を介して機器利用者側(例えば画像形成装置を利用しているユーザ先)の仲介装置101との通信を司るものであり、送受信するデータを変復調する。このモデム121と通信端末122により通信手段としての機能を果たす。
図8は、管理装置102の概略構成例を示すブロック図である。
この管理装置102は、モデム121,通信端末122,プロキシ(Proxy)サーバ123,操作者端末124,データベース125,制御装置126等からなる。
モデム121は、公衆回線を介して機器利用者側(例えば画像形成装置を利用しているユーザ先)の仲介装置101との通信を司るものであり、送受信するデータを変復調する。このモデム121と通信端末122により通信手段としての機能を果たす。
通信端末122は、公衆回線を介してラインアダプタや仲介装置101とのデータの送受信を行う。
プロキシサーバ123は、インターネット103を介して機器利用者側の仲介装置101とのデータの送受信及びセキュリティ管理を行う。このプロキシサーバ123も、通信手段としての機能を果たす。
プロキシサーバ123は、インターネット103を介して機器利用者側の仲介装置101とのデータの送受信及びセキュリティ管理を行う。このプロキシサーバ123も、通信手段としての機能を果たす。
操作者端末124は、管理センタのオペレータが操作する端末であり、各種データの入力をオペレータによるキーボード等の入力装置上の操作により受け付けたり、オペレータに通知すべき情報を表示部に表示したりする。入力されるデータとしては、例えば、各機器利用者側の仲介装置101が管理装置102へ通信する際に使用するIPアドレスや発呼先電話番号等の顧客情報がある。
データベース125は、図示しないデータベースサーバのハードディスク装置等の記憶装置に存在し、画像形成装置100のIPアドレスや電話番号、それらの装置から受信した異常情報等のデータ、操作者端末124から入力されたデータ等の各種データを記憶する。
データベース125は、図示しないデータベースサーバのハードディスク装置等の記憶装置に存在し、画像形成装置100のIPアドレスや電話番号、それらの装置から受信した異常情報等のデータ、操作者端末124から入力されたデータ等の各種データを記憶する。
制御装置126は、図示しないCPU,ROM,RAM等からなるマイクロコンピュータを備えており、管理装置102全体を統括的に制御する。そのCPUが、ROM等に記憶している制御プログラムを必要に応じて実行すると共に、モデム121,通信端末122,プロキシサーバ123,操作者端末124またはデータベース125を利用することにより、この発明による機能(記憶手段,要求生成手段,収集手段,分配手段,送信手段,受信手段,その他の手段としての機能)を実現することができる。
なお、管理装置の構成はこれに限られることはなく、例えば1台のPCを用いて構成することもできる。
なお、管理装置の構成はこれに限られることはなく、例えば1台のPCを用いて構成することもできる。
次に、図9に画像形成装置のハードウェア構成を示す。
画像形成装置100はここでは、プリンタ、ファクシミリ(FAX)装置、デジタル複写機、スキャナ装置、文書管理装置等の機能を備えたデジタル複合機として構成しており、図9に示すように、CPU201,ASIC(Application Specific Integrated Circuit)202,SDRAM203,フラッシュメモリ(不揮発性メモリ)204,NRS用メモリ205,PHY(物理メディアインタフェース)206,NVRAM(不揮発性メモリ)207,操作部209,HDD(ハードディスクドライブ)210,モデム211,PI(パーソナルインタフェース)212,FCU(ファックスコントロールユニット)213,USB(Universal Serial Bus)214,IEEE(Institute of Electrical and Electronic Engineers)1394_215,エンジンインタフェース(I/F)216,およびエンジン部217を備えている。これらの構成が、画像読み取り、画像形成、画情報送信等の画像処理を行うためのハードウェア資源である。
画像形成装置100はここでは、プリンタ、ファクシミリ(FAX)装置、デジタル複写機、スキャナ装置、文書管理装置等の機能を備えたデジタル複合機として構成しており、図9に示すように、CPU201,ASIC(Application Specific Integrated Circuit)202,SDRAM203,フラッシュメモリ(不揮発性メモリ)204,NRS用メモリ205,PHY(物理メディアインタフェース)206,NVRAM(不揮発性メモリ)207,操作部209,HDD(ハードディスクドライブ)210,モデム211,PI(パーソナルインタフェース)212,FCU(ファックスコントロールユニット)213,USB(Universal Serial Bus)214,IEEE(Institute of Electrical and Electronic Engineers)1394_215,エンジンインタフェース(I/F)216,およびエンジン部217を備えている。これらの構成が、画像読み取り、画像形成、画情報送信等の画像処理を行うためのハードウェア資源である。
CPU201は、ASIC202を介してデータ処理(各機能の制御)を行う演算処理手段である。
ASIC202は、CPUインターフェース,SDRAMインターフェース,ローカルバスインタフェース,PCIインタフェース,MAC(Media Access Controller)、HDDインタフェースなどからなる多機能デバイスボードであり、CPU201の制御対象となるデバイスの共有化を図り、アーキテクチャの面からアプリ(アプリケーションソフト)や共通システムサービスの開発の高効率化を支援するものである。
また、このASIC202には各エンジン部の操作命令等を受け付けるオペレーションパネル等による操作部209が直接的に接続されると共に、PHY206も直接的に接続される。また、FCU213やUSB214,IEEE1394_215及びエンジンI/F216がPCIバス218を介して接続され、必要に応じてモデム211やPI212等が直接接続される。
ASIC202は、CPUインターフェース,SDRAMインターフェース,ローカルバスインタフェース,PCIインタフェース,MAC(Media Access Controller)、HDDインタフェースなどからなる多機能デバイスボードであり、CPU201の制御対象となるデバイスの共有化を図り、アーキテクチャの面からアプリ(アプリケーションソフト)や共通システムサービスの開発の高効率化を支援するものである。
また、このASIC202には各エンジン部の操作命令等を受け付けるオペレーションパネル等による操作部209が直接的に接続されると共に、PHY206も直接的に接続される。また、FCU213やUSB214,IEEE1394_215及びエンジンI/F216がPCIバス218を介して接続され、必要に応じてモデム211やPI212等が直接接続される。
そして、上記のCPU201は、このASIC202を介してフラッシュメモリ204やHDD210等の記憶手段から必要な制御プログラムを読み出し、SDRAM203等に展開して実行することにより、情報の処理を行う処理手段として機能することができる。
SDRAM203は、OSを含む各種プログラムを記憶するプログラムメモリや、CPU201がデータ処理を行う際に使用するワークメモリ等として使用するメインメモリである。なお、このSDRAM203の代わりに、DRAMやSRAMを使用してもよい。
SDRAM203は、OSを含む各種プログラムを記憶するプログラムメモリや、CPU201がデータ処理を行う際に使用するワークメモリ等として使用するメインメモリである。なお、このSDRAM203の代わりに、DRAMやSRAMを使用してもよい。
フラッシュメモリ204は、例えば、画像形成装置100を起動させるブートローダ(ブートプログラム)やOSのファイルであるOSイメージ及び後述する種々のプログラムを記憶するプログラムメモリ、種々の固定パラメータを記憶する固定パラメータメモリ等として使用する不揮発性メモリ(記憶手段)であり、電源がオフになっても記憶内容を保持するようになっている。なお、このフラッシュメモリ204の代わりに、RAMと電池を利用したバックアップ回路を集積した不揮発性RAMや、EEPROM等の他の不揮発性メモリを使用してもよい。
NRS用メモリ205は、後述するNRSアプリを記憶する不揮発性メモリであり、オプションでNRS機能を追加することができる。
PHY206は、LANを介して外部装置と通信を行うためのインタフェースである。
NVRAM207は、例えば、この画像形成装置100の識別情報である機種機番を記憶する機種機番メモリ、操作部209による操作上の初期値を記憶するメモリ、各アプリ(APL)の初期値を記憶するメモリ、各カウンタ情報(課金カウンタのデータ)を記憶するメモリ、自身や通信相手の設定状況、ネットワークアドレス情報、プロトコル等の機種情報を記憶するメモリ等として使用する不揮発性メモリ(記憶手段)であり、電源がオフになっても記憶内容を保持するようになっている。なお、このNVRAM207として、RAMと電池を利用したバックアップ回路を集積した不揮発性RAMや、EEPROM,フラッシュメモリ等の不揮発性メモリを使用することができる。
PHY206は、LANを介して外部装置と通信を行うためのインタフェースである。
NVRAM207は、例えば、この画像形成装置100の識別情報である機種機番を記憶する機種機番メモリ、操作部209による操作上の初期値を記憶するメモリ、各アプリ(APL)の初期値を記憶するメモリ、各カウンタ情報(課金カウンタのデータ)を記憶するメモリ、自身や通信相手の設定状況、ネットワークアドレス情報、プロトコル等の機種情報を記憶するメモリ等として使用する不揮発性メモリ(記憶手段)であり、電源がオフになっても記憶内容を保持するようになっている。なお、このNVRAM207として、RAMと電池を利用したバックアップ回路を集積した不揮発性RAMや、EEPROM,フラッシュメモリ等の不揮発性メモリを使用することができる。
操作部209は、操作表示手段(操作手段および表示手段)である。
HDD210は、電源のオン・オフに関係なくデータを記憶保存する記憶手段(記録媒体)である。このHDD210に、上述したフラッシュメモリ204内のプログラムやそれ以外のデータ、あるいはNVRAM207内のデータを記憶しておくこともできる。また、定期的に収集、更新、送信等の処理を行う対象となるデータも、このHDD210に記憶させておくとよい。
モデム211は、変復調手段であり、管理装置102へ公衆回線経由でデータを送信する場合、そのデータを公衆回線に流せる形に変調する。また、管理装置102から送られてくる変調されたデータを受信した場合、そのデータを復調する。
HDD210は、電源のオン・オフに関係なくデータを記憶保存する記憶手段(記録媒体)である。このHDD210に、上述したフラッシュメモリ204内のプログラムやそれ以外のデータ、あるいはNVRAM207内のデータを記憶しておくこともできる。また、定期的に収集、更新、送信等の処理を行う対象となるデータも、このHDD210に記憶させておくとよい。
モデム211は、変復調手段であり、管理装置102へ公衆回線経由でデータを送信する場合、そのデータを公衆回線に流せる形に変調する。また、管理装置102から送られてくる変調されたデータを受信した場合、そのデータを復調する。
PI212は、RS485規格に準拠したインタフェースを備え、図示しないラインアダプタを介して公衆回線に接続している。
FCU213は、FAX装置又はモデム機能(FAX通信機能)を有するデジタル複写機やデジタル複合機等の画像形成装置および管理装置102等の外部装置との通信を公衆回線経由で制御する。
USB214及びIEEE1394_215はそれぞれ、周辺機器と通信を行うための、USB規格及びIEEE1394規格のインタフェースである。
エンジンI/F216は、エンジン部217をPCIバスに接続するためのインタフェースである。
エンジン部217は、公知のスキャナエンジン及びプロッタエンジン等からなる画像読み取り/形成用のエンジンや、プロッタエンジンによって画像を形成した用紙に、ソート、穴開け、ステープル処理等の後処理を行う後処理ユニット等が該当する。
FCU213は、FAX装置又はモデム機能(FAX通信機能)を有するデジタル複写機やデジタル複合機等の画像形成装置および管理装置102等の外部装置との通信を公衆回線経由で制御する。
USB214及びIEEE1394_215はそれぞれ、周辺機器と通信を行うための、USB規格及びIEEE1394規格のインタフェースである。
エンジンI/F216は、エンジン部217をPCIバスに接続するためのインタフェースである。
エンジン部217は、公知のスキャナエンジン及びプロッタエンジン等からなる画像読み取り/形成用のエンジンや、プロッタエンジンによって画像を形成した用紙に、ソート、穴開け、ステープル処理等の後処理を行う後処理ユニット等が該当する。
このような画像形成装置100において、電源投入(電源オン)時には、CPU201は、ASIC202経由でフラッシュメモリ204内のブートローダを起動させ、そのブートローダに従い、フラッシュメモリ204内のOSイメージを読み出し、それをSDRAM203にロードして使用可能なOSに展開する。そして、OSの展開が完了すると、そのOSを起動させる。その後、必要に応じてフラッシュメモリ204内のアプリ等のプログラムあるいはNRS用メモリ205内のNRSアプリを読み出し、それをSDRAM203にロードして展開し、起動させることにより、各種機能を実現することができる。
次に、図10に仲介装置のハードウェア構成を示す。
仲介装置101は、図10に示すように、CPU52,SDRAM53,フラッシュメモリ54(不揮発性メモリ),RTC(内部時計であるリアルタイムクロック回路)55,Op−Port(操作部接続ポート)56,PHY57,モデム58,HDD制御部59,拡張I/F60,RS232I/F(インタフェース)61,RS485I/F62,HDD63等を備えている。
仲介装置101は、図10に示すように、CPU52,SDRAM53,フラッシュメモリ54(不揮発性メモリ),RTC(内部時計であるリアルタイムクロック回路)55,Op−Port(操作部接続ポート)56,PHY57,モデム58,HDD制御部59,拡張I/F60,RS232I/F(インタフェース)61,RS485I/F62,HDD63等を備えている。
そして、CPU52は、フラッシュメモリ54やHDD63等の記憶手段から必要な制御プログラムを読み出し、SDRAM53等に展開して実行することにより、仲介装置101全体を制御し、この発明による機能(記憶手段,収集手段,分配手段,個別送信手段,個別受信手段,一括送信手段,一括受信手段,その他の手段としての機能)を実現することができる。
SDRAM53は、OSを含む各種プログラムを記憶するプログラムメモリや、CPU52がデータ処理を行う際に使用するワークメモリ等として使用するメインメモリである。
SDRAM53は、OSを含む各種プログラムを記憶するプログラムメモリや、CPU52がデータ処理を行う際に使用するワークメモリ等として使用するメインメモリである。
フラッシュメモリ54は、例えば、仲介装置101を起動させるブートローダ(ブートプログラム)やOSのファイルであるOSイメージ及び後述する種々のプログラムを記憶するプログラムメモリ、種々の固定パラメータを記憶する固定パラメータメモリ等として使用する不揮発性メモリ(記憶手段)であり、電源がオフになっても記憶内容を保持するようになっている。HDD63にも同様なデータを記憶させることができる。
RTC55は計時のための回路であり、Op−Port56は図示しない操作部における操作を検出する回路である。
また、PHY57,モデム58,RS485I/F62は、それぞれLAN,公衆回線,RS485規格のシリアル通信によって通信を行うためのインタフェースである。
拡張I/F60は、無線LANボードや拡張メモリ等の拡張ボードを接続するためのI/Fである。
RTC55は計時のための回路であり、Op−Port56は図示しない操作部における操作を検出する回路である。
また、PHY57,モデム58,RS485I/F62は、それぞれLAN,公衆回線,RS485規格のシリアル通信によって通信を行うためのインタフェースである。
拡張I/F60は、無線LANボードや拡張メモリ等の拡張ボードを接続するためのI/Fである。
そして、この仲介装置101はPHY57を介してネットワーク上の画像形成装置100や被管理仲介装置110と接続され、またインターネット103に接続されている。また、画像形成装置100とは、RS232I/F61およびRS485I/F62を介しても接続可能である。なお、SDRAM53の代わりに、DRAMやSRAMを使用してもよい。また、フラッシュメモリ54の代わりに、EEPROM等の他の不揮発性メモリを使用してもよい。
次に、図11に、仲介装置101の機能のうち、コマンド及びコマンド応答に関する処理を行うための機能の構成を示す機能ブロック図を示す。なお、この図において各手段及び機能部間の関連については図示を省略しており、図12には、仲介装置101が管理装置102と通信を行う場合のデータの流れを示している。そこで、まず図11及び図12を参照して、管理装置102との通信に関連する部分の仲介装置101の機能について説明する。
図11に示す機能のうち、被管理側コマンドプール41及び管理装置コマンドプール42は、いずれかの書き換え可能な記憶手段に設けられるものである。例えばフラッシュメモリ54に設けることができるが、SDRAM53やHDD63に設けてもよい。仲介装置コマンド生成手段43、管理装置コマンド実行結果生成手段44、送信メッセージ収集手段45、受信メッセージ分配手段48、応答状況管理手段49の機能は、CPU52によって実現されるものである。また、HTTPサーバ機能部46及びHTTPクライアント機能部47の機能は、CPU52及びPHY57によって実現されるものである。
これらの機能についてさらに詳述する。
まず、被管理側コマンドプール41は、仲介装置101に設けた第2の記憶領域に該当し、画像機器コマンド及び仲介機器コマンドを、これらのコマンドに対する応答や、このコマンドの識別情報及びコマンドの宛先や送信元の情報等と関連付けて登録するプールである。以後、画像機器コマンドと仲介機器コマンドとを一括して「被管理側コマンド」とも呼ぶことにする。
まず、被管理側コマンドプール41は、仲介装置101に設けた第2の記憶領域に該当し、画像機器コマンド及び仲介機器コマンドを、これらのコマンドに対する応答や、このコマンドの識別情報及びコマンドの宛先や送信元の情報等と関連付けて登録するプールである。以後、画像機器コマンドと仲介機器コマンドとを一括して「被管理側コマンド」とも呼ぶことにする。
また、管理装置コマンドプール42は、仲介装置101に設けた第1の記憶領域に該当し、管理装置コマンドを、このコマンドに対する応答や、このコマンドの識別情報及びこのコマンドの宛先や送信元の情報等と関連付けて登録するプールである。
これらのプールにおいては、コマンド毎にテーブル形式のコマンドシートを作成して情報を格納することにより、コマンドと、識別情報や応答等の情報とを関連付けるようにしている。また、これらのプールを設けた記憶手段がそれぞれ仲介装置101の第2,第1の記憶手段に該当するものとする。
これらのプールにおいては、コマンド毎にテーブル形式のコマンドシートを作成して情報を格納することにより、コマンドと、識別情報や応答等の情報とを関連付けるようにしている。また、これらのプールを設けた記憶手段がそれぞれ仲介装置101の第2,第1の記憶手段に該当するものとする。
仲介装置コマンド生成手段43は、要求生成手段に該当する。そして、被管理側コマンドを生成し、このコマンドを識別する識別情報(ID)を割り当て、さらにこのコマンドの送信元情報やこのコマンドを管理するための管理情報を付し、これらの情報を関連付けてテーブル形式の被管理側コマンドシートとして被管理側コマンドプール41に登録する機能を有する。この処理を行うのが仲介装置コマンド生成ハンドラ43aであり、このうち、仲介装置コマンドを生成する部分には、例えば仲介装置101に備えるアプリケーションが該当する。また、仲介装置コマンド生成ハンドラ43aに、管理装置102に各コマンドを実行させる際の優先順位を、生成した仲介装置コマンドに付する機能を設けてもよい。
また、図11及び図12には図示していないが、後述するように、仲介装置コマンド生成手段43は、画像形成装置100から受信した画像機器コマンドを、管理情報を付して被管理側コマンドシートとして被管理側コマンドプール41に登録すると共に、そのコマンドに対する応答を被管理側コマンドプール41から読み出して画像形成装置100に転送する機能も有する。
また、図11及び図12には図示していないが、後述するように、仲介装置コマンド生成手段43は、画像形成装置100から受信した画像機器コマンドを、管理情報を付して被管理側コマンドシートとして被管理側コマンドプール41に登録すると共に、そのコマンドに対する応答を被管理側コマンドプール41から読み出して画像形成装置100に転送する機能も有する。
ここで、図13に仲介装置101の被管理側コマンドシートにおけるデータ構造の例を示す。
この図に示すように、仲介装置101においては、被管理側コマンドシートには、「コマンドID」、「送信元情報」、「宛先情報」、「メソッド名」、「入力パラメータ」、「状態」、「コマンド実行結果の通知先」、および「出力パラメータ」のデータを記憶する領域を設けている。そして、このうち「コマンドID」、「メソッド名」、および「入力パラメータ」が被管理側コマンド(及びそこに付されたID)に該当し、「状態」及び「コマンド実行結果の通知先」が管理情報に該当する。「出力パラメータ」は、管理装置102から受信するコマンド応答の内容である。
この図に示すように、仲介装置101においては、被管理側コマンドシートには、「コマンドID」、「送信元情報」、「宛先情報」、「メソッド名」、「入力パラメータ」、「状態」、「コマンド実行結果の通知先」、および「出力パラメータ」のデータを記憶する領域を設けている。そして、このうち「コマンドID」、「メソッド名」、および「入力パラメータ」が被管理側コマンド(及びそこに付されたID)に該当し、「状態」及び「コマンド実行結果の通知先」が管理情報に該当する。「出力パラメータ」は、管理装置102から受信するコマンド応答の内容である。
各項目の内容について説明する。
まず、「メソッド名」は、管理装置102に対するリクエストの内容であり、管理装置102において呼び出す関数の種類を示す。「入力パラメータ」は、「メソッド名」に付随するデータであり、関数を呼び出す際の引数である。
「送信元情報」は、コマンドの送信元、すなわちコマンドを生成した装置の識別情報を示す。またこの情報は、コマンドに対する応答を送信する際の宛先を示す情報になる。「宛先情報」は、コマンドを実行させる対象の装置、すなわちコマンドの宛先となる装置の識別情報を示す。被管理側コマンドの場合には、ここには管理装置102の識別情報を登録することになる。なお、識別情報としては、ID、固有名称、IPアドレス等を用いることができる。
まず、「メソッド名」は、管理装置102に対するリクエストの内容であり、管理装置102において呼び出す関数の種類を示す。「入力パラメータ」は、「メソッド名」に付随するデータであり、関数を呼び出す際の引数である。
「送信元情報」は、コマンドの送信元、すなわちコマンドを生成した装置の識別情報を示す。またこの情報は、コマンドに対する応答を送信する際の宛先を示す情報になる。「宛先情報」は、コマンドを実行させる対象の装置、すなわちコマンドの宛先となる装置の識別情報を示す。被管理側コマンドの場合には、ここには管理装置102の識別情報を登録することになる。なお、識別情報としては、ID、固有名称、IPアドレス等を用いることができる。
「コマンドID」は、被管理側コマンドを識別するための識別情報である。「状態」は、被管理側コマンドに関する処理の進行状況を示すデータであり、処理の進行と共に、「未処理」→「応答待ち」→「応答受信済」もしくは「未処理」→「応答待ち」→「応答遅延」→「応答受信済」と遷移していく。
「コマンド実行結果の通知先」は、そのシートに記載している被管理側コマンドに対する応答を受信した場合に、その旨を通知して必要な処理を実行させるモジュールを示す参照情報である。参照するモジュールは、被管理側コマンドを登録したハンドラであることが多いが、必ずしもそうである必要はない。「出力パラメータ」には、コマンド応答を受け取った段階で、その内容を格納する。管理装置102からのコマンド応答を受け取るまでは空である。
「コマンド実行結果の通知先」は、そのシートに記載している被管理側コマンドに対する応答を受信した場合に、その旨を通知して必要な処理を実行させるモジュールを示す参照情報である。参照するモジュールは、被管理側コマンドを登録したハンドラであることが多いが、必ずしもそうである必要はない。「出力パラメータ」には、コマンド応答を受け取った段階で、その内容を格納する。管理装置102からのコマンド応答を受け取るまでは空である。
図11及び図12の説明に戻ると、管理装置コマンド実行結果生成手段44は、応答生成手段に該当する。そして、管理装置コマンドプール42から管理装置コマンドを読み出して実行するアプリケーションである管理装置コマンドハンドラ44aを備え、この管理装置コマンドハンドラ44aが、管理装置コマンドに対する応答を生成し、管理装置コマンドのコマンドIDと関連付けて管理装置コマンドプール42に登録する機能を有する。なお、管理装置102から受信した管理装置コマンドは、このコマンドを識別するID及やこのコマンドを管理するための管理情報等と関連付けて、テーブル形式の管理装置コマンドシートとして管理装置コマンドプール42に登録しておくようにしている。そして、管理装置コマンド実行結果生成手段44が生成したコマンド応答も、実行した管理装置コマンドについての管理装置コマンドシートに登録する。
また、管理装置コマンドハンドラ44aに、管理装置コマンドプール42から複数の種類の管理装置コマンドを読み出し、各管理装置コマンドに対する応答を生成する機能を設けることが考えられる。さらに、管理装置コマンドが仲介装置101に優先して処理を実行させるための実行優先順位の情報を含む場合には、優先順位の高いものから優先的に読み出して実行する機能を設けることも考えられる。
なお、管理装置コマンドハンドラ44aは、アプリケーションそのものではなく、管理装置コマンドの実行に必要なアプリケーションを呼び出してコマンドを実行させるモジュールであってもよい。
また、図11及び図12では図示していないが、後述するように、管理装置コマンド実行結果生成手段44は、画像形成装置100や被管理仲介装置110宛ての管理装置コマンドを管理装置コマンドプール42から読み出して画像形成装置100や被管理仲介装置110に転送すると共に、そのコマンドに対する応答を取得して管理装置コマンドプール42に登録する機能も有する。
なお、管理装置コマンドハンドラ44aは、アプリケーションそのものではなく、管理装置コマンドの実行に必要なアプリケーションを呼び出してコマンドを実行させるモジュールであってもよい。
また、図11及び図12では図示していないが、後述するように、管理装置コマンド実行結果生成手段44は、画像形成装置100や被管理仲介装置110宛ての管理装置コマンドを管理装置コマンドプール42から読み出して画像形成装置100や被管理仲介装置110に転送すると共に、そのコマンドに対する応答を取得して管理装置コマンドプール42に登録する機能も有する。
ここで、図14に仲介装置101の管理装置コマンドシートにおけるデータ構造の例を示す。
この図に示すように、仲介装置101においては、管理装置コマンドシートには、「コマンドID」、「送信元情報」、「宛先情報」、「メソッド名」、「入力パラメータ」、「状態」、「出力パラメータ」、および「コマンドの通知先」のデータを記憶する領域を設けている。そして、このうち「コマンドID」、「メソッド名」、および「入力パラメータ」が管理装置コマンド(及びそこに付されたID)に該当し、「状態」及び「コマンドの通知先」が管理情報に該当する。「出力パラメータ」は、管理装置コマンドの実行結果であり、仲介装置101や画像形成装置100あるいは被管理仲介装置110が返すコマンド応答の内容となる。
この図に示すように、仲介装置101においては、管理装置コマンドシートには、「コマンドID」、「送信元情報」、「宛先情報」、「メソッド名」、「入力パラメータ」、「状態」、「出力パラメータ」、および「コマンドの通知先」のデータを記憶する領域を設けている。そして、このうち「コマンドID」、「メソッド名」、および「入力パラメータ」が管理装置コマンド(及びそこに付されたID)に該当し、「状態」及び「コマンドの通知先」が管理情報に該当する。「出力パラメータ」は、管理装置コマンドの実行結果であり、仲介装置101や画像形成装置100あるいは被管理仲介装置110が返すコマンド応答の内容となる。
各データの内容について説明する。
まず、「メソッド名」は、仲介装置101に対するリクエストの内容であり、仲介装置101において呼び出す関数の種類を示す。「入力パラメータ」は、「メソッド名」に付随するデータであり、関数を呼び出す際の引数である。
「送信元情報」は、コマンドの送信元、すなわちコマンドを生成した装置の識別情報を示す。管理装置コマンドの場合には、ここには管理装置102の識別情報を登録することになる。またこの情報は、コマンドに対する応答を送信する際の宛先を示す情報になる。「宛先情報」は、コマンドを実行させる対象の装置、すなわちコマンドの宛先となる装置の識別情報を示す。
まず、「メソッド名」は、仲介装置101に対するリクエストの内容であり、仲介装置101において呼び出す関数の種類を示す。「入力パラメータ」は、「メソッド名」に付随するデータであり、関数を呼び出す際の引数である。
「送信元情報」は、コマンドの送信元、すなわちコマンドを生成した装置の識別情報を示す。管理装置コマンドの場合には、ここには管理装置102の識別情報を登録することになる。またこの情報は、コマンドに対する応答を送信する際の宛先を示す情報になる。「宛先情報」は、コマンドを実行させる対象の装置、すなわちコマンドの宛先となる装置の識別情報を示す。
「コマンドID」は、管理装置コマンドを識別するための識別情報である。「状態」は、管理装置コマンドに関する処理の状態を示すデータであり、処理の進行と共に、「未処理」→「処理完了」→「応答済」もしくは「未処理」→「遅延未通知」→「処理待ち」→「処理中」→「処理完了」→「応答済」と遷移していく。「出力パラメータ」には、管理装置コマンド実行結果生成手段44によって生成された応答が格納される。管理装置コマンドの実行が終了し、上記の「状態」が「処理完了」となるまでは空である。「コマンドの通知先」は、管理装置コマンドの実行又は転送を行うモジュールを示す参照情報である。
再び図11の説明に戻ると、送信メッセージ収集手段45は、収集手段に該当する。そして、管理装置コマンド実行結果生成手段44が生成したコマンド応答とこのコマンド応答に対応する管理装置コマンドのコマンドID及び宛先情報とを関連付けて管理装置コマンドプール42から読み出すと共に、仲介装置コマンド生成手段43が生成した被管理側コマンドとこのコマンドのコマンドID及び送信元情報とを関連付けて被管理側コマンドプール41から読み出し、これらから送信メッセージを生成する機能を有する。さらに、遅延通知が必要な管理装置コマンドについて、そのコマンドID及び宛先情報を関連付けて管理装置コマンドプール42から読み出し、遅延通知の送信メッセージを生成する機能も有する。
なお、コマンド応答や被管理側コマンドに実行優先順位が指定されている場合には、送信メッセージ収集手段45がそれぞれ実行優先順位の高いものから順に読み出すようにすることが考えられる。
なお、コマンド応答や被管理側コマンドに実行優先順位が指定されている場合には、送信メッセージ収集手段45がそれぞれ実行優先順位の高いものから順に読み出すようにすることが考えられる。
ここで、送信メッセージとは、上記のコマンド応答やコマンドとコマンドIDとを、構造化言語であるXML(Extensible Markup Language)で、SOAPメッセージとして記載したものである。そして、送信メッセージ収集手段45は、1つのコマンド応答あるいはコマンドにつき、送信メッセージとして1つのSOAPメッセージを生成する。またこのとき、各コマンドのコマンドID、発信元情報及び宛先情報はSOAPヘッダに記載し、コマンド応答、被管理側コマンドあるいは遅延通知の内容は、SOAPボディに記載する。SOAPによる通信では、SOAPヘッダとSOAPボディとからなるSOAPエンベロープ(封筒)と呼ばれるメッセージをXMLで記載し、HTTPなどのプロトコルで交換することになる。
このようなコマンドやコマンド応答からのSOAPメッセージの生成は、WSDL(Web Service Description Language)に基づいて生成される所要の変換プログラム(シリアライザ)を実行し、データを直列化することによって行うことができる。
このようなコマンドやコマンド応答からのSOAPメッセージの生成は、WSDL(Web Service Description Language)に基づいて生成される所要の変換プログラム(シリアライザ)を実行し、データを直列化することによって行うことができる。
また、HTTPクライアント機能部47は、HTTPリクエストを送信するHTTPリクエスト送信手段47aとHTTPレスポンスを受信するHTTPレスポンス受信手段47bとを備える。そして、HTTPリクエスト送信手段47aは、一括送信手段に該当し、送信メッセージ収集手段45が生成した送信メッセージを記載したHTTPリクエストを生成し、管理装置102に送信する機能を有する。このとき、1つのHTTPリクエストに送信メッセージをいくつ含めてもよいし、コマンド応答に係る送信メッセージと被管理側コマンドに係る送信メッセージと遅延通知に係る送信メッセージとを任意に混在させることもできる。もちろん、送信元の異なるコマンドやコマンド応答あるいは遅延通知に係る送信メッセージを混在させてもよい。
そこで、HTTPリクエスト送信手段47aは、これらのいずれに係る送信メッセージかに関わり無く、送信メッセージ収集手段45が生成した全ての送信メッセージを1つのHTTPリクエストに含めて送信するようにしている。ただし、1つのHTTPリクエストに含める送信メッセージの数に上限を設けることも考えられる。
そこで、HTTPリクエスト送信手段47aは、これらのいずれに係る送信メッセージかに関わり無く、送信メッセージ収集手段45が生成した全ての送信メッセージを1つのHTTPリクエストに含めて送信するようにしている。ただし、1つのHTTPリクエストに含める送信メッセージの数に上限を設けることも考えられる。
ところで、このHTTPリクエストの送信は、送信メッセージ収集手段45が被管理側コマンドやコマンド応答等の読み出しを試みた場合には、読み出すデータがなく、結果的に送信すべきSOAPメッセージを生成しなかった場合にも行うものである。そして、この読み出しの試みは、定期的に行うものとする。例えば、タイマによって60分毎に読み出すことが考えられる。
このようにするのは、上述のように、管理装置102から仲介装置101に送信したい情報があったとしても仲介装置101から通信を要求しない限り送信できないためである。仲介装置101から何も送信するデータがなかったとしても、定期的に管理装置102に対して通信要求を送信して、管理装置102から仲介装置101に情報を送信する機会を与えることにより、転送の必要な情報が長期間に亘って管理装置102に滞留してしまうことを防止できる。
このようにするのは、上述のように、管理装置102から仲介装置101に送信したい情報があったとしても仲介装置101から通信を要求しない限り送信できないためである。仲介装置101から何も送信するデータがなかったとしても、定期的に管理装置102に対して通信要求を送信して、管理装置102から仲介装置101に情報を送信する機会を与えることにより、転送の必要な情報が長期間に亘って管理装置102に滞留してしまうことを防止できる。
なお、送信メッセージ収集手段45による読み出しと、それに続くHTTPリクエスト送信手段47aによるHTTPリクエストの送信とを、定期的なタイミング以外に適宜行ってよいことはもちろんである。例えば、緊急に送信が必要な情報がいずれかのプールに登録された場合に、仲介装置コマンド生成手段43あるいは管理装置コマンド実行結果生成手段44が送信メッセージ収集手段45にその旨を通知して読み出しを行わせるようにしてもよい。
また、HTTPレスポンス受信手段47bは、一括受信手段に該当し、管理装置102からHTTPレスポンスを受信する機能を有する。そしてここでは、HTTPレスポンスには、管理装置コマンド及びそのコマンドと関連付けられたコマンドIDと宛先情報を含む受信メッセージと、被管理側コマンドに対する応答及びそのコマンドと関連付けられたコマンドIDと送信元情報を含む受信メッセージと、被管理側コマンドに対する遅延通知及びそのコマンドと関連付けられたコマンドIDと送信元情報を含む受信メッセージとが、任意に混在して含まれている。
ここで、受信メッセージとは、上記のコマンドや応答、遅延通知とコマンドID等とをSOAPメッセージとして記載したものである。
ここで、受信メッセージとは、上記のコマンドや応答、遅延通知とコマンドID等とをSOAPメッセージとして記載したものである。
受信メッセージ分配手段48は、第1の分配手段に該当する。そして、HTTPレスポンス受信手段47bが受信したHTTPレスポンスに含まれるデータを、被管理側コマンドプール41及び管理装置コマンドプール42に振り分けて登録する機能を有する。
具体的には、管理装置コマンド及びそのコマンドと関連付けられたコマンドID及び宛先情報とを管理装置コマンドプール42に管理装置コマンドシートを設けて登録すると共に、被管理側コマンドに対する応答については、そのコマンドと関連付けられたコマンドIDを被管理側コマンドプール41に記憶している被管理側コマンドシートのコマンドIDと照合して対応する被管理側コマンドを特定し、その被管理側コマンドについての「出力パラメータ」として登録する。被管理側コマンドに対する遅延通知については、やはりコマンドIDをもとに被管理側コマンドを特定し、そのコマンドについての「状態」を「応答遅延」に変更して応答の受信が遅延することを示す。
そしてこのとき、HTTPレスポンスを分割してそこに含まれる各受信メッセージを取り出し、そのデータをテーブルへの登録に必要な形式に変換するが、この変換は、WSDLに基づいて生成される所要の変換プログラム(デシリアライザ)を実行することによって行うことができる。
具体的には、管理装置コマンド及びそのコマンドと関連付けられたコマンドID及び宛先情報とを管理装置コマンドプール42に管理装置コマンドシートを設けて登録すると共に、被管理側コマンドに対する応答については、そのコマンドと関連付けられたコマンドIDを被管理側コマンドプール41に記憶している被管理側コマンドシートのコマンドIDと照合して対応する被管理側コマンドを特定し、その被管理側コマンドについての「出力パラメータ」として登録する。被管理側コマンドに対する遅延通知については、やはりコマンドIDをもとに被管理側コマンドを特定し、そのコマンドについての「状態」を「応答遅延」に変更して応答の受信が遅延することを示す。
そしてこのとき、HTTPレスポンスを分割してそこに含まれる各受信メッセージを取り出し、そのデータをテーブルへの登録に必要な形式に変換するが、この変換は、WSDLに基づいて生成される所要の変換プログラム(デシリアライザ)を実行することによって行うことができる。
応答状況管理手段49は、管理装置コマンドプール42に登録されている管理装置コマンドに対するコマンド応答の生成状況を管理する手段である。そして、管理装置コマンドについて、管理装置コマンドプール42に登録後、所定時間内にコマンド応答を生成できない場合には、管理装置102に対して遅延通知が必要である旨を設定する。具体的には、管理装置コマンドシートの「状態」を「遅延未通知」に変更する。
なお、HTTPサーバ機能部46は、HTTPレスポンスを送信するHTTPレスポンス送信手段46aとHTTPリクエストを受信するHTTPリクエスト受信手段46bとを備えるが、管理装置102との通信においては使用しない。
なお、HTTPサーバ機能部46は、HTTPレスポンスを送信するHTTPレスポンス送信手段46aとHTTPリクエストを受信するHTTPリクエスト受信手段46bとを備えるが、管理装置102との通信においては使用しない。
次に、図15に、図11に示した管理装置102の機能構成において、仲介装置101が画像形成装置100と通信を行う場合のデータの流れを示す。そして、図15を参照して、この場合の仲介装置101の機能について説明する。
この場合においては、図11及び図12では図示を省略していた、仲介装置コマンド生成手段43の画像機器コマンド転送ハンドラ43b及び管理装置コマンド実行結果生成手段44の管理装置コマンド転送ハンドラ44bが重要な役割を担う。
この場合においては、図11及び図12では図示を省略していた、仲介装置コマンド生成手段43の画像機器コマンド転送ハンドラ43b及び管理装置コマンド実行結果生成手段44の管理装置コマンド転送ハンドラ44bが重要な役割を担う。
まず、画像機器コマンド転送ハンドラ43bについては、画像機器コマンドを被管理側コマンドプール41に登録し、またそのコマンドに対する応答を画像形成装置100に転送する機能を有する。
すなわち、画像機器コマンド転送ハンドラ43bは、画像形成装置100が生成してSOAPメッセージとしてHTTPリクエストに記載して送信してきた画像機器コマンドを、HTTPサーバ機能部46のHTTPリクエスト受信手段46bを介して受信すると共に、受信した画像機器コマンドに管理情報を付し、IDと関連付けてテーブル形式の被管理側コマンドシートとして被管理側コマンドプール41に登録する機能を有する。この場合において、画像機器コマンド転送ハンドラ43bとHTTPリクエスト受信手段46bとが個別受信手段に該当し、画像機器コマンド転送ハンドラ43bが第2の分配手段に該当する。また、ここで行う処理が、個別受信手順、第2の分配手順の処理に該当する。
すなわち、画像機器コマンド転送ハンドラ43bは、画像形成装置100が生成してSOAPメッセージとしてHTTPリクエストに記載して送信してきた画像機器コマンドを、HTTPサーバ機能部46のHTTPリクエスト受信手段46bを介して受信すると共に、受信した画像機器コマンドに管理情報を付し、IDと関連付けてテーブル形式の被管理側コマンドシートとして被管理側コマンドプール41に登録する機能を有する。この場合において、画像機器コマンド転送ハンドラ43bとHTTPリクエスト受信手段46bとが個別受信手段に該当し、画像機器コマンド転送ハンドラ43bが第2の分配手段に該当する。また、ここで行う処理が、個別受信手順、第2の分配手順の処理に該当する。
またこのとき、被管理側コマンドシートの形式は、仲介装置の場合と全く同じものであり、画像機器コマンドは、仲介装置コマンドの場合と同様に送信メッセージ収集手段45が収集して管理装置102に転送し、管理装置102からの応答は、受信メッセージ分配手段48が分配して被管理側コマンドプールに登録する。
そして、画像機器コマンド転送ハンドラ43bは、この登録があった場合に、被管理側コマンドプール41から画像機器コマンドに対する応答を読み出して、SOAPによる送信メッセージを生成し、HTTPレスポンス送信手段46aを介して、画像形成装置100が画像機器コマンドを記載して送信してきたHTTPリクエストに対するHTTPレスポンスに記載して画像形成装置100に転送する機能も有する。この場合において、画像機器コマンド転送ハンドラ43bとHTTPレスポンス送信手段46aとが個別送信手段として機能し、ここで行う処理が、個別送信手順の処理に該当する。。
また、図示は省略したが、被管理仲介装置110や、被管理仲介装置110の通信相手となる画像形成装置100が被管理側コマンドを生成した場合には、コマンドを被管理仲介装置110から受信すると共に、応答を被管理仲介装置110に転送して必要な処理(画像形成装置100への転送も含む)を実行させることになる。
そして、画像機器コマンド転送ハンドラ43bは、この登録があった場合に、被管理側コマンドプール41から画像機器コマンドに対する応答を読み出して、SOAPによる送信メッセージを生成し、HTTPレスポンス送信手段46aを介して、画像形成装置100が画像機器コマンドを記載して送信してきたHTTPリクエストに対するHTTPレスポンスに記載して画像形成装置100に転送する機能も有する。この場合において、画像機器コマンド転送ハンドラ43bとHTTPレスポンス送信手段46aとが個別送信手段として機能し、ここで行う処理が、個別送信手順の処理に該当する。。
また、図示は省略したが、被管理仲介装置110や、被管理仲介装置110の通信相手となる画像形成装置100が被管理側コマンドを生成した場合には、コマンドを被管理仲介装置110から受信すると共に、応答を被管理仲介装置110に転送して必要な処理(画像形成装置100への転送も含む)を実行させることになる。
次に、管理装置コマンド転送ハンドラ44bについては、管理装置コマンドプール42に登録された、画像形成装置100宛ての管理装置コマンドを画像形成装置100に転送し、応答を取得してこれを管理装置コマンドプールに登録する機能を有する。
すなわち、管理装置コマンド転送ハンドラ44bは、画像形成装置100宛ての管理装置コマンドが管理装置コマンドプール42に登録されている場合、このコマンドに対する処理を行おうとする際に、処理用のハンドラとして呼び出される。そして、この場合、管理装置コマンド転送ハンドラ44bは、管理装置コマンドプール42から管理装置コマンドを読み出し、SOAPによる送信メッセージを生成して、HTTPリクエスト送信手段47aを介してHTTPリクエストに記載して画像形成装置100に転送し、画像形成装置100にそのコマンドに応じた動作を実行させる機能を有する。このときどの画像形成装置100に転送するかは、管理装置コマンドシートの「宛先情報」を参照して定めることができる。また、この場合において、管理装置コマンド転送ハンドラ44bとHTTPリクエスト送信手段47aとが個別送信手段に該当し、ここで行う処理も、個別送信手順の処理に該当する。
すなわち、管理装置コマンド転送ハンドラ44bは、画像形成装置100宛ての管理装置コマンドが管理装置コマンドプール42に登録されている場合、このコマンドに対する処理を行おうとする際に、処理用のハンドラとして呼び出される。そして、この場合、管理装置コマンド転送ハンドラ44bは、管理装置コマンドプール42から管理装置コマンドを読み出し、SOAPによる送信メッセージを生成して、HTTPリクエスト送信手段47aを介してHTTPリクエストに記載して画像形成装置100に転送し、画像形成装置100にそのコマンドに応じた動作を実行させる機能を有する。このときどの画像形成装置100に転送するかは、管理装置コマンドシートの「宛先情報」を参照して定めることができる。また、この場合において、管理装置コマンド転送ハンドラ44bとHTTPリクエスト送信手段47aとが個別送信手段に該当し、ここで行う処理も、個別送信手順の処理に該当する。
そして、画像形成装置100が動作を実行して動作応答をSOAPメッセージとしてHTTPレスポンスに記載して返してくると、HTTPレスポンス受信手段47bを介してこれを受信し、その内容を管理装置コマンドプール42の、実行した管理装置コマンドについての管理装置コマンドシートに登録する。この場合において、管理装置コマンド転送ハンドラ44bとHTTPレスポンス受信手段47bとが個別受信手段に該当し、管理装置コマンド転送ハンドラ44bが第2の分配手段に該当し、ここで行う処理も、個別受信手順及び第2の分配手順の処理に該当する。
なお、管理装置コマンド転送ハンドラ44bは、実際には画像形成装置100に動作応答を生成させるのであるが、呼び出し及び動作応答の登録の方式は、上述した管理装置コマンドハンドラ44aの場合と全く同一である。そこで、他のモジュールから見た場合には、管理装置コマンド転送ハンドラ44bが自身で動作応答を生成しているものと取り扱っても全く問題ない。そして、ここではこのように取り扱うものとする。
また、図示は省略したが、管理装置コマンドの宛先が、被管理仲介装置110や、被管理仲介装置110の通信相手となる画像形成装置100であった場合には、コマンドを被管理仲介装置110に転送して必要な処理(画像形成装置100への転送も含む)を実行させ、応答を取得することになる。
なお、管理装置コマンド転送ハンドラ44bは、実際には画像形成装置100に動作応答を生成させるのであるが、呼び出し及び動作応答の登録の方式は、上述した管理装置コマンドハンドラ44aの場合と全く同一である。そこで、他のモジュールから見た場合には、管理装置コマンド転送ハンドラ44bが自身で動作応答を生成しているものと取り扱っても全く問題ない。そして、ここではこのように取り扱うものとする。
また、図示は省略したが、管理装置コマンドの宛先が、被管理仲介装置110や、被管理仲介装置110の通信相手となる画像形成装置100であった場合には、コマンドを被管理仲介装置110に転送して必要な処理(画像形成装置100への転送も含む)を実行させ、応答を取得することになる。
次に、このような機能を有する仲介装置101が管理装置102に送信するHTTPリクエストの例を図16に示す。
このHTTPリクエストは、図16に示すように、ボディ部としてMIME(Multipurpose Internet Mail Extension)に従ったマルチパートのメッセージが記載され、この各パートには、それぞれエンティティヘッダが記載されると共に、詳細な図示は省略しているが、SOAPエンベロープが埋め込まれている。図16の例では、HTTPリクエストのHTTPボディには、「MIME_boundary」で区分された各要素が、独立した第1パート、第2パート、第3パート、第4パートを構成しているが、HTTPボディに含めることのできるパート数は4つに限られない。0個を含め、いくつでもよい。
このHTTPリクエストは、図16に示すように、ボディ部としてMIME(Multipurpose Internet Mail Extension)に従ったマルチパートのメッセージが記載され、この各パートには、それぞれエンティティヘッダが記載されると共に、詳細な図示は省略しているが、SOAPエンベロープが埋め込まれている。図16の例では、HTTPリクエストのHTTPボディには、「MIME_boundary」で区分された各要素が、独立した第1パート、第2パート、第3パート、第4パートを構成しているが、HTTPボディに含めることのできるパート数は4つに限られない。0個を含め、いくつでもよい。
HTTPリクエストに埋め込まれて引き渡されるSOAPエンベロープには、被管理側コマンドを記載したものと、管理装置コマンドに対する応答を記載したものと、管理装置コマンドに対する遅延通知を記載したものとがある。
また、このような機能を有する仲介装置101が管理装置102から受信するHTTPレスポンスの例を図17に示す。
また、このような機能を有する仲介装置101が管理装置102から受信するHTTPレスポンスの例を図17に示す。
図17に示すように、このHTTPレスポンスは、形式としては図16に示したHTTPリクエストとHTTPヘッダ部が異なるのみであり、ボディ部にはHTTPリクエストの場合と同様に、詳細な図示は省略しているが、MIMEに従ったマルチパートのSOAPエンベロープが記載される。SOAPエンベロープの内容については、当然コマンドやコマンド応答の内容に従って異なるものである。
HTTPレスポンスに埋め込まれて引き渡されるSOAPエンベロープには、管理装置コマンドを記載したものと、被管理側コマンドに対する応答を記載したものと、被管理側コマンドに対する遅延通知を記載したものとがある。
HTTPレスポンスに埋め込まれて引き渡されるSOAPエンベロープには、管理装置コマンドを記載したものと、被管理側コマンドに対する応答を記載したものと、被管理側コマンドに対する遅延通知を記載したものとがある。
そして、以上のような形式のHTTPリクエストやHTTPレスポンスは、転送可能な1つのメッセージであり、各パートのSOAPエンベロープを、形式を変更せずに複数結合して生成することができる。また、このような形式のHTTPリクエストやHTTPレスポンスを分割して各パートのSOAPエンベロープを取り出せば、各SOAPエンベロープ毎に個別に別のHTTPリクエストやHTTPレスポンスに記載して転送することができる。
次に、これらのHTTPリクエスト又はHTTPレスポンスに記載されるパートの具体例を図18乃至図26に示す。
図18に示すのは、画像機器コマンドを記載したパートの例である。
この例においては、まず、エンティティヘッダの部分の「X-SOAP-Type」ヘッダに、このパートに記載されているSOAPメッセージがSOAPリクエストであるかSOAPレスポンスであるかを示す情報を記載している。この例では、値の「Request」により、SOAPリクエストであること、すなわちコマンドを記載したSOAPメッセージであることを示している。
図18に示すのは、画像機器コマンドを記載したパートの例である。
この例においては、まず、エンティティヘッダの部分の「X-SOAP-Type」ヘッダに、このパートに記載されているSOAPメッセージがSOAPリクエストであるかSOAPレスポンスであるかを示す情報を記載している。この例では、値の「Request」により、SOAPリクエストであること、すなわちコマンドを記載したSOAPメッセージであることを示している。
また、「SOAPAction」ヘッダは、SOAPリクエストの内容を示すものであり、この例では、「http://www.…」というURI(Uniform Resource Identifier)によりリクエストの内容を示している。なお、「SOAPAction」ヘッダは、SOAPメッセージがSOAPレスポンスである場合には付加しないため、メッセージの受信側において、このヘッダの有無により、SOAPメッセージがSOAPリクエストであるかSOAPレスポンスであるかを判断することもできる。
そして、「Envelope」タグの属性として、名前空間の宣言を行っている。そしてここでは、SOAPで標準として定義されている名前空間の他に、「http://www.foo.com/header」及び「http://www.foo.com/server」のURIで特定される名前空間の宣言を行っている。従って、「n」の名前空間接頭辞が付されたXMLタグについては「http://www.foo.com/header」のURIで特定される名前空間に属するタグであることがわかり、「ns」の名前空間接頭辞が付されたXMLタグについては「http://www.foo.com/server」のURIで特定される名前空間に属するタグであることがわかる。
またSOAPヘッダには、「要求ID」のXMLタグの内容として、この被管理側コマンドのIDである「12345」が記載されている。
さらに、「送信元」タグの内容として、このコマンドの送信元を示す情報である「仲介装置ID」及び「画像形成装置ID」の情報が記載されている。このうち、「画像形成装置ID」は、この画像機器コマンドを生成した画像形成装置のIDであり、「仲介装置ID」は、この画像機器コマンドが管理装置に転送される際に経由する仲介装置のIDである。これは、被管理側コマンドシートの「送信元情報」に記憶されていた情報である。
さらに、「送信元」タグの内容として、このコマンドの送信元を示す情報である「仲介装置ID」及び「画像形成装置ID」の情報が記載されている。このうち、「画像形成装置ID」は、この画像機器コマンドを生成した画像形成装置のIDであり、「仲介装置ID」は、この画像機器コマンドが管理装置に転送される際に経由する仲介装置のIDである。これは、被管理側コマンドシートの「送信元情報」に記憶されていた情報である。
なお、この遠隔管理システムでは管理装置は1つしかないので、発信元の情報からこのSOAPメッセージが画像機器コマンドを記載したものであることが分かれば、宛先がその管理装置であることは自明であるため、ここでは宛先は特に記載していないが、記載するようにしてもよい。
また、SOAPボディには、被管理側コマンドシートの「メソッド名」に記憶されていたメソッドを指定する情報として、「異常通知」タグが記載され、その下位のタグ「エラーID」や「説明」の要素として、「入力パラメータ」に記憶されていた引数が記載されている。ここでは異常通知の通知内容が記載されている。
また、SOAPボディには、被管理側コマンドシートの「メソッド名」に記憶されていたメソッドを指定する情報として、「異常通知」タグが記載され、その下位のタグ「エラーID」や「説明」の要素として、「入力パラメータ」に記憶されていた引数が記載されている。ここでは異常通知の通知内容が記載されている。
図19に示すのは、管理装置コマンドに対する応答を記載したパートの例である。
この例においては、まず、エンティティヘッダの部分の「X-SOAP-Type」ヘッダの値を「Response」と記載することにより、このパートに記載されているSOAPメッセージがSOAPレスポンスであること、すなわちコマンド応答を記載したSOAPメッセージであることを示している。
また、この例においても、名前空間の宣言は図18に示した例と同様である。そして、SOAPヘッダには、「コマンドID」のXMLタグの内容として、応答を生成した画像機器コマンドのIDである「12345」が記述されている。
この例においては、まず、エンティティヘッダの部分の「X-SOAP-Type」ヘッダの値を「Response」と記載することにより、このパートに記載されているSOAPメッセージがSOAPレスポンスであること、すなわちコマンド応答を記載したSOAPメッセージであることを示している。
また、この例においても、名前空間の宣言は図18に示した例と同様である。そして、SOAPヘッダには、「コマンドID」のXMLタグの内容として、応答を生成した画像機器コマンドのIDである「12345」が記述されている。
さらに、「宛先」タグの内容として、このコマンド応答の宛先を示す情報である「仲介装置ID」及び「画像形成装置ID」の情報が記載されている。このうち、「画像形成装置ID」は、このコマンド応答の最終的な送信先となる画像形成装置のIDであり、「仲介装置ID」は、このコマンド応答が画像形成装置に転送される際に経由する仲介装置のIDである。
なお、この遠隔管理システムでは管理装置は1つしかないので、宛先の情報からこのSOAPメッセージが画像機器コマンドに対する応答を記載したものであることが分かれば、送信元がその管理装置であることは自明であるため、ここでは送信元は特に記載していないが、記載するようにしてもよい。
SOAPボディには、「異常通知」コマンドに対する応答であることを示すための「異常通知Response」タグが設けられ、その下位のタグに、コマンド応答の内容が記載される。ここでは、異常通知を正常に受信した旨の情報が記載されている。そして、この情報が被管理側コマンドシートの「出力パラメータ」の項目に格納される。
SOAPボディには、「異常通知」コマンドに対する応答であることを示すための「異常通知Response」タグが設けられ、その下位のタグに、コマンド応答の内容が記載される。ここでは、異常通知を正常に受信した旨の情報が記載されている。そして、この情報が被管理側コマンドシートの「出力パラメータ」の項目に格納される。
図20に示すのは、仲介装置コマンドを記載したパートの例である。
この例においても、図18の場合と同様に、「X-SOAP-Type」ヘッダの値の「Request」により、このパートに記載されているSOAPエンベロープがSOAPリクエストであることを示し、「SOAPAction」ヘッダの情報により、SOAPリクエストの内容を示している。
この例においても、図18の場合と同様に、「X-SOAP-Type」ヘッダの値の「Request」により、このパートに記載されているSOAPエンベロープがSOAPリクエストであることを示し、「SOAPAction」ヘッダの情報により、SOAPリクエストの内容を示している。
また、「Envelope」タグの属性として、名前空間の宣言を行っている点も、図13の場合と同様である。
SOAPヘッダには、「要求ID」のXMLタグの内容として、この仲介装置コマンドのIDである「12345」が記載されている。また、「送信元」タグの内容として、このコマンドの送信元を示す情報である「仲介装置ID」及び「画像形成装置ID」の情報が記載されているが、このコマンドは仲介装置が生成するものであるので、「仲介装置ID」要素の内容としてその仲介装置のIDが記載され、「画像形成装置ID」要素の内容は空である。
SOAPヘッダには、「要求ID」のXMLタグの内容として、この仲介装置コマンドのIDである「12345」が記載されている。また、「送信元」タグの内容として、このコマンドの送信元を示す情報である「仲介装置ID」及び「画像形成装置ID」の情報が記載されているが、このコマンドは仲介装置が生成するものであるので、「仲介装置ID」要素の内容としてその仲介装置のIDが記載され、「画像形成装置ID」要素の内容は空である。
また、SOAPボディには、被管理側コマンドシートの「メソッド名」に記憶されていたメソッドを指定する情報として、「異常通知」タグが記載され、その下位のタグ「エラーID」や「説明」の要素として、「入力パラメータ」に記憶されていた引数が記載されている。ここでは異常通知の通知内容が記載されている。
図21に示すのは、仲介装置コマンドに対する応答を記載したパートの例である。
この例においても、図19の場合と同様に、エンティティヘッダの部分の「X-SOAP-Type」ヘッダの値を「Response」と記載することにより、このパートに記載されているSOAPメッセージがSOAPレスポンスであることを示している。
また、この例においても、名前空間の宣言は図20に示した例と同様である。そして、SOAPヘッダには、「コマンドID」のXMLタグの内容として、応答を生成した仲介装置コマンドのIDである「12345」が記載されている。さらに、「宛先」タグの内容として、このコマンド応答の宛先を示す情報である「仲介装置ID」の情報が記載されている。「画像形成装置ID」の情報が記載されていない理由は、図20の場合と同様である。
この例においても、図19の場合と同様に、エンティティヘッダの部分の「X-SOAP-Type」ヘッダの値を「Response」と記載することにより、このパートに記載されているSOAPメッセージがSOAPレスポンスであることを示している。
また、この例においても、名前空間の宣言は図20に示した例と同様である。そして、SOAPヘッダには、「コマンドID」のXMLタグの内容として、応答を生成した仲介装置コマンドのIDである「12345」が記載されている。さらに、「宛先」タグの内容として、このコマンド応答の宛先を示す情報である「仲介装置ID」の情報が記載されている。「画像形成装置ID」の情報が記載されていない理由は、図20の場合と同様である。
SOAPボディには、「異常通知」コマンドに対する応答であることを示すための「異常通知Response」タグが設けられ、その下位のタグに、コマンド応答の内容が記載される。ここでは、異常通知を正常に受信した旨の情報が記載されている。そして、この情報が被管理側コマンドシートの「出力パラメータ」の項目に格納される。
図22に示すのは、画像形成装置宛ての管理装置コマンドを記載したパートの例である。
この例においても、図18の場合と同様に、「X-SOAP-Type」ヘッダの値の「Request」により、このパートに記載されているSOAPエンベロープがSOAPリクエストであることを示し、「SOAPAction」ヘッダの情報により、SOAPリクエストの内容を示している。
この例においても、図18の場合と同様に、「X-SOAP-Type」ヘッダの値の「Request」により、このパートに記載されているSOAPエンベロープがSOAPリクエストであることを示し、「SOAPAction」ヘッダの情報により、SOAPリクエストの内容を示している。
また、「Envelope」タグの属性として、名前空間の宣言を行っている点も、図18の場合と同様である。そしてここでは、SOAPで標準として定義されている名前空間の他に、「http://www.foo.com/header」及び「http://www.foo.com/client」のURIで特定される名前空間の宣言を行っている。
SOAPヘッダには、「要求ID」のXMLタグの内容として、この管理装置コマンドのIDである「98765」が記載されている。
SOAPヘッダには、「要求ID」のXMLタグの内容として、この管理装置コマンドのIDである「98765」が記載されている。
さらに、「宛先」タグの内容として、このコマンド応答の宛先を示す情報である「仲介装置ID」及び「画像形成装置ID」の情報が記載されている。このうち、「画像形成装置ID」は、このコマンドに係る動作を実行させる画像形成装置のIDであり、「仲介装置ID」は、このコマンドがその画像形成装置に転送される際に経由する仲介装置のIDである。ここで、「画像形成装置ID」に複数の画像形成装置のIDを記載し、複数の画像形成装置を宛先として指定することもできる。
また、この遠隔管理システムでは管理装置は1つしかないので、宛先の情報からこのSOAPメッセージが管理装置コマンドであることが分かれば、送信元がその管理装置であることは自明であるため、ここでは送信元は特に記載していないが、記載するようにしてもよい。
また、この遠隔管理システムでは管理装置は1つしかないので、宛先の情報からこのSOAPメッセージが管理装置コマンドであることが分かれば、送信元がその管理装置であることは自明であるため、ここでは送信元は特に記載していないが、記載するようにしてもよい。
そして、SOAPボディには、管理装置コマンドシートの「メソッド名」に記憶されるべきメソッドを指定する情報として、「温度センサ値取得」タグが記載され、その下位のタグ「センサID」の要素として、「入力パラメータ」に記憶されるべき引数が記載されている。ここではセンサ値を取得するセンサのIDが記載されている。
なお、管理装置がこのようなコマンドを送信する場合としては、例えば、画像形成装置からの異常通知を受けて異常の原因を特定しようとする場合等が考えられる。
なお、管理装置がこのようなコマンドを送信する場合としては、例えば、画像形成装置からの異常通知を受けて異常の原因を特定しようとする場合等が考えられる。
図23に示すのは、画像形成装置宛ての管理装置コマンドに対する応答を記載したパートの例である。
この例においても、図19の場合と同様に、エンティティヘッダの部分の「X-SOAP-Type」ヘッダの値を「Response」と記載することにより、このパートに記載されているSOAPメッセージがSOAPレスポンスであることを示している。
この例においても、図19の場合と同様に、エンティティヘッダの部分の「X-SOAP-Type」ヘッダの値を「Response」と記載することにより、このパートに記載されているSOAPメッセージがSOAPレスポンスであることを示している。
また、この例においても、名前空間の宣言は図22に示した例と同様である。そして、SOAPヘッダには、「コマンドID」のXMLタグの内容として、応答を生成した管理装置コマンドのIDである「98765」が記載されている。
さらに、「送信元」タグの内容として、このコマンド応答の送信元を示す情報である「仲介装置ID」及び「画像形成装置ID」の情報が記載されている。このうち、「画像形成装置ID」は、このコマンド応答を生成した画像形成装置のIDであり、「仲介装置ID」は、このコマンド応答が管理装置に転送される際に経由する仲介装置のIDである。宛先を記載していない点は、図18等の場合と同様である。
さらに、「送信元」タグの内容として、このコマンド応答の送信元を示す情報である「仲介装置ID」及び「画像形成装置ID」の情報が記載されている。このうち、「画像形成装置ID」は、このコマンド応答を生成した画像形成装置のIDであり、「仲介装置ID」は、このコマンド応答が管理装置に転送される際に経由する仲介装置のIDである。宛先を記載していない点は、図18等の場合と同様である。
また、SOAPボディには、「温度センサ値取得」コマンドに対する応答であることを示すための「温度センサ値取得Response」タグが設けられ、その下位のタグに、コマンド応答の内容が記載される。ここでは、値取得を要求されたセンサの示す温度値の情報が記載されている。
図24に示すのは、仲介装置宛ての管理装置コマンドを記載したパートの例である。
この例においても、図18の場合と同様に、「X-SOAP-Type」ヘッダの値の「Request」により、このパートに記載されているSOAPエンベロープがSOAPリクエストであることを示し、「SOAPAction」ヘッダの情報により、SOAPリクエストの内容を示している。
また、「Envelope」タグの属性として、名前空間の宣言を行っている点も、図18の場合と同様である。そしてここでは、SOAPで標準として定義されている名前空間の他に、「http://www.foo.com/header」及び「http://www.foo.com/agent」のURIで特定される名前空間の宣言を行っている。
この例においても、図18の場合と同様に、「X-SOAP-Type」ヘッダの値の「Request」により、このパートに記載されているSOAPエンベロープがSOAPリクエストであることを示し、「SOAPAction」ヘッダの情報により、SOAPリクエストの内容を示している。
また、「Envelope」タグの属性として、名前空間の宣言を行っている点も、図18の場合と同様である。そしてここでは、SOAPで標準として定義されている名前空間の他に、「http://www.foo.com/header」及び「http://www.foo.com/agent」のURIで特定される名前空間の宣言を行っている。
SOAPヘッダには、「要求ID」のXMLタグの内容として、この管理装置コマンドのIDである「98765」が記載されている。
さらに、「宛先」タグの内容として、このコマンド応答の宛先を示す情報である「仲介装置ID」及び「画像形成装置ID」の情報が記載されているが、このコマンドは仲介装置宛てであるので、「仲介装置ID」要素の内容としてその仲介装置のIDが記載され、「画像形成装置ID」要素の内容は空である。送信元を記載していない点は、図22等の場合と同様である。
さらに、「宛先」タグの内容として、このコマンド応答の宛先を示す情報である「仲介装置ID」及び「画像形成装置ID」の情報が記載されているが、このコマンドは仲介装置宛てであるので、「仲介装置ID」要素の内容としてその仲介装置のIDが記載され、「画像形成装置ID」要素の内容は空である。送信元を記載していない点は、図22等の場合と同様である。
また、SOAPボディには、管理装置コマンドシートの「メソッド名」に記憶されるべきメソッドを指定する情報として、「通信状況確認」タグが記載され、その下位のタグ「機器ID」の要素として、「入力パラメータ」に記憶されるべき引数が記載されている。ここでは、通信状況を確認すべき、仲介装置の通信相手機器のIDが記載されている。ここでは全ての機器を指定するALLを記載している。
なお、管理装置がこのようなコマンドを送信する場合としては、例えば、仲介装置からの異常通知を受けてシステムの状態を確認しようとする場合等が考えられる。
なお、管理装置がこのようなコマンドを送信する場合としては、例えば、仲介装置からの異常通知を受けてシステムの状態を確認しようとする場合等が考えられる。
図25に示すのは、仲介装置宛ての管理装置コマンドに対する応答を記載したパートの例である。
この例においても、図19の場合と同様に、エンティティヘッダの部分の「X-SOAP-Type」ヘッダの値を「Response」と記載することにより、このパートに記載されているSOAPメッセージがSOAPレスポンスであることを示している。
また、この例においても、名前空間の宣言は図24に示した例と同様である。そして、SOAPヘッダには、「コマンドID」のXMLタグの内容として、応答を生成した管理装置コマンドのIDである「98765」が記載されている。
この例においても、図19の場合と同様に、エンティティヘッダの部分の「X-SOAP-Type」ヘッダの値を「Response」と記載することにより、このパートに記載されているSOAPメッセージがSOAPレスポンスであることを示している。
また、この例においても、名前空間の宣言は図24に示した例と同様である。そして、SOAPヘッダには、「コマンドID」のXMLタグの内容として、応答を生成した管理装置コマンドのIDである「98765」が記載されている。
さらに、「送信元」タグの内容として、このコマンド応答の送信元を示す情報である「仲介装置ID」及び「画像形成装置ID」の情報が記載されているが、このコマンド応答は仲介装置が生成するものであるので、「仲介装置ID」要素の内容としてその仲介装置のIDが記載され、「画像形成装置ID」要素の内容は空である。送信元を記載していない点は、図18等の場合と同様である。
また、SOAPボディには、「通信状況確認」コマンドに対する応答であることを示すための「通信状況確認Response」タグが設けられ、その下位のタグに、コマンド応答の内容が記載される。ここでは、通信状況に異常がなかった旨の情報を記載している。
また、SOAPボディには、「通信状況確認」コマンドに対する応答であることを示すための「通信状況確認Response」タグが設けられ、その下位のタグに、コマンド応答の内容が記載される。ここでは、通信状況に異常がなかった旨の情報を記載している。
図26に示すのは、仲介装置宛ての管理装置コマンドに対する遅延通知を記載したパートの例である。
この図に示すように、遅延通知は、SOAPレスポンスとして取扱い、SOAPヘッダについては、コマンドに対して応答を返す場合とほぼ同一の書式となっている。そして、応答を返す場合の書式に加えてSOAPヘッダ中に「遅延」タグを設けてこのSOAPメッセージが遅延通知に係るものであることを示すと共に、SOAPボディは空にしている。なお、「遅延通知」要素の内容として、応答送信予定時刻等の情報を記載するようにしてもよい。
この図に示すように、遅延通知は、SOAPレスポンスとして取扱い、SOAPヘッダについては、コマンドに対して応答を返す場合とほぼ同一の書式となっている。そして、応答を返す場合の書式に加えてSOAPヘッダ中に「遅延」タグを設けてこのSOAPメッセージが遅延通知に係るものであることを示すと共に、SOAPボディは空にしている。なお、「遅延通知」要素の内容として、応答送信予定時刻等の情報を記載するようにしてもよい。
次に、以上説明したような構成及び機能を有する仲介装置101において実行する処理について、図27乃至図35のフローチャートを用いて説明する。これらのフローチャートに示す処理は、仲介装置101のCPU52が所要の制御プログラムを実行することによって行うものである。
まず、図27にメッセージの収集及び分配処理の基本動作のフローチャートを示す。
仲介装置101のCPU52は、送信メッセージ収集手段45が被管理側コマンドやコマンド応答等の読み出しを試みるタイミングになると、図27のフローチャートに示す処理を開始する。
そして、まず被管理側コマンド収集処理を行う(S11)。この処理は、被管理側コマンドプール41から管理装置102に送信すべき被管理側コマンドを収集する処理であり、収集したデータからSOAPエンベロープによるパートを生成する処理を含む。
仲介装置101のCPU52は、送信メッセージ収集手段45が被管理側コマンドやコマンド応答等の読み出しを試みるタイミングになると、図27のフローチャートに示す処理を開始する。
そして、まず被管理側コマンド収集処理を行う(S11)。この処理は、被管理側コマンドプール41から管理装置102に送信すべき被管理側コマンドを収集する処理であり、収集したデータからSOAPエンベロープによるパートを生成する処理を含む。
次に、管理装置コマンドに対する応答である管理装置コマンド実行結果の収集処理を行う(S12)。この処理は、管理装置コマンドプールから管理装置102に送信すべきコマンド応答及び遅延通知を収集する処理であり、やはり収集したデータからSOAPエンベロープによるパートを生成する処理を含む。
その後、ステップS11及びS12の処理で生成したパートを1つにマージして、すべてのパートを含むHTTPリクエストを生成し(S13)、そのHTTPリクエストを管理装置102に送信する(S14)。
ここまでの処理において、ステップS11及びS12が収集手順の処理であり、ここではCPU52は送信メッセージ収集手段45として機能する。また、ステップS13及びS14が一括送信手順の処理であり、ここではCPU52はHTTPリクエスト送信手段47aとして機能する。
その後、ステップS11及びS12の処理で生成したパートを1つにマージして、すべてのパートを含むHTTPリクエストを生成し(S13)、そのHTTPリクエストを管理装置102に送信する(S14)。
ここまでの処理において、ステップS11及びS12が収集手順の処理であり、ここではCPU52は送信メッセージ収集手段45として機能する。また、ステップS13及びS14が一括送信手順の処理であり、ここではCPU52はHTTPリクエスト送信手段47aとして機能する。
次に、HTTPリクエストに対する通信応答として管理装置102からHTTPレスポンスを受信する(S15)。そして、受信したHTTPレスポンスのHTTPボディを各パートに分割する(S16)。ここで、各パートへの分割は、「MIME_boundary」で区分された要素に分割することであり、またここで全てのパートに関して分割する。
そしてその後、分割して得た全てのパートを順に対象として、ステップS17乃至S19の処理を繰り返す。この処理においては、まず対象のパートが管理装置コマンドを記載したパートか否か判断する(S17)。この判断は、対象のパートにSOAPActionヘッダが存在するか否か、あるいはX-SOAP-Typeヘッダの内容によって判断することができる。
そして、管理装置コマンドであれば管理装置コマンド登録処理を行う(S18)。また、管理装置コマンドでないときは、被管理側コマンドに対する応答又は遅延通知が記載されたパートであるので、応答通知処理を行う(S19)。
そしてその後、分割して得た全てのパートを順に対象として、ステップS17乃至S19の処理を繰り返す。この処理においては、まず対象のパートが管理装置コマンドを記載したパートか否か判断する(S17)。この判断は、対象のパートにSOAPActionヘッダが存在するか否か、あるいはX-SOAP-Typeヘッダの内容によって判断することができる。
そして、管理装置コマンドであれば管理装置コマンド登録処理を行う(S18)。また、管理装置コマンドでないときは、被管理側コマンドに対する応答又は遅延通知が記載されたパートであるので、応答通知処理を行う(S19)。
ステップS18又はS19の後は、ステップS17に戻り、次のパートを対象として処理を繰り返す。そして、全てのパートについてこれらの処理を行った時点で、図27のフローチャートに示す処理を終了する。
ここまでの処理において、ステップS15及びS16が一括受信手順の処理であり、ここではCPU52はHTTPレスポンス受信手段47bとして機能する。また、ステップS17乃至S19が第1の分配手順の処理であり、ここでは受信メッセージ分配手段48及び応答状況管理手段49として機能する。
ここまでの処理において、ステップS15及びS16が一括受信手順の処理であり、ここではCPU52はHTTPレスポンス受信手段47bとして機能する。また、ステップS17乃至S19が第1の分配手順の処理であり、ここでは受信メッセージ分配手段48及び応答状況管理手段49として機能する。
次に、図27のフローチャートに示した処理について、一部分ずつより詳細に示したフローチャートを用いて説明する。
図28及び図29は、図27のステップS11乃至S14の部分である送信側の処理をより詳細に示したフローチャートである。このうち、図28にはステップS11に相当する被管理側コマンド収集処理の部分を、図29にはステップS12乃至S14に相当する管理装置コマンド収集処理からHTTPリクエスト送信処理の部分を示している。
図28及び図29は、図27のステップS11乃至S14の部分である送信側の処理をより詳細に示したフローチャートである。このうち、図28にはステップS11に相当する被管理側コマンド収集処理の部分を、図29にはステップS12乃至S14に相当する管理装置コマンド収集処理からHTTPリクエスト送信処理の部分を示している。
この処理においては、仲介装置101のCPU52はまず、被管理側コマンドプール41から、「状態」が「未送信」である被管理側コマンドシートの「メソッド名」と「入力パラメータ」の内容を、送信すべき被管理側コマンドとして収集し、「コマンドID」の内容もそのコマンドのコマンドIDとして、また「送信元情報」の内容もそのコマンドの送信元の情報として収集する(S21)。「未送信」という「状態」は、コマンドが被管理側コマンド生成手段43によって生成された後、まだ管理装置102に送信されていないことを示すものであるので、これを基準に管理装置102に送信すべきコマンドを抽出できる。また、この時、画像機器コマンドと仲介装置コマンドとは区別せずに取り扱う。
その後、ステップS21で収集した全ての被管理側コマンドを順次対象として、ステップS22乃至S24の処理を繰り返す。この部分の処理においては、まず対象の被管理側コマンドと、そのコマンドID及び送信元情報とを、これらの情報がそれぞれSOAPボディとSOAPヘッダとに含まれるXML文書(SOAPエンベロープ)に変換し(S22)、これにエンティティヘッダを付加して対象のコマンドに関するパートを生成する(S23)。そして、対象の被管理側コマンドを記載していた被管理側コマンドシートの「状態」を「応答待ち」に変更する(S24)。「応答待ち」という「状態」は、コマンドを管理装置102に送信済であることを示すものである。
これらが全て完了した後、処理は図29のフローチャートに示す部分に進み、CPU52は、管理装置コマンドプール42から、「状態」が「処理完了」又は「遅延未通知」である管理装置コマンドシートを、送信に係る処理を行う対象にすべきものとして抽出する(S25)。「処理完了」という「状態」は、管理装置コマンドに対応する処理が管理装置コマンド実行結果生成手段44によって生成された後、まだ管理装置102に通知されていないことを示すものであり、また、「遅延未通知」という「状態」は、管理装置コマンド対して遅延通知を行うべき旨が設定されていながらまだ遅延通知を行っていないことを示すものであるので、これらを基準に管理装置102に送信すべき内容を含むシートを抽出できる。
そしてステップS25の後で、ここで抽出した全ての管理装置コマンドシートを順次対象として、ステップS26乃至S33の処理を繰り返す。
これらの処理においては、まず対象の管理装置コマンドシートの「状態」が「処理完了」であるか否か判断する(S26)。そして、「処理完了」であれば、コマンド応答を管理装置102に送信するための処理を行うべくステップS27以下に進み、まず対象の管理装置コマンドシートの「出力パラメータ」の内容を、そのシートに記載された管理装置コマンドに対するコマンド応答として収集し、「コマンドID」の内容も、対応する管理装置コマンドのコマンドIDとして収集して、また「宛先情報」の内容もそのコマンドの宛先すなわちコマンド応答の送信元の情報として収集する(S27)。
これらの処理においては、まず対象の管理装置コマンドシートの「状態」が「処理完了」であるか否か判断する(S26)。そして、「処理完了」であれば、コマンド応答を管理装置102に送信するための処理を行うべくステップS27以下に進み、まず対象の管理装置コマンドシートの「出力パラメータ」の内容を、そのシートに記載された管理装置コマンドに対するコマンド応答として収集し、「コマンドID」の内容も、対応する管理装置コマンドのコマンドIDとして収集して、また「宛先情報」の内容もそのコマンドの宛先すなわちコマンド応答の送信元の情報として収集する(S27)。
その後、ステップS27で収集したコマンド応答と、その応答と共に収集したコマンドID及び送信元の情報とを、これらの情報がそれぞれSOAPボディとSOAPヘッダとに含まれるXML文書(SOAPエンベロープ)に変換し(S28)、これにエンティティヘッダを付加して、対象のシートに記載された管理装置コマンドに対するコマンド応答に関するパートを生成する(S29)。なお、ステップS28及びS29の処理は、対象が異なる点以外はステップS22及びS23の処理と同じものである。そして、次に対象の管理装置コマンドシートの「状態」を「応答済」に変更する(S30)。「応答済」という「状態」は、コマンド応答を管理装置102に送信済であることを示すものである。
一方、ステップS26で「処理完了」でなければ、対象シートの「状態」は「遅延未通知」であるので、遅延通知を管理装置102に送信するための処理を行うべくステップS31以下に進み、まず対象の管理装置コマンドシートに記載されている管理装置コマンドについてのSOAPエンベロープによる遅延通知を作成する(S31)。なお、上述のように、遅延通知の書式はコマンド応答の場合とほぼ同様であるので、シートの「コマンドID」や「宛先情報」等を参照して作成することになる。そして、これにエンティティヘッダを付加して遅延通知に関するパートを生成し(S32)、対象の管理装置コマンドシートの「状態」を「処理待ち」に変更する(S33)。「処理待ち」という「状態」は、遅延通知を管理装置102に送信済であり、コマンドに関する処理の実行を待っている状態であることを示すものである。
ステップS30又はS33の後は、ステップS26に戻り、次のシートを対象として処理を繰り返す。そして、全てのシートについてこれらの処理を行った時点で、CPU52は、ステップS23、S29又はS32で生成した各パートをマージし、図16に示したようなマルチパートのHTTPリクエストを生成して管理装置102に送信する(S34)。
なお、ステップS24、S30又はS33で行った「状態」の変更は、実際にこの送信が終了してから行うようにしてもよい。このようにすることにより、通信エラーが発生しても、送信しようとしていたコマンド及びコマンド応答を再度送信の対象とすることができるので、システムの信頼性が向上する。
以上でHTTPリクエストの送信に関する処理を終了し、図27のステップS15以降に相当する処理に進む。
なお、ステップS24、S30又はS33で行った「状態」の変更は、実際にこの送信が終了してから行うようにしてもよい。このようにすることにより、通信エラーが発生しても、送信しようとしていたコマンド及びコマンド応答を再度送信の対象とすることができるので、システムの信頼性が向上する。
以上でHTTPリクエストの送信に関する処理を終了し、図27のステップS15以降に相当する処理に進む。
図30及び図31は、受信側処理の一部である、図27のステップS18に示した管理装置コマンド登録処理をより詳細に示すフローチャートである。
この処理においては、CPU52は、図27のステップS17の処理で、対象のパートは管理装置コマンドを記載したパートであることがわかっているので、そのパートのSOAPエンベロープを解析して内容を参照できる形式のデータに変換し(S41)、その管理装置コマンドを登録するための管理装置コマンドシートを管理装置コマンドプール42に作成して(S42)、管理装置コマンドとコマンドID及び宛先情報をその管理装置コマンドシートに登録する(S43)。
この処理においては、CPU52は、図27のステップS17の処理で、対象のパートは管理装置コマンドを記載したパートであることがわかっているので、そのパートのSOAPエンベロープを解析して内容を参照できる形式のデータに変換し(S41)、その管理装置コマンドを登録するための管理装置コマンドシートを管理装置コマンドプール42に作成して(S42)、管理装置コマンドとコマンドID及び宛先情報をその管理装置コマンドシートに登録する(S43)。
ここで、管理装置コマンドの内容は管理装置コマンドシートの「メソッド名」及び「入力パラメータ」の項目に登録し、パートに記載されていたコマンドIDは「コマンドID」の項目に登録する。また、コマンドの宛先を示す情報は、「宛先情報」の項目に登録し、管理装置102の情報を「送信元情報」に登録する。なお、後者の情報については、この遠隔管理システムでは一意に定まるので、SOAPエンベロープに記載していなくても必要な情報を参照して作製可能であるし、登録も必須ではない。また、「状態」の初期値は「未処理」であり、「出力パラメータ」の初期値はNULLである。
そして、以上の項目への登録が終了すると、宛先情報を参照して、コマンドの宛先が仲介装置101すなわち自分自身であるか否か判断する(S44)。そして、仲介装置101であれば、管理装置コマンドシートの「メソッド名」に記憶させたメソッドを実行させるためのハンドラ(管理装置コマンドハンドラ44a)への参照情報を、予め用意してあるメソッドとハンドラとの対応関係の情報を参照して検索し(S45)、発見した参照情報を管理装置コマンドシートの「コマンドの通知先」の項目に登録する(S46)。
一方、ステップS44で仲介装置101でなければ、コマンドを宛先に転送するためのハンドラ(管理装置コマンド転送ハンドラ44b)への参照情報を検索し(S47)、発見した参照情報を同様に登録する(S46)。
そして、ここまでの処理で、管理装置コマンドの管理装置コマンドプール42への登録が完了し、続けて応答状況管理のための図31に示す処理に進む。
そして、ここまでの処理で、管理装置コマンドの管理装置コマンドプール42への登録が完了し、続けて応答状況管理のための図31に示す処理に進む。
この処理においては、まず所定時間内に管理装置コマンドに対する応答を生成できるか否か判断する(S51)。この「生成」には、上述のように、画像形成装置等にコマンド転送して応答を取得することも含むが、この場合には、ある程度の時間を要するので、ステップS51の判断は必ずNOにするものとする。
そして、ステップS51で所定時間内に生成できると判断した場合には、ステップS52以下の処理を行って直ちに管理装置コマンドに係る処理を実行する。すなわち、まず登録した管理装置コマンドについての管理装置コマンドシートの「コマンドの通知先」の情報に基づいて管理装置コマンドハンドラ44aを呼び出し、「メソッド名」や「入力パラメータ」のデータを渡して管理装置コマンドに係る処理を実行させる(S52)。なお、管理装置コマンドに係る処理自体は、このフローチャートには示していないが、ハンドラを用いてCPU52が別途実行することになる。
そして、ステップS51で所定時間内に生成できると判断した場合には、ステップS52以下の処理を行って直ちに管理装置コマンドに係る処理を実行する。すなわち、まず登録した管理装置コマンドについての管理装置コマンドシートの「コマンドの通知先」の情報に基づいて管理装置コマンドハンドラ44aを呼び出し、「メソッド名」や「入力パラメータ」のデータを渡して管理装置コマンドに係る処理を実行させる(S52)。なお、管理装置コマンドに係る処理自体は、このフローチャートには示していないが、ハンドラを用いてCPU52が別途実行することになる。
これが完了すると、実行結果を取得して管理装置コマンドシートの「出力パラメータ」の項目に登録する(S53)と共に、管理装置コマンドシートの「状態」を「処理完了」に変更し、処理が完了したことを示す(S54)。以上の処理を行うことにより、管理装置コマンドを実行し、その結果をコマンド応答として管理装置102に送信可能な状態にすることができる。
一方、ステップS51で所定時間内に生成できないと判断した場合には、登録した管理装置コマンドについての管理装置コマンドシートの「状態」を「遅延未通知」に変更して遅延通知が必要であることを示す(S55)。
そして、ステップS54又はS55が完了すると、管理装置コマンド登録処理を終了し、図27に示す通り、次のパートを対象としてステップS17の処理を行うか、次のパートがなければ処理を終了する。
そして、ステップS54又はS55が完了すると、管理装置コマンド登録処理を終了し、図27に示す通り、次のパートを対象としてステップS17の処理を行うか、次のパートがなければ処理を終了する。
次の図32は、受信側処理の一部である、図27のステップS19に示した応答通知処理をより詳細に示すフローチャートである。
この処理においては、図27のステップS17の処理で、対象のパートが被管理側コマンドに対する応答又は遅延通知を記載したパートであることがわかっているので、まずそのパートのSOAPエンベロープを解析して内容を参照できる形式のデータに変換する(S61)。
この処理においては、図27のステップS17の処理で、対象のパートが被管理側コマンドに対する応答又は遅延通知を記載したパートであることがわかっているので、まずそのパートのSOAPエンベロープを解析して内容を参照できる形式のデータに変換する(S61)。
そして、そのデータ中の応答内容を参照し、そのパートがコマンド応答を記載したパートであるか否かを判断する(S62)。遅延通知の場合には、応答内容としてこれが遅延通知である旨の情報が記憶されているので、このような情報がなければコマンド応答であると判断できる。
そして、コマンド応答であれば、被管理側コマンドプール41からそのコマンド応答に対応する被管理側コマンドシート(コマンド応答と対応する被管理側コマンドを登録してあるシート)を探索し、その被管理側コマンドシートの「出力パラメータ」の項目にコマンド応答のデータを登録する(S63)。なお、コマンド応答には、「コマンドID」の情報として、被管理側コマンドの送信時に付したものと同じコマンドIDが付してあるものとし、被管理側コマンドシートの探索は、この情報をキーとして行うことができる。
そして、コマンド応答であれば、被管理側コマンドプール41からそのコマンド応答に対応する被管理側コマンドシート(コマンド応答と対応する被管理側コマンドを登録してあるシート)を探索し、その被管理側コマンドシートの「出力パラメータ」の項目にコマンド応答のデータを登録する(S63)。なお、コマンド応答には、「コマンドID」の情報として、被管理側コマンドの送信時に付したものと同じコマンドIDが付してあるものとし、被管理側コマンドシートの探索は、この情報をキーとして行うことができる。
データの登録が終わると、データを登録した被管理側コマンドシートの「状態」を「応答受信済」に変更してその旨を示す(S64)。そして、「コマンド実行結果の通知先」に登録されている通知先に、応答があった旨を通知する(S65)。この通知によって、被管理側コマンドを生成したハンドラは、その生成したコマンドに応答があったことを認識し、応答に応じた処理を行うことができる。
例えば、異常通知を発する仲介装置コマンド生成ハンドラ43aが管理装置102に異常通知を行う旨の仲介装置コマンドを生成した場合、このコマンドが管理装置102に送信されると、管理装置102はこれを正しく受け取った旨のコマンド応答を返してくる。そして、仲介装置101側では、このコマンド応答を受信すると、ここに含まれるコマンドIDを基にどの被管理側コマンドに対する応答であるかを探索し、見つかった被管理側コマンドと対応させてそのコマンド応答を登録する。そして、そのコマンドの実行結果通知先として登録されている仲介装置コマンド生成ハンドラ43aに、応答があった旨を通知するのである。仲介装置コマンド生成ハンドラ43aは、この通知を受けた場合に被管理側コマンドシートを参照すれば、生成したコマンドの実行結果を「出力パラメータ」の項目から取得することができる。
なお、被管理側コマンドが画像機器コマンドである場合には、この通知を画像機器コマンド転送ハンドラ43bが受け取り、被管理側コマンドシートから必要な情報を読み出して応答のSOAPレスポンスを生成し、HTTPレスポンスに記載して、コマンドの送信元(応答の宛先)である画像形成装置100に送信する。この場合の処理は、被管理側コマンドが仲介装置コマンドである場合と大きく異なるものであるが、図32の処理においては、どちらも応答をハンドラに通知するという点で同じ処理であり、特に区別はない。
また、ステップS62でコマンド応答でなかった場合には、対象のパートは遅延通知を記載したパートであるので、被管理側コマンドプール41からその遅延通知に対応する被管理側コマンドシートを探索し、その被管理側コマンドシートの「状態」の項目を「応答遅延」に変更して遅延通知を受信したことを示す(S66)。この場合にも、「コマンドID」の情報をキーとして探索を行うことができることは、ステップS63の場合と同様である。
その後、「コマンド実行結果の通知先」に登録されている通知先に、遅延通知があった旨を通知する(S67)。この通知によって、被管理側コマンドを生成したハンドラは、その生成したコマンドに遅延通知があったことを認識し、それに応じた処理を行うことができる。なお、被管理側コマンドが画像機器コマンドである場合の取扱いについては、ステップS65の場合と概ね同様であるが、画像形成装置100は遅延通知に対応していないため、画像形成装置100に遅延を通知することはしない。
そして、ステップS64又はS65が完了すると、応答通知処理を終了し、図27に示す通り、次のパートを対象としてステップS17の処理を行うか、次のパートがなければ処理を終了する。
そして、ステップS64又はS65が完了すると、応答通知処理を終了し、図27に示す通り、次のパートを対象としてステップS17の処理を行うか、次のパートがなければ処理を終了する。
以上のようなメッセージの収集及び分配処理を行うことにより、仲介装置101が、画像形成装置100及び仲介装置101自身からの管理装置102宛ての動作要求と、管理装置102からの画像形成装置100及び仲介装置101自身宛ての動作要求に対する動作応答とを一括して管理装置102に送信することができる。また、管理装置102からの画像形成装置100及び仲介装置101自身宛ての動作要求と、画像形成装置100及び仲介装置101自身からの管理装置102宛ての動作要求に対する動作応答とを、一括して管理装置102から受信して処理することができる。
なお、ここでは送信すべき全てのパートを全て生成してからマージして送信を行うようにし、また全てのパートを受信してからこれを各パートに分割して処理を行うように説明したが、このようにする必要はない。
送信については、まず始めにHTTPヘッダを送信し、以後パートを生成するたびにそのパートを順次送信し、全てのパートの送信が完了した時点でその旨のデータを送信するようにしてもよい。このようにしても、これらの課程で送信されるデータが1つのみのHTTPヘッダを持つ論理的に連続した1つのHTTPリクエストであれば、1回のセッションで転送でき、ネゴシエーションの処理は1回で済むので、マージして送信する場合と同様な効果を得ることができる。また、送信すべきデータのバッファに必要なメモリ容量を低減できるので、低コストの通信装置で大きなデータを取り扱うことができる。
また、受信側でも、各パートに関する処理を、各パートを受信するたびに順次行うようにすることができる。このようにした場合に容量を低減できることは、送信側の場合と同様である。
送信については、まず始めにHTTPヘッダを送信し、以後パートを生成するたびにそのパートを順次送信し、全てのパートの送信が完了した時点でその旨のデータを送信するようにしてもよい。このようにしても、これらの課程で送信されるデータが1つのみのHTTPヘッダを持つ論理的に連続した1つのHTTPリクエストであれば、1回のセッションで転送でき、ネゴシエーションの処理は1回で済むので、マージして送信する場合と同様な効果を得ることができる。また、送信すべきデータのバッファに必要なメモリ容量を低減できるので、低コストの通信装置で大きなデータを取り扱うことができる。
また、受信側でも、各パートに関する処理を、各パートを受信するたびに順次行うようにすることができる。このようにした場合に容量を低減できることは、送信側の場合と同様である。
次に、遅延通知をした管理装置コマンドの実行に関する処理について説明する。
図33は、この処理を示すフローチャートである。この処理においては、仲介装置101のCPU52は、管理装置コマンド実行結果生成手段44として機能する。
この処理は、図27に示した管理装置102との間のメッセージの送受信に係る処理とは独立して、CPU52が仲介装置101の起動時に開始するものである。
そして、この処理においては、まず管理装置コマンドプール42に「状態」が「処理待ち」である管理装置コマンドシートがあるか否か判断し(SA1)、なければこのような管理装置コマンドシートを発見するまで待機する。なお、上述のように、「処理待ち」という状態は、管理装置102に対して遅延通知を送信済でかつコマンドに係る処理は未実行あることを示すものである。
図33は、この処理を示すフローチャートである。この処理においては、仲介装置101のCPU52は、管理装置コマンド実行結果生成手段44として機能する。
この処理は、図27に示した管理装置102との間のメッセージの送受信に係る処理とは独立して、CPU52が仲介装置101の起動時に開始するものである。
そして、この処理においては、まず管理装置コマンドプール42に「状態」が「処理待ち」である管理装置コマンドシートがあるか否か判断し(SA1)、なければこのような管理装置コマンドシートを発見するまで待機する。なお、上述のように、「処理待ち」という状態は、管理装置102に対して遅延通知を送信済でかつコマンドに係る処理は未実行あることを示すものである。
ステップSA1で「処理待ち」の管理装置コマンドシートを発見した場合には、その1つを処理対象とし、その管理装置コマンドシートの「状態」を「処理中」に変更する(SA2)。
その後、図31の場合と同様なステップS52乃至S54の処理を行って処理対象の管理装置コマンドシートに記載された管理装置コマンドを実行し、これが完了するとステップSA1に戻って処理を繰り返す。
その後、図31の場合と同様なステップS52乃至S54の処理を行って処理対象の管理装置コマンドシートに記載された管理装置コマンドを実行し、これが完了するとステップSA1に戻って処理を繰り返す。
なお、ステップS52の処理では、図30のステップS46の処理で管理装置コマンドシートの「コマンドの通知先」に登録した参照情報を用いてハンドラを呼び出すが、このハンドラは、管理装置コマンドが仲介装置101宛てである場合には管理装置コマンドハンドラ44aであり、画像形成装置100又は被管理仲介装置110宛てである場合には管理装置コマンド転送ハンドラ44bである。そして、前者の場合には仲介装置101の内部でコマンド応答を生成するのに対し、後者の場合には他の装置にコマンドを転送してコマンド応答を生成させるため、処理が大きく異なる。
しかし、図33の処理においては、ハンドラを呼び出してコマンドに係る処理を実行させるという点で同じ処理であり、特に区別はない。
しかし、図33の処理においては、ハンドラを呼び出してコマンドに係る処理を実行させるという点で同じ処理であり、特に区別はない。
また、以上の処理は、複数のスレッド(例えば4スレッド)で同時に行うようにしてもよい。処理対象となった管理装置コマンドシートの「状態」は、「処理待ち」ではないため、複数のスレッドで同時に処理を行っても、1つの管理装置コマンドシートを重複して処理対象としてしまうことはない。
以上のような処理を行うようにすれば、任意のタイミングで管理装置コマンドを実行することができるので、実行に時間のかかるコマンドがあった場合でも、以後の処理が滞ることがない。そして、実行の終了したものから順に、その結果をコマンド応答として管理装置102に送信可能な状態にすることができる。
なお、図31に示した処理において、ステップS51乃至S54の処理を行わず、全ての管理装置コマンドについて「状態」を「遅延未通知」にして一旦遅延通知を送信するようにし、その後図33に示した処理によって管理装置コマンドに係る処理を実行するようにしてもよい。このようにすれば、処理を単純化できる。そして、このようにした場合、遅延通知は、全てのコマンドについて送信するのであるから、コマンドの受信通知のような意味合いを持つことになる。
なお、図31に示した処理において、ステップS51乃至S54の処理を行わず、全ての管理装置コマンドについて「状態」を「遅延未通知」にして一旦遅延通知を送信するようにし、その後図33に示した処理によって管理装置コマンドに係る処理を実行するようにしてもよい。このようにすれば、処理を単純化できる。そして、このようにした場合、遅延通知は、全てのコマンドについて送信するのであるから、コマンドの受信通知のような意味合いを持つことになる。
次に、対象のコマンドが仲介装置101宛てでない場合の上記の図33のステップS52の処理、すなわち、管理装置コマンド転送ハンドラ44bが実行する処理について、より詳細に説明する。図34はこの処理を示すフローチャートである。なお、ステップS52は図31にも存在するが、対象のコマンドが仲介装置101宛てでない場合には、S51の判断がNOになるので、こちらの処理が実行されることはない。
図34に示す処理においては、まず対象の管理装置コマンドシートに登録されているコマンド(実行対象となる管理装置コマンド)が、仲介装置101の通信相手となる画像形成装置100又は被管理仲介装置110宛てであるか否か判断する(S71)。なお、この遠隔管理システムにおいては、各仲介装置の負荷が過大になることを防止するため、各装置に通信相手となる装置を定めており、同じLANに接続されていたとしても、その定めた装置以外とは通常は通信を行わないようにしている。
図34に示す処理においては、まず対象の管理装置コマンドシートに登録されているコマンド(実行対象となる管理装置コマンド)が、仲介装置101の通信相手となる画像形成装置100又は被管理仲介装置110宛てであるか否か判断する(S71)。なお、この遠隔管理システムにおいては、各仲介装置の負荷が過大になることを防止するため、各装置に通信相手となる装置を定めており、同じLANに接続されていたとしても、その定めた装置以外とは通常は通信を行わないようにしている。
そして、ステップS71の判断がNOであれば、実行対象となる管理装置コマンドは下位の被管理仲介装置110を介して宛先まで転送する必要があるので、対象のシートから、メソッド名、入力パラメータ、コマンドID、宛先情報等の必要な情報を読み出して管理装置コマンドを記載したSOAPメッセージに変換し(S72)、そのSOAPメッセージをHTTPリクエストに記載して、HTTPリクエスト送信手段47aを介して宛先装置への通信経路となる被管理仲介装置110に送信する(S73)。そして、被管理仲介装置110はこれを受け取るとコマンドの宛先まで(必要ならさらに他の被管理仲介装置を介して)転送してコマンドを実行させ、応答を取得してこれを返してくるので、仲介装置101では、その応答を被管理仲介装置110から受信する(S74)。
なお、各仲介装置には、遠隔管理システムを構成する装置のうち、少なくとも自身より下位に接続されている装置については接続関係の情報を保持しており、通信経路はこれを参照して定めることができるものとする。
なお、各仲介装置には、遠隔管理システムを構成する装置のうち、少なくとも自身より下位に接続されている装置については接続関係の情報を保持しており、通信経路はこれを参照して定めることができるものとする。
また、ステップS71の判断がYESであれば、ステップS72の場合と同様にSOAPメッセージを生成し(S75)、そのSOAPメッセージをHTTPリクエストに記載して、HTTPリクエスト送信手段47aを介してコマンドの宛先である画像形成装置100又は被管理仲介装置110に送信する(S76)。そして、宛先の装置はこれを受け取るとコマンドに係る動作を実行し、応答を返してくるので、仲介装置101では、その応答を宛先の装置から受信する(S77)。なお、画像形成装置100には遅延通知を行う機能は設けていないので、所定時間内に応答を受信できない場合には、処理をタイムアウトさせるようにするとよい。
ステップS74又はS77の後は、図33のステップS53以降の処理に進む。
これらの処理が、個別送信手順及び個別受信手順の処理である。
以上で、仲介装置101において実行する、各コマンド及びコマンド応答の転送に関する処理の説明を終了する。
ステップS74又はS77の後は、図33のステップS53以降の処理に進む。
これらの処理が、個別送信手順及び個別受信手順の処理である。
以上で、仲介装置101において実行する、各コマンド及びコマンド応答の転送に関する処理の説明を終了する。
次に、管理装置102側においてコマンド及びコマンド応答を取り扱うための機能構成について説明する。ハードウェアについては、図8を用いて説明した通りである。
図35は、管理装置102の機能のうち、コマンド及びコマンド応答に関する処理を行うための機能の構成を示す機能ブロック図である。
図35に示す各機能は、制御装置126中のCPUが所要の制御プログラムを実行して管理装置102の各部の動作を制御することにより実現されるものである。そして、これらの機能のうち、管理装置コマンドプール141及び被管理側コマンドプール142は、制御装置126中の書き換え可能な記憶手段に設けられるものである。管理装置コマンド生成手段143、被管理側コマンド実行結果生成手段144、送信メッセージ収集手段145、受信メッセージ分配手段148の機能は、制御装置126中のCPUによって実現されるものである。また、HTTPサーバ機能部146の機能は、制御装置126中のCPU及び通信I/Fによって実現されるものである。
図35は、管理装置102の機能のうち、コマンド及びコマンド応答に関する処理を行うための機能の構成を示す機能ブロック図である。
図35に示す各機能は、制御装置126中のCPUが所要の制御プログラムを実行して管理装置102の各部の動作を制御することにより実現されるものである。そして、これらの機能のうち、管理装置コマンドプール141及び被管理側コマンドプール142は、制御装置126中の書き換え可能な記憶手段に設けられるものである。管理装置コマンド生成手段143、被管理側コマンド実行結果生成手段144、送信メッセージ収集手段145、受信メッセージ分配手段148の機能は、制御装置126中のCPUによって実現されるものである。また、HTTPサーバ機能部146の機能は、制御装置126中のCPU及び通信I/Fによって実現されるものである。
図35に示した各手段の機能についてさらに詳述する。
まず、管理装置コマンドプール141は、管理装置102に設けた第2の記憶領域に該当し、管理装置コマンドを、このコマンドに対する応答や、このコマンドの識別情報及びコマンドの宛先や送信元の情報等と関連付けて登録するプールである。また、被管理側コマンドプール142は、管理装置102に設けた第1の記憶領域に該当し、被管理側コマンドを、このコマンドに対する応答や、このコマンドの識別情報及びコマンドの宛先や送信元の情報等と関連付けて登録するプールである。また、これらのプールを設けた記憶手段がそれぞれ管理装置102の第2,第1の記憶手段に該当するものとする。
まず、管理装置コマンドプール141は、管理装置102に設けた第2の記憶領域に該当し、管理装置コマンドを、このコマンドに対する応答や、このコマンドの識別情報及びコマンドの宛先や送信元の情報等と関連付けて登録するプールである。また、被管理側コマンドプール142は、管理装置102に設けた第1の記憶領域に該当し、被管理側コマンドを、このコマンドに対する応答や、このコマンドの識別情報及びコマンドの宛先や送信元の情報等と関連付けて登録するプールである。また、これらのプールを設けた記憶手段がそれぞれ管理装置102の第2,第1の記憶手段に該当するものとする。
管理装置コマンド生成手段143は、要求生成手段に該当する。そして、管理装置コマンドを生成し、このコマンドを識別する識別情報(ID)を割り当て、さらにこのコマンドの宛先情報やこのコマンドを管理するための管理情報を付し、これらの情報を関連付けてテーブル形式の管理装置コマンドシートとして管理装置コマンドプール141に登録する機能を有する。このうち、管理装置コマンドを生成する部分には、例えば管理装置102に備えるアプリケーションが該当する。また、管理装置102の管理装置コマンドシートにおけるデータ構造は、仲介装置101の被管理側コマンドシートにおけるデータ構造と同様なものである。
被管理側コマンド実行結果生成手段144は、応答生成手段に該当する。そして、被管理側コマンドプール142から被管理側コマンドを読み出して実行するアプリケーションである。そして、被管理側コマンドに対する応答を生成し、被管理側コマンドのコマンドIDと関連付けて被管理側コマンドプール142に登録する機能を有する。なお、仲介装置101から受信した被管理側コマンドは、このコマンドを識別するID、このコマンドの送信元情報(コマンド応答の宛先情報となる)及びこのコマンドを管理するための管理情報と関連付けて、テーブル形式の被管理側コマンドシートとして被管理側コマンドプール142に登録しておくようにしている。そして、被管理側コマンド実行結果生成手段144が生成したコマンド応答も、実行した被管理側コマンドについての被管理側コマンドシートに登録する。
また、被管理側コマンド実行結果生成手段144に、被管理側コマンドプール142から複数の種類の被管理側コマンドを読み出し、各被管理側コマンドに対する応答を生成する機能を設けることが考えられる。さらに、被管理側コマンド実行結果生成手段144は、アプリケーションそのものではなく、被管理側コマンドの実行に必要なアプリケーションを呼び出してコマンドを実行させるモジュールであってもよい。
また、管理装置102の被管理側コマンドシートにおけるデータ構造は、仲介装置101の管理装置コマンドシートにおけるデータ構造と同様なものである。
また、管理装置102の被管理側コマンドシートにおけるデータ構造は、仲介装置101の管理装置コマンドシートにおけるデータ構造と同様なものである。
次に、送信メッセージ収集手段145は、収集手段に該当する。そして、被管理側コマンド実行結果生成手段144が生成したコマンド応答とこのコマンド応答に対応する被管理側コマンドのコマンドID及び送信元情報とを関連付けて被管理側コマンドプール142から読み出すと共に、管理装置コマンド生成手段143が生成した管理装置コマンドとこのコマンドのコマンドID及び宛先情報とを関連付けて管理装置コマンドプール141から読み出し、これらから送信メッセージを生成する機能を有する。さらに、遅延通知が必要な被管理側コマンドについて、そのコマンドID及び宛先情報を関連付けて被管理側コマンドプール142から読み出し、遅延通知の送信メッセージを生成する機能も有する。
送信メッセージの形式については、図18乃至図26を用いて説明した通りである。
送信メッセージの形式については、図18乃至図26を用いて説明した通りである。
また、HTTPサーバ機能部146に設けたHTTPレスポンス送信手段146aは、送信手段に該当し、送信メッセージ収集手段145が生成した送信メッセージを含むHTTPレスポンスを、仲介装置101から受信したHTTPリクエストに対する通信応答として生成し、仲介装置101に送信する機能を有する。このとき、1つのHTTPレスポンスに送信メッセージをいくつ含めてもよいし、コマンド応答に係る送信メッセージと管理装置コマンドに係る送信メッセージと遅延通知に係る送信メッセージとを任意に混在させることもできる。もちろん、宛先の異なる送信メッセージを混在させることもできる。
そこで、HTTPレスポンス送信手段146aは、これらのいずれに係る送信メッセージかに関わり無く、送信メッセージ収集手段145が生成した全ての送信メッセージを1つのHTTPレスポンスに含めて送信するようにしている。ただし、1つのHTTPレスポンスに含める送信メッセージの数に上限を設けることも考えられる。
そこで、HTTPレスポンス送信手段146aは、これらのいずれに係る送信メッセージかに関わり無く、送信メッセージ収集手段145が生成した全ての送信メッセージを1つのHTTPレスポンスに含めて送信するようにしている。ただし、1つのHTTPレスポンスに含める送信メッセージの数に上限を設けることも考えられる。
ところで、HTTPレスポンスの送信は、送信メッセージ収集手段145が管理装置コマンドやコマンド応答等の読み出しを試みた場合には、読み出すデータがなく、結果的に送信すべきSOAPメッセージを生成しなかった場合にも行うものである。そして、この読み出しの試みは、仲介装置101からのHTTPリクエストを受信した場合に行うものとする。
これ以外の場面で読み出しを試みても、管理装置102からファイアウォール104を越えて仲介装置101にHTTPリクエストを送信することができないので、送信メッセージを仲介装置101に転送することができない。
これ以外の場面で読み出しを試みても、管理装置102からファイアウォール104を越えて仲介装置101にHTTPリクエストを送信することができないので、送信メッセージを仲介装置101に転送することができない。
また、HTTPリクエスト受信手段146bは、受信手段に該当し、仲介装置101からのHTTPリクエストを受信する機能を有する。そしてここでは、HTTPリクエストには、被管理側コマンド及びそのコマンドと関連付けられたコマンドIDと送信元情報を含む受信メッセージと、管理装置コマンドに対する応答及びそのコマンドと関連付けられたコマンドIDと宛先情報を含む受信メッセージと、管理装置コマンドに対する遅延通知及びそのコマンドと関連付けられたコマンドIDと宛先情報を含む受信メッセージとが、任意に混在して含まれている。
ここで、受信メッセージとは、上記のコマンドや応答あるいは遅延通知と、コマンドID及び送信元情報等とをSOAPメッセージとして記載したものである。
ここで、受信メッセージとは、上記のコマンドや応答あるいは遅延通知と、コマンドID及び送信元情報等とをSOAPメッセージとして記載したものである。
受信メッセージ分配手段148は、分配手段に該当する。そして、HTTPリクエスト受信手段146bが受信したHTTPリクエストに含まれるデータを、管理装置コマンドプール141及び被管理側コマンドプール142に振り分けて登録する機能を有する。
具体的には、被管理側コマンド及びそのコマンドと関連付けられたコマンドID及び送信元情報とを被管理側コマンドプール142に被管理側コマンドシートを設けて登録すると共に、管理装置コマンドに対する応答については、その応答と関連付けられたコマンドIDを管理装置コマンドプール141に記憶している管理装置コマンドシートのコマンドIDと照合して対応する管理装置コマンドシートを特定し、その管理装置コマンドシートの「出力パラメータ」の項目に登録する。管理装置コマンドに対する遅延通知については、やはりコマンドIDをもとに管理装置コマンドシートを特定し、そのコマンドシートの「状態」を「応答遅延」に変更して応答の受信が遅延することを示す。
具体的には、被管理側コマンド及びそのコマンドと関連付けられたコマンドID及び送信元情報とを被管理側コマンドプール142に被管理側コマンドシートを設けて登録すると共に、管理装置コマンドに対する応答については、その応答と関連付けられたコマンドIDを管理装置コマンドプール141に記憶している管理装置コマンドシートのコマンドIDと照合して対応する管理装置コマンドシートを特定し、その管理装置コマンドシートの「出力パラメータ」の項目に登録する。管理装置コマンドに対する遅延通知については、やはりコマンドIDをもとに管理装置コマンドシートを特定し、そのコマンドシートの「状態」を「応答遅延」に変更して応答の受信が遅延することを示す。
そしてこのとき、HTTPリクエストを分割してそこに含まれる各受信メッセージを取り出し、そのデータをテーブルへの登録に必要な形式に変換するが、この変換は、WSDLに基づいて生成される所要の変換プログラム(デシリアライザ)を実行することによって行うことができる。
このような機能を有する管理装置102が受信するHTTPリクエストは、仲介装置101から送信されてくるものであるので、例えば仲介装置101の機能の説明中で図16を用いて説明したものである。管理装置102が送信するHTTPレスポンスも、仲介装置101に対して送信し、仲介装置101が受信するものであるので、例えば図17を用いて説明したものである。これらに含まれるパートの内容も、図18乃至図26を用いて説明したようなものとなる。
このような機能を有する管理装置102が受信するHTTPリクエストは、仲介装置101から送信されてくるものであるので、例えば仲介装置101の機能の説明中で図16を用いて説明したものである。管理装置102が送信するHTTPレスポンスも、仲介装置101に対して送信し、仲介装置101が受信するものであるので、例えば図17を用いて説明したものである。これらに含まれるパートの内容も、図18乃至図26を用いて説明したようなものとなる。
次に、以上説明したような構成及び機能を有する管理装置102において実行する処理について説明する。
図36にメッセージの収集及び分配処理の基本動作のフローチャートを示すが、このフローチャートに示す処理は、管理装置102における制御装置126中のCPUが所要の制御プログラムを実行することによって行うものである。
図36にメッセージの収集及び分配処理の基本動作のフローチャートを示すが、このフローチャートに示す処理は、管理装置102における制御装置126中のCPUが所要の制御プログラムを実行することによって行うものである。
制御装置126中のCPUは、仲介装置101からHTTPリクエストが送信されてくると、図36のフローチャートに示す処理を開始する。
そして、まずそのHTTPリクエストを受信する(S311)。そして、受信したHTTPリクエストのHTTPボディを各パートに分割する(S312)。ここで、各パートへの分割は、「MIME_boundary」で区分された要素に分割することであり、またここで全てのパートに関して分割する。
そして、まずそのHTTPリクエストを受信する(S311)。そして、受信したHTTPリクエストのHTTPボディを各パートに分割する(S312)。ここで、各パートへの分割は、「MIME_boundary」で区分された要素に分割することであり、またここで全てのパートに関して分割する。
そしてその後、分割して得た全てのパートを順に対象として、ステップS313乃至S315の処理を繰り返す。この処理においては、まず対象のパートが被管理側コマンドを記載したパートか否か判断する(S313)。そして、被管理側コマンドであれば被管理側コマンド登録処理を行う(S314)。また、被管理側コマンドでないときは、管理装置コマンドに対する応答が記載されたパートであるので、応答通知処理を行う(S315)。
ステップS314又はS315の後は、ステップS313に戻り、次のパートを対象として処理を繰り返す。そして、全てのパートについてこれらの処理を行った時点で、次のステップS316に進む。
ここまでの処理において、ステップS311及びS312では制御装置126中のCPUはHTTPリクエスト受信手段146bとして機能し、ステップS313乃至S315では受信メッセージ分配手段148として機能する。
ここまでの処理において、ステップS311及びS312では制御装置126中のCPUはHTTPリクエスト受信手段146bとして機能し、ステップS313乃至S315では受信メッセージ分配手段148として機能する。
次に、制御装置126中のCPUは管理装置コマンドの収集処理を行う(S316)。この処理は、管理装置コマンドプール141から仲介装置101に送信すべき管理装置コマンドを収集する処理であり、収集したデータからSOAPエンベロープによるパートを生成する処理を含む。
次に、被管理側コマンドに対する応答である被管理側コマンド実行結果の収集処理を行う(S317)。この処理は、被管理側コマンドプール142から仲介装置101に送信すべきコマンド応答及び遅延通知を収集する処理であり、やはり収集したデータからSOAPエンベロープによるパートを生成する処理を含む。
次に、被管理側コマンドに対する応答である被管理側コマンド実行結果の収集処理を行う(S317)。この処理は、被管理側コマンドプール142から仲介装置101に送信すべきコマンド応答及び遅延通知を収集する処理であり、やはり収集したデータからSOAPエンベロープによるパートを生成する処理を含む。
その後、ステップS316及びS317の処理で生成したパートを1つにマージして、すべてのパートを含むHTTPレスポンスを生成し(S318)、そのHTTPレスポンスを、ステップS311で受信したHTTPリクエストに対する通信応答として仲介装置101に送信して(S319)処理を終了する。
ここまでの処理において、ステップS316及びS317では制御装置126中のCPUは送信メッセージ収集手段145として機能し、ステップS318及びS319ではHTTPレスポンス送信手段146aとして機能する。
ここまでの処理において、ステップS316及びS317では制御装置126中のCPUは送信メッセージ収集手段145として機能し、ステップS318及びS319ではHTTPレスポンス送信手段146aとして機能する。
これらの処理の詳細については、仲介装置101側の説明において図28乃至図32を用いて説明した処理と同様であるので、詳細な説明は省略する。ただし、被管理側コマンドと管理装置コマンドの位置付けが逆になった点及び、HTTPリクエストを受信してHTTPレスポンスを送信することから受信用のステップS311乃至S315の処理を送信用のステップS316乃至S319の処理よりも先に行う点は仲介装置101の場合と異なる。また、図示は省略したが、管理装置102側では、遅延通知をした被管理側コマンドの実行処理として、図33に示した処理と対応する処理も行っている。
なお、管理装置102は、受信したコマンドやコマンド応答をさらに他の装置に転送することはしないため、ステップS314の被管理側コマンド登録処理は、仲介装置101側の対応する処理である管理装置コマンド登録処理(図30及び図31に詳細を示した)とはこの点で異なる。そこで、図37を用いて、この相違点について説明を補足する。図37は、管理装置102における被管理側コマンド登録処理(S314)をより詳細に示すフローチャートである。この図から分かるように、この処理は、基本的には図30及び図31に示した処理と対応するものであり、扱うコマンドが管理装置コマンドではなく被管理側コマンドである点で異なるものであるが、図30のステップS44及びS47に対応する処理を設けていない点が異なるものである。
以上で、管理装置102において実行する、各コマンド及びコマンド応答の取扱いに関する処理の説明を終了する。
以上で、管理装置102において実行する、各コマンド及びコマンド応答の取扱いに関する処理の説明を終了する。
次に、画像形成装置100側においてコマンド及びコマンド応答を取り扱うための機能構成について説明する。ハードウェアについては、図9を用いて説明した通りである。
図38及び図39は、画像形成装置100の機能のうち、コマンド及びコマンド応答に関する処理を行うための機能の構成を示す機能ブロック図である。これらの図において、図38には管理装置コマンドを取り扱う場合のデータの流れを示す矢印を記載し、図39には画像機器コマンドを取り扱う場合のデータの流れを示す矢印を記載している。
これらの図に示す各機能は、CPU201が所要の制御プログラムを実行して画像形成装置100の各部の動作を制御することにより実現されるものである。そして、これらの機能のうち、管理装置コマンド実行結果生成手段243及び画像機器コマンド生成手段244の機能は、CPU201によって実現されるものである。また、HTTPサーバ機能部246及びHTTPクライアント機能部247の機能は、CPU201及びPHY206によって実現されるものである。
図38及び図39は、画像形成装置100の機能のうち、コマンド及びコマンド応答に関する処理を行うための機能の構成を示す機能ブロック図である。これらの図において、図38には管理装置コマンドを取り扱う場合のデータの流れを示す矢印を記載し、図39には画像機器コマンドを取り扱う場合のデータの流れを示す矢印を記載している。
これらの図に示す各機能は、CPU201が所要の制御プログラムを実行して画像形成装置100の各部の動作を制御することにより実現されるものである。そして、これらの機能のうち、管理装置コマンド実行結果生成手段243及び画像機器コマンド生成手段244の機能は、CPU201によって実現されるものである。また、HTTPサーバ機能部246及びHTTPクライアント機能部247の機能は、CPU201及びPHY206によって実現されるものである。
これらの各手段の機能についてさらに詳述する。
まず、管理装置コマンド実行結果生成手段243は、応答生成手段に該当する。そして、HTTPリクエスト受信手段246bを介して受信した管理装置コマンドに係る動作を実行し、実行結果として動作応答を生成し、これをHTTPレスポンス送信手段246aを介して送信する機能を有する。すなわち、ウェブサービスを提供する機能を有する。
なお、この遠隔管理システムにおいては、管理装置コマンドは、仲介装置101からHTTPリクエストに記載された状態でSOAPリクエストとして送信されてくるので、管理装置コマンド実行結果生成手段243が生成した動作応答は、このHTTPリクエストに対するHTTPレスポンスにSOAPレスポンスとして記載して仲介装置101に返すことになる。この場合において、HTTPリクエスト受信手段246bが受信手段として、HTTPレスポンス送信手段246aが送信手段としてそれぞれ機能する。
まず、管理装置コマンド実行結果生成手段243は、応答生成手段に該当する。そして、HTTPリクエスト受信手段246bを介して受信した管理装置コマンドに係る動作を実行し、実行結果として動作応答を生成し、これをHTTPレスポンス送信手段246aを介して送信する機能を有する。すなわち、ウェブサービスを提供する機能を有する。
なお、この遠隔管理システムにおいては、管理装置コマンドは、仲介装置101からHTTPリクエストに記載された状態でSOAPリクエストとして送信されてくるので、管理装置コマンド実行結果生成手段243が生成した動作応答は、このHTTPリクエストに対するHTTPレスポンスにSOAPレスポンスとして記載して仲介装置101に返すことになる。この場合において、HTTPリクエスト受信手段246bが受信手段として、HTTPレスポンス送信手段246aが送信手段としてそれぞれ機能する。
一方、画像機器コマンド生成手段244は、要求生成手段に該当する。そして、画像機器コマンドを生成し、このコマンドを識別する識別情報(ID)を割り当て、さらにこのコマンドの宛先情報を付して、これらの情報を記載した画像機器コマンドに係るSOAPリクエストを生成する機能を有する。このSOAPリクエストの形式は、例えば図18に示したようなものである。
そして、HTTPリクエスト送信手段247aが送信手段に該当し、画像機器コマンド生成手段244が生成したSOAPリクエストをHTTPリクエストに記載して仲介装置101に送信する機能を有する。
そして、HTTPリクエスト送信手段247aが送信手段に該当し、画像機器コマンド生成手段244が生成したSOAPリクエストをHTTPリクエストに記載して仲介装置101に送信する機能を有する。
また、仲介装置101が管理装置102から画像機器コマンドに対する応答を受信すると、この応答に係るSOAPレスポンスを、画像機器コマンドを記載したHTTPリクエストに対するHTTPレスポンスに記載して画像形成装置100に送信してくるが、HTTPレスポンス受信手段247bはこれを受信する機能を有し、受信手段に該当する。そして、画像機器コマンド生成手段244は、HTTPレスポンス受信手段247bからこのSOAPレスポンスを受け取り、そこに記載された応答に応じた処理を行う機能も有する。
以上のように、画像形成装置100は、画像機器コマンドを生成すると共にこのコマンドに対する応答を受信する機能を有し、また、管理装置コマンドを受信し、これに対するコマンド応答を生成して送信する機能を有する。しかし、仲介装置101や管理装置102の場合のように、コマンドプールや収集手段、分配手段は設けていないため、コマンドやコマンド応答の送受信は、1つずつ行うことになる。即ち、1つのHTTPリクエスト又はHTTPレスポンスに、1つのコマンド又はコマンド応答を記載して送受信することになる。
また、図示は省略したが、画像形成装置100で仲介装置101宛ての動作要求が発生した場合あるいは逆に仲介装置101で画像形成装置100宛ての動作要求が発生した場合にも、コマンドプールや収集手段、分配手段は使用しない。そして、要求が発生した側で要求を1つのHTTPリクエストに記載して相手に送信し、要求を受ける側では要求の受信時に要求に係る動作を実行して動作結果をHTTPレスポンスに記載して返信する処理を行う。
また、図示は省略したが、画像形成装置100で仲介装置101宛ての動作要求が発生した場合あるいは逆に仲介装置101で画像形成装置100宛ての動作要求が発生した場合にも、コマンドプールや収集手段、分配手段は使用しない。そして、要求が発生した側で要求を1つのHTTPリクエストに記載して相手に送信し、要求を受ける側では要求の受信時に要求に係る動作を実行して動作結果をHTTPレスポンスに記載して返信する処理を行う。
ここで、図40に、以上説明してきた遠隔管理システムにおいて、画像形成装置100が画像機器コマンドを生成してからそのコマンドに対する応答を受け取るまでに各装置において行われる一連の処理を示す。また、図41に、管理装置102が画像形成装置100宛ての管理装置コマンドを生成してからそのコマンドに対する応答を受け取るまでに各装置において行われる一連の処理を示す。なお、これらの図において、遅延通知は考慮していない。
これらの図に示す処理の各々は、既に説明した処理のいずれかであるので、詳細な説明は省略するが、以上説明してきた遠隔管理システムにおいては、このような処理を行うことにより、管理装置102と画像形成装置100との間のコマンド及びコマンド応答の送受信を、仲介装置101によって仲介して行うことができる。
これらの図に示す処理の各々は、既に説明した処理のいずれかであるので、詳細な説明は省略するが、以上説明してきた遠隔管理システムにおいては、このような処理を行うことにより、管理装置102と画像形成装置100との間のコマンド及びコマンド応答の送受信を、仲介装置101によって仲介して行うことができる。
そして、以上の説明からわかるように、この遠隔管理システムにおいては、仲介装置101を設け、画像形成装置100と管理装置102との間の通信を、この仲介装置101を介して行うようにしたことにより、管理装置102から複数の画像形成装置100に宛てた動作要求を送信する場合でも、仲介装置101までは一括して送信でき、また複数の画像形成装置100に宛てた動作要求に対する動作応答も仲介装置101から一括して受信できるので、動作要求の送信と動作応答の送信とについて別々にネゴシエーションを行って通信のコネクションを確立する必要がなく、通信のオーバーヘッドを低減して通信効率を高めることができる。
管理装置102が仲介装置101宛ての動作要求を送信したり、仲介装置101や画像形成装置100から管理装置102宛ての動作要求を送信したりして、各々動作応答を受信する場合でも、管理装置102と仲介装置101の間の転送を一括して行うことができるので、高い通信効率を維持することができる。画像形成装置100の数が多くなり、また管理装置102と画像形成装置100や仲介装置101との間で転送すべき動作要求や動作応答が多くなればなるほど、この効果は大きくなる。
また、画像形成装置100と仲介装置101との間では、上記のような一括転送は行わず、動作要求や動作応答を個別に転送するようにしているので、一括転送に対応していないシンプルな機能の画像形成装置100でも、仲介装置101に通信を仲介させることにより、特に機能の拡張を行うことなく、管理装置102と通信を行う場合の通信効率を向上させることができる。そして、このようにしたとしても、画像形成装置100と仲介装置101とは通常はLANのような通信相手が限定されたネットワークを介して通信を行うため、ネゴシエーションの処理負荷は小さくて済むので、通信の回数が増えてもさほど通信効率は低下しない。さらに、画像形成装置100を複雑な通信プロトコルに対応させる必要がないので、全体としてシステムを構成するための手間やコストを抑えることができる。
また、画像形成装置100と仲介装置101との間では、上記のような一括転送は行わず、動作要求や動作応答を個別に転送するようにしているので、一括転送に対応していないシンプルな機能の画像形成装置100でも、仲介装置101に通信を仲介させることにより、特に機能の拡張を行うことなく、管理装置102と通信を行う場合の通信効率を向上させることができる。そして、このようにしたとしても、画像形成装置100と仲介装置101とは通常はLANのような通信相手が限定されたネットワークを介して通信を行うため、ネゴシエーションの処理負荷は小さくて済むので、通信の回数が増えてもさほど通信効率は低下しない。さらに、画像形成装置100を複雑な通信プロトコルに対応させる必要がないので、全体としてシステムを構成するための手間やコストを抑えることができる。
また、動作要求と動作応答とを一括して送信できるのは、これらをそれぞれ直列化したデータに変換し、構造化言語形式で記載した送信メッセージに変換しているためである。このようにしたことにより、フォーマットの異なる動作要求と動作応答とを容易に結合し、論理的に1つの送信内容として送信することができるのである。
そして、このようにしたことにより、仲介装置101や管理装置102が、一括して受信した動作要求と動作応答とを、容易に個々のメッセージに分離し、それが動作要求であるか動作応答であるか、またその宛先に応じて、適切な処理を行うことができる。
また、動作要求及び動作応答をそれぞれ、形式を変更せずに複数結合して転送可能な1つのメッセージを生成することができる形式で表現し、また複数結合された状態では形式を変更せずに分割して転送可能な個々の動作要求及び動作応答に戻すことができる形式となるようにすれば、動作要求や動作応答の結合や分割を行う際の処理負荷を低減することができる。
そして、このようにしたことにより、仲介装置101や管理装置102が、一括して受信した動作要求と動作応答とを、容易に個々のメッセージに分離し、それが動作要求であるか動作応答であるか、またその宛先に応じて、適切な処理を行うことができる。
また、動作要求及び動作応答をそれぞれ、形式を変更せずに複数結合して転送可能な1つのメッセージを生成することができる形式で表現し、また複数結合された状態では形式を変更せずに分割して転送可能な個々の動作要求及び動作応答に戻すことができる形式となるようにすれば、動作要求や動作応答の結合や分割を行う際の処理負荷を低減することができる。
さらに、管理装置102と仲介装置101との間の通信について、通信要求を常に仲介装置101から発して通信を行い、その管理装置102から仲介装置101への動作要求等の送信は、その通信要求に対する応答として行うようにすれば、仲介装置101がファイアウォールの内側に設けられている場合であっても、ファイアウォールの存在を意識せずに動作要求及び動作応答の送受信を行うことができる。また、通信要求と通信応答とが対応しているため、通信のレベルでのタイミング管理が容易である。
この場合において、上記の仲介装置101から管理装置102に定期的に通信要求を送信するようにすれば、管理装置102から仲介装置101や画像形成装置100に向けての情報の送信が長時間に亘って停滞してしまう事態を防止できる。
この場合において、上記の仲介装置101から管理装置102に定期的に通信要求を送信するようにすれば、管理装置102から仲介装置101や画像形成装置100に向けての情報の送信が長時間に亘って停滞してしまう事態を防止できる。
また、画像形成装置100と仲介装置101との間では、どちらから通信要求を発しても通信を行うことができるようにしているので、ファイアウォール越しに通信するためのプロトコルに対応していないシンプルな機能の画像形成装置100であっても、仲介装置101に通信を仲介させることにより、特に機能の拡張を行うことなく管理装置102と動作要求及び動作応答の送受信を行うことができるようになる。そして、画像形成装置100と仲介装置101との間には通常はファイアウォールは設けないので、このような構成にした方が、動作要求や動作応答の転送を適切なタイミングで行うことができる。
また、画像形成装置100をファイアウォール越しに通信するためのプロトコルに対応させたとしても、情報送信の停滞を防止するためには上記のような定期的な通信要求を個々に行うことになるため、管理装置102に多数の通信要求が殺到することになり、通信のオーバーヘッドの面でも、管理装置102の処理負荷の面でも好ましくないので、仲介装置101を設けて仲介装置101に代表で定期的な通信要求を行わせることが好ましい。
また、画像形成装置100をファイアウォール越しに通信するためのプロトコルに対応させたとしても、情報送信の停滞を防止するためには上記のような定期的な通信要求を個々に行うことになるため、管理装置102に多数の通信要求が殺到することになり、通信のオーバーヘッドの面でも、管理装置102の処理負荷の面でも好ましくないので、仲介装置101を設けて仲介装置101に代表で定期的な通信要求を行わせることが好ましい。
また、仲介装置101において被管理側コマンドプールや管理装置コマンドプールを設け、各アプリケーション等が生成したり、管理装置102あるいは画像形成装置100から受信したりした動作要求や動作応答を、これらのプールに蓄積しておくようにすることにより、動作要求や動作応答の生成及び送受信を、その転送先に対する送信タイミングを考慮せずに行うことができる。従って、処理のタイミング管理を簡略化することができ、設計や開発が容易になる。管理装置102においても、これらのプールを設けることにより、同様に動作要求や動作応答の生成のタイミング管理を簡略化することができ、設計や開発が容易になる。
そして、このようにした場合でも、通信相手に送信すべき動作要求や動作応答をプールから読み出す収集手段を設けることにより、通信を行う場合に、送信すべき情報を漏れなく送信することができる。
また、受信した動作要求や動作応答を各々分離して適切なプールに記憶させる分配手段を設け、受信した情報もプールに蓄積しておくようにすることにより、受信した動作要求に係る動作の実行や、動作応答受信後の処理、動作要求及び動作応答の転送を、通信相手からの受信タイミングを考慮せずに行うことができる。従って、タイミング管理を簡略化することができ、設計や開発が容易になる。
また、受信した動作要求や動作応答を各々分離して適切なプールに記憶させる分配手段を設け、受信した情報もプールに蓄積しておくようにすることにより、受信した動作要求に係る動作の実行や、動作応答受信後の処理、動作要求及び動作応答の転送を、通信相手からの受信タイミングを考慮せずに行うことができる。従って、タイミング管理を簡略化することができ、設計や開発が容易になる。
また、生成した動作要求にID等の識別情報を付して、動作要求を記憶、送信する際にこの識別情報と関連付けて行うようにし、また動作応答を記憶、送信する際にも対応する動作要求の識別情報と関連付けて行うようにすれば、1つのメッセージ(ここではHTTPメッセージ)に複数の動作要求や動作応答を含める場合でも、その識別情報を媒介に動作要求と動作応答との対応関係を容易に認識することができる。
さらに、動作要求に優先順位を付して、これが高いものから順に実行したり応答を送信したりするようにすれば、緊急を要する動作を優先的に実行すると共にその応答も優先的に返すことができる。
さらに、動作要求に優先順位を付して、これが高いものから順に実行したり応答を送信したりするようにすれば、緊急を要する動作を優先的に実行すると共にその応答も優先的に返すことができる。
〔第1の実施例の変形例:図42〕
次に、上述した第1の実施例の変形例について説明する。この変形例は、仲介装置101が実行する管理装置コマンド登録処理の一部が第1の実施例の遠隔管理システムと異なるのみである。従って、これ以外の点は説明を省略する。図42は、この変形例における管理装置コマンド登録処理の一部を示すフローチャートである。
この変形例では、仲介装置101は、図27のステップS18の管理装置コマンド登録処理において、第1の実施例で図30を用いて説明した処理に代えて、図42に示す処理を行う。すなわち、まず図27のステップS17乃至S19のループで処理対象となっているパートのSOAPエンベロープを、SOAPヘッダのみ解析して内容を参照できる形式のデータに変換すると共に(S81)、その管理装置コマンドを登録するための管理装置コマンドシートを管理装置コマンドプール42に作成する(S82)。その後、SOAPヘッダに記載されていた宛先情報を参照して、対象パートに記載されている管理装置コマンドの宛先が仲介装置101自身であるか否か判断する。(S83)。
次に、上述した第1の実施例の変形例について説明する。この変形例は、仲介装置101が実行する管理装置コマンド登録処理の一部が第1の実施例の遠隔管理システムと異なるのみである。従って、これ以外の点は説明を省略する。図42は、この変形例における管理装置コマンド登録処理の一部を示すフローチャートである。
この変形例では、仲介装置101は、図27のステップS18の管理装置コマンド登録処理において、第1の実施例で図30を用いて説明した処理に代えて、図42に示す処理を行う。すなわち、まず図27のステップS17乃至S19のループで処理対象となっているパートのSOAPエンベロープを、SOAPヘッダのみ解析して内容を参照できる形式のデータに変換すると共に(S81)、その管理装置コマンドを登録するための管理装置コマンドシートを管理装置コマンドプール42に作成する(S82)。その後、SOAPヘッダに記載されていた宛先情報を参照して、対象パートに記載されている管理装置コマンドの宛先が仲介装置101自身であるか否か判断する。(S83)。
そして、コマンドが仲介装置101宛てであれば、対象パートのSOAPボディも解析して内容を参照できる形式のデータに変換し(S84)、ステップS82で作成した管理装置コマンドシートに管理装置コマンドとコマンドID及び宛先情報を登録する(S85)。各項目への登録内容については、第1の実施例の場合と同様である。そして、各項目への登録が終了すると、仲介装置101が管理装置コマンドシートの「メソッド名」に記憶させたメソッドを実行するためのハンドラ(管理装置コマンドハンドラ44a)への参照情報を、予め用意してあるメソッドとハンドラとの対応関係の情報を参照して検索し(S86)、発見した参照情報を管理装置コマンドシートの「コマンドの通知先」の項目に登録する(S87)。
一方、ステップS83で仲介装置101でなければ、対象パートのSOAPエンベロープを、作成した管理装置コマンドシートの「入力パラメータ」の項目にXMLのまま登録すると共に(S88)、SOAPヘッダに記載されていたコマンドID及び宛先情報については、ステップS81での変換後のデータを管理装置コマンドシートに登録する(S89)。そして、コマンドを宛先に転送するためのハンドラ(管理装置コマンド転送ハンドラ44b)への参照情報を検索し(S90)、発見した参照情報を登録する(S87)。
ステップS87より後の処理は、第1の実施例の場合と同様である。
ステップS87より後の処理は、第1の実施例の場合と同様である。
この変形例においては、以上のように、仲介装置101自身以外が宛先であり、宛先まで転送する必要があるコマンドについては、SOAPボディを解析せず、SOAPエンベロープ全体をXMLのままコマンドシートに登録するようにしている。従って、この変形例では、管理装置コマンドを宛先に転送する処理を行う際に、管理装置コマンドシートの「入力パラメータ」の項目から読み出したデータをそのまま転送すればよいことになる。
第1の実施例では、コマンドを転送する際に、コマンドシートから読み出したデータからSOAPメッセージを生成する必要があったが、この変形例ではこの処理が不要であり、処理負荷を低減することができる。また、コマンドをコマンドシートに登録する際にもSOAPボディー部分のデータ形式を変換する必要がないので、この点でも処理負荷を低減することができる。ただし、コマンドの宛先が仲介装置101自身である場合には、コマンドを実行するためにデータを管理装置コマンドハンドラ44aが内容を参照できる形式とする必要があることから、データ形式を変換してからコマンドシートに登録するようにしている。
なお、管理装置コマンドの宛先から仲介装置101が受け取るコマンド応答を「出力パラメータ」の項目に登録する際にも、応答に係るSOAPエンベロープをXMLのまま登録するようにしてもよい。このようにすれば、コマンド応答を管理装置102に転送する際の処理負荷も低減することができる。
なお、管理装置コマンドの宛先から仲介装置101が受け取るコマンド応答を「出力パラメータ」の項目に登録する際にも、応答に係るSOAPエンベロープをXMLのまま登録するようにしてもよい。このようにすれば、コマンド応答を管理装置102に転送する際の処理負荷も低減することができる。
〔第2の実施例:図43乃至図45〕
次に、図1に示した通信システムの第2の実施例である遠隔管理システムについて説明する。この遠隔管理システムの特徴は、管理装置102が、複数の装置を宛先とした管理装置コマンドを1つのSOAPリクエストとして送信できる点及び、このような管理装置コマンドに対する応答を、各宛先からの動作応答が揃った後で仲介装置101から管理装置102に送信する点である。そして、このような特徴を実現するため、主に仲介装置101における処理が第1の実施例の場合と異なる。そして、ハードウェア構成及び、管理装置102や画像形成装置100が実行する処理については、第1の実施例の場合とほぼ同様であるから、これらについての説明は省略するか簡単にする。
次に、図1に示した通信システムの第2の実施例である遠隔管理システムについて説明する。この遠隔管理システムの特徴は、管理装置102が、複数の装置を宛先とした管理装置コマンドを1つのSOAPリクエストとして送信できる点及び、このような管理装置コマンドに対する応答を、各宛先からの動作応答が揃った後で仲介装置101から管理装置102に送信する点である。そして、このような特徴を実現するため、主に仲介装置101における処理が第1の実施例の場合と異なる。そして、ハードウェア構成及び、管理装置102や画像形成装置100が実行する処理については、第1の実施例の場合とほぼ同様であるから、これらについての説明は省略するか簡単にする。
この遠隔管理システムにおいては、まず、仲介装置101における管理装置コマンドシートの形式が第1の実施例の場合と異なる。図43は、この実施例の仲介装置101における管理装置コマンドシートにおけるデータ構造の例を示す。
この図に示すように、この遠隔管理システムでも、管理装置コマンドシートに登録するデータの項目は第1の実施例の場合と同じである。しかし、「宛先情報」の項目を複数登録可能とし、また、「出力パラメータ」及び「コマンドの通知先」の項目も、各「宛先情報」と対応させて複数登録可能としている。
この図に示すように、この遠隔管理システムでも、管理装置コマンドシートに登録するデータの項目は第1の実施例の場合と同じである。しかし、「宛先情報」の項目を複数登録可能とし、また、「出力パラメータ」及び「コマンドの通知先」の項目も、各「宛先情報」と対応させて複数登録可能としている。
従って、複数の装置を宛先とした管理装置コマンドを、1つの管理装置コマンドシートに登録することができる。また、各宛先に転送又は仲介装置101自身で実行するためのハンドラへの参照を宛先毎に検索して登録することができる。さらに、各装置がコマンドに係る動作を実行して生成する動作応答も、宛先毎に登録することができる。そして、「コマンドID」や「送信元情報」といった、各宛先に共通の情報については、1つだけ記憶させるようにし、データ量を小さくしている。
また、ここでは、動作応答の管理装置102への送信は、全ての宛先から動作応答を取得した後で一括して行うようにしているので、「状態」の項目についても、1つの管理装置コマンドシート全体で1つだけ設けている。
また、ここでは、動作応答の管理装置102への送信は、全ての宛先から動作応答を取得した後で一括して行うようにしているので、「状態」の項目についても、1つの管理装置コマンドシート全体で1つだけ設けている。
なお、複数の装置を宛先とした管理装置コマンドは、管理装置102が同じ内容の動作要求を同時に複数の装置に対して送信しようとしたときに作成するものである。そして、転送時のSOAPメッセージの形式としては、例えば、図22に示した形式において、宛先のリスト中に複数の画像形成装置100のIDを記載したものが考えられる。
次に、この遠隔管理システムにおいて仲介装置101が実行する処理について説明する。
この遠隔管理システムにおいても、仲介装置101が実行するメッセージの収集及び分配処理の基本動作は、第1の実施例で図27を用いて説明したものと同様なものである。しかし、複数の装置を宛先とした管理装置コマンドを処理できるようにするため、各処理の詳細は、第1の実施例の場合と異なる箇所もある。
この遠隔管理システムにおいても、仲介装置101が実行するメッセージの収集及び分配処理の基本動作は、第1の実施例で図27を用いて説明したものと同様なものである。しかし、複数の装置を宛先とした管理装置コマンドを処理できるようにするため、各処理の詳細は、第1の実施例の場合と異なる箇所もある。
まず、ステップS18の管理装置コマンド登録処理は、図44及び図45のフローチャートに示す処理となる。
この処理においては、まず、図27のステップS17乃至S19のループで処理対象となっているパートのSOAPエンベロープを、SOAPヘッダのみ解析して内容を参照できる形式のデータに変換し(S101)、その管理装置コマンドを登録するための管理装置コマンドシートを管理装置コマンドプール42に作成する(S102)。このとき、「宛先情報」及びこれに対応する項目は、管理装置コマンドに含まれる宛先の数だけ設ける。その後、SOAPヘッダに記載されていた宛先情報を参照して、対象パートに記載されている管理装置コマンドの宛先に仲介装置101自身が含まれているか否か判断する(S103)。
この処理においては、まず、図27のステップS17乃至S19のループで処理対象となっているパートのSOAPエンベロープを、SOAPヘッダのみ解析して内容を参照できる形式のデータに変換し(S101)、その管理装置コマンドを登録するための管理装置コマンドシートを管理装置コマンドプール42に作成する(S102)。このとき、「宛先情報」及びこれに対応する項目は、管理装置コマンドに含まれる宛先の数だけ設ける。その後、SOAPヘッダに記載されていた宛先情報を参照して、対象パートに記載されている管理装置コマンドの宛先に仲介装置101自身が含まれているか否か判断する(S103)。
そして、コマンドの宛先に仲介装置101が含まれていれば、対象パートのSOAPボディも解析して内容を参照できる形式のデータに変換し(S104)、ステップS102で作成した管理装置コマンドシートに管理装置コマンドとコマンドID及び宛先情報を登録する(S105)。各項目への登録内容については、第1の実施例の場合と同様である。そして、各項目への登録が終了すると、仲介装置101が管理装置コマンドシートの「メソッド名」に記憶させたメソッドを実行するためのハンドラ(管理装置コマンドハンドラ44a)への参照情報を、予め用意してあるメソッドとハンドラとの対応関係の情報を参照して検索し(S106)、発見した参照情報を、管理装置コマンドシートのうち仲介装置の宛先情報と対応する「コマンドの通知先」の項目に登録する(S107)。
そして、処理中の管理装置コマンドの宛先に仲介装置101自身以外も含まれているか否か判断し(S108)、含まれていなければ図45に示す処理に進む。含まれていれば、ステップS111に進む。
そして、処理中の管理装置コマンドの宛先に仲介装置101自身以外も含まれているか否か判断し(S108)、含まれていなければ図45に示す処理に進む。含まれていれば、ステップS111に進む。
一方、ステップS83で宛先に仲介装置101が含まれていなければ、上述した第1の実施例の変形例の場合のように、対象パートのSOAPエンベロープを、作成した管理装置コマンドシートの「入力パラメータ」の項目にXMLのまま登録すると共に(S109)、SOAPヘッダに記載されていたコマンドID及び宛先情報については、ステップS81での変換後のデータを管理装置コマンドシートに登録する(S110)。
そして、コマンドを各宛先に転送するためのハンドラ(管理装置コマンド転送ハンドラ44b)への参照情報を検索し(S111)、発見した参照情報を、管理装置コマンドシートのうち画像形成装置100又は被管理仲介装置110の宛先情報と対応する「コマンドの通知先」の項目に登録して(S112)、図45に示す処理に進む。
ここで、宛先毎に異なる管理装置コマンド転送ハンドラ44bを用いることが考えられる場合には、参照情報の検索及び登録は、宛先毎に行うものとする。また、コマンドを内容を参照できるデータ形式に変換して管理装置コマンドシートに登録した場合と、XMLのまま登録した場合とで、転送のための管理装置コマンド転送ハンドラ44bは異なる場合もある。
以上のような処理で、複数の装置を宛先とした管理装置コマンドを、管理装置コマンドプール42の1つの管理装置コマンドシートに登録することができる。
ここで、宛先毎に異なる管理装置コマンド転送ハンドラ44bを用いることが考えられる場合には、参照情報の検索及び登録は、宛先毎に行うものとする。また、コマンドを内容を参照できるデータ形式に変換して管理装置コマンドシートに登録した場合と、XMLのまま登録した場合とで、転送のための管理装置コマンド転送ハンドラ44bは異なる場合もある。
以上のような処理で、複数の装置を宛先とした管理装置コマンドを、管理装置コマンドプール42の1つの管理装置コマンドシートに登録することができる。
次の図45に示す処理においては、まず所定時間内に管理装置コマンドに対する応答を全ての宛先について生成できるか否か判断する(S121)。なお、第1の実施例の場合と同様、画像形成装置等にコマンドを転送して応答を取得する必要がある場合には、ここでの判断は必ずNOにするものとする。
そして、ステップS121で所定時間内に生成できると判断した場合には、ステップS122以下の処理を行って直ちに管理装置コマンドに係る処理を実行する。すなわち、まず登録した管理装置コマンドに含まれる各「宛先情報」を順次対象として、ステップS122及びS123の処理を繰り返す。
この部分の処理は、対象の「宛先情報」と対応する「コマンドの通知先」の情報に基づいてハンドラを呼び出し、「メソッド名」や「入力パラメータ」や「宛先情報」のデータを渡して管理装置コマンドに係る処理を実行させると共に(S122)、その実行結果を取得して対象の「宛先情報」と対応する「出力パラメータ」の項目に登録する(S123)処理である。
そして、ステップS121で所定時間内に生成できると判断した場合には、ステップS122以下の処理を行って直ちに管理装置コマンドに係る処理を実行する。すなわち、まず登録した管理装置コマンドに含まれる各「宛先情報」を順次対象として、ステップS122及びS123の処理を繰り返す。
この部分の処理は、対象の「宛先情報」と対応する「コマンドの通知先」の情報に基づいてハンドラを呼び出し、「メソッド名」や「入力パラメータ」や「宛先情報」のデータを渡して管理装置コマンドに係る処理を実行させると共に(S122)、その実行結果を取得して対象の「宛先情報」と対応する「出力パラメータ」の項目に登録する(S123)処理である。
そして、全ての「宛先情報」を対象についてこれらの処理が終了すると、管理装置コマンドシートの「状態」を「処理完了」に変更し、全ての宛先について処理が完了したことを示す(S124)。以上の処理を行うことにより、全ての宛先について管理装置コマンドを実行し、その結果をコマンド応答として管理装置102に送信可能な状態にすることができる。
一方、ステップS121で全ての宛先については所定時間内に生成できないと判断した場合には、登録した管理装置コマンドについての管理装置コマンドシートの「状態」を「遅延未通知」に変更して遅延通知が必要であることを示す(S125)。
そして、ステップS124又はS125が完了すると、管理装置コマンド登録処理を終了する。以上がこの遠隔管理システムにおいて仲介装置101が実行する管理装置コマンド登録処理である。
なお、以上の処理において、第1の実施例の場合と同様に、SOAPエンベロープを初めから全て解析し、管理装置コマンドを、内容を参照できる形式のデータとして管理装置コマンドシートに登録するようにしてもよい。
そして、ステップS124又はS125が完了すると、管理装置コマンド登録処理を終了する。以上がこの遠隔管理システムにおいて仲介装置101が実行する管理装置コマンド登録処理である。
なお、以上の処理において、第1の実施例の場合と同様に、SOAPエンベロープを初めから全て解析し、管理装置コマンドを、内容を参照できる形式のデータとして管理装置コマンドシートに登録するようにしてもよい。
また、図27のステップS12乃至S14に相当する管理装置コマンド実行結果収集処理からHTTPリクエスト送信処理までの処理は、図46に示すものになる。
この処理においてはまず、管理装置コマンドプール42から、「状態」が「処理完了」又は「遅延未通知」である管理装置コマンドシートを、送信に係る処理を行う対象にすべきものとして抽出する(S131)。そして、ステップS131の後で、ここで抽出した全ての管理装置コマンドシートを順次対象として、ステップS132乃至S139の処理を繰り返す。
この処理においてはまず、管理装置コマンドプール42から、「状態」が「処理完了」又は「遅延未通知」である管理装置コマンドシートを、送信に係る処理を行う対象にすべきものとして抽出する(S131)。そして、ステップS131の後で、ここで抽出した全ての管理装置コマンドシートを順次対象として、ステップS132乃至S139の処理を繰り返す。
この部分の処理においては、まず対象の管理装置コマンドシートの「状態」が「処理完了」であるか否か判断する(S132)。
そして、「処理完了」であれば、コマンド応答を管理装置102に送信するための処理を行うべくステップS133以下に進み、まず対象の管理装置コマンドシートの全ての「宛先情報」を順次対象としてステップS133乃至S135の処理を行う。この部分の処理では、まず対象の管理装置コマンドシートの、対象の「宛先情報」と対応する「出力パラメータ」の内容を、そのシートに記載された管理装置コマンドに対する対象の宛先からのコマンド応答として収集し、また「コマンドID」の内容を、対応する管理装置コマンドのコマンドIDとして収集する(S133)。なお、対象の「宛先情報」の内容自体もコマンド応答の送信元の情報として収集する。
そして、「処理完了」であれば、コマンド応答を管理装置102に送信するための処理を行うべくステップS133以下に進み、まず対象の管理装置コマンドシートの全ての「宛先情報」を順次対象としてステップS133乃至S135の処理を行う。この部分の処理では、まず対象の管理装置コマンドシートの、対象の「宛先情報」と対応する「出力パラメータ」の内容を、そのシートに記載された管理装置コマンドに対する対象の宛先からのコマンド応答として収集し、また「コマンドID」の内容を、対応する管理装置コマンドのコマンドIDとして収集する(S133)。なお、対象の「宛先情報」の内容自体もコマンド応答の送信元の情報として収集する。
その後、ステップS133で収集したコマンド応答と、その応答と共に収集したコマンドID及び送信元の情報とを、これらの情報がそれぞれSOAPボディとSOAPヘッダとに含まれるXML文書(SOAPエンベロープ)に変換し(S134)、これにエンティティヘッダを付加して、対象のシートに記載された管理装置コマンドに対する対象の宛先からのコマンド応答に関するパートを生成する(S135)。そして、全ての「宛先情報」についてこれらの処理を行った時点で、対象の管理装置コマンドシートの「状態」を「応答済」に変更する(S136)。
この部分の記載からわかるように、1パートで複数の装置を宛先とした管理装置コマンドを受信した場合でも、そのコマンドに対する応答は、宛先毎に別々のパートに記載して送信する。これは、コマンドが各宛先に対して同じ内容であったとしても、応答は宛先毎に独立して生成されるためである。
この部分の記載からわかるように、1パートで複数の装置を宛先とした管理装置コマンドを受信した場合でも、そのコマンドに対する応答は、宛先毎に別々のパートに記載して送信する。これは、コマンドが各宛先に対して同じ内容であったとしても、応答は宛先毎に独立して生成されるためである。
一方、ステップS132で「処理完了」でなければ、対象シートの「状態」は「遅延未通知」であるので、遅延通知を管理装置102に送信するための処理を行うべくステップS137以下に進み、まず対象の管理装置コマンドシートに記載されている管理装置コマンドについてのSOAPエンベロープによる遅延通知を、シートの「コマンドID」や「宛先情報」等を参照して作成する(S137)。そして、これにエンティティヘッダを付加して遅延通知に関するパートを生成し(S138)、対象の管理装置コマンドシートの「状態」を「処理待ち」に変更する(S139)。
ステップS136又はS139の後は、ステップS132に戻り、次のシートを対象として処理を繰り返す。そして、全てのシートについてこれらの処理を行った時点で、ステップS135、S139又は、ここでは詳細を示していない図27のステップS11の部分で生成した各パートをマージし、図16に示したようなマルチパートのHTTPリクエストを生成して管理装置102に送信する(S140)。
なお、ステップS136又はS139で行った「状態」の変更は、実際にこの送信が終了してから行うようにしてもよい。このようにすることにより、通信エラーが発生しても、送信しようとしていたコマンド及びコマンド応答を再度送信の対象とすることができるので、システムの信頼性が向上する。
ステップS140の後は、図27のステップS15以降に相当する処理に進む。
この遠隔管理システムにおいては、メッセージの収集及び分配処理の基本動作を、以上のように変更することにより、複数の装置を宛先とした管理装置コマンドを処理することができる。
なお、ステップS136又はS139で行った「状態」の変更は、実際にこの送信が終了してから行うようにしてもよい。このようにすることにより、通信エラーが発生しても、送信しようとしていたコマンド及びコマンド応答を再度送信の対象とすることができるので、システムの信頼性が向上する。
ステップS140の後は、図27のステップS15以降に相当する処理に進む。
この遠隔管理システムにおいては、メッセージの収集及び分配処理の基本動作を、以上のように変更することにより、複数の装置を宛先とした管理装置コマンドを処理することができる。
次に、この遠隔管理システムにおいて仲介装置101が実行する、遅延通知をした管理装置コマンドの実行に関する処理について説明する。
図47は、この処理を示すフローチャートである。この処理においては、仲介装置101のCPU52は、管理装置コマンド実行結果生成手段44として機能する。またこの処理は、図27に示した管理装置102との間のメッセージの送受信に係る処理とは独立して、CPU52が仲介装置101の起動時に開始するものである。
図47は、この処理を示すフローチャートである。この処理においては、仲介装置101のCPU52は、管理装置コマンド実行結果生成手段44として機能する。またこの処理は、図27に示した管理装置102との間のメッセージの送受信に係る処理とは独立して、CPU52が仲介装置101の起動時に開始するものである。
そして、この処理においては、まず管理装置コマンドプール42に「状態」が「処理待ち」である管理装置コマンドシートがあるか否か判断し(SA1)、なければこのような管理装置コマンドシートを発見するまで待機する。なお、第1の実施例の場合と同様に、「処理待ち」という状態は、管理装置102に対して遅延通知を送信済でかつコマンドに係る処理は未実行あることを示すものである。
ステップSA1で「処理待ち」の管理装置コマンドシートを発見した場合には、その1つを処理対象とし、その管理装置コマンドシートの「状態」を「処理中」に変更する(SA2)。
ステップSA1で「処理待ち」の管理装置コマンドシートを発見した場合には、その1つを処理対象とし、その管理装置コマンドシートの「状態」を「処理中」に変更する(SA2)。
その後、図45の場合と同様なステップS122乃至S124の処理を行って処理対象の管理装置コマンドシートに記載された管理装置コマンドを実行し、これが完了するとステップSA1に戻って処理を繰り返す。
なお、ステップS122及びS123の処理は、複数の「宛先情報」に関して並行して行ってもよい。すなわち、ある宛先について「コマンドの通知先」に登録した参照情報を用いてハンドラを呼び出して処理を指示した後、実行結果を受け取る前に次の宛先についてハンドラを呼び出して処理を指示してもよい。
また、図46に示した処理全体を複数のスレッド(例えば4スレッド)で同時に行うようにしてもよいことは、第1の実施例における図33の処理の場合と同様である。
なお、ステップS122及びS123の処理は、複数の「宛先情報」に関して並行して行ってもよい。すなわち、ある宛先について「コマンドの通知先」に登録した参照情報を用いてハンドラを呼び出して処理を指示した後、実行結果を受け取る前に次の宛先についてハンドラを呼び出して処理を指示してもよい。
また、図46に示した処理全体を複数のスレッド(例えば4スレッド)で同時に行うようにしてもよいことは、第1の実施例における図33の処理の場合と同様である。
以上のような処理を行うようにすれば、任意のタイミングで管理装置コマンドを実行することができるので、実行に時間のかかるコマンドがあった場合でも、以後の処理が滞ることがない。そして、全ての宛先について処理が完了し、その結果をコマンド応答として管理装置102に送信可能な状態にできた場合に管理装置コマンドシートの「状態」を「処理完了」に変更してその旨を示すことができる。
この実施例の遠隔管理システムにおいては、以上のような処理を行うようにしたことにより、複数の装置を宛先とした管理装置コマンドに対応可能となり、管理装置が複数の装置に同じコマンドを送信しようとする場合に、宛先以外の部分を繰り返し送信する必要がなくなるため、転送データ量を低減して通信の効率化を図ることができる。
また、応答については各宛先毎に別のパートで送信するが、全ての宛先からの応答が揃ってから送信を行うため、各宛先からの応答を一括して送信できるため、応答送信のための仲介装置101から管理装置102への通信要求が1回で済むので、通信のオーバーヘッドを低減して通信効率を高めることができる。なお、被管理側コマンドや、他の管理装置コマンドに対する応答もこれらの応答と一括して転送してよいことは、言うまでもない。
また、応答については各宛先毎に別のパートで送信するが、全ての宛先からの応答が揃ってから送信を行うため、各宛先からの応答を一括して送信できるため、応答送信のための仲介装置101から管理装置102への通信要求が1回で済むので、通信のオーバーヘッドを低減して通信効率を高めることができる。なお、被管理側コマンドや、他の管理装置コマンドに対する応答もこれらの応答と一括して転送してよいことは、言うまでもない。
〔第3の実施例:図48乃至図50〕
次に、図1に示した通信システムの第3の実施例である遠隔管理システムについて説明する。この遠隔管理システムの特徴は、第2の実施例の場合と同様、複数の装置を宛先とした管理装置コマンドに対応している点及び、この場合に各宛先からの動作応答が揃った後で応答を送信する点である。そして、このような特徴を実現するため、主に仲介装置101における処理が第1の実施例の場合と異なる。そして、ハードウェア構成及び、管理装置102や画像形成装置100が実行する処理については、第1の実施例の場合とほぼ同様であるから、これらについての説明は省略するか簡単にする。
次に、図1に示した通信システムの第3の実施例である遠隔管理システムについて説明する。この遠隔管理システムの特徴は、第2の実施例の場合と同様、複数の装置を宛先とした管理装置コマンドに対応している点及び、この場合に各宛先からの動作応答が揃った後で応答を送信する点である。そして、このような特徴を実現するため、主に仲介装置101における処理が第1の実施例の場合と異なる。そして、ハードウェア構成及び、管理装置102や画像形成装置100が実行する処理については、第1の実施例の場合とほぼ同様であるから、これらについての説明は省略するか簡単にする。
この遠隔管理システムにおいても、管理装置102が、同じ内容の動作要求を同時に複数の装置に対して送信しようとしたときに複数の装置を宛先とした管理装置コマンドを作成することは、第2の実施例の場合と同様である。しかし、仲介装置においてこれを登録する管理装置コマンドシートは、宛先毎に別々に設けるため、第1の実施例の場合と同様な形式のものを用いる。
また、この遠隔管理システムにおいても、仲介装置101が実行するメッセージの収集及び分配処理の基本動作は、第1の実施例で図27を用いて説明したものと同様なものである。しかし、複数の装置を宛先とした管理装置コマンドを処理できるようにするため、各処理の詳細は、第1の実施例の場合と異なる箇所もある。
また、この遠隔管理システムにおいても、仲介装置101が実行するメッセージの収集及び分配処理の基本動作は、第1の実施例で図27を用いて説明したものと同様なものである。しかし、複数の装置を宛先とした管理装置コマンドを処理できるようにするため、各処理の詳細は、第1の実施例の場合と異なる箇所もある。
まず、ステップS18の管理装置コマンド登録処理は、図48及び図49のフローチャートに示す処理となる。
この処理においては、まず、図27のステップS17乃至S19のループで処理対象となっているパートのSOAPエンベロープを解析して内容を参照できる形式のデータに変換し(S151)、そのパートに記載されたコマンドを、宛先情報に従って展開、すなわち宛先情報を個々の宛先毎に分けると共に、各宛先情報に対応させてコマンドに係るそれ以外の情報をコピーする(S152)。そしてその後、対象のパートに宛先情報として記載されていた全ての宛先を順次対象として、ステップS153乃至S158の処理を繰り返す。
この処理においては、まず、図27のステップS17乃至S19のループで処理対象となっているパートのSOAPエンベロープを解析して内容を参照できる形式のデータに変換し(S151)、そのパートに記載されたコマンドを、宛先情報に従って展開、すなわち宛先情報を個々の宛先毎に分けると共に、各宛先情報に対応させてコマンドに係るそれ以外の情報をコピーする(S152)。そしてその後、対象のパートに宛先情報として記載されていた全ての宛先を順次対象として、ステップS153乃至S158の処理を繰り返す。
この部分の処理においては、まず対象の宛先についての管理装置コマンドを登録するための管理装置コマンドシートを管理装置コマンドプール42に作成する(S153)。そして、管理装置コマンドとコマンドID及び対象の宛先の宛先情報をその管理装置コマンドシートに登録する(S154)。各項目への登録内容については、第1の実施例の場合と同様である。
そして、以上の項目への登録が終了すると、対象としている宛先が仲介装置101すなわち自分自身であるか否か判断する(S155)。そして、仲介装置101であれば、管理装置コマンドシートの「メソッド名」に記憶させたメソッドを実行させるためのハンドラ(管理装置コマンドハンドラ44a)への参照情報を、予め用意してあるメソッドとハンドラとの対応関係の情報を参照して検索し(S156)、発見した参照情報を管理装置コマンドシートの「コマンドの通知先」の項目に登録する(S157)。
そして、以上の項目への登録が終了すると、対象としている宛先が仲介装置101すなわち自分自身であるか否か判断する(S155)。そして、仲介装置101であれば、管理装置コマンドシートの「メソッド名」に記憶させたメソッドを実行させるためのハンドラ(管理装置コマンドハンドラ44a)への参照情報を、予め用意してあるメソッドとハンドラとの対応関係の情報を参照して検索し(S156)、発見した参照情報を管理装置コマンドシートの「コマンドの通知先」の項目に登録する(S157)。
一方、ステップS155で仲介装置101でなければ、コマンドを宛先に転送するためのハンドラ(管理装置コマンド転送ハンドラ44b)への参照情報を検索し(S158)、発見した参照情報を同様に登録する(S157)。
ステップS157の後は、ステップS153に戻り、次の宛先を対象として処理を繰り返す。そして、全ての宛先についてこれらの処理を行った時点で、複数の装置を宛先とした管理装置コマンドを、管理装置コマンドプール42の宛先毎の管理装置コマンドシートに登録することができる。そして、続けて応答状況管理のための図49に示す処理に進む。
ステップS157の後は、ステップS153に戻り、次の宛先を対象として処理を繰り返す。そして、全ての宛先についてこれらの処理を行った時点で、複数の装置を宛先とした管理装置コマンドを、管理装置コマンドプール42の宛先毎の管理装置コマンドシートに登録することができる。そして、続けて応答状況管理のための図49に示す処理に進む。
図49に示す処理においては、まず所定時間内に管理装置コマンドに対する応答を全ての宛先について生成できるか否か判断する(S161)。なお、第1の実施例の場合と同様、画像形成装置等にコマンド転送して応答を取得する必要がある場合には、ここでの判断は必ずNOにするものとする。
そして、ステップS161で所定時間内に生成できると判断した場合には、ステップS162以下の処理を行って直ちに管理装置コマンドに係る処理を実行する。すなわち、ステップS153で作成した各管理装置コマンドシートを順次対象として、ステップS162乃至S164の処理を繰り返す。
そして、ステップS161で所定時間内に生成できると判断した場合には、ステップS162以下の処理を行って直ちに管理装置コマンドに係る処理を実行する。すなわち、ステップS153で作成した各管理装置コマンドシートを順次対象として、ステップS162乃至S164の処理を繰り返す。
この部分の処理は、対象の管理装置コマンドシートの「コマンドの通知先」の情報に基づいてハンドラを呼び出し、「メソッド名」や「入力パラメータ」や「宛先情報」のデータを渡して管理装置コマンドに係る処理を実行させると共に(S162)、その実行結果を取得して対象の「宛先情報」と対応する「出力パラメータ」の項目に登録し(S163)、これが終了すると、対象の管理装置コマンドシートの「状態」を「処理完了」に変更し、そのコマンドシートについて処理が完了したことを示す(S164)ものである。
以上の処理をステップS153で作成した全ての管理装置コマンドシートについて繰り返すことにより、全ての宛先について管理装置コマンドを実行し、その結果をコマンド応答として管理装置102に送信可能な状態にすることができる。
以上の処理をステップS153で作成した全ての管理装置コマンドシートについて繰り返すことにより、全ての宛先について管理装置コマンドを実行し、その結果をコマンド応答として管理装置102に送信可能な状態にすることができる。
一方、ステップS161で全ての宛先については所定時間内に生成できないと判断した場合には、ステップS153で作成した全ての管理装置コマンドシートの「状態」を「遅延未通知」に変更して遅延通知が必要であることを示す(S165)。ここで、全てのコマンドシートの「状態」を変更するのは、全てのコマンドシートに応答が登録された後で管理装置102にそれらを一括して送信するためである。
そして、これらのいずれかの処理が完了すると、管理装置コマンド登録処理を終了する。以上がこの遠隔管理システムにおいて仲介装置101が実行する管理装置コマンド登録処理である。
そして、これらのいずれかの処理が完了すると、管理装置コマンド登録処理を終了する。以上がこの遠隔管理システムにおいて仲介装置101が実行する管理装置コマンド登録処理である。
また、図27のステップS12乃至S14に相当する管理装置コマンド実行結果収集処理からHTTPリクエスト送信処理までの処理は、図50に示すものになる。
この処理においてはまず、管理装置コマンドプール42から、コマンドID毎に組にして管理装置コマンドシートを抽出する。別々のコマンドシートであっても、同じコマンドIDを有する管理装置コマンドシートには、もともと1つのパートに記載されていたコマンドが登録されていると考えられるためである。
そして、ここで抽出した全ての組を順次対象としてステップS172乃至S180の処理を繰り返す。
この処理においてはまず、管理装置コマンドプール42から、コマンドID毎に組にして管理装置コマンドシートを抽出する。別々のコマンドシートであっても、同じコマンドIDを有する管理装置コマンドシートには、もともと1つのパートに記載されていたコマンドが登録されていると考えられるためである。
そして、ここで抽出した全ての組を順次対象としてステップS172乃至S180の処理を繰り返す。
この部分の処理においては、まず対象組の全管理装置コマンドシートの「状態」が「処理完了」であるか否か判断する。そして、全て「処理完了」であれば、これらのシートに登録されているコマンド応答を一括して管理装置102に送信すべく、対象組の全ての管理装置コマンドシートを順次対象としてステップS173乃至S176の処理を繰り返す。
この部分の処理は、まず対象の管理装置コマンドシートの「出力パラメータ」の内容を、そのシートに記載された管理装置コマンドに対する「宛先情報」に登録された宛先からのコマンド応答として収集し、「宛先情報」の内容もコマンド応答の送信元の情報として収集し、また「コマンドID」の内容も、対応する管理装置コマンドのコマンドIDとして収集する(S173)。その後、ステップS173で収集したコマンド応答と、その応答と共に収集したコマンドID及び送信元の情報とを、これらの情報がそれぞれSOAPボディとSOAPヘッダとに含まれるXML文書(SOAPエンベロープ)に変換し(S174)、これにエンティティヘッダを付して、対象のシートに記載された管理装置コマンド対する対象の宛先からのコマンド応答に関するパートを生成する(S175)。そしてその後、対象の管理装置コマンドシートの「状態」を「応答済」に変更する(S176)。
ステップS176の後は、ステップS173に戻り、次の管理装置コマンドシートを対象として処理を繰り返す。
ステップS176の後は、ステップS173に戻り、次の管理装置コマンドシートを対象として処理を繰り返す。
一方、ステップS172で全て「処理完了」でなかった場合には、対象組の全管理装置コマンドシートの「状態」が「遅延未通知」であるか否か判断する(S177)。そして、全て「遅延未通知」であれば、対象組の各管理装置コマンドシートに登録されている管理装置コマンドに対する遅延通知を管理装置102に送信すべく、ステップS178以下の処理に進む。そして、まずSOAPエンベロープによるこの遅延通知を、シートの「コマンドID」や「宛先情報」等を参照して作成する(S178)。そして、これにエンティティヘッダを付して遅延通知に関するパートを生成し(S179)、対象組の各管理装置コマンドシートの「状態」を「処理待ち」に変更する(S180)。ここで、遅延通知は対象組について1つだけ作成し、各管理装置コマンドシートから収集した「宛先情報」を全て登録するものとする。遅延通知は、コマンドの宛先が異なっても同じ内容なので、このような形式で作成することにより、データ量の低減を図っている。
この処理が完了すると、ステップS172に戻って次の組を対象として処理を繰り返す。ステップS176の後で次の管理装置コマンドシートがなかった場合も同様である。また、ステップS177で全て「遅延未通知」でなかった場合にも、そのままステップS172に戻って次の組を対象として処理を繰り返す。このケースに該当するのは、例えば遅延通知の送信後に各管理装置コマンドシートの「状態」が「処理待ち」になっていたり、一部のシートのみについて「処理中」や「処理完了」になっている場合である。
そして、これらの場合に全ての組について処理が完了していれば、ステップS175、S179又は、ここでは詳細を示していない図27のステップS11の部分で生成した各パートをマージし、図16に示したようなマルチパートのHTTPリクエストを生成して管理装置102に送信する(S181)。
そして、これらの場合に全ての組について処理が完了していれば、ステップS175、S179又は、ここでは詳細を示していない図27のステップS11の部分で生成した各パートをマージし、図16に示したようなマルチパートのHTTPリクエストを生成して管理装置102に送信する(S181)。
なお、ステップS176又はS180で行った「状態」の変更は、実際にこの送信が終了してから行うようにしてもよい。このようにすることにより、通信エラーが発生しても、送信しようとしていたコマンド及びコマンド応答を再度送信の対象とすることができるので、システムの信頼性が向上する。
ステップS181の後は、図27のステップS15以降に相当する処理に進む。
ステップS181の後は、図27のステップS15以降に相当する処理に進む。
この遠隔管理システムにおいては、メッセージの収集及び分配処理の基本動作を、以上のように変更することにより、複数の装置を宛先とした管理装置コマンドを、宛先毎に管理装置コマンドシートを用意して処理することができる。
なお、この遠隔管理システムにおいては、管理装置コマンドシートの形式は第1の実施例の場合と同様であるので、仲介装置101が実行する、遅延通知をした管理装置コマンドの実行に関する処理は、第1の実施例で図33を用いて説明した処理をそのまま用いることができる。なお、この処理では管理装置コマンドシートの選択順を考慮していないが、「コマンドID」が同じ管理装置コマンドシートに関する処理を続けて行うようにするとよい。
なお、この遠隔管理システムにおいては、管理装置コマンドシートの形式は第1の実施例の場合と同様であるので、仲介装置101が実行する、遅延通知をした管理装置コマンドの実行に関する処理は、第1の実施例で図33を用いて説明した処理をそのまま用いることができる。なお、この処理では管理装置コマンドシートの選択順を考慮していないが、「コマンドID」が同じ管理装置コマンドシートに関する処理を続けて行うようにするとよい。
この実施例の遠隔管理システムにおいても、以上のような処理を行うようにしたことにより、複数の装置を宛先とした管理装置コマンドに対応可能となり、管理装置が複数の装置に同じコマンドを送信しようとする場合に、宛先以外の部分を繰り返し送信する必要がなくなるため、転送データ量を低減して通信の効率化を図ることができる。
また、応答については各宛先毎に別のパートで送信するが、全ての宛先からの応答が揃ってから送信を行うため、各宛先からの応答を一括して送信できるため、仲介装置101から管理装置102への通信要求が1回で済むので、通信のオーバーヘッドを低減して通信効率を高めることができる。
なお、この実施例においても、第1の実施例と同様な変形を適用することが可能である。
また、応答については各宛先毎に別のパートで送信するが、全ての宛先からの応答が揃ってから送信を行うため、各宛先からの応答を一括して送信できるため、仲介装置101から管理装置102への通信要求が1回で済むので、通信のオーバーヘッドを低減して通信効率を高めることができる。
なお、この実施例においても、第1の実施例と同様な変形を適用することが可能である。
〔第4の実施例:図51乃至図53〕
次に、図1に示した通信システムの第4の実施例である遠隔管理システムについて説明する。この遠隔管理システムの特徴は、管理装置102が、複数の装置を宛先とした管理装置コマンドを1つのSOAPリクエストとして送信できる点及び、このような管理装置コマンドに対する応答を、応答が取得できたものから順に仲介装置101から管理装置102に送信する点である。そして、このような特徴を実現するため、主に仲介装置101における処理が第1の実施例の場合と異なる。そして、ハードウェア構成及び、管理装置102や画像形成装置100が実行する処理については、第1の実施例の場合とほぼ同様であるから、これらについての説明は省略するか簡単にする。
次に、図1に示した通信システムの第4の実施例である遠隔管理システムについて説明する。この遠隔管理システムの特徴は、管理装置102が、複数の装置を宛先とした管理装置コマンドを1つのSOAPリクエストとして送信できる点及び、このような管理装置コマンドに対する応答を、応答が取得できたものから順に仲介装置101から管理装置102に送信する点である。そして、このような特徴を実現するため、主に仲介装置101における処理が第1の実施例の場合と異なる。そして、ハードウェア構成及び、管理装置102や画像形成装置100が実行する処理については、第1の実施例の場合とほぼ同様であるから、これらについての説明は省略するか簡単にする。
この遠隔管理システムにおいても、管理装置102が、同じ内容の動作要求を同時に複数の装置に対して行おうとしたときに複数の装置を宛先とした管理装置コマンドを作成することは、第2及び第3の実施例の場合と同様である。
そして、仲介装置101においてこれを登録する管理装置コマンドシートは、第2の実施例で用いたものに若干変更を加えた形式としている。図51に、この実施例の仲介装置101における管理装置コマンドシートにおけるデータ構造の例を示す。
この図に示すように、この遠隔管理システムでも、仲介装置101の管理装置コマンドシートに登録するデータの構成は、第2の実施例の場合と概ね同様である。しかし、「状態」の項目を各「宛先情報」と対応させて複数登録可能とした点が、第2の実施例の場合と異なる。これは、コマンド応答が取得できたものから順に応答を管理装置102に送信するようにするためには、宛先毎に「状態」を管理する必要あるためである。
そして、仲介装置101においてこれを登録する管理装置コマンドシートは、第2の実施例で用いたものに若干変更を加えた形式としている。図51に、この実施例の仲介装置101における管理装置コマンドシートにおけるデータ構造の例を示す。
この図に示すように、この遠隔管理システムでも、仲介装置101の管理装置コマンドシートに登録するデータの構成は、第2の実施例の場合と概ね同様である。しかし、「状態」の項目を各「宛先情報」と対応させて複数登録可能とした点が、第2の実施例の場合と異なる。これは、コマンド応答が取得できたものから順に応答を管理装置102に送信するようにするためには、宛先毎に「状態」を管理する必要あるためである。
次に、この遠隔管理システムにおいて仲介装置101が実行する処理について説明する。この遠隔管理システムにおいても、仲介装置101が実行するメッセージの収集及び分配処理の基本動作は、第1の実施例で図27を用いて説明したものと同様なものである。しかし、複数の装置を宛先とした管理装置コマンドを処理できるようにするため、各処理の詳細は、第1の実施例の場合と異なる箇所もある。
まず、ステップS18の管理装置コマンド登録処理は、第2の実施例で説明したものと同様な処理となる。ただし、図45に示した部分に関しては、宛先毎に「状態」を管理するようにしたため、第2の実施例で説明したものとは若干異なる。図52に、この遠隔管理システムにおいて仲介装置101が実行する処理のうち、図45と対応する部分の処理を示す。
この図から分かるように、図52に示す処理は、第1の実施例で図31を用いて説明した処理を、作成した管理装置コマンドシートに含まれる各「宛先情報」を順次対象として繰り返すものである。従って、各処理の詳細についての説明は省略する。
この図から分かるように、図52に示す処理は、第1の実施例で図31を用いて説明した処理を、作成した管理装置コマンドシートに含まれる各「宛先情報」を順次対象として繰り返すものである。従って、各処理の詳細についての説明は省略する。
また、図27のステップS12乃至S14に相当する管理装置コマンド実行結果収集処理からHTTPリクエスト送信処理までの処理は、図53に示すものになる。
この処理においてはまず、管理装置コマンドプール42から、少なくとも1つの「宛先情報」に対応する「状態」が「処理完了」又は「遅延未通知」である管理装置コマンドシートを、送信に係る処理を行う対象にすべきものとして抽出する(S191)。そして、ステップS191の後で、ここで抽出した全ての管理装置コマンドシートを順次対象とし、さらに対象の管理装置コマンドシートに含まれる全ての「宛先情報」を順次対象として、ステップS192乃至S200の処理を繰り返す。
この処理においてはまず、管理装置コマンドプール42から、少なくとも1つの「宛先情報」に対応する「状態」が「処理完了」又は「遅延未通知」である管理装置コマンドシートを、送信に係る処理を行う対象にすべきものとして抽出する(S191)。そして、ステップS191の後で、ここで抽出した全ての管理装置コマンドシートを順次対象とし、さらに対象の管理装置コマンドシートに含まれる全ての「宛先情報」を順次対象として、ステップS192乃至S200の処理を繰り返す。
この部分の処理においては、まず対象のシートの中の対象の「宛先情報」と対応する「状態」が「処理完了」であるか否か判断する(S192)。
そして、「処理完了」であれば、コマンド応答を管理装置102に送信するための処理を行うべくステップS133以下に進み、対象の管理装置コマンドシートの、対象の「宛先情報」と対応する「出力パラメータ」の内容を、そのシートに記載された管理装置コマンドに対する対象の宛先からのコマンド応答として収集し、対象の「宛先情報」の内容自体もコマンド応答の送信元の情報として収集し、また「コマンドID」の内容も、対応する管理装置コマンドのコマンドIDとして収集する(S193)。
そして、「処理完了」であれば、コマンド応答を管理装置102に送信するための処理を行うべくステップS133以下に進み、対象の管理装置コマンドシートの、対象の「宛先情報」と対応する「出力パラメータ」の内容を、そのシートに記載された管理装置コマンドに対する対象の宛先からのコマンド応答として収集し、対象の「宛先情報」の内容自体もコマンド応答の送信元の情報として収集し、また「コマンドID」の内容も、対応する管理装置コマンドのコマンドIDとして収集する(S193)。
その後、ステップS193で収集したコマンド応答と、その応答と共に収集したコマンドID及び送信元の情報とを、これらの情報がそれぞれSOAPボディとSOAPヘッダとに含まれるXML文書(SOAPエンベロープ)に変換し(S194)、これにエンティティヘッダを付して、対象のシートに記載された管理装置コマンドに対する対象の宛先からのコマンド応答に関するパートを生成する(S195)。そして、これらの処理が完了すると、対象の管理装置コマンドシート中の対象の「宛先情報」に対応する「状態」を「応答済」に変更する(S196)。
一方、ステップS192で「処理完了」でなければ、対象シートの中の対象の「宛先情報」と対応する「状態」が「遅延未通知」であるか否か判断する(S197)。そして、「遅延未通知」であれば、対象の「宛先情報」が示す宛先についての遅延通知を管理装置102に送信するための処理を行うべくステップS198以下に進み、まず対象の管理装置コマンドシートに記載されている管理装置コマンドについての、対象の「宛先情報」が示す宛先についてのSOAPエンベロープによる遅延通知を、シートの「コマンドID」や「宛先情報」等を参照して作成する(S198)。そして、これにエンティティヘッダを付してその遅延通知に関するパートを生成し(S199)、対象の管理装置コマンドシート中の対象の「宛先情報」と対応する「状態」を「処理待ち」に変更する(S200)。
ステップS196又はS200の後は、ステップS192に戻り、次のシートを対象として処理を繰り返す。また、ステップS197で「遅延未通知」でなかった場合には、特に管理装置102に通知を行う必要はないので、そのままステップS192に戻り、次の「宛先情報」を対象として処理を繰り返す。
そして、対象の管理装置コマンドシートの全ての「宛先情報」についてこれらの処理を行った時点で、次の管理装置コマンドシートを対象として同様な処理を行い、ステップS191で抽出した全ての管理装置コマンドシートについて処理が終了すると、ステップS201に進む。
そして、対象の管理装置コマンドシートの全ての「宛先情報」についてこれらの処理を行った時点で、次の管理装置コマンドシートを対象として同様な処理を行い、ステップS191で抽出した全ての管理装置コマンドシートについて処理が終了すると、ステップS201に進む。
そして、ステップS195,S199又は、ここでは詳細を示していない図27のステップS11の部分で生成した各パートをマージし、図16に示したようなマルチパートのHTTPリクエストを生成して管理装置102に送信する(S201)。
なお、ステップS196又はS200で行った「状態」の変更は、実際にこの送信が終了してから行うようにしてもよい。このようにすることにより、通信エラーが発生しても、送信しようとしていたコマンド及びコマンド応答を再度送信の対象とすることができるので、システムの信頼性が向上する。
ステップS201の後は、図27のステップS15以降に相当する処理に進む。
この遠隔管理システムにおいては、メッセージの収集及び分配処理の基本動作を、以上のように変更することにより、複数の装置を宛先とした管理装置コマンドを処理することができる。
なお、ステップS196又はS200で行った「状態」の変更は、実際にこの送信が終了してから行うようにしてもよい。このようにすることにより、通信エラーが発生しても、送信しようとしていたコマンド及びコマンド応答を再度送信の対象とすることができるので、システムの信頼性が向上する。
ステップS201の後は、図27のステップS15以降に相当する処理に進む。
この遠隔管理システムにおいては、メッセージの収集及び分配処理の基本動作を、以上のように変更することにより、複数の装置を宛先とした管理装置コマンドを処理することができる。
次に、この遠隔管理システムにおいて仲介装置101が実行する、遅延通知をした管理装置コマンドの実行に関する処理について説明する。
図54は、この処理を示すフローチャートである。この処理においては、仲介装置101のCPU52は、管理装置コマンド実行結果生成手段44として機能する。またこの処理は、図27に示した管理装置102との間のメッセージの送受信に係る処理とは独立して、CPU52が仲介装置101の起動時に開始するものである。
図54は、この処理を示すフローチャートである。この処理においては、仲介装置101のCPU52は、管理装置コマンド実行結果生成手段44として機能する。またこの処理は、図27に示した管理装置102との間のメッセージの送受信に係る処理とは独立して、CPU52が仲介装置101の起動時に開始するものである。
そして、この処理においては、まず管理装置コマンドプール42に少なくとも1つの「宛先情報」と対応する「状態」が「処理待ち」である管理装置コマンドシートがあるか否か判断し(S211)、なければこのような管理装置コマンドシートを発見するまで待機する。そして、ステップS211で「処理待ち」の管理装置コマンドシートを発見した場合には、その1つを処理対象とすると共に(S212)、その管理装置コマンドシートに含まれる各「宛先情報」を順次対象としてステップS213乃至S217の処理を繰り返す。
この部分の処理は、対象の管理装置コマンドシート中の対象「宛先情報」と対応する「状態」が処理待ちであるか否か判断する(S213)。ここで「処理待ち」であれば、その「宛先情報」の示す宛先について、管理装置コマンドに係る処理を実行する必要があることから、ステップS214以下に進む。
そして、まず対象の管理装置コマンドシート中の対象の「宛先情報」と対応する「状態」を「処理中」に変更し、その後、図52のステップS182乃至S184と同様なステップS215乃至S217の処理を行って処理対象の管理装置コマンドシートに記載された管理装置コマンドを対象の「宛先情報」の示す宛先について実行する。
また、ステップS213で「処理待ち」でなければ、対象の「宛先情報」の示す宛先については処理を行う必要がないので、そのまま次の「宛先情報」を対象として処理を繰り返す。
そして、全ての「宛先情報」について処理が終了すると、ステップS211に戻って処理を繰り返す。
そして、まず対象の管理装置コマンドシート中の対象の「宛先情報」と対応する「状態」を「処理中」に変更し、その後、図52のステップS182乃至S184と同様なステップS215乃至S217の処理を行って処理対象の管理装置コマンドシートに記載された管理装置コマンドを対象の「宛先情報」の示す宛先について実行する。
また、ステップS213で「処理待ち」でなければ、対象の「宛先情報」の示す宛先については処理を行う必要がないので、そのまま次の「宛先情報」を対象として処理を繰り返す。
そして、全ての「宛先情報」について処理が終了すると、ステップS211に戻って処理を繰り返す。
なお、ステップS213乃至S217の処理は、複数の「宛先情報」に関して並行して行ってもよい。すなわち、ある宛先について「コマンドの通知先」に登録した参照情報を用いてハンドラを呼び出して処理を指示した後、実行結果を受け取る前に次の宛先についてハンドラを呼び出して処理を指示してもよい。また、全ての「宛先情報」に関する処理を一連の処理として行うことは必須ではない。
また、図54に示した処理全体を複数のスレッド(例えば4スレッド)で同時に行うようにしてもよいことは、第1の実施例における図33の処理の場合と同様である。
以上のような処理を行うようにすれば、任意のタイミングで管理装置コマンドを実行することができるので、実行に時間のかかるコマンドがあった場合でも、以後の処理が滞ることがない。そして、コマンドに係る動作の結果をコマンド応答として管理装置102に送信可能な状態にできたものから順に、管理装置コマンドシートの「状態」を「処理完了」に変更してその旨を示すことができる。
また、図54に示した処理全体を複数のスレッド(例えば4スレッド)で同時に行うようにしてもよいことは、第1の実施例における図33の処理の場合と同様である。
以上のような処理を行うようにすれば、任意のタイミングで管理装置コマンドを実行することができるので、実行に時間のかかるコマンドがあった場合でも、以後の処理が滞ることがない。そして、コマンドに係る動作の結果をコマンド応答として管理装置102に送信可能な状態にできたものから順に、管理装置コマンドシートの「状態」を「処理完了」に変更してその旨を示すことができる。
この実施例の遠隔管理システムにおいては、以上のような処理を行うようにしたことにより、複数の装置を宛先とした管理装置コマンドに対応可能となり、管理装置が複数の装置に同じコマンドを送信しようとする場合に、宛先以外の部分を繰り返し送信する必要がなくなるため、転送データ量を低減して通信の効率化を図ることができる。
また、応答については、応答が取得できたものから順に送信を行うため、応答の取得後速やかに転送を行うことができる。なおこの場合に、被管理側コマンドや、他の管理装置コマンドに対する応答もこれらの応答と一括して転送することができるので、第1の実施例の場合ような通信効率の向上の効果を得ることができる。
また、応答については、応答が取得できたものから順に送信を行うため、応答の取得後速やかに転送を行うことができる。なおこの場合に、被管理側コマンドや、他の管理装置コマンドに対する応答もこれらの応答と一括して転送することができるので、第1の実施例の場合ような通信効率の向上の効果を得ることができる。
なお、この実施例では1つの管理装置コマンドシートに複数の宛先を登録するようにしているが、第3の実施例の場合のように、宛先毎に管理装置コマンドシートを設けるようにしてもよい。このようにした場合、管理装置コマンドシートの作成後の処理は、第1の実施例の場合と同じものでよい。
また、この実施例においても、第1の実施例と同様な変形を適用することが可能である。
また、この実施例においても、第1の実施例と同様な変形を適用することが可能である。
〔各実施例の第2の変形例:図55,図56〕
次に、以上説明した各実施例の第2の変形例について説明する。この変形例は、仲介装置101の管理装置コマンドシートにおける「状態」の遷移を上述の各実施例の場合と変えたものである。すなわち、初期状態の「未処理」から、「未処理」→「処理中」→「処理完了」→「応答済み」、「未処理」→「処理中」→「遅延通知済処理中」→「処理完了」→「応答済み」、または「未処理」→「遅延通知済未処理」→「遅延通知済処理中」→「処理完了」→「応答済み」と遷移するようにしている。
なお、「遅延通知済未処理」は、まだコマンドに係る処理に着手していないが管理装置102に対する遅延通知の送信は完了している状態を示し、「遅延通知済処理中」は、管理装置102に対する遅延通知の送信が完了しており、かつコマンドに係る処理を実行中であることを示す。また、この変形例での「未処理」及び「処理中」は、それぞれコマンドに係る処理に着手していない状態及び着手はしているが完了していない状態で、かつ管理装置102に対する遅延通知の送信が完了していない状態を示し、「遅延未通知」及び「処理待ち」の「状態」はここでは設けていない。
次に、以上説明した各実施例の第2の変形例について説明する。この変形例は、仲介装置101の管理装置コマンドシートにおける「状態」の遷移を上述の各実施例の場合と変えたものである。すなわち、初期状態の「未処理」から、「未処理」→「処理中」→「処理完了」→「応答済み」、「未処理」→「処理中」→「遅延通知済処理中」→「処理完了」→「応答済み」、または「未処理」→「遅延通知済未処理」→「遅延通知済処理中」→「処理完了」→「応答済み」と遷移するようにしている。
なお、「遅延通知済未処理」は、まだコマンドに係る処理に着手していないが管理装置102に対する遅延通知の送信は完了している状態を示し、「遅延通知済処理中」は、管理装置102に対する遅延通知の送信が完了しており、かつコマンドに係る処理を実行中であることを示す。また、この変形例での「未処理」及び「処理中」は、それぞれコマンドに係る処理に着手していない状態及び着手はしているが完了していない状態で、かつ管理装置102に対する遅延通知の送信が完了していない状態を示し、「遅延未通知」及び「処理待ち」の「状態」はここでは設けていない。
この変形例においては、このようにしたことに伴い、仲介装置101が実行する処理が、上述した各実施例の場合と一部異なる。そして、ここではこの変形を第1の実施例に適用した場合の処理例について説明する。
まず、この変形例においては、図27のステップS18に示した管理装置コマンド登録処理において、図31に示した処理は行わず、図30に示した処理により管理装置コマンドの管理装置コマンドプール42への登録が完了すると、そのまま次のパートを対象として図27のステップS17の処理を行うか、次のパートがなければ処理を終了するようにしている。
そして、管理装置コマンドの実行は、図33に示した処理と対応する図55に示す処理によって行うようにしている。
まず、この変形例においては、図27のステップS18に示した管理装置コマンド登録処理において、図31に示した処理は行わず、図30に示した処理により管理装置コマンドの管理装置コマンドプール42への登録が完了すると、そのまま次のパートを対象として図27のステップS17の処理を行うか、次のパートがなければ処理を終了するようにしている。
そして、管理装置コマンドの実行は、図33に示した処理と対応する図55に示す処理によって行うようにしている。
この処理においては、まず管理装置コマンドプール42に「状態」が「未処理」又は「遅延通知済未処理」である管理装置コマンドシートがあるか否か判断し(SB1)、なければこのような管理装置コマンドシートを発見するまで待機する。
ステップSB1で「未処理」又は「遅延通知済未処理」の管理装置コマンドシートを発見した場合には、その1つを処理対象とし、その管理装置コマンドシートの「状態」を、元が「未処理」であれば「処理中」に、「遅延通知済未処理」であれば「遅延通知済処理中」に変更する(SB2)。
その後のステップS52乃至S54の処理については、図33の場合と同様である。
この処理の内容からわかるように、この変形例では、「状態」が「未処理」の管理装置コマンドシートも処理の対象としているので、管理装置コマンドプールに登録後、遅延通知の送信が完了していない管理装置コマンドシートも、直ちに処理の対象となる。
ステップSB1で「未処理」又は「遅延通知済未処理」の管理装置コマンドシートを発見した場合には、その1つを処理対象とし、その管理装置コマンドシートの「状態」を、元が「未処理」であれば「処理中」に、「遅延通知済未処理」であれば「遅延通知済処理中」に変更する(SB2)。
その後のステップS52乃至S54の処理については、図33の場合と同様である。
この処理の内容からわかるように、この変形例では、「状態」が「未処理」の管理装置コマンドシートも処理の対象としているので、管理装置コマンドプールに登録後、遅延通知の送信が完了していない管理装置コマンドシートも、直ちに処理の対象となる。
また、この変形例においては、「状態」の遷移を変更したことにより、図27のステップS12乃至S14に相当する管理装置コマンド実行結果収集処理からHTTPリクエスト送信処理までの処理も、上述した第1の実施例のものから変更され、図56に示すものになる。
この処理においては、まず、管理装置コマンドプール42に登録されている全ての管理装置コマンドシートを順次対象として、ステップS401乃至S409の処理を繰り返す。
この処理においては、まず、管理装置コマンドプール42に登録されている全ての管理装置コマンドシートを順次対象として、ステップS401乃至S409の処理を繰り返す。
そして、この部分の処理では、まず対象の管理装置コマンドシートの状態が「未処理」又は「処理中」であるか否か判断する(S401)。これらの「状態」は、コマンドに係る処理が完了していないが管理装置102に遅延通知も送信していないことを示すものであるので、これらの「状態」のいずれかであれば、管理装置102に遅延通知を送信すべく、ステップS402以下の処理に進む。
そして、まず対象の管理装置コマンドシートに記載されている管理装置コマンドについてのSOAPエンベロープによる遅延通知を、シートの「コマンドID」や「宛先情報」等を参照して作成する(S402)。そして、これをにエンティティヘッダを付して遅延通知に関するパートを生成し(S403)、対象の管理装置コマンドシートの「状態」が「未処理」であれば「遅延通知済未処理」に、「処理中」であれば「遅延通知済処理中」に変更して遅延通知を行った旨を示す(S404)。
そして、まず対象の管理装置コマンドシートに記載されている管理装置コマンドについてのSOAPエンベロープによる遅延通知を、シートの「コマンドID」や「宛先情報」等を参照して作成する(S402)。そして、これをにエンティティヘッダを付して遅延通知に関するパートを生成し(S403)、対象の管理装置コマンドシートの「状態」が「未処理」であれば「遅延通知済未処理」に、「処理中」であれば「遅延通知済処理中」に変更して遅延通知を行った旨を示す(S404)。
一方、ステップS401で「未処理」又は「処理中」でなければ、対象の管理装置コマンドシートの状態が「処理完了」であるか否か判断する(S405)。そして、「処理完了」であれば、コマンド応答を管理装置102に送信するための処理を行うべくステップS406以下に進み、まず対象の管理装置コマンドシートの「出力パラメータ」の内容を、そのシートに記載された管理装置コマンドに対するコマンド応答として収集し、「コマンドID」の内容も、対応する管理装置コマンドのコマンドIDとして収集して、また「宛先情報」の内容もそのコマンドの宛先すなわちコマンド応答の送信元の情報として収集する(S406)。
その後、ステップS406で収集したコマンド応答と、その応答と共に収集したコマンドID及び送信元の情報とを、これらの情報がそれぞれSOAPボディとSOAPヘッダとに含まれるXML文書(SOAPエンベロープ)に変換し(S407)、これにエンティティヘッダを付して、対象のシートに記載された管理装置コマンドに対するコマンド応答に関するパートを生成する(S408)。そして、次に対象の管理装置コマンドシートの「状態」を「応答済」に変更する(S409)。
ステップS404又はS409の後は、ステップS401に戻り、次の管理装置コマンドシートを対象として処理を繰り返す。ステップS405で「処理完了」でなかった場合にも、同様である。
ステップS404又はS409の後は、ステップS401に戻り、次の管理装置コマンドシートを対象として処理を繰り返す。ステップS405で「処理完了」でなかった場合にも、同様である。
そして、全てのシートについてこれらの処理を行った時点で、ステップS403、S408又は、ここでは詳細を示していない図27のステップS11の部分で生成した各パートをマージし、図16に示したようなマルチパートのHTTPリクエストを生成して管理装置102に送信する(S410)。
なお、ステップS404又はS409で行う「状態」の変更は、実際にこの送信が終了してから行うようにしてもよい。このようにすることにより、通信エラーが発生しても、送信しようとしていたコマンド及びコマンド応答を再度送信の対象とすることができるので、システムの信頼性が向上する。
以上でHTTPリクエストの送信に関する処理を終了し、図27のステップS15以降に相当する処理に進む。
なお、ステップS404又はS409で行う「状態」の変更は、実際にこの送信が終了してから行うようにしてもよい。このようにすることにより、通信エラーが発生しても、送信しようとしていたコマンド及びコマンド応答を再度送信の対象とすることができるので、システムの信頼性が向上する。
以上でHTTPリクエストの送信に関する処理を終了し、図27のステップS15以降に相当する処理に進む。
この変形例の遠隔管理システムにおいては、以上のような処理を行うようにしたことにより、処理が遅延するか否かを判断する必要がなく、管理装置コマンドシートの「状態」のみを参照して遅延通知の要否を判断することができるので、処理を効率よく行うことができる。また、遅延通知を行う前であってもコマンドに係る処理に着手できるので、この点でも処理の効率化を図ることができる。
なお、ここではこの変形例を第1の実施例に適用した例について説明したが、他の実施例にも適用できることはもちろんである。この場合において、具体的な処理はここで説明したものと異なることになるが、管理装置コマンドシート毎あるいは宛先情報毎に上記のような「状態」の遷移を行わせるようにすればよい。
また、管理装置102でも同様な処理を行い、被管理側コマンドシートについても同様な取扱いを行うようにしてもよい。
なお、ここではこの変形例を第1の実施例に適用した例について説明したが、他の実施例にも適用できることはもちろんである。この場合において、具体的な処理はここで説明したものと異なることになるが、管理装置コマンドシート毎あるいは宛先情報毎に上記のような「状態」の遷移を行わせるようにすればよい。
また、管理装置102でも同様な処理を行い、被管理側コマンドシートについても同様な取扱いを行うようにしてもよい。
〔第2の実施形態:図57乃至図62〕
次に、この発明の仲介装置及びその仲介装置を用いて構成した通信システムの第2の実施形態について説明する。なお、この実施形態は、上述した第1の実施形態と共通点が多いので、この実施形態の説明に使用する図面において、第1の実施形態及びその各実施例で説明した構成と対応する部分には、同じ符号を用いる。
まず、図57に、この実施形態の通信システムの構成を示す。
この通信システムも、第1の実施形態の場合と同様、第1の通信装置である管理装置102と、第2の通信装置である複数の画像形成装置100と、これらの間の通信を仲介する仲介装置101を備える。しかし、この実施形態では、仲介装置101と管理装置102との間の通信プロトコルにSMTPを採用しているため、全体としての構成は第1の実施形態とはかなり異なったものとなっている。なお、仲介装置101と画像形成装置100との間の通信方式は、第1の実施形態の場合と全く同様である。
次に、この発明の仲介装置及びその仲介装置を用いて構成した通信システムの第2の実施形態について説明する。なお、この実施形態は、上述した第1の実施形態と共通点が多いので、この実施形態の説明に使用する図面において、第1の実施形態及びその各実施例で説明した構成と対応する部分には、同じ符号を用いる。
まず、図57に、この実施形態の通信システムの構成を示す。
この通信システムも、第1の実施形態の場合と同様、第1の通信装置である管理装置102と、第2の通信装置である複数の画像形成装置100と、これらの間の通信を仲介する仲介装置101を備える。しかし、この実施形態では、仲介装置101と管理装置102との間の通信プロトコルにSMTPを採用しているため、全体としての構成は第1の実施形態とはかなり異なったものとなっている。なお、仲介装置101と画像形成装置100との間の通信方式は、第1の実施形態の場合と全く同様である。
この通信システムは、図57に示すように、管理装置102とメールサーバA′とを接続したLAN_Aと、仲介装置101及び複数の画像形成装置100とメールサーバB′とを接続したLAN_Bとを、それぞれファイアウォールAとファイアウォールBとを介してインターネット103に接続して構成している。また、ファイアウォールを介して外部からアクセス可能な位置に、LAN_A側ではメールサーバAを、LAN_B側ではメールサーバBをそれぞれ設けている。
SMTPを用いて通信を行う場合には、管理装置102と仲介装置101との間での情報転送は電子メールによって行う。そして、例えば仲介装置101から管理装置102に情報を送信する場合、図57に破線で示したように、仲介装置101は、管理装置102を宛先とする電子メールをまずメールサーバB′に送信する。すると、各メールサーバB′,B,Aを順次介して、管理装置102が直接アクセスするメールサーバA′まで電子メールが転送される。また、図示は省略したが、通常はメールサーバBとメールサーバAとの間に更に別のメールサーバを介して転送を行うことになる。
そして、一点鎖線で示したように管理装置102が定期的にメールサーバA′にアクセスすることにより、管理装置102宛の電子メールを受け取ることができ、以上で仲介装置101から管理装置102への情報転送が完了する。管理装置102から仲介装置101への情報転送は、逆の手順で行うことができ、情報転送に関しては、管理装置102と仲介装置101とは対称である。ただし、メールサーバA′及びB′を設けることは必須ではなく、管理装置102がメールサーバAと、仲介装置101がメールサーバBと直接通信を行うようにしてもよい。また、メール受信用のメールサーバとメール送信用のメールサーバが異なってもよい。
このような通信システムにおいて、各LANには外部からアクセス可能な位置にメールサーバを設けていることから、ファイアウォールを越えて電子メールを転送することができる。
なお、この実施例においては、管理装置102と仲介装置101とが直接ネゴシエーションをした上で通信を行っているわけではないが、相互に情報転送を行うことが可能である。
なお、この実施例においては、管理装置102と仲介装置101とが直接ネゴシエーションをした上で通信を行っているわけではないが、相互に情報転送を行うことが可能である。
また、この通信システムにおいても、管理装置102及び仲介装置101は、第1の実施形態の場合と同様に、互いの制御管理を行うためのアプリケーションプログラムを実装している。そして、RPCにより、互いの実装するアプリケーションプログラムのメソッドに対する処理の依頼である「動作要求」を送信し、この依頼された処理の結果である「動作応答」を取得することができるようになっている。
また、これらの動作要求と動作応答の関係も、第1の実施形態の場合と同様、管理装置102と仲介装置101とで対称なものである。しかし、SMTPの場合には、通信のレベルでも管理装置102と仲介装置101とが対称な関係にあることが、HTTPの場合と異なる。
また、これらの動作要求と動作応答の関係も、第1の実施形態の場合と同様、管理装置102と仲介装置101とで対称なものである。しかし、SMTPの場合には、通信のレベルでも管理装置102と仲介装置101とが対称な関係にあることが、HTTPの場合と異なる。
図58に、この通信システムにおける通信シーケンスの例を示す。
上述したように、この通信システムにおいては、管理装置102と仲介装置101との間の通信は、電子メールを用いて行う。そして、電子メールには、送信元と宛先は存在し、その宛先から送信元に返信を行うことも可能である。しかし、初めの電子メールと返信とは全く独立したものであり、HTTPの場合のような、通信要求と通信応答のような関係はない。
従って、どちらの通信装置から先に通信を行ってもよいし、交互に電子メールを送信しなければならないということもないのであるが、ここでは、管理装置102から仲介装置101にまず電子メールを送信し、交互に計3通の電子メールを送受信する場合の例を示している。
上述したように、この通信システムにおいては、管理装置102と仲介装置101との間の通信は、電子メールを用いて行う。そして、電子メールには、送信元と宛先は存在し、その宛先から送信元に返信を行うことも可能である。しかし、初めの電子メールと返信とは全く独立したものであり、HTTPの場合のような、通信要求と通信応答のような関係はない。
従って、どちらの通信装置から先に通信を行ってもよいし、交互に電子メールを送信しなければならないということもないのであるが、ここでは、管理装置102から仲介装置101にまず電子メールを送信し、交互に計3通の電子メールを送受信する場合の例を示している。
この図に示すように、仲介装置101から管理装置102への電子メールには、仲介装置コマンドと、画像機器コマンドと、仲介装置101宛ての管理装置コマンドに対する応答(コマンド応答)と、画像形成装置100宛ての管理装置コマンドに対する応答とを記載して送信するようにしている。また、管理装置102から仲介装置101への電子メールには、仲介装置101宛て又は画像形成装置100宛ての管理装置コマンドと、仲介装置コマンドに対する応答と、画像機器コマンドに対する応答とを記載して送信するようにしている。なお、遅延通知を送信する場合には、上記コマンド応答に代えて遅延通知を記載してもよい。
従って、例えば画像機器コマンドaは、電子メールxに記載して転送し、管理装置102からのコマンド応答をその後の電子メールyに記載して転送することができる。また、仲介装置101宛ての管理装置コマンドcは、電子メールyに記載して転送し、仲介装置101からのコマンド応答をその後の電子メールzに記載して転送することができる。
従って、例えば画像機器コマンドaは、電子メールxに記載して転送し、管理装置102からのコマンド応答をその後の電子メールyに記載して転送することができる。また、仲介装置101宛ての管理装置コマンドcは、電子メールyに記載して転送し、仲介装置101からのコマンド応答をその後の電子メールzに記載して転送することができる。
なお、コマンド及びコマンド応答はそれぞれ任意の数ずつ(0でもよい)1通の電子メールに記載することができる。そして、1通の電子メールに記載した内容は、1つのメッセージであり、当然論理的に一括して転送する。そして、このようにすることにより、必要な情報を転送するための電子メールの数を減らし、オーバーヘッドを低減して通信の効率化を図っている。
また、コマンドを受信した後最初に送信する電子メールにコマンド応答を記載しなくてもよいことは、図7を用いて説明した第1の実施形態の場合と同様である。
また、コマンドを受信した後最初に送信する電子メールにコマンド応答を記載しなくてもよいことは、図7を用いて説明した第1の実施形態の場合と同様である。
次に、管理装置102及び仲介装置101における、コマンドやコマンド応答を結合し、また分離する処理を行うための機能構成及びその処理の手順について説明する。ハードウェア構成については、それぞれ第1の実施形態で説明したものと同様なものを使用することができる。
図59は、仲介装置101の機能のうち、コマンド及びコマンド応答に関する処理を行うための機能の構成を示す図11と対応する機能ブロック図である。そして、この図には、仲介装置101が管理装置102と通信を行う場合のデータの流れを示している。
図59に示す機能のうち、被管理側コマンドプール41,管理装置コマンドプール42,仲介装置コマンド生成手段43,管理装置コマンド実行結果生成手段44は、それぞれ図11に示した同名の構成要素と対応するものであり、同様な機能を有する。
図59は、仲介装置101の機能のうち、コマンド及びコマンド応答に関する処理を行うための機能の構成を示す図11と対応する機能ブロック図である。そして、この図には、仲介装置101が管理装置102と通信を行う場合のデータの流れを示している。
図59に示す機能のうち、被管理側コマンドプール41,管理装置コマンドプール42,仲介装置コマンド生成手段43,管理装置コマンド実行結果生成手段44は、それぞれ図11に示した同名の構成要素と対応するものであり、同様な機能を有する。
また、送信メッセージ収集手段75及び受信メッセージ分配手段78も、図11に示した同名の手段と対応するものである。ただし、送受信するためのデータの形式が、SMTPに対応した形式である点が図11に示した例とは異なる。しかし、コマンドやコマンド応答に対応する、個々のSOAPメッセージについては、図11の場合と同様なものである。
メール送信手段76及びメール受信手段77については、それぞれ一括送信手段及び一括受信手段に該当するが、送受信に使用するプロトコルが異なることに伴って、図11に示したHTTPリクエスト送信手段47a及びHTTPレスポンス受信手段47bとは異なるものである。
メール送信手段76及びメール受信手段77については、それぞれ一括送信手段及び一括受信手段に該当するが、送受信に使用するプロトコルが異なることに伴って、図11に示したHTTPリクエスト送信手段47a及びHTTPレスポンス受信手段47bとは異なるものである。
すなわち、メール送信手段76は、送信メッセージ収集手段45が生成した送信メッセージを含む、管理装置102宛の電子メールを生成し、メールサーバB′に送信する機能を有する。そして、それ以降の電子メールの転送には、仲介装置101は関与しない。また、1つの電子メールに送信メッセージをいくつ含めてもよいし、コマンド応答に係る送信メッセージと管理装置102側コマンドに係る送信メッセージとを任意に混在させることもできる点等は、図11に示した例の場合と同様である。
メール受信手段77は、定期的にメールサーバB′にアクセスして仲介装置101宛ての新着メールの有無を調べ、新着メールがあった場合にこれを受信する機能を有する。そしてここでは、受信する電子メールには、管理装置コマンド及びそのコマンドと関連付けられたコマンドIDを含む受信メッセージと、仲介装置コマンド又は画像機器コマンドに対する応答又は遅延通知及びそのコマンドと関連付けられたコマンドIDを含む受信メッセージとが、任意に混在して含まれている。
また、この実施形態においても、仲介装置101にHTTPサーバ機能部46とHTTPクライアント機能部47とを設けているが、これは、被管理装置10と通信を行うためのものである。
また、この実施形態においても、仲介装置101にHTTPサーバ機能部46とHTTPクライアント機能部47とを設けているが、これは、被管理装置10と通信を行うためのものである。
次に、このような機能を有する仲介装置101が管理装置102宛てに送信する電子メールの例を図60に示す。
この電子メールは、図16に示したHTTPリクエストの場合と同様に、ボディ部としてMIME(Multipurpose Internet Mail Extension)に従ったマルチパートのメッセージが記載され、この各パートには、それぞれSOAPエンベロープが埋め込まれている。すなわち、ボディの部分はHTTPリクエストの場合と同様なものになっている。
この電子メールは、図16に示したHTTPリクエストの場合と同様に、ボディ部としてMIME(Multipurpose Internet Mail Extension)に従ったマルチパートのメッセージが記載され、この各パートには、それぞれSOAPエンベロープが埋め込まれている。すなわち、ボディの部分はHTTPリクエストの場合と同様なものになっている。
しかし、ヘッダ部分はHTTPリクエストの場合とは異なり、電子メールの送信元アドレスを示すFrom、宛先アドレスを示すTo、表題を示すSubject等の情報が記載されている。
管理装置102から仲介装置101に送信する電子メールについては、ヘッダのうちFromの内容とToの内容を入れ替えたものになる。
また、これらの電子メールに記載されるSOAPエンベロープの内容は、HTTPリクエストやHTTPレスポンスの場合と同様なものである。ただし、各パートのエンティティヘッダの部分は、データのエンコード方式が異なるためHTTPの場合とは一部が異なる。
管理装置102から仲介装置101に送信する電子メールについては、ヘッダのうちFromの内容とToの内容を入れ替えたものになる。
また、これらの電子メールに記載されるSOAPエンベロープの内容は、HTTPリクエストやHTTPレスポンスの場合と同様なものである。ただし、各パートのエンティティヘッダの部分は、データのエンコード方式が異なるためHTTPの場合とは一部が異なる。
次に、以上説明したような構成及び機能を有する仲介装置101において実行する処理について、図61及び図62のフローチャートを用いて説明する。これらのフローチャートに示す処理は、仲介装置101のCPU52が所要の制御プログラムを実行することによって行うものである。
まず、図61にメッセージ送信時の処理の基本動作のフローチャートを示す。
仲介装置101のCPU52は、送信メッセージ収集手段45が被管理側コマンドやコマンド応答等の読み出しを試みるタイミングになると、図61のフローチャートに示す処理を開始する。
そして、まず被管理側コマンド収集処理を行う(S501)。この処理は、被管理側コマンドプール41から管理装置102に送信すべき被管理側コマンドを収集する処理であり、収集したデータからSOAPエンベロープのパートを生成する処理を含む。
仲介装置101のCPU52は、送信メッセージ収集手段45が被管理側コマンドやコマンド応答等の読み出しを試みるタイミングになると、図61のフローチャートに示す処理を開始する。
そして、まず被管理側コマンド収集処理を行う(S501)。この処理は、被管理側コマンドプール41から管理装置102に送信すべき被管理側コマンドを収集する処理であり、収集したデータからSOAPエンベロープのパートを生成する処理を含む。
次に、管理装置コマンドに対する応答である管理装置コマンド実行結果の収集処理を行う(S502)。この処理は、管理装置コマンドプール42から管理装置に送信すべきコマンド応答を収集する処理であり、やはり収集したデータからSOAPエンベロープのパートを生成する処理を含む。
その後、ステップS501及びS502の処理で生成したパートを1つにマージして、すべてのパートを含む電子メールを生成し(S503)、その電子メールを管理装置102に宛てて送信して(S504)、処理を終了する。
その後、ステップS501及びS502の処理で生成したパートを1つにマージして、すべてのパートを含む電子メールを生成し(S503)、その電子メールを管理装置102に宛てて送信して(S504)、処理を終了する。
以上の処理において、ステップS501及びS502の処理が収集手順の処理であり、ここではCPU52は送信メッセージ収集手段45として機能する。また、ステップS503及びS504が一括送信手順の処理であり、ここではCPU52がメール送信手段76として機能する。
これらの処理は、図27に示したステップS11乃至S14の処理と対応するものであるが、SMTPの場合には、電子メールの送信と受信の間には、通信要求と通信応答のような関係はないため、処理は一旦ここで終了し、電子メールを受信する場合には、別途図62に示す処理を行う。
これらの処理は、図27に示したステップS11乃至S14の処理と対応するものであるが、SMTPの場合には、電子メールの送信と受信の間には、通信要求と通信応答のような関係はないため、処理は一旦ここで終了し、電子メールを受信する場合には、別途図62に示す処理を行う。
図62には、メッセージ受信時の処理の基本動作のフローチャートを示す。
仲介装置101のCPU52は、定期的にメールサーバB′にアクセスし、仲介装置101宛ての新着の電子メールがあると、図62のフローチャートに示す処理を開始する。
この処理においては、まず新着の電子メールを受信する(S511)。そして、受信した電子メールのボディ(本文)を、各パートに分割する(S512)。ここで、各パートへの分割は、「MIME_boundary」で区分された要素に分割することであり、またここで全てのパートに関して分割する。
仲介装置101のCPU52は、定期的にメールサーバB′にアクセスし、仲介装置101宛ての新着の電子メールがあると、図62のフローチャートに示す処理を開始する。
この処理においては、まず新着の電子メールを受信する(S511)。そして、受信した電子メールのボディ(本文)を、各パートに分割する(S512)。ここで、各パートへの分割は、「MIME_boundary」で区分された要素に分割することであり、またここで全てのパートに関して分割する。
そしてその後、全てのパートを順に対象としてステップS513乃至S515の処理を繰り返す。この処理においては、まず対象のパートが管理装置コマンドを記載したパートか否か判断する(S513)。そして、管理装置コマンドであれば管理装置コマンド登録処理を行う(S514)。また、管理装置コマンドでないときは、被管理側コマンドに対する応答又は遅延通知が記載されたパートであるので、応答通知処理を行う(S515)。
ステップS514又はS515の後は、ステップS513に戻り、次のパートを対象として処理を繰り返す。そして、全てのパートについてこれらの処理を行った時点で、図62のフローチャートに示す処理を終了する。
以上の処理においては、ステップS511が一括受信手順の処理であり、ここではCPU52はメール受信手段77として機能する。また、ステップS512乃至S515が第1の分配手順の処理であり、ここではCPU52が受信メッセージ分配手段48として機能する。これらの処理は、図27に示したステップS15乃至S19の処理と対応するものである。
以上の処理においては、ステップS511が一括受信手順の処理であり、ここではCPU52はメール受信手段77として機能する。また、ステップS512乃至S515が第1の分配手順の処理であり、ここではCPU52が受信メッセージ分配手段48として機能する。これらの処理は、図27に示したステップS15乃至S19の処理と対応するものである。
以上の各処理の詳細は、第1の実施形態で図28乃至図32を用いて説明したものと同様である。また、遅延通知をした管理装置コマンドの実行に関する処理については、第1の実施形態で図33を用いて説明した処理と同様なものである。
以上で、仲介装置101において実行する、各コマンド及びコマンド応答の転送に関する処理の説明を終了する。
なお、管理装置102の機能及び管理装置102において実行する処理については、管理装置コマンドと被管理側コマンドとの意味合いが逆になる点以外は、仲介装置101の場合と概ね同様である。ただし、管理装置102は、画像形成装置100宛ての管理装置コマンドのように、他の装置に転送して実行させるべきコマンドを受信することはないので、HTTPクライアント機能部やHTTPサーバ機能部を設ける必要はない。また、第1の実施形態で図37を用いて説明したように、受信したコマンドの転送に関連する処理は行う必要がない。
以上で、仲介装置101において実行する、各コマンド及びコマンド応答の転送に関する処理の説明を終了する。
なお、管理装置102の機能及び管理装置102において実行する処理については、管理装置コマンドと被管理側コマンドとの意味合いが逆になる点以外は、仲介装置101の場合と概ね同様である。ただし、管理装置102は、画像形成装置100宛ての管理装置コマンドのように、他の装置に転送して実行させるべきコマンドを受信することはないので、HTTPクライアント機能部やHTTPサーバ機能部を設ける必要はない。また、第1の実施形態で図37を用いて説明したように、受信したコマンドの転送に関連する処理は行う必要がない。
以上説明してきたように、この発明は、SMTPのように、情報の送信と返信とが必ずしも対応しないプロトコルを使用して通信を行う場合にも適用できる。そして、この場合にも、仲介装置101を設け、画像形成装置100と管理装置102との間の通信を、この仲介装置101を介して行うようにしたことにより、管理装置102から複数の画像形成装置100に宛てた動作要求を送信する場合でも、仲介装置101までは一括して送信でき、また複数の画像形成装置100に宛てた動作要求に対する動作応答も仲介装置101から一括して受信できるので、通信のオーバーヘッドを低減して通信効率を高めることができる。これ以外の点についても、第1の実施形態の場合と概ね同様な効果を得ることができる。
また、通信に電子メールを用いれば、ファイアウォールの内側へも容易に情報を転送することができる。
なお、この第2の実施形態についても、第1の実施形態について説明した第1乃至第4の実施例やその変形例のような処理を採用し、同様な効果を得ることができる。
なお、この第2の実施形態についても、第1の実施形態について説明した第1乃至第4の実施例やその変形例のような処理を採用し、同様な効果を得ることができる。
〔各実施形態のその他の変形例〕
ここで、上述した各実施形態に適用する、その他の変形例について説明する。
上述した各実施形態においては、RPCを実現する上位プロトコルとしてSOAPを採用し、アプリケーションは直接プールを操作してRPCを実現しているが、アプリケーションとプールとの間にCORBA(Common Object Request Broker Architecture)やJAVA(登録商標)RMI(Remote Method Invocation)とのブリッジ(メッセージ変換機能)を備えることによってアプリケーションの開発効率をさらに向上させてもよい。
すなわち、上述した各実施形態において、各ノード間でのコマンド及びこれに対するコマンド応答のやり取りは、XMLで記述されたSOAPメッセージにより行うこととしているが、これに限るものでなく、他の形式で記述されていてもよい。
ここで、上述した各実施形態に適用する、その他の変形例について説明する。
上述した各実施形態においては、RPCを実現する上位プロトコルとしてSOAPを採用し、アプリケーションは直接プールを操作してRPCを実現しているが、アプリケーションとプールとの間にCORBA(Common Object Request Broker Architecture)やJAVA(登録商標)RMI(Remote Method Invocation)とのブリッジ(メッセージ変換機能)を備えることによってアプリケーションの開発効率をさらに向上させてもよい。
すなわち、上述した各実施形態において、各ノード間でのコマンド及びこれに対するコマンド応答のやり取りは、XMLで記述されたSOAPメッセージにより行うこととしているが、これに限るものでなく、他の形式で記述されていてもよい。
また、上述した各実施形態において、被管理装置10や画像形成装置100が、仲介装置101と管理装置102との間でコマンドやコマンド応答の送受信に使用するプロトコル(ここではSOAP)に対応していない場合、仲介装置101がデータ形式を変換し、被管理装置10や画像形成装置100が対応する形式でこれらの装置との間でコマンドやコマンド応答の送受信を行うようにしてもよい。例えば、画像形成装置100がSNMP(Simple Network Management Protocol)にしか対応していない場合、仲介装置101が画像機器コマンドをMIB(Management Information Base)形式に変換して転送することが考えられる。
また、送受信するコマンドやコマンド応答の情報量に制限を設けても構わない。特に、受信するコマンドの情報量を制限するようにすると、受信側がメモリ容量の限られた装置である場合にメモリの使用量を抑えることができる。
また、送受信するコマンドやコマンド応答の情報量に制限を設けても構わない。特に、受信するコマンドの情報量を制限するようにすると、受信側がメモリ容量の限られた装置である場合にメモリの使用量を抑えることができる。
また、上述した実施例において、SOAP標準のプロトコルだけでなく、SOAPとMIMEマルチパートを組み合わせた独自のプロトコルをもこれに加えて採用することにより、HTTPリクエスト、或いはHTTPレスポンスに含まれるSOAPエンベロープを全く独立したものとして扱うこととしているが、SOAPの関連仕様として定義されたSOAPアタッチメントによって、HTTPレスポンスに含まれる第1パートのSOAPエンベロープに、第2パート以降のSOAPエンベロープへのリンクを埋め込んでこれらを関連付けて引き渡す構成にしてもよい。SMTPを用いる電子メールの場合にも同様である。
更に、SOAP等の上位プロトコルの下位に位置するデータ通信のプロトコルとして、ここではHTTPあるいはSMTPを採用した例について説明したが、この下位プロトコルについても、FTP(File Transfer Protocol)等の他のプロトコルを採用してもよい。
また、ここでは仲介装置101と管理装置102とをインターネット103を介して接続した例について説明したが、これ以外にも、有線、無線を問わず、ネットワーク通信が可能な各種通信経路を用いることができる。仲介装置101、被管理仲介装置110、被管理装置10の相互間においても、LAN以外の各種通信経路を用いることもできる。
また、ここでは仲介装置101と管理装置102とをインターネット103を介して接続した例について説明したが、これ以外にも、有線、無線を問わず、ネットワーク通信が可能な各種通信経路を用いることができる。仲介装置101、被管理仲介装置110、被管理装置10の相互間においても、LAN以外の各種通信経路を用いることもできる。
さらにまた、通信システムの構成についても、以上説明したものに限られることはなく、遠隔管理システム以外の通信システムにもこの発明を適用できることは、言うまでもない。例えば、第2の通信装置が遅延通知等の機能に対応しているものであってもよいし、第1の通信装置が第2の通信装置や仲介装置を管理する機能を有しない装置であってもよい。また、第1の通信装置が、第2の通信装置が提供する種々の機能を利用して動作する装置であるような構成も考えられる。
この場合において、この発明を適用することにより、第1の通信装置が多数の第2の通信装置に処理を依頼する場合でも、少ない通信負荷で動作要求及び動作応答を授受することができるので、多数の第2の通信装置を連携して動作させるシステムを容易に実現でき、負荷の大きな処理を依頼する場合でも、多数の第2の通信装置間に効率よく処理を分散させることができる。
また、仲介装置を多段にカスケード接続する構成にも対応可能である。
この場合において、この発明を適用することにより、第1の通信装置が多数の第2の通信装置に処理を依頼する場合でも、少ない通信負荷で動作要求及び動作応答を授受することができるので、多数の第2の通信装置を連携して動作させるシステムを容易に実現でき、負荷の大きな処理を依頼する場合でも、多数の第2の通信装置間に効率よく処理を分散させることができる。
また、仲介装置を多段にカスケード接続する構成にも対応可能である。
また、この発明によるプログラムは、コンピュータを、第1の通信装置と複数の第2の通信装置との間の通信を仲介する仲介装置として機能させるためのプログラムであり、このようなプログラムをコンピュータに実行させることにより、上述したような効果を得ることができる。
このようなプログラムは、はじめからコンピュータに備えるROMあるいはHDD等の記憶手段に格納しておいてもよいが、記録媒体であるCD−ROMあるいはフレキシブルディスク,SRAM,EEPROM,メモリカード等の不揮発性記録媒体(メモリ)に記録して提供することもできる。そのメモリに記録されたプログラムをコンピュータにインストールしてCPUに実行させるか、CPUにそのメモリからこのプログラムを読み出して実行させることにより、上述した各手順を実行させることができる。
さらに、ネットワークに接続され、プログラムを記録した記録媒体を備える外部機器あるいはプログラムを記憶手段に記憶した外部機器からダウンロードして実行させることも可能である。
さらに、ネットワークに接続され、プログラムを記録した記録媒体を備える外部機器あるいはプログラムを記憶手段に記憶した外部機器からダウンロードして実行させることも可能である。
以上説明してきたように、この発明の仲介装置、通信システム、仲介装置の制御方法、プログラムあるいは記録媒体を用いれば、ある通信装置が複数の通信装置に動作要求を送信してその動作要求に対する動作応答を受け取るような通信システムを構成する場合において、通信装置間の通信を適切に仲介することにより、通信の効率を上げることができる。
従って、この発明を、このような通信システム又はこのような通信システムにおいて通信を仲介する仲介装置に適用することにより、通信の負荷が小さい通信システムを構成することができる。
従って、この発明を、このような通信システム又はこのような通信システムにおいて通信を仲介する仲介装置に適用することにより、通信の負荷が小さい通信システムを構成することができる。
10:被管理装置
41,142:被管理側コマンドプール
42,141:管理装置コマンドプール
43:仲介装置コマンド生成手段
43a:仲介装置コマンド生成ハンドラ
43b:画像機器コマンド転送ハンドラ
44,243:管理装置コマンド実行結果生成手段
44a:管理装置コマンドハンドラ
44b:管理装置コマンド転送ハンドラ
45,75,145:送信メッセージ収集手段
46,146,246:HTTPサーバ機能部
46a,146a,246a:HTTPレスポンス送信手段
46b,146b,246b:HTTPリクエスト受信手段
47,247:HTTPクライアント機能部
47a,247a:HTTPリクエスト送信手段
47b,247b:HTTPレスポンス受信手段
48,78,148:受信メッセージ分配手段
49:応答状況管理手段
52,201:CPU 57,206:PHY
76:メール送信手段 77:メール受信手段
100:画像形成装置 101:仲介装置
102:管理装置 103:インターネット
104:ファイアウォール 126:制御装置
143:管理装置コマンド生成手段
144:被管理側コマンド実行結果生成手段
244:画像機器コマンド生成手段
41,142:被管理側コマンドプール
42,141:管理装置コマンドプール
43:仲介装置コマンド生成手段
43a:仲介装置コマンド生成ハンドラ
43b:画像機器コマンド転送ハンドラ
44,243:管理装置コマンド実行結果生成手段
44a:管理装置コマンドハンドラ
44b:管理装置コマンド転送ハンドラ
45,75,145:送信メッセージ収集手段
46,146,246:HTTPサーバ機能部
46a,146a,246a:HTTPレスポンス送信手段
46b,146b,246b:HTTPリクエスト受信手段
47,247:HTTPクライアント機能部
47a,247a:HTTPリクエスト送信手段
47b,247b:HTTPレスポンス受信手段
48,78,148:受信メッセージ分配手段
49:応答状況管理手段
52,201:CPU 57,206:PHY
76:メール送信手段 77:メール受信手段
100:画像形成装置 101:仲介装置
102:管理装置 103:インターネット
104:ファイアウォール 126:制御装置
143:管理装置コマンド生成手段
144:被管理側コマンド実行結果生成手段
244:画像機器コマンド生成手段
Claims (41)
- 第1の通信装置と複数の第2の通信装置との間の通信を仲介し、前記第1の通信装置に対して通信要求を送信し、前記第1の通信装置からその通信要求に対する通信応答を受信する仲介装置において、
前記各第2の通信装置から、前記第1の通信装置からの動作要求に対する動作応答を受信する個別受信手段と、
該個別受信手段が受信した各動作応答を前記通信要求として一括して前記第1の通信装置に送信する一括送信手段と、
その通信要求に対する通信応答として、前記第1の通信装置から、前記第2の通信装置宛ての複数の動作要求を一括して受信する一括受信手段と、
該受信手段が受信した各動作要求を、該各動作要求に含まれる宛先情報に従って宛先となる第2の通信装置に送信する個別送信手段とを設けたことを特徴とする仲介装置。 - 請求項1記載の仲介装置であって、
前記動作要求及び動作応答がそれぞれ、形式を変更せずに複数結合して転送可能な1つのメッセージを生成することができる形式で表現され、また複数結合された状態では形式を変更せずに分割して転送可能な個々の動作要求及び動作応答に戻すことができる形式で表現されていることを特徴とする仲介装置。 - 請求項1又は2記載の仲介装置であって、
前記一括送信手段が前記第1の通信装置に対して定期的に通信要求を送信するようにしたことを特徴とする仲介装置。 - 請求項1乃至3のいずれか一項記載の仲介装置であって、
当該仲介装置宛ての動作要求に係る動作を実行し、実行結果としてその動作要求に対する動作応答を生成する手段を有し、
前記一括送信手段を、前記個別受信手段が受信した各動作応答に加え、前記第1の通信装置からの当該仲介装置宛ての動作要求に対する動作応答も前記通信要求として一括して前記第1の通信装置に送信する手段とし、
前記一括受信手段を、その通信要求に対する通信応答として、前記第1の通信装置から、前記第2の通信装置宛ての動作要求に加え、当該仲介装置宛ての動作要求も一括して受信する手段としたことを特徴とする仲介装置。 - 第1の通信装置と複数の第2の通信装置との間の通信を仲介し、前記第1の通信装置に対して通信要求を送信し、前記第1の通信装置からその通信要求に対する通信応答を受信する仲介装置において、
前記第1の通信装置からの前記第2の通信装置宛ての動作要求と、該動作要求に対する動作応答とを記憶する記憶手段と、
前記動作応答を前記記憶手段から読み出す収集手段と、
前記第1の通信装置に対して、前記収集手段が読み出した複数の動作応答を前記通信要求として一括して送信する一括送信手段と、
その通信要求に対する通信応答として、前記第1の通信装置から、複数の前記動作要求を一括して受信する一括受信手段と、
該一括受信手段が受信した各動作要求を、動作要求毎に分割して前記記憶手段に記憶させる分配手段と、
前記各第2の通信装置から、前記動作応答を受信すると共に、受信した動作応答を、その動作応答と対応する動作要求と関連付けて前記記憶手段に記憶させる個別受信手段と、
前記動作要求を前記記憶手段から読み出すと共に、読み出した各動作要求を、その動作要求に含まれる宛先情報に従って宛先となる第2の通信装置に送信する個別送信手段とを設けたことを特徴とする仲介装置。 - 第1の通信装置と複数の第2の通信装置との間の通信を仲介し、前記第1の通信装置に対してHTTPリクエストを送信し、前記第1の通信装置からそのHTTPリクエストに対するHTTPレスポンスを受信する仲介装置において、
前記各第2の通信装置から、前記第1の通信装置からのSOAPリクエストに対するSOAPレスポンスを受信する個別受信手段と、
該個別受信手段が受信した各SOAPレスポンスを1つのHTTPリクエストに記載して前記第1の通信装置に送信する一括送信手段と、
そのHTTPリクエストに対するHTTPレスポンスとして、前記第1の通信装置から、前記第2の通信装置宛ての複数のSOAPリクエストを1つのHTTPレスポンスに記載した状態で受信する一括受信手段と、
該受信手段が受信した各SOAPリクエストを、該各SOAPリクエストに含まれる宛先情報に従って宛先となる第2の通信装置に送信する個別送信手段とを設けたことを特徴とする仲介装置。 - 請求項6記載の仲介装置であって、
前記SOAPリクエスト及びSOAPレスポンスがそれぞれ、形式を変更せずに複数結合して転送可能な1つのメッセージを生成することができる形式で表現され、また複数結合された状態では形式を変更せずに分割して転送可能な個々のSOAPリクエスト及びSOAPレスポンスに戻すことができる形式で表現されていることを特徴とする仲介装置。 - 請求項6又は7記載の仲介装置であって、
前記一括送信手段が前記第1の通信装置に対して定期的にHTTPリクエストを送信するようにしたことを特徴とする仲介装置。 - 請求項6乃至8のいずれか一項記載の仲介装置であって、
当該仲介装置宛てのSOAPリクエストによって要求された動作を実行し、そのSOAPリクエストに対するSOAPレスポンスに記載すべき実行結果を生成する手段を有し、
前記一括送信手段を、前記個別受信手段が受信した各SOAPレスポンスに加え、前記第1の通信装置からの当該仲介装置宛てのSOAPリクエストに対するSOAPレスポンスも1つのHTTPリクエストに記載して前記第1の通信装置に送信する手段とし、
前記一括受信手段を、そのHTTPリクエストに対するHTTPレスポンスとして、前記第1の通信装置から、前記第2の通信装置宛てのSOAPリクエストに加え、当該仲介装置宛てのSOAPリクエストも1つのHTTPレスポンスに記載した状態で受信する手段としたことを特徴とする仲介装置。 - 第1の通信装置と複数の第2の通信装置との間の通信を仲介し、前記第1の通信装置に対してHTTPリクエストを送信し、前記第1の通信装置からそのHTTPリクエストに対するHTTPレスポンスを受信する仲介装置において、
前記第1の通信装置からの前記第2の通信装置宛ての動作要求と、該動作要求に対する動作応答とを記憶する記憶手段と、
前記動作応答を前記記憶手段から読み出す収集手段と、
前記第1の通信装置に対して、前記収集手段が読み出した動作応答の内容を記載した複数のSOAPレスポンスを1つのHTTPリクエストに記載して送信する一括送信手段と、
そのHTTPリクエストに対するHTTPレスポンスとして、前記第1の通信装置から、前記動作要求の内容を記載した複数のSOAPリクエストを1つのHTTPレスポンスに記載した状態で受信する一括受信手段と、
該一括受信手段が受信した各SOAPリクエストに記載された動作要求の内容を、動作要求毎に分割して前記記憶手段に記憶させる分配手段と、
前記各第2の通信装置から、前記動作応答の内容を記載したSOAPレスポンスを受信すると共に、受信したSOAPレスポンスに記載された動作応答の内容を、その動作応答と対応する動作要求と関連付けて前記記憶手段に記憶させる個別受信手段と、
前記動作要求を前記記憶手段から読み出すと共に、読み出した各動作要求の内容を記載したSOAPリクエストを、その動作要求に含まれる宛先情報に従って宛先となる第2の通信装置に送信する個別送信手段とを設けたことを特徴とする仲介装置。 - 第1の通信装置と、複数の第2の通信装置と、該第1の通信装置と各第2の通信装置との間の通信を仲介する仲介装置とを備え、前記仲介装置が、前記第1の通信装置に対して通信要求を送信し、前記第1の通信装置からその通信要求に対する通信応答を受信する通信システムにおいて、
前記第1の通信装置と前記仲介装置との間の通信経路は、前記仲介装置側から通信要求を発した場合のみ通信可能な通信経路であり、
前記仲介装置と前記各第2の通信装置との間の通信経路は、前記仲介装置と前記第2の通信装置のどちらから通信要求を行っても通信可能な通信経路であり、
前記仲介装置に、
前記各第2の通信装置から、前記第1の通信装置からの動作要求に対する動作応答を受信する個別受信手段と、
該個別受信手段が受信した各動作応答を前記通信要求として一括して前記第1の通信装置に送信する一括送信手段と、
その通信要求に対する通信応答として、前記第1の通信装置から、前記第2の通信装置宛ての複数の動作要求を一括して受信する一括受信手段と、
該受信手段が受信した各動作要求を、該各動作要求に含まれる宛先情報に従って宛先となる第2の通信装置に送信する個別送信手段とを設け、
前記第1の通信装置に、
前記第2の通信装置宛ての動作要求に対する動作応答を前記通信要求として複数一括して前記仲介装置から受信する受信手段と、
その通信要求に対する通信応答として、前記第2の通信装置宛ての複数の動作要求を一括して前記仲介装置に送信する送信手段とを設け、
前記各第2の通信装置に、
前記第1の通信装置からの当該第2の通信装置宛ての動作要求を前記仲介装置から受信する受信手段と、
該手段が受信した動作要求に係る動作を実行し、実行結果としてその動作要求に対する動作応答を生成する手段と、
該手段が生成した動作応答を前記仲介装置に送信する送信手段とを設けたことを特徴とする通信システム。 - 請求項11記載の通信システムであって、
前記動作要求及び動作応答がそれぞれ、形式を変更せずに複数結合して転送可能な1つのメッセージを生成することができる形式で表現され、また複数結合された状態では形式を変更せずに分割して転送可能な個々の動作要求及び動作応答に戻すことができる形式で表現されていることを特徴とする通信システム。 - 請求項11又は12記載の通信システムであって、
前記仲介装置において、
前記一括送信手段が前記第1の通信装置に対して定期的に通信要求を送信するようにしたことを特徴とする通信システム。 - 請求項11乃至13のいずれか一項記載の通信システムであって、
前記仲介装置に、当該仲介装置宛ての動作要求に係る動作を実行し、実行結果としてその動作要求に対する動作応答を生成する手段を設け、
該仲介装置において、
前記一括送信手段を、前記個別受信手段が受信した各動作応答に加え、前記第1の通信装置からの当該仲介装置宛ての動作要求に対する動作応答も前記通信要求として一括して前記第1の通信装置に送信する手段とし、
前記一括受信手段を、その通信要求に対する通信応答として、前記第1の通信装置から、前記第2の通信装置宛ての動作要求に加え、当該仲介装置宛ての動作要求も一括して受信する手段とし、
前記第1の通信装置において、
前記受信手段を、前記第2の通信装置宛ての動作要求に対する動作応答に加え、前記仲介装置宛ての動作要求に対する動作応答も前記通信要求として一括して前記仲介装置から受信する手段とし、
前記送信手段を、その通信要求に対する通信応答として、前記第2の通信装置宛ての動作要求に加え、前記仲介装置宛ての動作要求も一括して前記仲介装置に送信する手段としたことを特徴とする通信システム。 - 第1の通信装置と、複数の第2の通信装置と、該第1の通信装置と各第2の通信装置との間の通信を仲介する仲介装置とを備え、前記仲介装置が、前記第1の通信装置に対して通信要求を送信し、前記第1の通信装置からその通信要求に対する通信応答を受信する通信システムにおいて、
前記第1の通信装置と前記仲介装置との間の通信経路は、前記仲介装置側から通信要求を発した場合のみ通信可能な通信経路であり、
前記仲介装置と前記各第2の通信装置との間の通信経路は、前記仲介装置と前記第2の通信装置のどちらから通信要求を行っても通信可能な通信経路であり、
前記仲介装置に、
前記第1の通信装置からの前記第2の通信装置宛ての動作要求と、該動作要求に対する動作応答とを記憶する記憶手段と、
前記動作応答を前記記憶手段から読み出す収集手段と、
前記第1の通信装置に対して、前記収集手段が読み出した複数の動作応答を前記通信要求として一括して送信する一括送信手段と、
その通信要求に対する通信応答として、前記第1の通信装置から、複数の前記動作要求を一括して受信する一括受信手段と、
該一括受信手段が受信した各動作要求を、動作要求毎に分割して前記記憶手段に記憶させる分配手段と、
前記各第2の通信装置から、前記動作応答を受信すると共に、受信した動作応答を、その動作応答と対応する動作要求と関連付けて前記記憶手段に記憶させる個別受信手段と、
前記動作要求を前記記憶手段から読み出すと共に、読み出した各動作要求を、その動作要求に含まれる宛先情報に従って宛先となる第2の通信装置に送信する個別送信手段とを設け、
前記第1の通信装置に、
前記動作要求と前記動作応答とを記憶する記憶手段と、
前記動作要求を生成して前記記憶手段に記憶させる要求生成手段と、
前記仲介装置から、前記動作応答を前記通信要求として複数一括して受信する受信手段と、
該受信手段が受信した各動作応答を、それぞれの動作応答と対応する動作要求と関連付けて前記第2の記憶手段に記憶させる分配手段と、
前記動作要求を前記記憶手段から読み出す収集手段と、
前記受信手段が受信した通信要求に対する通信応答として、前記仲介装置に対して、前記収集手段が読み出した複数の動作要求を一括して送信する送信手段とを設け、
前記各第2の通信装置に、
前記動作要求を前記仲介装置から受信する受信手段と、
該手段が受信した動作要求に係る動作を実行し、実行結果としてその動作要求に対する動作応答を生成する手段と、
該手段が生成した動作応答を前記仲介装置に送信する送信手段とを設けたことを特徴とする通信システム。 - 第1の通信装置と、複数の第2の通信装置と、該第1の通信装置と各第2の通信装置との間の通信を仲介する仲介装置とを備え、前記仲介装置が、前記第1の通信装置に対してHTTPリクエストを送信し、前記第1の通信装置からそのHTTPリクエストに対するHTTPレスポンスを受信する通信システムにおいて、
前記第1の通信装置と前記仲介装置との間の通信経路は、HTTPを用いた通信については、前記仲介装置側からHTTPリクエストを送信した場合のみ通信可能な通信経路であり、
前記仲介装置と前記各第2の通信装置との間の通信経路は、前記仲介装置と前記第2の通信装置のどちらからHTTPリクエストを送信しても通信可能な通信経路であり、
前記仲介装置に、
前記各第2の通信装置から、前記第1の通信装置からのSOAPリクエストに対するSOAPレスポンスを受信する個別受信手段と、
該個別受信手段が受信した各SOAPレスポンスを1つのHTTPリクエストに記載して前記第1の通信装置に送信する一括送信手段と、
そのHTTPリクエストに対するHTTPレスポンスとして、前記第1の通信装置から、前記第2の通信装置宛ての複数のSOAPリクエストを1つのHTTPレスポンスに記載した状態で受信する一括受信手段と、
該受信手段が受信した各SOAPリクエストを、該各SOAPリクエストに含まれる宛先情報に従って宛先となる第2の通信装置に送信する個別送信手段とを設け、
前記第1の通信装置に、
前記第2の通信装置宛てのSOAPリクエストに対するSOAPレスポンスを複数1つのHTTPリクエストに記載した状態で前記仲介装置から受信する受信手段と、
そのHTTPリクエストに対するHTTPレスポンスとして、前記第2の通信装置宛ての複数のSOAPリクエストを1つのHTTPレスポンスに記載して前記仲介装置に送信する送信手段とを設け、
前記各第2の通信装置に、
前記第1の通信装置からの当該第2の通信装置宛てのSOAPリクエストを前記仲介装置から受信する受信手段と、
該手段が受信したSOAPリクエストによって要求された動作を実行し、そのSOAPリクエストに対するSOAPレスポンスに記載すべき実行結果を生成する手段と、
該手段が生成した実行結果を、前記SOAPリクエストに対するSOAPレスポンスに記載して前記仲介装置に送信する送信手段とを設けたことを特徴とする通信システム。 - 請求項16記載の通信システムであって、
前記SOAPリクエスト及びSOAPレスポンスがそれぞれ、形式を変更せずに複数結合して転送可能な1つのメッセージを生成することができる形式で表現され、また複数結合された状態では形式を変更せずに分割して転送可能な個々のSOAPリクエスト及びSOAPレスポンスに戻すことができる形式で表現されていることを特徴とする通信システム。 - 請求項16又は17記載の通信システムであって、
前記仲介装置において、
前記一括送信手段が前記第1の通信装置に対して定期的にHTTPリクエストを送信するようにしたことを特徴とする通信システム。 - 請求項16乃至18のいずれか一項記載の通信システムであって、
前記仲介装置に、当該仲介装置宛てのSOAPリクエストによって要求された動作を実行し、そのSOAPリクエストに対するSOAPレスポンスに記載すべき実行結果を生成する手段を設け、
該仲介装置において、
前記一括送信手段を、前記個別受信手段が受信した各SOAPレスポンスに加え、前記第1の通信装置からの当該仲介装置宛てのSOAPリクエストに対するSOAPレスポンスも1つのHTTPリクエストに記載して前記第1の通信装置に送信する手段とし、
前記一括受信手段を、そのHTTPリクエストに対するHTTPレスポンスとして、前記第1の通信装置から、前記第2の通信装置宛てのSOAPリクエストに加え、当該仲介装置宛てのSOAPリクエストも1つのHTTPレスポンスに記載した状態で受信する手段とし、
前記第1の通信装置において、
前記受信手段を、前記第2の通信装置宛てのSOAPリクエストに対するSOAPレスポンスに加え、前記仲介装置宛てのSOAPリクエストに対するSOAPレスポンスも1つのHTTPリクエストに記載した状態で前記仲介装置から受信する手段とし、
前記送信手段を、そのHTTPリクエストに対するHTTPレスポンスとして、前記第2の通信装置宛てのSOAPリクエストに加え、前記仲介装置宛てのSOAPリクエストも1つのHTTPレスポンスに記載して前記仲介装置に送信する手段としたことを特徴とする通信システム。 - 第1の通信装置と、複数の第2の通信装置と、該第1の通信装置と各第2の通信装置との間の通信を仲介する仲介装置とを備え、前記仲介装置が、前記第1の通信装置に対してHTTPリクエストを送信し、前記第1の通信装置からそのHTTPリクエストに対するHTTPレスポンスを受信する通信システムにおいて、
前記第1の通信装置と前記仲介装置との間の通信経路は、HTTPを用いた通信については、前記仲介装置側からHTTPリクエストを送信した場合のみ通信可能な通信経路であり、
前記仲介装置と前記各第2の通信装置との間の通信経路は、前記仲介装置と前記第2の通信装置のどちらからHTTPリクエストを送信しても通信可能な通信経路であり、
前記仲介装置に、
前記第1の通信装置からの前記第2の通信装置宛ての動作要求と、該動作要求に対する動作応答とを記憶する記憶手段と、
前記動作応答を前記記憶手段から読み出す収集手段と、
前記第1の通信装置に対して、前記収集手段が読み出した動作応答の内容を記載した複数のSOAPレスポンスを1つのHTTPリクエストに記載して送信する一括送信手段と、
そのHTTPリクエストに対するHTTPレスポンスとして、前記第1の通信装置から、前記動作要求の内容を記載した複数のSOAPリクエストを1つのHTTPレスポンスに記載した状態で受信する一括受信手段と、
該一括受信手段が受信した各SOAPリクエストに記載された動作要求の内容を、動作要求毎に分割して前記記憶手段に記憶させる分配手段と、
前記各第2の通信装置から、前記動作応答の内容を記載したSOAPレスポンスを受信すると共に、受信したSOAPレスポンスに記載された動作応答の内容を、その動作応答と対応する動作要求と関連付けて前記記憶手段に記憶させる個別受信手段と、
前記動作要求を前記記憶手段から読み出すと共に、読み出した各動作要求の内容を記載したSOAPリクエストを、その動作要求に含まれる宛先情報に従って宛先となる第2の通信装置に送信する個別送信手段とを設け、
前記第1の通信装置に、
前記動作要求と前記動作応答とを記憶する記憶手段と、
前記動作要求を生成して前記記憶手段に記憶させる要求生成手段と、
前記仲介装置から、前記動作応答の内容を記載したSOAPレスポンスを複数1つのHTTPリクエストに記載した状態で受信する受信手段と、
前記受信手段が受信したSOAPレスポンスに記載された各動作応答の内容を、それぞれの動作応答と対応する動作要求と関連付けて前記記憶手段に記憶させる分配手段と、
前記動作要求を前記記憶手段から読み出す収集手段と、
前記受信手段が受信したHTTPリクエストに対するHTTPレスポンスとして、前記仲介装置に対して、前記収集手段が読み出した動作要求の内容を記載した複数のSOAPリクエストを1つのHTTPレスポンスに記載して送信する送信手段とを設け、
前記各第2の通信装置に、
前記第1の通信装置からの当該第2の通信装置宛てのSOAPリクエストを前記仲介装置から受信する受信手段と、
該手段が受信したSOAPリクエストによって要求された動作を実行し、そのSOAPリクエストに対するSOAPレスポンスに記載すべき実行結果を生成する手段と、
該手段が生成した実行結果を、前記SOAPリクエストに対するSOAPレスポンスに記載して前記仲介装置に送信する送信手段とを設けたことを特徴とする通信システム。 - 第1の通信装置と複数の第2の通信装置との間の通信を仲介し、前記第1の通信装置に対して通信要求を送信し、前記第1の通信装置からその通信要求に対する通信応答を受信する仲介装置の制御方法において、
前記各第2の通信装置から、前記第1の通信装置からの動作要求に対する動作応答を受信する個別受信手順と、
該個別受信手順で受信した各動作応答を前記通信要求として一括して前記第1の通信装置に送信する一括送信手順と、
その通信要求に対する通信応答として、前記第1の通信装置から、前記第2の通信装置宛ての複数の動作要求を一括して受信する一括受信手順と、
該受信手順で受信した各動作要求を、該各動作要求に含まれる宛先情報に従って宛先となる第2の通信装置に送信する個別送信手順とを前記仲介装置に実行させることを特徴とする仲介装置の制御方法。 - 請求項21記載の仲介装置の制御方法であって、
前記動作要求及び動作応答をそれぞれ、形式を変更せずに複数結合して転送可能な1つのメッセージを生成することができる形式で表現し、また複数結合された状態では形式を変更せずに分割して転送可能な個々の動作要求及び動作応答に戻すことができる形式で表現することを特徴とする仲介装置の制御方法。 - 請求項21又は22記載の仲介装置の制御方法であって、
前記仲介装置に、前記第1の通信装置に対して定期的に通信要求を送信させるようにしたことを特徴とする仲介装置の制御方法。 - 請求項21乃至23のいずれか一項記載の仲介装置の制御方法であって、
当該仲介装置宛ての動作要求に係る動作を実行し、実行結果としてその動作要求に対する動作応答を生成する手順をさらに前記仲介装置に実行させ、
前記一括送信手順において、前記個別受信手段が受信した各動作応答に加え、前記第1の通信装置からの当該仲介装置宛ての動作要求に対する動作応答も前記通信要求として一括して前記第1の通信装置に送信するようにし、
前記一括受信手順において、その通信要求に対する通信応答として、前記第1の通信装置から、前記第2の通信装置宛ての動作要求に加え、当該仲介装置宛ての動作要求も一括して受信するようにしたことを特徴とする仲介装置の制御方法。 - 第1の通信装置と複数の第2の通信装置との間の通信を仲介し、前記第1の通信装置に対して通信要求を送信し、前記第1の通信装置からその通信要求に対する通信応答を受信する仲介装置の制御方法において、
前記第1の通信装置からの前記第2の通信装置宛ての動作要求と、該動作要求に対する動作応答とを記憶する記憶領域を設ける手順と、
前記動作応答を前記記憶領域から読み出す収集手順と、
前記第1の通信装置に対して、前記収集手順で読み出した複数の動作応答を前記通信要求として一括して送信する一括送信手順と、
その通信要求に対する通信応答として、前記第1の通信装置から、複数の前記動作要求を一括して受信する一括受信手順と、
該一括受信手順で受信した各動作要求を、動作要求毎に分割して前記第1の記憶領域に記憶させる分配手順と、
前記各第2の通信装置から、前記動作応答を受信すると共に、受信した動作応答を、その動作応答と対応する動作要求と関連付けて前記記憶領域に記憶させる個別受信手順と、
前記動作要求を前記第1の記憶領域から読み出すと共に、読み出した各動作要求を、その動作要求に含まれる宛先情報に従って宛先となる第2の通信装置に送信する個別送信手順とを前記仲介装置に実行させることを特徴とする仲介装置の制御方法。 - 第1の通信装置と複数の第2の通信装置との間の通信を仲介し、前記第1の通信装置に対してHTTPリクエストを送信し、前記第1の通信装置からそのHTTPリクエストに対するHTTPレスポンスを受信する仲介装置の制御方法において、
前記各第2の通信装置から、前記第1の通信装置からのSOAPリクエストに対するSOAPレスポンスを受信する個別受信手順と、
該個別受信手順で受信した各SOAPレスポンスを1つのHTTPリクエストに記載して前記第1の通信装置に送信する一括送信手順と、
そのHTTPリクエストに対するHTTPレスポンスとして、前記第1の通信装置から、前記第2の通信装置宛ての複数のSOAPリクエストを1つのHTTPレスポンスに記載した状態で受信する一括受信手順と、
該受信手順で受信した各SOAPリクエストを、該各SOAPリクエストに含まれる宛先情報に従って宛先となる第2の通信装置に送信する個別送信手順とを前記仲介装置に実行させることを特徴とする仲介装置の制御方法。 - 請求項26記載の仲介装置の制御方法であって、
前記SOAPリクエスト及びSOAPレスポンスをそれぞれ、形式を変更せずに複数結合して転送可能な1つのメッセージを生成することができる形式で表現し、また複数結合された状態では形式を変更せずに分割して転送可能な個々のSOAPリクエスト及びSOAPレスポンスに戻すことができる形式で表現することを特徴とする仲介装置の制御方法。 - 請求項26又は27記載の仲介装置の制御方法であって、
前記仲介装置に、前記第1の通信装置に対して定期的にHTTPリクエストを送信させるようにしたことを特徴とする仲介装置の制御方法。 - 請求項26乃至28のいずれか一項記載の仲介装置の制御方法であって、
当該仲介装置宛てのSOAPリクエストによって要求された動作を実行し、そのSOAPリクエストに対するSOAPレスポンスに記載すべき実行結果を生成する手順をさらに前記仲介装置に実行させ、
前記一括送信手順において、前記個別受信手段が受信した各SOAPレスポンスに加え、前記第1の通信装置からの当該仲介装置宛てのSOAPリクエストに対するSOAPレスポンスも1つのHTTPリクエストに記載して前記第1の通信装置に送信するようにし、
前記一括受信手順において、そのHTTPリクエストに対するHTTPレスポンスとして、前記第1の通信装置から、前記第2の通信装置宛てのSOAPリクエストに加え、当該仲介装置宛てのSOAPリクエストも1つのHTTPレスポンスに記載した状態で受信するようにしたことを特徴とする仲介装置の制御方法。 - 第1の通信装置と複数の第2の通信装置との間の通信を仲介し、前記第1の通信装置に対してHTTPリクエストを送信し、前記第1の通信装置からそのHTTPリクエストに対するHTTPレスポンスを受信する仲介装置の制御方法において、
前記第1の通信装置からの前記第2の通信装置宛ての動作要求と、該動作要求に対する動作応答とを記憶する記憶領域を設ける手順と、
前記動作応答を前記記憶領域から読み出す収集手順と、
前記第1の通信装置に対して、前記収集手順で読み出した動作応答の内容を記載した複数のSOAPレスポンスを1つのHTTPリクエストに記載して送信する一括送信手順と、
そのHTTPリクエストに対するHTTPレスポンスとして、前記第1の通信装置から、前記動作要求の内容を記載した複数のSOAPリクエストを1つのHTTPレスポンスに記載した状態で受信する一括受信手順と、
該一括受信手順で受信した各SOAPリクエストに記載された動作要求の内容を、動作要求毎に分割して前記記憶領域に記憶させる分配手順と、
前記各第2の通信装置から、前記動作応答の内容を記載したSOAPレスポンスを受信すると共に、受信したSOAPレスポンスに記載された動作応答の内容を、その動作応答と対応する動作要求と関連付けて前記記憶領域に記憶させる個別受信手順と、
前記動作要求を前記記憶領域から読み出すと共に、読み出した各動作要求の内容を記載したSOAPリクエストを、その動作要求に含まれる宛先情報に従って宛先となる第2の通信装置に送信する個別送信手順とを前記仲介装置に実行させることを特徴とする仲介装置の制御方法。 - コンピュータを、第1の通信装置と複数の第2の通信装置との間の通信を仲介し、前記第1の通信装置に対して通信要求を送信し、前記第1の通信装置からその通信要求に対する通信応答を受信する仲介装置として機能させるためのプログラムにおいて、
前記コンピュータを、
前記各第2の通信装置から、前記第1の通信装置からの動作要求に対する動作応答を受信する個別受信手段と、
該個別受信手段が受信した各動作応答を前記通信要求として一括して前記第1の通信装置に送信する一括送信手段と、
その通信要求に対する通信応答として、前記第1の通信装置から、前記第2の通信装置宛ての複数の動作要求を一括して受信する一括受信手段と、
該受信手段が受信した各動作要求を、該各動作要求に含まれる宛先情報に従って宛先となる第2の通信装置に送信する個別送信手段として機能させるためのプログラム。 - 請求項31記載のプログラムであって、
前記動作要求及び動作応答をそれぞれ、形式を変更せずに複数結合して転送可能な1つのメッセージを生成することができる形式で表現し、また複数結合された状態では形式を変更せずに分割して転送可能な個々の動作要求及び動作応答に戻すことができる形式で表現するようにしたことを特徴とするプログラム。 - 請求項31又は32記載のプログラムであって、
前記一括送信手段に、前記第1の通信装置に対して定期的に通信要求を送信する機能を設けたことを特徴とするプログラム。 - 請求項31乃至33のいずれか一項記載のプログラムであって、
前記コンピュータを、前記仲介装置宛ての動作要求に係る動作を実行し、実行結果としてその動作要求に対する動作応答を生成する手段として機能させるためのプログラムを含み、
前記一括送信手段の機能を、前記個別受信手段が受信した各動作応答に加え、前記第1の通信装置からの前記仲介装置宛ての動作要求に対する動作応答も前記通信要求として一括して前記第1の通信装置に送信する機能とし、
前記一括受信手段の機能を、その通信要求に対する通信応答として、前記第1の通信装置から、前記第2の通信装置宛ての動作要求に加え、前記仲介装置宛ての動作要求も一括して受信する機能としたことを特徴とするプログラム。 - コンピュータを、第1の通信装置と複数の第2の通信装置との間の通信を仲介し、前記第1の通信装置に対して通信要求を送信し、前記第1の通信装置からその通信要求に対する通信応答を受信する仲介装置として機能させるためのプログラムにおいて、
前記コンピュータを、
前記第1の通信装置からの前記第2の通信装置宛ての動作要求と、該動作要求に対する動作応答とを記憶する記憶手段と、
前記動作応答を前記記憶手段から読み出す収集手段と、
前記第1の通信装置に対して、前記収集手段が読み出した複数の動作応答を前記通信要求として一括して送信する一括送信手段と、
その通信要求に対する通信応答として、前記第1の通信装置から、複数の前記動作要求を一括して受信する一括受信手段と、
該一括受信手段が受信した各動作要求を、動作要求毎に分割して前記記憶手段に記憶させる分配手段と、
前記各第2の通信装置から、前記動作応答を受信すると共に、受信した動作応答を、その動作応答と対応する動作要求と関連付けて前記記憶手段に記憶させる個別受信手段と、
前記動作要求を前記記憶手段から読み出すと共に、読み出した各動作要求を、その動作要求に含まれる宛先情報に従って宛先となる第2の通信装置に送信する個別送信手段として機能させるためのプログラム。 - コンピュータを、第1の通信装置と複数の第2の通信装置との間の通信を仲介し、前記第1の通信装置に対してHTTPリクエストを送信し、前記第1の通信装置からそのHTTPリクエストに対するHTTPレスポンスを受信する仲介装置として機能させるためのプログラムにおいて、
前記コンピュータを、
前記各第2の通信装置から、前記第1の通信装置からのSOAPリクエストに対するSOAPレスポンスを受信する個別受信手段と、
該個別受信手段が受信した各SOAPレスポンスを1つのHTTPリクエストに記載して前記第1の通信装置に送信する一括送信手段と、
そのHTTPリクエストに対するHTTPレスポンスとして、前記第1の通信装置から、前記第2の通信装置宛ての複数のSOAPリクエストを1つのHTTPレスポンスに記載した状態で受信する一括受信手段と、
該受信手段が受信した各SOAPリクエストを、該各SOAPリクエストに含まれる宛先情報に従って宛先となる第2の通信装置に送信する個別送信手段として機能させるためのプログラム。 - 請求項36記載のプログラムであって、
前記SOAPリクエスト及びSOAPレスポンスをそれぞれ、形式を変更せずに複数結合して転送可能な1つのメッセージを生成することができる形式で表現し、また複数結合された状態では形式を変更せずに分割して転送可能な個々のSOAPリクエスト及びSOAPレスポンスに戻すことができる形式で表現するようにしたことを特徴とするプログラム。 - 請求項36又は37記載のプログラムであって、
前記一括送信手段に、前記第1の通信装置に対して定期的にHTTPリクエストを送信する機能を設けたことを特徴とするプログラム。 - 請求項36乃至38のいずれか一項記載のプログラムであって、
前記コンピュータを、前記仲介装置宛てのSOAPリクエストによって要求された動作を実行し、そのSOAPリクエストに対するSOAPレスポンスに記載すべき実行結果を生成する手段として機能させるためのプログラムを含み、
前記一括送信手段の機能を、前記個別受信手段が受信した各SOAPレスポンスに加え、前記第1の通信装置からの前記仲介装置宛てのSOAPリクエストに対するSOAPレスポンスも1つのHTTPリクエストに記載して前記第1の通信装置に送信する機能とし、
前記一括受信手段の機能を、そのHTTPリクエストに対するHTTPレスポンスとして、前記第1の通信装置から、前記第2の通信装置宛てのSOAPリクエストに加え、前記仲介装置宛てのSOAPリクエストも1つのHTTPレスポンスに記載した状態で受信する機能としたことを特徴とするプログラム。 - コンピュータを、第1の通信装置と複数の第2の通信装置との間の通信を仲介し、前記第1の通信装置に対してHTTPリクエストを送信し、前記第1の通信装置からそのHTTPリクエストに対するHTTPレスポンスを受信する仲介装置として機能させるためのプログラムにおいて、
前記コンピュータを、
前記第1の通信装置からの前記第2の通信装置宛ての動作要求と、該動作要求に対する動作応答とを記憶する記憶手段と、
前記動作応答を前記記憶手段から読み出す収集手段と、
前記第1の通信装置に対して、前記収集手段が読み出した動作応答の内容を記載した複数のSOAPレスポンスを1つのHTTPリクエストに記載して送信する一括送信手段と、
そのHTTPリクエストに対するHTTPレスポンスとして、前記第1の通信装置から、前記動作要求の内容を記載した複数のSOAPリクエストを1つのHTTPレスポンスに記載した状態で受信する一括受信手段と、
該一括受信手段が受信した各SOAPリクエストに記載された動作要求の内容を、動作要求毎に分割して前記記憶手段に記憶させる分配手段と、
前記各第2の通信装置から、前記動作応答の内容を記載したSOAPレスポンスを受信すると共に、受信したSOAPレスポンスに記載された動作応答の内容を、その動作応答と対応する動作要求と関連付けて前記記憶手段に記憶させる個別受信手段と、
前記動作要求を前記記憶手段から読み出すと共に、読み出した各動作要求の内容を記載したSOAPリクエストを、その動作要求に含まれる宛先情報に従って宛先となる第2の通信装置に送信する個別送信手段として機能させるためのプログラム。 - 請求項31乃至40のいずれか一項記載のプログラムを記録したコンピュータ読み取り可能な記録媒体。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2003332572A JP2004139586A (ja) | 2002-09-24 | 2003-09-24 | 仲介装置、通信システム、仲介装置の制御方法、プログラム及び記録媒体 |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2002276448 | 2002-09-24 | ||
JP2003332572A JP2004139586A (ja) | 2002-09-24 | 2003-09-24 | 仲介装置、通信システム、仲介装置の制御方法、プログラム及び記録媒体 |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2004139586A true JP2004139586A (ja) | 2004-05-13 |
Family
ID=32473029
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2003332572A Pending JP2004139586A (ja) | 2002-09-24 | 2003-09-24 | 仲介装置、通信システム、仲介装置の制御方法、プログラム及び記録媒体 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2004139586A (ja) |
Cited By (14)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2008210089A (ja) * | 2007-02-26 | 2008-09-11 | Mitsubishi Electric Corp | コマンド中継装置及びコマンド中継プログラム |
JP2009048510A (ja) * | 2007-08-22 | 2009-03-05 | Internatl Business Mach Corp <Ibm> | データ通信を中継する中継装置、中継方法及び中継用プログラム |
US7822864B2 (en) | 2005-04-08 | 2010-10-26 | Ricoh Co., Ltd. | Communication apparatus, program product for adding communication mechanism to communication apparatus for providing improved usability and communication efficiency, and recording medium storing program product |
US7831737B2 (en) | 2005-05-24 | 2010-11-09 | Ricoh Company, Ltd. | Apparatus, method, and system for selecting one of a plurality of communication methods for communicating via a network based on the detection of a firewall |
JP2011055075A (ja) * | 2009-08-31 | 2011-03-17 | Kyocera Mita Corp | 画像形成システムおよび画像形成装置 |
JP2011059238A (ja) * | 2009-09-08 | 2011-03-24 | Ricoh Elemex Corp | 画像形成システム |
JP2011216107A (ja) * | 2007-03-01 | 2011-10-27 | Research In Motion Ltd | モバイル配信のためのシンジケートコンテンツの変換のためのシステムおよび方法 |
JP2013196139A (ja) * | 2012-03-16 | 2013-09-30 | Pfu Ltd | 情報処理システム、端末管理装置、情報処理装置、情報処理方法、及びプログラム |
JP2016060122A (ja) * | 2014-09-18 | 2016-04-25 | 富士ゼロックス株式会社 | 画像形成装置及びプログラム |
JP2017016422A (ja) * | 2015-07-01 | 2017-01-19 | コニカミノルタ株式会社 | 通信システム、管理サーバおよびプログラム |
JP2018124830A (ja) * | 2017-02-01 | 2018-08-09 | 日本電信電話株式会社 | メッセージ転送及び集約装置、並びにメッセージ転送及び集約方法 |
JP2019179446A (ja) * | 2018-03-30 | 2019-10-17 | ブラザー工業株式会社 | プログラム及び通信システム |
JP2021056748A (ja) * | 2019-09-30 | 2021-04-08 | ブラザー工業株式会社 | ドライバインストールプログラム、主仲介プログラム、副仲介プログラムおよび管理支援システム |
JP7496244B2 (ja) | 2020-06-04 | 2024-06-06 | 株式会社東海理化電機製作所 | 処理装置、プログラム、システム、および制御装置 |
-
2003
- 2003-09-24 JP JP2003332572A patent/JP2004139586A/ja active Pending
Cited By (16)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7822864B2 (en) | 2005-04-08 | 2010-10-26 | Ricoh Co., Ltd. | Communication apparatus, program product for adding communication mechanism to communication apparatus for providing improved usability and communication efficiency, and recording medium storing program product |
US7831737B2 (en) | 2005-05-24 | 2010-11-09 | Ricoh Company, Ltd. | Apparatus, method, and system for selecting one of a plurality of communication methods for communicating via a network based on the detection of a firewall |
JP2008210089A (ja) * | 2007-02-26 | 2008-09-11 | Mitsubishi Electric Corp | コマンド中継装置及びコマンド中継プログラム |
JP2011216107A (ja) * | 2007-03-01 | 2011-10-27 | Research In Motion Ltd | モバイル配信のためのシンジケートコンテンツの変換のためのシステムおよび方法 |
JP2009048510A (ja) * | 2007-08-22 | 2009-03-05 | Internatl Business Mach Corp <Ibm> | データ通信を中継する中継装置、中継方法及び中継用プログラム |
JP2011055075A (ja) * | 2009-08-31 | 2011-03-17 | Kyocera Mita Corp | 画像形成システムおよび画像形成装置 |
JP2011059238A (ja) * | 2009-09-08 | 2011-03-24 | Ricoh Elemex Corp | 画像形成システム |
JP2013196139A (ja) * | 2012-03-16 | 2013-09-30 | Pfu Ltd | 情報処理システム、端末管理装置、情報処理装置、情報処理方法、及びプログラム |
JP2016060122A (ja) * | 2014-09-18 | 2016-04-25 | 富士ゼロックス株式会社 | 画像形成装置及びプログラム |
JP2017016422A (ja) * | 2015-07-01 | 2017-01-19 | コニカミノルタ株式会社 | 通信システム、管理サーバおよびプログラム |
JP2018124830A (ja) * | 2017-02-01 | 2018-08-09 | 日本電信電話株式会社 | メッセージ転送及び集約装置、並びにメッセージ転送及び集約方法 |
JP2019179446A (ja) * | 2018-03-30 | 2019-10-17 | ブラザー工業株式会社 | プログラム及び通信システム |
JP7081273B2 (ja) | 2018-03-30 | 2022-06-07 | ブラザー工業株式会社 | プログラム及び通信システム |
JP2021056748A (ja) * | 2019-09-30 | 2021-04-08 | ブラザー工業株式会社 | ドライバインストールプログラム、主仲介プログラム、副仲介プログラムおよび管理支援システム |
JP7310506B2 (ja) | 2019-09-30 | 2023-07-19 | ブラザー工業株式会社 | ドライバインストールプログラム、主仲介プログラム、副仲介プログラムおよび管理支援システム |
JP7496244B2 (ja) | 2020-06-04 | 2024-06-06 | 株式会社東海理化電機製作所 | 処理装置、プログラム、システム、および制御装置 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
EP1638290B1 (en) | System, method and intermediary server for transmitting operational requests and responses between apparatuses | |
EP1638289B1 (en) | Transfer device, system and method for mediating communications between first and second communication devices | |
JP4704105B2 (ja) | 通信装置、通信システム及び通信方法 | |
US7620700B2 (en) | Communication system implementing a plurality of communication apparatuses as communication client and communication server for exchanging operation requests and operation responses | |
JP2004139586A (ja) | 仲介装置、通信システム、仲介装置の制御方法、プログラム及び記録媒体 | |
US7822864B2 (en) | Communication apparatus, program product for adding communication mechanism to communication apparatus for providing improved usability and communication efficiency, and recording medium storing program product | |
JP4160480B2 (ja) | 仲介装置、通信システム、仲介装置の制御方法、プログラム及び記録媒体 | |
JP4382006B2 (ja) | 仲介装置、通信システム、通信方法、プログラム及び記録媒体 | |
JP4030943B2 (ja) | 画像処理装置、画像処理システム、画像処理装置の制御方法、プログラム及び記録媒体 | |
JP2005322222A (ja) | 通信機能付加方法、プログラム、記録媒体及び通信装置 | |
Wu et al. | Dynamic reliable service routing in enterprise service bus | |
JP2005259106A (ja) | 仲介装置、分散処理システム、データ転送方法、プログラム及び記録媒体 | |
Mascolo et al. | Survey of middleware for networked embedded systems | |
JP2005259105A (ja) | 仲介装置、通信システム、仲介装置の制御方法、プログラム及び記録媒体 | |
JP2008301159A (ja) | ネットワーク間仲介装置 | |
Aldred et al. | Understanding the challenges in getting together: The semantics of decoupling in middleware | |
JP2004139565A (ja) | 通信方法 | |
JP4198562B2 (ja) | 通信クライアント、通信サーバ、通信システム及び通信方法 | |
JP5387065B2 (ja) | 画像処理装置 | |
JP4025331B2 (ja) | データ通信システム | |
JP2004140803A (ja) | 通信クライアント、通信クライアントの制御方法、プログラム及び記録媒体 | |
JP2004139566A (ja) | 通信装置、通信システム、通信装置の制御方法、プログラム及び記録媒体 | |
JP2004140804A (ja) | 通信サーバ、通信サーバの制御方法、プログラム及び記録媒体 | |
JP3667322B2 (ja) | データ通信方法 | |
Kosc | Evaluation of message-oriented middleware in the context of a future run control system for CMS |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20051019 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080826 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20081027 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20081118 |