J2EE架构下系统设计模式

1.1  J2EE 应用模型

J2EE 提供了一个企业级的计算模型和运行环境用于开发和部署多层分布式结构的应用模型。该模型具有重用组件的能力、基于扩展标记语言 (XML) 的数据交换、统一的安全模式和灵活的事务控制。它通过提供企业计算环境所必需的各种服务，使得部署在 J2EE 平台上的多层应用，可以实现高可用性、安全性、可扩展性和可靠性。

1.1.1 J2EE框架

目前，Java 2平台有3个版本，它们是适用于小型设备和智能卡的Java 2平台Micro版（Java 2 Platform Micro Edition，J2ME）、适用于桌面系统的Java2平台标准版（Java 2 Platform Standard Edition，J2SE）、适用于创建服务器应用程序和服务的Java2平台企业版（Java 2 Platform EnterpriseEdition，J2EE）。

J2EE 是一种利用 Java 2 平台来简化企业解决方案的开发、部署和管理相关的复杂问题的体系结构。 J2EE 技术的基础就是核心 Java 平台或 Java2 平台的标准版， J2EE 不仅巩固了标准版中的许多优点，例如 " 编写一次、随处运行 " 的特性、方便存取数据库的 JDBC API 、 CORBA 技术以及能够在 Internet 应用中保护数据的安全模式等等，同时还提供了对 EJB （ Enterprise JavaBeans ）、 Java Servlets API 、 JSP （ Java Server Pages ）以及 XML 技术的全面支持。其最终目的就是成为一个能够使企业开发者大幅缩短投放市场时间的体系结构。

1.1.2 多层分布式结构的应用模型

J2EE 平台采用一个多层次分布式的应用模式。这意味着应用逻辑根据功能被划分成组件，组成 J2EE 应用的不同应用组件安装在不同的服务器上，这种划分是根据应用组件属于多层次 J2EE 环境中的哪一个层次来决定的。图 1 展示了两个多层次 J2EE 应用划分成在下面的表中描述的不同层次。图 1 中表示的 J2EE 应用部分代表了 J2EE 应用组件。

• 运行在客户机器上的客户层组件

• 运行在 J2EE 服务器上的 Web 层组件

• 运行在 J2EE 服务器上的业务层组件

• 运行在 EIS 服务器上的企业信息系统层软件

如图 1 所示， J2EE 应用可以由三或四个层次组成， J2EE 多层次应用一般被认为是三层应用，因为它们是被分布在三个不同的地点：客户端机器、 J2EE 服务器和数据库或后端的传统系统服务器。三层架构应用是对标准的客户端 / 服务器应用架构的一种扩展，即在客户端应用和后台存储之间增加一个多线程应用服务器。  

 

 

 

 

 

 

 

 图1：多层应用

1.3 J2EE 架构

通常，瘦客户端多层次应用是很难编写的，因为它包括很多行非常难以理解的代码，以处理交易和状态管理，多线程，资源池管理，以及其他复杂的低层次细节问题。基于组件的、与平台无关的 J2EE 应用的开发是很容易的，因为业务逻辑被组织成可重复使用的组件，而且 J2EE 服务器以容器 (Container) 的形式为每种类型的组件提供后台支持。由于你不必自己开发这些服务，你可以专注于解决你面临的业务问题。

1.3.1 容器（ container ）和服务

组件在部署时被安装在容器之中，是组件和特定平台底层功能之间的接口支持着组件。在 Web ，企业 Bean 或者应用客户端组件能够被执行以前，它必须被组装到 J2EE 应用里，并且被部署到它的容器里。组装流程包括设定 J2EE 应用中的每一个组件以及 J2EE 应用本身在容器之中的设置。容器的设置个性化了 J2EE 服务器对每个组件的后台支持，包括像安全性、交易管理、 Java 命名和目录接口查询，以及远程连接等等。这里是一些重点：

• J2EE 安全模式，使你能够配置 Web 组件或企业 Bean ，使系统资源只能被授权的用户访问。

• J2EE 交易模式，使你能够指定方法之间的关系，从而组成一个交易，这样交易中的所有方法将被作为一个单元对待。

• JNDI 查询服务，为企业中多种命名和目录服务提供统一的接口，这样应用组件就可以访问命名和目录服务了。

• J2EE 远程连接模式，管理客户端和企业 Beans 之间的底层通讯。在企业 Bean 被创建后，客户端调用它的方法，就像它在同一个虚拟机上一样。

实际上， J2EE 架构提供可配置的服务，意思是在同一个 J2EE 应用中的应用组件可以根据他们部署的位置不同，表现不同。一个企业 Bean 可以通过不同的安全设置，是它在一个生产系统中获得一种层次的数据库数据访问，而在另一个生产系统中，则获得另一种数据库访问权限。

容器还管理着不可配置服务，如企业bean和Servlet的生命周期，数据库连接资源池，数据持续性（persistence），以及J2EE API中描述的访问J2EE平台的API。 尽管数据持续性机制是一个不可配置服务， J2EE 架构允许你在需要比缺省的容器管理的持续性机制更多的控制时，用你的企业 Bean 实现中的相应的代码覆盖原有的容器管理的持续机制。例如，你可以使用 Bean 管理的持续性机制来实现你自己的搜索方法，或创建个性化的数据库缓存。

1.3.2 容器类型

在部署过程之中， J2EE 应用组件被安装在如下类型的 J2EE 容器中。本文中涉及的 J2EE 组件和容器参见图 5 。

企业JavaBeans(EJB)容器，为J2EE应用管理着所有的企业Beans。企业Bean和它们的容器运行在J2EE服务器上。

Web 容器，为 J2EE 应用管理着所有的 JSP 页面和 Servlet 组件。 Web 组件和它们的容器运行在 J2EE 服务器上。

应用客户端容器，为 J2EE 应用管理着所有的应用客户端组件。应用客户端组件和它们的容器运行在客户端机器上。

applet 容器，是 Web 浏览器和 Java 插件的组合，运行在客户端机器上。

                    

 

 

 

 

 

 

 

 

图 5 ： J2EE 服务器和容器

1.3.3 包装

J2EE 组件是单独包装的，为部署而捆绑到 J2EE 应用中。每个组件，其相关的文件如 GIF 和 HTML 文件，或者服务器端应用类，以及部署描述，被集成一个模块并添加到 J2EE 应用中。 J2EE 应用是由一个或多个企业 Bean ， Web ，或应用客户端组件模块组成的。最终企业解决方案可以使用一个 J2EE 应用或根据设计需要由两个或更多的 J2EE 应用组成。

一个 J2EE 应用以及它的每一个模块都有它自己的部署描述。部署描述是一个 XML 文本文件，带有 .xml 后缀，描述组件的部署设置。一个企业 Bean 的部署描述，例如，声明交易属性，和企业 Bean 的安全认证。由于部署描述的信息是可以声明的，这样它可以在无需修改 Bean 的源代码的情况下，进行修改。在运行时， J2EE 服务器读取部署描述，并依次对组件进行操作。

J2EE应用以及相关的模块是在一个Enterprise Archive(EAR)中发送的。EAR文件是一个标准的JAR文件，以.ear后缀结尾。在GUI版的J2EE SDK应用部署工具集中，你先创建一个EAR文件，在添加JAR和WAR到EAR中。如果你使用命令行打包工具，则先创建JAR和WAR文件，然后创建EAR文件。J2EE SDK工具：

• 每个 EJB JAR 文件包含它的部署描述，相关文件和企业 Bean 的 .class 文件

• 每个应用客户端 JAR 包含它的部署描述，相关文件和应用客户端的 .class 文件

• 每个 WAR 文件包含它的部署描述，相关文件和 servlet 的 .class 文件以及 JSP 页面的 .jsp 文件

使用模块和 EAR 文件使使用一些相同的组件组装多个不同的 J2EE 应用成为可能。无需额外的编程，只是把不同的 J2EE 模块组装到 J2EE EAR 文件中。

1.4 J2EE API

Java 2 平台标准版（ J2SE ） SDK 在运行 J2EE SDK 时是必需的，它为编写 J2EE 组件提供核心 API ，核心开发工具，以及 Java 虚拟机。下面介绍科研管理系统中所涉及到的 API 。

1.4.1 企业 JavaBeans 技术 2.0

一个企业 Bean 是一段包含域和方法的代码体，用于实现业务逻辑的一个模块。你可以认为企业 Bean 是一个构建模块，可以单独使用或与其他企业 Beans 一起在 J2EE 服务器上执行业务逻辑。

由三种类型的企业 Bean ： Session Bean ，实体 Beans ，和消息驱动 Beans ，这些在业务组件中描述过。有了实体 Beans ，你无需编写任何 SQL 代码或直接使用 JDBC API 执行数据库访问操作。 EJB 容器替你处理这些。当然，如果你不管因为任何原因，覆盖了却省的容器管理持续性机制，你将需要使用 JDBC API 。同样，如果你选用 Session Beans 访问数据库，你必须使用 JDBC API 。

1.4.2 JDBC 2.0 API

       JDBC 是为 java 语言定义的一个 SQL 调用级（ CLI ）界面，也就是说其中心在于执行基本的 SQL 声明和取回结果。在此基础上可以定义更高层次的 API ，其中的接口包括直接将基本表与 JAVA 中的类相对应，提供更多的通用查询的语义树表示，以及 JAVA 语言的嵌入式 SQL 语法等。

1.4.3 Java Servlet 技术 2.3

Java Servlet 技术为你定义 HTTP 专用的 servlet 类。一个 Servlet 类扩展了服务器的能力，这个服务器存放着应用，而应用是以请求 - 响应编程模式被访问的。尽管 Servlet 可以响应任意形式的请求，但是它通常被用于扩展 Web 服务器存放的应用。

1.4.4 JavaServer Pages(JSP) 技术 1.2

JSP 页面技术是你能够在基于文本的文件中结合小段的 Java 编程语言代码和静态内容。一个 JSP 页面是一个基于文本的文件，它包含两种类型的文本：静态模板数据，它可以表示为任何基于文本的格式，如 HTML 、 WML 和 XML ； JSP 元素，决定这个页面如何构造动态内容。

1.4.5 JavaMail 技术 1.2

很多互联网应用需要发送邮件进行确认，所以 J2EE 平台包含了与 JavaMail 服务提供商配合使用的 JavaMail API ，这样，应用组件可以使用它发送邮件。 JavaMail API 包含两个部分：一个是应用层接口，应用组件使用它发送邮件；一个服务提供商接口。

1.5 MVC 设计模式

MVC设计模式起源于Smalltalk语言，它由以下三个部分组成：模型（model）,视图（view），控制器（Controller）。

Model ： 模型指的是真正完成任务的代码，包含应用系统的核心功 能表示一个应用系统的数据，并且包含访问、维护和管理这些数据的逻辑。所有属于应用系统持久状态的数据都应该保存于模型对象里。模型提供的服务必须足够适用于不同的终端。一个模型聚集了相关的数据和操作，以提供 一个详细而精确的服务 ; 这些被封装在操作中的抽象事物的功能被模型化。一个模型的接口提供了访问和更新模型状态，执行封装在模型中的复杂进程 的方法。模型服务被控制器访问，用于查询或更改模型的状态。当模型状态 发生变化时，模型会通报给视图。对大多数 Web 应用程序而言，功能比界面 感觉更重要。在模型同界面分离的情况下，代码即可实现可管理性和可重用 性。例如，在一个保险应用程序中，模型就是处理计算保险费和同数据库交互的那些业务代码。模型通常也被称作业务逻辑。

View : 视图表示模型的状态，是应用系统的外观，当模型发生改变时， 视图也将随之改变，以维持系统数据的一致性。在 MVC 模式下，通常的设计 前提是界面任务较小。当然视图也应该具有一定的功能性并遵守可用性的约 束，但视图界面不应当处理数据。事实上，视图的每一部分都只能包含采集 数据的逻辑，并把采集到的数据传递给设计模式中的其他组成部分进行处 理。

Controller : 控制器是联系模型与视图之间的纽带，控制模型和视 图之间的交互过程。它获取并翻译用户输入的动作，指定执行该动作的模型， 或者根据用户的输入和执行的结果来选择下一个视图。

MVC 通过建立一个 “ 订购 / 通知 ” 协议来分离视图和模型。视图必须保证它的显示正确地反映了模型的状态。一旦模型的数据发生变化，模型将通知有关的视图，每个视图相应地得到刷新自己的机会。这种方法可以让一个模型提供不同的多个视图表现形式，也能够为一个模型创建新的视图而无须重写模型。

1.5.1 MVC 的优点

(1) 因为视图与模型分离，而且模型与视图之间没有直接依赖性，所以用户界面可以同时显示同一数据的多个视图。例如， Web 应用程序中的多个页面可以使用同一模型对象。变化一传播机制可以确保所有相关的视图及时 得到模型数据变化，从而使所有关联的视图和控制器做到行为同步。

(2) 视图与控制器的可接插性，允许更换视图和控制器对象，而且可以根据需求动态的打开或关闭、甚至在运行期间进行对象替换。

(3) 模型的可移植性。因为模型是独立于视图的，所以可以把一个模型独立地移植到新的平台工作。需要做的只是在新平台上对视图和控制器进 行新的修改。

(4) 潜在的框架结构。可以基于此模型建立应用程序框架，不仅仅是 用在设计界面的设计中。

1.5.2 MVC 的缺点

(1) 增加了系统结构和实现的复杂性。 MVC 模式引入了新的间接级别， 因此稍微增加了解决方案的复杂性。它还增加了用户界面代码的事件驱动特 性，调试用户界面代码会变得更加困难。

(2) 视图与控制器间的过于紧密的连接。视图与控制器是相互分离，但确实联系紧密的部件，视图没有控制器的存在，其应用是很有限的，反之亦然，这样就妨碍了他们的独立重用。

(3) 视图对模型数据的低效率访问。依据模型操作接口的不同，视图可能需要多次调用才能获得足够的显示数据 . 对未变化数据的不必要的频繁访 问，也将损害操作性能。

(4) 频繁更新的成本。将模型与视图分离并不意味着模型的开发人员可 以忽略视图的特性。例如，如果模型发生频繁更改，则它可能向视图发出大 量更新请求。一些视图 ( 如图形显示 ) 的显示可能需要一定时间。因此，视 图可能滞后于更新请求。因此，在对模型进行编码时牢记视图是很重要的。 例如，模型可以将多个更新作为单个通知发送到视图。

                                模型     

            查询状态

                     向视图通知模型          在模型的公共

                       状态中的改变                    API 中调用方法

 

    视图          选择视图               控制器

             用户动作/命令

                      方法调用

         事件

图6     MVC 的体系结构

1.6 Struts对MVC实现

模型（ The Model ）

Struts框架没有提供特定的模型组件。

视图（ The View ）

Struts 框架中 视图组件对应于一个简单的 JSP 文件，这个 JSP 文件包含了 Struts 定义的标签，几个 JSP 的标签是 JSP 文件中的重点。这些标签在 Struts 框架中定义，它使 struts 应用项目和控制器之间实现松耦合。

控制器（ The Controller ）

控制器是Struts框架中的中枢，它由 org.apache.struts.action.ActionServlet 这个servlet来贯彻和执行的。这个 org.apache.struts.action.ActionServlet 接收所有客户端的请求，并把请求委派到指定的Action类(用户扩展自 org.apache.struts.action )。ActionServlet委派请求是基于客户端传入的URI。一旦Action类完成处理，ActionServlet根据Action返回的键值来决定在什么视图中显示Action的类处理结果。ActionServlet类似于一个创建Action对象的工厂，由Action对象去执行应用中实际的业务逻辑。控制器是Struts框架中最重要的部分。

1.6.1 Struts的运行过程

下面是 一幅和 MVC 模式对应的 STRUTS 框架图

 视图（view1）                                   

                                              Action1

                                                   

                                              Action2

                   ActionServlet              Action3

                     (控制器)

                                              Action4

                                                  

视图（view2）                                          模型(Model)

 

      　　　　　　　　　图 7  STRUTS 框架图

图 7 是 Struts 框架下应用程序请求流通过的路径。这个处理过程由 5 个基本的步骤组成。

下面是 处理步骤的描述。

1 ． 由显示视图产生一个请求。

2．  请求被ActionServlet（控制器）接收，它在struts-config.xml文件中寻找请求的URI，找到对应的Action类后，Action类执行相应的业务逻辑。

3 ．  Action 类执行建立在模型组件基础上的业务逻辑，模型组件是和应用程序关联的。

4．  一旦Action类处理完业务逻辑，它把控制权返回给 ActionServlet。，Action类提供一个键值作为返回的一部分，它指明了处理的结果。ActionServlet使用这个键值来决定在什么视图中显示Action的类处理结果。

5．  当 ActionServlet把Action类的处理结果传送到指定的视图中，请求的过程也就完成了。

 

                 HttpServlet                                          FrowardConfig

   <<front controller>>

org.apache.struts.action.ActionServlet                     org.apache.struts.action.ActionForWard

 

 

 

  <<dispatcher>>                                                     ActionConfig

 org.apache.struts.action.RequestProcessor                   org.apache.struts.action.ActionMapping

 

 

                      Serializable

           <<view helper>>                                <<request handler>>

   org.apache.struts.action.ActionForm                                org.apache.struts.action.Action

 

图8 Struts中MVC实现

 

图 8 中各个类的语义

1．  ActionServlet类：实现控制器,Struts必需的配置在ActionServlet.init()方法中加载。ActionServlet将所有的输入请求委托给RequestProcessor.

2．  RequestProcessor类：分配器,所有输入的请求都被控制器委托给分配器(dispatcher).

3. ActionForm类：存储表单数据，由ActionForm派生出来的对象用于存储请求对象中的参数，因此它们和用户是紧密耦合的。

4. ActionForward类：ActionForward对象是配置对象。这些配置对象有唯一的标识符，以使它们根据有意义的名称进行寻找。 ActionForward 对象封装提交的 URL 路径，它被请求处理程序用来标识目标视图。

5. ActionMapping类：它提供了引入的请求和相应的请求处理程序之间的映射。

6.Action类：请求处理程序。Action类的子类作为适配器用于引入的请求和模型之间。 Action 类的子类是为每个请求单独创建的。 Action 的基类提供了访问与框架相关的资源的公共函数，以及保存由它的子类的 exectue(…) 方法进行检查而得到错误的方法。

1.6.2 Struts 的主要组件：

1.6.2.1 控制器对象

控制器语义有 ActionServlet 。控制器语义提供了处理所有客户请求的中心位置。这就为控制器层提供了一个清楚的工作分配情况，控制器层主要的工作是处理试图和导航管理、将模型访问和操作交给有特定请求的请求处理程序（ Command 对象 [Gof] ）。所有引入的请求被映射到部署描述符的中心控制器上。

1.6.2.2 分配器对象

RequestProcessor 作为一个分配器运行，并通过实例化（或重用）一个请求处理和对应的表单 bean 来处理客户机请求。创建的错误或是表单 bean 和请求处理程序抛出的异常（由 RequestProcessor 处理），影响了 RequestProcessor 的视图管理功能。表单 bean 帮助 RequestProcessor 存储表单数据和分段传输视图需要的中间模型数据， RequestProcessor 使用 <action> 声明实例化特定请求的请求处理程序。

1.6.2.3 请求处理程序

Action 类的子类作为适配器用于引入的请求和模型之间。请求最初由 RequestProcessor 截获， RequestProcessor 则实例化一个对应的请求处理程序。这个从 Action 类继承而来的对象（也称为请求处理程序）是为每个请求而特别创建的。客户机请求封装请求 URI 中所需的动作作为 servlet 路径，该路径信息随后有分配器（ RequestProcessor ）提取，从而创建相应的请求处理程序来处理程序实例。命令模式将 URI 从请求