发帖    主题    评论    推荐    标签    作者    订阅    查搜    注册   登陆   关注
 
面向对象 设计模式 领域驱动设计 企业架构 框架 开发教程 微服务 CQRS 扩展性 并发编程 事件溯源 分布式 SOA
1 2 下一页 Go 2

ejb可行性报告

    
2002-11-04 11:25
赞助商链接

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

2002-11-04 11:46

比较全面,有几点补充:

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


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

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


2002-11-04 13:37

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

2002-11-04 19:36

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

2002-11-05 09:22

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

2Go 1 2 下一页

赞助商链接

赞助商链接

返回顶部

移动版 关于本站 使用帮助 联系管理员 最佳分辨率1366x768
OpenSource JIVEJDON Powered by JdonFramework Code © 2002-20 jdon.com