把P2P进行到底：讲述Jxta的故事(2)

　　在 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 标识符从潜力上讲，对等组或许可以跟整个联系着的宇宙一样大。在这么大的名称空间中为任何事物进行唯一的命名都是一个挑战。为了应对这个问题，Jxta 给 Jxta 组件的每个可设定地址的实例都分配了一个内部标识符。这种标识是通过一个 UUID 进行的，UUID 是使用能够确保在时间和空间上都有很高概率的唯一性的算法产生的 64 字节的数字。Jxta 标识符是 URN（统一资源名称）格式的，并被嵌入到广告中供内部使用。目前定义了四种标识符类型，用于标识对等组、对等机、管道和代码／数据（code/data）（简写为 codat）。
　　
　　广告
　　广告有点像是消息的“堂兄弟”。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 网络上运行的基于网络的音乐请求服务。对等机提交了几个对音乐文件的请求并在一段时间后核查对等组中的音乐请求服务是否找到了这些文件。当我们在一段时间后去核查音乐请求服务时，所请求的一些文件已经被找到，但其它的却无法定位。服务对那些文件的响应是：音乐的选择和可用性在不断地变化；请稍后重试您的请求。这是一个可接受的不确定的结果：虽然服务未能找到一个文件