论文部分内容阅读
中图分类号：TP 文献标识码：A 文章编号：1009-914X（2013）23-583-01
EJB是sun的服务器端组件模型，设计目标与核心应用是部署分布式应用程序。凭借java跨平台的优势，用EJB技术部署的分布式系统可以不限于特定的平台。EJB （Enterprise JavaBean）是J2EE的一部分，定义了一个用于开发基于组件的企业多重应用程序的标准。其特点包括网络服务支持和核心开发工具（SDK）。 在J2EE里，Enterprise Java Beans（EJB）称为Java 企业Bean，是Java的核心代码，分别是会话Bean（Session Bean），实体Bean（Entity Bean）和消息驱动Bean（MessageDriven Bean）。
1.SessionBean用于实现业务逻辑，它可以是有状态的，也可以是无状态的。每当客户端请求时，容器就会选择一个SessionEJB EJBBean来为客户端服务。Session Bean可以直接访问数据库，但更多时候，它会通过Entity Bean实现数据访问。
2.Entity Bean是域模[1]型对象，用于实现O/R映射，负责将数据库中的表记录映射为内存中的Entity对象，事实上，创建一个Entity Bean对象相当于新建一条记录，删除一个Entity Bean会同时从数据库中删除对应记录，修改一个Entity Bean时，容器会自动将Entity Bean的状态和数据库同步。
3.MessageDriven Bean是EJB2.0中引入的新的企业Bean，它基于JMS消息，只能接收客户端发送的JMS消息然后处理。MDB实际上是一个异步的无状态Session Bean，客户端调用MDB后无需等待，立刻返回，MDB将异步处理客户请求。这适合于需要异步处理请求的场合，比如订单处理，这样就能避免客户端长时间的等待一个方法调用直到返回结果。EJB实际上是SUN的J2EE中的一套规范，并且规定了一系列的API用来实现把EJB概念转换成EJB产品。
由于EJB的复杂性使之在J2EE架构中的表现一直不是很好。EJB大概是J2EE架构中唯一一个没有兑现其能够简单开发并提高生产力的组件。EJB3.0规范正尝试在这方面作出努力以减轻其开发的复杂性。
那为什么我们还要使用EJB呢？因为EJB是J2EE重要的组成部分，可以说没有EJB的J2EE只是一种Web系统，这样的系统非常容易丧失了多层结构的大部分优点。
Web完全只是一个MVC模式的实现，关键业务核心是在EJB的服务层实现，这样做的优点是，Web只负责界面相关部分，因为，如果是一个智能客户端，如Swing或J2ME，在不需要修改任何业务核心的情况下能够方便地更换。同样，提供Web Services功能，也只是在 Web层修改，不会涉及EJB方面的修改，同样保证了系统的稳定性，保证了系统升级和未来的扩展性。
如果不使用EJB，在EJB服务层实现的业务核心将由普通JavaBeans实现，使用何种架构或设计能够保证负责MVC的JavaBeans和负责业务核心的JavaBeans清晰地分开，又如何保证在新的程序员不会破坏和打乱你精心布局的JavaBeans架构？ 最主要的是性能问题，由于以前国内中文Java网站有些人弯曲EJB，认为EJB性能低，其实这是一种非常肤浅错误的认识，我们首先看看在一般Java环境中是如何提高性能。假定一个JavaBeans为A，那么一般使用这个JavaBeans命令如下：
A a = new A（）；
但是，在高访问量的环境中，new A（）其实是很费时消耗系统性能的，因此，能不能在软件系统启动时候就预先建立一些对象，这样，系统运行时，从这些已经生成的对象池中借用一个，这样，就无需在使用时进行New，节约了开销，提高了性能，因此，真正成熟性能解决方案都是需要对象池等支持。
在一个纯Web结构的系统（也就是只能运行在Tomat环境中），例如Struts + Hibernate等这样的系统，除非自己动手做，一般是没有对象池技术支持的，因此他们的性能只能算是Demo演示版本的性能，根本无法承受大容量并发访问，也无法称为一个成熟的系统，所以，我们研究成熟的开源Web系统，如Jive、OFBize，LifeRay等，他们都在Web层拥有自己的对象池和缓存池。 对象池和缓存机制是J2EE必须的吗？当然，是所有成熟系统必须的，
Windows系统如果去掉缓存将会变得怎样？自己动手开发对象池和缓存机制并不是一件简单的事情，需要对多线程以及同步锁等底层原理有深层次的把握，这其实也是一门非常深入的Java研究分支，所以，你可以抛开你的客户焦急的催促，精心研究开发自己的对象池和缓存池。但是，EJB容器（如JBoss）已经提供了对象池和缓存机制，所以，没有事务机制的无状态Session Bean的性能肯定要强于普通JavaBeans。EJB容器不但在单机中提供了对象池和缓存，而且可以跨服务器实现动态负载平衡，这些都无需开发者自己开发任何软件代码。 EJB组件能提供真正的可重用框架 每一个jar包代表一个EJB组件，一个系统可以由多个可重用的EJB组件构成，例如：树形结构EJB组件；自增序号EJB组件；用户资料EJB组件等，这样的EJB组件可以象积木一样搭配在大部分应用系统中，提高了系统的开发效率，保证了开发质量。
由于EJB容器（如JBoss）对CMP实现有事务机制的缓存优化，因此，CMP特别适合多个用户同时更新同一个数据源的情况，CMP这种严格的事务完整性保证多个用户同时操作一个数据记录时，能够保证性能优化和数据的完整性，如果这个数据记录是是软件系统的状态标志，它的状态会影响系统中很多的环节，那么状态更改的重要性不言而喻。
如果没有事务完整性支持，你的软件系统在用户访问量变大，就会变得发生各种不可能发生的逻辑错误，查看程序逻辑是正确的，那么问题出在哪里？出在数据完整性上。
由于每个CMP在内存中都有一个缓存，在实际应用中，如果使用CMP批量读数据库数据，几万条查询完毕，内存中充满了几万条CMP缓存，如果这时你的EJB容器设置不当（如使用JBoss缺省配置），那么JVM的垃圾回收机制就会频繁启动，导致你的系统变慢甚至死机，这也是一些人抨击CMP慢的原因所在，其实他们使用方法不当，或者没有正确配置EJB容器CMP缓存。
对于这种情况，根据J2EE核心模式，推荐使用DAO+JDBC方式。
除非你对设计模式非常精深，能够将自己系统中的JavaBeans使用模式或某种框架进行固定分层，同时，你孜孜不倦研发出对象池，又熟练于JTA等事务机制，你可以选择没有EJB的纯Web结构，就象Jive、OFBiz那样。当然还有一个前提，老板不懂或者非常有挑战性（做与IBM SUN 微软齐名的公司和技术）。不要再被TSS那些狂热的开源先生误导，他们有时间有保障可以做他们喜欢的事情，作为专业的J2EE程序员，按照J2EE標准去学习去行动，也不要认为，只要使用了J2EE其中某个技术如Jsp或JavaBeans就心安理得认为自己的系统是J2EE了。
EJB是sun的服务器端组件模型，设计目标与核心应用是部署分布式应用程序。凭借java跨平台的优势，用EJB技术部署的分布式系统可以不限于特定的平台。EJB （Enterprise JavaBean）是J2EE的一部分，定义了一个用于开发基于组件的企业多重应用程序的标准。其特点包括网络服务支持和核心开发工具（SDK）。 在J2EE里，Enterprise Java Beans（EJB）称为Java 企业Bean，是Java的核心代码，分别是会话Bean（Session Bean），实体Bean（Entity Bean）和消息驱动Bean（MessageDriven Bean）。
1.SessionBean用于实现业务逻辑，它可以是有状态的，也可以是无状态的。每当客户端请求时，容器就会选择一个SessionEJB EJBBean来为客户端服务。Session Bean可以直接访问数据库，但更多时候，它会通过Entity Bean实现数据访问。
2.Entity Bean是域模[1]型对象，用于实现O/R映射，负责将数据库中的表记录映射为内存中的Entity对象，事实上，创建一个Entity Bean对象相当于新建一条记录，删除一个Entity Bean会同时从数据库中删除对应记录，修改一个Entity Bean时，容器会自动将Entity Bean的状态和数据库同步。
3.MessageDriven Bean是EJB2.0中引入的新的企业Bean，它基于JMS消息，只能接收客户端发送的JMS消息然后处理。MDB实际上是一个异步的无状态Session Bean，客户端调用MDB后无需等待，立刻返回，MDB将异步处理客户请求。这适合于需要异步处理请求的场合，比如订单处理，这样就能避免客户端长时间的等待一个方法调用直到返回结果。EJB实际上是SUN的J2EE中的一套规范，并且规定了一系列的API用来实现把EJB概念转换成EJB产品。
由于EJB的复杂性使之在J2EE架构中的表现一直不是很好。EJB大概是J2EE架构中唯一一个没有兑现其能够简单开发并提高生产力的组件。EJB3.0规范正尝试在这方面作出努力以减轻其开发的复杂性。
那为什么我们还要使用EJB呢？因为EJB是J2EE重要的组成部分，可以说没有EJB的J2EE只是一种Web系统，这样的系统非常容易丧失了多层结构的大部分优点。
Web完全只是一个MVC模式的实现，关键业务核心是在EJB的服务层实现，这样做的优点是，Web只负责界面相关部分，因为，如果是一个智能客户端，如Swing或J2ME，在不需要修改任何业务核心的情况下能够方便地更换。同样，提供Web Services功能，也只是在 Web层修改，不会涉及EJB方面的修改，同样保证了系统的稳定性，保证了系统升级和未来的扩展性。
如果不使用EJB，在EJB服务层实现的业务核心将由普通JavaBeans实现，使用何种架构或设计能够保证负责MVC的JavaBeans和负责业务核心的JavaBeans清晰地分开，又如何保证在新的程序员不会破坏和打乱你精心布局的JavaBeans架构？ 最主要的是性能问题，由于以前国内中文Java网站有些人弯曲EJB，认为EJB性能低，其实这是一种非常肤浅错误的认识，我们首先看看在一般Java环境中是如何提高性能。假定一个JavaBeans为A，那么一般使用这个JavaBeans命令如下：
A a = new A（）；
但是，在高访问量的环境中，new A（）其实是很费时消耗系统性能的，因此，能不能在软件系统启动时候就预先建立一些对象，这样，系统运行时，从这些已经生成的对象池中借用一个，这样，就无需在使用时进行New，节约了开销，提高了性能，因此，真正成熟性能解决方案都是需要对象池等支持。
在一个纯Web结构的系统（也就是只能运行在Tomat环境中），例如Struts + Hibernate等这样的系统，除非自己动手做，一般是没有对象池技术支持的，因此他们的性能只能算是Demo演示版本的性能，根本无法承受大容量并发访问，也无法称为一个成熟的系统，所以，我们研究成熟的开源Web系统，如Jive、OFBize，LifeRay等，他们都在Web层拥有自己的对象池和缓存池。 对象池和缓存机制是J2EE必须的吗？当然，是所有成熟系统必须的，
Windows系统如果去掉缓存将会变得怎样？自己动手开发对象池和缓存机制并不是一件简单的事情，需要对多线程以及同步锁等底层原理有深层次的把握，这其实也是一门非常深入的Java研究分支，所以，你可以抛开你的客户焦急的催促，精心研究开发自己的对象池和缓存池。但是，EJB容器（如JBoss）已经提供了对象池和缓存机制，所以，没有事务机制的无状态Session Bean的性能肯定要强于普通JavaBeans。EJB容器不但在单机中提供了对象池和缓存，而且可以跨服务器实现动态负载平衡，这些都无需开发者自己开发任何软件代码。 EJB组件能提供真正的可重用框架 每一个jar包代表一个EJB组件，一个系统可以由多个可重用的EJB组件构成，例如：树形结构EJB组件；自增序号EJB组件；用户资料EJB组件等，这样的EJB组件可以象积木一样搭配在大部分应用系统中，提高了系统的开发效率，保证了开发质量。
由于EJB容器（如JBoss）对CMP实现有事务机制的缓存优化，因此，CMP特别适合多个用户同时更新同一个数据源的情况，CMP这种严格的事务完整性保证多个用户同时操作一个数据记录时，能够保证性能优化和数据的完整性，如果这个数据记录是是软件系统的状态标志，它的状态会影响系统中很多的环节，那么状态更改的重要性不言而喻。
如果没有事务完整性支持，你的软件系统在用户访问量变大，就会变得发生各种不可能发生的逻辑错误，查看程序逻辑是正确的，那么问题出在哪里？出在数据完整性上。
由于每个CMP在内存中都有一个缓存，在实际应用中，如果使用CMP批量读数据库数据，几万条查询完毕，内存中充满了几万条CMP缓存，如果这时你的EJB容器设置不当（如使用JBoss缺省配置），那么JVM的垃圾回收机制就会频繁启动，导致你的系统变慢甚至死机，这也是一些人抨击CMP慢的原因所在，其实他们使用方法不当，或者没有正确配置EJB容器CMP缓存。
对于这种情况，根据J2EE核心模式，推荐使用DAO+JDBC方式。
除非你对设计模式非常精深，能够将自己系统中的JavaBeans使用模式或某种框架进行固定分层，同时，你孜孜不倦研发出对象池，又熟练于JTA等事务机制，你可以选择没有EJB的纯Web结构，就象Jive、OFBiz那样。当然还有一个前提，老板不懂或者非常有挑战性（做与IBM SUN 微软齐名的公司和技术）。不要再被TSS那些狂热的开源先生误导，他们有时间有保障可以做他们喜欢的事情，作为专业的J2EE程序员，按照J2EE標准去学习去行动，也不要认为，只要使用了J2EE其中某个技术如Jsp或JavaBeans就心安理得认为自己的系统是J2EE了。