当前页面: 开发资料首页 → J2EE 专题 → 为J2EE准备良好的应用架构
为J2EE准备良好的应用架构
摘要: J2EE 架构 模式
RUP （统一软件过程）有如下需求定义：一项需求描述了系统必须符合的条件或提供的能力，它可直接来自用户，并在合同、标准、规范等一些正式的文档中标出。
需求可以分为两类，分别为架构需求和业务性功能需求。架构需求是那些影响系统构架的需求，具有普遍性，如对于一个维护子系统，要有安全保障、可靠性高、良好的可扩展性及跨平台。业务性功能需求为系统主要解决的业务问题，具有特殊性，如网上报税、网上订票等。
随着应用不断向分布式和大型规模发展，架构需求越来越成为系统开发和实施的核心。比如电子政务就明确提出“应用支撑平台”的概念，包括公文交换、旧系统集成、工作流、报表打印和单点登陆等。J2EE规范和基于此规范的技术，是实现架构需求的、具有良好竞争力的选择。
J2EE Web应用程序架构（就像在Windows平台中的MFC）经历了较长时间的发展，这个路程主要经历了模型1和模型2两大阶段。
模型1
模型1其实不是一个稳定架构，甚至谈不上形成了架构。模型1的基础是JSP文件，JSP文件从HTTP的请求中提取参数、调用相应的业务逻辑、处理HTTP会话，最后生成HTTP文档。一系列这样的JSP文件形成一个完整的模型1应用，当然可能会有其它辅助类或文件。早期的ASP和 PHP技术就属于这个情况。
总的看来，这个模型的好处是简单，但是它把业务逻辑和表现混在一起。对大型应用来说，这个缺点是让人容忍不了的。
模型2
模型2在客户级应用和JSP或Servlet之间插入了一个控制组件。这个控制组件集中了处理客户级应用发过来的HTTP请求的分发逻辑。也就是说，它会根据HTTP请求的URL输入参数和目前应用的内部状态，把请求分发给相应Web级的JSP或Servlet。另外，它也负责选择下一个视图（在J2EE中，JSP和Servlet会生成返回给浏览器的HTML从而形成视图）。集中的控制组件有利于安全验证和记录日志，因为有时它也给下面的Web Tier封装请求数据。这一套逻辑的实现形成了一个像MFC的应用框架（如图1）。
目前，对于基于组件、所覆盖的技术不断膨胀的J2EE体系主要采用MVC模式，这种技术就是由模式2实现的。
MVC模式
在经过一番实践，并广泛借鉴和总结经验教训之后，J2EE应用程序终于迎来了MVC（模型-视图-控制）模式。MVC模式并不是J2EE行业人士标新立异的。MVC的核心就是要做到三级甚至多级的松散耦合。
应用系统有两类：交互式和工作流式。前者需要大量地和使用者交互，后者只需少量使用者的介入，甚至可以完全在后台运行。在B/S网站式应用程序中，使用者通过提交请求与网站交互，访问设备不断地显示页面相应请求，这是一个典型的交互式应用。架构设计师在设计这样的应用时普遍采用MVC模式。
MVC模式把涉及数据管理和显示的功能分散到不同的对象上，降低对象间的耦合。它把应用分成三部分，分别为模型、视图和控制，并且尽量降低部分间的耦合。每一部分处理特定的任务，并负责完成与其它部分的通信。
其中模型部分代表了商业数据和访问及修改数据的操作。当数据发生改变时，它要负责通知视图部分，并且提供视图查询状态的能力。另外，它还向控制提供应用功能。
视图部分以自己的方式显示模型的内容。它访问模型的数据，并且当模型的数据发生变化时更新模型的显示。视图还把从用户那里得到的信息传给控制部分。
控制部分定义了应用的行为。它分发用户请求和选择表现视图，还负责解释用户输入，进而调用模型的功能。在独立GUI程序中，用户输入包括鼠标点击和菜单选择，在Web应用中，用户输入包括对Web级资源的HTTP GET和POST请求。控制部分根据用户交互和模型的状态选择要显示的视图。一个应用程序一般为相关的功能选择一个控制。
图2显示了一个MVC应用中三部分的关系。在模型、视图和控制三者之间分配职责有助于减少代码重复、降低维护难度。因为商业逻辑和数据分离无论是在增加数据源，还是在改变数据表示时，操作都变得相对简单，而且不需要改变业务逻辑，另外增加新的客户类型也变得很容易。
架构立方图从三个纬度剖析J2EE系统，这三个纬度分别是级、层和能力度。
多层划分
大家一定忘不了硬件裸机、操作系统及应用程序的划层思想，也一定忘不了ISO网络协议的七层模型。在架构立方图中(如图3)，下层平台指操作系统层，上层平台指J2EE应用服务器，虚拟平台指一些API和组件提供商的组件，应用程序指为解决某种用户需求开发的项目应用。组件提供商的中间件组件，如SilverStream的Director可以定位在虚拟平台层。
能力度划分
能力度为一系列的Ablity要求。一般情况下，设计模式主要考虑这些Ablity要求。在设计应用时，能力度方面的考虑是一个权衡各种因素的过程。
多级应用
平时人们讲的三层结构在这里应是五级结构，图4为J2EE体系中典型的多级应用体系，划分的五级分别是：
◆ Client Tier客户级,一般为浏览器或其它应用，以及在这些浏览器上运行的程序。客户层普遍地支持HTTP协议，也称客户代理。
◆ Web Tier Web应用级,在J2EE中，这一级由Web 容器运行，包括JSP和 Servlet等Web部件。
◆ EJB Tier 企业组件级，企业组件级由EJB容器运行，它支持EJB技术。
◆ EAI Tier 系统集成级，包括JDBC、Web Services、JavaMail、JINI、JMS及JTA，这一层要么在两端有相应的联络站，要么中间设一个系统负责协调、集中数据和控制，如Web Services注册服务器、邮件服务器等。
◆ EIS Tier 企业信息系统级,企业信息系统包含企业内传统信息系统，如财务系统、CRM系统等，特点是有数据库系统的支持。
Web应用框架（比如Struts、JSF）目前主要集中在Web级，旨在规范这一层软件的开发。
客户级
在实现应用程序的客户级时，需要考虑网络、安全和平台等方面的因素。
1. 网络
网络方面应主要考虑如下方面：
◆ 非零时间的网络延迟；
◆ 有限的带宽；
◆ 不可靠的网络。
好的客户端应该具备如下功能：
◆ 必要时才连接服务器；
◆ 在网络上只传递必要的数据；
◆ 不能连接服务器时也能比较好地工作。
2. 安全
我们必须考虑客户端与防火墙的关系，因此有些客户端技术不能通过防火墙。
如果客户端在企业外部，在验证等安全问题方面就需要加强。
3. 平台
我们要考虑平台的计算能力，比如浏览器一般用来浏览，这样针对浏览器的Web级程序就不能返回简单的数据，它必须返回HTML等浏览器能表现的文档。而独立的应用程序可以下载数据，并且可以绘制各种各样的表现。
另外一个要考虑的是平台的尺寸。桌面PC能一次显示很多的内容，并且有键盘和鼠标等输入设备。而移动手机则不具备这些条件。在设计针对手机的客户端内容时，就不能有很多的输入和很大的显示版面要求。
4. 支持多客户的设计
Web应用程序可以只支持一种协议的单类型客户端，也可以支持具有不同协议、安全策略、表现逻辑和工作流程的多类型客户端。Web客户端可能包括一些不同浏览器的不同版本，如MIDP（Mobile Information Device Profile）客户端和独立程序的客户端。长久的应用程序设计应该能支持新类型的客户端。
每一类客户端都需要自己的控制器，有些客户端由于尺寸因素还需要不同的视图组件。多控制提供了支持将来任意客户端类型的扩展能力，每一个控制为自己的客户端类型实现了工作流程、表现逻辑、安全约束等功能。所有的控制还可以共享模型部分，这样确保了跨越客户端类型的统一应用行为，并且使得维护和测试简单、容易。一个协议路由组件提供了一个控制所有客户端类型的单一入口，为实现一些跨越客户端类型的功能提供了切入点，图5体现了这个设计结构。
5. 客户级可用的技术
客户级程序在使用者用来访问系统的设备上运行，目前主要的技术有：
◆ 各种客户端脚本技术，包括Java Script、VB Script、Java小应用程序和CSS技术,这种技术用来定制客户端页面的样式甚至内容；
◆ Web Start技术,这种技术用来远程部署独立应用程序；
◆ 开发独立应用程序的技术，独立应用程序的开发可以采用各式各样的开发平台，如Windows 32程序、Java独立程序等；
◆ 安全机制，安全机制用来限制从网络上下载的程序在使用机器上运行时的访问权限，JDK V1.3就已经提供了一个灵活可定制的安全机制。
Web级和EJB级
MVC主要体现在这两个级中。下面重点讨论Sun公司蓝皮书WAF架构中控制的组成情况。
图6体现了 WAF架构中“控制”部分的组成情况。其中Servlet Filter和Front Controller为前端控制；Request Processor、Web Controller和EJB Controller为子控制部分；Template Service和Screen Flow Manager控制部分实现视图的选择和产生；其它为程序开发人员根据功能性需求提供的控制部分，其中有属于控制部分的（ACTION类）、有属于视图部分的（如JSP页面和其它资源文件），也有属于模型部分的（如企业BEAN）。
从图6可看出，控制部分由几个组件组成，它们一起工作实现可扩展性和维护性的需求。这些控制组件是：
◆ 一个前端控制Servlet，它接收和处理HTTP请求，然后和其它控制组件一起完成分发请求和选择、生成视图的工作；
◆ 在EJB级的EJB控制类解释事件和执行EJB级的EJB动作。事件和动作也可在XML文件中配置，开发者很容易定义新的业务逻辑。Web级动作和EJB级动作类的存在允许开发者选择合适的级实现应用功能；
◆ Servlet过滤器放在前端控制Servlet的前面，用来增加一些针对所有请求的功能，如加密和解密；
◆ 一个模板服务Servlet把屏幕数据赋给屏幕定义参数，并把类资源组织起来形成视图，然后响应用户。屏幕定义是在外部的配置文件中，开发者很方便实现视图的定制。
Web级和EJB级是应用程序最主要的部分，一般情况下都需要负载均衡技术、高可用性技术和数据库连接池的支持。
Web级目前主要技术有：
◆ Java Pages,这种技术主要用在MVC模式的视图部分；
◆ Java Servlets,这种技术主要用在MVC模式的控制部分，也经常用在传输文件、产生二进制数据响应等方面；
◆ Java Bean,这种技术主要用在MVC模式的模型部分，是一种临时的模型,经常出现在参数传递、返回结果等地方；
◆ XSLT,作为可扩展风格页XSL的一部分，XSLT用来转换XML文档，比如把XML文档转换成HTML文档。
EJB级目前主要的技术有：
◆ Enterprise Bean,其中会话Bean主要用作控制部分，实体Bean用作模型部分，消息Bean用在集成层；
◆ Java Bean,这种技术主要用在MVC模式的模型部分，是一种临时的模型,经常出现在参数传递、返回结果等地方，避免企业Bean的消耗。
集成级
为了解决EIS(企业信息系统)的集成问题，J2EE 平台提供了以下四大技术（如图7）：
◆ J2EE连接体系，J2EE连接体系提供了J2EE应用和企业内存在的EIS系统集成的标准框架，它使得外部EIS的适配器能以插件的形式与J2EE应用服务器一起工作。企业应用能使用适配器的标准接口编程，从而可以安全地、事务化地和高伸缩性地与EIS一起运行。
◆ JMS(Java信息服务)，Java信息服务是一个支持企业通信系统的标准编程接口，目的在于提供一个跨越不同类型通信系统的公共接口。Java 应用程序利用JMS API和企业的通信系统连接后，应用程序就能利用通信系统提供的功能创建和发送消息，达到和其它应用系统异步通信的目的。
◆ JDBC API,是和关系型数据库系统集成的标准接口。Java 应用程序用这个接口获得数据库连接、查询数据和执行其它的数据库功能。
◆ Web Services技术,这种技术允许EIS提供一些服务访问点，新的应用通过这些点可以获取数据,也可以提交数据。
J2EE大部分规范都会涉及到角色分工，如Servlet规范就指明容器提供商做什么，也指明应用开发商做什么。架构和角色是紧密联系在一起的，因为好的架构遵循严格的规格，并且允许角色并发工作，从而加速开发。
在应用开发和部署生命周期内，J2EE平台定义了一些角色来完成各自的工作。它们是J2EE产品提供者、应用组件提供者、应用集成者、部署者、系统管理者和工具提供者，它们之间的关系可以见图8。角色的定义有助于理清在应用开发、部署和运行时不同参与者的责任。不同的角色并不意味着不同的参与者，一个参与者可以有多个角色，一个角色可以被多个参与者承担。
下面定义了这些角色，在一些规范中还会定义一些子角色，如EJB规范中定义的企业Bean提供者、EJB容器提供者和EJB服务器提供者等。
J2EE产品提供者
J2EE产品提供者实现了一个J2EE产品，这个产品提供组件容器、J2EE平台API和J2EE规范中定义的其它特性。一个J2EE产品当然还可以实现规范中没规定的接口。J2EE产品提供者还提供了应用部署和管理工具。部署工具使得部署者能把组件部署到J2EE产品中去，管理工具允许系统管理者管理J2EE产品和部署的应用。
应用组件提供者
应用组件提供者生产J2EE 程序的基本建造块，他们拥有开发可重用组件和业务领域两方面的专业知识。应用组件提供者不必要知道它们组件的操作环境。这个平台角色具有以下子角色：
◆ 页面作者；
◆ 文档编写者；
◆ BEAN开发者等。
这些子角色采用工具提供者的工具工作。
应用集成者
应用集成者从应用组件提供者那里获得组件，并把这些组件集成在一起形成一个完整的J2EE应用。他们的专业知识在于为特定的问题域提供解决方案。应用集成者可以不熟悉他们集成组件的源代码，为了知道用这些组件如何建立一个应用，他们充分利用组件的申明性描述。如同应用组件提供者一样，应用集成者不必知道应用的操作环境。他们往往用应用组件提供者或工具提供者开发的GUI工具工作。应用集成者只负责提供描述应用外部依赖的集成指令，解决这些外部依赖就是部署者的工作。
部署者
部署者是一个特定操作环境的专家，负责部署J2EE组件和应用到实际环境中去。他利用J2EE产品提供者的工具执行部署工作，在J2EE服务器上安装组件和应用，然后进行配置来解决组件开发者和集成者声明的外部依赖。
系统管理员
系统管理员负责配置和管理企业的计算和网络设施，并且要监控部署J2EE应用的运行状况。他一般用J2EE产品提供者的工具进行运行时监控和管理工作。
工具提供者
工具提供者为应用组件的开发和打包提供工具。这些工具一般是与平台无关的。
JSF简述
JSF技术是一个用户界面框架，适用于构建运行在JSP服务器上，向用户显示界面的Web应用程序。其主要功能为：
◆ 表示UI组件，并且能很好地管理他们的状态；
◆ 在服务器端处理用户界面事件和输入校验；
◆ 定义页面导航；
◆ 支持国际化；
◆ 提供与JSP相容的定制标签库。
开发者以极小的代价能做到：
◆ 用服务器端的代码处理客户端产生的用户界面事件；
◆ 映射用户界面组件到服务端数据；
◆ 用一个重用和可扩展的组件库构造用户界面；
◆ 跨越一个服务请求保存和恢复用户界面状态。
JSF技术的最大好处
这个技术提供了一个表现和行为彻底隔离的能力，而JSP只能做到部分隔离。JSF使得先前只有在客户端UI体系（DOM）下完成的细粒度隔离移到了服务器端，客户端只需解释标准的HTML语法，从而达到了完全瘦客户端的目标。
JSF的另一个主要目的在于利用熟悉的UI组件和Web级概念，并不把开发者局限在某种特定的脚本技术或标记语言。JSF提供了一个JSP标签库实现与JSP的绑定，但开发者完全可以用另外一些表现技术，因为JSF直接依赖于JavaServlet API。
JSF应用程序组成
JSF应用程序组成大部分与先前的Java Web相同，它运行于Java Servlet容器内，包含有：
◆ JSF技术中成为模型的JavaBeans组件；
◆ 事件（Servlet事件）监听器；
◆ 普通标签库；
◆ 网页（HTML、JSP等）；
◆ 服务端帮助类；
◆ 一个定制的在页面上解释UI组件的标签库；
◆ 在服务器端表现为状态对象的UI 组件；
◆ 验证器、UI事件处理器、导航器。
为在网页上表达UI组件，每一个JSF应用必须包含一个定制标签库，这样不需要用HTML或其它的标记语言硬编码UI组件。一般JSF的实现会提供这样的标签库，开发者也可以自己定义和实现标签库。
JSF技术中的UI组件界面在客户端，但运行和状态却保存在服务端。应用程序能操纵组件的状态，也能用服务端代码处理客户端产生的事件。
在更改服务器端数据前，JSF技术允许对每一个组件验证数据的有效性，没通过有效性检验的数据提交，错误信息会自动显示在产生错误的组件旁边。
JSF技术还提供一个独立的类完成页面导航任务。
图9表示了一个JSF程序中JSF技术组成。
JSF涉及的角色
JSF中涉及到页面作者、界面组件开发者、应用程序开发者、工具提供者和JSF实现者各种角色。其中页面作者负责Web应用的用户界面；界面组件开发者负责提供可重用的界面组件库应用程序开发者负责开发和用户界面没有直接联系的服务端功能部分；工具提供者负责研究工具来辅助基于JSF的应用程序的开发；JSF实现者提供JSF规范要求的JSF运行时环境。
为了满足架构需求，必须有一个良好的应用架构。这样有利于项目组成员的沟通，并且可以加快开发速度、加大重用力度、充分保障项目的成功实施和运作。
</td></tr></table>