学习了EJB有一段时间，但觉得系统部分都由容器实现了，我们只用关心业务逻辑。还请前辈讲讲一些我们没有发现的东西，要注意些什么，有什么难点呢？请指教了，谢谢。

我觉得难点是部属和控制EJB

这个帖子好像见过啊！？

要注意的是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对数据流的传递和接受。并负责显示。
                             
                                           
                                       长春中通科技
                                             范大为
                                        fdw_009@163.com