既然你没经验,最好是听技术顾问的。EJB最大的问题还不是效率,而是巨大的复杂度。EJB提供了业务层及持久层的一揽子解决方案,能够为J2EE application提供强大的分布式能力。在entity bean这里,这种能力主要体现为分布式事务管理和负载均衡。这是EJB最大的优点,也是它最大的弱点:对于没有分布式需求的application,EJB增加了极大的、而且是毫无价值的复杂度。如果你们的application没有打算做成分布式的,EJB绝对会是一个不必要的负担。实际情况正如这位顾问所说,国内企业很少有用EJB做项目的(做产品的可能会用到),O/R mapping完全可以用Hibernate之类轻量级框架实现,session bean在非分布的application中就更是毫无价值可言,基于POJO的facade加上自定义的事务机制(或者是JTA)就可以取代它。对于非分布的中小型项目,EJB不可能减轻开发负担,同时也不可能提供比基于Java Bean的ORM更好的复用性。不过这位顾问说的性能实验恐怕多少有点问题。几十个entity bean class是不可能把服务器跑死的,哪怕你只是用PC Server。也许他是想吓吓你们,也许是因为他的系统没有tuning到很好的状态。
解决方案 »
- 在form表单做上传,用enctype="multipart/form-data" ,request.getParameter()得不到值
- 请问关于calendar的问题
- Exception Processing ErrorPage[errorCode=404, location=/WEB-INF/jsp/errors/404.jsp]
- ◆相当费解◆:通过Struts2标签打印的数据中的HTML标签不能被解析
- JSF验证信息为何前面有一串代码
- ActiveX插件的运用问题?请大家看看!
- lucene 入门问题,祝好心人平安!
- 我要用JDBC把整个数据库的表复制到另一个数据库中去
- 在Struts的struts-config.xml中配置data-source的oracle连接?
- 凌晨2:54放分求解:weblogic7.0中启动的时候先读取那个文件呢?
- struts问题:如何实现修改功能?
- 如何使用SUN的J2EE演示程序Pet Store ?
有客户端又有服务器算不算分布式
Schlemiel(维特根斯坦的扇子) 能不能给我们举个分布式的例子
能将Session Bean、X Bean 做好的更少。
任何一个J2EE application必然是有client和server的。J2EE的“分布式”是指服务器端的distribution,也就是说在多台服务器(或者干脆就是服务器集群)上运行application。如果你熟悉Java Classloader就会知道,在集群上处理同步、缓存、事务之类的问题会很麻烦,甚至就是一个Singleton就能搞死你。所以EJB的存在是有其价值的。to minxlover(robert):
我想他说的“可扩展性”是指scalability,而我更强调extensibility——在我看来,如果满足了后者,前者可以相对容易地达到。再强大的服务器、再强大的技术,必定是有其负载极限的。虽然AIX小型机很强,如果并发过大,肯定就非要分布不可了,这时一个extensible的application会比较容易地获得scalability。
我看你应该从用户的角度出发,先度量一下常规的和极限的负载情况,再做决定。
j2ee的确有很多内容.只不过我个人很喜欢ejb.多谢提点.
你是对的。当scalability非常重要时,值得投入更大的复杂度去采用EJB。设计就是一个不断权衡的过程,扩展性和简单性之间的权衡只是一个方面。
其实在选择技术时,技术角度的考虑和心理角度的考虑同样存在着权衡。就像你所说的,你很喜欢EJB——如果作为技术的选择者,我会希望手下的开发者都没有这样的偏爱,仅仅从技术本身的适用性来考虑问题。但显然这是不可能的,如果他们谁都不偏爱哪一项技术,可以想象他们的技术水平(和热情)也不会很高。所以这也是个相当重要的权衡:选择最合适当前环境的技术,还是选择团队最愿意用的技术?尤其当你已经拥有一支“胶凝团队”,不太愿意换血的时候。
有些情况的确如你所说.呵呵,这么晚了大家还在研究技术.注意身体啊...
从个人角度来说,我喜欢用EJB,JDBC太简单了
PIII 933MHz
CPU with 1GB SDRAM, and two Quantum Atlas 9GB
10,000rpm Ultra160 SCSI disk drives. A number of PII 450MHz
machines run the client emulation software. We use enough client
emulation machines to make sure that the clients do not become a
bottleneck in any of our experiments. All machines are connected
through a switched 100Mbps Ethernet LAN.
app server用1
1jboss2.4(还有3.0)Dynamic proxy based container
2jonas2.5 Pre-compiled approach测试用的example是一个拍卖网站。
用了6不同种设计风格的实现。代码的规模如下
0 纯servlet实现( 数据库操作在servlet中完成)。 25个class和4590行代码
1 servlet+session bean(session bean封装数据库操作,只用到app的pooling和事物服务)。76个class和8000行代码
2DAO separation with Entity Beans CMP 。63个class和10760行代码
3DAO separation with Entity Beans BMP。 25个class和4590行代码
4EJB 2.0 local interfaces。 113个class和13795行代码
5Session facade。 107个class和13440行代码
测试结果:
0的速度最快,1的速度和0接近。。可以在1200个用户连接下每分钟执行一万次的响应,纯servlet实现可以达到12000次。
(interactions per minute )
一旦用到bmp或cmp,速度就慢了。最好的EJB 2.0 local方式只能在460个用户连接下每分钟执行不到4500次的响应
而bmp只能在220个用户连接下每分钟执行不到2000次的响应,用户再多,interactions per minute也高不了(还会下降)。呵呵,没什么好说的了,使用entity bean,代码量大,速度也够慢,好郁闷。。
2002年测试的东西,不知道现在怎么样了。。微软叫嚣.net的pet sore有ejb实现的10倍速度是有可能的
要追求速度,除了servlet,就只用无状态session bean,
这和com+组件的设计原则(使用无状态对象和存储过程)是一样的。
java的stateless session beans的效率比com+的无状态对象的效率要高一些。
大部分java app server是 1个stateless session beans服务所有的client。
com+是1个无状态对象服务一个client。
大多数时候,当你抱怨一种技术时,请先看看自己是不是非常愚蠢地误用了它。
对一个Jsp用那个EntityBean,我想这本身的设计就有问题,不是我们有了EntityBean,为一个实体都要写一个Bean来
微软当然是自卖自夸,误导听众。。如果
http://www.cs.rice.edu/CS/Systems/DynaServer/perf_scalability_ejb.pdf
是可信的话,
那么应该是:
在j2ee的各种设计风格中:
servlet(还有statless session bean)比ejb“节省2/3程序代码、承载六倍的使用者的功能,效能快?倍(六倍的使用者和6倍的响应速度,怎么算啊?36倍吗?)”
本人前段时间“有幸”参与了一个比较大的J2EE日本外包项目,
采用日本某知名大企业自行开发的一套MVC框架,
JSP+Servlet+SessionBean(CMP), Server使用的是WEB Logic,数据库为Oracle 9i.
该项目是为一个日本的县级政府机关管理其公共事业使用的,如县内公共事业工程的竞标管理,
预算管理,工程的实际进度管理(我接触到的部分),整个项目的确非常庞大,是我接触过的最大的项目。
由于项目的显示层采用了JSP代码与HTML代码分离的技术,即在JSP中将HTML模板文件读入,然后进行特定标志的替换,如果数据查询的结果行数非常多,那么在生成页面时就会产生大量的文件IO操作因为显示在页面上的每一条纪录都是一个HTML模板,而搞笑的是只要有一条纪录就要将模板文件读入一次,进行一次IO操作,困惑。可能是机器配置不行吧,实际编码调试过程中总是非常慢,很担心实际的使用效果。然而经“高人”指点,我等的顾虑实在是多余,因为整个系统虽然大,但是真正的用户也就是办公室里的几个人而已。当询问既然如此,有必要使用EJB时,得到的答复根本不是技术性的,而是:
这样日本人可以从日本人那里赚到更多得Money!!!!!
从技术的角度来讲,我们考虑的是开发的高效项目以后的可扩展性等,
但是从经营的角度来讲,可能考虑的是更多的利润,
其实有很多项目最终采取的开发方式并非是技术上最高效的,
至少日本人的很多项目就是如此,他们特别喜欢赶新潮,
我想这一点也不能忽视!
不错用了j2ee,尤其是EJB来说可以圈得很多的钱,但有多少是自己的呢?
以前我们做产品和项目时都要用EntityBean,效率不高是无可厚非的,现在我们主SessionBean加自己的数据处理层
看你们如何考虑了,采用了好的架构对系统维护更新等有好处
也许同时降低了性能,其中谁好谁坏要看实际用途
如果系统要每天支撑几百万访问,性能是首先要考虑的
如果每天就几个人办公使用,多些考虑设计,采用先进架构
大项目若是用ejb他们的服务器会差吗?
损失点速度换来扩展性,还是值得的!
好的架构和设计与好的性能并不矛盾,很多时候前者是后者的先决条件,因为良好的设计使你更容易profiling和tuning。另一方面,架构和设计是否良好,并不取决于是否采用某种技术,那基本上纯粹是一个OO的问题。优秀的J2EE应用首先必须是优秀的Java应用,具体的技术应该是第二位考虑的。
ejb速度慢只是相对jdbc来说的.并不会慢的象你所说的那么慢.在我测试server上ejb查找,插入记录只需要0.0几秒的时间.