アクターとAJAX

並列計算を実行するプログラムを作成するには、スレッドが広く使用されます。 スレッドはプログラムの並列処理を柔軟に構成できるという事実にもかかわらず、多くの欠点があります。 実際、スレッドはメモリを共有します。 これは、過失により、プログラムの整合性を侵害することは非常に簡単であることを意味します。 これは、一部のコードが共有リソースに排他的にアクセスできるようにするロックの助けを借りて克服できます。 ただし、ロック自体は、記憶する必要があるという事実に加えて、順番に問題を引き起こします。 最悪の問題の1つは、デッドロックを引き起こす能力です。 ただし、これがなくても、非常に適切に機能するマルチスレッドプログラムを作成することは宝石の仕事になります。



しかし、スレッドには代替手段があります。 私に知られている-俳優（俳優）とソフトウェアトランザクションメモリのモデル。 タイトルから明らかなように、この記事のヒーローが最初です。 しかし、あなたの好奇心を満たすSTMに関するインターネット上の記事は非常に多くあります。

アクターモデルとは何ですか？

インターネットには、アクターモデルへの参照がたくさんあります。 したがって、歴史、アプリケーション、使用パターンには触れずに、アクターとは何かについてのみ記述します。



したがって、アクターは次のようなオブジェクトです。

• 状態を互いに共有しないでください。
• 非同期メッセージを送信することによってのみ相互作用します。
• アクターは2つのメッセージを同時に処理しません。 代わりに、アクターは受信したメッセージをキューに収集し、順番に処理します。

アクターは、JMS、ActiveMQ、MSMQなどのさまざまなメッセージキューシステムを非常に連想させます。 さらに、多くのGUIフレームワークでは、アクターなどのコントロールは、非同期メッセージを使用して互いに対話します。

分散コンピューティング

並列コンピューティングで、同じ物理マシン上で計算が回転していると想像する必要があるのはなぜですか？ また、クラスターがある場合はどうなりますか？ 負荷の高いプロジェクトの場合、これは特に当てはまります。 遅かれ早かれ、それらは1台のマシンの境界に沿って休みます。 この場合のフローモデルはまったく適合しません。 スレッドには共有メモリがあります。 分散システムの場合に類似したものを実装しようとすると、ノード間のデータの同期に問題が発生します。異なるノードで実行されているスレッドは共有メモリを持っているように見えるためです。 しかし、アクターは、非同期メッセージを介してのみ互いに​​対話します。非同期メッセージは、ネットワークを介して適切に送信されます。



アクターには、分散コンピューティングの別の利点があります。 なぜなら アクターは自分の状態を誰とも共有しません;この状態自体は、ノード間のシリアル化と転送が簡単です。 一方、すべてのメッセージは非同期に配信されるため、アクターはメッセージに即座に応答する必要はありません。したがって、アクターが状態のシリアライズ/デシリアライズに時間を費やし、メッセージの処理を短時間延期することは正常です。

既存の実装

従来、アクターモデルは、アクターがネイティブにサポートされているErlangおよびScalaのプログラマーに愛されています。 Javaを含むさまざまな言語用のライブラリがあり、最も有名なものはAkkaです。 ハブには、このライブラリの概要があります。



しかし、Akkaを持っていても、俳優をサポートするための独自のライブラリを作成したいとは思いませんでした。 なぜこれが必要なのか、以下で説明します。 それまでの間、私は図書館で俳優がどのように働くかをお見せします。

nop.actors

フレームワークにアクターサポートを実装しました。 このメカニズムは、Akkaの型指定されたアクターに似ており、非同期メッセージの受け渡しのみがあります。



俳優をどのように説明しますか？ このためには、インターフェースを記述する必要があります。 アクターと実装によって処理されるメッセージのセット、つまり 実際にメッセージを処理します。 パターンマッチングがサポートされている言語で類似点を描画する場合、インターフェイスの記述は代数型宣言と同等であり、実装はパターンマッチング自体と同等です。 俳優の説明の例を次に示します。

@Actor public interface Pingable { void ping(String token, Pinger pinger); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

 @Actor public interface Pinger { void pong(String token); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

 public class DefaultPingable implements Pingable { @Override public void ping(String token, Pinger pinger) { System.out.println("Pinging with: " + token); pinger.pong(token); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、これがどのように使用されるかです：

 Pingable pingable = Actors.wrap(Pingable.class, new DefaultPingable()); pingable.ping("hello", new Pinger() { @Override public void pong(String a) { System.out.println("Ping received: " + a); } });
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

引数で渡されるデータには特定の制限があります。 非公式には、プリミティブ、POJO、他のアクターおよびリストのみを転送できるように理解できます。 正式には、次のように記述されます。 Sをメッセージで送信されるすべてのタイプのセットとします。 次に：

• プリミティブ型とラッパークラスはSに含まれています。
• アクターアノテーションでマークされたインターフェイスはすべてSに含まれます。
• 列挙型はすべてSです。
• リスト<T>、セット<T>、T [] TがSに入る場合はSを入力し、
• 各フィールドのタイプがSである場合、プライベートフィールドとそれらのそれぞれのアクセサメソッドのペアで構成されるクラスはすべてSに含まれます。

次に、HTTPプロトコルを介してアクターをリモートで使用可能にする方法を見てみましょう。 これを行うために、nopに統合され、フレームワークを使用するメカニズムがあります。 アクターをリモートでアクセス可能にするには、ActorManagerオブジェクトでexportActorメソッドを呼び出す必要があります。 ActorManagerは、依存性注入を通じて取得できます。

 public class PingController { private ActorManager actorManager; @Injected public PingController(ActorManager actorManager) { this.actorManager = actorManager; } public Content pingDemo() { ActorInfo fooInfo = actorManager.exportActor(new DefaultPingable()); //    ,    hello // ... } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

もちろん、nopフレームワークによって提供される機能を全体として使用する必要はありません。 すべての依存関係をドラッグする必要がない場合は、HttpActorDispatcherクラスをサーブレットに配置するだけで十分です。

ブラウザ側のアクター

リストされているアクターのプロパティは、アクターがブラウザーとWebサーバーの間で双方向にデータを積極的に交換する必要があるWebアプリケーションに最適であることを示唆しています。 しかし、これにはJavaScriptのアクターモデルのサポートが必要です。 そして彼女はnop.actorsにいます！



ブラウザ自体の内部でのみアクターを取得する場合、すべてがシンプルになります。 まず、アクタークラスのコンストラクターをアクター呼び出しでラップする必要があります。 次に、クラスのインスタンスをアクターにするには、アクターメソッドでラップする必要があります。 Pingerアクターの例では、次のようになります。

 DefaultPinger = actor(function(elem) { this.elem = elem; }); DefaultPinger.prototype.pong = function(token) { var messageElem = document.createElement("div"); messageElem.textContent = token; this.elem.appendChild(messageElem); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

 var pinger = actor(new DefaultPinger(document.getElementById("pingResult"))); pinger.pong("hello");
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ブラウザ側のアクターとWebサーバー側のアクターの相互作用を確実にしたい場合は、JavaScriptでインターフェースを記述する必要があります。 この例では、説明は次のようになります。

 Pingable = {}; Pinger = {}; Pingable.ping = ["value", actorRef(Pinger)]; Pinger.pong = ["value"];
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここでの一般原則はこれです。 アクターと通信するために必要なプロトコルは、オブジェクトとして記述されます。 オブジェクトのプロパティは、アクターによって処理されるメッセージに対応しています。 プロパティの値は常に、メッセージとともに渡される引数のタイプをリストした配列でなければなりません。 フレームワークは、次のタイプの引数を理解します。

• 文字列「値」は、任意のプリミティブ型または列挙型と一致します。
• actorRef（A）、ここでAはアクターの説明です。
• 1つの要素Aの配列は、引数がタイプAの要素を持つコレクションであることを示します。
• 任意のオブジェクトはPOJOを意味し、オブジェクトのプロパティの値はPOJOプロパティのタイプを示します。

ActorRemotingクラスは、リモートアクターの操作を担当します。 クラスを初期化して使用する例を次に示します。

 var remoting = new ActorRemoting("/actors/" + sessionId); var pingable = remoting.importActor(Pingable, nodeId, actorId); remoting.start(pregable.ping("hello", pinger);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

もちろん、サーバーはまずセッションID、ノードID、およびアクターIDをブラウザーに何らかの方法で渡す必要があります。 たとえば、これらの変数を初期化するJavaScriptコードをページに追加することで、ページを生成するときにこれを行うことができます。

完全な例

上記では、サーバー側とブラウザ側の両方でnopにアクターモデルを実装することについて説明しました。 ただし、当面は、これらすべてを1つの小さなアプリケーションにまとめる方法については黙っていました。 そのため、次のクラスも必要です。

 @Route(prefix = "pingpong") public interface PingRoute { @RoutePattern("/") String main(); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

 @RouteBinding(PingRoute.class) public class PingController extends AbstractController { private ActorManager actorManager; @Injected public PingController(ActorManager actorManager) { this.actorManager = actorManager; } public Content main() { ActorInfo pingInfo = actorManager.exportActor(Pingable.class, new DefaultPingable()); return html(createView(PingView.class).setActorInfo(pingInfo)); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

 public class PingView extends Template { PingView setActorInfo(ActorInfo actorInfo); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

 @ModuleRequires(modules = ActorsModule.class) public class PingModule extends AbstractModule { @Override public void load() { app.loadPackage(PingModule.class.getPackage().getName()); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

さらに、次の内容のPingView.xmlテンプレートを追加する必要があります。

 <?xml version="1.0" encoding="UTF-8"?> <t:template xmlns:t="http://nop.org/schemas/templating/core"> <t:head> <t:parameter name="actorInfo"/> <t:service name="actorsRoute" class="org.nop.actors.ActorsRoute"/> </t:head> <t:body> <html> <head> <title>A simple actors example</title> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/> <script src="${actorsRoute.resource('actors.js')}" type="text/javascript"/> </head> <body> <div> <input type="text" id="argument"/> <button id="pingButton" type="button">Ping</button> </div> <div id="pingResult"/> <script> Pingable = {}; Pinger = {}; Pingable.ping = ["value", actorRef(Pinger)]; Pinger.pong = ["value"]; DefaultPinger = actor(function(elem) { this.elem = elem; }); DefaultPinger.prototype.pong = function(token) { var messageElem = document.createElement("div"); messageElem.textContent = token; this.elem.appendChild(messageElem); } var pinger = actor(new DefaultPinger( document.getElementById("pingResult"))); var remoting = new ActorRemoting("/actors/${actorInfo.sessionId}"); var pingable = remoting.importActor(Pingable, ${actorInfo.nodeId}, ${actorInfo.actorId}); remoting.start(); var argumentElem = document.getElementById("argument"); document.getElementById("pingButton").onclick = function() { pingable.ping(argumentElem.value, pinger); } </script> </body> </html> </t:body> </t:template>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

すぐに実行できるサンプルはこちらからダウンロードできます 。

俳優のチェス

ここでは、すべてが明らかであるように思われます。3人の俳優がゲームに参加しています：2人のプレイヤーと1つの競技場 最後の俳優は、プレーヤーの動きをチェックし、互いの動きを通知します。 したがって、そのようなインターフェースについて書くことができます：

 @Actor public interface Board { void registerPlayer(Player player, PieceColor color); void move(Player player, BoardLocation source, BoardLocation destination); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

 @Actor public interface Player { void moveRejected(); void moved(BoardLocation source, BoardLocation destination); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ボードの実装は、プレイヤーが間違った動きをしたか、時間通りに行かなかった場合、明らかにmoveRejectedメッセージをプレーヤーに送り返します。 移動したメッセージは両方のプレイヤーに送信されます。 歩行者へ-移動の確認のサインとして、対戦相手へ-対戦相手の進捗状況の通知として。



それはまさにこのインターフェースが非常に素朴になっているということです。 自分で移動したプレイヤーは、誰に代わって移動が行われたかを示します。 攻撃者はこれを知らないうちに使用できます。 さらに、何らかの理由で、俳優プレーヤーの1人が「倒れた」場合、彼はゲームの状態を復元する方法がありません。 そこで、これらの欠点を克服するために次のインターフェースを作成します。

 @Actor public interface Board { void authorizePlayer(PlayerObserver observer, String key); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

 @Actor public interface Player { void move(BoardLocation source, BoardLocation destination, PieceType promotedType); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

 @Actor public interface PlayerObserver { void authorizationAccepted(PieceColor color, Player player); void authorizationRejected(); void moveRejected(); void boardStateChanged(BoardState state); void moved(BoardLocation source, BoardLocation destination); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これが起こったことです。 これで、プレーヤーはPlayerObserverインターフェイスの背後に隠れています。 そして、競技場は1人のボードと1人のプレーヤーで表されます。 プレイヤーは、特定のプレイヤーが利用できる競技場の一種です。 ゲームに入ると、アクタープレーヤーはゲームフィールドにパスワードを通知し、自分へのリンクを送信します。 authorizationAcceptedメッセージの形式で、競技場から確認を受け取ります。 さらに、ゲームに接続することにより、アクターはメッセージboardStateChangedの形式で現在の競技場のステータスを受け取ります。



PlayerアクターとBoardアクターの両方が互いに状態を共有する必要があることに注意してください。 本当にそうです、nopはこれをサポートしています。 これは、さまざまな角度から見ることができる1つの俳優であると言えます。 authorizePlayerのメッセージ処理は、実際には次のようになります。

  @Override public void authorizePlayer(PlayerObserver observer, String key) { boolean matches = false; for (PlayerImpl player : players.values()) { if (player.token.equals(key)) { observer.authorizationAccepted(player.color, player); sendFullState(observer); player.setPlayerObserver(observer); updateObserverList(); matches = true; break; } } if (!matches) { observer.authorizationRejected(); } } private void sendFullState(PlayerObserver observer) { BoardState state = new BoardState(); //      . // ... observer.boardStateChanged(state); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここでは、ボードがメッセージを処理している間、プレイヤーはオブザーバーに渡されます。 なぜなら プレーヤーは明らかにアクターになっていないため、フレームワークは自動的にそれを作成し、同時にボードとマージします。 実際、他と共通の状態を持たない新しいアクターを作成するには、Actors.wrapを使用して明示的にアクターにする必要があります。



ボード/プレーヤーの完全なアクターコードはこちらにあります 。



JavaScriptの一部の場合、アクターインターフェースの説明が必要です。 これは次のようなものです。

 Board = {}; Player = {}; PlayerObserver = {}; BoardLocation = { row : "value", column : "value" }; PieceState = { type : "value", color : "value", location : BoardLocation }; Move = { source : BoardLocation, destination : BoardLocation, piece : "value", capturedPiece : "value" }; BoardState = { moves : [Move], pieces : [PieceState] }; Board.authorizePlayer = [actorRef(PlayerObserver), "value"]; Player.move = [BoardLocation, BoardLocation]; PlayerObserver.authorizationAccepted = ["value", actorRef(Player)]; PlayerObserver.authorizationRejected = []; PlayerObserver.moveRejected = []; PlayerObserver.boardStateChanged = [BoardState]; PlayerObserver.moved = [BoardLocation, BoardLocation];
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

PlayerObserverの実装は、サーバーからメッセージが届くとページを再描画し、プレーヤーがフィギュアを移動するとサーバーにメッセージを送信します。



ブラウザアクターの完全な実装は、 ここから入手できます 。



チェスの例は、デモアプリケーションとしてnopフレームワークの配布に含まれています。 アプリケーションコードは/ demo / chessフォルダーにあります。 完成したサービスも上げました。

メリット

透過的なメッセージングを実現できることに加えて、nop.actorsは次のことも実行できます。



まず、フレームワークは完全にモジュール化されています。 プロセス内のアクターのメカニズムの実装があります。 プロセス内のアクターの上にリモートアクターの実装があり、この実装は任意のトランスポートを使用できます。



第二に、バージョン3.0のサーブレットを使用したロングポールリクエストの非同期処理。 1000のクライアントがサーバーに接続している場合、これは何もしない1000のスレッドを作成することを意味しません。



第三に、システムは自動的にアンロードし、アクターをディスクに何もせずにメモリを解放します。 さらに、アクターの存続期間は潜在的に無限です。