JP3831352B2 - プログラム生成処理をコンピュータに行わせるためのコンピュータ読み取り可能なプログラム - Google Patents
プログラム生成処理をコンピュータに行わせるためのコンピュータ読み取り可能なプログラム Download PDFInfo
- Publication number
- JP3831352B2 JP3831352B2 JP2003081246A JP2003081246A JP3831352B2 JP 3831352 B2 JP3831352 B2 JP 3831352B2 JP 2003081246 A JP2003081246 A JP 2003081246A JP 2003081246 A JP2003081246 A JP 2003081246A JP 3831352 B2 JP3831352 B2 JP 3831352B2
- Authority
- JP
- Japan
- Prior art keywords
- function
- web service
- name
- program
- handler
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Stored Programmes (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、Ｗｅｂサービスの要求及び応答メッセージの記述形式と該Ｗｅｂサービスのプログラムで処理可能なデータ形式を変換するプログラムを自動生成するプログラムを提供するものである。
【０００２】
【従来の技術】
近年、プリンタ、コピー、ファクシミリ、スキャナなどの各装置の機能を１つの筐体内に収納した画像形成装置が一般的に知られている。このような複合型の画像形成装置は、１つの筐体内に表示部、印刷部および撮像部などを設けるとともに、プリンタ、コピー、スキャナおよびファクシミリ装置にそれぞれ対応するアプリケーションを設け、アプリケーションの切り替えによって、当該装置をプリンタ、コピー、スキャナまたはファクシミリ装置として動作させるものである。
【０００３】
【発明が解決しようとする課題】
しかしながら、上記従来の複合型画像形成装置において、ネットワークを介して個々のアプリケーションが画像形成処理をＷｅｂサービスとして提供する場合、そのネットワークプロトコルに従って交換されるメッセージの記述形式を意識したプログラム開発が必要であった。つまり、メッセージには、Ｗｅｂサービス機能に行わせる処理内容が指示されており、プログラムされたＷｅｂサービス機能は、該メッセージを解釈するための機能を組み込んでおく必要があった。メッセージの記述形式がＸＭＬ（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要素において、構造体でデータ型が定義されている場合について説明する。図６は、ソースコード生成処理における構造体の型定義生成処理を説明する図である。
【００４５】
図６において、ＸＭＬスキーマ６１１は、構造体でデータ型が定義されるＸＭＬによる記述例である。ＸＭＬスキーマ６１１は、タグ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」に値「１００」を設定する。
【０１５２】
次に、処理結果を示す構造体３９から要素木を生成する要素木の生成処理について図３０及び図３１で説明する。図３０でのステップ番号は、図１９でのステップ番号に対応する。図３０は、印刷ハンドラによる要素木生成処理を説明するためのフローチャート図である。図３１は、生成された要素木の例を示す図である。
【０１５３】
図３１を参照しつつ、印刷ハンドラによる要素木生成処理を説明する。図３０において、印刷ハンドラ２０１は、Ｅｎｖｅｌｏｐｅ要素３２を生成する（ステップＳ１４０）。Ｂｏｄｙ要素３３を生成する（ステップＳ１４１）。そして、Ｂｏｄｙ要素３３をＥｎｖｅｌｏｐｅ要素３２に接続する（ステップＳ１４２）。これらステップＳ１４０からＳ１４２での処理によって、ＳＯＡＰに従ったＨＴＴＰレスポンスのＨＴＴＰボディが設定される。
【０１５４】
そして、印刷ハンドラ２０１は、ｐｒｉｎｔＲｅｓｐｏｎｓｅ要素３４を生成し（ステップＳ１４３）、ｐｒｉｎｔＲｅｓｐｏｎｓｅ要素３４をＢｏｄｙ要素３３に接続する（ステップＳ１４４）。更に、ｒｅｑｕｅｓｔＩｄ要素３５を生成し（ステップＳ１４５）、ｒｅｑｕｅｓｔＩｄ要素３５をｐｒｉｎｔＲｅｓｐｏｎｓｅ要素３４に接続する（ステップＳ１４６）。
【０１５５】
印刷ハンドラ２０１は、結果として得られたリクエストＩＤより、テキストノード３６を生成して（ステップＳ１４７）、テキストノードをｒｅｑｕｅｓｔＩｄ要素３５に接続する（ステップＳ１４８）。この場合、テキストノード３６には、「１００」が設定される。
【０１５６】
このように生成された要素木は、ＸＭＬ処理部１１５及びＸＭＬシリアライザ１１２によって、図３２に示されるようなＨＴＴＰボディ３２を生成する。図３２は、要素木から変換されたＸＭＬを使用したＳＯＡＰに従ったＨＴＴＰレスポンスの記述例を示す図である。図３２において、図３１に示す各要素３２から３６は、< >で区切られるタグ内に記述され、所定の情報をＳＯＡＰに従った手順でＸＭＬにて記述される。融合機１２００は、ＨＴＴＰデーモン２によってＨＴＴＰリクエストを送信した機器へネットワーク１５を介してこのＨＴＴＰレスポンスを送信する。このようにして、融合機１２００は、ネットワーク１５を介して接続される機器へＷｅｂサービスを提供する。
【０１５７】
上記実施例より、ＸＭＬによる要素間の関連を示す要素木からＷｅｂサービス機能が処理可能なプログラム言語による入力データに変換、及び、プログラム言語による出力データを所定記述形式の要素木に変換するソースコード５３１が自動生成される。従って、単純で同じようなコードを大量に生成することができるため、開発者による単純ミスによるバグが入り込むといった問題を解消することができる。また、短時間でハンドラソースコード５３２を生成することができるため、開発者の負担を軽減することができる。
【０１５８】
また、自動生成されたソースコード５３１による要素木解析・生成ハンドラ２００を融合機１２００に備えることによって、開発者は、従来と同様の開発方法、例えば、Ｃ言語による開発方法によって、Ｗｅｂサービスファンクションとしてのアプリケーションの開発を行うことができる。また、既に実装されているアプリケーションを容易にＷｅｂサービスに対応するに改良することができる。
【０１５９】
また、要素木解析・生成ハンドラ２００を有する融合機１２００では、ＳＯＡＰに従うＸＭＬ記述されたメッセージをプログラム開発されたＷｅｂサービスファンクション３００が解釈することができるため、Ｗｅｂサービスファンクション３００を他システムに提供することが可能となる。よって、融合機１２００に接続されるシステム又はコンピュータ端末を限定しないため、融合機１２００の利用可能性を大幅に拡大することが可能となる。
【０１６０】
【発明の効果】
以上、説明してきたように、本願発明によれば、機器間におけるメッセージ交換プロトコルに従ったメッセージのデータ形式の変換を行うためのプログラムが自動的に生成される。従って、開発者による単純ミスによるバグが入り込むといった問題を解消することができる。また、このように自動生成されたプログラムを画像形成装置に実装することによって、従来と同様の方法によって開発されたＷｅｂサービスファンクションであっても、該メッセージの処理が可能となる。そのため、画像形成装置におけるＷｅｂサービスファンクションの開発を容易に行うことができる。また、画像形成装置に接続可能な他システムとの連携を拡大することができる。
【０１６１】
【図面の簡単な説明】
【図１】本発明の一実施例に係るハンドラ自動生成装置の機能構成を示すブロック図である。
【図２】本発明の一実施例に係るハンドラ自動生成装置のハードウェア構成を示すブロック図である。
【図３】ハンドラ自動生成処理の全体を説明するフローチャート図である。
【図４】タイプライブラリ生成処理を説明するフローチャート図である。
【図５】ソースコード生成処理における列挙型定義生成処理を説明する図である。
【図６】ソースコード生成処理における構造体の型定義生成処理を説明する図である。
【図７】ソースコード生成処理における配列の型定義生成処理を説明する図である。
【図８】ソースコード生成処理における列挙型の関数宣言処理を説明する図である。
【図９】ソースコード生成処理における構造体の関数宣言処理を説明する図である。
【図１０】ソースコード生成処理における配列の関数宣言処理を説明する図である。
【図１１】ハンドラ生成処理を説明するフローチャート図である。
【図１２】ハンドラ生成処理を説明するフローチャート図である。
【図１３】ＷＳＤＬによるインターフェイス定義の記述例を示す図である。
【図１４】ＷＳＤＬによるインターフェイス定義の記述例を示す図である。
【図１５】ハンドラ処理部の関数宣言を説明する図である。
【図１６】Ｗｅｂサービス機能の関数宣言を説明する図である。
【図１７】入力メッセージの構造体定義を説明する図である。
【図１８】出力メッセージの構造体定義を説明する図である。
【図１９】自動生成されたハンドラソースコードの例を示す図である。
【図２０】本発明の一実施例に係る多種の画像形成機能を融合する融合機の機能構成を示すブロック図である。
【図２１】図２０に示す融合機のハードウェア構成を示すブロック図である。
【図２２】Ｗｅｂサービスを実現するための構成例を示す図である。
【図２３】ＳＯＡＰによるＷｅｂサービスの提供処理について説明するフローチャート図である。
【図２４】ＳＯＡＰによるＷｅｂサービスの提供処理について説明するフローチャート図である。
【図２５】ＸＭＬを使用したＳＯＡＰに従ったＨＴＴＰリクエストの記述例を示す図である。
【図２６】ＸＭＬプロセッサによって変換された要素木の例を示す図である。
【図２７】印刷ハンドラによる要素木解析処理を説明するためのフローチャート図である。
【図２８】Ｗｅｂサービス機能の関数の引数の設定例を示す図である。
【図２９】印刷ハンドラでの処理結果の設定例を示す図である。
【図３０】印刷ハンドラによる要素木生成処理を説明するためのフローチャート図である。
【図３１】生成された要素木の例を示す図である。
【図３２】要素木から変換されたＸＭＬを使用したＳＯＡＰに従ったＨＴＴＰレスポンスの記述例を示す図である。
【符号の説明】
２ ｈｔｔｐデーモン、 ７ 要求仲介デーモン、 ８ ＮＡＩ
９ プロトコル制御デーモン、 １５ ネットワーク
１００ シーケンス制御ライブラリ、 １０１ ＨＴＴＰ接続管理部
１０２ ＨＴＴＰサービス実行部、 １０５ ＰＯＳＴメソッド分配処理部
１１０ ＸＭＬライブラリ、 １１５ ＸＭＬ処理部
１１６ ＸＭＬプロセッサ、 １１７ ＸＭＬシリアライザ
１２０ ＳＯＡＰライブラリ、 １２１ ＳＯＡＰアクション振分処理部
２００ 要素木解析・生成ハンドラ
３００ Ｗｅｂサービスファンクション、 ５００ ハンドラ自動生成装置
５１０ ハンドラ自動生成部、 ５１１ ＸＭＬ解析部
５１２ タイプライブラリ生成部、 ５１３ ハンドラソースコード生成部
５１４ ＸＭＬスキーマ解析部、 ５１５ タイプ要素解析部、
５１６ メッセージ要素解析部、 ５１７ 操作要素解析部
５２０ ファイル入力部、 ５２１ インターフェイス定義５１２
５２２ インターフェイス定義ファイル（ＷＳＤＬ）
５２３ 型定義ファイル（ＸＭＬスキーマ）、 ５３０ ファイル出力
５３１ ソースコード、 ５３２ ハンドラソースコード
５３３ タイプライブラリ、 １２００ 融合機、 １２０１ プロッタ
１２０２ スキャナ、 １２０３ その他ハードウェアリソース、
１２１０ ソフトウェア群、 １２３０ アプリケーション
１２２０ プラットフォーム、 １２２１ ＯＳ、 １２２２ ＳＣＳ
１２２３ ＳＲＭ、 １２２４ ＥＣＳ、 １２２５ ＭＣＳ
１２２６ ＯＣＳ、 １２２７ ＦＣＳ、 １２２８ ＮＣＳ
１２２９ ＩＭＨ、 １２４０ 融合機起動部、 １３００ コントローラ
１３０１ ＡＳＩＣ、 １３０２ ＭＥＭ−Ｃ、 １３０３ ＨＤＤ
１３０４ ＣＰＵ、 １３０５ ＮＢ、 １３０６ ＭＥＭ−Ｐ
１３０７ ＳＢ、 １３０８ ＡＧＰ、 １３１０ オペレーションパネル
１３２０ ファックスコントロールユニット
１３１１ ＮＩＣ、 １３１２ ＵＳＢ、 １３１３ ＩＥＥＥ１３９４
１３１４ セントロニクス、 １３５０ エンジン部
【発明の属する技術分野】
本発明は、Ｗｅｂサービスの要求及び応答メッセージの記述形式と該Ｗｅｂサービスのプログラムで処理可能なデータ形式を変換するプログラムを自動生成するプログラムを提供するものである。
【０００２】
【従来の技術】
近年、プリンタ、コピー、ファクシミリ、スキャナなどの各装置の機能を１つの筐体内に収納した画像形成装置が一般的に知られている。このような複合型の画像形成装置は、１つの筐体内に表示部、印刷部および撮像部などを設けるとともに、プリンタ、コピー、スキャナおよびファクシミリ装置にそれぞれ対応するアプリケーションを設け、アプリケーションの切り替えによって、当該装置をプリンタ、コピー、スキャナまたはファクシミリ装置として動作させるものである。
【０００３】
【発明が解決しようとする課題】
しかしながら、上記従来の複合型画像形成装置において、ネットワークを介して個々のアプリケーションが画像形成処理をＷｅｂサービスとして提供する場合、そのネットワークプロトコルに従って交換されるメッセージの記述形式を意識したプログラム開発が必要であった。つまり、メッセージには、Ｗｅｂサービス機能に行わせる処理内容が指示されており、プログラムされたＷｅｂサービス機能は、該メッセージを解釈するための機能を組み込んでおく必要があった。メッセージの記述形式がＸＭＬ（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要素において、構造体でデータ型が定義されている場合について説明する。図６は、ソースコード生成処理における構造体の型定義生成処理を説明する図である。
【００４５】
図６において、ＸＭＬスキーマ６１１は、構造体でデータ型が定義されるＸＭＬによる記述例である。ＸＭＬスキーマ６１１は、タグ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」に値「１００」を設定する。
【０１５２】
次に、処理結果を示す構造体３９から要素木を生成する要素木の生成処理について図３０及び図３１で説明する。図３０でのステップ番号は、図１９でのステップ番号に対応する。図３０は、印刷ハンドラによる要素木生成処理を説明するためのフローチャート図である。図３１は、生成された要素木の例を示す図である。
【０１５３】
図３１を参照しつつ、印刷ハンドラによる要素木生成処理を説明する。図３０において、印刷ハンドラ２０１は、Ｅｎｖｅｌｏｐｅ要素３２を生成する（ステップＳ１４０）。Ｂｏｄｙ要素３３を生成する（ステップＳ１４１）。そして、Ｂｏｄｙ要素３３をＥｎｖｅｌｏｐｅ要素３２に接続する（ステップＳ１４２）。これらステップＳ１４０からＳ１４２での処理によって、ＳＯＡＰに従ったＨＴＴＰレスポンスのＨＴＴＰボディが設定される。
【０１５４】
そして、印刷ハンドラ２０１は、ｐｒｉｎｔＲｅｓｐｏｎｓｅ要素３４を生成し（ステップＳ１４３）、ｐｒｉｎｔＲｅｓｐｏｎｓｅ要素３４をＢｏｄｙ要素３３に接続する（ステップＳ１４４）。更に、ｒｅｑｕｅｓｔＩｄ要素３５を生成し（ステップＳ１４５）、ｒｅｑｕｅｓｔＩｄ要素３５をｐｒｉｎｔＲｅｓｐｏｎｓｅ要素３４に接続する（ステップＳ１４６）。
【０１５５】
印刷ハンドラ２０１は、結果として得られたリクエストＩＤより、テキストノード３６を生成して（ステップＳ１４７）、テキストノードをｒｅｑｕｅｓｔＩｄ要素３５に接続する（ステップＳ１４８）。この場合、テキストノード３６には、「１００」が設定される。
【０１５６】
このように生成された要素木は、ＸＭＬ処理部１１５及びＸＭＬシリアライザ１１２によって、図３２に示されるようなＨＴＴＰボディ３２を生成する。図３２は、要素木から変換されたＸＭＬを使用したＳＯＡＰに従ったＨＴＴＰレスポンスの記述例を示す図である。図３２において、図３１に示す各要素３２から３６は、< >で区切られるタグ内に記述され、所定の情報をＳＯＡＰに従った手順でＸＭＬにて記述される。融合機１２００は、ＨＴＴＰデーモン２によってＨＴＴＰリクエストを送信した機器へネットワーク１５を介してこのＨＴＴＰレスポンスを送信する。このようにして、融合機１２００は、ネットワーク１５を介して接続される機器へＷｅｂサービスを提供する。
【０１５７】
上記実施例より、ＸＭＬによる要素間の関連を示す要素木からＷｅｂサービス機能が処理可能なプログラム言語による入力データに変換、及び、プログラム言語による出力データを所定記述形式の要素木に変換するソースコード５３１が自動生成される。従って、単純で同じようなコードを大量に生成することができるため、開発者による単純ミスによるバグが入り込むといった問題を解消することができる。また、短時間でハンドラソースコード５３２を生成することができるため、開発者の負担を軽減することができる。
【０１５８】
また、自動生成されたソースコード５３１による要素木解析・生成ハンドラ２００を融合機１２００に備えることによって、開発者は、従来と同様の開発方法、例えば、Ｃ言語による開発方法によって、Ｗｅｂサービスファンクションとしてのアプリケーションの開発を行うことができる。また、既に実装されているアプリケーションを容易にＷｅｂサービスに対応するに改良することができる。
【０１５９】
また、要素木解析・生成ハンドラ２００を有する融合機１２００では、ＳＯＡＰに従うＸＭＬ記述されたメッセージをプログラム開発されたＷｅｂサービスファンクション３００が解釈することができるため、Ｗｅｂサービスファンクション３００を他システムに提供することが可能となる。よって、融合機１２００に接続されるシステム又はコンピュータ端末を限定しないため、融合機１２００の利用可能性を大幅に拡大することが可能となる。
【０１６０】
【発明の効果】
以上、説明してきたように、本願発明によれば、機器間におけるメッセージ交換プロトコルに従ったメッセージのデータ形式の変換を行うためのプログラムが自動的に生成される。従って、開発者による単純ミスによるバグが入り込むといった問題を解消することができる。また、このように自動生成されたプログラムを画像形成装置に実装することによって、従来と同様の方法によって開発されたＷｅｂサービスファンクションであっても、該メッセージの処理が可能となる。そのため、画像形成装置におけるＷｅｂサービスファンクションの開発を容易に行うことができる。また、画像形成装置に接続可能な他システムとの連携を拡大することができる。
【０１６１】
【図面の簡単な説明】
【図１】本発明の一実施例に係るハンドラ自動生成装置の機能構成を示すブロック図である。
【図２】本発明の一実施例に係るハンドラ自動生成装置のハードウェア構成を示すブロック図である。
【図３】ハンドラ自動生成処理の全体を説明するフローチャート図である。
【図４】タイプライブラリ生成処理を説明するフローチャート図である。
【図５】ソースコード生成処理における列挙型定義生成処理を説明する図である。
【図６】ソースコード生成処理における構造体の型定義生成処理を説明する図である。
【図７】ソースコード生成処理における配列の型定義生成処理を説明する図である。
【図８】ソースコード生成処理における列挙型の関数宣言処理を説明する図である。
【図９】ソースコード生成処理における構造体の関数宣言処理を説明する図である。
【図１０】ソースコード生成処理における配列の関数宣言処理を説明する図である。
【図１１】ハンドラ生成処理を説明するフローチャート図である。
【図１２】ハンドラ生成処理を説明するフローチャート図である。
【図１３】ＷＳＤＬによるインターフェイス定義の記述例を示す図である。
【図１４】ＷＳＤＬによるインターフェイス定義の記述例を示す図である。
【図１５】ハンドラ処理部の関数宣言を説明する図である。
【図１６】Ｗｅｂサービス機能の関数宣言を説明する図である。
【図１７】入力メッセージの構造体定義を説明する図である。
【図１８】出力メッセージの構造体定義を説明する図である。
【図１９】自動生成されたハンドラソースコードの例を示す図である。
【図２０】本発明の一実施例に係る多種の画像形成機能を融合する融合機の機能構成を示すブロック図である。
【図２１】図２０に示す融合機のハードウェア構成を示すブロック図である。
【図２２】Ｗｅｂサービスを実現するための構成例を示す図である。
【図２３】ＳＯＡＰによるＷｅｂサービスの提供処理について説明するフローチャート図である。
【図２４】ＳＯＡＰによるＷｅｂサービスの提供処理について説明するフローチャート図である。
【図２５】ＸＭＬを使用したＳＯＡＰに従ったＨＴＴＰリクエストの記述例を示す図である。
【図２６】ＸＭＬプロセッサによって変換された要素木の例を示す図である。
【図２７】印刷ハンドラによる要素木解析処理を説明するためのフローチャート図である。
【図２８】Ｗｅｂサービス機能の関数の引数の設定例を示す図である。
【図２９】印刷ハンドラでの処理結果の設定例を示す図である。
【図３０】印刷ハンドラによる要素木生成処理を説明するためのフローチャート図である。
【図３１】生成された要素木の例を示す図である。
【図３２】要素木から変換されたＸＭＬを使用したＳＯＡＰに従ったＨＴＴＰレスポンスの記述例を示す図である。
【符号の説明】
２ ｈｔｔｐデーモン、 ７ 要求仲介デーモン、 ８ ＮＡＩ
９ プロトコル制御デーモン、 １５ ネットワーク
１００ シーケンス制御ライブラリ、 １０１ ＨＴＴＰ接続管理部
１０２ ＨＴＴＰサービス実行部、 １０５ ＰＯＳＴメソッド分配処理部
１１０ ＸＭＬライブラリ、 １１５ ＸＭＬ処理部
１１６ ＸＭＬプロセッサ、 １１７ ＸＭＬシリアライザ
１２０ ＳＯＡＰライブラリ、 １２１ ＳＯＡＰアクション振分処理部
２００ 要素木解析・生成ハンドラ
３００ Ｗｅｂサービスファンクション、 ５００ ハンドラ自動生成装置
５１０ ハンドラ自動生成部、 ５１１ ＸＭＬ解析部
５１２ タイプライブラリ生成部、 ５１３ ハンドラソースコード生成部
５１４ ＸＭＬスキーマ解析部、 ５１５ タイプ要素解析部、
５１６ メッセージ要素解析部、 ５１７ 操作要素解析部
５２０ ファイル入力部、 ５２１ インターフェイス定義５１２
５２２ インターフェイス定義ファイル（ＷＳＤＬ）
５２３ 型定義ファイル（ＸＭＬスキーマ）、 ５３０ ファイル出力
５３１ ソースコード、 ５３２ ハンドラソースコード
５３３ タイプライブラリ、 １２００ 融合機、 １２０１ プロッタ
１２０２ スキャナ、 １２０３ その他ハードウェアリソース、
１２１０ ソフトウェア群、 １２３０ アプリケーション
１２２０ プラットフォーム、 １２２１ ＯＳ、 １２２２ ＳＣＳ
１２２３ ＳＲＭ、 １２２４ ＥＣＳ、 １２２５ ＭＣＳ
１２２６ ＯＣＳ、 １２２７ ＦＣＳ、 １２２８ ＮＣＳ
１２２９ ＩＭＨ、 １２４０ 融合機起動部、 １３００ コントローラ
１３０１ ＡＳＩＣ、 １３０２ ＭＥＭ−Ｃ、 １３０３ ＨＤＤ
１３０４ ＣＰＵ、 １３０５ ＮＢ、 １３０６ ＭＥＭ−Ｐ
１３０７ ＳＢ、 １３０８ ＡＧＰ、 １３１０ オペレーションパネル
１３２０ ファックスコントロールユニット
１３１１ ＮＩＣ、 １３１２ ＵＳＢ、 １３１３ ＩＥＥＥ１３９４
１３１４ セントロニクス、 １３５０ エンジン部
Claims (8)
- コンピュータに、
Ｗｅｂサービスのインターフェイスを定義するインターフェイス定義を構成する複数の要素間の関連を示す第一要素木に基づいて、上記Ｗｅｂサービスを実行するＷｅｂサービス機能を関数コールするためのＣ言語プログラムによる入出力データ形式とＸＭＬによって記述される該Ｗｅｂサービスに関する要求及び応答メッセージとの変換処理を行う変換プログラムを生成する変換プログラム生成手順を実行させるコンピュータ読み取り可能なプログラムであって、
上記変換プログラム生成手順は、
上記Ｗｅｂサービス機能のＣ言語プログラムによる入出力データ形式と上記要求及び応答メッセージに含まれる値のデータ型との変換を行う第一コードを生成する第一コード生成手順と、
上記要求メッセージを構成する複数の要素間の関連を示す第二要素木の末端に設定される値を、上記Ｗｅｂサービス機能のＣ言語プログラムによる入力データ形式に変換する第二コードを生成する第二コード生成手順と、
上記Ｗｅｂサービス機能のＣ言語プログラムによる出力データ形式を上記応答メッセージを構成する複数の要素間の関連を示す第三要素木の末端の値に変換する第三コードを生成する第三コード生成手順とを有することを特徴とするコンピュータ読み取り可能なプログラム。 - 上記第一要素木に基づいて、上記インターフェイス定義にて指定されるサービス名と操作名とによって上記変換プログラム生成手順によって生成された上記変換プログラムを実行する第一関数の関数名を生成し、その関数名によって該第一関数を宣言する第一関数宣言手順と、
上記第一要素木に基づいて、上記インターフェイス定義にて指定されるサービス名と操作名とによって上記Ｗｅｂサービス機能を実行する第二関数の関数名を生成し、該インターフェイス定義にて指定される該サービス名と入力メッセージ名及び出力メッセージとによって引数の型と引数名とを決定し、その関数名と引数名とによって該第二関数を宣言する第二関数宣言手順とを有することを特徴とする請求項１記載のプログラム。 - 上記第一要素木に基づいて、上記インターフェイス定義にて指定される上記サービス名と上記入力メッセージ名とによって入力データの構造体名を生成し、該インターフェイス定義にて指定されるパラメータ型と、パラメータ名とによって上記Ｗｅｂサービス機能によって処理可能な入力データ構造体を構成して定義する第一構造体定義手順と、
上記第一要素木に基づいて、上記インターフェイス定義にて指定される上記サービス名と上記出力メッセージ名とによって出力データの構造体名を生成し、該インターフェイス定義にて指定されるパラメータ型と、パラメータ名とによって上記Ｗｅｂサービス機能によって処理可能な出力データ構造体を構成して定義する第二構造体定義手順とを有することを特徴とする請求項２記載のプログラム。 - 上記第一要素木におけるデータ型の定義に基づいて、上記Ｗｅｂサービス機能によって処理可能な型定義を生成する型定義生成手順と、
上記第二要素木における入力データが格納される要素を上記Ｗｅｂサービス機能によって処理可能な定義された型に変換するデータ型変換関数の宣言を生成するデータ型関数宣言生成手順とを有することを特徴とする請求項１記載のプログラム。 - 上記型定義に基づいて、上記Ｗｅｂサービス機能による上記出力データのデータ型を上記第三要素木における出力データが格納される要素に変換するデータ型変換関数の宣言を生成するデータ型関数宣言生成手順とを有することを特徴とする請求項４記載のプログラム。
- 上記第一要素木は、Extensible Markup Languageによって記述された上記インターフェイス定義を解析して生成されていることを特徴とする請求項１乃至５のいずれか一項記載のプログラム。
- コンピュータが、
Ｗｅｂサービスのインターフェイスを定義するインターフェイス定義を構成する複数の要素間の関連を示す第一要素木に基づいて、上記Ｗｅｂサービスを実行するＷｅｂサービス機能を関数コールするためのＣ言語プログラムによる入出力データ形式とＸＭＬによって記述される該Ｗｅｂサービスに関する要求及び応答メッセージとの変換処理を行う変換プログラムを生成する変換プログラム生成手順を実行するプログラム生成方法であって、
上記変換プログラム生成手順は、
上記Ｗｅｂサービス機能のＣ言語プログラムによる入出力データ形式と上記要求及び応答メッセージに含まれる値のデータ型との変換を行う第一コードを生成する第一コード生成手順と、
上記要求メッセージを構成する複数の要素間の関連を示す第二要素木の末端に設定される値を、上記Ｗｅｂサービス機能のＣ言語プログラムによる入力データ形式に変換する第二コードを生成する第二コード生成手順と、
上記Ｗｅｂサービス機能のＣ言語プログラムによる出力データ形式を上記応答メッセージを構成する複数の要素間の関連を示す第三要素木の末端の値に変換する第三コードを生成する第三コード生成手順とを有することを特徴とするプログラム生成方法。 - コンピュータに、
Ｗｅｂサービスのインターフェイスを定義するインターフェイス定義を構成する複数の要素間の関連を示す第一要素木に基づいて、上記Ｗｅｂサービスを実行するＷｅｂサービス機能を関数コールするためのＣ言語プログラムによる入出力データ形式とＸＭＬによって記述される該Ｗｅｂサービスに関する要求及び応答メッセージとの変換処理を行う変換プログラムを生成する変換プログラム生成手順を実行させるコンピュータ読み取り可能なプログラムが記憶された記憶媒体であって、
上記変換プログラム生成手順は、
上記Ｗｅｂサービス機能のＣ言語プログラムによる入出力データ形式と上記要求及び応答メッセージに含まれる値のデータ型との変換を行う第一コードを生成する第一コード生成手順と、
上記要求メッセージを構成する複数の要素間の関連を示す第二要素木の末端に設定される値を、上記Ｗｅｂサービス機能のＣ言語プログラムによる入力データ形式に変換する第二コードを生成する第二コード生成手順と、
上記Ｗｅｂサービス機能のＣ言語プログラムによる出力データ形式を上記応答メッセージを構成する複数の要素間の関連を示す第三要素木の末端の値に変換する第三コードを生成する第三コード生成手順とを有することを特徴とするコンピュータ読み取り可能なプログラムが記憶された記憶媒体。
Priority Applications (7)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003081246A JP3831352B2 (ja) | 2002-03-25 | 2003-03-24 | プログラム生成処理をコンピュータに行わせるためのコンピュータ読み取り可能なプログラム |
| PCT/JP2003/003651 WO2003081443A1 (fr) | 2002-03-25 | 2003-03-25 | Dispositif de formation d'images comportant une fonction de service web |
| EP03715406.9A EP1489520B1 (en) | 2002-03-25 | 2003-03-25 | Image formation device having a web service function |
| US10/490,978 US7743162B2 (en) | 2002-03-25 | 2003-03-25 | Image forming apparatus, with connection request mediation, having web service functions |
| CN200610172730.5A CN1980247B (zh) | 2002-03-25 | 2003-03-25 | 具有万维网服务功能的图像形成装置及方法 |
| CNB038015641A CN100351818C (zh) | 2002-03-25 | 2003-03-25 | 具有万维网服务功能的图像形成装置 |
| US12/771,330 US8549162B2 (en) | 2002-03-25 | 2010-04-30 | Image forming apparatus having web service functions |
Applications Claiming Priority (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002084552 | 2002-03-25 | ||
| JP2002084554 | 2002-03-25 | ||
| JP2002084553 | 2002-03-25 | ||
| JP2003081246A JP3831352B2 (ja) | 2002-03-25 | 2003-03-24 | プログラム生成処理をコンピュータに行わせるためのコンピュータ読み取り可能なプログラム |
Related Child Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2005128242A Division JP2005310171A (ja) | 2002-03-25 | 2005-04-26 | プログラム生成処理をコンピュータに行わせるためのコンピュータ読み取り可能なプログラム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2004005505A JP2004005505A (ja) | 2004-01-08 |
| JP3831352B2 true JP3831352B2 (ja) | 2006-10-11 |
Family
ID=30449505
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003081246A Expired - Fee Related JP3831352B2 (ja) | 2002-03-25 | 2003-03-24 | プログラム生成処理をコンピュータに行わせるためのコンピュータ読み取り可能なプログラム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3831352B2 (ja) |
Families Citing this family (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4522771B2 (ja) | 2003-09-22 | 2010-08-11 | 株式会社リコー | 通信装置、通信システム、通信装置の制御方法及びプログラム |
| JP2005339520A (ja) * | 2004-04-26 | 2005-12-08 | Ricoh Co Ltd | サービス提供装置、サービス提供プログラム、記録媒体及びサービス提供方法 |
| JP4208786B2 (ja) | 2004-07-28 | 2009-01-14 | キヤノン株式会社 | 画像処理装置、ネットワークシステム、情報処理方法、ならびにプログラム、記憶媒体 |
| US7890659B2 (en) * | 2005-12-15 | 2011-02-15 | Microsoft Corporation | Conforming web services to an updated contract |
| JP4760425B2 (ja) * | 2006-02-13 | 2011-08-31 | セイコーエプソン株式会社 | プリンタを用いた印刷におけるスタイルシートの切替 |
| JP5222642B2 (ja) * | 2008-07-11 | 2013-06-26 | 京セラドキュメントソリューションズ株式会社 | 画像形成装置 |
| JP5551141B2 (ja) * | 2011-11-05 | 2014-07-16 | 京セラドキュメントソリューションズ株式会社 | クライアントサイドＷｅｂサービスインターフェイス及びこれを備えたソフトウェア開発キット並びにこの開発キットを用いたソフトウェア開発方法 |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2002032263A (ja) * | 2000-07-13 | 2002-01-31 | Atl Systems:Kk | 異なる構造のｘｍｌファイルを使用したシステムどうしの接続方法 |
-
2003
- 2003-03-24 JP JP2003081246A patent/JP3831352B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2004005505A (ja) | 2004-01-08 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8549162B2 (en) | Image forming apparatus having web service functions | |
| JP4444752B2 (ja) | サービス提供装置、サービス提供プログラム、記録媒体及びサービス提供方法 | |
| US7809750B2 (en) | Data management apparatus that controls a data storage apparatus by transmitting command of structured document format | |
| US8230200B2 (en) | Image forming apparatus capable of creating, managing and using job history and control method for the same | |
| US20050053402A1 (en) | Printing processing device and method thereof | |
| WO2011080994A1 (en) | Server apparatus, terminal apparatus, and printing system and data conversion method thereof | |
| US7860954B2 (en) | Device management system and control method therefor | |
| US20090063612A1 (en) | Image forming apparatus and image forming system | |
| JP2005310171A (ja) | プログラム生成処理をコンピュータに行わせるためのコンピュータ読み取り可能なプログラム | |
| JP3831352B2 (ja) | プログラム生成処理をコンピュータに行わせるためのコンピュータ読み取り可能なプログラム | |
| JP4291856B2 (ja) | Ｗｅｂサービス機能を有する画像形成装置 | |
| JP4141209B2 (ja) | Ｗｅｂサービス機能を有する画像形成装置 | |
| JP2005050018A (ja) | 文書ファイル管理装置及びデータ構造 | |
| US20050108649A1 (en) | Control apparatus, control instruction apparatus, control program product and control instruction program product for transmitting/receiving data described in extensible markup language | |
| JP4373692B2 (ja) | Ｗｅｂサービス機能を有する画像形成装置 | |
| JP4130108B2 (ja) | Ｗｅｂサービス機能を有する画像形成装置 | |
| JP4203287B2 (ja) | 情報処理装置、情報処理方法及び情報処理システム | |
| JP4291855B2 (ja) | Ｗｅｂサービス機能を有する画像形成装置 | |
| JP2005050017A (ja) | 文書ファイル管理装置、文書ファイル管理方法及びデータ構造 | |
| JP4136738B2 (ja) | Ｗｅｂサービス機能を有する画像形成装置 | |
| JP2006020341A (ja) | Ｗｅｂサービス機能を有する画像形成装置 | |
| JP2004272888A (ja) | サービス提供装置、ユーザ端末装置、サービス提供方法、サービス利用方法、サービス提供プログラム、サービス利用プログラム及び記録媒体 | |
| JP2004274736A (ja) | サービス情報提供装置、ユーザ端末装置、サービス情報提供方法、サービス利用方法、サービス情報提供プログラム、サービス利用プログラム及び記録媒体 | |
| JP2004086354A (ja) | 画像処理装置 | |
| JP2007128544A (ja) | 電子データ送信装置、電子メール送信方法、及び記録媒体 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20050301 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050426 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20051206 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060203 |
|
| A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20060215 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20060711 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20060713 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090721 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100721 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110721 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120721 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120721 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130721 Year of fee payment: 7 |
|
| LAPS | Cancellation because of no payment of annual fees |