(57)【要約】      （修正有）【課題】ワークフローモデリングに関し、容易に設計でき、実行時オーサリングが可能で柔軟性のあるコンポーネント化された拡張可能なワークフローモデルを構築する。【解決手段】エラーおよび例外処理をワークフロー内の選択されたアクティビティに適用する。選択された動作コンポーネントはアクティビティに関連付けられ、動作コンポーネントはこの関連付けられたアクティビティに応答して動作する。動作コンポーネントはルールを含み、これをアクティビティに適用する。【選択図】図１
2006107479.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-defined behavioral component）を選択することを含む。この方法は、さらに、ワークフロー内の１つまたは複数のアクティビティを選択することも含む。この方法は、さらに、選択された動作コンポーネントを選択されたアクティビティに関係付けて、選択された動作コンポーネントが選択されたアクティビティに応答して動作できるようにすることも含む。
【００１４】
本発明の他の態様によれば、１つまたは複数のコンピュータ読み取り可能媒体は、エラーおよび例外処理をワークフロー内の１つまたは複数の選択されたアクティビティに適用するためのコンピュータ実行可能モジュールを格納する。これらのモジュールは、定義済み動作コンポーネントを選択し、またワークフロー内の１つまたは複数のアクティビティを選択するためのデザイナモジュールを含む。これらのモジュールは、さらに、動作コンポーネントとデザイナモジュールにより選択されたアクティビティとを関係付けて、選択された動作コンポーネントが選択されたアクティビティに応答して動作できるようにするためのコンテキストモジュールも含む。これらのモジュールは、さらに、コンテキストモジュールによって関係付けられている動作コンポーネントに応じてデザイナモジュールにより選択されたアクティビティを実行するためのランタイムエンジンモジュールも含む。
【００１５】
本発明のさらに他の態様によれば、システムは、エラーおよび例外処理をワークフロー内の１つまたは複数の選択されたアクティビティに適用する。システムは、定義されたインターフェイスをそれぞれが有する複数のアクティビティを格納するメモリ領域を備える。メモリ領域は、さらに、それぞれ定義されたインターフェイスに適合する複数の動作コンポーネントを格納する。動作コンポーネントの各々は、アクティビティのうちの少なくとも２つに関係付けられる。システムは、さらに、メモリ領域内に格納されている動作コンポーネントの１つの選択をユーザから受け取るコンピュータ実行可能命令、メモリ領域内に格納されているアクティビティのうちの少なくとも２つの選択をユーザから受け取るコンピュータ実行可能命令、選択された動作コンポーネントに関連付けられているコンテキストを作成するコンピュータ実行可能命令、および作成されたコンテキスト内で選択されたアクティビティを実行するコンピュータ実行可能命令を実行するように構成されているプロセッサを備える。
【００１６】
それとは別に、本発明は、他のさまざまな方法および器具装置を含むことができる。
【００１７】
他の特徴は、一部は明白であり、また一部は以下で指摘される。
【発明を実施するための最良の形態】
【００１８】
本発明のいくつかの実施形態では、ビジネスプロセスなどのプロセスを表すワークフローをモデル化する。ビジネスプロセスとは、予測可能で再現可能な成果が得られる従属する、順序付けられたタスク、アクティビティなどのことである。組織の運営手順、制度に関する実務知識、および情報資源を含めて、ビジネスプロセスは、効率よく、時機を逃すことなく定義済みのビジネス目的を達成するように設計される。効率的な環境では、プロセスの機能コンポーネントは、絶え間なく変化する企業要件に対処するために、容易に識別し、適合し、展開することができる。ワークフローは、ビジネスプロセス内のタスクとやり取りするエンドユーザ体験である。タスクは、アクティビティ、コンポーネントなどとしてモデル化され、それぞれ人またはマシンにより実行される一単位の作業である。一実施形態では、複数のアクティビティが一人のユーザに提示される。ユーザは、ワークフローを作成する複数のアクティビティを選択して編成する。作成されたワークフローは、実行され、ビジネスプロセスをモデル化する。図１を参照すると、ワークフロー１００の実施例は、タスクおよび制御フロー複合アクティビティを含んでいる。
【００１９】
一実施例では、オーケストレーションエンジンワークフローモデルは、さまざまなクラスのワークフローのモデリング、オーサリング、および実行をサポートする。実施例は、整然とした順序で、または非同期イベントの集合として実行される構造化されたステップの集合に関して与えられた問題をモデル化することを含む。オーケストレーションエンジンは、スケジュールの実行を調整する。スケジュールは、ツリー構造で階層的に配列されたアクティビティの整理された集合である。実行アクティビティの実行コンテキストおよび実行アクティビティから見える共有データは、スコープにより規定される。それぞれのアクティビティは、ワークフロープロセス内のステップに対するメタデータをカプセル化するコンポーネントを表す。アクティビティは、ワークフローモデルでの実行の基本単位であり、関連付けられたプロパティ、ハンドラ、制約、およびイベントを持つ。それぞれのアクティビティは、任意のプログラミング言語のユーザコードにより構成することができる。例えば、ユーザコードは、共通言語ランタイム（ＣＬＲ）言語で書かれたビジネスもしくはアプリケーションロジックまたはルールを表すことができる。それぞれのアクティビティは、ユーザコードでの実行へのインターセプト前フックおよびインターセプト後フック（pre-interception hooks and post-interception hooks）をサポートする。それぞれのアクティビティは、関連付けられたランタイム実行意味論および動作（例えば、状態管理、トランザクション、イベント処理、および例外処理）を持つ。アクティビティは、他のアクティビティと状態を共有できる。アクティビティは、プリミティブなアクティビティであるか、または複合アクティビティにグループ化することができる。プリミティブつまり基本アクティビティは、下位構造（例えば、子アクティビティ）を持たず、したがって、ツリー構造内の葉ノードである。複合アクティビティは、下位構造を含む（例えば、これは、１つまたは複数の子アクティビティの親である）。
【００２０】
一実施形態では、アクティビティは、単純アクティビティ、コンテナアクティビティ、およびルートアクティビティの３種類がある。この実施形態では、モデルには１つのルートアクティビティがあり、ルートアクティビティの内側に単純アクティビティまたはコンテナアクティビティは全くないか、またはいくらかある。コンテナアクティビティは、単純またはコンテナアクティビティを含むことができる。ワークフロープロセス全体は、高位のワークフロープロセスを構築するアクティビティとして使用することができる。さらに、アクティビティは、中断可能であるか、または非中断可能とすることができる。非中断可能複合アクティビティは、中断可能アクティビティを含まない。非中断可能アクティビティには、アクティビティにブロックさせるサービスはない。
【００２１】
オーケストレーションエンジンは、アクティビティの集まりの例を示している。図２を参照すると、アクティビティ継承ツリーにアクティビティの実施例が示されている。図２に一覧として示されているアクティビティの実施例は、付録Ａで詳しく説明する。さらに、ユーザは、ワークフローモデルを拡張するために１つまたは複数のアクティビティを書くことができる。例えば、ユーザは、特定のビジネス問題、領域、ワークフロー標準（例えば、ビジネスプロセス実行言語）、またはターゲットプラットフォームに対するアクティビティを書くことができる。オーケストレーションエンジンは、例えば、コードを分析するサービス、タイプ解決およびタイプシステム、シリアライゼーションするサービス、およびレンダリングを含むアクティビティを書くためのさまざまなサービスの集合をユーザに提供することができる。
【００２２】
一実施形態では、それぞれのアクティビティは、メタデータ、インスタンスデータ、および実行ロジックの少なくとも３つの部分を持つ。アクティビティのメタデータは、構成することができるデータプロパティを定義する。例えば、いくつかのアクティビティは、アクティビティ抽象基本クラスで定義されているメタデータの共通集合を共有することができる。それぞれのアクティビティは、このクラスを拡張することによりそのニーズに応じて独自の追加メタデータプロパティを宣言する。
【００２３】
メタデータプロパティの値は、アクティビティが構成されたスケジュールのいくつかのインスタンスの範囲において、そのアクティビティのすべてのインスタンスにより共有される。例えば、ユーザがスケジュールＡを作成し、送信アクティビティをそれに追加した場合、送信アクティビティはそのメタデータの一部として識別情報（例えば、「００１」）を与えられる。スケジュールに追加される第２の送信アクティビティは、その独自の一意的な識別情報（例えば、「００２」）を受け取ることになる。スケジュールＡの複数のインスタンスが作成され、実行されると、送信「００１」のすべてのインスタンスはメタデータ値を共有する。対照的に、アクティビティのインスタンスデータは、実行スケジュールインスタンス内のアクティビティのインスタンスに特有のデータの集合を定義する。例えば、遅延アクティビティは、遅延アクティビティのタイムアウト値を表す日時値であるインスタンスデータに関する読み取り専用プロパティを与えることができる。この値は、遅延アクティビティが実行を開始した後利用可能になり、遅延アクティビティの１つ１つのインスタンスについて十中八九異なる。参照を「インスタンス」で修飾せずに、スケジュールのインスタンス、特にアクティビティおよびタスクのインスタンスを参照するのがふつうである。
【００２４】
複合アクティビティは、その子アクティビティの集合を他の要素として持つ。子アクティビティは、一実施形態ではメタデータと考えられる。オーケストレーションエンジンモデルでは、スケジュールのインスタンス内で実行時にこのメタデータを操作できることを明示している。新しい子アクティビティを実行スケジュールインスタンスの一部である複合アクティビティに追加し、そのスケジュールインスタンスに対するメタデータ（アクティビティツリー）のみが影響を受けるようにすることが可能である。
【００２５】
次に図３を参照すると、それぞれのアクティビティは、そのアクティビティに対するコンポーネントモデルを形成する関連付けられたコンポーネントの集合を持つ。関連付けられたコンポーネントの集合は、アクティビティエグゼキュータ（activity executor）、アクティビティデザイナ、アクティビティシリアライザ（activity serializer）、アクティビティバリデータ（例えば、意味チェッカー（semantic checker））、およびアクティビティコードジェネレータを含む。アクティビティエグゼキュータは、アクティビティに対する実行意味論を実装するステートレスコンポーネントである。アクティビティエグゼキュータは、アクティビティを実装するためのアクティビティのメタデータを操作する。コアスケジューラは、アクティビティエグゼキュータのサービスプロバイダとして機能し、アクティビティエグゼキュータにサービスを提供する。
【００２６】
アクティビティデザイナは、アクティビティ設計時のビジュアル表現を視覚的に表示する。アクティビティデザイナは、デザイナ階層内の１つのノードであり、テーマまたはスキンを作成して設定できる。アクティビティデザイナは、設計環境（例えば、アプリケーションプログラム）でホスティングされ、サービスを介してホスト設計環境とやり取りする。アクティビティバリデータでは、コンパイル時だけでなく実行時にもアクティビティ意味論を課す。アクティビティバリデータは、ワークフローモデルのコンテキストに作用し、環境が提供するサービス（例えば、コンパイラ、デザイナ、またはランタイム）を使用する。妥当性検証は、ワークフローのライフサイクルの各時点で実行される。構造準拠検査は、ワークフローのシリアライゼーション表現を作成するときに、コンパイルするときに、およびユーザの要求に対する応答として実行される。意味検査は、コンパイル時に実行するよりも実行時の方が強く、このため実行インスタンスのアクティビティツリー内のアクティビティの追加または置換などの実行時オペレーションの安全性を保証することができる。本発明では、例えば、定義済みインターフェイス要件への適合または準拠に関してアクティビティのそれぞれに関連付けられた意味論を評価する。
【００２７】
アクティビティシリアライザは、アクティビティのメタデータをシリアライゼーションするコンポーネントである。アクティビティシリアライザは、さまざまなモデル／フォーマットシリアライザから呼び出される。ワークフローモデル全体が、拡張可能スキーマに基づいて宣言的マークアップ言語内にシリアライゼーションされ、さらに、望むとおりに他のワークフロー言語に変換することができる。
【００２８】
一実施形態では、アクティビティのコンポーネントモデルは、コンピュータ読み取り可能媒体上にデータ構造体として格納される。データ構造体において、アクティビティデザイナは、アクティビティを視覚的に表現するためデータ（例えば、アイコン）を格納する画像フィールドにより表される。さらに、１つまたは複数の作者時刻フィールドでは、アクティビティに関連付けられているプロパティ、メソッド、およびイベントを定義するメタデータを格納する。アクティビティシリアライザは、作者時刻フィールドに格納されているメタデータをアクティビティの宣言的表現に変換するためのデータを格納するシリアライザフィールドにより表される。アクティビティジェネレータは、作者時刻フィールドに格納されているメタデータに関連付けられているソフトウェアコードを格納するビジネスロジックフィールドにより表される。アクティビティエグゼキュータは、ビジネスロジックフィールドに格納されているソフトウェアコードを実行するためのデータを格納するエグゼキュータフィールドにより表される。
【００２９】
（スコープとスケジュール）
実行アクティビティの実行コンテキストおよび実行アクティビティから見える共有データは、スコープにより規定される。スコープとは、コアアクティビティのうちの１つである。スコープは、変数および長時間実行しているサービスの状態をトランザクション意味論、エラー処理意味論、補正、イベントハンドラ、およびデータ状態管理とともにひとまとめにするための統一言語構文である。スコープは、関連付けられた例外およびイベントハンドラを持つことができる。一実施形態では、スコープは、トランザクション、アトミック、長時間実行、または同期化のスコープとすることができる。ユーザ変数に対するｒｅａｄ−ｗｒｉｔｅまたはｗｒｉｔｅ−ｗｒｉｔｅ  アクセスが衝突する場合にユーザのために同時実行制御が用意される。スコープは、さらに、トランザクション境界、例外処理境界、および補正境界でもある。スコープはスケジュール内でネストすることができるので、さらに、名前が衝突することなく異なるスコープ（スコープがネストしているとしても）内で同じ名前により変数、メッセージ、チャネル、および相関関係集合を宣言することが可能である。
【００３０】
スケジュール内にネストされているスコープは、そのスケジュールのコンテキスト内でのみ実行可能である。スケジュールは、アプリケーション（例えば、スタンドアロンの実行可能エンティティ）として、またはライブラリ（例えば、他のスケジュールから呼び出すため）としてコンパイルすることができる。ライブラリとしてコンパイルされたスケジュールはすべて、実際に、他のスケジュール内から呼び出すことができる新しいアクティビティ型を構成する。スケジュールのメタデータは、パラメータの宣言を含む。
【００３１】
スケジュールが作成された後、作成されたスケジュールのインスタンスを実行できる。スケジュールインスタンスをアクティブにし、制御するプロセスは、オーケストレーションエンジンが埋め込まれているホスト環境に応じて異なる。オーケストレーションエンジンは、スケジュールをテストするために使用できる余計な機能のない「単純なホスト」を提供する。さらに、オーケストレーションエンジンは、サービス環境（つまり、ホスト）とやり取りするため、エンジンおよび外部アプリケーションにより同様に使用される「サービスプロバイダ」モデル（例えば、アプリケーションプログラミングインターフェイス）の標準化を推進するアクティベーションサービスを提供する。アクティベーションサービスは、特定のスケジュール型のスケジュールインスタンスを作成し、その際に、任意選択で、パラメータを受け渡す。スケジュールインスタンスは、本質的に、実行スケジュールインスタンスのプロキシであり、インスタンス、スケジュールのメタデータ（アクティビティツリー）への参照、およびインスタンスのサスペンド、レジューム、および終了を実行するメソッドを一意に識別する識別子を含む。アクティベーションサービスは、さらに、与えられたスケジュールインスタンス識別子に基づいてスケジュールインスタンスを見つける操作もサポートする。
【００３２】
（コードビサイド）
スコープアクティビティは、スコープアクティビティのビジネスロジックを含む関連するコードビサイドクラスを持つことができる。スケジュールはそれ自体スコープであるため、スケジュールはコードビサイドクラスも持つことができる。スケジュール内にネストされているスコープも、それ独自のコードビサイドクラスを持つことができる。スコープ内でネストされているアクティビティは、共有データ状態およびビジネスロジックのコンテナとして働くスコープのコードビサイドクラスを共有する。例えば、コードアクティビティのメタデータは、コードビサイド内に特定のシグネチャを持つメソッドへの参照を含む。他の実施例では、送信アクティビティのメタデータは、特定のシグネチャのコードビサイドメソッドへのオプションの参照に加えてメッセージ宣言およびチャネル宣言への必須参照を含む。
【００３３】
コードビサイドの使用例としては、変数、メッセージ、チャネル、および相関関係集合の宣言、ｉｎ／ｏｕｔ／ｒｅｆパラメータの宣言、追加カスタムプロパティの宣言、送信するメッセージの準備、受信されたメッセージの処理、論理値を返すコードで表現されたルールの実装、ローカルで定義されている変数の操作、アクティビティメタデータおよびインスタンスデータの読み取り、アクティビティインスタンスデータの書き込み（例えば、実行されようとしているアクティビティに関するプロパティの設定）、イベントの発生、例外のスロー、横断的なネストされているスコープおよびスケジュール呼び出し境界を含む実行スケジュールインスタンスのアクティビティツリー内のアクティビティの階層の列挙およびナビゲート、実行スケジュールインスタンス内で複合アクティビティへの新規アクティビティの追加、実行スケジュールインスタンス内のアクティビティに関連付けられている宣言的ルールの変更、ならびに他の実行スケジュールインスタンスへの参照の取得および他の実行スケジュールインスタンスの操作が挙げられる。
【００３４】
（動作コンポーネント）
本発明のオーケストレーションエンジンを使用することで、開発者は、複数のワークフローアクティビティにまたがる動作に関する分野横断的直交問題（cross-cutting orthogonal concerns）をモデル化することができる。分野横断的または複雑に絡み合った問題の例として、トランザクション（例えば、分散トランザクションコーディネータおよび長時間実行）、同時実行、追跡、永続性、エラー処理、ロギングなどがある。動作コンポーネントをワークフロープロセスモデリングに適用することにより、高度なプロセスモジュール化が可能になり、再利用可能な、きわめて軽快な、反応ワークフロープロセスを構築することができる。システムレベルの問題（例えば、プロセス監視、追跡、永続性、トランザクション、および同期）だけでなく、宣言的基準および／または実行中プロセスの状態に基づいてビジネスレベルの問題（例えば、サービス品質基準に基づいて動的にＷｅｂサービスを選び、ビジネスコントラクトなどを履行するため実行中プロセスの実行ステップの集合を条件付きでスキップし、置き換え、やり直し、追加し、または削除する）をも客観化するのに役立つ。
【００３５】
動作コンポーネントを適用することで、より優れたモジュール化モデルが得られ、プログラムまたはコンポーネントベースシステムを横断する入り組んだ問題を分離しやすくなる。分野横断的問題は、動作コンポーネントと呼ばれるモジュール性境界内に捕捉される。動作コンポーネントは、分野横断的機能を備える。一般に、プログラムされる２つのプロパティが異なる形で構成されなければならず、それでも調整される場合、それらのプロパティは互いに横断する。実装されるプロパティは、きれいにカプセル化されるか、または他の何らかの方法できちんとローカライズされ、容易にアクセスでき、一般化されたプロシージャ（例えば、オブジェクト、メソッド、プロシージャ、ＡＰＩ）で必要に応じて構成することができる場合にコンポーネントとして定義される。一実施例では、コンポーネントは、画像フィルタ、銀行口座、グラフィカルユーザインターフェイスウィジェット、またはワークフローモデル内のステップなどのシステムの機能分割の単位である。
【００３６】
複数のワークフローアクティビティにまたがる分野横断的問題は、ワークフロー動作コンポーネントとして表すことができる。ワークフロー動作コンポーネントは、宣言的モジュール性コンストラクトとしてみなすことができる。動作コンポーネントは、ワークフローアプリケーションまたはアプリケーションの一部分上に重ね合わされる。これらは、図式化され、宣言的方法で記述されるという点で宣言的である。
【００３７】
トランザクション、同期、および例外処理は、複合アクティビティとしてモデル化されるのに不向きな動作特性／問題のいくつかの例である。これらは、複数のアクティビティおよびビジネスロジックにまたがり、分野横断的な直交問題である。これらは、基本的に追跡、ロギング、およびトレースなどの他の問題のように本質的に分野横断的である。モデリングルールの例としては、実行ロジックがコンポーネントとしてきれいにカプセル化できる場合に任意の実行ロジックをアクティビティとして表すこと、および意味論が複数のアクティビティまたはコンポーネントの集合にまたがる場合に動作問題を動作コンポーネントとして表すことが挙げられる。
【００３８】
動作コンポーネントおよびアクティビティは、それらのコンポーネントモデルに関する類似性を共有する。それぞれの動作コンポーネントは、アクティビティのように、そのメタデータをプロパティ、メソッド、およびイベントに関して宣言的に記述する。さらに、それぞれの動作コンポーネントは、関連付けられたデザイナ、シリアライザ、およびランタイムコンポーネントを持つ。しかし、実際に動作／意味論を実装するランタイムコンポーネントは、一実施形態ではアクティビティエグゼキュータと同一でない。例えば、スケジューラと動作コンポーネントエグゼキュータとの間のインターフェイスコントラクトは、アクティビティエグゼキュータと異なる。
【００３９】
動作コンポーネントの実施例は、エラー処理、例外処理、およびメッセージ送受信のうちの１つまたは複数に関係する。例えば、動作コンポーネントは、スコープコンポーネントおよびプロセスコンポーネントを含むことができる。スコープコンポーネントは、プロセス分析、状態管理、トランザクション、同期、および例外エラー処理のうちの１つまたは複数に関係する。プロセスコンポーネントは、トランザクション処理、同期、および例外エラー処理のうちの１つまたは複数に関係する。
【００４０】
動作コンポーネントは、複数のアクティビティ境界にまたがる分野横断的問題を表す。アクティビティは、動作コンポーネント内に置かれ、この配置のおかげで、動作コンポーネントの動作を継承する。例えば、アクティビティがアトミックトランザクション動作コンポーネント内に置かれている場合、これは実行時にＡＣＩＤ意味論を継承する。さらに、ＤＴＣトランザクションは、実行時に渡されるコンテキスト内で利用可能でもある。
【００４１】
一実施形態では、アクティビティは、複数の動作コンポーネントに加わる。特に、アクティビティは、コンテキストと呼ばれる動作コンポーネントの集合の合併の中で存続する。コンテキストは、１−ｎ動作コンポーネントを含む集合の合併により定義される領域である。すべての動作コンポーネントは、コンパイル時に自分自身の妥当性確認を行うよう求められる。これはコンテキストを受け取り、このコンテキストから、他の兄弟関係にある態様、コンテキストに含まれるアクティビティなどのすべてのリストを取得できる。妥当性検査およびエラー伝搬は、アクティビティの場合のものと類似している。
【００４２】
実行時に、スケジューラは、コンテキストの動作コンポーネントエグゼキュータのそれぞれに対し、動作コンポーネントがサポートする動作を解釈し、実装する機会を与える。一実施形態では、アクティビティの実行時に以下のオペレーションが実行される。
【００４３】
−スケジューラは、オブジェクトモデルを読み込むことによりオンデマンドで適切な態様を作成する。
【００４４】
−スケジューラは、動作コンポーネント（ＢｅｈａｖｉｏｒａｌＣｏｍｐｏｎｅｎｔＥｘｅｃｕｔｏｒ．ＧｅｔＳｅｒｖｉｃｅ（））に依頼し、それをＳｅｒｖｉｃｅ  Ｃｏｎｔａｉｎｅｒにプッシュすることにより適切なサービスを作成する。
【００４５】
−スケジューラは、ＢｅｈａｖｉｏｒａｌＣｏｍｐｏｎｅｎｔＥｘｅｃｕｔｏｒ．Ｌｏａｄ（）を呼び出して、動作コンポーネントに自己初期化の機会を与える。
【００４６】
−スケジューラは、Ａｃｔｉｖｉｔｙが置かれるコンテキストの動作コンポーネント毎にＰｒｅＰｒｏｃｅｓｓ（）を呼び出して、その後ＡｃｔｉｖｉｔｙＥｘｅｃｕｔｏｒ．Ｅｘｅｃｕｔｅ（）を呼び出してＣｏｎｔｅｘｔＳｅｒｖｉｃｅを受け渡す。
【００４７】
−スケジューラは、飲み込む側の動作コンポーネントのそれぞれについてＢｅｈａｖｉｏｒａｌＣｏｍｐｏｎｅｎｔＥｘｅｃｕｔｏｒ．ＰｏｓｔＰｒｏｃｅｓｓを呼び出す。
【００４８】
−スケジューラは、飲み込む側の動作コンポーネントのそれぞれについてＡｓｐｅｃｔＥｘｅｃｕｔｏｒ．Ｕｎｌｏａｄを呼び出す。
【００４９】
図４を参照すると、ブロック図はコンポーネントモデルのライフサイクルの例を示す。ユーザは、１つまたは複数のコンピュータ読み取り可能媒体上に格納されているコンピュータ実行可能モジュールを対話形式で操作し、エラーおよび例外処理をワークフロー内の１つまたは複数の選択されたアクティビティに適用する。コンピュータ実行可能モジュールは、パレットモジュール４０８、デザイナモジュール４０２、コンテキストモジュール４０４、およびランタイムエンジンモジュール４０６を含む。ユーザは、パレットモジュール４０８を対話形式で操作し、動作コンポーネントを定義する。動作コンポーネントは、動作コンポーネントの機能を記述したユーザ編集可能なメタデータを含む。ユーザは、デザイナモジュール４０２（例えば、ユーザインターフェイス）を対話形式で操作して、定義済み動作コンポーネントを選択し、ワークフロー内の１つまたは複数のアクティビティを選択する。ユーザは、さらに、コンテキストモジュール４０４を対話形式で操作し、動作コンポーネントとデザイナモジュール４０２を介して選択されたアクティビティとを関係付けて、選択された動作コンポーネントが選択されたアクティビティに応答して動作できるようにする。つまり、デザイナモジュール４０２を使用することにより、選択された動作コンポーネントは、選択されたアクティビティの実行に応答してオペレーションを実行することができる。例えば、選択された動作コンポーネントは、選択されたアクティビティのうちの１つによりスローされた例外またはエラーを捕捉することができる。一般に、選択された動作コンポーネントは、選択されたアクティビティからの出力への応答としてオペレーションを実行する。ユーザは、ランタイムエンジンモジュール４０６を対話形式で操作し、コンテキストモジュール４０４によってそれに関係付けられている動作コンポーネントに応じてデザイナモジュール４０２を介して選択されたアクティビティを実行する。ランタイムエンジンモジュール４０６は、選択された動作コンポーネントと連携して選択されたアクティビティを実行する。例えば、ランタイムエンジンモジュール４０６は、選択された動作コンポーネントに関連付けられたコンテキストを作成し、作成されたコンテキスト内で選択されたアクティビティを実行する。一実施形態では、動作コンポーネントは、１つまたは複数のルールを含み、選択された動作コンポーネントは、ルールを選択されたアクティビティに適用する。
【００５０】
本発明は、さらに、動作コンポーネントが適用されるアクティビティのカスタマイズもサポートする。一実施例では、本発明は、それに関連付けられた１つまたは複数の意味論を持つユーザ定義アクティビティをユーザから受け取るステップと、定義済みインターフェイス要件に適合しているかどうかを調べるため意味論を評価するステップと、その評価結果に応じてランタイムエンジンモジュール４０６により作成されたコンテキスト内で受け取ったユーザ定義アクティビティを実行するステップとを含む。
【００５１】
図４に示されているようなシステムでは、メモリ領域は、定義済みインターフェイスをそれぞれ備える複数のアクティビティおよび定義されているインターフェイスにそれぞれ適合する複数の動作コンポーネントを格納する。動作コンポーネントはそれぞれ、アクティビティの１つまたは複数に関係付けられる。メモリ領域は、さらに、動作コンポーネントのそれぞれに対するデータ構造体（例えば、コンポーネントモデル）を格納する。データ構造体の実施例は、プロパティ、メソッド、イベント、デザイナ、シリアライザ、および／またはランタイムコンポーネントを含む。さらに、システムは、メモリ領域内に格納されている動作コンポーネントの１つの選択をユーザから受け取るコンピュータ実行可能命令、メモリ領域内に格納されているアクティビティのうちの少なくとも２つの選択をユーザから受け取るコンピュータ実行可能命令、選択された動作コンポーネントに関連付けられているコンテキストを作成するコンピュータ実行可能命令、および作成されたコンテキスト内で選択されたアクティビティを実行するコンピュータ実行可能命令を実行するように構成されているプロセッサを備える。
【００５２】
１つまたは複数のコンピュータ読み取り可能媒体は、本明細書で説明されているメソッドを実行するコンピュータ実行可能命令を格納する。
【００５３】
（ワークフローステンシル（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)
【００６３】
一実施例において、ユーザは、スケジュールを作成し、それをアクティビティとしてコンパイルする。コンパイルに成功すると、スケジュールはツールボックス上に表示される。ユーザは、コンパイルされたスケジュールの使用が望ましいスケジュールを開くか、または作成する。ユーザは、ツールボックスからコンパイル済みスケジュールをドラッグ＆ドロップする。縮小されたスケジュールデザイナがデザインサーフェスに示される。ユーザがドロップされたコンパイル済みスケジュールのコンテンツを表示したい場合、ユーザはそのスケジュールデザイナを展開して、呼び出されたスケジュールのコンテンツを読み取り専用状態でインライン表示する。呼び出されたスケジュールのインライン化により、ユーザはスケジュールデザイナ同士を切り換えなくても呼び出されたスケジュールを表示することができる。この機能は、既存のスケジュールを再利用して上位スケジュールを作成する開発者に有用な機能である。
【００６４】
（テーマ／スキンを使用したデザイナフレームワークのカスタマイズのサポート）
デザイナフレームワークを使用して書かれたワークフローデザイナは、ワークフローテーマを使用してカスタマイズすることができる。これらは、デザイナのさまざまな態様を宣言的に記述する拡張マークアップ言語（ＸＭＬ）ファイルとすることができる。ワークフローデザイナは、アクティビティを拡張するパートナのサポートをウィザードで対応している。ワークフローデザイナによりサポートされるユーザインターフェイス機能の例として、限定はしないが、元に戻す／繰り返し、ドラッグ／ドロップ、切り取り／コピー／貼り付け、ズーム、パン、検索／置換、ブックマーク、装飾、妥当性検証エラー用のスマートタグ、アクティビティ用の有効なドロップターゲットインジケータ、自動レイアウト、ビューページ付け、ナビゲーションマーカー、ドラッグインジケータ、ヘッダ／フッタ付き印刷およびプレビュー、およびドキュメントアウトライン統合がある。ワークフローデザイナは、ＸＭＬメタデータを使用してデザイナのルック＆フィールをカスタマイズできるカスタムデザイナテーマ／スキンをサポートする。ワークフローデザイナでは、バックグラウンドコンパイルをサポートする。一実施例では、スケジュールを設計しながら妥当性検証エラーを調べるスマートタグおよびスマートアクションが用意される。ワークフローデザイナは、任意のコンテナ（例えば、アプリケーションプログラム、シェルなど）でホスティングすることができる。
【００６５】
オーケストレーションエンジンプログラムの一実施例は、送信アクティビティが後に続く受信アクティビティを含む。このプロセスでは、メッセージを受信し、それを送出する。ユーザは、「Ｈｅｌｌｏ  Ｗｏｒｌｄ」と呼ばれるプロジェクトを作成し、オーケストレーションアイテムをプロジェクトに追加する。ユーザは、その後、スコープアクティビティをデザインサーフェス上にドラッグ＆ドロップする。次に、ユーザは、送信アクティビティが後に続く受信アクティビティをスコープ上にドロップする。図６は、デザイナ内の結果として得られるワークフロー７００を例示している。それぞれのアクティビティデザイナは、オブジェクトモデル上のユーザインターフェイス表現を提供する。開発者は、オブジェクトモデルを直接プログラムして、アクティビティのプロパティを設定するか、またはデザイナを使用することができる。オーケストレーションエンジンデザイナを使用することにより、開発者はツールボックスからアクティビティを選択し、それをデザイナサーフェス上にドラッグすることができる。アクティビティがすでにスケジュールに入れられており、移動する必要がある場合、開発者は、それを選択して（それをクリックすることにより）、そのアクティビティを入れる必要のあるスケジュールの領域にドラッグすることができる。開発者がコントロールキーを押しながらドラッグ＆ドロップを行うと、選択されたアクティビティのコピーが作成される。
【００６６】
アクティブな配置では、可能なドロップポイント（ターゲット）をデザインサーフェス上にビジュアルインジケータとして用意する。自動スクロール機能も、ドラッグ＆ドロップのコンテキスト内で関与する。大きなスケジュールを取り扱う場合、現在ビューポート内にないデザイナの領域へのナビゲーションは、入れるスケジュールの領域に向かってアクティビティをドラッグすることによりアクセス可能である。
【００６７】
ドラッグ＆ドロップは、同じプロジェクト内のスケジュール間で、また同じソリューション内の他のプロジェクト内のスケジュール間でサポートされる。アクティビティがデザインサーフェス上に配置された後、開発者はそのアクティビティの構成を設定する。各アクティビティは、スケジュールが有効なものとなるように開発者が構成する一連のプロパティを持つ。これらのプロパティは、プロパティブラウザで編集可能である。すべてのアクティビティは、プロパティブラウザ内にどのようなプロパティを表示できるかを制御する。開発者がさまざまなアクティビティを構成するのを補助するため、デザイナは、さまざまなダイアログまたは「サブデザイナ」を備えている。ダイアログの各々は、アクティビティのさまざまなプロパティについて呼び出される。
【００６８】
オーケストレーションエンジンは、ツールボックス内に提示されるアクティビティをカスタマイズすることができる。開発者がカスタムアクティビティまたはスケジュールを作成する場合、最終結果はアセンブリである。ダイアログを使用することにより、開発者は、アセンブリロケーションに移動してブラウズし、そのアセンブリを選択してオーケストレーションエンジンアクティビティとして現れるようにすることができる。それとは別に、開発者は、オーケストレーションエンジンのインストールパス内にそのアセンブリを置くことができ、オーケストレーションエンジンアクティビティとして存在することになる。
【００６９】
（アプリケーションプログラミングインターフェイス（ＡＰＩ））
他の実施形態では、本発明は、さまざまなワークフローオペレーションを実行するためのアプリケーションプログラミングインターフェイス（ＡＰＩ）を備える。本発明は、ワークフローをオーサリングするためのデザインアプリケーションプログラミングインターフェイスを含む。デザインアプリケーションプログラミングインターフェイスは、ワークフローをオーサリングする手段およびアクティビティのうちの１つまたは複数を選択してワークフローを作成する手段を備える。本発明は、さらに、デザインアプリケーションプログラミングインターフェイスを介してオーサリングされたワークフローをコンパイルするためのコンパイルアプリケーションプログラミングインターフェイスも含む。コンパイルアプリケーションプログラミングインターフェイスは、ワークフローをシリアライゼーションする手段、ワークフローの視覚的な表示をカスタマイズする手段、デザインアプリケーションプログラミングインターフェイスを介してオーサリングされたワークフローをコンパイルする手段、ワークフローの妥当性確認を行う手段を含む。
【００７０】
本発明は、さらに、型をワークフロー内のアクティビティのそれぞれに関連付けるためのタイププロバイダアプリケーションプログラミングインターフェイスも含む。タイププロバイダアプリケーションプログラミングインターフェイスは、型をワークフロー内のアクティビティのそれぞれに関連付ける手段および型をワークフロー内のアクティビティのそれぞれに関連付ける手段を含む。
【００７１】
１つまたは複数のアプリケーションプログラミングインターフェイスは、ワークフローをオーサリングする手段の実施例、アクティビティの１つまたは複数を選択してワークフローを作成する手段の実施例、ワークフローをシリアライズする手段の実施例、ワークフローの視覚的表示をカスタマイズする手段の実施例、ワークフローの妥当性確認を行う手段の実施例、ワークフローをコンパイルする手段の実施例、および型をワークフロー内のアクティビティのそれぞれに関連付ける手段の実施例を含む。
【００７２】
（アクティビティ実行フレームワーク）
スケジュールおよびスコープを除き、エンジンは、アクティビティを抽象エンティティとして表示し、特定のアクティビティの特定のデータまたは意味論を知らずにアクティビティの実行を簡単に調整する。一実施形態では、４つのエンティティは、アクティビティ自体、実行中のアクティビティの親アクティビティ、実行中のアクティビティを取り囲むスコープ、およびオーケストレーションエンジンの実行中にやり取りをする。それぞれのエンティティは異なる関数を持つ。
【００７３】
完了をアクティビティコーディネータに知らせることなくアクティビティの実行メソッドが戻る場合、そのアクティビティは、論理的待ち状態にあると識別される。このようなアクティビティは、オーケストレーションエンジンによりキャンセルするか、または継続することができる（例えば、待っているアイテムまたはイベントが利用可能になるか、または実行され、エンジンによりこれにアクティビティが通知された後）。
【００７４】
論理的待ち状態に決して入らないいくつかのアクティビティは、決してキャンセルできない。実施例は、送信アクティビティおよびコードアクティビティを含むが、これらは外部イベントまたはサブスクリプションへの要求なしで実行されるからである。スレッドを渡された後（つまり、実行メソッドがオーケストレーションエンジンにより呼ばれた後）、これらのアクティビティは完了するまで動作し続ける。完了を通知するまでスレッドを返さないので、オーケストレーションエンジンにはキャンセルする機会が決して与えられない。
【００７５】
オーケストレーションエンジンのランタイムは、ルールを使用して、オーケストレーションエンジンアクティビティが実行されるイベントをトリガする。オーケストレーションエンジンデザイナは、関連付けられたルールを実行時に評価し、イベントを取り出するユーザ機能を提供する。オーケストレーションエンジンデザイナを利用することで、ユーザは、拡張性アーキテクチャを用意することによりさまざまな種類のルール技術を使用できる。デザイナは、使用されるルールの型には関知しない。
【００７６】
一実施形態では、デザイナは、ルールをアクティビティに関連付ける手段として論理式ハンドラをサポートしている。これは、ユーザコードファイル内で、ユーザが真または偽の値を返すメソッドを書くことを意味し、それに基づいてルールがトリガされる。現在、Ｉｎｆｏ  ＡｇｅｎｔおよびＢｕｓｉｎｅｓｓ  Ｒｕｌｅｓ  Ｅｎｇｉｎｅ（ＢＲＥ）を含むルールを評価するために使用することもできる複数の技術がある。これを達成するために、デザイナは、ルール技術開発者がデザイナでカスタムユーザインターフェイスをホスティングできるようにする拡張性アーキテクチャを備える。デザイナは、コードステートメントコレクションの形でルールをシリアライゼーションするカスタムユーザインターフェイスライター向けの手段を用意している。デザイナは、コードステートメントコレクションが中に挿入されているユーザコードファイル内にブールハンドラを生成し出力する。オーケストレーションエンジンは、ルールライターにより使用することもできる既定のユーザインターフェイスを含む。ルール技術プロバイダは、カスタムルール宣言を作成し、そのカスタムルール宣言に関連付けられたユーザインターフェイスタイプエディタを書き、ルールユーザインターフェイスをホスティングするカスタムユーザインターフェイスを作成し、保存後にコードステートメントを生成することによりオーケストレーションエンジンデザイナにルールを追加する。
【００７７】
一実施例では、ユーザは、ルールがアタッチされる必要のあるアクティビティデザイナを選択し、プロパティブラウザでルールプロパティを特定し、ドロップダウン内の「ＲｕｌｅＥｘｐｒｅｓｓｉｏｎＨａｎｄｌｅｒ」を選択し（「Ｓｔａｔｅｍｅｎｔｓ」プロパティがユーザインターフェイス内のＲｕｌｅ  Ｐｒｏｐｅｒｔｙの下に表示されるようにする）、「Ｓｔａｔｅｍｅｎｔｓ」プロパティ内のユーザコードメソッド名を指定し、ユーザインターフェイスタイプエディタを呼び出してルール特有のユーザインターフェイスをホスティングするダイアログを呼び出し、新しい述語行を作成しそれらをグループ化することによりダイアログ内でルールを定義する。ユーザインターフェイスは、ユーザコードファイルにメソッドを生成して出力する。メソッド名は、プロパティブラウザでユーザが指定したのと同じものである。ルールを作成することに相当するコードステートメントが、ルール用のユーザコードメソッド内に挿入される。
【００７８】
（実行時のメッセージング）
実行ワークフローでは、スケジュールに送られるメッセージは、特定のスケジュールインスタンス向けである。例えば、発注書＃１２３に対するインボイスをその発注書を発信した（例えば、送出した）のと同じスケジュールインスタンスに送り返さなければならない。受信メッセージと適切なスケジュールインスタンスとを照合するために、メッセージおよびスケジュールインスタンスは相関関係集合を共有する。相関関係集合は、メッセージ内の識別子フィールドがスケジュールインスタンスにより保持される同じ型の識別子と突き合わせて照合されることを意味する一価相関関係集合でよい。多プロパティ相関関係集合も可能であり、データベーステーブル内の複数列主キーに類似している。
【００７９】
スケジュールインスタンスにより保持されている相関関係集合の値は、スケジュールインスタンスがメッセージを送出するか（例えば、値は送信発注書の識別子フィールドから取り出せる）、またはメッセージを受信するときに初期化される。その後、この相関関係集合値は、そのスケジュールインスタンスの状態の一部となる。後続の受信メッセージが到着すると、スケジュールインスタンス状態で保持されている相関関係集合値は、予想される型の受信メッセージにより保持されている識別子と突き合わせて照合される。一致が見つかった場合、相関関係集合は満たされ、メッセージがスケジュールインスタンスに配送される。
【００８０】
相関関係集合の実装はオーケストレーションエンジンおよびホスト環境に左右されるが、一実施形態では、ユーザは相関関係集合を宣言してスケジュールインスタンスを正しく動作するようにする。他の実施形態では、いくつかのアクティビティ（例えば、ＳｅｎｄＲｅｑｕｅｓｔ／ＲｅｃｅｉｖｅＲｅｓｐｏｎｓｅアクティビティおよびＲｅｃｅｉｖｅＲｅｑｕｅｓｔ／ＳｅｎｄＲｅｓｐｏｎｓｅアクティビティ）は、ユーザと無関係に相関関係集合をセットアップする。送信および受信アクティビティにより広範にわたる妥当性チェックが実行され、相関関係集合が正しく初期化され、追随されるようにする。
【００８１】
（実行ワークフローの動的編集）
オーケストレーションエンジンは、さまざまな種類のワークフローをオーサリングする（そして、その後、ビジュアル化し、実行する）ためのフレームワークを提供する。実施例としては、ｅｖｅｎｔ−ｃｏｎｄｉｔｉｏｎ−ａｃｔｉｏｎ（ＥＣＡ）スタイルのワークフローまたは構造化フローまたはルール駆動フローがある。さらに、ワークフローのモデル化方法に関係なく、フレームワークにより、ユーザは設計時と同じ方法で、またはワークフロープロセスを再コンパイルしなくてもワークフロープロセスが実行しているときであってもワークフローをオーサリングまたは編集することができる。フレームワークを使用すると、ユーザはランタイムと高忠実度の設計時表現との間のラウンドトリッピングが可能になる。アドホックな変更は、プロセスモデルに対し実行時に加えられる変更である。ユーザは、そのスケジュールモデルを実行インスタンスに問い合わせ、モデルに変更を加えることができる。例えば、ユーザは、バッチ式でアクティビティの追加、削除、または置換を行うことができ、その後、バッチ変更をコミットまたはロールバックすることができる。一実施形態では、モデルは更新の後に妥当性確認が行われる。本発明の多くのワークフローシナリオでは、「設計時オーサリング」および「ランタイム実行」との間の分離のぼかし、またはさらには除去がある。
【００８２】
スケジュールインスタンスは、実際に、それらのインスタンスのスケジュール型について定義されているアクティビティ型（メタデータ）ツリーを他のインスタンスと共有する。しかし、スケジュールインスタンスは、実行を開始した後、新しいアクティビティの追加または宣言的ルールの操作を介してオンザフライで変更できる。そのような修正されたスケジュールインスタンスを取り出し、新しいスケジュール型として「名前を付けて保存」するか、またはより一般的に、インスタンスからシリアライゼーションされた表現を単純に復元することが可能である。つまり、実行スケジュールインスタンスを、シリアライゼーションし、その後、デザイナ（例えば、オーサリング環境）またはランタイムビジュアル化ツールに持ち込むことができる。
【００８３】
さらに、上級開発者は、スケジュールを丸ごとソフトウェアコードとしてオーサリングすることも可能である。スケジュール型を直接オーサリングする場合も、開発者は、単に、スケジュールのコードビサイドクラスのソフトウェアコードにＩｎｉｔｉａｌｉｚｅＳｃｈｅｄｕｌｅＭｏｄｅｌという静的メソッドを入れ、このメソッドに［ＳｃｈｅｄｕｌｅＣｒｅａｔｏｒ］属性でマークするだけである。一実施形態では、静的メソッドは、パラメータを取らず、Ｓｃｈｅｄｕｌｅオブジェクトを返す。随伴するシリアライゼーションされたファイルはないが、スケジュールのシリアライゼーションされた表現は、作成されるＳｃｈｅｄｕｌｅオブジェクトから復元できる。これは、単一のソフトウェアコードファイルを使用してスケジュールを作成できることを意味しているが、妥当性チェックは、このファイルには実行されえない。オーケストレーションエンジンのコンパイルにより、スケジュール型の基礎となっているアクティビティツリーの構造上および意味論的な有効性が保証される。他の実施形態では、コンパイルおよび妥当性検証を内部で実行し、実行される実際の型を生成するが、コードの入力は不要である。スケジュール型のコンパイルは、コンパイル時オブジェクトモデルから実行時オブジェクトモデルへの変換がない分、超軽量なプロセスとなっている。本質的に、コンパイルは、単に、スケジュールのオブジェクトモデル表現をコードビサイドと組み合わせて新しい型を生成するだけである。一実施形態では、基本的に、コンパイル済みコードビサイドがオブジェクトモデル内のアクティビティにより要求される内容と一致するか、またはコードビサイドがコンパイル済みフォーム（アセンブリ）内にすでに存在している可能性がある場合には、特定のスケジュールについてコードビサイドを全く生成する必要はないと考えられる。
【００８４】
シリアライゼーションされたスケジュールをコンパイルする場合、そのスケジュールに対するコードビサイドとして実際に使用される既存のコンパイル済み型を指すことが可能である。このコンパイル済み型の派生型が作成され、この新しい型はコードビサイドとして使用され、一意的な型が新しいスケジュールを表すように作成されることが保証される。
【００８５】
（シリアライゼーションアーキテクチャ）
シリアライゼーションインフラストラクチャは、オーケストレーションエンジンのアクティビティツリーをシリアライゼーションする、モジュール方式の、形式に依存しない、容易に拡張可能なメカニズムを提供する。
【００８６】
特に、呼び出し側（例えば、アプリケーションプログラムまたはユーザ）は、シリアライゼーションマネージャからシリアライザにオブジェクト（またはアクティビティ）Ａを要求する。オブジェクトＡの型のメタデータ属性により、オブジェクトＡは要求された型のシリアライザにバインドされる。次に、呼び出し側は、オブジェクトＡをシリアライゼーションするようにシリアライザに要求する。続いて、オブジェクトＡのシリアライザはオブジェクトＡをシリアライゼーションする。シリアライザは、遭遇するオブジェクト毎に、シリアライゼーションしながら、シリアライゼーションマネージャに追加シリアライザを要求する。シリアライゼーションの結果が呼び出し側に返される。
【００８７】
オーケストレーションエンジンコンポーネントモデル内のすべてのアクティビティは、シリアライゼーションに参加することができる。シリアライザコンポーネントは、一実施形態ではアクティビティクラス自体の一部ではない。その代わりに、このコンポーネントは、アクティビティに関連付けられたクラス内のシリアライザ属性に注釈を入れることにより指定される。シリアライザ属性は、そのアクティビティ型のオブジェクトをシリアライゼーションするために使用されるクラスを指す。他の実施形態では、ある１つのアクティビティ型のプロバイダコンポーネントが、そのアクティビティにより与えられる既定のシリアライザをオーバーライドする。
【００８８】
デザイナシリアライゼーションは、メタデータ、シリアライザ、およびシリアライゼーションマネージャに基づく。メタデータ属性は、型をシリアライザに関係付けるために使用される。「ブートストラッピング」属性は、シリアライザを持たない型に対しシリアライザを提供するオブジェクトをインストールするために使用することができる。シリアライザは、特定の１つの型またはある範囲の複数の型をシリアライゼーションする方法を認識するオブジェクトである。それぞれのデータ形式に対して１つの基本クラスがある。例えば、オブジェクトをＸＭＬに変換する方法を認識するＸｍｌＳｅｒｉａｌｉｚｅｒ基本クラスが考えられる。本発明は、特定のシリアライゼーション形式に関係しない一般的なアーキテクチャである。シリアライゼーションマネージャは、オブジェクトグラフをシリアライゼーションするために使用されるさまざまなシリアライザに対する情報ストアとなるオブジェクトである。例えば、５０個のオブジェクトのグラフは、すべてそれ独自の出力を生成する５０個の異なるシリアライザを持つことができる。これらのシリアライザがシリアライゼーションマネージャを使用して、必要に応じて互いに通信し合うことができる。
【００８９】
一実施形態では、汎用オブジェクトメタデータを使用するシリアライザに結合されたシリアライゼーションプロバイダを使用することにより、与えられた型に対するシリアライザを用意する機会がオブジェクトに与えられるコールバックメカニズムを実現する。ＡｄｄＳｅｒｉａｌｉｚａｔｉｏｎＰｒｏｖｉｄｅｒなどのメソッドを通じて、シリアライゼーションマネージャにシリアライゼーションプロバイダを用意することができる。シリアライゼーションプロバイダは、ＤｅｆａｕｌｔＳｅｒｉａｌｉｚａｔｉｏｎＰｒｏｖｉｄｅｒＡｔｔｒｉｂｕｔｅなどの属性をシリアライザに追加することによりシリアライゼーションマネージャに自動的に追加できる。
【００９０】
一実施形態では、オブジェクトはｘｍｌ要素としてシリアライゼーションされる、オブジェクトのプロパティは単純プロパティ（例えば、ｘｍｌ属性としてシリアライゼーションされる）または複合プロパティ（子要素としてシリアライゼーションされる）として分類される、オブジェクトの子オブジェクトは子要素としてシリアライゼーションされる、というルールに従って形式が示される。子オブジェクトの定義は、オブジェクト毎に異なることがある。以下の実施例は、子オブジェクトの１つとしてＳｅｎｄアクティビティを持つ、ｗｈｉｌｅアクティビティのシリアライゼーションである。
【００９１】
【表１】
2006107479.tif 000003
【００９２】
シリアライゼーションに使用される言語がＸＯＭＬである一実施形態では、それぞれのＸＯＭＬ要素は、スケジュールがコンパイルされるときにそれぞれのオブジェクトにシリアライゼーションされる。オブジェクトは、単純型と複合型の両方を含む。各アクティビティのＸＯＭＬ表現の間のマッピングとオーサリングオブジェクトモデルへのマッピングについて、次に説明する。ＸＯＭＬのシリアライゼーションは、プリミティブアクティビティと複合アクティビティとで異なる。
【００９３】
プリミティブアクティビティに対する単純型は、アクティビティ型に関する属性としてシリアライゼーションされる。プリミティブアクティビティに対する複合型は、子要素としてシリアライゼーションされる。例えば、以下に、ＳｅｎｄアクティビティのＸＯＭＬ表現を示す。
【００９４】
【表２】
2006107479.tif 000004
【００９５】
プリミティブ型のシリアライゼーションと同様に、複合アクティビティに対する単純型は、アクティビティ型に関する属性としてシリアライゼーションされる。しかし、定義により、複合アクティビティはネストされたアクティビティをカプセル化したものである。それぞれのネストされているアクティビティは、他の子要素としてシリアライゼーションされる。例えば、以下に、ＷｈｉｌｅアクティビティのＸＯＭＬ表現を示す。
【００９６】
【表３】
2006107479.tif 000005
【００９７】
プロセス／ワークフロービューとシリアライゼーションされた表現との間に強い関係が存在する。図８は、スケジュール定義およびビジュアルワークフローと、ワークフローのシリアライゼーションされた（例えば、ＸＯＭＬ）表現と、ワークフローのコードビサイドとの間の関係を示す図である。いずれかの表現でオーサリングする場合、他方は変更を招く。そのため、アクティビティ（または複合アクティビティの場合にはその構成要素部分）に対するＸＯＭＬを修正すると、開発者がプロセス／ワークフロービューの切り換えを行うときにプロセス／ワークフロービューに直接反映される。逆も言える。プロセス／ワークフロービュー内のアクティビティを修正すると、ＸＯＭＬ内に適切な修正が生じる。例えば、プロセス／ワークフロービュー内でアクティビティを削除すると、同じアクティビティについてＸＯＭＬ内のＸＭＬ要素も削除される。ラウンドトリッピングは、プロセス／ワークフロービューとコードビサイドとの間にも生じる。
【００９８】
ＸＯＭＬコードを作成するときに、ＸＯＭＬ定義が定義済みインターフェイス要件に適合していない場合、違反しているＸＭＬ要素は、下線が付けられるか、または開発者がそれとわかるように他の何らかの方法で視覚的に識別される。開発者がプロセスビューに切り換えた場合、ＸＯＭＬ内にエラーがあると警告され、デザイナがリンクを表示するので、開発者はそのリンクをクリックして、違反している要素にナビゲートする。この同じエラーは、タスクペインにも表示され、そのエラーをダブルクリックすると、開発者はＸＯＭＬの違反要素にナビゲートされる。
【００９９】
（ＸＯＭＬファイルからのアクティビティツリーの作成（デシリアライゼーション））
一実施形態では、ＣｒｅａｔｅＥｄｉｔｏｒＩｎｓｔａｎｃｅ（）関数が、ＤｅｓｉｇｎＳｕｒｆａｃｅオブジェクトを作成し、その後、ＤｅｓｉｇｎＳｕｒｆａｃｅオブジェクト上でＢｅｇｉｎＬｏａｄ（）関数を呼び出して実際のローダオブジェクトをその中に渡し、最後に、ＢｅｇｉｎＬｏａｄ（）でＤｅｓｉｇｎｅｒＬｏａｄｅｒ（）関数を呼び出す。ＰｅｒｆｏｒｍＬｏａｄ（）関数は、テキストバッファオブジェクトを読み込み、それをオーケストレーションエンジンコンポーネントモデル階層にデシリアライゼーションする。本発明は、階層内を辿り、アクティビティをデザインサーフェスに挿入し、コンポーネントをＶｉｓｕａｌ  Ｓｔｕｄｉｏにロードする。
【０１００】
本発明は、さらに、ＸＯＭＬの変更を監視し、階層およびアイテム識別の変更を追跡して、Ｖｉｓｕａｌ  Ｓｔｕｄｉｏのキャッシュ内の値を更新する。二次ドキュメントデータリストは、オーケストレーションエンジンデザイナが作用する、ユーザには見えない二次ドキュメントのリストを含む。例えば、ユーザはコードビサイドファイルを開いていないが、ユーザがオーケストレーションエンジンデザイナ内で変更を加えた場合に、コードビサイドファイルに変更が加えられる。このファイルはユーザには見えないので、ファイルは二次ドキュメントとして保持されるＸＯＭＬファイルが保存されると、必ず、二次ドキュメントも自動的に保存される。これらのファイルの１つの名前が変更されるか、またはファイルが削除された場合、本発明では、それに応じて、対応する二次ドキュメントオブジェクトを更新する。
【０１０１】
オブジェクトツリーのデシリアライゼーションガイドラインの例を以下に示す。ｘｍｌ要素は、まず、親オブジェクトのプロパティとして取り扱われる。親オブジェクトが要素のタグ名を持つプロパティを持たない場合、その要素は親オブジェクトの子オブジェクトとして取り扱われる。ｘｍｌ要素は、親オブジェクト上の単純プロパティとして取り扱われる。
【０１０２】
上記のシリアライゼーションされたコードを使用するデシリアライゼーションの実施例では、＜Ｗｈｉｌｅ＞要素は、ｘｍｌ名前空間情報を使用して作成されたオブジェクトとして取り扱われる。＜ＣｏｎｄｉｔｉｏｎＲｕｌｅ＞要素は、Ｗｈｉｌｅアクティビティのプロパティとして取り扱われる。＜ＣｏｄｅＥｘｐｒｅｓｓｉｏｎＲｕｌｅＤｅｃｌａｒａｔｉｏｎ＞要素は、値がＣｏｎｄｉｔｉｏｎＲｕｌｅプロパティに適用されるオブジェクトとして取り扱われる。最初に、＜Ｓｅｎｄ＞要素がＷｈｉｌｅアクティビティのプロパティとして試みられるが、「Ｗｈｉｌｅ」アクティビティは、名前「Ｓｅｎｄ」のプロパティを持たず、したがって、＜Ｓｅｎｄ＞要素はオブジェクトとして取り扱われ、ｗｈｉｌｅアクティビティの子アクティビティとして取り扱われる。＜Ｍｅｓｓａｇｅ＞要素は、Ｓｅｎｄアクティビティのプロパティとして取り扱われる。Ｓｅｎｄ  上のＭｅｓｓａｇｅプロパティは読み取り専用なので、Ｍｅｓｓａｇｅ要素のコンテンツは、Ｍｅｓｓａｇｅオブジェクトのコンテンツと考えられる。同様のルールが、＜ＯｎＢｅｆｏｒｅＳｅｎｄ＞および＜ＴｙｐｅｄＣｈａｎｎｅｌ＞要素のデシリアライゼーションに適用される。
【０１０３】
ＸＯＭＬコードがきちんとした形でない、ＸｏｍｌＤｏｃｕｍｅｎｔがＸＯＭＬコード内の第１の要素でなく、ＸＯＭＬコード内の第１のアクティビティがデシリアライザできないという第１の条件の下では、ＸＯＭＬデシリアライゼーションは決定的に失敗する。開発者に対して、ＸＯＭＬビューからプロセス／ワークフロービューへ切り換える場合に、違反している側のＸＭＬ要素にナビゲートするためのエラーメッセージが提示される。
【０１０４】
（オーケストレーションエンジンデザイナのホスティング）
デザイナフレームワークは、どのようなアプリケーションプログラムでもホスティングできる。これは、サードパーティのアプリケーションでそれぞれの環境においてワークフローをレンダリングするのに非常に有用な機能である。またこれにより、サードパーティは、デザインサーフェスを再ホスティングおよびカスタマイズすることで、オーケストレーションエンジンデザイナ周辺のツールを開発することができる。本発明のフレームワークでは、ホスティングコンテナアプリケーション側でエディタおよび／またはテキストバッファなどのサービス群を用意することを想定している。
【０１０５】
デザイナを再ホストする１ステップでは、ローダおよびデザインサーフェスを作成する。ローダは、ＸＯＭＬファイルをロードし、アクティビティホストインフラストラクチャを構築する役割を持つ。デザインサーフェスは、その中にデザイナホストインフラストラクチャを保持し、デザインサーフェスをホスティングし、それとやり取りするサービスを提供する。デザインサーフェスは、サービスコンテナだけでなくサービスプロバイダとしても機能する。一実施例では、以下のコードを実行して、ＸＯＭＬドキュメントをロードし、その中にアクティビティを保持するデザイナホストを構築する。
【０１０６】
【表４】
2006107479.tif 000006
【０１０７】
以下のサービスでは、デザイナで異なる機能を使用できる。ＩＳｅｌｅｃｔｉｏｎＳｅｒｖｉｃｅ関数は、選択されたオブジェクトを保持する。ＩＴｏｏｌｂｏｘＳｅｒｖｉｃｅ関数は、ツールボックスとのやり取りを管理する。ＩＭｅｎｕＣｏｍｍａｎｄＳｅｒｖｉｃｅ関数は、メニューとのやり取りを管理する。ＩＴｙｐｅＰｒｏｖｉｄｅｒ関数を使用すると、タイプシステムを利用できる。さらに、高度なデザイナ機能を使用可能にするデザイナホスティング環境が提供する追加サービスもありえる。
【０１０８】
タイプシステムは、本発明のコンポーネントモデルフレームワーク内の一コンポーネントである。デザイナがプロジェクトシステムの内側でホスティングされる場合、ＴｙｐｅＰｒｏｖｉｄｅｒオブジェクトがプロジェクト毎に作成される。プロジェクト内のアセンブリ参照は、タイププロバイダへプッシュされる。さらに、プロジェクト内のユーザコードファイルが解析され、単一コードコンパイル単位が作成され、タイププロバイダへプッシュされる。また、本発明は、タイプシステム内で型を変更させることが可能なプロジェクトシステム内のイベントを監視し、その変更に対する応答として型を再ロードする適切な呼び出しをタイププロバイダに対し実行する。
【０１０９】
（元に戻す／繰り返し）
スケジュールを作成し、正しく構築した後、開発者は一連の実行済みオペレーションをロールバックしたい場合がある。本発明の「元に戻す」および「繰り返し」機能を使用すると、どのアクティビティが直接影響を受けているかを例示する視覚的フィードバックが得られる。例えば、アクティビティ上でプロパティの変更が元に戻される場合、影響を受けたアクティビティは選択状態になる。複数のオブジェクトの削除が元に戻される場合、関わっているすべてのオブジェクトが、スケジュールに復元されるときに選択状態になる。Ｕｎｄｏ／Ｒｅｄｏ（元に戻す／繰り返し）は、他の分野における多くのアプリケーション全体を通して使用される共通の機能であり、その意味はよく理解されている。オーケストレーションエンジンデザイナでは、Ｓａｖｅ後に、元に戻す／繰り返しアイテムがパージされることはない。さらに、元に戻す／繰り返しは、プロセス／ワークフロービューで、ＸＯＭＬビューで、開発者がビューを切り換えた場合に、およびコードビサイド内で実行することができる。
【０１１０】
Ｕｎｄｏ／Ｒｅｄｏは、プロセス／ワークフロービュー内のアクション、つまり、アクティビティのドラッグ＆ドロップ（例えば、ツールボックスからデザインサーフェスにアクティビティをドラッグする、スケジュールの一部分から他の部分にアクティビティを移動する、一方のデザイナから他方のデザイナにアクティビティを移動する）、アクティビティの構成（例えば、アクティビティのプロパティを指定する）、および切り取り／コピー／貼り付け／削除のアクションに対し用意されている。
【０１１１】
一実施形態では、シリアライゼーションされたビュー（例えば、ＸＯＭＬビュー）は、テキストエディタ標準の元に戻す／繰り返しオペレーションを備えるＸＭＬエディタである。本発明のデザイナは、プロセス／ワークフロービュー内で加えられた変更を示すフィードバックを開発者に提示する。その後、シリアライゼーションされたビュー内で元に戻した結果として、シリアライゼーションされたコードは失われる。開発者がプロセス／ワークフロービュー内のスケジュールの一部分を構築し、シリアライゼーションされたビューに切り換えて、その後、元に戻す／繰り返しオペレーションを実行することに決めた場合、警告が表示される。
【０１１２】
（動作環境の例）
図９は、コンピュータ１３０の形態の汎用コンピューティング装置の一実施例を示している。本発明の一実施形態では、コンピュータ１３０などのコンピュータは、例示され、本明細書で説明されている他の図で使用するのに適している。コンピュータ１３０は、１つまたは複数のプロセッサまたは演算処理装置１３２およびシステムメモリ１３４を備える。例示されている実施形態では、システムバス１３６は、システムメモリ１３４を含むさまざまなシステムコンポーネントをプロセッサ１３２に結合する。バス１３６は、メモリバスまたはメモリコントローラ、周辺機器バス、アクセラレイティッドグラフィックスポート、およびさまざまなバスアーキテクチャのどれかを使用するプロセッサまたはローカルバスを含む数種類のバス構造のうちの１つまたは複数を表している。例えば、限定はしないが、このようなアーキテクチャとしては、Ｉｎｄｕｓｔｒｙ  Ｓｔａｎｄａｒｄ  Ａｒｃｈｉｔｅｃｔｕｒｅ（ＩＳＡ）バス、Ｍｉｃｒｏ  Ｃｈａｎｎｅｌ  Ａｒｃｈｉｔｅｃｔｕｒｅ（ＭＣＡ）バス、Ｅｎｈａｎｃｅｄ  ＩＳＡ（ＥＩＳＡ）バス、Ｖｉｄｅｏ  Ｅｌｅｃｔｒｏｎｉｃｓ  Ｓｔａｎｄａｒｄｓ  Ａｓｓｏｃｉａｔｉｏｎ（ＶＥＳＡ）ローカルバス、およびＭｅｚｚａｎｉｎｅバスとも呼ばれるＰｅｒｉｐｈｅｒａｌ  Ｃｏｍｐｏｎｅｎｔ  Ｉｎｔｅｒｃｏｎｎｅｃｔ（ＰＣＩ）バスがある。
【０１１３】
コンピュータ１３０は、通常、少なくともある種の形態のコンピュータ読み取り可能媒体を備える。コンピュータ読み取り可能媒体は、揮発性および不揮発性媒体、取り外し可能および固定の媒体を含み、コンピュータ１３０によってアクセスできる媒体であればどのような媒体でもよい。例えば、限定はしないが、コンピュータ読み取り可能媒体は、コンピュータ記憶媒体および通信媒体を含む。コンピュータ記憶媒体は、コンピュータ読み取り可能命令、データ構造体、プログラムモジュール、またはその他のデータなどの情報を格納する方法または技術で実装される揮発性および不揮発性、取り外し可能な、および固定の媒体を含む。例えば、コンピュータ記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたはその他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多目的ディスク（ＤＶＤ）またはその他の光ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置またはその他の磁気記憶装置、または所望の情報を格納するために使用することができ、しかもコンピュータ１３０によりアクセスできるその他の媒体を含む。通信媒体は、通常、コンピュータ読み取り可能命令、データ構造体、プログラムモジュール、または搬送波もしくはその他のトランスポートメカニズムなどの変調データ信号によるその他のデータを具現するものであり、任意の情報配信媒体を含む。当業者は、信号内の情報を符号化するなどの方法により特性のうちの１つまたは複数が設定または変更される変調データ信号を熟知している。有線ネットワークまたは直接配線接続などの有線媒体、ならびに音響、ＲＦ、赤外線、およびその他の無線媒体などの無線媒体は、通信媒体のいくつかの実施例である。上記のいずれの組み合わせもコンピュータ読み取り可能媒体の範囲に含まれる。
【０１１４】
システムメモリ１３４は、取り外し可能な、および／または固定の、揮発性および／または不揮発性メモリの形のコンピュータ記憶媒体を備える。例示されている実施形態では、システムメモリ１３４は、読み取り専用メモリ（ＲＯＭ）１３８およびランダムアクセスメモリ（ＲＡＭ）１４０を含む。起動時などにコンピュータ１３０内の要素間の情報伝送を助ける基本ルーチンを含む基本入出力システム１４２（ＢＩＯＳ）は、通常、ＲＯＭ  １３８に格納される。通常、ＲＡＭ  １４０は、演算処理装置１３２に直接アクセス可能な、および／または演算処理装置１３２によって現在操作されているデータおよび／またはプログラムモジュールを格納する。例えば、限定はしないが、図９は、オペレーティングシステム１４４、アプリケーションプログラム１４６、その他のプログラムモジュール１４８、およびプログラムデータ１５０を例示している。
【０１１５】
コンピュータ１３０はさらに、その他の取り外し可能な／固定の揮発性／不揮発性コンピュータ記憶媒体を備えることもできる。例えば、図９は、固定の不揮発性磁気媒体への読み書きを行うハードディスクドライブ１５４を例示している。図９は、さらに、取り外し可能不揮発性磁気ディスク１５８への読み書きを行う磁気ディスクドライブ１５６、およびＣＤ−ＲＯＭまたはその他の光媒体などの取り外し可能不揮発性光ディスク１６２への読み書きを行う光ディスクドライブ１６０を示している。動作環境の実施例で使用できる他の取り外し可能な／固定の揮発性／不揮発性コンピュータ記憶媒体としては、限定はしないが、磁気テープカセット、フラッシュメモリカード、デジタル多目的ディスク、デジタルビデオテープ、ソリッドステートＲＡＭ、ソリッドステートＲＯＭなどがある。ハードディスクドライブ１５４、および磁気ディスクドライブ１５６、および光ディスクドライブ１６０は、通常、インターフェイス１６６などの不揮発性メモリインターフェイスによりシステムバス１３６に接続される。
【０１１６】
図９に例示されている上記のドライブまたは他の大容量記憶装置およびその関連コンピュータ記憶媒体は、コンピュータ１３０用のコンピュータ読み取り可能命令、データ構造体、プログラムモジュール、およびその他のデータを格納する機能を備える。例えば、図９では、ハードディスクドライブ１５４は、オペレーティングシステム１７０、アプリケーションプログラム１７２、その他のプログラムモジュール１７４、およびプログラムデータ１７６を格納するものとして例示されている。これらのコンポーネントは、オペレーティングシステム１４４、アプリケーションプログラム１４６、その他のプログラムモジュール１４８、およびプログラムデータ１５０と同じである場合もあれば異なる場合もあることに留意されたい。オペレーティングシステム１７０、アプリケーションプログラム１７２、その他のプログラムモジュール１７４、およびプログラムデータ１７６に対しては、ここで、異なる番号を割り当てて、最低でも、それらが異なるコピーであることを示している。
【０１１７】
ユーザは、キーボード１８０、およびポインティング装置１８２（例えば、マウス、トラックボール、ペン、またはタッチパッド）などのなどの入力装置またはユーザインターフェイス選択装置を通じてコマンドおよび情報をコンピュータ１３０に入力することができる。他の入力装置（図に示されていない）としては、マイク、ジョイスティック、ゲームパッド、衛星放送受信アンテナ、スキャナなどがある。これらの入力装置およびその他の入力装置は、システムバス１３６に結合されているユーザ入力インターフェイス１８４を通じて演算処理装置１３２に接続されるが、パラレルポート、ゲームポート、またはユニバーサルシリアルバス（ＵＳＢ）などの他のインターフェイスおよびバス構造により接続することもできる。モニタ１８８またはその他の種類の表示装置も、ビデオインターフェイス１９０などのインターフェイスを介してシステムバス１３６に接続される。モニタ１８８のほかに、コンピュータはプリンタおよびスピーカなどの他の周辺出力装置（図に示されていない）を備えることが多く、これらは出力周辺機器インターフェイス（図に示されていない）を通じて接続することができる。
【０１１８】
コンピュータ１３０は、リモートコンピュータ１９４などの１つまたは複数のリモートコンピュータへの論理接続を使用してネットワーク接続環境で動作することができる。リモートコンピュータ１９４は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピア装置、またはその他の共通ネットワークノードとすることができ、通常は、コンピュータ１３０に関して上で説明されている要素の多くまたはすべてを含む。図９に示されている論理接続は、ローカルエリアネットワーク（ＬＡＮ）１９６およびワイドエリアネットワーク（ＷＡＮ）１９８を含むが、他のネットワークを含むこともできる。ＬＡＮ  １９６および／またはＷＡＮ  １９８は、有線ネットワーク、無線ネットワーク、それらの組み合わせなどとすることができる。このようなネットワーキング環境は、オフィス、企業規模のコンピュータネットワーク、イントラネット、および大域的コンピュータネットワーク（例えば、インターネット）では一般的である。
【０１１９】
ローカルエリアネットワーキング環境で使用される場合、コンピュータ１３０は、ネットワークインターフェイスまたはアダプタ１８６を介してＬＡＮ  １９６に接続される。ワイドエリアネットワーキング環境で使用される場合、コンピュータ１３０は、通常、インターネットなどのＷＡＮ  １９８上で通信を確立するためモデム１７８またはその他の手段を備える。モデム１７８は、内蔵でも外付けでもよいが、ユーザ入力インターフェイス１８４、またはその他の適切なメカニズムを介してシステムバス１３６に接続される。ネットワーク接続環境では、コンピュータ１３０またはその一部に関して示されているプログラムモジュールは、リモートメモリ記憶装置（図に示されていない）に格納されうる。例えば、限定はしないが、図９には、リモートアプリケーションプログラム１９２がメモリ装置に常駐しているように例示されている。図に示されているネットワーク接続は実施例であり、コンピュータ間の通信リンクを確立するのに他の手段が使用されうる。
【０１２０】
一般に、コンピュータ１３０のデータプロセッサは、コンピュータのさまざまなコンピュータ読み取り可能記憶媒体にさまざまな時点において格納された命令を使ってプログラムされる。プログラムおよびオペレーティングシステムは、通常、例えば、フロッピー（登録商標）ディスクまたはＣＤ−ＲＯＭで配布される。そこから、コンピュータの補助記憶装置にインストールまたはロードされる。実行時に、それらは少なくとも一部はコンピュータの主記憶装置にロードされる。本明細書で説明されている発明は、これらおよび他のさまざまな種類のコンピュータ読み取り可能記憶媒体を含むが、ただしそのような媒体にマイクロプロセッサまたはその他のデータプロセッサに関して以下で説明されるステップを実装する命令またはプログラムが格納されている場合である。本発明は、さらに、本明細書で説明されている方法および手法に従ってプログラムされた場合にコンピュータ自体も含む。
【０１２１】
例示の目的に関して、オペレーティングシステムなどのプログラムおよびその他の実行可能プログラムコンポーネントは、本明細書では異なるブロックとして例示されている。しかし、そのようなプログラムおよびコンポーネントは、コンピュータの異なる記憶装置コンポーネント内にさまざまな時点において常駐し、コンピュータの（複数の）データプロセッサにより実行されることは理解される。
【０１２２】
本発明は、コンピュータ１３０を含む、コンピューティングシステム環境例に関して説明されているが、他の多くの汎用または専用コンピューティングシステム環境または構成で動作する。このコンピューティングシステム環境は、本発明の用途または機能の範囲に関する制限を示唆する意図はない。さらに、コンピューティングシステム環境は、動作環境例に例示されている１つのコンポーネントまたは複数のコンポーネントの組み合わせに関係する何らかの依存関係または要求条件がその環境にあるものと解釈すべきでない。本発明とともに使用するのに適していると思われるよく知られているコンピューティングシステム、環境、および／または構成の例として、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルドまたはラップトップ装置、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、プログラム可能な家電製品、携帯電話、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、上記システムまたは装置を含む分散コンピューティング環境などがある。
【０１２３】
本発明は、１つまたは複数のコンピュータまたはその他の装置により実行される、プログラムモジュールなどのコンピュータ実行可能命令の一般的状況において説明することができる。一般に、プログラムモジュールは、限定はしないが、特定のタスクを実行する、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、およびデータ構造を含む。また、本発明は、通信ネットワークを通じてリンクされているリモート処理装置によりタスクが実行される分散コンピューティング環境で実施することもできる。分散コンピューティング環境では、プログラムモジュールをメモリ記憶装置などのローカルとリモートの両方のコンピュータ記憶媒体に配置できる。
【０１２４】
ソフトウェアアーキテクチャの背景状況におけるインターフェイスは、ソフトウェアモジュール、コンポーネント、コード部分、またはコンピュータ実行可能命令の他のシーケンスを含む。例えば、インターフェイスは、第１のモジュールの代わりにコンピューティングタスクを実行するために第２のモジュールにアクセスする第１のモジュールを含む。第１および第２のモジュールは、一実施例では、オペレーティングシステムによって提供されるようなアプリケーションプログラミングインターフェイス（ＡＰＩ）、コンポーネントオブジェクトモデル（ＣＯＭ）インターフェイス（例えば、ピアツーピアアプリケーション通信用）、および拡張マークアップ言語メタデータ交換形式（ＸＭＩ）インターフェイス（例えば、複数のＷｅｂサービス間の通信用）を含む。
【０１２５】
インターフェイスは、Ｊａｖａ（登録商標）  ２  Ｐｌａｔｆｏｒｍ  Ｅｎｔｅｒｐｒｉｓｅ  Ｅｄｉｔｉｏｎ（Ｊ２ＥＥ）、ＣＯＭ、または分散ＣＯＭ（ＤＣＯＭ）の実施例などの密結合の同期実装であってよい。それとは別に、またはそれに加えて、インターフェイスは、Ｗｅｂサービスの場合のような疎結合の非同期実装とすることもできる（例えば、シンプルオブジェクトアクセスプロトコルを使用する）。一般に、インターフェイスは、密結合、疎結合、同期、および非同期という特性の任意の組み合わせを含む。さらに、インターフェイスは、標準プロトコル、専用プロトコル、または標準プロトコルと専用プロトコルとの任意の組み合わせに適合することができる。
【０１２６】
本明細書で説明されているインターフェイスは、すべて、単一インターフェイスの一部であるか、または別々のインターフェイスもしくはそれらの任意の組み合わせとして実装することができる。これらのインターフェイスは、機能を提供するためにローカルまたはリモートで実行できる。さらに、これらのインターフェイスが含む機能は、例示されている、または本明細書で説明されている機能よりも多い場合も少ない場合もある。
【０１２７】
例示され、本明細書で説明されている方法の実行または遂行の順序は、断りのない限り本質的ではない。つまり、これらの方法の要素は、断りのない限り任意の順序で実行することができ、それらの方法が含む要素は、本明細書で開示されている要素よりも多い場合も少ない場合もある。例えば、特定の要素を、他の要素の前に、他の要素と同時に、または他の要素の後に実行または遂行することは本発明の範囲であると考えられる。
【０１２８】
本発明または本発明の（複数の）実施形態の要素を導入する際に、英文中の「ａ」、「ａｎ」、「ｔｈｅ」、および「ｓａｉｄ」という冠詞、したがって和文中の「１つの」、「その」、「前記」は、それらの要素が１つまたは複数あることを意味することを意図している。「備える」、「含む」、および「持つ、格納する、含む、備える」という言葉は、包含的であることを意図し、一覧に示されている要素以外にさらに要素がありうることを意味する。
【０１２９】
上記の説明に照らして、本発明の複数の目的が達成され、他の有益な結果が得られることは理解されるであろう。
【０１３０】
本発明の範囲から逸脱することなく上記の構成、製品、および方法にさまざまな変更を加えることが可能であるので、上記の説明に含まれ、付属の図面に示されているすべての事柄は、例示しているのであって、限定する意味はないと解釈するものとする。
【０１３１】
付録Ａ
（アクティビティの例およびその実装例）
アクティビティの例としては、Ｓｅｎｄ、ＳｅｎｄＲｅｑｕｅｓｔ、ＳｅｎｄＲｅｓｐｏｎｓｅ、Ｒｅｃｅｉｖｅ、ＲｅｃｅｉｖｅＲｅｑｕｅｓｔ、ＲｅｃｅｉｖｅＲｅｓｐｏｎｓｅ、Ｃｏｄｅ、Ｄｅｌａｙ、Ｆａｕｌｔ、Ｓｕｓｐｅｎｄ、Ｔｅｒｍｉｎａｔｅ、ＩｎｖｏｋｅＳｃｈｅｄｕｌｅ、ＩｎｖｏｋｅＳｃｈｅｄｕｌｅｓ、Ｉｎｖｏｋｅ  ＷｅｂＳｅｒｖｉｃｅ、ＤｏｔＮｅｔＥｖｅｎｔＳｏｕｒｃｅ、ＤｏｔＮｅｔＥｖｅｎｔＳｉｎｋ、Ｓｅｑｕｅｎｃｅ、Ｐａｒａｌｌｅｌ、Ｗｈｉｌｅ、ＣｏｎｄｉｔｉｏｎａｌＢｒａｎｃｈ、Ｃｏｎｄｉｔｉｏｎａｌ、Ｃｏｎｓｔｒａｉｎｅｄ、ＣｏｎｓｔｒａｉｎｅｄＡｃｔｉｖｉｔｙＧｒｏｕｐ（ＣＡＧ）、ＥｖｅｎｔＤｒｉｖｅｎ、Ｌｉｓｔｅｎ、ＥｖｅｎｔＨａｎｄｌｅｒｓ、ＥｘｃｅｐｔｉｏｎＨａｎｄｌｅｒ、ＥｘｃｅｐｔｉｏｎＨａｎｄｌｅｒｓ、Ｃｏｍｐｅｎｓａｔｅ、ＣｏｍｐｅｎｓａｔｉｏｎＨａｎｄｌｅｒ、Ｓｃｏｐｅ、およびＳｃｈｅｄｕｌｅがある。
【０１３２】
アクティビティの実施例はそれぞれ、メタデータが関連付けられている。メタデータは、アクティビティに関連付けられたシリアライザによってワークフローの宣言的表現に移される。例えば、メタデータは、オプションのコードビサイドメソッドおよびオプションの相関関係集合のコレクションを含むことができる。
（Ｓｅｎｄアクティビティ）
オーケストレーションエンジンは、メッセージを送信する３つのアクティビティ（例えば、Ｓｅｎｄ、ＳｅｎｄＲｅｑｕｅｓｔ、およびＳｅｎｄＲｅｓｐｏｎｓｅ）を備え、それぞれ異なる使用事例を対象とする。さらに、これら３つのアクティビティは、何らかのメタデータを共有するので、抽象基本クラスが３つのすべての上位クラスとして定義され使用される。
（Ｒｅｃｅｉｖｅアクティビティ）
オーケストレーションエンジンは、メッセージを受信する３つのアクティビティ（例えば、Ｒｅｃｅｉｖｅ、ＲｅｃｅｉｖｅＲｅｑｕｅｓｔ、およびＲｅｃｅｉｖｅＲｅｓｐｏｎｓｅ）を備え、それぞれ異なる使用事例を対象とする。さらに、これら３つのアクティビティは、何らかのメタデータを共有するので、抽象基本クラスが３つのすべての上位クラスとして定義され使用される。
（Ｃｏｄｅ）
Ｃｏｄｅアクティビティは、メタデータで指示されているコードビサイドメソッドを実行する。
（Ｄｅｌａｙ）
Ｄｅｌａｙアクティビティは、その必須コードビサイドメソッドを実行してＤａｔｅＴｉｍｅ値を生成する。そのインスタンスデータのＴｉｍｅｏｕｔＶａｌｕｅプロパティをこの値に内部的に設定する。ＤａｔｅＴｉｍｅが過去であれば、Ｄｅｌａｙは即座に完了する。そうでなければ、タイマーが作動ときにＤｅｌａｙに通知するようにタイマーサブスクリプションをセットアップする。タイマーが作動した場合、Ｄｅｌａｙは通知され、完了する。
（Ｆａｕｌｔ）
Ｆａｕｌｔアクティビティは、その必須コードビサイドメソッドを実行してＥｘｃｅｐｔｉｏｎオブジェクトを生成する。
（Ｓｕｓｐｅｎｄ）
Ｓｕｓｐｅｎｄアクティビティは、現在のスケジュールインスタンスをサスペンドする。
（Ｔｅｒｍｉｎａｔｅ）
Ｔｅｒｍｉｎａｔｅアクティビティは、現在のスケジュールインスタンスを終了する。
（Ｉｎｖｏｋｅ  Ｓｃｈｅｄｕｌｅ）
ＩｎｖｏｋｅＳｃｈｅｄｕｌｅアクティビティは、スケジュールを呼び出す。
（Ｉｎｖｏｋｅ  Ｗｅｂ  Ｓｅｒｖｉｃｅ）
プロキシクラスを介してＷｅｂサービスを呼び出して、パラメータを指定通り受け渡し、受信する。
（ＤｏｔＮｅｔＥｖｅｎｔ  Ｓｉｎｋ）
すでに呼び出されているスケジュールインスタンスにより指定イベントが発生したという通知が来るのを待つブロック。
（ＤｏｔＮｅｔＥｖｅｎｔ  Ｓｏｕｒｃｅ）
指定イベントを発生し、即座に実行を完了する。
（Ｓｅｑｕｅｎｃｅ）
Ｓｅｑｕｅｎｃｅアクティビティは、一度に１つずつ、順序正しく子アクティビティの集合の実行を調整する。
（Ｐａｒａｌｌｅｌ）
Ｐａｒａｌｌｅｌアクティビティは、子アクティビティの集合を同時実行する。
（Ｗｈｉｌｅ）
子アクティビティを繰り返し実行する。
（ＣｏｎｄｉｔｉｏｎａｌＢｒａｎｃｈ）
Ｓｅｑｕｅｎｃｅの意味論に従って、子アクティビティを実行する。
（Ｃｏｎｄｉｔｉｏｎａｌ）
Ｃｏｎｄｉｔｉｏｎａｌアクティビティは、ＣｏｎｄｉｔｉｏｎａｌＢｒａｎｃｈアクティビティの順序付き集合を含む。
（Ｃｏｎｓｔｒａｉｎｅｄ）
ＣｏｎｓｔｒａｉｎｅｄアクティビティがＣＡＧにより実行を指示された場合、それがラップするアクティビティを単に実行するだけである。
（ＣＡＧ（Ｃｏｎｓｔｒａｉｎｅｄ  Ａｃｔｉｖｉｔｙ  Ｇｒｏｕｐ））
ＣＡＧは、制約アクティビティのみを含む。ＣＡＧは、実行されると、その使用可能および使用不可制約の評価に基づいて子アクティビティを実行（および再実行）する。
（Ｔａｓｋ）
１つまたは複数のプリンシパルにより実行される外部作業単位をモデル化する。
（Ｅｖｅｎｔ  Ｄｒｉｖｅｎ）
実行が「イベント」アクティビティによりトリガされるアクティビティをラップする。
（Ｌｉｓｔｅｎ）
ｎ個の子ＥｖｅｎｔＤｒｉｖｅｎアクティビティの１つを条件付きで実行する。
（Ｅｖｅｎｔ  Ｈａｎｄｌｅｒｓ）
ＥｖｅｎｔＨａｎｄｌｅｒｓアクティビティは、単純に、ＥｖｅｎｔＤｒｉｖｅｎアクティビティの集合を保持し、これを関連するＳｃｏｐｅが使用する。
（Ｅｘｃｅｐｔｉｏｎ  Ｈａｎｄｌｅｒ）
スコープに対するキャッチブロックを表すメタデータでアクティビティをラップする。
（Ｅｘｃｅｐｔｉｏｎ  Ｈａｎｄｌｅｒｓ）
ＥｘｃｅｐｔｉｏｎＨａｎｄｌｅｒアクティビティの順序付き集合をラップする。
（Ｃｏｍｐｅｎｓａｔｅ）
完了した子スコープを補正する。
（Ｃｏｍｐｅｎｓａｔｉｏｎ  Ｈａｎｄｌｅｒ）
スコープに対する補正ハンドラとして定義されている子アクティビティをラップする。
（Ｓｃｏｐｅ）
スコープは、トランザクション境界、例外処理境界、補正境界、イベント処理境界、およびメッセージ、変数、相関関係集合、およびチャネル宣言の境界（つまり、共有データ状態）である。
実行：
Ｓｃｏｐｅ内のアクティビティの実行は順次であり、したがって、含まれているアクティビティは、Ｓｅｑｕｅｎｃｅの場合のように、スコープが構築されたときに明示的に順序付けられる。
（Ｓｃｈｅｄｕｌｅ）
Ｓｃｈｅｄｕｌｅは、オーケストレーションエンジンが実行する唯一の最上位レベルのアクティビティである。
（複合アクティビティ）
制御フローを使用可能にする複合アクティビティ型は、Ｓｅｑｕｅｎｃｅ、Ｐａｒａｌｌｅｌ、Ｃｏｎｓｔｒａｉｎｅｄ  Ａｃｔｉｖｉｔｙ  Ｇｒｏｕｐ、Ｃｏｎｄｉｔｉｏｎａｌ、Ｗｈｉｌｅ、Ｌｉｓｔｅｎである。さらに、ＳｃｏｐｅおよびＳｃｈｅｄｕｌｅは、中にあるアクティビティの暗黙のシーケンス動作を含むコンテナとして動作する複合アクティビティ型である。
【図面の簡単な説明】
【０１３３】
【図１】タスクおよび制御フロー複合アクティビティを含むワークフローの実施例を示す図である。
【図２】アクティビティ継承ツリーの実施例を示す図である。
【図３】コンポーネントモデルの実施例を示す図である。
【図４】コンポーネントモデルのライフサイクルの例を示す図である。
【図５】ワークフローの指定にウィザードに依存する、ワークフローオーサリングするための高水準アプリケーションユーザインターフェイスを示す図である。
【図６】ワークフローデザイナの実施例を示す図である。
【図７】送信アクティビティが後に続く受信アクティビティを含むオーケストレーションプログラムを示す図である。
【図８】スケジュール定義およびビジュアルワークフローと、ワークフローのＸＯＭＬによるシリアライズされた表現と、ワークフローのコードビサイドとの間の関係を示す図である。
【図９】本発明を実装することができる１つの好適なコンピューティングシステム環境の一実施例を示すブロック図である。
【符号の説明】
【０１３４】
１３０  コンピュータ
１５４  ハードディスクドライブ
１５６  磁気ディスクドライブ
１６０  光ディスクドライブ
１７８  モデム
１８８  モニタ
１９４  リモートコンピュータ
【図１】
2006107479.tif 000007
【図２】
2006107479.tif 000008
【図３】
2006107479.tif 000009
【図４】
2006107479.tif 000010
【図５】
2006107479.tif 000011
【図６】
2006107479.tif 000012
【図７】
2006107479.tif 000013
【図８】
2006107479.tif 000014
【図９】
2006107479.tif 000015