\chapter{考察}

前章では Federated Linda と他の分散フレームワークとの比較を行い、
Federated Linda のプログラミングモデルとしての簡潔さを示した。Federated
Linda の記述の簡潔さは、ベースとした Linda のコマンド``in'', ``read'',
``out''を使ったタプルの出し入れという通信モデルと、分散プログラムを
``Local Access'', ``Protocol Engine'' ``Link Configuration'' の3 つの要素
に分け、それぞれで実装するモデルであることが理由として挙げられる。

タプルの出し入れは直観的に理解しやすいモデルであり、またタプルスペースの
中身を把握しやすいことがわかる。プロトコルエンジンでは、タプルをタプルス
ペースからタプルスペースへとリレー転送を行う。リレー転送はインターネット
のパケット転送に近く、インターネットの分散アルゴリズムを Federated Linda 
の上でスクリプト言語を用いて実装することができる。これはインターネットで
用いられているアルゴリズムの学習に適用できる。また逆にFederated Linda で
実装・検証したアルゴリズムをインターネット上で構築することも期待できる。

分散プログラムを3つの要素に分けたことで、それぞれの依存を抑えられ、各々
個別に開発・テストすることができた。プログラムを小さな単位に分けることで、
開発のサイクルを短くすることが期待できる。また、アプリケーション、プロト
コル、トポロジが相互に切替えることができるモデルなので、よりポータビリティ
の高いシステムが構築できるといえる。

Federated Linda は Perl, Python, Ruby で実装可能である。これらの言語は須
くリストやハッシュなどの基本的なデータ構造、ガベージコレクタや多くの拡張
モジュールなど、プログラミングに必要な諸要素が用意されている。これらの代
わりに C 言語などの低レベルの言語を使用すると、記述する量が増し、ソースは
複雑になり、可読性が下がる。また、ソースのメンテナンスも難しくなる。スク
リプト言語を使用することにより、分散プログラムのより中核である分散アルゴ
リズムに注力することができる。

Federated Linda ではタプルを出し入れして通信する時に、使用するプロトコル
やタプルのデータなどを事前に決めておく必要がある。Web サービスでは、
WSDL(Web Services Description Language)で、このようなことを定義できる。
WSDLは、Webサービスのポートのインターフェースを記述する。つまり、1. その
Webサービスがどこにあるのか、2. どんなフォーマットのメッセージを使用する
か、3. どんな通信プロトコルを使うか、という情報をXMLで記述できる。WSDLを
用いることにより、Web サービスのモジュールを呼び出すコードを自動生成する
こともできる。Federated Linda では、タプルスペースのタプルIDがポートとし
て利用される。よって、使用するタプルIDに依って、使用するプロトコルやタプ
ルのデータフォーマットが決まることが多く、WSDLのようなインターフェース言
語と親和性も高い。そして、そのようなインターフェース言語で記述することに
より、クライアントプログラムやプロトコルエンジンのプログラミングを支援す
ることが可能となる。

アプリケーション、プロトコルエンジンはタプルの出し入れというモデルとスク
リプト言語より、個々は簡潔に記述できる。しかし、より俯瞰的にシステムがど
う構築されるかを確認したり、デバッグしたりするツールが必要である。分散プ
ログラミング用のデバッガなどを用意すると、より開発しやすくなると思われる。

タプルスペースやプロトコルエンジンの接続は Link Configuration で使用する
XML で定義しており、トポロジは固定されたままである。接続の変化が頻繁に起
こる環境では、柔軟に対処することができない。より変化に強いトポロジ定義手
法が必要である。