分布式计算技术的比较：Jini, Jxta and Web Services

网络就是计算机，SUN当初推出Java时就喊出这个口号，最近微软又在喊这个口号，
这个口号的真正实施实际变成了分布式计算标准的竞争，Web Services无疑是现在
风头正劲的。

但是Web Services是基于HTTP协议，而Jini和Jxta则可以直接基于TCP或UDP（QQ是基于UDP
协议的，QQ的使用一点不亚于新浪等网站的WEB使用），因此它们应该说是互补，可以共生的。

Jini和Web Services的共同特点都有相差不多的Lookup和Discovery机制：client通过lookup
查找提供相应Service的Server,然后彼此直接建立连接。Jini还有一个Join机制。

推荐SUN公司的这篇关于三者技术比较的文章，也许对你了解分布式架构技术有所帮助，文章
从协议和网络角度比较了这三个技术，总结如下：

直接调用socket:
反应时间最快；
传输消耗为0;

但是
网络必须是可靠稳定的；
网络拓扑结构不能改变；
网络种类必须是同质的；
可能比较难于管理;
网络安全无保障；

Web Services:
非常容易管理维护；
无带宽要求；
对网络的稳定性要求也不高；
当然还有一个更大的优点(文章没有列出)：不必一定基于Java，所以微软才大力推行它，
如果你的系统完全基于Java（强烈建议），Web Services基本就是鸡肋;

jini基本上类似直接调用socket，还有两个优点就是对带宽无要求 和网络种类无要求；同时继承
了web sercies的优点之一：易于管理。
响应时间还可以，但是可能在传输层上性能有所消耗。

Jxta是最安全的(因为是p2p 点对点啊)，可能依赖带宽速度，其它和Jini差不多。

文章连接：http://developer.java.sun.com/developer/onlineTraining/webcasts/20plus/pdf/mgoff.pdf

很早以前买过一本<<Distribute Operation System>>的英文书，
一直没看，最近开始当休闲读物看了一点，感觉写得很通俗易懂。
对了解分布式系统有帮助

呵呵，那本书叫 Distribute Operation System.

另，给 Banq 的 Jive 提个建议，把 HTML 解析去掉，只支持 UBB 代码。
或都自动将< 转换成 &lt;

Jini 是一种连接分布式服务以及集中式服务定位器(lookup service)的机制，
而JXTA是一种在peer-style网络中连接连接分布式服务, 如果在JXTA中的Peer或者Peer组
提供一种特别的服务，这样就可以通过查询lookup service获得这种服务。

Jini是注重在服务的注册,发现，事务跟踪以及服务的租用；而JXTA注重在一个面向Peer的
计算模式:支持Peer组，Peer管道以及Peer广播，这些只要在Jini Service Registrar中
建立一个连接就可以。用这种办法，Jini和JXTA能够提供建立分布式服务的强有力的工具。
并且能够和其它技术和语言整合在一起(因为JXTA是语言无关性)

to iceant
了解分布式计算的理论就象了解Internet的理论一样，于实际意义不大，最近我们有个分布式计算的架构，不能用J2EE,我觉得Jini不错。

^_^ 各有各的看法。

我觉得理论是前人总结的经验，值得学习和借鉴,但是我不抄袭。

我对分布式系统很有兴趣，但是我一直没有时间和精力来学习相关的知识。可以说我对分布式处理只是门外汉。
但是，一直以来我都喜欢"做梦"，如果有时间你可以到 www.apusic.com的论坛上,看看我在差不多一年前发的有关我的梦的文章。在那里我谈到了我对分布式系统的一个梦想。我可以大致重复一下那篇文章的内容，我眼里的计算机已经不再是实体的概念。它只是一个虚拟存在的系统。我认为这样的系统有一个内核(有多大，该怎么做我并不知道)，内核就像我们的心脏，失去了内核，该系统就在虚拟世界里消失了。但是内核很强大。它可以帮助系统从其它计算机实体里获得资源。举个例子来说，内核可以控制多台计算机实体做为它的计算组件，可以联接多台Storage做为存贮。当一个计算机实体发生故障，比如说是计算组件发生故障，该内核会在网络里搜索一台从网络速度到单机负载能力综合能力比较强的机器或多台做为后备组件，然后当它能够接管过这些机器的控制权以后，它会将发生故障的机器上的 Session 转移到这些后备组件上去。....
....我还可以继续下去写成科幻小说 ^_^

OK,回到现实，我的梦从哪里来? 从前人的经验来。我可以说，这些想法绝不是空想，每一个小的光点，我都能在现在的分布式系统里找到依据。

我发现自己在读 EJB 规范的时候又明白了 CORBA 的设计思想，我能很深的感受到为什么要有 Home-Remote-Bean 的划分这样的细节(试问有多少人真正懂得EJB里的每一部分到底为什么是那样?)。
当我评击 EJB 和 CORBA 的缺点时(基于接口的调用必须先知道接口是什么，而不能动态的发现接口，有一个朋友对 CORBA 比较熟，他说 CORBA 是可以动态发现接口的，但是没有说明工作原理)，Web Service 又让我看到了，不只我一个人看到了 EJB 和 CORBA 的不足。

回归自然，(这里思维要跳得快一点)生物生存的自然系统，交通，银行等构成的人文系统大部分都是使用 Message Driven. 大家经过了这么长的路才走到了 Service Central,Message Driven 的系统架构里.

有时现实是很有意思的，总追求现实，会只能看到现实，总追求梦想，会只看到梦想。

呵呵，今天写的东西最乱，其实我只是想说，只看自己能看到的现实，有点像盲人摸象。看看别人是怎么想的，听听别人是怎么说的，可以让自己的眼界开阔很多。你不用管它对不对，只要听着，用你的思维去分析，总有一个结果....

iceant 兄：
非常棒，其实你的分布式之梦就是internet未来之梦，真正的Internet是什么，就是实现真正的分布式计算。

你能说说Home-Remote-Bean 为什么这样设计，你觉得EJB在性能瓶颈上是在哪里？

你说的很对，目前信息系统基本是Service Central,Message Driven ，因为我现在在搞实时快速系统，所以我现在感兴趣是peer to peer这样的端对端快速连接。

TO: Banq

有人说"授之以鱼，不如授之以渔"
我简单介绍一下自己是怎样思考这个问题的.

因为我们的应用是分布式的，我首先就想，分布式和单机运行在调用一个方法或服务时有什么区别?我们第一步需要什么？
是获取我们需要的对象!
单机，我们直接 new 一个对象，但是分布式系统，如果在远端 new 对象, 然后传到本地，怎么样? 似乎太昂贵! 于是，How about like this, 在远端 new 一个对象，然后在从 server 传一个 reference or handler 到 client. 看起来第二种方式比较好哦, 要传的小了啊。 OK, 那么我们就用第二种方式， 但是这样好像有问题啊，如果访问的人多了，老是重复创建对象，那不是很累? 来个小池子怎么样？不要老是重复建嘛，先建几个，放着，用得着就大家一起用，用不着了，就让它去休假嘛。休假? 你刚才说让这些工人去休假? 天啊，刚刚在做事的那个休假了，可是一直都是他和我在打交道，他对我比较了解啊。没关系，先生，我们这里有您的资料，我们可以很快地让其它人熟悉您，并能很好完成您的工作,于是...我们又有了钝化和激活....

您可以看得到，我是在一步步的引出需求，并寻找适合的解决方案。
但是当你解决了一个问题时，还会带来更多的问题，于是新的需求发现，
我们又能为新需求寻找到新的解决方案... 这样不断下去，我们就能找到问题的真象。

写规范的人和我们一样都是人，他们能想到的解决方案我们也能想到。

写得很形象易懂。

从中可以看出，提高EJb的性能的一个办法就是 失效EJb的钝化，使其永远处于激活状态，其实我认为EJB是对象池+远程通讯的组合。

banq大哥霍格威 现在我们公司有个分布式项目 我想请教一下 我特别想用jini技术 不知道 那位给点意见
基本的项目如下:
1.用户能够通过卡号+密码的方式访问我们的web程序 这时察看是否是没有注册过的卡（是:更改密码产生对称密钥 同时用新密码加密私钥 否:在数据库中拿出私钥）把软件和私钥给用户下载
2.用户得到客户端软件用自己的卡号密码登录 密码在客户端将私钥解开并用私钥加密卡号 然后传到服务器方式ssl 类型是 卡号+加密卡号 的字符串
3.服务器接受卡号+加密卡号 通过卡号找到公钥 然后对加密卡号解密 (不成功返回)
4.登陆成功 产生对应的ID并在服务器的对象池中注册 并将ID注册号返回客户(因为ID随机并在服务器注册所以不容易破解)
5.客户端进行操作但是每次操作都要求跟随ID号 如果ID号在服务器被迫删除 客户端停止相应
6.这里的客户端请求用的是线程池来限制客户连接数(超过100提示服务器繁忙)
7.因为我们的是客户端答题系统 客户主要是为了练习考试内容 当登录成功后客户端最可能的操作就是选择考题难度 在从服务器获得考题 考试时间2个小时超时 客户端自动清空 考生可以在2个小时内提交答案 服务器处理答案 我们的都是选择题
8.现在老板为了防止我们的考题泄漏所以我没有用web程序的方式作
9.还有我想如果客户端一经下载就有可能不访问我们的网站 所以我们的维护就是个问题 譬如客户端软件升级

基本要求就这么多 可选择技术有 web service+ajax(这种是web开发了如果客户端禁止了活动脚本就完了) CORBA RMI RMI-IIOP jini 这些都可以
但是由于我们的服务器不直接支持EJB所以EJB不行
不知道大家有没有好的建议 还有就是那个技术跟适合 有一点目前所有软件都使用java开发 还有一个问题想问如果我的客户端软件该升级了 肯定有崩本号区别 可是我应该怎样设计才能提示升级呢 ??