(57)【要約】【課題】  コンポーネント化されたワークフローモデルのビルド機能を提供すること。【解決手段】  ワークフローの各ステップは、ワークフローステップの設計時の態様、コンパイル時の態様、および実行時の態様を記述するメタデータを持つアクティビティとしてモデル化される。ユーザは、ユーザインターフェイスまたはアプリケーションプログラミングインターフェイスを介してワークフローを作成するアクティビティを選択し、配置する。ワークフロー内のアクティビティのそれぞれに関連付けられたメタデータが収集され、ワークフローの永続的表現を作成する。ユーザは、カスタムアクティビティをオーサリングすることによりワークフローモデルを拡張する。ワークフローは、コンパイルして実行することができる。【選択図】  図１
2006107477.tif 000002
【特許請求の範囲】
【請求項１】
ビジネスプロセスをモデル化するワークフローをオーサリングするためのコンピュータシステムであって、
ワークフローに関連付けられた複数のアクティビティを識別するパッケージと、
前記複数のアクティビティのうち１つまたは複数を選択し、相互関連付けるためのインターフェイスと、
前記ワークフローの永続的表現を作成する前記識別されたアクティビティをシリアライズするシリアライザとを備えることを特徴とするコンピュータシステム。
【請求項２】
さらに、
前記ワークフローをオーサリングするためのデザインアプリケーションプログラミングインターフェイスであって、前記複数のアクティビティのそれぞれがそれと関連付けられたコンポーネントモデルを備え、前記コンポーネントモデルはそれと関連付けられたアクティビティのプロパティを指定する、デザインアプリケーションプログラミングインターフェイスと、
前記デザインアプリケーションプログラミングインターフェイスを介してオーサリングされた前記ワークフローをコンパイルするためのコンパイルアプリケーションプログラミングインターフェイスとを備えることを特徴とする請求項１に記載のコンピュータシステム。
【請求項３】
前記指定されたプロパティは、設計時ビヘイビア、コンパイル時ビヘイビア、および実行時ビヘイビアのうちの１つまたは複数を含み、
前記複数のアクティビティは、ユーザ定義アクティビティを含み、前記ユーザ定義アクティビティは１つまたは複数のプロパティを備え、さらに前記プロパティのそれぞれに関連付けられた形式を検証するための意味チェッカーを備えることを特徴とする請求項１または２に記載のコンピュータシステム。
【請求項４】
前記インターフェイスは、前記選択されたアクティビティに関連付けられているビジネスロジックを実装するソフトウェアコードを受け取り、さらに、前記シリアライズされたワークフロー表現および前記ソフトウェアコードを前記ワークフローの実行可能表現にコンパイルするコンパイラを備え、さらに、前記コンパイラにより作成された前記ワークフローの前記実行可能表現を実行するランタイムエンジンを備えることを特徴とする請求項１乃至３のいずれかに記載のコンピュータシステム。
【請求項５】
前記デザインアプリケーションプログラミングインターフェイスは、前記ワークフローをオーサリングする手段および前記アクティビティのうちの１つまたは複数を選択して前記ワークフローを作成する手段を備え、前記コンパイルアプリケーションプログラミングインターフェイスは、
前記ワークフローのビジュアル表現をカスタマイズする手段と、
前記デザインアプリケーションプログラミングインターフェイスを介してオーサリングされた前記ワークフローをコンパイルする手段と、
前記ワークフローの妥当性を確認する手段と、
前記ワークフローをシリアライズする手段のうちの１つまたは複数を備えることを特徴とする請求項１乃至４のいずれかに記載のコンピュータシステム。
【請求項６】
さらに、前記ワークフロー内の前記複数のアクティビティのそれぞれに型を関連付けるためのタイププロバイダアプリケーションプログラミングインターフェイスを備え、前記タイププロバイダアプリケーションプログラミングインターフェイスは、前記ワークフロー内の前記複数のアクティビティのそれぞれに前記型を関連付ける手段を備えることを特徴とする請求項１乃至５のいずれかに記載のコンピュータシステム。
【請求項７】
さらに、前記ワークフロー内の前記アクティビティのそれぞれに関連付けられた前記コンポーネントモデルを表すデータ構造体を含み、前記データ構造体は、
前記アクティビティを視覚的に表すためのデータを格納する画像フィールドと、
前記アクティビティに関連付けられているプロパティ、メソッド、およびイベントを定義するメタデータを格納する１つまたは複数の作者時刻フィールドと、
前記作者時刻フィールドに格納されている前記メタデータを前記アクティビティの宣言的表現に移行するためのデータを格納するシリアライザフィールドと、
前記作者時刻フィールドに格納されている前記メタデータに関連付けられているソフトウェアコードを格納するビジネスロジックフィールドと、
前記ビジネスロジックフィールドに格納されている前記ソフトウェアコードを実行するためのデータを格納するエグゼキュータフィールドとを含み、
前記意味チェッカーは、前記ビジネスロジックフィールドに格納されている前記ソフトウェアコードの妥当性を確認することを特徴とする請求項１乃至６のいずれかに記載のコンピュータシステム。
【請求項８】
アクティビティを含みビジネスプロセスをモデル化するワークフローをモデル化するためのコンピュータにより実装される方法であって、
複数のアクティビティを提示することと、
ユーザによる前記提示されたアクティビティの選択を受け取ることと、
前記受け取った選択をシリアライズし、前記ワークフローの永続的表現を作成することとを含むことを特徴とするコンピュータにより実装される方法。
【請求項９】
さらに、
前記ワークフローに関連付けられたスケジュールを作成するためのスケジュールインターフェイスを提供することと、
前記スケジュールに関連付けられたスコープを作成するためのスコープインターフェイスを提供することと、
１つまたは複数のアクティビティを選択するためのアクティビティインターフェイスを提供することと、
前記選択されたアクティビティを配列し、前記作成されたスケジュール内にワークフローを作成して、前記作成されたスコープ内で実行することとを含むことを特徴とする請求項８に記載のコンピュータにより実装される方法。
【請求項１０】
さらに、
ユーザからビジネスロジックを表すソフトウェアコードを受け取り、前記複数のアクティビティのうちの１つに関連付けることと、
前記ソフトウェアコードをコンパイルして１つまたは複数のバイナリファイルを作成することと、
前記作成されたバイナリファイルを実行して、前記ワークフローを実行することとを含むことを特徴とする請求項８または９に記載のコンピュータにより実装される方法。
【請求項１１】
さらに、
前記複数のアクティビティのそれぞれに対するメタデータをそれに関連付けられたコンポーネントモデルから受け取るためのメタデータインターフェイスを提供し、前記受け取ったメタデータは意味論を持つことと、
前記受け取ったメタデータに関連付けられている前記意味論を調べることにより前記受け取ったメタデータの妥当性を確認するための妥当性確認インターフェイスを提供することと、
前記妥当性確認の結果に応じて、前記受け取ったメタデータに関連付けられているソフトウェアコードを生成するためのコードジェネレータインターフェイスを提供することと、
前記生成されたソフトウェアコードをコンパイルするためのコードコンパイルインターフェイスを提供することとを含むことを特徴とする請求項８乃至１０のいずれかに記載のコンピュータにより実装される方法。
【請求項１２】
さらに、
前記配列されたアクティビティをコンパイルして、実行可能ワークフローを作成することと、
前記作成されたスケジュールに応じて、前記作成されたスコープ内で、前記作成されたワークフローを実行することとを含むことを特徴とする請求項８乃至１１のいずれかに記載のコンピュータにより実装される方法。
【請求項１３】
さらに、
前記シリアライズされたワークフロー表現およびソフトウェアコードを前記ワークフローの実行可能表現を含む単一のアセンブリにコンパイルすることと、
前記配列されたアクティビティのそれぞれに関連付けるための前記コンポーネントモデルを提供し、前記コンポーネントモデルは前記配列されたアクティビティのプロパティを定義することと、
前記シリアライズされたワークフロー表現を他のワークフロー言語に変換することのうちの１つまたは複数を含むことを特徴とする請求項８乃至１２のいずれかに記載のコンピュータにより実装される方法。
【請求項１４】
さらに、
前記ユーザからユーザ定義アクティビティを受け取り、前記ユーザ定義アクティビティはそれに関連付けられた１つまたは複数の意味論を持つことと、
定義済みインターフェイス要件への適合を調べるために前記意味論を評価することと、
前記ユーザ定義アクティビティを前記評価の結果に応じて前記複数のアクティビティのうちの１つとして提示することとを含むことを特徴とする請求項８乃至１３のいずれかに記載のコンピュータにより実装される方法。
【請求項１５】
前記複数のアクティビティを提示することは、
設計時、コンパイル時、および実行時ビヘイビアを指定するそれぞれ関連付けられた１つまたは複数のプロパティを持つ前記複数のアクティビティを提示することと、
前記ユーザに対して前記複数のアクティビティを視覚的に提示することのうちの１つまたは複数を含むことを特徴とする請求項８乃至１４のいずれかに記載のコンピュータにより実装される方法。
【請求項１６】
さらに、前記ユーザから前記選択されたアクティビティの階層的編成結果を受け取ることを含み、前記受け取った階層的編成結果は、イベント−条件−アクションワークフロー、構造化ワークフロー、および制約駆動ワークフローのうちの１つまたは複数を含むことを特徴とする請求項８乃至１５のいずれかに記載のコンピュータにより実装される方法。
【請求項１７】
アクティビティを含む、ビジネスプロセスをモデル化するワークフローをモデル化するコンピュータ実行可能コンポーネントを含む１つまたは複数のコンピュータ可読媒体であって、前記コンピュータ実行可能コンポーネントは、
複数のアクティビティを提示するためのパレットコンポーネント（４０２）と、
前記パレットコンポーネント（４０２）により提示される前記アクティビティの選択および階層的編成結果をユーザから受け取るためのインターフェイスコンポーネント（４０４）と、
前記インターフェイスコンポーネント（４０４）が受け取る前記アクティビティをシリアライズし、前記ワークフローの永続的表現を作成する宣言的コンポーネント（４０６）とを含むことを特徴とするコンピュータ可読媒体。
【請求項１８】
前記インターフェイスコンポーネント（４０４）は、さらに、ユーザからビジネスロジックを表すソフトウェアコードを受け取り、前記複数のアクティビティの１つに関連付け、さらに、前記宣言的コンポーネント（４０６）によりシリアライズされた前記ワークフロー表現および前記インターフェイスコンポーネント（４０４）で受け取った前記ソフトウェアコードを前記ワークフローの実行可能表現を含む単一のアセンブリにコンパイルするランタイムコンポーネント（４０８）を含むことを特徴とする請求項１７に記載のコンピュータ可読媒体。
【請求項１９】
前記宣言的コンポーネント（４０６）は、さらに、前記シリアライズされたアクティビティをバリデーションのため拡張可能スキーマ定義名前空間にマッピングすることを特徴とする請求項１７または１８に記載のコンピュータ可読媒体。
【請求項２０】
さらに、アプリケーションプログラム内で前記パレットコンポーネント（４０２）、インターフェイスコンポーネント（４０４）、および宣言的コンポーネント（４０６）をホスティングすることを含むことを特徴とする請求項１７乃至１９のいずれかに記載のコンピュータ可読媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、ワークフローモデリングの分野に関係する。特に、本発明の実施形態は、コンポーネント化された拡張可能ワークフローモデル（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)
一実施例では、ユーザはスケジュールは作成し、それをアクティビティとしてコンパイルする。コンパイルに成功すると、スケジュールはツールボックス上に表示される。ユーザは、コンパイルされたスケジュールの使用が望ましいスケジュールを開くか、または作成する。ユーザは、ツールボックスからコンパイル済みスケジュールをドラッグ＆ドロップする。縮小されたスケジュールデザイナがデザインサーフェスに示される。ユーザがドロップされたコンパイル済みスケジュールのコンテンツを表示したい場合、ユーザはそのスケジュールデザイナを展開して、呼び出されたスケジュールのコンテンツを読み取り専用状態でインライン表示する。呼び出されたスケジュールのインライン化により、ユーザはスケジュールデザイナ同士を切り換えなくても呼び出されたスケジュールを表示することができる。この機能は、既存のスケジュールを再利用して上位スケジュールを作成する開発者に有用な機能である。
【００４４】
テーマ／スキンを使用したデザイナフレームワークのカスタマイズのサポート  
デザイナフレームワークを使用して書かれたワークフローデザイナは、ワークフローテーマを使用してカスタマイズすることができる。これらは、デザイナのさまざまな態様を宣言的に記述する拡張マークアップ言語（ＸＭＬ）ファイルとすることができる。ワークフローデザイナは、アクティビティを拡張するパートナのサポートをウィザードで対応している。ワークフローデザイナによりサポートされるユーザインターフェイス機能の例として、限定はしないが、元に戻す／繰り返し、ドラッグ／ドロップ、切り取り／コピー／貼り付け、ズーム、パン、検索／置換、ブックマーク、装飾、バリデーションエラー用のスマートタグ、アクティビティ用の有効なドロップターゲットインジケータ、自動レイアウト、ビューページ付け、ナビゲーションマーカー、ドラッグインジケータ、ヘッダ／フッタ付き印刷およびプレビュー、およびドキュメントアウトライン統合がある。ワークフローデザイナは、ＸＭＬメタデータを使用してデザイナのルック＆フィールをカスタマイズできるカスタムデザイナテーマ／スキンをサポートする。ワークフローデザイナでは、バックグラウンドコンパイルをサポートする。一実施例では、スケジュールを設計しながらバリデーションエラーを調べるスマートタグおよびスマートアクションが用意される。ワークフローデザイナは、任意のコンテナ（例えば、アプリケーションプログラム、シェルなど）でホスティングすることができる。
【００４５】
オーケストレーションエンジンプログラムの一実施例は、送信はアクティビティが後に続く受信アクティビティを含む。このプロセスでは、メッセージを受信して、送出する。ユーザは、「Ｈｅｌｌｏ  Ｗｏｒｌｄ」と呼ばれるプロジェクトを作成して、オーケストレーションアイテムをプロジェクトに追加する。ユーザは、その後、スコープアクティビティをデザインサーフェス上にドラッグ＆ドロップする。次に、ユーザは、送信アクティビティが後に続く受信アクティビティをスコープ上にドロップする。図７は、デザイナ内の結果として得られるワークフロー７００を例示している。それぞれのアクティビティデザイナは、オブジェクトモデル上のユーザインターフェイス表現を提供する。開発者は、オブジェクトモデルを直接プログラムして、アクティビティのプロパティを設定するか、またはデザイナを使用することができる。オーケストレーションエンジンデザイナを使用することにより、開発者はツールボックスからアクティビティを選択し、それをデザイナサーフェス上にドラッグすることができる。アクティビティがすでにスケジュールに入れられており、移動する必要がある場合、開発者は、それを選択して（それをクリックすることにより）、そのアクティビティを入れる必要のあるスケジュールの領域にドラッグすることができる。開発者がコントロールキーを押しながらドラッグ＆ドロップを行うと、選択されたアクティビティのコピーが作成される。
【００４６】
アクティブな配置では、可能なドロップポイント（ターゲット）をデザインサーフェス上にビジュアルインジケータとして用意する。自動スクロール機能も、ドラッグ＆ドロップのコンテキスト内で関与する。大きなスケジュールを取り扱う場合、現在ビューポート内にないデザイナの領域へのナビゲーションは、入れるスケジュールの領域に向かってアクティビティをドラッグすることによりアクセス可能である。
【００４７】
ドラッグ＆ドロップは、同じプロジェクト内のスケジュール間で、また同じソリューション内の他のプロジェクト内のスケジュール間でサポートされる。アクティビティがデザインサーフェス上に配置された後、開発者はそのアクティビティの構成を設定する。各アクティビティは、スケジュールが有効なものとなるように開発者が構成する一連のプロパティを持つ。これらのプロパティは、プロパティブラウザで編集可能である。すべてのアクティビティは、プロパティブラウザ内にどのようなプロパティを表示できるかを制御する。開発者がさまざまなアクティビティを構成するのを補助するため、デザイナはさまざまなダイアログまたは「サブデザイナ」を備えている。ダイアログは、それぞれ、アクティビティのさまざまなプロパティについて呼び出される。
【００４８】
オーケストレーションエンジンは、ツールボックス内に提示されるアクティビティをカスタマイズすることができる。開発者がカスタムアクティビティまたはスケジュールを作成する場合、最終結果はアセンブリである。ダイアログを使用することにより、開発者は、アセンブリロケーションに移動してブラウズし、そのアセンブリを選択してオーケストレーションエンジンアクティビティとして現れるようにすることができる。それとは別に、開発者は、オーケストレーションエンジンのインストールパス内にそのアセンブリを置くことができ、オーケストレーションエンジンアクティビティとして存在することになる。
【００４９】
アプリケーションプログラミングインターフェイス（ＡＰＩ）  
他の実施形態では、本発明は、さまざまなワークフローオペレーションを実行するためのアプリケーションプログラミングインターフェイス（ＡＰＩ）を備える。本発明は、ワークフローをオーサリングするためのデザインアプリケーションプログラミングインターフェイスを含む。デザインアプリケーションプログラミングインターフェイスは、ワークフローをオーサリングする手段およびアクティビティのうちの１つまたは複数を選択してワークフローを作成する手段を備える。本発明は、さらに、デザインアプリケーションプログラミングインターフェイスを介してオーサリングされたワークフローをコンパイルするためのコンパイルアプリケーションプログラミングインターフェイスも含む。コンパイルアプリケーションプログラミングインターフェイスは、ワークフローをシリアライズする手段、ワークフローの視覚的な表示をカスタマイズする手段、デザインアプリケーションプログラミングインターフェイスを介してオーサリングされたワークフローをコンパイルする手段、ワークフローの妥当性確認を行う手段を含む。
【００５０】
本発明は、さらに、型をワークフロー内のアクティビティのそれぞれに関連付けるためのタイププロバイダアプリケーションプログラミングインターフェイスも含む。タイププロバイダアプリケーションプログラミングインターフェイスは、型をワークフロー内のアクティビティのそれぞれに関連付ける手段および型をワークフロー内のアクティビティのそれぞれに関連付ける手段を含む。
【００５１】
付録Ｄは、ＡＰＩのいくつかの実施例を説明する付録である。付録ＤのＡＰＩは、ワークフローをオーサリングする手段の実施例、アクティビティの１つまたは複数を選択してワークフローを作成する手段の実施例、ワークフローをシリアライズする手段の実施例、ワークフローの視覚的表示をカスタマイズする手段の実施例、ワークフローの妥当性確認を行う手段の実施例、ワークフローをコンパイルする手段の実施例、および型をワークフロー内のアクティビティのそれぞれに関連付ける手段の実施例を含む。
【００５２】
アクティビティ実行フレームワーク  
スケジュールおよびスコープを除き、エンジンは、アクティビティを抽象エンティティとして表示し、単に、特定のアクティビティの特定のデータまたは意味論を知らずにアクティビティの実行を簡単に調整する。一実施形態では、４つのエンティティは、アクティビティ自体、実行中のアクティビティの親アクティビティ、実行中のアクティビティを閉じるスコープ、およびオーケストレーションエンジンの実行中にやり取りをする。それぞれのエンティティは異なる関数を持つ。
【００５３】
完了をアクティビティコーディネータに知らせることなくアクティビティの実行メソッドが戻る場合、そのアクティビティは、論理的待ち状態にあると識別される。このようなアクティビティは、オーケストレーションエンジンによりキャンセルするか、または継続することができる（例えば、待っているアイテムまたはイベントが利用可能になるか、または実行され、エンジンによりこれにアクティビティが通知された後）。
【００５４】
論理的待ち状態に決して入らないいくつかのアクティビティは、決してキャンセルできない。実施例は、送信アクティビティおよびコードアクティビティを含むが、これらは外部イベントまたはサブスクリプションへの要求なしで実行されるからである。スレッドを渡された後（つまり、実行メソッドがオーケストレーションエンジンにより呼ばれた後）、これらのアクティビティは完了するまで動作し続ける。完了を通知するまでスレッドを返さないので、オーケストレーションエンジンにはキャンセルする機会が決して与えられない。
【００５５】
オーケストレーションエンジンのランタイムは、ルールを使用して、オーケストレーションエンジンアクティビティが実行されるイベントをトリガする。オーケストレーションエンジンデザイナは、関連付けられたルールを実行時に評価し、イベントを取り出するユーザ機能を提供する。オーケストレーションエンジンデザイナを利用することで、ユーザは、拡張性アーキテクチャを用意することによりさまざまな種類のルール技術を使用できる。デザイナは、使用されるルールの型には関知しない。
【００５６】
一実施形態では、デザイナは、ルールをアクティビティに関連付ける手段として論理式ハンドラをサポートしている。これは、ユーザコードファイル内で、ユーザが値ｔｒｕｅまたはｆａｌｓｅを返すメソッドを書くことを意味し、それに基づいてルールがトリガされる。現在、Ｉｎｆｏ  ＡｇｅｎｔおよびＢｕｓｉｎｅｓｓ  Ｒｕｌｅｓ  Ｅｎｇｉｎｅ（ＢＲＥ）を含むルールを評価するために使用することもできる複数の技術がある。これを達成するために、デザイナは、ルール技術開発者がデザイナでカスタムユーザインターフェイスをホスティングできるようにする拡張性アーキテクチャを備える。デザイナは、コードステートメントコレクションの形でルールをシリアライズするカスタムユーザインターフェイスライター向けの手段を用意している。デザイナは、コードステートメントコレクションが中に挿入されているユーザコードファイル内にブールハンドラを生成し出力する。オーケストレーションエンジンは、ルールライターにより使用することもできる既定のユーザインターフェイスを含む。ルール技術プロバイダは、カスタムルール宣言を作成し、そのカスタムルール宣言に関連付けられたユーザインターフェイスタイプエディタを書き、ルールユーザインターフェイスをホスティングするカスタムユーザインターフェイスを作成し、保存後にコードステートメントを生成することによりオーケストレーションエンジンデザイナにルールを追加する。
【００５７】
一実施例では、ユーザは、ルールがアタッチされる必要のあるアクティビティデザイナを選択し、プロパティブラウザでルールプロパティを特定し、ドロップダウン内の「ＲｕｌｅＥｘｐｒｅｓｓｉｏｎＨａｎｄｌｅｒ」を選択し（「Ｓｔａｔｅｍｅｎｔｓ」プロパティがユーザインターフェイス内のＲｕｌｅ  Ｐｒｏｐｅｒｔｙの下に表示されるようにする）、「Ｓｔａｔｅｍｅｎｔｓ」プロパティ内のユーザコードメソッド名を指定し、ユーザインターフェイスタイプエディタを呼び出してルール特有のユーザインターフェイスをホスティングするダイアログを呼び出し、新しい述語行を作成しそれらをグループ化することによりダイアログ内でルールを定義する。ユーザインターフェイスは、ユーザコードファイルにメソッドを生成して出力する。メソッド名は、プロパティブラウザでユーザが指定したのと同じものである。ルールを作成することに相当するコードステートメントが、ルール用のユーザコードメソッド内に挿入される。
【００５８】
実行時のメッセージング  
実行ワークフローでは、スケジュールに送られるメッセージは、特定のスケジュールインスタンス向けである。例えば、発注書＃１２３に対するインボイスをその発注書を発信した（例えば、送出した）のと同じスケジュールインスタンスに送り返さなければならない。受信メッセージと適切なスケジュールインスタンスとを照合するために、メッセージおよびスケジュールインスタンスは相関関係集合を共有する。相関関係集合は、メッセージ内の識別子フィールドがスケジュールインスタンスにより保持される同じ型の識別子と突き合わせて照合されることを意味する一価相関関係集合でよい。多プロパティ相関関係集合も、可能であり、データベーステーブル内の複数列主キーに類似している。
【００５９】
スケジュールインスタンスにより保持されている相関関係集合の値は、スケジュールインスタンスがメッセージを送出するか（例えば、値は送信発注書の識別子フィールドから取り出せる）、またはメッセージを受信するときに初期化される。その後、この相関関係集合値は、そのスケジュールインスタンスの状態の一部となる。後続の受信メッセージが到着すると、スケジュールインスタンス状態で保持されている相関関係集合値は、予想される型の受信メッセージにより保持されている識別子と突き合わせて照合される。一致が見つかった場合、相関関係集合は満たされ、メッセージがスケジュールインスタンスに配送される。
【００６０】
相関関係集合の実装はオーケストレーションエンジンおよびホスト環境に左右されるが、一実施形態では、ユーザは相関関係集合を宣言してスケジュールインスタンスを正しく動作するようにする。他の実施形態では、いくつかのアクティビティ（例えば、ＳｅｎｄＲｅｑｕｅｓｔ／ＲｅｃｅｉｖｅＲｅｓｐｏｎｓｅアクティビティおよびＲｅｃｅｉｖｅＲｅｑｕｅｓｔ／ＳｅｎｄＲｅｓｐｏｎｓｅアクティビティ）は、ユーザと無関係に相関関係集合をセットアップする。送信および受信アクティビティにより広範にわたるバリデーションチェックが実行され、相関関係集合が正しく初期化され、追随されるようにする。
【００６１】
実行ワークフローの動的編集  
オーケストレーションエンジンは、さまざまな種類のワークフローをオーサリングする（そして、その後、ビジュアル化し、実行する）ためのフレームワークを提供する。実施例としては、ｅｖｅｎｔ−ｃｏｎｄｉｔｉｏｎ−ａｃｔｉｏｎ（ＥＣＡ）スタイルのワークフローまたは構造化フローまたはルール駆動フローがある。さらに、ワークフローのモデル化方法に関係なく、フレームワークにより、ユーザは設計時と同じ方法で、またはワークフロープロセスを再コンパイルしなくてもワークフロープロセスが実行しているときであってもワークフローをオーサリングまたは編集することができる。フレームワークを使用すると、ユーザはランタイムと高忠実度の設計時表現との間のラウンドトリッピングが可能になる。アドホックな変更は、プロセスモデルに対し実行時に加えられる変更である。ユーザは、そのスケジュールモデルを実行インスタンスに問い合わせ、モデルに変更を加えることができる。例えば、ユーザは、バッチ式でアクティビティの追加、削除、または置換を行うことができ、その後、バッチ変更をコミットまたはロールバックすることができる。一実施形態では、モデルは更新の後に妥当性確認が行われる。本発明の多くのワークフローシナリオでは、「設計時オーサリング」および「ランタイム実行」との間の分離のぼかし、またはさらには除去がある。
【００６２】
スケジュールインスタンスは、実際に、それらのインスタンスのスケジュール型について定義されているアクティビティ型（メタデータ）ツリーを他のインスタンスと共有する。しかし、スケジュールインスタンスは、実行を開始した後、新しいアクティビティの追加または宣言的ルールの操作を介してオンザフライで変更できる。そのような修正されたスケジュールインスタンスを取り出し、新しいスケジュール型として「名前を付けて保存」するか、またはより一般的に、インスタンスからシリアライズされた表現を単純に復元することが可能である。つまり、実行スケジュールインスタンスを、シリアライズし、その後、デザイナ（例えば、オーサリング環境）またはランタイムビジュアル化ツールに持ち込むことができる。
【００６３】
さらに、上級開発者は、スケジュールを丸ごとソフトウェアコードとしてオーサリングすることも可能である。スケジュール型を直接オーサリングする場合も、開発者は、単に、スケジュールのコードビサイドクラスのソフトウェアコードにＩｎｉｔｉａｌｉｚｅＳｃｈｅｄｕｌｅＭｏｄｅｌという静的メソッドを入れ、このメソッドに［ＳｃｈｅｄｕｌｅＣｒｅａｔｏｒ］属性でマークするだけである。一実施形態では、静的メソッドは、パラメータを取らず、Ｓｃｈｅｄｕｌｅオブジェクトを返す。随伴するシリアライズされたファイルはないが、スケジュールのシリアライズされた表現は、作成されるＳｃｈｅｄｕｌｅオブジェクトから復元できる。これは、単一のソフトウェアコードファイルを使用してスケジュールを作成できることを意味しているが、バリデーションチェックは、このファイルには実行されえない。オーケストレーションエンジンのコンパイルにより、スケジュール型の基礎となっているアクティビティツリーの構造上および意味論的な有効性が保証される。他の実施形態では、コンパイルおよびバリデーションを内部で実行し、実行される実際の型を生成するが、コードの入力は不要である。スケジュール型のコンパイルは、コンパイル時オブジェクトモデルから実行時オブジェクトモデルへの変換がない分、超軽量なプロセスとなっている。本質的に、コンパイルは、単に、スケジュールのオブジェクトモデル表現をコードビサイドと組み合わせて新しい型を生成するだけである。一実施形態では、基本的に、コンパイル済みコードビサイドがオブジェクトモデル内のアクティビティにより要求される内容と一致するか、またはコードビサイドがコンパイル済みフォーム（アセンブリ）内にすでに存在している可能性がある場合には、特定のスケジュールについてコードビサイドを全く生成する必要はないと考えられる。
【００６４】
シリアライズされたスケジュールをコンパイルする場合、そのスケジュールに対するコードビサイドとして実際に使用される既存のコンパイル済み型を指すことが可能である。このコンパイル済み型の派生型が作成され、この新しい型はコードビサイドとして使用され、一意的な型が新しいスケジュールを表すように作成されることが保証される。
【００６５】
シリアライゼーションアーキテクチャ  
シリアライゼーションインフラストラクチャは、オーケストレーションエンジンのアクティビティツリーをシリアライズする、モジュール方式の、形式に依存しない、容易に拡張可能なメカニズムを提供する。図８は、グラフ内のオブジェクトのシリアライゼーションを示す図である。
【００６６】
特に、呼び出し側（例えば、アプリケーションプログラムまたはユーザ）は、シリアライゼーションマネージャからシリアライザにオブジェクト（またはアクティビティ）Ａを要求する。オブジェクトＡの型のメタデータ属性により、オブジェクトＡは要求された型のシリアライザにバインドされる。次に、呼び出し側は、オブジェクトＡをシリアライズするようにシリアライザに要求する。続いて、オブジェクトＡのシリアライザはオブジェクトＡをシリアライズする。シリアライザは、遭遇するオブジェクト毎に、シリアライズしながら、シリアライゼーションマネージャに追加シリアライザを要求する。シリアライゼーションの結果が呼び出し側に返される。
【００６７】
オーケストレーションエンジンコンポーネントモデル内のすべてのアクティビティは、シリアライゼーションに参加することができる。シリアライザコンポーネントは、一実施形態ではアクティビティクラス自体の一部ではない。その代わりに、このコンポーネントは、アクティビティに関連付けられたクラス内のシリアライザ属性に注釈を入れることにより指定される。シリアライザ属性は、そのアクティビティ型のオブジェクトをシリアライズするために使用されるクラスを指す。他の実施形態では、ある１つのアクティビティ型のプロバイダコンポーネントが、そのアクティビティにより与えられる既定のシリアライザをオーバーライドする。
【００６８】
デザイナシリアライゼーションは、メタデータ、シリアライザ、およびシリアライゼーションマネージャに基づく。メタデータ属性は、型をシリアライザに関係付けるために使用される。「ブートストラッピング」属性は、シリアライザを持たない型に対しシリアライザを提供するオブジェクトをインストールするために使用することができる。シリアライザは、特定の１つの型またはある範囲の複数の型をシリアライズする方法を認識するオブジェクトである。それぞれのデータ形式に対して１つの基本クラスがある。例えば、オブジェクトをＸＭＬに変換する方法を認識するＸｍｌＳｅｒｉａｌｉｚｅｒ基本クラスが考えられる。本発明は、特定のシリアライゼーション形式に関係しない一般的なアーキテクチャである。シリアライゼーションマネージャは、オブジェクトグラフをシリアライズするために使用されるさまざまなシリアライザに対する情報ストアとなるオブジェクトである。例えば、５０個のオブジェクトのグラフは、すべてそれ独自の出力を生成する５０個の異なるシリアライザを持つことができる。シリアライゼーションマネージャを、これらのシリアライザが使用して、必要な場合に互いに通信し合うことができる。
【００６９】
一実施形態では、ジェネリックなオブジェクトメタデータを使用するシリアライザに結合されたシリアライゼーションプロバイダを使用することにより、与えられた型に対するシリアライザを用意する機会がオブジェクトに与えられるコールバックメカニズムを実現する。ＡｄｄＳｅｒｉａｌｉｚａｔｉｏｎＰｒｏｖｉｄｅｒなどのメソッドを通じて、シリアライゼーションマネージャにシリアライゼーションプロバイダを用意することができる。シリアライゼーションプロバイダは、ＤｅｆａｕｌｔＳｅｒｉａｌｉｚａｔｉｏｎＰｒｏｖｉｄｅｒＡｔｔｒｉｂｕｔｅなどの属性をシリアライザに追加することによりシリアライゼーションマネージャに自動的に追加できる。
【００７０】
一実施形態では、オブジェクトはｘｍｌ要素としてシリアライズされる、オブジェクトのプロパティは単純プロパティ（例えば、ｘｍｌ属性としてシリアライズされる）または複合プロパティ（子要素としてシリアライズされる）として分類される、オブジェクトの子オブジェクトは子要素としてシリアライズされる、というルールに従って形式が示される。子オブジェクトの定義は、オブジェクト毎に異なることがある。以下の実施例は、子オブジェクトの１つとしてＳｅｎｄアクティビティを持つ、ｗｈｉｌｅアクティビティのシリアライゼーションである。
【００７１】
【表１】
2006107477.tif 000003
【００７２】
シリアライゼーションに使用される言語がＸＯＭＬである一実施形態では、それぞれのＸＯＭＬ要素は、スケジュールがコンパイルされるときにそれぞれのオブジェクトにシリアライズされる。オブジェクトは、単純型と複合型の両方を含む。各アクティビティのＸＯＭＬ表現の間のマッピングとオーサリングオブジェクトモデルへのマッピングについて、次に説明する。ＸＯＭＬのシリアライゼーションは、プリミティブアクティビティと複合アクティビティとで異なる。
【００７３】
プリミティブアクティビティに対する単純型は、アクティビティタイプに関する属性としてシリアライズされる。プリミティブアクティビティに対する複合型は、子要素としてシリアライズされる。例えば、以下に、ＳｅｎｄアクティビティのＸＯＭＬ表現を示す。
【００７４】
【表２】
2006107477.tif 000004
【００７５】
プリミティブ型のシリアライゼーションと同様に、複合アクティビティに対する単純型は、アクティビティ型に関する属性としてシリアライズされる。しかし、定義により、複合アクティビティはネストされたアクティビティをカプセル化したものである。それぞれのネストされているアクティビティは、他の子要素としてシリアライズされる。例えば、以下に、ＷｈｉｌｅアクティビティのＸＯＭＬ表現を示す。
【００７６】
【表３】
2006107477.tif 000005
【００７７】
プロセス／ワークフロービューとシリアライズされた表現との間に強い関係が存在する。図９は、スケジュール定義およびビジュアルワークフローと、ワークフローのシリアライズされた（例えば、ＸＯＭＬ）表現と、ワークフローのコードビサイドとの間の関係を示す図である。いずれかの表現でオーサリングする場合、他方は変更を招く。そのため、アクティビティ（または複合アクティビティの場合にはその構成要素部分）に対するＸＯＭＬを修正すると、開発者がプロセス／ワークフロービューの切り換えを行うときにプロセス／ワークフロービューに直接反映される。逆も言える。プロセス／ワークフロービュー内のアクティビティを修正すると、ＸＯＭＬ内に適切な修正が生じる。例えば、プロセス／ワークフロービュー内でアクティビティを削除すると、同じアクティビティについてＸＯＭＬ内のＸＭＬ要素も削除される。ラウンドトリッピングは、プロセス／ワークフロービューとコードビサイドとの間にも生じる。
【００７８】
ＸＯＭＬコードを作成するときに、ＸＯＭＬ定義が定義済みインターフェイス要件に適合していない場合、違反しているＸＭＬ要素は、下線が付けられるか、または開発者がそれとわかるように他の何らかの方法で視覚的に識別される。開発者がプロセスビューに切り換えた場合、ＸＯＭＬ内にエラーがあると警告され、デザイナがリンクを表示するので、開発者はそのリンクをクリックして、違反している要素にナビゲートする。この同じエラーは、タスクペインにも表示され、そのエラーをダブルクリックすると、開発者はＸＯＭＬの違反要素にナビゲートされる。
【００７９】
ＸＯＭＬファイルからのアクティビティツリーの作成（デシリアライゼーション）  
一実施形態では、ＣｒｅａｔｅＥｄｉｔｏｒＩｎｓｔａｎｃｅ（）関数が、ＤｅｓｉｇｎＳｕｒｆａｃｅオブジェクトを作成し、その後、ＤｅｓｉｇｎＳｕｒｆａｃｅオブジェクト上でＢｅｇｉｎＬｏａｄ（）関数を呼び出して実際のローダオブジェクトをその中に渡し、最後に、ＢｅｇｉｎＬｏａｄ（）でＤｅｓｉｇｎｅｒＬｏａｄｅｒ（）関数を呼び出す。ＰｅｒｆｏｒｍＬｏａｄ（）関数は、テキストバッファオブジェクトを読み込み、それをオーケストレーションエンジンコンポーネントモデル階層にデシリアライズする。本発明は、階層内を辿り、アクティビティをデザインサーフェスに挿入し、コンポーネントをＶｉｓｕａｌ  Ｓｔｕｄｉｏにロードする。
【００８０】
本発明は、さらに、ＸＯＭＬの変更を監視し、階層およびアイテム識別の変更を追跡して、Ｖｉｓｕａｌ  Ｓｔｕｄｉｏのキャッシュ内の値を更新する。二次ドキュメントデータリストは、オーケストレーションエンジンデザイナが作用する、ユーザには見えない二次ドキュメントのリストを含む。例えば、ユーザはコードビサイドファイルを開いていないが、ユーザがオーケストレーションエンジンデザイナ内で変更を加えた場合に、コードビサイドファイルに変更が加えられる。このファイルはユーザには見えないので、ファイルは二次ドキュメントとして保持されるＸＯＭＬファイルが保存されると、必ず、二次ドキュメントも自動的に保存される。これらのファイルの１つの名前が変更されるか、またはファイルが削除された場合、本発明では、それに応じて、対応する二次ドキュメントオブジェクトを更新する。
【００８１】
オブジェクトツリーのデシリアライゼーションガイドラインの例を以下に示す。ｘｍｌ要素は、まず、親オブジェクトのプロパティとして取り扱われる。親オブジェクトが要素のタグ名を持つプロパティを持たない場合、その要素は親オブジェクトの子オブジェクトとして取り扱われる。ｘｍｌ要素は、親オブジェクト上の単純プロパティとして取り扱われる。
【００８２】
上記のシリアライズされたコードを使用するデシリアライゼーションの実施例では、＜Ｗｈｉｌｅ＞要素は、ｘｍｌ名前空間情報を使用して作成されたオブジェクトとして取り扱われる。＜ＣｏｎｄｉｔｉｏｎＲｕｌｅ＞要素は、Ｗｈｉｌｅアクティビティのプロパティとして取り扱われる。＜ＣｏｄｅＥｘｐｒｅｓｓｉｏｎＲｕｌｅＤｅｃｌａｒａｔｉｏｎ＞要素は、値がＣｏｎｄｉｔｉｏｎＲｕｌｅプロパティに適用されるオブジェクトとして取り扱われる。最初に、＜Ｓｅｎｄ＞要素がＷｈｉｌｅアクティビティのプロパティとして試みられるが、「Ｗｈｉｌｅ」アクティビティは、名前「Ｓｅｎｄ」のプロパティを持たず、したがって、＜Ｓｅｎｄ＞要素はオブジェクトとして取り扱われ、ｗｈｉｌｅアクティビティの子アクティビティとして取り扱われる。＜Ｍｅｓｓａｇｅ＞要素は、Ｓｅｎｄアクティビティのプロパティとして取り扱われる。Ｓｅｎｄ  上のＭｅｓｓａｇｅプロパティは読み取り専用なので、Ｍｅｓｓａｇｅ要素のコンテンツは、Ｍｅｓｓａｇｅオブジェクトのコンテンツと考えられる。同様のルールが、＜ＯｎＢｅｆｏｒｅＳｅｎｄ＞および＜ＴｙｐｅｄＣｈａｎｎｅｌ＞要素のデシリアライゼーションに適用される。
【００８３】
ＸＯＭＬコードがきちんとした形でない、ＸｏｍｌＤｏｃｕｍｅｎｔがＸＯＭＬコード内の第１の要素でなく、ＸＯＭＬコード内の第１のアクティビティがデシリアライザできないという第１の条件の下では、ＸＯＭＬデシリアライゼーションは決定的に失敗する開発者に対して、ＸＯＭＬビューからプロセス／ワークフロービューから切り換える場合に、違反している側のＸＭＬ要素にナビゲートするためのエラーメッセージが提示される。
【００８４】
オーケストレーションエンジンデザイナのホスティング  
デザイナフレームワークは、どのようなアプリケーションプログラムでもホスティングできる。これは、サードパーティのアプリケーションでそれぞれの環境においてワークフローをレンダリングするのに非常に有用な機能である。またこれにより、サードパーティは、デザインサーフェスを再ホスティングおよびカスタマイズすることで、オーケストレーションエンジンデザイナ周辺のツールを開発することができる。本発明のフレームワークでは、ホスティングコンテナアプリケーション側でエディタおよび／またはテキストバッファなどのサービス群を用意することを想定している。
【００８５】
デザイナを再ホストする１ステップでは、ローダおよびデザインサーフェスを作成する。ローダは、ＸＯＭＬファイルをロードし、アクティビティホストインフラストラクチャを構築する役割を持つ。デザインサーフェスは、その中にデザイナホストインフラストラクチャを保持し、デザインサーフェスをホスティングし、それとやり取りするサービスを提供する。デザインサーフェスは、サービスコンテナだけでなくサービスプロバイダとしても機能する。一実施例では、以下のコードを実行して、ＸＯＭＬドキュメントをロードし、その中にアクティビティを保持するデザイナホストを構築する。
【００８６】
【表４】
2006107477.tif 000006
【００８７】
以下のサービスでは、デザイナで異なる機能を使用できる。ＩＳｅｌｅｃｔｉｏｎＳｅｒｖｉｃｅ関数は、選択されたオブジェクトを保持する。ＩＴｏｏｌｂｏｘＳｅｒｖｉｃｅ関数は、ツールボックスとのやり取りを管理する。ＩＭｅｎｕＣｏｍｍａｎｄＳｅｒｖｉｃｅ関数は、メニューとのやり取りを管理する。ＩＴｙｐｅＰｒｏｖｉｄｅｒ関数を使用すると、タイプシステムを利用できる。さらに、高度なデザイナ機能を使用可能にするデザイナホスティング環境が提供する追加サービスもありえる。
【００８８】
タイプシステムは、本発明のコンポーネントモデルフレームワーク内の一コンポーネントである。デザイナがプロジェクトシステムの内側でホスティングされる場合、ＴｙｐｅＰｒｏｖｉｄｅｒオブジェクトがプロジェクト毎に作成される。プロジェクト内のアセンブリ参照はタイププロバイダへプッシュされる。さらに、プロジェクト内のユーザコードファイルが解析され、単一コードコンパイル単位が作成され、タイププロバイダへプッシュされる。さらに、本発明は、タイプシステム内で型を変更させることが可能なプロジェクトシステム内のイベントを監視し、その変更に対する応答として型を再ロードする適切な呼び出しをタイププロバイダに対し実行する。
【００８９】
元に戻す／繰り返し  
スケジュールを作成し、正しく構築した後、開発者は一連の実行済みオペレーションをロールバックしたい場合がある。本発明の「元に戻す」および「繰り返し」機能を使用すると、どのアクティビティが直接影響を受けているかを例示する視覚的フィードバックが得られる。例えば、アクティビティ上でプロパティの変更が元に戻される場合、影響を受けたアクティビティは選択状態になる。複数のオブジェクトの削除が元に戻される場合、関わっているすべてのオブジェクトが、スケジュールに復元されるときに選択状態になる。Ｕｎｄｏ／Ｒｅｄｏ（元に戻す／繰り返し）は、他の分野における多くのアプリケーション全体を通して使用される共通の機能であり、その意味はよく理解されている。オーケストレーションエンジンデザイナでは、Ｓａｖｅ後に、元に戻す／繰り返しアイテムがパージされることはない。さらに、元に戻す／繰り返しは、プロセス／ワークフロービューで、ＸＯＭＬビューで、開発者がビューを切り換えた場合に、およびコードビサイド内で実行することができる。
【００９０】
Ｕｎｄｏ／Ｒｅｄｏは、プロセス／ワークフロービュー内のアクション、つまり、アクティビティのドラッグ＆ドロップ（例えば、ツールボックスからデザインサーフェスにアクティビティをドラッグする、スケジュールの一部分から他の部分にアクティビティを移動する、一方のデザイナから他方のデザイナにアクティビティを移動する）、アクティビティの構成（例えば、アクティビティのプロパティを指定する）、および切り取り／コピー／貼り付け／削除のアクションに対し用意されている。
【００９１】
一実施形態では、シリアライズされたビュー（例えば、ＸＯＭＬビュー）は、テキストエディタ標準の元に戻す／繰り返しオペレーションを備えるＸＭＬエディタである。本発明のデザイナは、プロセス／ワークフロービュー内で加えられた変更を示すフィードバックを開発者に提示し、その後、シリアライズされたビュー内で元に戻した結果として、シリアライズされたコードは失われる。開発者がプロセス／ワークフロービュー内のスケジュールの一部分を構築し、シリアライズされたビューに切り換えて、その後、元に戻す／繰り返しオペレーションを実行することに決めた場合、警告が表示される。
【００９２】
動作環境の例  
図１０は、コンピュータ１３０の形態の汎用コンピューティング装置の一実施例を示している。本発明の一実施形態では、コンピュータ１３０などのコンピュータは、例示され、本明細書で説明されている他の図で使用するのに適している。コンピュータ１３０は、１つまたは複数のプロセッサまたは演算処理装置１３２およびシステムメモリ１３４を備える。例示されている実施形態では、システムバス１３６は、システムメモリ１３４を含むさまざまなシステムコンポーネントをプロセッサ１３２に結合する。バス１３６は、メモリバスまたはメモリコントローラ、周辺機器バス、アクセラレイティッドグラフィックスポート、およびさまざまなバスアーキテクチャのどれかを使用するプロセッサまたはローカルバスを含む数種類のバス構造のうちの１つまたは複数を表している。例えば、限定はしないが、このようなアーキテクチャとしては、Ｉｎｄｕｓｔｒｙ  Ｓｔａｎｄａｒｄ  Ａｒｃｈｉｔｅｃｔｕｒｅ（ＩＳＡ）バス、Ｍｉｃｒｏ  Ｃｈａｎｎｅｌ  Ａｒｃｈｉｔｅｃｔｕｒｅ（ＭＣＡ）バス、Ｅｎｈａｎｃｅｄ  ＩＳＡ（ＥＩＳＡ）バス、Ｖｉｄｅｏ  Ｅｌｅｃｔｒｏｎｉｃｓ  Ｓｔａｎｄａｒｄｓ  Ａｓｓｏｃｉａｔｉｏｎ（ＶＥＳＡ）ローカルバス、およびＭｅｚｚａｎｉｎｅバスとも呼ばれるＰｅｒｉｐｈｅｒａｌ  Ｃｏｍｐｏｎｅｎｔ  Ｉｎｔｅｒｃｏｎｎｅｃｔ（ＰＣＩ）バスがある。
【００９３】
コンピュータ１３０は、通常、少なくともある種の形態のコンピュータ可読媒体を備える。コンピュータ可読媒体は、揮発性および不揮発性媒体、取り外し可能および取り外し不可能媒体を含み、コンピュータ１３０によってアクセスできる媒体であればどのような媒体でもよい。例えば、限定はしないが、コンピュータ可読媒体は、コンピュータ記憶媒体および通信媒体を含む。コンピュータ記憶媒体は、コンピュータ可読命令、データ構造体、プログラムモジュール、またはその他のデータなどの情報を格納する方法または技術で実装される揮発性および不揮発性、取り外し可能および取り外し不可能媒体を含む。例えば、コンピュータ記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたはその他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多目的ディスク（ＤＶＤ）またはその他の光ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置またはその他の磁気記憶装置、または所望の情報を格納するために使用することができ、しかもコンピュータ１３０によりアクセスできるその他の媒体を含む。通信媒体は、通常、コンピュータ可読命令、データ構造体、プログラムモジュール、または搬送波もしくはその他のトランスポートメカニズムなどの変調データ信号によるその他のデータを具現するものであり、任意の情報配信媒体を含む。当業者は、信号内の情報を符号化するなどの方法により特性のうちの１つまたは複数が設定または変更される変調データ信号を熟知している。有線ネットワークまたは直接配線接続などの有線媒体、ならびに音響、ＲＦ、赤外線、およびその他の無線媒体などの無線媒体は、通信媒体のいくつかの実施例である。上記のいずれの組み合わせもコンピュータ可読媒体の範囲に含まれる。
【００９４】
システムメモリ１３４は、取り外し可能な、および／または取り外し不可能な、揮発性および／または不揮発性メモリの形のコンピュータ記憶媒体を備える。例示されている実施形態では、システムメモリ１３４は、読み取り専用メモリ（ＲＯＭ）１３８およびランダムアクセスメモリ（ＲＡＭ）１４０を含む。起動時などにコンピュータ１３０内の要素間の情報伝送を助ける基本ルーチンを含む基本入出力システム１４２（ＢＩＯＳ）は、通常、ＲＯＭ  １３８に格納される。通常、ＲＡＭ  １４０は、演算処理装置１３２に直接アクセス可能な、および／または演算処理装置１３２によって現在操作されているデータおよび／またはプログラムモジュールを格納する。例えば、限定はしないが、図１０は、オペレーティングシステム１４４、アプリケーションプログラム１４６、その他のプログラムモジュール１４８、およびプログラムデータ１５０を例示している。
【００９５】
コンピュータ１３０はさらに、その他の取り外し可能／取り外し不可能な揮発性／不揮発性コンピュータ記憶媒体を備えることもできる。例えば、図１０は、取り外し不可能な不揮発性磁気媒体への読み書きを行うハードディスクドライブ１５４を例示している。図１０は、さらに、取り外し可能不揮発性磁気ディスク１５８への読み書きを行う磁気ディスクドライブ１５６、およびＣＤ−ＲＯＭまたはその他の光媒体などの取り外し可能不揮発性光ディスク１６２への読み書きを行う光ディスクドライブ１６０を示している。動作環境の実施例で使用できる他の取り外し可能／取り外し不可能な揮発性／不揮発性コンピュータ記憶媒体としては、限定はしないが、磁気テープカセット、フラッシュメモリカード、デジタル多目的ディスク、デジタルビデオテープ、ソリッドステートＲＡＭ、ソリッドステートＲＯＭなどがある。ハードディスクドライブ１５４、および磁気ディスクドライブ１５６、および光ディスクドライブ１６０は、通常、インターフェイス１６６などの不揮発性メモリインターフェイスによりシステムバス１３６に接続される。
【００９６】
図１０に例示されている上記のドライブまたは他の大容量記憶装置およびその関連コンピュータ記憶媒体は、コンピュータ１３０用のコンピュータ可読命令、データ構造体、プログラムモジュール、およびその他のデータを格納する機能を備える。例えば、図１０では、ハードディスクドライブ１５４は、オペレーティングシステム１７０、アプリケーションプログラム１７２、その他のプログラムモジュール１７４、およびプログラムデータ１７６を格納するものとして例示されている。これらのコンポーネントは、オペレーティングシステム１４４、アプリケーションプログラム１４６、その他のプログラムモジュール１４８、およびプログラムデータ１５０と同じである場合もあれば異なる場合もあることに留意されたい。オペレーティングシステム１７０、アプリケーションプログラム１７２、その他のプログラムモジュール１７４、およびプログラムデータ１７６に対しては、ここで、異なる番号を割り当てて、最低でも、それらが異なるコピーであることを示している。
【００９７】
ユーザは、キーボード１８０、およびポインティング装置１８２（例えば、マウス、トラックボール、ペン、またはタッチパッド）などのなどの入力装置またはユーザインターフェイス選択装置を通じてコマンドおよび情報をコンピュータ１３０に入力することができる。他の入力装置（図に示されていない）としては、マイク、ジョイスティック、ゲームパッド、衛星放送受信アンテナ、スキャナなどがある。これらの入力装置およびその他の入力装置は、システムバス１３６に結合されているユーザ入力インターフェイス１８４を通じて演算処理装置１３２に接続されるが、パラレルポート、ゲームポート、またはユニバーサルシリアルバス（ＵＳＢ）などの他のインターフェイスおよびバス構造により接続することもできる。モニタ１８８またはその他の種類の表示装置も、ビデオインターフェイス１９０などのインターフェイスを介してシステムバス１３６に接続される。モニタ１８８のほかに、コンピュータはプリンタおよびスピーカなどの他の周辺出力装置（図に示されていない）を備えることが多く、これらは出力周辺機器インターフェイス（図に示されていない）を通じて接続することができる。
【００９８】
コンピュータ１３０は、リモートコンピュータ１９４などの１つまたは複数のリモートコンピュータへの論理接続を使用してネットワーク接続環境で動作することができる。リモートコンピュータ１９４は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピア装置、またはその他の共通ネットワークノードとすることができ、通常は、コンピュータ１３０に関して上で説明されている要素の多くまたはすべてを含む。図１０に示されている論理接続は、ローカルエリアネットワーク（ＬＡＮ）１９６およびワイドエリアネットワーク（ＷＡＮ）１９８を含むが、他のネットワークを含むこともできる。ＬＡＮ  １３６および／またはＷＡＮ  １３８は、有線ネットワーク、無線ネットワーク、それらの組み合わせなどとすることができる。このようなネットワーキング環境は、オフィス、企業全体にわたるコンピュータネットワーク、イントラネット、および大域的コンピュータネットワーク（例えば、インターネット）では一般的である。
【００９９】
ローカルエリアネットワーキング環境で使用される場合、コンピュータ１３０は、ネットワークインターフェイスまたはアダプタ１８６を介してＬＡＮ  １９６に接続される。ワイドエリアネットワーキング環境で使用される場合、コンピュータ１３０は、通常、インターネットなどのＷＡＮ  １９８上で通信を確立するためモデム１７８またはその他の手段を備える。モデム１７８は、内蔵でも外付けでもよいが、ユーザ入力インターフェイス１８４、またはその他の適切なメカニズムを介してシステムバス１３６に接続される。ネットワーク接続環境では、コンピュータ１３０またはその一部に関して示されているプログラムモジュールは、リモートメモリ記憶装置（図に示されていない）に格納されうる。例えば、限定はしないが、図１０には、リモートアプリケーションプログラム１９２がメモリ装置に常駐しているように例示されている。図に示されているネットワーク接続は実施例であり、コンピュータ間の通信リンクを確立するのに他の手段が使用されうる。
【０１００】
一般に、コンピュータ１３０のデータプロセッサは、コンピュータのさまざまなコンピュータ可読記憶媒体にさまざまな時点において格納された命令を使ってプログラムされる。プログラムおよびオペレーティングシステムは、通常、例えば、フロッピー（登録商標）ディスクまたはＣＤ−ＲＯＭで配布される。そこから、コンピュータの補助記憶装置にインストールまたはロードされる。実行時に、それらは少なくとも一部はコンピュータの主記憶装置にロードされる。本明細書で説明されている発明は、これらおよび他のさまざまな種類のコンピュータ可読記憶媒体を含むが、ただしそのような媒体にマイクロプロセッサまたはその他のデータプロセッサに関して以下で説明されるステップを実装する命令またはプログラムが格納されている場合である。本発明は、さらに、本明細書で説明されている方法および手法に従ってプログラムされた場合にコンピュータ自体も含む。
【０１０１】
例示の目的に関して、オペレーティングシステムなどのプログラムおよびその他の実行可能プログラムコンポーネントは、本明細書では異なるブロックとして例示されている。しかし、そのようなプログラムおよびコンポーネントは、コンピュータの異なる記憶装置コンポーネント内にさまざまな時点において常駐し、コンピュータの（複数の）データプロセッサにより実行されることは理解される。
【０１０２】
本発明は、コンピュータ１３０を含む、コンピューティングシステム環境例に関して説明されているが、他の多くの汎用または専用コンピューティングシステム環境または構成で動作する。このコンピューティングシステム環境は、本発明の用途または機能の範囲に関する制限を示唆する意図はない。さらに、コンピューティングシステム環境は、動作環境例に例示されている１つのコンポーネントまたは複数のコンポーネントの組み合わせに関係する何らかの依存関係または要求条件がその環境にあるものと解釈すべきでない。本発明とともに使用するのに適していると思われるよく知られているコンピューティングシステム、環境、および／または構成の例として、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルドまたはラップトップ装置、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、プログラム可能な家電製品、携帯電話、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、上記システムまたは装置を含む分散コンピューティング環境などがある。
【０１０３】
本発明は、１つまたは複数のコンピュータまたはその他の装置により実行される、プログラムモジュールなどのコンピュータ実行可能命令の一般的状況において説明することができる。一般に、プログラムモジュールは、限定はしないが、特定のタスクを実行する、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、およびデータ構造を含む。また、本発明は、通信ネットワークを通じてリンクされているリモート処理装置によりタスクが実行される分散コンピューティング環境で実施することもできる。分散コンピューティング環境では、プログラムモジュールをメモリ記憶装置などのローカルとリモートの両方のコンピュータ記憶媒体に配置できる。
【０１０４】
ソフトウェアアーキテクチャの背景状況におけるインターフェイスは、ソフトウェアモジュール、コンポーネント、コード部分、またはコンピュータ実行可能命令の他のシーケンスを含む。例えば、インターフェイスは、第１のモジュールの代わりにコンピューティングタスクを実行するために第２のモジュールにアクセスする第１のモジュールを含む。第１および第２のモジュールは、一実施例では、オペレーティングシステムによって提供されるようなアプリケーションプログラミングインターフェイス（ＡＰＩ）、コンポーネントオブジェクトモデル（ＣＯＭ）インターフェイス（例えば、ピアツーピアアプリケーション通信用）、および拡張マークアップ言語メタデータ交換形式（ＸＭＩ）インターフェイス（例えば、複数のＷｅｂサービス間の通信用）を含む。
【０１０５】
インターフェイスは、Ｊａｖａ（登録商標）  ２  Ｐｌａｔｆｏｒｍ  Ｅｎｔｅｒｐｒｉｓｅ  Ｅｄｉｔｉｏｎ（Ｊ２ＥＥ）、ＣＯＭ、または分散ＣＯＭ（ＤＣＯＭ）の実施例などの密結合の同期実装であってよい。それとは別に、またはそれに加えて、インターフェイスは、Ｗｅｂサービスの場合のような疎結合の非同期実装とすることもできる（例えば、シンプルオブジェクトアクセスプロトコルを使用する）。一般に、インターフェイスは、密結合、疎結合、同期、および非同期という特性の任意の組み合わせを含む。さらに、インターフェイスは、標準プロトコル、専用プロトコル、または標準プロトコルと専用プロトコルとの任意の組み合わせに適合することができる。
【０１０６】
本明細書で説明されているインターフェイスは、すべて、単一インターフェイスの一部であるか、または別々のインターフェイスもしくはそれらの任意の組み合わせとして実装することができる。これらのインターフェイスは、機能を提供するためにローカルまたはリモートで実行できる。さらに、これらのインターフェイスが含む機能は、例示されている、または本明細書で説明されている機能よりも多い場合も少ない場合もある。
【０１０７】
例示され、本明細書で説明されている方法の実行または遂行の順序は、断りのない限り本質的ではない。つまり、これらの方法の要素は、断りのない限り任意の順序で実行することができ、それらの方法が含む要素は、本明細書で開示されている要素よりも多い場合も少ない場合もある。例えば、特定の要素を、他の要素の前に、他の要素と同時に、または他の要素の後に実行または遂行することは本発明の範囲であると考えられる。
【０１０８】
本発明または本発明の（複数の）実施形態の要素を導入する際に、英文中の「ａ」、「ａｎ」、「ｔｈｅ」、および「ｓａｉｄ」という冠詞、したがって和文中の「１つの」、「その」、「前記」は、それらの要素が１つまたは複数あることを意味することを意図している。「備える」、「含む」、および「持つ、格納する、含む、備える」という言葉は、包含的であることを意図し、一覧に示されている要素以外にさらに要素がありうることを意味する。
【０１０９】
上記の説明に照らして、本発明の複数の目的が達成され、他の有益な結果が得られることは理解されるであろう。
【０１１０】
本発明の範囲から逸脱することなく上記の構成、製品、および方法にさまざまな変更を加えることが可能であるので、上記の説明に含まれ、付属の図面に示されているすべての事柄は、例示しているのであって、限定する意味はないと解釈するものとする。
【０１１１】
付録Ａ  
付録Ａでは、アクティビティのいくつかの実施例を説明する。
【０１１２】
アクティビティの例およびその実装例  
アクティビティの例としては、Ｓｅｎｄ、ＳｅｎｄＲｅｑｕｅｓｔ、ＳｅｎｄＲｅｓｐｏｎｓｅ、Ｒｅｃｅｉｖｅ、ＲｅｃｅｉｖｅＲｅｑｕｅｓｔ、ＲｅｃｅｉｖｅＲｅｓｐｏｎｓｅ、Ｃｏｄｅ、Ｄｅｌａｙ、Ｆａｕｌｔ、Ｓｕｓｐｅｎｄ、Ｔｅｒｍｉｎａｔｅ、ＩｎｖｏｋｅＳｃｈｅｄｕｌｅ、ＩｎｖｏｋｅＳｃｈｅｄｕｌｅｓ、Ｉｎｖｏｋｅ  ＷｅｂＳｅｒｖｉｃｅ、ＤｏｔＮｅｔＥｖｅｎｔＳｏｕｒｃｅ、ＤｏｔＮｅｔＥｖｅｎｔＳｉｎｋ、Ｓｅｑｕｅｎｃｅ、Ｐａｒａｌｌｅｌ、Ｗｈｉｌｅ、ＣｏｎｄｉｔｉｏｎａｌＢｒａｎｃｈ、Ｃｏｎｄｉｔｉｏｎａｌ、Ｃｏｎｓｔｒａｉｎｅｄ、ＣｏｎｓｔｒａｉｎｅｄＡｃｔｉｖｉｔｙＧｒｏｕｐ（ＣＡＧ）、ＥｖｅｎｔＤｒｉｖｅｎ、Ｌｉｓｔｅｎ、ＥｖｅｎｔＨａｎｄｌｅｒｓ、ＥｘｃｅｐｔｉｏｎＨａｎｄｌｅｒ、ＥｘｃｅｐｔｉｏｎＨａｎｄｌｅｒｓ、Ｃｏｍｐｅｎｓａｔｅ、ＣｏｍｐｅｎｓａｔｉｏｎＨａｎｄｌｅｒ、Ｓｃｏｐｅ、およびＳｃｈｅｄｕｌｅがある。
【０１１３】
上記のアクティビティクラスは、メタデータ宣言に対するサポートしている型の集合に依存する。これらの型は、ＤａｔａＥｌｅｍｅｎｔ、ＬｉｔｅｒａｌＥｌｅｍｅｎｔ、ＭｅｍｂｅｒＤｅｃｌａｒａｔｉｏｎ、ＶａｒｉａｂｌｅＤｅｃｌａｒａｔｉｏｎ、ＴｙｐｅｄＶａｒｉａｂｌｅＤｅｃｌａｒａｔｉｏｎ、ＭｅｓｓａｇｅＤｅｃｌａｒａｔｉｏｎ、ＣｏｒｒｅｌａｔｉｏｎＳｅｔＤｅｃｌａｒａｔｉｏｎ、ＣｈａｎｎｅｌＤｅｃｌａｒａｔｉｏｎ、ＴｙｐｅｄＣｈａｎｎｅｌＤｅｃｌａｒａｔｉｏｎ、ＨａｎｄｌｅｒＤｅｃｌａｒａｔｉｏｎ、ＴｙｐｅｄＨａｎｄｌｅｒＤｅｃｌａｒａｔｉｏｎ、ＲｕｌｅＤｅｃｌａｒａｔｉｏｎ、ＣｏｄｅＥｘｐｒｅｓｓｉｏｎＲｕｌｅＤｅｃｌａｒａｔｉｏｎ、ＤｅｃｌａｒａｔｉｖｅＥｘｐｒｅｓｓｉｏｎＲｕｌｅＤｅｃｌａｒａｔｉｏｎ、ＰａｒａｍｅｔｅｒＤｅｃｌａｒａｔｉｏｎ、ＰａｒａｍｅｔｅｒＤｅｃｌａｒａｔｉｏｎＣｏｌｌｅｃｔｉｏｎ、ＰａｒａｍｅｔｅｒＢｉｎｄｉｎｇ、およびＰａｒａｍｅｔｅｒＢｉｎｄｉｎｇＣｏｌｌｅｃｔｉｏｎを含む。
【０１１４】
さらに、いくつかのアクティビティがメタデータとして必要とするコードビサイドメソッドの型にマッピングされる標準デリゲート型の集合がある。さらに、スケジュールのシリアライゼーション［ＸｏｍｌＳｅｒｉａｌｉｚｅｒおよび関係する型］およびコンパイル［ＸｏｍｌＣｏｍｐｉｌｅｒおよび関係する型］をサポートするユーティリティクラスの集合がある。ユーティリティｗｆｃ．ｅｘｅ（例えば、「ｗｏｒｋｆｌｏｗ  ｃｏｍｐｉｌｅｒ」）があるが、これはスケジュールをコンパイルするためのコマンドラインツールである。
【０１１５】
Ｓｅｎｄアクティビティ  
オーケストレーションエンジンは、メッセージを送信する３つのアクティビティを備え、それぞれ異なる使用事例を対象とする。さらに、これら３つのアクティビティは、何らかのメタデータを共有するので、抽象基本クラスが３つのすべての上位クラスとして定義され使用される。  
ＳｅｎｄＢａｓｅ  
メタデータ：  
□  メッセージ参照。  
□  オプションのコードビサイドメソッド。  
□  相関関係集合のオプションのコレクション。  
Ｓｅｎｄ  
メタデータ：  
○  メッセージ参照。  
○  オプションのコードビサイドメソッド。  
○  相関関係集合のオプションのコレクション。  
□  型なしまたは型付きの送信チャネル参照。チャネルが型付きの場合、オペレーションはチャネル宣言でも指定される。  
実行：  
Ｓｅｎｄアクティビティは、指定チャネルで指定メッセージを送信する。型付きチャネルが使用される場合、Ｓｅｎｄアクティビティは特定のオペレーションを利用する。このオペレーションは、ｖｏｉｄを返すように定義されなければならない。型なしチャネルは、任意の型のメッセージを受け付ける。メッセージが送信される前に、オプションのコードビサイドハンドラが呼び出される。このハンドラの通常の使用では、送信されようとしているメッセージを初期化するか、または他の何らかの形で準備する。Ｓｅｎｄアクティビティは、さらに、すでに指定されている相関関係集合を初期化する。Ｓｅｎｄアクティビティは、相関関係集合に追随しない。Ｓｅｎｄは、同期して実行される（完了するまでスレッドを放棄しない）。
【０１１６】
ＳｅｎｄＲｅｑｕｅｓｔ  
目的：要求−応答メッセージパターンの一部として要求メッセージを送信する。  
メタデータ：  
○  メッセージ参照。  
○  オプションのコードビサイドメソッド。  
○  相関関係集合のオプションのコレクション。  
□  型なしまたは型付きの送信チャネル参照。チャネルが型付きの場合、オペレーションも指定される。  
実行：  
ＳｅｎｄＲｅｑｕｅｓｔアクティビティは、指定チャネルで指定メッセージを送信する。型付きチャネルが使用される場合、Ｓｅｎｄアクティビティは特定のオペレーションを利用する。このオペレーションは、ｖｏｉｄ以外の型を返すように定義されなければならない（注意：これがＳｅｎｄＲｅｑｕｅｓｔとＳｅｎｄとが異なる点である）。型なしチャネルは、任意の型のメッセージを受け付ける。メッセージが送信される前に、オプションのコードビサイドハンドラが呼び出される。このハンドラの通常の使用では、送信されようとしているメッセージを初期化するか、または他の何らかの形で準備する。ＳｅｎｄＲｅｑｕｅｓｔアクティビティは、さらに、すでに指定されている相関関係集合を初期化する。ＳｅｎｄＲｅｑｕｅｓｔ／ＲｅｃｅｉｖｅＲｅｓｐｏｎｓｅペアのみを含み、他の受信アクティビティを含まない単純スケジュールでは、相関関係集合を明示的に作成または初期化する必要はなく、要求メッセージおよび応答メッセージの相関が自動的に実行される。Ｓｅｎｄアクティビティは、相関関係集合に追随しない。ＳｅｎｄＲｅｑｕｅｓｔは、同期して実行される（完了するまでスレッドを放棄しない）。
【０１１７】
ＳｅｎｄＲｅｓｐｏｎｓｅ  
目的：要求−応答メッセージパターンの一部として応答メッセージを送信する。  
メタデータ：  
○  メッセージ参照。  
○  オプションのコードビサイドメソッド。  
○  相関関係集合のオプションのコレクション。  
□  ＲｅｃｅｉｖｅＲｅｑｕｅｓｔアクティビティのＩＤ。  
実行：  
ＳｅｎｄＲｅｓｐｏｎｓｅアクティビティは、関連付けられたＲｅｃｅｉｖｅＲｅｑｕｅｓｔアクティビティ上で宣言されているチャネルで指定メッセージを送信する。型付きチャネルが使用される場合、ＳｅｎｄＲｅｓｐｏｎｓｅアクティビティはＲｅｃｅｉｖｅＲｅｑｕｅｓｔアクティビティにより示されるオペレーションを利用する。このオペレーションは、ｖｏｉｄ以外の型を返すように定義されなければならない。型なしチャネルは、任意の型のメッセージを受け付ける。メッセージが送信される前に、オプションのコードビサイドハンドラが呼び出される。このハンドラの通常の使用では、送信されようとしているメッセージを初期化するか、または他の何らかの形で準備する。ＳｅｎｄＲｅｓｐｏｎｓｅアクティビティは、さらに、すでに指定されている相関関係集合を初期化する。Ｓｅｎｄアクティビティは、相関関係集合に追随しない。ＳｅｎｄＲｅｓｐｏｎｓｅは、同期して実行される（完了するまでスレッドを放棄しない）。
【０１１８】
Ｒｅｃｅｉｖｅアクティビティ  
オーケストレーションエンジンは、メッセージを受信する３つのアクティビティを備え、それぞれ異なる使用事例を対象とする。さらに、これら３つのアクティビティは、何らかのメタデータを共有するので、抽象基本クラスが３つのすべての上位クラスとして定義され使用される。
【０１１９】
ＲｅｃｅｉｖｅＢａｓｅ  
目的：受信アクティビティの抽象基本クラス。  
メタデータ：  
□  メッセージ参照。  
□  オプションのコードビサイドメソッド。  
□  相関関係集合のオプションのコレクション。
【０１２０】
Ｒｅｃｅｉｖｅ  
目的：メッセージを受信する。  
メタデータ：  
○  メッセージ参照。  
○  オプションのコードビサイドメソッド。  
○  相関関係集合のオプションのコレクション。  
□  これがアクティブ状態の受信かどうかを示す論理値。  
□  型なしまたは型付きの受信チャネル参照。チャネルが型付きの場合、オペレーションも指定される。  
実行：  
Ｒｅｃｅｉｖｅアクティビティは、指定チャネル上でメッセージの到着を待つブロッキングウェイトを実行する。型付きチャネルが使用される場合、Ｒｅｃｅｉｖｅは、そのチャネルの特定のオペレーションで特定の型のメッセージの到着を待つ。このオペレーションは、ｖｏｉｄを返すように定義されなければならない。型なしチャネルは、任意の型のメッセージを配信する。Ｒｅｃｅｉｖｅがアクティブ状態の受信の場合、特別なサブスクリプションが構成され、これにより指示されたチャネル上でメッセージが到着すると、Ｒｅｃｅｉｖｅが一部であるスケジュールの新しいインスタンスが作成または実行される。Ｒｅｃｅｉｖｅが後に続く相関関係集合は、そのチャネル上でセットアップされたメッセージサブスクリプション内で使用される。これにより、スケジュールインスタンスは、必ず、そのインスタンスを向けのメッセージのみを受信するようになる。メッセージを受信した後、Ｒｅｃｅｉｖｅアクティビティは、初期化を要すると指定されている相関関係集合を初期化する。その後、オプションのコードビサイドハンドラが呼び出される。このハンドラの通常の使用では、メッセージを何らかの方法で処理する。
【０１２１】
ＲｅｃｅｉｖｅＲｅｑｕｅｓｔ  
目的：要求−応答メッセージパターンの一部として要求メッセージを受信する。  
メタデータ：  
○  メッセージ参照。  
○  オプションのコードビサイドメソッド。  
○  相関関係集合のオプションのコレクション。  
□  これがアクティブ状態の受信かどうかを示す論理値。  
□  型なしまたは型付きの受信チャネル参照。チャネルが型付きの場合、オペレーションも指定される。  
実行：  
ＲｅｃｅｉｖｅＲｅｑｕｅｓｔアクティビティは、指定チャネル上でメッセージの到着を待つブロッキングウェイトを実行する。型付きチャネルが使用される場合、ＲｅｃｅｉｖｅＲｅｑｕｅｓｔは、そのチャネルの特定のオペレーションで特定の型のメッセージの到着を待つ。このオペレーションは、ｖｏｉｄ以外の型を返すように定義されなければならない（これがＲｅｃｅｉｖｅＲｅｑｕｅｓｔとＲｅｃｅｉｖｅとが異なる点である）。型なしチャネルは、任意の型のメッセージを配信する。ＲｅｃｅｉｖｅＲｅｑｕｅｓｔがアクティブ状態の受信の場合、特別なサブスクリプションが構成され、これにより指示されたチャネル上でメッセージが到着すると、ＲｅｃｅｉｖｅＲｅｑｕｅｓｔが一部であるスケジュールの新しいインスタンスが作成または実行される。ＲｅｃｅｉｖｅＲｅｑｕｅｓｔが後に続く相関関係集合は、そのチャネル上でセットアップされたメッセージサブスクリプション内で使用される。これにより、スケジュールインスタンスは、必ず、そのインスタンスを向けのメッセージのみを受信するようになる。メッセージを受信した後、ＲｅｃｅｉｖｅＲｅｑｕｅｓｔアクティビティは、初期化を要すると指定されている相関関係集合を初期化する。その後、オプションのコードビサイドハンドラが呼び出される。このハンドラの通常の使用では、メッセージを何らかの方法で処理する。ＲｅｃｅｉｖｅＲｅｑｕｅｓｔ／ＳｅｎｄＲｅｓｐｏｎｓｅペアのみを含み、他の受信アクティビティを含まない単純スケジュールでは、相関関係集合を明示的に作成または初期化する必要はなく、要求メッセージおよび応答メッセージの相関が自動的に実行される。
【０１２２】
ＲｅｃｅｉｖｅＲｅｓｐｏｎｓｅ  
目的：要求−応答メッセージパターンの一部として応答メッセージを受信する。  
メタデータ：  
○  メッセージ参照。  
○  オプションのコードビサイドメソッド。  
○  相関関係集合のオプションのコレクション。  
□  ＳｅｎｄＲｅｑｕｅｓｔアクティビティのＩＤ。  
実行：  
ＲｅｃｅｉｖｅＲｅｓｐｏｎｓｅアクティビティは、関連付けられたＳｅｎｄＲｅｑｕｅｓｔアクティビティ上で指定されたチャネル上でメッセージの到着を待つブロッキングウェイトを実行する。型付きチャネルが使用される場合、ＲｅｃｅｉｖｅＲｅｓｐｏｎｓｅアクティビティはＳｅｎｄＲｅｑｕｅｓｔアクティビティにより示されるオペレーションを利用する。このオペレーションは、ｖｏｉｄ以外の型を返すように定義されなければならない。型なしチャネルは、任意の型のメッセージを配信する。ＲｅｃｅｉｖｅＲｅｓｐｏｎｓｅアクティビティは、相関関係集合に追随しない。メッセージが受信された後に、オプションのコードビサイドハンドラが呼び出される。このハンドラの通常の使用では、すでに受信されているメッセージを処理する。メッセージを受信した後、ＲｅｃｅｉｖｅＲｅｓｐｏｎｓｅアクティビティは、初期化を要すると指定されている相関関係集合を初期化する。その後、オプションのコードビサイドハンドラが呼び出される。このハンドラの通常の使用では、メッセージを何らかの方法で処理する。
【０１２３】
Ｃｏｄｅ  
目的：コードビサイドで実装されたメソッドを実行する。  
メタデータ：  
□  コードビサイドメソッド。  
実行：  
Ｃｏｄｅアクティビティは、メタデータで指示されているコードビサイドメソッドを実行する。Ｃｏｄｅは、同期して実行される（完了するまでスレッドを放棄しない）。したがって、コードビサイドメソッドの実行は、実行されることが想定されており、何らかの外部資源への依存でブロックすべきでない。例えば、このコードは、通常、Ｗｅｂサービスを呼び出さない。Ｃｏｄｅアクティビティの通常使用では、スケジュールインスタンス状態を検査し、ローカル変数およびメッセージを操作する。
【０１２４】
Ｄｅｌａｙ  
目的：将来の特定のＤａｔｅＴｉｍｅが到来するまで待つ。  
メタデータ：  
□  ＤａｔｅＴｉｍｅを返すコードビサイドメソッド。  
インスタンスデータ：  
Ｄｅｌａｙが待っている（または待っていた）ＤａｔｅＴｉｍｅ値。この値は、Ｄｅｌａｙが実際に実行を開始するまでヌルとして報告される。  
実行：  
Ｄｅｌａｙアクティビティは、その必須コードビサイドメソッドを実行してＤａｔｅＴｉｍｅ値を生成する。そのインスタンスデータのＴｉｍｅｏｕｔＶａｌｕｅプロパティをこの値に内部的に設定する。ＤａｔｅＴｉｍｅが過去であれば、Ｄｅｌａｙは即座に完了する。そうでなければ、タイマーが発火したときにＤｅｌａｙに通知するようにタイマーサブスクリプションをセットアップする。タイマーが発火した場合、Ｄｅｌａｙは通知され、完了する。Ｄｅｌａｙは、受信アクティビティのように、実行を同期して完了せず、その代わりに、スレッドを放棄して、ＤａｔｅＴｉｍｅが到来したという通知を待つ。
【０１２５】
エンジンにより明るみに出された基本タイマーサービスの特性に基づいて、Ｄｅｌａｙアクティビティは、指示されたＤａｔｅＴｉｍｅが到来するやいなや完了することを保証されるが、実際には、タイマー通知はＤａｔｅＴｉｍｅの到来後しばらくしてから発生することがあるため長くかかることがある（例えば、サーバ環境でシステムに強いストレスがかかっている場合）。Ｄｅｌａｙが期待通り動作するためにはＵＴＣ時刻が返されなければならず、多くの場合、これは、ＤａｔｅＴｉｍｅ値を返すコードハンドラ内でＤａｔｅＴｉｍｅ．Ｎｏｗの代わりにＤａｔｅＴｉｍｅ．ＵｔｃＮｏｗを使用することを意味することに注意されたい。
【０１２６】
Ｆａｕｌｔ  
目的：例外をスローする。  
メタデータ：  
□  Ｅｘｃｅｐｔｉｏｎを返すコードビサイドメソッド。  
実行：  
Ｆａｕｌｔアクティビティは、その必須コードビサイドメソッドを実行してＥｘｃｅｐｔｉｏｎオブジェクトを生成する。その後、この例外をスローする。機能的には、Ｆａｕｌｔアクティビティは、コードビサイドメソッドがＥｘｃｅｐｔｉｏｎＰｒｏｖｉｄｅｒにより発生された例外を単にスローするだけのＣｏｄｅアクティビティと同等である。Ｆａｕｌｔの目的は、スケジュールに対するプロセスメタデータの一部としてビジネス例外のスローを捕捉することである。これは例外をスローするという事実から、Ｆａｕｌｔアクティビティは、これがこのアクティビティの通常の実行を構成するという事実があっても、報告されたＯｕｔｃｏｍｅ  ｏｆ  Ｆａｕｌｔｅｄを持つことになる。
【０１２７】
Ｓｕｓｐｅｎｄ  
目的：実行スケジュールインスタンスをサスペンドする。  
メタデータ：  
□  管理者に報告するエラーメッセージ。  
実行：  
Ｓｕｓｐｅｎｄアクティビティは、現在のスケジュールインスタンスをサスペンドする。これが意味することは、スレッドをサスペンドされているインスタンスのキューに入れられている任意のアイテムに受け渡すことをエンジンが即座に停止するということである、つまり、「Ｃａｎｃｅｌ」シグナルは発生しない。ホスト（例えば、インスタンスマネージャおよび永続プロバイダ）は、エラーメッセージの送り先を決定する。
【０１２８】
Ｔｅｒｍｉｎａｔｅ  
目的：実行スケジュールインスタンスを終了する。  
メタデータ：  
□  管理者に報告するエラーメッセージ。  
実行：  
Ｔｅｒｍｉｎａｔｅアクティビティは、現在のスケジュールインスタンスを終了する。これが意味することは、Ｓｕｓｐｅｎｄの場合のように、スレッドを終了されたインスタンスのキューに入れられているアイテムに受け渡すことをエンジンが即座に停止するということである。Ｔｅｒｍｉｎａｔｅでは、インスタンスがレジュームされる可能性はないため、キューに入っているアイテムも削除される。Ｓｕｓｐｅｎｄの場合のように、「Ｃａｎｃｅｌ」シグナルは発生しない。ホスト（例えば、インスタンスマネージャおよび永続プロバイダ）は、エラーメッセージの送り先を決定する。
【０１２９】
Ｉｎｖｏｋｅ  Ｓｃｈｅｄｕｌｅ  
目的：スケジュールを呼び出す。  
メタデータ：  
●  呼び出されるスケジュールの型。  
●  呼び出しにＣＡＬＬまたはＥＸＥＣ意味論があるかどうかを示す列挙型。  
●  パラメータバインディングの集合。  
●  スケジュールが呼び出される前に呼び出されるオプションのコードビサイドメソッド。  
実行：  
ＩｎｖｏｋｅＳｃｈｅｄｕｌｅアクティビティは、まず最初に、すでに指定されていればＯｎＩｎｉｔｉａｌｉｚｅＣａｌｌｅｅコードビサイドメソッドを呼び出す。通常、このメソッドは、呼び出されるスケジュールインスタンスに対しＩｎパラメータを設定するために使用される。ＩｎｖｏｋｅＳｃｈｅｄｕｌｅは、その後、指定された型のスケジュールインスタンスを作成して呼び出し、与えられたパラメータを受け渡す。ＩｎｖｏｋｅＳｃｈｅｄｕｌｅアクティビティは、呼び出し意味論がＣＡＬＬである場合にブロックし（さらにスレッドを放棄し）、呼び出されたスケジュールが完了するのを待つ。それとは別に、ＩｎｖｏｋｅＳｃｈｅｄｕｌｅアクティビティは、呼び出し意味論がＥＸＥＣである場合に、スケジュールインスタンスが呼び出されると即座に完了する。ＩｎｖｏｋｅＳｃｈｅｄｕｌｅは、すでに指定されていればＯｎＣｏｍｐｌｅｔｅｄＣａｌｌｅｅ  コードビサイドメソッドを呼び出す。通常、このメソッドは、呼び出されたスケジュールインスタンスのＯｕｔパラメータを処理する。
【０１３０】
Ｉｎｖｏｋｅ  Ｗｅｂ  Ｓｅｒｖｉｃｅ  
目的：Ｗｅｂサービスを呼び出す。  
メタデータ：  
●  Ｗｅｂサービスを呼び出すために使用されるプロキシクラスの名前。  
●  呼び出されるＷｅｂサービス上のメソッドの名前。  
●  呼び出しが同期しているかどうかを示す論理値。  
●  パラメータバインディングの集合。  
実行：  
プロキシクラスを介してＷｅｂサービスを呼び出して、パラメータを指定通り受け渡し、受信する。
【０１３１】
ＤｏｔＮｅｔＥｖｅｎｔ  Ｓｉｎｋ  
目的：ＲａｉｓｅＥｖｅｎｔメソッドまたはすでに呼び出されている（子）スケジュール内のＤｏｔＮｅｔＥｖｅｎｔＳｏｕｒｃｅアクティビティを介して発生されるイベントの処理をモデル化する。  
メタデータ：  
●  処理されるイベントの発生で指示されるデリケートと同じ型であるコードビサイドのメソッド。  
インスタンスデータ：ＡｃｔｉｖｉｔｙＳｔａｔｅを超えるものは何もない。  
実行：  
すでに呼び出されているスケジュールインスタンスにより指定イベントが発生したという通知が来るのを待つブロック。呼び出されたスケジュールインスタンスは、ＣＡＬＬ意味論の下で実行中でなければならない。
【０１３２】
ＤｏｔＮｅｔＥｖｅｎｔ  Ｓｏｕｒｃｅ  
目的：ＲａｉｓｅＥｖｅｎｔメソッドを介してコードビサイドでイベントを発生することと機能的に同等のイベントの発生をモデル化する。  
メタデータ：  
●  発生しているイベントの型（およびイベントを処理するために必要なハンドラの型）を示す、デリゲート型。  
●  デリゲート型に基づいて定義されたメソッドパラメータへのパラメータバインディング。  
実行：  
指定イベントを発生し、即座に実行を完了する。このイベントへのサブスクライバの数に関して保証はなく（０個以上ありえる）、またこのイベントの複数の潜在的ハンドラからデータを取り戻すためのメカニズムもない、つまり、意味論は「発火して忘却」である。
【０１３３】
Ｓｅｑｕｅｎｃｅ  
目的：単一の定義済み順序付けに従って子アクティビティの集合を実行する。  
実行：  
Ｓｅｑｕｅｎｃｅアクティビティは、一度に１つずつ、順序正しく子アクティビティの集合の実行を調整する。Ｓｅｑｕｅｎｃｅは、最終子アクティビティが完了すると完了する。
【０１３４】
Ｐａｒａｌｌｅｌ  
目的：子アクティビティの集合を同時実行する。  
実行：  
Ｐａｒａｌｌｅｌアクティビティは、子アクティビティの集合を同時実行する。子が実行に関して有効にされる順序は、非決定論的である。Ｐａｒａｌｌｅｌは、すべての子アクティビティが完了すると完了する。オーケストレーションエンジンのスレッディングモデルのせいで、実際には、Ｐａｒａｌｌｅｌ内の１つのアクティビティのみが所定の時点において実行されている可能性がある。
【０１３５】
Ｗｈｉｌｅ  
目的：子アクティビティを繰り返し実行する。  
メタデータ：  
●  繰り返しを決定するルール。  
実行：  
子アクティビティを繰り返し実行する。各繰り返し前に（最初も含む）、ルールが評価され、ｆａｌｓｅに評価された場合、Ｗｈｉｌｅアクティビティは完了する。
【０１３６】
ＣｏｎｄｉｔｉｏｎａｌＢｒａｎｃｈ  
目的：Ｃｏｎｄｉｔｉｏｎａｌの分岐を表す。  
メタデータ：  
●  ラップされたアクティビティ（分岐）の条件付き実行を決定するルール。  
実行：  
Ｓｅｑｕｅｎｃｅの意味論に従って、子アクティビティを実行する。親Ｃｏｎｄｉｔｉｏｎａｌアクティビティは、ＣｏｎｄｉｔｉｏｎａｌＢｒａｎｃｈを実行すべきかどうかを決定するメタデータ（ルール）を調べる役割を持つ。Ｃｏｎｄｉｔｉｏｎａｌアクティビティ自体は、追加プロパティを持たない（ＩＤおよびＤｅｓｃｒｉｐｔｉｏｎ以外）。しかし、Ｃｏｎｄｉｔｉｏｎａｌｓは、プロパティを公開する条件付き分岐からなる。ＣｏｎｄｉｔｉｏｎａｌＢｒａｎｃｈの選択後、Ｍｏｖｅ  Ｌｅｆｔ（選択されたＣｏｎｄｉｔｉｏｎａｌＢｒａｎｃｈを条件節のすぐ左に移動する）およびＭｏｖｅ  Ｒｉｇｈｔ（選択されたＣｏｎｄｉｔｉｏｎａｌＢｒａｎｃｈを条件節のすぐ右に移動する）の２つの追加コンテキストメニューオペレーションが表示される。
【０１３７】
Ｃｏｎｄｉｔｉｏｎａｌ  
目的：ｎ個のＣｏｎｄｉｔｉｏｎａｌＢｒａｎｃｈアクティビティの１つを条件付きで実行する。  
実行：  
Ｃｏｎｄｉｔｉｏｎａｌアクティビティは、ＣｏｎｄｉｔｉｏｎａｌＢｒａｎｃｈアクティビティの順序付き集合を含む。Ｃｏｎｄｉｔｉｏｎａｌは、ルールがＴＲＵＥに評価される第１のＣｏｎｄｉｔｉｏｎａｌＢｒａｎｃｈアクティビティを実行する。  
最終的なＣｏｎｄｉｔｉｏｎａｌＢｒａｎｃｈアクティビティは、ルールを指定しないことを許可され。この場合、ＴＲＵＥに評価されると常に考えられる。Ｃｏｎｄｉｔｉｏｎａｌが、子アクティビティを実行していなくても完了することは可能である。本質的に、これによりＩＦ−ＥＬＳＥＩＦ−ＥＬＳＥ意味論が実現される。
【０１３８】
Ｃｏｎｓｔｒａｉｎｅｄ  
目的：ＣＡＧに追加する目的でアクティビティをラップする。  
メタデータ：  
●  ラップされたアクティビティのイネーブルルール。  
●  ラップされたアクティビティのディセーブルルール。  
実行時プロパティ：  
●  ラップされたアクティビティが少なくとも１回完了しているかどうかを示す整数値。  
実行：  
制約されているアクティビティの唯一の許容される親はＣＡＧである。ＣＡＧ自体は、制約されているアクティビティでイネーブルおよびディセーブルルールを使用して、いつ実行するかを決定する。ＣｏｎｓｔｒａｉｎｅｄアクティビティがＣＡＧにより実行を指示された場合、それがラップするアクティビティを単に実行するだけである。  
Ｐｅｒｆｏｒｍｅｄプロパティは、制約アクティビティがその実行を完了するとインクリメントされる。親ＣＡＧ自体が再実行される場合のみ０にリセットされる（例えば、ＷｈｉｌｅＬｏｏｐまたは第２の外側のＣＡＧ内）。
【０１３９】
ＣＡＧ（Ｃｏｎｓｔｒａｉｎｅｄ  Ａｃｔｉｖｉｔｙ  Ｇｒｏｕｐ）  
目的：子Ｃｏｎｓｔｒａｉｎｅｄアクティビティの集合の制約ベースの実行を行う。  
メタデータ：  
●  完了ルール。  
実行：  
ＣＡＧは、制約アクティビティのみを含む。ＣＡＧは、実行されると、そのイネーブルおよびディセーブル制約の評価に基づいて子アクティビティを実行（および再実行）する。子アクティビティは、イネーブルルールがｔｒｕｅに評価され、ディセーブルルールがｆａｌｓｅに評価された場合のみＣＡＧによって実行される。特に、ＣＡＧは、部分ツリーを辿り、すべてのアクティビティに関してアクティビティ状態変更にサブスクライブし、これは呼び出し境界のところで停止する。ＣＡＧは、アクティビティが部分ツリーに動的に追加される場合にサブスクリプションを追加する。ＣＡＧは、囲むスコープおよびスケジュール境界までのすべての親スコープに対するデータ変更にサブスクライブするが、これらのサブスクリプションは、ＣＡＧ内のすべての制約アクティビティ上のイネーブルおよびディセーブルルールの分析により決定される。エンジンは、データ変更の一括処理通知を配信し、ＣＡＧは、評価すべきルールを決定する。呼び出されたスケジュールにより加えられたデータ変更は、その呼び出しが完了するとポストされることに注意されたい。それらの変数がコードビサイドメソッドを介して間接的にアクセスされる場合でもスコープ変数依存関係を識別することは可能である。したがって、変数が変更されたときにどの制約を再評価すべきかを決定する際に非常に特異的である可能性がある。宣言的ルールとコードルールの両方について、同じメカニズムが機能する。制約アクティビティにイネーブルルールがない場合、常にｔｒｕｅになるとみなす。
【０１４０】
制約アクティビティにディセーブルルールがない場合、常にＰｅｒｆｏｒｍｅｄ＞０になるとみなす。したがって、制約アクティビティ上でルールが指定されていない場合、ＣＡＧが実行され、再実行されることがない場合にすぐに実行される。同様に、制約アクティビティ上でカスタムイネーブルルールのみが用意される場合、そのイネーブルルールがｔｒｕｅに評価されたときに実行され、そのときのみ実行される。制約ベースの再実行が望まれている場合、適切なカスタムディセーブルルールを、適切なイネーブルルールとともに用意しなければならない。
【０１４１】
以下の表は、制約アクティビティを実行するために必要な条件をまとめたものである。
【０１４２】
【表５】
2006107477.tif 000007
【０１４３】
アクティビティの実行時に、そのアクティビティに対するディセーブルルールがｔｒｕｅに評価される場合、ＣＡＧはそのアクティビティの実行をキャンセルする。これは、そのアクティビティの再実行を除外するわけではない。ＣＡＧの完了ルールがｔｒｕｅに評価されるとすぐに、ＣＡＧは、現在実行中の子アクティビティを直ちにキャンセルした後、それ自体完了する。すべてのルール（イネーブル、ディセーブル、完了）は、そのデータおよび状態変更依存関係に基づいて必要な場合であれば必ず評価される。
【０１４４】
ＣＡＧは、ＰｒｅｖｉｅｗとＥｄｉｔの２つのオペレーションモードを持つ。ＣＡＧデザイナがＰｒｅｖｉｅｗモードであれば、開発者は、フィルムストリップを表示するアクティビティを選択することだけできる。プロパティブラウザは、開発者がアクティビティを選択していた場合に、ＥｎａｂｌｅおよびＤｉｓａｂｌｅルールオプション（後述）を公開する。これにより、開発者は、ＣＡＧを使用してそれぞれのアクティビティに対してイネーブルおよびディセーブルルールを設定することができる。ＣＡＧデザイナがＤｅｓｉｇｎモードであれば、開発者は、プレビューウィンドウ内のアクティビティ（Ｃｏｎｓｔｒａｉｎｅｄと呼ぶ）をクリックすることができる。プロパティブラウザは、その後、特定のアクティビティにより通常は公開されるプロパティに加えて、ＥｎａｂｌｅおよびＤｉｓａｂｌｅルールオプション（プレビューモードのように）を表示する。
【０１４５】
ＣＡＧデザイナは、以下の幾つかの追加コンテキストメニューオプションを備える。  
Ｐｒｅｖｉｅｗ  Ａｃｔｉｖｉｔｙ  
選択されたアクティビティが与えられると、ＣＡＧはＤｅｓｉｇｎ  ＭｏｄｅからＰｒｅｖｉｅｗ  Ｍｏｄｅに切り換わる。
Ｅｄｉｔ  Ａｃｔｉｖｉｔｙ  
選択されたアクティビティが与えられると、ＣＡＧはＰｒｅｖｉｅｗ  ＭｏｄｅからＤｅｓｉｇｎ  Ｍｏｄｅに切り換わる。  
Ｖｉｅｗ  Ｐｒｅｖｉｏｕｓ  Ａｃｔｉｖｉｔｙ  
フィルムストリップ内で現在選択されているアクティビティの直前のアクティビティに移動する。ＣＡＧフィルムストリップ内の第１のアクティビティに達すると、このメニューオプションは無効にされる。  
Ｖｉｅｗ  Ｎｅｘｔ  Ａｃｔｉｖｉｔｙ  
フィルムストリップ内で現在選択されているアクティビティの直後のアクティビティに移動する。ＣＡＧフィルムストリップ内の最後のアクティビティに達すると、このメニューオプションは無効にされる。
【０１４６】
一実施形態では、ＣＡＧ内のそれぞれのアクティビティは「制約アクティビティ」の中にラップされる。これは、その後、ＣＡＧのフィルムストリップを介して開発者に公開される。ＣＡＧがプレビューモードに入っており、開発者がこのアクティビティを選択して、それをコピーした場合、貼り付けられる（したがって、その結果のコンテキストメニューが有効にされる）唯一の場所は他のＣＡＧ内である。しかし、開発者がＣＡＧモードを「Ｄｅｓｉｇｎ」に切り換えて、プレビューペイン内でアクティビティを選択した場合、コピー／貼り付けおよびドラッグ＆ドロップは、残りのアクティビティと同様に有効にされる。
【０１４７】
Ｔａｓｋ  
目的：１つまたは複数のプリンシパルにより実行される外部作業単位をモデル化する。ＩｎｖｏｋｅＳｃｈｅｄｕｌｅまたはカスタムアクティビティのいずれかであるテンプレートアクティビティをラップする。  
メタデータ：  
●  並列または順次のいずれの実行であるかを示す実行モード。  
●  基本タスク実行の型（テンプレートと呼ばれる）。  
●  タスクの受託者を示すロール。  
●  開発者が受託者ベースでタスクプロパティを設定できるようにするオプションのコードビサイドメソッド。  
実行：  
タスクが実行されると、まず、ロールがプリンシパル（受託者）の集まりに解決される。ロールが空の場合、例外がスローされる。その後、受託者毎に１回、テンプレートアクティビティのクローンが作成され、そのクローンのプロパティを初期化するオプションのコードビサイドメソッド（例を以下に示す）が、もし存在すれば呼び出される。実行モードに応じて、個々の受託者タスクが、その後、並列実行または順次実行される。これを達成するために、それぞれの受託者タスク（クローン）は、適切なイネーブルおよびディセーブルルール集合により制約アクティビティ内に実際にラップされる。実行モードが順次の場合、順序は、ロール解決により返される受託者の順序付けにより決定される。ＣＡＧ（タスクの親アクティビティ）の場合のように、完了ルールがｔｒｕｅになった場合、タスクは完了し、未処理のクローンはキャンセルされる。そうでない場合、タスクは、すべての受託者タスク（クローン）が完了すると完了する。
【０１４８】
Ｅｖｅｎｔ  Ｄｒｉｖｅｎ  
目的：実行が「イベント」アクティビティによりトリガされるアクティビティをラップする。  
実行：  
ＥｖｅｎｔＤｒｉｖｅｎアクティビティは、ＬｉｓｔｅｎまたはＥｖｅｎｔＨａｎｄｌｅｒｓのいずれかの複合アクティビティである親を持たなければならない。ＥｖｅｎｔＤｒｉｖｅｎアクティビティは、ＩＥｖｅｎｔＡｃｔｉｖｉｔｙおよび任意の型の第２のアクティビティの両方を含む。ＩＥｖｅｎｔＡｃｔｉｖｉｔｙは、定義により、タイマーの発火またはメッセージの到着などの何らかのイベントの発生を待つ間ブロックする。イベントが発生すると、ＩＥｖｅｎｔＡｃｔｉｖｉｔｙはその実行を完了し、その後、第２のアクティビティが実行される。  
Ｅｖｅｎｔ  Ｄｒｉｖｅｎ（一般的にＥｖｅｎｔＨａｎｄｌｅｒｓまたはＬｉｓｔｅｎアクティビティ内にある）の選択後、Ｍｏｖｅ  Ｌｅｆｔ（選択されたＥｖｅｎｔＤｒｉｖｅｎを条件節のすぐ左に移動する）およびＭｏｖｅ  Ｒｉｇｈｔ（選択されたＥｖｅｎｔＤｒｉｖｅｎを条件節のすぐ右に移動する）の２つの追加コンテキストメニューオペレーションが表示される。
【０１４９】
Ｌｉｓｔｅｎ  
目的：ｎ個の子ＥｖｅｎｔＤｒｉｖｅｎアクティビティの１つを条件付きで実行する。  
実行：  
Ｌｉｓｔｅｎアクティビティにより、ＩＥｖｅｎｔＤｒｉｖｅｎ子のイベントを発生させるその子ＥｖｅｎｔＤｒｉｖｅｎアクティビティのうちの最初のもののみが実行を許される。他はすべてキャンセルされる。概念的には、Ｌｉｓｔｅｎは、分岐の選択が手続き的ビジネスロジックではなくイベントの発生により決定される場合にｎ子の分岐のうちのちょうど１つが実行されるという点でＣｏｎｄｉｔｉｏｎａｌに類似している。
【０１５０】
Ｅｖｅｎｔ  Ｈａｎｄｌｅｒｓ  
目的：ＥｖｅｎｔＤｒｉｖｅｎアクティビティの集合をラップする。ＥｖｅｎｔＨａｎｄｌｅｒｓアクティビティは、単純に、ＥｖｅｎｔＤｒｉｖｅｎアクティビティの集合を保持し、これを関連するＳｃｏｐｅが使用する。ＥｖｅｎｔＨａｎｄｌｅｒｓアクティビティは、Ｓｃｏｐｅにしか関連付けることができない。
【０１５１】
Ｅｘｃｅｐｔｉｏｎ  Ｈａｎｄｌｅｒ  
目的：スコープに対するキャッチブロックを表すメタデータでアクティビティをラップする。  
メタデータ：  
●  キャッチブロックの型を示す列挙型。  
○  Ａｌｌ−すべての例外を捕捉する  
○  Ｔｙｐｅ−指定された型の例外を捕捉する  
○  Ｖａｒｉａｂｌｅ−指定された型の例外を捕捉し、コードビサイドのローカル変数内で例外を検査に利用できるようにする  
●  捕捉された例外の型を示すプロパティ（ｅｎｕｍがＴｙｐｅに設定されている場合のみ使用される）  
●  例外が預けられるローカル変数への参照（ｅｎｕｍがＶａｒｉａｂｌｅに設定されている場合のみ使用される）  
実行：  
ＥｘｃｅｐｔｉｏｎＨａｎｄｌｅｒアクティビティは、一実施形態では、ＥｘｃｅｐｔｉｏｎＨａｎｄｌｅｒｓアクティビティにしか追加できない。ＥｘｃｅｐｔｉｏｎＨａｎｄｌｅｒｓアクティビティに関連付けられているＳｃｏｐｅは、ＥｘｃｅｐｔｉｏｎＨａｎｄｌｅｒアクティビティの集合に関するメタデータを使用して、Ｓｃｏｐｅが例外を受け取ったときにどれを実行するかを決定する。ＥｘｃｅｐｔｉｏｎＨａｎｄｌｅｒアクティビティがＳｃｏｐｅにより実行を指示された場合、それがラップするアクティビティを単に実行するだけである。ＥｘｃｅｐｔｉｏｎＨａｎｄｌｅｒｓの選択後、Ｖｉｅｗ  Ｐｒｅｖｉｏｕｓ  Ａｃｔｉｖｉｔｙ、Ｖｉｅｗ  Ｎｅｘｔ  Ａｃｔｉｖｉｔｙの２つの追加コンテキストメニューオペレーションが表示される。
【０１５２】
Ｅｘｃｅｐｔｉｏｎ  Ｈａｎｄｌｅｒｓ  
目的：ＥｘｃｅｐｔｉｏｎＨａｎｄｌｅｒアクティビティの順序付き集合をラップする。ＥｘｃｅｐｔｉｏｎＨａｎｄｌｅｒｓアクティビティは、単純に、ＥｘｃｅｐｔｉｏｎＨａｎｄｌｅｒアクティビティの集合を保持し、これを関連するＳｃｏｐｅが使用する。ＥｘｃｅｐｔｉｏｎＨａｎｄｌｅｒｓアクティビティは、一実施形態では、Ｓｃｏｐｅにしか関連付けることができない。２つ以上のＥｘｃｅｐｔｉｏｎＨａｎｄｌｅｒアクティビティが存在する場合、「Ｍｏｖｅ  Ｌｅｆｔ」および「Ｍｏｖｅ  Ｒｉｇｈｔ」コンテキストメニューオプションが有効にされる。
【０１５３】
Ｃｏｍｐｅｎｓａｔｅ  
目的：完了した子スコープを補正する。  
メタデータ：  
●  補正する子スコープのＩＤ。  
実行：  
Ｃｏｍｐｅｎｓａｔｅアクティビティは、スコープに対する補正ハンドラまたは例外ハンドラ内にしか存在しえない。その目的は、完了した子スコープの補正ハンドラをトリガすることである。
【０１５４】
Ｃｏｍｐｅｎｓａｔｉｏｎ  Ｈａｎｄｌｅｒ  
目的：スコープに対する補正ハンドラとして定義されている子アクティビティをラップする。  
実行：  
その子アクティビティを実行する。ＣｏｍｐｅｎｓａｔｉｏｎＨａｎｄｌｅｒアクティビティは、Ｓｃｏｐｅにしか関連付けることができない。
【０１５５】
Ｓｃｏｐｅ  
目的：スコープは、トランザクション境界、例外処理境界、補正境界、イベント処理境界、およびメッセージ、変数、相関関係集合、およびチャネル宣言の境界（つまり、共有データ状態）である。スコープアクティビティは、論理的コンテナとして動作するアクティビティのグループである。多くの場合、スコープの目的はトランザクション意味論をアクティビティの囲まれている集合に適用することである。
メタデータ：  
●  スコープのコードビサイドクラスのＴｙｐｅ。  
●  スコープが同期したスコープかどうかを示す論理値。  
●  スコープのトランザクション特性に関係する複数のプロパティ。  
○  トランザクションの型：なし、アトミック、または長時間実行  
○  孤立レベル（トランザクションがアトミックの場合）  
□  Ｃｈａｏｓ：孤立度の高いトランザクションからの保留変更は、上書きできない。  
□  ＲｅａｄＣｏｍｍｉｔｔｅｄ：ダーティリードを避けるため、共有ロックはデータの読み込み中保留にされるが、データは、トランザクションが終了する前に変更することができ、そのため、繰り返し不可能な読み込みまたはファントムデータが生じる。
【０１５６】
□  ＲｅａｄＵｎｃｏｍｍｉｔｔｅｄ：ダーティリードは可能である、つまり、共有ロックは発効されず、排他的ロックも受け付けない。  
□  ＲｅｐｅａｔａｂｌｅＲｅａｄ：クエリで使用されるすべてのデータにロックがかけられ、他のユーザはデータの更新を行えなくなる。繰り返し不可能な読み込みを防止するが、ファントム行はそれでも可能である。  
□  Ｓｅｒｉａｌｉｚａｂｌｅ：ＤａｔａＳｅｔに範囲ロックがかけられ、トランザクションが完了するまで、他のユーザは行を更新したり行をデータセット内に挿入したりできない。  
□  Ｓｎａｐｓｈｏｔ：一方のアプリケーションが、他方のアプリケーションが同じデータを修正している間に読み込むことができるデータのバージョンを格納することによりブロッキングを低減する。一方のトランザクションからは、再度クエリを実行しても、他のトランザクションで行った変更を見ることはできないことを示す。  
□  Ｕｎｓｐｅｃｉｆｉｅｄ：指定されたのと異なる孤立レベルが使用されているが、そのレベルは決定できない。  
○  秒単位のタイムアウト（トランザクションがアトミックの場合）  
○  トランザクションがリトライ可能かどうか（トランザクションがアトミックの場合）  
○  トランザクションがバッチ処理可能かどうか（トランザクションがアトミックの場合）  
○  タイムアウト値を示すＤａｔｅＴｉｍｅを返すコードビサイドメソッド（トランザクションが長時間実行の場合）  
□  スコープが実行を開始した場合に実行されるコードビサイドメソッド。これは、本質的に、スコープ内の第１のアクティビティとしてＣｏｄｅアクティビティと同等である。このメソッドは、スコープに対するイベントハンドラが実行できる前に完了することが保証される。ここで例外は、スコープの内側のＣｏｄｅアクティビティ内の例外としてのみ取り扱われる。  
□  スコープが実行を終了した場合に実行されるコードビサイドメソッド。これは、スコープ内の最後のアクティビティとしてＣｏｄｅアクティビティとほぼ同等であり、このコードは、インスタンス化されたイベントハンドラがその実行を終了した後にしか実行されない。ここで例外は、スコープの内側のＣｏｄｅアクティビティ内の例外としてのみ取り扱われる。  
□  イベントハンドラのオプションの集合。  
□  例外ハンドラのオプションの順序付き集合（アトミックトランザクションであるスコープについては有効でない）。  
□  オプションの補正ハンドラ。
実行：  
Ｓｃｏｐｅ内のアクティビティの実行は順次であり、したがって、含まれているアクティビティは、Ｓｅｑｕｅｎｃｅの場合のように、スコープが構築されたときに明示的に順序付けられる。他の複合型のように、スコープは、いくつかの制限に従って、ネストすることができる。開発者がスコープ内で宣言されていない型を参照しているが、そのスコープ内の任意のプロパティに対する型である場合、そのプロパティは、プロパティブラウザ内の外側の呼び出しスケジュール名で完全に修飾される。通常の状況では、Ｓｃｏｐｅアクティビティは、単に、「主」子アクティビティだけでなく、発火するそのイベントハンドラのどれかをも実行する。ＯｎＳｃｏｐｅＩｎｉｔｉａｌｉｚｅｄコードビサイドメソッドが指定されている場合、そのメソッドは、スコープの内側にある最初のアイテムとしてＣｏｄｅアクティビティであるかのように実行される。イベントハンドラは、Ｓｃｏｐｅの「主」子アクティビティと同時実行され、Ｓｃｏｐｅの実行のオプションではあるが通常の態様と考えられる。Ｌｉｓｔｅｎアクティビティのように、イベントハンドラ内の第１のアクティビティはＩＥｖｅｎｔＡｃｔｉｖｉｔｙでなければならない。通常、これは、受信アクティビティまたはＤｅｌａｙのいずれかであるが、適切なインターフェイスを実装するどのようなカスタマーアクティビティでもよい。特定のイベントハンドラが、所定のＳｃｏｐｅについて複数回実行できるが、イベントハンドラのそれらのインスタンスは同時実行することも可能である。新しいインスタンスは、各イベントハンドラについて発火する「イベント」毎に作成されることが保証される。Ｓｃｏｐｅの「主」子アクティビティがその実行を完了した場合、すべての現在実行中のイベントハンドラインスタンスは、その実行を通常通り終了することができる。しかし、どのイベントハンドラの新しいインスタンスも、その後作成されない。ＯｎＳｃｏｐｅＣｏｍｐｌｅｔｅｄコードビサイドメソッドが指定されている場合、そのメソッドは、スコープの本体が終了し、未処理のイベントハンドラすべてが終了した後に実行される。
【０１５７】
本質的に、スコープのＯｎｌｎｉｔｉａｌｉｚｅｄおよびＯｎＣｏｍｐｌｅｔｅｄメソッドは、必ずスコープの内側にある。得られる唯一の「特別な処理」は以下のとおりである。  
□  ＯｎＩｎｉｔｉａｌｉｚｅｄメソッドが完了する前に起動できるイベントハンドラはない  
□  ＯｎＣｏｍｐｌｅｔｅｄメソッドは、現在実行中のすべてのイベントハンドラが完了するまで実行されない（Ｓｃｏｐｅの本体とともに）
□  ＯｎＣｏｍｐｌｅｔｅｄメソッドが起動すると、イベントハンドラはもはや実行できない。イベントハンドラ内で発生する例外は、Ｓｃｏｐｅの「主」子アクティビティ内で生じる例外と全く同じように取り扱われる。Ｓｃｏｐｅが同期Ｓｃｏｐｅとマークされている場合、これは、共有データに対する同時実行アクセスを安全に行えることを保証する。同期スコープはネストできない。（両方とも外部の）同じ共有データにアクセスする同期スコープは、そのデータに対する読み書きオペレーションの結果が、スコープが逐次実行された場合と異ならないように保証される。Ｓｃｏｐｅは、さらに、例外処理境界として働く、つまり、Ｓｃｏｐｅの例外ハンドラは、スコープ内のネストされているすべてのアクティビティにより共有される（イベントハンドラも含む）。例外が非アトミックＳｃｏｐｅ内の実行アクティビティによりスローされた場合、スコープは他のすべての実行アクティビティおよびイベントハンドラインスタンスをキャンセルし、その後、その例外を捕捉できる例外ハンドラがあればその例外を処理する。例外ハンドラが実行された後、Ｓｃｏｐｅは完了するが、Ｆａｉｌｅｄの結果が返される。特定の例外型について非アトミックスコープに対し例外ハンドラが定義されていない場合、または例外ハンドラが例外をスローした場合、子スコープの完了の逆順に子スコープに対しインストールされているすべての補正ハンドラ（以下を参照）を実行する既定のハンドラが（捕捉されないすべての例外について）作成され、その後、例外をその親Ｓｃｏｐｅに再スローする。
【０１５８】
アトミックスコープは、関連する例外ハンドラを持ちえない。アトミックスコープの実行時に例外が発生した場合、そのスコープの実行のように、トランザクションは失敗する。スコープは、それ自体、例外を処理することができる、次の外側の囲むスコープに伝播する例外を発生する。実行が通常通り完了するＳｃｏｐｅ（例外が発生していないことを意味する）では、補正ハンドラを「インストール」されている。この補正ハンドラは、その後、Ｃｏｍｐｅｎｓａｔｅアクティビティを介して、親スコープの例外ハンドラ、または親スコープの補正ハンドラのいずれかの内から呼び出すことができる。完了したスコープについて補正ハンドラが定義されていない場合、子スコープに対するインストールされているすべての補正ハンドラを、それらの子スコープの完了の逆順で実行する既定のハンドラがインストールされる。上で述べたように、補正は、何らかの例外ハンドラのコンテキストでのみ発生する。補正ハンドラの実行時に例外が発生した場合、その例外は、その例外ハンドラ内の例外として取り扱われる。  
標準コンテキストメニューオプションに加えて、Ｓｃｏｐｅアクティビティは、以下の追加メニューオプションを公開する。
【０１５９】
Ｖｉｅｗ  Ｓｃｏｐｅ  
これは、デザイナに追加した場合のスコープの既定のビューである。このオプションを選択すると、開発者はこのビューに戻ることができる。
【０１６０】
Ｖｉｅｗ  Ｅｘｃｅｐｔｉｏｎｓ  
このオプションを選択すると、ＵＩがインプレースで変更され、Ｓｃｏｐｅに関連付けられている例外が表示される。これは、Ｔｒａｎｓａｃｔｉｏｎ  ＴｙｐｅがＬｏｎｇ  Ｒｕｎｎｉｎｇ（長時間実行）またはＮｏｎｅ（なし）の場合にのみ有効にされる。言い換えると、このメニューは、Ｔｒａｎｓａｃｔｉｏｎ  ＴｙｐｅがＡｔｏｍｉｃ（アトミック）の場合には利用できないということである。
【０１６１】
Ｖｉｅｗ  Ｅｖｅｎｔｓ  
このオプションを選択すると、ＵＩがインプレースで変更され、Ｓｃｏｐｅに関連付けられているイベントハンドラが表示される。
【０１６２】
Ｖｉｅｗ  Ｃｏｍｐｅｎｓａｔｉｏｎ  
このオプションを選択すると、ＵＩがインプレースで変更され、Ｓｃｏｐｅで定義されているＣｏｍｐｅｎｓａｔｉｏｎが表示される。これは有効のみである（Ｔｒａｎｓａｃｔｉｏｎ型プロパティがＬｏｎｇ  ＲｕｎｎｉｎｇまたはＡｔｏｍｉｃに設定されている場合）。
【０１６３】
Ｓｃｈｅｄｕｌｅ  
目的：Ｓｃｈｅｄｕｌｅは、オーケストレーションエンジンが実行する唯一の最上位レベルのアクティビティである。  
メタデータ（Ｓｃｏｐｅメタデータに加えて）：  
●  スケジュール型のＮａｍｅｓｐａｃｅ。  
●  スケジュールがスタンドアロンアプリケーションであるか、ライブラリであるかを示すＣｏｍｐｉｌａｔｉｏｎＴｙｐｅ列挙型（他のスケジュールから呼び出されることを意味する）。  
●  ＸＯＭＬ形式によるスケジュール全体の表現。  
●  パラメータ宣言。  
実行：  
ＩｎおよびＯｐｔｉｏｎａｌ−Ｉｎパラメータを消費し、Ｏｕｔパラメータを生成する必要があること以外に、ＳｃｈｅｄｕｌｅはＳｃｏｐｅと全く同じように実行する。  
パラメータ：  
スケジュールのメタデータの一部は、その実行に加わるパラメータの集合である。  
複合アクティビティ  
制御フローを使用可能にする複合アクティビティ型は、Ｓｅｑｕｅｎｃｅ、Ｐａｒａｌｌｅｌ、Ｃｏｎｓｔｒａｉｎｅｄ  Ａｃｔｉｖｉｔｙ  Ｇｒｏｕｐ、Ｃｏｎｄｉｔｉｏｎａｌ、Ｗｈｉｌｅ、Ｌｉｓｔｅｎである。さらに、ＳｃｏｐｅおよびＳｃｈｅｄｕｌｅは、中にあるアクティビティの暗黙のシーケンス動作を含むコンテナとして動作する複合アクティビティ型である。
ＩＤおよびＤｅｓｃｒｉｐｔｉｏｎプロパティ  
すべてのアクティビティは、ＩＤおよびＤｅｓｃｒｉｐｔｉｏｎプロパティを提供する。ツールボックスからアクティビティをデザインサーフェスにドラッグすると、このＩＤが自動的に生成される。Ｄｅｓｃｒｉｐｔｉｏｎプロパティは、開発者が入力するためのプレースホルダである。通常の使用シナリオでは、開発者が条件の特別分岐の使用目的に関する短い説明を与える必要があるであろう。概念的には、このプロパティを、Ｖｉｓｕａｌ  ＢａｓｉｃおよびＣ＃のコードエディタにおける／／と等価なものと考える。
【０１６４】
ヘルプテキスト  
プロパティブラウザでプロパティを選択した場合、開発者は、Ｆ１キーを押して、そのプロパティに関するオンラインヘルプの索引を表示できる。各アクティビティの各プロパティは、関連するヘルプテキストを用意している。
【０１６５】
タスクエラーリストおよびプロパティブラウザの統合  
アクティビティのプロパティが十分に構成されていない場合、開発者に対し、感嘆符を含むアイコンが提示される。その後、アイコンをクリックし、構成エラーのドロップダウンリストを表示することができる。それらのエラーのうちの１つを選択すると、フォーカスはＰｒｏｐｅｒｔｉｅｓ  Ｂｒｏｗｓｅｒに移動し、エラーのあるプロパティがハイライト表示される。アクティビティのプロパティが完了すると、アイコンが消える。エラーのある構成は、「Ｔａｓｋ  Ｌｉｓｔ」にも表示される。Ｔａｓｋ  Ｌｉｓｔ内に提示されているエラーメッセージをダブルクリックすると、開発者は、プロパティブラウザ内のプロパティに直接進む。
【０１６６】
ＩＤ生成  
デザイナに追加されるアクティビティの指定の識別子は、すでに存在する類似のアクティビティの数に基づいて作成される。アクティビティの追加および削除が行われると、範囲内のオープンスロットにより識別子が作成される。例えば、追加される第１のＳｅｎｄアクティビティは、識別子を「１」として持つ。第２は「２」、いったように続く。しかし、５つのＳｅｎｄアクティビティが存在する場合、開発者は番号３を（削除または切り取りで）削除し、その後他のＳｅｎｄを再び追加し（コピー／切り取り／貼り付けまたはツールボックスを通じて）、識別子は「３」でなければならない。
【０１６７】
ＩＤの有効な名前  
開発者は、プロジェクトの言語で有効なＩＤに対する名前を与えることができる（エスケープされた有効な名前を含む）。
【０１６８】
アクティビティの複数選択  
開発者は、アクティビティのグループを選択し、それらをスケジュールの他の領域に移動することを望むことが多い。これは、アクティビティレベルによりアクティビティについて遂行可能であるが、開発者が一度に複数のアクティビティを選択し、それらをこの新しい領域にドラッグする可能性が高い。
【０１６９】
これらのアクティビティが同じ型である場合、プロパティブラウザは有効にされ、共通プロパティの大規模な構成を行うことができる。例えば、選択されたすべてのアクティビティが制約アクティビティグループである場合、Ｃｏｍｐｌｅｔｉｏｎ  Ｃｏｎｄｉｔｉｏｎプロパティは、開発者による構成に利用できる。
【０１７０】
開発者がさまざまな異なる型を選択した場合、プロパティブラウザでは、アクティビティが共有するプロパティを構成することのみできる（例えば、ＩＤおよび記述）。複数選択では、選択されたアクティビティは、アクティビティのコーナーのところに青色インジケータを飾られる。これらのインジケータは、青色ドットとして示される。キーボードフォーカスを持つアクティビティは違う飾り付けをされる。これは、中身の詰まった塗りつぶし対中空の塗りつぶしであり、フォーカスのあたっているアクティビティであることを示す。
【０１７１】
ハンドラおよび変数生成  
多くのアクティビティが、コードビサイドで変数および／またはコードハンドラを生成するプロパティを公開する。いずれかがアクションを実行するプロパティはすべて、アクティビティ毎にプロパティブラウザ統合で呼び出される。開発者がプロパティブラウザを介して新しい変数またはハンドラ名を指定する場合、新しい変数またはハンドラの作成が実行される。例えば、Ｓｅｎｄに対するメッセージ変数である。型Ｓｙｓｔｅｍ．Ｓｔｒｉｎｇの「ｍ１」を指定すると、その結果得られるコードビサイドは、以下のようになる。  
public OEMessage<System.String> m1 = new OEMessage<System.String>();
コードビサイド変数またはハンドラを作成するプロパティに対する他の値を指定することにより、新しい変数またはハンドラが作成される。既存の変数／ハンドラは変更なしである。生成された変数（またはそれぞれのハンドラ）の削除は開発者の責任において行う。開発者がコードビサイド内の既存の変数の名前を変更するシナリオでは、それを参照するアクティビティは更新されない。これもまた、この新しい変数でオリジナルの変数を参照したそれぞれのアクティビティの更新は、開発者の責任で行う。
【０１７２】
特定のアクティビティのハンドラに適用される場合の複数のスケジュールにまたがるコピー／貼り付けおよびドラッグ−ドラッグオペレーションは、それらに関連するハンドラには適用されない。Ｓｃｏｐｅｓに適用される場合、変数およびコードハンドラの生成は、少し異なる挙動を示す。より具体的には、生成された変数およびコードハンドラは、Ｓｃｏｐｅ  Ｃｌａｓｓの定義内に置かれる。すべてのｐｒｉｖａｔｅ、ｐｒｏｔｅｃｔｅｄ、ｉｎｔｅｒｎａｌ、およびｐｕｂｌｉｃメソッドおよび変数は、アクティビティのスコープからのものであり、そのアクティビティについて設定できる（型およびシグネチャが一致する限り）。すべてのｐｕｂｌｉｃおよびｉｎｔｅｒｎａｌメソッドおよび変数は、アクティビティの囲むスコープからのものであり、現在はそのアクティビティについて正当に設定できる（型およびシグネチャが一致する限り）。
その結果、メニューから、またはプロパティブラウザからこれらの変数およびハンドラを作成する一方で、ルールは以下のとおりである。  
●  変数またはメソッドがアクティビティのスコープ内で作成される場合、それは作成されたｐｒｉｖａｔｅである。  
●  変数またはメソッドがアクティビティの囲むスコープのどれかで作成される場合、それは作成されたｐｕｂｌｉｃである。
【０１７３】
コンテキストメニュー  
アクティビティを右クリックすると、関連付けられたデザイナは開発者向けにアクティビティ特有のアクションを表示する。例えば、スコープを右クリックすると、「Ｖｉｅｗ  Ｓｃｏｐｅ，  Ｖｉｅｗ  Ｅｘｃｅｐｔｉｏｎｓ，  Ｖｉｅｗ  Ｅｖｅｎｔｓ」が標準の「Ｖｉｅｗ  Ｃｏｄｅ」、Ｃｕｔ／Ｃｏｐｙ／Ｐａｓｔｅパラメータに加えて表示される。
【０１７４】
以下に、共通点に基づいて実行できる可能なアクションの一覧を示す。  
Ｖｉｅｗ  Ｃｏｄｅ  
選択されたアクティビティに関連付けられたコードを表示する。アクティビティが選択され、ハンドラが指定されている場合、このオプションを選択すると、開発者に対し指定ハンドラが示される。  
Ｃｕｔ  
デザイナから選択されたアクティビティを削除し、それをクリップボードにコピーする。  
Ｃｏｐｙ  
選択されたアクティビティをクリップボードにコピーする。  
Ｐａｓｔｅ  
最後にコピーされたアクティビティをクリップボードからデザイナに貼り付ける。選択領域が選択されていない場合、アクティビティは、スケジュール内のアクティビティとしてコピーされる。  
Ｄｅｌｅｔｅ  
選択されたアクティビティを削除する。  
Ｐｒｏｐｅｒｔｉｅｓ  
選択されたアクティビティについてＰｒｏｐｅｒｔｙ  Ｂｒｏｗｓｅｒに対する初期値設定およびフォーカス設定を行う。  
Ｇｅｎｅｒａｔｅ  Ｈａｎｄｌｅｒｓ  
選択されたアクティビティの対応するハンドラを生成する。
Ｅｘｐａｎｄ  
デザイナを展開し、その構成部分を公開する。  
Ｃｏｌｌａｐｓｅ  
デザイナを縮小し、その構成部分を隠す。
【０１７５】
Ｈｏｔｌｉｎｋ／Ｈｙｐｅｒｌｉｎｋ  Ｐｒｏｐｅｒｔｙ  Ｂｒｏｗｓｅｒの統合  
それぞれのアクティビティは、コンテキストメニューオプションをＰｒｏｐｅｒｔｙ  Ｂｒｏｗｓｅｒ内のＨｙｐｅｒｌｉｎｋｓとして用意する。すべてのプリミティブアクティビティについて、これは「Ｇｅｎｅｒａｔｅ  Ｈａｎｄｌｅｒｓ」を含む。それぞれの複合アクティビティは、「Ｅｘｐａｎｄ／Ｃｏｌｌａｐｓｅ」およびそのアクティビティに特有のコンテキストメニューオプションを提供する。これらについては、アクティビティレベル毎に詳述する。
【０１７６】
アクティビティのコメント作成  
オーケストレーションエンジンデザイナでは、ユーザは複雑な階層型スケジュールを作成することができる。これらのスケジュールは、非常に複雑でデビューが難しい場合がある。コメント作成機能を使用すると、ユーザはコメントされたアクティビティが実行時に実行されないようにスケジュールの一部をコメントアウトすることができる。これにより、デバッグが簡素化され、ユーザは一度にスケジュールの一部の実行を監視することができる。アクティビティは、Ｂｏｏｌｅａｎプロパティを公開し、スケジュールからの「擬似」削除を実行できる。このアクティビティは、まだスケジュール内に存在するが、実行時に、その存在は無視され、実行されない。開発者は、Ｐｒｏｐｅｒｔｙ  Ｂｒｏｗｓｅｒで公開されているプロパティを設定し、コンテキストメニューを介して、コメント作成機能の有効／無効を設定することができる。
【０１７７】
コメント作成機能は、設計時の関係があるだけでなく実行時にも関係がある。ユーザは、プログラムによりアクティビティにコメントを付けることができるだけでなく、デザイナが備えるユーザインターフェイスを使用することもできる。デザイナを使用すると、ユーザは、形状を選択し、プロパティブラウザを使用して、コメントプロパティをｔｒｕｅに設定し、アクティビティのラバーバンディングおよび複数選択を行い、コンテキストメニューでコメントメニューを選択することにより形状にコメントを付けることができる。コメントに対する応答として、デザイナはアクティビティデザイナを半透明にする。ユーザがアクティビティデザイナを選択し、それのプロパティを設定することが可能である。Ｘｏｍｌは、引き続き、コメントされた形状を持つが、唯一の違いは、コメントプロパティがｔｒｕｅに設定されることである。設計時バリデーションは、コメントされたアクティビティをスキップし、それらのアクティビティが存在していないかのように振る舞う。実行時に、オーサリングオブジェクトモデルは、アクティビティおよび実行可能アクティビティを返す２つのコレクションを提供する。ランタイムは、実行可能アクティビティに作用する。
【０１７８】
付録Ｂ  
付録Ｂでは、アクティビティデザイナインターフェイスの実施例を説明する。
【０１７９】
アクティビティデザイナ  
ＩＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒインターフェイスは、ワークフローに参加する必要があるすべてのアクティビティデザイナにより実装される。これは、デザイナが他のデザイナおよびワークフロービューと対話するためのプロトコルである。ワークフロービューは、ＩＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒインターフェイスを探し、イベントのレンダリング、レイアウト、またはデザイナへの転送を行う。ＩＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒインターフェイスをサポートすることで、すべてのデザイナは、デザイナが実際にはウィンドウコントロールから派生しないとしてもウィンドウコントロールのように動作することができる。このインターフェイスを使用すると、さらに、ワークフロービューおよび装飾サービス、メニューコマンドサービスのような他のデザイナインフラストラクチャも、デザイナと情報をやり取りすることができる。ＩＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒインターフェイスから派生されたデザイナは、階層を持ち得ないが、階層を持つためには、デザイナは、ＩＣｏｍｐｏｓｉｔｅＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒインターフェイスを実装する必要がある。以下に、ＩＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒの定義を、プロパティおよびメソッドに関する詳細とともに示す。
【０１８０】
【表６−１】
2006107477.tif 000008
【０１８１】
【表６−２】
2006107477.tif 000009
【０１８２】
ＩＣｏｍｐｏｓｉｔｅＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒ：  
ＩＣｏｍｐｏｓｉｔｅＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒは、階層を持ちうる、つまり子を持ちうるデザイナによって実装される。複合デザイナは、それ自身とその子すべてを保持する必要がある。ＩＣｏｍｐｏｓｉｔｅＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒインターフェイスを使用することで、複合デザイナは、その子に関する情報を公表し、子デザイナの追加および削除を行う機能を提供し、キーボードナビゲーションを有効にする。以下に、ＩＣｏｍｐｏｓｉｔｅＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒの定義を、プロパティおよびメソッドに関する詳細とともに示す。
【０１８３】
【表７】
2006107477.tif 000010
【０１８４】
単純デザイナ  
ＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒクラスは、デザイナの最も単純な実装を表す。ワークフロー内のアクティビティに関連付けられたすべてのデザイナは、ＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒから派生する。ＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒクラスは、ＩＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒインターフェイスから継承し、そのインターフェイスの既定の実装を提供する。ワークフロービューは、ＩＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒインターフェイスを使用してデザイナと対話する。ＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒクラスは、通常、デザイナの描画のため超軽量実装を必要とするデザイナによって継承される。これらのデザイナには、子または階層がない。アクティビティデザイナが備える機能としては、基本レイアウトロジック、レンダリングサポート（例えば、アイコン、説明、枠線、内部、および背景を描画することによる）、ヘルプテキストのレンダリング、すべてのデザイナにより必要とされる既定のグリフを返すこと、ＤｅｓｉｇｎｅｒＶｅｒｂｓを介したコンテキストメニューの表示、設計時特有のプロパティのフィルタ処理、既定のイベント発生、既定のヒットテスト、バリデーションのトリガ、ツールチップの表示、およびキーボードナビゲーションへの参加がある。  
public abstract class ActivityDesigner:ComponentDesigner, IActivityDesigner
【０１８５】
【表８】
2006107477.tif 000011
【０１８６】
複合デザイナ  
ＣｏｍｐｏｓｉｔｅＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒは、階層を持つデザイナである（例えば、下に子がいる）。ＣｏｍｐｏｓｉｔｅＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒは、それ自体のすべての態様だけでなくその子をも管理する役割を持つ。これは、さらに、イベントを転送するためにその子と情報のやり取りをする必要もある。ＣｏｍｐｏｓｉｔｅＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒに含まれるアクティビティデザイナコレクションを修正する要求がある場合には必ず、アクティビティが削除される必要のある場所を指定するコンテキスト（ＣｏｎｔｅｘｔＢａｓｅ）を渡される。ＣｏｎｔｅｘｔＢａｓｅは各ＣｏｍｐｏｓｉｔｅＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒ派生クラスにより特殊化され、これにより、それらに特有のコンテキストを指定するようにできる。これの例として、ＳｅｑｕｅｎｔｉａｌＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒがあるが、これは、ＣｏｎｎｅｃｔｏｒＣｏｎｔｅｘｔと呼ばれるクラスをＣｏｎｔｅｘｔＢａｓｅから派生させてＣｏｎｔｅｘｔＢａｓｅを特殊化する。ＣｏｍｐｏｓｉｔｅＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒクラスは、ＩＣｏｍｐｏｓｉｔｅＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒインターフェイスから派生し、それに対する既定の実装を提供する。ＣｏｍｐｏｓｉｔｅＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒが備える機能は、デザイナの展開／縮小、ドラッグ＆ドロップインジケータ、自己および子のレイアウト、自己および子の描画、子のヒットテスト、および階層からのアクティビティの挿入／削除を含む。  
public abstract class CompositeActivityDesigner:ActivityDesigner, ICompositeActivityDesigner
【０１８７】
【表９】
2006107477.tif 000012
【０１８８】
ＣｏｍｐｏｓｉｔｅＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒは、抽象クラスであり、勝手に存在することはできないのでインスタンス化できない。Ｓｅｑｕｅｎｔｉａｌ、Ｐａｒａｌｌｅｌ、およびＣＡデザイナは、このクラスのすべての特殊化である。
【０１８９】
ＳｅｑｕｅｎｔｉａｌＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒ  
ＳｅｑｕｅｎｔｉａｌＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒクラスは、下に子を持つすべてのデザイナを表し、すべての子は連続して順序付けられる。子は、子の順序を修正するためにも使用されるコネクタと呼ばれるリンクにより接続される。ＳｅｑｕｅｎｔｉａｌＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒクラスは、ＣｏｍｐｏｓｉｔｅＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒの特殊化であり、コネクタ起動およびエンドビットマップ描画、すべての子の順次レイアウトおよびそれらをリンクしているすべてのコネクタの更新、子同士をつなぐコネクタの描画、ドラッグ＆ドロップが実行されたときのドロップ領域のハイライト表示、コネクタのヒットテスト、上向きおよび下向き矢印を使用する順次キーボードナビゲーション、およびコネクタのグリフを返す操作といった機能を備える。  
internal abstract class SequentialActivityDesigner: CompositeActivityDesigner
【０１９０】
【表１０】
2006107477.tif 000013
【０１９１】
上記のデザイナはすべて、ＳｅｑｕｅｎｔｉａｌＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒの特殊化であり、すべて主に描画が異なる。これらのデザイナはすべて、ワークフロー内でそれ自体を表す特別な手段を持つが、すべて、ＳｅｑｕｅｎｔｉａｌＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒによって提供される共通機能を取り除いている。
【０１９２】
ＰａｒａｌｌｅｌＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒ  
ＰａｒａｌｌｅｌＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒは、ＣｏｍｐｏｓｉｔｅＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒのもう１つの特殊化であり、複数のＳｅｑｕｅｎｔｉａｌＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒｓを含む。これらのＳｅｑｕｅｎｔｉａｌＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒｓはそれぞれ、並列デザイナにおける分岐である。並列デザイナは、複数の順次デザイナのレイアウト、さらに分岐を追加するためのドラッグ＆ドロップインジケータ、左および右矢印キーを使用することにより並列分岐間を横断するためのキーボードナビゲーション、および複数の並列分岐をリンクするための描画コネクタといった特殊化された機能を備える。  
internal abstract class ParallelActivityDesigner: CompositeActivityDesigner
【０１９３】
【表１１】
2006107477.tif 000014
【０１９４】
Ｃｏｎｄｉｔｉｏｎａｌ、Ｌｉｓｔｅｎ、およびＰａｒａｌｌｅｌデザイナは、追加描画ロジックがそれらに関連付けられているＰａｒａｌｌｅｌＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒの特殊化である。
【０１９５】
ＡｃｔｉｖｉｔｙＰｒｅｖｉｅｗＤｅｓｉｇｎｅｒ  
ＡｃｔｉｖｉｔｙＰｒｅｖｉｅｗＤｅｓｓｉｇｎｅｒは、順次デザイナであるが、コレクションバッグの形で複数のデザイナのコレクションを表示することができる。ＡｃｔｉｖｉｔｙＰｒｅｖｉｅｗＤｅｓｉｇｎｅｒは、フィルムストリップのメタファーを使用してこのコレクションを表示する。特定のデザイナが選択された場合、その表現は、アクティビティプレビューデザイナがホスティングするプレビューウィンドウ内に表示される。ＡｃｔｉｖｉｔｙＰｒｅｖｉｅｗＤｅｓｉｇｎｅｒは、編集モードとプレビューモードの２つのモードを持つ。プレビューモードでは、ユーザは選択されているデザイナを修正することはできない。このモードでは、ユーザは、スクロールしなくても、デザイナの表現全体を見ることができる。編集モードでは、デザイナを修正することができる。ＡｃｔｉｖｉｔｙＰｒｅｖｉｅｗＤｅｓｉｇｎｅｒが備える機能は、アクティビティのコレクションを表示するためのプレビューストリップ、現在選択されているアクティビティのプレビュー、および選択されたデザイナの編集機能を含む。  
internal abstract class ActivityPreviewDesigner: SequentialActivityDesigner
【０１９６】
【表１２】
2006107477.tif 000015
【０１９７】
Ｓｃｏｐｅ  ＆  Ｓｅｒｖｉｃｅデザイナ  
ＳｃｏｐｅデザイナおよびＳｅｒｖｉｃｅデザイナは、特別なデザイナである。これらはそれぞれ、例外、イベント、およびそれらに関連付けられた補正を持つことができる。ＳｃｏｐｅおよびＳｃｈｅｄｕｌｅは、さらに、ユーザコードファイル内でそれらに関連付けられたクラスも持ち、ユーザはそれらのクラス内のスコーピングを行うことができる。ＳｃｏｐｅデザイナおよびＳｅｒｖｉｃｅデザイナは、他のデザイナと異なる形で例示されており、ウォーターマークを表示し、またドロップシャドウを描画することによりハイライト表示する。
【０１９８】
ＳｃｏｐｅデザイナおよびＳｅｒｖｉｃｅデザイナは、ユーザがビューを次々にめくってゆき例外、イベント、およびそれらに関連付けられている補正をさらけ出せるようにビューを変更することができる。ユーザがＳｅｒｖｉｃｅまたはＳｃｏｐｅアイコン上でホバリングした場合、ドロップダウンパレットが現れ、そこでユーザは例外、イベント、または補正ビューの１つを選ぶことができる。次に、デザイナビューがめくられ、その選択されたビューに含まれるアクティビティが表示される。ユーザは、任意の時点にビューのどれか１つに属するアクティビティのみを表示できる。ビューをめくる動作は、ＳｃｏｐｅまたはＳｃｈｅｄｕｌｅに含まれる子アクティビティをフィルタ処理することにより実行される。ＳｃｏｐｅおよびＳｃｈｅｄｕｌｅは、ＥｘｃｅｐｔｉｏｎＨａｎｄｌｅｒｓ、ＥｖｅｎｔＨａｎｄｌｅｒｓ、およびＣｏｍｐｅｎｓａｔｉｏｎのうちの高々１つをその子として持つ。デザイナは、ユーザが見ているビューに基づいて、それらの子を除去し、選択されたビュー内に表示できる子アクティビティのみを表示するという形で、複数のビューをサポートする効果を実現している。Ｓｃｈｅｄｕｌｅデザイナは、通常、ワークフロービュー内のルートデザイナとして設定される。  
internal class ScopeDesigner: SequentialActivityDesigner  
internal class ServiceDesigner: ScopeDesigner
【０１９９】
【表１３】
2006107477.tif 000016
【０２００】
ＳｅｒｖｉｃｅＲｏｏｔＤｅｓｉｇｎｅｒ  
ＳｅｒｖｉｃｅＲｏｏｔＤｅｓｉｇｎｅｒは、Ｄｅｓｉｇｎｅｒ  Ｈｏｓｔに含まれるＲｏｏｔコンポーネントに関連付けられる。これは、デザイナウィンドウペイン内でその後ホスティングされるワークフロービューを作成する必要がある。ＳｅｒｖｉｃｅＲｏｏｔＤｅｓｉｇｎｅｒは、さらに、ツールボックスアイテムをダブルクリックすることによりワークフロー内にツールボックスアイテムを追加する機能を備えるＩＴｏｏｌＢｏｘＵｓｅｒインターフェイスもサポートする。
【０２０１】
設計時ディスクリプタ  
オーサリングオブジェクトモデルのそれぞれのアクティビティは、設計時にそのビヘイビアを記述するメタデータを持つ。これは、アクティビティ（デザイナ）だけでなくプロパティグリッドのビヘイビア（命名、説明、フィルタ処理、プロパティエディタなど）を関連付ける操作を含む。Ｔｙｐｅｓ＼Ｐｒｏｐｅｒｔｙ＼Ｅｖｅｎｔ設計時ビヘイビアは、以下の属性のうちの０個以上を使用して記述される。  
−ＳＲＣａｔｅｇｏｒｙＡｔｔｒｉｂｕｔｅ−オーケストレーションエンジン属性。ローカライズされたカテゴリ名を与える。  
−ＳＲＤｅｓｃｒｉｐｔｉｏｎＡｔｔｒｉｂｕｔｅ−オーケストレーションエンジン属性。ローカライズされた説明を与える。  
−ＥｄｉｔｏｒＡｔｔｒｉｂｕｔｅ−ＵＩＴｙｐｅＥｄｉｔｏｒを提供する。  
−ＴｙｐｅＣｏｎｖｅｒｔｅｒ−フィルタ処理、値リスト、および型の変換の機能を備える。  
−ＢｒｏｗｓａｂｌｅＡｔｔｒｉｂｕｔｅ−設計時にメンバを表示＼非表示にする。  
ＳＲＣａｔｅｇｏｒｙおよびＳＲＤｅｓｃｒｉｐｔｉｏｎは、資源名と文字列との間の単なるマッピングである。ほとんどのエディタ（ＵＩＴｙｐｅＥｄｉｔｏｒ）は、ダイアログ（ＣｏｒｒｅｌａｔｉｏｎＳｅｔｓＤｉａｌｏｇのような）またはドロップダウンリストを処理するためのマネージャである。ＰｒｏｐｅｒｔｙＤｅｓｃｒｉｐｔｏｒは、設計時のプロパティを処理し、既定のＴｙｐｅＣｏｎｖｅｒｔｅｒ、カスタムＴｙｐｅＣｏｎｖｅｒｔｅｒ（上記のように属性として宣言されている）、またはＴｙｐｅＤｅｓｃｒｉｐｔｏｒのいずれかによりプロパティを渡される。  
ＵＩ  Ｔｙｐｅ  Ｅｄｉｔｏｒｓは、オーケストレーションエンジンＣｏｍｐｏｎｅｎｔモデルにおけるさまざまなプロパティのためのエディタとなる。プロパティブラウザでは、それらを使用して、省略またはドロップダウンを表示し、エディタを起動する。
【０２０２】
型コンバータ  
型コンバータは、他の型へ／他の型からオブジェクトを変換するメソッドを備え、設計時にオブジェクトプロパティを表すＰｒｏｐｅｒｔｙＤｅｓｃｒｉｐｔｏｒリストを提供し、プロパティグリッドのプロパティのドロップダウン内で使用される値を与えることが可能である。  
以下に、オーケストレーションエンジンＣｏｍｐｏｎｅｎｔモデルで実装されるＴｙｐｅＣｏｎｖｅｒｔｅｒｓのいくつかを示す。  
−ＤｅｃｌＴｙｐｅＣｏｎｖｅｒｔｅｒ  
すべてのアクティビティの型コンバータへの基本クラス。アクティビティオブジェクトを文字列に／文字列から変換するためＣａｎＣｏｎｖｅｒｔＦｒｏｍ（）、ＣａｎＣｏｎｖｅｒｔＴｏ（）、ＣｏｎｖｅｒｔＦｒｏｍ（）、ＣｏｎｖｅｒｔＴｏ（）を実装する（プロパティグリッド内のアクティビティの名前を表示する、名前編集でアクティビティを作成できるようにする）。また、ＧｅｔＳｉｔｅ（）でもサービスへのアクセスを提供する。  
−ＨａｎｄｌｅｒＤｅｃｌＴｙｐｅＣｏｎｖｅｒｔｅｒ  
イベントに対する型コンバータ。ＤｅｃｌＴｙｐｅＣｏｎｖｅｒｔｅｒから派生する。ＩＥｖｅｎｔＢｉｎｄｉｎｇＳｅｒｖｉｃｅを使用して互換性のあるハンドラを表示するＧｅｔＳｔａｎｄａｒｄＶａｌｕｅｓ（）を実装する。  
−ＶａｒｉａｂｌｅＤｅｃｌＴｙｐｅＣｏｎｖｅｒｔｅｒ  
変数（メッセージ、チャネル、相関関係など）用の型コンバータ。ＤｅｃｌＴｙｐｅＣｏｎｖｅｒｔｅｒから派生する。ＩＦｉｅｌｄＢｉｎｄｉｎｇＳｅｒｖｉｃｅを使用して互換性のある変数フィールを表示するＧｅｔＳｔａｎｄａｒｄＶａｌｕｅｓ（）を実装する。さらに、型コンバータは、「Ｎａｍｅ」プロパティを除去し、ジェネリック型として現れる型プロパティの特別なｐｒｏｐｅｒｔｙＤｅｓｃｒｉｐｔｏｒを設定する。
【０２０３】
プロパティディスクリプタ  
プロパティディスクリプタは、設計時サービスをアクティビティオブジェクトに提供する。これは、名前、説明、カテゴリ、型コンバータ情報だけでなく、プロパティ値を取得／設定する場合の追加機能も備える。既定では、ＴｙｐｅＣｏｎｖｅｒｔｅｒは、ＰｒｏｐｅｒｔｙＤｅｓｃｒｉｐｔｏｒｓをすべてのプロパティに用意する。しかし、ＴｙｐｅＣｏｎｖｅｒｔｅｒは、その型の異なる設計時ビヘイビアを与えるためにそれらを削除、追加、またはラップすることができる。  
以下に、オーサリングオブジェクトモデルで実装されるＰｒｏｐｅｒｔｙＤｅｓｃｒｉｐｔｏｒｓの一部を示す。  
−ＤｙｎａｍｉｃＰｒｏｐｅｒｔｙＤｅｓｃｒｉｐｔｏｒ  
オーサリングオブジェクトモデル内のすべてのプロパティディスクリプタへの基本クラス。既定のプロパティディスクリプタを囲むラッパを実装し、それらのメソッドすべてをそのラッパにデリゲートする。さらに、オブジェクトから直接的に（コンポーネントである場合）、またはｌＲｅｆｅｒｅｎｃｅＳｅｒｖｉｃｅを介して、オブジェクトサイトにアクセスできるようにする。
−ＶａｒｉａｂｌｅＤｅｃｌＰｒｏｐｅｒｔｙＤｅｓｃｒｉｐｔｏｒ  
すべての変数（メッセージ、チャネル、相関関係など）用のプロパティディスクリプタ。以下のようにコードビサイドフィールドを用意するためＳｅｔＶａｌｕｅ（）をオーバーロードする。  
−設定する変数とそのサイトを取得する。  
−含むスコープのサイトを取得する。  
−含むスコープのＩＦｉｅｌｄＢｉｎｄｉｎｇＳｅｒｖｉｃｅを取得する。それぞれのスコープは、フィールドの独自の集合が含まれるそれ独自のＩＦｉｅｌｄＢｉｎｄｉｎｇＳｅｒｖｉｃｅを持つ。  
−サービスによりフィールド名の妥当性を確認する。  
−デザイナトランザクションを開く。  
−値を保存する。  
−ＩＦｉｅｌｄＢｉｎｄｉｎｇＳｅｒｖｉｃｅ．ＣｒｅａｔｅＦｉｅｌｄ（）を呼び出して、フィールドをコードビサイドファイルに追加する。  
−トランザクションをコミットする。  
−ＨａｎｄｌｅｒＤｅｃｌＰｒｏｐｅｒｔｙＤｅｓｃｒｉｐｔｏｒ  
すべてのハンドラ用のプロパティディスクリプタ。以下のようにコードビサイドフィールドを用意するためＳｅｔＶａｌｕｅ（）をオーバーロードする。  
−設定するＨａｎｄｌｅｒＤｅｃｌａｒａｔｉｏｎとそのサイトを取得する。  
−ＩＥｖｅｎｔＢｉｎｄｉｎｇＳｅｒｖｉｃｅを取得する。  
−デザイナトランザクションを開く。  
−ＬｏｃａｌＥｖｅｎｔＤｅｓｃｒｉｐｔｏｒを作成する。  
−イベントのＰｒｏｐｅｒｔｙＤｅｓｃｒｉｐｔｏｒを取得し（ｅｖｅｎｔＢｉｎｄｉｎｇＳｅｒｖｉｃｅ．ＧｅｔＥｖｅｎｔｐｒｏｐｅｒｔｙ（）を使用して）、それにＨａｎｄｌｅｒＤｅｃｌａｒａｔｉｏｎを設定する。  
−ＨａｎｄｌｅｒＤｅｃｌａｒａｔｉｏｎオブジェクトの「Ｎａｍｅ」プロパティを設定する。  
−トランザクションをコミットする。  
−ＡｒｒａｙＥｌｅｍｅｎｔＰｒｏｐｅｒｔｙＤｅｓｃｒｉｐｔｏｒ
コレクション内のアイテムを表すプロパティディスクリプタ。コレクションアイテム−例えば、Ｃｏｒｒｅｌａｔｉｏｎ  Ｓｅｔｓ−はプロパティディスクリプタを持たないため（それらのプロパティではない）、ＡｒｒａｙＥｌｅｍｅｎｔＰｒｏｐｅｒｔｙＤｃｓｃｒｉｐｔｏｒでは、それらがプロパティであるかのようにディスクリプタをフェイクし、それにより、プロパティブラウザの内側にそれらを表示するようにできる。このプロパティディスクリプタは、上述のプロパティディスクリプタのどれかによりラップされるように設計された。  
−ＬｏｃａｌＥｖｅｎｔＤｅｓｃｒｉｐｔｏｒ  
ハンドラ宣言を表すＥｖｅｎｔＤｅｓｃｒｉｐｔｏｒ。オーサリングオブジェクトモデル内のハンドラは、実際のイベントではなく、プロパティであるので、使用されるＩＥｖｅｎｔＢｉｎｄｉｎｇＳｅｒｖｉｃｅに独自のＥｖｅｎｔＤｅｓｃｒｉｐｔｏｒｓを導入する。
【０２０４】
ＩＣｕｓｔｏｍＴｙｐｅＤｅｓｃｒｉｐｔｏｒの使用  
ＩＣｕｓｔｏｍＴｙｐｅＤｅｓｃｒｉｐｔｏｒは、コンポーネントに対しディスクリプタを設定するための代替え手段である。コンポーネント自体はインターフェイスを実装し、ディスクリプタを、型コンバータ、既定値などとして提供する。ＧｅｎｅｒｉｃＡｃｔｉｖｉｔｙ、ＩｎｖｏｋｅＷｅｂＳｅｒｖｉｃｅＡｃｔｉｖｉｔｙ、およびＩｎｖｏｋｅＳｃｈｅｄｕｌｅはこのインターフェイスを実装する。
【０２０５】
ＩＥｘｔｅｎｄｅｒＰｒｏｖｉｄｅｒの使用  
これは、設計時プロパティをコンポーネントに導入するためのさらに他の手法である。拡張クラスＲｕｌｅＰｒｏｐｅｒｔｙＰｒｏｖｉｄｅｒＥｘｔｅｎｄｅｒは、ルールプロパティをＳｅｒｖｉｃｅＤｅｓｉｇｎｅｒに提供する。プロパティは、ＰｒｏｖｉｄｅＰｒｏｐｅｒｔｙＡｔｔｒｉｂｕｔｅを介してエクステンダクラスを修飾し、その属性のゲッターおよびセッターを実装し、エクステンダクラスをコンポーネントのサイト（Ｓｃｈｅｄｕｌｅ．Ｓｉｔｅ）を通じてアクセス可能なＩＥｘｔｅｎｄｅｒＰｒｏｖｉｄｅｒＳｅｒｖｉｃｅクラス（この場合は、ＲｕｌｅＰｒｏｐｅｒｔｙＰｒｏｖｉｄｅｒＥｘｔｅｎｄｅｒにより実装される）に追加することにより追加される。
【０２０６】
拡張性のサポート  
Ｓｙｓｔｅｍ．Ｗｏｒｋｆｌｏｗ．ＣｏｍｐｏｎｅｎｔＭｏｄｅｌ．Ｄｅｓｉｇｎ名前空間は、さまざまな再利用可能なクラスを用意しており、ユーザはそれを使って、独自のアクティビティデザイナを作成し、それらをオーケストレーションエンジンデザイナにプラグインとして追加する。以下に、ユーザが使用できるクラスの一覧を示す。  
−ＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒ：ＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒを使用すると、ユーザは、下に他のアクティビティの階層を持たない単純なアクティビティを追加できる。ユーザは、このデザイナから継承する必要があり、またビットマップ、説明、および描画をカスタマイズできる。  
−ＳｅｑｕｅｎｔｉａｌＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒ：ＳｅｑｕｅｎｔｉａｌＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒを使用すると、ユーザは、複数のアクティビティを含むことができるデザイナを書くことができる。これらのアクティビティはすべて、順次配列され、コネクタ線を使ってリンクされる。ユーザは、このクラスから派生させることができ、カスタム配色、説明、アイコンなどを用意できる。  
−ＰａｒａｌｌｅｌＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒ：ＰａｒａｌｌｅｌＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒを使用すると、ユーザは、並列様式で配列された、複数の複合アクティビティを持つことができるアクティビティデザイナを書くことができる。また、このクラスを使用することで、ユーザは、説明、アイコン、色などをカスタマイズできる。このクラスは、継承を通じて拡張できる。  
−ＯｒｃｈｅｓｔｒａｔｉｏｎＥｎｇｉｎｅＴｏｏｌｂｏｘＩｔｅｍ：ＯｒｃｈｅｓｔｒａｔｉｏｎＥｎｇｉｎｅＴｏｏｌｂｏｘＩｔｅｍを使用すると、ユーザは、カスタムツールボックスアイテムを作成することができる。このクラスでは、ユーザは、シリアライゼーションを制御できる。このクラスでは、アクティビティがデザイナの中に追加される場合にユーザがカスタムＵＩをポップアップするために使用するフックを用意している。ユーザは、継承を通じてこのクラスを再利用できる。ユーザは、ＴｏｏｌＢｏｘＩｔｅｍ属性を使用してツールボックスアイテムを用意する必要がある。
【０２０７】
−ＴｙｐｅＢｒｏｗｓｅｒＥｄｉｔｏｒ：ＴｙｐｅＢｒｏｗｓｅｒＥｄｉｔｏｒを使用すると、ユーザは、デザイナに用意されている型をブラウズすることができる。このクラスは、Ｓｙｓｔｅｍ.Ｔｙｐｅ型のプロパティに関連付けることで使用される。ユーザは、ＵＩＴｙｐｅＥｄｉｔｏｒ属性を使用して、このクラスをプロパティに関連付ける。
【０２０８】
−ＴｙｐｅＣｏｎｖｅｒｔｅｒクラス：オーケストレーションエンジンコンポーネントモデルは、独自の型コンバータをユーザ側で定義できるさまざまな型コンバータを備えている。型コンバータはすべて、継承を通じて拡張することにより使用することができる。
【０２０９】
−ＤｅｓｉｇｎｅｒＧｌｙｐｈ：ＤｅｓｉｇｎｅｒＧｌｙｐｈクラスは、ユーザがデザイナの上にカスタムグリフを描画する場合に使用できる。一番上のＺ順で描画する必要がある視覚的グリフをいくつか表示したい場合がある。ＤｅｓｉｇｎｅｒＧｌｙｐｈクラスは、このようなグリフを描画するために使用することができる。このクラスは、継承を通じて拡張することにより使用できる。  
−ＤｅｓｉｇｎｅｒＡｃｔｉｏｎ：ユーザは、ＤｅｓｉｇｎｅｒＡｃｔｉｏｎｓをＤｅｓｉｇｎｅｒＧｌｙｐｈｓに関連付けることができる。ユーザがＤｅｓｉｇｎｅｒＧｌｙｐｈｓをクリックすると、アクションが表示される。カスタムデザイナアクションは、ＤｅｓｉｇｎｅｒＡｃｔｉｏｎから継承することにより作成できる。
【０２１０】
付録Ｃ  
付録Ｃでは、アクティビティバリデーション（activity validation）を説明する。
【０２１１】
アクティビティの意味論的バリデーション  
これらバリデーションチェック例は、オーケストレーションエンジンにより生み出される複数のアクティビティに共通である。  
すべてのアクティビティ  
−アクティビティのＩＤプロパティは、プロジェクトの言語（Ｃ＃またはＶＢ）における有効な識別子でなければならない。  
−非ＳｃｏｐｅアクティビティのＩＤは、包含するＳｃｏｐｅ内では一意でなければならない。ＳｃｏｐｅアクティビティのＩＤは、すべてのＳｃｏｐｅにわたって一意でなければならない。  
−変数であるプロパティは、可視である変数に設定されなければならない−例えば、これは、アクティビティのＳｃｏｐｅ内で定義されるか、または含むＳｃｏｐｅでは、パブリックでなければならない。
コードビサイドハンドラ  
−アクティビティのＩＤプロパティは、プロジェクトの言語（Ｃ＃またはＶＢ）における有効な識別子でなければならない。  
−Ｈａｎｄｌｅｒは、Ｈａｎｄｌｅｒを含むアクティビティのコードビサイドスコープクラス内に存在していなければならず、一致するメソッドシグネチャを持たなければならない。  
メッセージ  
−パラメトリック型ＴのＯＥＭｅｓｓａｇｅ＜Ｔ＞はシリアライズ可能でなければならない。  
相関関係  
−パラメトリック型ＴのＯＥＣｏｒｒｅｌａｔｉｏｎ＜Ｔ＞はＩＣｏｍｐａｒａｂｌｅを実装しなければならない。
ルール  
−ＲｕｌｅのＨａｎｄｌｅｒは、ハンドラバリデーションに通らなければならない。ハンドラのシグネチャは、Ｒｕｌｅの型により定義される。  
アクティビティ特有のバリデーションチェック  
これらのバリデーションチェック例は、アクティビティ型に特有である。  
Ｃｏｄｅ  
−ＵｓｅｒＣｏｄｅＨａｎｄｌｅｒプロパティは、指定され、シグネチャｖｏｉｄ  Ｍｅｔｈｏｄ（）を持たなければならない。
Ｃｏｍｐｅｎｓａｔｅ  
−Ｃｏｍｐｅｎｓａｔｅアクティビティは、ＥｘｃｅｐｔｉｏｎＨａｎｄｌｅｒアクティビティまたはＴｒａｎｓａｃｔｉｏｎＴｙｐｅがＮｏｎｅでないＳｃｏｐｅのＣｏｍｐｅｎｓａｔｉｏｎアクティビティの内側にしか現れない。  
−ＣｏｍｐｅｎｓａｔｅＳｃｏｐｅがＴｒｕｅの場合、Ｓｃｏｐｅプロパティは、Ｃｏｍｐｅｎｓａｔｅが生じるＳｃｏｐｅの直近の子であるか、またはそれ自体であるＳｃｏｐｅアクティビティに設定されなければならない。  
−ＣｏｍｐｅｎｓａｔｅＳｃｏｐｅがＦａｌｓｅの場合、Ｉｎｖｏｋｅプロパティは、Ｃｏｍｐｅｎｓａｔｅが生じるＳｃｏｐｅの直近の子であるＣｏｍｐｏｓｉｔｅＳｃｈｅｄｕｌｅアクティビティに設定されなければならない。  
Ｃｏｎｄｉｔｉｏｎａｌ  
−Ｃｏｎｄｉｔｉｏｎａｌアクティビティは、少なくとも１つの子を持たなければならない。  
−ＣｏｎｄｉｔｉｏｎａｌＢｒａｎｃｈアクティビティのみが子として許容される。
ＣｏｎｄｉｔｉｏｎａｌＢｒａｎｃｈ  
−親アクティビティはＣｏｎｄｉｔｉｏｎａｌでなければならない。  
−ＣｏｎｄｉｔｉｏｎａｌＢｒａｎｃｈが親の最後の子でない限り、Ｒｕｌｅプロパティを指定しなければならない。  
ＣｏｎｓｔｒａｉｎｅｄＡｃｔｉｖｉｔｙＧｒｏｕｐ  
−ＣｏｍｐｌｅｔｉｏｎＲｕｌｅプロパティは、有効なＲｕｌｅに設定されなければならない。  
−Ｃｏｎｓｔｒａｉｎｅｄアクティビティのみが子として許容される。  
Ｃｏｎｓｔｒａｉｎｅｄ  
−親アクティビティはＣｏｎｓｔｒａｉｎｅｄＡｃｔｉｖｉｔｙＧｒｏｕｐでなければならない。  
−Ｃｏｎｓｔｒａｉｎｅｄは、ちょうど１つの子を持たなければならない。  
−ＤｉｓａｂｌｅＲｕｌｅおよびＥｎａｂｌｅＲｕｌｅｓは、指定されている場合には、有効でなければならない。  
Ｄｅｌａｙ  
−ＴｉｍｅｏｕｔＰｒｏｖｉｄｅｒプロパティは、有効なＨａｎｄｌｅｒに設定されなければならない。
ＥｖｅｎｔＨａｎｄｌｅｒｓ  
−親はＳｃｏｐｅアクティビティでなければならない。  
−ＥｖｅｎｔＤｒｉｖｅｎアクティビティのみが子として許容される。  
−子ＥｖｅｎｔＤｒｉｖｅｎアクティビティの最初の子が、ＡｃｔｉｖａｔｉｏｎがＴｒｕｅに設定されているＲｅｃｅｉｖｅの場合、すべての子ＥｖｅｎｔＨａｎｄｌｅｒｓは、最初の子として、ＡｃｔｉｖａｔｉｏｎがＴｒｕｅに設定されているＲｅｃｅｉｖｅを持たなければならない。  
−ただ１つの子ＥｖｅｎｔＤｒｉｖｅｎアクティビティのみが、Ｄｅｌａｙアクティビティを最初の子として持つことができる。  
ＥｖｅｎｔＤｒｉｖｅｎ  
−親は、ＬｉｓｔｅｎアクティビティまたはＥｖｅｎｔＨａｎｄｌｅｒｓアクティビティでなければならない。  
−最初の子は、ＤｅｌａｙまたはＲｅｃｅｉｖｅアクティビティのいずれかでなければならない。  
−少なくとも１つの子アクティビティが存在していなければならない。
Ｆａｕｌｔ  
−ＥｘｅｃｅｐｔｉｏｎＰｒｏｖｉｄｅｒプロパティは、シグネチャＳｙｓｔｅｍ．Ｅｘｃｅｐｔｉｏｎ  Ｍｅｔｈｏｄ（）を持つ有効なＨａｎｄｌｅｒに設定されなければならない。  
−Ｆａｕｌｔアクティビティは、ＴｒａｎｓａｃｔｉｏｎＴｙｐｅがＡｔｏｍｉｃに設定されているＳｃｏｐｅアクティビティの内側にネストすることはできない。  
ＩｎｖｏｋｅＳｃｈｅｄｕｌｅ  
−被呼び出し側の型は、ＩｎｖｏｋｅＳｃｈｅｄｕｌｅから派生されなければならず、既定のコンストラクタを持たなければならない。  
−ＩｎＡｔｔｒｉｂｕｔｅ、ＯｕｔＡｔｔｒｉｂｕｔｅ、またはＯｐｔｉｏｎａｌＡｔｔｒｉｂｕｔｅを持つ被呼び出し側のパブリックプロパティは、割り当て可能な型の表示変数に割り当てることができる。  
−ＥｘｅｃｕｔｉｏｎＭｅｔｈｏｄプロパティがＥｘｅｃに設定されている場合、ＯｕｔＡｔｔｒｉｂｕｔｅを持つが、ＩｎＡｔｔｒｉｂｕｔｅを持たないプロパティは割り当てられない。  
−ＥｘｅｃｕｔｉｏｎＭｅｔｈｏｄプロパティがＥｘｅｃに設定されている場合、変数はシリアライズ可能でなければならない。  
−ＣｈａｎｎｅｌまたはＣｏｒｒｅｌａｔｉｏｎは、ＯｕｔＡｔｔｒｉｂｕｔｅを持つプロパティに割り当てることはできない。  
−再帰的呼び出しはできない。
ＩｎｖｏｋｅＷｅｂＳｅｒｖｉｃｅ  
−ＰｒｏｘｙＣｌａｓｓＮａｍｅプロパティは、有効なプロキシクラスに設定されなければならない。  
−ＭｅｔｈｏｄＮａｍｅプロパティは、プロキシクラス内のＷｅｂメソッドに設定されなければならない。  
−Ｗｅｂメソッドへのパラメータはすべて指定され、表示状態でなければならず、それらの型は割り当て可能でなければならない。さらに、任意のｏｕｔ／ｒｅｆパラメータおよび戻り値については、指定されたパラメータは読み取り専用であってはならない。  
Ｌｉｓｔｅｎ  
−ＥｖｅｎｔＤｒｉｖｅｎアクティビティのみが子として許容される。  
−少なくとも２つの子が存在していなければならない。  
−子ＥｖｅｎｔＤｒｉｖｅｎアクティビティの最初の子が、ＡｃｔｉｖａｔｉｏｎがＴｒｕｅに設定されているＲｅｃｅｉｖｅの場合、すべての子ＥｖｅｎｔＤｒｉｖｅｎアクティビティは、最初の子として、ＡｃｔｉｖａｔｉｏｎがＴｒｕｅに設定されているＲｅｃｅｉｖｅ、またはＤｅｌａｙアクティビティを持たなければならない。  
−ただ１つの子ＥｖｅｎｔＤｒｉｖｅｎアクティビティのみが、Ｄｅｌａｙアクティビティを最初の子として持つことができる。
Ｐａｒａｌｌｅｌ  
−Ｓｅｑｕｅｎｃｅアクティビティのみが子として許容される。  
−少なくとも２つの子が存在していなければならない。  
−子Ｓｅｑｕｅｎｃｅアクティビティの最初の子が、ＡｃｔｉｖａｔｉｏｎがＴｒｕｅに設定されているＲｅｃｅｉｖｅの場合、すべての子Ｓｅｑｕｅｎｃｅアクティビティは、最初の子として、ＡｃｔｉｖａｔｉｏｎがＴｒｕｅに設定されているＲｅｃｅｉｖｅを持たなければならない。
Ｒｅｃｅｉｖｅ  
−Ｍｅｓｓａｇｅプロパティが設定され、有効でなければならない。  
−ＨａｓＴｙｐｅｄＣｈａｎｎｅｌプロパティがＴｒｕｅの場合、ＴｙｐｅｄＣｈａｎｎｅｌプロパティは設定され、有効でなければならない−Ｔがインターフェイスである型ＯＥＩｎｂｏｕｎｄＣｈａｎｎｅｌ＜Ｔ＞の表示変数。  
−ＨａｓＴｙｐｅｄＣｈａｎｎｅｌプロパティがＴｒｕｅの場合、ＴｙｐｅｄＣｈａｎｎｅｌのＯｐｅｒａｔｉｏｎは、シグネチャｖｏｉｄ  Ｍｅｔｈｏｄ（Ｔｙｐｅ  ｐａｒａｍｅｔｅｒ）を持つインターフェイスからのメソッドでなければならない。  
−ＨａｓＴｙｐｅｄＣｈａｎｎｅｌプロパティがＴｒｕｅの場合、ＭｅｓｓａｇｅのＴｙｐｅは、ＯｐｅｒａｔｉｏｎのパラメータのＴｙｐｅから割り当て可能でなければならない。  
−ＨａｓＴｙｐｅｄＣｈａｎｎｅｌプロパティがＦａｌｓｅの場合、ＵｎｔｙｐｅｄＣｈａｎｎｅｌプロパティは設定され、有効でなければならない−型ＩｎｂｏｕｎｄＣｈａｎｎｅｌの表示変数。  
−ＡｃｔｉｖａｔｉｏｎプロパティがＴｒｕｅの場合、Ｒｅｃｅｉｖｅは、Ｓｃｈｅｄｕｌｅ内の第１の実行可能ステートメントでなければならず、またＳｅｑｕｅｎｃｅ、Ｐａｒａｌｌｅｌ、ＥｖｅｎｔＤｒｉｖｅｎ、Ｌｉｓｔｅｎ、Ｓｃｏｐｅ、またはＳｃｈｅｄｕｌｅアクティビティを祖先としてしか持つことができない。  
−ＡｃｔｉｖａｔｉｏｎプロパティがＴｒｕｅの場合、Ｓｃｈｅｄｕｌｅは、ＣｏｍｐｉｌｅＡｓプロパティがＡｃｔｉｖｉｔｙに設定されていてはならない。  
−ＡｃｔｉｖａｔｉｏｎプロパティがＴｒｕｅの場合、Ｒｅｃｅｉｖｅは、ＣｏｍｐｅｎｓａｔｉｏｎまたはＥｘｃｅｐｔｉｏｎＨａｎｄｌｅｒまたはＷｈｉｌｅアクティビティの内側にネストされてはならない。  
−ＡｃｔｉｖａｔｉｏｎプロパティがＦａｌｓｅの場合、Ｒｅｃｅｉｖｅは、少なくとも１つのＣｏｒｒｅｌａｔｉｏｎに続かなければならない。  
−Ｃｏｒｒｅｌａｔｉｏｎは、高々１回指定することができ、同時に初期化され続くことはできない。  
−ＯｎＡｆｔｅｒＲｅｃｅｉｖｅハンドラは設定されている場合には、シグネチャｖｏｉｄ  Ｍｅｔｈｏｄ（）を持たなければならない。
ＲｅｃｅｉｖｅＲｅｑｕｅｓｔ  
−ＴｙｐｅｄＣｈａｎｎｅｌプロパティのＯｐｅｒａｔｉｏｎ（設定する必要がある場合）は、シグネチャＲｅｔｕｒｎＴｙｐｅ  Ｍｅｔｈｏｄ（Ｔｙｐｅ  ｐａｒａｍｅｔｅｒ）を持たなければならない。  
ＲｅｃｅｉｖｅＲｅｓｐｏｎｓｅ  
−ＴｙｐｅｄＣｈａｎｎｅｌプロパティのＯｐｅｒａｔｉｏｎ（設定する必要がある場合）は、シグネチャＲｅｔｕｒｎＴｙｐｅ  Ｍｅｔｈｏｄ（Ｔｙｐｅ  ｐａｒａｍｅｔｅｒ）を持たなければならない。  
−ＯｐｅｒａｔｉｏｎのＲｅｔｕｒｎＴｙｐｅは、ＭｅｓｓａｇｅのＴｙｐｅから割り当て可能でなければならない。  
−ＳｅｎｄＲｅｑｕｅｓｔプロパティは、有効なＳｅｎｄＲｅｑｕｅｓｔアクティビティの修飾名でなければならない。  
−ＳｅｎｄＲｅｑｕｅｓｔアクティビティは、ＲｅｃｅｉｖｅＲｅｓｐｏｎｓｅの前に発生しなければならない。  
−ＳｅｎｄＲｅｑｕｅｓｔおよびＲｅｃｅｉｖｅＲｅｓｐｏｎｓｅアクティビティは、同じＡｔｏｍｉｃ  Ｓｃｏｐｅの内側にネストされてはならない。  
−ＲｅｃｅｉｖｅＲｅｓｐｏｎｓｅＡｃｔｉｖｉｔｙはＣｏｒｒｅｌａｔｉｏｎの後に続くことはできない。
Ｓｅｎｄ  
−Ｍｅｓｓａｇｅプロパティが設定され、有効でなければならない。  
−ＨａｓＴｙｐｅｄＣｈａｎｎｅｌプロパティがＴｒｕｅの場合、ＴｙｐｅｄＣｈａｎｎｅｌプロパティは設定され、有効でなければならない−Ｔがインターフェイスである型ＯＥＯｕｔｂｏｕｎｄＣｈａｎｎｅｌ＜Ｔ＞の表示変数。  
−ＨａｓＴｙｐｅｄＣｈａｎｎｅｌプロパティがＴｒｕｅの場合、ＴｙｐｅｄＣｈａｎｎｅｌのＯｐｅｒａｔｉｏｎは、シグネチャｖｏｉｄ  Ｍｅｔｈｏｄ（Ｔｙｐｅ  ｐａｒａｍｅｔｅｒ）を持つインターフェイスからのメソッドでなければならない。  
−ＨａｓＴｙｐｅｄＣｈａｎｎｅｌプロパティがＴｒｕｅの場合、ＯｐｅｒａｔｉｏｎのパラメータのＴｙｐｅは、ＭｅｓｓａｇｅのＴｙｐｅから割り当て可能でなければならない。  
−ＨａｓＴｙｐｅｄＣｈａｎｎｅｌプロパティがＦａｌｓｅの場合、ＵｎｔｙｐｅｄＣｈａｎｎｅｌプロパティは設定され、有効でなければならない−型ＯｕｔｂｏｕｎｄＣｈａｎｎｅｌの表示変数。  
−Ｃｏｒｒｅｌａｔｉｏｎは、高々１回指定することができ、同時に初期化され続くことはできない。  
−ＯｎＢｅｆｏｒｅＳｅｎｄハンドラは設定されている場合には、シグネチャｖｏｉｄ  Ｍｅｔｈｏｄ（）を持たなければならない。
ＳｅｎｄＲｅｑｕｅｓｔ  
−ＴｙｐｅｄＣｈａｎｎｅｌプロパティのＯｐｅｒａｔｉｏｎ（設定する必要がある場合）は、シグネチャＲｅｔｕｒｎＴｙｐｅ  Ｍｅｔｈｏｄ（Ｔｙｐｅ  ｐａｒａｍｅｔｅｒ）を持たなければならない。  
ＳｅｎｄＲｅｓｐｏｎｓｅ  
−ＴｙｐｅｄＣｈａｎｎｅｌプロパティのＯｐｅｒａｔｉｏｎ（設定する必要がある場合）は、シグネチャＲｅｔｕｒｎＴｙｐｅ  Ｍｅｔｈｏｄ（Ｔｙｐｅ  ｐａｒａｍｅｔｅｒ）を持たなければならない。  
−ＯｐｅｒａｔｉｏｎのＲｅｔｕｒｎＴｙｐｅは、ＭｅｓｓａｇｅのＴｙｐｅから割り当て可能でなければならない。  
−ＲｅｃｅｉｖｅＲｅｑｕｅｓｔプロパティは、有効なＲｅｃｅｉｖｅＲｅｑｕｅｓｔアクティビティの修飾名でなければならない。  
−ＲｅｃｅｉｖｅＲｅｑｕｅｓｔアクティビティは、ＳｅｎｄＲｅｓｐｏｎｓｅの前に発生しなければならない。  
−ＳｅｎｄＲｅｓｐｏｎｓｅＡｃｔｉｖｉｔｙはＣｏｒｒｅｌａｔｉｏｎの後に続くことはできない。  
Ｓｃｏｐｅ  
−ＳｙｎｃｈｒｏｎｉｚｅｄがＴｒｕｅに設定されているＳｃｏｐｅアクティビティは、ＳｙｎｃｈｒｏｎｉｚｅｄがＴｒｕｅに設定されている他のＳｃｏｐｅアクティビティの内側にネストすることはできない。  
−ＴｒａｎｓａｃｔｉｏｎＴｙｐｅがＡｔｏｍｉｃであるＳｃｏｐｅアクティビティは、ＥｘｃｅｐｔｉｏｎＨａｎｄｌｅｒアクティビティ内でネストすることはできない。
【０２１２】
−ＴｒａｎｓａｃｔｉｏｎＴｙｐｅがＡｔｏｍｉｃまたはＬｏｎｇＲｕｎｎｉｎｇのＳｃｏｐｅアクティビティは、ＴｒａｎｓａｃｔｉｏｎＴｙｐｅがＬｏｎｇＲｕｎｎｉｎｇであるＳｃｏｐｅアクティビティ内でネストされなければならない（ＳｃｏｐｅがＳｃｈｅｄｕｌｅでない限り）。  
−ＴｒａｎｓａｃｔｉｏｎＴｙｐｅがＡｔｏｍｉｃの場合、ＳｙｎｃｈｒｏｎｉｚｅｄプロパティはＴｒｕｅでなければならない。  
−ＴｒａｎｓａｃｔｉｏｎＴｙｐｅがＬｏｎｇＲｕｎｎｉｎｇの場合、ＴｉｍｅｏｕｔＰｒｏｖｉｄｅｒハンドラは、シグネチャＳｙｓｔｅｍ．ＤａｔｅＴｉｍｅ  Ｍｅｔｈｏｄ（）で設定されなければならない。  
Ｓｃｈｅｄｕｌｅ  
−コードビサイドクラスは、ちょうど１つのコンストラクタを持たなければならない。
Ｓｅｑｕｅｎｃｅ  
バリデーションなし。  
Ｓｕｓｐｅｎｄ  
−Ｓｕｓｐｅｎｄアクティビティは、ＴｒａｎｓａｃｔｉｏｎＴｙｐｅがＡｔｏｍｉｃに設定されているＳｃｏｐｅの内側にネストすることはできない。  
−ＥｒｒｏｒＳｔｒｉｎｇプロパティは、有効な文字列でなければならない。  
Ｔｅｒｍｉｎａｔｅ  
−ＥｒｒｏｒＳｔｒｉｎｇプロパティは、有効な文字列でなければならない。  
Ｗｈｉｌｅ  
−ＣｏｎｄｉｔｉｏｎａｌＲｕｌｅプロパティは、有効なＲｕｌｅでなければならない。
【０２１３】
相関関係集合、およびコンボイバリデーションチェック（Convoy Validation Checks）  
これらのバリデーションチェック例は、相関関係集合およびコンボイシナリオに特有である。  
−Ｃｏｒｒｅｌａｔｉｏｎは、後に続く前に初期化されなければならない。  
−Ｃｏｒｒｅｌａｔｉｏｎは、いくつかの例外で高々１回初期化できる。  
−相関関係を初期化するＳｅｎｄおよびそれに続くＲｅｃｅｉｖｅは、同じＡｔｏｍｉｃ  Ｓｃｏｐｅ内に置かれる。  
−順次コンボイの検出。  
−並列コンボイの検出およびバリデーション：  
○  並列コンボイ内のすべてのＲｅｃｅｉｖｅアクティビティは、同じＣｏｒｒｅｌａｔｉｏｎｓの集合を初期化しなければならない。  
○  並列コンボイ内のすべての非アクティベーションＲｅｃｅｉｖｅアクティビティは、同じＣｏｒｒｅｌａｔｉｏｎｓの集合の後に続かなければならない。  
○  並列のアクティベーションＲｅｃｅｉｖｅは、Ｃｏｒｒｅｌａｔｉｏｎを初期化しなければならない。  
アクティベーションＲｅｃｅｉｖｅがワークフロー内の最初の実行可能非複合アクティビティ（例えば、Ｓｃｏｐｅｓ、Ｐａｒａｌｌｅｌｓ、Ｌｉｓｔｅｎｓなどを無視する）であり、その祖先がＰａｒａｌｌｅｌまたはＬｉｓｔｅｎの場合、ＰａｒａｌｌｅｌまたはＬｉｓｔｅｎのすべての分岐は、アクティベーションＲｅｃｅｉｖｅを最初の実行可能アクティビティとして持たなければならない。
【０２１４】
付録Ｄ  
付録Ｄでは、本発明のアプリケーションプログラミングインターフェイスのいくつかの実施例を説明する。
【０２１５】
名前空間ＡＰＩの例  
Ｓｙｓｔｅｍ．Ｗｏｒｋｆｌｏｗ．ＣｏｍｐｏｎｅｎｔＭｏｄｅｌ名前空間は、標準のＷｏｒｋｆｌｏｗ  Ａｃｔｉｖｉｔｉｅｓの実装を含む。Ａｃｔｉｖｉｔｙオブジェクトモデルは、オーケストレーションプログラムをオーサリングするためのＡＰＩを備えている。さらに、宣言オブジェクトモデル内のすべてのオブジェクトは、設計時ビヘイビアをコンポーネントに関連付けることを可能にする継承を持つ。以下に、メッセージを受信し、宣言オブジェクトモデルを使用してそれを送信するオーケストレーションプログラムを表す例を示す。
【０２１６】
【表１４】
2006107477.tif 000017
【０２１７】
そのようなサービスを構築する対応するＡｕｔｈｏｒｉｎｇ  ＡＰＩは以下のとおりである。
【０２１８】
【表１５】
2006107477.tif 000018
【０２１９】
以下の表は、この名前空間の記述および用途を簡単に説明したものである。
【０２２０】
【表１６】
2006107477.tif 000019
【０２２１】
Ｗｏｒｋｆｌｏｗコンポーネントモデルは、階層型宣言オブジェクトモデルである。このオブジェクトモデルのルートはＳｃｈｅｄｕｌｅである。このオブジェクトモデルは、ツールライターが使用するだけでなく、ランタイム実行でも使用される。コンポーネントモデル内のすべてのアクティビティは、ＩＡｃｔｉｖｉｔｙインターフェイスにより表される。ＩＡｃｔｉｖｉｔｙインターフェイスは、ＩＣｏｍｐｏｎｅｎｔから継承する。ＩＣｏｍｐｏｎｅｎｔは、アクティビティが設計時に通信できるようにするＳｉｔｅプロパティを持つ。このオブジェクトモデルは、サードパーティのアクティビティライターにより拡張できる。アクティビティは、次のように分類することができる。  
１）Ｐｒｉｍｉｔｉｖｅ（プリミティブ）アクティビティ：プリミティブアクティビティは、子アクティビティを持たず、プロパティのフラットリストを含む。  
２）Ｃｏｍｐｏｓｉｔｅ（複合）アクティビティ：複合アクティビティは、プリミティブアクティビティから継承し、子アクティビティのリストを保持する。
【０２２２】
上記のＰｒｉｍｉｔｉｖｅおよびＣｏｍｐｏｓｉｔｅアクティビティの分類に加えて、ＳｃｏｐｅおよびＳｃｈｅｄｕｌｅアクティビティは、異なる方法で取り扱われる。ＳｃｏｐｅおよびＳｃｈｅｄｕｌｅは、対応するＵｓｅｒ  Ｃｏｄｅクラスが関連付けられている。すべてのアクティビティとともに、この名前空間は、さらに、ｘｏｍｌファイルとの間のシリアライゼーションおよびでデシリアライゼーション、Ｓｃｈｅｄｕｌｅアクティビティのコンパイル、および各アクティビティ上のバリデーション実装といった機能を備える。
【０２２３】
ＩＡｃｔｉｖｉｔｙインターフェイスは、ＩＣｏｍｐｏｎｅｎｔから継承する。
【０２２４】
【表１７】
2006107477.tif 000020
【０２２５】
【表１８】
2006107477.tif 000021
【０２２６】
【表１９】
2006107477.tif 000022
【０２２７】
以下に、ＩＶａｌｉｄａｔｉｏｎＥｒｒｏｒの定義を示す。このエラーは、アクティビティ上でＶａｌｉｄａｔｅを呼び出したときに返される。
【０２２８】
【表２０】
2006107477.tif 000023
【０２２９】
すべての複合アクティビティはＩＣｏｍｐｏｓｉｔｅＡｃｔｉｖｉｔｙから継承する。Ｃｏｍｐｏｓｉｔｅアクティビティは、Ｐｒｉｍｉｔｉｖｅアクティビティと対照的に、追加プロパティ「Ａｃｔｉｖｉｔｉｅｓ」およびＥｘｅｃｕｔａｂｌｅＡｃｔｉｖｉｔｉｅｓを持つ。以下に、ＩＣｏｍｐｏｓｉｔｅＡｃｔｉｖｉｔｙの継承定義を示す。
【０２３０】
【表２１】
2006107477.tif 000024
【０２３１】
ＩＡｃｔｉｖｉｔｙＣｏｌｌｅｃｔｉｏｎは、ＩＬｉｓｔから継承し、リストに対する修正に関する１つの追加イベントおよび実行時モードでコレクションの動的更新に関係するさらに多くのメソッドを持つ。
【０２３２】
【表２２】
2006107477.tif 000025
【０２３３】
ランタイムバリュープロバイダ  
アクティビティプロパティの値は、定数またはコードビサイドファイル内の変数またはメソッドへのポインタである。例えば、ＳｅｎｄアクティビティのＭｅｓｓａｇｅプロパティは、コードビサイドファイル内のメンバ変数を指しており、また、ＴｅｒｍｉｎａｔｅアクティビティのＥｒｒｏｒＳｔｒｉｎｇプロパティには、リテラル形式で実際の文字列を保持したい、またはコードビサイドファイル内の変数を指すようにしたい場合がある。ランタイムの観点から、これは、そのプロパティに対する値を取得することのみを扱い、これは、値が取り出されるリテラル、またはコードビサイドファイル内の変数のいずれかとすることができるであろう。
【０２３４】
【表２３】
2006107477.tif 000026
【０２３５】
一実施形態では、１）リテラル宣言、２）メンバ宣言の、２種類のバリュープロバイダ（value providers）がある。
【０２３６】
ＭｅｍｂｅｒＤｅｃｌａｒａｔｉｏｎ  
これらのオブジェクトは、特定のランタイム型のユーザコードファイル内の変数またはメソッド名を表す。例えば、ＳｅｎｄのＭｅｓｓａｇｅプロパティは、ユーザコードビサイドファイル内の変数を指すが、これは型「Ｓｙｓｔｅｍ．Ｗｏｒｋｆｌｏｗ．Ｒｕｎｔｉｍｅ．ＯＥＭｅｓｓａｇｅ＜Ｔ＞」でなければならない。このようなプロパティは、型「ｓｔｒｉｎｇ」であり、その値は、その変数の名前である。非アクティビティクラスは、文字列値に加えてそれらに関連付けられている何らかのメタデータを持つ。例えば、これらは、その変数がどのようなランタイム型を参照すべきかなどを指示することができる。
【０２３７】
【表２４】
2006107477.tif 000027
【０２３８】
ＭｅｍｂｅｒＤｅｃｌａｒａｔｉｏｎからの主要な継承分岐としては、１）ＶａｒｉａｂｌｅＤｅｃｌａｒａｔｉｏｎ、２）ＨａｎｄｌｅｒＤｅｃｌａｒａｔｉｏｎがある。ＶａｒｉａｂｌｅＤｅｃｌａｒａｔｉｏｎは、ユーザコードビサイドファイル内の変数を参照するために使用され、ＨａｎｄｌｅｒＤｅｃｌａｒａｔｉｏｎは、ユーザコードビサイドファイル内のメソッドを参照するために使用される。ＶａｒｉａｂｌｅＤｅｃｌＷｉｔｈＯｎｅＡｒｇは、ｖａｒｉａｂｌｅＤｅｃｌから継承し、ランタイム型が引数１つをとるジェネリック型である、ユーザコードビサイドファイル内の変数を参照するために使用される。
【０２３９】
さらに、これらの宣言クラスに関連付けられた設計時機能が多数ある。例えば、ＶａｒｉａｂｌｅＤｅｃｌａｒａｔｉｏｎをアクティビティのプロパティ型として使用すると、プロパティブラウザのウィンドウ内にコンボボックスが自動的に表示され、そこに、特定のランタイム型のコードビサイドファイル内のすべての変数の一覧が表示される。また、これらのクラスは、意味論的チェックを実行する機能も持つ。例えば、ＨａｎｄｌｅｒＤｅｃｌａｒａｔｉｏｎは、メソッド名が有効か、メソッドがユーザコードファイル内に存在するか、メソッドのシグネチャがランタイム型プロパティにより識別されたものと一致するかどうかをチェックする。
【０２４０】
変数宣言  
ＶａｒｉａｂｌｅＤｅｃｌａｒａｔｉｏｎは、ＭｅｍｂｅｒＤｅｃｌａｒａｔｉｏｎから継承し、コードビサイドファイルに変数の名前を格納する。これは、実行時モードで以下のように３つの追加メソッドを持つ。
【０２４１】
【表２５】
2006107477.tif 000028
【０２４２】
ＴｙｐｅｄＶａｒｉａｂｌｅＤｅｃｌａｒａｔｉｏｎは、ＶａｒｉａｂｌｅＤｅｃｌａｒａｔｉｏｎから継承し、ランタイム型プロパティを読み取り専用にする。
【０２４３】
ハンドラ宣言  
ＨａｎｄｌｅｒＤｅｃｌａｒａｔｉｏｎは、ＭｅｍｂｅｒＤｅｃｌａｒａｔｉｏｎから継承し、コードビサイドファイル内のメソッド名を指す。これは、コードビサイドクラス内のメソッドを指しているデリゲートオブジェクトを返す実行時の追加メソッドを１つ持つ。  
ＴｙｐｅｄＨａｎｄｌｅｒＤｅｃｌａｒａｔｉｏｎは、ＨａｎｄｌｅｒＤｅｃｌａｒａｔｉｏｎから継承し、ランタイム型プロパティを読み取り専用にする。
【０２４４】
リテラル宣言  
ＬｉｔｅｒａｌＤｅｃｌａｒａｔｉｏｎオブジェクトは、コードビサイドファイル内の変数を指す代わりにリテラル値を含む。以下に、このクラスの定義を示す。
【０２４５】
【表２６】
2006107477.tif 000029
【０２４６】
ルール宣言  
ルールは、オーケストレーションのビヘイビアを動的に変更するためビジネスプロセスにおいて使用される。Ｗｏｒｋｆｌｏｗコンポーネントモデルでは、任意のルール技術をプラグインする方法を定義する。カスタムルール技術を実装するには、ＲｕｌｅＤｅｃｌａｒａｔｉｏｎから継承するクラスを定義しなければならない。これは、ルールの妥当性を確認し、継承されたクラスに実行時初期化モードについて通知する抽象メソッドを持つ。カスタムルール技術プロバイダは、ＲｕｌｅＤｅｃｌａｒａｔｉｏｎクラスから継承し、これらのメソッドをオーバーライドする。また、これは、ルール定義を定義するために使用される追加プロパティを備える。
【０２４７】
現在のところ、ワークフローコンポーネントモデルは、２つのＲｕｌｅＤｅｃｌａｒａｔｉｏｎｓクラスを持ち、１つはＣｏｄｅベースのルール宣言であり、それに関連付けられたＢｏｏｌｅａｎハンドラメソッドを持ち、ルールを評価して、ｔｒｕｅまたはｆａｌｓｅ値を返す。他の技術としては、ＢＲＥベースのルール宣言があり、ルールを定義するオブジェクトモデルを提供する。ルール宣言クラスのランタイム版として、ＲｕｌｅＥｖａｌｕａｔｏｒがある。ワークフローエンジンは、ＲｕｌｅＤｅｃｌａｒａｔｉｏｎクラス上のＲｕｌｅＥｖａｌｕａｔｏｒ属性を探す。この属性は、ＩＲｕｌｅＥｖａｌｕａｔｏｒインターフェイスを実装するＴｙｐｅの名前を指示する。ＩＲｕｌｅＥｖａｕｌａｔｏｒインターフェイスは、論理値を返すただ１つのメソッドＥｖａｌｕａｔｅ（）を持つ。
【０２４８】
実行時モード  
設計時にオーケストレーションプログラムをオーサリングするために使用されるのと同じアクティビティグラフも、実行時にインスタンス化される。実行時に、ワークフローエンジンは、アクティビティグラフのルートオブジェクトを呼び出して実行し、さらに、これは子アクティビティを呼び出して実行し、というように続け、複合アクティビティである子アクティビティは、子アクティビティに自ら実行するよう要求する。アクティビティグラフが実行時に使用するためにインスタンス化された場合、それらのアクティビティでは、プロパティの変更を行えない。
【０２４９】
アクティビティは、Ａｃｔｉｖｉｔｙクラスで定義されているｐｒｏｔｅｃｔｅｄメソッドであるＯｎＲｕｎｔｉｍｅＩｎｉｔｉａｌｉｚｅｄ（）メソッドをオーバーライドすることによりランタイム初期化に関する情報を得る。アクティビティは、このメソッドでカスタムランタイム特有の初期化を実行できる。通常、アクティビティのランタイムインスタンス化では、アクティビティは、文字列化された情報を実際のランタイム型に解決する。例えば、ＩｎｖｏｋｅＷｅｂＳｅｒｖｉｃｅアクティビティは、設計時にプロキシクラスの名前を文字列形式で保持し、ｉｎｖｏｋｅ  ｗｅｂ  ｓｅｒｖｉｃｅがランタイム用にインスタンス化されると、これはプロキシクラス名を実際のＳｙｓｔｅｍ．Ｔｙｐｅオブジェクトに解決する。
【０２５０】
ワークフローエンジンは、実行オーケストレーションの複数のインスタンスに対する１つのアクティビティグラフを保持するだけである。アクティビティに関するＧｅｔＳｔａｔｅ（ｏｂｊｅｃｔ  ｓｃｏｐｅＢｏｕｎｄＯｂｊｅｃｔ）メソッドは、オーケストレーションの特定のインスタンスについてＩＡｃｔｉｖｉｔｙＳｔａｔｅを返す。ＩＡｃｔｉｖｉｔｙＳｔａｔｅインターフェイスを使用して、アクティビティのＳｔａｔｕｓおよびＯｕｔｃｏｍｅプロパティを取得することができる。
【０２５１】
【表２７】
2006107477.tif 000030
【０２５２】
アクティビティのランタイムインスタンス化と並行して、非アクティビティ宣言も、実行時モード用にインスタンス化される。例えば、名前が「ａｒｔ」であり、ランタイム型が「Ｓｙｓｔｅｍ．Ｓｔｒｉｎｇ」であるＶａｒｉａｂｌｅＤｅｃｌａｒａｔｉｏｎは、Ｓｙｓｔｅｍ．Ｒｅｆｌｅｃｔｉｏｎ．ＦｉｅｌｄＩｎｆｏオブジェクトをランタイムインスタンス化の実行時に持ち、これはコードビサイドファイル内の「Ａｒｔ」変数を指している。型ＶａｒｉａｂｌｅＤｅｃｌａｒａｔｉｏｎｓまたはＨａｎｄｌｅｒＤｅｃｌａｒａｔｉｏｎｓであるアクティビティのプロパティも、ＯｎＲｕｎｔｉｍｅＩｎｉｔｉａｌｉｚｅｄ（）をオーバーライドすることにより実行時モードに関する情報を得ることができる。ＭｅｍｂｅｒＤｅｃｌａｒａｔｉｏｎの「Ｓｃｏｐｅ」プロパティは、Ｍｅｍｂｅｒが属しているＳｃｏｐｅオブジェクトで初期化される。さらに、ＶａｒｉａｂｌｅＤｅｃｌａｒａｔｉｏｎおよびＨａｎｄｌｅｒＤｅｃｌａｒａｔｉｏｎのＧｅｔＲｕｎｔｉｍｅＶａｌｕｅ（）およびＳｅｔＲｕｎｔｉｍｅＶａｌｕｅ（）メソッドはスケジュールの特定のインスタンスに対する変数または方法の値を変えすること開始する。
【０２５３】
カスタムアクティビティの作成  
カスタムアクティビティを書くために、アクティビティクラスはＡｃｔｉｖｉｔＤｅｃｌまたはＣｏｍｐｏｓｉｔｅＡｃｔｉｖｉｔｙＤｅｃｌのいずれかから継承する。アクティビティのカスタムシリアライゼーションをサポートするために、ＳｅｒｉａｌｉｚｅｒＡｔｔｒｉｂｕｔｅがアクティビティクラスにすでに追加されている。デザイナ属性により、デザイナはアクティビティに関連付けられる。以下にアクティビティコードのサンプルを示す。
【０２５４】
【表２８】
2006107477.tif 000031
【０２５５】
コンポーネントモデルを使用するサンプルプログラム  
以下に、Ｃｏｍｐｏｎｅｎｔモデルに対するプログラムのサンプルコードを示す。Ｓｃｈｅｄｕｌｅは、オブジェクトモデルのルートである。このサンプルでは、新しいＳｃｈｅｄｕｌｅ列挙型を作成するが、これを使用して、アイテムリストへの変更の理由を示す。
【０２５６】
【表２９】
2006107477.tif 000032
【０２５７】
【表３０】
2006107477.tif 000033
【０２５８】
Ｘｏｍｌコンパイラ  
Ｘｏｍｌコンパイラは、Ｘｏｍｌファイルをコンパイルし、そのファイル用のランタイムコードを生成するために使用される。Ｘｏｍｌコンパイラにより出力されるエラーは、ＸｏｍｌＣｏｍｐｉｌｅｒＥｒｒｏｒによって提示される。また、コンパイラは、ＸｏｍｌＣｏｍｐｉｌｅｒＰａｒａｍｅｔｅｒを入力として受け取る。コンパイラ結果は、ＸｏｍｌＣｏｍｐｉｌｅｒＲｅｓｕｌｔｓによって示される。
【０２５９】
Ｘｏｍｌコンパイラは、ｘｏｍｌファイルをデシリアライズし、その後、アクティビティグラフを辿る。これは、それぞれのアクティビティに対し、与えられたコンテキスト内で自らの妥当性確認を行うよう要求する。アクティビティをバリデーションに参加させたい場合、これは、ＩＡｃｔｉｖｉｔｙＶａｌｉｄａｔｏｒから継承する。どのようなアクティビティからもバリデーションエラーが生じない場合、それぞれのアクティビティに対し、それ自身に対するコードを生成するよう要求する。アクティビティをコード生成に参加させたい場合、これは、ＩＡｃｔｉｖｉｔｙＣｏｄｅＧｅｎｅｒａｔｏｒから継承する。
【０２６０】
ＸｏｍｌＣｏｍｐｉｌｅｒクラス  
Ｘｏｍｌコンパイルは、他の多くの言語コンパイラとは異なる。Ｘｏｍｌコンパイラは、ｘｏｍｌファイル、ユーザコードファイルを入力として受け取り、ランタイムプロセスコードを生成する。以下に、ＸｏｍｌＣｏｍｐｉｌａｔｉｏｎに関わるステップを示す。
【０２６１】
１）すべてのＸｏｍｌファイルをデシリアライズし、そこからアクティビティグラフを作成する。  
２）アセンブリ参照に基づいて、パラメータの形でコンパイラに受け渡されるユーザコードファイルおよびコードコンパイル単位により、ＴｙｐｅＰｒｏｖｉｄｅｒコンポーネントを作成する。  
３）それぞれの個別ｘｏｍｌファイルのアクティビティグラフを辿り、それらに関するｖａｌｉｄａｔｅを呼び出す。  
４）バリデーションをエラーがない場合、各ｘｏｍｌアクティビティグラフに対する一番上のアクティビティでＩＡｃｔｉｖｉｔｙＣｏｄｅＧｅｅｎｒａｔｏｒ．ＧｅｎｅｒａｔｅＣｏｄｅを呼び出し、ＣｏｄｅＳｔａｔｅｍｅｎｔＣｏｌｌｅｃｔｉｏｎを生成する。  
５）生成されたプロセスコードのＣｏｄｅＣｏｍｐｉｌｅＵｎｉｔを出力するか、または渡されたユーザコードでプロセスコードをコンパイルしＣ＃またはＶＢコンパイラを使用してビルドする。
【０２６２】
以下に、ＸｏｍｌＣｏｍｐｉｌｅｒで使用可能なｐｕｂｌｉｃメソッドを示す。
【０２６３】
【表３１】
2006107477.tif 000034
【０２６４】
ＣｏｍｐｉｌｅＦｒｏｍＤｏｍメソッド  
XomlCompilerResults CompileFromDom(XomlCompilerParameters parameters, Schedule scheduleDecl);  
ＣｏｍｐｉｌｅＦｒｏｍＤｏｍは、単一のＳｃｈｅｄｕｌｅのみを入力パラメータとして受け取り、コンパイルしてプロセスコードを生成する。この関数は、一度に１つのスケジュールをコンパイルしたいユーザに役立つ。この関数は、内部で、ＣｏｍｐｉｌｅＦｒｏｍＤｏｍＢａｔｃｈを呼び出している。
【０２６５】
ＣｏｍｐｉｌｅＦｒｏｍＤｏｍＢａｔｃｈメソッド  
XomlCompilerResults CompileFromDomBatch(XomlCompilerparameters parameters, Schedule[] scheduleDecls);  
ＣｏｍｐｉｌｅＦｒｏｍＤｏｍＢａｔｃｈは、複数のＳｃｈｅｄｕｌｅを入力パラメータとして受け取り、コンパイルしてプロセスコードを生成する。
【０２６６】
ＣｏｍｐｉｌｅＦｒｏｍＦｉｌｅメソッド  
XomlCompilerResults CompileFromFile(XomlCompilerParameters parameters, string file);  
ＣｏｍｐｉｌｅＦｒｏｍＦｉｌｅは、単一のｘｏｍｌファイルを入力パラメータとして受け取る。第２のパラメータは、ｘｏｍｌファイルへのパスとして処理される。この関数は、一度に１つのｘｏｍｌファイルをコンパイルしたいユーザに役立つ。この関数は、内部で、ＣｏｍｐｉｌｅＦｒｏｍＦｉｌｅＢａｔｃｈを呼び出している。
【０２６７】
ＣｏｍｐｉｌｅＦｒｏｍＦｉｌｅＢａｔｃｈメソッド  
XomlCompilerResults CompileFromFileBatch(xomlCompilerParameters parameters, string[] files);  
ＣｏｍｐｉｌｅＦｒｏｍＦｉｌｅＢａｔｃｈは、複数のｘｏｍｌファイルを入力として受け取り、コンパイルしてプロセスコードを生成する。第２のパラメータは、ｘｏｍｌファイルへのパスの配列である。この関数は、すべてのｘｏｍｌファイルをデシリアライズする。ＸＯＭＬファイルをデシリアライズできなかった場合、ＳｅｒｉａｌｉｚａｔｉｏｎＥｒｒｏｒがＣｏｍｐｉｌｅｒ  ＲｅｓｕｌｔｓのＥｒｒｏｒｓコレクションに追加される。これは、ＣｏｍｐｉｌｅＦｒｏｍＤｏｍＢａｔｃｈ関数を呼び出してコンパイルを実行する。
【０２６８】
ＣｏｍｐｉｌｅＦｒｏｍＳｏｕｒｃｅメソッド  
XomlCompilerResults CompileFromSource(XomlCompilerParameters parameters, string xomlSource);  
ＣｏｍｐｉｌｅＦｒｏｍＳｏｕｒｃｅは、ｘｏｍｌファイルのテキストを入力パラメータとして受け取り、コンパイルしてプロセスコードを生成する。この関数は、ＣｏｍｐｉｌｅＦｒｏｍＳｏｕｒｃｅＢａｔｃｈを呼び出して実際のコンパイルを実行する。
【０２６９】
ＣｏｍｐｉｌｅＦｒｏｍＳｏｕｒｃｅＢａｔｃｈメソッド  
XomlCompilerResults CompileFromSourceBatch(XomlCompilerParameters parameters, string[] xomlSources);  
ＣｏｍｐｉｌｅＦｒｏｍＳｏｕｒｃｅＢａｔｃｈは、ｘｏｍｌファイルの複数のソースを入力パラメータとして受け取り、コンパイルしてプロセスコードを生成する。これは、ソースをデシリアライズして、アクティビティＤＯＭを取得する。デシリアライゼーションエラーがある場合、これらのエラーはＸｏｍｌＣｏｍｐｉｌｅＥｒｒｏｒに変換され、ｘｏｍｌＣｏｍｐｉｌｅｒＲｅｓｕｌｔｓを通じて報告される。
【０２７０】
ＧｅｎｅｒａｔｅＳｋｅｌｅｔｏｎＣｏｍｐａｎｉｏｎメソッド  
void GenerateSkeletonCompanionCode(Schedule schedule, SupportedLanguages language, System.IO.TextWriter writer);  
この関数は、ハンドラ、アクティビティｄｏｍで使用される変数名に基づいてスケルトンユーザＣｏｄｅビサイドファイルを生成するために使用される。この関数は、アクティビティグラフを辿り、スコープ、変数、およびハンドラのテンプレートコードを生成する。第２のパラメータは、コードを生成するために使用する必要がある言語を指示する。第３のパラメータは、テキストライターであり、これは、生成されたコードが書き込まれるバッファを保持する。  
void GenerateSkeletonCompanionCode(string file, SupportedLanguages language, System.IO.TextWriter writer);  
この関数は、ｘｏｍｌファイルパスを入力パラメータとして受け取る。この関数は、ｘｏｍｌファイルをデシリアライズし、はじめの方の関数を呼び出す。
【０２７１】
ＸｏｍｌＣｏｍｐｉｌｅｒＰａｒａｍｅｔｅｒｓ  
ＸｏｍｌＣｏｍｐｉｌｅｒＰａｒａｍｅｔｅｒｓは、ユーザコードでコンパイラに渡すプロパティを持つ。以下に、ＸｏｍｌＣｏｍｐｉｌｅｒＰａｒａｍｅｔｅｒのｐｕｂｌｉｃインターフェイスを示す。
【０２７２】
【表３２】
2006107477.tif 000035
【０２７３】
ＧｅｎｅｒａｔｅＣｏｄｅＣｏｍｐｉｌｅＵｎｉｔＯｎｌｙプロパティ  
bool GenerateCodeCompileUnitOnly { get; set; }  
このフラグは、ユーザがＣｏｄｅＣｏｍｐｉｌｅＵｎｉｔの生成にのみ関心があり、実行可能ファイルまたはｄｌｌには関心がないことをコンパイラに知らせるために使用される。この場合、コンパイラは、コードを生成するためにＣ＃またはＶＢコンパイラを呼び出さない。
【０２７４】
ＧｅｎｅｒａｔｅＤｅｂｕｇＣｏｄｅプロパティ  
bool GenerateDebugCode { get; set; }  
このフラグは、デバッグコードを使用するかどうかを指示するために使用される。
【０２７５】
ＬａｎｇｕａｇｅＴｏＵｓｅプロパティ  
SupportedLanguages LanguageToUse { get; set; }  
サポートされている言語は、ＶＢおよびＣＳｈａｒｐの少なくとも２つがある。コンパイラは、使用する言語を知っている必要があるが、それは、言語に基づくバリデーションが多数あるからである。
【０２７６】
ＬｉｂｒａｒｙＰａｔｈｓプロパティ  
StringCollection LibraryPaths { get; }  
これは、コンパイラが参照されているアセンブリを探る際に基づくディレクトリ名のコレクションである。コンパイラは、さらにアセンブリ参照を解決するためにいくつかの標準ライブラリパスをこのコレクションに追加することに留意されたい。このビヘイビアは、ＣＳｈａｒｐおよびＶＢコンパイラに似ている。
【０２７７】
ＳｅｒｖｉｃｅＰｒｏｖｉｄｅｒプロパティ  
IServiceProvider ServiceProvider { get; set; }  
このプロパティは、コンパイラがプロジェクトシステムから呼び出された場合のみ使用される。このプロパティの目的は、コンパイルがプロジェクトシステムから呼び出されるときにパフォーマンスを達成することである。プロジェクトシステムはプロジェクト毎に作成されるＴｙｐｅＰｒｏｖｉｄｅｒを持つので、コンパイラは、同じＴｙｐｅＰｒｏｖｉｄｅｒを使用する。これにより、プロジェクトシステムから呼び出されたときにコンパイラのパフォーマンスを大幅に高められる。
【０２７８】
ＵｓｅｒＣｏｄｅＣｏｍｐｉｌｅＵｎｉｔｓプロパティ  
IList<CodeCompileUnit> UserCodeCompileUnits { get; }  
このプロパティは、ユーザコードビサイドファイルのＣｏｄｅコンパイル単位でコンパイラに渡すために使用される。
【０２７９】
ＵｓｅｒＣｏｄｅＦｉｌｅｓプロパティ  
StringCollection UserCodeFiles { get; }  
このプロパティは、ユーザコードビサイドファイルのファイルパスをコンパイラに渡すために使用される。
【０２８０】
ＸｏｍｌＣｏｍｐｉｌｅｒＲｅｓｕｌｔｓ  
ＸｏｍｌＣｏｍｐｉｌｅｒＲｅｓｕｌｔｓは、生成されたプロセスコードのＣｏｄｅＣｏｍｐｉｌｅＵｎｉｔを取り出すためのプロパティを備えている。以下に、ＸｏｍｌＣｏｍｐｉｌｅｒＲｅｓｕｌｔｓのｐｕｂｌｉｃインターフェイスを示す。
【０２８１】
【表３３】
2006107477.tif 000036
【０２８２】
Ｃｏｍｐｉｌｅｄ  Ｕｎｉｔプロパティにより、プロセスコードにアクセスできる。
【０２８３】
ＸｏｍｌＣｏｍｐｉｌｅｒＥｒｒｏｒ  
ＸｏｍｌＣｏｍｐｉｌｅｒＥｒｒｏｒは、Ｄｉｃｔｉｏｎａｒｙ型である、ＵｓｅｒＤａｔａプロパティを取得するメソッドを持つ。このプロパティの目的は、エラーに関する付加的詳細を挿入することである。例えば、プロパティバリデーションの１つがあるアクティビティ上で失敗した場合、ｔｙｐｅｏｆ（ｓｔｒｉｎｇ）を辞書のキーとするプロパティ名を持つ。以下に、このクラスによって公開されるｐｕｂｌｉｃインターフェイスを示す。
【０２８４】
【表３４】
2006107477.tif 000037
【０２８５】
ＸｏｍｌＣｏｍｐｉｌｅｒＥｒｒｏｒは、さらに、ＩＷｏｒｋｆｌｏｗＥｒｒｏｒインターフェイスも実装するが、このインターフェイスの目的は、エラーに対するＣＯＭ相互運用性を実現することである。以下に、ＩＷｏｒｋｆｌｏｗＥｒｒｏｒインターフェイスの定義を示す。
【０２８６】
【表３５】
2006107477.tif 000038
【０２８７】
これらのプロパティは、Ｓｙｓｔｅｍ．ＣｏｄｅＤｏｍで定義されたＣｏｍｐｉｌｅＥｒｒｏｒクラスのプロパティにマッピングされる。
【０２８８】
バリデーションインフラストラクチャ  
すべてのアクティビティは、Ｖａｌｉｄａｔｅメソッドを持つＩＡｃｔｉｖｉｔｙから継承する。ｖａｌｉｄａｔｅメソッドはＩＳｅｒｖｉｃｅＰｒｏｖｉｄｅｒを受け取る。例えば、ＩＴｙｐｅＰｒｏｖｉｄｅｒは、アクティビティのプロパティである型名が実際の型に解決できるのかどうかを判定する。ｖａｌｉｄａｔｅメソッドは、ＩＶａｌｉｄａｔｉｏｎＥｒｒｏｒのコレクションを返す。以下に、Ｖａｌｉｄａｔｅメソッドのシグネチャを示す。  
IValidationError[] Validate(IServiceProvider context);  
以下に、ＩＶａｌｉｄａｔｉｏｎＥｒｒｏｒで利用可能なｐｕｂｌｉｃメソッドを示す。
【０２８９】
【表３６】
2006107477.tif 000039
【０２９０】
バリデーションルーチンのサンプル：  
以下に、ＤｅｌａｙＤｅｃｌアクティビティのバリデーションルーチンの一実施例を示す。Ｄｅｌａｙでは、ＴｉｍｅｏｕｔＰｒｏｖｉｄｅｒハンドラが実際にはヌルでなく、メソッド名が親スコープクラス内に存在することを確認したい。
【０２９１】
【表３７】
2006107477.tif 000040
【０２９２】
そして、以下に、ＨａｎｄｌｅｒＤｅｃｌａｒａｔｉｏｎのバリデーションルーチンを示す。
【０２９３】
【表３８】
2006107477.tif 000041
【０２９４】
【表３９】
2006107477.tif 000042
【０２９５】
ランタイムコード生成  
Ｘｏｍｌコンパイラは、名前空間をスケジュール上のＮａｍｅｓｐａｃｅＮａｍｅプロパティとし、クラス名をスケジュール上のＩＤプロパティとするＳｃｈｅｄｕｌｅクラスを生成する。次に、Ｓｃｈｅｄｕｌｅオブジェクトをｘｏｍｌ文字列にシリアライズし、第１のパラメータをｘｏｍｌ文字列として、ＸｏｍｌＡｔｔｒｉｂｕｔｅでスケジュールクラスに注釈を入れる。
【０２９６】
以下のサンプルコードは、Ｓｃｈｅｄｕｌｅ  Ｄｅｃｌオブジェクトを作成し、さらに、ユーザコードを含むＣｏｄｅＣｏｍｐｉｌｅＵｎｉｔオブジェクトを作成する。さらに、ＳｃｈｅｄｕｌｅオブジェクトおよびＵｓｅｒＣｏｄｅをＸｏｍｌコンパイラに送る。
【０２９７】
特に、以下のコードでスケジュールが作成される。
【０２９８】
【表４０】
2006107477.tif 000043
【０２９９】
以下のコードは、コードコンパイル単位を作成し、名前空間を追加し、ＭｙＳｃｈｅｄｕｌｅ  Ｃｌａｓｓを追加し、ｄｅｌａｙメソッドを追加する。
【０３００】
【表４１】
2006107477.tif 000044
【０３０１】
以下に示すコードは、ＭｙＳｃｏｐｅクラスを作成し、フィールドを追加する。
【０３０２】
【表４２】
2006107477.tif 000045
【０３０３】
【表４３】
2006107477.tif 000046
【０３０４】
以下のコードは最終的なＣ＃コードを生成する。特に、このコードは、ユーザコードからのＣＣＵとＸＯＭＬ  ＯＭのＣＣＵとを組み合わせてアセンブリを生成する。
【０３０５】
【表４４】
2006107477.tif 000047
【０３０６】
エラーナビゲーションインフラストラクチャ  
Ｘｏｍｌコンパイラは、呼び出されると、エラーがあった場合にＩＷｏｒｋｆｌｏｗＥｒｒｏｒオブジェクトのコレクションを返す。ＩＷｏｒｋｆｌｏｗＥｒｒｏｒオブジェクト毎に、タスクアイテムが作成される。以下に、ユーザがタスクアイテムをダブルクリックしたときに、デザイナ上のエラー箇所にナビゲートする作業に関わるステップを示す。
【０３０７】
１）各タスクアイテムは、ＩＷｏｒｋｆｌｏｗＥｒｒｏｒオブジェクトに関連付けられる。  
２）最初にダブルクリックすると、ＩＷｏｒｋｆｌｏｗＥｒｒｏｒ．Ｄｏｃｕｍｅｎｔプロパティを呼び出すことによりファイルの名前を取得する。  
３）デザイナに、ファイルを開き、関連付けられているＤｏｃＶｉｅｗオブジェクトを取得するよう要求する。  
４）ＤｏｃＶｉｅｗ上へのＩＷｏｒｋｆｌｏｗＥｒｒｏｒＮａｖｉｇａｔｏｒインターフェイスを見る。  
５）ＩＷｏｒｋｆｌｏｗＥｒｒｏｒＮａｖｉｇａｔｏｒ．Ｎａｖｉｇａｔｅ（）メソッドを呼び出して、ＩＷｏｒｋｆｌｏｗＥｒｒｏｒを第１のパラメータとして渡す。  
６）ＩＷｏｒｋｆｌｏｗＥｒｒｏｒＮａｖｉｇａｔｏｒインターフェイスが、ドキュメントビューオブジェクト上に実装される。Ｎａｖｉｇａｔｅメソッドの実装では、エディタはＩＷｏｒｋｆｌｏｗＥｒｒｏｒのＵｓｅｒＤａｔａプロパティ内で「ｔｙｐｅｏｆ（ＩＡｃｔｉｖｉｔｙ）」オブジェクトを探そうとし、見つかった場合、そのアクティビティのスコープ修飾名を取得し、デザイナ内で同じ名前を持つアクティビティを探索する。アクティビティが見つかった場合には、フォーカスが当たる。その後、ＵｓｅｒＤａｔａプロパティ内の「ｔｙｐｅｏｆ（ｓｔｒｉｎｇ）」キーを探し、見つかったら、フォーカスを置く必要があるプロパティの名前であると想定し、プロパティ名を第１の引数として渡すことによりＩＥｘｔＵＩＳｅｒｖｉｃｅ．ＮａｖｉａｇｔｅＴｏＰｒｏｐｅｒｔｙ（）メソッドを呼び出す。
【０３０８】
以下に、ＩＷｏｒｋｆｌｏｗＥｒｒｏｒＮａｖｉｇａｔｏｒのインターフェイス定義を示す。
【０３０９】
【表４５】
2006107477.tif 000048
【０３１０】
ワークフローコンパイラ実行可能ファイル（ＷＦＣ．ＥＸＥという名前でもある）  
Ｗｆｃ．ｅｘｅは、コマンドラインバージョンのＸｏｍｌＣｏｍｐｉｌｅｒであるバイナリ製品である。この実行可能ファイルは、コマンドライン引数を解析して、ＸｏｍｌＣｏｍｐｉｌｅｒＰａｒａｍｅｔｅｒｓ構造体に書き込む。
【０３１１】
以下に、ＸｏｍｌＣｏｍｐｉｌｅｒに渡すことができるオプションの定義を示す。
【０３１２】
【表４６】
2006107477.tif 000049
【０３１３】
タイプシステム  
タイプシステムは、デザイナ内の独立のコンポーネントである。ＣｏｄｅＣｏｍｐｉｌｅＵｎｉｔおよびアセンブリは、タイプシステムにプッシュすることができる。これは、Ｓｙｓｔｅｍ．Ｔｙｐｅオブジェクトをアセンブリ参照からロードし、タイプツリーにプッシュする。また、ＣｏｄｅＣｏｍｐｉｌｅＵｎｉｔ内のＣｏｄｅＴｙｐｅＤｅｃｌａｒａｔｉｏｎオブジェクト毎に、Ｓｙｓｔｅｍ．Ｔｙｐｅから継承するＤｅｓｉｇｎＴｉｍｅＴｙｐｅを作成し、タイプツリーにプッシュする。このようにして、タイプシステムからの型は、共通抽象クラスＳｙｓｔｅｍ．Ｔｙｐｅにより公開される。他の多くのタイプシステムと同様に、型をロードするときにツリー構造を作成し、型解決を高速化している。タイプシステムは、型を解決するためのタイプツリー上のユーザインターフェイスを備え、さらに、イベントを発火して、タイプツリー内の変更を通知する。
【０３１４】
以下に、タイプシステム内の主要なコンポーネントを示す。  
１．ＴｙｐｅＰｒｏｖｉｄｅｒ：これは、アセンブリ参照およびＣｏｄｅＣｏｍｐｉｌｅＵｎｉｔをタイプシステムに追加／削除するｐｕｂｌｉｃメソッドを持つ。さらに、これは、タイプツリーをユーザに公開するインターフェイスを実装する。  
ａ．ＴｒｅｅＮｏｄｅ：ツリーノードは、タイプツリー内の一般的ノードである。これは、それに関連付けられているすべての型定義を保持する。  
２．ＣｏｄｅＤＯＭＬｏａｄｅｒ：ＣｏｄｅＤＯＭ  Ｌｏａｄｅｒは、Ｃｏｄｅ  Ｃｏｍｐｉｌｅ  Ｕｎｉｔからすべての型をロードし、それらをＴｙｐｅ  Ｔｒｅｅにプッシュする。ＣｏｄｅＤＯＭローダを処置すると、これは、タイプツリーに追加したすべての型を削除する。  
３．ＡｓｓｅｍｂｌｙＬｏａｄｅｒ：アセンブリローダは、アセンブリからすべての型をロードして、すべての型をタイプツリーにプッシュする。これを処置した後、タイプツリーからすべての型を削除する。
４．ＤｅｓｉｇｎＴｉｍｅＴｙｐｅ：このクラスはＳｙｓｔｅｍ．Ｔｙｐｅから継承する。これは、ＣｏｄｅＴｙｐｅＤｅｃｌａｒａｔｉｏｎ  ＣｏｄｅＤＯＭコンストラクトをコンストラクタの引数として受け取り、Ｓｙｓｔｅｍ．Ｔｙｐｅクラスのすべてのプロパティおよびメソッドを実装する。さらに、以下のクラスを使用して、ＣｏｄｅＴｙｐｅＤｅｃｌａｒａｔｉｏｎからＳｙｓｔｅｍ．Ｔｙｐｅに変換する。  
ａ．ＤｅｓｉｇｎＴｉｍｅＭｅｔｈｏｄＩｎｆｏ：このクラスは、ＣｏｄｅＭｅｍｂｅｒＭｅｔｈｏｄに基づいてＭｅｔｈｏｄＩｎｆｏのすべてのメンバを実装するために使用される。  
ｉ．ＤｅｓｉｇｎＴｉｍｅＰａｒａｍｅｔｅｒＩｎｆｏ：このクラスは、ＰａｒａｍｅｔｅｒＩｎｆｏから継承し、ＣｏｄｅＰａｒａｍｅｔｅｒＤｅｃｌａｒａｔｉｏｎＥｘｐｒｅｓｓｉｏｎ  Ｃｏｄｅ  ＤＯＭコンストラクトに基づいて実装を行う。
【０３１５】
ｂ．ＤｅｓｉｇｎＴｉｍｅＥｖｅｎｔＩｎｆｏ：このクラスは、ＣｏｄｅＭｅｍｂｅｒＥｖｅｎｔに基づいてＥｖｅｎｔＩｎｆｏのメンバを実装するために使用される。  
ｃ．ＤｅｓｉｇｎＴｉｍｅＦｉｅｌｄＩｎｆｏ：このクラスは、ＦｉｅｌｄＩｎｆｏから継承し、ＣｏｄｅＭｅｍｂｅｒＦｉｅｌｄに基づいてすべてのメソッドおよびプロパティの実装を行う。  
ｄ．ＤｅｓｉｇｎＴｉｍｅＰｒｏｐｅｒｔｙＩｎｆｏ：このクラスは、ＰｒｏｐｅｒｔｙＩｎｆｏから継承し、ＣｏｄｅＭｅｍｂｅｒＰｒｏｐｅｒｔｙ  Ｃｏｄｅ  Ｄｏｍに基づいてすべてのメソッドおよびプロパティの実装を行う。  
ｅ．ＤｅｓｉｇｎＴｉｍｅＣｏｎｓｔｒｕｃｔｏｒＩｎｆｏ：このクラスは、ＣｏｎｓｔｒｕｃｔｏｒＩｎｆｏから継承し、ＣｏｄｅＭｅｍｂｅｒＭｅｔｈｏｄに基づいてすべてのメソッドおよびプロパティの実装を行う。  
ｆ．ＡｔｔｒｉｂｕｔｅＩｎｆｏ：ＡｔｔｒｉｂｕｔｅＩｎｆｏクラスは、型の属性に関する情報を保持するために使用される。
【０３１６】
タイププロバイダコンポーネント  
タイププロバイダは、タイプシステム内の最上位のコンポーネントである。タイププロバイダのインスタンスを作成できる。タイププロバイダは、タイプツリーのルートノードを保持する。アセンブリ参照およびコードコンパイル単位をタイププロバイダに追加するときに、それらからすべての型をロードし、タイプツリーにロードする。  
ここで例として、以下の型がアセンブリから得られる場合を取りあげる。
【０３１７】
【表４７】
2006107477.tif 000050
【０３１８】
次に、対応するツリー構造は以下のようになる。
【０３１９】
【表４８】
2006107477.tif 000051
【０３２０】
それぞれのノードは、それが指す型定義のリストを保持する。例えば、上のシナリオでは、ＳｔｒｉｎｇノードはＳｙｓｔｅｍ．Ｓｔｒｉｎｇ型を含む。型定義のリストは、それぞれのノード上で保持される。タイプシステム内には、重複する型がありえる。
以下に、タイププロバイダのパブリックメソッドを示す。
【０３２１】
ＡｄｄＡｓｓｅｍｂｌｙＲｅｆｅｒｅｎｃｅメソッド  
public void AddAssemblyReference(string path)  
このメソッドは、アセンブリ参照をタイプシステムに追加する場合に使用される。アセンブリからのすべての型がタイプシステムにロードされる。
【０３２２】
ＲｅｍｏｖｅＡｓｓｅｍｂｌｙＲｅｆｅｒｅｎｃｅメソッド  
public void RemoveAssemblyReference(string path)  
このメソッドは、アセンブリ参照をタイプシステムから削除する場合に使用される。アセンブリからタイプツリーにロードされたすべての型が削除される。
【０３２３】
ＡｄｄＣｏｄｅＣｏｍｐｉｌｅＵｎｉｔメソッド  
public void AddCodeCompileUnit(CodeCompileUnit codeCompileUnit)  
このメソッドは、ＣｏｄｅＣｏｍｐｉｌｅＵｎｉｔｓをタイプシステムにロードする場合に使用される。これは、コードコンパイル単位内のすべてのＣｏｄｅＴｙｐｅＤｅｃｌａｒａｔｉｏｎｓを通り、それらのそれぞれについてＳｙｓｔｅｍ．Ｔｙｐｅから継承する適切なＤｅｓｉｇｎＴｉｍｅＴｙｐｅを作成する。さらに、ＤｅｓｉｇｎＴｉｍｅＴｙｐｅがタイプシステムにロードされる。
【０３２４】
ＲｅｍｏｖｅＣｏｄｅＣｏｍｐｉｌｅＵｎｉｔメソッド  
public void RemoveCodeCompileUnit(CodeCompileunit codeCompileUnit)  
このメソッドは、ＣｏｄｅＣｏｍｐｉｌｅＵｎｉｔをタイプシステムからアンロードする場合に使用される。ＣｏｄｅＣｏｍｐｉｌｅＵｎｉｔからロードされたすべての型が削除される。
【０３２５】
ＲｅｆｒｅｓｈＣｏｄｅＣｏｍｐｉｌｅＵｎｉｔメソッド  
public void RefreshCodeCompileUnit(CodeCompileUnit codeCompileUnit, CodeCompileUnitRefreshHandler refresher)  
このメソッドは、タイプシステム内のコードコンパイル単位をリフレッシュする場合に使用される。これは、タイプシステムからコンパイル単位を削除し、その後タイプシステムに追加して戻すことに似ている。
【０３２６】
ＩＴｙｐｅＰｒｏｖｉｄｅｒインターフェイス  
このサービスは、ホスティング環境のタイプシステム内の型にアクセスし、解決するために使用される。これは、ＴｙｐｅＰｒｏｖｉｄｅｒコンポーネントにより公開されるインターフェイスである。ＩＴｙｐｅＰｒｏｖｉｄｅｒは、ＴｙｐｅＰｒｏｖｉｄｅｒによりユーザに公開されるインターフェイスである。タイプシステム内の型を解決するために使用される。以下に、このインターフェイスの定義を示す。
【０３２７】
【表４９】
2006107477.tif 000052
【０３２８】
以下では、デザイナでＴｙｐｅＰｒｏｖｉｄｅｒをホスティングすることに関わるコンポーネントについて説明する。
【０３２９】
ＴｙｐｅＰｒｏｖｉｄｅｒＨｏｓｔコンポーネント  
ＴｙｐｅＰｒｏｖｉｄｅｒＨｏｓｔは、プロジェクト毎にＴｙｐｅＳｙｓｔｅｍを維持するために使用される主コンポーネントである。ＴｙｐｅＰｒｏｖｉｄｅｒＨｏｓｔは、プロジェクトシステムポインタおよび対応するＴｙｐｅＰｒｏｖｉｄｅｒを保持する。これは、すべてのユーザコードファイルを解析することにより１つのＣｏｄｅＣｏｍｐｉｌｅＵｎｉｔをＴｙｐｅＳｙｓｔｅｍにプッシュする。さらに、タイプシステムに含まれる型を修正できるすべてのプロジェクトシステムイベントを監視する。以下は、ＴｙｐｅＰｒｏｖｉｄｅｒＨｏｓｔにより実行されるアーキテクチャ上の作業である。  
１．ユーザコードファイルを解析して、ＣｏｄｅＣｏｍｐｉｌｅＵｎｉｔを作成する（ＦｉｌｅＣｏｄｅＭｏｄｅｌからＣｏｄｅＤＯＭ層へ）。
【０３３０】
２．プロジェクトシステム内のイベントを監視し、適宜ＴｙｐｅＰｒｏｖｉｄｅｒを呼び出して型をリフレッシュする。  
次に、監視対象のイベントのリストと、変更を通知するために実行する対応するＴｙｐｅＰｒｏｖｉｄｅｒ呼び出しを示す。  
ＩＬａｎｇＦｉｌｅＥｖｅｎｔｓ：これらのイベントは、プロジェクタ内のファイル追加、削除、移動、ビルドアクションの変更などについて追跡される。これらのイベントのどれかが発生した場合、タイププロバイダはＣｏｄｅＣｏｍｐｉｌｅＵｎｉｔをリフレッシュする。  
＿ｄｉｓｐＣｏｄｅＭｏｄｅｌＥｖｅｎｔｓ：これらのイベントは、新しいＣｏｄｅＥｌｅｍｅｎｔがユーザコードファイルに追加されると必ずＶｉｓｕａｌ  Ｂａｓｉｃのファイルコードモデルにより発火する。これらのイベントは、Ｖｉｓｕａｌ  Ｂａｓｉｃプロジェクトシステムのみを対象とし、類似のイベントでもＣ＃プロジェクトシステムでは発火しない。  
＿ｄｉｓｐＲｅｆｅｒｅｎｃｅｓＥｖｅｎｔｓ：これらのイベントは、アセンブリ参照をプロジェクトに追加または削除すると発火する。追加アセンブリ参照イベントを取得すると、アセンブリが対応するＴｙｐｅＰｒｏｖｉｄｅｒに追加される。削除アセンブリ参照イベントを取得すると、アセンブリ参照がタイプシステムから削除される。  
＿ｄｉｓｐＢｕｉｌｄＥｖｅｎｔｓ：ビルドイベントは、オブジェクト間参照の場合について追跡される。そのような場合、参照されるプロジェクトがビルドされると、古いアセンブリはタイプシステムから削除され、新しいアセンブリがＴｙｐｅＰｒｏｖｉｄｅｒ内にリフレッシュされて新しいタイプをそこからロードする。  
＿ＩＶｓＲｕｎｎｉｎｇＤｏｃＴａｂｌｅＥｖｅｎｔｓ：実行ドキュメントテーブルイベントは、複数の目的に関して追跡される。例えば、エディタ内でドキュメントが変更されたが、保存せずに閉じられた場合、タイプシステムがファイル内の変更で更新されたため、タイプシステムは非保存状態に戻される。ドキュメントが編集のためエディタで開かれた場合、本発明では、ＩＶｓＴｅｘｔＳｔｒｅａｍＥｖｅｎｔｓを監視し、それらのイベントを取得し、コードコンパイル単位をリフレッシュする。  
＿ＩＶｓＴｅｘｔＳｔｒｅａｍＥｖｅｎｔｓ：これらのイベントは、ユーザによるファイル編集の実行を監視するために使用される。
【０３３１】
ＩＴｙｐｅＰｒｏｖｉｄｅｒＣｒｅａｔｏｒサービス  
ＩＴｙｐｅＰｒｏｖｉｄｅｒＣｒｅａｔｏｒサービスは、デザイナパッケージレベルで公開される。そのサービスを使用することで、プロジェクトに対するＴｙｐｅＰｒｏｖｉｄｅｒを取得することができる。以下に、ＩＴｙｐｅＰｒｏｖｉｄｅｒＣｒｅａｔｏｒのインターフェイス定義を示す。
【０３３２】
【表５０】
2006107477.tif 000053
【０３３３】
このサービスは、オーケストレーションデザイナパッケージにより実装される。このサービスの実装では、ＩＶｓＳｏｌｕｔｉｏｎを監視し、ソリューション内のプロジェクト毎にタイププロバイダホストを維持する。また、このサービスは、誰かが最初に要求したときにプロジェクトに対するＴｙｐｅＰｒｏｖｉｄｅｒＨｏｓｔを作成する。開発者は、このサービスを使用して、任意のプロジェクトのＴｙｐｅＳｙｓｔｅｍにアクセスする。また、ソリューションが閉じると、このサービスはシステム内のすべてのＴｙｐｅＰｒｏｖｉｄｅｒＨｏｓｔを破壊する。プロジェクトを閉じると、このサービスは、システムから対応するＴｙｐｅＰｒｏｖｉｄｅｒＨｏｓｔを削除する。
【０３３４】
オーケストレーションエンジンツールボックスページでは、アセンブリにより分類されたツールボックスエントリをバイナリファイルでバッファリングする。アクティブ化されると、これらのエントリはそのページにロードされる。ツールボックス内のアイテムはチェックされ、ツールボックスによりそれらが示されているかどうかを示す。Ｕｓｅｒは、ｂｒｏｗｓｅボタンを選択することにより、異なるアセンブリから新しいツールボックスアイテムを追加することができる。Ｂｒｏｗｓｅボタンにより、Ｆｉｌｅ  Ｓｅｌｅｃｔダイアログが現れ、そこで、ユーザはアセンブリを選択し、そこから追加ツールボックスアイテムをロードすることができる。ツールボックスページでは、ユーザ選択アセンブリを別のアプリケーション領域にロードし、ＴｏｏｌｂｏｘＳｅｒｖｉｃｅ．ＧｅｔＴｏｏｌＢｏｘＩｔｅｍｓを呼び出すことによりそれからすべてのツールボックスアイテムを取り出す。これらのアイテムは、領域間でマーシャリングされ、ツールボックスページ内にロードされる。これは、ユーザアセンブリが一次領域にロードされロックされないように実行される。その後、Ｕｓｅｒは、ツールボックス内に表示する必要があるツールボックスアイテムのチェックボックスのオン、オフを行うことができる。ダイアログが閉じられると、ツールボックスページはＴｏｏｌｂｏｘＳｅｒｖｉｃｅ．ＡｄｄＴｏｏｌＢｏｘＩｔｅｍｓおよびＴｏｏｌｂｏｘＳｅｒｖｉｃｅ．ＲｅｍｏｖｅＴｏｏｌＢｏｘＩｔｅｍｓを使用し、そのチェックボックスのオン／オフ状態に基づいてツールボックスへのアイテムの追加および削除を行う。ツールボックスページでは、さらに、更新されたツールボックスエントリをバイナリファイル内でシリアライズし、次回ツールボックスページが表示されたときにそれらがロードされるようにする。
【０３３５】
ＧｅｔＴｙｐｅメソッド  
Type GetType(string name);  
このメソッドは、タイプツリー内で型を解決するために使用される。Ｕｓｅｒは、「Ａ．Ｂ．Ｃ」の形で文字列を渡すが、ただし、Ａ．Ｂは名前空間であり、Ｃは名前空間内の型の名前である。このメソッドは、「ｎｕｌｌ」を返す可能性があるが、これは、後に続く名前を持つ型が解決できなかったことを意味する。
【０３３６】
ＧｅｔＴｙｐｅオーバーロードメソッド  
Type GetType(string name, bool throwOnError);  
このメソッドは、上記のメソッドと同一であるが、型が見つからない場合に例外をスローするという点のみが異なる。
【０３３７】
ＧｅｔＴｙｐｅｓメソッド  
Type[] GetTypes();  
このメソッドは、タイプシステム内に存在するすべての型を取り出すために使用される。
【０３３８】
ＴｙｐｅＬｏａｄＥｒｒｏｒｓプロパティ  
StringCollection TypeLoadErrors {get; }  
タイププロバイダに型をロードするときに、何らかの問題を生じる可能性があり、例えば、アセンブリ参照を解決できないことがある。このようなシナリオでは、ＴｙｐｅＬｏａｄＥｒｒｏｒｓプロパティがすべての型ロードエラーを返す。
【０３３９】
ＴｙｐｅｓＣｈａｎｇｅｄイベント  
event EventHandler TypesChanged;  
新しいアセンブリ参照またはコードコンパイル単位がタイプシステムに追加されると必ず、このイベントは、ユーザに対し発火され、タイプシステム内の型が変更されたことを通知する。これは、型が追加または削除される特定の情報を提供しないことを意味する一般的イベントである。
【０３４０】
遅延ロードインフラストラクチャ  
タイプシステムは、遅延ロード機能を持つ。ＴｙｐｅＰｒｏｖｉｄｅｒに追加されたアセンブリ参照およびＣｏｄｅＣｏｍｐｉｌｅＵｎｉｔｓは、誰かがタイプツリーから型を解決することを必要とするまでロードされない。そこで、ＡｄｄＡｓｓｅｍｂｌｙＲｅｆｅｒｅｎｃｅおよびＡｄｄＣｏｍｐｉｌｅＵｎｉｔ内のコードがアセンブリパスおよびＣｏｄｅＣｏｍｐｉｌｅＵｎｉｔを捕捉し、ＴｙｐｅｓＣｈａｎｇｅｄイベントを発火する。型はどれも、誰かがそれを必要としない限りロードされない。この手法により、タイプシステムのパフォーマンスで改善される。このような理由から、型ロードが失敗した場合には例外はスローされない。その代わりに、ＴｙｐｅＬｏａｄＥｒｒｏｒｓが発火する。
【０３４１】
【表５１】
2006107477.tif 000054
【０３４２】
ＸｏｍｌＳｅｒｉａｌｉｚｅｒクラス  
アクティビティに関連付けられているシリアライザコンポーネントはＸｏｍｌＳｅｒｉａｌｉｚｅｒから継承する。ＸｏｍｌＳｅｒｉａｌｉｚｅｒは、それらのアクティビティの既定のシリアライザコンポーネントでもある。これは、アクティビティプロパティ越しに反映し、それらをシリアライズする。複合アクティビティについては、既定のシリアライザコンポーネントはＣｏｍｐｏｓｉｔｅＸｏｍｌＳｅｒｉａｌｉｚｅｒであり、プリミティブＸｏｍｌシリアライゼーションに加えて、子アクティビティをもシリアライズする。
【０３４３】
このクラスの関数は、さらに、ｘｏｍｌファイルのシリアライズおよびデシリアライズを行うために使用されるパブリック関数、オブジェクトのシリアライゼーションを制御するために使用される関数、およびオブジェクトのデシリアライゼーションを制御するために使用される関数として分類することができる。
【０３４４】
ＸＯＭＬファイルのシリアライズ／デシリアライズを行うパブリック関数  
public object Deserialize(XmlTextReader reader)  
このメソッドは、ＸｍｌＴｅｘｔＲｅａｄｅｒオブジェクトが与えられると、それをデシリアライズし、オブジェクトを返す。ＸｍｌＴｅｘｔＲｅａｄｅｒは、ｘｍｌ要素を指している。これは、ｘｏｍｌファイルをデシリアライズするパブリックメソッドである。  
public object Deserialize(IDesignerSerializationManager sm, XmlTextReader reader)  
このメソッドは、ＴｅｘｔＲｅａｄｅｒおよびＩＤｅｓｉｇｎｅｒＳｅｒｉａｌｉｚａｔｉｏｎＭａｎａｇｅｒが与えられたアクティビティをデシリアライズする。ＩＤｅｓｉｇｎｅｒＳｅｒｉａｌｉｚａｔｉｏｎＭａｎａｇｅｒオブジェクトは、オブジェクトのカスタムデシリアライザを提供し、さらに型を解決するために使用することができる。  
public void Serialize(object obj, XmlTextWriter writer)  
このメソッドは、第１のパラメータで指定されたオブジェクトをＸｍｌＴｅｘｔＷｒｉｔｅｒオブジェクトにシリアライズする。  
public void Serialize(IDesignerSerializationManager sm, object obj, XmlTextWriter wr);  
このメソッドは、オブジェクトをＸｍｌＴｅｘｔＷｒｉｔｅｒオブジェクトにシリアライズする。これは、型などを解決するために使用できる追加デザイナシリアライゼーションマネージャオブジェクトを受け取る。
【０３４５】
オブジェクトのデシリアライズ  
protected object DeserializeObject(IXomlSerializationManager sm, XmlTextReader rd);  
このメソッドは、要素をデシリアライズし、オブジェクトを作成する。これは、ＣＬＲ名前空間およびアセンブリマッピングへのｘｍｌｎｓを使用してオブジェクトの型を解決し、その後、その型に関連付けられているシリアライザコンポーネントに、その型のインスタンスを作成する機会を与える。ＸｏｍｌＳｅｒｉａｌｉｚｅｒのＣｒｅａｔｅＩｎｓｔａｎｃｅメソッドは、オブジェクトのインスタンスを作成するために使用され、これは、派生クラスでオーバーライドすることができる。ＸｍｌＴｅｘｔＲｅａｄｅｒは、要素ノードを指していなければならないが、そうでなければ、このメソッドは例外をスローする。このメソッドは、オブジェクトのインスタンスを作成した後にＤｅｓｅｒｉａｌｉｚｅＣｏｎｔｅｎｔｓを呼び出す。
【０３４６】
protected void DeserializeContents(IXomlSerializationManager sm, object obj, XmlTextReader rd);  
このメソッドは、オブジェクトのプロパティおよび子オブジェクトをデシリアライズするために使用される。これは、オブジェクトおよびＸｍｌＴｅｘｔＲｅａｄｅｒをパラメータとして受け取る。ＸｍｌＴｅｘｔＲｅａｄｅｒは、ＸｍｌＥｌｅｍｅｎｔノードを指している。要素のすべての属性を辿り、シリアライザ上でＤｅｓｅｒｉａｌｉｚｅＳｉｍｐｌｅＰｒｏｐｅｒｔｙ（）を呼び出す。ＤｅｓｅｒｉａｌｉｚｅＳｉｍｐｌｅＰｒｏｐｅｒｔｙは、プロパティのカスタムデシリアライゼーションを実行するようにオーバーライドできる。その後、要素のすべての子要素を通り、それらを子オブジェクトまたはプロパティとして認識する。これは、子要素をプロパティとして理解した後、シリアライザ上でＤｅｓｅｒｉａｌｉｚｅＣｏｍｐｏｕｎｄＰｒｏｐｅｒｔｙ（）を呼び出し、理解しなかった場合は、ＤｅｓｅｒｉａｌｉｚｅＯｂｊｅｃｔ（）を呼び出して、子要素をデシリアライズし、返されたオブジェクトを主オブジェクトの子として追加する。返されたオブジェクトを子オブジェクトとして追加するには、シリアライザ上で異なる親子関係を実装するためにオーバーライドできるＡｄｄＣｈｉｌｄ（）メソッドを呼び出す。
【０３４７】
protected virtual void DeserializeSimpleProperty(IXomlSerializationManager sm. object obj, XmlTextReader rd);  
このメソッドは、単純プロパティをデシリアライズするために、ＤｅｓｅｒｉａｌｉｚｅＣｏｎｔｅｎｔｓ（）により呼び出される。単純プロパティが一部であるオブジェクトおよびｔｈｅ  ＸｍｌＴｅｘｔＲｅａｄｅｒは、パラメータとして受け渡される。ＸｍｌＴｅｘｔＲｅａｄｅｒは、属性を指す。属性の名前は、プロパティの名前として処理される。
【０３４８】
protected virtual void DeserializeCompoundProperty(IXomlSerializationManager sm, object obj, PropertyDescriptor pd, XmlTextReader rd);  
このメソッドは、複合プロパティをデシリアライズするために、ＤｅｓｅｒｉａｌｉｚｅＣｏｎｔｅｎｔｓ（）により呼び出される。これは、オブジェクト、プロパティディスクリプタ、およびＸｍｌＴｅｘｔＲｅａｄｅｒを受け渡される。ＸｍｌＴｅｘｔＲｅａｄｅｒは、ＸｍｌＥｌｅｍｅｎｔを指す。このプロパティは、読み取り専用または非読み取り専用とすることができる。プロパティが読み取り専用であれば、そのプロパティのｇｅｔｔｅｒメソッドが呼び出され、オブジェクトを与え、次に、そのオブジェクトのＤｅｓｅｒｉａｌｉｚｅＣｏｎｔｅｎｔｓが呼び出され、オブジェクトのコンテンツをデシリアライズする。プロパティが読み書きの場合、ただ１つの子要素を持つことができる。第１の子要素は、デシリアライズされ、返されたオブジェクトがプロパティ上で設定される。
【０３４９】
オブジェクトのシリアライズ
protected void SerializeObject(IXomlSerializationManager s, object o, XmlText Writer wr);  
このメソッドは、オブジェクトをシリアライズするために呼び出される。シリアライズされる必要のあるオブジェクトおよびシリアライゼーションコンテンツが書かれなければならないＸｍｌＴｅｘｔＷｒｉｔｅｒを渡される。このメソッドは、実際にはオブジェクトの型のｘｍｌ名前空間およびクラス名であるオブジェクトのＸｍｌＱｕａｌｉｆｌｅｄＮａｍｅを構成する。ｘｍｌ名前空間は、そのオブジェクトの型のアセンブリおよび名前空間情報を使用して構成される。これは、その修飾名を持つｘｍｌ要素の開始を書き、その後、ＳｅｒｉａｌｉｚｅＣｏｎｔｅｎｔｓ（）を呼び出してそのオブジェクトのプロパティおよび子オブジェクトをさらにシリアライズする。そして、ＥｎｄＥｌｅｍｅｎｔを呼び出して要素を閉じる。
【０３５０】
protected void SerializeContents(IXomlSerializationManager s, object o, XmlTextWriter w);  
このメソッドは、オブジェクトのすべてのプロパティおよび子オブジェクトをシリアライズするために呼び出される。このメソッドは、オブジェクトおよびＸｍｌ要素を指すＸｍｌＴｅｘｔＷｒｉｔｅｒを渡される。オブジェクトのシリアライザコンポーネントを探し、それのＧｅｔＰｒｏｐｅｒｔｉｅｓ（）を呼び出して、オブジェクトのプロパティを取得する。プロパティのＤｅｓｉｇｎｅｒＳｅｒｉａｌｉｚａｔｉｏｎＶｉｓｉｂｉｌｉｔｙ属性を探し、ＶｉｓｉｂｌｙがＶｉｓｉｂｌｅに設定されている場合、プロパティは単純プロパティとして取り扱われ、ＳｅｒｉａｌｉｚｅｓｉｍｐｌｅＰｒｏｐｅｒｔｙが呼び出され、ＶｉｓｉｂｉｌｉｔｙがＣｏｎｔｅｎｔに設定されている場合、プロパティは複合プロパティとして取り扱われ、ＳｅｒｉａｌｉｚｅＣｏｍｐｏｕｎｄＰｒｏｐｅｒｔｙ（）が呼び出され、さもなければ、ＶｉｓｉｂｉｌｉｔｙがＨｉｄｄｅｎに設定されている場合、プロパティは無視される。さらに、これは、プロパティのＤｅｆａｕｌｔＶａｌｕｅ属性を調べて、プロパティのＤｅｆａｕｌｔ  Ｖａｌｕｅがプロパティの値と同じであれば、そのプロパティはスキップされる。これは、オブジェクトのシリアライザコンポーネント上でＧｅｔＣｈｉｌｄｒｅｎ（）を呼び出し、すべての子オブジェクトを取得する。その後、ＳｅｒｉａｌｉｚｅＯｂｊｅｃｔ（）を使用してすべてのオブジェクトをシリアライズする。
【０３５１】
protected virtual void SerializeSimpleProperty(IXomlSerializationManager sm, object obj, PropertyDescriptor pd, string parentPropName, XmlTextWriter wr);
このメソッドは、プロパティがシリアライズされる必要のあるオブジェクト、プロパティのＰｒｏｐｅｒｔｙＤｅｓｃｒｉｐｔｏｒ、およびＸｍｌｔｅｘｔＷｒｉｔｅｒオブジェクトを渡される。この関数は、プロパティ名を属性名として、プロパティ値を属性値として使用することにより、ＸｍｌＴｅｘｔＷｒｉｔｅｒを使用してｘｍｌ属性を書き込む。
【０３５２】
protected virtual void SerializeCompoundProperty(IXomlSerializationManager sm, object obj, PropertyDescriptor pd, XmlTextWriter wr);  
このメソッドは、オブジェクトの複合プロパティをシリアライズするために使用される。これは、オブジェクト、プロパティディスクリプタ、およびＸｍｌＴｅｘｔＷｒｉｔｅｒオブジェクトを渡される。プロパティが読み取り専用の場合、要素を作成して、プロパティのｇｅｔｔｅｒメソッド呼び出しにより返されるオブジェクトでＳｅｒｉａｌｉｚｅＣｏｎｔｅｎｔｓ（）を呼び出し、そうでない場合、名前がプロパティの名前である開始要素を書き、プロパティのｇｅｔｔｅｒメソッド呼び出しにより返されるオブジェクトでＳｅｒｉａｌｉｚｅＯｂｊｅｃｔ（）を呼び出す。
【０３５３】
ヘルパー関数  
protected virtual List GetChildren(object obj);  
このメソッドは、オブジェクトの子オブジェクトを取得するために使用される。通常、親子関係を記述するために異なるメカニズムを使用する。例えば、ＩＣｏｍｐｏｓｉｔｅＡｃｔｉｖｉｔｙは、Ａｃｔｉｖｉｔｉｅｓプロパティを使用してプログラムにより子オブジェクトを表す。異なるシリアライザは、このプロパティをオーバーライドして、子オブジェクトのリストを返すことができる。既定では、これは＜ｎｕｌｌ＞値を返す。  
protected virtual PropertyDescriptorCollection GetProperties(object obj);  
このメソッドは、オブジェクトのプロパティを取得するために使用される。既定では、このメソッドは、Ｂｒｏｗｓａｂｌｅ属性がｔｒｕｅに設定され、ＤｅｓｉｇｎｅｒＳｅｒｉａｌｉｚａｔｉｏｎＶｉｓｉｂｉｌｉｔｙ属性がＨｉｄｄｅｎに設定されていないプロパティを返す。オブジェクトシリアライザコンポーネントは、これをオーバーライドして、返されたプロパティのコレクションを制御することができる。
【０３５４】
protected virtual void AddChild(object obj, object childObj);  
このメソッドは、親オブジェクトの子を追加するために使用される。これは、ＧｅｔＣｈｉｌｄｒｅｎ（）の逆を実行する。シリアライザコンポーネントは、ＡｄｄＣｈｉｌｄ（）実装のビヘイビアを制御することができる。  
protected virtual object CreateInstance(Type type, XmlTextReader rd);  
このメソッドは、型の継承を作成するために使用される。既定では、Ａｃｔｉｖａｔｏｒ．ＣｒｅａｔｅＩｎｓｔａｎｃｅ（）を呼び出して、オブジェクトを作成する。しかし、派生クラスは、コンポーネント型のＣｒｅａｔｅｌｎｓｔａｎｃｅ（）に対し異なる手法を使用することができ、またＸｍｌＴｅｘｔＲｅａｄｅｒオブジェクトを使用することによりコンストラクタにいくつかのパラメータを受け渡すこともできる。
【０３５５】
ＣｏｍｐｏｓｉｔｅＸｏｍｌＳｅｒｉａｌｉｚｅｒクラス  
複合Ｘｏｍｌシリアライザは、複合アクティビティをシリアライズするために使用される。これは、子アクティビティのデシリアライズおよびシリアライズのため基本クラスからオーバーライドされた２つのメソッドを持つ。
【０３５６】
【表５２】
2006107477.tif 000055
【０３５７】
ＩＸｏｍｌＳｅｒｉａｌｉｚａｔｉｏｎＭａｎａｇｅｒインターフェイス  
ＩＸｏｍｌＳｅｒｉａｌｉｚａｔｉｏｎＭａｎａｇｅｒはＩＤｅｓｉｇｎｅｒＳｅｒｉａｌｉｚａｔｉｏｎＭａｎａｇｅｒクラスから継承する。これは、ｘｍｌ修飾名が与えられた場合にアクティビティ型を与え、アクティビティ型が与えられた場合にｘｍｌ修飾名を与える追加機能を提供する。以下に、ＩＸｏｍｌＳｅｒｉａｌｉｚａｔｉｏｎＭａｎａｇｅｒのインターフェイス定義を示す。
【０３５８】
【表５３】
2006107477.tif 000056
【０３５９】
シリアライゼーションエラー  
Ｘｏｍｌシリアライザは、ＩＤｅｓｉｇｎｅｒＳｅｒｉａｌｉｚａｔｉｏｎＭａｎａｇｅｒ．ＲｅｐｏｒｔＥｒｒｏｒ（）メソッドを使用してすべてのＤｅｓｅｒｉａｌｉｚａｔｉｏｎエラーを追加する。デシリアライゼーションでエラーが発生した場合、単にエラーオブジェクトを追加するだけであるが、ｘｍｌ形式が不正でない限りデシリアライゼーションプロセスを停止しない。ＸｏｍｌＳｅｒｉａｌｉｚｅｒは、ＸｏｍｌＳｅｒｉａｌｉｚｅｒＥｘｃｅｐｔｉｏｎクラスを使用してデシリアライゼーションエラーを報告する。
【０３６０】
【表５４】
2006107477.tif 000057
【０３６１】
ワークフローｃｏｍｐｏｎｅｎｔＭｏｄｅｌは、さらに、スケジュールをＷｅｂサービス記述言語（ＷＳＤＬ）形式にシリアライズする操作も行う。
【０３６２】
オーケストレーションエンジンデザイナのアーキテクチャ  
オーケストレーションエンジンデザイナでは、Ｓｙｓｔｅｍ．ＣｏｍｐｏｎｅｎｔＭｏｄｅｌおよびＳｙｓｔｅｍ．ＣｏｍｐｏｎｅｎｔＭｏｄｅｌ．Ｄｅｓｉｇｎ名前空間内で定義されたクラスを使用する。オーケストレーションエンジンデザイナより使用されるフレームワークインフラストラクチャクラスは、ＤｅｓｉｇｎＳｕｒｆａｃｅ、ＤｅｓｉｇｎＳｕｒｆａｃｅＭａｎａｇｅｒ、およびＤｅｓｉｇｎｅｒＬｏａｄｅｒである。これらのクラスはすべて、Ｓｙｓｔｅｍ．ＣｏｍｐｏｎｅｎｔＭｏｄｅｌ．Ｄｅｓｉｇｎ名前空間の一部である。  
以下の表は、この名前空間の記述および用途を簡単に説明したものである。
【０３６３】
【表５５】
2006107477.tif 000058
【０３６４】
ＤｅｓｉｇｎＳｕｒｆａｃｅおよびＤｅｓｉｇｎＳｕｒｆａｃｅＭａｎａｇｅｒ  
ＤｅｓｉｇｎＳｕｒｆａｃｅは、デザイナを表し、デザイナによって必要とされるサービスの既定の集合を含む。ＤｅｓｉｇｎＳｕｒｆａｃｅＭａｎａｇｅｒは、これらのデザイナで通信目的に使用できる何らかのアプリケーションレベルのサービスとともに、本質的にデザイナのコレクションを提供する。ＤｅｓｉｇｎＳｕｒｆａｃｅは、ＩＳｅｒｖｉｃｅＰｒｏｖｉｄｅｒインターフェイスを使用して複数のサービスを公開する。公開されるマスターサービスはＩＤｅｓｉｇｎｅｒＨｏｓｔである。ＩＤｅｓｉｇｎｅｒＨｏｓｔは、コンポーネント上で宣言されたＤｅｓｉｇｎｅｒＡｔｔｒｉｂｕｔｅに基づいて、それに追加されたコンポーネントのコレクションを保持し、それに追加されたすべてのコンポーネントについてデザイナを作成する。デザイナホストに追加されたすべてのコンポーネントは、ＩＣｏｍｐｏｎｅｎｔから継承しなければならない。さらに、それに追加された第１のコンポーネントは、ＲｏｏｔＣｏｍｐｏｎｅｎｔと呼ばれる。ＲｏｏｔＣｏｍｐｏｎｅｎｔのデザイナは、ＩＲｏｏｔＤｅｓｉｇｎｅｒと呼ばれるインターフェイスを実装しなければならない。このインターフェイスは、ＧｅｔＶｉｅｗ（）と呼ばれるメソッドを持ち、このメソッドはルートコンポーネントに対する「Ｃｏｎｔｒｏｌ」オブジェクトを返す。デザインサーフェスは、そのビュープロパティ実装のルートコンポーネントのＧｅｔＶｉｅｗ（）により返されるＣｏｎｔｒｏｌを返す。
【０３６５】
オーケストレーションエンジンデザイナは、ＳｃｈｅｄｕｌｅをＲｏｏｔＣｏｍｐｏｎｅｎｔとして使用し、ＳｅｒｖｉｃｅＲｏｏｔＤｅｓｉｇｎｅｒをそのルートデザイナとして使用する。ＳｅｒｖｉｃｅＲｏｏｔＤｅｓｉｇｎｅｒのＧｅｔＶｉｅｗ（）メソッドは、ホスティング環境により直接ホスティングできる、「ＷｏｒｋｆｌｏｗＶｉｅｗ」コントロールを返し、例えば、オーケストレーションエンジンデザイナがデザイナでホスティングされる場合、ＷｏｒｋｆｌｏｗＶｉｅｗコントロールは、ＩＶｓＷｉｎｄｏｗＰａｎｅの一次ウィンドウによりホスティングされる。
【０３６６】
ＤｅｓｉｇｎｅｒＬｏａｄｅｒ  
ＤｅｓｉｇｎｅｒＬｏａｄｅｒは、オブジェクトグラフのデシリアライゼーションおよびシリアライゼーションを受け持つ抽象クラスである。デザイナローダが作成され、デザイナのシリアライズされた状態を含むデータのファイルまたはブロブを渡される。データとローダとの間の関係は、ローダの実装にはプライベートである。デザイナローダは、ロードプロセスを開始するよう求められる。デザイナの作成方法を知らないＤｅｓｉｇｎＳｕｒｆａｃｅにアクセスできるようにするＩＤｅｓｉｇｎｅｒＬｏａｄｅｒＨｏｓｔと呼ばれるインターフェイスポインタを渡される。ＩＤｅｓｉｇｎｅｒＬｏａｄｅｒＨｏｓｔは、さらに、いくつかの共通ユーティリティ関数も備える。デザイナローダは、シリアライズされたデータのバッグを解釈する。これは、コンポーネントのインスタンスを作成し、それらをコンテナに追加し、プロパティを設定する。オーケストレーションエンジンデザイナは、ＳｅｒｖｉｃｅＤｅｓｉｇｎｅｒＬｏａｄｅｒをＤｅｓｉｇｎｅｒＬｏａｄｅｒクラスの実装として持つ。
【０３６７】
Ｘｏｍｌファイルから、ＷｏｒｋｆｌｏｗＶｉｅｗコントロールへの旅（ｊｕｒｎｅｙ）  
以下に、Ｘｏｍｌをデシリアライズし、Ｗｉｎｄｏｗ  Ｆｏｒｍコントロールに表示するためこれらのインフラストラクチャ断片すべてをつなぎ合わせる方法を説明する擬似コードを示す。
【０３６８】
【表５６】
2006107477.tif 000059
【０３６９】
上記のコードは、まず、ＤｅｓｉｇｎＳｕｒｆａｃｅを作成する。次に、ＤｅｓｉｇｎｅｒＬｏａｄｅｒを作成し、サーフェスオブジェクトをコンストラクタ内に渡す。その後、ＦｉｌｅＰａｔｈプロパティをローダに設定する。次に、指定されたローダを使用してロードを開始するようにサーフェスに要求する。ＤｅｓｉｇｎＳｕｒｆａｃｅは、さらに、ＤｅｓｉｇｎｅｒＬｏａｄｅｒ．ＢｅｇｉｎＬｏａｄ（）を呼び出してｘｏｍｌファイルをロードする。これにより、アクティビティがＤｅｓｉｇｎＳｕｒｆａｃｅに追加され、これによりさらに、それらのアクティビティ用のデザイナが作成され、アクティビティおよびデザイナが捕捉される。追加された最初のコンポーネントは、ＲｏｏｔＣｏｍｐｏｎｅｎｔと呼ばれるＳｃｈｅｄｕｌｅであり、ＤｅｓｉｇｎｅｒＡｔｔｒｉｂｕｔｅを使用して、ＳｅｒｖｉｃｅＲｏｏｔＤｅｓｉｇｎｅｒがデザイナとして関連付けられる。
【０３７０】
ＩＣｏｍｐｏｎｅｎｔおよびＩＣｏｍｐｏｎｅｎｔ．Ｓｉｔｅ  
ＤｅｓｉｇｎＳｕｒｆａｃｅに追加されたすべてのコンポーネントは、ＩＣｏｍｐｏｎｅｎｔを実装する。ＤｅｓｉｇｎＳｕｒｆａｃｅは、Ｓｉｔｅオブジェクトを作成し、それをＩＣｏｍｐｏｎｅｎｔ．Ｓｉｔｅプロパティに設定する。コンポーネントがサイト設定されると、それは特定のコンテナにより「所有される」と言われる。コンテナは、コンポーネントのサイトを通じてサービスをコンポーネントに提供することができ、コンテナ自体は、親サービスプロバイダにサービス要求をデリゲートすることさえできる。
【０３７１】
ＩＤｅｓｉｇｎｅｒおよびＩＡｃｔｉｖｉｔｖＤｅｓｉｇｎｅｒ  
デザインサーフェスに追加されるコンポーネントは、ＩＤｅｓｉｇｎｅｒインターフェイスを実装する、それらに関連付けられたデザイナを持つ。ＩＤｅｓｉｇｎｅｒインターフェイスは、プリミティブであり、提供される機能は、すべてのコンポーネントに共通である。オーケストレーションエンジンＤｅｓｉｇｎＳｕｒｆａｃｅでデザイナをホスティングするには、ＵＩ関連作業の大半を実行するように定義されているインターフェイスである、ＩＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒを実装しなければならない。例えば、ドラッグ／ドロップ、マウス、キーボード、レイアウト、レンダリングなどである。デザイナは、型ＤｅｓｉｇｎｅｒＡｔｔｒｉｂｕｔｅのクラスレベルの属性を通じてコンポーネントに関連付けられる。デザイナは、ＩＣｏｎｔａｉｎｅｒインターフェイスの特別な実装により作成される。コンポーネントがこのコンテナに追加されると、コンテナは、コンポーネントのメタデータ内でデザイナ属性を探索する。存在すれば、デザイナが作成され、初期化される。
【０３７２】
設計時サービス要件  
すべてのデザイナは、それが関連付けられているＩＣｏｍｐｏｎｅｎｔにより初期化される。ＩＣｏｍｐｏｎｅｎｔ．Ｓｉｔｅを使用すると、デザイナは、外部の世界を通して通信できる。コンポーネントがＩＤｅｓｉｇｎｅｒＨｏｓｔに追加される場合、デザイナホストは、そのコンポーネントに対するサイトを作成し、それをＩＣｏｍｐｏｎｅｎｔ．Ｓｉｔｅプロパティに設定する。サイトは、ＩＳｅｒｖｉｃｅＰｒｏｖｉｄｅｒから継承し、これにより、デザイナは外部世界のサービスにアクセスすることができる。
【０３７３】
ＤｅｓｉｇｎＳｕｒｆａｃｅにより提供されるサービス  
これらは、ＤｅｓｉｇｎＳｕｒｆａｃｅにより提供される標準サービスである。
【０３７４】
【表５７】
2006107477.tif 000060
【０３７５】
ホスティング環境により提供されるサービス  
【０３７６】
【表５８】
2006107477.tif 000061
【０３７７】
ワークフロービュー  
ワークフロービューは、ＸＯＭＬで記述されるプロセスフローのビジュアル表現をレンダリングするデザインサーフェスである。ワークフロービューは、レンダリングするため、またさまざまなウィンドウ生成イベントに応答するためにアクティビティデザイナにより必要とされるＵＩ機能を数多く備える。これに加えて、ワークフロービューは、すべてのデザイナにより使用できる共通関数の集合を提供し、これにより、いくつかのアクティビティを実行する。  
public class WorkflowView: UserControl, IDesignerService, IDesignerView, IServiceProvider
【０３７８】
【表５９】
2006107477.tif 000062
【０３７９】
ＵｓｅｒＣｏｎｔｒｏｌ：ユーザコントロールを使用することにより、ワークフロービューをサードパーティアプリケーションに再ホスティングし、ワークフローをレンダリングすることができる。
【０３８０】
ＩＤｅｓｉｇｎｅｒＳｅｒｖｉｃｅ：デザイナサービスを使用すると、ワークフロービューに、アクティビティデザイナおよびその他のホストがやり取りしてさまざまなユーザインターフェイス機能を活用できるようにする機能を公開することができる。
【０３８１】
ＩＤｅｓｉｇｎｅｒＶｉｅｗ：デザイナビューインターフェイスを使用すると、ワークフロービューコンテナでワークフローとやり取りすることができる。このサービスを使用すると、外部のコンテナがそのアクティブ状態をワークフロービューに伝達し、そのメッセージに対する応答として、ＵＩ状態を更新し、初期化を実行できる。
ＩＳｅｒｖｉｃｅＰｒｏｖｉｄｅｒ：ワークフロービューはアクティビティデザイナへのサービスプロバイダとして機能し、ワークフロービューを使用すれば、アクティビティデザイナは、サービスコンテナで提供される他のサービスにアクセスすることができる。
【０３８２】
ワークフロービューは、ＸＯＭＬで記述されるプロセスフローのビジュアル表現をレンダリングするデザインサーフェスである。ワークフロービューは、レンダリングするため、またさまざまなウィンドウ生成イベントに応答するためにアクティビティデザイナにより必要とされるＵＩ機能を数多く備える。これに加えて、ワークフロービューは、すべてのデザイナにより使用できる共通関数の集合を提供し、これにより、いくつかのアクティビティを実行する。
【図面の簡単な説明】
【０３８３】
【図１】タスクおよび制御フロー複合アクティビティを含むワークフローの実施例を示す図である。
【図２】アクティビティ継承ツリーの実施例を示す図である。
【図３】コンポーネントモデルの実施例を示す図である。
【図４】コンポーネントモデルのライフサイクルの例を示す図である。
【図５】ワークフローの指定にウィザードに依存する、ワークフローオーサリングするための高水準アプリケーションユーザインターフェイスを示す図である。
【図６】ワークフローデザイナの実施例を示す図である。
【図７】送信アクティビティが後に続く受信アクティビティを含むオーケストレーションプログラムを示す図である。
【図８】グラフ内のオブジェクトのシリアライゼーションを示す図である。
【図９】スケジュール定義およびビジュアルワークフローと、ワークフローのＸＯＭＬによるシリアライズされた表現と、ワークフローのコードビサイドとの間の関係を示す図である。
【図１０】本発明を実装することができる１つの好適なコンピューティングシステム環境の一実施例を示すブロック図である。
【符号の説明】
【０３８４】
４０２  パレットコンポーネント
４０４  インターフェイスコンポーネント
４０６  宣言的コンポーネント
４０８  ランタイムコンポーネント
１３２  演算処理装置
１３４  システムメモリ
１３６  システムバス
１４４  オペレーティングシステム
１４６  アプリケーションプログラム
１４８  その他のプログラムモジュール
１５０  プログラムデータ
１６６  不揮発性メモリインターフェイス
１７０  オペレーティングシステム
１７２  アプリケーションプログラム
１７４  その他のプログラムモジュール
１７６  プログラムデータ
１８４  ユーザ入力インターフェイス
１８６  ネットワークインターフェイス
１９０  ビデオインターフェイス
１９２  リモートアプリケーションプログラム
１９６  ローカルエリアネットワーク
１９８  ワイドエリアネットワーク
【図１】
2006107477.tif 000063
【図２】
2006107477.tif 000064
【図３】
2006107477.tif 000065
【図４】
2006107477.tif 000066
【図５】
2006107477.tif 000067
【図６】
2006107477.tif 000068
【図７】
2006107477.tif 000069
【図８】
2006107477.tif 000070
【図９】
2006107477.tif 000071
【図１０】
2006107477.tif 000072