"プロセッサとシステムメモリとを含むコンピュータシステムにおいて、オブジェクト指向のコードで表現された複数のサービスの間での同時実行を実施する方法であって、前記複数のサービスの外部のコントラクトを宣言するステップであって、情報を同期させる前記コントラクトは前記複数のサービス内の複数の対象サービスの間に送信されて前記複数の対象サービスの同時実行を実施し、前記コントラクトは、複数の対象サービスの間で情報を同期させる複数のメッセージと、前記複数の対象サービスの部分集合を順序づけるメッセージとを宣言するステップと、複数の対象サービスの前記部分集合の間で前記外部のコントラクトに従って前記メッセージの順序付けを実施するステップであって、前記メッセージの順序付けの実施は、対象サービスの前記部分集合の間で同期された情報を編成して複数の対象サービスの同時実行を促進し、複数の対象サービスの前記部分集合における第1のサービスであって、メッセージを複数の対象サービスの前記部分集合における第2のサービスに送信し、前記メッセージは前記外部のコントラクトに対し実施スケジュールを識別するペイロードを含み、前記ペイロードは、前記第1のサービスおよび前記第2のサービスが他のサービスをブロックすることなく待機するときを指示する第1のサービスを含み、前記第2のサービスは前記第1のサービスからのメッセージを受信し、かつ前記第2のサービスは、前記ペイロードを使用しかつ前記コントラクトに対し前記スケジュールを実施するために前記メッセージを逆コンパイルする、前記メッセージの順序付けを実施するステップと、を含むことを特徴とする方法。コントラクトを宣言するステップは、少なくとも1つの非同期メッセージを宣言するステップを含むことを特徴とする請求項1に記載の方法。コントラクトを宣言するステップは、少なくとも1つの非同期メッセージの実行のパターンを指定するステップを含むことを特徴とする請求項2に記載の方法。前記メッセージの順序付けを実施するステップは、前記少なくとも1つの非同期メッセージの実行のトリガを指定するステップを含むことを特徴とする請求項2に記載の方法。前記メッセージの順序付けを実施するステップは、メソッド呼び出しを宣言し、前記メソッド呼び出しの実施のパターンを指定するステップを含むことを特徴とする請求項1に記載の方法。前記メッセージの順序付けを実施するステップは、既存のコントラクトを拡張するコントラクト拡張を識別するステップを含むことを特徴とする請求項1に記載の方法。前記コントラクト拡張を識別するステップは、少なくとも1つの追加メッセージを前記コントラクトに追加するステップを含むことを特徴とする請求項6に記載の方法。前記コントラクト拡張を識別するステップは、少なくとも1つの追加状態を前記コントラクトに追加するステップを含むことを特徴とする請求項6に記載の方法。前記コントラクト拡張を識別するステップは、少なくとも1つの追加トリガを前記コントラクトに追加するステップを含むことを特徴とする請求項6に記載の方法。前記メッセージの順序付けを実施するステップは、前記コントラクトを切り分けてスケジュールの生成を促進するステップと、前記切り分けたコントラクトを分割して前記スケジュールを生成するステップと、前記スケジュールをランタイムアルゴリズムに伝達するステップとを含むことを特徴とする請求項2に記載の方法。プロセッサとシステムメモリとを含むコンピュータシステムにおいて、オーケストレーションコンポーネントを使用して複数のサービスの間での通信を管理する方法であって、前記複数のサービスの外部のコントラクトを宣言するステップであって、前記外部のコントラクトを宣言するステップは、複数のメッセージを定義するステップと、前記複数のサービスの間で同時実行を実施する前記外部のコントラクトのプロトコルを定義するステップとを含み、前記複数のメッセージは複数の非同期メッセージをデータと共に含む、外部のコントラクトを宣言するステップと、前記外部のコントラクトを実施して複数のサービスの間で通信するステップであって、前記複数のサービスの各々はスレッドコンテキストを含むステップと、前記外部のコントラクトをコンパイルし、非同期のメッセージングと、前記複数のサービスの間で同時実行を実施する前記コントラクトのプロトコルとに応じてスケジュールを生成するステップと、前記生成されたスケジュールを使用して前記複数のサービスを並列に編成し、前記データの共有および同期化を実行するステップであって、前記スケジュールは、前記複数の非同期メッセージを並列に待機して、複数のサービスのスレッドコンテキストのブロックを回避するステップであって、前記複数のサービスのうちのサービスにメッセージを送信するステップであって、前記メッセージは前記スケジュールを識別するペイロードを含み、前記ペイロードは、前記サービスが他のサービスをブロックすることなく待機するときを指示するステップと、前記ペイロードを使用しかつ前記スケジュールを実施して他のサービスをブロックすることなく待機するために前記サービスが前記メッセージを逆コンパイルするステップとを含む、前記データの共有および同期化を実行するステップとを含むことを特徴とする方法。前記スケジュールをランタイムアルゴリズムに伝達するステップをさらに含むことを特徴とする請求項11に記載の方法。以下では、本発明のいくつかの態様の基本的な内容を理解できるように、発明の開示を簡単に説明する。この発明の開示は、本発明の概要を広範囲にわたって述べたものではない。この発明の開示は、本発明の鍵となる/決定的な要素を示したり、本発明の範囲を定めることを目的としていない。後で述べる詳細な説明の前置きとして、本発明のいくつかの概念を簡略化した形式で述べることのみを目的とする。本明細書で開示され請求される本発明は、その一態様において、主流のオブジェクト指向OO言語で同時実行の高水準の抽象化を直接実現する。これは、複数のサービス間の通信を同時に管理するメカニズム例えば、オーケストレーションを利用する非同期メッセージ受け渡しを導入することにより正しい同時実行プログラムを簡単に書けるようにすることを目的とする同時実行モデルを提供する。一態様では、本発明は、主流のオブジェクト指向言語に同時実行のサポートを追加する。これにより1つのアドレス空間内で実行できるか、または単一コンピュータ上で複数のプロセス間に分散できるか、またはローカルエリアまたはワイドエリアネットワーク内に分散できるプログラムを、プログラムのコーディングし直しをすることなく、開発できるようにする言語拡張が提供される。この態様の中心には、自アルゴリズム論理的スレッドを実行することができる、サービスという概念がある。したがって、サービスは明示的な同期プリミティブを使用してメモリを共有または同期しない。むしろ、データ共有と同期は、両方とも、メッセージ受け渡しを介して実行される、例えば、一組の明示的に宣言されたメッセージがサービス間で送信される。メッセージは、共有されるデータおよび同期を実現するメッセージ交換のパターンを含むことができる。他の態様では、サービス間のメッセージベースのインターフェースを指定する方法、例えば、コントラクトが用意される。他の詳細をインターフェース例えば、メソッドおよびコントラクトに追加するメカニズムも用意される。このような詳細は、形式的プロトコル定義を与えることができるメソッド呼び出しの順序付けインターフェースの場合、またはメッセージコントラクトの場合を記述する機能を備える。本発明の他の態様は、異なるコントラクト関係の革新技術を対象とする。コントラクトは、インターフェースのメンバの許容可能な呼び出しシーケンスの形式的指定である。これらは、双方向のメッセージベースのインターフェースとともに使用する場合に特に力を発揮するが、適用は、本明細書で説明されているように、従来のOOインターフェースにも及ぶ。例えば、本発明の一態様は、動的検証アルゴリズムの実装に関係する。より具体的には、この態様は、コントラクトを強制する実行時アルゴリズムに関係する。したがって、式のパターンに関係なく、実行時表現は、すべての正当なコントラクト状態を符号化する非決定論的有限状態マシンであってよいとも考えられる。そこで、この状態マシンを使用して、コントラクト仕様と突き合わせてメソッド呼び出しまたはメッセージの正当性を検証することができる。本発明の他の態様は、OO言語で明示的に宣言されたメッセージの導入に関係する。メッセージ指向言語を採用する従来のシステムが知られているが、有向ペイロード伝送メッセージdirected,payload-carrying,messagesの明示的宣言は、OO言語との組合せであるため、新規性がある。特に、本明細書で説明されているように、メッセージ受け渡しの概念は、OO言語には新しいものであり、従来の概念とかなり異なる。プロトコルをメソッドまたはメッセージの時間的な順序付けのメソッドまたは有向メッセージの集合として表現することについては、他の態様により説明される。より具体的には、この革新技術のこの態様は、OO言語例えば、VB.NETブランドの環境に形式的コントラクトformalcontractを追加することに関係する。宣言されたメッセージまたはメソッドをパターンの字母として使用することにより、通信プロトコルの単純ではあるが十分に形式的なプロトコル定義を設定することができる。コントラクトの概念は、オブジェクト指向言語に関して同じ種類のソフトウェア再利用を継承として実現するメカニズムを付加して増強することができる。特に、主要な概念の1つに、コントラクト拡張extensionがあり、これにより、コントラクトの世代間の非対称的互換性asymmetricalcompatibilityが得られる。例えば、この概念を使用すれば、コントラクトの旧バージョンを使用しているクライアントは、新しいバージョンを使用するようにすでに更新されているサービスと通信することができる。さらに、本発明は、オーケストレーションを対象とする。したがって、メッセージ指向プログラムの非同期的なニーズを取り扱うために、本発明の一態様では、安全な並列処理のいくつかの概念をサポートする言語構文を加える。このモデルは疎結合であるため、プログラムコンポーネントの分散をサポートすることができる。非同期アプリケーションをプログラムする際のプログラマの生産性、開発されたアプリケーションの信頼性、およびアプリケーションソースコードの総合的な可読性の高さが利点の一部としてあげられる。理解しやすくするために、本発明の説明されている態様は、Service、Send、Receive、SelectReceive、Wait、Split、Timeout、InnerServices、Begin、CatchReceive、Accept、SplitSelectReceiveというキーワードに関係するVisualBasicVBを対象とする。併せて、この新しい言語構文は、メッセージ同士を並列に処理するためのモデルを実装することができる。本発明は、疎結合同時実行と密結合並列処理用のコルーチンとをサポートすることができると考えられる。これらの構文については、本書の後の方で詳しく説明する。本発明のいくつかの態様によるコンパイラアルゴリズムを使用することができる。特に、スレッドのコンテキストをブロックすることなく並列ウエイトparallelwaitsが発生するようにコルーチンベースのコードを複数のコード断片に細分するコンパイラのアプローチは、本発明の他の新規性のある態様である。メッセージの到着を待っている間に現在のスレッドを潜在的にブロックする可能性のあるソースコード内のそれぞれの場所を切り離すことにより、複数のそのような場所で並列待機するか、または代替として、スレッドコンテキストで他の何らかの計算を続行するようにできる。前記の関係する目的を達成するために、本発明のいくつかの例示されている態様について、以下の説明および付属の図面に関して本明細書で説明される。ただし、これらの態様は本発明の原理を採用する様々な方法の少数のみを示しており、本発明はこのような態様およびその等価物すべてを含むことを意図している。本発明の他の利点および新規性のある特徴は、図面を参照しつつ本発明の以下の詳細な説明を読むと明白になるであろう。次に、本発明は、本明細書全体を通して類似の番号が類似の要素を示すために使用される図面を参照しつつ説明される。以下の説明では、説明を目的として、本発明を完全に理解できるようにする多数の具体的詳細を述べている。しかし、本発明は具体的詳細を知らなくても実施できることは明白であろう。他の場合には、本発明を説明しやすくするために、よく知られている構造および装置がブロック図形式で示されている。本出願で使用されているように、コンポーネント、システムおよびメカニズムなどの用語は、コンピュータ関連のエンティティ、つまりハードウェア、ハードウェアとソフトウェアの組合せ、ソフトウェア、または実行中のソフトウェアのいずれかを指すことを意図されている。例えば、コンポーネントとして、プロセッサ上で実行されているプロセス、プロセッサ、オブジェクト、実行可能ファイル、実行スレッド、プログラム、および/またはコンピュータなどがある。一例として、サーバ上で実行されているアプリケーションとサーバは両方ともコンポーネントであってよい。1つまたは複数のコンポーネントを1つのプロセスおよび/または実行スレッド内に常駐させることができ、またコンポーネントを1台のコンピュータにローカルとして配置し、および/または2台以上のコンピュータ間に分散させることができる。以下では、本発明の様々な態様について説明する。本開示はVisualBasicVB環境で本発明のシステムおよび方法を採用する態様に関して説明されているが、本明細書で開示されている概念は、本発明の精神、範囲、または機能から逸脱することなくオブジェクト指向OO環境とともに採用することができることは理解されるであろうことに留意すべきである。一般に、本発明の一態様は、VB.NETブランドの環境における言語拡張機能を使用し、メッセージ受け渡し、コントラクト、およびオーケストレーションを通じて非同期プログラミングをサポートすることができるシステムおよび方法を対象とする。つまり、本発明の開示されている態様によれば、VBオーケストレーションでは、プロトコルを記述し、サービスまたはクライアントをそれに応じてコーディングすることができるということである。本発明を使用すると、対話状態を明示的にコーディングし管理する必要性が緩和されることは、理解されるであろう。まず図1を参照すると、本発明の一態様によるオブジェクト指向システム100の一般的なブロック図が示されている。すでに述べたように、理解しやすくするために、システム100は、VBアプリケーション向けであるものとして、本明細書で説明されている。VB環境は、本発明のいくつかの態様について説明するために主に使用されるが、システム100は、本明細書で説明されている本発明の範囲から逸脱することなく知られている任意のオブジェクト指向言語に適用することができることは理解されるであろう。一般に、システム100は、クライアント102、コントラクトコンポーネント104、オーケストレーションコンポーネント106、およびNを整数として複数のターゲットサービス1081~108Nを含むように構成することができる。ターゲットサービス1081~108Nは、これ以降、ターゲットサービス108と総称されることは理解されるであろう。コントラクトコンポーネント104は、ペイロード伝送メッセージ、または複数のメッセージと、それらのメッセージの実装スケジュールを識別する1つのプロトコルとの集合を含むことができる。コントラクトコンポーネントは、代替として、複数のメソッドまたは複数のメソッドの集合の転送を対象とすることもできることは理解されるであろう。オーケストレーションコンポーネント106は、コントラクトを解釈し、サービス108の並列処理および/または同時実行を容易にするように構成することができる。例えば、オーケストレーションコンポーネント106は、複数のメッセージとともに複数のメッセージの複数のターゲットの処理を容易にするように構成することができる。本発明には新規であるが、図1のオーケストレーションコンポーネントは、サービスへ/からのメッセージ受け渡しを介してオブジェクト指向環境とメッセージ指向環境を統合するという基本的な新規性のある概念および革新技術を一層向上させることは理解されるであろう。図2は、本発明の一態様によりコントラクトおよびメッセージを交換する方法を例示する図である。説明を簡単にするために、本明細書に例えば流れ図の形で示されている1つまたは複数の方法は、一連の動作として示され、説明されているが、本発明は、一部の動作が本発明により本明細書に示され説明されているのと異なる順序で、および/または他の活動と同時に発生しうるので、動作の順序によって制限されないことは理解され、認識されることであろう。例えば、当業者であれば、代替として方法を一連の相互に関連のある状態またはイベントとして状態図などの中に表すことが可能であることを理解し、認識するであろう。さらに、本発明により、方法を実装するために例示されているすべての動作が必要なわけではない。202で、コントラクトが宣言される-本明細書で説明されているように、コントラクトの宣言は、複数のメッセージまたはメソッドとともにオプションの展開のパターンをも定義することを含むことができることは理解されるであろう。204で、コントラクト内に具現化されるメッセージまたはメソッドはターゲットサービスに送信される。次に、206で、メッセージまたはメソッドは受信され、遷移が引き起こされる。最後に、コントラクトを実装し、複数のメッセージおよび/または複数のメソッド内に含まれるコードを使用するために、208でメッセージが受け入れられ、その後210で逆コンパイルされる。同時実行モデル再び図1を参照するが、クライアント102とサービス108との間に共有状態がある同時実行には、たとえ熟練プログラマであっても問題があることが実証されていることに留意されたい。様々な力がソフトウェアをクライアント102とサービス108との間の同時実行および非同期相互作用に向けて押し引きするが、正しいものを実現することの難しさが障害となっている。本発明は、正しい同時実行プログラムを書く際の一部の複雑さを緩和するために同時実行モデルを使用するシステムおよび/または方法を対象とする。従来の実装とは反対に、図1に例示されている本発明のVBオーケストレーション例では、インメモリ状態を共有するどの2つの実行行も同時実行とならない。例示されているように、本発明は、サービス108を使用して、同時実行を容易に行えるようにしている。これらのサービスでは、個別のサービスの外部にあるコードと状態を共有しない。さらに、非同期通信を実現するために、図1に例示されている本発明のシステムは、コントラクトコンポーネント104またはメッセージ受け渡し手法を使用するが、これは、言語内に明示的なSendおよびReceive演算として現れ、オーケストレーションコンポーネント106内に実現される。非同期メッセージ受け渡しの導入には、複数のサービス間の通信を同時に管理するメカニズムが必要であることは理解されるであろう。そこで、同時実行サービス間の通信を調整するメカニズムの集まりは、オーケストレーションと名付けられ、図1のオーケストレーションコンポーネント106により使用される。以下で詳述するように、擬似並列実行例えば、Splitを導入する言語メカニズムが示されている。しかし、これらのメカニズムは、実際には、同時実行ではなく同時実行待機concurrentwaitingを実現する。サービス108およびオーケストレーションコンポーネント106の組合せにより、競合状態および同期しないメモリアクセスの危険を冒すことなく同時実行および非同期の動作が可能である。本発明により、2つのサービス間のメッセージ交換は、コントラクトコンポーネント104により管理される対話として生じる。コントラクトコンポーネント104は、サービス108のメッセージング動作の仕様を定め、やり取りする相手のサービスの実装にアクセスせずにある種の形態の正しさ例えば、メッセージ交換のパターンへの適合、デッドロックからの解放について個々のサービス108をチェックすることができる。したがって、サービスの動作を理解する際の主要なアーチファクトはその実装されたコントラクトであることは理解されるであろう。コントラクト図3を参照すると、本質的に、コントラクト104は、より豊富な意味を持つ非同期メッセージ受け渡しのインターフェース宣言として定義することができる。つまり、メッセージコンポーネント302を使用して一組のメッセージまたはメソッドおよび許容可能なメッセージ交換のシーケンスを記述するオプションのプロトコルまたはパターンコンポーネント304を指定するということである。さらに、コントラクトコンポーネント104は、既存のコントラクトコンポーネントを拡張するコントラクト拡張コンポーネント306を使用することができる。図4は、本発明の様々な態様によりコントラクトを宣言する方法202を例示する図である。本明細書で説明されているように、コントラクトの宣言は、複数のメッセージまたはメソッドだけでなくオプションのパターンも定義することを含むことができる。図4を参照し、402に進むと、そこではコントラクトタイプが宣言されている。特に、VBの実施例では、コントラクト宣言は、コントラクト上のクライアントパースペクティブおよびサーバパースペクティブを表す2つのVB型を作成する。例えば、宣言ContractCは、型Cクライアントパースペクティブを表すおよび型ImplementsCサーバパースペクティブを表すを作成する。例えば、以下は、アラームクロックサービスのコントラクト例である。さらに、コントラクトを拡張しスヌーズ機能を追加したアラームクロックサービスのコントラクトを以下に示す。状況を示し、理解しやすくするために、コントラクトの文法および意味について以下で説明する。例を以下に示す。図3を参照しつつすでに説明したように、コントラクトではメッセージの集合302、およびオプションにより、許容可能なメッセージ交換シーケンスを記述するパターン304、および/または図3に例示されているようなコントラクト拡張306を指定できる。パターン304が指定されていない場合、指定されたすべてのメッセージシーケンスが使用可能であることに留意されたい。コントラクト拡張メカニズム306は、エラボレーテッドコントラクトelaboratedcontractを使用して分類されたコネクタとエラボレーティングコントラクトelaboratingcontractを使用して分類されたコネクタとの間の対話が可能であるようにコントラクトに追加するメカニズムである。図4を再び参照し、404に進むと、そこで、メッセージを宣言できる。次に、406で、オプションによりパターンを指定できる。406で指定されたパターンは、状態マシンとして指定できる。これらの状態は、StateTransitionStatementGroups内のラベルで指定できる。上述のアラームクロック例では、開始状態は開始startという名前である。メッセージの送受信とともに他のコントラクトの実行により、状態マシンに遷移が引き起こされる。StateTransitionStatementGroupが複数のStateTransitionStatementを含む場合に、パターンがグループ内にそれらの遷移の1つを許す。408で、パターンに関連して使用されるトリガを定義することができる。特に、MessageTransitionStatement内の矢印の左にある名前はトリガであり、メッセージまたはコントラクトの名前とすることができる。次に、410で、ターゲットが識別される。矢印の右にある識別子はターゲットであり、状態の名前とすることができる。トリガがない場合、ターゲット状態のトリガが発生すると遷移が生じる。トリガがコントラクトの場合、その効果は、コントラクトのパターンの新しいインスタンスの実行である。複数のターゲットがある場合、この遷移はすべてのターゲットに対し並列に行われる。この状況を分割遷移splittransitionと呼ぶ。ターゲットがImmediateの場合、遷移は、最後のトリガが完了したときではなく最初のトリガが開始したときに発生する。これは、特に、トリガがコントラクトの場合に有用であることに留意されたい。一実施例によれば、状態はと等価である。同様に、状態はと等価である。さらに、状態はと等価である。当業者であれば、Or、And、およびThenは、式の構文内のそれぞれOr、And、およびAndAlsoと同じ優先順序関係を持つことを理解するであろう。一態様では、InMessageまたはOutMessageとして与えられたトリガは、適切な方向に進行するコントラクト内で宣言されたメッセージを表すことができる。他の態様では、AnyInMessageまたはAnyOutMessageとして与えられたトリガは、適切な方向に進行するメッセージを表すことができ、コントラクト内で宣言されていないメッセージとすることができる。与えられた状態は、与えられたトリガに関して高々1回の遷移を行うことができる。本発明のシステムおよび方法によれば、状態がメッセージについて遷移する場合、その状態はそのメッセージを受け付ける。状態が複数のメッセージを受け付けることができ、1つの状態により受け付けられるメッセージは必ずしもすべ同じ方向に進行するわけではない。例えば、すべてのメッセージが同じ方向に進行しない場合、反対方向に進行する状態Sにより受け付けられるすべてのメッセージを受け付けるわけではない状態Sにより受け付けられるメッセージに対するターゲット状態はそれらのメッセージを無視する。終了Endへの遷移で、状態マシンの現在の行が終了する。停止Stopへの遷移で、状態マシンの現在の行が終了する。分割遷移がない場合、終了および停止は等価であることに留意されたい。図4を再び参照すると、本発明のシステムおよび方法により、接続を通じてメッセージの送受信を行うことができる。接続は、402で宣言されたコントラクト型である型を持つデータである。このコントラクト型は、コントラクトに名前を付けることにより指定できることは理解されるであろう。その一方で、接続は、コントラクト実装型である型を持つデータとすることができる。コントラクト実装型は、コントラクトの名前の前に指定Implementを付けることにより指定することができる。コントラクト型を持つ接続は、Inメッセージを送信し、Outメッセージを受信することができる。コントラクトImplements型を持つ接続は、Outメッセージを送信し、Inメッセージを受信することができる。分割遷移410で、状態遷移が複数のターゲットを持つ場合、その遷移を並列でのすべてのターゲットへの分割遷移と呼ぶ。例えば、分割遷移は、その分割遷移からの一部の経路がSに収束する場合に部分的に状態Sでマージし、全部の経路が収束する場合に完全にマージする。状態Tが分割遷移の直接または間接ターゲットの場合、分割遷移がTのところでまたはTの前で完全にマージしていない限り、分割遷移を通らないTへの経路はありえない。分割遷移が状態Sでマージする場合、Sからの遷移は、その分割遷移からのすべての経路がSに到着するまで発生しえない。簡単に言うと、分割/マージは適切にネストし、分割/マージの真ん中への遷移はありえない。例を以下に示す。パターンは、メッセージシーケンスM1、M1、M2、M4、M3、M3、M5を受け入れる。S1を含むそれぞれの分割遷移では、M3がマージ状態S3に遷移する必要があり、したがって等しい数のM3およびM1メッセージがありうる。パターンでは、M1をCon1のメッセージと混ぜることができるが、これは、M2がCon1の完了後に発生することを必要とする。このパターンは、さらに、終了をマージ状態とすることができることも例示していることに留意されたい。コントラクト拡張本発明のシステムおよび方法によれば、412で、コントラクト拡張メカニズム例えば、図3の306を採用し、エラボレーテッドコントラクトを使用して分類されたコネクタとエラボレーティングコントラクトを使用して分類されたコネクタとの間の対話が可能であるようにコントラクトに追加することができる。対話の一方の側のみが、使用するコントラクトに関する選択権を有する。決定は、拡張の型によって行われる。文法および意味の例は以下の通りである。ここで、Extendsステートメント内の名前を、包含コントラクトcontainingcontractでないコントラクトまたは包含コントラクトを拡張または精緻化するコントラクトの名前とすることができる。コントラクトBがコントラクトAを拡張する場合、Aのすべてのメッセージは、Bのメッセージである。Aのすべての状態は、Bの状態である。Aによってホストされるすべてのコントラクトは、Bによってホストされる。Bは、Aから継承した状態から遷移を除去することはできない。Bは、メッセージ、状態、およびホストされているコントラクトを追加することができる。Bは、Aから継承した状態に遷移を追加することができる。追加された遷移はすべて、同じ方向に進行するメッセージ用とすることができる。例えば、追加された遷移がInメッセージ用であれば、クライアントは、AまたはBのいずれかを使用してBを実装するサービスに接続することができる。追加された遷移がOutメッセージ用であれば、クライアントは、AまたはBのいずれかを使用してAを実装するサービスに接続することができる。プログラムテキストにおいて、Aの状態は、Bが遷移をそれに追加した場合のみB内で繰り返され、追加された遷移のみが現れる。設計では、継承された遷移は見えているが、不変として視覚的マークを付けられていることに留意されたい。コネクタ図2を再び参照すると、本発明のシステムおよび方法により、動作204と206との間のメッセージ交換は、接続を介して実行される。接続の両端のコードは、コネクタファクトリを介して作成されるコネクタを通じてメッセージの送受信を行う。コントラクト型CTでは、クライアントサイドコネクタは、型CTを有するが、サーバサイドコネクタは型ImplementsCTを有する。オーケストレーションさらに、Split演算は、複数の実行行を生成し、そのどの行も出力するまで実行され、出力されたときに、他の実行行を実行できる。様々な言語演算において、実行行に結果を出力させることができる。そのようなものには、Receive例えば、メッセージの到着を待つ、およびWait例えば、特定の時間間隔の間待つがある。一組のメソッドは、オーケストレーションユニットを形成するか、またはそれらのメソッドの1つの出力結果でのメソッドでの1行が実行可能であれば、オーケストレートするということができる。これにより、呼び出しが戻るまで実行がメソッド呼び出しを通り過ぎるということはないことに注意されたい。オーケストレーションクラスのインスタンスメソッド基本および派生クラス内のメソッドを含むは、所定のインスタンスについてオーケストレートする。オーケストレーションクラスはorchestration修正子を付けて宣言される。オーケストレーションクラスは、共有メソッドまたはプロパティを持ちえない。この態様によれば、オーケストレーション演算はVBステートメントであり、いくつかの制約条件に従うが、どのメソッドにも出現しうる。図2を再び参照すると、204で、Sendステートメントは以下のように構成することができる。この態様によれば、Sendステートメントは、オプションの式である、特定のコネクタを通じてメッセージを送信する。コネクタの式が存在しないことで、メッセージが一次コネクタを通じて送信され、サービス内でのみ許可されることを意味することができる。このコネクタの式をコントラクトまたはコントラクト実装型とすることができることは理解されるであろう。存在する場合、識別子は、コントラクトのメッセージの名前とすることができ、そのメッセージは適切な方向を持ちうる。メソッド呼び出しと同様に、引数は、メッセージのパラメータについて型検査される。Messageキーワードが存在する場合、この式は、System.MessageBus.Messageに変換可能であり、送信するメッセージオブジェクトを識別する。同様に、206で、Receiveステートメントは以下のように構成することができる。Receiveステートメントは、特定のコネクタを通じてメッセージを受信することができ、メッセージが到着するまでブロックする。コネクタの式が存在しない場合は、メッセージが一次コネクタを通じて受信され、サービス内でのみ許可されることを意味する。コネクタの式は、コントラクトまたはコントラクト実装型とすることができ、識別子は、もし存在すれば、コントラクトのメッセージの名前を指定することができ、メッセージは適切な方向を識別することができる。Receiveステートメントで宣言されたパラメータは、ローカル変数宣言と似たスコープに入る。さらに、Receiveステートメントで宣言されていないパラメータは、別の場所でローカル変数として宣言することができる。Messageキーワードが存在する場合、関連するパラメータは、System.MessageBus.Messageとして宣言することができ、Receiveで受信メッセージオブジェクトをローカル変数に割り当てることができる。Messageキーワードが存在し、特定のメッセージ名が与えられていない場合、Receiveは、フィルタ式filterexpressionがもし存在すればそれを満たすメッセージを受信することができる。そのうえ、存在する場合、Receiveの中のWhen式がBooleanフィルタとして動作する。フィルタ式が存在する場合、そのフィルタがTrueに評価されればメッセージが受信され、そうでなければ、他の何らかのReceiveがそれを消費するまで無視される。フィルタ式は、そのフィルタ式が付けられたreceive句のパラメータおよび受信されたメッセージオブジェクトのメンバにアクセスすることができるが、他の非定数宣言にはアクセスできない。フィルタ式が存在しないことは、常に値Trueを持つフィルタ式と等価である。例えば、の形のReceiveステートメントはに等価である。Waitステートメントは以下のように構成できる。Waitステートメントは、型System.TimeSpanとすることができる式により与えられる指定間隔の間実行をブロックする。Waitステートメントを使用すると、間隔が0であっても、1つの実行行で出力できる。Waitステートメントとして形のステートメントはに等価である。注意:Threading.Thread.Sleepは、オーケストレーション内の他の行を実行することを許さずにスレッドをブロックできるので、オーケストレーションコードの内部では使用されないことが重要である。受信されると、遷移を引き起こすことができる。Beginステートメントは以下のように構成できる。識別子は、ローカル変数として宣言することができる。変数の型は、コントラクト型またはコントラクト実装型とすることができる。初期化子initializerは存在できる。Beginステートメントは、指定されたコントラクトにより管理される対話の開始を待つ。当業者であれば、Beginステートメントは一種のインラインサービスを表すことを理解するであろう。このような対話は、他のコード本体がそのコントラクト型の逆のコネクタを作成し、その後そのコネクタを通じてメッセージを送信するときに開始する。対話が開始すると、初期化子が評価され、その値が変数に代入され、実行が続く。Beginは、部分対話の相関関係を求めるためのメカニズムを提供する。相関関係のある部分対話に関し、コネクタの初期化は、コネクタを単独の引数として持つNew式である。接続の他方の側のコネクタは、コネクタを単独の引数として持つNew式により作成済みであろう。その上、引数として与えられた2つのコネクタも接続されていることであろう。Beginステートメントとして形のステートメントはに等価である。最後に、そのメッセージは、208で受け入れることができる。そこで、AcceptStateStatementは以下のように構成できる。AcceptStateStatementは、接続が特定のコントラクト状態に遷移するまで待機する。コネクタの式が存在しないことで、状態が一次コネクタを通じて受け付けられ、サービス内でのみ許可されることを意味することができる。コネクタの式は、コントラクトまたはコントラクト実装型とすることができ、識別子で、コントラクトの状態パターンの状態に名前を付けることができる。Accept状態ステートメントは、メッセージを消費しない。特に、状態遷移を引き起こしたメッセージは消費されない。ブロック解除には、状態遷移が必要である。Accept状態ステートメントが開始したときに接続がすでに名前付きの状態に入っている場合、Accept状態ステートメントは、接続がその状態に再入するまで待機する。AcceptStateステートメントがSelectReceiveステートメントの一部としてだけでなく、catchacceptステートメントの一部としても、特に有用であることは理解されるであろう。Accept状態ステートメントとしてという形のステートメントはに等価である。SelectReceiveステートメントは以下のように構成できる。SelectReceiveステートメントは、メッセージの集合それぞれ異なるコネクタを通る可能性があるの1つまたは複数を受信することができ、および/または1つまたは複数の対話を開始し、および/または1つまたは複数の接続の状態を受け入れるか、またはタイムアウトになり、複数のメッセージ/複数の対話/複数の状態に関連付けられたコード本体、またはタイムアウトを実行することは理解されるであろう。タイムアウト式は、タイムスパンを示さなければならない。複数のCaseReceiveClauseがCaseReceiveStatement内に存在する場合、すべての句の条件が満たされることができ、条件に関連付けられたコード本体の実行がトリガされる。Splitステートメントは以下のように構成できる。Splitステートメントは、実行を適当に複数の論理実行行に分割することができる。これらの実行行は、実行行でメッセージの待機をブロックしたときに必ず次のブロック解除された行が実行されることを除き、語彙順序で順次実行することができる。Splitステートメントのどの2行も同時実行されないことは理解されるであろう。Splitの1行内にあるReceiveステートメントは、Splitの他の行から送信されたメッセージに対する応答を受信することはできない。当業者であれば、これにより特定のメッセージに対する応答を相互に関連付けることができることを理解するであろう。SplitForEachステートメントは以下のように構成できる。SplitForEachStatementGroupの本体は、各反復がSplitStatementGroupの別々の1行であるかのように実行することができる。コレクションを通る完全な反復は、本体の実行前に実行できる。SplitSelectReceiveステートメントは以下のように構成できる。SplitSelectReceiveステートメントは、受信されたメッセージ、開始された対話、およびタイムアウトを処理する実行行をいくつでも自動的に作成する。SplitSelectReceiveステートメントのという形は、と微妙にまたかなり異なっているが、類似している。SplitSelectReceiveステートメントは、1行が終了するのを待つのではなく、1行が出力する場合に必ずアクティブにできる。実行行でSplitSelectReceiveステートメントの外に制御を移すと、SplitSelectReceiveステートメントの他のすべての行を終了することができる。CatchReceiveステートメントは以下のように構成できる。Tryステートメントは、メッセージを受信するハンドラを指定できる。この概念を実装するために、新しい形式のCatchステートメントを使用することができる。CatchAcceptStateステートメントは以下のように構成できる。Tryステートメントは、接続の状態を受け付けるハンドラを指定できる。この概念を実装するために、新しい形式のCatchステートメントを使用することができる。新しいExitステートメントを考える。例えば、新しいexitタイプとしてLineとSplitが考えられる。これらは、Split、SplitForEach、およびSplitSelectReceiveステートメント内で適用され、他の場所では使用できない。ExitLineステートメントは、Split内の実行行を終了させることができる。ExitSplitステートメントは、Splitを抜けて、Splitの他のすべての行を終了させることができる。何らかの形のSplitを終了する制御権の移転が他にあればそれらは、ExitLineの意味ではなく、ExitSplitの意味を持ちうる。サービス図2を再び参照すると、次に、コントラクトは210で実装される。本発明によれば、サービス例えば、図1のサービス108は、コントラクトの実装を備える。サービスは、サービスのコントラクトの開始メッセージを受けとると、自動的にインスタンス化される。サービスがそのコントラクトを実装するために使用するコネクタは、自動的に初期化され、メッセージの送受信に暗黙のうちに使用することができ、したがって、Primaryと明示的に呼ぶことができる。説明されている態様によれば、サービスは、パラメータを持たず、したがって結果を返さないRunという名前のインスタンスメソッドを持つことができ、このサービスをアクティブ化すると、Runを呼び出す。サービスは、RuntimeServiceから直接的にまたは間接的に派生するオーケストレーションクラスである。基本クラスが指定されていない場合、これは暗黙のうちにRuntimeServiceである。再びすでに提示されているアラームクロック例を参照すると、上述のアラームクロックコントラクトを実装するサービスは、以下のように構成できることがわかる。さらに、以下では、サービス例は、前の例のスヌーズアラームクロックコントラクトを実装するように構成されている。次にサービスの文法および意味については、以下の通りである。上記によれば、サービスは、1つのImplementsステートメントと任意のMessageステートメントの両方を持つことはできない。しかし、Implementsステートメントが存在する場合、1つあり、それは単一の型に名前を付けることができ、その型はコントラクトとすることができる。サービスは、コントラクトを実装する暗黙の一次コネクタを備えることができる。実装されたコントラクトは、Implementsステートメントで名前を付けることができる。サービスがImplementsステートメントなしで宣言されている場合、そのサービスにおいて、その一次コネクタを通ることができるメッセージを宣言することができ、パターンはサービスのメソッドから派生される。つまり、サービスはどれも、コントラクトを実装するということである。一次コネクタは、サービス内でPrimaryとして利用可能である。コネクタの式がSendまたはReceiveステートメントから省略された場合、コネクタは、暗黙のうちにPrimaryとすることができる。サービスを呼び出すと、サービスの実装されたコントラクトとして分類されているコネクタの新しいインスタンスを返す。本発明のより一般的な説明に入るが、n層または一般的に分散環境におけるクライアントおよびサーバのことを話す場合、混乱を避けるために用語を十分厳密に定義することが重要である。例えば、VB環境では、サービスクライアントは、メッセージが送信されても開始されないオーケストレーションオブジェクトのことである。つまり、サービスクライアントは、他の何らかの方法で起動することができる。その一方で、サービスは、メッセージが送信されることによって作成されるオブジェクトである。サービスを起動する方法は他にないということは理解されるであろう。ある程度ゆるやかな概念として、クライアントは、サービスとの通信を開始する、サービスであろうとサービスクライアントであろうと、コードの断片のことである。コントラクト再び一般的にコントラクトについて言及すると、コントラクトはプロトコルおよびそのメッセージを指定するためにOO言語例えば、VBで使用することができる。この説明では、以下に示すようなコントラクトインポートステートメント、メッセージ宣言ステートメント、および単一パターン定義ステートメントの3つの部分を重点的に取り上げる。上記は、Stringだけを受け渡すRequestと呼ばれるインバウンドメッセージの定義である。同様に、これもまたStringだけを受け渡すResponseと呼ばれるアウトバウンドメッセージが定義される。メッセージ自体は、名前であって、データの塊ではないことに注意されたい。むしろ、メッセージ自体は、そのメッセージの識別子であり、その点ではクラス名に類似している。データは、メッセージのパラメータとして定義することができる。さらに、プロトコルがセッションで2つのメッセージ、つまりRequestおよびResponseのみを許容することも定義される。相互作用でのこれら2つのメッセージの方向は、それぞれのメッセージ宣言により暗示される。一方の人のインバウンドメッセージは、他方の人のアウトバウンドメッセージであることは理解されるであろう。本発明によれば、このパースペクティブは、コントラクトを実装するサービスのパースペクティブからのものである。プロトコル上のそれぞれの相互作用は、対話、メッセージのやり取りを行う2者を伴い、それによって、互いの内部状態に影響を及ぼすか、または有用ないくつかの外部影響を有する。2者のそれぞれのそのような結合において、分かりやすくするため、両者を実装側と使用側とラベルを付けて明示する。開示されている態様のVBオーケストレーションでは、これは、コントラクトパースペクティブと呼ばれる。コンパイラでは、インバウンドメッセージが実装側により送信されること、または使用側により受信されることを許さず、またアウトバウンドメッセージが実装側により受信されること、または使用側により送信されることも許さないことは理解されるであろう。上記のコントラクトは、本質的に、同期メッセージ受け渡しメカニズムで許容している複雑さである、つまり一方のメッセージが一方向に出て、他方のメッセージが応答として戻ることが観察される。戻りデータ、またはプロシージャ呼び出しでパラメータがない場合、対応するメッセージは、それに応じて調整されるが、同期パターンで単一のインバウンドメッセージの後に単一のアウトバウンドメッセージに続く。以下で説明するように、プロトコルは、様々な多数の方法で定義することができ、VBオーケストレーションを使用することにより、完全なプログラムでこの技術を容易に利用することができる。本質的に、コントラクトを採用することにより、メッセージおよびパターンを宣言することが可能である。しかし、コントラクトは、膨大なレベルのセキュリティおよび堅牢さをプロトコルの実装に加えることができるが、それは、コンパイラを使ってコードがプロトコルに準拠していることをチェックすることができるからである。最低限、コントラクトの強制は実行時に行われ、多くの場合コンパイル時に行われる。本発明によれば、コントラクトは、開示されている態様のVBオーケストレーションにおける基本的な言語追加機能のうちの1つである。以下に、コントラクト宣言に関係する詳細説明を続ける。メッセージ宣言図4を再び参照すると、上記の例では、コントラクトを宣言する方法を示している。特に、404で、メッセージを宣言する動作が例示されている。当業者であれば、これらは、本質的に、以下の制約条件を持つ、Sub宣言として類似の一般的規則を共有することを理解するであろう。1.ByValであるすべてのパラメータ。Optional、ByRef、またはParamArray宣言は、使用できない。2.リモートで使用されるプロトコルについては、すべてのパラメータはシリアライズ可能である。3.すべてのメッセージは指定された方向を持たなければならない。4.メッセージはオーバーロードできない。パターン宣言次に406のパターン宣言を参照すると、パターン宣言の最も基本的な構成要素は、メッセージ参照である。上述の例では、パターン内で参照するときのみメッセージの名前に言及するだけでよいことは理解されるであろう。これは、その方向がよく知られているからである。さらに、いったん宣言されてしまうと、オーバーロードは許されず、方向およびパラメータの型を超えてメッセージに追加制約条件を課すことはできない。例えば、上記の例の文字列引数は、それが望ましい制約であれば、非ヌルでなければならないと指定する方法はないことに留意されたい。パターンは、プロトコルの名前付き状態の集合、例えば、それに対する何らかの意味を持つ対話における異なる位置を定義することにより宣言される。パターンの第1の状態は、Beginと呼ぶことができる。状態が定義されると、プロトコル状態の変化の仕方を示す状態遷移を追加することにより、プロトコルを完成させることができる。トリガおよびターゲットは、動作408および410に関して識別することができることは理解されるであろう。一態様では、そのような遷移は、メッセージによりトリガされる。他の態様では、それらのメッセージは、複数のメソッドまたはインポートされたコントラクトにより表すことができる。例を以下に示す。上述のように、RequestThenResponseという句は、遷移トリガであり、Endは遷移の終了状態である。遷移トリガは、言い換えると、複合トリガであってもよい。例えば、複合遷移トリガは、Thenを使用してメッセージの集合を順序付けるか、またはAndを使用して順序付けなしでグループ化することにより使用することができる。その上、メッセージ名の間にOrを使用してトリガの代替集合を指定することも可能である。遷移は、トリガのすべてのメッセージが送信されるか受信されるとすぐに発生する。遷移終了状態は、複数の状態であってもよい。例えば、遷移を2つ以上のターゲット状態に分割することができ、これは、プロトコル位置が複数の名前付き状態により一度に定義されることを意味する。一態様では、ターゲット終了状態は、さらに、修正子Immediateを付けることもでき、これは、その状態への遷移は、完全なトリガが完了するのを待つのではなく特定のトリガと一致すると即座に発生することを意味する。これは、トリガがコントラクト名を含む場合に特に有用である。すでに説明したように、パターンを持たないコントラクトは任意のメッセージ交換パターンを許容し、空のパターンを持つコントラクトはメッセージ交換を許さないことは理解されるであろう。コントラクト拡張さらに、本発明のいくつかの態様は、図4に例示されているように412で、コントラクト拡張を採用している。図5は、コントラクトの拡張を容易に行えるようにする方法を例示している。この方法によりコントラクトを拡張することで、旧バージョンと非対称的に互換性のある新しいバージョンを作成することができる。特に、コントラクトを拡張する場合に、502で、新しいメッセージを追加できる。その上、504で、新しい状態を既存のパターンに追加することができる。さらに、以下のようにいくつかの制約条件に応じて、506で新しいトリガを既存の状態に追加することができる。1.曖昧性が入り込まない。2.既存のトリガを変更できない。3.既存の状態に追加されたトリガはInとOutの両方のメッセージを第1の可能なメッセージとして持つことはできない、つまり、メッセージの方向は同じでなければならない。4.トリガが既存の状態に追加され、トリガがInメッセージである場合、既存の状態に追加されたすべてのトリガはInメッセージのみを含む。5.逆に、トリガが既存の状態に追加され、トリガがOutメッセージである場合、既存の状態に追加されたすべてのトリガはOutメッセージのみを含む。これらの制約条件により、コントラクト再利用のモデルは、クラスに関する継承に類似している場合がある。一態様では例えば、Inメッセージのみが既存の状態に追加される、新しいコントラクトはクライアント互換client-compatibleであり、他の場合には、サービス互換service-compatibleである。クライアント互換コントラクトは、クライアントに知らせずに、サービスを旧いコントラクトから新しいコントラクトにアップグレードできることを意味する。つまり、旧いコントラクトを使用しているクライアントは、決して、新しい状態への遷移をトリガするメッセージを送信しないということである。その一方で、より新しいコントラクトを認識するクライアントは、サービスがその新しいコントラクトをサポートしている場合のみそのコントラクトを利用することができる。したがって、この関係は非対称互換であることは理解されるであろう。その一方で、コントラクトがサービス互換である場合、クライアントは、新しいコントラクトを使用するようにアップグレードすることができ、旧いコントラクトまたは新しいコントラクトのいずれかをサポートするサービスとの対話を持ち続ける。以下に、すでに提示されている要求/応答例の修正バージョンを使用した例を示す。クライアント互換の例:上のコード例に示されているように、クライアントのみが旧いコントラクトを認識している場合でも、新しいメッセージがまったく送信されない限り、コントラクトは交換可能であるため、新しいコントラクトをサポートするサービスに接続することができる。上に示されているように、サービスは、旧いコントラクトを使用するクライアントと新しい特徴を単純に利用しないだけのクライアントとの違いを区別することはできない。サービス互換の例:ここで、サービスは、既存のコントラクトを超えるかどうかを決定することができる。したがって、アップグレードされたクライアントは、サービスが旧いコントラクトを使用するのか、それとも新しいコントラクトを使用するのかを見分けることはできない。拡張されたパターンでは、新しい情報のみ、つまり新しい状態、および既存の状態に対する新しいトリガがリストされることに注意されたい。これは、エラーの発生源を回避し、明確さが必要な場合は、旧いコントラクトパターンをコメントとして含めることができる。コントラクトAは、ホストされているコントラクトを追加し、メッセージを追加しないことにより、コントラクトBを拡張することができることは理解されるであろう。この場合、AはBと対称的互換である。コントラクトのホスティングについては、本明細書の後の方で詳述する。コネクタコントラクトを使用することにより、それらを参照するものを宣言することができる。例示されている態様によれば、他のコードとの通信のためにVBオーケストレーションベースのコードで使用するオブジェクトは、Connectorと呼ばれる。型に関する限り、Connectorはコントラクト参照型である。Connectorには風変わりなところがある。例えば、Connectorは、その型の一部である明確に定義されたコントラクトパースペクティブを持つ。いずれも、コントラクトの実装側、または使用側を表す。実装側コネクタを使用側コネクタに、またその逆にも、割り当てることはできない。これらの規則に従うと、コネクタをどのように作成するか、それが実装側であるか使用側であるかをどのように定義するのかについて不思議に思うのももっともである。コネクタは、ランタイム例えば、VBランタイムにより定義することができるコネクタファクトリを使用して作成することができる。ほとんどのコネクタファクトリは、サービスURLまたは他のコネクタから作成される。URIは、ここでは、サービス参照と呼ばれる。これは、コンフィギュレーションファイル内に保持される何らかのよく知られているURIとすることができ、あるいは他の何らかのブローカサービスにより実行時にまとめることも可能である。例えば、最もよい取引の場所を決定し、その卸売業者へのURIを要求者側に送り返す卸売業者入札サービスが考えられる。コネクタファクトリが用意されると、コネクタファクトリクラス内に組み込まれる対話演算子を使用してConnectorを簡単に作成できる。このステートメント例では、コネクタファクトリによりアドレッシングされ、その一次コネクタ上にCtRequestResponseを実装することができるサービスを参照するパースペクティブ使用コネクタを作成する。このようなコネクタファクトリの使用により、使用側コネクタを生成することができる。コネクタファクトリは、以下のように、実装パースペクティブのコネクタに直接バインドすることもできることは理解されるであろう。この態様は、両方の側が同じアプリケーションドメインにあり、分離される必要がないことがよく知られている状況では有用な場合がある。分散されないようにするコードをアプリケーションに追加する必要があるので、一般的には、推奨されないが、特別な場合のパフォーマンスに関しては有用である。前の例は、パースペクティブ使用コネクタである。他方で、実装側コネクタは、2つの点で異なるように宣言することができる。特に、コネクタ名は、キーワードImplementsで修正することができ、また初期化子の式は、以下のように引数なしのコントラクト呼び出しでなければならない。パースペクティブ使用コネクタが初期化されると、これは、対応する実装側コネクタにバインドされるが、実装側コネクタは、バインディングを開始せず、したがって、サービス参照をパラメータとしては必要としない。そのため、その結果得られるコネクタは、作成された後バインド解除され、何らかの使用側コネクタが新しいコネクタにバインドされるまでメッセージの送信には使用できない。サービスは、すでに定義されているように、一次コネクタと呼ばれる暗黙の実装側コネクタを持つことに注意されたい。これは、サービスが起動される前にランタイムアルゴリズムにより作成され、Primaryフィールドとしてスケジュールに利用することができる。メッセージの送信および受信の際に、一次コネクタは、参照されているコネクタがなければ暗黙のうちに含まれるため、実際に一次コネクタを明示的に参照するコードを見ることは滅多にない。以下で詳しく説明するが、一次コネクタは、多重化のためサービス参照を作成する場合に使用することができる。コネクタは、参照型の変数が宣言できる場合に必ず宣言することができる。例えば、コネクタは、VBモジュールなどでは、ローカル、パラメータ、および/またはフィールドとして宣言することができる。これらは、オブジェクト参照と同様に、参照により受け渡され、他の変数にコピーされるようにできる。本発明の一態様によれば、コネクタのパースペクティブはいっさい変更できない。さらに、コンパイラでは、強固な分類によりこれを保証することができる。したがって、この態様では、コネクタ、または一般的にはサービスを定義するか、または使用するどのようなソースファイルにおいてもOptionStrictOffを使用することは許可できない。セッション本発明のオーケストレーションに関する新規性のある一態様では、スレッド、プロセス、またはスケーラブルなマルチスレッドアプリケーションに関する典型的な課題である他の態様に関する問題を軽減することができる。適切な取り扱いと予見とにより、スレッドおよびプロセスの分離は、アプリケーションの開発問題ではなく、アプリケーションの分散および管理問題となりうる。しかし、非分散アプリケーションに関して通常は問題とならないが、VBオーケストレーションには本質的である概念の1つに、セッションという概念がある。以下の例は、理解を助けるために掲載する。インターネットを使用して金融機関サイトでショッピングまたはアクセスを行い、口座情報または支払い請求書にアクセスしたことのあるユーザは、分散アプリケーションの意味でのセッションに慣れていることであろう。特に、電子商取引サイトがアクセスされ、商品がショッピングカートに追加されたり、MyAccountページがアクセスされたときに、Webサイトソフトウェアは、いくつかのオブジェクトをメモリ内に割り当てて、訪問者およびログインしている間に実行された操作内容を記憶しておかなければならない。このデータは、一時データであり、通常データベースに格納されている長期間にわたって存続する注文情報または口座情報と異なる場合がある。この一時データの寿命が、セッションと呼ばれる。非分散アプリケーションでは、データは、ゴミになるまでメモリ内に保持しておくことができる。他方、この状況は、分散アプリケーションではまったく異なる。分散アプリケーションに関しては、2つの主要な問題がある。まず、アプリケーションノードにまたがったオブジェクト参照は存在しない。第2に、セッションがいつ終了されたかを通知されることに頼れない。第1のポイントは、オブジェクトを片づけるためにガベージコレクションに依存していたとすると、すべての一時データはたちまちゴミのように見えて、除去されることになることを意味する。すると、アプリケーションノードは、訪問者が以前そこにいたことについてすべて忘れてしまうので、これは面倒なことであろう。したがって、そのようなソフトウェアは、セッション固有のデータ構造を、通常はある種の大域的コレクションの中に割り当てることができ、同じセッションにおいて新しい要求が来たときにその構造を取り出す。次に、第2のポイントとして、セッションがいつ終了したかがわからないと、セッションデータは、決して、ゴミにはなることがないということであり、大域的コレクションはメモリリーク問題が生じるということについて有名である。これらの問題に対処するために、セッションには通常時限が定められる。タイマーは、セッションが最初に作成されるときにセットされ、メッセージまたは要求が入来する毎にリセットされるようにできる。Webユーザのログアウトなどでセッションが終了したと判断できる場合、その時点でデータが除去される。それが判断できない場合、タイマーが停止したときに、セッションデータが大域的ハッシュテーブルから除去され、データはゴミになる。妥当なタイムアウト間隔の決定は完全にアプリケーションに依存することは理解されるであろう。Webサイトでは、通常、タイムアウト間隔を10から30分の間に設定するが、それが普遍的に有効な設定であるとは限らない。一部のアプリケーションで2、3秒が適切であるが、他のアプリケーションでは数時間が適切な場合もある。VBオーケストレーションの例によれば、これはすべて自動的にサポートされる。一態様では、既定のタイムアウト値は10分である。10分が適切でない場合は、App.configファイルでタイムアウトを再構成するとよい。この再構成については、以下のApp.config設定で詳細に説明される。スケジュールが最初に開始すると、それがサービスであろうと、サービスクライアントであろうと、そのセッションは他の何かが発生する前に作成することができる。セッションは、実際にはサービスクラスのインスタンスである。しかし、これは、クライアントが参照に使用する大域的に一意の識別子を割り当てられる。したがって、セッションは、サービスインスタンスとも呼ばれる。後者は、メモリ内の特定のオブジェクトを参照していることを示す必要がある場合に特に有用であるが、前者は、分散アプリケーションパースペクティブから見たい場合に特に有用であることは理解されるであろう。サービスインスタンスは、通常、それに関連付けられた多数のコネクタを持つ。最初に、複数のコネクタをそれらを作成したスケジュールにのみ結合できるが、メッセージを他のスケジュールに送信するために、コネクタを、常に同じコントラクトであるが反対のパースペクティブの他のコネクタにバインドすることができる。バインドされた後、コネクタは再バインドすることはできない。上記の例を参照すると、作成された第1の3つのコネクタは、サービスまたはコントラクト呼び出しが戻ったときにすべてバインドされる。第4の場合にはそうではない。これは、コネクタは他の何らかのコネクタがバインドに使用するサービス参照を作成するためにしか使用できないからである。それが発生すると、通信が開始することができる。上記のWebサービス例では、セッションを処理するソフトウェアがセッション自体の外部にセッション固有のオブジェクトへの参照を格納しないことが重要である。そのようにすることは、セッションが除去される場合に、それらのオブジェクトがゴミにならず、セッションの主要な目的の1つである、分散アプリケーションでのオブジェクトの寿命を制御することが違反になることを意味する。アプリケーション全体が最初は同じアプリケーション領域内にある場合であっても、VBオーケストレーションをプログラムする際にこれが行われることが等しく重要である。セッション中に作成された参照がスケジュールの外部に格納できるようにしても、アプリケーションがスケーリングするようにするかしないかを最終的に決定する大域的システム資源の自動管理を行うことはできない。この規則は単純である-データ状態への参照を、サービスまたはスケジュールの本体内で宣言されている参照内に格納するだけである。つまり、どのような種類であっても大域的変数またはコレクションには格納しないということである。この規則は、従うのは簡単であり、非常に妥当である。その上、この規則は、その性質上他のソフトウェアの基本的な再入規則に非常によく似ている。例えば、大域的状態を避けて、代わりに、常にデータをパラメータとして伝える。データがアプリケーションレベルのデータとして属している、つまりデータがアプリケーション領域内の複数のセッション間で共有される場合に限り、セッションの外部で宣言し、格納すべきである。そのときでさえ、これは、再考を要するアプリケーションの設計に関して何かあるのではないかという危険を知らせる赤旗として使用すべきである。スケジュールオーケストレーションそこで図6を参照すると、オーケストレーションコンポーネントの一般的なブロック図が示されている。図に示されているように、オーケストレーションコンポーネントは、実装またはスケジュールコンポーネント602およびコンパイラコンポーネント604を含むように例示することができる。本発明によれば、スケジュールコンポーネント602は、ソースコードのマニフェストを持たないが、それでも、以下のセクションを理解するうえで欠かせない実行時概念である。簡単にいうと、スケジュールコンポーネント602は、メッセージ指向コードが複数のメッセージを並列方式で待機できるようにするために使用される実行時オブジェクトである。抽象的にいうと、VB環境例に関して、すべてのメソッドは、スケジュールが完了したときにメソッドが戻るために使用されるスケジュールを持つ。具体的にいうと、下記のようにメッセージ受信または待機ステートメントを含むメソッドのみがスケジュールを必要とするということである。VBコンパイラを使用すると、必ず最も効率のよい実装がスケジュールフリーの実装で使用される。このような実行時定義が与えられた場合、スケジュールは、複数のメソッドに分割されるか、または単一のメソッド内に含まれる、メッセージ関係コードの本体としてをおおまかに説明することができる。後者の場合は、既定であり、例えば、メッセージングコードを持つそれぞれのメソッドはそれ自体のスケジュールを定義する。他方で、前者は、オーケストレーションクラスを使用して実装され、これらは、クラスSystem.Orchestration.RuntimeOrchestrationから直接的にまたは間接的に発生されるすべてのクラスである。オーケストレーションクラスは、1つのインスタンス上ですべてのメソッドに対する単一のスケジュールを共有する。スケジュールは、インスタンスメソッドへの外部例えば、Meを使用しない呼び出しにより起動することができ、オリジナルメソッドが戻るまでその同じインスタンス上ですべての内部メソッド呼び出しにまたがって拡張する。オーケストレーションクラスは、必要な基本クラスを持つことを除きあらゆる点で通常のクラスに類似しており、共有メソッドまたはプロパティを宣言することはできない。サービスさらに、本発明によれば、サービスは、クラスSystem.Orchestration.RuntimeServiceから例えば、他のサービスから直接的にまたは間接的に派生することができるオーケストレーションクラスを参照する。そのうえ、サービスはランタイムにより自動インスタンス化される。状況を設定するために、以下の説明では、1サービスの一次コネクタが実装するコントラクトおよび2その起動のメソッドというサービスに関係する2つの概念を明確にする。第1に、コントラクトは、1Implementsステートメントで名前による指定、または2スケジュール本体からの派生の2つの方法で定義することができる。前者の例を以下に示す。ここで、コントラクトは、すでに説明されている要求/応答である。例えば、サービスは、株価表示器記号を文字列として受信し、最後の売買での価格の文字列表現で応答する。もちろん、応答に対し異なるデータ型を使用することもよい考えであろうが、ここで重要な点は、適切なコントラクトをどのように設計するかではなく、サービスでコントラクトをどのように使用するかである。サービスは、使用側コネクタをサービス起動直前に作成された実装側コネクタにバインドするサービスにメッセージを送信することによりサービスを呼び出すクライアントにより常に開始される。コントラクトおよびスケジュールを指定し、多数のサーバ上の多数のプロセスで利用可能にできる、サービス定義、およびそのサービスの特定のセッションを表すサービスインスタンスを別にすることが重要である。サービスは、型定義であり、サービスインスタンスはオブジェクトであることは理解されるであろう。しかし、実際には決してサービスインスタンスへの参照を持つまたは使用することができるわけではないので、この関係を見ることはときに困難である。サービスは、コネクタを介してのみ相互作用する。メッセージングがサービスと相互作用する単一の手段である場合に限り、拡張可能なアプリケーション設計をシステムでサポートするために必要な方法で再配置または複製することができる。したがって、サービスは、New式を使用してコンストラクタを定義すること、または割り当てることはできない。サービスが実装するコントラクトを指定する第2の方法では、コンパイラを使用してスケジュールに含まれるコードからそのコントラクトを派生させる。ここで、コンパイラは、コードを解釈するためにコードを切り分ける。つまり、コントラクト定義を書かなくてもよいということである。このメカニズムを使用するために、一次コネクタ上で使用されるメッセージを宣言するだけである。そのようなサービスのコントラクトを使用してコネクタを作成できるようにするために、そのサービスに対し派生するコントラクトには、<service-name>.Contractという予測可能な名前を付けることができる。しかし、すべて便宜をはかるためにコントラクトを派生すると、抽象性を欠くことになる。理解されるであろうが、コントラクトは、プロトコルで何が続いているかを正確に説明するために使用される。派生コントラクトは、常に正しいサービス実装がそうである限りが、可読性または使い勝手を保証するわけではない。これは、サービスの内部構造を直接反映し、クライアントをまとめようとするプログラマにとっては理解しにくいことがある。また、コンパイラ側で処理するのが難しく、しかもその結果非常にリベラルなものとなる状況もある。サービスは、一度起動すると、同じアプリケーション領域にあろうとなかろうと、呼び出し側コードと並列に実行することができる。同時実行性について述べることは何もなく、単に並列処理であるというだけであることに注意されたい。この2つは、メッセージングを通じてのみ同期しデータを共有している限り、互いの制御の流れとは無関係に書いて実装することができる。異なるサービスインスタンスが同時実行される例えば、別のスレッドまたはプロセスでことは必要ないか、または実行されないことに注意されたい。メッセージング前の説明に鑑みて、次に、クライアントサイドまたはサーバサイドのいずれかにプロトコルを実装するコード本体として定義することができるスケジュールの概念に注目することにする。スケジュールの見方については、1スケジュールを、メッセージを送信し、メッセージをポーリングする手順として見ること、または2手順のとは根本的に異なる、実行モデルを詳細に見ることの2通りがある。本明細書ですでに説明したように、プロトコルハンドラの単純な実装は、何らかのメッセージ送信APIを通じてメッセージを送信し、他のAPIを使用してメッセージをポーリングするメソッドとしてであろう。それぞれのサービスインスタンスは、この従来のモデルでは、自実行スレッドを持たなければならず、これは拡張可能でもないし、環境の実行時のチューニングを許すわけでもない状況である。従来、それぞれのサービスインスタンスは、別々のスレッドを必要とし、それだけのことである。オペレーティングシステムOSでは、どのスレッドがいつ実行するかを決定し、アプリケーションオペレータ側で利用できるチューニングコントロールはない。この従来のアプローチの最初の問題は、必要とする割り当て済みスレッドが多すぎること、OS例えば、カーネル資源の負担大、さらにメモリフットプリントの著しい増大などである。サービスインスタンスが出入りする毎に、OSスレッドの作成と破壊を繰り返さなければならず、負担が大きく、しかも、一度に限られた数のスレッドをアクティブに保持できる例えば、1つのサービスインスタンスに1つ必要スロットルがない。さらに問題を複雑にしているのは、バイナリコード内の低レベル位置が対話状態を含むものであるという点である。したがって、サービスインスタンスを他のマシンに移動したり、ただ単に対話状態を検査することは困難であろう。そこで、本発明のシステムおよび方法では、プロトコルハンドラ例えば、サービスの妥当な実装に対する2つの基本的な態様がある。第1に、プロトコルハンドラの実行環境に関する仮定があり得ないということである。ハンドラ毎に1つのスレッドがありうるか、または複数のスレッドを重なり合う寿命を持つものであっても複数のサービスインスタンス間で共有できる。第2に、対話状態は、コードではなくデータで表現することができるということである。2番目に述べたことは、データでの実装というよりもむしろ対話状態の流れの宣言に関して前に述べたことに反していると受け取られるおそれがあるが、開発者は対話の流れを宣言的に見ることができるべきであるというのが意図であった。それでもランタイムモデルは、対話状態がデータで表現されるモデルである必要がある。つまり、単純ナイーヴモデルはプロトコルハンドラのソース例えば、プログラマの視点では適切であるが、ランタイムモデルは非常に異なる場合があることは理解されるであろう。当業者であれば、このギャップに橋渡しすることで、VBオーケストレーションが生産性および可読性の高レベルの向上をなんとか達成することを理解するであろう。次に、スケジュールコードは、ソーススケジュールのすべての論理を含む別のクラスにコンパイルされるが、異なる同時実行モデルをサポートするように再配置される。スケジュールを起動すると、コードは、休止イベント別名、降伏点yieldpointが発生するまで実行される。休止イベントが発生すると、スケジュールは実行を停止し、それを起動したスケジューリングランタイムに、または最後に再開したイベントのサイトに制御を返す。現在のところ、唯一の再開イベントは、メッセージ到着、メッセージタイムアウト、およびウエイトステートメントの完了である。スケジュールを一時停止した後、そのスレッドは何か好ましいことに使用するためにランタイムに戻されるか、または破壊されるが、すべて基盤のランタイムのスレッドモデルに依存する。より高度なホスティングフレームワークは、そのすべての活動に対しスレッドプールに依存する可能性があるが、より基本的なホスティングフレームワークでは必要になる毎に新しいスレッドを作成する場合のあることは理解されるであろう。スケジュールのコードは、いずれにせよ,何も仮定を置くことはありえない。非サービスコンテキストでの第1の休止イベント例えば、メソッドの呼び出しでは、使用されるスレッドをスケジュールが完了するまでブロックさせることができることに注意されたい。メッセージが届き、特定のサービスインスタンスに経路指定され、それを待つ休止中の受信があることが判明した場合、ランタイムによりReceiveステートメントの後の本体を保持するメソッドを呼び出すことができる。この呼び出し点は、次に、新しい再開部位別名、継続点continuationpointとなり、この呼び出しは、スケジュールが再び休止するまで戻らない。つまり、スケジュールは、データとして公開される対話状態を持つコールバックとして実装されるが、コードはそれでも、ポーリングコードとして出現し、その場合、その対話の流れは、VB.Netの例におけるおなじみの言語要素languageconstructsを使用して宣言される。本発明によれば、スケジュール内のメッセージ処理および並列処理のため適切な言語追加を行うことができるが、ほとんどの場合、スケジュールコードは、通常のVBステートメント、つまり、ループおよびifステートメントから例外ブロックおよび変数宣言にいたるまでのすべてからなる。メッセージの送受信プロトコルコード内のほとんどの基本的なオペレーションは、クライアントサイドであろうとサーバサイドであろうと、接続の一方の側でメッセージを送信し、他方の側でそれを受信することである。はじめからのオペレーションでは、メッセージは、受信する前に、送信しなければならず、そのようにする構文は非常に簡単である。要求/応答コントラクトについては、すでに説明されている。Sendステートメントは、ある種のコネクタを持つことができる。コネクタは、スケジュールがサービスであり、Sendが一次コネクタ上で動作する場合に暗黙のコネクタである。この例では、クライアントは、最初にサービスに接続する。前に述べたサービスクライアントの呼び出しの場合と異なり、Sendステートメントは値を返さないことに注意されたい。非同期メッセージ受け渡しの核心は、すべてのデータ受け渡しを明示的にすることであり、したがって、双方向通信にはそれぞれの側で送信と受信を必要とすることは理解されるであろう。サービス側、つまり、実装側では、メッセージは以下のように処理されるであろう。このステートメントではコネクタ参照がないことに注意されたい。サービスは、その一次コネクタ上でメッセージを受信する。応答のため、サービスは、コントラクト定義に従って、その結果を文字列値として送り返す。株価情報サービスはまったく信頼できず、そのデータ収集戦略においてはかなり静的であるという事実を別にすれば、ただそれだけのことである。そこで、メッセージは他方の側で受信されなければならない。例示されているように、メッセージパラメータがReceiveステートメントの外に出る場合の変数が宣言されている。上記の例は、完全なスケジュールベースのアプリケーションの表現である。以下では、コード全体が1箇所にある。OptionStrictOn例えば、VBオーケストレーションでは、現在、厳密モードコンパイルを必要としているなどのステートメントをファイルの先頭に追加するか、または何らかのappコードをサービスクライアントに追加することにより、他にコンフィギュレーションの設定を行わずにコードを実行することができることは理解されるであろう。このコードは、sample-1ディレクトリの下にある。これらのステートメントの実行モデルによれば、Receiveステートメントが実行され、すでに利用可能なそれと一致するメッセージがない場合、スケジュールは休止する例えば、それが使用しているスレッドを放棄する。メッセージが利用可能であれば、休止しないが、実行は次の行へ即座に継続する。Sendステートメントは決して休止しない-メッセージが基礎のシステムによって受け付けられるとすぐに、そのステートメントは終了する。メッセージがスケジュールに届くと、ランタイム側でそのスケジュールがその種のメッセージを待つのを休止したことを検出した場合、スケジュールは、通常、ランタイムが使用しているのと同じスレッド上で即座に再開される。これではコントラクト言語で表現できる強力なすべてのプロトコルに対し十分でないと誤って信じる可能性がある。例えば、様々なメッセージが一度に入って来るのをシステムが待つ状況、例えば、同じ状態からの2つの遷移、または複数の順序付けされていないメッセージによるトリガ、または分割されたコントラクト定義である。これらの他の遷移状況を取り扱うために、VBオーケストレーションでは、一組のメッセージのうちから1つのメッセージの受信を処理するselectステートメントの一変種を定義する。このコード例では、2つのメッセージRequestおよびItsOver1のうちの1つだけがこのステートメントで受信される。しかし、以下に示されているように、AおよびB任意の順序でまたはCだけを受信することが望ましい場合がある。以下のコードは、この目標を達成することができる。特に、Receiveステートメントを同じ行、例えば、selectReceive内の同じCaseステートメント内に置くことにより、何らかの未定義の順序でメッセージのすべてを受信してから次へ進むように指定することができる。すべての入来メッセージの要求条件を最初に満たすケースは、最終的に選択されるケースである。Selectステートメントに関する限り、CがAの後、ただしBの前に入る場合、Aは利用可能にされ将来の他の時点に受信される。次にCtRepeatedRequestResponseコントラクトの実装に移る。ここで注目すべき態様がいくつかある。第1に、実行中のselectReceiveステートメントが例示されているが、これは、さらに、通常のDoループステートメント内にネストされる。スケジュールの包含に関する制約はごくわずかであり例えば、以下の言語の制約で説明されている、ループはそれらの間にない。サービスクライアントでは、送信/受信を中心としてループが使用され、そこで、システムは、株価について何度も尋ねることを許されているユーザと相互作用する。このコードは、DVSサンプル間で、Sample-2として使用することができる。この実施例では、サービスクライアントは一か八かで実行している。例えば、クライアントからまる1分間何も届かなかった後、適切であると感じられたときにサービスがItsOver2メッセージを送信すると仮定する。ここで、サービスクライアントは、さらに、selectReceiveステートメントを使用して、この可能性に対応することも可能である。サービスは、まる1分間、メッセージがなかったことを検出することができるであろう。例えば、サービスは、これがItsOverlメッセージを送信せずにクライアントが消えてしまったという好ましくないサインであると決定することも可能であろう。このような状況を取り扱う何らかの手段が必要である。セッションタイムアウトは、上述のように有用であるが、多くの場合、強烈すぎる。むしろ、タイムアウト間隔をselectReceiveステートメントに設定することが可能であり、メッセージが届かない場合の状況をより精密に制御する。この間隔の型はSystem.TimeSpanとすることができる。上記のFromMinutesメソッド呼び出しは、その型に対する共有メソッドの1つであり、これによりTimeSpanを特定の時間単位例えば、秒、分、時から構成することができる。System.TimeSpanの詳細については、.NETフレームワークのドキュメンテーションを参照されたい。selectReceiveステートメントの定義では、TimeSpanが0の場合、すでに到着していて待機中のメッセージから分岐条件が直ちに満たされ得なければタイムアウト分岐が選択される。つまり、SelectReceiveステートメントが休止しないようにすることが1つの手段となっている。これにより、利用可能であれば即座に処理されなければならない何らかのメッセージがないかスケジュール側で素早くチェックするようにでき、利用可能でなければスケジュールで実行するのがより適切なことがある。上記の例では、セッションにただタイムアウトさせ、サービスインスタンスに消えてもらうだけでなく、むしろ、ItsOver2メッセージをクライアントに送信し、クライアントに通知する機会があったことに注意していただきたいが、これは遅いユーザを待つ際に十分うまく機能する可能性がある。これは、よいサービスシチズンservicecitizenであることの一部である例えば、消え去るgoawayことをパートナーに通知する。分割行selectReceiveは単一状態遷移をトリガする代替および順序付けなしのメッセージグループをサポートするのに十分であったが、コントラクト内での分割をサポートする場合には不便である。この実施例では、コントラクトパターンは以下のようであることを仮定する。受信側では、これは次のようにコーディングすることが可能である。どのメッセージがすでに受信されているしたがって、再び参照すべきでないかを追跡するため、このブックキーピングをすべてどのように完了しなければならないかに注意されたい。VBオーケストレーション例では、このタイプの状況を取り扱う。例えば、以下のようになる。ここには、どのような形であれブックキーピングコードはない。つまり、それぞれのメッセージは、他のメッセージとは独立に処理されることができるということである。Splitステートメントにより、VBオーケストレーションは並列処理が行われ、しかも、同時実行性の複雑さを気にかける必要はない。上記のステートメントの意味は、分割行と呼ばれる、分割内のその3つのネストされているブロックは、互いに無関係に、例えば、並列に実行できるということである。しかし、同時には実行されず、この管理はすでに説明されている休止pauseおよび再開プロセスを通じて処理される。分割行は、スケジュール内の他のすべての行が休止されるまで再開することはできない。分割が実行されると、その分割行はすべて最初に中止される、その後、分割行は宣言の順序で再開される。これは、最初の分割行が休止しない限り、それが実行中のスケジュール内の唯一の分割行であることを意味する。つまり、分割行の同期は暗黙の同期であり、休止を通じて制御される。オブジェクトをロックするか、または分割行の間にバッファを入れるかについて悩む必要はない。むしろ、休止イベントの間で、現在の分割行は実行中の唯一の分割行であることは理解されるであろう。実際、どのような形態であろうと自スレッド管理をスケジュールの中に導入することは、絶対に避けることができる。導入すると、本発明によるスケジュールの基盤として使用されるモデルが弱体化することになる。次に、分割行を使用して上の株価情報繰り返しクライアントを実装する方法を説明する態様に進むことにする。第1の分割行は、すでに説明されている実装と同一であることに注意されたい。行われるのは、ExitSplitが追加されることだけであることに注意されたい。これは、囲む分割ステートメントのすべての分割行を終了する一般的なExitステートメントのもう1つの変種である。第2の分割行は、決して届くことのないItsOver2メッセージを待つ。待たなければ、第1の行はステートメントを終了する。オーケストレーションクラス再び通常スケジュールとオーケストレーションクラス内に現れるスケジュールとの区別に戻ると、このクラスが存在する場合以下のようになる。次のように分けることも可能である。問題は、それぞれのメソッドが自スケジュールを持つため、GetSingle呼び出しが、完了するまでブロックする点である。つまり、第1の分割行の内部で、その呼び出しは、応答メッセージを待っている間出力せず、第2の行は、実行に取りかからない。本質的に、長時間の停止状態starvedになる。GetSingleの内部のReceiveステートメントが第2の行の中のステートメントで調整できれば、この問題は緩和できるであろう。それはちょうど、オーケストレーションクラスが遂行するものである。クラス宣言を単純に以下のものに変更することにより所望の挙動が得られる。つまり、GetSingle内のReceiveステートメントが出力することは、分割行が出力し、第2の行が実行可能であることを意味する。待機スケジュール内の他の基本オペレーションは設定された期間の間待機することである。その時間の大部分を遅延に費やす長時間実行サービスのクラス全体がある一般にぐずぐず先へ延ばす人procrastinatorパターンと呼ばれる。これらは、通常、コマンド例えば、シャットダウン、モニタ追加などの到着を監視し、それと同時に、ハートビート信号またはハートビートポーリング要求を他のサービスに送信することができる監視サービスであることが多い。そこでこれらの概念を参照して、他の理由もなく、共通の用語を定めることにする。長期間実行することが予想される何らかのサービス/サービスのクラスを設計する場合、通常、サービスがまだ利用可能かどうかを他のサービスが自動的に判別し、積極的にそれを実行できるようにするある種のインターフェースを設計しなければならない。アプローチの1つは、サービスにアクセスするのが困難なすべてのクライアントに何らかの中央サービスに情報を送信させることであるが、それだと、クライアントは、使用事例を設計に追加することにより必要以上に複雑になり、使用事例はクライアントの元の目的に関係しない。むしろ、ある頻度で監視サービスに送信されるメッセージである、ハートビートの受信を待機することにより、第1のサービスが利用可能かどうかを追跡する監視サービスが作成される。通常の設計では、監視サービスは、監視されるサービスにそのハートビートを1回送信するか、またはN秒おきに送信を開始するよう要求するか、またはハートビートの送信をどれだけの頻度で準備するかをモニタに通知することができる。監視サービスは、その後、一定時間待機し、single-shot-heart-beat要求を送信するループを使用するか、または定期的にハートビートを送信するように監視されるサービスに要求することができる。後者の状況では、監視サービスは、selectReceiveを使用し、タイムアウト間隔をagreed-upon間隔よりも少しだけ長い何らかの値に設定する。ハートビートが届いた場合は、すべて良好であるが、ステートメントがタイムアウトになった場合、それは、何かよくないことが進行中であることを示しており、監視サービスはある形態のアラームを送出することが可能である。より高度な実装は、ハートビートメッセージ上に他の情報を抱き合わせで載せてpiggy-back、オペレータが長時間実行サービスに関する統計量を取得できることが理解されるであろう。Waitがオーケストレーションのステートメントとして明示的にサポートされていなかった場合、一定時間の遅延を導入すると、アプリケーションの拡張性に対し破滅的結果をもたらす可能性がある。.NETフレームワーク内のAPIである、Thread.Sleepに依存しなければならない場合があるが、ホスト環境のランタイムにより同時実行性を管理することを要求する、サービス実行モデルには完全に不適切である。Thread.Sleepを呼び出すと、ウエイトの持続期間中に現在のスレッドを結合する。Waitを呼び出すことをループするサービスについては、これは無期限とすることができる。つまり、そのようなサービスでは、スレッドをすべてそれ自身に割り当てることになる。これはほとんどの期間未使用状態のままであるスレッドに関することであることは理解されるであろう例えば、通常の監視スレッドは、作業実行に100マイクロ秒を費やし、その後、数分間スリーピング状態に進む。1分間スリープし、100マイクロ秒間動作するスレッドは、そのタイムスリーピングの99.9998を費やすことになる。したがって、このモデルでは遅延の必要性を考慮することが重要である。これは、Waitステートメントで実行される。監視サービスコマンドの受信を監視しないでの使用例について、以下では、適当なスケジュールを示す。システムは、ループの本体を実行するのに要する時間を補償できることに注意されたい。これは、ウエイト期間が指定された時間にできるだけ近くなるようにするためである。Waitステートメントのオペランドは、型System.TimeSpanとすることができる。動的並列処理Splitステートメントによりコードの本体の定義を可能にできるが、n行分のコードを並列に実行するために使用する可能性はない。そのような動的挙動のケースは強く、以下の2つの方法でサポートされる。1.Split-For-Eachステートメント2.Split-Select-Receiveステートメント前者は、他のすべての反復と並列にループの各反復を実行することを除き、For-Eachステートメントと同じ基本的な意味を持つ。つまり、繰り返されるコレクション内にあるアイテムの数だけ並列実行行があるということである。この数が決定された後、さらに行を並列ステートメントに追加することはできない。Split-For-Eachは、Splitと同じ結合join規則を持つ、つまり、すべての反復が終了すると、Split-For-Eachステートメントも終了する。例を以下に示す。これがそのようなステートメントを含む通常のFor-Eachを超える利点は、すべてのReceiveステートメントが並列に待機するという点である。送信と受信との間の遅延が大きいほど、これを実行できることがますます重要になる。split-Select-Receiveは、入来メッセージに対する応答として並列実行の新しい行を動的に開始するために使用することができる。ある変種は、多重化された対話に関する理解によって異なるが、より単純な変種は、このコントラクトを実装するのを手助けする変種であるA、B、およびCはすべて入来メッセージである。ここで、コントラクトにより、Cを得るまで任意の個数のインタリーブされた<A,B>シーケンスを取ることができ、Cを得たときに、すべてのBが入ってくるのを待つ。各<A,B>シーケンスは他のすべてと独立に処理されるため、ループ内でSelect-Receiveステートメントを使用してこれを実装するのは困難であろう。しかし、Split-Select-Receiveを使用することができる。このステートメントの内側の1行が出力する毎に、新しい行が作成され、Selectステートメントをその新しい行について実行することができる。これは、そのステートメントは決して独立に終了することはないことを意味している例えば、常に、次のメッセージを処理するために新しい行が生じる。ステートメントを終了し、そのまますでに開始されているすべての行を実行できるようにするために、そのステートメント内の何らかのコードでFinishSplitステートメントを実行することが可能である。注意:前文を考慮すると、1つの実行行という考え方は、ソースコード行を指すのではなく、むしろ、一連の実行、例えば、並列処理プログラム内の一連のステートメントを指すことは理解されるであろう。終了Exitの新しいバージョンのいくつかは、すでに上で説明されているが、わかりやすくするために、以下にその内容と動作を繰り返し示す。これは囲むsplit、split-For-Each、またはsplit-Select-Receiveのすべての出力行を終了し、対応するEndまたはNextステートメントに移動する。これは、現在の行静的であろうと動的であろうとを終了するが、他には影響を及ぼさない。フィルタメッセージフィルタは、前の方でReceiveステートメントについて説明したときには取り上げられていなかった。句を例外ハンドラに入れてそのハンドラの一致がただ単なる例外の型に基づくのではないようにすることと同様に、句をReceiveステートメントに追加し、コンテンツまたは大域的状態などの特別ないくつかの要因に基づいてメッセージを受け入れるか、または拒絶することができる。コントラクト言語は対応する条件を指定する手段を持たないため、フィルタ式を使用してメッセージを除去するスケジュールは、そのコントラクトがプロセス内で違反にならないようにすることに注意されたい。特にある場合にはさらに多くのメッセージを受信することができ、他の場合にはそうすることができないときに、フィルタを採用すると都合がよい。例えば、以下のようになる。このステートメントは、メッセージパラメータが値OKを持つ場合のみメッセージAを受け入れ、そうでなく、Aメッセージパラメータが値ACKを持つ場合にはAおよびBを受信する。これらの状況がどれも真でない場合、ステートメントはそれらが真になるまで待つ。そこで、フィルタは、メッセージが消費されるまで何回も呼び出されることがあり、したがって、副作用を起こすことなく真の式であることが重要である。二次コネクタ上述のように、サービスが最初に起動されると、明示的に指定することなくメッセージの送受信に使用することができるコネクタを割り当てられる。このコネクタは、サービスの一次コネクタと呼ばれる。一次コネクタは、第1のメッセージがサービスに送信された際のクライアントコネクタにバインドされる。これは、常に、そのコントラクトに関する実装パースペクティブを持つことができる。他のクライアントとまったく同様に、アクティブ化されたサービスがクライアントとして他のサービスと通信することを望んでいる場合、何らかのサービスアドレスにバインドされているコネクタファクトリを使用し、そのファクトリからコネクタを作成し、メッセージの送信を開始することが可能である。上述のように、コネクタファクトリにより作成されたすべてのコネクタは使用パースペクティブを持つ。もしサービスが、一次コネクタと同じコントラクト上にあろうとそうでなかろうと、他のクライアントに対話を開始させたいとすればどうであろうか一次コネクタは、すでにバインドされており、したがって、共有することはオプションではない。それに、他の何らかのコントラクトを実装したい場合、一次コネクタはおそらくとにかく役立たない。答えは、実装パースペクティブを持つ二次コネクタを作成することである。サービスにおけるすべての実装パースペクティブコネクタは、二次コネクタと呼ばれる。サービス外では、すべてのコネクタは等しい、一次でも二次でもないことは理解されるであろう。新しい二次実装コネクタの作成を以下に示す。ここでは以下の2点に注目すべきである。1.Implementsキーワードを変数宣言の中で型修正子typemodifierとして使用することができる。これは、宣言された変数に実装パースペクティブを与える。2.実際のコネクタオブジェクトは、サービス参照なしで所望のコントラクトを呼び出すことによって作成できる。これは、たぶん型名のかなり奇妙な使い方であるが、二次コネクタを作成する唯一の方法である。Implementsコントラクト型修正子は、クラスまたはモジュールメンバとして、またはメソッドへのパラメータとして含む、コネクタ変数が作成できる場合には必ず使用できる。一方のパースペクティブのオブジェクトを反対のパースペクティブの変数に割り当てようとすると、コンパイル時に失敗することがある。コネクタ-変数割り当ての規則は、コネクタ-コネクタのバインドの規則とちょうど反対とすることができることに注意されたい。つまり、コネクタは、同じパースペクティブの割り当て済みコネクタとしかできないが、反対のパースペクティブのコネクタにバインドしなければならない。見つからないサービス利用可能なサービスがないことを検出する方法は2つある。第1に、TCPアドレスが有効でないことがある。つまり、ポートが開かれておらず、サービスが実際にはそこにない。この問題は、第1のメッセージをサービスに送信しようとする際に検出され、即座に例外を発生させることができる。第2に、メッセージは宛先に届くことができるが、ホスティング環境はサービス名またはサービスインスタンスを認識しない。この場合、メッセージを送信するスケジュールは、寿命とともに移動しており、例外を投げるのは意味がない。代わりに、問題は、オーケストレーションクラスのメソッドをオーバーライドすることにより取り扱われる。タイムアウト一方が一方のスケジュールから他方に非同期メッセージを送信する場合、応答は届く保証はない。このようなことが生じる可能性のある理由としては、限定はしないが、低水準の通信障害、またはクライアントとサーバとの間での予想される内容についての不一致を含む様々な理由がある。コントラクトは、2つのメッセージの間の最大遅延を指定できないため、コントラクトが2週間の間必要とする要求に応答しないサービスは、技術的に、そのコントラクトを分けていない。最初にメッセージを送信することなくスケジュールが終了した場合のみ、コントラクトの違反となる。これは、サービスおよびサービスクライアントに対するスケジュールを作成する際に考慮しなければならない問題を示している。サービスが受信を依存できる唯一のメッセージは、第1のものであるが、それは、メッセージが到着したのが第1の場所で開始したという理由にあるからである。サービスクライアントは、そのことにさえあまり依存できない。幸運なことに、VBオーケストレーションでは、適当な実装ツールを用意している。異なる取り扱いを要する2つの状況がある。1.与えられたメッセージが届かない場合、スケジュールが具現化する計算プロセスを完全に放棄することができる。スケジュールコードは大きくならないようにされるので、セッションタイムアウトは、この状況では十分であり、推奨される。2.与えられたメッセージが届かない場合、スケジュールは、それから回復して、既定の情報とともに進むことができるか、または要求の再送を試みるか、または情報について他の何らかのサービスとのコンタクトを取ることができる。タイムアウト間隔を設定しているSelect/Receiveステートメントは、この状況に対し推奨される。このような状況についてはすでに説明されている。上述のように、Select/Receiveステートメントは、複数のケースを持たなくてよい。Receiveステートメントは、実際、より効率的に実装されたが、機能的に等価なバージョンの、単一のケースを伴うSelect/Receiveである。つまり、はに等価である。この実現を備えると、メッセージが予期されているのに届かない場合はいつでも、Receiveステートメントにタイムアウト間隔を追加することによりそれを処理することができる。本発明によれば、状況に応じて、このようなことが生じた場合にいくつかの代替が使用可能である。しかし、一般にガイドラインを定義できないことに留意されたい。すべては、解決しようとしている問題に完全に依存する。例えば、次のようである。少し長く待つ。応答がパラメータなしのacknowledgement-styleメッセージであった場合、確認応答が否定的または、状況によっては肯定的であるという仮定の下で進めることを決定することができる。応答メッセージが、なしで処理することができる何らかのクリティカルでないデータを送り返した場合、たぶん、到着していないデータに対する何らかの既定値とともにそうする。おそらく、Webサービスは、パスポートに似たサービスから個人化データを検索しているが、何もなければ、Webサービスは制限付きの個人化とともに処理を進める。待機していたサービスにメッセージを再送しようと試みる。接続可能な他の何らかのサービス、または同じサービスの他のインスタンスを見つけて、その情報を取得する。これを行うメソッドは、もちろん、状況により異なる。上の1番目の項目を除くすべてに共通なのは、コントラクト自体がいくつかのメッセージが到着しないおそれがあるという事実を受け入れないと、大きな問題になるという点である。スケジュールを抜けると、寿命内で作成されたそれぞれのコネクタが調査され、それを通じて行われたメッセージ交換が完了しているかどうか検証する。行われていないコネクタはいずれも、そのコントラクトに違反しているとして注目され、例外が投げられる。あるべきメッセージを受信しない場合、どこかにエラーがあっても、スケジュールに対してどれだけ重要なことかを知る手段がないため、ランタイムは単純に無視することはできない。しかし、メッセージが到着しないコネクタを破棄することにより、スケジュールはランタイムに、その特定のコネクタについてコントラクトに違反すべきでないことを通知する。しかし、コネクタを破棄することもまた、そのコネクタに対し他の処置が講じられないことを意味する場合がある。それに送信できないか、またはそれからメッセージを受信することができない。試みると、エラーが発生する。Selectステートメントのタイムアウト間隔では、ステートメントのグループが実行に要する総時間に上限を設定せず、1つのステートメントがメッセージを待つ時間のみに対し設定することに注意されたい。前者を実行するには、SplitおよびWaitステートメントを使用することができる。VBオーケストレーションではリアルタイムの動作を主張していないので、これが要する時間は指定された2分以内であるという保証はない。第2行が休止イベントに達した場合のみ、Splitステートメントが実際に終了し、EndSplitの後のステートメントが実行される。非スケジュールコードとの相互作用非同期プログラミングにSendおよびReceiveステートメントを使用することが正しい解決手段とならない状況がある。状況によっては、スケジュールの単一スレッドのブロッキングの性質がエレガントな解決手段を邪魔することになるか、またはおそらく、本質的に、単にスケジュール駆動でない何らかのUIコードを用意する必要がある。吉報なのは、このような状況であっても、ボタン押下イベントなどをサービスまたはサービスクライアントへのメッセージに変換する少しのコードを書くのは容易であることである。つまり、非同期プログラミングは、イベントベースのグラフィカルUIプログラミングとは非常に相性がよいのである。これら2つのパラダイム-イベントベースとスケジュールベース-の間のこのようなブリッジを実現するために、VBオーケストレーションでは、非スケジュールコードでイベントへの入来メッセージの送信およびマッピングを行うことができる。したがって、メッセージは、スケジュールおよびそのブロッキングの意味なしでやり取りできる。コントラクト内のそれぞれのメッセージにより、イベントがその型に追加される。メソッドおよびイベントは.NETではオーバーロードをできないため、イベント名はStringEventが直接追加されたメッセージの名前となる。メソッドは、メッセージとまったく同じ名前を持つ。例を以下に示す。以下で調べるサンプルアプリケーションでは、グラフィカルUI相互作用に特に関係するこのような方法でメッセージ交換が使用される。グラフィカルユーザインターフェースWin32ベースのグラフィカルユーザインターフェースには、表示する新しいデータをコントロールに与えるなど、特定の操作を行うために使用されるスレッドに関して特別な要求条件がある。すべてのコントロールがこの要求条件を持つわけではないが、一部のコントロールはそうであり、それに適応しなければならない。スケジュールと個別のコネクタは両方とも、UIスレッドにアタッチし、スケジュールで受信した、またはコネクタで受信したすべてのメッセージは、特定のUIスレッドのコンテキストで受信される。この機能は、使いやすいが、実際に必要になった状況に限られるであろう。スケジュールコードを単一スレッドに強制すると、同時実行の機会が制限され、したがって、パフォーマンスに対するボトルネックになるおそれがあることは理解されるであろう。第2のステートメントは、必ず、戻った後、そのコネクタ上で受信されたすべてのメッセージはそのフォームの所有スレッド上に到着するようにする。これはサービスの一次コネクタ上でも実行できることに注意されたいこれは、一次コネクタを明示的に参照する数少ない妥当な機会の1つである。しかし、たいていは、サービスおよびサービスクライアントは、UIコードを直接呼び出さず、メッセージをそれらを含むフォームに送信するが、これは、たいてい、制御スレッドを設定することに意味がある非スケジュールコネクタであることを意味する。以下に、setControlを使用した場合の例を示す。connector1およびconnector2が両方とも同じ所有スレッドにバインドされていない限り、メッセージ受信はこのケースの中で非決定論的となるスレッドに関して。スレッド情報は、このケースの中のいずれかのコネクタから引き出すことができることは理解されるであろう。したがって、ケースの中のすべてのコネクタが同じ所有スレッドにバインドされ、スケジュールが所有スレッドにバインドされるようにすることが重要である。動作可能なコンピューティング環境次に、図7を参照すると、開示されているアーキテクチャを実行する動作が可能なコンピュータのブロック図が示されている。本発明の様々な態様の他の状況を示すために、図7および以下の説明は、本発明の様々な態様を実装できる好適なコンピューティング環境700の簡潔な一般的説明を行うことを意図している。本発明は、1つまたは複数のコンピュータ上で実行できるコンピュータ実行可能命令の一般的な状況において上で説明されているが、当業者であれば、本発明は、他のプログラムモジュールと組み合わせて、および/またはハードウェアとソフトウェアとの組合せとしても実装できることを理解するであろう。一般に、プログラムモジュールは、特定のタスクを実行する、または特定の抽象データ型を実装するルーチン、プログラム、コンポーネント、データ構造などを含む。さらに、当業者であれば、本発明は、それぞれ、1つまたは複数の関連する装置に動作するように結合できる、シングルプロセッサまたはマルチプロセッサコンピュータシステム、ミニコンピュータ、メインフレームコンピュータ、ならびにパーソナルコンピュータ、ハンドヘルドコンピューティングデバイス、マイクロプロセッサベースまたはプログラム可能家電製品などを含む、他のコンピュータシステム構成で実施できることを理解するであろう。本発明の例示されている態様は、通信ネットワークを通じてリンクされているリモート処理装置によりいくつかのタスクが実行される分散コンピューティング環境で実施することもできる。分散コンピューティング環境では、プログラムモジュールは、ローカルおよびリモートの両方のメモリ記憶装置内に配置されうる。コンピュータは、通常、様々なコンピュータ可読媒体を含む。コンピュータ可読媒体は、コンピュータによってアクセスできる媒体であればどのような媒体でもよく、揮発性および不揮発性媒体、取り外し可能および固定媒体を含む。例えば、限定はしないが、コンピュータ可読媒体は、コンピュータ記憶媒体および通信媒体を含むことができる。コンピュータ記憶媒体は、コンピュータ可読命令、データ構造体、プログラムモジュール、またはその他のデータなどの情報を格納する方法または技術で実装される揮発性および不揮発性、取り外し可能および固定媒体を含む。コンピュータ記憶媒体は、限定はしないが、RAM、ROM、EEPROM、フラッシュメモリまたはその他のメモリ技術、CD-ROM、デジタルビデオディスクDVDまたはその他の光ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置またはその他の磁気記憶装置、または所望の情報を格納するために使用することができコンピュータによりアクセスできるその他の媒体を含む。通信媒体は、通常、コンピュータ可読命令、データ構造体、プログラムモジュール、または搬送波もしくはその他のトランスポートメカニズムなどの変調されたデータ信号によるその他のデータを具現するものであり、任意の情報配信媒体を含む。変調されたデータ信号という用語は、信号内の情報を符号化する方法によりその特性のうち1つまたは複数が設定または変更された信号を意味する。例えば、限定はしないが、通信媒体としては、有線ネットワークまたは直接配線接続などの有線媒体、ならびに、音響、RF、赤外線、およびその他の無線媒体などの無線媒体がある。上記のいずれの組合せもコンピュータ可読媒体の範囲に含まれるべきである。図7を再び参照すると、コンピュータ702を含む本発明の様々な態様を実装するための環境例700が例示されており、またコンピュータ702は、処理ユニット704、システムメモリ706、およびシステムバス708を備える。システムバス708は、限定はしないがシステムメモリ706を含むシステムコンポーネントを処理ユニット704に結合する。処理ユニット704は、様々な市販プロセッサがあるがそのうちどれでもよい。デュアルマイクロプロセッサおよびその他のマルチプロセッサアーキテクチャも、処理ユニット704として採用することができる。システムバス708は、メモリバスメモリコントローラを備える、または備えない、周辺機器バス、および様々な市販のバスアーキテクチャのどれかを使用するローカルバスにさらに相互接続できる数種類のバス構造のうちのいずれでもよい。システムメモリ706は、読み取り専用メモリROM710およびランダムアクセスメモリRAM712を含む。基本入出力システムBIOSは、ROM、EPROM、EEPROMなどの不揮発性メモリ710に格納され、BIOSは、起動時などにコンピュータ702内の要素間の情報伝送を助ける基本ルーチンを含む。RAM712は、さらに、データをキャッシュするためのスタティックRAMなどの高速RAMも含むことができる。コンピュータ702は、さらに、好適なシャシ図には示されていないに入れて外部で使用するように構成することも可能な、内蔵ハードディスクドライブHDD714例えば、EIDE、SATA、磁気フロッピー登録商標ディスクドライブFDD716例えば、取り外しディスケット718からの読み出しまたは書き込み用、および光ディスクドライブ720例えば、CD-ROMディスク722を読み込む、またはDVDなどの他の大容量光媒体から読み出しまたは書き込むを備える。ハードディスクドライブ714、磁気ディスクドライブ716、および光ディスクドライブ720は、ハードディスクドライブインターフェース724、磁気ディスクドライブインターフェース726、および光ドライブインターフェース728によりそれぞれシステムバス708に接続できる。外付けドライブ実装用のインターフェース724は、UniversalSerialBusUSBおよびIEEE1394インターフェース技術のうちの少なくとも一方または両方を含む。ドライブおよび関連するコンピュータ可読媒体は、データ、データ構造、コンピュータ実行可能命令などを格納する不揮発性記憶装置を実現する。コンピュータ702では、ドライブおよび媒体は、好適なデジタル形式のデータの格納に対応している。上記のコンピュータ可読媒体の説明ではHDD、取り外し可能磁気ディスケット、およびCDまたはDVDなどの取り外し可能光媒体を取り上げたが、当業者であれば、zipドライブ、磁気カセット、フラッシュメモリカード、カートリッジなどのコンピュータにより読み取り可能な他のタイプの媒体も、動作環境例で使用することができ、またそのような媒体は、本発明の方法を実行するためのコンピュータ実行可能命令を格納できることは理解するであろう。オペレーティングシステム730、1つまたは複数のアプリケーションプログラム732、その他のプログラムモジュール734、およびプログラムデータ736を含む、多くのプログラムモジュールは、ドライブおよびRAM712に格納することができる。オペレーティングシステム、アプリケーション、モジュール、および/またはデータの全部または一部も、RAM712にキャッシュすることができる。本発明は、様々な市販のオペレーティングシステムまたはオペレーティングシステムの組合せで実装できることは理解される。ユーザは、1つまたは複数の有線/無線入力装置、例えばキーボード738およびマウス740などのポインティングデバイスを通じてコンピュータ702にコマンドおよび情報を入力することができる。他の入力装置図に示されていないとしては、マイク、IRリモートコントロール、ジョイスティック、ゲームパッド、スタイラスペン、タッチスクリーンなどがある。これらの入力装置およびその他の入力装置は、システムバス708に結合されている入力装置インターフェース742を介して処理ユニット704に接続されることが多いが、パラレルポート、IEEE1394シリアルポート、ゲームポート、USBポート、IRインターフェースなどの他のインターフェースにより接続されることもできる。モニタ744またはその他の種類の表示装置も、ビデオアダプタ746などのインターフェースを介してシステムバス708に接続される。コンピュータは、通常、モニタ744の他に、スピーカおよびプリンタなど、他の周辺出力装置図に示されていないを含む。コンピュータ702は、複数のリモートコンピュータ748などの1つまたは複数のリモートコンピュータへの有線および/または無線通信を介する論理接続を使用してネットワーク接続環境で動作することができる。複数のリモートコンピュータ748は、ワークステーション、サーバコンピュータ、ルータ、パーソナルコンピュータ、ポータブルコンピュータ、マイクロプロセッサベースの娯楽機器、ピアデバイス、またはその他の共通ネットワークノードなどとすることができ、通常は、コンピュータ702に関係する上述の要素の多くまたはすべてを含むが、簡単のため、メモリ記憶装置750のみが例示されている。示されている論理接続は、ローカルエリアネットワークLAN752および/またはより大規模なネットワーク、例えば、ワイドエリアネットワークWAN754への有線/無線接続を含む。このようなLANおよびWANネットワーキング環境は、オフィスおよび会社では一般的なもので、イントラネットなどの企業規模のコンピュータネットワークを円滑にし、これらはすべて、大域的な通信ネットワーク、例えば、インターネットに接続することができる。LANネットワーキング環境で使用される場合、コンピュータ702は有線および/または無線通信ネットワークインターフェースまたはアダプタ756を介してローカルネットワーク752に接続される。アダプタ756により、無線アダプタ756と通信するように配置されている無線アクセスポイントも含むことができる、LAN752との有線または無線通信を円滑にすることができる。WANネットワーキング環境で使用される場合、コンピュータ702は、モデム758を含むことができるか、またはLAN上で通信サーバに接続されるか、またはインターネットなどにより、WAN754上での通信を確立する他の手段を有する。モデム758は、内蔵でも外付けでも、また有線装置でも無線装置でよいが、シリアルポートインターフェース742を介してシステムバス708に接続される。ネットワーク接続環境では、コンピュータ702またはその一部に関して示されているプログラムモジュールは、リモートメモリ/記憶装置750に格納されうる。図に示されているネットワーク接続は実施例であり、コンピュータ間の通信リンクを確立するのに他の手段が使用可能であることは理解されるであろう。コンピュータ702は、無線通信で動作が可能なように配置された無線装置またはエンティティ、例えば、プリンタ、スキャナ、デスクトップおよび/またはポータブルコンピュータ、ポータブルデータアシスタント、通信衛星、無線検出可能タグに関連付けられた機器または場所例えば、キオスク、ニューススタンド、屋内トイレ、および電話と通信するように動作可能である。これは、少なくともWi-FiおよびBluetooth商標無線技術を含む。そのため、通信は、従来のネットワークの場合ような定義済み構造、または少なくとも2つの装置間の単にアドホックな通信とすることができる。Wi-Fi、つまりワイヤレスフィデリティを使用すると、家庭のソファに座ったまま、ホテルの寝室で、または仕事中の会議室から、無線により、インターネットに接続することができる。Wi-Fiは、そのような装置、例えば、コンピュータがデータを屋内と屋外で、しかも基地局の範囲内であれば場所を限らず、送受信できる携帯電話のような無線技術である。Wi-Fiネットワークでは、IEEE802.11a、b、gなどと呼ばれる無線技術を使用して、安全で信頼性の高い、高速な無線接続を実現する。Wi-Fiネットワークは、コンピュータ同士を接続したり、インターネットに接続したり、有線ネットワークIEEE802.3またはEthernet登録商標を使用するに接続したりするために使用できる。Wi-Fiネットワークは、無認可の2.4および5GHz無線周波数帯で、11Mbps802.11bまたは54Mbps802.11aのデータ転送速度により動作するか、または両方の帯域を含むデュアルバンド製品を使用して動作するため、これらのネットワークは、多くのオフィスで使用されている基本的な10BaseT有線Ethernet登録商標ネットワークに似た現実世界のパフォーマンスを達成することができる。次に図8を参照すると、本発明によるコンピューティング環境例800の略ブロック図が例示されている。システム800は、1つまたは複数のクライアント802を含む。クライアント802は、ハードウェアおよび/またはソフトウェア例えば、スレッド、プロセス、コンピューティングデバイスとすることができる。複数のクライアント802は、例えば、本発明を採用することにより複数のクッキーおよび/または関連するコンテキスト情報を収容することができる。システム800は、さらに、1つまたは複数のサーバ804も含む。サーバ804もまた、ハードウェアおよび/またはソフトウェア例えば、スレッド、プロセス、コンピューティングデバイスとすることができる。サーバ804には、例えば、本発明を採用することにより変換を実行するスレッドを置くことができる。クライアント802とサーバ804との間で可能な通信の1つは、2つまたはそれ以上のコンピュータプロセス間で伝送されるように適合されたデータパケットの形で実行できる。データパケットは、例えば、クッキーおよび/または関連するコンテキスト情報を含むことができる。システム800は、複数のクライアント802と複数のサーバ804との間の通信を円滑にするために採用することができる通信フレームワーク806例えば、インターネットなどの大域的通信ネットワークを含む。通信は、有線光ファイバを含むおよび/または無線技術を介して円滑にすることができる。複数のクライアント802は、複数のクライアント802のローカルにある情報例えば、複数のクッキーおよび/または関連するコンテキスト情報を格納するために使用することができる1つまたは複数のクライアントデータストア808に動作可能なように接続される。同様に、複数のサーバ804は、複数のサーバ804のローカルにある情報を格納するために使用することができる1つまたは複数のサーバデータストア810に接続し動作させることができる。付録Aはスタックフリー適合という表題の論文である。この付録は、サブジェクト仕様の一部をなす。付録Aでは、本発明の様々な態様について説明しており、本出願の明細書の一部とみなすべきである。上述した内容は、本発明の複数の実施例を含む。もちろん、本発明を説明するためにコンポーネントまたは方法の考えられるすべての組合せを説明することは不可能であるが、当業者であれば、本発明の他の多くの組合せおよび置換が可能であることを理解できるであろう。したがって、本発明は、付属の請求項の精神と範囲内に収まるすべてのそのような変更、修正、および変更形態を包含することが意図されている。さらに、含むという言い回しを詳細な説明または請求項で使用している範囲において、このような用語は備える、含むという用語と似た使い方をし、これは使用した場合に請求項の中で暫定的用語transitionalwordと解釈する。付録Aスタックフリー適合CedricFournet、TonyHoare、SriramK.Rajamani、JakobRehofMicrosoftResearchfournetthoaresriramrehofmicrosoftcom概要。代替可能性特性を満たす、つまり、IがSに準拠し、Pが、P|Sがスタックフリーとなるような環境であるならば、P|Iはスタックフリーであるということが成り立つ、CCSプロセスの新規性のある詳細化関係refinementrelationスタックフリー適合を提示する。スタックフリーダムは、デッドロックのCSP概念に関係しているが、これは、非同期システムの孤立メッセージを考慮することにより区別しやすい。適合は、CCSプロセス上の前合同関係であり、それによって、モジュール方式の精密化をサポートすることを証明する。適合を関係する先行順preorders、CSPにおける安定失敗詳細化stablefailuresrefinement、およびCCSにおける拒絶先行順refusalpreorderから区別する。新しいソフトウェアモデル検査器ZINGで適合検査を実行し、それを使って分散プログラムにおけるエラーを見つけた方法について報告する。1はじめにわれわれは、メッセージ受け渡しプログラムがスタックフリーであることを検査することに関心を持っている[11]。スタックフリーダムは、通信システムが、決して送信されないメッセージまたは決して受信されない送信メッセージを待ってデッドロックに陥ることがあり得ないという特性を形式化するものである。この論文では、適合の理論を一般化し、モデル検査分散プログラムのアプリケーションに関して報告することにより[11]を拡張する。このアプリケーション例では、プログラマが、プログラムの外部から見えるメッセージ受け渡しの挙動を指定するインターフェースであるコントラクトを書く。コントラクトは、CCSプロセスと同じくらい豊かであると考えられる。スタックフリーダムは、モデル検査器を使用して実装がそのコントラクトに適合していることを検査することにより確認される。システム全体の状態空間を探索することによりスタックフリーダムを検査すると、状態空間は同時実行プロセスの数が増えるとともに指数関数的に増大するため、状態空間はたちまち爆発的に増大し、またシステム全体が分析に利用可能である必要があるが、これは分散システムでは特に非現実的である。したがって、スタックフリーダムを構成的に検査したいのである。Iがコンポーネントの実装であり、Cがそのコントラクトである場合、記法I≦Cを使用して、IがCに適合していることを表す。われわれの構成的アプローチがスタックフリーダムに関して健全であるためには、適合関係≦は以下の代替可能性特性に従う必要がある。I≦Cであり、Pが、P|Cがスタックフリーであるような環境である場合、P|IもスタックフリーであるP|CはPとCの並列化構成を表す。代替可能性は、コンポーネントのコントラクトが呼び出しコンテキストにおけるコンポーネントの代わりに安全に使用できること、したがってモデル検査のスケーリングに役立つことを意味する。われわれの適合という概念は、スタックネスstuck-nessを保存する新規性のあるプロセス先行順である。スタックネスは、可視アクションとともに安定性隠されたアクションを実行できないことも観察されるうるラベル付けされた推移システム内で直接観察することができる。われわれのアプリケーションで、これが重要なのは、そのモデルを実行し、何が生じるかを観察することによりシステムを分析したいからである。スタックネスは、チャネル名に対する残りleft-overアクションを包含するので、CSPデッドロックまたは未指定受信[9]よりも区別しやすい。デッドロックの他に、これは、非同期システムでは決して消費されない孤立メッセージを含み、処理されない例外メッセージなどのソフトウェア内の重要な失敗条件を直接モデル化する。この論文では、以下の寄稿を行う。-標準CCS推移意味論に基づいて適合の概念を定義し、それがスタックフリーダムの代替可能性特性を満たす前合同precongruenceつまり、すべてのCCSコンテキストにより保存されるであることを証明する。適合を最も密接に関係する知られている先行順、CSP安定失敗詳細化[3,5,12]、およびCCS拒絶先行順[10]から区別する。-われわれは、ソフトウェアモデル検査器ZINGで適合検査器を実装した。この実装手法は、極めて一般的なものであり、ソフトウェアで適合検査を実行するように既存のモデル検査器を手直しするために使用できる。ZINGプロセスは、CCSプロセスとしてみなすことができ、したがって、われわれの適合理論は、ZING適合検査器に適用される。ZINGを適用して、非自明な分散アプリケーションにおけるコントラクト適合を検査したところ、アプリケーションにいくつかのバグが発見された。この論文では、代替可能性特性を満たす適合関係を提案している、[11]で報告された研究結果を拡張する。[11]の適合関係は、いくつかの点で制限されている。まず、[11]における適合は、推移により生成されるアクションを記録することにより適合検査の純粋に観察的な実装を排除する、プロセス1の構文的形態を参照することにより定義される。第2に、[11]における関係は、統語的制約が任意のCCSコンテキストの下で保存されないため、前合同関係ではない。その結果、P1≦Q1かつP2≦Q2ならばP1|P2≦Q1|Q2という望ましいモジュール原理を含む自然で有用な代数法則は失敗する。第3に、[11]における理論は、非標準アクション2を使用して非決定論を処理することにより複雑になる。この論文は、純粋に観察的であり、標準CCS推移システムに基づき、隠されたアクションγに関する非決定論、隠蔽、および安定性の統一された取り扱いを与える適合の実質的一般化を示す。これは、目に見えるアクションおよび安定性を観察することによりモデル検査器で実装することができ、また他の意味論的詳細化関係と比較することができる。代替可能性を証明する他に、われわれの一般化された適合関係は前合同関係であり、それによってモジュール方式の詳細化をサポートすることを証明する。最後に、ソフトウェアモデル検査器で実装し、分散プログラムを検査するコントラクトに適用することによりこの理論を適用した。----------1例えば、[11]の適合定義のいくつかの場合は、PQまたはPQの形式のプロセスにのみ適用される。この性質の他の類似の統語的依存関係も[11]に存在する。2アクションは[11]で名前を付けられている。----------この論文の残りは、以下のように編成される。セクション2で、スタックフリー適合に最も密接に関係するCSPおよびCCSの伝統における詳細化関係について説明する。セクション3で、われわれの適合の理論を提示する。論文を制限の範囲内に留めるために、われわれの適合理論のプレゼンテーションにおけるすべての証明を省略した。完全に詳細な証明は、われわれの技術レポート[]にある。セクション4では、ZING適合検査器を適用することにより分散プログラム内のエラーを見つけることについて説明し、セクション5で締めくくる。2関連する研究われわれの適合の概念は、CSP[3,5,12]で安定失敗詳細化に関してモデル化され、詳細化検査器FDR[12]の成功が刺激となっている。われわれのプロセスモデルでは、CCSの動作意味論をCSP概念に類似してはいるが異なる拒絶の概念と組み合わせる。適合の定義は、シミュレーションに依存し、目に見えるアクションおよび安定性が観察可能なラベル付けされた推移システムに直接適用される。セクション3.3で説明されているように、スタックフリーダムに関する代替可能性の条件は、安定失敗詳細化がCCSに直接組み込まれる場合には、満たされない。理由は、スタックフリーダムはデッドロックのCSP概念と異なり、またそれと比べて特徴的な概念であるからである。この違いに対応するため、われわれの適合関係は、即時拒絶readyrefusalsの考えに基づいており、プロセスは特定のアクションを同時に他を拒絶しながらすぐに受け付ける必要がある。スタックフリー適合は、IainPhillipsの拒絶試験理論[10]で開発されたようなCCSに対する拒絶先行順にも関係する。拒絶先行順により、拒絶の後に生じるアクションの観察が可能になり、したがって、拒絶と組み合わせて即座条件を表すことができる。しかし、セクション3.4で説明されているように、スタックフリー適合は、拒絶先行順よりも厳密に大きい前合同である。LarsenおよびSkou[6]による2/3バイシミュレーションの概念は、適合にある程度類似している。しかし、LarsenおよびSkouは、隠蔽および内部アクションγアクションを取り扱わず、したがって、安定性の問題はそこでは生じない。われわれの適合の理論では、アプリケーションに本質的な、内部アクション、非決定論、および安定性の統一された取り扱いが可能である。交互シミュレーション[1]は、インターフェースを[4]の実装に関連付けるために使用された。[11]で説明されているように、交互シミュレーションでは、スタックフリーダムに対する代替可能性の条件を満たさない。3適合理論このセクションでは、CCS[7,8]に関する必要な背景を述べ、スタックフリーダムおよび適合の概念を定義し、適合が前合同定理1であり、代替可能性特性を満たす定理2ことを証明する。3.1CCSプロセス名前の可算集合N={a,b,c,...}を仮定する。集合は、ラベルの集合と呼ばれる。集合は、アクションの集合と呼ばれる。αはAを範囲とし、λはLを範囲として、と書く。Lの部分集合Xについて、と書く。P上の範囲のCCSプロセスは、以下の式で定義される。P::=0|A<a1,...,an>|G1...Gn|P|Q|νaPG::=α.Pここで、Aはプロセス名を範囲にとり、式を定義する。名前aはνaPでバインドされていると主張する。Pの自由名はfnPと表され、バインドされていないPにおける名前である。定義1構造合同、≡。構造合同≡は、バインドされた名前および変数α変換の変更および総和の項の順序変更とともに、以下の規則に従って閉じられた項に関する最小合同関係congruencerelationである。CCSの動作の意味は、定義2に示されているラベル付けされた推移システムにより与えられる。このシステムは、CCSの最近の発表において標準であるように、われわれが規則[CONG]を追加したことを除き、Milner[8]により与えられたそのものである。以下の規則[SUM]では、Mの範囲は総和に及んでいる。定義2ラベル付け推移。とする。a.Pb.Qとa.Pb.Qの違いは重要である。前者は、内部選択を表し、プロセスはa.Pまたはb.Qへの推移を選択するが、後者は、外部選択[5]を表し、プロセスがまたはを提供することによりPまたはQに進むかどうかを環境が制御する。内部選択と外部選択との区別は、われわれの適合の概念では重要である。非同期アクションは、CCSにおける順次継続なしのアクションとしてモデル化される。したがって、非同期アクションは、aが非同期に生起する場合に、a|Pのように生成spawnされる。記法。名前とアクションの場合によっては空のシーケンスに対しおよびを書く。について、と書き、P≡P0、P’≡PnとなるようなP0、P1、...、Pnがある場合に、0≦i<nについて、となる。記法を使用するが、ただしγλ∈{λ,γλ,γγλ,...}である。となるようなが存在する場合にP→P’と書き、は、となるようなP’が存在することを意味し、P→は、あるについてであることを意味する。Pは、隠蔽アクションを実行できない場合、つまりであれば安定であり、アクションをまったく実行しない場合、つまりであれば終了状態である。最後に、簡略表記を使用して、λまたはのいずれかが内に現れるラベル間にあることを意味する。3.2スタックフリーダム、即時拒絶、および適合2つのプロセスPおよびQが内のローカル名で通信する場合、システムをと書くことができる。は、PおよびQに対するローカル名であるため、上で相互作用できる環境は他になく、したがって、上のPおよびQの相互作用が完全に成功するかどうかを検証することには意味がある。簡単に、進行がありえなければ上でプロセスがスタックしているといい、その一部分はにおける名前で通信することが可能な状態にある、つまり終了していなかったため、上の通信は成功していない。われわれのアプリケーションでは、Pは、通常、仕様コントラクトがQであるプロセスへのローカル接続を持つプログラムのモデルである。PとQによって表される実装との間の相互作用がスタックフリー、つまりスタックしえないことを検査したい。スタックフリーダムは、安全特性であり、システムP|Qの到達可能性分析により検査することができる。以下の定義では、スタックネスとスタックフリーダムを正確にしている。定義3スタックプロセス。が終了状態であり、あるに対しての場合、プロセスPは上でスタックしているという。このようなλを残留アクションと呼ぶ。定義4スタックフリープロセス。でとなるようなP’およびがなく、P’が上でスタックしている場合に、プロセスPは上でスタックフリーであるという。上述の状況において、であり、上でP’|Q’がスタックするような遷移を検索することにより定義4を適用する。定義3の制約および定義4の条件により、常にがローカルである状態で、における名前について内部反応γアクションのみが生起しうることが強制される。あるについてなので、PとQとの相互作用は、コアクションにより照合できない残留アクションλで終了する。λが入力アクションをモデル化する場合、コンポーネントは決して到着しないメッセージの受信を待ち続け、λが送信アクションをモデル化する場合、コンポーネントは決して消費されないメッセージを送信し続ける。後者の例は、処理されないリモートの例外メッセージである。このような状態は、多くの非同期アプリケーションにおける数々の問題の重要な指標となっている。セクション4には、実際のシステムの適合を検査する際の定義4の使用例を示す。P|Qがスタックフリーならば、P|Sは任意の選択された名前上でスタックフリーであるという代替可能性特性をS≦Qが保証するような適合関係≦を求める。例示的シナリオでは、これは、実装SがそのコントラストQにより表されるシステムP|Qのスタックフリーダムを検査しても安全であることを意味している。この目標を達成するために、関係≦は、S≦Qならば、任意のコンテキストで、少なくともSと同じ回数だけQが上でスタックするような関係でなければならない。この要求条件は、Sによって実際には送られない、CSP[5]の拒絶の概念によりエレガントに捕捉できるアクションを与える見込みはないことを意味する。しかし、残留アクションのすべての場合を除外しないので、拒絶要求条件単独では十分でないことがわかる。これが、拒絶が即時拒絶に強められる場合に、以下の定義の動機となっている。とし、Lは、空集合とともにLのシングルトンsingleton集合を表すものとする。定義5拒絶。XがLの部分集合であれば、Pが安定でありである場合、かつその場合に限り、PはXを拒絶するという。であり、P’がXを拒絶するようなP’が存在する場合、かつその場合に限り、PはXを拒絶できるという。定義6即時readiness。Y∈Lならば、Pが安定であり、λ∈Yならばである場合、かつその場合に限り、PはY上で即時readyであるという。自明であるが安定プロセスは上で即時であることに注意されたい。定義7即時拒絶。X⊆LかつY∈Lならば、PがY上で即時である状態からXを拒絶できる場合、つまり、であり、P’がXを拒絶し、P’がY上で即時であるようなP’が存在する場合、かつその場合に限り、Y上で即時となっている間にPはXを拒絶できるという。即時集合は、アクションに関して定義されるが定義6、拒絶は、コアクションに関して定義される定義5ことに注意されたい。最初、これは少し混乱させる可能性がある。例えば、プロセスaは、{a}を拒絶し、{a}上で即時である。定義8適合関係。プロセス上の2項関係Rは、PRQであればいつでも以下の条件が成立する場合、かつその場合に限り適合関係であるという。C1.ならば、およびP’RQ’となるようなQ’が存在する。C2.PがY上で即時である間Xを拒絶することができれば、QはY上で即時である間Xを拒絶できる。定義8の条件[C2]は、驚くべきことのように見えるかもしれない。これは、セクション3.3および3.4を含めて、以下で動機付けされ説明される。R1およびR2がプロセス上の2項関係である場合、R1○R2と表されるその合成を、R1○R2={P,Q|∃R.P,R∈R1∧R,Q∈R2}により定義する。補助定理1.{Ri}i∈Iを適合関係の族とする。すると、1.関係∪i∈IRiは適合関係である。2.任意のi,j∈Iについて、関係R1○R2は適合関係である。3.プロセス上の恒等関係は適合関係である。補助定理1.1は、CCSバイシミュレーションおよびシミュレーション[7]について標準的な方法により、すべての適合関係の和集合をとることにより最大の適合関係として≦を定義できることを示している。定義9適合、≦。最大の適合関係を適合と呼び、≦で表す。P,Q∈≦に対してP≦Qと書き、PはQに適合するという。定義8の条件[C2]により、P≦Qならば、QはPと同じ回数だけ名前a上でスタックすることが保証される。定義8では、即時制約は一度に1つの名前にしか課せられないことが非常に重要であるが、これは、即時集合Yが高々シングルトン集合であるという事実によるを選択すると、特別な場合として、即時制約のない標準拒絶条件が得られる。これにより、仕様を詳細化よりも非決定論的にすることができるが、それは、仕様が名前毎に異なる方法でその非決定論を解決することができるからである。例えば、ab≦abである。名前{a,b}のアルファベットについて考察すると、プロセスabは{a,b}を拒絶し、{a}と{b}の両方で即時である。プロセスabは、状態aからを拒絶し、状態{b}からを拒絶する。状態aから{a}で即時であり、状態bから{b}で即時である。したがって、条件[C2]は満たされる。読者は、いくつかのより興味深い例を検証したいことであろう。ただし、P≦QかつQ≦Pの場合、かつその場合に限りと書く。また、規則[CONG]により≡、⊆、≦であることも述べておく適合の他の代数的特性については[]を参照。命題1.適合関係≦は再帰的reflectiveかつ推移的transitiveである。以下の定理では、主要な理論的結果、前合同CCSの演算子は適合に関して単調である、定理1および代替可能性仕様は、安全に、それに適合するプロセスの代わりにできる、定理2を述べている。完全な証明については、[]を参照されたい。CをCCSコンテキストに渡るとし、これらはその中に穴hole[]と書くを持つプロセス式である。C::=[]|P|[]|[]|P|α.[]±M|νa[]C[Q]と書いて、C内の穴をQで置き換えて生じるプロセス式を表す。定理1前合同。P≦QならばC[P]≦C[Q]である。定理2代替可能性。P≦Qと仮定する。すると、上でC[Q]がスタックフリーであることは上でC[P]はスタックフリーであることを示す。以下の2つのセクションは、適合がCSPにおける安定失敗詳細化よりも細かく適合がトレースに関して定義されるか、または代替として、安定失敗詳細化が推移に関して定義されている場合、CCSにおける拒絶先行順序よりも粗いことを意味する。この意味で、適合は中間である。3.3適合および安定失敗詳細化適合の定義の中の条件[C2]は、CSP[5,12]における安定失敗詳細化の理論から手直ししたもので、トレースと拒絶の概念に基づいている。安定失敗モデルでは、プロセスPは、その失敗の集合により表される。Pの失敗は、ペアであり、ここではPの有限トレースであり、Xは拒絶集合である。つまり、イベントPの集合はの後の安定状態から拒絶できる。プロセスPは、PのトレースがQのトレースに含まれ、Pの失敗がQの失敗に含まれる場合にプロセスQを失敗詳細化する。われわれの適合定義では、拒絶を使用するが、より強い即時拒絶を条件[C2]で使用している。これは、適合がスタックフリーダムに関して代替可能であるべきという要求条件を動機としている。例えば、以下の式で定義された2つのプロセスPおよびQを考える。P=a.0およびQ=a.0γ.0プロセスがラベル集合にわたると考えると、Pの失敗3は、であり、Qの失敗はである。その結果、PはQを失敗詳細化することになる。しかし、Pは、a上でスタックしているが、Qはスタックしえず、それは、その唯一の安定派生形が0であり、スタックプロセスではないからである。したがって、PがQを失敗詳細化しても、Qのスタックフリーダムは、Pのスタックフリーダムを意味しない。対照的に、われわれの適合の定義における条件[C2]の即時制約では、Pが安定状態P自体からアクションaを実行することができるが、Qは不安定状態Q自体からしかアクションaを実行できないため、という帰結になる。スタックフリー適合に対応する自然なトレースモデルでは、その失敗で即時拒絶を使用するように安定失敗モデルを修正し、失敗が、R=X,Yが拒絶集合X⊆Lおよび即時集合Y∈Lからなる即時拒絶であるペアとなるようにする。CSPにおける安定失敗詳細化とスタックフリー適合との違いは、スタックネスとCSPデッドロックとの違いから生じる。CSPでは、デッドロックは、特別な成功する終了イベントが存在しないことにより示される。スタックネスは、ラベル付けされた推移システム内の複数の状態で直接観察可能であり、CSPデッドロックよりも区別しやすい。3.4適合および拒絶先行順われわれの適合の概念は、IainPhillipsの拒絶検証の理論[10]で定義されているような拒絶先行順に類似している。拒絶先行順では、拒絶集合を観察結果にすることにより拒絶またはデッドロックの後に生起することを観察することができる。[2]に従い、X⊆Lに対し、推移規則を追加することにより拒絶先行順を定義することができる。について、である場合、かつその場合に限り、と書く。通常の方法で、ベクトルにリフトする。次に、失敗トレースを定義する。≦rfで表される拒絶先行順は、f-tracesP⊆f-tracesQの場合、かつその場合に限り、P≦rfQと設定することにより定義される。この定義により、同時拒絶および即時特定が捕捉される。例えば、であれば、となり、これはaが安定状態であることを示し、ここで集合{a}は拒絶され、ラベルaが提供される。遷移がaγ.0により照合できないため、となることを観察することは興味深い。実際、拒絶先行順は十分強く、スタックフリーダムの代替可能性を保証する。しかし、適合よりも制約が強い。以下の式により定義されるプロセスPおよびQを考える。P=ab.ccb.aQ=ab.acb.c----------3最大拒絶集合に関して失敗を表し、シーケンスに対し<...>を使用する。----------定義からまたは[]の詳細を参照、P≦Qであるが、であることを検査することができる。P≦Qとなるのは、条件[C1]および[C2]からわかるようにQは異なる派生形を選択できるからである。条件[C1]は、Qの派生形cb.cにより明らかであり、[C2]は、Qの派生形ab.aにより明らかである。4アプリケーションセクション3に提示されている理論に基づき、共通プログラミング言語で書かれている非同期プログラムを分析するために使用できる適合検査器を実装した。このような言語例えば、C、Java登録商標、Cは、CCSで直接モデル化するのが面倒ないくつかの機能プロシージャ呼び出し、ポインタ、共有メモリ、例外、およびオブジェクトを持つ。われわれの適合検査器は、複雑な符号化を必要とせず直接そのような機能をサポートする言語ZINGに対応している。ZINGの動作に関する意味は、ラベル付け推移システムとして与えられる。SendおよびReceiveステートメント以外のすべてのステートメントは、γアクションのラベル付きの遷移としてモデル化される。SendおよびReceiveステートメントからの遷移は、対応するチャネル名でラベル付けされる送信または受信されるデータ値を無視する。適合の定義8では、CCSの構文を参照しておらず、ラベル付けされた遷移システムの意味論に純粋に基づいていることに注意されたい。したがって、定義8を直接使用して2つのZINGプロセスの間の適合を定義することができる。われわれの適合検査器を適用して、共通プログラミング言語で書かれている分散プログラムのコントラクトを検査した。次に、適合検査の実行方法と見つけたエラーについて説明する。われわれのアプリケーション例は、書店の在庫および発注プロセスを管理するための分散プログラムである。このシステムは、Microsoft社の製品開発グループにより作成され、メッセージ受け渡しおよびコントラクト仕様を受け付ける共通プログラミング言語の拡張となっている。コントラクトは、通信している状態マシンとして指定され、ソースコード内に型指定として現れる。コントラクトは、元々、メッセージの挙動の実行時検査をサポートすることを目的としていたが不要なメッセージシーケンスを除去し、プログラミングエラーを発見するため、ZING適合検査器を使用して、静的に検査することを試みることを決定した。われわれは、ZING適合検査器を開発環境に統合して、実装コードと突き合わせてスタックフリー適合に関してコントラクトを自動検査できるようにした。プログラミング言語、システム、およびコントラクトはすべて、われわれおよびわれわれの技術とは無関係に書かれたものであることを強調しておく。システムの構造は図1上に示されている。これは、ShoppingCarservice、InventoryService、OrderService、PublicInventoryService、およびInventoryProcessingの5つのサービスコンポーネントと、さらに2つのユーザインターフェースプロセスとを含む。サービスAからサービスBへ矢印は、AがBを使用しているBのクライアントである場合に1つある。5つのサービスはそれぞれ、関連するコントラクトを持ち、それは、サービスの公に見える挙動の指定である。図1上では、それぞれのコントラクトは、それが指定するサービスと関連して名前が付けられている。コントラクトのうち2つが図1下に示されている。コントラクトは、メッセージペイロードを無視して、メッセージの集合上で通信状態マシンを指定する4.例えば、Shoppingcartコントラクトは、CheckOutメッセージまたはCancelメッセージが受信されるまでサービスが型AddItemsまたはRemoveItemのメッセージを繰り返し入力することを指定するわれわれは、入力にTを使用し、出力にTを使用するが、Tはメッセージ型である。InventoryReservationコントラクトで使用されるTimeoutイベントは、特別なイベントである。Timeoutsは、実装言語の入力構文に付随させることができる。コントラクト宣言で、コントラクトの名前と同じ新しい型名を作成する。サービスの実装コードは、以下のように、実装が想定されるコントラクトを指定するサービス宣言クラス宣言とかなり似ている内に置かれる。他のサービスへの接続を表すオブジェクトを保持する変数は、それらのサービスを記述するコントラクトにより分類される。例えば、ShoppingCartService実装の以下のステートメントでは、InventoryServiceへの接続を作成し、contで続行する。コントラクト型に依存することにより、サービス実装を使用されるサービスのコントラクトを置き換えるZINGモデルに自動的に変換することが可能である。そうする際に、定理2に頼る。例えば、上記の接続作成は、ZINGステートメントinv=newcInventoryReservationに変換され、cInventoryReservationは、InventoryReservationコントラクトからコンパイルされたZINGクラスである。このクラスのコンストラクタを呼び出すことの副作用として、並列処理プロセスが生成され、コントラクトで指定された通りに動作する。これは、以下のCCSプロセスに対応する。ただし、[cont]はコードcontを表す。これは、セクション3.2の適合の理論を導入した際に、定義3および定義4の前後でコメントの中で言及されたCCS形式の一例であることに注意されたい。サービスとそのコントラクトの間の適合を検査することに加えて、われわれは、常に、サービスとそのサービスが使用するコントラクトとの間の相互作用におけるスタック状態を検査するスタックネス検証を実行する5。----------4メッセージ型自体は、コントラクト指定の一部としても宣言されるが、ここでは簡単のため省略した。5これは、例えば、サービスが自明なコントラクトを持ち、それでも、使用するサービスでスタックする可能性があるため必要である。このような場合も、適合検査器によって捕捉され、フラグが立てられる。----------書店システムの適合分析を、それぞれのサービス実装および関連するコントラクトをZINGにコンパイルすることにより実行したところ、2つのZINGプロセスが得られたので、それらをわれわれの適合検査器で比較した。適合検査は、合成的に実行された、つまり、コントラクト指定と突き合わせて一度に1つずつサービス実装を検査し、使用されるサービスを表すようにコントラクトを置き換えた。プロセス全体は完全自動である。われわれの適合分析により、以下で簡単に説明する、デッドロックを含む多数の重大なエラーを検出した。以下のリストには、どのコントラクトが検査されたか、定義8のどの条件[C1]または[C2]に違反したかを示し、また、上述のスタックネス検証の失敗も示している。これらのエラーは、コードを検査する前には見つからなかったものであることを強調しておく6。1InventoryReservation。欠落タイムアウト指定[C2]。コントラクトは、そのイベントループでサービスをタイムアウトにできることを指定できなかった。このため、サービスがタイムアウトの後すべての要求を拒絶するので、適合検査器により即時拒絶失敗が識別されることをもたらした。コントラクトは、Timeoutの場合を追加することにより是正された。Timeoutイベントは、内部γアクションとしてモデル化され、入力aに付随したときに、ZINGにより、aγ.0として表されるここで、タイムアウトの後には何も生じないことを仮定する。2InventoryReservation.指定されない繰り返し入力[C1]。前のエラーの修正後、適合検査器がシミュレーション失敗を報告した。問題は、コントラクトで、サービスがメッセージのComumitReservationを1回だけ取り、サービスのイベントループを終了することを指定したことにある。しかし、サービス実装では、CommitReservationの受信後にループを終了すべきなのに終了せず、実装が修正された。3ShoppingCart。スタックネス。図1は、コントラクトのShoppingCartおよび修正されたInventoryReservationを示している。実装では、InventoryServiceおよびOrderingサービスを使用する。適合検査では、サービスがCheckOutメッセージを受け取り、その後続けてCommitReservationメッセージをInventoryServiceに送信し、そしてAcknowledgementを受け取るまで待つという状況で、サービス実装がInventoryReservationコントラクトでスタックしたことを検出する。これは、InventoryServiceがタイムアウトになった場合に、デッドロックを受け取る。他の状況では、タイムアウトの結果、ShoppingCartServiceから送信された残留メッセージによりスタックネスが生じる。実装は修正された。4Inventory。サービス内に実装されない入力[C2]。コントラクトInventoryで指定されているが実装されていない入力があると、残留失敗が生じる。実装は是正された。5InventoryChangeNotification。特定のメッセージを受信した後、入力が利用できない[C2]。1つの特定の状態において、サービスイベントループ内でメッセージDoneを受信すると、サービスPublicInventoryServiceは、InventoryProcessingサービスにおける公開加入システムとの通信を終了せずにイベントループを終了するが、コントラクトはこの可能性を反映しない。したがって、そのシステムに対するメッセージは失われる可能性があり、実装が是正された。----------6コードは、完全には検証されていない。しかし、エラーのいくつかは、通常、検証によっても見つからないことに注意されたい。----------5結論われわれは、CCSの新規性のある詳細化関係を提示し、それが通信プロセスのスタックフリーダムの構成検査を行うのに好適であることを示した。適合は、目に見えるアクションおよび安定性が観察可能なラベル付けされた推移システムに直接適用可能であるという利点を有する。スタックネスは、非同期プロセスを検査するのに役立つ、孤立メッセージを考慮することによりCSPデッドロックよりも区別しやすい。われわれは、適合が代替可能性を満たすCCSプロセスに対する前合同であることを証明し、関連するプロセス先行順から区別した。表現力の高いモデル化言語であるZING用の適合検査器を構築し、分散システムに適用した。謝辞。われわれは、RobinMilner氏にはこの論文の草稿についてコメントを寄せて激励してくれたことについて、RankoLazic氏には話し合いの中でいろいろな思いつきを与えてくれたことについて感謝する。われわれは、TonyHoare氏がお膳立てしてくれた、ケンブリッジでの2002年6月のMicrosoftResearchErnieCohen、PaulGardiner、AndyGordon、RobinMilner、およびBillRoscoeおよびオックスフォード大学での2003年の11月のComputingLaboratoryChristieBolton、MichaelGoldsmith、RankoLazic、およびGavinLoweのワークショップの参加者たちに感謝する。また、ZINGの設計および実装作業に取り組んでくれたMicrosoft社のTonyAndrews氏にも感謝したい。参考文献"