从web container 到ejb container的调用是怎么样的?用rmi吗?不断序列化对象会不会影响性能?谁能够详细将一下?
2 偶实在是太懒,对sun的petstore看不进去,用jbuilder打开它带的例子,看ejb的实现怎么都是一堆接口,没找到实现啊,难道写ejb就是写一堆接口?不懂了
37 个解决方案
#1
web container,ejb container是在同一个层次上的。j2ee app。
如果是使用ejb,当然要用到rmi的,对性能影响肯定是有的。
从你的问题来看: petstore目前还不适合你看。先看些基础的东西吧。
如果是使用ejb,当然要用到rmi的,对性能影响肯定是有的。
从你的问题来看: petstore目前还不适合你看。先看些基础的东西吧。
#2
1。web container调用EJB是通过RMI调用。不过如果web container和EJB container是同一个服务器实例的话,可以通过本地接口调用而不是RMI。
2。同意楼上的。不要浮躁。
2。同意楼上的。不要浮躁。
#3
学习中,观注中
upupupupppupupupuppupupupppu
upupupupppupupupuppupupupppu
#4
j2ee的四层对应实际就是一个三层。web container 和ejb container可以驻留在同一个应用服务器上面,可以像本地一样访问。使用rmi确实需要序列化对象,但是并非所有的都需要。网络传输的代价并不高。这种代价相对于以前的两层在开发中带来的问题还是相当值得的。并且传输的数据量远比下载一个页面小,web container 和ejb container之间通常也是高速局域网(有的比本地硬盘都快)
关于你的第二个问题,建议你直接去看书。只告诉你EJB的接口和实现肯定在petstore中有。
关于你的第二个问题,建议你直接去看书。只告诉你EJB的接口和实现肯定在petstore中有。
#5
1. 通过JNDI API来查找EJB的本地接口对象,通过找到的对象创建bean实例,然后调用其方法。序列化是容器掌管的,相信专家。
2. 有实现啊,当然有啦。一般命名规范是这样的远程接口如果叫AaaBbb,bean的实现类就叫AaaBbbBean,本地接口就叫AaaBbbHome。运行的时候容器还会自动生成一些类。PetStore挺深的,不要急着看,慢慢来。
2. 有实现啊,当然有啦。一般命名规范是这样的远程接口如果叫AaaBbb,bean的实现类就叫AaaBbbBean,本地接口就叫AaaBbbHome。运行的时候容器还会自动生成一些类。PetStore挺深的,不要急着看,慢慢来。
#6
1. 通过JNDI API来查找EJB的本地接口对象,通过找到的对象创建bean实例,然后调用其方法。序列化是容器掌管的,相信专家。
2. 有实现啊,当然有啦。一般命名规范是这样的远程接口如果叫AaaBbb,bean的实现类就叫AaaBbbBean,本地接口就叫AaaBbbHome。运行的时候容器还会自动生成一些类。PetStore挺深的,不要急着看,慢慢来。
2. 有实现啊,当然有啦。一般命名规范是这样的远程接口如果叫AaaBbb,bean的实现类就叫AaaBbbBean,本地接口就叫AaaBbbHome。运行的时候容器还会自动生成一些类。PetStore挺深的,不要急着看,慢慢来。
#7
学习中
#8
学习中
#9
继续>>>>>>>>>>>>>>>
#10
多谢各位的回复,
相信 如果把web容器和ejb容器部属到不同的机器,类似rmi调用是很难避免的,我想确认,它们是不是真的使用了rmi调用?还是使用了类似的其他技术?
本来,大部分应用,像ejb只是产生计算结果的话,rmi序列化的损耗可以忽略不记,但是,也有这样一些应用,它们通过http协议,客户端applet需要大量的数据,这样的话
1。数据通过 jdbc从数据库序列化到ejb
2.(ejb处理以后)从ejb序列化到servlet
3.从servlet序列化到applet
这样一来,很多步骤,比如说第二步,实在是看起来多余啊,数据大的话,损耗很大啊
当然,applet通过rmi调用ejb好想也是可以的,但是rmi协议不如http这样普遍啊,很多防火墙会凤吊这个端口,不能适应大众啊
相信 如果把web容器和ejb容器部属到不同的机器,类似rmi调用是很难避免的,我想确认,它们是不是真的使用了rmi调用?还是使用了类似的其他技术?
本来,大部分应用,像ejb只是产生计算结果的话,rmi序列化的损耗可以忽略不记,但是,也有这样一些应用,它们通过http协议,客户端applet需要大量的数据,这样的话
1。数据通过 jdbc从数据库序列化到ejb
2.(ejb处理以后)从ejb序列化到servlet
3.从servlet序列化到applet
这样一来,很多步骤,比如说第二步,实在是看起来多余啊,数据大的话,损耗很大啊
当然,applet通过rmi调用ejb好想也是可以的,但是rmi协议不如http这样普遍啊,很多防火墙会凤吊这个端口,不能适应大众啊
#11
不知道你怎么需要传这么多数据。这是你设计的问题。
其中第一步和第二步是可以忍受的,而且通常是很快的。比如数据库服务器和应用服务器、web服务器之间以1000M网卡连接。1000M网卡的速度比本地硬盘都快。
第3步是最费时间的,但是根本没有这个必要。传20条数据以上通常都是要分页的,即使不序列化其数据量也是让客户难以忍受的。比如传20个1MB的图片给客户端,序不序列化都是不能忍受的。
ejb的调用就是基于rmi的调用。
其中第一步和第二步是可以忍受的,而且通常是很快的。比如数据库服务器和应用服务器、web服务器之间以1000M网卡连接。1000M网卡的速度比本地硬盘都快。
第3步是最费时间的,但是根本没有这个必要。传20条数据以上通常都是要分页的,即使不序列化其数据量也是让客户难以忍受的。比如传20个1MB的图片给客户端,序不序列化都是不能忍受的。
ejb的调用就是基于rmi的调用。
#12
学.....
#13
学习中
#14
〉〉〉〉〉〉〉〉〉〉〉〉〉>
#15
〉〉
#16
非常感谢 liujiboy的回复
请注意我在这儿提到了序列化,而不是使用数据传输这个字眼,因为序列化是很消耗cpu资源的,相对于对于上面提到的第二步,序列化对cpu的占用才是瓶颈(个人以为,请拍砖),第三步,网络带宽才是应该主要考虑的
对于第一步,我觉得很难下手调整的,ejb(cmp),应该具有很强的缓存功能,总不能把数据处理都写在存储过程里把
对于servlet,她是http的门户,总不能把它拿掉吧,或者,把ejb拿掉,谁来做缓存呢?应该说四层结构还是有道理的,特别对于普通的broswer对数据量需求不大的情况
可是并不是所有的应用都如此,如果有一个应用对数据的需求很大,那该如何处理呢?
可不可以实现这样一种机制,将webcontainer和ejb container和到一块去,它们之间通过引用调用(注意不是rmi), alienbat(死灵巫师)的回答很重要,我没有很仔细的看j2ee,希望这是可以实现的,能不能说的具体点?这样的话如果不考虑集群,只是简单的负载均衡,我想应该可以看作去掉第二步的序列化影响了
还有,如果我实现集群(j2ee层上的集群),是不是又要回到rmi的老路子上去,集群的服务器之间,好像也是通过该死的rmi吧(我对集群不甚了解,请拍砖)
请注意我在这儿提到了序列化,而不是使用数据传输这个字眼,因为序列化是很消耗cpu资源的,相对于对于上面提到的第二步,序列化对cpu的占用才是瓶颈(个人以为,请拍砖),第三步,网络带宽才是应该主要考虑的
对于第一步,我觉得很难下手调整的,ejb(cmp),应该具有很强的缓存功能,总不能把数据处理都写在存储过程里把
对于servlet,她是http的门户,总不能把它拿掉吧,或者,把ejb拿掉,谁来做缓存呢?应该说四层结构还是有道理的,特别对于普通的broswer对数据量需求不大的情况
可是并不是所有的应用都如此,如果有一个应用对数据的需求很大,那该如何处理呢?
可不可以实现这样一种机制,将webcontainer和ejb container和到一块去,它们之间通过引用调用(注意不是rmi), alienbat(死灵巫师)的回答很重要,我没有很仔细的看j2ee,希望这是可以实现的,能不能说的具体点?这样的话如果不考虑集群,只是简单的负载均衡,我想应该可以看作去掉第二步的序列化影响了
还有,如果我实现集群(j2ee层上的集群),是不是又要回到rmi的老路子上去,集群的服务器之间,好像也是通过该死的rmi吧(我对集群不甚了解,请拍砖)
#17
正在研究中...............
#18
第二步传递的是句柄而不是整个对象,同样的这也是设计的问题。如果真的把ejb中的所有数据提取到servlet中,也同样是不合理的做法。servlet只要1个图片,但是却把全部图片传回的情况,同样是不能容忍的。
j2ee规范中确实可以让webcontainer和ejb container和到一块去,它们之间通过引用调用。具体的设置是在ejb的xml文件里面定义引用的描述(记得不太清楚,又好像是在web.xml,反正无所谓),具体的开发工具中都可以设置。查查资料吧。
还有就是rmi的成本问题,应该不会高,序列化的对象也不可能都很大。目前业界通用的都是类似的方法,无论是微软的还是sun的在这方面都没得任何优势。
j2ee规范中确实可以让webcontainer和ejb container和到一块去,它们之间通过引用调用。具体的设置是在ejb的xml文件里面定义引用的描述(记得不太清楚,又好像是在web.xml,反正无所谓),具体的开发工具中都可以设置。查查资料吧。
还有就是rmi的成本问题,应该不会高,序列化的对象也不可能都很大。目前业界通用的都是类似的方法,无论是微软的还是sun的在这方面都没得任何优势。
#19
Weblogic,Websphere,JBoss这些应用服务器全部都是Web Container和
EJB Container集成在一起的,怎么会用到RMI来连接?你想多一台机器
做Web Container一来没必要,二来老板还心痛钱呢。
EJB Container集成在一起的,怎么会用到RMI来连接?你想多一台机器
做Web Container一来没必要,二来老板还心痛钱呢。
#20
来了
#21
收藏。
#22
其实就是三层。
其实有本地方法,和rmi方法两种。
其实性能问题,是自己设计的问题。
其实.....
^_^
其实有本地方法,和rmi方法两种。
其实性能问题,是自己设计的问题。
其实.....
^_^
#23
我也收着!
#24
关注呀
#25
关注
#26
〉〉〉
#27
非常感谢liujiboy,我完全能够明白您说的意思,也确信一个良好的设计很重要。
的确,对于普通的企业应用来说,j2ee可能是非常合理的
其数据量可能是这样的,从底层逐渐递减,ejb完成关键的数据计算,servlet完成控制和数据的显示(如有不妥,非常欢迎指正)
/ /web / ejb / db
然而,也会有这样的应用
数据量可能是这样分布
| web container |
| ejb |
| database |
整个框架像一个数据的管道,ejb负责处理数据,处理完成后,交给webcontainer,由它传给browser,大家看到多余的环节了把,数据序列化经过经过webcontainer和ejb所在的机器,(rmi调用应该通常是能够容忍的,但是如果涉及到太多的对象的序列化,我想肯定对性能的影响会不小),既然大家已经确认的告诉我servlet可以通过引用调用ejb,对我来说,应该是个好消息
但是,如果部署到不同的机器上,rmi不是又回来了吗?
的确,对于普通的企业应用来说,j2ee可能是非常合理的
其数据量可能是这样的,从底层逐渐递减,ejb完成关键的数据计算,servlet完成控制和数据的显示(如有不妥,非常欢迎指正)
/ /web / ejb / db
然而,也会有这样的应用
数据量可能是这样分布
| web container |
| ejb |
| database |
整个框架像一个数据的管道,ejb负责处理数据,处理完成后,交给webcontainer,由它传给browser,大家看到多余的环节了把,数据序列化经过经过webcontainer和ejb所在的机器,(rmi调用应该通常是能够容忍的,但是如果涉及到太多的对象的序列化,我想肯定对性能的影响会不小),既然大家已经确认的告诉我servlet可以通过引用调用ejb,对我来说,应该是个好消息
但是,如果部署到不同的机器上,rmi不是又回来了吗?
#28
我虽然没做过j2ee项目,但对lasersong2004(路宋)的观点不敢苟同
1。我私下里想,就算他们是集成到一起的,也不能就非常确认的说他们就用了本地调用(不要想当然嘛,好像微软就会这么搞,好想它的很多东西都在127.0.0.1上开了个端口,比如ie,做什么用的?)
1。我私下里想,就算他们是集成到一起的,也不能就非常确认的说他们就用了本地调用(不要想当然嘛,好像微软就会这么搞,好想它的很多东西都在127.0.0.1上开了个端口,比如ie,做什么用的?)
#29
up
#30
2。j2ee号称是企业应用,我的理解,是为了应付非常巨型的应用,比如电信,门户网站,它们要求高稳定性和能够承载巨大的访问量和数据流量,如果老板不肯或者买不起服务器,我觉得推荐他用dotnet可能更合适一些
我认为j2ee含金量比较高的地方是应该是它的集群技术,以及cmp的缓存技术
(其实我是乱说的,我对j2ee不懂,欢迎来骂我)
我认为j2ee含金量比较高的地方是应该是它的集群技术,以及cmp的缓存技术
(其实我是乱说的,我对j2ee不懂,欢迎来骂我)
#31
罗嗦了这么多,有点烦
我觉得j2ee像一根长长的管子,如果有太多的数据在里面传输,那将会有很大的损耗,如果给它把脖子缩一缩,叫ejb和servlet之间本地调用...
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
我错了,不在一台机器上怎么可能本地调用,看来这个坎是绕不过去喽
谁有注意?
我觉得j2ee像一根长长的管子,如果有太多的数据在里面传输,那将会有很大的损耗,如果给它把脖子缩一缩,叫ejb和servlet之间本地调用...
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
我错了,不在一台机器上怎么可能本地调用,看来这个坎是绕不过去喽
谁有注意?
#32
本地调用就是在一台机器?
#33
to blueye11(流浪的我) ,只是必要条件,应该说在一台机器才可能本地调用,本地调用应该在同一个jvm内,好像还没有哪个jvm能同时在两台机器上运行班
#34
你说的这种大量数据的问题,j2ee本身是没有必然的解决方法的。还是要靠设计来解决。实在没得办法只能让用户等。好在大量数据的传输本身是可以优化的。
比如ejb传回1GB的数据,这1GB的数据是干吗的?是要之间传给用户吗?如果是要传给最终用户,那不就和网络下载差不多了吗?用户不等上几个小时才是怪事。
如果是要进行处理,传个结果给用户,那么为什么不在ejb就处理呢?如果觉得ejb也慢,为什么不在数据库这一层处理呢?
我曾经遇到这种情况需要对200多种商品进行计算,最后的方法是放到存储过程中,因为我只需要200个商品的计算结果,而不需要他们的其他数据。
综上,我认为不仅j2ee,任何技术对这些应用的优化都不能自己完成,必须有赖于程序员的设计。分布式数据库就是一个明显的例子。
比如ejb传回1GB的数据,这1GB的数据是干吗的?是要之间传给用户吗?如果是要传给最终用户,那不就和网络下载差不多了吗?用户不等上几个小时才是怪事。
如果是要进行处理,传个结果给用户,那么为什么不在ejb就处理呢?如果觉得ejb也慢,为什么不在数据库这一层处理呢?
我曾经遇到这种情况需要对200多种商品进行计算,最后的方法是放到存储过程中,因为我只需要200个商品的计算结果,而不需要他们的其他数据。
综上,我认为不仅j2ee,任何技术对这些应用的优化都不能自己完成,必须有赖于程序员的设计。分布式数据库就是一个明显的例子。
#35
>>
#36
to liujiboy(liujiboy),我举一个简单的例子,
ejb根据数据库的内容,生成一幅或者几幅1--200k的图片,然后由servlet 把图片写的httpOutputSteam里面,这可以用来做报表,或是WMS(web map server),这种设计思路应该是没有问题吧?
我们已经在ejb里生成了一幅图片,却又不得不将图片这个对象物理的挪移到servlet,这难道不是一种浪费吗?
这是我主要关心的。
=========================================================================
我觉得已经大致知道应该怎么去做,过几天结贴,谢谢!
ejb根据数据库的内容,生成一幅或者几幅1--200k的图片,然后由servlet 把图片写的httpOutputSteam里面,这可以用来做报表,或是WMS(web map server),这种设计思路应该是没有问题吧?
我们已经在ejb里生成了一幅图片,却又不得不将图片这个对象物理的挪移到servlet,这难道不是一种浪费吗?
这是我主要关心的。
=========================================================================
我觉得已经大致知道应该怎么去做,过几天结贴,谢谢!
#37
根据你的情况,如果觉得ejb耗费太大,就直接访问数据库吧。
我以前也有类似的情况。
我以前也有类似的情况。
#1
web container,ejb container是在同一个层次上的。j2ee app。
如果是使用ejb,当然要用到rmi的,对性能影响肯定是有的。
从你的问题来看: petstore目前还不适合你看。先看些基础的东西吧。
如果是使用ejb,当然要用到rmi的,对性能影响肯定是有的。
从你的问题来看: petstore目前还不适合你看。先看些基础的东西吧。
#2
1。web container调用EJB是通过RMI调用。不过如果web container和EJB container是同一个服务器实例的话,可以通过本地接口调用而不是RMI。
2。同意楼上的。不要浮躁。
2。同意楼上的。不要浮躁。
#3
学习中,观注中
upupupupppupupupuppupupupppu
upupupupppupupupuppupupupppu
#4
j2ee的四层对应实际就是一个三层。web container 和ejb container可以驻留在同一个应用服务器上面,可以像本地一样访问。使用rmi确实需要序列化对象,但是并非所有的都需要。网络传输的代价并不高。这种代价相对于以前的两层在开发中带来的问题还是相当值得的。并且传输的数据量远比下载一个页面小,web container 和ejb container之间通常也是高速局域网(有的比本地硬盘都快)
关于你的第二个问题,建议你直接去看书。只告诉你EJB的接口和实现肯定在petstore中有。
关于你的第二个问题,建议你直接去看书。只告诉你EJB的接口和实现肯定在petstore中有。
#5
1. 通过JNDI API来查找EJB的本地接口对象,通过找到的对象创建bean实例,然后调用其方法。序列化是容器掌管的,相信专家。
2. 有实现啊,当然有啦。一般命名规范是这样的远程接口如果叫AaaBbb,bean的实现类就叫AaaBbbBean,本地接口就叫AaaBbbHome。运行的时候容器还会自动生成一些类。PetStore挺深的,不要急着看,慢慢来。
2. 有实现啊,当然有啦。一般命名规范是这样的远程接口如果叫AaaBbb,bean的实现类就叫AaaBbbBean,本地接口就叫AaaBbbHome。运行的时候容器还会自动生成一些类。PetStore挺深的,不要急着看,慢慢来。
#6
1. 通过JNDI API来查找EJB的本地接口对象,通过找到的对象创建bean实例,然后调用其方法。序列化是容器掌管的,相信专家。
2. 有实现啊,当然有啦。一般命名规范是这样的远程接口如果叫AaaBbb,bean的实现类就叫AaaBbbBean,本地接口就叫AaaBbbHome。运行的时候容器还会自动生成一些类。PetStore挺深的,不要急着看,慢慢来。
2. 有实现啊,当然有啦。一般命名规范是这样的远程接口如果叫AaaBbb,bean的实现类就叫AaaBbbBean,本地接口就叫AaaBbbHome。运行的时候容器还会自动生成一些类。PetStore挺深的,不要急着看,慢慢来。
#7
学习中
#8
学习中
#9
继续>>>>>>>>>>>>>>>
#10
多谢各位的回复,
相信 如果把web容器和ejb容器部属到不同的机器,类似rmi调用是很难避免的,我想确认,它们是不是真的使用了rmi调用?还是使用了类似的其他技术?
本来,大部分应用,像ejb只是产生计算结果的话,rmi序列化的损耗可以忽略不记,但是,也有这样一些应用,它们通过http协议,客户端applet需要大量的数据,这样的话
1。数据通过 jdbc从数据库序列化到ejb
2.(ejb处理以后)从ejb序列化到servlet
3.从servlet序列化到applet
这样一来,很多步骤,比如说第二步,实在是看起来多余啊,数据大的话,损耗很大啊
当然,applet通过rmi调用ejb好想也是可以的,但是rmi协议不如http这样普遍啊,很多防火墙会凤吊这个端口,不能适应大众啊
相信 如果把web容器和ejb容器部属到不同的机器,类似rmi调用是很难避免的,我想确认,它们是不是真的使用了rmi调用?还是使用了类似的其他技术?
本来,大部分应用,像ejb只是产生计算结果的话,rmi序列化的损耗可以忽略不记,但是,也有这样一些应用,它们通过http协议,客户端applet需要大量的数据,这样的话
1。数据通过 jdbc从数据库序列化到ejb
2.(ejb处理以后)从ejb序列化到servlet
3.从servlet序列化到applet
这样一来,很多步骤,比如说第二步,实在是看起来多余啊,数据大的话,损耗很大啊
当然,applet通过rmi调用ejb好想也是可以的,但是rmi协议不如http这样普遍啊,很多防火墙会凤吊这个端口,不能适应大众啊
#11
不知道你怎么需要传这么多数据。这是你设计的问题。
其中第一步和第二步是可以忍受的,而且通常是很快的。比如数据库服务器和应用服务器、web服务器之间以1000M网卡连接。1000M网卡的速度比本地硬盘都快。
第3步是最费时间的,但是根本没有这个必要。传20条数据以上通常都是要分页的,即使不序列化其数据量也是让客户难以忍受的。比如传20个1MB的图片给客户端,序不序列化都是不能忍受的。
ejb的调用就是基于rmi的调用。
其中第一步和第二步是可以忍受的,而且通常是很快的。比如数据库服务器和应用服务器、web服务器之间以1000M网卡连接。1000M网卡的速度比本地硬盘都快。
第3步是最费时间的,但是根本没有这个必要。传20条数据以上通常都是要分页的,即使不序列化其数据量也是让客户难以忍受的。比如传20个1MB的图片给客户端,序不序列化都是不能忍受的。
ejb的调用就是基于rmi的调用。
#12
学.....
#13
学习中
#14
〉〉〉〉〉〉〉〉〉〉〉〉〉>
#15
〉〉
#16
非常感谢 liujiboy的回复
请注意我在这儿提到了序列化,而不是使用数据传输这个字眼,因为序列化是很消耗cpu资源的,相对于对于上面提到的第二步,序列化对cpu的占用才是瓶颈(个人以为,请拍砖),第三步,网络带宽才是应该主要考虑的
对于第一步,我觉得很难下手调整的,ejb(cmp),应该具有很强的缓存功能,总不能把数据处理都写在存储过程里把
对于servlet,她是http的门户,总不能把它拿掉吧,或者,把ejb拿掉,谁来做缓存呢?应该说四层结构还是有道理的,特别对于普通的broswer对数据量需求不大的情况
可是并不是所有的应用都如此,如果有一个应用对数据的需求很大,那该如何处理呢?
可不可以实现这样一种机制,将webcontainer和ejb container和到一块去,它们之间通过引用调用(注意不是rmi), alienbat(死灵巫师)的回答很重要,我没有很仔细的看j2ee,希望这是可以实现的,能不能说的具体点?这样的话如果不考虑集群,只是简单的负载均衡,我想应该可以看作去掉第二步的序列化影响了
还有,如果我实现集群(j2ee层上的集群),是不是又要回到rmi的老路子上去,集群的服务器之间,好像也是通过该死的rmi吧(我对集群不甚了解,请拍砖)
请注意我在这儿提到了序列化,而不是使用数据传输这个字眼,因为序列化是很消耗cpu资源的,相对于对于上面提到的第二步,序列化对cpu的占用才是瓶颈(个人以为,请拍砖),第三步,网络带宽才是应该主要考虑的
对于第一步,我觉得很难下手调整的,ejb(cmp),应该具有很强的缓存功能,总不能把数据处理都写在存储过程里把
对于servlet,她是http的门户,总不能把它拿掉吧,或者,把ejb拿掉,谁来做缓存呢?应该说四层结构还是有道理的,特别对于普通的broswer对数据量需求不大的情况
可是并不是所有的应用都如此,如果有一个应用对数据的需求很大,那该如何处理呢?
可不可以实现这样一种机制,将webcontainer和ejb container和到一块去,它们之间通过引用调用(注意不是rmi), alienbat(死灵巫师)的回答很重要,我没有很仔细的看j2ee,希望这是可以实现的,能不能说的具体点?这样的话如果不考虑集群,只是简单的负载均衡,我想应该可以看作去掉第二步的序列化影响了
还有,如果我实现集群(j2ee层上的集群),是不是又要回到rmi的老路子上去,集群的服务器之间,好像也是通过该死的rmi吧(我对集群不甚了解,请拍砖)
#17
正在研究中...............
#18
第二步传递的是句柄而不是整个对象,同样的这也是设计的问题。如果真的把ejb中的所有数据提取到servlet中,也同样是不合理的做法。servlet只要1个图片,但是却把全部图片传回的情况,同样是不能容忍的。
j2ee规范中确实可以让webcontainer和ejb container和到一块去,它们之间通过引用调用。具体的设置是在ejb的xml文件里面定义引用的描述(记得不太清楚,又好像是在web.xml,反正无所谓),具体的开发工具中都可以设置。查查资料吧。
还有就是rmi的成本问题,应该不会高,序列化的对象也不可能都很大。目前业界通用的都是类似的方法,无论是微软的还是sun的在这方面都没得任何优势。
j2ee规范中确实可以让webcontainer和ejb container和到一块去,它们之间通过引用调用。具体的设置是在ejb的xml文件里面定义引用的描述(记得不太清楚,又好像是在web.xml,反正无所谓),具体的开发工具中都可以设置。查查资料吧。
还有就是rmi的成本问题,应该不会高,序列化的对象也不可能都很大。目前业界通用的都是类似的方法,无论是微软的还是sun的在这方面都没得任何优势。
#19
Weblogic,Websphere,JBoss这些应用服务器全部都是Web Container和
EJB Container集成在一起的,怎么会用到RMI来连接?你想多一台机器
做Web Container一来没必要,二来老板还心痛钱呢。
EJB Container集成在一起的,怎么会用到RMI来连接?你想多一台机器
做Web Container一来没必要,二来老板还心痛钱呢。
#20
来了
#21
收藏。
#22
其实就是三层。
其实有本地方法,和rmi方法两种。
其实性能问题,是自己设计的问题。
其实.....
^_^
其实有本地方法,和rmi方法两种。
其实性能问题,是自己设计的问题。
其实.....
^_^
#23
我也收着!
#24
关注呀
#25
关注
#26
〉〉〉
#27
非常感谢liujiboy,我完全能够明白您说的意思,也确信一个良好的设计很重要。
的确,对于普通的企业应用来说,j2ee可能是非常合理的
其数据量可能是这样的,从底层逐渐递减,ejb完成关键的数据计算,servlet完成控制和数据的显示(如有不妥,非常欢迎指正)
/ /web / ejb / db
然而,也会有这样的应用
数据量可能是这样分布
| web container |
| ejb |
| database |
整个框架像一个数据的管道,ejb负责处理数据,处理完成后,交给webcontainer,由它传给browser,大家看到多余的环节了把,数据序列化经过经过webcontainer和ejb所在的机器,(rmi调用应该通常是能够容忍的,但是如果涉及到太多的对象的序列化,我想肯定对性能的影响会不小),既然大家已经确认的告诉我servlet可以通过引用调用ejb,对我来说,应该是个好消息
但是,如果部署到不同的机器上,rmi不是又回来了吗?
的确,对于普通的企业应用来说,j2ee可能是非常合理的
其数据量可能是这样的,从底层逐渐递减,ejb完成关键的数据计算,servlet完成控制和数据的显示(如有不妥,非常欢迎指正)
/ /web / ejb / db
然而,也会有这样的应用
数据量可能是这样分布
| web container |
| ejb |
| database |
整个框架像一个数据的管道,ejb负责处理数据,处理完成后,交给webcontainer,由它传给browser,大家看到多余的环节了把,数据序列化经过经过webcontainer和ejb所在的机器,(rmi调用应该通常是能够容忍的,但是如果涉及到太多的对象的序列化,我想肯定对性能的影响会不小),既然大家已经确认的告诉我servlet可以通过引用调用ejb,对我来说,应该是个好消息
但是,如果部署到不同的机器上,rmi不是又回来了吗?
#28
我虽然没做过j2ee项目,但对lasersong2004(路宋)的观点不敢苟同
1。我私下里想,就算他们是集成到一起的,也不能就非常确认的说他们就用了本地调用(不要想当然嘛,好像微软就会这么搞,好想它的很多东西都在127.0.0.1上开了个端口,比如ie,做什么用的?)
1。我私下里想,就算他们是集成到一起的,也不能就非常确认的说他们就用了本地调用(不要想当然嘛,好像微软就会这么搞,好想它的很多东西都在127.0.0.1上开了个端口,比如ie,做什么用的?)
#29
up
#30
2。j2ee号称是企业应用,我的理解,是为了应付非常巨型的应用,比如电信,门户网站,它们要求高稳定性和能够承载巨大的访问量和数据流量,如果老板不肯或者买不起服务器,我觉得推荐他用dotnet可能更合适一些
我认为j2ee含金量比较高的地方是应该是它的集群技术,以及cmp的缓存技术
(其实我是乱说的,我对j2ee不懂,欢迎来骂我)
我认为j2ee含金量比较高的地方是应该是它的集群技术,以及cmp的缓存技术
(其实我是乱说的,我对j2ee不懂,欢迎来骂我)
#31
罗嗦了这么多,有点烦
我觉得j2ee像一根长长的管子,如果有太多的数据在里面传输,那将会有很大的损耗,如果给它把脖子缩一缩,叫ejb和servlet之间本地调用...
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
我错了,不在一台机器上怎么可能本地调用,看来这个坎是绕不过去喽
谁有注意?
我觉得j2ee像一根长长的管子,如果有太多的数据在里面传输,那将会有很大的损耗,如果给它把脖子缩一缩,叫ejb和servlet之间本地调用...
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
我错了,不在一台机器上怎么可能本地调用,看来这个坎是绕不过去喽
谁有注意?
#32
本地调用就是在一台机器?
#33
to blueye11(流浪的我) ,只是必要条件,应该说在一台机器才可能本地调用,本地调用应该在同一个jvm内,好像还没有哪个jvm能同时在两台机器上运行班
#34
你说的这种大量数据的问题,j2ee本身是没有必然的解决方法的。还是要靠设计来解决。实在没得办法只能让用户等。好在大量数据的传输本身是可以优化的。
比如ejb传回1GB的数据,这1GB的数据是干吗的?是要之间传给用户吗?如果是要传给最终用户,那不就和网络下载差不多了吗?用户不等上几个小时才是怪事。
如果是要进行处理,传个结果给用户,那么为什么不在ejb就处理呢?如果觉得ejb也慢,为什么不在数据库这一层处理呢?
我曾经遇到这种情况需要对200多种商品进行计算,最后的方法是放到存储过程中,因为我只需要200个商品的计算结果,而不需要他们的其他数据。
综上,我认为不仅j2ee,任何技术对这些应用的优化都不能自己完成,必须有赖于程序员的设计。分布式数据库就是一个明显的例子。
比如ejb传回1GB的数据,这1GB的数据是干吗的?是要之间传给用户吗?如果是要传给最终用户,那不就和网络下载差不多了吗?用户不等上几个小时才是怪事。
如果是要进行处理,传个结果给用户,那么为什么不在ejb就处理呢?如果觉得ejb也慢,为什么不在数据库这一层处理呢?
我曾经遇到这种情况需要对200多种商品进行计算,最后的方法是放到存储过程中,因为我只需要200个商品的计算结果,而不需要他们的其他数据。
综上,我认为不仅j2ee,任何技术对这些应用的优化都不能自己完成,必须有赖于程序员的设计。分布式数据库就是一个明显的例子。
#35
>>
#36
to liujiboy(liujiboy),我举一个简单的例子,
ejb根据数据库的内容,生成一幅或者几幅1--200k的图片,然后由servlet 把图片写的httpOutputSteam里面,这可以用来做报表,或是WMS(web map server),这种设计思路应该是没有问题吧?
我们已经在ejb里生成了一幅图片,却又不得不将图片这个对象物理的挪移到servlet,这难道不是一种浪费吗?
这是我主要关心的。
=========================================================================
我觉得已经大致知道应该怎么去做,过几天结贴,谢谢!
ejb根据数据库的内容,生成一幅或者几幅1--200k的图片,然后由servlet 把图片写的httpOutputSteam里面,这可以用来做报表,或是WMS(web map server),这种设计思路应该是没有问题吧?
我们已经在ejb里生成了一幅图片,却又不得不将图片这个对象物理的挪移到servlet,这难道不是一种浪费吗?
这是我主要关心的。
=========================================================================
我觉得已经大致知道应该怎么去做,过几天结贴,谢谢!
#37
根据你的情况,如果觉得ejb耗费太大,就直接访问数据库吧。
我以前也有类似的情况。
我以前也有类似的情况。