(57)【要約】【課題】  複数のサービス手段によって提供されるサービスを、ファイアウォール内における利用環境を維持したまま、ファイアウォールの外側からでも低コストで効率よく利用できるようにする。【解決手段】  ＳＯＡＰリクエストをＨＴＴＰリクエストに含めた状態で受信し、そのＳＯＡＰリクエストに対する応答であるＳＯＡＰレスポンスをＨＴＴＰレスポンスに含めて送信するサービス提供部１２３を複数備えたサーバ装置１０１に、外部装置２０１と、上記複数のサービス提供部１２３との間の通信を仲介する仲介機能部１１０の機能を付加することにより、外部装置２０１とサーバ装置１０１との間で、上記複数のサービス提供部１２３の動作に係るＳＯＡＰリクエスト及びＳＯＡＰレスポンスを複数一括して送受信できるようにする。【選択図】        図６
2005322222.tif 000002
【特許請求の範囲】
【請求項１】
ファイアウォールの内側の送信元から動作要求を通信要求に含めた状態で受信し、その送信元に対しその動作要求に対する応答である動作応答を通信応答に含めて送信するサービス手段を複数備えた第２の通信装置に、
ファイアウォールの外側の第１の通信装置と、前記複数のサービス手段との間の通信を仲介する仲介モジュールを付加することにより、
前記第１の通信装置と前記第２の通信装置との間で、前記複数のサービス手段の動作に係る動作要求及び動作応答を複数一括して送受信できるようにすることを特徴とする通信機能付加方法。
【請求項２】
請求項１記載の通信機能付加方法であって、
前記仲介モジュールが、
前記各サービス手段から、前記第１の通信装置からの動作要求に対する動作応答を受信する個別受信手段と、
該個別受信手段が受信した各動作応答を通信要求に含めて一括して前記第１の通信装置に送信する一括送信手段と、
その通信要求に対する通信応答に含めた状態で、前記第１の通信装置から、前記サービス手段に対する複数の動作要求を一括して受信する一括受信手段と、
該一括受信手段が受信した各動作要求を、該各動作要求に含まれる情報に従って宛先となるサービス手段に送信する個別送信手段との機能を実現するためのモジュールであることを特徴とする通信機能付加方法。
【請求項３】
請求項２記載の通信機能付加方法であって、
前記仲介モジュールが送受信する動作要求及び動作応答がそれぞれ、形式を変更せずに複数結合して転送可能な１つのメッセージを生成することができる形式で表現され、また複数結合された状態では、形式を変更せずに分割して転送可能な個々の動作要求及び動作応答に戻すことができる形式で表現されていることを特徴とする通信機能付加方法。
【請求項４】
請求項２又は３記載の通信機能付加方法であって、
前記一括送信手段が前記第１の通信装置に対して定期的に通信要求を送信する機能を有することを特徴とする通信機能付加方法。
【請求項５】
請求項１記載の通信機能付加方法であって、
前記仲介モジュールが、
前記第１の通信装置からの前記サービス手段宛ての動作要求と、該動作要求に対する動作応答とを記憶する記憶手段と、
前記動作応答を前記記憶手段から読み出す収集手段と、
前記第１の通信装置に対して、前記収集手段が読み出した複数の動作応答を前記通信要求に含めて一括して送信する一括送信手段と、
その通信要求に対する通信応答に含めた状態で、前記第１の通信装置から、複数の前記動作要求を一括して受信する一括受信手段と、
該一括受信手段が受信した各動作要求を、動作要求毎に分割して前記記憶手段に記憶させる分配手段と、
前記各サービス手段から、前記動作応答を受信すると共に、受信した動作応答を、その動作応答と対応する動作要求と関連付けて前記記憶手段に記憶させる個別受信手段と、
前記動作要求を前記記憶手段から読み出すと共に、読み出した各動作要求を、その動作要求に含まれる情報に従って宛先となるサービス手段に送信する個別送信手段との機能を実現するためのモジュールであることを特徴とする通信機能付加方法。
【請求項６】
請求項１記載の通信機能付加方法であって、
前記通信要求及び通信応答はそれぞれＨＴＴＰリクエスト及びＨＴＴＰレスポンスであり、
前記動作要求及び動作応答はそれぞれＳＯＡＰリクエスト及びＳＯＡＰレスポンスであり、
前記仲介モジュールは、
前記各サービス手段から、前記第１の通信装置からのＳＯＡＰリクエストに対するＳＯＡＰレスポンスを受信する個別受信手段と、
該個別受信手段が受信した各ＳＯＡＰレスポンスを１つのＨＴＴＰリクエストに記載して前記第１の通信装置に送信する一括送信手段と、
そのＨＴＴＰリクエストに対するＨＴＴＰレスポンスとして、前記第１の通信装置から、前記サービス手段宛ての複数のＳＯＡＰリクエストを１つのＨＴＴＰレスポンスに記載した状態で受信する一括受信手段と、
該一括受信手段が受信した各ＳＯＡＰリクエストを、該各ＳＯＡＰリクエストに含まれる情報に従って宛先となるサービス手段に送信する個別送信手段との機能を実現するためのモジュールであることを特徴とする通信機能付加方法。
【請求項７】
ファイアウォールの内側の送信元から動作要求を通信要求に含めた状態で受信し、その送信元に対しその動作要求に対する応答である動作応答を通信応答に含めて送信するサービス手段を複数備え、他の装置と通信可能な通信装置を制御するコンピュータに、
前記各サービス手段から、ファイアウォールの外側の通信相手からの動作要求に対する動作応答を受信する個別受信手段と、
該個別受信手段が受信した各動作応答を通信要求に含めて一括して前記通信相手に送信する一括送信手段と、
その通信要求に対する通信応答に含めた状態で、前記通信相手から、前記サービス手段に対する複数の動作要求を一括して受信する一括受信手段と、
該一括受信手段が受信した各動作要求を、該各動作要求に含まれる情報に従って宛先となるサービス手段に送信する個別送信手段との機能を付加するためのプログラム。
【請求項８】
請求項７記載のプログラムであって、
動作要求及び動作応答がそれぞれ、形式を変更せずに複数結合して転送可能な１つのメッセージを生成することができる形式で表現され、また複数結合された状態では形式を変更せずに分割して転送可能な個々の動作要求及び動作応答に戻すことができる形式で表現されているものであることを特徴とするプログラム。
【請求項９】
請求項７又は８記載のプログラムであって、
前記一括送信手段が前記通信相手に対して定期的に通信要求を送信する機能を有することを特徴とするプログラム。
【請求項１０】
ファイアウォールの内側の送信元から動作要求を通信要求に含めた状態で受信し、その送信元に対しその動作要求に対する応答である動作応答を通信応答に含めて送信するサービス手段を複数備え、他の装置と通信可能な通信装置を制御するコンピュータに、
ファイアウォールの外側の通信相手からの前記サービス手段宛ての動作要求と、該動作要求に対する動作応答とを記憶する記憶手段と、
前記動作応答を前記記憶手段から読み出す収集手段と、
前記通信相手に対して、前記収集手段が読み出した複数の動作応答を前記通信要求に含めて一括して送信する一括送信手段と、
その通信要求に対する通信応答に含めた状態で、前記通信相手から、複数の前記動作要求を一括して受信する一括受信手段と、
該一括受信手段が受信した各動作要求を、動作要求毎に分割して前記記憶手段に記憶させる分配手段と、
前記各サービス手段から、前記動作応答を受信すると共に、受信した動作応答を、その動作応答と対応する動作要求と関連付けて前記記憶手段に記憶させる個別受信手段と、
前記動作要求を前記記憶手段から読み出すと共に、読み出した各動作要求を、その動作要求に含まれる情報に従って宛先となるサービス手段に送信する個別送信手段との機能を付加するためのプログラム。
【請求項１１】
ファイアウォールの内側の送信元からＳＯＡＰリクエストをＨＴＴＰリクエストに記載した状態で受信し、その送信元に対しそのＳＯＡＰリクエストに対する応答であるＳＯＡＰレスポンスをＨＴＴＰレスポンスに記載して送信するサービス手段を複数備え、他の装置と通信可能な通信装置を制御するコンピュータに、
前記各サービス手段から、ファイアウォールの外側の通信相手からのＳＯＡＰリクエストに対するＳＯＡＰレスポンスを受信する個別受信手段と、
該個別受信手段が受信した各ＳＯＡＰレスポンスを１つのＨＴＴＰリクエストに記載して前記通信相手に送信する一括送信手段と、
そのＨＴＴＰリクエストに対するＨＴＴＰレスポンスとして、前記通信相手から、前記サービス手段宛ての複数のＳＯＡＰリクエストを１つのＨＴＴＰレスポンスに記載した状態で受信する一括受信手段と、
該一括受信手段が受信した各ＳＯＡＰリクエストを、該各ＳＯＡＰリクエストに含まれる情報に従って宛先となるサービス手段に送信する個別送信手段との機能を付加するためのプログラム。
【請求項１２】
請求項７乃至１１のいずれか一項記載のプログラムを記録したコンピュータ読み取り可能な記録媒体。
【請求項１３】
ファイアウォールの内側の送信元から動作要求を通信要求に含めた状態で受信し、その送信元に対しその動作要求に対する応答である動作応答を通信応答に含めて送信する複数のサービス手段と、
ファイアウォールの外側の通信相手と前記複数のサービス手段との間の通信を仲介する仲介手段とを設け、
前記通信相手と当該通信装置との間で、前記複数のサービス手段の動作に係る動作要求及び動作応答を複数一括して送受信できるようにしたことを特徴とする通信装置。
【請求項１４】
請求項１３記載の通信装置であって、
前記仲介手段が、
前記各サービス手段から、前記通信相手からの動作要求に対する動作応答を受信する個別受信手段と、
該個別受信手段が受信した各動作応答を通信要求に含めて一括して前記通信相手に送信する一括送信手段と、
その通信要求に対する通信応答に含めた状態で、前記通信相手から、前記サービス手段に対する複数の動作要求を一括して受信する一括受信手段と、
該一括受信手段が受信した各動作要求を、該各動作要求に含まれる情報に従って宛先となるサービス手段に送信する個別送信手段とを有することを特徴とする通信装置。
【請求項１５】
請求項１４記載の通信装置であって、
前記仲介手段が送受信する動作要求及び動作応答がそれぞれ、形式を変更せずに複数結合して転送可能な１つのメッセージを生成することができる形式で表現され、また複数結合された状態では、形式を変更せずに分割して転送可能な個々の動作要求及び動作応答に戻すことができる形式で表現されていることを特徴とする通信装置。
【請求項１６】
請求項１４又は１５記載の通信装置であって、
前記一括送信手段が前記通信相手に対して定期的に通信要求を送信するようにしたことを特徴とする通信装置。
【請求項１７】
請求項１３記載の通信装置であって、
前記仲介手段が、
前記通信相手からの前記サービス手段宛ての動作要求と、該動作要求に対する動作応答とを記憶する記憶手段と、
前記動作応答を前記記憶手段から読み出す収集手段と、
前記通信相手に対して、前記収集手段が読み出した複数の動作応答を前記通信要求に含めて一括して送信する一括送信手段と、
その通信要求に対する通信応答に含めた状態で、前記通信相手から、複数の前記動作要求を一括して受信する一括受信手段と、
該一括受信手段が受信した各動作要求を、動作要求毎に分割して前記記憶手段に記憶させる分配手段と、
前記各サービス手段から、前記動作応答を受信すると共に、受信した動作応答を、その動作応答と対応する動作要求と関連付けて前記記憶手段に記憶させる個別受信手段と、
前記動作要求を前記記憶手段から読み出すと共に、読み出した各動作要求を、その動作要求に含まれる情報に従って宛先となるサービス手段に送信する個別送信手段とを有することを特徴とする通信装置。
【請求項１８】
請求項１３記載の通信装置であって、
前記通信要求及び通信応答はそれぞれＨＴＴＰリクエスト及びＨＴＴＰレスポンスであり、
前記動作要求及び動作応答はそれぞれＳＯＡＰリクエスト及びＳＯＡＰレスポンスであり、
前記仲介手段が、
前記各サービス手段から、前記通信相手からのＳＯＡＰリクエストに対するＳＯＡＰレスポンスを受信する個別受信手段と、
該個別受信手段が受信した各ＳＯＡＰレスポンスを１つのＨＴＴＰリクエストに記載して前記通信相手に送信する一括送信手段と、
そのＨＴＴＰリクエストに対するＨＴＴＰレスポンスとして、前記通信相手から、前記サービス手段宛ての複数のＳＯＡＰリクエストを１つのＨＴＴＰレスポンスに記載した状態で受信する一括受信手段と、
該一括受信手段が受信した各ＳＯＡＰリクエストを、該各ＳＯＡＰリクエストに含まれる情報に従って宛先となるサービス手段に送信する個別送信手段とを有することを特徴とする通信装置。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、動作要求を通信要求に含めた状態で受信し、その動作要求に対する応答である動作応答を通信応答に含めて送信するサービス手段を複数備えた通信装置に新たな通信機能を付加する通信機能付加方法、上記の通信装置に新たな通信機能を付加するためのプログラム、そのようなプログラムを記録した記録媒体、および上記の新たな通信機能を備えた通信装置に関する。
【背景技術】
【０００２】
従来から、種々の通信装置において、その通信装置が実行するアプリケーションプログラムにメソッドを用意し、外部装置からコマンドとしてメソッドに対する処理の依頼を受け付け、処理の結果を応答として返すようにすることが行われている。ここで、メソッドとは、入力と出力の形式を規定した論理的な関数として定義することができる。そしてこの場合、コマンドはこの関数を呼び出す関数呼び出し（Procedure Call）となり、応答はその関数呼び出しによって呼び出された関数の実行結果となる。
具体的には、このような機能は、例えば、コマンドをＳＯＡＰリクエストとしてＨＴＴＰリクエストに含めた状態で受信し、そのＳＯＡＰリクエストに対する応答であるＳＯＡＰレスポンスをＨＴＴＰレスポンスに含めて送信するサービス機能、例えばウェブサービスを提供する機能として実現することができる。
【０００３】
そして、パーソナルコンピュータ（ＰＣ）等のクライアントにおいてコマンドＳＯＡＰリクエストとして記載し、これをＨＴＴＰリクエストに含める形でその通信装置に送信し、そのコマンドの実行結果としてＳＯＡＰレスポンスをＨＴＴＰレスポンスに含めた形で受信することにより、サービス機能を利用できるようにすることも行われている。ここで、ＨＴＴＰは「HyperText Transfer Protocol」、ＳＯＡＰは「Simple Object Access Protocol」である。
【０００４】
そして、通信装置が上記のサービスを提供しようとする場合、サービスを利用する（ユーザが使用する）装置との間にファイアウォールがない場合、例えば、ＬＡＮ（ローカルエリアネットワーク）のようなユーザ環境内のネットワークを介した通信が可能である場合には大きな問題は発生しない。この場合、通常、任意の装置が任意の装置に対してＨＴＴＰリクエストのような通信要求の送信／受付が可能なネットワーク構成となっており、利用側の装置が提供側の装置に対して自由に通信要求を送信できるためである。
しかし、サービス利用側の装置が、ファイアウォールを越えてサービス提供側の装置と通信しようとする場合、例えばインターネットを介してＬＡＮ内の装置が提供するサービスを利用しようとする場合には問題があった。すなわち、ファイアウォールは通常は外部から内部へのアクセスを遮断するように設定されているため、サービス提供側の装置がファイアウォールの内側にあると、ファイアウォールの外側の装置からはサービス提供側の装置に通信要求に含めたコマンド（動作要求）を送信できない点が問題になっていた。
【０００５】
このような問題に対応するための技術としては、例えば特許文献１に記載の技術が知られており、この文献には、ローカルプロセッサがファイアウォールの内側に配置されている場合において、ローカルプロセッサからファイアウォールの外側のリモートプロセッサにＨＴＴＰリクエストを送信し、リモートプロセッサがこのＨＴＴＰリクエストに対する応答としてローカルプロセッサに対してコマンドを送信するようにすることにより、ファイアウォールの外側から内側に向けてコマンドを送信できるようにする技術が開示されている。
また、リバースプロキシとプロキシエージェントを利用し、リバーストンネリングによりファイアウォールの内側と外側でコマンドと応答の送受信を可能にする技術も開示されている。
【特許文献１】特開２００１−２７３２１１号公報
【０００６】
また、このようなコマンド送信に関する技術は、通信装置に接続された装置の動作を遠隔制御するシステムにも適用することができる。特許文献２には、ブラインド及び照明を操作する機能を有する遠隔被操作装置に、ユーザからの操作を受け付ける機能を有する遠隔操作装置からコマンドを送信してブラインド及び照明を操作させる遠隔操作システムにこのような技術を適用した例が記載されている。ただし、この文献には、コマンドに対する応答を送信する点は示されていない。
【特許文献２】特開２００２−１３５８５８号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
ところで、種々の装置が提供するサービスを設計する場合において、サービスをパッケージ化し、そのパッケージ毎にコマンドの受け口を設けるようにすることが行われている。そして、この場合の受け口として、例えばコマンドの送信先となるＵＲＬ（Uniform Resource Locator）が考えられる。
このような構成とした場合、サービス利用側の装置は、サービス提供側の装置において用意される適切なＵＲＬを指定してコマンドを送信する必要がある。しかし、ファイアウォールの外から中へ、ＵＲＬを指定して通信要求を送信することはさほど容易ではない。
【０００８】
例えば上記の各特許文献に記載のように、単にＨＴＴＰリクエストに対応するＨＴＴＰレスポンスにコマンドを記載して返すようにするとすると、そのＨＴＴＰリクエストの送信元ＵＲＬにしかコマンドを送信することができない。従って、サービス提供側の装置はＵＲＬ毎に利用側の装置にＨＴＴＰリクエストを送信する必要が生じ、通信トラフィックが増大してしまうという問題があった。また、コマンドの受け口となるＵＲＬ等における通信をこのようなプロトコルで制御するようにしてしまうと、ファイアウォール内部からのサービスの利用についても使用するプロトコルを同様なものに変更したり、要求元がファイアウォールの内部か外部かに応じて使用するプロトコルを切り換えたりする必要が生じ、システム構成の煩雑化につながるという問題もあった。
【０００９】
また、特許文献１には、リバースプロキシとプロキシエージェントによりリバーストンネリングを行い、ファイアウォールの外側のブラウザ等からの要求を、指示されたウェブサーバにディスパッチされる要求に変換する構成も記載されているが、このような動作を行うためには、ファイアウォールの外側にリパースプロキシが必要になり、コストアップにつながるという問題があった。
そこで、ファイアウォールの外側からでも、ファイアウォールの内側の装置によって提供される種々のサービスを、低コストで効率よく利用できるようにしたいという要求があった。また、既にＬＡＮ内でのサービスの利用が行われている環境にあっては、そのサービスの利用環境を維持したままこのような機能を実現したいという要求もあった。
【００１０】
一方、コマンドの受け口が複数ある場合、サービスの利用側の装置は、従来は、コマンドの送信を受け口毎に別々の通信要求に含めて行い、応答もその各通信要求に対応する別々の通信応答に記載した状態で受け取るようにしていた。従って、サービス提供側の装置との間にファイアウォールがない（又はファイアウォールを通して通信要求を送信できる）場合でも、コマンドの受け口の数が多いと、コマンド転送のために必要な通信要求の数が増え、コネクション確立等のためのオーバーヘッドが増加して通信効率が低下するという問題があった。
【００１１】
この発明は、これらの問題を解決し、ファイアウォールの内側の通信装置において、動作要求を通信要求に含めた状態で受信し、その動作要求に対する応答である動作応答を通信応答に含めて送信する複数のサービス手段によって提供されるサービスを、ファイアウォール内における利用環境を維持したまま、ファイアウォールの外側からでも低コストで効率よく利用できるようにすることを目的とする。さらに、ファイアウォールの有無に関わらず、サービスを利用する際の通信効率を改善することを目的とする。
【課題を解決するための手段】
【００１２】
上記の目的を達成するため、この発明の通信機能付加方法は、ファイアウォールの内側の送信元から動作要求を通信要求に含めた状態で受信し、その送信元に対しその動作要求に対する応答である動作応答を通信応答に含めて送信するサービス手段を複数備えた第２の通信装置に、ファイアウォールの外側の第１の通信装置と、上記複数のサービス手段との間の通信を仲介する仲介モジュールを付加することにより、上記第１の通信装置と上記第２の通信装置との間で、上記複数のサービス手段の動作に係る動作要求及び動作応答を複数一括して送受信できるようにしたものである。
【００１３】
このような通信機能付加方法において、上記仲介モジュールを、上記各サービス手段から、上記第１の通信装置からの動作要求に対する動作応答を受信する個別受信手段と、その個別受信手段が受信した各動作応答を通信要求に含めて一括して上記第１の通信装置に送信する一括送信手段と、その通信要求に対する通信応答に含めた状態で、上記第１の通信装置から、上記サービス手段に対する複数の動作要求を一括して受信する一括受信手段と、その一括受信手段が受信した各動作要求を、その各動作要求に含まれる情報に従って宛先となるサービス手段に送信する個別送信手段との機能を実現するためのモジュールとするとよい。
【００１４】
さらに、上記仲介モジュールが送受信する動作要求及び動作応答をそれぞれ、形式を変更せずに複数結合して転送可能な１つのメッセージを生成することができる形式で表現し、また複数結合された状態では、形式を変更せずに分割して転送可能な個々の動作要求及び動作応答に戻すことができる形式で表現するようにするとよい。
さらに、上記一括送信手段に、上記第１の通信装置に対して定期的に通信要求を送信する機能を設けるとよい。
【００１５】
また、上記の通信機能付加方法において、上記仲介モジュールを、上記第１の通信装置からの上記サービス手段宛ての動作要求と、その動作要求に対する動作応答とを記憶する記憶手段と、上記動作応答を上記記憶手段から読み出す収集手段と、上記第１の通信装置に対して、上記収集手段が読み出した複数の動作応答を上記通信要求に含めて一括して送信する一括送信手段と、その通信要求に対する通信応答に含めた状態で、上記第１の通信装置から、複数の上記動作要求を一括して受信する一括受信手段と、その一括受信手段が受信した各動作要求を、動作要求毎に分割して上記記憶手段に記憶させる分配手段と、上記各サービス手段から、上記動作応答を受信すると共に、受信した動作応答を、その動作応答と対応する動作要求と関連付けて上記記憶手段に記憶させる個別受信手段と、上記動作要求を上記記憶手段から読み出すと共に、読み出した各動作要求を、その動作要求に含まれる情報に従って宛先となるサービス手段に送信する個別送信手段との機能を実現するためのモジュールとするとよい。
【００１６】
あるいは、上記通信要求及び通信応答をそれぞれＨＴＴＰリクエスト及びＨＴＴＰレスポンスとし、上記動作要求及び動作応答をそれぞれＳＯＡＰリクエスト及びＳＯＡＰレスポンスとし、上記仲介モジュールを、上記各サービス手段から、上記第１の通信装置からのＳＯＡＰリクエストに対するＳＯＡＰレスポンスを受信する個別受信手段と、その個別受信手段が受信した各ＳＯＡＰレスポンスを１つのＨＴＴＰリクエストに記載して上記第１の通信装置に送信する一括送信手段と、そのＨＴＴＰリクエストに対するＨＴＴＰレスポンスとして、上記第１の通信装置から、上記サービス手段宛ての複数のＳＯＡＰリクエストを１つのＨＴＴＰレスポンスに記載した状態で受信する一括受信手段と、その一括受信手段が受信した各ＳＯＡＰリクエストを、その各ＳＯＡＰリクエストに含まれる情報に従って宛先となるサービス手段に送信する個別送信手段との機能を実現するためのモジュールとするとよい。
【００１７】
また、この発明のプログラムは、ファイアウォールの内側の送信元から動作要求を通信要求に含めた状態で受信し、その送信元に対しその動作要求に対する応答である動作応答を通信応答に含めて送信するサービス手段を複数備え、他の装置と通信可能な通信装置を制御するコンピュータに、上記各サービス手段から、ファイアウォールの外側の通信相手からの動作要求に対する動作応答を受信する個別受信手段と、その個別受信手段が受信した各動作応答を通信要求に含めて一括して上記通信相手に送信する一括送信手段と、その通信要求に対する通信応答に含めた状態で、上記通信相手から、上記サービス手段に対する複数の動作要求を一括して受信する一括受信手段と、その一括受信手段が受信した各動作要求を、その各動作要求に含まれる情報に従って宛先となるサービス手段に送信する個別送信手段との機能を付加するためのプログラムである。
【００１８】
このようなプログラムにおいて、動作要求及び動作応答をそれぞれ、形式を変更せずに複数結合して転送可能な１つのメッセージを生成することができる形式で表現し、また複数結合された状態では形式を変更せずに分割して転送可能な個々の動作要求及び動作応答に戻すことができる形式で表現するようにするとよい。
さらに、上記一括送信手段に、上記通信相手に対して定期的に通信要求を送信する機能を設けるとよい。
【００１９】
また、この発明は、ファイアウォールの内側の送信元から動作要求を通信要求に含めた状態で受信し、その送信元に対しその動作要求に対する応答である動作応答を通信応答に含めて送信するサービス手段を複数備え、他の装置と通信可能な通信装置を制御するコンピュータに、ファイアウォールの外側の通信相手からの上記サービス手段宛ての動作要求と、その動作要求に対する動作応答とを記憶する記憶手段と、上記動作応答を上記記憶手段から読み出す収集手段と、上記通信相手に対して、上記収集手段が読み出した複数の動作応答を上記通信要求に含めて一括して送信する一括送信手段と、その通信要求に対する通信応答に含めた状態で、上記通信相手から、複数の上記動作要求を一括して受信する一括受信手段と、その一括受信手段が受信した各動作要求を、動作要求毎に分割して上記記憶手段に記憶させる分配手段と、上記各サービス手段から、上記動作応答を受信すると共に、受信した動作応答を、その動作応答と対応する動作要求と関連付けて上記記憶手段に記憶させる個別受信手段と、上記動作要求を上記記憶手段から読み出すと共に、読み出した各動作要求を、その動作要求に含まれる情報に従って宛先となるサービス手段に送信する個別送信手段との機能を付加するためのプログラムも提供する。
【００２０】
さらに、この発明は、ファイアウォールの内側の送信元からＳＯＡＰリクエストをＨＴＴＰリクエストに記載した状態で受信し、その送信元に対しそのＳＯＡＰリクエストに対する応答であるＳＯＡＰレスポンスをＨＴＴＰレスポンスに記載して送信するサービス手段を複数備え、他の装置と通信可能な通信装置を制御するコンピュータに、上記各サービス手段から、ファイアウォールの外側の通信相手からのＳＯＡＰリクエストに対するＳＯＡＰレスポンスを受信する個別受信手段と、その個別受信手段が受信した各ＳＯＡＰレスポンスを１つのＨＴＴＰリクエストに記載して上記通信相手に送信する一括送信手段と、そのＨＴＴＰリクエストに対するＨＴＴＰレスポンスとして、上記通信相手から、上記サービス手段宛ての複数のＳＯＡＰリクエストを１つのＨＴＴＰレスポンスに記載した状態で受信する一括受信手段と、その一括受信手段が受信した各ＳＯＡＰリクエストを、その各ＳＯＡＰリクエストに含まれる情報に従って宛先となるサービス手段に送信する個別送信手段との機能を付加するためのプログラムも提供する。
【００２１】
また、この発明の記録媒体は、上記のいずれかのプログラムを記録したコンピュータ読み取り可能な記録媒体である。
【００２２】
また、この発明の通信装置は、ファイアウォールの内側の送信元から動作要求を通信要求に含めた状態で受信し、その送信元に対しその動作要求に対する応答である動作応答を通信応答に含めて送信する複数のサービス手段と、ファイアウォールの外側の通信相手と上記複数のサービス手段との間の通信を仲介する仲介手段とを設け、上記通信相手とその通信装置との間で、上記複数のサービス手段の動作に係る動作要求及び動作応答を複数一括して送受信できるようにした通信装置である。
【００２３】
このような通信装置において、上記仲介手段に、上記各サービス手段から、上記通信相手からの動作要求に対する動作応答を受信する個別受信手段と、その個別受信手段が受信した各動作応答を通信要求に含めて一括して上記通信相手に送信する一括送信手段と、その通信要求に対する通信応答に含めた状態で、上記通信相手から、上記サービス手段に対する複数の動作要求を一括して受信する一括受信手段と、その一括受信手段が受信した各動作要求を、その各動作要求に含まれる情報に従って宛先となるサービス手段に送信する個別送信手段とを設けるとよい。
【００２４】
さらに、上記仲介手段が送受信する動作要求及び動作応答をそれぞれ、形式を変更せずに複数結合して転送可能な１つのメッセージを生成することができる形式で表現し、また複数結合された状態では、形式を変更せずに分割して転送可能な個々の動作要求及び動作応答に戻すことができる形式で表現するとよい。
さらにまた、上記一括送信手段に上記通信相手に対して定期的に通信要求を送信するようにするとよい。
【００２５】
また、上記の通信装置において、上記仲介手段が、上記通信相手からの上記サービス手段宛ての動作要求と、その動作要求に対する動作応答とを記憶する記憶手段と、上記動作応答を上記記憶手段から読み出す収集手段と、上記通信相手に対して、上記収集手段が読み出した複数の動作応答を上記通信要求に含めて一括して送信する一括送信手段と、その通信要求に対する通信応答に含めた状態で、上記通信相手から、複数の上記動作要求を一括して受信する一括受信手段と、その一括受信手段が受信した各動作要求を、動作要求毎に分割して上記記憶手段に記憶させる分配手段と、上記各サービス手段から、上記動作応答を受信すると共に、受信した動作応答を、その動作応答と対応する動作要求と関連付けて上記記憶手段に記憶させる個別受信手段と、上記動作要求を上記記憶手段から読み出すと共に、読み出した各動作要求を、その動作要求に含まれる情報に従って宛先となるサービス手段に送信する個別送信手段とを設けるとよい。
【００２６】
あるいは、上記通信要求及び通信応答をそれぞれＨＴＴＰリクエスト及びＨＴＴＰレスポンスとし、上記動作要求及び動作応答をそれぞれＳＯＡＰリクエスト及びＳＯＡＰレスポンスとし、上記仲介手段に、上記各サービス手段から、上記通信相手からのＳＯＡＰリクエストに対するＳＯＡＰレスポンスを受信する個別受信手段と、その個別受信手段が受信した各ＳＯＡＰレスポンスを１つのＨＴＴＰリクエストに記載して上記通信相手に送信する一括送信手段と、そのＨＴＴＰリクエストに対するＨＴＴＰレスポンスとして、上記通信相手から、上記サービス手段宛ての複数のＳＯＡＰリクエストを１つのＨＴＴＰレスポンスに記載した状態で受信する一括受信手段と、その一括受信手段が受信した各ＳＯＡＰリクエストを、その各ＳＯＡＰリクエストに含まれる情報に従って宛先となるサービス手段に送信する個別送信手段とを設けるとよい。
【発明の効果】
【００２７】
以上のようなこの発明の通信機能付加方法及び通信装置によれば、ファイアウォールの内側の通信装置において、動作要求を通信要求に含めた状態で受信し、その動作要求に対する応答である動作応答を通信応答に含めて送信する複数のサービス手段によって提供されるサービスを、ファイアウォール内における利用環境を維持したまま、ファイアウォールの外側からでも低コストで効率よく利用できるようにすることができる。さらに、ファイアウォールの有無に関わらず、サービスを利用する際の通信効率を改善することができる。
また、この発明のプログラムによれば、通信装置を制御するコンピュータに新規な通信機能を付加し、同様な効果を得ることができる。この発明の記録媒体によれば、上記のプログラムを記憶していないコンピュータにそのプログラムを読み出させて実行させ、上記の効果を得ることができる。
【発明を実施するための最良の形態】
【００２８】
以下、この発明を実施するための最良の形態について、図面を参照して説明する。
〔実施形態：図１乃至図２０〕
まず図１に、この発明の通信機能付加方法の適用対象の例である通信装置を用いて構成した通信システムの構成例を示す。
図１に示すように、この通信システムは、第１の通信装置である外部装置２０１と、第２の通信装置であるサーバ装置１０１及び画像処理装置１０２とを備える。そして、このうちサーバ装置１０１及び画像処理装置１０２をユーザ側の設置環境に配置し、これらと外部装置２０１とがインターネット１００を介して通信可能な構成としている。
また、ユーザ側環境内にはＰＣ１０３も設け、サーバ装置１０１及び画像処理装置１０２とＬＡＮ（ローカルエリアネットワーク）１０５によって接続すると共に、そして、セキュリティ面を考慮し、ＬＡＮ１０５をファイアウォール１０４を介してインターネット１００に接続している。
【００２９】
また、このような通信システムにおいて、サーバ装置１０１及び画像処理装置１０２はそれぞれ、動作要求を通信要求に記載した状態で受信し、その動作要求に対する動作応答を通信応答に記載して送信する機能を備えている。そして、この機能により、動作要求に従った動作を行ってその結果を動作応答として返すサービス、例えばウェブサービスを、通信相手となる通信装置（及びそのユーザ）に提供することができる。図に「サービス提供側装置」と記載しているのは、このようなサービス提供機能を備えていることを示すものである。
そして、サービスを利用したい装置（図では「サービス利用側装置」と記載している）は、このような「動作要求」を送信し、この依頼された処理の結果である「動作応答」を取得することにより、サービスを利用することができる。なお、サービス提供側装置がサービス利用側装置を兼ねることもある。
【００３０】
なお、「動作要求」は、例えばサービス提供側装置が実行するアプリケーションプログラムのメソッドに対する処理の依頼に該当する。また、ここではメソッドを、入力と出力の形式を規定した論理的な関数として定義するものとする。そしてこの場合、動作要求はこの関数を呼び出す関数呼び出し（Procedure Call）となり、動作応答はその関数呼び出しによって呼び出された関数の実行結果となる。動作要求による要求の内容には、意味のある実行結果を伴わない通知も含まれる。そして、サービス利用側装置は、サービス提供側の装置に対して動作要求を送信することにより、ＲＰＣ（Remote Procedure Call）を行うことができる。
なお、ここではＲＰＣによる引数並びに戻り値の受け渡しのプロトコルとしてＳＯＡＰ（Simple Object Access Protocol）を採用し、上記の動作要求や動作応答は、ここではＳＯＡＰメッセージとして記載するようにしている。ただし、ＤＣＯＭ（Distributed Component Object Model）のような他のプロトコルを使用してもよい。
【００３１】
図２に、これらの動作要求と動作応答の関係を示す。なお、この図においてはファイアウォール１０４の存在は考慮していない。
この図に示すように、サービス利用側装置でサービス提供側装置が提供するサービスを利用する要求が発生した場合、サービス利用側装置が動作要求を生成してサービス提供側装置に送信し、これを受け取ったサービス提供側装置がその要求に対する動作応答を返すというモデルになる。
なお、以下の説明において、「動作要求」を「コマンド」と呼び、「動作応答」を「コマンドに対する応答」あるいは単に「応答」と呼ぶことにする。
【００３２】
そして、実際に動作要求や動作応答を転送するための通信プロトコルとしては、システムの構成に合わせて適当なものを採用することができ、例えばＨＴＴＰ（HyperText Transfer Protocol）やＳＭＴＰ（Simple Mail Transfer Protocol）を採用することができる。ここでは、通信プロトコルにＨＴＴＰを採用する場合の実施形態を示している。そして、この場合、サービス提供側の装置は、動作要求であるＳＯＡＰリクエストを通信要求であるＨＴＴＰリクエストに記載した状態で受信し、そのＳＯＡＰリクエストに対する動作応答であるＳＯＡＰレスポンスを通信応答であるＨＴＴＰレスポンスに記載して送信する機能を有すると言える。
【００３３】
ところで、ＨＴＴＰリクエストのような通信要求は、ファイアウォール１０４の内側にあるＰＣ１０３のようなサービス利用側装置からであれば、自由にサービス提供側装置に送信することができる。しかし、ファイアウォール１０４は通常は外部からの通信要求を遮断するよう設定されているため、外部装置２０１は、通信要求を送信するだけではファイアウォール１０４の内側のサービス提供側装置にコマンドを送信することができない。従って、外部装置２０１からファイアウォール１０４の内側のサービス提供側装置が提供するサービスを利用するためには、特殊なプロトコルを採用する必要がある。
【００３４】
そこで、この通信システムにおいては、既にサービス提供機能を有するサービス提供側のサーバ装置１０１や画像処理装置１０２のような通信装置に、ファイアウォール１０４の外部の装置と各サービス機能との間の通信を仲介する仲介モジュールを付加することができるようにしている。そして、仲介モジュールにより、サービス提供側の装置が、外部装置２０１のようなファイアウォール１０４の外側の装置からコマンドを受信し、そのコマンドに対する応答を返せるようにしている。
【００３５】
また、サービス提供側の装置に複数のサービス機能を設け、それらが異なるポートで動作要求を受信するような構成を採る場合でも、上記の仲介モジュールにより、各サービス機能の動作に係るコマンドやコマンド応答を一括して送受信できるようにしている。
なお、このような仲介モジュールを用いた通信を行う際には、その通信の通信相手となるサービス利用側の装置にも、このような通信を行う機能を設けたり組みこんだりしておくようにする。
【００３６】
次に、図３に、この仲介モジュールを用いたサービス提供側装置とサービス利用側装置との間の通信シーケンスの例を示す。なお、以後の説明おいては、特に断らない限り、サービス提供側装置がサーバ装置１０１であり、サービス利用側装置が外部装置２０１である場合について説明する。
サーバ装置１０１と外部装置２０１との間には、ファイアウォール１０４があるが、この図に示すように、サーバ装置１０１から通信要求としてＨＴＴＰリクエストを外部装置２０１に送信し、外部装置２０１からこの通信要求に対する通信応答としてＨＴＴＰレスポンスをサーバ装置１０１に返すという手順であれば、これらの装置間で通信を行うことができる。例えばサーバ装置１０１が送信したＨＴＴＰリクエストＸに対して外部装置２０１がＨＴＴＰレスポンスＸを返し、同じくＨＴＴＰリクエストＹに対してＨＴＴＰレスポンスＹを返すという具合である。そこで、仲介モジュールを用いた通信においては、常にこのように通信を行うようにしている。
【００３７】
そして、サーバ装置１０１が、ＨＴＴＰリクエストに、外部装置２０１からサーバ装置１０１に送信されてきたコマンドに対する応答を記載して送信し、外部装置２０１は、そのＨＴＴＰリクエストと対応するＨＴＴＰレスポンスに、サーバ装置１０１において提供されるサービスを利用するためのコマンドを記載して送信するようにしている。
従って、外部装置２０１からサーバ装置１０１に送信するコマンドは、任意のタイミングで送信することはできず、サーバ装置１０１からＨＴＴＰリクエストを受信した場合にのみ送信することができることになる。しかし、サーバ装置１０１が定期的にあるいは適当なタイミングで外部装置２０１にＨＴＴＰリクエストを送信するようにすれば、この点はあまり問題にならない。
【００３８】
なお、コマンドや応答は、それぞれ任意の数ずつ（０でもよい）１つのＨＴＴＰリクエストやＨＴＴＰレスポンスに記載することができ、１つのＨＴＴＰリクエスト又はＨＴＴＰレスポンスに記載した内容は、論理的に一括して転送する。これは、本来別々のＵＲＬにおいてコマンドを受け付けているサービス（それぞれサービスＭとサービスＮとする）に対するコマンドや、そのコマンドに対する応答であっても同様である。
そして、このように、宛先や送信元の異なるコマンドや応答を一括して転送することにより、必要な情報を転送するために必要なコネクションの回数を減らし、オーバーヘッドを低減して通信の効率化を図っている。
【００３９】
図４にサーバ装置と外部装置との間の別の通信シーケンスの例を示す。
説明のため、図３には極めて単純なシーケンス例を示したが、図４には、各ＨＴＴＰリクエストやＨＴＴＰレスポンスに記載するコマンドや応答の数が一定でない例を示している。
また、サーバ装置１０１がコマンドを受信した場合において、その次にＨＴＴＰリクエストを送信する際に、受信したコマンド全てに対する応答をそのＨＴＴＰリクエストに記載して送信する必要はない。この図に示すように、先に処理が完了したコマンドに対する応答を送信し（ＨＴＴＰリクエストＹ）、その後、残りの応答を送信するようにしてもよい（ＨＴＴＰリクエストＺ）。
【００４０】
ところで、各コマンド及び応答は、それぞれ独立して生成され、また処理に供されるべきものであるから、サーバ装置１０１と外部装置２０１との間で上記のような一括転送を行うためには、転送前にこれらのコマンドやコマンド応答を結合し、また転送後に分離する処理が必要となる。また、サーバ装置１０１においては、受信したコマンドを適当なサービス機能部に転送する処理も必要となる。次に、各装置のハードウェア構成と共に、このような処理を行うための機能構成及びその処理の手順について説明する。
【００４１】
まず、図５に、サーバ装置１０１及び外部装置２０１のハードウェア構成例を示す。これらの装置は、提供あるいは利用するサービスや、そのサービスを通して実現しようとする機能、あるいはサービス以外の面で備える機能等に応じて種々の構成を取り得るが、図５には、構成を極めて単純化した例を示している。
この図に示すように、サーバ装置１０１及び外部装置２０１はそれぞれ、ＣＰＵ１１、ＲＯＭ１２、ＲＡＭ１３、不揮発メモリ１４、ネットワークインタフェース（Ｉ／Ｆ）１５を備え、これらがシステムバス１６で接続されている。
【００４２】
これら構成要素を更に具体的に説明すると、まずＣＰＵ１１は、ＲＯＭ１２や不揮発メモリ１４に格納している制御プログラムによってサーバ装置１０１又は外部装置２０１全体を統括的に制御する制御手段である。そして、ＲＯＭ１２は、ＣＰＵ１１が使用する制御プログラムを含む各種固定データを格納している読み出し専用メモリである。
ＲＡＭ１３は、ＣＰＵ１１がデータ処理を行う際のワークメモリ等として使用する一時記憶用メモリである。不揮発メモリ１４は、装置の電源がオフになっても記憶内容を保持するようになっている不揮発性メモリであり、例えばＳＤ（Secure Digital）カードによって構成できる。図３及び図４を用いて説明したような通信機能を実現するためのプログラムは、付加的なプログラムとしてこの不揮発メモリ１４に記憶させることが考えられる。
ネットワークＩ／Ｆ１５は、インターネット１００やＬＡＮ１０５を始めとする各種ネットワークを介して通信相手と情報の送受信を行うための通信手段であり、例えばＮＩＣ（ネットワークインタフェースカード）を用いて構成することができる。
【００４３】
次に、図６に、サーバ装置１０１の機能のうち、コマンド及びコマンド応答の送受信及びサービスの提供に関する処理を行うための機能の構成を示す機能ブロック図を示す。図６に示す各機能は、ＣＰＵ１１が所要の制御プログラムを実行してサーバ装置１０１の各部の動作を制御することにより実現されるものである。
図６に示す通り、サーバ装置１０１において、外部装置２０１との間でのコマンド及び応答の送受信に関する機能は、仲介機能部１１０が担う。そして、サービスの提供に関する機能は、ウェブサービス機能部１２０が担う。そして、ウェブサービス機能部１２０は単独でも直接コマンドを受信して応答を返す機能を有し、仲介機能部１１０の機能は、ウェブサービス機能部１２０の機能を有するサーバ装置１０１に、仲介モジュール（ソフトウェアモジュールの場合もハードウェアモジュールの場合もある）によって付加される機能である。
【００４４】
そして、仲介機能部１１０のうち、コマンドプール１１３の機能は、いずれかの書き換え可能な記憶手段に設けられるものである。例えば不揮発メモリ１４に設けることができるが、ＲＡＭ１３や図示しないＨＤＤ（ハードディスクドライブ）に設けてもよい。受信メッセージ分配機能部１１２、コマンド転送ハンドラ１１４、送信メッセージ収集機能部１１５の機能は、ＣＰＵ１１によって実現されるものである。また、ＨＴＴＰリクエスト送信機能部１１１及びＨＴＴＰレスポンス受信機能部１１６の機能は、ＣＰＵ１１及びネットワークＩ／Ｆ１５によって実現されるものである。
【００４５】
これらの機能についてさらに詳述する。
まず、ＨＴＴＰリクエスト送信機能部１１１は、送信メッセージ収集機能部１１５が生成した送信メッセージを記載したＨＴＴＰリクエストを生成し、外部装置２０１に送信する機能を有する（Ａ２，Ａ３）。また、コマンド転送ハンドラ１１４から渡されるメッセージ、すなわちウェブサービス機能部１２０に転送すべき各種ＳＯＡＰリクエストを、ＨＴＴＰリクエストに記載してウェブサービス機能部１２０に送信する機能も有する（Ｂ１，Ｂ２）。これらの送信機能については、後に詳述する。
【００４６】
また、ＨＴＴＰレスポンス受信機能部１１６は、外部装置２０１が送信してくるＨＴＴＰレスポンスを受信し、受信メッセージ分配機能部１１２に渡す機能を有する（Ａ４，Ａ５）。また、ウェブサービス機能部１２０が送信してくるＨＴＴＰレスポンスを受信し、コマンド転送ハンドラ１１４に渡す機能も有する（Ｂ８，Ｂ９）。これらは、例えばＨＴＴＰレスポンスの送信元によって識別することができる。
【００４７】
受信メッセージ分配機能部１１２は、分配手段に該当し、ＨＴＴＰレスポンス受信機能部１１６が受信したＨＴＴＰレスポンスに含まれるデータを、コマンドプール１１３にコマンドシートを設けて登録する機能を有する（Ａ６）。
そして、コマンドプール１１３は、外部装置２０１から受信したコマンドを、これらのコマンドに対する応答や、このコマンドの識別情報等と関連付けて登録するプールである。
【００４８】
ここで、図７にサーバ装置１０１のコマンドシートにおけるデータ構造の例を示す。
この図に示すように、サーバ装置１０１においては、コマンドシートには、「コマンドＩＤ」、「メソッド名」、「入力パラメータ」、「状態」、「出力パラメータ」、および「コマンドの通知先」のデータを記憶する領域を設けている。そして、このうち「コマンドＩＤ」、「メソッド名」、および「入力パラメータ」がコマンド（及びそこに付されたＩＤ）に該当し、「状態」及び「コマンドの通知先」が管理情報に該当する。「出力パラメータ」は、コマンドに応じてウェブサービス機能部１２０のサービス提供部１２３が生成する応答の内容である。この他に、シートのプロパティを記録できるようにしてもよい。
【００４９】
各項目の内容について説明する。
まず、「メソッド名」は、サーバ装置１０１に対するリクエストの内容であり、サーバ装置１０１のウェブサービス機能部１２０において呼び出す関数（メソッド）の種類を示す。「入力パラメータ」には、ここではウェブサービス機能部１２０に転送するコマンドのＳＯＡＰエンベロープ全体あるいはＳＯＡＰボディを、ＸＭＬ（Extensible Markup Language）文字列のまま登録する。仲介機能部１１０ではコマンドを実行しないため、その詳細を解析する必要がないからである。
「コマンドＩＤ」は、コマンドを識別するための識別情報である。
「状態」は、コマンドに関する処理の進行状況を示すデータであり、処理の進行と共に、「未処理」→「処理完了」→「応答済」もしくは、「未処理」→「処理中」→「処理完了」→「応答済」と遷移していく。
【００５０】
「出力パラメータ」には、コマンドに対する応答を受け取った段階で、その内容を格納する。ここでは、ＳＯＡＰレスポンスに係るＳＯＡＰエンベロープ全体をＸＭＬ文字列として格納するようにしている。なお、ウェブサービス機能部１２０からの応答を受け取るまでは空である。
「コマンドの通知先」は、そのシートに記載しているコマンドを取り扱うためのモジュールを示す参照情報である。しかし、ここではコマンドプール１１３に登録した全てのコマンドをコマンド転送ハンドラ１１４によってウェブサービス機能部１２０に転送するので、全てのコマンドシートについてコマンド転送ハンドラ１１４の参照情報が記載される。従って、これは省略可能な情報といえる。
【００５１】
図６の説明に戻ると、コマンド転送ハンドラ１１４は、ウェブサービス機能部１２０に転送すべきコマンドを、コマンドＩＤ及びメソッド名と関連付けてコマンドプール１１３から読み出し（Ｂ１）、これらから送信メッセージを生成し、ＨＴＴＰリクエスト送信機能部１１１に渡してウェブサービス機能部に送信させる機能を有する（Ｂ２）。なお、コマンドに転送優先順位が指定されている場合には、コマンド転送ハンドラ１１４が転送優先順位の高いものから順に読み出すようにすることが考えられる。
【００５２】
また、送信メッセージとは、上記のコマンドとコマンドＩＤとを、構造化言語であるＸＭＬで、ＳＯＡＰメッセージとして記載したものである。そして、コマンド転送ハンドラ１１４は、１つのコマンドにつき、送信メッセージとして１つのＳＯＡＰメッセージを生成する。またこのとき、各コマンドのコマンドＩＤはＳＯＡＰヘッダに記載し、コマンドの内容は、ＳＯＡＰボディに記載する。ＳＯＡＰによる通信では、ＳＯＡＰヘッダとＳＯＡＰボディとからなるＳＯＡＰエンベロープ（封筒）と呼ばれるメッセージをＸＭＬで記載し、ＨＴＴＰなどのプロトコルで交換することになる。
このようなコマンドからのＳＯＡＰメッセージの生成は、ＷＳＤＬ（Web Service Description Language）に基づいて生成される所要の変換プログラム（シリアライザ）を実行し、データを直列化することによって行うことができる。なお、コマンドシートにＸＭＬ文字列がそのまま登録されている部分については、シリアライザは不要である。
【００５３】
また、コマンド転送ハンドラ１１４は、ＨＴＴＰレスポンス受信機能部１１６を介してウェブサービス機能部１２０からの応答を受け取り（Ｂ９）、これをコマンドプール１１３に記憶している適当なコマンドシートに登録する機能も有する（Ｂ１０）。
具体的には、ウェブサービス機能部１２０から受信したＨＴＴＰレスポンスに含まれる応答を、対応するコマンドについての「出力パラメータ」として登録する。その際、そのコマンドと関連付けられたコマンドＩＤをコマンドプール１１３に記憶しているコマンドシートのコマンドＩＤと照合して対応するコマンドを特定することができる。
そしてこのとき、ＨＴＴＰレスポンスに含まれる受信メッセージ（ＳＯＡＰレスポンス）を取り出し、そのデータをテーブルへの登録に必要な形式に変換するが、この変換は、ＷＳＤＬに基づいて生成される所要の変換プログラム（デシリアライザ）を実行することによって行うことができる。なお、ここでは応答はそのまま外部装置２０１に転送すればよいので、ＸＭＬ文字列をそのまま出力パラメータとして登録すればよく、このようにする場合にはデシリアライザによる処理を省略することができる。
【００５４】
また、送信メッセージ収集機能部１１５は、収集手段に該当し、外部装置２０１に送信すべき応答を、コマンドＩＤと関連付けてコマンドプール１１３から読み出し（Ａ１）、これらから送信メッセージを生成する機能を有する。また、生成した送信メッセージをＨＴＴＰリクエスト送信機能部１１１に渡し、外部装置２０１に送信させる機能も有する（Ａ２）。なお、応答に送信優先順位が指定されている場合には、送信メッセージ収集機能部１１５が送信優先順位の高いものから順に読み出すようにすることが考えられる。
【００５５】
そして、ＨＴＴＰリクエスト送信機能部１１１は、送信メッセージ収集機能部１１５が生成した送信メッセージを記載したＨＴＴＰリクエストを生成し、外部装置２０１に送信するが、このとき、１つのＨＴＴＰリクエストに送信メッセージをいくつ含めてもよい。もちろん、異なるＵＲＬに転送したコマンドに対する応答に係る送信メッセージを混在させてもよい。
そこで、ＨＴＴＰリクエスト送信機能部１１１は、応答に係るコマンドの種類に関わり無く、送信メッセージ収集機能部１１５が生成した全ての送信メッセージを１つのＨＴＴＰリクエストに含めて送信するようにしている。ただし、１つのＨＴＴＰリクエストに含める送信メッセージの数に上限を設けることも考えられる。
【００５６】
ところで、このＨＴＴＰリクエストの送信は、送信メッセージ収集機能部１１５が応答の読み出しを試みた場合には、読み出すデータがなく、結果的に送信すべきＳＯＡＰメッセージを生成しなかった場合にも行うものである。そして、この読み出しの試みは、定期的に行うものとする。例えば、タイマによって６０分毎に読み出すことが考えられる。
このようにするのは、上述のように、外部装置２０１からサーバ装置１０１に送信したい情報があったとしてもサーバ装置１０１から通信を要求しない限り送信できないためである。サーバ装置１０１から何も送信するデータがなかったとしても、定期的に外部装置２０１に対して通信要求を送信して、外部装置２０１からサーバ装置１０１に情報を送信する機会を与えることにより、転送の必要な情報が長期間に亘って外部装置２０１に滞留してしまうことを防止できる。
【００５７】
なお、送信メッセージ収集機能部１１５による読み出しと、それに続くＨＴＴＰリクエスト送信機能部１１１によるＨＴＴＰリクエストの送信とを、定期的なタイミング以外に適宜行ってよいことはもちろんである。例えば、緊急に送信が必要な情報がコマンドプール１１３に登録された場合に、コマンド転送ハンドラ１１４が送信メッセージ収集機能部１１５にその旨を通知して読み出しを行わせるようにしてもよい。
以上のような仲介機能部１１０により、外部装置２０１とサーバ装置１０１との間で、ウェブサービス機能部１２０の動作に係るコマンド及び応答を複数一括して送受信できるようにすることができる。
【００５８】
一方、ウェブサービス機能部１２０については、ＨＴＴＰリクエスト受信機能部１２１及びＨＴＴＰレスポンス送信機能部１２６の機能は、ＣＰＵ１１及びネットワークＩ／Ｆ１５によって実現されるものである。また、ウェブサービスライブラリ１２２及び各サービス提供部１２３の機能は、ＣＰＵ１１によって実現されるものである。
そして、ＨＴＴＰリクエスト受信機能部１２１は、ＨＴＴＰリクエスト送信機能部１１１が送信してくるＨＴＴＰリクエストを受信し、ウェブサービスライブラリ１２２に渡す機能を有する（Ｂ３，Ｂ４）。また、他の装置が送信してくるＨＴＴＰリクエストもこれと同様に受信し、ウェブサービスライブラリ１２２に渡す機能を有する。
【００５９】
ウェブサービスライブラリ１２２は、ＨＴＴＰリクエストの送信先となっているＵＲＬの情報を取得し、その中のポート番号やＵＲＬパスの情報に従って、ＳＯＡＰリクエストを、そこに記載されたコマンドを実行すべきサービス提供部１２３に渡す機能を有する（Ｂ５）。この際、ＳＯＡＰリクエストの内容を解析し、サービス提供部１２３が認識できる形式のデータに変換する機能を設けてもよい。
また、ウェブサービスライブラリ１２２は、サービス提供部１２３から返されたコマンド実行結果のＳＯＡＰレスポンスをＨＴＴＰレスポンス送信機能部１２６に渡し、コマンドに対する応答としてＨＴＴＰリクエストの送信元に返信させる機能も有する（Ｂ７）。上記と同様、サービス提供部１２３から返されたデータからＳＯＡＰレスポンスを生成する機能を設けてもよい。
【００６０】
サービス提供部１２３は、ＲＰＣによって呼び出される関数に該当し、ウェブサービス機能部１２０中に複数設けられる。そして、ウェブサービスライブラリ１２２から受け取ったＳＯＡＰリクエストの内容を解析してコマンドを取得し、そのコマンドに係る動作を実行して実行結果を生成し、その実行結果を記載したＳＯＡＰレスポンスを生成してウェブサービスライブラリ１２２に返す機能を有する（Ｂ５，Ｂ６）。ウェブサービスライブラリ１２２がＳＯＡＰリクエストの解析を行う場合には、サービス提供部１２３にはその機能を設けなくてもよい。
また、サービス提供部１２３は、１又は複数のコマンドに対応して設けられるが、自身でコマンドに係る処理を実行するほか、他のサービス提供部や、さらには他の装置にコマンドに係る処理を実行させる機能を有していてもよい。また、ＳＯＡＰリクエストが記載されていたＨＴＴＰリクエストの送信先の情報を取得し、同じコマンドを受け取った場合でも、ＨＴＴＰリクエストを受信したポート番号やＵＲＬパスに応じて異なる動作結果を返すようにしてもよい。
【００６１】
ＨＴＴＰレスポンス送信機能部１２６は、ウェブサービスライブラリ１２２から受け取ったＳＯＡＰレスポンスを記載したＨＴＴＰレスポンスを生成し、対応するＨＴＴＰリクエストの送信元に送信する機能を有する（Ｂ７，Ｂ８）。すなわち、仲介機能部１１０から転送されてきたコマンドに対する応答は仲介機能部１１０に返し、ウェブサービス機能部１２０が他の装置から直接受信したコマンドに対する応答は、その送信元の装置に返すことになる。
【００６２】
以上のようなウェブサービス機能部１２０により、コマンドをＨＴＴＰリクエストに記載した状態で受信し、そのコマンドに応じた動作を行った結果である応答をＨＴＴＰレスポンスに記載してコマンドの送信元に返信するサービスを提供することができる。そして、このようなサービスは、コマンドが、外部装置２０１のようなファイアウォールの外側の送信元によって発行され、仲介機能部１１０から転送されてきたものであっても（Ｂ３，Ｂ８）、ＰＣ１０３のようなファイアウォールの内側の送信元からウェブサービス機能部１２０が直接受信したものであっても（Ｎ１，Ｎ２）、同様に提供することができる。
【００６３】
また、コマンドを記載したＨＴＴＰリクエストを、特定のポートやＵＲＬパスでのみ受け付けるようにすると、不適切なポートやＵＲＬパスに送信されてきたコマンドを、ウェブサービスライブラリ１２２の段階でエラーと認識することができたり、ウェブサービスの利用以外の用途で送られてくるＨＴＴＰリクエストと容易に区別できたりするので、処理効率が向上する。そこで、ここではこのような構成を採用している。
また、特定の機能単位、例えばユーザ管理や文書管理といった単位毎にコマンドを受け付けるポートやＵＲＬパスを定めると、ウェブサービスライブラリ１２２におけるコマンドの各サービス提供部１２３への分配規則を大きく変更することなく、サービス提供部の追加や構成変更が可能になる。そこで、ここではこのような構成を採用しており、この場合、ウェブサービス機能部１２０には上記の機能単位毎にサービス手段があると考えることができる。
【００６４】
次に、図８に、このような機能を有するサーバ装置１０１が外部装置２０１に送信するＨＴＴＰリクエストの例を示す。
このＨＴＴＰリクエストは、図８に示すように、ボディ部としてＭＩＭＥ（Multipurpose Internet Mail Extension）に従ったマルチパートのメッセージが記載され、この各パートには、それぞれエンティティヘッダが記載されると共に、詳細な図示は省略しているが、ＳＯＡＰエンベロープが埋め込まれている。図８の例では、ＨＴＴＰリクエストのＨＴＴＰボディには、「MIME_boundary」で区分された各要素が、独立した第１パート、第２パート、第３パート、第４パートを構成しているが、ＨＴＴＰボディに含めることのできるパート数は４つに限られない。０個を含め、いくつでもよい。
そして、ここでＨＴＴＰリクエストに埋め込まれて引き渡されるＳＯＡＰエンベロープは、外部装置２０１から受信してウェブサービス機能部１２０に転送したコマンドに対する応答を記載したＳＯＡＰレスポンスである。
【００６５】
また、図９に、このような機能を有するサーバ装置１０１が外部装置２０１から受信するＨＴＴＰレスポンスの例を示す。
図９に示すように、このＨＴＴＰレスポンスは、形式としては図８に示したＨＴＴＰリクエストとＨＴＴＰヘッダ部が異なるのみであり、ボディ部にはＨＴＴＰリクエストの場合と同様に、詳細な図示は省略しているが、ＭＩＭＥに従ったマルチパートのＳＯＡＰエンベロープが記載される。ただし、ＨＴＴＰレスポンスに埋め込まれて引き渡されるＳＯＡＰエンベロープに記載されているのが、外部装置２０１から送信されてくるコマンドに係るＳＯＡＰリクエストである点は、図８の場合と異なる。
【００６６】
そして、以上のような形式のＨＴＴＰリクエストやＨＴＴＰレスポンスは、転送可能な１つのメッセージであり、各パートのＳＯＡＰエンベロープを、形式を変更せずに複数結合して生成することができる。また、このような形式のＨＴＴＰリクエストやＨＴＴＰレスポンスを分割して各パートのＳＯＡＰエンベロープを取り出せば、各ＳＯＡＰエンベロープ毎に個別に別のＨＴＴＰリクエストやＨＴＴＰレスポンスに記載して転送することができる。
【００６７】
次に、これらのＨＴＴＰリクエスト又はＨＴＴＰレスポンスに記載されるパートの具体例を図１０及び図１１に示す。
図１０に示すのは、ウェブサービス機能部１２０に対するコマンドを記載したパートの例である。
この例においては、まず、エンティティヘッダの部分の「X-SOAP-Type」ヘッダに、このパートに記載されているＳＯＡＰメッセージがＳＯＡＰリクエストであるかＳＯＡＰレスポンスであるかを示す情報を記載している。この例では、値の「Request」により、ＳＯＡＰリクエストであること、すなわちコマンドを記載したＳＯＡＰメッセージであることを示している。
【００６８】
また、「SOAPAction」ヘッダは、ＳＯＡＰリクエストの内容を示すものであり、この例では、「http://www.…」というＵＲＩ（Uniform Resource Identifier）によりリクエストの内容を示している。なお、「SOAPAction」ヘッダは、ＳＯＡＰメッセージがＳＯＡＰレスポンスである場合には付加しないため、メッセージの受信側において、このヘッダの有無により、ＳＯＡＰメッセージがＳＯＡＰリクエストであるかＳＯＡＰレスポンスであるかを判断することもできる。
【００６９】
そして、「Envelope」タグの属性として、名前空間の宣言を行っている。そしてここでは、ＳＯＡＰで標準として定義されている名前空間の他に、「http://www.example.com/header」及び「http://www.example.com/useradmin」のＵＲＩで特定される名前空間の宣言を行っている。従って、「ｎ」の名前空間接頭辞が付されたＸＭＬタグについては「http://www.example.com/header」のＵＲＩで特定される名前空間に属するタグであることがわかり、「ｎｃ」の名前空間接頭辞が付されたＸＭＬタグについては「http://www.example.com/useradmin」のＵＲＩで特定される名前空間に属するタグであることがわかる。
【００７０】
またＳＯＡＰヘッダには、「要求ＩＤ」のＸＭＬタグの内容として、このコマンドのＩＤである「９８７６５」が記載されている。
なお、図１に示した通信システムでは、仲介機能部１１０を通してウェブサービス機能部１２０にコマンドを送信する装置は外部装置２０１の１つしかないので、ウェブサービス機能部１２０側では仲介機能部１１０から受信したコマンドは全て外部装置２０１からのものであることがわかる。また、ウェブサービス機能部１２０が直接受信するコマンドについては、ＨＴＴＰリクエストの送信元がコマンドの送信元であるとわかる。従って、ＳＯＡＰリクエストにコマンドの発信元の情報を記載する必要はなく、ここでは記載していない。しかし、外部装置２０１の装置が複数ある場合には、ＳＯＡＰヘッダに、コマンドの送信元の情報として送信元装置のＩＤ等を記載するようにするとよい。
【００７１】
また、ＳＯＡＰボディには、ウェブサービス機能部１２０のサービス提供部１２３に実行させるメソッドを指定する情報として、「ユーザ登録」タグが記載され、その下位のタグ「ユーザ名」や「パスワード」の要素として、メソッドに引数として引き渡すパラメータが記載されている。ここでは登録するユーザの名前とそのユーザが使用するパスワードが記載されている。
【００７２】
図１１に示すのは、コマンドに対する応答を記載したパートの例である。
この例においては、まず、エンティティヘッダの部分の「X-SOAP-Type」ヘッダの値を「Response」と記載することにより、このパートに記載されているＳＯＡＰメッセージがＳＯＡＰレスポンスであること、すなわち応答を記載したＳＯＡＰメッセージであることを示している。
また、この例においても、名前空間の宣言は図１０に示した例と同様である。そして、ＳＯＡＰヘッダには、「コマンドＩＤ」のＸＭＬタグの内容として、応答を生成したコマンドのＩＤである「９８７６５」が記述されている。
なおここでは、ＳＯＡＰリクエストにおける送信元と同様な理由で、応答の宛先を記載していないが、記載するようにしてもよいことも同様である。
また、ＳＯＡＰボディには、「ユーザ登録」コマンドに対する応答であることを示すための「ユーザ登録Response」タグが設けられ、その下位のタグに、応答の内容が記載される。ここでは、ユーザ登録が成功した旨の情報が記載されている。
【００７３】
次に、以上説明したような構成及び機能を有するサーバ装置１０１において実行する処理について、図１２乃至図１７を用いて説明する。これらの図のうち、図１２，図１４，図１６，図１７のフローチャートに示す処理は、サーバ装置１０１のＣＰＵ１１が所要の制御プログラムを実行することによって行うものである。
【００７４】
まず、図１２にメッセージの収集及び分配処理の基本動作のフローチャートを示す。
サーバ装置１０１のＣＰＵ１１は、送信メッセージ収集機能部１１５がコマンドプール１１３から応答の読み出しを試みるタイミングになると、図１２のフローチャートに示す処理を開始する。
そして、この処理においては、サーバ装置１０１のＣＰＵ１１はまず、ステップＳ１１で、コマンドプール１１３から、「状態」が「処理完了」であるコマンドを、応答の内容を外部装置２０１に送信すべきものとして収集し、「コマンドＩＤ」の内容も、対応するコマンドのコマンドＩＤとして収集する。「処理完了」という「状態」は、コマンドに対応する処理がウェブサービス機能部１２０によって実行され、応答がコマンドシートに登録された後、まだ外部装置２０１に通知されていないことを示すものであるので、これを基準に外部装置２０１に送信すべき内容を含むシートを抽出できる。
【００７５】
その後、ステップＳ１１で収集した全てのコマンドを順次対象として、ステップＳ１２乃至Ｓ１４の処理を繰り返す。
これらの処理においては、まずステップＳ１２で、対象のコマンドのコマンドシートから、「出力パラメータ」の項目に登録されているＸＭＬ文字列を、外部装置２０１に送信すべき応答の内容として取得する。ここで、「出力パラメータ」の項目には、ウェブサービス機能部１２０が仲介機能部１１０に返した応答のＳＯＡＰレスポンスを、ＳＯＡＰエンベロープのまま登録してあるものとする。
そして、ステップＳ１３で、ステップＳ１２で取得したＸＭＬ文字列に係るＳＯＡＰエンベロープにエンティティヘッダを付して、対象のコマンドに対する応答に関するパートを作成する。その後、ステップＳ１４で、対象のコマンドについてのコマンドシートの「状態」を「応答済」に変更する。「応答済」という「状態」は、コマンド応答を外部装置２０１に通知済であることを示すものである。
【００７６】
そして、ここまでの処理がステップＳ１１で収集した全てのコマンドについて完了した後、ステップＳ１５で、ステップＳ１３で生成した各パートをマージし、図８に示したようなマルチパートのＨＴＴＰリクエストを生成して外部装置に送信する。この処理において、ＣＰＵ１１は一括送信手段として機能する。
なお、ステップＳ１４で行った「状態」の変更は、実際にこの送信が終了してから行うようにしてもよい。このようにすることにより、通信エラーが発生しても、送信しようとしていたコマンド及びコマンド応答を再度送信の対象とすることができるので、システムの信頼性が向上する。
以上でＨＴＴＰリクエストの送信に関する処理を終了し、ステップＳ１６以降の処理に進む。
【００７７】
そして、ステップＳ１６では、ＣＰＵ１１は、送信したＨＴＴＰリクエストに対するＨＴＴＰレスポンスの受信を待ち、外部装置２０１からこれを受信する。ここで受信するＨＴＴＰリクエストは、図９に示したように、マルチパートで任意の数（０の場合もありうる）のコマンドに係るＳＯＡＰリクエストが記載されたものであり、この処理においてはＣＰＵ１１が一括受信手段として機能する。
そして、ステップＳ１６でＨＴＴＰレスポンスを受信すると、ステップＳ１７でそのＨＴＴＰボディを解析して各パートに分割する。そしてその後、分割して得た各パートを順次対象として、ステップＳ１８及びステップＳ１９の処理を繰り返す。
【００７８】
この部分の処理においては、まずステップＳ１８で、対象のパートのＳＯＡＰボディを解析して、対象パートに記載されたコマンドによって呼び出すメソッド名及びその名前空間ＵＲＩを取得する。なお、コマンドに係る名前空間ＵＲＩとメソッド名は、ＳＯＡＰボディを示す「Body」要素の子要素の属する名前空間と要素のローカル名であり、「Body」要素の子要素のタグに記載されている。例えば図１０に示したＳＯＡＰリクエストの例では、「ｎｃ：ユーザ登録」である。そして、名前空間接頭辞「ｎｃ」から、「Envelope」タグの属性における名前空間ＵＲＩの定義を参照すると、コマンドに係る名前空間ＵＲＩは「http://www.example.com/useradmin」であることがわかる。また、「：」の後側の部分は、そのままメソッド名である。
ステップＳ１８の後は、ステップＳ１９に進み、図７に示したようなコマンドシートを作成して対象パートのコマンドをコマンドプール１１３に登録する。
【００７９】
ここで、図１３に、このコマンドをコマンドシートに登録する場合の、各項目に記載すべきデータの取得先を示す。
この図に示すように、「コマンドＩＤ」は、ＳＯＡＰリクエストのＳＯＡＰヘッダから抽出する。図１０に示した例では、コマンドＩＤは「コマンドＩＤ」タグの要素として記載されている。
また、「メソッド名」には、ステップＳ１８でＳＯＡＰボディから抽出したメソッド名及び名前空間ＵＲＩを登録する。そして、「入力パラメータ」としては、ＳＯＡＰリクエストに係るＳＯＡＰエンベロープのＸＭＬ文字列をそのまま登録する。この場合において、上記のコマンドＩＤやメソッド名以外の部分の内容を解釈する必要はない。また、ＳＯＡＰボディのみを登録するようにしてもよい。
【００８０】
そして、「状態」には初期値として「未処理」を登録し、「コマンドの通知先」には、コマンド転送ハンドラ１１４を登録する。「出力パラメータ」の初期値が空であることは、図７の説明において述べた通りである。
ここで登録されたコマンドは、後述するように、コマンド転送ハンドラ１１４の機能によりウェブサービス機能部１２０の適当なＵＲＬに転送される。
【００８１】
そして、ここまでの処理がステップＳ１７の分割で得た全てのパートについて完了すると、このフローチャートの処理を終了する。
以上の処理を行うことにより、サーバ装置１０１が、ウェブサービス機能部１２０における複数のサービス手段が生成した応答を一括して外部装置２０１に送信することができる。また、外部装置２０１からの複数のサービス手段に対するコマンドを一括して受信し、ウェブサービス機能部１２０の適当なＵＲＬに転送できる状態にすることができる。
【００８２】
なお、ここでは送信すべきパートを全て生成してからマージして送信を行うようにし、また全てのパートを受信してからこれを各パートに分割して処理を行うように説明したが、このようにする必要はない。
送信については、まず始めにＨＴＴＰヘッダを送信し、以後パートを生成するたびにそのパートを順次送信し、全てのパートの送信が完了した時点でその旨のデータを送信するようにしてもよい。このようにしても、これらの課程で送信されるデータが１つのみのＨＴＴＰヘッダを持つ論理的に連続した１つのＨＴＴＰリクエストであれば、１回のセッションで転送でき、ネゴシエーションの処理は１回で済むので、マージして送信する場合と同様な効果を得ることができる。また、送信すべきデータのバッファに必要なメモリ容量を低減できるので、低コストの通信装置で大きなデータを取り扱うことができる。
また、受信側でも、各パートに関する処理を、各パートを受信するたびに順次行うようにすることができる。このようにした場合に容量を低減できることは、送信側の場合と同様である。
【００８３】
次に、図１４に、コマンド転送ハンドラ１１４によるコマンド転送処理の一例のフローチャートを示す。
コマンド転送処理としては、まず、図１４のフローチャートに示す処理を、図１２に示したステップＳ１９の処理の後に、すなわち外部装置２０１から受信したコマンドをコマンドプール１１３に登録した直後に行うことが考えられる。
【００８４】
そして、この処理においては、まずステップＳ２１で、登録したコマンドについてのコマンドシートの「メソッド名」の項目のデータを取得し、これをキーに宛先テーブルを検索し、コマンドの宛先（転送先）となるＵＲＬの情報を取得する。ここで、転送先はウェブサービス機能部１２０であり、ハードウェアとしては自分自身であるので、ＩＰアドレスはその旨を示すループバックアドレスの「１２７．０．０．１」であり、宛先テーブルにはポート番号とＵＲＬパスを記載しておくものとする。
【００８５】
図１５に宛先テーブルの具体例を示すが、例えば、コマンドの名前空間ＵＲＩと対応させてそのコマンドの転送先となるＵＲＬのポート番号とＵＲＬパスを記憶しておけばよい。そして、図１５に示した例では、例えば名前空間ＵＲＩに「http://www.example.com/useradmin」を含むコマンドは、「http://127.0.0.1:80/useradmin」のＵＲＬに転送すればよいことがわかる。また、コマンドの名前空間ＵＲＩが宛先テーブルに記載されていないものであった場合にエラー処理を行うようにすることが考えられる。
なお、宛先テーブルの記載がコマンドの種類毎でないのは、コマンドの受け口となるポートやＵＲＬは、通常はある程度の機能的なまとまりをもったコマンド群毎に定められ、このようなコマンド群中の各コマンドにはある程度共通性のある名前空間ＵＲＩが付されているためである。コマンド毎にポートやＵＲＬを記載するようにすることも可能であるが、このようにコマンド群毎に記載した方が、コマンドの追加や変更があった場合のメンテナンスの負担を軽減できる。
【００８６】
次のステップＳ２２では、コマンドシートの「入力パラメータ」の項目に登録されているＳＯＡＰエンベロープをＨＴＴＰリクエストに記載し、ステップＳ２１で取得した宛先に送信する。この処理において、ＣＰＵ１１が個別送信手段として機能する。
なお、ここで用いる宛先は、ハードウェアとしては自分自身のものであるので、送信したＨＴＴＰリクエストは、ＯＳ（オペレーティングシステム）等の機能によって提供されるループバック機能により、サーバ装置１０１自身が受信することになる。図６にはこの転送がネットワークＩ／Ｆ１５経由で行われるように図示したが、ループバックがどの時点で行われるかはシステムの構成や設定に依存し、物理層に達する前に行われる場合もあれば、ＬＡＮ１０５内のルータやファイアウォールにおいて行われる場合もある。
そして、サーバ装置１０１が受信したＨＴＴＰリクエストは、ウェブサービス機能部１２０に渡され、サービス提供部１２３においてコマンドに応じた処理がなされ、応答がＨＴＴＰレスポンスに記載された状態で送信されてくるので、ステップＳ２３でこの受信を待つ。この受信も、上記と同様なループバック機能を利用してなされるものである。
【００８７】
そして、サービス提供部１２３からＨＴＴＰレスポンスを受信すると、そこに記載されているＳＯＡＰレスポンスに係るＳＯＡＰエンベロープのＸＭＬデータを、コマンドシートの「出力パラメータ」の項目に登録する。その後、ステップＳ２４でコマンドシートの「状態」を「処理完了」に変更し、処理が完了したことを示して、もとの図１２の処理に戻る。なお、ステップＳ２３の処理において、ＣＰＵ１１は個別受信手段として機能する。
以上の処理を行うことにより、外部装置２０１から受信したコマンドを、コマンドに含まれる情報に従って宛先となるサービス手段に転送し、またそのサービス手段から受信した応答を受信し、コマンドと関連付けて記憶することができる。
【００８８】
次に、図１６に、ウェブサービス機能部１２０によるコマンド実行処理の一例のフローチャートを示す。
このコマンド実行処理は、ウェブサービス機能部１２０にＨＴＴＰリクエストが送信されてきた場合に実行する処理であり、そのＨＴＴＰリクエストが、仲介機能部１１０が図１４のステップＳ２２の処理により送信したものであっても、ＰＣ１０３等の他の装置がＬＡＮ１０５を介して送信してきたものであっても、同じ処理を行うようにしている。
【００８９】
そして、この処理においては、まずステップＳ３１で、送信されてきたＨＴＴＰリクエストを受信する。そして、ステップＳ３２で、その受信したＨＴＴＰリクエスト中のＨＴＴＰボディのＸＭＬの構文を解析し、ステップＳ３３で、ＨＴＴＰリクエストの送信先となっていたＵＲＬパスやポートに応じて、ＨＴＴＰリクエストに記載されていたＳＯＡＰリクエストに係る処理を、適切なサービス提供部１２３に振り分ける。このとき、ステップＳ３２の解析で得た内容のうち「SOAPAction」ヘッダの値も参照して振り分けを行うようにしてもよい。
そして、ステップＳ３４で、振り分け先のサービス提供部１２３の機能により、ＳＯＡＰリクエストに記載されていた入力パラメータを解析し、ステップＳ３５でその入力パラメータの内容に従った処理を実行して、出力パラメータを生成する。なお、ステップＳ２３の構文解析も、ここで行うようにしてもよい。
【００９０】
その後、ステップＳ３６でその出力パラメータをＳＯＡＰレスポンスのＸＭＬ文書に変換し、ステップＳ３７でそれをステップＳ３１で受信したＨＴＴＰリクエストに対するＨＴＴＰレスポンスに記載して、そのＨＴＴＰリクエストの送信元に返して処理を終了する。
以上の処理により、受信したＨＴＴＰリクエストに記載されていたＳＯＡＰリクエストに係るコマンドの内容に応じた処理を行い、その結果を示すＳＯＡＰレスポンスをＨＴＴＰレスポンスに記載してその送信元に返すことができる。
【００９１】
また、コマンド転送に関する処理としては、図１２に示した処理とは独立に、図１７に示す処理を実行することも考えられる。
この場合、ＣＰＵ１１は適当なタイミングで図１７のフローチャートに示す処理を開始する。
そして、この処理においては、まずコマンドプールに「状態」が「未処理」であるコマンドシートがあるか否か判断し（ＳＸ１）、なければこのようなコマンドシートが追加されるまで待機する。そして、このようなコマンドシートを発見した場合、その１つを処理対象とし、そのコマンドシートの「状態」を「処理中」に変更する（ＳＸ２）。
【００９２】
その後、図１４の場合と同様なステップＳ２１乃至Ｓ２４の処理を行って処理対象のコマンドシートに記載されたコマンドをウェブサービス機能部１２０に転送すると共に、応答を受信してコマンドシートに登録し、これが完了するとステップＳＸ１に戻って処理を繰り返す。
以上の処理は、複数のスレッド（例えば４スレッド）で同時に行うようにしてもよい。処理対象となったコマンドシートの「状態」は、「処理待ち」ではないため、複数のスレッドで同時に処理を行っても、１つのコマンドシートを重複して処理対象としてしまうことはない。
【００９３】
以上のような処理を行うようにすれば、任意のタイミングでコマンドをウェブサービス機能部１２０に転送することができるので、ウェブサービス機能部１２０における実行に時間のかかるコマンドがあった場合でも、以後の処理が滞ることがない。そして、実行の終了したものから順に、その結果をコマンド応答として外部装置２０１に送信可能な状態にすることができる。
以上で、サーバ装置１０１において実行する、各コマンド及びコマンド応答の転送に関する処理の説明を終了する。
【００９４】
サーバ装置１０１に以上説明してきたような各機能を設け、各処理を行わせることにより、ファイアウォール１０４の内側のサーバ装置１０１のような装置において複数のサービス手段によって提供されるサービスを、ファイアウォール１０４の外側の外部装置２０１のような装置から利用できるようにすることができる。このような効果は、仲介機能部１１０の付加によって実現されるものであるが、仲介機能部１１０を付加した場合でも、サーバ装置１０１は付加前と同様に各サービス機能部が実行するコマンドを受け付けることができ、ファイアウォール１０４内におけるサービスの利用環境を維持することができる。
【００９５】
また、サーバ装置１０１と外部装置２０１との間で、複数のサービス手段の動作に係る、宛先の異なるコマンド及びそのコマンドに対する応答を一括して送受信することができるので、これらの送受信の際の通信のオーバーヘッドを低減し、外部装置２０１がサービスを利用する際の通信効率を改善することができる。この点は、ファイアウォール１０４の有無とは無関係である。すなわち、仮にサービスの提供側と利用側の装置が双方ともファイアウォールの内側にあった場合でも、またサービスの提供側の装置がファイアウォールの外側に、利用側の装置が内側にあってファイアウォールがコマンド送信の障害にならない場合でも、上述の仲介機能部１１０を利用したコマンド及び応答の一括転送を行うようにすれば、図１に示したサーバ装置１０１と外部装置２０１との間の場合と同様、通信効率改善の効果を得ることができる。
【００９６】
なお、上述したように、仲介機能部１１０を利用した通信を行うためには、通信相手の装置（ここでは外部装置２０１）にも、この通信に対応する機能を設けることが必要となる。次に、仲介機能部１１０を用いた通信に対応するための、外部装置２０１側の機能構成について説明する。ハードウェアについては、図５を用いて説明した通り、サーバ装置１０１と同様なものを用いることができる。従って、以下の外部装置２０１の説明において、ハードウェアの構成要素を指す場合には、サーバ装置１０１の場合と共通の符号を用いるものとする。
【００９７】
図１８は、外部装置２０１の機能のうち、コマンド及び応答に関する処理を行うための機能の構成を示す機能ブロック図である。
図１８に示す機能のうち、コマンドプール２１３はいずれかの書き換え可能な記憶手段に設けられるものである。例えば不揮発メモリ１４に設けることができるが、ＲＡＭ１３や図示しないＨＤＤ（ハードディスクドライブ）に設けてもよい。コマンド生成機能部２１４、送信メッセージ収集機能部２１５、受信メッセージ分配機能部２１２の機能は、ＣＰＵ１１によって実現されるものである。また、ＨＴＴＰレスポンス送信機能部２１６及びＨＴＴＰリクエスト受信機能部２１１の機能は、ＣＰＵ１１及びネットワークＩ／Ｆ１５によって実現されるものである。
【００９８】
これらの機能についてさらに詳述する。
まず、ＨＴＴＰリクエスト受信機能部２１１は、受信手段に該当し、サーバ装置１０１が送信してくるＨＴＴＰリクエストを受信し、受信メッセージ分配機能部２１２に渡す機能を有する（Ｃ１，Ｃ２）。
受信メッセージ分配機能部２１２は、ＨＴＴＰリクエスト受信機能部２１１が受信したＨＴＴＰレスポンスに含まれるデータを、コマンドプール２１３のコマンドシートに登録する機能を有する（Ｃ３）。
【００９９】
また、コマンド生成機能部２１４は、要求生成手段に該当する。そして、サーバ装置１０１のウェブサービス機能部１２０に実行させるコマンドを生成し、このコマンドを識別する識別情報（ＩＤ）を割り当て、さらにこのコマンドを管理するための管理情報を付し、これらの情報を関連付けてテーブル形式のコマンドシートとしてコマンドプール２１３に登録する機能を有する（Ｃ５）。このうち、コマンドを生成する部分には、例えば外部装置２０１に備えるアプリケーションが該当する。また、コマンド生成機能部２１４に、ウェブサービス機能部１２０に各コマンドを実行させる際の優先順位を生成したコマンドに付する機能を設けてもよい。また、コマンド生成機能部２１４は、コマンドプール２１３のコマンドシートにコマンドに対する応答が登録された場合に、その応答を取得し、その応答に応じた処理を行う機能も有する（Ｃ４）。
そして、コマンドプール１１３は、コマンド生成機能部２１４が生成したコマンドと、サーバ装置１０１から受信した応答とを、そのコマンドの識別情報等と関連付けて登録するプールである。
【０１００】
ここで、図１９に外部装置２０１のコマンドシートにおけるデータ構造の例を示す。
この図に示すように、外部装置２０１のコマンドシートには、図７に示したサーバ装置１０１のコマンドシートとほぼ同様なデータを記憶する領域を設けている。
ただし、「コマンドの通知先」に代えて「コマンド実行結果の通知先」の項目を設け、そのシートに記載しているコマンドに対する応答を受信した場合に、その旨を通知して必要な処理を実行させるモジュールを示す参照情報を登録している。参照するモジュールは、コマンド生成機能部２１４中のコマンドを登録したモジュールであることが多いが、必ずしもそうである必要はない。
【０１０１】
また、「入力パラメータ」や「出力パラメータ」の項目には、コマンドを登録したモジュールや、応答を受信した場合に必要な処理を実行させるモジュールが認識できる形式でデータを登録し、このために上述した「シリアライザ」や「デシリアライザ」を利用するようにしている。
さらに、「状態」については、「未処理」→「応答待ち」→「応答受信済」と遷移する。
その他の点については、図７に示したサーバ装置１０１のコマンドシートの場合と同様である。
【０１０２】
図１８の説明に戻ると、送信メッセージ収集機能部２１５は、収集手段に該当する。そして、コマンド生成機能部２１４が生成したコマンドとこのコマンドのコマンドＩＤとを関連付けてコマンドプール２１３から読み出し、これらから送信メッセージを生成する機能を有する（Ｃ６）。なお、コマンドに実行優先順位が指定されている場合には、送信メッセージ収集機能部２１５が実行優先順位の高いものから順に読み出すようにすることが考えられる。
送信メッセージの形式については、サーバ装置１０１の場合と同様である。
【０１０３】
また、ＨＴＴＰレスポンス送信機能部２１６は、送信手段に該当し、送信メッセージ収集機能部２１５が生成した送信メッセージを記載したＨＴＴＰレスポンスを生成し、サーバ装置１０１に送信する機能を有する（Ｃ７，Ｃ８）。このとき、１つのＨＴＴＰレスポンスに送信メッセージをいくつ含めてもよいし、ＨＴＴＰリクエストの送信元に送信すべき送信メッセージであれば、ポートやＵＲＬパスが異なるＵＲＬに送信すべきコマンドに係る送信メッセージを任意に混在させることもできる。
そこで、ＨＴＴＰレスポンス送信機能部２１６は、これらのいずれに係る送信メッセージかに関わり無く、送信メッセージ収集機能部２１５が生成した全ての送信メッセージを１つのＨＴＴＰレスポンスに含めて送信するようにしている。ただし、１つのＨＴＴＰレスポンスに含める送信メッセージの数に上限を設けることも考えられる。
【０１０４】
また、ＨＴＴＰレスポンスの送信は、送信メッセージ収集機能部２１５がコマンドの読み出しを試みた場合には、読み出すデータがなく、結果的に送信すべきＳＯＡＰメッセージを生成しなかった場合にも行うものである。そして、この読み出しの試みは、サーバ装置１０１からのＨＴＴＰリクエストを受信した場合に行うものとする。
このようにするのは、上述のように、外部装置２０１からファイアウォール１０４を越えてサーバ装置１０１にＨＴＴＰリクエストを送信することができないためである。
【０１０５】
このような機能を有する外部装置２０１が受信するＨＴＴＰリクエストは、サーバ装置１０１から送信されてくるものであるので、例えばサーバ装置１０１の機能の説明中で図８を用いて説明したものである。外部装置２０１が送信するＨＴＴＰレスポンスも、サーバ装置１０１に対して送信し、サーバ装置１０１が受信するものであるので、例えば図９を用いて説明したものである。これらに含まれるパートの内容も、図１０及び図１１を用いて説明したようなものとなる。
【０１０６】
次に、図２０に、以上説明したような構成及び機能を有する外部装置２０１において実行するメッセージの収集及び分配処理の基本動作のフローチャートを示す。
外部装置２０１のＣＰＵ１１は、サーバ装置１０１からＨＴＴＰリクエストが送信されてくると、図２０のフローチャートに示す処理を開始する。
そして、まずステップＳ１０１で、サーバ装置１０１から送信されてきたＨＴＴＰリクエストを受信する。そして、これを受信すると、ステップＳ１０２でそのＨＴＴＰボディを解析して各パートに分割する。これらの各パートは、図８に示した通り、サーバ装置１０１に送信したコマンドに対する応答に係るＳＯＡＰレスポンスが記載されている。
そしてその後、分割して得た各パートを順次対象として、ステップＳ１０３乃至ステップＳ１０６の処理を繰り返す。
【０１０７】
この部分の処理においては、まずステップＳ１０３で、対象パートのＳＯＡＰエンベロープに係るＸＭＬ文書を解析してコマンドシートに登録できる形式のデータに変換する。そして、ステップＳ１０４で、コマンドプール２１３から対象パートのコマンド応答に対応するコマンドを探索し、そのコマンドについてのコマンドシートの「出力パラメータ」の項目に応答のデータを登録する。なお、応答には、「コマンドＩＤ」の情報として、コマンドの送信時に付したものと同じコマンドＩＤが付してあるものとし、コマンドの探索は、この情報をキーとして行うことができる。
【０１０８】
データの登録が終わると、ステップＳ１０５で、データを登録したコマンドシートの「状態」を「応答受信済」に変更してその旨を示す。そして、ステップＳ１０６で「コマンド実行結果の通知先」に登録されている通知先に、応答があった旨を通知する。この通知によって、コマンドを生成したアプリケーション等は、その生成したコマンドに応答があったことを認識し、応答に応じた処理を行うことができる。
【０１０９】
例えば、サーバ装置１０１にユーザを登録するコマンドを生成した場合、このコマンドがサーバ装置１０１に送信されると、サーバ装置１０１は登録処理の結果を含む応答を返してくる。そして、外部装置２０１側では、この応答を受信すると、ここに含まれるコマンドＩＤを基にどのコマンドに対する応答であるかを探索し、見つかったコマンドと対応させてそのコマンド応答を登録する。そして、そのコマンドの実行結果通知先として登録されている、ユーザ登録に対応するアプリケーションに、応答があった旨を通知するのである。アプリケーションは、この通知を受けた場合にコマンドシートを参照すれば、生成したコマンドの実行結果を「出力パラメータ」の項目から取得することができる。
【０１１０】
以上のステップＳ１０６までの処理が終了すると、次のパートがあればそれを対象としてステップＳ１０３からの処理を繰り返す。
全てのパートについてステップＳ１０３乃至Ｓ１０６の処理が終了すると、ＨＴＴＰリクエストの受信に関する処理を終了し、ステップＳ１０７以下のＨＴＴＰレスポンスの送信に関する処理に進む。
【０１１１】
この処理においては、まずステップＳ１０７で、コマンドプール２１３から、「状態」が「未送信」であるコマンドを、サーバ装置１０１に送信すべきコマンドとして収集し、「コマンドＩＤ」の内容もそのコマンドのコマンドＩＤとして収集する。外部装置２０１においては、「未送信」という「状態」は、コマンドがコマンド生成機能部２１４によって生成された後、まだサーバ装置１０１に通知されていないことを示すものであるので、これを基準にサーバ装置１０１に送信すべきコマンドを抽出できる。
【０１１２】
その後、ステップＳ１０７で収集した全てのコマンドを順次対象として、ステップＳ１０８乃至Ｓ１１０の処理を繰り返す。これらの処理においては、まずステップＳ１０８で、対象のコマンドとそのコマンドＩＤとを、これらの情報がそれぞれＳＯＡＰボディとＳＯＡＰヘッダとに含まれるＸＭＬ文書によるＳＯＡＰエンベロープに変換し、ステップＳ１０９で、これにエンティティヘッダを付して対象のコマンドに関するパートを生成する。そして、ステップＳ１１０で対象のコマンドを記載していたコマンドシートの「状態」を「応答待ち」に変更する。ここでの「応答待ち」という「状態」は、コマンドをサーバ装置１０１に通知済であることを示すものである。
【０１１３】
そして、ここまでの処理が全て完了した後、ステップＳ１１１でＣＰＵ１１は、ステップＳ１０９で生成した各パートをマージし、図９に示したようなマルチパートのＨＴＴＰレスポンスを生成してサーバ装置１０１に送信する。
なお、ステップＳ１１０で行った「状態」の変更は、実際にこの送信が終了してから行うようにしてもよい。このようにすることにより、通信エラーが発生しても、送信しようとしていたコマンドを再度送信の対象とすることができるので、システムの信頼性が向上する。
【０１１４】
なお、ここでは送信すべきパートを全て生成してからマージして送信を行うようにし、また全てのパートを受信してからこれを各パートに分割して処理を行うように説明したが、このようにする必要はない。各パートを生成するたびに順次送信するようにしたり、各パートを受信するたびに順次各パートに関する処理を行うようにしてもよいことは、サーバ装置１０１の場合と同様である。
【０１１５】
外部装置２０１に以上説明してきたような各機能を設け、各処理を行わせることにより、サーバ装置１０１との間で仲介機能部１１０を利用した通信が可能となり、上述したように、ファイアウォール１０４の外側から内側の装置が提供するサービスを利用できるようになる、通信効率が改善できる、等の効果を得ることができる。
また、外部装置２０１が仲介機能部１１０を有する複数の装置と通信を行う場合には、コマンドシートにおいてコマンドの宛先を管理し、ＨＴＴＰリクエストを受信した場合に、送信メッセージ収集機能部２１６が、そのＨＴＴＰリクエストの送信元が宛先となっているコマンドのみを収集するようにするとよい。
【０１１６】
〔実施形態の変形例：図２１，図２２〕
次に、上述した実施形態の変形例について説明する。
上述した実施形態においては、外部装置２０１がサーバ装置１０１に送信したコマンドを最終的にどのＵＲＬに転送するかを、仲介機能部１１０のコマンド転送ハンドラ１１４が宛先テーブルを参照して決める例について説明した。このようにすれば、外部装置２０１側ではコマンドの転送先を認識する必要はなく、単にコマンドのＵＲＩとメソッド名を正確に記載すればよいことになる。
しかし、外部装置２０１側で、サーバ装置１０１におけるコマンドの受け口となるＵＲＬ、すなわちコマンドの転送先となるＵＲＬを認識しているのであれば、コマンドをサーバ装置１０１に送信する際のパートにそのＵＲＬを記載し、コマンド転送ハンドラ１１４がそのＵＲＬにコマンドを転送するようにしてもよい。
【０１１７】
図２１及び図２２に、このような方式を採用した場合の、図１０に示した例と同じコマンドに係るパートの例を示す。
これらの図からわかるように、転送先のＵＲＬは、例えばパートのエンティティヘッダや、ＳＯＡＰエンベロープ中のＳＯＡＰヘッダの部分に記載することができる。ＳＯＡＰボディに記載することも可能ではあるが、転送先のＵＲＬはコマンド自体の情報ではないので、これ以外の部分に記載することが好ましい。
【０１１８】
また、この方式を採用する場合、上述の実施形態で説明した処理のうち、表１に示す部分を、表１に示す通り変更する必要があるが、このような変更を行えば、他の部分の処理は、上述の実施形態で説明したものと同様なものを適用可能である。
そして、転送先ＵＲＬをパートに記載するようにすれば、サーバ装置１０１側では宛先テーブルは不要であり、仲介機能部１１０を追加する際に設定すべき項目を低減し、仲介機能部１１０を容易に付加できるようにすることができる。
【表１】
2005322222.tif 000003
【０１１９】
〔実施形態の具体的な実施例：図２３乃至図３４〕
次に、上述した実施形態について、より具体的な実施例について説明する。
まず、図２３乃至図３２に、外部装置２０１からサーバ装置１０１に送信するコマンド及び、そのコマンドに対する応答を記載したパートの、図１０及び図１１に示した例とは別の例を示す。
【０１２０】
図２３に示すのは、ユーザ削除コマンドを記載したパートの例である。
ユーザ削除コマンドは、ユーザ登録コマンドと同じコマンド群に属するコマンドである。そしてこのため、「SOAPAction」ヘッダは、「http://www.example.com/useradmin/」までは図１０に示したユーザ登録コマンドの場合と同じである。ただし、コマンドの種類が異なるため、最後の「scratch」は異なる。
また、名前空間の宣言はユーザ登録コマンドの場合と同じであるので、「Envelope」タグの属性の図示は省略している。
【０１２１】
そしてＳＯＡＰヘッダには、「要求ＩＤ」のＸＭＬタグの内容として、このコマンドのＩＤである「９８７６６」が記載されている。またＳＯＡＰボディには、ウェブサービス機能部１２０のサービス提供部１２３に実行させるメソッドを指定する情報として、「ユーザ削除」タグが記載され、その下位のタグ「ユーザ名」の要素として、メソッドに引数として引き渡す、削除するユーザの名前が記載されている。
【０１２２】
図２４に示すのは、図２３に示したユーザ削除コマンドに対する応答を記載したパートの例である。
この例においても、名前空間の宣言は図１０に示した例と同じであるので、「Envelope」タグの属性の図示は省略している。そして、ＳＯＡＰヘッダには、「コマンドＩＤ」のＸＭＬタグの内容として、対応するコマンドのＩＤである「９８７６６」が記述されている。
また、ＳＯＡＰボディには、「ユーザ削除」コマンドに対する応答であることを示すための「ユーザ削除Response」タグが設けられ、その下位のタグに、応答の内容が記載される。ここでは、ユーザ削除が成功した旨の情報が記載されている。
【０１２３】
図２５及び図２６には、やはりユーザ登録コマンドと同じコマンド群に属するユーザ一覧取得コマンドと、そのコマンドに対する応答を記載したパートの例をそれぞれ示す。
このコマンドについても、やはり「SOAPAction」ヘッダは、「http://www.example.com/useradmin/」までは図１０に示したユーザ登録コマンドの場合と同じであるが、コマンドの種類が異なるため、最後の「getuserlist」は異なる。
そして、「要求ＩＤ」としては「９８７６７」が記載され、コマンドのＳＯＡＰボディには、引数なしで、ユーザ一覧取得コマンドであることを示す「ユーザ一覧取得」タグが記載されている。
そして、応答のＳＯＡＰボディには、「ユーザ一覧取得」コマンドに対する応答であることを示すための「ユーザ一覧取得Response」タグが設けられ、その下位のタグに、応答の内容として、ユーザ一覧の情報が記載されている。
【０１２４】
図２７及び図２８には、ユーザ登録コマンドとは異なるコマンド群に属する文書一覧取得コマンドと、そのコマンドに対する応答を記載したパートの例をそれぞれ示す。
このコマンドについては、「SOAPAction」ヘッダは、「http://www.example.com/」までは図１０に示したユーザ登録コマンドの場合と同じであるが、コマンド群が異なるので、「docadmin/getdocumentlist」の部分は異なる。そして、名前空間接頭辞「ｎｃ」についての名前空間の宣言も、図１０の場合とは異なる。ただし、図２７の例と図２８の例とでは同じである。
【０１２５】
そして、「要求ＩＤ」としては「９８７６８」が記載され、コマンドのＳＯＡＰボディには、引数なしで、文書一覧取得コマンドであることを示す「文書一覧取得」タグが記載されている。
そして、応答のＳＯＡＰボディには、「文書一覧取得」コマンドに対する応答であることを示すための「文書一覧取得Response」タグが設けられ、その下位のタグに、応答の内容として、文書一覧の情報が記載されている。
【０１２６】
図２９及び図３０には、文書一覧取得コマンドと同じコマンド群に属する文書画像取得コマンドと、そのコマンドに対する応答を記載したパートの例をそれぞれ示す。
このコマンドについては、「SOAPAction」ヘッダは、「http://www.example.com/docadmin」までは図２７に示した文書一覧取得コマンドの場合と同じであるが、コマンドが異なるので、最後の「getimagedata」は異なる。名前空間の宣言は図２７に示した例と同じであるので、「Envelope」タグの属性の図示は省略している。
【０１２７】
そして、「要求ＩＤ」としては「９８７６９」が記載され、コマンドのＳＯＡＰボディには、文書画像取得メソッドを呼び出すことを示す「文書画像取得」タグが記載され、その下位のタグ「文書ＩＤ」の要素として、メソッドに引数として引き渡す、画像を取得する文書のＩＤが記載されている。
このＩＤは、例えば文書一覧取得コマンドによって取得した文書一覧から選択して記載することが考えられる。
そして、応答のＳＯＡＰボディには、「文書画像取得」コマンドに対する応答であることを示すための「文書画像取得Response」タグが設けられ、その下位のタグに、応答の内容として、文書画像データの情報がバイナリ形式で記載されている。
【０１２８】
図３１及び図３２には、文書一覧取得コマンドと同じコマンド群に属する文書削除コマンドと、そのコマンドに対する応答を記載したパートの例をそれぞれ示す。
このコマンドについては、「SOAPAction」ヘッダは、「http://www.example.com/docadmin」までは図２７に示した文書一覧取得コマンドの場合と同じであるが、コマンドが異なるので、最後の「delete」は異なる。名前空間の宣言は図２７に示した例と同じであるので、「Envelope」タグの属性の図示は省略している。
【０１２９】
そして、「要求ＩＤ」としては「９８７７０」が記載され、コマンドのＳＯＡＰボディには、文書削除メソッドを呼び出すことを示す「文書削除」タグが記載され、その下位のタグ「文書ＩＤ」の要素として、メソッドに引数として引き渡す、削除する文書のＩＤが記載されている。
このＩＤも、例えば文書一覧取得コマンドによって取得した文書一覧から選択して記載することが考えられる。
そして、応答のＳＯＡＰボディには、「文書削除」コマンドに対する応答であることを示すための「文書削除Response」タグが設けられ、その下位のタグに、応答の内容として、削除が成功したことを示す情報が記載されている。
【０１３０】
次に、図３３に、図１０，図１１及び図２３乃至図２６に示したようなユーザ管理関係のコマンド群を利用する場合の、上述した実施形態の適用例を示す。
図３３（ａ）に示す例において、ＬＡＮ内のデジタル複合機やプリンタが、ユーザ管理関係のサービスを提供する機能を有している場合、管理者がＬＡＮに接続された管理者端末を操作し、各装置にユーザ登録／削除等のコマンドを送信して、各装置を使用するユーザを管理することができる。しかし、逆に言えば、ユーザ管理関係のサービスをファイアウォールの外側から利用できない場合、内部で管理を行う他ない。
【０１３１】
しかし、管理対象機器に、図６に示したような仲介機能部１１０を付加することにより、（ｂ）に示すように、ファイアウォールの外側から各装置におけるユーザ管理関係のサービスを利用できるようになる。そして、この場合、例えばユーザ環境内の各装置におけるユーザの管理を、管理サービス会社に委託し、アウトソーシングによってＴＣＯ（Total Cost of Ownership）を削減することができる。
【０１３２】
また、図３４に、図２７乃至図３３に示したような文書管理関係のコマンド群を利用する場合の、上述した実施形態の適用例を示す。
図３４（ａ）に示す例において、ＬＡＮ内のデジタル複合機が、文書管理関係のサービスを提供する機能を備えている場合、スキャンした画像を文書としてドキュメントボックスに蓄積しておき、これを文書管理サーバやユーザ端末に読み出してバックアップしたり、プリントアウトやメディアに保存する等して外に持ち出すことができる。しかし、逆に言えば、文書管理関係のサービスをファイアウォールの外側から利用できない場合、ユーザ環境（例えばオフィス）内でバックアップやプリント等を行う他ない。
【０１３３】
しかし、デジタル複合機に図６に示したような仲介機能部１１０を付加することにより、（ｂ）に示すように、ファイアウォールの外側からデジタル複合機における文書管理関係のサービスを利用できるようになる。そして、この場合、例えばデジタル複合機がスキャンした文書の管理を管理サービス会社に委託し、管理サービス会社がデジタル複合機内の文書を定期的に取り出して保管・管理するようにすることもできる。そして、このようにすると、ユーザがユーザ端末から管理サービス会社端末にアクセスしてその文書のデータを取得することができるし、コンビニエンスストア等の店舗に供えたコピー機等から文書のデータにアクセスし、これをプリントするといったことも可能になる。また、外部のＳＯＨＯ（Small Office Home Office）等の端末装置から文書データにアクセスし、業務に使用することも可能になる。
ユーザ環境内にサーバを立てて外部からの広汎なアクセスを許可するとすると、その維持管理には大きな労力を有するが、（ｂ）に示すように管理を外部の会社に委託できるようになれば、比較的小さな労力で、セキュリティを維持しながら広汎な場所からユーザ環境で読み取った文書にアクセスできるようになると考えられる。
【０１３４】
〔各実施形態のその他の変形例〕
ここで、上述した実施形態に適用する、その他の変形例について説明する。
上述した各実施形態においては、ＲＰＣを実現する上位プロトコルとしてＳＯＡＰを採用し、アプリケーションは直接プールを操作してＲＰＣを実現しているが、アプリケーションとプールとの間にＣＯＲＢＡ（Common Object Request Broker Architecture）やＪＡＶＡ（登録商標）ＲＭＩ（Remote Method Invocation）とのブリッジ（メッセージ変換機能）を備えることによってアプリケーションの開発効率をさらに向上させてもよい。
すなわち、上述した各実施形態において、各ノード間でのコマンド及びこれに対するコマンド応答のやり取りは、ＸＭＬで記述されたＳＯＡＰメッセージにより行うこととしているが、これに限るものでなく、他の形式で記述されていてもよい。
また、送受信するコマンドやコマンド応答の情報量に制限を設けても構わない。特に、受信するコマンドの情報量を制限するようにすると、受信側がメモリ容量の限られた装置である場合にメモリの使用量を抑えることができる。
【０１３５】
また、上述した実施例において、ＳＯＡＰ標準のプロトコルだけでなく、ＳＯＡＰとＭＩＭＥマルチパートを組み合わせた独自のプロトコルをもこれに加えて採用することにより、ＨＴＴＰリクエスト、或いはＨＴＴＰレスポンスに含まれるＳＯＡＰエンベロープを全く独立したものとして扱うこととしているが、ＳＯＡＰの関連仕様として定義されたＳＯＡＰアタッチメントによって、ＨＴＴＰレスポンスに含まれる第１パートのＳＯＡＰエンベロープに、第２パート以降のＳＯＡＰエンベロープへのリンクを埋め込んでこれらを関連付けて引き渡す構成にしてもよい。ＳＭＴＰを用いる電子メールの場合にも同様である。
【０１３６】
更に、ＳＯＡＰ等の上位プロトコルの下位に位置するデータ通信のプロトコルとして、ここではＨＴＴＰを採用した例について説明したが、この下位プロトコルについても、ＦＴＰ（File Transfer Protocol）やＳＭＴＰ等の他のプロトコルを採用してもよい。
また、ここではサーバ装置１０１と外部装置２０１とをインターネット１００を介して接続した例について説明したが、これ以外にも、有線、無線を問わず、ネットワーク通信が可能な各種通信経路を用いることができる。ユーザ環境内の装置間の接続についても、ＬＡＮ以外の各種通信経路を用いることもできる。
【０１３７】
さらにまた、通信システムの構成についても、以上説明したものに限られることはなく、例えば、サービス提供側の装置がファイアウォールの外にあったり、サービス利用側の装置が複数あったりする構成でもよいことは、上述した通りである。
また、サービス提供側の装置やサービス利用側の装置が、汎用コンピュータによる端末装置に限られないことはもちろんであり、プリンタ，ＦＡＸ装置，デジタル複写機，スキャナ装置，デジタル複合機等の画像処理装置や、ネットワーク家電，自動販売機，医療機器，電源装置，空調システム，ガス・水道・電気等の計量システム，自動車，航空機等に通信機能を持たせた通信装置、さらには携帯電話等の通信装置が考えられる。
【０１３８】
また、この発明によるプログラムは、動作要求を通信要求に含めた状態で受信し、その動作要求に対する応答である動作応答を通信応答に含めて送信するサービス手段を複数備え、外部の通信相手と通信可能な通信装置を制御するコンピュータに、図６に示した仲介機能部１１０のような通信機能を付加するためのプログラムである。
【０１３９】
このようなプログラムは、はじめからコンピュータに備えるＲＯＭあるいはＨＤＤ等の記憶手段に格納しておいてもよいが、記録媒体であるＣＤ−ＲＯＭあるいはフレキシブルディスク，ＳＲＡＭ，ＥＥＰＲＯＭ，メモリカード等の不揮発性記録媒体（メモリ）に記録して提供することもできる。そのメモリに記録されたプログラムをコンピュータにインストールしてＣＰＵに実行させるか、ＣＰＵにそのメモリからこのプログラムを読み出して実行させることにより、上述した各機能を付加することができる。
さらに、ネットワークに接続され、プログラムを記録した記録媒体を備える外部機器あるいはプログラムを記憶手段に記憶した外部機器からダウンロードして実行させることも可能である。
【０１４０】
また、仲介機能部の機能を実現するためのモジュールの付加方法としては、ＣＤ−ＲＯＭやインターネットからプログラムを読み出させてインストールする、ＰＣカードやＳＤカードから読み出させてインストールする、あるいは仲介機能部の機能を有するボードを追加する等が考えられる。また、この際、必要であれば、図１５に示したような宛先テーブルの内容も設定する。この設定は、キーボードからの手入力により行ったり、ウェブサービスライブラリ１２２が有するＷＳＤＬファイルを利用して、コマンド送信先のＵＲＬを指定して行ったりすることができる。また、外部装置２０１に対する通信要求の送信間隔や、通信要求の送信先とする外部装置のＵＲＬ等も必要に応じて登録する。プログラムのインストール時に自動的にこのような設定がなされるようにしてもよい。
【産業上の利用可能性】
【０１４１】
以上説明してきたように、この発明の通信機能付加方法、通信装置、プログラム又は記録媒体によれば、ファイアウォールの内側の通信装置において、複数のサービス手段によって提供されるサービスを、ファイアウォール内における利用環境を維持したまま、ファイアウォールの外側からでも低コストで効率よく利用できるようにすることができる。さらに、ファイアウォールの有無に関わらず、サービスを利用する際の通信効率を改善することができる。
従って、この発明を適用することにより、既にあるウェブサービス等の機能を、ファイアウォールの外側から利用できるようにし、管理業務のアウトソーシングを可能とするようなシステムを構築することができる。
【図面の簡単な説明】
【０１４２】
【図１】この発明の通信機能付加方法の適用対象の例である通信装置を用いて構成した通信システムの構成例を示す図である。
【図２】図１に示した通信システムにおける動作要求と動作応答の関係を示す図である。
【図３】図１に示した通信システムにおける、仲介モジュールを用いたサービス提供側装置とサービス利用側装置との間の通信シーケンスの例を示す。
【図４】その別の例を示す図である。
【図５】図１に示したサーバ装置及び外部装置のハードウェア構成例を示す図である。
【０１４３】
【図６】図１に示したサーバ装置の機能のうち、コマンド及びコマンド応答の送受信及びサービスの提供に関する処理を行うための機能の構成を示す機能ブロック図である。
【図７】図６に示したサーバ装置のコマンドシートにおけるデータ構造の例を示す。
【図８】同じくサーバ装置が外部装置に送信するＨＴＴＰリクエストの例を示す図である。
【図９】同じくサーバ装置が外部装置から受信するＨＴＴＰレスポンスの例を示す図である。
【図１０】図９に示したようなＨＴＴＰレスポンスに記載する、ウェブサービス機能部に対するコマンドを記載したパートの例を示す図である。
【０１４４】
【図１１】図１０に示したコマンドに対する応答を記載したパートの例を示す図である。
【図１２】図６に示したサーバ装置におけるメッセージの収集及び分配処理の基本動作のフローチャートである。
【図１３】同じくサーバ装置が外部装置から受信したコマンドをコマンドシートに登録する場合の、各項目に記載すべきデータの取得先を示す図である。
【図１４】同じくサーバ装置におけるコマンド転送処理の一例のフローチャートである。
【図１５】同じくサーバ装置が記憶する宛先テーブルの例を示す図である。
【０１４５】
【図１６】同じくサーバ装置におけるコマンド実行処理の一例のフローチャートである。
【図１７】コマンド転送処理の図１４とは異なる例を示す図である。
【図１８】図１に示した外部装置の機能のうち、コマンド及び応答に関する処理を行うための機能の構成を示す機能ブロック図である。
【図１９】図１８に示した外部装置のコマンドシートにおけるデータ構造の例を示す図である。
【図２０】同じく外部装置において実行するメッセージの収集及び分配処理の基本動作のフローチャートである。
【０１４６】
【図２１】実施形態の変形例における、図１０と対応するパートの例を示す図である。
【図２２】その別の例を示す図である。
【図２３】ユーザ削除コマンドを記載したパートの例を示す図である。
【図２４】そのコマンドに対する応答を記載したパートの例を示す図である。
【図２５】ユーザ一覧取得コマンドを記載したパートの例を示す図である。
【０１４７】
【図２６】そのコマンドに対する応答を記載したパートの例を示す図である。
【図２７】文書一覧取得コマンドを記載したパートの例を示す図である。
【図２８】そのコマンドに対する応答を記載したパートの例を示す図である。
【図２９】文書画像取得コマンドを記載したパートの例を示す図である。
【図３０】そのコマンドに対する応答を記載したパートの例を示す図である。
【０１４８】
【図３１】文書削除コマンドを記載したパートの例を示す図である。
【図３２】そのコマンドに対する応答を記載したパートの例を示す図である。
【図３３】この発明の実施形態のより具体的な適用例について説明するための図である。
【図３４】その別の例について説明するための図である。
【符号の説明】
【０１４９】
１１：ＣＰＵ              １２：ＲＯＭ
１３：ＲＡＭ              １４：不揮発メモリ
１５：ネットワークＩ／Ｆ  １００：インターネット
１０１：サーバ装置        １０２：画像処理装置
１０３：ＰＣ              １０４：ファイアウォール
１１０：仲介機能部
１１１：ＨＴＴＰリクエスト送信機能部
１１２，２１２：受信メッセージ分配機能部
１１３，２１３：コマンドプール
１１４：コマンド転送ハンドラ
１１５，２１５：送信メッセージ収集機能部
１１６：ＨＴＴＰレスポンス受信機能部
１２０：ウェブサービス機能部
１２１，２１１：ＨＴＴＰリクエスト受信機能部
１２２：ウェブサービスライブラリ
１２３：サービス提供部
１２６，２１６：ＨＴＴＰレスポンス送信機能部
２１４：コマンド生成機能部
【図１】
2005322222.tif 000004
【図２】
2005322222.tif 000005
【図３】
2005322222.tif 000006
【図４】
2005322222.tif 000007
【図５】
2005322222.tif 000008
【図６】
2005322222.tif 000009
【図７】
2005322222.tif 000010
【図８】
2005322222.tif 000011
【図９】
2005322222.tif 000012
【図１０】
2005322222.tif 000013
【図１１】
2005322222.tif 000014
【図１２】
2005322222.tif 000015
【図１３】
2005322222.tif 000016
【図１４】
2005322222.tif 000017
【図１５】
2005322222.tif 000018
【図１６】
2005322222.tif 000019
【図１７】
2005322222.tif 000020
【図１８】
2005322222.tif 000021
【図１９】
2005322222.tif 000022
【図２０】
2005322222.tif 000023
【図２１】
2005322222.tif 000024
【図２２】
2005322222.tif 000025
【図２３】
2005322222.tif 000026
【図２４】
2005322222.tif 000027
【図２５】
2005322222.tif 000028
【図２６】
2005322222.tif 000029
【図２７】
2005322222.tif 000030
【図２８】
2005322222.tif 000031
【図２９】
2005322222.tif 000032
【図３０】
2005322222.tif 000033
【図３１】
2005322222.tif 000034
【図３２】
2005322222.tif 000035
【図３３】
2005322222.tif 000036
【図３４】
2005322222.tif 000037