(57)【要約】【課題】本発明の課題は、夫々異なる画像形成処理を行う複数のアプリケーションを有する画像形成装置において、接続される機器との間のデータの送受信制御に従ったメッセージ形式を意識せずに該複数のＷｅｂサービスの開発を可能とする画像形成装置を提供することを目的とする。【解決手段】本発明の課題は、ネットワークを介して接続される機器からの要求メッセージに基づいて処理を実行し、その処理結果をＷｅｂサービスとして提供するＷｅｂサービス処理手段と、所定メッセージ交換プロトコルに従って受信した上記要求メッセージを上記Ｗｅｂサービス処理手段によって処理可能な処理要求に変換すると共に、該Ｗｅｂサービス処理手段から出力される上記処理結果を該メッセージ交換プロトコルに従った応答メッセージに変換する変換手段とを有する画像形成装置によって達成される。【選択図】　図３
2004005504.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを介して接続される機器からの要求メッセージに基づいて処理を実行し、その処理結果をＷｅｂサービスとして提供するＷｅｂサービス処理手段と、
所定メッセージ交換プロトコルに従って受信した上記要求メッセージを上記Ｗｅｂサービス処理手段によって処理可能な処理要求に変換すると共に、該Ｗｅｂサービス処理手段から出力される上記処理結果を該メッセージ交換プロトコルに従った応答メッセージに変換する変換手段とを有することを特徴とする画像形成装置。
【請求項２】
上記要求メッセージを該要求メッセージの構成を示す第一データ形式に変換する第一メッセージ変換手段を有し、
上記変換手段は、上記第一データ形式を上記Ｗｅｂサービス処理手段を開発したプログラム言語にて処理可能な第二データ形式に対応させる第一データ形式変換手段を有することを特徴とする請求項１記載の画像形成装置。
【請求項３】
上記第一メッセージ変換手段は、上記要求メッセージから該要求メッセージを構成する要素とその要素に対して設定された値とに基づいて要素木を生成し、その要素木を上記第一データ形式とすることを特徴とする請求項２記載の画像形成装置。
【請求項４】
上記第一データ形式変換手段は、上記要素木の上記要素間の関連を辿ることによって、上記Ｗｅｂサービス処理手段にて処理可能な上記第二データ形式の要素に値を設定することを特徴とする請求項３記載の画像形成装置。
【請求項５】
上記応答メッセージの構成に基づいて、上記機器にて受信可能な記述形式にて該応答メッセージを記述する第二メッセージ変換手段を有し、
上記変換手段は、上記Ｗｅｂサービス処理手段によって出力された上記処理結果を示す第三データ形式を、該処理結果を示す応答メッセージの構成を示す第四データ形式に変換する第二データ形式変換手段を有し、
上記応答メッセージは上記第四データ形式によって示されることを特徴とする請求項４記載の画像形成装置。
【請求項６】
上記第二データ形式変換手段は、上記第三データ形式の要素に上記処理結果として設定された値と上記応答メッセージを構成する複数の要素とに基づいて要素木を生成し、その要素木を上記第四データ形式とすることを特徴とする請求項５記載の画像形成装置。
【請求項７】
複数の上記Ｗｅｂサービス処理手段と、
複数の上記Ｗｅｂサービス処理手段の夫々に対応する複数の上記変換手段とを有することを特徴とする請求項１乃至６のいずれか一項記載の画像形成装置。
【請求項８】
上記要求メッセージ及び上記応答メッセージは、Ｓｉｍｐｌｅ　Ｏｂｊｅｃｔ　Ａｃｃｅｓｓ　Ｐｒｏｔｏｃｏｌに従ってＥｘｔｅｎｓｉｂｌｅ　Ｍａｒｋｕｐ　Ｌａｎｇｕａｇｅによって記述されることを特徴とする請求項１乃至７のいずれか一項記載の画像形成装置。
【請求項９】
上記第二データ形式及び上記第三データ形式は、Ｃ言語によって処理可能な構造体を示すことを特徴とする請求項２乃至８のいずれか一項記載の画像形成装置。
【請求項１０】
所定通信プロトコルに従って受信した処理リクエストが上記要求メッセージによって処理要求を行うメソッドであるか否かを判断するメソッド判断手段と、
上記メソッド判断手段による判断結果に基づいて、上記処理リクエストを上記第一メッセージ変換手段へ分配する分配手段とを有することを特徴とする請求項１乃至９のいずれか一項記載の画像形成装置。
【請求項１１】
上記処理リクエストのヘッダ部を解析してＷｅｂサービスを指定するＷｅｂサービス指定情報を取得するヘッダ解析手段と、
上記ヘッダ解析手段による解析結果に基づいて、上記第一メッセージ変換手段によって変換された上記第一データ形式を引数として対応する上記複数の変換手段の１つを関数コールすることによって、処理を振り分ける振り分け手段とを有することを特徴とする請求項１０記載の画像形成装置。
【請求項１２】
上記処理リクエストのボディ部の上記所定記述形式による要素名を解析してＷｅｂサービスを指定するＷｅｂサービス指定情報を取得するＷｅｂサービス指定情報取得手段と、
上記Ｗｅｂサービス指定情報取得手段による解析結果に基づいて、上記第一メッセージ変換手段によって変換された上記第一データ形式を引数として対応する上記複数の変換手段の１つを関数コールすることによって、処理を振り分ける振り分け手段とを有することを特徴とする請求項１０記載の画像形成装置。
【請求項１３】
上記所定通信プロトコルに従って、ネットワークを介して機器との接続を管理する接続管理手段と、
上記接続管理手段から上記接続の通知を受信後、上記所定通信プロトコルに従って、上記処理リクエストに基づいて上記Ｗｅｂサービス処理手段に処理を実行させ、その処理結果を処理レスポンスとして上記機器へ提供するサービス提供手段とを有することを特徴とする請求項１０記載の画像形成装置。
【請求項１４】
上記所定通信プロトコルに従って通信を制御する通信制御手段と、
上記接続管理手段へ、上記ネットワークを介して処理リクエストを受信したことを通知することによって、上記通信制御手段と上記サービス提供手段との接続を制御する接続制御手段とを有することを特徴とする請求項１３記載の画像形成装置。
【請求項１５】
上記所定通信プロトコルは、Ｈｙｐｅｒｔｅｘｔ　Ｔｒａｎｓｆｅｒ　Ｐｒｏｔｏｃｏｌであることを特徴とする請求項１乃至１４のいずれか一項記載の画像形成装置。
【請求項１６】
複数の上記Ｗｅｂサービス処理手段を有するアプリケーションと、
上記画像形成処理で利用される複数のハードウェア資源を管理すると共に、上記アプリケーションからの利用要求に応じて、該複数のハードウェア資源への利用を制御するコントロールサービスと、
該アプリケーションと該コントロールサービスとを制御するオペレーティングシステムとを有することを特徴とする請求項１記載の画像形成装置。
【請求項１７】
コンピュータが、
ネットワークを介して接続される機器からの要求メッセージに基づいて処理を実行し、その処理結果をＷｅｂサービスとして提供するＷｅｂサービス処理手順と、
所定メッセージ交換プロトコルに従って受信した上記要求メッセージを上記Ｗｅｂサービス処理手順によって処理可能な処理要求に変換すると共に、該Ｗｅｂサービス処理手順から出力される上記処理結果を該メッセージ交換プロトコルに従った応答メッセージに変換する変換手順とを有することを特徴とするＷｅｂサービス提供方法。
【請求項１８】
上記要求メッセージを該要求メッセージの構成を示す第一データ形式に変換する第一メッセージ変換手順を有し、
上記変換手順は、上記第一データ形式を上記Ｗｅｂサービス処理手順を開発したプログラム言語にて処理可能な第二データ形式に対応させる第一データ形式変換手順を有することを特徴とする請求項１７記載のＷｅｂサービス提供方法。
【請求項１９】
上記第一メッセージ変換手順は、上記要求メッセージから該要求メッセージを構成する要素とその要素に対して設定された値とに基づいて要素木を生成し、その要素木を上記第一データ形式とすることを特徴とする請求項１８記載のＷｅｂサービス提供方法。
【請求項２０】
上記第一データ形式変換手順は、上記要素木の上記要素間の関連を辿ることによって、上記Ｗｅｂサービス処理手順にて処理可能な上記第二データ形式の要素に値を設定することを特徴とする請求項１９記載のＷｅｂサービス提供方法。
【請求項２１】
上記所定のプログラム言語にて処理可能であって上記Ｗｅｂサービス手順によるＷｅｂサービスの処理結果を示す第三データ形式を、該処理結果を示す応答メッセージの構成を示す第四データ形式に変換する第二データ形式変換手順と、
上記第四データ形式によって示される上記応答メッセージの構成に基づいて、上記機器にて受信可能な記述形式にて該応答メッセージを記述する第二メッセージ変換手順とを有することを特徴とする請求項１８記載のＷｅｂサービス提供方法。
【請求項２２】
上記第二データ形式変換手順は、上記第三データ形式の要素に上記処理結果として設定された値と上記応答メッセージを構成する複数の要素とに基づいて要素木を生成し、その要素木を上記第四データ形式とすることを特徴とする請求項１８乃至２１のいずれか一項記載のＷｅｂサービス提供方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、Ｗｅｂサービスを提供する画像形成装置に係り、詳しくは、夫々異なる画像形成処理を行う複数のアプリケーションを有する画像形成装置において、接続される機器との間のデータの送受信制御に従ったメッセージ形式を意識せずに該複数のＷｅｂサービスの開発を可能とする画像形成装置を提供するものである。
【０００２】
【従来の技術】
近年、プリンタ、コピー、ファクシミリ、スキャナなどの各装置の機能を１つの筐体内に収納した画像形成装置が一般的に知られている。このような複合型の画像形成装置は、１つの筐体内に表示部、印刷部および撮像部などを設けるとともに、プリンタ、コピー、スキャナおよびファクシミリ装置にそれぞれ対応するアプリケーションを設け、アプリケーションの切り替えによって、当該装置をプリンタ、コピー、スキャナまたはファクシミリ装置として動作させるものである。
【０００３】
【発明が解決しようとする課題】
しかしながら、上記従来の複合型画像形成装置において、ネットワークを介して個々のアプリケーションが画像形成処理をＷｅｂサービスとして提供する場合、そのネットワークプロトコルに従って交換されるメッセージの記述形式を解釈できるように実装されたアプリケーションを改良する必要があった。また、メッセージの記述形式がＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ　Ｍａｒｋｕｐ　Ｌａｎｇｕａｇｅ）である場合、従来の開発方法で開発されたアプリケーションをＷｅｂサービス対応に改良するのも、また、上記従来の複合型画像形成装置に新規にＷｅｂサービス対応のアプリケーションを追加するのも、開発者にＸＭＬの知識が要求されるため、従来の開発方法によってアプリケーションを開発することが困難であった。。
【０００４】
そこで、本発明の課題は、複数のＷｅｂサービスを提供する該画像形成装置と接続される機器とで交換されるメッセージの記述形式に依存することなく、Ｗｅｂサービスとして機能可能なアプリケーションの開発を行うことができる画像形成装置を提供することである。
【０００５】
【課題を解決するための手段】
上記課題を解決するため、本発明は、請求項１に記載されるように、ネットワークを介して接続される機器からの要求メッセージに基づいて処理を実行し、その処理結果をＷｅｂサービスとして提供するＷｅｂサービス処理手段と、所定メッセージ交換プロトコルに従って受信した上記要求メッセージを上記Ｗｅｂサービス処理手段によって処理可能な処理要求に変換すると共に、該Ｗｅｂサービス処理手段から出力される上記処理結果を該メッセージ交換プロトコルに従った応答メッセージに変換する変換手段とを有するように構成される。
【０００６】
このような画像形成装置では、メッセージ交換プロトコルで規定される要求メッセージをＷｅｂサービス処理手段が処理可能な処理要求に変換し、また、Ｗｅｂサービス処理手段の処理結果をメッセージ交換プロトコルで規定される応答メッセージに変換するため、このようなメッセージ交換プロトコルの知識を必要とせずに、Ｗｅｂサービス処理手段を開発することができる。
【０００７】
また、本発明は、請求項２に記載されるように、上記要求メッセージを該要求メッセージの構成を示す第一データ形式に変換する第一メッセージ変換手段を有し、上記変換手段は、上記第一データ形式を上記Ｗｅｂサービス処理手段を開発したプログラム言語にて処理可能な第二データ形式に対応させる第一データ形式変換手段を有するように構成することができる。
【０００８】
このような画像形成装置では、ネットワークを介して接続された機器からの要求メッセージを、Ｗｅｂサービスを実行するＷｅｂサービス処理手段が処理可能なデータ形式に変換されるため、Ｗｅｂサービス手段を開発する開発者は、要求メッセージの記述形式を意識する必要がない。
【０００９】
更に、要求メッセージをデータ形式にするという観点から、本発明は、請求項３に記載されるように、上記第一メッセージ変換手段は、上記要求メッセージから該要求メッセージを構成する要素とその要素に対して設定された値とに基づいて要素木を生成し、その要素木を上記第一データ形式とするように構成することができる。また、本発明は、請求項４に記載されるように、上記第一データ形式変換手段は、上記要素木の上記要素間の関連を辿ることによって、上記Ｗｅｂサービス処理手段にて処理可能な上記第二データ形式の要素に値を設定するように構成することができる。
【００１０】
このような画像形成装置では、Ｗｅｂサービス処理手段が処理可能なデータ形式の形式に変換し易い要素木が生成され、要素木の要素間の関連を辿ることによって、Ｗｅｂサービス手段にて処理可能な第二データ形式の要素に値を容易に設定することができる。
【００１１】
更に、Ｗｅｂサービスの処理結果を機器にて受信可能な応答メッセージにするという観点から、本発明は、請求項５に記載されるように、上記応答メッセージの構成に基づいて、上記機器にて受信可能な記述形式にて該応答メッセージを記述する第二メッセージ変換手段を有し、上記変換手段は、上記Ｗｅｂサービス処理手段によって出力された上記処理結果を示す第三データ形式を、該処理結果を示す応答メッセージの構成を示す第四データ形式に変換する第二データ形式変換手段を有し、上記応答メッセージは上記第四データ形式によって示されるように構成することができる。また、本発明は、請求項６に記載されるように、上記第二データ形式変換手段は、上記第三データ形式の要素に上記処理結果として設定された値と上記応答メッセージを構成する複数の要素とに基づいて要素木を生成し、その要素木を上記第四データ形式とするように構成することができる。
【００１２】
このような画像形成装置では、Ｗｅｂサービス処理手段は、処理結果を機器にて受信可能な応答メッセージに構成する必要がないため、Ｗｅｂサービス処理手段の開発者は、従来からの所定のプログラム言語にて開発することができる。
【００１３】
複数のＷｅｂサービスを提供するという観点から、本発明は、請求項７に記載されるように、複数の上記Ｗｅｂサービス処理手段と、複数の上記Ｗｅｂサービス処理手段の夫々に対応する複数の上記変換手段とを有するように構成することができる。
【００１４】
更に、画像形成装置がネットワークを介して種々のシステム又は機器へＷｅｂサービスを提供するという観点から、本発明は、請求項８に記載されるように、上記要求メッセージ及び上記応答メッセージは、Ｓｉｍｐｌｅ　Ｏｂｊｅｃｔ　Ａｃｃｅｓｓ　Ｐｒｏｔｏｃｏｌに従ってＥｘｔｅｎｓｉｂｌｅ　Ｍａｒｋｕｐ　Ｌａｎｇｕａｇｅによって記述されるように構成することができる。
【００１５】
プログラム開発したＷｅｂサービス手段が汎用的に画像形成装置に搭載できるという観点から、本発明は、請求項９に記載されるように、上記第三データ形式及び上記第四データ形式は、Ｃ言語によって処理可能な構造体を示すように構成することができる。
【００１６】
所定通信プロトコルに従ったメソッドに応じてＷｅｂサービスを実行するという観点から、本発明は、請求項１０に記載されるように、所定通信プロトコルに従って受信した処理リクエストが上記要求メッセージによって処理要求を行うメソッドであるか否かを判断するメソッド判断手段と、上記メソッド判断手段による判断結果に基づいて、上記処理リクエストを上記第一メッセージ変換手段へ分配する分配手段とを有するように構成することができる。
【００１７】
機器から送信された処理リクエストの解析結果に基づいて処理を振り分けるという観点から、本発明は、請求項１１に記載されるように、上記処理リクエストのヘッダ部を解析してＷｅｂサービスを指定するＷｅｂサービス指定情報を取得するヘッダ解析手段と、上記ヘッダ解析手段による解析結果に基づいて、上記第一メッセージ変換手段によって変換された上記第一データ形式を引数として対応する上記複数の変換手段の１つを関数コールすることによって、処理を振り分ける振り分け手段とを有するように構成することができる。また、本発明は、請求項１２に記載されるように、上記処理リクエストのボディ部の上記所定記述形式による要素名を解析してＷｅｂサービスを指定するＷｅｂサービス指定情報を取得するＷｅｂサービス指定情報取得手段と、上記Ｗｅｂサービス指定情報取得手段による解析結果に基づいて、上記第一メッセージ変換手段によって変換された上記第一データ形式を引数として対応する上記複数の変換手段の１つを関数コールすることによって、処理を振り分ける振り分け手段とを有するように構成することができる。
【００１８】
資源を効率的に利用した所定通信制御を行うという観点から、本発明は、請求項１３に記載されるように、上記所定通信プロトコルに従って、ネットワークを介して機器との接続を管理する接続管理手段と、上記接続管理手段から上記接続の通知を受信後、上記所定通信プロトコルに従って、上記処理リクエストに基づいて上記Ｗｅｂサービス処理手段に処理を実行させ、その処理結果を処理レスポンスとして上記機器へ提供するサービス提供手段とを有するように構成することができる。
【００１９】
更に、本発明は、請求項１４に記載されるように、上記所定通信プロトコルに従って通信を制御する通信制御手段と、上記接続管理手段へ、上記ネットワークを介して処理リクエストを受信したことを通知することによって、上記通信制御手段と上記サービス提供手段との接続を制御する接続制御手段とを有するように構成することができる。
【００２０】
また、本発明は、請求項１５に記載されるように、請求項１２記載の画像形成装置において、上記所定通信プロトコルは、Ｈｙｐｅｒｔｅｘｔ　Ｔｒａｎｓｆｅｒ　Ｐｒｏｔｏｃｏｌであるように構成することができる。
【００２１】
画像形成装置であるという観点から、本発明は、請求項１６に記載されるように、複数の上記Ｗｅｂサービス処理手段を有するアプリケーションと、上記画像形成処理で利用される複数のハードウェア資源を管理すると共に、上記アプリケーションからの利用要求に応じて、該複数のハードウェア資源への利用を制御するコントロールサービスと、該アプリケーションと該コントロールサービスとを制御するオペレーティングシステムとを有するように構成することができる。
【００２２】
上記課題を解決するための手段として、本発明は、上記画像形成装置におけるＷｅｂサービス提供方法とすることもできる。
【００２３】
【発明の実施の形態】
以下、本発明の実施の形態を図面に基づいて説明する。
【００２４】
多種の画像形成機能を融合する本発明の実施の一形態に係る画像形成装置（以下、融合機と言う）は、例えば、図１に示すような機能構成を成す。図１は、本発明の一実施例に係る多種の画像形成機能を融合する融合機の機能構成を示すブロック図である。
【００２５】
図１において、融合機１２００は、プロッタ１２０１と、スキャナ１２０２と、その他ハードウェアリソース１２０３などを有するとともに、プラットフォーム１２２０とアプリケーション１２３０とから構成されるソフトウェア群１２１０と、融合機起動部１２４０とを備えている。
【００２６】
融合機起動部１２４０は、融合機１２００の電源投入時に先ず始めに実行され、プラットフォーム１２２０やアプリケーション１２３０を起動する。
【００２７】
プラットフォーム１２２０は、アプリケーション１２３０からの処理要求を解釈して、ハードウェア資源の獲得要求を発生させる下記に示すコントロールサービス１２５０と、一または複数のハードウェア資源の管理をおこない、コントロールサービス１２５０からの獲得要求を調停するシステムリソースマネージャー（ＳＲＭ（Ｓｙｓｔｅｍ　Ｒｅｓｏｕｒｃｅ　Ｍａｎａｇｅｒ）１２２３）と、ＯＳ（Ｏｐｅｒａｔｉｎｇ　Ｓｙｓｔｅｍ）１２２１とを有する。
【００２８】
このコントロールサービス１２５０は、複数のサービスモジュールにより形成され、具体的には、ＳＣＳ（Ｓｙｓｔｅｍ　Ｃｏｎｔｒｏｌ　Ｓｅｒｖｉｃｅ）１２２２と、ＥＣＳ（（Ｅｎｇｉｎｅ　Ｃｏｎｔｒｏｌ　Ｓｅｒｖｉｃｅ）１２２４と、ＭＣＳ（Ｍｅｍｏｒｙ　Ｃｏｎｔｒｏｌ　Ｓｅｒｖｉｃｅ）１２２５と、ＯＣＳ（Ｏｐｅｒａｔｉｏｎ　ｐａｎｅｌ　Ｃｏｎｔｒｏｌ　Ｓｅｒｖｉｃｅ）１２２６と、ＦＣＳ（ＦＡＸ　Ｃｏｎｔｒｏｌ　Ｓｅｒｖｉｃｅ）１２２７と、ＮＣＳ（Ｎｅｔｗｏｒｋ　Ｃｏｎｔｒｏｌ　Ｓｅｒｖｉｃｅ）１２２８と、ＩＭＨ（Ｉｍａｇｉｎｇ　Ｍｅｍｏｒｙ　Ｈａｎｄｌｅｒ）１２２９とがある。なお、このプラットフォーム１２２０は、あらかじめ定義された関数により前記アプリケーションからの処理要求を受信可能とするアプリケーションプログラムインターフェースを有する。
【００２９】
ＯＳ１２２１は、ＵＮＩＸ（登録商標）などのオペレーティング・システムであり、プラットフォーム１２２０並びにアプリケーション１２３０の各ソフトウェアをそれぞれプロセスとして並列実行する。オープンソースのＵＮＩＸ（登録商標）を用いることにより、プログラムの安全性を確保できるとともに、ネットワーク対応可能となり、ソースコードの入手も容易となる。さらに、ＯＳ、ＴＣＰ／ＩＰのロイヤリティが不要であり、アウトソーシングも容易となる。
【００３０】
ＳＲＭ１２２３は、ＳＣＳ１２２２とともにシステムの制御およびリソースの管理をおこなうものであり、スキャナやプロッタなどのエンジン部、メモリ、ＨＤＤファイル、ホストＩ／Ｏ（セントロＩ／Ｆ、ネットワークＩ／Ｆ、ＩＥＥＥ１３９４Ｉ／Ｆ、ＲＳ２３２ＣＩ／Ｆなど）のハードウェア資源を利用する上位層からの要求にしたがって調停をおこない、実行制御する。
【００３１】
具体的には、このＳＲＭ１２２３は、要求されたハードウェア資源が利用可能であるかどうか（他の要求により利用されていないかどうか）を判断し、利用可能であれば要求されたハードウェア資源が利用可能である旨を上位層に伝える。また、上位層からの要求に対してハードウェア資源の利用スケジューリングをおこない、要求内容（たとえば、プリンタエンジンによる紙搬送と作像動作、メモリ確保、ファイル生成など）を直接実施するようにしてもよい。
【００３２】
ＳＣＳ１２２２は、アプリ管理（機能１）、操作部制御（機能２）、システム画面表示（ジョブリスト画面、カウンタ表示画面など）（機能３）、ＬＥＤ表示（機能４）、リソース管理（機能５）、割り込みアプリ制御（機能６）等の複数の機能を行う。具体的には、アプリ管理（機能１）では、アプリの登録と、その情報を他のアプリに通知する処理をおこなう。操作部制御（機能２）では、アプリの操作部使用権の排他制御をおこなう。システム画面表示（機能３）では、操作部使用権を持つアプリからの要求内容に応じて、エンジン部の状態に対応する警告画面の表示をおこなう。ＬＥＤ表示（機能４）では、警告ＬＥＤ、アプリキーなどのシステムＬＥＤの表示制御をおこなう。リソース管理（機能５）では、アプリがＥＣＳを使ってジョブを実行するにあたって、排他しなければならないエンジンリソース（スキャナ、ステープルなど）の排他制御のためのサービスをおこなう。割り込みアプリ制御（機能６）では、特定のアプリを優先動作させるための制御及びサービスをおこなう。
【００３３】
ＥＣＳ１２２４は、プロッタ１２０１、スキャナ１２０２、その他ハードウェアリソース１２０３などのエンジン部を制御するものであり、画像読み込みと印刷動作、状態通知、ジャムリカバリなどをおこなう。
【００３４】
ＭＣＳ１２２５は、メモリ制御をおこなうものであり、具体的には、画像メモリの取得および開放、ハードディスク装置（ＨＤＤ）の利用、画像データの圧縮および伸張などをおこなう。
【００３５】
ＯＣＳ１２２６は、オペレータと本体制御間の情報伝達手段となる操作パネルを制御するモジュールであり、オペレータのキー操作イベントを本体制御に通知する処理、各アプリがＧＵＩを構築するためのライブラリ関数を提供する処理、構築されたＧＵＩ情報をアプリ別に管理する処理、操作パネル上への表示反映処理などをおこなう。
【００３６】
ＦＣＳ１２２７は、システムコントローラの各アプリ層からＰＳＴＮ／ＩＳＤＮ網を使ったファクシミリ送受信、ＢＫＭ（バックアップＳＲＡＭ）で管理されている各種ファクシミリデータの登録／引用、ファクシミリ読み取り、ファクシミリ受信印刷、融合送受信をおこなうためのＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ　Ｐｒｏｇｒａｍ　Ｉｎｔｅｒｆａｃｅ）を提供する。
【００３７】
ＮＣＳ１２２８は、ネットワークＩ／Ｏを必要とするアプリケーションに対して共通に利用できるサービスを提供するためのモジュール群であり、ネットワーク側から各プロトコルによって受信したデータを各アプリケーションに振り分けたり、アプリケーションからデータをネットワーク側に送信する際の仲介をおこなう。
【００３８】
本実施例において、ＮＣＳ１２２８は、複数のプロトコルのうちｈｔｔｐ（Ｈｙｐｅｒｔｅｘｔ　Ｔｒａｎｓｆｅｒ　Ｐｒｏｔｏｃｏｌ）デーモンによって、インターネットを介して接続されるネットワーク機器とのデータ通信をＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ　Ｔｒａｎｓｆｅｒ　Ｐｒｏｔｏｃｏｌ）で制御し、ＨＴＴＰリクエストヘッダで指定される処理に必要な複数のＷｅｂサービスを関数コールによって起動し、その複数のＷｅｂサービスによる処理結果をＨＴＴＰレスポンスで該ネットワーク機器へ通知する。Ｗｅｂサービスは、例えば、ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ　Ｍａｒｋｕｐ　Ｌａｎｇｕａｇｅ）によって記述されたメッセージに従って処理を行う。
【００３９】
ＩＭＨ１２２９は、イメージデータを仮想メモリ領域（ユーザー仮想空間）から物理メモリへマップする。プロセスの起動に応じて、システムコールを行ない、プロセス用の仮想メモリ領域をマップしたり、マップした仮想メモリ領域をプロセスの終了時に開放する処理等を行う。
【００４０】
アプリケーション１２３０は、ページ記述言語（ＰＤＬ）、ＰＣＬおよびポストスクリプト（ＰＳ）を有するプリンタ用のアプリケーションであるプリンタアプリ１２１１と、コピー用アプリケーションであるコピーアプリ１２１２と、ファクシミリ用アプリケーションであるファックスアプリ１２１３と、スキャナ用アプリケーションであるスキャナアプリ１２１４と、ネットファイル用アプリケーションであるネットファイルアプリ１２１５と、工程検査用アプリケーションである工程検査アプリ１２１６と、配信用アプリケーションである配信アプリ１２１７と、実行した処理結果をＷｅｂサービスとして提供するＷｅｂサービスアプリ１２１８とを有する。各アプリケーション１２１１〜１２１８は、プラットフォーム１２２０上の各プロセスを利用して動作実行し得るため、画面制御、キー操作制御およびジョブ生成などをおこなう画面表示制御プログラムがその主体となる。なお、ＮＣＳ１２２８により接続されたネットワークを介して新たなアプリケーションをネットワーク経由で搭載することもできる。また、各アプリケーションはアプリケーションごとに追加または削除することができる。
【００４１】
ここで、Ｗｅｂサービスアプリ１２１８とは、ＮＣＳ１２２８によって通知されるＨＴＴＰリクエスト対応する処理を実行するアプリケーションであって、その処理結果は、ＨＴＴＰレスポンスとしてＮＣＳ１２２８によってＨＴＴＰリクエストを行ったネットワーク機器へ提供される。
【００４２】
このように、融合機１２００は、各アプリで共通的に必要となる処理をプラットフォーム１２２０で一元的に処理する。
【００４３】
次に、融合機１２００のハードウェア構成について説明する。図２は、図１に示す融合機のハードウェア構成を示すブロック図である。図２に示すように、この融合機１２００は、オペレーションパネル１３１０と、ＦＣＵ（ファックスコントロールユニット）１３２０と、プロッタ１２０１、スキャナ１２０２及びその他ハードウェアで構成されるエンジン部１３５０と、コントローラ１３００のＡＳＩＣ１３０１とをＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ　Ｃｏｍｐｏｎｅｎｔ　Ｉｎｔｅｒｃｏｎｎｅｃｔ）バス等で接続した構成となる。ＦＣＵ１３２０は、受信したファックスデータを格納するための不揮発性メモリ１３２１と、ＦＣＵ１３２０内での時間を計測するためのＲＴＣ（Ｒｅａｌ　Ｔｉｍｅ　Ｃｌｏｃｋ）１３２２とを有し、通常Ｇ３規格に従ってファックスデータの送受信を行う。ＦＣＵ１３２０は、オプションとして更にＧ３規格とＧ４規格とを搭載しても良い。
【００４４】
コントローラ１３００は、ＡＳＩＣ１３０１にＭＥＭ−Ｃ１３０２、ＨＤＤ（Ｈａｒｄ　Ｄｉｓｋ　Ｄｒｉｖｅ）１３０３などを接続するとともに、このＡＳＩＣ１３０１とＣＰＵ１３０４とをＣＰＵチップセットのＮＢ１３０５を介して接続している。このように、ＮＢ１３０５を介して接続する理由は、ＣＰＵ１３０４自体のインターフェイスが公開されていないためである。
【００４５】
ここで、このＡＳＩＣ１３０１とＮＢ１３０５は、単にＰＣＩを介して接続されているのではなく、ＡＧＰ１３０８を介して接続されている。このようにＡＧＰ１３０８を介して接続することとした理由は、この融合機１２００がプラットフォーム１２２０やアプリケーション１２３０を形成する複数のプロセスを実行制御する関係上、これらを低速のＰＣＩで接続したのでは、パフォーマンスが低下するからである。
【００４６】
ＣＰＵ１３０４は、融合機１２００の全体制御をおこなうものであり、具体的には、ＯＳ１２２１上でプラットフォーム１２２０を形成するＳＣＳ１２２２、ＳＲＭ１２２３、ＥＣＳ１２２４、ＭＣＳ１２２５、ＯＣＳ１２２６、ＦＣＳ１２２７、ＮＣＳ１２２８をそれぞれプロセスとして起動して実行させるとともに、アプリケーション１２３０を形成するプリンタアプリ１２１１、コピーアプリ１２１２、ファックスアプリ１２１３、スキャナアプリ１２１４、ネットファイルアプリ１２１５、工程検査アプリ１２１６、配信アプリ１２１７、Ｗｅｂサービスアプリ１２１８を起動して実行させる。
【００４７】
ＮＢ１３０５は、ＣＰＵ１３０４とＭＥＭ−Ｐ１３０６、ＳＢ１３０７、ＡＳＩＣ１３０１とを接続するためのブリッジであり、ＭＥＭ−Ｐ１３０６は、融合機の描画用メモリなどとして用いるシステムメモリであり、ＭＥＭ−Ｃ１３０２は、コピー用画像バッファ、符号バッファとして用いるローカルメモリであり、ＡＳＩＣ１３０１は、画像処理用のハードウェア要素を有する画像処理用途向けのＩＣである。
【００４８】
ＮＢ１３０５は、ＰＣＩバスを介してＳＢ１３０７と接続する他、ネットワーク通信を制御するＮＩＣ（Ｎｅｔｗｏｒｋ　Ｉｎｔｅｒｆａｃｅ　Ｃａｒｄ）１３１１と、パーソナルコンピュータと接続し大容量の画像データの送受信を可能とするＵＳＢ（Ｕｎｉｖｅｒｓａｌ　Ｓｅｒｉａｌ　Ｂｕｓ）１３１２及びＩＥＥＥ１３９４１３１３と、パラレルケーブルによって接続可能なセントロニクス１３１４と接続する。ＳＢ１３０７は、ＮＢ１３０５とＲＯＭ、ＰＣＩデバイス、周辺デバイスとを接続するためのブリッジである。ＳＢ１３０７は、コントローラ１３００での時間を計測するＲＴＣ（Ｒｅａｌ　Ｔｉｍｅ　Ｃｌｏｃｋ）１３２３を有する。
【００４９】
ＨＤＤ１３１０は、画像データの蓄積、プログラムの蓄積、フォントデータの蓄積、フォームの蓄積を行うためのストレージであり、オペレーションパネル１３１０は、操作者からの入力操作の受け付け並びに操作者に向けた表示をおこなう操作部である。
【００５０】
したがって、ＡＳＩＣ１３０１には、ＭＥＭ−Ｃ１３０２を接続するためのＲＡＭインターフェイスと、ＨＤＤ１３１０を接続するためのハードディスクインターフェースが設けられ、これらの記憶部に対して画像データの入出力をおこなう場合には、入出力先がＲＡＭインターフェイスまたはハードディスクインターフェースに切り替えられる。
【００５１】
ＡＧＰ１３０８は、グラフィック処理を高速化するために提案されたグラフィックスアクセラレーターカード用のバスインターフェイスであり、システムメモリに高スループットで直接アクセスすることにより、グラフィックスアクセラレーターカードを高速にする。
【００５２】
次に、上記構成を有する融合機１２００において、ＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ　Ｍａｒｋｕｐ　Ｌａｎｇｕａｇｅ）によるＳＯＡＰ（Ｓｉｍｐｌｅ　Ｏｂｊｅｃｔ　Ａｃｃｅｓｓ　Ｐｒｏｔｏｃｏｌ）に従ったＷｅｂサービスを提供可能とする構成について詳述する。Ｗｅｂサービスファンクションは、例えば、Ｃ言語などのプログラム言語で記述されたソフトウェア（アプリケーション）である。ＳＯＡＰに従って記述されるＸＭＬによる処理内容をメッセージとしてＷｅｂサービスファンクションが理解できるように、構文の異なるＸＭＬとプログラム言語との間をハンドリングする処理部（ハンドラ）が必要となる。以下に、印刷する印刷Ｗｅｂサービス、文書リストを取得する文書リスト取得Ｗｅｂサービス、文書情報を取得する文書情報取得Ｗｅｂサービスを例として、図３で説明する。
【００５３】
図３は、Ｗｅｂサービスを実現するための構成例を示す図である。図３において、印刷Ｗｅｂサービス、文書リスト取得Ｗｅｂサービス、文書情報取得Ｗｅｂサービスが、Ｗｅｂサービスアプリ１２１８にて提供される場合を示す。これらＷｅｂサービスは、アプリケーション１２３０の別の機能としてＷｅｂサービスアプリ１２１８から独立した構成としても良い。図３中、図１に示す融合機１２００の機能構成のうち主要な機能構成のみが図示され、他の機能構成は省略される。
【００５４】
図３において、Ｗｅｂサービスを実現するために、コントロールサービス１２５０とＷｅｂサービスアプリ１２１８との間に、接続される機器との間のデータの送受信を制御する中間層が構成される。
【００５５】
コントロールサービス１２５０は、Ｗｅｂサービスアプリ１２１８によるＷｅｂサービスを実現する構成部分として、ＥＣＳ１２２４と、ＭＣＳ１２２５と、ＮＣＳ１２２８とを有する。ＮＣＳ１２２８は、ＨＴＴＰを制御するＨＴＴＰデーモン２と、ＨＴＴＰデーモン２とＷｅｂサービスアプリ１２１８との接続処理の仲介をする要求仲介デーモン７とを有する。
【００５６】
また、中間層１２５５は、接続される機器との間のデータの送受信制御を吸収する構成部分として、シーケンス制御ライブラリ１００と、ＸＭＬライブラリ１１０と、ＳＯＡＰライブラリ１２０と、ジョブ管理部３１０と、ファイル管理部３１１とを有する。シーケンス制御ライブラリ１００は、更に、ＨＴＴＰ接続管理部１０１と、ＨＴＴＰサービス実行部１０２と、ＰＯＳＴメソッド分配処理部１０５とを有する。ＸＭＬライブラリ１１０は、ＸＭＬ処理部１１５と、ＸＭＬプロセッサ１１６と、ＸＭＬシリアライザ１１７とを有する。ＳＯＡＰライブラリ１２０は、ＳＯＡＰアクション振分処理部１２１を有する。
【００５７】
更に、Ｗｅｂサービスアプリ１２１８は、Ｗｅｂサービスを実現するための構成部分として、要素木解析・生成ハンドラ２００と、Ｗｅｂサービスファンクション（ＷＳＦ）３００とを有する。要素木解析・生成ハンドラ２００は、機器間におけるＳＯＡＰに従ったメッセージのデータ形式による構文を解析し、Ｗｅｂサービスファンクション３００にて処理可能なデータ形式に変換する処理部であって、複数の要素木解析・生成ハンドラを有し、例えば、印刷ハンドラ２０１と、文書リスト取得ハンドラ２０２と、文書情報取得ハンドラ２０３とを有する。
【００５８】
Ｗｅｂサービスファンクション３００は、複数のＷｅｂサービスファンクションを有し、例えば、印刷機能３０１と、文書リスト取得機能３０２と、文書情報取得機能３０３とを有する。この場合、印刷ハンドラ２０１は、印刷機能３０１に対する処理の内容を示すＳＯＡＰに従ったメッセージのデータ形式を構文解析し、印刷機能３０１が処理可能なデータ形式に変換して印刷機能３０１に処理を要求する。また、印刷ハンドラ２０１は、印刷機能３０１からの応答をＳＯＡＰに従ったデータ形式にてメッセージとして生成する。文書リスト取得ハンドラ２０２及び文書情報取得ハンドラ２０３は、夫々、文書リスト取得機能３０２及び文書情報取得機能３０３に対して同様の処理を行う。
【００５９】
印刷機能３０１は、入力パラメータとしてファイルＩＤと部数を受け取り、ジョブ管理部ファイルＩＤと部数を指定して印刷要求をジョブ管理部３１０に発行する。ジョブ管理部３１０から受け取ったリクエストＩＤを出力パラメータとして返す。文書リスト取得機能３０２は、ファイル管理部３１１にファイルリストを要求し、ファイル管理部３１１から受け取ったＩＤのリストを出力パラメータとして返す。文書情報取得機能３０３は、入力パラメータとしてファイルＩＤを受け取り、ファイル管理部３１１にファイルＩＤを指定してファイル情報を要求する。ファイル管理部３１１から受け取ったファイル情報を出力パラメータとして返す。
【００６０】
ジョブ管理部３１０は、ジョブのキュー及び実行結果を管理する。また、ＥＣＳ１２２４及びＭＣＳ１１２５と通信して蓄積文書の印刷処理を実行する。ファイル管理部３１１は、ＭＣＳ１２２５と通信してファイル情報を取得する。
【００６１】
以下、ＨＴＴＰリクエストを受信してからＨＴＴＰレスポンスを送信するまでの処理について図４及び図５を参照しつつ説明する。図４及び図５は、ＳＯＡＰによるＷｅｂサービスの提供処理について説明するフローチャート図である。
【００６２】
ＮＣＳ１２２８のＨＴＴＰデーモン２がネットワーク１５からの接続要求を受信する（ステップＳ１１００）。その接続要求は要求仲介デーモン７を介してＷｅｂサービスアプリ１２１８のＨＴＴＰ接続管理部１０１に通知される。その後、ＨＴＴＰ接続管理部１０１は、その接続要求をＨＴＴＰに従ってサービスを提供するＨＴＴＰサービス実行部１０２に通知する。通知を受けたＨＴＴＰサービス実行部１０２は、ＨＴＴＰデーモン２に接続を行い、ＨＴＴＰリクエストを取得する。このような制御をＮＣＳ１２２８で行うことにより、必要時のみＨＴＴＰによる通信制御をすることができる。よって、常時ＨＴＴＰ通信制御をする場合に比べて、通信制御に必要な資源を効果的に利用することができる。
【００６３】
ＨＴＴＰサービス実行部１０２は、ネットワーク１５を介して受信したＨＴＴＰリクエストからデータ送信方法を示すＨＴＴＰメソッドを解析して、ＧＥＴメソッドであるか否かをチェックする（ステップＳ１１０１）。ＧＥＴメソッドである場合、ＧＥＴメソッドによるＷｅｂサービスの提供を実行する（ステップＳ１１０２）。つまり、ＳＯＡＰによるＷｅｂサービス以外のＷｅｂサービスの提供を行う。
【００６４】
一方、ＧＥＴメソッドでない場合、ＰＯＳＴメソッドであるか否かをチェックする（ステップＳ１１０３）。ＰＯＳＴメソッドでない場合、ステップＳ１１０７へ進み、エラー処理を行い、ＳＯＡＰによるＷｅｂサービスの提供処理を終了する。ＰＯＳＴメソッドである場合、ＰＯＳＴメソッド分配処理部１０５をコールする。ＰＯＳＴメソッド分配処理部１０５は、ＨＴＴＰリクエストヘッダ情報を解析し、ＨＴＴＰボディの記述形式がＸＭＬであることを確認する（ステップＳ１１０４）。つまり、ＨＴＴＰレスポンスヘッダのＣｏｎｔｅｎｔ−Ｔｙｐｅがｔｅｘｔ／ｘｍｌを指定しているか否かを判断する。ＸＭＬでない場合、ステップＳ１１０７へ進み、エラー処理を行う。一方、ＸＭＬである場合、ＸＭＬコンテンツハンドラ１１１をコールする。
【００６５】
ＸＭＬ処理部１１５は、ＰＯＳＴメソッドハンドラとして、ＸＭＬプロセッサ１１６によって、ＨＴＴＰボディのＸＭＬの構文を解析し、ＸＭＬで記述されるタグ間の関連を木構造で示すリクエストの要素木を作成する（ステップＳ１１０５）。構文解析結果がエラーか否かを判断する（ステップＳ１１０６）。構文解析結果がエラーの場合、ステップＳ１１０７へ進み、エラー処理を行う。一方、構文解析結果が正常の場合、図５のステップＳ１１０９へ進む。
【００６６】
ＳＯＡＰアクション振分処理部１２１は、ＨＴＴＰリクエストのＳＯＡＰＡｃｔｉｏｎヘッダを解析して、ＵＲＩ（Ｕｎｉｆｏｒｍ　Ｒｅｓｏｕｒｃｅ　Ｉｎｄｉｃａｔｏｒ）により異なる要素木解析・生成ハンドラ２００にＨＴＴＰリクエストを振り分ける（ステップＳ１１０９）。この場合、印刷Ｗｅｂサービスを指定するＵＲＩに対して印刷ハンドラ２０１、文書リスト取得Ｗｅｂサービスを指定するＵＲＩに対して文書リスト取得ハンドラ２０２、及び、文書情報取得Ｗｅｂサービスを指定するＵＲＩに対して文書情報取得ハンドラ２０３に、ＨＴＴＰリクエスト及び要素木とが振り分けられる。
【００６７】
各要素木解析・生成ハンドラ２００は、リクエストの要素木を解析してＣ言語の構造体データに変換する（ステップＳ１１１０）。その後、変換した構造体データを引数として、ＨＴＴＰリクエストで指定されるＵＲＩに対応するＷｅｂサービスファンクション３００をコールする（ステップＳ１１１１）。この場合、印刷ハンドラ２０１は印刷機能３０１、文書リスト取得ハンドラ２０２は文書リスト取得機能３０２、文書情報取得ハンドラ２０３は文書情報取得機能３０３をコールする。
【００６８】
Ｗｅｂサービスファンクション３００は、所定のＷｅｂサービスのロジックを実行して、構造体データとして結果を返す（ステップＳ１１１２）。この場合、印刷機能３０１、文書リスト取得機能３０２、文書情報取得機能３０３は、各Ｗｅｂサービスのロジックを実行して、その結果を返す。返される結果は、プログラム言語で処理可能なデータ形式（例えば、Ｃ言語の構造体）である。
【００６９】
各要素木解析・生成ハンドラ２００は、受け取った結果の構造体データからレスポンスの要素木を生成する（ステップＳ１１１３）。各要素木解析・生成ハンドラ２００によって生成された要素木は、例えば、ＸＭＬのタグ間の関係をタグからタグへのポインタによるリンクによって、そのデータ構造を示す。以後、ＳＯＡＰアクション振分処理部１２１を介して、ＸＭＬシリアライザ１１７によって、レスポンスの要素木からＸＭＬに変換される。ＸＭＬシリアライザ１１７は、要素木をテキストで示すＸＭＬに変換する。変換されたＸＭＬは、ＳＯＡＰに従ったＨＴＴＰボディに構成され、所定のＨＴＴＰヘッダが付加された後、ＨＴＴＰレスポンスとして送信される（ステップＳ１１１４）。
【００７０】
上述より、要素木解析・生成ハンドラ２００が要素木をＣ言語の構造体に応じたデータ変換を行う。また、Ｃ言語の構造体データから要素木への変換を行う。各機能３０１から３０３は、ＳＯＡＰに従ったＸＭＬの解析を行わなくて良いため、開発者は、ＳＯＡＰ及びＸＭＬの知識が無くても、Ｗｅｂサービスをプログラム言語で開発することができる。
【００７１】
Ｗｅｂサービスファンクション３００を起動時の初期化処理では、モジュール間の（直線で示される）接続が行われ、図３に示すように構成される。初期化処理では、ＰＯＳＴメソッド分配処理部１０５がＰＯＳＴメソッドハンドラとしてシーケンス制御ライブラリ１００に接続することで開始され、ＸＭＬ処理部１１５のＰＯＳＴメソッド分配処理部１０５への登録、ＳＯＡＰアクション振分処理部１２１のＸＭＬ処理部１１５への登録、要素木解析・生成ハンドラ２００のＳＯＡＰアクション振分処理部１２１への登録が行われる。
【００７２】
次に、要素木解析・生成ハンドラ２００の印刷ハンドラ２０１を例にして、印刷ハンドラ２０１における要素木の解析処理について図６、図７及び図８で説明する。図６は、ＸＭＬを使用したＳＯＡＰに従ったＨＴＴＰリクエストの記述例を示す図である。図７は、ＸＭＬプロセッサによって変換された要素木の例を示す図である。図８は、印刷ハンドラによる要素木解析処理を説明するためのフローチャート図である。
【００７３】
印刷Ｗｅｂサービスを依頼する図６に示すようなＨＴＴＰリクエストの場合、ＸＭＬプロセッサ１１２は、＜ＳＯＡＰ−ＥＮＶ：Ｅｎｖｅｌｏｐｅ＞で始まるＨＴＴＰボディ２０を要素木に変換する。タグ名２１「Ｅｎｖｅｌｏｐｅ」をルート要素とし、ルート要素の子ノードとしてタグ名２２「Ｈｅａｄｅｒ」及びタグ名２３「Ｂｏｄｙ」を関連づける。更に、タグ名２３「Ｂｏｄｙ」の子ノードをタグ名２４「ｐｒｉｎｔ」とし、更に、タグ名２４「ｐｒｉｎｔ」の子ノードとしてタグ名２５「ｆｉｌｅＩｄ」及びタグ名２６「ｃｏｕｎｔ」とを関連付ける。そして、タグ名２５「ｆｉｌｅＩｄ」及びタグ名２６「ｃｏｕｎｔ」に、夫々、テキストデータ２７「１２３」及びテキストデータ２８「２」を関連付ける。このようにして関連付けられた要素木構造は、例えば、図７に示されるようなデータ構造となる。図７において、タグ名２１から２６及びテキストデータ２７から２８を楕円で示し、関連付けが矢印で示される。
【００７４】
図７に示すようなデータ構造となった要素木は、印刷ハンドラ２０１によって、図８に示されるフローチャートに従って、印刷機能３０１が処理可能なプログラム言語による構造体データが生成される。図８において、印刷ハンドラ２０１は、ルート要素を取得する（ステップＳ１２０）。この場合、ルート要素は、Ｅｎｖｅｌｏｐｅ要素となる。子ノードリストを取得する（ステップＳ１２１）。つまり、タグ名２２「Ｈｅａｄｅｒ」及び２３「Ｂｏｄｙ」を取得する。子ノードリストからタグ名がＢｏｄｙの要素を検索して取得する（ステップＳ１２２）。Ｂｏｄｙ要素の最初の子ノードを取得する（ステップＳ１２３）。この場合、ｐｒｉｎｔ要素を取得する。ｐｒｉｎｔ要素の子ノードリストを取得する（ステップＳ１２４）。取得した子ノードリストからタグ名を順に取得する（ステップＳ１２５）。
【００７５】
タグ名がｆｉｌｅＩＤであるか否かを判断する（ステップＳ１２６）。タグ名がｆｉｌｅＩＤでない場合、ステップＳ１２９へ進む。一方、タグ名がｆｉｌｅＩＤである場合、タグ名がｆｉｌｅＩＤの最初の子ノードを取得する（ステップＳ１２７）。つまり、テキストノードを取得する。取得したテキストノードを抽出して整数に変換する（ステップＳ１２８）。つまり、ファイルＩＤパラメータとして、値「１２３」が所定の構造体に設定される。更に、タグ名がｃｏｕｎｔであるか否かを判断する（ステップＳ１２９）。タグ名がｃｏｕｎｔでない場合、ステップＳ１３２へ進む。一方、タグ名がｃｏｕｎｔである場合、タグ名がｃｏｕｎｔの最初の子ノードを取得する（ステップＳ１３０）。つまり、テキストノードを取得する。取得したテキストノードを抽出して整数に変換する（ステップＳ１３１）。つまり、部数パラメータとして、値「２」が所定の構造体に設定される。
【００７６】
印刷ハンドラ２０１は、ステップＳ１２５で取得した子ノードリストから次の子ノードがあるか否かを判断する（ステップＳ１３２）。次の子ノードがある場合、ステップＳ１２５に戻り、次の子ノードを取得し、上記同様の処理を行う。次の子ノードがない場合、要素木の解析処理を終了する。
【００７７】
このようにして解析された要素木は、印刷ハンドラ２０１によって図９に示されるようなプログラム言語による構造体２９（「ｓｔｒｕｃｔ　ｐｒｉｎｔＰａｒａｍ」）に変換される。パラメータ「ｉｎｔ　ｆｉｌｅＩｄ」には、ステップＳ１２８によって、値「１２３」が設定される。また、パラメータ「ｉｎｔ　ｃｏｕｎｔ」には、ステップＳ１３１によって、値「２」が設定される。
【００７８】
Ｗｅｂサービスファンクション３００の印刷機能３０１が、例えば、Ｃ言語でプログラミングされる「ｐｒｉｎｔ」関数である場合、例えば、「ｓｔｒｕｃｔ　ｐｒｉｎｔＰａｒａｍ＊ｉｎ」のようにして、構造体２９へのポインタ「ｉｎ」が引数３０に設定される。印刷機能３０１（「ｐｒｉｎｔ」関数）をコールすると、印刷機能３０１での処理結果が、例えば、構造体名「ｓｔｒｕｃｔ　ｐｒｉｎｔＲｅｓｕｌｔ」へのポインタ「ｏｕｔ」を示す「ｓｔｒｕｃｔ　ｐｒｉｎｔＲｅｓｕｌｔ　＊ｏｕｔ」のような引数３１で戻る。
【００７９】
図１０は、印刷ハンドラでの処理結果を示す構造体の例を示す図である。図１０において、印刷ハンドラ２０１は、引数３１のポインタ「ｏｕｔ」によって、処理結果を設定すべき構造体３９を取得する。例えば、構造体３９において、処理結果として、パラメータ「ｒｅｑｕｅｓｔＩｄ」に値「１００」を設定する。
【００８０】
次に、処理結果を示す構造体３９から要素木を生成する要素木の生成処理について図１１及び図１２で説明する。図１１は、印刷ハンドラによる要素木生成処理を説明するためのフローチャート図である。図１２は、生成された要素木の例を示す図である。
【００８１】
図１２を参照しつつ印刷ハンドラによる要素木生成処理を説明する。図１１において、印刷ハンドラ２０１は、Ｅｎｖｅｌｏｐｅ要素３２を生成する（ステップＳ１４０）。Ｂｏｄｙ要素３３を生成する（ステップＳ１４１）。そして、Ｂｏｄｙ要素３３をＥｎｖｅｌｏｐｅ要素３２に接続する（ステップＳ１４２）。これらステップＳ１４０からＳ１４２での処理によって、ＳＯＡＰに従ったＨＴＴＰレスポンスのＨＴＴＰボディが設定される。
【００８２】
そして、印刷ハンドラ２０１は、ｐｒｉｎｔＲｅｓｐｏｎｓｅ要素３４を生成し（ステップＳ１４３）、ｐｒｉｎｔＲｅｓｐｏｎｓｅ要素３４をＢｏｄｙ要素３３に接続する（ステップＳ１４４）。更に、ｒｅｑｕｅｓｔＩｄ要素３５を生成し（ステップＳ１４５）、ｒｅｑｕｅｓｔＩｄ要素３５をｐｒｉｎｔＲｅｓｐｏｎｓｅ要素３４に接続する（ステップＳ１４６）。
【００８３】
印刷ハンドラ２０１は、結果として得られたリクエストＩＤより、テキストノード３６を生成して（ステップＳ１４７）、テキストノードをｒｅｑｕｅｓｔＩｄ要素３５に接続する（ステップＳ１４８）。この場合、テキストノード３６には、「１００」が設定される。
【００８４】
このように生成された要素木は、ＸＭＬ処理部１１５及びＸＭＬシリアライザ１１７によって、図１３に示されるようなＨＴＴＰボディ３２を生成する。図１３は、要素木から変換されたＸＭＬを使用したＳＯＡＰに従ったＨＴＴＰレスポンスの記述例を示す図である。図１３において、図１２に示す各要素３２から３６は、＜　＞で区切られるタグ内に記述され、所定の情報をＳＯＡＰに従った手順でＸＭＬにて記述される。
【００８５】
上記実施例より、ＸＭＬのデータ構造を示す要素木をＷｅｂサービスファンクション３００が処理可能な構造体に変換、及び、構造体をＸＭＬの要素木に変換する要素木解析・生成ハンドラ２００を備えることによって、開発者は、従来と同様の開発方法、例えば、Ｃ言語による開発方法によって、Ｗｅｂサービスファンクションとしてのアプリケーションの開発を行うことができる。また、既に実装されているアプリケーションを容易にＷｅｂサービスに対応するに改良することができる。
【００８６】
また、要素木解析・生成ハンドラ２００を有する融合機１２００では、ＳＯＡＰに従うＸＭＬ記述されたメッセージをＷｅｂサービスファンクション３００が解釈することができるため、Ｗｅｂサービスファンクション３００を他システムに提供することが可能となる。よって、融合機１２００に接続されるシステム又はコンピュータ端末を限定しないため、融合機１２００の利用可能性を大幅に拡大することが可能となる。
【００８７】
【発明の効果】
以上、説明してきたように、本願発明によれば、機器間におけるメッセージ交換プロトコルに従ったメッセージのデータ形式の変換を行う処理部を備えているため、従来と同様の方法によって開発されたＷｅｂサービスファンクションであっても、該メッセージの処理が可能となる。そのため、画像形成装置におけるＷｅｂサービスファンクションの開発をメッセージの記述形式に依存することなく容易に行うことができる。また、既に実装されているアプリケーションを容易にＷｅｂサービスに対応できるように改良することができる。更に、画像形成装置に接続可能な他システムとの連携を拡大することができる。
【００８８】
【図面の簡単な説明】
【図１】本発明の一実施例に係る多種の画像形成機能を融合する融合機の機能構成を示すブロック図である。
【図２】図１に示す融合機のハードウェア構成を示すブロック図である。
【図３】Ｗｅｂサービスを実現するための構成例を示す図である。
【図４】ＳＯＡＰによるＷｅｂサービスの提供処理について説明するフローチャート図である。
【図５】ＳＯＡＰによるＷｅｂサービスの提供処理について説明するフローチャート図である。
【図６】ＸＭＬを使用したＳＯＡＰに従ったＨＴＴＰリクエストの記述例を示す図である。
【図７】ＸＭＬプロセッサによって変換された要素木の例を示す図である。
【図８】印刷ハンドラによる要素木解析処理を説明するためのフローチャート図である。
【図９】要素木解析処理によって生成される構造体の例を示す図である。
【図１０】印刷ハンドラでの処理結果を示す構造体の例を示す図である。
【図１１】印刷ハンドラによる要素木生成処理を説明するためのフローチャート図である。
【図１２】生成された要素木の例を示す図である。
【図１３】要素木から変換されたＸＭＬを使用したＳＯＡＰに従ったＨＴＴＰレスポンスの記述例を示す図である。
【符号の説明】
２　　　　　ｈｔｔｐデーモン
７　　　　　要求仲介デーモン
１５　　　　ネットワーク
１００　　　シーケンス制御ライブラリ
１０１　　　ＨＴＴＰ接続管理部
１０２　　　ＨＴＴＰサービス実行部
１０５　　　ＰＯＳＴメソッド分配処理部
１１０　　　ＸＭＬライブラリ
１１５　　　ＸＭＬ処理部　　　　　１１６　　　ＸＭＬプロセッサ
１１７　　　ＸＭＬシリアライザ
１２０　　　ＳＯＡＰライブラリ
１２１　　　ＳＯＡＰアクション振分処理部
２００　　　要素木解析・生成ハンドラ
３００　　　Ｗｅｂサービスファンクション
１２００　　融合機
１２０１　　プロッタ、　　　　　　１２０２　　スキャナ、
１２０３　　その他ハードウェアリソース、
１２１０　　ソフトウェア群、
１２３０　　アプリケーション、　　１２２０　　プラットフォーム、
１２２１　　ＯＳ、　　　　　　　　１２２２　　ＳＣＳ、
１２２３　　ＳＲＭ、　　　　　　　１２２４　　ＥＣＳ、
１２２５　　ＭＣＳ、　　　　　　　１２２６　　ＯＣＳ、
１２２７　　ＦＣＳ、　　　　　　　１２２８　　ＮＣＳ、
１２２９　　ＩＭＨ、　　　　　　　１２４０　　融合機起動部、
１３００　　コントローラ、　　　　１３０１　　ＡＳＩＣ、
１３０２　　ＭＥＭ−Ｃ、　　　　　１３０３　　ＨＤＤ、
１３０４　　ＣＰＵ、　　　　　　　１３０５　　ＮＢ、
１３０６　　ＭＥＭ−Ｐ、　　　　　１３０７　　ＳＢ、
１３０８　　ＡＧＰ、　　　　　　　１３１０　　オペレーションパネル、
１３２０　　ファックスコントロールユニット
１３１１　　ＮＩＣ、　　　　　　　１３１２　　ＵＳＢ、
１３１３　　ＩＥＥＥ１３９４、　　１３１４　　セントロニクス、
１３５０　　エンジン部
【図１】
2004005504.tif 000003
【図２】
2004005504.tif 000004
【図３】
2004005504.tif 000005
【図４】
2004005504.tif 000006
【図５】
2004005504.tif 000007
【図６】
2004005504.tif 000008
【図７】
2004005504.tif 000009
【図８】
2004005504.tif 000010
【図９】
2004005504.tif 000011
【図１０】
2004005504.tif 000012
【図１１】
2004005504.tif 000013
【図１２】
2004005504.tif 000014
【図１３】
2004005504.tif 000015