Java EE架构原理探秘及企业级应用
在之前的文章中我们曾介绍过Java企业级应用架构设计中的分布式结构，在实际的项目中，开发n级分布式应用是一项复杂且富有挑战性的工作，需要对Java EE架构的原理深入掌握，并将其运用到企业级应用的开发中去。
Java EE架构
将处理过程拆分到不同的级中分别处理，可以使资源得到更好的利用。同时我们还可以将工作分配给适合开发某一级程序的最佳人选。以网页设计师为例，他们就更适合在网页服务器上进行表现层的开发；而另一方面，数据库开发人员则可以把精力集中于存储过程与函数的开发。然而，简单的将各级相互隔离开并不能满足我们的需求。为了最终满足企业的需要，我们必须把这些级整合起来。选择使用最有效的协议对成败至关重要，错误的选择将会导致严重的性能降低。
除了系统整合之外，分布式应用还需要各种各样的服务。它必须能够创建、参与或者管理与不同信息系统之间进行交互时的事务（transaction），这一点对于保证企业数据的并发性绝对必要。因为n级结构是通过互联网进行访问的，因此使用强大的安全服务阻止恶意访问就变得至关重要。
今时今日，如CPU、内存之类的硬件价格已经有了极大地下降，但是局限仍然存在，比如处理器能够支持的内存总容量。因此，我们就有必要优化系统资源的使用。现代分布式应用通常是建立在面向对象技术之上的，因此诸如对象缓存或者缓冲池之类的功能就变得非常方便。这些应用会经常与关系数据库或者其他信息系统――比如面向消息的中间件――进行交互。然而，建立与这些系统之间的连接代价很大，因为它会消耗大量的处理资源从而严重影响系统性能。在这种情况下，“连接池”就变得非常有用，它既可以提高系统性能，又可以优化资源的使用。
典型的分布式应用会通过中间件服务器调用一些系统服务，例如事务、安全以及缓冲池等。想要访问这些服务，就必须使用这些中间件服务器的应用程序接口（API），因此，编写出的应用代码中就必须掺杂进某个特定的API。这种内置服务提供商API的方式浪费了大量的开发时间，并且使得维护变得非常困难，同时也限制了其扩展性。
到了1999年，Sun 微系统公司发布了Java EE 2平台，以解决企业级多级应用开发中的难点问题。这个平台基于Java平台标准版本2（Java Platform, Standard Edition 2），因此它也可以实现“编写一次就可以在任何地方部署运行”。Java EE2一经发布就迅速得到了来自开源社区以及主要商业供应商――如IBM、Oracle、BEA等――的极大支持，而其原因，就在于Java EE2是基于技术规范的，任何人只要遵从技术规范的内容，就可以开发出自己的服务程序。而Java EE规范与平台也从此开始不断发展，如今其平台已经基于Java平台标准版本5（Java Platform, Standard Edition 5），其名称也改为Java平台企业版5（Java Platform, Enterprise Edition 5）。在本文中，我们将集中讨论最新版本，其官方名称为Java EE 5。
Java EE平台通过一个基于“容器”（container）的结构提供必要的系统服务。容器向使用Java编写的面向对象应用程序组件提供运行环境，并提供一系列的底层服务，例如：安全、事务、生命周期管理、对象查找与缓存、持久化以及网络通讯等等。这种方式有利于明确分工，系统程序员只管负责开发底层服务，而应用程序员就可以把更多的精力放在业务及表现逻辑的开发上面。
如图1所示，在服务器端共存在两种容器：
◆Web容器（web container）。Web容器中装载着表现组件，例如Java服务器页面（JSP）以及小服务程序（servlet）等。而这些组件又可以通过远程协议与EJB容器进行交互。
◆EJB容器（EJB container）。EJB容器控制着企业级JavaBean（EJB）组件的运行。
图1. Java EE平台架构（图中文字：Web Browser――网络浏览器；Java Server Pages――Java服务器页面“JSP”；Java Servlets――Java小服务程序“Servlet”；Web Container――Web容器；Application Client Container――应用客户端容器；Application Client――应用客户端；Enterprise JavaBeans――企业级JavaBeans“EJB”；EJB Container――EJB容器；Java EE 5 Application Server――JavaEE5 应用服务器；Java 5 Virtual Machine――Java5虚拟机）
在客户端方面，独立的客户端程序是一个Java核心应用程序，通过网络与EJB容器连接；而如果用户使用网络浏览器，则通常浏览器会通过HTTP协议与Web容器进行交互。EJB容器和Web容器都来自Java EE应用服务器，而服务器程序本身又运行在Java虚拟机（JVM）之上。
不同的容器提供不同类型的底层服务，比如Web容器不提供对事务的支持，而EJB容器则正相反。容器所提供的服务可以通过标准的JavaEE API进行访问，例如Java消息服务（JMS，Java Message Service）、Java命名与目录接口（JNDI，Java Naming and Directory Interface）、Java持久化API（JPA，Java Persistence API）以及Java事务API（JTA，Java Transaction API）（译注：作者可能自己写晕了，JTA写了两遍。。。）等等。这些服务的最大优点是，应用组件可以透明地调用它们而且不需要太多配置改动。如果想插入这些服务，应用组件需要与一个XML格式的部署描述文件一起封装进一个预定义好的归档文件。这种方式有效地减少了部署时间，也简化了维护工作。
Java EE的应用架构
Java EE平台简化了n级分布式应用系统的开发，应用组件可以根据功能的不同被轻松划分到不同的级上运行，不同级上的组件都要通过一个构建好的架构准则实现相互间合作，而这个架构就是MVC。
MVC概览
MVC第一次被提出要追溯到1979年Trygve Reenskaug在他的一篇名为《Smalltalk-80™应用程序开发：如何使用模型―视图―控制器结构》的论文中对它的描述。最初它主要是作为一种分离用户接口逻辑与业务逻辑的策略被设计出来的。然而，只是简单的将二者分离开无法实现有效的功能，还需要加入一个间接层以连接并协调表现层与业务逻辑层。而这个新的层就被称作“控制器层”。就这样，MVC结构将应用程序划分成了3个独特又相互协作的组件：
◆模型。模型通过业务逻辑管理应用中的数据。
◆视图。视图负责应用程序的数据显示以及向用户提供控制选项，使用户可以与系统进行进一步交互。
◆控制器。控制器负责模型与视图之间的协调。
图2描述了这三个组件之间的关系。控制器截获任何由用户操作出发的事件；根据用户操作的类型，控制器调用模型以应用与之匹配的业务逻辑然后修改相应的应用数据；之后控制器选择一个视图组件向终端用户展示修改之后的应用数据。从这个过程中你可以看到，MVC提供了一种明确应用程序中各部分职能的方法。通过这种分离方式，多个视图以及控制器就可以同时与一个模型一起工作了。
图2. 模型―视图―控制器（图中文字：Apply business rules――应用业务逻辑；Modify application data――修改应用数据；User Actions――用户操作；Select view――选择视图；Display changed application data――显示修改后的数据；Model――模型；Controller――控制器；View――视图）
使用MVC结构的Java EE架构
目前的企业级应用开发中，MVC被广泛使用。MVC的概念可以很容易地被用来构建Java EE应用架构的基础。Java EE的Servlet技术作为控制器就非常完美。任何浏览器请求都可以通过HTTP协议发送给Servlet，之后Servlet作为控制器可以调用EJB模型组件。这些模型组件内部封装了业务逻辑并可以对应用数据进行操作，而处理过的企业数据之后可以通过JSP表现给用户。这是真实生活中企业级Java应用架构的一个最简范例，尽管这种结构只在很小的范围内能够有效工作，但是它仍然对应用的开发具有重大的意义。如果你能让不同技术领域的专业人员一起工作，你的风险就会降低，而生产力就会提高。除此之外，任何一层的替换都是透明的，你可以轻易的加入新的功能而不需要修改其它层（参见图3）。