“Implementing Domain-Driven Design”の著者であるVaughn Vernon氏が先週，Dotseroを公開した。C#で記述され，Akka APIを忠実にフォローした.NETのアクタモデルツールキットだ。アクタモデルの実装であるAkkaツールキットでは，これまでJavaとScala用のAPIが公開されていた。
同じアクタモデルに基づいた，クラウドプログラミングモデルであるOrleansフレームワークのプレビューリリースは，今年の初めにMicrosoft Researchからリリースされている。スケーラブルで信頼性の高い双方向サービス構築時の課題を最小化することがその目標だ。
Orleansチームは，ErlangやAkkaなどのアクタプラットフォームについて，分散システムプログラミングの簡略化として一歩前進ではあるものの，提供する抽象化やシステムサービスが比較的低レベルであるがために，まだ多くの複雑さがあると考えている。これらを使って正しいソリューションを構築するには，開発者が分散システムのエキスパートでなければならない，というのが彼らの主張だ。このような複雑性を回避して，メインストリームの開発者を対象にするため，Orleansではアクタの抽象化レベルを高くしている。アクタベースではあるが，既存のアクタベースのプラットフォームとは違って，アクタを物理的存在ではなく，仮想エンティティとして扱うのだ。
Vemon氏は，Microsoft ResearchでOrleansプロジェクトのリーダを務めるSergey Bykov氏との先日のtwitterでの議論の中で，Orleansは真のアクタモデル実装ではないと主張した。アクタの定義に元来含まれると氏が主張する，有限状態マシン(FSM/Finite State Machine)をサポートするBecome/Unbecomeがサポートされていない，というのがその理由だ。さらに氏は，Orleansのアクタが常に存在するという事実は，存在していないものを探して具現化するというクライアントの動作を困難にするため，エラーの原因となりやすいと考えている。
Bykov氏はそれに対して，Becomeは定義を読み込む方法のひとつに過ぎず，アクタモデルの要件ではないと主張する。また，アクタが常に存在するOrleansの方法については，レースの発生が回避されてリカバリが単純になることから，エラーの発生がはるかに少ないことに気付いたのだという。アクタが存在すべきでないケースについては，エラーを返すアプリケーションロジックで処理されることになる。これが理想的な方法でないことは認めるものの，アクタ生成時のレース条件の発生よりは望ましいのだ。
Microsoft MVP for Azureを持つRichard Astbury氏は先日，簡単な“Internet of Things(モノのインターネット)”ゲートウェイアプリケーションを開発した。高スケール，低レイテンシで回復性を備えたクラウド用 .NETアプリケーションを開発する上でOrleansがいかに有用か，氏の見解をデモンストレーションすることが目的だ。ごく簡単な例ではあるが，より複雑なシナリオを構築するための基本的なビルディングブロックは含んでいる，と氏は述べている。
Orleansの基本となった設計思想を著した論文“Orleans: Distributed Virtual Actors for Programmability and Scalability”が５月に公開されている。
Vemon氏は，昨年のリアクティブなドメイン駆動設計(Domain-Driven Design/DDD)におけるアクタモデルについての講演以前にも，アクタモデルの基盤とDDDについて講演を行っている。