プロトコル

ブラウザが現在見ている部分と条件にあったリソースの検索を実行しながら結果をダイナミックに重ねる機能を実現するために、GLOBALBASE PROTOCOL は以下の3つのことを中心の無い分散環境上で提供する。
Mapping Resource によって与えられた双方向リンクをどちらの方向からもたどれるための情報を構成し、維持すること。(Mapping Protocol Layer) 任意に与えられた二つの座標系がどのように重なっているかが分かること。つまり、この二つの座標系を結ぶ、連続したマッピングの列がブラウザから求められること。(Routing Protocol Layer) 発信されたリソースに与えられたメタデータが検索可能であること。(PSE: Pertial Search Engine)

図2. にGLOBALBASE アーキテクチャを構成するプロトコルスタックを示した。このプロトコルスタックを下位のレイヤから説明する。
プロトコル全体の構成
すべてはTCP/IPの上に実装されている。また、サーバ同士も情報交換を行うので、サーバ・サーバ・プロトコルというのが存在する。

(1) XL層 (XLSession)
クライアント、サーバを問わず、GLOBALBASE のすべての情報交換は、XL プロトコルというプロトコル上に実装されている。XL とは、(XML LISP) の略であり、XML の構文をLISPのS式として解釈する言語である。XMLで記述されたドキュメントと親和性が高い、実行言語である。
また、リモート実行機能を備えているので、プログラム一部を他のサーバで実行できる。この機能を使い、サーバからのデータ転送などが実現できる。

(2) Mapping
Mapping は、GLOBALBASE の双方向リンクであるMappingを管理するプロトコルである。Mapping は、異なるサーバのリソース同士を双方向に結びつけるリンクであり、なおかつMapping 自身も両側のリソースとは別のサーバに置くことのできる独立したデータなので、マッピングをも含めた三者のリソースのどれからも、他の二つを引き出すことが出来るように、情報を交換するプロトコルである。
両側のリソースのそれぞれには、どのマッピングを通してどこのリソースへつながっているかという情報を集めた、マッピング・データベースが用意されている。情報発信者によりMapping がサーバに登録されるとサーバは、マッピングの両側のリソースのマッピング・データベースへ、Mapping の情報を登録する。マッピング・データベースへ登録された情報は常に期限があり、期限が来ると、抹消される。従って、Mapping を保持しているサーバは期限が来る前に、Mapping の両端のマッピング・データベースをポーリングし、期限を更新する必要がある。このマッピング・データベースへの登録とポーリングを実行するのがMapping 層である。

(3) (4) Routing
マッピング・データベースの存在により、ある地図(リソース)から別の地図(リソース)へと渡り歩くことが可能になる。しかし、任意の二つの地図(リソース)を与え、その二つを重ねたい、あるいは、その間をつなげたいと思ったとき、二つの間の連続する複数のマッピングをたどることが出来るだろうか。この任意のリソースの間をつなげる連続したマッピングの列をマッピング・パスとよび、このマッピング・パスを見つけることをルーティングと呼ぶ。
この問題を解決するのが、Routingである。まず、リソースのうち、座標リソースにすべてアドレスを振る。ここで、インターネットを思い浮かべてほしい。座標リソースが一台一台のコンピュータやルータ、座標リソースを結びつけるマッピングをコンピュータやルータを結びつけるネットワークだと思うと、座標リソースにIP アドレスのようなルーティング可能アドレスが振られていれば、マッピングのルーティングもネットワークと同じように出来るはずである。
しかしここで問題なのは、アドレスをどうやって振るかである。インターネットは世界中のネットワーク管理者によって、正確にIPアドレスが振られている。しかし、GLOBALBASEはいろんな情報発信者がどんどん発信するわけで、正確にアドレスを振ることなど不可能に近い。そこで、自動的にIPのようなルーティング可能アドレスを振る技術が必要となる。これがACRP (Auto-Configurated Routing Protocol)と呼ばれるものである。
(3)のサーバ・サーバ・プロトコルでは、 ACRPとルーティングの両方が動いているのに対して、(4) はルーティングのみのプロトコルである。

(5) (6) PSE (Pertial Search Engine)
GLOBALBASE では、クライアントは検索条件に従って、リソースをとってきて、重ねたりつなげたりして表示する。検索条件に従ってリソースを検索する仕組みが必要となる。サーバは、自分のちょっと大きな周りのリソースのメタデータを蓄え、検索条件を送ってきたクライアントに対して、合致するリソースを返答する。一方、クライアントは、自分の見ている周辺の情報があるデータベース(LUMP)にアクセスしなければならない。
まず、(5) サーバ・サーバ・プロトコルでは、Mapping 層で維持されているマッピングのネットワークをたどり、各座標系リソースからマッピングを何ホップたどると、Lump があるかという情報を座標系リソースごとに集積している。もし、ある座標系リソースからみて、周辺にLump が見あたらないか、ずっと遠くにある場合、その座標系リソースの位置にLumpを一つ生成する。また逆に、Lump を持っている座標系リソースの周辺にたくさんLumpがある場合は、そのLump を消去する。
また、(5) サーバ・サーバ・プロトコルでは、定期的に各リソースは、自分のメタデータを近くのいくつかのLump に登録する。このとき、各リソースがどの範囲のものか、あるいは、どのくらいの解像度かというメタデータは、Lump の位置の座標系に変換した値を登録する。このときに、下位のRouting によって得られたマッピング・パスを使って情報変換を行う。

(6) のクライアント・サーバ・プロトコルでは、クライアントの現在見ている位置にある座標系リソースの周辺にあるLump を見つけだし、そのLump に対して、条件検索を行うプロトコルが用意されている。
さらにクライアントは、見ている位置の変化、拡大縮小に伴い、定期的にLump に問い合わせをだし、新しい座標系リソースをキャッシュに加え、見ている位置からはずれた物をキャッシュから捨てる機能を持っている。この座標系リソースの変化に伴い、問い合わせ先の、Lump も異なってくる。こういった仕組みがRadarの仕組みである。

(7) Resource Access Mechanism
Radarにより、得られた情報を元に表示すべきリソースの本体をとってくるのが、 (7) である。リソースの本体が分離不可能な一つのファイルである場合は、HTTP のGETのような操作である。一方、リソースが階層構造を持っていて、解像度や見ている位置にあった部分的な情報を検索して持ってくることが出来る場合もある。
検索されたリソースは、Graphic Module により画面に表示される。
以上がGLOBALBASE ARCHITECTURE における GLOBALBASE PROTOCOL である。

  SourceForge.jp SourceForge.net Logo