ejb可行性报告

关于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对数据流的传递和接受。并负责显示。

比较全面,有几点补充:

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

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

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


/***********************
尽量不使用事务,使用事务时小心隔离级。
当发生事务并发时,大家强占共享资源,这时应当设立隔离级。
事务势必造成大量内存开销,所以在安全的前提下应该不使用
事务。
************************/
怎么可能在使用EJB的系统中,不使用事务???
这里事务的总结太少了.........
能否再提供点事务处理的建议呢?

EJB 的应用都不多,做到 Cluster 这一级的,就更少了.
电信行业还是 CORBA 老大.
我当初想搞 EJB_over_CORBA, 就是因为 EJB 开发简单(相对CORBA来说),前端 CORBA 通信协议,后端 EJB 事务支持. 想起来就让人心动,任何语言都可以调用 EJB。
我就是因为在 OpenEJB 里,第一个让 EJB_over_CORBA 运行起来,所以才上了 contributor list.
哎,可惜,应用机会太少,很难搞起来啦。

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

啥是P2P?

嗯? 我始终没弄明白,你说的 J2EE 线程是指什么?
And,
据我了解,对于Mobile Game(MG),服务器端用什么技术好像不是很重要。
有人用 ASP/PHP/JSP/Servlet/CGI 在做。
其根本就是协议的应用,现在好像没有一个标准的 MG 通信协议标准(希望以后会有)。
也就是说终端没有一个标准的专门为游戏而设的标准。那么,你用什么来让游戏运行得更好,支持的终端最多呢?
有些游戏就是用 SMS 协议来做。即然是 SMS,那只要从服务器端返回的是PS能接收和解析的信息就行了,用不用 J2EE 都无所谓.

不知道 GSM 的网上应用能不能做到,接收的信息带背景音乐,带图片。就像我们在收邮件一样,一打开信息,就可以自动播放背景音乐,可以看到背景图片.(据我所知,wap 好像没法做到.)

最好这些图片不用下载到本机,可以是 Web 上的一个 url, 手机能自动解析收到的信息,并向服务器请求图片数据.