World Wide Webに続くもの

White Paperから、JXTAの構造を示した図を紹介しよう(図1)。

図1

最下部に位置するのはいわゆるプラットフォームの部分で、ハードウェアやOS、ネットワークプロトコルなどだ。SolarisやWindowsといったOSから下の部分だと言ってもよいだろう。この上に、JXTAの基本構造が大きく2層に分かれて積み上げられる。基本となるのがJXTA Coreで、P2Pシステムに必須となる基本機能を実現する。そして、その上にJXTA Services層がより上位のサービスを提供するために実装される。この関係は、X Window Systemで言うところのxlibとツールキット／ウィジェットセットの関係に似ていると表現できるかもしれない。最上位に位置するのがJXTA Applications層だが、これは下2層の機能を利用して実装されるユーザーアプリケーションであり、いわゆるシステムには含まれない。

JXTAは、アプリケーションを実現するための土台を提供するものだ。一般にP2Pというと、即座にGnutellaやNapstarのような具体的なアプリケーションを思い浮かべてしまうが、これらはP2Pアプリケーションである。GnutellaやNapstarが代表的な存在とイメージされてしまうと、「P2Pとは、サーバなしでファイル交換を行なうシステムである」と短絡してしまいそうになるが、これはもちろん正しくない。ファイル交換は1つの応用例に過ぎないのである。

では、P2Pとは結局のところ何なのだろうか? 筆者は以前JXTAについて「P2Pアプリケーションのポイントは『ダイナミックな情報検索手段の実装』といえる」と書いたことがあるが、公開されたJXTAの資料を見る限り、これはそう的外れではないようだ。JXTAでは、基本となるのはpeer間で公開情報をやりとりしてサービスやリソースを見つけだし、それを実際に交換する、という機能が中心になっている。この“リソース”がファイルであれば、ファイル交換アプリケーションとなるわけだし、CPUパワーそのものであれば、SETI@Homeのような分散処理アプリケーションとなる。

JXTAが提供する基本的な機能は、peer間での情報交換である。これには、peerを見つけだすこと、peerをグルーピングしてセキュリティポリシーを適用できるようにすること、peer間で交換する情報の標準フォーマットを定義すること、peer間での情報交換のための通信インターフェイスを確定すること、といった感じである。逆に言うと、JXTAではこれしか実現されない、という言い方も可能であろう。ただし、実際にはこれだけあれば相当いろいろなアプリケーションが作れそうなのだが、アプリケーションの可能性については実際のデモを見ながら改めて触れることにしたい。

JXTAでは、標準データフォーマットとしてXMLを利用している。ただし、XMLに依存しているというわけではない。また、現在のJXTAのデモコードはJavaで実装されているが、プログラミング言語としてJavaが必須というわけでもない。このあたりは、TCP/IPとよく似ている。今どきTCP/IPはどんなOSでも実装されているし、さまざまな言語が使われているはずだ。JXTAも同様に、エンタープライズサーバからPC、PDAや携帯電話など、さまざまな環境で利用されることを想定しているので、特定の環境に依存するような仕様は含まれていない。

さて、JXTAの基本要素として筆者がポイントと考えたのが、AdvertisementとCodatである。実は、どちらも実体として同じものと考えることもできそうだが、一応分けておこう。Advertisement(どう訳してよいかよく分からない。意味を汲んで意訳すると“公開情報”という感じだろうか)は、peerが外部に発信する情報である。ここには、自分が提供するリソースの種類やアクセスの際のセキュリティに関する情報などが含まれる。逆に、ほかのpeerにあるリソースを探す場合も、ここに探したいリソースの手がかりを記述する。実体としてはXMLデータである。JXTA環境では、peerはAdvertisementを発信／受信することでほかのpeerの情報を取得する。一方、CodatはCODE+DATAの意味の造語だそうである。これも実装上はXMLデータという形であるが、ここには、各種のプロパティ値(Advertisementの場合は、これが主となる)、テキスト、バイナリデータ、実行可能コードなど、ありとあらゆるものが格納できる。そして、JXTAでpeer間で交換されるのはこのCodatである。つまり、ごく単純化してしまうと、JXTAとは、Advertisementを交換することで目的のCodatを持つpeerを探し、そのCodatを入手するためのメカニズムである、とも表現できそうだ。

通信インターフェイスとしては、「パイプ」が用意される。UNIXのシェルで利用されるパイプ(“|”)と同様で、プログラムとプログラムを接続する働きをする。発想としては、UNIXのパイプをpeer間に拡張したもの、と言える。ただし、インターネットのような環境を前提としているため、JXTAのパイプは非同期で、信頼性が低く、片方向通信をサポートする通信路、と想定されている。筆者の印象としては、使われ方を見る限りこれはパイプというよりは通信バッファという感じだ。peer間の通信にパイプを利用する場合、発信側のpeerの出力パイプにCodatを送り、この出力パイプを受信側peerの入力パイプに接続(Bind)する。受信側peerでは入力パイプをプログラムで読み出せばCodatを受け取れるわけだ。ただし、UNIXのパイプとは違い、データ転送が終了したら即座に破棄されるわけではない。実際には、一度接続したパイプを切断し、再度別のpeerに接続して同じデータを複数のpeerに配布するようなこともできるようだ。この点で、データを一時格納しておくバッファに近い動作をする。

さて、これですでにある代表的なP2Pアプリケーションを実現するための基本的なメカニズムはできあがっている。AdvertisementとしてローカルにあるMP3ファイルの局名やアーティスト名などを含むリストを交換しあい、欲しい曲のMP3データをCodatに格納して送ってもらうようなアプリケーションを作成すれば、Napstarと同様の仕掛けがすぐにできあがる。また、Codatに分析のためのコードと分析したいデータを格納して多数のpeerに配布し、分析結果を送り返してもらうようにすればSETI@Homeのような仕掛けも実現できる。

P2Pはネットワークの1つのモデルであり、アプリケーションではない。従って、P2PのためのフレームワークであるJXTAは、一見なんと言うこともない地味な機能を実装することになる。P2Pは、現在のWebとサーチエンジンの組み合わせではカバーできない領域を対象とした、リソース発見のためのモデルだといえるが、筆者には画期的なアイデアとは思えない。ただ、補完的に利用できれば便利だろうと思うのは間違いない。とはいえ、JXTAを見れば、思い浮かぶP2Pアプリケーションの多くが比較的簡単に実装できそうな気がしてくるのは確かで、この点でJXTAはけっこう価値が高いものかもしれない、とも思う。