Aliceを拡張していく中でいくつかの問題点が明らかになり、これらを解決するにはAlice自体を再設計する必要があるとわかった。可読性の低いコードはプログラマの負担となるため、CSが何を待ち合わせているのかそのCSを見ただけで理解できるようにAPIを改善すべきである。+\section{setKeyは最後に呼ばなければならない}+setKeyメソッドをコンストラクタで呼ぶ際、setKeyメソッドを必ず最後に呼ばなければならない。++CSは内部で実行に必要なDSを数えている。poolへと送られNullPointerExceptionを引き起こす。++\lstinputlisting[label=src:NullPointerException,caption=NullPointerExceptionになる可能性がある]{source/ShowDataFailed.java}++ソースコード\ref{src:NullPointerException}は、for文でsetKeyとids.createをcntの回数呼び、動的にDSの取得数を決めようとしている。setKeyが最初に呼ばれた際に、DSの取得に成功すると実行可能と判断されてしまう。runの中でinfoの配列の要素だけ中身を表示させようとしてるが、2回目のasClassでNullPointExceptionを引き起こす。+今回の場合、コンストラクタ内をソースコード\ref{src:success}のように記述する必要がある。++\lstinputlisting[label=src:success,caption=NullPointerExceptionにならない記述]{source/ShowData.java}++このように記述の順序を考えながらプログラミングしなければならない設計では、バグを引き起こし信頼性を損なうことに繋がる。自然に扱えるAPI設計にするべきだと考える。setKeyはCSのコンストラクタで指定することが多い。このとき、指定するkeyは引数などから動的に受け取り、セットすることができる。辿ってもflipされている可能性もあるため、最初にそのDSをputしている部分を見つけるのは困難である。従って、待ち合わせているkeyにどのような型のデータが対応しているのかをそのCSを見ただけで分かるようにするべきと考える。2.4のCodeSegmentの例題である通り、key名とそのkeyで待ち合わせたDSを受け取るReceiver名は異なることがある。Alice自体の拡張・デバッグをしやすくするためにも、DSがどの型を持っているのかをひと目で分かるようにしたい。Aliceでは1つのノードにつき1つしかLocalDSMを立ち上げられない作りになっている。その一つがNAT越えの機能である。NAT越えは分散アプリケーション構築における課題の1つでもあるが、プログラマにとってその実装は容易ではない。ManagerにNATを越えたノード間通信機能をつけることにより、ネットワークを気にせずに通信が行えるようにしたい。\ref{fig:nat}はTopologyManagerを用いてNAT越えをするための設計である。別トポロジーで立ち上げたアプリケーション同士を接続する機能も追加したいと考えていた。TreeTopologyのVNCアプリとStarTopologyのチャットアプリを連携したいという要望が生まれたためである。\ref{fig:vncandchat})。1つのノードに複数のTopologyManagerを対応させるには、TopologyNodeが複数のnodeNameを持つ必要がある。TopologyNodeが複数のTopologyManagerに対応できるようにしなければならない。\ref{fig:somehostname})。Managerに対応できるという設計である。DSMを持つことはできなかった。3章でのAliceの問題点を踏まえ、新たにフレームワークを作り直すべきだと考えた。本章では、新たに作った分散フレームワークChristieの設計を説明する。+Christieに必要な要件は以下のように考える。基本的にはAliceと同じ、タスクとデータを細かい単位に分割して依存関係を記述し、入力が揃った順から並列実行するというプログラミング手法を用いる。DGはAliceと同様にDataGearManager(以下DGM)が管理する。DGMはLocalとRemoteがあり、全てのDGMはCodeGearManager(以下CGM)で管理される。GearsOSではContextという全てのCG/DGを一括管理するプロセスがあり、AliceのCGMもこのContextに相当する。-+全てのCGMはThreadPoolと他のCGM全てのリストを共有しているため、全てのCG/DGにアクセス可能である。CGを記述する際はAlice同様CodeGear.classを継承する。ChristieのAPIにはrunの引数で受け取ったCGMを経由しアクセスする。GearsOSではCG間でContextを受け渡すことによってCGはDGにアクセスするため、Christieでもその記述方法を採用した。InputAPIにはAliceと同じくTakeとPeekを用意した。指定にはAnnotationを使う。-Annotationとは、Javaのクラスやメソッド、パッケージに対して付加情報を記述できる機能である。-先頭に@をつけることで記述でき、オリジナルのAnnotationを定義することもできる。指定にはアノテーションを使う。Computationである。+先頭に@をつけることで記述でき、オリジナルのアノテーションを定義することもできる。AliceではInputの受け皿であるReceiverを作り後からkeyをセットしていたが、-ChristieではInputのためのDGを作り、その上にAnnotationでKeyを指定する(\ref{src:take})。+ChristieではInputのためのDGを作り、その上にアノテーションでKeyを指定する(\ref{src:take})。-Annotationで指定したInputDGは、CGを生成した際にCodeGear.class内で待ち合わせの処理が行われる。+アノテーションで指定したInputDGは、CGを生成した際にCodeGear.class内で待ち合わせの処理が行われる。これにはJavaのreflectionAPIを利用している。-Annotationの指定はRUNTIMEではできないため、動的なkeyの指定も防ぐことができる。+アノテーションの指定はRUNTIMEではできないため、動的なkeyの指定も防ぐことができる。\ref{src:take}の2行目にあるように、InputDGを宣言する際には必ず型の指定が必要となる。-DataGearは様々な型のデータを扱うためにJavaの総称型で受け取るようにしており、<>内に指定した型でデータの型を限定できる。内に指定した型でデータの型を限定できる。このように記述することで、Christieでは他の部分を辿らなくてもCGを見るだけでインプットされるデータの型が分かるように可読性を向上させた。取得してきたDGが指定と違う型であった場合はエラーとなるため、型の整合性を保ちながら信頼性の高いプログラミングが可能となった。Aliceではkeyと変数名の不一致から可読性が低くなっていた。Christieではkeyと変数名が一致しないとエラーとなるため、自然と読みやすいコードが書けるようになっている。-この部分に関しては、JavaのメタプログラミングAPIであるjavassist\cite{}を用いてAnnotationから変数の自動生成も試みたが、javassistでは変数生成の前に他のどのクラスも生成してはならないという制限があったため、Christieでは実現できなかった。+この部分に関しては、JavaのメタプログラミングAPIであるjavassist\cite{}を用いてアノテーションから変数の自動生成も試みたが、javassistでは変数生成の前に他のどのクラスも生成してはならないという制限があったため、Christieでは実現できなかった。-リモートノードに対してTake/Peekする際は、RemoteTake/RemotePeekのAnnotationを用いる(\ref{src:remotetake})。-そのため待ち合わせ先がLocalかRemoteかはAnnotationの違いからひと目でわかるようになった。+リモートノードに対してTake/Peekする際は、RemoteTake/RemotePeekのアノテーションを用いる(\ref{src:remotetake})。+そのため待ち合わせ先がLocalかRemoteかはアノテーションの違いからひと目でわかるようになった。createCGMの引数にはリモートノードとソケット通信する際使うポート番号を指定する。CGMを生成した際にLocalDGMやリモートと通信を行うためのDaemonも作られる。-CGの待ち合わせ処理はsetupメソッドが行う。+CGに対してアノテーションから待ち合わせを実行する処理はsetupメソッドが行う。そのためソースコード\ref{src:StartCodeGear}の13行目、\ref{src:TestCodeGear}の10行目のように、newしたCGをCGMのsetupメソッドに渡す必要がある。-AliceではnewすればCGが待ちに入ったが、Christieでは一度CGをnewしないとAnnotationから待ち合わせを行う処理ができないため、newの後にsetupを行う。+AliceではnewすればCGが待ちに入ったが、Christieでは一度CGをnewしないとアノテーションから待ち合わせを行う処理ができないため、newの後にsetupを行う。そのため、CGの生成には必ずCGMが必要になる。runでCGMを受け渡すのはこのためである。+なお、StartCGはインプットを持たないため、setupを行う必要がなく、newされた時点でrunが実行されuる。\chapter{今後の課題}+\section{TopologyManagerの実装}+Aliceと同じく、静的・動的なトポロジー管理のできるTopologyManagerの実装が必要である。+Christieでは複数のLocalDSMが立ち上げ可能なため、TopologyManagerでのNAT超えも実装し実用性があるかを検証する+また、通信の信頼性を保証するために、TopologyManagerがダウンした際に新たなTopologyManagerを立ち上げる機能もあるべきだと考える。++\section{検証機構の導入?}++\section{GearsOSへの移行}+GearsOSはまだ開発途中であったため、本論文の作成時点ではChristieのような分散機能を実装することが叶わなかった。Computationを実装する必要がある。+そしてChristieでは実現できなかったアノテーションからの変数の自動生成が行えれば更にプログラミングしやすいAPIになると考えられる。++\chapter{付録}+\section{独自のアノテーション定義}+Christieのアノテーションの実装方法と、そのアノテーションからtakeを実行する部分を解説する。++ソースコード\ref{src:take}、\ref{src:remotetake}がChristie独自のアノテーションの定義である。caption=RemoteTakeの実装]{source/christie/RemoteTakeAnnotation.java}++@Targetや@Retentionはアノテーション定義のためのアノテーション、メタアノテーションである。+@Targetには、フィールドやメソッド、コンストラクタなど、このアノテーションの付加対象となる構文要素が何かを記述する。+@Retentionには、SOURCE・CLASS・RUNTIMEが選択でき、アノテーションで付加された情報がどの段階まで保持されるかを定義する。reflectionAPIを利用するにはRUNTIMEでなければならないため、Christieのアノテーションの@Retentionは全てRUNTIMEである。++定義したアノテーションの仕様例がソースコード\ref{src:takeAno}、\ref{src:remotetakeAno}である。caption=RemoteTakeアノテーションの使用例]{source/christie/RemoteInputDG.java}++アノテーションを使う際、()内に記述する値が\ref{src:take}のvalueや\ref{src:remotetake}のdsmNameといったキーに保存される。+通常キーに対して値を入れる場合は、ソースコード\ref{src:remotetakeAno}のようにkey=の形で記述しなければならないが、Takeのようにキーが1つの場合、キー名をvalueにすることでその記述を省略することができる。++setupメソッド内では生成されたフィールドに対してアノテーションを含めた情報を処理している(ソースコード\ref{src:setup})。caption=reflectionAPIでフィールドの情報を取得]{source/christie/Setup.java}++これにはJavaのreflectionAPIが使用されている。+reflectionAPIでは対象となるクラスのフィールドやメソッド、それに対するアノテーションも取得できる。+フィールドから取得したDGとアノテーションから取得したkeyからインプットコマンド(TAKE/PEEK)を生成し、DGMへ送って実行する。++このとき要求したデータがDGM内にない場合はwaitListに入る。+PUTコマンドが実行された際、もしwaitListに同じkeyのDGを待っているコマンドがあれば実行される。+CGは生成したインプットコマンドの総数を初期値としたカウンタを持っており、コマンドが解決されるたびにカウンタは減っていき、0になった時、CGがThreadPoolへ送られる。教授を賜わりました河野真治准教授に深く感謝したします。設計・実装に関わった全ての方々に感謝いたします。W・クリスティーに敬意を評します。家族に心より感謝いたします。+そして、数々の貴重な御助言と技術的指導を戴いた伊波立樹さん、他フレームワークの調査に協力してくださった清水隆博さん、赤堀貴一さん、浜瀬裕暉さん、大城由也さん、並びに信頼研究室の皆様に感謝いたします。TreeVNCがなければ本研究はありませんでした。これら先行研究の設計や実装に関わった全ての先輩方に感謝いたします。++また、本フレームワークの名前の由来となったクリスティー式戦車の生みの親、ジョン・W・クリスティーに敬意を評します。++最後に、日々の研究生活を支えてくださった米須智子さん、菱田正和さん、情報工学科の方々、そして家族に心より感謝いたします。value();+}。