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

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

Info

Publication number
JP2006024223A
JP2006024223A JP2005201542A JP2005201542A JP2006024223A JP 2006024223 A JP2006024223 A JP 2006024223A JP 2005201542 A JP2005201542 A JP 2005201542A JP 2005201542 A JP2005201542 A JP 2005201542A JP 2006024223 A JP2006024223 A JP 2006024223A
Authority
JP
Japan
Prior art keywords
contract
component
message
service
statement
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2005201542A
Other languages
English (en)
Inventor
Jason P Allen
ピー.アレン ジェイソン
John L Hamby
エル.ハンビー ジョン
Niklas Gustafsson
ガスタフソン ニクラス
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Microsoft Corp
Original Assignee
Microsoft Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Microsoft Corp filed Critical Microsoft Corp
Publication of JP2006024223A publication Critical patent/JP2006024223A/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/54Interprogram communication
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F17/00Digital computing or data processing equipment or methods, specially adapted for specific functions
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/30Creation or generation of source code
    • G06F8/31Programming languages or programming paradigms
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/52Program synchronisation; Mutual exclusion, e.g. by means of semaphores

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Databases & Information Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Mathematical Physics (AREA)
  • Stored Programmes (AREA)
  • Computer And Data Communications (AREA)
  • Multi Processors (AREA)
  • Devices For Executing Special Programs (AREA)
  • Programmable Controllers (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

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

Description

本発明は、一般的にコンピュータシステムに関する。より具体的には、本発明は、オブジェクト指向環境における言語拡張機能を使用し、メッセージ受け渡し(message passing)、コントラクト、およびオーケストレーションを通じて非同期プログラミングをサポートすることができるシステムおよび方法を対象とする。
同時実行アプリケーション(concurrent application)のプログラミングは、大半のプロ開発者により、難しいものであり、誤りが発生しやすいものであると考えられている。ほとんどのシステム開発者は、このタイプのプログラミングに難儀しているが、その理由の1つは、ほとんどのビジネスアプリケーション開発者の守備範囲外だからである。
同時実行アルゴリズムは、いつでも適切であるとはかぎらないが、当を得た問題の解決に使用するのであれば、パフォーマンスおよびアルゴリズムの簡潔さに関して非常に大きなメリットがある。ワイドエリアネットワークに分散されるプログラムを開発することに対する関心が高まるとともに、通信待ち時間が急激に長くなり、順次実行のコストが急増していることから、同時実行プログラミングツールの必要性が高まりつつある。
しかし、問題の1つは、ほとんどのプログラマから同時実行が利用可能な機能は低水準であり、使いにくいという点である。同時実行がどのようなものであれ、それをサポートするプログラミング言語はわずかである。従来、同時実行をサポートするプログラミング言語は、専用言語であるか、小規模な学術研究機関内でしか使用されない言語である。
J2EEおよび.NETブランドの環境などのオブジェクト指向(OO)フレームワークでは、主流のプログラム設計に対しOOアプローチをとってきた。しかし、共有メモリに重点を置くと、同時実行に対するサポートが複雑になり、アプリケーションプログラミングよりもシステムプログラミング向きのサポートとなる。共有メモリは、同時実行のサポートを簡素化するうえでの主要な障害の1つであると広く認識されている。
したがって、この技術分野には、主流のOO言語に対する同時実行のサポートを付け加え、共存を実装する大きな必要性が存在する。さらに、1つのアドレス空間内で実行できるか、または単一コンピュータ上で複数のプロセス間に分散できるか、またはローカルエリアまたはワイドエリアネットワーク内に分散できるプログラムを、すべてプログラムのコーディングし直しをすることなく、開発できるシステムおよび/または方法に対する未だ満たされていない必要性がある。この態様の中心には、自アルゴリズム(論理的)スレッドを実行する、「サービス」という概念がある。さらに、サービス間のメッセージベースのインターフェースを指定する手段に対する未だ満たされていない必要性もある。言い換えると、アプリケーションプログラミングを簡素化するためにOOおよびメッセージ指向言語を統合する必要があるということである。
メッセージ受け渡しによる従来のサービスは、特定のハードウェアプロセッサ向けに設計され、そのプロセッサでしか動作できない1980年代に開発された専用言語であるOCCAMにより定義される。このプログラミング言語に埋め込まれている形式的プログラム仕様は新しいものではない。例えば、Eiffelは、直接プログラミング言語自体で、制限された形態ではあるがプログラム仕様をサポートする。Eiffelは、Bertrand Meyerにより作成され、同氏の会社であるInteractive Software Engineering(ISE)により開発された高度なプログラミング言語である。
しかし、プロトコル仕様を実装から分離することは、現在のところ利用できない。この分離は、サービス同士の相互作用を抽象化する機能にとって極めて重要である。例えば、BizTalkをベースとする言語であるXLANGは、サービスメッセージ交換パターン全体を1つのプロトコルとして公開する。しかし、この実装は、インターフェースから分離されておらず、コントラクト準拠の静的検証が困難である。
以下では、本発明のいくつかの態様の基本的な内容を理解できるように、発明の開示を簡単に説明する。この発明の開示は、本発明の概要を広範囲にわたって述べたものではない。この発明の開示は、本発明の鍵となる/決定的な要素を示したり、本発明の範囲を定めることを目的としていない。後で述べる詳細な説明の前置きとして、本発明のいくつかの概念を簡略化した形式で述べることのみを目的とする。
本明細書で開示され請求される本発明は、その一態様において、主流のオブジェクト指向(OO)言語で同時実行の高水準の抽象化を直接実現する。これは、複数のサービス間の通信を同時に管理するメカニズム(例えば、オーケストレーション)を利用する非同期メッセージ受け渡しを導入することにより正しい同時実行プログラムを簡単に書けるようにすることを目的とする同時実行モデルを提供する。
一態様では、本発明は、主流のオブジェクト指向言語に同時実行のサポートを追加する。これにより1つのアドレス空間内で実行できるか、または単一コンピュータ上で複数のプロセス間に分散できるか、またはローカルエリアまたはワイドエリアネットワーク内に分散できるプログラムを、プログラムのコーディングし直しをすることなく、開発できるようにする言語拡張が提供される。この態様の中心には、自アルゴリズム(論理的)スレッドを実行することができる、「サービス」という概念がある。したがって、サービスは明示的な同期プリミティブを使用してメモリを共有または同期しない。むしろ、データ共有と同期は、両方とも、メッセージ受け渡しを介して実行される、例えば、一組の明示的に宣言されたメッセージがサービス間で送信される。メッセージは、共有されるデータおよび同期を実現するメッセージ交換のパターンを含むことができる。
他の態様では、サービス間のメッセージベースのインターフェースを指定する方法、例えば、コントラクトが用意される。他の詳細をインターフェース(例えば、メソッド)およびコントラクトに追加するメカニズムも用意される。このような詳細は、形式的プロトコル定義を与えることができるメソッド呼び出しの順序付け(インターフェースの場合)、またはメッセージ(コントラクトの場合)を記述する機能を備える。
本発明の他の態様は、異なるコントラクト関係の革新技術を対象とする。コントラクトは、インターフェースのメンバの許容可能な呼び出しシーケンスの形式的指定である。これらは、双方向のメッセージベースのインターフェースとともに使用する場合に特に力を発揮するが、適用は、本明細書で説明されているように、従来のOOインターフェースにも及ぶ。例えば、本発明の一態様は、動的検証アルゴリズムの実装に関係する。より具体的には、この態様は、コントラクトを強制する実行時アルゴリズムに関係する。したがって、式のパターンに関係なく、実行時表現は、すべての正当なコントラクト状態を符号化する非決定論的有限状態マシンであってよいとも考えられる。そこで、この状態マシンを使用して、コントラクト仕様と突き合わせてメソッド呼び出しまたはメッセージの正当性を検証することができる。
本発明の他の態様は、OO言語で明示的に宣言されたメッセージの導入に関係する。メッセージ指向言語を採用する従来のシステムが知られているが、有向ペイロード伝送メッセージ(directed,payload−carrying,messages)の明示的宣言は、OO言語との組合せであるため、新規性がある。特に、本明細書で説明されているように、メッセージ受け渡しの概念は、OO言語には新しいものであり、従来の概念とかなり異なる。プロトコルをメソッドまたはメッセージの時間的な順序付けのメソッドまたは有向メッセージの集合として表現することについては、他の態様により説明される。より具体的には、この革新技術のこの態様は、OO言語(例えば、VB.NETブランドの環境)に形式的コントラクト(formal contract)を追加することに関係する。宣言されたメッセージまたはメソッドをパターンの字母として使用することにより、通信プロトコルの単純ではあるが十分に形式的なプロトコル定義を設定することができる。
コントラクトの概念は、オブジェクト指向言語に関して同じ種類のソフトウェア再利用を継承として実現するメカニズムを付加して増強することができる。特に、主要な概念の1つに、コントラクト拡張(extension)があり、これにより、コントラクトの世代間の非対称的互換性(asymmetrical compatibility)が得られる。例えば、この概念を使用すれば、コントラクトの旧バージョンを使用しているクライアントは、新しいバージョンを使用するようにすでに更新されているサービスと通信することができる。
さらに、本発明は、オーケストレーションを対象とする。したがって、メッセージ指向プログラムの非同期的なニーズを取り扱うために、本発明の一態様では、「安全な」並列処理のいくつかの概念をサポートする言語構文を加える。このモデルは疎結合であるため、プログラムコンポーネントの分散をサポートすることができる。非同期アプリケーションをプログラムする際のプログラマの生産性、開発されたアプリケーションの信頼性、およびアプリケーションソースコードの総合的な可読性の高さが利点の一部としてあげられる。
理解しやすくするために、本発明の説明されている態様は、Service、Send、Receive、Select Receive、Wait、Split、Timeout、Inner Services、Begin、Catch Receive、Accept、Split Select Receiveというキーワードに関係するVisual Basic(VB)を対象とする。併せて、この新しい言語構文は、メッセージ同士を並列に処理するためのモデルを実装することができる。本発明は、疎結合同時実行と密結合並列処理用のコルーチンとをサポートすることができると考えられる。これらの構文については、本書の後の方で詳しく説明する。
本発明のいくつかの態様によるコンパイラアルゴリズムを使用することができる。特に、スレッドのコンテキストをブロックすることなく並列ウエイト(parallel waits)が発生するようにコルーチンベースのコードを複数のコード断片に細分するコンパイラのアプローチは、本発明の他の新規性のある態様である。メッセージの到着を待っている間に現在のスレッドを潜在的にブロックする可能性のあるソースコード内のそれぞれの場所を切り離すことにより、複数のそのような場所で並列待機するか、または代替として、スレッドコンテキストで他の何らかの計算を続行するようにできる。前記の関係する目的を達成するために、本発明のいくつかの例示されている態様について、以下の説明および付属の図面に関して本明細書で説明される。ただし、これらの態様は本発明の原理を採用する様々な方法の少数のみを示しており、本発明はこのような態様およびその等価物すべてを含むことを意図している。本発明の他の利点および新規性のある特徴は、図面を参照しつつ本発明の以下の詳細な説明を読むと明白になるであろう。
次に、本発明は、本明細書全体を通して類似の番号が類似の要素を示すために使用される図面を参照しつつ説明される。以下の説明では、説明を目的として、本発明を完全に理解できるようにする多数の具体的詳細を述べている。しかし、本発明は具体的詳細を知らなくても実施できることは明白であろう。他の場合には、本発明を説明しやすくするために、よく知られている構造および装置がブロック図形式で示されている。
本出願で使用されているように、「コンポーネント」、「システム」および「メカニズム」などの用語は、コンピュータ関連のエンティティ、つまりハードウェア、ハードウェアとソフトウェアの組合せ、ソフトウェア、または実行中のソフトウェアのいずれかを指すことを意図されている。例えば、コンポーネントとして、プロセッサ上で実行されているプロセス、プロセッサ、オブジェクト、実行可能ファイル、実行スレッド、プログラム、および/またはコンピュータなどがある。一例として、サーバ上で実行されているアプリケーションとサーバは両方ともコンポーネントであってよい。1つまたは複数のコンポーネントを1つのプロセスおよび/または実行スレッド内に常駐させることができ、またコンポーネントを1台のコンピュータにローカルとして配置し、および/または2台以上のコンピュータ間に分散させることができる。
以下では、本発明の様々な態様について説明する。本開示はVisual Basic(VB)環境で本発明のシステムおよび方法を採用する態様に関して説明されているが、本明細書で開示されている概念は、本発明の精神、範囲、または機能から逸脱することなくオブジェクト指向(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)を導入する言語メカニズムが示されている。しかし、これらのメカニズムは、実際には、同時実行ではなく同時実行待機(concurrent waiting)を実現する。サービス108およびオーケストレーションコンポーネント106の組合せにより、競合状態および同期しないメモリアクセスの危険を冒すことなく同時実行および非同期の動作が可能である。本発明により、2つのサービス間のメッセージ交換は、コントラクトコンポーネント104により管理される対話として生じる。コントラクトコンポーネント104は、サービス108のメッセージング動作の仕様を定め、やり取りする相手のサービスの実装にアクセスせずにある種の形態の正しさ(例えば、メッセージ交換のパターンへの適合、デッドロックからの解放)について個々のサービス108をチェックすることができる。したがって、サービスの動作を理解する際の主要なアーチファクトはその実装されたコントラクトであることは理解されるであろう。
コントラクト
図3を参照すると、本質的に、コントラクト104は、より豊富な意味を持つ非同期メッセージ受け渡しのインターフェース宣言として定義することができる。つまり、メッセージコンポーネント302を使用して一組のメッセージ(またはメソッド)および許容可能なメッセージ交換のシーケンスを記述するオプションのプロトコルまたはパターンコンポーネント304を指定するということである。さらに、コントラクトコンポーネント104は、既存のコントラクトコンポーネントを拡張するコントラクト拡張コンポーネント306を使用することができる。
図4は、本発明の様々な態様によりコントラクトを宣言する方法202を例示する図である。本明細書で説明されているように、コントラクトの宣言は、複数のメッセージまたはメソッドだけでなくオプションのパターンも定義することを含むことができる。図4を参照し、402に進むと、そこではコントラクトタイプが宣言されている。特に、VBの実施例では、コントラクト宣言は、コントラクト上のクライアントパースペクティブおよびサーバパースペクティブを表す2つのVB型を作成する。例えば、宣言「Contract C」は、型「C」(クライアントパースペクティブを表す)および型「Implements C」(サーバパースペクティブを表す)を作成する。例えば、以下は、アラームクロックサービスのコントラクト例である。
Figure 2006024223
さらに、コントラクトを拡張しスヌーズ機能を追加したアラームクロックサービスのコントラクトを以下に示す。
Figure 2006024223
状況を示し、理解しやすくするために、コントラクトの文法および意味について以下で説明する。例を以下に示す。
Figure 2006024223
Figure 2006024223
Figure 2006024223
図3を参照しつつすでに説明したように、コントラクトではメッセージの集合302、およびオプションにより、許容可能なメッセージ交換シーケンスを記述するパターン304、および/または図3に例示されているようなコントラクト拡張306を指定できる。パターン304が指定されていない場合、指定されたすべてのメッセージシーケンスが使用可能であることに留意されたい。コントラクト拡張メカニズム306は、エラボレーテッドコントラクト(elaborated contract)を使用して分類されたコネクタとエラボレーティングコントラクト(elaborating contract)を使用して分類されたコネクタとの間の対話が可能であるようにコントラクトに追加するメカニズムである。
図4を再び参照し、404に進むと、そこで、メッセージを宣言できる。次に、406で、オプションによりパターンを指定できる。406で指定されたパターンは、状態マシンとして指定できる。これらの状態は、StateTransitionStatementGroups内のラベルで指定できる。上述のアラームクロック例では、開始状態は「開始(start)」という名前である。メッセージの送受信とともに他のコントラクトの実行により、状態マシンに遷移が引き起こされる。StateTransitionStatementGroupが複数のStateTransitionStatementを含む場合に、パターンがグループ内にそれらの遷移の1つを許す。
408で、パターンに関連して使用されるトリガを定義することができる。特に、MessageTransitionStatement内の矢印の左にある名前はトリガであり、メッセージまたはコントラクトの名前とすることができる。次に、410で、ターゲットが識別される。矢印の右にある識別子はターゲットであり、状態の名前とすることができる。トリガがない場合、ターゲット状態のトリガが発生すると遷移が生じる。トリガがコントラクトの場合、その効果は、コントラクトのパターンの新しいインスタンスの実行である。複数のターゲットがある場合、この遷移はすべてのターゲットに対し並列に行われる。この状況を分割遷移(split transition)と呼ぶ。ターゲットがImmediateの場合、遷移は、最後のトリガが完了したときではなく最初のトリガが開始したときに発生する。これは、特に、トリガがコントラクトの場合に有用であることに留意されたい。
一実施例によれば、状態
Figure 2006024223
Figure 2006024223
と等価である。
同様に、状態
Figure 2006024223
Figure 2006024223
と等価である。
さらに、状態
Figure 2006024223
Figure 2006024223
と等価である。
当業者であれば、「Or」、「And」、および「Then」は、式の構文内のそれぞれ「Or」、「And」、および「AndAlso」と同じ優先順序関係を持つことを理解するであろう。
一態様では、「In Message」または「Out Message」として与えられたトリガは、適切な方向に進行するコントラクト内で宣言されたメッセージを表すことができる。他の態様では、「Any In Message」または「Any Out Message」として与えられたトリガは、適切な方向に進行するメッセージを表すことができ、コントラクト内で宣言されていないメッセージとすることができる。
与えられた状態は、与えられたトリガに関して高々1回の遷移を行うことができる。本発明のシステムおよび方法によれば、状態がメッセージについて遷移する場合、その状態はそのメッセージを受け付ける。状態が複数のメッセージを受け付けることができ、1つの状態により受け付けられるメッセージは必ずしもすべ同じ方向に進行するわけではない。例えば、すべてのメッセージが同じ方向に進行しない場合、反対方向に進行する状態Sにより受け付けられるすべてのメッセージを受け付けるわけではない状態Sにより受け付けられるメッセージに対するターゲット状態はそれらのメッセージを無視する。
「終了(End)」への遷移で、状態マシンの現在の行が終了する。「停止(Stop)」への遷移で、状態マシンの現在の行が終了する。分割遷移がない場合、「終了」および「停止」は等価であることに留意されたい。
図4を再び参照すると、本発明のシステムおよび方法により、接続を通じてメッセージの送受信を行うことができる。接続は、402で宣言されたコントラクト型である型を持つデータである。このコントラクト型は、コントラクトに名前を付けることにより指定できることは理解されるであろう。その一方で、接続は、コントラクト実装型である型を持つデータとすることができる。コントラクト実装型は、コントラクトの名前の前に指定「Implement」を付けることにより指定することができる。コントラクト型を持つ接続は、Inメッセージを送信し、Outメッセージを受信することができる。コントラクトImplements型を持つ接続は、Outメッセージを送信し、Inメッセージを受信することができる。
分割遷移
410で、状態遷移が複数のターゲットを持つ場合、その遷移を並列でのすべてのターゲットへの分割遷移と呼ぶ。例えば、分割遷移は、その分割遷移からの一部の経路がSに収束する場合に部分的に状態Sでマージし、全部の経路が収束する場合に完全にマージする。状態Tが分割遷移の直接または間接ターゲットの場合、分割遷移がTのところでまたはTの前で完全にマージしていない限り、分割遷移を通らないTへの経路はありえない。分割遷移が状態Sでマージする場合、Sからの遷移は、その分割遷移からのすべての経路がSに到着するまで発生しえない。簡単に言うと、分割/マージは適切にネストし、分割/マージの真ん中への遷移はありえない。
例を以下に示す。
パターン
Figure 2006024223
は、メッセージシーケンスM1、M1、M2、M4、M3、M3、M5を受け入れる。S1を含むそれぞれの分割遷移では、M3がマージ状態S3に遷移する必要があり、したがって等しい数のM3およびM1メッセージがありうる。
パターン
Figure 2006024223
では、M1をCon1のメッセージと混ぜることができるが、これは、M2がCon1の完了後に発生することを必要とする。このパターンは、さらに、「終了」をマージ状態とすることができることも例示していることに留意されたい。
コントラクト拡張
本発明のシステムおよび方法によれば、412で、コントラクト拡張メカニズム(例えば、図3の306)を採用し、エラボレーテッドコントラクトを使用して分類されたコネクタとエラボレーティングコントラクトを使用して分類されたコネクタとの間の対話が可能であるようにコントラクトに追加することができる。対話の一方の側のみが、使用するコントラクトに関する選択権を有する。決定は、拡張の型によって行われる。
文法および意味の例は以下の通りである。
Figure 2006024223
ここで、Extendsステートメント内の名前を、包含コントラクト(containing contract)でないコントラクトまたは包含コントラクトを拡張または精緻化するコントラクトの名前とすることができる。
コントラクト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を有するが、サーバサイドコネクタは型Implements CTを有する。
オーケストレーション
さらに、Split演算は、複数の実行行を生成し、そのどの行も出力するまで実行され、出力されたときに、他の実行行を実行できる。様々な言語演算において、実行行に結果を出力させることができる。そのようなものには、Receive(例えば、メッセージの到着を待つ)、およびWait(例えば、特定の時間間隔の間待つ)がある。
一組のメソッドは、オーケストレーションユニットを形成するか、またはそれらのメソッドの1つの出力結果でのメソッドでの1行が実行可能であれば、オーケストレートするということができる。これにより、呼び出しが戻るまで実行がメソッド呼び出しを通り過ぎるということはないことに注意されたい。オーケストレーションクラスのインスタンスメソッド(基本および派生クラス内のメソッドを含む)は、所定のインスタンスについてオーケストレートする。
オーケストレーションクラスは「orchestration」修正子を付けて宣言される。オーケストレーションクラスは、共有メソッドまたはプロパティを持ちえない。この態様によれば、オーケストレーション演算はVBステートメントであり、いくつかの制約条件に従うが、どのメソッドにも出現しうる。
図2を再び参照すると、204で、Sendステートメントは以下のように構成することができる。
Figure 2006024223
この態様によれば、Sendステートメントは、オプションの式である、特定のコネクタを通じてメッセージを送信する。コネクタの式が存在しないことで、メッセージが一次コネクタを通じて送信され、サービス内でのみ許可されることを意味することができる。このコネクタの式をコントラクトまたはコントラクト実装型とすることができることは理解されるであろう。
存在する場合、識別子は、コントラクトのメッセージの名前とすることができ、そのメッセージは適切な方向を持ちうる。メソッド呼び出しと同様に、引数は、メッセージのパラメータについて型検査される。
Messageキーワードが存在する場合、この式は、System.MessageBus.Messageに変換可能であり、送信するメッセージオブジェクトを識別する。
同様に、206で、Receiveステートメントは以下のように構成することができる。
Figure 2006024223
Receiveステートメントは、特定のコネクタを通じてメッセージを受信することができ、メッセージが到着するまでブロックする。コネクタの式が存在しない場合は、メッセージが一次コネクタを通じて受信され、サービス内でのみ許可されることを意味する。コネクタの式は、コントラクトまたはコントラクト実装型とすることができ、識別子は、もし存在すれば、コントラクトのメッセージの名前を指定することができ、メッセージは適切な方向を識別することができる。Receiveステートメントで宣言されたパラメータは、ローカル変数宣言と似たスコープに入る。さらに、Receiveステートメントで宣言されていないパラメータは、別の場所でローカル変数として宣言することができる。
Messageキーワードが存在する場合、関連するパラメータは、System.MessageBus.Messageとして宣言することができ、Receiveで受信メッセージオブジェクトをローカル変数に割り当てることができる。Messageキーワードが存在し、特定のメッセージ名が与えられていない場合、Receiveは、フィルタ式(filter expression)がもし存在すればそれを満たすメッセージを受信することができる。
そのうえ、存在する場合、Receiveの中のWhen式がBooleanフィルタとして動作する。フィルタ式が存在する場合、そのフィルタがTrueに評価されればメッセージが受信され、そうでなければ、他の何らかのReceiveがそれを消費するまで無視される。フィルタ式は、そのフィルタ式が付けられたreceive句のパラメータおよび受信されたメッセージオブジェクトのメンバにアクセスすることができるが、他の非定数宣言にはアクセスできない。フィルタ式が存在しないことは、常に値「True」を持つフィルタ式と等価である。
例えば、
Figure 2006024223
の形のReceiveステートメントは
Figure 2006024223
に等価である。
Waitステートメントは以下のように構成できる。
Figure 2006024223
Waitステートメントは、型System.TimeSpanとすることができる式により与えられる指定間隔の間実行をブロックする。Waitステートメントを使用すると、間隔が0であっても、1つの実行行で出力できる。
Waitステートメントとして
Figure 2006024223
形のステートメントは
Figure 2006024223
に等価である。
注意:Threading.Thread.Sleep()は、オーケストレーション内の他の行を実行することを許さずにスレッドをブロックできるので、オーケストレーションコードの内部では使用されないことが重要である。
受信されると、遷移を引き起こすことができる。Beginステートメントは以下のように構成できる。
Figure 2006024223
識別子は、ローカル変数として宣言することができる。変数の型は、コントラクト型またはコントラクト実装型とすることができる。初期化子(initializer)は存在できる。
Beginステートメントは、指定されたコントラクトにより管理される対話の開始を待つ。当業者であれば、Beginステートメントは一種のインラインサービスを表すことを理解するであろう。このような対話は、他のコード本体がそのコントラクト型の逆のコネクタを作成し、その後そのコネクタを通じてメッセージを送信するときに開始する。対話が開始すると、初期化子が評価され、その値が変数に代入され、実行が続く。
Beginは、部分対話の相関関係を求めるためのメカニズムを提供する。相関関係のある部分対話に関し、コネクタの初期化は、コネクタを単独の引数として持つNew式である。接続の他方の側のコネクタは、コネクタを単独の引数として持つNew式により作成済みであろう。その上、引数として与えられた2つのコネクタも接続されていることであろう。
Beginステートメントとして
Figure 2006024223
形のステートメントは
Figure 2006024223
に等価である。
最後に、そのメッセージは、208で受け入れることができる。そこで、Accept State Statementは以下のように構成できる。
Figure 2006024223
AcceptStateStatementは、接続が特定のコントラクト状態に遷移するまで待機する。コネクタの式が存在しないことで、状態が一次コネクタを通じて受け付けられ、サービス内でのみ許可されることを意味することができる。コネクタの式は、コントラクトまたはコントラクト実装型とすることができ、識別子で、コントラクトの状態パターンの状態に名前を付けることができる。
Accept状態ステートメントは、メッセージを消費しない。特に、状態遷移を引き起こしたメッセージは消費されない。ブロック解除には、状態遷移が必要である。Accept状態ステートメントが開始したときに接続がすでに名前付きの状態に入っている場合、Accept状態ステートメントは、接続がその状態に再入するまで待機する。
Accept StateステートメントがSelect Receiveステートメントの一部としてだけでなく、catch acceptステートメントの一部としても、特に有用であることは理解されるであろう。
Accept状態ステートメントとして
Figure 2006024223
という形のステートメントは
Figure 2006024223
に等価である。
Select Receiveステートメントは以下のように構成できる。
Figure 2006024223
SelectReceiveステートメントは、メッセージの集合(それぞれ異なるコネクタを通る可能性がある)の1つ(または複数)を受信することができ、および/または1つまたは複数の対話を開始し、および/または1つまたは複数の接続の状態を受け入れるか、またはタイムアウトになり、(複数の)メッセージ/(複数の)対話/(複数の)状態に関連付けられたコード本体、またはタイムアウトを実行することは理解されるであろう。タイムアウト式は、タイムスパンを示さなければならない。
複数のCaseReceiveClauseがCaseReceiveStatement内に存在する場合、すべての句の条件が満たされることができ、条件に関連付けられたコード本体の実行がトリガされる。
Splitステートメントは以下のように構成できる。
Figure 2006024223
Splitステートメントは、実行を適当に複数の論理実行行に分割することができる。これらの実行行は、実行行でメッセージの待機をブロックしたときに必ず次のブロック解除された行が実行されることを除き、語彙順序で順次実行することができる。Splitステートメントのどの2行も同時実行されないことは理解されるであろう。Splitの1行内にあるReceiveステートメントは、Splitの他の行から送信されたメッセージに対する応答を受信することはできない。当業者であれば、これにより特定のメッセージに対する応答を相互に関連付けることができることを理解するであろう。
Split For Eachステートメントは以下のように構成できる。
Figure 2006024223
SplitForEachStatementGroupの本体は、各反復がSplitStatementGroupの別々の1行であるかのように実行することができる。コレクションを通る完全な反復は、本体の実行前に実行できる。
Split Select Receiveステートメントは以下のように構成できる。
Figure 2006024223
Split Select Receiveステートメントは、受信されたメッセージ、開始された対話、およびタイムアウトを処理する実行行をいくつでも自動的に作成する。
Split Select Receiveステートメントの
Figure 2006024223
という形は、
Figure 2006024223
と微妙にまたかなり異なっているが、類似している。
Split Select Receiveステートメントは、1行が終了するのを待つのではなく、1行が出力する場合に必ずアクティブにできる。実行行でSplit Select Receiveステートメントの外に制御を移すと、Split Select Receiveステートメントの他のすべての行を終了することができる。
Catch Receiveステートメントは以下のように構成できる。Tryステートメントは、メッセージを受信するハンドラを指定できる。この概念を実装するために、新しい形式のCatchステートメントを使用することができる。
Figure 2006024223
Catch Accept Stateステートメントは以下のように構成できる。Tryステートメントは、接続の状態を受け付けるハンドラを指定できる。この概念を実装するために、新しい形式のCatchステートメントを使用することができる。
Figure 2006024223
新しいExitステートメントを考える。例えば、新しいexitタイプとしてLineとSplitが考えられる。これらは、Split、Split For Each、およびSplit Select Receiveステートメント内で適用され、他の場所では使用できない。Exit Lineステートメントは、Split内の実行行を終了させることができる。Exit Splitステートメントは、Splitを抜けて、Splitの他のすべての行を終了させることができる。
何らかの形のSplitを終了する制御権の移転が他にあればそれらは、Exit Lineの意味ではなく、Exit Splitの意味を持ちうる。
サービス
図2を再び参照すると、次に、コントラクトは210で実装される。本発明によれば、サービス(例えば、図1のサービス108)は、コントラクトの実装を備える。サービスは、サービスのコントラクトの開始メッセージを受けとると、自動的にインスタンス化される。サービスがそのコントラクトを実装するために使用するコネクタは、自動的に初期化され、メッセージの送受信に暗黙のうちに使用することができ、したがって、「Primary」と明示的に呼ぶことができる。説明されている態様によれば、サービスは、パラメータを持たず、したがって結果を返さない「Run」という名前のインスタンスメソッドを持つことができ、このサービスをアクティブ化すると、Runを呼び出す。
サービスは、RuntimeServiceから直接的にまたは間接的に派生するオーケストレーションクラスである。基本クラスが指定されていない場合、これは暗黙のうちにRuntimeServiceである。
再びすでに提示されているアラームクロック例を参照すると、上述のアラームクロックコントラクトを実装するサービスは、以下のように構成できることがわかる。
Figure 2006024223
さらに、以下では、サービス例は、前の例のスヌーズアラームクロックコントラクトを実装するように構成されている。
Figure 2006024223
次にサービスの文法および意味については、以下の通りである。
Figure 2006024223
上記によれば、サービスは、1つのImplementsステートメントと任意のMessageステートメントの両方を持つことはできない。しかし、Implementsステートメントが存在する場合、1つあり、それは単一の型に名前を付けることができ、その型はコントラクトとすることができる。
サービスは、コントラクトを実装する暗黙の一次コネクタを備えることができる。実装されたコントラクトは、Implementsステートメントで名前を付けることができる。サービスがImplementsステートメントなしで宣言されている場合、そのサービスにおいて、その一次コネクタを通ることができるメッセージを宣言することができ、パターンはサービスのメソッドから派生される。つまり、サービスはどれも、コントラクトを実装するということである。
一次コネクタは、サービス内でPrimaryとして利用可能である。コネクタの式がSendまたはReceiveステートメントから省略された場合、コネクタは、暗黙のうちにPrimaryとすることができる。
サービスを呼び出すと、サービスの実装されたコントラクトとして分類されているコネクタの新しいインスタンスを返す。
本発明のより一般的な説明に入るが、n層または一般的に分散環境におけるクライアントおよびサーバのことを話す場合、混乱を避けるために用語を十分厳密に定義することが重要である。例えば、VB環境では、「サービスクライアント」は、メッセージが送信されても開始されないオーケストレーションオブジェクトのことである。つまり、サービスクライアントは、他の何らかの方法で起動することができる。その一方で、「サービス」は、メッセージが送信されることによって作成されるオブジェクトである。「サービス」を起動する方法は他にないということは理解されるであろう。ある程度ゆるやかな概念として、「クライアント」は、サービスとの通信を開始する、サービスであろうとサービスクライアントであろうと、コードの断片のことである。
コントラクト
再び一般的にコントラクトについて言及すると、コントラクトはプロトコルおよびそのメッセージを指定するためにOO言語(例えば、VB)で使用することができる。この説明では、以下に示すようなコントラクトインポートステートメント、メッセージ宣言ステートメント、および単一パターン定義ステートメントの3つの部分を重点的に取り上げる。
Figure 2006024223
上記は、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に関して識別することができることは理解されるであろう。一態様では、そのような遷移は、メッセージによりトリガされる。他の態様では、それらのメッセージは、複数のメソッドまたはインポートされたコントラクトにより表すことができる。
例を以下に示す。
Figure 2006024223
上述のように、「Request Then Response」という句は、遷移トリガであり、「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)である。
クライアント互換コントラクトは、クライアントに知らせずに、サービスを旧いコントラクトから新しいコントラクトにアップグレードできることを意味する。つまり、旧いコントラクトを使用しているクライアントは、決して、新しい状態への遷移をトリガするメッセージを送信しないということである。その一方で、より新しいコントラクトを認識するクライアントは、サービスがその新しいコントラクトをサポートしている場合のみそのコントラクトを利用することができる。したがって、この関係は非対称互換であることは理解されるであろう。
その一方で、コントラクトがサービス互換である場合、クライアントは、新しいコントラクトを使用するようにアップグレードすることができ、旧いコントラクトまたは新しいコントラクトのいずれかをサポートするサービスとの対話を持ち続ける。
以下に、すでに提示されている要求/応答例の修正バージョンを使用した例を示す。
Figure 2006024223
クライアント互換の例:
Figure 2006024223
上のコード例に示されているように、クライアントのみが旧いコントラクトを認識している場合でも、新しいメッセージがまったく送信されない限り、コントラクトは交換可能であるため、新しいコントラクトをサポートするサービスに接続することができる。上に示されているように、サービスは、旧いコントラクトを使用するクライアントと新しい特徴を単純に利用しないだけのクライアントとの違いを区別することはできない。サービス互換の例:
Figure 2006024223
ここで、サービスは、既存のコントラクトを超えるかどうかを決定することができる。したがって、アップグレードされたクライアントは、サービスが旧いコントラクトを使用するのか、それとも新しいコントラクトを使用するのかを見分けることはできない。拡張されたパターンでは、新しい情報のみ、つまり新しい状態、および既存の状態に対する新しいトリガがリストされることに注意されたい。これは、エラーの発生源を回避し、明確さが必要な場合は、旧いコントラクトパターンをコメントとして含めることができる。
コントラクトAは、ホストされているコントラクトを追加し、メッセージを追加しないことにより、コントラクトBを拡張することができることは理解されるであろう。この場合、AはBと対称的互換である。コントラクトのホスティングについては、本明細書の後の方で詳述する。
コネクタ
コントラクトを使用することにより、それらを参照するものを宣言することができる。例示されている態様によれば、他のコードとの通信のためにVBオーケストレーションベースのコードで使用するオブジェクトは、「Connector」と呼ばれる。
型に関する限り、Connectorはコントラクト参照型である。Connectorには風変わりなところがある。例えば、Connectorは、その型の一部である明確に定義されたコントラクトパースペクティブを持つ。いずれも、コントラクトの実装側、または使用側を表す。実装側コネクタを使用側コネクタに、またその逆にも、割り当てることはできない。これらの規則に従うと、コネクタをどのように作成するか、それが実装側であるか使用側であるかをどのように定義するのかについて不思議に思うのももっともである。
コネクタは、ランタイム(例えば、VBランタイム)により定義することができるコネクタファクトリを使用して作成することができる。ほとんどのコネクタファクトリは、サービスURLまたは他のコネクタから作成される。
Figure 2006024223
URIは、ここでは、サービス参照と呼ばれる。これは、コンフィギュレーションファイル内に保持される何らかのよく知られているURIとすることができ、あるいは他の何らかのブローカサービスにより実行時にまとめることも可能である。例えば、最もよい取引の場所を決定し、その卸売業者へのURIを要求者側に送り返す卸売業者入札サービスが考えられる。
コネクタファクトリが用意されると、コネクタファクトリクラス内に組み込まれる対話演算子を使用してConnectorを簡単に作成できる。
Figure 2006024223
このステートメント例では、コネクタファクトリによりアドレッシングされ、その一次コネクタ上に「CtRequestResponse」を実装することができるサービスを参照するパースペクティブ使用コネクタを作成する。このようなコネクタファクトリの使用により、使用側コネクタを生成することができる。
コネクタファクトリは、以下のように、実装パースペクティブのコネクタに直接バインドすることもできることは理解されるであろう。
Figure 2006024223
この態様は、両方の側が同じアプリケーションドメインにあり、分離される必要がないことがよく知られている状況では有用な場合がある。分散されないようにするコードをアプリケーションに追加する必要があるので、一般的には、推奨されないが、特別な場合のパフォーマンスに関しては有用である。前の例は、パースペクティブ使用コネクタである。
他方で、実装側コネクタは、2つの点で異なるように宣言することができる。特に、コネクタ名は、キーワード「Implements」で修正することができ、また初期化子の式は、以下のように引数なしのコントラクト呼び出しでなければならない。
Figure 2006024223
パースペクティブ使用コネクタが初期化されると、これは、対応する実装側コネクタにバインドされるが、実装側コネクタは、バインディングを開始せず、したがって、サービス参照をパラメータとしては必要としない。そのため、その結果得られるコネクタは、作成された後バインド解除され、何らかの使用側コネクタが新しいコネクタにバインドされるまでメッセージの送信には使用できない。
サービスは、すでに定義されているように、「一次」コネクタと呼ばれる暗黙の実装側コネクタを持つことに注意されたい。これは、サービスが起動される前にランタイムアルゴリズムにより作成され、「Primary」フィールドとしてスケジュールに利用することができる。メッセージの送信および受信の際に、一次コネクタは、参照されているコネクタがなければ暗黙のうちに含まれるため、実際に一次コネクタを明示的に参照するコードを見ることは滅多にない。以下で詳しく説明するが、一次コネクタは、多重化のためサービス参照を作成する場合に使用することができる。
コネクタは、参照型の変数が宣言できる場合に必ず宣言することができる。例えば、コネクタは、VBモジュールなどでは、ローカル、パラメータ、および/またはフィールドとして宣言することができる。これらは、オブジェクト参照と同様に、参照により受け渡され、他の変数にコピーされるようにできる。本発明の一態様によれば、コネクタのパースペクティブはいっさい変更できない。さらに、コンパイラでは、強固な分類によりこれを保証することができる。したがって、この態様では、コネクタ、または一般的にはサービスを定義するか、または使用するどのようなソースファイルにおいても「Option Strict Off」を使用することは許可できない。
セッション
本発明のオーケストレーションに関する新規性のある一態様では、スレッド、プロセス、またはスケーラブルなマルチスレッドアプリケーションに関する典型的な課題である他の態様に関する問題を軽減することができる。適切な取り扱いと予見とにより、スレッドおよびプロセスの分離は、アプリケーションの開発問題ではなく、アプリケーションの分散および管理問題となりうる。
しかし、非分散アプリケーションに関して通常は問題とならないが、VBオーケストレーションには本質的である概念の1つに、セッションという概念がある。
以下の例は、理解を助けるために掲載する。インターネットを使用して金融機関サイトでショッピングまたはアクセスを行い、口座情報または支払い請求書にアクセスしたことのあるユーザは、分散アプリケーションの意味でのセッションに慣れていることであろう。特に、電子商取引サイトがアクセスされ、商品がショッピングカートに追加されたり、「My Account」ページがアクセスされたときに、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に、コントラクトは、1)Implementsステートメントで名前による指定、または2)スケジュール本体からの派生の2つの方法で定義することができる。前者の例を以下に示す。
Figure 2006024223
ここで、コントラクトは、すでに説明されている要求/応答である。例えば、サービスは、株価表示器記号を文字列として受信し、最後の売買での価格の文字列表現で応答する。もちろん、応答に対し異なるデータ型を使用することもよい考えであろうが、ここで重要な点は、適切なコントラクトをどのように設計するかではなく、サービスでコントラクトをどのように使用するかである。
サービスは、使用側コネクタをサービス起動直前に作成された実装側コネクタにバインドするサービスにメッセージを送信することによりサービスを呼び出すクライアントにより常に開始される。
コントラクトおよびスケジュールを指定し、多数のサーバ上の多数のプロセスで利用可能にできる、サービス定義、およびそのサービスの特定のセッションを表すサービスインスタンスを別にすることが重要である。
サービスは、型定義であり、サービスインスタンスはオブジェクトであることは理解されるであろう。しかし、実際には決してサービスインスタンスへの参照を持つ(または使用することができる)わけではないので、この関係を見ることはときに困難である。サービスは、コネクタを介してのみ相互作用する。メッセージングがサービスと相互作用する単一の手段である場合に限り、拡張可能なアプリケーション設計をシステムでサポートするために必要な方法で再配置または複製することができる。したがって、サービスは、「New」式を使用してコンストラクタを定義すること、または割り当てることはできない。
サービスが実装するコントラクトを指定する第2の方法では、コンパイラを使用してスケジュールに含まれるコードからそのコントラクトを派生させる。ここで、コンパイラは、コードを解釈するためにコードを切り分ける。つまり、コントラクト定義を書かなくてもよいということである。このメカニズムを使用するために、一次コネクタ上で使用されるメッセージを宣言するだけである。そのようなサービスのコントラクトを使用してコネクタを作成できるようにするために、そのサービスに対し派生するコントラクトには、「<service−name>.Contract」という予測可能な名前を付けることができる。
Figure 2006024223
しかし、すべて便宜をはかるためにコントラクトを派生すると、抽象性を欠くことになる。
理解されるであろうが、コントラクトは、プロトコルで何が続いているかを正確に説明するために使用される。派生コントラクトは、常に正しい(サービス実装がそうである限り)が、可読性または使い勝手を保証するわけではない。これは、サービスの内部構造を直接反映し、クライアントをまとめようとするプログラマにとっては理解しにくいことがある。また、コンパイラ側で処理するのが難しく、しかもその結果非常にリベラルなものとなる状況もある。
サービスは、一度起動すると、同じアプリケーション領域にあろうとなかろうと、呼び出し側コードと並列に実行することができる。同時実行性について述べることは何もなく、単に並列処理であるというだけであることに注意されたい。この2つは、メッセージングを通じてのみ同期しデータを共有している限り、互いの制御の流れとは無関係に書いて実装することができる。異なるサービスインスタンスが同時実行される(例えば、別のスレッドまたはプロセスで)ことは必要ないか、または実行されないことに注意されたい。
メッセージング
前の説明に鑑みて、次に、クライアントサイドまたはサーバサイドのいずれかにプロトコルを実装するコード本体として定義することができるスケジュールの概念に注目することにする。スケジュールの見方については、1)スケジュールを、メッセージを送信し、メッセージをポーリングする手順として見ること、または2)手順のとは根本的に異なる、実行モデルを詳細に見ることの2通りがある。
本明細書ですでに説明したように、プロトコルハンドラの単純な実装は、何らかのメッセージ送信APIを通じてメッセージを送信し、他のAPIを使用してメッセージをポーリングするメソッドとしてであろう。それぞれのサービスインスタンスは、この従来のモデルでは、自実行スレッドを持たなければならず、これは拡張可能でもないし、環境の実行時のチューニングを許すわけでもない状況である。従来、それぞれのサービスインスタンスは、別々のスレッドを必要とし、それだけのことである。オペレーティングシステム(OS)では、どのスレッドがいつ実行するかを決定し、アプリケーションオペレータ側で利用できるチューニングコントロールはない。
この従来のアプローチの最初の問題は、必要とする割り当て済みスレッドが多すぎること、OS(例えば、カーネル)資源の負担大、さらにメモリフットプリントの著しい増大などである。サービスインスタンスが出入りする毎に、OSスレッドの作成と破壊を繰り返さなければならず、負担が大きく、しかも、一度に限られた数のスレッドをアクティブに保持できる(例えば、1つのサービスインスタンスに1つ必要)「スロットル」がない。
さらに問題を複雑にしているのは、バイナリコード内の低レベル位置が対話状態を含むものであるという点である。したがって、サービスインスタンスを他のマシンに移動したり、ただ単に対話状態を検査することは困難であろう。
そこで、本発明のシステムおよび方法では、プロトコルハンドラ(例えば、サービス)の妥当な実装に対する2つの基本的な態様がある。第1に、プロトコルハンドラの実行環境に関する仮定があり得ないということである。ハンドラ毎に1つのスレッドがありうるか、または複数のスレッドを重なり合う寿命を持つものであっても複数のサービスインスタンス間で共有できる。第2に、対話状態は、コードではなくデータで表現することができるということである。
2番目に述べたことは、データでの実装というよりもむしろ対話状態の流れの宣言に関して前に述べたことに反していると受け取られるおそれがあるが、開発者は対話の流れを宣言的に見ることができるべきであるというのが意図であった。それでもランタイムモデルは、対話状態がデータで表現されるモデルである必要がある。つまり、「単純(ナイーヴ)」モデルはプロトコルハンドラのソース(例えば、プログラマ)の視点では適切であるが、ランタイムモデルは非常に異なる場合があることは理解されるであろう。当業者であれば、このギャップに橋渡しすることで、VBオーケストレーションが生産性および可読性の高レベルの向上をなんとか達成することを理解するであろう。
次に、スケジュールコードは、ソーススケジュールのすべての論理を含む別のクラスにコンパイルされるが、異なる同時実行モデルをサポートするように再配置される。スケジュールを起動すると、コードは、休止イベント(別名、「降伏点(yield point)」)が発生するまで実行される。
休止イベントが発生すると、スケジュールは実行を停止し、それを起動したスケジューリングランタイムに、または最後に再開したイベントのサイトに制御を返す。現在のところ、唯一の再開イベントは、メッセージ到着、メッセージタイムアウト、およびウエイトステートメントの完了である。
スケジュールを一時停止した後、そのスレッドは何か好ましいことに使用するためにランタイムに戻されるか、または破壊されるが、すべて基盤のランタイムのスレッドモデルに依存する。より高度なホスティングフレームワークは、そのすべての活動に対しスレッドプールに依存する可能性があるが、より基本的なホスティングフレームワークでは必要になる毎に新しいスレッドを作成する場合のあることは理解されるであろう。スケジュールのコードは、いずれにせよ,何も仮定を置くことはありえない。非サービスコンテキストでの第1の休止イベント(例えば、メソッドの呼び出し)では、使用されるスレッドをスケジュールが完了するまでブロックさせることができることに注意されたい。
メッセージが届き、特定のサービスインスタンスに経路指定され、それを待つ休止中の受信があることが判明した場合、ランタイムによりReceiveステートメントの後の本体を保持するメソッドを呼び出すことができる。この呼び出し点は、次に、新しい再開部位(別名、「継続点(continuation point)」)となり、この呼び出しは、スケジュールが再び休止するまで戻らない。
つまり、スケジュールは、データとして公開される対話状態を持つコールバックとして実装されるが、コードはそれでも、ポーリングコードとして出現し、その場合、その対話の流れは、VB.Netの例におけるおなじみの言語要素(language constructs)を使用して宣言される。
本発明によれば、スケジュール内のメッセージ処理および並列処理のため適切な言語追加を行うことができるが、ほとんどの場合、スケジュールコードは、通常のVBステートメント、つまり、ループおよびifステートメントから例外ブロックおよび変数宣言にいたるまでのすべてからなる。
メッセージの送受信
プロトコルコード内のほとんどの基本的なオペレーションは、クライアントサイドであろうとサーバサイドであろうと、接続の一方の側でメッセージを送信し、他方の側でそれを受信することである。
はじめからのオペレーションでは、メッセージは、受信する前に、送信しなければならず、そのようにする構文は非常に簡単である。
Figure 2006024223
要求/応答コントラクトについては、すでに説明されている。Sendステートメントは、ある種のコネクタを持つことができる。コネクタは、スケジュールがサービスであり、Sendが一次コネクタ上で動作する場合に暗黙のコネクタである。この例では、クライアントは、最初にサービスに接続する。
前に述べたサービスクライアントの呼び出しの場合と異なり、Sendステートメントは値を返さないことに注意されたい。非同期メッセージ受け渡しの核心は、すべてのデータ受け渡しを明示的にすることであり、したがって、双方向通信にはそれぞれの側で送信と受信を必要とすることは理解されるであろう。
サービス側、つまり、実装側では、メッセージは以下のように処理されるであろう。
Figure 2006024223
このステートメントではコネクタ参照がないことに注意されたい。サービスは、その一次コネクタ上でメッセージを受信する。応答のため、サービスは、コントラクト定義に従って、その結果を文字列値として送り返す。
Figure 2006024223
株価情報サービスはまったく信頼できず、そのデータ収集戦略においてはかなり静的であるという事実を別にすれば、ただそれだけのことである。そこで、メッセージは他方の側で受信されなければならない。例示されているように、メッセージパラメータがReceiveステートメントの外に出る場合の変数が宣言されている。
Figure 2006024223
上記の例は、完全なスケジュールベースのアプリケーションの表現である。以下では、コード全体が1箇所にある。
Figure 2006024223
Figure 2006024223
「Option Strict On」(例えば、VBオーケストレーションでは、現在、厳密モードコンパイルを必要としている)などのステートメントをファイルの先頭に追加するか、または何らかのappコードをサービスクライアントに追加することにより、他にコンフィギュレーションの設定を行わずにコードを実行することができることは理解されるであろう。このコードは、「sample−1」ディレクトリの下にある。
これらのステートメントの実行モデルによれば、Receiveステートメントが実行され、すでに利用可能なそれと一致するメッセージがない場合、スケジュールは休止する(例えば、それが使用しているスレッドを放棄する)。メッセージが利用可能であれば、休止しないが、実行は次の行へ即座に継続する。Sendステートメントは決して休止しない−メッセージが基礎のシステムによって受け付けられるとすぐに、そのステートメントは終了する。
メッセージがスケジュールに届くと、ランタイム側でそのスケジュールがその種のメッセージを待つのを休止したことを検出した場合、スケジュールは、通常、ランタイムが使用しているのと同じスレッド上で即座に再開される。
これではコントラクト言語で表現できる強力なすべてのプロトコルに対し十分でないと誤って信じる可能性がある。例えば、様々なメッセージが一度に入って来るのをシステムが待つ状況、例えば、同じ状態からの2つの遷移、または複数の順序付けされていないメッセージによるトリガ、または分割されたコントラクト定義である。
これらの他の遷移状況を取り扱うために、VBオーケストレーションでは、一組のメッセージのうちから1つのメッセージの受信を処理する「select」ステートメントの一変種を定義する。
Figure 2006024223
このコード例では、2つのメッセージ「Request」および「ItsOver1」のうちの1つだけがこのステートメントで受信される。しかし、以下に示されているように、AおよびB(任意の順序で)またはCだけを受信することが望ましい場合がある。
Figure 2006024223
以下のコードは、この目標を達成することができる。
Figure 2006024223
特に、Receiveステートメントを同じ行、例えば、「select Receive」内の同じ「Case」ステートメント内に置くことにより、何らかの未定義の順序でメッセージのすべてを受信してから次へ進むように指定することができる。すべての入来メッセージの要求条件を最初に満たすケースは、最終的に選択されるケースである。Selectステートメントに関する限り、CがAの後、ただしBの前に入る場合、Aは利用可能にされ将来の他の時点に受信される。
次にCtRepeatedRequestResponseコントラクトの実装に移る。
Figure 2006024223
Figure 2006024223
Figure 2006024223
ここで注目すべき態様がいくつかある。第1に、実行中の「select Receive」ステートメントが例示されているが、これは、さらに、通常の「Do」ループステートメント内にネストされる。スケジュールの包含に関する制約はごくわずかであり(例えば、以下の「言語の制約」で説明されている)、ループはそれらの間にない。サービスクライアントでは、送信/受信を中心としてループが使用され、そこで、システムは、株価について何度も尋ねることを許されているユーザと相互作用する。このコードは、DVSサンプル間で、Sample−2として使用することができる。
この実施例では、サービスクライアントは一か八かで実行している。例えば、クライアントからまる1分間何も届かなかった後、適切であると感じられたときにサービスが「ItsOver2()」メッセージを送信すると仮定する。ここで、サービスクライアントは、さらに、「select Receive」ステートメントを使用して、この可能性に対応することも可能である。
サービスは、まる1分間、メッセージがなかったことを検出することができるであろう。例えば、サービスは、これがItsOverlメッセージを送信せずにクライアントが消えてしまったという好ましくないサインであると決定することも可能であろう。このような状況を取り扱う何らかの手段が必要である。セッションタイムアウトは、上述のように有用であるが、多くの場合、強烈すぎる。
むしろ、タイムアウト間隔を「select Receive」ステートメントに設定することが可能であり、メッセージが届かない場合の状況をより精密に制御する。
Figure 2006024223
この間隔の型はSystem.TimeSpanとすることができる。上記の「FromMinutes」メソッド呼び出しは、その型に対する共有メソッドの1つであり、これによりTimeSpanを特定の時間単位(例えば、秒、分、時)から構成することができる。System.TimeSpanの詳細については、.NETフレームワークのドキュメンテーションを参照されたい。
「select Receive」ステートメントの定義では、TimeSpanが0の場合、すでに到着していて待機中のメッセージから分岐条件が直ちに満たされ得なければタイムアウト分岐が選択される。つまり、Select Receiveステートメントが休止しないようにすることが1つの手段となっている。これにより、利用可能であれば即座に処理されなければならない何らかのメッセージがないかスケジュール側で素早くチェックするようにでき、利用可能でなければスケジュールで実行するのがより適切なことがある。
上記の例では、セッションにただタイムアウトさせ、サービスインスタンスに消えてもらうだけでなく、むしろ、「ItsOver2」メッセージをクライアントに送信し、クライアントに通知する機会があったことに注意していただきたいが、これは遅いユーザを待つ際に十分うまく機能する可能性がある。これは、よい「サービスシチズン(service citizen)」であることの一部である(例えば、消え去る(go away)ことをパートナーに通知する)。
分割行
「select Receive」は単一状態遷移をトリガする代替および順序付けなしのメッセージグループをサポートするのに十分であったが、コントラクト内での分割をサポートする場合には不便である。この実施例では、コントラクトパターンは以下のようであることを仮定する。
Figure 2006024223
受信側では、これは次のようにコーディングすることが可能である。
Figure 2006024223
どのメッセージがすでに受信されている(したがって、再び参照すべきでない)かを追跡するため、このブックキーピングをすべてどのように完了しなければならないかに注意されたい。VBオーケストレーション例では、このタイプの状況を取り扱う。例えば、以下のようになる。
Figure 2006024223
ここには、どのような形であれブックキーピングコードはない。つまり、それぞれのメッセージは、他のメッセージとは独立に処理されることができるということである。
「Split」ステートメントにより、VBオーケストレーションは並列処理が行われ、しかも、同時実行性の複雑さを気にかける必要はない。上記のステートメントの意味は、分割行と呼ばれる、「分割」内のその3つのネストされているブロックは、互いに無関係に、例えば、並列に実行できるということである。
しかし、同時には実行されず、この管理はすでに説明されている休止(pause)および再開プロセスを通じて処理される。分割行は、スケジュール内の他のすべての行が休止されるまで再開することはできない。
「分割」が実行されると、その分割行はすべて最初に中止される、その後、分割行は宣言の順序で再開される。これは、最初の分割行が休止しない限り、それが実行中のスケジュール内の唯一の分割行であることを意味する。つまり、分割行の同期は暗黙の同期であり、休止を通じて制御される。オブジェクトをロックするか、または分割行の間にバッファを入れるかについて悩む必要はない。むしろ、休止イベントの間で、現在の分割行は実行中の唯一の分割行であることは理解されるであろう。
実際、どのような形態であろうと自スレッド管理をスケジュールの中に導入することは、絶対に避けることができる。導入すると、本発明によるスケジュールの基盤として使用されるモデルが弱体化することになる。
次に、分割行を使用して上の株価情報繰り返しクライアントを実装する方法を説明する態様に進むことにする。
Figure 2006024223
Figure 2006024223
第1の分割行は、すでに説明されている実装と同一であることに注意されたい。行われるのは、「Exit Split」が追加されることだけであることに注意されたい。これは、囲む「分割」ステートメントのすべての分割行を終了する一般的な「Exit」ステートメントのもう1つの変種である。第2の分割行は、決して届くことのない「ItsOver2」メッセージを待つ。待たなければ、第1の行はステートメントを終了する。
オーケストレーションクラス
再び通常スケジュールとオーケストレーションクラス内に現れるスケジュールとの区別に戻ると、このクラスが存在する場合以下のようになる。
Figure 2006024223
Figure 2006024223
次のように分けることも可能である。
Figure 2006024223
Figure 2006024223
問題は、それぞれのメソッドが自スケジュールを持つため、「GetSingle」呼び出しが、完了するまでブロックする点である。つまり、第1の分割行の内部で、その呼び出しは、応答メッセージを待っている間出力せず、第2の行は、実行に取りかからない。本質的に、長時間の停止状態(starved)になる。「GetSingle」の内部のReceiveステートメントが第2の行の中のステートメントで調整できれば、この問題は緩和できるであろう。それはちょうど、オーケストレーションクラスが遂行するものである。
クラス宣言を単純に以下のものに変更することにより
Figure 2006024223
所望の挙動が得られる。つまり、GetSingle内のReceiveステートメントが出力することは、分割行が出力し、第2の行が実行可能であることを意味する。
待機
スケジュール内の他の基本オペレーションは設定された期間の間待機することである。その時間の大部分を遅延に費やす長時間実行サービスのクラス全体がある(一般に「ぐずぐず先へ延ばす人(procrastinator)」パターンと呼ばれる)。これらは、通常、コマンド(例えば、シャットダウン、モニタ追加など)の到着を監視し、それと同時に、ハートビート信号またはハートビートポーリング要求を他のサービスに送信することができる監視サービスであることが多い。そこでこれらの概念を参照して、他の理由もなく、共通の用語を定めることにする。
長期間実行することが予想される何らかのサービス/サービスのクラスを設計する場合、通常、サービスがまだ利用可能かどうかを他のサービスが自動的に判別し、積極的にそれを実行できるようにするある種のインターフェースを設計しなければならない。アプローチの1つは、サービスにアクセスするのが困難なすべてのクライアントに何らかの中央サービスに情報を送信させることであるが、それだと、クライアントは、使用事例を設計に追加することにより必要以上に複雑になり、使用事例はクライアントの元の目的に関係しない。
むしろ、ある頻度で監視サービスに送信されるメッセージである、ハートビートの受信を待機することにより、第1のサービスが利用可能かどうかを追跡する監視サービスが作成される。
通常の設計では、監視サービスは、監視されるサービスにそのハートビートを1回送信するか、またはN秒おきに送信を開始するよう要求するか、またはハートビートの送信をどれだけの頻度で準備するかをモニタに通知することができる。監視サービスは、その後、一定時間待機し、single−shot−heart−beat要求を送信するループを使用するか、または定期的にハートビートを送信するように監視されるサービスに要求することができる。
後者の状況では、監視サービスは、「select Receive」を使用し、タイムアウト間隔をagreed−upon間隔よりも少しだけ長い何らかの値に設定する。ハートビートが届いた場合は、すべて良好であるが、ステートメントがタイムアウトになった場合、それは、何かよくないことが進行中であることを示しており、監視サービスはある形態のアラームを送出することが可能である。
より高度な実装は、ハートビートメッセージ上に他の情報を抱き合わせで載せて(piggy−back)、オペレータが長時間実行サービスに関する統計量を取得できることが理解されるであろう。
Waitがオーケストレーションのステートメントとして明示的にサポートされていなかった場合、一定時間の遅延を導入すると、アプリケーションの拡張性に対し破滅的結果をもたらす可能性がある。.NETフレームワーク内のAPIである、Thread.Sleep()に依存しなければならない場合があるが、ホスト環境のランタイムにより同時実行性を管理することを要求する、サービス実行モデルには完全に不適切である。Thread.Sleep()を呼び出すと、ウエイトの持続期間中に現在のスレッドを結合する。Waitを呼び出すことをループするサービスについては、これは無期限とすることができる。
つまり、そのようなサービスでは、スレッドをすべてそれ自身に割り当てることになる。これはほとんどの期間未使用状態のままであるスレッドに関することであることは理解されるであろう(例えば、通常の監視スレッドは、作業実行に100マイクロ秒を費やし、その後、数分間スリーピング状態に進む。1分間スリープし、100マイクロ秒間動作するスレッドは、そのタイムスリーピングの99.9998%を費やすことになる。)
したがって、このモデルでは遅延の必要性を考慮することが重要である。これは、「Wait」ステートメントで実行される。
Figure 2006024223
監視サービス(コマンドの受信を監視しない)での使用例について、以下では、適当なスケジュールを示す。
Figure 2006024223
システムは、ループの本体を実行するのに要する時間を補償できることに注意されたい。これは、ウエイト期間が指定された時間にできるだけ近くなるようにするためである。
Waitステートメントのオペランドは、型System.TimeSpanとすることができる。
動的並列処理
Splitステートメントによりコードの本体の定義を可能にできるが、n行分のコードを並列に実行するために使用する可能性はない。そのような動的挙動のケースは強く、以下の2つの方法でサポートされる。
1.Split−For−Eachステートメント
2.Split−Select−Receiveステートメント
前者は、他のすべての反復と並列にループの各反復を実行することを除き、For−Eachステートメントと同じ基本的な意味を持つ。つまり、繰り返されるコレクション内にあるアイテムの数だけ並列実行行があるということである。この数が決定された後、さらに行を並列ステートメントに追加することはできない。Split−For−Eachは、Splitと同じ「結合(join)」規則を持つ、つまり、すべての反復が終了すると、Split−For−Eachステートメントも終了する。
例を以下に示す。
Figure 2006024223
これがそのようなステートメントを含む通常のFor−Eachを超える利点は、すべてのReceiveステートメントが並列に待機するという点である。送信と受信との間の遅延が大きいほど、これを実行できることがますます重要になる。
「split−Select−Receive」は、入来メッセージに対する応答として並列実行の新しい行を動的に開始するために使用することができる。ある変種は、多重化された対話に関する理解によって異なるが、より単純な変種は、このコントラクトを実装するのを手助けする変種である(A、B、およびCはすべて入来メッセージである)。
Figure 2006024223
ここで、コントラクトにより、Cを得るまで任意の個数のインタリーブされた<A,B>シーケンスを取ることができ、Cを得たときに、すべてのBが入ってくるのを待つ。各<A,B>シーケンスは他のすべてと独立に処理されるため、ループ内でSelect−Receiveステートメントを使用してこれを実装するのは困難であろう。しかし、Split−Select−Receiveを使用することができる。
Figure 2006024223
このステートメントの内側の1行が出力する毎に、新しい行が作成され、Selectステートメントをその新しい行について実行することができる。これは、そのステートメントは決して独立に終了することはないことを意味している(例えば、常に、次のメッセージを処理するために新しい行が生じる)。ステートメントを終了し、そのまますでに開始されているすべての行を実行できるようにするために、そのステートメント内の何らかのコードで「Finish Split」ステートメントを実行することが可能である。
注意:前文を考慮すると、1つの実行行という考え方は、ソースコード行を指すのではなく、むしろ、「一連の実行」、例えば、並列処理プログラム内の一連のステートメントを指すことは理解されるであろう。
終了
「Exit」の新しいバージョンのいくつかは、すでに上で説明されているが、わかりやすくするために、以下にその内容と動作を繰り返し示す。
Figure 2006024223
これは囲む「split」、「split−For−Each」、または「split−Select−Receive」のすべての出力行を終了し、対応する「End」または「Next」ステートメントに移動する。
Figure 2006024223
これは、現在の行(静的であろうと動的であろうと)を終了するが、他には影響を及ぼさない。
フィルタ
メッセージフィルタは、前の方で「Receive」ステートメントについて説明したときには取り上げられていなかった。句を例外ハンドラに入れてそのハンドラの一致がただ単なる例外の型に基づくのではないようにすることと同様に、句をReceiveステートメントに追加し、コンテンツまたは大域的状態などの特別ないくつかの要因に基づいてメッセージを受け入れるか、または拒絶することができる。
コントラクト言語は対応する条件を指定する手段を持たないため、フィルタ式を使用してメッセージを除去するスケジュールは、そのコントラクトがプロセス内で違反にならないようにすることに注意されたい。
特にある場合にはさらに多くのメッセージを受信することができ、他の場合にはそうすることができないときに、フィルタを採用すると都合がよい。例えば、以下のようになる。
Figure 2006024223
このステートメントは、メッセージパラメータが値「OK」を持つ場合のみメッセージAを受け入れ、そうでなく、Aメッセージパラメータが値「ACK」を持つ場合にはAおよびBを受信する。これらの状況がどれも真でない場合、ステートメントはそれらが真になるまで待つ。そこで、フィルタは、メッセージが消費されるまで何回も呼び出されることがあり、したがって、副作用を起こすことなく真の式であることが重要である。
二次コネクタ
上述のように、サービスが最初に起動されると、明示的に指定することなくメッセージの送受信に使用することができるコネクタを割り当てられる。このコネクタは、サービスの「一次」コネクタと呼ばれる。一次コネクタは、第1のメッセージがサービスに送信された際のクライアントコネクタにバインドされる。これは、常に、そのコントラクトに関する実装パースペクティブを持つことができる。
他のクライアントとまったく同様に、アクティブ化されたサービスがクライアントとして他のサービスと通信することを望んでいる場合、何らかのサービスアドレスにバインドされているコネクタファクトリを使用し、そのファクトリからコネクタを作成し、メッセージの送信を開始することが可能である。上述のように、コネクタファクトリにより作成されたすべてのコネクタは使用パースペクティブを持つ。
もしサービスが、一次コネクタと同じコントラクト上にあろうとそうでなかろうと、他のクライアントに対話を開始させたいとすればどうであろうか?一次コネクタは、すでにバインドされており、したがって、共有することはオプションではない。それに、他の何らかのコントラクトを実装したい場合、一次コネクタはおそらくとにかく役立たない。
答えは、実装パースペクティブを持つ二次コネクタを作成することである。サービスにおけるすべての実装パースペクティブコネクタは、二次コネクタと呼ばれる。サービス外では、すべてのコネクタは等しい、一次でも二次でもないことは理解されるであろう。
新しい二次実装コネクタの作成を以下に示す。
Figure 2006024223
ここでは以下の2点に注目すべきである。
1.「Implements」キーワードを変数宣言の中で型修正子(type modifier)として使用することができる。これは、宣言された変数に実装パースペクティブを与える。
2.実際のコネクタオブジェクトは、サービス参照なしで所望のコントラクトを呼び出すことによって作成できる。これは、たぶん型名のかなり奇妙な使い方であるが、二次コネクタを作成する唯一の方法である。
「Implements」コントラクト型修正子は、クラスまたはモジュールメンバとして、またはメソッドへのパラメータとして含む、コネクタ変数が作成できる場合には必ず使用できる。一方のパースペクティブのオブジェクトを反対のパースペクティブの変数に割り当てようとすると、コンパイル時に失敗することがある。コネクタ−変数割り当ての規則は、コネクタ−コネクタのバインドの規則とちょうど反対とすることができることに注意されたい。つまり、コネクタは、同じパースペクティブの割り当て済みコネクタとしかできないが、反対のパースペクティブのコネクタにバインドしなければならない。
見つからないサービス
利用可能なサービスがないことを検出する方法は2つある。第1に、TCPアドレスが有効でないことがある。つまり、ポートが開かれておらず、サービスが実際にはそこにない。この問題は、第1のメッセージをサービスに送信しようとする際に検出され、即座に例外を発生させることができる。
第2に、メッセージは宛先に届くことができるが、ホスティング環境はサービス名またはサービスインスタンスを認識しない。この場合、メッセージを送信するスケジュールは、寿命とともに移動しており、例外を投げるのは意味がない。
代わりに、問題は、オーケストレーションクラスのメソッドをオーバーライドすることにより取り扱われる。
Figure 2006024223
タイムアウト
一方が一方のスケジュールから他方に非同期メッセージを送信する場合、応答は届く保証はない。このようなことが生じる可能性のある理由としては、限定はしないが、低水準の通信障害、またはクライアントとサーバとの間での予想される内容についての不一致を含む様々な理由がある。コントラクトは、2つのメッセージの間の最大遅延を指定できないため、コントラクトが2週間の間必要とする要求に応答しないサービスは、技術的に、そのコントラクトを分けていない。最初にメッセージを送信することなくスケジュールが終了した場合のみ、コントラクトの違反となる。
これは、サービスおよびサービスクライアントに対するスケジュールを作成する際に考慮しなければならない問題を示している。サービスが受信を依存できる唯一のメッセージは、第1のものであるが、それは、メッセージが到着したのが第1の場所で開始したという理由にあるからである。サービスクライアントは、そのことにさえあまり依存できない。幸運なことに、VBオーケストレーションでは、適当な実装ツールを用意している。
異なる取り扱いを要する2つの状況がある。
1.与えられたメッセージが届かない場合、スケジュールが具現化する計算プロセスを完全に放棄することができる。スケジュールコードは大きくならないようにされるので、セッションタイムアウトは、この状況では十分であり、推奨される。
2.与えられたメッセージが届かない場合、スケジュールは、それから回復して、既定の情報とともに進むことができるか、または要求の再送を試みるか、または情報について他の何らかのサービスとのコンタクトを取ることができる。タイムアウト間隔を設定しているSelect/Receiveステートメントは、この状況に対し推奨される。このような状況についてはすでに説明されている。
Figure 2006024223
上述のように、Select/Receiveステートメントは、複数のケースを持たなくてよい。Receiveステートメントは、実際、より効率的に実装された(が、機能的に等価な)バージョンの、単一のケースを伴うSelect/Receiveである。
つまり、
Figure 2006024223
Figure 2006024223
に等価である。
この実現を備えると、メッセージが予期されているのに届かない場合はいつでも、Receiveステートメントにタイムアウト間隔を追加することによりそれを処理することができる。
本発明によれば、状況に応じて、このようなことが生じた場合にいくつかの代替が使用可能である。しかし、一般にガイドラインを定義できないことに留意されたい。すべては、解決しようとしている問題に完全に依存する。例えば、次のようである。
・ 少し長く待つ。
・ 応答がパラメータなしの「acknowledgement−style」メッセージであった場合、確認応答が否定的(または、状況によっては肯定的)であるという仮定の下で進めることを決定することができる。
・ 応答メッセージが、なしで処理することができる何らかのクリティカルでないデータを送り返した場合、たぶん、到着していないデータに対する何らかの既定値とともにそうする。おそらく、Webサービスは、パスポートに似たサービスから個人化データを検索しているが、何もなければ、Webサービスは制限付きの個人化とともに処理を進める。
・ 待機していたサービスにメッセージを再送しようと試みる。
・ 接続可能な他の何らかのサービス、または同じサービスの他のインスタンスを見つけて、その情報を取得する。
これを行うメソッドは、もちろん、状況により異なる。上の1番目の項目を除くすべてに共通なのは、コントラクト自体がいくつかのメッセージが到着しないおそれがあるという事実を受け入れないと、大きな問題になるという点である。スケジュールを抜けると、寿命内で作成されたそれぞれのコネクタが調査され、それを通じて行われたメッセージ交換が完了しているかどうか検証する。「行われていない」コネクタはいずれも、そのコントラクトに違反しているとして注目され、例外が投げられる。あるべきメッセージを受信しない場合、どこかにエラーがあっても、スケジュールに対してどれだけ重要なことかを知る手段がないため、ランタイムは単純に無視することはできない。しかし、メッセージが到着しないコネクタを破棄することにより、スケジュールはランタイムに、その特定のコネクタについてコントラクトに違反すべきでないことを通知する。
Figure 2006024223
しかし、コネクタを破棄することもまた、そのコネクタに対し他の処置が講じられないことを意味する場合がある。それに送信できないか、またはそれからメッセージを受信することができない。試みると、エラーが発生する。
Selectステートメントのタイムアウト間隔では、ステートメントのグループが実行に要する総時間に上限を設定せず、1つのステートメントがメッセージを待つ時間のみに対し設定することに注意されたい。前者を実行するには、SplitおよびWaitステートメントを使用することができる。
Figure 2006024223
VBオーケストレーションではリアルタイムの動作を主張していないので、これが要する時間は指定された2分以内であるという保証はない。第2行が休止イベントに達した場合のみ、Splitステートメントが実際に終了し、「End Split」の後のステートメントが実行される。
非スケジュールコードとの相互作用
非同期プログラミングにSendおよびReceiveステートメントを使用することが正しい解決手段とならない状況がある。状況によっては、スケジュールの単一スレッドのブロッキングの性質がエレガントな解決手段を邪魔することになるか、またはおそらく、本質的に、単にスケジュール駆動でない何らかのUIコードを用意する必要がある。
吉報なのは、このような状況であっても、ボタン押下イベントなどをサービスまたはサービスクライアントへのメッセージに変換する少しのコードを書くのは容易であることである。つまり、非同期プログラミングは、イベントベースのグラフィカルUIプログラミングとは非常に相性がよいのである。
これら2つのパラダイム−イベントベースとスケジュールベース−の間のこのようなブリッジを実現するために、VBオーケストレーションでは、非スケジュールコードでイベントへの入来メッセージの送信およびマッピングを行うことができる。したがって、メッセージは、スケジュールおよびそのブロッキングの意味なしでやり取りできる。
コントラクト内のそれぞれのメッセージにより、イベントがその型に追加される。メソッドおよびイベントは.NETではオーバーロードをできないため、イベント名はString“Event”が直接追加されたメッセージの名前となる。メソッドは、メッセージとまったく同じ名前を持つ。
例を以下に示す。
Figure 2006024223
以下で調べるサンプルアプリケーションでは、グラフィカルUI相互作用に特に関係するこのような方法でメッセージ交換が使用される。
グラフィカルユーザインターフェース
Win32ベースのグラフィカルユーザインターフェースには、表示する新しいデータをコントロールに与えるなど、特定の操作を行うために使用されるスレッドに関して特別な要求条件がある。すべてのコントロールがこの要求条件を持つわけではないが、一部のコントロールはそうであり、それに適応しなければならない。スケジュールと個別のコネクタは両方とも、UIスレッドにアタッチし、スケジュールで受信した、またはコネクタで受信したすべてのメッセージは、特定のUIスレッドのコンテキストで受信される。
この機能は、使いやすいが、実際に必要になった状況に限られるであろう。スケジュールコードを単一スレッドに強制すると、同時実行の機会が制限され、したがって、パフォーマンスに対するボトルネックになるおそれがあることは理解されるであろう。
Figure 2006024223
第2のステートメントは、必ず、戻った後、そのコネクタ上で受信されたすべてのメッセージはそのフォームの所有スレッド上に到着するようにする。これはサービスの一次コネクタ上でも実行できることに注意されたい(これは、一次コネクタを明示的に参照する数少ない妥当な機会の1つである)。
Figure 2006024223
しかし、たいていは、サービスおよびサービスクライアントは、UIコードを直接呼び出さず、メッセージをそれらを含むフォームに送信するが、これは、たいてい、制御スレッドを設定することに意味がある非スケジュールコネクタであることを意味する。
以下に、「setControl()」を使用した場合の例を示す。
Figure 2006024223
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は、読み取り専用メモリ(ROM)710およびランダムアクセスメモリ(RAM)712を含む。基本入出力システム(BIOS)は、ROM、EPROM、EEPROMなどの不揮発性メモリ710に格納され、BIOSは、起動時などにコンピュータ702内の要素間の情報伝送を助ける基本ルーチンを含む。RAM712は、さらに、データをキャッシュするためのスタティックRAMなどの高速RAMも含むことができる。
コンピュータ702は、さらに、好適なシャシ(図には示されていない)に入れて外部で使用するように構成することも可能な、内蔵ハードディスクドライブ(HDD)714(例えば、EIDE、SATA)、磁気フロッピー(登録商標)ディスクドライブ(FDD)716(例えば、取り外しディスケット718からの読み出しまたは書き込み用)、および光ディスクドライブ720(例えば、CD−ROMディスク722を読み込む、またはDVDなどの他の大容量光媒体から読み出しまたは書き込む)を備える。ハードディスクドライブ714、磁気ディスクドライブ716、および光ディスクドライブ720は、ハードディスクドライブインターフェース724、磁気ディスクドライブインターフェース726、および光ドライブインターフェース728によりそれぞれシステムバス708に接続できる。外付けドライブ実装用のインターフェース724は、Universal Serial Bus(USB)および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のみが例示されている。示されている論理接続は、ローカルエリアネットワーク(LAN)752および/またはより大規模なネットワーク、例えば、ワイドエリアネットワーク(WAN)754への有線/無線接続を含む。このような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.11(a、b、gなど)と呼ばれる無線技術を使用して、安全で信頼性の高い、高速な無線接続を実現する。Wi−Fiネットワークは、コンピュータ同士を接続したり、インターネットに接続したり、有線ネットワーク(IEEE802.3またはEthernet(登録商標)を使用する)に接続したりするために使用できる。Wi−Fiネットワークは、無認可の2.4および5GHz無線周波数帯で、11Mbps(802.11b)または54Mbps(802.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では、本発明の様々な態様について説明しており、本出願の明細書の一部とみなすべきである。
上述した内容は、本発明の複数の実施例を含む。もちろん、本発明を説明するためにコンポーネントまたは方法の考えられるすべての組合せを説明することは不可能であるが、当業者であれば、本発明の他の多くの組合せおよび置換が可能であることを理解できるであろう。したがって、本発明は、付属の請求項の精神と範囲内に収まるすべてのそのような変更、修正、および変更形態を包含することが意図されている。さらに、「含む」という言い回しを詳細な説明または請求項で使用している範囲において、このような用語は「備える、含む」という用語と似た使い方をし、これは使用した場合に請求項の中で暫定的用語(transitional word)と解釈する。
付録A
スタックフリー適合
Cedric Fournet、Tony Hoare、Sriram K.Rajamani、Jakob Rehof
Microsoft Research
{fournet,thoare,sriram,rehof}@microsoft.com
概要。代替可能性特性を満たす、つまり、IがSに準拠し、Pが、P|Sがスタックフリーとなるような環境であるならば、P|Iはスタックフリーであるということが成り立つ、CCSプロセスの新規性のある詳細化関係(refinement relation)(スタックフリー適合)を提示する。スタックフリーダムは、デッドロックのCSP概念に関係しているが、これは、非同期システムの孤立メッセージを考慮することにより区別しやすい。適合は、CCSプロセス上の前合同関係であり、それによって、モジュール方式の精密化をサポートすることを証明する。適合を関係する先行順(preorders)、CSPにおける安定失敗詳細化(stable failures refinement)、およびCCSにおける拒絶先行順(refusal preorder)から区別する。新しいソフトウェアモデル検査器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]の適合定義のいくつかの場合は、P#QまたはP+Qの形式のプロセスにのみ適用される。この性質の他の類似の統語的依存関係も[11]に存在する。
2 アクションは[11]で名前を付けられている。
−−−−−−−−−−
この論文の残りは、以下のように編成される。セクション2で、スタックフリー適合に最も密接に関係するCSPおよびCCSの伝統における詳細化関係について説明する。セクション3で、われわれの適合の理論を提示する。論文を制限の範囲内に留めるために、われわれの適合理論のプレゼンテーションにおけるすべての証明を省略した。完全に詳細な証明は、われわれの技術レポート[?]にある。セクション4では、ZING適合検査器を適用することにより分散プログラム内のエラーを見つけることについて説明し、セクション5で締めくくる。
2 関連する研究
われわれの適合の概念は、CSP[3,5,12]で安定失敗詳細化に関してモデル化され、詳細化検査器FDR[12]の成功が刺激となっている。われわれのプロセスモデルでは、CCSの動作意味論をCSP概念に類似してはいるが異なる拒絶の概念と組み合わせる。適合の定義は、シミュレーションに依存し、目に見えるアクションおよび安定性が観察可能なラベル付けされた推移システムに直接適用される。セクション3.3で説明されているように、スタックフリーダムに関する代替可能性の条件は、安定失敗詳細化がCCSに直接組み込まれる場合には、満たされない。理由は、スタックフリーダムはデッドロックのCSP概念と異なり、またそれと比べて特徴的な概念であるからである。この違いに対応するため、われわれの適合関係は、即時拒絶(ready refusals)の考えに基づいており、プロセスは特定のアクションを(同時に)他を拒絶しながらすぐに受け付ける必要がある。
スタックフリー適合は、Iain Phillipsの拒絶試験理論[10]で開発されたようなCCSに対する拒絶先行順にも関係する。拒絶先行順により、拒絶の後に生じるアクションの観察が可能になり、したがって、拒絶と組み合わせて即座条件を表すことができる。しかし、セクション3.4で説明されているように、スタックフリー適合は、拒絶先行順よりも厳密に大きい前合同である。
LarsenおよびSkou[6]による2/3バイシミュレーションの概念は、適合にある程度類似している。しかし、LarsenおよびSkouは、隠蔽および内部アクション(γアクション)を取り扱わず、したがって、安定性の問題はそこでは生じない。われわれの適合の理論では、アプリケーションに本質的な、内部アクション、非決定論、および安定性の統一された取り扱いが可能である。
交互シミュレーション[1]は、インターフェースを[4]の実装に関連付けるために使用された。[11]で説明されているように、交互シミュレーションでは、スタックフリーダムに対する代替可能性の条件を満たさない。
3 適合理論
このセクションでは、CCS[7,8]に関する必要な背景を述べ、スタックフリーダムおよび適合の概念を定義し、適合が前合同(定理1)であり、代替可能性特性を満たす(定理2)ことを証明する。
3.1 CCSプロセス
名前の可算集合N={a,b,c,...}を仮定する。集合
Figure 2006024223
は、ラベルの集合と呼ばれる。集合
Figure 2006024223
は、アクションの集合と呼ばれる。αはAを範囲とし、λはLを範囲として、
Figure 2006024223
と書く。Lの部分集合Xについて、
Figure 2006024223
と書く。P上の範囲のCCSプロセスは、以下の式で定義される。
P::=0|A<a1,...,an>|G1+...+Gn|(P|Q)|(νa)P
G::=α.P
ここで、Aはプロセス名を範囲にとり、式
Figure 2006024223
を定義する。名前aは(νa)Pでバインドされていると主張する。Pの自由名はfn(P)と表され、バインドされていないPにおける名前である。
定義1(構造合同、≡)。構造合同≡は、バインドされた名前および変数(α変換)の変更および総和の項の順序変更とともに、以下の規則に従って閉じられた項に関する最小合同関係(congruence relation)である。
Figure 2006024223
CCSの動作の意味は、定義2に示されているラベル付けされた推移システムにより与えられる。このシステムは、CCSの最近の発表において標準であるように、われわれが規則[CONG]を追加したことを除き、Milner[8]により与えられたそのものである。以下の規則[SUM]では、Mの範囲は総和に及んでいる。
定義2(ラベル付け推移)。
Figure 2006024223
Figure 2006024223
とする。a.P#b.Qとa.P+b.Qの違いは重要である。前者は、内部選択を表し、プロセスはa.Pまたはb.Qへの推移を選択するが、後者は、外部選択[5]を表し、プロセスが
Figure 2006024223
または
Figure 2006024223
を提供することによりPまたはQに進むかどうかを環境が制御する。内部選択と外部選択との区別は、われわれの適合の概念では重要である。
非同期アクションは、CCSにおける順次継続なしのアクションとしてモデル化される。したがって、非同期アクションは、aが非同期に生起する場合に、a|Pのように「生成(spawn)」される。
記法。名前とアクションの(場合によっては空の)シーケンスに対し
Figure 2006024223
および
Figure 2006024223
を書く。
Figure 2006024223
について、
Figure 2006024223
と書き、P≡P0、P’≡PnとなるようなP0、P1、...、Pnがある場合に、0≦i<nについて、
Figure 2006024223
となる。記法
Figure 2006024223
を使用するが、ただし(γ*λ)∈{λ,γλ,γγλ,...}である。
Figure 2006024223
となるような
Figure 2006024223
が存在する場合にP→P’と書き、
Figure 2006024223
は、
Figure 2006024223
となるようなP’が存在することを意味し、P→は、ある
Figure 2006024223
について
Figure 2006024223
であることを意味する。Pは、隠蔽アクションを実行できない場合、つまり
Figure 2006024223
であれば安定であり、アクションをまったく実行しない場合、つまり
Figure 2006024223
であれば終了状態である。最後に、簡略表記
Figure 2006024223
を使用して、λまたは
Figure 2006024223
のいずれかが
Figure 2006024223
内に現れるラベル間にあることを意味する。
3.2 スタックフリーダム、即時拒絶、および適合
2つのプロセスPおよびQが
Figure 2006024223
内のローカル名で通信する場合、システムを
Figure 2006024223
と書くことができる。
Figure 2006024223
は、PおよびQに対するローカル名であるため、
Figure 2006024223
上で相互作用できる環境は他になく、したがって、
Figure 2006024223
上のPおよびQの相互作用が完全に成功するかどうかを検証することには意味がある。簡単に、進行がありえなければ
Figure 2006024223
上でプロセスがスタックしているといい、その一部分は
Figure 2006024223
における名前で通信することが可能な状態にある、つまり終了していなかったため、
Figure 2006024223
上の通信は成功していない。われわれのアプリケーションでは、Pは、通常、仕様(コントラクト)がQであるプロセスへのローカル接続
Figure 2006024223
を持つプログラムのモデルである。PとQによって表される実装との間の相互作用がスタックフリー、つまりスタックしえないことを検査したい。スタックフリーダムは、安全特性であり、システムP|Qの到達可能性分析により検査することができる。以下の定義では、スタックネスとスタックフリーダムを正確にしている。
定義3(スタックプロセス)。
Figure 2006024223
が終了状態であり、ある
Figure 2006024223
に対して
Figure 2006024223
の場合、プロセスPは
Figure 2006024223
上でスタックしているという。このようなλを残留アクションと呼ぶ。
定義4(スタックフリープロセス)。
Figure 2006024223
Figure 2006024223
となるようなP’および
Figure 2006024223
がなく、P’が
Figure 2006024223
上でスタックしている場合に、プロセスPは
Figure 2006024223
上でスタックフリーであるという。
上述の状況において、
Figure 2006024223
であり、
Figure 2006024223
上でP’|Q’がスタックするような遷移
Figure 2006024223
を検索することにより定義4を適用する。定義3の制約
Figure 2006024223
および定義4の条件
Figure 2006024223
により、常に
Figure 2006024223
がローカルである状態で、
Figure 2006024223
における名前について内部反応(γアクション)のみが生起しうることが強制される。ある
Figure 2006024223
について
Figure 2006024223
なので、PとQとの相互作用は、コアクション
Figure 2006024223
により照合できない残留アクションλで終了する。λが入力アクションをモデル化する場合、コンポーネントは決して到着しないメッセージの受信を待ち続け、λが送信アクションをモデル化する場合、コンポーネントは決して消費されないメッセージを送信し続ける。後者の例は、処理されないリモートの例外メッセージである。このような状態は、多くの非同期アプリケーションにおける数々の問題の重要な指標となっている。セクション4には、実際のシステムの適合を検査する際の定義4の使用例を示す。
P|Qがスタックフリーならば、P|Sは任意の選択された名前
Figure 2006024223
上でスタックフリーであるという代替可能性特性をS≦Qが保証するような適合関係≦を求める。例示的シナリオでは、これは、実装SがそのコントラストQにより表されるシステムP|Qのスタックフリーダムを検査しても安全であることを意味している。この目標を達成するために、関係≦は、S≦Qならば、任意のコンテキストで、少なくともSと同じ回数だけQが
Figure 2006024223
上でスタックするような関係でなければならない。この要求条件は、Sによって実際には送られない、CSP[5]の拒絶の概念によりエレガントに捕捉できるアクションを与える見込みはないことを意味する。しかし、残留アクションのすべての場合を除外しないので、拒絶要求条件単独では十分でないことがわかる。これが、拒絶が即時拒絶に強められる場合に、以下の定義の動機となっている。
Figure 2006024223
とし、L(1)は、空集合
Figure 2006024223
とともにLのシングルトン(singleton)集合を表すものとする。
定義5(拒絶)。XがLの部分集合であれば、Pが安定であり
Figure 2006024223
である場合、かつその場合に限り、PはXを拒絶するという。
Figure 2006024223
であり、P’がXを拒絶するようなP’が存在する場合、かつその場合に限り、PはXを拒絶できるという。
定義6(即時(readiness))。Y∈L(1)ならば、Pが安定であり、λ∈Yならば
Figure 2006024223
である場合、かつその場合に限り、PはY上で即時(ready)であるという。自明であるが安定プロセスは
Figure 2006024223
上で即時であることに注意されたい。
定義7(即時拒絶)。X⊆LかつY∈L(1)ならば、PがY上で即時である状態からXを拒絶できる場合、つまり、
Figure 2006024223
であり、P’がXを拒絶し、P’がY上で即時であるようなP’が存在する場合、かつその場合に限り、Y上で即時となっている間にPはXを拒絶できるという。
即時集合は、アクションに関して定義されるが(定義6)、拒絶は、コアクションに関して定義される(定義5)ことに注意されたい。最初、これは少し混乱させる可能性がある。例えば、プロセスaは、{a}を拒絶し、{a}上で即時である。
定義8(適合関係)。プロセス上の2項関係Rは、P R Qであればいつでも以下の条件が成立する場合、かつその場合に限り適合関係であるという。
C1.
Figure 2006024223
ならば、
Figure 2006024223
およびP’ R Q’となるようなQ’が存在する。
C2.PがY上で即時である間Xを拒絶することができれば、QはY上で即時である間Xを拒絶できる。
定義8の条件[C2]は、驚くべきことのように見えるかもしれない。これは、セクション3.3および3.4を含めて、以下で動機付けされ説明される。
1およびR2がプロセス上の2項関係である場合、R1○R2と表されるその合成を、
1○R2={(P,Q)|∃R.(P,R)∈R1∧(R,Q)∈R2
により定義する。
補助定理1.{Rii∈Iを適合関係の族とする。すると、
1.関係∪i∈Iiは適合関係である。
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が高々シングルトン集合であるという事実による(
Figure 2006024223
を選択すると、特別な場合として、即時制約のない標準拒絶条件が得られる)。これにより、仕様を詳細化よりも非決定論的にすることができるが、それは、仕様が名前毎に異なる方法でその非決定論を解決することができるからである。例えば、a+b≦a#bである。名前{a,b}のアルファベットについて考察すると、プロセスa+bは{a,b}を拒絶し、{a}と{b}の両方で即時である。プロセスa#bは、状態aから
Figure 2006024223
を拒絶し、状態{b}から
Figure 2006024223
を拒絶する。状態aから{a}で即時であり、状態bから{b}で即時である。したがって、条件[C2]は満たされる。読者は、いくつかのより興味深い例を検証したいことであろう。
Figure 2006024223
ただし、P≦QかつQ≦Pの場合、かつその場合に限り
Figure 2006024223
と書く。また、規則[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と仮定する。すると、
Figure 2006024223
上でC[Q]がスタックフリーであることは
Figure 2006024223
上でC[P]はスタックフリーであることを示す。
以下の2つのセクションは、適合がCSPにおける安定失敗詳細化よりも細かく(適合がトレースに関して定義されるか、または代替として、安定失敗詳細化が推移に関して定義されている場合)、CCSにおける拒絶先行順序よりも粗いことを意味する。この意味で、適合は中間である。
3.3 適合および安定失敗詳細化
適合の定義の中の条件[C2]は、CSP[5,12]における安定失敗詳細化の理論から手直ししたもので、トレースと拒絶の概念に基づいている。安定失敗モデルでは、プロセスPは、その失敗の集合により表される。Pの失敗は、ペア
Figure 2006024223
であり、ここで
Figure 2006024223
はPの有限トレースであり、Xは拒絶集合である。つまり、イベントPの集合は
Figure 2006024223
の後の安定状態から拒絶できる。プロセスPは、PのトレースがQのトレースに含まれ、Pの失敗がQの失敗に含まれる場合にプロセスQを失敗詳細化する。
われわれの適合定義では、拒絶を使用するが、より強い即時拒絶を条件[C2]で使用している。これは、適合がスタックフリーダムに関して代替可能であるべきという要求条件を動機としている。例えば、以下の式で定義された2つのプロセスPおよびQを考える。
P=a.0およびQ=a.0+γ.0
プロセスがラベル集合
Figure 2006024223
にわたると考えると、Pの失敗3は、
Figure 2006024223
であり、Qの失敗は
Figure 2006024223
である。その結果、PはQを失敗詳細化することになる。しかし、Pは、a上でスタックしているが、Qはスタックしえず、それは、その唯一の安定派生形が0であり、スタックプロセスではないからである。したがって、PがQを失敗詳細化しても、Qのスタックフリーダムは、Pのスタックフリーダムを意味しない。対照的に、われわれの適合の定義における条件[C2]の即時制約では、Pが安定状態(P自体)からアクションaを実行することができるが、Qは不安定状態(Q自体)からしかアクションaを実行できないため、
Figure 2006024223
という帰結になる。
スタックフリー適合に対応する自然なトレースモデルでは、その失敗で即時拒絶を使用するように安定失敗モデルを修正し、失敗が、R=(X,Y)が拒絶集合X⊆Lおよび即時集合Y∈L(1)からなる即時拒絶であるペア
Figure 2006024223
となるようにする。
CSPにおける安定失敗詳細化とスタックフリー適合との違いは、スタックネスとCSPデッドロックとの違いから生じる。CSPでは、デッドロックは、特別な成功する終了イベント
Figure 2006024223
が存在しないことにより示される。スタックネスは、ラベル付けされた推移システム内の複数の状態で直接観察可能であり、CSPデッドロックよりも区別しやすい。
3.4 適合および拒絶先行順
われわれの適合の概念は、Iain Phillipsの拒絶検証の理論[10]で定義されているような拒絶先行順に類似している。拒絶先行順では、拒絶集合を観察結果にすることにより拒絶(またはデッドロック)の後に生起することを観察することができる。[2]に従い、X⊆Lに対し、推移規則
Figure 2006024223
を追加することにより拒絶先行順を定義することができる。
Figure 2006024223
について、
Figure 2006024223
である場合、かつその場合に限り、
Figure 2006024223
と書く。通常の方法で、ベクトル
Figure 2006024223
にリフトする。次に、失敗トレース
Figure 2006024223
を定義する。≦rfで表される拒絶先行順は、f−traces(P)⊆f−traces(Q)の場合、かつその場合に限り、P≦rfQと設定することにより定義される。この定義により、同時拒絶および即時特定が捕捉される。例えば、
Figure 2006024223
であれば、
Figure 2006024223
となり、これはaが安定状態であることを示し、ここで集合{a}は拒絶され、ラベルaが提供される。遷移
Figure 2006024223
がa+γ.0により照合できないため、
Figure 2006024223
となることを観察することは興味深い。実際、拒絶先行順は十分強く、スタックフリーダムの代替可能性を保証する。しかし、適合よりも制約が強い。以下の式により定義されるプロセスPおよびQを考える。
P=(a+b.c)#(c+b.a)
Q=(a+b.a)#(c+b.c)
−−−−−−−−−−
3 最大拒絶集合に関して失敗を表し、シーケンスに対し<...>を使用する。
−−−−−−−−−−
定義から(または[?]の詳細を参照)、P≦Qであるが、
Figure 2006024223
であることを検査することができる。P≦Qとなるのは、条件[C1]および[C2]からわかるようにQは異なる派生形を選択できるからである。条件[C1]は、Qの派生形(c+b.c)により明らかであり、[C2]は、Qの派生形(a+b.a)により明らかである。
4 アプリケーション
セクション3に提示されている理論に基づき、共通プログラミング言語で書かれている非同期プログラムを分析するために使用できる適合検査器を実装した。このような言語(例えば、C、Java(登録商標)、C#)は、CCSで直接モデル化するのが面倒ないくつかの機能(プロシージャ呼び出し、ポインタ、共有メモリ、例外、およびオブジェクト)を持つ。われわれの適合検査器は、複雑な符号化を必要とせず直接そのような機能をサポートする言語ZINGに対応している。ZINGの動作に関する意味は、ラベル付け推移システムとして与えられる。SendおよびReceiveステートメント以外のすべてのステートメントは、γアクションのラベル付きの遷移としてモデル化される。SendおよびReceiveステートメントからの遷移は、対応するチャネル名でラベル付けされる(送信または受信されるデータ値を無視する)。適合の定義8では、CCSの構文を参照しておらず、ラベル付けされた遷移システムの意味論に純粋に基づいていることに注意されたい。したがって、定義8を直接使用して2つのZINGプロセスの間の適合を定義することができる。
われわれの適合検査器を適用して、共通プログラミング言語で書かれている分散プログラムのコントラクトを検査した。次に、適合検査の実行方法と見つけたエラーについて説明する。
われわれのアプリケーション例は、書店の在庫および発注プロセスを管理するための分散プログラムである。このシステムは、Microsoft社の製品開発グループにより作成され、メッセージ受け渡しおよびコントラクト仕様を受け付ける共通プログラミング言語の拡張となっている。コントラクトは、通信している状態マシンとして指定され、ソースコード内に型指定として現れる。コントラクトは、元々、メッセージの挙動の実行時検査をサポートすることを目的としていたが(不要なメッセージシーケンスを除去し、プログラミングエラーを発見するため)、ZING適合検査器を使用して、静的に検査することを試みることを決定した。われわれは、ZING適合検査器を開発環境に統合して、実装コードと突き合わせてスタックフリー適合に関してコントラクトを自動検査できるようにした。プログラミング言語、システム、およびコントラクトはすべて、われわれおよびわれわれの技術とは無関係に書かれたものであることを強調しておく。
Figure 2006024223
システムの構造は図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は、実装言語の入力構文に付随させることができる。
コントラクト宣言で、コントラクトの名前と同じ新しい型名を作成する。サービスの実装コードは、以下のように、実装が想定されるコントラクトを指定するサービス宣言(クラス宣言とかなり似ている)内に置かれる。
Figure 2006024223
他のサービスへの接続を表すオブジェクトを保持する変数は、それらのサービスを記述するコントラクトにより分類される。例えば、ShoppingCartService実装の以下のステートメントでは、InventoryServiceへの接続を作成し、contで続行する。
Figure 2006024223
コントラクト型に依存することにより、サービス実装を使用されるサービスのコントラクトを置き換えるZINGモデルに自動的に変換することが可能である。そうする際に、定理2に頼る。例えば、上記の接続作成は、ZINGステートメントinv=new cInventoryReservationに変換され、cInventoryReservationは、InventoryReservationコントラクトからコンパイルされたZINGクラスである。このクラスのコンストラクタを呼び出すことの副作用として、並列処理プロセスが生成され、コントラクトで指定された通りに動作する。これは、以下のCCSプロセスに対応する。
Figure 2006024223
ただし、[cont]はコードcontを表す。これは、セクション3.2の適合の理論を導入した際に、定義3および定義4の前後でコメントの中で言及されたCCS形式の一例であることに注意されたい。サービスとそのコントラクトの間の適合を検査することに加えて、われわれは、常に、サービスとそのサービスが使用するコントラクトとの間の相互作用におけるスタック状態を検査するスタックネス検証を実行する5
−−−−−−−−−−
4 メッセージ型自体は、コントラクト指定の一部としても宣言されるが、ここでは簡単のため省略した。
5 これは、例えば、サービスが自明なコントラクトを持ち、それでも、使用するサービスでスタックする可能性があるため必要である。このような場合も、適合検査器によって捕捉され、フラグが立てられる。
−−−−−−−−−−
書店システムの適合分析を、それぞれのサービス実装および関連するコントラクトをZINGにコンパイルすることにより実行したところ、2つのZINGプロセスが得られたので、それらをわれわれの適合検査器で比較した。適合検査は、合成的に実行された、つまり、コントラクト指定と突き合わせて一度に1つずつサービス実装を検査し、使用されるサービスを表すようにコントラクトを置き換えた。プロセス全体は完全自動である。われわれの適合分析により、以下で簡単に説明する、デッドロックを含む多数の重大なエラーを検出した。以下のリストには、どのコントラクトが検査されたか、定義8のどの条件([C1]または[C2])に違反したかを示し、また、上述のスタックネス検証の失敗も示している。これらのエラーは、コードを検査する前には見つからなかったものであることを強調しておく6
(1)InventoryReservation。欠落タイムアウト指定([C2])。コントラクトは、そのイベントループでサービスをタイムアウトにできることを指定できなかった。このため、サービスがタイムアウトの後すべての要求を拒絶するので、適合検査器により即時拒絶失敗が識別されることをもたらした。コントラクトは、Timeoutの場合を追加することにより是正された。Timeoutイベントは、内部(γ)アクションとしてモデル化され、入力aに付随したときに、ZINGにより、a+γ.0として表される(ここで、タイムアウトの後には何も生じないことを仮定する)。
(2)InventoryReservation.指定されない繰り返し入力([C1])。前のエラーの修正後、適合検査器がシミュレーション失敗を報告した。問題は、コントラクトで、サービスがメッセージのComumitReservationを1回だけ取り、サービスのイベントループを終了することを指定したことにある。しかし、サービス実装では、CommitReservationの受信後にループを終了すべきなのに終了せず、実装が修正された。
(3)ShoppingCart。スタックネス。図1は、コントラクトのShoppingCartおよび修正されたInventoryReservationを示している。実装では、InventoryServiceおよびOrderingサービスを使用する。適合検査では、サービスがCheckOutメッセージを受け取り、その後続けてCommitReservationメッセージをInventoryServiceに送信し、そしてAcknowledgementを受け取るまで待つという状況で、サービス実装がInventoryReservationコントラクトでスタックしたことを検出する。これは、InventoryServiceがタイムアウトになった場合に、デッドロックを受け取る。他の状況では、タイムアウトの結果、ShoppingCartServiceから送信された残留メッセージによりスタックネスが生じる。実装は修正された。
(4)Inventory。サービス内に実装されない入力([C2])。コントラクトInventoryで指定されているが実装されていない入力があると、残留失敗が生じる。実装は是正された。
(5)InventoryChangeNotification。特定のメッセージを受信した後、入力が利用できない([C2])。1つの特定の状態において、サービスイベントループ内でメッセージDoneを受信すると、サービスPublicInventoryServiceは、InventoryProcessingサービスにおける公開加入システムとの通信を終了せずにイベントループを終了するが、コントラクトはこの可能性を反映しない。したがって、そのシステムに対するメッセージは失われる可能性があり、実装が是正された。
−−−−−−−−−−
6 コードは、完全には検証されていない。しかし、エラーのいくつかは、通常、検証によっても見つからないことに注意されたい。
−−−−−−−−−−
5 結論
われわれは、CCSの新規性のある詳細化関係を提示し、それが通信プロセスのスタックフリーダムの構成検査を行うのに好適であることを示した。適合は、目に見えるアクションおよび安定性が観察可能なラベル付けされた推移システムに直接適用可能であるという利点を有する。スタックネスは、非同期プロセスを検査するのに役立つ、孤立メッセージを考慮することによりCSPデッドロックよりも区別しやすい。われわれは、適合が代替可能性を満たすCCSプロセスに対する前合同であることを証明し、関連するプロセス先行順から区別した。表現力の高いモデル化言語であるZING用の適合検査器を構築し、分散システムに適用した。
謝辞。われわれは、Robin Milner氏にはこの論文の草稿についてコメントを寄せて激励してくれたことについて、Ranko Lazic氏には話し合いの中でいろいろな思いつきを与えてくれたことについて感謝する。われわれは、Tony Hoare氏がお膳立てしてくれた、ケンブリッジでの2002年6月のMicrosoft Research(Ernie Cohen、Paul Gardiner、Andy Gordon、Robin Milner、およびBill Roscoe)およびオックスフォード大学での2003年の11月のComputing Laboratory(Christie Bolton、Michael Goldsmith、Ranko Lazic、およびGavin Lowe)のワークショップの参加者たちに感謝する。また、ZINGの設計および実装作業に取り組んでくれたMicrosoft社のTony Andrews氏にも感謝したい。
参考文献
Figure 2006024223
本発明の一態様によるオーケストレーションシステムの一般的なコンポーネントブロック図である。 開示されている本発明の一態様によりオブジェクト指向環境内でメッセージ受け渡しを容易にするための手順の流れ図である。 本発明の一態様によるコントラクトコンポーネントの一般的なコンポーネントブロック図である。 開示されている本発明の一態様によりコントラクトの宣言を容易にするための手順の流れ図である。 開示されている本発明の一態様によりコントラクト拡張を容易にするための手順の流れ図である。 本発明の一態様によるオーケストレーションコンポーネントの一般的なコンポーネントブロック図である。 開示されているアーキテクチャを実行する動作が可能なコンピュータのブロック図である。 本発明によるコンピューティング環境例の略ブロック図である。
符号の説明
100 オブジェクト指向環境
102 クライアント
104 コントラクトコンポーネント
106 オーケストレーションコンポーネント
108 サービス
108 サービス
108 サービス
108 サービス
104 コントラクトコンポーネント
302 メッセージコンポーネント
304 プロトコルコンポーネント
306 コントラクト拡張コンポーネント
106 オーケストレーションコンポーネント
602 スケジュールコンポーネント
604 コンパイラコンポーネント
802 クライアント(群)
808 クライアントデータストア(群)
806 通信フレームワーク
804 サーバ(群)
810 サーバデータストア(群)

Claims (30)

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

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US10/887,739 US7676791B2 (en) 2004-07-09 2004-07-09 Implementation of concurrent programs in object-oriented languages

Related Child Applications (2)

Application Number Title Priority Date Filing Date
JP2011224078A Division JP2012009081A (ja) 2004-07-09 2011-10-11 オブジェクト指向言語による同時実行プログラムの実装
JP2012041903A Division JP5590572B2 (ja) 2004-07-09 2012-02-28 サービスの同時実行を実施するシステム

Publications (1)

Publication Number Publication Date
JP2006024223A true JP2006024223A (ja) 2006-01-26

Family

ID=35207422

Family Applications (4)

Application Number Title Priority Date Filing Date
JP2005201542A Pending JP2006024223A (ja) 2004-07-09 2005-07-11 オブジェクト指向言語による同時実行プログラムの実装
JP2011224078A Pending JP2012009081A (ja) 2004-07-09 2011-10-11 オブジェクト指向言語による同時実行プログラムの実装
JP2012041903A Expired - Fee Related JP5590572B2 (ja) 2004-07-09 2012-02-28 サービスの同時実行を実施するシステム
JP2014075907A Expired - Fee Related JP5815067B2 (ja) 2004-07-09 2014-04-02 サービスの同時実行を実施するシステム及び方法

Family Applications After (3)

Application Number Title Priority Date Filing Date
JP2011224078A Pending JP2012009081A (ja) 2004-07-09 2011-10-11 オブジェクト指向言語による同時実行プログラムの実装
JP2012041903A Expired - Fee Related JP5590572B2 (ja) 2004-07-09 2012-02-28 サービスの同時実行を実施するシステム
JP2014075907A Expired - Fee Related JP5815067B2 (ja) 2004-07-09 2014-04-02 サービスの同時実行を実施するシステム及び方法

Country Status (10)

Country Link
US (1) US7676791B2 (ja)
EP (1) EP1615129A3 (ja)
JP (4) JP2006024223A (ja)
KR (1) KR101076910B1 (ja)
CN (1) CN1719410B (ja)
AU (2) AU2005202252B2 (ja)
BR (1) BRPI0502261A (ja)
CA (1) CA2509483A1 (ja)
MX (1) MXPA05006176A (ja)
RU (1) RU2386999C2 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008217786A (ja) * 2007-03-02 2008-09-18 Internatl Business Mach Corp <Ibm> コンピューティング環境内のメモリ管理方法、メモリ管理システム及びコンピュータ・プログラム

Families Citing this family (33)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7457671B2 (en) * 2004-09-30 2008-11-25 Rockwell Automation Technologies, Inc. Systems and methods that facilitate management of add-on instruction generation, selection, and/or monitoring during execution
US20060204466A1 (en) * 2005-03-08 2006-09-14 Ecolab Inc. Hydroalcoholic antimicrobial composition with skin health benefits
US20060294290A1 (en) * 2005-06-15 2006-12-28 Xerox Corporation Concurrent in-application programming of programmable devices
US8024405B2 (en) * 2006-03-30 2011-09-20 Microsoft Corporation Declarative model for concurrency-control across lightweight threads
US8380483B2 (en) * 2006-10-05 2013-02-19 Nec Laboratories America, Inc. Inter-procedural dataflow analysis of parameterized concurrent software
WO2008040080A1 (en) * 2006-10-05 2008-04-10 Waratek Pty Limited Silent memory reclamation
CN101438234B (zh) * 2007-01-09 2013-08-21 美国日本电气实验室公司 参数化并发软件的过程间数据流分析
US8949457B1 (en) * 2007-03-08 2015-02-03 Aurea Software, Inc. Local transparent extensibility and routing slip extensibility for business process execution language
EP2071452A1 (en) * 2007-12-07 2009-06-17 Alcatel Lucent Device and method for automatically building applications from specifications and from off-the-shelf components selected by semantic analysis
US20090157848A1 (en) * 2007-12-18 2009-06-18 Western Digital Technologies, Inc. Application server processing tcp/ip requests from a client by invoking an asynchronous function
JP5272833B2 (ja) * 2008-03-28 2013-08-28 富士通株式会社 無線通信装置、無線通信方法及び無線通信プログラム
CN101276371B (zh) * 2008-04-18 2012-12-05 浙江大学 基于操作流的异步交互式数据挖掘系统及方法
US8032633B2 (en) * 2008-06-10 2011-10-04 International Business Machines Corporation Computer-implemented method for implementing a requester-side autonomic governor using feedback loop information to dynamically adjust a resource threshold of a resource pool scheme
US8250212B2 (en) * 2008-06-10 2012-08-21 International Business Machines Corporation Requester-side autonomic governor
US8224378B2 (en) * 2008-10-15 2012-07-17 Texas Instruments Incorporated Protecting uplink transmissions in coexisting wireless networks
US8477703B2 (en) * 2009-06-24 2013-07-02 Texas Instruments Incorporated Channel utilization improvement in coexisting wireless networks
US8429605B2 (en) * 2009-12-30 2013-04-23 The United States Of America As Represented By The Secretary Of The Navy Finite state machine architecture for software development
US8789010B2 (en) * 2010-05-10 2014-07-22 Tibco Software Inc. Managing static data structures of legacy software in dynamic class loader environments
US9600255B2 (en) 2010-10-08 2017-03-21 Microsoft Technology Licensing, Llc Dynamic data and compute resource elasticity
US9658890B2 (en) 2010-10-08 2017-05-23 Microsoft Technology Licensing, Llc Runtime agnostic representation of user code for execution with selected execution runtime
US9600250B2 (en) 2010-10-08 2017-03-21 Microsoft Technology Licensing, Llc Declarative programming model with a native programming language
CN102456026A (zh) * 2010-10-21 2012-05-16 中国移动通信集团浙江有限公司 一种数据采集装置和方法
US9760348B2 (en) 2010-11-29 2017-09-12 Microsoft Technology Licensing, Llc Verification of a dataflow representation of a program through static type-checking
US9641403B2 (en) * 2011-04-26 2017-05-02 Openet Telecom Ltd. Systems, devices and methods of decomposing service requests into domain-specific service requests
WO2012164439A1 (en) * 2011-06-02 2012-12-06 International Business Machines Corporation Handling cross-thread method calls
US9176769B2 (en) 2012-06-29 2015-11-03 Microsoft Technology Licensing, Llc Partitioned array objects in a distributed runtime
US8924944B2 (en) 2012-06-29 2014-12-30 Microsoft Corporation Implementation of distributed methods that support generic functions
US8893155B2 (en) 2013-03-14 2014-11-18 Microsoft Corporation Providing distributed array containers for programming objects
RU2656580C9 (ru) * 2014-01-30 2020-01-22 Общество с ограниченной ответственностью "Аби Девелопмент" Определение порядка инициализации статических объектов
US9417876B2 (en) * 2014-03-27 2016-08-16 International Business Machines Corporation Thread context restoration in a multithreading computer system
US9678787B2 (en) 2014-05-23 2017-06-13 Microsoft Technology Licensing, Llc Framework for authoring data loaders and data savers
US9773070B2 (en) * 2014-06-30 2017-09-26 Microsoft Technology Licensing, Llc Compound transformation chain application across multiple devices
KR101805462B1 (ko) 2017-06-29 2018-01-10 주식회사 티맥스소프트 스레드에서 처리되는 서비스 처리량을 증가시키기 위한 방법 및 컴퓨팅 장치

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003337767A (ja) * 2002-05-17 2003-11-28 Katsuhiko Kondo 情報システムを構築するための基盤システム
WO2004040399A2 (en) * 2002-10-28 2004-05-13 Jgr Acquisition, Inc. Transparent ejb support and horizontal data partitioning

Family Cites Families (35)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US204641A (en) * 1878-06-04 Improvement in qar-axue boxes
US64528A (en) * 1867-05-07 Self and-george jaques
US64529A (en) * 1867-05-07 hellen
US204570A (en) * 1878-06-04 Improvement in stove-pipe shelves
US5794005A (en) * 1992-01-21 1998-08-11 The United States Of America As Represented By The Administrator Of The National Aeronautics And Space Administration Synchronous parallel emulation and discrete event simulation system with self-contained simulation objects and active event objects
EP0591593A1 (en) 1992-10-09 1994-04-13 International Business Machines Corporation Device and method of managing asynchronous events in a finite state machine
US5991538A (en) * 1992-12-18 1999-11-23 Inprise Corporation System for generating and using programs in an object-oriented environment with a message dispatch architecture
CA2115464C (en) 1994-02-11 1998-12-15 William G. O'farrell Concurrent processing in object oriented parallel and near parallel systems
JPH08286962A (ja) * 1994-12-16 1996-11-01 Internatl Business Mach Corp <Ibm> 処理システム及びオブジェクト活動化をスケジュールする方法
US6182108B1 (en) 1995-01-31 2001-01-30 Microsoft Corporation Method and system for multi-threaded processing
US5708838A (en) * 1995-09-08 1998-01-13 Iq Systems, Inc. Distributed processing systems having a host processor and at least one object oriented processor
US6587889B1 (en) 1995-10-17 2003-07-01 International Business Machines Corporation Junction manager program object interconnection and method
US5768505A (en) * 1995-12-19 1998-06-16 International Business Machines Corporation Object oriented mail server framework mechanism
WO1998021651A1 (en) * 1996-11-14 1998-05-22 Alcatel Usa Sourcing, L.P. Generic software state machine and method of constructing dynamic objects for an application program
US6167423A (en) 1997-04-03 2000-12-26 Microsoft Corporation Concurrency control of state machines in a computer system using cliques
JPH11249918A (ja) * 1998-03-04 1999-09-17 Sony Corp データ処理方法、記録媒体及びデータ処理装置
US6922834B1 (en) * 1999-03-04 2005-07-26 Sony Corporation Data processing apparatus, data processing method, and program providing medium
JP2000259417A (ja) * 1999-03-12 2000-09-22 Sony Corp データ処理装置、データ処理方法及びプログラム提供媒体
US6804818B1 (en) * 1999-04-29 2004-10-12 International Business Machines Corporation Integration mechanism for object-oriented software and message-oriented software
JP2001167060A (ja) * 1999-12-07 2001-06-22 Hitachi Ltd タスク並列化方法
AU2001249424A1 (en) * 2000-03-29 2001-10-08 Nextset Software Inc. System and method of providing a messaging engine for an enterprise javabeans enabled server to achieve container managed asynchronous functionality
JP3803707B2 (ja) * 2000-12-28 2006-08-02 フューチャーシステムコンサルティング株式会社 フレームワークシステム
US6996833B1 (en) * 2001-03-27 2006-02-07 Microsoft Corporation Protocol agnostic request response pattern
US7095747B2 (en) * 2001-03-28 2006-08-22 Siemens Communications, Inc. Method and apparatus for a messaging protocol within a distributed telecommunications architecture
US7055143B2 (en) * 2001-07-10 2006-05-30 Microsoft Corporation System and methods for providing a declarative syntax for specifying SOAP-based web services
AUPR753401A0 (en) * 2001-09-06 2001-09-27 Canon Kabushiki Kaisha A method of handling asynchronous events
US7310803B2 (en) * 2001-10-19 2007-12-18 419638 Canada Inc. Method and system for executing multiple tasks in a task set
WO2003086108A1 (en) * 2002-04-10 2003-10-23 Archer-Daniels-Midland Company Hydrothermically processed compositions containing phytosterols
US7203924B2 (en) 2002-04-30 2007-04-10 Microsoft Corporation Behavioral analysis for message-passing application programs
US7703077B2 (en) 2002-04-30 2010-04-20 Microsoft Corporation Programming model to detect deadlocks in concurrent programs
US7159211B2 (en) * 2002-08-29 2007-01-02 Indian Institute Of Information Technology Method for executing a sequential program in parallel with automatic fault tolerance
US20040064528A1 (en) 2002-09-30 2004-04-01 Microsoft Corporation Safe interoperability among web services
US7191450B2 (en) * 2003-02-06 2007-03-13 International Business Machines Corporation Data-driven application integration adapters
US7895589B2 (en) * 2003-02-26 2011-02-22 International Business Machines Corporation Dynamic data-driven application integration adapters
US7240054B2 (en) * 2004-02-27 2007-07-03 International Business Machines Corporation Techniques to preserve data constraints and referential integrity in asynchronous transactional replication of relational tables

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003337767A (ja) * 2002-05-17 2003-11-28 Katsuhiko Kondo 情報システムを構築するための基盤システム
WO2004040399A2 (en) * 2002-10-28 2004-05-13 Jgr Acquisition, Inc. Transparent ejb support and horizontal data partitioning

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008217786A (ja) * 2007-03-02 2008-09-18 Internatl Business Mach Corp <Ibm> コンピューティング環境内のメモリ管理方法、メモリ管理システム及びコンピュータ・プログラム

Also Published As

Publication number Publication date
BRPI0502261A (pt) 2006-02-21
CN1719410A (zh) 2006-01-11
EP1615129A3 (en) 2008-02-13
AU2005202252A1 (en) 2006-02-02
US20060020446A1 (en) 2006-01-26
JP5815067B2 (ja) 2015-11-17
RU2386999C2 (ru) 2010-04-20
EP1615129A2 (en) 2006-01-11
RU2005117775A (ru) 2006-12-20
KR101076910B1 (ko) 2011-10-25
AU2011200375B2 (en) 2012-01-19
JP2012133806A (ja) 2012-07-12
KR20060049813A (ko) 2006-05-19
CA2509483A1 (en) 2006-01-09
JP2014142959A (ja) 2014-08-07
US7676791B2 (en) 2010-03-09
AU2011200375A1 (en) 2011-02-17
AU2005202252B2 (en) 2010-11-11
MXPA05006176A (es) 2006-01-12
CN1719410B (zh) 2010-12-08
JP5590572B2 (ja) 2014-09-17
JP2012009081A (ja) 2012-01-12

Similar Documents

Publication Publication Date Title
JP5815067B2 (ja) サービスの同時実行を実施するシステム及び方法
US8108834B2 (en) Defining and executing processes using declarative programming language constructs
Schmidt et al. Pattern-oriented software architecture, patterns for concurrent and networked objects
Schmerl et al. Exploiting architectural design knowledge to support self-repairing systems
Meyer et al. Automating data exchange in process choreographies
Posse et al. An executable formal semantics for UML-RT
JP2011129150A (ja) ビジネスプロセスの自動化
Tolosana‐Calasanz et al. Adaptive exception handling for scientific workflows
Riccobene et al. A formal framework for service modeling and prototyping
Ritter et al. Exception handling in message-based integration systems and modeling using BPMN
Kumar et al. Building Data Streaming Applications with Apache Kafka
Philips et al. NOW: Orchestrating services in a nomadic network using a dedicated workflow language
US20120191650A1 (en) Synchronizing database projects with partner projects
Yu et al. Dynamic software architecture oriented service composition and evolution
Pandey Kafka Streams-Real-Time Stream Processing
Baxter Mastering Akka
Lenhard A pattern-based analysis of WS-BPEL and windows workflow
Čukić A continuation‐based task programming model for C++: design of the Causeway library
de Faria A dynamic event processing framework for high performance streams
Sykes Autonomous architectural assembly and adaptation
Gomez et al. A Conversation-oriented language for B2B integration based on Semantic Web Services
Hafid et al. Using BPEL for Behavioral Concepts in ODP Computational Language
Ramollari Automated Runtime Testing of Web Services
Musiol A Process Engine Independent Architecture Enabling Robust Execution of Mobile Tasks in Business Processes
Wirtz Distributed Systems Group

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20080613

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20110708

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20111011

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20111028

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20120228