JP2006107480A - フローベースおよび制約ベースのワークフローをオーサリングし、実行するための統一モデル - Google Patents

Abstract

【課題】 フローベースおよび制約ベースの領域を持つワークフローを設計し実行する機能を提供すること。
【解決手段】 ユーザは、制約ベースの領域の一部となるように１つまたは複数のアクティビティを選択する。それぞれの制約ベースの領域は、それに関連付けられた制約を持つ。ワークフローは、フローベースの領域および制約ベースの領域を実行することにより実行される。フローベースの領域は、順次実行される。制約は、評価され、制約ベースの領域は、評価された制約に応答して実行される。
【選択図】 図１

Description

本発明は、ワークフローモデリングの分野に関し、より詳細には、コンポーネント化された拡張可能ワークフローモデル（componentized and extensible workflow model）に関する。

既存のシステムでは、ビジネス問題をモデル化することによりビジネス問題を高水準のワークフローにマッピングすることを試みる。しかし、現実世界のワークフローは、（ａ）実行およびモデリングの複雑さ、（ｂ）設計時のフローの構造に関する知識、（ｃ）静的に定義された、またはアドホック／動的な特性、（ｄ）ライフサイクルにおけるさまざまな時点でのフローのオーサリングおよび編集の容易さ、（ｅ）ビジネスロジックとコアワークフロープロセスとの弱いまたは強い関連などのさまざまな次元において異なる。既存のモデルでは、これらすべての要因に対応することはできない。

さらに、ほとんどの既存のワークフローモデルは、言語ベースのアプローチ（例えば、ＢＰＥＬ４ＷＳ、ＸＬＡＮＧ／Ｓ、およびＷＳＦＬ）またはアプリケーションベースのアプローチに基づいている。言語ベースのアプローチは、定義済み言語構文の閉じた集合を持つ高水準のワークフロー言語であり、これにより、ユーザ／プログラマに対するワークフロープロセスのモデル化が容易になる。ワークフロー言語は、言語構文の閉じた集合に対するすべての意味情報を備え、これによりユーザはワークフローモデルを構築できる。しかし、言語は、開発者側で拡張することはできず、ワークフローモデルを構成するプリミティブの閉じた集合となっている。言語は、ワークフローシステムベンダが出荷する言語コンパイラに結び付けられている。ワークフローシステム製品ベンダのみが、将来の製品バージョンにおいて新しい言語構文の集合を加えて言語を拡張することによりモデルを拡張することができる。このため、多くの場合、言語に関連付けられたコンパイラのアップグレードが必要となる。

アプリケーションベースのアプローチは、アプリケーション内に領域特有の問題を解決するためのワークフロー機能を備えるアプリケーションである。これらのアプリケーションは、本当に拡張可能であるとはいえず、またプログラム可能なモデルも持たない。

既存のアプローチでは、複雑さ、先見、動的ワークフロー、オーサリングの容易さ、およびビジネスロジックとコアワークフローとの関連度の強さの課題が適切に扱えない。さまざまなクラスのワークフローをモデル化するビジュアルワークフローデザイナ（visual workflow designers）を構築するために利用できる、拡張可能、カスタマイズ可能、および再ホスト可能な（re-hostable）ワークフローデザイナフレームワークはない。既存のシステムでは、ユーザがグラフィックスを利用してワークフロープロセスの設計を行い、開発者が選択したプログラミング言語によるビジネスロジックを関連付けることができるアプリケーション短期開発（ＲＡＤ）スタイルのワークフロー設計の経験を欠いている。さらに、インク対応ワークフローデザイナ（ink-enabled workflow designer）もない。

さらに、既存システムは、ワークフローの実行のための継ぎ目のないアドホックな、または動的な編集機能を備えていない。ワークフロープロセスは、本質的に動的であり移動性を有し、その形態は設計時には全く予見できない。ワークフロープロセスは、構造化様式で始まり、最終的には、その実行存続期間の過程で発展し変化する。ワークフロービルダが設計時にさまざまな種類のワークフローモデルをオーサリングするだけでなく、継ぎ目のない方式でアドホックな、または動的な変更を実行中のワークフローに加えられるようにするワークフローオーサリングフレームワーク（workflow authoring framework）が必要である。ワークフロープロセスが展開された後、実行されていても、ビジネス要件に変更があれば、多くの場合、現在実行中のワークフロープロセスを変更または編集せざるを得ない。ワークフロープロセスの実行時オーサリングを行えるシステムが必要である。

さらに、ワークフロープロセスでは、ワークフロープロセスの複数のステップにまたがる分野横断的に直交する、かつ入り組んだ諸問題を取り扱う。例えば、ワークフロープロセスの一部が長い実行トランザクションに参加するように設計されているが、同じプロセスの他の部分は同時実行用に設計されている。同じワークフロープロセスのさらに他の部分では、追跡を必要とするが、他の部分ではビジネスまたはアプリケーションレベルの例外を扱う。特定の動作をワークフロープロセスの１つまたは複数の部分に適用する必要がある。

いくつかのワークフローモデリングアプローチは、すべての例外および人間介入を含むビジネスプロセス全体の完全なフローベースの記述を必要とするので実用的でない。これらのアプローチのいくつかは、例外が発生したときの追加機能を用意しているが、他のアプローチでは、ビジネスプロセスをモデル化するフローベースのアプローチの代わりに制約ベースのアプローチのみを採用する。既存システムでは、フローベースまたは制約ベースのアプローチのいずれかを実装する。このようなシステムは、柔軟性が低すぎて、ビジネスの数多くの一般的状況をモデル化できない。

したがって、これらの欠点およびその他の欠点の１つまたは複数を解決する、コンポーネント化された拡張可能なワークフローモデルが望まれる。

本発明のいくつかの実施形態は、コンポーネント化されたワークフローモデルを構築する拡張可能なフレームワークを実現する。特に、ワークフロープロセスの各ステップは、ワークフローステップの設計時の態様、コンパイル時の態様、および実行時の態様を記述する関連コンポーネントモデルを持つ。さらに、開発者は、これらのコンポーネントをオーサリングすることによりコアワークフローモデルを拡張することができる。本発明は、高度に形式的なマシン同士のプロセス、制約ベースのアドホックなヒューマンワークフロー、およびフローベースのアプローチおよび制約ベースのアプローチの混合を持つワークフローを含む、さまざまな種類のワークフローの実行を調整するのに十分柔軟であり強力なワークフローエンジンを含む。ワークフローエンジンでは、実行中ワークフローに対するアクティベーション、実行、クエリ、および制御の機能を使用できる。例えば、本発明では、実行ワークフローにアドホックな動的変更を加えることができる。ワークフローエンジンは、サーバおよびクライアント環境の両方を含むさまざまなホスト環境において再ホスト可能または埋め込み可能である。それぞれの特定のホスト環境では、ワークフローエンジンをサービスプロバイダ群に結合する。サービスプロバイダの集約機能により、特定のホスト環境で実行できるワークフローの種類が決定される。

本発明の他の実施形態では、ワークフローモデルをシリアライゼーションするために拡張オーケストレーションマークアップ言語（extensible orchestration markup language）（ＸＯＭＬ）などの宣言形式を備える。宣言形式を使用すると、ユーザはコンポーネントの集合を書くことによりワークフローモデルを拡張することができる。ワークフロープロセスのさまざまなステップに対応する意味論は、コンパイル時に与えられたコンポーネントの意味論の妥当性を確認し、それを強制するアクティビティバリデータコンポーネント（activity validator component）内にカプセル化される。本発明の宣言形式の実施態様では、さらに、データの宣言およびデータとワークフローモデルのさまざまな要素との関連付けが可能である。宣言形式では、ワークフローを通じてデータを変換する操作をサポートする。例えば、この形式は、ワークフローモデル内のデータベースまたはファイル、コードスニペット、およびビジネスルールなどの外部データソースを宣言的に表す。

本発明の一実施態様では、さまざまなクラスのワークフローをモデル化するグラフィカル／ビジュアルワークフローデザイナを構築する拡張可能、カスタマイズ可能、および再ホスト可能なワークフローデザイナフレームワークを提供する。本発明の他の実施態様では、ユーザが任意のプログラミング言語によりグラフィックスを利用してワークフロープロセスの設計を行い、ビジネスロジックの関連付けを行うことができるようにするアプリケーション短期開発スタイルのワークフロー設計のエクスペリエンスをサポートする。本発明の実施態様は、さらに、ペンおよびタブレット技術を使用してインクもサポートする。本発明は、ユーザにより描画されたワークフローが内部表現に変換されるフリーフォームドローイングサーフェス（free form drawing surface）を備える。本発明は、既存のドローイングサーフェス上のインク編集（例えば、追加／削除アクティビティ）、および既存のワークフローのインク注釈（例えば、デザインサーフェス（design surface）に手書きされたコメント、提案、または注意喚起）を介してワークフローの作成および修正をサポートする。

本発明のさらに他の実施態様では、宣言的方法により分野横断的な動作を捕捉し、その動作をワークフローモデルの選択された部分に適用するためのコンポーネントを備える。本発明の他の実施態様は、それに関連付けられている動作の背景状況においてワークフローモデルの選択された部分を実行する。本発明の実施態様は、フレームワーク、再利用可能コンポーネント、およびワークフロープロセスモデルの複数のステップにまたがる分野横断的に直交する、かつ入り組んだ諸問題を扱うための言語を提供する。

本発明の一態様によれば、コンピュータにより実装されるシステムは、ワークフローモデルに相当する。コンピュータにより実装されるシステムは、構造化された複数のアクティビティを持つワークフローを含む。ワークフローは、さらに、制約がそれぞれに関連付けられている構造化されていない複数のアクティビティを含む。このシステムは、さらに、構造化された複数のアクティビティのそれぞれを実行し、構造化されていない複数のアクティビティのそれぞれの制約を評価し、関連付けられている制約を評価した結果に応じて構造化されていない複数のアクティビティのそれぞれを実行することにより、ワークフローを実行するランタイムエンジンも備える。

本発明のさらに他の態様によれば、方法はワークフローをモデル化する。ワークフローは、ビジネスプロセスに相当する。この方法は、複数のアクティビティをユーザに提示することを含む。この方法は、さらに、ユーザから提示されたアクティビティの選択およびそれに関連付けられたフロー指定を受け取ることも含む。この方法は、さらに、受け取ったフロー指定に従ってアクティビティの受け取った選択をグループ化することも含む。この方法は、さらに、ユーザから提示されたアクティビティの他の選択およびそれに関連付けられた制約を受け取ることも含む。この方法は、さらに、ワークフローを作成するために提示されたアクティビティの受け取った他の選択とアクティビティのグループ化された選択とをマージすることも含む。

本発明のさらに他の態様によれば、１つまたは複数のコンピュータ読み取り可能媒体は、フローベースの領域および制約ベースの領域を持つワークフローをモデル化するためのコンピュータ実行可能コンポーネントを格納する。これらのコンポーネントは、複数のアクティビティをユーザに提示するための表示コンポーネントを含む。これらのコンポーネントは、さらに、ユーザから提示されたアクティビティの選択およびそれに関連付けられたフロー指定を受け取るためのインターフェイスコンポーネントも含む。インターフェイスコンポーネントは、さらに、ユーザから提示されたアクティビティの他の選択およびそれぞれ関連付けられた制約も受け取る。コンポーネントは、さらに、受け取ったフロー指定に従ってアクティビティの受け取った選択をグループ化するデザイナコンポーネントも含む。デザイナコンポーネントは、さらに、ワークフローを作成するために提示されたアクティビティの受け取った他の選択とアクティビティのグループ化された選択とをマージする。

それとは別に、本発明は、他のさまざまな方法および装置を含むことができる。

他の特徴は、一部は明白であり、また一部は以下で指摘される。

本発明のいくつかの実施形態では、ビジネスプロセスなどのプロセスを表すワークフローをモデル化する。ビジネスプロセスとは、予測可能で再現可能な成果が得られる従属する、順序付けられたタスク、アクティビティなどのことである。組織の運営手順、制度に関する実務知識、および情報資源を含めて、ビジネスプロセスは、効率よく、時機を逃すことなく定義済みのビジネス目的を達成するように設計される。効率的な環境では、プロセスの機能コンポーネントは、絶え間なく変化する企業要件に対処するために、容易に識別し、適合し、展開することができる。ワークフローは、ビジネスプロセス内のタスクとやり取りするエンドユーザ体験である。タスクは、アクティビティ、コンポーネントなどとしてモデル化され、それぞれ人またはマシンにより実行される一単位の作業である。一実施形態では、複数のアクティビティが一人のユーザに提示される。ユーザは、ワークフローを作成する複数のアクティビティを選択して編成する。作成されたワークフローは、実行され、ビジネスプロセスをモデル化する。図１を参照すると、ワークフロー１００の実施例は、タスクおよび制御フロー複合アクティビティを含んでいる。

一実施例では、オーケストレーションエンジンワークフローモデルは、さまざまなクラスのワークフローのモデリング、オーサリング、および実行をサポートする。実施例は、整然とした順序で、または非同期イベントの集合として実行される構造化されたステップの集合に関して与えられた問題をモデル化することを含む。オーケストレーションエンジンは、スケジュールの実行を調整する。スケジュールは、ツリー構造で階層的に配列されたアクティビティの整理された集合である。実行アクティビティの実行コンテキストおよび実行アクティビティから見える共有データは、スコープにより規定される。それぞれのアクティビティは、ワークフロープロセス内のステップに対するメタデータをカプセル化するコンポーネントを表す。アクティビティは、ワークフローモデルでの実行の基本単位であり、関連付けられたプロパティ、ハンドラ、制約、およびイベントを持つ。それぞれのアクティビティは、任意のプログラミング言語のユーザコードにより構成することができる。例えば、ユーザコードは、共通言語ランタイム（ＣＬＲ）言語で書かれたビジネスもしくはアプリケーションロジックまたはルールを表すことができる。それぞれのアクティビティは、ユーザコードでの実行へのインターセプト前フックおよびインターセプト後フック（pre-interception hooks and post-interception hooks）をサポートする。それぞれのアクティビティは、関連付けられたランタイム実行意味論および動作（例えば、状態管理、トランザクション、イベント処理、および例外処理）を持つ。アクティビティは、他のアクティビティと状態を共有できる。アクティビティは、プリミティブなアクティビティであるか、または複合アクティビティにグループ化することができる。プリミティブつまり基本アクティビティは、下位構造（例えば、子アクティビティ）を持たず、したがって、ツリー構造内の葉ノードである。複合アクティビティは、下位構造を含む（例えば、これは、１つまたは複数の子アクティビティの親である）。

一実施形態では、アクティビティは、単純アクティビティ、コンテナアクティビティ、およびルートアクティビティの３種類がある。この実施形態では、モデルには１つのルートアクティビティがあり、ルートアクティビティの内側に単純アクティビティまたはコンテナアクティビティは全くないか、またはいくらかある。コンテナアクティビティは、単純またはコンテナアクティビティを含むことができる。ワークフロープロセス全体は、高位のワークフロープロセスを構築するアクティビティとして使用することができる。さらに、アクティビティは、中断可能であるか、または非中断可能とすることができる。非中断可能複合アクティビティは、中断可能アクティビティを含まない。非中断可能アクティビティには、アクティビティにブロックさせるサービスはない。

オーケストレーションエンジンは、アクティビティの集まりの例を示している。図２を参照すると、アクティビティ継承ツリーにアクティビティの実施例が示されている。図２に一覧として示されているアクティビティの実施例は、付録Ａで詳しく説明する。さらに、ユーザは、ワークフローモデルを拡張するために１つまたは複数のアクティビティを書くことができる。例えば、ユーザは、特定のビジネス問題、領域、ワークフロー標準（例えば、ビジネスプロセス実行言語）、またはターゲットプラットフォームに対するアクティビティを書くことができる。オーケストレーションエンジンは、例えば、コードを分析するサービス、タイプ解決およびタイプシステム、シリアライゼーションするサービス、およびレンダリングを含むアクティビティを書くためのさまざまなサービスの集合をユーザに提供することができる。

一実施形態では、それぞれのアクティビティは、メタデータ、インスタンスデータ、および実行ロジックの少なくとも３つの部分を持つ。アクティビティのメタデータは、構成することができるデータプロパティを定義する。例えば、いくつかのアクティビティは、アクティビティ抽象基本クラスで定義されているメタデータの共通集合を共有することができる。それぞれのアクティビティは、このクラスを拡張することによりそのニーズに応じて独自の追加メタデータプロパティを宣言する。

メタデータプロパティの値は、アクティビティが構成されたスケジュールのいくつかのインスタンスの範囲において、そのアクティビティのすべてのインスタンスにより共有される。例えば、ユーザがスケジュールＡを作成し、送信アクティビティをそれに追加した場合、送信アクティビティはそのメタデータの一部として識別情報（例えば、「００１」）を与えられる。スケジュールに追加される第２の送信アクティビティは、その独自の一意的な識別情報（例えば、「００２」）を受け取ることになる。スケジュールＡの複数のインスタンスが作成され、実行されると、送信「００１」のすべてのインスタンスはメタデータ値を共有する。対照的に、アクティビティのインスタンスデータは、実行スケジュールインスタンス内のアクティビティのインスタンスに特有のデータの集合を定義する。例えば、遅延アクティビティは、遅延アクティビティのタイムアウト値を表す日時値であるインスタンスデータに関する読み取り専用プロパティを与えることができる。この値は、遅延アクティビティが実行を開始した後利用可能になり、遅延アクティビティの１つ１つのインスタンスについて十中八九異なる。参照を「インスタンス」で修飾せずに、スケジュールのインスタンス、特にアクティビティおよびタスクのインスタンスを参照するのがふつうである。

複合アクティビティは、その子アクティビティの集合を他の要素として持つ。子アクティビティは、一実施形態ではメタデータと考えられる。オーケストレーションエンジンモデルでは、スケジュールのインスタンス内で実行時にこのメタデータを操作できることを明示している。新しい子アクティビティを実行スケジュールインスタンスの一部である複合アクティビティに追加し、そのスケジュールインスタンスに対するメタデータ（アクティビティツリー）のみが影響を受けるようにすることが可能である。

次に図３を参照すると、それぞれのアクティビティは、そのアクティビティに対するコンポーネントモデルを形成する関連付けられたコンポーネントの集合を持つ。関連付けられたコンポーネントの集合は、アクティビティエグゼキュータ（activity executor）、アクティビティデザイナ、アクティビティシリアライザ（activity serializer）、アクティビティバリデータ（例えば、意味チェッカー（semantic checker））、およびアクティビティコードジェネレータを含む。アクティビティエグゼキュータは、アクティビティに対する実行意味論を実装するステートレスコンポーネントである。アクティビティエグゼキュータは、アクティビティを実装するためのアクティビティのメタデータを操作する。コアスケジューラは、アクティビティエグゼキュータのサービスプロバイダとして機能し、アクティビティエグゼキュータにサービスを提供する。

アクティビティデザイナは、アクティビティ設計時のビジュアル表現を視覚的に表示する。アクティビティデザイナは、デザイナ階層内の１つのノードであり、テーマまたはスキンを作成して設定できる。アクティビティデザイナは、設計環境（例えば、アプリケーションプログラム）でホスティングされ、サービスを介してホスト設計環境とやり取りする。アクティビティバリデータでは、コンパイル時だけでなく実行時にもアクティビティ意味論を課す。アクティビティバリデータは、ワークフローモデルのコンテキストに作用し、環境が提供するサービス（例えば、コンパイラ、デザイナ、またはランタイム）を使用する。妥当性検証は、ワークフローのライフサイクルの各時点で実行される。構造準拠検査は、ワークフローのシリアライゼーション表現を作成するときに、コンパイルするときに、およびユーザの要求に対する応答として実行される。意味検査は、コンパイル時に実行するよりも実行時の方が強く、このため実行インスタンスのアクティビティツリー内のアクティビティの追加または置換などの実行時オペレーションの安全性を保証することができる。本発明では、例えば、定義済みインターフェイス要件への適合または準拠に関してアクティビティのそれぞれに関連付けられた意味論を評価する。

アクティビティシリアライザは、アクティビティのメタデータをシリアライゼーションするコンポーネントである。アクティビティシリアライザは、さまざまなモデル／フォーマットシリアライザから呼び出される。ワークフローモデル全体が、拡張可能スキーマに基づいて宣言的マークアップ言語内にシリアライゼーションされ、さらに、望むとおりに他のワークフロー言語に変換することができる。

一実施形態では、アクティビティのコンポーネントモデルは、コンピュータ読み取り可能媒体上にデータ構造体として格納される。データ構造体において、アクティビティデザイナは、アクティビティを視覚的に表現するためデータ（例えば、アイコン）を格納する画像フィールドにより表される。さらに、１つまたは複数の作者時刻フィールドでは、アクティビティに関連付けられているプロパティ、メソッド、およびイベントを定義するメタデータを格納する。アクティビティシリアライザは、作者時刻フィールドに格納されているメタデータをアクティビティの宣言的表現に変換するためのデータを格納するシリアライザフィールドにより表される。アクティビティジェネレータは、作者時刻フィールドに格納されているメタデータに関連付けられているソフトウェアコードを格納するビジネスロジックフィールドにより表される。アクティビティエグゼキュータは、ビジネスロジックフィールドに格納されているソフトウェアコードを実行するためのデータを格納するエグゼキュータフィールドにより表される。

（スコープとスケジュール）
実行アクティビティの実行コンテキストおよび実行アクティビティから見える共有データは、スコープにより規定される。スコープとは、コアアクティビティのうちの１つである。スコープは、変数および長時間実行しているサービスの状態をトランザクション意味論、エラー処理意味論、補正、イベントハンドラ、およびデータ状態管理とともにひとまとめにするための統一言語構文である。スコープは、関連付けられた例外およびイベントハンドラを持つことができる。一実施形態では、スコープは、トランザクション、アトミック、長時間実行、または同期化のスコープとすることができる。ユーザ変数に対するｒｅａｄ−ｗｒｉｔｅまたはｗｒｉｔｅ−ｗｒｉｔｅ アクセスが衝突する場合にユーザのために同時実行制御が用意される。スコープは、さらに、トランザクション境界、例外処理境界、および補正境界でもある。スコープはスケジュール内でネストすることができるので、さらに、名前が衝突することなく異なるスコープ（スコープがネストしているとしても）内で同じ名前により変数、メッセージ、チャネル、および相関関係集合を宣言することが可能である。

スケジュール内にネストされているスコープは、そのスケジュールのコンテキスト内でのみ実行可能である。スケジュールは、アプリケーション（例えば、スタンドアロンの実行可能エンティティ）として、またはライブラリ（例えば、他のスケジュールから呼び出すため）としてコンパイルすることができる。ライブラリとしてコンパイルされたスケジュールはすべて、実際に、他のスケジュール内から呼び出すことができる新しいアクティビティ型を構成する。スケジュールのメタデータは、パラメータの宣言を含む。

スケジュールが作成された後、作成されたスケジュールのインスタンスを実行できる。スケジュールインスタンスをアクティブにし、制御するプロセスは、オーケストレーションエンジンが埋め込まれているホスト環境に応じて異なる。オーケストレーションエンジンは、スケジュールをテストするために使用できる余計な機能のない「単純なホスト」を提供する。さらに、オーケストレーションエンジンは、サービス環境（つまり、ホスト）とやり取りするため、エンジンおよび外部アプリケーションにより同様に使用される「サービスプロバイダ」モデル（例えば、アプリケーションプログラミングインターフェイス）の標準化を推進するアクティベーションサービスを提供する。アクティベーションサービスは、特定のスケジュール型のスケジュールインスタンスを作成し、その際に、任意選択で、パラメータを受け渡す。スケジュールインスタンスは、本質的に、実行スケジュールインスタンスのプロキシであり、インスタンス、スケジュールのメタデータ（アクティビティツリー）への参照、およびインスタンスのサスペンド、レジューム、および終了を実行するメソッドを一意に識別する識別子を含む。アクティベーションサービスは、さらに、与えられたスケジュールインスタンス識別子に基づいてスケジュールインスタンスを見つける操作もサポートする。

（コードビサイド）
スコープアクティビティは、スコープアクティビティのビジネスロジックを含む関連するコードビサイドクラスを持つことができる。スケジュールはそれ自体スコープであるため、スケジュールはコードビサイドクラスも持つことができる。スケジュール内にネストされているスコープも、それ独自のコードビサイドクラスを持つことができる。スコープ内でネストされているアクティビティは、共有データ状態およびビジネスロジックのコンテナとして働くスコープのコードビサイドクラスを共有する。例えば、コードアクティビティのメタデータは、コードビサイド内に特定のシグネチャを持つメソッドへの参照を含む。他の実施例では、送信アクティビティのメタデータは、特定のシグネチャのコードビサイドメソッドへのオプションの参照に加えてメッセージ宣言およびチャネル宣言への必須参照を含む。

コードビサイドの使用例としては、変数、メッセージ、チャネル、および相関関係集合の宣言、ｉｎ／ｏｕｔ／ｒｅｆパラメータの宣言、追加カスタムプロパティの宣言、送信するメッセージの準備、受信されたメッセージの処理、論理値を返すコードで表現されたルールの実装、ローカルで定義されている変数の操作、アクティビティメタデータおよびインスタンスデータの読み取り、アクティビティインスタンスデータの書き込み（例えば、実行されようとしているアクティビティに関するプロパティの設定）、イベントの発生、例外のスロー、横断的なネストされているスコープおよびスケジュール呼び出し境界を含む実行スケジュールインスタンスのアクティビティツリー内のアクティビティの階層の列挙およびナビゲート、実行スケジュールインスタンス内で複合アクティビティへの新規アクティビティの追加、実行スケジュールインスタンス内のアクティビティに関連付けられている宣言的ルールの変更、ならびに他の実行スケジュールインスタンスへの参照の取得および他の実行スケジュールインスタンスの操作が挙げられる。

図４を参照すると、ブロック図はコンポーネントモデルのライフサイクルの例を示す。ユーザは、１つまたは複数のコンピュータ読み取り可能媒体に格納されているコンピュータ実行可能コンポーネントとやり取りをし、フローベースの領域および制約ベースの領域を持つワークフローをモデル化する。コンピュータ実行可能コンポーネントは、表示コンポーネント４０２、インターフェイスコンポーネント４０４、デザイナコンポーネント４０６、およびランタイムコンポーネント４０８を含む。表示コンポーネント４０２は、複数のアクティビティをユーザに提示する。インターフェイスコンポーネント４０４は、ユーザから提示されたアクティビティの選択およびそれに関連付けられたフロー指定を受け取る。デザイナコンポーネント４０６は、受け取ったフロー指定に従ってアクティビティの受け取った選択をグループ化し、構造化された複数のアクティビティを作成する。インターフェイスコンポーネント４０４は、さらに、ユーザから提示されたアクティビティの他の選択およびそれぞれ関連付けられた制約も受け取る。この他の選択は、制約がそれぞれに関連付けられている構造化されていない複数のアクティビティを表す。一実施形態では、ユーザは、制約の１つまたは複数を定義する。デザイナコンポーネント４０６は、さらに、構造化された複数のアクティビティと構造化されていない複数のアクティビティとをマージして、ワークフローを作成する。ランタイムコンポーネント４０８は、フロー指定に従って構造化されている複数のアクティビティを実行する。ランタイムコンポーネント４０８は、さらに、構造化されていない複数のアクティビティのそれぞれに関連付けられた制約を評価し、評価により制約が満たされているアクティビティを実行することにより作成されたワークフローを実行する。一実施形態では、制約は、入力パラメータを持ち、ランタイムエンジン４０８は、さらに、入力パラメータの変更を識別し、制約を再評価することによりワークフローを実行する。

一実施形態では、表示コンポーネント４０２、インターフェイスコンポーネント４０４、デザイナコンポーネント４０６、およびランタイムコンポーネント４０８のうちの１つまたは複数は、アプリケーションプログラムの実行環境、コンテキストなどの中で実行される。

ハードウェア、ソフトウェア、および図４に例示され本明細書で説明されているようなシステムは、構造化された複数のアクティビティおよび構造化されていない複数のアクティビティをユーザに提示する手段の実施例、ユーザから構造化された複数のアクティビティの選択、構造化されていない複数のアクティビティの選択、および選択されたアクティビティに関連付けられているフロー指定を受け取る手段の実施例、ワークフローを作成するためにフロー指定に従って構造化された複数のアクティビティの選択および構造化されていない複数のアクティビティの選択をグループ化する手段の実施例、および作成されたワークフローを実行する手段の実施例の構成要素となる。

１つまたは複数のコンピュータ読み取り可能媒体は、メソッドを実行するコンピュータ実行可能命令を持つ。

（制約アクティビティグループ）
ワークフローは、さまざまな形状およびサイズのものがあり、それぞれ、アドホックなものからフォーマルなものまでの範囲のどこにあるかにより特徴付けられる。一般に、アドホックなワークフローは、タスクを任意の順序で遂行または実行する。つまり、タスクの集合は実行順序に関して独立である。フォーマルなワークフローは、きちんと定義された制御フローコンストラクト（例えば、順次実行、同時実行、条件付き分岐、ｗｈｉｌｅループ）を持ち、タスクの集合を正確に定義し制御するために使用される。いくつかのワークフローは、フォーマルな部分と、目標および制約を持つものとして表すのが最も容易なアドホックな他の部分とを持つ。場合によっては、ワークフローは、その存続期間中にこの範囲に沿って移行することも可能であり、またはインスタンスが実行中（ｉｎ−ｆｌｉｇｈｔ）のときにそのフローおよび／または制約を持つことも可能である。

本発明は、フローベースのスケジューリングおよび制約ベースのスケジューリングの統合を行う。この統合は、制約アクティビティグループ（ＣＡＧ）と呼ばれる制御フローコンストラクトを中心とする。ＣＡＧアクティビティは、実行過程が制約されたアクティビティに関連付けられた制約により誘導されるアクティビティのグループ化を実現する。この方法で、ＣＡＧを利用すると、実行パスが明示的にモデル化されないアクティビティの集合（例えば、関係する複数のアクティビティ）の目標指向の制約実行が容易になる。ＣＡＧの退化したケース（例えば、制約アクティビティ上で制約が指定されておらず、既定の完了条件が使用される場合）は、制約アクティビティの非同期同時実行または並列実行である。

ＣＡＧは、ＣＡＧが完了したとみなされるときを宣言する完了条件に関連付けられる。既定の完了条件の例では、ＣＡＧの実行は、含まれるアクティビティがすべて、完了またはキャンセル状態にある場合に完了であると宣言する。完了条件の例は、ＣＡＧを囲むスコープおよびその親スコープの中の変数およびメッセージおよび他のアクティビティの状態を参照する論理値である。ＣＡＧが潜在状態から有効化状態に移行したときに完了条件が真と評価された場合、ＣＡＧは、含まれているアクティビティを有効化または実行せずに即座に完了する。如何なるときでも実行中ＣＡＧアクティビティの完了条件が真と評価されれば、ＣＡＧ内に含まれるあらゆる実行中のアクティビティは、即座にキャンセルされ、ＣＡＧアクティビティは完了状態に移行する。

ＣＡＧ内のそれぞれのアクティビティは、関連付けられた制約を持つ。制約アクティビティの制約の例（例えば、ＣＡＧ内の制約）は、ＣＡＧを囲むスコープおよび兄弟スコープではなく、その親スコープの中の変数およびメッセージ、ならびにＣＡＧ内の他のアクティビティの状態も参照する論理関数である。制約は、データ依存関係および実装に関して知っていることに応じて透明、半透明、または不透明のいずれかである。実装ではなくデータ依存関係は、半透明制約の場合に分かる。完全透明制約については、データ依存関係および実装が分かる。不透明制約は、データ依存関係または実装のいずれについても情報を与えない。透明および半透明制約では、エンジンがそのような制約の評価が必要な場合について有益な判断を下せるためより効率的な評価を利用する。

アクティビティ上の使用可能制約は、真の場合、関連するアクティビティが実行可状態であり、有効にされなければならないとの宣言である。この制約は、アクティビティが潜在状態である間だけ意味がある。そのため、１回だけ真と評価することができる。制約は、有効にされた後いつでも無効にできる。これは、２つのタスクが２つの個別のものに割り当てられ、一方のタスクの完了により他方のタスクがキャンセルされる（無効にされる）場合に一般的なＸＯＲ条件をサポートする。使用不可制約は、使用可能制約のように、１回限りである。ＣＡＧの使用可能制約は、ＣＡＧの完了条件が満たされた後再有効化され、ＣＡＧ内のタスクに対し意味論またはｗｈｉｌｅ意味論を与えることができる。

ＣＡＧアクティビティの完了条件および制約されたアクティビティに関連付けられているすべての制約は、式の単一のコレクションと考えることができる。ＣＡＧ自体が有効化された場合、データ依存関係が満たされているすべての論理式が評価される。ＣＡＧの完了条件が真の場合、ＣＡＧは、直ちに完了とみなされる。そうでない場合、有効化される０個以上のアクティビティのリストが生成される。本発明のワークフローエンジンでは、識別されたアクティビティを有効化する。アクティビティが実行されたためスケジュールの状態（例えば、制約および完了条件が依存するデータユニバースの状態）に変更が生じると、制約の再評価が実行され、有効化される新しいアクティビティが識別される。式の評価およびアクティビティの実行は、段階的な、または２ステップの反復プロセスとは異なり、同時実行される。

次に図５を参照すると、ブロック図は、ＣＡＧを使用しフローベースの領域内に定義されている制約ベースの領域を持つワークフローモデル５００を例示している。フローベースの領域は、構造化されたアクティビティの集合（例えば、ワークフローモデル要素）を含む。ワークフローの制約ベースの領域は、関連付けられた制約（例えば、スケジュールのデータ状態についての論理式）が真の場合に実行されるアクティビティの集合を示す。フローベースのモデルは、アクティビティの１つに関連付けられている制約が満たされた場合は（例えば、いつまでも、またはＣＡＧ完了意味論が満たされるまで）、制約ベースの領域内のアクティビティが実行されている間にその終点に達したときに完了する。制約ベースの領域に対する完了意味論があれば、制約ベースの領域およびフローベースの領域を組み合わせることができる。

図５の実施例では、制約ベースの領域は、ＣｏｎｓｔｒａｉｎｅｄＧｒｏｕｐ１ ５０２を含む。ＣｏｎｓｔｒａｉｎｅｄＧｒｏｕｐ１内のアクティビティは、Ｓｅｎｄ１ ５０４およびＤｅｌａｙ１ ５０６を含む。アクティビティ５０４、５０６はそれぞれ、関連付けられた制約を持つ。さらに、完了条件５０８は、ＣｏｎｓｔｒａｉｎｅｄＧｒｏｕｐ１ ５０２に関連付けられる。

（ワークフローステンシル（Workflow Stencils））
ワークフローステンシル（例えば、ワークフローテンプレートまたはアクティビティパッケージ）は、ルートアクティビティおよびアクティビティの集合を含む。ステンシルは、領域および／またはホスト固有である。前者の実施例としては、構造化ワークフローステンシル、ヒューマンワークフローステンシル、および非構造化ワークフローステンシルがある。いくつかのステンシルは、場合によっては特定のホスト環境内で連携するように設計されている１つまたは複数のルートを含むアクティビティの集合として「閉じて」いてもよい。他のステンシルは、さまざまな程度で「開いて」いてもよい。ステンシルは、その拡張性ポイントを定める。例えば、開発者は、ＣｕｓｔｏｍＲｏｏｔおよび新しい抽象ＣｕｓｔｏｍＡｃｔｉｖｉｔｙを書いて、パッケージがＣｕｓｔｏｍＲｏｏｔであり、さらにＣｕｓｔｏｍＡｃｔｉｖｉｔｙから派生したアクティビティであると宣言する。

ＢＰＥＬまたはＸＬＡＮＧ／Ｓステンシルの実施例は、状態管理およびトランザクションに参加する、関連付けられたイベントおよび例外ハンドラを備える、コントラクトファーストモデル（contract first model）をサポートする、分析できる、正しく定義されたアクティベーションおよび終了動作を持つ、という特性を有するルートアクティビティを含む。ステンシルの実施例は、さらに、メッセージング特有のアクティビティの集合（例えば、ＳｅｎｄおよびＲｅｃｅｉｖｅおよびその変種）およびＳｃｏｐｅ、Ｌｏｏｐ、Ｃｏｎｄｉｔｉｏｎ、Ｌｉｓｔｅｎ、およびＴｈｒｏｗなどの他の構造化アクティビティを含む。

Ｈａｌｉｆａｘ Ｓｔｅｎｃｉｌの実施例は、暗黙の状態管理関連の例外ハンドラ（０〜ｎ）、イベントベースのモデルをサポートする、適切に定義されたアクティベーション動作を持つ、および未定義の終了がある、という特性を備えるルートアクティビティを含む。ルートアクティビティは、０〜ｎのＥｖｅｎｔＤｒｉｖｅｎアクティビティを含む。それぞれのＥｖｅｎｔＤｒｉｖｅｎ Ａｃｔｉｖｉｔｙは、Ｈａｌｉｆａｘ Ａｃｔｉｏｎを表す。それぞれのＥｖｅｎｔＤｒｉｖｅｎ Ａｃｔｉｖｉｔｙは、関連付けられた状態管理プロトコルを有し、アトミックスコープ内で実行される。

（デザイナフレームワーク（ユーザインターフェイス））
オーケストレーションエンジンは、ＷＹＳＷＹＧ方式でさまざまなクラスのワークフローモデルを設計するためのフレームワークを備える。例えば、図６を参照すると、ワークフローオーサリングするための高水準アプリケーションユーザインターフェイスは、ワークフローの指定をウィザードに依存している。このフレームワークは、開発者がビジュアルワークフローデザイナを書けるようにするサービスおよび動作の集合を含む。これらのサービスは、ワークフロープロセスのレンダリング、フローを描画するためのインク／タブレットのサポート、および元に戻す／繰り返し、ドラッグ／ドロップ、切り取り／コピー／貼り付け、ズーム、パン、検索／置換、ブックマーク、装飾、妥当性検証エラー用のスマートタグ、アクティビティ用の有効なドロップターゲットインジケータ、自動レイアウト、ビューページ付け、ナビゲーションマーカー、ドラッグインジケータ、ヘッダ／フッタ付き印刷およびプレビューなどの効率的方法を提供する。このようなユーザインターフェイスを使用することで、タスクおよび制御フロー複合アクティビティ（例えば、シーケンス、パラレル、および条件付き）を含む単純なワークフローを構成することができる。ルール指定（例えば、条件付き分岐ロジック、ｗｈｉｌｅループロジック）、またはデータフロー指定（例えば、タスクＡの出力がタスクＢへの入力である）のいずれにも、コードの入力（または既存のコンパイル済みコードへの依存）は不要である。（ルールおよびデータフローを含む）スケジュールのシリアライゼーションされた表現は、コードビサイドが必要ないいくつかのシナリオにおいて自己充足しており、完全である。

本発明のデザイナフレームワークを使用することで、本発明のオーケストレーションエンジンは、ソフトウェアコードをビジュアルな形でワークフローモデルに関連付ける機能をサポートするアプリケーション短期開発（ＲＡＤ）スタイルのビジュアルワークフローデザイナを含む。ワークフロー内のそれぞれのアクティビティは、関連付けられたアクティビティデザイナを備える。それぞれのアクティビティデザイナは、フレームワークサービスに関して作成される。本発明のフレームワークは、さらに、ビジュアルデザイナモデルも含む。ビジュアルデザイナモデルは、ワークフローモデルで記述された関係を介して互いにリンクされているアクティビティデザイナの集合を含む。図７は、ワークフローデザイナの実施例を示す。本発明は、ユーザコードとワークフローモデルとの間のラウンドトリッピングをリアルタイムで可能にする「Ｃｏｄｅ−Ｂｅｓｉｄｅ」、「Ｃｏｄｅ−Ｗｉｔｈｉｎ」、および「Ｃｏｄｅ−Ｏｎｌｙ」を含むコードをワークフローモデルに関連付けるさまざまなモードを含む。本発明は、さらに、ユーザがワークフロー構築している最中にリアルタイムで意味論的エラーを提示する。

一実施形態では、本発明は、デザイナフレームワークのユーザインターフェイス内の複数のアクティビティを識別するパッケージをユーザに提示する。本発明は、さらに、ユーザから、提示されたアクティビティの選択および階層的編成結果を受け取る。本発明では、受け取ったアクティビティをシリアライゼーションし、ワークフローの永続的表現を作成する。本発明は、さらに、ユーザから、ワークフロー内の複数のアクティビティのうちの１つとの関連付けのためのビジネスロジックを表すソフトウェアコードを受け取る。本発明は、さらに、関連付けられている１つまたは複数の意味論を持つユーザ定義アクティビティも受け取ることができる。本発明は、定義済みインターフェイス要件への適合に関して意味論を評価する意味チェッカーまたはバリデータを含む。意味論が定義済みインターフェイス要件に適合している場合、本発明では、ユーザ定義アクティビティを複数のアクティビティのうちの１つとして提示する。本発明は、さらに、そのソフトウェアコードをコンパイルして１つまたは複数のバイナリファイルを作成する。例えば、本発明は、シリアライゼーションされたワークフロー表現およびソフトウェアコードをワークフローの実行可能表現を含む単一のアセンブリにコンパイルする。本発明は、作成されたワークフローを実行する。一実施形態では、１つまたは複数のコンピュータ読み取り可能媒体は、メソッドを実行するコンピュータ実行可能命令を持つ。

オーケストレーションエンジンデザイナによって、ユーザは、他の作成済みスケジュールを使用し、それらを使用して上位のスケジュールを再帰的に作成することができる。スケジュールのインライン展開では、ユーザはスケジュールコンテンツをインラインで表示し、コンテンツを切り取ったりコピーしたりすることができる。スケジュールのインライン展開を有効にし、スケジュールを読み取り専用にするには、インラインスケジュールに対して別のデザインサーフェスおよびデザイナホストを作成する。さらに、複合スケジュールデザイナはそれ独自の階層を持つ。呼び出されたスケジュールはロードされ、ユーザによってデザイナが展開されたときに表示される。一実施形態では、デザイナは、アクティビティがデザインサーフェス上でアクティビティドロップまたはコピーされた場合に縮小する。プロパティは、呼び出し側アクティビティデザイナをホスティングされたスケジュールのルートデザイナに連鎖する。下記の関数は、デザイナからアクティビティの追加および削除を行うことを禁止する。

internal static bool AreAllComponentsInWritableContext(ICollection components)
internal static bool IsContextReadOnly(IServiceProvider serviceProvider)

これらの関数は、アクティビティが挿入されるコンテキストが書き込み可能かどうかをチェックするためにインフラストラクチャにより呼び出される。ホスティングされたデザイナでは、これらの関数は偽を返す。さらに、プロパティの修正が禁止される。他の関数は、適切なコンポーネントからアクティビティデザイナをフェッチする。

internal static ServiceDesigner GetSafeRootDesigner(IServiceProvider serviceProvider)
internal static ICompositeActivityDesigner GetSafeParentDesigner(object obj)
internal static IActivityDesigner GetSafeDesigner(object obj)

一実施例において、ユーザは、スケジュールを作成し、それをアクティビティとしてコンパイルする。コンパイルに成功すると、スケジュールはツールボックス上に表示される。ユーザは、コンパイルされたスケジュールの使用が望ましいスケジュールを開くか、または作成する。ユーザは、ツールボックスからコンパイル済みスケジュールをドラッグ＆ドロップする。縮小されたスケジュールデザイナがデザインサーフェスに示される。ユーザがドロップされたコンパイル済みスケジュールのコンテンツを表示したい場合、ユーザはそのスケジュールデザイナを展開して、呼び出されたスケジュールのコンテンツを読み取り専用状態でインライン表示する。呼び出されたスケジュールのインライン化により、ユーザはスケジュールデザイナ同士を切り換えなくても呼び出されたスケジュールを表示することができる。この機能は、既存のスケジュールを再利用して上位スケジュールを作成する開発者に有用な機能である。

（テーマ／スキンを使用したデザイナフレームワークのカスタマイズのサポート）
デザイナフレームワークを使用して書かれたワークフローデザイナは、ワークフローテーマを使用してカスタマイズすることができる。これらは、デザイナのさまざまな態様を宣言的に記述する拡張マークアップ言語（ＸＭＬ）ファイルとすることができる。ワークフローデザイナは、アクティビティを拡張するパートナのサポートをウィザードで対応している。ワークフローデザイナによりサポートされるユーザインターフェイス機能の例として、限定はしないが、元に戻す／繰り返し、ドラッグ／ドロップ、切り取り／コピー／貼り付け、ズーム、パン、検索／置換、ブックマーク、装飾、妥当性検証エラー用のスマートタグ、アクティビティ用の有効なドロップターゲットインジケータ、自動レイアウト、ビューページ付け、ナビゲーションマーカー、ドラッグインジケータ、ヘッダ／フッタ付き印刷およびプレビュー、およびドキュメントアウトライン統合がある。ワークフローデザイナは、ＸＭＬメタデータを使用してデザイナのルック＆フィールをカスタマイズできるカスタムデザイナテーマ／スキンをサポートする。ワークフローデザイナでは、バックグラウンドコンパイルをサポートする。一実施例では、スケジュールを設計しながら妥当性検証エラーを調べるスマートタグおよびスマートアクションが用意される。ワークフローデザイナは、任意のコンテナ（例えば、アプリケーションプログラム、シェルなど）でホスティングすることができる。

オーケストレーションエンジンプログラムの一実施例は、送信アクティビティが後に続く受信アクティビティを含む。このプロセスでは、メッセージを受信し、それを送出する。ユーザは、「Ｈｅｌｌｏ Ｗｏｒｌｄ」と呼ばれるプロジェクトを作成し、オーケストレーションアイテムをプロジェクトに追加する。ユーザは、その後、スコープアクティビティをデザインサーフェス上にドラッグ＆ドロップする。次に、ユーザは、送信アクティビティが後に続く受信アクティビティをスコープ上にドロップする。図７は、デザイナ内の結果として得られるワークフロー７００を例示している。それぞれのアクティビティデザイナは、オブジェクトモデル上のユーザインターフェイス表現を提供する。開発者は、オブジェクトモデルを直接プログラムして、アクティビティのプロパティを設定するか、またはデザイナを使用することができる。オーケストレーションエンジンデザイナを使用することにより、開発者はツールボックスからアクティビティを選択し、それをデザイナサーフェス上にドラッグすることができる。アクティビティがすでにスケジュールに入れられており、移動する必要がある場合、開発者は、それを選択して（それをクリックすることにより）、そのアクティビティを入れる必要のあるスケジュールの領域にドラッグすることができる。開発者がコントロールキーを押しながらドラッグ＆ドロップを行うと、選択されたアクティビティのコピーが作成される。

アクティブな配置では、可能なドロップポイント（ターゲット）をデザインサーフェス上にビジュアルインジケータとして用意する。自動スクロール機能も、ドラッグ＆ドロップのコンテキスト内で関与する。大きなスケジュールを取り扱う場合、現在ビューポート内にないデザイナの領域へのナビゲーションは、入れるスケジュールの領域に向かってアクティビティをドラッグすることによりアクセス可能である。

ドラッグ＆ドロップは、同じプロジェクト内のスケジュール間で、また同じソリューション内の他のプロジェクト内のスケジュール間でサポートされる。アクティビティがデザインサーフェス上に配置された後、開発者はそのアクティビティの構成を設定する。各アクティビティは、スケジュールが有効なものとなるように開発者が構成する一連のプロパティを持つ。これらのプロパティは、プロパティブラウザで編集可能である。すべてのアクティビティは、プロパティブラウザ内にどのようなプロパティを表示できるかを制御する。開発者がさまざまなアクティビティを構成するのを補助するため、デザイナは、さまざまなダイアログまたは「サブデザイナ」を備えている。ダイアログの各々は、アクティビティのさまざまなプロパティについて呼び出される。

オーケストレーションエンジンは、ツールボックス内に提示されるアクティビティをカスタマイズすることができる。開発者がカスタムアクティビティまたはスケジュールを作成する場合、最終結果はアセンブリである。ダイアログを使用することにより、開発者は、アセンブリロケーションに移動してブラウズし、そのアセンブリを選択してオーケストレーションエンジンアクティビティとして現れるようにすることができる。それとは別に、開発者は、オーケストレーションエンジンのインストールパス内にそのアセンブリを置くことができ、オーケストレーションエンジンアクティビティとして存在することになる。

（アプリケーションプログラミングインターフェイス（ＡＰＩ））
他の実施形態では、本発明は、さまざまなワークフローオペレーションを実行するためのアプリケーションプログラミングインターフェイス（ＡＰＩ）を備える。本発明は、ワークフローをオーサリングするためのデザインアプリケーションプログラミングインターフェイスを含む。デザインアプリケーションプログラミングインターフェイスは、ワークフローをオーサリングする手段およびアクティビティのうちの１つまたは複数を選択してワークフローを作成する手段を備える。本発明は、さらに、デザインアプリケーションプログラミングインターフェイスを介してオーサリングされたワークフローをコンパイルするためのコンパイルアプリケーションプログラミングインターフェイスも含む。コンパイルアプリケーションプログラミングインターフェイスは、ワークフローをシリアライゼーションする手段、ワークフローの視覚的な表示をカスタマイズする手段、デザインアプリケーションプログラミングインターフェイスを介してオーサリングされたワークフローをコンパイルする手段、ワークフローの妥当性確認を行う手段を含む。

本発明は、さらに、型をワークフロー内のアクティビティのそれぞれに関連付けるためのタイププロバイダアプリケーションプログラミングインターフェイスも含む。タイププロバイダアプリケーションプログラミングインターフェイスは、型をワークフロー内のアクティビティのそれぞれに関連付ける手段および型をワークフロー内のアクティビティのそれぞれに関連付ける手段を含む。

１つまたは複数のＡＰＩは、ワークフローをオーサリングする手段の実施例、アクティビティの１つまたは複数を選択してワークフローを作成する手段の実施例、ワークフローをシリアライゼーションする手段の実施例、ワークフローの視覚的表示をカスタマイズする手段の実施例、ワークフローの妥当性確認を行う手段の実施例、ワークフローをコンパイルする手段の実施例、および型をワークフロー内のアクティビティのそれぞれに関連付ける手段の実施例を含む。

（アクティビティ実行フレームワーク）
スケジュールおよびスコープを除き、エンジンは、アクティビティを抽象エンティティとして表示し、特定のアクティビティの特定のデータまたは意味論を知らずにアクティビティの実行を簡単に調整する。一実施形態では、４つのエンティティは、アクティビティ自体、実行中のアクティビティの親アクティビティ、実行中のアクティビティを取り囲むスコープ、およびオーケストレーションエンジンの実行中にやり取りをする。それぞれのエンティティは異なる関数を持つ。

完了をアクティビティコーディネータに知らせることなくアクティビティの実行メソッドが戻る場合、そのアクティビティは、論理的待ち状態にあると識別される。このようなアクティビティは、オーケストレーションエンジンによりキャンセルするか、または継続することができる（例えば、待っているアイテムまたはイベントが利用可能になるか、または実行され、エンジンによりこれにアクティビティが通知された後）。

論理的待ち状態に決して入らないいくつかのアクティビティは、決してキャンセルできない。実施例は、送信アクティビティおよびコードアクティビティを含むが、これらは外部イベントまたはサブスクリプションへの要求なしで実行されるからである。スレッドを渡された後（つまり、実行メソッドがオーケストレーションエンジンにより呼ばれた後）、これらのアクティビティは完了するまで動作し続ける。完了を通知するまでスレッドを返さないので、オーケストレーションエンジンにはキャンセルする機会が決して与えられない。

オーケストレーションエンジンのランタイムは、ルールを使用して、オーケストレーションエンジンアクティビティが実行されるイベントをトリガする。オーケストレーションエンジンデザイナは、関連付けられたルールを実行時に評価し、イベントを取り出するユーザ機能を提供する。オーケストレーションエンジンデザイナを利用することで、ユーザは、拡張性アーキテクチャを用意することによりさまざまな種類のルール技術を使用できる。デザイナは、使用されるルールの型には関知しない。

一実施形態では、デザイナは、ルールをアクティビティに関連付ける手段として論理式ハンドラをサポートしている。これは、ユーザコードファイル内で、ユーザが真または偽の値を返すメソッドを書くことを意味し、それに基づいてルールがトリガされる。現在、Ｉｎｆｏ ＡｇｅｎｔおよびＢｕｓｉｎｅｓｓ Ｒｕｌｅｓ Ｅｎｇｉｎｅ（ＢＲＥ）を含むルールを評価するために使用することもできる複数の技術がある。これを達成するために、デザイナは、ルール技術開発者がデザイナでカスタムユーザインターフェイスをホスティングできるようにする拡張性アーキテクチャを備える。デザイナは、コードステートメントコレクションの形でルールをシリアライゼーションするカスタムユーザインターフェイスライター向けの手段を用意している。デザイナは、コードステートメントコレクションが中に挿入されているユーザコードファイル内にブールハンドラを生成し出力する。オーケストレーションエンジンは、ルールライターにより使用することもできる既定のユーザインターフェイスを含む。ルール技術プロバイダは、カスタムルール宣言を作成し、そのカスタムルール宣言に関連付けられたユーザインターフェイスタイプエディタを書き、ルールユーザインターフェイスをホスティングするカスタムユーザインターフェイスを作成し、保存後にコードステートメントを生成することによりオーケストレーションエンジンデザイナにルールを追加する。

一実施例では、ユーザは、ルールがアタッチされる必要のあるアクティビティデザイナを選択し、プロパティブラウザでルールプロパティを特定し、ドロップダウン内の「ＲｕｌｅＥｘｐｒｅｓｓｉｏｎＨａｎｄｌｅｒ」を選択し（「Ｓｔａｔｅｍｅｎｔｓ」プロパティがユーザインターフェイス内のＲｕｌｅ Ｐｒｏｐｅｒｔｙの下に表示されるようにする）、「Ｓｔａｔｅｍｅｎｔｓ」プロパティ内のユーザコードメソッド名を指定し、ユーザインターフェイスタイプエディタを呼び出してルール特有のユーザインターフェイスをホスティングするダイアログを呼び出し、新しい述語行を作成しそれらをグループ化することによりダイアログ内でルールを定義する。ユーザインターフェイスは、ユーザコードファイルにメソッドを生成して出力する。メソッド名は、プロパティブラウザでユーザが指定したのと同じものである。ルールを作成することに相当するコードステートメントが、ルール用のユーザコードメソッド内に挿入される。

（実行時のメッセージング）
実行ワークフローでは、スケジュールに送られるメッセージは、特定のスケジュールインスタンス向けである。例えば、発注書＃１２３に対するインボイスをその発注書を発信した（例えば、送出した）のと同じスケジュールインスタンスに送り返さなければならない。受信メッセージと適切なスケジュールインスタンスとを照合するために、メッセージおよびスケジュールインスタンスは相関関係集合を共有する。相関関係集合は、メッセージ内の識別子フィールドがスケジュールインスタンスにより保持される同じ型の識別子と突き合わせて照合されることを意味する一価相関関係集合でよい。多プロパティ相関関係集合も可能であり、データベーステーブル内の複数列主キーに類似している。

スケジュールインスタンスにより保持されている相関関係集合の値は、スケジュールインスタンスがメッセージを送出するか（例えば、値は送信発注書の識別子フィールドから取り出せる）、またはメッセージを受信するときに初期化される。その後、この相関関係集合値は、そのスケジュールインスタンスの状態の一部となる。後続の受信メッセージが到着すると、スケジュールインスタンス状態で保持されている相関関係集合値は、予想される型の受信メッセージにより保持されている識別子と突き合わせて照合される。一致が見つかった場合、相関関係集合は満たされ、メッセージがスケジュールインスタンスに配送される。

相関関係集合の実装はオーケストレーションエンジンおよびホスト環境に左右されるが、一実施形態では、ユーザは相関関係集合を宣言してスケジュールインスタンスを正しく動作するようにする。他の実施形態では、いくつかのアクティビティ（例えば、ＳｅｎｄＲｅｑｕｅｓｔ／ＲｅｃｅｉｖｅＲｅｓｐｏｎｓｅアクティビティおよびＲｅｃｅｉｖｅＲｅｑｕｅｓｔ／ＳｅｎｄＲｅｓｐｏｎｓｅアクティビティ）は、ユーザと無関係に相関関係集合をセットアップする。送信および受信アクティビティにより広範にわたる妥当性チェックが実行され、相関関係集合が正しく初期化され、追随されるようにする。

（実行ワークフローの動的編集）
オーケストレーションエンジンは、さまざまな種類のワークフローをオーサリングする（そして、その後、ビジュアル化し、実行する）ためのフレームワークを提供する。実施例としては、ｅｖｅｎｔ−ｃｏｎｄｉｔｉｏｎ−ａｃｔｉｏｎ（ＥＣＡ）スタイルのワークフローまたは構造化フローまたはルール駆動フローがある。さらに、ワークフローのモデル化方法に関係なく、フレームワークにより、ユーザは設計時と同じ方法で、またはワークフロープロセスを再コンパイルしなくてもワークフロープロセスが実行しているときであってもワークフローをオーサリングまたは編集することができる。フレームワークを使用すると、ユーザはランタイムと高忠実度の設計時表現との間のラウンドトリッピングが可能になる。アドホックな変更は、プロセスモデルに対し実行時に加えられる変更である。ユーザは、そのスケジュールモデルを実行インスタンスに問い合わせ、モデルに変更を加えることができる。例えば、ユーザは、バッチ式でアクティビティの追加、削除、または置換を行うことができ、その後、バッチ変更をコミットまたはロールバックすることができる。一実施形態では、モデルは更新の後に妥当性確認が行われる。本発明の多くのワークフローシナリオでは、「設計時オーサリング」および「ランタイム実行」との間の分離のぼかし、またはさらには除去がある。

スケジュールインスタンスは、実際に、それらのインスタンスのスケジュール型について定義されているアクティビティ型（メタデータ）ツリーを他のインスタンスと共有する。しかし、スケジュールインスタンスは、実行を開始した後、新しいアクティビティの追加または宣言的ルールの操作を介してオンザフライで変更できる。そのような修正されたスケジュールインスタンスを取り出し、新しいスケジュール型として「名前を付けて保存」するか、またはより一般的に、インスタンスからシリアライゼーションされた表現を単純に復元することが可能である。つまり、実行スケジュールインスタンスを、シリアライゼーションし、その後、デザイナ（例えば、オーサリング環境）またはランタイムビジュアル化ツールに持ち込むことができる。

さらに、上級開発者は、スケジュールを丸ごとソフトウェアコードとしてオーサリングすることも可能である。スケジュール型を直接オーサリングする場合も、開発者は、単に、スケジュールのコードビサイドクラスのソフトウェアコードにＩｎｉｔｉａｌｉｚｅＳｃｈｅｄｕｌｅＭｏｄｅｌという静的メソッドを入れ、このメソッドに［ＳｃｈｅｄｕｌｅＣｒｅａｔｏｒ］属性でマークするだけである。一実施形態では、静的メソッドは、パラメータを取らず、Ｓｃｈｅｄｕｌｅオブジェクトを返す。随伴するシリアライゼーションされたファイルはないが、スケジュールのシリアライゼーションされた表現は、作成されるＳｃｈｅｄｕｌｅオブジェクトから復元できる。これは、単一のソフトウェアコードファイルを使用してスケジュールを作成できることを意味しているが、妥当性チェックは、このファイルには実行されえない。オーケストレーションエンジンのコンパイルにより、スケジュール型の基礎となっているアクティビティツリーの構造上および意味論的な有効性が保証される。他の実施形態では、コンパイルおよび妥当性検証を内部で実行し、実行される実際の型を生成するが、コードの入力は不要である。スケジュール型のコンパイルは、コンパイル時オブジェクトモデルから実行時オブジェクトモデルへの変換がない分、超軽量なプロセスとなっている。本質的に、コンパイルは、単に、スケジュールのオブジェクトモデル表現をコードビサイドと組み合わせて新しい型を生成するだけである。一実施形態では、基本的に、コンパイル済みコードビサイドがオブジェクトモデル内のアクティビティにより要求される内容と一致するか、またはコードビサイドがコンパイル済みフォーム（アセンブリ）内にすでに存在している可能性がある場合には、特定のスケジュールについてコードビサイドを全く生成する必要はないと考えられる。

シリアライゼーションされたスケジュールをコンパイルする場合、そのスケジュールに対するコードビサイドとして実際に使用される既存のコンパイル済み型を指すことが可能である。このコンパイル済み型の派生型が作成され、この新しい型はコードビサイドとして使用され、一意的な型が新しいスケジュールを表すように作成されることが保証される。

（シリアライゼーションアーキテクチャ）
シリアライゼーションインフラストラクチャは、オーケストレーションエンジンのアクティビティツリーをシリアライゼーションする、モジュール方式の、形式に依存しない、容易に拡張可能なメカニズムを提供する。

特に、呼び出し側（例えば、アプリケーションプログラムまたはユーザ）は、シリアライゼーションマネージャからシリアライザにオブジェクト（またはアクティビティ）Ａを要求する。オブジェクトＡの型のメタデータ属性により、オブジェクトＡは要求された型のシリアライザにバインドされる。次に、呼び出し側は、オブジェクトＡをシリアライゼーションするようにシリアライザに要求する。続いて、オブジェクトＡのシリアライザはオブジェクトＡをシリアライゼーションする。シリアライザは、遭遇するオブジェクト毎に、シリアライゼーションしながら、シリアライゼーションマネージャに追加シリアライザを要求する。シリアライゼーションの結果が呼び出し側に返される。

オーケストレーションエンジンコンポーネントモデル内のすべてのアクティビティは、シリアライゼーションに参加することができる。シリアライザコンポーネントは、一実施形態ではアクティビティクラス自体の一部ではない。その代わりに、このコンポーネントは、アクティビティに関連付けられたクラス内のシリアライザ属性に注釈を入れることにより指定される。シリアライザ属性は、そのアクティビティ型のオブジェクトをシリアライゼーションするために使用されるクラスを指す。他の実施形態では、ある１つのアクティビティ型のプロバイダコンポーネントが、そのアクティビティにより与えられる既定のシリアライザをオーバーライドする。

デザイナシリアライゼーションは、メタデータ、シリアライザ、およびシリアライゼーションマネージャに基づく。メタデータ属性は、型をシリアライザに関係付けるために使用される。「ブートストラッピング」属性は、シリアライザを持たない型に対しシリアライザを提供するオブジェクトをインストールするために使用することができる。シリアライザは、特定の１つの型またはある範囲の複数の型をシリアライゼーションする方法を認識するオブジェクトである。それぞれのデータ形式に対して１つの基本クラスがある。例えば、オブジェクトをＸＭＬに変換する方法を認識するＸｍｌＳｅｒｉａｌｉｚｅｒ基本クラスが考えられる。本発明は、特定のシリアライゼーション形式に関係しない一般的なアーキテクチャである。シリアライゼーションマネージャは、オブジェクトグラフをシリアライゼーションするために使用されるさまざまなシリアライザに対する情報ストアとなるオブジェクトである。例えば、５０個のオブジェクトのグラフは、すべてそれ独自の出力を生成する５０個の異なるシリアライザを持つことができる。これらのシリアライザがシリアライゼーションマネージャを使用して、必要に応じて互いに通信し合うことができる。

一実施形態では、汎用オブジェクトメタデータを使用するシリアライザに結合されたシリアライゼーションプロバイダを使用することにより、与えられた型に対するシリアライザを用意する機会がオブジェクトに与えられるコールバックメカニズムを実現する。ＡｄｄＳｅｒｉａｌｉｚａｔｉｏｎＰｒｏｖｉｄｅｒなどのメソッドを通じて、シリアライゼーションマネージャにシリアライゼーションプロバイダを用意することができる。シリアライゼーションプロバイダは、ＤｅｆａｕｌｔＳｅｒｉａｌｉｚａｔｉｏｎＰｒｏｖｉｄｅｒＡｔｔｒｉｂｕｔｅなどの属性をシリアライザに追加することによりシリアライゼーションマネージャに自動的に追加できる。

一実施形態では、オブジェクトはｘｍｌ要素としてシリアライゼーションされる、オブジェクトのプロパティは単純プロパティ（例えば、ｘｍｌ属性としてシリアライゼーションされる）または複合プロパティ（子要素としてシリアライゼーションされる）として分類される、オブジェクトの子オブジェクトは子要素としてシリアライゼーションされる、というルールに従って形式が示される。子オブジェクトの定義は、オブジェクト毎に異なることがある。以下の実施例は、子オブジェクトの１つとしてＳｅｎｄアクティビティを持つ、ｗｈｉｌｅアクティビティのシリアライゼーションである。

シリアライゼーションに使用される言語がＸＯＭＬである一実施形態では、それぞれのＸＯＭＬ要素は、スケジュールがコンパイルされるときにそれぞれのオブジェクトにシリアライゼーションされる。オブジェクトは、単純型と複合型の両方を含む。各アクティビティのＸＯＭＬ表現の間のマッピングとオーサリングオブジェクトモデルへのマッピングについて、次に説明する。ＸＯＭＬのシリアライゼーションは、プリミティブアクティビティと複合アクティビティとで異なる。

プリミティブアクティビティに対する単純型は、アクティビティ型に関する属性としてシリアライゼーションされる。プリミティブアクティビティに対する複合型は、子要素としてシリアライゼーションされる。例えば、以下に、ＳｅｎｄアクティビティのＸＯＭＬ表現を示す。

プリミティブ型のシリアライゼーションと同様に、複合アクティビティに対する単純型は、アクティビティ型に関する属性としてシリアライゼーションされる。しかし、定義により、複合アクティビティはネストされたアクティビティをカプセル化したものである。それぞれのネストされているアクティビティは、他の子要素としてシリアライゼーションされる。例えば、以下に、ＷｈｉｌｅアクティビティのＸＯＭＬ表現を示す。

プロセス／ワークフロービューとシリアライゼーションされた表現との間に強い関係が存在する。図９は、スケジュール定義およびビジュアルワークフローと、ワークフローのシリアライゼーションされた（例えば、ＸＯＭＬ）表現と、ワークフローのコードビサイドとの間の関係を示す図である。いずれかの表現でオーサリングする場合、他方は変更を招く。そのため、アクティビティ（または複合アクティビティの場合にはその構成要素部分）に対するＸＯＭＬを修正すると、開発者がプロセス／ワークフロービューの切り換えを行うときにプロセス／ワークフロービューに直接反映される。逆も言える。プロセス／ワークフロービュー内のアクティビティを修正すると、ＸＯＭＬ内に適切な修正が生じる。例えば、プロセス／ワークフロービュー内でアクティビティを削除すると、同じアクティビティについてＸＯＭＬ内のＸＭＬ要素も削除される。ラウンドトリッピングは、プロセス／ワークフロービューとコードビサイドとの間にも生じる。

ＸＯＭＬコードを作成するときに、ＸＯＭＬ定義が定義済みインターフェイス要件に適合していない場合、違反しているＸＭＬ要素は、下線が付けられるか、または開発者がそれとわかるように他の何らかの方法で視覚的に識別される。開発者がプロセスビューに切り換えた場合、ＸＯＭＬ内にエラーがあると警告され、デザイナがリンクを表示するので、開発者はそのリンクをクリックして、違反している要素にナビゲートする。この同じエラーは、タスクペインにも表示され、そのエラーをダブルクリックすると、開発者はＸＯＭＬの違反要素にナビゲートされる。

（ＸＯＭＬファイルからのアクティビティツリーの作成（デシリアライゼーション））
一実施形態では、ＣｒｅａｔｅＥｄｉｔｏｒＩｎｓｔａｎｃｅ（）関数が、ＤｅｓｉｇｎＳｕｒｆａｃｅオブジェクトを作成し、その後、ＤｅｓｉｇｎＳｕｒｆａｃｅオブジェクト上でＢｅｇｉｎＬｏａｄ（）関数を呼び出して実際のローダオブジェクトをその中に渡し、最後に、ＢｅｇｉｎＬｏａｄ（）でＤｅｓｉｇｎｅｒＬｏａｄｅｒ（）関数を呼び出す。ＰｅｒｆｏｒｍＬｏａｄ（）関数は、テキストバッファオブジェクトを読み込み、それをオーケストレーションエンジンコンポーネントモデル階層にデシリアライゼーションする。本発明は、階層内を辿り、アクティビティをデザインサーフェスに挿入し、コンポーネントをＶｉｓｕａｌ Ｓｔｕｄｉｏにロードする。

本発明は、さらに、ＸＯＭＬの変更を監視し、階層およびアイテム識別の変更を追跡して、Ｖｉｓｕａｌ Ｓｔｕｄｉｏのキャッシュ内の値を更新する。二次ドキュメントデータリストは、オーケストレーションエンジンデザイナが作用する、ユーザには見えない二次ドキュメントのリストを含む。例えば、ユーザはコードビサイドファイルを開いていないが、ユーザがオーケストレーションエンジンデザイナ内で変更を加えた場合に、コードビサイドファイルに変更が加えられる。このファイルはユーザには見えないので、ファイルは二次ドキュメントとして保持されるＸＯＭＬファイルが保存されると、必ず、二次ドキュメントも自動的に保存される。これらのファイルの１つの名前が変更されるか、またはファイルが削除された場合、本発明では、それに応じて、対応する二次ドキュメントオブジェクトを更新する。

オブジェクトツリーのデシリアライゼーションガイドラインの例を以下に示す。ｘｍｌ要素は、まず、親オブジェクトのプロパティとして取り扱われる。親オブジェクトが要素のタグ名を持つプロパティを持たない場合、その要素は親オブジェクトの子オブジェクトとして取り扱われる。ｘｍｌ要素は、親オブジェクト上の単純プロパティとして取り扱われる。

上記のシリアライゼーションされたコードを使用するデシリアライゼーションの実施例では、＜Ｗｈｉｌｅ＞要素は、ｘｍｌ名前空間情報を使用して作成されたオブジェクトとして取り扱われる。＜ＣｏｎｄｉｔｉｏｎＲｕｌｅ＞要素は、Ｗｈｉｌｅアクティビティのプロパティとして取り扱われる。＜ＣｏｄｅＥｘｐｒｅｓｓｉｏｎＲｕｌｅＤｅｃｌａｒａｔｉｏｎ＞要素は、値がＣｏｎｄｉｔｉｏｎＲｕｌｅプロパティに適用されるオブジェクトとして取り扱われる。最初に、＜Ｓｅｎｄ＞要素がＷｈｉｌｅアクティビティのプロパティとして試みられるが、「Ｗｈｉｌｅ」アクティビティは、名前「Ｓｅｎｄ」のプロパティを持たず、したがって、＜Ｓｅｎｄ＞要素はオブジェクトとして取り扱われ、ｗｈｉｌｅアクティビティの子アクティビティとして取り扱われる。＜Ｍｅｓｓａｇｅ＞要素は、Ｓｅｎｄアクティビティのプロパティとして取り扱われる。Ｓｅｎｄ 上のＭｅｓｓａｇｅプロパティは読み取り専用なので、Ｍｅｓｓａｇｅ要素のコンテンツは、Ｍｅｓｓａｇｅオブジェクトのコンテンツと考えられる。同様のルールが、＜ＯｎＢｅｆｏｒｅＳｅｎｄ＞および＜ＴｙｐｅｄＣｈａｎｎｅｌ＞要素のデシリアライゼーションに適用される。

ＸＯＭＬコードがきちんとした形でない、ＸｏｍｌＤｏｃｕｍｅｎｔがＸＯＭＬコード内の第１の要素でなく、ＸＯＭＬコード内の第１のアクティビティがデシリアライザできないという第１の条件の下では、ＸＯＭＬデシリアライゼーションは決定的に失敗する。開発者に対して、ＸＯＭＬビューからプロセス／ワークフロービューへ切り換える場合に、違反している側のＸＭＬ要素にナビゲートするためのエラーメッセージが提示される。

（オーケストレーションエンジンデザイナのホスティング）
デザイナフレームワークは、どのようなアプリケーションプログラムでもホスティングできる。これは、サードパーティのアプリケーションでそれぞれの環境においてワークフローをレンダリングするのに非常に有用な機能である。またこれにより、サードパーティは、デザインサーフェスを再ホスティングおよびカスタマイズすることで、オーケストレーションエンジンデザイナ周辺のツールを開発することができる。本発明のフレームワークでは、ホスティングコンテナアプリケーション側でエディタおよび／またはテキストバッファなどのサービス群を用意することを想定している。

デザイナを再ホストする１ステップでは、ローダおよびデザインサーフェスを作成する。ローダは、ＸＯＭＬファイルをロードし、アクティビティホストインフラストラクチャを構築する役割を持つ。デザインサーフェスは、その中にデザイナホストインフラストラクチャを保持し、デザインサーフェスをホスティングし、それとやり取りするサービスを提供する。デザインサーフェスは、サービスコンテナだけでなくサービスプロバイダとしても機能する。一実施例では、以下のコードを実行して、ＸＯＭＬドキュメントをロードし、その中にアクティビティを保持するデザイナホストを構築する。

以下のサービスでは、デザイナで異なる機能を使用できる。ＩＳｅｌｅｃｔｉｏｎＳｅｒｖｉｃｅ関数は、選択されたオブジェクトを保持する。ＩＴｏｏｌｂｏｘＳｅｒｖｉｃｅ関数は、ツールボックスとのやり取りを管理する。ＩＭｅｎｕＣｏｍｍａｎｄＳｅｒｖｉｃｅ関数は、メニューとのやり取りを管理する。ＩＴｙｐｅＰｒｏｖｉｄｅｒ関数を使用すると、タイプシステムを利用できる。さらに、高度なデザイナ機能を使用可能にするデザイナホスティング環境が提供する追加サービスもありえる。

タイプシステムは、本発明のコンポーネントモデルフレームワーク内の一コンポーネントである。デザイナがプロジェクトシステムの内側でホスティングされる場合、ＴｙｐｅＰｒｏｖｉｄｅｒオブジェクトがプロジェクト毎に作成される。プロジェクト内のアセンブリ参照は、タイププロバイダへプッシュされる。さらに、プロジェクト内のユーザコードファイルが解析され、単一コードコンパイル単位が作成され、タイププロバイダへプッシュされる。また、本発明は、タイプシステム内で型を変更させることが可能なプロジェクトシステム内のイベントを監視し、その変更に対する応答として型を再ロードする適切な呼び出しをタイププロバイダに対し実行する。

（元に戻す／繰り返し）
スケジュールを作成し、正しく構築した後、開発者は一連の実行済みオペレーションをロールバックしたい場合がある。本発明の「元に戻す」および「繰り返し」機能を使用すると、どのアクティビティが直接影響を受けているかを例示する視覚的フィードバックが得られる。例えば、アクティビティ上でプロパティの変更が元に戻される場合、影響を受けたアクティビティは選択状態になる。複数のオブジェクトの削除が元に戻される場合、関わっているすべてのオブジェクトが、スケジュールに復元されるときに選択状態になる。Ｕｎｄｏ／Ｒｅｄｏ（元に戻す／繰り返し）は、他の分野における多くのアプリケーション全体を通して使用される共通の機能であり、その意味はよく理解されている。オーケストレーションエンジンデザイナでは、Ｓａｖｅ後に、元に戻す／繰り返しアイテムがパージされることはない。さらに、元に戻す／繰り返しは、プロセス／ワークフロービューで、ＸＯＭＬビューで、開発者がビューを切り換えた場合に、およびコードビサイド内で実行することができる。

Ｕｎｄｏ／Ｒｅｄｏは、プロセス／ワークフロービュー内のアクション、つまり、アクティビティのドラッグ＆ドロップ（例えば、ツールボックスからデザインサーフェスにアクティビティをドラッグする、スケジュールの一部分から他の部分にアクティビティを移動する、一方のデザイナから他方のデザイナにアクティビティを移動する）、アクティビティの構成（例えば、アクティビティのプロパティを指定する）、および切り取り／コピー／貼り付け／削除のアクションに対し用意されている。

一実施形態では、シリアライゼーションされたビュー（例えば、ＸＯＭＬビュー）は、テキストエディタ標準の元に戻す／繰り返しオペレーションを備えるＸＭＬエディタである。本発明のデザイナは、プロセス／ワークフロービュー内で加えられた変更を示すフィードバックを開発者に提示する。その後、シリアライゼーションされたビュー内で元に戻した結果として、シリアライゼーションされたコードは失われる。開発者がプロセス／ワークフロービュー内のスケジュールの一部分を構築し、シリアライゼーションされたビューに切り換えて、その後、元に戻す／繰り返しオペレーションを実行することに決めた場合、警告が表示される。

（動作環境の例）
図１０は、コンピュータ１３０の形態の汎用コンピューティング装置の一実施例を示している。本発明の一実施形態では、コンピュータ１３０などのコンピュータは、例示され、本明細書で説明されている他の図で使用するのに適している。コンピュータ１３０は、１つまたは複数のプロセッサまたは演算処理装置１３２およびシステムメモリ１３４を備える。例示されている実施形態では、システムバス１３６は、システムメモリ１３４を含むさまざまなシステムコンポーネントをプロセッサ１３２に結合する。バス１３６は、メモリバスまたはメモリコントローラ、周辺機器バス、アクセラレイティッドグラフィックスポート、およびさまざまなバスアーキテクチャのどれかを使用するプロセッサまたはローカルバスを含む数種類のバス構造のうちの１つまたは複数を表している。例えば、限定はしないが、このようなアーキテクチャとしては、Ｉｎｄｕｓｔｒｙ Ｓｔａｎｄａｒｄ Ａｒｃｈｉｔｅｃｔｕｒｅ（ＩＳＡ）バス、Ｍｉｃｒｏ Ｃｈａｎｎｅｌ Ａｒｃｈｉｔｅｃｔｕｒｅ（ＭＣＡ）バス、Ｅｎｈａｎｃｅｄ ＩＳＡ（ＥＩＳＡ）バス、Ｖｉｄｅｏ Ｅｌｅｃｔｒｏｎｉｃｓ Ｓｔａｎｄａｒｄｓ Ａｓｓｏｃｉａｔｉｏｎ（ＶＥＳＡ）ローカルバス、およびＭｅｚｚａｎｉｎｅバスとも呼ばれるＰｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ（ＰＣＩ）バスがある。

コンピュータ１３０は、通常、少なくともある種の形態のコンピュータ読み取り可能媒体を備える。コンピュータ読み取り可能媒体は、揮発性および不揮発性媒体、取り外し可能および固定の媒体を含み、コンピュータ１３０によってアクセスできる媒体であればどのような媒体でもよい。例えば、限定はしないが、コンピュータ読み取り可能媒体は、コンピュータ記憶媒体および通信媒体を含む。コンピュータ記憶媒体は、コンピュータ読み取り可能命令、データ構造体、プログラムモジュール、またはその他のデータなどの情報を格納する方法または技術で実装される揮発性および不揮発性、取り外し可能な、および固定の媒体を含む。例えば、コンピュータ記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたはその他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多目的ディスク（ＤＶＤ）またはその他の光ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置またはその他の磁気記憶装置、または所望の情報を格納するために使用することができ、しかもコンピュータ１３０によりアクセスできるその他の媒体を含む。通信媒体は、通常、コンピュータ読み取り可能命令、データ構造体、プログラムモジュール、または搬送波もしくはその他のトランスポートメカニズムなどの変調データ信号によるその他のデータを具現するものであり、任意の情報配信媒体を含む。当業者は、信号内の情報を符号化するなどの方法により特性のうちの１つまたは複数が設定または変更される変調データ信号を熟知している。有線ネットワークまたは直接配線接続などの有線媒体、ならびに音響、ＲＦ、赤外線、およびその他の無線媒体などの無線媒体は、通信媒体のいくつかの実施例である。上記のいずれの組み合わせもコンピュータ読み取り可能媒体の範囲に含まれる。

システムメモリ１３４は、取り外し可能な、および／または固定の、揮発性および／または不揮発性メモリの形のコンピュータ記憶媒体を備える。例示されている実施形態では、システムメモリ１３４は、読み取り専用メモリ（ＲＯＭ）１３８およびランダムアクセスメモリ（ＲＡＭ）１４０を含む。起動時などにコンピュータ１３０内の要素間の情報伝送を助ける基本ルーチンを含む基本入出力システム１４２（ＢＩＯＳ）は、通常、ＲＯＭ １３８に格納される。通常、ＲＡＭ １４０は、演算処理装置１３２に直接アクセス可能な、および／または演算処理装置１３２によって現在操作されているデータおよび／またはプログラムモジュールを格納する。例えば、限定はしないが、図１０は、オペレーティングシステム１４４、アプリケーションプログラム１４６、その他のプログラムモジュール１４８、およびプログラムデータ１５０を例示している。

コンピュータ１３０はさらに、その他の取り外し可能な／固定の揮発性／不揮発性コンピュータ記憶媒体を備えることもできる。例えば、図１０は、固定の不揮発性磁気媒体への読み書きを行うハードディスクドライブ１５４を例示している。図１０は、さらに、取り外し可能不揮発性磁気ディスク１５８への読み書きを行う磁気ディスクドライブ１５６、およびＣＤ−ＲＯＭまたはその他の光媒体などの取り外し可能不揮発性光ディスク１６２への読み書きを行う光ディスクドライブ１６０を示している。動作環境の実施例で使用できる他の取り外し可能な／固定の揮発性／不揮発性コンピュータ記憶媒体としては、限定はしないが、磁気テープカセット、フラッシュメモリカード、デジタル多目的ディスク、デジタルビデオテープ、ソリッドステートＲＡＭ、ソリッドステートＲＯＭなどがある。ハードディスクドライブ１５４、および磁気ディスクドライブ１５６、および光ディスクドライブ１６０は、通常、インターフェイス１６６などの不揮発性メモリインターフェイスによりシステムバス１３６に接続される。

図１０に例示されている上記のドライブまたは他の大容量記憶装置およびその関連コンピュータ記憶媒体は、コンピュータ１３０用のコンピュータ読み取り可能命令、データ構造体、プログラムモジュール、およびその他のデータを格納する機能を備える。例えば、図１０では、ハードディスクドライブ１５４は、オペレーティングシステム１７０、アプリケーションプログラム１７２、その他のプログラムモジュール１７４、およびプログラムデータ１７６を格納するものとして例示されている。これらのコンポーネントは、オペレーティングシステム１４４、アプリケーションプログラム１４６、その他のプログラムモジュール１４８、およびプログラムデータ１５０と同じである場合もあれば異なる場合もあることに留意されたい。オペレーティングシステム１７０、アプリケーションプログラム１７２、その他のプログラムモジュール１７４、およびプログラムデータ１７６に対しては、ここで、異なる番号を割り当てて、最低でも、それらが異なるコピーであることを示している。

ユーザは、キーボード１８０、およびポインティング装置１８２（例えば、マウス、トラックボール、ペン、またはタッチパッド）などのなどの入力装置またはユーザインターフェイス選択装置を通じてコマンドおよび情報をコンピュータ１３０に入力することができる。他の入力装置（図に示されていない）としては、マイク、ジョイスティック、ゲームパッド、衛星放送受信アンテナ、スキャナなどがある。これらの入力装置およびその他の入力装置は、システムバス１３６に結合されているユーザ入力インターフェイス１８４を通じて演算処理装置１３２に接続されるが、パラレルポート、ゲームポート、またはユニバーサルシリアルバス（ＵＳＢ）などの他のインターフェイスおよびバス構造により接続することもできる。モニタ１８８またはその他の種類の表示装置も、ビデオインターフェイス１９０などのインターフェイスを介してシステムバス１３６に接続される。モニタ１８８のほかに、コンピュータはプリンタおよびスピーカなどの他の周辺出力装置（図に示されていない）を備えることが多く、これらは出力周辺機器インターフェイス（図に示されていない）を通じて接続することができる。

コンピュータ１３０は、リモートコンピュータ１９４などの１つまたは複数のリモートコンピュータへの論理接続を使用してネットワーク接続環境で動作することができる。リモートコンピュータ１９４は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピア装置、またはその他の共通ネットワークノードとすることができ、通常は、コンピュータ１３０に関して上で説明されている要素の多くまたはすべてを含む。図１０に示されている論理接続は、ローカルエリアネットワーク（ＬＡＮ）１９６およびワイドエリアネットワーク（ＷＡＮ）１９８を含むが、他のネットワークを含むこともできる。ＬＡＮ １９６および／またはＷＡＮ １９８は、有線ネットワーク、無線ネットワーク、それらの組み合わせなどとすることができる。このようなネットワーキング環境は、オフィス、企業規模のコンピュータネットワーク、イントラネット、および大域的コンピュータネットワーク（例えば、インターネット）では一般的である。

ローカルエリアネットワーキング環境で使用される場合、コンピュータ１３０は、ネットワークインターフェイスまたはアダプタ１８６を介してＬＡＮ １９６に接続される。ワイドエリアネットワーキング環境で使用される場合、コンピュータ１３０は、通常、インターネットなどのＷＡＮ １９８上で通信を確立するためモデム１７８またはその他の手段を備える。モデム１７８は、内蔵でも外付けでもよいが、ユーザ入力インターフェイス１８４、またはその他の適切なメカニズムを介してシステムバス１３６に接続される。ネットワーク接続環境では、コンピュータ１３０またはその一部に関して示されているプログラムモジュールは、リモートメモリ記憶装置（図に示されていない）に格納されうる。例えば、限定はしないが、図１０には、リモートアプリケーションプログラム１９２がメモリ装置に常駐しているように例示されている。図に示されているネットワーク接続は実施例であり、コンピュータ間の通信リンクを確立するのに他の手段が使用されうる。

一般に、コンピュータ１３０のデータプロセッサは、コンピュータのさまざまなコンピュータ読み取り可能記憶媒体にさまざまな時点において格納された命令を使ってプログラムされる。プログラムおよびオペレーティングシステムは、通常、例えば、フロッピー（登録商標）ディスクまたはＣＤ−ＲＯＭで配布される。そこから、コンピュータの補助記憶装置にインストールまたはロードされる。実行時に、それらは少なくとも一部はコンピュータの主記憶装置にロードされる。本明細書で説明されている発明は、これらおよび他のさまざまな種類のコンピュータ読み取り可能記憶媒体を含むが、ただしそのような媒体にマイクロプロセッサまたはその他のデータプロセッサに関して以下で説明されるステップを実装する命令またはプログラムが格納されている場合である。本発明は、さらに、本明細書で説明されている方法および手法に従ってプログラムされた場合にコンピュータ自体も含む。

例示の目的に関して、オペレーティングシステムなどのプログラムおよびその他の実行可能プログラムコンポーネントは、本明細書では異なるブロックとして例示されている。しかし、そのようなプログラムおよびコンポーネントは、コンピュータの異なる記憶装置コンポーネント内にさまざまな時点において常駐し、コンピュータの（複数の）データプロセッサにより実行されることは理解される。

本発明は、コンピュータ１３０を含む、コンピューティングシステム環境例に関して説明されているが、他の多くの汎用または専用コンピューティングシステム環境または構成で動作する。このコンピューティングシステム環境は、本発明の用途または機能の範囲に関する制限を示唆する意図はない。さらに、コンピューティングシステム環境は、動作環境例に例示されている１つのコンポーネントまたは複数のコンポーネントの組み合わせに関係する何らかの依存関係または要求条件がその環境にあるものと解釈すべきでない。本発明とともに使用するのに適していると思われるよく知られているコンピューティングシステム、環境、および／または構成の例として、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルドまたはラップトップ装置、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、プログラム可能な家電製品、携帯電話、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、上記システムまたは装置を含む分散コンピューティング環境などがある。

本発明は、１つまたは複数のコンピュータまたはその他の装置により実行される、プログラムモジュールなどのコンピュータ実行可能命令の一般的状況において説明することができる。一般に、プログラムモジュールは、限定はしないが、特定のタスクを実行する、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、およびデータ構造を含む。また、本発明は、通信ネットワークを通じてリンクされているリモート処理装置によりタスクが実行される分散コンピューティング環境で実施することもできる。分散コンピューティング環境では、プログラムモジュールをメモリ記憶装置などのローカルとリモートの両方のコンピュータ記憶媒体に配置できる。

ソフトウェアアーキテクチャの背景状況におけるインターフェイスは、ソフトウェアモジュール、コンポーネント、コード部分、またはコンピュータ実行可能命令の他のシーケンスを含む。例えば、インターフェイスは、第１のモジュールの代わりにコンピューティングタスクを実行するために第２のモジュールにアクセスする第１のモジュールを含む。第１および第２のモジュールは、一実施例では、オペレーティングシステムによって提供されるようなアプリケーションプログラミングインターフェイス（ＡＰＩ）、コンポーネントオブジェクトモデル（ＣＯＭ）インターフェイス（例えば、ピアツーピアアプリケーション通信用）、および拡張マークアップ言語メタデータ交換形式（ＸＭＩ）インターフェイス（例えば、複数のＷｅｂサービス間の通信用）を含む。

インターフェイスは、Ｊａｖａ（登録商標） ２ Ｐｌａｔｆｏｒｍ Ｅｎｔｅｒｐｒｉｓｅ Ｅｄｉｔｉｏｎ（Ｊ２ＥＥ）、ＣＯＭ、または分散ＣＯＭ（ＤＣＯＭ）の実施例などの密結合の同期実装であってよい。それとは別に、またはそれに加えて、インターフェイスは、Ｗｅｂサービスの場合のような疎結合の非同期実装とすることもできる（例えば、シンプルオブジェクトアクセスプロトコルを使用する）。一般に、インターフェイスは、密結合、疎結合、同期、および非同期という特性の任意の組み合わせを含む。さらに、インターフェイスは、標準プロトコル、専用プロトコル、または標準プロトコルと専用プロトコルとの任意の組み合わせに適合することができる。

本明細書で説明されているインターフェイスは、すべて、単一インターフェイスの一部であるか、または別々のインターフェイスもしくはそれらの任意の組み合わせとして実装することができる。これらのインターフェイスは、機能を提供するためにローカルまたはリモートで実行できる。さらに、これらのインターフェイスが含む機能は、例示されている、または本明細書で説明されている機能よりも多い場合も少ない場合もある。

例示され、本明細書で説明されている方法の実行または遂行の順序は、断りのない限り本質的ではない。つまり、これらの方法の要素は、断りのない限り任意の順序で実行することができ、それらの方法が含む要素は、本明細書で開示されている要素よりも多い場合も少ない場合もある。例えば、特定の要素を、他の要素の前に、他の要素と同時に、または他の要素の後に実行または遂行することは本発明の範囲であると考えられる。

本発明または本発明の（複数の）実施形態の要素を導入する際に、英文中の「ａ」、「ａｎ」、「ｔｈｅ」、および「ｓａｉｄ」という冠詞、したがって和文中の「１つの」、「その」、「前記」は、それらの要素が１つまたは複数あることを意味することを意図している。「備える」、「含む」、および「持つ、格納する、含む、備える」という言葉は、包含的であることを意図し、一覧に示されている要素以外にさらに要素がありうることを意味する。

上記の説明に照らして、本発明の複数の目的が達成され、他の有益な結果が得られることは理解されるであろう。

本発明の範囲から逸脱することなく上記の構成、製品、および方法にさまざまな変更を加えることが可能であるので、上記の説明に含まれ、付属の図面に示されているすべての事柄は、例示しているのであって、限定する意味はないと解釈するものとする。

付録Ａ
（アクティビティの例およびその実装例）
アクティビティの例としては、Ｓｅｎｄ、ＳｅｎｄＲｅｑｕｅｓｔ、ＳｅｎｄＲｅｓｐｏｎｓｅ、Ｒｅｃｅｉｖｅ、ＲｅｃｅｉｖｅＲｅｑｕｅｓｔ、ＲｅｃｅｉｖｅＲｅｓｐｏｎｓｅ、Ｃｏｄｅ、Ｄｅｌａｙ、Ｆａｕｌｔ、Ｓｕｓｐｅｎｄ、Ｔｅｒｍｉｎａｔｅ、ＩｎｖｏｋｅＳｃｈｅｄｕｌｅ、ＩｎｖｏｋｅＳｃｈｅｄｕｌｅｓ、Ｉｎｖｏｋｅ ＷｅｂＳｅｒｖｉｃｅ、ＤｏｔＮｅｔＥｖｅｎｔＳｏｕｒｃｅ、ＤｏｔＮｅｔＥｖｅｎｔＳｉｎｋ、Ｓｅｑｕｅｎｃｅ、Ｐａｒａｌｌｅｌ、Ｗｈｉｌｅ、ＣｏｎｄｉｔｉｏｎａｌＢｒａｎｃｈ、Ｃｏｎｄｉｔｉｏｎａｌ、Ｃｏｎｓｔｒａｉｎｅｄ、ＣｏｎｓｔｒａｉｎｅｄＡｃｔｉｖｉｔｙＧｒｏｕｐ（ＣＡＧ）、ＥｖｅｎｔＤｒｉｖｅｎ、Ｌｉｓｔｅｎ、ＥｖｅｎｔＨａｎｄｌｅｒｓ、ＥｘｃｅｐｔｉｏｎＨａｎｄｌｅｒ、ＥｘｃｅｐｔｉｏｎＨａｎｄｌｅｒｓ、Ｃｏｍｐｅｎｓａｔｅ、ＣｏｍｐｅｎｓａｔｉｏｎＨａｎｄｌｅｒ、Ｓｃｏｐｅ、およびＳｃｈｅｄｕｌｅがある。

アクティビティの実施例はそれぞれ、メタデータが関連付けられている。メタデータは、アクティビティに関連付けられたシリアライザによってワークフローの宣言的表現に移される。例えば、メタデータは、オプションのコードビサイドメソッドおよびオプションの相関関係集合のコレクションを含むことができる。
（Ｓｅｎｄアクティビティ）
オーケストレーションエンジンは、メッセージを送信する３つのアクティビティ（例えば、Ｓｅｎｄ、ＳｅｎｄＲｅｑｕｅｓｔ、およびＳｅｎｄＲｅｓｐｏｎｓｅ）を備え、それぞれ異なる使用事例を対象とする。さらに、これら３つのアクティビティは、何らかのメタデータを共有するので、抽象基本クラスが３つのすべての上位クラスとして定義され使用される。
（Ｒｅｃｅｉｖｅアクティビティ）
オーケストレーションエンジンは、メッセージを受信する３つのアクティビティ（例えば、Ｒｅｃｅｉｖｅ、ＲｅｃｅｉｖｅＲｅｑｕｅｓｔ、およびＲｅｃｅｉｖｅＲｅｓｐｏｎｓｅ）を備え、それぞれ異なる使用事例を対象とする。さらに、これら３つのアクティビティは、何らかのメタデータを共有するので、抽象基本クラスが３つのすべての上位クラスとして定義され使用される。
（Ｃｏｄｅ）
Ｃｏｄｅアクティビティは、メタデータで指示されているコードビサイドメソッドを実行する。
（Ｄｅｌａｙ）
Ｄｅｌａｙアクティビティは、その必須コードビサイドメソッドを実行してＤａｔｅＴｉｍｅ値を生成する。そのインスタンスデータのＴｉｍｅｏｕｔＶａｌｕｅプロパティをこの値に内部的に設定する。ＤａｔｅＴｉｍｅが過去であれば、Ｄｅｌａｙは即座に完了する。そうでなければ、タイマーが発火したときにＤｅｌａｙに通知するようにタイマーサブスクリプションをセットアップする。タイマーが発火した場合、Ｄｅｌａｙは通知され、完了する。
（Ｆａｕｌｔ）
Ｆａｕｌｔアクティビティは、その必須コードビサイドメソッドを実行してＥｘｃｅｐｔｉｏｎオブジェクトを生成する。その後、この例外をスローする。
（Ｓｕｓｐｅｎｄ）
Ｓｕｓｐｅｎｄアクティビティは、現在のスケジュールインスタンスをサスペンドする。
（Ｔｅｒｍｉｎａｔｅ）
Ｔｅｒｍｉｎａｔｅアクティビティは、現在のスケジュールインスタンスを終了する。
（Ｉｎｖｏｋｅ Ｓｃｈｅｄｕｌｅ）
ＩｎｖｏｋｅＳｃｈｅｄｕｌｅアクティビティはスケジュールを呼び出す。
（Ｉｎｖｏｋｅ Ｗｅｂ Ｓｅｒｖｉｃｅ）
プロキシクラスを介してＷｅｂサービスを呼び出して、パラメータを指定通り受け渡し、受信する。
（ＤｏｔＮｅｔＥｖｅｎｔ Ｓｉｎｋ）
すでに呼び出されているスケジュールインスタンスにより指定イベントが発生したという通知が来るのを待つブロック。
（ＤｏｔＮｅｔＥｖｅｎｔ Ｓｏｕｒｃｅ）
指定イベントを発生し、即座に実行を完了する。
（Ｓｅｑｕｅｎｃｅ）
Ｓｅｑｕｅｎｃｅアクティビティは、一度に１つずつ、順序正しく子アクティビティの集合の実行を調整する。
（Ｐａｒａｌｌｅｌ）
Ｐａｒａｌｌｅｌアクティビティは、子アクティビティの集合を同時実行する。
（Ｗｈｉｌｅ）
子アクティビティを繰り返し実行する。
（ＣｏｎｄｉｔｉｏｎａｌＢｒａｎｃｈ）
Ｓｅｑｕｅｎｃｅの意味論に従って、子アクティビティを実行する。
（Ｃｏｎｄｉｔｉｏｎａｌ）
Ｃｏｎｄｉｔｉｏｎａｌアクティビティは、ＣｏｎｄｉｔｉｏｎａｌＢｒａｎｃｈアクティビティの順序付き集合を含む。
（Ｃｏｎｓｔｒａｉｎｅｄ）
制約アクティビティグループ（ＣＡＧ）に追加する目的でアクティビティをラップする。
メタデータ：
ラップされたアクティビティの使用可能ルール。

ラップされたアクティビティの使用不可ルール。
実行時プロパティ：
ラップされたアクティビティが少なくとも１回完了しているかどうかを示す整数値。
実行：
制約されているアクティビティの唯一許容される親はＣＡＧである。ＣＡＧ自体は、制約されているアクティビティで使用可能および使用不可ルールを用いて、いつ実行するかを決定する。ＣｏｎｓｔｒａｉｎｅｄアクティビティがＣＡＧにより実行を指示された場合、それがラップするアクティビティを単に実行するだけである。

Ｐｅｒｆｏｒｍｅｄプロパティは、制約アクティビティがその実行を完了するとインクリメントされる。親ＣＡＧ自体が再実行される場合のみ０にリセットされる（例えば、ＷｈｉｌｅＬｏｏｐまたは第２の外側のＣＡＧ内）。
（ＣＡＧ（Ｃｏｎｓｔｒａｉｎｅｄ Ａｃｔｉｖｉｔｙ Ｇｒｏｕｐ））
子Ｃｏｎｓｔｒａｉｎｅｄアクティビティの集合の制約ベースの実行を行う。
メタデータ：
完了ルール。
実行：
ＣＡＧは、制約アクティビティのみを含む。ＣＡＧは、実行されると、その使用可能および使用不可制約の評価に基づいて子アクティビティを実行（および再実行）する。子アクティビティは、使用可能ルールが真と評価され、使用不可ルールが偽と評価された場合のみＣＡＧによって実行される。一実施形態では、ＣＡＧは、部分ツリーを辿り、すべてのアクティビティについてアクティビティ状態変更にサブスクライブする（これは呼び出し境界のところで停止する）。ＣＡＧは、アクティビティが部分ツリーに動的に追加される場合にサブスクリプションを追加する。ＣＡＧは、その囲むスコープおよびすべての親スコープからスケジュール境界までについてデータ変更にサブスクライブする。これらのサブスクリプションは、ＣＡＧ内のすべての制約されているアクティビティに対する使用可能および使用不可ルールを分析することにより決定される。エンジンは、データ変更の一括処理通知を配信し、ＣＡＧは、評価すべきルールを決定する。呼び出されたスケジュールにより加えられたデータ変更は、その呼び出しが完了するとポストされることに注意されたい。本発明では、さらに、それらの変数がコードビサイドメソッドを介して間接的にアクセスされる場合でもスコープ変数依存関係を識別する。したがって、変数が変更されたときにどの制約を再評価すべきかを決定する際に非常に特異的である可能性がある。宣言的ルールとコードルールの両方について、同じメカニズムが機能する。制約アクティビティに使用可能ルールがない場合、常に真とみなす。制約アクティビティに使用不可ルールがない場合、常にＰｅｒｆｏｒｍｅｄ＞０になるとみなす。したがって、制約アクティビティ上でルールが指定されていない場合、ＣＡＧが実行され、再実行されることがない場合にすぐに実行される。同様に、制約アクティビティ上でカスタム使用可能ルールのみが用意される場合、その使用可能ルールが真と評価されたときに実行され、そのときのみ実行される。制約ベースの再実行が望まれている場合、適切なカスタム使用不可ルールを、適切な使用可能ルールとともに用意しなければならない。以下の表は、制約アクティビティを実行するために必要な条件をまとめたものである。

アクティビティの実行時に、そのアクティビティに対する使用不可ルールが真と評価される場合、ＣＡＧはそのアクティビティの実行をキャンセルする。これは、そのアクティビティの再実行を除外するわけではない。ＣＡＧの完了ルールが真と評価されるとすぐに、ＣＡＧは、現在実行中の子アクティビティを直ちにキャンセルした後、それ自体完了する。ルール（使用可能、使用不可、および完了）は、そのデータおよび状態変更依存関係に基づいて必要な場合であれば必ず評価される。

ＣＡＧは、ＰｒｅｖｉｅｗとＥｄｉｔの２つのオペレーションモードを持つ。ＣＡＧデザイナがプレビューモードであれば、開発者は、フィルムストリップを表示するアクティビティを選択することだけできる。プロパティブラウザは、開発者がアクティビティを選択していた場合に、使用可能および使用不可ルールオプションを公開する。これにより、開発者は、ＣＡＧを使用してそれぞれのアクティビティに対して使用可能および使用不可ルールを設定することができる。ＣＡＧデザイナが設計モードであれば、開発者は、プレビューウィンドウ内のアクティビティ（Ｃｏｎｓｔｒａｉｎｅｄと呼ばれる）をクリックすることができる。プロパティブラウザは、特定のアクティビティにより通常は公開されるプロパティに加えて、使用可能および使用不可ルールオプション（例えば、プレビューモードに類似）を表示する。ＣＡＧデザイナは、以下に示されている複数の追加メニューオプションを備える。

Ｐｒｅｖｉｅｗ Ａｃｔｉｖｉｔｙ：選択されたアクティビティが与えられると、ＣＡＧは設計モードからプレビューモードに切り換わる。

Ｅｄｉｔ Ａｃｔｉｖｉｔｙ：選択されたアクティビティが与えられると、ＣＡＧはプレビューモードから設計モードに切り換わる。

Ｖｉｅｗ Ｐｒｅｖｉｏｕｓ Ａｃｔｉｖｉｔｙ：フィルムストリップ内で現在選択されているアクティビティの直前のアクティビティに移動する。ＣＡＧフィルムストリップ内の第１のアクティビティに達すると、このメニューオプションは無効にされる。

Ｖｉｅｗ Ｎｅｘｔ Ａｃｔｉｖｉｔｙ：フィルムストリップ内で現在選択されているアクティビティの直後のアクティビティに移動する。ＣＡＧフィルムストリップ内の最後のアクティビティに達すると、このメニューオプションは無効にされる。

一実施形態では、ＣＡＧ内のそれぞれのアクティビティは「制約アクティビティ」の中にラップされる。これは、その後、ＣＡＧのフィルムストリップを介して開発者に公開される。ＣＡＧがプレビューモードに入っており、開発者がこのアクティビティを選択して、それをコピーした場合、貼り付けられる（したがって、その結果のコンテキストメニューが有効にされる）唯一の場所は一実施形態において他のＣＡＧ内である。しかし、開発者がＣＡＧモードを「Ｄｅｓｉｇｎ」に切り換えて、プレビューペイン内でアクティビティを選択した場合、コピー、貼り付け、およびドラッグ＆ドロップは、他のアクティビティと同様に有効にされる。
Ｔａｓｋ
１つまたは複数のプリンシパルにより実行される外部作業単位をモデル化する。
Ｅｖｅｎｔ Ｄｒｉｖｅｎ
実行が「イベント」アクティビティによりトリガされるアクティビティをラップする。
Ｌｉｓｔｅｎ
ｎ個の子ＥｖｅｎｔＤｒｉｖｅｎアクティビティの１つを条件付きで実行する。
Ｅｖｅｎｔ Ｈａｎｄｌｅｒｓ
ＥｖｅｎｔＨａｎｄｌｅｒｓアクティビティは、単純に、ＥｖｅｎｔＤｒｉｖｅｎアクティビティの集合を保持し、これを関連するＳｃｏｐｅが使用する。
Ｅｘｃｅｐｔｉｏｎ Ｈａｎｄｌｅｒ
スコープに対するキャッチブロックを表すメタデータでアクティビティをラップする。
Ｅｘｃｅｐｔｉｏｎ Ｈａｎｄｌｅｒｓ
ＥｘｃｅｐｔｉｏｎＨａｎｄｌｅｒアクティビティの順序付き集合をラップする。
Ｃｏｍｐｅｎｓａｔｅ
完了した子スコープを補正する。
Ｃｏｍｐｅｎｓａｔｉｏｎ Ｈａｎｄｌｅｒ
スコープに対する補正ハンドラとして定義されている子アクティビティをラップする。
Ｓｃｏｐｅ
スコープは、トランザクション境界、例外処理境界、補正境界、イベント処理境界、およびメッセージ、変数、相関関係集合、およびチャネル宣言の境界（つまり、共有データ状態）である。Ｓｃｏｐｅ内のアクティビティの実行は順次であり、したがって、含まれているアクティビティは、Ｓｅｑｕｅｎｃｅの場合のように、スコープが構築されたときに明示的に順序付けられる。
Ｓｃｈｅｄｕｌｅ
Ｓｃｈｅｄｕｌｅは、オーケストレーションエンジンが実行する唯一の最上位レベルのアクティビティである。
複合アクティビティ
制御フローを使用可能にする複合アクティビティ型は、Ｓｅｑｕｅｎｃｅ、Ｐａｒａｌｌｅｌ、Ｃｏｎｓｔｒａｉｎｅｄ Ａｃｔｉｖｉｔｙ Ｇｒｏｕｐ、Ｃｏｎｄｉｔｉｏｎａｌ、Ｗｈｉｌｅ、Ｌｉｓｔｅｎである。さらに、ＳｃｏｐｅおよびＳｃｈｅｄｕｌｅは、中にあるアクティビティの暗黙のシーケンス動作を含むコンテナとして動作する複合アクティビティ型である。

タスクおよび制御フロー複合アクティビティを含むワークフローの実施例を示す図である。 アクティビティ継承ツリーの実施例を示す図である。 コンポーネントモデルの実施例を示す図である。 コンポーネントモデルのライフサイクルの例を示す図である。 フローベースのワークフロー内の制約されたアクティビティグループを例示するブロック図である。 ワークフローの指定にウィザードに依存する、ワークフローオーサリングするための高水準アプリケーションユーザインターフェイスを示す図である。 ワークフローデザイナの実施例を示す図である。 送信アクティビティが後に続く受信アクティビティを含むオーケストレーションプログラムを示す図である。 スケジュール定義およびビジュアルワークフローと、ワークフローのＸＯＭＬによるシリアライゼーションされた表現と、ワークフローのコードビサイドとの間の関係を示す図である。 本発明を実装することができる１つの好適なコンピューティングシステム環境の一実施例を示すブロック図である。

符号の説明

１３０ コンピュータ
１５４ ハードディスクドライブ
１５６ 磁気ディスクドライブ
１６０ 光ディスクドライブ
１７８ モデム
１８８ モニタ
１９４ リモートコンピュータ

Claims (20)

1. ワークフローモデルを表すコンピュータにより実装されるシステムであって、
   構造化された複数のアクティビティを有するワークフローであって、それぞれ制約が関連付けられている、構造化されていない複数のアクティビティを含むワークフローと、
   ランタイムエンジンであって、
   前記構造化された複数のアクティビティの各々を実行し、
   前記構造化されていない複数のアクティビティの各々について前記制約を評価し、
   関連付けられている前記制約の評価に応じて前記構造化されていない複数のアクティビティの各々を実行する
   ことにより前記ワークフローを実行するランタイムエンジンと
   を備えたことを特徴とするコンピュータにより実装されるシステム。
2. 前記制約は、完了意味論を含むことを特徴とする請求項１に記載のコンピュータにより実装されるシステム。
3. 前記制約は、入力パラメータを有し、前記ランタイムエンジンは、
   前記入力パラメータの変更を識別し、
   前記制約を再評価する
   ことにより前記ワークフローをさらに実行することを特徴とする請求項１に記載のコンピュータにより実装されるシステム。
4. 前記構造化された複数のアクティビティのうちの１つは、前記構造化されていない複数のアクティビティのうちの１つを含むことを特徴とする請求項１に記載のコンピュータにより実装されるシステム。
5. 表示領域と、
   前記構造化された複数のアクティビティを表示する前記表示領域のフローベースの領域と、
   前記構造化されていない複数のアクティビティを表示する前記表示領域のフローベースの領域内の制約ベースの領域と
   をさらに備えたことを特徴とする請求項１に記載のコンピュータにより実装されるシステム。
6. 前記ユーザに対し、前記構造化された複数のアクティビティおよび前記構造化されていない複数のアクティビティを提示する手段をさらに備えたことを特徴とする請求項１に記載のコンピュータにより実装されるシステム。
7. 前記ユーザから、前記構造化された複数のアクティビティの選択、前記構造化されていない複数のアクティビティの選択、および前記選択されたアクティビティに関連付けられたフロー指定を受け取る手段をさらに備えたことを特徴とする請求項１に記載のコンピュータにより実装されるシステム。
8. 前記ワークフローを作成するための前記フロー指定に従って前記構造化された複数のアクティビティの選択および前記構造化されていない複数のアクティビティの選択をグループ化する手段をさらに備えたことを特徴とする請求項７に記載のコンピュータにより実装されるシステム。
9. 前記作成されたワークフローを実行する手段をさらに備えたことを特徴とする請求項８に記載のコンピュータにより実装されるシステム。
10. ビジネスプロセスを表すワークフローをモデル化するための方法であって、
    複数のアクティビティをユーザに提示するステップと、
    前記ユーザから前記提示されたアクティビティの選択およびそれに関連付けられたフロー指定を受け取るステップと、
    前記受け取ったフロー指定に従ってアクティビティの前記受け取った選択をグループ化するステップと、
    前記ユーザから前記提示されたアクティビティの他の選択およびそれに関連付けられた制約を受け取るステップと、
    ワークフローを作成するために前記提示されたアクティビティの前記受け取った他の選択とアクティビティの前記グループ化された選択とをマージするステップと
    を備えたことを特徴とする方法。
11. 前記制約を定義するステップをさらに備えたことを特徴とする請求項１０に記載の方法。
12. 前記制約を評価するステップと、
    前記評価に応じて前記提示されたアクティビティの前記他の選択から前記アクティビティを実行することにより前記作成されたワークフローを実行するステップと
    をさらに備えたことを特徴とする請求項１０に記載の方法。
13. 前記フロー指定に従ってアクティビティの前記受け取った選択で前記アクティビティを実行することにより前記作成されたワークフローを実行するステップをさらに備えたことを特徴とする請求項１０に記載の方法。
14. 前記複数のアクティビティを前記ユーザに提示するステップは、前記複数のアクティビティをディスプレイ上に表示するステップを含むことを特徴とする請求項１０に記載の方法。
15. １つまたは複数のコンピュータ読み取り可能媒体は、請求項１０に記載の方法を実行するコンピュータ実行可能命令を有することを特徴とする請求項１０に記載の方法。
16. フローベースの領域および制約ベースの領域を持つワークフローをモデル化するコンピュータ実行可能コンポーネントを含む１つまたは複数のコンピュータ読み取り可能媒体であって、前記コンポーネントは、
    複数のアクティビティをユーザに提示する表示コンポーネントと、
    前記ユーザから、前記提示されたアクティビティの選択およびそれに関連付けられたフロー指定を受け取るインターフェイスコンポーネントであって、前記ユーザから、前記提示されたアクティビティの他の選択およびそれぞれに関連付けられた制約をさらに受け取るインターフェイスコンポーネントと、
    前記受け取ったフロー指定に従ってアクティビティの前記受け取った選択をグループ化するデザイナコンポーネントであって、ワークフローを作成するための前記提示されたアクティビティの前記受け取った他の選択とアクティビティの前記グループ化された選択とをさらにマージするデザイナコンポーネントと
    を備えたことを特徴とするコンピュータ読み取り可能媒体。
17. 前記制約を評価し、
    前記評価に応じて前記提示されたアクティビティの前記他の選択から前記アクティビティを実行する
    ことにより前記作成されたワークフローを実行するランタイムコンポーネントをさらに備えたことを特徴とする請求項１６に記載のコンピュータ読み取り可能媒体。
18. 前記フロー指定に従ってアクティビティの前記受け取った選択から前記アクティビティを実行することにより、前記作成されたワークフローを実行するランタイムコンポーネントをさらに備えたことを特徴とする請求項１６に記載のコンピュータ読み取り可能媒体。
19. 前記表示コンポーネント、前記インターフェイスコンポーネント、および前記デザイナコンポーネントは、アプリケーションプログラムの実行環境内で実行されることを特徴とする請求項１６に記載のコンピュータ読み取り可能媒体。
20. 前記制約は、完了意味論を含むことを特徴とする請求項１６に記載のコンピュータ読み取り可能媒体。
    
    

Images