WO2003081443A1

WO2003081443A1 - Dispositif de formation d'images comportant une fonction de service web

Info

Publication number: WO2003081443A1
Application number: PCT/JP2003/003651
Authority: WO
Inventors: Hiroyuki Matsushima
Original assignee: Ricoh Company, Ltd.
Priority date: 2002-03-25
Filing date: 2003-03-25
Publication date: 2003-10-02
Also published as: CN1980247B; EP1489520B1; US20100220348A1; CN100351818C; US20040267808A1; US7743162B2; CN1980247A; EP1489520A1; US8549162B2; EP1489520A4; CN1592893A

Description

W e bサービス機能を有する画像形成装置技術分野

本発明は、複数の通信プロトコルを有する画像形成処理装置に係り、詳しくは、アプリケーションが多種多様な通信プロトコルに応じた処理部を有することなくデータの送受信を行うことができ、通信プロトコル及ぴアプリケーションの ϋ¾口を容易とする画像形成処理装置を提供するものである。また、本発明は、 W e b " サービスをするアプリケーションの開発及び il¾口を容易とする画像形成装置を提供するものである。更に、本発明は、 We bサービスの要求及び応答メッセージの記述形式と ¾W e bサービスのプログラムで処理可能なデータ形式を変換するプログラムを自動生成するプログラムを提供するものである。背景技術

近年、プリンタ、コピー、ファクシミリ、スキャナなどの各装置の機能を 1つの筐体内に収納した画像形成装置が一般的に知られている。このような複合型の画像形成装置は、 1つの筐体内に表示部、印刷部および撮像部などを設けるとともに、プリンタ、コピー、スキャナおよびファクシミリ装置にそれぞれ対応するアプリケーションを設け、アプリケーションの切り替えによって、当該装置をプリンタ、コピー、スキャナまたはファタシミリ装置として動作させるものである。しかしながら、近年のインターネットの普及及び通信プロトコルの多様化にともなつて、プリンタ機能を有する上記従来の複合型画像形成装置は、市場要求として多種多様なィンターフェイスからの印刷要求に応じなければならなくなってきた。上記従来の複合型画像形成装置において、このような市場要求に応じるため、新しいインターフェイスが ϋ ^される毎に個別に対応をしてきた。個別に対

従来から実装されているアプリケーションに新規のィンターフェイスに対応するために手を加えなければならない。また、新規にアプリケーションを開発して実装するためには、複数のインターフェイスに対応するように開発を行わなければならない等の問題があつた。

また、近年、インターネットの発達と普及により、ネットワークを介して通信可能なプリンタ機能を有する上記従来の複合型画像形成装置は、ネットワークを介して機器と接続可能であるために、更にインターネットを介して行われる通信プロ卜コル、つまり、 HT T P (Hypertext Trans fer Protocol) による通信制御によつて行われる W e bサービスの提供が望まれるようになった。更に、 HT T Pによる通信制御に加え、 HT T Pのボディ部に XML (extensible M arkup Language)等の汎用的な記述形式によるメッセージを記述して、接続さ ' れる機器の対象範囲を拡大する傾向にあるなかで、上記従来の複合型画像形成装置では、画像形成に関する処理を実行する各アプリケーションが HT T Pによる通信制御と XML等によってメッセージ交換を行うためには、各アプリケーションに HT T Pによって指定されるメソッドの違いによる処理、及び、 XMLの記. 述に関する処理を行わせる必要があった。従って、 W e bサービスに対応するァプリケーシヨンを開発する開発者には、機能毎のプログラムの開発が必要とされていた。

上記従来の複合型画像形成装置において、ネットワークを介して個々のアプリケーションが画像形成処理を W e bサービスとしてする場合、そのネットヮークプロトコルに従って交換されるメッセージの記述形式を解釈できるように実装されたアプリケーションに改良する必要があった。. また、メッセージの記述形式が XML (extensible Markup Language)である場合、従来の開発方法で開発されたアプリケーションを W e bサービス対応に改良するのも、また、上記従来の複合型画像形成装置に新規に W e bサービス対応のアプリケーションを追加するのも、開発者に XMLの知識が要求されるため、従来の開発方法によってアプリケーシヨンを開発することが困難であった。

上述したように、 XMLによるメッセージのデータ形式と We bサービス機能におけるプログラム言語にて処理可能なデータ形式とは異なつているため、各 W e bサービス機能の中にこれらデータ形式の違いを吸収するための仕組みを持つ必要があった。このようなデータ形式の違いを吸収するための仕組みの開発では、単純で同じょうなコードを大量に繰り返す必要があり、単純ミスによるバグカ入りやすレ、という問題があつた。発明の開示

そこで、本発明の課題は、多種多様なインターフェイスを介して接続される機器との間の印刷データ及ぴ画像データの送受信制御を行うことによって、多種多様な通信プロトコルと夫々異なる画像形成処理を行う複数のアプリケーションとを仲介する仲介処理部を有し、通信プロトコル及ぴアプリケーションの追加を容易とする画像形成処理装置を提供することである。

また、本発明の課題は、夫々異なる画像形成処理を行う複数のアプリケーションを有し、 W e bサービスを提供するために必要な処理部を部品化し該複数のァプリケーションにて共有できる構成とすることによって We bサービスを提供するアプリケーションの開発及び ϋ¾Πを容易とする画像形成処3¾置を ^することである。

更に、本発明の課題は、複数の We bサービスを提供する該画像形成装置と接続される機器とで交換されるメッセージの記述形式に依存することなく、 W e b サービスとして機能可能なアプリケーションの開発を行うことができる画像形成装置をすることである。

また、本発明の課題は、複数の We bサービスを ^する該画像形成装置と接続される機器とで交換されるメッセージの記述形式に依存することなく該複数の W e bサービスのプログラム開発を容易とする、該記述形式と l¾We bサービスの開発プログラムで処理可能なデータ形式を変換するプログラムを自動生成するプログラムを提供することである。

これら目的は、以下に説明する手段により解決される。

本発明によれば、画像形成に関する処理を実行するアプリケーションと、夫々異なる通信プロトコルに従ってデータ送受信を行う複数の通信プロトコルデーモンと、上記各通信プロトコルデーモンからの接続通知に応じて、該通信プロトコルデーモンに代わって、該通信プロトコルデーモンにて接続要求があったことを上記アプリケーションへ通知することによって接続を仲介する接続要求仲介手段とを有するように構成される。また、上記複数の通信プロトコルデーモンによつて共有され、受信データ及び送信データを格納し、上記アプリケーションと該複数の通信プロトコルデーモンとの間で該受信データ及び該送信データの受け渡しに使用される共有メモリとを有するように構成することができる。

このような画像形成装置では、多種多様な通信プロトコルと画像形成に関する処理を実行するアプリケーションとの接続を仲介する接続要求仲介手段（要求仲介デーモン 7) 及び共有メモリ（9 9 ) を用いてデータ送受信を制御するプロトコル制御デーモン 9が構成される。そのため、複数の通信プロトコルのインターフェイスと各アプリケーションとが互いを意識する必要がない。従って、このような画像形成装置への通信プロトコル及びアプリケーションの追加を容易に行うことができる。

本発明によれば、メソッドに従った所定の処理を行う複数のメソッド処理手段と、処理要求に応じて、該処理要求で指定される上記メソッドに対応する上記メソッド処理手段に該処理要求を振り分けることによって W e bサービスを実行する We bサービス実行手段を有するように構成される。また、同一メソッドにおける処理を共有し、上記 W e bサービスとして画像形成に関する処理を行う複数の W e bサービスアプリケーションを有するように構成することができる。このような画像形成装置では、メソッド毎に処理を部品化されるため、メソッド特有の処理を、複数の We bサービスアプリケーションによって共有することができる。

本発明によれば、ネットワークを介して接続される機器からの要求メッセージに基づいて処理を実行し、その処¾結果を W e bサービスとして提供する W e b サービス処理手段と、所定メッセージ交換プロトコルに従って受信した上記要求メッセージを上記 We bサービス処理手段によって処理可能な処理要求に変換すると共に、 ^W e bサービス処理手段から出力される上記処理結果を該メッセージ交換プロトコルに従った応答メッセージに変換する変換手段とを有するように構成される。

このような画像形成装置では、メッセージ交換プロトコルで規定される要求メッセージを We bサービス処理手段が処理可能な処理要求に変換し、また、 We bサービス処理手段の処結果をメッセージ交換プロトコルで規定される応答メッセージに変換するため、このようなメッセージ交換プロトコルの知識を必要とせずに、 W e bサービス処理手段を開発することができる。

本発明によれば、コンピュータに、 W e bサービスのインターフェイスを定義するインターフェイス定義を解析し、該インターフェイス定義を構成する複数の要素間の関連を示す第一要素木を生成する要素木生成手順と、上記第一要素木に基づいて、上記 W e bサービスを実行する W e 'bサービス機能によって処理可能 -な入出力データ形式と所 ¾|己述形式によつて記述される^ W e bサービスに関する要求及び応答メッセージとの変換処理を行う変換プログラムを生成する変換プログラム生成手順と実行させるように構成される。

このようなプログラムをインストールしたコンピュータ装置では、 W e bサービスのインターフェイスを定義するインターフェイス定義（例えば、 WS D L (

Web Service Description Language) )力ら、 W e bサービス機能の入出力デ" タ形式と所定記述形式（例えば、 XML (extensible Markup Language) ) による要求及び応答メッセージとの変換を行うプログラム（例えば、実施例におけるハンドラ処理部）を生成することができる。従って、単純で同じようなコードを大量に生成することができるため、開発者による単純ミスによるバグが入り込むといった問題を解消することができる。また、短時間でプログラムを生成することができるため、開発者の負担を軽減することができる。

図面の簡単な説明

図 1は、本発明の一実施例に係る.多種の画像形成機能を融合する融合機の機能構成を示すブロック図である。

図 2は、図 1に示す融合機のハードウエア構成を示すプロック図である。

図 3は、通信制御を行うプロセスとアプリケーシヨンとの仲介を行うプロセスによる処理の全 «要を示す図である。

図 4は、アプリケーションの登録を行う登録シーケンスを示す図である。

図 5は、アプリケーション用パッファの登録を行うバッファ登録シーケンスを' 示す図である。 '

図 6は、アプリケーションへリクエストを通知するリクエスト通知シーケンスを示す図である。図 7は、データ送受信シーケンスを示す図である。

図 8は、アプリケーションのコネクションを終了するコネクション終了シーケンスを示す図である。

図 9は、アプリの開発及ぴ追加を容易とする融合機の基本構成例を示す図である。

図 1 0は、アプリの開発及び追加を容易とする融合機の第一構成例を示す図である。

図 1 1は、図 1 0の第一構成例における処理フローを示す図である。

図 1 2は、図 1 0の第一構成例における処理フローを示す図である。

図 1 3は、シーケンス制御ライブラリのスレツド構成の例を示す図である。図 1 4は、シーケンス制御ライブラリのスレツド構成の例を示す図である。図 1 5は、アプリの開発及ぴ口を容易とする融合機の第二構成例を示す図でめる。

図 1 6は、アプリの開発及び ϋ¾πを容易とする融合機の第三構成例を示す図である。

図 1 7は、本発明の一実施例に係るハンドラ自動生成装置の機能構成を示すブ口ック図である。

図 1 8は、本発明の一実施例に係るハンドラ自動生成装置のハードウエア構成を示すプロック図である。

図 1 9は、ハンドラ自動生成処理の全体を説明するフローチャート図である。図 2 0は、タイプライブラリ生成処理を説明するフローチャート図である。図 2 1は、ソースコード生成処理における列挙型定義生成処理を説明する図である。

図 2 2は、ソースコード生成処理における構造体の型定義生成処理を説明する図である。

図 2 3は、ソースコード生成処理における配列の型定義生成処理を説明する図である。

図 2 4は、ソースコード生成処理における列挙型の関数宣言処理を説明する図である。図 2 5は、ソースコード生成処理における構造体の関数宣言処理を説明する図である。

図 2 6は、ソースコード生成処理における配列の関数宣言処理を説明する図である。

図 2 7は、ハンドラ生成処理を説明するフローチャート図である。

図 2 8は、ハンドラ生成処理を説明するフローチヤト図である。

図 2 9は、 WS D Lによるインターフェイス定義の記述例を示す図である。 ' 図 3 0は、 WS D Lによるインターフェイス定義の記述例を示す図である。

図 3 1は、ハンドラ処理部の関数宣言を説明する図である。

図 3 2は、 W e bサービス機能の関数宣言を説明する図である。

.図 3 3は、入カメッセージの構造体定義を説明する図である。

図 3 4は、出カメッセージの構造体定義を説明する図である。

図 3 5は、自動生成されたハンドラソースコードの例を示す図である。

図 3 6は、 W e bサービスを実現するための構成例を示す図である。

図 3 7は、 S OA Pによる We bサービスの提供処理について説明するフローチャート図である。

図 3 8は、 S O A Pによる W e bサービスの提供処理にっレ、て説明するフローチャート図である。

図 3 9は、 XMLを使用した S OA Pに従った HT T Pリクエストの記述例を示す図である。

図 4 0は、 XMLプロセッサによって変換された要素木の例を示す図である。図 4 1は、印刷ハンドラによる要素木解析処理を説明するためのフローチヤ一ト図である。

図 4 2は、 W e bサービス機能の関数の引数の設定例を示す図である。

図 4 3は、印刷ハンドラでの処 S t果の設定例を示す図である。

図 4 4は、印刷ハンドラによる要素木生成処理を説明するためのスローチヤ一ト図である。

図 4 5は、生成された要素木の例を示す図である。

図 4 6は、要素木から変換された XMLを使用した S OA Pに従った HTT P レスポンスの記述例を示す図である。発明を実施するための最良の形態

以下、本発明の実施の形態を図面に基づいて説明する。

[第一実施例]

多種の画像形成機能を融合する本発明の第一実施例に係る画像形成装置 (以下、融合機と言う）は、例えば、図 1に示すような機能構成を成す。図 1は、本発明の実施例に係る多種の画像形成機能を融合する融合機の機能構成を示すプロック図である。

図 1において、融合機 1200は、プロッタ 1201と、スキャナ 1202と、その他ハードウエアリソース 1203などを有するとともに、プラットフオーム 1220とアプリケーション 1230とから構成されるソプトウエア群 1210 と、融合機起動部 1240とを備えている。

融合機起動部 1240は、癒合機 1200の電源投入時に先ず始めに実行され、プラットフオーム 1220やアプリケーション 1230を起動する。

プラットフオーム 1220は、アプリケーション 1230からの処理要求を解釈して、ハードウエア資源の獲得要求を発生させる下記に示すコントロールサービス 1250と、一または複数のハードウエア資源の管理をおこない、コント口ールサービス 12.50からの獲得要求を調停するシステムリソースマネージャー (SRM (System Resource Manager) 1223) と、 OS (Operating Syst em) 1221とを有する。

このコントロールサービス 1250は、複数のサービスモジュールにより形成され、具体的には、 SCS (System Control Service) 1222と、 ECS ((E ngine Control Service) 1224と、 MCS (Memory Control Service) 122 5と、 O C S (Operation panel Control Service) 1226と、 FCS (FAX Control Service) 1227と、 NCS (Network Control Service) 1228と、 I MH (Imaging Memory Handler) 1229とがある。なお、このプラットフォーム 1220は、あらかじめ定義された関数により前記アプリケーションからの処理要求を受信可能とするアプリケーションプログラムインターフェースを有する。

O S 1221は、 UN I X (登録商標）などの才ぺレーティング ·システムであり、プラットフオーム 1220並びにアプリケーション 1230の各ソフトウエアをそれぞれプロセスとして並列実行する。オープンソースの UN IX (登録商標）を用いることにより、プログラムの安全' I·生を確保できるとともに、ネットワーク対応可能となり、ソースコードの入手も容易となる。さらに、 OS、 TC P/I Pのロイャリティが不要であり、アウトソーシングも容易となる。

SRM1223は、 SCS 1222とともにシステムの制御およびリソースの管理をおこなうものであり、スキャナやプロッタなどのエンジン部、メモリ、 H DDファイル、ホスト I/O (セント口 I/F、ネットワーク I/F、 I EEE 1394 I/F、 RS 232C IZFなど）のハードウェア資源を利用する上位層からの要求にしたがって調停をおこない、実行制御する。

具体的には、この SRM1223は、要求されたハードウェア資源が利用可能であるかどうか（他の要求により利用されていないかどう力を判断し、利用可能であれば要求されたハードウエア資源が利用可能である旨を上位層に伝える。また、上位層からの要求に対してハードウエア資源の利用スケジューリングをおこない、要求内容' (たとえば、プリンタエンジンによる紙搬送と作像動作、メモリ確保、ファイル生成など）を直接実施するようにしてもよレ、。

SCS 1222は、アプリ管理（機能 1)、操作部制御（機能 2)、システム画面表示（ジョブリスト画面、力ゥンタ表示画面など）（機能 3 )、 L E D表示（機能 4)、リソース管理（機能 5)、割り込みアプリ制御（機能 6) 等の複数の機能を行う。具体的には、アプリ管理（機能 1) では、アプリの登録と、その情報を他のアプリに通知する処理をおこなう。操作部制御（機能 2) では、アプリの操作部使用権の排他制御をおこなう。システム画面表示（機能 3) では、操作部使用権を持つアプリからの要求内容に応じて、エンジン部の状態に対応する警告画面の表示をおこなう。 LED表示（機能 4) では、警告 LED、アプリキーなどのシステム LEDの表示制御をおこなう。リソース管理（機能 5) では、アプリが EC Sを使ってジョブを実行するにあたって、他しなければならないェンジンリソース（スキャナ、ステープルなど）の排他制御のためのサービスをおこなう。割り込みアプリ制御（機能 6 ) では、特定のアプリを優先動作させるための制御及びサービスをおこなう。

E C S 1 2 2 4は、プロッタ 1 2 0 1、スキャナ 1 2 0 2、その他ハードゥエァリソース 1 2 0 3などのエンジン部を制御するものであり、画像読み込みと印動作、状態通知、ジャムリカバリなどをおこなう。

MC S 1 2 2' 5は、メモリ制御をおこなうものであり、具体的には、画像メモリの取得おょぴ開放、ハードディスク装置 (HDD) の利用、画像データの圧縮および伸張などをおこなう。

O C S 1 2 2 6は、オペレータと本体制御間の情報伝達手段となる操作パネルを制御するモジュールであり、オペレータのキー操作ィベントを本体制御に通知する処理、各アプリが GU Iを構築するためのライブラリ関数を提供する処理、構築された GU I情報をアプリ別に管理する処理、操作パネル上への表示反映処理などをおこなう。

F C S 1 2 2 7は、システムコントローラの各アプリ層から P S TN/ I S D N網を使ったファクシミリ送受信、 B KM (バックアップ S RAM) で管理されている各種ファクシミリデータの登録/引用、ファクシミリ読み取り、ファクシミリ受信印刷、融合送受信をおこなうための A P I (Application Program Int er ace) を提供する。

NC S 1 2 2 8は、ネットワーク I /Oを必要とするアプリケーションに対して共通に利用できるサービスを提供するためのモジュ一ノレ群であり、ネトヮーク側から各プロトコルによって受ィ言したデータを各アプリケーションに捩り分けたり、アプリケーションからデータをネットワーク側に送信する際の仲介をおこなう。

本実施例において、 N C S 1 2 2 8は、複数のプロトコルのうち h t t p (Hy pertext Transfer Protocol) デーモンによって、インターネットを介して接続されるネットワーク機器とのデータ通信を H T T P (Hypertext Transfer Protoco 1)で制御し、 HTT Pリクエストヘッダで指定される処理に必要な複数の W e b サービスを関数コールによって起動し、その複数の W e bサービスによる処理結果を HTT Pレスポンスで該ネットワーク^^へ通知する。 We bサービスは、例えば、 XML (extensible Markup Language) によって記述されたメッセ一ジに従って処理を行う。

IMH1229は、イメージデータを仮想メモリ領域（ユーザー仮想空間）から物理メモリへマップする。プロセスの起動に応じて、システムコールを行ない、プロセス用の仮想メモリ領域をマップしたり、マップした仮想メモリ領域をプロセスの終了時に開放する処理等を行う。 · '

アプリケーション 1230は、ページ記述言語（PDL)、 PCLおよびポストスクリプト（PS) を有するプリンタ用のアプリケ"シヨンであるプリンタァプリ 1211と、コピー用アプリケージヨンであるコピーアプリ 1212と、ファクシミリ用アプリケーションであるファックスアプリ 1213と、スキャナ用ァプリ'ケーシヨンであるスキャナアプリ 1214と、ネットファイル用アプリケーシヨンであるネッ卜ファイルアプリ 1215と、工程検査用アプリケーションである工程検査アプリ 1216と、配信用アプリケションである配信アプリ 12 17と、実行した処理結果を We bサービスとしてする We bサービスァプリ 1218とを有する。各アプリケーション 1211〜1218は、プラットフオーム 1220上の各プロセスを利用して動作実行し得るため、画面制御、キー操作制御おょぴジョブ生成などをおこなう画面表示制御プログラムがその主体となる。なお、 NCS 1228により接続されたネットワークを介して新たなアブリケーシヨンをネットワーク経由で搭載することもできる。また、各アプリケーシヨンはアプリケーションごとに卩または削除することができる。

ここで、 We bサービスアプリ 1218とは、 NCS 1228によって通知される HTTPリクエスト対応する処理を実行するアプリケーションであって、その処理結果は、 HTTPレスポンスとして NCS 1228によって HTTPリクエストを行ったネットワーク機器へ提供される。

このように、融合機 1200は、各アプリで共通的に必要となる処理をブラットフオーム 1220で一元的に処理する。

次に、融合機 1200のハードウエア構成について説明する。図 2は、図 1に示す融合機のハードウエア構成を示すプロック図である。図 2に示すように、この融合機 1200は、オペレーションパネル 1310と、 FCU (ファックスコントロールユニット） 1320と、プロッタ 1201、スキャナ 1202及ぴその他ハードウェアで構成されるエンジン部 1350と、コントローラ 1300の AS I C1301とを PC I (Peripheral Component Interconnect) ノス等で接続した構成となる。 FCU1320は、受信したファックスデータを格納するための不揮努性メモリ 1321と、 FCU1320内での時間を計測するための RTC (Real Time Clock) 1322とを有し、通常 G 3規格に従ってファックスデータの送受信を行う。 FCU1320は、オプションとして更に G 3規格と G 4規格とを搭載しても良い。 '

コントローラ 1300は、 AS I C1301に MEM— C 1302、 HDD (H ard Disk Drive) 1303などを接続するとともに、この AS I C1301と C PU1304とを CPUチップセットの NB 1305を介して接続している。このように、 NB 1305を介して接続する理由は、 CPU1.304自体のインタ一フェイスが公開されていないためである。

ここで、この AS I C1301と NB 1305は、単に PC Iを介して接続されているのではなく、 AGP 1308を介して接続されている。このように AG P 1308を介して接続することとした理由は、この融合機 1200がブラットフォーム 1220やアプリケーション 1230を形成する複数のプロセスを実行 ■ 制御する関係上、これらを低速の PC Iで接続したのでは、パフォーマンスが低下するからである。

C PU 1304は、融合機 1200の全体制御をおこなうものであり、具体的には、 OS 1221上でプラットフオーム 1220を形成する S C S 1222、 SRM1223、 ECS 1224, MCS 1225, OCS 1226、 FCS 1 227、NCS 1228をそれぞれプロセスとして起動して実行させるとともに、アプリケーション 1230を形成するプリンタアプリ 1211、コピーアプリ 1 212、ファックスアプリ 1213、スキャナアプリ 1214、ネットフアイノレアプリ 1215、工程検查アプリ 1216、配信アプリ 1217、 We bサービスアプリ 1218を起動して実行させる。

NB 1305は、 CPU1304と MEM— P 1306、 SB 1307, AS I C 1301とを接続するためのプリッジであり、 MEM— P 1306は、融合機の描画用メモリなどとして用いるシステムメモリであり、 MEM— C 1302 は、コピー用画像バッファ、符号バッファとして用いるローカルメモリであり、 AS I C 1301は、画像処理用のハードウエア要素を有する画像処理用途向けの I Cである。

NB 1305は、 PC Iパスを介して SB 1307と接続する他、ネットヮーク通信を制御する N I C (Network Interface Card) 1311と、ノ、。ソナルコンピュータと接続し大容量の画像データの送受信を可能とする U S B (Univer sal Serial Bus) 1312及び I EEE13941313と、パラレルケーブルによつて接続可能なセントロニタス 1314と接続する。 SB1307は、 NB 13 05と ROM、 P C Iデバイス、周辺デバイスとを接続するためのブリッジである。 SB 1307は、コントローラ 1300での時間を計測する RTC (Real T ime Clock) 1323を有する。

HDD1310は、画像データの蓄積、プログラムの蓄積、フォントデータの蓄積、フォームの蓄積を行うためのストレージであり、オペレーションパネル 1 310は、操作者からの入力操作の受け付け並びに操作者に向けた表示をおこなう操作部である。

したがって、 AS I C 1301には、 MEM—C 1302を接続するための R AMインターフェイスと、 HDD 1310を接続するためのハードディスクインターフェースが設けられ、これらの記憶部に対して画像データの入出力をおこなう場合には、入出力先が RAMインターフェイスまたはハードディスクインターフェースに切り替えられる。

AGP 1308は、グラフィック処理を高速化するために提案されたグラフィックスァクセラレーターカード用のバスインターフェイスであり、システムメモリに高スループットで直接アクセスすることにより、グラフィックスァクセラレ一ターカードを高速にする。

次に、アプリケーション 1230と NCS 1228間のデータ送受信制御について説明する。

図 3は、通信制御を行うプロセスとアプリケーシヨンとの仲介を行うプロセスによる処理の全 ίΦ¾要を示す図である。図 3中、図 1に示す融合機 1200の機能構成のうち主要な機能構成のみが図示され、他の機能構成は省略される。図 3 において、融合機 1200は、種々の画像形成処理を実行するアプリケーション 1230と、種々の通信プロトコルを制御する複数の通信制御デーモンを有する NCS 1228と。 NCS 1228とアプリケーション 1230とのインターフエイスを行う NAI 8とを有し、ネットワーク 15に接続される。 NCS 122 8は、デーモン 9とアプリケーション 1230との仲介をする要求仲介デーモン 7と、種々の通信プロトコルデーモンによって構成されるプロトコル制御デーモ. ン 9とを有する。プロトコル制御デーモン 9は、 h t t pデーモン 2と、 i p デーモン 91と、 f t pデーモン 92と、 USBデーモン 93と、 I EEE1394 デーモン 94と、セントロニ 'タスデーモン 95とを有する。

h t t pデーモン 2は、例えば、 HTTP (Hypertext Transfer Protocol) に従った通信制御を行い、ネットワークの設定、機器の状態監視、及び、アプリと連携して XMLによる β制御コマンドの送受信を行う。 i p pデーモン 91は、 HTTPベースの印刷プロトコルである I PP (Internet Printing Protocol)による印刷データの受信を制御する。 f t pデーモン 92は、 FTP (File Trans fer Protocol) によるサービスの提供を制御する。

USBデーモン 93は、 U S Bケーブルで直結されるからの印刷データの受信を制御する。 I EEE 139 デーモン 94は、 I EEE 1394専用ケーブルで直結される機器からの印刷データの受信を制御する。セントロニクスデーモン 9 5は、パラレルケーブルで直結される βからの印刷データの受信を制御する。図 3より、アプリケーション 1230は、 ΝΑ 18を介して、 NCS 1228 の要求仲介デーモン 7にアプリ登録を行う（ステップ SO) 。ネットワーク 15 を介して接続要求を受信をすると（ステップ S I) 、 NCS 1228のプロトコル制御デーモン 9は、要求仲介デーモン 7へ通知する（ステップ S 2) 。要求仲介デーモン 7は、 NAI 8を介して、アプリケーション 1230へ接続要求を通知する（ステップ S 3) 。アプリケーション 1230は、 NAI 8を介して、プロトコル制御デーモン 9に接続を行う（ステップ S 4) 。プロトコル制御デーモン 9は、アプリケーション 1230からの接続によって、ネットワーク 15を介して、データの送受信をアプリケーション 1230との間で行う（ステップ S 5)。上記より、 N C S 1 2 2 8は、要求仲介デーモン 7とプロトコノ Vf U御デーモン 9の 2つのプロセスとによって通信を行う点において、コントロールサービス 1 2 5 0の他のサービスと異なる。

N C S 1 2 2 8は、大量のデータをプロセス間で通信する手段として共有メモリを用いる。共有メモリは、複数の異なるプロセスからアクセスすることのできるメモリ領域であり、 N e t B S D (登録商標）の備える標準機能である。共有メモリに対して、複数のプロセスから排他的にアクセスするには、データの読み書きに関する情報を互いにやりとりする必要がある。

図 3示す処理の全«要において、 N C S 1 2 2 8とアプリケーション 1 2 3 0間で大量のデータを受け渡すためのシーケンスについて図 4力ら図 8で詳細に説明する。

図 4は、アプリケーションの登録を行う登録シーケンスを示す図である。図 4 において、アプリケーション 1 2 3 0は、要求仲介デーモン 7に問い合わせを行い（ステップ S 1 0 1 )、要求仲介デーモン 7からサポー'トするサービスの通知を受けると (ステップ S 1 0 2 )、アプリケーション 1 2 3 0が行うサービスの内容を通知することによって要求仲介デーモン 7にアプリケーションの登録を行う (ステップ S 1 0 3 )。例えば、「データ受信サービス」として、アプリケーション名、スプール機能「なし」、及びジョブ機能「なし」等が登録される。

この登録によって、要求仲介デーモン 7は、プロトコル制御デーモン 9から接続の通知を受けた際には、どのアプリケーションとどの通信プロトコルデーモンとの接続を仲介すべきかを知ることができる。

図 5は、アプリケーション用バッファの登録を行うバッファ登録シーケンスを示す図である。図 5において、アプリケーション 1 2 3 0は、送受信バッファ獲得処理を実行する。アプリケ一ション 1 2 3 0は、要求仲介デーモン 7に対して、アプリケーション 1 2 3 0のための複数の送受信バッファの登録を行ない（ステップ S 1 1 1 )、更に、登録した送受信バッファをオープンし（ステップ S 1 1 2 )、要求仲介デーモン 7から送受信バッファ管理情報を取得する（ステップ S 1 1 3 )。このとき、アプリケーション 1 2 3 0は、自分専用に複数の送受信バッファを共有メモリ内に確保する。図 6は、アプリケーションヘリクェストを通知するリクエスト通知シーケンスを示す図である。図 6において、プロトコノ御デーモン 9は、ネットワーク 1 · 5を介して接続を受信すると（ステップ S 11 ) 、要求仲介デーモン 7へ接続通知を行う（ステップ S 12) 。プロトコ ^lj御デーモン 9からの接続通知に応じて、要求仲介デーモン 7は、アプリケーシヨン 1230が登録した複数の送受信バッファの一つを割り当てて、プロトコル制御デーモン 9に通知する（ステップ S 13)₀

更に、要求仲介デーモン 7は、アプリケーション 1230に対して接続通知を行い、接続先を通知するステップ S 14)。この接続通知に応じて、アプリケーシヨン 1230は、要求仲介デーモン 7に対して接続許可を行う（ステップ S 15)。そして、アプリケ一ション 1230は、プロトコル制御デーモン 9と接続する (ステツプ S 16)。アプリケーション 1230と接続されるプロトコル制御デーモン 9は、図 3に示されるデーモン 2、 91〜 95のいずれかである。更に、アプリケーシヨン 1230は、プロトコル制御デーモン 9に対して、通知タイミングの設定を行い（ステップ S 17)、接続先からのデータ受信を開始するよう要求する (ステップ S 18)。

図 7は、データ送受信シーケンスを示す図である。図 7において、 NCS 12 30のプロトコル制御デーモン 9は、受信データを共有メモリ 99内の受信パッファ 97に書き込むと（ステップ S 21)、書き込みポインタを受信データ分移動する (ステップ S 22)。プロトコル制御デーモン 9は、アプリケーシヨン 123 0へ受信バッファへの書き込みを通知する（ステップ S 23)。この通知によって、書き込みを開始した開始ボインタと書き込みを終了した終了ボインタとが通知される。

プロトコル制御デーモン 9からの通知を受けて、アプリケーション 1230は、受信データを共有メモリ 99から読み出し（ステップ S 24)、読み出しポインタを受信データ分移動する（ステップ S 25)。そして、アプリケーション 1230 は、プロトコル制御ーモン 9に受信バッファからの読み出しを通知する（ステップ S 26)。

アプリケーション 1230からネットワーク 15にデータ送信する場合について説明する。アプリケーション 1 2 3 0は、送信データを共有メモリ 9 9内の送信用バッファ 9 8に書き込むと（ステップ S 2 7 )、書き込みポインタを送信データ分移動する（ステップ S 2 7—2 )。アプリケーション 1 2 3 0は、プロトコル制御デーモン 9へ送信バッファへの書き込みを通知する（ステップ S 2 8 )。この通知によって、書き込みを開始した開始ポインタと書き込みを終了した終了ボインタとが通知される。

アプリケーション 1 2 3 0からの通知を受けて、プロトコル制御デーモン 9は、送信データを共有メモリ 9 9から読み出して接続先へ送信し（ステップ S 2 9 )、読み出しポイントを移動する（ステップ S 3 0 )。そして、プロトコル制御デーモン 9は、アプリケーション 1 2· 3 0に送信パッファからの読み出しを通知する（ス · テツプ S 3 0— 2 )。

図 7において、説明の便宜上、受信データの書き込みの後に読み出しが行われるように説明したが、書き込みと読み出しが同時に行われても良い。送信データの書き込み及び読み出しについても同様である。

図 8は、アプリケーションのコネクションを終了するコネクション終了シーケンスを示す図である。図 8において、プロトコゾ H 御デーモン 9は、アプリケーシヨン 1 2 3 0に対して、データ受 ί言が完了したことを通知する（ステップ S 3 1 ) 。この通知は、例えば、ネットワーク上の接続が切断されたときに通知される。通知を受けたアプリケーション 1 2 3 0は、切断状態である判断して、プロトコル制御デーモン 9に対してデータを受信したデーモンとの切断を要求する (ステップ S 3 2 ) 。プロトコル制御デーモン 9は、終了処理をおこない、要求仲介デーモン 7に終了を通知する（ステップ S 3 3 ) 。

上記より、データの読み書きに関する情報をアプリケーシヨン 1 2 3 0とプロトコル制御デーモン 9との間で互いにやりとりすることによって、共有メモリ 9 9に対して、複数のプロセスから排他的にアクセスすることが可能となる。

上記より、本発明によれば、融合機 1 2 0 0に、多種多様なインターフェイスを介して接続される; βとの間の印刷データ及び画像データの送受信制御を行うことによって、多種多様な通信プロトコルと夫々異なる画像形成処理を行う複数のアプリケーシヨンとの接続を仲介する要求仲介デーモン Ί及ぴ共有メモリを用いてデータ送受信を制御するプロトコ御デーモン 9が構成される。そのため、複数の通信プロトコルのインターフェイスと各アプリケーションとが互いを意識する必要がない。従って、このような融合機 1 2 0 0への通信プロトコル及ぴァプリケーションの i ¾口を容易に行うことができる。

以上、第一実施例にて説明してきたように、本願発明によれば、多種多様なィンターフェイス介して接続される βとの間の印刷データ及び画像データの送受信制御を行うことによって、多種多様な通信プロトコルと夫々異なる画像形成処理を行う複数のアプリケーションとを仲介する仲介処理部が画像形成装置内に構成されるため、複数の通信プロトコルのインターフェイスと各アプリケーションとが互いを意識する必要がない。従って、本願発明に係る画像形成装置への通信プロトコル及ぴアプリケーションの追加を容易とする。

本願発明において、多種多様な通信プロトコルと画像形成に関する処理を寒行するアプリケーションとの接続を仲介する接続要求仲介手段は、上記アプリケーシヨンからの登録要求に応じて該アプリケーションを登録する登録手段と、上記アプリケーションから送受信バッファの登録要求に応じて、該アプリケーション専用に使用される受信用パッファ及び送信用パッファとを登録して使用可能状態とするノッファ登録手段とを有するように構成することができる。

また、上記接続要求仲介手段は、上記各通信プロトコルデーモンからの接続通知を受けると、上記共有メモリ内に上記接続中にて使用される受信用バッファと送信用バッファとを割り当てて、上記通信プロトコルデーモンに通知する送受信バッファ割当手段を有するように構成することができる。

更に、アプリケーション 1 2 3 0は、上記接続要求仲介手段から接練の通知を受信すると、 .該接続要求仲介手段に接続許可を通知すると共に、上記通信プロトコルデーモンに対して接続を行う接続処理手段と、上記通信プロトコルデーモンへデータ受信の開始を要求するデータ受信開始要求手段とを有するように構成することができる。

また、各通信プロトコルデーモンは、上記通信プロトコルデーモンが受信データを上記送受信バッファ割当手段によって割り当てられた上記受信用バッファに書き込んで、書き込み開始位置をデータ長分移動する受信データ書込手段と、上記アプリケーションに、上記受信用バッファへ上記受信データを書き込んだことを通知すると共に、該受信データの書き込み開始位置と書き込み終了位置とを指定する書き込み通知を行う受信書込通知手段とを有するように構成することができる。 ,

更に、アプリケーシヨン 1 2 3 0は、上記通信プロトコルデーモンから上記受信データの書き込み通知を受信すると、該書き込み通知で指定される上記書き込み開始位置から上記書き込み終了位置まで上記受信用バッファから上記受信データを読み出して、読み出し開始位置を該書き込み終了位置まで移動する受信データ読込手段と、上記通信プロトコルデーモンに、上記受信用バッファから上記受信データを読み出したことを通知する受信読出通知手段とを有するように構成す

-ることができる。

また、アプリケーション 1 2 3 0は、上記パッフケ登録手段によって登録された上記送信用バッファへ送信データを書き込んで、書き込み開始位置をデータ長分移動する送信データ書き込み手段と、上記通信プロトコルデーモンに、上記送信用バッファへ上記送信データを書き込んだことを通知すると共に、該送信データの書き込み開始位置と書き込み終了位置とを指定する書き込み通知を行う送信書込通知手段とを有するように構成することができる。

. 更に、上記各通信プロトコルデーモンは、上記アプリケーションから上記送信データの書き込み通知を受信すると、該書き込み通知で指定される上記書き込み開始位置から上記書き込み終了位置まで上記送信用バッファ力ら上記送信データを読み出して、上記アプリケーションと接続した上記通信プロトコルデモンに該送信データを送信させる送信データ読出手段と、上記読み出し開始位置を上記書き込み終了位置まで移動する読出開始位置移動手段と、上記アプリケーションに、上記送信用バッファから上記送信データを読み出したことを通知する送信読出通知手段とを有するように構成することができる。

[第二実施例]

第二実施例において、融合機 1 2 0 0の機能構成及びハードウェア構成は、第一実施例における機能構成及びハードウエア構成と同様であるため、その説明を省略する。上記第一実施例における機能構成及ぴハードウェア構成に加えて、更に、 NC S 1228とアプリケーション 1230との間で行われるデータ送受信に関する処理をシーケンス制御ライブラリとして共通化すると共に、 We bサービス機能を実現する際には同様のいくつもの処理が行なわれるため、これら同様の処理を部品化して共通化する方法が考えられる。

以下に、シーケンス制御ライブラリとして共通ィヒした場合の基本構成について図囪 9で説明する。図 9は、アプリの開発及びを容易とする融合機の基本構成例を示す図である。図 9中、図 1に示す融合機 1200の機能構成のうち主要な機能構成のみが図示され、他の機能構成は省略される。図 9において、アプリケーシヨン 1230と NCS 1228とは、中間層としてのシーケンス制御ライブラリ 100を介して、受信データ及ぴ送信データの受け渡しを行う。ここでは、 HTTPデーモン 2によつて通信制御される場合につ！/、て説明する。他デーモンによる通信制御の場合においても同様に、シーケンス制御ライブラリ 100が行アプリケーション 1230は、データの送信方法を指定するメソッド毎に処理部を有し、例えば、 P O S Τメソッドによる処理を行う POSTメソッド処理部 103と、 GETメソッドによる処理を行う GETメソッド処理部 104と、 P O S Tメソッド及び G E Tメソッド以外のメソッドの処理を行うその他メソッド処理部 199とを有する。各処理部 103、 104及び 199では、メソッドに特有の^ f処理を行うと共に、処理要求に従った処理を実行し、その処理結果を W e bサービスとして提供する。

シーケンス制御ライブラリ 100は、 HTTPに従った接続を管理する HTT P接続管理部 101と、 HTTPに従つてデータの送受信を行うことによってサ一ビスを実行する HTTPサービス実行部 102とを有する。

H T T Pサービス実行部 102は、 H T T Pサービスの要求毎に接続が確立されるため、複数の HTTPサービス実行部 102がスレッド（又はプロセス）として生成される。 HTTPサービス実行部 102は、 HTTPヘッダで指定されるデータの送信方法を指定するメソッドに従つて G E Tメソッド処理部 104、 P O S Tメソッド処理部 103、その他メソッド処理部 199とに処理を振り分ける。

NCS 1228は、ネットワーク 15を介してデータ送受信を HTTPに従つて通信制御する HTTPデーモン 2と、 HTTPデーモン 2からの接続及び切断の通知を受けると、 HTTP接続管理部 101との間で接続及び切断の処理を行う要求仲介デーモン 7とを有する。

HTTP接続管理部 101は、要求仲介デーモン 7から最初の接続通知を受け • ると、共有メモリ 99の初期化を行い、可能な接続数分の受信バッファ 97及び送信バッファ 98を登録し、データ送受信可能な状態どする。また、この初期化によって、複数の接続要求を受付けることができ、接続毎に HTTPサービス実行部 1.02がスレツドとして生成され、接続毎に HTT Pサービスの ^^を可能とする。 .

例えば、 HT T Pデーモン 2が同時に受けることのできる接続要求の最大数が 3であるとすると、予め 3つのスレッドを常駐させておぐことで、処理性能を向上させることができる。一方、接続毎に 1つのスレッドを生成し、処理が終了した時点で終了させることも可能である。

アプリケーション 1230の各処理部 103、 104及び 199は、 HTTP デーモン 2及ぴ要求仲介デーモン 7と直接データのやり取りを行うのではなく、 HTTPサービス実行部 102から処理要求を受けて、処理結果を共有バッファ 99を介して HTTPサービス実行部 102に通知する。

各処理部 103、 104及び 199は、例えば、 HT T Pサービス実行部 10 2からの処理要求を受信後に、処理の対象となる印刷データ（MB単位のデータ）を共有バッファ 99から読み込み、処理要求に応じた処理を印刷データに行った処理結果を共有バッファ 99に書き込んで、 We bサービスとして HTTPサービス実行部 102を介して処理要求元に提供する。処理結果は、例えば、その印刷データに対して画像形成処理を行うことによって生成される画像データ（MB 単位のデータ）、或いは、画像形成処理に関するステータスを示すステータス情報等である。

つまり、アプリケーション 1230の各処理部 103、 104及ぴ 199は、 H T T Pサービス実行部 102によつて処理要求が振り分け可能な処理部であれば良い。

また、同様に、種々のアプリケーションの !]、つまり、メソッドに対応する処理部の融合機 1200へのをも容易に行うことができる。

図 9では、 We bサービスを提供するためのメソッド毎に処理部を容易に追加することができる基本構成例について説明した。し力し、このようなメソッド毎の処理部では；同じメソッドであるが異なる We bサービスを提供する場合、 W e bサービスを行うための実際の処理を実行する前に必要となるメソッドに特有の処理を We bサービス毎に備える必要がある。メソッドに特有の処理を共通ィ匕することが考えられる。

上記 N CS 1228とアプリケーシヨン 1230との間で行われるデータ送受信に関する処理をシーケンス制御ライブラリとして共通化すると共に、メソッドに特有の処理を共通ィ匕した場合の構成について図 10で説明する。また、その処理フローについて図 11及び図 12で詳述する。

図 10は、アプリの開発及び ϋ¾卩を容易とする融合機の第一構成例を示す図である。図 10中、図 1に示す融合機 1200の機能構成のうち主要な機能構成のみが図示され、他の機能構成は省略される。図 10中、図 9と同様の処理部には同一の符号を付しその説明を省略する。

図 9に示す基本構成例との違いは、アプリケーション 1230の POSTメソッド処理部 103において、 We bサービスアプリ 1218— 1と We bサービスアプリ 1218— 2とが、 POSTメソッドに特有の XMLによるメッセージの解析及び XMLによるメッセージの生成を行う XML処理部 103— 2と、 X MLの解析及び生成に必要な部品を有する XML解析部 103— 3とを共有化した構成となっている点である。

HTT Pサービス実行部 102から P O S Tメソッド処理部 103に処理が振り分けられると、 POSTメソッド処理部 103は、処理要求が XMLメッセ一ジにて記述されている場合、一様に、 XML処理部 103— 2に XMLメッセ一ジの解析を行わせ、実際に W e bサービスとして要求に応じた処理を行う W e b サービスアプリ 1218—1及び 1218— 2からの応答を XML処理部 103 —2によって XMLメッセージとして記述させる。 XML処理部 103— 2は、必要に応じて XML解析部 103-3を実行し、 XM.Lメッセージの解析及び生成を行う。

このような第一構成例では、各 We bサービスアプリ 1218— 1及び 121 8-2は XMLメッセージの解析及び生成を行う必要がないため、開発者は、 P O S Tメソッドによって W e bサービスを実際に行う処理部分のみを開発すれば良いため、新たな We bサービスアプリの融合機 1200への追加を容易に行うことができる。

図 10に示す第構成例において、 We bサービスとして We bサービスァプリ 1218が実行され、その処理結果が HTTPデーモン 2に通知されるまでの処理フローについて図 11及び図 12にて説明する。図 11及ぴ図 12は、図 1 0の第一構成例における処理フローを示す図である。図 1.1において、要求仲介デーモン 7が HTTP接続管理部 101に接続を通知すると（ステップ S 40)、 11丁丁？接続管理部101は、接続通知キュー 105にその通知を追加する（ステツプ S 41)。 HTTPサービス実行部 102は、 HTTP接続管理部 101に対して接続の取得を要求する（ステップ S 42 )。 HTTP接続管理部 101は、その要求に応じて、接続通知キュー 105に対して通知の取得を要求し（ステツプ S43)、接続通知キュー 105から接続通知を取得する（ステップ S 44)。

HTTP接続管理部 101は、接続通知キュー 105から取得した接続通知に基づいて、 HTTPデーモン 2との接続を行う。また、 HTTP接続管理部 10 1は、接続管理情報を生成して接続処理部 89に保存する（ステップ S46)。接続処理部 89は、 HTTPサービス実行部 102で行われる処理の一部である。一方、 HTTP接続管理部 101からの接続に応じて、 HTTPデーモン 2は、接続処理部 89に HTTPヘッダ情報を保存する（ステップ S 47)。

HTTP接続管理部 101は、 HTTPサービス実行部 102に対して接続管理情報を通知し（ステップ S 48 )、 H T T Pサービス実行部 102は、接続管理情報が POSTメソッドを指定している場合、 POSTメソッド処理部 103に対して処理の依頼を行う（ステップ S 49)。 POSTメソッド処理部 103は、 Con t e n t— Typ eとして t e x t/xm 1が指定されている：^、 XM Lメッセージの解析を行うため XML処理部 103— 2に対して処理を依頼する (ステップ S 50)。

XML処理部 103— 2は、接続処理部 89に対してデータの読み込みを要求する（ステップ S 51)。 HTTPデーモン 2は、受信バッファ 97へ受信データを書き込んだことを接続処理部 89に通知する（ステップ S 52)。接続処理部 8 9は、受信データを XML処理部 10 S— 2に通知する（ステップ S 53)。

XML処理部 103 2は、受信データのうち XMLメッセージの部分を XM L解析部 103— 3に対して解析を依頼する（ステップ S 54)。そして、 XML 処理部 103— 2は、 XML解析部 103— 3に対して結果の取得を要求すると、 XML解析部 1.0.3— ^;3は、 XMLメッセージの構文を解析した結果として要素木を XML処理部 103— 2に通知する（ステップ S 56)。

^ML処理部 103— 2は、 XML角部 103— 3から通知された要素木によって処理を We bサービスアプリ 1218に依頼する- (ステップ S 57)。依頼に応じて We bサービスアプリ 1218は、処理を実行し、その処理結果を要素木によって XML処理部 103— 2に通知する（ステップ S 58)。

XML処理部 103— 2は、通知された要素木に基づいて、 We bサービスァプリ 1218による処理結果を接続管理部 87に XMLで書き出すことによって XMLメッセージを生成する（ステップ S 59)。そして、接続処理部 89は、 X MLメッセージを送信バッファ 98へ書き込んで、 HTTPデーモン 2へ送信パッファ 98への書き込みを通知する（ステップ S 60)。

また、 XM L処理部 103— 2は、終了通知を接続処理部 89に対して行う（ステツプ S 61)。その終了通知に応じて、接続処理部 89は、 HTTPデーモン 2 との接続の切断を行う（ステップ S 62)。更に、 XML.処理部 103— 2は、接続処理部 89に処理終了を通知する（ステップ S 63 )、接続処理部 89は、 HT TPサービス実行部 102に処理終了を通知する（ステップ S 64)。そして、 H T T Pサービス実行部 102は、処理が終了したことを H T T P接続管理部 10 1に対して通知する（ステップ S 65)。

上記処理フローにおいて、 We bサービスアプリ 1218は、ステップ S 57 及ぴ S 58にて XML処理部 103-2のみとで相互の処理が行われるだけである。このように、シーケンス制御ライブラリ 100と、アプリケーション 123 0の POSTメソッド処理部 103内の XML処理部 103— 2及ぴ XML解析部 103— 3等による部品化され共有ィ匕された処理部によって、新たな POST メソッドによる We bサービスアプリの開発を容易とすることができる。

更に、共有メモリ 99を用いた送受信データのやり取りを実現するシーケンス制御ライブラリで生成きれるスレツドの構成について図 13及ぴ図 14で説明する。図 13及び図 14は、 'シーケンス制御ライブラリのスレツド構成の例を示す図である。 .

図 13において、融合機 1.200が起動すると生成される初期化スレヅド 19 1は、仲介デーモン用クライアントスレツド 192を生成する（ステップ S 61)。仲介デーモン用クライアントスレッド 192は、 HTTP接続管理部 101の処理単位であって、 HTT-P接続管理部 101として機能する。そして、初期化スレッド 1.91.は、要求仲介デーモン 7にアプリケーションを登録する（ステツプ S 62)。更に、初期化スレツド 191は、 HTTPサービス実行スレツド 193 を少なくとも 1つ以上を生成する (ステップ S 63)。 HTTPサービス実行スレッド 193は、 HTTPサービス実行部 102の処理単位であって、 HTTPサ一ビス実行部 102として機能する。

仲介デーモン用クライアントスレッド 192は、要求仲介デーモン 7から接続通知を受けると（ステップ S 64)、接続通知キュー 105に接続通知を追加して、 HTTPサービス実行スレツド 193の 1つに接続を通知する（ステップ S 65)。接続通知を受けた HTTPサービス実行スレッド 193は、 HTTPデーモン用クライアントスレツド 194を生成する（ステップ S 66)。 HTTPサービス実行スレッド 193は、 HTTPデーモン 2と接続する（ステップ S 67)。

要求仲介デーモン 7は、 HTT Pデーモン用クライアントスレッド 194に対して受信バッファ 97に受信データを書き込んだことを通知する（ステップ S 6 8)。そして、 HTTPデーモン用クライアントスレツド 194は、 HTTPサービス実行スレツド 193に受信データが書き込まれたことを通知する（ステップ S 69)。 HTTPサービス実行スレツド 193は、要求仲介デーモン 7が書き込んだ受信データを受信バッファ 97から読み出す（ステップ S 70)。

H T T Pサービス実行スレッド 193は、送信データを送信パッファ 98へ書き込んで、送信バッファへの書き込み通知を要求仲介デーモン 7へ通知する（ステツプ S 7 Do要求仲介デーモン 7は、送信バッファ 98から送信データを取り出す (ステップ S 72)。 HTTPサービス実行スレツド 193は、要求仲介デーモン 7との接続を切断する（ステップ S 73)。

シーケンス制御ライブラリ' 100におけるスレツドの処理によって、共有メモリ 99を使用することによる大量のデータのアクセスを可能とすると共に、ァプリケーシヨン.1230に実装された We bサービス機能を実際に行う We bサービスアプリ 1218から切り離した処理として実現することができる。図 10に示される GETメソッド処理部 104及ぴその他メソッド処理部 199での実際に We bサービス機能を行う We bサービスアプリについても同様である。よつて、 W e bサービス機能の.開発者は、 NCS 1228とアプリケーシヨン 12.3 0との間で行われるデータ送受信に関する処理フローについての知識を必要とすることなく、 We bサービス機能の開発を行うことができる。

図 10に示す第一構成例では、 POSTメソッドにて XMLメッセージによつて処理の依頼及び応答を行う場合について説明したが、 POSTメソッドには、コンテントタイプに応じた様々な処理形態がある。そのような POSTメソッドにおける処理形態毎に共通ィ匕した ¾^について図 15で説明する。図 15は、ァプリの開発及び追加を容易とする融合機の第二構成例を示す図である。図 15中、図 10と同様の処理部には同一の符号を付し、その説明を省略する。

図 15において、 POSTメソッド処理部 103は、図 10に示される処理部 103— 2及び 103— 3と 1218— 1から 1218— 2に相当する処理部 1 03— 2及び 103— 3と 1218— 4に加えて、共通化される処理部として、コンテンッタイプに基づいて処理を分配するコンテントタイプ分配処理部 113 ー1と、コンテンツタイプに FORMが指定された処理要求を解析する FORM データ^?部 113— 2と、コンテンツタイプにマルチパートが指定された処理要求解析するマルチパート解析部 113— 4とを有し、 W e bサービスのを行う処理部として、 FORMで設定されたデータを実際に処理する We bサービスアプリ 1218— 3と、マルチパートによって指定されるデータファイルを実際にアップロードするための処理を行う We bサービスアプリ 1218— 5とを有する。

コンテンツタイプ分配処理部 113— 1は、コンテンツタイプに「application /x-www-form-urlencodedjが指定されている場合、 FORMデータ解析部 113 一 2に処理要求を分配し、コンテンツタイプに「nmltipart/form-data」が指定されている場合、マルチパート解析部 113— 4に処理要求を分配し、コンテンッタイプに「text/xmlj が指定されている場合、 XML処理部 103— 2に処理要求を分配する。

処理要求を分配されると、 F ORMデータ解析部 113— 2、マルチパート解 ' 析部 113— 4及ぴ XML処理部' 103-2は、夫々処理の解析処理を行った後、処理要求に対応する We bサービスアプリ 1218— 3、 1218— 5、 121 8— 4に対して処理を行わせる。 - このように、 ΡΌ S Tメソッドで扱われるコンテンツタイプに応じた所定の解析処理を共有化することによって、開発者は、コンテンツタイプに応じた所定の解析処理に関する知識を必要とすることなく、新たな We bサービスアプリ 12 18の開発を行うことができ、また、融合機 1200への新たな We bサービスアプリ 1218の追加を容易に行うことができる。

次に、 G E Tメソッド処理部 104におレ、て、 G E Tメソッドに特有な処理を共有化する構成について図 16で説明する。囱 16は、アプリの開発及び追加を容易とする融合機の第三構成例を示す図である。図 16中、図 9と同様の処理部には同一の符号を付し、その説明を省略する。

図 16において、 GETメソッド処理部 104は、共通化される処理部として、 We bサービスを特定する URL (Uniform resource Locator)に基づいて処理要求を分配する UR L分配処理部 104— 1を有し、 We bサービスの提供を行う処理部として、 URLに対応する複数の We bサービスアプリ 1218— 6から 1218— 8を有する。

このように、 G E Tメソッドで扱われる U R Lの所定の解析処理を共有化することによって、開発者は、 URLの所定の解析処理に関する知織を必要とすることなく、新たな We bサービスアプリ 1218の開発を行うことができ、また、融合機 1200への新たな We bサービスアプリ 1218の i ¾を容易に行うことができる。

また、融合機 1 2 0 0が図 1 5に示す P O S Tメソッド処理部 1 0 3と、図 1 6に示す G E Tメソッド処理部 1 0 4とを有するように構成されることによって、 P O S Tメソッド及ぴ G E Tメソッドのレ、ずれにぉレヽても、 W e bサービスァプリ 1 2 1 8の開発及ぴ追加を容易に行うことができる。

本発明によれば、融合機 1 2 0 0が W e bサービスを提供するために必要な処 -理部を部品化し複数のアプリケーションにて共有できる構成とすることができる。したがって、 W e bサービスの提供に必要な同じような機能をまとめて部品化され、実装されるアプリケーションによってそれら部品化された機能（処理部) を再利用することができるため、アプリケーションの開発及び融合機 1 2 0 0への該アプリケーションの追加を容易に行える。

以上、第二実施例にて説明してきたように、本願発明によれば、 W e bサービスを提供するために必要な処理部を部品化し複数のアプリケーションにて共有できる構成であるため、 W e bサービスを提供するアプリケーションの開発を容易とする画像形成装置を提供することができる。

本発明において、上記接続管理情報を生成し接続処理を行う接続処理手段は、上記処理要求が振り分けられた上記メソッド処理部から処理通知を受信すると、上記 W e b通信プロトコルデーモンとの接続を切断するように構成することができる。

また、上記接続処理手段は、上記 W e bサービス実行手段に上記処理要求に応じた処理を終了したことを通知し、上記 W e bサービス実行手段は、上記 W e b 接続管理手段に上記処理の終了を通知するように構成することができる。

更に、コンピュータに、メソッドに従った所定の処理を行う複数のメソッド処理手順と、処理要求に応じて、該処理要求で指定される上記メソッドに対応する上記メソッド処理手順に該処理要求を振り分けることによって W e bサービスを実行する W e bサービス実行手順とを実行させるためのプログラムとすることができる。

[第三実施例]

本発明の一実施例に係るハンドラ自動生成装置は、図 1 7に示すような機能構成を有する。図 1 7は、本発明の一実施例に係るハンドラ自動生成装置の機能構成を示すブロック図である。図 1 7において、ハンドラ自動生成装置 500は、コンピュータ装置であって、メッセージのデータ形式と We bサービス機能におけるプロダラム言語にて処理可能なデータ形式との違レ、を吸収するプログラムを 5 生成するハンドラ自動生成部 5 10と、 WSDL (Web Service Description L anguage) によるインターフェイス定義 521と、ハンドラを実行するために必要なソースコード 531とを記憶するための記憶媒体（例えば、ハードディスクドライブ（HDD)) 有する。

ハンドラ自動生成部 510は、 WSDL (Web Service Description Langua L0 ge) によるインターフェイス定義 521を入力し、 XML (extensible Markup Language) で記述された要求メッセージの構文を解析して要素木を生成して、要素木に基づいて We bサービス機能 (WSF) を関数コールするための引数を' 設定すると共に、 We bサービス機能からの戻り値を含む XMLによる応答メッセージを記述するための要素木を生成するハンドラ処理部のソースコードを生成 L5 して出力する処理部である。

ハンドラ自動生成部 510は、 ]^1^解析部51 1と、タイプライブラリ生成部 51 2と、ハンドラソースコード生成部 51 3と、 XMLスキーマ解析部 51 4と、タイプ要素解析部 51 5と、メッセージ要素解析部 5 16と、操作要素解析部 5 17と、インターフェイス定義 521を入力するファイル入力部 520と、 20 ソースコード 53 1を出力するファイル出力部 530とを有する。

インターフェイス定義 521は、どういうインターフェイスで 1つの We bサ一ビスを提供するかを定義し、 WSDLによるインターフェイス定義ファイル 5 . 22と、インターフェイス定義ファイル 522からのインポートによって取り込まれる型定義ファイル 523とで構成される。インターフェイス定義ファイル 5 5 22にてインポートによって型定義ファイル 523が取り込まれない場合は、型定義フアイノレ 523が存在しない。

ソースコード 531は、例えば、 C言語のソースコードであって、ハンドラ処理部のヘッダファイルとプログラムファイルとで構成されるハンドラソースコー. ド 532と、ハンドラソースコード 532から参照されるタイプライブラリ 53 3とで構成される。タイプライブラリ 533は、ヘッダファイルとプログラムフアイルとで構成され.る。

フアイノレ入力部 520は、利用者によって指定されたインターフェイス定義 5 21をハンドラ自動生成部 510に入力し（ステップ S 81)、 XML解析部 51 1に通知する（ステップ S 82)。 XML解析部 511は、ファイル入力部 520 力ら受け取ったインターフェイス定義 521に基づいて、 XMLの構文を解析して要素木を生成する。そして、 ^1 解析部511は、その要素木をタイプ要素解析部 515に通知し（ステップ S 83— 1 )、またメッセージ要素解析部 516 に通知し（ステップ S 83-2),更に操作要素解析部 517に通知する（ステツプ S83— 3)。

タイプ要素解析部 515は、タイプライブラリを生成するために要素木内の ty pes要素を解析する処理部であって、要素木を解析して型定義を示す types要素'' を検出し、 XMLスキーマ解析部 514に検出した types要素を解析させる（ステツプ S 84—1)。そして、タイプ要素解析部 515は、 XMLスキーマ解析部 514による解析結果をタイプライブラリ生成部 512に通知する（ステップ S 85— 1)。

メッセージ要素解析部 516は、ハンドラソースコードを生成するために要素木内の message要素を解析する処理部であって、その解析結果をハンドラソースコード生成部 513に通知する（ステップ S 85— 2)。操作要素解析部 517は、ハンドラソースコードを生成するために要素木内の operation要素を解析する処理部であって、その解析結果をハンドラ'ソースコード生成部 513に通知する（ステツプ S 85— 3)。

タイプライブラリ生成部 512は、タイプ要素解析部 515から通知された解析結果に基づいてタイプライブラリを生成する処理部であって、生成されたタイプライブラリはファイル出力部 530へ通知される（ステップ S 86— 1)。ハンドラソースコード生成部 513は、メッセージ要素解析部 516及ぴ操作要素解析部 517から通知された解析結果に基づいて、ソースコードを生成してフアイル出力部に通知する（ステップ S 86— 2)。ファイル出力部 530はハンドラソースコード生成部 513から通知されたソースコードをハンドラソースコード 651

31

532として、また、タイプライブラリ生成部 512から通知されたタイプライブラリをタイプライブラリ 533として、ソースコード 531を出力する（ステップ S 87)。

このように、ハンドラ自動生成装置 500は、 We bサービスを定義するインターフェイス定義 521の入力によって、自動的にハンドラ処理部のソースコード 531を出力することができる。

このようなハンドラ自動生成装置 500は、図 18に示すようなハードウェア構成を有する。図 18は、本発明の一実施例に係るパンドラ自動生成装置のハー Kゥェァ構成を示すプロック図である。

図 18において、ハンドラ自動生成装置 500は、コンピュータによって制御されハンドラ自動生成部 510を実行する装置であって、 CPU (中央処理装置） 551と、メモリュニット 552と、表示ュニット 553と、入力ユエット 55 4と、記憶装置 556と、ドライパ、 557とで構成され、システムバス Bに接続される。

CPU551は、メモリユニット 552に格納されたプログラムに従ってハンドラ自動生成装置 500を制御する。メモリュ-ット 552は、 RAM及ぴ R O M等にて構成され、 CPU551にて実行されるプログラム、 CPU551での処理に必要な —タ、 C PU 551での処理にて得られたデータ等を格納する。また、メモリユニット 552の一部の領域が、 CPU551での処理に利用されるワークエリアとして割り付けられている。

表示ュニット 553は、 CPU551の制御のもとに必要な各種情報を表示する。入力ユニット 554は、マウス、キーボード等を有し、利用者がハンドラ自動生成装置 500が処理を行なうための必要な各種情報を入力するために用いられる。記憶装置 556は、例えば、ハードディスクユニットにて構成され、図 1 7に示すインターフェイス定義 521及びソースコード 531、ハンドラ処理部を生成するために必要なデータ等を格納する。

ハンドラ自動生成装置 500においてハンドラ自動生成部 510によって行われる自動生成処理を実現するプログラムは、例えば、 C D— R OM等の記憶媒体 558によってハンドラ自動生成装置 500に提洪される。即ち、プログラムが保存された記憶媒体 5 5 8がドライバ 5 5 7にセットされると、ドライノ 5 5 7 が記憶媒体 5 5 8からプログラムを読み出し、その読み出されたプログラムがシステムバス Bを介して記憶装置 5 5 6にインストールされる。そして、プログラムが起動されると、記憶装置 5 5 6にインストールされたプログラムに従って C P U 5 5 1がその処理を開合する。尚、プログラムを格納する媒体として C D— R OMに限定するものではなく、コンピュータが読み取可能な媒体であればよい。 ■

'パンドラ自動生成部 5 1 0によって実行されるハンドラ自動生成処理の全体について説明する。図 1 9は、ハンドラ自動生成処理の全体を説明するフローチヤート図である。図 1 9において、フアイノレ入力部 5 2 0によってインターフェイス定義ファイル 5 2 1を読み込み（ステップ S 5 0 1 )、. XML解析部 5 1 1が X MLによる記述を解析し要素木を生成する（ステップ S 5 0 2 )。

ハンドラ自動生成部 5 1 0は、解析が成功した力否かを判断する（ステップ S 5 0 3 )。解析が失敗した場贪、エラーを表示ュニット 5 5 3に表示し（ステップ S 5 0 4 )、ハンドラ生成処理を終了する。解析が成功した場合、タイプライブラリ生成部 5 1 2によってタイプライブラリが生成される（ステップ S 5 0 5 )。また、ハンドラソースコード生成部 5 1 3によって、ハンドラソースコードが生成され（ステップ S 5 0 6 )、ハンドラ生成処理を終了する。

タイプライブラリ生成部 5 1 2によるタイプライブラリ生成処理（ステップ S 5 0 5 ) について詳述する。図 2 0は、タイプライブラリ生成処理を説明するフローチャート図である。図 2 0において、タイプ要素解析部 5 1 5は、 XML解祈部 5 1 1から通知された要素木から types要素を探す（ステップ S 5 1 1 )。タイプ要素解析部 5 1 5は、 types要素が見つかったカゝ否かを判断する（ステップ S 5 1 2 )。具つからなかった場合、タイプライブラリ生成処理を終了する。一方、見つかった場合、空要素である力否かを判断する（ステップ S 5 1 3 )。空の要素である場合、タイプライブラリ生成処理を終了する。一方、空要素でない場合、外部ファイルのインポート力否かを判断する（ステップ S 5 1 4 )。つまり、図 1 7において、インターフェイス定義ファイル 5 2 2が型定義ファイル 5 2 3 をインポートしている力否かを判断する。外部ファイル（型定義ファイル 5 2 3 ) をインポ一トしていない場合、ステップ S 5 1 6へ進む。一方、外部フアイノレ（型定義ファイル 5 2 3 ) をインポートしている場合、スキーマ定義ファイル (型定義ファイル 5 2 3 ) を読み込む（ステップ S 5 1 5 )。

XMLスキーマ解析部 5 1 4は、インターフェイス定義ファイル 5 2 2の XM Lスキーマを解析し（ステップ S 5 1 6 )、ソースコードを生成する（ステップ S 5 1 7 )。そして、ファイル出力部 5 3 0によって、ヘッダファ'ィルとプログラムファイルとで構成されるタイプライブラリ 5 3 3として出力される。

ステップ S 5 1 7のソースコード生成処理について図 2 1から図 2 7で説明す 'る。先ず、' types要素において、列挙型でデータ型が定義されている場合について説明する。図 2 1は、ソースコード生成処理における列挙型定義生成処理を説明する図である。

図 2 1において、 XMLスキーマ 6 0 1は、列挙型でデータ型が定義される X MLによる記述例である。 1\1 スキーマ6 0 1は、タグ sinipleT^ peによる記述 6 0 2によって、「SomeVakieEnuni」という名前を持つ単純型のデータ型であることが定義される。更に、タグ restrictionによる記述 6 0 3によって、記述 6 0 4は、 baseで指定される「string」によって基底型が文字列であるように制限される。例えば、記述 6 0 4において、 enumerationタグによって文字列が「V ALUE1」、「VALUE2」、 rVALUE3j の 3つの値が列挙される。この場合、名前「SomeValueEnum」のデータ型は、 3つの文字列を持つことが定義される。 Cコード 7 0 1は、列挙型でデータ型を定義する XM Lスキーマ 6 0 1から生成された C言語のソースコードである。 Cコード 7 0 1において、記述 7 0 2は、記述 6 0 2に基づいて「一 SomeValueEnumJ が列挙型であることを定義し、記述 6 0 3及び記述 6 0 4に基づいて記述 7 0 4が生成される。「SomeValueEnu m_VALUEl」、 rSomeValueEnum_VALUE2j _N rSomeValueEnum_VALUE3j の 3つが列挙される記述 7 0 4によって、 3つの文字列を持つことが定義される。そして、記述 7 0 5は、「SomeVal ieEnum」力 S 「en m — SomeValueEiiiim」と同じデータ型を定義することを示す。

このように、 types要素で列挙型が記述されている XMLスキーマ 6 0 1から Cコード 7 0 1が生成される。次に、 types要素において、構造体でデータ型が定義されている場合について説明する。図 2 2は、ソースコード生成処理における構造体の型定義生成処理を説明する図である。

図 2 2において、 XMLスキーマ 6 1 1は、構造体でデータ型が定義される X MLによる記述例である。 XMLスキーマ 6 1 1は、タグ complexT pe による記述 6 1 2によって、「SomeStruct」という名前を持つ複合型のデ"タ型であることが定義される。タグ sequenceによる記述 6 1 3によって、データ順を規定する。タグ elementによる記述 6 1 4によって、構造体メンバー「strParam」が文字列であることが定義され、タグ elementによる記述 6 1 5によって、構造体メンバー「intParam」が整数であることが定義される。

Cコード 7 1 1は、構造体でデータ型を定義する XMLスキーマ 6 1 1から生成された C言語のソースコードである。 Cコード 7 1 1において、記述 7 1 2は、記述 6 1 2に基づいてし SomeStructJ が構造体であることを定義し、記述 6 1 4及び記述 6 1 5に基づいて記述 7 1 4による「char *strParam;」及び記述 7 1 5による「int intParam；」が生成される。そして、記述 7 1 5は、「SomeStr uct」力 S 「struct _SomeStruct」と同じデータ型を定義することを示す。

このように、 types要素で構造体が記述されている XMLスキマ 6 1 1から Cコード 7 1 1が生成される。

次に、 types要素において、配列でデータ型が定義されている場合について説明する。図 2 3は、ソースコード生成処理における配列の型定義生成処理を説明する図である。

図 2 3において、 XMLスキーマ 6 2 1は、配列でデータ型が定義される XM Lによる記述例である。 XMLスキーマ 6 2 1は、タグ complexTVpe による記述 6 2 2によって、「ArrayOfString」という名前を持つ複合型のデータ型であることが定義される。更に、タグ restrictionによる記述 6 2 4によって、 baseで指定される「soapEnc:Array」によって S OA P符号化に従つた配列であるように制限される。また、タグ sequenceによる記述 6 2 5によって、記述 6 2 6によるデータ順を規定する。タグ elementによる記述 6 2 6によって、「item」が文^^であり、省略可能であり、出現回数に上限のないことが定義される。タグ attributeによる記述 6 2 7は、「soapEnc:arra iVpe」が参照されて、その配列のタイプが「wsdl:arrayType="xs:string口：] によつて文字列の配列であるように属性を定義する。

Cコード 7 2 1は、配列でデータ型を定義する XMLスキーマ 6 2 1から生成された C言語のソースコードである。 Cコード 7 2 1において、記述 7 2 2は、記述 6 2 2に基づいてし ArrayOfStringJ が構造体であることを定義し、記述 6 2 6及び記述 6 2 7に基づいて記述 7 2 3及び記述 7 2 4による要素数を示す「i nt length;J 及ぴ記述 7 1 5による「char*」の配列のポインタであ'る「char ** array；」が生成される。そして、記述 7 2 5は、「AirayOfString」力「struct— A rrayOiStringJ と同じデータ型を定義することを示す。

types要素の simpleT^ype及び complexTVpeの定義に基づレ、て C言語の関数宣言を生成する例について図 2 4から図 2 6で説明する。図 2 4から図 2 6において、 C言語コード内の Document及び Elementは、 D OM(Document Object Model)によつて定義される型を C言語の構造体にマッビングしたものであるとする。また、図 2 4から図 2 6において、シリアライザ及びデシリアライザは、要素木と各型に対応した構造体データの変換を行う際に実行されるプログラムであって、シリアライザは構造体データを要素木に変換し、でシリアライザは要素木に構造体データに変換するプログラムである。また、コンストラクタ及びデストラクタは、構造体データを生成する際に実行されるプログラムであって、デストラクタは構造体データを解放するプログラムである。

図 2 4は、ソースコード生成処理における列挙型の関数宣言処理を説明する図である。図 2 4におレヽて、 Element *SomeValueEnum_serialize(Document * doc, char *tagName, SomeValueEnum value)；」で示されるシリアライザ 8 0 1は、 rSomeValueEnum value」によつて列挙値を入力として受け取って、「cha r *tagnamej によって tagnameをタク、名とする要素（Element) を生成して出力する。また、「SomeValueEnum Some ValueEnum_deserialize(Element *ele ment)；」で示されるデシリアライザ 8 1 1は、要素（Element) を入力として受け取って、これを解析して列 «を出力する。

シリアライザ 8 0 1及ぴデシリアライザ 8 1 1は、 XMLスキーマ 6 0 1より生成される。

図 2 5は、ソースコード生成処理における構造体の関数宣言処理を説明する図である。図 2 5におレヽて、「SomeStruct *SomeStruct_create(char *strParam, int intParam)；」で示されるコンストラクタ 8 2 1は、構造体メンバーの値を入力として受け取って、構造体を生成して出力する。「void SomeStruct_free(Som eStruct *st);j で示されるデストラクタ 8 3 1は、構造体を入力として受け取つて、 'その使用するメモリ領域を解放する。また、構造体メンバーの使用するメモリ領域も再帰的に解放する。「Element *SomeStruct_serialize(Document 中 doc， char *tagName, SomeStruct *st);J で示されるシリアライザ 8 4 1は、「Som eStruct *st」によつて構造体を入力として受け取つて、「cliar *tagnamejによつて tagnameをタグ名とする要素（Element) を生成して出力する。また、「Som eStruct *SomeStruct_deserialize(Element *element);」.で示さ..れるテシ 'リ'ァラ. ィザ 8 5 1は、要素（Element) を入力として受け取って、これを解析して構造体を生成して出力する。

従って、 XMLで記述された入力値を示す要素をデシリアライザ 8 5 1とコンストラクタ 8 2 1とを用いることによって、 W e bサービス機能が処理可能な構造体に入力値を設定することができる。また、 W e bサービス機能からの戻り値 (処理結果としての出力値）を、シリアライザ 8 4 1を用いることによって、 X MLで記述される要素に対応させて処結果を設定することができる。

コンストラクタ 8 2 1、デストラクタ 8 3 1、シリアライザ 8 4 1及びデシリァライザ 8 5 1は、 XMLスキーマ 6 1 1より生成される

図 2 6は、ソースコード生成処理における配列の関数宣言処理を説明する図である。図 2 6において、「ArrayOfString *ArrayOfString_create(int length, c har **array)；」で示されるコンストラクタ 8 6 1は、配列サイズと、配列を入力として受け取って、配列を保持する構造体を生成して出力する。「void ArrayOf String_free(ArrayOfString *st)；」で示されるデストラクタ 8 7 1は、配列を保持する構造体を入力として受け取って、その使用するメモリ領域を解放する。また、配列メンバーの使用するメモリ領域も再帰的に解放する。 HElement *Array OfString_serialize(Document *doc, char *tagName, ArrayOfString *st)；」で示されるシリアライザ 8 8 1は、「ArrayOiString *stjによつて配列を保持する構造体を入力として受け取つて、「char *tagnamej によって tagnameをタグ名とする要素（Element) を生成して出力する。また、「SomeStruct *SomeStruc t_deserialize(Element *element);Jで示されるデシリアライザ 8 9 1は、要素（E lement) を入力として受け取って、これを解析して配列を保持する構造体を生成して出力する。

従って、 XMLで記述された入力値を示す要素をデシリアライザ 8 9 1とコンストラクタ 8 6 1とを用いることによって、 W e bサービス機能が処理可能な配列に入力値を設定することができる。また、 W e bサービス機能からの戻り値 (処理結果としての出力値）をシ,リアライザ 8 8 1とを用いることによって、 XML で記述される要素に対応させて処理結果を設定することができる。.

コンストラクタ 8 6 1、デストラクタ 8 7 1、シリアライザ 8 8 1及ぴデシリァライザ 8 9 1は、' XMLスキーマ 6 2 1より生成される

このようにして生成された C言語の関数宣言は、タイプライブラリ 5 3 3のへッダファイルに出力される。また、各関数の処理はプログラムファイルに出力される。

次に、ハンドラ自動生成部 5 1 0によるハンドラ生成処理について図 2 7及ぴ図 2 8で詳述する。図 2 7及ぴ図 2 8は、ハンドラ生成処理を説明するフローチヤート図である。図 2 7において、ハンドラ自動生成部 5 1 0は、 service要素の name属性からサービス名を取得する. （ステップ S 5 2 1 )。そして、 service要素、 binding要素、 porttype要素の順に迪つて各要素を探す（ステップ S 5 2 2 )。 porttype要素の子の operation要素を探し、 name属性から操作名を取得する (ステップ S 5 2 3 )。 operation要素の子の input要素を探し、 name属性から入力メッセージ名を取得する（ステップ S 5 2 4 )。 operation要素の子の outpu t要素を探し、 name属性から出力メッセージ名を取得する（ステップ S 5 2 5 )。そして、ハンドラ処理部と W e サービス機能 (WS F) の関数宣言を生成する (ステップ S 5 2 6 )。

入力メッセージの message要素を探す（ステップ S 5 2 7 )。 message要素の子の part要素を探し、 name属性からパラメータ名、及ぴ、 types属性から型を取得する（ステップ S 5 2 8 )。そして、型を C言語の型にマッピングする（ステップ S 5 2 9 )。まだ part要素があるか否かを判断する（ステップ S 5 3 0 )。 p art要素がある場合、ステップ S 5 2 8へ戻り、上記処理を繰り返す。一方、 par t要素がない場合、入力メッセージの C言語の型へのマッピングを終了し、出力メッセージの C言語の型へのマッピングを行う。 ' 出カメッセージの message要素を採す（ステップ S 5 3 1 )。 message要素の子の part要素を探し、 name属性からパラメータ名、及ぴ、 typ 属性から型を取得する（ステップ S 5 3 2 )。そして、型を C言語の型にマッピングする（スデップ S 5 3 3 )。まだ part要素があるか否かを判断する（ステップ S 5 3 4 )。 p. art要素がある場合、ステップ S 5 3 2へ戻り、上記処理を繰り返す。一方、 par ' t要素がない場合、出力メッセージの C言語の型へのマッピングを終了する。

次に、入力メッセージの構造体定義を生成する（ステップ S 5 3 5 )。また、出. カメッセージの構造体定義を生成する（ステップ S 5 3 6、)。ハンドラ処理部のプログラムを生成する（ステップ S 5 3 7 )。入カメッセージの構造体定義及び出力メッセージを構造体定義をヘッダファイルに出力し、ハンドラ処理部のプロダラムをプログラムファイルに出力する（ステップ S 5 3 8 )。そして、まだ operati on要素があるカゝ否かを判断する（ステップ S 5 3 9 )。 operation要素がある場合、ステップ S 5 2 3へ戻り、上記同様の処理を繰り返す。 operation要素がない場合、ハンドラ生成処理を終了する。

ハンドラ自動生成部 5 1 0に入力されるインターフェイス定義ファイル（WS D L) の記述例について図 2 9及び図 3 0で説明する。図 2 9及び図 3 0は、 W S D Lによるインターフェイス定義の記述例を示す図である。図 2 9及び図 3 0 において、本来く ¾ype>タグによって記述されるデータ型の定義は、「foo.bar.com/ types.xsdjで特定される型定義ファイル 5 2 3によって定義されているものとする。この記述例において、メッセージを記述するためのデータ型を定義し、スキ一マの定義が設定されるく t pe>タグは省略され、その代わりに、記述 4 0によつて「foo.bar.com/types.xsd」力らインポートされる。

メッセージの書式を定義するく message>タグ 4 1 (記く message name="pri ntlnput">) によって定義される定義情報 4 2において、記述く part name="filel d" type="xs:unsignedInt"/>¾.O^?fB¾ <par name="count" type="xs:unsignedl nt"/>によって、印刷要求の入力パラメータ（printtnput) は、符号なし整数 (u nsignedlnt) の fileld及ぴ符号なし整数（unsignedlnt) の countによって構成されることを定義する。また、メッセージの書式を定義す 5<message>タグ 4 3 (記述く message name="printOutput">)によつて定義される定義情報 4 4におレヽて、言己述く part name="reques d". t pe- 'xs:unsignedlnt'7>こよって、卩 ΐ!]要求の出力パラメータ（printOutput) は、符号なし整数 (unsignedlnt) (D reque stldによって構成されることを定義する。- .

操作 (operation) の集合を定義するく porWy e>タグ 4 5 (記述く portT^ pe na me="netdocPortiype">) によつて定義される定義情報.4 6におレ、て、操作毎の入力メッセージ及び出力メッセージが定義される。例えば、く operation>タグ 4 7 (記述く operation name="print">)によって定義される定義情報 4 8において、記述 <input message="tns:printlnput7>によって入カメッセーンは printmput であること力 ^s定義され、また、記述く output message="tns:print0utput7>によつて出力メッセージは printOutputであることが定義される。この場合、印刷（p rint) のみが定義される。

<portType>タグ 4 5によって定義された操作とメッセージを具体的なプロトコルとデータフォーマツトにマップするく binding>タグ 4 9 (記述く binding na me="netdocHttpBinding" type=''tns:netdoc or Type''>) によって疋 '義される疋. 義情報 5 0において、 netdocPor TVpeで定義されるポートタイプについて、操作とメッセージのプロトコルとデータフォーマツトへのマップが定義される。定義情報 5 0において、く sb:binding>タグ 5 1 (記述く sb binding transport= "http://schemas.xmlsoap.org/soap/http" style="rpc"/> ) ίこよって、 S O A P H T T Pバインディングによる R P C (Remote Procedure Call) の使用が定義される。く operation>タグ 5 2 (記述く operation name="print">) によって、以下に印刷（print) に関する S O A Pメッセージが定義される。

先す、く sb:operation>タグ 5 3 (記述く sb:operation

r.com/netdoc print"/>) によって、印刷（print) 要求時の S O A P A c t i o n へッダの値が「http://foo.bar.com/netdoc/print」であることを定義する。次に、 <input>タグ 5 4によって定義される定義情報 5 5において、記述く sb: oody encoctmgStyle^littp /scliemas-xmlsoapOrg/soap/encoding/" use= "literal " namespace="littp：〃 foo.bar.com/netdoc/7>によって、入力 Bきのェンコ一ディング形式を定義し、 <output>タグ 5 6によって定義される定義情報 5 7において、 gd¾&<sb:body encodingStyle= nttp ://schemas .xmlsoap.org/soap/encoding/' . us e="literal" namespace=''http://foo.bar.com/netdoc/7>によって、出力時のェンコ一ディング形式を定義する。

そして、ネットワークの端点の集まりを定義するく 861^^6>タグ 5 8 (記述く se rvice name="netdoc">)によって定義される定義情報 5 9において、 <port>タグ 6 0 sd3∑!i<port name="netdocPort" binding="tns:netdocHttpBinding">) によってネットワークの端点の 1つとなる netdocPortが定義され、更に、記述 !)： address

よって、その不'ットヮ一クの端点のアドレス位置が定義される。つまり、サービス名「netdoc」のバイ. ンデイングは「netdocHttpBinding」であり、サービスの U R L (Uniform Res ource Locator;は「Jittp：〃 printer.foo.bar.com/netdoc」であること »定義される。このように W S D Lで定義されたインターフェイス定義ファイル 5 2 2及び方定義ファイル 5 2 3によって、データ型が決定され、操作が決定され、また、 U R L及び S O A P A c t i o nヘッダが決定される。

次に、図 2 9及び図 3 0に示すィンターフェィス定義が入力された場合のハンドラ処理部及 OW e bサービス機能の関数宣言と、入カメッセージ及ぴ出カメッセージの構造体定義について説明する。先ず、図 2 7のステップ S 5 2 6にて生成されるハンドラ処理部と W e bサービス機能の関数宣言について図 3 1及び図 3 2で説明する。

図 3 1は、ハンドラ処理部の関数宣言を説明する図である。図 3 1において、ハンドラ処理部の関数宣言は、例えば、サービス名を示す「netdoc」と操作名を示す「print」と、更にハンドラ処理部を示す rhandlerj による「netdoc_print _handlerj によって関数名とし、これをハンドラ処理部の関数として宣言する。この例では、「netdoc_print_liandler」によって、印刷操作を行うサービスに対応するハンドラ処理部を示す。ハンドラ処理部の関数宣言は、ハンドラソースコード 5 3 2のヘッダファイルに出力される。

図 3 2は、 W e bサービス機能の関数宣言を説明する図である。図 3 2において、 W e bサービス機能の関数宣言は、例えば、サービス名を示す rnetdocj と操作名を示す「print」とによる「netdoc_print」を関数名とし、；れを W e bサ一ビス機能の関数として宣言する。また、 W e bサービス機能の関数の引数は、サービス名を示す「Netdoc」と入力メッセ一ジ名を示す rprintlnputj とによる「Netdoc_printInput」によって入力メッセージの構造体を指定し、また、サービス名を示す rNetdocj と出力メッセージ名を示す rprintOutputJ とによる' ΓΝ etdoc_printOutputJ によって出力メッセージの構造体を指定する。 W e bサービス機能の関数宣言は、ハンドラソースコード 5 3 2のヘッダファイルに出力される。

図 2 8のステップ S 5 3 5にて生成される入カメッセージの構造体定義につレ、. て図 3 3で説明する。図 3 3は、入カメッセージの構造体定義を説明する図である。図 3 3において、入カメッセージの構造体は、例えば、サービス名を示す「n etdocj と入力メッセージ名を示す「printlnput」とによるし Netdoc_printInpu t」を構造体として定義する。また、構造体「_Netdoc_printInput」は、パラメ一タ型を「unsigned int」によって符号なし整数としてパラメータ名「fileld」と、パラメータ型を「unsigned int」によつて符号なし整数としてパラメータ名「co untj とで構成される。入力メッセージの構造体は、ハンドラソースコード 5 3 2のへッダファィルに出力される。

図 2 8のステップ S 5 3 6にて生成される出カメッセージの構造体定義について図 3 4で説明する。図 3 4は、出カメッセージの構造体定義を説明する図である。図 3 4において、出力メッセージの構造体は、例えば、サービス名を示す「n etdocj と出力メッセージ名を示す「printOutput」とによる「_Netdoc— printOu tputj を構造体として定義する。また、構造体「― Netdoc_j>rintOutput」は、パラメータ型を「unsigned int」によって符号なし整数としてパラメータ名「requ estldj で構成される。出カメッセージの構造体は、ハンドラソースコード 5 3 2 のヘッダファイルに出力される。

図 2 9及ぴ図 3 0に示すインターフェイス定義に基づいて自動生成されるハンドラソースコード 5 3 2のプログラムの例について図 3 5で説明する。図 3 5は、自動生成されたハンドラソースコードの例を示す図である。図 3 5において、実際のソースコードを記載する代わりに、ステップ毎の処理概要を記してある。図 3 5に示すようなハンドラソースコードでは、記述 9 0 1に示すように、図 3 1に示す宣言されたハンドラ処理部の関数名が最初に記述される。このハンドラ処理部は、 W e b'サービス機能としての印刷機能のためのハンドラである。以下、印刷ハンドラと言う。ステップ S 1 2 0から S 1 3 1までのコードは、要素木に基づいて処理リクエストを示す S OA Pエンベロープを解析するコードである。また、ステップ S 1 4 0から S 1 4 8までのコードは、処理レスポンスを示す S OA Pエンベロープを作成するための要素木を生成するたコードである。印刷ハンドラにて口一カルに定義される変数の記述の後、印刷ノヽンドラがルート要素を取得するためのステップ S 1 2 0が記載される。ステップ S 1 2 0が実行された結果として、ルート要素（E n v e 1 o _{P e}要素）を取得する。子ノードリストを取得するステップ S 1 2 1が記載される。ステップ S 1 2 1が実行された結果として、印刷ハンドラは要素木から「Header」及ぴ「Body」を取得することになる。

子ノードリストからタグ名が B o d yの要素を検索して取得するステツプ S 1 2 2が記述される。 B o d y要素の最初の子ノードを取得するステップ S 1 2 3 が記述される。ステップ S 1 2 3が実行された結果として、印刷ハンドラは操作名を示す p r i n t要素を取得する。 p r i n t要素の子ノードリストを取得するステップ S 1 2 4が記述される。取得した子ノドリストからタグ名を順に取得するステップ S 1 2 5 (繰り返しの判断をステップ S 1 3 2とする）が記述される。

タグ名が f i 1 e I Dである；^否かを判断するステップ S 1 2 6が記述される。タグ名が f i 1 e I Dである:^に、タグ名が f i 1 e I Dの最初の子ノードを取得するステップ S 1 2 7が記述される。ステップ S 1 2.7が実行された結果として、印刷ハンドラはテキストノードを取得する。取得したテキストノードからテキストデータを抽出して整数に変換するステップ S 1 2 8が記述される。ステップ S 1 2 8が実行された結果として、印刷ハンドラはファイル I Dパラメータとして値を所定の構造体に設定する。

タグ名が c o un tである力否かを判断するステップ S 129が記述される。タグ名が c o u n tである場合に、タグ名が c o u n tの最初の子ノ一ドを取得するステップ S 130が記述される。ステップ S 130が実行された結果として、印刷ハンドラはテキストノードを取得する。取得したテキストノードを抽出して整数に変換するステップ S 131が記述される。ステップ S 131が実行された結果として、印刷ハンドラは部数パラメ一として値を所定の構造体に設定する。上記ステップ S 126から S 131までの記述 902は、印刷ハンドラでの例であるが、他のハンドラでは、入力メッセージのパラメータ定義によってタグ名毎の判断及びタグ名に対する処理は変化する。

記述 902を実行した場合に取得した各パラメータの値を入カメッセージの構造体データとして生成し、データ名「in」に設定するステップ S 133が記述される。

入カメッセージの構造体データを引数とした図 32に示すような宣言された W e bサービス機能の関数「netdoc— print(in， out)」をコールするステップ S 13 4が記述される。

ステップ S 134が実行された場合に、戻り値がエラーであるかを判靳し、ェラーである場合、 SOAPFaultを responseDocumentに設定するステップ S 13 5が記述される。

以下ステップ S 140から S 148までは、 We bサービス機能の関数「netd oc_print(in, out)」の実行によってエラーでなかった場合に処理レスポンスを生成するための要素木を生成するステップが記述される。

Env e l o e要素を生成するステップ S 140が記述される。 B o d y要素を生成するステップ S 141が記述される。 B o d y要素を E n v e 1 o p e 要素に接続するステップ S 142が記述される。 p r i n t Re s p on s e要素を生成するステップ S 143が記述される。 p r i n tRe s p on s e要素を B o d y要素に接続するステップ S 144が記述される。 r e q u e s t I d 要素を生成するステップ S 145が記述される。 p r i n t Re s p on s e要素を B o d y要素に接続するステップ S 146が記述される。ステップ S 1 3 4が実行された結果として得られたリクエスト I Dを用いてテキストノードを生成するステップ S 1 4 7が記述される。テキストノードを r e q u e s t I d要素に接続するステップ S 1 4 8が記述される。

印刷ハンドラでの処理結果を示す responseDocument を戻り値とするステツプ S 1 4 9が記述される。

このよ-うにして記述されたハンドラソースコード 5 3' 2は、印刷ハンドラに限るものではなく、同様のステップを他の操作に対応させて生成することができる。従って、'上記ノヽンドラソースコードにおける操作名「print」は、定義によって変化する。 '

このように、ハンドラソースコード 5 3 2が自動生成されることによって、単純で同じようなコードを大量に生成することができるため、開発者による単純ミスによるバグが入り込むといった問題を解消することができる。また、短時間でハンドラソースコード 5 3 2を生成することができるため、開発者の負担を軽減することができる。更に、開発者は、 XMLによるメッセージのデータ形式と W e bサービス機能におけるプログラム言語にて処理可能なデータ形式との違いを意識することなく、 W e bサービス機能を開発することができる。

このようにハンドラ自動生成部 5 1 0によって、インターフェイス定義 5 2 1 に基づいて、各 W e bサービス機能の関数に対応させて自動生成されたハンドラソースコード 5 3 2及ぴタイプライブラリ 5 3 3は、 W e bサービス機能の関数他、必要な処理部を構成するソースコードと共に、コンパイルされる。

以上、第三実施例にて説明してきたように、本願発明によれば、機器間におけるメッセージ交換プロトコルに従ったメッセージのデータ形式の変換を行うためのプログラムが自動的に生成される。従って、開発者による単純ミスによるバグが入り込むといった問題を解消することができる。また、このように自動生成されたプログラムを画像形成装置に実装することによって、従来と同様の方法によつて開発された W e bサービスファンクションであっても、該メッセ^ ~ジの処理が可能となる。そのため、画像形成装置における W e bサービスファンクションの開発を容易に行うことができる。また、画像形成装置に接続可能な他システムとの連携を拡大することができる。本願発明に係るプログラム生成方法おいて、コンピュータが、 We bサービスのインターフェイスを定義するインターフェイス定義を解析し、該インターフエイス定義を構成する複数の要素間の関連を示す第一要素木を生成する要素木生成手順と、上記第一要素木に基づいて、上記 We bサービスを実行する We bサービス機能によつて処理可能な入出力データ形式と所定記述形式によつて記述される ^We bサービスに関する要求及び応答メッセージへの変換処理を行う変換プ口グラムを生成する変換プログラム生成手厦とを実行するように構成することができる。

また、上記変換プログラム生成手順は、上記 W e bサービス機能によつて処理可能な上記入出力データ形式と上記所; ¾|S述形式によつて記述される上記要求及ぴ応答メッセージにて設定される入出力メッセージとの変換を行うデータ型変換プログラム'を生成する第一プログラム生成手順と、上記所定記述形式によつて記述される上記要求メッセージを解析すると共に、上記応答メッセージを生成する第二プログラムを生成する第二プログラム生成手順とを有するように構成することができる。'

本発明に係るコンピュータ読み取り可能なプログラムが記憶された記憶媒体において、コンビユータに、 We bサービスのインターフェイスを定義するインタ一フェイス定義を解析し、該インターフェイス定義を構成する複数の要素間の関連を示す第一要素木を生成する要素木生成手順と、上記第一要素木に基づいて、上記 W e bサービスを実行する W e bサービス機能によつて処理可能な入出力データ形式と所定記述形式によつて記述される^ W e bサービスに関する要求及び応答メッセージへの変換処理を行う変換プログラムを生成する変換プログラム生成手順とを對亍させるためのコンピュータ読み取り可能なプログラムが記憶された記憶媒体。

また、上記変換プログラム生成手順は、上記 We bサービス機能によって処理可能な上記入出力データ形式と上記所^ 5述形式によつて記述される上記要求及び応答メッセージにて設定される入出力メッセージとの変換を行うデータ型変換プログラムを生成する第一プログラム生成手順と、上記所定記述形式によって記述される上記要求メッセージを解析すると共に、上記応答メッセージを生成する第二プログラムを生成する第二プログラム生成手順とを有することを特徴とする請求項 11記載の記憶媒体。

[第四実施例]

以下、第三実施例にて説明された自動生成されたハンドラ処理部が組み込まれた画像形成装置と ·しての融合機 1200の実施例について説明する。 '

第四実施例において、融合機 1200の機能構成及びハードウェア構成は、第 —実施例における機能構成及ぴノ、一ドウエア構成と同様であるため、 +その説明を' 省略する。

次に、融合機 1200において、 XML (extensible Markup Language) による S OAP (Simple Object Access Protocol)に従った We bサービスを » 可能とする構成について詳述する。 We bサービスファンクションは、例えば、 C言語などのプログラム言語で記述されたソフトウェア（アプリケーション）である。 SOAPに従って記述される XMLによる処理内容をメッセージとして W e bサービスファンクションが理解できるように、構文の異なる XMLとプログラム言語との間をハンドリングする処理部（ハンドラ）が必要となる。以下に、印刷する印刷 We bサービス、文書リストを取得する文書リスト取得 We bサービス、文書情報を取得する文書情報取得 We bサービスを例として、図 36で説明する。

図 36は、 We bサービス.を実現するための構成例を示す図である。図 37において、印刷 We bサービス、文書リスト取得 We bサービス、文書情報取得 W e bサービスが、 We bサー t:、、スアプリ 1218にて提供される^を示す。これら We bサービスは、アプリケーション 1230の別の機能として We サービスアプリ 1·218力ら独立した構成としても良レ、。図 36中、図 34に示す融合機 1200の機能構成のうち主要な機能構成のみが図示され、他の機能構成は省略される。

図 36において、 We bサービスを実現するために、コントロー^/サービス 1 250と We bサービスアプリ 1218との間に、接続される βとの間のデータの送受信制御する中間層が構成される。コントロールサービス 1250は、 We bサービスアプリ 1218による We bサービスを実現する構成部分として、 ECS 1224と、 MCS 1225と、 NCS 1228とを有する。 NCS 1228は、 HTT Pを制御する HTT Pデ一モン 2と、 HTTPデーモン 2と We bサービスアプリ 1218との接続処理の仲介をする要求仲介デーモン 7とを有する。

また、中間層 1255は、接続される βとの間のデータの送受信制御を吸収する構成部分として、シーケンス制御ライブラリ 100と、. XMLライブラリ 1 10と、 SOAPライブラリ 120と、ジョブ管理部 310と、ファイル管理部 311とを有する。シーケンス制御ライブラリ 100は、更に、 HTTP接続管理部 101と、 HTTPサービス実行部 102と、 POSTメソッド分酉 S処理咅 1り 5とを有する。 XMLライブラリ 110は、 XML処理部 115と、. XML プロセッサ 116と、 XMLシリアライザ 117とを有ずる。 SOAPライブラリ 120は、 SOAPアクション振分処理部 121を有する。

更に、 We bサービスアプリ 1218は、 We bサービスを実現するための構成部分として、要素未解析 ·生成ハンドラ 200と、 We bサービスファンクション（WS F) 300とを有する。要素木解析 ·生成ハンドラ 200は、騰間における SOAPに従ったメッセージのデータ形式による構文を解析し、 We b サービスファンクション 300にて処理可能なデータ形式に変換する処理部であつて、複数の要素木解析'生成ハンドラを有し、例えば、印刷ハンドラ 201と、文書リスト取得ハンドラ 202と、文書情報取得ハンドラ 203とを有する。ここで、印刷ハンドラ 201、文書リスト取得ハンドラ 202、文書情報取得ハンドラ 203の夫々は、第三実施例における図 17に示すハンドラ自動生成部 51 0によって自動生成されたソースコード 531のハンドラソースコード 532及びタイプライブラリ 533に基づくハンドラ処理部である。

We bサービスファンクション 300は、複数の We bサービスファンクションを有し、例えば、印刷機能 301と、文書リスト取得機能 302と、文書情報取能 303とを有する。この、印刷ハンドラ 201は、印刷機能 301 に対する処理の内容を示す S OAPに従ったメッセージのデータ形式を構文解析し、印刷機能 301が処理可能なデータ形式に変換して印刷機能 301に処理を要求する。また、印刷ハンドラ 201は、印刷機能 301からの応答を S OAP に従ったデータ形式にてメッセージとして生成する。文書リスト取得ハンドラ 2 02及ぴ文書情報取得ハンドラ 203は、夫々、文書リスト取得機能 302及び文書情報取得機能 303に対して同様の処理を行う。

印刷機能 301は、入力パラメータとしてファイル I Dと部数を受け取り、ジョブ管理部ファイル I Dと部数を指定して印刷要求をジョブ管理部 3.10に発行する。ジョブ管理部 310から受け取ったリクエスト I Dを出力パラメータとして返す。文書リスト取得機能 302は、ファイル管理部 311にファイルリス卞を要求し、ファイル管理部 311から受け取った IDのリストを出力パラメータとして返す。文書情報取觀能 303は、入力パラメータとしてファイル IDを受け取り、ファイル管理部 311にファイル IDを指定してファイル情報を要求する。ファイル管理部 311から受け取ったファイル情報を出力パラメータとして返す。

ジョブ管理部 310は、ジョブのキュー及び実行結果を管理する。また、 E C S 1224及び MC S 1125と通信して蓄積文書の印刷処理を亍する。ファィル管理部 311は、 MCS 1225と通信してファイル情報を取得する。

以下、 HTTPリクエストを受信してから HTTPレスポンスを送信するまでの処理について図 37及び図 38を参照しつつ説明する。図 37及び図 38は、 SOAPによる We bサービスの処理について説明するフローチヤ一ト図である。

NCS 1228の HTTPデーモン 2がネットワーク 15からの接続要求を受信する（ステップ S 1100) 。その接続要求は要求仲介デーモン 7を介して W e bサービスアプリ 1218の HTTP接続管理部 101に通知される。その後、 HTTP¾^ ¾¾101は、その接続要求を HTTPに従ってサービスを提供する HTTPサービス実行部 102に通知する。通知を受けた HTTPサービス実行部 102は、 HTTPデーモン 2に接続を行い、 HTTPリクエストを取得する。このような制御を NCS 1228で行うことにより、必要時のみ HTTP による通信制御をすることができる。よって、常時 HTTP通信制御をする場合に比べて、通信制御に必要な資源を効果的に利用することができる。 HTTPサービス実行部 102は、ネットワーク 15を介して受信した HTT Pリクエストからデータ送信方法を示す H T T Pメソッドを解析して、 G E Tメソッドである力否かをチェックする（ステップ S 1101) 。 GETメソッドである場合、 GETメソッドによる We bサービスの «を実行する（ステップ S 1102) 。つまり、 SOAPによる We bサービス以外の We bサービスの提供を行う。

一方、 GE.丁メソッドでない場合、 P O S Tメソッドであるか否かをチェックする（ステップ S 1103) 。 POSTメソッドでない場合、ステップ S 110 7へ進み、エラー処理を行い、 SOAPによる We bサービスの処理を終了する。 P O S Tメソッドである場合、 P O S Tメソッド分配処理部 105をコールする。 P O S Tメソッド分配処理部 105は、 HTT Pリクエストヘッダ情報を解析し、 HTTPボディの記迷形式が XMLであることを ¾mする（ステップ S 1104) 。つまり、 HTT Pレスポンスヘッダの Content-Typeが text/xml を指定している；^否かを判断する。 XMLでない場合、ステップ S 1107へ進み、エラー処理を行う。一方、 XMLである場合、 XMLコンテンツハンドラ 1 11をコーノレする。

1^乙処理部115は、 POSTメソッドハンドラとして、 XMLプロセッサ 116によって、 HTTPボディの XMLの構文を解析し、 XMLで記述されるタグ間の関連を木構造で示すリクエストの要素木を作成する（ステップ S 110 5) 。構文解析結果がエラー力、否かを判断する（ステップ S 1106) 。構文解析結果がエラーの場合、ステップ S 1107へ進み、エラー処理を行う。一方、構文解析結果が正常の場合、図 38のステップ S 1109へ進む。

SOAPァクション振分処理部 121は、 HTTPリクエストの SOAP Ac t i o nヘッダを解析して、 UR I (Uniform Resource Indicator) により異なる要素木解析'生成ハンドラ 200に HTTPリクエストを振り分ける（ステツプ S 1109) 。この場合、印刷 We bサービスを指定する UR Iに対して印刷ハンドラ 201、文書リスト取得 We bサービスを指定する UR Iに対して文書リスト取得ノヽンドラ 202、及ぴ、文書情報取得 W e bサービスを指定する U R Iに対して文書情報取得ハンドラ 203に、 HTT Pリクエスト及ぴ要素木とが振り分けられる。

各要素木 ·生成ハンドラ 200は、リクエストの要素木を解析して C言語の構造体データに変換する（ステップ S 1110) 。その後、変換した構造体データを引数として、 HTTPリクエストで指定される UR Iに対応する We bサ一ビスファンクション 300をコールする（ステップ S 1111) 。この場合、印刷ノヽンドラ 201は印刷機能 301、文書リスト取得ハンドラ 202は文書リスト取得機能 302、文書情報取得ハンドラ 203は文書情報取得機能 303をコールする。

We bサービスファンクション 3ひ 0は、所定の" We bサービスのロジックを実行して、構造体データとして結果を返す（ステップ S 1112) 。この場合、印刷機能 301、文書リスト取得機能 302、文書情報取得機能 303は、各 W e bサービスのロジックを実行して、その結果を返す。返される結果は、プログ' ラム言語で処理可能なデータ形式（例えば、 C言語の構造体）である。

各要素木解析 ·生成ハンドラ 200は、受け取った結果の構造体データからレスポンスの要素木を生成する（ステップ S 1113) 。各要素木解析■生成ハンドラ 200によって生成された要素木は、例えば、 XMLのタグ間の関係をタグからタグへのポインタによるリンクによって、そのデータ構造を示す。以後、 S

OAPァクション振分処理部 121を介して、 XMLシリアライザ 117によつて、レスポンスの要素木から XMLに変換される。 XMLシリアライザ 117は、要素木をテキストで示す XMLに変換する。変換された XMLは、 SOAPに従つた HTTPボディに構成され、所定の HTTPヘッダが付加された後、 HTT

Pレスポンスとして言される（ステップ S 1114) 。

上述より、要素木解析 ·生成ハンドラ 200が要素木を C言語の構造体に応じたデータ変換を行う。また、 C言語の構造体データから要素木への変換を行う。開発者は、 SOAP及び XMLの知識が無くても、 We bサビスをプログラム言語で開発することができる。

We bサービスファンクション 300を起動時の初期化処理では、モジュール間の（¾/線で示される）接続が行われ、図 36に示すように構成される。初期化処理では、 P O S Tメソッド分配処理部 105が P O S Tメソッドハンドラとしてシーケンス制御ライブラリ 100に接続することで開始され、 XML処理部 1 15の POSTメソッド分配処理部 105への登録、 SOAPアクション振分処理部 121の XML処理部 115への登録、要素木解析 ·生成ハンドラ 200の SOAPァクション振分処理部 121への登録が行われる。

次に、要素木解析 ·生成ハンドラ 200の印刷ノヽンドラ 201を例にして、印刷ハンドラ 201における要素木の解析処理について図 39、図 40及び図 41 で説明する。図 39は、 XMLを使用した SOAPに従った HTTPリクエストの記述例を示す図である。'図 40は、 XMLプロセッサによって変換された要素木の例を示す図である。図 41は、印刷ハンドラによる要素木解析処理を説明するためのフローチャート図である。

印刷 W e bサービスを依頼する図 39に示すような HTTPリクエストの場合、 XMLプロセッサ 112は、く SOAP-ENV:Envelope>で始まる HTTPボディ 2 0を要素木に変換する。タグ名 21 iEnvelopeJ をルート要素とし、ルート要素の芋ノードとしてタグ名 22 「Header」及ぴタグ名 23 「Body」を関連づける。更に、タグ名 23 「Body」の子ノードをタグ名 24 「print」とし、更に、タグ名 24 「print」の子ノードとしてタグ名 25 「fileld」及ぴタグ名 26 「count」とを関連付ける。そして、タグ名 25 rfileldj及びタグ名 26 「count」に、夫々、テキストデータ 27 「123」及びテキストデータ 28 「2」を関連付ける。このようにして関連付けられた要素木構造は、例えば、図 40に示されるようなデータ構造となる。図 40において、タグ名 21から 26及ぴテキストデータ 27 から 28を楕円で示し、関連付けが矢印で示される。

図 40に示すようなデータ構造となった要素木は、印刷ハンドラ 201によつて、図 41に示されるフローチャートに従って、印刷機能 301が処理可能なプログラム言語による構造体データが生成される。図 41でのステップ番号は、図 35でのステップ番号に対応する。図 41において、印刷ノヽンドラ 201は、ルート要素を取得する（ステップ S 120) 。この場合、ルート要素は、 Enve 1 o p e要素となる。子ノードリストを取得する（ステップ S 121)。つまり、タグ名 22 「Header」及び 23 HBodyJ を取得する。子ノードリストからタグ名が B o d yの要素を検索して取得する (ステップ S 122) 。 Bo dy要素の最初の子ノードを取得する（ステップ S 1 23) 。この場合、 r i n t要素を取得する。 p r i n t要素の子ノードリストを取得する（ステップ S 1 24)。取得した子ノードリストからタグ名を順に取得する（ステップ S 1 25 )。

タグ名が f i 1 e I Dである力否かを判断する（ステップ S 1 26)。タグ名が f i 1 e I Dでない場合、ステップ S 1 2 9へ進む。一方、タグ名が f i 1 e I Dである場合、タグ名が. f i 1 e I Dの最初の子ノードを取得する（ステップ S 1 27)。つまり、テキストノードを取得する。取得したテキストノードを抽出レて整数に変換する（ステップ S 1 28)。つまり、ファイル I Dパラメータとして、値「1 23」が所定の構造体に設定される。更に、タグ名が c o u n tであるか否かを判断する.（ステップ S 1 2 9)。タグ名が c o un tでない場合、ステツ:/ S 1 3 2へ進む。一方、タグ名が c o u n tである場合、タグ名が c o u n tの最初の子ノードを取得する'（ステップ S 1 30)。つまり、テキストノードを取得する。取得したテキストノードを抽出して整数に変換する（ステップ S 1 3 1)。つまり、部数パラメータとして、値「2」が所定の構造体に設定される。

印刷ハンドラ 20 1は、ステップ S 1 2 5で取得した子ノードリストから次の子ノードがある力否かを判断する（ステップ S 1 3 2) 。次の子ノードがある場合、ステップ S 1 2 5に戻り、次の子ノードを取得し、上記同様の処理を行う。次の子ノードがない場合、要素木の解析処理を終了する。

このようにして解析された要素木は、印刷ハンドラ 20 1によって図 42に示されるようなプログラム言語による構造体のパラメータに値が設定される。図 4 2は、 We bサービス機能の関数の引数の設定例を示す図である。図 42において、構造体 29 ( ["struct Netdoc一 printlnputj ) のノラメータ「 nsigned int ffleldj には、ステップ S 1 28によって、値「1 23J が設定される。また、パラメータ「unsigned int count」には、ステップ S 1 3 1によって、値「2」が設定される。

W e bサービスファンクション 300の印刷機能 30 1は、ハンドラ自動生成部 5 1 0によって We bサービス機能の関数として宣言された「netdoc一 printj 関数であるため（図 3 2参照）、「struct Netdoc_printInput *in」のようにして、ハンドラ自動生成部 5 1 0によって入カメッセージの構造体として定義された構造体 29の構造「struct Netdoc_printInput」とその構造体 29へのポインタ「in」が引数 30に設定される。印刷機能 301 ( rnetdoc_printj 関数）をコールすると、印刷機能 301での処理結果が、例えば、構造体名「struct N etdoc— printOutputJ へのホインタ「out」を示す「struct etdoc— printOutput *out」のような引数 31で戻る。

図 43は、印刷ハンドラでの処理結果の設定例を示す図である。図 43において、印刷ハンドラ 201は、引数 31のポインタ「out」によって、処理結果を設定すべき構造体 39を取得する。構造体 39は、ハンドラ自動生成部 510によ 'つて出カメッセージの構造体として定義された構造体である（図 34参照)。例えば、構造体 39において、処理結果として、パラメータ「unsigned int request Idj に値「100」を設定する。

次に、処結果を示す構造体 39から要素木を生成する要素木の生成処理について図 44及ぴ図 45で説明する。図 44でのステップ番号は、図 35でのステップ番号に対応する。図 44は、印刷ハンドラによる要素木生成処理を説明するためのフローチャート図である。図 45は、生成された要素木の例を示す図である。

図 45を照しつつ、印刷ハンドラによる要素木生成処理を説明する。図 44 において、印刷ハンドラ 201は、 Env e l o p e要素 32を生成する（ステップ S 140)。 B o dy要素 33を生成する（ステップ S 141)。そして、 o d y要素 33を En V e 1 o p e要素 32に接続する（ステップ S 142)。これらステップ S 140から S 142での処理によって、 SOAPに従った HTT Pレスポンスの HTTPボディが設定される。

そして、印刷ハンドラ 201は、 p r i n t R e s p o n s e要素 34を生成し（ステップ S 143), p r i n tRe s p o n s e要素 34を B o d y要素 3 3に接続する (ステップ S 144)。更に、 r e q u e s t I d要素 35を生成し

(ステップ S 145)、 r e que s t I d要素 35を p r i n tRe s p on s e要素 34に接続する（ステップ S I 46)。

印刷ノヽンドラ 201は、結果として得られたリクエスト IDよ,り、テキストノード 36を生成して (ステップ S 147)、テキストノードを r e a u e s t l d 要素 3 5に接続する（ステップ S 1 4 8 )。この場合、テキストノード 3 6には、「1 0 0」が設定される。

このように生成された要素木は、 XML処理部 1 1 5及ぴ XMLシリアライザ 1 1 2によって、図 4 6に示されるような HT T Pボディ 3 2を生成する。図 4 6は、要素木から変換された XMLを使用した S OA Pに従った HT T Pレスポンスの記述例を示す図である。図 4 6において、図 4 5に示す各要素 3 2から 3 6は、 < >で区切られるタグ内に記述され、所定の情報を S OA Pに従った手順で XMLにて記述される。融合機 1 2 0 0は、 HT T Pデーモン 2によって HT T Pリクエストを送信した機器へネットワーク 1 5を介じてこの HT T Pレスポンスを送信する。このようにして、融合機 1 2 0 0は、ネットワーク 1 5を介して接続される機器へ We bサービスを«する。

上記実施例より、 XMLによる要素間の関連を示す要素木から W e サービス機能が処理可能なプログラム言語による入力データに変換、及び、プログラム言語による出力データを所定記述形式の要素木に変換するソースコード 5 3 1が自動生成される。従って、単純で同じようなコードを大量に生成することができるため、開発者による単純ミスによるバグが入り込むといつた問題を解消することができる。また、短時間でハンドラソースコード 5 3 2を生成することができるため、開発者の負担を軽減することができる。

また、自動生成されたソースコード 5 3 1による要素木解析'生成ノヽンドラ 2 0 0を融合機 1 2 0 0に備えることによって、開発者はく従来と同様の開発方法、例えば、 C言語による開発方法によって、 We bサービスファンクションとしてのアプリケーションの開発を行うことができる。また、既に実装されているァプリケーションを容易に W e bサービスに対応するに改良することができる。

また、要素木解析 ·生成ハンドラ 2 0 0を有する融合機 1 2 0 0では、 S O A Pに従う XML記述されたメッセージをプログラム開発された W e bサービスフアンクション 3 0 0が解釈することができるため、 We bサービスファンクション 3 0 0を他システムにすることが可能となる。よって、融合機 1 2 0 0に接続されるシステム又はコンピュータ端末を限定しないため、融合機 1 2 0 0の利用可能性を大幅に拡大することが可能となる。以上、第四実施例にて説明してきたように、本願発明によれば、機器間におけるメッセージ交換プロトコルに従ったメッセージのデータ形式の変換を行う処理部を備えているため、従来と同様の方法によって開発された W e bサービスファンクシヨンであっても、該メッセージの処理が可能となる。そのため、画像形成装置における bサービスファンクションの開発をメッセジの記述形式に依存することなく容易に行うことができる。また、既に実装されているアプリケーシヨンを容易に W e bサービスに対応できるように改良することができる。更に、画像形成装置に接続可能な他システムとの連携を拡大することができる。

以上、本発明の好ましい実施例を説明したが、本発明はこれに限定されるわけではなく、本発明の要旨の範囲内で種々の変形及ぴ変更が可能である。

本発明に係る融合機 1 2 0 0は、複数の W e bサービス処理手段の夫々に対応させて、所定メッセージ交換プロトコルに従って受信した上記要求メッセージを上記 W e bサービス処理手段によって処理可能な処理要求に変換すると共に、該 W e bサービス処理手段から出力される上記処理結果を該メッセージ交換プロトコルに従った応答メッセージに変換する複数の変換手段を有するように構成することができる。

また、本発明に係る融合機 1 2 0 0において、要求メッセージ及び応答メッセーシ ίま、 Simple Object Access Protocol^こ従って Extensible Marmp Languag eによって記述されるように構成することができる。

更に、プログラム言語にて処理可能な第二データ形式及び W e bサービス処理手段によって出力された処理結果を示す第三データ形式は、 C言語によって処理可能な構造体を示すように構成することができる。

また、本発明に係る融合機 1 2 0 0は、所定通信プロトコルに従って通信を制御する通信制御手段と、接続管理手段へ、上記ネットワークを介して処理リクェストを受信したことを通知することによって'、上記通信制御手段と、上記所定通' 信プロトコルに従って、上記処理リクエストに基づいて上記 W e bサービス処理手段に処理を実行させ、その処理結果を処理レスポンスとして上器へ »する上記サービス «手段との接続を制御する接続制御手段とを有するように構成することができる。更に、上記所定通信プロトコノレは、 Hypertext Transfer Protocolであるように構成することができる。

また、本発明に係る融合機 1 2 0 0は、複数の上記 W e bサービス処理手段を有するアプリケーションと、上記画像形成処理で利用される複数のハードウエア資源を管理すると共に、上記アプリケーションからの利用要求に応じて、該複数のハードウエア資源への利用を制御するコントロールサービスと、該アプリケーションと該コント口一ルサービスとを制御するオペレーテイングシステムとを有するように構成することができる。，

本発明に係る虫合機 1 2 0 0は、上記要求メッセージを該要求メッセージの構成を示す第一データ形式に変換する第一メッセージ変換手順を有し、上記変換手 j噴は、上記第一データ形式を上記 W e bサービス処理手)噴を開発したプログラム言語にて処理可能な第二データ形式に対応させる第一データ形式変換手順を有するように構成することができる。

本発明に係る融合機 1 2 0 0にて行われる W e bサービス提供方法において、要求メッセージを該要求メッセージの構成を示す第一データ形式に変換する第一メッセージ変換手順は、上記要求メッセージから該要求メッセージを構成する要素とその要素に対して設定された値とに基づレ、て要素木を生成し、その要素木を上記第一データ形式とするように構成することができる。

また、このような W e bサービス提供方法において、上記第一データ形式変換手順は、上記要素木の上記要素間の関連を迪ることによって、上記 W e bサービス処理手順にて処理可能な上記第二データ形式の要素に値を設定するように構成することができる

更に、 W e bサービス提供方法において、上記所定のプログラム言語にて処理可能であって上記 W e bサービス手順による W e bサービスの処 3結果を示す第三データ形式を、該処理結果を示す応答メッセージの構成を示す第四データ形式に変換する第二データ形式変換手順と、上記第四データ形式によって示される上記応答メッセージの構成に基づいて、上記機器にて受信可能な記述形式にて該応答メッセージを記述する第二メッセージ変換手順とを有するように構成することができる。また、 W e bサービス提供方法において、上記第二データ形式変換手順は、上記第三データ形式の要素に上記処理結果として設定された値と上記応答メッセージを構成する複数の要素とに基づいて要素木を生成し、その要素木を上記第四データ形式とするように構成することができる。

以上、本発明の好ましい実施例を説明したが、本発明はこれに限定されるわけではなく、本発明の要旨の範囲内で種々の変形及び変更が可能である。

Claims

請求の範囲

1 . 画像形成に関する処理を実行するアプリケーションと、

夫々異なる通信プロトコルに従ってデータ送受信を行う複数の通信プロトコルァーモンと、

上記各通信プロトコルデーモンからの接続通知に応じて、該通信プロトコルデーモンに代わつて、該通信プ口トコルデーモンにて接続要求があったことを上記アプリケーションへ通知することによって接続を仲介する接続要求仲介手段とを有することを特徴とする画像形成装置。

2. 上記アプリケーションと上記通信プロトコルデーモンによって共有され、受信データ及び送信データを格納し、上記アプリケーションと該複数の通信プロトコルデーモンとの間で該受信データ及ぴ該送信データの受け渡しに使用される共有メモリとを有することを特徴とする請求項 1記載の画像形成装置。

3. 上記接続要求仲介手段は、

上記アプリケーションからの登録要求に応じて該アプリケーションを登録する登録手段と、

上記アプリケーシヨンから送受信バッファの登録要求に応じて、該アプリケーション専用に使用される受信用バッファ及び送信用バッファとを登録して使用可能状態とするバッファ登録手段とを有することを特徴とする請求項 1記載の画像形成装置。

4 . 上記接続要求仲介手段は、

上記各通信プロトコルデーモンからの接続通知を受けると、上記共有メモリ内に上記接続中にて使用される受信用バッファと送信用バッファとを割り当てて、上記通信プロトコ /レデーモンに通知する送受信バッファ割当手段を有することを特徴とする請求項 2又は 3のレ、ずれ力一項記載の画像形成装置。

5 . 上記アプリケーションは、

上記接続要求仲介手段から接続の通知を受信すると、該接続要求仲介手段に接続許可を通知すると共に、上記通信プロトコルデーモンに対して接続を行う接続処理手段と、上記通信プロトコルデーモンへデータ受信の開始を要求するデータ受信開始要求手段とを有することを特徴とする請求項 1乃至 4のいずれカゝ一項記載の画像形

6 . 上記各通信プロトコルデーモンは、

上記通信プロトコルデーモンが受信データを上記送受信バッファ割当手段によつて割り当てられた上記受信用パッファに書き込んで、書き込み開始位置をデ一' タ長分移動する受信データ書込手段と、

上記アプリケーションに；上記受信用バッファへ上記受信データを書き込んだことを通知すると共に、該受信データの書き込み開始位置と書き込み終了位置と' を指定する書き込み通知を行う受信書込通知手段とを有することを特徴とする請求項 4又は 5項記載の画像形成装置。

7. 上記アプリケーションは、

上記通信プロトコルデーモンから上記受信データの書き込み通知を受信すると、該書き込み通知で指定される上記書き込み開始位置から上記書き込み終了位置まで上記受信用バッファから上記受信データを読み出して、読み出し開台位置を該書き込み終了位置まで移動する受信データ読込手段と、

上記通信プロトコルデーモンに、上記受信用バッファから上記受信データを読み出したことを通知する受信読出通知手段とを有することを特徴とする請求項 6 記載の画像形成装置。

8 . 上記アプリケーションは、

上記パッファ登録手段によつて登録された上記送信用パッファへ送信データを書き込んで、書き込み開始位置をデータ長分移動する送信データ書き込み手段と、上記通信プロトコルデーモンに、上記言用バッファへ上記送信データを書き込んだことを通知すると共に、該送信データの書き込み開始位置と書き込み終了位置とを指定する書き込み通知を行う送信書込通知手段とを有することを特徴とする請求項 4乃至 7のいずれか一項記載の画像形成装置。

9 . 上記各通信プロトコルデーモンは、

上記アプリケーションから上記言データの書き込み通知を受信すると、該書き込み通知で指定される上記書き込み開始位置から上記書き込み終了位置まで上記送信用バッファから上記送信データを読み出して、上記アプリケーションと接続した上記通信プロトコルデーモンに該送信データを送信させる送信データ読出手段と、

上記読み出し開始位置を上記書き込み終了位置まで移動する読出開始位置移動手段と、

上記アブリケーシ 'ョンに、上記送信用パッファから上記送信データを読み出したことを通知する送信読出通知手段とを有することを特徴とする請求項 8記載の

1 0 . コンピュータが夫々異なる通信プロトコルに従ってデータ送受信を行う . 複数の通信プロトコルデーモンと複数のアプリケーションとの間で行われるデータ送受信を制御するデータ送受信制御方法にぉ、て、

上記上記各通信プロトコルデーモンからの接続通知に応じて、該通信プロトコノレデーモンに代わって、該通信プロトコルデーモンにて接続要求があったことを上記アプリケーションへ通知することによって接続を仲介する接続要求仲介手順と、

上記複数の通信プロトコルデーモンによって共有される共有メモリを介して上記アブリケーシヨンとの間で行われる受信データ及び送信データの受け渡しを制御するデータ送受信制御手順とを有することを特徴とするデータ送受信制御方法。

1 1 . メソッドに従つた所定の処理を行う複数のメソッド処理手段と、処理要求に応じて、該処理要求で指定される上記メソッドに対応する上記メソッド処理手段に該処理要求を振り分けることによって W e bサービスを実行する W e bサービス実行手段とを有することを特徴とする画像形成装置。

1 2. 同一メソッドにおける処理を共有し、上記 We bサービスとして画像形成に関する処理を行う複数の We bサービスアプリケーションを有することを特徴とする請求項 1 1記載の画像形成装置。

1 3 . 上記複数のメソッド処理手段の 1つである第一メソッド処理手段は、所定記述形式によって記述された上記処理要求のボディ部を処理する記述処理手段を有し、

上記記述処理手段による処理結果に基づレ、て、上記 W e bサービスアプリケーシヨンが実行されることを特徴とする請求項 1 1又は 1 2記載の画像形成装置。

1 4 . 上記複数のメソッド処理手段の 1つである第一メソッド処理手段は、上記第一メソッド処理手段を指定する上記第一メソッドに関して、上記処理要求のボディ部の記述形式を指定するへッダに応じた所定の処理を実行する複数の処理手段と、

上記処理要求に指定されるコンテンッタイプに対応する上記処理手段に該処理要求を分配する第一分配処理手段とを有し、

上記第一メソッドが上記処理要求によって指定されている場合、該処理要求が上記 W e bサービズ実行手段によって上記第一分配処理手段に振り分けられ、上記第一分配処理手段によって、上記処理要求が上記へッダに対応する上記処理手段に分配され、該処理手段による処理結果に基づいて、上記 W e bサービスアブリケーションが実行されることを特徴とする請求項 1 1又は 1 2記載の画像形成

1 5 . 上記複数のメソッド処理手段の 1つである第二メソッド処理手段は、 . 上記第二メソッド処理手段を指定する上記第二メソッドに関して、上記 W e b サービスアプリケーションを特定する特定情報に基づいて、上記処理要求を e bサービスアプリケーションに分配する第二分配処理手段を有し、

上記第二メソッドが上記処理要求によって指定されている場合、該処理要求が上記 W e bサービス実行手段によつて上記第二分配処理手段に振り分けられることを特徴とする請求項 1 1乃至 1 4のレ、ずれか一項記載の画像形成装置。

1 6 . W e bを介して通信制御を行う W e b通信プロトコルデーモンと、上記 W e b通信プロトコルデーモンとの接続によって生成され、 ^W e b通信プロトコルデーモンと上記 _{W e} bサービスアプリケーシヨンとの間で行われる所定記憶 S域からの受信データの読み込み及び該所定記憶領域への送信データの書き込みを制御する接続処理手段とを有することを特徴とする請求項 1 2乃至 1 5 の!/、ずれ力—項記載の画像形成装置。

1 7 . 接続通知をキューとして保持する接続通知キューと、

上記接続通知キューを用いて、上記 W e bサービス実行手段と上記 W e b,通信プロトコルデーモンとの接続を管理する W e b接続管理手段と、 ±fSW e b通信プロトコルデーモンから上記接続通知があったことを、上記 W e b通信プロトコルデーモンに代わって、上記 W e b接続管理手段へ通知することによって接続を仲介する接続要求仲介手段とを有し、

上記 W e b接続管理手段は、上記 W e bサービス実行手段からの接続要求に応じて、上記 W e bサービスアプリケーションに代わって、上記接続通知キューから上記接続通知を取り出して、記 W e 通信プロトコルデーモンと接続することを特徴とする請求項 1 6記載の画像形成装置。 .

1 8. 上記 W_e b接続管理手段は、上記 We b通信プロトコルデーモンと接続後、上記接続処理手段を生成し、上記 W e bサービス実行手段に上記接続に関する接続管理情報を通知し、

上記 W e bサービス実行手段は、上記通知を受けて、上記処理要求を該処理要求で指定されるメソッドに対応する上記メソ Vド処理手段に振り分けること'を特徴とする請求項 1 7記載の画像形成装置。

1 9 . 上記画像形成処理で利用される複数のハードウェア資源を管理すると共に、上記複数の W e bサービスアプリケーションからの利用要求に応じて、該複数のハードゥエァ資源への利用を制御するコント口一ルサービスと、

該複数の W e bサービスアプリケーションと該コント口一ルサービスとを制御するオペレーティングシステムとを有することを特徴とする請求: 2乃至 1 8 のいずれ力一項記載の画像形成装置。

2 0. コンピュータが、

メソッドに従つた所定の処理を行う複数のメソッド処理手順と、

処理要求に応じて、該処理要求で指定される上記メソッドに対応する上記メソッド処理手順に該処理要求を振り分けることによって W e bサービスを実行する W e bサービス実行手順とを有することを特徴とする画像形成方法。

2 1 . ネットワークを介して接続される; βからの要求メッセージに基づいて処理を^ ΐし、その処理結果を W e bサービスとして提供する W e bサービス処理手段と、

所定メッセージ交換プロトコルに従って受信した上記要求メッセージを上記 W e bサービス処理手段によつて処理可能な処理要求に変換すると共に、該 W e b サービス処理手段から出力される上記処理結果を該メッセージ交換プロトコルに従った応答メッセージに変換する変換手段とを有することを特徴とする画像形成

2 2. 上記要求メッセージを該要求メッセージの構成を示す第一データ形式に変換する第一メッセージ変換手段を有し、

上記変換手段は、上記第一データ形式を上記 We bサービス処理手段を開発したプログラム言語にて処理可能な第二データ形式に対応させる第一データ形式変換手段を有することを特徴とする請求項 2 1記載の画像形成装置。

2 3 . 上記第一メッセージ変換手段は、上記要求メッセージから該要求メッセ' ージを構成する要素とその要素に対して設定された値とに基づいて要素木を生成し、その要素木を上記第一データ形式とすることを特徴とする請求項 2 2記載の

2 4. 上記第一データ形式変換手段は、上記要素木の上記要素間の関連を迪ることによって、上記 W e bサービス処理手段にて処理可能な上記第二データ形式の要素に値を設定することを特徴とする請求項 2 3記載の画像形成装置。

2 5. 上記応答メッセージの構成に基づいて、上記機器にて受信可能な記述形式にて該応答メッセージを記述する第二メッセージ変換手段を有し、

上記変換手段は、上記 W e bサービス処理手段によつて出力された上記処理結果を示す第三データ形式を、該処結果を示す応答メッセージの構成を示す第四データ形式に変換する第二データ形式変換手段を有し、

上記応答メッセージは上記第四データ形式によって示されることを特徴とする請求項 2 4記載の画像形成装置 _b

2 6 . 上記第二データ形式変換手段は、上記第三データ形式の要素に上記処理結果として設定された値と上記応答メッセージを構成する複数の要素とに基づいて要素木を生成し、その要素木を上記第四データ形式とすることを特徴とする請求項 2 5記載の画像形成装置。

2 7. 所定通信プロトコルに従って受信した処理リクエストが上記要求メッセージによって処理要求を行うメソッドであるカゝ否かを判断するメソッド判断手段と、上記メソッド判断手段による判断結果に基づいて、上記処理リクエストを上記第一メッセージ変換手段へ分配する分配手段とを有することを特徴とする請求項 2 1乃至 2 6のいずれか一項記載の画像形成装置。

' 2 8 . 上記処理リクエストのヘッダ部を解析して W e bサービスを指定する W e bサービス指定情報を取得するヘッダ解析手段と、

上記ヘッダ解析手段による解析結果に基づいて、上記第一メッセージ変換手段によって変換された上記第一データ形式を引数として対応する上記複数の変換手段の 1つを関数コールすることによって、処理を振り分ける振り分け手段とを有ることを特徴とする請求項 2 7記載の画像形成装置。

2 9 . 上記処理リクエストのポディ部の上記所定記述形式による要素名を解析して W e bサービスを指定する W e bサービス指定情報を取得する W e bサービス指定情報取得手段と、

上記 W e bサービス指定情報取得手段による解析結果に基づいて、上記第一メッセージ変換手段によつて変換された上記第一データ形式を引数として対応する上記複数の変換手段の 1つを関数コールすることによって、処理を振り分ける振り分け手段とを有することを特徴とする請求項 2 7記載の画像形成装置。

3 0 . 上記所定通信プロトコルに従って、ネットワークを介して βとの接続を管理する接続管理手段と、

上記接続管理手段から上記接続の通知を受信後、上記所定通信プロトコルに従つて、上記処理リクエストに基づレ、て上記 W e bサービス処理手段に処理を実行させ、その処理結果を処理レスポンスとして上記機器へ «するサービス «手段とを有することを特徴とする請求項 2 7記載の画像形成装置。

3 1 . コンピュータが、

ネットワークを介して接続される機器からの要求メッセージに基づいて処理を実行し、その処理結果を W e bサービスとして^する W e bサービス処理手順と、

所定メッセージ交換プロトコルに従って受信した上記要求メッセージを上記 W e bサービス処理手順によつて処理可能な処理要求に変換すると共に、 w e サービス処理手順から出力される上記処理結果を該メッセージ交換プロトコノレに従った応答メッセージに変換する変換手順とを有することを特徴とする W e bサ一ビス方法。

3 2. コンピュータに、

We bサービスのインターフェイスを定義するインターフェイス定義を解析し、該インターフェイス定義を構成する複数の要素間の関連を示す第一要素木を生成する要素木生成手順と、

上記第一要素木に基づいて、上記 W e bサービスを実行する W e bサービス機能によって処理可能な入出力データ形式と所定記述形式によって記述される^ W e b:サービスに関する要求及び応答メッセージとの変換処理を行う変換プロダラムを生成する変換プログラム生成手順とを実行させるためのコンピュータ読み取り可能なプログラム。

3 3 . 上記変換プログラム生成手順は、

上記 W e bサービス機能によつて処理可能な上記入出力データ形式と上記所定記述形式によって記述される上記要求及び応答メッセージにて設定される入出力メッセージとの変換を行うデータ型変換プログラムを生成する第一プログラム生成手順と、

上記所定記述形式によって記述される上記要求メッセージを解析すると共に、上記応答メッセージを生成する第二プログラムを生成する第二プログラム生成手 J嗔とを有することを特徴とする請求項 3 2記載のプロ,グラム。

3 4. 上記第二プログラム生成手順は、

上記要求メッセージを構成する複数の要素間の関連を示す第二要素木の末端に設定される値を、上記 W e bサービス機能によって処理可能な入力データ形式に変換する第ニコードを生成する第ニコード生成手順と、

上記 We bサービス機能を関数コールする第三コードを生成する第三コード生成手順と、

上記応答メッセージを構成する複数の要素間の関連を示す第三要素木を生成すると共に、上記 We bサービス機能による戻り値を該第三要素木の末端に設定する第四コードを生成する第四コード生成手順とを有することを特徴とする請求項 3 2又は 3 3記載のプログラム。

3 5 . 上記第一要素木に基づいて、上記インターフェイス定義にて指定されるサービス名と操作名とによつて上記変換プログラム生成手順によって生成された上記変換プログラムを実行する第一関数の関数名を生成し、その関数名によって該第一関数を宣言する第一関数宣言手順と、

上記第一要素木に基づいて、上記ィンターフェイス定義にて指定されるサービス名と操作名とによつて上記 W e bサービス機能を実行する第二関数の関数名を生成し、該インターフェイス定義にて指定される該サービス名と入カメッセージ名及び出カメッセージとによって引数の型と引数名とを決定し、その関数名と引数名とによって該第二関数を宣言する第二関数宣言手順とを有することを特徴とする請求項 3 2乃至 3 4のいずれか一項記載のプログラム。

3 6 . 上記第一要素木に基づいて、上記インターフェイス定義にて指定される上記サービス名.と上記入カメッセージ名とによって入力データの構造を生成し、該インターフェイス定義にて指定されるパラメータ型と、パラメータ名とに ,よつて上記 W e bサービス機能によつて処理可能な入力データ構造体を構成して定義する第一構造体定義手 1嗔と、

上記第一要素木に基づレ、て、上記ィンターフェイス定義にて指定される上記サ一ビス名と上記出カメッセージ名とによって出力データの構造体名を生成し、該インターフェイス定義にて指定されるパラメータ型と、パラメータ名とによって上記 W e bサービス機能によつて処理可能な出力データ構造体を構成して定義する第二構造体定義手順とを有することを特徴とする請求項 3 5記載のプログラム

3 7. 上記第一要素木におけるデータ型の定義に基づいて、上記 W e bサービス機能によつて処理可能な型定義を生成する型定義生成手順と、

上記第二要素木における入力データが格納される要素を上記 W e bサービス機能によって処理可能な定義された型に変換するデータ型変換関数の宣言を生成するデータ型関数宣言生成手順とを有することを特徴とする請求項 3 4記載のプログラム。 .

3 8. 上記型定義に基づいて、上記 W e bサービス機能による上記出力デ、ータのデータ型を上記第三要素木における出力データが格納される要素に変換するデータ型変換関数の宣言を生成するデータ型関数宣言生成手順とを有することを特徴とする請求項 3 7記載のプログラム。

3 9 . 上記要素木生成手順は、 Extensible Markup Languageによって記述された上記ィンターフェイス定義を解析して上記第一要素木を生成することを特徴とする請求項 1記載のプログラム。

4 0 . 上記変換プログラム生成手順によって生成された上記変換プログラムは、画像形成処理を行うアプリケーションと上記画像形成処理によって利用されるハードウエア資源とを制御するオペレーティンダシステム上で実行可能であることを特徴とする請求項 1乃至 8のいずれカゝ一項記載のプログラム