JP2004206694A - 要件ベースワークフローを動的に順序付けするシステムおよび方法 - Google Patents

Abstract

【課題】 個々のジョブに対しても、またはワークフローを実行するのにランタイムで利用可能となり得るサービスまたはプロセッサの変更に対しても、適応性を有するシステムおよび方法を提供する。
【解決手段】 本システムは、受取られたジョブ要求を完了するのに利用可能なサービスに関連する情報を格納するレジストリを有する。また、本システムは、受取られたジョブ要求に基づいてワークフローを動的に生成することができるワークフローコントローラも有する。ワークフローコントローラは、ジョブ要求の性質に基づいてワークフローを構成するための、要件を指定するルールを含むルールデータベースを有する。ワークフローは、１つまたは複数のノードを含み、ワークフローコントローラは、ルールの要件を先のノードの出力と比較することにより後続するノードを生成することによって、ワークフローを動的に生成する。最後に、選択されたサービスはノードを実行する。
【選択図】 図３

Description

本技術分野は、要件ベースワークフロー実行に関し、特に、要件ベースワークフロー実行を動的に順序付けするシステムおよび方法に関する。

ジョブまたはワークフローを実行する現行のシステムには、モノリシックアプリケーションソフトウェアを使用してワークフロー実行を制御するものがある。それらのシステムは、ワークフロー定義をシステム内にハードコード化することにより、ワークフローの先の知識または定義に依存する。その知識に基づいて、アプリケーションソフトウェアは、ワークフローすなわちステップのシーケンスを構築し、その後、ワークフローの実行を制御する。ハードコード化のために、これらのシステムは、個々のジョブに対しても、またはワークフローを実行するのにランタイムで利用可能となり得るサービスまたはプロセッサの変更に対しても、適応性がない。

コンピュータベースネットワークでは、１つまたは複数の動作ユニットがサービスを提供する場合がある。ネットワークのユーザは特定のジョブを生成し、それらのジョブを、動作ユニットのうちの１つに割当てられるネットワークに送出すことができる。たとえば、ユーザはコンピュータ端末において、端末にインストールされたプリンタドライバを使用してプリント命令を生成することができる。プリンタドライバは、プリント要求を制御するために使用される。別の例では、ユーザは、コンピュータ端末においてプリント命令を生成し、そのプリント命令を、プリントサービスによって完了されるようにコンピュータネットワークに送出すことができる。プリント命令は、会社パンフレットに関連してもよい。プリント命令は、用紙タイプ、フォントサイズ、レイアウト、グラフィックス、色および他の要件等の一意の要件を含んでもよい。ユーザは、Ｋｉｎｋｏｓ（商標）等の特定のプリントサービスが会社パンフレットを用意するように指定することができる。代替的に、コンピュータネットワークは、ユーザに対してプリントサービスを提案するプログラムを含む場合もある。

個々のジョブに対しても、またはワークフローを実行するのにランタイムで利用可能となり得るサービスまたはプロセッサの変更に対しても、適応性を有するシステムおよび方法を提供する。

一態様では、開示するものは、要件ベースワークフローを動的に順序付けするシステムである。本システムは、受取られたジョブ要求を完了するのに利用可能なサービスに関連する情報を格納するレジストリを有する。また、本システムは、受取られたジョブ要求に基づいてワークフローを動的に生成することができるワークフローコントローラも有する。ワークフローコントローラは、ジョブ要求の性質に基づいてワークフローを構成するための、要件を指定するルールを含むルールデータベースを有する。ワークフローは、１つまたは複数のノードを含み、ワークフローコントローラは、ルールの要件を先のノードの出力と比較することにより後続するノードを生成することによって、ワークフローを動的に生成する。最後に、選択されたサービスはノードを実行する。

別の態様では、開示するものは、分散ネットワークにおいてワークフローを動的に順序付けるシステムであって、ネットワークのサービスセンタにおいて、ジョブに関連する情報を含むジョブ要求を受取る手段と、受取ったジョブ要求に基づいてワークフローを動的に生成する手段と、動的に生成する手段にサービスを結合させる手段と、サービスに関連する情報を格納する手段と、を有するシステムである。動的に生成する手段は、サービスに関連する格納された情報とジョブに関連する情報とを使用して、ワークフローを生成する。

さらに別の態様では、開示するものは、要件ベースワークフローを動的に順序付けする方法である。本方法は、完了されるべきジョブを指定するジョブ要求を受取るステップを含む。さらに、本方法は、ジョブに基づいて動的ワークフローシーケンスを生成するステップを含む。動的ワークフローシーケンスを生成するステップは、ワークフローシーケンスにおける第１のノードを定義するステップと、第１のノードに対する入力リソースと予測された出力リソースとを確定するステップと、を含む。次に、本方法は、第１のノードが実行し得る時を確定し、その後第１のノードの実行が開始するステップを含む。最後に、本方法は、第１のノードの実際の出力リソースに基づいて、ジョブを満足させるために追加のノードが必要であるか否かを確定するステップを含む。

さらに別の態様では、コンピュータを、要件ベースワークフローを動的に順序付けする方法を実行するようにプログラムしてもよく、その方法は、完了されるべきジョブを指定するジョブ要求を受取るステップと、ジョブに基づいて動的ワークフローシーケンスを生成するステップと、第１のノードの実行が開始する、第１のノードが実行し得る時を確定するステップと、第１のノードの実際の出力リソースに基づいて、ジョブを満足させるために追加のノードが必要であるか否かを確定するステップと、を含む。動的ワークフローシーケンスを生成するステップは、ワークフローシーケンスにおける第１のノードを定義することと、第１のノードに対する入力リソースと予測された出力リソースとを確定することと、を含んでもよい。

さらに別の態様では、コンピュータ読取可能媒体は、要件ベースワークフローを動的に順序付けするプログラムされた命令を含み、その方法は、完了されるべきジョブを指定するジョブ要求を受取るステップと、ジョブに基づいて動的ワークフローシーケンスを生成するステップと、第１のノードの実行が開始する、第１のノードが実行し得る時を確定するステップと、第１のノードの実際の出力リソースに基づいて、ジョブを満足させるために追加のノードが必要であるか否かを確定するステップと、を含む。動的ワークフローシーケンスを生成するステップは、ワークフローシーケンスにおける第１のノードを定義することと、第１のノードに対する入力リソースと予測された出力リソースとを確定することと、を含んでもよい。

詳細な説明は、同様の数字が同様の項目を参照する以下の図面を参照する。

図１は、特定のアプリケーションソフトウェアを使用して、要求されたタスクすなわちジョブが制御されるワークフロー実行のための既存の手法を示す。かかるアプリケーションはプリント規格に関連することが多く、その例はジョブ定義フォーマット（job definition format（ＪＤＦ））である。ＪＤＦは、参照により本明細書に援用される、http://www.cip.orgにおいて入手可能なＪＤＦ Ｓｐｅｃｉｆｉｃａｔｉｏｎ Ｄｒａｆｔ Ｓｐｉｒａｌ ４．０において詳細に述べられている。図１において、ユーザ／クライアント１はジョブ要求を生成し、そのジョブ要求を、ポータル４を通してプロセッサ５に送信する。ジョブ要求は、ジョブデータファイル２とコンテンツファイル３とを含んでもよい。ユーザ１は、ネットワークコンピュータシステムにおけるコンピュータ端末であってもよく、プロセッサ５はネットワークプリンタであってもよい。ジョブ要求は、文書をプリントすることを含んでもよい。文書を、プリントされるテキストおよび画像のデジタル表現であるコンテンツ３で表してもよい。プリント文書の意図されたフォーマットを、単に、プリンタが文書をプリントする方法を指定するデジタルファイルである、ジョブデータファイル２において記述してもよい。たとえば、ジョブデータファイル２は、文書が両面ページにプリントされるように要求してもよい。

特定のアプリケーションでは、プリンタドライバが、ジョブデータファイル２の機能を実行する場合がある。プリンタドライバは、文書のプリントに関連する制御データを符号化し、その制御データとコンテンツ３とをプリンタ（すなわち、プロセッサ５）に送信する。プリンタは、制御データとコンテンツ３とにアクセスして文書をプリントする。

図１に示すアプリケーションは文書をプリントするためには効果があるが、多くの欠点を有する。特に、文書を作成する際に複数のプロセッサが必要である場合、かかるプロセッサの各々は、ジョブデータファイル２へのアクセスを要求する。このアクセスにより、セキュリティ、変更制御およびワークフロー制御に関する問題がもたらされる。たとえば、ジョブデータファイル２に対するアクセスを要求しているプロセッサは、先のプロセッサがジョブデータファイル２の使用を完了するまで処理を待たなければならない場合がある。このため、従来技術によるアプリケーションは、ジョブ要求を完了する際に望ましくない遅延をもたらす可能性がある。

また、図１に示すようなワークフロー実行サービスの従来技術によるアプリケーションでは、ユーザが、プロセッサの能力および可用性を含むプロセッサに関すること、あるいはプロセッサが存在するか否かをも知らない可能性があるため、問題がある。このため、ユーザは、特定のプロセッサに接続するためにいずれのポータルを使用すべきかを知らない可能性がある。

また、図１に示すシステムには、ワークフローを制御するために使用されるアプリケーションソフトウェアがモノリシックであるため、問題がある。すなわち、ワークフロー定義はアプリケーションソフトウェアにハードコード化され、個々のジョブに対して適応性がないため、アプリケーションソフトウェアはワークフローの以前の知識を有する。その知識に基づいて、アプリケーションソフトウェアは、ワークフロー、すなわちステップのシーケンスを構築し、その後、そのワークフローを実行して完成させる。しかしながら、アプリケーションソフトウェアは、所望のワークフローの変化を動的に考慮することができず、ワークフローの実行時に使用するために利用可能となるサービスまたはプロセッサの変化を考慮することができない。

これらおよび他の問題を、ワークフロー実行を動的に制御する方法およびシステムによって解決する。本システムは、複数のサービスまたはプロセッサ間でワークフローへのアクセスを調停し、セキュリティ機能を組込むことによってワークフローへのアクセスを制限し、１つのサービス、プロセッサまたはユーザによって行われる変更がワークフローに反映されるのを確実にするメカニズムを含む。実施形態では、本システムは、ジョブ要求としてのクライアントからの入力データを、それらジョブ要求を完了するためにタスクまたはプロセスを実行するサービスの出力能力と結合する、中央データベース、すなわちレジストリを含む。本レジストリは、レジストリが拡張可能であるという点と、クライアントが実行される個々のプロセスまたはサービスの内部プログラミング要件のいずれの知識も有する必要がないという点において、汎用ＸＭＬデータベースの特徴を有することができる。このため、クライアントは、ジョブ要求を完了するために適当な１つまたは複数のサービスが割当てられることを保証するサービスセンタに対し、ジョブ要求を提出してもよい。

本装置および方法は、いかなる数のワークフローに従うことができ、その一例を、図２に、パンフレットをプリントするためのワークフローに定義されるプロセスを示すノード−ツリー図（または単にノードツリー）１０として示す。さらに、ノードは必須であっても任意であってもよく、特定のワークフローの実行中に、特定のノードが必須であるかまたは任意であるかが変化してもよい。パンフレットを商用印刷機でプリントしてもよく、デジタルコンテンツを使用してパンフレットをプリントするための版を生成してもよい。ノードツリー１０内では、ノードは、製品、プロセスまたはプロセス群を指定する。各ノードは、リソースを変更し、消費し、または生成してもよい。各ノードは、さらに入れ子にされたノード、すなわちサブノードを含んでもよい。ノードとサブノードとの配置をツリーになぞらえることができ、各ノードおよびサブノードをブランチと呼んでもよい。パンフレットノード１１は、パンフレットの特徴およびパラメータを定義する。プレフライトノード１７を使用して、向き、ページレイアウト、フォント、色および他の文書特定の特徴等、パンフレット要件を取得することができる。表紙ノード１２は、パンフレット表紙を製作するためのパラメータを定義する。内部ページノード１３は、内部ページを製作するためのパラメータを含む。内部ページノード１３を、デジタル製版サブノード１４を含むいくつかのサブノードを有するように示す。デジタル製版サブノード１４自体は、２つのさらなるサブノード、すなわちリッピングサブノード１６と製版サブノード１８とを有する。

図２に示すノードおよびサブノードの各々には、入力リソースと少なくとも１つの出力リソースとが関連する。リソースを、パラメータまたは論理エンティティによって説明することができる。リソースは、コンポーネント、処理リソースまたは消耗品等の物理エンティティであってもよい。コンポーネントリソースは、プリントされるシート等、ノードまたはサブノードの出力であってもよい。処理リソースはプロセス中に使用されるが、プロセスによって消費されない。処理リソースは、コンポーネントリソースを製作の１つの段階から別の段階に搬送するメカニズムを含んでもよい。本プロセスは、部分的に、または全体として消費可能リソースを消費してもよい。消費可能リソースの例には、インク、版および膠がある。他のリソースは、物理的物体のデジタルファイルまたは表現であってもよい。たとえば、リッピングサブノード１６は、入力リソースとして、実行リスト、媒体、ＲＩＰパラメータおよびレイアウトを含んでもよい。実行リストリソースは、ページが発生するファイルを含むページと、いずれのページが使用されるかと、を記述する。媒体リソースは、版を作成するために使用される媒体を記述し、媒体の寸法を記述するために必要とされる。ＲＩＰパラメータリソースは、リッピングプロセスの装置特定パラメータのすべてを記述する。レイアウトリソースは、ソースページの版上、最終的にはプレスシート上の配置を記述する。出力リソースとして、リッピングサブノード１６は、リッピングされた原板を提供してもよい。他のリソースには、プロセスの詳細を定義するパラメータリソース、ならびにプロセスによって使用される他の非物理コンピュータファイルと、がある。

図２に示すノードツリー１０は、文書のプリントに適用するように意図されている。しかしながら、ノード−ツリー図を、プリント以外の他のサービスに対するワークフローを表現するために使用してもよい。たとえば、ワークフローを、データ処理、画像処理、データベースの作成および維持、電子出版、電子メールおよびあらゆる電子商取引サービスに使用してもよい。さらに、ワークフローを使用して、異なる電子商取引サービスがいかに互いと対話するかを定義してもよい。

図３は、クライアント３１によって提出されるジョブ要求を制御するためにサービスセンタ４０を組込む、動的ワークフロー実行システム２０のブロック図である。サービスセンタ４０は、単一ポータルとして動作してもよく、それを通して、クライアント３１は、電子メール、電子商取引およびオンラインショッピング、電子プリント、ならびにデータベース検索およびデータベース構成、ポピュレーションおよびメンテナンスを含むデータサービス等の１つまたは複数の電子サービスに接続する。サービスセンタ４０等の単一ポータルを使用することにより、クライアント３１は、電子サービスのいかなる従来の知識をも有する必要なしに、上述したような多種多様な電子サービスを受取ることができる。

サービスセンタ４０は、ジョブ要求の形態で情報を受取り、その情報を使用して、タスクおよびリソースを指定するワークフロー定義を動的に生成するコンポーネントを有してもよい。ワークフロー定義を、一時的にサービスセンタ４０に格納してもよく、ワークフロー定義または代替的に関連する通知を、ワークフロー定義が利用可能な時を指示するようにポストしてもよい。サービスセンタ４０は、ジョブ要求を完了するための候補サービスを選択してもよい。代替的に、サービスセンタ４０に結合されるサービスは、ワークフローによって定義されるジョブの完了時にビッド（bid）してもよく、サービスセンタ４０は、ビッドを評価するビディングサービスを含んでもよい。サービスセンタ４０は、クライアントが提供する基準に基づいて、または業界標準基準を含む標準基準のセットに基づいて、ワークフローの実行に割当てる１つまたは複数のサービスを選択してもよい。サービスセンタ４０は、ジョブまたはジョブの一部（タスク、サブタスクまたはブランチ）に対するアクセスを制御するメカニズムを提供してもよい。このメカニズムは、ブランチロッキングと、公開鍵暗号化または同様のプロセスを使用する許可サーバおよび認証サーバと、を含む。

サービスセンタ４０は、上述した機能を実行するために必要な処理能力およびデータ記憶を提供する、サーバ、コンピュータ、中央処理装置、通信インタフェースおよびメモリ装置等のハードウェアコンポーネントを含んでもよい。

システム２０は、クライアント３１がサービスまたはジョブ要求３２を生成し提出することができるようにするフロントエンドサービス（ＦＥＳ）３０を含む。実施形態では、フロントエンドサービス３０はインターネットウェブブラウザであってもよい。代替的に、フロントエンドサービス３０は、ウェブアプリケーションかまたはポートモニタであってもよい。ジョブ要求３２は、いかにジョブが実行されるかに関する詳細な情報を含んでもよく、ジョブ定義フォーマット規格に従ってフォーマットされてもよい。代替的に、ジョブ要求３２は、ジョブ定義またはワークフローを仕上げるために別のコンポーネントによって使用される、基本情報のみを含んでもよい。実施形態では、ジョブ要求３２は、処理されるデータである、コンテンツファイル３４を含む。コンテンツファイル３４は、１つまたは複数のデジタルファイル、テキストファイルおよび他のファイルであってもよい。たとえば、コンテンツファイル３４は、パンフレットにおいてプリントされるテキストおよびグラフィックスを含んでもよい。また、ジョブ要求は、コンテンツファイル３４を処理するための要件を指定し、たとえばクライアント３１の識別を含む他の情報を提供してもよい、制御データファイル３６も含んでよい。

フロントエンドサービス３０は、たとえばインターネット、広域ネットワークまたはローカルエリアネットワークであってもよい、通信ネットワーク３５に結合される。通信ネットワーク３５には、１つまたは複数のサービス８０_ｉを通信ネットワーク３５にリンクするサービスセンタ４０が連結される。サービス８０_ｉの各々は、標準ワークフロー定義またはステップに関連する情報を含む、ジョブ要求３２に関連する情報を格納するために使用することができる、データベース８１_ｉを含んでもよい。実施形態では、サービスセンタ４０は、データ記憶および制御機能を含むインターネットウェブサイトであってもよい。別の実施形態では、サービスセンタ４０は、ローカルエリアネットワークにおけるノードである。

サービスセンタ４０は、サービスセンタ４０に連結されるエンティティ間の広範囲の通信を可能にする。特に、サービスセンタ４０は、異なる電子サービスが、特定プロトコルと汎用プロトコル（たとえば、ＴＣＰ／ＩＰ）とを使用して互いにプログラム的に対話することを可能にする。このプログラム的対話により、ネットワークに結合される異なるサービスおよびプロセスがデータおよびファイルを交換することができ、データおよびファイルを変更することができる。プログラム的対話を、サービスセンタ４０に連結されるエンティティ間のリモートプロシージャコール（ＲＰＣ）を使用して完了してもよい。プログラム的対話を提供する他の方法には、ＣＯＲＢＡ、ＵＤＤＩ、ＳＯＡＰ、ｘｍｌ ｏｖｅｒ ｈｔｔｐおよびｅ−ｓｐｅａｋがある。

図４を参照すると、サービスセンタ４０は、ワークフローコントローラ（ＷＦＣ）７０等の適当にプログラムされたプロセッサを有する。その多くのあり得る動作のうち、ワークフローコントローラ７０は、あらゆるノードと、入出力リソースと、ジョブ要求を完了するために使用されるノードツリーの他の特徴と、を指定する。すなわち、ワークフローコントローラ７０を使用して、図２に示すノードツリー１０等の構成体またはワークフロー定義を動的に生成することができる。これらのタスクを達成するために、ワークフローコントローラ７０は、ジョブ要求３２に含まれる制御データに基づいてジョブ定義ファイルを書く１つまたは複数のエージェント７１_ｉを有する。任意選択で、別個の管理情報システム（ＭＩＳ）５０を使用して、ノードを生成し、サービス８０_ｉおよび他のエンティティに対するタスクのフローを制御してもよい。さらに別の実施形態では、ジョブ要求３２を発生したクライアント３１がジョブ定義を書いてもよい。

また、サービスセンタ４０は、通信ネットワーク３５（図３参照）およびサービス８０_ｉと通信するサービスバス４１を有する。サービスバス４１には、中央レジストリ６０と、データベース９０と、任意のビディングサーバ９４と、許可サーバ９２および認証サーバ９３と、が連結される。任意のデバイスについては後述する。データベース９０は、１つまたは複数の特定のワークフロー定義ファイル９１_ｉを制御してもよい。ワークフロー定義ファイル９１_ｉは、ジョブ要求を完了するために、図２に示すノードツリー１０等のワークフローを実施するために必要なあらゆるタスクおよびサブタスクを指定してもよい。ワークフローコントローラ７０は、１つまたは複数のエージェント７１_ｉを使用して、サービスバス４１上のプロセスを制御してもよい。

再び図２のノードツリー１０を参照すると、個々のノードの多くの出力リソースは、他のノードに対する入力リソースとしての役割を果たす。これらの他のノードは、いくつかまたはすべての入力リソースが完了し利用可能となるまで、実行を開始することができない場合があり、それは、ジョブ要求におけるいくつかのタスクおよびサブタスクが、明確ではあるが必ずしも予め定義されていないシーケンスで実行されるような１組のルールに従って実行する必要のある場合があることを意味する。たとえば、版を作成するプロセスは、プリントプロセスによって要求される出力リソースとして刷版を製作する。パンフレットをプリントするプロセスは、版の使用を要求する場合がある。しかしながら、パンフレットを、パンフレットデータをネットワークプリンタ（すなわち、サービス８０）に送信することによってプリントしてもよく、その後、ネットワークプリンタは、パンフレットのためのプリントされたページの初期出力リソースを製作する。ノードツリー１０の階層構成において、ノードツリー１０の高位で発生するノードは、それより高レベルのより抽象的な動作を表し、一方下位ノードはより詳細な特定プロセスを表す。さらに、ノードツリー１０の上部近くのノードは、製品を含むコンポーネントまたはアセンブリに関する意図のみを表してもよく、下位レベルのノードは、サービス８０に対して特定のプロセスを実行するための詳細な命令を提供することができる。

２つのノードツリーは同様でなくてもよいため、ワークフローコントローラ７０は、完了されるプロセスと、プロセスが完了される順序と、プロセスを完了するサービス８０_ｉと、を確定してもよい。ワークフローコントローラ７０は、たとえばプロセスを完了するサービスの制御能力、サービス間の転送距離、サービスの負荷能力、およびジョブ要求における時間制約等の要素を考慮して、エージェント７１_ｉを使用して実際のワークフローを確定する。エージェント７１_ｉは、サービス８０_ｉによるリソースの後続する製作および消費を含む逐次処理と、複数のサービス８０によるリソースの同時消費および製作を含むオーバラップ処理と、サービス８０_ｉ間のリソースの共有を含む並列処理と、リソースを開発するための往復処理方式を含む反復処理と、を使用して、全プロセスを定義することができる。

特定のジョブ要求を完了するためにサービス８０_ｉのうちのいずれを割当てるべきかを確定する際、ワークフローコントローラ７０は、サービスセンタ４０に結合されるサービス８０_ｉをポーリングしてもよい。上述したように、サービス８０_ｉを、サービスバス４１に直接連結してもよく、あるいは、たとえばインターネット等の別の通信バスを通して間接的に結合してもよい。ポーリングは、サービスセンタ４０においてワークフロー定義ファイル９１_ｉが作成されるたびに発生してもよい。代替的に、ポーリングおよび対応する情報収集は、周期的に発生してもよく、ワークフローコントローラ７０は、サービス８０_ｉに関連する情報を格納してもよい。

ポーリングに代る方法として、サービスセンタ４０に結合されたサービス８０_ｉが、ワークフロー定義ファイル９１_ｉの実行を監視してもよい。サービスセンタ４０は、たとえば処理に利用可能なワークフロー定義ファイル９１_ｉに対する通知を、掲示板式に定期的にポストする。そして、サービス８０_ｉは、通知において定義されるタスクおよびプロセスに対してビッドを提出する。ワークフローコントローラ７０または別個の任意のビディングサーバ９４は、ビッドを検査して、ジョブ通知に定義されるタスクおよびプロセスを完了するためにいずれの単一サービス８０_ｉまたはサービス８０_ｉの組合せが最も適当であるかを確定することができる。

特定のタスクまたはサブタスクにいずれのサービス８０_ｉを割当てるかを確定する際、ワークフローコントローラ７０は、中央レジストリ６０を調べる。図５は、レジストリ６０の実施形態を示す。レジストリ６０は、サービス８０_ｉがアクセス可能なデータ記憶装置または媒体である。サービス８０_ｉは、予め定義されたフォーマットに従ってサービス情報をレジストリ６０に登録する。そして、ワークフローコントローラ７０は、サービスを特定のワークフローを定義するタスクおよびサブタスクに割当てるためにサービス情報にアクセスする。サービス８０_ｉをタスクまたはサブタスクに割当てる場合、ワークフローコントローラ７０は、先のタスクまたはサブタスクの完了時に存在する状況を考慮してもよい。たとえば、パンフレットをプリントするサブタスクは、本来スケジュールされたものより１２時間遅れて完了する場合があり、それにより通常次のサブタスク（たとえば、綴じ）を完了するいくつかのサービスが利用可能でなく、その間、新たな綴じサービスがレジストリ６０に登録している可能性がある。このため、ワークフローコントローラ７０は、ワークフローの実際の実行に基づいてサービスを動的に割付けることができる。

図５に示すように、レジストリ６０は、別個のファイル６２_ｉとして予め定義されたフォーマットに従ってサービス情報を格納する複数のセクション６１_ｉを有する。セクション６１_ｉは、共通タイプのサービス８０_ｉに対するファイル６２_ｉを備える。たとえば、プリントサービスセクション６１_ｉは、Ｋｉｎｋｏｓ（商標）および他の商用プリントサービスと、ネットワークプリンタ、および他のプリントサービスと、に対するファイル６２_ｉを含む。ファイル６２_ｉに含まれる情報を、個々のサービス８０_ｉによって提供する。ファイルに含まれる情報はサービス８０_ｉを識別し、サービス８０_ｉの能力および可用性と、例えば価格情報を含む他の情報と、を提供することができる。

サービスセンタ４０（図４参照）は、セキュリティを提供し、かつワークフロー定義ファイル９１_ｉに対するアクセスを制御するいくつかの機能を含む。上述したように、サービスセンタ４０は、ブランチロッキングを提供することを含む。さらに、サーバを使用して、サービス８０を許可および認証し、ジョブ要求３２の完了中に許可および認証を維持することができる。認証サーバ９３は、サービス８０から認証情報を受取り、また許可サーバ９２は、その情報を使用して許可機能をチェックする。サービス８０の許可またはアクセス権を、ワークフロー定義ファイル９１_ｉの一部として有することができる。サーバ９２および９３は、ハードウェアデバイスであってもよいが、同じハードウェアプラットフォームに存在する必要はなく、密連結される必要はない。代替的に、サーバ９２および９３の機能を、たとえばワークフローコントローラ７０等のサービスセンタ４０のコンポーネントのうちの１つに格納されるプログラミングで実行してもよい。上述した機能を使用して、サービスセンタ４０は、サービス８０に関する信用認証情報を許可サーバ９２に提供することができ、その後許可サーバ９２はその権限チェック機能を実行する。

ワークフローコントローラ７０によって生成されるワークフロー定義ファイル９１_ｉは、ジョブ要求３２（図３参照）を完了するために完了しなければならない特定のタスクまたはサブタスク（ブランチ）を含む。単純なジョブ要求３２は、１つのブランチのみを有してもよい。図２に示すジョブ要求（すなわち、パンフレットをプリント）等のより複雑なジョブ要求３２は、多くのブランチを有する。さらに、特定のシーケンスでのみ完了することができるように相互に関係付けられたブランチがあってもよく、一方並列またはオーバラップして完了することができるブランチがあってもよい。これらの相互関係は、１つのブランチが、１つまたは複数の他のブランチに対する入力リソースである出力リソースを製作する結果である場合が多い。さらに、新たなサービス８０_ｉがレジストリ６０に登録すると、ブランチ間の相互関係が変化する場合がある。

ワークフロー定義ファイル９１_ｉは、特定ブランチとそれらの相互関係との記述を含む。この情報を、サービス８０_ｉがブランチの完了に対してビッドすることができるために十分詳細に示してもよい。ワークフロー定義ファイル９１_ｉは、サービス８０_ｉがビッドを送出することができるように指定された時間サービスセンタ４０に存続してもよい。その時間は、設定値（たとえば、１時間）であってもよく、あるいはジョブ要求３２に指定された完了デッドラインに基づいてもよい。

実施形態では、ワークフローコントローラ７０は、１組の基準に基づいて落札（winning）サービス８０_ｉを選択する。代替的に、任意のビディングサーバ９４が、設定基準に基づいてサービス８０_ｉからビッドを選択してもよい。たとえば、ジョブ要求３２は、最低パフォーマンス要件（たとえば、最大コストおよび完了デッドライン）を指定する。ビディングサーバ９４は、最低パフォーマンス要件を満足しないビッドをすべて拒絶する。ワークフローコントローラ７０が複数のブランチを確立した場合、かかるブランチの各々は、最低パフォーマンス要件を含む。ブランチ特定パフォーマンス要件を、ワークフローコントローラ７０によりワークフロー定義ファイル９１_ｉにおける全パフォーマンス要件に基づいて確立してもよい。ビディングサーバ９４は、特定ブランチに対してビッドするサービス８０が最低パフォーマンス要件を満たさない場合、そのサービス８０を拒絶する。

クライアント３１がいかなる最低パフォーマンス要件も指定しない場合、ワークフローコントローラ７０あるいはビディングサーバ９４は、基準の標準セット（たとえば、業界標準）を適用してもよい。ビッドは、出力リソースを製作するためのいかなる要件も満足させなければならない。このように、誤って作成されたかまたはそれ以外で拒絶される可能性のあるビッドを、ふるいにかけることができる。たとえば、パンフレットの内部ページをプリントするビッドが、１年後の完了日を指示するものとする。かかるビッドを、クライアント３１からのいかなる指定されたパフォーマンス要件もない場合に、拒絶してもよい。

パフォーマンス要件を提出することに加えて、クライアント３１は、ビッドおよびサービス８０_ｉを評価する評価アルゴリズムを指定する。たとえば、クライアント３１は、コストを、他のパフォーマンス要件の２倍重み付けするように指定する。

クライアントが指定する評価アルゴリズムがない場合、ワークフローコントローラ７０あるいはビディングサービス９１は、ワークフロー定義ファイル９１_ｉにおける各ブランチに対してサービス８０_ｉをランク付けするために標準評価アルゴリズムを適用することができる。評価アルゴリズムは、重み付け基準を適用することができ、あるいはデフォルトルールを適用することができる。たとえば、サービス８０_ｉを、最大スコアに基づいてランク付けすることができ、その場合、ポイントは、最大を下回るコスト推定値と最大を下回る完了時間とに対して与えられる。一旦評価アルゴリズムが適用されると、ワークフローコントローラ７０は、各ブランチに対してサービス８０_ｉをランク付けする（または、ビディングサービス９１がビッドをランク付けする）。１つのサービス８０のみがプロセスを生き残る場合、そのサービス８０を自動的に選択してブランチに割当ててもよい。複数のサービス８０_ｉが生き残る場合、ワークフローコントローラ７０は、ラウンドロビン選択方式等の追加の選択基準を適用して、サービス８０_ｉをブランチに割当てることができる。代替的に、リストをクライアント３１に提供してもよく、クライアント３１は、ワークフロー定義ファイル９１_ｉにおいて定義されるタスクを完了するためのサービス（複数可）８０_ｉを選択してもよい。

ワークフローコントローラ７０は、落札サービス８０_ｉをワークフロー定義ファイル９１_ｉの対応するブランチに関連付けることができ、ワークフロー定義ファイル９１_ｉとともにサービス選択情報を格納することができる。格納された選択情報は、許可サーバ９２と認証サーバ９３とがワークフロー定義ファイル９１_ｉのブランチに対するか、またはワークフロー定義ファイル９１_ｉ全体に対するアクセスを許可することができるような識別情報を含んでもよい。選択情報はワークフロー定義ファイル９１_ｉとともに格納されるため、サービス８０は、サービスセンタ４０と直接通信する必要なしにアクセスが許可されるブランチにアクセスすることができる。この特徴により、ワークフロー定義ファイル９１_ｉを、１つのサービス８０から別のサービス８０に渡すことができ、それにより処理時間および効率が向上する。

実施形態では、サービスセンタ４０は、たとえばＣＤ−ＲＯＭ等の機械読取可能媒体に記録されるプログラミング命令のシーケンスを有する。コンピュータは、プログラミング命令を読出して、プロセスを実行することにより、ワークフロー定義ファイルを使用してビッド情報を格納することを含む、サービスセンタ４０の機能を提供する。

図６は、サービスセンタ４０の選択された機能の動作を示す図である。図６に示すように、サービスセンタ４０は、図２に示し上述したノードツリー１０によって表されるもの等のプログラミングオブジェクトである、ワークフロー定義ファイル９１_ｉを含む。クライアント３１_１は、サービスセンタ４０にジョブ要求３２を提供する。サービスセンタ４０は、ジョブ要求３２を使用して、ワークフロー定義ファイル９１_ｉを作成し、ワークフロー定義ファイル９１_ｉを１つまたは複数のサービス８０_ｉに利用可能であるようにする。また、サービスセンタ４０は、クライアント３１_１にワークフロー定義ファイル９１_ｉを提供する。クライアント３１_１は、ネットワークコンピュータかまたは、ジョブ要求３２を表すデジタル情報をサービスセンタ４０に送信することができる同様の装置である。

また図６は、クライアント３１_２およびサービス８０_１〜８０_Ｎも示す。サービス８０_１〜８０_Ｎは、ネットワークプリンタ等のネットワークリソース、インターネットウェブサイト等の電子商取引エンティティ、およびサービスバス４１を使用してサービスセンタ４０に連結されるローカルプリントショップ等の「ブリックアンドモルタル（brick and mortar）」エンティティを含む。

ワークフロー定義ファイル９１_ｉは、ジョブ要求３２を終了するために完了しなければならないタスクおよびサブタスクを指定する。上述したように、図２は、内部ページおよび表紙を含むパンフレットをプリントするために必要なプロセスを示す。かかるジョブ要求３２を完了するため、または最も費用効率のよいおよび／またはタイムリな方法でジョブ要求３２を完了するために、複数のサービス８０_ｉを要求してもよい。ワークフローコントローラ７０（図４参照）は、いずれのサービス８０_１〜８０_Ｎが特定プロセスを完了するべきであるかと、必要な場合は、かかるプロセスを完了しなければならない順序と、を確定することができる。ワークフローコントローラ７０は、あらゆるサービス８０_ｉをポーリングして、ジョブ要求を完了するためにいずれを使用することができるかを確定することができる。

各ジョブ要求３２が受取られる度に、ワークフローコントローラ７０は、ジョブ要求３２に対する参照７２_ｉを生成する。サービス８０_１は、１つまたは複数のタスクまたはサブタスクを完了するために、関連するワークフロー定義ファイル９１_ｉに対するアクセスを要求する。それに応じて、ワークフローコントローラ７０は、サービス８０_１に対してジョブ要求参照７２_ｉを提供する。そして、ジョブ要求参照７２_１を、ジョブ要求３２に対するインデックスとして使用する。また、ジョブ要求参照７２_１を、サービス８０_２等の他のサービスとクライアント３１_２等の他のクライアントとに提供する。そして、サービス８０_２およびクライアント３１_２は、サービス８０_１がワークフロー定義ファイル９１_ｉにアクセスするのと同時にワークフロー定義ファイル９１_ｉにアクセスしてもよい。この同時アクセスにより、異なるタスクおよびサブタスクが並列に完了することができる。図２に示す例では、サービス８０_１は、内部ページに対するいくつか、またはすべてのタスクを完了してもよく、またサービス８０_２は表紙に対するタスクを完了する。

図７は、サービスセンタ４０の制御機能のアプリケーション例を示すブロック図である。ワークフロー定義ファイル（ＷＦＤＦ）９１_ｉは、ジョブ要求３２のコンテンツファイル３４を参照し、ワークフロー定義ファイル９１_ｉとコンテンツファイル３４とに関連する情報が、サービスバス４１によって渡される。サービス８０_ｉは、サービスバス４１を使用してコンテンツファイル３４とワークフロー定義ファイル９１_ｉとにアクセスすることができる。図示する例では、ワークフロー定義ファイル９１_ｉは、図２に概説したプロセスを使用してパンフレットをプリントするためのジョブ要求３２を参照する。サービス８０_１は、ワークフローコントローラ７０により、パンフレットの内部ページを製作するように指定され、サービス８０_２は、パンフレット表紙を製作するように指定される。サービス８０_１は、アクセス要求をサービスセンタ４０に渡す。アクセス要求は、サービス８０_１がワークフロー定義ファイル９１_１と対応するコンテンツ３４_１またはジョブにアクセスすることができるようにするセキュリティ情報を含んでもよい。それに応じて、サービスセンタ４０は、サービス８０_１がワークフロー定義ファイル９１_ｉにアクセスするために使用するジョブ要求参照（ＲＥＦ）７２_１を提供する。サービス８０_１は、ワークフロー定義ファイル９１_ｉの情報を使用して、コンテンツファイル３４_１にアクセスすることができる。サービス８０_１は内部ページのみを製作するため、ワークフロー定義ファイル９１_ｉに含まれる情報のすべてにアクセスする必要はない。さらに、ワークフロー定義ファイル９１_ｉはサービスセンタ４０に残るため、サービス８０_２等の他のエンティティが、ワークフロー定義ファイル９１_ｉにアクセスし続けることができる。

サービス８０_１は、あらゆるタスクを完了すると、コンテンツファイル３４とワークフロー定義ファイル９１_ｉとを更新してもよい。このため、ワークフロー定義ファイル９１_ｉは、ジョブ要求３２の最新ステータスを反映することができる。ステータス報告は、ノートツリー１０のノードが完了する時と、仮のデッドラインが完了する時と、タスクを完了するために別のサービスを使用することができる時と、すべてのタスクが完了する時と、を示す。ステータス報告を、たとえばワークフローコントローラ７０によって使用されるデジタルファイルに含めることができる。また、ステータス報告を、コンピュータディスプレイ画面上のポップアップウィンドウ等、人間が読むことができるフォーマットに含めることができる。サービス８０_１は、ジョブ要求参照７２_１を受取ることができ、スケジュールされたタスクをすべて完了して、ジョブ要求参照７２_１をサービスセンタ４０に戻すことができる。また、サービス８０_１は、サービス８０_２に対してジョブ要求参照７２_１のコピーを送信してもよく、それにより、サービス８０_２は、ワークフロー定義ファイル９１_ｉとコンテンツファイル３４とにアクセスし、パンフレット表紙を製作することができる。

前述の論考では、ワークフローコントローラ７０が、ワークフロー定義ファイル９１_ｉを生成する（または検索する）ことを含む、特定のジョブ要求３２を完了するために必要なワークフローを生成することができる、と述べた。図８は、ワークフローの生成とワークフロー実行の管理を可能にするあらゆるコンポーネントを示す、ワークフローコントローラ７０のブロック図である。ワークフローコントローラ７０は、メモリ７５を含む。メモリ７５は、ルールデータベース７７と短期記憶領域またはワークフロー定義ファイルキャッシュ７９とを含んでもよい。ルールデータベース７７は、ワークフローと対応するワークフロー定義ファイル９１_ｉとを生成するためのルールを含む。キャッシュ７９を、ジョブ要求３２の処理中にワークフロー定義ファイル９１_ｉの一時記憶のために使用することができる。

また、ワークフローコントローラ７０には、ワークフロー発生器６３と、ワークフロー実行エンジン６５と、インタフェースコントローラ６７と、が含まれる。ワークフロー発生器６３は、ジョブ要求３２に含まれる情報とルールデータベース７７のルールとを使用して、ワークフロー定義ファイル９１_ｉを生成する。ワークフロー実行エンジン６５は、ワークフロー定義ファイル９１_ｉに定義されるタスクおよびサブタスクの実行を開始し、監視する。インタフェースコントローラ６７は、クライアント３１とサービスセンタ４０と（図３参照）の間の通信のためのメカニズムを提供する。インタフェースコントローラ６７は、テキストメッセージと、グラフィックスと、クライアント３１において人間のユーザが解釈することができる他の情報と、を生成する。代替的に、インタフェースコントローラは、クライアント３１とサービスセンタ４０との間に直接通信機能を提供する。

ルールデータベース７７におけるルールは、特定ジョブ要求３２に対して適用することができる提案を述べる。ルールによっては、本質的に反復的であってもよい。すなわち、ルール内の述べられた条件を満足するまでルールを適用し続けてもよい。ルールデータベース７７における他のルールは、ルールに対応するタスクが実行される前に完了すべき必須条件または先行条件を含んでもよい。さらに、ルールによっては、１つまたは複数の先のタスクが完了するまで、対応するステップが発生しないようにする必要条件を有してもよい。たとえば、図２に示すワークフローを参照すると、製版に関するルールが、コンテンツファイル３４等の特定のリソースとプレフライト１７等の先のタスクの完了とを必要とする。

パンフレットをプリントする例では、ジョブ要求（PRINT_DOCUMNET（文書プリント））に述べられている基本要件（コマンド）は、パンフレットをプリントするために必須であっても任意であってもよい特定のコマンド（および関連ルール）を含む。PRINT_DOCUMENTは、PSP_SELECTED（ＰＳＰ選択）を必要とし、PSP_SELECTEDは、USER_SELECTION_PSP(ユーザ選択ＰＳＰ)を必要とし、USER_SELECTION_PSPは、PSP_DISPLAY LIST（ＰＳＰ表示リスト）を必要とし、PSP_DISPLAY LISTはPSP_QUERY（ＰＳＰクエリ）を必要とし、PSP_QUERYは、PREFLIGHT_DOCUMENT（文書プレフライト）を必要とする。これらのコマンドの各々に関連するルールを、ルールの要件を満足するまで適用し続けてもよい。このため、コマンドPSP_SELECTEDを生成するルールにより、ワークフロー発生器６３は、ユーザがプリントサービスを選択する（USER_SELECTION_PSP）までか、またはワークフローコントローラ７０がレジストリ６０を調べてプリントサービスを選択するまで、PSP_SELECTEDを生成するルールを呼出してもよい。言換えれば、ワークフロー発生器６３は、パンフレットをプリントするジョブ要求３２を受取ると、ルールデータベース７７を調べて、満足すべき第１のルールが、文書をプレフライトを行うこと（すなわち、文書プリント要件を取得すること）であると確定する。一旦文書プリント要件が利用可能となると（要件を、ジョブ要求３２とともに提供してもよく、あるいは、通常はプロンプトか、またはジョブ要求３２を発生しているクライアント３１に対するワークフローコントローラ７０からの他の指示に応じて、ジョブ要求３２の提出に続いて入力してもよい）、ルールを調べてワークフローを生成するプロセスが継続する。

ワークフローの生成（およびワークフロー定義ファイル９１_ｉの生成）におけるある時点において、ワークフローコントローラ７０とそのコンポーネント要素とは、要求されたタスクを十分に定義し、適当なサービス８０_ｉを選択して、ワークフローのその実行を開始することができるようにしてもよい。すなわち、実施形態において、ワークフロー発生器６３は、ワークフローの第１の部分を生成するのみであってもよく、後に、サービス８０_ｉが利用可能になる際に、または他の理由によって、特定のタスクが完了する際にワークフローに追加してもよい。このように、ジョブ要求３２に述べられているジョブを開始するために、完全なワークフロー定義は必要ではない。ワークフローの開始に続き、ワークフロー発生器６３は、ワークフローを生成し続けてもよく、先のタスクおよびサブタスクの完了（出力リソース）に基づいて特定のタスクおよびサブタスクを定義してもよい。このため、たとえば、一旦内部ページの数が既知となると綴じのタイプと綴じサービスとを最適化することができるため、文書を綴じるタスクは、文書の内部ページが用意されるまで待機してもよい。このフィードバック機能を、ワークフロー発生器６３と通信するワークフロー実行エンジン６５によって提供することができる。ワークフロー実行エンジン６５は、ワークフロー実行エンジン６５が特定のタスクに対する条件（たとえば、出力リソース）が満たされる時を確定することができるようにするプログラミングおよびアルゴリズムを含んでもよい。ワークフロー実行エンジン６５は、この情報を使用して、ワークフロー発生器６３がワークフローと対応するワークフロー定義ファイル９１_ｉとを動的に変更するかまたは生成し続けることができるように、ワークフロー発生器６３に実際の出力リソース情報を提供してもよい。

図９は、ワークフロー発生器６３によって適用されるような文書プリントルールのアプリケーションの例を示す。図示する例では、クライアント３１は、文書（パンフレット）がプリントされることを要求するジョブ要求３２を、サービスセンタ４０に送信する。ワークフロー発生器６３は、ジョブ要求３２を、PRINT_DOCUMENTと題されたアクションのクラスに属するものと解釈する。そして、ワークフロー発生器６３は、文書プリントに関連する可能性のある１つまたは複数のルールをルールデータベース７７から検索する。それらルールを、それらのアプリケーションの予測されたシーケンスに従って順序付けてもよい。したがって、第１のルール検索は、PREFLIGHT_DOCUMENT８４である。ルールPREFLIGHT_DOCUMENT８４は、関連する必要条件、入力リソースおよび出力リソースを有してもよい。さらに、ルールが適用されるノードを指示してもよい。満足させるべき必須のルールがない場合、ワークフロー発生器６３は、要求された入力リソースに対して実際の入力リソース（たとえば、コンテンツファイル３４で提供される）をチェックすることにより、ワークフロー発生器６３がPREFLIGHT（プレフライト）ノードを生成することができるか否かを確定する。出力リソースは、PREFLIGHTノードにおけるすべての処理が完了した後に利用可能となるべき予測されたリソース（すなわち、コンテンツファイル３４、制御データ３６）を列挙する。PSP_QUERY８５は、必要条件として、PRINT_DOCUMENT命令を有する。すなわち、ジョブ要求３２が文書をプリントするよう要求しない場合、PSP_QUERY８５は呼出されない。PSP_QUERY８５を、２つのノード、すなわちINSIDE PAGES（内部ページ）とCOVER（表紙）とに適用してもよい。それは、両ノードがプリントサービスプロバイダ（サービス８０_ｉ）の使用を要求する可能性があるためである。最終的に、ワークフロー発生器６３は、ルールデータベース７７からＮ個のルールを検索してもよい。しかしながら、ジョブ要求３２を受取った時に、すべてのルールを識別する必要はない。代わりに、ワークフロー生成の動的性質により、ワークフローのあらゆるノードにおけるタスクおよびサブタスクの完了に基づいて追加のルールを調べてもよい。また、上述したように、検索されたルールのうちの１つまたは複数は反復的であってもよく、それは、実際の出力リソースが予測された出力リソースに一致するまでルールは適用され続けることを意味する。

図１０ないし図１３は、要件ベースワークフローを動的に生成し実行するサービスセンタ４０の動作を示すフローチャートである。

図１０は、要件ベースワークフローを動的に順序付ける全動作１００を示す。一例としての動作１００は、図２のノードツリー１０、特に図２に示す内部ページノードの完了に基づく。動作１００は開始ブロック１０１で開始する。ブロック１０５において、サービスセンタ４０は、クライアント３１からジョブ要求３２を受取る。ブロック１１０において、ワークフローコントローラ７０は、ジョブ要求３２において述べられているジョブの性質、すなわち、パンフレットのプリント、またはより包括的には文書のプリントを確定する。ブロック１１５において、ワークフローコントローラ７０は、パンフレットをプリントするために必要とされる可能性のあるあらゆるタスクおよびサブタスクを実行するために、いずれのサービス８０_ｉが利用可能であるかを確定する。ブロック１２０において、ワークフロー発生器６３は、ワークフローにおける１つまたは複数の初期ノード（本明細書では明確にするためにノードＡ、Ｂ、Ｃ、…Ｎと呼ぶ）を、ノードＡに対するノード要件を満足させるために必要なタスクおよびサブタスクとともに定義することにより、パンフレットをプリントするためのワークフローを動的に生成するプロセスを開始する。ブロック１２５において、ワークフロー発生器６３は、要求されたノードＡの入力リソースを利用可能なリソースと比較する。利用可能なリソースが要求されたリソースと一致する場合、動作１００はブロック１３０に進み、ワークフロー発生器６３は、生成されたワークフローを予測されたワークフローと比較することにより、このように生成されたワークフローが少なくとも最初は完全に定義されているか否かを確定する。ワークフローが少なくとも最初は完全に定義されている場合、動作１００はブロック１４０に進む。

ワークフローが少なくとも最初は定義されていない場合、動作１００はブロック１３５に進み、ワークフロー実行エンジン６５は、利用可能なサービス８０_ｉと生成したばかりのノードの要件とを比較し、そのノードの実行を開始してもよいか否かを判断する。ノードの実行を開始してもよい場合、動作はブロック１４０に進む。ブロック１４０において、ワークフロー実行エンジン６５は、選択されたサービス（複数可）８０_ｉに対してノードＡを実行するように指示する。ブロック１３５にしたがい、ノードリソースが満足されない場合、動作１００はブロック１２０に戻り、ワークフローを動的に生成するプロセスが継続する。

ワークフローを生成することと平行して、ワークフロー実行エンジン６５は、ブロック１４５において、ノードＡを定義するタスクおよびサブタスクの実行を監視する。ブロック１５０において、ワークフロー実行エンジン６５は、ノードＡの実際の出力リソースをノードＡの予測された、または要求された出力リソースと比較することにより、ノードＡが満足された時を確定する。ノードＡが満足された場合、ブロック１５５において、ワークフロー実行エンジン６５はワークフロー発生器６３に通知する。ワークフロー発生器６３は、ブロック１２０において、後続するノード（たとえば、ノードＢ、Ｃ、…Ｎ）を生成するプロセスにおいて満足されたノードＡの結果を使用してもよい。ブロック１６０において、ワークフロー実行エンジン６５は、すべてのワークフローノードが満足されたか否かを確定する。すべてのノードが満足された場合、動作１００はブロック１６５に進み、終了する。すべてのノードが満足されなかった場合、動作１００はブロック１４５に戻り、ワークフロー実行エンジン６５は実行を監視し続ける。

図１１は、パンフレットをプリントするために必要となるように予測されるタスクおよびサブタスクを実行するために、１つまたは複数のサービス８０ｉ_ｉを選択する動作１１５の実施形態を示す。検査および割当サービスブロック２０５において、ワークフローコントローラ７０は、いずれのサービス８０_ｉがジョブを完了することができ、そのために利用可能であるかを確定する。実施形態において、ワークフローコントローラ７０は、レジストリ６０を調べることによりこの確定を行う。代替的に、任意のビディングサーバ９０が、ポーリングまたはビディング機能を使用して確定を行ってもよい。複数のサービス８０_ｉが利用可能であり、ジョブ要求３２の要件を満足させることができる場合、ワークフローコントローラ７０は、ブロック２１０において、１つの特定のサービス８０をジョブに割当ててもよい。代替的に、ワークフローコントローラ７０は、クライアント３１にサービス８０_ｉのリストを提供してもよく（ブロック２１５）、クライアント３１が１つまたは複数のサービス８０_ｉを選択することができるようにしてもよい（ブロック２２０）。そして、動作１１５は終了し、処理は動作１００に戻る。

図１２は、ワークフローを動的に生成する動作１２０の実施形態を示す。上述したように、ジョブ要求３２は、パフォーマンス要件、リソースおよび他のパラメータ（すなわち、制御データファイル３６）を指定してもよく、またコンテンツファイル３４かまたはコンテンツファイル３６へのリンクを含んでもよい。制御データファイル３６は、ジョブ要求３２において述べられているジョブが、データベース９０に格納されていてもよい先に定義されたワークフローに従って、完了されるべきであると識別してもよい。代替的に、ジョブ要求３２において述べられているジョブは、新たなワークフローの生成を要求してもよい。制御データファイル３６が既存のワークフローの使用を指示する場合であっても、ワークフローコントローラ７０は、新たなサービス８０_ｉに基づいて、または他の理由でワークフローを動的に変更してもよい。ブロック３０５において、ジョブ要求３２において述べられているジョブの性質の確定に続き、ワークフローコントローラ７０は、要求されたジョブが既存のワークフローの使用を含むか否かを確定する。既存のワークフローが使用される場合、ワークフロー発生器は、データベース９０から要求されたワークフローを検索する（ブロック３１０）。新たなワークフローが生成される場合、動作１２０はブロック３１５に進む。ブロック３１５において、ワークフロー発生器６３はルールデータベース７７を調べ、文書プリントジョブ要求の場合、適用すべき第１のルールがPREFLIGHT（図２のノード１７およびこの例ではノードＡ）であると確定する。ブロック３２０において、ワークフロー発生器６３は、ルールデータベース７７からPREFLIGHTルールを検索する。ブロック３２５において、ワークフロー発生器６３は、ジョブ要求３２のコンテンツファイル３４と制御データファイル３６とを、PREFLIGHTルールにおいて指定された入力リソース要件と比較する。ジョブ要求３２がPREFLIGHTルール入力リソース要件を満たす場合、動作１００はステップ３３０に進み、ワークフロー発生器は、ワークフロー定義ファイル９１_ｉに関してPREFLIGHTノード（ノードＡ）を調べる。ブロック３２５の比較の結果要件が満たされない場合、動作はステップ３３５に進み、ワークフローコントローラ７０はインタフェース６７を使用して、クライアント３１に対し、追加の情報または入力リソースが必要であることを通知する。かかる通知は、たとえば、ポップアップウィンドウ表示、テキストメッセージまたはクライアント３１に対するプロシージャコールを含んでもよい。そして、動作１２０はブロック３１０に戻り、サービスセンタ４０は変更されたジョブ要求を受取るのを待つ。動作１２０は、任意選択で、クライアント３１が指定された時間内にブロック３３５の通知に応答しない場合に動作１２０（および動作１００）を終了する、タイムアウト機能を含んでもよい。

図１３は、動的にワークフローを生成し定義を順序付けする代替動作１２０’を示す。ブロック３５５において、ワークフローコントローラ７０は、ワークフローが複数のブランチを含むか否かを確定する。ワークフローが複数のブランチを含む場合、ワークフローコントローラ７０は、ブロック３６０においてブランチを定義する。ブロック３６５において、ワークフローコントローラ７０は、リソースおよびサービス８０_ｉが定義されるブランチを選択する。ブロック３７０において、ワークフローコントローラ７０は、第１のノードに対する入力リソースを定義する。ブロック３７５において、ワークフローコントローラ７０は、第１のノードに対して完了されるべきタスクを定義する。ブロック３８０において、ワークフローコントローラ７０は、第１のノードの出力リソースを確定する。ブロック３８５において、ワークフローコントローラ７０は、ワークフローまたはブランチに対して別のノードが必要であるか否かを確定する。更なるノードが必要でない場合、ワークフローコントローラ７０は、ブロック３９０において、別のブランチが定義されるべきか否かを確定する。別のブランチが定義されるべきである場合、ワークフローコントローラ７０は、ブロック３６５において別のブランチを選択し、動作１２０’は継続する。別のブランチが定義されるべきではない場合、動作１２０’は終了し、処理は動作１００に戻る。

図１０ないし図１３に示す方法を、たとえば、適当にプログラムされた汎用コンピュータ、専用コンピュータおよび特定用途向け集積回路によって実行することができる。プログラミングを、たとえば磁気記憶媒体および光記憶媒体を含むコンピュータ読取可能媒体に書込むことができる。

本明細書で使用する用語および説明は、単に例として示すものであり、限定するものとしては意図されていない。当業者は、特許請求の範囲において定義されるような発明およびそれらの等価物の精神および範囲内で、多くの変形形態が可能である、ということを認めるであろう。特許請求の範囲においては、すべての用語が特に指示がない限りあり得る最も広い意味で理解されるべきである。

以下に本発明の実施態様の例を列挙する。
〔実施態様１〕
要件ベースワークフローを動的に順序付けするシステムであって、
受取られたジョブ要求を完了するのに利用可能なサービスに関連する情報を格納するレジストリと、
前記受取られたジョブ要求に基づいて１つまたは複数のノードを含むワークフローを動的に生成することができ、前記ジョブ要求の性質に基づいて前記ワークフローを構成するための要件を指定するルールを含むルールデータベースを備え、前記ルールの前記要件を先のノードの出力と比較することにより後続するノードを生成することにより、前記ワークフローを動的に生成するワークフローコントローラであって、前記サービスが前記ノードを実行するものである、ワークフローコントローラと、
を具備するシステム。
〔実施態様２〕
分散ネットワークにおけるサービスセンタをさらに具備し、該サービスセンタは、１つまたは複数のクライアントと、前記サービスと、前記ワークフローコントローラとを結合するように動作可能であり、前記１つまたは複数のクライアントはジョブ要求を発生する、実施態様１記載のシステム。
〔実施態様３〕
前記ワークフローコントローラは、前記ワークフローにおけるノードの実行を監視するワークフロー実行エンジンをさらに備え、該ワークフロー実行エンジンは、ノードが完了する時を指示する、実施態様１記載のシステム。
〔実施態様４〕
前記レジストリは、前記サービスに関連する前記情報をサービスのタイプ毎に含む、実施態様１記載のシステム。
〔実施態様５〕
前記ワークフローコントローラは、前記ワークフローにおけるノードを実行するのに前記利用可能なサービスのうちのいずれのサービスが割当てられるかを確定する手段を備える、実施態様１記載のシステム。
〔実施態様６〕
前記確定する手段は、前記ノードを実行するために最適なサービスを確定するランキングアルゴリズムを備える、実施態様５記載のシステム。
〔実施態様７〕
前記ランキングアルゴリズムは、クライアントが提供する基準に基づく、実施態様６記載のシステム。
〔実施態様８〕
要件ベースワークフローを動的に順序付けする方法であって、
完了されるべきジョブを指定するジョブ要求を受取ること、
前記ジョブに基づいて動的ワークフローシーケンスを生成することであり、
該ワークフローシーケンスにおける第１のノードを定義すること、および
前記第１のノードに対する入力リソースと予測された出力リソースとを確定すること、
を含む動的ワークフローシーケンスを生成すること、
前記第１のノードが実行し得る時を確定することであって、前記第１のノードの実行が開始する、確定すること、および
前記第１のノードの実際の出力リソースに基づいて、前記ジョブを満足させるために追加のノードが必要であるか否かを確定すること、
を含む方法。
〔実施態様９〕
前記ジョブ要求における前記ジョブの性質を確定することをさらに含む実施態様８記載の方法。
〔実施態様１０〕
ルールデータベースを調べることであって、それによって、前記ジョブの性質に基づいて確定される少なくとも第１のルールの適用を確定する、調べること、および
前記少なくとも第１のルールを反復的に適用することであって、それによって、前記第１のノードを定義する、適用すること、
をさらに含む実施態様９記載の方法。

ワークフロー実行のための従来技術によるソリューションを示す。 実施形態によるワークフローにおける個々の要件を定義するために使用してもよいノードツリーを示す。 実施形態による図２に示すワークフロー等、要件ベースワークフローを動的に生成するシステムのブロック図を示す。 図３に示すシステムのコンポーネントのブロック図である。 図３のシステムで使用されるレジストリの論理図である。 図３のシステムの選択された機能を示す図である。 図４のコンポーネントの制御機能を示すブロック図である。 図４のワークフローコントローラのブロック図である。 図８のワークフローコントローラで使用されるルールベースデータベースの論理図である。 図３のシステムを使用して要件ベースワークフローを動的に生成する方法を示すフローチャートである。 図３のシステムを使用して要件ベースワークフローを動的に生成する方法を示すフローチャートである。 図３のシステムを使用して要件ベースワークフローを動的に生成する方法を示すフローチャートである。 図３のシステムを使用して要件ベースワークフローを動的に生成する方法を示すフローチャートである。

Claims (10)

1. 要件ベースワークフローを動的に順序付けするシステムであって、
   受取られたジョブ要求を完了するのに利用可能なサービスに関連する情報を格納するレジストリと、
   前記受取られたジョブ要求に基づいて１つまたは複数のノードを含むワークフローを動的に生成することができ、前記ジョブ要求の性質に基づいて前記ワークフローを構成するための要件を指定するルールを含むルールデータベースを備え、前記ルールの前記要件を先のノードの出力と比較することにより後続するノードを生成することにより、前記ワークフローを動的に生成するワークフローコントローラであって、前記サービスが前記ノードを実行するものである、ワークフローコントローラと、
   を具備するシステム。
2. 分散ネットワークにおけるサービスセンタをさらに具備し、該サービスセンタは、１つまたは複数のクライアントと、前記サービスと、前記ワークフローコントローラとを結合するように動作可能であり、前記１つまたは複数のクライアントはジョブ要求を発生する、請求項１記載のシステム。
3. 前記ワークフローコントローラは、前記ワークフローにおけるノードの実行を監視するワークフロー実行エンジンをさらに備え、該ワークフロー実行エンジンは、ノードが完了する時を指示する、請求項１記載のシステム。
4. 前記レジストリは、前記サービスに関連する前記情報をサービスのタイプ毎に含む、請求項１記載のシステム。
5. 前記ワークフローコントローラは、前記ワークフローにおけるノードを実行するのに前記利用可能なサービスのうちのいずれのサービスが割当てられるかを確定する手段を備える、請求項１記載のシステム。
6. 前記確定する手段は、前記ノードを実行するために最適なサービスを確定するランキングアルゴリズムを備える、請求項５記載のシステム。
7. 前記ランキングアルゴリズムは、クライアントが提供する基準に基づく、請求項６記載のシステム。
8. 要件ベースワークフローを動的に順序付けする方法であって、
   完了されるべきジョブを指定するジョブ要求を受取ること、
   前記ジョブに基づいて動的ワークフローシーケンスを生成することであり、
   該ワークフローシーケンスにおける第１のノードを定義すること、および
   前記第１のノードに対する入力リソースと予測された出力リソースとを確定すること、
   を含む動的ワークフローシーケンスを生成すること、
   前記第１のノードが実行し得る時を確定することであって、前記第１のノードの実行が開始する、確定すること、および
   前記第１のノードの実際の出力リソースに基づいて、前記ジョブを満足させるために追加のノードが必要であるか否かを確定すること、
   を含む方法。
9. 前記ジョブ要求における前記ジョブの性質を確定することをさらに含む請求項８記載の方法。
10. ルールデータベースを調べることであって、それによって、前記ジョブの性質に基づいて確定される少なくとも第１のルールの適用を確定する、調べること、および
    前記少なくとも第１のルールを反復的に適用することであって、それによって、前記第１のノードを定義する、適用すること、
    をさらに含む請求項９記載の方法。
    

Images