図1: GT3の構成
首藤一幸, "グリッド & Java 最前線", 月刊ジャバワールド 2003年 11月号, pp.62-73, IDGジャパン, 2003年 9月
"Grid"は、格子を意味する一般名詞である。 しかし、コンピュータの世界では、1990年代半ば過ぎから この言葉が特別な意味を持ち始めている。 グリッドの語源はthe Electric Power Grid、つまり世界を覆う電力の送電網である。 これと同様の社会基盤を情報について実現しようというコンセプトが提唱され、 グリッドコンピューティングと呼ばれるようになった。
電力と同じとはどういうことかというと、 コンセントについて考えてみるとよい。 電灯やテレビなど電化製品をコンセントにつなぎさえすれば、 電力の供給、つまり電気サービスを受けることができる。 サービスを受ける側は、コンセントの向こう側で 何が行われているかを知る必要はまったくない。 コンセントの裏側では、地域の電力会社が、原子力、火力など様々な種類の 発電設備を運転し、供給量を調節しながら、ときにはお互いに電力を融通し合い、 送電網を通じて消費者に電気サービスを提供している。
グリッドコンピューティングの場合、 電気にあたるのは、様々な計算機資源、情報資源や、そこからの恩恵である。 そこでは、コンピュータの処理能力やデータ、大容量ストレージ、 ソフトウェア、各種のセンサ、入出力装置、 実験装置、さらには、人、人が持つ知識といった様々な資源が仮想化される。 仮想化されるということは、高性能コンピュータといった「モノ」が手元になくとも、 その効果、恩恵を受けることができる、ということである。 仮想化された資源の授受、融通はネットワーク越しに行われ、 それが容易かつ安全であるべきことは、言うまでもない。
グリッドのコンセプトは、資源の授受だけにとどまらない。 2001年頃まで、グリッドは主に科学技術計算の手段として利用されてきた。 これはつまり、グリッド技術を利用して仮想化した多量の計算能力を、 組織の枠を越えて連携、集約することで、飛躍的に性能の高い 仮想スーパーコンピュータを構築していた、と説明できる。
この1,2年で、グリッドのビジネス応用が盛んに検討されるようになった。 仮想化された資源を融通するための研究開発、標準化だけでなく、 売買し、流通させるための取り組みも盛んに行われている。 例えば、GGF（コラム参照）では、 資源の利用に対する課金には欠かせないアカウンティングのための 標準仕様の作成も進められている。 近年、自社でサーバや管理スタッフを抱える代わりに、ITサービスを必要に応じて 購入するというコンセプト、ユーティリティコンピューティングが注目されている。 つまり、モノからサービスへの、取り引き対象の転換である。 このためには、機材やソフトウェアといったITリソースの仮想化が必要となる。 これが、グリッドがユーティリティコンピューティングの基盤技術と 目される理由である。
最近までグリッドは、主に科学技術計算の道具であった。 例えば、方々に分散しているスーパーコンピュータを連係させて 単体では不可能であるような大規模な計算をさせるメタコンピューティングや、 数千から百万台のPCで分散処理を行うSETI@homeに代表される メガコンピューティングは、 主に計算能力に着目した一種のグリッドであると言える。 こういった計算能力のグリッド以外にも、 ペタバイト級の超大規模データの処理を目的とするグリッドや、 数千、数万のセンサから得られる多量のデータを取り扱うためのグリッド、 稀少な実験装置からのデータを遠隔地の高性能コンピュータ群で処理するグリッド、 世界中に散らばっている技術者や研究者のコラボレーションを支援するグリッドなど、 様々な資源を扱うグリッドが研究、開発されてきた。 現在、計算能力のグリッドでは、 薬剤や建築物、自動車、航空機、電子機器設計のためのシミュレーション、 制御、流通のための最適化問題、多量の画像処理などが行われ、 データのグリッドでは、遺伝子情報処理、高エネルギー物理学の実験データ処理 などが行われている。 実験装置のグリッドでは、電子顕微鏡や電波望遠鏡、脳磁計などのデバイスを 大陸をまたいで利用する研究がなされている。 また、コラボレーションのためのグリッドでは、 大規模分散遠隔ミーティングや、実験結果、可視化結果の共有に加え、 分散パフォーマンスなど芸術的な試みもなされている。
これらの先端的な研究開発は、我々の日常生活とは縁遠く感じられるかもしれない。 しかし、コンピュータやネットワークの能力は、 10年前のスーパーコンピュータが今日のPCであることを思い出して欲しい。 前述の現グリッドは、今はハイエンドであり、個人が直接触れるものとは なっていない。 しかし、何年か後には、その恩恵を、より直接的に多くの人が受けることになろう。 よく言われることだが、WWWも高エネルギー物理学の研究者が研究のために 開発したツールから始まり、今や社会基盤の一部となった。 また、コンセントの裏側には電力網が広がっており、 それを支える多くの技術は長年の研究開発の成果であるが、 そんなことを利用者は意識しない。 グリッド技術が社会基盤を構成するようになった日には、 その存在を意識することはなくなるのかもしれない。
このように、これまでは主にサイエンスの道具として研究されてきたグリッドだが、 最近、ビジネス分野への適用や、そのための仕様作りが急速に進められている。 そのきっかけは、2002年2月にGlobus ProjectとIBMが共同で発表した OGSA（Open Grid Services Architecture）（コラム参照）である。 OGSAは、Web Services技術を活用してグリッドを構築しようという構想である。 事実上の標準グリッドミドルウェアを提供しているGlobus Projectと 産業界における影響力の大きいIBMによる提案であることから、 大きな注目を浴びている。 また、Web Servicesは、関連仕様の整備や実装が活発に行われている。 そのアクティビティや成果を活用することで、 企業がWeb Services向けに行っている投資や開発努力が、 そのままグリッドでも活きることになる。
グリッドのビジネス応用に取り組む企業の狙いは、 顧客企業のIT資源利用率を高めることである。 例えば、資源の仮想化がなされない場合、ピーク時の使用量に合わせて、 サーバ、ストレージ、ネットワークなどIT資源を調達して、 保有、管理しなければならない。 このため、せっかく調達した資源の利用率が平均的にはたかだか2割、 ということになる。 これをもし完全に最適化できたとすれば、投資は元の2割で済むはずである。 ITベンダとしては、この2割の資源をユーティリティとして従量課金で販売したり、 顧客企業の部署間で融通できるような仮想化機能を付加したIT資源を販売したり、 追加のIT資源の代わりに仮想化機能を提供するソリューションを販売するなどの ビジネスが考えられる。
GGFでは、グリッドのための仕様作成作業や、 そのための議論が活発に行われている。 OGSAの発表以来、産業界からの貢献も増えている。 最近の議論や作業、特にビジネス応用を意識した仕様作りは、 そのほとんどがOGSAを前堤としており、 多くのワーキンググループが、 それぞれの目的に沿ったGridサービスを規定するという作業を行っている。
OGSAはWeb Services関連技術に立脚している。 UDDIこそ使われないものの、OGSAの基本部分である OGSI仕様はWSDL仕様を補うものである。 SOAPは、必須でこそないが、bindingとして標準的に使われていくことは間違いない。
そして、Web Servicesや、それらが前堤としているXMLのための各種ツール、 ソフトウェアは、Java言語を前堤とするものが最も充実している。 例えば、SOAPエンジンとして非常に広く使われているApache Axisは Java言語で記述されており、そのサーバはServletプログラムとして動作する。 また、WSDL形式のサービス記述を扱うAxis付属のツールWSDL2Java、Java2WSDLも Java言語が対象である。
XML/HTMLで表現されるデータを扱い、HTTPで通信を行う サーバサイドアプリケーション、ウェブアプリケーションは、そのほとんどが、 Javaか、または.NET向けのC#などの言語で書かれている。 主流はJavaであろう。 それをホストするアプリケーションサーバも、 J2EEの諸仕様、特にServletとJSPをサポートするものが主流である。 XMLや、ほぼHTTPを前堤とするSOAPはWeb Servicesの重要な要素である。 Web ServicesがやはりJava言語を中心に発展しているのは、ごく自然な流れであろう。
図1: GT3の構成
Web Servicesに立脚するOGSAも、自然と、Java言語を中心に開発が進んでいる。 OGSIは、PythonやC言語版などの開発も行われているが、 Globus Projectが配布しているGT3（Globus Toolkit 3.x）中の OGSI部分は、やはりJava言語で書かれている（図１）。
OGSA、Web Servicesを視野に入れずとも、 Javaはグリッドに向いた性質をいろいろと持っている。 高性能計算、数値計算が目的である計算のグリッドでは、今なお、 C言語のプログラムや既存のパッケージソフトウェア、 つまりネイティブコードを用いた分散処理が一般的であるが、 Javaを用いれば、各計算機に配るのは、単一のプログラムで済む。 これは、Gridサービスを配備する際にも同じことが言える。 また、Java仮想マシンが提供するサンドボックス機能のおかげで、 計算機資源を提供する側は安心してアプリケーションを安全に実行できる。 こうしたJavaの性質は、グリッドの重要な活用法である分散処理にとって、 非常に有用なものである。
スレッドやガーベジコレクションといった言語組み込みの近代的な機能や、 クラスローダによるプログラムの実行時ロードもグリッドに有用な機能である。
現在、SMPといった形で複数のCPUを持つマシンがごく当たり前のものになりつつあり、 アプリケーションやミドルウェアには複数CPUを活用することが求められている。 グリッド向けであればなおさらである。 Javaではスレッドの使い方や挙動が言語自体の仕様としてかなり規定されているため、 OS、ライブラリごとの機能や挙動の違いに不安を抱く必要がない。
また、グリッドのサーバ側プログラムは 数時間から場合によっては数ヵ月に渡る長期間の安定動作が求められる。 このためには、Javaの提供するメモリ管理機能、 すなわち、ガーベジコレクションや、 メモリ上のアドレスを計算の対象にできないという言語仕様が貢献する。
プログラムの実行時ロードは、グリッド以前に、 アプリケーションサーバがアプリケーションをロードするために欠かせない 機能である。 それだけではなく、グリッドの目指す資源の仮想化にも大きく貢献し得る。 Java仮想マシンは、ネットワーク越しに受け取ったソフトウェアを実行時ロードし、 かつ、安全に実行できる。 この機能が、ソフトウェアを容易に、ときに自動的に、 ネットワーク越しに他のコンピュータに配備することを可能とする。 つまり、ソフトウェアという資源が提供する恩恵、効果、つまりサービスを、 特定のコンピュータから切り離し得るということである。 サービスを提供するコンピュータを柔軟かつ容易に変更、増減できれば、 耐故障性や可用性といったQoSの向上を図れる。 また、前述した、IT資源利用率の向上にも応用できるだろう。
OGSAにおいてJavaが重要な位置を占めていることは疑いない事実だが、 Javaのグリッド応用は何もOGSAから始まったわけではない。 OGSA以前から、そして今も、様々な形での応用が試みられている。
例えば、組織をまたいで安全に高性能計算を行うという、 グリッドの一形態を考える。 そこでの並列処理は、最も原始的には、 例えばGlobus ToolkitのAPIを直接利用して遠隔のコンピュータ上に プロセスを起動する、といったプログラミングによって達成できる。 Java CoG Kitというライブラリを利用することで、 JavaからGlobus Toolkitの諸機能を直接利用することが可能である。 しかし、Globus ToolkitのAPIを直接利用することは、繁雑で手間がかかる。 もう少し簡単には、メッセージパッシングや RPC（遠隔手続き呼び出し）を行う並列プログラムを開発するという方法もある。
これをさらに簡単にすることを目的とした グリッドポータルという種類のソフトウェアも、研究、開発されている。 ここで言う「ポータル」とは、Yahooなど、ウェブのポータルと同様に、 ウェブブラウザを用いてアクセスする入口を指す。 つまり、グリッドへの入口である。 グリッドポータルは、資源の種類や量、状況を閲覧したり、 アプリケーションプログラムを起動する機能を提供することが一般的である。
図2: 気象予報グリッドポータル
図3: 広域テストベッドでのグリッド実験
グリッドポータルは、ウェブブラウザを用いてアクセスされるので、 ウェブアプリケーションとして構築される。 図２に、産業技術総合研究所（産総研）で開発された 気象予報グリッドポータルのアーキテクチャを示す。 図３は、このグリッドポータルを用いて実際に行われた広域実験の際の システム構成図である。 ウェブアプリケーションのバックエンドにはたいていデータベースがあるが、 グリッドポータルの場合はデータベースに限らず、そこにグリッドの各種資源、 例えば多数のコンピュータや、観測機器、実験機器などが置かれる。 ウェブアプリケーションとして構築されるということは、 グリッドポータルにもJSPやServletが欠かせないということである。 つまり、Javaが欠かせない。 これもやはり、OGSAの場合と同様に、 HTTP、HTML/XMLなどの上に成り立つウェブ技術において Javaが重要な役割を果たしていることの帰結であろう。
とはいえ、ウェブ技術との親和性だけがJavaを グリッドにおける特別な言語/実行系/技術にしているわけでもない。 ウェブとは直接関係なくとも、Javaを前堤として産み出された、または、 Javaの性質が大きく貢献している諸技術がグリッドに適用される例は多い。 例えば、Javaの発表以来、Javaアプレット、ときにアプリケーションで SETI@homeのような広域分散コンピューティングを行おうという試みが 多数なされている。 その多くは、Javaバイトコードの機種非依存性や、プログラムの実行時ロード、 サンドボックス機構を活用する、Javaならではの取り組みである。
図4: Access Gridの利用シーン(1)
図5: Access Gridの利用シーン(2)
図6: Access Gridの利用シーン(3)
図7: Access Gridの利用シーン(4)
特に機種非依存性に着目し、 LinuxやWindowsなど様々なOSで動作させるために グリッド向けプログラムをJavaで開発する例もある。 例えば、高速ネットワーク越しに、多拠点にまたがる大規模な協働空間を 作り出そうというAccess Gridプロジェクトは、 Access Grid 1.xの開発にJavaを採用した。 図４〜７は、Access Gridを用いた分散ミーティングの様子である。 ここでもJavaが活用されている。
Jiniのグリッド応用も試みられてきた。 すなわち、Jiniの提供する資源の発見機構や、 資源を利用するコードをネットワーク経由で配布、取得する機構を グリッド上の資源に適用しようという試みである。 そこでは、計算を行うコンピュータや、利用したいソフトウェア、ライブラリを ネットワーク上から発見する目的に、Jiniが使われる。
また、最近では、JXTAのグリッド応用も盛んである。 JXTAは、P2Pアプリケーション向けプロトコルとその参照実装、また、 それらを開発しているプロジェクトの名前である。 例えば、グリッド上の資源を売買するための市場を JXTAの広報/発見機構で構築する試みや、 発見機構、ピアグループ機構などを用いて分散処理の枠組みを構築する といった試みが行われている。 Sun社のグループは、耐故障性の高い分散計算の枠組みとしてJNGIを開発している。 また、産総研、筆者らのグループは、PCなどの資源の容易な授受を狙って、 分散処理ミドルウェアP3（Personal Power Plant）を開発している。
これまで述べてきたグリッド応用は、 Javaの、Javaならではの機能や特性をグリッドに適用しようというものである。 一方で、システムソフトウェアやアプリケーション開発のための 数ある言語、言語環境のうちのひとつとして見ても、 Javaには様々な魅力がある。 C/C++言語と比較すると、 アドレスの演算が排除されていることや、配列の境界チェック、 充実したネットワークおよびI/O向け標準ライブラリなどの恩恵によって、 Javaでの開発の方が生産性、開発効率が高いことは疑いないだろう。 こういったJavaの利点を享受するために、 従来はCやC++、FORTRANなどが用いられてきた目的に Javaを適用しようという取り組みも行われている。
例えば、コンピュータの計算能力を絞り尽くすことが至上命題である 高性能計算、数値計算にも、Javaの適用が試みられている。 初期のJava仮想マシンがバイトコードをインタプリタだけで処理していたために、 Javaはインタプリタ言語である、といった誤解は、かつてあった。 しかし、現在のJava仮想マシンは、たいていの場合、 Cプログラムをコンパイルしたものと比較しても遜色のないスループットを発揮する。 Javaプログラムの方が高性能であることも少なくない。 筆者は、Pentium 4プロセッサを搭載したPC上で、 高性能と言われるIntel社製Cコンパイラと Sun社およびIBM社のJava仮想マシンを比較した。 Linpackベンチマーク（連立一次方程式の直接解法）で、 Java版の性能はC版の約9割であった。 もっともこれは、最適化前のベンチマークプログラムであり、 レジスタ、キャッシュなどメモリ階層を考慮する最適化の余地は Cプログラムの方が多く、限界近くまで最適化を行った場合の性能には、 かなり開きが生じるだろう。 とはいえ、Java実装の性能はこれだけ向上してきたということである。
また、最近では、GCCの対応言語として、 C、C++、FORTRAN、Objective-C、Adaに加えてJavaが加わった。 GCCは、LinuxなどのいわゆるPC UNIXで標準的に使われているコンパイラである。 それまでGCCへの+αとして開発されてきたJavaコンパイラGCJが、 晴れてGCCの標準配布の一部となった。 今や、Red Hat Linuxなど、Linuxのディストリビューションをインストールすると、 GCJも標準的にインストールされる。 GCJには、Java 2 SEの標準ライブラリのすべてが揃っているわけではないが、 C/C++の代替としてJava言語を活用しやすくなってきたことは確かである。
Javaバイトコードの機種非依存性、サンドボックス機構によるセキュリティ、 実行時クラスロードといった機構、性質は非常にグリッド向きであるため、 これまで、 Javaをグリッドに適用しようという様々な取り組みがなされてきた。 そして、グリッドにおけるJavaの重要性は、OGSAの発表によって より強固なものとなった。
グリッドというコンセプトが世に出て、およそ5年。 メディアで取り上げられるようになってから1、2年。 そのビジョンはまだ一部が実現されているに過ぎないが、 Javaの成熟やウェブ親和性の向上に後押しされ、 今後、着実に実現されていくだろう。
OGSAは、高性能コンピュータのグリッドで標準的に使われているグリッドミドルウェア Globus Toolkitを開発しているGlobus Projectが、IBMと共同で発表した グリッド構築アーキテクチャである。 発表は、2002年2月にトロントで開催されたGGF4に合わせて行われた。
OGSAの基本的なアイディアは、グリッド上の資源をサービスとしてとらえ、 Web Servicesの各種仕様、実装を活用して、 その上にグリッドのミドルウェアとアプリケーションを構築しようというものである。 Web Services+αであるGrid Servicesとして、様々なサービスを積み上げていく。 まずはFactory、Notificationといったごく基本的なサービスを用意し、 その上にOS的なSecurity、Data Access、Meteringといったサービスを構築、 さらにその上により高級なサービスを構築していくというアーキテクチャである。
産業界で注目され、仕様の整備や実装が急速に進んでいる Web Services関係技術を活用することで、 グリッドのビジネス応用がさらに促進されると見られている。 同時に、Globus Projectとしては、 それまで開発してきたGlobus Toolkit 2.xで複雑、雑多になってしまった 下位プロトコルをGrid Serviceに一本化、整理するという狙いもある。 2.xでは、CPUやOSの種別といった資源情報の管理にはLDAP、 ジョブ管理にはGRAMプロトコルといったように、 目的ごとに様々な通信プロトコルが使われてきた。 2003年6月末にリリースされたGT3（Globus Toolkit 3.x）以降は、 これらプロトコルの多くが、Grid Servicesに置き換えられていく。
OGSA実現への取り組みとして、 まずは、現在のWeb Servicesに欠けているグリッド向けの機能が補充された。 グリッドでは、サービスの先にある資源を明確に意識する必要がある。 そのために策定されたWeb Servicesへの追加仕様が OGSI（Open Grid Services Infrastructure）である。 OGSIは、言ってみれば、Web Servicesを分散オブジェクトに仕立てる仕様である。 OGSI仕様に沿ったWebサービスは、Gridサービスと呼ばれる。
御存じの通り、Web Servicesの基本部分であるSOAPには、 セッション管理の仕様が含まれていない。 OGSIは、そこに、オブジェクトの遠隔参照にあたるGSH（Grid Service Handle）と GSR（Grid Service Reference）や、インスタンス変数にあたる Service Dataを導入している。 WebサービスがRPC（遠隔手続き呼び出し）なら、 Gridサービスは分散オブジェクト、というわけである。
なぜ、Web Servicesが元から分散オブジェクトではなかったのか？という 疑問は自然なものだろう。 現在のOGSI仕様v1.0は、WSDL 1.1への拡張や必須portTypeなどを規定している。 この拡張されたWSDLはGWSDLと呼ばれ、 WSDL 1.1に対しては、具体的には、portTypeの継承とService Dataが付加されている。 これらの拡張は、すでに、WSDLの次期仕様である1.2の草案に追加された。 この先Web Servicesとグリッドは、相互に影響を与えあいながら 成熟していくことだろう。 場合によってはひとつになることも考えられる。
このように、グリッド向け仕様が、 より一般的と見なされている他の仕様に取り込まれていくとすると、 グリッドという名前が付いたものは、段々と、見えない、目立たないものと なっていくだろう。 WSDLの件は、グリッドが、 存在を意識するまでもない、あって当たり前のものとなっていく ことの予兆かもしれない。
GGF（Global Grid Forum）は、 グリッド技術についての議論と標準作成作業を行う、 唯一の世界規模の集まりである。 1999年、米国でGrid Forumが構成され、 6月に第一回目の会合GF1（The 1st Grid Forum Workshop）が開催された。 その後GF5まで開催され、 2000年11月には、eGrid（European Grid Forum）やアジア諸国の活動が加わり、 GGFとなった。 2003年3月には、GGF7がアジア地域で初めて東京で開催された。 10月にはシカゴでGGF9が開催される。
GF1では6、GF2では9だったワーキンググループの数も増え、 現在では7つのエリアに、合計40以上のワーキンググループ（WG）と リサーチグループ（RG）が設置されている。 WGは、あらかじめスケジュールを決めて、仕様や勧告などの文書を作成する。 それに対してRGは、そういった文書化には時機尚早であるテーマについて 情報交換や議論を進める。 各グループのメーリングリストには、2003年初めの時点で2500名以上が登録しており、 その約25%は産業界からの参加だという。 会合は年3回のペースで開催され、最近は700から800名の参加がある。
GGFの組織や文書作成プロセスは、インターネット関係の標準化活動を行っている IETF（The Internet Engineering Task Force）にならっている。 活動の結果産み出される文書の取り扱いプロセスも、IETFにならって策定された。 例えば、IETFでは、仕様の規定、情報提供などを行う重要な文書は RFC（Request for Comments）として認定され、 まだRFCになっていない、または、しない文書はInternet-Draftsと呼ばれる。 GGFではそれぞれ、Grid Forum Documents（GFD's）、Grid Working Drafts（GWD's） と呼ばれる。
日本からの貢献も活発であり、GF2にはすでに、電子技術総合研究所 （2001年、産総研に改組）、 新情報処理開発機構、東工大、早稲田大学などからの参加があった。 現在では、東工大松岡氏、産業技術総合研究所（産総研）の関口氏が Steering Groupのメンバ、 早稲田大学の村岡氏がAdvisory Committeeのメンバを務めている。 また、OGSA-WGでは富士通岸本氏が中心的に活動し、 日立、NECはまた別の観点から、積極的にOGSA周辺に貢献している。 他にも、産総研中田氏はGridRPC-WGのチェアを務め、 産総研建部氏はGrid File System RGの設立提案を行っている。
"Peer-to-Peer"（P2P）は、「グリッド」以上に様々に受け取られている 言葉ではないだろうか。 様々な定義が提案され続けている。 純粋に技術的には、 decentralization（非集中）がP2Pの本質、要件であるという主張が 優勢であるように思われる。 さらに要件を厳しくして、 スケーラビリティ、状況への適応性、自己組織化、耐故障性、 各ノードが持つ機能の対称性などを要件として挙げる流儀もある。 ネットワークと言えば今やウェブ、ウェブと言えばクライアント/サーバ型の関係を 基本とすることから、クライアント/サーバでなければP2Pであるという おおらかな定義をする向きもある。
いずれにせよ、P2Pへの注目は、歴史的には ウェブの隆盛と切り離しては考えられないだろう。 ウェブは、人々の手もとにはウェブブラウザという表示装置だけがあり、 コンテンツなど、重要に思われる何かは、 相対的に数が少ないウェブサーバから頂くという、非対称な関係である。 そこに現れたNapsterやGnutellaに始まるファイル直接交換ツールや、 また、SETI@homeやdistributed.net、GIMPSに代表される PCによる広域分散計算においては、 ウェブでは表示に専念していた手もとの機械が何か重要に思われる 動作を始めたことになる。 P2Pとは、これら、ウェブとは分散のモデルが異なる ネットワークアプリケーションに対して 人々が抱いた新鮮な気持ちではなかっただろうか。
P2Pという認識の出現を社会的なものととらえて、 ウェブが暗黙のうちに規定してきた、人と情報の関係、知識の流れ方を、 P2Pが変える、変えて欲しいと考えている人もいる。 技術には、それとは気づかぬうちに人々の生活スタイルや考え方を変えていく 力や危険性がある。 携帯電話然り、ウェブ然り、である。 このことを踏まえると、P2Pというコンセプト、P2Pシステムが ヒトやその社会を変える可能性も否定できない。
P2Pを技術的に厳密に定義しようとすると、例えば、 SETI@homeでPCは集中サーバとだけ通信するから非集中ではなくP2Pにあらず、 など、議論の紛糾は目に見えている。 最近、2003年6月にIRTF（The Internet Research Task Force）内に立ち上げられた P2P RGのメーリングリストでも、様々な定義が投稿された。 P2P RGの憲章では 「個々のノードが同等の役割を持つような分散アプリケーションを 組織化するひとつの方法」 というくらいの大雑把な定義を与えるにとどめている。
共通の認識がこれだけ緩やかであるにも関わらず、 その"P2P"をキーワードに、人が集まり、 様々な活動が行われていることは興味深い。 2000年10月には、Intel社が主導して多数の企業、参加者が集まり、 P2P Working Group（P2PWG）という団体が作られた。 P2PWGはその後、2002年4月にGGFに合流し、 GGFにはP2Pエリアが新設された。 P2Pエリアには現在、Relation of OGSA/Globus and Peer to Peer（OGSAP2P-RG） とAppliance Aggregation（APPAGG-RG）という2つのRGが設けられている。 元のP2PWGには、例えば、P2Pの障害となる ファイアウォール/NATなど、P2P一般のいくつかの課題についての サブグループがあった。 GGFでは、こうしたP2P一般の話題はOGSAP2P-RGで議論されている。
P2Pとグリッド、両コンセプトの全体をカバーし得るのは、 分散システム、くらい意味の広い言葉であろう。 言ってしまえば、両者の関係を強く意識する人が多いのは、SETI@homeなどの 広域分散計算プロジェクトが、ときにP2Pと呼ばれ、 同時にグリッドと呼ばれるからに他ならない。 厳密な定義、分類は、技術的な議論には欠かせないものではある。 しかしそれでも、P2Pという言葉に技術者を駆る力がある以上、 ラフな共通認識に基づいて前進するのも悪くないのではないか。
