（计算机软件与理论专业论文）一个基于java的面向web应用开发的构件组装工具.pdf

【摘要】 基于构件的软件开发的关键在于构件组装，现有的组装方法和组装工具没有 专门针对于w e b 应用的开发提供支持。本文提出了一个基于j a v a 的、面向w e b 应用开发的构件组装工具j b c a - t o o l ( j a v a b a s e dc o m p o n e n ta s s e m b l yt 0 0 1 ) ，为 了在已有的构件的基础上，通过构件组装迅速开发基于j 2 e e 体系结构的w e b 应 用，提供了一个可视化的建模、组装、部署的w e b 应用开发工具。w e b 应用开 发人员通过使用j b c a - t o o l 可以对于w e b 应用的表现逻辑和业务逻辑分别独立 进行建模，并在w e b 层和业务逻辑层之间引入了业务接口层作为表现逻辑和业 务逻辑的中介。本文还提出了个通用的构件组装框架，引入了连接器的概念， 使得连接器作为连接构件、适配构件接口，实现了异构构件的统一组装。本文详 细说明了j b c a - t o o l 的总体设计、开发流程，以及实现关键，最后通过一个实例 来说明如何使用j b c a t o o l 进行w e b 应用开发的建模和构件组装。 【关键字】 基于构件的软件开发，w e b 应用，表现逻辑，构件组装 【中图分类号】 3 a b s t r a c t c o m p o n e n ta s s e m b l yi st h ek e yw o r ko fc b s d ( c o m p o n e n tb a s e ds o f t w a r e d e v e l o p m e n t ) c u r r e n ta s s e m b l ym e t h o d sa n dt o o l sd o n 、p r o v i d es p e c i f i cs u p p o r tf o r w e ba p p l i c a t i o n d e v e l o p m e n t t h i sp a p e rp m l x maj a v a - b a s e dc o m p o n e n t a s s e m b l yt o o lf o rw e ba p p l i c a t i o nd e v e l o p m e n t i t sav i s u a ld e v e l o p m e n tt o o lf o r m o d e l i n g , a s s e m b l y , d e p l o yw e ba p p l i c a t i o n w i t ht h eh e l po fj b c a - t o o l ，d e v e l o p e r c a nd e s i g na n di m p l e m e n taw e ba p p l i c a t i o nb yr e u s i n gr e u s a b l ec o m p o n e n t sa n d s e r v i c e s w e ba p p l i c a t i o nd e v e l o p e rc a nm o d e lp r e s e n t a t i o nl o g i ca n db u s i n e 船l o g i c s e p a r a t e l y j b c a - t o o li n t r o d u c e st h ec o n c e p to fs e r v i c ei n t e r f a c et i e rb e t w e e nw e b t i e ra n db u s i n e s st i e r , a sa ni n t e r m e d i af o rw e bc o m p o n e n tt or e q u e s tt h es e r v i c e p r o v i d e db yb u s m e 鼹c o m p o n e n t j b c a - t o o l o f f e r sau n i v e r s a l c o m p o n e n t c o m p o s i t i o nf i a m e w o r ki no r d e rt oa s s e m b l ec o m p o n e n t si nd i f f e r e n ts t a n d a r d st o 毫 w h o l ew e b a p p l i c a t i o ns y s t e m c o n n e c t o ri nj b c a - t o o li st h ec o a n e 虻- t o ra n da d a p t e r f o rc o m p o n e n t s t h i sp a p e ri n t r o d u c e st h ea r c h i t e c t u r eo fj b c a - t o o l ，t h e k e y t e c h n o l o g yf o ri m p l e m e n t a t i o no fj b c a - t 0 0 1 ad e v e l o p m e n te x a m p l ei sg i v e na tt h e e n d ，t of u r t h e re x p l a i nh o wt ou s et h et o o lt od e v e l o paw e b a p p l i c a t i o n k e yw o r d s c b s d ( c o m p o n e n tb a s e ds o f t w a r ed e v e l o p m e n t ) ， w e ba p p l i c a t i o n ，p r e s e n t a t i o nl o 西c ， c o m p o n e n ta s s e m b l y 4 第一章绪论 1 1 背景 1 1 1 基于j 2 e e 体系结构的w e b 应用系统的开发 应用系统从在一台单独的机器上运行，发展到客户机服务器( c l i e n t ， s e r v e r ) 的结构，再发展到基于浏览器的多层结构。基于浏览器的w e b 应用系统 和一般的应用系统相比，作为用户界面的网页比传统的图形界面内容更加丰富， 风格更加多样，由于用户偏好或者系统需要而发生变化更加频繁。表现逻辑和业 务逻辑分离和所有应用系统良好设计的原则之一。w e b 应用系统就更加强调表现 逻辑和业务逻辑相分离。 基于j 2 e e 体系结构的w e b 应用系统一般是四层结构，由上而下分别是客户 层、w e b 层、业务层、企业信息系统层。客户层包括客户端浏览器和浏览器所显 示的w e b 页面。w e b 层包括s e r v l e t 、j s p 页面以及j a v a b e a n s 。业务逻辑层封装 了核心业务过程，通常由f _ j b 构件组成。企业信息系统层通常是数据库和遗留 系统，如e r p 系统、c r m 系统等等【1 】。图1 1 展示了基于j 2 e e 的w e b 应用系 统的层次结构： 图11 左边是一般的应用系统，右边的是基于浏览器的w e b 应用 w e b 应用主要分为如上图所示的四层，最上面的是客户层，用户通过浏览器 与应用进行交互；第二层是w e b 层，包括j s p 页面、s e r v l e t 、j a v a b e a n s ，运行 在w e b 容器上；第三层是业务逻辑层，应用的核心业务逻辑封装在该层的 j a v a b e a n 和e j b 中，运行在e j b 服务器上；最底层是企业信息系统层( e n t e r p r i s e i n f o r m a t i o ns y s t e mt i e r ) ，又可以称为持久层( p e r s i s t e n tt i e r ) ，或者称为数据层 ( d a t at i e r ) ，运行在数据库服务器上或者遗留系统的服务器上。 5 在基于j 2 e e 的w e b 应用系统多层结构的基础上，讨论表现逻辑与业务逻辑 如何交互，主要着眼点在于w e b 层。服务器接收到用户请求之后如何分配到相 应的业务逻辑单元进行处理，根据处理结果，返回怎样的界面给用户 1 1 2c b s d 基于构件的软件开发 基于构件的软件开发，是近几年来软件工程领域一直研究的热点。构件技术 通过在软件开发中重用经过验证的构件，从而提高了软件复用程度、提高了软件 开发效率、更好地保证了开发的质量。构件技术被认为是解决软件危机的重要手 段之- 2 ，3 ，4 1 。 在基于构件的软件体系结构的应用系统中，应用系统是由构件组成的，应用 系统体系结构的每个原子单元是构件。按照构件可重用的程度和范围来分类，构 件一般可以分为三种：通用构件，领域共性构件，应用专用构件。通用构件是对 于所有领域所有应用都可以通用的构件，比方说一些基础的服务如：日志、安全 等等。领域共性构件是在特定的领域可以通用的构件，已经经过了一个或者多个 该领域的应用系统实际的顺利运行所验证的构件。领域共性构件是构件重用中运 用得最多的一种，我们讨论构件重用，主要是在某个特定领域的多个应用系统开 发中来讨论构件的重用。应用专用构件，是指一个应用系统特定的构件，只能在 该应用系统内部被重用，不能供其他应用系统直接重用的构件当然系统专用构 件可能在经过提取共性、摒除特性之后，或者经过某种包装、经过抽象和客户化 ( c u s t o m i z e ) 之后成为可重用的构件。基于构件技术来开发一个应用系统，通常就 是通过把上述的通用构件、领域共性构件、应用专用构件组装成一个可运行的系 统【5 ，6 , 7 1 。 基于构件的开发主要包括三个步骤：构件开发、构件管理、构件组装。我们 讨论基于构件的开发，总是基于一种规范、一种构件模型、构件标准。现有的一 些构件标准包括c o m d c o m 、c o r b a 、e j b 、w e bs e r v i c e s 等等。构件开发也 可以称为构件的制作，就是开发符合构件模型规范的构件、或者是把现有的构件 包装成目标构件标准的构件。构件管理包括如何把大量的可重用的构件按照不同 的特点( 不同的刻面) 进行管理，如何让用户检索到符合用户需求的构件。构件 管理相关的技术有构件库技术、构件描述、构件检索等等。在多年的基于构件的 软件开发实践中，各个特定的领域已经有了可重用构件的积累，并且按照一定的 描述方案进行构件库入库管理，有专门的高效的构件检索支持。在开发某个领域 的应用系统中，不需要全部从头开始进行开发编码，而是通过重用构件库中的构 件，当然也需要补充开发一些应用专用的构件，然后把这些构件组装起来成为一 个完整的可运行的应用系统。构件组装是基于构件开发的关键步骤，构件组装过 6 程包括构件之间组装关系的建模、构件组装模型的验证、构件组装粘合代码的生 成等等。如何把不同标准的构件组装起来是构件组装研究的难点之一，如何使得 构件概念和构件实体分离开来，使得不同构件实体的组装、异构构件的组装对用 户透明，都是构件组装研究的难点以及热点【8 ，9 】。 1 2 国内外研究现状 a b c 方法( a r c h i t e c t u r eb a s e dc o m p o n e n to r i e n t e d ) 是北京大学软件研究所 提出的一种基于体系结构、面向构件的软件开发方法。a b c 方法在软件体系结 构的层次上指导软件开发，贯穿了整个软件生命周期。从基于体系结构的需求分 析到体系结构设计、基于体系结构的组装、基于体系结构的部署，以及基于体系 结构的维护a b c 方法结合了从上而下的体系结构思想和自下而上的基于构件、 基于构件组装的软件开发方法，对软件开发的整个生命周期提出了一套系统的开 发方法论。为了支持a b c 方法，北大软件研究所开发了体系结构建模、部署t 具a b c - t o o l 。a b c 方法和a b c - t o o l 没有区别传统的应用系统和时下最广泛使 用的w e b 应用系统，针对于w e b 应用系统表现逻辑尤其丰富、变动灵活的特点 给出特定的指导【1 0 ，1 1 】。 s c a 是s e r v i c ec o m p o n e n t a r c h i t e c t u r e 的简写，s c a 一种是面向服务构件的 框架。s c a 是目前业界主要的软件厂商大力推广的一种与实现语言无关的构件 模型，是s o a 概念和传统c b s d 方法相结合的产物。在s o a 的应用系统下， 组成系统的单元是服务构件，每个构件是粗粒度的，实现一个完整业务功能服务 的单位。每个可独立运行、独立部署的服务作为分布式的、松耦合的构件。在系 统建模阶段，系统模型中的s c a 构件实例与具体实现技术无关，是抽象概念的 构件。在系统实现阶段，概念构件才与构件实体联系起来。这样就很好的实践了 s o a 思想的精髓。s c a 构件模型和开发方法受到了如b e a 、i b m 、s a p 、s y b a s c 、 o r a c l e 等主流软件厂商的推广和实现，这些厂商正在把s c a 思想实现到各自的 产品和解决方案中，如i b m 的w e b s p h e r e 、s y b a s e 的w o r k p l a c e 等等。 1 3j b c a 工具的提出 目前，绝大多数构件组装工具是面向所有应用的开发的，很少有面向w e b 应用开发的构件组装工具。w e b 应用与其他应用的开发有所不同，w e b 应用的 表现逻辑更为丰富，需求变化更为灵活，这个在系统体系结构建模和组装关系建 模及实现上就有其特殊性。针对于w e b 应用的构件组装工具，我们复旦大学软 件工程实验室进行了长期的研究与开发，在本文所涉及的8 6 3 项目一期，开发实 7 现了一个面向基于j a v a 的b s 应用、基于c 2 风格组装构件的工具b s a p p b u i l d e r ， 在表现逻辑层上引入了一个新的w e b 页面流转模型：c b m o d e l 。b s a p p b u i l d e r 解决了表现逻辑与业务逻辑分别独立建模，实现了b s 应用与构件组装的结合。 但是c 2 风格的构件组装需要对每个原有的构件进行包装，而且c b m o d e l 并不 是一个业界推广使用的w e b 模型或框架，b s a p p b u i l d e r 是对于基于j a v a 的构件 进行组装，没有考虑异构构件统一组装的问题 1 3 ，1 4 ，1 5 1 。 在b s a p p b u i l d e r 的基础上，该8 6 3 项目二期开发了一个基于j a v a 面向w e b 应用开发的构件组装工具j b c a - 1 b 0 1 该工具是用j a v a 实现的，主要支持基于 j a v a 的构件构装，提供了一个通用的构件组装框架，支持p o j o 、e j b 、w e bs e r v i c e s 等异构构件的统一组装。j b c a - t b h o l 不仅仅支持表现逻辑与业务逻辑的独立建 模，还在w e b 层引入了j a k a r t as t r u t s 作为w e b 框架，s t r u t s 是目前业务应用最为 广泛的w e b 开源框架之一。在j 2 e e 多层结构中，在w e b 层和业务逻辑层中问， 引入了服务接口层的概念，作为w e b 层和业务逻辑层交互的中介。 1 4 文章的组织结构 本文一共分为五章，第一章绪论主要介绍了j b c a - 1 b o l 提出的技术背景和商 业背景，简要分析了国内外相关研究，指出j b c a o t o o l 的开发动机。第二章概述 了j b c at 具的总体设计，介绍了j b c a 工具的各个功能模型，并说明了使用 j b c a 工具开发w e b 应用的流程，并对开发流程的各个阶段逐一进行介绍。第三 章详细阐述了j b c a 工具的实现的关键技术。j b c a 工具支持表现逻辑和业务逻 辑相分离，在w e b 层引入了动作映射和转发映射的概念，提出了页面流转模型。 在j 2 e e 多层体系结构中，在w e b 层和业务逻辑层之间引入了服务接口层，作为 w e b 层和业务逻辑层交互的中介。为了支持异构构件的组装，j b c a t 具提出了 两个层次的组装概念，实现了一个通用的构件组装框架，使得异构构件可以以统 一的方式进行组装。第四章以一个实例说明使用j b c a 工具如何进行w e b 应用 的开发、建模、组装以及部署。最后，第五章总结了开发j b c a 工具的意义，并 指明了将来的研究方向。 8 第二章j b c a 工具的总体设计及开发流程 2 1 j b c a 工具的总体设计 我们设计并开发了一个构件组装工具j b c at o o l 。j b c a - t o o l 是一个提供给 w e b 应用开发人员使用的辅助w e b 应用开发、制作构件、管理构件、组装构件 的可视化建模、组装、部署工具。w e b 应用开发人员可以通过j b c a - t o o l 进行 w e b 应用的项目资源管理、w e b 层页面流转设计、构件制作、构件管理、构件 组装、w e b 应用打包及部署等等图2 1 是j b c a - t o o l 的系统整体结构图，反映 了j b c a - t o o l 的各个功能模块。 图2 1 系统结构图 用户可以使用j b c a - t o o l 对w e b 应用开发项目进行资源管理，包括新建一 个w e b 应用项目、把已经开发好的资源导入到项目中、新建w e b 应用资源( 资 源包括h t m l 页面、j s p 页面、j a v a 文件等等) 、移除资源文件、移除并删除资 源文件。 用户可以使用j b c a - t o o l 对w e b 应用的w e b 层的页面流转进行设计建模。 9 j b c a - t o o l 提供了一个画板，使得用户可以在画板上可视化地拖拉图形、连线， 进行页面流转设计，然后生成页面流转的配置信息。 用户可以使用j b c a - t o o l 进行构件制作一方面可以根据构件源码生成构件 类型描述文件，根据w e bs e r v i c e s 构件的w s d l 文件生成构件类型描述文件 另一方面，可以根据构件类型描述文件，生成用j a v a 语言实现的构件的框架代 码 用户还可以使用j b c a - t o o l 进行构件管理。j b c a - t o o l 可以连接上海构件库， 检索所需要的构件，下载到本地构件库。还可以把开发好的构件上传入库。 用户使用j b c a - t o o l 进行构件组装。组装建模包括两个层次：模块内的组装 建模、系统级别的组装建模。对组装模型进行验证，然后生成组装的粘合代码。 最后，用户可以对w e b 应用进行打包部署。对于应用的每个模块进行独立打 包和部署，可以将不同的模块部署到不同的目标服务器上。 2 2 使用j b c a 工具开发w e b 应用的流程 用户使用j b c a - t o o l 进行辅助w e b 应用开发、构件组装到最终w e b 应用的 整体部署，既实现了s o a 思想的服务构件之问的松耦合，也继承了传统的基于 构件、基于构件组装的c b s d 开发思想。使用j b c a - t o o l 进行w e b 应用开发， 既是面向服务的、也是基于构件的，因此下文我们把使用j b c a - t o o l 进行w e b 应用开发的方法简称为s o c b 方法，( s e r v i c eo d e n t e dc o m p o n e n tb a s e d ) 。s o c b 方法的主要开发流程图如图2 2 所示： 1 0 图2 2 使用j b c a - t o o l 开发w e b 应用的流程图 使用j b c a - t o o l 来开发w e b 应用，大致分为4 个阶段：准备阶段、w e b 层 页面流转设计阶段、构件组装阶段、部署阶段在准备阶段，主要是做w e b 应 用的数据准备和资源准备。w e b 应用资源准备包括一些静态的h t m l 页面、j s p 页面、图片等等。然后利用j b c a - t o o l 新建一个w e b 应用项目、导入w e b 资源。 在w e b 层页面流转设计阶段，主要做w e b 层页面流转建模。对于用户请求的动 作映射和转发映射进行配置，并生成配置信息。构件组装阶段是最重要的阶段。 我们在模块层次和系统层次对于组装构件进行设计建模，然后验证组装关系，生 成粘合代码。最后对整个w e b 应用的各个模块进行分别打包、部署到目标服务 器上。 在第四章我们将会以一个开发实例来详细说明如何使用j b c a - t o o l 进行w e b 应用的开发与构件组装。 2 2 1 建模阶段 建模阶段包括对开发的目标w e b 应用系统进行需求分析和设计建模。建模阶 段包括四个步骤：一、获取以及分析用户需求，二、划分服务功能模块，三、在 模块层次，对各个模块内部的构件之间的组装关系建模，四、在系统层次，对模 块之间的组装关系进行建模。 1 1 模块的划分是按照业务功能来进行的，而且还要考虑是否可以独立进行部 署，然后把一个w e b 应用系统分为若干个实现业务功能的服务模块。w e b 应用 系统的组装关系的建模分为两个层次：模块建模和系统建模。模块建模是模块内 部的构件之间的组装关系的建模。系统建模是模块之间的组装关系的建模。建模 包括模型元素的定义、指定元素之间的关系。模块建模的元素定义就是定义原子 构件的过程，然后通过连接器来连接原予构件实例的接口，并绑定某些原子构件 提供的服务以及请求的服务作为模块对外可以提供的服务以及对外需要引用的 服务。系统建模的元素定义就是模块建模，然后通过连接器来连接模块构件实例 的接口。建模阶段的构件都是概念构件，与具体实现无关，是抽象级别的构件概 念。 特别地，w e b 模块的建模比一般模块的建模多一个表现逻辑建模的步骤。 w e b 模块与一般业务模块不同，w e b 模块包含丰富的表现逻辑。在一个w e b 应 用中，部署在一个w e b 服务器上的，负责接收和响应用户请求的部分，通常划 分在一个w e b 模块中。一个w e b 应用至少有一个w e b 模块，在w e b 模块表现 逻辑建模中，主要通过把用户请求分派给相应的处理以及根据处理结果返回不同 的响应，这两步来进行流转控制建模。 2 2 2 实现阶段 实现阶段的主要工作是对于建模阶段得到的组装模型来指定实现实体。建模 阶段得到的组装模型是与具体技术无关的，与具体实现实体无关的。构件实体可 能是构件库里可重用的构件，可能是已经在运行的w e bs e r v i c e ，可能是已经部 署好的f 2 b ，又或者不在上述三种情况中，需要w e b 应用系统的开发人员另外 进行开发，这些需要另外开发的就是第一章我们所介绍的各种构件类型中的应用 专用构件。可见，实现阶段需要做的工作有；在构件库中检索符合要求的可重用 的构件实体，在服务注册中心搜索服务要求的w e b 服务，另外开发符合要求的 应用专用构件。在实现阶段，w e b 应用开发人员对于组装模型中，主要是指系统 每个模块中的抽象概念的构件，把构件实体与组装模型中的构件概念进行一一对 应，对应关系全部完成之后，组装模型才是一个完整意义上的模型。 2 2 3 组装阶段 组装阶段，提出了一个通用的构件组装框架。通过引入连接器( c o n n e c t o r ) 的概念作为构件之间的连接器和适配器，对请求一个服务的构件接口和实现这个 服务的构件接口进行连接以及适配。在组装阶段，构件组装框架根据组装模型以 及构件实现实体的描述文件，首先验证组装模型的合法性和完整性，然后自动生 成连接和适配的粘合代码。 2 2 4 部署阶段 w e b 应用系统的各个模块是独立的完整的业务功能单元，在设计阶段就考虑 了各个模块是否需要独立部署。在部署阶段，w e b 应用开发人员将各个模块的构 件、组装粘合代码和资源统一打包或者分别打包，并部署到一个或者多个目标服 务器上。 第三章j b c a 工具实现的关键技术 3 1 表现逻辑与业务逻辑相分离 w e b 页面是w e b 应用的用户界面，w e b 应用通过w e b 页面与用户进行交互。 w e b 页面变化的灵活性比传统界面要求更高。由于用户对于w e b 页面表达能力 要求不断提高以及应用开发者改善w e b 页面风格等等原因，常常发生对于改变 w e b 页面的变更需求。与其他应用相比，w e b 应用的表现逻辑内容更丰富、变 化需求更频繁。相对于表现逻辑来讲，业务逻辑的内容相对稳定、变化幅度相对 比较小、变化周期相对比较长。通常来说，w e b 页面的变更与w e b 应用业务逻 辑的变更不是捆绑在一块的，业务逻辑变化可能只是业务过程的变化，不需要 w e b 页面随之发生变化；w e b 页面变化可能只是页面表现风格、结构等变化， 不牵涉应用的业务过程。因此，良好设计w e b 应用的准则之一就是：表现逻辑 与业务逻辑分离。表现逻辑的变化不影响业务逻辑的过程，业务逻辑的变动不影 响表现逻辑的代码。尽可能降低表现逻辑与业务逻辑的耦合程度。在其中一方发 生变化的时候，不影响另外一方。表现逻辑与业务逻辑相分离的好处有两点：第 一，在系统开发时，有利于开发人员的分工。业务逻辑开发人员主要关注业务过 程的建模、设计与开发，e j b 的设计与开发，功能模块的设计与开发。表现逻辑 开发人员可以把精力集中在页面的设计与开发，页面流转的建模与实现等等。当 然，其中需要系统架构师或者高级程序丌发人员对于表现逻辑和业务逻辑如何衔 接进行预先设计。第二，在系统变化时，一个变更需求所对应的变更工作所牵涉 到的人员以及代码修改工作可以降低到更少，这样有利于保证变更的质量和进 度。s o c b 方法的特点之一就是支持表现逻辑与业务逻辑分离，独立建模。丰富 的表现逻辑是w e b 应用的特点之一，s o c b 方法是针对于w e b 应用的开发方法， 在表现逻辑建模上有其独到之处，本章着重介绍s o c b 方法对于表现逻辑的指 导。表现逻辑包括页面设计与开发、页面流转的建模与实现。 s o c b 方法在w e b 层采用了s t r u t s 框架，在s t r u t s 框架的基础上研究页面流 转的控制。页面流转的过程是：首先，j s p 页面表单提交执行的动作映射路径； 其次，请求被a c t i o n s e r v l e t 拦截之后，根据请求路径，把要执行的动作映射到相 应的a c t i o n 进行处理；然后，根据a c t i o n 处理结果，把结果和下一个j s p 页面 或者下一个a c t i o n 映射联系起来，作为下一步流转的目标。我们的工作是，在 此过程中，使得页面流转控制建模可配置，并提供工具支持可视化的建模操作。 页面流转的研究点有二：一是动作映射，用户请求的动作路径与控制器分派 1 4 a c t i o n 处理的映射。二是转发映射，控制器通过a c t i o n 处理的结果，把用户请 求转发给相应的视图展现给用户，或者把用户请求转发给相应的下一步操作。 动作( a c t i o n ) 是页面流转控制的中心概念，是s c r v l e t 和业务逻辑之间的桥梁 s e r v l e t 根据请求路径把处理任务委派给相应的a c t i o n ，a c t i o n 对外请求的服务作 为w e b 层构件对外请求服务的请求点a l - t i o l l 辅助s e r v l e t 完成控制器的任务。 页面流转控制的关键在于动作委派和转发选择两个部分因此，要集中管理页面 流转控制的信息，s o c b 方法抽取出动作映射信息和转发映射信息。 3 1 1 动作映射 动作映射信息是用户提交的请求所要执行的动作信息，a c t i o n s e r v l e t 根据动 作映射信息把用户请求映射到相应的动作，把用户请求分派给相应的a c t i o n 进 行处理。动作映射的信息包括：用户请求，处理用户请求的动作，用户提交的表 单信息其中，处理用户请求的动作信息包括：动作处理的u r l ，实现动作的 类。表单信息又包括：表单名，表单数据的作用范围，表单是否需要验证，提交 表单的j s p 页面( 当表单验证失败，返回提交表单的j s p 页面) 以下是动作映 射信息的简单的文法描述： 动作映射：= t 请求。动作表单 动作 = ：= 动作路径动作的实现类， 表单 ：= 表单名作再范国提交表单的页面，是否需要验证 一个请求只能对应一个动作，但是不同的请求提交给s c r v l c t ，s e r v l e t 可能会 委派执行同一个动作。动作路径在整个w e b 应用中是全局唯一的，动作路径是 一个动作的标识。尽管如此，不同动作路径的动作可能由同一个j a v a 类来实现， 路径不同的动作被看作是不同的动作。如果表单需要验证，而且验证失败的话， 就要返回提交请求表单的j s p 页面。下图是动作映射的一个例子： 图3 h 动作映射 上图的例子说明了一个动作委派的过程。在一个j s p 页面l o g i n j s p 中，用户 提交一个表单，作为控制器的a c t i o n s e r v l e t 接收到用户请求之后，查看配置文件 中的动作映射信息，根据请求路径，把该请求分派给e x a m p l e l o g i n a c t i o n 进行 处理。处理结果如何，请求如何转发，接下来在3 1 2 转发映射部分介绍。 3 1 2 转发映射 转发映射信息是动作执行的不同结果，所对应的不同的返回视图或者所要执 行的下一个动作的信息。a c t i o n s e r v l e t 根据动作处理用户请求的不同结果，查看 转发映射信息，把用户请求转发给下一个视图或者下一个动作。转发映射的信息 要包括：动作路径，动作结果，转发的目标，转发的类型等等。转发映射信息的 简单的文法描述如下： 转发映射：= t 动作路径动作结果转发8 标。转发类登， 转发目标：= 视图路径、动作路径 一个动作可以有一个或者多个执行的结果，每个结果对应一个转发目标，转 发的类型可以是直接转发( f o r w a r d ) 或者是重定i 句( r e d i r e e t ) ，转发目标可能是视图 路径，也可能是动作路径。也就是说一个动作执行之后的后续操作可能是返回下 一个视图，也可能是执行下一个动作。控制器a c t i o n s e r v l c t 查看转发映射信息， 根据动作路径以及动作执行的结果，选择转发目标，按照指定的转发类型，如果 转发目标是视图，就返回视图给用户；如果转发目标是动作，就把请求转发给目 标动作，然后执行目标动作。执行目标动作之后，同样由控制器a c t i o n s c r v l e t 1 6 来根据转发映射来选择下一个转发目标。下图是转发映射的一个例子： 图3 a 转发映射 这个例子说明了l o g i n a c t i o n 处理用户请求之后，如果处理结果是s u c c e s s ， 控制器a c t i o n s e r v l e t 查看配置文件中的转发映射信息，把用户请求转发给下一个 动作g e t l n f o a c t i o n 进行处理；如果l o g i n a c t i o n 处理结果是f a i l u r e ，控制器 a c t i o n s c r v l c t 查看配置文件中的转发映射信息，把用户请求转发给视图l o g i n j s p 返回给用户。 3 1 3 页面流转模型 动作映射信息是用户提交的请求所要执行的动作信息，用来把用户请求映射 到相应的动作。转发映射信息是根据动作执行的结果所要返回的视图或者所要执 行的下一个动作的信息，用来把执行结果转发给下一个视图或者下一个动作。这 两个映射信息都是围绕动作( a c t i o n ) 的。 每一个用户请求路径对应与一个动作类路径，经过处理之后，一个动作可以 又不同的转发目标，因此动作映射信息和转发映射信息可以和一个特定的动作联 系在一齐进行存放。我们把动作映射信息和转发映射信息放在a c t i o n m a p p i n g 里 面。我们实现可配置页面流转控制就是对a c t i o n 和a c t i o n f o r w a r d 进行流转配置， 然后把信息存放在a c t i o n m a p p i n g 里面，生成页面流转模型，把模型信息记录在 配置文档中。 a c t i o n m a p p i n g 是页面流转的中心元素，每个a c t i o n m a p p i n g 有一个中心的 a c t i o n 。用户请求的入i = 1 路径是a c t i o n m a p p i n g 的键值，在一个w e b 应用中是全 1 7 局唯一的。一个a c t i o n 有一个请求入口路径，可以有多个f o r w a r d 目标。以下是 a c t i o n m a p p i n g 模型： a c t i o n m a p p i n g 模型： a c t i o n m a p p i n g ：= 捐岛朗努经4 c 蛞d a 西加f 溉4 c 瞄鲫e 删耐集毋 a c t i o n 苌= a c t i o n 类毯a c t 如n 韵实现类 a c t i o n f o r m ：= f o r m 名字作甬范国是否验证提交表萃的1 s p 页硅霸 a c t i o n f o r w a r d ：= 廿o r 臌耐各隽f o r w a r d 届# 螽务 在a c t i o n m a p p i n g 模型里面，请求路径是用户提交请求的动作路径，是动作 的入口a c t i o n 实现类路径信息告诉控制器接收到该请求路径之后，调用哪个 a c t i o n 的实例。a c t i o n f o r m 是用户提交的表单信息，包括表单名字，作用范围， 是否需要验证，以及提交表单的j s p 页面( 在验证失败之后要返回该页面) 。 a c t i o 棚a r d 集合是该a c t i o n 处理之后可能的转发去向，是转发映射信息 f o r w a r d 名字在一个动作之内是唯一的，根据f o r w a r d 的名字找到转发的路径。 在表现逻辑的页面流转控制建模完成之后，可以按照模型来通过生成s t r u t s 配置 文件而生成页面之间的流转关系。以下给出一个a c t i o n m a p p i n g 的例子： a c u o n p a t h = l o g i n a c b o n 。t y p e = ”e x a m p l e l o g m a c b o n 。n a m e = l o g i n f o r m i n p u t = l o g mj s p - s p e - r e q u e s rv a h d a t e = t r u e 。， 这个例子说明了这样的一个页面流转过程：一个请求路径为l o g i n a c t i o n 的动 作，处理来自j s p 页面l o g i n j s p 提交的表单。实现动作的j a v a 类是 e x a m p l e l o g i n a c t i o n ，表单对应a c t i o n f o r m 名字是l o g i n f o r m ，作为范围是 r e q u e s t ，需要验证，如果验证失败就返回l o g i n j s p 页面。当l o g i n a c t i o n 处理用 户请求之后，如果处理结果是s u c c e s s ，a c t i o n s e r v l e t 把用户请求转发给后续动作 g e t l n f o a c t i o n ；如果处理结果是f a i l u r e ，a c t i o n s e r v l e t 把用户请求转发给后续视 m l o g i n j s p ，请求并不是通过s t r u t s 的一个叫做r e q u e s t d i s p a t c h e r 的组件被转发， 而是被重定向到l o g i n j s p 。 1 8 3 2 服务接口层 s o c b 方法使得表现逻辑与业务逻辑可以分离，独立进行建模建模之后， w e b 层的表现逻辑应该如何与业务逻辑层相连接呢? 上文介绍了w e b 层页面流 转，动作映射和转发映射都是以a c t i o n 为中心，a c t i o n 和表现逻辑和业务逻辑 的桥梁我们可以在a c t i o n 的实现类的代码中直接调用业务逻辑层的服务方法 这是一种直接调用、直接连接的方式，是一种紧耦合的方式，不失为一种w c b 层与业务逻辑层连接的方法。基于j 2 e e 的w e b 应用是多层结构的，s o c b 关注 与w e b 层与业务逻辑层，j 2 e e 多层结构的旨意就是为了降低j 2 e e 应用中构件 的耦合程度，以分层的方式来降低层与层之间构件的依赖关系，使得大型的j 2 e e 应用分工更明确、更细致，应用变更更加灵活。遵循这一宗旨，良好的w e b 应 用设计应该使得w e b 层与业务逻辑层可以灵活地连接，降低依赖的耦合程度。 这个思想就是s o c b 方法把服务接口层的概念引入到w e b 应用中的原因。 3 2 1 服务接口层的概念 服务接口层是由一组代表业务逻辑层的服务接口的构件组成的。服务接口层 中的服务接口构件是w e b 层构件与业务逻辑层构件交互的中介服务接口构件 把业务逻辑层的业务构件所提供的服务，按照一定的业务关系、时序关系等组织 起来，以更方便w e b 层构件进行服务调用。下图是引入服务接口层的w e b 应用 层次结构图： 1 9 图3 3 引入服务接口层之后的层次结构图 3 2 2 分层思想与模块划分 服务接口层是一个逻辑概念，是对于起服务接口作用的构件集合的一个统 称。j 2 e e 体系结构下的分层：w e b 层、业务逻辑层等，也是逻辑概念。w e b 层 代表客户h t t p 请求响应、分派及处理的构件集合，业务逻辑层是处理应用业务 过程的构件集合。 s o c b 组装模型中的模块的概念，是一个物理概念。模块是w e b 应用中可独 立部署的单元，模块中的构件、配置文件等等可以打包在一个w a r 文件、j a r 文件或者e a r 文件中，并部署到目标服务器上。 s o c b 方法引入了服务接口层的概念，服务接口层的构件如何划分到模 块中去呢? 一般有两种划分方法：第一种方法，服务接口层的构件与w e b 层构 件一起打包为w a r 模块构件，w e b 层a c t i o n 构件在模块内调用服务接口层的服 务接口构件封装好的服务接口。服务接口层构件和w e b 层构件物理上在一台机 器上的一个w a r 文件里。第二种方法，服务接口层的构件作为一个独立的模块， 作为一个w e b 模块构件与业务模块构件之间的中介者( m e d i a ) 、适配器 ( a d a p t e r ) ，这时，服务接口层构件组成的模块可以独立于w e b 模块进行部署， 独立于业务模块进行部署。这样，提高了w e b 层与业务逻辑层连接的灵活性。 通常地，业务逻辑层构件可能是已经存在、已经部署好或者已经在线使用的 2 0 构件，服务接口构件与w e b 层构件关系更加密切。s o c b 方法为w e b 应用开发 者提供了一种利用现有的f i b 构件、w e bs e r v i c e s 构件，如何快速开发w e b 应 用的方法。某些业务逻辑层构件是已经存在的，不需要我们从头进行开发，而 w e b 层构件和服务接口层构件是需要我们针对于某个特定系统进行开发的。因 此，服务接口层构件通常与w e b 层构件都作为w e b 模块的组成部分。 3 2 3 服务接口层作为连接w e b 层与业务逻辑层的中介 通过服务接口层，使得w e b 层构件和业务层构件可以松耦合地组装起来。下 图给出了一个包括服务接口层的例子，通过这个例子我们可以看到，在s o c b 组装模型下，服务接口层是如何参与组装： 图3 4 w e b 应用构件组装整体图 3 3 两个层次的组装 3 3 1 构件模型 构件首先是一个抽象概念。一个应用系统的运行，实际上是一组提供服务的 构件之间的互相调用服务的通信活动。应用系统的面向服务、基于构件的体系结 构，用一组构件以及构件之间的联系来表示。构件是在面向服务、基于构件的体 系结构中的基本组成元素和基本构建单位，是提供服务的原子单位。构件与具体 实现的技术无关，是一种抽象概念的构件。 其次，构件的第二个特点是通用。构件模型并不是区别于e j b 、c o r b a 、 w e bs e r v i c e s 等构件标准的一种新的构件模型我们可以很容易地把e i b 、 c o r b a 等传统构件、w e bs e r v i s 构件、甚至p o j o 等包装成构件，使得客户 端可以通过统一的接口来调用构件所提供的服务。因此，我们可以说构件模型兼 容了传统的各种构件模型。 构件作为一种通用的抽象构件模型，可以采用e j b 、p o j o 、c o r b a