Java EE现状及其发展趋势

原文： http://blog.sina.com.cn/s/blog_4e0c121101000awr.html

(这是我年初写的一篇文章，但迟迟没有公开。有些内容可能已经过时，但还是值得一读.) 


   经过将近10年的发展后，Java EE已经演变为当前企业的主流计算平台。开发者再也不能够简简单单地将Java看成一种编程语言了，其产业和技术链已经渗入到各行各业的企业系统的各个环节。本文试图对Java EE现状及其发展趋势进行阐述。

现状
   整体而言，Java EE平台正处在一个十字路口。现如今，整个Java SE/Java EE/Java ME平台已经开源了，这在Java发展史上是前所未有的。与此同时，许多开源实体已经参与到许多重要的Java EE技术规范的制定工作中，比如EJB 3.0的推出、Java EE 5平台的发布。这些讯息也告诉我们，整个Java EE平台已经非常成熟，急需找到新的突破口、新的机遇，并进一步去推动自身的发展。

   无论是Java EE规范的制订者、Java EE容器厂商，还是Java EE工具提供者、和基于Java EE开发的ISV，开源社区已经在它们身上扮演着非常重要、关键的角色。

   可以看出，开源已经成为了Java EE的主基调，这是一种全新的协作、互动模式。

从开源谈起
   开源不仅仅是一个形式，其蕴涵的内容非常丰富。对于ISV而言，这意味着软件的研发模式需要转变了，尽可能采纳成熟的、主流的开源技术来打造我们的系统。此时，我们不用去关注开源技术的底层实现和维护工作，因为整个开源社区在积极推动这一重要而基础的工作。

   来研究一个案例。开源领域的Spring已经成为了构建Java EE应用的事实上标准，它将Java EE领域中不同容器的差异性蕴藏起来，为开发人员暴露了统一的、一致的接口。采纳Spring架构目标应用后，应用的可移植性（便携性）不再是问题，而且开发者的开发效率和开发体验得到非常大的提升，应用的质量也能够得到保障。与此同时，Spring还在不断地超越Java EE平台技术本身。难道我们的系统有理由不架构在这类开源技术上？其实，这是一种精细化分工。ISV们再也不用在这类基础工作上花费太多的时间和精力，而且这类工作还很难做好。ISV可以将更多的精力放在系统的业务逻辑和功能的实现上。

   再来研究一个案例。大部分开发者都会采用开源领域的Eclipse（WTP） IDE来开发目标系统，其安装方便、可扩展性强。从Eclipse 3.2开始，OSGi成为了它的微内核，这是一重要的使能技术（后续内容会重点讨论到它）。Eclipse几乎成为了大部分ISV们首选的IDE。BEA/Borland/Oracle/RedHat等公司全面拥抱了这一扩展性强的工具平台，这不是在向我们暗示些什么吗？

   因此，我们必须参与到这一开源社区中，并从其中吸取到丰富的养分，并使得目标系统的研发速度、质量能够有较大的提升。开源是一种全新的协作模式，而且它也在诠释一种全新的互动模式。比如，一旦用户对某开源技术的某些方面有更好的建议时，整个开源社区便会快速地响应这一需求。

POJO编程模型
   开发出身的我非常注重目标应用采纳的开发模型。现如今，POJO编程模型是目前的主流开发模型。通俗地说，POJO的含义指，开发人员编写的Java类不会同Java EE API耦合在一起。

   从分层角度划分，应用的架构由展示层、业务层、持久化层构成。如果采纳传统的J2EE技术开发应用，则这类开发模型肯定不是POJO编程模型。POJO的实质是回归到对象的本质，即OO编程。所幸，开源社区一直在推动Java EE的发展。比如，对于展示层而言，Tapestry一直在倡导POJO编程模型；对于业务层而言，Spring一直在倡导这一编程模型；对于持久层而言，Hibernate一直也在倡导这一POJO编程模型。本人开发、架构及咨询过的许多大型应用都是基于Tapestry+Spring+Hibernate组合。当J2EE看到这一开源技术栈所带来的巨大冲击后，简化开发模型和力推POJO编程模型便成为了Java EE 5的主基调。比如，JSF 1.2已经成为了Java EE 5的标准件，这是类似于Tapestry的技术框架；EJB 3.0也将Hibernate的许多内容进行了“标准化”，即JPA 1.0。尽管JSF 1.2/EJB 3.0同Tapestry/Hibernate相比还存在许多不足之处，但这在Java EE发展史上已经是非常大的进步了，因为Java EE规范的推出是开源社区与商业实体协作的结果，这说明开发人员的地位越来越得到重视。

   可以看出，我们没有理由不在新项目中采纳POJO编程模型。

敏捷开发
   现有的软件市场是很残酷的，这势必要求我们能够控制好项目的开发风险。无论是开发过程本身，还是交付代码的质量和速度，这些都是项目要谨慎对待的。大体而言，我们要尽早将开发过程中的各种风险暴露出来。比如，快速实现系统功能、引入持续集成、开发人员必须编写测试代码、等等。如有可能，功能测试（包括用户接受测试）尽可能采取脚本驱动，因为计算机最擅长做重复性工作。不管如何，项目中的各种基础工作如果能够做到具有“可回归性”，则这将为项目的成功奠定非常重要的基础。上述内容都是敏捷开发的重要组成部分。

   当然，上述内容并不是基于Java EE平台技术的项目才要求的，这些都是与语言无关的敏捷特性。但是，在敏捷开发的可操作性方面，Java EE项目确实具有自身的优势。比如，JUnit和TestNG为测试代码（包括单元、集成及功能测试）的编写创造了条件；项目持续集成的实施可以依托于持续集成服务器，比如Java版的CruiseControl；Selenium RC为自动化功能测试的实施创造了条件；等等。

   可以看出，现有的Java EE平台技术非常适合于敏捷开发，而敏捷开发也需要敏捷的Java EE技术。另一方面，敏捷开发的粒度也要合理控制好，如果太激进，比如不重视系统的架构设计（包括业务架构和技术架构），则可能会出现“只见树木，不见森林”的局面。

无论如何，我们要重视敏捷开发！

发展趋势
   现有的Java EE技术非常成熟，而且各厂商容器趋于同质化。实际上，Java EE 5的主基调，“简化开发”，也暗示了这一点。可以看出，Java EE 5在试图简化开发者视图（客户视图），即让开发者能够更方便、更高效地使用Java EE技术，而不是引入新的、Java EE容器级的功能。很遗憾，Spring 2.0、即将推出的新版Acegi、Hibernate 3.x、Tapestry 5.0等开源技术暴露的客户视图已经远远超越了Java EE 5。开发者很难再次去钟爱Java EE 5了。在J2EE 1.3年代，由于开发者没有太多的选择，加上那时候J2EE还是新生事物，因此开发人员真的是“不得不爱”。

   与此同时，在服务器端，OSGi逐渐受到企业的关注和钟爱。这将是未来若干年中重要的基础架构技术。

将OSGi应用到服务器端
   试想，当我们的Java EE应用上线后，如果需要修改其中的部分内容，则我们通常要重新发布或重启这一目标应用吧？是的，在大部分情况下确实是如此！尽管一些容器厂商宣称自身的Java EE容器支持Java EE应用的版本化，但这毕竟是特定容器厂商的行为，而且这些专有特性的使用限制非常多。

   一直一来，Java平台本身就缺乏这类规范。尽管Servlet规范针对Web应用引入了Servlet类装载模型，但这一粒度还不够细。比如，如果在同一Web容器内部的不同Web应用中需要使用到不同版本的同一类，则通过启用Servlet类装载模型能够达到这一目标。但如果同一Web应用内部要同时启用不同版本的同一类，则Servlet类装载模型是应对不了这一苛刻的需求的。不幸的是，许多企业应用需要针对Web应用的不同部分进行真正的版本化（模块化）管理，进而矛盾产生了。

   此时，历史悠久的OSGi便被企业注意到，并试图将它引入到服务器端。OSGi本身定义了一套非常严格的类装载机制，并真正实现了“针对接口编程”。开发人员手中的Eclipse 3.2+便是基于它架构的。从目前来看，OSGi的应用深度和广度非常不错，但是它在Java EE服务器端的应用才刚开始。到目前为止，OSGi的应用还只是局限于桌面应用和嵌入式应用。Spring OSGi项目也正在试图降低采纳OSGi的门槛，并将OSGi引入到企业计算领域，最终将加快这类系统的交付速度。各Java EE容器厂商已经在最新的产品中积极跟进了OSGi，并将它应用到这些产品中。可以预见，对于OSGi和企业应用的开发而言，2007年将是重要的一年。我们应该跟进这一重要的基础技术，并试图将它应用到我们的研发工作中。

小结
   由于时间和篇幅原因，本文仅仅从宏观上给出了Java EE现状及其发展趋势的介绍。在此，要感谢肖朝华、肖艳龙的修改建议。希望本文没有浪费您宝贵的时间。如果有什么好的写作建议（无论是内容还是写作手法），则可以与我取得联系。