JP4291856B2

JP4291856B2 - Ｗｅｂサービス機能を有する画像形成装置

Info

Publication number: JP4291856B2
Application number: JP2007003699A
Authority: JP
Inventors: 達雄伊藤
Original assignee: Ricoh Co Ltd
Current assignee: Ricoh Co Ltd
Priority date: 2002-03-25
Filing date: 2007-01-11
Publication date: 2009-07-08
Anticipated expiration: 2022-08-30
Also published as: JP2007135238A

Description

本発明は、利用者が使用するコンピュータ端末に、複数の画像形成機能を利用するために複数のドライバ・ソフトウェアをインストールすることなく、標準的なＷｅｂサービス対応ソフトウェアをインストールするだけでよく、また、該コンピュータ端末の機種又はオペレーティングシステムに依存することなく、Ｗｅｂサービスの提供を可能とし、他の機器からの処理要求も統一的に処理することが可能となる画像形成装置を提供するものである。

近年、プリンタ、コピー、ファクシミリ、スキャナなどの各装置の機能を１つの筐体内に収納した画像形成装置が一般的に知られている。このような複合型の画像形成装置は、１つの筐体内に表示部、印刷部および撮像部などを設けるとともに、プリンタ、コピーおよびファクシミリ装置にそれぞれ対応する３種類のアプリケーションを設け、アプリケーションの切り替えによって、当該装置をプリンタ、コピー、スキャナまたはファクシミリ装置として動作させるものである。

しかしながら、上記従来の複合型画像形成装置においては、ネットワークを介して接続される複数のＰＣ（パーソナルコンピュータ）からプリンタ、コピー、ファクシミリ、スキャナ等の機能を利用する場合、各ＰＣに各画像形成機能に応じたドライバ等のソフトウェアをインストールする必要があった。また、ＰＣにインストールされるそれらソフトウェアは、該ＰＣの機種及びオペレーティングシステムに対応したものでなければならない。また、同様な要求がサーバー等の機器との間でも要求されることがあるが、要求される処理のプロトコルや処理単位が異なるため、実装時には両方の要求を満たすようにする必要があった。更に、従来の利用形態では、ドライバによって決まった処理しか行うことができない等の制限があった。

そこで、本発明の課題は、利用者が使用するコンピュータ端末に複数の画像形成機能を利用するための複数のドライバ・ソフトウェアをインストールすることなく、該コンピュータ端末の機種又はオペレーティングシステムに依存することなく、画像形成装置の機能をネットワークを介してインターネット標準の各種Ｗｅｂプロトコルを利用してアクセス可能なプログラマブルなアプリケーションコンポーネントとして利用できる画像形成装置を提供することである。また、画像形成装置内又は画像形成装置と他装置間とにおいて、Ｗｅｂサービスが他Ｗｅｂサービスとやり取りする分散環境を実現する画像形成装置を提供する。

上記課題を解決するため、本発明は、スキャナとプロッタと記憶装置とを含む複数のハードウェア資源の１つ以上を利用して画像形成を行う画像形成装置であって、ネットワークを介して接続された機器からの処理リクエスト及び該機器への処理レスポンスの通信制御を行うネットワーク通信制御手段と、上記処理リクエスト内に所定メッセージ交換プロトコルに従って記述されたメッセージに含まれるＷｅｂサービスを特定する特定情報に対応するＷｅｂサービス関数をコールすることによって該メッセージに含まれる処理内容で上記ハードウェア資源の１つを制御し、該Ｗｅｂサービス関数の処理結果を示す上記所定メッセージ交換プロトコルに従った処理レスポンスを生成する手段であり、上記ハードウェア資源の夫々に対応させた複数のＷｅｂサービス提供処理手段と、上記処理リクエストに応じて２以上の上記Ｗｅｂサービス提供処理手段を複合して処理を行う複合Ｗｅｂサービス提供処理手段と、上記複数のＷｅｂサービス提供処理手段と上記複合Ｗｅｂサービス提供処理手段とによって共有される手段であり、上記所定メッセージ交換プロトコルに従って上記処理リクエストのヘッダ部を解析し、また上記処理レスポンスのヘッダ部を作成して、上記メッセージの交換を制御するプロトコル処理手段と、該処理リクエストのボディ部に記述される上記メッセージから処理内容を取得して上記画像形成装置を制御するための処理に関するデータ構成に変換し、また該処理の結果を該レスポンスのボディ部に所定記述形式で記述するメッセージ処理手段とを有するハンドラ手段とを有し、上記複数のハードウェア資源毎に上記Ｗｅｂサービス提供手段が備えられ、異なるＷｅｂサービスを指定する複数の処理リクエストによって上記複数のハードウェア資源に対する制御の組み合わせを可能とするように構成される。

このような画像形成装置では、ネットワークを介して接続された機器の機種又はオペレーティングシステムに依存することなく、Ｗｅｂサービスの提供を行うことができる。

上記所定メッセージ交換プロトコルは、例えば、ＳＯＡＰ（ＳｉｍｐｌｅＯｂｊｅｃｔＡｃｃｅｓｓＰｒｏｔｏｃｏｌ）である。

また、本発明は、上記画像処理装置での処理を行う画像形成方法とすることもできる。

本願発明によれば、利用者が使用するコンピュータ端末に複数の画像形成機能を利用するために複数のドライバ・ソフトウェアをインストールすることなく、標準的なＷｅｂサービス対応ソフトウェアをインストールするだけでよい。また、該コンピュータ端末の機種又はオペレーティングシステムに依存することなく、複数の画像形成機能を有する融合機への処理要求を行うこと可能となるだけでなく、他の機器からの処理要求も統一的に処理することが可能となる。

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

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

図１において、融合機１２００は、プロッタ１２０１と、スキャナ１２０２と、ファクシミリなどのハードウェアリソース１２０３などを有するとともに、プラットフォーム１２２０とアプリケーション１２３０とから構成されるソフトウェア群１２１０と、融合機起動部１２４０とを備えている。

融合機起動部１２４０は、融合機１２００の電源投入時に先ず始めに実行され、プラットフォーム１２２０やアプリケーション１２３０を起動する。

プラットフォーム１２２０は、アプリケーション１２３０からの処理要求を解釈して、ハードウェア資源の獲得要求を発生させる下記に示すコントロールサービス１２５０と、一または複数のハードウェア資源の管理をおこない、コントロールサービス１２５０からの獲得要求を調停するシステムリソースマネージャー（ＳＲＭ（System Resource Manager））１２２３）と、ＯＳ１２２１とを有する。

このコントロールサービス１２５０は、複数のサービスモジュールにより形成され、具体的には、ＳＣＳ（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 Daemon）によって、インターネットを介して接続されるネットワーク機器とのデータ通信をＨＴＴＰ（Hypertext Transfer Protocol）で制御し、ＨＴＴＰリクエストヘッダで指定されるＷｅｂサービスに対応する処理部を関数コールによって起動し、そのＷｅｂサービスによる処理結果をＨＴＴＰレスポンスで該ネットワーク機器へ通知するように構成しても良い。Ｗｅｂサービスは、例えば、ＸＭＬ（eXtensible Markup Language）によって記述されたメッセージに従って提供される。

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

アプリケーション１２３０は、ページ記述言語（ＰＤＬ）、ＰＣＬおよびポストスクリプト（ＰＳ）を有するプリンタ用のアプリケーションであるプリンタアプリ１２１１と、コピー用アプリケーションであるコピーアプリ１２１２と、ファクシミリ用アプリケーションであるファックスアプリ１２１３と、スキャナ用アプリケーションであるスキャナアプリ１２１４と、ＷｅｂサービスアプリケーションであるＷｅｂサービス処理アプリ１２１５と、工程検査用アプリケーションである工程検査アプリ１２１６とを有する。各アプリケーション１２１１〜１２１６は、プラットフォーム１２２０上の各プロセスを利用して動作実行し得るため、画面制御、キー操作制御およびジョブ生成などをおこなう画面表示制御プログラムがその主体となる。なお、ＮＣＳ１２２８により接続されたネットワークを介して新たなアプリケーションをネットワーク経由で搭載することもできる。また、各アプリケーションはアプリケーションごとに追加または削除することができる。

Ｗｅｂサービス処理アプリ１２１５は、ＳＯＡＰ（Simple Object Access Protocol）に従ってメッセージ交換を行うＳＯＡＰ処理部７０と、ＡＰＩ（Application Program Interface）を介してコントロールサービス１２５０を利用して所定処理を行い、その処理結果をＷＳ−ＡＰＩ（Web Service Application Program Interface）を介してＷｅｂサービスとして提供するＷｅｂサービスファンクション（ＷＳＦ）１４００とを有する。

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

次に、融合機１２００のハードウェア構成について説明する。図２は、図１に示す融合機１２００のハードウェア構成を示すブロック図である。図２に示すように、この融合機１２００は、オペレーションパネル１３１０、ＦＡＸコントロールユニット１５３０、ＵＳＢ（Universal Serial Bus）１３３０、ＩＥＥＥ１３９４１３４０およびエンジン部１３５０（プロッタ１２０１、スキャナ１２０２等が接続される）とコントローラ１３００のＡＳＩＣ１３０１とをＰＣＩ（Peripheral Component Interconnect）バス等で接続した構成となる。

コントローラ１３００は、ＡＳＩＣ１３０１にＭＥＭ−Ｃ１３０２、ＨＤＤ（Hard Disk Drive）１３０３などを接続するとともに、このＡＳＩＣ１３０１とＣＰＵ１３０４とをＣＰＵチップセットのＮＢ１３０５を介して接続している。このように、ＮＢ１３０５を介して接続する理由は、ＣＰＵ１３０４自体のインターフェースが公開されていないためである。

ここで、このＡＳＩＣ１３０１とＮＢ１３０５は、単にＰＣＩを介して接続されているのではなく、ＡＧＰ１３０８を介して接続されている。このようにＡＧＰ１３０８を介して接続することとした理由は、この融合機１２００が図１２に示したプラットフォーム１２２０やアプリケーション１２３０を形成する複数のプロセスを実行制御する関係上、これらを低速のＰＣＩで接続したのでは、パフォーマンスが低下するからである。

ＣＰＵ１３０４は、融合機１２００の全体制御をおこなうものであり、具体的には、ＯＳ１２２１上でプラットフォーム１２２０を形成するＳＣＳ１２２２、ＳＲＭ１２２３、ＥＣＳ１２２４、ＭＣＳ１２２５、ＯＣＳ１２２６、ＦＣＳ１２２７、ＮＣＳ１２２８をそれぞれプロセスとして起動して実行させるとともに、アプリケーション１２３０を形成するプリンタアプリ１２１１、コピーアプリ１２１２、ファックスアプリ１２１３、スキャナアプリ１２１４、Ｗｅｂサービス処理アプリ１２１５、工程検査アプリ１２１６を起動して実行させる。

ＮＢ１３０５は、ＣＰＵ１３０４とＭＥＭ−Ｐ１３０６、ＳＢ１３０７、ＡＳＩＣ１３０１とを接続するためのブリッジであり、ＭＥＭ−Ｐ１３０６は、融合機の描画用メモリなどとして用いるシステムメモリであり、ＳＢ１３０７は、ＮＢ１３０５とＲＯＭ、ＰＣＩデバイス、周辺デバイスとを接続するためのブリッジである。ＭＥＭ−Ｃ１３０２は、コピー用画像バッファ、符号バッファとして用いるローカルメモリであり、ＡＳＩＣ１３０１は、画像処理用のハードウェア要素を有する画像処理用途向けのＩＣである。

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

したがって、ＡＳＩＣ１３０１には、ＭＥＭ−Ｃ１３０２を接続するためのＲＡＭインターフェースと、ＨＤＤ１３０３を接続するためのハードディスクインターフェースが設けられ、これらの記憶部に対して画像データの入出力をおこなう場合には、入出力先がＲＡＭインターフェースまたはハードディスクインターフェースに切り替えられる。

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

以下、上述したような図１に示す機能構成、及び、図２に示すハードウェア構成を有する融合機１２００がＷｅｂサービスを提供するための機能構成例について説明する。ここで、Ｗｅｂサービスとは、ネットワーク機器からのＨＴＴＰリクエストによるサービス要求に応じて、融合機１２００が所定の処理を行ない、その処理結果をＨＴＴＰレスポンスとしてネットワーク機器へ提供することを言う。

先ず、ネットワークを介して、融合機１２００からＷｅｂサービスが提供される仕組みについて図３で説明する。図３は、Ｗｅｂサービスが提供されるネットワークの構成例を示す図である。図３中、Ｗｅｂサービスが提供される仕組みの概要を説明するため、詳細な機能構成の説明は省略される。

図３において、融合機１２００は、ネットワーク機器１０との通信制御を行うＷｅｂサーバー１１０１と、ネットワーク機器１０との間でＳＯＡＰに従ってＷｅｂサービスの要求及び応答のメッセージ交換を行うＳＯＡＰ処理部７０と、インターフェイス定義２１１に基づいて所定のＷｅｂサービスファンクション１４００を起動し、Ｗｅｂサービスファンクション１４００から応答を受け取るハンドラ１１０３と、Ｗｅｂサーバー１１０１によって起動され、処理を実行することによってＷｅｂサービスを提供するＷｅｂサービスファンクション（ＷＳＦ）１４００とを有する。ＳＯＡＰ処理部７０は、後述するような機能構成において、ハンドラ１１０３に含まれるようにしても良い。

インターフェイス定義２１１は、ＵＤＤＩサーバー１００へ登録されるＷｅｂサービスのサービス仕様を示すＷＳＤＬ（Web Service Description Language）であって、ハンドラ１１０３は、そのＷＳＤＬに記述されるＷｅｂサービス仕様を実現するものである。融合機１２００は、また、インターフェイス定義２１１に基づいてハンドラ１１０３を自動的に生成するハンドラ自動生成部２１０を有するように構成することができる。

ＵＤＤＩサーバー１００は、融合機１２００から融合機１２００が行うＷｅｂサービスのサービス仕様を示すＷＳＤＬを管理し、検索要求に応じて発見したＷＳＤＬを提供する機能を有し、融合機１２００とネットワーク機器１０との仲介を行うサービスブローカー１１０と、融合機１２００から登録されたＷＳＤＬを管理するＵＤＤＩレジストリ１１２とを有する。

サービスブローカー１１０によって、ネットワーク機器１０が所望するＷｅｂサービスが提供される場合について説明する。サービスブローカー１１０は、ネットワーク機器１０からのＷｅｂサービスの要求に応じて、その要求に対応するＷＳＤＬをＵＤＤＩレジストリ１１２から検索して、ＵＤＤＩレジストリ１１２にて発見したＷＳＤＬに記述されたＷｅｂサービス仕様に基づいて、ＳＯＡＰに従って、Ｗｅｂサービスの要求を示す要求メッセージを融合機１２００に対して送信する。融合機１２００のＷｅｂサーバー１１０１がＷｅｂサービスの要求を受信すると、ＳＯＡＰ処理部７０によって要求メッセージが処理され、ハンドラ１１０３はそのメッセージに応じた処理を行うＷｅｂサービスファンクション１４００を起動する。ハンドラ１１０３がＷｅｂサービスファンクション１４００から応答を受けると、ＳＯＡＰ処理部７０によってその応答はＳＯＡＰに従った応答メッセージとして処理され、Ｗｅｂサーバー１１０１によってサービスブローカー１１０へ送信される。

サービスブローカー１１０は、Ｗｅｂサーバー１１０１からＷｅｂサービスの応答を示す応答メッセージを受信すると、更に、その応答をネットワーク機器１０へ送信する。このように、ネットワーク機器１０と融合機１２００とを仲介するサービスブローカー１１０によって、ネットワーク機器１０は、ＷＳＤＬを取得することなく、融合機１２００に対してＷｅｂサービスを要求することができる。

また、ネットワーク機器１０が、ＵＤＤＩサーバー１００から所望のＷｅｂサービスに対応するＷＳＤＬを取得するようにしても良い。この場合、ネットワーク機器１０は、ＵＤＤＩサーバー１００に対して、所望のＷｅｂサービスに対応するＷＳＤＬを検索させて、ＵＤＤＩサーバー１００がＵＤＤＩレジストリにて発見したＷＳＤＬを取得する。そして、ネットワーク機器１０は、取得したＷＳＤＬによって記述されるＷｅｂサービスの仕様に基づいて、ＳＯＡＰに従って、Ｗｅｂサービスの要求を示す要求メッセージを融合機１２００に対して送信する。

融合機１２００のＷｅｂサーバー１１０１がＷｅｂサービスの要求を受信すると、ＳＯＡＰ処理部７０及びハンドラ１１０３によって上記同様の処理が行われた後、Ｗｅｂサービスの要求を示す要求メッセージに応じた処理を行うＷｅｂサービスファンクション（ＷＳＦ）１４００が起動される。そして、処理を実行したＷｅｂサービスファンクション（ＷＳＦ）１４００は、ハンドラ１１０３にその処理に対する応答を返す。ハンドラ１１０３及びＳＯＡＰ処理部７０での処理を経てＷｅｂサーバー１１０１が応答を受けると、ＳＯＡＰに従ったＷｅｂサービスの応答を示す応答メッセージをネットワーク機器１０へ送信する。このように、ネットワーク機器１０が、取得したＷＳＤＬに基づいて、ＳＯＡＰに従って所望のＷｅｂサービスを融合機１２００に要求するようにしても良い。

また、融合機１２００において、Ｗｅｂサービスファンクション（ＷＳＦ）１４００が、ＷＳＤＬによって記述可能な構成を有するようにしても良い。つまり、ＷＳＤＬに基づいたＷｅｂサービスの要求を処理可能とすると共に、ネットワーク機器１０と融合機１２００間における所定手順によるＷｅｂサービスの要求をも処理可能とする。

このＷｅｂサービスが提供されるネットワークの構成例において、メッセージ交換手順であるＳＯＡＰを利用した場合について説明するが、Ｗｅｂサービスを提供可能とするメッセージ交換手順は、ＳＯＡＰに限定されるものではなく、融合機１２００とネットワーク１０との間で取り決めた所定のメッセージ交換手順によって実現しても良い。

融合機１２００は、また、インターフェイス定義２１１に基づいてハンドラ１１０３を自動的に生成するハンドラ自動生成部２１０を有することによって、上記Ｗｅｂサービスファンクション（ＷＳＦ）１４００は、ＵＤＤＩサーバー１００に登録したＷｅｂサービスの仕様を記述するＷＳＤＬに基づいて、自動的に生成されるようにしても良い。この場合、新たに登録されたＷＳＤＬに基づいて、融合機１２００自身が、随時ハンドラ１１０３を動的に生成することが可能となる。例えば、ハンドラ１１０３の動作環境をＪａｖａ（登録商標）プログラムが動作可能な環境とすることで実現できる。また、ハンドラ自動生成部２１０を開発環境において利用し、その生成されたハンドラ１１０３のオブジェクトコードを融合機１２００に搭載するようにしても良い。この場合、ハンドラ１１０３を開発する工数を削減することができる。

ハンドラ１１０３を生成するハンドラ自動生成部２１０での自動生成処理について図４から図８で説明する。例えば、Ｗｅｂサービスファンクション１４００は、ファイル管理処理を行い、その結果を提供するＷｅｂサービスを提供するものとする。この場合、Ｗｅｂサービスファンクション１４００のためのインターフェイス定義２１１は、例えば、図４及び図５に示すように記述される。また、要求メッセージ及び応答メッセージは、ＸＭＬで記述されるものとする。

図４及び図５は、ＷＳＤＬによるインターフェイス定義の記述例を示す図である。図４において、データ型を定義する＜type＞タグ２４０は、メッセージを記述するためのデータタイプを定義し、スキーマの定義が設定される。この例の場合、＜/type＞のみ記述され、ＸＭＬのスキーマの基本型のみであることを示す。

メッセージの書式を定義する＜message＞タグ２４１（記述＜message name="filemanagementInput"＞）によって定義される定義情報２４２において、記述＜part name="fileId" type="xs:unsignedInt"/＞及び記述＜part name="operationCode" type="xs:unsignedInt"/＞によって、ファイル管理要求の入力パラメータ（filemanagementInput）は、符号なし整数（unsignedInt）のfileId及び符号なし整数（unsignedInt）のoperationCodeによって構成されることを定義する。また、メッセージの書式を定義する＜message＞タグ２４３（記述＜message name="filemanagementOnput"＞）によって定義される定義情報２４４において、記述＜part name="requestId" type="xs:unsignedInt"/＞によって、ファイル管理要求の出力パラメータ（filemanagementOnput）は、符号なし整数（unsignedInt）のrequestIdによって構成されることを定義する。

操作（operation）の集合を定義する＜portType＞タグ２４５（記述＜portType name="netdocPortType"＞）によって定義される定義情報２４６において、操作毎の入力メッセージ及び出力メッセージが定義される。例えば、＜operation＞タグ２４７（記述＜operation name="filemanagement"＞）によって定義される定義情報２４８において、記述＜input message="tns:filemanagementInput"/＞によって入力メッセージはfilemanagementInputであることが定義され、また、記述＜output message="tns:filemanagementOutput"/＞によって出力メッセージはfilemanagementOutputであることが定義される。この場合、ファイル管理（filemanagement）のみが定義される。

＜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="filemanagement"＞）によって、以下にファイル管理（filemanagement）に関するＳＯＡＰメッセージが定義される。

先ず、＜sb:operation＞タグ２５３（記述＜sb:operation soapAction="http://foo.bar.com/netdoc/filemanagement"/＞）によって、ファイル管理（filemanagement）要求時のＳＯＡＰＡｃｔｉｏｎヘッダの値が「
http://foo.bar.com/netdoc/filemanagement」であることを定義する。

次に、＜input＞タグ２５４によって定義される定義情報２５５において、記述＜sb:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" use="literal" namespace="http://foo.bar.com/netdoc/"/＞によって、入力時のエンコーディング形式を定義し、記述＜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_filemanagementInput」を定義するコードを生成する。宣言文として、例えば、「typedef struct _netdoc_filemanagementInput」のようなコードを生成し、続けて、図４の＜message＞タグ２４１によって定義される定義情報２４２に基づいて、図７に示すコード２６１を生成する。つまり、図４の定義情報２４２において、name="fileId"によって構成要素「fileId」が、type="unsignedInt"によって符号なし整数として、「unsigned int fileId;」のようなコードを生成する。また、name="operationCode"によって構成要素「operationCode」が、type="unsignedInt"によって符号なし整数として、「unsigned int operationCode;」のようなコードを生成する。そして、構造体「Netdoc_filemanagementInpput」にこの構造体定義「_nnetdoc_filemanagementInput」を適用するコードを生成する。コード２６１の生成によって入力用の構造体が定義される。

次に、ファイル管理関数３０１から出力される引数３１として使用される構造体「Netdoc_filemanagementOutput」を定義するコードを生成する。宣言文として、例えば、「typedef struct _netdoc_filemanagementOutput」のようなコードを生成し、続けて、図４の＜message＞タグ２４１によって定義される定義情報２４２に基づいて、図７に示すコード２６２を生成する。つまり、図４の定義情報２４４において、name="requestId"によって構成要素「requestId」が、type="unsignedInt"によって符号なし整数として、「unsigned int requestId;」のようなコードを生成する。そして、構造体「Netdoc_filemanagementOutput」にこの構造体定義「_netdoc_filemanagementOutput」を適用するコードを生成する。コード２６２の生成によって出力用の構造体が定義される。

ハンドラ自動生成部２１０は、ファイル管理関数３０１をコールするための関数宣言を生成する（ステップＳ１５１）。この場合、図４の＜operation＞タグ２４７によって定義される定義情報２４８に基づいて、例えば、ファイル管理関数３０１をコールするために、「SoapFault netdoc_filemanagement （Netdoc_filemanagementInput *in, Netdoc_filemanagementOutput *out）;」のようなコードを生成する。

ハンドラ自動生成部２１０は、ＳＯＡＰ処理部７０によって処理された要求メッセージをＸＭＬで記述する際のタグ間の関連をツリー構造で示すＤＯＭ（Document Object Model）ツリーに変換するコードを生成し（ステップＳ１５３）、Ｗｅｂサービスファンクション１４００をコールするコードを生成する（ステップＳ１５４）。つまり、ハンドラ自動生成部２１０は、ステップＳ１５１で生成した関数宣言のコードを使用してファイル管理関数３０１のコードを生成する。

続けて、ハンドラ自動生成部２１０は、Ｗｅｂサービスファンクション１４００からの処理結果がエラーであるか否かを判断するコードと、エラーの場合の処理を行なうコードを生成する（ステップＳ１５５）。更に、ハンドラ自動生成部２１０は、ＤＯＭツリーから応答メッセージへ変換するコードを生成する（ステップＳ１５６）。

このように、ハンドラ自動生成部２１０は、インターフェイス定義２１１に基づいて、ハンドラ１１０３を生成することができる。このような構成にすることによって、ハンドラ１１０３を実現するソースコードを自動生成することができるため、単純で繰り返しの多いＤＯＭプログラミングを作成する必要がない。従って、短期間で品質の高いソフトウェア開発を行うことができる。また、Ｗｅｂサービスファンクション１４００は、入出力ともにプログラミング言語で扱いやすい形式とすることができるため、開発者にＸＭＬ又はＨＴＴＰについての深い知識を必要としない。従って、開発者の教育に要するコストを削減することができる。更に、プロトコルの追加や変更が生じた際にも、インターフェイス定義２１１を変更するだけでハンドラ１１０３のソースコードを自動生成することができる。従って、高い保守性を実現することができる。

以下、Ｗｅｂサービスの提供を可能とする融合機１２００の機能構成例について、融合機１２００とネットワーク機器１０とで説明する。

先ず、メッセージ交換手順であるＳＯＡＰを利用せずにＸＭＬにて記述されたメッセージに基づいて、ネットワークを介して接続されるネットワーク機器に、Ｗｅｂサービスを提供する融合機１２００について説明する。図９は、Ｗｅｂサービスを提供する融合機の第一機能構成例を示す図である。図９において、図１に示す融合機１２００の機能構成のうち主要な機能構成のみが図示され、他の機能構成は省略される。

図９において、融合機１２００は、ＨＴＴＰに従った通信制御を行うと共に、内部のＷｅｂサービス提供処理部に処理を分配するＷｅｂサーバー５００と、複数のＷｅｂサービス提供処理部としてファイル管理Ｗｅｂサービス提供処理部４０及び他Ｗｅｂサービス提供処理部４９と、処理を振り分けるハンドラ１１０３と、スキャナ１２０２と、ＨＤＤ１３０３と、プロッタ１２０１と、オペレーションパネル１３１０と、ＦＡＸコントロールユニット１５３０等とを有する。Ｗｅｂサーバー５００は、ＨＴＴＰに従った通信制御を行うｈｔｔｐｄ２と、ＨＴＴＰリクエストに対応するＷｅｂサービス提供処理部へ処理を分配するディストリビューター（Distributor）３０とを有する。

ファイル管理Ｗｅｂサービス提供処理部４０は、例えば、Ｗｅｂサービスを実行するＷｅｂサービスファンクション１４００（図３）としてＨＤＤ１３０３への文書の蓄積等のファイル管理を制御するファイル管理実行部４００を有する。

ハンドラ１１０３は、図３に示すように、インターフェイス定期２１１によって提供される各Ｗｅｂサービス提供処理部４０及び４９のＷｅｂサービスファンクションを記述したＷＳＤＬに基づいて、ハンドラ自動生成部２１０によって生成された処理部であり、複数のＷｅｂサービス提供処理部４０及び４９とで共有されるＸＭＬ処理部５０と、ＸＭＬ処理部５０によって解析されたＷｅｂサービスの処理内容を示す処理メッセージに基づいてファイル管理実行部４００に振り分けるディスパッチャー（Dispatcher）６０とを有する。

なお、融合機１２００において、説明の便宜上、複数のＷｅｂサービス提供処理部として、ファイル管理Ｗｅｂサービス提供処理部４０と他Ｗｅｂサービス提供処理部４９のみが示されるが、更に多くのＷｅｂサービス提供処理部を有する構成とすることもできる。この場合、ハンドラ１１０３は、複数のＷｅｂサービス提供処理部の夫々の実行部に処理を振り分ける複数のディスパッチャー６０を備えるようにする。また、それら複数のＷｅｂサービス提供処理部によって、ハンドラ１１０３においてＸＭＬ処理部５０は共有される。

また、ネットワーク１５を介して融合機１２００と接続されるネットワーク機器１０は、キーボード又はマウス等の入力装置からの入力データを制御すると共に、モニタ９に表示させる出力データとを制御する入出力制御部１１と、融合機１２００に対するＷｅｂサービスの処理内容及び融合機１２００からのＷｅｂサービスの処理結果をＸＭＬによって処理するＸＭＬ処理部１３と、ＨＴＴＰに従ったリクエストの生成及びレスポンスを解析するリクエスト／レスポンス処理部１４とを有する。ここで、ＨＴＴＰリクエストはＨＴＴＰに従ったデータ通信によって、Ｗｅｂサービスを要求することを示し、ＨＴＴＰレスポンスは該Ｗｅｂサービスの処理結果を通知する応答を示す。また、この第一機能構成例では、ＨＴＴＰリクエスト及びＨＴＴＰレスポンスのボディ部はＸＭＬによって記述される例を示している。

このようなネットワーク機器１０を利用する利用者は、所望のＷｅｂサービスを融合機１２００へ要求するための画面から融合機１２００へ要求する（ステップＳ１）。利用者によるＷｅｂサービスの要求に応じて、入出力制御部１１は、リクエスト／レスポンス処理部１４へ要求データを通知する（ステップＳ２）。リクエスト／レスポンス処理部１４は、入出力制御部１１からの要求データに基づいてＨＴＴＰリクエストを生成し（ステップＳ３）、ＸＭＬ処理部１３が処理内容をＸＭＬによってＨＴＴＰリクエストのボディ部に記述すると、ＨＴＴＰリクエストがネットワーク１５を介して融合機１２００へ送信される（ステップＳ４）。

融合機１２００のＷｅｂサーバー５００は、ｈｔｔｐｄ２によってＨＴＴＰリクエストを受信すると、ディストリビューター３０によって、ＨＴＴＰリクエストのヘッダ部で指定されるＷｅｂサービス提供処理部へ受信したＨＴＴＰリクエストを分配する（ステップＳ５）。例えば、ＨＴＴＰリクエストのヘッダ部でファイル管理Ｗｅｂサービス提供処理部４０が指定されていた場合、ファイル管理Ｗｅｂサービス提供処理部４０がディストリビューター３０によって関数コールされる。

ファイル管理Ｗｅｂサービス提供処理部４０において、ハンドラ１１０３は、ＸＭＬ処理部５０によってＨＴＴＰリクエストのＸＭＬで記述されたボディ部から処理内容を取得し（ステップＳ６）、取得した処理内容をディスパッチャー６０に通知する（ステップＳ７）。ディスパッチャー６０は通知された処理内容に従って、Ｗｅｂサービスによる処理をファイル管理実行部４００に振り分ける（ステップＳ８）。ファイル管理実行部４００は、処理内容に従ってＨＤＤ１３０３に対して処理を実行し、その処理結果を取得する（ステップＳ９）。例えば、処理内容に指定される文書の追加、更新、又は削除等の処理を実行する。ファイル管理実行部４００は処理結果をＸＭＬ処理部５０へ通知する（ステップＳ１０）。ＸＭＬ処理部５０は、通知された処理結果をＸＭＬで記述したＨＴＴＰレスポンスのボディ部を生成する（ステップＳ１１）。そして、ファイル管理Ｗｅｂサービス提供処理部４０から通知を受けたＷｅｂサーバー５００は、ｈｔｔｐｄ２を介してＸＭＬで記述された処理結果をボディ部とするＨＴＴＰレスポンスをネットワーク機器１０に送信する。

ネットワーク機器１０にてＨＴＴＰレスポンスが受信されると、ＸＭＬ処理部１３は、ＨＴＴＰレスポンスのボディ部を解析して処理結果を取得し（ステップＳ１３）、リクエスト／レスポンス処理部１４は、その取得した処理結果をモニタ９に表示させる出力データとして入出力制御部１１に渡す（ステップＳ１４）。そして、入出力制御部１１は、受け取った出力データをモニタ９に表示させるように制御する（ステップＳ１５）。

上記第一機能構成例において、ネットワーク機器１０は、予め取り決めておいたＸＭＬによる記述形式に従ってＨＴＴＰリクエストのボディ部に処理内容を記述することによって、融合機１２００に対して遠隔地からＷｅｂサービスの要求を行うことができる。また、融合機１２００は、予め取り決めておいたＸＭＬによる記述形式に従ってＨＴＴＰレスポンスのボディ部に処理結果を記述することによって、遠隔地にあるネットワーク機器１０に対してＷｅｂサービスの提供を行うことが可能となる。融合機１２００は、ネットワーク１５を介して、複数のネットワーク機器１０に対して、Ｗｅｂサービスを提供することも可能である。

次に、ＳＯＡＰに従ってＷｅｂサービスを提供可能とする融合機１２００の機能構成例について説明する。以下、例示される各Ｗｅｂサービス提供処理部は、ＷＳＤＬによって記述されたサービス仕様に基づいて記述された処理（サービス）を実行する関数である。

以下、ＳＯＡＰを利用したＷｅｂサービスを提供する融合機１２００の機能構成例について説明する。図１０は、Ｗｅｂサービスを提供する融合機の第二機能構成例を示す図である。図１０中、図９と同一構成には同一符号を付し、その説明は省略する。また、処理フローも同様であるためその説明は省略する。図１０に示される第二機能構成例において、融合機１２００が、ファイル管理Ｗｅｂサービス提供処理部４０及び他Ｗｅｂサービス提供処理部４９等の複数のＷｅｂサービス提供処理部に対応するハンドラ１１０３において、複数のＷｅｂサービス提供処理部によって共有されるＳＯＡＰ処理部７０を有し、ＸＭＬ処理部５０とディスパッチャー６０とがＳＯＡＰ処理部７０に含まれる点において、上記第一機能構成例と異なった構成となっている。また、ネットワーク機器１０は、ＳＯＡＰに従って融合機１２００とメッセージ交換するためのＳＯＡＰ処理部１２を有し、ＸＭＬで記述されたメッセージを処理するＸＭＬ処理部１３がＳＯＡＰ処理部１２に含まれる点において、上記第一機能構成例と異なった構成となっている。

このような融合機１２００において、ＳＯＡＰ処理部７０は、ＨＴＴＰリクエストのヘッダ部を解析し、ディスパッチャー６０によって処理を振り分け、ＸＭＬ処理部５０によってＨＴＴＰリクエストのボディ部のＸＭＬで記述されたメッセージから処理内容を取得する。例えば、ディスパッチャー６０は、Ｗｅｂサービスによる処理をファイル管理実行部４００に振り分ける。その後、処理を実行したファイル管理実行部４００からその処理結果を受け取ったＳＯＡＰ処理部７０は、ＸＭＬ処理部５０によってＨＴＴＰレスポンスのボディ部にその処理結果をＸＭＬで記述し、ＳＯＡＰに従って、そのＨＴＴＰレスポンスをネットワーク機器１０に送信する。

上記第二機能構成例において、ディスパッチャー６０をＸＭＬ処理部５０に含むようにしても良い。

上記説明より、ＳＯＡＰが適用された融合機１２００及びネットワーク機器１０とにおいて、ネットワーク機器１０は、融合機１２００に対してＸＭＬを使ったＲＰＣ（Remote Procedure Call）を実現することができる。

融合機１２００とネットワーク機器１０との間でＳＯＡＰに従ってメッセージ交換するＨＴＴＰリクエスト及びＨＴＴＰレスポンスについて図１１で説明する。図１１は、ＨＴＴＰリクエスト及びＨＴＴＰレスポンスの例を示す図である。図１１（Ａ）は、ＨＴＴＰリクエストの例を示す図である。図１１（Ａ）に示すＨＴＴＰリクエストにおいて、ＵＲＩ（Uniform Resource Indicator）１６は、ＰＯＳＴメソッドによってＨＴＴＰリクエストが送信されるＵＲＩを示し、例えば、「ｎｅｔｄｏｃ」である。更に、ＳＯＡＰＡｃｔｉｏｎ１７でリクエストの目的を表すＵＲＩが示され、例えば、「http://foo.bar.com/netdoc/filemanagement」によって「ファイル管理」が指定される。

図１０の融合機１２００のｈｔｔｐｄ２のディストリビューター３０は、ＳＯＡＰＡｃｔｉｏｎ１７で指定される「filemanagement」により、ファイル管理Ｗｅｂサービス提供処理部４０を関数コールする。ファイル管理Ｗｅｂサービス提供処理部４０は、ＳＯＡＰ処理部７０によってＳＯＡＰに従ってＨＴＴＰリクエストを処理する。ＳＯＡＰ処理部７０において、ディスパッチャー６０は、ＳＯＡＰＡｃｔｉｏｎ１７で指定される「filemanagement」により、ファイル管理実行部４００に処理を振り分ける。また、ＸＭＬ処理部５０は、ＳＯＡＰエンベロープのボディ（＜SOAP-ENV:Body＞から＜/SOAP-ENV:Body＞まで）にＸＭＬによって記述されるメッセージ１８を解析する。例えば、メッセージ１８は、＜ns:filemanagement＞から＜/ns:filemanagement＞までに示される。「filemanagement」は、コマンドを示す。メッセージ１８によって要求される処理内容は、＜fileId＞から＜/fileId＞によって指定されるファイルＩＤ「１２３」を、＜operationCode＞から＜/operationCode＞によって指定されるオペレーションコード「３」の処理を行うことを示している。例えば、オペレーションコード「３」はファイル削除、オペレーションコード「１」はファイル追加、オペレーションコード「２」はファイル編集を要求する。

この場合、ディスパッチャー６０によって処理が振り分けられたファイル管理実行部４００は、ＸＭＬ処理部５０によって解析された処理内容に従って、ＨＤＤ１３０３からフィルＩＤ「１２３」の文書を削除する。

なお、上記例は、一つのコマンド「filemanagement」で、＜operationCode＞の設定によってファイルの管理方法を指定しているが、ファイル管理の処理を細分し、例えば、ファイル追加Ｗｅｂサービス、ファイル編集Ｗｅｂサービス、及び、ファイル削除Ｗｅｂサービス等のように複数のＷｅｂサービスをＷｅｂサービスファンクション１４００としてＷｅｂサービス処理アプリ１２１５に備えるようにしても良い。この場合、例えば、「fileadd」、「fileedit」、「filedelete」のように、Ｗｅｂサービス毎に一意に対応するコマンドがＸＭＬメッセージ１８に設定されるようにすることによって、＜operationCode＞によるオペレーションコードが不要となる。

図１１（Ｂ）は、ＨＴＴＰレスポンスの例を示す図である。図１１（Ｂ）に示すＨＴＴＰレスポンスは、ファイル管理Ｗｅｂサービス提供処理部４０のＳＯＡＰ処理部７０によって、ファイル管理Ｗｅｂサービス提供処理部４０の処理結果に基づいて作成される。図１１（Ｂ）に示すＨＴＴＰレスポンスにおいて、ＳＯＡＰ処理部７０は、ファイル管理Ｗｅｂサービス提供処理部４０の処理結果に基づいて、ステータスコード２０として「２００」と、説明句２１として「ＯＫ」を設定する。更に、ＸＭＬ処理部５０は、ＳＯＡＰエンベロープのボディ（＜SOAP-ENV:Body＞から＜/SOAP-ENV:Body＞まで）にＸＭＬによって記述されるメッセージ２２を生成する。コマンド「filemanagement」のレスポンスは、＜ns:filemanagementResponse＞から＜/ns:filemanagementResponse＞で示され、例えば、＜requestId＞と＜/requestId＞とのよってリクエストＩＤ「１０」が設定される。このＨＴＴＰレスポンスを受信したネットワーク機器１０は、ＸＭＬ処理部１３によるＸＭＬによって記述されたメッセージ２２を処理することによって、処理が正常に行われたことを確認する。

次に、ＳＯＡＰ処理部７０とＸＭＬ処理部５０とが個別に複数のＷｅｂサービス提供処理部によって共有される融合機１２００の機能構成について説明する。図１２は、Ｗｅｂサービスを提供する融合機の第三機能構成例を示す図である。図１２中、図１０と同一構成には同一符号を付し、その説明は省略する。また、処理フローも同様であるためその説明は省略する。図１２に示される第三機能構成例において、融合機１２００は、図１０に示される第二機能構成例と同様に、ファイル管理Ｗｅｂサービス提供処理部４０及び他Ｗｅｂサービス提供処理部４９等の複数のＷｅｂサービス提供処理部に対応するハンドラ１１０３において、複数のＷｅｂサービス提供処理部によって共有されるＳＯＡＰ処理部７０を有するが、ＸＭＬ処理部５０は、ＳＯＡＰ処理部７０とは独立して複数のＷｅｂサービス提供処理部によって共有される点が、上記第二機能構成例と異なっている。この第三機能構成例では、第二機能構成例と同様に、ディスパッチャー６０がＳＯＡＰ処理部７０に含まれる構成となっているが、ＸＭＬ処理部５０に含まれる構成としても良い。ネットワーク機器１０は、図１０に示されるネットワーク機器１０と同様の機能構成を有する。

融合機１２００は、複数の機能の夫々に対応させて複数のＷｅｂサービス提供処理部を有するように構成することができる。図１３は、Ｗｅｂサービスを提供する融合機の第四機能構成例を示す図である。図１３中、図１０と同一構成には同一符号を付し、その説明は省略する。図１２に示される第三機能構成例において、融合機１２００は、ＨＤＤ１３０３に蓄積された文書を管理するＷｅｂサービスを提供するファイル管理Ｗｅｂサービス提供処理部４０と、スキャナ１２０２を制御するＷｅｂサービスを提供するスキャナ制御Ｗｅｂサービス提供処理部４１と、プロッタ１２０１を制御するＷｅｂサービスを提供する印刷Ｗｅｂサービス提供処理部４２と、オペレーションパネル１３１０を制御するＷｅｂサービスを提供する操作部制御Ｗｅｂサービス提供処理部４３とを有する。また、ファイル管理Ｗｅｂサービス提供処理部４０はＨＤＤ１３０３に対して処理を実行するファイル管理実行部４００を有し、スキャナ制御Ｗｅｂサービス提供処理部４１はスキャナ１２０２に対して処理を実行するスキャナ制御実行部４０１を有し、印刷Ｗｅｂサービス提供処理部４２はプロッタ１２０１に対して処理を実行するプロッタ制御実行部４０２を有し、操作部制御Ｗｅｂサービス提供処理部４３はオペレーションパネル１３１０に対して処理を実行する操作部制御実行部４０３を有する。

更に、第三機能構成例と同様に、ハンドラ１１０３において、ＸＭＬ処理部５０とＳＯＡＰ処理部７０とは夫々独立して複数のＷｅｂサービス提供処理部４０〜４３によって共有される。また、ディスパッチャー６０〜６３が、複数のＷｅｂサービス提供処理部４０〜４３の夫々に対応するように構成される。

また、ネットワーク機器１０は、図１０に示されるネットワーク機器１０と同様の機能構成を有する。

このような第四機能構成例において、ＳＯＡＰが適用された融合機１２００及びネットワーク機器１０とにおいて、ネットワーク機器１０は、融合機１２００に対してＸＭＬを使ったＲＰＣ（Remote Procedure Call）を実現することができる。また、ネットワーク機器１０は、複数のＷｅｂサービス提供処理部４０〜４３を有する融合機１２００から所望のＷｅｂサービスに対応したＨＴＴＰリクエストを送信することによって、該所望のＷｅｂサービスの提供を受けることができる。従って、ネットワーク機器１０は、スキャナ１２０２、ＨＤＤ１３０３、プロッタ１２０１、オペレーションパネル１３１０等の画像形成装置の機能を利用するための複数のドライバをインストールすることなく、これらの機能をＷｅｂサービスとして利用することができる。

次に、ネットワーク機器１０の一回のＨＴＴＰリクエストに応じて、複数のＷｅｂサービス提供処理部を組み合せて実行する融合機１２００の機能構成例について説明する。図１４は、Ｗｅｂサービスを提供する融合機の第五機能構成例を示す図である。図１４中、図１２及び図１３と同一構成には同一符号を付し、その説明は省略する。図１４に示される第五機能構成例において、図１２に示す第三機能構成例と異なる点は、融合機１２００が、ファイル管理Ｗｅｂサービス提供処理部４０と、印刷Ｗｅｂサービス提供処理部４２とを有すると共に、ファイル管理Ｗｅｂサービス提供処理部４０と印刷Ｗｅｂサービス提供処理部４２とを組み合せて制御する複合Ｗｅｂサービス提供処理部９０を有し、ファイル管理Ｗｅｂサービス提供処理部４０と、印刷Ｗｅｂサービス提供処理部４２と、複合Ｗｅｂサービス提供処理部９０と、他Ｗｅｂサービス提供処理部４９とがハンドラ１１０３においてＸＭＬ処理部５０とＳＯＡＰ処理部７０とを共有するように構成される点である。更に、ＳＯＡＰ処理部７０は各実行部４００、４１２、８０等に処理を振り分けるディスパッチャー６０、６２、６８及び６９等を有する。

Ｗｅｂサービスファンクション１４００（図３）としてのファイル管理Ｗｅｂサービス提供処理部４０のファイル管理実行部４００は、ディスパッチャー６０によって振り分けられた処理に基づいて、ＨＤＤ１３０３へのファイル管理処理を実行すると共に、複合Ｗｅｂサービス実行部８０によって指定されるファイル管理処理を実行する。また、Ｗｅｂサービスファンクション１４００としての印刷Ｗｅｂサービス提供処理部４２のファイル印刷実行部４１２は、ディスパッチャー６２によって振り分けられた処理に基づいて、ファイルの印刷を実行すると共に、複合Ｗｅｂサービス実行部８０によって指定されるファイルの印刷を実行する。

複合Ｗｅｂサービス提供処理部９０は、ファイル管理Ｗｅｂサービス提供処理部４０と、印刷Ｗｅｂサービス提供処理部４２とを組み合せて実行する複合Ｗｅｂサービス実行部８０を有する。

図１４において、融合機１２００は、ネットワーク機器１０から、例えば、文書をＨＤＤ１３０３に蓄積して印刷する蓄積印刷を要求するＨＴＴＰリクエストを受信すると、複合Ｗｅｂサービス提供処理部９０は複合Ｗｅｂサービス実行部８０をコールし、ファイル管理実行部４００に文書をＨＤＤ１３０３に蓄積させ、続けて、蓄積した文書のファイルＩＤを指定することによってファイル印刷実行部４１２に印刷処理を実行させる一連の処理を行う。

このように、複合Ｗｅｂサービス実行部８０が、ファイル管理実行部４００とファイル印刷実行部４１２とに連続して処理を行わせることにより、ネットワーク１５を介して接続されるネットワーク機器１０は、一回のＨＴＴＰリクエストを送信するのみで、２つ以上のＷｅｂサービス提供処理部による一連のＷｅｂサービスの提供を受けることが可能となる。また、複合Ｗｅｂサービス実行部８０自身はファイルを管理する処理及び印刷処理を行うＷｅｂサービスファンクション１４００としての実体を備える必要がないため、開発効率を大幅に削減することができる。更に、ネットワーク機器１０は、ファイル管理Ｗｅｂサービス提供処理部４０のみによるＷｅｂサービスの提供、及び、印刷Ｗｅｂサービス提供処理部４２のみによるＷｅｂサービスの提供を要求することもできる。

このように、融合機１２００は、画像を形成すると共に、実際にＷｅｂサービスを提供するための処理を行う複数の実行部と、それらの組み合せによって、幅広いＷｅｂサービスを提供することができる。

上記第一〜第五機能構成例において、融合機１２００が一台のネットワーク機器１０へＷｅｂサービスを提供する構成について説明したが、複数のネットワーク機器１０とネットワーク１５を介して接続される場合には、各ネットワーク機器１０へ所望のＷｅｂサービスを提供することが可能である。

また、融合機１２００への処理内容をＸＭＬで記述することができ、また、メッセージ交換手順をＳＯＡＰとすることによって、ネットワーク機器１０の機種又はオペレーティングシステムに依存することなく、ネットワーク機器１０は、Ｗｅｂサービスの提供を受けることが可能となる。

更に、利用者は、使用するコンピュータ端末に複数の画像形成機能を利用するための複数のドライバ・ソフトウェアをインストールすることなく、画像形成装置の機能を、ネットワークを介してインターネット標準の各種Ｗｅｂプロトコルを利用してアクセス可能なプログラマブルなアプリケーションコンポーネントとして利用することができる。

また、融合機１２００内又は融合機１２００と他装置間とにおいて、Ｗｅｂサービスが他Ｗｅｂサービスとやり取りする分散環境を実現することができる。

上記実施例により、画像を形成する融合機１２００は、オペレーションパネルの制御、印刷処理、ファイル管理、スキャナ制御等、画像処理に関する種々の内部情報を処理し、その処理結果を要求元へ提供するＷｅｂサービスを実現することができる。ここで言う内部情報とは、画像情報、画像情報についてのステータス情報、及び、機器本体の設定を変更したりネットワークＩＰを変更したりする制御パラメータ等の情報等の画像処理及び融合機１２００に関する多種多様の情報を示しており、それら内部情報に対して所定処理を行い、その処理結果をＷｅｂサービスとして提供することは、上記実施例により実現可能である。

なお、上記実施例において、ｈｔｔｐｄ２は、ネットワーク通信制御手段に対応し、Ｗｅｂサービス提供処理部４０から４３、４９及び９０の夫々は、Ｗｅｂサービス提供処理手段に対応し、ファイル管理実行部４００、スキャナ制御実行部４０１、プロッタ制御実行部４０２及び操作部制御実行部４０３の夫々は、Ｗｅｂサービス実行手段に対応する。また、ＳＯＡＰ処理部７０は、プロトコル処理手段に対応し、ＸＭＬ処理部５０はメッセージ処理手段に対応する。

本発明の一実施例に係る多種の画像形成機能を融合する融合機の機能構成を示すブロック図である。図１に示す融合機１２００のハードウェア構成を示すブロック図である。Ｗｅｂサービスが提供されるネットワークの構成例を示す図である。ＷＳＤＬによるインターフェイス定義の記述例を示す図である。ＷＳＤＬによるインターフェイス定義の記述例を示す図である。ハンドラのソースコードを生成する自動生成処理を説明するためのフローチャート図である。生成された構造体定義のコードの例を示す図である。Ｗｅｂサービスファンクションをコールする関数の例を示す図である。Ｗｅｂサービスを提供する融合機の第一機能構成例を示す図である。Ｗｅｂサービスを提供する融合機の第二機能構成例を示す図である。ＨＴＴＰリクエスト及びＨＴＴＰレスポンスの例を示す図である。Ｗｅｂサービスを提供する融合機の第三機能構成例を示す図である。Ｗｅｂサービスを提供する融合機の第四機能構成例を示す図である。Ｗｅｂサービスを提供する融合機の第五機能構成例を示す図である。

符号の説明

２ｈｔｔｐｄ（Hypertext Transfer Protocol Daemon）
３０ディストリビューター
４０〜４９Ｗｅｂサービス提供処理部
５０ＸＭＬ処理部、６０ディスパッチャー
７０ＳＯＡＰ処理部
１２００融合機、
１２０１プロッタ１２０２スキャナ
１２１０ソフトウェア群
１２３０アプリケーション、１２２０プラットフォーム
１２２１ＯＳ、１２２２ＳＣＳ
１２２３ＳＲＭ、１２２４ＥＣＳ
１２２５ＭＣＳ、１２２６ＯＣＳ
１２２７ＦＣＳ、１２２８ＮＣＳ
１２２９ＩＭＨ、１２４０融合機起動部
１３００コントローラ、１３０１ＡＳＩＣ
１３０２ＭＥＭ−Ｃ、１３０３ＨＤＤ
１３０４ＣＰＵ、１３０５ＮＢ
１３０６ＭＥＭ−Ｐ、１３０７ＳＢ
１３０８ＡＧＰ、１３１０オペレーションパネル
１３３０ＵＳＢ、１３４０ＩＥＥＥ１３９４
１３５０エンジン部、１５００ネットワークＩ／Ｆ部
１５３０ＦＡＸコントロールユニット

Claims

スキャナとプロッタと記憶装置とを含む複数のハードウェア資源の１つ以上を利用して画像形成を行う画像形成装置であって、
ネットワークを介して接続された機器からの処理リクエスト及び該機器への処理レスポンスの通信制御を行うネットワーク通信制御手段と、
上記処理リクエスト内に所定メッセージ交換プロトコルに従って記述されたメッセージに含まれるＷｅｂサービスを特定する特定情報に対応するＷｅｂサービス関数をコールすることによって該メッセージに含まれる処理内容で上記ハードウェア資源の１つを制御し、該Ｗｅｂサービス関数の処理結果を示す上記所定メッセージ交換プロトコルに従った処理レスポンスを生成する手段であり、上記ハードウェア資源の夫々に対応させた複数のＷｅｂサービス提供処理手段と、
上記処理リクエストに応じて２以上の上記Ｗｅｂサービス提供処理手段を複合して処理を行う複合Ｗｅｂサービス提供処理手段と、
上記複数のＷｅｂサービス提供処理手段と上記複合Ｗｅｂサービス提供処理手段とによって共有される手段であり、上記所定メッセージ交換プロトコルに従って上記処理リクエストのヘッダ部を解析し、また上記処理レスポンスのヘッダ部を作成して、上記メッセージの交換を制御するプロトコル処理手段と、該処理リクエストのボディ部に記述される上記メッセージから処理内容を取得して上記画像形成装置を制御するための処理に関するデータ構成に変換し、また該処理の結果を該レスポンスのボディ部に所定記述形式で記述するメッセージ処理手段とを有するハンドラ手段とを有し、
上記複数のハードウェア資源毎に上記Ｗｅｂサービス提供手段が備えられ、異なるＷｅｂサービスを指定する複数の処理リクエストによって上記複数のハードウェア資源に対する制御の組み合わせを可能とすることを特徴とする画像形成装置。
上記ハンドラ手段は、上記メッセージを上記画像形成装置を制御するための処理に関するデータ構成に変換することを特徴とする請求項１記載の画像形成装置。
上記ハンドラ手段は、Ｗｅｂサービスの内容を記述する所定サービス記述言語によって記述された該Ｗｅｂサービスのプロトコル仕様に基づいて生成されたことを特徴とする請求項２記載の画像形成装置。
Ｗｅｂサービスの内容を記述する所定サービス記述言語によって記述された該Ｗｅｂサービスのプロトコル仕様に基づいて、上記ハンドラ手段を自動生成するハンドラ生成手段を有することを特徴とする請求項２記載の画像形成装置。
上記ハンドラ手段は、Ｗｅｂサービスの内容を記述する所定サービス記述言語によってＷｅｂサービスのプロトコル仕様として記述可能であることを特徴とする請求項２記載の画像形成装置。
上記ハンドラ手段は、上記複数のＷｅｂサービス提供処理手段によって共有可能であって、上記メッセージを処理するメッセージ処理手段とを有することを特徴とする請求項５記載の画像形成装置。
上記ネットワーク通信制御手段によって受信した上記処理リクエストのリクエスト種別を、上記所定メッセージ交換プロトコルに従って解析し、その解析結果に基づいて、上記複数のＷｅｂサービス提供処理手段の一つに上記処理リクエストを分配する分配手段を有することを特徴とする請求項１記載の画像形成装置。
上記ハンドラ手段は、上記処理リクエスト内のＷｅｂサービスを特定する上記特定情報を上記所定メッセージ交換プロトコルに従って解析し、その解析結果に基づいて、該特定情報によって特性される上記Ｗｅｂサービス関数に処理を振り分ける振分手段を有することを特徴とする請求項７記載の画像形成装置。
上記ハンドラ手段は、上記複数のＷｅｂサービス提供処理手段の夫々に対応させて複数の上記振分手段を有することを特徴とする請求項８記載の画像形成装置。
２以上の上記Ｗｅｂサービス提供処理手段を複合した複合Ｗｅｂサービス提供処理手段を有することを特徴とする請求項７記載の画像形成装置。
スキャナとプロッタと記憶装置とを含む複数のハードウェア資源の１つ以上を利用して画像形成を行う画像形成方法であって、
ネットワークを介して接続された機器からの処理リクエスト及び該機器への処理レスポンスの通信制御を行うネットワーク通信制御手順と、
上記処理リクエスト内に所定メッセージ交換プロトコルに従って記述されたメッセージに含まれるＷｅｂサービスを特定する特定情報に対応するＷｅｂサービス関数をコールすることによって該メッセージに含まれる処理内容によって上記ハードウェア資源の１つを制御し、該Ｗｅｂサービス関数の処理結果を示す上記所定メッセージ交換プロトコルに従った処理レスポンスを生成する手順であり、上記ハードウェア資源の夫々に対応させた複数のＷｅｂサービス手順と、
上記処理リクエストに応じて２以上の上記Ｗｅｂサービス提供処理手順を複合して処理を行う複合Ｗｅｂサービス提供処理手順と、
上記複数のＷｅｂサービス提供処理手順と上記複合Ｗｅｂサービス提供処理手順とによって共有される手順であり、上記所定メッセージ交換プロトコルに従って上記処理リクエストのヘッダ部を解析し、また上記処理レスポンスのヘッダ部を作成して、上記メッセージの交換を制御するプロトコル処理手順と、該処理リクエストのボディ部に記述される上記メッセージから処理内容を取得して上記画像形成装置を制御するための処理に関するデータ構成に変換し、また該処理の結果を該レスポンスのボディ部に所定記述形式で記述するメッセージ処理手順とを有するハンドラ手順とを有し、
上記複数のハードウェア資源毎に上記Ｗｅｂサービス提供手順が備えられ、異なるＷｅｂサービスを指定する複数の処理リクエストによって上記複数のハードウェア資源に対する制御の組み合わせを可能とすることを特徴とする画像形成方法。
コンピュータに請求項１記載の画像形成装置として機能させることを特徴とするコンピュータ実行可能なプログラム。