(57)【要約】      （修正有）【課題】ワークフローアプリケーションの複数サーバでの分散処理における信頼性の高いフォールトハンドリングを提供する。【解決手段】各タスクサーバ２２は、タスクサーバプロセス４２をローカルで実行するオペレーティングシステム４０を備え、タスクサーバ２２上で実行するワークフロープロセス４２は、実行準備が整ったワークフロータスクを識別するスケジュールキューからワークフロータスクを要求する。タスクサーバプロセス４２がタスクを完了すると、タスクサーバプロセス４２は、キューから新規タスクを要求する。部分的に実行されたタスクが失敗したり、あるいは、不適切にストールすると、ワークフロー管理サーバ２４がこの状況を検出し、そのタスクの任意のトランザクションをロールバックし、タスクを再度キューする。【選択図】図１
2011123881.tif 000002
【特許請求の範囲】
【請求項１】
複数のタスクサーバ上でワークフローを実行する方法であって、
前記複数のタスクサーバ上で複数のタスクサーバプロセスを開始する工程と、ここで、各タスクサーバは、各タスクサーバプロセスをローカルで実行するように構成かつ配置されているオペレーティングシステムを提供し、
一連の従属関係が予め定められたアクティビティを含むワークフローを受信する工程と、
前記受信したワークフローに基づいて、タスク識別子をキュー構造に配置する工程と、ここで、前記タスク識別子は、前記複数のタスクサーバ上で開始された前記複数のタスクサーバプロセスによって分散して実行されるタスクを識別し、各タスクは、前記ワークフローの従属関係の予め定められたアクティビティの特定の実行であり、前記ワークフローを実行時の進捗は、前記複数のタスクサーバプロセスが、（ｉ）前記キュー構造からタスク識別子を要求し、（ｉｉ）前記要求されたタスク識別子によって識別された前記タスクを実行する際になされる、
を含む方法。
【請求項２】
特定のタスクサーバ上で実行している特定のタスクサーバプロセスが、前記キュー構造から特定のタスク識別子を要求した場合、
前記特定のタスクサーバプロセスによって、前記ワークフローの特定の従属関係の予め定められたアクティビティによって定義されるタスク特定ロジックを実行する工程と、
ここで、前記ワークフローの前記特定の従属関係の予め定められたアクティビティは、前記特定のタスク識別子によって識別され、
前記特定のタスクサーバプロセスが前記タスク特定ロジックの実行を完了した際に、トランザクションをワークフローデータベースに委ねて、前記タスク特定ロジックの完了を記録する工程と、
をさらに含む請求項１に記載の方法。
【請求項３】
前記特定の従属関係の予め定められたアクティビティが、前記特定の従属関係の予め定められたアクティビティに従属する前記ワークフローの次の予め定められたアクティビティを識別し、
前記方法が、前記特定のタスクサーバプロセスが前記タスク特定ロジックの実行を完了した際に、前記トランザクションを前記ワークフローデータベースに委ねて前記タスク特定ロジックの完了を記録する前に、前記特定のタスクサーバプロセスによって新規タスク識別子を前記キュー構造に配置する工程をさらに含み、
ここで、前記新規タスク識別子は、新たにスケジュール設定されたタスクとして、前記特定の従属関係の予め定められたアクティビティに従属する前記ワークフローの前記次の予め定められたアクティビティの特定の実行を識別する請求項２に記載の方法。
【請求項４】
前記特定のタスクサーバプロセスが、前記キュー構造から前記特定のタスク識別子を要求する場合に、前記新規タスク識別子を従属キューに最初に追加し、
前記特定のタスクサーバプロセスが、前記新規タスク識別子を前記キュー構造に配置する場合に、前記新規タスク識別子を前記従属キューからレディキューに移動させるように構成かつ配置されている請求項３に記載の方法。
【請求項５】
前記ワークフローデータベースに委ねられたトランザクションに基づいてワークフロー完了レポートを作成する工程をさらに含み、
前記ワークフロー完了レポートが、ユーザへのワークフロー完了のログを識別する請求項３に記載の方法。
【請求項６】
前記複数のタスクサーバが、ハートビート信号を周期的に出力するように構成かつ配置されており、
各タスクサーバプロセスが、前記キュー構造からタスク識別子を要求する場合に、レディキューから前記タスク識別子をデキューし、要求されたタスクリストを更新するよう構成かつ配置されており、
前記方法が、前記要求されたタスクリストと、前記複数のタスクサーバによって周期的に出力された前記ハートビート信号とを監視して、ストールしている任意のタスクを検出する工程をさらに含む請求項１に記載の方法。
【請求項７】
前記要求されたタスクリストおよび前記ハートビート信号の監視に基づいてストールしている特定のタスクの検出時に、前記特定のタスクによってなされた任意のトランザクションをロールバックする工程と、前記特定のタスクを識別する新規タスク識別子を前記レディキューに配置する工程とをさらに含む請求項６に記載の方法。
【請求項８】
前記要求されたタスクリストおよび前記ハートビート信号の監視に基づいて失敗した特定のタスクサーバの検出時に、前記特定のタスクサーバ上で実行している未完了タスクによってなされた任意のトランザクションをロールバックする工程と、前記未完了タスクを識別する新規タスク識別子を前記レディキューに配置する工程とをさらに含む請求項６に記載の方法。
【請求項９】
前記ワークフローを受信する工程が、前記ワークフローとして、前記ワークフロー管理サーバのメモリサブシステムでオブジェクトグラフとして表わされる前記従属関係の予め定められたアクティビティの階層を取得する工程を含む請求項１に記載の方法。
【請求項１０】
前記ワークフロー管理サーバの前記メモリサブシステムで前記オブジェクトグラフのワークフロー定義を更新する工程と、前記ワークフロー管理サーバから前記複数のタスクサーバに前記更新されたワークフロー定義を送信する工程とをさらに含む請求項９に記載の方法。
【請求項１１】
前記オブジェクトグラフとして表わされた前記従属関係の予め定められたアクティビティの前記階層が、デジタル資産管理システムのデジタル資産トランザクションをアーカイブに保管するように構成かつ配置されている請求項９に記載の方法。
【請求項１２】
前記デジタル資産管理システムが、コンピュータネットワークを通じて前記ワークフロー管理サーバに接続された複数のホスト装置を備え、
各タスクサーバが、前記ホスト装置の１つ上の仮想マシンとして実現される請求項１１に記載の方法。
【請求項１３】
前記デジタル資産管理システムが、コンピュータネットワークを通じて前記ワークフロー管理サーバに接続された複数の物理マシンを備え、
各物理マシンが、前記タスクサーバの１つをネイティブに実行する請求項１１に記載の方法。
【請求項１４】
一連の従属関係が予め定められたアクティビティを含むワークフローを実行するためのシステムであって、前記システムは：
複数のタスクサーバと、
前記複数のタスクサーバに接続されたワークフロー管理サーバと、
を備え、
前記ワークフロー管理サーバは：
前記複数のタスクサーバ上で複数のタスクサーバプロセスを開始し、ここで、各タスクサーバは、各タスクサーバプロセスをローカルで実行するためのオペレーティングシステムを提供し、
キュー構造を維持し、
タスク識別子をキュー構造に配置する、ここで、前記タスク識別子は、前記複数のタスクサーバ上で開始された前記複数のタスクサーバプロセスによって分散して実行されるタスクを識別し、各タスクは、前記ワークフローの従属関係の予め定められたアクティビティの特定の実行であり、前記ワークフローを実行時の進捗は、前記複数のタスクサーバプロセスが、（ｉ）前記キュー構造からタスク識別子を要求し、（ｉｉ）前記要求されたタスク識別子によって識別された前記タスクを実行する際になされる、ように構成かつ配置されているシステム。
【請求項１５】
前記複数のタスクサーバが、ハートビート信号を周期的に出力するように構成かつ配置されており、
各タスクサーバプロセスが、前記キュー構造からタスク識別子を要求する場合に、レディキューから前記タスク識別子をデキューし、要求されたタスクリストを更新するよう構成かつ配置されており、
前記ワークフロー管理サーバが、（ｉ）前記要求されたタスクリストと、前記複数のタスクサーバによって周期的に出力された前記ハートビート信号とを監視して、ストールしている任意のタスクを検出し、（ｉｉ）前記要求されたタスクリストおよび前記ハートビート信号の監視に基づいてストールしている特定のタスクの検出時に、前記特定のタスクによってなされた任意のトランザクションをロールバックし、前記特定のタスクを識別する新規タスク識別子を前記キュー構造に配置するようにさらに構成かつ配置されており、
前記複数のタスクサーバが、複数のホスト装置上で実行している仮想マシンとして実現される請求項１４に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
従来型ワークフローアプリケーションは、単一の物理マシン上でネイティブに実行する。従って、ユーザがワークフローベースのプログラムを構成かつ実行可能なワークフロー開発および実行プラットフォームを提供する。コードのラインを単に書くという従来の方法とは異なり、ワークフローアプリケーションのユーザは、別々のワークフローアクティビティを作成した後、別々のワークフローアクティビティを一緒にリンクさせることでワークフローベースプログラムを構成する。
【背景技術】
【０００２】
ランタイム時に、単一の物理マシン上でネイティブに実行しているワークフローアプリケーションは、アクティビティが互いにどのようにリンクしているかに基づいて、ワークフローアクティビティを順番に実行する。特に、ワークフローアプリケーションは、各々のアクティビティを、ワークフローの他のアクティビティと相互従属しているロジックの離散（またはアトミック）ピースとして扱う。
【０００３】
例えば、アクティビティＢがアクティビティＡに従属する場合、ワークフローアプリケーションは、ワークフローアプリケーションがアクティビティＡの実行を終了するまでアクティビティＢを実行しない。上述したものと同様の従来型ワークフロープラットフォームは、マイクロソフト（ワシントン州レットモンド）によって提供されるＷｉｎｄｏｗｓ（登録商標）  Ｗｏｒｋｆｌｏｗ  Ｆｏｕｎｄａｔｉｏｎ（ＷＦ）技術である。
【発明の概要】
【０００４】
残念なことに、上述の従来型ワークフローアプリケーションには欠点がある。例えば、上述の従来型ワークフローアプリケーションは、うまくスケールしない。むしろ、従来型ワークフローアプリケーションの能力は、それをネイティブに実行する単一の物理マシンの処理能力に限定される。
【０００５】
さらに、上述の従来型ワークフローアプリケーションは、アクティビティの失敗をうまく処理しない。特に、従来型ワークフローアプリケーションは、部分的に実行されたアクティビティが完了し損なう場合に、アクティビティの失敗を検出し、優雅に修復する直接的な機構を提供しない。これらの状況を適切に処理する信頼性の高い機構なしには、未完了なアクティビティは、さらなる進捗をするためのワークロードの能力を妨げ、ハング状態または暴走状態のままになり、他のアクティビティの実行を遅らせてしまう。
【０００６】
上述の従来型ワークフローアプリケーションとは異なり、改良された技術は、タスクサーバプロセスをローカルで実行するオペレーティングシステムを備えた複数のタスクサーバを利用する。タスクサーバ上で実行しているこれらのタスクサーバプロセスは、実行準備が整ったワークフロータスクを識別するスケジュールキューからワークフロータスク（即ち、予め定められたアクティビティのインスタンシエーション）を要求する。タスクサーバプロセスがタスクを完了すると、タスクサーバプロセスは、キューから新規タスクを要求する。その結果、タスクは、タスクサーバプロセスが現在のタスク完了時に新規タスクを要求するので、タスクサーバ全体にわたって自然にロードバランスがなされる。さらに、部分的に実行されたタスクが失敗したり、あるいは、不適切にストールすると、ワークフロー管理サーバは、この状況を検出し、そのタスクの任意のトランザクションをロールバックし、タスクパフォーマンスを再度キューする、即ち、全てのトランザクションをうまく完了することができる新規タスクをキューする。従って、改良された技術は、信頼性の高いフォールトハンドリングを提供する。
【０００７】
一実施形態は、複数のタスクサーバ上でワークフローを実行する方法に関する。本方法は、複数のタスクサーバ上で複数のタスクサーバプロセスを開始する工程を含む。各タスクサーバは、各タスクサーバプロセスをローカルで実行するように構成かつ配置されているオペレーティングシステムを提供する。本方法は、一連の従属関係が予め定められたアクティビティを含むワークフローを受信する工程と、受信したワークフローに基づいて、タスク識別子をキュー構造に配置する工程とをさらに含む。タスク識別子は、複数のタスクサーバ上で開始された複数のタスクサーバプロセスによって分散して実行されるタスクを識別する。各タスクは、ワークフローの従属関係の予め定められたアクティビティの特定の実行である。ワークフロー実行時の進捗は、複数のタスクサーバプロセスが、（ｉ）キュー構造からタスク識別子を要求し、（ｉｉ）要求されたタスク識別子によって識別されたタスクを実行する際になされる。
【０００８】
別の実施形態は、一連の従属関係が予め定められたアクティビティを含むワークフローを実行するためのシステムに関する。本システムは、複数のタスクサーバと、複数のタスクサーバに接続されたワークフロー管理サーバとを含む。本システム内で、ワークフロー管理サーバは、複数のタスクサーバ上で複数のタスクサーバプロセスを開始するように構成かつ配置されている。各タスクサーバは、各タスクサーバプロセスをローカルで実行するためのオペレーティングシステムを提供する。ワークフロー管理サーバはさらに、キュー構造を維持し、かつ、タスク識別子をキュー構造に配置するように構成かつ配置されている。上述の方法と同様に、タスク識別子は、複数のタスクサーバ上で開始された複数のタスクサーバプロセスによって分散して実行されるタスクを識別する。各タスクは、ワークフローの従属関係の予め定められたアクティビティの特定の実行である。ワークフロー実行時の進捗は、複数のタスクサーバプロセスが、（ｉ）キュー構造からタスク識別子を要求し、（ｉｉ）要求されたタスク識別子によって識別されたタスクを実行する際になされる。
【０００９】
前述および他の目的、特徴、および利点は、添付図面を参照する本発明の特定の実施形態の以下の説明から明らかになるであろう。図中、同様の参照符号は様々な図を通じて同様の部分を示している。図面は必ずしも比例尺で描かれておらず、代りに、本発明の種々の実施形態の原理を示す場合は強調されている。
【図面の簡単な説明】
【００１０】
【図１】一連の従属関係が予め定められたアクティビティを含むワークフローを実行するように構成かつ配置されているワークフローシステムのブロック図である。
【図２】図１のワークフローシステムのワークフロー管理サーバの分散型ワークフローコントローラのブロック図である。
【図３Ａ】図１のワークフローシステムによってサポートされる単純型アクティビティの図である。
【図３Ｂ】図１のワークフローシステムによってサポートされる順次型アクティビティの図である。
【図３Ｃ】図１のワークフローシステムによってサポートされる並列型アクティビティの図である。
【図３Ｄ】図１のワークフローシステムによってサポートされるループ（ｗｈｉｌｅ−ｌｏｏｐ）型アクティビティの図である。
【図４】図１のワークフローシステムによって処理されるタスク（即ち、予め定められたアクティビティのインスタンシエーション）の種々の状態の図である。
【図５】図２の分散型ワークフローコントローラによって維持されるプロセステーブルの図である。
【図６】図２の分散型ワークフローコントローラによって実行される方法のフローチャートである。
【発明を実施するための形態】
【００１１】
概要
改良型の技術は、タスクサーバプロセスを実行する複数のタスクサーバ（即ち、仮想マシン、物理マシン、またはその組み合わせ）を利用する。タスクサーバプロセスは、実行準備が整った（ｒｅａｄｙ−ｔｏ−ｅｘｅｃｕｔｅ）ワークフロータスク（即ち、ワークフローアクティビティのインスタンシエーション）のキューからワークフロータスクを要求する。かかるオペレーションは、複数のタスクサーバ間のタスクについてロードバランスを行う。さらに、部分的に実行されたタスクが失敗すると、ワークフロー管理サーバは、失敗を検出し、そのタスクの任意の実行されたトランザクションを必要に応じてロールバックし、タスクを再度キューすることができる。その結果、この技術は、信頼性の高いフォールトトレランスを提供する。
【００１２】
図１は、ワークフローを分散して実行するように構成かつ配置されているワークフローシステム２０を示す。ワークフローシステム２０は、タスクサーバ２２（１）、２２（２）、…（集合的にタスクサーバ２２）、ワークフロー管理サーバ２４、および通信媒体２６を含む。タスクサーバ２２は、ワークフロー管理サーバ２４のみならず互いに通信することができ、なおかつ、通信媒体２６を通じて電子データ信号３０を交換することによって１つ以上の他の装置２８とも通信することができる。
【００１３】
通信媒体２６は、堅牢かつ信頼性の高い通信用のコンピュータネットワーク機器（例、ケーブル、スイッチ、ルーター、光ファイバ装置、ワイヤレス装置、他のネットワーク構成要素、その組み合わせなど）を含むのが好ましい。従って、電子データ信号３０としては、パケット、セル、フレーム、光ファイバ信号、無線信号、その組み合わせなどが挙げられる。さらに、通信媒体２６は、種々のトポロジー（例、ハブ＆スポーク、リング、バックボーン、不規則、その組み合わせなど）を有することができるため、ネットワーククラウドとして示される。さらに、通信媒体２６は、１つ以上のＬＡＮ、ＷＡＮ、公衆通信回線、インターネットなどに広がり得る。
【００１４】
各タスクサーバ２２は、少なくとも１つのタスクサーバプロセス４２をローカルで実行するためのオペレーティングシステム４０を提供する。例えば、タスクサーバ２２（１）は、１つ以上のタスクサーバプロセス４２（１）を実行するためのオペレーティングシステム４０（１）を提供する。同様に、タスクサーバ２２（２）は、１つ以上のタスクサーバプロセス４２（２）を実行するためのオペレーティングシステム４０（２）を提供する。以下、同様。
【００１５】
いくつかの構成において、タスクサーバ２２は、物理マシンとして実現される、即ち、オペレーティングシステム４０およびタスクサーバプロセス４２は、物理マシン上にネイティブに実行する。これらの構成において、各物理マシンは、物理資源の冗長性を最大化するために独自の物理資源セット（例：電源、プロセッサ容量、メモリなど）を持っているのが好ましい。システム２０は、物理マシン上で実行しているタスクサーバプロセス４２の数、および／または、システム２０における物理マシンの数あるいは計算能力を増加することによって容易にスケールされる。
【００１６】
別の構成において、タスクサーバ２２は、プールされたホスト装置上で実行している仮想マシンとして実現される。これらの構成において、特定のホスト装置は、１つ以上のゲストオペレーティングシステムをサポートし、コンピュータ資源の共有に関してさらなる柔軟性や効率を提供してもよい。同様に、システム容量は、ホスト装置の数あるいは計算能力を増加することによって容易に増すことができる。
【００１７】
さらに別の構成において、タスクサーバ２２は、物理マシンとして実現される物理マシンタスクサーバと、一連のホスト装置上で実行している仮想マシンとして実現される仮想マシンタスクサーバとの両方を含む。ここで、物理マシンタスクサーバと仮想マシンタスクサーバは、協働して動作し、ワークフロー６０の従属関係の予め定められたアクティビティ５８をロードバランスをとりフォールトトレランスをとりながら実行する。
【００１８】
ワークフロー管理サーバ２４は、デザイン・コンパイルステージ５０と、記憶装置５２と、分散型ワークフローコントローラ５４と、ツール５６とを含む。これらのコンポーネントが動作することで、ユーザに堅牢かつ信頼性の高いワークフロー開発プラットフォームおよびランタイム環境を提供する。
【００１９】
デザイン・コンパイルステージ５０により、ユーザはアクティビティ５８を作成し、記憶装置５２にアクティビティを格納することができる。これらの線に沿って、ユーザは、アクティビティ５８を作成する際、ＸＭＬエディタまたはＷＹＳＩＷＹＧデザインツールなどのユーザインタフェースを介して入力を入れる。アクティビティ５８が予め定められた型になった状態で、ユーザは、従属関係を介してアクティビティ５８を相互関連させ、コンパイラを実行することで、１つ以上のワークフロー６０を作成する。アクティビティＢがアクティビティＡの後に続いて起こらなければならない場合、アクティビティＢは、アクティビティＡに従属してもよい。さらに、アクティビティＣが子アクティビティ（恐らく、他の子アクティビティに沿って）としてアクティビティＤを含む場合、アクティビティＤは、アクティビティＣに従属してもよい。Ｖｉｓｕａｌ  Ｓｔｕｄｉｏで入手可能なＭｉｃｒｏｓｏｆｔ．ＮＥＴ  Ｗｉｎｄｏｗｓ（登録商標）  Ｗｏｒｋｆｌｏｗ  Ｆｏｕｎｄａｔｉｏｎ（ＷＦ）のＷＹＳＩＷＹＧデザイナーや標準のＣ＃コンパイラは、デザイン・コンパイルステージ５０の少なくとも一部として使用するのに適したツールの例である。
【００２０】
記憶装置５２は、ワークフロー管理サーバ２４のメモリサブシステムであり、デザイン・コンパイルステージ５０から予め定められたアクティビティ５８とワークフロー６０とを受信し、格納するように構成かつ配置されている。記憶装置５２はさらに、ワークフローシステム２０の特定の属性（例、コンピュータ名、動作パラメータなど）を詳細に示す構成データ、ユーザアカウント情報などの他の情報６２を受信し、格納するように構成かつ配置されている。この構成データは、ユーザによって入力され、後で変更してもよく、あるいは、変更可能なデフォルト設定として最初に入手可能であってもよい。
【００２１】
さらに詳細について簡潔に説明すると、予め定められたアクティビティ５８は、基本的には、アトミック単位として実行するようになっているコードのブロックであるが、予め定められたアクティビティ５８の特定の実行あるいはインスタンシエーションは、タスクと呼ばれる。各々の予め定められたアクティビティ５８は、入力を受信し、入力を処理し、入力の処理に応じて出力を生成することができる。さらに、ワークフロー６０は、明確に定められた順番で実行するように構成された予め定められたアクティビティ５８の階層である。すなわち、ユーザは、予め定められたアクティビティ５８を一緒にリンクさせて、ワークフロー６０を形成する。これらの線に沿って、ワークフロー６０は、従属関係の予め定められたアクティビティ５８の流れ図として視覚化することができる。流れ図は、オブジェクトグラフとしてシステム２０内で内部的に表わされる。
【００２２】
分散型ワークフローコントローラ５４は、ワークフローシステム２０内のワークフロー６０のパフォーマンス制御を担当するワークフロー管理サーバ２４の一部である。分散型ワークフローコントローラ５４は、タスクサーバ２２間でタスクサーバプロセス４２の初期展開を制御するのみならず、追加のタスクサーバプロセス４２の任意のその後の展開、ならびにワークフローパフォーマンス中のタスクサーバプロセス４２間でのタスクの実行を制御する動作インフラストラクチャ（例、トランザクションデータベース、キュー、ハートビートデーモンなど）を維持する。さらに、分散型ワークフローコントローラ５４は、ワークフロー６０によってなされたトランザクション／進捗のログをとる。
【００２３】
ツール５６は、ユーザがワークフローシステム２０のオペレーションを監視できるのみならず、システム管理動作を行い、レポートを生成できるように構成かつ配置されている。例えば、ツール５６は、分散型ワークフローコントローラ５４のトランザクションデータベースを検索して、ワークフローの進捗、調査トレンド、およびパフォーマンス統計をトラッキングすることができる。
【００２４】
ワークフローシステム２０は、基本的に、有用な作業を実行するための製品アグノスティックなコアエンジンを提供することを理解すべきである。例えば、デジタル資産管理システム（図１の他の装置２８も参照されたい）の状況において、ワークフローシステム２０は、デジタル資産管理システムの種々のコンポーネント（例、ユーザワークステーション、ラップトップ、データベースサーバなど）上で起こっているデジタル資産トランザクションイベントをトラッキングするように構成することができる。特に、ワークフローシステム２０は、デジタル資産の作成、デジタル資産の複写、デジタル資産の読み込み、デジタル資産の変更、およびデジタル資産の削除を特にトラッキングするように構成することができる。さらに、ワークフローシステム２０は、デジタル資産のロケーションのみならず、いつどこでデジタル資産がバックアップおよび／またはアーカイブされるかについてもトラッキングすることができる。ワークフローシステム２０が使用可能なデジタル資産管理システムの例としては、「Ｓｙｓｔｅｍｓ  ａｎｄ  Ｍｅｔｈｏｄｓ  ｆｏｒ  Ｓｔｏｒｉｎｇ  Ｍｅｔａ−Ｄａｔａ  Ｓｅｐａｒａｔｅ  ｆｒｏｍ  ａ  Ｄｉｇｉｔａｌ  Ａｓｓｅｔ」と題された米国出願第１１／２８３，２５２号に記載されており、その教示全体を参照によって本明細書に引用したものとする。
【００２５】
ワークフロー管理サーバ２４および／またはタスクサーバ２２の１つ以上のソフトウェアコンポーネントは、コンピュータプログラム製品７０（図１にディスケットアイコン７０によって概括的に示す）の形で配信可能なことをさらに理解すべきである。かかるコンピュータプログラム製品７０としては、コンピュータ化されたプロセッサ（例、マイクロプロセッサ、一連のプロセッサなど）によって実行される命令を格納するためのコンピュータ可読媒体が挙げられる。適当なコンピュータ可読媒体の例としては、ＣＤ−ＲＯＭ、フラッシュメモリ、ディスクメモリ、テープメモリなどの有形の製造製品および装置が挙げられる。図２を参照しながらさらなる詳細について説明する。
【００２６】
ワークフロー制御
図２は、分散型ワークフローコントローラ５４の具体的な詳細を示す。分散型ワークフローコントローラ５４は、インタフェース８０と、制御ロジック８２と、メモリ８４とを含む。上述のように、分散型ワークフローコントローラ５４は、タスクサーバプロセス４２の展開を制御するのみならず、ワークフローランタイム中のシステム２０のオペレーション（即ち、分散ワークフローエンジンとして）を制御する。
【００２７】
インタフェース８０は、記憶装置５２からアクティビティ５８およびワークフロー６０にアクセスするように構成されている（図１も参照）。さらに、インタフェース８０は、タスクサーバ２２と通信し、タスクパフォーマンスを管理する（図１の電子データ信号３０も参照）。
【００２８】
メモリ８４は、予め定められたアクティビティ５８（即ち、タスク）の特定の実行を種々の状態において識別するタスク識別子８８を格納するためのスケジュールキュー（即ち、キュー構造）８６を保持する。スケジュールキュー８６は、これらのタスクのトラッキングおよび管理を容易化する種々の専用の構造物を含む。特に、スケジュールキュー８６は、タスクサーバプロセス４２によって現在実行されているタスクを識別するタスク識別子８８を保持する実行リスト（即ち、要求されたタスクリスト）を含む。スケジュールキュー８６は、タスクサーバプロセス４２による実行準備が整ったタスクを識別するタスク識別子８８を保持するためのレディキュー（例、プールされた、中止可能な、実行準備が整ったタスク）をさらに備える。
【００２９】
スケジュールキュー８６は、現在実行しているタスクに従属し、かつ、現在実行しているタスクが完了するとすぐに実行する準備が整ったタスク識別子８８を保持するための従属キューをさらに備える。分散型ワークフローコントローラ５４の制御ロジック８２は、種々のタスクの従属トラッキングを自動的に行い、それに応じて、従属キューを維持する。
【００３０】
スケジュールキュー８６は、実行準備がまだ整っていないタスク識別子８８、あるいは、実行準備はほぼ整っているが、タスクサーバ２２によって現在実行されているワークフロー６０に属しているタスク識別子８８（例、下位レベルの従属タスク）を保持するための遅延キューをさらに備える。あるタスクについては実行準備がなぜまだ整っていないのかについて適切な理由が存在することを理解すべきである。例えば、特定のタスクに対して「一時停止」ビットが設定されており、遅延キューにそのタスク識別子８８の配置を保証する場合がある。別の例として、タスクに対して明確な遅延が指定されている場合などもある。
【００３１】
いくつかの構成において、スケジュールキュー８６は、単一の包括的なタスクテーブルとして実現され、種々の他のキュー（例、レディキュー、従属キュー、遅延キューなど）は、基本的に、作成時間、ランタイム、エラーが発生しているか、タスクの準備が整っているかあるいは実行中であるか、タスクに優先度の高低があるかなどの基準を用いて、タスクテーブルにリストされたタスクをフィルタリングすることで導出される。さらに、種々のタスクは、優先度や資源配分に基づいてタスク識別子を動的にフィルタリングし、ソーティングすることによって、優先順位を決めることができる。
【００３２】
メモリ８４は、基本的にワークフロー６０によってなされた進捗のトランザクションログあるいはアーカイブであるワークフローデータベース９０をさらに格納する。各タスクが進行するにつれて、制御ロジック８２がワークフローデータベース９０を更新し、タスク進捗を記録する。他のメモリ構造物９２は、メモリ８４のみならず、タスクサーバ動作をトラッキングするサーバテーブル、タスクサーバプロセス動作をトラッキングするプロセステーブルにも格納される。メモリ構造物９２は、システム動作パラメータ、設定情報などの他のデータをさらに備えてもよい。
【００３３】
いくつかの構成において、タスクサーバ２２は、それ自体を起動し、ワークフロー管理サーバ２４にデータ送信を積極的に始める。これらの構成において、タスクサーバ２２は、それ自体をオン／オフにすることで（即ち、あらゆる中央管理ロジックによってではなく）、自動的に簡単に追加／除去される。かかる自己設定動作により、分散ワークフローシステム２０は簡単に管理およびスケールされる。しかしながら、ワークフロー管理サーバ２４は、タスクサーバ２２が一旦作動すると、各タスクサーバ２２を簡単に再設定したり、あるいは、一時停止／再開することができる。
【００３４】
別の構成において、制御ロジック８２は、スケジュールキュー８６を用いてタスクサーバプロセス４２間のタスクの実行を管理することを加えて、タスクサーバ２２上のタスクサーバプロセス４２の展開を制御する。特に、ワークフロー６０を実行するようワークフローシステム２０を準備するため、制御ロジック８２は、設定コマンドを最初に送信し、タスクサーバ２２を起動する（図１の電子データ信号３０も参照）。すなわち、設定された動作パラメータ（メモリ構造物９２を参照）に基づいて、制御ロジック８２は、タスクサーバ２２を動的に追加または除去し、タスクサーバ２２上でタスクサーバプロセス４２を開始することができる。これらの線に沿って、電子データ信号３０（図１）を介して、制御ロジック８２は、各タスクサーバ２２上で実行すべきタスクサーバプロセス４２の数を命じる。
【００３５】
タスクサーバプロセス４２がタスクサーバ２２上で開始されると、そのタスクサーバプロセス４２は、タスクの実行準備が整っているため、ワークフロー管理サーバ４２（図１）と通信し、タスクを要求して実行する。各特定のタスクサーバ２２上で実行しているタスクサーバプロセス４２の数が異なり得ることに留意されたい。
【００３６】
次に、制御ロジック８２は、記憶装置５２から実行されるワークフロー６０を読み込み、スケジュールキュー８６を管理する（図２）。ワークフローの進捗を完了するため、制御ロジック８２は、予め定められたアクティビティ５８がワークフロー６０内で互いにどのように関連しているかに基づいて、タスク識別子８８をスケジュールキュー８６に配置する。
【００３７】
その後、タスクサーバプロセス４２は、スケジュールキュー８６（即ち、レディキュー）からタスク識別子８８を要求し、要求されたタスク識別子８８によって識別されたタスクを実行する。スケジュールキュー８６からタスクを要求する基準としては、ワークフロー６０の性質や必須要件に応じて、開始時間が最も早い、優先度が最も高い、作成時間が最も早いなどのタスクを（タスク識別子８８に基づいて）選択することを含み得る。
【００３８】
上述のように、ワークフロー６０は、メモリ８４内でオブジェクトグラフとして表わされるのが好ましい。システム２０が実行中に、ワークフロー６０のワークフロー定義は動的に変更することができる。これらの線に沿って、メモリ８４内に追加あるいは更新される任意のワークフロー定義は、ワークフロー管理サーバ２４から各タスクサーバ２２にさらに押し出される（図１も参照）。図３Ａ乃至図３Ｄを参照しながら種々のタイプのアクティビティ５８について詳細に説明する。
【００３９】
ワークフロー構造
タスクは、予め定められたアクティビティ５８の特定の実行であることを理解すべきである。タスクは、（例、データベース内のトランザクションとしてデジタル資産動作を記録するデジタル資産管理システムの状況において）データベースに対してトランザクショナルであってもよい。各タスクは、タスクサーバプロセス４２によって実行されるタスク特定ロジック（例、コンパイルされたコード）を含む。タスクがその実行をほぼ完了した（即ち、タスクが、その有用な作業を適切に実行した）場合にのみ、タスクはデータベーストランザクションをコミットし、完了信号（例、図１の電子データ信号３０を参照）に応答して、任意の従属タスクを開始してもよいことを示す。
【００４０】
エラー状態がタスクの部分実行中に発生すると、タスクの結果は、トランザクションはまだコミットされていなければ容易に無効にすることができる。これらの線に沿って、たとえシステム２０内に変更がなされても、ワークフローデータベース９０は、イベントのログを提供し、これによりこれらの変更をロールバックしたり、あるいは変更を行わないようにすることができる。かかる状況において、分散型ワークフローコントローラ５４の制御ロジック８２は、そのタスクを正式に没にし、タスクを定義するアクティビティ５８を満たすために新規タスクをその代わりに再スタートすることができる。
【００４１】
図３Ａ乃至図３Ｄは、ワークフロー６０内で使用することができる異なるタイプのアクティビティ５８を示す。ワークフロー６０は、明確に定められた順番で実行されるアクティビティ５８の階層であることに留意されたい。これらの線に沿って、ワークフロー６０は、流れ図としてユーザに視覚化することができるが、オブジェクトパス（図２のワークフロー６０の絵画図も参照）としてワークフローシステム２０内に表わすことができる。ユーザは、ワークフロー管理サーバ２４のデザイン・コンパイルステージ５０を作動させることのよってワークフロー６０を作成し（図２）、予め定められたアクティビティ５８を一緒にリンクさせる。最終結果は、ワークフローシステム２０上で実行した場合に、タスクサーバ２２を介して作業全体を分散して達成することが可能なワークフロー６０（例、デジタル資産管理システム内でデジタル資産上で実行されたトラッキング動作）である。
【００４２】
図３Ａは、入力を取り込み、その入力を処理し、出力を提供する単純なタイプの予め定められたアクティビティ５８ａを示す。一般に、この単純なタイプのアクティビティ５８ａは、アトミック単位として実行するコードのブロックとして扱われる。この基本型は、他の複合型アクティビティ５８によって用いられる。
【００４３】
図３Ｂは、複数の子アクティビティ１００ａ、１００ｂを含む順次アクティビティ５８ｂを示す。ここで、子アクティビティ１００ａと子アクティビティ１００ｂとは、従属関係によってリンクされ、直列実行される。特に、子アクティビティ１００ｂは、子アクティビティ１００ａの従属（即ち、次の）アクティビティであるため、子アクティビティ１００ａが完了するまでは実行することができない。実行中、アクティビティ５８ｂは、アトミック単位として扱われる。従って、アクティビティ５８ｂをタスクとして実行する場合、そこに含まれている子アクティビティ１００ａ、１００ｂの１つが実行中に失敗すると、アクティビティ５８ｂ全体の実行を行うことはできず（即ち、ロールバックされ）、新規タスクとして再度キューされる。
【００４４】
図３Ｃは、複数の子型アクティビティ１００ｃ、１００ｄを含む並列アクティビティ５８ｃを示す。並列アクティビティ５８ｃにおいて、子アクティビティ１００ｃと子アクティビティ１００ｄとはリンクされ、並列実行される。これらの線に沿って、並列アクティビティ５８ｃは、階層的観点から子アクティビティとしてアクティビティ１００ｃ、１００ｄをリストする。従って、２つの別々のタスクサーバプロセス４２は、子アクティビティ１００ｃと１００ｄとを同時に実行することが可能である。しかしながら、子アクティビティ１００ｃ、１００ｄの１つ（あるいは両方）の実行が実行中に失敗すると、アクティビティ５８ｃ全体の実行は行わず、新規タスクとして再度キューすることができる。
【００４５】
図３Ｄは、ループ（ｗｈｉｌｅ  ｌｏｏｐ）機能のコードブランチを定義する子アクティビティ１００ｅ（あるいは、子アクティビティのグループ）を含みながらのＷｈｉｌｅアクティビティ５８ｄを示す。ここで、アクティビティ５８ｄは、長時間にわたって連続的なループで実行することが可能である。
【００４６】
図３Ａ乃至図３Ｄは、ワークフローシステム６０で使用するのに適した、予め定められたアクティビティ５８の基本型および複合型の構造を示していることを理解すべきである。上述した種々のアクティビティ型の１つ以上を含むカスタム構造などの他の構造も使用するのに適している。例えば、特定のカスタムアクティビティ５８は、少なくとも１つの子順次アクティビティ５８ｂと、少なくとも１つの子並列アクティビティ５８ｃと、少なくとも１つの子Ｗｈｉｌｅアクティビティ５８ｄとを含み得る。他の組み合わせも用いられる。図４を参照しながらさらなる詳細について説明する。
【００４７】
ランタイム動作
図４は、分散型ワークフローコントローラ５４（図２）によって管理されるタスクで使用するのに適した状態図１１０を示す。種々のタスク状態は、「作成済み」状態、「閉鎖」状態、「実行可能」状態、「実行中」状態、「完了」状態、「無効」状態、「キャンセル」状態、および「失敗」状態を含む。他の状態も使用するのに適当である。
【００４８】
分散型ワークフローコントローラ５４によってタスクを最初にインスタンシエートすると、タスクは作成済み状態になる。図４に示すように、作成済み状態のタスクを無効状態、実行可能状態、または閉鎖状態にすることができる。無効タスクは、分散型ワークフローコントローラ５４によって一時的に停止されるものである。実行可能タスクは、タスクサーバプロセス４２によって実行する準備が整ったものである。
【００４９】
閉鎖タスクは、実行可能状態にほぼ到達しようとしているものである。これらの線に沿って、閉鎖タスクは、まだ完了していないが実行準備が整っている別のタスクに従属してもよいし、使用可能になるために「制限あるリソース」を待っていてもよい。いくつかの構成において、システム２０は、特定のリソースと、これらのリソースに対して実行可能なタスクの最大数とを定義することができる。例えば、いくつかのタスクはプリンタを使用する必要があるが、システム２０は、これらのプリンタタスクの１つ以上を一度に実行できないように構成することができる。この例では、これらのプリンタタスクの２つを同時に実行することはできず、これらのプリンタタスクの２つ以上を実行する資格がある場合、これらのタスクの１つ以外は全て「閉鎖」状態になる。
【００５０】
実行中タスクは、タスクサーバ２２上で現在実行しているものである。実行中状態のタスクは、キャンセル、完了、あるいは失敗することができる。キャンセルタスクは、分散型ワークフローコントローラ５４によって、恐らくユーザコマンドにより意図的に停止されるものである。失敗タスクは、フォールトに遭遇しているもの、例えば、恐らく、ストールしたり、暴走状態に入ったり、あるいはタイムアウトしたタスクである。完了タスクは、正しく終了したタスク、予め定められた時間制限および／またはデータ処理時間制限内にできる限り多くの作業を完了したタスク、実行待機中の１つ以上の従属タスクを恐らく有するタスクである。
【００５１】
分散型ワークフローコントローラ５４の制御ロジック８２は、スケジュールキュー８６の種々の部分間のタスクを識別するタスク識別子８８を移動することによって（あるいは、スケジュールキュー８６のフィールドを更新することによって）、タスクを調整することを理解すべきである。例えば、実行中タスクは、スケジュールキュー８６の実行リスト上にある。さらに、実行可能タスクはレディキュー上にあり、閉鎖タスクは従属キュー（即ち、識別された従属キュータスクは、識別されたタスクに従属する先のタスクが完了次第、実行準備が整っている）あるいは遅延キューのいずれかのキュー上にある。タスクが完了すると、制御ロジック８２は、従属キューからレディキューへ即時従属するものを識別するタスク識別子８８を移動する。
【００５２】
タスクサーバプロセス４２（図１）がワークフローアクティビティ５８の実行に利用できるようになると、タスクサーバプロセス４２は、タスクを要求し、スケジュールキュー８６のレディキューに現在あるタスク識別子８８に基づいて、分散型ワークフローコントローラ５４から実行する。タスクサーバプロセス４２が特定のタスクを要求すると、タスクサーバプロセス４２は、そのタスクを定義するワークフローアクティビティ５８のタスク特定ロジックを実行する。楽観的ロック技術を用いて、タスクを同時に要求しようとしている複数のサーバに関する競合状態を最適かつ確実に解決することができる。特定のタスクを完了するため、タスクサーバプロセス４２は、トランザクションをワークフローデータベース９０に入力し、タスクの完了を記録する。従って、制御ロジック８２は、ワークフローパフォーマンスの制御および監視を効果的かつ効率的に行うことができる。
【００５３】
ワークフローデータベース９０は、ツール５６（図１）によって問い合わせられるため、ステータスおよびパフォーマンス統計をユーザに提供することができることを理解すべきである。例えば、監視ツールは、ワークフローパフォーマンス中に進捗するにつれて、ワークフローシステム２０のオペレーションのリアルタイムステータスを提供することができる。さらに、報告ツールは、ワークフロー完了のログまたはトランザクション履歴をユーザに提供することができる。さらに、統計ツールは、レポートを生成することができ、それにより、ユーザは、パフォーマンスを分析し、ワークフローシステム２０の特定の態様を動的に調整もしくは微調整することができる。例えば、ユーザは、オンザフライの各タスクサーバ２２上で実行するタスクサーバプロセス４２の数を変更する（即ち、プロセス４２を開始もしくは停止する）ことができ、システム２０のロードバランス態様を動的に変更することができる。図５を参照しながらさらなる詳細について説明する。
【００５４】
ハートビート動作
図５は、タスクサーバ２２上で実行しているタスクサーバプロセス４２のオペレーションを監視するために分散型ワークフローコントローラ５４の制御ロジック８２によって維持されるプロセステーブル１２０を示す（図２の追加のメモリ構造物９２も参照）。示すように、プロセステーブル１２０は、タスクサーバ２２上で実行しているタスクサーバプロセス４２（図１も参照）に対応するタスクサーバプロセスエントリー１２２（１）、１２２（２）、…（集合的に、エントリー１２２）を含む。
【００５５】
各タスクサーバプロセスエントリー１２２は、タスクサーバプロセス識別子１２４と、最終ピングタイムデータ１２６と、ＣＰＵ使用率データ１２８と、タスクカウントデータ１３０と、フリーメモリデータ１３２と、追加の情報１３４（例、有効フラッグ、優先度など）とを含む。タスクサーバプロセス識別子１２４は、特定のタスクサーバ２２上で実行している特定のタスクサーバプロセス４２を識別する（各タスクサーバ２２は、複数のタスクサーバプロセス４２を実行できることに留意されたい）。いつ分散型ワークフローコントローラ５４の制御ロジック８２がそのタスクサーバプロセス４２と最後に通信したかなどの最終ピングタイムデータ１２６は、そのタスクサーバプロセス４２のランタイム態様を識別する。これらの線に沿って、各タスクサーバ２２（あるいは、各タスクサーバプロセス４２）は、ハートビート信号（図１の電子データ信号３０も参照）を定期的に出力し、タスクサーバ２２（もしくはタスクサーバプロセス４２）がまだ動作中であることを示すように構成されている。
【００５６】
ＣＰＵ使用率データ１２８は、現在のＣＰＵ使用率と、タスクサーバプロセス４２に対して測定される最大のＣＰＵ使用率とを示す。タスクカウントデータ１３０は、そのタスクサーバプロセス４２によって現在実行されているタスクのタスク識別子、アクティブタスクカウント、最小タスクカウント、最大タスクカウントなどのタスクカウント統計を示す。フリーメモリデータ１３２は、タスクサーバプロセス４２に利用できる現在フリーなメモリの量を示す。
【００５７】
分散型ワークフローコントローラ５４の制御ロジック８２は、タスクサーバプロセス４２からの通信に応じて、プロセステーブル１２０を連続的に更新することを理解すべきである。異なる予め定められたアクティビティ５８は異なる動作を行うように構成されているため、特定の実行タスクは、他のタスクの比較してより大量の、あるいはより少量のタスクサーバリソースを消費する場合がある。継続的に、制御ロジック８２がプロセステーブル１２０内の情報を更新することで、とりわけ、制御ロジック８２は、任意のタスクサーバプロセスがフォールトに遭遇したかどうかを識別することができる。
【００５８】
さらに、タスクサーバ２２は、他のタスクサーバ２２によって現在実行されているストールされた／非アクティブなタスクをチェックする。特定のタスクサーバ２２が別のタスクサーバ２２上でストールまたは非アクティブタスクを発見すると、特定のタスクサーバ２２は、分散型ワークフローコントローラ５４の制御ロジック８２（図２）にこの発見についての信号を送り、そのタスクを引き継ぐためにタスクサーバ２２自体を利用できるようにする。
【００５９】
制御ロジック２２の上述の応答動作の代わりに、または該動作に加えて、制御ロジック８２は、プロセステーブル１２０内のデータを定期的にスキャンし、ストールしたり、暴走したり、異常終了したりしたタスクを識別する。いくつかの構成において、制御ロジック８２は、プロセスエントリー１２２を更新する際に、特定のタスクサーバ２２のタスクサーバプロセス４２をチェックする。かかるチェック中、制御ロジック８２は、タスクサーバプロセスエントリー１２２内のデータを分析し、任意のタスクが失敗したか検出する。
【００６０】
制御ロジック８２が失敗タスクを発見すると、制御ロジック８２は、タスクカウントデータ１３０内に現在あるそのタスクのタスク識別子をキルリストに移動させる（図２のスケジュールキュー８６も参照）。その後、定期的に（例、ハートビート信号が１分ごとに１回起こるならば、５分ごとに１回のハートビート信号の後）、制御ロジック８２は、キルリスト上のタスクをキルし、スケジュールキュー８６内のその場所に新規タスクを追加する。
【００６１】
部分的に完了したタスクをキルし、新規タスクとして再度キューすると、制御ロジック８２は、部分的に完了したタスクによって実行されたトランザクションを無効にしたり、あるいは、ロールバックする必要があることを理解すべきである。このために、制御ロジック８２は、コミットされていないトランザクションを無効にしたり、あるいは、ワークフローデータベース９０内の記録に基づいて、完了したトランザクションをロールバックもしくは非処理（ｕｎｄｕｅ）とすることができる。かかる動作により、各タスクのアトミック挙動が保たれる。
【００６２】
システム２０は、タスクサーバ２２全体の失敗を処理したりすることができる、即ち、タスクサーバ２２はそれ自体をストール／ダイできることをさらに理解すべきである。かかる状況において、残ったタスクサーバ２２は、強固でフォールトトレランスな動作のために失敗タスクサーバ２２上で実行していた全ての未完了タスクを再要求する。
【００６３】
結論
図６は、ワークフロー６０を実行するために、ワークフロー管理サーバ２４の分散型ワークフローコントローラ５４（図１）によって実行される方法１５０のフローチャートである。ステップ１５２で、分散型ワークフローコントローラ５４は、タスクサーバ２２上でタスクサーバプロセス４２を開始する。各タスクサーバ２２は、１つ以上のタスクサーバプロセス４２をローカルで実行するように構成かつ配置されているオペレーティングシステムを提供することに留意されたい。ワークフローコントローラ５４は、随時、実行中タスクサーバプロセス４２の数を動的に増減できることを理解すべきである。
【００６４】
ステップ１５４で、分散型ワークフローコントローラ５４は、記憶装置５２からワークフロー６０にアクセスする（図１）。これらの線に沿って、ワークフロー６０は、一連の従属関係が予め定められたアクティビティ５８を含み、分散型ワークフローコントローラ５４は、これらのアクティビティ５８を読み込み、該アクティビティ５８のタスク識別子８８を作成することができる。
【００６５】
ステップ１５６で、分散型ワークフローコントローラ５４は、タスク識別子８８をスケジュールキュー８６に配置する（図２）。タスク識別子８８がスケジュールキュー８６のレディキューに移動すると、タスクサーバ２２上で実行しているタスクサーバプロセス４２は、レディキューからタスク識別子８８を要求し実行した後、タスクを分散して実行することができる。
【００６６】
この時点で、ワークフローシステム２０は容易にスケールが可能であることを理解すべきである。特に、システム２０のスループットを向上させるために、１つ以上のタスクサーバプロセス４２、および／または、１つ以上のタスクサーバ２２をシステム２０に追加することができる。タスクサーバプロセス４２が配置されると、タスクは、タスクサーバプロセス４２がレディキューからタスクを要求し実行すると、タスクサーバプロセス４２にわたってロードバランスを自動的に行う。
【００６７】
さらに、ワークフローシステム２０は、組込み式（ｂｕｉｌｔ−ｉｎ）のフォールトトレランスを有することを理解すべきである。特に、タスクがフォールトに遭遇すると、それをキルし、新規タスクとして再スタートすることができる。さらに、他のタスクサーバ２２やタスクサーバプロセス４２を利用できる限り、システム２０は、タスクサーバプロセス４２全体もしくはタスクサーバ２２全体の損失に耐えながら、残ったタスクサーバ２２やタスクサーバプロセス４２を用いてワークフロー６０を完了することができる。
【００６８】
さらに、ワークフローシステム２０は、柔軟かつユーザフレンドリであることを理解すべきである。これらの線に沿って、ワークフロー６０、および／または、アクティビティ５８に優先度を割り当て、システム２０のオペレーションを微調整することができる。さらに、システム２０上で２つ以上のワークフロー６０をどの時点においても実行することができ、システム動作中にワークフロー６０を動的に追加することができる。
【００６９】
上述のように、改良された技術は、タスクサーバプロセス４２をローカルで実行するオペレーティングシステム４０を備えた複数のタスクサーバ２２を利用する。タスクサーバ２２上で実行しているこれらのタスクサーバプロセス４２は、実行準備が整ったワークフロータスクのキューからワークフロータスク（即ち、アクティビティ５８のインスタンシエーション）を要求する。タスクサーバプロセス４２がタスクを完了すると、タスクサーバプロセス４２は、キューから新規タスクを要求する。その結果、タスクサーバプロセス４２は、自然かつ効果的にロードバランスを達成する。さらに、部分的に実行されたタスクが失敗したり、あるいは不適切にストールすると、ワークフロー管理サーバ２４は、この状況を検出し、そのタスクの任意のトランザクションをロールバックした後、タスクを再度キューする、即ち、全てのトランザクションを無事に完了できる新規タスクをキューすることができる。
【００７０】
本発明の種々の実施形態について具体的に示し、説明してきたが、添付された特許請求の範囲に記載されている本発明の精神および範囲から逸脱せずに形態および詳細において種々の変更が可能であることが当業者には理解されるであろう。
【００７１】
例えば、ワークフローシステム２０は、単なる例としてデジタル資産管理システムの一部として動作するように説明したことを理解すべきである。他の利用もワークフローシステム２０に適当である。これらの線に沿って、ワークフローシステム２０は、基本的に、製品アグノスティックなコアエンジンとして利用できる。従って、ワークフロー６０に適当な任意のタイプの作業をこの製品アグノスティックなコアエンジンで利用することができる。
【００７２】
さらに、タスクサーバ２２は、物理マシンまたは仮想マシンのいずれかとして実現することができる。タスクサーバ２２が仮想マシンとして実現されると、タスクサーバ２２は、ワークフローランタイム中に異なるホスト装置にわたって再配置するため、ワークフローシステム２０のオペレーションにさらなる柔軟性を加えることができる。かかる変更や改善は、本発明の種々の実施形態に属するものである。
【図１】
2011123881.tif 000003
【図２】
2011123881.tif 000004
【図３Ａ】
2011123881.tif 000005
【図３Ｂ】
2011123881.tif 000006
【図３Ｃ】
2011123881.tif 000007
【図３Ｄ】
2011123881.tif 000008
【図４】
2011123881.tif 000009
【図５】
2011123881.tif 000010
【図６】
2011123881.tif 000011
【外国語明細書】
2011123881000001.pdf