(57)【要約】  アクティビティの実行を宣言的に取り消すこと。アクティビティの状態オートマトンを定義し、該状態オートマトンは、実行状態、取り消し状態、および閉状態を含み、アクティビティの実行時間を分類する。アクティビティは、ワークアイテムを含み、該ワークアイテムを実行階層構造内に編成する。ワークアイテムは、実行状態から、アクティビティの各ワークアイテムの実行が完了したことを示す閉状態に遷移される。ワークアイテムの１つが閉状態に遷移されると、現在実行状態にあるワークアイテムに取り消し要求が送信される。実行中のワークアイテムは、送信された取り消し要求の関数、および定義されたアクティビティの実行階層構造として識別される。アクティビティの実行時間は、識別されたワークアイテムを実行状態から取り消し状態に遷移することによって取り消される。
2009532759.tif 000002
【特許請求の範囲】
【請求項１】
プロセス中心プログラムのアクティビティ（４０６）を宣言的に取り消す方法であって、
前記アクティビティ（４０６）に関する状態オートマトン（６００）を定義することであって、前記状態オートマトン（６００）が実行状態（６０４）と、取り消し状態（６０６）と、閉状態（６１２）とを含み、前記状態オートマトン（６００）が前記アクティビティ（４０６）の実行時間を分類することと、
複数のワークアイテム（４２２）を含むように前記アクティビティ（４０６）を定義することであって、定義された前記アクティビティ（４０６）が前記複数のワークアイテム（４２２）を実行階層構造（５００）内に編成し、前記ワークアイテム（４２２）の各々が前記アクティビティ（４０６）の一部分を実行する方法を含むことと、
前記複数のワークアイテム（４２２）を、前記実行状態（６０４）から、前記アクティビティ（４０６）の実行の完了を示す前記閉状態（６１２）に遷移させることと、
前記ワークアイテム（４２２）の１つが前記閉状態（６１２）に遷移されると、現在前記実行状態（６０４）にある前記ワークアイテム（４２２）の１つまたは複数に取り消し要求（７２２）を送信することと、
前記実行状態（６０４）にある１つまたは複数のワークアイテム（４２２）を、前記送信された取り消し要求（７２２）の関数、および定義された前記アクティビティ（４０６）の前記実行階層構造（５００）として識別することと、
１つまたは複数の識別された前記ワークアイテム（４２２）を前記実行状態（６０４）から前記取り消し状態（６０６）に遷移させることによって、前記アクティビティ（４０６）の前記実行時間を取り消すことと
を含むことを特徴とする方法。
【請求項２】
前記アクティビティ（４０６）の前記実行時間を取り消すことに応答して、１つまたは複数の識別された前記ワークアイテム（４２２）を、前記取り消し状態（６０６）から前記閉状態（６１２）に遷移させることをさらに含むことを特徴とする、請求項１に記載の方法。
【請求項３】
前記アクティビティ（４０６）の前記実行時間を取り消すことに応答して、取り消し後のオペレーションの集合をユーザ（４３０）に提供することをさらに含むことを特徴とする、請求項１に記載の方法。
【請求項４】
前記１つまたは複数のワークアイテム（４２２）を識別することは、前記ワークアイテム（４２２）をスケジューラキュー（７１４）にエンキューすることを含むことを特徴とする、請求項１に記載の方法。
【請求項５】
取り消すことは、前記ワークアイテム（４２２）を前記スケジューラキュー（７１４）から前記取り消し状態（６０６）にデキューすることを含むことを特徴とする、請求項４に記載の方法。
【請求項６】
前記実行階層構造（５００）は、ツリー構造を含み、前記１つまたは複数のワークアイテム（４２２）を識別することは、前記ツリー構造の下位レベルから前記ツリー構造の上位レベルまで前記ツリー構造をトラバースすることによって、前記実行状態にある前記１つまたは複数のワークアイテム（４２２）を識別することを含むことを特徴とする、請求項１に記載の方法。
【請求項７】
１つまたは複数のコンピュータ読み取り可能な媒体は、請求項１の方法を実行するコンピュータ実行可能命令を有することを特徴とする、請求項１に記載の方法。
【請求項８】
プロセス中心プログラムのアクティビティ（４０６）を宣言的に取り消すシステム（４００）であって、
実行シーケンス（５００）内のワークアイテム（４２２）を編成している前記アクティビティ（４０６）の前記ワークアイテム（４２２）に関連付けられたデータを格納するメモリ領域（４０４）と、
前記アクティビティ（４０６）の状態オートマトン（６００）を定義することであって、前記状態オートマトン（６００）が実行状態（６０４）と、取り消し状態（６０６）と、閉状態（６１２）とを含み、前記状態オートマトン（６００）が前記アクティビティ（４０６）の実行時間を分類することと、
前記ワークアイテム（４２２）を含むように前記アクティビティ（４０６）を定義することと、
前記ワークアイテム（４２２）を、前記実行状態（６０４）から、前記アクティビティ（４０６）の実行の完了を示す前記閉状態（６１２）に遷移させることと、
前記ワークアイテム（４２２）の１つが前記閉状態（６１２）に遷移されると、現在前記実行状態（６０４）にある前記ワークアイテム（４２２）の１つまたは複数に取り消し要求（７２２）を送信することと、
前記実行状態（６０４）にある１つまたは複数のワークアイテム（４２２）を、送信された前記取り消し要求（７２２）の関数、および定義された前記アクティビティ（４０６）の前記実行シーケンス（５００）として識別することと、
前記１つまたは複数の識別されたワークアイテム（４２２）を前記実行状態（６０４）から前記取り消し状態（６０６）に遷移させることによって、前記アクティビティ（４０６）の前記実行時間を取り消すことと
に関するコンピュータ実行可能命令を実行するように構成されたプロセッサ（４０２）と
を備えることを特徴とするシステム。
【請求項９】
前記アクティビティ（４０６）の取り消された前記実行時間に応答して、１つまたは複数の識別された前記ワークアイテム（４２２）を、前記取り消し状態（６０６）から前記閉状態（６１２）に遷移させる手段をさらに含むことを特徴とする、請求項８に記載のシステム（４００）。
【請求項１０】
前記アクティビティ（４０６）の前記実行時間を取り消すことに応答して、取り消し後のオペレーションの集合をユーザ（４３０）に提供する手段をさらに含むことを特徴とする、請求項８に記載のシステム（４００）。
【請求項１１】
前記プロセッサ（４０２）は、前記１つまたは複数のワークアイテム（４２２）を識別することが、前記ワークアイテム（４２２）を前記メモリ領域（４０４）内のスケジューラキュー（７１４）にエンキューすることを含むように構成されることを特徴とする、請求項８に記載のシステム（４００）。
【請求項１２】
前記プロセッサ（４０２）は、前記アクティビティ（４０６）の取り消された前記実行時間に応答して、前記ワークアイテム（４２２）を前記スケジューラキュー（７１４）から前記取り消し状態（６０６）にデキューするように構成されることを特徴とする、請求項１１に記載のシステム（４００）。
【請求項１３】
前記実行シーケンス（５００）は、ツリー構造を含み、前記プロセッサ（４０２）は、前記ツリー構造の下位レベルから前記ツリー構造の上位レベルまで前記ツリー構造をトラバースすることによって、前記１つまたは複数のワークアイテム（４２２）を識別するように構成されることを特徴とする、請求項８に記載のシステム（４００）。
【請求項１４】
前記ワークアイテム（４２２）に関連付けられたデータを、前記アクティビティ（４０６）の取り消された前記実行時間の関数として前記メモリ領域（４０４）から除去する手段をさらに含むことを特徴とする、請求項８に記載のシステム（４００）。
【請求項１５】
プロセス中心プログラムのアクティビティ（４０６）を宣言的に取り消すためのコンピュータ実行可能なコンポーネントを有する１つまたは複数のコンピュータ読み取り可能な媒体（９００）であって、前記コンピュータ実行可能なコンポーネントが、
前記アクティビティ（４０６）の状態オートマトン（６００）を定義する状態マシン（９０２）であって、前記状態オートマトン（６００）が実行状態（６０４）と、取り消し状態（６０６）と、閉状態（６１２）とを含み、前記状態オートマトン（６００）が前記アクティビティ（４２２）の実行時間を分類する、状態マシンと、
前記複数のワークアイテム（４２２）を含むように前記アクティビティ（４０６）を定義するアクティビティコンポーネント（９０４）であって、定義された前記アクティビティ（４０６）が前記複数のワークアイテム（４２２）を実行シーケンス（５００）に編成し、前記ワークアイテム（４２２）の各々が前記アクティビティ（４０６）の一部分を実行する方法を含む、アクティビティコンポーネントと、
前記ワークアイテム（４２２）を、前記実行状態（６０４）から、前記アクティビティ（４０６）の実行の完了を示す前記閉状態（６１２）に遷移させるスケジューラコンポーネント（９０６）と、
前記ワークアイテム（４２２）の１つが前記閉状態（６１２）に遷移されていることに応答して、取り消し要求（７２２）を現在前記実行状態（６０４）にある前記ワークアイテム（４２２）の１つまたは複数に送信するメッセージコンポーネント（９０８）と、
識別されるワークアイテム（４２２）をキュー（７１４）にエンキューすることによって、前記実行状態（６０４）にある１つまたは複数のワークアイテム（４２２）を、送信された前記取り消し要求（７２２）の関数、および前記定義されたアクティビティの前記実行シーケンス（５００）として識別する取り消しハンドラ（９１０）と、
１つまたは複数の識別された前記ワークアイテム（４２２）を、前記実行状態（６０４）から前記取り消し状態（６０６）に遷移させることによって、前記アクティビティ（４０６）の前記実行時間を取り消す実行コンポーネント（９１２）と
を含むことを特徴とする、１つまたは複数のコンピュータ読み取り可能な媒体。
【請求項１６】
前記スケジューラコンポーネント（９０６）は、１つまたは複数の識別された前記ワークアイテム（４２２）を、前記取り消し状態（６０６）から前記閉状態（６１２）に遷移させるように構成されることを特徴とする、請求項１５に記載のコンピュータ読み取り可能な媒体（９００）。
【請求項１７】
前記アクティビティ（４０６）の前記実行時間を取り消すことに応答して、取り消し後のオペレーションの集合をユーザ（４３０）に提供するユーザインタフェース（ＵＩ）（４２８）をさらに含むことを特徴とする、請求項１５に記載のコンピュータ読み取り可能な媒体（９００）。
【請求項１８】
前記取り消しハンドラ（９１０）は、前記ワークアイテム（４０６）を前記キュー（７１４）から前記取り消し状態（６０６）にデキューするように構成されることを特徴とする、請求項１５に記載のコンピュータ読み取り可能な媒体（９００）。
【請求項１９】
前記実行シーケンス（５００）は、ツリー構造を含み、前記取り消しハンドラ（９１０）は、前記ツリー構造の下位レベルから前記ツリー構造の上位レベルまで前記ツリー構造をトラバースすることによって、前記１つまたは複数のワークアイテム（４２２）を識別するように構成されることを特徴とする、請求項１５に記載のコンピュータ読み取り可能な媒体（９００）。
【請求項２０】
前記ワークアイテム（４２２）の実行に関連付けられたデータを、前記実行コンポーネント（９１０）による前記アクティビティ（４０６）の実行時間の取り消しの関数として除去するクリーニングコンポーネント（９１２）をさらに含むことを特徴とする、請求項１５に記載のコンピュータ読み取り可能な媒体（９００）。
【発明の詳細な説明】
【背景技術】
【０００１】
プロセス指向プログラム（process-oriented program）またはプロセス中心プログラム（process-centric program）が発展し、自律エージェント間の実世界のやりとりをモデル化する複雑な命令の処理が可能となっている。プロセス中心プログラムは、実世界のプロセスをミラーリングし、実世界のエンティティ間のやりとりをミラーリングする。既存のシステムは、ビジネス上の問題をモデル化することにより、ビジネス上の問題を高レベルのワークフローにマッピングすることを試みる。しかし、実世界のワークフローは、（ａ）実行およびモデル化の複雑性、（ｂ）設計時におけるフロー構造に関する知識、（ｃ）静的に定義されたかまたはアドホック／動的であること、（ｄ）ライフサイクルの様々な時点におけるフローのオーサリングおよび編集の容易性、および（ｅ）ビジネスロジックとコアワークフロープロセスとの弱い関連性または強い関連性、などのさまざまな側面において異なる。既存のモデルでは、これらすべての要因に対応することはできない。
【０００２】
また、ほとんどの既存のワークフローモデルは、言語ベースのアプローチ（例えば、ＢＰＥＬ４ＷＳ、ＸＬＡＮＧ／Ｓ、およびＷＳＦＬ）またはアプリケーションベースのアプローチに基づいている。言語ベースのアプローチは、予め定義された構文の閉集合（closed set）を有する高レベルのワークフロー言語であり、これはワークフロープロセスをユーザ／プログラマに対してモデル化するのに役立つ。ワークフロー言語は、構文の閉集合に関する意味情報（semantic information）の全てを有し、ユーザがワークフローモデルを構築することが可能となる。しかし、言語は、開発者側では拡張することができず、ワークフローモデルを構成するプリミティブの閉集合を表している。言語は、ワークフローシステムのベンダによって出荷される言語コンパイラに結び付けられている。ワークフローシステム製品のベンダのみが、製品の将来のバージョンで構文の新しい集合を用いて言語を拡張することによってモデルを拡張することができる。このことは、言語に関連付けられたコンパイラのアップグレードを必要とすることがしばしばある。さらに、言語は通常、他のプログラムが容易かつ効果的に使用することができる関数またはオペレーションを、宣言的に公開または定義しない。
【０００３】
アプリケーションベースのアプローチは、アプリケーション内にドメイン特有の問題を解決するワークフロー機能を有するアプリケーションである。これらのアプリケーションは、正確には拡張可能ではなく、プログラム可能なモデルも有しない。
【０００４】
さらに、既存のアプローチでは、複雑性、予知（foreknowledge）、動的ワークフロー、オーサリングの容易性、およびビジネスロジックとコアワークフローとの関連性の強さに関する課題が適切に対処されない。異なるクラスのワークフローをモデル化するビジュアルワークフロー設計機能（visual workflow designer）を構築するのに利用可能である、拡張可能かつカスタマイズ可能かつ再ホスト可能なワークフロー設計機能のフレームワークは存在しない。既存のシステムは、ユーザが、ワークフロープロセスを図式的に設計することを可能にし、かつ開発者の選択によるプログラミング言語のビジネスロジックを関連付けることを可能にする、ＲＡＤ（rapid application development）スタイルのワークフロー設計の経験がない。
【０００５】
また、ワークフロープロセスは、ワークフロープロセスモデルの複数のステップに及ぶ、分野横断的に直交し絡み合った問題を取り扱う。例えば、ワークフロープロセスの一部分は、長い実行トランザクションに参加するように設計されているが、同じプロセスの他の部分は、同時実行のためまたは共有リソースにアクセスするために設計されている。設計上の欠陥のため、既存のシステムでは、ユーザがアクティビティの同期実行またはインターリーブ実行を設計できるようにする実行スレッドのインターリーブを提供することができない。同じワークフロープロセスのさらに他の部分では追跡を必要とするが、他の部分ではビジネスまたはアプリケーションレベルの例外を扱う。特定の振舞いをワークフロープロセスの１つまたは複数の部分に適用する必要がある。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
一部のワークフローモデル化アプローチは、全ての例外および人間介入を含むビジネスプロセス全体の完全なフローベースの記述を必要とするので、実用的ではない。これらのアプローチの一部は、例外が発生するときの追加機能を提供するが、他のアプローチは、ビジネスプロセスをモデル化するフローベースのアプローチの代わりに制約ベースのアプローチのみを採用する。既存のシステムでは、フローベースまたは制約ベースのアプローチのいずれかを実装する。このようなシステムは、柔軟性が低すぎて、多くの一般的なビジネス状況をモデル化することができない。これらのシステムは、例外処理（exception）および取り消し（cancellation）を非同期的に扱う機能も欠けている。
【課題を解決するための手段】
【０００７】
本発明の実施形態は、状態オートマトンにおける取り消し状態（canceling state）を定義することにより、プログラム内の取り消しをモデル化する宣言フレームワーク（declarative framework）を提供する。さらに、取り消し状態および本発明の他の態様を、開発者またはプログラムが宣言的に定義することができ、プログラムの取り消し処理においてユーザに提供することができる。
【０００８】
さらに、本発明の実施形態は、複合アクティビティ（composite activity）（例えば、階層構造を有するアクティビティのグループ）が、１つまたは複数のアクティビティ（例えば、アクティビティツリー内の子アクティビティ）の実行を取り消すことを可能にする。また、取り消しを具現化する本発明の態様により、プログラムおよび動的制御フロー内における早期完了のモデル化が可能となる。
【０００９】
この要約は、以下の「発明を実施するための最良の形態」においてより詳細に説明される概念の選択を、簡略化した形式で説明するために提供される。この要約は、特許請求される主題の重要な特徴または本質的な特徴を特定するようには意図されておらず、特許請求される主題の範囲を定める助けとして使用されるようにも意図されていない。
【００１０】
他の特徴は、一部は明らかであり、一部は以下において指摘されることになる。
【００１１】
対応する参照記号は、図面全体を通して対応する部分を示す。
【発明を実施するための最良の形態】
【００１２】
初めに図１を参照すると、ブロック図は、ワークフローなど、プロセス中心のアクティビティのプログラムを設計するための既存のプログラミングパラダイムを図示する。例えば、この図は、既存のプログラムパラダイムの３つのレベルの仮想化モデルを示しており、レベルは、マネージド実行環境（managed execution environment）が最上位レベルであり、処理ユニットが最下位レベルである。このプログラミング設計システムでは、マネージド実行環境レベルであっても、プログラム、特にワークフロープロセスを扱うプロセス中心プログラムは、ワークフロー内のプロセス間の複雑なやりとりに対応する能力および効率が欠けている。
【００１３】
当業者には公知であるように、ソフトウェアまたはアプリケーションプログラムの設計には何らかの制約が関連する。この例では、オペーレーティングシステムのソフトウェアプログラム１０４を書く際に、プログラミングコードまたはルーチンは、コンピューティングアーキテクチャ（例えば、ＩＢＭ（登録商標）準拠、ＡＰＰＬＥ（登録商標）コンピュータ、または他のシステム）のタイプに特有な処理ユニット１０２のタイプもしくは構成、または他の制約に依存する。さらに、プログラミング言語は典型的に、スタック、ヒープ、スレッドベース、または他のハードウェア特有の構造など、オペーレーティングシステム１０４が適切に機能するためのデータ構造を正確に識別して利用することが必要である。
【００１４】
複雑なワークフロープロセスを扱う場合、既存のアプリケーションは、あるプログラミング言語で書かれたプログラムが異なるプログラミング言語で書かれた他のプログラムの関数を呼び出すことができる、マネージド実行環境１０６（例えば、プログラムが関数または共通オブジェクト指向クラスを共有することができるランタイム環境）の概念を使用する。このような実行環境では、異なるプログラミング言語のこれらのプログラムが中間言語にコンパイルされると、マネージド実行環境１０６は、パラメータ、引数、またはスキーマもしくは関数を異なるプログラムに公開することができ、その結果、プログラムは互いにやりとりすることができる。
【００１５】
この実行環境１０６はプログラム間の共通の通信環境を作成するが、実行環境１０６は、プロセス中心プログラムの複雑性および機能を扱うのに適さない可能性のある様々な厳格な要件を含む。例えば、実行環境１０６は、プログラムが特定のファイルフォーマットであると確認されることを必要とする。実行環境１０６は、プログラムの関数またはオペレーションが、実行環境１０６によって定義された関数の固定集合または関数のクラスを使用することを必要とする。
【００１６】
本発明の実施形態は、拡張可能ファウンデーション（extensible foundation）すなわち図２のフレームワーク２０２を構築し、既存のプログラミングモデルの欠点を克服する。プログラムを任意のプログラミング言語で書くこと、および任意のファイルフォーマットで構成することを可能にすることによって、本発明の態様は、プログラム開発者が機能および仕様を落とすことなく特定の関数を有するプログラムを設計することを可能にする。ワークフロータスクまたはプロセスなどのアクティビティをワークフローフレームワークで実行されるベースクラスとして定義することによって、開発者は、既存の実行環境において、厳格かつハードコーディングされた柔軟性のないもの、および関数もしくはアクティビティクラスの固定集合に固執することなく、ドメイン特有の（例えば、医療産業、金融業界などにおけるプログラムなどのような特定の実行環境）オペレーションコード（以下「ｏｐ−コード」と称する）を容易かつ効率的に構築することができる。さらに、本発明の態様を具現化するワークフローファウンデーションは、任意の既存のフレームワーク（例えば、マネージド実行環境、オペーレーティングシステム環境、またはハードウェア処理ユニットレベルのいずれか）の最上部に階層化された継続ベースのランタイム（continuation based runtime）である。
【００１７】
本発明の態様は、任意の様式または表現（例えば、フローチャート、図、番号付の説明など）でワークフローの設計を可能にすることにより、ワークフロー内のアクティビティを該ワークフロー設計の表現から構成することができる限り、特定のファイルフォーマットのアクティビティを定義する際の制約を取り除く。
【００１８】
図３は、本発明の一実施形態にかかるワークフロー３００の簡略な図を示す。例えば、ワークフロー３００は、注文書処理のワークフローとすることができ、この注文書ワークフロー３００は、注文書を受信し、顧客に確認書を送信し、管理者が注文書を承認するなどのプロセスまたはアクティビティを含むことができる。さらに、一部を他と同時に実行し、一方で他の一部を他のアクティビティの完了時のみに実行することができるように、これらのアクティビティを順序付けすることができる。
【００１９】
ワークフロー３００は、開始点３０２から開始することができる。例えば、注文書ワークフローの開始点３０２は、顧客からの注文を受信していることがある。ワークフロー３００は、条件ステートメント３０４（「ＩＦステートメント」または「ＷＨＩＬＥステートメント」など）を含むこともでき、これを、追加の条件ステートメント３０６および３０８にさらに分割することができる。ワークフロー３００は、１つまたは複数のシーケンスまたはアクティビティ３１２をさらに含む並列構造３１０を含むことができる。例えば、並列構造３１０は、在庫リストのチェックおよび利用可能な出荷業者の更新などの、並列に処理されるべきアクティビティを含む。示される例では、「Ｅ−ｍａｉｌを送信（ＳＥＮＤ  Ｅ−ｍａｉｌ）」および「承認を得る（Ｇｅｔ  Ａｐｐｒｏｖａｌ）」などのアクティビティを並列に処理することができる。「アクティビティをここにドロップ」３１６では、ユーザは、さらなるアクティビティをワークフロー３００にさらに追加または補給することができる。ワークフロー３００を完了するために、プロセスまたはアクティビティは、完了ステップまたは完了点３１４で終了することになる。
【００２０】
一実施形態では、アクティビティを、ツリー構造（図５参照）５００または他の実行シーケンスにおいて階層的に配列することができる。例えば、あるアクティビティは、該アクティビティに関連付けられた２つ以上のワークアイテムを含む複合アクティビティとすることができる。アクティビティメソッドは、２つの子ノードまたはリーフノード５０４および５０６を有するルートノード５０２内にあることができる。子ノード５０４および５０６（例えば、それぞれワークアイテム＿１およびワークアイテム＿２）内のアクティビティメソッドを、階層構造に従って実行することができる。さらに、子ノード５０４および５０６は、実行されるべきそれぞれのワークアイテムを有する他の子ノードも含むことができる。
【００２１】
別の実施形態では、アクティビティは、次のタイプの１つまたは複数を含むことができる。すなわち、単純アクティビティ、コンテナアクティビティ、およびルートアクティビティの１つまたは複数を含むことができる。この実施形態では、あるルートアクティビティがモデル内に存在し、単純アクティビティまたはコンテナアクティビティは、該ルートアクティビティ内に全てないか、または全てある。コンテナアクティビティは、単純アクティビティまたはコンテナアクティビティを含むことができる。ワークフロープロセスの全体を、あるアクティビティとして使用して、上位順のワークフロープロセスを構築することができる。さらに、アクティビティは、割り込み可能であっても割り込み不可能であってもよい。割り込み不可能な複合アクティビティは、割り込み可能アクティビティを含まない。割り込み不可能なアクティビティは、アクティビティにブロックさせるサービスが欠けている。
【００２２】
さらに、アクティビティおよびそのアクティビティに含まれるワークアイテムを実行する際、ワークフローフレームワークは、ワークアイテムの各々の範囲または境界である実行コンテキストまたは実行環境を定義する。この範囲または境界は、ワークアイテムによってアクセスされる共有データもしくはリソース、関連するプロパティ、ハンドラ、制約、および自律エージェント間のやりとりなどの情報（例えば、データ、メタデータなどの形式で）を含み、公開する。これらの範囲を階層的に構成することができる。また、各アクティビティを、基礎となるマネージドフレームワークをサポートする任意のプログラミング言語のユーザコードによって、構成することができる。例えば、ユーザコードは、特定のドメインまたは実行環境において書かれた、ビジネスまたはアプリケーションのロジックまたはルールを表すことができる。各アクティビティは、ユーザコードでの実行に対するインターセプト前のフックおよびインターセプト後のフックをサポートすることができる。各アクティビティは、関連するランタイム実行セマンティクスおよび振舞い（例えば、状態管理、トランザクション、イベント処理、および例外処理）を有する。アクティビティは、状態またはリソースを他のアクティビティと共有することができる。さらに、アクティビティは、プリミティブなアクティビティ（primitive activity）とすることができ、または複合アクティビティにグループ化することができる。プリミティブなアクティビティすなわち基本アクティビティ（basic activity）は、サブストラクチャ（例えば、子アクティビティ）を有さず、したがってツリー構造内のリーフノードである。複合アクティビティは、サブストラクチャを含む（例えば、複合アクティビティは、１つまたは複数の子アクティビティの親である）。
【００２３】
図４は、本発明の一実施形態にかかるワークフローアクティビティを処理するシステム４００を示す図である。システム４００は、１つの処理ユニットまたは複数の処理ユニットの集合とすることができるプロセッサ４０２を含む。システム４００は、プロセッサ４０２によりアクセス可能なデータを格納するメモリ領域４０４も含む。一実施形態において、システム４００は、１つまたは複数のプロセッサまたは処理ユニット（例えば、プロセッサ４０２）、および他のコンポーネントを有するシステムメモリ（例えば、メモリ領域４０４）を備えるコンピュータとすることができ、システムメモリを含む様々なシステムコンポーネントをプロセッサ４０２と結合することができる。
【００２４】
一例では、メモリ領域４０４は、コンピュータ読み取り可能な命令、データ構造、プログラムモジュール、または他のデータなどの情報を格納するための任意の方法または技術で実装される、コンピュータ読み取り可能な媒体、または揮発性、不揮発性、リムーバブル、もしくは非リムーバブルな媒体を含むことができる。例えば、コンピュータ記憶媒体には、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリもしくは他のメモリ技術、ＣＤ−ＲＯＭ、ＤＶＤもしくは他の光ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置もしくは他の磁気記憶装置、または所望の情報を格納するのに使用可能でありシステム４００によってアクセス可能な任意の他の媒体が含まれる。メモリ４０４は、コンピュータ読み取り可能な命令、データ構造、プログラムモジュール、または他のデータを、搬送波もしくは他のトランスポートメカニズムなどの変調データ信号で具現化する通信媒体を含むこともでき、任意の情報送達媒体を含む。当業者は、信号内の情報を符号化するなどの方法で設定または変更された１つまたは複数の特性を有する変調データ信号を熟知している。有線ネットワークまたは直接有線接続などの有線媒体、ならびに音響、ＲＦ、赤外線、および他の無線媒体などの無線媒体は、通信媒体の例である。上記の任意の組み合わせも、コンピュータ読み取り可能な媒体の範囲に含まれる。
【００２５】
一例では、メモリ領域４０４は、ワークフロー（例えば、ワークフロー３００）内で処理する複数のアクティビティ４０６を格納する。複数のアクティビティ４０６の各々は、１つまたは複数のワークアイテムを含み、ワークアイテムは、ツリー構造（図５参照）などの階層構造で編成することができる。複数のアクティビティ４０６を処理する場合、プロセッサ４０２は、編成されたアクティビティの集合をセットアップするように構成されるスケジューラ４０８にアクセスするか、または該スケジューラ４０８を実行する。
【００２６】
例えば、プロセッサ４０８は、コンポーネント、またはスケジューラ４０８などのコンピュータ実行可能命令の集合を介して複数のアクティビティ４０６内のワークアイテムにアクセスして、ワークアイテム４２２をキュー４１０にエンキューまたは格納する。プロセッサ４０２によってアクセス可能なディスパッチャ４１２は、実行用ワークアイテム４２２をディスパッチする。例えば、ワークアイテム４２２−１は、アクティビティメソッド４２４、ルーチン、または「ユーザからの入力を要求する（ｒｅｑｕｅｓｔｉｎｇ  ｉｎｐｕｔ  ｆｒｏｍ  ａ  ｕｓｅｒ）」関数を実行するためのコードのコレクションを含んでいてもよい。１つまたは複数の他のアクティビティメソッド、ルーチン、またはコードが、本発明の範囲を逸脱することなく、ワークアイテム４２２の各々に含まれることがある。
【００２７】
ワークアイテム４２２がディスパッチャ４１２によってディスパッチされると、プロセッサ４０２は、４１４で、ワークアイテム４２２内のメソッド４２４の各々を実行する。ワークアイテム４２２−１の例では、プロセッサ４０２は、ユーザに、ユーザインタフェース（ＵＩ）を介して、要求した情報またはデータを入力させることがある。別の実施形態において、プロセッサ４０２は、ユーザからの入力を要求するために、外部データソースに接続またはアクセスすることができる。アクティビティメソッド４２４の完了時に、プロセッサ４０２は、４１６で、ワークアイテム４２２の実行を終了する。一実施形態では、プロセッサ４０２は、４１８で、ワークアイテムの実行状態をデータストア４２０に対して非活性化（passivate）にする。
【００２８】
別の実施形態において、プロセッサ４０２は、図６に示されるオートマトンなどの状態オートマトンに従って、ワークアイテム４２２を実行する。図６は、本発明の実施形態にかかるアクティビティに関連付けられたワークアイテムの処理状態を記述する、例示的な状態オートマトン６００を示す図である。一実施形態において、状態オートマトン６００は、アクティビティの実行時間（execution lifetime）を定義する。一例では、状態オートマトン６００は、（図４に示されるように）初期化状態、実行状態、および閉状態（closed state）を含むことができる。別の実施形態では、状態オートマトン６００は、初期化状態６０２、実行状態６０４、取り消し状態６０６、障害状態（faulting state）６０８、補正状態（compensating state）６１０、および閉状態６１２を含む。
【００２９】
例えば、状態オートマトン６００は、ワークフローアクティビティ内のワークアイテム（例えば、ワークアイテム４２２）の実行のプロセスフローを記述する。ワークアイテム４２２−１は初めに、図４に示されるように、キュー４１０にエンキューされるときに初期化される。ワークアイテム４２２−１は次に、実行状態（例えば、図６の実行状態６０４）において実行される前に、キュー４１０からディスパッチャ４１２へデキューまたは除去される。ワークアイテム４２２−１の実行中のパラメータまたは条件に応じて、ワークアイテム４２２−１は、取り消し状態６０６または障害状態６０８に進むことができる。一実施形態において、ワークアイテム４２２−１は、取り消し状態６０６から障害状態６０８に進むことができる。代替的な実施形態において、補正状態６１０は、障害または例外が発生したときに実行されるべきオペレーションまたは関数の集合を記述する。
【００３０】
例えば、ワークアイテム（例えば、ワークアイテム４２２−１）の実行中に、関数のパラメータが無いなどの例外が発生する場合を想定されたい。システム４００は、ワークアイテム４２２−１を障害状態６０８に遷移させる。その際、システム４００はまた、ワークアイテム４２２−１を閉状態６１２に遷移させる前に、ガーベジコレクションの（例えば、オペレーションの実行済の部分をキャッシュまたはメモリから事前に削除する、パラメータ値をリセットするなどの）オペレーションを、補正状態６１０において実行する。閉状態６１２は、アクティビティ（例えば、図５のアクティビティ５００）の実行が完了したことを示す。
【００３１】
一実施形態において、状態オートマトン６００は、複合アクティビティ内のワークアイテム間の関係（relationship）を確立する。例えば、関係ルールの１つは、閉状態６１２メソッドまたはアクティビティツリーのルートノード内のワークアイテムに遷移する前は、子ノード内の全てのワークアイテムが初期化状態６０２または閉状態６１２でなければならないということを含むことがある。別のルールは、アクティビティツリーの子ノード内のワークアイテムを実行状態６０４に遷移させるために、ルートノード内のワークアイテムは既に実行状態６０４でなければならないことを必要とすることがある。
【００３２】
別の実施形態では、１つまたは複数の追加の状態を、本発明の実施形態の範囲を逸脱することなく、状態オートマトン６００において定義することができる。
【００３３】
次に図７Ａから図７Ｅを参照すると、ブロック図は、本発明の実施形態にかかるアクティビティのワークアイテムの宣言的取り消しを示している。限定ではなく単に簡略化の目的のために、図７Ａは、ツリー構造で編成された３つの子ワークアイテム、すなわちワークアイテム＿１  ７０４、ワークアイテム＿２  ７０６、およびワークアイテム＿３  ７０８を含む、複合アクティビティ７０２を示す。図示されるように、ルートアクティビティ７０２は、「テキストをディスプレイに書き、テキストを書いた後にアクティビティを終了する（ｗｒｉｔｅ  ｔｅｘｔ  ｏｎ  ｄｉｓｐｌａｙ  ａｎｄ  ｔｅｒｍｉｎａｔｅ  ｔｈｅ  ａｃｔｉｖｉｔｙ  ａｆｔｅｒ  ｗｒｉｉｎｇ  ｔｈｅ  ｔｅｘｔ）」というメソッドを含む。上記のワークアイテムの関数により、下記が提供される。  
ワークアイテム＿１  ７０４：
｛  ＰＡＵＳＥ  ３０  ＳＥＣＯＮＤＳ；
ＷＲＩＴＥ  ＴＥＸＴ（“ＨＥＬＬＯ”）；
｝
ワークアイテム＿２  ７０６：
｛  ＷＲＩＴＥ  ＴＥＸＴ（“ＨＥＬＬＯ  ＷＯＲＬＤ”）；
ＰＡＵＳＥ  ６０  ＳＥＣＯＮＤＳ；
｝
ワークアイテム＿３  ７０８：
｛  ＷＲＩＴＥ  ＴＥＸＴ（“ＨＥＬＬＯ  ＭＥＳＳＡＧＥ”）；
ＰＡＵＳＥ  １８０  ＳＥＣＯＮＤＳ；
｝
【００３４】
図７Ｂでは、実行状態７１０のスナップショット（すなわち、ワークアイテムが実行状態７１０になった後の３０秒）は、現在実行状態にあるワークアイテムを図示している。この時点でアクティビティ７０２も既に実行状態７１０にあることは理解されよう。この段階で、ワークアイテム＿１  ７０４に含まれる関数に従って、テキスト「Ｈｅｌｌｏ」が、図４のユーザインタフェース（ＵＩ）４２８などのディスプレイに表示される。
【００３５】
図７Ｃでは、ワークアイテムが実行状態になった後３１秒の時点で、ワークアイテム＿１  ７０４内の関数は、実行（すなわち、「Ｈｅｌｌｏ」をディスプレイに書くこと）を完了している。ワークアイテム＿１  ７０４は閉状態７１２に遷移される。閉状態７１２に遷移すると、取り消し要求７２２が、７２０で、現在実行状態にある１つまたは複数のワークアイテム、例えばワークアイテム＿２  ７０６およびワークアイテム＿３  ７０８などに送信される。
【００３６】
本発明の実施形態によると、アクティビティ７０２が、「テキストをディスプレイに書き、テキストを書いた後にアクティビティを終了する」というメソッドの実行を完了したので、アクティビティツリー内の全ての残りのワークアイテムが、取り消し状態に遷移される。したがって、アクティビティ７０２は、閉状態７１２に遷移される必要がある。このため、現在実行状態７１０にあるオペレーション、関数、またはメソッドが廃棄されることになるか、またはこれらの実行が完了することになる。
【００３７】
したがって、図７Ｄでは、ワークアイテムが実行状態７１０になった後３２秒の時点で、ワークアイテム＿２  ７０６およびワークアイテム＿３  ７０８が、取り消し状態７１６に遷移される。一実施形態において、ワークアイテム＿２  ７０６およびワークアイテム＿３  ７０８が、取り消し状態７１６（例えば、図４の取り消し状態４２６）に遷移する前に、スケジューラキュー７１４にエンキューされる。図７Ｅでは、ワークアイテム＿２  ７０６およびワークアイテム＿３  ７０８が、スケジューラキュー７１４からデキューされ、取り消し状態７１６に遷移されている。この図において、全てのワークアイテムが（矢印７１８で示されるように）閉状態に遷移されると、アクティビティ７０２は、アクティビティ７０２がその実行を完了したことを示す閉状態７１２に遷移する。
【００３８】
例外をトリガする既存のシステムと異なり、本発明の態様は、取り消し状態７１６を提供することによって、宣言的に取り消しをトリガする。取り消し状態７１６を用いて、開発者またはプログラマは、プロセス中心プログラムを設計して、プログラムの一部の取り消しを効率的に扱うことができる。
【００３９】
ワークアイテムを取り消し状態７１６に遷移させる際、本発明の代替実施形態は、アクティビティの実行時間の取り消しに応答して、取り消し後のオペレーションの集合をユーザ４３０に提供する。例えば、図４のシステム４００は、ダイアログウィンドウ内の多数のオペレーションを、ＵＩ４２８を介してユーザ４３０に提供することができる。オペレーションは、これに限定されないが実行状態７１０にある残りのワークアイテムも取り消して他のオペレーションなどを実行する判断記号（decision box）を含むことができる。本発明の代替実施形態は、ワークアイテムの実行と関連付けられたデータ（例えば、一時的な記憶装置、バッファ、メモリアクセスなど）を除去するオペレーションの集合を、アクティビティの実行時間の取り消しの関数として実行することができる。
【００４０】
一実施形態において、図６は、６つの状態（初期化、実行、閉、取り消し、障害および補正状態）を含むオートマトンを表すが、ここで、あるアクティビティ（例えば、そのドメインに特有のｏｐ−コードの集合を定義することができるオペレーションの集合）は、その実行時間中であってもよい。上述のように取り消し機能を組み込むと、実行ハンドラが実際にディスパッチされる前に、ワークアイテムは、スケジューラキューからデキューされる。オートマトン６００は、同様にプリミティブアクティビティおよび複合アクティビティの両方に適用する。
【００４１】
複合アクティビティにより制御フローパターンのモデル化が可能となるように、本発明の実施形態に従って親と子の間の構成関係が強化されることにも留意されたい。
【００４２】
例えば、アクティビティツリーの親アクティビティ内の子の構成は、以下のことを要求する。
【００４３】
（１）親アクティビティを閉状態に遷移させるために、要求される事前条件は、いずれの子も初期化状態または閉状態にあることである。この例では、子アクティビティまたは子ワークアイテムは、親が閉状態に遷移するときは、実行状態、取り消し状態、障害状態または補正状態にないことがある。
【００４４】
（２）子を実行状態に遷移させるために、要求される事前条件は、親がすでに実行状態、取り消し状態、障害状態、補正状態または他の「＜＞している（ｉｎｇ）」状態にあることである。
【００４５】
例示的な実施形態において、ワークフローファウンデーションまたはフレームワークランタイムは、上記のルールまたは要件を厳密に実施する。さらに、ワークフローフレームワークは、上記の記載に基づいてアクティビティを書く人に、取り消しをモデル化するためのより良く定義されたプロトコルを提供する。取り消しは、自身の子の取り消しをスケジューリングする親の複合アクティビティから始まり、次にその子を取り消す、というように、アクティビティの構成の階層の中で下方に伝搬する。この例は、実行信号が構成構造の中で下方へ伝搬する方法と同様である。
【００４６】
取り消しを例外として扱っている既存の技術と異なり、本発明の実施形態は、取り消しを複合アクティビティの通常の実行セマンティクスの特定の振舞いとしてモデル化し、その結果、アクティビティの実行の動的な制御フローが達成される。
【００４７】
図８は、本発明の実施形態にかかる、ワークフローのアクティビティのワークアイテムを取り消す方法を示すフロー図である。一例では、図８に記載される方法またはプロセスを、図９に図示されるコンピュータ読み取り可能な媒体９００などのコンピュータ読み取り可能な媒体に格納されたコンピュータ実行可能なコンポーネントによって実行することができる。例えば、最初に、８０２において状態マシン９０２がアクティビティの状態オートマトンを定義する。状態オートマトン（例えば、状態オートマトン６００）は実行状態、取り消し状態、および閉状態を含む。アクティビティコンポーネント９０４は、８０４において、複数のワークアイテムを含むようにアクティビティを定義する。定義されたアクティビティは、実行シーケンスまたは実行階層構造（例えば、ツリー構造）内で複数のワークアイテムを編成する。ワークアイテムの各々は、アクティビティの一部分を実行する方法を含む。
【００４８】
８０６において、スケジューラコンポーネント９０６は、ワークアイテムを実行状態から閉状態に遷移させる。この閉状態はアクティビティの実行の完了を示す。８０８において、ワークアイテムの１つが閉状態に遷移されていることに応答して、メッセージコンポーネント９０８は、現在実行状態にあるワークアイテムの１つまたは複数に、取り消し要求を送信する。取り消しハンドラ９１０は、８１０において、実行状態にある１つまたは複数のワークアイテムを、送信された取り消し要求の関数、および定義されたアクティビティの実行シーケンスとして識別する。一実施形態において、取り消しハンドラ９１０は、ワークアイテムを取り消し状態に遷移させる前に該ワークアイテムをスケジューラキューにエンキューすることによって、該ワークアイテムを識別する。
【００４９】
８１２において、実行コンポーネント９１２は、１つまたは複数の識別されたワークアイテムを実行状態から取り消し状態に遷移させることによって、アクティビティの実行時間を取り消す。別の実施形態では、コンピュータ読み取り可能な媒体９００には、アクティビティの実行時間の取り消しに応答して取り消し後のオペレーションの集合を図４のユーザ４３０に提供する、ＵＩ（例えば、ＵＩ４２８）も含まれる。さらに別の実施形態では、クリーニングコンポーネント９１４は、ワークアイテムの実行に関連付けられたデータを、実行コンポーネントによるアクティビティの実行時間の取り消しの関数として除去する。
【００５０】
図４のシステム４００などの例示的なコンピューティングシステム環境と関連して説明してきたが、本発明の実施形態は、多くの他の汎用または専用のコンピューティングシステム環境または構成で動作可能である。コンピューティングシステム環境は、本発明の任意の態様の使用または機能の範囲についていかなる制限も示唆するようには意図されていない。さらに、このコンピューティングシステム環境は、例示的な動作環境において図示されたコンポーネントの任意の１つまたは組み合わせに関するいかなる依存関係または要件も有するものと解釈されるべきではない。本発明の態様で使用するのに適した周知のコンピューティングシステム、環境、および／または構成の例には、パーソナルコンピュータ、サーバコンピュータ、ポータブルまたはラップトップデバイス、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、プログラマブル家庭用電化製品、携帯電話、ネットワークＰＣ、マイクロコンピュータ、メインフレームコンピュータ、上記システムまたはデバイスの任意のものを含む分散コンピューティング環境などが含まれるが、これらには限定されない。
【００５１】
本発明の実施形態を、１つまたは複数のコンピュータまたは他のデバイスによって実行される、プログラムモジュールなどのコンピュータ実行可能命令の一般的な文脈で説明することができる。一般に、プログラムモジュールには、ルーチン、プログラム、オブジェクト、コンポーネント、および特定のタスクを実行するかまたは特定の抽象データタイプを実装するデータ構造が含まれるが、これらには限定されない。本発明の態様を、通信ネットワークを通じてリンクされるリモート処理デバイスによってタスクが実行される、分散コンピューティング環境において実施することもできる。分散コンピューティング環境では、プログラムモジュールを、メモリストレージデバイスを含むローカルコンピュータ記憶媒体とリモートコンピュータ記憶媒体の両方に配置することができる。
【００５２】
動作については、システム４００は、図８などの図に図示された命令などのコンピュータ実行可能命令を実行して、本発明の態様を実施する。例えば、ユーザが車を売りたい場合、「自動車販売アクティビティ」を想定する。ファイルおよび任意のフォーマットでアクティビティを明確に表すことによって、本発明の実施形態は、このようなワークフローアクティビティを処理することができる。この「自動車販売アクティビティ」は、次のような１つまたは複数のワークアイテムを含むことができる。すなわち、オンラインで販売を宣伝する、ラジオ局を介して販売を宣伝する、新聞の広告欄を介して販売を宣伝する、および自動車の窓に「売り物」の張り紙を貼って販売を宣伝するなどのワークアイテムである。アクティビティはまた、ユーザが任意のソースから申し込みを受け付けると、該ユーザは多数の申し込みを受け取るおよび／または受け付けることを避けるために宣伝活動を取り消すように規定する。
【００５３】
例えば、ユーザが、オンラインで掲示された宣伝を見ている人から申し込みを受け取りおよび受け付ける場合を想定する。「オンラインで販売を宣伝する」ワークアイテムは、閉状態に遷移され、現在実行状態にある全ての他のワークアイテムに対して通知をトリガする。本発明の実施形態は、「新聞に告知する」、「未決定かつ見込みのある買い手に通知する」、「オンライン宣伝を取り下げる」などの取り消しの後オペレーションのいずれかが実行されるどうかを指示するように、ユーザにさらに要求することができる。したがって、アクティビティは最終的には閉状態に遷移され、「自動車販売アクティビティ」を宣言的なやり方で終了する。
【００５４】
本明細書に図示および記載された本発明の実施形態において、オペレーションの実行または実施の順序は、特に指定しない限り重要ではない。すなわち、特に指定しない限り、オペレーションを任意の順序で実行することができ、本発明の実施形態は、追加のオペレーションまたは本明細書に開示されるよりも少ないオペレーションを含むことができる。例えば、特定のオペレーションを、別のオペレーションの前、同時、または後で実行または実施することは、本発明の態様の範囲内であると考えられる。
【００５５】
本発明の実施形態を、コンピュータ実行可能命令を用いて実装することができる。コンピュータ実行可能命令を、１つまたは複数のコンピュータ実行可能なコンポーネントまたはモジュールに編成することができる。本発明の態様を、任意の数および編成の上記コンポーネントまたはモジュールで実装することができる。例えば、本発明の態様は、図面に図示され本明細書に記載された、特定のコンピュータ実行可能命令、または特定のコンポーネンもしくはモジュールに限定されない。本発明の他の実施形態は、本明細書に図示および記載されるよりも多いまたは少ない機能を有する異なるコンピュータ実行可能命令またはコンポーネンを含むことができる。
【００５６】
本発明の態様またはその実施形態の構成要素を紹介するとき、冠詞「ある（ａ）」、「ある（ａｎ）」、「その（ｔｈｅ）」、および「前記（ｓａｉｄ）」は、該構成要素の１つまたは複数があることを意味するように意図される。「備える（ｃｏｍｐｒｉｓｉｎｇ）」、「含む（ｉｎｃｌｕｄｉｎｇ）」、および「有する（ｈａｖｉｎｇ）」という語は、包括的であり、列挙した要素の他に追加の要素があり得ることを意味するように意図される。
【００５７】
本発明の態様について詳細に説明してきたが、添付の特許請求の範囲で定義される本発明の態様の範囲から逸脱することなく、修正および変形が可能であることは明らかであろう。本発明の態様の範囲から逸脱することなく、上記の構造、生成物、および方法に様々な変更が可能であるので、上記の記載に含まれ添付の図面に示された全ての事項は、例示であり制限的な意味ではないと解釈されるべきである。
【図面の簡単な説明】
【００５８】
【図１】既存のプログラミングパラダイムを示すブロック図である。
【図２】本発明の一実施形態にかかる、ワークフロー設計フレームワークの仮想化を示す例示的なブロック図である。
【図３】本発明の一実施形態にかかる、例示的なワークフローを示す例示的な図である。
【図４】本発明の一実施形態にかかる、ワークフローアクティビティを処理するシステムの例示的なコンピューティング環境を示す図である。
【図５】本発明の一実施形態にかかる、ワークフローアクティビティの階層構造を示す図である。
【図６】本発明の一実施形態にかかる、アクティビティに関連付けられたワークアイテムの処理状態を記述する例示的な状態オートマトンを示す図である。
【図７Ａ】本発明の一実施形態にかかる、アクティビティのワークアイテムの宣言的な取り消しを示すブロック図である。
【図７Ｂ】本発明の一実施形態にかかる、アクティビティのワークアイテムの宣言的な取り消しを示すブロック図である。
【図７Ｃ】本発明の一実施形態にかかる、アクティビティのワークアイテムの宣言的な取り消しを示すブロック図である。
【図７Ｄ】本発明の一実施形態にかかる、アクティビティのワークアイテムの宣言的な取り消しを示すブロック図である。
【図７Ｅ】本発明の一実施形態にかかる、アクティビティのワークアイテムの宣言的な取り消しを示すブロック図である。
【図８】本発明の一実施形態にかかる、ワークフローのアクティビティのワークアイテムを取り消す方法を示すフロー図である。
【図９】本発明の態様を格納することができる、例示的なコンピュータ読み取り可能な媒体を示すブロック図である。
【図１】
2009532759.tif 000003
【図２】
2009532759.tif 000004
【図３】
2009532759.tif 000005
【図４】
2009532759.tif 000006
【図５】
2009532759.tif 000007
【図６】
2009532759.tif 000008
【図７Ａ】
2009532759.tif 000009
【図７Ｂ】
2009532759.tif 000010
【図７Ｃ】
2009532759.tif 000011
【図７Ｄ】
2009532759.tif 000012
【図７Ｅ】
2009532759.tif 000013
【図８】
2009532759.tif 000014
【図９】
2009532759.tif 000015
【国際調査報告】
2009532759.tif 000016
2009532759.tif 000017