JP2006024223A - オブジェクト指向言語による同時実行プログラムの実装 - Google Patents

Abstract

【課題】 本発明は、主流のオブジェクト指向言語に同時実行のサポートを追加する。これにより１つのアドレス空間内で実行できるか、または単一コンピュータ上で複数のプロセス間に分散できるか、またはローカルエリアまたはワイドエリアネットワーク内に分散できるプログラムを、プログラムのコーディングし直しをすることなく、開発できるようにする言語拡張を提供する。
【解決手段】 この態様の中心には、自アルゴリズム（論理的）スレッドを実行することができる、「サービス」という概念がある。サービスは明示的な同期プリミティブを使用してメモリを共有または同期しない。むしろ、データ共有と同期は、両方とも、メッセージ受け渡しを介して実行される、例えば、一組の明示的に洗練されたメッセージがサービス間で送信される。メッセージは、共有されるデータおよび必要な同期を実現するメッセージ交換のパターンを含むことができる。
【選択図】 図１

Description

本発明は、一般的にコンピュータシステムに関する。より具体的には、本発明は、オブジェクト指向環境における言語拡張機能を使用し、メッセージ受け渡し（ｍｅｓｓａｇｅ ｐａｓｓｉｎｇ）、コントラクト、およびオーケストレーションを通じて非同期プログラミングをサポートすることができるシステムおよび方法を対象とする。

同時実行アプリケーション（ｃｏｎｃｕｒｒｅｎｔ ａｐｐｌｉｃａｔｉｏｎ）のプログラミングは、大半のプロ開発者により、難しいものであり、誤りが発生しやすいものであると考えられている。ほとんどのシステム開発者は、このタイプのプログラミングに難儀しているが、その理由の１つは、ほとんどのビジネスアプリケーション開発者の守備範囲外だからである。

同時実行アルゴリズムは、いつでも適切であるとはかぎらないが、当を得た問題の解決に使用するのであれば、パフォーマンスおよびアルゴリズムの簡潔さに関して非常に大きなメリットがある。ワイドエリアネットワークに分散されるプログラムを開発することに対する関心が高まるとともに、通信待ち時間が急激に長くなり、順次実行のコストが急増していることから、同時実行プログラミングツールの必要性が高まりつつある。

しかし、問題の１つは、ほとんどのプログラマから同時実行が利用可能な機能は低水準であり、使いにくいという点である。同時実行がどのようなものであれ、それをサポートするプログラミング言語はわずかである。従来、同時実行をサポートするプログラミング言語は、専用言語であるか、小規模な学術研究機関内でしか使用されない言語である。

Ｊ２ＥＥおよび．ＮＥＴブランドの環境などのオブジェクト指向（ＯＯ）フレームワークでは、主流のプログラム設計に対しＯＯアプローチをとってきた。しかし、共有メモリに重点を置くと、同時実行に対するサポートが複雑になり、アプリケーションプログラミングよりもシステムプログラミング向きのサポートとなる。共有メモリは、同時実行のサポートを簡素化するうえでの主要な障害の１つであると広く認識されている。

したがって、この技術分野には、主流のＯＯ言語に対する同時実行のサポートを付け加え、共存を実装する大きな必要性が存在する。さらに、１つのアドレス空間内で実行できるか、または単一コンピュータ上で複数のプロセス間に分散できるか、またはローカルエリアまたはワイドエリアネットワーク内に分散できるプログラムを、すべてプログラムのコーディングし直しをすることなく、開発できるシステムおよび／または方法に対する未だ満たされていない必要性がある。この態様の中心には、自アルゴリズム（論理的）スレッドを実行する、「サービス」という概念がある。さらに、サービス間のメッセージベースのインターフェースを指定する手段に対する未だ満たされていない必要性もある。言い換えると、アプリケーションプログラミングを簡素化するためにＯＯおよびメッセージ指向言語を統合する必要があるということである。

メッセージ受け渡しによる従来のサービスは、特定のハードウェアプロセッサ向けに設計され、そのプロセッサでしか動作できない１９８０年代に開発された専用言語であるＯＣＣＡＭにより定義される。このプログラミング言語に埋め込まれている形式的プログラム仕様は新しいものではない。例えば、Ｅｉｆｆｅｌは、直接プログラミング言語自体で、制限された形態ではあるがプログラム仕様をサポートする。Ｅｉｆｆｅｌは、Ｂｅｒｔｒａｎｄ Ｍｅｙｅｒにより作成され、同氏の会社であるＩｎｔｅｒａｃｔｉｖｅ Ｓｏｆｔｗａｒｅ Ｅｎｇｉｎｅｅｒｉｎｇ（ＩＳＥ）により開発された高度なプログラミング言語である。

しかし、プロトコル仕様を実装から分離することは、現在のところ利用できない。この分離は、サービス同士の相互作用を抽象化する機能にとって極めて重要である。例えば、ＢｉｚＴａｌｋをベースとする言語であるＸＬＡＮＧは、サービスメッセージ交換パターン全体を１つのプロトコルとして公開する。しかし、この実装は、インターフェースから分離されておらず、コントラクト準拠の静的検証が困難である。

以下では、本発明のいくつかの態様の基本的な内容を理解できるように、発明の開示を簡単に説明する。この発明の開示は、本発明の概要を広範囲にわたって述べたものではない。この発明の開示は、本発明の鍵となる／決定的な要素を示したり、本発明の範囲を定めることを目的としていない。後で述べる詳細な説明の前置きとして、本発明のいくつかの概念を簡略化した形式で述べることのみを目的とする。

本明細書で開示され請求される本発明は、その一態様において、主流のオブジェクト指向（ＯＯ）言語で同時実行の高水準の抽象化を直接実現する。これは、複数のサービス間の通信を同時に管理するメカニズム（例えば、オーケストレーション）を利用する非同期メッセージ受け渡しを導入することにより正しい同時実行プログラムを簡単に書けるようにすることを目的とする同時実行モデルを提供する。

一態様では、本発明は、主流のオブジェクト指向言語に同時実行のサポートを追加する。これにより１つのアドレス空間内で実行できるか、または単一コンピュータ上で複数のプロセス間に分散できるか、またはローカルエリアまたはワイドエリアネットワーク内に分散できるプログラムを、プログラムのコーディングし直しをすることなく、開発できるようにする言語拡張が提供される。この態様の中心には、自アルゴリズム（論理的）スレッドを実行することができる、「サービス」という概念がある。したがって、サービスは明示的な同期プリミティブを使用してメモリを共有または同期しない。むしろ、データ共有と同期は、両方とも、メッセージ受け渡しを介して実行される、例えば、一組の明示的に宣言されたメッセージがサービス間で送信される。メッセージは、共有されるデータおよび同期を実現するメッセージ交換のパターンを含むことができる。

他の態様では、サービス間のメッセージベースのインターフェースを指定する方法、例えば、コントラクトが用意される。他の詳細をインターフェース（例えば、メソッド）およびコントラクトに追加するメカニズムも用意される。このような詳細は、形式的プロトコル定義を与えることができるメソッド呼び出しの順序付け（インターフェースの場合）、またはメッセージ（コントラクトの場合）を記述する機能を備える。

本発明の他の態様は、異なるコントラクト関係の革新技術を対象とする。コントラクトは、インターフェースのメンバの許容可能な呼び出しシーケンスの形式的指定である。これらは、双方向のメッセージベースのインターフェースとともに使用する場合に特に力を発揮するが、適用は、本明細書で説明されているように、従来のＯＯインターフェースにも及ぶ。例えば、本発明の一態様は、動的検証アルゴリズムの実装に関係する。より具体的には、この態様は、コントラクトを強制する実行時アルゴリズムに関係する。したがって、式のパターンに関係なく、実行時表現は、すべての正当なコントラクト状態を符号化する非決定論的有限状態マシンであってよいとも考えられる。そこで、この状態マシンを使用して、コントラクト仕様と突き合わせてメソッド呼び出しまたはメッセージの正当性を検証することができる。

本発明の他の態様は、ＯＯ言語で明示的に宣言されたメッセージの導入に関係する。メッセージ指向言語を採用する従来のシステムが知られているが、有向ペイロード伝送メッセージ（ｄｉｒｅｃｔｅｄ，ｐａｙｌｏａｄ−ｃａｒｒｙｉｎｇ，ｍｅｓｓａｇｅｓ）の明示的宣言は、ＯＯ言語との組合せであるため、新規性がある。特に、本明細書で説明されているように、メッセージ受け渡しの概念は、ＯＯ言語には新しいものであり、従来の概念とかなり異なる。プロトコルをメソッドまたはメッセージの時間的な順序付けのメソッドまたは有向メッセージの集合として表現することについては、他の態様により説明される。より具体的には、この革新技術のこの態様は、ＯＯ言語（例えば、ＶＢ．ＮＥＴブランドの環境）に形式的コントラクト（ｆｏｒｍａｌ ｃｏｎｔｒａｃｔ）を追加することに関係する。宣言されたメッセージまたはメソッドをパターンの字母として使用することにより、通信プロトコルの単純ではあるが十分に形式的なプロトコル定義を設定することができる。

コントラクトの概念は、オブジェクト指向言語に関して同じ種類のソフトウェア再利用を継承として実現するメカニズムを付加して増強することができる。特に、主要な概念の１つに、コントラクト拡張（ｅｘｔｅｎｓｉｏｎ）があり、これにより、コントラクトの世代間の非対称的互換性（ａｓｙｍｍｅｔｒｉｃａｌ ｃｏｍｐａｔｉｂｉｌｉｔｙ）が得られる。例えば、この概念を使用すれば、コントラクトの旧バージョンを使用しているクライアントは、新しいバージョンを使用するようにすでに更新されているサービスと通信することができる。

さらに、本発明は、オーケストレーションを対象とする。したがって、メッセージ指向プログラムの非同期的なニーズを取り扱うために、本発明の一態様では、「安全な」並列処理のいくつかの概念をサポートする言語構文を加える。このモデルは疎結合であるため、プログラムコンポーネントの分散をサポートすることができる。非同期アプリケーションをプログラムする際のプログラマの生産性、開発されたアプリケーションの信頼性、およびアプリケーションソースコードの総合的な可読性の高さが利点の一部としてあげられる。

理解しやすくするために、本発明の説明されている態様は、Ｓｅｒｖｉｃｅ、Ｓｅｎｄ、Ｒｅｃｅｉｖｅ、Ｓｅｌｅｃｔ Ｒｅｃｅｉｖｅ、Ｗａｉｔ、Ｓｐｌｉｔ、Ｔｉｍｅｏｕｔ、Ｉｎｎｅｒ Ｓｅｒｖｉｃｅｓ、Ｂｅｇｉｎ、Ｃａｔｃｈ Ｒｅｃｅｉｖｅ、Ａｃｃｅｐｔ、Ｓｐｌｉｔ Ｓｅｌｅｃｔ Ｒｅｃｅｉｖｅというキーワードに関係するＶｉｓｕａｌ Ｂａｓｉｃ（ＶＢ）を対象とする。併せて、この新しい言語構文は、メッセージ同士を並列に処理するためのモデルを実装することができる。本発明は、疎結合同時実行と密結合並列処理用のコルーチンとをサポートすることができると考えられる。これらの構文については、本書の後の方で詳しく説明する。

本発明のいくつかの態様によるコンパイラアルゴリズムを使用することができる。特に、スレッドのコンテキストをブロックすることなく並列ウエイト（ｐａｒａｌｌｅｌ ｗａｉｔｓ）が発生するようにコルーチンベースのコードを複数のコード断片に細分するコンパイラのアプローチは、本発明の他の新規性のある態様である。メッセージの到着を待っている間に現在のスレッドを潜在的にブロックする可能性のあるソースコード内のそれぞれの場所を切り離すことにより、複数のそのような場所で並列待機するか、または代替として、スレッドコンテキストで他の何らかの計算を続行するようにできる。前記の関係する目的を達成するために、本発明のいくつかの例示されている態様について、以下の説明および付属の図面に関して本明細書で説明される。ただし、これらの態様は本発明の原理を採用する様々な方法の少数のみを示しており、本発明はこのような態様およびその等価物すべてを含むことを意図している。本発明の他の利点および新規性のある特徴は、図面を参照しつつ本発明の以下の詳細な説明を読むと明白になるであろう。

次に、本発明は、本明細書全体を通して類似の番号が類似の要素を示すために使用される図面を参照しつつ説明される。以下の説明では、説明を目的として、本発明を完全に理解できるようにする多数の具体的詳細を述べている。しかし、本発明は具体的詳細を知らなくても実施できることは明白であろう。他の場合には、本発明を説明しやすくするために、よく知られている構造および装置がブロック図形式で示されている。

本出願で使用されているように、「コンポーネント」、「システム」および「メカニズム」などの用語は、コンピュータ関連のエンティティ、つまりハードウェア、ハードウェアとソフトウェアの組合せ、ソフトウェア、または実行中のソフトウェアのいずれかを指すことを意図されている。例えば、コンポーネントとして、プロセッサ上で実行されているプロセス、プロセッサ、オブジェクト、実行可能ファイル、実行スレッド、プログラム、および／またはコンピュータなどがある。一例として、サーバ上で実行されているアプリケーションとサーバは両方ともコンポーネントであってよい。１つまたは複数のコンポーネントを１つのプロセスおよび／または実行スレッド内に常駐させることができ、またコンポーネントを１台のコンピュータにローカルとして配置し、および／または２台以上のコンピュータ間に分散させることができる。

以下では、本発明の様々な態様について説明する。本開示はＶｉｓｕａｌ Ｂａｓｉｃ（ＶＢ）環境で本発明のシステムおよび方法を採用する態様に関して説明されているが、本明細書で開示されている概念は、本発明の精神、範囲、または機能から逸脱することなくオブジェクト指向（ＯＯ）環境とともに採用することができることは理解されるであろうことに留意すべきである。

一般に、本発明の一態様は、ＶＢ．ＮＥＴブランドの環境における言語拡張機能を使用し、メッセージ受け渡し、コントラクト、およびオーケストレーションを通じて非同期プログラミングをサポートすることができるシステムおよび方法を対象とする。つまり、本発明の開示されている態様によれば、ＶＢオーケストレーションでは、プロトコルを記述し、サービスまたはクライアントをそれに応じてコーディングすることができるということである。本発明を使用すると、対話状態を明示的にコーディングし管理する必要性が緩和されることは、理解されるであろう。

まず図１を参照すると、本発明の一態様によるオブジェクト指向システム１００の一般的なブロック図が示されている。すでに述べたように、理解しやすくするために、システム１００は、ＶＢアプリケーション向けであるものとして、本明細書で説明されている。ＶＢ環境は、本発明のいくつかの態様について説明するために主に使用されるが、システム１００は、本明細書で説明されている本発明の範囲から逸脱することなく知られている任意のオブジェクト指向言語に適用することができることは理解されるであろう。一般に、システム１００は、クライアント１０２、コントラクトコンポーネント１０４、オーケストレーションコンポーネント１０６、およびＮを整数として複数のターゲットサービス１０８₁〜１０８_Nを含むように構成することができる。ターゲットサービス１０８₁〜１０８_Nは、これ以降、ターゲットサービス１０８と総称されることは理解されるであろう。

コントラクトコンポーネント１０４は、ペイロード伝送メッセージ、または複数のメッセージと、それらのメッセージの実装スケジュールを識別する１つのプロトコルとの集合を含むことができる。コントラクトコンポーネントは、代替として、複数のメソッドまたは複数のメソッドの集合の転送を対象とすることもできることは理解されるであろう。

オーケストレーションコンポーネント１０６は、コントラクトを解釈し、サービス１０８の並列処理および／または同時実行を容易にするように構成することができる。例えば、オーケストレーションコンポーネント１０６は、複数のメッセージとともに（複数の）メッセージの複数のターゲットの処理を容易にするように構成することができる。本発明には新規であるが、図１のオーケストレーションコンポーネントは、サービスへ／からのメッセージ受け渡しを介してオブジェクト指向環境とメッセージ指向環境を統合するという基本的な新規性のある概念および革新技術を一層向上させることは理解されるであろう。

図２は、本発明の一態様によりコントラクトおよびメッセージを交換する方法を例示する図である。説明を簡単にするために、本明細書に例えば流れ図の形で示されている１つまたは複数の方法は、一連の動作として示され、説明されているが、本発明は、一部の動作が本発明により本明細書に示され説明されているのと異なる順序で、および／または他の活動と同時に発生しうるので、動作の順序によって制限されないことは理解され、認識されることであろう。例えば、当業者であれば、代替として方法を一連の相互に関連のある状態またはイベントとして状態図などの中に表すことが可能であることを理解し、認識するであろう。さらに、本発明により、方法を実装するために例示されているすべての動作が必要なわけではない。

２０２で、コントラクトが宣言される−本明細書で説明されているように、コントラクトの宣言は、複数のメッセージまたはメソッドとともにオプションの展開のパターンをも定義することを含むことができることは理解されるであろう。２０４で、コントラクト内に具現化されるメッセージ（またはメソッド）はターゲットサービスに送信される。次に、２０６で、メッセージ（またはメソッド）は受信され、遷移が引き起こされる。最後に、コントラクトを実装し、（複数の）メッセージおよび／または（複数の）メソッド内に含まれるコードを使用するために、２０８でメッセージが受け入れられ、その後２１０で逆コンパイルされる。

同時実行モデル
再び図１を参照するが、クライアント１０２とサービス１０８との間に共有状態がある同時実行には、たとえ熟練プログラマであっても問題があることが実証されていることに留意されたい。様々な力がソフトウェアをクライアント１０２とサービス１０８との間の同時実行および非同期相互作用に向けて押し引きするが、正しいものを実現することの難しさが障害となっている。本発明は、正しい同時実行プログラムを書く際の一部の複雑さを緩和するために同時実行モデルを使用するシステムおよび／または方法を対象とする。

従来の実装とは反対に、図１に例示されている本発明のＶＢオーケストレーション例では、インメモリ状態を共有するどの２つの実行行も同時実行とならない。例示されているように、本発明は、サービス１０８を使用して、同時実行を容易に行えるようにしている。これらのサービスでは、個別のサービスの外部にあるコードと状態を共有しない。さらに、非同期通信を実現するために、図１に例示されている本発明のシステムは、コントラクトコンポーネント１０４または「メッセージ受け渡し」手法を使用するが、これは、言語内に明示的なＳｅｎｄおよびＲｅｃｅｉｖｅ演算として現れ、オーケストレーションコンポーネント１０６内に実現される。

非同期メッセージ受け渡しの導入には、複数のサービス間の通信を同時に管理するメカニズムが必要であることは理解されるであろう。そこで、同時実行サービス間の通信を調整するメカニズムの集まりは、「オーケストレーション」と名付けられ、図１のオーケストレーションコンポーネント１０６により使用される。

以下で詳述するように、擬似並列実行（例えば、Ｓｐｌｉｔ）を導入する言語メカニズムが示されている。しかし、これらのメカニズムは、実際には、同時実行ではなく同時実行待機（ｃｏｎｃｕｒｒｅｎｔ ｗａｉｔｉｎｇ）を実現する。サービス１０８およびオーケストレーションコンポーネント１０６の組合せにより、競合状態および同期しないメモリアクセスの危険を冒すことなく同時実行および非同期の動作が可能である。本発明により、２つのサービス間のメッセージ交換は、コントラクトコンポーネント１０４により管理される対話として生じる。コントラクトコンポーネント１０４は、サービス１０８のメッセージング動作の仕様を定め、やり取りする相手のサービスの実装にアクセスせずにある種の形態の正しさ（例えば、メッセージ交換のパターンへの適合、デッドロックからの解放）について個々のサービス１０８をチェックすることができる。したがって、サービスの動作を理解する際の主要なアーチファクトはその実装されたコントラクトであることは理解されるであろう。

コントラクト
図３を参照すると、本質的に、コントラクト１０４は、より豊富な意味を持つ非同期メッセージ受け渡しのインターフェース宣言として定義することができる。つまり、メッセージコンポーネント３０２を使用して一組のメッセージ（またはメソッド）および許容可能なメッセージ交換のシーケンスを記述するオプションのプロトコルまたはパターンコンポーネント３０４を指定するということである。さらに、コントラクトコンポーネント１０４は、既存のコントラクトコンポーネントを拡張するコントラクト拡張コンポーネント３０６を使用することができる。

図４は、本発明の様々な態様によりコントラクトを宣言する方法２０２を例示する図である。本明細書で説明されているように、コントラクトの宣言は、複数のメッセージまたはメソッドだけでなくオプションのパターンも定義することを含むことができる。図４を参照し、４０２に進むと、そこではコントラクトタイプが宣言されている。特に、ＶＢの実施例では、コントラクト宣言は、コントラクト上のクライアントパースペクティブおよびサーバパースペクティブを表す２つのＶＢ型を作成する。例えば、宣言「Ｃｏｎｔｒａｃｔ Ｃ」は、型「Ｃ」（クライアントパースペクティブを表す）および型「Ｉｍｐｌｅｍｅｎｔｓ Ｃ」（サーバパースペクティブを表す）を作成する。例えば、以下は、アラームクロックサービスのコントラクト例である。

さらに、コントラクトを拡張しスヌーズ機能を追加したアラームクロックサービスのコントラクトを以下に示す。

状況を示し、理解しやすくするために、コントラクトの文法および意味について以下で説明する。例を以下に示す。

図３を参照しつつすでに説明したように、コントラクトではメッセージの集合３０２、およびオプションにより、許容可能なメッセージ交換シーケンスを記述するパターン３０４、および／または図３に例示されているようなコントラクト拡張３０６を指定できる。パターン３０４が指定されていない場合、指定されたすべてのメッセージシーケンスが使用可能であることに留意されたい。コントラクト拡張メカニズム３０６は、エラボレーテッドコントラクト（ｅｌａｂｏｒａｔｅｄ ｃｏｎｔｒａｃｔ）を使用して分類されたコネクタとエラボレーティングコントラクト（ｅｌａｂｏｒａｔｉｎｇ ｃｏｎｔｒａｃｔ）を使用して分類されたコネクタとの間の対話が可能であるようにコントラクトに追加するメカニズムである。

図４を再び参照し、４０４に進むと、そこで、メッセージを宣言できる。次に、４０６で、オプションによりパターンを指定できる。４０６で指定されたパターンは、状態マシンとして指定できる。これらの状態は、ＳｔａｔｅＴｒａｎｓｉｔｉｏｎＳｔａｔｅｍｅｎｔＧｒｏｕｐｓ内のラベルで指定できる。上述のアラームクロック例では、開始状態は「開始（ｓｔａｒｔ）」という名前である。メッセージの送受信とともに他のコントラクトの実行により、状態マシンに遷移が引き起こされる。ＳｔａｔｅＴｒａｎｓｉｔｉｏｎＳｔａｔｅｍｅｎｔＧｒｏｕｐが複数のＳｔａｔｅＴｒａｎｓｉｔｉｏｎＳｔａｔｅｍｅｎｔを含む場合に、パターンがグループ内にそれらの遷移の１つを許す。

４０８で、パターンに関連して使用されるトリガを定義することができる。特に、ＭｅｓｓａｇｅＴｒａｎｓｉｔｉｏｎＳｔａｔｅｍｅｎｔ内の矢印の左にある名前はトリガであり、メッセージまたはコントラクトの名前とすることができる。次に、４１０で、ターゲットが識別される。矢印の右にある識別子はターゲットであり、状態の名前とすることができる。トリガがない場合、ターゲット状態のトリガが発生すると遷移が生じる。トリガがコントラクトの場合、その効果は、コントラクトのパターンの新しいインスタンスの実行である。複数のターゲットがある場合、この遷移はすべてのターゲットに対し並列に行われる。この状況を分割遷移（ｓｐｌｉｔ ｔｒａｎｓｉｔｉｏｎ）と呼ぶ。ターゲットがＩｍｍｅｄｉａｔｅの場合、遷移は、最後のトリガが完了したときではなく最初のトリガが開始したときに発生する。これは、特に、トリガがコントラクトの場合に有用であることに留意されたい。

一実施例によれば、状態

は

と等価である。

同様に、状態

は

と等価である。

さらに、状態

は

と等価である。

当業者であれば、「Ｏｒ」、「Ａｎｄ」、および「Ｔｈｅｎ」は、式の構文内のそれぞれ「Ｏｒ」、「Ａｎｄ」、および「ＡｎｄＡｌｓｏ」と同じ優先順序関係を持つことを理解するであろう。

一態様では、「Ｉｎ Ｍｅｓｓａｇｅ」または「Ｏｕｔ Ｍｅｓｓａｇｅ」として与えられたトリガは、適切な方向に進行するコントラクト内で宣言されたメッセージを表すことができる。他の態様では、「Ａｎｙ Ｉｎ Ｍｅｓｓａｇｅ」または「Ａｎｙ Ｏｕｔ Ｍｅｓｓａｇｅ」として与えられたトリガは、適切な方向に進行するメッセージを表すことができ、コントラクト内で宣言されていないメッセージとすることができる。

与えられた状態は、与えられたトリガに関して高々１回の遷移を行うことができる。本発明のシステムおよび方法によれば、状態がメッセージについて遷移する場合、その状態はそのメッセージを受け付ける。状態が複数のメッセージを受け付けることができ、１つの状態により受け付けられるメッセージは必ずしもすべ同じ方向に進行するわけではない。例えば、すべてのメッセージが同じ方向に進行しない場合、反対方向に進行する状態Ｓにより受け付けられるすべてのメッセージを受け付けるわけではない状態Ｓにより受け付けられるメッセージに対するターゲット状態はそれらのメッセージを無視する。

「終了（Ｅｎｄ）」への遷移で、状態マシンの現在の行が終了する。「停止（Ｓｔｏｐ）」への遷移で、状態マシンの現在の行が終了する。分割遷移がない場合、「終了」および「停止」は等価であることに留意されたい。

図４を再び参照すると、本発明のシステムおよび方法により、接続を通じてメッセージの送受信を行うことができる。接続は、４０２で宣言されたコントラクト型である型を持つデータである。このコントラクト型は、コントラクトに名前を付けることにより指定できることは理解されるであろう。その一方で、接続は、コントラクト実装型である型を持つデータとすることができる。コントラクト実装型は、コントラクトの名前の前に指定「Ｉｍｐｌｅｍｅｎｔ」を付けることにより指定することができる。コントラクト型を持つ接続は、Ｉｎメッセージを送信し、Ｏｕｔメッセージを受信することができる。コントラクトＩｍｐｌｅｍｅｎｔｓ型を持つ接続は、Ｏｕｔメッセージを送信し、Ｉｎメッセージを受信することができる。

分割遷移
４１０で、状態遷移が複数のターゲットを持つ場合、その遷移を並列でのすべてのターゲットへの分割遷移と呼ぶ。例えば、分割遷移は、その分割遷移からの一部の経路がＳに収束する場合に部分的に状態Ｓでマージし、全部の経路が収束する場合に完全にマージする。状態Ｔが分割遷移の直接または間接ターゲットの場合、分割遷移がＴのところでまたはＴの前で完全にマージしていない限り、分割遷移を通らないＴへの経路はありえない。分割遷移が状態Ｓでマージする場合、Ｓからの遷移は、その分割遷移からのすべての経路がＳに到着するまで発生しえない。簡単に言うと、分割／マージは適切にネストし、分割／マージの真ん中への遷移はありえない。

例を以下に示す。

パターン

は、メッセージシーケンスＭ１、Ｍ１、Ｍ２、Ｍ４、Ｍ３、Ｍ３、Ｍ５を受け入れる。Ｓ１を含むそれぞれの分割遷移では、Ｍ３がマージ状態Ｓ３に遷移する必要があり、したがって等しい数のＭ３およびＭ１メッセージがありうる。

パターン

では、Ｍ１をＣｏｎ１のメッセージと混ぜることができるが、これは、Ｍ２がＣｏｎ１の完了後に発生することを必要とする。このパターンは、さらに、「終了」をマージ状態とすることができることも例示していることに留意されたい。

コントラクト拡張
本発明のシステムおよび方法によれば、４１２で、コントラクト拡張メカニズム（例えば、図３の３０６）を採用し、エラボレーテッドコントラクトを使用して分類されたコネクタとエラボレーティングコントラクトを使用して分類されたコネクタとの間の対話が可能であるようにコントラクトに追加することができる。対話の一方の側のみが、使用するコントラクトに関する選択権を有する。決定は、拡張の型によって行われる。

文法および意味の例は以下の通りである。

ここで、Ｅｘｔｅｎｄｓステートメント内の名前を、包含コントラクト（ｃｏｎｔａｉｎｉｎｇ ｃｏｎｔｒａｃｔ）でないコントラクトまたは包含コントラクトを拡張または精緻化するコントラクトの名前とすることができる。

コントラクトＢがコントラクトＡを拡張する場合、
・ Ａのすべてのメッセージは、Ｂのメッセージである。
・ Ａのすべての状態は、Ｂの状態である。
・ Ａによってホストされるすべてのコントラクトは、Ｂによってホストされる。
・ Ｂは、Ａから継承した状態から遷移を除去することはできない。
・ Ｂは、メッセージ、状態、およびホストされているコントラクトを追加することができる。
・ Ｂは、Ａから継承した状態に遷移を追加することができる。追加された遷移はすべて、同じ方向に進行するメッセージ用とすることができる。例えば、追加された遷移がＩｎメッセージ用であれば、クライアントは、ＡまたはＢのいずれかを使用してＢを実装するサービスに接続することができる。追加された遷移がＯｕｔメッセージ用であれば、クライアントは、ＡまたはＢのいずれかを使用してＡを実装するサービスに接続することができる。

プログラムテキストにおいて、Ａの状態は、Ｂが遷移をそれに追加した場合のみＢ内で繰り返され、追加された遷移のみが現れる。設計では、継承された遷移は見えているが、不変として視覚的マークを付けられていることに留意されたい。

コネクタ
図２を再び参照すると、本発明のシステムおよび方法により、動作２０４と２０６との間のメッセージ交換は、接続を介して実行される。接続の両端のコードは、コネクタファクトリを介して作成されるコネクタを通じてメッセージの送受信を行う。コントラクト型ＣＴでは、クライアントサイドコネクタは、型ＣＴを有するが、サーバサイドコネクタは型Ｉｍｐｌｅｍｅｎｔｓ ＣＴを有する。

オーケストレーション
さらに、Ｓｐｌｉｔ演算は、複数の実行行を生成し、そのどの行も出力するまで実行され、出力されたときに、他の実行行を実行できる。様々な言語演算において、実行行に結果を出力させることができる。そのようなものには、Ｒｅｃｅｉｖｅ（例えば、メッセージの到着を待つ）、およびＷａｉｔ（例えば、特定の時間間隔の間待つ）がある。

一組のメソッドは、オーケストレーションユニットを形成するか、またはそれらのメソッドの１つの出力結果でのメソッドでの１行が実行可能であれば、オーケストレートするということができる。これにより、呼び出しが戻るまで実行がメソッド呼び出しを通り過ぎるということはないことに注意されたい。オーケストレーションクラスのインスタンスメソッド（基本および派生クラス内のメソッドを含む）は、所定のインスタンスについてオーケストレートする。

オーケストレーションクラスは「ｏｒｃｈｅｓｔｒａｔｉｏｎ」修正子を付けて宣言される。オーケストレーションクラスは、共有メソッドまたはプロパティを持ちえない。この態様によれば、オーケストレーション演算はＶＢステートメントであり、いくつかの制約条件に従うが、どのメソッドにも出現しうる。

図２を再び参照すると、２０４で、Ｓｅｎｄステートメントは以下のように構成することができる。

この態様によれば、Ｓｅｎｄステートメントは、オプションの式である、特定のコネクタを通じてメッセージを送信する。コネクタの式が存在しないことで、メッセージが一次コネクタを通じて送信され、サービス内でのみ許可されることを意味することができる。このコネクタの式をコントラクトまたはコントラクト実装型とすることができることは理解されるであろう。

存在する場合、識別子は、コントラクトのメッセージの名前とすることができ、そのメッセージは適切な方向を持ちうる。メソッド呼び出しと同様に、引数は、メッセージのパラメータについて型検査される。

Ｍｅｓｓａｇｅキーワードが存在する場合、この式は、Ｓｙｓｔｅｍ．ＭｅｓｓａｇｅＢｕｓ．Ｍｅｓｓａｇｅに変換可能であり、送信するメッセージオブジェクトを識別する。

同様に、２０６で、Ｒｅｃｅｉｖｅステートメントは以下のように構成することができる。

Ｒｅｃｅｉｖｅステートメントは、特定のコネクタを通じてメッセージを受信することができ、メッセージが到着するまでブロックする。コネクタの式が存在しない場合は、メッセージが一次コネクタを通じて受信され、サービス内でのみ許可されることを意味する。コネクタの式は、コントラクトまたはコントラクト実装型とすることができ、識別子は、もし存在すれば、コントラクトのメッセージの名前を指定することができ、メッセージは適切な方向を識別することができる。Ｒｅｃｅｉｖｅステートメントで宣言されたパラメータは、ローカル変数宣言と似たスコープに入る。さらに、Ｒｅｃｅｉｖｅステートメントで宣言されていないパラメータは、別の場所でローカル変数として宣言することができる。

Ｍｅｓｓａｇｅキーワードが存在する場合、関連するパラメータは、Ｓｙｓｔｅｍ．ＭｅｓｓａｇｅＢｕｓ．Ｍｅｓｓａｇｅとして宣言することができ、Ｒｅｃｅｉｖｅで受信メッセージオブジェクトをローカル変数に割り当てることができる。Ｍｅｓｓａｇｅキーワードが存在し、特定のメッセージ名が与えられていない場合、Ｒｅｃｅｉｖｅは、フィルタ式（ｆｉｌｔｅｒ ｅｘｐｒｅｓｓｉｏｎ）がもし存在すればそれを満たすメッセージを受信することができる。

そのうえ、存在する場合、Ｒｅｃｅｉｖｅの中のＷｈｅｎ式がＢｏｏｌｅａｎフィルタとして動作する。フィルタ式が存在する場合、そのフィルタがＴｒｕｅに評価されればメッセージが受信され、そうでなければ、他の何らかのＲｅｃｅｉｖｅがそれを消費するまで無視される。フィルタ式は、そのフィルタ式が付けられたｒｅｃｅｉｖｅ句のパラメータおよび受信されたメッセージオブジェクトのメンバにアクセスすることができるが、他の非定数宣言にはアクセスできない。フィルタ式が存在しないことは、常に値「Ｔｒｕｅ」を持つフィルタ式と等価である。

例えば、

の形のＲｅｃｅｉｖｅステートメントは

に等価である。

Ｗａｉｔステートメントは以下のように構成できる。

Ｗａｉｔステートメントは、型Ｓｙｓｔｅｍ．ＴｉｍｅＳｐａｎとすることができる式により与えられる指定間隔の間実行をブロックする。Ｗａｉｔステートメントを使用すると、間隔が０であっても、１つの実行行で出力できる。

Ｗａｉｔステートメントとして

形のステートメントは

に等価である。

注意：Ｔｈｒｅａｄｉｎｇ．Ｔｈｒｅａｄ．Ｓｌｅｅｐ（）は、オーケストレーション内の他の行を実行することを許さずにスレッドをブロックできるので、オーケストレーションコードの内部では使用されないことが重要である。

受信されると、遷移を引き起こすことができる。Ｂｅｇｉｎステートメントは以下のように構成できる。

識別子は、ローカル変数として宣言することができる。変数の型は、コントラクト型またはコントラクト実装型とすることができる。初期化子（ｉｎｉｔｉａｌｉｚｅｒ）は存在できる。

Ｂｅｇｉｎステートメントは、指定されたコントラクトにより管理される対話の開始を待つ。当業者であれば、Ｂｅｇｉｎステートメントは一種のインラインサービスを表すことを理解するであろう。このような対話は、他のコード本体がそのコントラクト型の逆のコネクタを作成し、その後そのコネクタを通じてメッセージを送信するときに開始する。対話が開始すると、初期化子が評価され、その値が変数に代入され、実行が続く。

Ｂｅｇｉｎは、部分対話の相関関係を求めるためのメカニズムを提供する。相関関係のある部分対話に関し、コネクタの初期化は、コネクタを単独の引数として持つＮｅｗ式である。接続の他方の側のコネクタは、コネクタを単独の引数として持つＮｅｗ式により作成済みであろう。その上、引数として与えられた２つのコネクタも接続されていることであろう。

Ｂｅｇｉｎステートメントとして

形のステートメントは

に等価である。

最後に、そのメッセージは、２０８で受け入れることができる。そこで、Ａｃｃｅｐｔ Ｓｔａｔｅ Ｓｔａｔｅｍｅｎｔは以下のように構成できる。

ＡｃｃｅｐｔＳｔａｔｅＳｔａｔｅｍｅｎｔは、接続が特定のコントラクト状態に遷移するまで待機する。コネクタの式が存在しないことで、状態が一次コネクタを通じて受け付けられ、サービス内でのみ許可されることを意味することができる。コネクタの式は、コントラクトまたはコントラクト実装型とすることができ、識別子で、コントラクトの状態パターンの状態に名前を付けることができる。

Ａｃｃｅｐｔ状態ステートメントは、メッセージを消費しない。特に、状態遷移を引き起こしたメッセージは消費されない。ブロック解除には、状態遷移が必要である。Ａｃｃｅｐｔ状態ステートメントが開始したときに接続がすでに名前付きの状態に入っている場合、Ａｃｃｅｐｔ状態ステートメントは、接続がその状態に再入するまで待機する。

Ａｃｃｅｐｔ ＳｔａｔｅステートメントがＳｅｌｅｃｔ Ｒｅｃｅｉｖｅステートメントの一部としてだけでなく、ｃａｔｃｈ ａｃｃｅｐｔステートメントの一部としても、特に有用であることは理解されるであろう。

Ａｃｃｅｐｔ状態ステートメントとして

という形のステートメントは

に等価である。

Ｓｅｌｅｃｔ Ｒｅｃｅｉｖｅステートメントは以下のように構成できる。

ＳｅｌｅｃｔＲｅｃｅｉｖｅステートメントは、メッセージの集合（それぞれ異なるコネクタを通る可能性がある）の１つ（または複数）を受信することができ、および／または１つまたは複数の対話を開始し、および／または１つまたは複数の接続の状態を受け入れるか、またはタイムアウトになり、（複数の）メッセージ／（複数の）対話／（複数の）状態に関連付けられたコード本体、またはタイムアウトを実行することは理解されるであろう。タイムアウト式は、タイムスパンを示さなければならない。

複数のＣａｓｅＲｅｃｅｉｖｅＣｌａｕｓｅがＣａｓｅＲｅｃｅｉｖｅＳｔａｔｅｍｅｎｔ内に存在する場合、すべての句の条件が満たされることができ、条件に関連付けられたコード本体の実行がトリガされる。

Ｓｐｌｉｔステートメントは以下のように構成できる。

Ｓｐｌｉｔステートメントは、実行を適当に複数の論理実行行に分割することができる。これらの実行行は、実行行でメッセージの待機をブロックしたときに必ず次のブロック解除された行が実行されることを除き、語彙順序で順次実行することができる。Ｓｐｌｉｔステートメントのどの２行も同時実行されないことは理解されるであろう。Ｓｐｌｉｔの１行内にあるＲｅｃｅｉｖｅステートメントは、Ｓｐｌｉｔの他の行から送信されたメッセージに対する応答を受信することはできない。当業者であれば、これにより特定のメッセージに対する応答を相互に関連付けることができることを理解するであろう。

Ｓｐｌｉｔ Ｆｏｒ Ｅａｃｈステートメントは以下のように構成できる。

ＳｐｌｉｔＦｏｒＥａｃｈＳｔａｔｅｍｅｎｔＧｒｏｕｐの本体は、各反復がＳｐｌｉｔＳｔａｔｅｍｅｎｔＧｒｏｕｐの別々の１行であるかのように実行することができる。コレクションを通る完全な反復は、本体の実行前に実行できる。

Ｓｐｌｉｔ Ｓｅｌｅｃｔ Ｒｅｃｅｉｖｅステートメントは以下のように構成できる。

Ｓｐｌｉｔ Ｓｅｌｅｃｔ Ｒｅｃｅｉｖｅステートメントは、受信されたメッセージ、開始された対話、およびタイムアウトを処理する実行行をいくつでも自動的に作成する。

Ｓｐｌｉｔ Ｓｅｌｅｃｔ Ｒｅｃｅｉｖｅステートメントの

という形は、

と微妙にまたかなり異なっているが、類似している。

Ｓｐｌｉｔ Ｓｅｌｅｃｔ Ｒｅｃｅｉｖｅステートメントは、１行が終了するのを待つのではなく、１行が出力する場合に必ずアクティブにできる。実行行でＳｐｌｉｔ Ｓｅｌｅｃｔ Ｒｅｃｅｉｖｅステートメントの外に制御を移すと、Ｓｐｌｉｔ Ｓｅｌｅｃｔ Ｒｅｃｅｉｖｅステートメントの他のすべての行を終了することができる。

Ｃａｔｃｈ Ｒｅｃｅｉｖｅステートメントは以下のように構成できる。Ｔｒｙステートメントは、メッセージを受信するハンドラを指定できる。この概念を実装するために、新しい形式のＣａｔｃｈステートメントを使用することができる。

Ｃａｔｃｈ Ａｃｃｅｐｔ Ｓｔａｔｅステートメントは以下のように構成できる。Ｔｒｙステートメントは、接続の状態を受け付けるハンドラを指定できる。この概念を実装するために、新しい形式のＣａｔｃｈステートメントを使用することができる。

新しいＥｘｉｔステートメントを考える。例えば、新しいｅｘｉｔタイプとしてＬｉｎｅとＳｐｌｉｔが考えられる。これらは、Ｓｐｌｉｔ、Ｓｐｌｉｔ Ｆｏｒ Ｅａｃｈ、およびＳｐｌｉｔ Ｓｅｌｅｃｔ Ｒｅｃｅｉｖｅステートメント内で適用され、他の場所では使用できない。Ｅｘｉｔ Ｌｉｎｅステートメントは、Ｓｐｌｉｔ内の実行行を終了させることができる。Ｅｘｉｔ Ｓｐｌｉｔステートメントは、Ｓｐｌｉｔを抜けて、Ｓｐｌｉｔの他のすべての行を終了させることができる。

何らかの形のＳｐｌｉｔを終了する制御権の移転が他にあればそれらは、Ｅｘｉｔ Ｌｉｎｅの意味ではなく、Ｅｘｉｔ Ｓｐｌｉｔの意味を持ちうる。

サービス
図２を再び参照すると、次に、コントラクトは２１０で実装される。本発明によれば、サービス（例えば、図１のサービス１０８）は、コントラクトの実装を備える。サービスは、サービスのコントラクトの開始メッセージを受けとると、自動的にインスタンス化される。サービスがそのコントラクトを実装するために使用するコネクタは、自動的に初期化され、メッセージの送受信に暗黙のうちに使用することができ、したがって、「Ｐｒｉｍａｒｙ」と明示的に呼ぶことができる。説明されている態様によれば、サービスは、パラメータを持たず、したがって結果を返さない「Ｒｕｎ」という名前のインスタンスメソッドを持つことができ、このサービスをアクティブ化すると、Ｒｕｎを呼び出す。

サービスは、ＲｕｎｔｉｍｅＳｅｒｖｉｃｅから直接的にまたは間接的に派生するオーケストレーションクラスである。基本クラスが指定されていない場合、これは暗黙のうちにＲｕｎｔｉｍｅＳｅｒｖｉｃｅである。

再びすでに提示されているアラームクロック例を参照すると、上述のアラームクロックコントラクトを実装するサービスは、以下のように構成できることがわかる。

さらに、以下では、サービス例は、前の例のスヌーズアラームクロックコントラクトを実装するように構成されている。

次にサービスの文法および意味については、以下の通りである。

上記によれば、サービスは、１つのＩｍｐｌｅｍｅｎｔｓステートメントと任意のＭｅｓｓａｇｅステートメントの両方を持つことはできない。しかし、Ｉｍｐｌｅｍｅｎｔｓステートメントが存在する場合、１つあり、それは単一の型に名前を付けることができ、その型はコントラクトとすることができる。

サービスは、コントラクトを実装する暗黙の一次コネクタを備えることができる。実装されたコントラクトは、Ｉｍｐｌｅｍｅｎｔｓステートメントで名前を付けることができる。サービスがＩｍｐｌｅｍｅｎｔｓステートメントなしで宣言されている場合、そのサービスにおいて、その一次コネクタを通ることができるメッセージを宣言することができ、パターンはサービスのメソッドから派生される。つまり、サービスはどれも、コントラクトを実装するということである。

一次コネクタは、サービス内でＰｒｉｍａｒｙとして利用可能である。コネクタの式がＳｅｎｄまたはＲｅｃｅｉｖｅステートメントから省略された場合、コネクタは、暗黙のうちにＰｒｉｍａｒｙとすることができる。

サービスを呼び出すと、サービスの実装されたコントラクトとして分類されているコネクタの新しいインスタンスを返す。

本発明のより一般的な説明に入るが、ｎ層または一般的に分散環境におけるクライアントおよびサーバのことを話す場合、混乱を避けるために用語を十分厳密に定義することが重要である。例えば、ＶＢ環境では、「サービスクライアント」は、メッセージが送信されても開始されないオーケストレーションオブジェクトのことである。つまり、サービスクライアントは、他の何らかの方法で起動することができる。その一方で、「サービス」は、メッセージが送信されることによって作成されるオブジェクトである。「サービス」を起動する方法は他にないということは理解されるであろう。ある程度ゆるやかな概念として、「クライアント」は、サービスとの通信を開始する、サービスであろうとサービスクライアントであろうと、コードの断片のことである。

コントラクト
再び一般的にコントラクトについて言及すると、コントラクトはプロトコルおよびそのメッセージを指定するためにＯＯ言語（例えば、ＶＢ）で使用することができる。この説明では、以下に示すようなコントラクトインポートステートメント、メッセージ宣言ステートメント、および単一パターン定義ステートメントの３つの部分を重点的に取り上げる。

上記は、Ｓｔｒｉｎｇだけを受け渡す「Ｒｅｑｕｅｓｔ」と呼ばれるインバウンドメッセージの定義である。同様に、これもまたＳｔｒｉｎｇだけを受け渡す「Ｒｅｓｐｏｎｓｅ」と呼ばれるアウトバウンドメッセージが定義される。メッセージ自体は、名前であって、データの「塊」ではないことに注意されたい。むしろ、メッセージ自体は、そのメッセージの識別子であり、その点ではクラス名に類似している。データは、メッセージのパラメータとして定義することができる。

さらに、プロトコルが「セッション」で２つのメッセージ、つまりＲｅｑｕｅｓｔおよびＲｅｓｐｏｎｓｅのみを許容することも定義される。相互作用でのこれら２つのメッセージの方向は、それぞれのメッセージ宣言により暗示される。一方の人のインバウンドメッセージは、他方の人のアウトバウンドメッセージであることは理解されるであろう。本発明によれば、このパースペクティブは、コントラクトを実装するサービスのパースペクティブからのものである。

プロトコル上のそれぞれの相互作用は、対話、メッセージのやり取りを行う２者を伴い、それによって、互いの内部状態に影響を及ぼすか、または有用ないくつかの外部影響を有する。２者のそれぞれのそのような結合において、分かりやすくするため、両者を実装側と使用側とラベルを付けて明示する。

開示されている態様のＶＢオーケストレーションでは、これは、コントラクトパースペクティブと呼ばれる。コンパイラでは、インバウンドメッセージが実装側により送信されること、または使用側により受信されることを許さず、またアウトバウンドメッセージが実装側により受信されること、または使用側により送信されることも許さないことは理解されるであろう。

上記のコントラクトは、本質的に、同期メッセージ受け渡しメカニズムで許容している複雑さである、つまり一方のメッセージが一方向に出て、他方のメッセージが応答として戻ることが観察される。戻りデータ、またはプロシージャ呼び出しでパラメータがない場合、対応するメッセージは、それに応じて調整されるが、同期パターンで単一のインバウンドメッセージの後に単一のアウトバウンドメッセージに続く。以下で説明するように、プロトコルは、様々な多数の方法で定義することができ、ＶＢオーケストレーションを使用することにより、完全なプログラムでこの技術を容易に利用することができる。

本質的に、コントラクトを採用することにより、メッセージおよびパターンを宣言することが可能である。しかし、コントラクトは、膨大なレベルのセキュリティおよび堅牢さをプロトコルの実装に加えることができるが、それは、コンパイラを使ってコードがプロトコルに準拠していることをチェックすることができるからである。最低限、コントラクトの強制は実行時に行われ、多くの場合コンパイル時に行われる。

本発明によれば、コントラクトは、開示されている態様のＶＢオーケストレーションにおける基本的な言語追加機能のうちの１つである。以下に、コントラクト宣言に関係する詳細説明を続ける。

メッセージ宣言
図４を再び参照すると、上記の例では、コントラクトを宣言する方法を示している。特に、４０４で、メッセージを宣言する動作が例示されている。当業者であれば、これらは、本質的に、以下の制約条件を持つ、Ｓｕｂ宣言として類似の一般的規則を共有することを理解するであろう。

１．「ＢｙＶａｌ」であるすべてのパラメータ。「Ｏｐｔｉｏｎａｌ」、「ＢｙＲｅｆ」、または「ＰａｒａｍＡｒｒａｙ」宣言は、使用できない。

２．リモートで使用されるプロトコルについては、すべてのパラメータはシリアライズ可能である。

３．すべてのメッセージは指定された方向を持たなければならない。

４．メッセージはオーバーロードできない。

パターン宣言
次に４０６のパターン宣言を参照すると、パターン宣言の最も基本的な構成要素は、メッセージ参照である。上述の例では、パターン内で参照するときのみメッセージの名前に言及するだけでよいことは理解されるであろう。これは、その方向がよく知られているからである。さらに、いったん宣言されてしまうと、オーバーロードは許されず、方向およびパラメータの型を超えてメッセージに追加制約条件を課すことはできない。例えば、上記の例の文字列引数は、それが望ましい制約であれば、非ヌルでなければならないと指定する方法はないことに留意されたい。

パターンは、プロトコルの名前付き「状態」の集合、例えば、それに対する何らかの意味を持つ対話における異なる位置を定義することにより宣言される。パターンの第１の状態は、「Ｂｅｇｉｎ」と呼ぶことができる。

状態が定義されると、プロトコル状態の変化の仕方を示す状態「遷移」を追加することにより、プロトコルを完成させることができる。トリガおよびターゲットは、動作４０８および４１０に関して識別することができることは理解されるであろう。一態様では、そのような遷移は、メッセージによりトリガされる。他の態様では、それらのメッセージは、複数のメソッドまたはインポートされたコントラクトにより表すことができる。

例を以下に示す。

上述のように、「Ｒｅｑｕｅｓｔ Ｔｈｅｎ Ｒｅｓｐｏｎｓｅ」という句は、遷移トリガであり、「Ｅｎｄ」は遷移の終了状態である。遷移トリガは、言い換えると、複合トリガであってもよい。例えば、複合遷移トリガは、「Ｔｈｅｎ」を使用してメッセージの集合を順序付けるか、または「Ａｎｄ」を使用して順序付けなしでグループ化することにより使用することができる。その上、メッセージ名の間に「Ｏｒ」を使用してトリガの代替集合を指定することも可能である。遷移は、トリガのすべてのメッセージが送信されるか受信されるとすぐに発生する。

遷移終了状態は、複数の状態であってもよい。例えば、遷移を２つ以上のターゲット状態に「分割」することができ、これは、プロトコル「位置」が複数の名前付き状態により一度に定義されることを意味する。一態様では、ターゲット終了状態は、さらに、修正子「Ｉｍｍｅｄｉａｔｅ」を付けることもでき、これは、その状態への遷移は、完全なトリガが完了するのを待つのではなく特定のトリガと一致すると即座に発生することを意味する。これは、トリガがコントラクト名を含む場合に特に有用である。

すでに説明したように、パターンを持たないコントラクトは任意のメッセージ交換パターンを許容し、空のパターンを持つコントラクトはメッセージ交換を許さないことは理解されるであろう。

コントラクト拡張
さらに、本発明のいくつかの態様は、図４に例示されているように４１２で、コントラクト拡張を採用している。図５は、コントラクトの拡張を容易に行えるようにする方法を例示している。この方法によりコントラクトを拡張することで、旧バージョンと非対称的に互換性のある新しいバージョンを作成することができる。特に、コントラクトを拡張する場合に、５０２で、新しいメッセージを追加できる。その上、５０４で、新しい状態を既存のパターンに追加することができる。さらに、以下のようにいくつかの制約条件に応じて、５０６で新しいトリガを既存の状態に追加することができる。

１．曖昧性が入り込まない。

２．既存のトリガを変更できない。

３．既存の状態に追加されたトリガは「Ｉｎ」と「Ｏｕｔ」の両方のメッセージを第１の可能なメッセージとして持つことはできない、つまり、メッセージの方向は同じでなければならない。

４．トリガが既存の状態に追加され、トリガが「Ｉｎ」メッセージである場合、既存の状態に追加されたすべてのトリガは「Ｉｎ」メッセージのみを含む。

５．逆に、トリガが既存の状態に追加され、トリガが「Ｏｕｔ」メッセージである場合、既存の状態に追加されたすべてのトリガは「Ｏｕｔ」メッセージのみを含む。

これらの制約条件により、コントラクト再利用のモデルは、クラスに関する継承に類似している場合がある。一態様では（例えば、「Ｉｎ」メッセージのみが既存の状態に追加される）、新しいコントラクトはクライアント互換（ｃｌｉｅｎｔ−ｃｏｍｐａｔｉｂｌｅ）であり、他の場合には、サービス互換（ｓｅｒｖｉｃｅ−ｃｏｍｐａｔｉｂｌｅ）である。

クライアント互換コントラクトは、クライアントに知らせずに、サービスを旧いコントラクトから新しいコントラクトにアップグレードできることを意味する。つまり、旧いコントラクトを使用しているクライアントは、決して、新しい状態への遷移をトリガするメッセージを送信しないということである。その一方で、より新しいコントラクトを認識するクライアントは、サービスがその新しいコントラクトをサポートしている場合のみそのコントラクトを利用することができる。したがって、この関係は非対称互換であることは理解されるであろう。

その一方で、コントラクトがサービス互換である場合、クライアントは、新しいコントラクトを使用するようにアップグレードすることができ、旧いコントラクトまたは新しいコントラクトのいずれかをサポートするサービスとの対話を持ち続ける。

以下に、すでに提示されている要求／応答例の修正バージョンを使用した例を示す。

クライアント互換の例：

上のコード例に示されているように、クライアントのみが旧いコントラクトを認識している場合でも、新しいメッセージがまったく送信されない限り、コントラクトは交換可能であるため、新しいコントラクトをサポートするサービスに接続することができる。上に示されているように、サービスは、旧いコントラクトを使用するクライアントと新しい特徴を単純に利用しないだけのクライアントとの違いを区別することはできない。サービス互換の例：

ここで、サービスは、既存のコントラクトを超えるかどうかを決定することができる。したがって、アップグレードされたクライアントは、サービスが旧いコントラクトを使用するのか、それとも新しいコントラクトを使用するのかを見分けることはできない。拡張されたパターンでは、新しい情報のみ、つまり新しい状態、および既存の状態に対する新しいトリガがリストされることに注意されたい。これは、エラーの発生源を回避し、明確さが必要な場合は、旧いコントラクトパターンをコメントとして含めることができる。

コントラクトＡは、ホストされているコントラクトを追加し、メッセージを追加しないことにより、コントラクトＢを拡張することができることは理解されるであろう。この場合、ＡはＢと対称的互換である。コントラクトのホスティングについては、本明細書の後の方で詳述する。

コネクタ
コントラクトを使用することにより、それらを参照するものを宣言することができる。例示されている態様によれば、他のコードとの通信のためにＶＢオーケストレーションベースのコードで使用するオブジェクトは、「Ｃｏｎｎｅｃｔｏｒ」と呼ばれる。

型に関する限り、Ｃｏｎｎｅｃｔｏｒはコントラクト参照型である。Ｃｏｎｎｅｃｔｏｒには風変わりなところがある。例えば、Ｃｏｎｎｅｃｔｏｒは、その型の一部である明確に定義されたコントラクトパースペクティブを持つ。いずれも、コントラクトの実装側、または使用側を表す。実装側コネクタを使用側コネクタに、またその逆にも、割り当てることはできない。これらの規則に従うと、コネクタをどのように作成するか、それが実装側であるか使用側であるかをどのように定義するのかについて不思議に思うのももっともである。

コネクタは、ランタイム（例えば、ＶＢランタイム）により定義することができるコネクタファクトリを使用して作成することができる。ほとんどのコネクタファクトリは、サービスＵＲＬまたは他のコネクタから作成される。

ＵＲＩは、ここでは、サービス参照と呼ばれる。これは、コンフィギュレーションファイル内に保持される何らかのよく知られているＵＲＩとすることができ、あるいは他の何らかのブローカサービスにより実行時にまとめることも可能である。例えば、最もよい取引の場所を決定し、その卸売業者へのＵＲＩを要求者側に送り返す卸売業者入札サービスが考えられる。

コネクタファクトリが用意されると、コネクタファクトリクラス内に組み込まれる対話演算子を使用してＣｏｎｎｅｃｔｏｒを簡単に作成できる。

このステートメント例では、コネクタファクトリによりアドレッシングされ、その一次コネクタ上に「ＣｔＲｅｑｕｅｓｔＲｅｓｐｏｎｓｅ」を実装することができるサービスを参照するパースペクティブ使用コネクタを作成する。このようなコネクタファクトリの使用により、使用側コネクタを生成することができる。

コネクタファクトリは、以下のように、実装パースペクティブのコネクタに直接バインドすることもできることは理解されるであろう。

この態様は、両方の側が同じアプリケーションドメインにあり、分離される必要がないことがよく知られている状況では有用な場合がある。分散されないようにするコードをアプリケーションに追加する必要があるので、一般的には、推奨されないが、特別な場合のパフォーマンスに関しては有用である。前の例は、パースペクティブ使用コネクタである。

他方で、実装側コネクタは、２つの点で異なるように宣言することができる。特に、コネクタ名は、キーワード「Ｉｍｐｌｅｍｅｎｔｓ」で修正することができ、また初期化子の式は、以下のように引数なしのコントラクト呼び出しでなければならない。

パースペクティブ使用コネクタが初期化されると、これは、対応する実装側コネクタにバインドされるが、実装側コネクタは、バインディングを開始せず、したがって、サービス参照をパラメータとしては必要としない。そのため、その結果得られるコネクタは、作成された後バインド解除され、何らかの使用側コネクタが新しいコネクタにバインドされるまでメッセージの送信には使用できない。

サービスは、すでに定義されているように、「一次」コネクタと呼ばれる暗黙の実装側コネクタを持つことに注意されたい。これは、サービスが起動される前にランタイムアルゴリズムにより作成され、「Ｐｒｉｍａｒｙ」フィールドとしてスケジュールに利用することができる。メッセージの送信および受信の際に、一次コネクタは、参照されているコネクタがなければ暗黙のうちに含まれるため、実際に一次コネクタを明示的に参照するコードを見ることは滅多にない。以下で詳しく説明するが、一次コネクタは、多重化のためサービス参照を作成する場合に使用することができる。

コネクタは、参照型の変数が宣言できる場合に必ず宣言することができる。例えば、コネクタは、ＶＢモジュールなどでは、ローカル、パラメータ、および／またはフィールドとして宣言することができる。これらは、オブジェクト参照と同様に、参照により受け渡され、他の変数にコピーされるようにできる。本発明の一態様によれば、コネクタのパースペクティブはいっさい変更できない。さらに、コンパイラでは、強固な分類によりこれを保証することができる。したがって、この態様では、コネクタ、または一般的にはサービスを定義するか、または使用するどのようなソースファイルにおいても「Ｏｐｔｉｏｎ Ｓｔｒｉｃｔ Ｏｆｆ」を使用することは許可できない。

セッション
本発明のオーケストレーションに関する新規性のある一態様では、スレッド、プロセス、またはスケーラブルなマルチスレッドアプリケーションに関する典型的な課題である他の態様に関する問題を軽減することができる。適切な取り扱いと予見とにより、スレッドおよびプロセスの分離は、アプリケーションの開発問題ではなく、アプリケーションの分散および管理問題となりうる。

しかし、非分散アプリケーションに関して通常は問題とならないが、ＶＢオーケストレーションには本質的である概念の１つに、セッションという概念がある。

以下の例は、理解を助けるために掲載する。インターネットを使用して金融機関サイトでショッピングまたはアクセスを行い、口座情報または支払い請求書にアクセスしたことのあるユーザは、分散アプリケーションの意味でのセッションに慣れていることであろう。特に、電子商取引サイトがアクセスされ、商品がショッピングカートに追加されたり、「Ｍｙ Ａｃｃｏｕｎｔ」ページがアクセスされたときに、Ｗｅｂサイトソフトウェアは、いくつかのオブジェクトをメモリ内に割り当てて、訪問者およびログインしている間に実行された操作内容を記憶しておかなければならない。このデータは、一時データであり、通常データベースに格納されている長期間にわたって存続する注文情報または口座情報と異なる場合がある。

この一時データの寿命が、セッションと呼ばれる。非分散アプリケーションでは、データは、ゴミになるまでメモリ内に保持しておくことができる。他方、この状況は、分散アプリケーションではまったく異なる。分散アプリケーションに関しては、２つの主要な問題がある。まず、アプリケーションノードにまたがったオブジェクト参照は存在しない。第２に、セッションがいつ終了されたかを通知されることに頼れない。

第１のポイントは、オブジェクトを片づけるためにガベージコレクションに依存していたとすると、すべての一時データはたちまちゴミのように見えて、除去されることになることを意味する。すると、アプリケーションノードは、訪問者が以前そこにいたことについてすべて忘れてしまうので、これは面倒なことであろう。したがって、そのようなソフトウェアは、セッション固有のデータ構造を、通常はある種の大域的コレクションの中に割り当てることができ、同じセッションにおいて新しい要求が来たときにその構造を取り出す。

次に、第２のポイントとして、セッションがいつ終了したかがわからないと、セッションデータは、決して、ゴミにはなることがないということであり、大域的コレクションはメモリリーク問題が生じるということについて有名である。

これらの問題に対処するために、セッションには通常時限が定められる。タイマーは、セッションが最初に作成されるときにセットされ、メッセージまたは要求が入来する毎にリセットされるようにできる。Ｗｅｂユーザのログアウトなどでセッションが終了したと判断できる場合、その時点でデータが除去される。それが判断できない場合、タイマーが停止したときに、セッションデータが大域的ハッシュテーブルから除去され、データはゴミになる。

妥当なタイムアウト間隔の決定は完全にアプリケーションに依存することは理解されるであろう。Ｗｅｂサイトでは、通常、タイムアウト間隔を１０から３０分の間に設定するが、それが普遍的に有効な設定であるとは限らない。一部のアプリケーションで２、３秒が適切であるが、他のアプリケーションでは数時間が適切な場合もある。

ＶＢオーケストレーションの例によれば、これはすべて自動的にサポートされる。一態様では、既定のタイムアウト値は１０分である。１０分が適切でない場合は、Ａｐｐ．ｃｏｎｆｉｇファイルでタイムアウトを再構成するとよい。この再構成については、以下の「Ａｐｐ．ｃｏｎｆｉｇ設定」で詳細に説明される。

スケジュールが最初に開始すると、それがサービスであろうと、サービスクライアントであろうと、そのセッションは他の何かが発生する前に作成することができる。セッションは、実際にはサービスクラスのインスタンスである。しかし、これは、クライアントが参照に使用する大域的に一意の識別子を割り当てられる。したがって、セッションは、サービスインスタンスとも呼ばれる。後者は、メモリ内の特定のオブジェクトを参照していることを示す必要がある場合に特に有用であるが、前者は、分散アプリケーションパースペクティブから見たい場合に特に有用であることは理解されるであろう。

サービスインスタンスは、通常、それに関連付けられた多数のコネクタを持つ。最初に、複数のコネクタをそれらを作成したスケジュールにのみ結合できるが、メッセージを他のスケジュールに送信するために、コネクタを、常に同じコントラクトであるが反対のパースペクティブの他のコネクタにバインドすることができる。バインドされた後、コネクタは再バインドすることはできない。

上記の例を参照すると、作成された第１の３つのコネクタは、サービスまたはコントラクト呼び出しが戻ったときにすべてバインドされる。第４の場合にはそうではない。これは、コネクタは他の何らかのコネクタがバインドに使用するサービス参照を作成するためにしか使用できないからである。それが発生すると、通信が開始することができる。

上記のＷｅｂサービス例では、セッションを処理するソフトウェアがセッション自体の外部にセッション固有のオブジェクトへの参照を格納しないことが重要である。そのようにすることは、セッションが除去される場合に、それらのオブジェクトがゴミにならず、セッションの主要な目的の１つである、分散アプリケーションでのオブジェクトの寿命を制御することが違反になることを意味する。

アプリケーション全体が最初は同じアプリケーション領域内にある場合であっても、ＶＢオーケストレーションをプログラムする際にこれが行われることが等しく重要である。セッション中に作成された参照がスケジュールの外部に格納できるようにしても、アプリケーションがスケーリングするようにするかしないかを最終的に決定する大域的システム資源の自動管理を行うことはできない。

この規則は単純である−データ状態への参照を、サービスまたはスケジュールの本体内で宣言されている参照内に格納するだけである。つまり、どのような種類であっても大域的変数またはコレクションには格納しないということである。この規則は、従うのは簡単であり、非常に妥当である。その上、この規則は、その性質上他のソフトウェアの基本的な再入規則に非常によく似ている。例えば、大域的状態を避けて、代わりに、常にデータをパラメータとして伝える。

データがアプリケーションレベルのデータとして属している、つまりデータがアプリケーション領域内の複数のセッション間で共有される場合に限り、セッションの外部で宣言し、格納すべきである。そのときでさえ、これは、再考を要するアプリケーションの設計に関して何かあるのではないかという危険を知らせる赤旗として使用すべきである。

スケジュール（オーケストレーション）
そこで図６を参照すると、オーケストレーションコンポーネントの一般的なブロック図が示されている。図に示されているように、オーケストレーションコンポーネントは、実装またはスケジュールコンポーネント６０２およびコンパイラコンポーネント６０４を含むように例示することができる。本発明によれば、スケジュールコンポーネント６０２は、ソースコードのマニフェストを持たないが、それでも、以下のセクションを理解するうえで欠かせない実行時概念である。簡単にいうと、スケジュールコンポーネント６０２は、メッセージ指向コードが複数のメッセージを並列方式で待機できるようにするために使用される実行時オブジェクトである。

抽象的にいうと、ＶＢ環境例に関して、すべてのメソッドは、スケジュールが完了したときにメソッドが戻るために使用されるスケジュールを持つ。具体的にいうと、下記のようにメッセージ受信または待機ステートメントを含むメソッドのみがスケジュールを必要とするということである。ＶＢコンパイラを使用すると、必ず最も効率のよい実装がスケジュールフリーの実装で使用される。

このような実行時定義が与えられた場合、スケジュールは、複数のメソッドに分割されるか、または単一のメソッド内に含まれる、メッセージ関係コードの本体としてをおおまかに説明することができる。後者の場合は、既定であり、例えば、メッセージングコードを持つそれぞれのメソッドはそれ自体のスケジュールを定義する。

他方で、前者は、オーケストレーションクラスを使用して実装され、これらは、クラスＳｙｓｔｅｍ．Ｏｒｃｈｅｓｔｒａｔｉｏｎ．ＲｕｎｔｉｍｅＯｒｃｈｅｓｔｒａｔｉｏｎから直接的にまたは間接的に発生されるすべてのクラスである。オーケストレーションクラスは、１つのインスタンス上ですべてのメソッドに対する単一のスケジュールを共有する。スケジュールは、インスタンスメソッドへの外部（例えば、「Ｍｅ」を使用しない）呼び出しにより起動することができ、オリジナルメソッドが戻るまでその同じインスタンス上ですべての内部メソッド呼び出しにまたがって拡張する。

オーケストレーションクラスは、必要な基本クラスを持つことを除きあらゆる点で通常のクラスに類似しており、共有メソッドまたはプロパティを宣言することはできない。

サービス
さらに、本発明によれば、サービスは、クラスＳｙｓｔｅｍ．Ｏｒｃｈｅｓｔｒａｔｉｏｎ．ＲｕｎｔｉｍｅＳｅｒｖｉｃｅから（例えば、他のサービスから）直接的にまたは間接的に派生することができるオーケストレーションクラスを参照する。そのうえ、サービスはランタイムにより自動インスタンス化される。

状況を設定するために、以下の説明では、１）サービスの一次コネクタが実装するコントラクトおよび２）その起動のメソッドというサービスに関係する２つの概念を明確にする。

第１に、コントラクトは、１）Ｉｍｐｌｅｍｅｎｔｓステートメントで名前による指定、または２）スケジュール本体からの派生の２つの方法で定義することができる。前者の例を以下に示す。

ここで、コントラクトは、すでに説明されている要求／応答である。例えば、サービスは、株価表示器記号を文字列として受信し、最後の売買での価格の文字列表現で応答する。もちろん、応答に対し異なるデータ型を使用することもよい考えであろうが、ここで重要な点は、適切なコントラクトをどのように設計するかではなく、サービスでコントラクトをどのように使用するかである。

サービスは、使用側コネクタをサービス起動直前に作成された実装側コネクタにバインドするサービスにメッセージを送信することによりサービスを呼び出すクライアントにより常に開始される。

コントラクトおよびスケジュールを指定し、多数のサーバ上の多数のプロセスで利用可能にできる、サービス定義、およびそのサービスの特定のセッションを表すサービスインスタンスを別にすることが重要である。

サービスは、型定義であり、サービスインスタンスはオブジェクトであることは理解されるであろう。しかし、実際には決してサービスインスタンスへの参照を持つ（または使用することができる）わけではないので、この関係を見ることはときに困難である。サービスは、コネクタを介してのみ相互作用する。メッセージングがサービスと相互作用する単一の手段である場合に限り、拡張可能なアプリケーション設計をシステムでサポートするために必要な方法で再配置または複製することができる。したがって、サービスは、「Ｎｅｗ」式を使用してコンストラクタを定義すること、または割り当てることはできない。

サービスが実装するコントラクトを指定する第２の方法では、コンパイラを使用してスケジュールに含まれるコードからそのコントラクトを派生させる。ここで、コンパイラは、コードを解釈するためにコードを切り分ける。つまり、コントラクト定義を書かなくてもよいということである。このメカニズムを使用するために、一次コネクタ上で使用されるメッセージを宣言するだけである。そのようなサービスのコントラクトを使用してコネクタを作成できるようにするために、そのサービスに対し派生するコントラクトには、「＜ｓｅｒｖｉｃｅ−ｎａｍｅ＞．Ｃｏｎｔｒａｃｔ」という予測可能な名前を付けることができる。

しかし、すべて便宜をはかるためにコントラクトを派生すると、抽象性を欠くことになる。

理解されるであろうが、コントラクトは、プロトコルで何が続いているかを正確に説明するために使用される。派生コントラクトは、常に正しい（サービス実装がそうである限り）が、可読性または使い勝手を保証するわけではない。これは、サービスの内部構造を直接反映し、クライアントをまとめようとするプログラマにとっては理解しにくいことがある。また、コンパイラ側で処理するのが難しく、しかもその結果非常にリベラルなものとなる状況もある。

サービスは、一度起動すると、同じアプリケーション領域にあろうとなかろうと、呼び出し側コードと並列に実行することができる。同時実行性について述べることは何もなく、単に並列処理であるというだけであることに注意されたい。この２つは、メッセージングを通じてのみ同期しデータを共有している限り、互いの制御の流れとは無関係に書いて実装することができる。異なるサービスインスタンスが同時実行される（例えば、別のスレッドまたはプロセスで）ことは必要ないか、または実行されないことに注意されたい。

メッセージング
前の説明に鑑みて、次に、クライアントサイドまたはサーバサイドのいずれかにプロトコルを実装するコード本体として定義することができるスケジュールの概念に注目することにする。スケジュールの見方については、１）スケジュールを、メッセージを送信し、メッセージをポーリングする手順として見ること、または２）手順のとは根本的に異なる、実行モデルを詳細に見ることの２通りがある。

本明細書ですでに説明したように、プロトコルハンドラの単純な実装は、何らかのメッセージ送信ＡＰＩを通じてメッセージを送信し、他のＡＰＩを使用してメッセージをポーリングするメソッドとしてであろう。それぞれのサービスインスタンスは、この従来のモデルでは、自実行スレッドを持たなければならず、これは拡張可能でもないし、環境の実行時のチューニングを許すわけでもない状況である。従来、それぞれのサービスインスタンスは、別々のスレッドを必要とし、それだけのことである。オペレーティングシステム（ＯＳ）では、どのスレッドがいつ実行するかを決定し、アプリケーションオペレータ側で利用できるチューニングコントロールはない。

この従来のアプローチの最初の問題は、必要とする割り当て済みスレッドが多すぎること、ＯＳ（例えば、カーネル）資源の負担大、さらにメモリフットプリントの著しい増大などである。サービスインスタンスが出入りする毎に、ＯＳスレッドの作成と破壊を繰り返さなければならず、負担が大きく、しかも、一度に限られた数のスレッドをアクティブに保持できる（例えば、１つのサービスインスタンスに１つ必要）「スロットル」がない。

さらに問題を複雑にしているのは、バイナリコード内の低レベル位置が対話状態を含むものであるという点である。したがって、サービスインスタンスを他のマシンに移動したり、ただ単に対話状態を検査することは困難であろう。

そこで、本発明のシステムおよび方法では、プロトコルハンドラ（例えば、サービス）の妥当な実装に対する２つの基本的な態様がある。第１に、プロトコルハンドラの実行環境に関する仮定があり得ないということである。ハンドラ毎に１つのスレッドがありうるか、または複数のスレッドを重なり合う寿命を持つものであっても複数のサービスインスタンス間で共有できる。第２に、対話状態は、コードではなくデータで表現することができるということである。

２番目に述べたことは、データでの実装というよりもむしろ対話状態の流れの宣言に関して前に述べたことに反していると受け取られるおそれがあるが、開発者は対話の流れを宣言的に見ることができるべきであるというのが意図であった。それでもランタイムモデルは、対話状態がデータで表現されるモデルである必要がある。つまり、「単純（ナイーヴ）」モデルはプロトコルハンドラのソース（例えば、プログラマ）の視点では適切であるが、ランタイムモデルは非常に異なる場合があることは理解されるであろう。当業者であれば、このギャップに橋渡しすることで、ＶＢオーケストレーションが生産性および可読性の高レベルの向上をなんとか達成することを理解するであろう。

次に、スケジュールコードは、ソーススケジュールのすべての論理を含む別のクラスにコンパイルされるが、異なる同時実行モデルをサポートするように再配置される。スケジュールを起動すると、コードは、休止イベント（別名、「降伏点（ｙｉｅｌｄ ｐｏｉｎｔ）」）が発生するまで実行される。

休止イベントが発生すると、スケジュールは実行を停止し、それを起動したスケジューリングランタイムに、または最後に再開したイベントのサイトに制御を返す。現在のところ、唯一の再開イベントは、メッセージ到着、メッセージタイムアウト、およびウエイトステートメントの完了である。

スケジュールを一時停止した後、そのスレッドは何か好ましいことに使用するためにランタイムに戻されるか、または破壊されるが、すべて基盤のランタイムのスレッドモデルに依存する。より高度なホスティングフレームワークは、そのすべての活動に対しスレッドプールに依存する可能性があるが、より基本的なホスティングフレームワークでは必要になる毎に新しいスレッドを作成する場合のあることは理解されるであろう。スケジュールのコードは、いずれにせよ，何も仮定を置くことはありえない。非サービスコンテキストでの第１の休止イベント（例えば、メソッドの呼び出し）では、使用されるスレッドをスケジュールが完了するまでブロックさせることができることに注意されたい。

メッセージが届き、特定のサービスインスタンスに経路指定され、それを待つ休止中の受信があることが判明した場合、ランタイムによりＲｅｃｅｉｖｅステートメントの後の本体を保持するメソッドを呼び出すことができる。この呼び出し点は、次に、新しい再開部位（別名、「継続点（ｃｏｎｔｉｎｕａｔｉｏｎ ｐｏｉｎｔ）」）となり、この呼び出しは、スケジュールが再び休止するまで戻らない。

つまり、スケジュールは、データとして公開される対話状態を持つコールバックとして実装されるが、コードはそれでも、ポーリングコードとして出現し、その場合、その対話の流れは、ＶＢ．Ｎｅｔの例におけるおなじみの言語要素（ｌａｎｇｕａｇｅ ｃｏｎｓｔｒｕｃｔｓ）を使用して宣言される。

本発明によれば、スケジュール内のメッセージ処理および並列処理のため適切な言語追加を行うことができるが、ほとんどの場合、スケジュールコードは、通常のＶＢステートメント、つまり、ループおよびｉｆステートメントから例外ブロックおよび変数宣言にいたるまでのすべてからなる。

メッセージの送受信
プロトコルコード内のほとんどの基本的なオペレーションは、クライアントサイドであろうとサーバサイドであろうと、接続の一方の側でメッセージを送信し、他方の側でそれを受信することである。

はじめからのオペレーションでは、メッセージは、受信する前に、送信しなければならず、そのようにする構文は非常に簡単である。

要求／応答コントラクトについては、すでに説明されている。Ｓｅｎｄステートメントは、ある種のコネクタを持つことができる。コネクタは、スケジュールがサービスであり、Ｓｅｎｄが一次コネクタ上で動作する場合に暗黙のコネクタである。この例では、クライアントは、最初にサービスに接続する。

前に述べたサービスクライアントの呼び出しの場合と異なり、Ｓｅｎｄステートメントは値を返さないことに注意されたい。非同期メッセージ受け渡しの核心は、すべてのデータ受け渡しを明示的にすることであり、したがって、双方向通信にはそれぞれの側で送信と受信を必要とすることは理解されるであろう。

サービス側、つまり、実装側では、メッセージは以下のように処理されるであろう。

このステートメントではコネクタ参照がないことに注意されたい。サービスは、その一次コネクタ上でメッセージを受信する。応答のため、サービスは、コントラクト定義に従って、その結果を文字列値として送り返す。

株価情報サービスはまったく信頼できず、そのデータ収集戦略においてはかなり静的であるという事実を別にすれば、ただそれだけのことである。そこで、メッセージは他方の側で受信されなければならない。例示されているように、メッセージパラメータがＲｅｃｅｉｖｅステートメントの外に出る場合の変数が宣言されている。

上記の例は、完全なスケジュールベースのアプリケーションの表現である。以下では、コード全体が１箇所にある。

「Ｏｐｔｉｏｎ Ｓｔｒｉｃｔ Ｏｎ」（例えば、ＶＢオーケストレーションでは、現在、厳密モードコンパイルを必要としている）などのステートメントをファイルの先頭に追加するか、または何らかのａｐｐコードをサービスクライアントに追加することにより、他にコンフィギュレーションの設定を行わずにコードを実行することができることは理解されるであろう。このコードは、「ｓａｍｐｌｅ−１」ディレクトリの下にある。

これらのステートメントの実行モデルによれば、Ｒｅｃｅｉｖｅステートメントが実行され、すでに利用可能なそれと一致するメッセージがない場合、スケジュールは休止する（例えば、それが使用しているスレッドを放棄する）。メッセージが利用可能であれば、休止しないが、実行は次の行へ即座に継続する。Ｓｅｎｄステートメントは決して休止しない−メッセージが基礎のシステムによって受け付けられるとすぐに、そのステートメントは終了する。

メッセージがスケジュールに届くと、ランタイム側でそのスケジュールがその種のメッセージを待つのを休止したことを検出した場合、スケジュールは、通常、ランタイムが使用しているのと同じスレッド上で即座に再開される。

これではコントラクト言語で表現できる強力なすべてのプロトコルに対し十分でないと誤って信じる可能性がある。例えば、様々なメッセージが一度に入って来るのをシステムが待つ状況、例えば、同じ状態からの２つの遷移、または複数の順序付けされていないメッセージによるトリガ、または分割されたコントラクト定義である。

これらの他の遷移状況を取り扱うために、ＶＢオーケストレーションでは、一組のメッセージのうちから１つのメッセージの受信を処理する「ｓｅｌｅｃｔ」ステートメントの一変種を定義する。

このコード例では、２つのメッセージ「Ｒｅｑｕｅｓｔ」および「ＩｔｓＯｖｅｒ１」のうちの１つだけがこのステートメントで受信される。しかし、以下に示されているように、ＡおよびＢ（任意の順序で）またはＣだけを受信することが望ましい場合がある。

以下のコードは、この目標を達成することができる。

特に、Ｒｅｃｅｉｖｅステートメントを同じ行、例えば、「ｓｅｌｅｃｔ Ｒｅｃｅｉｖｅ」内の同じ「Ｃａｓｅ」ステートメント内に置くことにより、何らかの未定義の順序でメッセージのすべてを受信してから次へ進むように指定することができる。すべての入来メッセージの要求条件を最初に満たすケースは、最終的に選択されるケースである。Ｓｅｌｅｃｔステートメントに関する限り、ＣがＡの後、ただしＢの前に入る場合、Ａは利用可能にされ将来の他の時点に受信される。

次にＣｔＲｅｐｅａｔｅｄＲｅｑｕｅｓｔＲｅｓｐｏｎｓｅコントラクトの実装に移る。

ここで注目すべき態様がいくつかある。第１に、実行中の「ｓｅｌｅｃｔ Ｒｅｃｅｉｖｅ」ステートメントが例示されているが、これは、さらに、通常の「Ｄｏ」ループステートメント内にネストされる。スケジュールの包含に関する制約はごくわずかであり（例えば、以下の「言語の制約」で説明されている）、ループはそれらの間にない。サービスクライアントでは、送信／受信を中心としてループが使用され、そこで、システムは、株価について何度も尋ねることを許されているユーザと相互作用する。このコードは、ＤＶＳサンプル間で、Ｓａｍｐｌｅ−２として使用することができる。

この実施例では、サービスクライアントは一か八かで実行している。例えば、クライアントからまる１分間何も届かなかった後、適切であると感じられたときにサービスが「ＩｔｓＯｖｅｒ２（）」メッセージを送信すると仮定する。ここで、サービスクライアントは、さらに、「ｓｅｌｅｃｔ Ｒｅｃｅｉｖｅ」ステートメントを使用して、この可能性に対応することも可能である。

サービスは、まる１分間、メッセージがなかったことを検出することができるであろう。例えば、サービスは、これがＩｔｓＯｖｅｒｌメッセージを送信せずにクライアントが消えてしまったという好ましくないサインであると決定することも可能であろう。このような状況を取り扱う何らかの手段が必要である。セッションタイムアウトは、上述のように有用であるが、多くの場合、強烈すぎる。

むしろ、タイムアウト間隔を「ｓｅｌｅｃｔ Ｒｅｃｅｉｖｅ」ステートメントに設定することが可能であり、メッセージが届かない場合の状況をより精密に制御する。

この間隔の型はＳｙｓｔｅｍ．ＴｉｍｅＳｐａｎとすることができる。上記の「ＦｒｏｍＭｉｎｕｔｅｓ」メソッド呼び出しは、その型に対する共有メソッドの１つであり、これによりＴｉｍｅＳｐａｎを特定の時間単位（例えば、秒、分、時）から構成することができる。Ｓｙｓｔｅｍ．ＴｉｍｅＳｐａｎの詳細については、．ＮＥＴフレームワークのドキュメンテーションを参照されたい。

「ｓｅｌｅｃｔ Ｒｅｃｅｉｖｅ」ステートメントの定義では、ＴｉｍｅＳｐａｎが０の場合、すでに到着していて待機中のメッセージから分岐条件が直ちに満たされ得なければタイムアウト分岐が選択される。つまり、Ｓｅｌｅｃｔ Ｒｅｃｅｉｖｅステートメントが休止しないようにすることが１つの手段となっている。これにより、利用可能であれば即座に処理されなければならない何らかのメッセージがないかスケジュール側で素早くチェックするようにでき、利用可能でなければスケジュールで実行するのがより適切なことがある。

上記の例では、セッションにただタイムアウトさせ、サービスインスタンスに消えてもらうだけでなく、むしろ、「ＩｔｓＯｖｅｒ２」メッセージをクライアントに送信し、クライアントに通知する機会があったことに注意していただきたいが、これは遅いユーザを待つ際に十分うまく機能する可能性がある。これは、よい「サービスシチズン（ｓｅｒｖｉｃｅ ｃｉｔｉｚｅｎ）」であることの一部である（例えば、消え去る（ｇｏ ａｗａｙ）ことをパートナーに通知する）。

分割行
「ｓｅｌｅｃｔ Ｒｅｃｅｉｖｅ」は単一状態遷移をトリガする代替および順序付けなしのメッセージグループをサポートするのに十分であったが、コントラクト内での分割をサポートする場合には不便である。この実施例では、コントラクトパターンは以下のようであることを仮定する。

受信側では、これは次のようにコーディングすることが可能である。

どのメッセージがすでに受信されている（したがって、再び参照すべきでない）かを追跡するため、このブックキーピングをすべてどのように完了しなければならないかに注意されたい。ＶＢオーケストレーション例では、このタイプの状況を取り扱う。例えば、以下のようになる。

ここには、どのような形であれブックキーピングコードはない。つまり、それぞれのメッセージは、他のメッセージとは独立に処理されることができるということである。

「Ｓｐｌｉｔ」ステートメントにより、ＶＢオーケストレーションは並列処理が行われ、しかも、同時実行性の複雑さを気にかける必要はない。上記のステートメントの意味は、分割行と呼ばれる、「分割」内のその３つのネストされているブロックは、互いに無関係に、例えば、並列に実行できるということである。

しかし、同時には実行されず、この管理はすでに説明されている休止（ｐａｕｓｅ）および再開プロセスを通じて処理される。分割行は、スケジュール内の他のすべての行が休止されるまで再開することはできない。

「分割」が実行されると、その分割行はすべて最初に中止される、その後、分割行は宣言の順序で再開される。これは、最初の分割行が休止しない限り、それが実行中のスケジュール内の唯一の分割行であることを意味する。つまり、分割行の同期は暗黙の同期であり、休止を通じて制御される。オブジェクトをロックするか、または分割行の間にバッファを入れるかについて悩む必要はない。むしろ、休止イベントの間で、現在の分割行は実行中の唯一の分割行であることは理解されるであろう。

実際、どのような形態であろうと自スレッド管理をスケジュールの中に導入することは、絶対に避けることができる。導入すると、本発明によるスケジュールの基盤として使用されるモデルが弱体化することになる。

次に、分割行を使用して上の株価情報繰り返しクライアントを実装する方法を説明する態様に進むことにする。

第１の分割行は、すでに説明されている実装と同一であることに注意されたい。行われるのは、「Ｅｘｉｔ Ｓｐｌｉｔ」が追加されることだけであることに注意されたい。これは、囲む「分割」ステートメントのすべての分割行を終了する一般的な「Ｅｘｉｔ」ステートメントのもう１つの変種である。第２の分割行は、決して届くことのない「ＩｔｓＯｖｅｒ２」メッセージを待つ。待たなければ、第１の行はステートメントを終了する。

オーケストレーションクラス
再び通常スケジュールとオーケストレーションクラス内に現れるスケジュールとの区別に戻ると、このクラスが存在する場合以下のようになる。

次のように分けることも可能である。

問題は、それぞれのメソッドが自スケジュールを持つため、「ＧｅｔＳｉｎｇｌｅ」呼び出しが、完了するまでブロックする点である。つまり、第１の分割行の内部で、その呼び出しは、応答メッセージを待っている間出力せず、第２の行は、実行に取りかからない。本質的に、長時間の停止状態（ｓｔａｒｖｅｄ）になる。「ＧｅｔＳｉｎｇｌｅ」の内部のＲｅｃｅｉｖｅステートメントが第２の行の中のステートメントで調整できれば、この問題は緩和できるであろう。それはちょうど、オーケストレーションクラスが遂行するものである。

クラス宣言を単純に以下のものに変更することにより

所望の挙動が得られる。つまり、ＧｅｔＳｉｎｇｌｅ内のＲｅｃｅｉｖｅステートメントが出力することは、分割行が出力し、第２の行が実行可能であることを意味する。

待機
スケジュール内の他の基本オペレーションは設定された期間の間待機することである。その時間の大部分を遅延に費やす長時間実行サービスのクラス全体がある（一般に「ぐずぐず先へ延ばす人（ｐｒｏｃｒａｓｔｉｎａｔｏｒ）」パターンと呼ばれる）。これらは、通常、コマンド（例えば、シャットダウン、モニタ追加など）の到着を監視し、それと同時に、ハートビート信号またはハートビートポーリング要求を他のサービスに送信することができる監視サービスであることが多い。そこでこれらの概念を参照して、他の理由もなく、共通の用語を定めることにする。

長期間実行することが予想される何らかのサービス／サービスのクラスを設計する場合、通常、サービスがまだ利用可能かどうかを他のサービスが自動的に判別し、積極的にそれを実行できるようにするある種のインターフェースを設計しなければならない。アプローチの１つは、サービスにアクセスするのが困難なすべてのクライアントに何らかの中央サービスに情報を送信させることであるが、それだと、クライアントは、使用事例を設計に追加することにより必要以上に複雑になり、使用事例はクライアントの元の目的に関係しない。

むしろ、ある頻度で監視サービスに送信されるメッセージである、ハートビートの受信を待機することにより、第１のサービスが利用可能かどうかを追跡する監視サービスが作成される。

通常の設計では、監視サービスは、監視されるサービスにそのハートビートを１回送信するか、またはＮ秒おきに送信を開始するよう要求するか、またはハートビートの送信をどれだけの頻度で準備するかをモニタに通知することができる。監視サービスは、その後、一定時間待機し、ｓｉｎｇｌｅ−ｓｈｏｔ−ｈｅａｒｔ−ｂｅａｔ要求を送信するループを使用するか、または定期的にハートビートを送信するように監視されるサービスに要求することができる。

後者の状況では、監視サービスは、「ｓｅｌｅｃｔ Ｒｅｃｅｉｖｅ」を使用し、タイムアウト間隔をａｇｒｅｅｄ−ｕｐｏｎ間隔よりも少しだけ長い何らかの値に設定する。ハートビートが届いた場合は、すべて良好であるが、ステートメントがタイムアウトになった場合、それは、何かよくないことが進行中であることを示しており、監視サービスはある形態のアラームを送出することが可能である。

より高度な実装は、ハートビートメッセージ上に他の情報を抱き合わせで載せて（ｐｉｇｇｙ−ｂａｃｋ）、オペレータが長時間実行サービスに関する統計量を取得できることが理解されるであろう。

Ｗａｉｔがオーケストレーションのステートメントとして明示的にサポートされていなかった場合、一定時間の遅延を導入すると、アプリケーションの拡張性に対し破滅的結果をもたらす可能性がある。．ＮＥＴフレームワーク内のＡＰＩである、Ｔｈｒｅａｄ．Ｓｌｅｅｐ（）に依存しなければならない場合があるが、ホスト環境のランタイムにより同時実行性を管理することを要求する、サービス実行モデルには完全に不適切である。Ｔｈｒｅａｄ．Ｓｌｅｅｐ（）を呼び出すと、ウエイトの持続期間中に現在のスレッドを結合する。Ｗａｉｔを呼び出すことをループするサービスについては、これは無期限とすることができる。

つまり、そのようなサービスでは、スレッドをすべてそれ自身に割り当てることになる。これはほとんどの期間未使用状態のままであるスレッドに関することであることは理解されるであろう（例えば、通常の監視スレッドは、作業実行に１００マイクロ秒を費やし、その後、数分間スリーピング状態に進む。１分間スリープし、１００マイクロ秒間動作するスレッドは、そのタイムスリーピングの９９．９９９８％を費やすことになる。）
したがって、このモデルでは遅延の必要性を考慮することが重要である。これは、「Ｗａｉｔ」ステートメントで実行される。

監視サービス（コマンドの受信を監視しない）での使用例について、以下では、適当なスケジュールを示す。

システムは、ループの本体を実行するのに要する時間を補償できることに注意されたい。これは、ウエイト期間が指定された時間にできるだけ近くなるようにするためである。

Ｗａｉｔステートメントのオペランドは、型Ｓｙｓｔｅｍ．ＴｉｍｅＳｐａｎとすることができる。

動的並列処理
Ｓｐｌｉｔステートメントによりコードの本体の定義を可能にできるが、ｎ行分のコードを並列に実行するために使用する可能性はない。そのような動的挙動のケースは強く、以下の２つの方法でサポートされる。

１．Ｓｐｌｉｔ−Ｆｏｒ−Ｅａｃｈステートメント
２．Ｓｐｌｉｔ−Ｓｅｌｅｃｔ−Ｒｅｃｅｉｖｅステートメント
前者は、他のすべての反復と並列にループの各反復を実行することを除き、Ｆｏｒ−Ｅａｃｈステートメントと同じ基本的な意味を持つ。つまり、繰り返されるコレクション内にあるアイテムの数だけ並列実行行があるということである。この数が決定された後、さらに行を並列ステートメントに追加することはできない。Ｓｐｌｉｔ−Ｆｏｒ−Ｅａｃｈは、Ｓｐｌｉｔと同じ「結合（ｊｏｉｎ）」規則を持つ、つまり、すべての反復が終了すると、Ｓｐｌｉｔ−Ｆｏｒ−Ｅａｃｈステートメントも終了する。

例を以下に示す。

これがそのようなステートメントを含む通常のＦｏｒ−Ｅａｃｈを超える利点は、すべてのＲｅｃｅｉｖｅステートメントが並列に待機するという点である。送信と受信との間の遅延が大きいほど、これを実行できることがますます重要になる。

「ｓｐｌｉｔ−Ｓｅｌｅｃｔ−Ｒｅｃｅｉｖｅ」は、入来メッセージに対する応答として並列実行の新しい行を動的に開始するために使用することができる。ある変種は、多重化された対話に関する理解によって異なるが、より単純な変種は、このコントラクトを実装するのを手助けする変種である（Ａ、Ｂ、およびＣはすべて入来メッセージである）。

ここで、コントラクトにより、Ｃを得るまで任意の個数のインタリーブされた＜Ａ，Ｂ＞シーケンスを取ることができ、Ｃを得たときに、すべてのＢが入ってくるのを待つ。各＜Ａ，Ｂ＞シーケンスは他のすべてと独立に処理されるため、ループ内でＳｅｌｅｃｔ−Ｒｅｃｅｉｖｅステートメントを使用してこれを実装するのは困難であろう。しかし、Ｓｐｌｉｔ−Ｓｅｌｅｃｔ−Ｒｅｃｅｉｖｅを使用することができる。

このステートメントの内側の１行が出力する毎に、新しい行が作成され、Ｓｅｌｅｃｔステートメントをその新しい行について実行することができる。これは、そのステートメントは決して独立に終了することはないことを意味している（例えば、常に、次のメッセージを処理するために新しい行が生じる）。ステートメントを終了し、そのまますでに開始されているすべての行を実行できるようにするために、そのステートメント内の何らかのコードで「Ｆｉｎｉｓｈ Ｓｐｌｉｔ」ステートメントを実行することが可能である。

注意：前文を考慮すると、１つの実行行という考え方は、ソースコード行を指すのではなく、むしろ、「一連の実行」、例えば、並列処理プログラム内の一連のステートメントを指すことは理解されるであろう。

終了
「Ｅｘｉｔ」の新しいバージョンのいくつかは、すでに上で説明されているが、わかりやすくするために、以下にその内容と動作を繰り返し示す。

これは囲む「ｓｐｌｉｔ」、「ｓｐｌｉｔ−Ｆｏｒ−Ｅａｃｈ」、または「ｓｐｌｉｔ−Ｓｅｌｅｃｔ−Ｒｅｃｅｉｖｅ」のすべての出力行を終了し、対応する「Ｅｎｄ」または「Ｎｅｘｔ」ステートメントに移動する。

これは、現在の行（静的であろうと動的であろうと）を終了するが、他には影響を及ぼさない。

フィルタ
メッセージフィルタは、前の方で「Ｒｅｃｅｉｖｅ」ステートメントについて説明したときには取り上げられていなかった。句を例外ハンドラに入れてそのハンドラの一致がただ単なる例外の型に基づくのではないようにすることと同様に、句をＲｅｃｅｉｖｅステートメントに追加し、コンテンツまたは大域的状態などの特別ないくつかの要因に基づいてメッセージを受け入れるか、または拒絶することができる。

コントラクト言語は対応する条件を指定する手段を持たないため、フィルタ式を使用してメッセージを除去するスケジュールは、そのコントラクトがプロセス内で違反にならないようにすることに注意されたい。

特にある場合にはさらに多くのメッセージを受信することができ、他の場合にはそうすることができないときに、フィルタを採用すると都合がよい。例えば、以下のようになる。

このステートメントは、メッセージパラメータが値「ＯＫ」を持つ場合のみメッセージＡを受け入れ、そうでなく、Ａメッセージパラメータが値「ＡＣＫ」を持つ場合にはＡおよびＢを受信する。これらの状況がどれも真でない場合、ステートメントはそれらが真になるまで待つ。そこで、フィルタは、メッセージが消費されるまで何回も呼び出されることがあり、したがって、副作用を起こすことなく真の式であることが重要である。

二次コネクタ
上述のように、サービスが最初に起動されると、明示的に指定することなくメッセージの送受信に使用することができるコネクタを割り当てられる。このコネクタは、サービスの「一次」コネクタと呼ばれる。一次コネクタは、第１のメッセージがサービスに送信された際のクライアントコネクタにバインドされる。これは、常に、そのコントラクトに関する実装パースペクティブを持つことができる。

他のクライアントとまったく同様に、アクティブ化されたサービスがクライアントとして他のサービスと通信することを望んでいる場合、何らかのサービスアドレスにバインドされているコネクタファクトリを使用し、そのファクトリからコネクタを作成し、メッセージの送信を開始することが可能である。上述のように、コネクタファクトリにより作成されたすべてのコネクタは使用パースペクティブを持つ。

もしサービスが、一次コネクタと同じコントラクト上にあろうとそうでなかろうと、他のクライアントに対話を開始させたいとすればどうであろうか？一次コネクタは、すでにバインドされており、したがって、共有することはオプションではない。それに、他の何らかのコントラクトを実装したい場合、一次コネクタはおそらくとにかく役立たない。

答えは、実装パースペクティブを持つ二次コネクタを作成することである。サービスにおけるすべての実装パースペクティブコネクタは、二次コネクタと呼ばれる。サービス外では、すべてのコネクタは等しい、一次でも二次でもないことは理解されるであろう。

新しい二次実装コネクタの作成を以下に示す。

ここでは以下の２点に注目すべきである。
１．「Ｉｍｐｌｅｍｅｎｔｓ」キーワードを変数宣言の中で型修正子（ｔｙｐｅ ｍｏｄｉｆｉｅｒ）として使用することができる。これは、宣言された変数に実装パースペクティブを与える。
２．実際のコネクタオブジェクトは、サービス参照なしで所望のコントラクトを呼び出すことによって作成できる。これは、たぶん型名のかなり奇妙な使い方であるが、二次コネクタを作成する唯一の方法である。

「Ｉｍｐｌｅｍｅｎｔｓ」コントラクト型修正子は、クラスまたはモジュールメンバとして、またはメソッドへのパラメータとして含む、コネクタ変数が作成できる場合には必ず使用できる。一方のパースペクティブのオブジェクトを反対のパースペクティブの変数に割り当てようとすると、コンパイル時に失敗することがある。コネクタ−変数割り当ての規則は、コネクタ−コネクタのバインドの規則とちょうど反対とすることができることに注意されたい。つまり、コネクタは、同じパースペクティブの割り当て済みコネクタとしかできないが、反対のパースペクティブのコネクタにバインドしなければならない。

見つからないサービス
利用可能なサービスがないことを検出する方法は２つある。第１に、ＴＣＰアドレスが有効でないことがある。つまり、ポートが開かれておらず、サービスが実際にはそこにない。この問題は、第１のメッセージをサービスに送信しようとする際に検出され、即座に例外を発生させることができる。

第２に、メッセージは宛先に届くことができるが、ホスティング環境はサービス名またはサービスインスタンスを認識しない。この場合、メッセージを送信するスケジュールは、寿命とともに移動しており、例外を投げるのは意味がない。

代わりに、問題は、オーケストレーションクラスのメソッドをオーバーライドすることにより取り扱われる。

タイムアウト
一方が一方のスケジュールから他方に非同期メッセージを送信する場合、応答は届く保証はない。このようなことが生じる可能性のある理由としては、限定はしないが、低水準の通信障害、またはクライアントとサーバとの間での予想される内容についての不一致を含む様々な理由がある。コントラクトは、２つのメッセージの間の最大遅延を指定できないため、コントラクトが２週間の間必要とする要求に応答しないサービスは、技術的に、そのコントラクトを分けていない。最初にメッセージを送信することなくスケジュールが終了した場合のみ、コントラクトの違反となる。

これは、サービスおよびサービスクライアントに対するスケジュールを作成する際に考慮しなければならない問題を示している。サービスが受信を依存できる唯一のメッセージは、第１のものであるが、それは、メッセージが到着したのが第１の場所で開始したという理由にあるからである。サービスクライアントは、そのことにさえあまり依存できない。幸運なことに、ＶＢオーケストレーションでは、適当な実装ツールを用意している。

異なる取り扱いを要する２つの状況がある。

１．与えられたメッセージが届かない場合、スケジュールが具現化する計算プロセスを完全に放棄することができる。スケジュールコードは大きくならないようにされるので、セッションタイムアウトは、この状況では十分であり、推奨される。

２．与えられたメッセージが届かない場合、スケジュールは、それから回復して、既定の情報とともに進むことができるか、または要求の再送を試みるか、または情報について他の何らかのサービスとのコンタクトを取ることができる。タイムアウト間隔を設定しているＳｅｌｅｃｔ／Ｒｅｃｅｉｖｅステートメントは、この状況に対し推奨される。このような状況についてはすでに説明されている。

上述のように、Ｓｅｌｅｃｔ／Ｒｅｃｅｉｖｅステートメントは、複数のケースを持たなくてよい。Ｒｅｃｅｉｖｅステートメントは、実際、より効率的に実装された（が、機能的に等価な）バージョンの、単一のケースを伴うＳｅｌｅｃｔ／Ｒｅｃｅｉｖｅである。

つまり、

は

に等価である。

この実現を備えると、メッセージが予期されているのに届かない場合はいつでも、Ｒｅｃｅｉｖｅステートメントにタイムアウト間隔を追加することによりそれを処理することができる。

本発明によれば、状況に応じて、このようなことが生じた場合にいくつかの代替が使用可能である。しかし、一般にガイドラインを定義できないことに留意されたい。すべては、解決しようとしている問題に完全に依存する。例えば、次のようである。

・ 少し長く待つ。

・ 応答がパラメータなしの「ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ−ｓｔｙｌｅ」メッセージであった場合、確認応答が否定的（または、状況によっては肯定的）であるという仮定の下で進めることを決定することができる。

・ 応答メッセージが、なしで処理することができる何らかのクリティカルでないデータを送り返した場合、たぶん、到着していないデータに対する何らかの既定値とともにそうする。おそらく、Ｗｅｂサービスは、パスポートに似たサービスから個人化データを検索しているが、何もなければ、Ｗｅｂサービスは制限付きの個人化とともに処理を進める。

・ 待機していたサービスにメッセージを再送しようと試みる。

・ 接続可能な他の何らかのサービス、または同じサービスの他のインスタンスを見つけて、その情報を取得する。

これを行うメソッドは、もちろん、状況により異なる。上の１番目の項目を除くすべてに共通なのは、コントラクト自体がいくつかのメッセージが到着しないおそれがあるという事実を受け入れないと、大きな問題になるという点である。スケジュールを抜けると、寿命内で作成されたそれぞれのコネクタが調査され、それを通じて行われたメッセージ交換が完了しているかどうか検証する。「行われていない」コネクタはいずれも、そのコントラクトに違反しているとして注目され、例外が投げられる。あるべきメッセージを受信しない場合、どこかにエラーがあっても、スケジュールに対してどれだけ重要なことかを知る手段がないため、ランタイムは単純に無視することはできない。しかし、メッセージが到着しないコネクタを破棄することにより、スケジュールはランタイムに、その特定のコネクタについてコントラクトに違反すべきでないことを通知する。

しかし、コネクタを破棄することもまた、そのコネクタに対し他の処置が講じられないことを意味する場合がある。それに送信できないか、またはそれからメッセージを受信することができない。試みると、エラーが発生する。

Ｓｅｌｅｃｔステートメントのタイムアウト間隔では、ステートメントのグループが実行に要する総時間に上限を設定せず、１つのステートメントがメッセージを待つ時間のみに対し設定することに注意されたい。前者を実行するには、ＳｐｌｉｔおよびＷａｉｔステートメントを使用することができる。

ＶＢオーケストレーションではリアルタイムの動作を主張していないので、これが要する時間は指定された２分以内であるという保証はない。第２行が休止イベントに達した場合のみ、Ｓｐｌｉｔステートメントが実際に終了し、「Ｅｎｄ Ｓｐｌｉｔ」の後のステートメントが実行される。

非スケジュールコードとの相互作用
非同期プログラミングにＳｅｎｄおよびＲｅｃｅｉｖｅステートメントを使用することが正しい解決手段とならない状況がある。状況によっては、スケジュールの単一スレッドのブロッキングの性質がエレガントな解決手段を邪魔することになるか、またはおそらく、本質的に、単にスケジュール駆動でない何らかのＵＩコードを用意する必要がある。

吉報なのは、このような状況であっても、ボタン押下イベントなどをサービスまたはサービスクライアントへのメッセージに変換する少しのコードを書くのは容易であることである。つまり、非同期プログラミングは、イベントベースのグラフィカルＵＩプログラミングとは非常に相性がよいのである。

これら２つのパラダイム−イベントベースとスケジュールベース−の間のこのようなブリッジを実現するために、ＶＢオーケストレーションでは、非スケジュールコードでイベントへの入来メッセージの送信およびマッピングを行うことができる。したがって、メッセージは、スケジュールおよびそのブロッキングの意味なしでやり取りできる。

コントラクト内のそれぞれのメッセージにより、イベントがその型に追加される。メソッドおよびイベントは．ＮＥＴではオーバーロードをできないため、イベント名はＳｔｒｉｎｇ“Ｅｖｅｎｔ”が直接追加されたメッセージの名前となる。メソッドは、メッセージとまったく同じ名前を持つ。

例を以下に示す。

以下で調べるサンプルアプリケーションでは、グラフィカルＵＩ相互作用に特に関係するこのような方法でメッセージ交換が使用される。

グラフィカルユーザインターフェース
Ｗｉｎ３２ベースのグラフィカルユーザインターフェースには、表示する新しいデータをコントロールに与えるなど、特定の操作を行うために使用されるスレッドに関して特別な要求条件がある。すべてのコントロールがこの要求条件を持つわけではないが、一部のコントロールはそうであり、それに適応しなければならない。スケジュールと個別のコネクタは両方とも、ＵＩスレッドにアタッチし、スケジュールで受信した、またはコネクタで受信したすべてのメッセージは、特定のＵＩスレッドのコンテキストで受信される。

この機能は、使いやすいが、実際に必要になった状況に限られるであろう。スケジュールコードを単一スレッドに強制すると、同時実行の機会が制限され、したがって、パフォーマンスに対するボトルネックになるおそれがあることは理解されるであろう。

第２のステートメントは、必ず、戻った後、そのコネクタ上で受信されたすべてのメッセージはそのフォームの所有スレッド上に到着するようにする。これはサービスの一次コネクタ上でも実行できることに注意されたい（これは、一次コネクタを明示的に参照する数少ない妥当な機会の１つである）。

しかし、たいていは、サービスおよびサービスクライアントは、ＵＩコードを直接呼び出さず、メッセージをそれらを含むフォームに送信するが、これは、たいてい、制御スレッドを設定することに意味がある非スケジュールコネクタであることを意味する。

以下に、「ｓｅｔＣｏｎｔｒｏｌ（）」を使用した場合の例を示す。

ｃｏｎｎｅｃｔｏｒ１およびｃｏｎｎｅｃｔｏｒ２が両方とも同じ所有スレッドにバインドされていない限り、メッセージ受信はこのケースの中で非決定論的となる（スレッドに関して）。スレッド情報は、このケースの中のいずれかのコネクタから引き出すことができることは理解されるであろう。したがって、ケースの中のすべてのコネクタが同じ所有スレッドにバインドされ、スケジュールが所有スレッドにバインドされるようにすることが重要である。

動作可能なコンピューティング環境
次に、図７を参照すると、開示されているアーキテクチャを実行する動作が可能なコンピュータのブロック図が示されている。本発明の様々な態様の他の状況を示すために、図７および以下の説明は、本発明の様々な態様を実装できる好適なコンピューティング環境７００の簡潔な一般的説明を行うことを意図している。本発明は、１つまたは複数のコンピュータ上で実行できるコンピュータ実行可能命令の一般的な状況において上で説明されているが、当業者であれば、本発明は、他のプログラムモジュールと組み合わせて、および／またはハードウェアとソフトウェアとの組合せとしても実装できることを理解するであろう。

一般に、プログラムモジュールは、特定のタスクを実行する、または特定の抽象データ型を実装するルーチン、プログラム、コンポーネント、データ構造などを含む。さらに、当業者であれば、本発明は、それぞれ、１つまたは複数の関連する装置に動作するように結合できる、シングルプロセッサまたはマルチプロセッサコンピュータシステム、ミニコンピュータ、メインフレームコンピュータ、ならびにパーソナルコンピュータ、ハンドヘルドコンピューティングデバイス、マイクロプロセッサベースまたはプログラム可能家電製品などを含む、他のコンピュータシステム構成で実施できることを理解するであろう。

本発明の例示されている態様は、通信ネットワークを通じてリンクされているリモート処理装置によりいくつかのタスクが実行される分散コンピューティング環境で実施することもできる。分散コンピューティング環境では、プログラムモジュールは、ローカルおよびリモートの両方のメモリ記憶装置内に配置されうる。

コンピュータは、通常、様々なコンピュータ可読媒体を含む。コンピュータ可読媒体は、コンピュータによってアクセスできる媒体であればどのような媒体でもよく、揮発性および不揮発性媒体、取り外し可能および固定媒体を含む。例えば、限定はしないが、コンピュータ可読媒体は、コンピュータ記憶媒体および通信媒体を含むことができる。コンピュータ記憶媒体は、コンピュータ可読命令、データ構造体、プログラムモジュール、またはその他のデータなどの情報を格納する方法または技術で実装される揮発性および不揮発性、取り外し可能および固定媒体を含む。コンピュータ記憶媒体は、限定はしないが、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたはその他のメモリ技術、ＣＤ−ＲＯＭ、デジタルビデオディスク（ＤＶＤ）またはその他の光ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置またはその他の磁気記憶装置、または所望の情報を格納するために使用することができコンピュータによりアクセスできるその他の媒体を含む。

通信媒体は、通常、コンピュータ可読命令、データ構造体、プログラムモジュール、または搬送波もしくはその他のトランスポートメカニズムなどの変調されたデータ信号によるその他のデータを具現するものであり、任意の情報配信媒体を含む。「変調されたデータ信号」という用語は、信号内の情報を符号化する方法によりその特性のうち１つまたは複数が設定または変更された信号を意味する。例えば、限定はしないが、通信媒体としては、有線ネットワークまたは直接配線接続などの有線媒体、ならびに、音響、ＲＦ、赤外線、およびその他の無線媒体などの無線媒体がある。上記のいずれの組合せもコンピュータ可読媒体の範囲に含まれるべきである。

図７を再び参照すると、コンピュータ７０２を含む本発明の様々な態様を実装するための環境例７００が例示されており、またコンピュータ７０２は、処理ユニット７０４、システムメモリ７０６、およびシステムバス７０８を備える。システムバス７０８は、限定はしないがシステムメモリ７０６を含むシステムコンポーネントを処理ユニット７０４に結合する。処理ユニット７０４は、様々な市販プロセッサがあるがそのうちどれでもよい。デュアルマイクロプロセッサおよびその他のマルチプロセッサアーキテクチャも、処理ユニット７０４として採用することができる。

システムバス７０８は、メモリバス（メモリコントローラを備える、または備えない）、周辺機器バス、および様々な市販のバスアーキテクチャのどれかを使用するローカルバスにさらに相互接続できる数種類のバス構造のうちのいずれでもよい。システムメモリ７０６は、読み取り専用メモリ（ＲＯＭ）７１０およびランダムアクセスメモリ（ＲＡＭ）７１２を含む。基本入出力システム（ＢＩＯＳ）は、ＲＯＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭなどの不揮発性メモリ７１０に格納され、ＢＩＯＳは、起動時などにコンピュータ７０２内の要素間の情報伝送を助ける基本ルーチンを含む。ＲＡＭ７１２は、さらに、データをキャッシュするためのスタティックＲＡＭなどの高速ＲＡＭも含むことができる。

コンピュータ７０２は、さらに、好適なシャシ（図には示されていない）に入れて外部で使用するように構成することも可能な、内蔵ハードディスクドライブ（ＨＤＤ）７１４（例えば、ＥＩＤＥ、ＳＡＴＡ）、磁気フロッピー（登録商標）ディスクドライブ（ＦＤＤ）７１６（例えば、取り外しディスケット７１８からの読み出しまたは書き込み用）、および光ディスクドライブ７２０（例えば、ＣＤ−ＲＯＭディスク７２２を読み込む、またはＤＶＤなどの他の大容量光媒体から読み出しまたは書き込む）を備える。ハードディスクドライブ７１４、磁気ディスクドライブ７１６、および光ディスクドライブ７２０は、ハードディスクドライブインターフェース７２４、磁気ディスクドライブインターフェース７２６、および光ドライブインターフェース７２８によりそれぞれシステムバス７０８に接続できる。外付けドライブ実装用のインターフェース７２４は、Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ（ＵＳＢ）およびＩＥＥＥ１３９４インターフェース技術のうちの少なくとも一方または両方を含む。

ドライブおよび関連するコンピュータ可読媒体は、データ、データ構造、コンピュータ実行可能命令などを格納する不揮発性記憶装置を実現する。コンピュータ７０２では、ドライブおよび媒体は、好適なデジタル形式のデータの格納に対応している。上記のコンピュータ可読媒体の説明ではＨＤＤ、取り外し可能磁気ディスケット、およびＣＤまたはＤＶＤなどの取り外し可能光媒体を取り上げたが、当業者であれば、ｚｉｐドライブ、磁気カセット、フラッシュメモリカード、カートリッジなどのコンピュータにより読み取り可能な他のタイプの媒体も、動作環境例で使用することができ、またそのような媒体は、本発明の方法を実行するためのコンピュータ実行可能命令を格納できることは理解するであろう。

オペレーティングシステム７３０、１つまたは複数のアプリケーションプログラム７３２、その他のプログラムモジュール７３４、およびプログラムデータ７３６を含む、多くのプログラムモジュールは、ドライブおよびＲＡＭ７１２に格納することができる。オペレーティングシステム、アプリケーション、モジュール、および／またはデータの全部または一部も、ＲＡＭ７１２にキャッシュすることができる。

本発明は、様々な市販のオペレーティングシステムまたはオペレーティングシステムの組合せで実装できることは理解される。

ユーザは、１つまたは複数の有線／無線入力装置、例えばキーボード７３８およびマウス７４０などのポインティングデバイスを通じてコンピュータ７０２にコマンドおよび情報を入力することができる。他の入力装置（図に示されていない）としては、マイク、ＩＲリモートコントロール、ジョイスティック、ゲームパッド、スタイラスペン、タッチスクリーンなどがある。これらの入力装置およびその他の入力装置は、システムバス７０８に結合されている入力装置インターフェース７４２を介して処理ユニット７０４に接続されることが多いが、パラレルポート、ＩＥＥＥ１３９４シリアルポート、ゲームポート、ＵＳＢポート、ＩＲインターフェースなどの他のインターフェースにより接続されることもできる。

モニタ７４４またはその他の種類の表示装置も、ビデオアダプタ７４６などのインターフェースを介してシステムバス７０８に接続される。コンピュータは、通常、モニタ７４４の他に、スピーカおよびプリンタなど、他の周辺出力装置（図に示されていない）を含む。

コンピュータ７０２は、（複数の）リモートコンピュータ７４８などの１つまたは複数のリモートコンピュータへの有線および／または無線通信を介する論理接続を使用してネットワーク接続環境で動作することができる。（複数の）リモートコンピュータ７４８は、ワークステーション、サーバコンピュータ、ルータ、パーソナルコンピュータ、ポータブルコンピュータ、マイクロプロセッサベースの娯楽機器、ピアデバイス、またはその他の共通ネットワークノードなどとすることができ、通常は、コンピュータ７０２に関係する上述の要素の多くまたはすべてを含むが、簡単のため、メモリ記憶装置７５０のみが例示されている。示されている論理接続は、ローカルエリアネットワーク（ＬＡＮ）７５２および／またはより大規模なネットワーク、例えば、ワイドエリアネットワーク（ＷＡＮ）７５４への有線／無線接続を含む。このようなＬＡＮおよびＷＡＮネットワーキング環境は、オフィスおよび会社では一般的なもので、イントラネットなどの企業規模のコンピュータネットワークを円滑にし、これらはすべて、大域的な通信ネットワーク、例えば、インターネットに接続することができる。

ＬＡＮネットワーキング環境で使用される場合、コンピュータ７０２は有線および／または無線通信ネットワークインターフェースまたはアダプタ７５６を介してローカルネットワーク７５２に接続される。アダプタ７５６により、無線アダプタ７５６と通信するように配置されている無線アクセスポイントも含むことができる、ＬＡＮ７５２との有線または無線通信を円滑にすることができる。ＷＡＮネットワーキング環境で使用される場合、コンピュータ７０２は、モデム７５８を含むことができるか、またはＬＡＮ上で通信サーバに接続されるか、またはインターネットなどにより、ＷＡＮ７５４上での通信を確立する他の手段を有する。モデム７５８は、内蔵でも外付けでも、また有線装置でも無線装置でよいが、シリアルポートインターフェース７４２を介してシステムバス７０８に接続される。ネットワーク接続環境では、コンピュータ７０２またはその一部に関して示されているプログラムモジュールは、リモートメモリ／記憶装置７５０に格納されうる。図に示されているネットワーク接続は実施例であり、コンピュータ間の通信リンクを確立するのに他の手段が使用可能であることは理解されるであろう。

コンピュータ７０２は、無線通信で動作が可能なように配置された無線装置またはエンティティ、例えば、プリンタ、スキャナ、デスクトップおよび／またはポータブルコンピュータ、ポータブルデータアシスタント、通信衛星、無線検出可能タグに関連付けられた機器または場所（例えば、キオスク、ニューススタンド、屋内トイレ）、および電話と通信するように動作可能である。これは、少なくともＷｉ−ＦｉおよびＢｌｕｅｔｏｏｔｈ（商標）無線技術を含む。そのため、通信は、従来のネットワークの場合ような定義済み構造、または少なくとも２つの装置間の単にアドホックな通信とすることができる。

Ｗｉ−Ｆｉ、つまりワイヤレスフィデリティを使用すると、家庭のソファに座ったまま、ホテルの寝室で、または仕事中の会議室から、無線により、インターネットに接続することができる。Ｗｉ−Ｆｉは、そのような装置、例えば、コンピュータがデータを屋内と屋外で、しかも基地局の範囲内であれば場所を限らず、送受信できる携帯電話のような無線技術である。Ｗｉ−Ｆｉネットワークでは、ＩＥＥＥ８０２．１１（ａ、ｂ、ｇなど）と呼ばれる無線技術を使用して、安全で信頼性の高い、高速な無線接続を実現する。Ｗｉ−Ｆｉネットワークは、コンピュータ同士を接続したり、インターネットに接続したり、有線ネットワーク（ＩＥＥＥ８０２．３またはＥｔｈｅｒｎｅｔ（登録商標）を使用する）に接続したりするために使用できる。Ｗｉ−Ｆｉネットワークは、無認可の２．４および５ＧＨｚ無線周波数帯で、１１Ｍｂｐｓ（８０２．１１ｂ）または５４Ｍｂｐｓ（８０２．１１ａ）のデータ転送速度により動作するか、または両方の帯域を含む（デュアルバンド）製品を使用して動作するため、これらのネットワークは、多くのオフィスで使用されている基本的な１０ＢａｓｅＴ有線Ｅｔｈｅｒｎｅｔ（登録商標）ネットワークに似た現実世界のパフォーマンスを達成することができる。

次に図８を参照すると、本発明によるコンピューティング環境例８００の略ブロック図が例示されている。システム８００は、１つまたは複数のクライアント８０２を含む。クライアント８０２は、ハードウェアおよび／またはソフトウェア（例えば、スレッド、プロセス、コンピューティングデバイス）とすることができる。（複数の）クライアント８０２は、例えば、本発明を採用することにより（複数の）クッキーおよび／または関連するコンテキスト情報を収容することができる。システム８００は、さらに、１つまたは複数のサーバ８０４も含む。サーバ８０４もまた、ハードウェアおよび／またはソフトウェア（例えば、スレッド、プロセス、コンピューティングデバイス）とすることができる。サーバ８０４には、例えば、本発明を採用することにより変換を実行するスレッドを置くことができる。クライアント８０２とサーバ８０４との間で可能な通信の１つは、２つまたはそれ以上のコンピュータプロセス間で伝送されるように適合されたデータパケットの形で実行できる。データパケットは、例えば、クッキーおよび／または関連するコンテキスト情報を含むことができる。システム８００は、（複数の）クライアント８０２と（複数の）サーバ８０４との間の通信を円滑にするために採用することができる通信フレームワーク８０６（例えば、インターネットなどの大域的通信ネットワーク）を含む。

通信は、有線（光ファイバを含む）および／または無線技術を介して円滑にすることができる。（複数の）クライアント８０２は、（複数の）クライアント８０２のローカルにある情報（例えば、（複数の）クッキーおよび／または関連するコンテキスト情報）を格納するために使用することができる１つまたは複数のクライアントデータストア８０８に動作可能なように接続される。同様に、（複数の）サーバ８０４は、複数のサーバ８０４のローカルにある情報を格納するために使用することができる１つまたは複数のサーバデータストア８１０に接続し動作させることができる。

付録Ａは「スタックフリー適合」という表題の論文である。この付録は、サブジェクト仕様の一部をなす。
付録Ａでは、本発明の様々な態様について説明しており、本出願の明細書の一部とみなすべきである。

上述した内容は、本発明の複数の実施例を含む。もちろん、本発明を説明するためにコンポーネントまたは方法の考えられるすべての組合せを説明することは不可能であるが、当業者であれば、本発明の他の多くの組合せおよび置換が可能であることを理解できるであろう。したがって、本発明は、付属の請求項の精神と範囲内に収まるすべてのそのような変更、修正、および変更形態を包含することが意図されている。さらに、「含む」という言い回しを詳細な説明または請求項で使用している範囲において、このような用語は「備える、含む」という用語と似た使い方をし、これは使用した場合に請求項の中で暫定的用語（ｔｒａｎｓｉｔｉｏｎａｌ ｗｏｒｄ）と解釈する。

付録Ａ
スタックフリー適合
Ｃｅｄｒｉｃ Ｆｏｕｒｎｅｔ、Ｔｏｎｙ Ｈｏａｒｅ、Ｓｒｉｒａｍ Ｋ．Ｒａｊａｍａｎｉ、Ｊａｋｏｂ Ｒｅｈｏｆ
Ｍｉｃｒｏｓｏｆｔ Ｒｅｓｅａｒｃｈ
{fournet,thoare,sriram,rehof}@microsoft.com
概要。代替可能性特性を満たす、つまり、ＩがＳに準拠し、Ｐが、Ｐ｜Ｓがスタックフリーとなるような環境であるならば、Ｐ｜Ｉはスタックフリーであるということが成り立つ、ＣＣＳプロセスの新規性のある詳細化関係（ｒｅｆｉｎｅｍｅｎｔ ｒｅｌａｔｉｏｎ）（スタックフリー適合）を提示する。スタックフリーダムは、デッドロックのＣＳＰ概念に関係しているが、これは、非同期システムの孤立メッセージを考慮することにより区別しやすい。適合は、ＣＣＳプロセス上の前合同関係であり、それによって、モジュール方式の精密化をサポートすることを証明する。適合を関係する先行順（ｐｒｅｏｒｄｅｒｓ）、ＣＳＰにおける安定失敗詳細化（ｓｔａｂｌｅ ｆａｉｌｕｒｅｓ ｒｅｆｉｎｅｍｅｎｔ）、およびＣＣＳにおける拒絶先行順（ｒｅｆｕｓａｌ ｐｒｅｏｒｄｅｒ）から区別する。新しいソフトウェアモデル検査器ＺＩＮＧで適合検査を実行し、それを使って分散プログラムにおけるエラーを見つけた方法について報告する。

１ はじめに
われわれは、メッセージ受け渡しプログラムがスタックフリーであることを検査することに関心を持っている［１１］。スタックフリーダムは、通信システムが、決して送信されないメッセージまたは決して受信されない送信メッセージを待ってデッドロックに陥ることがあり得ないという特性を形式化するものである。この論文では、適合の理論を一般化し、モデル検査分散プログラムのアプリケーションに関して報告することにより［１１］を拡張する。このアプリケーション例では、プログラマが、プログラムの外部から見えるメッセージ受け渡しの挙動を指定するインターフェースであるコントラクトを書く。コントラクトは、ＣＣＳプロセスと同じくらい豊かであると考えられる。スタックフリーダムは、モデル検査器を使用して実装がそのコントラクトに適合していることを検査することにより確認される。

システム全体の状態空間を探索することによりスタックフリーダムを検査すると、状態空間は同時実行プロセスの数が増えるとともに指数関数的に増大するため、状態空間はたちまち爆発的に増大し、またシステム全体が分析に利用可能である必要があるが、これは分散システムでは特に非現実的である。したがって、スタックフリーダムを構成的に検査したいのである。Ｉがコンポーネントの実装であり、Ｃがそのコントラクトである場合、記法Ｉ≦Ｃを使用して、ＩがＣに適合していることを表す。われわれの構成的アプローチがスタックフリーダムに関して健全であるためには、適合関係≦は以下の代替可能性特性に従う必要がある。Ｉ≦Ｃであり、Ｐが、Ｐ｜Ｃがスタックフリーであるような環境である場合、Ｐ｜Ｉもスタックフリーである（Ｐ｜ＣはＰとＣの並列化構成を表す）。代替可能性は、コンポーネントのコントラクトが呼び出しコンテキストにおけるコンポーネントの代わりに安全に使用できること、したがってモデル検査のスケーリングに役立つことを意味する。

われわれの適合という概念は、スタックネス（ｓｔｕｃｋ−ｎｅｓｓ）を保存する新規性のあるプロセス先行順である。スタックネスは、可視アクションとともに安定性（隠されたアクションを実行できないこと）も観察されるうるラベル付けされた推移システム内で直接観察することができる。われわれのアプリケーションで、これが重要なのは、そのモデルを実行し、何が生じるかを観察することによりシステムを分析したいからである。スタックネスは、チャネル名に対する「残り（ｌｅｆｔ−ｏｖｅｒ）」アクションを包含するので、ＣＳＰデッドロックまたは未指定受信［９］よりも区別しやすい。デッドロックの他に、これは、非同期システムでは決して消費されない孤立メッセージを含み、処理されない例外メッセージなどのソフトウェア内の重要な失敗条件を直接モデル化する。

この論文では、以下の寄稿を行う。

− 標準ＣＣＳ推移意味論に基づいて適合の概念を定義し、それがスタックフリーダムの代替可能性特性を満たす前合同（ｐｒｅｃｏｎｇｒｕｅｎｃｅ）（つまり、すべてのＣＣＳコンテキストにより保存される）であることを証明する。適合を最も密接に関係する知られている先行順、ＣＳＰ安定失敗詳細化［３，５，１２］、およびＣＣＳ拒絶先行順［１０］から区別する。

− われわれは、ソフトウェアモデル検査器ＺＩＮＧで適合検査器を実装した。この実装手法は、極めて一般的なものであり、ソフトウェアで適合検査を実行するように既存のモデル検査器を手直しするために使用できる。ＺＩＮＧプロセスは、ＣＣＳプロセスとしてみなすことができ、したがって、われわれの適合理論は、ＺＩＮＧ適合検査器に適用される。ＺＩＮＧを適用して、非自明な分散アプリケーションにおけるコントラクト適合を検査したところ、アプリケーションにいくつかのバグが発見された。

この論文では、代替可能性特性を満たす適合関係を提案している、［１１］で報告された研究結果を拡張する。［１１］の適合関係は、いくつかの点で制限されている。まず、［１１］における適合は、推移により生成されるアクションを記録することにより適合検査の純粋に観察的な実装を排除する、プロセス¹の構文的形態を参照することにより定義される。第２に、［１１］における関係は、統語的制約が任意のＣＣＳコンテキストの下で保存されないため、前合同関係ではない。その結果、Ｐ₁≦Ｑ₁かつＰ₂≦Ｑ₂ならばＰ₁｜Ｐ₂≦Ｑ₁｜Ｑ₂という望ましいモジュール原理を含む自然で有用な代数法則は失敗する。第３に、［１１］における理論は、非標準アクション²を使用して非決定論を処理することにより複雑になる。この論文は、純粋に観察的であり、標準ＣＣＳ推移システムに基づき、隠されたアクション（γ）に関する非決定論、隠蔽、および安定性の統一された取り扱いを与える適合の実質的一般化を示す。これは、目に見えるアクションおよび安定性を観察することによりモデル検査器で実装することができ、また他の意味論的詳細化関係と比較することができる。代替可能性を証明する他に、われわれの一般化された適合関係は前合同関係であり、それによってモジュール方式の詳細化をサポートすることを証明する。最後に、ソフトウェアモデル検査器で実装し、分散プログラムを検査するコントラクトに適用することによりこの理論を適用した。

−−−−−−−−−−
¹ 例えば、［１１］の適合定義のいくつかの場合は、Ｐ＃ＱまたはＰ＋Ｑの形式のプロセスにのみ適用される。この性質の他の類似の統語的依存関係も［１１］に存在する。

² アクションは［１１］で名前を付けられている。

−−−−−−−−−−
この論文の残りは、以下のように編成される。セクション２で、スタックフリー適合に最も密接に関係するＣＳＰおよびＣＣＳの伝統における詳細化関係について説明する。セクション３で、われわれの適合の理論を提示する。論文を制限の範囲内に留めるために、われわれの適合理論のプレゼンテーションにおけるすべての証明を省略した。完全に詳細な証明は、われわれの技術レポート［？］にある。セクション４では、ＺＩＮＧ適合検査器を適用することにより分散プログラム内のエラーを見つけることについて説明し、セクション５で締めくくる。

２ 関連する研究
われわれの適合の概念は、ＣＳＰ［３，５，１２］で安定失敗詳細化に関してモデル化され、詳細化検査器ＦＤＲ［１２］の成功が刺激となっている。われわれのプロセスモデルでは、ＣＣＳの動作意味論をＣＳＰ概念に類似してはいるが異なる拒絶の概念と組み合わせる。適合の定義は、シミュレーションに依存し、目に見えるアクションおよび安定性が観察可能なラベル付けされた推移システムに直接適用される。セクション３．３で説明されているように、スタックフリーダムに関する代替可能性の条件は、安定失敗詳細化がＣＣＳに直接組み込まれる場合には、満たされない。理由は、スタックフリーダムはデッドロックのＣＳＰ概念と異なり、またそれと比べて特徴的な概念であるからである。この違いに対応するため、われわれの適合関係は、即時拒絶（ｒｅａｄｙ ｒｅｆｕｓａｌｓ）の考えに基づいており、プロセスは特定のアクションを（同時に）他を拒絶しながらすぐに受け付ける必要がある。

スタックフリー適合は、Ｉａｉｎ Ｐｈｉｌｌｉｐｓの拒絶試験理論［１０］で開発されたようなＣＣＳに対する拒絶先行順にも関係する。拒絶先行順により、拒絶の後に生じるアクションの観察が可能になり、したがって、拒絶と組み合わせて即座条件を表すことができる。しかし、セクション３．４で説明されているように、スタックフリー適合は、拒絶先行順よりも厳密に大きい前合同である。

ＬａｒｓｅｎおよびＳｋｏｕ［６］による２／３バイシミュレーションの概念は、適合にある程度類似している。しかし、ＬａｒｓｅｎおよびＳｋｏｕは、隠蔽および内部アクション（γアクション）を取り扱わず、したがって、安定性の問題はそこでは生じない。われわれの適合の理論では、アプリケーションに本質的な、内部アクション、非決定論、および安定性の統一された取り扱いが可能である。

交互シミュレーション［１］は、インターフェースを［４］の実装に関連付けるために使用された。［１１］で説明されているように、交互シミュレーションでは、スタックフリーダムに対する代替可能性の条件を満たさない。

３ 適合理論
このセクションでは、ＣＣＳ［７，８］に関する必要な背景を述べ、スタックフリーダムおよび適合の概念を定義し、適合が前合同（定理１）であり、代替可能性特性を満たす（定理２）ことを証明する。

３．１ ＣＣＳプロセス
名前の可算集合Ｎ＝｛ａ，ｂ，ｃ，．．．｝を仮定する。集合

は、ラベルの集合と呼ばれる。集合

は、アクションの集合と呼ばれる。αはＡを範囲とし、λはＬを範囲として、

と書く。Ｌの部分集合Ｘについて、

と書く。Ｐ上の範囲のＣＣＳプロセスは、以下の式で定義される。

Ｐ：：＝０｜Ａ＜ａ₁，．．．，ａ_n＞｜Ｇ₁＋．．．＋Ｇ_n｜（Ｐ｜Ｑ）｜（νａ）Ｐ
Ｇ：：＝α．Ｐ
ここで、Ａはプロセス名を範囲にとり、式

を定義する。名前ａは（νａ）Ｐでバインドされていると主張する。Ｐの自由名はｆｎ（Ｐ）と表され、バインドされていないＰにおける名前である。

定義１（構造合同、≡）。構造合同≡は、バインドされた名前および変数（α変換）の変更および総和の項の順序変更とともに、以下の規則に従って閉じられた項に関する最小合同関係（ｃｏｎｇｒｕｅｎｃｅ ｒｅｌａｔｉｏｎ）である。

ＣＣＳの動作の意味は、定義２に示されているラベル付けされた推移システムにより与えられる。このシステムは、ＣＣＳの最近の発表において標準であるように、われわれが規則［ＣＯＮＧ］を追加したことを除き、Ｍｉｌｎｅｒ［８］により与えられたそのものである。以下の規則［ＳＵＭ］では、Ｍの範囲は総和に及んでいる。

定義２（ラベル付け推移）。

とする。ａ．Ｐ＃ｂ．Ｑとａ．Ｐ＋ｂ．Ｑの違いは重要である。前者は、内部選択を表し、プロセスはａ．Ｐまたはｂ．Ｑへの推移を選択するが、後者は、外部選択［５］を表し、プロセスが

または

を提供することによりＰまたはＱに進むかどうかを環境が制御する。内部選択と外部選択との区別は、われわれの適合の概念では重要である。

非同期アクションは、ＣＣＳにおける順次継続なしのアクションとしてモデル化される。したがって、非同期アクションは、ａが非同期に生起する場合に、ａ｜Ｐのように「生成（ｓｐａｗｎ）」される。

記法。名前とアクションの（場合によっては空の）シーケンスに対し

および

を書く。

について、

と書き、Ｐ≡Ｐ₀、Ｐ’≡Ｐ_nとなるようなＰ₀、Ｐ₁、．．．、Ｐ_nがある場合に、０≦ｉ＜ｎについて、

となる。記法

を使用するが、ただし（γ＊λ）∈｛λ，γλ，γγλ，．．．｝である。

となるような

が存在する場合にＰ→Ｐ’と書き、

は、

となるようなＰ’が存在することを意味し、Ｐ→は、ある

について

であることを意味する。Ｐは、隠蔽アクションを実行できない場合、つまり

であれば安定であり、アクションをまったく実行しない場合、つまり

であれば終了状態である。最後に、簡略表記

を使用して、λまたは

のいずれかが

内に現れるラベル間にあることを意味する。

３．２ スタックフリーダム、即時拒絶、および適合
２つのプロセスＰおよびＱが

内のローカル名で通信する場合、システムを

と書くことができる。

は、ＰおよびＱに対するローカル名であるため、

上で相互作用できる環境は他になく、したがって、

上のＰおよびＱの相互作用が完全に成功するかどうかを検証することには意味がある。簡単に、進行がありえなければ

上でプロセスがスタックしているといい、その一部分は

における名前で通信することが可能な状態にある、つまり終了していなかったため、

上の通信は成功していない。われわれのアプリケーションでは、Ｐは、通常、仕様（コントラクト）がＱであるプロセスへのローカル接続

を持つプログラムのモデルである。ＰとＱによって表される実装との間の相互作用がスタックフリー、つまりスタックしえないことを検査したい。スタックフリーダムは、安全特性であり、システムＰ｜Ｑの到達可能性分析により検査することができる。以下の定義では、スタックネスとスタックフリーダムを正確にしている。

定義３（スタックプロセス）。

が終了状態であり、ある

に対して

の場合、プロセスＰは

上でスタックしているという。このようなλを残留アクションと呼ぶ。

定義４（スタックフリープロセス）。

で

となるようなＰ’および

がなく、Ｐ’が

上でスタックしている場合に、プロセスＰは

上でスタックフリーであるという。

上述の状況において、

であり、

上でＰ’｜Ｑ’がスタックするような遷移

を検索することにより定義４を適用する。定義３の制約

および定義４の条件

により、常に

がローカルである状態で、

における名前について内部反応（γアクション）のみが生起しうることが強制される。ある

について

なので、ＰとＱとの相互作用は、コアクション

により照合できない残留アクションλで終了する。λが入力アクションをモデル化する場合、コンポーネントは決して到着しないメッセージの受信を待ち続け、λが送信アクションをモデル化する場合、コンポーネントは決して消費されないメッセージを送信し続ける。後者の例は、処理されないリモートの例外メッセージである。このような状態は、多くの非同期アプリケーションにおける数々の問題の重要な指標となっている。セクション４には、実際のシステムの適合を検査する際の定義４の使用例を示す。

Ｐ｜Ｑがスタックフリーならば、Ｐ｜Ｓは任意の選択された名前

上でスタックフリーであるという代替可能性特性をＳ≦Ｑが保証するような適合関係≦を求める。例示的シナリオでは、これは、実装ＳがそのコントラストＱにより表されるシステムＰ｜Ｑのスタックフリーダムを検査しても安全であることを意味している。この目標を達成するために、関係≦は、Ｓ≦Ｑならば、任意のコンテキストで、少なくともＳと同じ回数だけＱが

上でスタックするような関係でなければならない。この要求条件は、Ｓによって実際には送られない、ＣＳＰ［５］の拒絶の概念によりエレガントに捕捉できるアクションを与える見込みはないことを意味する。しかし、残留アクションのすべての場合を除外しないので、拒絶要求条件単独では十分でないことがわかる。これが、拒絶が即時拒絶に強められる場合に、以下の定義の動機となっている。

とし、Ｌ⁽¹⁾は、空集合

とともにＬのシングルトン（ｓｉｎｇｌｅｔｏｎ）集合を表すものとする。

定義５（拒絶）。ＸがＬの部分集合であれば、Ｐが安定であり

である場合、かつその場合に限り、ＰはＸを拒絶するという。

であり、Ｐ’がＸを拒絶するようなＰ’が存在する場合、かつその場合に限り、ＰはＸを拒絶できるという。

定義６（即時（ｒｅａｄｉｎｅｓｓ））。Ｙ∈Ｌ⁽¹⁾ならば、Ｐが安定であり、λ∈Ｙならば

である場合、かつその場合に限り、ＰはＹ上で即時（ｒｅａｄｙ）であるという。自明であるが安定プロセスは

上で即時であることに注意されたい。

定義７（即時拒絶）。Ｘ⊆ＬかつＹ∈Ｌ⁽¹⁾ならば、ＰがＹ上で即時である状態からＸを拒絶できる場合、つまり、

であり、Ｐ’がＸを拒絶し、Ｐ’がＹ上で即時であるようなＰ’が存在する場合、かつその場合に限り、Ｙ上で即時となっている間にＰはＸを拒絶できるという。

即時集合は、アクションに関して定義されるが（定義６）、拒絶は、コアクションに関して定義される（定義５）ことに注意されたい。最初、これは少し混乱させる可能性がある。例えば、プロセスａは、｛ａ｝を拒絶し、｛ａ｝上で即時である。

定義８（適合関係）。プロセス上の２項関係Ｒは、Ｐ Ｒ Ｑであればいつでも以下の条件が成立する場合、かつその場合に限り適合関係であるという。

Ｃ１．

ならば、

およびＰ’ Ｒ Ｑ’となるようなＱ’が存在する。

Ｃ２．ＰがＹ上で即時である間Ｘを拒絶することができれば、ＱはＹ上で即時である間Ｘを拒絶できる。

定義８の条件［Ｃ２］は、驚くべきことのように見えるかもしれない。これは、セクション３．３および３．４を含めて、以下で動機付けされ説明される。

Ｒ₁およびＲ₂がプロセス上の２項関係である場合、Ｒ₁○Ｒ₂と表されるその合成を、
Ｒ₁○Ｒ₂＝｛（Ｐ，Ｑ）｜∃Ｒ．（Ｐ，Ｒ）∈Ｒ₁∧（Ｒ，Ｑ）∈Ｒ₂｝
により定義する。

補助定理１．｛Ｒ_i｝_i∈Iを適合関係の族とする。すると、
１．関係∪_i∈IＲ_iは適合関係である。

２．任意のｉ，ｊ∈Ｉについて、関係Ｒ₁○Ｒ₂は適合関係である。

３．プロセス上の恒等関係は適合関係である。

補助定理１．１は、ＣＣＳバイシミュレーションおよびシミュレーション［７］について標準的な方法により、すべての適合関係の和集合をとることにより最大の適合関係として≦を定義できることを示している。

定義９（適合、≦）。最大の適合関係を適合と呼び、≦で表す。（Ｐ，Ｑ）∈≦に対してＰ≦Ｑと書き、ＰはＱに適合するという。

定義８の条件［Ｃ２］により、Ｐ≦Ｑならば、ＱはＰと同じ回数だけ名前ａ上でスタックすることが保証される。定義８では、即時制約は一度に１つの名前にしか課せられないことが非常に重要であるが、これは、即時集合Ｙが高々シングルトン集合であるという事実による（

を選択すると、特別な場合として、即時制約のない標準拒絶条件が得られる）。これにより、仕様を詳細化よりも非決定論的にすることができるが、それは、仕様が名前毎に異なる方法でその非決定論を解決することができるからである。例えば、ａ＋ｂ≦ａ＃ｂである。名前｛ａ，ｂ｝のアルファベットについて考察すると、プロセスａ＋ｂは｛ａ，ｂ｝を拒絶し、｛ａ｝と｛ｂ｝の両方で即時である。プロセスａ＃ｂは、状態ａから

を拒絶し、状態｛ｂ｝から

を拒絶する。状態ａから｛ａ｝で即時であり、状態ｂから｛ｂ｝で即時である。したがって、条件［Ｃ２］は満たされる。読者は、いくつかのより興味深い例を検証したいことであろう。

ただし、Ｐ≦ＱかつＱ≦Ｐの場合、かつその場合に限り

と書く。また、規則［ＣＯＮＧ］により≡、⊆、≦であることも述べておく（適合の他の代数的特性については［？］を参照）。

命題１．適合関係≦は再帰的（ｒｅｆｌｅｃｔｉｖｅ）かつ推移的（ｔｒａｎｓｉｔｉｖｅ）である。

以下の定理では、主要な理論的結果、前合同（ＣＣＳの演算子は適合に関して単調である、定理１）および代替可能性（仕様は、安全に、それに適合するプロセスの代わりにできる、定理２）を述べている。完全な証明については、［？］を参照されたい。ＣをＣＣＳコンテキストに渡るとし、これらはその中に「穴（ｈｏｌｅ）」（［］と書く）を持つプロセス式である。

Ｃ：：＝［］｜（Ｐ｜［］）｜（［］｜Ｐ）｜（α．［］±Ｍ）｜（（νａ）［］）
Ｃ［Ｑ］と書いて、Ｃ内の穴をＱで置き換えて生じるプロセス式を表す。

定理１（前合同）。Ｐ≦ＱならばＣ［Ｐ］≦Ｃ［Ｑ］である。

定理２（代替可能性）。Ｐ≦Ｑと仮定する。すると、

上でＣ［Ｑ］がスタックフリーであることは

上でＣ［Ｐ］はスタックフリーであることを示す。

以下の２つのセクションは、適合がＣＳＰにおける安定失敗詳細化よりも細かく（適合がトレースに関して定義されるか、または代替として、安定失敗詳細化が推移に関して定義されている場合）、ＣＣＳにおける拒絶先行順序よりも粗いことを意味する。この意味で、適合は中間である。

３．３ 適合および安定失敗詳細化
適合の定義の中の条件［Ｃ２］は、ＣＳＰ［５，１２］における安定失敗詳細化の理論から手直ししたもので、トレースと拒絶の概念に基づいている。安定失敗モデルでは、プロセスＰは、その失敗の集合により表される。Ｐの失敗は、ペア

であり、ここで

はＰの有限トレースであり、Ｘは拒絶集合である。つまり、イベントＰの集合は

の後の安定状態から拒絶できる。プロセスＰは、ＰのトレースがＱのトレースに含まれ、Ｐの失敗がＱの失敗に含まれる場合にプロセスＱを失敗詳細化する。

われわれの適合定義では、拒絶を使用するが、より強い即時拒絶を条件［Ｃ２］で使用している。これは、適合がスタックフリーダムに関して代替可能であるべきという要求条件を動機としている。例えば、以下の式で定義された２つのプロセスＰおよびＱを考える。

Ｐ＝ａ．０およびＱ＝ａ．０＋γ．０
プロセスがラベル集合

にわたると考えると、Ｐの失敗³は、

であり、Ｑの失敗は

である。その結果、ＰはＱを失敗詳細化することになる。しかし、Ｐは、ａ上でスタックしているが、Ｑはスタックしえず、それは、その唯一の安定派生形が０であり、スタックプロセスではないからである。したがって、ＰがＱを失敗詳細化しても、Ｑのスタックフリーダムは、Ｐのスタックフリーダムを意味しない。対照的に、われわれの適合の定義における条件［Ｃ２］の即時制約では、Ｐが安定状態（Ｐ自体）からアクションａを実行することができるが、Ｑは不安定状態（Ｑ自体）からしかアクションａを実行できないため、

という帰結になる。

スタックフリー適合に対応する自然なトレースモデルでは、その失敗で即時拒絶を使用するように安定失敗モデルを修正し、失敗が、Ｒ＝（Ｘ，Ｙ）が拒絶集合Ｘ⊆Ｌおよび即時集合Ｙ∈Ｌ⁽¹⁾からなる即時拒絶であるペア

となるようにする。

ＣＳＰにおける安定失敗詳細化とスタックフリー適合との違いは、スタックネスとＣＳＰデッドロックとの違いから生じる。ＣＳＰでは、デッドロックは、特別な成功する終了イベント

が存在しないことにより示される。スタックネスは、ラベル付けされた推移システム内の複数の状態で直接観察可能であり、ＣＳＰデッドロックよりも区別しやすい。

３．４ 適合および拒絶先行順
われわれの適合の概念は、Ｉａｉｎ Ｐｈｉｌｌｉｐｓの拒絶検証の理論［１０］で定義されているような拒絶先行順に類似している。拒絶先行順では、拒絶集合を観察結果にすることにより拒絶（またはデッドロック）の後に生起することを観察することができる。［２］に従い、Ｘ⊆Ｌに対し、推移規則

を追加することにより拒絶先行順を定義することができる。

について、

である場合、かつその場合に限り、

と書く。通常の方法で、ベクトル

にリフトする。次に、失敗トレース

を定義する。≦_rfで表される拒絶先行順は、ｆ−ｔｒａｃｅｓ（Ｐ）⊆ｆ−ｔｒａｃｅｓ（Ｑ）の場合、かつその場合に限り、Ｐ≦_rfＱと設定することにより定義される。この定義により、同時拒絶および即時特定が捕捉される。例えば、

であれば、

となり、これはａが安定状態であることを示し、ここで集合｛ａ｝は拒絶され、ラベルａが提供される。遷移

がａ＋γ．０により照合できないため、

となることを観察することは興味深い。実際、拒絶先行順は十分強く、スタックフリーダムの代替可能性を保証する。しかし、適合よりも制約が強い。以下の式により定義されるプロセスＰおよびＱを考える。

Ｐ＝（ａ＋ｂ．ｃ）＃（ｃ＋ｂ．ａ）
Ｑ＝（ａ＋ｂ．ａ）＃（ｃ＋ｂ．ｃ）
−−−−−−−−−−
³ 最大拒絶集合に関して失敗を表し、シーケンスに対し＜．．．＞を使用する。

−−−−−−−−−−
定義から（または［？］の詳細を参照）、Ｐ≦Ｑであるが、

であることを検査することができる。Ｐ≦Ｑとなるのは、条件［Ｃ１］および［Ｃ２］からわかるようにＱは異なる派生形を選択できるからである。条件［Ｃ１］は、Ｑの派生形（ｃ＋ｂ．ｃ）により明らかであり、［Ｃ２］は、Ｑの派生形（ａ＋ｂ．ａ）により明らかである。

４ アプリケーション
セクション３に提示されている理論に基づき、共通プログラミング言語で書かれている非同期プログラムを分析するために使用できる適合検査器を実装した。このような言語（例えば、Ｃ、Ｊａｖａ（登録商標）、Ｃ＃）は、ＣＣＳで直接モデル化するのが面倒ないくつかの機能（プロシージャ呼び出し、ポインタ、共有メモリ、例外、およびオブジェクト）を持つ。われわれの適合検査器は、複雑な符号化を必要とせず直接そのような機能をサポートする言語ＺＩＮＧに対応している。ＺＩＮＧの動作に関する意味は、ラベル付け推移システムとして与えられる。ＳｅｎｄおよびＲｅｃｅｉｖｅステートメント以外のすべてのステートメントは、γアクションのラベル付きの遷移としてモデル化される。ＳｅｎｄおよびＲｅｃｅｉｖｅステートメントからの遷移は、対応するチャネル名でラベル付けされる（送信または受信されるデータ値を無視する）。適合の定義８では、ＣＣＳの構文を参照しておらず、ラベル付けされた遷移システムの意味論に純粋に基づいていることに注意されたい。したがって、定義８を直接使用して２つのＺＩＮＧプロセスの間の適合を定義することができる。

われわれの適合検査器を適用して、共通プログラミング言語で書かれている分散プログラムのコントラクトを検査した。次に、適合検査の実行方法と見つけたエラーについて説明する。

われわれのアプリケーション例は、書店の在庫および発注プロセスを管理するための分散プログラムである。このシステムは、Ｍｉｃｒｏｓｏｆｔ社の製品開発グループにより作成され、メッセージ受け渡しおよびコントラクト仕様を受け付ける共通プログラミング言語の拡張となっている。コントラクトは、通信している状態マシンとして指定され、ソースコード内に型指定として現れる。コントラクトは、元々、メッセージの挙動の実行時検査をサポートすることを目的としていたが（不要なメッセージシーケンスを除去し、プログラミングエラーを発見するため）、ＺＩＮＧ適合検査器を使用して、静的に検査することを試みることを決定した。われわれは、ＺＩＮＧ適合検査器を開発環境に統合して、実装コードと突き合わせてスタックフリー適合に関してコントラクトを自動検査できるようにした。プログラミング言語、システム、およびコントラクトはすべて、われわれおよびわれわれの技術とは無関係に書かれたものであることを強調しておく。

システムの構造は図１（上）に示されている。これは、ＳｈｏｐｐｉｎｇＣａｒｓｅｒｖｉｃｅ、ＩｎｖｅｎｔｏｒｙＳｅｒｖｉｃｅ、ＯｒｄｅｒＳｅｒｖｉｃｅ、ＰｕｂｌｉｃＩｎｖｅｎｔｏｒｙＳｅｒｖｉｃｅ、およびＩｎｖｅｎｔｏｒｙＰｒｏｃｅｓｓｉｎｇの５つのサービスコンポーネントと、さらに２つのユーザインターフェースプロセスとを含む。サービスＡからサービスＢへ矢印は、ＡがＢを使用している（Ｂのクライアントである）場合に１つある。５つのサービスはそれぞれ、関連するコントラクトを持ち、それは、サービスの公に見える挙動の指定である。図１（上）では、それぞれのコントラクトは、それが指定するサービスと関連して名前が付けられている。コントラクトのうち２つが図１（下）に示されている。コントラクトは、メッセージペイロードを無視して、メッセージの集合上で通信状態マシンを指定する⁴．例えば、Ｓｈｏｐｐｉｎｇｃａｒｔコントラクトは、ＣｈｅｃｋＯｕｔメッセージまたはＣａｎｃｅｌメッセージが受信されるまでサービスが型ＡｄｄＩｔｅｍｓまたはＲｅｍｏｖｅＩｔｅｍのメッセージを繰り返し入力することを指定する（われわれは、入力にＴ？を使用し、出力にＴ！を使用するが、Ｔはメッセージ型である）。ＩｎｖｅｎｔｏｒｙＲｅｓｅｒｖａｔｉｏｎコントラクトで使用されるＴｉｍｅｏｕｔイベントは、特別なイベントである。Ｔｉｍｅｏｕｔｓは、実装言語の入力構文に付随させることができる。

コントラクト宣言で、コントラクトの名前と同じ新しい型名を作成する。サービスの実装コードは、以下のように、実装が想定されるコントラクトを指定するサービス宣言（クラス宣言とかなり似ている）内に置かれる。

他のサービスへの接続を表すオブジェクトを保持する変数は、それらのサービスを記述するコントラクトにより分類される。例えば、ＳｈｏｐｐｉｎｇＣａｒｔＳｅｒｖｉｃｅ実装の以下のステートメントでは、ＩｎｖｅｎｔｏｒｙＳｅｒｖｉｃｅへの接続を作成し、ｃｏｎｔで続行する。

コントラクト型に依存することにより、サービス実装を使用されるサービスのコントラクトを置き換えるＺＩＮＧモデルに自動的に変換することが可能である。そうする際に、定理２に頼る。例えば、上記の接続作成は、ＺＩＮＧステートメントｉｎｖ＝ｎｅｗ ｃＩｎｖｅｎｔｏｒｙＲｅｓｅｒｖａｔｉｏｎに変換され、ｃＩｎｖｅｎｔｏｒｙＲｅｓｅｒｖａｔｉｏｎは、ＩｎｖｅｎｔｏｒｙＲｅｓｅｒｖａｔｉｏｎコントラクトからコンパイルされたＺＩＮＧクラスである。このクラスのコンストラクタを呼び出すことの副作用として、並列処理プロセスが生成され、コントラクトで指定された通りに動作する。これは、以下のＣＣＳプロセスに対応する。

ただし、［ｃｏｎｔ］はコードｃｏｎｔを表す。これは、セクション３．２の適合の理論を導入した際に、定義３および定義４の前後でコメントの中で言及されたＣＣＳ形式の一例であることに注意されたい。サービスとそのコントラクトの間の適合を検査することに加えて、われわれは、常に、サービスとそのサービスが使用するコントラクトとの間の相互作用におけるスタック状態を検査するスタックネス検証を実行する⁵。

−−−−−−−−−−
⁴ メッセージ型自体は、コントラクト指定の一部としても宣言されるが、ここでは簡単のため省略した。
⁵ これは、例えば、サービスが自明なコントラクトを持ち、それでも、使用するサービスでスタックする可能性があるため必要である。このような場合も、適合検査器によって捕捉され、フラグが立てられる。
−−−−−−−−−−

書店システムの適合分析を、それぞれのサービス実装および関連するコントラクトをＺＩＮＧにコンパイルすることにより実行したところ、２つのＺＩＮＧプロセスが得られたので、それらをわれわれの適合検査器で比較した。適合検査は、合成的に実行された、つまり、コントラクト指定と突き合わせて一度に１つずつサービス実装を検査し、使用されるサービスを表すようにコントラクトを置き換えた。プロセス全体は完全自動である。われわれの適合分析により、以下で簡単に説明する、デッドロックを含む多数の重大なエラーを検出した。以下のリストには、どのコントラクトが検査されたか、定義８のどの条件（［Ｃ１］または［Ｃ２］）に違反したかを示し、また、上述のスタックネス検証の失敗も示している。これらのエラーは、コードを検査する前には見つからなかったものであることを強調しておく⁶。

（１）ＩｎｖｅｎｔｏｒｙＲｅｓｅｒｖａｔｉｏｎ。欠落タイムアウト指定（［Ｃ２］）。コントラクトは、そのイベントループでサービスをタイムアウトにできることを指定できなかった。このため、サービスがタイムアウトの後すべての要求を拒絶するので、適合検査器により即時拒絶失敗が識別されることをもたらした。コントラクトは、Ｔｉｍｅｏｕｔの場合を追加することにより是正された。Ｔｉｍｅｏｕｔイベントは、内部（γ）アクションとしてモデル化され、入力ａに付随したときに、ＺＩＮＧにより、ａ＋γ．０として表される（ここで、タイムアウトの後には何も生じないことを仮定する）。

（２）ＩｎｖｅｎｔｏｒｙＲｅｓｅｒｖａｔｉｏｎ．指定されない繰り返し入力（［Ｃ１］）。前のエラーの修正後、適合検査器がシミュレーション失敗を報告した。問題は、コントラクトで、サービスがメッセージのＣｏｍｕｍｉｔＲｅｓｅｒｖａｔｉｏｎを１回だけ取り、サービスのイベントループを終了することを指定したことにある。しかし、サービス実装では、ＣｏｍｍｉｔＲｅｓｅｒｖａｔｉｏｎの受信後にループを終了すべきなのに終了せず、実装が修正された。

（３）ＳｈｏｐｐｉｎｇＣａｒｔ。スタックネス。図１は、コントラクトのＳｈｏｐｐｉｎｇＣａｒｔおよび修正されたＩｎｖｅｎｔｏｒｙＲｅｓｅｒｖａｔｉｏｎを示している。実装では、ＩｎｖｅｎｔｏｒｙＳｅｒｖｉｃｅおよびＯｒｄｅｒｉｎｇサービスを使用する。適合検査では、サービスがＣｈｅｃｋＯｕｔメッセージを受け取り、その後続けてＣｏｍｍｉｔＲｅｓｅｒｖａｔｉｏｎメッセージをＩｎｖｅｎｔｏｒｙＳｅｒｖｉｃｅに送信し、そしてＡｃｋｎｏｗｌｅｄｇｅｍｅｎｔを受け取るまで待つという状況で、サービス実装がＩｎｖｅｎｔｏｒｙＲｅｓｅｒｖａｔｉｏｎコントラクトでスタックしたことを検出する。これは、ＩｎｖｅｎｔｏｒｙＳｅｒｖｉｃｅがタイムアウトになった場合に、デッドロックを受け取る。他の状況では、タイムアウトの結果、ＳｈｏｐｐｉｎｇＣａｒｔＳｅｒｖｉｃｅから送信された残留メッセージによりスタックネスが生じる。実装は修正された。

（４）Ｉｎｖｅｎｔｏｒｙ。サービス内に実装されない入力（［Ｃ２］）。コントラクトＩｎｖｅｎｔｏｒｙで指定されているが実装されていない入力があると、残留失敗が生じる。実装は是正された。

（５）ＩｎｖｅｎｔｏｒｙＣｈａｎｇｅＮｏｔｉｆｉｃａｔｉｏｎ。特定のメッセージを受信した後、入力が利用できない（［Ｃ２］）。１つの特定の状態において、サービスイベントループ内でメッセージＤｏｎｅを受信すると、サービスＰｕｂｌｉｃＩｎｖｅｎｔｏｒｙＳｅｒｖｉｃｅは、ＩｎｖｅｎｔｏｒｙＰｒｏｃｅｓｓｉｎｇサービスにおける公開加入システムとの通信を終了せずにイベントループを終了するが、コントラクトはこの可能性を反映しない。したがって、そのシステムに対するメッセージは失われる可能性があり、実装が是正された。

−−−−−−−−−−
⁶ コードは、完全には検証されていない。しかし、エラーのいくつかは、通常、検証によっても見つからないことに注意されたい。
−−−−−−−−−−

５ 結論
われわれは、ＣＣＳの新規性のある詳細化関係を提示し、それが通信プロセスのスタックフリーダムの構成検査を行うのに好適であることを示した。適合は、目に見えるアクションおよび安定性が観察可能なラベル付けされた推移システムに直接適用可能であるという利点を有する。スタックネスは、非同期プロセスを検査するのに役立つ、孤立メッセージを考慮することによりＣＳＰデッドロックよりも区別しやすい。われわれは、適合が代替可能性を満たすＣＣＳプロセスに対する前合同であることを証明し、関連するプロセス先行順から区別した。表現力の高いモデル化言語であるＺＩＮＧ用の適合検査器を構築し、分散システムに適用した。

謝辞。われわれは、Ｒｏｂｉｎ Ｍｉｌｎｅｒ氏にはこの論文の草稿についてコメントを寄せて激励してくれたことについて、Ｒａｎｋｏ Ｌａｚｉｃ氏には話し合いの中でいろいろな思いつきを与えてくれたことについて感謝する。われわれは、Ｔｏｎｙ Ｈｏａｒｅ氏がお膳立てしてくれた、ケンブリッジでの２００２年６月のＭｉｃｒｏｓｏｆｔ Ｒｅｓｅａｒｃｈ（Ｅｒｎｉｅ Ｃｏｈｅｎ、Ｐａｕｌ Ｇａｒｄｉｎｅｒ、Ａｎｄｙ Ｇｏｒｄｏｎ、Ｒｏｂｉｎ Ｍｉｌｎｅｒ、およびＢｉｌｌ Ｒｏｓｃｏｅ）およびオックスフォード大学での２００３年の１１月のＣｏｍｐｕｔｉｎｇ Ｌａｂｏｒａｔｏｒｙ（Ｃｈｒｉｓｔｉｅ Ｂｏｌｔｏｎ、Ｍｉｃｈａｅｌ Ｇｏｌｄｓｍｉｔｈ、Ｒａｎｋｏ Ｌａｚｉｃ、およびＧａｖｉｎ Ｌｏｗｅ）のワークショップの参加者たちに感謝する。また、ＺＩＮＧの設計および実装作業に取り組んでくれたＭｉｃｒｏｓｏｆｔ社のＴｏｎｙ Ａｎｄｒｅｗｓ氏にも感謝したい。

参考文献

本発明の一態様によるオーケストレーションシステムの一般的なコンポーネントブロック図である。 開示されている本発明の一態様によりオブジェクト指向環境内でメッセージ受け渡しを容易にするための手順の流れ図である。 本発明の一態様によるコントラクトコンポーネントの一般的なコンポーネントブロック図である。 開示されている本発明の一態様によりコントラクトの宣言を容易にするための手順の流れ図である。 開示されている本発明の一態様によりコントラクト拡張を容易にするための手順の流れ図である。 本発明の一態様によるオーケストレーションコンポーネントの一般的なコンポーネントブロック図である。 開示されているアーキテクチャを実行する動作が可能なコンピュータのブロック図である。 本発明によるコンピューティング環境例の略ブロック図である。

符号の説明

１００ オブジェクト指向環境
１０２ クライアント
１０４ コントラクトコンポーネント
１０６ オーケストレーションコンポーネント
１０８_１ サービス_１
１０８_２ サービス_２
１０８_３ サービス_３
１０８_Ｎ サービス_Ｎ
１０４ コントラクトコンポーネント
３０２ メッセージコンポーネント
３０４ プロトコルコンポーネント
３０６ コントラクト拡張コンポーネント
１０６ オーケストレーションコンポーネント
６０２ スケジュールコンポーネント
６０４ コンパイラコンポーネント
８０２ クライアント（群）
８０８ クライアントデータストア（群）
８０６ 通信フレームワーク
８０４ サーバ（群）
８１０ サーバデータストア（群）

Claims (30)

1. オブジェクト指向およびメッセージ指向言語を統合するシステムであって、
   オブジェクト指向環境における少なくとも１つのサービスへの通信を円滑にするコントラクトコンポーネントと、
   前記コントラクトコンポーネントを解釈するコンパイラコンポーネントとを備えることを特徴とするシステム。
2. 前記コンパイラコンポーネントが前記コントラクトコンポーネントに従ってスケジュールを生成することを円滑にするオーケストレーションコンポーネントをさらに備えることを特徴とする請求項１に記載のシステム。
3. 前記コントラクトコンポーネントは、少なくとも１つの非同期メッセージコンポーネントおよび１つのプロトコルコンポーネントを含むことを特徴とする請求項１に記載のシステム。
4. 前記プロトコルコンポーネントは、
   前記少なくとも１つの非同期メッセージの有効なシーケンスを指定する順序を識別するパターンコンポーネントを含むことを特徴とする請求項３に記載のシステム。
5. 前記コントラクトコンポーネントは、少なくとも１つのメソッドコンポーネント、および前記少なくとも１つのメソッドコンポーネントの有効なシーケンスを指定する順序を識別するパターンコンポーネントを含むことを特徴とする請求項１に記載のシステム。
6. 少なくとも１つの追加メッセージを前記コントラクトコンポーネントに追加するように前記コントラクトコンポーネントを拡張するコントラクト拡張コンポーネントをさらに備えることを特徴とする請求項１に記載のシステム。
7. 前記コントラクト拡張コンポーネントは、少なくとも１つの追加状態を前記コントラクトコンポーネントに追加するように前記コントラクトコンポーネントを拡張することを特徴とする請求項６に記載のシステム。
8. 前記コントラクト拡張コンポーネントは、少なくとも１つの追加トリガを前記コントラクトコンポーネントに追加するように前記コントラクトコンポーネントを拡張することを特徴とする請求項６に記載のシステム。
9. 請求項１に記載の前記システムを実行するためのコンピュータ実行可能命令を格納していることを特徴とするコンピュータ可読媒体。
10. 請求項１に記載のシステムを採用することを特徴とするコンピュータ。
11. 請求項１に記載のシステムを採用することを特徴とするＷｅｂベースの環境。
12. 請求項１に記載のコンポーネントを格納していることを特徴とするコンピュータ可読媒体。
13. 請求項１２に記載のコンポーネントを格納しているコンピュータ可読媒体を含むことを特徴とするコンピュータシステム。
14. オブジェクト指向環境においてメッセージ受け渡しを介して同時実行をサポートする方法であって、
    コントラクトコンポーネントを宣言すること、および
    前記コントラクトコンポーネントを実装することを備えることを特徴とする方法。
15. コントラクトを宣言する動作は、少なくとも１つの非同期メッセージコンポーネントおよび１つのプロトコルコンポーネントを宣言することをさらに含むことを特徴とする請求項１４に記載の方法。
16. 前記コントラクトを宣言する前記動作は、少なくとも１つの非同期メッセージコンポーネントの実行のパターンを指定することをさらに含むことを特徴とする請求項１５に記載の方法。
17. 前記コントラクトを宣言する前記動作は、前記少なくとも１つの非同期メッセージコンポーネントの実行のトリガを指定することをさらに含むことを特徴とする請求項１５に記載の方法。
18. コントラクトを宣言する動作は、メソッドコンポーネントを宣言し、前記メソッドコンポーネントの呼び出しのパターンを指定することをさらに含むことを特徴とする請求項１４に記載の方法。
19. 前記コントラクトを宣言する前記動作は、既存のコントラクトを拡張するコントラクト拡張コンポーネントを識別することをさらに含むことを特徴とする請求項１４に記載の方法。
20. 前記コントラクト拡張コンポーネントを識別する動作は、少なくとも１つの追加メッセージを前記コントラクトに追加することをさらに含むことを特徴とする請求項１９に記載の方法。
21. 前記コントラクト拡張コンポーネントを識別する動作は、少なくとも１つの追加状態を前記コントラクトに追加することをさらに含むことを特徴とする請求項１９に記載の方法。
22. 前記コントラクト拡張コンポーネントを識別する動作は、少なくとも１つの追加トリガを前記コントラクトに追加することをさらに含むことを特徴とする請求項１９に記載の方法。
23. スケジュールを生成するように前記コントラクトコンポーネントをコンパイルすることをさらに備えることを特徴とする請求項１５に記載の方法。
24. 前記のコントラクトコンポーネントをコンパイルする動作は、
    前記少なくとも１つの非同期メッセージコンポーネントを切り分けて、スケジュールの生成を円滑にすること、
    前記切り分けた非同期メッセージコンポーネントをパーティション分割して前記スケジュールを生成すること、および
    前記スケジュールをランタイムアルゴリズムに伝達することをさらに含むことを特徴とする請求項２３に記載の方法。
25. 複数のサービス間の通信を管理するためオーケストレーションコンポーネントを使用する方法であって、
    少なくとも１つのコントラクトを宣言すること、
    それぞれの通信が状態を定める前記少なくとも１つのコントラクトに従ってＷｅｂサービスベースの環境で少なくとも１つのサービスとの通信を開始すること、および
    前記定義された状態を集約することを備えることを特徴とする方法。
26. スケジュールを生成するように前記オーケストレーションコンポーネントを切り分けることをさらに備えることを特徴とする請求項２５に記載の方法。
27. 前記スケジュールをランタイムアルゴリズムに伝達することをさらに備えることを特徴とする請求項２６に記載の方法。
28. 少なくとも１つの前記コントラクトコンポーネントを切り分けて、スレッドコンテキストをブロックすることなく並列ウエイトが発生することを許可することをさらに備えることを特徴とする請求項２６に記載の方法。
29. オブジェクト指向環境における並列処理を円滑にするシステムであって、
    コントラクトを宣言する手段と、
    前記コントラクトを実装する手段とを備えることを特徴とするシステム。
30. 複数のサービスへの伝達をオーケストレートする手段をさらに備えることを特徴とする請求項２９に記載のシステム。
    

Images