(57)【特許請求の範囲】
【請求項１】
他の装置から受信したメッセージに含まれる要素をアプリケーションが処理可能な形態の情報に変換するメッセージ通信装置であって、
受信したメッセージに含まれる前記要素を記憶するメモリと、
前記要素を前記情報に変換する変換手段と、
前記要素の個数が複数である場合に、該複数の要素のうちの少なくとも一部を、前記変換手段により前記情報に変換せずに保存する保存手段と
を備え、
前記変換手段は、前記情報に変換せずに保存された要素を前記アプリケーションからの要求に応じて前記保存手段から読み出し、前記情報に変換して該アプリケーションに提供する
ことを特徴とするメッセージ通信装置。
【請求項２】
前記保存手段は、前記要素の個数が所定の数よりも多い場合に前記複数の要素のうちの少なくとも一部を、前記変換手段により前記情報に変換せずに保存することを特徴とする請求項１に記載のメッセージ通信装置。
【請求項３】
前記変換手段は、前記要素を前記アプリケーションが処理可能なオブジェクトに変換することを特徴とする請求項１に記載のメッセージ通信装置。
【請求項４】
他の装置から受信したメッセージに含まれる要素をアプリケーションが処理可能な形態の情報に変換し、受信したメッセージに含まれる前記要素を記憶するメモリと前記要素を前記情報に変換する変換手段とを備えるメッセージ通信装置の制御方法であって、
保存手段が、前記要素の個数が複数である場合に該複数の要素のうちの少なくとも一部を、前記変換手段が前記情報に変換せずに前記メモリに保存する保存工程と、
前記変換手段が、前記保存工程において保存された前記要素を前記アプリケーションからの要求に応じて前記メモリから読み出し、前記情報に変換して該アプリケーションに提供する工程と
を有することを特徴とするメッセージ通信装置の制御方法。
【請求項５】
前記保存工程において、前記要素の個数が所定の数よりも多い場合に前記複数の要素のうちの少なくとも一部を、前記変換手段により前記情報に変換せずに保存することを特徴とする請求項４に記載の制御方法。
【請求項６】
前記変換手段は、前記要素を前記アプリケーションが処理可能なオブジェクトに変換することを特徴とする請求項４に記載の制御方法。
【請求項７】
コンピュータを請求項１乃至３のいずれか１項に記載のメッセージ通信装置として機能させるためのコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、メッセージ通信技術に関する。
【背景技術】
【０００２】
現在、ネットワークに接続された複数の装置同士がデータを通信する「Ｗｅｂサービス」が実用化されている。Ｗｅｂサービスでは複数の装置上で動作しているアプリケーション同士がアプリケーションで利用するオブジェクトを交換する。送信側の装置はアプリケーションが送信するオブジェクトをＸＭＬの要素に変換し、Ｗｅｂサービスの標準ブロトコルであるＳＯＡＰメッセージの一部として送信する。そして、受信側の装置は受信したＳＯＡＰメッセージから取り出したＸＭＬの要素をオブジェクトに変換して、そのオブジェクトをアプリケーションが利用する。サービス利用側の装置上のアプリケーションは、サービス提供側のアプリケーションの関数の引数となるオブジェクトを送信し、関数の戻り値のオブジェクトを受信する。また、サービス提供側の装置のアプリケーションは、受信したオブジェクトを引数として自己の関数を実行し、その戻り値のオブジェクトを応答として送信する。Ｗｅｂサービスを利用したデータ通信では、このように、関数呼び出しの形でオブジェクトを交換する方法が一般的である。
【０００３】
前述した関数呼び出しを行うためには、ＳＯＡＰメッセージとして受信したＸＭＬの要素をアプリケーションが利用できる形態であるオブジェクトに変換する必要がある。この変換は特許文献1に記載の方法のように、ＳＯＡＰメッセージに含まれるすべてのＸＭＬの要素をメモリに書き込んでからオブジェクトに変換するのが一般的である。図１（ａ）を用いてこの方式の概要を説明する。図１は受信したＳＯＡＰメッセージの処理方式を比較する図である。ＳＯＡＰメッセージ１０１には複数のＸＭＬの要素１０７が含まれる。ＳＯＡＰメッセージ１０１を受信した通信装置１０２は、受信したＳＯＡＰメッセージ１０１に含まれるすべてのＸＭＬの要素１０７をメモリ１０５に書き込み、変換部１０３がオブジェクト１０８に変換する。図１ではＥ１〜ＥｎがＸＭＬの要素を表し、それをオブジェクトに変換したものをそれぞれＯ１〜Ｏｎで表す。このオブジェクト１０８を用いてアプリケーション１０４は処理を実行する。
【特許文献１】特開２００６−１６４２６４号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
ＳＯＡＰメッセージの形式はインターフェース定義文書などで事前に定義することが可能である。しかし、ＸＭＬの要素数は関数を実行するときに初めて決定される場合も多く、ＳＯＡＰメッセージを受信する側の装置はＳＯＡＰメッセージの大きさをあらかじめ予想できない。ＸＭＬの要素数が多いＳＯＡＰメッセージを一括してオブジェクトに変換する場合、特に組み込み装置のようなメモリ容量の少ない環境ではメモリを圧迫する。その結果、ＳＯＡＰメッセージに含まれるＸＭＬの要素をオブジェクトに変換することができないか、変換できたとしてもメモリ不足でアプリケーションが続行不能となる可能性がある。例えば図１（ａ）に示す形式では、ＳＯＡＰメッセージ１０１に含まれるすべてのＸＭＬの要素１０７をメモリ１０５に書き込んでからオブジェクト１０８に変換する。そのため、ＸＭＬの要素１０７の個数が多い場合には、メモリ１０５を圧迫することになる。
【０００５】
ＸＭＬの要素をオブジェクトに変換せずにアプリケーションがそのまま処理することも可能ではある。例えば図１（ｂ）に示す形式である。ここでは、ＳＯＡＰメッセージ１０１を受信したアプリケーションがＸＭＬの要素１０７を取り出しオブジェクト１０８に変換する。アプリケーション１０４はすぐに使用しないオブジェクト１０９を一時記憶域１０６に退避させることが可能なため、不必要にメモリを圧迫する心配はない。しかしこの場合、ＳＯＡＰメッセージを直接扱う処理やＸＭＬの要素をアプリケーションが処理可能なオブジェクトに変換する処理をそれぞれのアプリケーションで実装しなければならない。そのため、アプリケーションの開発効率が著しく低下してしまう。そこで、本発明は、アプリケーションの開発効率を低下せずにメモリを大量に消費することのないメッセージ通信を提供することを目的とする。
【課題を解決するための手段】
【０００６】
本発明に係るメッセージ通信装置は、他の装置から受信したメッセージに含まれる要素をアプリケーションが処理可能な形態の情報に変換するメッセージ通信装置であって、受信したメッセージに含まれる前記要素を記憶するメモリと、前記要素を前記情報に変換する変換手段と、前記要素の個数が複数である場合に、該複数の要素のうちの少なくとも一部を、前記変換手段により前記情報に変換せずに保存する保存手段とを備え、前記変換手段は、前記情報に変換せずに保存された要素を前記アプリケーションからの要求に応じて前記保存手段から読み出し、前記情報に変換して該アプリケーションに提供することを特徴とする。
【発明の効果】
【０００７】
大量のメモリを消費することがなく、またアプリケーションの開発効率を低下させないメッセージ通信を実現できる。
【発明を実施するための最良の形態】
【０００８】
以下、添付の図面を参照しながら本発明の実施形態について詳細に説明する。なお、以下ではＳＯＡＰメッセージを例として扱うが、メッセージの要素をアプリケーションが利用できる形態のオブジェクトに変換するメッセージ通信で使用されるメッセージであればＳＯＡＰメッセージに限られない。
【０００９】
＜第1の実施形態＞
本実施形態ではＳＯＡＰメッセージを受信した通信装置に本発明を適用した場合を扱う。
【００１０】
図１（ｃ）を用いて本実施形態の概要を説明する。ＳＯＡＰメッセージ１０１を受信した通信装置１０２は取り出したＸＭＬの要素１０７をメモリ１０５に書き込み、変換部１０３がオブジェクト１０８に変換する。メモリに書き込んだＸＭＬの要素１０７の個数が事前に設定した閾値を超えた場合は、ＳＯＡＰメッセージ１０１に含まれる残りのＸＭＬの要素１１０をそのままの形態で一時記憶域１０６に保存する。その後アプリケーションが関数を実行する。アプリケーション１０４が未変換のオブジェクトを必要とした場合は、変換部１０３は一時記憶域１０６に保存されているＸＭＬの要素１１０をメモリ１０５に書き込み、オブジェクト１０８に変換する。これにより、アプリケーション１０４はＸＭＬの要素を直接処理することを必要とせず、自身が処理できる形態であるオブジェクトだけを扱って関数を実行できる。以上が本実施形態の概要である。
【００１１】
ネットワークに接続するメッセージの送受信を行う通信装置２０１の構成の一例とその他のサービスリクエスタ２０２、サービスプロバイダ２０３とを含むメッセージ通信システムの構成を、図２を参照して説明する。図２は本実施形態におけるメッセージ通信システムの構成の一例である。
【００１２】
通信装置２０１はメッセージの送受信を行う通信装置である。サービスリクエスタ２０２はサービスを利用する側であるクライアントとなるコンピュータ装置である。通信装置２０１やサービスプロバイダ２０３にサービスを要求するためのメッセージである要求メッセージを送信し、その返答として応答メッセージを受信する。サービスプロバイダ２０３はサービスを提供する側であるサーバとなるコンピュータ装置である。通信装置２０１やサービスリクエスタ２０２から要求メッセージを受信し、その返答として応答メッセージを送信する。通信装置２０１はサービスリクエスタ２０２とサービスプロバイダ２０３とのどちらの役割として振舞うことも可能である。これらの装置はネットワーク２１０に接続される。ネットワーク２１０はメッセージを通信できればどのような形態でもよく、例えばインターネット、ＷＡＮ、又はＬＡＮなどである。
【００１３】
通信装置２０１はアプリケーション２０４、オブジェクト変換部２０５、メッセージ送信部２０６、メッセージ受信部２０７、一時記憶部２０８、及びメモリ２０９を備える。
【００１４】
アプリケーション２０４は他の装置に含まれるアプリケーションとオブジェクトを交換する。オブジェクト変換部２０５はネットワーク２１０の通信に使用可能な形態であるメッセージに含まれるＸＭＬの要素とアプリケーション２０４が処理可能な形態であるオブジェクトとを相互に変換する。メッセージ送信部２０６はオブジェクト変換部２０５から受け取ったメッセージをネットワーク２１０に向けて送信する。メッセージ受信部２０７はネットワーク２１０から受信したメッセージをオブジェクト変換部２０５に渡す。一時記憶部２０８はオブジェクト変換部２０５から受け取ったメッセージに含まれるＸＭＬの要素の一部をそのままの形態で一時的に保存し、オブジェクト変換部２０５から要求に応じてメモリ２０９に書き込む。メモリ２０９はオブジェクト変換部２０５の変換やアプリケーション２０４の関数の実行に使用される作業領域であり、ＸＭＬの要素やオブジェクトが格納される。
【００１５】
図３は、通信装置２０１のハードウェア構成の一例を示すブロック図である。通信装置２０１は、制御部３０１、入力部３０２、出力部３０３、通信制御部３０４、及び記憶部３０５を備える。
【００１６】
制御部３０１はＣＰＵ、ＲＯＭ、ＲＡＭ、及び周辺機器などを含み、通信装置２０１全体を制御する。ＲＡＭはメモリ２０９として使用される。入力部３０２は、キーボードやマウスなどを接続するためのインターフェースを含み、通信装置２０１への指示や各種入力を制御する。出力部３０３は、ディスプレイなどを接続するためのインターフェースを含み、通信装置２０１の状態や処理結果などの出力を制御する。通信制御部３０４は、ネットワーク２１０との間で通信するためのインターフェースを含み、サービスリクエスタ２０２やサービスプロバイダ２０３などの他の通信装置との通信を制御する。記憶部３０５は大容量記憶装置へのアクセスを制御するインターフェースを含み、データなどを記憶する。記憶部３０５は一時記憶部２０８として使用される。そして、システムバス３１０は上述の各部を接続する。
【００１７】
図４はメッセージ４０１とそのスキーマ定義４０５との一例である。メッセージ４０１はサービスリクエスタ２０２が送信するメッセージであり、ＸＭＬ形式で表現される。本実施形態ではEnvelopeタグがつけられたＳＯＡＰメッセージである。内部にBody要素であるメッセージ本文４０２を含む。メッセージ本文４０２はアプリケーション同士が交換するメッセージの中身である。本実施形態では内部に配列データ４０３を含む。配列データ４０３はＸＭＬの要素４０４を配列の要素として含む。本実施形態では、ＸＭＬの要素４０４であるmyObject要素が連続することで配列であることを表す。配列の要素数はメッセージ４０１ごとに異なるため特に制限されない。
【００１８】
スキーマ定義４０５は、メッセージ４０１を構成するＸＭＬ文書の取りうる構造の定義であるスキーマを記述する。本実施形態ではＸＭＬ  Ｓｃｈｅｍａの形式で表現しているが、メッセージ４０１の構成を定義できればどのような形式であっても本発明を適用可能である。
【００１９】
スキーマ定義部分４０６は矢印４０８で対応を示すとおり、メッセージ本文４０２の取りうる構造を定義する。element要素のname属性でメッセージ本文４０２の要素名を定義する。ここでは「myOperation」が要素名である。またスキーマ定義部分４０７は矢印４０９で対応を示すとおり、配列データ４０３の取りうる構造を定義する。element要素のname属性が配列データ４０３の要素を定義する。ここでは「myObject」が要素名である。さらに、maxOccurs属性が「unbounded」になっていることから、「myObject」を要素に持つ配列を構成することがわかる。
【００２０】
通信装置２０１はメッセージの受信時に図４に示すスキーマ定義４０５を保持しているとする。通信装置２０１の記憶部３０５が事前に保存してもよいし、ネットワーク２１０上の他の装置から配信を受けてもよい。また、保存される形式も例に示す文書の限りではなくアブリケーションコード等の他の形式で同等の情報で保持しておくことも可能である。
【００２１】
本実施形態では、アプリケーション２０４が配列の要素であるオブジェクトを取得するためのオブジェクトである配列用オブジェクト５０１を定義する。図５は配列用オブジェクトの一例を表す模式図である。なお、図５に示す構造は一例であり、これに限定されるものではない。一般にオブジェクトは当該オブジェクトが有する数値や文字列などのデータである「属性」と当該オブジェクトの有する機能である「操作」とを備える。配列用オブジェクト５０１の属性は要素数５０４とファイル参照５０５とを含む。要素数５０４は配列用オブジェクト５０１が表す配列の要素数である。ファイル参照５０５は配列を構成するＸＭＬの要素を格納する一時記憶部２０８に保存された一時保存ファイル５０３への参照である。また、配列用オブジェクト５０１の操作はgetLength５０６とgetItem５０７とを含む。getLength５０６は配列の要素数５０４を取得する関数である。getItem５０７は配列の要素番号を引数とし、配列の要素であるオブジェクトを取得する関数である。すでにオブジェクト変換部２０５により変換済みのオブジェクトが指定された場合はそのオブジェクトをアプリケーション２０４に戻す。まだ変換されていないオブジェクトは一時保存ファイル５０３にＸＭＬの要素として保存されている。そこで、未変換のオブジェクトが指定された場合は、オブジェクト変換部２０５がＸＭＬの要素をオブジェクトに変換してからアプリケーション２０４に戻す。
【００２２】
このように、アプリケーション２０４は必要な配列の要素がＸＭＬの要素の形態であったとしても、配列用オブジェクト５０１を操作するだけで、配列の要素をオブジェクトの形態として取得することが可能となる。
【００２３】
本実施形態におけるメッセージ通信システムにおいて、通信装置２０１がサービスリクエスタからメッセージとして配列データを受信する場合の制御を、図６を用いて説明する。図６は通信装置２０１がメッセージを受信する場合の内部動作の一例を示すフローチャートである。なお、図６に示す内部動作は一例であり、これに限定されるものではない。フローチャートは制御部３０１が記憶部３０５に保存されたコンピュータプログラムを実行することで処理される。
【００２４】
まずステップＳ６０１で、通信装置２０１のメッセージ受信部２０７がメッセージの受信を開始し、順次オブジェクト変換部２０５に渡す。
【００２５】
ステップＳ６０２で、オブジェクト変換部２０５は受信したメッセージのメッセージ本文４０２に含まれる先頭のＸＭＬの要素４０４をメモリ２０９に書き込む。
【００２６】
ステップＳ６０３で、オブジェクト変換部２０５はスキーマ定義４０５を参照してメモリ２０９に書き込んだＸＭＬの要素４０４が配列の要素か否かを判定する。配列の要素でない場合（ステップＳ６０３において「ＮＯ」）は、ステップＳ６０４に移行する。ステップＳ６０４で、オブジェクト変換部２０５はＸＭＬの要素４０４をオブジェクトに変換し、ステップＳ６１３に移行する。
【００２７】
配列の要素である場合（ステップＳ６０３において「ＹＥＳ」）は、ステップＳ６０５に移行する。ステップＳ６０５で、オブジェクト変換部２０５はメモリ２０９上に配列用オブジェクト５０１を作成する。
【００２８】
ステップＳ６０６で、オブジェクト変換部２０５はメモリ２０９に書き込んだＸＭＬの要素４０４をオブジェクトに変換し、変換後の要素をメモリ２０９に書き込む。
【００２９】
ステップＳ６０７で、オブジェクト変換部２０５はメッセージ本文４０２に含まれるＸＭＬの要素４０４をすべてオブジェクトに変換したか否かを判定する。すべて変換した場合（ステップＳ６０７において「ＹＥＳ」）は、ステップＳ６１２に移行する。ステップＳ６１２で、オブジェクト変換部２０５は配列用オブジェクト５０１に配列の要素数５０４を記録する。
【００３０】
未変換のＸＭＬの要素４０４がある場合（ステップＳ６０７において「ＮＯ」）は、ステップＳ６０８に移行する。ステップＳ６０８で、オブジェクト変換部２０５は、これまでに変換したＸＭＬの要素数が事前に設定した閾値を超えたか否かを判定する。閾値を超えていない場合（ステップＳ６０８において「ＮＯ」）は、ステップＳ６０９に移行する。ステップＳ６０９で、オブジェクト変換部２０５は次のＸＭＬの要素４０４をメモリ２０９に書き込み、ステップＳ６０６に戻る。
【００３１】
閾値を超えている場合（ステップＳ６０８において「ＹＥＳ」）、ステップＳ６１０で、一時記憶部２０８は残りのＸＭＬの要素４０４をそのままの形態で一時保存ファイル５０３に保存する。なお、一時記憶部２０８は、このステップＳ６１０において、オブジェクトに変換しなかった要素だけでなく、オブジェクトに変換した要素も一時保存ファイル５０３に保存してもよい。
【００３２】
ステップＳ６１１で、オブジェクト変換部２０５は一時保存ファイル５０３のファイル参照５０５をメモリ２０９上の配列用オブジェクト５０１の属性に記録する。
【００３３】
ステップＳ６１２で、オブジェクト変換部２０５は配列の要素数５０４をメモリ２０９上の配列用オブジェクト５０１の属性に記録する。
【００３４】
ステップＳ６１３で、オブジェクト変換部２０５はアプリケーション２０４にオブジェクトを渡す。メッセージ本文４０２が配列でない場合（ステップＳ６０３において「ＮＯ」）はステップＳ６０４において変換したオブジェクトを渡す。メッセージ本文４０２が配列である場合（ステップＳ６０３において「ＹＥＳ」）はステップＳ６０５において作成した配列用オブジェクト５０１を渡す。
【００３５】
以上でオブジェクト変換部２０５はアプリケーション２０４が処理可能な形態のオブジェクトをアプリケーション２０４に渡すことができる。
【００３６】
次に、図７を用いて、アプリケーション２０４が関数を実行するときの動作を説明する。図７はアプリケーション２０４の関数実行時における通信装置２０１の動作の一例を示すフローチャートである。フローチャートは制御部３０１が記憶部３０５に保存されたコンピュータプログラムを実行することで処理される。ここでは、配列用オブジェクト５０１の処理を中心に説明し、本発明の本質に影響しないアプリケーション２０４固有の動作は説明しない。
【００３７】
ステップＳ７０１で、アプリケーション２０４はオブジェクトを引数とした関数の実行を開始する。
【００３８】
ステップＳ７０２で、アプリケーション２０４は関数の実行で必要となったオブジェクトが配列の要素であるか否かを判定する。配列の要素でない場合（ステップＳ７０２において「ＮＯ」）は、そのオブジェクトはすでにステップＳ６０４でオブジェクトに変換済みである。そこで、そのオブジェクトを使用して関数の実行を継続し、ステップＳ７０７に移行する。
【００３９】
配列の要素である場合（ステップＳ７０２において「ＹＥＳ」）は、ステップＳ７０３に移行する。ステップＳ７０３で、アプリケーション２０４は配列用オブジェクト５０１のgetItem５０７を用いて配列の要素のオブジェクトをオブジェクト変換部２０５に要求する。
【００４０】
ステップＳ７０４で、オブジェクト変換部２０５は要求された配列の要素をオブジェクトに変換済みか否かを判定する。
【００４１】
メモリ２０９上にある要求された要素がオブジェクトに変換済みの場合（ステップＳ７０４において「ＹＥＳ」）は、ステップＳ７０６に移行して、そのオブジェクトをメモリ２０９から読み出し、アプリケーション２０４に渡す。
【００４２】
未変換の場合（ステップＳ７０４において「ＮＯ」）は、ステップＳ７０５に移行する。
【００４３】
ステップＳ７０５で、一時記憶部２０８は対応するＸＭＬの要素４０４を一時保存ファイル５０３からメモリ２０９に書き込み、オブジェクト変換部２０５がオブジェクトに変換し、変換後の要素をメモリ２０９に書き込む。また、一時記憶部２０８は当該ＸＭＬの要素４０４を一時保存ファイル５０３から削除する。ステップＳ７０６で、オブジェクト変換部２０５は変換したオブジェクトをアプリケーション２０４に戻す。
【００４４】
ステップＳ７０７で、アプリケーション２０４は関数が終了したか否かを判定する。終了していない場合（ステップＳ７０７において「ＮＯ」）はステップＳ７０２に戻り、実行を継続する。
【００４５】
終了した場合（ステップＳ７０７において「ＹＥＳ」）はステップＳ７０８で、関数の戻り値のオブジェクトをオブジェクト変換部２０５に戻す。
【００４６】
ステップＳ７０９で、一時記憶部２０８は、一時保存ファイル５０３が存在していれば削除する。そして、戻り値のオブジェクトをＸＭＬの要素４０４に変換して、メッセージに含めてサービスリクエスタ２０２に送信する。
【００４７】
以上より、本実施形態によればアプリケーション２０４にメッセージを直接処理させることなく、メモリ２０９を圧迫しないメッセージ受信が可能となる。
【００４８】
なお、図６に示すステップＳ６０８において、配列の要素数が閾値を越えたか否かを判定しているが、その時点でＸＭＬの要素４０４が使用しているメモリの量を基準に判定してもよい。また、その時点でのメモリの空き容量を基準に判定してもよい。これにより、他の用途で使用しているメモリ２０９の状況に合わせてオブジェクト変換部２０５が使用するメモリ量を判断できる。
【００４９】
また、図６に示すステップＳ６０３において、ＸＭＬの要素４０４が配列の要素であると判定された直後にステップＳ６１０に移行してもよい。これにより、アプリケーション２０４の関数実行前のオブジェクト変換にかかる時間を短縮できる。この場合もアプリケーション２０４がメッセージを直接処理できなくてもよいという利点は損なわれない。
【００５０】
＜第２の実施形態＞
第１の実施形態では、通信装置２０１が配列データを含むメッセージを受信した場合を説明した。本実施形態では通信装置２０１が配列データを含むメッセージを送信する場合を説明する。
【００５１】
図８を用いて本実施形態の概要を説明する。図８は送信するＳＯＡＰメッセージの処理方式を比較する図である。
【００５２】
図８（ａ）に示すように、配列の要素であるオブジェクト８０７をすべてメモリ８０５に書き込んだ後、変換部８０３がＸＭＬの要素８０８に変換するとメモリ８０５を圧迫する可能性がある。そこで、図８（ｂ）に示すとおり、アプリケーション８０４がメモリ８０５に展開したオブジェクトを一つずつ又はメモリを圧迫しない程度の個数をまとめて変換部８０３がＸＭＬの要素８０８に変換し、それを一時記憶領域８０６に保存する。変換済みのオブジェクト８０７はメモリ８０５から削除する。また、アプリケーション８０４は一時記憶領域８０６から適宜オブジェクトをメモリ８０５に書き込む。すべてのオブジェクトがＸＭＬの要素に変換し終わったら、変換部８０３はＸＭＬの要素を含んだＳＯＡＰメッセージ８０１を送信する。
【００５３】
本実施形態におけるシステムの構成やハードウェア構成は第１の実施形態で説明したものと同様のため、説明を省略する。
【００５４】
図９は通信装置２０１がメッセージを送信する場合の内部動作の一例を示すフローチャートである。フローチャートは制御部３０１が記憶部３０５に保存されたコンピュータプログラムを実行することで処理される。
【００５５】
ステップＳ９０１で、アプリケーション２０４は送信するオブジェクトをオブジェクト変換部２０５に渡す。
【００５６】
ステップＳ９０２で、オブジェクト変換部２０５は、受け取ったオブジェクトが配列用オブジェクト５０１であるか否かを判定する。配列用オブジェクト５０１でない場合（ステップＳ９０２において「ＮＯ」）は、ステップＳ９０３に移行する。ステップＳ９０３で、オブジェクト変換部２０５はオブジェクトをＸＭＬの要素４０４に変換し、ステップＳ９１０に移行する。
【００５７】
配列用オブジェクト５０１である場合（ステップＳ９０２において「ＹＥＳ」）は、ステップＳ９０４に移行する。
【００５８】
ステップＳ９０４で、一時記憶部２０８は配列の先頭のオブジェクトをメモリ２０９に書き込む。すでに当該オブジェクトがメモリ２０９上にある場合には、この操作は必要ない。
【００５９】
ステップＳ９０５で、オブジェクト変換部２０５は配列の要素の当該オブジェクトをＸＭＬの要素４０４に変換する。
【００６０】
ステップＳ９０６で、オブジェクト変換部２０５は配列に含まれるオブジェクトをすべて変換したか否かを判定する。
【００６１】
未変換のオブジェクトがある場合（ステップＳ９０６において「ＮＯ」）はステップＳ９０７に移行する。
【００６２】
ステップＳ９０７で、変換済みでまだメモリ２０９上にあるＸＭＬの要素４０４が事前に設定した閾値を超えたか否かを判定する。超えていない場合（ステップＳ９０７において「ＮＯ」）は、ステップＳ９０８で、一時記憶部２０８は次のオブジェクトをメモリ２０９に書き込む。すでに当該オブジェクトがメモリ２０９上にある場合には、この操作は必要ない。その後、ステップＳ９０５に戻る。
【００６３】
超えている場合（ステップＳ９０７において「ＹＥＳ」）は、ステップＳ９０９に移行する。ステップＳ９０９で、一時記憶部２０８は、変換済みのＸＭＬの要素４０４を一時保存ファイル５０３に保存し、保存したＸＭＬの要素４０４をメモリ２０９から削除する。その後、ステップＳ９０８に移行する。
【００６４】
アプリケーション２０４が送信を要求するすべてのオブジェクトを変換した場合（ステップＳ９０５において「ＹＥＳ」）は、ステップＳ９１０に移行する。
【００６５】
ステップＳ９１０で、オブジェクト変換部２０５はＸＭＬの要素４０４を含んだＳＯＡＰメッセージを作成して、メッセージ送信部２０６に渡す。一時保存ファイル５０３にＸＭＬの要素が保存されている場合は、そこからＸＭＬの要素をメモリ２０９に逐次書き込んでＳＯＡＰメッセージを生成する。すべてのＸＭＬの要素をメッセージ送信部２０６に渡し終わったら、配列用オブジェクト５０１と一時保存ファイル５０３とが存在する場合にはそれらを削除する。
【００６６】
以上より、本実施形態によればアプリケーション１０４にメッセージを処理させることなく、メモリ２０９を圧迫しないメッセージ送信が可能となる。
【００６７】
＜その他の実施形態＞
なお、本発明は、複数の機器（例えばホストコンピュータ、インターフェース機器、リーダ、プリンタなど）から構成されるシステムに適用しても、一つの機器からなる装置（例えば、複写機、ファクシミリ装置など）に適用してもよい。
【００６８】
また、本発明の目的は、前述した機能を実現するコンピュータプログラムのコードを記録した記憶媒体を、システムに供給し、そのシステムがコンピュータプログラムのコードを読み出し実行することによっても達成される。この場合、記憶媒体から読み出されたコンピュータプログラムのコード自体が前述した実施形態の機能を実現し、そのコンピュータプログラムのコードを記憶した記憶媒体は本発明を構成する。また、そのプログラムのコードの指示に基づき、コンピュータ上で稼働しているオペレーティングシステム（ＯＳ）などが実際の処理の一部または全部を行い、その処理によって前述した機能が実現される場合も含まれる。
【００６９】
さらに、以下の形態で実現しても構わない。すなわち、記憶媒体から読み出されたコンピュータプログラムコードを、コンピュータに挿入された機能拡張カードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込む。そして、そのコンピュータプログラムのコードの指示に基づき、その機能拡張カードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行って、前述した機能が実現される場合も含まれる。
【００７０】
本発明を上記記憶媒体に適用する場合、その記憶媒体には、先に説明したフローチャートに対応するコンピュータプログラムのコードが格納されることになる。
【図面の簡単な説明】
【００７１】
【図１】受信したＳＯＡＰメッセージの処理方式を比較する図である。
【図２】本発明の実施形態におけるメッセージ通信システムの構成の一例である。
【図３】本発明の実施形態における通信装置２０１のハードウェア構成の一例を示すブロック図である。
【図４】本発明の実施形態におけるメッセージ４０１４０１の一例とそのスキーマ定義４０５の一例である。
【図５】本発明の実施形態における配列用オブジェクトの一例を表す模式図である。
【図６】本発明の第１の実施形態における通信装置２０１がメッセージを受信する場合の内部動作を示すフローチャートである。
【図７】本発明の第１の実施形態におけるアプリケーション２０４の関数実行時における通信装置２０１の動作の一例を示すフローチャートである。
【図８】送信するＳＯＡＰメッセージの処理方式を比較する図である。
【図９】本発明の第２の実施形態における通信装置２０１がメッセージを送信する場合の内部動作の一例を示すフローチャートである。
【符号の説明】
【００７２】
１０１  ＳＯＡＰメッセージ
１０２  通信装置
１０３  変換部
１０４  アプリケーション
１０５  メモリ
１０６  一時記憶域
１０７  ＸＭＬの要素
１０８  オブジェクト
１０９  オブジェクト
１１０  ＸＭＬの要素
【図１】
0005014212.tif 000002
【図２】
0005014212.tif 000003
【図３】
0005014212.tif 000004
【図４】
0005014212.tif 000005
【図５】
0005014212.tif 000006
【図６】
0005014212.tif 000007
【図７】
0005014212.tif 000008
【図８】
0005014212.tif 000009
【図９】
0005014212.tif 000010