J2EE--之EJB的没落与轻量级服务器的崛起
前言：好久一段时间没关注过j2ee了, 昨天恶补了一下。不看不知道，一看吓一跳！ J2EE在过去一年发生了如此大的变化：EJB， 那个曾经作为J2EE核心部件的概念，如今似乎已经没落了， 落得人人喊打的地步了！！！继而兴起了一批新的概念：AOP, IoC轻量级服务器，POJO...
真的感慨万千。在2004年还无限风光的EJB, 在2005年便落到这种地步了！ 于是让我怀疑： 当前那么急切的紧跟EJB潮流是否值得？ AOP又能持续多久？ 是否还要紧跟所谓的时尚技术？ 以后如何应对新技术潮流的变迁？
本来这个技术圈子没有一个严格的标准，就是一个婆说婆有理，媳说媳有理的事！这个圈子从来没缺少过争吵！J2EE与.net吵， C++ 与JAVA吵， Linux与Windows吵... 感觉真的很乱，让人无所适从！
跑题太远了，还是转入正题吧！
一、EJB为我们提供了什么？
1. 声明性事务管理
避免编写大量的事务管理代码, 通过声明来完成事务性管理
2. 持久性管理
通过使用entity bean 来实现O/R mapping 即对象到关系数据库的影射
3. 安全性管理
开发者可以在EJB的部署描述文件中进行方法级的、基于角色的安全性管理
4. 生命周期管理
它实际上是为了实现EJB的持久性管理和资源管理而衍生出的功能。由于EJB实例对象和的生命周期是由EJB容器负责维护的，所以EJB实例对象的状态通常是不可预期的。于是EJB提供了一组生命周期管理接口， 供用户对EJB的生命周期进行一定的控制管理。
5. 资源管理
在J2EE的缓冲池中，不仅有对象实例池，还有资源管理池。例如：将数据库连接放入连接池中，其主要作用是防止以外情况时，不断的加载造成连接被全部耗尽！
6. 并发访问管理
也就是线程管理。EJB让开发者以编写单线程程序的方式编写业务对象，同时能使这些业务对象运行在多线程环境。
7. 业务对象管理（寻址服务）
借助JNDI为服务对象提供目录服务。EJB的部署描述文件提供了一个从服务名称到实现对象的影射，从而消除了业务接口（EJB组件接口）与实现类之间的耦合。
8. 远程访问
EJB本身设计就是分布式的，它通常是基于RMI来实现。
9. 集群
EJB曾被称为获得J2EE应用最大可伸缩性的不二法门。当然它有着出众的集群能力， 可方便的实现横向、纵向的集群，而不只是简单的应用的拷贝。
二、EJB的缺陷
EJB容器为EJB提供了一个优越而全面的服务环境！ 这是它的优点，但也是它被人诟病的缺点： 很少有用到这么全面的服务的业务对象， 但不管用不用到这些服务都要为它埋单！因此在实施成本和性能上会有很大的损耗！
尽管当前的高端商业应用服务器在性能上有很强的表现，但是价格不菲！而开源的应用服务器在性能表现上并不能让人满意！
另外在如下一些方面也存在一些不足
1. 远程调用
EJB极大的简化了远程调用。但是EJB规范混淆了远程和组件模型。它往往会诱使人们采用一种并不适用且昂贵得体系结构。这对设计是有害的。
2. 集群方面
其实，机群的重点不应该在J2EEweb的应用业务对象层，通常专门的业务层集群不是很必要。相比而言，数据访问层，数据库层才是集群的重点！不过像 EJB这种比较笨重的东西需要集群也是可以理解的。^0^
3. 侵入性
为了使用EJB的服务业务对象必须实现EJB的特定接口！从而影响了原业务对象的固有形式！（其实在IoC中这个问题也没有真的完全解决。）
三、用什么方法代替EJB?
从EJB架构到轻量级架构：
1. 对于本地对象： local EJB => 应用AOP注入操作代码的POJO
就分布式对象而言无状态session bean当然还是最好的选择！
2. 容器：EJB 容器=>IoC容器
3. entity bean => Hibernate或JDO
entity bean 早就被人们看作是不成功的废品了。这里就不多说了。
关于IoC容器， 以Spring架构为例说明它将如何以及在什么程度代替EJB容器。Spring一个开源的IoC容器实现。
1. 声明性事务管理、声明性安全、并发管理： Spring框架内置支持该功能。
2. 资源管理、业务对象管理： 是J2EE应用服务器提供的功能，它并不是EJB容器的特性。String支持这种能力。
3. 远程访问：
4. 生命周期管理：
5. 集群管理：支持横向集群，也就是应用的横向复制。
四、EJB目前还在坚守的阵地！
1. SLSB即无状态的session bean 还在被使用。在大型的企业级服务应用中，尤其涉及到需要横纵向集群方式的。SLSB仍是当前的最佳选择。只是，这种项目可能会很少接触到！而在一般情况下，我们应该考虑使用IoC, 而不是EJB.
2. MDB即消息驱动Bean， 这主要是目前轻量级服务器暂时没有一个规范性的实现策略。这只是暂时的， 因为轻量级服务器要想真的替代EJB，这个问题必须解决！(在Spring 2.0中已经有了异步JMS)
前言：好久一段时间没关注过j2ee了, 昨天恶补了一下。不看不知道，一看吓一跳！ J2EE在过去一年发生了如此大的变化：EJB， 那个曾经作为J2EE核心部件的概念，如今似乎已经没落了， 落得人人喊打的地步了！！！继而兴起了一批新的概念：AOP, IoC轻量级服务器，POJO...
真的感慨万千。在2004年还无限风光的EJB, 在2005年便落到这种地步了！ 于是让我怀疑： 当前那么急切的紧跟EJB潮流是否值得？ AOP又能持续多久？ 是否还要紧跟所谓的时尚技术？ 以后如何应对新技术潮流的变迁？
本来这个技术圈子没有一个严格的标准，就是一个婆说婆有理，媳说媳有理的事！这个圈子从来没缺少过争吵！J2EE与.net吵， C++ 与JAVA吵， Linux与Windows吵... 感觉真的很乱，让人无所适从！
跑题太远了，还是转入正题吧！
一、EJB为我们提供了什么？
1. 声明性事务管理
避免编写大量的事务管理代码, 通过声明来完成事务性管理
2. 持久性管理
通过使用entity bean 来实现O/R mapping 即对象到关系数据库的影射
3. 安全性管理
开发者可以在EJB的部署描述文件中进行方法级的、基于角色的安全性管理
4. 生命周期管理
它实际上是为了实现EJB的持久性管理和资源管理而衍生出的功能。由于EJB实例对象和的生命周期是由EJB容器负责维护的，所以EJB实例对象的状态通常是不可预期的。于是EJB提供了一组生命周期管理接口， 供用户对EJB的生命周期进行一定的控制管理。
5. 资源管理
在J2EE的缓冲池中，不仅有对象实例池，还有资源管理池。例如：将数据库连接放入连接池中，其主要作用是防止以外情况时，不断的加载造成连接被全部耗尽！
6. 并发访问管理
也就是线程管理。EJB让开发者以编写单线程程序的方式编写业务对象，同时能使这些业务对象运行在多线程环境。
7. 业务对象管理（寻址服务）
借助JNDI为服务对象提供目录服务。EJB的部署描述文件提供了一个从服务名称到实现对象的影射，从而消除了业务接口（EJB组件接口）与实现类之间的耦合。
8. 远程访问
EJB本身设计就是分布式的，它通常是基于RMI来实现。
9. 集群
EJB曾被称为获得J2EE应用最大可伸缩性的不二法门。当然它有着出众的集群能力， 可方便的实现横向、纵向的集群，而不只是简单的应用的拷贝。
二、EJB的缺陷
EJB容器为EJB提供了一个优越而全面的服务环境！ 这是它的优点，但也是它被人诟病的缺点： 很少有用到这么全面的服务的业务对象， 但不管用不用到这些服务都要为它埋单！因此在实施成本和性能上会有很大的损耗！
尽管当前的高端商业应用服务器在性能上有很强的表现，但是价格不菲！而开源的应用服务器在性能表现上并不能让人满意！
另外在如下一些方面也存在一些不足
1. 远程调用
EJB极大的简化了远程调用。但是EJB规范混淆了远程和组件模型。它往往会诱使人们采用一种并不适用且昂贵得体系结构。这对设计是有害的。
2. 集群方面
其实，机群的重点不应该在J2EEweb的应用业务对象层，通常专门的业务层集群不是很必要。相比而言，数据访问层，数据库层才是集群的重点！不过像 EJB这种比较笨重的东西需要集群也是可以理解的。^0^
3. 侵入性
为了使用EJB的服务业务对象必须实现EJB的特定接口！从而影响了原业务对象的固有形式！（其实在IoC中这个问题也没有真的完全解决。）
三、用什么方法代替EJB?
从EJB架构到轻量级架构：
1. 对于本地对象： local EJB => 应用AOP注入操作代码的POJO
就分布式对象而言无状态session bean当然还是最好的选择！
2. 容器：EJB 容器=>IoC容器
3. entity bean => Hibernate或JDO
entity bean 早就被人们看作是不成功的废品了。这里就不多说了。
关于IoC容器， 以Spring架构为例说明它将如何以及在什么程度代替EJB容器。Spring一个开源的IoC容器实现。
1. 声明性事务管理、声明性安全、并发管理： Spring框架内置支持该功能。
2. 资源管理、业务对象管理： 是J2EE应用服务器提供的功能，它并不是EJB容器的特性。String支持这种能力。
3. 远程访问：
4. 生命周期管理：
5. 集群管理：支持横向集群，也就是应用的横向复制。
四、EJB目前还在坚守的阵地！
1. SLSB即无状态的session bean 还在被使用。在大型的企业级服务应用中，尤其涉及到需要横纵向集群方式的。SLSB仍是当前的最佳选择。只是，这种项目可能会很少接触到！而在一般情况下，我们应该考虑使用IoC, 而不是EJB.
2. MDB即消息驱动Bean， 这主要是目前轻量级服务器暂时没有一个规范性的实现策略。这只是暂时的， 因为轻量级服务器要想真的替代EJB，这个问题必须解决！(在Spring 2.0中已经有了异步JMS)
扫一扫
351
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
