JP5014095B2 - 複合機 - Google Patents

Description

本発明は一般に複合機(MFP)に関し、特にウェブサービスアプリケーションのイベント処理仕様を統合すること、複数のスレッドと共にMFPでウェブサービスアプリケーションを実現すること、及び異なるタイプのSOAPリクエストを別々に処理することに関連する。

このセクションで説明されるアプローチは追跡可能なアプローチであるが、考察又は追跡が過去になされているアプローチであるとは限らない。従って、特に断りのない限り、このセクションで説明されるどのアプローチも、このセクションに含まれているという理由だけで従来技術とみなすべきではない。

「ウェブサービス」なる用語は、ネットワーキングプロトコル上でXML,SOAP及びWSDL規格を利用するウェブベースアプリケーションを統合する標準方式に関する。XMLはデータをタグ付けするのに使用され、SOAPはウェブサービスリクエストを如何にしてエンコードするかを指定し、XMLメッセージに応答するのに使用され、WSDLは利用可能なサービスを記述するのに使用される。プログラム可能なネットワーク化されたエンティティは、ウェブサービスを利用して、各自の実現手段のプラットフォームによらずに互いに通信する。多くのそのようなエンティティは業務用（ビジネス関連）なので、ウェブサービスは、ファイヤウォール背後の互いのITシステム各々についての深い知識なしに、ビジネスの通信ができるようにする。

ネットワークを介したプログラム可能なインターフェースにより、ウェブサービスはビジネスロジック、データ及びプロセスを共有する。時間のかかるカスタムコード処理なしに、ウェブサービスは様々なソースからの様々なアプリケーションが互いに通信でいるようにする。更に、全ての通信はXMLでなされるので、ウェブサービスはオペレーティングシステム又はプログラミング言語のどれにも拘束されない。例えば、ジャバ(Java(登録商標))はパイソン(Python)と通信可能であり、ウィンドウズ(登録商標)アプリケーションはユニックス(UNIX(登録商標))アプリケーションと通信可能である。

緩く結合されたシステムでトランザクション、信頼できるメッセージ処理及びセキュリティに関する相互運用可能なプロトコルをもたらすように、複数のウェブサービス仕様が共に構成される。ウェブサービス仕様は、（例えば、ワールドワイドウェブコンソーシアム(W3C)及び構造化情報標準促進協会(OASIS)により）承認済みの規格並びに規格になるかもしれない提案中のドキュメント及びドラフトの何れも含む。

ウェブサービス仕様を利用する複数のサービスを提供する１つの方法は、複合機(MFP)を利用することである。そのようなサービスは、印刷、複写、ファクシミリ、スキャン及びアーカイブ(記録)を含む。MFPで動作するウェブサービスアプリケーションにより、各サービスは提供される。各WSAはサービスを求めるSOAPリクエストを短時間の間に数百個受けるかもしれない。SOAPリクエストは処理する時間、サイズ及びタイプが異なり、MFPの様々なコンポーネントを必要とする。従って、複数のクライアントリクエストをできるだけ効率的に処理するWSAを１つ以上備えたMFPをもたらすことが望まれている。

本発明の課題は、複数のサービスが提供されるMFPでSOAPリクエストを効率的に処理する技法をもたらすことである。

本発明の一形態によれば、WSAはWSイベンティング−重要なウェブサービス仕様を実現するイベントマネジャを有し、そのウェブサービス仕様は、MFPで生成されるイベントにクライアントが如何にして予約するか、それを如何にして通知するかを規定する。WSイベンティング(WS-Eventing)の単一の実現手段をMFPの全てのWSAで共有する代わりに、１つ又はそれ以上のWSAが各自自身のイベントマネジャを有する。例えば、WSAは、クライアントアプリケーションからイベント予約リクエストを受信し、そのリクエストをWSAのイベントマネジャに転送する。イベントマネジャは予約識別子、予約終了時間、及び通知を受けるイベントシンクに関する情報を保守してもよい。イベントマネジャはMFPのプラットフォームから通知データを受信し、その通知データはイベントが発生したことを示す。イベントマネジャはその通知データを識別情報と比較し、そのクライアントアプリケーションについて通知メッセージを構成する。イベントマネジャは通知メッセージをイベントシンクに送信する。イベント予約応答がクライアントアプリケーションに送信される前に、あるWSAはイベント予約リクエスト中のデータを特別に処理する必要がある。WSAの中でWSイベンティングを実現することで、そのような特別な処理は、WSイベンティングの実現手段がMFPの全WSAの中で共有された場合に必要となるかもしれない量よりも大幅に少ない量で実行される。

本発明の一形態では、WSAは以下の少なくとも３つのスレッドを含む：外部リクエスト処理(ERP)スレッド、リクエスト処理(RP)スレッド及び内部通信(IC)スレッド。ERPスレッドはリクエストの受信を待機し、RP及びICスレッドのような１つ以上の他のスレットにディスパッチする。RPスレッドはWSAのビジネスロジックに従ってリクエストを処理する。ICスレッドはWSAとは異なるMFPのコンポーネントと通信を行う。このようにWSAは外部リクエストを受信する一方、他のリクエストを内部で処理し、MFP野コンポーネント間で内部通信を行う。

本発明の一形態では、異なるタイプのリクエストは別様に処理される。先ず、WSAは或る特定のSOAPリクエストをクライアントアプリケーションから受信し、そのリクエストを次の少なくとも２種類の内の１つに分類する：「ファースト(fast)」リクエスト又は「スロー(slow)」リクエスト。リクエストが「ファースト」なのか或いは「スロー」なのかの判断基準の１つは、クライアントアプリケーションに関連するコネクションがタイムアウトせずに、そのリクエストが比較的速やかに処理できるか否かである。別の基準は、リクエストの処理が、WSAにとっての何らかの外部リソースの利用が限られているという依存性を有するか否かである。そうであれば（依存性を有していれば）、そのリクエストはスローリクエストになる。

特定のリクエストがスローリクエストであった場合、その特定のリクエストに関連するコネクションのTCPウインドウは狭められてもよい（例えば、閉じられてもよい。）。特定のリクエストを処理するのに必要なリソースが利用可能になった場合、TCPウインドウは広げられる（例えば、開かれる。）。以後、WSAはその特定のリクエストに関連する全てのデータをバッファリングし、WSAは特定のリクエスト及び関連するデータを処理する。

特定のリクエストがファーストリクエストであった場合、その特定のリクエストに関連する全てのデータは、コネクションのTCPウインドウを狭めることなしにバッファリングされてもよい。そして特定のリクエスト及び如何なる関連データも処理される。ファーストリクエストはスローリクエストとは別個に処理されるので、リソースが利用可能になるのを「待機している」スローリクエストからの影響を受けずに、WSAはファーストリクエストを速やかに処理できる。

以下、本発明が添付図面と共に非限定的な実施例により説明され、図中同じ参照番号は同様な要素に関連する。

以下の記述の中では説明のため多くの具体的詳細が説明され、本発明の十分な理解を図る。しかしながら本発明はそのような具体的詳細とは別に実現されてもよいことは明白であろう。他方、発明を不必要に曖昧にすることを避けるため、周知の構造及び装置はブロック図形式で示される。

説明は次のような章立てでなされる。

１．０ アーキテクチャ概要
１．１ クライアント
１．２ ネットワーク
１．３ デバイスファシリティマネジャ
１．４ WSDマネジャ
１．４．１ 一般的API
１．４．２ 一般的API実現手段
１．５ ウェブサービスアプリケーション
１．５．１ アブストラクトAPI
１．５．２ アブストラクトAPI実現手段
２．０ ウェブサービスアプリケーションのマルチスレッド手段
２．１ 外部リクエスト処理スレッド
２．２ 内部通信スレッド
２．３ リクエスト処理スレッド
２．４ SOAPリクエストのマルチスレッド処理フロー
２．５ SOAPリクエストのマルチスレッド処理例
２．６ ウェブサービスアプリケーションのマルチスレッド手段の利点
２．７ スレッド数
３．０ ファーストリクエスト及びスローリクエストを別様に処理すること
３．１ ファーストリクエスト及びスローリクエストを処理するフローチャート
３．１．１ ファーストリクエスト処理スレッド
３．１．２ スローリクエスト処理スレッド
３．２ ファーストリクエスト及びスローリクエストを別様に処理する利点
４．０ WS-Eventingのウェブサービスアプリケーションへの統合
４．１ イベンティングシーケンス図
４．１．１ 前処理
４．１．２ 後処理
４．２ マルチスレッドイベント処理フローチャート
４．２．１ ファーストリクエスト処理スレッド
４．２．２ イベント処理スレッド
４．３ WS-Eventingをウェブサービスアプリケーションに統合する利点
５．０ 実現手段
以下、上記の各項目を説明する。

１．０ アーキテクチャ概要
図１は、SOAPリクエストを処理する本発明の一実施例によるアーキテクチャ例１００を示すブロック図である。アーキテクチャ１００は、クライアント１０２、アドミニストレータ１０４、デバイスファシリティマネジャ(DFM)１０６、MFPで動作する複数のウェブサービスアプリケーション(WSA)１０８を含む。

図１に示されるように、MFPは、複数のプラットフォーム（例えば、従来のプラットフォーム１３０、リナックスベースのプラットフォーム１４０及びVxWorksベースのプラットフォーム１５０）で構成され、各プラットフォームでWSA３０８の１つ以上が動作してもよい。図１に示されるプラットフォームは、単なる一例として与えられているに過ぎず、本方法は如何なるタイプのプラットフォームにも適用可能である。

クライアント１０２からのディスカバリリクエスト、メタデータリクエスト、及びアドミニストレータ１０４からのコンフィギュレーションその他のMFP管理リクエストに応答することによって、DFM１０６はMFPの代理を務める。WSディスカバリ１１２及びWS-MeX(即ち、WS-MetadataExchange)１１６のような複数のウェブサービス仕様を実現するリポジトリとしてDFM１０６は機能してもよい。

MFPで動作する各WSA１０８は、例えばSOAPプロトコルを利用して、サービスを要求するクライアント１０２にサービスを提供する。各WSA１０８は、ターゲットプラットフォームとは別に、アブストラクトAPI１２４のようなサービス固有のアブストラクトAPIを使用してもよい。各WSA１０８はWSイベント処理部(WS-Eventing)１２２を利用してもよい。

（同一ネットワーク上の装置にMFPを通知するブロードキャスト又はマルチキャストメッセージのような）ディスカバリリクエスト又はディスカバリハローメッセージを介して或るMFPが存在することを、クライアント１０２は発見してもよい。MFPの存在にクライアント１０２が気付くと、クライアント１０２はデバイスメタデータイクスチェンジリクエストを例えばWS-MetadataExchangeを介して送信し、そのMFPが提供する全てのサービスを見出す。装置全体を代行するDFM１０６は、そのリクエストを受信し、MFPにより提供される様々なサービスを記述するメタデータを返す。ウェブサービスアプリケーション(WSA)１０８のようなMFPで動作する特定のサービスアプリケーションからのサービスメタデータをクライアント１０２は要求する。WSA１０８はウェブサービスデバイス(WSD)マネジャ１１０からのサービスメタデータを要求し、ウェブサービスデバイスマネジャはサービスメタデータをWSA１０８に返す。WSA１０８はサービスメタデータをクライアント１０２に転送する。

或いは、MFPのデバイスメタデータ及び１つ以上のWSAのサービスメタデータが、同じレスポンスでクライアント１０２に送信されてもよい。

サービスメタデータに基づいて、WSA１０８により提供されるサービスに対応するSOAPリクエストをクライアント１０２は生成及び送信し、そのSOAPリクエストをWSA１０８は受信及び処理する。サービスリクエストに基づいて、WSA１０８はアブストラクトAPI１２４を利用して、アブストラクトAPI手段１４４のようなアブストラクトAPI手段１２４宛のプラットフォーム固有の呼出(call)を行う。このように、ウェブサービスアプリケーション（WSA１０８等）の開発者は、ウェブサービス自体の開発に集中でき、ウェブサービスが動作する基礎となるプラットフォームの構成を深く知らなくてよい。従って、ターゲッットプラットフォームの知識を備えたウェブサービスアプリケーション開発者以外の者が、対応するアブストラクトAPIの実現手段を規定してもよい。

１．１ クライアント
クライアント１０２は或るプロセスに関連するアプリケーションであり、それはMFPにより提供される１つ以上のサービスを要求する。クライアント１０２は典型的にはオペレーティングシステムに関連するアプリケーションであり、それは初期要求プロセスをサポートする。クライアント１０２の目的は、プラットフォーム固有のプロシジャコールを、リクエストプロセスからSOAPリクエストに変換することであり、SOAPリクエストはSOAPを「理解」するアプリケーションにより処理可能である。

例えば、リクエストプロセスはマイクロソフトアプリケーションに関連してもよいし、WSA１０８は印刷サービスを提供してもよい。クライアント１０２は、初期リクエストプロセスをサポートするオペレーティングシステムに関連するアプリケーションでもよい。クライアント１０２は、リクエストプロセスにより送信されたプラットフォーム固有の「印刷データ」リクエストを受信する。クライアント１０２はSOAPメッセージ中の印刷データリクエストをエンコードし、その印刷データリクエストはSOAPメッセージを「理解」するWSAにより処理可能である。

１．２ ネットワーク
クライアント１０２及びMFP間のSOAP通信は、（不図示の）ネットワークを介してなされてもよい。ネットワークは如何なる媒体で又は如何なる手段で実現されてもよく、ネットワーク中の様々なノード間でデータ通信機能をもたらす。そのようなネットワークの具体例は、ローカルエリアネットワーク(LAN)、広域ネットワーク(WAN)、イーサーネット、インターネット、１つ以上の地上、衛星又は無線リンク等のネットワークを含むがこれらに限定されない。ネットワークはこれら説明済みのネットワークの組み合わせを含んでもよい。ネットワークは、トランスミッションコントロールプロトコル(TCP)、ユーザデータグラムプロトコル(UDP)及び／又はインターネットプロトコル(IP)に従ってデータを伝送してもよい。

１．３ デバイスファシリティマネジャ
ディスカバリリクエスト、ロギング情報のリクエスト及びコンフィギュレーション命令のリクエストを受け入れることで、DFM１０６はMFPの代理を務める。一実施例によれば、DFM１０６は複数のウェブサービス仕様の実現手段に関するリポジトリとして機能してもよい。従ってDFM１０６は共有ライブラリルーチンを含み、各ルーチンは１つ以上のウェブサービス仕様（例えば、WSセキュリティ、WSメタデータイクスチェンジ）で規定される１つ以上の機能を実現する。こうして、複数のウェブサービス仕様は、一旦実現されると、MFPで動作する複数のウェブサービスアプリケーション（即ち、WSA１０８）どうしで共有される。その結果、ウェブサービスアプリケーションの開発者は、DFM１０６に実装される如何なる仕様についても多くの詳細を知る必要はなく、それらの仕様を当てにして使用することができる。DFM１０６に備わるウェブサービス仕様は、限定ではないが、WSディスカバリ１１２、WSトランスファ１１４、WS-MeX(即ち、WS-MetadataExchange)１１６及びWSセキュリティ１１８を含んでもよい。

一実施例ではDFM１０６は、SOAPプロトコルに対応するライブラリルーチンを含む。各SOAPライブラリルーチンは、１つ以上のSOAP仕様で規定される１つ以上の機能を実行する。SOAPライブラリルーチンは、SOAPリクエストを分析し、SOAPメッセージをパッケージ化するのに使用される。従って各WSA１０８は１つ以上のSOAPライブラリルーチンをDFM１０６から起動し、SOAPライブラリルーチンが一旦規定されるとMFPで動作する全てのWSA３０８の中でSOAPライブラリルーチンが共有されるようにする。SOAPプロトコル規格のいくつものバージョンがサポートされてもよい。SOAPプロトコル規格の新たなバージョンにアップデートすることは、WSA１０８に対するほんの僅かな修正と共に又は全く修正を伴わずになされる。

一実施例では、クライアントアプリケーション（例えば、クライアント１０２）は、MFPにおける１つ以上のWSAに対する更新に関する情報を受信するように登録してもよい。特定のアプリケーションの更新に関する更新情報をDFM１０６が受信し、クライアントアプリケーションがそのような更新を示すメッセージを受けるように登録されていたならば、その更新情報を示すメッセージをDFM１０６はクライアントアプリケーションに送信する。関連する実施例では、クライアントはそのような更新の通知を受けるように登録されなくてもよい。むしろ、DFM１０６は、更新を示すメッセージを１つ以上のWSAに自動的にブロードキャストするように構築されてもよい。

一実施例では、DFM１０６はWSAに関する更新情報を受信してもよい。例えば、WSA１０８はファックスサービスを提供し、ファクシミリ回線が切断されていることをMFPが検出するかもしれない。ファクシミリサービスが利用可能でなかった場合、DFM１０６は或るデバイスメタデータと共に以後メタデータリクエストに応答すべきでない（そのデバイスメタデータは、MFPがファクシミリサービスを提供することを示すものである。）。従って、WSAから更新情報を受けたことに応じて、DFM１０６は、WSAに関するサービスメタデータ及び／又は装置を更新する。

一実施例では、DFM１０６はアドミニストレータアプリケーション（例えば、アドミニストレータ１０４）からコンフィギュレーションリクエストを受信してもよい。コンフィギュレーションリクエストは、構築及び／又は更新されるべき１つ以上のWSAを示す。DFM１０６は、コンフィギュレーションリクエストを処理し、そのコンフィギュレーションを実行する又は実行されるように促し、或いは適切なWSAで命令を更新する。或いは、以下で詳細に説明されるように、DFM１０６はそのようなコンフィギュレーションリクエストを処理するようにWSDマネジャ１１０を指示してもよい。

一実施例では、DFM１０６は、アドミニストレータアプリケーション（例えば、アドミニストレータ１０４）からのログリクエストを受信してそれに応答する。DFM１０６は、MFPで動作する１つ以上のWSAに関するロギング情報を検索し、そのロギング情報をアドミニストレータ１０４に送信する。以下で詳細に説明されるように、WSDマネジャ１１０は、ロギング情報を検索し、それをDFM１０６に与える。

１．４ WSDマネジャ
一実施例によれば、DFM１０６はWSDマネジャ１１０も有する。WSDマネジャ１１０は、ロギング情報、ステータスの問い合わせ及び（アドミニストレータ１０４からのような）MFPの外部管理についてのセントラルポイント(central point)を提供する。アドミニストレータ１０４は或るアプリケーションであり、そのアプリケーションはWSDマネジャ１１０を介してMFPに関する情報を検索するように構成される。例えば、WSDマネジャ１１０は、全てのWSA１０８から及び様々なプラットフォーム（WSA１０８が動作しているプラットフォーム）から内部に集まるロギング情報全てを集めてもよい。アドミニストレータはWSDマネジャ１１０を用いてWSA１０８を構築してもよいし、更新してもよいし、或いはディセーブルにしてもよい。

一実施例では、WSDマネジャ１１０はステータス情報全体を保守し、ステータス情報は、例えばMFPが設けられる場所、如何なるWSAがMFPにインストールされるか、WSAが適切に動作しているか否か等を示す。

一実施例では、WSDマネジャ１１０は、MFPに関するメタデータと、MFPで動作している各サービスアプリケーションに関連するサービスメタデータとを保守する。

１．４．１ 一般的API
一実施例によれば、WSDマネジャ１１０はMFPに関する一般情報（IPアドレス及びMFPのモデル番号等）を一般的API(general API)１２０を介して検索する。一般的API１２０は或るインターフェースを規定し、そのインターフェースにより、DFM１０６はMFPの各プラットフォームに固有の情報を受信する。このようなわけでDFM開発者は、特定のプラットフォームの詳細を知る必要はなく、あるMFPについてその開発者が構築しようとするDFMの詳細だけを知っていればよい（図１における波線は、特定のAPIから適切なAPI手段へのAPI呼出(コール)である。）。

１．４．２ 一般的API実現手段
一般的API１２０がDFM１０６で規定されていた場合、特定のプラットフォームについて一般的API１２０の実現手段が規定される必要がある。例えば、一般的API実現手段１３２が、従来のプラットフォーム１３０上で一般的API１２０として規定される。同様に、一般的API実現手段１４２が、リナックスベースのプラットフォーム１４０上で一般的API１２０として規定される。対応する一般的API実現手段は、装置固有のリクエストで特定され且つMFPで実現される機能を決める。DFM１０６の開発者がその実現手段を決定してもよいし、或いはターゲットプラットフォームの知識を有するそれ以外の誰かが実現手段を決めてもよい。

１．５ ウェブサービスアプリケーション
ウェブサービスアプリケーション(WSA)１０８は或るモジュールであり、そのモジュールは、１つ以上のウェブサービスを提供し、DFM１０６で用意されるプロトコルのようなウェブサービスプロトコル及び技術を当てにしている。WSA１０８がSOAPリクエストを分析するロジックを含んでいなかったならば、WSA１０８はSOAPリクエストを分析するために別個のSOAPモジュール（不図示）を当てにしてもよい。上述したように、別個のSOAPモジュールが、DFM１０６によって用意され、全てのWSA１０８の中で共有されてもよい。

クライアント１０２からのイベントリクエストに応答するWSイベンティングモジュール１２２をWSA３０８は備えてもよい。クライアント１０２は、WSA１０８により提供されるサービスに関するイベントに予約してもよい。例えば、WSA１０８が印刷アプリケーションであり、クライアント３０２が予約するイベントは、WSA１０８に関連するMFPが印刷ジョブを完了したことでもよい。こうしてイベントが完了すると、印刷ジョブが完了していることを示すイベントメッセージを、WSA１０８はクライアント１０２に送信する。WSイベンティングをWSAに統合することについての更なる詳細は、後のセクションで与えられる。

１．５．１ アブストラクトAPI
WSA１０８はアブストラクトAPI(例えば、アブストラクトAPI３２４)を含んでもよく、そのAPIを介して装置固有のコールが生成される。アブストラクトAPI又は抽象的API(abstract API)は或るインターフェースを規定し、そのインターフェースによって、関連するWSA１０８はMFPの１つ以上の機能を起動する。従ってウェブサービスアプリケーションの開発者は、対象とするプラットフォームに潜む複雑な知識を知る必要はなく、その開発者が目的とする新たに提供するサービスだけ知っていればよい。

１．５．２ アブストラクトAPI実現手段
アブストラクトAPIがウェブサービスアプリケーション開発者により規定されている場合、ある特定のプラットフォームについてそのアブストラクトAPIの実現手段が規定される必要がある。例えば、VxWorksプラットフォーム１５０上でアブストラクトAPI１２４に関するアブストラクトAPI実現手段１５４が規定される。関連するアブストラクトAPI実現手段は、プラットフォーム固有のリクエストで指定され且つMFPに実装されている機能を規定する。ウェブサービスアプリケーションの開発者がその実現手段を規定してもよいし、或いはターゲットプラットフォームの知識を有するそれ以外の誰かが実現手段を規定してもよい。

２．０ ウェブサービスアプリケーションのマルチスレッド手段
MFPでWSAを実現するための１つの目標は、複数のクライアントからの複数のリクエストを仮想的に同時に処理することである。これを可能にする１つの方法は、複数のスレッドを引き起こして実行することで、少なくとも１つの特定の機能を実行することに各自専念させることである。

図２は、MFPのウェブサービスアプリケーションの中で実行してよいマルチスレッドを示す本発明の一実施例によるシーケンス図である。メインスレッド２０２と言及される或るスレッドは、メインスレッド２０２が属するWSA（関連WSAと言及される）が最初に実行する場合に生成される。例えば、MFPがシャットダウンの後に起動される場合や、関連WSAがMFPに追加されて動作し始めた場合に、メインスレッド２０２が生成されてもよい。スレッドがメモリリークを引き起こしたり、他の何らかの方法で動作不良になってしまうことに備えて、メインスレッド２０２は、関連WSAで動作する他のスレッドのステータスを周期的に検査する。メインスレッド２０２の目的の１つは、複数のクライアントアプリケーションからのSOAPリクエストを処理する他のスレッドを作成することである。以下、これらのスレッドのいくつかが詳細に説明される。

２．１ 外部リクエスト処理スレッド
そのようなスレッドの１つは外部リクエスト処理(EPR)スレッド２０４であり、LAN、WAN又はインターネットのようなネットワークから来るSOAPリクエストを受信する責務を負う。EPRスレッド２０４はSOAPリクエストを検査し、そのSOAPリクエストを他のどのスレッドが更に処理すべきかを確認する。この検査に基づいて、EPRスレッドは、関連WSAで同時に実行する１つ以上の他のスレッドにSOAPリクエストを送る。

２．２ 内部通信スレッド
他のスレッドは内部通信(IC: Internal Communications)スレッド２０６であり、関連WSAと異なるMFPの他のコンポーネント(要素)と通信する責務を負う。そのようなコンポーネントはDFM及び特定のプラットフォームを含んでもよい。一実施例では、関連WSAと異なるMFPの各コンポーネントについて別個のスレッドが作成され、関連WSAはSOAPリクエストの処理中にそのMFPと通信してもよい。言い換えれば、複数のICスレッドがあってよいが、説明の便宜上、唯１つのスレッド２０６しか示されていない。

２．３ リクエスト処理スレッド
図２に示されている他のスレッドはリクエスト処理(RP)スレッド２０８であり、関連WSAのビジネスロジックに従ってSOAPリクエストを処理する責務を負う。例えば、関連WSAは印刷サービスを提供しているかもしれない。印刷ジョブを実行するリクエストを受信すると、RPスレッド２０８は、印刷ジョブのサイズ、プリンタの利用可能性、他の処理途中の印刷ジョブと比較した場合の印刷ジョブの優先状態を確認する。RPスレッド２０８は印刷ジョブの詳細をプリンタに教えてもよい。WSAのビジネスロジックの他の例は、SOAPリクエストをインターナルリクエストに変換することであり、インターナルリクエストは下位レベル（即ち、ターゲットプラットフォーム）に転送可能であり且つ理解可能である。RPスレッド２０８はセキュリティ機能を実行してもよい。例えば、（SOAPリクエストを送信した）クライアントが、そのSOAPリクエストを実行するのにクライアントが必要とする特定のリソースへのアクセス権を持っているか否かを確認してもよい。

本発明の実施例では、メインスレッド２０２のようなメインスレッドを実行することは必須ではない。むしろ上記以外の他のスレッドが、他の機能を実行しつつ、メインスレッド２０２として機能してもよい。例えば、関連WSAが初めて起動される場合にEPRスレッド２０４が作成され、ICスレッド及びRPスレッド２０８の生成を引き起こしてもよい。以後、ERPスレッド２０４は、クライアントアプリケーションから送られてくるSOAPリクエストを待機し、受信し、処理し、送信する。

２．４ SOAPリクエストのマルチスレッド処理フロー
図３はWSAの中で複数のスレッドが複数のリクエストをどのように処理するかを示す本発明の一実施例によるフローチャートを示す。ステップ３０２では、少なくとも３つのスレッド（上述したようなERPスレッド、RPスレッド及びICスレッド）が作成される。

ステップ３０４では、ERPスレッドが外部ネットワークコネクションを開設する。ステップ３０６では、ERPスレッドが到来するメッセージ及び／又はコネクションをモニタする。ステップ３０８，３１０では、ERPはSOAPリクエストを受信し、SOAPリクエストのタイプを検査することで、どのスレッドが（例えば、ICスレッドが又はRPスレッドが）SOAPリクエストを以後処理すべきかをERPは確認する。そのような確認は、ICスレッド又はRPスレッドのような特定のスレッドにそれぞれ関連するタイプのリスト又はテーブルと、SOAPリクエストのタイプとを比較することでなされてもよい。

ステップ３１２では、ステップ３１０での確認に基づいて、ERPスレッドは、将来の処理に備えて適切なスレッドにSOAPリクエストをディスパッチ又は転送する。一実施例では、EPRスレッドは、適切なスレッドに専念するためにSOAPリクエストをキューに入れる。例えば、EPRスレッドはSOAPリクエストをRPスレッドのRPキューに入れる。

RPスレッドはSOAPリクエストディスパッチを待機する（ステップ３１４）。RPスレッドがSOAPリクエストを受けると、RPスレッドはSOAPリクエストを分析し、そのタイプを確認する（ステップ３１６）。或いは、ERPスレッドはSOAPリクエストと共にリクエストタイプを送信し、SOAPリクエストの分析にRPスレッドが不要になるようにしてもよい。

ステップ３１８では、関連WSAのビジネスロジックに従ってRPスレッドがSOAPリクエストを処理する。

ステップ３２０，３２２では、RPスレッドは或るレスポンスを生成し、SOAPリクエストを送信したクライアントアプリケーションにそのレスポンスを送る。或いは、SOAPリクエストを処理する際にエラーが起こるかもしれない。例えば、SOAPリクエストが適切にフォーマットされないかもしれない。別の例として、プリンタで紙詰まりが起こった場合、プリンタが復旧するまで、コネクションをオープンにし続ける代わりに、RPスレッドはクライアントアプリケーションに障害を通知し、クライアントアプリケーションが印刷ジョブを別のMFPに送信してもよいようにする。別の例として、イベント予約リクエストで指定されている宛先数が許容可能な限界より多いことをRPスレッドが確認してもよい。そのような場合、RPスレッドはフォルトメッセージを作成し、SOAPリクエストを送ったクラアイントアプリケーションに送付する。

ステップ３２４では、例えば、MFPのDFMとの、WSイベンティングモジュールとの、又はMFPのターゲットプラットフォームとの内部通信をICスレッドが始める。ステップ３２６では、ICスレッドはERPスレッドから内部通信リクエストを待機する。ステップ３２８では、ICスレッドはSOAPリクエストをMFPの適切なモジュール（関連WSAとは異なる）に送る。ステップ３３０では、ICスレッドはそのモジュールから応答又は障害メッセージを受信する。ステップ３３２では、ICスレッドは、SOAPリクエストを送信したクライアントアプリケーションに応答又は障害メッセージを送る。

２．５ SOAPリクエストのマルチスレッド処理例
クライアントアプリケーションはSOAPリクエストをMFPのソケットに送信し、そこではWSAのERPスレッドがコネクションをモニタしている。WSAは印刷サービスを提供し、SOAPリクエストは、WSAがリクエストを速やかに処理できる限り印刷ジョブが送られることを示す。SOAPリクエストはイベント予約リクエストを含んでもよいし、その後に続いてもよいし、イベント予約リクエストは、印刷ジョブが完了したことの通知を受けることをクライアントアプリケーションが希望していることを示す。ERPは、リクエストを受信し、RPスレッドがリクエストを処理すべきことを確認する。RPスレッドはSOAPリクエストを受信し、印刷ジョブキュー及び関連するプリンタの状態を確認することでWSAがそのリクエストを速やかに処理できるか否かをRPスレッドが確認する。WSAが印刷ジョブを速やかに処理できることをRPスレッドが確認すると、RPスレッドはそれを指示しているクライアントアプリケーションにレスポンスを返す。

クライアントアプリケーションは、MFPのプリンタで印刷されるデータをイベント予約リクエストと共に送信する。ERPスレッドは印刷ジョブデータを受信し、それをICスレッドに転送し、ICスレッドは印刷されるデータをターゲットプラットフォームに伝送する。イベント予約リクエストが初期SOAPリクエストと別々であった場合、ERPスレッドは以後の処理及び分析に備えてイベント予約リクエストをRPスレッドに転送する。RPスレッドはイベント予約リクエストをイベントマネジャに転送し、イベントマネジャは、例えば、モジュールで又はスレッドで構成され、イベント予約リクエストを処理し、それらのイベントを登録する。完了すると、ターゲットプラットフォームは、印刷ジョブが終了したことをしめす通知をICスレッドに送付する。ICスレッドはその通知をイベントマネジャに送付する。イベントマネジャは、印刷ジョブの完了をクライアントに通知するイベントメッセージを作成し、クライアントに送付する。

２．６ ウェブサービスアプリケーションのマルチスレッド手段の利点
本発明の実施例により、いくつもの利点がもたらされる。例えば、特定のスレッドは少数の機能についてしか責務を負わないので、WSAの設計はいっそうモジュール式になり、WSAはプログラムするのに容易になる。例えば、MFPの他のコンポーネントと通信することに関する如何なる知識も持たずに、開発者はRPスレッドに集中してよい。

複数のスレッドを利用する別の利点は、ネットワークから到来する外部リクエストは、残りのシステムに影響を及ぼさずに、待ち行列化され、先着順に処理されることである。別の利点は、WSAが現在行っている業務に如何なる制約も課さずに、ターゲットプラットフォームが、後の処理に備えてキューに入れたイベントを作成し、WSAに送付することである。

２．７ スレッド数
WSAを実現するのに実際に使用されるスレッド数は、上述のスレッド数より多くてもよい。より多くのスレッドを伴う場合でさえ、複数スレッドを実現する目標の１つはそのまま残り、効率を改善し、MFPの他のコンポーネントと非同期に動作することを可能にする。WSAを実現するのに使用されてよい他のスレッドは、以下のセクションで説明される。しかしながら、過剰に多くのスレッドが作成された場合、特に複数のスレッドがメモリのような同じリソースにアクセスできる場合、効果が減殺されるかもしれない。過剰に多くのスレッドは、デッドロック、ロジックの複雑さが増えること、バグの可能性を増やすこと、リソースコストの高いコンテキストスイッチを招き、そのスイッチはスレッド間で切り替えを行う場合に必要になるかもしれない。MFPでいくつのスレッドが動作するかを決める際に適用されてよい１つの原理は、排他的なリソース各々へのアクセスを処理することに専念する高々１つのスレッドを持つことである。

３．０ ファーストリクエスト及びスローリクエストを別様に処理すること
WSAが多数のSOAPリクエストを比較的短期期間に受信すると、好ましくない状態が生じるおそれがある。WSAが３つの大きな印刷ジョブリクエストを受信し、サイズがかなり小さく且つ処理に多くの時間を要しない２つのイベント予約リクエストが続いたとする。SOAPリクエストが順番に処理される場合、その２つの予約リクエストは、３つの大きな印刷ジョブが印刷を完了するまで待たなければならない。最初の印刷ジョブが実行にかなり多くの時間を費やしたとすると、残りの４つのリクエストは（それまでにWSAがそれらを十分に処理せずに）時間切れになってしまうおそれがある。従って本発明の一実施例では、異なるタイプのクライアントリクエストは別個に処理される。

リクエストは少なくとも２つのタイプに分類されてよい。単なる説明の便宜上、唯２つのタイプのリクエストが説明されるが、多くのタイプが規定されてよい。一方のタイプのリクエストは「ファースト又は短時間(fast)」リクエストと言及され、他方のタイプのリクエストは「スロー又は長時間(slow)」リクエストと言及される。

ファーストリクエストは、そのリクエストを処理する時間が、クライアントアプリケーションに時間切れを引き起こすほどには長くないリクエストである。スローリクエストは、そのリクエストを処理する時間が、クライアントアプリケーションに時間切れを引き起こすほど長いリクエストである。リクエストが「ファースト」であるか又は「スロー」であるかの判定で考察されてよいいくつかの要因は、リクエスト及び何らかの関連するデータのサイズ、クライアントがどの程度長くブロックされるか、プリンタやスキャナ等のような特定のリソースの利用可能性にリクエストが依存するか否か等を含んでよいが、それらに限定されない。例えば、SOAPリクエスト及びその関連するデータが、（イベント予約リクエストのように）全体をバッファリングできるほど十分に小さかったならば、そのSOAPリクエストは「ファースト」と考えられ、ファーストリクエストとして処理されてよい。別の例として、リクエストが印刷ジョブであって、プリンタの独占的な使用を要する場合、そのリクエストは「スロー」であると考えられ、スローリクエストとして処理されてよい。ファーストリクエストの具体例は、イベントに予約するためのリクエスト、ジョブのステータスを検索するためのリクエスト、ジョブをキャンセルするためのリクエスト、及びジョブを作成するためのリクエスト等を含んでもよい。スローリクエストの具体例は、書類送付リクエスト（即ち、印刷ジョブの一部分）でもよい。

３．１ ファーストリクエスト及びスローリクエストを処理するフローチャート
図４Ａ−Ｂは、ファースト及びスローリクエストがどのように別々に処理されるかを示す本発明の一実施例によるフローチャートである。ステップ４０２では、少なくとも３つのリクエスト（外部リクエスト処理(ERP)スレッド、ファーストリクエスト処理(短時間RP)スレッド、スローリクエスト処理(長時間RP)スレッド）が作成される。ステップ４０４では、例えば「マスタ(master)」リスニングソケットをオープンにすることでネットワークが初期化され、そのソケットを介して関連WSAがSOAPリクエストを受信する。マスタソケットの特性を受け継いだ第２ソケットが作成される。一旦リクエストが受け入れられると、リクエストに関連する全てのデータを受け入れるために第２ソケットが使用される。

ステップ４０６では、（スローリクエストに必要ならば）コネクションに関するTCPウインドウをERPスレッドが狭める又は閉じる。これは、リクエスト全体を受信するよう動作することが適切であるか否かが分かるまで、それを回避するためである。リクエスト全体が受信される前にTCPウインドウを狭めることは、リクエストがファーストであるか又はスローであるかをERPスレッドが確認するまで、WSAが新たなリクエストのデータを徐々に増やしながら受信することを保証する。リクエスト全体が受信された後にTCPウインドウが狭められる場合、クライアントはそのリクエストを「完全に送付されるもの」と考え、クライアントは以後タイムアウトタイマーを開始する。リクエストがスローリクエストであった場合、そのクライアントはタイムアウトしやすくなり、エラーしやすくなってしまう。TCPウインドウを操作する目的は、WSAがリクエストを処理する準備が整うまで（例えば、排他的なリソースアクセス権が得られるまで）、クライアントがリクエストを完全に送出するのを防ぐことである。しかしながら代替実施例ではERPスレッドは如何なるリクエストについてもTCPウインドウを変更しない。

TCPコネクションのウインドウサイズは、コネクションの間に保持可能なデータ量（バイト）である。クライアントがWSAからの確認（アクノリッジメント）及びウインドウ更新を待機しなければならなくなる前に、クライアントはそのデータ量だけなら送ることができる。従って、TCPコネクションのウインドウサイズを狭めるために、ERPスレッドは２を伴うアクノリッジメントを送信し、例えば、少なくとも更なる通知（例えば、スローRPスレッドがリクエストを処理するよう準備できた旨の通知）を受けるまで、WSAは一度に２バイトだけ受け入れ可能なことをクライアントアプリケーションに通知する。０バイトウインドウは、クライアントアプリケーションとのコネクションを落とさずに、TCPウインドウを実際上閉じてしまう。

ステップ４０８では、ERPスレッドは到来するコネクションをモニタする。ステップ４１０では、ERPはSOAPリクエストに関する少なくとも何らかのデータを受信する。図４Ｂのステップ４１４では、ERPスレッドはSOAPリクエストを分析し、そのSOAPリクエストが「ファースト」なのか或いは「スロー」なのかを確認する。

一実施例では、リクエストがファーストであること及びスローであることの確認は、少なくとも一部のリクエストがWSAで受信された時になされる。ERPスレッドはリクエストの「アクション(Action)」フィールド（WS-Addressing仕様で規定されているようなフィールド）を検査し、そのアクション（例えば、ジョブを生成すること）を確認し、リクエストアクションの所定のリスト又はテーブルを調べる（リクエストアクションはそれぞれファーストタイプ又はスロータイプに関連している。）。

リクエストが「ファースト」であった場合、ステップ４１６でSOAPリクエスト全体及び関連するデータがバッファリングされてよい。ステップ４１８では、ERPスレッド（又は別のスレッド）が、ファーストリクエストのキューが一杯であるか否かを判定する。キューが一杯であった場合、問い合わせのスロットが空くまでリクエストはブロックされる。「ブロックする」とは、ERPスレッドが別の何かを行うことに優先して、ファーストキューが利用可能になるまでERPスレッドが待機することを意味する。ファーストリクエストキューは如何なるサイズでもよい。ファーストリクエストはスローリクエストよりも十分小さい性質があるので、ファーストリクエストキューは、スローリクエストキューより多くのSOAPリクエストを保持する。

ステップ４２０では、ERPスレッドは、スローリクエストを処理するために以前にTCPウインドウを狭めたならば、そのTCPウインドウを広げる。ステップ４２２でERPスレッドはSOAPリクエストをファーストリクエストキューに入れる。

リクエストが「スロー」であった場合、ステップ４２４にて、SOAPリクエストに関連する全てのデータを完全にバッファリングすることは止められる。ステップ４２６にてERPスレッドは、スローリクエストのキューが一杯であるか否かを確認する。キューが一杯であった場合、そのリクエストは拒絶され、過剰に多くの（例えば、大きな）リクエストが未処理であることをクライアントに示すフォルト信号をクライアントに送ってもよい。

ステップ４２８では、ERPスレッドがTCPウインドウを広げる又は狭める（スローリクエストにとって必要であった場合）。一実施例では、ERPスレッドがステップ４０６でTCPウインドウを狭めていた場合、ERPスレッドはステップ２３８でTCPウインドウをクローズにする。

ステップ４３０では、ERPスレッドはSOAPリクエストをスローリクエストキューに入れる。

３．１．１ ファーストリクエスト処理スレッド
ステップ４４０では、バッファされていたSOAPリクエストをファーストリクエストキューから取り出す。ファーストRPスレッドがそのキューの中で次の特定のリクエストを選択する方法はいくつもある。例えば、処理する次のファーストリクエストは、FIFOやLIFOに基づいて決定されてもよいし、リクエストがWSAで受信された順序によらない他の何らかの優先方法に基づいて決定されてもよい。

ステップ４４２では、キャンセルジョブやイベント予約リクエスト等のようなリクエストの具体的なタイプに基づいて、ファーストRPスレッドがSOAPリクエストを処理する。SOAPリクエストの処理は、（アブストラクトAPIを介してターゲットプラットフォームに至るような）下位レベルAPIを呼び出すことや、以下で詳細に説明されるイベントマネジャのような他のモジュール又はスレッドにSOAPリクエストを転送することを含んでもよい。

ステップ４４４，４４６では、ファースとRPスレッドがレスポンスを生成し、ファースとリクエストを送ったクライアントにそのレスポンスを返す。

３．１．２ スローリクエスト処理スレッド
ステップ４５０では、スローRPスレッドは、スローリクエストのキュー内の最初のリクエストに必要で利用可能なリソースを点検する。例えば、キューの中で処理されるべき次のスローリクエストが印刷ジョブであり、今のところプリンタは別の印刷ジョブの書類を印刷していたとする。従ってプリンタは利用可能でなく、最初のスローリクエストはその印刷ジョブが終わるまで待たなければならない。リソースが利用可能でなかった場合、スローRPスレッドはリソースの利用可能性を周期的に点検してもよい。次のリクエストが利用できないリソースを待機している場合、スローRPスレッドはキューの中の別のリソースを処理し始めてもよい。例えば、キュー内の全てのスローリクエストが同じリソースの独占的な利用を要する場合、それらのスローリクエストは順番に処理される（例えば、リクエストが受信された順序で処理される。）。しかしながら、リソースＡ及びリソースＢのように異なるリソースをスローリクエスト(複数)が必要としていた場合で、リソースＡは利用不可能であるが、リソースＢは利用可能であった場合、リソースＢの独占的利用を要するスローリクエストは、そのスローリクエストがたとえ後に待ち並んでいたとしても最初に処理されてよい。

リソースが利用可能になると、プロセスはステップ４５２に進み、スローRPスレッドは次のリクエストをスローリクエストキューの中から取り出す。ステップ４５４では、コネクションに関連するTCPウインドウは、（以前に狭められていた又は閉じられていた場合）広げられる。

ステップ４５６にてスローRPスレッドは、取り出されたSOAPリクエストに関する残りのデータを受信する。例えば、スローリクエストが書類送付リクエストであった場合、（いくらかは既に送付済みであったならば）印刷される残りの書類がWSAに送られる。

ステップ４５８では、スローRPスレッドはリクエストの具体的なタイプに基づいてSOAPリクエストを処理する。ファースとリクエストに関連して説明したように、スローリクエストの処理は、（例えば、抽象APIを介してターゲットプラットフォームに至るような）下位レベルAPIを呼び出すことや、イベントマネジャのような別のモジュールにリクエストを転送することを含んでよい。

ステップ４６０，４６２にてスローRPスレッドはレスポンスを作成し、スローリクエストを送ったクライアントにレスポンスを返す。しかしながらリクエストによってはレスポンスを要しないかもしれない。例えば、書類送付リクエストは、クライアントにレスポンスを送ることをWSAに要求しないかもしれない。

場合によっては複数のタイプの外部リソースが存在し、様々なタイプのスローリクエストがそれら複数のタイプに依存する。従って一実施例ではタイプ各々に別個のスレッド及びキューが用意される。例えば、スローリクエストが電話回線の利用を要するファックスを送るリクエストであり、その電話回線では一度に１つのファックスしか伝送できないかもしれない。従ってファックスリクエストの処理及びキューイングに専念する別個のスレッドが生成されてもよい。別の実施例として、スキャニングサービスを提供するWSAが２種類のスローリクエストを有するかもしれない：１つはスキャンジョブ生成（スキャンエンジンの排他的な利用を要する）であり、もう１つはスキャンされた大量のデータをネットワークを介して抽出することである（しばらく時間がかかる）。これら２種類のリクエストをファーストリクエストと別々に処理することは、全てのファーストリクエストが時間どおりに処理されること及びシステムが効率的に動作することの保証を支援する。例えば、スキャンされた大量のデータを転送するリクエストをした後に、クライアントがジョブキャンセルリクエストを送った場合、WSAはそのジョブキャンセルリクエストを受けると直ぐに、WSAはスキャンデータの送信を速やかに止める。

３．２ ファーストリクエスト及びスローリクエストを別様に処理する利点
ファースト及びスローリクエストを別個に処理することにより多くの利点が得られる。利点の１つは、１つ以上の様々なリソースへのアクセスを要するリクエストの処理をシリアル化するようにWSAを動作させることである。別の利点は、ファーストリクエストの処理の促進を犠牲にせずに、WSAがスローリクエストを処理することである。別の利点は、WSAとのクライアントのコネクションは、処理されるリクエストをクライアントが待機している間に時間切れにならずに済むことである。要するに、異なるタイプのリクエストを別様に処理することは、MFPで動作するWSAの効率及び機能的スループットを最大化する。

４．０ WS-Eventingのウェブサービスアプリケーションへの統合
MFPのWSAに複数のウェブサービス仕様を用意する１つの方法は、MFPのDFMのような、MFP内の単独の場所にウェブサービス仕様を実現することである。その場合、ウェブサービスは、いったん実装されると、MFPの全てのWSAの中で共有される。しかしながらDFM内にWSイベンティング(WS-Eventing)を実装することは、いくつもの理由で問題がある（以下のWSイベンティングに関するものは、WSノーティフィケーション(WS-Notification)のような他のイベンティング仕様にも適用可能である。従ってMFPはWSイベンティングの代わりにWSノーティフィケーションを実現してもよい。）。

WSイベンティングは、簡潔なイベント記述及び通知サービスであるように当初は意図されていた。しかしながら、MFPの或るWSAはそのような簡潔なイベントサービスを上回るものを必要とする。従って、イベント記述応答メッセージが要求を発するクライアントに送付される前に、イベント記述リクエストの追加的な処理をWSA（例えば、スキャニングサービスを提供するもの）が実行することを許容するように、WSイベンティングは拡張されなければならない。そのような追加的な処理が必要とされるのは、或るイベント記述リクエストは、関連するWSAに固有の情報を含んでいるからである。WSイベンティングがMFPのDFMで実現される場合、WSA及びDFMの間で追加的な通信がなされなければならない。なぜならDFMはWSAの詳細を知らないからである。従ってWSA及びDFM間の通信の複雑さが増し、処理時間の中でエラー及び少なくとも劣化を招きやすくなるおそれがある。イベント予約リクエストに応答して、クライアントが予約応答メッセージを一切受信しなかった場合又はクライアントがエラーメッセージを受信した場合、感じられるMFPの利用性は大幅に減ってしまう。

従って本発明の実施例では、WSイベンティングがMFPの１つ以上のWSAに統合される。このビルトイン機能（「イベントマネジャ」と言及される）は一般的なイベンティング手段（例えば、予約生成、管理及びイベントデリバリ等）を与えるだけでなく、イベントマネジャは関連するWSAの他のコンポーネントと緊密に機能し、それらのコンポーネント及びイベントマネジャ間で効率的な双方向通信を可能にする。

図５はMFPのイベント処理コンポーネントの相互関係を示す本発明の一実施例によるブロック図である。クライアント５０２はイベント予約リクエストをWSA５０４に送る。WSA５０４は、イベントマネジャ(EM)５０６と通信し、WSイベンティング（仕様に従って動作する手段）を実装し、EM５０６がイベント予約リクエストをクライアント５０２に送る前にその予約リクエストを事前に処理する。EM５０６はWSA５０４内のスレッド又はモジュールとして実現されてもよい。後の時点でデバイス５０８はWSA５０４のアブストラクトレイヤ５１０にイベントを通知し、アブストラクトレイヤはその通知をWSA５０４に転送する。アブストラクトレイヤ５１０は、例えばMFPの様々なプラットフォームと通信することに専念する別個のモジュール又はスレッドとして実現されてもよい。或いは、デバイス５０８はその通知をWSA５０４に直接的に送信してもよい。例えばデバイス５０８はターゲットプラットフォームでもよく、少なくとも何らかのイベントがそのターゲットプラットフォームから生成される。

WSA５０４はEM５０６に通知を転送するが、それは比較的簡易なプロシジャである。なぜなら、EM５０６はWSA５０４内のモジュール又はスレッドとして実現されてよいからである。EM５０６はその通知を処理し、イベント通知メッセージを作成し、そのメッセージをクライアント５０２に送信する。

４．１ イベンティングシーケンス図
図６はイベント予約リクエストがWSAでどのように処理されるかの詳細を示す本発明の一実施例によるシーケンス図である。ステップ１でクライアント５０２はイベント予約リクエストを生成し、そのリクエストをWSA５０４に送信する。

ステップ２にてWSA５０４は予約リクエストをイベントマネジャ(EM)５０６に転送する。WSA５０４はWSイベンティング仕様を知らないので、WSA５０４はその予約リクエストに含まれている必要などのWSA固有データも取り出せない。WSA５０４がスキャニングサービスを提供する場合、WSA固有データはスキャンジョブの宛先であるかもしれない。従ってEM５０６はWSA固有データをその予約リクエストから取り出し、（ステップ３で）それを処理するWSA５０４に送信する。

ステップ３の前に、EM５０６はイベント予約リクエストが適切にフォーマットされているか否かを（WSイベンティング仕様に従って）確認してもよい。そのようにフォーマットされていなかった場合、WSA５０４又はEM５０６はフォルトメッセージをクライアント５０２に直接的に送ってもよい。

４．１．１ 前処理
ステップ４でWSA５０４は、EM５０６がイベント予約応答を構築する前にWSA固有データに前処理を施す。例えば、WSA５０４がスキャニングサービスを提供していた場合、クライアント５０２からのイベント予約リクエストは、スキャンされた書類を送付する宛先を識別している。従ってWSA５０４は、WSA固有のデータで指定されている宛先を管理する宛先マネジャを含んでもよい。宛先が有効でないことを（例えば、宛先マネジャを用いて）WSA５０４が確認した場合、WSA５０４は（ステップ５で）フォルトメッセージをクライアント５０２に直接的に送信し、クライアントにエラーを通知し、以後イベント予約リクエストの処理を停止してもよい。WSA５０４及びEM５０６の間で追加的な通信は一切必要なく、これはWSAにWSイベンティングを実装することによる利点の１つである。有効でない宛先の具体例は、イベント予約リクエストの宛先数の閾値を越えた場合である。

或いは、ステップ４でWSA５０４はWSA固有データを認識しないかもしれない。その結果、WSA５０４は（ステップ５で）フォルトメッセージをクライアント５０２に送信し、クライアントにエラーを通知するかもしれない。

ステップ４での前処理の別の例は、スキャニングコンテキストにおけるものである。WSA５０４は、WSA固有データで指定されている宛先を、セキュリティの目的で代替的な宛先アドレスに対応付けてもよい。代替的な宛先アドレスはEM５０６に送信され、EMは、その代替的な宛先アドレスを、クライアント５０２に送られるイベント予約レスポンスに付ける。

WSA５０４からEM５０６（例えば、代替的な宛先アドレス）へ伝送されるデータは「ブラックボックス」として伝送され、EM５０６はデータの内容を一切知らないし、そのデータについて如何なる処理も実行しない。EM５０６は、イベント予約レスポンス内の所定場所にデータをそのまま挿入するにすぎない。言い換えれば、WSA５０４及びEM５０６は実際のところ互いのデータの知識を持っていないが、このことは、それらがモジュール形式を維持し且つ互いに独立であるようにイベントマネジャをWSAに統合する上で重要になる。

同様にEM５０６がリクエストからWSA固有データを取り出す場合、データ内容の知識なしに、EM５０６はリクエスト中の所定場所でデータを取り出すにすぎない。

ステップ５にてフォルトメッセージが一切送信されなかった場合、WSA５０４はWSA固有データをEM５０６に送信し、それをイベント予約レスポンスメッセージ（予約応答）に含める。

ステップ６ではEM５０６が予約応答をクライアント５０２に送信し、その予約応答はイベント予約リクエストが成功したことをクライアントに通知するものである。WSA５０４はWSイベンティング仕様を「知らない」ので、EM５０６が予約応答を生成する責務を有する。

４．１．２ 後処理
ステップ７では、EM５０６は後処理に備えてWSAにデータを送信し、以後WSA５０４はそのデータに後処理を施す（ステップ８）。例えばスキャニングの例の場合、WSA５０４は、予約リクエストで指定されている宛先を、（例えば、宛先マネジャを利用して）将来の利用に備えてローカルメモリ中の宛先リストに加えて保存してもよい。

ステップ８の後処理を行う理由の１つは、EM５０６が予約応答を作成する場合、EMで作成されたデータをWSA５０４が利用しなければならないかもしれないからである。例えば、WSA５０４は予約識別子を追跡しなければならないかもしれない（その予約識別子は、受け入れた予約を一意に区別するためにEM５０６が生成したものである。）。従って後処理は前処理と一緒にすべきでない。しかしながらこれは或る典型例である。一般的にはWSA５０４はイベンティングについて何も知らなくてよい。

ステップ８で後処理を行う別の理由は、不要な処理ステップを避けるためである。前処理の最中に（ステップ４）、EM５０６は可能ならばWSA固有データを取り出すことを要するかもしれない。WSイベンティング仕様に基づいてイベント予約リクエストの正当性を確認することはEM５０６にとって選択的なことである。予約応答メッセージを構成する前に、イベント予約リクエストは有効でないことをEM５０６が確認した場合、EM５０６はそのエラーをWSA５０４に通知し、WSA５０４は後処理ステップを実行しなくてよい。

イベントマネジャの予約処理で前処理及び後処理を分離することは、イベントマネジャ及びWSAのモジュール性を維持しつつ柔軟性及び拡張性を大きくする。このように、イベントマネジャもWSAも互いのデータ方式やビジネスロジックを理解しなくてよい。

４．１ イベンティングシーケンス図（続き）
ステップ９ではデバイス５０８がイベントを生成し、そのイベントの通知をアブストラクトレイヤ５１０に送信する。ステップ１０では、アブストラクトレイヤ５１０がイベント通知をWSA５０４に転送し、WSAはWSA固有のノーティフィケーションボディを作成し、それをEM５０６に伝送する（ステップ１１）。一実施例では、WSA５０４はイベント処理スレッド（図７に関連して詳細に説明される）を有し、そのようなイベント通知をアブストラクトレイヤ５１０から受信し、イベント通知をイベントシンクに配る。このように、イベント予約リクエストを処理するタスクは、生成したイベントを処理するタスク及びイベント通知を配るタスクから分離されてよい。以後のステップは１つ以上のイベント処理スレッドによって代替的に実行されてもよい。

ステップ１２では、EM５０６が、ノーティフィケーションボディに基づいて適切なイベント通知メッセージを作成し、そのメッセージをイベントシンクに送信し、イベントシンクはクライアント５０２及び（クライアント５０２がイベントを予約することに関する）他の何らかのクライアントを含んでもよい。ステップ１３ではEM５０６は、（例えば、適切なクライアントがイベントの通知を受けていた）特定のイベントの通知状況を更新する。

ステップ１４では、イベント予約が期限切れになった場合又は解約になった場合、EM５０６はWSA５０４に通知を行う。期限切れ又は解約に起因して或るイベント予約が除かれた場合、或るWSAは或るアクション（動作）を要するかもしれない。例えば、クライアントがスキャンの宛先をイベント予約リクエストを通じて登録していたが、その予約が削除された場合、スキャナWSAは登録済みのスキャン宛先を削除する必要がある。

４．２ マルチスレッドイベント処理フローチャート
上述したように、SOAPリクエスト−特にイベント予約リクエスト−を処理するために複数のスレッドが使用されてよい。図７はイベント予約リクエストを処理するマルチスレッドWSAを示す本発明の一実施例によるフローチャートである。このフローチャートは、SOAPリクエストを効率的に処理することに関して説明されたスレッドに関連している。そのようなスレッドは、外部リクエスト処理(ERP)スレッド、スローリクエスト処理(RP)スレッド及びファーストRPスレッドを含む。（デバイスから抽象APIを経てWSAへの）イベント生成及び（WSAからイベントマネジャを経てクライアントへの）イベント通知の責務を担う新たなスレッド、イベント処理スレッドが含まれている。

ステップ７０２では複数のスレッドが作成される。一実施例では、EPRスレッドは、SOAPリクエストを受信し、そのリクエストがファーストリクエストとして又はスローリクエストとして処理可能か否かを判定し、適切なキューにリクエストを入れる（図示せず）。

４．２．１ ファーストリクエスト処理スレッド
ステップ７０４ではファーストRPスレッドが、SOAPリクエストをファーストリクエストキューから取り出し、リクエストのタイプをステップ７０６で確認する。SOAPリクエストがイベント予約リクエストでなかったならば、ステップ７０８にて例えば関連するWSAの抽象APIを呼び出すこと、そのリクエストをWSA又はMFP（例えば、DFM）の別モジュールに転送すること等により、ファーストRPスレッドはリクエストを適切に処理する。ステップ７０８での処理の結果、ファーストRPスレッドは（リクエストで必要ならば）レスポンスを作成し（ステップ７１０）、そのレスポンスを適切なクライアントに送る（ステップ７１２）。

リクエストがイベント予約リクエストであることをファーストRPスレッドが確認した場合（ステップ７０６）、プロセスはステップ７１４に進み、イベントマネジャがWSA固有データを取り出した後に、ファーストRPスレッドが予約リクエストに前処理を施す。WSAによっては、このステップは不要かもしれない。（典型的には）イベントマネジャはイベント予約リクエストがどのようにフォーマットされているかということだけなら「知っている」ので、ファーストRPスレッドがステップ７１４を実行するか否かによらず、イベントマネジャはイベント予約リクエストの有効性を確認する。

ステップ７１６では、イベントマネジャはWSイベンティング仕様に従って予約リクエストを処理する。ステップ７１８ではイベントマネジャはイベント予約レスポンスを作成し、そのレスポンスを適切なクライアントに送る。再び、具体的なWSAに依存して、ステップ７２０でファーストRPスレッドは予約レスポンス中のWSA固有データに後処理を施しても施さなくてもよい。

ステップ７２０の後にファーストRPスレッドはステップ７０４で別のリクエストをファーストリクエストキューから取り出し、上述の処理を続ける。

４．２．２ イベント処理スレッド
ステップ７２２では、イベント処理スレッドがWSAからイベントアクションリストを登録する。このステップは、WSAが用意できる全ての可能なイベントをイベントマネジャに通知することをWSAに許可する。イベントマネジャはこのリストを用いて予約リクエストの有効性を確認する。特定の予約リクエストが、WSAが提供していないイベントについてのものであった場合、イベントマネジャはそのイベント予約リクエストを拒否するかもしれない。従って、イベントマネジャはそのモジュール性を発揮するよう設計されるが、イベントマネジャは、関連するWSAが如何なるイベントをサポートするかを「知っておく」べきである。

ステップ７２４３ではイベント処理スレッドが関連WSAの抽象APIと共にイベントを登録する。ステップ７２２，７２４は典型的には一度しか発生しないが、追加的なイベントがアブストラクトレイヤに後に登録される可能性がある。

ステップ７２６ではイベント処理スレッドはアブストラクトレイヤからのイベントを待つ。ステップ７２８ではイベント処理スレッドがアブストラクトレイヤからのイベントの通知を受ける。

ステップ７３０では、アブストラクトレイヤからのイベントについて受けた通知に基づいて、WSAはノーティフィケーションボディを生成し、それをイベントマネジャに渡す。イベントマネジャはそのノーティフィケーションヘッダを付加し、その結果のイベント通知メッセージをイベントシンクに送る。イベントシンクはイベント予約リクエストを送ったクライアントアプリケーションと同一である必要はない。なぜなら、クライアントアプリケーションは他のクライアントアプリケーションに代わってイベントを予約してよいからである。

ステップ７３２ではイベント処理スレッドがイベントのノーティフィケーションステータス(通知状況)を更新する。或るWSAは１つ以上の予約済みのイベントの通知状況を知る必要がある。例えば、プリンタWSAはイベントの通知状況を知らなくてよいかもしれない。なぜなら、プリンタのインベントは以後のクライアントリクエストに対して如何なる因果関係もないからである。一方、スキャナWSAの場合、クライアントが或るイベント通知を受けたときだけ、クライアントは以後のリクエストを送信する。したがってそのようなイベントの通知状況は、必要に応じてスキャナWSAが以後別の動作を行えるようにする点で特に重要である。

イベント通知がなされていなかったならば、イベント処理スレッドは、通知を再送したり予約をキャンセルしたりするような別のアクションを採用してもよい。追加的に又は代替的に、イベント処理スレッドは、関連するクライアントがオフラインの場合や動作してない場合にイベント通知を何度も再送してよい。

イベント処理スレッドは、予約の期限切れ時間を周期的に点検し、期限切れの予約を削除してよい。期限切れ、クライアントの解約リクエストその他の理由で或る種の予約が削除された場合、WSA内の他の関連するサブコンポーネントは通知を受けるようにしてもよい。

イベントが生成され、通知レスポンスが適切なクライアントアプリケーションに送付されたような良好なシナリオでは、更新された通知ステータスは「コンプリート(COMPLETE)」を示してもよい。クライアント各自のイベントの通知を依然として待機しているクライアントについては、関連するステータスは関連する期限切れ期間と共に「イベント処理中(EVENT PENDING)」を示してもよい。

４．３ WS-Eventingをウェブサービスアプリケーションに統合する利点
WSAにWSイベントティングを統合することは、MFPのDFMにWSイベンティングを実装するような他の可能性のある方法を上回る多くの利点をもたらす。１つの利点は、大量のデータがアプリケーション境界を越えて伝送されなくてよいことである。別の利点は、アプリケーション間の通信エラーのおそれが、少なくともWSイベンティングコンテキストにおいては無くなることである。また、WSAにWSイベンティングを統合することで、イベント予約リクエスト及びレスポンスからWSA固有データを取り出すことや、WSA固有データをイベントマネジャに渡すことは、WSAにとって比較的平易になる。例えば、イベントマネジャが予約を一掃するよう指示されたスレッドを作成する代わりに、WSAはWSAがアイドルの場合にイベントマネジャの機能を呼び出して期限切れの予約を一掃してもよい。

WSAにWSイベンティングを統合することは、WSA及び関連するイベントマネジャのモジュール性を保つ。そのようなモジュール性は、WSA及びイベントマネジャの将来的な更新及び設計の簡易化を促す。最後に、イベント通知の送出状況について、WSAはイベントマネジャからタイムリーに更新内容を受信できるようになる。

５．０ 実現手段
上記のアプローチは如何なるタイプのコンピュータプラットフォームでもアーキテクチャでも実現されてよい。図８は本発明の実施例で使用されるコンピュータシステム８００のブロック図を示す。コンピュータシステム８００は、情報を通信するためのバス８０２又は他の通信手段と、バス８０２に結合された情報を処理するプロセッサ８０４とを有する。コンピュータシステム８００は、ランダムアクセスメモリ(RAM)又は他のダイナミックストレージデバイスのようなバス８０２に結合されたメインメモリ８０６を有し、メインメモリはプロセッサ８０４で実行される命令や情報を格納する。メインメモリ８０６は、プロセッサ８０４で実行される命令の実行中に、一時的な変数又は他の中間的な情報を格納するのに使用されてもよい。コンピュータシステム８００は、プロセッサ８０４のための命令や静的な情報を格納する、バス８０２に結合されたリードオンリメモリ(ROM)８０８又は他のスタティックストレージデバイスを更に含む。磁気ディスク又は他の光ディスクのようなストレージデバイス８１０は、情報及び命令を格納するために用意されてバス８０２に結合される。

コンピュータシステム８００は、コンピュータユーザに情報を表示するために、陰極線管(CRT)のようなディスプレイ８１２にバス８０２を介して結合されてもよい。英数字その他のキーを含む入力装置８１４は、情報及び命令選択内容をプロセッサ８０４に通知するためにバス８０２に結合される。他の種類のユーザ入力装置は、カーソル制御装置８１６（例えば、マウス、トラックボール、カーソル方向キー）であり、指示情報及び命令選択をプロセッサ８０４に通知し且つディスプレイ８１２でのカーソルの動きを制御する。この入力装置は典型的には第１軸（例えば、ｘ）及び第２軸（例えば、ｙ）の２軸による２つの自由度を有し、装置が平面上の位置を指定できるようにする。

本発明は上記の技法を実現するコンピュータシステム８００を利用することに関連する。本発明の一実施例によれば、メインメモリ８０６に含まれる１以上の命令の１以上のシーケンスを実行するプロセッサ８０４に応じて、上記の技法がコンピュータシステム８００によって実行される。そのような命令は、ストレージデバイス８１０のような他のマシン読取可能な媒体からメインメモリ８０６に読み込まれてもよい。メインメモリ８０６に含まれている命令シーケンスの実行は、本願で説明されるプロセスステップをプロセッサ８０４が実行することを引き起こす。代替実施例では、本発明を実施するために、ハードワイヤード回路が、代替的に使用されてもよいし或いはソフトウエア命令との組み合わせで使用されてもよい。すなわち本発明の実施例はハードウエア回路及びソフトウエアの特定の如何なる組み合わせにも限定されない。

ここで使用されているように「マシン読取可能な媒体」なる用語は、マシン(コンピュータ)動作を特定の形態で引き起こすデータを用意することに関与する如何なる媒体にも関連する。コンピュータシステム８００を利用して実現される実施例では、様々なマシン読取可能な媒体が、実行する命令をプロセッサ８０４に提供する際に含まれてよい。そのような媒体は多くの形態をとってよく、限定ではないが、不揮発性媒体、揮発性媒体及び伝送媒体を含む。不揮発性媒体は、例えば、ストレージデバイス８１０のような光又は磁気ディスクを含む。揮発性媒体は、メインメモリ８０６のようなダイナミックメモリを含む。伝送媒体は、同軸ケーブル、銅線及び光ファイバを含み、バス８０２を構成するワイヤを含む。伝送媒体は、無線電波及び赤外線データ通信の際に生成されるもののような、音波又は光波の形式をとってもよい。

マシン読取可能な媒体の一般的な形態は、フロッピディスク、フレキシブルディスク、ハードディスク、磁気テープその他の如何なる磁気媒体、CD-ROMその他の如何なる光媒体、パンチカード、紙テープ又は穴のパターンを有する他の如何なる物理的媒体、RAM、PROM、EPROM、フラッシュEPROMその他のメモリチップ、カートリッジ、上記のような搬送波又はコンピュータが読み取ることの可能な他の如何なる媒体も含んでよい。

マシン読取可能な様々な形態は、１以上の命令の１以上のシーケンスをプロセッサ８０４に実行に備えて搬送する際にも適用可能である。例えば命令は初期には遠く離れたリモートコンピュータの磁気ディスクで搬送されてもよい。リモートコンピュータは自身のダイナミックメモリにその命令をロードし、モデムを用いて電話回線を介して命令を送信してもよい。コンピュータシステム８００付近のモデムは電話回線でそのデータを受信し、赤外線送信機を用いてそのデータを赤外線信号に変換する。赤外線検出器は、赤外線信号で搬送されたデータを受信し、そのデータをバス８０２に与えることができる。バス８０２はデータをメインメモリ８０６に運び、プロセッサ８０４はメインメモリから命令を抽出して実行する。メインメモリ８０６で受信された命令は、プロセッサ８０４で実行される前又はその後にストレージデバイス８１０に選択的に格納されてもよい。

コンピュータシステム８００はバス８０２に結合された通信インターフェース８１８も含む。通信インターフェース８１８は、ローカルネットワーク８２２に接続されるネットワークリンク８２０に結合する双方向データ通信をもたらす。例えば、通信インターフェース８１８は、データ通信接続を対応するタイプの電話回線に与える統合サービスディジタルネットワーク(ISDN)カード又はモデムでもよい。別の例では、通信インターフェース８１８は、データ通信接続をコンパチブルなLANに与えるLANカードでもよい。無線リンクが使用されてもよい。どの実現手段でも、通信インターフェース８１８は、電気的な、電磁的な又は光学的な信号を送信及び受信し、様々なタイプの情報を表現するディジタルデータストリームを運ぶ。

ネットワークリンク８２０は典型的には１以上のネットワークを介して他のデータ装置とのデータ通信をもたらす。例えば、ネットワークリンク８２０はローカルネットワーク８２２を介してホストコンピュータ８２４とのコネクションを提供する、或いはインターネットサービスプロバイダ(ISP)８２６により運営されるデータ機器とのコネクションを提供する。そしてISP８２６はデータ通信サービスをワールドワイドパケットデータ通信ネットワーク(今日、「インターネット」８２８として一般に言及されている)を介して提供する。ローカルネットワーク８２２及びインターネット８２８の双方は、ディジタルデータストリームを搬送する、電気的な、電磁的な又は光学的な信号を使用する。様々なネットワークを介する信号や、ネットワークリンク８２０における通信インターフェース８１８を介する信号は、コンピュータシステム８００に及びそこからディジタルデータを搬送し、例えば情報を伝送する搬送波の形式をとってもよい。

コンピュータシステム８００は、ネットワーク、ネットワークリンク８２０及び通信インターフェース８１８を介して、メッセージを送信し及びプログラムコードを含むデータを受信する。インターネットの例では、サーバー８３０はインターネット８２８、ISP８２６、ローカルネットワーク８２２及び通信インターフェース８１８を介して、アプリケーションプログラムに要求されるコードを送信するかもしれない。

プロセッサ８０４は受信したコードを受信したときに実行してもよいし、後の実行に備えてストレージデバイス８１０又は他の不揮発性ストレージに格納していたかのように実行してもよい。このようにコンピュータシステム８００は搬送波の形式でアプリケーションコードを取得してもよい。

以上本発明の実施例が多くの具体的詳細と共に説明されてきたが、その具体的詳細は実現手段毎に異なってよい。本発明が何であるかの及び出願人により発明であると意図されているものの唯一排他的なインジケータは、本願により発行される特許請求の範囲であり、その特許請求の範囲には将来的な如何なる補正も含まれる。特許請求の範囲に含まれている用語については明細書で明示的に言及された何らかの定義が、特許請求の範囲で使用されている用語の意味を定める。特許請求の範囲で明示的に言及されていない、限定、構成要件、性質、特徴、効果又は属性のいずれも特許請求の範囲を限定するように決して解釈されるべきでない。従って本明細書及び図面は、限定的な意味ではなく例示として解釈されるべきである。

［関連出願］
本願は２００６年１２月に出願された“IMPLEMENTING A WEB SERVICE APPLICATION ON A MULTI-FUNCTIONAL PERIPHERAL WITH MULTIPLE THREADS”と題する米国出願(代理人管理番号49986-0603)に関連し、その全内容が本願のリファレンスに組み入れられる。

本願は２００６年１２月に出願された“PROCESSING FAST AND SLOW SOAP REQUESTS DIFFERENTLY IN A WEB SERBICE APPLICATION OF A MULTI-FUNCTIONAL PERIPHERAL”と題する米国出願(代理人管理番号49986-0604)に関連し、その全内容が本願のリファレンスに組み入れられる。

本願は２００６年１２月に出願された“INTEGRATING EVENTING IN A WEB SERVICE APPLICATION OF MULTI-FUNCTIONAL PERIPHERAL”と題する米国出願(代理人管理番号49986-0599)に関連し、その全内容が本願のリファレンスに組み入れられる。

SOAPリクエストを処理する本発明の一実施例によるアーキテクチャ例１００を示すブロック図である。 MFPのウェブサービスアプリケーション内で動作する様々なスレッドを示す本発明の一実施例によるシーケンス図である。 ウェブサービスアプリケーションの中で複数のスレッドが１つ以上のリクエストを如何にして処理するかを示す本発明の一実施例によるフローチャートを示す。 速い及び遅いリクエストがどのように別様に処理されるかを示す本発明の一実施例によるフローチャートを示す。 速い及び遅いリクエストがどのように別様に処理されるかを示す本発明の一実施例によるフローチャートを示す。 MFPのイベント処理要素の関係を示す本発明の一実施例によるブロック図である。 WSA及び関連するイベントマネジャによりイベント予約リクエストがどのように処理されるかを示す本発明の一実施例によるシーケンス図である。 イベント予約リクエストを処理する複数のスレッドウェブサービスアプリケーションを示す本発明の一実施例によるフローチャートである。 本発明の一実施例で使用されるコンピュータシステムを示すブロック図である。

符号の説明

１００ アーキテクチャ
１０２ クライアント
１０４ アドミニストレータ
１０６ デバイスファシリティマネジャ
１０８ ウェブサービスアプリケーション
１１０ WSDマネジャ
１１２ WSディスカバリ
１１４ WSトランスファ
１１６ WSメタデータイクスチェンジ
１１８ WSセキュリティ
１２０ 一般的API
１２２ WSイベンティング
１２４ アブストラクトAPI
１３０ 従来のプラットフォーム
１３２，１４２，１５２ 一般的API手段
１３４，１４４，１５４ アブストラクトAPI手段
１４０ リナックスベースのプラットフォーム
１５０ VxWorksベースのプラットフォーム
５０２ クライアント
５０４ ウェブサービスアプリケーション
５０６ イベントマネジャ
５０８ デバイス
５１０ WSA抽象レイヤ
８００ コンピュータシステム
８０２ バス
８０４ プロセッサ
８０６ メインメモリ
８０８ リードオンリメモリ
８１０ ストレージデバイス
８１２ ディスプレイ
８１４ 入力装置
８１６ カーソル制御部
８１８ 通信インターフェース
８２０ ネットワークリンク
８２２ ローカルネットワーク
８２４ ホスト
８２６ インターネットサービスプロバイダ
８２８ インターネット
８３０ サーバー

Claims (11)

1. 複数のイベント予約リクエストを処理し、複数のサービスアプリケーションを有する複合機(MFP)であって、各サービスアプリケーションは少なくとも１つのサービスを提供し、当該MFPは、
   複数のサービスアプリケーションの中の或るサービスアプリケーションにて、イベントに予約するためのシンプルオブジェクトアクセスプロトコル(SOAP)リクエストを、クライアントアプリケーションから受信すること、及び
   通知メッセージをイベントシンクに送信すること、
   を実行するよう形成され、前記SOAPリクエストはイベント予約リクエストであり、
   前記サービスアプリケーションはイベントマネジャを含み、該イベントマネジャは(a)前記サービスアプリケーションのコンポーネントであり且つ(b)イベンティング仕様に従い、
   前記サービスアプリケーションは、イベントマネジャの機能を他の機能に加えて単独プロセスとして実行し、
   前記イベントマネジャが、前記SOAPリクエストで指定されている少なくともイベント及びイベントシンクを特定する識別情報を保持することを引き起こし、
   前記イベントマネジャが、イベントが生じたことを示す通知データを前記MFPのプラットフォームから受信することを引き起こし、
   前記イベントマネジャが、前記通知データを前記識別情報と比較することを引き起こし、
   該比較に基づいて、前記イベントマネジャが、前記クライアントアプリケーションに対する通知メッセージを作成することを引き起こし、
   前記サーバーアプリケーションが、第１スレッド及び第２スレッドを含み、該第１スレッドは、第１タイプのリクエストを処理することに割り当てられ、前記第１タイプのリクエストを処理するのに要する時間は、前記クライアントアプリケーションにタイムアウトを引き起こさせる程度に充分長く、前記第２スレッドは、第２タイプのリクエストを処理することに割り当てられ、前記第２タイプのリクエストを処理するのに要する時間は、前記クライアントアプリケーションにタイムアウトを引き起こさせる程には長くなく、
   前記SOAPリクエストは前記第２タイプであり、
   当該MFPは、
   前記SOAPリクエストが前記イベント予約リクエストであることを確認することを前記第２スレッドが引き起こし、
   前記イベント予約リクエストの処理の開始を前記第２スレッドが引き起こし、
   前記イベント予約リクエストの処理に基づいて、前記イベントマネジャが、予約レスポンスメッセージを前記クライアントアプリケーションに返すことを引き起こす、複合機。
2. 前記イベンティング仕様が、WSイベンティング及びWSノーティフィケーションの少なくとも一方である請求項１記載の複合機。
3. 前記複数のサービスアプリケーションの内の１つが印刷プロセスを含み、該印刷プロセスは、印刷データを処理し、該印刷データに反映されている印刷形式の電子書類が生成されることを引き起こすようにした請求項１記載の複合機。
4. デバイスファシリティマネジャ(DFM)が、当該MFPに関連付けられ且つクライアントアプリケーションからのデバイスメタデータを処理し、当該MFPで用意されているサービスを捜し、
   前記DFMは１つ以上のウェブサービスプロトコルに従う
   ようにした請求項１記載の複合機。
5. 前記DFMが、前記複数のサービスアプリケーションの内の１つ以上の他のサービスアプリケーションについて、WSイベンティング及びWSノーティフィケーションの少なくとも一方に従うようにした請求項４記載の複合機。
6. 前記イベントマネジャが識別情報を保持することを引き起こすように構成された当該MFPが、
   前記サービスアプリケーションに固有であって前記イベント予約リクエストからの第１データを、前記イベントマネジャが前記サーバーアプリケーションへ送信することを引き起こし、
   前記サービスアプリケーションが前記第１データを処理して第２データを生成することを引き起こし、
   前記サービスアプリケーションが前記第２データを前記イベントマネジャに送信することを引き起こし、
   前記イベントマネジャが、前記イベントマネジャにより生成された予約レスポンスに前記第２データを含めることを引き起こし、
   前記イベントマネジャが、前記予約レスポンスを前記クライアントアプリケーションに送付することを引き起こす
   ように構成される請求項１記載の複合機。
7. 前記イベントマネジャが識別情報を保持することを引き起こすように構成された当該MFPが、
   前記イベントマネジャが、予約レスポンスを生成することを引き起こし、
   前記サービスアプリケーションに固有であって前記予約レスポンスからの第３データを、前記イベントマネジャが前記サーバーアプリケーションへ送信することを引き起こし、
   前記サービスアプリケーションが、前記第３データを処理することを引き起こす
   ように構成される請求項１記載の複合機。
8. 前記イベントマネジャが識別情報を保持することを引き起こすように構成された当該MFPが、
   前記イベントマネジャが、予約レスポンスを生成することを引き起こし、
   前記イベントマネジャが、前記サービスアプリケーションへ処理のステータスを送信し、前記サービスアプリケーションに別の処理を実行可能にすることを引き起こす
   ように構成される請求項１記載の複合機。
9. 前記サービスアプリケーションがイベント処理スレッドを含み、該イベント処理スレッドは、
   前記サービスアプリケーションのアブストラクトレイヤにイベントを登録し、
   前記アブストラクトレイヤからのイベントの通知を待機及び受信し、
   通知メッセージを作成して前記イベントシンクに送付する
   ようにした請求項１記載の複合機。
10. イベントに関連するステータスを取り出すこと、該ステータスを更新すること、イベントを解約すること及びイベントを改新することを含む追加機能の内の少なくとも１つを前記イベントマネジャに実行させるように構成される請求項１記載の複合機。
11. 前記サービスアプリケーションが、
    クライアントアプリケーションからリクエストを受信し、該リクエストを少なくとも２つの他のスレッドに割り当てる外部リクエスト処理スレッドと、
    前記サービスアプリケーションのビジネスロジックに従ってSOAPリクエストを処理するリクエスト処理スレッドと、
    前記サービスアプリケーションとは異なる当該MFPの１つ以上のコンポーネントと通信する内部通信スレッドと、
    を有し、前記外部リクエスト処理スレッドは、前記イベント予約リクエストを受信する
    ようにした請求項１記載の複合機。

Images