第1篇 基础知识
第1章 经典Java EE应用和开发环境
Java EE开发平台广泛应用于各种信息化平台的开发，无论在电信、移动、银行、证券、电子商务哪个平台上，Java EE开发平台的市场占有率都具有绝对的优势。大部分大型企业信息化平台，也会选择使用Java EE平台来构建。现今Oracle正式并购Sun公司，Java EE平台与Oracle的数据库系统一起融合在Oracle大旗之下，将为大型信息化系统提供更加完善的解决方案。
在目前实际的Java EE开发平台中，主要可分为两支：一支以Spring、Hibernate两个框架为核心来构建，这类应用无须应用服务器支持，只要在Tomcat、Jetty之类的Web服务器上即可运行良好。这类Java EE应用被称为轻量级Java EE应用；另一支则以EJB 3为核心来构建，这类应用需要EJB容器支持，通常需要在JBoss、WebLogic、WebSphere服务器中运行，这类Java EE应用是Sun公司官方推荐的Java EE平台，笔者在这里将其称为经典Java EE应用。无论是轻量级Java EE应用，还是经典Java EE应用，一样具有稳定的性能和极高的可扩展性、可维护性。
本书作为《轻量级Java EE企业应用实战》的姊妹篇，主要介绍JSF和EJB 3的整合开发，不再涉及JSP、Struts、Spring、Hibernate的相关知识，如果读者需要学习这些方面的相关知识，建议阅读疯狂Java体系的《轻量级Java EE企业应用实战》一书。
1.1 经典Java EE应用概述
本书所介绍的经典Java EE应用基于Sun的Java EE平台构建，这种Java EE应用以EJB 3为核心，前端MVC框架当然也可以选择Struts 1.x、Struts 2.x或其他MVC框架。但习惯上优先考虑选择JSF（Java Server Faces）——JSF本身就是Java EE规范之一。当Sun提出JSF规范的同时，也提供了JSF的一个参考实现（Reference Implementation，RI）。在很多时候，我们说JSF，可能指的是JSF RI；Apache组织也提供了JSF的另一个实现，这就是MyFaces框架。不管是JSF RI，还是MyFaces框架，现在都已经非常成熟，完全可用于实际企业开发。
由于经典Java EE应用需要以EJB 3为核心，因此经典Java EE应用通常需要包含EJB容器的应用服务器支持。
1.1.1 Java EE 6相关规范
1998年，Sun公司发布了EJB 1.0标准，EJB是整个Java EE平台的核心规范，它为企业应用提供数据库访问、事务控制、业务处理相关支持。到了1999年，Sun公司正式发布了J2EE的第一个版本，其中包括Servlet、JSP和EJB 1.0。
为了抢占Java带来的巨大商机，为企业应用提供支撑的应用服务器大量出现，其中最成功的有BEA（现已被Oracle并购）的WebLogic、IBM的WebSphere等，还有开源的JBoss应用服务器。
接下来J2EE发布了1.4版，伴随J2EE一起发布的有EJB 2.0、Servlet 2.4和JSP 1.2，其中EJB 2.0是一个争议极大的东西，这并不是因为EJB 2.0不够强大；相反是因为EJB被设计得过于强大，因此导致它变得难以驾驭，尤其是对于广大初、中级程序员则显得更加复杂——而世界是一个悖论：喜欢到处（尤其是网络上）吵架、骂人的往往就是这些初、中级用户，因此导致了业界充斥着对EJB 2.0的骂声。
于是Sun公司于2005年发布了Java EE 5规范（由J2EE 1.5版更名而来），Java EE 5最大的改变是简化后的EJB规范：EJB 3.0。与此同时，Java EE 5包含了JSF 1.2规范，正式引入JSF为Java EE的MVC解决方案。
不管是早期的J2EE应用，还是今天的Java EE应用，其核心组件都是EJB，EJB的功能覆盖底层数据库访问、业务逻辑实现、事务控制几乎整个中间层开发。所不同的是，Java EE引入了JSF规范作为MVC的解决方案。
2009年年底，Java EE 6相关规范发布了，从Java EE 5到Java EE 6经过了漫长的4年多，Java EE规范主要包含如下技术：
Servlet 3.0
JSP 2.2
JSF 2.0
JSTL 1.2
CDI（Contexts and Dependency Injection for Java 1.0）
JTA 1.1
JPA 2.0
EJB 3.1
JMS 1.1
JavaMail 1.4
如果读者学习过《轻量级Java EE企业应用实战》一书，对JSP、Servlet、JSTL等规范应该相当熟悉了，但《轻量级Java EE企业应用实战》介绍的Servlet规范是Servlet 2.5、JSP规范是JSP 2.1，它们其实是属于Java EE 5规范的。
Java EE 5则包含如下规范：
Servlet 2.5
JSP 2.1
JSF 1.2
JSTL 1.2
JTA 1.1
JPA
EJB 3.0
JMS 1.1
JavaMail 1.4
对比Java EE 5和Java EE 6，Java EE的核心规范Servlet、JSP、JSF、EJB都得到了升级，但Java EE 6绝没这么快就能应用到实际企业项目，因为前面已经提到：以EJB为核心的Java EE应用需要应用服务器的支持，否则Java EE 6规范将无法应用于实际项目。
至笔者成书之时，Apache的Tomcat的最新稳定版是Tomcat 6.0.24，该版本的Tomcat只支持Servlet 2.5和JSP 2.1，最新的Servlet 3.0和JSP 2.2无法在该版本的Tomcat中运行。而本书所介绍的WebLogic和JBoss目前也还只支持Java EE 5，因此本书依然以Java EE 5为基础进行介绍。
1.1.2 经典Java EE应用的分层模型
熟悉轻量级Java EE应用架构的读者都知道，Java EE应用大致可分为如下几层：
Domain Object（领域对象）层：此层由系列的POJO（Plain Old Java Object，普通的、传统Java对象）组成，这些对象是该系统的Domain Object，这些对象往往包含了各自所需要实现的业务逻辑方法。
DAO（Data Access Object，数据访问对象）层：此层由系列的DAO组件组成，这些DAO实现了对数据库的增加、查询、更新和删除（CRUD）等原子操作。
业务逻辑层：此层由系列的业务逻辑对象组成，这些业务逻辑对象实现了系统所需要的业务逻辑方法。这些业务逻辑方法可能仅仅用于暴露Domain Object对象所实现的业务逻辑方法，也可能是依赖DAO组件实现的业务逻辑方法。
控制器层：此层由系列的控制器组成，这些控制器用于拦截用户请求，并调用业务逻辑组件的业务逻辑方法，处理用户请求，并根据处理结果转发到不同的表现层组件。
表现层：此层由系列的JSP页面、Velocity页面、PDF文档视图组件组成。此层负责收集用户请求，并将显示处理结果。
轻量级Java EE应用大致有如图1.1所示的分层架构。
图1.1 轻量级Java EE应用的分层架构
轻量级Java EE应用的各组件并不以硬编码方式耦合，而是依靠Spring框架提供的IoC来管理各组件的依赖关系，从而让各组件以松耦合的方式组织在一起，从而为应用提供较好的扩展性。
Java EE 5充分借鉴了轻量级Java EE应用的两大框架：Hibernate和Spring，因此经典Java EE应用也有类似的分层架构，区别只是实现技术不同而已，本书所介绍的经典Java EE应用有如图1.2所示的分层架构。
图1.2 经典Java EE应用的分层架构
对比图1.1和图1.2不难发现，经典Java EE应用和轻量级Java EE应用从分层架构上来看差别并不大，区别只是实现细节上的差异。
1.1.3 经典Java EE应用的组件
从上一节的介绍可以发现：不管是轻量级Java EE应用，还是经典Java EE应用，它们都有完全相似的分层架构，这种设计的目的就是实现应用组件的解耦，为应用提供较好的可扩展性和可维护性。
总体来说，经典Java EE应用大致包括如下几类组件：
控制器组件：对于Java EE的MVC框架而言，框架提供一个前端核心控制器，而核心控制器负责拦截用户请求，并将请求转发给用户实现的控制器组件。而这些用户实现的控制器则负责处理调用业务逻辑方法，处理用户请求。
业务逻辑组件：业务逻辑组件实现系统的业务逻辑，通常使用Session Bean来实现。一般来说，一个业务逻辑方法对应一次用户操作。一个业务逻辑方法应该是一个整体的，因此我们要求对业务逻辑方法增加事务性。业务逻辑方法仅仅负责实现业务逻辑，不应该进行数据库访问。因此，业务逻辑组件中不应该出现原始的Hibernate、JDBC等API。
注意
保证业务逻辑组件之中不出现Hibernate和JDBC等API，可以保证业务逻辑方法的实现与具体的持久层访问技术分离。当系统需要在不同持久层技术之间切换时，系统的业务逻辑组件无须任何改变。笔者有时见到一些所谓的Java EE应用，在JSP页面里调用EJB的实体管理器执行持久化、直接在JSP页面里访问实体，这无疑是非常荒唐的，这种应用仅仅是为了EJB而EJB，根本完全没有脱离Model 1的JSP开发模式—— 这与直接在JSP页面中调用JDBC访问数据库并没有本质区别。实际上，不仅JSP、Servlet中不要出现持久层API（包括JDBC、Hibernate API、JPA等），而且业务逻辑组件中也不应该出现持久层API。
EAO组件：EAO组件的全称是Entity Access Object，也被称为实体访问对象，经典Java EE应用中的EAO组件通常采用Session Bean来实现，实际上，EAO就相当于轻量级Java EE应用中的DAO对象，一样提供对系统Entity（也被称为实体）的增加、查询、修改和删除等操作，这些操作对应于数据表的CRUD（增加、查询、修改和删除）等原子操作。因为JPA规范中的Entity本身就是POJO（普通的、传统Java对象），因此有些人认为可以直接使用Entity作为DTO（Data Transfer Object，数据传输对象）使用，因此把DAO组件更名为EAO组件。
Entity对象：Entity抽象了系统的对象模型。通常而言，这些领域对象的状态都必须保存在数据库里。因此，每个Entity映射到一个或多个数据表。
表现层组件：表现层组件主要负责收集用户输入数据，或者向客户显示系统状态。最常用的表现层技术是JSP，而JSP并不是唯一的表现层技术，表现层还可由Velocity、FreeMarker等技术完成，或者使用普通的应用程序充当表现层组件，甚至可以是小型智能设备。
1.1.4 经典Java EE应用架构的优势
正如前面所指出的，经典Java EE应用架构与轻量级Java EE应用架构并没有本质的区别，它们的区别只是实现技术上的差异。
从另外一个角度来看，经典Java EE应用架构和轻量级Java EE应用架构本来就是相互影响、相互借鉴的，因此它们二者的优势基本相同。
提示
如果读者需要了解更多关于Java EE应用架构的优势，可以参考疯狂Java体系的《轻量级Java EE企业应用实战》第1章的阐述。
1.1.5 常用的企业服务器
本书介绍的经典Java EE应用是以EJB 3为核心的，这种Java EE应用必须在包含EJB容器的应用服务器上运行，普通的Java Web服务器（如Tomcat、Jetty等）无法运行这种Java EE应用。
目前Java领域市场应用比较广泛的有如下几个应用服务器：
GlassFish：Sun官方提供的一款开源应用服务器，它主要以Sun公司的Sun Java System Application Server PE 9的源代码和Oracle公司的TopLink持久性代码构建。至笔者成书之时，GlassFish的最新版本是GlassFish v3，这是目前极少能支持Java EE 6的应用服务器。不过就实际应用来看，GlassFish目前并未大规模应用于实际项目，故本书并未太多介绍这个应用服务器。
WebSphere应用服务器：IBM提供的一款优秀的商业应用服务器。实际上，WebSphere是IBM的一套完整的产品，而WebSphere只是这套产品的其中之一。不过习惯上我们说WebSphere时往往就是指WebSphere。
WebLogic：Oracle提供的一款商业应用服务器，这款应用服务器早期归BEA所有，后来BEA被Oracle收购，WebLogic自然也就归到Oracle旗下了。WebLogic也是一款非常优秀的应用服务器，在实际项目中市场占有率很高。至笔者成书之时，WebLogic的最新版本是11g（其实就是10.3.2版），这也是本书所介绍的WebLogic。
JBoss：这是一款开源的Java EE应用服务器，因为JBoss具有开源、免费的特征，因此许多中小型企业都会考虑选择JBoss作为应用服务器。JBoss的最新稳定版是5.1.0.GA版，笔者成书之时，JBoss已经发布了第一个里程碑版本：6.0.0.M1，但这个里程碑版本投入实际应用依然有风险。所以本书所介绍的JBoss依然是5.1.0.GA版。