# HG changeset patch
# User Shinji KONO <kono@ie.u-ryukyu.ac.jp>
# Date 1524487678 -32400
# Node ID b81702f6108a31c3360c35b3f806018c6e00b422
# Parent  f55662d3643f322b1b4e3dbe13631ccbf34bd1f9
fix

diff -r f55662d3643f -r b81702f6108a paper/sigos.tex
--- a/paper/sigos.tex	Mon Apr 23 19:50:25 2018 +0900
+++ b/paper/sigos.tex	Mon Apr 23 21:47:58 2018 +0900
@@ -315,7 +315,7 @@
 \section{分散フレームワークChristieの設計}
 
 以上の問題を踏まえ、新しい分散フレームワークChristieの設計とプロトタイプの実装を行った。
-Christieに必要な要件は以下のように考える。
+Christieに必要な要件は以下のように考えた。
 
 \begin{itemize}
 \item {\ttfamily create/setKeyのような煩雑なAPIをシンプルにし可読性を向上させる}
@@ -326,13 +326,119 @@
 \item {\ttfamily これらの仕組みを実現するメタ計算機構を提供する}
 \end{itemize}
 
+Chirstie では、CodeSegment/DataSegment と呼ばずに、CodeGear/DataGear と呼ぶ。これは将来的にはGears OSにより実装するためである。
+
+Alice のAPIの問題は、送信するオブジェクトの型を前もって指定できないことと、記述する場所に自由度があることが問題になっている。
+そこで、DataGear を Java のAnnoationを用いて宣言することにした。これに関しては、実装を行ない、妥当なAPIを決定した。
+これについは次節で説明する。
+
+Alice のSingleton は広範囲で使われており、Refactoring では修正できない。そこで、Christie では基本的な部分を再実装することにした。
+
+Jungle との整合性では、Alice と Jungle の両方にオブジェクトのデータベースが存在することが良くない。Jungle では変更ログを
+Aliceにより送信しているが、これはリスト構造を送信することに相当する。Jungle では木の変更を伝搬させるが、これは木構造そのものを
+通信しているのと同等である。つまり、Alice の通信を木構造を持つオブジェクトにまで拡張することが可能だと考えられる。
+
+Jungleの木構造と、AliceのTuple空間の違いは、変更時の同期方法にある。Jungle では木はラベルにより指定されて、その変更はトランザクション
+として失敗と成功がある形で直列化される。Alice の同期機構は、Data Segment の待ち合わせによって行われる。単一のData Segment を
+待ち合わせれば、それは単一のトランザクションと同等になる。複数のData Segmentを待ち合わせる形の同期は Jungle では実現できない。
+Jungle の木をキーに対応する Data Segment とすることよって、Alice により Jungle のトランザクションを実現できる。
+
+Jungleの木のラベルは大域的なIDである必要があるが、特に構造を持たせていない。Alice のラベルは、接続された2点間でのみ有効になっている。
+従って、Jungle の木のラベルは分散システムの中で管理する必要がある。通常のURIのように木構造を持った構造として分散管理することが
+望ましい。つまり、Jungle の木のラベルはJungle 自体で管理される木構造であるべきだと思われる。これはファイルシステムのパスに
+相当する。Christie はGears OSでの分散ファイルシステムとして使えるのが望ましい。
+
+\section{アノテーションの導入}
+
+InputAPIにはAliceと同じくTakeとPeekを用意した。
+ChristieではInput DG の指定にはアノテーションを使う。
+アノテーションとは、クラスやメソッド、パッケージに対して付加情報を記述できるJavaのMeta Computationである。
+先頭に@をつけることで記述でき、オリジナルのアノテーションを定義することもできる。
+
+AliceではInputの受け皿であるReceiverを作り後からkeyをセットしていたが、
+ChristieではInputとなる型の変数を直接宣言し、変数名としてkeyを記述する。
+そして、その宣言の上にアノテーションでTakeまたはPeekを指定する(ソースコード\ref{src:takeex})。
+
+\lstinputlisting[label=src:takeex, caption=Takeの例]{src/InputDG.java}
+
+
+アノテーションで指定したInputDGは、CGを生成した際にCodeGear.class内で待ち合わせの処理が行われる。
+これにはJavaのreflectionAPIを利用しており、アノテーションと同時に変数名も取得できるため、変数名によるkey指定が実現した。
+
+Christieのこのインプットアノテーションはフィールドに対してしか記述できないため、keyの指定とTake/Peekの指定を必ず一箇所で書くことが明確に決まっている。
+そのためAliceのように外のCSからのkeyへの干渉をされることがない。
+このように、アノテーションを用いたことで、Aliceの記述の分離問題が解決された。
+また、keyを変数名にしたことで、動的なkeyの指定や、keyと変数名の不一致による可読性の低下を防ぐことができた。
+
+リモートノードに対してTake/Peekする際は、TakeFrom/PeekFromのアノテーションを用いる(ソースコード\ref{src:remotetake})。
+
+\lstinputlisting[label=src:remotetake, caption=TakeFromの例]{src/RemoteInputDG.java}
+
+なお、圧縮のMeta ComputationはAliceと同様で、指定する際にDGM名の前にcompressedをつける(ソースコード\ref{src:compresslocal})。
+
+\lstinputlisting[label=src:compresslocal, caption=Remoteから圧縮して受け取る例]{src/CompressLocal.java}
 
 
+OutputAPIにはput/flipを用意した。
+基本的なシンタックスはAliceと同様だが、Christieではput/flipのメソッドはCodeGear.classに用意されている。
+そのためCodeGear.classを継承するCGで直接putメソッドを呼ぶことができる(ソースコード\ref{src:remoteput})。
+
+\lstinputlisting[label=src:remoteput, caption=putの例]{src/RemotePut.java}
+
+そのため、ChristieにはAliceのODSにあたる部分がない。
+ODSを経由するより直接DGMに書き込むような記述のほうが直感的であると考えたためである。
+圧縮を指定してのputも、Alice同様DGM名の前にcompressedをつける。
+
+
+\subsection*{型の整合性の向上}
+ChristieではReceiver型ではなく直接変数を宣言する。
+そのため他の場所を辿らなくともCGを見るだけでインプットされるデータの型が分かるようになった。
+また、変数を直接宣言するため、そもそもAliceのようにasClassメソッドで型の取り出す必要がない。
+ソースコード\ref{src:getdata}はInputDGのデータを扱うである。
+
+\lstinputlisting[label=src:getdata, caption=InputDGを扱う例]{src/GetData.java}
+
+InputDGとして宣言した変数の型は、reflectionAPIにより内部で保存され、リモートノードと通信する際も適切な変換が行われる。
+このようにプログラマが指定しなくとも正しい型で取得できるため、プログラマの負担を減らし信頼性を保証することができる。
+
+以下のコードはLocalDSMにputしたDGを取り出して表示するのを10回繰り返す例題である。
+
+\lstinputlisting[label=src:StartCodeGear, caption=StartCodeGearの例]{src/StartTest.java}
+\lstinputlisting[label=src:TestCodeGear, caption=CodeGearの例]{src/TestCodeGear.java}
+
+Alice同様、ChristieでもInputDGを持たないStartCGから処理を開始する。
+StartCGはStartCodeGear.classを継承することで記述できる。
+AliceではStartCSもCodeSegment.classを継承して書かれていたため、どれがStartCSなのか判別しづらかったが、Christieではその心配はない。
+
+StartCGを記述する際にはcreateCGMメソッドでCGMを生成してコンストラクタに渡す必要がある。
+ソースコード\ref{src:StartCodeGear}の8行目でそれが行われている。
+createCGMの引数にはリモートノードとソケット通信する際使うポート番号を指定する。
+CGMを生成した際にLocalDGMやリモートと通信を行うためのDaemonも作られる。
+
+CGに対してアノテーションから待ち合わせを実行する処理はsetupメソッドが行う。
+そのためソースコード\ref{src:StartCodeGear}の13行目、ソースコード\ref{src:TestCodeGear}の10行目のように、newしたCGをCGMのsetupメソッドに渡す必要がある。
+AliceではnewすればCGが待ちに入ったが、Christieでは一度CGをnewしないとアノテーションから待ち合わせを行う処理ができないため、newの後にsetupを行う。
+そのため、CGの生成には必ずCGMが必要になる。
+runでCGMを受け渡すのはこのためである。
+なお、StartCGはインプットを持たないため、setupを行う必要がなく、newされた時点でrunが実行される。
+
+\subject{まとめ}
+
+分散木構造データベースJungleと、分散フレームワークAliceについて考察し、両者を統一する形で、分散フレームワークChristieを
+提案した。
+
+Christie ではアノテーションを用いて、Aliceの欠点であった記述の分離と型の整合性をコンパイル時に解決できない問題を解決した。
+
+Jungle の構造をChristieに内蔵することにより、ChristieのData Gear は、分散環境で共有、あるいは、持続性を持つことができるようになる。
+そのData Gear へのアクセスに、大域的な木構造を持つラベルを用意することで、ChristieのData Gearをファイルシステムのように
+使えるようになる。
+
+将来的には Gears OS でのファイルシステムとしてChristieを使えるように、持続性、DataGearにアクセスするパスとしての木構造、分散環境での
+同期手法を研究していく予定である。
 
 
 
 %参考文献　
-\nocite{*}
 \bibliographystyle{ipsjunsrt}
 \bibliography{sigos}