使 P2P 能进行交互操作:Jxta的故事
(来源:http://www-900.ibm.com/developerWorks/)
Sing Li (westmakaha@yahoo.com) 对等网络即将来临了,它承诺要创建一个根本不同的计算世界 — 而且,在某些方面 — 比基于老模式客户机/服务器的要更好。Jxta 工程是按社区方式运作的,旨在为对等应用构建实用应用程序底层。虽然 Jxta 的参考实现是用 Java 语言写的,但事实上它对当今现有的任何语言,操作系统(OS)或平台都会欣然接纳 — 而且,更重要的是,对于人们现在想都没想过的技术,它也做好了准备。在本文,即此系列的第一部分(共 3 部分)中,Java 开发人员兼作者 Sing Li 解释了支持 Jxta 的基本概念和协议,使您为阅读后面的文章做好准备。后面这些文章将教您试验 Jxta shell 并且构建 P2P 应用。请在 讨论论坛与作者和其他读者共享您关于本文的心得。 对等(P2P)网络与传统的客户机/服务器或多层服务器网络不同,对等网络中的对等机是彼此直接通信的。这种通信无需依赖集中式服务器或资源就可完成。在 P2P 网络中,通过对等机之间的交互操作就可以完成工作,共享信息。通过创建有潜力展示非常高的可用性和容错能力的计算资源网络,P2P 体系结构使真正的分布式计算成为可能。 传统的客户机/服务器和多层次体系结构已经是业界的识途老马,而采用 P2P 体系结构的系统则还只是初生牛犊。Jxta 工程是 Sun 为了向构建跨平台、跨操作系统(OS)和跨编程语言的 P2P 应用提供实用应用程序底层而发动的突袭。这项工程现在是开放源代码的,Sun 也参与其中,请参阅参考资料部分以获取关于 Jxta 社区的信息。 Jxta 的设计理念 Jxta 工程对 Java 平台的独立性
互操作性作为一个设计选项 在其核心处使用 XML Jxta 核心构件
对这些组件中的每一个所做的研究将揭示 P2P 通信在 Jxta 网络上是如何工作的。 对等机和对等组 物理网络的逻辑划分产生了对等机的工作组,P2P 行话称之为对等组。对等组成员资格的交迭没有任何约束;换句话说,任何对等机有必要属于几个对等组,就可以属于几个对等组。Jxta 规范并没有规定或推荐组织对等组的合适方式。在 Jxta 网络中,对等组就是共享资源和服务的对等机的集合。您可以很容易地明白,如果这个规范把对等组限制为例如局域网 — 或者甚至是广域网的一个子集 — 那么,很多要求组成员资格超出这些物理限制的新应用程序的可能性将一概被排除。与 Jxta 的设计理念一致,对等组被规定为尽可能不受限制、尽可能普遍适应。 请注意,对等组的存在要求一些维护成员资格的手段。Jxta 规范又一次只规定了维护组成员资格的最小需求,而没有指示该怎样维护。这种组成员资格服务只是核心 Jxta 服务的一部分,但它可以接受很多种形式 — 例如,它可以是数据库或目录服务,还可以是基于集中式或分布式实现的。 服务 表 1. Jxta 服务
Jxta 工程最初的参考实现不提供上面列出的五项之外的任何服务。甚至核心服务中的一些服务,例如处理安全性的访问服务,也只是实现了非常基础的方面。现行的 Jxta 社区正在为这些服务中的大多数充实细节,同时也在定义和实现对对等组或许有益的新服务(一般地或特定地)。例如,该社区目前正在进行的新服务包括:
在 Jxta 1.0 规范中,一个运行中的服务实例总是和一个对等机联系在一起(您可以把它想象成是由一个对等“服务器”主管的)。在一个对等组内,只能有一个服务实例和指定的对等机联系在一起。这种类型的服务被视为对等服务;如果主管该对等服务的对等机当机了,那么将无法获得该服务。另一方面,同一服务的多个实例被冗余地安装在一个对等组内的多个对等机上 — 这被称为对等组服务。对等组服务是 Jxta 网络的高可用性和容错性的关键。Jxta 应用的实现者可以自由地把任意 Jxta 服务作为对等服务或对等组服务进行安装。管道服务,即为对等通信提供逻辑管道抽象的核心 Jxta 服务,常常被作为对等组服务来实现,以确保其总是可用。 管道 一个管道实例,从逻辑上讲,是对等组内的一个资源。管道实例的实际实现通常情况下是通过管道服务完成的。与传统(类似 UNIX 的)的系统不同,Jxta 管道是单向的、异步的。需要双向通信的两个对等机将不得不创建两个独立的管道实例。也跟传统机制如 UNIX 管道或 TCP/IP 套接字不同,Jxta 管道的末端可以在不同的时间连接到不同的对等机上,或者根本不连接。在为 P2P 网络上的服务提供冗余实现方面,只此一个单一概念就是革命性的一步。对等机可以在任一点及时逻辑地“拾起”管道。例如,设想一个想使用拼写检查器服务的对等机。它可以连接到一个对等组的拼写检查器管道(该管道是被作为冗余对等组服务实现的)上。在这种情况下,只要至少有一个拼写检查器的实例还在该对等组内的某个地方运行,该对等机就还能得到服务。 Jxta 1.0 规范提供了两种一般类型的管道:点对点和广播(propagate)。 对等机可以使用点对点管道连接到另一个对等机并单向传输消息。对等机可以使用广播管道连接到一个或多个其它对等机并向它们全体传输消息。从本质上讲,点对点管道是一对一的消息传输机制,广播管道则是一对多的消息传输机制。Jxta 社区目前正在多对多消息传输机制方面努力;这个机制已经被命名为 Jxta 导线(wire)。 不管是什么类型的管道,通过管道载送的信息块都称为 Jxta 消息。那么,这些消息的确切格式是什么样子呢? 消息
消息正文的长度是任意的,可以包含一个可选的信任状(出于安全性目的)和内容。 请注意,Jxta 消息的定义非常松散。考虑到我们日常一般都是在可靠的、宽带的 TCP/IP 网络上操作,这样做的必要性并不是立即可以明了的。但 Jxta 消息的格式必须是灵活的、善于适应新环境的,因为它可能要在所有种类的网络上实现,而不只是在 TCP/IP 上。设想在一个支持 256 字节数据包的不可靠传输的网络(象传统的基于数据包的无线网络)上的一个 Jxta 实现,您就会对 Jxta 消息的简单定义如何使自己适应诸如这样的不利环境表示赞赏。 为了提供一个标准的、语法上易分析的、通用的编码机制,Jxta 消息目前采用 XML 文档格式。Jxta 利用了 XML 的普遍可访问性和易使用、易编程的特点,这意味着 Jxta 可以用大多数编程语言在大多数平台上很容易地实现 — 只要 XML 语法分析器和生成库在那里是可用的。然而,Jxta 本身的设计却使其消息代码的编写不依赖于 XML 的使用。虽然现在不太可能,但 Jxta 社区在规范的未来版本中包含(或要求)基于非 XML 的消息是完全可能的。
广告 互操作性的基础:Jxta 协议 例如,一个简单的 PDA(8 位处理器,基于 C 语言编程)就可以是一个运行在基于数据包的无线网络上的 Jxta 对等机,它可与同一对等组内的各种系统,从 PC 服务器到大型机,进行交互。如果这些对等机共享一个公共网络(传送)并正使用 Jxta 协议和消息格式进行通信,这是可以做到的。 Sun 已为 Jxta 提供了初步的 Java 语言实现。Jxta 社区现在拥有这个参考实现。这个参考实现为那些想立刻使用 Jxta 的 Java 程序员把事情变简单了。而如果您正在非 Java 平台上实现 Jxta,那么理解这些协议就是非常重要的。表 2 简要描述了 Jxta 协议的核心集,涵盖了发现(对等机如何找到对方)、广告(对等机如何让别的对等机了解对等组、管道等信息)、通过管道进行的通信和对等组成员资格的处理。下面的所有协议都是建立在传送器上的 XML 消息交换的基础上的。同样地,它们可以用几乎所有的编程语言在几乎所有平台上实现。 表 2. Jxta 核心协议
Jxta 规范不要求对等机实现上述所有协议。任一特定的对等机只须实现那些实际要用到的协议。 基于 Jxta 的系统的一些有趣的属性 有“电子心跳”的任何东西都可以成为一个 Jxta 对等机 在 P2P 网络上,过分简化的设备需要对等代理人。这个代理人可以代表该简化设备(或多个简化设备)执行发现、广告和通信。代理人的位置可以被硬性固定在简化设备。这样,在代理人的帮助下,简化设备就可以成为 Jxta 网络上完全合格的对等机。例如,一个被绑在一只海龟身上并以无线方式发送出带有位置信息的 Jxta 消息的 GPS 定位器,就可以成为 Jxta 网络上的一个对等机。 不确定拓扑结构的网络中的顺序 在 Jxta 世界里,一个特定的资源请求不会在几分钟、几小时或甚至几天内返回;事实上,它可能根本就不会返回。另外,请求同一资源的世界各地的人们很可能得到的是来自完全不同的服务器的资源副本。这就引起了一个问题:不确定性系统有什么好处呢? 来自 grassroots 软件革命的灵感
在完美的 Jxta 世界中,我们将在不确定性网络上执行异步请求。您觉得这个概念古怪吗? 让我们用一个示例来阐明。设想一个在基于 Jxta 的 P2P 网络上运行的基于网络的音乐请求服务。对等机提交了几个对音乐文件的请求并在一段时间后核查对等组中的音乐请求服务是否找到了这些文件。当我们在一段时间后去核查音乐请求服务时,所请求的一些文件已经被找到,但其它的却无法定位。服务对那些文件的响应是:音乐的选择和可用性在不断地变化;请稍后重试您的请求。这是一个可接受的不确定的结果:虽然服务未能找到一个文件,但如果我们稍后再次提交同一个请求,那个文件或许就是可用的了,因为主管我们想要的那个文件的对等机这时或许在线了。 当放到这样一个具体的上下文中的时候,不确定性网络的概念看起来就不再那么陌生了。事实上,我们多数人大概都会接受并使用这样一个音乐请求服务。我们中的一些人甚至愿意为这样的自动代理支付一点费用,这种代理会持续监视所选文件的可用性,然后为我们取来并存储它们的副本。这是 P2P 计算的巨大魅力之一:均衡并共享全世界的所有连接着的资源的能力 — 但愿是以有秩序的和文明的方式。 该讲的都讲完了,但最先几个在商业上取得突破的 Jxta/P2P 应用大概还是会因把确定性和同步性作为它们的主要特征而引以为豪。这是一个必要的过渡,因为用户的习惯和市场取向不会在一夜之间改变 — 如果没有强制原因的话将来不会改变。新的 P2P 模型将慢慢地浮现,起先可能会是以混合的形式出现。一个当前示例:基于边缘传播(edge-propagation-based)的网络高速缓存技术,比如 Akamai,是目前确定性的、集中式的 Web 上的规范。这些技术用 P2P 风格的概念在集中式服务器的世界里实现优化的内容传送。 社会影响和棘手的知识产权问题 在大众和商业新闻中已经写了很多。Sun 不在其 Jxta 实现中规定策略的决定使得它可以自由地前进并扫除了这些争论 — 把责任放在了那些在内容分发上率先采用 Jxta 技术的先锋们的肩上。然而,在这个舞台上, Jxta 技术基于社区的发展使它有潜力全局控制 IP(知识产权)所有者和公众之间的良好平衡。开放的 Jxta 社区可以作为一个论坛,IP(知识产权)所有者和技术专家可在此论坛解决它们之间的分歧。 透视 Jxta:它如何与 .Net 和 Jini 较量 要确信,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 并试验它的命令行 shell,创建该 shell 的定制扩展,为 Jxta 网络设计 P2P 应用。
|