(57)【要約】【課題】  コンポーネント化された拡張可能なワークフローモデルを提供する。【解決手段】  宣言型マークアップ言語を介して、コンポーネント化されたワークフローモデルを表現する。ワークフローの各ステップは、ワークフローステップの設計時の諸面、コンパイル時の諸面、および実行時の諸面を記述するメタデータを有するアクティビティとしてモデリングされる。ユーザは、ユーザインターフェースまたはアプリケーションプログラミングインターフェースを介して、アクティビティを選択し、配置してワークフローを作成する。ワークフローの各アクティビティに関連付けられたメタデータが集められて、ワークフローの永続的表現を作成する。ユーザは、カスタムのアクティビティを作成することによりワークフローモデルを拡張する。【選択図】  図１
2006107474.tif 000002
【特許請求の範囲】
【請求項１】
宣言ファイルを作成およびコンパイルするコンピュータ化された方法であって、前記宣言ファイルは、中に複数のアクティビティを有し、前記複数のアクティビティは、ユーザによって定義されたワークフローを作成するように配置され、前記複数のアクティビティはそれぞれ、関連付けられたシリアライザとメタデータを有し、前記コンピュータ化された方法は、
前記ユーザによって定義されたワークフローに対応する前記複数のアクティビティを受け取るステップと、
それぞれが前記受け取られた複数のアクティビティの少なくとも１つに関連付けられた複数のシリアライザを識別するステップと、
前記識別された複数のシリアライザを実行して、前記複数のアクティビティのメタデータを前記ワークフローの宣言型表現に移すステップであって、前記メタデータは、前記複数のアクティビティそれぞれに関連付けられた機能を定義するステップと
を備えることを特徴とする方法。
【請求項２】
前記メタデータは、プロパティ、メソッド、およびイベントの１つまたは複数を備えることを特徴とする請求項１に記載のコンピュータ化された方法。
【請求項３】
前記メタデータはソフトウェアコードを備え、さらに、
前記ワークフローの前記宣言型表現から前記メタデータを取り出すステップと、
前記ソフトウェアコードをコンパイルするステップと、
前記取り出されたメタデータおよび前記コンパイルされたソフトウェアコードに応じて前記ワークフローを再作成するステップと
を備えることを特徴とする請求項１に記載のコンピュータ化された方法。
【請求項４】
前記移されたメタデータを、妥当性検査のために拡張可能スキーマ定義の名前空間にマッピングするステップをさらに備えることを特徴とする請求項１に記載のコンピュータ化された方法。
【請求項５】
前記ワークフローの前記宣言型表現をコンパイルして実行ファイルを作成するステップをさらに備えることを特徴とする請求項１に記載のコンピュータ化された方法。
【請求項６】
前記複数のアクティビティそれぞれの妥当性を検査するステップをさらに備えることを特徴とする請求項１に記載のコンピュータ化された方法。
【請求項７】
１つまたは複数のデータソースに前記メタデータを関連付けるステップをさらに備えることを特徴とする請求項１に記載のコンピュータ化された方法。
【請求項８】
前記複数のアクティビティそれぞれに関連付ける宣言データを定義するステップをさらに備えることを特徴とする請求項１に記載のコンピュータ化された方法。
【請求項９】
１つまたは複数のコンピュータ可読媒体が、請求項１に記載の方法を行うコンピュータ実行可能命令を有することを特徴とする請求項１に記載のコンピュータ化された方法。
【請求項１０】
宣言ファイルを作成およびコンパイルするコンピュータ実行可能コンポーネントを有する１つまたは複数のコンピュータ可読媒体であって、前記宣言ファイルは、中に複数のアクティビティを有し、前記複数のアクティビティは、ユーザによって定義されたワークフローを作成するように配置され、前記複数のアクティビティはそれぞれ、関連付けられたシリアライザとメタデータを有し、前記コンポーネントは、
前記ユーザによって定義されたワークフローに対応する前記複数のアクティビティを受け取るインターフェースコンポーネントと、
それぞれが前記インターフェースコンポーネントによって受け取られた前記複数のアクティビティの少なくとも１つに関連付けられた複数のシリアライザを識別するメタデータコンポーネントと、
前記メタデータコンポーネントによって識別された前記複数のシリアライザを実行して、前記複数のアクティビティのメタデータを前記ワークフローの宣言型表現に移す直列化コンポーネントであって、前記メタデータは、前記複数のアクティビティそれぞれに関連付けられた機能を定義する直列化コンポーネントと
を備えることを特徴とするコンピュータ可読媒体。
【請求項１１】
前記移されたメタデータを、妥当性検査のために拡張可能スキーマ定義の名前空間にマッピングする妥当性検査コンポーネントをさらに備えることを特徴とする請求項１０に記載のコンピュータ可読媒体。
【請求項１２】
前記インターフェースコンポーネントは、グラフィカルユーザインターフェースおよびアプリケーションプログラミングインターフェースの１つまたは複数を備えることを特徴とする請求項１０に記載のコンピュータ可読媒体。
【請求項１３】
複数のアクティビティを中に有する宣言ファイルを作成およびコンパイルするシステムであって、
前記複数のアクティビティを記憶するメモリ領域であって、前記複数のアクティビティは、ユーザによって定義されたワークフローを作成するように配置され、前記メモリ領域はさらに、前記複数のアクティビティそれぞれのシリアライザとメタデータを記憶し、前記メタデータは、前記複数のアクティビティそれぞれに関連付けられた機能を定義するメモリ領域と、
前記ユーザによって定義された前記ワークフローに対応する前記複数のアクティビティを前記メモリ領域から取り出し、
前記受け取られた複数のアクティビティの少なくとも１つにそれぞれが関連付けられた複数のシリアライザを前記メモリ領域から識別し、
前記識別された複数のシリアライザを実行して、前記複数のアクティビティの前記メタデータを前記メモリ領域から前記ワークフローの宣言型表現に移す
コンピュータ実行可能命令を実行するように構成されたプロセッサと
を備えることを特徴とするシステム。
【請求項１４】
前記ユーザによって定義された前記ワークフローに対応する前記複数のアクティビティを前記メモリ領域から取り出す手段をさらに備えることを特徴とする請求項１３に記載のシステム。
【請求項１５】
それぞれが前記受け取られた複数のアクティビティの少なくとも１つに関連付けられた複数のシリアライザを前記メモリ領域から識別する手段をさらに備えることを特徴とする請求項１３に記載のシステム。
【請求項１６】
前記識別された複数のシリアライザを実行して、前記複数のアクティビティのメタデータを前記メモリ領域から前記ワークフローの宣言型表現に移す手段をさらに備えることを特徴とする請求項１３に記載のシステム。
【請求項１７】
前記複数のアクティビティそれぞれに関連付けられたコンポーネントモデルをさらに備え、前記コンポーネントモデルは、
前記アクティビティを視覚的に表現するアイコンと、
前記メタデータに関連付けられたソフトウェアコードと、
前記ソフトウェアコードを実行するランタイムアプリケーションプログラムと
を備えることを特徴とする請求項１３に記載のシステム。
【請求項１８】
前記ワークフローの前記宣言型表現を表すデータ構造をさらに備え、前記データ構造は、
前記ワークフローの識別情報を記憶するマニフェストと、
前記ワークフローを定義する関連付けられたプロパティ、メソッド、およびイベントをそれぞれが有する前記複数のアクティビティのリストと
を備えることを特徴とする請求項１３に記載のシステム。
【請求項１９】
前記プロパティは、共通言語ランタイムタイプを備えることを特徴とする請求項１８に記載のシステム。
【請求項２０】
前記識別情報は、名前、バージョン、記述、および識別の１つまたは複数を備えることを特徴とする請求項１８に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、ワークフローモデリングの分野に関する。詳細には、本発明の実施形態は、コンポーネント化された、拡張可能なワークフローモデルに関する。
【背景技術】
【０００２】
ＣＤ−ＲＯＭのコンピュータプログラム一覧の付録
本特許のファイルは、ＡＳＣＩＩファイルフォーマットのＭＳＦＴ５１３９．ＴＸＴと題するメモリファイルを含む読み取り専用コンパクトディスク（ＣＤ−ＲＯＭ）の複製を含む。このファイルは２００５年１月２０日に作成され、４２，０００バイトのサイズである。このテキスト文書は、本発明のためのコンピュータプログラム一覧の可能な一実施形態の例を表すコード行を含む。ＣＤ−ＲＯＭと同ＣＤ−ＲＯＭに含まれるＭＳＦＴ５１３９．ＴＸＴファイルは、参照により本願に組み込まれる。本願は、このＣＤ−ＲＯＭのコンピュータプログラム一覧の付録、コード行、およびそれに含まれるコード行番号の参照を含む。
【０００３】
本願は、２００４年１０月１日出願の米国仮特許出願第６０／６１５，５４１号の利益を請求する。
【０００４】
既存のシステムは、業務上の課題をモデリングすることにより、業務上の課題を高水準のワークフローに対応付けることを試みる。しかし、現実世界のワークフローは、（ａ）実行とモデリングの複雑さ、（ｂ）設計時におけるフローの構造の知識、（ｃ）静的に定義されるか、随時（ａｄ  ｈｏｃ）／動的であるか、（ｄ）ライフサイクルにおける様々な時点でのフローの作成と編集の容易さ、（ｅ）ビジネスロジックとコアワークフロープロセスとの関連付けが弱いか、強いか、などの諸面で異なる。既存のモデルは、こうしたすべての要素には対応できていない。
【０００５】
さらに、大半の既存のワークフローモデルは、言語に基づく手法（ＢＰＥＬ４ＷＳ、ＸＬＡＮＧ／Ｓ、ＷＳＦＬなど）か、またはアプリケーションに基づく手法を基本とする。言語に基づく手法は、あらかじめ定義されたコンストラクトの限定されたセットを有する、高水準のワークフロー言語であり、ユーザ／プログラマに合わせてワークフロープロセスをモデリングするのを助ける。そのようなワークフロー言語は、限定されたコンストラクトのセットについてのすべての意味情報を伝達して、ユーザがワークフローモデルを構築できるようにする。しかし、そうした言語は、開発者によって拡張することができず、ワークフローモデルを構成するプリミティブの限定されたセットに相当する。それらの言語は、ワークフローシステムベンダから提供される言語コンパイラに結び付けられる。そのワークフローシステム製品のベンダだけが、その製品の将来のバージョンで、新しいコンストラクトのセットで言語を拡張することによってモデルを拡張することができる。拡張には、しばしば、その言語に関連付けられたコンパイラをアップグレードすることが必要となる。
【０００６】
アプリケーションに基づく手法は、領域固有の問題を解決するワークフロー能力をそのアプリケーション内に有するアプリケーションである。そうしたアプリケーションは、真に拡張可能ではなく、プログラム可能なモデルも持たない。
【発明の開示】
【発明が解決しようとする課題】
【０００７】
既存の手法では、複雑性、事前の知識、動的なワークフロー、作成の容易さ、およびビジネスロジックとコアワークフローの関連付けの強さなどの問題が十分には対処されない。視覚的ワークフローの設計者が様々なクラスのワークフローをモデリングするために利用することができる、拡張、カスタマイズ、再ホストが可能なワークフローデザイナフレームワークは存在しない。既存のシステムには、ユーザがワークフロープロセスを視覚的に設計し、開発者によって選択されたプログラミング言語でビジネスロジックを関連付けることができる、ラピッドアプリケーション開発（ＲＡＤ）型のワークフロー設計エクスペリエンスが欠如している。また、インク対応のワークフローデザイナも存在しない。
【０００８】
また、既存のシステムは、ワークフローを実行するための随時の、あるいは動的なシームレスな編集を提供しない。ワークフロープロセスは、本質的に動的で流動的であり、その形は、設計時に完全に予測することはできない。ワークフロープロセスは、構造化された方式で開始し、最終的には、その実行の存続期間中に進展し、変化して行く。ワークフローの構築者が設計時に様々なタイプのワークフローモデルを作成することができ、また、実行されているワークフローにシームレスな方式で、随時の、あるいは動的な変更を加えることができるワークフロー作成フレームワークが必要とされる。ワークフロープロセスが配置され、実行中となった後でも、しばしば、業務要件の変化により、現在実行されているワークフロープロセスを変更または編集することが余儀なくされる。ワークフロープロセスの実行時の作成を提供するシステムが必要とされる。
【０００９】
また、ワークフロープロセスは、ワークフロープロセスモデルの複数のステップにまたがる横断的で直交的な入り組んだ問題を扱う。例えば、ワークフロープロセスの一部は、長期間にわたる業務に関与するように設計され、一方、同じプロセスの他の部分は、並行して実行されるように設計される。同じワークフロープロセスのさらに他の部分は追跡を必要とし、一方、他の部分は、業務またはアプリケーションレベルの例外を処理する。ワークフロープロセスの１つまたは複数の部分に一定の挙動を適用する必要がある。
【００１０】
一部のワークフローモデリング手法は、あらゆる例外と人間による介入を含む全業務プロセスを完全にフローに基づいて記述することが必要であるため、実用的ではない。そうした手法の中には、例外が発生すると追加的な機能を提供するものがあり、一方、他の手法は、業務プロセスをモデリングするフローに基づく手法の代わりに、制約に基づく手法を限定的に用いる。既存のシステムは、このフローに基づく手法か、制約に基づく手法のいずれかを実施する。そのようなシステムは、多くの一般的な業務状況をモデリングするだけの柔軟性がない。
【００１１】
したがって、こうした不利点および他の不利点の１つまたは複数に対処するために、コンポーネント化された拡張可能なワークフローモデルが望まれる。
【課題を解決するための手段】
【００１２】
本発明の実施形態は、コンポーネント化されたワークフローモデルを構築するための拡張可能なフレームワークを提供する。詳細には、ワークフロープロセスの各ステップは、そのワークフローステップの設計時の諸面、コンパイル時の諸面、および実行時の諸面を記述する、関連付けられたコンポーネントモデルを有する。さらに、どの開発者でも、それらのコンポーネントを作成することにより、コアワークフローモデルを拡張することができる。本発明は、非常に形式的なマシン間のプロセス、制約に基づく人間による随時のワークフロー、およびフローに基づく手法と制約に基づく手法の混合を有するワークフローを含む各種のワークフローの実行を調整する柔軟性があり、強力なワークフローエンジンを含む。このワークフローエンジンは、実行されるワークフローに対する、起動、実行、照会、および制御の機能を可能にする。例えば、本発明は、実行中のワークフローへの随時の動的な変更を可能にする。ワークフローエンジンは、サーバ環境とクライアント環境の両方を含む各種のホスト環境で再ホストする、あるいは埋め込むことが可能である。特定のホスト環境はそれぞれ、ワークフローエンジンをサービスプロバイダのセットと結合する。サービスプロバイダの集合的な機能が、特定のホスト環境で実行されることが可能なワークフローの種類を決定する。
【００１３】
本発明の他の実施形態は、ワークフローモデルを直列化（ｓｅｒｉａｌｉｚｅ）するための拡張可能オーケストレーションマークアップ言語（ＸＯＭＬ）などの宣言フォーマットを提供する。この宣言フォーマットは、ユーザが、コンポーネントのセットを書くことによりワークフローモデルを拡張することを可能にする。ワークフロープロセスの各種ステップに対応するセマンティックは、コンパイル時に所与のコンポーネントのセマンティックを検証し、強制するアクティビティバリデータコンポーネントにカプセル化される。本発明の宣言フォーマットの実施形態はさらに、データを宣言し、ワークフローモデルの各種要素に関連付けることを可能にする。宣言フォーマットは、ワークフローを通じたデータの変換をサポートする。例えば、このフォーマットは、データベースやファイルなどの外部データソース、コードスニペット（ｓｎｉｐｐｅｔ）、およびワークフローモデル中の業務規則を宣言的に表す。
【００１４】
本発明の一実施形態は、様々なクラスのワークフローをモデリングするためのグラフィカル／視覚的なワークフローデザイナを構築する、拡張、カスタマイズ、および再ホストが可能なワークフローデザイナフレームワークを提供する。本発明の別の実施形態は、ユーザがワークフロープロセスをグラフィックで設計し、任意のプログラミング言語の業務ロジックを関連付けることができる、ラピッドアプリケーション開発型のワークフロー設計エクスペリエンスをサポートする。本発明の実施形態は、ペンおよびタブレット技術を使用したインクのサポートも提供する。本発明は、ユーザによって描画されたワークフローが内部表現に変換されるフリーフォームの描画面を提供する。本発明は、既存の描画面でインク編集を介してワークフローを作成および変更（アクティビティの追加／削除など）することと、すでにあるワークフローにインク注釈を加える（設計面に手で書かれたコメント、提案、リマインダなど）ことをサポートする。
【００１５】
本発明のさらに他の実施形態は、横断的な挙動を宣言的に取り込み、その挙動を、ワークフローモデルの選択された部分に適用するコンポーネントを提供する。本発明の他の実施形態は、その部分に関連付けられた挙動のコンテクストで、ワークフローモデルの選択部分を実行する。本発明の実施形態は、ワークフロープロセスモデルの複数のステップにまたがる、横断的で直交した入り組んだ問題に対処する、フレームワーク、再使用可能なコンポーネント、および言語を提供する。
【００１６】
本発明の一態様によれば、コンピュータ化された方法が、宣言ファイルを作成し、コンパイルする。宣言ファイルは、複数のアクティビティを含む。複数のアクティビティは、ユーザによって定義されたワークフローを作成するように配置される。複数のアクティビティはそれぞれ、関連付けられたシリアライザとメタデータを有する。コンピュータ化された方法は、ユーザによって定義されたワークフローに対応する複数のアクティビティを受け取ることを含む。この方法は、複数のシリアライザを識別することも含む。識別された複数のシリアライザそれぞれには、受け取られた複数のアクティビティの少なくとも１つが関連付けられている。この方法は、識別された複数のシリアライザを実行して、複数のアクティビティのメタデータをワークフローの宣言表現に移すことも含む。メタデータは、複数のアクティビティそれぞれに関連付けられた機能を定義する。
【００１７】
本発明の別の態様によれば、１つまたは複数のコンピュータ可読媒体が、宣言ファイルを作成およびコンパイルするコンピュータ実行可能コンポーネントを有する。宣言ファイルは、複数のアクティビティを含む。複数のアクティビティは、ユーザによって定義されたワークフローを作成するように配置される。複数のアクティビティはそれぞれ、関連付けられたシリアライザとメタデータを有する。上記のコンポーネントには、ユーザによって定義されたワークフローに対応する複数のアクティビティを受け取るインターフェースコンポーネントが含まれる。コンポーネントには、複数のシリアライザを識別するメタデータコンポーネントも含まれる。識別された複数のシリアライザはそれぞれ、インターフェースコンポーネントによって受け取られる複数のアクティビティの少なくとも１つに関連付けられている。コンポーネントには、メタデータコンポーネントによって識別された複数のシリアライザを実行して、複数のアクティビティのメタデータをワークフローの宣言型表現に移す直列化コンポーネントも含まれる。メタデータは、複数のアクティビティそれぞれに関連付けられた機能を定義する。
【００１８】
本発明のさらに別の態様によれば、システムが、複数のアクティビティを含む宣言ファイルを作成し、コンパイルする。このシステムは、複数のアクティビティを記憶するメモリ領域を含む。複数のアクティビティは、ユーザによって定義されたワークフローを作成するように配置される。メモリ領域は、さらに、複数のアクティビティそれぞれのシリアライザとメタデータを記憶する。メタデータは、複数のアクティビティそれぞれに関連付けられた機能を定義する。このシステムは、メモリ領域から複数のアクティビティを取り出すコンピュータ実行可能命令を実行するように構成されたプロセッサも含む。複数のアクティビティは、ユーザによって定義されたワークフローに対応する。プロセッサはさらに、メモリ領域の複数のシリアライザを識別するコンピュータ実行命令を実行するように構成される。識別された複数のシリアライザはそれぞれ、受け取られた複数のアクティビティの少なくとも１つに関連付けられている。プロセッサはさらに、識別された複数のシリアライザを実行して、複数のアクティビティのメタデータをメモリ領域からワークフローの宣言型表現に移すコンピュータ実行可能命令を実行するように構成される。
【００１９】
あるいは、本発明は、各種の他の方法および装置を備えることができる。
【００２０】
その他の特徴の一部は自ずと明らかになり、一部は下記で指摘される。
【００２１】
付録Ａは、例示的アクティビティを記載する。
【００２２】
付録Ｂは、拡張可能オーケストレーションマークアップ言語（ＸＯＭＬ）の例示的実装を記載する。
【００２３】
付録Ｃは、ワークフローおよびワークフローファイルを直列化および非直列化（ｄｅｓｅｒｉａｌｉｚｅ）するアプリケーションプログラミングインターフェースを記載する。
【００２４】
コンピュータプログラム一覧の付録は、本発明によるソフトウェアプログラムの一実施形態の例示的な一覧である。上記のように、この一覧は、ＣＤ−ＲＯＭで本願に含められる。
【００２５】
すべての図面を通じて対応する参照符号は対応する部分を指す。
【発明を実施するための最良の形態】
【００２６】
本発明の実施形態は、業務プロセスなどのプロセスを表すワークフローをモデリングする。業務プロセスとは、予測および反復することが可能な結果をもたらす、順序付けられた独立した作業、活動などである。組織の運営手順、組織内の実際的な知識、および情報源を含む業務プロセスは、効率的でタイムリーな方式で、定められた業務目標を満たすように設計される。効率的な環境では、プロセスの機能コンポーネントは、常に変化する企業の要件に対応するように、容易に識別、適合、および配置されることができる。ワークフローは、業務プロセス中のタスクと対話するエンドユーザの体験である。タスクは、それぞれが人または機械によって行われる作業単位に相当するアクティビティ、コンポーネントなどとしてモデリングされる。一実施形態では、複数のアクティビティがユーザに提示される。ユーザは、ワークフローを作成するためのアクティビティを選択し、編成する。作成されたワークフローが実行されて業務プロセスをモデリングする。図１を参照すると、例示的なワークフロー１００は、タスクと、制御フロー複合アクティビティとを含む。
【００２７】
一例では、オーケストレーションエンジンワークフローモデルが、様々なクラスのワークフローのモデリング、作成、および実行をサポートする。その例には、順番に行われる、または非同期のイベントのセットとして行われる、構造化されたステップのセットとして所与の問題をモデリングすることが含まれる。オーケストレーションエンジンは、スケジュールの実行を調整する。スケジュールは、ツリー構造として階層的に配置された、編成されたアクティビティの集合である。実行中のアクティビティの実行コンテクストと、そのアクティビティに見える共有データが、スコープによって提供される。各アクティビティは、ワークフロープロセスのステップのメタデータをカプセル化するコンポーネントに相当する。アクティビティは、ワークフローモデルにおける実行の基本単位であり、関連付けられたプロパティ、ハンドラ、制約、およびイベントを有する。各アクティビティは、任意のプログラミング言語のユーザコードで構成されることができる。ユーザコードは、例えば、共通言語ランタイム（ＣＬＲ）言語で書かれた業務ロジックまたはアプリケーションロジックまたは規則を表すことができる。各アクティビティは、ユーザコードでの実行へのインターセプト前のフックとインターセプト後のフックをサポートする。各アクティビティには、実行時の実行セマンティックと挙動（状態管理、トランザクション、イベント処理、例外処理など）が関連付けられる。アクティビティは、他のアクティビティと状態を共有することができる。アクティビティは、プリミティブアクティビティとしても、１つの複合アクティビティにまとめてもよい。プリミティブあるいは基本アクティビティは、下位構造（例えば子アクティビティ）を持たず、したがってツリー構造では葉ノードになる。複合アクティビティは、下位構造を含む（例えば１つまたは複数の子アクティビティの親になる）。
【００２８】
一実施形態では、アクティビティは、単純アクティビティ、コンテナアクティビティ、およびルートアクティビティの３タイプである。この実施形態では、モデル中には１つのルートアクティビティがあり、ルートアクティビティの中には、単純アクティビティあるいはコンテナアクティビティはまったくない。コンテナアクティビティは、単純アクティビティまたはコンテナアクティビティを含むことができる。ワークフロープロセス全体を１つのアクティビティとして使用して、高位のワークフロープロセスを構築することができる。さらに、アクティビティは、割り込み可能（ｉｎｔｅｒｒｕｐｔｉｂｌｅ）である場合も、割り込み不可能（ｎｏｎ−ｉｎｔｅｒｒｕｐｔｉｂｌｅ）である場合もある。割り込み不可能な複合アクティビティは、割り込み可能のアクティビティを含まない。割り込みが不可能なアクティビティは、そのアクティビティに妨害を起こさせる可能性があるサービスを持たない。
【００２９】
オーケストレーションエンジンは、例示的なアクティビティのセットを提供する。図２を参照すると、アクティビティの継承ツリーで、例示的なアクティビティを示す。図２に列記される例示的なアクティビティは、付録Ａにより詳細に記載される。また、どのユーザでも、１つまたは複数のアクティビティを書いてワークフローモデルを拡張することができる。例えば、ユーザは、特定の業務問題、領域、ワークフロー標準（業務プロセス実行言語など）、またはターゲットプラットフォームについてのアクティビティを書くことができる。オーケストレーションエンジンは、例えば、コード分析のサービス、タイプ解決およびタイプシステム、直列化のためのサービス、レンダリングなど、アクティビティを書くための豊富なサービスのセットをユーザに提供することができる。
【００３０】
一実施形態では、各アクティビティは、メタデータ、インスタンスデータ、および実行ロジック、の少なくとも３つの部分を有する。アクティビティのメタデータは、設定されることが可能なデータプロパティを定義する。例えば、一部のアクティビティは、アクティビティの抽象基本クラスで定義される共通のメタデータセットを共有することができる。各アクティビティは、そのクラスを拡張することにより、各自アクティビティの必要性に応じて独自の追加的なメタデータプロパティを宣言する。
【００３１】
メタデータプロパティの値は、そのアクティビティが設定されたスケジュールのインスタンスにまたがって、そのアクティビティのすべてのインスタンスに共有される。例えば、ユーザがスケジュールＡを作成し、そのスケジュールに送信アクティビティを追加した場合、送信アクティビティには、メタデータの一部として識別情報（「００１」など）が与えられる。スケジュールに追加される第２の送信アクティビティは、独自の一意の識別情報（「００２」など）を受け取ることになる。スケジュールＡの複数のインスタンスが作成され、実行されると、送信「００１」のすべてのインスタンスは、メタデータ値を共有する。これに対し、アクティビティのインスタンスデータは、実行されるスケジュールインスタンス中にそのアクティビティのインスタンスに固有のデータのセットを定義する。例えば、遅延のアクティビティは、遅延アクティビティの時限値を表す日付と時刻の値である読み取り専用プロパティを自身のインスタンスデータに提供することができる。この値は、遅延アクティビティが実行を開始すると利用できるようになり、多くの場合は遅延アクティビティのすべての単一のインスタンスについて異なる値となる。参照を「インスタンス」で修飾（ｑｕａｌｉｆｙ）せずに、スケジュールのインスタンス、特にアクティビティとタスクのインスタンスを参照するのが一般的である。
【００３２】
複合アクティビティは、自身の子アクティビティのセットを別の要素として有する。一実施形態では、子アクティビティは、メタデータとみなされる。オーケストレーションエンジンモデルは、実行時にスケジュールのインスタンス中でこのメタデータを操作することを明示的に許可する。実行されているスケジュールインスタンスの一部である複合アクティビティに新しい子アクティビティを追加して、そのスケジュールインスタンスのメタデータ（アクティビティツリー）だけが影響されるようにすることができる。
【００３３】
次いで図３を参照すると、各アクティビティには、そのアクティビティのコンポーネントモデルを形成するコンポーネントのセットが関連付けられる。関連付けられるコンポーネントのセットには、アクティビティエクゼキュータ、アクティビティデザイナ、アクティビティシリアライザ、アクティビティバリデータ（例えばセマンティックチェッカ）、およびアクティビティコードジェネレータが含まれる。アクティビティエクゼキュータは、そのアクティビティの実行のセマンティックを実装するステートレスコンポーネントである。アクティビティエクゼキュータは、アクティビティのメタデータとともに機能してアクティビティを実施する。コアスケジューラは、アクティビティエクゼキュータのためのサービスプロバイダとして機能してアクティビティエクゼキュータにサービスを提供する。
【００３４】
アクティビティデザイナは、設計時のアクティビティの視覚的表現を視覚的に表示する。アクティビティデザイナは、デザイナ階層内のノードであり、テーマまたはスキンが用いられてよい。アクティビティデザイナは、設計環境（例えばアプリケーションプログラム）でホストされ、サービスを介してホスト設計環境と対話する。アクティビティバリデータは、コンパイル時と実行時にアクティビティセマンティックを強制する。アクティビティバリデータは、ワークフローモデルのコンテクストに作用し、環境から提供されるサービス（コンパイラ、デザイナ、ランタイムなど）を使用する。妥当性検査は、ワークフローのライフサイクルの様々な時点で行われる。ワークフローの直列化表現を作成する際、コンパイルの際、そしてユーザの要求に応答して、構造的な準拠の確認が行われる。セマンティックの確認は、実行中のインスタンスのアクティビティツリー内でのアクティビティの追加または置換などの実行時操作の安全性を保証するために、コンパイル時よりも実行時により強くすることができる。本発明は、例えばあらかじめ定義されたインターフェース要件に準拠または遵守しているかどうか、各アクティビティに関連付けられたセマンティックを評価する。
【００３５】
アクティビティシリアライザは、アクティビティのメタデータを直列化するコンポーネントである。アクティビティシリアライザは、各種のモデル／フォーマットシリアライザから呼び出される。ワークフローモデル全体が拡張可能なスキーマに基づいて宣言型のマークアップ言語に直列化され、必要に応じてその言語がさらに他のワークフロー言語に変換されることができる。
【００３６】
一実施形態では、アクティビティのコンポーネントモデルは、データ構造としてコンピュータ可読媒体に記憶される。このデータ構造中で、アクティビティデザイナは、アクティビティを視覚的に表現するデータ（アイコンなど）を記憶する画像フィールドで表される。また、１つまたは複数の作成時フィールドが、アクティビティに関連付けられたプロパティ、メソッド、およびイベントを定義するメタデータを記憶する。アクティビティシリアライザは、作成時フィールドに記憶されたメタデータをアクティビティの宣言型の表現に変換するデータを記憶するシリアライザフィールドによって表される。アクティビティジェネレータは、作成時フィールドに記憶されたメタデータに関連付けられたソフトウェアコードを記憶する業務ロジックフィールドで表される。アクティビティエクゼキュータは、業務ロジックフィールドに記憶されたソフトウェアコードを実行するためのデータを記憶するエクゼキュータフィールドによって表される。
【００３７】
スコープおよびスケジュール
実行中のアクティビティの実行コンテクストと、そのアクティビティに見える共有データは、スコープによって提供される。スコープは、コアアクティビティの１つである。スコープは、長期実行サービスの変数と状態を、トランザクションのセマンティック、エラー処理のセマンティック、補償、イベントハンドラ、データ状態管理とまとめる統合コンストラクトである。スコープは、関連付けられた例外ハンドラとイベントハンドラを有することができる。一実施形態では、スコープは、トランザクション単位、アトミック、長期実行、または同期にすることができる。ユーザ変数への矛盾する読み取り−書き込みのアクセスまたは書き込み−読み取りのアクセスの場合には、並行処理制御がユーザに提供される。スコープは、トランザクションの境界、例外処理の境界、および補償の境界でもある。スコープはスケジュールの中に入れ子にすることができるので、（スコープが入れ子になっている場合でも）名前の衝突を生じずに異なるスコープで同じ名前の変数、メッセージ、チャネル、および相関のセットを宣言することがさらに可能である。
【００３８】
スケジュールの中に入れ子になったスコープは、そのスケジュールのコンテクストでのみ実行することができる。スケジュールは、アプリケーション（例えば独立した実行可能エンティティ）としてコンパイルされても、ライブラリ（例えば他のスケジュールから呼び出される）としてコンパイルされてもよい。ライブラリとしてコンパイルされるすべてのスケジュールは、他のスケジュールの中から呼び出されることが可能な新しいアクティビティタイプを有効に構成する。スケジュールのメタデータは、パラメータの宣言を含む。
【００３９】
スケジュールが開発されると、開発されたスケジュールのインスタンスが実行されることができる。スケジュールインスタンスを起動し、制御するプロセスは、オーケストレーションエンジンが埋め込まれたホスト環境の機能である。オーケストレーションエンジンは、スケジュールをテストするために使用することができる最低限の機能を備えた「単純なホスト」を提供する。また、オーケストレーションエンジンは、サービス環境（つまりホスト）と対話するためにエンジンと外部アプリケーションの双方によって使用される「サービスプロバイダ」モデル（例えばアプリケーションプログラミングインターフェース）の標準化を促進するアクティベーションサービスを提供する。このアクティベーションサービスは、特定のスケジュールタイプのスケジュールインスタンスを作成し、必要に応じてパラメータを渡す。スケジュールインスタンスは、基本的に、実行中のスケジュールインスタンスのプロキシであり、そのインスタンスを一意に識別する識別子、そのスケジュールのメタデータ（アクティビティツリー）への参照、およびそのインスタンスを一時停止、再開、および終了させるメソッドを含む。アクティベーションサービスは、所与のスケジュールインスタンス識別子に基づいてスケジュールインスタンスを見つけることもサポートする。
【００４０】
Ｃｏｄｅ−Ｂｅｓｉｄｅ
スコープアクティビティは、そのスコープアクティビティの業務ロジックを含む、関連付けられたｃｏｄｅ−ｂｅｓｉｄｅクラスを有することができる。スケジュールはそれ自体スコープなので、スケジュールもｃｏｄｅ−ｂｅｓｉｄｅクラスを有することができる。スケジュールの中に入れ子になったいずれのスコープも、独自のｃｏｄｅ−ｂｅｓｉｄｅクラスを有することができる。スコープの中に入れ子になったアクティビティは、それらのアクティビティに共有されるデータ状態と業務ロジックのコンテナとして機能するそのスコープのｃｏｄｅ−ｂｅｓｉｄｅクラスを共有する。例えば、コードアクティビティのメタデータは、ｃｏｄｅ−ｂｅｓｉｄｅ中の特定の署名を有するメソッドへの参照を含む。別の例では、送信アクティビティのメタデータは、特定の署名のｃｏｄｅ−ｂｅｓｉｄｅメソッドへの任意の参照と、メッセージ宣言およびチャネル宣言への必須の参照を含む。
【００４１】
ｃｏｄｅ−ｂｅｓｉｄｅの使用例には以下が含まれる。変数、メッセージ、チャネル、相関セットの宣言、ｉｎ／ｏｕｔ／ｒｅｆパラメータの宣言、追加的なカスタムプロパティの宣言、送信されるメッセージの作成、受け取られたメッセージの処理、ブール値を返すコードで表された規則の実施、ローカル定義変数の操作、アクティビティのメタデータおよびインスタンスデータの読み出し、アクティビティのインスタンスデータの書き込み（実行しようとするアクティビティのプロパティの設定など）、イベントの発生、例外の投入、入れ子になったスコープとスケジュール呼び出しの境界を越える列挙と移動を含む、実行中のスケジュールインスタンスのアクティビティツリー中のアクティビティ階層の列挙と移動、実行中のスケジュールインスタンスの複合アクティビティへの新しいアクティビティの追加、実行中のスケジュールインスタンスでアクティビティに関連付けられた宣言型の規則の変更、および、他の実行中のスケジュールインスタンスへの参照の獲得と、そのインスタンスの操作。
【００４２】
図４を参照すると、ブロック図で例示的なコンポーネントモデルのライフサイクルを示す。ユーザは、１つまたは複数のコンピュータ可読媒体に記憶されたコンピュータ実行可能コンポーネントと対話する。コンピュータ実行可能コンポーネントには、インターフェースコンポーネント４０２、メタデータコンポーネント４０４、直列化コンポーネント４０６、および妥当性検査コンポーネント４０８が含まれる。インターフェースコンポーネント４０２は、ユーザによって定義されたワークフローに対応する複数のアクティビティを受け取る。メタデータコンポーネント４０４は、それぞれがインターフェースコンポーネント４０２によって受け取られる複数のアクティビティの少なくとも１つに関連付けられた複数のシリアライザを識別する。直列化コンポーネント４０６は、メタデータコンポーネント４０４によって識別された複数のシリアライザを実行して、複数のアクティビティのメタデータを、ワークフローの宣言型の表現に移す。妥当性検査コンポーネント４０８は、妥当性検査のために、移されたメタデータを拡張可能なスキーマ定義の名前空間にマッピングする。
【００４３】
一例では、ワークフローの宣言型の表現（ファイルなど）は、そのワークフローの識別情報を含むマニフェストを記憶するデータ構造を含む。例示的な識別情報には、名前、バージョン、記述、ファイルに関連付けられた識別、の１つまたは複数が含まれる。ファイルは、各アクティビティに関連付けられたプロパティ（ＣＬＲタイプなど）、メソッド、イベントのリストとともに、ワークフローに関連付けられた複数のアクティビティのリストも含む。
【００４４】
ワークフローステンシル
ワークフローステンシル（例えばワークフローのテンプレートあるいはアクティビティパッケージ）は、ルートアクティビティとアクティビティのセットを含む。ステンシルは、領域固有かつ／またはホスト固有とすることができる。前者の例には、構造化されたワークフローステンシル、人間によるワークフローステンシル、および非構造化ワークフローステンシルが含まれる。一部のステンシルは、可能性としては特定のホスト環境でともに機能するように設計された１つまたは複数のルートを含むアクティビティのセットとして「クローズ」にすることができる。他のステンシルは、様々な程度に「オープン」にすることができる。ステンシルは、自身の拡張性の限界を定義する。例えば、開発者は、ＣｕｓｔｏｍＲｏｏｔと新しい抽象的なＣｕｓｔｏｍＡｃｔｉｖｉｔｙを書き、ＣｕｓｔｏｍＲｏｏｔに、ＣｕｓｔｏｍＡｃｔｉｖｉｔｙから派生するアクティビティを加えたものをパッケージとすると宣言する。
【００４５】
例示的なＢＰＥＬまたはＸＬＡＮＧ／Ｓのステンシルは、次の特性を有するルートアクティビティを含む：状態管理およびトランザクションに関与する、関連付けられたイベントハンドラおよび例外ハンドラを有する、コントラクト第１のモデルをサポートする、分析されることが可能、明確な呼び出しおよび終了の挙動を有する。例示的なステンシルはさらに、メッセージングに固有のアクティビティ（送信、受信、およびその変種など）のセットと、スコープ、ループ、条件、リスン、投入などの構造化された他のアクティビティを含む。
【００４６】
例示的なＨａｌｉｆａｘステンシルは、暗示的な状態管理、関連付けられた例外ハンドラ（０〜ｎ）、イベントに基づくモデルをサポートする、明確な起動の挙動を有する、終了が未定義、という特性を有するルートアクティビティを含む。このルートアクティビティは、０〜ｎのＥｖｅｎｔＤｒｉｖｅｎアクティビティを含む。各ＥｖｅｎｔＤｒｉｖｅｎアクティビティは、Ｈａｌｉｆａｘ  Ａｃｔｉｏｎを表す。各ＥｖｅｎｔＤｒｉｖｅｎアクティビティは、関連付けられた状態管理プロトコルを有し、アトミックなスコープで実行される。
【００４７】
デザイナフレームワーク（ユーザインターフェース）
オーケストレーションエンジンは、ＷＹＳＷＹＧ方式で様々なクラスのワークフローモデルを設計するためのフレームワークを提供する。例えば、図５を参照すると、ワークフローを作成するための高水準のアプリケーションユーザインターフェースは、ワークフローを指定するウィザードに依拠する。このフレームワークは、開発者が視覚的なワークフローデザイナを書くことを可能にするサービスと挙動のセットを含む。これらのサービスは、ワークフロープロセスをレンダリングする効率的な方式と、フローを描画するためのインク／タブレットのサポートと、取り消し／やり直し、ドラッグ／ドロップ、カット／コピー／ペースト、ズーム、パン、検索／置換、ブックマーク、装飾、妥当性検査エラーのためのスマートタグ、アクティビティの有効ドロップターゲットのインジケータ、自動レイアウト、ビューのページ番号付け、ナビゲーションマーカ、ドラッグインジケータ、ヘッダ／フッタを含む印刷とプレビューなどのデザイナ動作のサポートを提供する。このようなユーザインターフェースを通じて、タスクと制御フロー複合アクティビティ（順次（ｓｅｑｕｅｎｃｅ）、並行（ｐａｒａｌｌｅｌ）、条件文（ｃｏｎｄｉｔｉｏｎａｌ）など）とを含む単純なワークフローを構築することができる。規則の指定（条件付き分岐論理（ｃｏｎｄｉｔｉｏｎａｌ  ｂｒａｎｃｈｉｎｇ  ｌｏｇｉｃ）、ｗｈｉｌｅループ論理など）にも、データフローの指定（タスクＡの出力がタスクＢへの入力となるなど）にも、コードの入力（あるいは既存のコンパイル済みコードへの依拠）は必要とされない。スケジュール（規則とデータフローを含む）の直列化された表現は、ｃｏｄｅ−ｂｅｓｉｄｅが必要とされない一部のシナリオでは自己完結型で、完結している。
【００４８】
本発明のデザイナフレームワークを使用すると、本発明のオーケストレーションエンジンは、ソフトウェアコードを視覚的な方式でワークフローモデルに関連付けることをサポートする、ラピッドアプリケーション開発（ＲＡＤ）型の視覚的ワークフローデザイナを含む。ワークフロー中の各アクティビティには、アクティビティデザイナが関連付けられる。各アクティビティデザイナは、フレームワークサービスの点から書かれる。本発明のフレームワークは、視覚的デザイナモデルも含む。視覚的デザイナモデルは、ワークフローモデル中に記述される関係を介して相互と結び付けられたアクティビティデザイナのセットを含む。図６に、例示的なワークフローデザイナを示す。本発明は、ワークフローモデルにコードを関連付ける様々な方式を含み、これには、「ｃｏｄｅ−ｂｅｓｉｄｅ」、「ｃｏｄｅ−ｗｉｔｈｉｎ」、および、リアルタイムでワークフローモデルとユーザコードを往復（ｒｏｕｎｄ−ｔｒｉｐｐｉｎｇ）することを可能にする「ｃｏｄｅ−ｏｎｌｙ」が含まれる。本発明は、ユーザがワークフローを構築する際のリアルタイムのセマンティックエラーも提供する。
【００４９】
一実施形態では、本発明は、デザイナフレームワークユーザインターフェースで複数のアクティビティを識別するパッケージをユーザに提示する。本発明はさらに、ユーザから、提示されたアクティビティの選択と階層的な編成を受け取る。本発明は、受け取ったアクティビティを直列化して、ワークフローの永続的な表現を作成する。本発明はさらに、ユーザから、ワークフローの複数のアクティビティの１つに関連付ける業務ロジックを表すソフトウェアコードを受け取る。本発明は、１つまたは複数のセマンティックが関連付けられた、ユーザ定義のアクティビティも受け取ることができる。本発明は、所定のインターフェース要件に準拠しているかどうかセマンティックを評価するセマンティックチェッカあるいはバリデータを含む。セマンティックが所定のインターフェース要件に準拠している場合、本発明は、ユーザによって定義されたアクティビティを複数のアクティビティの１つとして提示する。本発明はさらに、ソフトウェアコードをコンパイルして１つまたは複数のバイナリファイルを作成する。例えば、本発明は、直列化されたワークフロー表現とソフトウェアコードをコンパイルしてワークフローの実行可能表現を含む単一のアセンブリにする。本発明は、作成されたワークフローを実行する。一実施形態では、１つまたは複数のコンピュータ可読媒体が、この方法を行うコンピュータ実行可能命令を有する。
【００５０】
オーケストレーションエンジンデザイナは、ユーザが、作成された他のスケジュールを使用することにより、高位のスケジュールを反復的に作成し、そのスケジュールを使用できるようにする。スケジュールのインライン展開により、ユーザは、スケジュールの内容をインラインで見、その内容をカットまたはコピーすることができる。スケジュールのインライン展開を可能にし、スケジュールを読み取り専用にするために、インラインスケジュールのための別個の設計面とデザイナホストが作成される。さらに、複合スケジュールデザイナは、独自の階層を有する。呼び出されたスケジュールは、デザイナがユーザによって拡大されたときにロードされ、表示される。一実施形態では、デザイナは、アクティビティが設計面でドロップまたはコピーされると折りたたまれる。プロパティが、呼び出し元のアクティビティデザイナを、ホストされるスケジュールのルートデザイナにつなぐ。次の関数は、デザイナへのアクティビティの追加とデザイナからのアクティビティの除去を阻止する。
【００５１】
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)
一例では、ユーザがスケジュールを作成し、そのスケジュールをアクティビティとしてコンパイルする。コンパイルが成功すると、そのスケジュールは、ツールボックスに表示される。ユーザは、コンパイルされたスケジュールの使用が要求されるスケジュールを開くか、または作成する。ユーザは、ツールボックスからコンパイルされたスケジュールをドラッグし、ドロップする。閉じられていたスケジュールデザイナが設計面に表示される。ユーザが、ドロップされたコンパイル済みスケジュールの内容を見たい場合、ユーザは、スケジュールデザイナを拡大して、呼び出されたスケジュールの内容を読み取り専用の状態でインライン表示する。呼び出されるスケジュールをインラインにすることにより、ユーザは、異なるスケジュールデザイナの間で切り替えをせずに、呼び出したスケジュールを見ることができる。この機能は、既存のスケジュールを再使用することにより高位のスケジュールを作成する開発者に有用である。
【００５３】
テーマ／スキンを使用したデザイナフレームワークのカスタマイズのサポート
デザイナフレームワークを使用して書かれたワークフローデザイナは、ワークフローテーマを使用してカスタマイズすることができる。これらは、デザイナの各種側面を宣言的に記述する拡張可能マークアップ言語（ＸＭＬ）ファイルとすることができる。ワークフローデザイナは、提携者がアクティビティを拡張するためのウィザードサポートを提供する。ワークフローデザイナでサポートされる例示的なユーザインターフェース機能には、これらに限定しないが、取り消し／やり直し、ドラッグ／ドロップ、カット／コピー／ペースト、ズーム、パン、検索／置換、ブックマーク、装飾、妥当性検査エラーのためのスマートタグ、アクティビティのための有効ドロップターゲットインジケータ、自動レイアウト、ビューのページ番号付け、ナビゲーションマーカ、ドラッグインジケータ、ヘッダ／フッタを入れた印刷およびプレビュー、文書のアウトラインの統合が含まれる。ワークフローデザイナは、ＸＭＬメタデータを使用したデザイナのルックアンドフィールのカスタマイズを可能にするカスタムデザイナテーマ／スキンをサポートする。ワークフローデザイナは、バックグラウンドコンパイルをサポートする。一例では、スケジュールを設計している際の妥当性検査エラーのためのスマートタグとスマートアクションが提供される。ワークフローデザイナは、任意のコンテナ（アプリケーションプログラム、シェルなど）の中でホストされることができる。
【００５４】
例示的なオーケストレーションエンジンプログラムは、受信アクティビティおよびその後に続く送信アクティビティを含む。基本的に、プロセスは、メッセージを受け取り、そのメッセージを送り出す。ユーザは、「Ｈｅｌｌｏ  Ｗｏｒｌｄ」と呼ばれるプロジェクトを作成し、そのプロジェクトにオーケストレーション項目を追加する。次いで、ユーザは、スコープアクティビティをドラッグし、設計面にドロップする。次いで、ユーザは、受信アクティビティ、続いて送信アクティビティをスコープにドロップする。図７に、その結果得られるデザイナ中のワークフロー７００を示す。各アクティビティデザイナは、オブジェクトモデルについてのユーザインターフェース表現を提供する。開発者は、そのオブジェクトモデルを直接プログラムし、アクティビティのプロパティを設定するか、またはデザイナを使用することができる。オーケストレーションエンジンデザイナでは、開発者は、ツールボックスからアクティビティを選択し、そのアクティビティを設計面にドラッグすることができる。アクティビティがすでにスケジュールの中に置かれており、移動する必要がある場合、開発者は、（クリックすることにより）そのアクティビティを選択し、アクティビティを移動する必要があるスケジュールの領域内にドラッグすることができる。開発者がコントロールキーを押しながらドラッグ・アンド・ドロップすると、選択されたアクティビティのコピーが行われる。
【００５５】
アクティブな置換は、設計面に視覚的なインジケータとして可能なドロップ点（ターゲット）を提供する。ドラッグ・アンド・ドロップに関しては、自動的なスクロールも関連する。大きなスケジュールを扱う場合、現在ビューポートにないデザイナ範囲への移動は、アクティビティを、配置するスケジュール範囲の方にドラッグすることによりアクセスすることができる。
【００５６】
ドラッグ・アンド・ドロップは、同じプロジェクト中のスケジュールにまたがって、また、同じソリューション中の他のプロジェクトのスケジュールにまたがってサポートされる。設計面にアクティビティを配置した後、開発者は、そのアクティビティを構成する。各アクティビティは、スケジュールを有効にするために開発者が設定するプロパティのセットを有する。このプロパティは、プロパティブラウザで編集することができる。すべてのアクティビティは、プロパティブラウザで閲覧することができるプロパティをコントロールする。開発者が各種アクティビティを設定するのを支援するために、デザイナは、各種のダイアログあるいは「サブデザイナ」を提供する。各ダイアログは、アクティビティの各種プロパティに対して呼び出される。
【００５７】
オーケストレーションエンジンは、ツールボックスに提示されるアクティビティをカスタマイズすることができる。開発者がカスタムのアクティビティまたはスケジュールを作成すると、その最終的な結果は、アセンブリになる。開発者は、ダイアログを使用して、アセンブリ位置にブラウズし、アセンブリを選択してそのアセンブリがオーケストレーションエンジンアクティビティとして表示されるようにすることができる。あるいは、開発者は、オーケストレーションエンジンのインストールパスにアセンブリを配置することもでき、そのアセンブリもオーケストレーションエンジンアクティビティとして存在するようになる。
【００５８】
アプリケーションプログラミングインターフェース（ＡＰＩ）
別の実施形態では、本発明は、各種のワークフロー操作を行うためのアプリケーションプログラミングインターフェース（ＡＰＩ）を提供する。本発明は、ワークフローを作成するための設計アプリケーションプログラミングインターフェースを含む。設計アプリケーションプログラミングインターフェースは、ワークフローを作成する手段と、ワークフローを作成するために１つまたは複数のアクティビティを選択する手段とを備える。本発明は、設計アプリケーションプログラミングインターフェースを介して作成されたワークフローをコンパイルするコンパイルアプリケーションプログラミングインターフェースも含む。コンパイルアプリケーションプログラミングインターフェースは、ワークフローを直列化する手段、ワークフローの視覚的外観をカスタマイズする手段、設計アプリケーションプログラミングインターフェースを介して作成されたワークフローをコンパイルする手段、ワークフローの妥当性検査を行う手段を備える。
【００５９】
本発明は、ワークフローの各アクティビティにタイプを関連付ける、タイププロバイダアプリケーションプログラミングインターフェースも含む。タイププロバイダアプリケーションプログラミングインターフェースは、ワークフローの各アクティビティにタイプを関連付ける手段と、ワークフローの各アクティビティにタイプを関連付ける手段とを備える。
【００６０】
ハードウェア、ソフトウェア、および１つまたは複数のアプリケーションプログラミングインターフェース（ＡＰＩ）が、ワークフローを作成する例示的手段、ワークフローを作成するために１つまたは複数のアクティビティを選択する例示的手段、ワークフローを直列化する例示的手段、ワークフローの視覚的外観をカスタマイズする例示的手段、ワークフローを妥当性検査する例示的手段、ワークフローをコンパイルする例示的手段、ワークフローの各アクティビティにタイプを関連付ける例示的手段を構成する。
【００６１】
アクティビティ実行フレームワーク
スケジュールとスコープを除いて、エンジンは、アクティビティを抽象的エンティティとみなし、特定アクティビティの固有のデータあるいはセマンティックを知ることなく、単にアクティビティの実行を調整する。一実施形態では、アクティビティ自体、実行されるアクティビティの親アクティビティ、実行されるアクティビティを包含するスコープ、およびオーケストレーションエンジン、の４つのエンティティがアクティビティの実行中に対話する。各エンティティは、異なる機能を有する。
【００６２】
完了をそのアクティビティコーディネータに通知することなくアクティビティの実行メソッドが返された場合、そのアクティビティは、論理的な待機状態にあると言う。そのようなアクティビティは、（例えばそれが待機している項目またはイベントが利用可能になるか、発生し、そのことがエンジンによりアクティビティに通知されると）オーケストレーションエンジンによってキャンセルされるか、継続することができる。
【００６３】
論理的待機状態に入ることがない一部のアクティビティは、決してキャンセルされることができない。その例には、送信アクティビティとコードアクティビティが含まれる。これは、これらのアクティビティが、外部のイベントまたはサブスクリプションを必要とせずに実行されるためである。スレッドが渡される（すなわち各自の実行メソッドがオーケストレーションエンジンによって呼び出される）と、それらのアクティビティは、完了するまで動作する。それらのアクティビティは完了を通知するまでスレッドを返さないので、オーケストレーションエンジンには、それらをキャンセルする機会は決して与えられない。
【００６４】
オーケストレーションエンジンランタイムは、規則を使用してオーケストレーションエンジンのアクティビティが実行されるイベントをトリガする。オーケストレーションエンジンデザイナは、関連付けられた規則を実行時に評価してイベントをトリガするユーザ能力を提供する。オーケストレーションエンジンデザイナは、拡張性アーキテクチャを提供することにより、ユーザが様々なタイプの規則技術を使用できるようにする。デザイナは、使用される規則技術のタイプに依存しない。
【００６５】
一実施形態では、デザイナは、アクティビティに規則を関連付ける手段として、ブール式ハンドラをサポートする。これは、ユーザコードファイルに、ユーザが、真または偽の値を返すメソッドを書き、その値に基づいて規則がトリガされることを意味する。現在、Ｉｎｆｏ  ＡｇｅｎｔとＢｕｓｉｎｅｓｓ  Ｒｕｌｅｓ  Ｅｎｇｉｎｅ（ＢＲＥ）を含む、規則を評価するために使用することが可能な技術が複数存在する。これを実現するために、デザイナは、規則技術の開発者がカスタムのユーザインターフェースをデザイナ内にホストできるようにする拡張性アーキテクチャを含む。デザイナは、カスタムユーザインターフェースのライタが、コード文の集まりの形で規則を直列化する手段を提供する。デザイナは、コード文の集まりが挿入された状態のユーザコードファイル中にブールハンドラをエミットする。オーケストレーションエンジンは、これも規則のライタによって使用されることができるデフォルトのユーザインターフェースを含む。規則技術の提供者は、カスタムの規則宣言を作成し、そのカスタムの規則宣言に関連付けられたユーザインターフェースタイプエディタを書き、規則ユーザインターフェースをホストするカスタムのユーザインターフェースを作成し、保存についてのコード文を生成することにより、オーケストレーションエンジンデザイナに規則を追加する。
【００６６】
一例では、ユーザは、規則を付加する必要があるアクティビティデザイナを選択し、プロパティブラウザで規則のプロパティを見つけ、ドロップダウンで「ＲｕｌｅＥｘｐｒｅｓｓｉｏｎＨａｎｄｌｅｒ」を選択し（それにより「ステートメント」プロパティがユーザインターフェースの規則プロパティの下に表示される）、「ステートメント」プロパティでユーザコードメソッドの名前を指定し、ユーザインターフェースタイプエディタを起動して、規則に固有のユーザインターフェースをホストするダイアログを呼び出し、新しい述部行を作成し、その行をまとめてグループ化することによりダイアログ中に新しい規則を定義する。ユーザインターフェースは、ユーザコードファイル中にメソッドを発行する。このメソッドの名前は、プロパティブラウザでユーザによって指定された名前と同じ名前になる。規則を作成するのに相当するコード文が、規則のユーザコードメソッドに挿入される。
【００６７】
実行中のメッセージング
実行中のワークフローでは、スケジュールに送信されるメッセージは、特定のスケジュールインスタンスを対象とする。例えば、購入注文＃１２３の送り状は、その購入注文の発生元である（例えば送信した）スケジュールインスタンスと同じスケジュールインスタンスに送り返されなければならない。受け取るメッセージを該当するスケジュールインスタンスに一致させるために、メッセージとスケジュールインスタンスは、相関セットを共有する。相関セットは、単一の値をとる相関セットでよく、この手段では、メッセージ中の識別子フィールドが、スケジュールインスタンスに保持される同じタイプの識別子と照合される。複数のプロパティを持つ相関セットも可能であり、データベーステーブルにおける複数の列にわたるプライマリキーに似る。
【００６８】
スケジュールインスタンスによって保持される相関セットの値は、そのスケジュールインスタンスがメッセージを送出するとき（例えば送出される購入注文の識別子フィールドから値を得ることができる）か、またはメッセージを受け取るときに初期化される。そして、その相関セット値は、そのスケジュールインスタンスの状態の一部となる。続く入力メッセージが到着すると、スケジュールインスタンスの状態に保持されている相関セット値が、予想されるタイプの入力メッセージに保持される識別子と照合される。一致が見つかると、その相関セットは満たされることになり、メッセージがスケジュールインスタンスに伝達される。
【００６９】
相関セットの実施はオーケストレーションエンジンとホスト環境の機能であるが、一実施形態では、ユーザが相関セットを宣言してスケジュールインスタンスが正しく働くようにする。別の実施形態では、いくつかのアクティビティ（ＳｅｎｄＲｅｑｕｅｓｔ／ＲｅｃｅｉｖｅＲｅｓｐｏｎｓｅアクティビティやＲｅｃｅｉｖｅＲｅｑｕｅｓｔ／ＳｅｎｄＲｅｓｐｏｎｓｅアクティビティ）が、ユーザに依存せずに相関セットを設定する。送信および受信のアクティビティによって幅広い妥当性の確認が行われて、相関セットが初期化されており、正しく準拠されていることを確実にする。
【００７０】
実行中のワークフローの動的な編集
オーケストレーションエンジンは、各種タイプのワークフローを作成（およびその後視覚化し、実行）するためのフレームワークを提供する。その例には、イベント−条件−アクション（ＥＣＡ）型のワークフロー、構造化されたフロー、または規則によって駆動されるフローが含まれる。さらに、このフレームワークは、ワークフローがモデリングされた方式に関係なく、ユーザが、ワークフロープロセスを再コンパイルする必要なしに、設計時に、さらにはワークフロープロセスの実行中に、同じ方式でワークフローを作成あるいは編集することを可能にする。このフレームワークでは、ユーザは、実行時の表現と設計時の表現の間を高い忠実度で往復することができる。随時の変更は、実行時にプロセスモデルに行われる変更である。ユーザは、実行中のインスタンスにそのスケジュールモデルを問い合わせ、そのモデルに変更を加えることができる。例えば、ユーザは、複数のアクティビティを一括して追加、削除、あるいは置換することができ、そして一括した変更を確定またはロールバックすることができる。一実施形態では、更新後にモデルの妥当性が検査される。本発明のワークフローシナリオの多くでは、「設計時の作成」と「実行時の実行」との区別があいまいにされるか、さらには区別がなくされる。
【００７１】
スケジュールインスタンスは、他のインスタンスと、それらのインスタンスのスケジュールタイプに定義されたアクティビティタイプ（メタデータ）のツリーを効果的に共有する。しかし、どのスケジュールインスタンスも、一旦実行を開始すると、新しいアクティビティの追加または宣言型規則の操作を介して実行中に変更することができる。そのような変更されたスケジュールインスタンスを取り込み、新しいスケジュールタイプとして「保存」する、あるいはより一般的には、単にそのインスタンスから直列化された表現を回復することができる。すなわち、実行中のスケジュールインスタンスは、直列化し、次いで任意のデザイナ（例えば作成環境）または実行時視覚化ツールに入れることができる。
【００７２】
さらに、高度な開発者は、スケジュールを完全にソフトウェアコードとして作成することができる。スケジュールタイプを直接作成するには、開発者は、単に、ＩｎｉｔｉａｌｉｚｅＳｃｈｅｄｕｌｅＭｏｄｅｌと称される静的なメソッドをスケジュールのｃｏｄｅ−ｂｅｓｉｄｅクラスのソフトウェアコードに含め、そのメソッドを［ＳｃｈｅｄｕｌｅＣｒｅａｔｏｒ］属性でマークする。一実施形態では、静的なメソッドは、パラメータをとらず、Ｓｃｈｅｄｕｌｅオブジェクトを返す。直列化されたコンパニオンファイルはないが、スケジュールの直列化表現は、作成されたＳｃｈｅｄｕｌｅオブジェクトから回復することができる。これは、１つのソフトウェアコードファイルを使用してスケジュールを開発できることを意味するが、そのファイルには妥当性の確認が行われない可能性がある。オーケストレーションエンジンのコンパイルは、スケジュールタイプの基礎となるアクティビティツリーの構造的および意味的な妥当性を保証する。別の実施形態では、コンパイルと妥当性検査が内部で行われて、実行される実際のタイプを生成するが、コード入力は必要とされない。コンパイル時のオブジェクトモデルから実行時のオブジェクトモデルへの変換がないので、スケジュールタイプのコンパイルは、非常に軽量のプロセスになる。基本的に、コンパイルは、単に、スケジュールのオブジェクトモデル表現とｃｏｄｅ−ｂｅｓｉｄｅを組み合わせて新しいタイプを生成する。一実施形態では、コンパイルされたｃｏｄｅ−ｂｅｓｉｄｅが、そのオブジェクトモデルのアクティビティによって要求されるものと一致する場合、またはｃｏｄｅ−ｂｅｓｉｄｅがコンパイルされた形態（アセンブリ）ですでに存在する可能性がある場合には、特定のスケジュールについてｃｏｄｅ−ｂｅｓｉｄｅを提供する根本的な必要性がない場合がある。
【００７３】
直列化されたスケジュールをコンパイルする際には、そのスケジュールのｃｏｄｅ−ｂｅｓｉｄｅとして有効に機能する既存のコンパイル済みタイプをポイントすることが可能である。そのコンパイル済みタイプの派生が作成され、その新しいタイプがｃｏｄｅ−ｂｅｓｉｄｅとして機能して、新しいスケジュールを表す一意のタイプが作成されることを保証する。
【００７４】
直列化アーキテクチャ
直列化のインフラストラクチャは、オーケストレーションエンジンのアクティビティツリーを直列化するための、モジュール式で、フォーマット中立の容易に拡張できる機構を提供する。図８にオブジェクトの直列化をグラフで示す。一般に、本発明は、宣言型ファイルを作成し、コンパイルする、コンピュータ化された方法を含む。このコンピュータ化された方法は、ユーザによって定義されたワークフローに対応する複数のアクティビティを受け取ることを含む。一実施形態では、本発明は、メモリに記憶されたワークフローにアクセスすることにより、複数のアクティビティを受け取る。本発明は、受け取られた複数のアクティビティの少なくとも１つにそれぞれが関連付けられた複数のシリアライザを識別する。本発明は、識別された複数のシリアライザを実行して、複数のアクティビティそれぞれに関連付けられたメタデータをワークフローの宣言的表現に移す。このメタデータは、複数のアクティビティそれぞれに関連付けられた機能を定義する。例えば、アクティビティの１つに関連付けられたメタデータは、そのアクティビティに関連付けられたプロパティ、メソッド、および／またはイベントを定義する。本発明はまた、ワークフローの宣言型表現をコンパイルして実行ファイルを作成する。本発明はさらに、妥当性検査のために、転送されたメタデータを拡張可能なスキーマ定義の名前空間にマッピングすることができる。一実施形態では、１つまたは複数のコンピュータ可読媒体が、このコンピュータ化された方法を行うコンピュータ実行可能命令を有する。
【００７５】
一実施形態では、コンピュータ化された方法とアプリケーションプログラミングインターフェースは、ユーザによって定義されたワークフローに対応する複数のアクティビティをメモリ領域から取り出す例示的手段と、受け取られた複数のアクティビティの少なくとも１つにそれぞれが関連付けられた複数のシリアライザをメモリ領域から識別する手段と、識別された複数のシリアライザを実行して、複数のアクティビティのメタデータをメモリ領域からワークフローの宣言型表現に転送する手段とを構成する。
【００７６】
詳細には、呼び出し元（例えばアプリケーションプログラムあるいはユーザ）が、直列化マネジャに、オブジェクト（あるいはアクティビティ）Ａのシリアライザを要求する。オブジェクトＡのタイプのメタデータ属性が、オブジェクトＡを、要求されるタイプのシリアライザに結び付ける。次いで、呼び出し元は、オブジェクトＡを直列化するようにシリアライザに要求する。そしてオブジェクトＡのシリアライザは、オブジェクトを直列化する。直列化の際に遭遇する各オブジェクトについて、シリアライザは、直列化マネジャに追加的なシリアライザを要求する。直列化の結果は呼び出し元に返される。
【００７７】
オーケストレーションエンジンコンポーネントモデル中のすべてのアクティビティは、直列化に関与することができる。一実施形態では、シリアライザコンポーネントは、アクティビティクラス自体の一部ではない。代わりに、このコンポーネントは、アクティビティに関連付けられたクラスのシリアライザ属性に注釈をつけることによって指定される。シリアライザ属性は、そのアクティビティタイプのオブジェクトを直列化するために使用されるクラスをポイントする。別の実施形態では、アクティビティタイプのプロバイダコンポーネントが、アクティビティによって提供されるデフォルトのシリアライザを無効にする。
【００７８】
デザイナの直列化は、メタデータ、シリアライザ、および直列化マネジャに基づく。メタデータ属性を使用してタイプとシリアライザを関係付ける。「ブートストラッピング」属性を使用して、シリアライザを持たないタイプにシリアライザを提供するオブジェクトをインストールすることができる。シリアライザは、特定のタイプまたはある範囲のタイプをどのように直列化するかを知っているオブジェクトである。各データフォーマットには、基本クラスがある。例えば、オブジェクトをＸＭＬに変換する方法を知っているＸｍｌＳｅｒｉａｌｉｚｅｒ基本クラスがあることが可能である。本発明は、どの特定の直列化フォーマットにも依存しない一般的なアーキテクチャである。直列化マネジャは、オブジェクトグラフを直列化するために使用される各種のシリアライザすべてに情報ストアを提供するオブジェクトである。例えば、５０個のオブジェクトからなるグラフは、すべてが独自の出力を生成する５０個の異なるシリアライザを有することができる。必要な際には、それらのシリアライザによって直列化マネジャを使用して相互と通信することができる。
【００７９】
一実施形態では、汎用的なオブジェクトのメタデータを使用するシリアライザと結び付けられた直列化プロバイダを使用することにより、所与のタイプのためのシリアライザを提供する機会がオブジェクトに与えられるコールバック機構が得られる。直列化マネジャは、ＡｄｄＳｅｒｉａｌｉｚａｔｉｏｎＰｒｏｖｉｄｅｒなどのメソッドを通じて直列化プロバイダを与えられることができる。直列化プロバイダは、ＤｅｆａｕｌｔＳｅｒｉａｌｉｚａｔｉｏｎＰｒｏｖｉｄｅｒＡｔｔｒｉｂｕｔｅなどの属性をシリアライザに追加することにより、直列化マネジャに自動的に追加されることができる。
【００８０】
一実施形態では、以下の規則によってフォーマットが決定される。すなわち、オブジェクトはｘｍｌ要素として直列化され、オブジェクトのプロパティは、単純なプロパティ（例えばｘｍｌ属性として直列化される）または複雑なプロパティ（子要素として直列化される）に分類され、オブジェクトの子オブジェクトは子要素として直列化される。子オブジェクトの定義は、オブジェクトごとに異なってよい。次に示す例は、Ｓｅｎｄアクティビティを子オブジェクトの１つとして有するｗｈｉｌｅアクティビティの直列化である。
【００８１】
【表１】
2006107474.tif 000003
【００８２】
直列化に使用される言語が拡張可能オーケストレーションマークアップ言語（ＸＯＭＬ）である実施形態では、スケジュールがコンパイルされるときに各ＸＯＭＬ要素がその個々のオブジェクトに直列化される。ＸＯＭＬの例示的な実施を付録Ｂに記載する。ＸＯＭＬオブジェクトは、単純なタイプと複雑なタイプの両方を含む。各アクティビティのＸＯＭＬ表現と、作成オブジェクトモデルへのそのマッピングとの対応付けを次いで説明する。ＸＯＭＬの直列化は、プリミティブアクティビティと複合アクティビティとで異なる。
【００８３】
プリミティブアクティビティの単純タイプは、アクティビティタイプの属性として直列化される。プリミティブアクティビティの複雑タイプは、子要素として直列化される。一例として、ＳｅｎｄアクティビティのＸＯＭＬ表現を示す。
【００８４】
【表２】
2006107474.tif 000004
【００８５】
プリミティブタイプの直列化と同じように、複合アクティビティの単純タイプは、アクティビティタイプの属性として直列化される。しかし、本質的に、複合アクティビティは、入れ子になったアクティビティをカプセル化する。入れ子になった各アクティビティは、別の子要素として直列化される。一例として、ＷｈｉｌｅアクティビティのＸＯＭＬ表現を示す。
【００８６】
【表３】
2006107474.tif 000005
【００８７】
プロセス／ワークフローのビューと、直列化された表現の間には強い関係が存在する。図９に、スケジュール定義、および、視覚的ワークフローとワークフローの直列化（例えばＸＯＭＬ）表現とワークフローのｃｏｄｅ  ｂｅｓｉｄｅとの間の関係を示す。どちらか一方の表現で作成すると、もう一方の表現に変化が生じる。したがって、アクティビティ（あるいは複合アクティビティの場合はその構成部分）についてのＸＯＭＬを変更すると、開発者がプロセス／ワークフロービューとＸＯＭＬ表現とを切り替えたときにプロセス／ワークフローのビューに変更が直接反映される。この逆も当てはまる。プロセス／ワークフロービューの中でアクティビティに変更を加えると、ＸＯＭＬ中でそれに該当する変更が行われる。一例として、プロセス／ワークフロービューでアクティビティを削除すると、同じアクティビティのＸＯＭＬでそのＸＭＬ要素が除去される。プロセス／ワークフロービューとｃｏｄｅ  ｂｅｓｉｄｅの間では往復も行われる。
【００８８】
ＸＯＭＬコードを作成する際に、ＸＯＭＬ定義があらかじめ定義されたインターフェース要件に従わない場合は、違反しているＸＭＬ要素に下線が引かれるか、その他の形で開発者に視覚的に識別される。開発者がプロセスビューに切り替えると、ＸＯＭＬにエラーがあることが通知され、デザイナは、開発者がクリックして違反している要素に移動することができるリンクを提供する。これと同じエラーはタスクペインにも表示され、そのエラーをダブルクリックすると、開発者は、ＸＯＭＬ中の違反要素に導かれる。
【００８９】
ＣＤ−ＲＯＭのコンピュータプログラム一覧付録の注釈をつけた説明
ＣＤ−ＲＯＭのコンピュータプログラム一覧の付録は、本発明によるＸＯＭＬスキーマの一実施形態の例示的な一覧である。このＸＯＭＬスキーマ（ＣＤ−ＲＯＭのコンピュータプログラム一覧付録、１〜７３７行参照）は、例示的なアクティビティセットを定義する。ＣＤ−ＲＯＭでコンピュータプログラム一覧の付録として提供される例示的なコンピュータコードは、本発明で使用する宣言型マークアップ言語の一実施形態に過ぎない。本発明の他の実施形態では、ＣＤ−ＲＯＭのコンピュータプログラム一覧の付録は、異なるコード、異なるソフトウェアコードモジュールで、または完全に統一して書くことができる。
【００９０】
ＸＯＭＬファイルからアクティビティツリーを作成する（非直列化）
本発明は、ワークフローの宣言型表現（例えばＸＯＭＬファイル）からワークフローを非直列化する方法を含む。本発明は、ワークフロー中の各アクティビティについてワークフローの宣言型表現に格納されたメタデータを取り出し、ワークフローの各アクティビティに関連付けられたソフトウェアコードをコンパイルし、取り出されたメタデータとコンパイルされたソフトウェアコードの関数としてワークフローを再作成する方法を含む。
【００９１】
一実施形態では、ＣｒｅａｔｅＥｄｉｔｏｒｌｎｓｔａｎｃｅ（）関数がＤｅｓｉｇｎＳｕｒｆａｃｅオブジェクトを作成し、次いでＢｅｇｉｎＬｏａｄ関数をＤｅｓｉｇｎＳｕｒｆａｃｅオブジェクトに呼び出してその関数に実際のローダオブジェクトを渡し、その結果最終的にはＤｅｓｉｇｎｅｒＬｏａｄｅｒ（）関数にＢｅｇｉｎＬｏａｄ（）が呼び出される。ＰｅｒｆｏｒｍＬｏａｄ（）関数は、テキストバッファオブジェクトを読み出し、そのオブジェクトを非直列化してオーケストレーションエンジンコンポーネントの階層にする。本発明は、その階層をウォークスルーし、設計面にアクティビティを挿入してビジュアルスタジオにコンポーネントをロードする。
【００９２】
本発明はまた、ＸＯＭＬファイルへの変更をリスンして、階層と項目の識別の変更を追跡してヴィジュアルスタジオキャッシュの値を更新する。補助文書データリストは、ユーザには見えない補助文書のリストを含み、その文書に対してオーケストレーションエンジンデザイナが機能する。例えば、ユーザがｃｏｄｅ  ｂｅｓｉｄｅファイルを開いていない場合でも、ユーザがオーケストレーションエンジンデザイナで変更を行うと、その変更がｃｏｄｅ  ｂｅｓｉｄｅファイルに行われることが可能である。このファイルはユーザには見えないので、このファイルは補助文書として保持される。ＸＯＭＬファイルが保存されると、補助文書は必ず自動的に保存される。それらのファイルの１つの名前が変わった場合、またはファイルが削除された場合、本発明は、相応して対応する補助文書オブジェクトを更新する。
【００９３】
オブジェクトツリーの例示的な非直列化の指針は、以下の通りである。初め、ｘｍｌ要素は、親オブジェクトのプロパティとして扱われる。親オブジェクトがその要素のタグ名を有するプロパティを持たない場合、その要素は、親オブジェクトの子オブジェクトとして扱われる。ｘｍｌ属性は、その親オブジェクトの単純なプロパティとして扱われる。
【００９４】
上記の直列化されたコードを使用した非直列化の例では、＜ｗｈｉｌｅ＞要素は、ｘｍｌ名前空間情報を使用して作成されたオブジェクトとして扱われる。＜ＣｏｎｄｉｔｉｏｎＲｕｌｅ＞要素は、Ｗｈｉｌｅアクティビティのプロパティとして扱われる。＜ＣｏｄｅＥｘｐｒｅｓｓｉｏｎＲｕｌｅＤｅｃｌａｒａｔｉｏｎ＞要素は、その値がＣｏｎｄｉｔｉｏｎＲｕｌｅプロパティに適用されるオブジェクトとして扱われる。＜Ｓｅｎｄ＞要素は、初めはＷｈｉｌｅアクティビティのプロパティとして試みられるが、「Ｗｈｉｌｅ」アクティビティは、「Ｓｅｎｄ」という名前のプロパティを持たないので、＜Ｓｅｎｄ＞要素はオブジェクトとして扱われ、ｗｈｉｌｅアクティビティの子アクティビティとして追加される。＜Ｍｅｓｓａｇｅ＞要素は、Ｓｅｎｄアクティビティのプロパティとして扱われる。ＳｅｎｄのＭｅｓｓａｇｅプロパティは読み取り専用なので、Ｍｅｓｓａｇｅ要素の内容は、Ｍｅｓｓａｇｅオブジェクトの内容とみなされる。同様の規則が、＜ＯｎＢｅｆｏｒｅＳｅｎｄ＞要素と＜ＴｙｐｅｄＣｈａｎｎｅｌ＞要素の非直列化にも当てはまる。
【００９５】
次の状況では、ＸＯＭＬの非直列化は、決定的に失敗する。すなわち、ＸＯＭＬコードが適切に形成されておらず、ＸｏｍｌＤｏｃｕｍｅｎｔがＸＯＭＬコード中の最初の要素でなく、ＸＯＭＬコードの最初のアクティビティを非直列化することができない。開発者には、エラーメッセージが提示され、そのメッセージで、開発者は、ＸＯＭＬビューからプロセス／ワークフロービューに切り替える際に違反しているＸＭＬ要素に移動することができる。
【００９６】
直列化と非直列化のためのアプリケーションプログラミングインターフェースが、付録Ｃにより詳細に記載される。
【００９７】
オーケストレーションエンジンデザイナをホストする
デザイナフレームワークは、任意のアプリケーションプログラムでホストすることができる。これは、サードパーティアプリケーションが各自の環境でワークフローをレンダリングするために非常に有用な機能である。また、これは、サードパーティが、設計面を再ホストし、カスタマイズすることにより、オーケストレーションエンジンデザイナを核としてツールを開発することも可能にする。本発明のフレームワークは、ホストするコンテナアプリケーションが、エディタおよび／またはテキストバッファなどのサービスのセットを提供するものと見込む。
【００９８】
デザイナを再ホストする際のステップの１つは、ローダと設計面を作成することである。ローダは、ＸＯＭＬファイルをロードし、アクティビティを維持するデザイナホストインフラストラクチャを構築する役割を負う。設計面は、その中にデザイナホストインフラストラクチャを保持し、設計面をホストするサービスおよび設計面と対話するためのサービスを提供する。設計面は、サービスコンテナとして、またサービスプロバイダとして機能する。一例では、次のコードが実行されてＸＯＭＬ文書をロードし、中にアクティビティを保持するデザイナホストを構築する。
【００９９】
this.loader.XomlFile = filePath;
if (this.surface.IsLoaded = false)
this. surface. BeginLoad(this. loader);
【０１００】
以下のサービスは、デザイナ中で様々な機能を可能にする。ＩＳｅｌｅｃｔｉｏｎＳｅｒｖｉｃｅ関数は、選択されたオブジェクトを維持する。ＩＴｏｏｌｂｏｘＳｅｒｖｉｃｅ関数は、ツールボックスとの対話を管理する。ＩＭｅｎｕＣｏｍｍａｎｄＳｅｒｖｉｃｅ関数は、メニューとの対話を管理する。ＩＴｙｐｅＰｒｏｖｉｄｅｒ関数は、タイプシステムを可能にする。また、高度なデザイナ機能を可能にするために、デザイナをホストする環境によって追加的なサービスが提供されることが可能である。
【０１０１】
タイプシステムは、本発明のコンポーネントモデルフレームワークの１コンポーネントである。プロジェクトシステムの内部でデザイナがホストされるときに、ＴｙｐｅＰｒｏｖｉｄｅｒオブジェクトが、プロジェクトにつき１つ作成される。プロジェクト中のアセンブリ参照は、タイププロバイダにプッシュされる。さらに、プロジェクト中のユーザコードファイルが解析され、単一のコードコンパイルユニットが作成され、タイププロバイダにプッシュされる。また、本発明は、タイプシステム中でタイプを変化させる可能性のあるプロジェクトシステム内のイベントをリスンし、変化に応じてタイププロバイダに適切な呼び出しを行ってタイプを再ロードする。
【０１０２】
取り消し／やり直し
スケジュールを作成し、正しく構築した後に、開発者は、行われた一連の動作をロールバックしたい場合がある。本発明の取り消しおよびやり直しの機能は、どのアクティビティが直接影響を受けたかを示す視覚的なフィードバックを提供する。例えば、アクティビティのプロパティ変更が未完了のときには、影響されたアクティビティが選択された状態になる。複数のオブジェクトの削除が未完了である場合には、関連するすべてのオブジェクトが、スケジュールに戻されるときに選択される。取り消し／やり直しは、他の分野の多くのアプリケーションで使用される一般的な機能であり、その意味はよく理解されている。オーケストレーションエンジンデザイナでは、取り消し／やり直しの項目は、保存されてパージされない。さらに、取り消し／やり直しは、プロセス／ワークフロービュー、ＸＯＭＬビューで、開発者がビューを切り替える時、および、ｃｏｄｅ  ｂｅｓｉｄｅで行うことができる。
【０１０３】
取り消し／やり直しは、プロセス／ワークフロービューにおける以下の動作に提供される。アクティビティのドラッグ・アンド・ドロップ（ツールボックスから設計面にアクティビティをドラッグする、スケジュールの一部から別の部分にアクティビティを移動する、１つのデザイナから別のデザイナにアクティビティを移動する等）、アクティビティの設定（アクティビティのプロパティを指定するなど）、および、カット／コピー／ペースト／削除。
【０１０４】
一実施形態では、直列化されたビュー（ＸＯＭＬビュー）は、テキストエディタの標準的な取り消し／やり直し操作を提供するＸＭＬエディタである。本発明のデザイナは、プロセス／ワークフロービューで行われ、直列化ビューで未完了になっている変更が、直列化コードの損失につながることを知らせるフィードバックを開発者に提供する。開発者がプロセス／ワークフロービューでスケジュールの一部を構築し、直列化ビューに切り替えた後、取り消し／やり直し操作を行うことを決定すると、警告が表示される。
【０１０５】
例示的動作環境
図１０に、コンピュータ１３０の形態の汎用コンピューティングデバイスの一例を示す。本発明の一実施形態では、コンピュータ１３０などのコンピュータが、ここに図示され、説明される他の図で使用するのに適する。コンピュータ１３０は、１つまたは複数のプロセッサすなわち処理装置１３２とシステムメモリ１３４を有する。図の実施形態では、システムバス１３６が、システムメモリ１３４を含む各種のシステム構成要素をプロセッサ１３２に結合する。バス１３６は、各種のバスアーキテクチャを使用した、メモリバスあるいはメモリコントローラ、ペリフェラルバス、アクセラレーテッドグラフィックポート、およびプロセッサバスあるいはローカルバスを含む数種のバス構造の１つまたは複数を表す。限定ではなく例として、そのようなアーキテクチャには、ＩＳＡ（Ｉｎｄｕｓｔｒｙ  Ｓｔａｎｄａｒｄ  Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＭＣＡ（Ｍｉｃｒｏ  Ｃｈａｎｎｅｌ  Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＥＩＳＡ（Ｅｎｈａｎｃｅｄ  ＩＳＡ）バス、ＶＥＳＡ（Ｖｉｄｅｏ  Ｅｌｅｃｔｒｏｎｉｃｓ  Ｓｔａｎｄａｒｄｓ  Ａｓｓｏｃｉａｔｉｏｎ）ローカルバス、およびメザニンバスとも称されるＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ  Ｃｏｍｐｏｎｅｎｔ  Ｉｎｔｅｒｃｏｎｎｅｃｔ）が含まれる。
【０１０６】
コンピュータ１３０は通例、少なくとも何らかの形態のコンピュータ可読媒体を有する。コンピュータ可読媒体は、揮発性および不揮発性の媒体、取り外し可能および取り外し不能の媒体を含み、コンピュータ１３０によるアクセスが可能な利用可能媒体でよい。限定ではなく例として、コンピュータ可読媒体は、コンピュータ記憶媒体と通信媒体を含む。コンピュータ記憶媒体には、コンピュータ可読命令、データ構造、プログラムモジュール、他のデータなどの情報を記憶するための方式または技術として実施された、揮発性および不揮発性、取り外し可能および取り外し不能の媒体が含まれる。例えば、コンピュータ記憶媒体には、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、または他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）、または他の光ディスク記憶、磁気カセット、磁気テープ、磁気ディスク記憶、または他の磁気記憶装置、あるいは、所望の情報の記憶に使用することができ、コンピュータ１３０によるアクセスが可能な他の媒体が含まれる。通信媒体は通例、コンピュータ可読命令、データ構造、プログラムモジュール、あるいは他のデータを、搬送波や他の移送機構などの変調データ信号として実施し、任意の情報伝達媒体を含む。当業者は、信号中に情報を符号化するような方式で特性の１つまたは複数を設定または変化させた変調データ信号に精通している。有線ネットワークや直接配線接続などの有線媒体と、音波、ＲＦ、赤外線、その他の無線媒体などの無線媒体は、通信媒体の例である。上記の媒体の組合せもコンピュータ可読媒体の範囲に含まれる。
【０１０７】
システムメモリ１３４は、取り外し可能および／または取り外し不能、揮発性および／または不揮発性メモリの形態のコンピュータ記憶媒体を含む。図の実施形態では、システムメモリ１３４は、読み取り専用メモリ（ＲＯＭ）１３８とランダムアクセスメモリ（ＲＡＭ）１４０を含む。起動時などにコンピュータ１３０内の要素間の情報転送を助ける基本ルーチンを含む基本入出力システム１４２（ＢＩＯＳ）は、通例ＲＯＭ１３８に記憶される。ＲＡＭ１４０は通例、処理装置１３２から即座にアクセス可能な、かつ／または処理装置１３２によって現在操作されているデータおよび／またはプログラムモジュールを保持する。限定ではなく例として、図１０には、オペレーティングシステム１４４、アプリケーションプログラム１４６、他のプログラムモジュール１４８、およびプログラムデータ１５０を示す。
【０１０８】
コンピュータ１３０は、この他の取り外し可能／取り外し不能、揮発性／不揮発性のコンピュータ記憶媒体も含むことができる。例えば、図１０には、取り外し不能、不揮発性の磁気媒体の読み書きを行うハードディスクドライブ１５４を示す。図１０には、取り外し可能、不揮発性の磁気ディスク１５８の読み書きを行う磁気ディスクドライブ１５６と、ＣＤ−ＲＯＭや他の光学媒体などの取り外し可能、不揮発性の光ディスク１６２の読み書きを行う光ディスクドライブ１６０も示す。例示的動作環境で使用することが可能なこの他の取り外し可能／取り外し不能、揮発性／不揮発性のコンピュータ記憶媒体には、これらに限定しないが、磁気テープカセット、フラッシュメモリカード、デジタル多用途ディスク、デジタルビデオテープ、固体素子ＲＡＭ、固体素子ＲＯＭなどがある。ハードディスクドライブ１５４、磁気ディスクドライブ１５６、光ディスクドライブ１６０は、通例、インターフェース１６６などの不揮発性メモリインターフェースによってシステムバス１３６に接続される。
【０１０９】
上記で説明し、図１０に示すドライブまたは他の大容量記憶装置とそれに関連するコンピュータ記憶媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、および他のデータを記憶をコンピュータ１３０に提供する。例えば図１０では、ハードディスクドライブ１５４に、オペレーティングシステム１７０、アプリケーションプログラム１７２、他のプログラムモジュール１７４、およびプログラムデータ１７６が記憶されている。これらの構成要素は、オペレーティングシステム１４４、アプリケーションプログラム１４６、他のプログラムモジュール１４８、プログラムデータ１５０と同じでも、異なってもよいことに留意されたい。ここでは、オペレーティングシステム１７０、アプリケーションプログラム１７２、他のプログラムモジュール１７４、プログラムデータ１７６には、それらが少なくとも異なるコピーであることを表すために異なる参照符号を付している。
【０１１０】
ユーザは、キーボード１８０およびポインティングデバイス１８２（マウス、トラックボース、ペン、タッチパッドなど）などの入力装置またはユーザインターフェース選択装置を通じてコンピュータ１３０にコマンドと情報を入力することができる。他の入力装置（図示せず）には、マイクロフォン、ジョイスティック、ゲームパッド、衛星受信アンテナ、スキャナなどがある。上記および他の入力装置は、システムバス１３６に結合されたユーザ入力インターフェース１８４を通じて処理装置１３２に接続されるが、パラレルポート、ゲームポート、ユニバーサルシリアルバス（ＵＳＢ）などの他のインターフェースおよびバス構造で接続してもよい。モニタ１８８または他のタイプの表示装置も、ビデオインターフェース１９０などのインターフェースを介してシステムバス１３６に接続される。モニタ１８８に加えて、コンピュータは多くの場合、プリンタやスピーカなどの他の周辺出力装置（図示せず）を含み、それらの出力装置は、出力周辺インターフェース（図示せず）を通じて接続することができる。
【０１１１】
コンピュータ１３０は、リモートコンピュータ１９４などの１つまたは複数のリモートコンピュータとの論理接続を使用するネットワーク環境で動作することができる。リモートコンピュータ１９４は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイス、あるいは他の一般的なネットワークノードであり、通例は、コンピュータ１３０との関連で上述した要素の多くまたはすべてを含む。図１０に示す論理接続は、ローカルエリアネットワーク（ＬＡＮ）１９６とワイドエリアネットワーク（ＷＡＮ）１９８を含むが、他のネットワークを含むことも可能である。ＬＡＮ１９６および／またはＷＡＮ１９８は、有線ネットワーク、無線ネットワーク、それらの組合せ等である。このようなネットワーキング環境は、オフィス、企業内のコンピュータネットワーク、イントラネット、および世界規模のコンピュータネットワーク（インターネットなど）に一般的に見られる。
【０１１２】
ローカルエリアネットワーキングの環境で使用される場合、コンピュータ１３０は、ネットワークインターフェースあるいはアダプタ１８６を通じてＬＡＮ１９６に接続される。ワイドエリアネットワーキング環境で使用される場合、コンピュータ１３０は通例、インターネットなどのＷＡＮ１９８を通じて通信を確立するモデム１７８あるいは他の手段を含む。モデム１７８は、内蔵型でも外付け型でもよく、ユーザ入力インターフェース１８４あるいは他の適切な機構を介してシステムバス１３６に接続される。ネットワーク環境では、コンピュータ１３０との関連で図示されるプログラムモジュール、あるいはその一部は、遠隔のメモリ記憶装置（図示せず）に記憶してよい。限定ではなく例として、図１０では、リモートアプリケーションプログラム１９２がメモリ装置にある。ここに示すネットワーク接続は例示的なものであり、コンピュータ間に通信リンクを確立する他の手段を使用してよい。
【０１１３】
一般に、コンピュータ１３０のデータプロセッサは、異なる時にコンピュータの各種のコンピュータ可読記憶媒体に記憶される命令によってプログラムされる。通例、プログラムとオペレーティングシステムは、例えばフロッピー（登録商標）ディスクやＣＤ−ＲＯＭで配布される。そこから、コンピュータの２次メモリにインストールまたはロードされる。実行時に、プログラムとオペレーティングシステムは、少なくとも一部がコンピュータの主要電子メモリにロードされる。本明細書に記載される本発明は、そのような媒体が、マイクロプロセッサあるいは他のデータプロセッサと連動して下記のステップを実施する命令またはプログラムを含む場合には、上記およびその他の各種タイプのコンピュータ可読記憶媒体を含む。本発明は、本明細書に記載される方法および技術に従ってプログラムされた場合にはコンピュータ自体も含む。
【０１１４】
説明のために、オペレーティングシステムなどのプログラムおよび他の実行可能プログラムコンポーネントは、ここでは別個のブロックとして図示する。しかし、そのようなプログラムおよびコンポーネントは、様々な時にコンピュータの様々な記憶コンポーネントに存在し、コンピュータのデータプロセッサによって実行されることは認識されよう。
【０１１５】
ここではコンピュータ１３０を含む例示的なコンピューティングシステム環境との関連で説明したが、本発明は、多数の他の汎用または特殊目的のコンピューティングシステム環境または構成で動作することができる。このコンピューティングシステム環境は、本発明の使用または機能性の範囲についての限定を示唆するものではない。さらに、このコンピューティングシステム環境は、例示的動作環境に図示する構成要素の１つまたは組合せに関連する依存性または必要性を有するものと解釈すべきでない。本発明に使用するのに適する可能性があるよく知られるコンピューティングシステム、環境、および／または構成の例には、これらに限定しないが、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルドあるいはラップトップデバイス、マルチプロセッサシステム、マイクロプロセッサを利用したシステム、セットトップボックス、設定可能な家庭電化製品、携帯電話、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、上記のシステムまたはデバイスを含む分散コンピューティング環境などがある。
【０１１６】
本発明は、１つまたは複数のコンピュータまたは他のデバイスによって実行される、プログラムモジュールなどのコンピュータ実行可能命令の一般的な文脈で説明することができる。一般に、プログラムモジュールには、これらに限定しないが、特定のタスクを行うか、特定の抽象データ型を実装する、ルーチン、プログラム、オブジェクト、コンポーネント、およびデータ構造が含まれる。本発明は、通信ネットワークを通じて結ばれた遠隔の処理デバイスによってタスクが行われる分散コンピューティング環境でも実施することができる。分散コンピューティング環境では、プログラムモジュールは、メモリ記憶装置を含むローカルおよびリモート両方のコンピュータ記憶媒体に配置することができる。
【０１１７】
ソフトウェアアーキテクチャの文脈におけるインターフェースには、ソフトウェアモジュール、コンポーネント、コード部分、あるいは他のコンピュータ実行可能命令のシーケンスが含まれる。インターフェースは、例えば、第２のモジュールにアクセスして第１のモジュールのためのコンピューティングタスクを行う第１のモジュールを含む。第１および第２のモジュールは、一例では、オペレーティングシステムによって提供されるようなアプリケーションプログラミングインターフェース（ＡＰＩ）、コンポーネントオブジェクトモデル（ＣＯＭ）インターフェース（ピアツーピアのアプリケーション通信用など）、拡張型マークアップ言語メタデータ交換フォーマット（ＸＭＩ）インターフェース（ウェブサービス間の通信用等）を含む。
【０１１８】
インターフェースは、Ｊａｖａ（登録商標）２Ｐｌａｔｆｏｒｍ  Ｅｎｔｅｒｐｒｉｓｅ  Ｅｄｉｔｉｏｎ（Ｊ２ＥＥ）、ＣＯＭ、または分散ＣＯＭ（ＤＣＯＭ）の例などのように、密結合の同期された実装とすることができる。これに代えて、またはこれに加えて、インターフェースは、ウェブサービス（シンプルオブジェクトアクセスプロトコルを使用したものなど）などのように、疎結合の非同期の実装としてもよい。一般に、インターフェースは、密結合、疎結合、同期、および非同期、の特徴の組合せを含む。さらに、インターフェースは、標準プロトコル、独自プロトコル、または標準プロトコルと独自プロトコルの組合せに準拠することができる。
【０１１９】
ここに記載されるインターフェースは、すべて、単一のインターフェースの一部であっても、別個のインターフェースとして実施されても、またはそれらの組合せとして実装してもよい。インターフェースは、ローカルまたはリモートで実行されて機能を提供することができる。さらに、インターフェースは、ここに図示あるいは記載されるより多くの機能を含んでも、あるいは少ない機能を含んでもよい。
【０１２０】
ここに図示され記載される方法の実行または動作の順序は、特に指定しない限りは重要ではない。すなわち、方法の要素は、指定しない場合はどのような順序で行ってもよく、この方法は、本明細書に開示されるより含む要素が多くても少なくてもよい。例えば、別の要素の前に特定の要素を実行する、別の要素と同時に実行する、または別の要素の後に実行することが本発明の範囲内にあることが企図される。
【０１２１】
本発明または本発明の実施形態の要素を紹介する際、冠詞「ａ」、「ａｎ」、「ｔｈｅ」、「ｓａｉｄ（前記）」は、その要素が１つまたは複数あることを意味する。用語「〜を備える」、「〜を含む」、「〜を有する」は、包含的な意味とし、列挙される要素以外に追加的な要素があってよいことを意味する。
【０１２２】
上記から、本発明のいくつかの目的が実現され、他の有利な結果が得られることが理解されよう。
【０１２３】
本発明の範囲から逸脱することなく、上記の構成、製品、および方法に各種の変更を加えることができるので、上記の説明に含まれ、添付の図面に示されるすべての事項は、例示的なものであり、限定的な意味で解釈すべきではない。
【０１２４】
付録Ａ
例示的アクティビティとその例示的実装
例示的なアクティビティには、以下が含まれる：Ｓｅｎｄ、ＳｅｎｄＲｅｑｕｅｓｔ、ＳｅｎｄＲｅｓｐｏｎｓｅ、Ｒｅｃｅｉｖｅ、ＲｅｃｅｉｖｅＲｅｑｕｅｓｔ、ＲｅｃｅｉｖｅＲｅｓｐｏｎｓｅ、Ｃｏｄｅ、Ｄｅｌａｙ、Ｆａｕｌｔ、Ｓｕｓｐｅｎｄ、Ｔｅｒｍｉｎａｔｅ、ＩｎｖｏｋｅＳｃｈｅｄｕｌｅ、ＩｎｖｏｋｅＳｃｈｅｄｕｌｅｓ、ＩｎｖｏｋｅＷｅｂＳｅｒｖｉｃｅ、ＤｏｔＮｅｔＥｖｅｎｔＳｏｕｒｃｅ、ＤｏｔＮｅｔＥｖｅｎｔＳｉｎｋ、Ｓｅｑｕｅｎｃｅ、Ｐａｒａｌｌｅｌ、Ｗｈｉｌｅ、ＣｏｎｄｉｔｉｏｎａｌＢｒａｎｃｈ、Ｃｏｎｄｉｔｉｏｎａｌ、Ｃｏｎｓｔｒａｉｎｅｄ、ＣｏｎｓｔｒａｉｎｅｄＡｃｔｉｖｉｔｙＧｒｏｕｐ（ＣＡＧ）、ＥｖｅｎｔＤｒｉｖｅｎ、Ｌｉｓｔｅｎ、ＥｖｅｎｔＨａｎｄｌｅｒｓ、ＥｘｃｅｐｔｉｏｎＨａｎｄｌｅｒ、ＥｘｃｅｐｔｉｏｎＨａｎｄｌｅｒｓ、Ｃｏｍｐｅｎｓａｔｅ、ＣｏｍｐｅｎｓａｔｉｏｎＨａｎｄｌｅｒ、Ｓｃｏｐｅ、およびＳｃｈｅｄｕｌｅ。
【０１２５】
この例示的なアクティビティそれぞれには、メタデータが関連付けられる。このメタデータは、アクティビティに関連付けられたシリアライザによってワークフローの宣言型表現に移される。メタデータには、例えば、オプションのｃｏｄｅ−ｂｅｓｉｄｅメソッドと、オプションの相関セットの集まりが含まれる。
【０１２６】
Ｓｅｎｄアクティビティ
オーケストレーションエンジンは、メッセージを送信するために３つのアクティビティ（例えばＳｅｎｄ、ＳｅｎｄＲｅｑｕｅｓｔ、ＳｅｎｄＲｅｓｐｏｎｓｅ）を提供し、それぞれのアクティビティは、異なる使用事例に対応する。また、これら３つのアクティビティは一部のメタデータを共有するので、抽象基本クラスが定義され、３つすべてのスーパークラスとして使用される。
【０１２７】
Ｒｅｃｅｉｖｅアクティビティ
オーケストレーションエンジンは、メッセージを受け取る３つのアクティビティ（例えばＲｅｃｅｉｖｅ、ＲｅｃｅｉｖｅＲｅｑｕｅｓｔ、ＲｅｃｅｉｖｅＲｅｓｐｏｎｓｅ）を提供し、それぞれのアクティビティは、異なる使用事例に対応する。また、これら３つのアクティビティは一部のメタデータを共有するので、抽象基本クラスが定義され、３つすべてのスーパークラスとして使用される。
【０１２８】
Ｃｏｄｅ
Ｃｏｄｅアクティビティは、メタデータで指示されるｃｏｄｅ−ｂｅｓｉｄｅメソッドを実行する。
【０１２９】
Ｄｅｌａｙ
Ｄｅｌａｙアクティビティは、自身の必須のｃｏｄｅ−ｂｅｓｉｄｅメソッドを実行してＤａｔｅＴｉｍｅ値を生成する。Ｄｅｌａｙアクティビティは、内部で、自身のインスタンスデータのＴｉｍｅｏｕｔＶａｌｕｅプロパティをその値に設定する。そのＤａｔｅＴｉｍｅ値が過去である場合、Ｄｅｌａｙは直ちに完了する。そうでない場合は、タイマが始動するとＤｅｌａｙが通知されるようにタイマの利用をセットアップする。タイマが始動すると、Ｄｅｌａｙが通知され、完了する。
【０１３０】
Ｆａｕｌｔ
Ｆａｕｌｔアクティビティは、自身の必須のｃｏｄｅ−ｂｅｓｉｄｅメソッドを実行してＥｘｃｅｐｔｉｏｎオブジェクトを生成する。そしてその例外を投げる。
【０１３１】
Ｓｕｓｐｅｎｄ
Ｓｕｓｐｅｎｄアクティビティは、現在のスケジュールインスタンスを一時停止する。
【０１３２】
Ｔｅｒｍｉｎａｔｅ
Ｔｅｒｍｉｎａｔｅアクティビティは、現在のスケジュールインスタンスを終了させる。
【０１３３】
Ｉｎｖｏｋｅ  Ｓｃｈｅｄｕｌｅ
ＩｎｖｏｋｅＳｃｈｅｄｕｌｅアクティビティは、スケジュールを呼び出す。
【０１３４】
Ｉｎｖｏｋｅ  Ｗｅｂ  Ｓｅｒｖｉｃｅ
プロキシクラスを介してウェブサービスを呼び出し、指定されるパラメータを渡し、受け取る。
【０１３５】
ＤｏｔＮｅｔＥｖｅｎｔ  Ｓｉｎｋ
指定されたイベントが、以前に呼び出されたスケジュールインスタンスによって発生させられていることを知らせる待機中の通知を阻止する。
【０１３６】
ＤｏｔＮｅｔＥｖｅｎｔ  Ｓｏｕｒｃｅ
指定されたイベントを発生させ、直ちに実行を完了する。
【０１３７】
Ｓｅｑｕｅｎｃｅ
Ｓｅｑｕｅｎｃｅアクティビティは、一度に１つずつ順序付けられた方式で子アクティビティのセットが実行されるように調整する。
【０１３８】
Ｐａｒａｌｌｅｌ
Ｐａｒａｌｌｅｌアクティビティは、子アクティビティのセットを並行して実行する。
【０１３９】
Ｗｈｉｌｅ
子アクティビティを反復的に実行する。
【０１４０】
ＣｏｎｄｉｔｉｏｎａｌＢｒａｎｃｈ
Ｓｅｑｕｅｎｃｅのセマンティック単位で子アクティビティを実行する。
【０１４１】
Ｃｏｎｄｉｔｉｏｎａｌ
Ｃｏｎｄｉｔｉｏｎａｌアクティビティは、順序付けられたＣｏｎｄｉｔｉｏｎａｌＢｒａｎｃｈアクティビティのセットを含む。
【０１４２】
Ｃｏｎｓｔｒａｉｎｅｄ
ＣｏｎｓｔｒａｉｎｅｄアクティビティがＣＡＧから実行されるように指示されると、単にそれがラップするアクティビティを実行する。
【０１４３】
ＣＡＧ（Ｃｏｎｓｔｒａｉｎｅｄアクティビティグループ）
ＣＡＧが実行されるときには、各自のイネーブルおよびディセーブルの制約の評価に基づいて子アクティビティを実行（および再実行）する。
【０１４４】
Ｔａｓｋ
１つまたは複数のプリンシパルによって行われる外部の作業単位をモデリングする。
【０１４５】
ＥｖｅｎｔＤｒｉｖｅｎ
「イベント」アクティビティによって実行がトリガされるアクティビティをラップする。
【０１４６】
Ｌｉｓｔｅｎ
ｎ個の子ＥｖｅｎｔＤｒｉｖｅｎアクティビティの１つを条件付きで実行する。
【０１４７】
Ｅｖｅｎｔ  Ｈａｎｄｌｅｒ
ＥｖｅｎｔＨａｎｄｌｅｒアクティビティは、単に、関連付けられたＳｃｏｐｅで使用されるＥｖｅｎｔＤｒｉｖｅｎアクティビティのセットを保持する。
【０１４８】
Ｅｘｃｅｐｔｉｏｎ  Ｈａｎｄｌｅｒ
スコープのキャッチブロックを表すメタデータを有するアクティビティをラップする。
【０１４９】
Ｅｘｃｅｐｔｉｏｎ  Ｈａｎｄｌｅｒｓ
ＥｘｃｅｐｔｉｏｎＨａｎｄｌｅｒアクティビティの順序付けられたセットをラップする。
【０１５０】
Ｃｏｍｐｅｎｓａｔｅ
完了した子スコープを補償する。
【０１５１】
Ｃｏｍｐｅｎｓａｔｉｏｎ  Ｈａｎｄｌｅｒ
スコープの補償ハンドラとして定義された子アクティビティをラップする。
【０１５２】
Ｓｃｏｐｅ
スコープは、トランザクションの境界、例外処理の境界、補償の境界、イベント処理の境界、メッセージ、変数、相関セット、およびチャネルの宣言（すなわち共有されるデータ状態）の境界である。スコープ中のアクティビティの実行は順次行われ、したがって、含まれるアクティビティは、Ｓｅｑｕｅｎｃｅと同様に、スコープが構築されるときに明示的に順序付けられる。
【０１５３】
Ｓｃｈｅｄｕｌｅ
Ｓｃｈｅｄｕｌｅは、オーケストレーションエンジンが実行する唯一の最上位アクティビティである。
【０１５４】
Ｃｏｍｐｏｓｉｔｅ  Ａｃｔｉｖｉｔｉｅｓ
制御のフローを可能にする複合アクティビティタイプは、Ｓｅｑｕｅｎｃｅ、Ｐａｒａｌｌｅｌ、Ｃｏｎｓｔｒａｉｎｅｄ  Ａｃｔｉｖｉｔｙ  Ｇｒｏｕｐ、Ｃｏｎｄｉｔｉｏｎａｌ、Ｗｈｉｌｅ、Ｌｉｓｔｅｎである。また、ＳｃｏｐｅとＳｃｈｅｄｕｌｅは、それらの中のアクティビティの暗示的な順序付けを有するコンテナとして機能する複合アクティビティタイプである。
【０１５５】
付録Ｂ
拡張可能オーケストレーションマークアップ言語（ＸＯＭＬ）
ＸＯＭＬは、ワークフロープロセス定義を定義する例示的な宣言型マークアップ言語である。ＸＯＭＬは、ワークフロー技術のアクティビティモデルを使用してプロセス定義を記述する。ＸＯＭＬスキーマフォーマットは、プロセス定義のみに限定されず、プロパティおよびイベントを使用してオブジェクトを記述する任意のオブジェクトツリーを記述するためにも使用することができる。ＸＯＭＬは、コンポーネントツリーの直列化の表現／フォーマットであり、固定された文法を持つ言語（ＢＰＥＬ、ＢＰＭＬ、ＷＳＦＬなど）ではない。ＸＯＭＬを使用して、拡張可能マークアップ言語（ＸＭＬ）の形式で任意のオブジェクト階層を表現することができ、各オブジェクトは、共通言語ルーチン（ＣＬＲ）のメタデータ（例えばプロパティおよびイベント）の点から記述することができる。ＸＯＭＬスキーマは、任意のオブジェクトをＸＯＭＬスキーマの一部とすることができる点で拡張可能である。
【０１５６】
基本ＸＯＭＬフォーマット
ＸＯＭＬファイルは、ＸＭＬファイルであり、そのルート要素はＸｏｍｌＤｏｃｕｍｅｎｔオブジェクトである。ＸｏｍｌＤｏｃｕｍｅｎｔは、所与のアクティビティパッケージのルートアクティビティまたはプロセスアクティビティを直列化したものである１つのプロセス定義を含む。次にＸＯＭＬファイルの例を示す。
【０１５７】
【表４】
2006107474.tif 000006
【０１５８】
ｘｍｌｓ：ｘｍｌｎｓ属性は、ｘｍｌ名前空間を、共通言語ルーチン（ＣＬＲ）の名前空間とアセンブリ情報にマッピングするために使用される。上記の例では、ｘｍｌｎｓ属性は、「ＸｏｍｌＤｏｃｕｍｅｎｔ」が、「Ｓｙｓｔｅｍ．Ｗｏｒｋｆｌｏｗ．ＣｏｍｐｏｎｅｎｔＭｏｄｅｌ．ｄｌｌ」アセンブリと「Ｓｙｓｔｅｍ．Ｗｏｒｋｆｌｏｗ．ＣｏｍｐｏｎｅｎｔＭｏｄｅｌ」名前空間のクラス名であることを表す。ｘｍｌｎｓに使用されるフォーマットは、＜名前空間の名前＞，＜完全修飾されたアセンブリ名＞である。この情報を使用して、対応するアセンブリがロードされ、そのアセンブリ中のタイプが解決される。
【０１５９】
＜ＸｏｍｌＤｏｃｕｍｅｎｔ＞：ｘｏｍｌの最上位要素は「ＸｏｍｌＤｏｃｕｍｅｎｔ」である。この要素を使用して、プロセス定義についての任意のコンテクスト固有の情報を関連付ける。一例として、ＣｏｍｐｉｌｅＷｉｔｈ属性は、設計時にｃｏｄｅ  ｂｅｓｉｄｅファイルをプロセス定義に関連付ける。同様に、ＭｅｓｓａｇｅＴｙｐｅｓ、Ｃｈａｎｎｅｌタイプなど環境に固有の他の情報をプロセス定義に関連付けることができる。
【０１６０】
＜Ｓｃｈｅｄｕｌｅ＞：スケジュール要素は、プロセス定義のルートである。一実施形態では、ＸｏｍｌＤｏｃｕｍｅｎｔは、関連付けられたスケジュール子要素を１つだけ有することができる。Ｓｃｈｅｄｕｌｅは、子アクティビティをいくつ含んでもよい複合アクティビティである。一実施形態では、ＸＯＭＬで表されるコンポーネントは、オーケストレーションエンジンのアクティビティであり、明確な作成時の挙動を有する。ＸＯＭＬはＣＬＲコンポーネントを直列化したものなので、そのタイプシステムはＣＬＲに基づき、ＸＳＤには基づかない。
【０１６１】
ＸＯＭＬは、次のための宣言型コンストラクトを含む。
【０１６２】
−  ＸＭＬ名前空間から他の名前空間へのマッピング
−  データ、アクティビティ、および規則の宣言
−  宣言型のデータバインディングと変換
−  エンティティ（データ、アクティビティ、規則など）を一意に識別する
−  エンティティ（内部および外部）を参照する
−  宣言型データバインディングのためのアクティビティのプロパティを定義する
ＸＯＭＬシリアライザは、名前空間宣言の値によって指定されるディレクトリのＸＭＬ名前空間ファイルを探す。シリアライザは、所定のネットワークアドレスにある定義ファイルを検索する。例示的な定義ファイルを下記に示す。
【０１６３】
【表５】
2006107474.tif 000007
【０１６４】
ＸＯＭＬ中のすべての要素名は、ＣＬＲタイプ名にマッピングされる。要素のＸＭＬ名前空間に基づいて、対応するＣＬＲ名前空間とアセンブリが見つけられる。一例として、次の例では、Ｔａｓｋ１がＷｏｒｋｆｌｏｗＡｐｐｌｉｃａｔｉｏｎ１アセンブリからロードされる。
【０１６５】
【表６】
2006107474.tif 000008
【０１６６】
ＸＯＭＬの属性は、プロパティを設定する。プロパティは次のように設定されることができる。
【０１６７】
１．単純なＸＭＬ属性
【０１６８】
【表７】
2006107474.tif 000009
【０１６９】
２．ストリング値を有する複合プロパティ
【０１７０】
【表８】
2006107474.tif 000010
【０１７１】
３．値としてのオブジェクトを有する複合プロパティ
【０１７２】
【表９】
2006107474.tif 000011
【０１７３】
この場合は、変数名Ａｒｔの値がパラメータとしてＳｕｓｐｅｎｄアクティビティに渡される。妥当性検査のインフラストラクチャは、変数Ａｒｔのタイプがｔｙｐｅｏｆ（ストリング）に変換可能であることを保証する。
【０１７４】
ＸＯＭＬのデータは、複数の方式で宣言されることができる。一実施形態では、コードクラスを使用してクラスをアクティビティに関連付け、ｄｅｆ：Ｃｏｄｅを使用してフィールドを宣言する。別の方式は、ＤａｔａＣｏｎｔｅｘｔをアクティビティに関連付けるものである。アクティビティが定義されたＤａｔａＣｏｎｔｅｘｔを有しない場合は、親チェーン中のそのアクティビティのＤａｔａＣｏｎｔｅｘｔが使用される。次に示すのは、アクティビティに関連付けられたＸＯＭＬ中でＤａｔａ  Ｓｏｕｒｃｅを宣言する例である。
【０１７５】
【表１０】
2006107474.tif 000012
【０１７６】
上記の例では、タイプが「Ａｒｔ．ｂａｒ」で名前「ａｒｔ」を有するＤａｔａ  Ｏｂｊｅｃｔを宣言している。ＯｂｊｅｃｔＤａｔａＳｏｕｒｃｅインスタンスは、自身のデフォルトコンストラクタを呼び出すか、または、Ｐａｒａｍｅｔｅｒｓ属性が指定される場合は、そのＰａｒａｍｅｔｅｒ属性の値を有する署名に最も一致するコンストラクタを呼び出すことにより、ＴｙｐｅＮａｍｅによって参照されるクラスの新しいインスタンスを作成する。
【０１７７】
Ｏｂｊｅｃｔデータソースと同様に、カスタムのデータソースも定義することができる。データソースは、次の例のようにＩＤａｔａＳｏｕｒｃｅインターフェースを実装する。
【０１７８】
【表１１】
2006107474.tif 000013
【０１７９】
このインターフェースは、バインディングにデータソース項目からデータを得させるＤａｔａプロパティを有する。Ｄａｔａ  Ｓｏｕｒｃｅの実装は、データプロバイダのネイティブのアプリケーションプログラミングインターフェース（ＡＰＩ）を返す、強く型付けされた（ｔｙｐｅｄ）プロパティも提供する。
【０１８０】
データバインディングは、基礎となる何らかのデータをデータソースの１つまたは複数に関連付ける。ＸＯＭＬでは、バインディングの前にデータを変換することもできる。データソースは、ＣＬＲオブジェクト、データベース、ＸＭＬ文書、ウェブサービスメッセージ、または、ＩＤａｔａＳｏｕｒｃｅインターフェースを実装するカスタム定義のデータソースなどの任意のデータソースでよい。
【０１８１】
アクティビティのプロパティはいずれも、データソースとアクティビティのターゲットプロパティとの間に必要とする対応関係を定義することにより、ＣＬＲオブジェクトにバインディングすることができる。そのような対応関係はそれぞれ次を指定する。
【０１８２】
−  データソース項目
−  データソース項目中の該当する値へのパス
−  ターゲットアクティビティ
−  ターゲットプロパティ
オーケストレーションエンジンの作成オブジェクトモデルは、Ｔｒａｎｓｆｏｒｍｅｒ、Ｓｏｕｒｃｅ、およびＰａｔｈなどの複数のプロパティを有するＢｉｎｄクラスを提供する。開発者は、Ｐａｔｈプロパティを、そのオブジェクトをバインディングするデータソース中のプロパティまたは値を指定するストリングに設定する。開発者は、Ｔｒａｎｓｆｏｒｍｅｒプロパティを、ＩＤａｔａＴｒａｎｓｆｏｒｍｅｒインターフェースを実装するオブジェクトに設定する。データバインディングが値を伝搬する際には、トランスフォーマを通じて値を渡す。トランスフォーマは、渡される値を調べ、出力として新しい値を生成する。Ｓｏｕｒｃｅプロパティは、そのバインディングのためのソースデータ項目を参照する。ＤａｔａＳｏｕｒｃｅ、ＡｃｔｉｖｉｔｙＳｏｕｒｃｅ、ＤａｔａＣｏｎｔｅｘｔＳｏｕｒｃｅ、およびＯｂｊｅｃｔＳｏｕｒｃｅ属性が、ＢｉｎｄオブジェクトのＳｏｕｒｃｅプロパティを設定する。ＡｃｔｉｖｉｔｙＳｏｕｒｃｅ属性は、アクティビティ識別子をＡｃｔｉｖｉｔｙＳｏｕｒｃｅ属性の値として提供することにより、ソースをあるアクティビティに設定する。ＤａｔａＣｏｎｔｅｘｔＳｏｕｒｃｅ属性は、Ｓｏｕｒｃｅを別のアクティビティのＤａｔａＣｏｎｔｅｘｔに設定する。ＯｂｊｅｃｔＳｏｕｒｃｅ属性は、バインディングのソースとしてのオブジェクトを指定する。ＤａｔａＳｏｕｒｃｅ属性は、バインディングのソースとしてのオブジェクトを指定する。
【０１８３】
アクティビティのプロパティのデータバインディングを指定する構文は複数存在する。簡潔な構文では、開発者は、複雑なプロパティを指定せず、代わりにプロパティの値自体にデータバインディングの宣言を直接指定することができる。バインドオブジェクトへのパラメータは、セミコロンで区切られた名前値の対として指定される。
【０１８４】
次のデータバインディングの例では、ＲｅｃｅｉｖｅアクティビティのＭｅｓｓａｇｅプロパティが、ＰｒｏｃｅｓｓのＤａｔａ  Ｃｏｎｔｅｘｔで定義されるｍｓｇｌのＯｂｊｅｃｔ  Ｄａｔａ  Ｓｏｕｒｃｅにバインディングされる。同様に、ＳｅｎｄアクティビティのＭｅｓｓａｇｅプロパティが、｛ｒｅｃｅｉｖｅ１｝アクティビティのＭｅｓｓａｇｅアクティビティにバインディングされる。
【０１８５】
【表１２】
2006107474.tif 000014
【０１８６】
ＸＯＭＬでのデータ変換は、データトランスフォーマを使用して行われる。データトランスフォーマは、データソースからターゲットに、またターゲットからデータソースに伝播する際に、値を１つの形式から別の形式に変換することを可能にするコンポーネントである。トランスフォーマを使用して、値をその内部表現から一意の値に変換することができる。トランスフォーマは、データタイプのコンバータとして使用することもできる。トランスフォーマは、データを１つのフォーマットから別のフォーマットに変換するために使用される、ＩＤａｔａＴｒａｎｓｆｏｒｍｅｒと称されるインターフェースに基づく。このインターフェースの例示的な定義を下に示す。
【０１８７】
【表１３】
2006107474.tif 000015
【０１８８】
データバインディングは、ソース値をターゲットプロパティに伝播する際にＴｒａｎｓｆｏｒｍメソッドを呼び出す。パラメータ「ｏ」がソース値である。次の例は、ＸＳＬＴを適用し、それを別のＸＭＬフォーマットに変換するＸＭＬ入力ストリングを有するトランスフォーマを示す。
【０１８９】
【表１４】
2006107474.tif 000016
【０１９０】
ＸＯＭＬ中でＴｒａｎｓｆｏｒｍｅｒを参照するために、開発者は、ＤａｔａＣｏｎｔｅｘｔにＴｒａｎｓｆｏｒｍｅｒオブジェクトを宣言し、それをＢｉｎｄクラスで参照する。次の例は、ＸＯＭＬでデータを宣言的に変換する方式を示す。
【０１９１】
【表１５−１】
2006107474.tif 000017
【０１９２】
【表１５−２】
2006107474.tif 000018
【０１９３】
本発明は、開発者がカスタムのアプリケーションロジックをワークフロープロセスモデルに関連付けられるように、Ｃ＃およびＶｉｓｕａｌＢａｓｉｃ（あるいは他のＣｏｄｅＤＯＭ対応言語）をＸＯＭＬに関連付けることをサポートする。各アクティビティは、任意で、コンパニオンクラスを介して自身の使用法とコードの関連付けを定義することができる。一部のアクティビティは、関連付けられた対応するコンパニオンクラス（オーケストレーションエンジンのＳｃｏｐｅなど）を有し、他のアクティビティは、親アクティビティのコンパニオンクラスの一部として関連付けられたメンバ、メソッド、およびハンドラのみを有する。コンパニオンクラスは、部分クラスである。コンパニオンクラスの典型的な使用法のいくつかには次が含まれる。
【０１９４】
・  変数、メッセージ、チャネル、および相関セットの宣言
・  ｉｎ／ｏｕｔ／ｒｅｆパラメータの宣言
・  追加的なカスタムプロパティの宣言
・  送信するメッセージの作成
・  受け取られたメッセージの処理
・  ブール値を返すコードとして表された規則の実装
・  ローカルに定義された変数の操作
・  アクティビティメタデータとインスタンスデータの読み取り
・  アクティビティインスタンスデータの書き込み（例えばデータフローで実行されるアクティビティのプロパティの設定）
・  イベントの発生
・  プロセスモデルの動的な変更
・  例外の投入
コンパニオンクラスとそれに関連付けられたメンバは、ＸＯＭＬの一部としても（ｃｏｄｅｗｉｔｈｉｎとして）、別個のコードファイルの一部として存在してもよい。それに応じて、ＸＯＭＬにコードを関連付けるには、ｃｏｄｅ  ｗｉｔｈｉｎとｃｏｄｅ  ｂｅｓｉｄｅの２つの作成方式がある。ｃｏｄｅ  ｗｉｔｈｉｎモデルは、ＸＯＭＬの一部としてのコードのインライン化をサポートする（例えばＡＳＰ、ＤＨＴＭＬ、ＢＰＥＬＪと同様のマークアップ内のコードのまとまり（ｉｓｌａｎｄ）をインタリーブする）。このモードは、過度にコードが多くない小規模なアプリケーションに適する。ＸＯＭＬファイルのｃｏｄｅ  ｗｉｔｈｉｎを可能にするために、すべての他のタグや属性のように実装の背後に実際のクラスを持たない、コンパイルプロセスによって解釈されるタグと属性の集まりがある。これらのタグは、Ｄｅｆｉｎｉｔｉｏｎの名前空間で定義される（ｘｍｌｎｓ：ｄｅｆ＝Ｄｅｆｉｎｉｔｉｏｎ）。ＸＯＭＬファイル中のすべてのアクティビティは、そのアクティビティに関連付けられたクラスを決定するｄｅｆ：Ｃｌａｓｓ属性に関連付けることができる。また、ｄｅｆ：Ｃｏｄｅを使用して、コードを用いてメソッドとフィールドを追加することができる。
【０１９５】
コードが多い（ｃｏｄｅ−ｉｎｔｅｎｓｉｖｅ）ワークフローアプリケーションに対しては、本発明は、ｃｏｄｅ−ｂｅｓｉｄｅファイルをＸＯＭＬ文書に関連付けることを含む、Ｃｏｄｅ  ＢｅｓｉｄｅまたはＣｏｄｅ  Ｓｅｐａｒａｔｉｏｎの作成方式をサポートする。ｃｏｄｅ  ｂｅｓｉｄｅファイルは、コンパニオンクラスを必要とするアクティビティ（例えばスケジュールおよびスコープ）のコンパニオンクラスを含む。ＸＯＭＬファイルは、ＲｅｆｅｒｅｎｃｅＦｉｌｅ要素を使用してＣｏｄｅ  Ｂｅｓｉｄｅを参照する。
【０１９６】
上記の２つの作成方式のいずれでも、ＸＯＭＬコンパイラが、ユーザに見えるコードクラスと併合された隠された部分クラスをエミットしてコードクラスをサポートするアクティビティ（例えばルートまたはその他）に関連付けられた一意のタイプを生成することを含むコード生成を行う。
【０１９７】
ＸＯＭＬファイルのローカライズ
本発明は、ＸＯＭＬを含む同一のアセンブリの．ｒｅｓｘまたは．ｒｅｓｏｕｒｃｅｓをポイントするスキーマ中にｄｅｆ：ｒｅｓｏｕｒｃｅｓを含む。リソース識別子を参照するには、ｒｅｓ：ＸＸＸタグが使用される。各ＸＯＭＬファイルは、任意で、ｃｏｄｅ  ｂｅｓｉｄｅ、規則の記述、ロールの記述、ホストの構成、および、アクティビティパッケージマニフェスト、の関連付けられたファイルの１つまたは複数に関連付けることができる。ＸＯＭＬファイルは、ユニフォームリソース識別子（ＵＲＩ）構文を介して上記の作成物を参照することができる。すべてのＸＯＭＬファイルは、そのファイルの名前、バージョン、識別、および記述を含むマニフェストを有する。ＸＯＭＬファイルのバージョンは、それが一部であるアセンブリに依存しない。ＸＯＭＬバージョンは、文書化のためである。プロセスのバージョニング、ＳＸＳ、リダイレクト等の真に実行に関連する面は、基本的にＣＬＲ方式である。
【０１９８】
【表１６】
2006107474.tif 000019
【０１９９】
付録Ｃ
ＸｏｍｌＳｅｒｉａｌｉｚｅｒクラス
アクティビティに関連付けられたシリアライザコンポーネントは、ＸｏｍｌＳｅｒｉａｌｉｚｅｒから継承する。ＸｏｍｌＳｅｒｉａｌｉｚｅｒは、アクティビティのためのデフォルトのシリアライザコンポーネントでもある。ＸｏｍｌＳｅｒｉａｌｉｚｅｒは、アクティビティプロパティを参照し、アクティビティプロパティを直列化する。複合アクティビティの場合、デフォルトのシリアライザコンポーネントはＣｏｍｐｏｓｉｔｅＸｏｍｌＳｅｒｉａｌｉｚｅｒであり、これは、プリミティブＸｏｍｌの直列化に加えて、子アクティビティも直列化する。
【０２００】
このクラスの関数はさらに、ｘｏｍｌファイルを直列化および非直列化するために使用されるパブリック関数、オブジェクトの直列化を制御するために使用される関数、およびオブジェクトの非直列化を制御するために使用される関数に分類されることができる。
【０２０１】
ｘｏｍｌファイルを直列化／非直列化するパブリック関数
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 sine object obj, XmlTextReader rd);
このメソッドは、単純なプロパティを非直列化するためにＤｅｓｅｒｉａｌｉｚｅＣｏｎｔｅｎｔｓ（）によって呼び出される。単純なプロパティは、そのオブジェクトの一部であり、ＸｍｌＴｅｘｔＲｅａｄｅｒがパラメータとして渡される。ＸｍｌＴｅｘｔＲｅａｄｅｒは、属性をポイントする。その属性の名前がプロパティの名前として扱われる。
【０２０８】
protected virtual void DeserializeCompoundProperty(IXomlSerializationManager sm, object obj, PropertyDescriptor pd, XmlTextReader rd);
このメソッドは、ＤｅｓｅｒｉａｌｉｚｅＣｏｎｔｅｎｔｓ（）によって呼び出されて複合プロパティを非直列化する。このメソッドには、オブジェクト、プロパティ記述子、およびＸｍｌＴｅｘｔＲｅａｄｅｒが渡される。ＸｍｌＴｅｘｔＲｅａｄｅｒは、ＸｍｌＥｌｅｍｅｎｔをポイントする。プロパティは、読み取り専用である場合も読み取り専用でない場合もある。プロパティが読み取り専用である場合は、そのプロパティのｇｅｔｔｅｒメソッドが呼び出されてオブジェクトを与え、そしてそのオブジェクトのＤｅｓｅｒｉａｌｉｚｅＣｏｎｔｅｎｔｓが呼び出されてオブジェクトの内容を非直列化する。プロパティが、読み取り−書き込みである場合は、そのプロパティは、１つのみの子要素を有することができる。最初の子要素が非直列化され、返されるオブジェクトがプロパティに設定される。
【０２０９】
オブジェクトの直列化
protected void SerializeObject(IXomlSerializationManager s, object o, XmlTextWriter 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 IList GetChildren(object obj);
このメソッドは、オブジェクトの子オブジェクトを得るために使用される。通例、オブジェクトは、異なる機構を使用して親子関係を記述する。一例として、ＩＣｏｍｐｏｓｉｔｅＡｃｔｉｖｉｔｙは、Ａｃｔｉｖｉｔｉｅｓプロパティを使用して子オブジェクトをプログラム的に表す。別のシリアライザがこのプロパティを無効にし、子オブジェクトのリストを返すことができる。デフォルトで、このメソッドは＜ｎｕｌｌ＞値を返す。
【０２１４】
protected virtual PropertyDescriptorCollection GetProperties(object obj);
このメソッドは、オブジェクトのプロパティを得るために使用される。デフォルトで、このメソッドは、Ｂｒｏｗｓａｂｌｅ属性が真に設定され、ＤｅｓｉｇｎｅｒＳｅｒｉａｌｉｚａｔｉｏｎＶｉｓｉｂｉｌｉｔｙ属性がＨｉｄｄｅｎに設定されていないプロパティを返す。オブジェクトのシリアライザコンポーネントは、このデフォルトのプロパティを無効にし、返されるプロパティの集まりを制御することができる。
【０２１５】
protected virtual void AddChild(object obj, object childObj);
このメソッドは、親オブジェクトの子を追加するために使用される。このメソッドは、ＧｅｔＣｈｉｌｄｒｅｎ（）の逆を行う。シリアライザコンポーネントは、ＡｄｄＣｈｉｌｄ（）実装の挙動をコントロールすることができる。
【０２１６】
protected virtual object Createlnstance(Type type, XmlTextReader rd);
このメソッドは、タイプのインスタンスを作成するために使用される。デフォルトで、このメソッドは、Ａｃｔｉｖａｔｏｒ．Ｃｒｅａｔｅｌｎｓｔａｎｃｅ（）を呼び出してオブジェクトを作成する。しかし、派生クラスは、各自のコンポーネントタイプのＣｒｅａｔｅｌｎｓｔａｎｃｅ（）に異なる技術を使用する可能性があり、また、ＸｍｌＴｅｘｔＲｅａｄｅｒオブジェクトを使用することによりコンストラクタのいくつかのパラメータを渡す場合もある。
【０２１７】
ＣｏｍｐｏｓｉｔｅＸｏｍｌＳｅｒｉａｌｉｚｅｒクラス
Ｃｏｍｐｏｓｉｔｅ  Ｘｏｍｌ  Ｓｅｒｉａｌｉｚｅｒは、複合アクティビティを直列化するために使用される。これは、子アクティビティを非直列化および直列化する、基本クラスから無効にされた２つのメソッドを有する。
【０２１８】
【表１７】
2006107474.tif 000020
【０２１９】
ＩＸｏｍｌＳｅｒｉａｌｉｚａｔｉｏｎＭａｎａｇｅｒインターフェース
ＩＸｏｍｌＳｅｒｉａｌｉｚａｔｉｏｎＭａｎａｇｅｒは、ＩＤｅｓｉｇｎｅｒＳｅｒｉａｌｉｚａｔｉｏｎＭａｎａｇｅｒクラスから継承する。これは、ｘｍｌ修飾された名前を与えられてアクティビティタイプを与える、およびその逆を行う追加的な関数を提供する。次に示すのは、ＩＸｏｍｌＳｅｒｉａｌｉｚａｔｉｏｎＭａｎａｇｅｒのインターフェース定義である。
【０２２０】
【表１８】
2006107474.tif 000021
【０２２１】
直列化エラー
Ｘｏｍｌシリアライザは、ＩＤｅｓｉｇｎｅｒＳｅｒｉａｌｉｚａｔｉｏｎＭａｎａｇｅｒ．ＲｅｐｏｒｔＥｒｒｏｒ（）メソッドを使用して、すべての非直列化エラーを追加する。非直列化でエラーが生じると、このメソッドは単にエラーオブジェクトを追加するが、ｘｍｌフォーマットが違法になるまで、かつ違法にならない限り、非直列化プロセスを停止しない。ＸｏｍｌＳｅｒｉａｌｉｚｅｒは、ＸｏｍｌＳｅｒｉａｌｉｚｅｒＥｘｃｅｐｔｉｏｎクラスを使用して非直列化エラーを報告する。
【０２２２】
【表１９】
2006107474.tif 000022
【０２２３】
ワークフローのコンポーネントモデルは、ウェブサービス記述言語（ＷＳＤＬ）フォーマットに合わせたスケジュールの直列化も提供する。シリアライザは、スケジュール中の型付けされた各チャネルのポートを含んだＷＳＤＬ文書を生成する。例示的なアルゴリズムは以下の通りである。
【０２２４】
−  スケジュールへのすべてのスコープ関与からすべての型付けチャネルをフェッチする
−  チャネルごとに
−  チャネルのインターフェースに基づいてＷＳＤＬポートタイプを作成する
−  ＷＳＤＬバインディングを作成し、ポートタイプに付加する
−  チャネルの名前に基づき、バインディングに付加されるＷＳＤＬポートを作成する
−  チャネルのインターフェース中の各メソッドについて、
−  ポートタイプ操作を作成する
−  入力メッセージ（部分はメソッドの引数）を作成し、操作に追加する
−  出力メッセージ（部分はメソッドのリターンタイプ）を作成し、操作に追加する
−  各メッセージ部分につき、
−  ＸＳＤ表現タイプを作成する
タイプのマッピングは、あるタイプをＸＳＤタイプに変換するＸｍｌＲｅｆｌｅｃｔｉｏｎＩｍｐｏｒｔｅｒクラス（Ｓｙｓｔｅｍ．Ｘｍｌ．Ｓｅｒｉａｌｉｚａｔｉｏｎ名前空間）を使用して行われる。各ＤｅｓｉｇｎＴｉｍｅＴｙｐｅは、ｘｍｌ．Ｓｅｒｉａｌｉｚａｔｉｏｎに渡される前に、ＲｕｎＴｉｍｅＴｙｐｅＥｍｉｔｔｅｒによってスタブ（ｓｔｕｂｂｅｄ）ランタイムタイプに変換される。
【０２２５】
ＷｓｄｌＯｐｔｉｏｎｓクラスは、直列化を設定し、ＩＳｅｒｉａｌｉｚｅｒＯｐｔｉｏｎｓから派生する。例示的なプロパティとその使用法を表Ｄ１に示す。
【０２２６】
【表２０】
2006107474.tif 000023
【０２２７】
ＷｓｄｌＳｅｒｉａｌｉｚｅｒクラスは、ＷＳＤＬの直列化を行う。例示的なクラスメンバを下の表Ｄ２に示す。
【０２２８】
【表２１】
2006107474.tif 000024
【０２２９】
ＲｕｎＴｉｍｅＴｙｐｅＥｍｉｔｔｅｒクラスは、タイプビルダを使用してＤｅｓｉｇｎＴｉｍｅＴｙｐｅをｒｕｎｔｉｍｅＴｙｐｅに変換する。例示的なメンバを下の表Ｄ３に示す。
【０２３０】
【表２２】
2006107474.tif 000025
【図面の簡単な説明】
【０２３１】
【図１】タスクと制御フロー複合アクティビティを含む例示的なワークフローの図である。
【図２】例示的なアクティビティの継承ツリーの図である。
【図３】例示的なコンポーネントモデルの図である。
【図４】例示的なコンポーネントモデルのライフサイクルを示す図である。
【図５】ワークフローを指定するためのウィザードに依拠する、ワークフローを作成するための高水準アプリケーションユーザインターフェースの図である。
【図６】例示的なワークフローデザイナの図である。
【図７】受信アクティビティとそれに続く送信アクティビティを含むオーケストレーションプログラムを表す図である。
【図８】グラフでオブジェクトの直列化を示す図である。
【図９】スケジュール定義、および、視覚的ワークフローと、ワークフローの直列化表現とワークフローのｃｏｄｅ  ｂｅｓｉｄｅとの関係を示す図である。
【図１０】本発明を実施することが可能な適切なコンピューティングシステム環境の一例を示すブロック図である。
【符号の説明】
【０２３２】
４０２  インターフェースコンポーネント
４０４  メタデータコンポーネント
４０６  直列化コンポーネント
４０８  妥当性検査コンポーネント
【図１】
2006107474.tif 000026
【図２】
2006107474.tif 000027
【図３】
2006107474.tif 000028
【図４】
2006107474.tif 000029
【図５】
2006107474.tif 000030
【図６】
2006107474.tif 000031
【図７】
2006107474.tif 000032
【図８】
2006107474.tif 000033
【図９】
2006107474.tif 000034
【図１０】
2006107474.tif 000035