JP2004139567A - 通信システム及び通信システムの制御方法 - Google Patents
通信システム及び通信システムの制御方法 Download PDFInfo
- Publication number
- JP2004139567A JP2004139567A JP2003305517A JP2003305517A JP2004139567A JP 2004139567 A JP2004139567 A JP 2004139567A JP 2003305517 A JP2003305517 A JP 2003305517A JP 2003305517 A JP2003305517 A JP 2003305517A JP 2004139567 A JP2004139567 A JP 2004139567A
- Authority
- JP
- Japan
- Prior art keywords
- request
- communication
- server
- client
- response
- 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.)
- Granted
Links
- 238000004891 communication Methods 0.000 title claims abstract description 835
- 238000000034 method Methods 0.000 title claims description 219
- 230000004044 response Effects 0.000 claims abstract description 590
- 230000005540 biological transmission Effects 0.000 claims description 113
- 239000000344 soap Substances 0.000 claims 49
- 238000012545 processing Methods 0.000 description 152
- 230000008569 process Effects 0.000 description 102
- 230000006870 function Effects 0.000 description 98
- 238000010586 diagram Methods 0.000 description 24
- 238000012546 transfer Methods 0.000 description 21
- 230000005856 abnormality Effects 0.000 description 9
- 230000002159 abnormal effect Effects 0.000 description 4
- 238000006243 chemical reaction Methods 0.000 description 3
- 238000011161 development Methods 0.000 description 3
- 230000000694 effects Effects 0.000 description 3
- 230000008859 change Effects 0.000 description 2
- 238000013461 design Methods 0.000 description 2
- 238000009434 installation Methods 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000007704 transition Effects 0.000 description 2
- 238000004378 air conditioning Methods 0.000 description 1
- 230000005611 electricity Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000010365 information processing Effects 0.000 description 1
- 230000002093 peripheral effect Effects 0.000 description 1
- XLYOFNOQVPJJNP-UHFFFAOYSA-N water Substances O XLYOFNOQVPJJNP-UHFFFAOYSA-N 0.000 description 1
Images
Landscapes
- Computer And Data Communications (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
【解決手段】 HTTPクライアント11は、HTTPサーバ12に対して、HTTPサーバ12に送信すべき動作要求であるクライアントコマンドとHTTPサーバ12からの動作要求であるサーバコマンドに対する応答(動作応答)とを1つのHTTPリクエスト(通信要求)に記載して送信する。また、HTTPサーバ12は、そのHTTPリクエストに対するHTTPレスポンス(通信応答)として、HTTPクライアント11に対して、HTTPクライアント11から受信したクライアントコマンドに対する応答とHTTPサーバ12からのサーバコマンドとを1つのHTTPレスポンスに記載して送信する。
【選択図】 図5
Description
また、通信システムを構成する通信装置の一部を通信クライアント、他の一部を通信サーバとし、通信クライアントと通信サーバとの間の通信を、常に通信クライアントから通信サーバに通信要求を送信し、通信サーバからその送信元の通信クライアントに対して通信応答を返すというプロトコルで行うようにすることも知られている。
そこで、通信クライアントから通信サーバへの動作要求を通信要求に記載して送信し、その動作要求に対する動作応答を通信応答に記載して通信サーバから通信クライアントに返信することも行われている。
例えば、特許文献1には、リモートプロセッサがローカルプロセッサに対して実行されるべきコマンドを指示するメッセージを送信し、そのコマンドに対する応答を受信することが記載されている。
また、この文献には、ローカルプロセッサがファイアウォールの内側に配置されている場合において、ローカルプロセッサからファイアウォールの外側のリモートプロセッサに通信要求を送信し、リモートプロセッサがこの通信要求に対する応答としてローカルプロセッサに対してコマンドを送信するようにすることにより、ファイアウォールの外側から内側に向けてコマンドを送信できるようにする技術も開示されている。
この場合において、ローカルプロセッサが通信クライアントに、リモートプロセッサが通信サーバに該当する。
現状では、ネットワークを介した通信をダイヤルアップ接続で行う環境もまだ多く残っており、このような環境においては上記の点が特に問題となる。このような環境では、コネクションの確立に数十秒単位の時間を要することもあり、またコネクションを確立する毎に料金を課金されるので、コネクションを確立する回数が増加するとコストアップにつながるためである。
この発明は、このような問題を解決し、通信要求とそれに対する通信応答とを送受信する複数の通信装置が互いに動作要求及び受信した動作要求に対する動作応答を送受信する場合において、通信の効率を上げることを目的とする。
このような通信システムにおいて、上記動作要求を関数呼び出しとし、上記動作応答をその関数呼び出しによって呼び出された関数の実行結果とするとよい。
さらに、上記通信クライアントにおいて、上記送信手段が、上記通信サーバに送信すべき動作応答と動作要求とを、それぞれSOAPメッセージとして送信するようにすると共に、上記受信手段が、上記通信サーバから受信する動作応答と動作要求とを、それぞれSOAPメッセージとして受信するようにし、上記通信サーバにおいて、上記受信手段が、上記通信クライアントから受信する動作応答と動作要求とを、それぞれSOAPメッセージとして受信するようにすると共に、上記送信手段が、上記通信クライアントに送信すべき動作応答と動作要求とを、それぞれSOAPメッセージとして送信するようにしてもよい。
さらに、上記通信クライアントにおいて、上記第1の記憶手段に記憶させたサーバ要求及び上記第2の記憶手段に記憶させたクライアント要求に優先順位を付す手段を設け、上記応答生成手段を、上記優先順位の高いサーバ要求から順に読み出し、そのサーバ要求に対する動作応答を生成して上記第1の記憶手段に記憶させる手段とし、上記収集手段を、上記優先順位の高いサーバ要求に対する動作応答から順に上記第1の記憶手段から読み出し、上記優先順位の高いクライアント要求から順に上記第2の記憶手段から読み出す手段とし、上記通信サーバにおいて、上記第1の記憶手段に記憶させたクライアント要求及び上記第2の記憶手段に記憶させたサーバ要求に優先順位を付す手段を設け、上記応答生成手段を、上記優先順位の高いクライアント要求から順に読み出し、そのクライアント要求に対する動作応答を生成して上記第1の記憶手段に記憶させる手段とし、上記収集手段を、上記優先順位の高いクライアント要求に対する動作応答から順に上記第1の記憶手段から読み出し、上記優先順位の高いサーバ要求から順に上記第2の記憶手段から読み出す手段とするとよい。
さらに、上記通信クライアントに、上記送信手順において、上記通信サーバに送信すべき動作応答と動作要求とを、それぞれSOAPメッセージとして送信させるようにすると共に、上記受信手段において、上記通信サーバから受信する動作応答と動作要求とを、それぞれSOAPメッセージとして受信させるようにし、上記通信サーバに、上記受信手順において、上記通信クライアントから受信する動作応答と動作要求とを、それぞれSOAPメッセージとして受信させるようにすると共に、上記送信手順において、上記通信クライアントに送信すべき動作応答と動作要求とを、それぞれSOAPメッセージとして送信させるようにするとよい。
まず図1に、この発明の通信装置を用いて構成したこの発明の通信システムの構成例を示す。
この通信システムは、図1に示すように、それぞれこの発明の通信装置である第1の通信装置1と第2の通信装置2とをネットワーク10によって接続して構成している。
そして、第1の通信装置1及び第2の通信装置2は、通信機能を備えたPC等のコンピュータを始め、通信機能及び情報処理機能を備えた各種電子装置として構成することができる。ネットワーク10としては、インターネットやLAN(ローカルエリアネットワーク)を始め、有線、無線を問わず、ネットワーク通信が可能な各種通信経路を用いることができる。
なお、ここではメソッドを入力と出力の形式を規定した論理的な関数として定義するものとする。そしてこの場合、動作要求はこの関数を呼び出す関数呼び出し(Procedure Call)となり、動作応答はその関数呼び出しによって呼び出された関数の実行結果となる。
図2(A)は、第1の通信装置1で第2の通信装置2に対する動作要求が発生したケースである。このケースでは、第1の通信装置1が第1の通信装置側動作要求を生成して第2の通信装置2に送信し、これを受け取った第2の通信装置2がその要求に対する動作応答を返すというモデルになる。
なお、ここではRPCによる引数並びに戻り値の受け渡しのプロトコルとしてSOAP(Simple Object Access Protocol)を採用し、上記の動作要求や動作応答は、ここではSOAPメッセージとして記載するようにしている。
そして、実際に動作要求や動作応答を転送するための通信プロトコルとしては、システムの構成に合わせて適当なものを採用することができ、例えばHTTP(HyperText Transfer Protocol)やSMTP(Simple Mail Transfer Protocol)を採用することができる。ただし、SMTPによって転送される電子メールには通信要求と通信応答のような対応関係がないため、SMTPを採用したシステムは、この発明の通信システムの実施例には含まれない。
そこで、まず通信プロトコルにHTTPを採用する場合の実施例について説明し、次にSMTPを採用する場合についても参考例として説明する。
図3に、HTTPを採用する場合の実施例を適用する通信システムの構成例を示す。
この通信システムは、図3に示すように、HTTPサーバ12とHTTPクライアント11とをインターネット13によって接続して構成している。ただし、セキュリティを向上させるため、HTTPクライアント11はファイアウォール14を介してインターネット13に接続するようにしている。そして、HTTPサーバ12が通信サーバであって第1の通信装置に該当し、HTTPクライアント11が通信クライアントであって第2の通信装置に該当する。
図4(A)は、HTTPクライアント11でHTTPサーバ12に対する動作要求が発生したケースである。このケースでは、HTTPクライアント11がクライアント側動作要求(クライアント要求に該当する。以下、「クライアントコマンド」とも呼ぶ)を生成してHTTPサーバ12に送信し、これを受け取ったHTTPサーバ12がそのコマンドに対する動作応答(以下、「コマンド応答」あるいは単に「応答」とも呼ぶ)を返すというモデルになる。
このように、動作要求及び動作応答は、RPCのレベルではHTTPクライアント11とHTTPサーバ12との間で対称に取り扱われるものである。しかし、通信のレベルでは対称ではない。
この図に示すように、この通信システムにおいては、通信は常に、HTTPクライアント11から通信要求としてHTTPリクエストをHTTPサーバ12に送信し、HTTPサーバ12からこの通信要求に対する通信応答としてHTTPレスポンスをHTTPクライアント11に返すという手順で行われる。例えばHTTPクライアント11が送信したHTTPリクエストXに対してHTTPサーバ12がHTTPレスポンスXを返し、同じくHTTPリクエストYに対してHTTPレスポンスYを返すという具合である。
そして、このようにすることにより、必要な情報を転送するために必要なコネクションの回数を減らし、オーバーヘッドを低減して通信の効率化を図っている。
説明のため、図5には極めて単純なシーケンス例を示したが、図6には、各HTTPリクエストやHTTPレスポンスに記載するコマンドやコマンド応答の数が一定でない例を示している。
また、コマンドを受信した場合に、次の送信機会の時点で応答を返す必要もない。例えば、図6に示すクライアントコマンドBのように、コマンドを記載したHTTPリクエストX′に対応するHTTPレスポンスX′に記載して応答を返さず、後のHTTPレスポンスY′に記載して応答を返すようにしてもよい。
もちろんサーバコマンドについても同様であり、サーバコマンドを記載したHTTPレスポンスの次のHTTPリクエストにそのコマンドに対する応答を記載する必要はない。そして、さらに後のHTTPリクエストに記載して転送すればよい。
この図に示すように、HTTPクライアント11及びHTTPサーバ12においてはそれぞれ、CPU31、ROM32、RAM33、SD(Secure Digital)カード34、ネットワークインタフェースカード(NIC)35を備え、これらがシステムバス36で接続されている。
RAM33は、CPU31がデータ処理を行う際のワークメモリ等として使用する一時記憶用メモリである。SDカード34は、装置の電源がオフになっても記憶内容を保持するようになっている不揮発性メモリである。NIC35は、インターネット13を始めとするネットワークを介して通信相手と情報の送受信を行うための通信手段である。
図8に示す機能のうち、クライアントコマンドプール41及びサーバコマンドプール42は、いずれかの書き換え可能な記憶手段に設けられるものである。例えばSDカード34に設けることができるが、RAM33や図示しないHDD(ハードディスクドライブ)に設けてもよい。クライアントコマンド生成手段43、サーバコマンド実行結果生成手段44、送信メッセージ収集手段45、受信メッセージ分配手段48の機能は、CPU31によって実現されるものである。また、HTTPリクエスト送信手段46及びHTTPレスポンス受信手段47の機能は、CPU31及びNIC35によって実現されるものである。
まず、クライアントコマンドプール41は、HTTPクライアント11に設けた第2の記憶領域に該当し、クライアントコマンドと、このコマンドに対する応答と、このコマンドの識別情報とを関連付けて登録するプールである。また、サーバコマンドプール42は、HTTPクライアント11に設けた第1の記憶領域に該当し、サーバコマンドと、このコマンドに対する応答と、このコマンドの識別情報とを関連付けて登録するプールである。これらのプールにおいては、コマンド毎にテーブル形式のコマンドシートを作成して情報を格納することにより、コマンドと、識別情報や応答等の情報とを関連付けるようにしている。また、これらのプールを設けた記憶手段がそれぞれHTTPクライアント11の第2,第1の記憶手段に該当するものとする。
この図に示すように、HTTPクライアント11においては、クライアントコマンドシートには、「コマンドID」、「メソッド名」、「入力パラメータ」、「状態」、「クライアントコマンド実行結果の通知先」、および「出力パラメータ」のデータを記憶する領域を設けている。そして、このうち「コマンドID」、「メソッド名」、および「入力パラメータ」がクライアントコマンド(及びそこに付されたID)に該当し、「状態」及び「クライアントコマンド実行結果の通知先」が管理情報に該当する。「出力パラメータ」は、HTTPサーバ12から受信するコマンド応答の内容である。
まず、「メソッド名」は、HTTPサーバ12に対するリクエストの内容であり、HTTPサーバ12において呼び出す関数の種類を示す。「入力パラメータ」は、「メソッド名」に付随するデータであり、関数を呼び出す際の引数である。「コマンドID」は、クライアントコマンドを識別するための識別情報である。「状態」は、クライアントコマンドに関する処理の進行状況を示すデータであり、処理の進行と共に、「未送信」→「応答待ち」→「応答受信済」と遷移していく。
なお、サーバコマンド実行結果生成手段44は、アプリケーションそのものではなく、サーバコマンドの実行に必要なアプリケーションを呼び出してコマンドを実行させるモジュールであってもよい。
この図に示すように、HTTPクライアント11においては、サーバコマンドシートには、「コマンドID」、「メソッド名」、「入力パラメータ」、「状態」、「出力パラメータ」、および「サーバコマンドの通知先」のデータを記憶する領域を設けている。そして、このうち「コマンドID」、「メソッド名」、および「入力パラメータ」がサーバコマンド(及びそこに付されたID)に該当し、「状態」及び「サーバコマンドの通知先」が管理情報に該当する。「出力パラメータ」は、サーバコマンドの実行結果であり、HTTPクライアント11が返すコマンド応答の内容となる。
まず、「メソッド名」は、HTTPクライアント11に対するリクエストの内容であり、HTTPクライアント11において呼び出す関数の種類を示す。「入力パラメータ」は、「メソッド名」に付随するデータであり、関数を呼び出す際の引数である。「コマンドID」は、サーバコマンドを識別するための識別情報である。「状態」は、サーバコマンドに関する処理の状態を示すデータであり、処理の進行と共に、「未処理」→「処理完了」→「応答済」、あるいは「未処理」→「処理中」→「処理完了」→「応答済」と遷移していく。「出力パラメータ」には、サーバコマンド実行結果生成手段44によって生成された応答が格納される。サーバコマンドの実行が終了し、上記の「状態」が「処理完了」となるまでは空である。「サーバコマンドの通知先」は、サーバコマンドの実行を行うモジュールを示す参照情報である。
なお、コマンド応答やクライアントコマンドに実行優先順位が指定されている場合には、送信メッセージ収集手段45がそれぞれ実行優先順位の高いものから順に読み出すようにすることが考えられる。
このようなコマンドやコマンド応答からのSOAPメッセージの生成は、WSDL(Web Service Description Language)に基づいて生成される所要の変換プログラム(シリアライザ)を実行し、データを直列化することによって行うことができる。
そこで、HTTPリクエスト送信手段46は、これらのいずれに係る送信メッセージかに関わり無く、送信メッセージ収集手段45が生成した全ての送信メッセージを1つのHTTPリクエストに含めて送信するようにしている。ただし、1つのHTTPリクエストに含める送信メッセージの数に上限を設けることも考えられる。
このようにするのは、上述のように、HTTPサーバ12からHTTPクライアント11に送信したい情報があったとしてもHTTPクライアント11から通信を要求しない限り送信できないためである。HTTPクライアント11から何も送信するデータがなかったとしても、定期的にHTTPサーバ12に対して通信要求を送信して、HTTPサーバ12からHTTPクライアント11に情報を送信する機会を与えることにより、転送の必要な情報が長期間に亘ってHTTPサーバ12に滞留してしまうことを防止できる。
ここで、受信メッセージとは、上記のコマンドや応答とコマンドIDとをSOAPメッセージとして記載したものである。
具体的には、サーバコマンド及びそのコマンドと関連付けられたコマンドIDとをサーバコマンドプール42にサーバコマンドシートを設けて登録すると共に、クライアントコマンドに対する応答については、そのコマンドと関連付けられたコマンドIDをクライアントコマンドプール41に記憶しているクライアントコマンドシートのコマンドIDと照合して対応するクライアントコマンドを特定し、そのクライアントコマンドについての「出力パラメータ」として登録する。
そしてこのとき、HTTPレスポンスを分割してそこに含まれる各受信メッセージを取り出し、そのデータをテーブルへの登録に必要な形式に変換するが、この変換は、WSDLに基づいて生成される所要の変換プログラム(デシリアライザ)を実行することによって行うことができる。
このHTTPリクエストは、図11に示すように、ボディ部としてMIME(Multipurpose Internet Mail Extension)に従ったマルチパートのメッセージが記載され、この各パートには、それぞれエンティティヘッダが記載されると共に、詳細な図示は省略しているが、SOAPエンベロープが埋め込まれている。図11の例では、HTTPリクエストのHTTPボディには、「MIME_boundary」で区分された各要素が、独立した第1パート、第2パート、第3パート、第4パートを構成しているが、HTTPボディに含めることのできるパート数は4つに限られない。0個を含め、いくつでもよい。
HTTPリクエストに埋め込まれて引き渡されるSOAPエンベロープには、クライアントコマンドを記載したものと、サーバコマンドに対する応答を記載したものとがある。
図12に示すように、このHTTPレスポンスは、形式としては図11に示したHTTPリクエストとHTTPヘッダ部が異なるのみであり、ボディ部にはHTTPリクエストの場合と同様に、詳細な図示は省略しているが、MIMEに従ったマルチパートのSOAPエンベロープが記載される。SOAPエンベロープの内容については、当然コマンドやコマンド応答の内容に従って異なるものである。
HTTPレスポンスに埋め込まれて引き渡されるSOAPエンベロープには、サーバコマンドを記載したものと、クライアントコマンドに対する応答を記載したものとがある。
図13に示すのは、クライアントコマンドを記載したパートの例である。
この例においては、まず、エンティティヘッダの部分の「X-SOAP-Type」ヘッダに、このパートに記載されているSOAPメッセージがSOAPリクエストであるかSOAPレスポンスであるかを示す情報を記載している。この例では、値の「Request」により、SOAPリクエストであること、すなわちコマンドを記載したSOAPメッセージであることを示している。
また、「SOAPAction」ヘッダは、SOAPリクエストの内容を示すものであり、この例では、「http://www.…」というURI(Uniform Resource Identifier)によりリクエストの内容を示している。なお、「SOAPAction」ヘッダは、SOAPメッセージがSOAPレスポンスである場合には付加しないため、メッセージの受信側において、このヘッダの有無により、SOAPメッセージがSOAPリクエストであるかSOAPレスポンスであるかを判断することもできる。
この例においては、まず、エンティティヘッダの部分の「X-SOAP-Type」ヘッダの値を「Response」と記載することにより、このパートに記載されているSOAPメッセージがSOAPレスポンスであること、すなわちコマンド応答を記載したSOAPメッセージであることを示している。
また、この例においても、名前空間の宣言は図13に示した例と同様である。そして、SOAPヘッダには、「コマンドID」のXMLタグの内容として、応答を生成したクライアントコマンドのIDである「12345」が記述されている。SOAPボディには、「異常通知」コマンドに対する応答であることを示すための「異常通知Response」タグが設けられ、その下位のタグに、コマンド応答の内容が記載される。ここでは、異常通知を正常に受信した旨の情報が記載されている。そして、この情報がクライアントコマンドシートの「出力パラメータ」の項目に格納される。
この例においても、図13の場合と同様に、「X-SOAP-Type」ヘッダの値の「Request」により、このパートに記載されているSOAPエンベロープがSOAPリクエストであることを示し、「SOAPAction」ヘッダの情報により、SOAPリクエストの内容を示している。
SOAPヘッダには、「要求ID」のXMLタグの内容として、このクライアントコマンドのIDである「98765」が記載されている。そして、SOAPボディには、サーバコマンドシートの「メソッド名」に記憶されるべきメソッドを指定する情報として、「温度センサ値取得」タグが記載され、その下位のタグ「センサID」の要素として、「入力パラメータ」に記憶されるべき引数が記載されている。ここではセンサ値を取得するセンサのIDが記載されている。
なお、サーバがこのようなコマンドを送信する場合としては、例えば、クライアントからの異常通知を受けて異常の原因を特定しようとする場合等が考えられる。
この例においても、図14の場合と同様に、エンティティヘッダの部分の「X-SOAP-Type」ヘッダの値を「Response」と記載することにより、このパートに記載されているSOAPメッセージがSOAPレスポンスであることを示している。
また、この例においても、名前空間の宣言は図15に示した例と同様である。そして、SOAPヘッダには、「コマンドID」のXMLタグの内容として、応答を生成したサーバコマンドのIDである「98765」が記述されている。SOAPボディには、「温度センサ値取得」コマンドに対する応答であることを示すための「温度センサ値取得Response」タグが設けられ、その下位のタグに、コマンド応答の内容が記載される。ここでは、値取得を要求されたセンサの示す温度値の情報が記載されている。
HTTPクライアント11のCPU31は、送信メッセージ収集手段45がクライアントコマンドやコマンド応答等の読み出しを試みるタイミングになると、図17のフローチャートに示す処理を開始する。
そして、まずクライアントコマンドの収集処理を行う(S11)。この処理は、クライアントコマンドプール41からHTTPサーバ12に送信すべきクライアントコマンドを収集する処理であり、収集したデータからSOAPエンベロープによるパートを生成する処理を含む。
その後、ステップS11及びS12の処理で生成したパートを1つにマージして、すべてのパートを含むHTTPリクエストを生成し(S13)、そのHTTPリクエストをHTTPサーバ12に送信する(S14)。
ここまでの処理において、ステップS11及びS12ではCPU31は送信メッセージ収集手段45として機能し、ステップS13及びS14ではHTTPリクエスト送信手段46として機能する。
そしてその後、分割して得た全てのパートを順に対象として、ステップS17乃至S19の処理を繰り返す。この処理においては、まず対象のパートがサーバコマンドを記載したパートか否か判断する(S17)。そして、サーバコマンドであればサーバコマンド登録処理を行う(S18)。また、サーバコマンドでないときは、クライアントコマンドに対する応答が記載されたパートであるので、応答通知処理を行う(S19)。
ここまでの処理において、ステップS15及びS16ではCPU31はHTTPレスポンス受信手段47として機能し、ステップS17乃至S19では受信メッセージ分配手段48として機能する。
図18は、図17のステップS11乃至S14の部分の処理をより詳細に示したフローチャートである。
なお、ステップS24又はS28で行った「状態」の変更は、実際にこの送信が終了してから行うようにしてもよい。このようにすることにより、通信エラーが発生しても、送信しようとしていたコマンド及びコマンド応答を再度送信の対象とすることができるので、システムの信頼性が向上する。
以上でHTTPリクエストの送信に関する処理を終了し、図17のステップS15以降に相当する処理に進む。
この処理においては、HTTPクライアント11のCPU31はまず、送信したHTTPリクエストに対するHTTPレスポンスの受信を待ち、HTTPサーバ12からこれを受信する(S31)。これを受信すると、そのHTTPボディを解析して各パートに分割する(S32)。
そしてその後、分割して得た各パートを順次対象として、ステップS33乃至ステップS39の処理を繰り返す。
以上のステップS37までの処理が終了すると、次のパートがあればそれを対象としてステップS33からの処理を繰り返す。
全てのパートについてステップS33乃至S39の処理が終了すると、図19のフローチャートに示した処理は終了する。
以上のような処理を行うことにより、HTTPクライアント11が、HTTPサーバ12に送信すべき動作要求とHTTPサーバ12から受信した動作要求に対する動作応答とを一括してHTTPサーバ12に送信することができる。また、HTTPサーバ12からの動作要求とHTTPサーバ12に送信した動作要求に対する動作応答とを一括してHTTPサーバ12から受信して処理することができる。
送信については、まず始めにHTTPヘッダを送信し、以後パートを生成するたびにそのパートを順次送信し、全てのパートの送信が完了した時点でその旨のデータを送信するようにしてもよい。このようにしても、これらの課程で送信されるデータが1つのみのHTTPヘッダを持つ論理的に連続した1つのHTTPリクエストであれば、1回のセッションで転送でき、ネゴシエーションの処理は1回で済むので、マージして送信する場合と同様な効果を得ることができる。また、送信すべきデータのバッファに必要なメモリ容量を低減できるので、低コストの通信装置で大きなデータを取り扱うことができる。
また、受信側でも、各パートに関する処理を、各パートを受信するたびに順次行うようにすることができる。このようにした場合に容量を低減できることは、送信側の場合と同様である。
図20は、この処理の一例を示すフローチャートである。
サーバコマンドの実行に関する処理としては、まず、図20のフローチャートに示す処理を、図19に示したステップS39の処理の後に、すなわちサーバコマンドをサーバコマンドプール42に登録した直後に行うことが考えられる。この処理において、HTTPクライアント11のCPU31は、サーバコマンド実行結果生成手段44として機能する。
そして、これが完了すると、実行結果をサーバコマンドシートの「出力パラメータ」の項目に登録する(S42)と共に、サーバコマンドシートの「状態」を「処理完了」に変更し、処理が完了したことを示して(S43)、もとの図19の処理に戻る。
以上の処理を行うことにより、サーバコマンドを実行し、その結果をコマンド応答としてHTTPサーバ12に送信可能な状態にすることができる。
この場合、CPU31は適当なタイミングで図21のフローチャートに示す処理を開始する。
その後、図20の場合と同様なステップS41乃至S43の処理を行って処理対象のサーバコマンドシートに記載されたサーバコマンドを実行し、これが完了するとステップSX1に戻って処理を繰り返す。
以上で、HTTPクライアント11において実行する、各コマンド及びコマンド応答の転送に関する処理の説明を終了する。
図22は、HTTPサーバ12の機能のうち、コマンド及びコマンド応答に関する処理を行うための機能の構成を示す機能ブロック図である。
図22に示す機能のうち、サーバコマンドプール141及びクライアントコマンドプール142は、いずれかの書き換え可能な記憶手段に設けられるものである。例えばSDカード34に設けることができるが、RAM33や図示しないHDD(ハードディスクドライブ)に設けてもよい。サーバコマンド生成手段143、クライアントコマンド実行結果生成手段144、送信メッセージ収集手段145、受信メッセージ分配手段148の機能は、CPU31によって実現されるものである。また、HTTPレスポンス送信手段146及びHTTPリクエスト受信手段147の機能は、CPU31及びNIC35によって実現されるものである。
まず、サーバコマンドプール141は、HTTPサーバ12に設けた第2の記憶領域に該当し、サーバコマンドと、このコマンドに対する応答と、このコマンドの識別情報とを関連付けて登録するプールである。また、クライアントコマンドプール142は、HTTPサーバ12に設けた第1の記憶領域に該当し、クライアントコマンドと、このコマンドに対する応答と、このコマンドの識別情報とを関連付けて登録するプールである。また、これらのプールを設けた記憶手段がそれぞれHTTPサーバ12の第2,第1の記憶手段に該当するものとする。
この図に示すように、HTTPサーバ12のサーバコマンドシートには、このサーバコマンドシートに記載するコマンドがサーバコマンドであり、その送信先やコマンド応答の送信元がHTTPクライアント11である点で若干異なるが、図9に示したHTTPクライアント11のクライアントコマンドシートとほぼ同様なデータを記憶する領域を設けている。「サーバコマンド実行結果の通知先」については、このシートに記載しているコマンドがサーバコマンドであることに伴って項目の名称が異なるが、内容は図9の「クライアントコマンド実行結果の通知先」と同様なものである。
なお、クライアントコマンド実行結果生成手段144は、アプリケーションそのものではなく、クライアントコマンドの実行に必要なアプリケーションを呼び出してコマンドを実行させるモジュールであってもよい。
この図に示すように、HTTPサーバ12のクライアントコマンドシートには、このクライアントコマンドシートに記載するコマンドがクライアントコマンドであり、その送信元やコマンド応答の送信先がHTTPクライアント11である点で若干異なるが、図10に示したHTTPクライアント11のサーバコマンドシートとほぼ同様なデータを記憶する領域を設けている。「クライアントコマンドの通知先」については、このシートに記載しているコマンドがサーバコマンドであることに伴って項目の名称が異なるが、内容は図10の「サーバコマンドの通知先」と同様なものである。
なお、コマンド応答やサーバコマンドに実行優先順位が指定されている場合には、送信メッセージ収集手段145がそれぞれ実行優先順位の高いものから順に読み出すようにすることが考えられる。
送信メッセージの形式については、HTTPクライアント11の場合と同様である。
そこで、HTTPレスポンス送信手段146は、これらのいずれに係る送信メッセージかに関わり無く、送信メッセージ収集手段145が生成した全ての送信メッセージを1つのHTTPレスポンスに含めて送信するようにしている。ただし、1つのHTTPレスポンスに含める送信メッセージの数に上限を設けることも考えられる。
このようにするのは、上述のように、HTTPサーバ12からファイアウォール14を越えてHTTPクライアント11にHTTPリクエストを送信することができないためである。
ここで、受信メッセージとは、上記のコマンドや応答とコマンドIDとをSOAPメッセージとして記載したものである。
具体的には、クライアントコマンド及びそのコマンドと関連付けられたコマンドIDとをクライアントコマンドプール142にクライアントコマンドシートを設けて登録すると共に、サーバコマンドに対する応答については、そのコマンドと関連付けられたコマンドIDをサーバコマンドプール141に記憶しているサーバコマンドシートのコマンドIDと照合して対応するサーバコマンドを特定し、そのサーバコマンドについての「出力パラメータ」として登録する。
このような機能を有するHTTPサーバ12が受信するHTTPリクエストは、HTTPクライアント11から送信されてくるものであるので、例えばHTTPクライアント11の機能の説明中で図11を用いて説明したものである。HTTPサーバ12が送信するHTTPレスポンスも、HTTPクライアント11に対して送信し、HTTPクライアント11が受信するものであるので、例えば図12を用いて説明したものである。これらに含まれるパートの内容も、図13乃至図16を用いて説明したようなものとなる。
HTTPサーバ12のCPU31は、HTTPクライアント11からHTTPリクエストが送信されてくると、図25のフローチャートに示す処理を開始する。
そして、まずそのHTTPリクエストを受信する(S111)。そして、受信したHTTPリクエストのHTTPボディを各パートに分割する(S112)。ここで、各パートへの分割は、「MIME_boundary」で区分された要素に分割することであり、またここで全てのパートに関して分割する。
ここまでの処理において、ステップS111及びS112ではCPU31はHTTPリクエスト受信手段147として機能し、ステップS113乃至S115では受信メッセージ分配手段148として機能する。
次に、クライアントコマンドに対する応答であるクライアントコマンド実行結果の収集処理を行う(S117)。この処理は、クライアントコマンドプールからHTTPクライアント11に送信すべきコマンド応答を収集する処理であり、やはり収集したデータからSOAPエンベロープによるパートを生成する処理を含む。
ここまでの処理において、ステップS116及びS117ではCPU31は送信メッセージ収集手段145として機能し、ステップS118及びS119ではHTTPレスポンス送信手段146として機能する。
図26は、図25のステップS111乃至S115の部分の処理をより詳細に示したフローチャートである。
この処理においては、HTTPサーバ12のCPU31はまず、HTTPクライアント
から送信されてきたHTTPリクエストを受信する(S121)。そして、これを受信すると、そのHTTPボディを解析して各パートに分割する(S122)。
そしてその後、分割して得た各パートを順次対象として、ステップS123乃至ステップS129の処理を繰り返す。
以上のステップS127までの処理が終了すると、次のパートがあればそれを対象としてステップS123からの処理を繰り返す。
全てのパートについてステップS123乃至S129の処理が終了すると、図26のフローチャートに示した処理は終了する。
以上でHTTPリクエストの受信に関する処理を終了し、図25のステップS116以降に相当する処理に進む。
この処理においては、HTTPサーバ12のCPU31はまず、サーバコマンドプール141から、「状態」が「未送信」であるサーバコマンドシートの「メソッド名」と「入力パラメータ」の内容を、送信すべきサーバコマンドとして収集し、「コマンドID」の内容もそのコマンドのコマンドIDとして収集する(S131)。HTTPサーバ12においては、「未送信」という「状態」は、コマンドがサーバコマンド生成手段143によって生成された後、まだHTTPクライアント11に通知されていないことを示すものであるので、これを基準にHTTPクライアント11に送信すべきコマンドを抽出できる。
なお、ステップS134又はS138で行った「状態」の変更は、実際にこの送信が終了してから行うようにしてもよい。このようにすることにより、通信エラーが発生しても、送信しようとしていたコマンド及びコマンド応答を再度送信の対象とすることができるので、システムの信頼性が向上する。
図28は、この処理の一例を示すフローチャートである。
クライアントコマンドの実行に関する処理としては、まず、図28のフローチャートに示す処理を、図27に示したステップS129の処理の後に、すなわちクライアントコマンドをクライアントコマンドプール42に登録した直後に行うことが考えられる。この処理において、HTTPサーバ12のCPU31は、クライアントコマンド実行結果生成手段144として機能する。
以上の処理を行うことにより、クライアントコマンドを実行し、その結果をコマンド応答としてHTTPクライアント11に送信可能な状態にすることができる。
この場合、CPU31は適当なタイミングで図29のフローチャートに示す処理を開始する。
その後、図28の場合と同様なステップS141乃至S143の処理を行って処理対象のクライアントコマンドシートに記載されたクライアントコマンドを実行し、これが完了するとステップSY1に戻って処理を繰り返す。
以上の処理を複数のスレッドで同時に行うようにしてもよいことは、HTTPクライアント11の場合と同様である。
以上で、HTTPサーバ12において実行する、各コマンド及びコマンド応答の転送に関する処理の説明を終了する。
また、このようにしたことにより、受信側でも、通信相手に送信した動作要求に対する動作応答と通信相手からの動作要求とを一括して受信し、その受信した内容を容易に個々のメッセージに分離し、それが動作要求であるか動作応答であるかに応じて適切な処理を行うことができる。
また、クライアントコマンドプールやサーバコマンドプールを設け、各アプリケーション等が生成した動作要求や動作応答をこれらのプールに蓄積しておくようにすることにより、動作要求や動作応答の生成を、通信相手に対する送信タイミングを考慮せずに行うことができる。従って、アプリケーション等が行う処理を簡略化することができ、設計や開発が容易になる。
また、受信した動作要求や動作応答を各々分離して適切なプールに記憶させる分配手段を設け、受信した情報もプールに蓄積しておくようにすることにより、受信した動作要求に係る動作の実行や、動作応答受信後の処理を、通信相手からの受信タイミングを考慮せずに行うことができる。従って、アプリケーション等が行う処理を簡略化することができ、設計や開発が容易になる。
さらに、動作要求に優先順位を付して、これが高いものから順に実行したり応答を送信したりするようにすれば、緊急を要する動作を優先的に実行すると共にその応答も優先的に返すことができる。
次に、通信プロトコルにSMTPを採用する場合の参考例について説明する。この参考例は、上述のHTTPを採用する場合の実施例と共通点が多いので、共通点については説明を省略するか簡単にし、相違点を中心に説明する。
まず、図30に、SMTPを採用する場合の参考例を適用する通信システムの構成例を示す。
なお、この参考例においては、通信装置Aと通信装置Bとが直接ネゴシエーションをした上で通信を行っているわけではないが、相互に情報転送を行うことが可能である。
上述したように、この通信システムにおいては、通信装置Aと通信装置Bとの間の通信は、電子メールを用いて行う。そして、電子メールには、送信元と宛先は存在し、その宛先から送信元に返信を行うことも可能である。しかし、初めの電子メールと返信とは全く独立したものであり、HTTPの場合のような、通信要求と通信応答のような関係はない。
従って、どちらの通信装置から先に通信を行ってもよいし、交互に電子メールを送信しなければならないということもないのであるが、ここでは、通信装置Aから通信装置Bにまず電子メールを送信し、交互に計3通の電子メールを送受信する場合の例を示している。
従って、例えば通信装置A側コマンドaは、電子メールxに記載して転送し、通信装置Bからのコマンド応答をその後の電子メールyに記載して転送することができる。また、通信装置B側コマンドcは、電子メールyに記載して転送し、通信装置Aからのコマンド応答をその後の電子メールzに記載して転送することができる。
また、コマンドを受信した後最初に送信する電子メールにコマンド応答を記載しなくてもよいことは、図6を用いて説明したHTTPの場合と同様である。
図33に示す機能のうち、通信装置A側コマンドプール51,通信装置B側コマンドプール52,通信装置A側コマンド生成手段53,通信装置B側コマンド実行結果生成手段54は、それぞれ図8に示したクライアントコマンドプール41,サーバコマンドプール42,クライアントコマンド生成手段43,サーバコマンド実行結果生成手段44と対応する機能であり、装置の名称が異なることにより名称を変更したものである。
メール送信手段56及びメール受信手段57については、それぞれ送信手段及び受信手段に該当するが、送受信に使用するプロトコルが異なることに伴って、図8に示したHTTPリクエスト送信手段46及びHTTPレスポンス受信手段47とは異なるものである。
この電子メールは、図11に示したHTTPリクエストの場合と同様に、ボディ部としてMIME(Multipurpose Internet Mail Extension)に従ったマルチパートのメッセージが記載され、この各パートには、それぞれSOAPエンベロープが埋め込まれている。すなわち、ボディの部分はHTTPリクエストの場合と同様なものになっている。
通信装置Bから通信装置Aに送信する電子メールについては、ヘッダのうちFromの内容とToの内容を入れ替えたものになる。
また、これらの電子メールに記載されるSOAPエンベロープの内容は、HTTPリクエストやHTTPレスポンスの場合と同様なものである。ただし、各パートのエンティティヘッダの部分は、データのエンコード方式が異なるためHTTPの場合とは一部が異なる。
通信装置AのCPUは、送信メッセージ収集手段45が通信装置A側コマンドやコマンド応答等の読み出しを試みるタイミングになると、図35のフローチャートに示す処理を開始する。
そして、まず通信装置A側コマンドの収集処理を行う(S51)。この処理は、通信装置A側コマンドプール51から通信装置Bに送信すべき通信装置A側コマンドを収集する処理であり、収集したデータからSOAPエンベロープのパートを生成する処理を含む。
その後、ステップS51及びS52の処理で生成したパートを1つにマージして、すべてのパートを含む電子メールを生成し(S53)、その電子メールを通信装置Bに宛てて送信して(S54)、処理を終了する。
これらの処理は、図17に示したステップS11乃至S14の処理と対応するものであるが、SMTPの場合には、電子メールの送信と受信の間には、通信要求と通信応答のような関係はないため、処理は一旦ここで終了し、電子メールを受信する場合には、別途図36に示す処理を行う。
通信装置AのCPUは、定期的にメールサーバA′にアクセスし、通信装置A宛ての新着の電子メールがあると、図36のフローチャートに示す処理を開始する。
この処理においては、まず新着の電子メールを受信する(S61)。そして、受信した電子メールのボディ(本文)を、各パートに分割する(S62)。ここで、各パートへの分割は、「MIME_boundary」で区分された要素に分割することであり、またここで全てのパートに関して分解する。
以上の処理においては、ステップS61ではCPU31はメール受信手段57として機能し、ステップS62乃至S65では受信メッセージ分配手段48として機能する。
これらの処理は、図17に示したステップS15乃至S19の処理と対応するものである。
以上で、通信装置Aにおいて実行する、各コマンド及びコマンド応答の転送に関する処理の説明を終了する。
なお、通信装置Bの機能及び通信装置Bにおいて実行する処理については、通信装置A側コマンドと通信装置B側コマンドとの意味合いが逆になる点以外は、通信装置Aの場合と全く同じであるので、説明を省略する。
また、通信に電子メールを用いれば、ファイアウォールの内側へも容易に情報を転送することができる。
次に、上述した実施例及び参考例の変形例について説明する。
まず、上述した実施例及び参考例では、説明を簡単にするために2つの通信装置からなる通信システムを例としてこの発明について説明したが、この発明は、さらに多くの通信装置からなる通信システムやこのような通信システムを構成する通信装置に適用することも当然可能である。
例えば、HTTPを採用する場合の実施例は、図37に示すような通信システムにも適用することができる。
ここで、被管理装置100の具体例としては、プリンタ、スキャナ、複写機、あるいはこれらの機能を兼ね備えたデジタル複合機等の画像処理装置を始めとし、通信機能を備えたネットワーク家電,自動販売機,医療機器,電源装置,空調システム,ガス・水道・電気等の計量システム等や、ネットワークに接続可能なコンピュータ等も含め、通信機能を備える各種電子装置が考えられる。
そして、仲介装置101及び被管理装置100は、その利用環境に応じて多様な階層構造を成す。例えば、図37に示す設置環境Aでは、管理装置102とHTTPによるコネクションを確立できる仲介装置101aが、被管理装置100a及び100bを従える単純な階層構造になっているが、設置環境Bでは、4台の被管理装置100を設置するため、1台の仲介装置101を設置しただけでは負荷が大きくなる。
なお、この場合において、管理装置102から被管理装置100にコマンドを送信しようとする場合、仲介装置101に対して、「被管理装置100にコマンドを送信せよ」というコマンドを送信し、コマンドに応じた動作として被管理装置100に対してコマンドを送信させることが考えられる。また、宛先として被管理装置100のいずれかを指定して仲介装置101に対してコマンドを送信し、仲介装置101に、自己以外が宛先となっているコマンドを、その宛先に対して転送させることも考えられる。
また、メールサーバを設ければ、SMTPを採用する場合の参考例も、このような通信システムに適用することができる。
また、送受信するコマンドやコマンド応答の情報量に制限を設けても構わない。特に、受信するコマンドの情報量を制限するようにすると、受信側がメモリ容量の限られた装置である場合にメモリの使用量を抑えることができる。
すなわち、上述した実施例及び参考例における、HTTPクライアント11とHTTPサーバ12との間等でのコマンド及びこれに対するコマンド応答のやり取りは、XMLで記述されたSOAPメッセージにより行うこととしているが、これに限るものでなく、他の形式で記述されていてもよい。
さらにまた、通信システムの構成についても、以上説明したものに限られることはない。
さらに、ネットワークに接続され、プログラムを記録した記録媒体を備える外部機器あるいはプログラムを記憶手段に記憶した外部機器からダウンロードして実行させることも可能である。
従って、この発明を、このような通信システムに適用することにより、通信の負荷が小さい通信システムを構成することができる。
10:ネットワーク 11:HTTPクライアント
12:HTTPサーバ 13:インターネット
14:ファイアウォール 31:CPU
32:ROM 33:RAM
34:SDカード 35:NIC
41,142:クライアントコマンドプール
42,141:サーバコマンドプール
43:クライアントコマンド生成手段
44:サーバコマンド実行結果生成手段
45,145:送信メッセージ収集手段
46:HTTPリクエスト送信手段
47:HTTPレスポンス受信手段
48,148:受信メッセージ分配手段
51:通信装置A側コマンドプール
52:通信装置B側コマンドプール
53:通信装置A側コマンド生成手段
54:通信装置B側コマンド実行結果生成手段
56:メール送信手段 57:メール受信手段
100:被管理装置 101:仲介装置
102:管理装置 143:サーバコマンド生成手段
144:クライアントコマンド実行結果生成手段
146:HTTPレスポンス送信手段
147:HTTPリクエスト受信手段
Claims (17)
- 通信クライアントと通信サーバとを備え、前記通信クライアントが前記通信サーバに対して通信要求を送信し、前記通信サーバからその通信要求に対する通信応答を受信し、その通信クライアントが前記通信サーバに対する動作要求であるクライアント要求を前記通信要求に記載して前記通信サーバに送信し、該通信サーバからそのクライアント要求に対する動作応答を記載した通信応答を受信する通信システムにおいて、
前記通信クライアントに、
前記クライアント要求と前記通信サーバからの動作要求であるサーバ要求に対する動作応答とを前記通信要求に記載して一括して前記通信サーバに送信する送信手段と、
その通信要求に対する通信応答として、前記通信サーバに送信したクライアント要求に対する動作応答と前記サーバ要求とを一括して前記通信サーバから受信する受信手段と、
前記サーバ要求に係る動作を実行し、実行結果としてそのサーバ要求に対する動作応答を生成する手段とを設け、
前記通信サーバに、
前記クライアント要求と前記通信クライアントに送信したサーバ要求に対する動作応答とを前記通信要求に記載した状態で一括して前記通信クライアントから受信する受信手段と、
その通信要求に対する通信応答として、前記通信クライアントから受信したクライアント要求に対する動作応答と前記サーバ要求とを一括して前記通信クライアントに送信する送信手段と、
前記クライアント要求に係る動作を実行し、実行結果としてそのクライアント要求に対する動作応答を生成する手段とを設けたことを特徴とする通信システム。 - 請求項1記載の通信システムであって、
前記動作要求は関数呼び出しであり、
前記動作応答はその関数呼び出しによって呼び出された関数の実行結果であることを特徴とする通信システム。 - 通信クライアントと通信サーバとを備え、前記通信クライアントが前記通信サーバに対して通信要求を送信し、前記通信サーバからその通信要求に対する通信応答を受信し、その通信クライアントが前記通信サーバに対する動作要求であるクライアント要求を前記通信要求に記載して前記通信サーバに送信し、該通信サーバからそのクライアント要求に対する動作応答を記載した通信応答を受信する通信システムにおいて、
前記通信クライアントに、
前記通信サーバからの動作要求であるサーバ要求とこの要求に対する動作応答とを記憶する第1の記憶手段と、
前記クライアント要求とこの要求に対する動作応答とを記憶する第2の記憶手段と、
前記クライアント要求を生成して前記第2の記憶手段に記憶させる要求生成手段と、
前記第1の記憶手段からサーバ要求を読み出し、そのサーバ要求に係る動作を実行し、その実行結果としてそのサーバ要求に対する動作応答を生成し、その動作応答を読み出したサーバ要求と関連付けて前記第1の記憶手段に記憶させる応答生成手段と、
前記サーバ要求に対する動作応答を前記第1の記憶手段から読み出すと共に、前記クライアント要求を前記第2の記憶手段から読み出す収集手段と、
前記通信サーバに対して、前記収集手段が読み出した動作応答とクライアント要求とを前記通信要求に記載して一括して送信する送信手段と、
その通信要求に対する通信応答として、前記通信サーバに送信したクライアント要求に対する動作応答と前記サーバ要求とを一括して前記通信サーバから受信する受信手段と、
該受信手段が受信したサーバ要求を前記第1の記憶手段に記憶させると共に、前記受信手段が受信した、前記通信サーバに送信したクライアント要求に対する動作応答を、前記通信サーバに送信したクライアント要求と関連付けて前記第2の記憶手段に記憶させる分配手段とを設け、
前記通信サーバに、
前記クライアント要求とこの要求に対する動作応答とを記憶する第1の記憶手段と、
前記サーバ要求とこの要求に対する動作応答とを記憶する第2の記憶手段と、
前記サーバ要求を生成して当該通信サーバの第2の記憶手段に記憶させる要求生成手段と、
当該通信サーバの第1の記憶手段からクライアント要求を読み出し、そのクライアント要求に係る動作を実行し、その実行結果としてそのクライアント要求に対する動作応答を生成し、その動作応答を読み出したクライアント要求と関連付けて当該通信サーバの第1の記憶手段に記憶させる応答生成手段と、
前記クライアント要求と前記通信クライアントに送信したサーバ要求に対する動作応答とを前記通信要求に記載した状態で一括して前記通信クライアントから受信する受信手段と、
該受信手段が受信したクライアント要求を当該通信サーバの第1の記憶手段に記憶させると共に、該受信手段が受信した、前記通信クライアントに送信したサーバ要求に対する動作応答を、前記通信クライアントに送信したサーバ要求と関連付けて当該通信サーバの第2の記憶手段に記憶させる分配手段と、
前記クライアント要求に対する動作応答を当該通信サーバの第1の記憶手段から読み出すと共に、前記サーバ要求を当該通信サーバの第2の記憶手段から読み出す収集手段と、
当該通信サーバの受信手段が受信した通信要求に対する通信応答として、その収集手段が読み出した動作応答とサーバ要求とを一括して前記通信クライアントに送信する送信手段とを設けたことを特徴とする通信システム。 - 請求項3記載の通信システムであって、
前記通信クライアントの送信手段が前記通信サーバに対して定期的に通信要求を送信するようにしたことを特徴とする通信システム。 - 請求項3又は4記載の通信システムであって、
前記通信クライアントにおいて、
前記送信手段が、前記通信サーバに送信すべき動作応答と動作要求とを、それぞれSOAPメッセージとして送信するようにすると共に、
前記受信手段が、前記通信サーバから受信する動作応答と動作要求とを、それぞれSOAPメッセージとして受信するようにし、
前記通信サーバにおいて、
前記受信手段が、前記通信クライアントから受信する動作応答と動作要求とを、それぞれSOAPメッセージとして受信するようにすると共に、
前記送信手段が、前記通信クライアントに送信すべき動作応答と動作要求とを、それぞれSOAPメッセージとして送信するようにしたたことを特徴とする通信システム。 - 請求項3乃至5のいずれか一項記載の通信システムであって、
前記通信クライアントにおいて、
前記第1の記憶手段に記憶させたサーバ要求及び前記第2の記憶手段に記憶させたクライアント要求に優先順位を付す手段を設け、
前記応答生成手段を、前記優先順位の高いサーバ要求から順に読み出し、そのサーバ要求に対する動作応答を生成して前記第1の記憶手段に記憶させる手段とし、
前記収集手段を、前記優先順位の高いサーバ要求に対する動作応答から順に前記第1の記憶手段から読み出し、前記優先順位の高いクライアント要求から順に前記第2の記憶手段から読み出す手段とし、
前記通信サーバにおいて、
前記第1の記憶手段に記憶させたクライアント要求及び前記第2の記憶手段に記憶させたサーバ要求に優先順位を付す手段を設け、
前記応答生成手段を、前記優先順位の高いクライアント要求から順に読み出し、そのクライアント要求に対する動作応答を生成して前記第1の記憶手段に記憶させる手段とし、
前記収集手段を、前記優先順位の高いクライアント要求に対する動作応答から順に前記第1の記憶手段から読み出し、前記優先順位の高いサーバ要求から順に前記第2の記憶手段から読み出す手段としたことを特徴とする通信システム。 - 通信クライアントと通信サーバとを備え、前記通信クライアントが前記通信サーバに対してHTTPリクエストを送信し、前記通信サーバからそのHTTPリクエストに対するHTTPレスポンスを受信し、前記通信クライアントが前記通信サーバに対するSOAPリクエストを前記HTTPリクエストに記載して前記通信サーバに送信し、該通信サーバからそのSOAPリクエストに対するSOAPレスポンスを記載したHTTPレスポンスを受信する通信システムにおいて、
前記通信クライアントに、
前記通信サーバに対するSOAPリクエストと前記通信サーバからのSOAPリクエストに対するSOAPレスポンスとを1つのHTTPリクエストに記載して前記通信サーバに送信する送信手段と、
そのHTTPリクエストに対するHTTPレスポンスとして、前記通信サーバに送信したSOAPリクエストに対するSOAPレスポンスと前記通信サーバからのSOAPリクエストとを、1つのHTTPレスポンスに記載した状態で前記通信サーバから受信する受信手段と、
前記通信サーバから受信したSOAPリクエストに係る動作を実行し、そのSOAPリクエストに対するSOAPレスポンスに記載すべき実行結果を生成する手段とを設け、
前記通信サーバに、
前記通信クライアントからのSOAPリクエストと前記通信クライアントに送信したSOAPリクエストに対するSOAPレスポンスとを1つのHTTPリクエストに記載した状態で前記通信クライアントから受信する受信手段と、
そのHTTPリクエストに対するHTTPレスポンスとして、前記通信クライアントからのSOAPリクエストに対するSOAPレスポンスと前記通信クライアントに対するSOAPリクエストとを、1つのHTTPレスポンスに記載して前記通信クライアントに送信する送信手段と、
前記通信クライアントから受信したSOAPリクエストに係る動作を実行し、そのSOAPリクエストに対するSOAPレスポンスに記載すべき実行結果を生成する手段と設けたことを特徴とする通信システム。 - 請求項7記載の通信システムであって、
前記SOAPリクエストには関数呼び出しを記載し、
前記SOAPレスポンスにはその関数呼び出しによって呼び出された関数の実行結果を記載するようにしたことを特徴とする通信システム。 - 通信クライアントと通信サーバとを備え、前記通信クライアントが前記通信サーバに対してHTTPリクエストを送信し、前記通信サーバからそのHTTPリクエストに対するHTTPレスポンスを受信し、前記通信クライアントが前記通信サーバに対するSOAPリクエストを前記HTTPリクエストに記載して前記通信サーバに送信し、該通信サーバからそのSOAPリクエストに対するSOAPレスポンスを記載したHTTPレスポンスを受信する通信システムにおいて、
前記通信クライアントに、
前記通信サーバからの動作要求であるサーバ要求とこの要求に対する動作応答とを記憶する第1の記憶手段と、
前記通信サーバに対する動作要求であるクライアント要求とこの要求に対する動作応答とを記憶する第2の記憶手段と、
前記クライアント要求を生成して前記第2の記憶手段に記憶させる要求生成手段と、
前記第1の記憶手段からサーバ要求を読み出し、そのサーバ要求に係る動作を実行し、その実行結果としてそのサーバ要求に対する動作応答を生成し、その動作応答を読み出したサーバ要求と関連付けて前記第1の記憶手段に記憶させる応答生成手段と、
前記サーバ要求に対する動作応答を前記第1の記憶手段から読み出すと共に、前記クライアント要求を前記第2の記憶手段から読み出す収集手段と、
前記通信サーバに対して、前記収集手段が読み出した動作応答の内容を記載したSOAPレスポンスと前記収集手段が読み出したクライアント要求の内容を記載したSOAPリクエストとを1つのHTTPリクエストに記載して送信する送信手段と、
その1つのHTTPリクエストに対するHTTPレスポンスとして、前記通信サーバに送信したSOAPリクエストに対するSOAPレスポンスと前記通信サーバからのSOAPリクエストとを、1つのHTTPレスポンスに記載した状態で前記通信サーバから受信する受信手段と、
該受信手段が受信したSOAPリクエストに記載されたサーバ要求の内容を前記第1の記憶手段に記憶させると共に、前記受信手段が受信したSOAPレスポンスに記載された、前記通信サーバに送信したクライアント要求に対する動作応答の内容を、前記通信サーバに送信したクライアント要求と関連付けて前記第2の記憶手段に記憶させる分配手段とを設け、
前記通信サーバに、
前記クライアント要求とこの要求に対する動作応答とを記憶する第1の記憶手段と、
前記サーバ要求とこの要求に対する動作応答とを記憶する第2の記憶手段と、
前記サーバ要求を生成して当該通信サーバの第2の記憶手段に記憶させる要求生成手段と、
当該通信サーバの第1の記憶手段からクライアント要求を読み出し、そのクライアント要求に係る動作を実行し、その実行結果としてそのクライアント要求に対する動作応答を生成し、その動作応答を読み出したクライアント要求と関連付けて当該通信サーバの第1の記憶手段に記憶させる応答生成手段と、
前記クライアント要求を記載したSOAPリクエストと、前記通信クライアントに送信したSOAPリクエストに対するSOAPレスポンスであって前記通信クライアントに送信したサーバ要求に対する動作応答を記載したSOAPレスポンスとを、1つのHTTPリクエストに記載した状態で前記通信クライアントから受信する受信手段と、
該受信手段が受信したSOAPリクエストに記載されたクライアント要求の内容を当該通信サーバの第1の記憶手段に記憶させると共に、該受信手段が受信したSOAPレスポンスに記載された動作応答の内容を、前記通信クライアントに送信したサーバ要求と関連付けて当該通信サーバの第2の記憶手段に記憶させる分配手段と、
前記クライアント要求に対する動作応答を当該通信サーバの第1の記憶手段から読み出すと共に、当該通信サーバのサーバ要求を前記第2の記憶手段から読み出す収集手段と、
前記1つのHTTPリクエストに対するHTTPレスポンスとして、その収集手段が読み出した動作応答の内容を記載したSOAPレスポンスと、その収集手段が読み出した動作要求の内容を記載したSOAPリクエストとを、1つのHTTPレスポンスに記載して前記通信クライアントに送信する送信手段とを設けたことを特徴とする通信システム。 - 請求項9記載の通信システムであって、
前記通信クライアントの送信手段が前記通信サーバに対して定期的にHTTPリクエストを送信するようにしたことを特徴とする通信システム。 - 請求項9又は10記載の通信システムであって、
前記通信クライアントにおいて、
前記第1の記憶手段に記憶させたサーバ要求及び前記第2の記憶手段に記憶させたクライアント要求に優先順位を付す手段を設け、
前記応答生成手段を、前記優先順位の高いサーバ要求から順に読み出し、そのサーバ要求に対する動作応答を生成して前記第1の記憶手段に記憶させる手段とし、
前記収集手段を、前記優先順位の高いサーバ要求に対する動作応答から順に前記第1の記憶手段から読み出し、前記優先順位の高いクライアント要求から順に前記第2の記憶手段から読み出す手段とし、
前記通信サーバにおいて、
前記第1の記憶手段に記憶させたクライアント要求及び前記第2の記憶手段に記憶させたサーバ要求に優先順位を付す手段を設け、
前記応答生成手段を、前記優先順位の高いクライアント要求から順に読み出し、そのクライアント要求に対する動作応答を生成して前記第1の記憶手段に記憶させる手段とし、
前記収集手段を、前記優先順位の高いクライアント要求に対する動作応答から順に前記第1の記憶手段から読み出し、前記優先順位の高いサーバ要求から順に前記第2の記憶手段から読み出す手段としたことを特徴とする通信システム。 - 通信クライアントと通信サーバとを備え、前記通信クライアントが前記通信サーバに対して通信要求を送信し、前記通信サーバからその通信要求に対する通信応答を受信し、その通信クライアントが前記通信サーバに対する動作要求であるクライアント要求を前記通信要求に記載して前記通信サーバに送信し、該通信サーバからそのクライアント要求に対する動作応答を記載した通信応答を受信する通信システムの制御方法において、
前記通信クライアントに、
前記クライアント要求と前記通信サーバからの動作要求であるサーバ要求に対する動作応答とを前記通信要求に記載して一括して前記通信サーバに送信する送信手順と、
その通信要求に対する通信応答として、前記通信サーバに送信したクライアント要求に対する動作応答と前記サーバ要求とを一括して前記通信サーバから受信する受信手順と、
前記サーバ要求に係る動作を実行し、実行結果としてそのサーバ要求に対する動作応答を生成する手順とを実行させ、
前記通信サーバに、
前記クライアント要求と前記通信クライアントに送信したサーバ要求に対する動作応答とを前記通信要求に記載した状態で一括して前記通信クライアントから受信する受信手順と、
その通信要求に対する通信応答として、前記通信クライアントから受信したクライアント要求に対する動作応答と前記サーバ要求とを一括して前記通信クライアントに送信する送信手順と、
前記クライアント要求に係る動作を実行し、実行結果としてそのクライアント要求に対する動作応答を生成する手順とを実行させることを特徴とする通信システムの制御方法。 - 請求項12記載の通信システムの制御方法であって、
前記動作要求は関数呼び出しであり、
前記動作応答はその関数呼び出しによって呼び出された関数の実行結果であることを特徴とする通信システムの制御方法。 - 通信クライアントと通信サーバとを備え、前記通信クライアントが前記通信サーバに対して通信要求を送信し、前記通信サーバからその通信要求に対する通信応答を受信し、その通信クライアントが前記通信サーバに対する動作要求であるクライアント要求を前記通信要求に記載して前記通信サーバに送信し、該通信サーバからそのクライアント要求に対する動作応答を記載した通信応答を受信する通信システムの制御方法において、
前記通信クライアントに、
前記通信サーバからの動作要求であるサーバ要求とこの要求に対する動作応答とを記憶する第1の記憶領域を設ける手順と、
前記クライアント要求とこの要求に対する動作応答とを記憶する第2の記憶領域を設ける手順と、
前記クライアント要求を生成して前記第2の記憶領域に記憶させる要求生成手順と、
前記第1の記憶領域からサーバ要求を読み出し、そのサーバ要求に係る動作を実行し、その実行結果としてそのサーバ要求に対する動作応答を生成し、その動作応答を読み出したサーバ要求と関連付けて前記第1の記憶領域に記憶させる応答生成手順と、
前記サーバ要求に対する動作応答を前記第1の記憶領域から読み出すと共に、前記クライアント要求を前記第2の記憶領域から読み出す収集手順と、
前記通信サーバに対して、前記収集手順で読み出した動作応答とクライアント要求とを前記通信要求に記載して一括して送信する送信手順と、
その通信要求に対する通信応答として、前記通信サーバに送信したクライアント要求に対する動作応答と前記サーバ要求とを一括して前記通信サーバから受信する受信手順と、
該受信手順で受信したサーバ要求を前記第1の記憶領域に記憶させると共に、前記受信手順で受信した、前記通信サーバに送信したクライアント要求に対する動作応答を、前記通信サーバに送信したクライアント要求と関連付けて前記第2の記憶領域に記憶させる分配手順とを実行させ、
前記通信サーバに、
前記クライアント要求とこの要求に対する動作応答とを記憶する第1の記憶領域を設ける手順と、
前記サーバ要求とこの要求に対する動作応答とを記憶する第2の記憶領域を設ける手順と、
前記サーバ要求を生成して当該通信サーバの第2の記憶領域に記憶させる要求生成手順と、
当該通信サーバの第1の記憶領域からクライアント要求を読み出し、そのクライアント要求に係る動作を実行し、その実行結果としてそのクライアント要求に対する動作応答を生成し、その動作応答を読み出したクライアント要求と関連付けて当該通信サーバの第1の記憶領域に記憶させる応答生成手順と、
前記クライアント要求と前記通信クライアントに送信したサーバ要求に対する動作応答とを前記通信要求に記載した状態で一括して前記通信クライアントから受信する受信手順と、
該受信手順で受信したクライアント要求を当該通信サーバの第1の記憶領域に記憶させると共に、その受信手順で受信した、前記通信クライアントに送信したサーバ要求に対する動作応答を、前記通信クライアントに送信したサーバ要求と関連付けて当該通信サーバの第2の記憶領域に記憶させる分配手順と、
前記クライアント要求に対する動作応答を当該通信サーバの第1の記憶領域から読み出すと共に、前記サーバ要求を当該通信サーバの第2の記憶領域から読み出す収集手順と、
当該通信サーバの受信手順で受信した通信要求に対する通信応答として、当該通信サーバの収集手順で読み出した動作応答とサーバ要求とを一括して前記通信クライアントに送信する送信手順とを実行させることを特徴とする通信システムの制御方法。 - 請求項14記載の通信システムの制御方法であって、
前記通信クライアントに、前記通信サーバに対して定期的に通信要求を送信させるようにしたことを特徴とする通信システムの制御方法。 - 請求項14又は15記載の通信システムの制御方法であって、
前記通信クライアントに、
前記送信手順において、前記通信サーバに送信すべき動作応答と動作要求とを、それぞれSOAPメッセージとして送信させるようにすると共に、
前記受信手段において、前記通信サーバから受信する動作応答と動作要求とを、それぞれSOAPメッセージとして受信させるようにし、
前記通信サーバに、
前記受信手順において、前記通信クライアントから受信する動作応答と動作要求とを、それぞれSOAPメッセージとして受信させるようにすると共に、
前記送信手順において、前記通信クライアントに送信すべき動作応答と動作要求とを、それぞれSOAPメッセージとして送信させるようにしたことを特徴とする通信システムの制御方法。 - 請求項14乃至16のいずれか一項記載の通信システムの制御方法であって、
前記通信クライアントにおいて、
前記第1の記憶領域に記憶させたサーバ要求及び前記第2の記憶領域に記憶させたクライアント要求に優先順位を付す手順を実行させると共に、
前記応答生成手順に、前記優先順位の高いサーバ要求から順に読み出し、そのサーバ要求に対する動作応答を生成して前記第1の記憶領域に記憶させるようにし、
前記収集手順に、前記優先順位の高いサーバ要求に対する動作応答から順に前記第1の記憶領域から読み出し、前記優先順位の高いクライアント要求から順に前記第2の記憶領域から読み出させるようにし、
前記通信サーバにおいて、
前記第1の記憶領域に記憶させたクライアント要求及び前記第2の記憶領域に記憶させたサーバ要求に優先順位を付す手順を実行させると共に、
前記応答生成手順に、前記優先順位の高いクライアント要求から順に読み出し、そのクライアント要求に対する動作応答を生成して前記第1の記憶領域に記憶させるようにし、
前記収集手順に、前記優先順位の高いクライアント要求に対する動作応答から順に前記第1の記憶領域から読み出し、前記優先順位の高いサーバ要求から順に前記第2の記憶領域から読み出させるようにしたことを特徴とする通信システムの制御方法。
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2003305517A JP4198562B2 (ja) | 2002-09-19 | 2003-08-28 | 通信クライアント、通信サーバ、通信システム及び通信方法 |
EP03255846.2A EP1418732B1 (en) | 2002-09-19 | 2003-09-18 | Communication system implementing a plurality of communication apparatuses as communication client and communication server for exchanging operation requests and operation responses |
US10/665,745 US7620700B2 (en) | 2002-09-19 | 2003-09-22 | Communication system implementing a plurality of communication apparatuses as communication client and communication server for exchanging operation requests and operation responses |
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2002272978 | 2002-09-19 | ||
JP2002276451 | 2002-09-24 | ||
JP2003305517A JP4198562B2 (ja) | 2002-09-19 | 2003-08-28 | 通信クライアント、通信サーバ、通信システム及び通信方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2004139567A true JP2004139567A (ja) | 2004-05-13 |
JP4198562B2 JP4198562B2 (ja) | 2008-12-17 |
Family
ID=32475193
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2003305517A Expired - Lifetime JP4198562B2 (ja) | 2002-09-19 | 2003-08-28 | 通信クライアント、通信サーバ、通信システム及び通信方法 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP4198562B2 (ja) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2012005588A (ja) * | 2010-06-23 | 2012-01-12 | Tomohiko Deguchi | サーバ装置およびプログラム |
-
2003
- 2003-08-28 JP JP2003305517A patent/JP4198562B2/ja not_active Expired - Lifetime
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2012005588A (ja) * | 2010-06-23 | 2012-01-12 | Tomohiko Deguchi | サーバ装置およびプログラム |
Also Published As
Publication number | Publication date |
---|---|
JP4198562B2 (ja) | 2008-12-17 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7620700B2 (en) | Communication system implementing a plurality of communication apparatuses as communication client and communication server for exchanging operation requests and operation responses | |
EP1638290B1 (en) | System, method and intermediary server for transmitting operational requests and responses between apparatuses | |
Braun et al. | Mobile agents: Basic concepts, mobility models, and the tracy toolkit | |
US11323508B2 (en) | Web service system and method | |
EP1638289B1 (en) | Transfer device, system and method for mediating communications between first and second communication devices | |
JP4704105B2 (ja) | 通信装置、通信システム及び通信方法 | |
US20080140857A1 (en) | Service-oriented architecture and methods for direct invocation of services utilizing a service requestor invocation framework | |
US20080140760A1 (en) | Service-oriented architecture system and methods supporting dynamic service provider versioning | |
US20030118353A1 (en) | Method and apparatus for managing intelligent assets in a distributed environment | |
JP2004334896A (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 | |
JP2004139586A (ja) | 仲介装置、通信システム、仲介装置の制御方法、プログラム及び記録媒体 | |
JP4966039B2 (ja) | ネットワーク対応機器及び機能提供方法 | |
JP2005322222A (ja) | 通信機能付加方法、プログラム、記録媒体及び通信装置 | |
JP4382006B2 (ja) | 仲介装置、通信システム、通信方法、プログラム及び記録媒体 | |
JP4030943B2 (ja) | 画像処理装置、画像処理システム、画像処理装置の制御方法、プログラム及び記録媒体 | |
EP1241834B1 (en) | Communication control apparatus and method | |
US8688858B2 (en) | Image processing device, device management system, and image processing method | |
JP4160480B2 (ja) | 仲介装置、通信システム、仲介装置の制御方法、プログラム及び記録媒体 | |
JP2004139565A (ja) | 通信方法 | |
JP4198562B2 (ja) | 通信クライアント、通信サーバ、通信システム及び通信方法 | |
JP2005259106A (ja) | 仲介装置、分散処理システム、データ転送方法、プログラム及び記録媒体 | |
JP2004140803A (ja) | 通信クライアント、通信クライアントの制御方法、プログラム及び記録媒体 | |
JP2004140804A (ja) | 通信サーバ、通信サーバの制御方法、プログラム及び記録媒体 | |
JP2004139566A (ja) | 通信装置、通信システム、通信装置の制御方法、プログラム及び記録媒体 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20051019 |
|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20080214 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080304 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080501 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20080930 |
|
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20081001 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111010 Year of fee payment: 3 |
|
R151 | Written notification of patent or utility model registration |
Ref document number: 4198562 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R151 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111010 Year of fee payment: 3 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121010 Year of fee payment: 4 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131010 Year of fee payment: 5 |
|
EXPY | Cancellation because of completion of term |