|
在 Jxta 规范中一个运行中的服务实例总是和一个对等机联系在一起（您可以把它想象成是由一个对等服务器主管的）在一个对等组内只能有一个服务实例和指定的对等机联系在一起这种类型的服务被视为对等服务如果主管该对等服务的对等机当机了那么将无法获得该服务另一方面同一服务的多个实例被冗余地安装在一个对等组内的多个对等机上这被称为对等组服务对等组服务是 Jxta 网络的高可用性和容错性的关键Jxta 应用的实现者可以自由地把任意 Jxta 服务作为对等服务或对等组服务进行安装管道服务即为对等通信提供逻辑管道抽象的核心 Jxta 服务常常被作为对等组服务来实现以确保其总是可用 管道正如 Jxta 规范定义在对等机之间传输数据文件信息代码或多媒体内容的一种方式是通过逻辑管道Jxta 管道用于在对等机之间发送消息（可带任意内容） 一个管道实例从逻辑上讲是对等组内的一个资源管道实例的实际实现通常情况下是通过管道服务完成的与传统（类似 UNIX 的）的系统不同Jxta 管道是单向的异步的需要双向通信的两个对等机将不得不创建两个独立的管道实例也跟传统机制如 UNIX 管道或 TCP/IP 套接字不同Jxta 管道的末端可以在不同的时间连接到不同的对等机上或者根本不连接在为 PP 网络上的服务提供冗余实现方面只此一个单一概念就是革命性的一步对等机可以在任一点及时逻辑地拾起管道例如设想一个想使用拼写检查器服务的对等机它可以连接到一个对等组的拼写检查器管道（该管道是被作为冗余对等组服务实现的）上在这种情况下只要至少有一个拼写检查器的实例还在该对等组内的某个地方运行该对等机就还能得到服务 Jxta 规范提供了两种一般类型的管道点对点和广播（propagate） 对等机可以使用点对点管道连接到另一个对等机并单向传输消息对等机可以使用广播管道连接到一个或多个其它对等机并向它们全体传输消息从本质上讲点对点管道是一对一的消息传输机制广播管道则是一对多的消息传输机制Jxta 社区目前正在多对多消息传输机制方面努力这个机制已经被命名为 Jxta 导线（wire）不管是什么类型的管道通过管道载送的信息块都称为 Jxta 消息那么这些消息的确切格式是什么样子呢？ 消息 Jxta 消息是通过管道从一个对等机传送到另一个对等机的数据束这里Jxta 规范再一次尽可能地使自己普遍适应以免不经意间在消息的定义中引入任何依赖于实现的策略消息被定义为由信封和正文组成的任意大小的束信封是标准格式它包括 报头 源端点信息（URI 格式） 目的地端点信息（URI 格式） 消息摘要（可选的出于安全性目的） 消息正文的长度是任意的可以包含一个可选的信任状（出于安全性目的）和内容 请注意Jxta 消息的定义非常松散考虑到我们日常一般都是在可靠的宽带的 TCP/IP 网络上操作这样做的必要性并不是立即可以明了的但 Jxta 消息的格式必须是灵活的善于适应新环境的因为它可能要在所有种类的网络上实现而不只是在 TCP/IP 上设想在一个支持 字节数据包的不可靠传输的网络（象传统的基于数据包的无线网络）上的一个 Jxta 实现您就会对 Jxta 消息的简单定义如何使自己适应诸如这样的不利环境表示赞赏 为了提供一个标准的语法上易分析的通用的编码机制Jxta 消息目前采用 XML 文档格式Jxta 利用了 XML 的普遍可访问性和易使用易编程的特点这意味着 Jxta 可以用大多数编程语言在大多数平台上很容易地实现只要 XML 语法分析器和生成库在那里是可用的然而Jxta 本身的设计却使其消息代码的编写不依赖于 XML 的使用虽然现在不太可能但 Jxta 社区在规范的未来版本中包含（或要求）基于非 XML 的消息是完全可能的 关于 Jxta 标识符从潜力上讲对等组或许可以跟整个联系着的宇宙一样大在这么大的名称空间中为任何事物进行唯一的命名都是一个挑战为了应对这个问题Jxta 给 Jxta 组件的每个可设定地址的实例都分配了一个内部标识符这种标识是通过一个 UUID 进行的UUID 是使用能够确保在时间和空间上都有很高概率的唯一性的算法产生的 字节的数字Jxta 标识符是 URN（统一资源名称）格式的并被嵌入到广告中供内部使用目前定义了四种标识符类型用于标识对等组对等机管道和代码／数据（code/data）（简写为 codat） 广告 广告有点像是消息的堂兄弟Jxta 广告也采用 XML 文档格式广告的内容描述了诸如对等机对等组管道或服务等 Jxta 组件实例的属性例如可以访问另一个对等机的广告的对等机可以设法直接连到该对等机上可以访问一个对等组的广告的对等机可以通过广告加入对等组目前的因特网中与广告相似的东西是域名和 Web 站点的 DNS 纪录Jxta 规范没有规定如何创建传播或销毁广告 互操作性的基础Jxta 协议互操作性的另一个关键是这样一个事实核心 Jxta 对等交互操作模型被完全表示为在底层网络上传输的一套简单协议换句话说既然协议和消息格式是定义完好的那么基于 Jxta 的系统间的互操作性完全可以在导线一级上达到 例如一个简单的 PDA（ 位处理器基于 C 语言编程）就可以是一个运行在基于数据包的无线网络上的 Jxta 对等机它可与同一对等组内的各种系统从 PC 服务器到大型机进行交互如果这些对等机共享一个公共网络（传送）并正使用 Jxta 协议和消息格式进行通信这是可以做到的 Sun 已为 Jxta 提供了初步的 Java 语言实现Jxta 社区现在拥有这个参考实现这个参考实现为那些想立刻使用 Jxta 的 Java 程序员把事情变简单了而如果您正在非 Java 平台上实现 Jxta那么理解这些协议就是非常重要的表 简要描述了 Jxta 协议的核心集涵盖了发现（对等机如何找到对方）广告（对等机如何让别的对等机了解对等组管道等信息）通过管道进行的通信和对等组成员资格的处理下面的所有协议都是建立在传送器上的 XML 消息交换的基础上的同样地它们可以用几乎所有的编程语言在几乎所有平台上实现 表 Jxta 核心协议 Jxta 规范不要求对等机实现上述所有协议任一特定的对等机只须实现那些实际要用到的协议 基于 Jxta 的系统的一些有趣的属性 既然您已经对 Jxta 平台理论上的构件有了一个基本理解我们就来讨论一下作为 Jxta 设计结果的一些有趣的属性 有电子心跳的任何东西都可以成为一个 Jxta 对等机从理论上说有文本字符串生成能力的最简设备都可以加入（虽然并不是在每个 PP 应用中都有必要）到 Jxta 网络中这是怎么成为可能的呢？ 在 PP 网络上过分简化的设备需要对等代理人这个代理人可以代表该简化设备（或多个简化设备）执行发现广告和通信代理人的位置可以被硬性固定在简化设备这样在代理人的帮助下简化设备就可以成为 Jxta 网络上完全合格的对等机例如一个被绑在一只海龟身上并以无线方式发送出带有位置信息的 Jxta 消息的 GPS 定位器就可以成为 Jxta 网络上的一个对等机 不确定拓扑结构的网络中的顺序 典型 Jxta 网络另一个迷人的方面是它固有的不确定的拓扑／响应结构计算机用户通常都习惯于本质上确定的同步的计算机系统并认为这是一种标准结构例如当我们的浏览器发出 Web 页面的 一个 URL 请求时我们期望输出立刻就会出现我们还期望世界上的每个人都可以使用同一个 URL 从同一个 Web 服务器检索同一个页面 在 Jxta 世界里一个特定的资源请求不会在几分钟几小时或甚至几天内返回事实上它可能根本就不会返回另外请求同一资源的世界各地的人们很可能得到的是来自完全不同的服务器的资源副本这就引起了一个问题不确定性系统有什么好处呢？ 来自 grassroots 软件革命的灵感 我们只要看看象 Napster 和 Gnutella 这样的流行 PP 系统就可以找到答案下面是它们的一些额外的优势特征（它们使同步性和确定性的丧失变得值得） 内容的高可用性 对等机可以从多个服务器上获取内容理想情况下可从附近开机运行着的一台服务器上获得原始源对等机不必为每一个资源请求服务事实上它甚至可以不开机运行网络带宽的最优化使用 现今 Web 上典型的局部流量集中导致的拥塞不会影响 PP 网络 更低的内容分发成本 PP 网络能吸纳内容并复制它以使它易于存取 来自网络中各个节点的计算能力的均衡 通过异步操作您可以同时发出许多资源或服务请求然后让网络为您完成这些工作 无限的可伸缩性 一个设计良好的 PP 应用可以在不影响可伸缩性限制的情况下横越整个已知的连接着的宇宙而这在任何集中式模式中是完全不可能的 在完美的 Jxta 世界中我们将在不确定性网络上执行异步请求您觉得这个概念古怪吗？让我们用一个示例来阐明设想一个在基于 Jxta 的 PP 网络上运行的基于网络的音乐请求服务对等机提交了几个对音乐文件的请求并在一段时间后核查对等组中的音乐请求服务是否找到了这些文件当我们在一段时间后去核查音乐请求服务时所请求的一些文件已经被找到但其它的却无法定位服务对那些文件的响应是音乐的选择和可用性在不断地变化请稍后重试您的请求这是一个可接受的不确定的结果虽然服务未能找到一个文件 |
