框架之轻量级和重量级

框架之轻量级和重量级
一：基本概念：
量级主要是看容器的依赖性所决定的,依赖性越小,越轻量.
1、轻量级框架
1.定义：在Java应用程序开发环境中，“轻量级Java”主要是指两个东西：简化的编程模型和更具响应能力的容器。

轻量级Java旨在消除与传统J2EE API有关的不必要的复杂性和限制。

它也将缩短应用程序的部署时间，这对于支持开发最佳实践（比如频繁单元测试）非常重要。

2.现在比较重要的轻量级以及对终端用户的帮助：控制反转(IoC)模式在这个领域有着重大的影响。

使用IoC，开发人员不需要编写复杂的代码来执行查询、处理基础架构异常或管理连接，就能够解决对象依赖性问题。

这有助于简化代码、将业务逻辑与基础架构分离，从而使应用程序更易于维护。

轻量级Java的另一个关键特征是，它不会强迫业务对象遵循平台特定接口。

这允许开发人员在普通旧式Java对象(POJO)中实现业务逻辑,从而提高生产率。

与具体的类相反，当把开发的最佳实践与界面相结合时,这些特性也使得对代码进行单元测试容易得多。

由于业务逻辑实现在POJO中，所以不再需要将对象部署到重量级容器中以在单元测试中练习它。

因此，将对象宿主在诸如JUnit之类的简单测试环境中和为快速迭代单元测试“模拟”外部依赖性就变得微不足道了。

3.现在典型的轻量级框架：Struts、Hibernate、Spring、Beehive.....
注：感觉转向轻量级技术越来越猛了，传统的重量级EJB也推出EJB3.0也基本上是以使得轻量级Java盛行的概念为基础。

2、重量级框架
dev2dev:人们在想起应用服务器供应商时，通常把它们置于“重量级阵营”。

我想您正在努力改变这种状况，对吧？换言之，许多人认为应用程序供应商已经在实现重量级组件（比如EJB2.0）上付出了很大的代价，它们不愿意轻易放弃这些成果。

Jim:首先，我认为没有理由放弃在EJB上的现有投资，因为在某些场景中它仍然是最好的技术，例如当您希望通过RMI远程公开业务服务时。

当然，诸如EJB之类的开放标准在保护客户投资方面的价值也不能低估。

已经说过,我觉得人们经常过分强调EJB在应用服务器中的实际价值。

尽管这一点未必对所有的应用服务器供应商都适用，但是BEA只投入了相对较少的一部分开发资源来支持J2EE API。

我们工作最主要的目标是为宿主应用程序构建最可靠、可伸缩和容错的内核。

这些品质以及分布式事务服务、高速消息传递、遗留系统集成、高级Web服务、配置管理、诊断和故障排除和高级安全性，代表了WebLogic Server的真正价值，而且对总体拥有成本（TCO）有着巨大的影响。

幸运的是，这些附加值对基于Spring或Beehive的应用程序的相关性和适用性与采用EJB构建的应用程序是一样的。

虽然轻量级Java技术使得应用程序的开发和维护更容易，但是它们不会代替真正高端应用服务器的品质。

实际上，我们认为轻量级Java与WebLogic Server是一致的。

dev2dev:BEA有没有一个轻量级Java策略？BEA实现轻量级Java的方法是什么？
Jim:我们的策略是接纳所有有利于提高开发人员生产率、在市场上为部署这些技术提供最佳平台的技术。

轻量级Java 有助于降低开发成本,WebLogic Server则有助于降低运营成本,它们是一个非常强大的组合。

3、应用程序框架
dev2dev:由BEA赞助的Beehive项目显然是一个轻量级Java组件模型。

您能否谈谈关于Beehive的情况，以及它在你们的整个策略中的地位？
Jim:Beehive是一个应用程序框架，致力于使J2EE应用程序和基于SOA的应用程序的开发更容易，它基于我们发布WebLogic Workshop的经验。

它基于POJO和用于配置依赖性、服务质量等的元数据提供一个编程模型。

元数据以J2SE5.0代码注解和外部XML文件的形式获得支持。

存在一些用于访问J2EE资源、定义业务和Web服务以及基
于MVC模式开发Web应用程序的组件。

在我们努力提高开发人员生产率、巩固Java整体市场的过程中，Beehive是非常关键的一部分。

ev2dev:Beehive可以被认为是一个“应用程序框架”。

在Spring Framework中提供了一种非常流行的轻量级Java方法。

Spring（以及其他类似的框架）对于BEA有多重要？
Jim:任何能够帮助我们的客户提高生产率的东西都对我们非常重要。

我们欢迎并且接纳这些技术,在适当的时候也可以在技术层面上集成或者共享这些技术。

dev2dev:你们考虑过明确支持这些框架吗？
Jim:就像我原来说过的,WebLogic Server具有很多方面的特性，能够提供基于轻量级Java技术的应用程序。

许多都是隐含的，然而在某些情况下，最小量的集成工作就能为轻量级Java开发人员提供重要的价值。

举个例子，当今存在的一些适配器允许Spring应用程序使用WebLogic Server的分布式事务能力，无需改变任何应用程序代码。

我们正在调查许多其他的机会，当然也一直在倾听客户的需求。

dev2dev:我们已经看到轻量级框架对EJB3的一些影响。

您认为这会扩展到J2EE的其他方面吗？
Jim:是的。

我认为JSR175（即Java元数据）对于简化J2EE编程模型是一种关键的支持技术。

EJB3.0使用了它，而且它也是JSR181（即Web Services元数据，一个BEA倡导的规范）的基础。

没有理由相信它会就此停止。

4、轻量级持久性
dev2dev:IoC容器看起来是轻量级Java的中心。

另外的一个关键因素是POJO和轻量级持久性。

您能针对这个问题谈谈看法吗？
Jim:同样，共同的主题是简化编程模型。

没有比POJO更简单的了。

当然，企业开发要求我们有能力应用附加的品质,比如持久性规则、事务语义和POJO的安全约束。

盛行很广的方式是在元数据中定义这些品质，要么作为代码注解，要么放在外部文件中。

dev2dev:您是否觉得因为有多种方法用于完成持久性这样的事情而存在一些危险？比如，我们很快将会有EJB2、EJB3、JDO、Hibernate，等等。

Jim:我认为这只是成熟领域的一个实际情况。

多年来，J2EE规范没有完全涵盖这个特定的领域，自然就会导致其他规范的出现。

就我所知道的在JCP中发生的事情，我们似乎正在走向统一。

这对于整个行业来说是一件好事。

5、未来
dev2dev:您能预见一下轻量级Java和BEA的未来吗？
Jim:我们将会继续活跃于这个领域中，既通过诸如Apache Beehive、XMLBeans、Eclipse和JCP之类的渠道推动创新，又吸收诸如Spring这样的其他领先技术，并且为了客户的利益而展开协作。

6、总结
重量级的开发倒并不是指EJB或者是JNDI，很大意义上，重量级的开发都是需要依赖一个非常庞大的容器系统进行开发，在EJB的开发中，我们所有开发的内容基本都需要放置在一个容器系统中进行运行，这些容器因为基本针对大型企业应用，所以体积庞大，占用资源过多，在开发的过程中效率很低，因为使用大型容器作为开发环境的话，我们很大一部分时间都用在了Deploy、Run，这样的过程上，有时候改动一个小小的部分，需要等等很长的时间才能看到结果，如果做单元测试也比较麻烦，虽然现在有很多针对容器的单元测试框架，但是还是没有很好的解决Deploy的等待问题，所以在开发者这里，EJB逐渐失去了很多的吸引力，因为感觉实在是太笨重了。

轻量级框架的优势很大程度上是因为加速了开发的速度，我们不用部署一个很庞大的容器系统就可以实现以前需要容器才能实现的功能，我们可以使用Spring代替EJB中的Stateless Session Bean，可以使用Hibernate代替EJB中的Entity Bean，而且我们可以直接写一个Application运行已经完成的系统，马上可以看到结果，做单元测试非常的简介，不需要做太多的工作就可以构建系统，这些特性对于开发人员来说非常的有吸引力。

关于轻量级和重量级之间的论战已经由来已久了，也最终没有出现一个很好的结果，重量级框架在大规模运行的时候会表现出非常优异的性能，劣势主要是开发效率较低，轻量级框架正好相反，开发的时候非常迅速，但是在大规模运行的时候，性能比重量级框架还是有差异。

但是随着最近一些框架标准的成熟，可以有新的选择，因为不管是轻量级还是重量级框架，基本解决的是两个问题，一个是“事务控制”，一个是“持久化控制”，在JPA标准发布以后，我们看到一个很好的解决方式，“持久化”的开发可以和任何框架没有关系，直接使用JPA的标准注解即可，所以开发“持久化”部分的时候可以使用JPA进行注解，开发时期用Hibernate作为JPA的实现进行开发测试，需要上线运行的时候就可以直接部署到EJB的EntityBean上，在EJB3.0之后，已经很好进行移植部署。

关于“事务控制”，现在所有的实现方式都比较简单，针对方法进行注解事务类型即可，开发的时候可以用一个转换器将这些注解转化为Spring的映射，快速的进行开发，在上线运行的时候，直接使用EJB 的Session Bean进行部署就可以解决，这些方式实现起来并不困难，可以很好解决“重量级”和“轻量级”之间的矛盾。