Comments
Description
Transcript
アドホックグループを対象とした 協調作業支援フレームワークの提案と
慶應義塾大学総合政策学部卒業論文 アドホックグループを対象とした 協調作業支援フレームワークの提案と実現 小松 純 概要 アドホックグループを対象とした協調作業支援フレームワークの提案と実現 本研究の目的はアドホックグループを対象とした協調作業支援環境の構築方法 の提案と実現である。本研究では、Peer to Peer(P2P) モデルのサービスにおける ブートストラップ問題、オフライン同期問題を一般的なサービス資源を利用した 擬似ノードによって解決することで、これを実現する。 近年、いわゆる「プロジェクトチーム」や「タスクフォース」といった特定の目 的の達成のために一時的に構成されるようなグループの事例が多く見られるよう になった。このようなグループを本論文では「アドホックグループ」と呼ぶ。 既存の協調作業支援環境の多くは企業等の継続的で大規模な組織を主な対象と しており、アドホックグループでの利用においてサーバ導入・運用のコストが大き くなりすぎるという問題がある。P2P モデルによる協調作業支援環境では、サー ビスの大部分をサーバ等の固定的ノードを用いずに実現できるが、ブートストラッ プ問題やオフライン同期問題の解決のためには何らかの固定的ノードが必要であ る。既存の P2P グループウェア等では、この部分をソフトウェアベンダーが運営 するサーバを用いて解決、あるいはユーザグループのネットワーク内に、常時ネッ トワークに接続した固定的ノードを導入するというアプローチによって解決して いる。しかし、このようなアプローチではソフトウェアベンダーの運営するサー バに依存し続けなければならず、あるいはユーザ自身でのサーバ導入・運営のた めのコストを負担する必要があるため好ましくない。 本研究では前述の問題を一般的なサービス資源を利用した擬似ノードを導入す ることで解決する方法を提案した。そして、一般的なサービス資源としてメール システムを利用したフレームワークを設計・実装した。 このフレームワークの応用として協調作業支援アプリケーション “collaboware” を実装した。そして、動作試験によって本フレームワークがブートストラップ問 題とオフライン同期問題を解決できることを確認した。本研究に関連する研究に ついて紹介し、今後の課題を示した。 キーワード: 協調作業支援, Peer to Peer, オフライン同期問題, ブートストラップ問題 慶應義塾大学総合政策学部 小松純 ABSTRACT “Proposal and Implementation of CSCW Framework for Ad-hoc Groups” The purpose of this research is to propose and to implement CSCW framework for ad-hoc groups. In this research, to realize the purpose, solve the bootstrup problem and the offline sycnronization problem on peer to peer(P2P) model service, by pseudo node using general service resources. In recent years, the cases that groups temporary built for specific objectives what is called as “Project Team” or “Task Force”, are appeared offen. In this thesis, such groups are called “ad-hoc group”. The most of existing environments are intended for continuous and large-scale organizations like enterprises, so these environments’ initial server construction and operation costs are too high to use in ad-hoc group. In case of P2P model CSCW environments, the most part of services are able to realize, with no fixed role node like a server, but it is necessary to some fixed role node for solving the bootstrup problem and the offline sychronization problem. The existing groupwares solve these problems by the approaches either using servers operated by software vendors or importing fixed role node connecting to network all the time. But these approaches are not good, because they necessary to keep depend on servers operated by software vendors, or they necessary to import own servers and keep operation. In this research, we proposed a solution of those problems by using pseudo node using general service resources. And we designed and implemented a framework using mail systems as general service resources. We implemented co-operative work supporting software “collaboware” as application of this framework. And, we confirmed that the framework can solve the bootstrup problem and the offline synchronization problem, by run test. Finally we introduced relational researches, and showed future works. Keywords: CSCW, peer to peer, offline synchronization problem, bootstrup problem Keio University, Fuculty of Policy Management Jun Komatsu 目次 第1章 1.1 1.2 1.3 1.4 1.5 第2章 2.1 2.2 2.3 はじめに 本研究の目的 . . . . . . . . . . . グループ協調作業支援の広がり . アドホックグループ . . . . . . . 1.3.1 アドホックグループの性質 用語の定義 . . . . . . . . . . . . 本論文の構成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 既存の協調作業支援環境 メーリングリスト . . . . . . . . . . . . . . . . ファイル共有システム . . . . . . . . . . . . . グループウェア . . . . . . . . . . . . . . . . . 2.3.1 クライアント/サーバ型グループウェア 2.3.2 ASP 型グループウェア . . . . . . . . . 2.3.3 P2P 型グループウェア . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 第 3 章 問題の定義 3.1 協調作業支援環境の要件 . . . . . . . . . . . . . . . . . 3.1.1 低い初期コスト . . . . . . . . . . . . . . . . . . 3.1.2 利用環境の自由 . . . . . . . . . . . . . . . . . . 3.1.3 高度な専門知識を必要としないこと . . . . . . . 3.1.4 可用性の維持 . . . . . . . . . . . . . . . . . . . 3.1.5 機密性の維持 . . . . . . . . . . . . . . . . . . . 3.2 既存協調作業支援環境の問題 . . . . . . . . . . . . . . 3.2.1 クライアント/サーバ型協調作業支援環境の問題 3.2.2 ASP 型協調作業支援環境の問題 . . . . . . . . . 3.3 P2P モデルによる協調作業支援環境の構築 . . . . . . . 3.3.1 既存 P2P 型協調作業支援環境の問題点 . . . . . 3.4 解決すべき問題 . . . . . . . . . . . . . . . . . . . . . . 3.4.1 オフライン同期問題 . . . . . . . . . . . . . . . 3.4.2 ブートストラップ問題 . . . . . . . . . . . . . . i . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1 1 1 2 2 2 . . . . . . 4 4 4 5 5 6 7 . . . . . . . . . . . . . . 11 11 11 11 12 12 12 12 12 13 13 13 14 14 15 第 4 章 問題解決のアプローチ 4.1 一般的なサービス資源を利用した擬似ノード . . . . . . . . 4.1.1 擬似ノードを実現する一般的なサービス資源の要件 4.2 システム全体のモデル . . . . . . . . . . . . . . . . . . . . 4.2.1 擬似ノードによる蓄積中継リンクの動作原理 . . . . 4.3 本アプローチによる問題の解決 . . . . . . . . . . . . . . . 4.3.1 オフライン同期問題の解決 . . . . . . . . . . . . . . 4.3.2 ブートストラップ問題の解決 . . . . . . . . . . . . 4.4 本アプローチの優位性 . . . . . . . . . . . . . . . . . . . . 第 5 章 フレームワークの設計と実装 5.1 擬似ノードを実現する一般的なサービス資源の選定 5.1.1 一般的なサービス資源の比較 . . . . . . . . 5.2 フレームワークの仕様 . . . . . . . . . . . . . . . . 5.3 フレームワークの構成 . . . . . . . . . . . . . . . . 5.3.1 ローカルキャッシュの管理 . . . . . . . . . . 5.3.2 グループメンバーリスト . . . . . . . . . . . 5.3.3 リンクマネージャ . . . . . . . . . . . . . . . 5.3.4 メール送受信マネージャ . . . . . . . . . . . 5.4 メッセージ . . . . . . . . . . . . . . . . . . . . . . 5.4.1 メッセージのフォーマット . . . . . . . . . . 5.4.2 メールによるメッセージの送信 . . . . . . . 5.5 ノードの基本動作 . . . . . . . . . . . . . . . . . . . 5.6 フレームワークの実装 . . . . . . . . . . . . . . . . 第6章 6.1 6.2 6.3 フレームワークの応用 応用の目的 . . . . . . . 実装環境 . . . . . . . . . 機能 . . . . . . . . . . . 6.3.1 プレゼンス共有 . 6.3.2 テキストチャット 6.3.3 ファイル共有 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 第 7 章 評価 7.1 試験環境 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2 試験方法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2.1 ブートストラップ問題解決の確認のための動作試験 7.2.2 オフライン同期問題解決の確認ための動作試験 . . 7.3 試験結果 . . . . . . . . . . . . . . . . . . . . . . . . . . . . ii . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 16 16 17 19 19 19 19 20 . . . . . . . . . . . . . 21 21 23 24 24 24 25 25 26 26 27 27 27 29 . . . . . . 31 31 31 32 32 32 32 . . . . . 33 33 34 34 36 37 第 8 章 関連研究 43 8.1 Mikan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 8.2 qwikWeb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 第 9 章 おわりに 9.1 本研究のまとめ . . . . . . . . 9.2 今後の課題 . . . . . . . . . . 9.2.1 デプロイメント . . . . 9.2.2 リソース保持の効率化 9.2.3 耐故障性の向上 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 44 44 44 44 45 付 録 A collaboware Ver. 0.6.0 49 A.1 リリースノート . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 A.2 マニュアル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 iii 図目次 2.1 サイボウズ Office 6 画面 . . . . . . . . . . . . . 2.2 Intranets PRO 画面 . . . . . . . . . . . . . . . . 2.3 Groove Virtual Office 画面 . . . . . . . . . . . . 2.4 アリエル・エアワン 画面 . . . . . . . . . . . . . 2.5 アリエル・エアワンのワークグループ・ノード . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 . 6 . 8 . 9 . 10 4.1 システム全体のモデル . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.1 メッセージフォーマット . . . . . . . . . . . . . . . . . . . . . . . . 27 5.2 フレームワークのクラス図 . . . . . . . . . . . . . . . . . . . . . . . 30 6.1 collaboware 画面 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 7.1 7.2 7.3 7.4 同一 LAN セグメントに接続した試験環境 . . . . . . . . . . . インターネットを介して接続した試験環境 . . . . . . . . . . ブートストラップ問題解決の確認のための動作試験シナリオ オフライン同期問題解決の確認のための動作試験シナリオ . . . . . . . . . . . . . . . . . 33 34 35 36 A.1 A.2 A.3 A.4 A.5 A.6 A.7 プロファイルの選択 . . . 基本設定 . . . . . . . . . . メールアカウント設定 . . 詳細設定 . . . . . . . . . . 接続ダイアログ . . . . . . 新しいグループの作成 . . 既存のグループへ参加する . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 52 53 53 54 55 55 . . . . . . . . . . . . . . . . . . . . . iv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 表目次 1.1 本論文における用語の定義 . . . . . . . . . . . . . . . . . . . . . . . 3 2.1 グループウェアの分類 . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 クライアント/サーバ型・ASP 型 グループウェアコスト比較 . . . . 5 7 3.1 既存の協調作業支援環境とアドホックグループにおける要件 . . . . 14 4.1 モデルにおける主な抽象とその役割 . . . . . . . . . . . . . . . . . . 18 4.2 既存の方式と本研究のアプローチの比較 . . . . . . . . . . . . . . . 20 5.1 一般的なサービス資源の比較 . . . . . . . . . . . . . . . . . . . . . 23 5.2 グループメンバーリストに含まれる情報 . . . . . . . . . . . . . . . 25 5.3 メッセージの種類 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 7.1 環境 A におけるブートストラップ問題の解決の確認のための動作試 験結果 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2 環境 B におけるブートストラップ問題の解決の確認のための動作試 験結果 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3 ブートストラップ問題の解決の確認 . . . . . . . . . . . . . . . . . . 7.4 環境 A におけるオフライン同期問題の解決の確認のための動作試験 結果 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.5 環境 B におけるオフライン同期問題の解決の確認のための動作試験 結果 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.6 オフライン同期問題の解決の確認 . . . . . . . . . . . . . . . . . . . v 37 38 38 40 41 42 第1章 はじめに 本章では、まず本研究の目的を述べる。そして本研究の背景としてコンピュータ とネットワークによる協調作業支援の発展及び、アドホックグループについて説 明する。また、本論文の残りの部分の構成について示す。 1.1 本研究の目的 本研究は、アドホックグループを対象とした協調作業支援環境の構築方法を提 案・実現することを目的とする。 アドホックグループとは何らかの目的達成のために一時的に構成するグループ のことである。 1.2 グループ協調作業支援の広がり コンピュータやネットワークによるグループの協調作業支援は、CSCW(Computer Supported Co-operative Work) の研究として 1980 年代より盛んに研究されるよう になった。また大企業等では 1990 年代以降、ホワイトカラーの生産性向上を目的 としたグループウェアの導入が進んだ。 1990 年代後半に入ると、個人がコンピュータやインターネットを利用すること も珍しいことではなくなった。総務省の平成 16 年版 情報通信白書によると、平成 15 年末におけるインターネットの世帯普及率は 88.1 ％であり、9 割近くの世帯が インターネットを利用している [1] 。 このような状況の中でコンピュータやネットワークによるグループの協調作業 支援は、企業だけでなく、家庭や教育、行政、あるいは地域コミュニティなどの非 商業的な場面でも利用されるようになってきている [2] 。 1.3 アドホックグループ アドホックグループとは何らかの目的達成のために一時的に構成されるグルー プである。 1 企業等では、従来の職能別組織では対応できない複雑な問題に対応するために、 各職能毎の専門家を集めてプロジェクトチームをつくり問題解決にあたるという ことが頻繁に行われるようになった。この傾向は 1 つの企業の中に留まらず、企業 の壁、または空間や場所の壁を超えて問題解決に取り組んでいくバーチャル・チー ムの事例は最近多く見られるようになってきた [3] 。 身近な例を挙げると、大学の授業等では学生が数人のグループを形成して課題 に取り組む、グループワークが盛んに行われている。このようなグループも、授業 の課題の達成という目的のもとに一時的に形成されたアドホックグループである。 1.3.1 アドホックグループの性質 アドホックグループの性質について述べる。アドホックグループは一般に以下 のような性質を持っている。 一時性 グループの存在期間が一時的であること。 目的志向性 グループが目的志向であること。 組織横断性 グループを構成するメンバーが所属する組織が、複数の組織にまた がっていること。 小規模性 グループを構成するメンバーの数が小さいこと。 流動性 グループを構成するメンバーの変化が流動的であること。 地理分散性 グループを構成するメンバーが地理的に分散していること。 時間分散性 グループを構成するメンバーの活動時間が時間的に分散していること。 1.4 用語の定義 本論文における用語で、特に注意を要するものを表 1.1 に示す。 1.5 本論文の構成 第 2 章では、既存のグループ協調作業支援環境としてメーリングリスト、ファイ ル共有システム、およびグループウェアを取り上げ、アドホックグループでの利 用の観点からその特徴と問題点を整理する。 第 3 章では、アドホックグループを対象とした協調作業支援環境の要件を明ら かにし、既存協調作業支援環境の問題点について明らかにした上で、本研究で解 2 表 1.1: 本論文における用語の定義 順番 用語 意味 1 オ ー バ レ イ ネット ワ ー ク (overlay network) 2 ロケーション (location) 3 オンライン (online) 4 オフライン (offline) 既存のリンクを用いて、その上位層における 目的に応じて仮想的なリンクを形成し、構成 するネットワーク オーバレイネットワークにおける下位層での 識別 ノードがオーバレイネットワークに接続して いること、つまり他の、オーバレイネットワー クに接続しているノードに接続しているか、 他のオーバレイネットワークに接続している ノードから接続可能な状態にあること。 ノードがオーバレイネットワークから切断し ているこ、オンラインの逆 決すべき問題として「オフライン同期問題」及び「ブートストラップ問題」を定 義する。 第 4 章では、第 3 章で示した問題に対して、「一般的なサービス資源を利用した 擬似ノードの導入」による解決を提案する。そしてこの方法による問題解決につ いて全体的なモデルを示す。また本アプローチの既存の方法に対する優位性を考 察する。 第 5 章では、4 章で示した問題解決手法のモデルを実際に実現するための P2P フレームワークについて概要を示し、設計と実装について述べる。 第 6 章では、5 章で設計したフレームワークの応用である、協調作業支援環境を 実現するアプリケーション “collaboware” について述べる。 第 7 章では、第 3 章で示した問題の解決を確認するためのフレームワークの動 作試験について述べる。そして動作試験の結果に基づいて本研究の評価を述べる。 第 8 章では、本研究の関連研究として、Mikan および qwikWeb について紹介し、 本研究との比較を行う。 第 9 章では、本研究のまとめを行い、関連研究と今後の課題を示す。 3 第2章 既存の協調作業支援環境 本章では既存のグループ協調作業支援環境として、メーリングリスト、ファイル共 有システム、およびグループウェアを取り上げ、前章で示したアドホックグルー プでの利用の観点からその特徴を整理する。 2.1 メーリングリスト メーリングリストとは、特定の興味分野やテーマについての議論などを目的と して、その参加者のメールアドレスのリストを作成し特定のメールアドレス宛てに 送られたメールをそのリスト中のメールアドレスに転送することによってグルー プでのコミュニケーションを実現する仕組みである。 メーリングリストを用いると日常的に利用している電子メールを利用して、グ ループでのコミュニケーションの場を手軽に実現することができる。電子メール にファイルを添付することによって、テキストだけでなく様々なデータを共有す ることもできる。 従来はメーリングリストを利用するためには、ISP 等が提供するサービスを利 用するか、あるいは、fml[5] , Majordomo[6] 等のメーリングリストマネージャのソ フトウェアを自身で運用しているメールサーバに導入して利用するといった方法 がとられていたが、最近では Yahoo!グループ [7] や QuickML[8] のようなユーザ自身 がメーリングリストの作成・管理を手軽に行える無料のサービスが普及してきて いる。 2.2 ファイル共有システム ファイル共有システムとは、複数のユーザの間でファイルを共有するためのシ ステムである。グループの協調作業においてファイルの共有は、協調作業の素材 や過程、そして成果物を共有する上で重要である。 特に集団でのソフトウェア開発の分野では、CVS(Concurrent Version System)[9] や subversion[10] のようなバージョン管理機能を持ったシステムが良く利用される。 バージョン管理機能とは、ファイルが更新されるたびにバージョン番号を振り、ま た更新の差分を保存しておくことで、後からファイルの更新過程を追跡すること 4 ができる機能である。バージョン管理機能により、複数人のユーザによって同じ ファイルを更新していく場合等に大変便利である。 グループウェア 2.3 グループウェアとは、グループでの作業をコンピュータやネットワークを活用 して支援するソフトウェアの総称、あるいは、それらの組み合わせによる統合的 なソフトウェアである。本論文ではグループウェアという言葉を後者の意味で捉 える。 現在、対象とするグループが取り組む作業の内容、グループの規模、利用形態 などに応じて様々なグループウェアが存在する。一般的にグループウェアは、ファ イル共有の機能やグループのスケジュール管理機能、掲示板等のコミュニケーショ ン機能を含んでいる。本節では、グループウェアをその実現方法および提供形態 で表 2.1 のように分類し、それぞれの特徴について説明する。 表 2.1: グループウェアの分類 提供形態 パッケージソフトウェア ASP サービス 実現 方法 2.3.1 C/S モデル P2P モデル C/S 型グループウェア P2P 型グループウェア ASP 型グループウェア クライアント/サーバ型グループウェア クライアント/サーバ型グループウェアとは、サービスを提供するサーバと、サー バの提供するサービスを受けるクライアントとに、役割が明確に分かれるネット ワークモデルによって実現されるグループウェアである。 Lotus Notes/Domino[11] は代表的なグループウェア製品であり、大企業等が全社 的に利用するような利用シーンにも対応可能な製品である。 サイボウズ Office 6[12] は、中小企業や、大企業の中の 1 セクション等の中・小 規模のグループを対象としたグループウェアである。サーバプログラムを LAN 内 に設置されたサーバにインストールし、ユーザは Web ブラウザを用いてサーバに アクセスすることで利用できる。 クライアント/サーバ型グループウェアを利用するためには、サーバの導入と運 用が必要である。サーバの導入にはサーバマシンの購入、サーバ構築、担当技術 者の確保など、一般的に大きなコストが掛かる。 5 図 2.1: サイボウズ Office 6 画面 2.3.2 ASP 型グループウェア 図 2.2: Intranets PRO 画面 6 ASP(Application Service Provider) とは、ネットワークを介して、多くの利用者 に対しアプリケーションソフトウェアと、その運用に必要なサーバ等の環境を合 わせて提供し、利用者数や、利用期間に応じた利用料を支払うというサービスモ デルによってサービスを提供する事業者、およびそのサービス提供形態である [13] 。 ASP 型グループウェアのひとつである、イントラネッツ [14] は、伝言板、スケ ジュール管理、共有アドレス帳、文書共有等のグループウェアの基本的な機能を提 供する。イントラネッツでは「Intranets Enterprise」、 「Intranets PRO」、 「Intranets Basic」の 3 種類のグレードのサービスを用意しており、PRO は月額 5 千円程度の 利用料金で利用でき、機能限定版の Intranets Basic については無料で利用するこ とができる。 また、2.1 節で取り上げた Yahoo!グループも、メーリングリストが機能の中心で はあるがファイル共有等の機能も含まれる ASP 型グループウェアの一種である。 ASP 型グループウェアでは 2.3.1 節で述べたようなサーバの導入と運用は必要な く、初期コストの面で大幅に有利である。2.3.1 節で取り上げたクライアント/サー バ型グループウェアと、ASP 型グループウェアの初期・運用コスト比較を表 2.2 に 示す。 表 2.2: クライアント/サーバ型・ASP 型 グループウェアコスト比較 Lotus Notes/Domino サイボウズ Intranets PRO 初期コスト サービス利用コスト (月額) 2.3.3 (C/S 型) (C/S 型) (ASP 型) 20 万円∼ 0円 8 万円∼ 0円 5,040 円 5,040 円∼ P2P 型グループウェア P2P モデルとは、役割の対等なノード (peer) 同士の通信によってサービスを実 現するネットワークモデルである。ノードが、サーバとクライアントの 2 つの役 割に分離しているクライアント/サーバモデルと比較すると、P2P モデルでは、そ れぞれのノードがサーバの役割とクライアントの役割の両方を兼ね備えていると 考えることもできる。P2P モデルはクライアント/サーバモデルと比較して、一般 に計算機資源やネットワーク負荷の分散性が高まり、規模性や頑健性の面で優位 なネットワークサービスを構築することが可能である。クライアント/サーバモデ ルではサービス全体の管理や制御は容易であるが、純粋な P2P モデルではサービ ス全体を集中的に管理・制御可能な存在が無いため、サービス全体の管理や制御 が難しい。 P2P 型グループウェアとはこの P2P モデルを利用して実現されているグループ ウェアである。 7 本節では、既存の P2P 型グループウェアとして、Groove Virtual Office 及びア リエル・エアワンについて取り上げて説明する。 Groove Virtual Office 図 2.3: Groove Virtual Office 画面 Groove Virtual Office は米 Groove Networks 社の製品であり、Lotus Notes の生 みの親といわれる Ray Ozzie によって開発された P2P 型グループウェアである [15] 。 Groove Virtual Office では、Workspace と呼ばれる共有空間を作成し、その空 間を通じて他のメンバとメッセージのやり取りや情報の共有を行う。 Groove のネットワークには、Relay Service 及び、Management Service を提供 するサーバが存在する。 Relay Service はノードがネットワークに接続するための最初の接続先ノードと なり、NAT(Network Address Translator) やファイヤウォール等の存在によりノー ド間で直接通信できない場合に中継接続を行ったり、また、通信相手のノードが ネットワークに接続していない場合には、更新差分通知を蓄積し、対象のノード が接続してきたときに蓄積された通信内容を伝える蓄積通信を実現している。 一方 Management Service は、各ユーザの状況を把握し、ドメイン・グループ単 位で運用ポリシやアクセス権限を規定し、それを適用することで、ネットワーク を、管理可能にする役割を担っている。 Relay Service や Management Service は、通常は Groove Networks 社が運用する サーバを利用する。一方で、Groove Networks 社は企業向けに Groove Enterprise 8 Relay Server および Groove Enterprise Management Server というサーバソフト ウェアのパッケージ製品を用意しており、これらのサーバソフトウェアを購入し て自前の Relay Service および Management Service を構築することで、Groove Networks 社のサーバを使わずに、自前でこれらのサーバを運用することで、きめ細 やかな管理や、要求されるサービスレベルを満たしたサービス運用が可能となる。 アリエル・エアワン 図 2.4: アリエル・エアワン 画面 アリエル・エアワンはアリエルネットワーク社が開発した P2P 型グループウェ アである [16] 。 アリエル・エアワンでは、ユーザ認証に PKI を利用しており、ユーザはアリエ ル・エアワンを PC に導入するときに、アリエル社の運営する認証サーバに接続し て、証明書を作成し、PC 内に保存する。 アリエル・エアワンでは、ルームという単位で情報の共有を行う。 アリエル・エアワンにも、アリエルネットワーク社が運用する中継サーバは存 在するが、その役割は限定されている。 アリエル・エアワンではワークグループ・ノードと呼ばれる仮想ノードをユー ザが設置してルームに含めることで、ワークグループ・ノードによってデータの 9 収集や中継接続を行うようになり、ルーム内での情報共有や相互接続が安定する ようになる (図 2.5)。 ӓᨼẰủẺἙὊἑ ἠὊἛỊẆࠝឪ ѣẲềẟỦὁὊἁ ἂἽὊἩὉἠὊἛ ỆஇИỆዓẴ ỦẮểầỂẨỦ ὁὊἁ ἂἽὊἩ ἠὊἛ ἠὊἛầὁὊἁἂ ἽὊἩὉἠὊἛỆ ዓẲẺểẨỆ ὁὊἁἂἽὊἩὉ ἠὊἛầӓᨼẲẺ ἙὊἑửἠὊἛỆ ᡫჷẴỦ ἠὊἛ ἠὊἛ ἙὊἑ ἠὊἛ ἠὊἛ ἙὊἑ 図 2.5: アリエル・エアワンのワークグループ・ノード 10 第3章 問題の定義 本章では、まずアドホックグループを対象とした協調作業支援環境の要件を明 らかにする。そして、既存協調作業支援環境の問題点について述べ、、それを踏ま えて、本研究で解決すべき問題である「オフライン同期問題」及び「ブートスト ラップ問題」を定義し説明する。 3.1 協調作業支援環境の要件 1.3 節で説明したアドホックグループを対象とした協調作業支援環境の要件は、 • 低い初期コスト • 利用環境の自由 • 高度な専門知識を必要としないこと • 可用性の維持 • 機密性の維持 である。 以下にそれぞれの要件についての説明を示す。 3.1.1 低い初期コスト アドホックグループはその一時性から、協調作業支援環境を利用する際に大き な初期コストを負担することが難しい。継続的組織を考えた場合には、初期コス トが高くても長期の運用の中で償還していくことが可能だが、アドホックグルー プでは運用期間が一時的であるために初期コストを低く抑えることが重要となる。 3.1.2 利用環境の自由 アドホックグループではメンバーの所属や所在等が多様であるため、利用環境 についても多様であると考えられる。そのためアドホックグループを対象とした 協調作業支援環境では、メンバーの利用環境の多様性に対応できるよう、ユーザ の利用環境に対して制限が少ないことが求められる。 11 3.1.3 高度な専門知識を必要としないこと アドホックグループに、サーバ管理のような高度な技能を持っているメンバー がいるとは限らないため、アドホックグループを対象とした協調作業支援環境に おいては、サーバ管理のような高度な技能を必要とせずに、環境を利用できる必 要がある。 3.1.4 可用性の維持 グループのコミュニケーション基盤として様々な情報の流通を担う協調作業支 援環境は、常に利用可能であることが求められる。アドホックグループでは特に、 グループのメンバーが同じ空間を共有できないことも多く協調作業支援環境に対 する依存度が高まると考えられるため、可用性が維持されることは重要である。 3.1.5 機密性の維持 協調作業支援環境の上でやりとりされる情報には様々なものが含まれる。3.1.4 節でも述べたように、アドホックグループでは協調作業支援環境への依存度が高 まるため、機密性の高い情報についても協調作業支援環境上でやりとりできるこ とが求められる。 3.2 既存協調作業支援環境の問題 本節では 3.1 節で明らかにした要件を踏まえ、アドホックグループが第 3.1 章で 取り上げた既存の協調作業支援環境を利用する上での問題点について述べる。 3.2.1 クライアント/サーバ型協調作業支援環境の問題 いわゆるクライアント/サーバ型の協調作業支援環境では、サーバ導入にかかる コストや、その運用コストがアドホックグループにとって大きな負担となる。 また、サーバの導入や運用には、多くの場合高度な専門知識が必要となる。し かし、アドホックグループを対象とした場合、3.1.3 節で述べた理由から、ユーザ が自らこのようなサーバを設置し運用することは難しい。 2.3.1 節で取り上げた Lotus Notes/Domino やサイボウズでは、LAN 内にサーバ を設置しての利用が想定されている。LAN 内にサーバを設置して利用するような 場合においては、LAN 外からのアクセスがファイアウォールなどによって妨害さ れ不可能となり、3.1.2 節で述べた利用環境の自由が満たされない可能性がある。 12 3.2.2 ASP 型協調作業支援環境の問題 2.3.2 節で示したような ASP 型の協調作業支援環境を利用することでサーバ導入 にかかる初期コストを低く抑えることができる。 また、一般的に ASP 型サービスはインターネットへの接続環境さえあれば、ど こからでもアクセスすることができるという利点がある。 システムの導入や運用については ASP 事業者が行うため、ユーザにシステムを 運用するための高度な専門知識は求められることはない。 しかし、ASP 型協調作業環境では可用性の維持の面で問題がある可能性がある。 多くの ASP 型協調作業環境では、ASP サービス提供者が多くの利用者に対して汎 用的なシステムを利用させるモデルをとっており、サーバ資源は共有されている。 そのため他の利用者の利用が一時的に集中するなどでサーバやネットワークの資 源が枯渇し、通常のサービスを受けられない状態になる可能性が考えられる。 また、機密性の維持の面でも、まず ASP サービス提供者がアドホックグループが 協調作業支援環境上でやり取りする様々な情報、利用履歴や利用者の個人情報、そ の他の情報に触れることになり、この点で幾分機密性が失われている。また、サー バ資源は他の利用者と共用であるため、場合によっては他の利用者にそれらの情 報が漏れる危険性も少なからず存在する。 3.3 P2P モデルによる協調作業支援環境の構築 P2P モデルで実現されている協調作業支援環境として、2.3.3 節で Groove Virtual Office とアリエル・エアワンを取り上げた。これらのソフトウェアは、ユーザがソ フトウェアをソフトウェアベンダのウェブサイトからダウンロードし、自分の PC にインストールしてグループの設定をすることで利用可能になる。基本的にはユー ザ自身によるサーバの導入・運用は不要である。このように P2P モデルによる協 調作業支援環境は、3.1.1 節や 3.1.3 節で述べた要件を満たし、アドホックグループ での利用に適していると考えられる。 3.3.1 既存 P2P 型協調作業支援環境の問題点 しかし、2.3.3 節で示したように Groove Virtual Office のネットワークにはソフ トウェアベンダが運用している中継サービスが組み込まれているし、アリエル・エ アワンではネットワークを安定させるために「ワークスペース・ノード」を設置 することを推奨しており、実際にワークスペース・ノードを設置しなかった場合 同時にオンラインになっているメンバー間で接続できなかったり、接続が確立す るまで時間が掛かったり、また発信した情報が届かなかったりということが発生 することがある。 13 3.4 解決すべき問題 表 3.1: 既存の協調作業支援環境とアドホックグループにおける要件 C/S 型 ASP 型 P2P 型 要件 (Lotus Notes/Domino) (Intranets PRO) (アリエル・エアワン) 大きい △ 大きい ○ ○ 小さい ○ 小さい △ △ 小さい ○ 小さい ○ ○ 初期コスト 利用環境の自由 高度な専門知識の要求 可用性の維持 機密性の維持 3.1 節で述べたアドホックグループにおける協調作業支援環境の要件を満たすた めには、協調作業支援環境の構築において、ユーザ自身でサーバ的な固定ノード を自身で導入・運用しなくてもよいようにする必要がある。 クライアント・サーバ型の協調作業支援環境では、3.2.1 節で述べたように、サー バの導入・運用に掛かるコストの面で 3.1.1 節や 3.1.3 節で述べた要件を満たさず、 ASP 型協調作業支援環境では、3.2.2 節で述べたように、可用性の維持および機密 性の維持の点で問題がある。 既存の P2P 型協調作業支援環境においては、3.3 節で述べたように、基本的には ユーザはサーバを必要とせず、要件を満たしているように思える。しかし、実際 にはサービスの一部においてソフトウェアベンダの運営するサーバや、 「ワークグ ループ・ノード」のような固定的なノードをネットワーク内に含める必要がある。 このような固定的ノードをネットワークに設置する必要が生じているのは、以 下に詳しく説明するブートストラップ問題及び、オフライン同期問題を解決する ためであると考えられる。 3.4.1 オフライン同期問題 オフライン同期問題とは、 • 参加しているノードが一時的にオーバレイネットワークから切断することが ある という前提を持ち、 • オーバレイネットワークに接続している全てのノードは、共有されているリ ソース集合の一貫性・完全性が保たれる 14 • 何れかのノードが共有されているリソース集合に対して行った変更は、オー バレイネットワーク上の（接続していないノードも含む）全てのノードに共 有される ということが保障されるオーバレイネットワークにおいて、オーバレイネットワー クから切断しているノードに情報の伝達ができないことに起因して、このことが 保障されなくなるという問題である。 3.4.2 ブートストラップ問題 ブートストラップ問題とは、オーバレイネットワークに接続していないコンピュー タがオーバレイネットワークに接続するために、最初に接続するエントリーポイ ントとなるノードのロケーションを、どのように獲得するかという問題である。 多くのコンピュータは、DHCP 等の機構により動的に IP アドレスの割り当てが 行われていることにより、オーバレイネットワークに参加しているノードのロケー ション (IP アドレス) も、接続ごとに変化する可能性がある。このような環境下で は、ブートストラップ時にオーバレイネットワークに接続している他のノードの ロケーションを確定的に把握することができない。 15 第4章 問題解決のアプローチ 本章では、前章の 3.4.1 節で示したブートストラップ問題、および 3.4.2 節で示 したオフライン同期問題に対して、 「一般的なサービス資源を利用した擬似ノード の導入」による解決を提案する。そしてこの方法によるシステムの全体的なモデ ルを示し、どのように 2 つの問題が解決されるかを説明する。また本アプローチ の既存の方法に対する優位性を考察する。 4.1 一般的なサービス資源を利用した擬似ノード 前章において、アドホックグループでは利用する協調作業支援環境の実現のた めに専用のサーバを導入・運用することが難しく、また、特定のサービスプロバ イダが提供するサービスに依存することが好ましくないことを示した。 また、P2P モデルを利用することで、サービスの大部分をサーバを用いずに実 現できるが、ブートストラップ問題、オフライン同期問題といった問題に対処す るために、何らかの固定的ノードの存在が依然必要とされることも示した。 本研究では、前章で定義した P2P モデルにおけるオフライン同期問題、および ブートストラップ問題をユーザが既に利用可能な一般的なサービス資源を利用し た擬似ノードによって解決する方法を提案する。これによって専用のサーバや、そ れに準じる固定的ノードの設置、もしくは特定のサービスプロバイダが運営する サービスに依存することなく協調作業支援環境を実現でき、結果 3.1 節で述べた要 件を満たすことができる。 4.1.1 擬似ノードを実現する一般的なサービス資源の要件 一般的なサービス資源とは、標準化され広く普及しており様々な提供者によっ て一般的に提供され、一般的なユーザが利用可能なサービス資源である。 擬似ノードとは、ノードと結び付けられ、ノードがオフラインのときに、代わ りに他のノードからのメッセージを受信し、蓄積し、ノードがオンラインになっ たときにその蓄積されたメッセージをノードに通知するノードである。 擬似ノードを実現するための一般的なサービス資源は、以下の要件を満たす必 要がある。 16 • 常時利用可能であること • 情報の蓄積が可能なこと • ユーザの識別・認証が可能であること 4.2 システム全体のモデル 前節で述べた一般的なサービス資源を利用した擬似ノードを含んだシステム全 体のモデルを図 4.1 に示す。また、このモデルに含まれる主な抽象とその役割を表 4.1 に示す。 લ˩ἠὊἛ ἳὅἢὊ ᔛᆢɶዒἼὅἁ ᔛᆢɶዒἼὅἁ ἠὊἛ ᵆỼἧἻỶὅᵇ ἳἕἍὊἊ ἳὅἢὊ ἕἚὁὊἁᴾỴὊỽỶἨ ἳὅἢὊ ἼἏὊἋ ἠὊἛ ἠὊἛ ἳἕἍὊἊ Ἴὅἁ લ˩ἠὊἛ ỼὊἢἾỶἕἚὁὊἁ ἂἽὊἩ 図 4.1: システム全体のモデル 17 લ˩ἠὊἛ 表 4.1: モデルにおける主な抽象とその役割 番号 抽象 役割 1 グループ 2 メンバー 3 ノード 4 擬似ノード 5 リンク 6 蓄積中継リンク 7 8 9 メッセージ リソース ネットワークアーカイブ 同一の目的を持ち協調作業を行うユーザの論 理的集合であり、そのための情報を共有する 範囲を規定する。 グループに属するユーザーであり、リソース にアクセスする主体である。 オーバレイネットワークに参加する自律的な 存在の単位、オンライン状態とオフライン状 態の二つの状態をとる。 蓄積中継リンクを実現するために、対応する ノードに対するメッセージを蓄積し、ノード がオーバレイネットワークに接続した時点で 蓄積されたメッセージをノードに伝達する擬 似的なノード。 ノード間でメッセージをやりとりするための 伝送路。 擬似ノードによって実現される、メッセージ を送信したい相手がオフラインであったとき に擬似ノードを経由して蓄積中継通信を行う ための擬似的なリンク。 ノード間でやり取りされる様々な情報。 グループによって共有される情報。 オーバレイネットワークに参加するノードに よって実現される共有リソースの集合。 本モデルでは、グループのメンバーがオーバレイネットワークを構成するノード に対応しており、ノード間の通信を通じてグループ内でのリソースの共有を、ネッ トワークアーカイブとして実現している。 それぞれのノードは、オーバレイネットワーク上の、他の全てのオンライン状 態のノードとの間に通常のリンクを形成し、リンクを通じて直接メッセージの伝 送が可能な状態を維持する。 18 4.2.1 擬似ノードによる蓄積中継リンクの動作原理 ノードがオフライン状態となった場合には、そのノードと他のノードとの間の 直接的なリンクについても切断されるため、ノードはリンクを通じて直接メッセー ジの伝送を行えなくなる。そこで、本モデルではノードが他のオフライン状態の ノードに対してメッセージを伝達するための手段として、擬似ノードによる蓄積 中継リンクを導入する。本モデルでは、それぞれのノードに対応する擬似ノード が存在する。擬似ノードとは、オーバレイネットワーク外部の常に利用可能な資 源を用いて構成されるノードである。擬似ノードは、そのノードがオフライン状 態である間に、他のノードからそのノードに送られるべきメッセージを、代わり に受信し、蓄積する。ノードがオーバレイネットワークに接続する場合には、そ の直前に、そのノードがオフライン状態である間に擬似ノードが代理で受信、蓄 積したメッセージを一括して取得し、適切な処理を行う。これによってそれぞれ のノードは、ノードのオーバレイネットワークへの接続状態の変化に対して透過 的にメッセージの伝送を行うことが可能になる。 4.3 4.3.1 本アプローチによる問題の解決 オフライン同期問題の解決 4.2 節で示した本モデルでは、それぞれのノードがノードのオーバレイネット ワークへの接続状態に関わらずメッセージの伝送を行えることを示した。これに よって、オーバレイネットワーク上の何れかのノードが、グループで共有されて いるリソース集合に対して行った変更を、オフライン状態のノードを含む全ての ノードに対しても伝達することができる。また同時に、共有されているリソース 集合の一貫性、完全性が保つことができる。これにより、本モデルによってオフ ライン同期問題は解決される。 4.3.2 ブートストラップ問題の解決 本モデルでは、それぞれのノードがオーバレイネットワークに接続、あるいは 切断するタイミングで、他のノード（オフラインのノードも含む）に対し、その 接続状態変化の内容及び、ロケーションに関する情報をメッセージとして伝達す る。これにより、それぞれのノードは、オーバレイネットワークに接続する直前 に、オフライン状態中に発生した他のノードの接続状態の変化、ロケーションの 変化についての情報を取得することが可能になり、問題なく、オーバレイネット ワークに接続することができるようになる。 19 4.4 本アプローチの優位性 表 4.2: 既存の方式と本研究のアプローチの比較 本アプローチ 既存 P2P 型 C/S 型 ASP 型 無し 小 小 有り 小&中 小&中 無し 大 大 有り 小 小 外部サービスプロバイダへの依存 初期導入コスト 運用コスト 表 4.2 に既存の協調作業支援環境と本研究のアプローチの比較を示す。 本アプローチは、従来の P2P ネットワークにおけるブートストラップ問題やオ フライン同期問題の解決手段である、「中央サーバによる中継接続」や、「常時接 続ノードの設置」に比べ、以下の点において優位性があると考えられる。 • ソフトウェアベンダが提供する中継サーバ等を利用しなくて良い 3.3 節で指摘したように、Groove Virtual Office やアリエル・エアワンにおい ては、基本的にはソフトウェア提供元が運営するサーバを利用することで、 ブートストラップ問題の解決や、オフライン同期問題の解決が図られる。 しかし、このモデルには 3.3 節で説明したように、ソフトウェアベンダが提 供するサービスへの依存が発生する点で問題がある。 本方式では、ソフトウェアベンダが提供するサーバを使うよりも、ユーザが 既に利用可能な一般的なサービス資源を用いることによって特定のソフト ウェアベンダやサービスプロバイダが集中的に運用するサーバの利用に依存 する必要が無くなる。 • ユーザが自身でサーバ的固定ノードを用意しなくて良い 3.3 節で述べたように、Groove Networks では企業などの大規模な組織にお いて Groove Virtual Office を利用することを想定して、Relay Server という サーバ製品を用意している。前項で述べたような問題は、このように、自前 でサーバを設置することで解決されるが、その場合は、やはりサーバ設置の コストの問題がネックとなる。 20 第5章 フレームワークの設計と実装 本章では、前章で示したモデルを実現する協調作業支援環境のフレームワーク の設計と実装について述べる。まず、重要な設計上の決定である擬似ノードを実 現する一般的なサービス資源の選定について述べ、その後、フレームワークの仕 様について延べ、そしてその詳細と実装について述べる。 5.1 擬似ノードを実現する一般的なサービス資源の選定 4.1.1 節で、擬似ノードを実現する一般的なサービス資源の要件について述べた。 本節では、フレームワークを設計・実装するにあたり、擬似ノードを実現する ための一般的なサービス資源について可能性を検討し、本フレームワークで擬似 ノードを実現するために利用する一般的なサービス資源について選定する。 WWW WWW は最も一般的なインターネットサービスのひとつである。WWW は、 HTML というハイパーテキスト記述言語によって記述されたウェブページを、ハ イパーリンクによって辿っていくことで、分散したホストに存在する関連する情 報に次々にアクセスできるシステムである。 WWW のシステムは、ウェブページを公開するウェブサーバと、それを閲覧す るウェブブラウザによって構成され、ウェブサーバとウェブブラウザの間の通信 は、HTTP というシンプルなプロトコルによって実現されている。 現在、多くの商用 ISP がそのユーザに対して、数 MB から数十 MB 程度のウェ ブページ公開用のディスクスペースを提供しておりユーザはその領域を使ってウェ ブページを公開することが可能である。このような ISP のユーザ用ウェブサーバ は基本的には常時利用可能であると考えてよいだろう。また、HTTP の基本認証 のスキームを利用することでウェブサーバにアクセスするユーザの識別・認証も可 能であり、CGI 等のプログラムを利用することで、情報の送信・蓄積も可能にな る。しかし、一般的な WWW のサービスは、公に情報を公開することを想定して おり、多くの ISP において、特定の領域にユーザの識別・認証を行えるような設定 を行うことは、ウェブサーバの設定方法等の知識が必要であり、一般のユーザに は難しい。CGI 等のプログラムをウェブサーバ上で利用することも、同様に、一 21 般のユーザには難しいと考えられる。あるいは、ISP のセキュリティポリシによっ ては、このような使い方を許容していない可能性も考えられる。 Instant Messaging (Jabber) Instant Messaging は、同時にネットワークに接続している知人に対して手軽に コミュニケーションをとることができるツールとして、近年急速に普及してきた サービスである。 現在の Instant Messaging のサービスは AOL, MSN, Yahoo! 等、様々な事業者 によってそれぞれ独自の内容のサービスとして提供され、それぞれのサービス間 での相互運用性は確保されていない。また、これらの事業者によるサービスにつ いては、プロトコルの仕様などもあまり公開されておらず、クライアントプログ ラムについても、一部クローンは存在するが基本的には事業者が提供するクライ アントプログラムの利用を前提としている。 Jabber[17] は、そのような状況を踏まえて開発された Instant Messaging のシステ ムであり、オープンなプロトコル仕様と、オープンソースによるソフトウェア実 装によって、様々なサーバやクライアントが開発されている。 wija[19] は Media Art Online[18] で開発されている、Jabber プロトコルによる Instant Messaging をサポートしたプログラムである。wija の特徴のひとつとして、 プラグインによって wija を拡張することが可能な点が挙げられる。 Jabber のシステムでは、クライアント間のメッセージは Jabber サーバを通じて 送られ、メッセージの送り先のノードが Jabber サーバに接続していなかったとし ても、Jabber サーバ内にそのメッセージが蓄積される。また、Jabber システムで は、 「ユーザ名@ドメイン名/リソース名」の形式を持つ Jabber ID によって通信の 相手が識別されるようになっており、これによってユーザの識別・認証も可能であ る。Jabber サーバ自体は jabberd 等のオープンソースの jabber サーバソフトウェ アを用いることで誰でも立ち上げることができるが、jabber.org や jabber.jp など 既に多くのパブリックな jabber サーバが存在しているのでこれを利用することも できる。 このように、Jabber は擬似ノードを実現する一般的なサービス資源の要件を満 たしている。 メール メールも WWW と同様に最も一般的なインターネットサービスのひとつである。 総務省の平成 16 年度 情報通信白書によると、自宅のパソコンからのインターネッ ト利用用途で最も多いのが連絡手段としての「電子メール」(57.6%) であった [1] 。 このように、電子メールは多くのインターネット利用者にとって身近なサービス であると考えられる。 22 一般的な商用 ISP は、ほぼ例外なくユーザにメールアカウントを提供している。 企業はもとより、最近では大学や高校等の教育機関でも、当たり前のように学生・ 生徒にメールアカウントが与えられるようになった。 また、hotmail や Yahoo!メール、Gmail[20] 等のサービスを利用すると、ウェブ ページから情報を入力して登録することで、メールアカウントを無料で発行する ことができる。このようなサービスでは、ユーザがそのサービスを通じてやりと りするメールの文末部分等に、広告が挿入され、その広告収入によりサービスが 成立している。 このように、メールはインターネットを利用しているユーザの大多数が既に利 用しており、また利用していないとしても、無料のサービスによりメールアカウ ントを取得することができ、ユーザが望めば利用可能なものであると考えられる。 メールサービスは最も基本的なインターネットサービスであり、基本的には常 に利用可能になっていると考えられる。メールサーバ上には、ユーザが未受信の メールを一時的に蓄積するために、各ユーザごとに数 MB から数十 MB の容量制 限を持った領域が確保されているのが一般的である。この領域を利用することで、 情報の蓄積も可能である。また、メールアドレスによるユーザの識別ができ、メー ルアドレスを利用するためには、メールサーバに対してパスワードによる認証を 要する。 5.1.1 要件 一般的なサービス資源の比較 表 5.1: 一般的なサービス資源の比較 WWW Instant Messaging (Jabber) メール 常に利用可能である 情報の蓄積が可能 ユーザの識別・認証が可能 ◎ △ △ ○ ○ ◎ ◎ ○ ◎ 広く普及している 様々な提供者により一般的に提供 一般的なユーザが利用可能 ◎ ◎ × △ △ ○ ◎ ◎ ◎ 表 5.1 に、一般的なサービス資源の比較を示す。この表に示した中で、全ての 要件及び前提条件を他の一般的なサービス資源に対して高度に達成しているため、 メールを擬似ノードを実現する一般的なサービス資源として利用することとする。 23 5.2 フレームワークの仕様 フレームワークが提供する機能は、 • ネットワークアーカイブへの透過的アクセス • ネットワーク状態管理 • リンク管理 • メールの送受信 • メッセージの送受信 である。 以上の仕様を満たすフレームワークを設計・実装する。 5.3 フレームワークの構成 本節ではフレームワークを構成する要素としてローカルキャッシュの管理、グ ループメンバーリスト、リンクマネージャについて述べる。 5.3.1 ローカルキャッシュの管理 本フレームワークでは、ネットワークアーカイブと呼ばれる、グループごとに 存在する仮想的な情報共有空間を実現する。 ネットワークアーカイブには、 「リソース」と「フォルダ」という 2 種類のリソー スを保持することができ、フォルダは他のフォルダやリソースを含むことによっ て階層構造をつくる。 実際には、ネットワークアーカイブはどこかに実体が存在するものではなく、 オーバレイネットワークに接続している各ノードのローカルキャッシュ間で、常に 内容の同期が取れている前提の元に、1 つの仮想的な情報共有空間を想定している にすぎない。 フレームワークは、このローカルキャッシュを管理し、オーバレイネットワーク 上の他のノードのローカルキャッシュと内容の同期が取れている状態を保つように 動作する。 そのために、アプリケーションからのローカルキャッシュに対するリソースの追 加・更新・削除等の変更作業が行われる時に、他のノードに後述するメッセージ によってその変更作業の内容が伝達される。それぞれのノードは、このようなリ ソースに対する変更作業のメッセージを受信した場合、その内容を、各ノードの ローカルキャッシュに反映する。これによって、アプリケーションに対して、ネッ トワークアーカイブに対する透過的なアクセスが実現される。 24 5.3.2 グループメンバーリスト 本フレームワークでは、オーバレイネットワークに接続しているノードは、そ のオーバレイネットワークに対応するグループのメンバー全員の情報を把握する。 これをグループメンバーリストと呼ぶ。 グループメンバーリストに含まれる情報を表 5.2 に示す。 表 5.2: グループメンバーリストに含まれる情報 番号 情報 説明 1 メンバー識別名 2 名前 3 接続状態 4 ロケーション (IP アドレスお よびポート番号) 5 6 情報更新日時 接続リンク数 メンバーを一意に識別するための識別名。擬 似ノードであるメールサーバで利用するアカ ウントに対応付けられたメールアドレスを利 用する。 アプリケーション上で表示する等の目的で利 用されるメンバーの名前 オーバレイネットワークに接続しているか、 接続していないかの状態を示す。 メンバーに対応付けられたノードに対してリ ンクを形成するために必要なロケーション情 報。 この情報が更新された日時 メンバーに対応付けられたノードがオーバレ イネットワーク内のノードと形成しているリ ンクの数 本フレームワークでは、オーバレイネットワークに接続している各ノードにお いて、このグループメンバーリストの情報を常に最新の正しい状態に保つ。その ために、各メンバーおよびノードの情報が変更された場合には、後述するメッセー ジによってその変更内容を伝達する。また、それぞれのノードは、このようなグ ループメンバーリストに対する変更に関するメッセージを受信した場合、その内 容を、各ノードのグループメンバーリストに反映する。 5.3.3 リンクマネージャ リンクマネージャはノードが他のノードとの間に形成するリンクを管理する。 グループメンバーリストが更新され、他のノードの接続状態が変化した場合に は、リンクマネージャは、その変化に応じて新しくリンクを接続しようとしたり、 既にあるリンクを切断しようとしたりする。 25 またリンクマネージャは、定期的にリンクの生存確認を行い、下位層での障害 等によってリンクが切断された場合等にそのことをフレームワークに通知する。 5.3.4 メール送受信マネージャ メール送受信マネージャは、蓄積中継リンクによるメッセージ送受信のために 利用される。メール送受信マネージャは、メール送信部とメール受信部によって 成っており、メール送信部は SMTP によってメールを送信し、メール受信部は、 POP3 あるいは IMAP によってメールを受信する。 メールの送信は、オフラインのノードに対してメッセージを送信する必要が生 じたときに随時行われ、メールの受信は、ノードがオンラインになるときに行わ れるのと、ポーリングによりメールの受信が確認される。 5.4 メッセージ グループ内のノードは、ノードのネットワーク接続状態変化や、ネットワーク アーカイブに対する変更をグループ全体で共有するために、相互にメッセージを 交換する。メッセージはリンクを通じて交換される。 本フレームワークがノード間でやりとりする、メッセージの種類を表 5.3 に示す。 表 5.3: メッセージの種類 種類 説明 LOGIN STATE JOIN DROP PING GROUP LOGOUT GET PUT DELETE LIST ネットワークへの接続を通知する 自ノードの把握しているグループリストを通知する グループへ新たに参加するために既存のグループに対して承認要求を行う グループから脱退する 他のノードの応答性を確認する グループメンバーリストの内容を転送する ネットワークからの切断を通知する リソースの取得を要求する リソースの登録・更新を要求する リソースの削除を要求する フォルダ内のリソースリストを通知する メッセージの種類には、ノードの状態変化を通知するための、LOGIN, STATE, JOIN, DROP, PING, GROUP, LOGOUT と、ネットワークアーカイブに対する 変更を通知・共有するための GET, PUT, DELETE, LIST とがある。 26 5.4.1 メッセージのフォーマット 0 1 Protocol Header 2 3 4 Protocol Version Content Length 5 6 7 Message Type Serial Number Message Date Message Content Body 図 5.1: メッセージフォーマット メッセージのフォーマットを図 5.1 に示す。メッセージには常に 24 バイトのヘッ ダが付いており、先頭から 2 バイトのプロトコルヘッダ、2 バイトのプロトコルバー ジョン、4 バイトのメッセージ種別、4 バイトのメッセージの本体部のデータ長、 4 バイトのメッセージシリアルナンバー、そして、8 バイトのメッセージ送信日時 (1970 年 1 月 1 日 0 時 0 分 [GMT] からの経過ミリ秒) が含まれている。複数バイト の整数についてはネットワークバイトオーダー表現を用いる。 5.4.2 メールによるメッセージの送信 メッセージを送信する対象のノードがオフライン状態の場合、メッセージが蓄 積中継リンク、つまりメールによって送信されることになるが、本フレームワーク では、メッセージをメールによって伝送する時に以下の方法に基づいてメッセー ジを送信する。 まず、メッセージを MIME エンコードする。そしてエンコードされたメッセー ジをメールの Body 部に設定する。メールのヘッダ部に、本フレームワークのメッ セージであることを示す特別なヘッダを追加する。 5.5 ノードの基本動作 ノードの一連の基本動作に沿って、本フレームワークの設計と実装を述べる。 新しいグループの作成 それぞれのノードは、新規にグループを作成することができる。 27 ノードは新しいグループを識別するための新しいグループ識別名を決定し、そ の識別名に基づいて新しいグループを作成する。 新しく作られるグループの初期メンバは、グループを作成したメンバのみである。 新しいグループが作成されるとフレームワークによってそのグループメンバリ ストとネットワークアーカイブのローカルキャッシュが管理されるようになる。 既存グループへの参加 ノードが既存のグループへ新たに参加する場合は、参加対象のグループのに既 に参加しているノードに対してグループへの参加許可の要求を JOIN メッセージ として送信する。 参加許可の要求を受けたノードがその要求に対して参加許可する場合は、自ノー ドのグループメンバーリストに参加許可元のノードの情報を追記し、そのグルー プメンバーリストの内容をグループ内の他のノード及び、参加要求元のノードに GROUP メッセージとして送る。 グループの他のノードはそのメッセージを受けて、ノード毎のグループメンバー リストの内容を更新する。 参加要求元のノードはグループメンバーリストを受け取ったことで、自身がそ のグループへの参加を許可されたことを確認する。 ネットワークへの接続 ノードがネットワークに接続するときには、まず、そのノードがネットワーク に接続していない間に他のノードから発信されたメッセージを、各ノードに対応 した擬似ノードから取得し、そのメッセージの内容を、グループメンバーリスト およびローカルキャッシュへ反映する。 その後、グループメンバーリストの内容に基づいて、グループ内のオンライン 状態のノードに対してリンクを試みる。 リンク接続要求を受けたノードがそれを受容すると、LOGIN メッセージをグ ループ内の全てのノードに対して通知する。リンクが存在するノードに対しては リンクを経由してメッセージを送信し、リンクが存在しないノードに対しては、擬 似ノードに対してメッセージを送信する。LOGIN メッセージを受け取ったグルー プ内のノードは、グループメンバーリストへその内容を反映し更新する。 ネットワークからの切断 ノードがネットワークから切断する場合は、まず全てのノードに対して、LOGOUT メッセージを送信する。リンクが存在するノードに対してはリンクを経由 してメッセージを送信し、リンクが存在しないノードに対しては、擬似ノードに 対してメッセージを送信する。その後、全てのリンクを切断する。 28 ネットワークアーカイブに対する更新 ノードがネットワークアーカイブに対してリソースの新規追加や更新を行うと き、そのノードはグループ内の他の全てのノードに対して PUT メッセージを送 る。リンクが存在するノードに対してはリンクを経由してメッセージを送信し、リ ンクが存在しないノードに対しては、擬似ノードに対してメッセージを送信する。 PUT メッセージを受信したノードは、ローカルキャッシュ内の該当リソースと比 較し、ローカルキャッシュ内のリソースより新しいと判断された場合、更新された 内容をローカルキャッシュに反映する。 5.6 フレームワークの実装 本フレームワークは、Java のクラス群として実装する。本フレームワーク中に 存在する主要なクラスの関連を図 5.2 のクラス図に示す。 本フレームワーク実装で中心的な役割を担うクラスは、Network クラスである。 Network クラスは、1 つのオーバレイネットワーク全体を把握し、アプリケーショ ンに対してネットワークアーカイブのリソースへのアクセス、グループやそのメ ンバの状態へのアクセスを提供すると共に、リンクやメッセージ等を用いてオー バレイネットワーク内のノードとしての機能を達成する。 29 Application Notifies Generate Use NetworkEvent <<interface>> NetworkListener Group Network Framework Open and have Resource Use Tied Generate / Use NetworkMessage User Folder Include Use Link Tied LocalCache Have Use MailSender Use Construct and send MailMessage ResourceHistory Receive MailReceiver LocalResource Framework 図 5.2: フレームワークのクラス図 30 第6章 フレームワークの応用 第 5 章で設計したフレームワークの応用として、協調作業支援環境を実現する アプリケーション collaboware を実装する。 6.1 応用の目的 本アプリケーションを実装する目的は、フレームワークの有効性を検証するこ とにある。実際に協調作業支援を行うためのアプリケーションを実現し、動作を 確認することで、フレームワーク自体の有効性について確認することができる。 6.2 実装環境 collaboware は、メンバーの PC 上にで動作するアプリケーションとして実装する。 今回 collaboware の実装には、Java 言語を用い、GUI の実装のために SWT(Standard Widget Toolkit) 及び JFace を用いた。 実装環境として Java 言語を用いることによって、Java VM がインストールされ ていれば、OS やコンピュータのアーキテクチャが異なっていてもプログラムを実 行することができる。アドホックグループにおいては、一般的な企業などと違い、 メンバの利用するコンピュータの OS やアーキテクチャについて統一されていると いう前提を置くことができない。複数の実行環境をサポートできることは、シス テムの利用可能性を大きくするうえで必要なことである。 従来は、実行速度などのパフォーマンスの面で不利であった Java であるが、近 年のコンピュータ自体の性能向上と、VM 技術の進化によって、ネイティブコード のプログラムに比べても遜色のない実行速度を得ることができるようになった。 SWT と JFace はオープンソースの統合開発環境である Eclipse の開発のため に産み出された GUI ツールキット及びフレームワークである。JNI(Java Native Interface) を積極的に利用することで、従来の AWT や Swing などの Java 標準の GUI に比べて軽快で OS の GUI コンポーネントとの親和性の高いユーザインタフェ イスを実現することができる。 31 6.3 機能 本アプリケーションは、「プレゼンス共有」、「テキストチャット」および「ファ イル共有」の機能を含む。本節では、その詳細を説明する。 図 6.1: collaboware 画面 6.3.1 プレゼンス共有 同じグループ内の他のメンバーが、ネットワークに接続されているかどうかを リアルタイムに確認する機能を持っている。 また、メンバーはそれぞれ自分の状態を選択、或いは文字によって入力するこ とによって、他のメンバーに自分のステータスを伝えることができる。 6.3.2 テキストチャット 同時にオンライン状態になっているグループ内のメンバー間で、テキストでの リアルタイムのコミュニケーションが可能である。 6.3.3 ファイル共有 グループ内のメンバーでのファイル共有の機能を持つ。この機能はフレームワー クの持つネットワークアーカイブを利用したものである。バージョン管理機能を 持っている。 32 第7章 評価 本章では、本研究で設計・実装した協調作業支援環境が、 「ブートストラップ問 題」及び「オフライン同期問題」について解決できるかを確認する動作試験につ いて述べる。 7.1 試験環境 今回の動作試験では、様々なネットワーク環境においての動作を検証するため に、2 種類の試験環境を用いた。 環境 A : 同一 LAN セグメントに接続した試験環境 ⇊∙⇥∞⇳⇩⇮ ∑∞⇥ ⇵⇼ ἠὊἛᾐ ἠὊἛᾑ ἠὊἛᾒ 図 7.1: 同一 LAN セグメントに接続した試験環境 図 7.1 に示す試験環境は、１つの LAN セグメントに全てのノードが接続してい ることを想定した試験環境である。 動作試験に参加するノードとしてノードＡ、ノードＢ、およびノードＣの 3 つ のノードを用意し、それぞれのノードを、PC は 100BASE-TX 規格のイーサネッ 33 トでハブと接続し、同じくハブに接続されたルータを介してインターネットに接 続する。 環境 B : インターネットを介して接続した試験環境 ⇊∙⇥∞⇳⇩⇮ ἠὊἛᾐ ἠὊἛᾑ ἠὊἛᾒ 図 7.2: インターネットを介して接続した試験環境 図 7.2 に示す試験環境は、それぞれのノードが別々の LAN セグメントに位置し、 インターネットを介して接続することを想定した試験環境である。 動作試験に参加するノードとしてノードＡ、ノードＢ、およびノードＣの 3 つ のノードを用意した。ノードＡは慶應義塾大学湘南藤沢キャンパス (SFC) のキャ ンパスネットワークシステム (CNS) の特別教室に設置され有線 LAN セグメント に接続された PC であり、ノードＢは同じく SFC の CNS に、無線 LAN(802.11a) にて接続詞、無線 LAN セグメントに接続された PC であり、ノードＣはケーブル テレビ事業者が運営する家庭向けのインターネット接続サービスを利用してイン ターネットへ接続している PC である。 7.2 試験方法 動作試験には、第 6 章で実装を行った collaboware を用いて行う。動作試験では、 前述した 2 種類の試験環境においてそれぞれ、collaboware を後述するシナリオに 沿って各ノードの挙動を制御した場合に、ブートストラップ問題およびオフライ ン同期問題の解決が図られるかを確認し、またその過程でそれぞれのノードがど のような挙動を示すかを観察する。 ノード間、あるいは擬似ノードに対して行われている通信の詳細について観察す るために、OGA 氏のフリーソフトウェアである TCP Monitor Plus[23] を利用した。 7.2.1 ブートストラップ問題解決の確認のための動作試験 34 3.4.2 節で述べたブートストラップ問題の解決を確認するための動作試験シナリ オを図 7.3 に示す。 ᧓℉ ⇴∞⇯≤ ⇴∞⇯≥ ⇴∞⇯≦ Ⅎ ℳ ℴ ℵ ℶ ℷ ℸ ℹ ℺ ℻ ℼ ℽ ℈※⁂⇈⇯−⇟٭ ⇐∙∏⇊∙ཞ७⅙⅙≋⇐∞⇶−⇊⇳⇩⇮∕∞⇕↚ዓↆཞ७‛ ⇐⇻∏⇊∙ཞ७‒‒‒‒‒‒≋⇐∞⇶−⇊⇳⇩⇮∕∞⇕ⅺ↸Џૺↄ↻ཞ७≌ 図 7.3: ブートストラップ問題解決の確認のための動作試験シナリオ 図 7.3 は、ノードＡ、ノードＢ、ノードＣの 3 つのノードのオーバレイネット ワークへの接続状態の時間軸に沿った変遷を示したものである。 まず初期状態において全てのノードはオンライン状態であり、3 つのノードは相 1 のタイミングでノードＢおよびノードＣは一 互に接続されている状態である。⃝ 2 のタイミングでノードＢがオンラインになり、⃝ 3 旦オフラインとなり、その後⃝ 4 のタイミングで全てのノー のタイミングでノードＣがオンラインになる。次に、⃝ 5 のタイミングでノードＡ、⃝ 6 のタイミングで ドがオフラインとなり、その後、⃝ 7 のタイミングでノードＣがそれぞれオンラインになる。 ⃝ 8 のタイミ ノードＢ、⃝ 9 のタイミングでは全てのノード ングで再度全てのノードがオフラインとなり、⃝ 10 のタイミングでノードＡ、⃝ 11 の に振られている IP アドレスを変更する。その後⃝ 12 のタイミングでノードＣがオンラインとなる。 タイミングでノードＢ、⃝ このシナリオでは、 2 および⃝ 3 のタイミングでオーバレイネットワーク内にオンラインのノード 1. ⃝ が継続的に存在し続ける状態でブートストラップ問題が解決されるか確認し、 5 ・⃝ 6 ・⃝ 7 のタイミングでオーバレイネットワーク内にオンラインのノードが 2. ⃝ 継続的に存在し続けない状態でブートストラップ問題が解決されるか確認し、 9 のタイミングで IP アドレスを変更することによって、⃝ 10 ・⃝ 11 ・⃝ 12 の 3. そして⃝ タイミングでそれぞれのノードにおいて把握している他ノードのロケーショ 35 ンについての情報が正しくないものとなった場合にブートストラップ問題が 解決されるかを確認する。 オフライン同期問題解決の確認ための動作試験 7.2.2 3.4.1 節で述べたオフライン同期問題の解決を確認するための動作試験シナリオ を図 7.4 に示す。 ᧓℉ ⇴∞⇯≤ ⇴∞⇯≥ ⇴∞⇯≦ Ⅎ ℳ ℴ ℵ ℶ ℷ ℸ ℹ ℺ ℻ ℼ ℽ ℾ ⇐∙∏⇊∙ཞ७⅙⅙≋⇐∞⇶−⇊⇳⇩⇮∕∞⇕↚ዓↆཞ७‛ ⇐⇻∏⇊∙ཞ७‒‒‒‒‒‒≋⇐∞⇶−⇊⇳⇩⇮∕∞⇕ⅺ↸Џૺↄ↻ཞ७≌ ૼ↝ႆဃ⅙⅙⅙⅙≋⇖∑∞⇽ϋ↖σஊↈ↺ૼ↝ႆဃ≌ 図 7.4: オフライン同期問題解決の確認のための動作試験シナリオ まず初期状態において全てのノードはオンライン状態であり、3 つのノードは相 1 のタイミングでノードＡで更新が発生する。そ 互に接続されている状態である。⃝ 2 のタイミングでノードＡがオフラインになる。次に⃝ 3 のタイミングでノー の後⃝ 4 のタイミングでノードＡがオンラインになり、⃝ 5 ドＢで更新が発生する。その後⃝ 6 のタイミングでノードＣで更新 のタイミングでノードＢがオフラインになる。⃝ 7 のタイミングでノードＣ、⃝ 8 のタイミングでノードＡがオフ が発生し、その後⃝ 9 のタイミングでノードＢがオンラインになる。⃝ 10 のタイ ラインになり、そして⃝ 11 のタイミングでノードＢがオフラインにな ミングでノードＢで更新が発生し、⃝ 12 のタイミングでノードＡおよびノードＣがオンラインに、⃝ 13 のタイミング り、⃝ でノードＢがオンラインになる。 このシナリオでは、 36 1 のタイミングにノードＡで発生 1. まず全てのノードがオンライン状態である⃝ した更新がノードＢおよびノードＣに反映されることを確認し、 3 のタイミングにノードＢで発生した更新が⃝ 4 のタイミングの時点でノード 2. ⃝ ＡがオンラインになったときにノードＡに反映されることを確認する。 6 のタイミングにノードＣで発生した更新が⃝ 8 のタイミングでノードＢ 3. 次に⃝ に反映されることを確認する。 10 のタイミングにノードＢで発生した更新が⃝ 12 のタイミングでノー 4. 最後に、⃝ ドＡおよびノードＣに反映されることを確認する。 7.3 試験結果 同一 LAN セグメントに接続した試験環境における、ブートストラップ問題の解 決の確認のための動作試験での各ノードの挙動の観察結果を表 7.1 に示す。 表 7.1: 環境 A におけるブートストラップ問題の解決の確認のための動作試験結果 1 ⃝ 2 ⃝ 3 ⃝ 4 ⃝ 5 ⃝ 6 ⃝ 7 ⃝ 8 ⃝ 9 ⃝ 10 ⃝ 11 ⃝ 12 ⃝ ノードＡ ノードＢ ノードＣ ノードＡ、Ｂと接続 IP addr:192.168.11.2 ノードＢ、Ｃとのリンク が切断 ノードＢから接続 ノードＣから接続 ノードＢ，Ｃから切断 オンライン状態 ノードＢから接続 ノードＣから接続 ノードＢ，Ｃから切断 IP アドレスを更新 IP addr:192.168.11.3 オンライン状態 ノードＢから接続 ノードＣから接続 ノードＡ、Ｃと接続 IP addr:192.168.11.6 ノードＡ、Ｃから切断 ノードＡ、Ｂと接続 IP addr:192.168.11.3 ノードＡ、Ｂから切断 ノードＡに接続 ノードＣから接続 ノードＡ, Ｃから切断 ノードＡ、Ｂに接続 ノードＡ, Ｂから切断 ノードＡへ接続 ノードＣから接続 ノードＡ, Ｃから切断 IP アドレスを更新 IP addr:192.168.11.2 ノードＡ、Ｂへ接続 ノードＡ, Ｂから切断 IP アドレスを更新 IP addr:192.168.11.4 ノードＡに接続 ノードＣから接続 ノードＡ、Ｂへ接続 インターネットを介して接続した試験環境における、ブートストラップ問題の 解決の確認のための動作試験での各ノードの挙動の観察結果を表 7.2 に示す。 ブートストラップ問題の解決の確認を表 7.3 に示す。この動作試験によって、ブー トストラップ問題の動作試験の全ての確認事項において、同一 LAN セグメントに 接続した試験環境とインターネット経由で接続した試験環境の両方で期待通りの 37 表 7.2: 環境 B におけるブートストラップ問題の解決の確認のための動作試験結果 1 ⃝ 2 ⃝ 3 ⃝ 4 ⃝ 5 ⃝ 6 ⃝ 7 ⃝ 8 ⃝ 9 ⃝ 10 ⃝ 11 ⃝ 12 ⃝ ノードＡ ノードＢ ノードＣ ノードＡ、Ｂと接続 IP addr:133.27.26.132 ノードＢ、Ｃとのリンク が切断 ノードＢから接続 ノードＣから接続 ノードＢ，Ｃから切断 オンライン状態 ノードＢから接続 ノードＣから接続 ノードＢ，Ｃから切断 IP アドレスを更新 IP addr:133.27.26.133 オンライン状態 ノードＢから接続 ノードＣから接続 ノードＡ、Ｃと接続 IP addr:133.27.63.7 ノードＡ、Ｃから切断 ノードＡ、Ｂと接続 IP addr:61.21.231.60 ノードＡ、Ｂから切断 ノードＡに接続 ノードＣから接続 ノードＡ, Ｃから切断 ノードＡ、Ｂに接続 ノードＡ, Ｂから切断 ノードＡへ接続 ノードＣから接続 ノードＡ, Ｃから切断 IP アドレスを更新 IP addr:133.27.63.10 ノードＡ、Ｂへ接続 ノードＡ, Ｂから切断 IP アドレスを更新 IP addr:61.21.231.53 ノードＡに接続 ノードＣから接続 ノードＡ、Ｂへ接続 挙動を示すことが確認できた。よって、本フレームワークによってブートストラッ プ問題を解決できることが確認できた。 表 7.3: ブートストラップ問題の解決の確認 番号 1 2 3 確認事項 確 認 (環境 A) 2 および⃝ 3 のタイミングでオーバレイネットワーク内に ○ ⃝ オンラインのノードが継続的に存在し続ける状態でブー トストラップ問題が解決されるか 5 ・⃝ 6 ・⃝ 7 のタイミングでオーバレイネットワーク内にオ ○ ⃝ ンラインのノードが継続的に存在し続けない状態でブー トストラップ問題が解決されるか 9 のタイミングで IP アドレスを変更することに そして⃝ ○ 10 ・⃝ 11 ・⃝ 12 のタイミングでそれぞれのノードに よって、⃝ おいて把握している他ノードのロケーションについての 情報が正しくないものとなった場合にブートストラップ 問題が解決されるか 確 認 (環境 B) ○ ○ ○ 同一 LAN セグメントに接続した試験環境における、オフライン同期問題の解決 38 の確認のための動作試験での各ノードの挙動の観察結果を表 7.4 に示す。 インターネットを介して接続した試験環境における、オフライン同期問題の解 決の確認のための動作試験での各ノードの挙動の観察結果を表 7.5 に示す。 オフライン同期問題の解決の確認を表 7.6 に示す。この動作試験によって、オフ ライン同期問題の動作試験の全ての確認事項において、同一 LAN セグメントに接 続した試験環境とインターネット経由で接続した試験環境の両方で期待通りの挙 動を示すことが確認できた。よって、本フレームワークによってオフライン同期 問題を解決できることが確認できた。 39 表 7.4: 環境 A におけるオフライン同期問題の解決の確認のための動作試験結果 1 ⃝ ノードＡ ノードＢ ノードＣ ノードＡ、Ｂと接続 ‘PUT /test/folder/’ を送信 ノードＡ、Ｃと接続 ‘PUT /test/folder/’ をノー ドＡより受信、ローカルキ ャッシュへ反映 ノードＡが切断 ‘PUT /test/folder/res4.txt’ を送信（ノードＡに対して はメールにカプセル化して 送信） ノードＡから接続 ノードＡ、Ｂと接続 ‘PUT /test/folder/’ をノー ドＡより受信、ローカルキ ャッシュへ反映 ノードＡが切断 ‘PUT /test/folder/res4.txt’ をノードＢより受信、ロー カルキャッシュへ反映 ノードＡ、Ｃから切断 ノードＢが切断 ‘PUT /test/folder/res6.txt’ を送信（ノードＢに対して はメールにカプセル化して 送信） ノードＡから切断、オフラ イン状態へ 2 ⃝ 3 ⃝ ノードＢ、Ｃから切断 4 ⃝ ‘PUT /test/folder/res4.txt’ をメールにて受信、ローカ ルキャッシュへ反映、ノー ドＢ、Ｃに接続、 ノードＢが切断 ‘PUT /test/folder/res6.txt’ をノードＢより受信、ロー カルキャッシュへ反映 5 ⃝ 6 ⃝ 7 ⃝ ノードＢが切断 8 ⃝ ノードＢから接続 9 ⃝ ノードＢから切断、オフラ イン状態へ 10 ⃝ 11 ⃝ 12 ⃝ 13 ⃝ ノードＡから接続 ‘PUT /test/folder/res6.txt’ をメールにて受信、ローカ ルキャッシュへ反映、ノー ドＡへ接続、 ノードＡが切断 ‘PUT /test/folder/res10.txt’ を送信（ノードＡ、Ｃ共に メールにて送信） オフライン状態へ ‘PUT /test/folder/res10.txt’ をメールにて受信、ローカ ルキャッシュへ反映、ノー ドＣへ接続 ノードＢから接続 ノードＡ、Ｃへ接続 40 ‘PUT /test/folder/res10.txt’ をメールにて受信、ローカ ルキャッシュへ反映、ノー ドＡへ接続 ノードＢから接続 表 7.5: 環境 B におけるオフライン同期問題の解決の確認のための動作試験結果 1 ⃝ ノードＡ ノードＢ ノードＣ ノードＡ、Ｂと接続 ‘PUT /test2/folder/’ を送 信 ノードＡ、Ｃと接続 ‘PUT /test2/folder/’ を ノードＡより受信、ローカ ルキャッシュへ反映 ノードＡが切断 ‘PUT /test2/folder/res4.txt’ を送信（ノードＡに対して はメールにカプセル化して 送信） ノードＡから接続 ノードＡ、Ｂと接続 ‘PUT /test2/folder/’ を ノードＡより受信、ローカ ルキャッシュへ反映 ノードＡが切断 ‘PUT /test2/folder/res4.txt’ をノードＢより受信、ロー カルキャッシュへ反映 ノードＡ、Ｃから切断 ノードＢが切断 ‘PUT /test2/folder/res6.txt’ を送信（ノードＢに対して はメールにカプセル化して 送信） ノードＡから切断、オフラ イン状態へ 2 ⃝ 3 ⃝ ノードＢ、Ｃから切断 4 ⃝ ‘PUT /test2/folder/res4.txt’ をメールにて受信、ローカ ルキャッシュへ反映、ノー ドＢ、Ｃに接続、 ノードＢが切断 ‘PUT /test2/folder/res6.txt’ をノードＢより受信、ロー カルキャッシュへ反映 5 ⃝ 6 ⃝ 7 ⃝ ノードＢが切断 8 ⃝ ノードＢから接続 9 ⃝ ノードＢから切断、オフラ イン状態へ 10 ⃝ 11 ⃝ 12 ⃝ 13 ⃝ ノードＡから接続 ‘PUT /test2/folder/res6.txt’ をメールにて受信、ローカ ルキャッシュへ反映、ノー ドＡへ接続、 ノードＡが切断 ‘PUT /test2/folder/res10.txt’ を送信（ノードＡ、Ｃ共に メールにて送信） オフライン状態へ ‘PUT /test2/folder/res10.txt’ をメールにて受信、ローカ ルキャッシュへ反映、ノー ドＣへ接続 ノードＢから接続 ノードＡ、Ｃへ接続 41 ‘PUT /test2/folder/res10.txt’ をメールにて受信、ローカ ルキャッシュへ反映、ノー ドＡへ接続 ノードＢから接続 表 7.6: オフライン同期問題の解決の確認 番号 1 2 3 4 確認事項 確 認 (環境 A) 確 認 (環境 B) 1 のタイミングに 全てのノードがオンライン状態である⃝ ノードＡで発生した更新がノードＢおよびノードＣに反 映される 3 のタイミングにノードＢで発生した更新が⃝ 4 のタイミ ⃝ ングの時点でノードＡがオンラインになったときにノー ドＡに反映される 6 のタイミングにノードＣで発生した更新が⃝ 8 のタイミ ⃝ ングでノードＢに反映される 10 のタイミングにノードＢで発生した更新が⃝ 12 のタイミ ⃝ ングでノードＡおよびノードＣに反映される ○ ○ ○ ○ ○ ○ ○ ○ 42 第8章 関連研究 本章では、本研究の関連研究を示す。 8.1 Mikan SMTP/POP3 を利用したファイル共有システム Mikan(み んなで かん たんファ イル共有)[24] は、慶應義塾大学大学院で開発されたファイル共有システムである。 Mikan はその名前の由来にも現れているように、短期的な共同作業を想定し、ファ イル共有の場を設けるコストが低いことを優先した設計を行っており、SMTP/POP を利用して、数名のグループでのファイル共有の利用の場面で手軽に利用できる ことが評価されている。 Mikan も本研究と同様にメールをノード間の通信に利用しているが、Mikan が 全ての通信をメール経由で実現しようとしているのに対し、本研究では、基本的 には直接の通信でメッセージをやりとりし、対象のノードがオフラインの場合の み、メールを利用するという点で、アプローチの違いが見られる。 8.2 qwikWeb qwikWeb[25] は、Wiki エンジンと QuickML の機能を組み合わせて実現されたシ ステムである。qwikWeb では、メールの投稿によって Wiki のページが追加される。 このシステムの興味深いところは、ML 上での議論の過程が自動的にウェブページ に蓄積され閲覧可能なかたちにまとめられていくということである。また、従来 の Wiki が基本的に誰でも編集できる公開型のサービスであったが、この qwikWeb は、QuickML のメーリングリストに登録されたメンバーのみがページを編集可能 になるという、アクセス制限の仕組みを持っている。 本研究で実現した協調作業支援環境が、P2P 技術とメールシステムの組み合わ せによって実現されているのと似ていることは偶然ではないかもしれない。2 つの 別の技術やツールを組み合わせることによって、新しい使い方や機能が実現され ている点が興味深い。 43 第9章 おわりに 本章では、本研究のまとめを行い、今後の課題を示す。 9.1 本研究のまとめ 本研究では、アドホックグループを対象とした協調作業支援環境の要件をあき らかにし、その要件を満たすために必要な問題であるオフライン同期問題および ブートストラップ問題について定義した。そして、これら 2 つの問題を解決するた めに、一般的なサービス資源による擬似ノードを用いた協調作業支援環境のモデ ルを示し、フレームワークとして設計、実装を行い、また応用の実装を行い、動 作試験によって動作を確認した。 9.2 9.2.1 今後の課題 デプロイメント 本研究で実装した collaboware が、多くのグループで実際に利用され、その利 用から得られたフィードバックをアプリケーションおよびフレームワークに反映 し、洗練させ、さらに多くのユーザに利用してもらうというスパイラルプロセス を経ることで、本研究の目的であるアドホックグループで手軽に利用できる協調 作業支援環境の実現を、より高度に達成できると考える。 9.2.2 リソース保持の効率化 現状のモデルでは、ネットワークアーカイブ上の全てのリソースをローカルキャッ シュに保持する。また、取得した全てのバージョンについても、ローカルキャッシュ 内に保持する。しかし、実際の利用の中では、ネットワークアーカイブ内のリソー スのうち、ユーザが必要なリソースは一部に限られることが多い。ユーザの利用 状況等にあわせて、ノードがキャッシュするリソースを部分化することで、リソー ス保持の効率化を行うことが可能であり、今後の課題として取り組んでいきたい。 44 9.2.3 耐故障性の向上 協調作業支援環境の基盤として、ネットワークアーカイブの耐故障性を向上さ せることは必要不可欠である。今回の実装では、オーバレイネットワーク上の何 れかのノードに予期しない事態が発生して、メッセージの送受信が適切に行われ なかった場合や、オーバレイネットワーク上でのリンク、蓄積中継リンクを構成す る IP ネットワーク上の問題やメールシステムにおける問題があった場合に、それ を正しく認識することができない。これを正しく認識し、適切な対処を行う等の 仕組みを組み入れることで耐故障性の向上が図られ、より実用的な協調作業支援 フレームワークを実現できると考えられる。 45 謝辞 本研究を進めるにあたり、ご指導を頂きました慶應義塾大学環境情報学部教授 村井純博士、徳田英幸博士、同学部助教授、同学部助教授 楠本博之博士、中村修 博士、同学部専任講師 南政樹氏に感謝致します。 絶えずご指導とご助言を頂きました慶應義塾大学大学院政策・メディア研究科 後期博士課程 須子義彦氏に感謝致します。neco KG の仲山昌宏氏、鈴木貴晶氏に は日々の研究活動の中で様々な形のご支援を頂きました。感謝致します。 研究を進める中で、常に的確なご助言をして頂いた慶應義塾大学大学院政策・メ ディア研究科特別研究助手 斉藤賢爾氏に感謝致します。 最後に、このような素晴らしい人達と出会い、研究を通して自らを成長させる 機会を与えて頂いた、両親に対する感謝を以って謝辞を締めさせて頂きます。 46 参考文献 [1] 平成 16 年版 情報通信白書, 総務省, 2004 [2] 松下 温, 岡田 謙一 : コラボレーションとコミュニケーション, 共立出版, 1995 [3] Jessica Lipnack, Jeffrey Stamps, 榎本英剛訳 : バーチャル・チーム ― ネット ワーク時代のチームワークとリーダーシップ, ダイヤモンド社, 1998 [4] ダニエル・ピンク, フリーエージェント社会の到来 - 「雇われない生き方」は 何を変えるか, ダイヤモンド社, 2002. [5] fml project, http://www.fml.org/ [6] Majordomo, http://www.greatcircle.com/majordomo/Welcome.html [7] Yahoo!グループ, http://groups.yahoo.co.jp [8] QuickML, http://www.quickml.com/ [9] cvshome.org, https://www.cvshome.org/ [10] subversion.tigris.org, http://subversion.tigris.org/ [11] IBM Lotus, http://www.lotus.com/ [12] サイボウズ株式会社, http://www.cybozu.co.jp/ [13] 藤田一広, ASP におけるコンピュータセキュリティ, pp. 64–78, UNISYS TECHNOLOGY REVIEW 第 72 号, 2002. [14] Intranets.co.jp, http://www.intranets.co.jp [15] Groove Virtual Office, http://www.groove.net/ [16] アリエル・エアワン, http://www.ariel-networks.com/product/airone/summary.html [17] Jabber, http://www.jabber.org/ [18] Media Art Online, http://www.media-art-online.org/ 47 [19] wija, http://www.media-art-online.org/wija/ [20] Gmail, https://gmail.google.com/ [21] 伊藤直樹, P2P コンピューティング 技術解説とアプリケーション , ソフト・ リサーチ・センター, 2001. [22] Eclipse.org Main Page, http://www.eclipse.org [23] OGA’s Web Page, http://hp.vector.co.jp/authors/VA032928/index.html [24] 西村祐貴, SMTP を利用したファイル共有システムに関する研究, 2003. [25] qwikWeb - qwik.jp, http://qwik.jp/qwikWeb.html 48 付 録A collaboware Ver. 0.6.0 本論文の付録として、collaboware の執筆時における最新のバージョンである Version 0.6.0 の、リリースノートおよびマニュアルを添付する。 A.1 リリースノート ---------------------------------------------------------------------collaboware version 0.6.0 [20041025] alpha release RELEASE NOTES 2004/10/25 ---------------------------------------------------------------------by Jun Komatsu <[email protected]> http://www.sfc.wide.ad.jp/kg/neco/ http://www.collaboware.com ---------------------------------------------------------------------- 動作環境 -- 本プログラムを動作させるには、Java VM が必要となります。 Sun Microsystems による最新の JRE(現時点での最新版は Java2 Standard Edition 1.4.2_05) は、以下の URL よりダウンロードできます。 -- http://java.com/ja/ ※ J2SE 1.4 以上の環境が必要です。 -- 本プログラムは、SWT(Standard Widget Toolkit) および、JFace のライブラ リを利用して実装されています。本プログラムの実行には、swt.jar および、 jface.jar, runtime.jar などの SWT/JFace 関連 JAR ファイルと、各ネイティ ブ環境用のダイナミックリンクライブラリが必要となります。配布用アーカイブ には、Win32 用の swt-win32-2135.dll を同梱しておりますが、それ以外の環境 での動作には、各環境用の SWT ライブラリを必要とします。以下の URL よりダウ ンロードできます。 -- http://www.eclipse.org -- 本プログラムは、以上の他、以下のライブラリ等を利用しています。ここで あげているライブラリ等は配布アーカイブ内に同梱していますが、最新版等は、 各一時配布元からダウンロードして下さい。 49 -- Java Activation Framework -- Java Mail API -- log4j ---------------------------------------------------------------------- 注意事項・免責 -- このリリースはプログラムの正式リリース前にプログラムの内容を確認して 頂くためのアルファリリースとなっています。このバージョンは、現状のソフト ウェアを多くの方に試用していただくことで、ソフトウェアの問題を明らかにし、 また、実際に利用される場で得られた経験を反映することで、リリースバージョン でのよりよいプログラムの配布を目的とするものです。 今後、ソフトウェアの仕様、データファイルフォーマット、通信プロトコル仕様な どは、今後大きく変化する可能性が高く、このアルファリリースは、次回以降の バージョンとの相互運用性は一切保障されておりません。 このソフトウェアの利用によって生じたいかなる損害も、開発者及びその関連団体 等は、一切その責任を負いかねます。予めご了承ください。 ---------------------------------------------------------------------- 連絡先 本プログラムに関するお問い合わせは下記までお願い致します。 小松 純 <[email protected]> ---------------------------------------------------------------------- A.2 マニュアル collaboware とは? collaboware は、小規模なグループでの共同作業を支援するためのソフトウェアです。 collaboware は、グループのメンバーと作業中のファイルを共有し、プレゼンス共有と、テ キストチャットでのコミュニケーションすることができます。 50 collaboware のネットワークモデルと動作のしくみ collaboware は、基本的にはピア・ツー・ピアモデルでの通信を行います。オンライン になっているノードは相互にコネクションを張り、そのコネクションを通じて通信します。 オフラインのノードに対しては、メールを利用してメッセージを送信します。それぞれの メールボックスにはオフラインの間に届いたメッセージが蓄積され、ノードがオンラインに なったときに、メールボックス内に蓄積されたメールを一括受信します。 （※ collaboware が送信するメールには、’x-collaboware: 1’ というメールヘッダがつきます。このヘッダの 有無を利用して、MUA で振り分け設定をすることで、collaboware 用のメールと、通常 のメールを同じメールアカウントで利用できます） ご利用方法 0. ご注意 現在バージョンが違うと相互接続できません。新しいバージョンがリリースされたら、 古いバージョンのファイルは削除して再インストール、再設定が必要です。この仕様は今 後は改善する予定です このソフトウェアは、メールを利用してノードオフライン時のメッセージ伝達を行いま す。普段利用しているメールアドレスを collaboware で利用することもできますが、その 場合は、collaboware 用のメールかどうかを、x-collaboware ヘッダの有無によって判別し て、collaboware 用のメールを普段使っているメーラーでダウンロードしない設定にする ことをお勧めします。また、collaboware 用のメールが削除されないようにしてください。 メールボックスから collaboware 用のメールが削除されると正しく通信が行われなくなる 可能性があります。 1. インストール まず、Java VM がシステム内にインストールされていることを確認してください。イ ンストールされていない場合は事前にインストールしてください。 (Win32) ダウンロードした zip ファイルを適当なディレクトリに展開します。これでイ ンストールは完了です。ディレクトリの中に「collaboware.exe」ができているので、この ファイルをダブルクリックすれば起動します。 collaboware.exe のショートカットを、デ スクトップや、クイック起動、あるいはスタートメニューの中に登録してください。 2. 初期設定 collaboware.exe を起動すると、最初に「プロファイルの選択」ダイアログボックスが 表示されます。ここに、 collaboware で使うメールアカウントのメールアドレスを入力し ます。このメールアドレスはネットワーク上で、あなたを一意に識別するＩＤとしても利 用されることになります。(図 A.1) 2 回目以降の起動では、この画面で、既に存在しているプロファイルを選択します。 新しいプロファイルを作ると、最初に「設定」ダイアログが表示されます。(図 A.2、図 A.3、図 A.4) ここで、ニックネーム、メールサーバーの情報などを設定します。 51 図 A.1: プロファイルの選択 図 A.2: 基本設定 ニックネーム グループの他のメンバーに表示される自分の名前を指定します。わかりや すい名前を指定しましょう。 Mail Transfer Protocol メール送信用のプロトコルを指定します。smtp または smtps(SMTP over SSL) のどちらかを指定します。 Server Host Name/Port メール送信用のサーバーのホスト名、ポート番号を指定し ます。 Username, Password SMTP Auth により SMTP サーバーの認証がある場合などは、 ここにユーザー名とパスワードを指定します。それ以外の場合は入力は必要ありま せん。 Mail Access Protocol メール受信用のプロトコルを指定します。pop3, pop3s( POP3 over SSL), imap, imaps(IMAP over SSL) の 4 つから選択します。 52 図 A.3: メールアカウント設定 図 A.4: 詳細設定 53 Server Host Name/Port メール受信用サーバーのホスト名、ポート番号を指定します。 Username, Password メール受信用サーバー (POP3 or IMAP) 用のユーザー名、パス ワードを指定します。 サーバーポートの指定 collaboware で利用するポートを指定します。標準は 1200 ですが、 ファイアウォールなどによって制限されている場合はこのポート番号を変更してく ださい。 SSL で証明書を検証しない smtps, pop3s, imaps で、SSL の証明書の検証を行いません。 3. 接続 プロファイル選択後、 （初回起動時にはその後設定ダイアログにて設定後）、メインウィ ンドウが表示されます。 ネットワークメニューの、「接続」メニューを選択するか、ツールバーの「接続」ボタ ンをクリックすると、ネットワークに接続します。接続中は「接続」ダイアログ (図 A.5) に接続状況が表示されます。 図 A.5: 接続ダイアログ メールボックスに大量のメールが残っている場合、接続に時間がかかる場合があります。 ネットワークの接続が完了すると、Disabled 状態だったメインウィンドウの各ペインが Enabled 状態になります。 メールアカウントの設定に誤りがある場合や、ネットワークに問題がある場合は接続に 失敗することがあります。 4. グループの作成/既存グループへの参加 ネットワークに接続したら、新たにグループを作成するか、既存のグループへ参加する かして、グループへ所属します。 54 図 A.6: 新しいグループの作成 グループの作成 新たにグループを作成します。作成したグループのメンバーは最初は 自分ひとりです。ネットワークメニューの「新しいグループの作成」メニューを選択する と新しいグループの作成ダイアログ (図 A.6) が開きます。ここに新しいグループのグルー プ ID を入力し OK ボタンをクリックすると、新しいグループが作成されます。自分が所 属しているグループは、メインウィンドウ左側のペインに表示されるリソースツリーに、 最上階層のリソースとして表示されます。 図 A.7: 既存のグループへ参加する 既存グループへの参加 既存のグループへ参加するためには、そのグループにあなたを 紹介してくれるメンバーが必要です。 ネットワークメニューから、「既存グループへの参加」メニューを選択すると、ダイア ログボックス (図 A.7) が開きます。参加したいグループのグループ ID、あなたをそのグ ループに紹介してくれるメンバーのユーザー ID（メールアドレス）をダイアログボック スに入力して OK ボタンをクリックします。すると、そのユーザーに向けて、グループ参 加承認要求が送信されます。そのユーザーがグループ参加承認すると、そのグループへ参 加することができます。 今後の予定 • NAT 裏同士での接続 • 掲示板機能の実装 • プレゼンス共有機能の強化 55 • 常駐起動 • セキュリティ強化 • Mac OS X への対応 リリースヒストリー • Version 0.6.0 (2004/10/25) – ネットワーク接続中に、他ノードへのリンクがつながったり切れたりしていた 問題を修正 – 自ノードへの不要なループバックリンクが張られることがあった問題を修正 – 使い方へのリンクを追加 – オートコミットモードの追加とデフォルト設定 – ファイルのアイコンをネイティブアイコンを使うようにした – chat に日付を表示 – group が選択されていない状態では chat 画面を disabled に – imap/imaps への対応 • Version 0.5.0 (2004/10/05) – 初回公開 56