而反观升阳的 Java 阵营，正努力的推动 JXTA 计划，用来定义一个建立分布式服务与应用的共同平台，目的在使应用程序开发者能够更专注于应用程序本身逻辑的开发，同时给予快速建立 P2P 分布式计算软件的能力。

P2P 的应用

那么，什么是 P2P 应用呢？其实我们都可以理解到，不论是何种应用程序，大都会有一个共同的要点，那就是数据传输。当程序与程序之间能够透过某种管道进行资源的分享与交换时，应用程序的价值便大大地提高。

目前最常见的网络通讯模式为主从式的运算模型（ client-server model ），客户端知道如何对伺服端发出请求，而伺服端也知道如何对客户端做出回应。而目前我们最常见的主从式运算模型，就是 Web 浏览器与 Web 服务器之间的沟通。这种沟通模式，是由许多个浏览器送出存取请求至 Web 服务器，而 Web 服务器的工作则是持续的等待外界所传入的请求，同时对这些请求送出相关数据当做响应。在这样的模型中，Web 服务器并不能与浏览器主动接触，也就是说，所有的沟通对话，都是由客户端开始发生。相对来说，一个 P2P 的应用程序就不是以传统主从式的模型来运作，而是每个端点（ peer ）都会同时具有客户端与服务器两种角色。也就是说，在某端点对外送出请求的同时，它也具备了响应其它端点请求的能力。通常一个典型的 P2P 应用程序会有以下几个重要的特色。

1.搜寻/发觉其他端点的能力（ Discovery ）

P2P 端点必须要有能力找到其他愿意分享信息的端点。以往这样的工作都是由向中央服务器登记与存取上线端点的数据所完成（如 ICQ 等），但这并不是唯一的方式。仍有许多网络上广播（ broadcasting ）与发觉（ discovery ）算法可以完成相同功能的运作。

2.查询其他端点的数据内容（ Query ）

一旦找到其他端点之后，（ P2P ）应用程序便可以对它发出查询数据内容（ content ）的请求。在此同时，P2P 应用程序也常会自动发出其他网络请求，以便利程序自身的运作需求。

3.与其它端点共享数据内容（ Sharing ）

如前所述，P2P 应用程序也可以具有伺服功能，因此它也可以与其他端点分享数据内容。

P2P 的运作模式

接下来，我们就来探讨一下，在这几种不同的 P2P 运作模式下，各会有什么样的特色。目前常见的 P2P 运作模型有四类，分别是纯粹的「点对点模式」，具有发觉功能服务器的模式，具有发觉与查询功能服务器的模式，以及具有「发觉」、「查询」以及「数据内容功能服务器」的模式。以下就是这四种模式的简要介绍：

1.纯粹的点对点模式（ Pure P2P model ）

所谓纯粹的 P2P 模式，就是动态地去寻找网络上的其他端点。同时也动态地分享与交换各自所拥有的数据内容，如（图一）所示。这种模式的好处，是在于这样的运作组合并不需要仰赖任何的服务器，而这类服务器的用途是在于登录同类型的端点。但是这种模式也有其缺点，就是在缺乏集中式服务器管理的情形下，能够寻找到的其他端点数目会相对较少，因此限制了应用程序所能够延展的存取范围。在这样的状况中，端点可以透过自身默认的组态或是透过网络广播的方式来和其他端点取得联系。

《图一 纯粹的点对点运作模式》

2.具有发觉功能服务器的模式（ P2P with Simple Discovery Server ）

在这种模式下，所有发觉端点的动作，都是透过一个集中式的服务器所提供的查询服务来完成，如（图二）所示。在这种模式下，P2P 应用程序会在初始化时通知服务器自己已经存在的讯息，以方便其他端点的寻找与发觉。而最后数据内容的下载则是经由两方端点的沟通，并不牵涉到集中式的服务器。在大多数的状况下，这种运作组合会有较好的扩充规模。但其限制是在于集中式服务器的数量与取得难度。此外，由于这种模式可以让两个距离甚远的端点取得连系。因此远距离网络传输负担将会是影响质量的重要因素。

《图二 具有发觉功能服务器的运作模式》

3.发觉与查询功能服务器的模式（ P2P with Discovery and Lookup Server ）

这种模式和上一个模式相当类似，只是集中式服务器将会多了一项任务，也就是数据内容的查询服务。在这种情形下，P2P应用程序不止是要将自己登录在集中式的服务器上，同时也会定期上载自身所欲分享的数据内容相关信息。

当有某个端点希望寻找某种数据内容时，它就会对集中式服务器发出查询的请求，接着才会依据查询结果来与真正提供的端点做连系沟通。一般而言，这种模式会比上一种模式还要具有扩充性，因为集中式的查询可以明显减少网络上所会出现的查询请求数量。当然了，这样省下的网络负担代价，自然就会转嫁到集中式的服务器上。

4.发觉、查询以及数据内容功能服务器的模式（ P2P with Discovery, Lookup, and Content Server ）

这种模式下各个端点将会把自己所欲分享的数据内容，在初始化时上载到服务器上，请参考（图三）。这种做法就是一种演化成主从式模型的运作方式。每个端点不论是在登录工作、数据查询、以及数据内容的存取上，都会与集中式服务器做连系。而且「只」与服务器联系。这种做法的问题是在于一旦 P2P 应用程序将自己的数据内容上载之后。服务器马上就成了容易产生瓶颈的所在。因此，将 P2P 模式转成主从式运作模型，将是 P2P 美意上的一种浪费。

《图三 发觉、查询以及数据内容功能服务器的模式》

在介绍完各种 P2P 运作模式之后，我们将探讨微软与升阳两大阵营。在这两大阵营所设计的应用伺服架构下，又该如何对 P2P 这样的运作模式，给予基本技术上的支持。

微软的 P2P 支持方案

由于微软所推广的是其引以为傲的 .NET 架构，因此，在 P2P 应用的设计上，.NET 也提供了许多开发上的选择。请注意，程序开发者在设计 P2P 应用时所做的决策，将会大大影响其用户所会付出的网络运算代价。在 .NET 架构下，设计 P2P 应用将会有四种应用型态可供选择，以下我们就逐一的检视这些型态。

1.Web 服务型态（ Web Services ）

这是在.NET架构中System.Web.Services 层次下的定义的型态。在这种型态下，举凡是登录、发觉、以及数据内容的服务，.NET 都提供了良好的支持。其中所定义的 Web 服务，让开发者可以轻易地建立起具有等待请求、处理请求、以及送回标的数据对象的 P2P 应用。

2.Windows Forms 型态

这是在.NET 架构中 System.WinForms 层次下所定义的型态。在 .NET 架构中，Windows Forms 提供了一组丰富的图型用户接口组件，这些组件可以让 P2P 应用的互动性更加丰富与有趣。因此很适合用在几种处理步骤上：用户登入、请求发送、以及数据内容的分享等等。

3.Web Forms 型态

这是在.NET架构中 System.Web 层次下所定义的型态。这种型态所支持的，是提供简便的方法来产生 HTML 内容，用以回传到 P2P 应用上。当 P2P 应用初始化的同时，不但可以登记自身所愿意提供的 Web 服务，同时也可以取出集中式服务器中最新的 HTML 数据。

4.Service Process 型态

这是在.NET架构中System.ServiceProcess 层次下所定义的型态。这里所谓的 service，其实指的就是 Windows NT 中的 service，是一种长驻形式的程序。Service 对于 P2P 模式中的发觉服务器而言相当有用，因为它是一个需要提供长期服务的部份。

除了提供丰富应用型态之外，.NET 架构也大幅地简化了 P2P 应用中所需的网络运作。其中包括 System.Web.Service 以及 System.Net 两个部份。因此笔者就针对这两个部分来做介绍。

System.Web.Service 层次

在 System.Web.Service 层次下的对象类别，主要是用来开发提供以及使用 Web 服务之用。而所谓 .NET 架构下的 Web 服务，就是一种建构在 SOAP（ Simple Object Access Protocol ）协议上的应用程序逻辑。SOAP 是由 W3C 的定义用来编译及传输数据的重要协议，其中利用了 XML 为数据描述的标准，而以 HTTP 为底层的传输媒介。对使用这种 Web 服务的客户端来说，并不需要对该服务所在的平台、对象模型、甚至所使用的程序语言有所认识，而只需要知道如何发送以及接收 SOAP 讯息即可，而在 .NET 架构下，建立一个 Web 服务就如同在服务器上建立一个网页对象类别般简单。同样地 P2P 应用程序使用 Web 服务也相当地简单，只需要呼叫一个由 Visual Studio.NET 产生的对象类别中的方法即可。至于其他的技术细节，请另行参考 .NET 平台 SDK 的技术文件。在说明了如何去开发 Web 服务的同时，将可提供外界呼叫的接口（ API ）并公开登录给 P2P 应用程序查询的情形。

在此情形下，主从式模型及 P2P 模型是以混合存在的状态出现。使用这样的混合模式有一种好处，它可以反映出主从式模型的单纯，同时又可以展现出 P2P 运算的强大。

在建立 Web 服务的步骤上，你必须先了解一个叫做 P2PService 的重要类别。这个类别定义了你可以用来呼叫使用 Web服务的方法。而除了建构的方法之外，其他的类别方法请参见（表二）。除了P2Pservice 类别之外，另外有一个PeerFile 类别，是用来储存 P2P 运算模型中有关档案的相关讯息。PeerFile 包含了以下的类别成员：IpAddress，代表了端点的 IP 位置；Name，代表了档案的名称；Connection，代表了端点链接的型态以及速度；Size，代表档案的大小。

System.Net 层次

在 System.Net 层次下的对象类别，主要是用来支持使用各种网络协议收发数据之用。由于是使用层级式的做法，使得应用程序的开发可以自由选择所需要的层级，包括从最细小的 socket 控制到最大范围的请求/响应模型，反映出了目前因特网上各式常用的通讯方法与协议。

此外，System .NET 下的类别，也可以随着因特网的改进而做有弹性的延伸。第一种类别方法，称为ListenForPeers。这个方法会让 P2P 应用程序进入等待请求到达的模式中，以响应任何一个端点所送达的请求。而当其他端点链接上之后，就会开始处理所欲取用的文件名，并回传之，这便是它最主要的程序功能，而由于程序是以多线程（ multi-thread ）的模式运作，所以当 P2P应用程序正在处理某个端点的请求时，仍然可以接受外界其他端点的链接请求。

另一种类别方法，称为DownloadToClient。这个方法就是用来连接其他端点并要求取用档案资源的部份。除了以上所提到的档案分享功能之外，P2P应用程序也可以用来当做 Web 浏览的工具，也就是说，成为一种提供 HTML 内容的支持技术。在 System.NET 下所定义的WebRequest 以及 WebResponse 两种类别，分别用来构成 Web 服务器的主要功能。

至于在扩充性部分的问题上，不同的P2P 设计也会产生相当不同的影响。一般而言，影响 P2P 最巨的因素，便是网络带宽的多寡，同时这也是 P2P 运作最容易发生瓶颈的所在。因此，如何小心设计搜寻/发觉其他端点以及查询其他端点数据内容的方法，将可以大大左右 P2P 共同运作的最大数量，这也是目前在 P2P 技术方面亟待讨论的课题。

在看完微软在 .NET 架构下对 P2P 应用的支持之后，接下来我们就来看看另一个阵营－也就是升阳的 Java 阵营，在 P2P 应用模式的设计上，到底提供了什么样的支持技术。

升阳的 P2P 支持方案

升阳公司一直在因特网方面，是最为积极的技术参与者之一。有鉴于 P2P 应用，可以造就更大规模的协同运作与通讯。升阳早就着手设计新一代的技术标准。由于 P2P 的运算模型，可以有效地运用并平衡各项网络资源（如计算效能、储存空间、传输带宽等等）。因此其价值自然不容忽视。

而 P2P 是由主从式模型所延伸发展( juxtaposed )而来，因此升阳在 P2P 方面的项目计划就简称为 JXTA。在 JXTA 中，升阳定义了一个开发并使用分布式服务的基础平台，其中加入运作的任何一个单位，都会被视为一个端点。而 JXTA 的目的，就是试图去提供一个完整的 P2P 运作支持，使得系统开发者可以更专注于应用程序逻辑的设计上。

在 JXTA 中，定义了一个为 P2P 模型所设计的开放式网络运算平台，而在 JXTA平台下，有下列几项端点所应具备的功能，可被标准化：如「发觉其他端点」、「公布自有资源」、「端点间的通讯」、「协同运作」等，这些功能可共同构成一个具有安全特性的群组。

升阳 JXTA 计划的基本网络服务

目前大多的 P2P 系统都是设计用来提供特定的网络服务（如 Napster 用来分享音乐，Gnutella 用来分享一般档案，而ATM 则是用来传输即时消息）。由于网络服务具有多样性，同时又缺乏一个共通的基础架构。因此各家 P2P 的厂商所建立的，都是无法兼容的 P2P 技术。也就因为如此，JXTA 便试图提出一个简单的 P2P 平台概念，用以提供具共通性的基本网络服务，特点如下：

1.JXTA 使用了少数的通讯协议，并且这些协议都很容易实作并整合进 P2P 的服务应用之中。因此据此开发系统的厂商，将有能力与其他厂商的应用程序做沟通。

2.JXTA 具有与程序语言无关的特性，因此它可以用许多不同的程序语言来进行实作，如 C/C++、Java、Perl 等等。也就因为如此，许多异质性的网络设备及其软件，便得以使用 JXTA 来进行沟通。

3.JXTA 具有与传输协议无关的特性，因此它可以建构在许多不同的传输协议之上。如TCP/IP、HTTP、蓝芽（ Bluetooth ）等等。这也意味着具有JXTA 功能的系统可以拥有扩展为使用新式网络环境或设备的能力。

升阳 JXTA 计划的优点

至于在使用 JXTA 的优点上，我们可以由几个典型的范例看出。假设目前有一个应用 P2P 的社群，其中社群成员会使用到搜寻的机制。在这种情形下，任何一个社群成员可以应用 P2P 技术，来发出查询的请求给其他有能力处理这项请求的社群成员。

我们再假设这是一个社群成员想要透过 Gnutella 系统找寻某个特定的 mp3 档案。因此，其他可提供 Gnutella 服务的端点都会各自查阅自己所可以分享的档案并响应之。因此，以 JXTA 最具一般性的运作模式来看，只要是能够提供符合Guntella 系统协议的 P2P 应用程序，都将可以提供服务。相对地，这样的 P2P 应用也不只是可以提供 Gnutella 服务，更可以提供其他不同的 P2P 应用服务。总而言之，JXTA 的设计目的之一，就是希望能够成为不同 P2P 系统之间的链接桥梁。

第二个例子我们假设的是「储存媒体」的问题。假设一个工程部门中的团队成员，需要一个具有弹性的储存形式来存放共有的设计数据。由于需要较具安全性的存放方式，因此会需要重复储存进而避免数据漏失。在这种情形下，最为常见的解决方式，就是添购一部高容量且具有数据镜像备份（ mirror ）的磁盘阵列系统。接着可能也会有另一个工程部门的团对也添置了这样的设备。这样一来，两个部门团队可能都付出了较为高昂的代价，但是却无法充分利用另一团对所闲置的磁盘空间。在这种情形下，使用 JXTA 技术，将可以避免购置昂贵的系统，同时又可以不需应用标准的镜像备份方式，而改为利用其他端点的闲置空间，来进行数据的备份。

升阳 JXTA 的运作层次

在 JXTA 所规划的层次方面，目前分为三层请参见（图四），分别是核心层次、服务层次、以及应用层次，分述如下：

《图四 JXTA运作模型所规划的层次》

1.核心层次（ core ）

这个层次仅涵盖了最基本的 P2P 应用网络元素。包括端点的定义、端点群组、端点的寻找，端点间的通讯、端点的监控、以及最基本的安全性制等等。这个层次是所有型态 P2P 应用都会共同使用的部分，也就因为如此，不同 P2P 应用之间的沟通与合作才有可能。

2.服务层次（ services ）

这个层次包含了许多常用、有用，但是并非绝对必要的网络服务，如搜寻、索引、目录功能、储存功能、档案分享、分布式文件系统、资源共享、协议转换、授权等等。

3.应用层次（ applications ）

这个层次包含了 P2P 的即时消息传递、数据内容管理与传送、P2P 邮件收发、分布式的竞价系统等等。

至于在「通讯协议」方面，JXTA 一共定出了六种网络协议，而在 P2P 应用程序部分，只需要实作出自身所需的协议即可，请参见（表三）的说明。

(注：所有的协议都是使用已 XML 为基础的讯息格式。)