第二章 J2EE技术新论
第一节J2EE技术的整体观
现代软件逐渐流行起来的研究方法首先必从所谓体系结构看起。这种看法颇有道理：从整体着眼可以看得清楚、有居高临下的感觉，不但看得远，而且可以看得清晰。看得清楚意指一个东西，如J2EE，他里面到底有那些东西，有了体系结构图，可以一目了然。所谓看得远，可以从体系结构中看开去，能够从体系上自然地与其他技术体系比较，看出这种体系的优点体现在哪里、缺点又表现在哪里、今后发展的方向应该在哪里；所谓看得清晰，意指一个体系结构中各种元素彼此之间的交错众和、文理经脉能够一目了然，比清楚又进了一层。所以无论是初学者，还是资深的体系架构师，他们有一个共同特点就是一定喜欢看体系结构图。J2EE首先是个有机的整体，她以J2SE为基础，包含13种主要技术，请看其结构图：
(图1)
上面可以看到J2EE平台的整体结构，他的大部分核心技术也有标明：JDBC, EJB, RMI, JSP, JAVA SERVLETS, XML, JMS, JTS, JTA, JAVAMAIL 和 JAF。其实J2EE本质上由一整套服务（SERVICES）、应用程序接口（APIS）和协议构成，它对开发基于WEB的多层应用提供了功能支持。J2EE还要求描述在何时、何处需要使用这些技术。当然，知道这些不同的技术之间是如何交互的是理解J2EE而必须的。
过去，二层化应用 -- 通常被称为CLIENT/SERVER应用 -- 是大家谈论的最多的。在很多情况下，服务器提供的唯一服务就是数据库服务。在这种解决方案中，客户端程序负责数据访问、实现业务逻辑、用合适的样式显示结果、弹出预设的用户界面、接受用户输入等。CLIENT/SERVER结构通常在第一次部署的时候比较容易，但难于升级或改进，而且经常基于某种专有的协议—通常是某种数据库协议。它使得重用业务逻辑和界面逻辑非常困难。更重要的是，在WEB时代，二层化应用通常不能体现出很好的伸缩性，因而很难适应INTERNET的要求。
SUN设计J2EE的部分起因就是想解决二层化结构的缺陷。于是，J2EE定义了一套标准来简化N层企业级应用的开发。它定义了一套标准化的组件，并为这些组件提供了完整的服务。J2EE还自动为应用程序处理了很多实现细节，如安全、多线程等。
用J2EE开发N层应用包括将二层化结构中的不同层面切分成许多层。一个N层化应用能够为以下的每种服务提供一个分开的层：
显示：在一个典型的WEB应用中，客户端机器上运行的浏览器负责实现用户界面。当然终端类型可以多种多样。
表示层: 尽管浏览器可以完成某些动态内容显示，但为了兼容不同的浏览器，这些动态生成工作应该放在WEB服务器端进行，使用JSP、SERVLETS，或者XML（可扩展标记语言）和（可扩展样式表语言）。
业务层：业务逻辑适合用SESSION EJBS（后面将介绍）来实现。
数据访问：数据访问适合用ENTITY EJBS（后面将介绍）和JDBC来实现。 同后台系统的集成可能需要用到许多不同的技术，至于何种最佳需要根据后台系统的特征而定。
为什么有这么多的层？事实上，多层方式可以使企业级应用具有很强的伸缩性，它允许每层专注于特定的角色。例如，让WEB服务器负责提供页面，应用服务器处理应用逻辑，而数据库服务器提供数据库服务。
由于J2EE建立在JAVA2平台标准版（J2SE）的基础上，所以具备了J2SE的所有优点和功能。包括“编写一次，到处可用”的可移植性、通过JDBC访问数据库、同原有企业资源进行交互的CORBA技术，以及一个经过验证的安全模型。在这些基础上，J2EE又增加了对EJB（企业级JAVA组件）、JAVA SERVLETS、JAVA服务器页面（JSPS）和XML技术的支持。
有了上面的介绍，如果不纠缠于细节技术的实现（这样才有架构师的气魄），脑子里应该就有了如下的J2EE体系结构图：所有实现J2EE规范的Application Server都必须完成完全的web Container与EJB Container功能。有关Application Server 的选择和比较在[url=http://www.csdn.net/editor/Editor.htm#_第一节__环境的选择]下文有更详细的介绍。
（图２）
第二节J2EE技术的模式观
在学习了Java后学习J2EE，一般人都会有这样的感觉：入门很容易，但是要向前进一步似乎像赶鸭子上架，很难。原因在哪里？本质上说，是没有理解J2EE，不知道他里面到底体现了什么，仅仅知道他的组成部分虽然是必须的，但是却不是足够的。我们需要用一种全新的眼光来审视这种祥和的技术，可以这么说，本质上J2EE是一种框架结构，框架就是骨架的意思。他不同于我们学习的Java语言，我们在学习Java语言时候用的是API，那是工具箱。而J2EE不同，它的应用领域是一开始就定义好了的，所谓Java Two Enterprise Edition，就是说让Java用于企业领域。既然领域定好了，它就自然可以定义一套在这一领域不变的架构。如它定义了JTA、JDBC和EJB可以用来处理企业的事务要求、大量的数据库操作需求等。企业一般要用到邮件订阅、消息处理，可以使用J2EE技术里有机结合的JMS，企业安全性要求比较高，J2EE提供系统的安全解决方案，它定义了JAAS等。实际上，各种技术是一个整体并且可伸缩，每个J2EE应用都是按照其体系结构提供有机的J2EE技术组装。例如表示层技术典型的可以用JSP作配件，非典型的可以用WAP作配件，不管怎样他们都是J2EE的脸面；业务层技术典型的可以是EJB，非典型的可以是servlet甚至JSP，这些才是业务处理逻辑的核心技术，往往安全性等要求很高；资源层连接典型的是JDBC，非典型的用JDBC-ODBC等。从上面可以看到，J2EE在设计上就是框架结构导向的技术――只不过这种框架结构有极强的伸缩性和可扩展性。框架结构意味着一种思想的实现，大的方面J2EE广泛应用于企业计算，据信国外1998年后出现的门户大多采用J2EE技术。模式为在框架内构成高效的内容提供支持。广义上J2EE还是MVC模式的一种实现。上图中客户端得到View，中间层是Controller，后台则是Model。所以，在企业应用这种情境下，J2EE可以采取不同的适合情境应用的解决方案（使用各种套件）。不变的东西已经定义好了，变化的则交由程序员来处理。有人也许会想起.Net，实际上她也是一套框架结构，可以说成是“超级（抄袭）模式”应用框架结构：－:）。
下面我们用模式的眼光来审视J2EE架构的特点（注意并不是每个框架都有这样的特点的，J2EE灵活性做到了最大）：
首先，灵活性。灵活性意指这种结构或模式是不依赖于任何实际应用，应该与操作系统、应用程序无关。提供独立的结构，可以提供最大的重用。
其次，可扩展性。新技术的发展是很快的。试想一个基于现有J2EE技术的应用，如果哪天JDO被引入规范，这种应用还是基于“J2EE”的吗？即J2EE的扩展会不会影响已有的应用的问题。可扩展性的应用架构是不会影响已有的应用的。J2EE的分层实现思想提供了各种技术的平滑过渡。
再次，可伸缩性。对于集群应用，这种功能要求体系的一览无余。迄今为止，除了在操作系统级集群能作的比较好外，在应用级恐怕只有J2EE能够很好的做到这一点了。
然后，可配置性。应用本身是变化的，因为需求随着人员的调用、业务的增长在不断变化。这样在配置应用时就需要有一定的灵活性。例如资源的访问控制，以前只有少许几个WEB资源，可以提供给大多数人访问；随着业务的扩展，新的业务不断增加，业务逻辑自然增加，这种资源的控制就需要一套灵活的机制来做调配。在J2EE中XML文件可以提供这种灵活的控制。
最后，安全性。进来由于网络环境的改善，网络应用呈爆炸式增长。在网络上一个基本的问题就是安全。一个安全的应用应该提供统一的用户访问控制即提供单入口点。J2EE天生为网络环境而诞生。J2EE模式中前端控制器等可以实现要求的安全控制。
