ＳＯＡＰリクエストを処理するネットワーク装置
【課題】ウェブサービスシステムを拡張する技法を提供すること。
【解決手段】１つ以上のウェブサービスアプリケーション(WSA)は或る装置上で動作する。各WSAは少なくとも１つのサービスを提供する。WSAは、現在のバージョンのWS標準仕様に先行する或る特定のバージョンのウェブサービス(WS)仕様を実現する。或る技法では、オーケストレーションモジュールが追加され、WSA及び１つ以上の拡張モジュール間の相互作用を管理する。リクエストを処理する際、WSAはオーケストレーションモジュールを呼び出す。リクエストの１つ以上の属性に基づいて、オーケストレーションモジュールは、ロジックを有する拡張モジュールが、リクエストの一部を処理するように呼び出されるべきか否かを決める。ロジックは、過去のバージョンと現在のバージョンとの間の差異に対応するものである。拡張モジュールがリクエストの一部を処理し終えた後、WSAは、そのリクエストを更に処理することを引き起こす。
【解決手段】１つ以上のウェブサービスアプリケーション(WSA)は或る装置上で動作する。各WSAは少なくとも１つのサービスを提供する。WSAは、現在のバージョンのWS標準仕様に先行する或る特定のバージョンのウェブサービス(WS)仕様を実現する。或る技法では、オーケストレーションモジュールが追加され、WSA及び１つ以上の拡張モジュール間の相互作用を管理する。リクエストを処理する際、WSAはオーケストレーションモジュールを呼び出す。リクエストの１つ以上の属性に基づいて、オーケストレーションモジュールは、ロジックを有する拡張モジュールが、リクエストの一部を処理するように呼び出されるべきか否かを決める。ロジックは、過去のバージョンと現在のバージョンとの間の差異に対応するものである。拡張モジュールがリクエストの一部を処理し終えた後、WSAは、そのリクエストを更に処理することを引き起こす。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は一般にウェブサービスの技術分野に関連し、特に、既に配備済みのウェブサービスアプリケーションを拡張することに関連する。
【背景技術】
【０００２】
このセクションで説明されるアプローチは追跡可能なアプローチであるが、考察又は追跡が過去になされているアプローチであるとは限らない。従って、特に断りのない限り、このセクションで説明されるどのアプローチも、このセクションに含まれているという理由だけで従来技術と考えるよう仮定されるべきではない。
【０００３】
「ウェブサービス」という用語は、IPのようなネットワークプロトコル上でXML、SOAP及びWSDL標準仕様を用いてウェブベースのアプリケーションを統合する標準的な方法を表す。XMLはデータをタグ付けするのに使用される。SOAPはウェブサービスリクエスト及びレスポンスをXMLメッセージにエンコードする方法を指定する。WSDLは利用可能なサービスを記述するのに使用される。ウェブサービスは、その実施に際してプラットフォームによらずに、互いに通信するプログラム可能でネットワーク化されたエンティティに使用される。そのような多くのエンティティはビジネスに関連したものであるので、ウェブサービスは、ファイヤウォール背後の互いのITシステムの詳細な知識なしに、業務でのデータ通信を可能にする。
【０００４】
ウェブサービスは、ネットワークを介したプログラムインターフェースを通じて、ビジネスロジック(論理装置)、データ及びプロセスを共有する。ウェブサービスは、時間のかかるカスタムコーディングなしに、様々なソースからの様々なアプリケーションが互いに通信できるようにする。更に総ての通信はXMLなので、ウェブサービスは、或る何らかのオペレーティングシステムやプログラミング言語に拘束されない。例えば、ジャバ(Java(登録商標))はパイソン(Python)と通信可能であり、ウインドウズ(Windows(登録商標))アプリケーションはユニックス(UNIX(登録商標))アプリケーションと通信可能である。
【０００５】
ウェブサービス仕様は、セキュリティ、信頼できるメッセージング及び緩く結合されたシステムでの処理に備えて、相互運用可能なプロトコルを提供するように共に構築される。ウェブサービス仕様は、承認済みの標準仕様(ワールドワイドウェブコンソーシアム(W3C)及び構造化情報標準促進協会(OASIS)によって承認される)と、標準仕様になるかもしれない提案中のドキュメント及びドラフトとの双方を含む。
【０００６】
一般的には、ウェブサービスアプリケーション(WSA)は、１つ以上のウェブサービス(WS)仕様に拘束される（又はそれらを実現する）。従って、関連するファイルがスキーマ(schema)毎に有効であったとしても、WSAは(拘束される)その仕様で規定されていない情報を認識しない。
【０００７】
関連するWS標準仕様が修正される場合、WSAは更新される必要がある。なぜなら、あるクライアントアプリケーションはその修正を考慮に入れることを望むかもしれないからである。しかしながら、WSAで提供されるサービスを要求するクライアントアプリケーションが、その修正を反映するように未だ更新されていない場合に備えて、WSAを提供する装置(デバイス)は、古いバージョンのWS標準仕様に準拠したままであるべきである。
【発明の開示】
【発明が解決しようとする課題】
【０００８】
WS標準仕様の修正に応じる１つの方法は、別のWSAを開発することである。これは、設計、コーディング、検査、ドキュメンテーション及びメンテナンス等の様々な段階のソフトウエア開発プロセスを（再び）行うこととなってしまう（これは、一般的には非常にコスト高である）。この方法によれば、WS標準仕様の一連の修正がなされた後、(a)同様な基本サービスを提供する及び(b)同時に実行する多数のWSAが存在することになる。同時に動作する同様なWSAを多数備えることは、余分なメモリや処理電力を必要としてしまう。
【０００９】
同様な方法として、古いバージョン及び新しいバージョンのWS標準仕様を考慮に入れた新しいWSAが、開発されるかもしれない。しかしながら、この方法によれば、新しいWSAが導入される前に古いWSAが停止されなければならない。従ってWSAで提供されるサービスが一時的に利用できなくなるかもしれない。
【課題を解決するための手段】
【００１０】
本発明の一形態によれば、ウェブサービスシステムを拡張する技法が提供される。ある技法では、ウェブサービスアプリケーション(WSA)はリクエストを受信する。WSAは、現在のバージョンのWS標準仕様に先行する或るバージョンのウェブサービス(WS)仕様を実現する。オーケストレーション(orchestration)モジュールがリクエストを処理するために呼び出され、オーケストレーションモジュールは、WSA及び１つ以上の拡張モジュール間の相互作用を管理する。リクエストの１つ以上の属性に基づいて、オーケストレーションモジュールは、リクエストの一部を処理する拡張モジュールを特定する。拡張モジュールはロジック(論理装置)を有し、そのロジックは、過去のバージョンのウェブサービス仕様と現在のバージョンとの間の差異に対応するものである。オーケストレーションモジュールは、拡張モジュールがリクエストの一部を処理することを引き起こす。そのロジックに従って拡張モジュールがリクエストの一部を処理し終えた後、そのリクエストを更に処理するためにWSAが呼び出される。
【００１１】
別の技法によれば、WSAは複数のモジュールを有し、その内少なくとも２つは互いに相互作用するように設計されてないかもしれない。先ず、複数のモジュール中の第１モジュールがリクエストを処理する。その処理はオーケストレーションモジュールにより引き起こされる。リクエストの１つ上の属性に基づいて、オーケストレーションモジュールは、リクエストの一部を処理するために、複数のモジュール中の第２モジュールを特定する。オーケストレーションモジュールは、第２モジュールがそのリクエストの一部を処理することを引き起こす。第２モジュールがリクエストの一部を処理し終えた後、オーケストレーションモジュールは、第１モジュールがそのリクエストの処理を続けるようにする。この場合、第１モジュール及び第２モジュール間での１つ以上の（間接的な）やりとりは、先行するバージョンと現在のバージョンとの間の差異を補う。
【００１２】
別の技法によれば、WSAはそのWSAにより提供されるサービスを求めるリクエストを受ける。WSAは、現在のバージョンのWS標準仕様に先行しているかもしれない特定のバージョンのWS標準仕様を実現する。リクエストは、その特定のバージョンでサポートされていないフィールドを特定する。マッピングに基づいて、そのフィールド値は、デバイスのファームウエア構成要素が処理できるデータに変換される。ファームウエア構成要素はそのデータに基づいてリクエストを処理する。
【発明を実施するための最良の形態】
【００１３】
本発明は添付図面と共に非限定的な実施例により説明される。図中、同様な参照番号は同様な要素を指す。
【００１４】
以下の説明では、説明の目的で多くの具体的詳細が記述され、本発明の十分な理解を促す。しかしながら本発明はそれらの具体的詳細によらず実施されてもよいことは明らかであろう。また、本発明を不必要に曖昧にすることを避けるため、周知の構造や装置はブロック図形式で示される。
【００１５】
以下のように構成された章立てで説明がなされる：
１．０ アーキテクチャ概要
１．１ クライアント
１．２ ネットワーク
１．３ デバイスファシリティマネジャ
１．４ WSDマネジャ
１．４．１ ゼネラルAPI
１．４．２ ゼネラルAPI実現手段
１．５ ウェブサービスアプリケーション
１．５．１ アブストラクトAPI
１．５．２ アブストラクトAPI実現手段
２．０ 総括
３．０ オーケストレーションモジュール
４．０ ウェブサービスアプリケーションを拡張モジュールと共に拡張すること
５．０ 以前には関連していなかったモジュールを接続することでウェブサービスアプリケーションを拡張すること
６．０ ウェブサービスアプリケーション及びデバイス性能間の相違に対処すること
７．０ ウェブサービス仕様とは分離したウェブサービスアプリケーションロジックを構築すること
８．０ 実現手段
【実施例１】
【００１６】
１．０ アーキテクチャ概要
図１は、SOAPリクエストを処理する本発明の一実施例によるアーキテクチャ例100を示すブロック図である。アーキテクチャ100は、クライアント102、アドミニストレータ104、デバイスファシリティマネジャ(DFM)106及びMFPで動作する複数のウェブサービスアプリケーション108を含む。
【００１７】
図１に示されるように、MFPは任意数の異なるプラットフォーム（例えば、レガシープラットフォーム130、リナックスベースのプラットフォーム140及びVxWorksベースのプラットフォーム150等）を有し、通常MFPは唯１つのプラットフォームを有する。MFPが印刷サービスを含んでいた場合、そのプラットフォームは印刷エンジンを含む。同様に、MFPがスキャンサービスを含んでいた場合、少なくとも１つのプラットフォームはスキャンエンジンを含む。
【００１８】
ディスカバリリクエスト、クライアント102からのメタデータリクエスト、及びアドミニストレータ104からのコンフィギュレーションその他のMFP管理リクエストに応答することで、DFM106はMFPを代表する。DFM106は、WSディスカバリ112及びWS-MeX(即ち、WS-MetadataExchange(WSメタデータイクスチェンジ))のような複数のウェブサービス仕様を実現する際のリポジトリとして機能する。
【００１９】
MFPで動作する各WSA108は、例えばSOAPプロトコルを使って、サービスを要求するクライアント102にサービスを提供する。ターゲットプラットフォームとは独立に、アブストラクトAPI124のようなサービス固有のアブストラクトAPIを、各WSA108は使用してもよい。更に各WSA108はWS-Eventing(WSイベンティング)122を実現してもよい。
【００２０】
、ディスカバリリクエスト又はディスカバリハロー(HELLO)メッセージを介して（即ち、同じネットワーク上で、MFPを通知するメッセージをデバイスにブロードキャスト又はマルチキャストすることで）、クライアント102はMFPが存在することを発見してもよい。いったんクライアント102がMFPの存在に気付くと、クライアント102はデバイスメタデータ交換リクエストを、例えばWA-MetadataExchangeを介して送信し、MFPが提供する総てのサービスを発見する。デバイス全体について作用するDFM106は、そのリクエストを受けて、MFPにより提供される様々なサービスを記述するメタデータを返す。 WSA108のようなMFPで動作する特定のWSAからのサービスメタデータを、クライアント102は要求してもよい。WSA108はウェブサービスデバイス(WSD)マネジャ110からのサービスメタデータを要求し、WSDはサービスメタデータをWSA108に返してもよい。WSA108はサービスメタデータをクライアント102に転送する。
【００２１】
或いは、MFPのデバイスメタデータ及び１つ以上のWSAのサービスメタデータは、同じレスポンスでクライアント102に送信されてもよい。
【００２２】
サービスメタデータに基づいて、WSA108により提供されるサービスに対応するSOAPリクエストをクライアント102が生成及び送信し、そのリクエストをWSA108が受信及び処理する。サービスリクエストに基づいて、WSA108はアブストラクトAPIを用いて、アブストラクトAPIの実行に対するプラットフォーム固有の呼び出しを行う（例えば、アブストラクトAPI実現手段144を呼び出す）。このように、WSA（例えば、WSA108）の開発者は、ウェブサービスが動作する前提のプラットフォームの詳細情報を必要とせずに、ウェブサービス自体の開発に焦点を合わせてよい。従って、ターゲットプラットフォームに関する知識を備えたWSA開発者以外の誰でもが、関連するアブストラクトAPIの実現手段を規定してよい。
【００２３】
１．１ クライアント
クライアント102はあるアプリケーションであり、MFPにより提供される１つ以上のサービスを要求するプロセスに関連付けられる。クライアント102は、一般的には、初期のプロセス要求をサポートするオペレーティングシステムに関連するアプリケーションである。クライアント102の目的は、プロセスを要求することに起因するプラットフォーム固有のプロシジャコールを、SOAPを「理解」できるアプリケーションで処理可能なSOAPリクエストに変換することである。
【００２４】
例えば、プロセスのリクエストはマイクロソフトワードアプリケーションに関連付けられ、WSA108は印刷サービスを提供してもよい。クライアント102は、初期のプロセス要求をサポートするオペレーティングシステムに関連するアプリケーションでもよい。クライアント102は、プロセスリクエストに起因して送信されたプラットフォーム固有の「印刷データ」を受信する。クライアント102はSOAPメッセージの印刷データリクエストをエンコードし、SOAPメッセージは、SOAPメッセージを「理解」できるWSA108により処理可能である。
【００２５】
１．２ ネットワーク
クライアント102及びMFP間のSOAP通信は、（不図示の）ネットワークを介してなされてもよい。ネットワーク内の様々なノード間でデータ交換可能な如何なる媒体や手段によって、そのネットワークが実現されてもよい。そのようなネットワークの具体例は、限定ではないが、ローカルエリアネットワーク(LAN)、広域ネットワーク(WAN)、イーサーネットやインターネット、又は１つ以上の地上、衛星若しくは無線のリンク等を含む。ネットワークは上述したようなものの組み合わせを含んでもよい。ネットワークは、伝送制御プロトコル(TCP)、ユーザデータプロトコル(UDP)及び／又はインターネットプロトコル(IP)等に従ってデータを送信してもよい。
【００２６】
１．３ デバイスファシリティマネジャ
DFM106は、ディスカバリリクエスト、情報のロギングリクエスト及びコンフィギュレーション命令を受け入れることでMFPを代表する。一実施例によれば、DFM106は、複数のウェブサービス(WS)仕様を実現する際のリポジトリとして機能する。従って、DFM106はルーチンの共有ライブラリを含み、各ライブラリは、１つ以上のWS標準仕様(例えば、WS-Security(WSセキュリティ)、WS-MetadataExchange)で規定されている１つ以上の機能を実行する。このように、複数のWS標準仕様がいったん実現され、MFPで動作する複数のウェブサービスアプリケーション(即ち、WSA108)の各々で共有される。その結果、WSAの開発者は、DFM106に実装される如何なる仕様についても多くの詳細を知る必要はなく、その仕様を利用でき且つ当てにしてよい。DFM106に実装されるいくつかのWS標準仕様は、限定ではないが、WS-Discovery(WSディスカバリ)112、WS-Transfer(WS転送)114、WS-MeX(即ち、WS-MetadataExchange)116及びWS-Security118等を含んでよい。
【００２７】
一実施例では、DFM106は、SOAPプロトコルに対応するライブラリルーチンを含む。各SOAPライブラリルーチンは、１つ以上のSOAP仕様で規定されている１つ以上の機能を実現する。SOAPライブラリルーチンは、SOAPリクエストを分析し、SOAPメッセージをまとめる(パッケージする)のに使用される。従って、各WSA108はDFM106から1つ以上のSOAPライブラリルーチンを起動し、SOAPライブラリルーチンが一度規定され、MFP上で動作する総てのWSA108の間で共有されるようにする。複数のバージョンのSOAPプロトコル標準仕様がサポートされてもよい。WSA108に対する一切の修正なしに又はほとんどなしに、新しいバージョンのSOAPプロトコル標準仕様への更新は行われる。
【００２８】
一実施例では、クライアントアプリケーション(例えば、クライアント102)は、MFPで１つ以上のWSAを更新することに関する情報を受けるように登録してもよい。特定のアプリケーションの更新に関する更新情報をDFM106が受信し、且つクライアントアプリケーションがそのような更新を示す情報を受けるように登録されていた場合、その更新情報を示すメッセージをDFM106はクライアントアプリケーションに送付する。関連する実施例では、クライアント102はそのような更新通知を受けるように登録（例えば、加入）する必要はない。むしろ、１つ以上のWSAに対して、更新を示すメッセージを自動的にブロードキャストするようにDFM106が構築されてもよい。
【００２９】
一実施例では、DFM106はWSAに関する更新情報を受信してもよい。例えば、WSA108はファックスサービスを提供しているが、MFPはファックス回線が切断されていることを検出するかもしれない。ファックスサービスが利用可能でない場合、MFPがファックスサービスを提供することを示すデバイスメタデータと共に、DFM106は将来的なメタデータリクエストに応じるべきではない。従って、WSAから更新情報を受けたことに応じて、WSAに関連するサービスメタデータ及び／又はデバイスをDFM106は更新する。
【００３０】
一実施例では、DFM106はアドミニストレータアプリケーション(例えば、アドミニストレータ104)からコンフィギュレーションリクエストを受信してもよい。コンフィギュレーションリクエストは、構築される及び／又は更新される１つ以上のWSAを示す。DFM106は、コンフィギュレーションリクエストを処理し、適切なWSAにおけるコンフィギュレーション又は更新指示を実行する又は実行させる。或いは、以下で更に詳細に説明されるように、DMF106はそのようなコンフィギュレーションリクエストを処理するようにWSDマネジャ110を指示する。
【００３１】
一実施例では、DFM106はアドミニストレータアプリケーション(例えば、アドミニストレータ104)からのリクエストを受信し、リクエストの記録に応じる。DFM106は、MFPで動作する１つ以上のWSAに関するロギング情報を取り出し、ロギング情報をアドミニストレータ104に送信する。以下で更に詳細に説明されるように、WSDマネジャ110はロギング情報を取り出してDFM106に与える。
【００３２】
１．４ WSDマネジャ
一実施例によれば、DFM106はWSDマネジャ110を有する。WSDマネジャ110は、情報の記録、ステータスの問い合わせ、及び（アドミニストレータ104からのような）MFPの外部管理に関する中央局又はセントラルポイントをもたらす。アドミニストレータ104は、WSDマネジャ110を介してMFPに関する情報を取り出すよう構築されたアプリケーションである。例えば、総てのWSA108から及びWSA108が動作する様々なプラットフォームから内部的に到来する総てのロギング情報を、WSDマネジャ110は集めてもよい。アドミニストレータは、WSDマネジャ110を用いてWSA108を構築、更新又は不活性化(ディセーブルに)してもよい。
【００３３】
一実施例では、どこにMFPが位置するか、どんなWSAがMFPにインストールされているか、WSAは適切に動作しているか否か等のような全体的な状態情報を、WSDマネジャ110は維持する。
【００３４】
一実施例では、MFPで動作している各サービスアプリケーションに関するサービスメタデータ及びMFPについてのメタデータを、WSDマネジャ110は維持する。
【００３５】
１．４．１ ゼネラルAPI
一実施例によれば、WSDマネジャ110はMFPに関する一般的な情報（例えば、MFPのモデル番号やIPアドレス等）をゼネラルAPI120を介して取り出す。ゼネラルAPI120は或るインターフェースを規定し、そのインターフェースにより、DFM106はMFPのプラットフォーム各々に固有の情報を受け取る。このようにして、DFMの開発者は、特定のプラットフォームの詳細を知る必要はなく、或るMFPについてその開発者が構築しようとしているDFMの詳細だけを知っていればよい（図１の波線は、特定のAPIから対応するAPI実現手段へのAPIコールである。）。
【００３６】
１．４．２ ゼネラルAPI実現手段
ゼネラルAPI120がDFM106について規定されていた場合、特定のプラットフォームに関するゼネラルAPI120の実現手段が規定される。例えば、ゼネラルAPI実現手段132が、レガシープラットフォーム130におけるゼネラルAPI120について規定される。同様に、ゼネラルAPI実現手段142が、リナックスベースのプラットフォーム140におけるゼネラルAPI120について規定される。関連するゼネラルAPI実現手段は、デバイス固有のリクエストで指定され及びMFPで実現される機能を規定する。
【００３７】
１．５ ウェブサービスアプリケーション
ウェブサービスアプリケーション(WSA)108は、1つ以上のモジュールを有する。WSA108は、１つ以上のウェブサービスを提供し、ウェブサービス(WS)プロトコル及びテクノロジ（例えば、DFM106で提供されているプロトコル等）を当てにしている。1つ以上のモジュールは、ハードウエア回路で、コンピュータソフトウエアで、或いはハードウエア回路及びコンピュータソフトウエアの組み合わせで実現されてもよく、特定のハードウエアの手段にも特定のソフトウエアの手段にも限定されない。WSA108がSOAPリクエストを分析するロジックを含んでいなかった場合、SOAPリクエストを分析するために、WSA108は、別個のSOAPモジュール(図示せず)も当てにしている。上述したように、別個のSOAPモジュールは、DFM106により用意され、総てのWSA108の間で共有されてもよい。
【００３８】
WSA108は、クライアント102からのイベントリクエストに応答するWSイベンティングモジュール122も有する。クライアント102は、WSA108により提供されるサービスに関連するイベントに加入してもよい。例えば、WSA108が印刷サービスを提供しており、クライアント102が加入するイベントは、WSA108に関するMFPが印刷ジョブを完了したことでもよい。こうして、印刷ジョブが完了した際、WSA108は、印刷ジョブが完了していることを示すイベントメッセージをクライアント102に送信する。
【００３９】
WSAは１つ以上のサービスを提供するために１つ以上のWS標準仕様に基づいて開発及び実現されてもよい。スキャンサービスについて或るWSが存在し、印刷サービスについて別のWS標準仕様が存在し、アーカイブサービスについて別のWS標準仕様が存在し、ファクシミリサービスについて別のWS標準仕様が存在するかもしれない。
【００４０】
ここで使用されるように、WSAが基づいている古いバージョンのWS標準仕様は「旧バージョン」と言及され、現在のバージョンのWS標準仕様は「新バージョン」と言及される。
【００４１】
リクエストを処理した結果、電子書類を印刷したり、イベント加入リクエストに対する応答を送信するような１つ以上のアクションを、WSAは実行する。SOAPリクエストかもしれないリクエストが、クライアント(例えば、クライアント102)から到来し、或いはMFPのタッチパネルディスプレイと共にインターフェースをとるユーザから到来するかもしれない。
【００４２】
１．５．１ アブストラクトAPI
WSA108はアブストラクトAPI(例えば、アブストラクトAPI124)も有し、そのアブストラクトAPIを介してプラットフォーム固有のコールが生成される。アブストラクトAPIは或るインターフェースを規定し、そのインターフェースにより、関連するWSA108はMFPに関する１つ以上の機能を起動する。
【００４３】
１．５．２ アブストラクトAPI実現手段
アブストラクトAPIがウェブサービスアプリケーション開発者により規定されていた場合、特定のプラットフォームについてそのアブストラクトAPIの実現手段が規定されている。例えば、アブストラクトAPI実現手段154は、VxWorksプラットフォーム150でのアブストラクトAPI124に備えて規定される。関連するアブストラクトAPI実現手段は、プラットフォーム固有のリクエストで指定され且つMFPに実装されている機能を規定する。
【００４４】
２．０ 総括
ウェブサービスシステムを拡張する技法が提供される。例えば、現在のバージョンより前のバージョンのWS標準仕様を、WSAは実装しているかもしれない。以前のバージョンではない現在のバージョンに従うリクエストをサポートするため、或るいは以前のバージョンにはない現在のバージョンの特性を参照するリクエストをサポートするため、好ましくはWSAの基本的なロジックを修正せずに、WSAは拡張される必要がある。
【００４５】
ウェブサービスシステムが現在のものであることをクライアントに示すため、WSAにより提供されるサービスを記述するWSDLファイルは、現在のバージョンのWS標準仕様を反映するように更新されてもよいし、或いはWSAが動作する装置の能力を反映するように更新されてもよい。クライアントがWSDLファイルを要求する際、クライアントは、WSAがどの特性をサポートしているかを知っている。本発明の様々な実施例により達成される利点の１つは、中断時間なしにユーザの処理に影響せずに、既存のWSAが再利用されてよいことである。
【００４６】
３．０ オーケストレーションモジュール
本発明の一実施例によれば、オーケストレーションモジュールが、MFPで動作する1つ以上のWSAについて用意される。オーケストレーションモジュールは、WSAの基本ロジックを修正せずに、WSAを拡張する責務を有する。オーケストレーションモジュールは、ルールベース(rule-based)でもよいし、オブジェクト指向階層に従って設計されてもよい。オーケストレーションモジュールは、印刷サービスモジュール、井部ティングサービスモジュール、スキャニングサービスモジュール及びアーカイブサービスモジュールの間でのやりとりを制御する。オーケストレーションモジュールは、単なる連鎖的な拡張モジュールでは達成できない柔軟性をもたらす。例えば、オーケストレーションモジュール内で示されるルールエントリが構築可能である。こうして、動作が実行時に修正され、拡張モジュール及び複数のモジュールを協調させる。また、新たなルールが実行時に追加されてもよい。
【００４７】
図１に示されるように、各WSA108はオーケストレーションモジュール126を有する。しかしながら、別の実施例では、デバイスが複数のWSAを有していた場合、オーケストレーションモジュール126が複数のWSAの中で共有されてもよく、その場合、オーケストレーションモジュール126は論理的にはDFM106の中にあってもよい。
【００４８】
図２は、リクエストを処理する本発明の一実施例によるオーケストレーションモジュール例126を示すブロック図である。オーケストレーションモジュール126は３つの列を含むテーブルを有し、その列は、キーフィールド列202、コンテキスト列204及びアクション列206である。そしてオーケストレーションモジュール126のテーブルは、図示の３つ組を４つ有する。３つ組の各々はキーフィールド値、コンテキスト値及びアクション値を有する。しかしながら他の実施例におけるテーブルは、２列でもよいし、４以上の列を含んでもよい。例えばテーブルはキーフィールド列202及びアクション列206だけを含んでもよい。
【００４９】
オーケストレーションモジュール126のテーブル中の各行に関し、キーフィールド列202は、あるリクエスト中の１つ以上のフィールドを示し、そのリクエストは、関連するアクションモジュール206で示されている１つ以上のモジュールの動作にトリガを与える。
【００５０】
コンテキスト列204は１つ以上のコンテキストを示し、そのコンテキストの中で、実行される１つ以上の対応するモジュールに備えて、対応するキーフィールドが少なくとも論理的に位置付けられている。「コンテキスト(context)」は、リクエストの中で対応するフィールドの論理的なロケーションを示す。オーケストレーションモジュール126がコンテキスト列204を含んでいた場合、対応するフィールドが、リクエストの適切なコンテキスト内に位置していた場合にのみ、アクションモジュール206で特定される１つ以上のモジュールが実行される。従って、あるコンテキストにおけるあるキーフィールドが或るアクション群にトリガを与えるかもしれないが、異なるコンテキスト中の同じキーフィールドは異なるアクション群にトリガを与える。
【００５１】
関連する実施例では、キーフィールド列202又はコンテキスト列204は、対応するフィールドに関連するネームスペース(namespace)を示す。例えば、ネームスペースが「Richo」(リコー)であり、優先度(プライオリティ)フィールドを規定するのにリコーのスキーマが使用されることを示す。
【００５２】
図２に示されるように、最初の３つ組は、「プライオリティ」を表すキーフィールド202の値、「SOAPヘッダ」を表すコンテキスト204の値、及び「プライオリティ処理モジュール、サービスモジュール」を表すアクション206の値を有する。「サービスモジュール」は、印刷、スキャニング、ファクシミリ送受信、複写又はアーカイブ等のような特定のMFPサービス212を実行するWSAに関連する。SOAPリクエストがオーケストレーションモジュール126に伝送され、オーケストレーションモジュール126が、リクエストはSOAPリクエストのヘッダ部分に「プライオリティ」フィールドを含んでいることを確認した場合、プライオリティ処理モジュールが呼び出される。プライオリティ処理モジュールがリクエストを処理し終えると、実行結果はオーケストレーションモジュール126に戻され、オーケストレーションモジュールは処理を続けるために適切なサービスモジュールを呼び出す。
【００５３】
最後の３つ組は、「期間経過」（有効期間又は期限切れ）を表すキーフィールド202の値、「SOAPヘッダ」を表すコンテキスト204の値及び「タイムモジュール、サービスモジュール」を表すアクション206の値を含む。この３つ組の場合、SOAPリクエストがオーケストレーションモジュール126に伝送された場合であって、オーケストレーションモジュール126がそのリクエストはSOAPリクエストのヘッダ部分に「期間経過」フィールドを含んでいることを確認した場合、タイムモジュールが呼び出される。タイムモジュールが偽（フォールス）を返した場合、オーケストレーションモジュール126は更なる処理に備えたサービスモジュールを呼び出さないであろう。そうでなかった場合、タイムモジュールがリクエストを処理した後、オーケストレーションモジュール126はそのリクエストを処理するために適切なサービスモジュールを呼び出すであろう。
【００５４】
４．０ ウェブサービスアプリケーションを拡張モジュールと共に拡張すること
一実施例では、WSA及び拡張モジュール間の相互作用をオーケストレーションモジュール126が管理し、拡張モジュールは、旧バージョンのWS標準仕様には無い新バージョンのWS標準仕様の特徴機能を実行する。現在動作しているWSAを修正もせず影響も与えないようにするため、オーケストレーションモジュールは、配備されているWSAと1つ以上のプラグイン拡張モジュールとの間のやりとりを調整する。SOAPリクエスト中の「プライオリティ」フィールドのような新たな特徴事項を適切に処理するため、一連の処理チャネル（即ち、ハンドル）がWSA処理ロジックのある場所に加えられる。
【００５５】
図３は、本発明の一実施例により、リクエスト中の「プライオリティ」フィールド（WSAでは認識できない）を処理する際、オーケストレーションモジュールが如何に使用されるかを示すフローチャートである。本発明の場合、WSAプロセスは、WSAが基づいているWS標準仕様に従って、FIFO(先入れ先出し)を要求する。その標準仕様は、プライオリティフィールドを含むリクエストを如何に処理するかについては規定していない：従って、WSAはプライオリティフィールドを含むリクエストを処理するロジックを含んでいない。従って、WSAがプライオリティフィールドを伴うリクエストに遭遇した場合、WSAはそのプライオリティフィールドを単に無視する。
【００５６】
プライオリティフィールドを含むリクエストを処理し、指定されたプライオリティに基づいてリクエストを処理するため、拡張モジュール（この場合、「プライオリティ処理モジュール」と言及される）が装置に加えられる。
【００５７】
更に図３を参照するに、ステップ302において、クライアントからWSAにてリクエストが受信される。ステップ304では、リクエストを処理するため、WSAに関連するオーケストレーションモジュールが呼び出される。メッセージは、WSAにより又はオーケストレーションモジュールにより分析され、フィールド照合はオーケストレーションモジュールにより実行される。従ってオーケストレーションモジュールは、プライオリティフィールドがリクエストの中に含まれているか否かを確認する。プライオリティフィールドがリクエスト中に見出されなかった場合、プロセスはステップ314に進み、WSAが(即ち、FIFOで)リクエストを処理する。プライオリティフィールドがリクエスト中に含まれていることをオーケストレーションモジュールが確認した場合、プロセスはステップ306に進む。
【００５８】
一実施例では、ステップ304において、プライオリティフィールドが適切なコンテキストの中に存在するか否かを（例えば、図２のオーケストレーションモジュール126により）更に確認する。例えば、リクエストがSOAPリクエストであり、プライオリティフィールドがSOAPリクエストのボディ部分(本体部分)に含まれているが、SOAPリクエストのヘッダ部分内には含まれていなかった場合、そのプライオリティフィールドはオーケストレーションモジュールによって無視され、プロセスはステップ314に進む。しかしながら、プライオリティフィールドのコンテキストが適切であった場合、即ち、プライオリティフィールドがSOAPリクエストのヘッダ部分に含まれていた場合、オーケストレーションモジュールは、SOAPリクエストのプライオリティフィールドを処理するようにプライオリティ処理モジュールを促し、プロセスはステップ306に進む。
【００５９】
ステップ306では、プライオリティ処理モジュールは、WSAが維持しているリクエスト処理キューが空になっているか否かを確認する。空になっていれば、プロセスはステップ314に進み、プライオリティ方式のキュー処理は不要である。
【００６０】
リクエスト処理キューが空でなければ、ステップ308において、プライオリティ処理モジュールは、例えばリンクしたリストを維持し、「プライオリティ」フィールド値に基づいてリクエストを処理し、WSAのリクエスト処理キューが空になるまで待機する。
【００６１】
ステップ310では、リンクしたリストのヘッダでリクエストを処理するようにWSAが呼び出される。ステップ312では、WSAがリクエストを処理し終えた後に、そのリクエストを送信したクライアントに或る応答が送信される。
【００６２】
かくしてプライオリティ処理モジュールだけがプライオリティフィールドのビジネスロジックに気付いている。プライオリティ処理モジュールがWSAにプラグインされる場合でさえ、WSAは修正されずそのまま動作し続ける。
【００６３】
５．０ 以前には関連していなかったモジュールを接続することでウェブサービスアプリケーションを拡張すること
一実施例では、オーケストレーションモジュールは、MFPで動作する様々なモジュール間のやりとりを管理し、そのやりとりは、旧バージョンには無かった新バージョンのWS標準仕様の１つ以上の特徴機能を構築する。例えば、MFPはスキャンサービス及びイベンティングサービスを含み、それらは独立に開発され、互いに如何なる相互作用もなしに開発されている。以後、スキャンサービスについての新バージョンのWS標準仕様が、スキャン宛先登録情報はイベント加入リクエストメッセージに組み込まれてよいことを表す。イベンティングサービス又はスキャンサービスを修正する代わりに、或るエントリがオーケストレーションモジュールに加えられ、それに従ってイベント加入リクエストの処理手順を決める。
【００６４】
図４は、イベント加入リクエストに組み込まれているスキャン宛先登録を処理する本発明の一実施例によるフローチャートである。ステップ402では、１つ以上のモジュールとして動作するイベントサービスは、クライアントからイベント加入リクエストを受信する。そして、イベンティングサービスは、オーケストレーションモジュール(例えば、オーケストレーションモジュール126)を呼び出す。ステップ402の一部分として、イベンティングサービスは、イベント加入リクエストが適切にフォーマットされているか否かを(例えば、WSイベンティング標準仕様に従って)確認する。適切にフォーマットされていなければ、イベンティングサービスは、偽メッセージをクライアントに送信する。
【００６５】
代替実施例では、オーケストレーションモジュールはイベンティングサービスを含むWSAの総てのモジュールの前に配置される。この場合、オーケストレーションモジュールは、クライアントからリクエストを受信し、呼び出すモジュールを判定する。
【００６６】
ステップ404では、オーケストレーションモジュールは、イベント加入リクエストがスキャン宛先登録を(例えば、図２に示されるような適切なコンテキストで)含んでいるか否かを確認する。含んでいなかった場合、堀はステップ414に進み、オーケストレーションモジュールはイベンティングサービスを呼び出し、既存のロジックに従ってリクエストを処理する。しかしながら、イベント加入リクエストはスキャン宛先登録を含んでいることをオーケストレーションモジュールが確認した場合、プロセスはステップ406に進む。
【００６７】
ステップ406では、オーケストレーションモジュールは、スキャンサービスを呼び出し、スキャン宛先登録情報を予備的に処理する。予備的な処理は多くのステップを含んでよく、例えば、スキャン宛先ディスプレイ名を有効化することや、宛先登録の最大数に圧したか否かを確認することを含んでよい。宛先登録の最大数は、デバイスの側で予め決められる。別の処理例として、スキャンサービスは宛先トークンを作成し、スキャン宛先登録リクエストを認識する（そのトークンは後のジョブ生成に使用される。）。スキャンサービスは宛先トークンをイベンティングサービスへ加入者応答の一部として伝送する。ジョブ生成の際クライアント及びスキャンサービス間のハンドシェーキング情報として、スキャン宛先関連イベント中の他のフィールドと共に宛先トークンが後に使用される。特定のスキャン宛先が例えばスキャンオペレーショナルパネル等から選択される場合、スキャン宛先関連イベントは、スキャンサービスにより生成される。
【００６８】
ステップ408では、スキャンサービス処理が成功したか否かを、スキャンサービスは確認する。成功していなかったならば、クライアントに偽(フォールト)が返される（ステップ418）。予備処理は不成功の一例は、イベント加入リクエスト内で指定されている宛先数が宛先登録の最大数を超えていた場合に生じる。予備処理不成功の別の例は、スキャンサービスがスキャン宛先登録情報を認識しなかった場合である。
【００６９】
スキャンサービス処理が成功した場合、プロセスはステップ410に進む。ステップ410では、スキャンサービスは、予備処理による何らかの出力をオーケストレーションモジュールに伝送し、オーケストレーションモジュールは、そのような情報をイベントサービスに伝送して加入者管理処理に備える。しかしながら、図２に示されるように、加入者管理モジュールはイベントサービスから独立していてもよい。その場合、オーケストレーションモジュールは、スキャンサービスの予備処理の出力を、加入登録に備えてイベントサービスに伝送する。以後、イベンティングサービスは作成した加入情報を加入管理モジュールに転送し、加入管理処理に備える。
【００７０】
イベンティングサービス(又は加入管理モジュール)が加入管理処理を終了した後、オーケストレーションモジュールは、スキャン宛先管理のような事後処理に備えてスキャンサービスを呼び出す(ステップ412)。例えば、スキャンサービスは、加入リクエスト内で指定されている宛先を、将来の利用に備えてローカルメモリの宛先リストに(例えば、宛先マネジャを使って)追加して保存してもよい。
【００７１】
ステップ412で事後処理を行う理由の１つは、イベンティングサービスが、イベント加入リクエストに対する加入応答を作成する際、イベンティングサービスで作成されたデータをスキャンサービスが利用しなければならないかもしれないからである。例えば、スキャンサービスは加入識別子を追跡する必要があり、イベンティングサービスは受け入れた加入を一意に識別するようにその加入識別子を生成する。従って事後処理は事前処理(予備処理)と組み合わせるべきではない。
【００７２】
ステップ412で事後処理を行う別の理由は、不要な処理工程を避けるためである。ステップ406の途中で又はその前に、イベンティングサービスがイベント加入リクエストを(例えば、WSイベンティング標準仕様に基づいて)有効化しているかもしれない。加入応答メッセージを作成する前に、そのイベント加入リクエストが無効であることを、イベンティングサービスが確認していた場合、イベンティングサービスは偽メッセージを作成し、その偽メッセージをクライアントに送付する。オーケストレーションモジュールはエラーの通知を受け、関連する処理を中断する：即ち、加入管理モジュールもスキャンサービスも呼び出されない。イベンティングサービスはそのエラーをスキャンサービスに通知すべきではない。なぜならそのようなサービスは互いに透明であるべきだからである。そのようなサービスはオーケストレーションモジュールの支援と共にのみ相互作用する。
【００７３】
イベント加入リクエストの処理から予備的な及び事後的な処理を分離することは、イベントサービス及びスキャンサービスのモジュール性を維持しつつ、柔軟性及び拡張性を最大化する。このように、イベントサービスもスキャンサービスも互いのデータスキーマやビジネス論理を詳細に理解することを要しない。
【００７４】
ステップ412の事後処理の後、イベンティングサービスはイベント加入応答を作成し、それをクライアントに送る(ステップ416)。オーケストレーションモジュールが総てのサービスの上にあり且つリクエストメッセージを受けた場合、オーケストレーションモジュールは、スキャンサービスの事後処理の後にその応答を返す。イベンティングサービスがクライアントリクエストを受け、その後に、可能性のある更なる処理に備えてオーケストレーションモジュールを呼び出した場合、イベンティングサービスは加入応答をクライアントに送る。
【００７５】
このように、既存のどのサービスも修正せずに、指定された方法でサービスを組み合わせることで、リクエストメッセージが処理される。
【００７６】
６．０ ウェブサービスアプリケーション及びデバイス性能間の相違に対処すること
別の実施例では、WSAが動作するデバイスで提供される特徴機能とWSAとの間の不一致が取り扱われる。比較的容易なワークフローやビジネス論理のカスタマイズを可能にするように、WSAは設計される。クライアントからのリクエストは、WSAが基づいているWS標準仕様で規定されていないフィールド（及びフィールド値）を含むかもしれない。しかしながらこのフィールド値は、デバイスのファームウエア構成要素によって認識可能である。
【００７７】
例えば、図１に示されるように、WSA108はアブストラクトAPI124を有し、そのアブストラクトAPIを介してプラットフォーム固有のコールが生成される。アブストラクトレイヤ124は或るインターフェースを規定し、そのインターフェースによって、WSA108は前提としているプラットフォームとインターフェースをとり、サービス（例えば、印刷サービス）を提供する。そして、アブストラクトAPI実現手段144は、リナックスベースのプラットフォーム140に関するアブストラクトAPI124に備えて用意される。アブストラクトAPI実現手段154は、VxWorksプラットフォーム150に関するアブストラクトAPI124に備えて用意される。
【００７８】
(デバイスが処理可能な)クライアントリクエストの総ての部分が適切に処理されることを保証するため、リクエストの内認識でない部分を適切なアブストラクトAPI実現手段に伝送するフック(hook)をWSAは用意する。マッピングテーブルは、リクエストで指定されている値(WSAが基づいている標準仕様では言及されていない値)と、アブストラクトレイヤが認識する値とを関連付ける。そのマッピングテーブルはオーケストレーションモジュール内にあってもよいし、それ以外の場所にあってもよい。例えば、アブストラクトレイヤがWSAの内蔵構成要素(ビルトインコンポーネント)であった場合、WSAはそのマッピングテーブルを使って、クライアントの要求値をアブストラクトレイヤで認識される値に変換する。他の例では、アブストラクトレイヤはWSAとは別個のモジュールであり、オーケストレーションモジュールはそのマッピングテーブルにより値を照合する。アブストラクトAPI実現手段に追加的な特徴が加えられる場合、唯一マッピングが更新されることを要するかもしれない。このように、WSAは更新されることを要しない。
【００７９】
例えば、或るバージョンのスキャンサービス標準仕様(旧バージョン又は新バージョン)は、両面原稿のページ開き方向を規定していない。しかしながら、スキャン装置は両面原稿について「表から表へ(Top To Top)」及び「表から裏へ(Top To Bottom)」のページ開き方向をサポートしている。この例の場合、WSAは或る特定のバージョンのスキャンサービス仕様に基づく。WSAは或るフィールドを含むリクエストを受信し、そのフィールドは「表から表へ」の値に関連する両面原稿のページ開き方向を示す。「表から表」を(スキャン装置の)スキャンエンジンが処理できるデータに変換するように、マッピングテーブルは(例えば、WSAにより)求められる。データは例えば“T2T”でもよい。デバイスのファームウエア構成要素は、両面原稿書類に関する「表から表」のページ開き方向に従って、１つ以上の処理をスキャンすることで“T2T”を処理することができる。後に、新たなバージョンのスキャンサービス仕様が、ページ開き方向をサポートするように加わった場合でも、旧バージョンの仕様に基づいていたWSAは修正されることを要しない。
【００８０】
７．０ ウェブサービス仕様とは分離したウェブサービスアプリケーションロジックを構築すること
本発明の一実施例によれば、WS標準仕様の中核的な(コアの)ビジネスロジックを、WS標準仕様のバージョン固有の情報から分離するように、WSAのロジックが始めに構築される。そして、バージョン固有の制約及び／又はデータスキーマ確認が１つ以上の拡張モジュールに課せられる一方、WSAは中核的なビジネスロジックを含む。そして、WSAの前提となるコードを修正することなく、WSAは再利用される。
【００８１】
WS標準仕様のコアビジネスロジック(CBL)は、デバイス自体に関する動作を処理する。CBLは構文的な(シンタックスの)観点からリクエストを有効化するものではなく；前提とするデバイスの機能に基づいてリクエストが受入可能で処理可能か否かを、CBLは確認する。
【００８２】
プリンタに関するCBLの具体例は、印刷ジョブを生成すること、書類を印刷すること、情報(プリンタメタデータ、性能、デフォルトのプリントチケット、プリンタステータス、アクティブな印刷ジョブ、ジョブ履歴等の情報)を抽出すること、更には、印刷ジョブステータスイベント及び／又は他のプリンタ関連イベントを生成すること等を含む。スキャナに関するCBLの具体例は、スキャンジョブを生成すること、書類をスキャンすること、画像をクライアント／スキャン宛先に送ること、スキャンステータスイベント及び／又は他のスキャナ関連イベントを生成すること、及び情報(スキャナメタデータ、性能、デフォルトのスやンチケット、スキャナステータス、アクティブなスキャンジョブ、スキャンジョブ履歴等の情報)を抽出すること等を含む。
【００８３】
WS標準仕様のバージョン固有の制約(VSC)は構文的な(シンタックスの)制約であり、リクエストメッセージ及び応答メッセージの構成に関する各バージョンの仕様によって課せられる。VSCはデバイスの機能を取り扱うものではない。VSCの具体例は、リクエスト及び応答メッセージのSOAPヘッダ中のWS-Addressing(WSアドレッシング)アクションフィールドである。各バージョンのサービス仕様(例えば、印刷サービスやスキャンサービスの仕様)は、各オペレータのリクエスト及び応答メッセージのSOAPヘッダ中で異なるWSアドレッシングアクションフィールドを規定するかもしれない。VSCの別の具体例は、スキャン書類フォーマットが或るバージョンの標準仕様では選択的(オプション)であるが、別のバージョンの標準仕様では必須かもしれないことである。そのようなVSCは、WSAとは別の１つ以上の拡張モジュールによって処理及び強制され、潜在的な標準仕様の変化を適切に収容する。
【００８４】
データスキーマ確認モジュールは、リクエストで指定されているフィールドが１つ以上のデータスキーマに基づいて有効か否かを確認するモジュールである。例えば、データスキーマ確認モジュールは、SOAPリクエストが適切にフォーマットされているか否かを確認し、適切にフォーマットされていなかった場合、そのSOAPリクエストは除外され、エラーメッセージがクライアントに送付されてもよい。別の例として、印刷サービスに関連するデータスキーマ確認モジュールは、リクエストで指定されているフィールドが或る印刷標準仕様に基づいて有効であるか否かを確認する。或る無効なフィールドは無視され(即ち、WSAはそのリクエストを処理し続けてよい)、別の無効なフィールドは無視されない(例えば、WSAはエラーメッセージをクライアントに返す)。
【００８５】
一実施例では、WS標準仕様のコアビジネスロジックは、複数の実行ファイルとして実現される。関連する例の場合、WS標準仕様のコアビジネスロジックは、(静的な又は動的な)複数のライブラリルーチンを起動する１つの実行ファイルとして実現される。複数のライブラリルーチンを利用する利点は、プロセス間のやりとりを回避できることであり、プロセス間の通信は、複数のライブラリルーチンを起動することよりも遅くなりがちである。
【００８６】
８．０ 実現手段
上記の手法は如何なるタイプのコンピュータプラットフォーム又はアーキテクチャでも実現されてよい。図５は本発明の一実施例が使用されるコンピュータシステム５００を示すブロック図である。コンピュータシステム５００は、情報を通信するためのバス５０２又は他の通信手段と、バス５０２に結合された情報を処理するプロセッサ５０４とを有する。コンピュータシステム５００は、ランダムアクセスメモリ(RAM)又は他のダイナミックストレージデバイスのようなバス５０２に結合されたメインメモリ５０６を有し、メインメモリはプロセッサ５０４で実行される命令や情報を格納する。メインメモリ５０６は、プロセッサ５０４で実行される命令の実行中に、一時的な変数又は他の中間的な情報を格納するのに使用されてもよい。コンピュータシステム５００は、プロセッサ５０４のための命令や静的な情報を格納する、バス５０２に結合されたリードオンリメモリ(ROM)５０８又は他のスタティックストレージデバイスを更に含む。磁気ディスク又は他の光ディスクのようなストレージデバイス５１０は、情報及び命令を格納するために用意されてバス５０２に結合される。
【００８７】
コンピュータシステム５００は、ユーザに情報を表示するために、陰極線管(CRT)のようなディスプレイ５１２にバス５０２を介して結合されてもよい。英数字その他のキーを含む入力装置５１４は、情報及び命令選択内容をプロセッサ５０４に通知するためにバス５０２に結合される。他の種類のユーザ入力装置は、カーソル制御装置５１６（例えば、マウス、トラックボール、スタイラス又はカーソル方向キー）であり、指示情報及び命令選択をプロセッサ５０４に通知し且つディスプレイ５１２でのカーソルの動きを制御する。この入力装置は典型的には第１軸（例えば、ｘ）及び第２軸（例えば、ｙ）の２軸による２つの自由度を有し、装置が平面上の位置を指定できるようにする。
【００８８】
本発明は無線通信アーキテクチャのコンピュータシステム５００を利用することに関連する。本発明の一実施例によれば、メインメモリ５０６に含まれる１以上の命令の１以上のシーケンスを実行するプロセッサ５０４に応じて、無線通信がコンピュータシステム５００によって提供される。そのような命令は、ストレージデバイス５１０のような他のマシン読取可能な媒体からメインメモリ５０６に読み込まれてもよい。メインメモリ５０６に含まれている命令シーケンスの実行は、本願で説明されるプロセスステップをプロセッサ５０４が実行することを引き起こす。代替実施例では、本発明を実施するために、ハードワイヤード回路が、代替的に使用されてもよいし或いはソフトウエア命令との組み合わせで使用されてもよい。すなわち本発明の実施例はハードウエア回路及びソフトウエアの特定の如何なる組み合わせにも限定されない。
【００８９】
ここで使用されているように「マシン読取可能な媒体」なる用語は、特定の形式でマシンが命令を実行することを引き起こすデータを用意することに関与する如何なる媒体にも関連する。コンピュータシステム５００を使用する実施例の場合、様々なマシン読取可能な媒体が、例えばプロセッサ５０４の実行する命令を提供するように含まれる。そのような媒体は多くの形態をとってよく、限定ではないが、不揮発性媒体、揮発性媒体及び伝送媒体を含む。不揮発性媒体は、例えば、ストレージデバイス５１０のような光又は磁気ディスクを含む。揮発性媒体は、メインメモリ５０６のようなダイナミックメモリを含む。伝送媒体は、同軸ケーブル、銅線及び光ファイバを含み、バス５０２を構成するワイヤを含む。伝送媒体は、無線電波及び赤外線データ通信の際に生成されるもののような、音波又は光波の形式をとってもよい。
【００９０】
マシン読取可能な媒体の一般的な形態は、フロッピディスク、フレキシブルディスク、ハードディスク、磁気テープその他の如何なる磁気媒体、CD-ROMその他の如何なる光媒体、パンチカード、紙テープ又は穴のパターンを有する他の如何なる物理的媒体、RAM、PROM、EPROM、フラッシュEPROMその他のメモリチップ、カートリッジ、上記のような搬送波又はコンピュータが読み取ることの可能な他の如何なる媒体でも含む。
【００９１】
マシン読取可能な様々な形態は、１以上の命令の１以上のシーケンスをプロセッサ５０４に実行に備えて搬送する際にも適用可能である。例えば命令は初期には遠く離れたリモートコンピュータの磁気ディスクで搬送されてもよい。リモートコンピュータは自身のダイナミックメモリからその命令をロードし、モデムを用いて電話回線を介して命令を送信してもよい。コンピュータシステム５００付近のモデムは電話回線でそのデータを受信し、赤外線送信機を用いてそのデータを赤外線信号に変換する。赤外線検出器は、赤外線信号で搬送されたデータを受信し、適切な回路がそのデータをバス５０２に置く。バス５０２はデータをメインメモリ５０６に運び、プロセッサ５０４はメインメモリから命令を抽出して実行する。メインメモリ５０６で受信された命令は、プロセッサ５０４で実行される前又はその後にストレージデバイス５１０に選択的に格納されてもよい。
【００９２】
コンピュータシステム５００はバス５０２に結合された通信インターフェース５１８も含む。通信インターフェース５１８は、ローカルネットワーク５２２に接続されるネットワークリンク５２０に結合する双方向データ通信をもたらす。例えば、通信インターフェース５１８は、データ通信接続を対応するタイプの電話回線に与える統合サービスディジタルネットワーク(ISDN)カード又はモデムでもよい。別の例では、通信インターフェース５１８は、データ通信接続をコンパチブルなLANに与えるLANカードでもよい。無線リンクが使用されてもよい。どの実現手段でも、通信インターフェース５１８は、電気的な、電磁的な又は光学的な信号を送信及び受信し、様々なタイプの情報を表現するディジタルデータストリームを運ぶ。
【００９３】
ネットワークリンク５２０は典型的には１以上のネットワークを介して他のデータ装置とのデータ通信をもたらす。例えば、ネットワークリンク５２０はローカルネットワーク５２２を介してホストコンピュータとのコネクションを提供する、或いはインターネットサービスプロバイダ(ISP)５２６により運営されるデータ機器とのコネクションを提供する。そしてISP５２６はデータ通信サービスをワールドワイドパケットデータ通信ネットワーク(今日、「インターネット」５２８として一般に言及されている)を介して提供する。ローカルネットワーク５２２及びインターネット５２８の双方は、ディジタルデータストリームを搬送する、電気的な、電磁的な又は光学的な信号を使用する。様々なネットワークを介する信号や、ネットワークリンク５２０における通信インターフェース５１８を介する信号は、コンピュータシステム５００に及びそこからディジタルデータを搬送し、例えば情報を伝送する搬送波の形式をとってもよい。
【００９４】
コンピュータシステム５００は、ネットワーク、ネットワークリンク５２０及び通信インターフェースを介して、メッセージを送信し及びプログラムコードを含むデータを受信する。インターネットの例では、サーバー５３０はインターネット５２８、ISP５２６、ローカルネットワーク５２２及び通信インターフェース５１８を介して、アプリケーションプログラムに関する要求されたコードを送信するかもしれない。
【００９５】
プロセッサ５０４は受信したコードを受信したときに実行してもよいし、後の実行に備えてストレージデバイス５１０又は他の不揮発性ストレージに格納していたかのように実行してもよい。このようにコンピュータシステム５００は搬送波の形式でアプリケーションコードを取得してもよい。
【００９６】
以上本発明の特定の具体的な実施例が、実施例毎に異なってもよい多くの具体的詳細と共に説明された。独占排他権の対象である本願発明であり且つ本願発明であるとして出願人の意図するものは本願により許可される特許請求の範囲であり、特許請求の範囲の具体的内容は出願後の如何なる補正をも含む請求項に記載された事項で特定される。特許請求の範囲に含まれている用語に関し、明細書で記述した明示的な如何なる定義も、特許請求の範囲で使用される用語の意味を規定する。従って、特許請求の範囲で明示的には言及されていない限定、要素、性質、特徴、利点及び属性の如何なるものも、特許請求の範囲を限定するよう（どのような方法によっても）解釈されるべきでない。従って明細書及び図面は限定的な意味ではなく例示として解釈されるべきである。
【図面の簡単な説明】
【００９７】
【図１】SOAPリクエストを処理する本発明の一実施例によるアーキテクチャ例100を示すブロック図である。
【図２】リクエストを処理する本発明の一実施例によるオーケストレーションモジュール例を示すブロック図である。
【図３】リクエスト中の“非予測的な”‘優先度’フィールドを処理する本発明の一実施例によるフローチャートである。
【図４】イベント加入リクエストに組み込まれているスキャン宛先登録を処理する本発明の一実施例によるフローチャートである。
【図５】本発明の一実施例が使用されるコンピュータシステムを示すブロック図である。
【符号の説明】
【００９８】
１００ アーキテクチャ
１０２ クライアント
１０４ アドミニストレータ
１０６ デバイスファシリティマネジャ(DFM)
１０８ MFPで実行する複数のウェブサービスアプリケーション
１２２ WSイベンティング部
１２４ アブストラクトAPI
１２６ オーケストレーションモジュール
１３０ レガシープラットフォーム
１３２，１４２，１５２ ゼネラルAPI実現手段
１３４，１４４，１５４ アブストラクトAPI実現手段
１４０ リナックスベースのプラットフォーム
１５０ VxWorksベースのプラットフォーム
５００ コンピュータシステム
５０２ バス
５０４ プロセッサ
５０６ メインメモリ
５０８ リードオンリメモリ
５１０ ストレージデバイス
５１２ ディスプレイ
５１４ 入力装置
５１６ カーソル制御部
５１８ 通信インターフェース
５２０ ネットワークリンク
５２２ ローカルネットワーク
５２４ ホスト
５２６ インターネットサービスプロバイダ
５２８ インターネット
５３０ サーバー
【技術分野】
【０００１】
本発明は一般にウェブサービスの技術分野に関連し、特に、既に配備済みのウェブサービスアプリケーションを拡張することに関連する。
【背景技術】
【０００２】
このセクションで説明されるアプローチは追跡可能なアプローチであるが、考察又は追跡が過去になされているアプローチであるとは限らない。従って、特に断りのない限り、このセクションで説明されるどのアプローチも、このセクションに含まれているという理由だけで従来技術と考えるよう仮定されるべきではない。
【０００３】
「ウェブサービス」という用語は、IPのようなネットワークプロトコル上でXML、SOAP及びWSDL標準仕様を用いてウェブベースのアプリケーションを統合する標準的な方法を表す。XMLはデータをタグ付けするのに使用される。SOAPはウェブサービスリクエスト及びレスポンスをXMLメッセージにエンコードする方法を指定する。WSDLは利用可能なサービスを記述するのに使用される。ウェブサービスは、その実施に際してプラットフォームによらずに、互いに通信するプログラム可能でネットワーク化されたエンティティに使用される。そのような多くのエンティティはビジネスに関連したものであるので、ウェブサービスは、ファイヤウォール背後の互いのITシステムの詳細な知識なしに、業務でのデータ通信を可能にする。
【０００４】
ウェブサービスは、ネットワークを介したプログラムインターフェースを通じて、ビジネスロジック(論理装置)、データ及びプロセスを共有する。ウェブサービスは、時間のかかるカスタムコーディングなしに、様々なソースからの様々なアプリケーションが互いに通信できるようにする。更に総ての通信はXMLなので、ウェブサービスは、或る何らかのオペレーティングシステムやプログラミング言語に拘束されない。例えば、ジャバ(Java(登録商標))はパイソン(Python)と通信可能であり、ウインドウズ(Windows(登録商標))アプリケーションはユニックス(UNIX(登録商標))アプリケーションと通信可能である。
【０００５】
ウェブサービス仕様は、セキュリティ、信頼できるメッセージング及び緩く結合されたシステムでの処理に備えて、相互運用可能なプロトコルを提供するように共に構築される。ウェブサービス仕様は、承認済みの標準仕様(ワールドワイドウェブコンソーシアム(W3C)及び構造化情報標準促進協会(OASIS)によって承認される)と、標準仕様になるかもしれない提案中のドキュメント及びドラフトとの双方を含む。
【０００６】
一般的には、ウェブサービスアプリケーション(WSA)は、１つ以上のウェブサービス(WS)仕様に拘束される（又はそれらを実現する）。従って、関連するファイルがスキーマ(schema)毎に有効であったとしても、WSAは(拘束される)その仕様で規定されていない情報を認識しない。
【０００７】
関連するWS標準仕様が修正される場合、WSAは更新される必要がある。なぜなら、あるクライアントアプリケーションはその修正を考慮に入れることを望むかもしれないからである。しかしながら、WSAで提供されるサービスを要求するクライアントアプリケーションが、その修正を反映するように未だ更新されていない場合に備えて、WSAを提供する装置(デバイス)は、古いバージョンのWS標準仕様に準拠したままであるべきである。
【発明の開示】
【発明が解決しようとする課題】
【０００８】
WS標準仕様の修正に応じる１つの方法は、別のWSAを開発することである。これは、設計、コーディング、検査、ドキュメンテーション及びメンテナンス等の様々な段階のソフトウエア開発プロセスを（再び）行うこととなってしまう（これは、一般的には非常にコスト高である）。この方法によれば、WS標準仕様の一連の修正がなされた後、(a)同様な基本サービスを提供する及び(b)同時に実行する多数のWSAが存在することになる。同時に動作する同様なWSAを多数備えることは、余分なメモリや処理電力を必要としてしまう。
【０００９】
同様な方法として、古いバージョン及び新しいバージョンのWS標準仕様を考慮に入れた新しいWSAが、開発されるかもしれない。しかしながら、この方法によれば、新しいWSAが導入される前に古いWSAが停止されなければならない。従ってWSAで提供されるサービスが一時的に利用できなくなるかもしれない。
【課題を解決するための手段】
【００１０】
本発明の一形態によれば、ウェブサービスシステムを拡張する技法が提供される。ある技法では、ウェブサービスアプリケーション(WSA)はリクエストを受信する。WSAは、現在のバージョンのWS標準仕様に先行する或るバージョンのウェブサービス(WS)仕様を実現する。オーケストレーション(orchestration)モジュールがリクエストを処理するために呼び出され、オーケストレーションモジュールは、WSA及び１つ以上の拡張モジュール間の相互作用を管理する。リクエストの１つ以上の属性に基づいて、オーケストレーションモジュールは、リクエストの一部を処理する拡張モジュールを特定する。拡張モジュールはロジック(論理装置)を有し、そのロジックは、過去のバージョンのウェブサービス仕様と現在のバージョンとの間の差異に対応するものである。オーケストレーションモジュールは、拡張モジュールがリクエストの一部を処理することを引き起こす。そのロジックに従って拡張モジュールがリクエストの一部を処理し終えた後、そのリクエストを更に処理するためにWSAが呼び出される。
【００１１】
別の技法によれば、WSAは複数のモジュールを有し、その内少なくとも２つは互いに相互作用するように設計されてないかもしれない。先ず、複数のモジュール中の第１モジュールがリクエストを処理する。その処理はオーケストレーションモジュールにより引き起こされる。リクエストの１つ上の属性に基づいて、オーケストレーションモジュールは、リクエストの一部を処理するために、複数のモジュール中の第２モジュールを特定する。オーケストレーションモジュールは、第２モジュールがそのリクエストの一部を処理することを引き起こす。第２モジュールがリクエストの一部を処理し終えた後、オーケストレーションモジュールは、第１モジュールがそのリクエストの処理を続けるようにする。この場合、第１モジュール及び第２モジュール間での１つ以上の（間接的な）やりとりは、先行するバージョンと現在のバージョンとの間の差異を補う。
【００１２】
別の技法によれば、WSAはそのWSAにより提供されるサービスを求めるリクエストを受ける。WSAは、現在のバージョンのWS標準仕様に先行しているかもしれない特定のバージョンのWS標準仕様を実現する。リクエストは、その特定のバージョンでサポートされていないフィールドを特定する。マッピングに基づいて、そのフィールド値は、デバイスのファームウエア構成要素が処理できるデータに変換される。ファームウエア構成要素はそのデータに基づいてリクエストを処理する。
【発明を実施するための最良の形態】
【００１３】
本発明は添付図面と共に非限定的な実施例により説明される。図中、同様な参照番号は同様な要素を指す。
【００１４】
以下の説明では、説明の目的で多くの具体的詳細が記述され、本発明の十分な理解を促す。しかしながら本発明はそれらの具体的詳細によらず実施されてもよいことは明らかであろう。また、本発明を不必要に曖昧にすることを避けるため、周知の構造や装置はブロック図形式で示される。
【００１５】
以下のように構成された章立てで説明がなされる：
１．０ アーキテクチャ概要
１．１ クライアント
１．２ ネットワーク
１．３ デバイスファシリティマネジャ
１．４ WSDマネジャ
１．４．１ ゼネラルAPI
１．４．２ ゼネラルAPI実現手段
１．５ ウェブサービスアプリケーション
１．５．１ アブストラクトAPI
１．５．２ アブストラクトAPI実現手段
２．０ 総括
３．０ オーケストレーションモジュール
４．０ ウェブサービスアプリケーションを拡張モジュールと共に拡張すること
５．０ 以前には関連していなかったモジュールを接続することでウェブサービスアプリケーションを拡張すること
６．０ ウェブサービスアプリケーション及びデバイス性能間の相違に対処すること
７．０ ウェブサービス仕様とは分離したウェブサービスアプリケーションロジックを構築すること
８．０ 実現手段
【実施例１】
【００１６】
１．０ アーキテクチャ概要
図１は、SOAPリクエストを処理する本発明の一実施例によるアーキテクチャ例100を示すブロック図である。アーキテクチャ100は、クライアント102、アドミニストレータ104、デバイスファシリティマネジャ(DFM)106及びMFPで動作する複数のウェブサービスアプリケーション108を含む。
【００１７】
図１に示されるように、MFPは任意数の異なるプラットフォーム（例えば、レガシープラットフォーム130、リナックスベースのプラットフォーム140及びVxWorksベースのプラットフォーム150等）を有し、通常MFPは唯１つのプラットフォームを有する。MFPが印刷サービスを含んでいた場合、そのプラットフォームは印刷エンジンを含む。同様に、MFPがスキャンサービスを含んでいた場合、少なくとも１つのプラットフォームはスキャンエンジンを含む。
【００１８】
ディスカバリリクエスト、クライアント102からのメタデータリクエスト、及びアドミニストレータ104からのコンフィギュレーションその他のMFP管理リクエストに応答することで、DFM106はMFPを代表する。DFM106は、WSディスカバリ112及びWS-MeX(即ち、WS-MetadataExchange(WSメタデータイクスチェンジ))のような複数のウェブサービス仕様を実現する際のリポジトリとして機能する。
【００１９】
MFPで動作する各WSA108は、例えばSOAPプロトコルを使って、サービスを要求するクライアント102にサービスを提供する。ターゲットプラットフォームとは独立に、アブストラクトAPI124のようなサービス固有のアブストラクトAPIを、各WSA108は使用してもよい。更に各WSA108はWS-Eventing(WSイベンティング)122を実現してもよい。
【００２０】
、ディスカバリリクエスト又はディスカバリハロー(HELLO)メッセージを介して（即ち、同じネットワーク上で、MFPを通知するメッセージをデバイスにブロードキャスト又はマルチキャストすることで）、クライアント102はMFPが存在することを発見してもよい。いったんクライアント102がMFPの存在に気付くと、クライアント102はデバイスメタデータ交換リクエストを、例えばWA-MetadataExchangeを介して送信し、MFPが提供する総てのサービスを発見する。デバイス全体について作用するDFM106は、そのリクエストを受けて、MFPにより提供される様々なサービスを記述するメタデータを返す。 WSA108のようなMFPで動作する特定のWSAからのサービスメタデータを、クライアント102は要求してもよい。WSA108はウェブサービスデバイス(WSD)マネジャ110からのサービスメタデータを要求し、WSDはサービスメタデータをWSA108に返してもよい。WSA108はサービスメタデータをクライアント102に転送する。
【００２１】
或いは、MFPのデバイスメタデータ及び１つ以上のWSAのサービスメタデータは、同じレスポンスでクライアント102に送信されてもよい。
【００２２】
サービスメタデータに基づいて、WSA108により提供されるサービスに対応するSOAPリクエストをクライアント102が生成及び送信し、そのリクエストをWSA108が受信及び処理する。サービスリクエストに基づいて、WSA108はアブストラクトAPIを用いて、アブストラクトAPIの実行に対するプラットフォーム固有の呼び出しを行う（例えば、アブストラクトAPI実現手段144を呼び出す）。このように、WSA（例えば、WSA108）の開発者は、ウェブサービスが動作する前提のプラットフォームの詳細情報を必要とせずに、ウェブサービス自体の開発に焦点を合わせてよい。従って、ターゲットプラットフォームに関する知識を備えたWSA開発者以外の誰でもが、関連するアブストラクトAPIの実現手段を規定してよい。
【００２３】
１．１ クライアント
クライアント102はあるアプリケーションであり、MFPにより提供される１つ以上のサービスを要求するプロセスに関連付けられる。クライアント102は、一般的には、初期のプロセス要求をサポートするオペレーティングシステムに関連するアプリケーションである。クライアント102の目的は、プロセスを要求することに起因するプラットフォーム固有のプロシジャコールを、SOAPを「理解」できるアプリケーションで処理可能なSOAPリクエストに変換することである。
【００２４】
例えば、プロセスのリクエストはマイクロソフトワードアプリケーションに関連付けられ、WSA108は印刷サービスを提供してもよい。クライアント102は、初期のプロセス要求をサポートするオペレーティングシステムに関連するアプリケーションでもよい。クライアント102は、プロセスリクエストに起因して送信されたプラットフォーム固有の「印刷データ」を受信する。クライアント102はSOAPメッセージの印刷データリクエストをエンコードし、SOAPメッセージは、SOAPメッセージを「理解」できるWSA108により処理可能である。
【００２５】
１．２ ネットワーク
クライアント102及びMFP間のSOAP通信は、（不図示の）ネットワークを介してなされてもよい。ネットワーク内の様々なノード間でデータ交換可能な如何なる媒体や手段によって、そのネットワークが実現されてもよい。そのようなネットワークの具体例は、限定ではないが、ローカルエリアネットワーク(LAN)、広域ネットワーク(WAN)、イーサーネットやインターネット、又は１つ以上の地上、衛星若しくは無線のリンク等を含む。ネットワークは上述したようなものの組み合わせを含んでもよい。ネットワークは、伝送制御プロトコル(TCP)、ユーザデータプロトコル(UDP)及び／又はインターネットプロトコル(IP)等に従ってデータを送信してもよい。
【００２６】
１．３ デバイスファシリティマネジャ
DFM106は、ディスカバリリクエスト、情報のロギングリクエスト及びコンフィギュレーション命令を受け入れることでMFPを代表する。一実施例によれば、DFM106は、複数のウェブサービス(WS)仕様を実現する際のリポジトリとして機能する。従って、DFM106はルーチンの共有ライブラリを含み、各ライブラリは、１つ以上のWS標準仕様(例えば、WS-Security(WSセキュリティ)、WS-MetadataExchange)で規定されている１つ以上の機能を実行する。このように、複数のWS標準仕様がいったん実現され、MFPで動作する複数のウェブサービスアプリケーション(即ち、WSA108)の各々で共有される。その結果、WSAの開発者は、DFM106に実装される如何なる仕様についても多くの詳細を知る必要はなく、その仕様を利用でき且つ当てにしてよい。DFM106に実装されるいくつかのWS標準仕様は、限定ではないが、WS-Discovery(WSディスカバリ)112、WS-Transfer(WS転送)114、WS-MeX(即ち、WS-MetadataExchange)116及びWS-Security118等を含んでよい。
【００２７】
一実施例では、DFM106は、SOAPプロトコルに対応するライブラリルーチンを含む。各SOAPライブラリルーチンは、１つ以上のSOAP仕様で規定されている１つ以上の機能を実現する。SOAPライブラリルーチンは、SOAPリクエストを分析し、SOAPメッセージをまとめる(パッケージする)のに使用される。従って、各WSA108はDFM106から1つ以上のSOAPライブラリルーチンを起動し、SOAPライブラリルーチンが一度規定され、MFP上で動作する総てのWSA108の間で共有されるようにする。複数のバージョンのSOAPプロトコル標準仕様がサポートされてもよい。WSA108に対する一切の修正なしに又はほとんどなしに、新しいバージョンのSOAPプロトコル標準仕様への更新は行われる。
【００２８】
一実施例では、クライアントアプリケーション(例えば、クライアント102)は、MFPで１つ以上のWSAを更新することに関する情報を受けるように登録してもよい。特定のアプリケーションの更新に関する更新情報をDFM106が受信し、且つクライアントアプリケーションがそのような更新を示す情報を受けるように登録されていた場合、その更新情報を示すメッセージをDFM106はクライアントアプリケーションに送付する。関連する実施例では、クライアント102はそのような更新通知を受けるように登録（例えば、加入）する必要はない。むしろ、１つ以上のWSAに対して、更新を示すメッセージを自動的にブロードキャストするようにDFM106が構築されてもよい。
【００２９】
一実施例では、DFM106はWSAに関する更新情報を受信してもよい。例えば、WSA108はファックスサービスを提供しているが、MFPはファックス回線が切断されていることを検出するかもしれない。ファックスサービスが利用可能でない場合、MFPがファックスサービスを提供することを示すデバイスメタデータと共に、DFM106は将来的なメタデータリクエストに応じるべきではない。従って、WSAから更新情報を受けたことに応じて、WSAに関連するサービスメタデータ及び／又はデバイスをDFM106は更新する。
【００３０】
一実施例では、DFM106はアドミニストレータアプリケーション(例えば、アドミニストレータ104)からコンフィギュレーションリクエストを受信してもよい。コンフィギュレーションリクエストは、構築される及び／又は更新される１つ以上のWSAを示す。DFM106は、コンフィギュレーションリクエストを処理し、適切なWSAにおけるコンフィギュレーション又は更新指示を実行する又は実行させる。或いは、以下で更に詳細に説明されるように、DMF106はそのようなコンフィギュレーションリクエストを処理するようにWSDマネジャ110を指示する。
【００３１】
一実施例では、DFM106はアドミニストレータアプリケーション(例えば、アドミニストレータ104)からのリクエストを受信し、リクエストの記録に応じる。DFM106は、MFPで動作する１つ以上のWSAに関するロギング情報を取り出し、ロギング情報をアドミニストレータ104に送信する。以下で更に詳細に説明されるように、WSDマネジャ110はロギング情報を取り出してDFM106に与える。
【００３２】
１．４ WSDマネジャ
一実施例によれば、DFM106はWSDマネジャ110を有する。WSDマネジャ110は、情報の記録、ステータスの問い合わせ、及び（アドミニストレータ104からのような）MFPの外部管理に関する中央局又はセントラルポイントをもたらす。アドミニストレータ104は、WSDマネジャ110を介してMFPに関する情報を取り出すよう構築されたアプリケーションである。例えば、総てのWSA108から及びWSA108が動作する様々なプラットフォームから内部的に到来する総てのロギング情報を、WSDマネジャ110は集めてもよい。アドミニストレータは、WSDマネジャ110を用いてWSA108を構築、更新又は不活性化(ディセーブルに)してもよい。
【００３３】
一実施例では、どこにMFPが位置するか、どんなWSAがMFPにインストールされているか、WSAは適切に動作しているか否か等のような全体的な状態情報を、WSDマネジャ110は維持する。
【００３４】
一実施例では、MFPで動作している各サービスアプリケーションに関するサービスメタデータ及びMFPについてのメタデータを、WSDマネジャ110は維持する。
【００３５】
１．４．１ ゼネラルAPI
一実施例によれば、WSDマネジャ110はMFPに関する一般的な情報（例えば、MFPのモデル番号やIPアドレス等）をゼネラルAPI120を介して取り出す。ゼネラルAPI120は或るインターフェースを規定し、そのインターフェースにより、DFM106はMFPのプラットフォーム各々に固有の情報を受け取る。このようにして、DFMの開発者は、特定のプラットフォームの詳細を知る必要はなく、或るMFPについてその開発者が構築しようとしているDFMの詳細だけを知っていればよい（図１の波線は、特定のAPIから対応するAPI実現手段へのAPIコールである。）。
【００３６】
１．４．２ ゼネラルAPI実現手段
ゼネラルAPI120がDFM106について規定されていた場合、特定のプラットフォームに関するゼネラルAPI120の実現手段が規定される。例えば、ゼネラルAPI実現手段132が、レガシープラットフォーム130におけるゼネラルAPI120について規定される。同様に、ゼネラルAPI実現手段142が、リナックスベースのプラットフォーム140におけるゼネラルAPI120について規定される。関連するゼネラルAPI実現手段は、デバイス固有のリクエストで指定され及びMFPで実現される機能を規定する。
【００３７】
１．５ ウェブサービスアプリケーション
ウェブサービスアプリケーション(WSA)108は、1つ以上のモジュールを有する。WSA108は、１つ以上のウェブサービスを提供し、ウェブサービス(WS)プロトコル及びテクノロジ（例えば、DFM106で提供されているプロトコル等）を当てにしている。1つ以上のモジュールは、ハードウエア回路で、コンピュータソフトウエアで、或いはハードウエア回路及びコンピュータソフトウエアの組み合わせで実現されてもよく、特定のハードウエアの手段にも特定のソフトウエアの手段にも限定されない。WSA108がSOAPリクエストを分析するロジックを含んでいなかった場合、SOAPリクエストを分析するために、WSA108は、別個のSOAPモジュール(図示せず)も当てにしている。上述したように、別個のSOAPモジュールは、DFM106により用意され、総てのWSA108の間で共有されてもよい。
【００３８】
WSA108は、クライアント102からのイベントリクエストに応答するWSイベンティングモジュール122も有する。クライアント102は、WSA108により提供されるサービスに関連するイベントに加入してもよい。例えば、WSA108が印刷サービスを提供しており、クライアント102が加入するイベントは、WSA108に関するMFPが印刷ジョブを完了したことでもよい。こうして、印刷ジョブが完了した際、WSA108は、印刷ジョブが完了していることを示すイベントメッセージをクライアント102に送信する。
【００３９】
WSAは１つ以上のサービスを提供するために１つ以上のWS標準仕様に基づいて開発及び実現されてもよい。スキャンサービスについて或るWSが存在し、印刷サービスについて別のWS標準仕様が存在し、アーカイブサービスについて別のWS標準仕様が存在し、ファクシミリサービスについて別のWS標準仕様が存在するかもしれない。
【００４０】
ここで使用されるように、WSAが基づいている古いバージョンのWS標準仕様は「旧バージョン」と言及され、現在のバージョンのWS標準仕様は「新バージョン」と言及される。
【００４１】
リクエストを処理した結果、電子書類を印刷したり、イベント加入リクエストに対する応答を送信するような１つ以上のアクションを、WSAは実行する。SOAPリクエストかもしれないリクエストが、クライアント(例えば、クライアント102)から到来し、或いはMFPのタッチパネルディスプレイと共にインターフェースをとるユーザから到来するかもしれない。
【００４２】
１．５．１ アブストラクトAPI
WSA108はアブストラクトAPI(例えば、アブストラクトAPI124)も有し、そのアブストラクトAPIを介してプラットフォーム固有のコールが生成される。アブストラクトAPIは或るインターフェースを規定し、そのインターフェースにより、関連するWSA108はMFPに関する１つ以上の機能を起動する。
【００４３】
１．５．２ アブストラクトAPI実現手段
アブストラクトAPIがウェブサービスアプリケーション開発者により規定されていた場合、特定のプラットフォームについてそのアブストラクトAPIの実現手段が規定されている。例えば、アブストラクトAPI実現手段154は、VxWorksプラットフォーム150でのアブストラクトAPI124に備えて規定される。関連するアブストラクトAPI実現手段は、プラットフォーム固有のリクエストで指定され且つMFPに実装されている機能を規定する。
【００４４】
２．０ 総括
ウェブサービスシステムを拡張する技法が提供される。例えば、現在のバージョンより前のバージョンのWS標準仕様を、WSAは実装しているかもしれない。以前のバージョンではない現在のバージョンに従うリクエストをサポートするため、或るいは以前のバージョンにはない現在のバージョンの特性を参照するリクエストをサポートするため、好ましくはWSAの基本的なロジックを修正せずに、WSAは拡張される必要がある。
【００４５】
ウェブサービスシステムが現在のものであることをクライアントに示すため、WSAにより提供されるサービスを記述するWSDLファイルは、現在のバージョンのWS標準仕様を反映するように更新されてもよいし、或いはWSAが動作する装置の能力を反映するように更新されてもよい。クライアントがWSDLファイルを要求する際、クライアントは、WSAがどの特性をサポートしているかを知っている。本発明の様々な実施例により達成される利点の１つは、中断時間なしにユーザの処理に影響せずに、既存のWSAが再利用されてよいことである。
【００４６】
３．０ オーケストレーションモジュール
本発明の一実施例によれば、オーケストレーションモジュールが、MFPで動作する1つ以上のWSAについて用意される。オーケストレーションモジュールは、WSAの基本ロジックを修正せずに、WSAを拡張する責務を有する。オーケストレーションモジュールは、ルールベース(rule-based)でもよいし、オブジェクト指向階層に従って設計されてもよい。オーケストレーションモジュールは、印刷サービスモジュール、井部ティングサービスモジュール、スキャニングサービスモジュール及びアーカイブサービスモジュールの間でのやりとりを制御する。オーケストレーションモジュールは、単なる連鎖的な拡張モジュールでは達成できない柔軟性をもたらす。例えば、オーケストレーションモジュール内で示されるルールエントリが構築可能である。こうして、動作が実行時に修正され、拡張モジュール及び複数のモジュールを協調させる。また、新たなルールが実行時に追加されてもよい。
【００４７】
図１に示されるように、各WSA108はオーケストレーションモジュール126を有する。しかしながら、別の実施例では、デバイスが複数のWSAを有していた場合、オーケストレーションモジュール126が複数のWSAの中で共有されてもよく、その場合、オーケストレーションモジュール126は論理的にはDFM106の中にあってもよい。
【００４８】
図２は、リクエストを処理する本発明の一実施例によるオーケストレーションモジュール例126を示すブロック図である。オーケストレーションモジュール126は３つの列を含むテーブルを有し、その列は、キーフィールド列202、コンテキスト列204及びアクション列206である。そしてオーケストレーションモジュール126のテーブルは、図示の３つ組を４つ有する。３つ組の各々はキーフィールド値、コンテキスト値及びアクション値を有する。しかしながら他の実施例におけるテーブルは、２列でもよいし、４以上の列を含んでもよい。例えばテーブルはキーフィールド列202及びアクション列206だけを含んでもよい。
【００４９】
オーケストレーションモジュール126のテーブル中の各行に関し、キーフィールド列202は、あるリクエスト中の１つ以上のフィールドを示し、そのリクエストは、関連するアクションモジュール206で示されている１つ以上のモジュールの動作にトリガを与える。
【００５０】
コンテキスト列204は１つ以上のコンテキストを示し、そのコンテキストの中で、実行される１つ以上の対応するモジュールに備えて、対応するキーフィールドが少なくとも論理的に位置付けられている。「コンテキスト(context)」は、リクエストの中で対応するフィールドの論理的なロケーションを示す。オーケストレーションモジュール126がコンテキスト列204を含んでいた場合、対応するフィールドが、リクエストの適切なコンテキスト内に位置していた場合にのみ、アクションモジュール206で特定される１つ以上のモジュールが実行される。従って、あるコンテキストにおけるあるキーフィールドが或るアクション群にトリガを与えるかもしれないが、異なるコンテキスト中の同じキーフィールドは異なるアクション群にトリガを与える。
【００５１】
関連する実施例では、キーフィールド列202又はコンテキスト列204は、対応するフィールドに関連するネームスペース(namespace)を示す。例えば、ネームスペースが「Richo」(リコー)であり、優先度(プライオリティ)フィールドを規定するのにリコーのスキーマが使用されることを示す。
【００５２】
図２に示されるように、最初の３つ組は、「プライオリティ」を表すキーフィールド202の値、「SOAPヘッダ」を表すコンテキスト204の値、及び「プライオリティ処理モジュール、サービスモジュール」を表すアクション206の値を有する。「サービスモジュール」は、印刷、スキャニング、ファクシミリ送受信、複写又はアーカイブ等のような特定のMFPサービス212を実行するWSAに関連する。SOAPリクエストがオーケストレーションモジュール126に伝送され、オーケストレーションモジュール126が、リクエストはSOAPリクエストのヘッダ部分に「プライオリティ」フィールドを含んでいることを確認した場合、プライオリティ処理モジュールが呼び出される。プライオリティ処理モジュールがリクエストを処理し終えると、実行結果はオーケストレーションモジュール126に戻され、オーケストレーションモジュールは処理を続けるために適切なサービスモジュールを呼び出す。
【００５３】
最後の３つ組は、「期間経過」（有効期間又は期限切れ）を表すキーフィールド202の値、「SOAPヘッダ」を表すコンテキスト204の値及び「タイムモジュール、サービスモジュール」を表すアクション206の値を含む。この３つ組の場合、SOAPリクエストがオーケストレーションモジュール126に伝送された場合であって、オーケストレーションモジュール126がそのリクエストはSOAPリクエストのヘッダ部分に「期間経過」フィールドを含んでいることを確認した場合、タイムモジュールが呼び出される。タイムモジュールが偽（フォールス）を返した場合、オーケストレーションモジュール126は更なる処理に備えたサービスモジュールを呼び出さないであろう。そうでなかった場合、タイムモジュールがリクエストを処理した後、オーケストレーションモジュール126はそのリクエストを処理するために適切なサービスモジュールを呼び出すであろう。
【００５４】
４．０ ウェブサービスアプリケーションを拡張モジュールと共に拡張すること
一実施例では、WSA及び拡張モジュール間の相互作用をオーケストレーションモジュール126が管理し、拡張モジュールは、旧バージョンのWS標準仕様には無い新バージョンのWS標準仕様の特徴機能を実行する。現在動作しているWSAを修正もせず影響も与えないようにするため、オーケストレーションモジュールは、配備されているWSAと1つ以上のプラグイン拡張モジュールとの間のやりとりを調整する。SOAPリクエスト中の「プライオリティ」フィールドのような新たな特徴事項を適切に処理するため、一連の処理チャネル（即ち、ハンドル）がWSA処理ロジックのある場所に加えられる。
【００５５】
図３は、本発明の一実施例により、リクエスト中の「プライオリティ」フィールド（WSAでは認識できない）を処理する際、オーケストレーションモジュールが如何に使用されるかを示すフローチャートである。本発明の場合、WSAプロセスは、WSAが基づいているWS標準仕様に従って、FIFO(先入れ先出し)を要求する。その標準仕様は、プライオリティフィールドを含むリクエストを如何に処理するかについては規定していない：従って、WSAはプライオリティフィールドを含むリクエストを処理するロジックを含んでいない。従って、WSAがプライオリティフィールドを伴うリクエストに遭遇した場合、WSAはそのプライオリティフィールドを単に無視する。
【００５６】
プライオリティフィールドを含むリクエストを処理し、指定されたプライオリティに基づいてリクエストを処理するため、拡張モジュール（この場合、「プライオリティ処理モジュール」と言及される）が装置に加えられる。
【００５７】
更に図３を参照するに、ステップ302において、クライアントからWSAにてリクエストが受信される。ステップ304では、リクエストを処理するため、WSAに関連するオーケストレーションモジュールが呼び出される。メッセージは、WSAにより又はオーケストレーションモジュールにより分析され、フィールド照合はオーケストレーションモジュールにより実行される。従ってオーケストレーションモジュールは、プライオリティフィールドがリクエストの中に含まれているか否かを確認する。プライオリティフィールドがリクエスト中に見出されなかった場合、プロセスはステップ314に進み、WSAが(即ち、FIFOで)リクエストを処理する。プライオリティフィールドがリクエスト中に含まれていることをオーケストレーションモジュールが確認した場合、プロセスはステップ306に進む。
【００５８】
一実施例では、ステップ304において、プライオリティフィールドが適切なコンテキストの中に存在するか否かを（例えば、図２のオーケストレーションモジュール126により）更に確認する。例えば、リクエストがSOAPリクエストであり、プライオリティフィールドがSOAPリクエストのボディ部分(本体部分)に含まれているが、SOAPリクエストのヘッダ部分内には含まれていなかった場合、そのプライオリティフィールドはオーケストレーションモジュールによって無視され、プロセスはステップ314に進む。しかしながら、プライオリティフィールドのコンテキストが適切であった場合、即ち、プライオリティフィールドがSOAPリクエストのヘッダ部分に含まれていた場合、オーケストレーションモジュールは、SOAPリクエストのプライオリティフィールドを処理するようにプライオリティ処理モジュールを促し、プロセスはステップ306に進む。
【００５９】
ステップ306では、プライオリティ処理モジュールは、WSAが維持しているリクエスト処理キューが空になっているか否かを確認する。空になっていれば、プロセスはステップ314に進み、プライオリティ方式のキュー処理は不要である。
【００６０】
リクエスト処理キューが空でなければ、ステップ308において、プライオリティ処理モジュールは、例えばリンクしたリストを維持し、「プライオリティ」フィールド値に基づいてリクエストを処理し、WSAのリクエスト処理キューが空になるまで待機する。
【００６１】
ステップ310では、リンクしたリストのヘッダでリクエストを処理するようにWSAが呼び出される。ステップ312では、WSAがリクエストを処理し終えた後に、そのリクエストを送信したクライアントに或る応答が送信される。
【００６２】
かくしてプライオリティ処理モジュールだけがプライオリティフィールドのビジネスロジックに気付いている。プライオリティ処理モジュールがWSAにプラグインされる場合でさえ、WSAは修正されずそのまま動作し続ける。
【００６３】
５．０ 以前には関連していなかったモジュールを接続することでウェブサービスアプリケーションを拡張すること
一実施例では、オーケストレーションモジュールは、MFPで動作する様々なモジュール間のやりとりを管理し、そのやりとりは、旧バージョンには無かった新バージョンのWS標準仕様の１つ以上の特徴機能を構築する。例えば、MFPはスキャンサービス及びイベンティングサービスを含み、それらは独立に開発され、互いに如何なる相互作用もなしに開発されている。以後、スキャンサービスについての新バージョンのWS標準仕様が、スキャン宛先登録情報はイベント加入リクエストメッセージに組み込まれてよいことを表す。イベンティングサービス又はスキャンサービスを修正する代わりに、或るエントリがオーケストレーションモジュールに加えられ、それに従ってイベント加入リクエストの処理手順を決める。
【００６４】
図４は、イベント加入リクエストに組み込まれているスキャン宛先登録を処理する本発明の一実施例によるフローチャートである。ステップ402では、１つ以上のモジュールとして動作するイベントサービスは、クライアントからイベント加入リクエストを受信する。そして、イベンティングサービスは、オーケストレーションモジュール(例えば、オーケストレーションモジュール126)を呼び出す。ステップ402の一部分として、イベンティングサービスは、イベント加入リクエストが適切にフォーマットされているか否かを(例えば、WSイベンティング標準仕様に従って)確認する。適切にフォーマットされていなければ、イベンティングサービスは、偽メッセージをクライアントに送信する。
【００６５】
代替実施例では、オーケストレーションモジュールはイベンティングサービスを含むWSAの総てのモジュールの前に配置される。この場合、オーケストレーションモジュールは、クライアントからリクエストを受信し、呼び出すモジュールを判定する。
【００６６】
ステップ404では、オーケストレーションモジュールは、イベント加入リクエストがスキャン宛先登録を(例えば、図２に示されるような適切なコンテキストで)含んでいるか否かを確認する。含んでいなかった場合、堀はステップ414に進み、オーケストレーションモジュールはイベンティングサービスを呼び出し、既存のロジックに従ってリクエストを処理する。しかしながら、イベント加入リクエストはスキャン宛先登録を含んでいることをオーケストレーションモジュールが確認した場合、プロセスはステップ406に進む。
【００６７】
ステップ406では、オーケストレーションモジュールは、スキャンサービスを呼び出し、スキャン宛先登録情報を予備的に処理する。予備的な処理は多くのステップを含んでよく、例えば、スキャン宛先ディスプレイ名を有効化することや、宛先登録の最大数に圧したか否かを確認することを含んでよい。宛先登録の最大数は、デバイスの側で予め決められる。別の処理例として、スキャンサービスは宛先トークンを作成し、スキャン宛先登録リクエストを認識する（そのトークンは後のジョブ生成に使用される。）。スキャンサービスは宛先トークンをイベンティングサービスへ加入者応答の一部として伝送する。ジョブ生成の際クライアント及びスキャンサービス間のハンドシェーキング情報として、スキャン宛先関連イベント中の他のフィールドと共に宛先トークンが後に使用される。特定のスキャン宛先が例えばスキャンオペレーショナルパネル等から選択される場合、スキャン宛先関連イベントは、スキャンサービスにより生成される。
【００６８】
ステップ408では、スキャンサービス処理が成功したか否かを、スキャンサービスは確認する。成功していなかったならば、クライアントに偽(フォールト)が返される（ステップ418）。予備処理は不成功の一例は、イベント加入リクエスト内で指定されている宛先数が宛先登録の最大数を超えていた場合に生じる。予備処理不成功の別の例は、スキャンサービスがスキャン宛先登録情報を認識しなかった場合である。
【００６９】
スキャンサービス処理が成功した場合、プロセスはステップ410に進む。ステップ410では、スキャンサービスは、予備処理による何らかの出力をオーケストレーションモジュールに伝送し、オーケストレーションモジュールは、そのような情報をイベントサービスに伝送して加入者管理処理に備える。しかしながら、図２に示されるように、加入者管理モジュールはイベントサービスから独立していてもよい。その場合、オーケストレーションモジュールは、スキャンサービスの予備処理の出力を、加入登録に備えてイベントサービスに伝送する。以後、イベンティングサービスは作成した加入情報を加入管理モジュールに転送し、加入管理処理に備える。
【００７０】
イベンティングサービス(又は加入管理モジュール)が加入管理処理を終了した後、オーケストレーションモジュールは、スキャン宛先管理のような事後処理に備えてスキャンサービスを呼び出す(ステップ412)。例えば、スキャンサービスは、加入リクエスト内で指定されている宛先を、将来の利用に備えてローカルメモリの宛先リストに(例えば、宛先マネジャを使って)追加して保存してもよい。
【００７１】
ステップ412で事後処理を行う理由の１つは、イベンティングサービスが、イベント加入リクエストに対する加入応答を作成する際、イベンティングサービスで作成されたデータをスキャンサービスが利用しなければならないかもしれないからである。例えば、スキャンサービスは加入識別子を追跡する必要があり、イベンティングサービスは受け入れた加入を一意に識別するようにその加入識別子を生成する。従って事後処理は事前処理(予備処理)と組み合わせるべきではない。
【００７２】
ステップ412で事後処理を行う別の理由は、不要な処理工程を避けるためである。ステップ406の途中で又はその前に、イベンティングサービスがイベント加入リクエストを(例えば、WSイベンティング標準仕様に基づいて)有効化しているかもしれない。加入応答メッセージを作成する前に、そのイベント加入リクエストが無効であることを、イベンティングサービスが確認していた場合、イベンティングサービスは偽メッセージを作成し、その偽メッセージをクライアントに送付する。オーケストレーションモジュールはエラーの通知を受け、関連する処理を中断する：即ち、加入管理モジュールもスキャンサービスも呼び出されない。イベンティングサービスはそのエラーをスキャンサービスに通知すべきではない。なぜならそのようなサービスは互いに透明であるべきだからである。そのようなサービスはオーケストレーションモジュールの支援と共にのみ相互作用する。
【００７３】
イベント加入リクエストの処理から予備的な及び事後的な処理を分離することは、イベントサービス及びスキャンサービスのモジュール性を維持しつつ、柔軟性及び拡張性を最大化する。このように、イベントサービスもスキャンサービスも互いのデータスキーマやビジネス論理を詳細に理解することを要しない。
【００７４】
ステップ412の事後処理の後、イベンティングサービスはイベント加入応答を作成し、それをクライアントに送る(ステップ416)。オーケストレーションモジュールが総てのサービスの上にあり且つリクエストメッセージを受けた場合、オーケストレーションモジュールは、スキャンサービスの事後処理の後にその応答を返す。イベンティングサービスがクライアントリクエストを受け、その後に、可能性のある更なる処理に備えてオーケストレーションモジュールを呼び出した場合、イベンティングサービスは加入応答をクライアントに送る。
【００７５】
このように、既存のどのサービスも修正せずに、指定された方法でサービスを組み合わせることで、リクエストメッセージが処理される。
【００７６】
６．０ ウェブサービスアプリケーション及びデバイス性能間の相違に対処すること
別の実施例では、WSAが動作するデバイスで提供される特徴機能とWSAとの間の不一致が取り扱われる。比較的容易なワークフローやビジネス論理のカスタマイズを可能にするように、WSAは設計される。クライアントからのリクエストは、WSAが基づいているWS標準仕様で規定されていないフィールド（及びフィールド値）を含むかもしれない。しかしながらこのフィールド値は、デバイスのファームウエア構成要素によって認識可能である。
【００７７】
例えば、図１に示されるように、WSA108はアブストラクトAPI124を有し、そのアブストラクトAPIを介してプラットフォーム固有のコールが生成される。アブストラクトレイヤ124は或るインターフェースを規定し、そのインターフェースによって、WSA108は前提としているプラットフォームとインターフェースをとり、サービス（例えば、印刷サービス）を提供する。そして、アブストラクトAPI実現手段144は、リナックスベースのプラットフォーム140に関するアブストラクトAPI124に備えて用意される。アブストラクトAPI実現手段154は、VxWorksプラットフォーム150に関するアブストラクトAPI124に備えて用意される。
【００７８】
(デバイスが処理可能な)クライアントリクエストの総ての部分が適切に処理されることを保証するため、リクエストの内認識でない部分を適切なアブストラクトAPI実現手段に伝送するフック(hook)をWSAは用意する。マッピングテーブルは、リクエストで指定されている値(WSAが基づいている標準仕様では言及されていない値)と、アブストラクトレイヤが認識する値とを関連付ける。そのマッピングテーブルはオーケストレーションモジュール内にあってもよいし、それ以外の場所にあってもよい。例えば、アブストラクトレイヤがWSAの内蔵構成要素(ビルトインコンポーネント)であった場合、WSAはそのマッピングテーブルを使って、クライアントの要求値をアブストラクトレイヤで認識される値に変換する。他の例では、アブストラクトレイヤはWSAとは別個のモジュールであり、オーケストレーションモジュールはそのマッピングテーブルにより値を照合する。アブストラクトAPI実現手段に追加的な特徴が加えられる場合、唯一マッピングが更新されることを要するかもしれない。このように、WSAは更新されることを要しない。
【００７９】
例えば、或るバージョンのスキャンサービス標準仕様(旧バージョン又は新バージョン)は、両面原稿のページ開き方向を規定していない。しかしながら、スキャン装置は両面原稿について「表から表へ(Top To Top)」及び「表から裏へ(Top To Bottom)」のページ開き方向をサポートしている。この例の場合、WSAは或る特定のバージョンのスキャンサービス仕様に基づく。WSAは或るフィールドを含むリクエストを受信し、そのフィールドは「表から表へ」の値に関連する両面原稿のページ開き方向を示す。「表から表」を(スキャン装置の)スキャンエンジンが処理できるデータに変換するように、マッピングテーブルは(例えば、WSAにより)求められる。データは例えば“T2T”でもよい。デバイスのファームウエア構成要素は、両面原稿書類に関する「表から表」のページ開き方向に従って、１つ以上の処理をスキャンすることで“T2T”を処理することができる。後に、新たなバージョンのスキャンサービス仕様が、ページ開き方向をサポートするように加わった場合でも、旧バージョンの仕様に基づいていたWSAは修正されることを要しない。
【００８０】
７．０ ウェブサービス仕様とは分離したウェブサービスアプリケーションロジックを構築すること
本発明の一実施例によれば、WS標準仕様の中核的な(コアの)ビジネスロジックを、WS標準仕様のバージョン固有の情報から分離するように、WSAのロジックが始めに構築される。そして、バージョン固有の制約及び／又はデータスキーマ確認が１つ以上の拡張モジュールに課せられる一方、WSAは中核的なビジネスロジックを含む。そして、WSAの前提となるコードを修正することなく、WSAは再利用される。
【００８１】
WS標準仕様のコアビジネスロジック(CBL)は、デバイス自体に関する動作を処理する。CBLは構文的な(シンタックスの)観点からリクエストを有効化するものではなく；前提とするデバイスの機能に基づいてリクエストが受入可能で処理可能か否かを、CBLは確認する。
【００８２】
プリンタに関するCBLの具体例は、印刷ジョブを生成すること、書類を印刷すること、情報(プリンタメタデータ、性能、デフォルトのプリントチケット、プリンタステータス、アクティブな印刷ジョブ、ジョブ履歴等の情報)を抽出すること、更には、印刷ジョブステータスイベント及び／又は他のプリンタ関連イベントを生成すること等を含む。スキャナに関するCBLの具体例は、スキャンジョブを生成すること、書類をスキャンすること、画像をクライアント／スキャン宛先に送ること、スキャンステータスイベント及び／又は他のスキャナ関連イベントを生成すること、及び情報(スキャナメタデータ、性能、デフォルトのスやンチケット、スキャナステータス、アクティブなスキャンジョブ、スキャンジョブ履歴等の情報)を抽出すること等を含む。
【００８３】
WS標準仕様のバージョン固有の制約(VSC)は構文的な(シンタックスの)制約であり、リクエストメッセージ及び応答メッセージの構成に関する各バージョンの仕様によって課せられる。VSCはデバイスの機能を取り扱うものではない。VSCの具体例は、リクエスト及び応答メッセージのSOAPヘッダ中のWS-Addressing(WSアドレッシング)アクションフィールドである。各バージョンのサービス仕様(例えば、印刷サービスやスキャンサービスの仕様)は、各オペレータのリクエスト及び応答メッセージのSOAPヘッダ中で異なるWSアドレッシングアクションフィールドを規定するかもしれない。VSCの別の具体例は、スキャン書類フォーマットが或るバージョンの標準仕様では選択的(オプション)であるが、別のバージョンの標準仕様では必須かもしれないことである。そのようなVSCは、WSAとは別の１つ以上の拡張モジュールによって処理及び強制され、潜在的な標準仕様の変化を適切に収容する。
【００８４】
データスキーマ確認モジュールは、リクエストで指定されているフィールドが１つ以上のデータスキーマに基づいて有効か否かを確認するモジュールである。例えば、データスキーマ確認モジュールは、SOAPリクエストが適切にフォーマットされているか否かを確認し、適切にフォーマットされていなかった場合、そのSOAPリクエストは除外され、エラーメッセージがクライアントに送付されてもよい。別の例として、印刷サービスに関連するデータスキーマ確認モジュールは、リクエストで指定されているフィールドが或る印刷標準仕様に基づいて有効であるか否かを確認する。或る無効なフィールドは無視され(即ち、WSAはそのリクエストを処理し続けてよい)、別の無効なフィールドは無視されない(例えば、WSAはエラーメッセージをクライアントに返す)。
【００８５】
一実施例では、WS標準仕様のコアビジネスロジックは、複数の実行ファイルとして実現される。関連する例の場合、WS標準仕様のコアビジネスロジックは、(静的な又は動的な)複数のライブラリルーチンを起動する１つの実行ファイルとして実現される。複数のライブラリルーチンを利用する利点は、プロセス間のやりとりを回避できることであり、プロセス間の通信は、複数のライブラリルーチンを起動することよりも遅くなりがちである。
【００８６】
８．０ 実現手段
上記の手法は如何なるタイプのコンピュータプラットフォーム又はアーキテクチャでも実現されてよい。図５は本発明の一実施例が使用されるコンピュータシステム５００を示すブロック図である。コンピュータシステム５００は、情報を通信するためのバス５０２又は他の通信手段と、バス５０２に結合された情報を処理するプロセッサ５０４とを有する。コンピュータシステム５００は、ランダムアクセスメモリ(RAM)又は他のダイナミックストレージデバイスのようなバス５０２に結合されたメインメモリ５０６を有し、メインメモリはプロセッサ５０４で実行される命令や情報を格納する。メインメモリ５０６は、プロセッサ５０４で実行される命令の実行中に、一時的な変数又は他の中間的な情報を格納するのに使用されてもよい。コンピュータシステム５００は、プロセッサ５０４のための命令や静的な情報を格納する、バス５０２に結合されたリードオンリメモリ(ROM)５０８又は他のスタティックストレージデバイスを更に含む。磁気ディスク又は他の光ディスクのようなストレージデバイス５１０は、情報及び命令を格納するために用意されてバス５０２に結合される。
【００８７】
コンピュータシステム５００は、ユーザに情報を表示するために、陰極線管(CRT)のようなディスプレイ５１２にバス５０２を介して結合されてもよい。英数字その他のキーを含む入力装置５１４は、情報及び命令選択内容をプロセッサ５０４に通知するためにバス５０２に結合される。他の種類のユーザ入力装置は、カーソル制御装置５１６（例えば、マウス、トラックボール、スタイラス又はカーソル方向キー）であり、指示情報及び命令選択をプロセッサ５０４に通知し且つディスプレイ５１２でのカーソルの動きを制御する。この入力装置は典型的には第１軸（例えば、ｘ）及び第２軸（例えば、ｙ）の２軸による２つの自由度を有し、装置が平面上の位置を指定できるようにする。
【００８８】
本発明は無線通信アーキテクチャのコンピュータシステム５００を利用することに関連する。本発明の一実施例によれば、メインメモリ５０６に含まれる１以上の命令の１以上のシーケンスを実行するプロセッサ５０４に応じて、無線通信がコンピュータシステム５００によって提供される。そのような命令は、ストレージデバイス５１０のような他のマシン読取可能な媒体からメインメモリ５０６に読み込まれてもよい。メインメモリ５０６に含まれている命令シーケンスの実行は、本願で説明されるプロセスステップをプロセッサ５０４が実行することを引き起こす。代替実施例では、本発明を実施するために、ハードワイヤード回路が、代替的に使用されてもよいし或いはソフトウエア命令との組み合わせで使用されてもよい。すなわち本発明の実施例はハードウエア回路及びソフトウエアの特定の如何なる組み合わせにも限定されない。
【００８９】
ここで使用されているように「マシン読取可能な媒体」なる用語は、特定の形式でマシンが命令を実行することを引き起こすデータを用意することに関与する如何なる媒体にも関連する。コンピュータシステム５００を使用する実施例の場合、様々なマシン読取可能な媒体が、例えばプロセッサ５０４の実行する命令を提供するように含まれる。そのような媒体は多くの形態をとってよく、限定ではないが、不揮発性媒体、揮発性媒体及び伝送媒体を含む。不揮発性媒体は、例えば、ストレージデバイス５１０のような光又は磁気ディスクを含む。揮発性媒体は、メインメモリ５０６のようなダイナミックメモリを含む。伝送媒体は、同軸ケーブル、銅線及び光ファイバを含み、バス５０２を構成するワイヤを含む。伝送媒体は、無線電波及び赤外線データ通信の際に生成されるもののような、音波又は光波の形式をとってもよい。
【００９０】
マシン読取可能な媒体の一般的な形態は、フロッピディスク、フレキシブルディスク、ハードディスク、磁気テープその他の如何なる磁気媒体、CD-ROMその他の如何なる光媒体、パンチカード、紙テープ又は穴のパターンを有する他の如何なる物理的媒体、RAM、PROM、EPROM、フラッシュEPROMその他のメモリチップ、カートリッジ、上記のような搬送波又はコンピュータが読み取ることの可能な他の如何なる媒体でも含む。
【００９１】
マシン読取可能な様々な形態は、１以上の命令の１以上のシーケンスをプロセッサ５０４に実行に備えて搬送する際にも適用可能である。例えば命令は初期には遠く離れたリモートコンピュータの磁気ディスクで搬送されてもよい。リモートコンピュータは自身のダイナミックメモリからその命令をロードし、モデムを用いて電話回線を介して命令を送信してもよい。コンピュータシステム５００付近のモデムは電話回線でそのデータを受信し、赤外線送信機を用いてそのデータを赤外線信号に変換する。赤外線検出器は、赤外線信号で搬送されたデータを受信し、適切な回路がそのデータをバス５０２に置く。バス５０２はデータをメインメモリ５０６に運び、プロセッサ５０４はメインメモリから命令を抽出して実行する。メインメモリ５０６で受信された命令は、プロセッサ５０４で実行される前又はその後にストレージデバイス５１０に選択的に格納されてもよい。
【００９２】
コンピュータシステム５００はバス５０２に結合された通信インターフェース５１８も含む。通信インターフェース５１８は、ローカルネットワーク５２２に接続されるネットワークリンク５２０に結合する双方向データ通信をもたらす。例えば、通信インターフェース５１８は、データ通信接続を対応するタイプの電話回線に与える統合サービスディジタルネットワーク(ISDN)カード又はモデムでもよい。別の例では、通信インターフェース５１８は、データ通信接続をコンパチブルなLANに与えるLANカードでもよい。無線リンクが使用されてもよい。どの実現手段でも、通信インターフェース５１８は、電気的な、電磁的な又は光学的な信号を送信及び受信し、様々なタイプの情報を表現するディジタルデータストリームを運ぶ。
【００９３】
ネットワークリンク５２０は典型的には１以上のネットワークを介して他のデータ装置とのデータ通信をもたらす。例えば、ネットワークリンク５２０はローカルネットワーク５２２を介してホストコンピュータとのコネクションを提供する、或いはインターネットサービスプロバイダ(ISP)５２６により運営されるデータ機器とのコネクションを提供する。そしてISP５２６はデータ通信サービスをワールドワイドパケットデータ通信ネットワーク(今日、「インターネット」５２８として一般に言及されている)を介して提供する。ローカルネットワーク５２２及びインターネット５２８の双方は、ディジタルデータストリームを搬送する、電気的な、電磁的な又は光学的な信号を使用する。様々なネットワークを介する信号や、ネットワークリンク５２０における通信インターフェース５１８を介する信号は、コンピュータシステム５００に及びそこからディジタルデータを搬送し、例えば情報を伝送する搬送波の形式をとってもよい。
【００９４】
コンピュータシステム５００は、ネットワーク、ネットワークリンク５２０及び通信インターフェースを介して、メッセージを送信し及びプログラムコードを含むデータを受信する。インターネットの例では、サーバー５３０はインターネット５２８、ISP５２６、ローカルネットワーク５２２及び通信インターフェース５１８を介して、アプリケーションプログラムに関する要求されたコードを送信するかもしれない。
【００９５】
プロセッサ５０４は受信したコードを受信したときに実行してもよいし、後の実行に備えてストレージデバイス５１０又は他の不揮発性ストレージに格納していたかのように実行してもよい。このようにコンピュータシステム５００は搬送波の形式でアプリケーションコードを取得してもよい。
【００９６】
以上本発明の特定の具体的な実施例が、実施例毎に異なってもよい多くの具体的詳細と共に説明された。独占排他権の対象である本願発明であり且つ本願発明であるとして出願人の意図するものは本願により許可される特許請求の範囲であり、特許請求の範囲の具体的内容は出願後の如何なる補正をも含む請求項に記載された事項で特定される。特許請求の範囲に含まれている用語に関し、明細書で記述した明示的な如何なる定義も、特許請求の範囲で使用される用語の意味を規定する。従って、特許請求の範囲で明示的には言及されていない限定、要素、性質、特徴、利点及び属性の如何なるものも、特許請求の範囲を限定するよう（どのような方法によっても）解釈されるべきでない。従って明細書及び図面は限定的な意味ではなく例示として解釈されるべきである。
【図面の簡単な説明】
【００９７】
【図１】SOAPリクエストを処理する本発明の一実施例によるアーキテクチャ例100を示すブロック図である。
【図２】リクエストを処理する本発明の一実施例によるオーケストレーションモジュール例を示すブロック図である。
【図３】リクエスト中の“非予測的な”‘優先度’フィールドを処理する本発明の一実施例によるフローチャートである。
【図４】イベント加入リクエストに組み込まれているスキャン宛先登録を処理する本発明の一実施例によるフローチャートである。
【図５】本発明の一実施例が使用されるコンピュータシステムを示すブロック図である。
【符号の説明】
【００９８】
１００ アーキテクチャ
１０２ クライアント
１０４ アドミニストレータ
１０６ デバイスファシリティマネジャ(DFM)
１０８ MFPで実行する複数のウェブサービスアプリケーション
１２２ WSイベンティング部
１２４ アブストラクトAPI
１２６ オーケストレーションモジュール
１３０ レガシープラットフォーム
１３２，１４２，１５２ ゼネラルAPI実現手段
１３４，１４４，１５４ アブストラクトAPI実現手段
１４０ リナックスベースのプラットフォーム
１５０ VxWorksベースのプラットフォーム
５００ コンピュータシステム
５０２ バス
５０４ プロセッサ
５０６ メインメモリ
５０８ リードオンリメモリ
５１０ ストレージデバイス
５１２ ディスプレイ
５１４ 入力装置
５１６ カーソル制御部
５１８ 通信インターフェース
５２０ ネットワークリンク
５２２ ローカルネットワーク
５２４ ホスト
５２６ インターネットサービスプロバイダ
５２８ インターネット
５３０ サーバー
【特許請求の範囲】
【請求項１】
シンプルオブジェクトアクセスプロトコル(SOAP)リクエストを処理するネットワーク装置であって、
第１ロジックを含むウェブサービスアプリケーション(WSA)と、
１つ以上の拡張モジュールと、
前記WSA及び前記１つ以上の拡張モジュール間の通信を制御するオーケストレーションモジュールと、
を有し、前記１つ以上の拡張モジュール中の或る拡張モジュールは第２ロジックを有し、
前記WSAは該WSAにより提供されるサービスを求めるSOAPリクエストを処理するよう構成され、
前記オーケストレーションモジュールは、
前記SOAPリクエストの１つ以上の属性に基づいて、前記SOAPリクエストの一部を処理するために、前記１つ以上の拡張モジュールの中の或る拡張モジュールを特定し、
該或る拡張モジュールが前記SOAPリクエストの一部を処理することを引き起こし、
該或る拡張モジュールが前記第２ロジックにより前記SOAPリクエストの一部を処理し終えた後、前記WSAが前記SOAPリクエストを更に処理することを引き起こすように構成されている
ことを特徴とするネットワーク装置。
【請求項２】
前記WSAは、或る特定のバージョンのウェブサービス仕様を実現し、該ウェブサービス仕様は現在のバージョンの前記ウェブサービス仕様に先行するものであり、
前記第２ロジックは、前記特定のバージョン及び前記現在のバージョンの間の不一致に対処するものである請求項１記載のネットワーク装置。
【請求項３】
当該ネットワーク装置が、少なくとも１つのサービスを提供するWSAを複数個有し、
該複数の内の或るWSAは、印刷データを処理する印刷プロセスを含み、前記印刷データを反映した印刷バージョンの電子書類が生成されることを引き起こすようにした請求項１記載のネットワーク装置。
【請求項４】
前記オーケストレーションモジュールが複数の対応関係を有し、
該複数の対応関係の各対応関係は、１つ以上のフィールドと１つ以上のモジュールとを関連付け、
前記オーケストレーションモジュールは或る拡張モジュールを識別するように構成され、前記オーケストレーションモジュールは、
前記SOAPリクエストの特定のフィールドを識別し、
該特定のフィールドに基づいて、前記複数の対応関係の内の特定の対応関係を特定し、
前記特定の対応関係に基づいて、１つ以上の特定のモジュールを特定するように構成され、
前記１つ以上の特定のモジュールは前記拡張モジュールを含むようにした請求項１記載のネットワーク装置。
【請求項５】
前記SOAPリクエストを受信し、前記オーケストレーションモジュールの動作を引き起こすように、前記WSAが構成されている請求項１記載のネットワーク装置。
【請求項６】
前記オーケストレーションモジュールが、前記SOAPリクエストを受信するように構成されている請求項１記載のネットワーク装置。
【請求項７】
シンプルオブジェクトアクセスプロトコル(SOAP)リクエストを処理するネットワーク装置であって、
複数のモジュールを有するウェブサービスアプリケーション(WSA)と、
前記複数のモジュールの内の２つ以上のモジュールの間での間接的な通信を制御するオーケストレーションモジュールと、
を有し、前記複数のモジュールの内の第１モジュールは、
前記WSAにより提供されるサービスを求めるSOAPリクエストを処理し、
前記オーケストレーションモジュールが動作することを促すように構成され、
前記オーケストレーションモジュールは、
前記SOAPリクエストの１つ以上の属性に基づいて、前記SOAPリクエストの一部を処理するために、前記複数のモジュールの中で第２モジュールを特定し、
該第２モジュールが前記SOAPリクエストの一部を処理することを引き起こし、
該第２モジュールが前記SOAPリクエストの一部を処理し終えた後、前記第１モジュールが前記SOAPリクエストを処理し続けることを引き起こすように構成されている
ことを特徴とするネットワーク装置。
【請求項８】
前記WSAは、或る特定のバージョンのウェブサービス仕様を実現し、該ウェブサービス仕様は現在のバージョンの前記ウェブサービス仕様に先行するものであり、
前記第１モジュール及び前記第２モジュール間の前記間接的な通信は、現在のバージョン及び前記特定のバージョンの間の不一致に対処するものである請求項７記載のネットワーク装置。
【請求項９】
当該ネットワーク装置が、少なくとも１つのサービスを提供するWSAを複数個有し、
該複数の内の或るWSAは、印刷データを処理する印刷プロセスを含み、前記印刷データを反映した印刷バージョンの電子書類が生成されることを引き起こすようにした請求項７記載のネットワーク装置。
【請求項１０】
前記オーケストレーションモジュールが複数の対応関係を有し、
該複数の対応関係の各対応関係は、１つ以上のフィールドと１つ以上のモジュールとを関連付け、
前記オーケストレーションモジュールは或る第２モジュールを識別するように構成され、前記オーケストレーションモジュールは、
前記SOAPリクエストの特定のフィールドを識別し、
該特定のフィールドに基づいて、前記複数の対応関係の内の特定の対応関係を特定し、
前記特定の対応関係に基づいて、１つ以上の特定のモジュールを特定するように構成され、
前記１つ以上の特定のモジュールは前記第２モジュールを含むようにした請求項７記載のネットワーク装置。
【請求項１１】
前記SOAPリクエストを受信し、前記オーケストレーションモジュールの動作を引き起こすように、前記WSAが構成されている請求項７記載のネットワーク装置。
【請求項１２】
前記オーケストレーションモジュールが、前記SOAPリクエストを受信するように構成されている請求項７記載のネットワーク装置。
【請求項１３】
リクエストを処理するネットワーク装置であって、
特定のバージョンの仕様を実現するウェブサービスアプリケーション(WSA)と、
ファームウエア構成要素と、
を有し、前記WSAは、１つ以上のサービスを提供するように、該ファームウエア構成要素と通信を行い、前記WSAは、
該WSAにより提供されるサービスを求めるリクエストを処理し、
或るマッピングに基づいて、前記ファームウエア構成要素が処理可能なデータに或る値を変換するよう構成され、前記リクエストは前記特定のバージョンの仕様ではサポートされていないフィールドを含み、該フィールドの前記値は前記ファームウエア構成要素によりサポートされ、
前記ファームウエア構成要素は、前記データに基づいて前記リクエストを処理するよう構成されているネットワーク装置。
【請求項１４】
前記特定のバージョンは、前記仕様の現在のバージョン又は該現在のバージョンに先行するバージョンの何れかである請求項１３記載のネットワーク装置。
【請求項１５】
当該ネットワーク装置が、少なくとも１つのサービスを提供するWSAを複数個有し、
該複数の内の或るWSAは、印刷データを処理する印刷プロセスを含み、前記印刷データを反映した印刷バージョンの電子書類が生成されることを引き起こすようにした請求項１３記載のネットワーク装置。
【請求項１６】
前記仕様がウェブサービス標準仕様である請求項１３記載のネットワーク装置。
【請求項１】
シンプルオブジェクトアクセスプロトコル(SOAP)リクエストを処理するネットワーク装置であって、
第１ロジックを含むウェブサービスアプリケーション(WSA)と、
１つ以上の拡張モジュールと、
前記WSA及び前記１つ以上の拡張モジュール間の通信を制御するオーケストレーションモジュールと、
を有し、前記１つ以上の拡張モジュール中の或る拡張モジュールは第２ロジックを有し、
前記WSAは該WSAにより提供されるサービスを求めるSOAPリクエストを処理するよう構成され、
前記オーケストレーションモジュールは、
前記SOAPリクエストの１つ以上の属性に基づいて、前記SOAPリクエストの一部を処理するために、前記１つ以上の拡張モジュールの中の或る拡張モジュールを特定し、
該或る拡張モジュールが前記SOAPリクエストの一部を処理することを引き起こし、
該或る拡張モジュールが前記第２ロジックにより前記SOAPリクエストの一部を処理し終えた後、前記WSAが前記SOAPリクエストを更に処理することを引き起こすように構成されている
ことを特徴とするネットワーク装置。
【請求項２】
前記WSAは、或る特定のバージョンのウェブサービス仕様を実現し、該ウェブサービス仕様は現在のバージョンの前記ウェブサービス仕様に先行するものであり、
前記第２ロジックは、前記特定のバージョン及び前記現在のバージョンの間の不一致に対処するものである請求項１記載のネットワーク装置。
【請求項３】
当該ネットワーク装置が、少なくとも１つのサービスを提供するWSAを複数個有し、
該複数の内の或るWSAは、印刷データを処理する印刷プロセスを含み、前記印刷データを反映した印刷バージョンの電子書類が生成されることを引き起こすようにした請求項１記載のネットワーク装置。
【請求項４】
前記オーケストレーションモジュールが複数の対応関係を有し、
該複数の対応関係の各対応関係は、１つ以上のフィールドと１つ以上のモジュールとを関連付け、
前記オーケストレーションモジュールは或る拡張モジュールを識別するように構成され、前記オーケストレーションモジュールは、
前記SOAPリクエストの特定のフィールドを識別し、
該特定のフィールドに基づいて、前記複数の対応関係の内の特定の対応関係を特定し、
前記特定の対応関係に基づいて、１つ以上の特定のモジュールを特定するように構成され、
前記１つ以上の特定のモジュールは前記拡張モジュールを含むようにした請求項１記載のネットワーク装置。
【請求項５】
前記SOAPリクエストを受信し、前記オーケストレーションモジュールの動作を引き起こすように、前記WSAが構成されている請求項１記載のネットワーク装置。
【請求項６】
前記オーケストレーションモジュールが、前記SOAPリクエストを受信するように構成されている請求項１記載のネットワーク装置。
【請求項７】
シンプルオブジェクトアクセスプロトコル(SOAP)リクエストを処理するネットワーク装置であって、
複数のモジュールを有するウェブサービスアプリケーション(WSA)と、
前記複数のモジュールの内の２つ以上のモジュールの間での間接的な通信を制御するオーケストレーションモジュールと、
を有し、前記複数のモジュールの内の第１モジュールは、
前記WSAにより提供されるサービスを求めるSOAPリクエストを処理し、
前記オーケストレーションモジュールが動作することを促すように構成され、
前記オーケストレーションモジュールは、
前記SOAPリクエストの１つ以上の属性に基づいて、前記SOAPリクエストの一部を処理するために、前記複数のモジュールの中で第２モジュールを特定し、
該第２モジュールが前記SOAPリクエストの一部を処理することを引き起こし、
該第２モジュールが前記SOAPリクエストの一部を処理し終えた後、前記第１モジュールが前記SOAPリクエストを処理し続けることを引き起こすように構成されている
ことを特徴とするネットワーク装置。
【請求項８】
前記WSAは、或る特定のバージョンのウェブサービス仕様を実現し、該ウェブサービス仕様は現在のバージョンの前記ウェブサービス仕様に先行するものであり、
前記第１モジュール及び前記第２モジュール間の前記間接的な通信は、現在のバージョン及び前記特定のバージョンの間の不一致に対処するものである請求項７記載のネットワーク装置。
【請求項９】
当該ネットワーク装置が、少なくとも１つのサービスを提供するWSAを複数個有し、
該複数の内の或るWSAは、印刷データを処理する印刷プロセスを含み、前記印刷データを反映した印刷バージョンの電子書類が生成されることを引き起こすようにした請求項７記載のネットワーク装置。
【請求項１０】
前記オーケストレーションモジュールが複数の対応関係を有し、
該複数の対応関係の各対応関係は、１つ以上のフィールドと１つ以上のモジュールとを関連付け、
前記オーケストレーションモジュールは或る第２モジュールを識別するように構成され、前記オーケストレーションモジュールは、
前記SOAPリクエストの特定のフィールドを識別し、
該特定のフィールドに基づいて、前記複数の対応関係の内の特定の対応関係を特定し、
前記特定の対応関係に基づいて、１つ以上の特定のモジュールを特定するように構成され、
前記１つ以上の特定のモジュールは前記第２モジュールを含むようにした請求項７記載のネットワーク装置。
【請求項１１】
前記SOAPリクエストを受信し、前記オーケストレーションモジュールの動作を引き起こすように、前記WSAが構成されている請求項７記載のネットワーク装置。
【請求項１２】
前記オーケストレーションモジュールが、前記SOAPリクエストを受信するように構成されている請求項７記載のネットワーク装置。
【請求項１３】
リクエストを処理するネットワーク装置であって、
特定のバージョンの仕様を実現するウェブサービスアプリケーション(WSA)と、
ファームウエア構成要素と、
を有し、前記WSAは、１つ以上のサービスを提供するように、該ファームウエア構成要素と通信を行い、前記WSAは、
該WSAにより提供されるサービスを求めるリクエストを処理し、
或るマッピングに基づいて、前記ファームウエア構成要素が処理可能なデータに或る値を変換するよう構成され、前記リクエストは前記特定のバージョンの仕様ではサポートされていないフィールドを含み、該フィールドの前記値は前記ファームウエア構成要素によりサポートされ、
前記ファームウエア構成要素は、前記データに基づいて前記リクエストを処理するよう構成されているネットワーク装置。
【請求項１４】
前記特定のバージョンは、前記仕様の現在のバージョン又は該現在のバージョンに先行するバージョンの何れかである請求項１３記載のネットワーク装置。
【請求項１５】
当該ネットワーク装置が、少なくとも１つのサービスを提供するWSAを複数個有し、
該複数の内の或るWSAは、印刷データを処理する印刷プロセスを含み、前記印刷データを反映した印刷バージョンの電子書類が生成されることを引き起こすようにした請求項１３記載のネットワーク装置。
【請求項１６】
前記仕様がウェブサービス標準仕様である請求項１３記載のネットワーク装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図２】
【図３】
【図４】
【図５】
【公開番号】特開２００９−３２２５６（Ｐ２００９−３２２５６Ａ）
【公開日】平成２１年２月１２日（２００９．２．１２）
【国際特許分類】
【出願番号】特願２００８−１８５３４２（Ｐ２００８−１８５３４２）
【出願日】平成２０年７月１６日（２００８．７．１６）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．リナックス
【出願人】（０００００６７４７）株式会社リコー (37,907)
【Ｆターム（参考）】
【公開日】平成２１年２月１２日（２００９．２．１２）
【国際特許分類】
【出願日】平成２０年７月１６日（２００８．７．１６）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．リナックス
【出願人】（０００００６７４７）株式会社リコー (37,907)
【Ｆターム（参考）】
[ Back to top ]