j2ee初学者问题，赶紧进来领分了

1。web container调用EJB是通过RMI调用。不过如果web container和EJB container是同一个服务器实例的话，可以通过本地接口调用而不是RMI。
2。同意楼上的。不要浮躁。

学习中，观注中
upupupupppupupupuppupupupppu

j2ee的四层对应实际就是一个三层。web container 和ejb container可以驻留在同一个应用服务器上面，可以像本地一样访问。使用rmi确实需要序列化对象，但是并非所有的都需要。网络传输的代价并不高。这种代价相对于以前的两层在开发中带来的问题还是相当值得的。并且传输的数据量远比下载一个页面小，web container 和ejb container之间通常也是高速局域网（有的比本地硬盘都快）关于你的第二个问题，建议你直接去看书。只告诉你EJB的接口和实现肯定在petstore中有。

1. 通过JNDI API来查找EJB的本地接口对象，通过找到的对象创建bean实例，然后调用其方法。序列化是容器掌管的，相信专家。
2. 有实现啊，当然有啦。一般命名规范是这样的远程接口如果叫AaaBbb，bean的实现类就叫AaaBbbBean，本地接口就叫AaaBbbHome。运行的时候容器还会自动生成一些类。PetStore挺深的，不要急着看，慢慢来。

继续>>>>>>>>>>>>>>>

多谢各位的回复，相信如果把web容器和ejb容器部属到不同的机器，类似rmi调用是很难避免的，我想确认，它们是不是真的使用了rmi调用？还是使用了类似的其他技术？本来，大部分应用，像ejb只是产生计算结果的话，rmi序列化的损耗可以忽略不记，但是，也有这样一些应用，它们通过http协议，客户端applet需要大量的数据，这样的话
1。数据通过 jdbc从数据库序列化到ejb
2.(ejb处理以后)从ejb序列化到servlet
3.从servlet序列化到applet
这样一来，很多步骤，比如说第二步，实在是看起来多余啊，数据大的话，损耗很大啊
当然，applet通过rmi调用ejb好想也是可以的，但是rmi协议不如http这样普遍啊，很多防火墙会凤吊这个端口，不能适应大众啊

不知道你怎么需要传这么多数据。这是你设计的问题。
其中第一步和第二步是可以忍受的，而且通常是很快的。比如数据库服务器和应用服务器、web服务器之间以1000M网卡连接。1000M网卡的速度比本地硬盘都快。
第3步是最费时间的，但是根本没有这个必要。传20条数据以上通常都是要分页的，即使不序列化其数据量也是让客户难以忍受的。比如传20个1MB的图片给客户端，序不序列化都是不能忍受的。
ejb的调用就是基于rmi的调用。

非常感谢 liujiboy的回复请注意我在这儿提到了序列化，而不是使用数据传输这个字眼，因为序列化是很消耗cpu资源的，相对于对于上面提到的第二步，序列化对cpu的占用才是瓶颈(个人以为，请拍砖)，第三步，网络带宽才是应该主要考虑的对于第一步，我觉得很难下手调整的，ejb（cmp）,应该具有很强的缓存功能，总不能把数据处理都写在存储过程里把
对于servlet,她是http的门户，总不能把它拿掉吧，或者，把ejb拿掉，谁来做缓存呢？应该说四层结构还是有道理的，特别对于普通的broswer对数据量需求不大的情况可是并不是所有的应用都如此，如果有一个应用对数据的需求很大，那该如何处理呢？
可不可以实现这样一种机制，将webcontainer和ejb container和到一块去，它们之间通过引用调用(注意不是rmi), alienbat(死灵巫师)的回答很重要，我没有很仔细的看j2ee,希望这是可以实现的，能不能说的具体点？这样的话如果不考虑集群，只是简单的负载均衡，我想应该可以看作去掉第二步的序列化影响了
还有，如果我实现集群（j2ee层上的集群），是不是又要回到rmi的老路子上去，集群的服务器之间，好像也是通过该死的rmi吧（我对集群不甚了解，请拍砖）

第二步传递的是句柄而不是整个对象，同样的这也是设计的问题。如果真的把ejb中的所有数据提取到servlet中，也同样是不合理的做法。servlet只要1个图片，但是却把全部图片传回的情况，同样是不能容忍的。j2ee规范中确实可以让webcontainer和ejb container和到一块去，它们之间通过引用调用。具体的设置是在ejb的xml文件里面定义引用的描述（记得不太清楚，又好像是在web.xml，反正无所谓），具体的开发工具中都可以设置。查查资料吧。还有就是rmi的成本问题，应该不会高，序列化的对象也不可能都很大。目前业界通用的都是类似的方法，无论是微软的还是sun的在这方面都没得任何优势。

Weblogic，Websphere，JBoss这些应用服务器全部都是Web Container和
EJB Container集成在一起的，怎么会用到RMI来连接？你想多一台机器
做Web Container一来没必要，二来老板还心痛钱呢。

其实就是三层。
其实有本地方法，和rmi方法两种。
其实性能问题，是自己设计的问题。
其实.....
^_^

非常感谢liujiboy，我完全能够明白您说的意思，也确信一个良好的设计很重要。
的确，对于普通的企业应用来说，j2ee可能是非常合理的
其数据量可能是这样的，从底层逐渐递减，ejb完成关键的数据计算，servlet完成控制和数据的显示（如有不妥，非常欢迎指正）
   /    /web  / ejb  /   db
然而，也会有这样的应用
数据量可能是这样分布|  web container |
|  ejb           |
|  database      |

整个框架像一个数据的管道，ejb负责处理数据，处理完成后，交给webcontainer,由它传给browser,大家看到多余的环节了把，数据序列化经过经过webcontainer和ejb所在的机器，(rmi调用应该通常是能够容忍的，但是如果涉及到太多的对象的序列化，我想肯定对性能的影响会不小)，既然大家已经确认的告诉我servlet可以通过引用调用ejb,对我来说，应该是个好消息
但是，如果部署到不同的机器上，rmi不是又回来了吗？

我虽然没做过j2ee项目,但对lasersong2004(路宋)的观点不敢苟同
1。我私下里想，就算他们是集成到一起的，也不能就非常确认的说他们就用了本地调用(不要想当然嘛，好像微软就会这么搞，好想它的很多东西都在127.0.0.1上开了个端口，比如ie,做什么用的？)

2。j2ee号称是企业应用，我的理解，是为了应付非常巨型的应用，比如电信，门户网站，它们要求高稳定性和能够承载巨大的访问量和数据流量，如果老板不肯或者买不起服务器，我觉得推荐他用dotnet可能更合适一些
我认为j2ee含金量比较高的地方是应该是它的集群技术，以及cmp的缓存技术
(其实我是乱说的，我对j2ee不懂，欢迎来骂我)

罗嗦了这么多，有点烦我觉得j2ee像一根长长的管子，如果有太多的数据在里面传输，那将会有很大的损耗，如果给它把脖子缩一缩，叫ejb和servlet之间本地调用...
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
我错了，不在一台机器上怎么可能本地调用，看来这个坎是绕不过去喽谁有注意？

to blueye11(流浪的我) ,只是必要条件，应该说在一台机器才可能本地调用，本地调用应该在同一个jvm内，好像还没有哪个jvm能同时在两台机器上运行班

你说的这种大量数据的问题，j2ee本身是没有必然的解决方法的。还是要靠设计来解决。实在没得办法只能让用户等。好在大量数据的传输本身是可以优化的。
比如ejb传回1GB的数据，这1GB的数据是干吗的？是要之间传给用户吗？如果是要传给最终用户，那不就和网络下载差不多了吗？用户不等上几个小时才是怪事。如果是要进行处理，传个结果给用户，那么为什么不在ejb就处理呢？如果觉得ejb也慢，为什么不在数据库这一层处理呢？我曾经遇到这种情况需要对200多种商品进行计算，最后的方法是放到存储过程中，因为我只需要200个商品的计算结果，而不需要他们的其他数据。综上，我认为不仅j2ee，任何技术对这些应用的优化都不能自己完成，必须有赖于程序员的设计。分布式数据库就是一个明显的例子。

to liujiboy(liujiboy),我举一个简单的例子，
ejb根据数据库的内容，生成一幅或者几幅1--200k的图片，然后由servlet 把图片写的httpOutputSteam里面,这可以用来做报表，或是WMS(web map server),这种设计思路应该是没有问题吧？我们已经在ejb里生成了一幅图片，却又不得不将图片这个对象物理的挪移到servlet,这难道不是一种浪费吗？这是我主要关心的。
=========================================================================
我觉得已经大致知道应该怎么去做，过几天结贴，谢谢！

根据你的情况，如果觉得ejb耗费太大，就直接访问数据库吧。
我以前也有类似的情况。

调试易

j2ee初学者问题，赶紧进来领分了

解决方案 »