对等网络即将来临了，它承诺要创建一个根本不同的计算世界 — 而且，在某些方面 — 比基于老模式客户机／服务器的要更好。Jxta 工程是按社区方式运作的，旨在为对等应用构建实用应用程序底层。虽然 Jxta 的参考实现是用 Java 语言写的，但事实上它对当今现有的任何语言，操作系统（OS）或平台都会欣然接纳 — 而且，更重要的是，对于人们现在想都没想过的技术，它也做好了准备。在本文，即此系列的第一部分（共 3 部分）中，Java 开发人员兼作者 Sing Li 解释了支持 Jxta 的基本概念和协议，使您为阅读后面的文章做好准备。后面这些文章将教您试验 Jxta shell 并且构建 P2P 应用。请在讨论论坛与作者和其他读者共享您关于本文的心得。
对等（P2P）网络与传统的客户机／服务器或多层服务器网络不同，对等网络中的对等机是彼此直接通信的。这种通信无需依赖集中式服务器或资源就可完成。在 P2P 网络中，通过对等机之间的交互操作就可以完成工作，共享信息。通过创建有潜力展示非常高的可用性和容错能力的计算资源网络，P2P 体系结构使真正的分布式计算成为可能。

传统的客户机／服务器和多层次体系结构已经是业界的识途老马，而采用 P2P 体系结构的系统则还只是初生牛犊。Jxta 工程是 Sun 为了向构建跨平台、跨操作系统（OS）和跨编程语言的 P2P 应用提供实用应用程序底层而发动的突袭。这项工程现在是开放源代码的，Sun 也参与其中，请参阅参考资料部分以获取关于 Jxta 社区的信息。

Jxta 的设计理念
Jxta 工程的组件是认真的设计分工的产物。它们为泛型 P2P 网络提供最小需求，去除了所有特定于策略的逻辑和组件。这样，就仅剩下几乎所有的应用程序都能使用的构件要素，不考虑目标用户和特定实现。在接下来的几个月和几年里，Jxta 核心社区的一个主要任务就是确保这种普遍适用性仍然是真实的。您可以争辩说，P2P 最引人注目的应用程序尚未开发，那么如果 Jxta 把特定于策略或实现的细节嵌入其基础构造层后就完事的话，那么这些尚未想像到的应用程序就可能永远不会和这个平台一起工作。换句话说，Jxta 组件没有强加一些不必要的策略，也没有硬性规定特定的应用操作模型，使得简单地构造 P2P 应用成为可能，也更方便。

Jxta 工程对 Java 平台的独立性
在我们讨论 Jxta 的核心构件的过程中，您会发现我们没有提到任何与 Java 技术相关的东西！Sun 已经为 Jxta 提供了初步的 Java 语言实现，但令人惊讶的是，Jxta 工程既不特定于 Java 编程语言，也不特定于 Java 平台。换句话说，任何人都可以在任何硬件平台上，用任何操作系统、任何编程语言实现基于 Jxta 的网络。添加了这种 Jxta 的传输不可知特性（您将看到，它甚至不依赖于 TCP/IP），您就有了一个准备着交互操作的 P2P 基础构造
在其核心处使用 XML
我们很快将更详细地说明，Jxta 目前使用 XML 作为消息和广告的格式，这对于使 Jxta 具有互操作性很有帮助。因为 XML 技术的简单性和普遍可访问性，软件几乎可以创建在任何平台上以生成并解析 Jxta 消息。

Jxta 核心构件
构成 Jxta 系统的组件与能在很多 P2P 网络实现中识别出来的组件完全一样

• 对等机和对等组
• 服务
• 管道
• 消息
• 广告

对这些组件中的每一个所做的研究将揭示 P2P 通信在 Jxta 网络上是如何工作的。

对等机和对等组
毫无疑问，对等网络是由彼此相互通信的对等机组成的。从根本上说，整个连结着的宇宙就是一个大型 P2P 系统。但由于目前连通性和可用带宽的限制，把整个因特网当作一个巨型 P2P 网络来使用是不切实际的。相反，一些划分是必要的。

物理网络的逻辑划分产生了对等机的工作组，P2P 行话称之为对等组。对等组成员资格的交迭没有任何约束；换句话说，任何对等机有必要属于几个对等组，就可以属于几个对等组。Jxta 规范并没有规定或推荐组织对等组的合适方式。在 Jxta 网络中，对等组就是共享资源和服务的对等机的集合。您可以很容易地明白，如果这个规范把对等组限制为例如局域网 — 或者甚至是广域网的一个子集 — 那么，很多要求组成员资格超出这些物理限制的新应用程序的可能性将一概被排除。与 Jxta 的设计理念一致，对等组被规定为尽可能不受限制、尽可能普遍适应。

请注意，对等组的存在要求一些维护成员资格的手段。Jxta 规范又一次只规定了维护组成员资格的最小需求，而没有指示该怎样维护。这种组成员资格服务只是核心 Jxta 服务的一部分，但它可以接受很多种形式 — 例如，它可以是数据库或目录服务，还可以是基于集中式或分布式实现的。

服务
对等组内的对等机可以共享使用 Jxta 服务。事实上，对等机加入一个组可能主要是为了使用该组内可用的服务。称为核心服务的一组服务对 Jxta 网络的基本运转是必不可少的。我们已经看到了一个核心服务的实例 — 成员资格服务。表 1 展示了 1.0 版 Jxta 规范中包含的核心服务。

表 1. Jxta 服务

服务名称	描述
管道	对等机之间通信的主要方式；为信息传输提供单向、异步的管道的抽象。
成员资格	判断哪个对等机属于哪个对等组；处理对等组内对等机的加入和退出。
访问	一种安全性服务，用于控制对对等组内服务和资源的访问；对等组的一种安全性管理器。
发现	对等机能用来发现对方、其它对等组的存在、管道、服务等等的一种方式。
解析器（Resolver）	允许对等机通过引用（Jxta 行话称之为广告）间接地引用对方，对等组、管道或服务；在运行期间，解析器把引用捆绑到实现上。

Jxta 工程最初的参考实现不提供上面列出的五项之外的任何服务。甚至核心服务中的一些服务，例如处理安全性的访问服务，也只是实现了非常基础的方面。现行的 Jxta 社区正在为这些服务中的大多数充实细节，同时也在定义和实现对对等组或许有益的新服务（一般地或特定地）。例如，该社区目前正在进行的新服务包括：

• 监视和计量服务
• 匿名的、安全的金融交易付款服务
• Web 内容和服务的分布式搜索服务

在 Jxta 1.0 规范中，一个运行中的服务实例总是和一个对等机联系在一起（您可以把它想象成是由一个对等“服务器”主管的）。在一个对等组内，只能有一个服务实例和指定的对等机联系在一起。这种类型的服务被视为对等服务；如果主管该对等服务的对等机当机了，那么将无法获得该服务。另一方面，同一服务的多个实例被冗余地安装在一个对等组内的多个对等机上 — 这被称为对等组服务。对等组服务是 Jxta 网络的高可用性和容错性的关键。Jxta 应用的实现者可以自由地把任意 Jxta 服务作为对等服务或对等组服务进行安装。管道服务，即为对等通信提供逻辑管道抽象的核心 Jxta 服务，常常被作为对等组服务来实现，以确保其总是可用。

管道
正如 Jxta 规范定义，在对等机之间传输数据、文件、信息、代码或多媒体内容的一种方式是通过逻辑管道。Jxta 管道用于在对等机之间发送消息（可带任意内容）。

一个管道实例，从逻辑上讲，是对等组内的一个资源。管道实例的实际实现通常情况下是通过管道服务完成的。与传统（类似 UNIX 的）的系统不同，Jxta 管道是单向的、异步的。需要双向通信的两个对等机将不得不创建两个独立的管道实例。也跟传统机制如 UNIX 管道或 TCP/IP 套接字不同，Jxta 管道的末端可以在不同的时间连接到不同的对等机上，或者根本不连接。在为 P2P 网络上的服务提供冗余实现方面，只此一个单一概念就是革命性的一步。对等机可以在任一点及时逻辑地“拾起”管道。例如，设想一个想使用拼写检查器服务的对等机。它可以连接到一个对等组的拼写检查器管道（该管道是被作为冗余对等组服务实现的）上。在这种情况下，只要至少有一个拼写检查器的实例还在该对等组内的某个地方运行，该对等机就还能得到服务。

Jxta 1.0 规范提供了两种一般类型的管道：点对点和广播（propagate）。

对等机可以使用点对点管道连接到另一个对等机并单向传输消息。对等机可以使用广播管道连接到一个或多个其它对等机并向它们全体传输消息。从本质上讲，点对点管道是一对一的消息传输机制，广播管道则是一对多的消息传输机制。Jxta 社区目前正在多对多消息传输机制方面努力；这个机制已经被命名为 Jxta 导线（wire）。

不管是什么类型的管道，通过管道载送的信息块都称为 Jxta 消息。那么，这些消息的确切格式是什么样子呢？

消息
Jxta 消息是通过管道从一个对等机传送到另一个对等机的数据束。这里，Jxta 规范再一次尽可能地使自己普遍适应，以免不经意间在消息的定义中引入任何依赖于实现的策略。消息被定义为由信封和正文组成的任意大小的束。信封是标准格式，它包括：

• 报头
• 源端点信息（URI 格式）
• 目的地端点信息（URI 格式）
• 消息摘要（可选的 — 出于安全性目的）

消息正文的长度是任意的，可以包含一个可选的信任状（出于安全性目的）和内容。

请注意，Jxta 消息的定义非常松散。考虑到我们日常一般都是在可靠的、宽带的 TCP/IP 网络上操作，这样做的必要性并不是立即可以明了的。但 Jxta 消息的格式必须是灵活的、善于适应新环境的，因为它可能要在所有种类的网络上实现，而不只是在 TCP/IP 上。设想在一个支持 256 字节数据包的不可靠传输的网络（象传统的基于数据包的无线网络）上的一个 Jxta 实现，您就会对 Jxta 消息的简单定义如何使自己适应诸如这样的不利环境表示赞赏。

为了提供一个标准的、语法上易分析的、通用的编码机制，Jxta 消息目前采用 XML 文档格式。Jxta 利用了 XML 的普遍可访问性和易使用、易编程的特点，这意味着 Jxta 可以用大多数编程语言在大多数平台上很容易地实现 — 只要 XML 语法分析器和生成库在那里是可用的。然而，Jxta 本身的设计却使其消息代码的编写不依赖于 XML 的使用。虽然现在不太可能，但 Jxta 社区在规范的未来版本中包含（或要求）基于非 XML 的消息是完全可能的。

广告
广告有点像是消息的“堂兄弟”。Jxta 广告也采用 XML 文档格式。广告的内容描述了诸如对等机、对等组、管道或服务等 Jxta 组件实例的属性。例如，可以访问另一个对等机的广告的对等机可以设法直接连到该对等机上；可以访问一个对等组的广告的对等机可以通过广告加入对等组。目前的因特网中与广告相似的东西是域名和 Web 站点的 DNS 纪录。Jxta 规范没有规定如何创建、传播或销毁广告。

互操作性的基础：Jxta 协议
互操作性的另一个关键是这样一个事实：核心 Jxta 对等交互操作模型被完全表示为在底层网络上传输的一套简单协议。换句话说，既然协议和消息格式是定义完好的，那么基于 Jxta 的系统间的互操作性完全可以在导线一级上达到。

例如，一个简单的 PDA（8 位处理器，基于 C 语言编程）就可以是一个运行在基于数据包的无线网络上的 Jxta 对等机，它可与同一对等组内的各种系统，从 PC 服务器到大型机，进行交互。如果这些对等机共享一个公共网络（传送）并正使用 Jxta 协议和消息格式进行通信，这是可以做到的。

Sun 已为 Jxta 提供了初步的 Java 语言实现。Jxta 社区现在拥有这个参考实现。这个参考实现为那些想立刻使用 Jxta 的 Java 程序员把事情变简单了。而如果您正在非 Java 平台上实现 Jxta，那么理解这些协议就是非常重要的。表 2 简要描述了 Jxta 协议的核心集，涵盖了发现（对等机如何找到对方）、广告（对等机如何让别的对等机了解对等组、管道等信息）、通过管道进行的通信和对等组成员资格的处理。下面的所有协议都是建立在传送器上的 XML 消息交换的基础上的。同样地，它们可以用几乎所有的编程语言在几乎所有平台上实现。

表 2. Jxta 核心协议

协议名称	描述
对等发现协议	用来发现来自对等组内其它对等机的广告；有助于发现对等机、对等组、管道和服务。
对等解析器协议	对等机用它来向另一个对等机发送搜索查询以定位对等机、对等组、服务或管道。
对等成员资格协议	对等机用它来加入或退出一个对等组。
对等信息协议	对等机用它来获得别的对等机的状态。
管道绑定协议	对等机用它来把自己绑定到管道端点。
端点路由协议	对等机用它来请求有关到另一对等机的路由信息。

Jxta 规范不要求对等机实现上述所有协议。任一特定的对等机只须实现那些实际要用到的协议。

基于 Jxta 的系统的一些有趣的属性
既然您已经对 Jxta 平台理论上的构件有了一个基本理解，我们就来讨论一下作为 Jxta 设计结果的一些有趣的属性。

有“电子心跳”的任何东西都可以成为一个 Jxta 对等机
从理论上说，有文本字符串生成能力的最简设备都可以加入（虽然并不是在每个 P2P 应用中都有必要）到 Jxta 网络中。这是怎么成为可能的呢？

在 P2P 网络上，过分简化的设备需要对等代理人。这个代理人可以代表该简化设备（或多个简化设备）执行发现、广告和通信。代理人的位置可以被硬性固定在简化设备。这样，在代理人的帮助下，简化设备就可以成为 Jxta 网络上完全合格的对等机。例如，一个被绑在一只海龟身上并以无线方式发送出带有位置信息的 Jxta 消息的 GPS 定位器，就可以成为 Jxta 网络上的一个对等机。

不确定拓扑结构的网络中的顺序
典型 Jxta 网络另一个迷人的方面是它固有的不确定的拓扑／响应结构。计算机用户通常都习惯于本质上确定的、同步的计算机系统，并认为这是一种标准结构。例如，当我们的浏览器发出 Web 页面的 一个 URL 请求时，我们期望输出立刻就会出现。我们还期望世界上的每个人都可以使用同一个 URL 从同一个 Web 服务器检索同一个页面。

在 Jxta 世界里，一个特定的资源请求不会在几分钟、几小时或甚至几天内返回；事实上，它可能根本就不会返回。另外，请求同一资源的世界各地的人们很可能得到的是来自完全不同的服务器的资源副本。这就引起了一个问题：不确定性系统有什么好处呢？

来自 grassroots 软件革命的灵感
我们只要看看象 Napster 和 Gnutella 这样的流行 P2P 系统就可以找到答案。下面是它们的一些额外的优势特征（它们使同步性和确定性的丧失变得值得）：

• 内容的高可用性。 对等机可以从多个服务器上获取内容，理想情况下可从附近开机运行着的一台服务器上获得。原始源对等机不必为每一个资源请求服务；事实上，它甚至可以不开机运行。
  
  
• 网络带宽的最优化使用。 现今 Web 上典型的局部流量集中导致的拥塞不会影响 P2P 网络。
  
  
• 更低的内容分发成本。 P2P 网络能吸纳内容并复制它以使它易于存取。
  
  
• 来自网络中各个节点的计算能力的均衡。 通过异步操作，您可以同时发出许多资源或服务请求，然后让网络为您完成这些工作。
  
  
• 无限的可伸缩性。 一个设计良好的 P2P 应用可以在不影响可伸缩性限制的情况下横越整个已知的连接着的宇宙；而这在任何集中式模式中是完全不可能的。

在完美的 Jxta 世界中，我们将在不确定性网络上执行异步请求。您觉得这个概念古怪吗？

让我们用一个示例来阐明。设想一个在基于 Jxta 的 P2P 网络上运行的基于网络的音乐请求服务。对等机提交了几个对音乐文件的请求并在一段时间后核查对等组中的音乐请求服务是否找到了这些文件。当我们在一段时间后去核查音乐请求服务时，所请求的一些文件已经被找到，但其它的却无法定位。服务对那些文件的响应是：音乐的选择和可用性在不断地变化；请稍后重试您的请求。这是一个可接受的不确定的结果：虽然服务未能找到一个文件，但如果我们稍后再次提交同一个请求，那个文件或许就是可用的了，因为主管我们想要的那个文件的对等机这时或许在线了。

当放到这样一个具体的上下文中的时候，不确定性网络的概念看起来就不再那么陌生了。事实上，我们多数人大概都会接受并使用这样一个音乐请求服务。我们中的一些人甚至愿意为这样的自动代理支付一点费用，这种代理会持续监视所选文件的可用性，然后为我们取来并存储它们的副本。这是 P2P 计算的巨大魅力之一：均衡并共享全世界的所有连接着的资源的能力 — 但愿是以有秩序的和文明的方式。

该讲的都讲完了，但最先几个在商业上取得突破的 Jxta/P2P 应用大概还是会因把确定性和同步性作为它们的主要特征而引以为豪。这是一个必要的过渡，因为用户的习惯和市场取向不会在一夜之间改变 — 如果没有强制原因的话将来不会改变。新的 P2P 模型将慢慢地浮现，起先可能会是以混合的形式出现。一个当前示例：基于边缘传播（edge-propagation-based）的网络高速缓存技术，比如 Akamai，是目前确定性的、集中式的 Web 上的规范。这些技术用 P2P 风格的概念在集中式服务器的世界里实现优化的内容传送。

社会影响和棘手的知识产权问题
我们先前使用的短语 — 有秩序的和文明的 — 是前沿计算和当代社会学的交汇处。事实上，短语“有秩序的和文明的”在不同的文化圈里可有不同的解释，或者甚至在单个文化圈的不同环境中也有不同解释。这已经在版权敏感的知识产权（IP）管理的世界里引起了激烈的争议和辩论。由于有关集团的优势以及内容分发上根深蒂固的市场惯例，这一争论不会很快平息。

在大众和商业新闻中已经写了很多。Sun 不在其 Jxta 实现中规定策略的决定使得它可以自由地前进并扫除了这些争论 — 把责任放在了那些在内容分发上率先采用 Jxta 技术的先锋们的肩上。然而，在这个舞台上， Jxta 技术基于社区的发展使它有潜力全局控制 IP（知识产权）所有者和公众之间的良好平衡。开放的 Jxta 社区可以作为一个论坛，IP（知识产权）所有者和技术专家可在此论坛解决它们之间的分歧。

透视 Jxta：它如何与 .Net 和 Jini 较量
自从 Jxta 被介绍后，它已经被拿来和每个可想象得到的网络技术进行比较。即使是有名望的商业杂志也不经意地忽略了这一创新，因为它显然不和主要竞争对手大肆宣传的旗舰产品较量。Jxta 工程是一只独一无二“怪兽” — 在讨论它的时候不会有任何现成的参照物。因此，必须独立地对它进行评价。

要确信，Jxta 基于 XML 的消息传递与微软（Microsoft）的 .Net 和 SOAP 技术是类似的。但这种比较的基础比较薄弱。随着越来越多的第三方协议使用了 XML，很显然只用 XML 作为消息格式对于实际的网络技术并不能说明什么。把高级别的、策略丰富的、基础构造基于 Web 服务的 .Net 与本质上低级别的、基本的、策略中立的 Jxta 相比是件毫无意义的事。

Jxta 工程和 Jini 工程也是根本不同的。它们俩在较高级别的交互作用方面有一些类似的地方，都能够实现网络上真正的分布式计算。然而，类似处也在那里嘎然而止。因为真正的分布式计算仍只是未来的一个设想，所以很容易低估 Jxta 和 Jini 工程之间的区别 — 尽管事实是我们在比较更多已建立的客户机／服务器或多层服务器技术的实现时不会做同样的事。

两者在战略上的明显不同是：Jxta 在一开始就是以完全互操作性技术（任何平台，任何编程语言，任何厂商）的面貌出现的。Sun 是唯一投身于该社区的公司。Jini 是以 Java 为中心的技术，作为一种战略，Sun 将把它集成并应用在将来提供的产品中。Sun 将对 Jini 的发展保持一定程度的控制。

没有 Java 平台（代码的灵活性，RMI 等等）的支持，Jini 的实用性将受到限制；另一方面，Jxta 则完全独立于 Java 的装饰。从另一个角度看：Sun 仅仅定位在促进 Jxta 的成长，而 Sun 和 Jini 的成长之间则是有着较多的利害关系。随着时间的推移，Jini 将成为 Jxta 的“愈发内向的堂兄弟”；它将作为启用的嵌入技术被应用、部署到许多产品中。Jxta 的命运，在另一方面，将取决于参与此项技术的开放社区的成员们的热情和创造力。

Jxta 的多功能性
由于提供基础机制而不规定策略，Jxta 基础对于很多 P2P 应用都是可用的和有价值的。下面是另外三个普通的个案研究：

• 对等机上的用户搜索并共享对等组内的文件、信息和内容
• 对等机加入到对等组以使用只在此特定对等组内才可用的特定服务
• 对等组内对等机间以及通过网关穿越对等组的即时消息传递系统

当然，可能的应用是无穷无尽的，其中的很多还有待开发或甚至有待构思。在后面的文章中，我们将安装 Jxta 并试验它的命令行 shell，创建该 shell 的定制扩展，为 Jxta 网络设计 P2P 应用。


Jxta：名称中包含什么意义？
Jxta 不只是以字母 J 开头代表 Java 和 Jini 名称的、由四个首字母组成的首字母缩写词。事实上，它代表 Juxtapose 工程。 Juxtapose 漂亮而优美地描绘了未来完整的 P2P 计算世界。据我们所知，企业内部网（intranet）或因特网（Internet）中现有的客户机／服务器计算永远不会消失或被取代。相反，Jxta 技术将作为一种补充，与这些技术共存（因此是 juxtaposition 并列）并给最终用户带来超值体验。因特网和企业内部网的用户将能够从网络的这两种形式中获益。

关于 Jxta 标识符
从潜力上讲，对等组或许可以跟整个联系着的宇宙一样大。在这么大的名称空间中为任何事物进行唯一的命名都是一个挑战。为了应对这个问题，Jxta 给 Jxta 组件的每个可设定地址的实例都分配了一个内部标识符。这种标识是通过一个 UUID 进行的，UUID 是使用能够确保在时间和空间上都有很高概率的唯一性的算法产生的 64 字节的数字。Jxta 标识符是 URN（统一资源名称）格式的，并被嵌入到广告中供内部使用。目前定义了四种标识符类型，用于标识对等组、对等机、管道和代码／数据（code/data）（简写为 codat）。

参考资料

• 参加本文的讨论论坛。
• 官方的 Jxta 社区位于 Jxta.org。您可在这里找到最新的规范、文档、源代码和二进制文件。
• 如果您对了解基于 Jini 的技术的更多详细信息有兴趣，请查阅 Sing Li 写的 Professional Jini。
• 另一个早期采纳者的对等工作组已经建成。这个组的战略会是什么，它与 Jxta 的关系又会是什么，这一点还不清楚。
• Todd Sundsted 写的 developerWorks 每月专栏 — 对等计算的实际应用，提供了关于 P2P 概念的抽象观点和用他自己的 P2P 应用框架进行的实用的学习经验。
• 要了解一个可与之替换的开放源代码的系统，请查看 Freenet 工程。
• 来自 IBM 的高级对等网络（APPN）提供了强伸缩性、高可用性、安全的网络解决方案。
• IBM 的 Magstar 对等虚拟磁带服务器被设计用来提高数据的可用性及改善您的灾难恢复基础构造。
• 在 developerWorks Java 技术专区查找更多 Java 参考资料。