(57)【要約】      （修正有）【課題】Ｗｅｂサービスの要求及び応答メッセージの記述形式と該Ｗｅｂサービスの開発プログラムで処理可能なデータ形式を変換するプログラムを自動生成する。【解決手段】コンピュータに、Ｗｅｂサービスのインターフェイス定義を構成する複数の要素の関連を示す第一要素木に基づいて、前記Ｗｅｂサービスを実行する関数によって処理可能な入出力データと前記Ｗｅｂサービスに関する要求及び応答メッセージに含まれる値のデータ型との変換処理を行う変換プログラムを生成する変換プログラム生成手順と、前記Ｗｅｂサービスに関する要求メッセージを解析するとともに前記応答メッセージを生成する解析プログラムを生成する解析プログラム生成手順とを実行させる。【選択図】図１
2005310171.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータに、
Ｗｅｂサービスのインターフェイス定義を構成する複数の要素の関連を示す第一要素木に基づいて、前記Ｗｅｂサービスを実行する関数によって処理可能な入出力データと前記Ｗｅｂサービスに関する要求及び応答メッセージに含まれる値のデータ型との変換処理を行う変換プログラムを生成する変換プログラム生成手順と、
前記Ｗｅｂサービスに関する要求メッセージを解析するとともに前記応答メッセージを生成する解析プログラムを生成する解析プログラム生成手順とを実行させるためのコンピュータ読み取り可能なプログラム。
【請求項２】
前記変換プログラム生成手順は、
前記第一要素木に含まれるサービス名及び操作名に基づいて生成した前記解析プログラムの関数名を含む関数宣言を生成することを特徴とする請求項１記載のプログラム。
【請求項３】
前記変換プログラム生成手順は、
上記第一要素木に含まれるサービス名、操作名、入力メッセージ、及び出力メッセージに基づいて生成した前記Ｗｅｂサービスを実行する関数の関数名を含む関数宣言を生成することを特徴とする請求項１又は２記載のプログラム。
【請求項４】
前記変換プログラム生成手順は
前記インターフェイス定義の一部であるデータ型定義に基づいて、前記変換プログラムの関数名を含む関数宣言を生成することを特徴とする請求項１乃至３のいずれか一項記載のプログラム。
【請求項５】
前記解析プログラム生成手順は、
前記変換プログラムに基づき前記要求メッセージを構成する複数の要素間の関連を示す第二要素木の末端に設定される値のデータ型を前記Ｗｅｂサービスを実行する関数によって処理可能な入出力データに変換する第一コード生成手順と、
前記Ｗｅｂサービスを実行する関数をコールする第二コードを生成する第二コード生成手順と、
前記変換プログラムに基づき前記Ｗｅｂサービスを実行する関数の戻り値を前記要求メッセージを構成する複数の要素間の関連を示す第三要素木の末端に設定される値のデータ型に変換する第三コード生成手順とを有することを特徴とする請求項１乃至４のいずれか一項記載のプログラム。
【請求項６】
前記第一コード生成手順は、
前記変換プログラムが前記インターフェイス定義に含まれるデータ型定義に基づき、前記第二要素木の末端に設定される値のデータ型の判断を行い該判断に基づき変換を行うことを特徴とする請求項５記載のプログラム。
【請求項７】
前記第三コード生成手順は、
前記変換プログラムが前記インターフェイス定義に含まれるデータ型定義に基づき、前記第三要素木の末端に設定される値のデータ型の判断を行い該判断に基づき変換を行うことを特徴とする請求項５又は６記載のプログラム。
【請求項８】
コンピュータが、
Ｗｅｂサービスのインターフェイス定義を構成する複数の要素の関連を示す第一要素木に基づいて、前記Ｗｅｂサービスを実行する関数によって処理可能な入出力データと前記Ｗｅｂサービスに関する要求及び応答メッセージに含まれる値のデータ型との変換処理を行う変換プログラムを生成する変換プログラム生成手順と、
前記Ｗｅｂサービスに関する要求メッセージを解析するとともに前記応答メッセージを生成する解析プログラムを生成する解析プログラム生成手順とを実行することを特徴とするプログラム生成方法。
【請求項９】
コンピュータに、
Ｗｅｂサービスのインターフェイス定義を構成する複数の要素の関連を示す第一要素木に基づいて、前記Ｗｅｂサービスを実行する関数によって処理可能な入出力データと前記Ｗｅｂサービスに関する要求及び応答メッセージに含まれる値のデータ型との変換処理を行う変換プログラムを生成する変換プログラム生成手順と、
前記Ｗｅｂサービスに関する要求メッセージを解析するとともに前記応答メッセージを生成する解析プログラムを生成する解析プログラム生成手順とを実行させるためのコンピュータ読み取り可能なプログラムが記憶された記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、Ｗｅｂサービスの要求及び応答メッセージの記述形式と該Ｗｅｂサービスのプログラムで処理可能なデータ形式を変換するプログラムを自動生成するプログラムを提供するものである。
【背景技術】
【０００２】
近年、プリンタ、コピー、ファクシミリ、スキャナなどの各装置の機能を１つの筐体内に収納した画像形成装置が一般的に知られている。このような複合型の画像形成装置は、１つの筐体内に表示部、印刷部および撮像部などを設けるとともに、プリンタ、コピー、スキャナおよびファクシミリ装置にそれぞれ対応するアプリケーションを設け、アプリケーションの切り替えによって、当該装置をプリンタ、コピー、スキャナまたはファクシミリ装置として動作させるものである。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
しかしながら、上記従来の複合型画像形成装置において、ネットワークを介して個々のアプリケーションが画像形成処理をＷｅｂサービスとして提供する場合、そのネットワークプロトコルに従って交換されるメッセージの記述形式を意識したプログラム開発が必要であった。つまり、メッセージには、Ｗｅｂサービス機能に行わせる処理内容が指示されており、プログラムされたＷｅｂサービス機能は、該メッセージを解釈するための機能を組み込んでおく必要があった。メッセージの記述形式がＸＭＬ（eXtensible Markup Language）である場合、Ｗｅｂサービス開発者は、ＸＭＬの知識を必要としていた。
【０００４】
また、ＸＭＬによるメッセージのデータ形式とＷｅｂサービス機能におけるプログラム言語にて処理可能なデータ形式とは異なっているため、各Ｗｅｂサービス機能の中にこれらデータ形式の違いを吸収するための仕組みを持つ必要があった。このようなデータ形式の違いを吸収するための仕組みの開発では、単純で同じようなコードを大量に繰り返す必要があり、単純ミスによるバグが入りやすいという問題があった。
【０００５】
そこで、本発明の課題は、複数のＷｅｂサービスを提供する該画像形成装置と接続される機器とで交換されるメッセージの記述形式に依存することなく該複数のＷｅｂサービスのプログラム開発を容易とする、該記述形式と該Ｗｅｂサービスの開発プログラムで処理可能なデータ形式を変換するプログラムを自動生成するプログラムを提供することである。
【課題を解決するための手段】
【０００６】
上記課題を解決するため、本発明は、請求項１に記載されるように、コンピュータに、Ｗｅｂサービスのインターフェイス定義を構成する複数の要素の関連を示す第一要素木に基づいて、前記Ｗｅｂサービスを実行する関数によって処理可能な入出力データと前記Ｗｅｂサービスに関する要求及び応答メッセージに含まれる値のデータ型との変換処理を行う変換プログラムを生成する変換プログラム生成手順と、前記Ｗｅｂサービスに関する要求メッセージを解析するとともに前記応答メッセージを生成する解析プログラムを生成する解析プログラム生成手順とを実行させるように構成される。
【０００７】
このようなプログラムをインストールしたコンピュータ装置では、Ｗｅｂサービスのインターフェイスを定義するインターフェイス定義（例えば、ＷＳＤＬ（Web Service Description Language））から、Ｗｅｂサービス機能の入出力データ形式と所定記述形式（例えば、ＸＭＬ（eXtensible Markup Language））による要求及び応答メッセージとの変換を行うプログラム（例えば、実施例におけるハンドラ処理部）を生成することができる。従って、単純で同じようなコードを大量に生成することができるため、開発者による単純ミスによるバグが入り込むといった問題を解消することができる。また、短時間でプログラムを生成することができるため、開発者の負担を軽減することができる。
【０００８】
また、このようなプログラムをインストールしたコンピュータ装置では、変換処理を行うプログラムとして、所定記述形式による要求及び応答メッセージの解析及び生成を行うプログラム（例えば、実施例におけるハンドラソースコード）を生成することができる。
【０００９】
更に、本発明は、請求項２に記載されるように、前記変換プログラム生成手順は、前記第一要素木に含まれるサービス名・操作名に基づいて生成した前記解析プログラムの関数名を含む関数宣言を生成するように構成することができる。
【００１０】
このようなプログラムをインストールしたコンピュータ装置では、インターフェイス定義（例えば、ＷＳＤＬ）にて指定されるサービス名、操作名等に基づいて自動生成したプログラムの関数名の関数名を宣言することができる。
【００１１】
また、本発明は、請求項３に記載されるように、前記変換プログラム生成手順は、上記第一要素木に含まれるサービス名・操作名・入力メッセージ及び出力メッセージに基づいて生成した前記Ｗｅｂサービスを実行する関数の関数名を含む関数宣言を生成するように構成することができる。
【００１２】
このようなプログラムをインストールしたコンピュータ装置では、インターフェイス定義（例えば、ＷＳＤＬ）にて指定されるサービス名、操作名、入力メッセージ名、出力メッセージ名等に基づいて自動生成したプログラムのＷｅｂサービス機能の関数名を宣言することができる。
【００１３】
更に、本発明は、請求項４に記載されるように、前記変換プログラム生成手順は
前記インターフェイス定義の一部であるデータ型定義に基づいて、前記変換プログラムの関数名を含む関数宣言を生成するように構成することができる。
【００１４】
このようなプログラムをインストールしたコンピュータ装置では、インターフェイス定義（例えば、ＷＳＤＬ）に基づいて、Ｗｅｂサービス機能によって処理可能な入力データ及び出力データの構造体を定義することができる。
【００１５】
更に、本発明は、請求項５に記載されるように、前記解析プログラム生成手順は、前記変換プログラムに基づき前記要求メッセージを構成する複数の要素間の関連を示す第二要素木の末端に設定される値のデータ型を前記Ｗｅｂサービスを実行する関数によって処理可能な入出力データに変換する第一コード生成手順と、前記Ｗｅｂサービスを実行する関数をコールする第二コードを生成する第二コード生成手順と、前記変換プログラムに基づき前記Ｗｅｂサービスを実行する関数の戻り値を前記要求メッセージを構成する複数の要素間の関連を示す第三要素木の末端に設定される値のデータ型に変換する第三コード生成手順とを有するように構成することができる。
【００１６】
このようなプログラムをインストールしたコンピュータ装置では、所定記述形式（例えば、ＸＭＬ）による要素間の関連を示す要素木（要求メッセージのＤＯＭツリー）からＷｅｂサービス機能が処理可能なプログラム言語による入力データに変換、及び、プログラム言語による出力データを所定記述形式（例えば、ＸＭＬ）の要素木（応答メッセージのＤＯＭツリー）に変換するソースコードが自動生成される。
【００１７】
また、本発明は、請求項６に記載されるように、前記第一コード生成手順は、前記変換プログラムが前記インターフェイス定義に含まれるデータ型定義に基づき、前記第二要素木の末端に設定される値のデータ型の判断を行い該判断に基づき変換を行うように構成することができる。更に、本発明は、請求項７に記載されるように、前記第三コード生成手順は、前記変換プログラムが前記インターフェイス定義に含まれるデータ型定義に基づき、前記第三要素木の末端に設定される値のデータ型の判断を行い該判断に基づき変換を行うように構成することができる。
【００１８】
このようなプログラムをインストールしたコンピュータ装置では、インターフェイス定義（ＷＳＤＬ）に含まれる入出力データのデータ型定義（例えば、列挙型、構造体、配列等の定義をしているＸＭＬＳｃｈｅｍａ）に基づいて、前記第二要素木の末端に設定される値のデータ型の判断を行い該判断に基づき変換することができる。また、インターフェイス定義（ＷＳＤＬ）に含まれる入出力データのデータ型定義（例えば、列挙型、構造体、配列等の定義をしているＸＭＬＳｃｈｅｍａ）に基づいて、前記第三要素木の末端に設定される値のデータ型の判断を行い該判断に基づき変換することができる。
【００１９】
上記課題を解決するための手段として、本発明は、上記プログラムをインストールしたコンピュータ装置におけるプログラム生成方法及び上記プログラムが記憶された記憶媒体とすることもできる。
【発明の効果】
【００２０】
以上、説明してきたように、本願発明によれば、機器間におけるメッセージ交換プロトコルに従ったメッセージのデータ形式の変換を行うためのプログラムが自動的に生成される。従って、開発者による単純ミスによるバグが入り込むといった問題を解消することができる。また、このように自動生成されたプログラムを画像形成装置に実装することによって、従来と同様の方法によって開発されたＷｅｂサービスファンクションであっても、該メッセージの処理が可能となる。そのため、画像形成装置におけるＷｅｂサービスファンクションの開発を容易に行うことができる。また、画像形成装置に接続可能な他システムとの連携を拡大することができる。
【発明を実施するための最良の形態】
【００２１】
以下、本発明の実施の形態を図面に基づいて説明する。
【００２２】
本発明の一実施例に係るハンドラ自動生成装置は、図１に示すような機能構成を有する。図１は、本発明の一実施例に係るハンドラ自動生成装置の機能構成を示すブロック図である。図１において、ハンドラ自動生成装置５００は、コンピュータ装置であって、メッセージのデータ形式とＷｅｂサービス機能におけるプログラム言語にて処理可能なデータ形式との違いを吸収するプログラムを生成するハンドラ自動生成部５１０と、ＷＳＤＬ（Web Service Description Language）によるインターフェイス定義５２１と、ハンドラを実行するために必要なソースコード５３１とを記憶するための記憶媒体（例えば、ハードディスクドライブ（ＨＤＤ））有する。
【００２３】
ハンドラ自動生成部５１０は、ＷＳＤＬ（Web Service Description Language）によるインターフェイス定義５２１を入力し、ＸＭＬ（eXtensible Markup Language）で記述された要求メッセージの構文を解析して要素木を生成して、要素木に基づいてＷｅｂサービス機能（ＷＳＦ）を関数コールするための引数を設定すると共に、Ｗｅｂサービス機能からの戻り値を含むＸＭＬによる応答メッセージを記述するための要素木を生成するハンドラ処理部のソースコードを生成して出力する処理部である。
【００２４】
ハンドラ自動生成部５１０は、ＸＭＬ解析部５１１と、タイプライブラリ生成部５１２と、ハンドラソースコード生成部５１３と、ＸＭＬスキーマ解析部５１４と、タイプ要素解析部５１５と、メッセージ要素解析部５１６と、操作要素解析部５１７と、インターフェイス定義５２１を入力するファイル入力部５２０と、ソースコード５３１を出力するファイル出力部５３０とを有する。
【００２５】
インターフェイス定義５２１は、どういうインターフェイスで１つのＷｅｂサービスを提供するかを定義し、ＷＳＤＬによるインターフェイス定義ファイル５２２と、インターフェイス定義ファイル５２２からのインポートによって取り込まれる型定義ファイル５２３とで構成される。インターフェイス定義ファイル５２２にてインポートによって型定義ファイル５２３が取り込まれない場合は、型定義ファイル５２３が存在しない。
【００２６】
ソースコード５３１は、例えば、Ｃ言語のソースコードであって、ハンドラ処理部のヘッダファイルとプログラムファイルとで構成されるハンドラソースコード５３２と、ハンドラソースコード５３２から参照されるタイプライブラリ５３３とで構成される。タイプライブラリ５３３は、ヘッダファイルとプログラムファイルとで構成される。
【００２７】
ファイル入力部５２０は、利用者によって指定されたインターフェイス定義５２１をハンドラ自動生成部５１０に入力し（ステップＳ８１）、ＸＭＬ解析部５１１に通知する（ステップＳ８２）。ＸＭＬ解析部５１１は、ファイル入力部５２０から受け取ったインターフェイス定義５２１に基づいて、ＸＭＬの構文を解析して要素木を生成する。そして、ＸＭＬ解析部５１１は、その要素木をタイプ要素解析部５１５に通知し（ステップＳ８３−１）、またメッセージ要素解析部５１６に通知し（ステップＳ８３−２）、更に操作要素解析部５１７に通知する（ステップＳ８３−３）。
【００２８】
タイプ要素解析部５１５は、タイプライブラリを生成するために要素木内のtypes要素を解析する処理部であって、要素木を解析して型定義を示すtypes要素を検出し、ＸＭＬスキーマ解析部５１４に検出したtypes要素を解析させる（ステップＳ８４−１）。そして、タイプ要素解析部５１５は、ＸＭＬスキーマ解析部５１４による解析結果をタイプライブラリ生成部５１２に通知する（ステップＳ８５−１）。
【００２９】
メッセージ要素解析部５１６は、ハンドラソースコードを生成するために要素木内のmessage要素を解析する処理部であって、その解析結果をハンドラソースコード生成部５１３に通知する（ステップＳ８５−２）。操作要素解析部５１７は、ハンドラソースコードを生成するために要素木内のoperation要素を解析する処理部であって、その解析結果をハンドラソースコード生成部５１３に通知する（ステップＳ８５−３）。
【００３０】
タイプライブラリ生成部５１２は、タイプ要素解析部５１５から通知された解析結果に基づいてタイプライブラリを生成する処理部であって、生成されたタイプライブラリはファイル出力部５３０へ通知される（ステップＳ８６−１）。ハンドラソースコード生成部５１３は、メッセージ要素解析部５１６及び操作要素解析部５１７から通知された解析結果に基づいて、ソースコードを生成してファイル出力部に通知する（ステップＳ８６−２）。ファイル出力部５３０は、ハンドラソースコード生成部５１３から通知されたソースコードをハンドラソースコード５３２として、また、タイプライブラリ生成部５１２から通知されたタイプライブラリをタイプライブラリ５３３として、ソースコード５３１を出力する（ステップＳ８７）。
【００３１】
このように、ハンドラ自動生成装置５００は、Ｗｅｂサービスを定義するインターフェイス定義５２１の入力によって、自動的にハンドラ処理部のソースコード５３１を出力することができる。
【００３２】
このようなハンドラ自動生成装置５００は、図２に示すようなハードウェア構成を有する。図２は、本発明の一実施例に係るハンドラ自動生成装置のハードウェア構成を示すブロック図である。
【００３３】
図２において、ハンドラ自動生成装置５００は、コンピュータによって制御されハンドラ自動生成部５１０を実行する装置であって、ＣＰＵ（中央処理装置）５５１と、メモリユニット５５２と、表示ユニット５５３と、入力ユニット５５４と、記憶装置５５６と、ドライバ５５７とで構成され、システムバスＢに接続される。
【００３４】
ＣＰＵ５５１は、メモリユニット５５２に格納されたプログラムに従ってハンドラ自動生成装置５００を制御する。メモリユニット５５２は、ＲＡＭ及びＲＯＭ等にて構成され、ＣＰＵ５５１にて実行されるプログラム、ＣＰＵ５５１での処理に必要なデータ、ＣＰＵ５５１での処理にて得られたデータ等を格納する。また、メモリユニット５５２の一部の領域が、ＣＰＵ５５１での処理に利用されるワークエリアとして割り付けられている。
【００３５】
表示ユニット５５３は、ＣＰＵ５５１の制御のもとに必要な各種情報を表示する。入力ユニット５５４は、マウス、キーボード等を有し、利用者がハンドラ自動生成装置５００が処理を行なうための必要な各種情報を入力するために用いられる。記憶装置５５６は、例えば、ハードディスクユニットにて構成され、図１に示すインターフェイス定義５２１及びソースコード５３１、ハンドラ処理部を生成するために必要なデータ等を格納する。
【００３６】
ハンドラ自動生成装置５００においてハンドラ自動生成部５１０によって行われる自動生成処理を実現するプログラムは、例えば、ＣＤ−ＲＯＭ等の記憶媒体５５８によってハンドラ自動生成装置５００に提供される。即ち、プログラムが保存された記憶媒体５５８がドライバ５５７にセットされると、ドライバ５５７が記憶媒体５５８からプログラムを読み出し、その読み出されたプログラムがシステムバスＢを介して記憶装置５５６にインストールされる。そして、プログラムが起動されると、記憶装置５５６にインストールされたプログラムに従ってＣＰＵ５５１がその処理を開始する。尚、プログラムを格納する媒体としてＣＤ−ＲＯＭに限定するものではなく、コンピュータが読み取り可能な媒体であればよい。
【００３７】
ハンドラ自動生成部５１０によって実行されるハンドラ自動生成処理の全体について説明する。図３は、ハンドラ自動生成処理の全体を説明するフローチャート図である。図３において、ファイル入力部５２０によってインターフェイス定義ファイル５２１を読み込み（ステップＳ５０１）、ＸＭＬ解析部５１１がＸＭＬによる記述を解析し要素木を生成する（ステップＳ５０２）。
【００３８】
ハンドラ自動生成部５１０は、解析が成功したか否かを判断する（ステップＳ５０３）。解析が失敗した場合、エラーを表示ユニット５５３に表示し（ステップＳ５０４）、ハンドラ生成処理を終了する。解析が成功した場合、タイプライブラリ生成部５１２によってタイプライブラリが生成される（ステップＳ５０５）。また、ハンドラソースコード生成部５１３によって、ハンドラソースコードが生成され（ステップＳ５０６）、ハンドラ生成処理を終了する。
【００３９】
タイプライブラリ生成部５１２によるタイプライブラリ生成処理（ステップＳ５０５）について詳述する。図４は、タイプライブラリ生成処理を説明するフローチャート図である。図４において、タイプ要素解析部５１５は、ＸＭＬ解析部５１１から通知された要素木からtypes要素を探す（ステップＳ５１１）。
【００４０】
タイプ要素解析部５１５は、types要素が見つかったか否かを判断する（ステップＳ５１２）。見つからなかった場合、タイプライブラリ生成処理を終了する。一方、見つかった場合、空要素であるか否かを判断する（ステップＳ５１３）。空の要素である場合、タイプライブラリ生成処理を終了する。一方、空要素でない場合、外部ファイルのインポートか否かを判断する（ステップＳ５１４）。つまり、図１において、インターフェイス定義ファイル５２２が型定義ファイル５２３をインポートしているか否かを判断する。外部ファイル（型定義ファイル５２３）をインポートしていない場合、ステップＳ５１６へ進む。一方、外部ファイル（型定義ファイル５２３）をインポートしている場合、スキーマ定義ファイル（型定義ファイル５２３）を読み込む（ステップＳ５１５）。
【００４１】
ＸＭＬスキーマ解析部５１４は、インターフェイス定義ファイル５２２のＸＭＬスキーマを解析し（ステップＳ５１６）、ソースコードを生成する（ステップＳ５１７）。そして、ファイル出力部５３０によって、ヘッダファイルとプログラムファイルとで構成されるタイプライブラリ５３３として出力される。
【００４２】
ステップＳ５１７のソースコード生成処理について図５から図１１で説明する。先ず、types要素において、列挙型でデータ型が定義されている場合について説明する。図５は、ソースコード生成処理における列挙型定義生成処理を説明する図である。
【００４３】
図５において、ＸＭＬスキーマ６０１は、列挙型でデータ型が定義されるＸＭＬによる記述例である。ＸＭＬスキーマ６０１は、タグsimpleTypeによる記述６０２によって、「SomeValueEnum」という名前を持つ単純型のデータ型であることが定義される。更に、タグrestrictionによる記述６０３によって、記述６０４は、baseで指定される「string」によって基底型が文字列であるように制限される。例えば、記述６０４において、enumerationタグによって文字列が「VALUE1」、「VALUE2」、「VALUE3」の３つの値が列挙される。この場合、名前「SomeValueEnum」のデータ型は、３つの文字列を持つことが定義される。
【００４４】
Ｃコード７０１は、列挙型でデータ型を定義するＸＭＬスキーマ６０１から生成されたＣ言語のソースコードである。Ｃコード７０１において、記述７０２は、記述６０２に基づいて「_SomeValueEnum」が列挙型であることを定義し、記述６０３及び記述６０４に基づいて記述７０４が生成される。「SomeValueEnum_VALUE1」、「SomeValueEnum_VALUE2」、「SomeValueEnum_VALUE3」の３つが列挙される記述７０４によって、３つの文字列を持つことが定義される。そして、記述７０５は、「SomeValueEnum」が「enum _SomeValueEnum」と同じデータ型を定義することを示す。
【００４５】
このように、types要素で列挙型が記述されているＸＭＬスキーマ６０１からＣコード７０１が生成される。
【００４６】
次に、types要素において、構造体でデータ型が定義されている場合について説明する。図６は、ソースコード生成処理における構造体の型定義生成処理を説明する図である。
【００４７】
図６において、ＸＭＬスキーマ６１１は、構造体でデータ型が定義されるＸＭＬによる記述例である。ＸＭＬスキーマ６１１は、タグcomplexTypeによる記述６１２によって、「SomeStruct」という名前を持つ複合型のデータ型であることが定義される。タグsequenceによる記述６１３によって、データ順を規定する。タグelementによる記述６１４によって、構造体メンバー「strParam」が文字列であることが定義され、タグelementによる記述６１５によって、構造体メンバー「intParam」が整数であることが定義される。
【００４８】
Ｃコード７１１は、構造体でデータ型を定義するＸＭＬスキーマ６１１から生成されたＣ言語のソースコードである。Ｃコード７１１において、記述７１２は、記述６１２に基づいて「_SomeStruct」が構造体であることを定義し、記述６１４及び記述６１５に基づいて記述７１４による「char *strParam;」及び記述７１５による「int intParam;」が生成される。そして、記述７１５は、「SomeStruct」が「struct _SomeStruct」と同じデータ型を定義することを示す。
【００４９】
このように、types要素で構造体が記述されているＸＭＬスキーマ６１１からＣコード７１１が生成される。
【００５０】
次に、types要素において、配列でデータ型が定義されている場合について説明する。図７は、ソースコード生成処理における配列の型定義生成処理を説明する図である。
【００５１】
図７において、ＸＭＬスキーマ６２１は、配列でデータ型が定義されるＸＭＬによる記述例である。ＸＭＬスキーマ６２１は、タグcomplexTypeによる記述６２２によって、「ArrayOfString」という名前を持つ複合型のデータ型であることが定義される。更に、タグrestrictionによる記述６２４によって、baseで指定される「soapEnc:Array」によってＳＯＡＰ符号化に従った配列であるように制限される。また、タグsequenceによる記述６２５によって、記述６２６によるデータ順を規定する。タグelementによる記述６２６によって、「item」が文字列であり、省略可能であり、出現回数に上限のないことが定義される。タグattributeによる記述６２７は、「soapEnc:arrayType」が参照されて、その配列のタイプが「wsdl:arrayType=”xs:string[]”」によって文字列の配列であるように属性を定義する。
【００５２】
Ｃコード７２１は、配列でデータ型を定義するＸＭＬスキーマ６２１から生成されたＣ言語のソースコードである。Ｃコード７２１において、記述７２２は、記述６２２に基づいて「_ArrayOfString」が構造体であることを定義し、記述６２６及び記述６２７に基づいて記述７２３及び記述７２４による要素数を示す「int length;」及び記述７１５による「char*」の配列のポインタである「char **array;」が生成される。そして、記述７２５は、「ArrayOfString」が「struct_ArrayOfString」と同じデータ型を定義することを示す。
【００５３】
types要素のsimpleType及びcomplexTypeの定義に基づいてＣ言語の関数宣言を生成する例について図８から１０で説明する。図８から図１０において、Ｃ言語コード内のDocument及びElementは、ＤＯＭ(Document Object Model)によって定義される型をＣ言語の構造体にマッピングしたものであるとする。また、図８から図１０において、シリアライザ及びデシリアライザは、要素木と各型に対応した構造体データの変換を行う際に実行されるプログラムであって、シリアライザは構造体データを要素木に変換し、でシリアライザは要素木に構造体データに変換するプログラムである。また、コンストラクタ及びデストラクタは、構造体データを生成する際に実行されるプログラムであって、デストラクタは構造体データを解放するプログラムである。
【００５４】
図８は、ソースコード生成処理における列挙型の関数宣言処理を説明する図である。図８において、「Element *SomeValueEnum_serialize(Document *doc, char *tagName, SomeValueEnum value);」で示されるシリアライザ８０１は、「SomeValueEnum value」によって列挙値を入力として受け取って、「char *tagname」によってtagnameをタグ名とする要素（Element）を生成して出力する。また、「SomeValueEnum SomeValueEnum_deserialize(Element *element);」で示されるデシリアライザ８１１は、要素（Element）を入力として受け取って、これを解析して列挙値を出力する。
【００５５】
シリアライザ８０１及びデシリアライザ８１１は、ＸＭＬスキーマ６０１より生成される。
【００５６】
図９は、ソースコード生成処理における構造体の関数宣言処理を説明する図である。図９において、「SomeStruct *SomeStruct_create(char *strParam, int intParam);」で示されるコンストラクタ８２１は、構造体メンバーの値を入力として受け取って、構造体を生成して出力する。「void SomeStruct_free(SomeStruct *st);」で示されるデストラクタ８３１は、構造体を入力として受け取って、その使用するメモリ領域を解放する。また、構造体メンバーの使用するメモリ領域も再帰的に解放する。「Element *SomeStruct_serialize(Document *doc, char *tagName, SomeStruct *st);」で示されるシリアライザ８４１は、「SomeStruct *st」によって構造体を入力として受け取って、「char *tagname」によってtagnameをタグ名とする要素（Element）を生成して出力する。また、「SomeStruct *SomeStruct_deserialize(Element *element);」で示されるデシリアライザ８５１は、要素（Element）を入力として受け取って、これを解析して構造体を生成して出力する。
【００５７】
従って、ＸＭＬで記述された入力値を示す要素をデシリアライザ８５１とコンストラクタ８２１とを用いることによって、Ｗｅｂサービス機能が処理可能な構造体に入力値を設定することができる。また、Ｗｅｂサービス機能からの戻り値（処理結果としての出力値）を、シリアライザ８４１を用いることによって、ＸＭＬで記述される要素に対応させて処理結果を設定することができる。
【００５８】
コンストラクタ８２１、デストラクタ８３１、シリアライザ８４１及びデシリアライザ８５１は、ＸＭＬスキーマ６１１より生成される
図１０は、ソースコード生成処理における配列の関数宣言処理を説明する図である。図１０において、「ArrayOfString *ArrayOfString_create(int length, char **array);」で示されるコンストラクタ８６１は、配列サイズと、配列を入力として受け取って、配列を保持する構造体を生成して出力する。「void ArrayOfString_free(ArrayOfString *st);」で示されるデストラクタ８７１は、配列を保持する構造体を入力として受け取って、その使用するメモリ領域を解放する。また、配列メンバーの使用するメモリ領域も再帰的に解放する。「Element *ArrayOfString_serialize(Document *doc, char *tagName, ArrayOfString *st);」で示されるシリアライザ８８１は、「ArrayOfString *st」によって配列を保持する構造体を入力として受け取って、「char *tagname」によってtagnameをタグ名とする要素（Element）を生成して出力する。また、「SomeStruct *SomeStruct_deserialize(Element *element);」で示されるデシリアライザ８９１は、要素（Element）を入力として受け取って、これを解析して配列を保持する構造体を生成して出力する。
【００５９】
従って、ＸＭＬで記述された入力値を示す要素をデシリアライザ８９１とコンストラクタ８６１とを用いることによって、Ｗｅｂサービス機能が処理可能な配列に入力値を設定することができる。また、Ｗｅｂサービス機能からの戻り値（処理結果としての出力値）をシリアライザ８８１とを用いることによって、ＸＭＬで記述される要素に対応させて処理結果を設定することができる。
【００６０】
コンストラクタ８６１、デストラクタ８７１、シリアライザ８８１及びデシリアライザ８９１は、ＸＭＬスキーマ６２１より生成される
このようにして生成されたＣ言語の関数宣言は、タイプライブラリ５３３のヘッダファイルに出力される。また、各関数の処理はプログラムファイルに出力される。
【００６１】
次に、ハンドラ自動生成部５１０によるハンドラ生成処理について図１１及び図１２で詳述する。図１１及び図１２は、ハンドラ生成処理を説明するフローチャート図である。図１１において、ハンドラ自動生成部５１０は、service要素のname属性からサービス名を取得する（ステップＳ５２１）。そして、service要素、binding要素、porttype要素の順に辿って各要素を探す（ステップＳ５２２）。
【００６２】
porttype要素の子のoperation要素を探し、name属性から操作名を取得する（ステップＳ５２３）。operation要素の子のinput要素を探し、name属性から入力メッセージ名を取得する（ステップＳ５２４）。operation要素の子のoutput要素を探し、name属性から出力メッセージ名を取得する（ステップＳ５２５）。そして、ハンドラ処理部とＷｅｂサービス機能（ＷＳＦ）の関数宣言を生成する（ステップＳ５２６）。
【００６３】
入力メッセージのmessage要素を探す（ステップＳ５２７）。message要素の子のpart要素を探し、name属性からパラメータ名、及び、types属性から型を取得する（ステップＳ５２８）。そして、型をＣ言語の型にマッピングする（ステップＳ５２９）。まだpart要素があるか否かを判断する（ステップＳ５３０）。part要素がある場合、ステップＳ５２８へ戻り、上記処理を繰り返す。一方、part要素がない場合、入力メッセージのＣ言語の型へのマッピングを終了し、出力メッセージのＣ言語の型へのマッピングを行う。
【００６４】
出力メッセージのmessage要素を探す（ステップＳ５３１）。message要素の子のpart要素を探し、name属性からパラメータ名、及び、types属性から型を取得する（ステップＳ５３２）。そして、型をＣ言語の型にマッピングする（ステップＳ５３３）。まだpart要素があるか否かを判断する（ステップＳ５３４）。part要素がある場合、ステップＳ５３２へ戻り、上記処理を繰り返す。一方、part要素がない場合、出力メッセージのＣ言語の型へのマッピングを終了する。
【００６５】
次に、入力メッセージの構造体定義を生成する（ステップＳ５３５）。また、出力メッセージの構造体定義を生成する（ステップＳ５３６）。ハンドラ処理部のプログラムを生成する（ステップＳ５３７）。入力メッセージの構造体定義及び出力メッセージを構造体定義をヘッダファイルに出力し、ハンドラ処理部のプログラムをプログラムファイルに出力する（ステップＳ５３８）。そして、まだoperation要素があるか否かを判断する（ステップＳ５３９）。operation要素がある場合、ステップＳ５２３へ戻り、上記同様の処理を繰り返す。operation要素がない場合、ハンドラ生成処理を終了する。
【００６６】
ハンドラ自動生成部５１０に入力されるインターフェイス定義ファイル（ＷＳＤＬ）の記述例について図１３及び図１４で説明する。図１３及び図１４は、ＷＳＤＬによるインターフェイス定義の記述例を示す図である。図１３及び図１４において、本来<type>タグによって記述されるデータ型の定義は、「foo.bar.com/types.xsd」で特定される型定義ファイル５２３によって定義されているものとする。この記述例において、メッセージを記述するためのデータ型を定義し、スキーマの定義が設定される<type>タグは省略され、その代わりに、記述４０によって「foo.bar.com/types.xsd」からインポートされる。
【００６７】
メッセージの書式を定義する<message>タグ４１（記述<message name="printInput">）によって定義される定義情報４２において、記述<part name="fileId" type="xs:unsignedInt"/>及び記述<part name="count" type="xs:unsignedInt"/>によって、印刷要求の入力パラメータ（printInput）は、符号なし整数（unsignedInt）のfileId及び符号なし整数（unsignedInt）のcountによって構成されることを定義する。また、メッセージの書式を定義する<message>タグ４３（記述<message name="printOutput">）によって定義される定義情報４４において、記述<part name="requestId" type="xs:unsignedInt"/>によって、印刷要求の出力パラメータ（printOutput）は、符号なし整数（unsignedInt）のrequestIdによって構成されることを定義する。
【００６８】
操作（operation）の集合を定義する<portType>タグ４５（記述<portType name="netdocPortType">）によって定義される定義情報４６において、操作毎の入力メッセージ及び出力メッセージが定義される。例えば、<operation>タグ４７（記述<operation name="print">）によって定義される定義情報４８において、記述<input message="tns:printInput"/>によって入力メッセージはprintInputであることが定義され、また、記述<output message="tns:printOutput"/>によって出力メッセージはprintOutputであることが定義される。この場合、印刷（print）のみが定義される。
【００６９】
<portType>タグ４５によって定義された操作とメッセージを具体的なプロトコルとデータフォーマットにマップする<binding>タグ４９（記述<binding name="netdocHttpBinding" type="tns:netdocPortType">）によって定義される定義情報５０において、netdocPortTypeで定義されるポートタイプについて、操作とメッセージのプロトコルとデータフォーマットへのマップが定義される。
【００７０】
定義情報５０において、<sb:binding>タグ５１（記述<sb:binding transport="http://schemas.xmlsoap.org/soap/http" style="rpc"/>）によって、ＳＯＡＰ  ＨＴＴＰバインディングによるＲＰＣ（Remote Procedure Call）の使用が定義される。<operation>タグ５２（記述<operation name="print">）によって、以下に印刷（print）に関するＳＯＡＰメッセージが定義される。
【００７１】
先ず、<sb:operation>タグ５３（記述<sb:operation soapAction="http://foo.bar.com/netdoc/print"/>）によって、印刷（print）要求時のＳＯＡＰＡｃｔｉｏｎヘッダの値が「http://foo.bar.com/netdoc/print」であることを定義する。
【００７２】
次に、<input>タグ５４によって定義される定義情報５５において、記述<sb:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" use="literal" namespace="http://foo.bar.com/netdoc/"/>によって、入力時のエンコーディング形式を定義し、<output>タグ５６によって定義される定義情報５７において、記述<sb:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" use="literal" namespace="http://foo.bar.com/netdoc/"/>によって、出力時のエンコーディング形式を定義する。
【００７３】
そして、ネットワークの端点の集まりを定義する<service>タグ５８（記述<service name="netdoc">）によって定義される定義情報５９において、<port>タグ６０（記述<port name="netdocPort" binding="tns:netdocHttpBinding">）によってネットワークの端点の１つとなるnetdocPortが定義され、更に、記述<sb:address location="http://printer.foo.bar.com/netdoc"/>によって、そのネットワークの端点のアドレス位置が定義される。つまり、サービス名「netdoc」のバインディングは「netdocHttpBinding」であり、サービスのＵＲＬ（Uniform Resource Locator）は「http://printer.foo.bar.com/netdoc」であることが定義される。
【００７４】
このようにＷＳＤＬで定義されたインターフェイス定義ファイル５２２及び方定義ファイル５２３によって、データ型が決定され、操作が決定され、また、ＵＲＬ及びＳＯＡＰＡｃｔｉｏｎヘッダが決定される。
【００７５】
次に、図１３及び図１４に示すインターフェイス定義が入力された場合のハンドラ処理部及びＷｅｂサービス機能の関数宣言と、入力メッセージ及び出力メッセージの構造体定義について説明する。先ず、図１１のステップＳ５２６にて生成されるハンドラ処理部とＷｅｂサービス機能の関数宣言について図１５及び図１６で説明する。
【００７６】
図１５は、ハンドラ処理部の関数宣言を説明する図である。図１５において、ハンドラ処理部の関数宣言は、例えば、サービス名を示す「netdoc」と操作名を示す「print」と、更にハンドラ処理部を示す「handler」による「netdoc_print_handler」によって関数名とし、これをハンドラ処理部の関数として宣言する。この例では、「netdoc_print_handler」によって、印刷操作を行うサービスに対応するハンドラ処理部を示す。ハンドラ処理部の関数宣言は、ハンドラソースコード５３２のヘッダファイルに出力される。
【００７７】
図１６は、Ｗｅｂサービス機能の関数宣言を説明する図である。図１６において、Ｗｅｂサービス機能の関数宣言は、例えば、サービス名を示す「netdoc」と操作名を示す「print」とによる「netdoc_print」を関数名とし、これをＷｅｂサービス機能の関数として宣言する。また、Ｗｅｂサービス機能の関数の引数は、サービス名を示す「Netdoc」と入力メッセージ名を示す「printInput」とによる「Netdoc_printInput」によって入力メッセージの構造体を指定し、また、サービス名を示す「Netdoc」と出力メッセージ名を示す「printOutput」とによる「Netdoc_printOutput」によって出力メッセージの構造体を指定する。Ｗｅｂサービス機能の関数宣言は、ハンドラソースコード５３２のヘッダファイルに出力される。
【００７８】
図１２のステップＳ５３５にて生成される入力メッセージの構造体定義について図１７で説明する。図１７は、入力メッセージの構造体定義を説明する図である。図１７において、入力メッセージの構造体は、例えば、サービス名を示す「netdoc」と入力メッセージ名を示す「printInput」とによる「_Netdoc_printInput」を構造体として定義する。また、構造体「_Netdoc_printInput」は、パラメータ型を「unsigned int」によって符号なし整数としてパラメータ名「fileId」と、パラメータ型を「unsigned int」によって符号なし整数としてパラメータ名「count」とで構成される。入力メッセージの構造体は、ハンドラソースコード５３２のヘッダファイルに出力される。
【００７９】
図１２のステップＳ５３６にて生成される出力メッセージの構造体定義について図１８で説明する。図１８は、出力メッセージの構造体定義を説明する図である。図１８において、出力メッセージの構造体は、例えば、サービス名を示す「netdoc」と出力メッセージ名を示す「printOutput」とによる「_Netdoc_printOutput」を構造体として定義する。また、構造体「_Netdoc_printOutput」は、パラメータ型を「unsigned int」によって符号なし整数としてパラメータ名「requestId」で構成される。出力メッセージの構造体は、ハンドラソースコード５３２のヘッダファイルに出力される。
【００８０】
図１３及び図１４に示すインターフェイス定義に基づいて自動生成されるハンドラソースコード５３２のプログラムの例について図１９で説明する。図１９は、自動生成されたハンドラソースコードの例を示す図である。図１９において、実際のソースコードを記載する代わりに、ステップ毎の処理概要を記してある。
【００８１】
図１９に示すようなハンドラソースコードでは、記述９０１に示すように、図１５に示す宣言されたハンドラ処理部の関数名が最初に記述される。このハンドラ処理部は、Ｗｅｂサービス機能としての印刷機能のためのハンドラである。以下、印刷ハンドラと言う。ステップＳ１２０からＳ１３１までのコードは、要素木に基づいて処理リクエストを示すＳＯＡＰエンベロープを解析するコードである。また、ステップＳ１４０からＳ１４８までのコードは、処理レスポンスを示すＳＯＡＰエンベロープを作成するための要素木を生成するたコードである。
【００８２】
印刷ハンドラにてローカルに定義される変数の記述の後、印刷ハンドラがルート要素を取得するためのステップＳ１２０が記載される。ステップＳ１２０が実行された結果として、ルート要素（Ｅｎｖｅｌｏｐｅ要素）を取得する。子ノードリストを取得するステップＳ１２１が記載される。ステップＳ１２１が実行された結果として、印刷ハンドラは要素木から「Header」及び「Body」を取得することになる。
【００８３】
子ノードリストからタグ名がＢｏｄｙの要素を検索して取得するステップＳ１２２が記述される。Ｂｏｄｙ要素の最初の子ノードを取得するステップＳ１２３が記述される。ステップＳ１２３が実行された結果として、印刷ハンドラは操作名を示すｐｒｉｎｔ要素を取得する。ｐｒｉｎｔ要素の子ノードリストを取得するステップＳ１２４が記述される。取得した子ノードリストからタグ名を順に取得するステップＳ１２５（繰り返しの判断をステップＳ１３２とする）が記述される。
【００８４】
タグ名がｆｉｌｅＩＤであるか否かを判断するステップＳ１２６が記述される。タグ名がｆｉｌｅＩＤである場合に、タグ名がｆｉｌｅＩＤの最初の子ノードを取得するステップＳ１２７が記述される。ステップＳ１２７が実行された結果として、印刷ハンドラはテキストノードを取得する。取得したテキストノードからテキストデータを抽出して整数に変換するステップＳ１２８が記述される。ステップＳ１２８が実行された結果として、印刷ハンドラはファイルＩＤパラメータとして値を所定の構造体に設定する。
【００８５】
タグ名がｃｏｕｎｔであるか否かを判断するステップＳ１２９が記述される。タグ名がｃｏｕｎｔである場合に、タグ名がｃｏｕｎｔの最初の子ノードを取得するステップＳ１３０が記述される。ステップＳ１３０が実行された結果として、印刷ハンドラはテキストノードを取得する。取得したテキストノードを抽出して整数に変換するステップＳ１３１が記述される。ステップＳ１３１が実行された結果として、印刷ハンドラは部数パラメーとして値を所定の構造体に設定する。
【００８６】
上記ステップＳ１２６からＳ１３１までの記述９０２は、印刷ハンドラでの例であるが、他のハンドラでは、入力メッセージのパラメータ定義によってタグ名毎の判断及びタグ名に対する処理は変化する。
【００８７】
記述９０２を実行した場合に取得した各パラメータの値を入力メッセージの構造体データとして生成し、データ名「in」に設定するステップＳ１３３が記述される。
【００８８】
入力メッセージの構造体データを引数とした図１６に示すような宣言されたＷｅｂサービス機能の関数「netdoc_print(in, out)」をコールするステップＳ１３４が記述される。
【００８９】
ステップＳ１３４が実行された場合に、戻り値がエラーであるかを判断し、エラーである場合、SOAPFaultをresponseDocumentに設定するステップＳ１３５が記述される。
【００９０】
以下ステップＳ１４０からＳ１４８までは、Ｗｅｂサービス機能の関数「netdoc_print(in, out)」の実行によってエラーでなかった場合に処理レスポンスを生成するための要素木を生成するステップが記述される。
【００９１】
Ｅｎｖｅｌｏｐｅ要素を生成するステップＳ１４０が記述される。Ｂｏｄｙ要素を生成するステップＳ１４１が記述される。Ｂｏｄｙ要素をＥｎｖｅｌｏｐｅ要素に接続するステップＳ１４２が記述される。ｐｒｉｎｔＲｅｓｐｏｎｓｅ要素を生成するステップＳ１４３が記述される。ｐｒｉｎｔＲｅｓｐｏｎｓｅ要素をＢｏｄｙ要素に接続するステップＳ１４４が記述される。ｒｅｑｕｅｓｔＩｄ要素を生成するステップＳ１４５が記述される。ｐｒｉｎｔＲｅｓｐｏｎｓｅ要素をＢｏｄｙ要素に接続するステップＳ１４６が記述される。
【００９２】
ステップＳ１３４が実行された結果として得られたリクエストＩＤを用いてテキストノードを生成するステップＳ１４７が記述される。テキストノードをｒｅｑｕｅｓｔＩｄ要素に接続するステップＳ１４８が記述される。
【００９３】
印刷ハンドラでの処理結果を示すresponseDocumentを戻り値とするステップＳ１４９が記述される。
【００９４】
このようにして記述されたハンドラソースコード５３２は、印刷ハンドラに限るものではなく、同様のステップを他の操作に対応させて生成することができる。従って、上記ハンドラソースコードにおける操作名「print」は、定義によって変化する。
【００９５】
このように、ハンドラソースコード５３２が自動生成されることによって、単純で同じようなコードを大量に生成することができるため、開発者による単純ミスによるバグが入り込むといった問題を解消することができる。また、短時間でハンドラソースコード５３２を生成することができるため、開発者の負担を軽減することができる。更に、開発者は、ＸＭＬによるメッセージのデータ形式とＷｅｂサービス機能におけるプログラム言語にて処理可能なデータ形式との違いを意識することなく、Ｗｅｂサービス機能を開発することができる。
【００９６】
このようにハンドラ自動生成部５１０によって、インターフェイス定義５２１に基づいて、各Ｗｅｂサービス機能の関数に対応させて自動生成されたハンドラソースコード５３２及びタイプライブラリ５３３は、Ｗｅｂサービス機能の関数他、必要な処理部を構成するソースコードと共に、コンパイルされる。
【００９７】
以下、上記自動生成されたハンドラ処理部が組み込まれた画像形成装置の実施例について説明する。
【００９８】
多種の画像形成機能を融合する画像形成装置（以下、融合機と言う）は、例えば、図２０に示すような機能構成を成す。図２０は、本発明の一実施例に係る多種の画像形成機能を融合する融合機の機能構成を示すブロック図である。
【００９９】
図２０において、融合機１２００は、プロッタ１２０１と、スキャナ１２０２と、その他ハードウェアリソース１２０３などを有するとともに、プラットフォーム１２２０とアプリケーション１２３０とから構成されるソフトウェア群１２１０と、融合機起動部１２４０とを備えている。
【０１００】
融合機起動部１２４０は、融合機１２００の電源投入時に先ず始めに実行され、プラットフォーム１２２０やアプリケーション１２３０を起動する。
【０１０１】
プラットフォーム１２２０は、アプリケーション１２３０からの処理要求を解釈して、ハードウェア資源の獲得要求を発生させる下記に示すコントロールサービス１２５０と、一または複数のハードウェア資源の管理をおこない、コントロールサービス１２５０からの獲得要求を調停するシステムリソースマネージャー（ＳＲＭ（System Resource Manager）１２２３）と、ＯＳ（Operating System）１２２１とを有する。
【０１０２】
このコントロールサービス１２５０は、複数のサービスモジュールにより形成され、具体的には、ＳＣＳ（System Control Service）１２２２と、ＥＣＳ（(Engine Control Service)１２２４と、ＭＣＳ（Memory Control Service）１２２５と、ＯＣＳ（Operation panel Control Service）１２２６と、ＦＣＳ（FAX Control Service）１２２７と、ＮＣＳ（Network Control Service）１２２８と、ＩＭＨ（Imaging Memory Handler）１２２９とがある。なお、このプラットフォーム１２２０は、あらかじめ定義された関数により前記アプリケーションからの処理要求を受信可能とするアプリケーションプログラムインターフェースを有する。
【０１０３】
ＯＳ１２２１は、ＵＮＩＸ（登録商標）などのオペレーティング・システムであり、プラットフォーム１２２０並びにアプリケーション１２３０の各ソフトウェアをそれぞれプロセスとして並列実行する。オープンソースのＵＮＩＸ（登録商標）を用いることにより、プログラムの安全性を確保できるとともに、ネットワーク対応可能となり、ソースコードの入手も容易となる。さらに、ＯＳ、ＴＣＰ／ＩＰのロイヤリティが不要であり、アウトソーシングも容易となる。
【０１０４】
ＳＲＭ１２２３は、ＳＣＳ１２２２とともにシステムの制御およびリソースの管理をおこなうものであり、スキャナやプロッタなどのエンジン部、メモリ、ＨＤＤファイル、ホストＩ／Ｏ（セントロＩ／Ｆ、ネットワークＩ／Ｆ、ＩＥＥＥ１３９４Ｉ／Ｆ、ＲＳ２３２ＣＩ／Ｆなど）のハードウェア資源を利用する上位層からの要求にしたがって調停をおこない、実行制御する。
【０１０５】
具体的には、このＳＲＭ１２２３は、要求されたハードウェア資源が利用可能であるかどうか（他の要求により利用されていないかどうか）を判断し、利用可能であれば要求されたハードウェア資源が利用可能である旨を上位層に伝える。また、上位層からの要求に対してハードウェア資源の利用スケジューリングをおこない、要求内容（たとえば、プリンタエンジンによる紙搬送と作像動作、メモリ確保、ファイル生成など）を直接実施するようにしてもよい。
【０１０６】
ＳＣＳ１２２２は、アプリ管理（機能１）、操作部制御（機能２）、システム画面表示（ジョブリスト画面、カウンタ表示画面など）（機能３）、ＬＥＤ表示（機能４）、リソース管理（機能５）、割り込みアプリ制御（機能６）等の複数の機能を行う。具体的には、アプリ管理（機能１）では、アプリの登録と、その情報を他のアプリに通知する処理をおこなう。操作部制御（機能２）では、アプリの操作部使用権の排他制御をおこなう。システム画面表示（機能３）では、操作部使用権を持つアプリからの要求内容に応じて、エンジン部の状態に対応する警告画面の表示をおこなう。ＬＥＤ表示（機能４）では、警告ＬＥＤ、アプリキーなどのシステムＬＥＤの表示制御をおこなう。リソース管理（機能５）では、アプリがＥＣＳを使ってジョブを実行するにあたって、排他しなければならないエンジンリソース（スキャナ、ステープルなど）の排他制御のためのサービスをおこなう。割り込みアプリ制御（機能６）では、特定のアプリを優先動作させるための制御及びサービスをおこなう。
【０１０７】
ＥＣＳ１２２４は、プロッタ１２０１、スキャナ１２０２、その他ハードウェアリソース１２０３などのエンジン部を制御するものであり、画像読み込みと印刷動作、状態通知、ジャムリカバリなどをおこなう。
【０１０８】
ＭＣＳ１２２５は、メモリ制御をおこなうものであり、具体的には、画像メモリの取得および解放、ハードディスク装置（ＨＤＤ）の利用、画像データの圧縮および伸張などをおこなう。
【０１０９】
ＯＣＳ１２２６は、オペレータと本体制御間の情報伝達手段となる操作パネルを制御するモジュールであり、オペレータのキー操作イベントを本体制御に通知する処理、各アプリがＧＵＩを構築するためのライブラリ関数を提供する処理、構築されたＧＵＩ情報をアプリ別に管理する処理、操作パネル上への表示反映処理などをおこなう。
【０１１０】
ＦＣＳ１２２７は、システムコントローラの各アプリ層からＰＳＴＮ／ＩＳＤＮ網を使ったファクシミリ送受信、ＢＫＭ（バックアップＳＲＡＭ）で管理されている各種ファクシミリデータの登録／引用、ファクシミリ読み取り、ファクシミリ受信印刷、融合送受信をおこなうためのＡＰＩ（Application Program Interface）を提供する。
【０１１１】
ＮＣＳ１２２８は、ネットワークＩ／Ｏを必要とするアプリケーションに対して共通に利用できるサービスを提供するためのモジュール群であり、ネットワーク側から各プロトコルによって受信したデータを各アプリケーションに振り分けたり、アプリケーションからデータをネットワーク側に送信する際の仲介をおこなう。
【０１１２】
本実施例において、ＮＣＳ１２２８は、複数のプロトコルのうちｈｔｔｐ（Hypertext Transfer Protocol）デーモンによって、インターネットを介して接続されるネットワーク機器とのデータ通信をＨＴＴＰ（Hypertext Transfer Protocol）で制御し、ＨＴＴＰリクエストヘッダで指定される処理に必要な複数のＷｅｂサービスを関数コールによって起動し、その複数のＷｅｂサービスによる処理結果をＨＴＴＰレスポンスで該ネットワーク機器へ通知する。Ｗｅｂサービスは、例えば、ＸＭＬによって記述されたメッセージに従って処理を行う。
【０１１３】
ＩＭＨ１２２９は、イメージデータを仮想メモリ領域（ユーザー仮想空間）から物理メモリへマップする。プロセスの起動に応じて、システムコールを行ない、プロセス用の仮想メモリ領域をマップしたり、マップした仮想メモリ領域をプロセスの終了時に解放する処理等を行う。
【０１１４】
アプリケーション１２３０は、ページ記述言語（ＰＤＬ）、ＰＣＬおよびポストスクリプト（ＰＳ）を有するプリンタ用のアプリケーションであるプリンタアプリ１２１１と、コピー用アプリケーションであるコピーアプリ１２１２と、ファクシミリ用アプリケーションであるファックスアプリ１２１３と、スキャナ用アプリケーションであるスキャナアプリ１２１４と、ネットファイル用アプリケーションであるネットファイルアプリ１２１５と、工程検査用アプリケーションである工程検査アプリ１２１６と、配信用アプリケーションである配信アプリ１２１７と、実行した処理結果をＷｅｂサービスとして提供するＷｅｂサービスアプリ１２１８とを有する。各アプリケーション１２１１〜１２１８は、プラットフォーム１２２０上の各プロセスを利用して動作実行し得るため、画面制御、キー操作制御およびジョブ生成などをおこなう画面表示制御プログラムがその主体となる。なお、ＮＣＳ１２２８により接続されたネットワークを介して新たなアプリケーションをネットワーク経由で搭載することもできる。また、各アプリケーションはアプリケーションごとに追加または削除することができる。
【０１１５】
ここで、Ｗｅｂサービスアプリ１２１８とは、ＮＣＳ１２２８によって通知されるＨＴＴＰリクエスト対応する処理を実行するアプリケーションであって、その処理結果は、ＨＴＴＰレスポンスとしてＮＣＳ１２２８によってＨＴＴＰリクエストを行ったネットワーク機器へ提供される。
【０１１６】
このように、融合機１２００は、各アプリで共通的に必要となる処理をプラットフォーム１２２０で一元的に処理する。
【０１１７】
次に、融合機１２００のハードウェア構成について説明する。図２１は、図２０に示す融合機のハードウェア構成を示すブロック図である。図２１に示すように、この融合機１２００は、オペレーションパネル１３１０と、ＦＣＵ（ファックスコントロールユニット）１３２０と、プロッタ１２０１、スキャナ１２０２及びその他ハードウェアで構成されるエンジン部１３５０と、コントローラ１３００のＡＳＩＣ１３０１とをＰＣＩ（Peripheral Component Interconnect）バス等で接続した構成となる。ＦＣＵ１３２０は、受信したファックスデータを格納するための不揮発性メモリ１３２１と、ＦＣＵ１３２０内での時間を計測するためのＲＴＣ（Real Time Clock）１３２２とを有し、通常Ｇ３規格に従ってファックスデータの送受信を行う。ＦＣＵ１３２０は、オプションとして更にＧ３規格とＧ４規格とを搭載しても良い。
【０１１８】
コントローラ１３００は、ＡＳＩＣ１３０１にＭＥＭ−Ｃ１３０２、ＨＤＤ（Hard Disk Drive）１３０３などを接続するとともに、このＡＳＩＣ１３０１とＣＰＵ１３０４とをＣＰＵチップセットのＮＢ１３０５を介して接続している。このように、ＮＢ１３０５を介して接続する理由は、ＣＰＵ１３０４自体のインターフェイスが公開されていないためである。
【０１１９】
ここで、このＡＳＩＣ１３０１とＮＢ１３０５は、単にＰＣＩを介して接続されているのではなく、ＡＧＰ１３０８を介して接続されている。このようにＡＧＰ１３０８を介して接続することとした理由は、この融合機１２００がプラットフォーム１２２０やアプリケーション１２３０を形成する複数のプロセスを実行制御する関係上、これらを低速のＰＣＩで接続したのでは、パフォーマンスが低下するからである。
【０１２０】
ＣＰＵ１３０４は、融合機１２００の全体制御をおこなうものであり、具体的には、ＯＳ１２２１上でプラットフォーム１２２０を形成するＳＣＳ１２２２、ＳＲＭ１２２３、ＥＣＳ１２２４、ＭＣＳ１２２５、ＯＣＳ１２２６、ＦＣＳ１２２７、ＮＣＳ１２２８をそれぞれプロセスとして起動して実行させるとともに、アプリケーション１２３０を形成するプリンタアプリ１２１１、コピーアプリ１２１２、ファックスアプリ１２１３、スキャナアプリ１２１４、ネットファイルアプリ１２１５、工程検査アプリ１２１６、配信アプリ１２１７、Ｗｅｂサービスアプリ１２１８を起動して実行させる。
【０１２１】
ＮＢ１３０５は、ＣＰＵ１３０４とＭＥＭ−Ｐ１３０６、ＳＢ１３０７、ＡＳＩＣ１３０１とを接続するためのブリッジであり、ＭＥＭ−Ｐ１３０６は、融合機の描画用メモリなどとして用いるシステムメモリであり、ＭＥＭ−Ｃ１３０２は、コピー用画像バッファ、符号バッファとして用いるローカルメモリであり、ＡＳＩＣ１３０１は、画像処理用のハードウェア要素を有する画像処理用途向けのＩＣである。
【０１２２】
ＮＢ１３０５は、ＰＣＩバスを介してＳＢ１３０７と接続する他、ネットワーク通信を制御するＮＩＣ（Network Interface Card）１３１１と、パーソナルコンピュータと接続し大容量の画像データの送受信を可能とするＵＳＢ（Universal Serial Bus）１３１２及びＩＥＥＥ1394１３１３と、パラレルケーブルによって接続可能なセントロニクス１３１４と接続する。ＳＢ１３０７は、ＮＢ１３０５とＲＯＭ、ＰＣＩデバイス、周辺デバイスとを接続するためのブリッジである。ＳＢ１３０７は、コントローラ１３００での時間を計測するＲＴＣ（Real Time Clock）１３２３を有する。
【０１２３】
ＨＤＤ１３１０は、画像データの蓄積、プログラムの蓄積、フォントデータの蓄積、フォームの蓄積を行うためのストレージであり、オペレーションパネル１３１０は、操作者からの入力操作の受け付け並びに操作者に向けた表示をおこなう操作部である。
【０１２４】
したがって、ＡＳＩＣ１３０１には、ＭＥＭ−Ｃ１３０２を接続するためのＲＡＭインターフェイスと、ＨＤＤ１３１０を接続するためのハードディスクインターフェースが設けられ、これらの記憶部に対して画像データの入出力をおこなう場合には、入出力先がＲＡＭインターフェイスまたはハードディスクインターフェースに切り替えられる。
【０１２５】
ＡＧＰ１３０８は、グラフィック処理を高速化するために提案されたグラフィックスアクセラレーターカード用のバスインターフェイスであり、システムメモリに高スループットで直接アクセスすることにより、グラフィックスアクセラレーターカードを高速にする。
【０１２６】
次に、上記構成を有する融合機１２００において、ＸＭＬ（Extensible Markup Language）によるＳＯＡＰ（Simple Object Access Protocol）に従ったＷｅｂサービスを提供可能とする構成について詳述する。Ｗｅｂサービスファンクションは、例えば、Ｃ言語などのプログラム言語で記述されたソフトウェア（アプリケーション）である。ＳＯＡＰに従って記述されるＸＭＬによる処理内容をメッセージとしてＷｅｂサービスファンクションが理解できるように、構文の異なるＸＭＬとプログラム言語との間をハンドリングする処理部（ハンドラ）が必要となる。以下に、印刷する印刷Ｗｅｂサービス、文書リストを取得する文書リスト取得Ｗｅｂサービス、文書情報を取得する文書情報取得Ｗｅｂサービスを例として、図２２で説明する。
【０１２７】
図２２は、Ｗｅｂサービスを実現するための構成例を示す図である。図２２において、印刷Ｗｅｂサービス、文書リスト取得Ｗｅｂサービス、文書情報取得Ｗｅｂサービスが、Ｗｅｂサービスアプリ１２１８にて提供される場合を示す。これらＷｅｂサービスは、アプリケーション１２３０の別の機能としてＷｅｂサービスアプリ１２１８から独立した構成としても良い。図２２中、図２０に示す融合機１２００の機能構成のうち主要な機能構成のみが図示され、他の機能構成は省略される。
【０１２８】
図２２において、Ｗｅｂサービスを実現するために、コントロールサービス１２５０とＷｅｂサービスアプリ１２１８との間に、接続される機器との間のデータの送受信制御する中間層が構成される。
【０１２９】
コントロールサービス１２５０は、Ｗｅｂサービスアプリ１２１８によるＷｅｂサービスを実現する構成部分として、ＥＣＳ１２２４と、ＭＣＳ１２２５と、ＮＣＳ１２２８とを有する。ＮＣＳ１２２８は、ＨＴＴＰを制御するＨＴＴＰデーモン２と、ＨＴＴＰデーモン２とＷｅｂサービスアプリ１２１８との接続処理の仲介をする要求仲介デーモン７とを有する。
【０１３０】
また、中間層１２５５は、接続される機器との間のデータの送受信制御を吸収する構成部分として、シーケンス制御ライブラリ１００と、ＸＭＬライブラリ１１０と、ＳＯＡＰライブラリ１２０と、ジョブ管理部３１０と、ファイル管理部３１１とを有する。シーケンス制御ライブラリ１００は、更に、ＨＴＴＰ接続管理部１０１と、ＨＴＴＰサービス実行部１０２と、ＰＯＳＴメソッド分配処理部１０５とを有する。ＸＭＬライブラリ１１０は、ＸＭＬ処理部１１５と、ＸＭＬプロセッサ１１６と、ＸＭＬシリアライザ１１７とを有する。ＳＯＡＰライブラリ１２０は、ＳＯＡＰアクション振分処理部１２１を有する。
【０１３１】
更に、Ｗｅｂサービスアプリ１２１８は、Ｗｅｂサービスを実現するための構成部分として、要素木解析・生成ハンドラ２００と、Ｗｅｂサービスファンクション（ＷＳＦ）３００とを有する。要素木解析・生成ハンドラ２００は、機器間におけるＳＯＡＰに従ったメッセージのデータ形式による構文を解析し、Ｗｅｂサービスファンクション３００にて処理可能なデータ形式に変換する処理部であって、複数の要素木解析・生成ハンドラを有し、例えば、印刷ハンドラ２０１と、文書リスト取得ハンドラ２０２と、文書情報取得ハンドラ２０３とを有する。ここで、印刷ハンドラ２０１、文書リスト取得ハンドラ２０２、文書情報取得ハンドラ２０３の夫々は、図１に示すハンドラ自動生成部５１０によって自動生成されたソースコード５３１のハンドラソースコード５３２及びタイプライブラリ５３３に基づくハンドラ処理部である。
【０１３２】
Ｗｅｂサービスファンクション３００は、複数のＷｅｂサービスファンクションを有し、例えば、印刷機能３０１と、文書リスト取得機能３０２と、文書情報取得機能３０３とを有する。この場合、印刷ハンドラ２０１は、印刷機能３０１に対する処理の内容を示すＳＯＡＰに従ったメッセージのデータ形式を構文解析し、印刷機能３０１が処理可能なデータ形式に変換して印刷機能３０１に処理を要求する。また、印刷ハンドラ２０１は、印刷機能３０１からの応答をＳＯＡＰに従ったデータ形式にてメッセージとして生成する。文書リスト取得ハンドラ２０２及び文書情報取得ハンドラ２０３は、夫々、文書リスト取得機能３０２及び文書情報取得機能３０３に対して同様の処理を行う。
【０１３３】
印刷機能３０１は、入力パラメータとしてファイルＩＤと部数を受け取り、ジョブ管理部ファイルＩＤと部数を指定して印刷要求をジョブ管理部３１０に発行する。ジョブ管理部３１０から受け取ったリクエストＩＤを出力パラメータとして返す。文書リスト取得機能３０２は、ファイル管理部３１１にファイルリストを要求し、ファイル管理部３１１から受け取ったＩＤのリストを出力パラメータとして返す。文書情報取得機能３０３は、入力パラメータとしてファイルＩＤを受け取り、ファイル管理部３１１にファイルＩＤを指定してファイル情報を要求する。ファイル管理部３１１から受け取ったファイル情報を出力パラメータとして返す。
【０１３４】
ジョブ管理部３１０は、ジョブのキュー及び実行結果を管理する。また、ＥＣＳ１２２４及びＭＣＳ１１２５と通信して蓄積文書の印刷処理を実行する。ファイル管理部３１１は、ＭＣＳ１２２５と通信してファイル情報を取得する。
【０１３５】
以下、ＨＴＴＰリクエストを受信してからＨＴＴＰレスポンスを送信するまでの処理について図２３及び図２４を参照しつつ説明する。図２３及び図２４は、ＳＯＡＰによるＷｅｂサービスの提供処理について説明するフローチャート図である。
【０１３６】
ＮＣＳ１２２８のＨＴＴＰデーモン２がネットワーク１５からの接続要求を受信する（ステップＳ１１００）。その接続要求は要求仲介デーモン７を介してＷｅｂサービスアプリ１２１８のＨＴＴＰ接続管理部１０１に通知される。その後、ＨＴＴＰ接続管理部１０１は、その接続要求をＨＴＴＰに従ってサービスを提供するＨＴＴＰサービス実行部１０２に通知する。通知を受けたＨＴＴＰサービス実行部１０２は、ＨＴＴＰデーモン２に接続を行い、ＨＴＴＰリクエストを取得する。このような制御をＮＣＳ１２２８で行うことにより、必要時のみＨＴＴＰによる通信制御をすることができる。よって、常時ＨＴＴＰ通信制御をする場合に比べて、通信制御に必要な資源を効果的に利用することができる。
【０１３７】
ＨＴＴＰサービス実行部１０２は、ネットワーク１５を介して受信したＨＴＴＰリクエストからデータ送信方法を示すＨＴＴＰメソッドを解析して、ＧＥＴメソッドであるか否かをチェックする（ステップＳ１１０１）。ＧＥＴメソッドである場合、ＧＥＴメソッドによるＷｅｂサービスの提供を実行する（ステップＳ１１０２）。つまり、ＳＯＡＰによるＷｅｂサービス以外のＷｅｂサービスの提供を行う。
【０１３８】
一方、ＧＥＴメソッドでない場合、ＰＯＳＴメソッドであるか否かをチェックする（ステップＳ１１０３）。ＰＯＳＴメソッドでない場合、ステップＳ１１０７へ進み、エラー処理を行い、ＳＯＡＰによるＷｅｂサービスの提供処理を終了する。ＰＯＳＴメソッドである場合、ＰＯＳＴメソッド分配処理部１０５をコールする。ＰＯＳＴメソッド分配処理部１０５は、ＨＴＴＰリクエストヘッダ情報を解析し、ＨＴＴＰボディの記述形式がＸＭＬであることを確認する（ステップＳ１１０４）。つまり、ＨＴＴＰレスポンスヘッダのContent-Typeがtext/xmlを指定しているか否かを判断する。ＸＭＬでない場合、ステップＳ１１０７へ進み、エラー処理を行う。一方、ＸＭＬである場合、ＸＭＬコンテンツハンドラ１１１をコールする。
【０１３９】
ＸＭＬ処理部１１５は、ＰＯＳＴメソッドハンドラとして、ＸＭＬプロセッサ１１６によって、ＨＴＴＰボディのＸＭＬの構文を解析し、ＸＭＬで記述されるタグ間の関連を木構造で示すリクエストの要素木を作成する（ステップＳ１１０５）。構文解析結果がエラーか否かを判断する（ステップＳ１１０６）。構文解析結果がエラーの場合、ステップＳ１１０７へ進み、エラー処理を行う。一方、構文解析結果が正常の場合、図２４のステップＳ１１０９へ進む。
【０１４０】
ＳＯＡＰアクション振分処理部１２１は、ＨＴＴＰリクエストのＳＯＡＰＡｃｔｉｏｎヘッダを解析して、ＵＲＩ（Uniform Resource Indicator）により異なる要素木解析・生成ハンドラ２００にＨＴＴＰリクエストを振り分ける（ステップＳ１１０９）。この場合、印刷Ｗｅｂサービスを指定するＵＲＩに対して印刷ハンドラ２０１、文書リスト取得Ｗｅｂサービスを指定するＵＲＩに対して文書リスト取得ハンドラ２０２、及び、文書情報取得Ｗｅｂサービスを指定するＵＲＩに対して文書情報取得ハンドラ２０３に、ＨＴＴＰリクエスト及び要素木とが振り分けられる。
【０１４１】
各要素木解析・生成ハンドラ２００は、リクエストの要素木を解析してＣ言語の構造体データに変換する（ステップＳ１１１０）。その後、変換した構造体データを引数として、ＨＴＴＰリクエストで指定されるＵＲＩに対応するＷｅｂサービスファンクション３００をコールする（ステップＳ１１１１）。この場合、印刷ハンドラ２０１は印刷機能３０１、文書リスト取得ハンドラ２０２は文書リスト取得機能３０２、文書情報取得ハンドラ２０３は文書情報取得機能３０３をコールする。
【０１４２】
Ｗｅｂサービスファンクション３００は、所定のＷｅｂサービスのロジックを実行して、構造体データとして結果を返す（ステップＳ１１１２）。この場合、印刷機能３０１、文書リスト取得機能３０２、文書情報取得機能３０３は、各Ｗｅｂサービスのロジックを実行して、その結果を返す。返される結果は、プログラム言語で処理可能なデータ形式（例えば、Ｃ言語の構造体）である。
【０１４３】
各要素木解析・生成ハンドラ２００は、受け取った結果の構造体データからレスポンスの要素木を生成する（ステップＳ１１１３）。各要素木解析・生成ハンドラ２００によって生成された要素木は、例えば、ＸＭＬのタグ間の関係をタグからタグへのポインタによるリンクによって、そのデータ構造を示す。以後、ＳＯＡＰアクション振分処理部１２１を介して、ＸＭＬシリアライザ１１７によって、レスポンスの要素木からＸＭＬに変換される。ＸＭＬシリアライザ１１７は、要素木をテキストで示すＸＭＬに変換する。変換されたＸＭＬは、ＳＯＡＰに従ったＨＴＴＰボディに構成され、所定のＨＴＴＰヘッダが付加された後、ＨＴＴＰレスポンスとして送信される（ステップＳ１１１４）。
【０１４４】
上述より、要素木解析・生成ハンドラ２００が要素木をＣ言語の構造体に応じたデータ変換を行う。また、Ｃ言語の構造体データから要素木への変換を行う。開発者は、ＳＯＡＰ及びＸＭＬの知識が無くても、Ｗｅｂサービスをプログラム言語で開発することができる。
【０１４５】
Ｗｅｂサービスファンクション３００を起動時の初期化処理では、モジュール間の（直線で示される）接続が行われ、図２２に示すように構成される。初期化処理では、ＰＯＳＴメソッド分配処理部１０５がＰＯＳＴメソッドハンドラとしてシーケンス制御ライブラリ１００に接続することで開始され、ＸＭＬ処理部１１５のＰＯＳＴメソッド分配処理部１０５への登録、ＳＯＡＰアクション振分処理部１２１のＸＭＬ処理部１１５への登録、要素木解析・生成ハンドラ２００のＳＯＡＰアクション振分処理部１２１への登録が行われる。
【０１４６】
次に、要素木解析・生成ハンドラ２００の印刷ハンドラ２０１を例にして、印刷ハンドラ２０１における要素木の解析処理について図２５、図２６及び図２７で説明する。図２５は、ＸＭＬを使用したＳＯＡＰに従ったＨＴＴＰリクエストの記述例を示す図である。図２６は、ＸＭＬプロセッサによって変換された要素木の例を示す図である。図２７は、印刷ハンドラによる要素木解析処理を説明するためのフローチャート図である。
【０１４７】
印刷Ｗｅｂサービスを依頼する図２５に示すようなＨＴＴＰリクエストの場合、ＸＭＬプロセッサ１１２は、<SOAP-ENV:Envelope>で始まるＨＴＴＰボディ２０を要素木に変換する。タグ名２１「Envelope」をルート要素とし、ルート要素の子ノードとしてタグ名２２「Header」及びタグ名２３「Body」を関連づける。更に、タグ名２３「Body」の子ノードをタグ名２４「print」とし、更に、タグ名２４「print」の子ノードとしてタグ名２５「fileId」及びタグ名２６「count」とを関連付ける。そして、タグ名２５「fileId」及びタグ名２６「count」に、夫々、テキストデータ２７「１２３」及びテキストデータ２８「２」を関連付ける。このようにして関連付けられた要素木構造は、例えば、図２６に示されるようなデータ構造となる。図２６において、タグ名２１から２６及びテキストデータ２７から２８を楕円で示し、関連付けが矢印で示される。
【０１４８】
図２６に示すようなデータ構造となった要素木は、印刷ハンドラ２０１によって、図２７に示されるフローチャートに従って、印刷機能３０１が処理可能なプログラム言語による構造体データが生成される。図２７でのステップ番号は、図１９でのステップ番号に対応する。図２７において、印刷ハンドラ２０１は、ルート要素を取得する（ステップＳ１２０）。この場合、ルート要素は、Ｅｎｖｅｌｏｐｅ要素となる。子ノードリストを取得する（ステップＳ１２１）。つまり、タグ名２２「Header」及び２３「Body」を取得する。子ノードリストからタグ名がＢｏｄｙの要素を検索して取得する（ステップＳ１２２）。Ｂｏｄｙ要素の最初の子ノードを取得する（ステップＳ１２３）。この場合、ｐｒｉｎｔ要素を取得する。ｐｒｉｎｔ要素の子ノードリストを取得する（ステップＳ１２４）。取得した子ノードリストからタグ名を順に取得する（ステップＳ１２５）。
【０１４９】
タグ名がｆｉｌｅＩＤであるか否かを判断する（ステップＳ１２６）。タグ名がｆｉｌｅＩＤでない場合、ステップＳ１２９へ進む。一方、タグ名がｆｉｌｅＩＤである場合、タグ名がｆｉｌｅＩＤの最初の子ノードを取得する（ステップＳ１２７）。つまり、テキストノードを取得する。取得したテキストノードを抽出して整数に変換する（ステップＳ１２８）。つまり、ファイルＩＤパラメータとして、値「１２３」が所定の構造体に設定される。更に、タグ名がｃｏｕｎｔであるか否かを判断する（ステップＳ１２９）。タグ名がｃｏｕｎｔでない場合、ステップＳ１３２へ進む。一方、タグ名がｃｏｕｎｔである場合、タグ名がｃｏｕｎｔの最初の子ノードを取得する（ステップＳ１３０）。つまり、テキストノードを取得する。取得したテキストノードを抽出して整数に変換する（ステップＳ１３１）。つまり、部数パラメータとして、値「２」が所定の構造体に設定される。
【０１５０】
印刷ハンドラ２０１は、ステップＳ１２５で取得した子ノードリストから次の子ノードがあるか否かを判断する（ステップＳ１３２）。次の子ノードがある場合、ステップＳ１２５に戻り、次の子ノードを取得し、上記同様の処理を行う。次の子ノードがない場合、要素木の解析処理を終了する。
【０１５１】
このようにして解析された要素木は、印刷ハンドラ２０１によって図２８に示されるようなプログラム言語による構造体２９（「struct Netdoc_printInput」）のパラメータに値が設定される。パラメータ「unsigned int fileId」には、ステップＳ１２８によって、値「１２３」が設定される。また、パラメータ「unsigned int count」には、ステップＳ１３１によって、値「２」が設定される。
【０１５２】
Ｗｅｂサービスファンクション３００の印刷機能３０１は、ハンドラ自動生成部５１０によってＷｅｂサービス機能の関数として宣言された「netdoc_print」関数であるため（図１６参照）、「struct Netdoc_printInput *in」のようにして、ハンドラ自動生成部５１０によって入力メッセージの構造体として定義された構造体２９の構造体名「struct Netdoc_printInput」とその構造体２９へのポインタ「in」が引数３０に設定される。印刷機能３０１（「netdoc_print」関数）をコールすると、印刷機能３０１での処理結果が、例えば、構造体名「struct Netdoc_printOutput」へのポインタ「out」を示す「struct Netdoc_printOutput *out」のような引数３１で戻る。
【０１５３】
図２９は、印刷ハンドラでの処理結果の設定例を示す図である。図２９において、印刷ハンドラ２０１は、引数３１のポインタ「out」によって、処理結果を設定すべき構造体３９を取得する。構造体３９は、ハンドラ自動生成部５１０によって出力メッセージの構造体として定義された構造体である（図１８参照）。例えば、構造体３９において、処理結果として、パラメータ「unsigned int requestId」に値「１００」を設定する。
【０１５４】
次に、処理結果を示す構造体３９から要素木を生成する要素木の生成処理について図３０及び図３１で説明する。図３０でのステップ番号は、図１９でのステップ番号に対応する。図３０は、印刷ハンドラによる要素木生成処理を説明するためのフローチャート図である。図３１は、生成された要素木の例を示す図である。
【０１５５】
図３１を参照しつつ、印刷ハンドラによる要素木生成処理を説明する。図３０において、印刷ハンドラ２０１は、Ｅｎｖｅｌｏｐｅ要素３２を生成する（ステップＳ１４０）。Ｂｏｄｙ要素３３を生成する（ステップＳ１４１）。そして、Ｂｏｄｙ要素３３をＥｎｖｅｌｏｐｅ要素３２に接続する（ステップＳ１４２）。これらステップＳ１４０からＳ１４２での処理によって、ＳＯＡＰに従ったＨＴＴＰレスポンスのＨＴＴＰボディが設定される。
【０１５６】
そして、印刷ハンドラ２０１は、ｐｒｉｎｔＲｅｓｐｏｎｓｅ要素３４を生成し（ステップＳ１４３）、ｐｒｉｎｔＲｅｓｐｏｎｓｅ要素３４をＢｏｄｙ要素３３に接続する（ステップＳ１４４）。更に、ｒｅｑｕｅｓｔＩｄ要素３５を生成し（ステップＳ１４５）、ｒｅｑｕｅｓｔＩｄ要素３５をｐｒｉｎｔＲｅｓｐｏｎｓｅ要素３４に接続する（ステップＳ１４６）。
【０１５７】
印刷ハンドラ２０１は、結果として得られたリクエストＩＤより、テキストノード３６を生成して（ステップＳ１４７）、テキストノードをｒｅｑｕｅｓｔＩｄ要素３５に接続する（ステップＳ１４８）。この場合、テキストノード３６には、「１００」が設定される。
【０１５８】
このように生成された要素木は、ＸＭＬ処理部１１５及びＸＭＬシリアライザ１１２によって、図３２に示されるようなＨＴＴＰボディ３２を生成する。図３２は、要素木から変換されたＸＭＬを使用したＳＯＡＰに従ったＨＴＴＰレスポンスの記述例を示す図である。図３２において、図３１に示す各要素３２から３６は、< >で区切られるタグ内に記述され、所定の情報をＳＯＡＰに従った手順でＸＭＬにて記述される。融合機１２００は、ＨＴＴＰデーモン２によってＨＴＴＰリクエストを送信した機器へネットワーク１５を介してこのＨＴＴＰレスポンスを送信する。このようにして、融合機１２００は、ネットワーク１５を介して接続される機器へＷｅｂサービスを提供する。
【０１５９】
上記実施例より、ＸＭＬによる要素間の関連を示す要素木からＷｅｂサービス機能が処理可能なプログラム言語による入力データに変換、及び、プログラム言語による出力データを所定記述形式の要素木に変換するソースコード５３１が自動生成される。従って、単純で同じようなコードを大量に生成することができるため、開発者による単純ミスによるバグが入り込むといった問題を解消することができる。また、短時間でハンドラソースコード５３２を生成することができるため、開発者の負担を軽減することができる。
【０１６０】
また、自動生成されたソースコード５３１による要素木解析・生成ハンドラ２００を融合機１２００に備えることによって、開発者は、従来と同様の開発方法、例えば、Ｃ言語による開発方法によって、Ｗｅｂサービスファンクションとしてのアプリケーションの開発を行うことができる。また、既に実装されているアプリケーションを容易にＷｅｂサービスに対応するに改良することができる。
【０１６１】
また、要素木解析・生成ハンドラ２００を有する融合機１２００では、ＳＯＡＰに従うＸＭＬ記述されたメッセージをプログラム開発されたＷｅｂサービスファンクション３００が解釈することができるため、Ｗｅｂサービスファンクション３００を他システムに提供することが可能となる。よって、融合機１２００に接続されるシステム又はコンピュータ端末を限定しないため、融合機１２００の利用可能性を大幅に拡大することが可能となる。
【図面の簡単な説明】
【０１６２】
【図１】本発明の一実施例に係るハンドラ自動生成装置の機能構成を示すブロック図である。
【図２】本発明の一実施例に係るハンドラ自動生成装置のハードウェア構成を示すブロック図である。
【図３】ハンドラ自動生成処理の全体を説明するフローチャート図である。
【図４】タイプライブラリ生成処理を説明するフローチャート図である。
【図５】ソースコード生成処理における列挙型定義生成処理を説明する図である。
【図６】ソースコード生成処理における構造体の型定義生成処理を説明する図である。
【図７】ソースコード生成処理における配列の型定義生成処理を説明する図である。
【図８】ソースコード生成処理における列挙型の関数宣言処理を説明する図である。
【図９】ソースコード生成処理における構造体の関数宣言処理を説明する図である。
【図１０】ソースコード生成処理における配列の関数宣言処理を説明する図である。
【図１１】ハンドラ生成処理を説明するフローチャート図である。
【図１２】ハンドラ生成処理を説明するフローチャート図である。
【図１３】ＷＳＤＬによるインターフェイス定義の記述例を示す図である。
【図１４】ＷＳＤＬによるインターフェイス定義の記述例を示す図である。
【図１５】ハンドラ処理部の関数宣言を説明する図である。
【図１６】Ｗｅｂサービス機能の関数宣言を説明する図である。
【図１７】入力メッセージの構造体定義を説明する図である。
【図１８】出力メッセージの構造体定義を説明する図である。
【図１９】自動生成されたハンドラソースコードの例を示す図である。
【図２０】本発明の一実施例に係る多種の画像形成機能を融合する融合機の機能構成を示すブロック図である。
【図２１】図２０に示す融合機のハードウェア構成を示すブロック図である。
【図２２】Ｗｅｂサービスを実現するための構成例を示す図である。
【図２３】ＳＯＡＰによるＷｅｂサービスの提供処理について説明するフローチャート図である。
【図２４】ＳＯＡＰによるＷｅｂサービスの提供処理について説明するフローチャート図である。
【図２５】ＸＭＬを使用したＳＯＡＰに従ったＨＴＴＰリクエストの記述例を示す図である。
【図２６】ＸＭＬプロセッサによって変換された要素木の例を示す図である。
【図２７】印刷ハンドラによる要素木解析処理を説明するためのフローチャート図である。
【図２８】Ｗｅｂサービス機能の関数の引数の設定例を示す図である。
【図２９】印刷ハンドラでの処理結果の設定例を示す図である。
【図３０】印刷ハンドラによる要素木生成処理を説明するためのフローチャート図である。
【図３１】生成された要素木の例を示す図である。
【図３２】要素木から変換されたＸＭＬを使用したＳＯＡＰに従ったＨＴＴＰレスポンスの記述例を示す図である。
【符号の説明】
【０１６３】
２  ｈｔｔｐデーモン、  ７  要求仲介デーモン、  ８  ＮＡＩ
９  プロトコル制御デーモン、  １５        ネットワーク
１００  シーケンス制御ライブラリ、  １０１  ＨＴＴＰ接続管理部
１０２  ＨＴＴＰサービス実行部、  １０５  ＰＯＳＴメソッド分配処理部
１１０  ＸＭＬライブラリ、  １１５  ＸＭＬ処理部
１１６  ＸＭＬプロセッサ、  １１７  ＸＭＬシリアライザ
１２０  ＳＯＡＰライブラリ、  １２１  ＳＯＡＰアクション振分処理部
２００  要素木解析・生成ハンドラ
３００  Ｗｅｂサービスファンクション、  ５００  ハンドラ自動生成装置
５１０  ハンドラ自動生成部、  ５１１  ＸＭＬ解析部
５１２  タイプライブラリ生成部、  ５１３  ハンドラソースコード生成部
５１４  ＸＭＬスキーマ解析部、  ５１５  タイプ要素解析部、
５１６  メッセージ要素解析部、  ５１７  操作要素解析部
５２０  ファイル入力部、  ５２１  インターフェイス定義５１２
５２２  インターフェイス定義ファイル（ＷＳＤＬ）
５２３  型定義ファイル（ＸＭＬスキーマ）、  ５３０  ファイル出力
５３１  ソースコード、  ５３２  ハンドラソースコード
５３３  タイプライブラリ、  １２００  融合機、  １２０１  プロッタ
１２０２  スキャナ、  １２０３  その他ハードウェアリソース、
１２１０  ソフトウェア群、  １２３０  アプリケーション
１２２０  プラットフォーム、  １２２１  ＯＳ、  １２２２  ＳＣＳ
１２２３  ＳＲＭ、  １２２４  ＥＣＳ、  １２２５  ＭＣＳ
１２２６  ＯＣＳ、  １２２７  ＦＣＳ、  １２２８  ＮＣＳ
１２２９  ＩＭＨ、  １２４０  融合機起動部、  １３００  コントローラ
１３０１  ＡＳＩＣ、  １３０２  ＭＥＭ−Ｃ、  １３０３  ＨＤＤ
１３０４  ＣＰＵ、  １３０５  ＮＢ、  １３０６  ＭＥＭ−Ｐ
１３０７  ＳＢ、  １３０８  ＡＧＰ、  １３１０  オペレーションパネル
１３２０  ファックスコントロールユニット
１３１１  ＮＩＣ、  １３１２  ＵＳＢ、  １３１３  ＩＥＥＥ１３９４
１３１４    セントロニクス、  １３５０  エンジン部
【図１】
2005310171.tif 000003
【図２】
2005310171.tif 000004
【図３】
2005310171.tif 000005
【図４】
2005310171.tif 000006
【図５】
2005310171.tif 000007
【図６】
2005310171.tif 000008
【図７】
2005310171.tif 000009
【図８】
2005310171.tif 000010
【図９】
2005310171.tif 000011
【図１０】
2005310171.tif 000012
【図１１】
2005310171.tif 000013
【図１２】
2005310171.tif 000014
【図１３】
2005310171.tif 000015
【図１４】
2005310171.tif 000016
【図１５】
2005310171.tif 000017
【図１６】
2005310171.tif 000018
【図１７】
2005310171.tif 000019
【図１８】
2005310171.tif 000020
【図１９】
2005310171.tif 000021
【図２０】
2005310171.tif 000022
【図２１】
2005310171.tif 000023
【図２２】
2005310171.tif 000024
【図２３】
2005310171.tif 000025
【図２４】
2005310171.tif 000026
【図２５】
2005310171.tif 000027
【図２６】
2005310171.tif 000028
【図２７】
2005310171.tif 000029
【図２８】
2005310171.tif 000030
【図２９】
2005310171.tif 000031
【図３０】
2005310171.tif 000032
【図３１】
2005310171.tif 000033
【図３２】
2005310171.tif 000034