本科毕业设计论文-网站系统RBAC的设计与实现.doc

1摘要班 级 06065 学 号 西安电子科技大学本科毕业设计论文题 目 网站系统RBAC的设计与实现 英文题目 Design and Implementation of RBAC of Web System 学 院 经济管理学院 专 业 电子商务 学生姓名 导师姓名 摘 要随着Internet及信息技术的飞速发展，信息共享应用日益广泛与深入，同时网络安全问题也日渐突出。安全性问题越来越被大多数人所重视，保护网络资源不被非法使用和非法访问已经成为人们首要考虑的问题之一。为了解决这个矛盾人们提出了许多安全策略，访问控制策略就是在保障授权用户能获取所需要资源的同时拒绝非授权用户的安全机制，是保护网络资源在一个相对安全的环境中进行的一个有效方法。安全访问控制策略一般有三种：自主型访问控制方法、强制型访问控制方法和基于角色的访问控制方法(RBAC)。其中，自主式太弱，强制式太强，二者工作量大，不便于管理。基于角色的访问控制方法是目前公认的解决大型企业的统一资源访问控制的有效方法。本文从基于角色的访问控制模型的基本理论出发，阐述了该模型的基本原理和特点，并从软件的角度分析了网站系统RBAC模式的需求，给出了一套基于RBAC模式的设计与实现方案，设计方案在分析RBAC在企业系统中应用的同时，对用户，角色，以及权限之间的关系进行了详细的论述，并在数据库结构中定义了它们之间的关系。利用当前最流行的MVC框架struts2对不同用户所具有的权限进行了拦截，使网络资源在一个合法安全的环境中被访问。论文的意义在于提出并实现了一个RBAC模型框架，这对于将来要开发类似系统的工程具有一定的参考价值。关键词：访问控制 角色 权限 基于角色的访问控制AbstractWith the rapid development of computer technology, Information sharing has been used widely and in depth, the problem of network security is increasingly highlighted. Security problems are increasingly valued by most people, to protect network resources from unauthorized use and unauthorized access has become one of the primary considerations. To resolve this conflict a number of security policies have been proposed, Access control policy is one of the security mechanisms to protect that the authorized users can access the resources necessary and to reject non-authorized users, which is an effective way to protect network resources in a relatively safe environment. Generally, there exist three kinds of Security access control policy: Autonomous access control, Mandatory access control, Role-based access control. the autonomous is too weak but the Mandatory is too strong, Both the workload is not manageable. Role-based access control method is widely recognized as an effective way of solving control access to resources of large enterprises. In this paper, we start from the Basic theory of Role-based access control; Set forth the basic principles and characteristics; give the analysis of demand from the perspective of software; give a set of design and implementation. Then, we have discussed the relationship of users, roles, and competence in detail and defined their relationship in the database structure. Also, the most popular MVC framework Struts2 is used to intercept the permissions of different users in order that the network resource is accessed in a legal and safe environment. The Significance of the paper lies in that we just propose and implement a framework for RBAC model, which will provide high reference value for future projects to develop similar system . Keywords: Access Control Role Permission Role-based access control3第一章 引言目录第一章 引 言11.1研究背景11.2 发展现状21.3论文组织形式3第二章RBAC及相关理论技术52.1 访问控制机制概述52.2 访问控制策略52.2.1自主访问控制(Discretionary Access Control，DAC)62.2.2强制访问控制(Mandatory Access Control，MAC)62.2.3基于角色访问控制(Role-based access control，RBAC)72.3 RBAC访问控制策略的提出82.3.1 RBAC基本概念82.3.2 基于角色的访问控制基本思想92.4 基于角色访问控制RBAC的优势10第三章 MVC框架与Struts2概述133.1 MVC理论概述133.1.1 MVC概念133.1.2 MVC工作过程133.1.3 MVC框架的优缺点分析143.2 MVC框架Struts2163.2.1 Struts2的诞生163.2.2 Struts2核心工作流程及原理193.3 Struts2的拦截器223.4 本章小结23第四章 RBAC的总体设计254.1 总体目标254.2 功能需求264.3 数据库结构的设计274.4 本章小结29第五章 RBAC的详细设计与实现315.1 Struts2的主要配置文件315.2 登录界面的设计335.3 登录处理页面(LoginAction)345.4 用户的CRUD操作请求355.5 拦截器部分365.6 功能页面action375.7 本章小结38第六章 总结与展望39致谢41参考文献42第一章 引 言1.1研究背景在Internet的出现和发展给我们带来方便的同时，一些安全性问题也突现了出来，因为网络平台的开放性，使得数据在网络上的传输存在许多安全隐患，可能造成信息的丢失，篡改，泄密，以及对信息系统造成的骚扰，破坏等严重后果。因此，网络信息安全问题己引起人们的广泛关注，并且已经成为当前网络技术研究的重点。为了解决这个矛盾，运用好网络信息平台这把双刃剑，人们提出了许多安全策略。这其中就包括在信息系统中使用访问控制(Access Control)来保证信息的安全1。访问控制是所有系统都必不可少的模块，但是各种不同的应用系统在访问控制的方式上各有特色，即使相同类型的系统在控制方式上也各有区别，这使得访问控制一直是系统开发中比较复杂的部分。现在的电子商务，电子政务等商业系统越来越大型化，协同化，不但需要保护系统资源不受侵犯，更需要给适当的访问者提供最大化的服务，这就要求系统必须要能够控制：哪些访问者能够访问系统的信息，访问者访问的是“什么信”，访问者对他所访问的数据拥有什么样的“权限”2 。可以用“Who对What(Which)是否能进行How的操作”来表述应用系统权限的需求。当前，不同领域的权限管理模块在具体的实现时具有一定的相似性。对不同的应用系统，开发不同的权限管理模块会造成重复开发，软件的重复利用率低下，并且带来软件后继维护困难等问题。在企业中，不同的应用系统都拥有一套独立的权限管理系统。每套权限管理系统只满足自身系统的权限管理需要，无论在数据存储、权限访问和权限控制机制等方面都可能不一样，这种不一致性存在如下弊端：a.系统管理员需要维护多套权限管理系统，重复劳动。b.用户管理、组织机构等数据重复维护，数据一致性、完整性得不到保证。c.由于权限管理系统的设计不同，概念解释不同，采用的技术有差异，权限管理系统之间的集成存在问题，实现单点登录难度十分大，也给企业构建企业门户带来困难。RBAC的出现在很大程度上改善了这一状况，它引入了Role的概念,目的是为了隔离User(即动作主体，Subject)与Privilege(权限，表示对Resource的一个操作，即Operation+Resource)。Role作为一个用户(User)与权限(Privilege)的代理层，解耦了权限和用户的关系，所有的授权应该给予Role而不是直接给User。基于角色的访问控制方法(RBAC)有两大显著特征是：其一、由于角色/权限之间的变化比角色/用户关系之间的变化相对要慢得多，减小了授权管理的复杂性，降低管理开销。其二、灵活地支持企业的安全策略，并对企业的变化有很大的伸缩性。 因此，本论文决定在现有访问控制模型的基础上设计和实现一个具有良好通用性的、可扩展的权限管理模块。这对于将来要开发或正在开发类似系统的开发者具有很高的参考价值。 1.2 发展现状 RBAC研究最初的学术文章是1992年美国NIST的研究人员David Ferraiolo和Richard Kulm发表的3。国内最早的相关学术论文是1994年华中理工大学(现在的华科)马建平的硕士学位论文一种无干扰的访问控制模型。在RBAC研究过程中，1996年美国George Mason大学的Ravi Sandhu教授在IEEE computer上发表了一篇学术文章4，在该文中Sandhu教授正式提出了RBAC96模型家族，它是RBAC模型研究的里程碑，为进一步地深入研究奠定了基础。此后国内外研究者在RBAC96模型家族的基础上提出了许多扩展模型。目前国外RBAC研究机构主要是美国NIST和George Mansion UnivLIST实验室(ProfRavi Sandhu)。NIST主要是进行RBAC及其相关模型的标准化工作，LIST侧重于对RBAC、RBDM及其扩展模型的创建、形式化描述，评价分析，以及在web中的应用等。国内主要是中国科学院软件研究所和华中科技大学计算机科学与工程系，他们正在对RBAC模型扩展和应用方面进行深入的研究。RBAC作为信息安全领域访问控制研究方向的一个分支，从上世纪90年代开始，到1996年里程碑式的RBAC96论文发表，开始了一个前所未有的研究高潮，这个高潮在国内外一直持续到2003年前后。纵观这个时期的国内外相关论文，可以看出众多的研究者在此方向作出了大量的、卓有成效的工作，以至于在2004年初NIST颁布了RBAC标准，该标准考虑到了大量RBAC扩展模型的思想，并给出了一个较为完备的RBAC参考标准模型，至此RBAC研究告一段落。目前国内外RBAC研究者较多，尤其是国内的硕博士论文都在此方向上开展了大量的工作。个人认为RBAC的理论研究目前已较为成熟，但基于这些理论的具体应用还不多，研究RBAC在不同计算环境和体系下的具体应用，做出重要的实践，以证明RBAC策略及其模型的有效性、高效性、可控性将是接下来一个时期研究的重点。当然，即便理论已经趋于成熟，但是依然有研究的空间，对RBAC的理论研究，尤其是RBAC在具体工作背景(体系)下完备的形式化描述工作，依然是今后研究的关键。可以说访问控制的形式化描述是一项极其重要的、颇有理论意义和研究价值的工作。1.3论文组织形式首先提出课题研究的背景及现状，分析了基于角色的访问控制(RBAC)在企业系统中的应用以及它给系统管理带来的便捷。分析了企业系统的结构，针对系统中用户(user)，角色(roles)，以及权限之间的多对多关系进行了数据库结构的设计。为了实现不同的角色只能具有相应的访问权限，使用到了struts提供的拦截器(interceptor)功能，成功的对用户的访问权限进行限制，保证了系统安全。另外文章中还对MVC设计模式作了简单的介绍，运用MVC思想对RBAC的各个具体模块进行了设计与实现。后续内容需要对RBAC具体的的管理功能作进一步的论述。论文主要分为六个章节，第一章是引言部分，简单的介绍了一下目前RBAC在国内外的研究情况和发展现状以及它在实际问题中的应用情况。在第二章节中，对访问控制策略以及RBAC相关理论技术作了具体的阐述和说明 。在论文的第三章，穿插了对MVC设计的介绍，本文主要用到了这一方面的知识，因此有必要对MVC具体的工作过程以及相关技术进行一下论述，这里只是对其中之一的Struts2进行了比较系统的介绍。第四章主要是对RBAC进行了总体设计与分析，具体包括对功能需求的分析，RBAC具体的工作流程以及对数据库结构的设计。第五章就是对RBAC具体的设计与实现，包括代码的编写以及最后实现的效果。最后一章就是对全文进行一个总结，分析一下可能存在的不足和需进一步努力的方向。11第二章 RBAC及相关理论技术第二章RBAC及相关理论技术 当前信息安全技术主要包括密码技术、身份认证、访问控制、入侵检测、风险分析与评估等诸多方面。在实际应用中，这些安全技术相互支持与协作，各自解决安全问题的某一方面，但目前人们关注的重点是密码技术、身份认证、入侵检测等，访问控制技术没有得到足够的重视。事实上访问控制技术是一个安全信息系统不可或缺的安全措施，对保护主机系统和应用系统的安全都有重要意义5。本章主要介绍访问控制机制和策略，比较了传统的访问控制模型：自主访问控制与强制访问控制，重点讨论基于角色的访问控制策略和模型，对相关理论进行研究，并在经典RBAC模型的基础上进行扩展和改进，提出新的模型框架通用RBAC模型，给出了模型设计目标，设计原则和模型定义。2.1 访问控制机制概述访问控制是计算机网络信息安全管理的主要策略，是通过某种途径显式的准许或限制信息资源访问能力及范围的一种方法6，访问控制技术是建立在身份认证的基础上，通过限制用户对关键资源的访问，防止非法用户的入侵或合法用户对资源的误用或滥用，因而能保证资源受控地、合法地使用。访问控制是实施允许被授权的主体对某些客体的访问，同时拒绝向非授权的主体提供服务的策略。这里主体(subject)可以是人，也可以是任何主动发出访问请求的智能体，包括程序、进程、服务等；客体(object)包括所有受访问控制保护的资源，在不同应用背景下可以有相当广泛的定义，比如在操作系统中可以是一段内存空间，在数据库里可以是一个表中的记录，在Web上可以是一个页面。访问的方式取决于客体的类型，一般是对客体的一种操作，比如请求内存空间，修改表中一记录，浏览页面等。通过对主体的授权，计算机系统可以在一个合法的范围内被使用，从而保证了客体被正确合理的访问，同时也维护了被授权主体的利益。这是访问控制的目的，同时也是一个安全系统所必须具备的特性。2.2 访问控制策略2.2.1自主访问控制(Discretionary Access Control，DAC)DAC是最常用的一类模型，最早出现在70初期的分时系统中，是一种多用户环境下最常用的一种访问控制技术，在目前流行的UNIX类操作系统中被普遍采用。它是基于客体一主体间的所属关系，根据主体所属的组来限制对客体的访问。所谓自主，是指主体可以根据自己的意愿，将访问控制权限授予其它主体，或从其它主体那里收回访问权限。也就是说，DAC的基本思想是将用户作为客体的拥有者，他有权自主地决定哪些用户可以访问他的客体。自主访问控制是基于用户的，具有很高的灵活性，适合于各类操作系统和应用程序，特别是在商业和工业领域。譬如用户需要在没有系统管理员介入的情况下，拥有设定其它用户访问其所控制信息资源的能力。在这种情况下，用户对信息的访问控制是动态的，这时采用自主访问控制就比较合适。但是自主访问控制策略也存在不能保证信息传输的安全性等隐患，它无法抵御特洛伊木马的攻击。在自主访问控制中，一旦带有特洛伊木马的应用程序被激活，系统无法辨别出哪些是用户所需的正常操作，哪些操作是特洛伊木马在起作用。 自主访问控制通常包括目录式访问控制、访问控制表、访问控制矩阵和面向过程的访问控制等方式。为了保证安全，自主访问控制策略的默认参考设置是拒绝访问的，以提高信息的安全性。2.2.2强制访问控制(Mandatory Access Control，MAC)MAC7是一种不允许主体干涉的访问控制策略。强制访问控制是根据客体中信息的敏感标签和访问敏感信息的主体的访问级对客体访问实行限制的一种方法，通过强加一些不可逾越的访问控制，系统可以防止某一些类型的特洛伊木马的攻击。在强制访问控制模型中，主体不能修改访问权，也不能将自己的访问权授予其它主体，而且系统对主体和客体都分配一个特殊的安全属性，而这一属性一般不能更改，系统通过比较主体和客体的安全属性来决定一个主体是否能够访问某个客体。用户的程序不能改变他自己及任何其它客体的安全属性。例如，在将安全等级作为安全属性的强制访问控制模型中，可以将安全等级分为多个级别8，譬如：最高秘密级(Top Secret)、秘密级(Secret)、机密级(Confidential)以及无级别级(unclassified)，并确定它们的高低偏序关系为TSSCU。这些安全级别可以支配同一级别或低一级别的物件。当一个主体访问一个客体时，必须符合各自的安全级别要求，特别是如下两个原则：(1)下读：主体的安全级别必须高于或等于被读客体的级别；(2)上写：主体安全级别必须低于或等子被写客体的级别。这些规则可以防止高级别对象的信息传播到低级别的对象中，这样系统中的信息只能在同一层次传送或流向更高一级。强制访问控制在军事和市政安全领域应用较多。例如，某些对安全要求很高的操作系统中规定了强制访问控制策略，安全级别由系统管理员按照严格程序设置，不允许用户修改。如果系统设置的用户安全级别不允许用户访问某个文件，那么即使该用户是该文件的拥有者也不能进行访问。强制访问控制的安全性比自主访问控制的安全性更高，但灵活性要差一些。 2.2.3基于角色访问控制(Role-based access control，RBAC)基于角色访问控制模型是目前国际上流行的先进的安全访问控制方法9。它通过分配和取消角色来完成用户权限的授予和取消，并且提供角色分配以及角色转换规则。安全管理人员根据需要定义各种角色，并赋予合适的访问权限，而用户根据其责任和资历被指派为不同的角色。这样，整个访问控制过程就分成两个部分，即访问权限与角色相关联，角色再与用户关联，从而实现了用户与访问权限的逻辑分离。由于实现了用户与访问权限的逻辑分离，基于角色的策略极大的方便了权限管理。例如，如果一个用户的职位发生变化，只要将用户当前的角色去掉，加入代表新职务或新任务的角色即可。研究表明，角色与权限之间的变化比角色与用户关系之间的变化相对要慢得多，并且给用户分配角色不需要很多技术，可以由行政管理人员来执行；而给角色配置权限的工作比较复杂，需要一定的技术，可以由专门的技术人员来承担，但是不给予他们为用户分配角色的权限，这与现实中的情况正好一致基于角色访问控制可以很好的描述角色层次关系，实现最小特权原则和职责分离原则。2.3 RBAC访问控制策略的提出RBAC模型在权限和用户之间增加了角色，用户与特定的一个或多个角色相联系，角色和一个或多个权限相联系，角色可以根据实际的工作需要生成或取消，大大降低了系统的复杂度。同时RBAC还体现了系统的组织结构，简洁并具有灵活性，大大降低了系统管理员误操作的可能性。根据角色的优点，通过使用角色很大程度上改进了在管理性和安全性上的不足。 2.3.1 RBAC基本概念用户(User)：用户就是一个可以独立访问计算机系统中的数据或者用数据表示的其它资源的主体，我们用USERS表示一个用户集合。用户在一般情况下是指人。角色(Role)：角色是指一个组织或任务中的工作或位置，它代表了一种资格、权利和责任。我们用ROLES表示一个角色集合。权限(Privilege)：权限是对计算机系统中的数据或者用数据表示的其它资源进行访问的许可。我们用PRIVILEGE表示一个权限集合。可分为对象访问控制和数据访问控制两种。主体(Subject)：即可以向应用系统发出应用请求的任何实体，包括各种用户、其它与本系统有接口的应用程序、非法入侵者。系统必须具有识别主体的能力，接口实际上也是由用户登记的，故主要问题是校验用户身份的合法性，系统应建立用户鉴别机构以验证用户身份。客体(Object)：被访问的对象。通常可以是被调用的程序、进程，要存取的数据、信息，要访问的文件、系统或各种网络设备、设施等资源。用户委派(User Assignment)：用户委派是USERS与ROLES之间的一个二元关系，我们用关系(U,R)来表示用户U被委派了一个角色R。权限配置(Privilege Assignment)：权限配置是ROLES与PRIVILEGE之间的一个二元关系，我们用(R,P)来表示角色R拥有一个权限P。角色激活(Role Activation)：是指用户从被授权的角色中选择一组角色的过程。用户访问的时候实际具有的角色只包含激活后的角色，未激活的角色在访问中不起作用。相对于静态的角色授权来说，角色激活是一种动态的过程，提供了相当的灵活性。会话(Session)：对应于一个用户和一组激活的角色，表征用户进行角色激活的过程。一个用户可以进行几次会话，在每次会话中激活不同的角色，这样用户也将具有不同的访问权限。用户必须通过会话才能激活角色。它们之间的关系如图2.1 图2.1 RBAC操作关系图2.3.2 基于角色的访问控制基本思想RBAC的基本思想可简单地用图2.2表示10，即把整个访问控制过程分为两步：1)角色指派，即用户委派(U,R)，使用户与角色相关联，通过角色使用户与访问权限在逻辑上分离。2)权限指派，即权限配置(R,P)，使角色与访问权限相关联。 图2.2 RBAC关系图由于RBAC实现了用户与访问权限的逻辑分离，因此它便于权限管理。例如，如果一个用户的职位发生变化，只要将用户当前的角色去掉，由代表新职务或新任务的角色代替即可，角色权限之间的变化比角色用户关系之间的变化相对要慢得多，并且委派用户为某角色不需要很多技术，可以由行政管理人员来执行，而配置权限到角色的工作比较复杂，需要一定的技术，可以由专门的技术人员来承担，但是不给他们委派用户的权限，这与现实中情况正好一致。在两种传统访问控制技术中，自主访问控制将赋予或取消访问权限的一部分权力留给用户个人，这使得管理员难以确定哪些用户对哪些资源有访问权限，不利于实现统一的全局访问控制，而且容易出错，也无法执行动态的和复杂的安全政策；而强制访问控制过于注重保密性，对系统连续工作能力、授权的可管理性等其他方面考虑不足11。基于角色的访问控制(Role Based Access Control, RBAC)是一种灵活、高效的访问控制方法，它有效地克服了传统访问控制(DAC,MAC等)技术中存在的不足，可以减少授权管理的复杂性，降低管理开销。RBAC在用户和权限之间引入了角色的概念，安全管理员根据实际需要定义各种角色，并设置和角色相对应的访问权限，而用户根据其职责被指派为不同的角色12。这样，访问权限和角色相关联，角色再与用户关联，使角色成为访问控制中访问主体和受控对象之间的一座桥梁。从而实现了用户与访问权限的逻辑分离。2.4 基于角色访问控制RBAC的优势相比较其它的访问控制策略，RBAC具有以下几点优势：(一)便于授权管理将角色作为一个桥梁，沟通于用户和资源之间。对用户的访问授权转变为对角色的授权，然后再将用户与特定的角色联系起来。一旦一个RBAC系统建立起来以后，主要的管理工作即为授权或取消用户的角色。用户的职责变化时，改变授权给他们的角色，也就改变了用户的权限。而当组织的功能变化或演进时，只需删除角色的旧功能、增加新功能，或定义新角色，而不必更新每一个用户的权限设置。(二)便于角色划分为了提高效率，避免相同权限的重复设置，RBAC采用了角色继承的概念，定义了这样一些角色，它们有自己的属性，但可能还继承其它角色的属性和权限。角色继承把角色组织起来，能够很自然地反映组织内部人员之间的职权、责任关系。(三)便于赋予最小权限原则所谓最小权限原则是指用户所拥有的权力不能超过他执行工作时所需的权限。实现最小权限原则，需分清用户的工作内容，确定执行该工作的最小权限集，然后将用户限制在这些权限范围之内。(四)便于职责分离对于某些特定的操作集，某一个角色或用户不可能同时独立地完成所有这些操作，这时需要进行职责分离。职责分离可以有静态和动态两种实现方式。(五)便于客体分类RBAC可以根据用户执行的不同操作集来划分不同的角色，对主体分类，同样的，客体也可以实施分类。23第三章 MVC框架与Struts2概述第三章 MVC框架与Struts2概述 MVC设计模式的出现不仅实现了功能模块和显示模块的分离，同时还给系统的维护提供了很大的便利。3.1 MVC理论概述 3.1.1 MVC概念 MVC设计模式中，M是指数据模型，V是指用户界面(即页面表示层)，C则是控制器。使用MVC的目的是将M和V实现代码分离，从而使同一个程序可以使用不同的表现形式。比如一批统计数据你可以分别用柱状图、饼图来表示。C存在的目的则是确保M和V的同步，一旦M改变，V应该同步更新。 模型视图控制器(MVC)是Xerox PARC在八十年代为编程语言Smalltalk80发明的一种软件设计模式，至今已被广泛使用。最近几年被推荐为Sun公司J2EE平台的设计模式，并且受到越来越多的使用 ColdFusion 和 PHP等开发语言的开发者的欢迎。模型视图控制器模式是一个有用的工具箱，它有很多好处，但也稍微存在着一些不足。3.1.2 MVC工作过程MVC是一个设计模式，它强制性的使应用程序的输入、处理和输出分开。使用MVC应用程序被分成三个核心部件：模型、视图、控制器。它们各自处理自己的任务。 视图 视图是用户看到并与之交互的界面。对以前的Web应用程序来说，视图就是由HTML元素组成的接口，在新式的Web应用程序中，HTML依旧在视图中扮演着重要的角色，但一些新的技术已层出不穷，它们包括Adobe Flash和象XHTML，XML/XSL，WML等一些标识语言和Web services. 如何处理应用程序的接口变得越来越有挑战性。MVC一个大的好处是它能为你的应用程序处理很多不同的视图。在视图中其实没有真正的处理发生，不管这些数据是联机存储的还是一个雇员列表，作为视图来讲，它只是作为一种输出数据并允许用户操纵的方式。 模型 模型表示企业数据和业务规则。在MVC的三个部件中，模型拥有最多的处理任务。例如它可能用象EJB和ColdFusion Components这样的构件对象来处理数据库。被模型返回的数据是中立的，就是说模型与数据格式无关，这样一个模型能为多个视图提供数据。由于应用于模型的代码只需写一次就可以被多个视图重用，所以减少了代码的重复性。 控制器 控制器接受用户的输入并调用模型和视图去完成用户的需求。所以当单击Web页面中的超链接和发送HTML窗体时，控制器(例如:servlet)本身不输出任何东西和做任何处理。它只是接收请求并决定调用哪个模型构件去处理请求，然后确定用哪个视图来显示模型处理返回的数据。 现在总结一下MVC的处理过程，首先控制器接收用户请求，并决定应该调用哪个模型来进行处理，然后模型用业务逻辑来处理用户的请求并返回数据，最后控制器用相应的视图格式化模型返回的数据，并通过表示层呈现给用户。 3.1.3 MVC框架的优缺点分析MVC设计模式受到广大设计开发者的喜爱，主要有以下一些优点:1) 低耦合性:视图层和业务层分离，这样就允许更改视图层代码而不用重新编译模型和控制器代码，同样，一个应用的业务流程或者业务规则的改变只需要改动MVC的模型层即可。因为模型与控制器和视图相分离，所以很容易改变应用程序的数据层和业务规则。2) 高重用性和可适用性:随着技术的不断进步，现在需要用越来越多的方式来访问应用程序。MVC模式允许你使用各种不同样式的视图来访问同一个服务器端的代码。它包括任何WEB(HTTP)浏览器或者无线浏览器(wap)，比如，用户可以通过计算机也可通过手机来订购某样产品，虽然订购的方式不一样，但处理订购产品的方式是一样的。由于模型返回的数据没有进行格式化，所以同样的构件能被不同的接口使用。例如，很多数据可能用HTML来表示，但是也有可能用WAP来表示，而这些表示所需要的仅令是改变视图层的实现方式，而控制层和模型层无需做任何改变。3) 较低的生命周期成本:MVC使降低开发和维护用户接口的技术含量成为可能。4) 快速的部署:使用MVC模式使开发时间得到相当大的缩减，它使程序员(Java开发人员)集中精力于业务逻辑，接口程序员(HTML和JSP开发人员)集中精力于表现形式上。5) 可维护性:分离视图层和业务逻辑层也使得WEB应用更易于维护和修改。6) 有利于软件工程化管理:由于不同的层各司其职，每一层不同的应用具有某些相同的特征，有利于通过工程化、工具化管理程序代码。MVC也存在一些不足之处，但是相对其优势来说可以忽略不予考虑:MVC的缺点是由于它没有明确的定义，所以完全理解MVC并不是很容易。使用MVC需要精心的计划，由于它的内部原理比较复杂，所以需要花费一些时间去思考领会。你将不得不花费相当可观的时间去考虑如何将MVC运用到你的应用程序，同时由于模型和视图要严格的分离，这样也给调试应用程序到来了一定的困难。每个构件在使用之前都需要经过彻底的测试。一旦你的构件经过了测试，你就可以毫无顾忌的重用它们了。根据开发者经验，由于开发者将一个应用程序分成了三个部件，所以使用MVC同时也意味着你将要管理比以前更多的文件，这一点是显而易见的。这样好像我们的工作量增加了，但是这比起它所能带给我们的好处是不值一提。MVC并不适合小型甚至中等规模的应用程序，花费大量时间将MVC应用到规模并不是很大的应用程序通常是得不偿失的。MVC设计模式是一个很好创建软件的途径，它所提倡的一些原则，像业务逻辑层和表示层互相分离可能比较好理解。但是如果要隔离模型、视图和控制器的构件，就可能需要重新思考你的应用程序，尤其是应用程序的构架方面。如果你肯接受MVC，并且有能力应付它所带来的额外的工作和复杂性，MVC将会使你的软件在健壮性，代码重用和结构方面上一个新的台阶。3.2 MVC框架Struts2Apache Struts(这里指Struts1.x) 作为最成功的 MVC Web 框架早已得到了广泛的应用，但是其自身也暴露出不少缺点，从而引出了Struts 2 。Struts2号称是一个全新的框架，但这仅仅是相对Struts 1而言。Struts 2 与Struts 1相比，确实有很多革命性的改进，但它并不是新发布的新框架，Struts 2 摒弃了原来 Struts 1 的设计，是在另一个赫赫有名的框架WebWork的基础上发展起来的。从某种程度上来讲，Struts2没有继承Struts 1的血统，而是继承WebWork的血统。或者说，WebWork衍生出了Struts2，而不是Struts1衍生了Struts2。因为Struts2是WebWork的升级，因此稳定性、性能等各方面都有很好的保证：而且吸收了Struts 1和WebWork两者的优势，因此，是一个非常值得期待的框架13。Apache Struts2是一个优雅的，可扩展的JAVA EE web框架。框架设计的目标贯穿整个开发周期，从开发到发布，包括维护的整个过程。 3.2.1 Struts2的诞生由于Struts1设计上的缺陷，使得它越来越无法满足开发人员要求高效，灵活的开发需求，很多开发人员开始选择其他优秀的Web开发框架。Struts1存在的问题主要有两个：(1)令人头痛的ActionForm；(2)单元测试困难下面具体看一下Struts1的这两个问题。1. 令人头痛的ActionForm使用Struts1框架开发过大型Web应用程序开发人员说起ActionForm，都是头痛加无奈。要理解ActionForm为什么让人头痛，就要从现代软件开发的分层结构说起。在现代企业软件开发中，分层与解耦是两个必须考虑的要素，经典的软件分层结构如图3.1所示。其中，数据访问层实现对数据库操作的封装，以隔离具体业务和数据库之间的联系；而业务逻辑层则实现对业务逻辑的封装，隔离用户操作的界面和具体业务逻辑；表现层即用户界面层，提供用户操作接口。这种封层封装的好处是分化了复杂的系统，同时也提高了系统的可维护性，使得开发过程中的分工协作更加方便快捷。采用这种层次结构，上层应该只依赖于它的下层结构，而不应该跨层依赖；同时，下层不应该依赖于它的上层结构，也就是说，业务逻辑层和数据访问层绝对不要依赖于表现层。在业务逻辑层和数据访问层的代码中，不要出现调用表现层代码的情况。遵循这个原则将简化在相同的基础上替换表现层的代价，也使得表现层的修改所带来的连锁反应尽可能小。图3.1 经典的软件分层结构Struts是属于表现层的技术，在Struts中，为了接收表单的数据，我们必须编写一个从Struts的ActionForm类继承的类，否则你就只能自己从HttpServletRequest中提取数据了。然而，不使用ActionForm，意味着你需要自己对表单数据做初始化，以及自己编写代码对表单数据进行验证。使用从ActionForm继承的类，如果更换Web框架，这个类也将被废弃。ActionForm中的数据往往需要传递给业务逻辑层和数据访问层处理，为了避免业务逻辑层和数据访问层依赖于Struts，通常会再编写一个和ActionForm类具有相同属性 的普通JavaBean类，在ActionForm对象接收到数据后，将其中的数据原封不动地复制到JavaBean对象中，然后将这个JavaBean对象向下层传递。想一想，如果能够直接使用普通对象的JavaBean对象来接收表单数据该多好，既可以避免多余的数据复制步骤，又可以不依赖于Struts框架。考虑到程序中可能还会存在着PO(Persistent Object，持久化对象，位于数据访问层，对应着数据库表中一条记录)和JavaBean对象之间的数据复制，加上众多的表单，对象与对象之间的数据复制会让人不胜其烦。2.单元测试困难在现代软件开发中，测试的重要性已经毋庸置疑。Struts1中的Action类与Servlet API耦合在一起，它的核心方法execute依赖于Servlet API中的HttpServletRequest和HttpServletResponse，其方法签名如下：Public ActionForword execute(ActionMapping mapping,ActionForm form,javax.servlet.http.HttpServletRequest request,javax.servlet.http.HttpServletResponse response)我们知道，HttpServletRequest和HttpServletResponse是由Servlet容器负责实例化的，因此Action类的测试就要依赖于Web容器，单元测试很难实现。当然，也可以使用第三方测试工具JUnit的扩展工具StrutsTestCase来对Action进行单元测试。除了上述两个问题外，Struts1还存在着一些其他设计上的不足，在这里就不一一列举了。Struts1开发团队也意识到了这一点，开始考虑Struts1的后续发展，于是WebWork进入了Struts1开发团队的视线。WebWork1.0是在2002年3月发布的，Rickard Oberg在研究了其他的Java Web开发框架之后创建了WebWork，引入了不少新的思想，概念和功能。2004年2月，WebWork2.0发布，从此WebWork拆分为XWork和WebWork两个项目。XWork完全脱离了Web层，成为一个可重用的组件，可供其他项目使用，WebWork2建立在XWork之上,负责处理HTTP请求和响应。WebWork解决了Struts1的ActionForm的问题，在WebWork中的Action没有和Servlet API耦合在一起，所以单元测试更加容易。虽然WebWork设计思想先进，功能强大，但市场占有率并不理想，Struts开发团队看中了WebWork的技术，而WebWork开发团队看中了Struts的人气和市场占有率，由于有共同的需求，于是一拍即合，决定合并开发。2006年，WebWork与Struts这两个优秀的Java Web框架(Web Framework)的开发团队，决定合作共同开发一个新的，整合了WebWork与Struts的优点，并且更加优雅、扩展性更强的框架，命名为“Struts2”，原先的Struts1.x版产品称为“Struts1”。Struts2是在WebWork2的基础上进行开发的，Struts2.0其实就是WebWork2.3，它和Strut1并没有多大关系。3.2.2 Struts2核心工作流程及原理 Struts2的体系结构如图3.2所示14：请求在Struts2框架中的处理大概分为以下几个步骤： 一个初始的请求到达Servlet容器(例如Tomcat或者Resin等)后，如在浏览器中输入http:/localhost:8080/xxx.action就是一个(HttpServletRequest)请求。将被传递给一个标准的过滤器链。这个过滤器链包括了可选的ActionContextCleanUp过滤器、其他过滤器(SiteMesh等)。ActionContextCleanUp这个在集成插件方面非常有用，当在Struts2 Web应用程序中集成SiteMesh时，将会用到这个过滤器。接下来，必须的FilterDispatcher被调用。调用FilterDispatecher会去查找相应的ActionMapper，如果找到了相应的ActionMapper它将会将控制权限委派给ActionProxy，ActionProxy将会通过ConfigurationManager来查找配置struts.xml，接下来，ActionProxy创建一个实现了命令模式的ActionInvocation。ActionInvocation在调用Action之前会依次调用所有配置的拦截器。 一旦action执行返回，ActionInvocation就要查找这个action的结果码所对应的result视图，然后执行这个result。通常情况下result会调用JSP或FreeMarker模板来呈现页面(但不总是这样，例如result也可以是一个Action链)。当呈现页面时，模板可以使用框架提供的Struts标签。其中一些组件可以和ActionMapper一起工作来为后面的请求呈现正确的URL。 拦截器被再次执行(执行顺序和开始相反)，最后响应被返回给在web.xml中配置的这些过滤器。如果已经设置了ActionContextCleanUp过滤器，那么FilterDispatcher就不会清理ThreadLocal中的ActionContext信息；如果没有设置ActionContextCleanUp过滤器，则FilterDispatcher会清理掉所有的ThreadLocal。 图3.2 struts