JP4704105B2 - 通信装置、通信システム及び通信方法 - Google Patents

Description

この発明は、通信相手の装置である相手先装置との間で動作要求及び該動作要求に対する応答である動作応答を送受信する通信装置、このような通信装置の通信相手となる通信装置、互いに動作要求及び該動作要求に対する応答である動作応答を送受信する第１及び第２の通信装置を備えた通信システム、および通信相手の装置である相手先装置との間で動作要求及び該動作要求に対する応答である動作応答を送受信する通信装置における通信方法に関する。

従来から、通信装置をネットワークを介して接続した通信システムにおいて、通信装置同士で互いにメッセージを交換させることにより、通信相手の装置に対して通知や要求を行わせることが行われている。そして、このようなシステムにおいて、ある装置から別の装置に動作要求としてコマンドを送信して動作を実行させ、送信相手から動作の実行結果を動作応答として返信させることも行われている。

また、通信システムを構成する通信装置の一部を通信クライアント、他の一部を通信サーバとし、通信クライアントと通信サーバとの間の通信を、常に通信クライアントから通信サーバに通信要求を送信し、通信サーバからその送信元の通信クライアントに対して通信応答を返すというプロトコルで行うようにすることも知られている。
そこで、通信クライアントから通信サーバへの動作要求を通信要求に記載して送信し、その動作要求に対する動作応答を通信応答に記載して通信サーバから通信クライアントに返信することも行われている。

また、逆に通信サーバから通信クライアントに動作要求を送信して動作を行わせる技術としては、以下のようなものが知られている。
例えば、特許文献１には、リモートプロセッサがローカルプロセッサに対して実行されるべきコマンドを指示するメッセージを送信し、そのコマンドに対する応答を受信することが記載されている。

この文献には、ローカルプロセッサがファイアウォールの内側に配置されている場合において、ローカルプロセッサからファイアウォールの外側のリモートプロセッサに通信要求を送信し、リモートプロセッサがこの通信要求に対する応答としてローカルプロセッサに対してコマンドを送信するようにすることにより、ファイアウォールの外側から内側に向けてコマンドを送信できるようにする技術も開示されている。
この場合において、ローカルプロセッサが通信クライアントに、リモートプロセッサが通信サーバに該当する。
特開２００１−２７３２１１号公報

また、特許文献２には、画像処理装置に通信相手と通信するための通信手段を設けた通信装置において、通信相手に対するＳＯＡＰリクエストと、その通信相手から受信したＳＯＡＰリクエストに対するＳＯＡＰレスポンスとを、その通信相手に対するＨＴＴＰリクエストとして一括して送信させ、また、そのＨＴＴＰリクエストに対するＨＴＴＰレスポンスとして、上記の通信相手に送信したＳＯＡＰリクエストに対するＳＯＡＰレスポンスとその通信相手からのＳＯＡＰリクエストとを、一括して受信させるようにすることが記載されている。
特開２００４−１３５３２３号公報

ところで、上述した特許文献１又は２に記載したような通信プロトコルは、相手側も同じプロトコルに対応していないと、通信を正常に行うことはできない。また、単に通信クライアントから通信サーバへの動作要求を通信要求に記載して送信し、その動作要求に対する動作応答を通信応答に記載して通信サーバから通信クライアントに返信する場合と比べ、処理負荷も大きくなる。
一方で、通信を行う装置間にファイアウォールがない場合には、特許文献１又は２に記載されているようなプロトコルを用いる必要は、特にない。従って、通信装置を上述した特許文献１又は２に記載されているような通信プロトコルに対応させる場合でも、常にこのような通信プロトコルを使用させると、却って不具合が生じてしまう場合があるという問題があった。

以上のようなこの発明の通信装置、通信システム又は通信方法によれば、通信装置間で動作要求を送受信させる場合において、通信の効率を向上させることができる。

上記の目的を達成するため、通信相手の装置である相手先装置との間で動作要求及びその動作要求に対する応答である動作応答を送受信する通信装置において、上記相手先装置から通信要求を受信し、その相手先装置に対してその通信要求に対する通信応答を送信し、上記相手先装置に対する動作要求と、上記相手先装置から受信した動作要求に対する動作応答とを、上記通信応答に含めて一括して上記相手先装置に送信し、上記相手先装置からの動作要求と、上記相手先装置に送信した動作要求に対する動作応答とを、上記通信要求に含まれた状態で一括して上記相手先装置から受信する第１の通信手段と、上記相手先装置に対する動作要求を上記相手先装置に対する通信要求に含めて送信し、その相手先装置に対する動作要求に対する動作応答をその送信した通信要求に対する通信応答に含まれた状態で受信し、上記相手先装置からの動作要求を上記相手先装置からの通信要求に含まれた状態で受信し、その相手先装置からの動作要求に対する動作応答を、その受信した通信要求に対する通信応答に含めて送信する第２の通信手段と、上記相手先装置に対する動作要求を上記相手先装置に送信する場合に、その通信装置が上記相手先装置に対してファイアウォールの外側にあるとき、上記第１の通信手段にその送信を行わせ、その通信装置と上記相手先装置との間にファイアウォールがないとき、上記第２の通信手段にその送信を行わせる第１の切換手段とを設けたものである。
このような通信装置において、上記第１の切換手段が、その通信装置のアドレス情報と上記相手先装置のアドレス情報とを取得し、これらのアドレス情報に基づいて、動作要求の送信を上記第１の通信手段に行わせるか上記第２の通信手段に行わせるかを決定するようにするとよい。

さらに、上記第１の通信手段が受信した動作要求を受信要求プールに記憶させる手段と、上記受信要求プールに記憶されている動作要求に係る動作を実行してその実行結果をその動作要求と対応させて上記受信要求プールに記憶させる要求実行手段と、上記第１の通信手段により上記相手先装置に送信すべき動作要求を送信要求プールに記憶させる手段とを設け、上記第１の通信手段が、上記相手先装置から通信要求を受信した場合に、上記受信要求プールに記憶されている動作要求に係る動作の実行が全て完了しているか否かに関わらず、上記送信要求プールに記憶されている未送信の動作要求と、上記受信要求プールに記憶されている未送信の実行結果を上記相手先装置に伝達するための動作応答とを、その通信要求に対する動作応答に含めて上記相手先装置に送信するようにするとよい。

さらに、上記第１の通信手段を、上記相手先装置から通信要求を受信し、その相手先装置に対してその通信要求に対する通信応答を送信し、上記相手先装置に対する動作要求と、上記相手先装置から受信した動作要求に対する動作応答とを、上記通信応答に含めて一括して上記相手先装置に送信し、上記相手先装置からの動作要求と、上記相手先装置に送信した動作要求に対する動作応答とを、上記通信要求に含まれた状態で一括して上記相手先装置から受信する第１の通信動作と、上記相手先装置に対して通信要求を送信し、その相手先装置からその通信要求に対する通信応答を受信し、上記相手先装置に対する動作要求と、上記相手先装置から受信した動作要求に対する動作応答とを、上記通信要求に含めて一括して上記相手先装置に送信し、上記相手先装置からの動作要求と、上記相手先装置に送信した動作要求に対する動作応答とを、上記通信応答に含まれた状態で一括して上記相手先装置から受信する第２の通信動作とを選択的に実行する手段とし、その通信装置が上記相手先装置に対してファイアウォールの外側にあるとき、上記第１の通信手段に上記第１の通信動作を実行させ、その通信装置が上記相手先装置に対してファイアウォールの内側にあるとき、上記第１の通信手段に上記第２の通信動作を実行させる第２の切換手段を設け、上記第１の切換手段が、その通信装置が上記相手先装置に対してファイアウォールの内側にあるときにも、上記第１の通信手段に上記動作要求の送信を行わせるようにするとよい。

また、この発明の別の通信装置は、上記の通信装置を通信相手とする通信装置において、上記通信相手に対する動作要求を、その通信相手に対する通信要求に含めて送信し、その通信要求に対する通信応答に、上記送信した動作要求に対する動作応答が含まれていない場合でも、その通信応答に含まれている、上記通信相手からその通信装置への動作要求に係る動作を実行するようにしたものである。
このような通信装置において、通信相手に送信した通信要求に対する通信応答に、上記通信相手からの動作要求が複数含まれていた場合に、その各動作要求を分離し、その各動作要求に係る動作を個別に実行するようにするとよい。

また、この発明の通信システムは、互いに動作要求及びその動作要求に対する応答である動作応答を送受信する第１及び第２の通信装置を備えた通信システムにおいて、上記第１の通信装置に、上記第２の通信装置から通信要求を受信し、その第２の通信装置に対してその通信要求に対する通信応答を送信し、上記第２の通信装置に対する動作要求と、上記第２の通信装置から受信した動作要求に対する動作応答とを、上記通信応答に含めて一括して上記第２の通信装置に送信し、上記第２の通信装置からの動作要求と、上記第２の通信装置に送信した動作要求に対する動作応答とを、上記通信要求に含まれた状態で一括して上記第２の通信装置から受信する第１の通信手段と、上記第２の通信装置に対する動作要求を上記第２の通信装置に対する通信要求に含めて送信し、その第２の通信装置に対する動作要求に対する動作応答をその送信した通信要求に対する通信応答に含まれた状態で受信し、上記第２の通信装置からの動作要求を上記第２の通信装置からの通信要求に含まれた状態で受信し、その第２の通信装置からの動作要求に対する動作応答を、その受信した通信要求に対する通信応答に含めて送信する第２の通信手段と、上記第２の通信装置に対する動作要求を上記第２の通信装置に送信する場合に、上記第１の通信装置が上記第２の通信装置に対してファイアウォールの外側にあるとき、上記第１の通信手段にその送信を行わせ、上記第１の通信装置と上記第２の通信装置との間にファイアウォールがないとき、上記第２の通信手段にその送信を行わせる第１の切換手段とを設けたものである。
このような通信システムにおいて、上記第１の通信装置の上記切換手段が、上記第１の通信装置のアドレス情報と上記第２の通信装置のアドレス情報とを取得し、これらのアドレス情報に基づいて、動作要求の送信を上記第１の通信手段に行わせるか上記第２の通信手段に行わせるかを決定するようにするとよい。

さらに、上記第１の通信装置に、上記第１の通信手段が受信した動作要求を受信要求プールに記憶させる手段と、上記受信要求プールに記憶されている動作要求に係る動作を実行してその実行結果をその動作要求と対応させて上記受信要求プールに記憶させる要求実行手段と、上記第１の通信手段により上記第２の通信装置に送信すべき動作要求を送信要求プールに記憶させる手段とを設け、上記第１の通信装置の上記第１の通信手段が、上記第２の通信装置から通信要求を受信した場合に、上記受信要求プールに記憶されている動作要求に係る動作の実行が全て完了しているか否かに関わらず、上記送信要求プールに記憶されている未送信の動作要求と、上記受信要求プールに記憶されている未送信の実行結果を上記第２の通信装置に伝達するための動作応答とを、その通信要求に対する動作応答に含めて上記第２の通信装置に送信するようにするとよい。

さらに、上記第１の通信装置の上記第１の通信手段を、上記第２の通信装置から通信要求を受信し、その第２の通信装置に対してその通信要求に対する通信応答を送信し、上記第２の通信装置に対する動作要求と、上記第２の通信装置から受信した動作要求に対する動作応答とを、上記通信応答に含めて一括して上記第２の通信装置に送信し、上記第２の通信装置からの動作要求と、上記第２の通信装置に送信した動作要求に対する動作応答とを、上記通信要求に含まれた状態で一括して上記第２の通信装置から受信する第１の通信動作と、上記第２の通信装置に対して通信要求を送信し、その第２の通信装置からその通信要求に対する通信応答を受信し、上記第２の通信装置に対する動作要求と、上記第２の通信装置から受信した動作要求に対する動作応答とを、上記通信要求に含めて一括して上記第２の通信装置に送信し、上記第２の通信装置からの動作要求と、上記第２の通信装置に送信した動作要求に対する動作応答とを、上記通信応答に含まれた状態で一括して上記第２の通信装置から受信する第２の通信動作とを選択的に実行する手段とし、上記第１の通信装置は、上記第１の通信装置が上記第２の通信装置に対してファイアウォールの外側にあるとき、上記第１の通信手段に上記第１の通信動作を実行させ、上記第１の通信装置が上記第２の通信装置に対してファイアウォールの内側にあるとき、上記第１の通信手段に上記第２の通信動作を実行させる第２の切換手段を設け、上記第１の切換手段が、上記第１の通信装置が上記第２の通信装置に対してファイアウォールの内側にあるときにも、上記第１の通信手段に上記動作要求の送信を行わせるようにするとよい。

あるいは、上記第２の通信装置が、上記第１の通信装置に対する動作要求を、その第１の通信装置に対する通信要求に含めて送信し、その通信要求に対する通信応答に、上記送信した動作要求に対する動作応答が含まれていない場合でも、その通信応答に含まれている、上記第１の通信装置から上記第２の通信装置への動作要求に係る動作を実行するようにするとよい。
また、上記第２の通信装置が、上記第１の通信装置に送信した通信要求に対する通信応答に、上記第１の通信装置からの動作要求が複数含まれていた場合に、その各動作要求を分離し、その各動作要求に係る動作を個別に実行するようにするとよい。

また、この発明の通信方法は、通信相手の装置である相手先装置との間で動作要求及びその動作要求に対する応答である動作応答を送受信する通信装置における通信方法において、上記通信装置が、上記相手先装置から通信要求を受信し、その相手先装置に対してその通信要求に対する通信応答を送信し、上記相手先装置に対する動作要求と、上記相手先装置から受信した動作要求に対する動作応答とを、上記通信応答に含めて一括して上記相手先装置に送信し、上記相手先装置からの動作要求と、上記相手先装置に送信した動作要求に対する動作応答とを、上記通信要求に含まれた状態で一括して上記相手先装置から受信する第１の通信手順と、上記相手先装置に対する動作要求を上記相手先装置に対する通信要求に含めて送信し、その相手先装置に対する動作要求に対する動作応答をその送信した通信要求に対する通信応答に含まれた状態で受信し、上記相手先装置からの動作要求を上記相手先装置からの通信要求に含まれた状態で受信し、その相手先装置からの動作要求に対する動作応答を、その受信した通信要求に対する通信応答に含めて送信する第２の通信手順と、上記相手先装置に対する動作要求を上記相手先装置に送信する場合に、上記通信装置が上記相手先装置に対してファイアウォールの外側にあるとき、上記第１の通信手順によりその送信を行い、上記通信装置と上記相手先装置との間にファイアウォールがないとき、上記第２の通信手順によりその送信を行うよう上記通信装置の動作を制御する第１の切換手順とを実行するようにしたものである。
このような通信方法において、上記第１の切換手順に、上記通信装置のアドレス情報と上記相手先装置のアドレス情報とを取得し、これらのアドレス情報に基づいて、動作要求の送信を上記第１の通信手順により行うか上記第２の通信手順により行うかを決定する手順を設けるとよい。

さらに、上記通信装置が、上記第１の通信手順で受信した動作要求を受信要求プールに記憶させる手順と、上記受信要求プールに記憶されている動作要求に係る動作を実行してその実行結果をその動作要求と対応させて上記受信要求プールに記憶させる要求実行手順と、上記第１の通信手順により上記相手先装置に送信すべき動作要求を送信要求プールに記憶させる手順とを実行し、上記第１の通信手順において、上記相手先装置から通信要求を受信した場合に、上記受信要求プールに記憶されている動作要求に係る動作の実行が全て完了しているか否かに関わらず、上記送信要求プールに記憶されている未送信の動作要求と、上記受信要求プールに記憶されている未送信の実行結果を上記相手先装置に伝達するための動作応答とを、その通信要求に対する動作応答に含めて上記相手先装置に送信するようにするとよい。

さらに、上記第１の通信手順を、上記相手先装置から通信要求を受信し、その相手先装置に対してその通信要求に対する通信応答を送信し、上記相手先装置に対する動作要求と、上記相手先装置から受信した動作要求に対する動作応答とを、上記通信応答に含めて一括して上記相手先装置に送信し、上記相手先装置からの動作要求と、上記相手先装置に送信した動作要求に対する動作応答とを、上記通信要求に含まれた状態で一括して上記相手先装置から受信する第１の通信動作と、上記相手先装置に対して通信要求を送信し、その相手先装置からその通信要求に対する通信応答を受信し、上記相手先装置に対する動作要求と、上記相手先装置から受信した動作要求に対する動作応答とを、上記通信要求に含めて一括して上記相手先装置に送信し、上記相手先装置からの動作要求と、上記相手先装置に送信した動作要求に対する動作応答とを、上記通信応答に含まれた状態で一括して上記相手先装置から受信する第２の通信動作とを選択的に実行する手順とし、上記通信装置が、上記通信装置が上記相手先装置に対してファイアウォールの外側にあるとき、上記第１の通信手順で上記第１の通信動作を実行し、上記通信装置が上記相手先装置に対してファイアウォールの内側にあるとき、上記第１の通信手順で上記第２の通信動作を実行するよう上記通信装置の動作を制御する第２の切換手順を実行し、上記第１の切換手順を、上記通信装置が上記相手先装置に対してファイアウォールの内側にあるときにも、上記第１の通信手順により上記動作要求の送信を行よう上記通信装置の動作を制御する手順とするとよい。

以上のようなこの発明の通信装置、通信システム又は通信方法によれば、通信装置間で動作要求を送受信させる場合において、通信の効率を向上させることができる。

以下、この発明を実施するための最良の形態について、図面を参照して説明する。
〔通信システムと通信システムの構成：図１乃至図３〕
まず図１に、この発明の通信方法を適用する対象であり、この発明の通信システムの実施形態を含む通信システムの構成を示す。
この通信システムは、図１に示すように、ローカル環境１に、通信装置１０ａと通信装置１０ｂとをＬＡＮ（ローカルエリアネットワーク）を介して通信可能なように設けている。また、ＬＡＮ１２はファイアウォール１１を介してインターネット１３に接続しており、通信装置１０ａ，１０ｂが、インターネット上に設けた通信装置１０ｃとファイアウォール１１を介して通信できるようにしている。
以後、これらの通信装置を総称する場合には、符号「１０」を用いる。また、図１に示したような各通信装置のうち、任意の少なくとも２つの通信装置によって構成される通信システムが、この発明の通信システムの実施形態である。

次に、図２に、図１に示した通信装置１０のハードウェア構成を示す。
この図に示すように、通信装置１０は、ＣＰＵ１０１，ＲＯＭ１０２，ＲＡＭ１０３，不揮発メモリ１０４，ネットワークインタフェース（Ｉ／Ｆ）１０５を備え、これらがシステムバス１０６により接続されている。

そして、ＣＰＵ１０１は、通信装置１０全体を統括制御する制御手段であり、ＲＯＭ１０２や不揮発メモリ１０４に記録された種々のプログラムを実行することにより、第１，第２の通信手段等の各手段として機能し、後述するこの実施形態の特徴に係る種々の機能を実現する。
ＲＯＭ１０２は、不揮発性の記憶手段であり、ＣＰＵ１０１が実行するプログラムや、固定的なパラメータ等を記憶する。ＲＯＭ１０２を書き換え可能な記憶手段として構成し、これらのデータをアップデートできるようにしてもよい。

ＲＡＭ１０３は、一時的に使用するデータを記憶したり、ＣＰＵ１０１のワークメモリとして使用したりする記憶手段である。
不揮発メモリ１０４は、フラッシュメモリやＨＤＤ（ハードディスクドライブ）等による書き換え可能な不揮発性記憶手段であり、ＣＰＵ１０１が実行するプログラムや、装置の電源がＯＦＦされた後でも保持しておく必要があるパラメータの値等を記憶する。

ネットワークＩ／Ｆ１０５は、通信装置１０をＬＡＮ１２やインターネット１３等のネットワークに接続するためのインタフェースであり、例えばイーサネット（登録商標）方式の通信を行うためのネットワークインタフェースとすることができる。そして、ネットワークを介して他の装置と通信を行う場合、このネットワークＩ／Ｆ１０５とＣＰＵ１０１とが通信手段として機能する。なお、ネットワークＩ／Ｆ１０５は、通信に利用するネットワークの規格や使用する通信プロトコル等に応じて適切なものを用意する。また、複数の規格に対応させて複数のネットワークＩ／Ｆ１０５を設けることも当然可能である。

なお、図２には示していないが、通信装置１０に外部に対して通信以外の物理的な出力を行うためのエンジン部を設けてもよい。このエンジン部は、例えば通信装置１０がデジタル複合機（ＭＦＰ）であれば、画像形成部、画像読取部、ファクシミリ通信ユニット等であり、ＣＰＵ１０１がこれらの動作を適切に制御することにより、通信装置１０にコピー、プリント、スキャン、ファクシミリ通信等の種々の動作を実行させることができる。

また、以上のような図１及び図２に示した各通信装置１０は、ＲＰＣ（Remote Procedure Call）により、互いの実装するアプリケーションプログラム（以下単に「アプリ」ともいう）のメソッドに対する処理の依頼である「動作要求」を送信し、この依頼された処理の結果である「動作応答」を取得することができるようになっている。即ち、例えば通信装置１０ａは、通信装置１０ｂや通信装置１０ｃへの要求を生成してこれを通信装置１０ｂや通信装置１０ｃへ引き渡し、この要求に対する応答を取得できる一方で、通信装置１０ｂや通信装置１０ｃは、通信装置１０ａへの要求を生成してこれを通信装置１０ａへ引き渡し、この要求に対する応答を取得できるようになっている。

なお、ここではメソッドを入力と出力の形式を規定した論理的な関数として定義するものとする。そしてこの場合、動作要求はこの関数を呼び出す関数呼び出し（Procedure Call）となり、動作応答はその関数呼び出しによって呼び出された関数の実行結果となる。動作要求による要求の内容には、意味のある実行結果を伴わない通知も含まれる。
また、動作要求としては、例えば印刷要求（通信装置がプリンタの場合）や、ＦＡＸ送信要求（通信装置がＦＡＸ装置の場合）のように、装置に外見上把握できるような動作を実行させるものや、装置の動作状況の通知やデータ転送要求等、データの転送や内部的な処理を行わせるもの等、種々のものが考えられる。
そして、各通信装置１０は、ネットワークを介して受信した動作要求の内容に応じた処理を行ってその結果を動作応答として返すことにより、ウェブサービスを提供することができる。

図３に、これらの動作要求と動作応答の関係を示す。
図３（Ａ）は、いずれかの通信装置（通信装置Ａとする）で他の通信装置（通信装置Ｂとする）に対する動作要求が発生したケースである。このケースでは、通信装置Ａが通信装置Ａ側動作要求を生成して通信装置Ｂに送信し、これを受け取った通信装置Ｂがその要求に対する動作応答を返すというモデルになる。

図３（Ｂ）は、通信装置Ｂで通信装置Ａに対する動作要求が発生したケースである。このケースでは、通信装置Ｂが通信装置Ｂ側要求を生成して通信装置Ａに送信し、これを受け取った通信装置Ａがその要求に対する動作応答を返すというモデルになる。
このように、動作要求及び動作応答は、ＲＰＣのレベルでは各通信装置１０の間で対称に取り扱われるものである。しかし、後述するとおり、通信のレベルでは対称には取り扱えない場合がある。

なお、ここではＲＰＣによる引数並びに戻り値の受け渡しのプロトコルとしてＳＯＡＰ（Simple Object Access Protocol）を採用し、上記の動作要求や動作応答は、ここではＳＯＡＰメッセージとして記載するようにしている。
そして、実際に動作要求や動作応答を転送するための通信プロトコルとしては、システムの構成に合わせて適当なものを採用することができ、例えばＨＴＴＰ（HyperText Transfer Protocol）やＳＭＴＰ（Simple Mail Transfer Protocol）を採用することができる。ここでは、このうちＨＴＴＰを採用する場合の例について説明する。

図１に示したような通信システムを構成し、通信プロトコルにＨＴＴＰを採用する場合、各通信装置１０には、通信時に通信クライアントとして機能する装置（通信要求であるＨＴＴＰリクエストを送信する装置）と、通信サーバとして機能する装置（受信した通信要求に対する通信応答であるＨＴＴＰレスポンスを送信する装置）と、その両方として機能する装置とが存在しうる。
より具体的には、通信を行う装置間にファイアウォールがなければ、通信を行う通信装置１０が互いに通信相手に対してＨＴＴＰリクエストを送信し、通信相手からＨＴＴＰレスポンスを受信できるため、各通信装置が通信クライアントと通信サーバの両方として機能する。この場合には、通信のレベルでも、各通信装置を対称に動作させることができる。

しかし、通信を行う装置間にファイアウォールがある場合、そのファイアウォールは、ＨＴＴＰを用いて通信を行う場合に、ファイアウォールの外側からはファイアウォールの内側にあるノードに対して自由にアクセスできず、内側のノードからのＨＴＴＰリクエストに対するＨＴＴＰレスポンスという形でしかデータを送信できないように設定されることが多い。そこで、このような場合には、ファイアウォールの内側にある通信装置をＨＴＴＰクライアント（通信クライアント）、外側にある通信装置をＨＴＴＰサーバ（通信サーバ）として機能させることになる。この場合には、通信のレベルでは、各通信装置を対称に動作させることはできない。

この実施形態の特徴は、上記のような通信のレベルで対称な動作が可能な場合と不可能な場合とに合わせて適切な手順で通信を行うことができるようにした点である。以下、この点に関連する機能を中心に通信装置１０が備える機能及びその機能を実現させるための動作について説明する。

〔通信手順の概略：図４乃至図７〕
まず、図４に、各通信装置１０がＲＰＣに関連して備える機能部及び、その各機能部間でのメッセージの受け渡し経路を示す。この図において、図示している通信装置１０が生成した動作要求及びその動作要求に対する動作応答の受け渡し経路は実線で示し、図示している通信装置１０に対する動作要求及びその動作要求に対する動作応答の受け渡し経路は破線で示している。また、以下の図も含め、特に断らない場合、図に示す各構成要素の機能は、ＣＰＵ１０１が所要の制御プログラムを実行することにより実現されるものである。

図４に示すとおり、通信装置１０は、ＨＴＴＰクライアント機能部２０，ＨＴＴＰサーバ機能部３０，第１のメッセージコントローラ４０，第２のメッセージコントローラ５０，アプリ６０，送信先切り替え部７１，送信元記憶部７２，通信応答振り分け部７３，送信元記憶部７４，実行結果振り分け部７５，通信要求振り分け部７６を設けている。

このうち、ＨＴＴＰクライアント機能部２０とＨＴＴＰサーバ機能部３０は、ＨＴＴＰにより通信要求と通信応答の送受信を行う機能を有する。そして、前者は、通信相手に対してＨＴＴＰリクエストを送信するＨＴＴＰリクエスト送信部２１と、その通信相手からＨＴＴＰレスポンスを受信するＨＴＴＰレスポンス受信部２２とを有する。また後者は、通信相手からＨＴＴＰリクエストを受信するＨＴＴＰリクエスト受信部３１と、その通信相手に対してＨＴＴＰレスポンスを送信するＨＴＴＰレスポンス送信部３２とを有する。

また、アプリ６０により実現される機能部としては、通信相手のアプリに対して処理を依頼するコマンドを生成する送信コマンド生成部６１と、通信相手から依頼されたコマンドに係る処理を実行してその結果を返す受信コマンド実行結果生成部６２とを備えている。そして、この図から明らかなように、第１のメッセージコントローラ４０を介して受信した受信コマンドに係る処理も、第２のメッセージコントローラ５０を介して受信した受信コマンドに係る処理も、共通の受信コマンド実行結果生成部６２、すなわち共通のアプリ６０が行う。なお、１つのアプリ６０に送信コマンド生成部６１や受信コマンド実行結果生成部６２を複数設けたり、通信装置１０に複数のアプリ６０を設けたりしてよいことは、もちろんである。

第１，第２のメッセージコントローラ４０，５０は、それぞれアプリ６０とＨＴＴＰクライアント機能部２０及びＨＴＴＰサーバ機能部３０との間に介在し、コマンドやコマンド実行結果の内容をＳＯＡＰメッセージに変換し、これをＨＴＴＰメッセージに記載して通信相手に対して送信させたり、逆にＨＴＴＰメッセージ内にＳＯＡＰメッセージとして記載されたコマンドやコマンド応答を適当なアプリ６０に引き渡したりする機能を有する。そして、第１のメッセージコントローラ４０は、通信相手との間にファイアウォールがある場合に適した通信を行うための、第１の通信手段及び第１の応答手段の機能を有するコントローラであり、第２のメッセージコントローラは、通信相手との間にファイアウォールがない場合に適した通信を行うための、第２の通信手段及び第２の応答手段の機能を有するコントローラである。

なお、図４では、第１のメッセージコントローラ４０が通信相手との間でのメッセージの送受信に、ＨＴＴＰクライアント機能部２０とＨＴＴＰサーバ機能部３０の双方を使用するように図示しているが、実際には、通信装置１０が通信相手に対してファイアウォールの内側にある場合にはＨＴＴＰクライアント機能部２０を、外側にある場合にはＨＴＴＰサーバ機能部３０を使用するようにする。

送信先切り替え部７１は、通信相手に対してコマンドを送信する際に、第１，第２のメッセージコントローラ４０，５０のいずれに送信に係る処理を実行させるかを切り替える機能を有する。そして、通信相手との間にファイアウォールがある場合に、第１のメッセージコントローラ４０を用い、通信相手と自身との間にファイアウォールがない場合には、第２のメッセージコントローラ５０を用いるようにしている。
この切り替えは、所定のパラメータの値を手動又は自動で設定して行うようにしてもよいし、通信装置１０が通信相手のＩＰ（Internet Protocol）アドレス等の位置情報を検出し、その内容（例えばネットワークアドレスが同一か否か）に従って自動的に行うようにしてもよい。通信装置１０が特定の通信相手とのみ通信するような場合には、送信先切り替え部７１が、常に第１，第２のメッセージコントローラ４０，５０のいずれか一方にコマンド送信に係る処理を実行させることもあり得る。

送信元記憶部７２は、各メッセージコントローラ４０，５０がＨＴＴＰリクエスト送信部２１にＨＴＴＰリクエストを通信相手に対して送信させる場合に、どちらのメッセージコントローラがその送信を要求したかを記憶しておく機能を有する。
そして、通信応答振り分け部７３は、ＨＴＴＰレスポンス受信部２２がＨＴＴＰレスポンスを受信した場合に、送信元記憶部７２が記憶している情報をもとに、そのＨＴＴＰレスポンスを、対応するＨＴＴＰリクエストの送信を要求したメッセージコントローラに渡す機能を有する。

なお、これらの送信元記憶部７２及び通信応答振り分け部７３の機能を実現するための処理は、明示的にプログラムを書かなくても、コンパイラの機能により生成される。すなわち、一般的な処理系では、例えば関数呼び出しで別モジュールに処理を依頼すると、処理終了後は依頼元（関数呼び出し元）に制御が戻るようになっており、これは、関数呼び出し元（アドレス）をスタック（メモリ）に記憶することで実現される。そして、送信元記憶部７２及び通信応答振り分け部７３の機能は、このような処理に対応するものである。図４においてこれらを仮想線で示しているのは、このためである。

また、送信元記憶部７４は、各メッセージコントローラ４０，５０が通信相手から受信したＳＯＡＰリクエストに係るコマンドを受信コマンド実行結果生成部６２に渡す場合に、どちらのメッセージコントローラがそのコマンドが渡したかを記憶しておく機能を有する。
そして、実行結果振り分け部７５は、受信コマンド実行結果生成部６２がコマンドの応答として実行結果を返す場合に、その応答を、対応するコマンドを渡したメッセージコントローラに返す機能を有する。
これらの送信元記憶部７４及び実行結果振り分け部７５の機能も、上記の送信元記憶部７２及び通信応答振り分け部７３の場合と同様、特に専用のコードを書かなくても実現できる。図４においてこれらを仮想線で示しているのは、このためである。

また、通信要求振り分け部７６は、ＨＴＴＰリクエスト受信部３１がＨＴＴＰリクエストを受信した場合に、そのＨＴＴＰリクエストを、第１，第２のメッセージコントローラ４０，５０のいずれにより取り扱うべきかを判断し、適当なメッセージコントローラに渡す機能を有する。後述するとおり、第１のメッセージコントローラ４０が取り扱うＨＴＴＰリクエストと第２のメッセージコントローラ５０が取り扱うＨＴＴＰリクエストとは、形式が大きく異なるため、通信要求振り分け部７６は、ＨＴＴＰリクエストのヘッダ等を参照することにより、容易に振り分けを行うことができる。この場合、ＵＲＬで振り分け先を区別することが考えられる。また、送信先切り替え部７１の場合と同様な方法で振り分け先を区別することも考えられる。

次に、図５乃至図７を用いて、第１のメッセージコントローラ４０と第２のメッセージコントローラ５０の機能の違いについて説明する。
まず、図５に、第１のメッセージコントローラ４０を用いた場合の、通信装置間の通信シーケンスの例を示す。この図においては、ファイアウォールの内側の通信装置Ｌと外側の通信装置Ｍとの間でコマンド及びそのコマンドに対する応答（以下「コマンド応答」ともいう）を送受信する場合の例を示している。また、通信装置Ｌと通信装置Ｍの双方が第１のメッセージコントローラ４０を備えているものとする。

この図に示すように、第１のメッセージコントローラ４０を用いる場合には、通信は常に、通信装置Ｌから通信要求としてＨＴＴＰリクエストを通信装置Ｍに送信し、通信装置Ｍからこの通信要求に対する通信応答としてＨＴＴＰレスポンスを通信装置Ｌに返すという手順で行うようにしている。例えば通信装置Ｌが送信したＨＴＴＰリクエストＸに対して通信装置ＭがＨＴＴＰレスポンスＸを返し、同じくＨＴＴＰリクエストＹに対してＨＴＴＰレスポンスＹを返すという具合である。

そして、通信装置Ｌには、ＨＴＴＰリクエストに、通信装置Ｌから通信装置Ｍに送信する動作要求であるＬ側コマンドと、通信装置Ｍから通信装置Ｌに送信されてきたＭ側コマンドに対する応答とを記載して送信させるようにしている。また、通信装置Ｍには、ＨＴＴＰレスポンスに、通信装置Ｍから通信装置Ｌに送信する動作要求であるＭ側コマンドと、通信装置Ｌから通信装置Ｍに送信したＬ側コマンドに対する応答とを記載して送信させるようにしている。

従って、例えばＬ側コマンドＡは、ＨＴＴＰリクエストＸに記載して転送し、コマンド応答をそのＨＴＴＰリクエストＸと対応するＨＴＴＰレスポンスＸに記載して転送することができる。一方、Ｍ側コマンドＣについては、ＨＴＴＰリクエストＸと対応するＨＴＴＰレスポンスＸに記載して転送し、そのコマンド応答は次のＨＴＴＰリクエストであるＨＴＴＰリクエストＹに記載して転送することになる。

また、Ｌ側コマンドについては、コマンドが生成された後直ちに通信装置Ｌが通信装置Ｍとコネクションを確立し、ＨＴＴＰリクエストにこれを含めて引き渡すことができるが、Ｍ側コマンドについては、ファイアウォールが通信装置Ｍから通信装置ＬへのＨＴＴＰリクエストを遮断するため、通信装置Ｍ側から通信装置Ｌへアクセスしてコマンドを直ちに引き渡すことができない。従って、通信装置ＬからＨＴＴＰリクエストがあるまでＭ側コマンドを送信することができない。しかし、逆に言えば、通信装置ＬからＨＴＴＰリクエストがあれば、ファイアウォールの内側に対してもＭ側コマンドを送信し、コマンド応答を取得することができる。
そこで、このことを利用し、通信装置Ｌから通信装置Ｍに対して定期的にＨＴＴＰリクエストを送信するようにすれば、通信装置Ｍ側に、Ｍ側コマンドや、Ｌ側コマンドに対する応答を長期間滞留させずに、速やかに通信装置Ｌに送信できるようにすることができる。

なお、Ｌ側コマンド及びＭ側コマンドに対する応答をそれぞれ任意の数ずつ（０でもよい）１つのＨＴＴＰリクエストに記載することができ、Ｍ側コマンド及びＬ側コマンドに対する応答をそれぞれ任意の数ずつ（０でもよい）１つのＨＴＴＰレスポンスに記載することができる。そして、１つのＨＴＴＰリクエスト又はＨＴＴＰレスポンス（通信メッセージ）に記載した内容は、論理的に一括して転送する。
そして、このようにすることにより、必要な情報を転送するために必要なコネクションの回数を減らし、オーバーヘッドを低減して通信の効率化を図っている。

図６に第１のメッセージコントローラ４０を用いた場合の別の通信シーケンスの例を示す。
説明のため、図５には極めて単純なシーケンス例を示したが、図６には、各ＨＴＴＰリクエストやＨＴＴＰレスポンスに記載するコマンドやコマンド応答の数が一定でない例を示している。

また、コマンドを受信した場合に、次の送信機会の時点で応答を返す必要もない。例えば、図６に示すＬ側コマンドＢのように、コマンドを記載したＨＴＴＰリクエストＸ′に対応するＨＴＴＰレスポンスＸ′に記載して応答を返さず、後のＨＴＴＰレスポンスＹ′に記載して応答を返すようにしてもよい。
もちろんＭ側コマンドについても同様であり、Ｍ側コマンドを記載したＨＴＴＰレスポンスの次のＨＴＴＰリクエストにそのコマンドに対する応答を記載する必要はない。そして、さらに後のＨＴＴＰリクエストに記載して転送すればよい。

また、図７に、第２のメッセージコントローラ５０を用いた場合の、通信装置間の通信シーケンスの例を示す。間にファイアウォールを挟まずに通信する通信装置Ｌと通信装置Ｎとの間でコマンド及びコマンド応答を送受信する場合の例を示している。また、通信装置Ｌと通信装置Ｍの双方が第２のメッセージコントローラ５０を備えているものとする。
この図に示すように、第２のメッセージコントローラ５０を用いる場合には、通信装置Ｌと通信装置Ｎのいずれも、通信相手に対してＨＴＴＰリクエストを送信し、その応答として通信相手からＨＴＴＰレスポンスを受信するようにしている。

そして、各通信装置に、通信相手に対する動作要求であるコマンドを、その通信相手に対するＨＴＴＰリクエストに記載して送信させ、通信相手から受信したコマンドに対する応答は、コマンドが記載されていたＨＴＴＰリクエストに対するＨＴＴＰレスポンスに記載して送信させるようにしている。
通信装置間にファイアウォールがない場合には、通信相手に対するＨＴＴＰリクエストがファイアウォールにより遮断されることはないので、このような通信手順により、コマンドとコマンド応答の送受信が可能である。

このような通信手順は、ＳＯＡＰメッセージをＨＴＴＰメッセージに記載して転送する通信手順としてごく標準的なものであり、図５及び図６に示したような通信手順と比べて、通信装置内部での処理負荷は小さい。従って、通信相手の機器が標準的な通信手順に対応していれば、第１のメッセージコントローラ４０を利用するような特殊な通信手順に対応していない場合でも、通信が可能である。
ただし、ネットワーク内のトラフィック低減のため、図７に示したようにＨＴＴＰリクエストを双方が送信する場合でも、図５及び図６に示したように、コマンド及びコマンド応答を、１つの通信メッセージに複数記載するようにすることも考えられる。

〔第１，第２のメッセージコントローラによる通信手順：図８乃至図２５〕
次に、図８乃至図２５を用いて、上述した通信装置１０が第１，第２のメッセージコントローラ４０，５０を用いて通信を行う場合の通信手順について、より詳細に説明する。
まず、第１のメッセージコントローラ４０を用いる場合、複数のコマンドやコマンド応答を１つのＨＴＴＰメッセージに記載して転送することは上述した通りである。しかし、各コマンド及びコマンド応答は、それぞれ独立して生成され、また処理に供されるべきものであるから、このような一括転送を行うためには、転送前にこれらのコマンドやコマンド応答を結合し、また転送後に分離する処理が必要となる。

図８に、このような結合及び分離を実現するための第１のメッセージコントローラ４０の機能構成を、その周辺の機能と共に示す。この図で用いている線の種類とその意味は、図４の場合と同様である。
図８に示すように、第１のメッセージコントローラ４０には、送信コマンドプール４１，受信コマンドプール４２，コマンド応答通知部４３，コマンド通知部４４，送信メッセージ収集部４５，受信メッセージ分配部４６を設けている。このうち送信コマンドプール４１及び受信コマンドプール４２は、不揮発メモリ１０４のような書き換え可能な不揮発性記憶手段に設けられるものである。

そして、送信コマンドプール４１は、送信コマンド生成部６１が生成した通信相手に対するコマンドである送信コマンドと、そのコマンドに対する応答と、このコマンドの識別情報とを関連付けて登録するプールである。また、受信コマンドプール４２は、通信相手から受信した受信コマンドと、このコマンドに対する応答と、このコマンドの識別情報とを関連付けて登録するプールである。これらのプールにおいては、コマンド毎にテーブル形式のコマンドシートを作成して情報を格納することにより、コマンドと、識別情報や応答等の情報とを関連付けるようにしている。

ここで、図９に送信コマンドシートにおけるデータ構造の例を示す。
この図に示すように、送信コマンドシートには、「コマンドＩＤ」、「メソッド名」、「入力パラメータ」、「状態」、「コマンド実行結果の通知先」、および「出力パラメータ」のデータを記憶する領域を設けている。そして、このうち「コマンドＩＤ」、「メソッド名」、および「入力パラメータ」が送信コマンド（及びそこに付されたＩＤ）に該当する。「出力パラメータ」は、通信相手から受信するコマンド応答の内容である。

次に、各項目の内容について説明する。
まず、「メソッド名」は、通信相手に対する要求の内容であり、通信相手において呼び出す関数の種類を示す。「入力パラメータ」は、「メソッド名」に付随するデータであり、関数を呼び出す際の引数である。「コマンドＩＤ」は、送信コマンドを識別するための識別情報である。「状態」は、送信コマンドに関する処理の進行状況を示すデータであり、処理の進行と共に、「未送信」→「応答待ち」→「応答受信済」と遷移していく。

「コマンド実行結果の通知先」は、そのシートに記載している送信コマンドに対する応答を受信した場合に、その旨を通知して必要な処理を実行させるモジュールを示す参照情報である。参照するモジュールは、送信コマンドを生成した送信コマンド生成部６１であることが多いが、必ずしもそうである必要はない。「出力パラメータ」には、コマンド応答を受け取った段階で、その内容を格納する。通信相手からのコマンド応答を受け取るまでは空である。

また、図１０に受信コマンドシートにおけるデータ構造の例を示す。
この図に示すように、受信コマンドシートには、「コマンドＩＤ」、「メソッド名」、「入力パラメータ」、「状態」、「出力パラメータ」、および「コマンドの通知先」のデータを記憶する領域を設けている。そして、このうち「コマンドＩＤ」、「メソッド名」、および「入力パラメータ」が受信コマンド（及びそこに付されたＩＤ）に該当し、「状態」及び「コマンドの通知先」が管理情報に該当する。「出力パラメータ」は、受信コマンドの実行結果であり、通信装置１０が返すコマンド応答の内容となる。

次に、各データの内容について説明する。
まず、「メソッド名」は、通信装置１０に対する要求の内容であり、通信装置１０において呼び出す関数の種類を示す。「入力パラメータ」は、「メソッド名」に付随するデータであり、関数を呼び出す際の引数である。「コマンドＩＤ」は、受信コマンドを識別するための識別情報である。「状態」は、受信コマンドに関する処理の状態を示すデータであり、処理の進行と共に、「未処理」→「処理完了」→「応答済」、あるいは「未処理」→「処理中」→「処理完了」→「応答済」と遷移していく。「出力パラメータ」には、受信コマンド実行結果生成部６２によって生成された応答が格納される。受信コマンドの実行が終了し、上記の「状態」が「処理完了」となるまでは空である。「受信コマンドの通知先」は、受信コマンドの実行を行うモジュールを示す参照情報である。なお、このモジュールは通常はいずれかのアプリ６０に含まれる受信コマンド実行結果生成部６２である。

図８の説明に戻ると、送信コマンドプール４１に送信コマンドを記憶させるのは、アプリ６０に含まれる送信コマンド生成部６１であり、送信先切り替え部７１が第１のメッセージコントローラ４０の使用を選択した場合に、この処理が行われる。そして、送信コマンド生成部６１は、生成したコマンドにそのコマンドを識別する識別情報（ＩＤ）を割り当て、さらにこのコマンドを管理するための管理情報を付し、これらの情報を関連付けてテーブル形式の送信コマンドシートとして送信コマンドプール４１に登録する。この機能は送信先切り替え部７１に設けてもよい。また、その後このコマンドに対する応答が送信コマンドプール４１に記憶されると、コマンド応答通知部４３が、送信コマンドシート中の「コマンド実行結果の通知先」で指定されるモジュールにコマンド応答を通知する。

また、受信コマンドプール４２に受信コマンドが記憶されると、コマンド通知部４４が、送信コマンドシート中の「コマンドの通知先」で指定されるモジュール（受信コマンド実行結果生成部６２）にコマンドを通知する。すると、これを受け取ったモジュールがコマンドに係る処理を実行し、実行結果をコマンド応答として受信コマンドプール４２に記憶させる。

ここで、通信相手から受信した受信コマンドは、このコマンドを識別するＩＤ及びこのコマンドを管理するための管理情報と関連付けて、テーブル形式の受信コマンドシートとして受信コマンドプール４２に登録しておくようにしている。そして、受信コマンド実行結果生成部６２が生成したコマンド応答も、実行した受信コマンドについての受信コマンドシートに登録する。
なお、受信コマンドが通信装置１０に優先して処理を実行させるための実行優先順位の情報を含む場合には、優先順位の高いものから優先的に通知するようにすることも考えられる。

また、送信メッセージ収集部４５は、受信コマンド実行結果生成部６２が生成したコマンド応答とこのコマンド応答に対応する受信コマンドのコマンドＩＤとを関連付けて受信コマンドプール４２から読み出すと共に、送信コマンド生成部６１が生成した送信コマンドとこのコマンドのコマンドＩＤとを関連付けて送信コマンドプール４１から読み出し、これらから送信メッセージを生成する機能を有する。
なお、コマンド応答や送信コマンドに実行優先順位が指定されている場合には、送信メッセージ収集部４５がそれぞれ実行優先順位の高いものから順に読み出すようにすることが考えられる。

ここで、送信メッセージとは、上記のコマンド応答やコマンドとコマンドＩＤとを、構造化言語であるＸＭＬ（Extensible Markup Language）で、ＳＯＡＰメッセージとして記載したものである。そして、送信メッセージ収集部４５は、１つのコマンド応答あるいはコマンドにつき、送信メッセージとして１つのＳＯＡＰメッセージを生成する。またこのとき、各コマンドのコマンドＩＤはＳＯＡＰヘッダに記載し、コマンド応答及び送信コマンドの内容はＳＯＡＰボディに記載する。ＳＯＡＰによる通信では、ＳＯＡＰヘッダとＳＯＡＰボディとからなるＳＯＡＰエンベロープ（封筒）と呼ばれるメッセージをＸＭＬで記載し、ＨＴＴＰなどのプロトコルで交換することになる。
このようなコマンドやコマンド応答からのＳＯＡＰメッセージの生成は、ＷＳＤＬ（Web Service Description Language）に基づいて生成される所要の変換プログラム（シリアライザ）を実行し、データを直列化することによって行うことができる。

そして、送信メッセージ収集部４５は、生成した送信メッセージをＨＴＴＰリクエスト送信部２１又はＨＴＴＰレスポンス送信部３２に渡し、その送信メッセージを含むＨＴＴＰリクエスト又はＨＴＴＰレスポンスを生成させて通信相手に送信させる機能も有する。
また、このとき送信メッセージをＨＴＴＰリクエスト送信部２１又はＨＴＴＰレスポンス送信部３２のどちらに渡すかは、サーバ／クライアント切り替え部４５ａが決定する。上述した通り、通信相手とファイアウォール越しに通信を行う場合、通信装置１０が通信相手に対してファイアウォールの内側にある場合にはＨＴＴＰクライアント機能部２０を、外側にある場合にはＨＴＴＰサーバ機能部３０を使用するようにするので、この基準に応じて、前者の場合には送信メッセージをＨＴＴＰリクエスト送信部２１に渡し、後者の場合にはＨＴＴＰレスポンス送信部３２に渡すようにする。

なお、サーバ／クライアント切り替え部４５ａがどちらの送信部を選択するかは、所定のパラメータの値を自動または手動で設定して決定すればよい。また、通常はＨＴＴＰクライアント機能部２０を利用するようにしつつ、ＨＴＴＰサーバ機能部３０がＨＴＴＰリクエストを受信した場合にはこれに対応する処理を行うようにするような対応も考えられる。
また、メッセージの送信の説明に戻ると、ＨＴＴＰメッセージの送信に際し、１つのＨＴＴＰメッセージに送信メッセージをいくつ含めてもよいし、コマンド応答に係る送信メッセージと送信コマンドに係る送信メッセージとを任意に混在させることもできる。

そこで、ＨＴＴＰリクエスト送信部２１及びＨＴＴＰレスポンス送信部３２は、これらのいずれに係る送信メッセージであるかに関わり無く、送信メッセージ収集部４５が生成した全ての送信メッセージを１つのＨＴＴＰメッセージに含めて送信するようにしている。ただし、１つのＨＴＴＰメッセージに含める送信メッセージの数に上限を設けることも考えられる。

また、このＨＴＴＰメッセージの送信は、送信メッセージ収集部４５が送信コマンドやコマンド応答等の読み出しを試みた場合には、読み出すデータがなく、結果的に送信すべきＳＯＡＰメッセージを生成しなかった場合にも行うものである。
そして、この読み出しの試みは、送信メッセージ収集部４５がＨＴＴＰクライアント機能部２０を利用する場合、すなわち、通信装置１０が通信クライアントとして機能する場合には、定期的に行うものとする。例えば、タイマによって６０分毎に読み出すことが考えられる。

このようにするのは、上述のように、通信相手から通信装置１０に送信したい情報があったとしても、通信装置１０から通信を要求しない限り送信できないためである。通信装置１０から何も送信するデータがなかったとしても、定期的に通信相手に対して通信要求を送信して、通信相手から通信装置１０に情報を送信する機会を与えることにより、転送の必要な情報が長期間に亘って通信相手に滞留してしまうことを防止できる。

なお、送信メッセージ収集部４５による読み出しと、それに続くＨＴＴＰリクエスト送信部２１によるＨＴＴＰリクエストの送信とを、定期的なタイミング以外に適宜行ってよいことはもちろんである。例えば、緊急に送信が必要な情報がいずれかのプールに登録された場合に、送信コマンド生成部６１や受信コマンド実行結果生成部６２が送信メッセージ収集部４５にその旨を通知して読み出しを行わせるようにしてもよい。

また、送信メッセージ収集部４５がＨＴＴＰサーバ機能部３０を利用する場合、すなわち、通信装置１０が通信サーバとして機能する場合には、送信メッセージ収集部４５によるコマンドやコマンド応答の読み出しは、受信メッセージ分配部４６がＨＴＴＰリクエスト受信部３１を介して通信相手からのＨＴＴＰリクエストを受け取った場合に行う。通信サーバとして機能する場合には、通信装置１０側から通信相手に対して能動的にメッセージを送信することができないためである。

次に、受信メッセージ分配部４６は、ＨＴＴＰレスポンス受信部２２を介して通信相手からＨＴＴＰレスポンスを受け取る機能と、ＨＴＴＰリクエスト受信部３１を介して通信相手からＨＴＴＰリクエストを受け取る機能とを有する。なお、受信メッセージ分配部４６が受け取るのは、前者の場合には通信応答振り分け部７３が、後者の場合には通信要求振り分け部７６が、それぞれ第１のメッセージコントローラ４０で処理すべきものと判断したＨＴＴＰリクエストである。また、図４及び図８では、第１のメッセージコントローラ４０がこれらの振り分け部７３，７６を介してＨＴＴＰメッセージを受け取るように記載しているが、これらの振り分け部７３，７６は、ＨＴＴＰレスポンス受信部２２やＨＴＴＰリクエスト受信部３１にメッセージの振り分け先を指示するだけでもよい。

そして、いずれの場合にも、受信メッセージ分配部４６が受け取るＨＴＴＰメッセージには、受信コマンド及びそのコマンドと関連付けられたコマンドＩＤを含む受信メッセージと、送信コマンドに対する応答及びそのコマンドと関連付けられたコマンドＩＤを含む受信メッセージとが、任意に混在して含まれている。
ここで、受信メッセージとは、上記のコマンドや応答とコマンドＩＤとをＳＯＡＰメッセージとして記載したものである。

また、受信メッセージ分配部４６は、受信したＨＴＴＰメッセージに含まれるデータを、送信コマンドプール４１及び受信コマンドプール４２に振り分けて登録する機能も有する。
具体的には、受信コマンド及びそのコマンドと関連付けられたコマンドＩＤとを受信コマンドプール４２に受信コマンドシートを設けて登録すると共に、送信コマンドに対する応答については、そのコマンドと関連付けられたコマンドＩＤを送信コマンドプール４１に記憶している送信コマンドシートのコマンドＩＤと照合して対応する送信コマンドを特定し、その送信コマンドについての「出力パラメータ」として登録する。
そしてこのとき、ＨＴＴＰメッセージを分割してそこに含まれる各受信メッセージを取り出し、そのデータをテーブルへの登録に必要な形式に変換するが、この変換は、ＷＳＤＬに基づいて生成される所要の変換プログラム（デシリアライザ）を実行することによって行うことができる。

次に、このような機能を有する第１のメッセージコントローラ４０が通信相手に送信させるＨＴＴＰリクエストの例を図１１に示す。
このＨＴＴＰリクエストは、図１１に示すように、ボディ部としてＭＩＭＥ（Multipurpose Internet Mail Extension）に従ったマルチパートのメッセージが記載され、この各パートには、それぞれエンティティヘッダが記載されると共に、詳細な図示は省略しているが、ＳＯＡＰエンベロープが埋め込まれている。図１１の例では、ＨＴＴＰリクエストのＨＴＴＰボディには、「MIME_boundary」で区分された各要素が、独立した第１パート、第２パート、第３パート、第４パートを構成しているが、ＨＴＴＰボディに含めることのできるパート数は４つに限られない。０個を含め、いくつでもよい。

ＨＴＴＰリクエストに埋め込まれて通信相手に引き渡されるＳＯＡＰエンベロープには、送信コマンドを記載したものと、受信コマンドに対する応答を記載したものとがある。
また、通信相手から受信するＨＴＴＰリクエストのうち、第１のメッセージコントローラ４０で処理すべきものも、同様な形式であり、例えば、Content-Typeヘッダの内容により、それと見分けることができる。ＨＴＴＰリクエストに埋め込まれて通信相手から引き渡されるＳＯＡＰエンベロープには、(通信装置１０にとっての)受信コマンドを記載したものと、送信コマンドに対する応答を記載したものとがある。

また、第１のメッセージコントローラ４０が通信相手から受け取るＨＴＴＰレスポンスの例を図１２に示す。
図１２に示すように、このＨＴＴＰレスポンスは、形式としては、図１１に示したＨＴＴＰリクエストとＨＴＴＰヘッダ部が異なるのみであり、ボディ部には、ＨＴＴＰリクエストの場合と同様に詳細な図示は省略しているが、ＭＩＭＥに従ったマルチパートのＳＯＡＰエンベロープが記載される。ＳＯＡＰエンベロープの内容については、当然コマンドやコマンド応答の内容に従って異なるものである。
ＨＴＴＰレスポンスに埋め込まれて通信相手から引き渡されるＳＯＡＰエンベロープには、受信コマンドを記載したものと、送信コマンドに対する応答を記載したものとがある。
また、第１のメッセージコントローラ４０が通信相手に送信するＨＴＴＰレスポンスも、同様な形式であり、ＨＴＴＰレスポンスに埋め込んで通信相手に引き渡すＳＯＡＰエンベロープには、送信コマンドを記載したものと、受信コマンドに対する応答を記載したものとがある。

次に、これらのＨＴＴＰリクエスト又はＨＴＴＰレスポンスに記載されるパートの具体例を図１３乃至図１６に示す。
図１３に示すのは、コマンドを記載したパートの第１の例である。
この例においては、まず、エンティティヘッダの部分の「X-SOAP-Type」ヘッダに、このパートに記載されているＳＯＡＰメッセージがＳＯＡＰリクエストであるかＳＯＡＰレスポンスであるかを示す情報を記載している。この例では、値の「Request」により、ＳＯＡＰリクエストであること、すなわちコマンドを記載したＳＯＡＰメッセージであることを示している。

また、「SOAPAction」ヘッダは、ＳＯＡＰリクエストの内容を示すものであり、この例では、「http://www.…」というＵＲＩ（Uniform Resource Identifier）によりリクエストの内容を示している。なお、「SOAPAction」ヘッダは、ＳＯＡＰメッセージがＳＯＡＰレスポンスである場合には付加しないため、メッセージの受信側において、このヘッダの有無により、ＳＯＡＰメッセージがＳＯＡＰリクエストであるかＳＯＡＰレスポンスであるかを判断することもできる。

そして、「Envelope」タグの属性として、名前空間の宣言を行っている。そしてここでは、ＳＯＡＰで標準として定義されている名前空間の他に、「http://www.example.com/header」及び「http://www.example.com/server」のＵＲＩで特定される名前空間の宣言を行っている。従って、「ｎ」の名前空間接頭辞が付されたＸＭＬタグについては「http://www.example.com/header」のＵＲＩで特定される名前空間に属するタグであることがわかり、「ｎｓ」の名前空間接頭辞が付されたＸＭＬタグについては「http://www.example.com/server」のＵＲＩで特定される名前空間に属するタグであることがわかる。

またＳＯＡＰヘッダには、「要求ＩＤ」のＸＭＬタグの内容として、このコマンドのＩＤである「１２３４５」が記載されている。そして、ＳＯＡＰボディには、送信側の送信コマンドシートの「メソッド名」の項目に記憶されており、受信側の受信コマンドシートの「メソッド名」の項目に記憶させるメソッドを指定する情報として、「異常通知」タグが記載されている。また、その下位のタグ「エラーＩＤ」や「説明」の要素として、送信側の送信コマンドシートの「入力パラメータ」の項目に記憶されており、また受信側の受信コマンドシートの「入力パラメータ」の項目に記憶させる引数が記載されている。ここでは異常通知の通知内容が記載されている。

図１４に示すのは、図１３に示したコマンドに対する応答を記載したパートの例である。
この例においては、まず、エンティティヘッダの部分の「X-SOAP-Type」ヘッダの値を「Response」と記載することにより、このパートに記載されているＳＯＡＰメッセージがＳＯＡＰレスポンスであること、すなわちコマンド応答を記載したＳＯＡＰメッセージであることを示している。

また、この例においても、名前空間の宣言は図１３に示した例と同様である。そして、ＳＯＡＰヘッダには、「コマンドＩＤ」のＸＭＬタグの内容として、応答を生成した送信コマンドのＩＤである「１２３４５」が記述されている。ＳＯＡＰボディには、「異常通知」コマンドに対する応答であることを示すための「異常通知Response」タグが設けられ、その下位のタグに、コマンド応答の内容が記載される。ここでは、異常通知を正常に受信した旨の情報が記載されている。そして、この情報は、コマンド受信側の受信コマンドシートの「出力パラメータ」の項目に記憶されていたものであり、コマンド送信側の送信コマンドシートの「出力パラメータ」の項目に記憶されるものである。

図１５に示すのは、コマンドを記載したパートの第２の例である。
この例においても、図１３の場合と同様に、「X-SOAP-Type」ヘッダの値の「Request」により、このパートに記載されているＳＯＡＰエンベロープがＳＯＡＰリクエストであることを示し、「SOAPAction」ヘッダの情報により、ＳＯＡＰリクエストの内容を示している。

また、「Envelope」タグの属性として、名前空間の宣言を行っている点も、図１３の場合と同様である。そしてここでは、ＳＯＡＰで標準として定義されている名前空間の他に、「http://www.example.com/header」及び「http://www.example.com/client」のＵＲＩで特定される名前空間の宣言を行っている。
ＳＯＡＰヘッダには、「要求ＩＤ」のＸＭＬタグの内容として、このコマンドのＩＤである「９８７６５」が記載されている。そして、ＳＯＡＰボディには、コマンドシートの「メソッド名」に記憶されるべきメソッドを指定する情報として、「センサ値取得」タグが記載され、その下位のタグ「センサＩＤ」の要素として、「入力パラメータ」に記憶されるべき引数が記載されている。ここではセンサ値を取得するセンサのＩＤが記載されている。

図１６に示すのは、受信コマンドに対する応答を記載したパートの例である。
この例においても、図１６の場合と同様に、エンティティヘッダの部分の「X-SOAP-Type」ヘッダの値を「Response」と記載することにより、このパートに記載されているＳＯＡＰメッセージがＳＯＡＰレスポンスであることを示している。
また、この例においても、名前空間の宣言は図１５に示した例と同様である。そして、ＳＯＡＰヘッダには、「コマンドＩＤ」のＸＭＬタグの内容として、応答を生成した受信コマンドのＩＤである「９８７６５」が記述されている。ＳＯＡＰボディには、「センサ値取得」コマンドに対する応答であることを示すための「センサ値取得Response」タグが設けられ、その下位のタグに、コマンド応答の内容が記載される。ここでは、値取得を要求されたセンサの示す値の情報が記載されている。

次に、図８に示した第１のメッセージコントローラ４０の機能を実現するための処理を、図１７乃至図２１のフローチャートを用いて説明する。これ以降の図も含め、各フローチャートに示す処理は、通信装置１０のＣＰＵ１０１が、所要の制御プログラムを実行することによって行うものである。

まず、図１７に、通信装置１０が通信クライアントとして機能する場合の、メッセージの収集及び分配処理の基本動作のフローチャートを示す。
通信装置１０のＣＰＵ１０１は、サーバ／クライアント切り替え部４５ａにより通信装置１０が通信クライアントとして機能する状態となっている場合、送信メッセージ収集部４５が送信コマンドやコマンド応答等の読み出しを試みるタイミングになると、図１７のフローチャートに示す処理を開始する。
そして、まず送信コマンドの収集処理を行う（Ｓ１１）。この処理は、送信コマンドプール４１から通信相手に送信すべき送信コマンドを収集する処理であり、収集したデータからＳＯＡＰエンベロープによるパートを生成する処理を含む。

次に、受信コマンドに対する応答である受信コマンド実行結果の収集処理を行う（Ｓ１２）。この処理は、受信コマンドプール４２から通信相手に送信すべきコマンド応答を収集する処理であり、やはり収集したデータからＳＯＡＰエンベロープによるパートを生成する処理を含む。
その後、ステップＳ１１及びＳ１２の処理で生成したパートを１つにマージして、すべてのパートを含むＨＴＴＰリクエストを生成し（Ｓ１３）、そのＨＴＴＰリクエストを通信相手に送信する（Ｓ１４）。
ここまでの処理において、ステップＳ１１及びＳ１２ではＣＰＵ１０１は送信メッセージ収集部４５として機能し、ステップＳ１３及びＳ１４ではＨＴＴＰリクエスト送信部２１として機能する。

次に、ＨＴＴＰリクエストに対する通信応答として通信相手からＨＴＴＰレスポンスを受信する（Ｓ１５）。そして、受信したＨＴＴＰレスポンスのＨＴＴＰボディを各パートに分割する（Ｓ１６）。ここで、各パートへの分割は、「MIME_boundary」で区分された要素に分割することであり、またここで全てのパートに関して分割する。
そしてその後、分割して得た全てのパートを順に対象として、ステップＳ１７乃至Ｓ１９の処理を繰り返す。この処理においては、まず対象のパートが受信コマンドを記載したパートか否か判断する（Ｓ１７）。そして、受信コマンドであれば受信コマンド登録処理を行う（Ｓ１８）。また、受信コマンドでないときは、送信コマンドに対する応答が記載されたパートであるので、応答通知処理を行う（Ｓ１９）。

ステップＳ１８又はＳ１９の後は、ステップＳ１７に戻り、次のパートを対象として処理を繰り返す。そして、全てのパートについてこれらの処理を行った時点で、図１７のフローチャートに示す処理を終了する。
ここまでの処理において、ステップＳ１５及びＳ１６ではＣＰＵ１０１はＨＴＴＰレスポンス受信部２２として機能し、ステップＳ１７乃至Ｓ１９では受信メッセージ分配部４６として機能する。

次に、図１７のフローチャートに示した処理について、一部分ずつより詳細に示したフローチャートを用いて説明する。
図１８は、図１７のステップＳ１１乃至Ｓ１４の部分の処理をより詳細に示したフローチャートである。

この処理においては、通信装置１０のＣＰＵ１０１はまず、送信コマンドプール４１から、「状態」が「未送信」である送信コマンドシートの「メソッド名」と「入力パラメータ」の内容を、送信すべき送信コマンドとして収集し、「コマンドＩＤ」の内容もそのコマンドのコマンドＩＤとして収集する（Ｓ２１）。「未送信」という「状態」は、コマンドが送信コマンド生成部６１によって生成された後、まだ通信相手に通知されていないことを示すものであるので、これを基準に通信相手に送信すべきコマンドを抽出できる。

その後、ステップＳ２１で収集した全ての送信コマンドを順次対象として、ステップＳ２２乃至Ｓ２４の処理を繰り返す。これらの処理においては、まず対象の送信コマンドとそのコマンドＩＤとを、これらの情報がそれぞれＳＯＡＰボディとＳＯＡＰヘッダとに含まれるＸＭＬ文書に変換し（Ｓ２２）、対象のコマンドに関するパートとなるＳＯＡＰエンベロープを生成する（Ｓ２３）。そして、対象の送信コマンドを記載していた送信コマンドシートの「状態」を「応答待ち」に変更する（Ｓ２４）。「応答待ち」という「状態」は、コマンドを通信相手に通知済であることを示すものである。

これらが全て完了した後、ＣＰＵ１０１は、受信コマンドプール４２から、「状態」が「処理完了」である受信コマンドシートの「出力パラメータ」の内容を、受信コマンドに対するコマンド応答のうち送信すべきものとして収集し、「コマンドＩＤ」の内容も、対応する受信コマンドのコマンドＩＤとして収集する（Ｓ２５）。「処理完了」という「状態」は、受信コマンドに対応する処理が受信コマンド実行結果生成部６２によって実行され、コマンド応答が生成されて受信コマンドプール４２に登録された後、まだ通信相手に通知されていないことを示すものであるので、これを基準に通信相手に送信すべきコマンド応答を抽出できる。

その後、ステップＳ２５で収集した全てのコマンド応答を順次対象として、ステップＳ２６乃至Ｓ２８の処理を繰り返す。これらの処理は、まず対象のコマンド応答とその応答と共に収集したコマンドＩＤとを、これらの情報がそれぞれＳＯＡＰボディとＳＯＡＰヘッダとに含まれるＸＭＬ文書に変換し（Ｓ２６）、対象のコマンド応答に関するパートとなるＳＯＡＰエンベロープを生成する（Ｓ２７）処理である。これらの処理は、対象が異なる点以外はステップＳ２２及びＳ２３の処理と同じものである。そして、次に対象のコマンド応答を記載していた受信コマンドシートの「状態」を「応答済」に変更する（Ｓ２８）。「応答済」という「状態」は、コマンド応答を通信相手に通知済であることを示すものである。

そして、ここまでの処理が全て完了した後、ＣＰＵ１０１は、ステップＳ２３又はＳ２７で生成した各パートをマージし、図１１に示したようなマルチパートのＨＴＴＰリクエストを生成して通信相手に送信する（Ｓ２９）。
なお、ステップＳ２４又はＳ２８で行った「状態」の変更は、実際にこの送信が終了してから行うようにしてもよい。このようにすることにより、通信エラーが発生しても、送信しようとしていたコマンド及びコマンド応答を再度送信の対象とすることができるので、システムの信頼性が向上する。
以上でＨＴＴＰリクエストの送信に関する処理を終了し、図１７のステップＳ１５以降に相当する処理に進む。

図１９は、図１７のステップＳ１５以下の部分の処理をより詳細に示すフローチャートである。図１８のステップＳ２９の次の処理は、この図ではステップＳ３１に該当する。
この処理においては、通信装置１０のＣＰＵ１０１はまず、送信したＨＴＴＰリクエストに対するＨＴＴＰレスポンスの受信を待ち、通信相手からこれを受信する（Ｓ３１）。これを受信すると、そのＨＴＴＰボディを解析して各パートに分割する（Ｓ３２）。
そしてその後、分割して得た各パートを順次対象として、ステップＳ３３乃至ステップＳ４１の処理を繰り返す。

この部分の処理においては、まず、対象のパートが受信コマンドであるか否か判断する（Ｓ３３）。上述したように、ＨＴＴＰレスポンスには、受信コマンドと、送信コマンドに対する応答とが含まれている可能性があるので、対象のパートがこのいずれであるかを判断するのである。そして、この判断は、対象のパートにSOAPActionヘッダが存在するか否か、あるいはX-SOAP-Typeヘッダの内容によって判断することができる。

ステップＳ３３で受信コマンドでなければ、そのパートは送信コマンドに対する応答であるので、そのパートのＸＭＬ文書を解析して送信コマンドシートに登録できる形式のデータに変換し（Ｓ３４）、送信コマンドプール４１からそのコマンド応答に対応する送信コマンドを探索し、その送信コマンドについての送信コマンドシートの「出力パラメータ」の項目にコマンド応答のデータを登録する（Ｓ３５）。なお、コマンド応答には、「コマンドＩＤ」の情報として、送信コマンドの送信時に付したものと同じコマンドＩＤが付してあるものとし、送信コマンドの探索は、この情報をキーとして行うことができる。

データの登録が終わると、データを登録した送信コマンドシートの「状態」を「応答受信済」に変更してその旨を示す（Ｓ３６）。そして、「コマンド実行結果の通知先」に登録されている通知先に、応答があった旨及びその内容を通知する（Ｓ３７）。この通知によって、送信コマンドを生成した送信コマンド生成部６１は、その生成したコマンドに応答があったことを認識し、応答に応じた処理を行うことができる。

例えば、異常通知を発するアプリ６０の送信コマンド生成部６１が通信相手に異常通知を行う旨の送信コマンドを生成した場合、このコマンドが通信相手に送信されると、通信相手はこれを正しく受け取った旨のコマンド応答を返してくる。そして、通信装置１０側では、このコマンド応答を受信すると、ここに含まれるコマンドＩＤを基にどの送信コマンドに対する応答であるかを探索し、見つかった送信コマンドと対応させてそのコマンド応答を登録する。そして、そのコマンドの実行結果通知先として登録されている、異常通知を発するアプリ６０の送信コマンド生成部６１に、応答があった旨及びその内容を通知するのである。

なお、通知先には応答があった旨のみを通知し、この通知を受けた送信コマンド生成部６１が送信コマンドシートを参照して実行結果を取得するようにしてもよい。
このステップＳ３７の処理においては、ＣＰＵ１０１がコマンド応答通知部４３として機能する。
以上のステップＳ３７までの処理が終了すると、次のパートがあればそれを対象としてステップＳ３３からの処理を繰り返す。

一方、ステップＳ３３で受信コマンドであれば、そのパートのＸＭＬ文書を解析して受信コマンドシートに登録できる形式のデータに変換し（Ｓ３８）、その受信コマンドに対応する受信コマンドシートを作成して、コマンドＩＤと共に受信コマンドプールに登録する（Ｓ３９）。ここで、受信コマンドの内容は受信コマンドシートの「メソッド名」及び「入力パラメータ」の項目に登録し、パートに記載されていたコマンドＩＤは「コマンドＩＤ」の項目に登録する。また、「コマンドの通知先」の項目には、「メソッド名」に記憶させたメソッドを実行させる受信コマンド実行結果生成部６２への参照情報を、予め用意してあるメソッドとアプリ６０や受信コマンド実行結果生成部６２との対応関係の情報を参照して登録する。「状態」の初期値は「未処理」であり、「出力パラメータ」の初期値はＮＵＬＬである。

その後、そのコマンドを登録した受信コマンドシートの「状態」を「処理中」に変更してコマンドに係る処理を実行中であることを示し（Ｓ４０）、その受信コマンドシートの「コマンドの通知先」の情報に基づいて受信コマンド実行結果生成部６２を呼び出し、「メソッド名」や「入力パラメータ」のデータを渡して受信コマンドに関する処理を実行させる（Ｓ４１）。なお、受信コマンドに関する処理は、このフローチャートには示していないが、ＣＰＵ１０１が別途実行することになる。
そして、これが完了すると、実行結果を受信コマンドシートの「出力パラメータ」の項目に登録する（Ｓ４２）と共に、受信コマンドシートの「状態」を「処理完了」に変更し、処理が完了したことを示す（Ｓ４３）。
以上のうちステップＳ４０及びＳ４１の処理においては、ＣＰＵ１０１がコマンド通知部４４として機能する。

以上のステップＳ４３までの処理が終了すると、次のパートがあればそれを対象としてステップＳ３３からの処理を繰り返す。
全てのパートについてステップＳ３３乃至Ｓ４３の処理が終了すると、図１９のフローチャートに示した処理は終了する。
なお、ステップＳ４０乃至Ｓ４３の処理は、アプリ側の処理能力を考慮して、図１９のフローチャートに示した処理とは別に非同期で行うようにしてもよい。

図２０に、このようにする場合にＣＰＵ１０１に実行させる処理のフローチャートを示す。
この場合、ＣＰＵ１０１は適当なタイミングで図２０のフローチャートに示す処理を開始する。
そして、この処理においては、まず受信コマンドプールに「状態」が「処理待ち」である受信コマンドシートがあるか否か判断し（Ｓ５１）、なければこのような受信コマンドシートが追加されるまで待機する。そして、このような受信コマンドシートを発見した場合、その１つを処理対象とし、その受信コマンドシートの「状態」を「処理中」に変更する（Ｓ５２）。

その後、その受信コマンドシートの「コマンドの通知先」の情報に基づいて受信コマンド実行結果生成部６２を呼び出し、「メソッド名」や「入力パラメータ」のデータを渡して受信コマンドに関する処理を実行させる（Ｓ５３）。なお、受信コマンドに関する処理は、このフローチャートには示していないが、ＣＰＵ１０１が別途実行することになる。
そして、これが完了すると、実行結果を受信コマンドシートの「出力パラメータ」の項目に登録する（Ｓ５４）と共に、受信コマンドシートの「状態」を「処理完了」に変更し、処理が完了したことを示す（Ｓ５５）。そして、これが完了するとステップＳ５１に戻って処理を繰り返す。

以上の処理は、複数のスレッド（例えば４スレッド）で同時に行うようにしてもよい。処理対象となった受信コマンドシートの「状態」は、「処理待ち」ではないため、複数のスレッドで同時に処理を行っても、１つの受信コマンドシートを重複して処理対象としてしまうことはない。

このような処理を行うようにすれば、任意のタイミングで受信コマンドを実行することができるので、実行に時間のかかるコマンドがあった場合でも、以後の処理が滞ることがない。そして、実行の終了したものから順に、その結果をコマンド応答として通信相手に送信可能な状態にすることができる。

次に、図２１に、通信装置１０が通信サーバとして機能する場合の、メッセージの収集及び分配処理の基本動作のフローチャートを示す。
通信装置１０のＣＰＵ１０１は、サーバ／クライアント切り替え部４５ａにより通信装置１０が通信サーバとして機能する状態となっている場合、通信相手からＨＴＴＰリクエストが送信されてくると、図２１のフローチャートに示す処理を開始する。

この処理においては、まずそのＨＴＴＰリクエストを受信する（Ｓ６１）。そして、受信したＨＴＴＰリクエストがマルチパートのものか否か判断する（Ｓ６２）。この判断は、例えばＨＴＴＰヘッダにおける「Content-Type」の項目に「multipart」の情報が記載されているか否かによって行うことが考えられる。そして、ここでマルチパートであれば、受信したＨＴＴＰリクエストは第１のメッセージコントローラ４０で処理すべきものと判断し、ステップＳ６３以下の処理に進む。

そして、ステップＳ６３以下の処理においては、まず受信したＨＴＴＰリクエストのＨＴＴＰボディを各パートに分割する（Ｓ６３）。ここで、各パートへの分割は、「MIME_boundary」で区分された要素に分割することであり、またここで全てのパートに関して分割する。
そしてその後、分割して得た全てのパートを順に対象として、ステップＳ６４乃至Ｓ６６の処理を繰り返す。この処理においては、まず対象のパートが受信コマンドを記載したパートか否か判断する（Ｓ６４）。そして、受信コマンドであれば受信コマンド登録処理を行う（Ｓ６５）。また、受信コマンドでないときは、送信コマンドに対する応答が記載されたパートであるので、応答通知処理を行う（Ｓ６６）。

ステップＳ６５又はＳ６６の後は、ステップＳ６４に戻り、次のパートを対象として処理を繰り返す。そして、全てのパートについてこれらの処理を行った時点で、次のステップＳ６７に進む。
ここまでの処理において、ＣＰＵ１０１は、ステップＳ６１及びＳ６３ではＨＴＴＰリクエスト受信部３１として機能し、ステップＳ６２では通信要求振り分け部７６として機能し、ステップＳ６４乃至Ｓ６６では受信メッセージ分配部４６として機能する。

次に、ＣＰＵ１０１は、送信コマンドの収集処理を行う（Ｓ６７）。この処理は、送信コマンドプール４１から通信相手に送信すべき送信コマンドを収集する処理であり、収集したデータからＳＯＡＰエンベロープによるパートを生成する処理を含む。
次に、受信コマンドに対する応答である受信コマンド実行結果の収集処理を行う（Ｓ６８）。この処理は、受信コマンドプール４２から通信相手に送信すべきコマンド応答を収集する処理であり、やはり収集したデータからＳＯＡＰエンベロープによるパートを生成する処理を含む。

その後、ステップＳ６７及びＳ６８の処理で生成したパートを１つにマージして、すべてのパートを含むＨＴＴＰレスポンスを生成し（Ｓ６９）、そのＨＴＴＰレスポンスを、ステップＳ６１で受信したＨＴＴＰリクエストに対する通信応答として通信相手に送信して（Ｓ７０）処理を終了する。
ここまでの処理において、ステップＳ６７及びＳ６８ではＣＰＵ１０１は送信メッセージ収集部４５として機能し、ステップＳ６９及びＳ７０ではＨＴＴＰレスポンス送信部３２として機能する。

また、ステップＳ６２でマルチパートでない場合には、受信したＨＴＴＰリクエストは第２のメッセージコントローラ５０で処理すべきものと判断し、ステップＳ７１で後述するような第２のメッセージコントローラ５０による処理を行い、ステップＳ７０でその結果をＨＴＴＰレスポンスに記載して通信相手に送信し、処理を終了する。

以上のうち、ステップＳ６１乃至Ｓ７０の処理の詳細については、通信装置１０が通信クライアントとして機能する場合の処理の説明において図１８及び図１９を用いて説明した処理と同様であるので、詳細な説明は省略する。ただし、ＨＴＴＰリクエストを受信してＨＴＴＰレスポンスを送信することから受信用のステップＳ６１乃至Ｓ６６の処理を送信用のステップＳ６７乃至Ｓ６９の処理よりも先に行う点と、ステップＳ６２の処理が追加された点は、通信クライアントとして機能する場合の処理と異なる。

以上のような各処理を行うことにより、通信装置１０は、通信クライアントとして機能する場合も、通信サーバとして機能する場合も、通信相手に送信すべき動作要求と通信相手から受信した動作要求に対する動作応答とを一括して通信相手に送信することができる。また、通信相手からの動作要求と通信相手に送信した動作要求に対する動作応答とを一括して通信相手から受信して処理することができる。

特に、通信サーバとして機能する場合に、通信相手に対する動作要求をその通信相手からの通信要求に対する通信応答に含めて送信できるので、自身がファイアウォールの外側にある場合でも、ファイアウォールの内側の通信装置に対して動作要求を送信することができる。
また、コマンドやコマンド応答を受信した場合にアプリ６０の送信コマンド生成部６１や受信コマンド実行結果生成部６２に通知できるので、アプリ６０側で各送信コマンド生成部６１や受信コマンド実行結果生成部６２が個別にコマンドプールを検索する必要がなく、このような処理を行うためのリソースを節約して処理負荷を低減できると共に、このような処理を行うプログラムを開発するための労力も節減できる。

なお、ここでは送信すべき全てのパートを全て生成してからマージして送信を行うようにし、また全てのパートを受信してからこれを各パートに分割して処理を行うように説明したが、このようにする必要はない。
送信については、まず始めにＨＴＴＰヘッダを送信し、以後パートを生成するたびにそのパートを順次送信し、全てのパートの送信が完了した時点でその旨のデータを送信するようにしてもよい。このようにしても、これらの課程で送信されるデータが１つのみのＨＴＴＰヘッダを持つ論理的に連続した１つのＨＴＴＰメッセージであれば、１回のセッションで転送でき、ネゴシエーションの処理は１回で済むので、マージして送信する場合と同様な効果を得ることができる。また、送信すべきデータのバッファに必要なメモリ容量を低減できるので、低コストの通信装置で大きなデータを取り扱うことができる。
また、受信側でも、各パートに関する処理を、各パートを受信するたびに順次行うようにすることができる。このようにした場合に容量を低減できることは、送信側の場合と同様である。

ところで、通信装置１０において、メッセージの送受信に第２のメッセージコントローラ５０を用いる場合、ＨＴＴＰリクエストにはコマンドを、ＨＴＴＰレスポンスにはコマンド応答を、それぞれ１つずつ記載して転送することは上述した通りである。
図２２に、このような転送を実現するための第２のメッセージコントローラ５０の構成を示す。この図で用いている線の種類とその意味は、図４の場合と同様である。

図２２に示すように、第２のメッセージコントローラ５０には、コマンド送信部５１，実行結果受信部５２，実行結果振り分け部５３，コマンド受信部５４，コマンド振り分け部５５，実行結果送信部５６を設けている。
そして、コマンド送信部５１は、アプリ６０に含まれる送信コマンド生成部６１が通信相手に対するコマンド（送信コマンド）を生成し、送信先切り替え部７１がそのコマンドの送信に第２のメッセージコントローラ５０の使用を選択した場合に、そのコマンドから送信メッセージを生成し、ＨＴＴＰリクエスト送信部２１に渡して通信相手に送信させる機能を有する。

なお、送信メッセージの形式は、図８に示した送信メッセージ収集部４５が生成するものと同じものでよく、やはりシリアライザを用いて生成できる。また、ＨＴＴＰリクエスト送信部２１に送信させるＨＴＴＰリクエストには、メッセージを１つしか記載しないため、マルチパートにする必要はない。そしてこの場合、ＨＴＴＰヘッダにおける「Content-Type」の内容は、「text/xml」となる。
また、実行結果受信部５２は、ＨＴＴＰレスポンス受信部２２を介して通信相手からＨＴＴＰレスポンスを受け取る機能と、受信したＨＴＴＰレスポンスに含まれるＳＯＡＰレスポンスから、コマンド応答に係るデータを取り出す機能を有する。このデータの取り出しは、デシリアライザを用いて行うことができる。

そして、実行結果振り分け部５３は、そのデータを、コマンド生成元の送信コマンド生成部６１に渡す機能を有する。第２のメッセージコントローラ５０を通信に使用する場合には、コマンド応答に係るＳＯＡＰレスポンスは、送信コマンドに係るＳＯＡＰリクエストを記載したＨＴＴＰリクエストに対するＨＴＴＰレスポンスに記載されて通信相手から送られてくる。従って、コマンドとコマンド応答の対応関係は容易に把握でき、コマンド応答が帰ってくるまでコマンド生成元の送信コマンド生成部６１の情報を記憶しておくようにすれば、実行結果振り分け部５３はこの情報を参照して振り分けを行うことができる。

また、コマンド受信部５４は、ＨＴＴＰリクエスト受信部３１を介して通信相手からＨＴＴＰリクエストを受け取る機能と、受信したＨＴＴＰリクエストに含まれるＳＯＡＰリクエストから、コマンドに係るデータを取り出す機能を有する。なお、コマンド受信部５４が受け取るのは、通信要求振り分け部７６が第２のメッセージコントローラ５０で処理すべきものと判断したＨＴＴＰリクエストである。

そして、コマンド振り分け部５５は、コマンド受信部５４が取り出したコマンドに係るデータを、そのコマンドに係る処理を行わせるべき受信コマンド実行結果生成部６２に渡し、コマンドに係る処理を実行させる機能を有する。コマンドをどの受信コマンド実行結果生成部６２に渡すかは、予め用意してあるメソッドとアプリ６０や受信コマンド実行結果生成部６２との対応関係の情報を参照して決定するようにすればよい。
また、実行結果送信部５６は、受信コマンド実行結果生成部６２が生成したコマンド応答を取得し、そのコマンド応答に係る送信メッセージを生成し、ＨＴＴＰレスポンス送信部３２に渡して通信相手に送信させる機能を有する。この送信メッセージの形式も、図８に示した送信メッセージ収集部４５が生成するものと同じものでよい。
以上のような第２のメッセージコントローラ５０を用いてコマンドやコマンド応答を送受信する場合の処理の流れについては、以下の図２３及び図２４のフローチャートの説明において述べる。

次に、図２３に、通信装置１０において送信コマンド生成部６１が通信相手に送信するコマンドを生成した場合にＣＰＵ１０１が実行する、そのコマンドに関する一連の処理のフローチャートを示す。
この処理においては、まずステップＳ８１で、送信コマンド生成部６１の機能により、アプリ６０の機能に応じた送信コマンドを生成する。そして、ステップＳ８２で、送信先切り替え部７１の機能により、その送信コマンドを、ファイアウォール越しの通信により通信相手に送信するか否かを判断する。

そして、ここでファイウォール越しの通信であれば、第１のメッセージコントローラ４０を用いて通信相手に送信コマンドを送信すべく、ステップＳ８３で送信コマンドを第１のメッセージコントローラ４０の送信コマンドプール４１に登録する。その後、ステップＳ８４及びＳ８５で、通信装置１０が通信クライアントとして機能するか通信サーバとして機能するかに応じて、図１７又は図２１を用いて説明したような、第１のメッセージコントローラ４０によるコマンド送信及びコマンド応答登録の処理を行い、送信コマンドを通信相手に送信すると共に、そのコマンドに対するコマンド応答を通信相手から受信して送信コマンドプール４１に登録する。
この図では破線でステップＳ８６として示すが、ステップＳ８５の処理には、図１９のステップＳ３７に示したような、コマンド応答通知部４３の機能により、送信コマンドを生成した送信コマンド生成部６１にそのコマンド応答を渡す処理も含む。そして、ステップＳ９３で、送信コマンド生成部６１の機能により、渡されたコマンド応答の内容に応じた処理を行って、一連の処理を終了する。

一方、ステップＳ８２でファイアウォール越しの通信でなければ、第２のメッセージコントローラ５０を用いて通信相手に送信コマンドを送信すべく、ステップＳ８７で送信コマンドを第２のメッセージコントローラ５０のコマンド送信部５１に渡す。そして、ステップＳ８８で、コマンド送信部５１の機能により送信コマンドに係るＳＯＡＰリクエストを生成し、ステップＳ８９で、ＨＴＴＰリクエスト送信部２１の機能によりそのＳＯＡＰリクエストをＨＴＴＰリクエストに記載して、コマンドの送信先の通信相手に送信する。

その後、ステップＳ９０で、ＨＴＴＰレスポンス受信部２２の機能により、送信したＨＴＴＰリクエストと対応するＨＴＴＰレスポンスを受信し、ステップＳ９１でそのＨＴＴＰレスポンスを第２のメッセージコントローラ５０の実行結果受信部５２に渡す。
そして、ステップＳ９２で、実行結果受信部５２と実行結果振り分け部５３の機能により、受信したＨＴＴＰレスポンス中のＳＯＡＰレスポンスに記載されているコマンド応答（実行結果）の情報を、対応するコマンドを生成した送信コマンド生成部６１に渡す。そしてこの場合も、ステップＳ９３で、送信コマンド生成部６１の機能により、渡されたコマンド応答に係る処理を行って、一連の処理を終了する。

通信装置１０は、以上のような処理を行うことにより、通信相手の位置に応じて適切な通信プロトコルを選択して、動作要求の送信及びその動作要求に対する動作応答の受信を行うことができる。また、この場合において、送信コマンド生成部６１は、いずれのプロトコルを利用する場合でも共通のものとすることができる。

次に、図２４に、通信装置１０において通信相手から自身に対するコマンドを記載したＨＴＴＰリクエストが送信されてきた場合にＣＰＵ１０１が実行する、そのコマンドに関する一連の処理のフローチャートを示す。
この処理においては、まずステップＳ１０１で、ＨＴＴＰリクエスト受信部３１の機能により、送信されてきたＨＴＴＰリクエストを受信する。そして、ステップＳ１０２で、通信要求振り分け部７６の機能により、そのＨＴＴＰリクエストがマルチパートのものか否か判断する。

そして、マルチパートであれば、受信したＨＴＴＰリクエストを第１のメッセージコントローラ４０を用いて処理すべく、ステップＳ１０３でそのＨＴＴＰリクエストを第１のメッセージコントローラ４０の受信メッセージ分配部４６に渡す。そして、ステップＳ１０４で、図２１を用いて説明したような、第１のメッセージコントローラ４０によるコマンド登録の処理を行い、受信コマンドプール４２に受信したコマンドを登録する。
この図では破線でステップＳ１０５として示すが、ステップＳ１０４の処理には、図１９のステップＳ４１あるいは図２０のステップＳ５３に示したような、コマンド通知部４４の機能により、そのコマンドに係る処理を行う受信コマンド実行結果生成部６２に通知する処理も含む。

一方、ステップＳ１０２でマルチパートでなければ、受信したＨＴＴＰリクエストを第２のメッセージコントローラ５０を用いて処理すべく、ステップＳ１０６でそのＨＴＴＰリクエストを第２のメッセージコントローラ５０のコマンド受信部５４に渡す。そして、ステップＳ１０７で、コマンド受信部５４及びコマンド振り分け部５５の機能により、受信したＨＴＴＰリクエスト中のＳＯＡＰリクエストからコマンド（受信コマンド）を取得し、そのコマンドに係る処理を行う受信コマンド実行結果生成部６２に通知する。
そして、ステップＳ１０５とステップＳ１０７のどちらで通知を行った場合も、ステップＳ１０８に進み、受信コマンド実行結果生成部６２の機能により、受信コマンドの実行に係る処理を行う。

そして、次のステップＳＸで、実行結果振り分け部７５の機能により、通信装置１０が通信相手との間でファイアウォール越しの通信を行っているか否か判断する。ここでファイアウォール越しであれば、第１のメッセージコントローラ４０によりコマンド応答を通信相手に送信させるべく、ステップＳ１０９で、処理の結果を第１のメッセージコントローラ４０に渡し、ステップＳ１１０で、受信コマンド実行結果生成部６２の機能により、その処理の結果を受信コマンドについての出力パラメータとして第１のメッセージコントローラ４０の受信コマンドプール４２に書き込み、その受信コマンドについての受信コマンドシートの「状態」を「処理完了」に変更する。その後、ステップＳ１１１で、図２１を用いて説明したような、第１のメッセージコントローラ４０によるコマンド応答送信の処理を行い、コマンド応答を通信相手に送信して処理を終了する。

一方、ステップＳＸでファイアウォール越しでなければ、ステップＳ１１２で、受信コマンド実行結果生成部６２の機能により、処理の結果を第２のメッセージコントローラ５０の実行結果送信部５６に渡す。そして、ステップＳ１１３で実行結果送信部５６の機能によりコマンド応答に係るＳＯＡＰレスポンスを生成し、ステップＳ１１４でＨＴＴＰレスポンス送信部３２の機能により、生成したＳＯＡＰレスポンスをステップＳ１０１で受信したＨＴＴＰリクエストと対応するＨＴＴＰレスポンスに記載して通信相手に送信し、処理を終了する。

なお、図４の説明で述べたように、実行結果振り分け部７５の機能は、専用のロジックを設けなくても、単に、受信コマンド実行結果生成部６２が、コマンドの通知元のメッセージコントローラにコマンド実行結果を渡すようにすればよい。従って、このような観点からは、図２４のうち破線で囲んだステップＳＸ，Ｓ１０９，Ｓ１１２の部分の処理は、受信コマンド実行結果生成部６２が受信コマンドの通知元にステップＳ１０８での処理の結果を渡す処理であると考えることができる。
通信装置１０は、以上のような処理を行うことにより、通信相手の位置に応じて適切な通信プロトコルを選択して、動作要求の受信及びその動作要求に対する動作応答の送信を行うことができる。また、この場合において、受信コマンド実行結果生成部６２は、いずれのプロトコルを利用する場合でも共通のものとすることができる。

また、通信装置１０が通信相手からＳＯＡＰリクエストを記載したＨＴＴＰレスポンスを受信する場合、すなわち第１のメッセージコントローラ４０を用いて通信し、かつ通信装置１０が通信クライアントとして機能する場合には、受信したＨＴＴＰレスポンスについて、図２４のステップＳ１０３乃至Ｓ１０５及びＳ１０８乃至Ｓ１１０の処理を行うことにより、そこに記載されたコマンドに係る処理を行って応答を返すことができる。

そして、複数の通信装置間で動作要求と動作応答とを送受信させるような通信システムを構築する場合において、各通信装置に以上説明してきたような通信装置１０のような機能を持たせ、自身が通信相手に対してファイアウォールの外側にあるとき、第１のメッセージコントローラ４０を用いて通信させ、自身と前記第２の通信装置との間にファイアウォールがないとき、第２のメッセージコントローラ５０を用いて通信させるようにすれば、通信相手の位置に応じて適切な通信プロトコルを選択して、動作要求の受信及びその動作要求に対する動作応答の送信を行うことができる。

すなわち、通信要求がファイアウォールにより遮断されてしまう場合には、これを回避可能なプロトコルを使用しつつ、通信要求の送信に支障がない場合には、処理負荷の低いプロトコルを使用するので、通信の処理負荷を抑え、処理を効率化することができる。
また、上記のようなプロトコルの切り替えを可能としておくことにより、ファイアウォールとの位置関係を考慮することなく通信装置を配置して通信システムを構築できるため、通信システムの構築作業も効率化することができる。

〔実施形態の変形例：図２５〕
次に、上述した実施形態の種々の変形例について説明する。
まず、上述した実施形態では、通信システムを構成する全ての通信装置が、上述した通信装置１０と同様な機能を有する例について説明したが、このようにすることは必須ではない。例えば、常に間にファイアウォールがないような通信相手としか通信しない装置には、第１のメッセージコントローラ４０を設ける必要はない。通信装置１０は、第２のメッセージコントローラ５０を用いて通信を行えば、第１のメッセージコントローラ４０を持たない通信相手との間でも動作要求や動作応答を送受信することができる。また、同様の理由により、第１のメッセージコントローラ４０を用いた通信において、通信サーバと通信クライアントの双方として機能できるようにすることも、必須ではない。

また、複数の通信装置が共通の通信相手と通信したり、１台の通信装置が複数の通信相手と通信したり、あるいは複数の通信装置がそれぞれ複数の通信相手と通信したりするシステム構成も可能である。
ただし、コマンドやコマンド応答の送信元や送信先が複数考えられる場合には、第１のメッセージコントローラ４０を利用する場合において、これらの発信元と宛先とを把握できるように、これらの情報もコマンドやコマンド応答のメッセージに含め、またコマンドシートにも記載して管理するようにするとよい。

さらに、上述の実施形態には、これら以外の変形を適用することも可能である。例えば、送信コマンドプール４１及び受信コマンドプール４２に登録する送信コマンドシート及び受信コマンドシートを、ＸＭＬドキュメントとして記載するようにしてもよい。「入力パラメータ」をデシリアライズする前のＸＭＬドキュメントとして保存したり、「出力パラメータ」をシリアライズした後のＸＭＬドキュメントとして保存したりしてもよい。

また、送信メッセージ収集部４５によるコマンドやコマンド応答の収集は、必ずしもＨＴＴＰリクエストあるいはＨＴＴＰレスポンスの送信直前に行う必要はない。送信タイミングとは関係なく予め送信メッセージの生成を行って記憶手段に記憶させておき、送信が要求された場合に直ちにメッセージの送信を開始できるようにしておいてもよい。
また、送受信するコマンドやコマンド応答の情報量に制限を設けても構わない。特に、受信するコマンドの情報量を制限するようにすると、受信側がメモリ容量の限られた装置である場合にメモリの使用量を抑えることができる。

また、上述した実施形態においては、ＲＰＣを実現する上位プロトコルとしてＳＯＡＰを採用し、アプリケーションは直接プールを操作してＲＰＣを実現しているが、アプリケーションとプールとの間にＣＯＲＢＡ（Common Object Request Broker Architecture）やＪＡＶＡ（登録商標）ＲＭＩ（Remote Method Invocation）とのブリッジ（メッセージ変換機能）を備えることによってアプリケーションの開発効率をさらに向上させてもよい。
すなわち、上述した実施形態における、通信装置間でのコマンド及びこれに対するコマンド応答のやり取りは、ＸＭＬで記述されたＳＯＡＰメッセージにより行うこととしているが、これに限るものでなく、他の形式で記述されていてもよい。

また、コマンドやコマンド応答をプールに記憶させた際にこれをアプリ６０の送信コマンド生成部６１や受信コマンド実行結果生成部６２に通知する機能を、第１のメッセージコントローラ４０側に設けた例について説明したが、アプリ６０側からプールを探索してこれらを取得する構成としてもよい。また、送信コマンド生成部６１や受信コマンド実行結果生成部６２が生成したコマンドやコマンド応答をプールに登録する機能を、第１のメッセージコントローラ４０側に設け、アプリ６０側ではこれらを単に第１のメッセージコントローラ４０に渡すのみとしてもよい。

また、第１のメッセージコントローラ４０を用いて通信を行う場合と、第２のメッセージコントローラ５０を用いて通信を行う場合とで、動作要求の生成や、動作要求に応じた処理を行うアプリが共通であることは必須ではない。このようにした方が、通信装置１０に記憶させ実行させるアプリの数を低減し、必要な記憶容量を低減できるが、メッセージコントローラとの間でのインタフェースの共通化が難しければ、各メッセージコントローラについて別々にアプリを用意することも考えられる。

また、上述した実施形態において、ＳＯＡＰ標準のプロトコルだけでなく、ＳＯＡＰとＭＩＭＥマルチパートを組み合わせた独自のプロトコルをもこれに加えて採用することにより、ＨＴＴＰリクエスト、或いはＨＴＴＰレスポンスに含まれるＳＯＡＰエンベロープを全く独立したものとして扱うこととしているが、ＳＯＡＰの関連仕様として定義されたＳＯＡＰアタッチメントによって、ＨＴＴＰレスポンスに含まれる第１パートのＳＯＡＰエンベロープに、第２パート以降のＳＯＡＰエンベロープへのリンクを埋め込んでこれらを関連付けて引き渡す構成にしてもよい。

更に、ＳＯＡＰ等の上位プロトコルの下位に位置するデータ通信のプロトコルとして、ここでは実施例としてＨＴＴＰを採用した例について説明したが、この下位プロトコルについても、ＦＴＰ等の他のプロトコルを採用してもよい。
さらにまた、通信システムの構成についても、以上説明したものに限られることはない。

例えば、この発明を適用する通信装置としては、プリンタ，ＦＡＸ装置，デジタル複写機，スキャナ装置，あるいはこれらの機能を備えたデジタル複合機（ＭＦＰ）等の画像処理装置を始め、ネットワーク家電，自動販売機，医療機器，電源装置，空調システム，ガス・水道・電気等の計量システム，汎用コンピュータ，自動車，航空機等の電子装置に通信機能を設けた種々の通信装置が考えられる。

また、通信システムの構成例としては、例えば、図２５に示すような遠隔管理システムも考えられる。
この遠隔管理システムは、インターネット１３に接続して設けた管理装置１２０により、テレビ受像機１１０ａ，冷蔵庫１１０ｂ，ＭＦＰ１１０ｃ，自動販売機１１０ｄ，計量システム１１０ｅ，空調システム１１０ｆ，航空機１１０ｇ，自動車１１０ｈのような被管理装置１１０を管理するシステムである。

そして、ここでいう管理とは、管理対象の機器から情報を取得し、その情報に基づいて何らかの動作を行うことである。この動作としては、例えば被管理装置がＭＦＰであれば、画像形成枚数を集計したり、管理対象の装置からの異常発生通知に対応して適当なサービスセンタに通報を行い、修理担当者の派遣を促したり、管理対象装置のファームウェアのバージョン情報を取得し、そのバージョンが古いものであった場合に新しいファームウェアを送信して更新させたりといった動作が考えられる。また、取得した情報を単に蓄積するのみでもよい。

このような遠隔管理システムにおける、被管理装置１１０と管理装置１２０との間での通信にも、この発明はもちろん適用可能である。また、被管理装置１１０と管理装置１２０との間の通信を仲介装置１１１に仲介させることも考えられるが、このような場合には、被管理装置１１０と仲介装置１１１との間の通信、仲介装置１１１同士の通信、および仲介装置１１１と管理装置１２０等にも、この発明を適用することができる。
この他にも、システムの構成、具体的な処理内容、通信に使用する通信プロトコル等が上述の実施形態で説明したものに限られないことはもちろんである。例えば、通信装置間の通信経路としては、有線、無線を問わず、任意のものを用いることができる。

また、この発明によるプログラムは、コンピュータに通信装置を制御させ、通信装置１０のような装置として機能させるためのプログラムであり、このようなプログラムをコンピュータに実行させることにより、上述したような効果を得ることができる。

このようなプログラムは、はじめからコンピュータに備えるＲＯＭあるいはＨＤＤ等の記憶手段に格納しておいてもよいが、記録媒体であるＣＤ−ＲＯＭあるいはフレキシブルディスク，ＳＲＡＭ，ＥＥＰＲＯＭ，メモリカード等の不揮発性記録媒体（メモリ）に記録して提供することもできる。そのメモリに記録されたプログラムをコンピュータにインストールしてＣＰＵに実行させるか、ＣＰＵにそのメモリからこのプログラムを読み出して実行させることにより、上述した各機能を実現させることができる。
さらに、ネットワークに接続され、プログラムを記録した記録媒体を備える外部機器あるいはプログラムを記憶手段に記憶した外部機器からダウンロードして実行させることも可能である。

以上説明してきたように、この発明の通信装置、通信システム又は通信方法によれば、通信装置間で動作要求を送受信させる場合において、通信の効率を向上させることができる。
従って、この発明を、通信装置間で動作要求を送受信させる通信システムに適用すれば、効率のよい通信が可能な通信システムを構築することができる。

この発明の通信方法を適用する対象であり、この発明の通信システムの実施形態を含む通信システムの構成例を示す図である。 図１に示した通信装置のハードウェア構成を示す図である。 図１に示した通信装置が送受信する動作要求と動作応答の関係を示す図である。 図１に示した通信装置がＲＰＣに関連して備える機能部及び、その各機能部間でのメッセージの受け渡し経路を示す。 図４に示した第１のメッセージコントローラを用いた場合の、通信装置間の通信シーケンスの例を示す図である。

その別の例を示す図である。 図４に示した第２のメッセージコントローラを用いた場合の、通信装置間の通信シーケンスの例を示す図である。 図４に示した第１のメッセージコントローラの機能構成を、その周辺の機能と共に示す図である。 図８に示した送信コマンドプールに記憶させる送信コマンドシートにおけるデータ構造の例を示す図である。 図８に示した受信コマンドプールに記憶させる受信コマンドシートにおけるデータ構造の例を示す図である。

図４に示した第１のメッセージコントローラが通信相手に送信させるＨＴＴＰリクエストの例を示す図である。 図４に示した第１のメッセージコントローラが通信相手から受け取るＨＴＴＰレスポンスの例を示す図である。 図４に示した通信装置が送受信するコマンドを記載したパートの第１の例を示す図である。 そのコマンドに対する応答を記載したパートの例を示す図である。 図４に示した通信装置が送受信するコマンドを記載したパートの第２の例を示す図である。

そのコマンドに対する応答を記載したパートの例を示す図である。 図４に示した通信装置が通信クライアントとして機能する場合の、メッセージの収集及び分配処理の基本動作のフローチャートである。 図１７のステップＳ１１乃至Ｓ１４の部分の処理をより詳細に示すフローチャートである。 図１７のステップＳ１５以下の部分の処理をより詳細に示すフローチャートである。 図１９のステップＳ４０及びＳ４１の処理を非同期で行う場合の処理のフローチャートである。

図４に示した通信装置が通信サーバとして機能する場合の、メッセージの収集及び分配処理の基本動作のフローチャートである。 図４に示した第２のメッセージコントローラの機能構成を、その周辺の機能と共に示す図である。 図４に示した通信装置において送信コマンド生成部が通信相手に送信するコマンドを生成した場合にＣＰＵが実行する、そのコマンドに関する一連の処理のフローチャートである。 同じく通信装置において通信相手から自身に対するコマンドを記載したＨＴＴＰリクエストが送信されてきた場合にＣＰＵが実行する、そのコマンドに関する一連の処理のフローチャートである。 この発明を適用する通信システムの別の構成例を示す図である。

符号の説明

１：ローカル環境、１０:通信装置、２１：ファイアウォール、２２：ＬＡＮ、
２３：インターネット、２０：ＨＴＴＰクライアント機能部、
２１：ＨＴＴＰリクエスト送信部、２２：ＨＴＴＰレスポンス受信部、
３０：ＨＴＴＰサーバ機能部、３１：ＨＴＴＰリクエスト受信部、
３２：ＨＴＴＰレスポンス送信部、４０：第１のメッセージコントローラ、
４１：送信コマンドプール、４２：受信コマンドプール、４３：コマンド応答通知部、
４４：コマンド通知部、４５：送信メッセージ収集部、
４５ａ：サーバ／クライアント切り替え部、４６：受信メッセージ分配部、
５０：第２のメッセージコントローラ、５１：コマンド送信部、
５２：実行結果受信部、５３：実行結果振り分け部、５４：コマンド受信部、
５５：コマンド振り分け部、５６：実行結果送信部、６０：アプリ、
６１：送信コマンド生成部、６２：受信コマンド実行結果生成部、
７１：送信先切り替え部、７２：送信元記憶部、７３：通信応答振り分け部、
７４：送信元記憶部、７５：実行結果振り分け部、７６：通信要求振り分け部

Claims (16)

1. 通信相手の装置である相手先装置との間で動作要求及び該動作要求に対する応答である動作応答を送受信する通信装置であって、
   前記相手先装置から通信要求を受信し、該相手先装置に対してその通信要求に対する通信応答を送信し、前記相手先装置に対する動作要求と、前記相手先装置から受信した動作要求に対する動作応答とを、前記通信応答に含めて一括して前記相手先装置に送信し、前記相手先装置からの動作要求と、前記相手先装置に送信した動作要求に対する動作応答とを、前記通信要求に含まれた状態で一括して前記相手先装置から受信する第１の通信手段と、
   前記相手先装置に対する動作要求を前記相手先装置に対する通信要求に含めて送信し、該相手先装置に対する動作要求に対する動作応答を該送信した通信要求に対する通信応答に含まれた状態で受信し、前記相手先装置からの動作要求を前記相手先装置からの通信要求に含まれた状態で受信し、該相手先装置からの動作要求に対する動作応答を、該受信した通信要求に対する通信応答に含めて送信する第２の通信手段と、
   前記相手先装置に対する動作要求を前記相手先装置に送信する場合に、当該通信装置が前記相手先装置に対してファイアウォールの外側にあるとき、前記第１の通信手段に該送信を行わせ、当該通信装置と前記相手先装置との間にファイアウォールがないとき、前記第２の通信手段に該送信を行わせる第１の切換手段とを備えたことを特徴とする通信装置。
2. 請求項１に記載の通信装置であって、
   前記第１の切換手段は、当該通信装置のアドレス情報と前記相手先装置のアドレス情報とを取得し、これらのアドレス情報に基づいて、動作要求の送信を前記第１の通信手段に行わせるか前記第２の通信手段に行わせるかを決定することを特徴とする通信装置。
3. 請求項１又は２に記載の通信装置であって、
   前記第１の通信手段が受信した動作要求を受信要求プールに記憶させる手段と、
   前記受信要求プールに記憶されている動作要求に係る動作を実行してその実行結果を該動作要求と対応させて前記受信要求プールに記憶させる要求実行手段と、
   前記第１の通信手段により前記相手先装置に送信すべき動作要求を送信要求プールに記憶させる手段とを備え、
   前記第１の通信手段は、前記相手先装置から通信要求を受信した場合に、前記受信要求プールに記憶されている動作要求に係る動作の実行が全て完了しているか否かに関わらず、前記送信要求プールに記憶されている未送信の動作要求と、前記受信要求プールに記憶されている未送信の実行結果を前記相手先装置に伝達するための動作応答とを、該通信要求に対する動作応答に含めて前記相手先装置に送信することを特徴とする通信装置。
4. 請求項１乃至３のいずれか一項に記載の通信装置であって、
   前記第１の通信手段は、前記相手先装置から通信要求を受信し、該相手先装置に対してその通信要求に対する通信応答を送信し、前記相手先装置に対する動作要求と、前記相手先装置から受信した動作要求に対する動作応答とを、前記通信応答に含めて一括して前記相手先装置に送信し、前記相手先装置からの動作要求と、前記相手先装置に送信した動作要求に対する動作応答とを、前記通信要求に含まれた状態で一括して前記相手先装置から受信する第１の通信動作と、前記相手先装置に対して通信要求を送信し、該相手先装置からその通信要求に対する通信応答を受信し、前記相手先装置に対する動作要求と、前記相手先装置から受信した動作要求に対する動作応答とを、前記通信要求に含めて一括して前記相手先装置に送信し、前記相手先装置からの動作要求と、前記相手先装置に送信した動作要求に対する動作応答とを、前記通信応答に含まれた状態で一括して前記相手先装置から受信する第２の通信動作とを選択的に実行する手段であり、
   当該通信装置が前記相手先装置に対してファイアウォールの外側にあるとき、前記第１の通信手段に前記第１の通信動作を実行させ、当該通信装置が前記相手先装置に対してファイアウォールの内側にあるとき、前記第１の通信手段に前記第２の通信動作を実行させる第２の切換手段を備え、
   前記第１の切換手段は、当該通信装置が前記相手先装置に対してファイアウォールの内側にあるときにも、前記第１の通信手段に前記動作要求の送信を行わせることを特徴とする通信装置。
5. 請求項３に記載の通信装置を通信相手とする通信装置であって、
   前記通信相手に対する動作要求を、該通信相手に対する通信要求に含めて送信し、該通信要求に対する通信応答に、前記送信した動作要求に対する動作応答が含まれていない場合でも、該通信応答に含まれている、前記通信相手から当該通信装置への動作要求に係る動作を実行することを特徴とする通信装置。
6. 請求項３に記載の通信装置を通信相手とする通信装置であって、
   通信相手に送信した通信要求に対する通信応答に、前記通信相手からの動作要求が複数含まれていた場合に、該各動作要求を分離し、該各動作要求に係る動作を個別に実行することを特徴とする通信装置。
7. 互いに動作要求及び該動作要求に対する応答である動作応答を送受信する第１及び第２の通信装置を備えた通信システムであって、
   前記第１の通信装置に、
   前記第２の通信装置から通信要求を受信し、該第２の通信装置に対してその通信要求に対する通信応答を送信し、前記第２の通信装置に対する動作要求と、前記第２の通信装置から受信した動作要求に対する動作応答とを、前記通信応答に含めて一括して前記第２の通信装置に送信し、前記第２の通信装置からの動作要求と、前記第２の通信装置に送信した動作要求に対する動作応答とを、前記通信要求に含まれた状態で一括して前記第２の通信装置から受信する第１の通信手段と、
   前記第２の通信装置に対する動作要求を前記第２の通信装置に対する通信要求に含めて送信し、該第２の通信装置に対する動作要求に対する動作応答を該送信した通信要求に対する通信応答に含まれた状態で受信し、前記第２の通信装置からの動作要求を前記第２の通信装置からの通信要求に含まれた状態で受信し、該第２の通信装置からの動作要求に対する動作応答を、該受信した通信要求に対する通信応答に含めて送信する第２の通信手段と、
   前記第２の通信装置に対する動作要求を前記第２の通信装置に送信する場合に、前記第１の通信装置が前記第２の通信装置に対してファイアウォールの外側にあるとき、前記第１の通信手段に該送信を行わせ、前記第１の通信装置と前記第２の通信装置との間にファイアウォールがないとき、前記第２の通信手段に該送信を行わせる第１の切換手段とを備えたことを特徴とする通信システム。
8. 請求項７に記載の通信システムあって、
   前記第１の通信装置の前記切換手段は、前記第１の通信装置のアドレス情報と前記第２の通信装置のアドレス情報とを取得し、これらのアドレス情報に基づいて、動作要求の送信を前記第１の通信手段に行わせるか前記第２の通信手段に行わせるかを決定することを特徴とする通信システム。
9. 請求項７又は８に記載の通信システムであって、
   前記第１の通信装置は、
   前記第１の通信手段が受信した動作要求を受信要求プールに記憶させる手段と、
   前記受信要求プールに記憶されている動作要求に係る動作を実行してその実行結果を該動作要求と対応させて前記受信要求プールに記憶させる要求実行手段と、
   前記第１の通信手段により前記第２の通信装置に送信すべき動作要求を送信要求プールに記憶させる手段とを備え、
   前記第１の通信装置の前記第１の通信手段は、前記第２の通信装置から通信要求を受信した場合に、前記受信要求プールに記憶されている動作要求に係る動作の実行が全て完了しているか否かに関わらず、前記送信要求プールに記憶されている未送信の動作要求と、前記受信要求プールに記憶されている未送信の実行結果を前記第２の通信装置に伝達するための動作応答とを、該通信要求に対する動作応答に含めて前記第２の通信装置に送信することを特徴とする通信システム。
10. 請求項７乃至９のいずれか一項に記載の通信システムであって、
    前記第１の通信装置の前記第１の通信手段は、前記第２の通信装置から通信要求を受信し、該第２の通信装置に対してその通信要求に対する通信応答を送信し、前記第２の通信装置に対する動作要求と、前記第２の通信装置から受信した動作要求に対する動作応答とを、前記通信応答に含めて一括して前記第２の通信装置に送信し、前記第２の通信装置からの動作要求と、前記第２の通信装置に送信した動作要求に対する動作応答とを、前記通信要求に含まれた状態で一括して前記第２の通信装置から受信する第１の通信動作と、前記第２の通信装置に対して通信要求を送信し、該第２の通信装置からその通信要求に対する通信応答を受信し、前記第２の通信装置に対する動作要求と、前記第２の通信装置から受信した動作要求に対する動作応答とを、前記通信要求に含めて一括して前記第２の通信装置に送信し、前記第２の通信装置からの動作要求と、前記第２の通信装置に送信した動作要求に対する動作応答とを、前記通信応答に含まれた状態で一括して前記第２の通信装置から受信する第２の通信動作とを選択的に実行する手段であり、
    前記第１の通信装置は、前記第１の通信装置が前記第２の通信装置に対してファイアウォールの外側にあるとき、前記第１の通信手段に前記第１の通信動作を実行させ、前記第１の通信装置が前記第２の通信装置に対してファイアウォールの内側にあるとき、前記第１の通信手段に前記第２の通信動作を実行させる第２の切換手段を備え、
    前記第１の切換手段は、前記第１の通信装置が前記第２の通信装置に対してファイアウォールの内側にあるときにも、前記第１の通信手段に前記動作要求の送信を行わせることを特徴とする通信システム。
11. 請求項９に記載の通信システムであって、
    前記第２の通信装置が、前記第１の通信装置に対する動作要求を、該第１の通信装置に対する通信要求に含めて送信し、該通信要求に対する通信応答に、前記送信した動作要求に対する動作応答が含まれていない場合でも、該通信応答に含まれている、前記第１の通信装置から前記第２の通信装置への動作要求に係る動作を実行することを特徴とする通信システム。
12. 請求項９に記載の通信システムであって、
    前記第２の通信装置が、前記第１の通信装置に送信した通信要求に対する通信応答に、前記第１の通信装置からの動作要求が複数含まれていた場合に、該各動作要求を分離し、該各動作要求に係る動作を個別に実行することを特徴とする通信システム。
13. 通信相手の装置である相手先装置との間で動作要求及び該動作要求に対する応答である動作応答を送受信する通信装置における通信方法であって、
    前記通信装置が、
    前記相手先装置から通信要求を受信し、該相手先装置に対してその通信要求に対する通信応答を送信し、前記相手先装置に対する動作要求と、前記相手先装置から受信した動作要求に対する動作応答とを、前記通信応答に含めて一括して前記相手先装置に送信し、前記相手先装置からの動作要求と、前記相手先装置に送信した動作要求に対する動作応答とを、前記通信要求に含まれた状態で一括して前記相手先装置から受信する第１の通信手順と、
    前記相手先装置に対する動作要求を前記相手先装置に対する通信要求に含めて送信し、該相手先装置に対する動作要求に対する動作応答を該送信した通信要求に対する通信応答に含まれた状態で受信し、前記相手先装置からの動作要求を前記相手先装置からの通信要求に含まれた状態で受信し、該相手先装置からの動作要求に対する動作応答を、該受信した通信要求に対する通信応答に含めて送信する第２の通信手順と、
    前記相手先装置に対する動作要求を前記相手先装置に送信する場合に、前記通信装置が前記相手先装置に対してファイアウォールの外側にあるとき、前記第１の通信手順により該送信を行い、前記通信装置と前記相手先装置との間にファイアウォールがないとき、前記第２の通信手順により該送信を行うよう前記通信装置の動作を制御する第１の切換手順とを実行することを特徴とする通信方法。
14. 請求項１３に記載の通信方法であって、
    前記第１の切換手順は、前記通信装置のアドレス情報と前記相手先装置のアドレス情報とを取得し、これらのアドレス情報に基づいて、動作要求の送信を前記第１の通信手順により行うか前記第２の通信手順により行うかを決定する手順を有することを特徴とする通信方法。
15. 請求項１３又は１４に記載の通信方法であって、
    前記通信装置が、
    前記第１の通信手順で受信した動作要求を受信要求プールに記憶させる手順と、
    前記受信要求プールに記憶されている動作要求に係る動作を実行してその実行結果を該動作要求と対応させて前記受信要求プールに記憶させる要求実行手順と、
    前記第１の通信手順により前記相手先装置に送信すべき動作要求を送信要求プールに記憶させる手順とをさらに実行し、
    前記第１の通信手順において、前記相手先装置から通信要求を受信した場合に、前記受信要求プールに記憶されている動作要求に係る動作の実行が全て完了しているか否かに関わらず、前記送信要求プールに記憶されている未送信の動作要求と、前記受信要求プールに記憶されている未送信の実行結果を前記相手先装置に伝達するための動作応答とを、該通信要求に対する動作応答に含めて前記相手先装置に送信することを特徴とする通信方法。
16. 請求項１３乃至１５のいずれか一項に記載の通信方法であって、
    前記第１の通信手順は、前記相手先装置から通信要求を受信し、該相手先装置に対してその通信要求に対する通信応答を送信し、前記相手先装置に対する動作要求と、前記相手先装置から受信した動作要求に対する動作応答とを、前記通信応答に含めて一括して前記相手先装置に送信し、前記相手先装置からの動作要求と、前記相手先装置に送信した動作要求に対する動作応答とを、前記通信要求に含まれた状態で一括して前記相手先装置から受信する第１の通信動作と、前記相手先装置に対して通信要求を送信し、該相手先装置からその通信要求に対する通信応答を受信し、前記相手先装置に対する動作要求と、前記相手先装置から受信した動作要求に対する動作応答とを、前記通信要求に含めて一括して前記相手先装置に送信し、前記相手先装置からの動作要求と、前記相手先装置に送信した動作要求に対する動作応答とを、前記通信応答に含まれた状態で一括して前記相手先装置から受信する第２の通信動作とを選択的に実行する手順であり、
    前記通信装置は、
    前記通信装置が前記相手先装置に対してファイアウォールの外側にあるとき、前記第１の通信手順で前記第１の通信動作を実行し、前記通信装置が前記相手先装置に対してファイアウォールの内側にあるとき、前記第１の通信手順で前記第２の通信動作を実行するよう前記通信装置の動作を制御する第２の切換手順を実行し、
    前記第１の切換手順は、前記通信装置が前記相手先装置に対してファイアウォールの内側にあるときにも、前記第１の通信手順により前記動作要求の送信を行よう前記通信装置の動作を制御する手順であることを特徴とする通信方法。

Images