1、Java分布式开发，有那些技术可以实现。
我知道的有RMI、CORBA
2、RMI和CORBA都能够实现下面的功能吗？如果都能够，那个更好？现有多台服务器，当用户登陆任何一台服务器的时候，这个服务器除了要检索自己本地的资源以外，还可以作为一个客户端，自动地去连接其它服务器，发出检索请求，并将检索的结果进行合并和汇总，返回给用户登陆的那台服务器。（这样，用户只需要登陆任意一台服务器，就可以检索到大量所需资源，尽管这些资源来自于不同的服务器，但检索的过程对用户来说是透明的，用户检索和获取这些资源就如同检索和获取所请求的服务器上的资源一样。）3、webservice可以实现吗，能简单介绍下webservice吗？望达人指教！
我知道的有RMI、CORBA
2、RMI和CORBA都能够实现下面的功能吗？如果都能够，那个更好？现有多台服务器，当用户登陆任何一台服务器的时候，这个服务器除了要检索自己本地的资源以外，还可以作为一个客户端，自动地去连接其它服务器，发出检索请求，并将检索的结果进行合并和汇总，返回给用户登陆的那台服务器。（这样，用户只需要登陆任意一台服务器，就可以检索到大量所需资源，尽管这些资源来自于不同的服务器，但检索的过程对用户来说是透明的，用户检索和获取这些资源就如同检索和获取所请求的服务器上的资源一样。）3、webservice可以实现吗，能简单介绍下webservice吗？望达人指教！
CORBA可以多语言下使用,编写比较复杂;
EJB3.0开始就用的是rmi-iiop了,他是兼容rmi和CORBA两者;
再有,webservice不可以,他只能处理soap协议的东西,当然如果你用SOA的框架可以整合包括webservice以内的任何一般协议的访问;
如楼主的一个服务器即当服务提供者又是其他服务使用者,最好不要用webservice,使用EJB,比较不错的选择
我不是很同意您的说法，现在很多大型系统的设计都不单纯使用到一种语言，很可能会有两种或者更多的，简单点，就是用C#和JAVA，如果C#主要处理应用端，而JAVA出要处理 WEB端，那么这样的系统算不算分布式系统，在这种模式下，采用的数据传输模式即为Webservice，只是，这样的方式与采用EJB的方式不同的地方在于，首先需要在应用端也加入对Session的判断以及过期时间，再次，应用端是完全服务于WEB端的。
但我更想知道的是第2问，即：
2、RMI和CORBA都能够实现下面的功能吗？如果都能够，那个更好？ 其它还有什么好的技术可以实现，EJB吗？现有多台服务器，当用户登陆任何一台服务器的时候，这个服务器除了要检索自己本地的资源以外，还可以作为一个客户端，自动地去连接其它服务器，发出检索请求，并将检索的结果进行合并和汇总，返回给用户登陆的那台服务器。（
lz要是不了解单点登陆，请参考下边
http://blog.csdn.net/hudon/archive/2007/02/09/1506042.aspx
如果lz比较了解了，这里给出一些常用的解决方案.
http://bbs.ad0.cn/viewthread.php?tid=1368
至于lz采用什么样的技术选型，这个还得从整个项目考虑。
不是SSO问题。
我简单说吧：打算做的是一个小项目，实现不同web服务器(Tomcat)之间通信，用什么技术可以实现呢？当然服务器同时也可以作为客户器使用。
打算做的是一个小项目，实现不同web服务器(Tomcat)之间通信，用什么技术可以实现呢？当然服务器同时也可以作为客户器使用。
2. EJB，Web Service / RESTful
那么使用http就行了
Web Service是一个应用组件,它逻辑性的为其他应用程序提供数据与服务.各应用程序通过网络协议和规定的一些标准数据格式（Http，XML，Soap)来访问Web Service,通过Web Service内部执行得到所需结果.Web Service可以执行从简单的请求到复杂商务处理的任何功能。一旦部署以后，其他Web Service应用程序可以发现并调用它部署的服务。
Hadoop分布式文件系统(HDFS)被设计成适合运行在通用硬件(commodity hardware)上的分布式文件系统。它和现有的分布式文件系统有很多共同点。但同时，它和其他的分布式文件系统的区别也是很明显的。HDFS是一个高度容错性的系统，适合部署在廉价的机器上。HDFS能提供高吞吐量的数据访问，非常适合大规模数据集上的应用。HDFS放宽了一部分POSIX约束，来实现流式读取文件系统数据的目的。HDFS在最开始是作为Apache Nutch搜索引擎项目的基础架构而开发的。HDFS是Apache Hadoop Core项目的一部分。这个项目的地址是http://hadoop.apache.org/core/。 前提和设计目标
硬件错误
硬件错误是常态而不是异常。HDFS可能由成百上千的服务器所构成，每个服务器上存储着文件系统的部分数据。我们面对的现实是构成系统的组件数目是巨大的，而且任一组件都有可能失效，这意味着总是有一部分HDFS的组件是不工作的。因此错误检测和快速、自动的恢复是HDFS最核心的架构目标。 流式数据访问
运行在HDFS上的应用和普通的应用不同，需要流式访问它们的数据集。HDFS的设计中更多的考虑到了数据批处理，而不是用户交互处理。比之数据访问的低延迟问题，更关键的在于数据访问的高吞吐量。POSIX标准设置的很多硬性约束对HDFS应用系统不是必需的。为了提高数据的吞吐量，在一些关键方面对POSIX的语义做了一些修改。 大规模数据集
运行在HDFS上的应用具有很大的数据集。HDFS上的一个典型文件大小一般都在G字节至T字节。因此，HDFS被调节以支持大文件存储。它应该能提供整体上高的数据传输带宽，能在一个集群里扩展到数百个节点。一个单一的HDFS实例应该能支撑数以千万计的文件。 简单的一致性模型
HDFS应用需要一个“一次写入多次读取”的文件访问模型。一个文件经过创建、写入和关闭之后就不需要改变。这一假设简化了数据一致性问题，并且使高吞吐量的数据访问成为可能。Map/Reduce应用或者网络爬虫应用都非常适合这个模型。目前还有计划在将来扩充这个模型，使之支持文件的附加写操作。 “移动计算比移动数据更划算”
一个应用请求的计算，离它操作的数据越近就越高效，在数据达到海量级别的时候更是如此。因为这样就能降低网络阻塞的影响，提高系统数据的吞吐量。将计算移动到数据附近，比之将数据移动到应用所在显然更好。HDFS为应用提供了将它们自己移动到数据附近的接口。 异构软硬件平台间的可移植性
HDFS在设计的时候就考虑到平台的可移植性。这种特性方便了HDFS作为大规模数据应用平台的推广。 Namenode 和 Datanode
HDFS采用master/slave架构。一个HDFS集群是由一个Namenode和一定数目的Datanodes组成。Namenode是一个中心服务器，负责管理文件系统的名字空间(namespace)以及客户端对文件的访问。集群中的Datanode一般是一个节点一个，负责管理它所在节点上的存储。HDFS暴露了文件系统的名字空间，用户能够以文件的形式在上面存储数据。从内部看，一个文件其实被分成一个或多个数据块，这些块存储在一组Datanode上。Namenode执行文件系统的名字空间操作，比如打开、关闭、重命名文件或目录。它也负责确定数据块到具体Datanode节点的映射。Datanode负责处理文件系统客户端的读写请求。在Namenode的统一调度下进行数据块的创建、删除和复制。