ejb可行性报告

02-11-04 yesky12
    

关于EJB五天报告

用EJB开发是有一定风险性的,但它的风险要小于CORBA2.4、DCOM+TMS。风险主要体现在效率上。例如连接上下

文和初始化Bean Home接口,在公司的机器上最小用2秒,最多用7

秒,方法调用用20豪秒以上,加上表示层和网络…。我写这份报告

的初衷是希望公司不会做出在程序开发中间或程序开发末尾改变开

发计划的决定,或者是因使用EJB带来的负面影响而感到措手不及。

以下所说的难免有错误和不足。因为在开始的几天里没有书和

时间太短。这当中也有一味追求高效和思考太片面而导致的错误和不

足。

EJB开发的整体优点和缺陷(个人观点):

EJB的开发周期相对C/S,B/S,假三层长:

导致EJB的开发周期相对长的原因在于它的松耦合性;对粒

度划分的级别;可扩展性;接口封装的完整、最小、高效、可扩展、

复用性;表示层的封装;整体的性能的提高和局部性能的取舍。这使

得考虑的问题很多。

EJB没有真正的负载平衡和故障恢复:

这里的故障恢复是当服务器出现故障时自动把负载转移到另

一台机器。

EJB没有真正的负载平衡,但它的容器功能在一定程度上可

以缓解,这要求硬件要好。或者由程序员通过JNDI完成负载平衡。

CORBA有真正的负载平衡和故障恢复

DCOM+TMS的负载平衡和故障恢复十分不好

并发问题:

EJB没有并发问题。

CORBA并发问题可以处理,但要编写大量代码。

DCOM+TMS 不太清楚。据说不好。

EJB指向同一实体Bean的问题:

实体Bean从属于会话Bean没有此问题。但其他情况很危险。

EJB十分先进是真正的分布式,这要求程序员的开发素质高:

EJB采用了十分先进的理念和技术,这要求程序员对面向对

象、程序设计有丰富的经验,如果有模式设计经验将畅通无阻。

EJB十分安全,灵活:

EJB做了很多工作,如果代码按照EJB的隐式书写规范(我感

觉EJB有一套书写规范但需要长期积累总结)将十分安全。EJB的组

件技术带来了很大的灵活性。但这些使EJB的性能下降。

EJB性能的提升(个人观点):

不要使用实体Bean的回调和相互调用。

EJB规范强烈建议不要使用实体Bean的回调和相互调用。

选择CMP实现

SUN公司的资深JAVA体系结构设计师强烈建议:

选择CMP实现:

…….

……我们应该选择CMP实现。

应该大量使用无状态会话Bean。

无状态会话Bean不维持会话状态,一旦完成了方法的调用,它就会服务与其他的客户。另外容器负责它的调度,这使它的一个

实例使用的范围更广。如果系统很忙,它不会频繁的创建和注销。

从而提高效率。

用户需要维持会话状态时,如果用无状态会话Bean可以解决尽量使用无状态会话Bean(方法不影响效率)。

基于上述应该使用无状态会话Bean。但是有时用户需要维持会话状态。状态会话Bean的状态保存在内存、硬盘、数据库中。内

存不安全。EJB对IO有很强的限制。最好是数据库,虽然数据库很

慢!无状态会话Bean一样可以访问数据库。所以应该尽量使用无状

态会话Bean。

对查询大量数据应该使用JDBC直接查询。

对查询大量数据应该使用会话Bean直接用JDBC查询,因为

要查询一万个记录要创建一万个实体Bean,这将会很慢。

会话Bean调用实体Bean的数量尽量少。

我对java的语言基础不好,我认为接口比函数的开销大很多,另外实体Bean的附加信息太多,为了节省内存开销,所以不应该调

用大量实体Bean。(内存对EJB服务器很重要,另外java的垃圾回收影响效率。)

不应该全部使用JDBC,不可抛弃实体Bean。

抛弃实体Bean等于抛弃了EJB。

所有Bean的接口尽量少。

Bean的接口尽量少,意味着调用少,意味着开销少。

业务流程的粒度尽量大。

业务流程的粒度尽量大,意味着调用少,意味着开销少。

使用会话Bean完成业务流,如果业务流太大,应该将集成部分挪到

servlet上(我想用servlet做封装)。

EJB的远程接口开销比本地接口开销大,并且实体Bean代表

着数据应将业务和数据分开。这些使实体Bean应该只有本地接口。

如果业务流太大,必然导致声明更多的Bean,促使Bean之间的

相互调用增多,EJB必然实例化更多的实例而导致服务器性能下降。

应该将集成部分挪到servlet上,但这样破坏了业务封装,和面向对象,也违反了EJB的初衷。但我认为是值得的。

EJB Bean的层次不应该多于三层。

尽量避免Bean之间的相互调用,应该将Bean的层次限制在三

层。

尽量不使用事务,使用事务时小心隔离级。

当发生事务并发时,大家强占共享资源,这时应当设立隔离级。

事务势必造成大量内存开销,所以在安全的前提下应该不使用

事务。

通过群集提高效率,但不易过多(书中的建议):

因为是软件开发完成后,通过部署完成,所以没有专门看。

体系结构设计:

EJB规范没有明确的一句话:

……

……可以证明的是,当在应用层使用EJB时,JSP和Servlet是用来作为表示层解

决方案的最为通用的技术。

让JSP、Servlet和EJB之间只见到数据。

EJB提供商务方法、业务逻辑和数据操作。

Servlet对商务方法集成(前面提到为什么),业务逻辑调用。

数据流的传递和接受。

JSP对数据流的传递和接受。并负责显示。

    

banq
2002-11-04 11:46

比较全面,有几点补充:

EJB是可以实现真正的负载平衡和故障恢复,也就是cluster,最近我正在研究cluster和并行计算。下图是Jboss的Cluster原理图

从中看到,建立在javagroups上可以对EJB和JNDI都提供负载平衡和故障恢复功能。

开发J2EE一定尽量不要用粘性stick技术,这样不利于集群,比如数据库访问尽量使用CMP 这样,这些CMP就可以参与cluster.

mdwolf
2002-11-04 13:37

/***********************

尽量不使用事务,使用事务时小心隔离级。

当发生事务并发时,大家强占共享资源,这时应当设立隔离级。

事务势必造成大量内存开销,所以在安全的前提下应该不使用

事务。

************************/

怎么可能在使用EJB的系统中,不使用事务???

这里事务的总结太少了.........

能否再提供点事务处理的建议呢?

iceant
2002-11-04 19:36

EJB 的应用都不多,做到 Cluster 这一级的,就更少了.

电信行业还是 CORBA 老大.

我当初想搞 EJB_over_CORBA, 就是因为 EJB 开发简单(相对CORBA来说),前端 CORBA 通信协议,后端 EJB 事务支持. 想起来就让人心动,任何语言都可以调用 EJB。

我就是因为在 OpenEJB 里,第一个让 EJB_over_CORBA 运行起来,所以才上了 contributor list.

哎,可惜,应用机会太少,很难搞起来啦。

banq
2002-11-05 09:22

是这样,因为目前我在一家Internet手机游戏公司工作,所以需要支持10万人同时在线,再也不能走联众那种一台服务器一个游戏屋的概念了,虽然P2P是手机游戏的未来,但是将P2p概念容于J2EE 线程 一起,我想基于服务器端的java游戏应该不错,目前我们已经取得第一步成功了。

2Go 1 2 下一页