%\input{/Users/e155753/.tex/setup}

%%文書開始****************************
\begin{document} 
%%**************************************
\chapter{分散フレームワークChrisiteについて}
ここでは本研究室で開発している分散フレームワークChrisiteについて解説する. 
Chrisiteは複雑な分散プログラムを簡潔に書くことのできる構成となっている. 


\section{Chrisiteとは}
ChristieはJava言語で構成された本研究室独自の分散フレームワークである. 
同じく本研究室で開発を行っているGearsOSのファイルシステムに組み込む予定があるため, GearsOSを構成している本研究室の独自の言語Continuation based C (以下CbC言語)とにた, Gearというプログラム概念が存在する.

\begin{itemize}
\item CodeGear(以下 CG)
\item DataGear(以下 DG)
\item CodeGearManager(以下 CGM)
\item DataGearManager(以下 DGM)
\end{itemize}

CodeGearはクラスやスレッドに相当する. DataGear は変数データに相当し, javaのアノテーション機能を用いて記述する. 
CG内に記述したKeyに全てのDGが揃った際に初めてそのCGが動作するという仕組みになっている. CodeGearManager はいわゆるノードに相当し, CG, DG ,DGM を管理する. 
DataGearManager は DG を管理するもので,  put という操作により DG , つまり変数データを格納することができる. 

DGM の put 操作を行う際には Local と Remote と 2 つのどちらかを選び, 変数の key とデータを引数に書く. 
Local であれば, Local の CGM が管理している DGM に対し, DG を格納していく. 
Remote であれば接続した Remote 先の CGM の DGM に DG を格納できる. put 操作を行ったあとは, 対象の DGM の中に queue として保管される. 

DG を取り出す際には, CG 内で宣言した変数データにアノテーションをつける必要がある. javaのアノテーションとは注釈, 注記を意味し, java.lang.Annotationインターフェースを継承して独自のアノテーションを作成できる. DG のアノテーションには Take, Peek, TakeFrom, PeekFrom の 4 つがある.

\begin{description}
\item[Take] 先頭のDGを読み込み, そのDGを削除する. DGが複数ある場合, この動作を用いる.
\item[Peek] 先頭のDGを読み込むが, DGが削除されない. そのため, 特に操作をしない場合は同じデータを参照し続ける. 
\item[TakeFrom(Remote DGM name)] Takeと同様に読み込んだ後, DGを削除する. Remote DGM nameを指定することで, その接続先(Remote)のDGMからTake操作を行える.
\item[PeekFrom(Remote DGM name)] Peekと同様に読み込み後もDGが削除されないが, Remote DGM nameを指定することで, その接続先(Remote)のDGMからPeek操作を行える.
\end{description}

\section{プログラムの例}
以下のソースコード\ref{code:nStartHelloWorld} , \ref{code:HelloWorldCodeGear}のプログラムはChrisitieの基本動作となる DGM による put 操作を用いた hello world の出力プログラムである.  

メソッド sreateCGM でポート番号を指定した上で CGM を作成しする.
CGM にCG (クラスファイル)を指定した上でsetupすることでCGMが CGを動作させることができる. HelloWorldCodeGear()とFinishHelloWorld()がここではCGに当たる.  
HelloWorldCodeGear() クラスには String型の"helloWorld" という key が用意され,  "helloWorld"に入力された DG(String型の変数データ) をprint するコードである. 
当然key:helloWorldにはString型しか当てはめられない. 

"helloWorld" に hello と worldというDGをputすることで出力結果がhello world となる.  またhelloWorldのkeyはアノテーションがTakeである. 
従って, 一度目にhelloをputし, hello をprintした後, helloWorldのkeyの中身はなくなるため, 二度目のCG:HelloWorldCodeGearをsetupした際はworldを問題なくkeyにputできる.

もしhelloWorldのkeyがPeekアノテーションがついていた場合, 一度目のputにて入力されたhelloがkey:helloWorldに残り続けるため, CG:HelloWorldCodeGearをsetupするたびにCGが動作し, 以下のコード\ref{code:HelloWorldCodeGear}ではhelloをprintし続ける無限ループが起こってしまう. 

\newpage

\lstinputlisting[caption=StartHelloWorld,label=code:nStartHelloWorld]{./src/HelloWorld/StartHelloWorld.java}

\lstinputlisting[caption=HelloWorldCodeGear,label=code:HelloWorldCodeGear]{./src/HelloWorld/HelloWorldCodeGear.java}

\newpage

CGM は起動し続けていると処理が自動的に終了しないという問題点がある. 
そこで役目がなくなったCGM を終了させるための処理を行わなければならない.

 CGMを終了させるためのプログラムはソースコード\ref{code:FinishHelloWorld} であり, 二つのkeyが揃ったらcgm.getLocalDGM().finish() の処理でcgmを終了させるよう記述されている.

\lstinputlisting[caption=FinishHelloWorld, label=code:FinishHelloWorld]{./src/FinishHelloWorld.java}


\section{Chrisiteにおけるコマンドパターンの実装}
コード\ref{code:DoCommand}はChristie上でのコマンドパターン構成による命令の送り合いを実装したテストコードである.

17行目:RTCommand cmd = new RTCommand("Z", 0); にて命令コマンドのインスタンスを作成, 同時に命令の内容を入力する.
この場合, エディタバッファのオフセット0に文字列”Z”を入力するという意味の命令オブジェクトを作れる.

そして, 18行目:gm.getDGM("remote").put("command",cmd); にて作成したコマンドをリモートのDGMへ送信する.
実際に実装したコードにはこの命令にさらに発進したノード名やコマンド番号が含まれる.

\lstinputlisting[caption=命令オブジェクトを作成して送信するテストコード, label=code:DoCommand]{./src/StartRemoteTake.java}


\section{TopologyManager について}
ここではChrstie上でノード同士の接続をより簡潔にするために使われるTopologyManagerという機能について説明する.

TopologyManagerとはTopologyを形成するために, 参加を表明したノード, TopologyNodeにlabel を与え, 必要があればノード同士の配線も自動で行う機能である.  
TopologyManagerのTopologyの形成方法として静的Topologyと動的Topologyの二つの方法がある. 
静的Topologyはソースコード:  \ref{code:dotFile} のようなdotファイルを与えることでノードの接続を図 \ref{fig:dot} のように接続することができる. 例えばnode0 からはnode1 はright という名前で参照することができ, それぞれのノードが同じCG を実行してもlabel の与え方次第で想定したDG の差し合いを実現することができる. 

静的Topologyはdotファイルのノード数と同等のTopologyNodeがあって初めて, CodeGear が実行され, ノード数が合わないとエラーが表示される. 

\newpage

\lstinputlisting[caption=ringを構成するdotファイル, label=code:dotFile]{./src/ring.dot}

\begin{figure}[H]
\centering
  \fbox{
   \includegraphics[scale=1]{./images/ring.pdf}
  }
\caption{ソースコード \ref{code:dotFile} のdotファイルを図示化したもの}
\label{fig:dot}
\end{figure}

動的Topologyは参加を表明したノードを順番にTopologyの構成要素として接続していく物である. 
現在時点で実装済みのTreeの構成を例とすると

\begin{enumerate}
\item 参加したノードを順にroot(根)に近い要素として接続する.
\item Topologyの要素に構成されたノードはそれぞれ親, 子のノードを特定の名前(parent, child[n])で参照できる.
\item 途中参加したノードは, 木の末端要素として接続する.
\end{enumerate}
以上の形でTopologyが形成される. 

\newpage

コード:\ref{code:SRTE} はTopologyManagerを使用してTopologyを構成するコードである. 
String型のリスト(今回はmanagerArg)に構成したいTopologyの形状をdotファイル, もしくは実装済みの動的Topologyの構成型を設定し, TopologyManagerCondfigを起動することでTopologyManagerが起動できる. 

ソースコードではTreeを構成しており, for文でnodeNum 個分のノードを生成し, それぞれmanagerPortを記憶させている. 
これによりノードすべてがTopologyManagerによりTreeの構成要素として接続される.

現状では通信アルゴリズムの構成のため, dotファイルにより接続を行なっているが, 最終的にはStar型の動的Topology機能を作成し, 途中で参加してきたノードを接続が行えるようにする必要がある.

\lstinputlisting[caption=TopologyManagerによるTree型Topologyを構成するコード, label=code:SRTE]{./src/StartPrefixTree.java}




%%文書終了****************************
\end{document}