JP2012053511A - サーバ装置、情報処理装置、サービス処理装置、ネットワークシステム、ジョブ処理方法及びプログラム - Google Patents

Abstract

【課題】 情報処理装置と各サービス処理装置が連携して実行すべきクライアントとサービスとの依存性を低下させることができる。
【解決手段】 情報処理装置から要求されるジョブに従い、当該ジョブを連携して処理するサービス処理装置を管理するサーバ装置１８１のＲＳＶ３２０は、記憶手段に記憶された連携サービス情報に従いＰＣ１３０が連携サービスを要求すべき情報処理装置の所在情報と連携処理を示すセッション情報と、サービス処理の進捗状態を示すオーダ情報を含むメッセージ３２２を生成する。そして、ＲＳＶ３２０が生成されるメッセージ３３１を前記情報処理装置に指示する。そして、ＰＣ１３０から連携処理情報に対する応答情報を取得する。さらに、ＰＣ１３０から取得する応答情報に従い、ＲＳＶ３２０が生成する次のメッセージ３３５をＰＣ１３３に指示する。
【選択図】 図３

Description

本発明は、サーバ装置、情報処理装置、サービス処理装置とが連携してサービス処理を実行するネットワークシステム、ジョブ処理方法及びプログラムに関する。

従来の連携サービスシステムには、サービス間をジョブが直接送受信されるシステムがある（例えば、特許文献１参照）。これは、クライアントがジョブを作成する際に、連携サービスの利用手順、利用手続きをジョブに入れ、受信したサーバがそのジョブの利用手続きにしたがって処理を行い、ジョブの利用手順にしたがって次のサーバへジョブを引き渡すものである。これによってサービスは次のサービスについての詳細は認識せずとも良く、ジョブの内容にしたがって次のサービスへ処理要求を行えばよい。したがって、サービス・サービス間の依存性を低くすることができる。
連携システムにおいて、例えばサービスの利用手順の変更、サービスのURLの変更された場合を想定する。例えばサービスを完了するまでの利用手順が変更されると、そのサービスに対して前段に位置するサービス、つまり変更されるサービスに対して処理を要求するサービスは、前記変更された新しい利用手順で要求を行う必要がある。つまりある１つのサービスの利用手順を変更する場合、そのサービスを使用した連携サービスを提供するためには、連携に関連した別のサービスも合わせて変更されなくてはならない。

同様にある１つのサービスのURLが変更されれば、連携に関連した別のサービスも前記変更後のURLを認識するように変更しなければならない。このようにサービス・サービス間の依存性が大きいと、ある１つのサービスの変更によって他のサービスの変更を余儀なくされることになり、変更工数の増加、変更時におけるシステム全体の停止などによる稼働率の低下、を招くことになる。

特開平８−２４９２９０号公報

従来例では、クライアントはあるサービスの要求を行う際にそれが連携サービスであることを認識し、どのような順番で行えばサービスの提供を受けることができるのかを把握している必要がある。例えばサービスAというものがあり、それはサービス１の実行結果をふまえてサービス２を実行し、次にそのサービス２の実行結果をふまえてサービス３を実行し、その結果を受け取ることにより実現される、という例を考える。

この場合、クライアントはまずサービス１、サービス２、サービス３を使用するという認識が必要であり、またこれらの実行順序を把握していなければサービスAの要求を作成することはできない。また、サービス２を提供するサーバのURLが変更になった場合や、同じサービス２を提供するサーバが複数ある場合に負荷状況や稼動状況などによって最適なサーバを選択する場合には、クライアントはそれらの情報を考慮に入れて要求を作成しなくてはならない。つまりクライアント・サービス間の依存性が大きい、という課題があった。

本発明は、上記の課題を解決するためになされたもので、本発明の目的は、情報処理装置と各サービス処理装置が連携して実行すべきクライアントとサービスとの依存性を低下させることができる。

上記目的を達成する本発明のサーバ装置は以下に示す構成を備える。
情報処理装置から要求されるジョブに従い、当該ジョブを連携して処理するサービス処理装置を管理するサーバ装置であって、前記ジョブ処理要求で特定される連携サービス処理を実行すべき複数のサービス処理装置の所在情報を含む連携サービス情報を記憶する記憶手段と、前記記憶手段に記憶された連携サービス情報に従い前記情報処理装置が連携サービスを要求すべきサービス処理装置の所在情報と連携処理を示すセッション情報と、サービス処理の進捗状態を示すオーダ情報を含む連携処理情報を生成する生成手段と、前記生成手段により生成される連携処理情報を前記情報処理装置に送信し、該情報処理装置に処理を指示する指示手段と、前記情報処理装置から前記連携処理情報に対する応答情報を取得する取得手段とを備え、前記指示手段は、前記取得手段が取得する応答情報に従い次に処理すべき処理を特定し、前記情報処理装置に該特定した処理を指示する。

上記目的を達成する本発明の情報処理装置は以下に示す構成を備える。
ジョブを実行するために連携すべきサービス処理を実行するサービス処理装置を管理するサーバ装置と通信する情報処理装置であって、前記サーバ装置から指示される連携処理情報に従い特定されるサービス処理装置に対してサービス処理を要求する要求手段と、前記サービス処理装置から前記サービス処理に対する前記連携処理情報を含む応答情報を前記サービス処理装置から受信する受信手段と、前記受信手段が受信した前記連携処理情報を含む応答情報を前記サーバ装置に通知する通知手段とを備え、前記要求手段は、前記サーバ装置から指示される次の連携処理情報に従い前記ジョブ処理要求に対して連携してサービス処理を実行する次のサービス処理装置へ接続して連携サービスを要求することを特徴とする。

上記目的を達成する本発明のサービス処理装置は以下に示す構成を備える。
サーバ装置で特定されて指示される連携処理情報に従う情報処理装置からの依頼に応じて連携すべきサービス処理を実行するサービス処理装置であって、前記情報処理装置から依頼されるサービス処理を実行する実行手段と、前記実行手段によるサービス処理実行後、前記情報処理装置から要求されるサービス処理に対して前記サーバ装置に通知すべき連携処理情報を含む応答情報を生成する生成手段と、前記生成手段が生成した前記連携処理情報を含む応答情報を前記情報処理装置に通知する通知手段と、を備えることを特徴とする。

本発明によれば、情報処理装置と各サービス処理装置が連携して実行すべきクライアントとサービスとの依存性を低下させることができる。

本実施形態を示すネットワークシステムの一例を示す図である。 図１に示した情報処理装置のハードウエア構成を説明するブロック図である。 本実施形態を示すプリントジョブ処理シーケンスの一例を示す図である。 サーバ装置のデータ処理手順の一例を示すフローチャートである。 情報処理装置のデータ処理手順の一例を示すフローチャートである。 サーバ装置で処理されるセッション情報の一例を示す図である。

次に本発明を実施するための最良の形態について図面を参照して説明する。
＜システム構成の説明＞
〔第１実施形態〕
図１は、本実施形態を示すネットワークシステムの一例を示す図である。本実施形態では、ネットワークに接続される複数の情報処理装置で実行されるサービス処理を連携して一連のデータ処理を実行するサービス処理システムの例である。具体的には、１つのジョブを実行するためにクライアントとしての情報処理装置（ＰＣ）が複数のサービス処理装置におけるサービス処理を連携するために、ルーティングサーバとして機能するサーバ装置がネットワーク上に設けてなるネットワークシステムである。ここで、サーバ装置は、サービス要求元のＰＣと、当該ＰＣから要求されるサービス処理を実行する複数のＰＣ（サービス処理装置）との連携処理状況並びに、１つのジョブ処理を複数のＰＣで連携するためのサービス処理実行先等を一元管理する。これにより、クライアントとしての情報処理装置と各サービス処理装置が連携して実行すべき各サービスとの依存性を低下させることが可能となる。

以下、サーバ装置１８１がプッシュプリントジョブをサービス要求元のＰＣ１３０から受付て、サーバ装置１８１からメッセージとして指示される連携処理情報に従いＰＣ１３０がサービス処理装置に接続してサービス処理を実行する実施形態について詳述する。なお、連携処理情報については、図３，図４において詳述する。
図１において、１００はデータ処理システムで、１１０は画像処理装置（ＭＦＰ）で、コピー、プリント、センド、ボックス、プルプリントなどを機能として持つ。ＰＣ１２０は1つ以上のサービスを提供するサーバ装置、１３０はサービス処理を要求するクライアント装置（ＰＣ）であり、それぞれＬＡＮ１０８に接続されている。

１０９はファイアウォールであり、ＬＡＮ１０８を外部のインターネット１９９に接続する。また、ＬＡＮ１０８はファイアウォール１０９、インターネット１９９を介して更に別のネットワーク１７０、１８０に接続される。ネットワーク１７０、１８０の内部構成は、ネットワーク１００と同様な構成である。
ネットワーク１７０には、情報処理装置（ＰＣ）１７１、１７２がＬＡＮ１７８に接続されている。同様に、ネットワーク１８０には、特定のサービス処理を実行するサーバとして機能するサーバ装置１８１，情報処理装置（ＰＣ）１８２、及び情報処理装置（ＰＣ）１８３、１８４がＬＡＮ１８８に接続されている。なお、外部のインターネットとはファイアウォール１７９、１８９によって接続される。本実施形態では、あるサービス処理を提供する情報処理装置、及びそれら複数のサービス処理を使用した連携サービスを一元管理するルーティングサーバとして機能するサーバ装置がある。以後、一例としてルーティングサーバをＰＣ１８１、サービス処理を実行する情報処理装置をＰＣ１２０、１７１、１７２、１８２、１８３、１８４として説明する。サービス要求元の情報処理装置をＰＣ１３０とする。

このように構成されたネットワークシステムにおいて、サーバ装置１８１は、ＰＣ１３０からの１つのジョブ要求に従い複数のサービス処理を連携すべきサービス処理装置を特定する機能を備える。さらに、サーバ装置１８１は、特定された各サービス処理装置とサービス要求元のＰＣとの間で連携されるサービス処理の実行状況を図３に示すようなシーケンス例に従い一元管理する機能を備える。そして、サーバ装置１８１は、サービス要求元の情報処理装置１３０が管理すべきサービス処理を実行するサービス処理装置を管理する負担を軽減している。したがって、サービス要求元の情報処理装置１３０は、ジョブ処理要求開始前に、何らサービス処理を実行するサービス処理装置の所在を示す情報や１つのジョブを処理するためのサービス処理順序を意識する必要がない。つまり、ルーティングサーバとして機能するサーバ装置は、サービス要求元のＰＣ１３０から要求される１つのジョブを実行する際に、システム状況を踏まえて柔軟なシステムを動的に組み立てることが可能に構成されている。

これにより、サービス処理を実行するサービス処理装置のアクセス先が変更されてもルーティングサーバが自在に対応するために、ＰＣ１３０側はアクセス先の変更、サービスの順序、代替サービスの選択等を意識する必要がなくなる。つまり、クライアントとしての情報処理装置と各サービス処理装置が連携して実行すべき各サービスとの依存性を低下させることが可能となる。

図２は、図１に示した情報処理装置のハードウエア構成を説明するブロック図である。なお、図１におけるＰＣ１２０、１３０、１７１、１７２、１８１、１８２、１８３、１８４の内部構成はこのようになっている。以下、上記ＰＣ１２０、１３０、１７１、１７２、１８１、１８２、１８３、１８４をＰＣ２００として説明する。なお、本実施形態において、ＰＣ１８２、１２０は、サーバ装置で特定されて指示される連携処理情報に従うＰＣ１３０からの依頼に応じて連携すべきサービス処理を実行するサービス処理装置として用いられる。
図２において、ＰＣ２００は、ＲＯＭ２０２もしくはハードディスク（ＨＤ）２１１に記憶された、あるいはフレキシブルディスクドライブ（ＦＤ）２１２より供給される各種ソフトウエアを実行するＣＰＵ２０１を備える。そして、ＣＰＵ２０１は、システムバス２０４に接続される各機器を総括的に制御する。

２０３はＲＡＭで、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。２０５はキーボードコントローラ（ＫＢＣ）で、キーボード（ＫＢ）２０９や不図示のポインティングデバイス等からの指示入力を制御する。
２０６はＣＲＴコントローラ（ＣＲＴＣ）で、ＣＲＴディスプレイ（ＣＲＴ）２１０の表示を制御する。２０７はディスクコントローラ（ＤＫＣ）で、ブートプログラム、本発明の動作を行うプログラム、種々のアプリケーション、編集ファイル、ならびにユーザファイル等を記憶するハードディスク（ＨＤ）２１１とのアクセスを制御する。また、ＤＫＣ２０７は、フレキシブルディスクドライブ（ＦＤ）２１２とのアクセスも制御する。

２０８はネットワークインタフェースカード（ＮＩＣ）で、ＬＡＮ２２０を介して、ネットワークプリンタ、他のネットワーク機器あるいは他のＰＣと双方向にデータをやりとりする。なお、本実施形態においては、ＬＡＮ２２０は図１におけるＬＡＮ１０８、１７８、１８８と同じものである。
以下、従来のネットワークシステムで起こり得る現状の問題、特に、サービス・サービス間の依存性が大きい場合の問題について例を挙げて説明する。サービス・サービス間の依存性が大きい連携システムにおいて、以下のような変更がある１つのサービスについて行われたとする。

例えばサービスの利用手順の変更、サービスのURLの変更である。ここで、連携システムにおいて、利用手順が変更されると、そのサービスに対して前段に位置するサービス、つまり変更されるサービスに対して処理を要求するサービスは、前記変更された新しい利用手順で要求を行う必要がある。つまりある１つのサービスの利用手順を変更する場合、そのサービスを使用した連携サービスを提供するためには、連携に関連した別のサービスも合わせて変更されなくてはならない。
同様にある１つのサービスのURLが変更されれば、連携に関連した別のサービスも前記変更後のURLを認識するように変更しなければならない。このようにサービス・サービス間の依存性が大きいと、ある１つのサービスの変更によって他のサービスの変更を余儀なくされることになり、変更工数の増加、変更時におけるシステム全体の停止などによる稼働率の低下、を招くことになる。

そこで、本実施形態では上記課題を解決すべく、ネットワークシステムにおいてルーティングサービスをサーバ装置１８１が実行する。
ここで本発明にて実現する連携サービス処理の例として、ドキュメントのプッシュプリントを行う連携サービス処理について説明する。このプッシュプリントは次の３つサービスを、次のような順番で構成されるものとする。したがって、連携サービス処理がさらに多くのサービス処理装置と連携するような場合もあり、サービスの数が「３」である場合に限定されるものではない。ここで、プッシュプリントサービスの場合、第１のサービス処理が指定したドキュメントを指定した場所へダウンロードするダウンロードサービスである。また、プッシュプリントサービスの場合、第２のサービス処理が指定したドキュメントを印刷データに変換する変換サービスである。さらに、プッシュプリントサービスの場合、第３のサービス処理が、指定した印刷データを指定したプリンタへ送信するディストリビュートサービスである。以降、前記ダウンロードサービスと、変換サービスは図１のＰＣ１８２が受け持ち、ディストリビュートサービスはＰＣ１２０が受け持つものとして説明する。

また、これらの第１〜第３のサービス処理を実現するプログラムは、各ＰＣを構成するハードウエアとしてのＲＯＭ２０２もしくはハードディスク（ＨＤ）２１１、あるいはフレキシブルディスクドライブ（ＦＤ）２１２に記憶されている。そして、各ＰＣのＣＰＵ２０１がこれらのメモリから読み出す制御プログラムをＲＡＭにロードして実行することで各サービス処理が実行される。なお、各サービス処理の実行順序は、ルーティングサーバとして機能するＰＣ１８１により制御される。なお、この処理の詳細については図３を参照して詳述する。

また、ルーティングサービスを提供するＰＣ１８１もまたルーティングサービスを実現するプログラムがＲＯＭ２０２もしくはハードディスク（ＨＤ）２１１、あるいはフレキシブルディスクドライブ（ＦＤ）２１２に記憶されている。そして、ＰＣ１８１のＣＰＵ２０１がＲＡＭにロードして実行することでルーティングサービスが実現される。

同様にクライアントとして機能するＰＣ１３０もプッシュプリントを要求するプログラムがＲＯＭ２０２もしくはハードディスク（ＨＤ）２１１、あるいはフレキシブルディスクドライブ（ＦＤ）２１２に記憶されている。そして、ＰＣ１３０のＣＰＵ２０１がＲＡＭに制御プログラムをロードして実行することで処理が実現される。
クライアントとしてのＰＣ１３０とサーバとして機能するＰＣ１８１、ＰＣ１８２、ＰＣ１２０との間の通信は、それぞれＮＩＣ２０８を使用してＬＡＮ２２０を介して行われる。ディストリビュートサーバとして機能するＰＣ１２０は、ネットワーク１０８に接続された画像処理装置１１０とも通信も行うが、この通信も同様にＮＩＣ２０８を使用してＬＡＮ２２０を介して行われる。なお、画像処理装置１１０が図示しないネットワーク上に接続されたシステムとして本システムが構築されていてもよい。また、画像処理装置１１０が複数台同一のネットワーク上に接続されていてもよい。つまり、プリントジョブを実行させる際に、各ジョブ処理状況に従い、プリントジョブを分割して処理するようなシステムであってもよい。

図３は、本実施形態を示すネットワークシステムのプリントジョブ処理シーケンスの一例を示す図である。本例は、連携サービスによるジョブ処理（プッシュプリント処理）に対応するシーケンス例である。以下の説明では、ＰＣ１３０のＣＰＵ２０１による処理の主体をクライアント３１０として、ＰＣ１８１のＣＰＵ２０１による処理であって、ルーティングサービスを提供する処理の主体をルーティングサービス３２０として説明する。同様に、ＰＣ１８２のＣＰＵ２０１による処理であって、ダウンロードサービス処理と、変換サービス処理の主体をダウンロードサービス３８０、変換サービス３８２として説明する。同様に、ＰＣ１２０のＣＰＵ２０１による処理であって、ディストリビュートサービス処理の主体をディストリビュートサービス（ＤＳＶ）３８４として説明する。ここで、プッシュプリントは、第１のサービス処理〜第３のサービス処理を連携し、さらにこれらとクライアント３１０との処理順序をルーティングサービス（ＲＳＶ）３２０が制御する例を説明する。なお、クライアントとしてのＰＣ１３０はブラウザ機能を実現可能に構成されている。

なお、本実施形態においては、第１のサービス処理とはダウンロードサービス処理に対応し、第２のサービス処理とは変換サービス処理に対応し、第３のサービス処理とはディストリビュートサービス処理に対応する。また、本実施形態において、メッセージ３３２、３３６、３４０は、情報処理装置としてのＰＣ１３０からサービス処理装置であるＰＣ１８２，１２０に通知される連携処理情報であって、例えばＵＲＩ４８１等で構成される。本実施形態では、連携処理情報をＵＲＩのクエリパラメートに設定する例である。連携情報は、ＰＣ１３０がサービス処理装置に接続するための所在情報と連携処理を示すセッション情報とを含む構成としている。ここで、セッション情報は、セッションＩＤと、サービス処理の進捗情報（サービス処理順序を特定する情報）としてのオーダ情報を含む構成とし、オーダ情報は、ＲＳＶ３２０を実行するサーバ装置１８１により順次構成される。

図３において、クライアント３１０がプッシュプリントをＲＳＶ３２０へ要求する。ここで、プッシュプリントはダウンロードサービス（ＤＷＳＶ）３８０、変換サービス（ＣＳＶ）３８２、ディストリビュートサービス（ＤＳＶ）３８４の順序で処理を実行する連携サービスによって提供される。これを図１に示したネットワークシステム例にあてはめると、このクライアント３１０はＰＣ１３０であり、ＲＳＶ３２０はＰＣ１８１が提供することとなる。３９９はメッセージで、連携サービス処理を実行すべき複数の情報処理装置の所在情報を含む連携サービス情報として用いられ、サーバ装置１８１のメモリ装置に更新可能に記憶されている。つまり、ＰＣ１３０からのジョブ要求が特定されると、サーバ装置１８１は、メモリ装置から連携サービス情報を取得して当該ジョブ要求を連携すべき複数のサービス処理装置の処理経路と処理順序とを決定する。本例は、プッシュプリントジョブ例であるので、連携サービス情報に従い３つのサービス処理を実行するサービス処理装置が特定される例である。

同様にＤＷＳＶ３８０、ＣＳＶ３８２は図１のＰＣ１８２、ＤＳＶ３８４はＰＣ１２０がそれぞれ提供する。
まず、クライアント３１０は、ユーザ３０１の指示またはプログラムからの要求により、ＲＳＶ３２０にメッセージ３３０を送信しプッシュプリントを要求する。メッセージ３３０を受信したＲＳＶ３２０は、処理３２１にてプッシュプリントの連携サービス情報を検索し取得する。連携サービス情報は、１つ以上のサービス処理からなる連携サービス処理の詳細を定義したものである。
また、ＲＳＶ３２０は処理３２２で、クライアント３１０からのメッセージ３３０にて要求を受けたサービスを提供するためにセッション情報を生成し、処理３２１で取得した連携サービス情報をセッション情報の一部として保存する。

ここで、セッション情報は、自身を識別するセッションＩＤを持ち、セッションに関連したデータを管理するための情報で、ルーティングサービスによって保存、取り出し可能であれば良い。ここで、セッション情報の保存場所の一例として、ルーティングサービスを提供するサーバ装置１８１が備えるメモリ装置内などである。
なお、ＲＳＶ３２０が作成するセッション情報には、クライアント３１０から要求する内容で確定されるサービス処理を要求すべきサービス処理装置の所在情報（例えばURL）ばかりでなく、サービスの組み合わせ順序も含まれる。この際、要求元であるクライアント３１０は、サービス処理を要求すべき所在情報（例えばURL）の変更だけではなく、サービスの組み合わせ順序の把握をせずともサービス処理装置にサービス処理を要求できる。

例えばサービスAの構成がサービス１、２、３から成り立っていることや、当該サービスがサービス１→２→３の順序で行う必要があることや、故障などによる代替サービスの選択などを要求元のクライアント３１０は意識する必要がなくなる。

次に、ＲＳＶ３２０は、クライアント３１０に対してメッセージ３３０の応答として、メッセージ３３１を送信する。その内容は、クライアント３１０に対してＤＷＳＶ３８０へのリダイレクト指示であり、また、処理３２２で生成したセッションを識別するセッションＩＤと、ｏｒｄｅｒ情報を合わせて渡している。
ここで、サービス処理の進捗情報として用いられるｏｒｄｅｒ情報とは「０」から始まる数値で連携サービスの順序を表すものである。メッセージ３３１ではｏｒｄｅｒの値は「０」であり、リダイレクト先のＤＷＳＶ３８０は連携サービスの１番目であることを示す。
このようにしてＲＳＶ３２０からメッセージ３３１を受信したクライアント３１０は、そのリダイレクトの指示内容にしたがってＤＷＳＶ３８０へメッセージ３３２を送信する。その際、メッセージ３３１で受信したセッションＩＤとｏｒｄｅｒ＝０を情報として合わせて渡す。クライアント３１０からメッセージ３３２を受信したＤＷＳＶ３８０は、処理３８１を実行する。処理３８１の動作の具体的な実施形は、図1に示したネットワークシステムを例として説明すると以下のようになる。

〔処理３８１の内容〕
サーバ装置１８２は、ＰＣ１３０上と通信を行い、ＰＣ１３０にダウンロードを行うドキュメントとドキュメントの記憶領域を指定させる画面を表示させ、ユーザの操作を待たせる。ユーザの指示によって、ＰＣ１３０はＰＣ１７１内のドキュメントと記憶領域を指定する。ＰＣ１３０により指定された情報により、ＰＣ１８２はＰＣ１３０により指定されたＰＣ１７１内のドキュメントを指定された場所へダウンロードする。そして、ＤＷＳＶ３８０は処理３８１を実行後（サービス処理実行後）、メッセージ３３３をＰＣ１３０に応答する。ここで、ＤＷＳＶ３８０がクライアント３１０（ＰＣ１３０）に応答する内容は、ＲＳＶ３２０へアクセスするリダイレクト指示であり、メッセージ３３２で受信したセッションＩＤとｏｒｄｅｒ＝０も合わせてクライアント３１０へ渡している。

メッセージ３３３を受信したクライアント３１０は、その指示にしたがってＲＳＶ３２０へメッセージ３３４（応答情報）を送信する。メッセージ３３４には、ダウンロードサービス３８０からのメッセージ３３３で受信したメッセージＩＤとｏｒｄｅｒ＝０の情報も記載されている。
クライアント３１０からメッセージ３３４を受信したＲＳＶ３２０は、受信したセッションＩＤから保存してあるセッション情報の連携サービス情報を取り出す。この連携サービス情報とメッセージ３３４のｏｒｄｅｒ情報の値が「０」であるから、次のサービスは2番目に位置しているＣＳＶ３８２であることが分かる。

そこで、ＲＳＶ３２０は、クライアント３１０に対してＣＳＶ３８２へのリダイレクト指示であるメッセージ３３５を作成し、メッセージ３３４の応答としてクライアント３１０に対してメッセージ３３５を送信する。メッセージ３３５は、メッセージ３３４に記載されていたセッションＩＤを持ち、ｏｒｄｅｒ情報は更新してその値を「１」としている。つまり、連携処理が１つ進行したことを示している。
ＲＳＶ３２０からメッセージ３３５を受信したクライアント３１０は、その内容にしたがってＣＳＶ３８２へメッセージ３３６を送信する。メッセージ３３６には、メッセージ３３５に記載されていたセッションＩＤとｏｒｄｅｒ＝１の情報を含んでいる。クライアント３１０からメッセージ３３６を受信したＣＳＶ３８２は、処理３８３を実行する。処理３８３の動作の具体的な実施形は、図1に示したネットワークシステムを例として説明すると以下のようになる。

〔処理３８３の内容〕
サーバ装置１８２は、ＰＣ１３０上と通信を行い、ＰＣ１３０に変換を行うドキュメントと、変換した印刷データを保存する記憶領域を指定させる画面を表示させ、ユーザの操作を待たせる。
そして、ユーザの指示によって、クライアントＰＣ１３０は変換するドキュメントと印刷データを保存する記憶領域を指定する。これらの情報により、サーバ装置１８２は指定されたドキュメントを印刷データに変換し、指定された領域へ保存する。
ＣＳＶ３８２は処理３８３を実行後、メッセージ３３７をクライアント３１０へ応答する。その内容はＲＳＶ３２０へアクセスするリダイレクト指示であり、メッセージ３３６で受信したセッションＩＤとｏｒｄｅｒ＝１も合わせてクライアント３１０へ渡している。

ＣＳＶ３８２からメッセージ３３７を受信したクライアント３１０は、その指示にしたがってＲＳＶ３２０へメッセージ３３８を送信する。メッセージ３３８には、メッセージ３３７で受信したメッセージＩＤとｏｒｄｅｒ＝１の情報も記載されている。クライアント３１０からメッセージ３３８を受信したＲＳＶ３２０は、受信したセッションＩＤから保存してあるセッション情報の連携サービス情報を取り出す。
この連携サービス情報とメッセージ３３８のｏｒｄｅｒ情報の値が「１」であるから、次に要求するべきサービスは３番目に位置しているＤＳＶ３８４であることが分かる。
そこで、ＲＳＶ３２０は、クライアント３１０に対してＤＳＶ３８４へのリダイレクト指示であるメッセージ３３９を作成し、メッセージ３３８の応答として送信する。メッセージ３３９は、メッセージ３３８に記載されていたセッションＩＤを持ち、ｏｒｄｅｒ情報は更新してその値を今度は「２」としている。

ＲＳＶ３２０からメッセージ３３９を受信したクライアント３１０は、その内容にしたがってＤＳＶ３８４へメッセージ３４０を送信する。メッセージ３４０には、メッセージ３３９に記載されていたセッションＩＤとｏｒｄｅｒ＝２の情報を含んでいる。クライアント３１０からメッセージ３４０を受信したＤＳＶ３８４は、処理３８５を実行する。処理３８５の動作の具体的な実施形は、図1に示したネットワークシステムを例として説明すると以下のようになる。

〔処理３８５の内容〕
ＰＣ１２０は、ＰＣ１３０上と通信を行い、ＰＣ１３０上に印刷を実行するプリンタと印刷データを指定させる画面を表示させ、ユーザの操作を待つ。
ユーザの操作により、クライアントＰＣ１３０はＭＦＰ１１０をプリンタとして指定し、ＣＳＶ３８２で得られた印刷データを指定する。これら指定された情報により、ＰＣ１２０は指定されたプリンタ（ＭＦＰ１１０）へ指定した印刷データを送信し、印刷を実行する。
次に、ＤＳＶ３８４は処理３８５実行後、メッセージ３４１をクライアント３１０へ応答として送信する。その内容はＲＳＶ３２０へ再度アクセスするリダイレクト指示であり、メッセージ３４０で受信したセッションＩＤとｏｒｄｅｒ＝２も合わせてクライアント３１０へ渡している。

ＤＳＶ３８４からメッセージ３４１を受信したクライアント３１０は、その指示にしたがってＲＳＶ３２０へメッセージ３４２を送信する。メッセージ３４２には、メッセージ３４１で受信したメッセージＩＤとｏｒｄｅｒ＝２の情報も記載されている。メッセージ３４２を受信したＲＳＶ３２０は、受信したセッションＩＤから保存してあるセッション情報の連携サービス情報を取り出す。

図３の例では連携して提供するサービスの数は「３」であるため、メッセージ３４２のｏｒｄｅｒ情報の値が２であることから、ＲＳＶ３２０は連携サービスが終了したことが分かる。そこで、ＲＳＶ３２０は、完了通知としてメッセージ３４３を作成し、クライアント３１０へ送信し、セッションＩＤで識別されるセッション情報を削除する（処理３２３）。
そして、ＲＳＶ３２０からメッセージ３４３を受信したクライアント３１０は、完了時の処理として完了表示を行う（処理３１１）

図４は、本実施形態を示すサーバ装置のデータ処理手順の一例を示すフローチャートである。本例は、図３のＲＳＶ３２０において、クライアント３１０からの要求を受信した際に行われる処理に対応する。ここで、クライアントの要求とは、図3の例で言えば、メッセージ３３０、３３４、３３８、３４２が該当する。図４では、リダイレクト指示にクエリパラメータを使用した、プッシュプリント〔ｐｕｓｈｐｒｉｎｔ〕の連携サービスを実施形の例としてあげている。
クライアント３１０からＲＳＶ３２０へ最初に連携サービスを要求するメッセージ３３０は、以後サービス開始要求メッセージと呼ぶ。
また、連携サービスの１つの処理が終了し次のサービスへのリダイレクト指示を要求するメッセージ３３４、３３８、３４２を以後、サービス終了メッセージと呼ぶ。なお、図４のフローチャートに示す各処理は、ＰＣ２００のＣＰＵ２０１がＨＤＤ２１１に記憶された図３に示した制御プログラムを実行することにより実現される。なお、制御主体は、図３に示した制御プログラムとして以下の処理を説明する。

ＲＳＶ３２０は、Ｓ４０１でクライアント３１０からのメッセージを受信すると、その内容によって処理を分岐させる。図３のクライアント３１０から送信されるメッセージ３３０（サービス開始要求メッセージ）はＵＲＩ(Uniform Resource Identifier)を持つ。図４では連携処理情報の一例として、クエリパラメータにｓｒｖ＝ｐｕｓｈｐｒｉｎｔが記載されている（ＵＲＩ４８０）。これは、プッシュプリントの開始を要求するサービス開始要求メッセージであることを示している。
Ｓ４０１にてサービス開始要求メッセージを受信したＲＳＶ３２０は、Ｓ４２０へ進み、複数ある連携サービス情報のうち要求されたプッシュプリントの連携サービス情報を取り出す。その後、ＲＳＶ３２０はセッションを生成し、そのセッション情報をメモリ上に保存する。

具体的には、ＲＳＶ３２０は、セッション情報を作成し、生成したセッションを識別するＩＤを発行し（Ｓ４２１）、セッション情報としてメモリ上に保存する（Ｓ４２２）。次に、Ｓ４２３では取得した連携サービス情報から、1番目のサービスを提供するサーバへリダイレクト先を指示する応答（メッセージ３３１）をクライアント３１０へ送信する。その際のリダイレクト先のＵＲＩの一例が、ＵＲＩ４８１である。ＵＲＩ４８１は所在情報の一例であって、セッション情報とオーダ情報とをクエリパラメータで指示した例である。
これは、ｈｔｔｐ：／／ｔｔｔ．ｔｔｔ．ｔｔｔ／ｄｗｌｄ．ａｓｐｘに対して処理を要求し、この連携サービスのセッションはセッションＩＤが「１２３４５」であることを示している。また、この処理のｏｒｄｅｒ情報は「０」、つまり連携サービスの１番目の処理であることを示している。Ｓ４２３が終了後、本処理を終了する。

図３のクライアント３１０から送信されるメッセージ３３４、３３８、３４２（各サービス処理に対するサービス終了メッセージ）のそれぞれはＵＲＩを持つ。
図４では一例として、クエリパラメータにｓｉｄ＝１２３４５、およびｏｒｄｅｒ＝ｎが記載されている（ＵＲＩ４８２）。これは、セッションＩＤ＝１２３４５における連携処理のうちｏｒｄｅｒ＝ｎのサービスが終了したということを通知するサービス終了メッセージであることを示している。ただし、ｎの値はメッセージ３３４、３３８、３４２で異なり、図３の例としてはそれぞれ０、１、２となる。ここで、ｏｒｄｅｒ＝ｎは、サービス処理の進捗状態を示す情報として用いられる。
Ｓ４０１にてサービス終了メッセージを受信したＲＳＶ３２０は、Ｓ４３０へ進む。Ｓ４３０で、ＲＳＶ３２０は、セッションＩＤよってメモリに保持されているセッション情報を読み出す。図４に示すＵＲＩ４８２の例では、セッションＩＤ＝１２３４５のセッション情報を読み出すことになる。

次に、ＲＳＶ３２０は、セッション情報とｏｒｄｅｒ情報から連携する次のサービス処理の有無を判断する（Ｓ４３１）。次の連携サービスが無ければサービス処理は終了しているとＲＳＶ３２０は判断し、Ｓ４４０へ進む。
Ｓ４４０では、ＲＳＶ３２０はクライアント３１０へ完了通知を行い、次に、Ｓ４４１にて、ＲＳＶ３２０はセッション情報を削除し、本処理を終了する。
一方、Ｓ４３１で、次に実行するサービス処理があるとＲＳＶ３２０が判断した場合、Ｓ４３２へ進む。Ｓ４３２で、ＲＳＶ３２０は次のサービス処理のためにセッション情報を更新する。そして、Ｓ４３３で、ＲＳＶ３２０はｏｒｄｅｒの値をｎ＋１、つまりｎ＋２番目のサーバへのリダイレクト指示を示すメッセージ３３５をクライアント３１０へ送信して、本処理を終了する。

なお、図４に示すＵＲＩ４８３は、ＲＳＶ３２０からクライアント３１０に送信されるメッセージ３３５で指示されるリダイレクトの内容の一例である。これは、ｈｔｔｐ：／／ｔｔｔ．ｔｔｔ．ｔｔｔ／ｃｏｎｖ．ａｓｐｘに対して処理を要求し、この連携サービスのセッションはセッションＩＤが「１２３４５」であることを示している。つまり、本メッセージ３３５は、クライアント３１０に対して、変換サービス３８２へのリダイレクトを指示している。

また、この処理のｏｒｄｅｒ情報は「１」、つまり連携サービスの２番目の処理であることを示している。同様にＵＲＩ４８４は、ＲＳＶ３２０からクライアント３１０に送信されるメッセージ３３９で指示されるリダイレクトの内容の一例である。
これは、ｈｔｔｐ：／／ｕｕｕ．ｕｕｕ．ｕｕｕ／ｐｕｓｈ．ａｓｐｘに対して処理を要求し、この連携サービスのセッションはセッションＩＤが「１２３４５」であることを示している。つまり、クライアント３１０に対して、ＤＳＶ３８４へのリダイレクトを指示している。また、この処理のｏｒｄｅｒ情報は「２」、つまり連携サービスの３番目の処理であることを示している。Ｓ４３３を終了後、本処理を終了する。

Ｓ４０１にてＲＳＶ３２０がサービス開始要求メッセージまたはサービス終了メッセージ以外のメッセージを受信したと判断した場合は、ＲＳＶ３２０は、Ｓ４１０へ進む。そして、Ｓ４１０で、ＲＳＶ３２０はクライアント３１０から受信したメッセージに適したその他の処理を実行し、本処理を終了する。なお、Ｓ４１０の一例として、予期しないメッセージを受信した場合としてのエラー応答などがある。

図５は、本実施形態を示す情報処理装置のデータ処理手順の一例を示すフローチャートである。本例は、図３の各ＤＳＶ３８０、ＣＳＶ３８２、ＤＳＶ３８４における、クライアント３１０からの要求を受信した際に行われる処理例である。ここで、クライアント３１０からの要求とは、図3の例で言えば、メッセージ３３２、３３６、３４０が該当する。この図では図４と同様に、リダイレクト指示にクエリパラメータを使用したｐｕｓｈｐｒｉｎｔの連携サービスを実施形の例としてあげている。
また、連携サービスの１つとして処理を要求するメッセージ３３２、３３６、３４０を以後、サービス処理要求メッセージと呼ぶ。図５のフローチャートに示す各処理は、ＰＣ２００のＣＰＵ２０１がＨＤＤ２１１に記憶された制御プログラムを実行することにより実現される。また、制御主体は、図３に示した制御プログラムとして以下の処理を説明する。

Ｓ５０１で、ＲＳＶ３２０は、クライアント３１０からのサービス処理要求メッセージを受信する。サービス処理要求メッセージはＵＲＩを持っている。図５に示す例では、図３のメッセージ３３２、３３６、３４０の例として、それぞれＵＲＩ５８０、ＵＲＩ５８２、ＵＲＩ５８３を示してある。
ここで、ＵＲＩ５８０は、メッセージ３３２に含まれるＵＲＩであり、処理の実行を要求するサービスとして、ｈｔｔｐ：／／ｔｔｔ．ｔｔｔ．ｔｔｔ／ｄｗｌｄ．ａｓｐｘを指定している。また、クエリパラメータとしてｓｉｄ＝１２３４５、およびｏｒｄｅｒ＝０が記載されている。

これは、セッションＩＤ＝１２３４５における連携処理のうちｏｒｄｅｒ＝０のサービスの実行を要求することを示している。同様にＵＲＩ５８２はメッセージ３３６に含まれるＵＲＩであり、処理の実行を要求するサービスとして、ｈｔｔｐ：／／ｔｔｔ．ｔｔｔ．ｔｔｔ／ｃｏｎｖ．ａｓｐｘを指定している。

また、クエリパラメータとしてｓｉｄ＝１２３４５、およびｏｒｄｅｒ＝１が記載されている。これは、セッションＩＤ＝１２３４５における連携処理のうちｏｒｄｅｒ＝１のサービスの実行を要求することを示している。ＵＲＩ５８３はメッセージ３４０に含まれるＵＲＩであり、処理の実行を要求するサービスとして、ｈｔｔｐ：／／ｕｕｕ．ｕｕｕ．ｕｕｕ／ｐｕｓｈ．ａｓｐｘを指定している。
また、クエリパラメータとしてｓｉｄ＝１２３４５、およびｏｒｄｅｒ＝２が記載されている。これは、セッションＩＤ＝１２３４５における連携処理のうちｏｒｄｅｒ＝２のサービスの実行を要求することを示している。

次に、Ｓ５０２で、ＤＳＶ３８０、ＣＳＶ３８２、ＤＳＶ３８４が、クライアント３１０から受信したメッセージの内容をチェックする。例えば、セッションＩＤの記載が無いなど、連携処理を継続できない内容であると判断した場合は、ＮＧとして、Ｓ５１０へ進む。そして、Ｓ５１０でエラー処理を行い、本処理を終了する。
一方、Ｓ５０２で受信した、メッセージの内容がＯＫであるとＤＳＶ３８０、ＣＳＶ３８２、ＤＳＶ３８４が判断した場合は、Ｓ５０３へ進む。そして、Ｓ５０３で、クライアント３１０から要求された処理を実行する。
次に、Ｓ５０４で、ＤＳＶ３８０、ＣＳＶ３８２、ＤＳＶ３８はクライアント３１０に対して、ＲＳＶ３２０へのリダイレクトを指示する応答を送信して、本処理を終了する。図５に示すＵＲＩ５８１は、そのリダイレクト先ＵＲＩの一例である。

ＵＲＩ５８１ではクエリパラメータとしてｓｉｄ＝１２３４５、およびｏｒｄｅｒ＝ｎが記載されている。これは、セッションＩＤ＝１２３４５における連携処理のうちｏｒｄｅｒ＝ｎのサービス処理が完了したことを示している。ただし、ｎの値はメッセージ３３３、３３７、３４１で異なり、図３の例としてはそれぞれｎ＝０、１、２となる。
ここで、図３のシーケンスと合わせて説明すると、ＵＲＩ５８０を含むメッセージ３３２をＳ５０１にて受信したＤＳＶ３８０は、Ｓ５０３にてダウンロードサービスをクライアント３１０に対して提供する。その後、Ｓ５０４にて、ｎ＝０としたＵＲＩ５８１を含むメッセージ３３３をクライアント３１０へ送信する。

同様にＵＲＩ５８２を含むメッセージ３３６を受信したＣＳＶ３８２は、Ｓ５０３にて変換サービスをクライアント３１０に対して提供する。その後、Ｓ５０４にて、ｎ＝１としたＵＲＩ５８１を含むメッセージ３３７をクライアント３１０へ送信する。ＵＲＩ５８３を含むメッセージ３４０を受信したＤＳＶ３８４は、Ｓ５０３にてディストリビュートサービスをクライアント３１０に対して提供する。その後、Ｓ５０４にて、ｎ＝２としたＵＲＩ５８１を含むメッセージ３４１をクライアント３１０へ送信する。

本実施形態によれば、１つのジョブをサービス１〜３を複数のサービス処理装置で連携して処理する場合において、クライアントはまずサービス１、サービス２、サービス３を使用するという認識が必要なくなる。この際、クライアントとしての情報処理装置は、サービスの実行順序を把握する必要がなくなり、クライアント・サービス間の依存性を低くすることができる。逆に言うと、クライアントとしての情報処理装置は、要求するジョブを実行する際に、サービス処理をいずれのサービス処理装置で受ければよいか意識する必要がなくなる。

また、サービス２を提供するサーバのURLが変更された場合、同じサービス２を提供するサーバが複数ある場合に負荷状況や稼動状況などによって最適なサーバを選択する場合もクライアントとしての情報処理装置は、それらの情報を意識する必要がなくなる。これにより、サービス・サービス間の依存性も低くすることができる。

〔第２実施形態〕
上記第１実施形態では、図４および図５はクエリパラメータを使用してセッションＩＤおよびｏｒｄｅｒの情報をメッセージとして送信する実施形であるが、これはあくまで一例である。
別の方法として、ＨＴＴＰのボディーにこれらの情報を記載し、ＵＲＩにはクエリパラメータを使用しない方法をとっても良い。以下、その実施形態について説明する。
図６は、本実施形態を示すサーバ装置で処理されるセッション情報の一例を示す図である。本例は、図４のＳ４２１にて、ＲＳＶ３２０が生成する、あるいはＳ４３２にて更新、Ｓ４４１にて削除が行われるセッション情報の一例である。本例はＸＭＬによりセッション情報を記載している例である。

図６において、行６０１はＸＭＬ宣言である。行６１０は「セッション情報」であることを示すコメント行であり、以降にセッション情報が記載されている。行６１１はセッション情報の開始タグである。行６１２はセッションＩＤであり、処理４２１にて生成したＩＤである。行６１３は、本セッションが作成された日時情報を示している。
行６１４は、本セッションで実行される連携サービスの最大ｏｒｄｅｒ値が記述されている。行６１５は、連携サービスにおいて現在実行されているサービスのｏｒｄｅｒ値である。情報６２０は連携サービス情報であり、図３のメッセージ３９９から検索し図４の処理４２０で読み出したものの一例である。

行６２１はコメント行である。行６２２は、連携サービス情報を一意に示す名前であり、この連携サービス情報の名前が"ｐｕｓｈｐｒｉｎｔ"であることを示している。行６３０は、連携サービスのリスト表示の開始タグである。
行６３１はｏｒｄｅｒ＝０のサービスであり、ＵＲＬがｈｔｔｐ：／／ｔｔｔ．ｔｔｔ．ｔｔｔ／ｄｗｌｄ．ａｓｐｘであることを示している。同様に行６３２は、ｏｒｄｅｒ＝１のサービスであり、ＵＲＬがｈｔｔｐ：／／ｔｔｔ．ｔｔｔ．ｔｔｔ／ｃｏｎｖ．ａｓｐｘである。行６３３はｏｒｄｅｒ＝２のサービスであり、ＵＲＬがｈｔｔｐ：／／ｕｕｕ．ｕｕｕ．ｕｕｕ／ｐｕｓｈ．ａｓｐｘとなる。行６３４は、連携サービスのリスト表示の終了タグである。行６１６はセッション情報の終了タグである。

〔第３実施形態〕
上記実施形態では、サービス処理としてプッシュプリントを一例として説明した。しかしながら、サービス処理としては、ネットワークの資源を利用した、例えばクラウドコンピューティングシステム環境において提供可能なサービス処理を複数の情報処理装置で連携するシステムではあれば本発明を提供可能である。
以上、詳細に説明した本発明を適用できる本実施形態により、アプリケーションで扱うデータが異なる場合でも、インストール時にデータ定義ファイルによる不要なデータの削除を伴った移行を行うことが出来る。

本発明の各工程は、ネットワーク又は各種記憶媒体を介して取得したソフトウエア（プログラム）をパソコン（コンピュータ）等の処理装置（ＣＰＵ、プロセッサ）にて実行することでも実現できる。

本発明は上記実施形態に限定されるものではなく、本発明の趣旨に基づき種々の変形（各実施形態の有機的な組合せを含む）が可能であり、それらを本発明の範囲から除外するものではない。

１３０ ＰＣ
１８２ サーバ装置

Claims (15)

1. 情報処理装置から要求されるジョブに従い、当該ジョブを連携して処理するサービス処理装置を管理するサーバ装置であって、
   前記ジョブ処理要求で特定される連携サービス処理を実行すべき複数のサービス処理装置の所在情報を含む連携サービス情報を記憶する記憶手段と、
   前記記憶手段に記憶された連携サービス情報に従い前記情報処理装置が連携サービスを要求すべきサービス処理装置の所在情報と連携処理を示すセッション情報と、サービス処理の進捗状態を示すオーダ情報を含む連携処理情報を生成する生成手段と、
   前記生成手段により生成される連携処理情報を前記情報処理装置に送信し、該情報処理装置に処理を指示する指示手段と、
   前記情報処理装置から前記連携処理情報に対する応答情報を取得する取得手段とを備え、
   前記指示手段は、前記取得手段が取得する応答情報に従い次に処理すべき処理を特定し、前記情報処理装置に該特定した処理を指示することを特徴とするサーバ装置。
2. 前記生成手段は、前記情報処理装置から応答される前記連携処理情報に含まれるオーダ情報を更新することを特徴とする請求項２記載のサーバ装置。
3. 前記連携処理情報は、ＵＲＩのクエリパラメータで指示することを特徴とする請求項１記載のサーバ装置。
4. 前記連携処理情報は、ＸＭＬで指示することを特徴とする請求項１記載のサーバ装置。
5. ジョブを実行するために連携すべきサービス処理を実行するサービス処理装置を管理するサーバ装置と通信する情報処理装置であって、
   前記サーバ装置から指示される連携処理情報に従い特定されるサービス処理装置に対してサービス処理を要求する要求手段と、
   前記サービス処理装置から前記サービス処理に対する前記連携処理情報を含む応答情報を前記サービス処理装置から受信する受信手段と、
   前記受信手段が受信した前記連携処理情報を含む応答情報を前記サーバ装置に通知する通知手段とを備え、
   前記要求手段は、前記サーバ装置から指示される次の連携処理情報に従い前記ジョブ処理要求に対して連携してサービス処理を実行する次のサービス処理装置へ接続して連携サービスを要求することを特徴とする情報処理装置。
6. 前記連携処理情報は、ＵＲＩのクエリパラメータで指示することを特徴とする請求項５記載の情報処理装置。
7. 前記連携処理情報は、ＸＭＬで指示することを特徴とする請求項５記載の情報処理装置。
8. サーバ装置から指示される連携処理情報に従って情報処理装置が要求するサービス処理を実行するサービス処理装置であって、
   前記情報処理装置から依頼されるサービス処理を実行する実行手段と、
   前記実行手段によるサービス処理実行後、前記情報処理装置から要求されるサービス処理に対して前記サーバ装置に通知すべき連携処理情報を含む応答情報を前記情報処理装置に通知する通知手段と、
   を備えることを特徴とするサービス処理装置。
9. 前記連携処理情報は、ＵＲＩのクエリパラメータで指示することを特徴とする請求項８記載のサービス処理装置。
10. 前記連携処理情報は、ＸＭＬで指示することを特徴とする請求項８記載のサービス処理装置。
11. 情報処理装置から要求されるジョブに従い、当該ジョブを連携して処理するサービス処理装置を管理するサーバ装置を含むネットワークシステムであって、
    前記サーバ装置は、
    前記ジョブ処理要求で特定される連携サービス処理を実行すべき複数のサービス処理装置の所在情報を含む連携サービス情報を記憶する記憶手段と、
    前記記憶手段に記憶された連携サービス情報に従い前記情報処理装置が連携サービスを要求すべきサービス処理装置の所在情報と連携処理を示すセッション情報とを含む連携処理情報を生成する生成手段と、
    前記生成手段により生成される連携処理情報を前記情報処理装置に指示する指示手段と、
    前記情報処理装置から前記連携処理情報に対する応答情報を取得する取得手段とを備え、
    前記指示手段は、前記取得手段が取得する応答情報に従い、前記生成手段が生成する次の連携処理情報を前記情報処理装置に指示し、
    前記情報処理装置は、
    前記サーバ装置から指示される連携処理情報に従い特定されるサービス処理装置に対してサービス処理を要求する要求手段と、
    前記サービス処理装置から前記サービス処理に対する前記連携処理情報を含む応答情報を前記サービス処理装置から受信する受信手段と、
    前記受信手段が受信した前記連携処理情報を含む応答情報を前記サーバ装置に通知する通知手段とを備え、
    前記要求手段は、前記サーバ装置から指示される次の連携処理情報に従い前記ジョブ処理要求に対して連携してサービス処理を実行する次のサービス処理装置へ接続して連携サービスを要求し、
    前記サービス処理装置は、
    前記情報処理装置から要求されるサービス処理に対して前記サーバ装置に通知すべき連携処理情報を含む応答情報を生成する生成手段と、
    前記生成手段が生成した前記連携処理情報を含む応答情報を前記情報処理装置に通知する通知手段と、
    を備えることを特徴とするネットワークシステム。
12. 情報処理装置から要求されるジョブに従い、当該ジョブを連携して処理するサービス処理装置を管理するサーバ装置におけるジョブ処理方法であって、
    記憶手段に記憶される前記ジョブ処理要求で特定される連携サービス処理を実行すべき複数のサービス処理装置の所在情報を含む連携サービス情報を取得する取得工程と、
    前記記憶手段から取得された連携サービス情報に従い前記情報処理装置が連携サービスを要求すべき情報処理装置の所在情報と連携処理を示すセッション情報と、サービス処理の進捗状態を示すオーダ情報を含む連携処理情報を生成する生成工程と、
    前記生成工程により生成される連携処理情報を前記情報処理装置に指示する指示工程と、
    前記情報処理装置から前記連携処理情報に対する応答情報を取得する取得工程とを備え、
    前記指示工程は、前記取得工程が取得する応答情報に従い、前記生成工程が生成する次の連携処理情報を前記情報処理装置に指示することを特徴とするジョブ処理方法。
13. ジョブを実行するために連携すべきサービス処理を実行するサービス処理装置を管理するサーバ装置と通信する情報処理装置におけるジョブ処理方法であって、
    前記サーバ装置から指示される連携処理情報に従い特定されるサービス処理装置に対してサービス処理を要求する要求工程と、
    前記サービス処理装置から前記サービス処理に対する前記連携処理情報を含む応答情報を前記サービス処理装置から受信する受信工程と、
    前記受信工程が受信した前記連携処理情報を含む応答情報を前記サーバ装置に通知する通知工程とを備え、
    前記要求工程は、前記サーバ装置から指示される次の連携処理情報に従い前記ジョブ処理要求に対して連携してサービス処理を実行する次のサービス処理装置へ接続して連携サービスを要求することを特徴とするジョブ処理方法。
14. サーバ装置から指示される連携処理情報に従って情報処理装置が要求するサービス処理を実行するサービス処理装置におけるジョブ処理方法であって、
    前記情報処理装置から依頼されるサービス処理を実行する実行工程と、
    前記実行工程によるサービス処理実行後、前記情報処理装置から要求されるサービス処理に対して前記サーバ装置に通知すべき連携処理情報を含む応答情報を前記情報処理装置に通知する通知工程と、
    を備えることを特徴とするジョブ処理方法。
15. 請求項１２乃至１４のいずれか１項に記載のジョブ処理方法をコンピュータに実行させることを特徴とするプログラム。

Images