随着移动计算的普及和嵌入式可联网微处理器的无处不在的应用，TCP/IP 终于显露出它已经显得过时。设计 Jxta 的初衷就是要突破当今基于 TCP/IP 的网络的限制，从而扩展因特网所能触及的范围。在 developerWorks 的讨论 Jxta 的系列的这最后一篇文章中，Sing Li 举例说明了体现这种扩展的系统，并解决了一个实际问题。您将看到 Jxta 不受客户机／服务器网络的典型约束的限制。请单击本文顶部或底部的讨论，在讨论论坛与作者及其他读者共享关于本文的心得。
到本系列文章的这里为止，我们仔细考察了 Jxta，一个 Java 参考实现的新 P2P 平台，是如何工作的。在第一部分中，我们了解了 Jxta 的互操作特征。Jxta 被定义为一组互操作协议，可以跨硬件平台、操作系统和编程语言实现。我们也讨论了 Jxta 的操作模型和包括对等机、对等组、服务和管道在内的许多重要概念。在第二部分中，我们的着眼点是建立和运行 Jxta。我们探讨了一个 Jxta 应用程序 ― Jxta shell ― 并经历了创建管道并从一个对等机发送消息到另一个对等机的情形。在我们编写 Jxta shell 扩展时，我们第一次获得了用 Jxta API 编程的经验。迄今为止，我们讨论 Jxta 的方式都是从下到上的。对于像我们这样具有系统编程和网络工程背景的人来说，这是再自然不过的。
在本系列的这第三篇也即最后一篇文章中，我们要把事情颠倒过来。从那些从事应用级设计和体系结构的人的角度来说，本文是自上而下看待 Jxta 的。我们从一个特定的示例问题开始，对这个问题进行分析并设计出一个解决方案，从而展示 Jxta 是如何自然地解决该问题的。
随着本文的进行，我们讨论 Jxta 如何通过并列（juxtaposition）改变联网的前景展望，我们还提供一个 Jxta 服务和客户机的设计和代码。
解决一个分布式数据收集问题
设想一下我们需要创建一个大规模的气象数据收集和分析系统。在这个系统中，我们有数百个气象数据收集点；每个收集点配备一个微型气象站，这些气象站将当前温度（和其它大气状态）提供给一组数据集中器。收集器遍布世界各地；这些收集器并不是都直接连接到因特网，任何时候都可能有新的数据收集器连接上来或脱开连接。在这个项目中，参与进来的收集器的确切数量经常在变化；数据分析和处理基于区域平均值。
开始时只有 10 个集中器。每个集中器监视来自许多个收集器的数据，这些数据被实时提供给关系数据库。随后，来自关系数据库的数据被提供给运行气象分析和预测的仿真模型的超级计算机并由它处理。集中器的数量和位置会发生变化，但它们的行为则大多更稳定。一旦安装后，集中器就会保持运转，除非碰到系统失效。
我们必须解决的问题：我们的系统如何能够持续运转，并能考虑到在几乎不影响整体性能的条件下，允许动态添加或除去收集器和集中器。
初始分析：特定网络的复杂性
系统中的某些收集器可直接访问因特网；其它的通过无线电传输技术进行连接，它们处在恶劣的外部环境中。事实上，在这些基于无线电的收集器中，许多都被设计成了节能的，以延长电池寿命；收集器的有效范围仅够与下一个最近的收集器或基站联系。这些收集器中许多都不支持 TCP/IP，而是使用基本的分组无线技术。一些更独立的收集器仅仅靠其太阳能电池板获得能量，并使用卫星传输进行通信。还有另外一些收集器则连接到标准蜂窝电话上，用 SMS（short message service，短消息服务）消息传递来发送消息。
在项目的整个生命周期中，可用的收集器的数量会发生变化；在项目开始时，我们无法预测将会构建到未来收集器中的连接类型，也无法预测收集器将使用的技术。例如，在项目的某个阶段，在一个超级计算机群集内使用软件仿真来仿真数量巨大的收集器。我们的解决方案必须能适应所有收集器，不管是真正的还是仿真的，现在的还是将来的。
解决方案：并列（Juxtaposition）
图 1 显示用来解决这个问题的高层次设计。
图 1. 解决数据收集问题
请注意，并列 P2P 网络用来适应网络的多种不同情况，而集中器提供 P2P 网络和传统的客户机／服务器网络之间的连接，数据库服务器和超级计算机驻留在客户机／服务器网络。集中器充当两个网络之间的网桥 ― 每个集中器在 P2P 网络上具有动态特性，在客户机／服务器网络具有静态特性。
这个体系结构反映了 Jxta 对传统系统的补充作用和提供并行于这些传统系统的增值的能力 ― 通过并列（juxtaposition），Jxta 的名称就源于这个词语。
我们不想深入讨论这里的客户机／服务器网络的细节，因为其中并没有什么独特之处；我们甚至可以使用 VPN 技术在因特网上运行它。有趣的部分在 P2P 网络。图 2 显示了它的组成，它可随将来的变化而变化。请注意其中用到的多种不同技术。
图 2. 数据收集器网络的组成
在实现这个 P2P 网络时，我们可以利用 Jxta，从而获得以下优点：
容易地添加或除去新的收集器或集中器，这得益于 Jxta 的统一分散寻址
设计简单性，这得益于 Jxta 的网络虚拟化
持续运转，这得益于 Jxta 支持故障弹性
免维护运转，这得益于 Jxta 支持动态自我组织网络
支持跨越许多硬件平台和编程语言的多种不同实现，支持所用的各种不同通信协议让我们来更详细地研究一下其中几个益处，并看看 Jxta 如何为体系结构的各个方面作出独特的贡献。
统一分散寻址
统一分散寻址的字面意思是，对等机可以为自己生成一个 ID 并立即加入到网络，而不必与任何注册人或中央认证机构联系，而当今的 DNS 则必须这样。这一特征使我们任何时候都可以向网络添加收集器和集中器。
在本文附带的代码包中（您可以从参考资料下载它），我们提供了名为 mdidgen 的实用程序，它可以用来为新的 Jxta 服务和管道生成地址。（要更多了解 mdidgen，请参阅旁注 mdidgen 实用程序。）您可以阅读本系列的第一篇文章，了解 Jxta ID 是如何用来对 Jxta 对象（例如：对等机、对等组、服务和管道）进行统一寻址的。
请注意，Jxta 网络中的对等机不一定要有一个独立的物理存在。在我们的示例中，我们用一个超级计算机群集来仿真数量巨大的收集器，每个收集器有它自己的统一地址。这些仿真收集器的每一个在 P2P 网络的其它部分看来都是一个与那些具有物理存在的对等机没有什么差别的对等机。
网络虚拟化
通过分散寻址为所有收集器和集中器赋予网络中唯一的标识后，它们立即就成为网络中的对等机并开始彼此通信。尽管它们可能通过许多种不同的消息传递机制进行相互联系，但在 Jxta 级别上，它们都只是一个虚拟网状网络中的节点，如图 3 所示。
图 3. 网络虚拟化
请注意，将收集器和对等机实际相互连接起来的所有不同的传输和寻址模式都被虚拟化了，只留下一个网状网络，其中的每个对等机都与其它每一个对等机相连接。Jxta 通过使用统一寻址模式和极迟绑定（very late binding），在多个端点协议上添加一个智能消息路由层做到这一点。从本质上说，每一个端点协议或传输协议栈都成为虚拟 Jxta 网络的一个驱动程序，将虚拟网络映射到物理网络上。图 4 显示了这种设置。
图 4. 端点协议作为驱动程序
通信协议要成为合格的端点协议，只需要它能够在两个物理节点之间发送或接收 XML 消息。对传输可靠性或消息广播支持没有什么要求。因而，最简单的分组无线协议也可以用作端点协议驱动程序，与像 TCP/IP 这样的复杂多层协议并列。这也解释了为什么 HTTP 和 TCP/IP 在 Jxta 协议栈内都是同一级别的端点协议，尽管它们的物理级别非常不同。HTTP 是一个受支持的端点协议，因为只要有必要，它就能够穿越尽可能多的防火墙，从而获取从一个 Jxta 对等机传送到另一个的消息。
Jxta 网络中的每个对等机可以同时支持多个端点协议，Jxta 虚拟网络机制会以一种尽可能迟的方式将虚拟化的统一网络地址映射到物理网络地址（在 Jxta 中称为网络端点）。从本质上说，一个对等机对应于一组物理端点，其中的每个物理端点可以在完全不同的物理通信协议上实现。较高级别的虚拟化和路由服务隐藏了这一点。许多人或许能看出这就是多协议路由器的一个非常高级的形式 ― 正是这相同的设备使当今的因特网成为现实。这一概念的发展将把我们带向一个更加普遍的因特网，这是再自然不过的了。
让我们更详细地研究一下图 5 所示的示例。对等机 A 是网络中的一个收集器，它试图通过一系列中介收集器（对等机 B、C 和 D）将其数据发送到集中器（对等机 E）。在图中每个对等机的下面是该对等机所支持的一组协议。
图 5. Jxta 路由示例
因为对等机 A 不直接连接到对等机 E，所以它的消息必须通过中介对等机 B、C 和 D 进行路由。Jxta 将自动对消息进行路由：
使用 TCP/IP 从对等机 A 到对等机 B
使用分组无线协议从对等机 B 到对等机 C
使用 SMS 从对等机 C 到对等机 D
使用 HTTP 从对等机 D 到对等机 E
对等机 E 将在它创建的管道上接收来自对等机 A 的消息，完全未觉察 Jxta 为它所执行的复杂工作。请注意，对等机 C 到对等机 D 的路径是非
