メッセージングのモード（PullとPush、AskとTell）について、まとめ

■ 「Pull」と「Push」

 

一般的なクライアント・サーバーモデルにおいて、クライアントがサーバーにデータを取りに行く動作モードを「Pull」、サーバー側がトリガーとなってクライアント側へデータを送り出す動作モードを「Push」といいます。

 

*:背景赤色はトリガーとなる側のノード

 

Pull … データ受領者が、能動的にデータを取りに行くモード

Push … データ受領者から見て、受動的にデータが送り付けられてくるモード

 

	制御の方向	データの流れ	同義	備考
Pull	受領者 → 提供者	受領者 ← 提供者	Request-Reply (Request-Response)	参照操作に同じ
Push	受領者 ← 提供者	受領者 ← 提供者	Notification	いわゆる「通知」

 

「Pull」か「Push」かという話は、「制御の方向」と「データの流れ」で分解してみると、「データの流れ」を受け取る方向で固定したとき、受領側がトリガーとなった操作か、提供側がトリガーとなった操作か、という違いになっていることがわかります。

■ 「Ask」と「Tell」

 

「Ask」、「Tell」とは、アクターモデルにおけるメッセージングモードを表す用語です。アクターモデルでは、通信する２つのノードは対称であり、クライアント・サーバーモデルのような“主従関係”はありません。

 

*:背景赤色はトリガーとなる側のノード

 

Ask … アクターモデルにて、あるアクターが他のアクターへデータを要求するモード

Tell … アクターモデルにて、あるアクターが他のアクターへデータを提供するモード

 

AkkaにおけるAskとTell：

http://doc.akka.io/docs/akka/snapshot/scala/actors.html#Send_messages

 

	制御の方向	データの流れ	備考
Ask	主体となるアクター → 他のアクター	主体となるアクター ← 他のアクター	参照操作に対応
Tell	主体となるアクター → 他のアクター	主体となるアクター → 他のアクター	更新操作に対応

 

「Ask」か「Tell」かという話は、「制御の方向」と「データの流れ」で分解してみると、「制御の方向」を主体側からの能動的な操作に固定したときに、その操作はデータを受け取るものか、データを送り出すものか、という違いになっていることがわかります。

 

■ 俯瞰的に整理してみると・・・

 

二つのノードCとSがあって、両者間でメッセージ交換が為されるとしたときの「制御の方向」と「データの流れ」の組み合わせを列挙して、まとめてみます。

 

*:背景赤色はトリガーとなる側のノード

制御の方向	データの流れ	説明	A(*1)	B	C	命名するならば、
C → S	C ← S	CがSに対しデータ提供を要求する	“Pullする”	Pull	Ask	普通に「参照」
C → S	C → S	CがSへデータを提供する	“Pushする”	-	Tell	普通に「更新」
C ← S	C ← S	SがCへデータを提供する	“Pushされる”	Push	(Tellされる)	いわゆる「通知」
C ← S	C → S	SがCへデータ提供を要求する	“Pullされる”	-	(Askされる)	いわば「待ち受け」

*1:ノードCを主体とした場合の表現

「制御の方向」と「データの流れ」の方向の組み合わせで4パターン列挙できることとなります。4つのパターンを、一方のノードCを主体として固定して「Push」と「Pull」の用語で表現してみると、上記表の「列A」のようになります。そして、いわゆる「Pull」と「Push」がそれぞれどこに位置付くかを「列B」に、「Ask」、「Tell」がどこに位置付くかを「列C」に示しました。

 

「列B」を見るに、通常単に「Pull」といった場合は、主体側（ノードC）から見て“Pullする”というモードであり、通常単に「Push」といった場合は、主体側（ノードC）から見て“Pushされる”というモードだということがわかります。また、「Pull」、「Push」の用語は、もっぱらデータを受領する方式について語るもので、主体側ノードが相手側ノードへデータを提供する方式については言及が無いことがわかります。

 

「列C」の「Ask」、「Tell」の用語は、主体側が能動的に起こす操作について語っており、受動的なモードについては言及が無いことがわかります。というよりも、アクターモデルでは通信する二つのノードは対称的なものと捉えるので（＝クライアント・サーバーモデルのような非対称性は想定しないので）、受動的なモードとは、単に主客の立場を変えて能動的なモードとして捉え直す、ということになります。

 

ところで、アクターモデルでは非同期性を想定するので、上記表の「命名するならば、」列のように「 Ask」＝「参照」、「Tell」＝「更新」に対応付けるのはやや粗いかもしれません。しかし、同期通信における参照操作、更新操作を非同期通信における相当する操作として再定義したものが「Ask」、「Tell」なのだと理解することで、一定の抽象度において同一視できると考えます。

 

上記表の下二つのパターンは、上二つのパターンのトリガーとなる側が逆になった場合となります。アクターモデルのように通信する二つのノードが対称的なものと想定するなら、単に主客を変えて表現しているだけで基本的には同一のメッセージングモードだと理解されます。対して、二つのノードをクライアント・サーバーモデルのように非対称なものと想定するなら、下二つのパターンは上二つとはまた別のメッセージングモードだと認識する必要があります。別のメッセージングモードだと捉える立場において、「SがCへデータを提供する」パターンは、いわゆる「通知」と命名できます。上記表最後の「SがCへデータ提供を要求する」というパターンは、イメージとしてはいわば「待ち受け」と言えるでしょう。ただ、「待ち受け」的な通信モードが直接設計、実装されることはたぶんあり得無くて、実際的には「待ち受け」の要件は常に「通知」と「更新」の組み合わせに分解されるでしょう。

 

◆以上