AOP下的权限控制实现

　　摘要 面向方面编程(AOP)是一种新编程技术，它弥补了面向对象编程(OOP)在跨越模块行为上不足。AOP引进了Aspect，它将影响多个类行为封装到一个可重用模块中，它允许程序员对横切关注点进行模块化，从而消除了OOP引起代码混乱和分散问题，增强了系统可维护性和代码重用性。本文分析传统权限控制实现方法，并研究了在AOP下权限控制实现方法。 字串5

　　关键词 AOP；横切关注点； 设计模式； 权限控制 字串3

　　OOP应用开发面临问题 字串8

　　面向对象技术很地解决了软件系统中角色划分问题。借助于面向对象分析、设计和实现技术，开发者可以将问题领域“名词”转换成软件系统中对象，从而很自然地完成从问题到软件转换。 字串3

　　但是，问题领域某些需求却偏偏不是用这样“名词”来描述。比如遇到这样问题：需要对系统中某些方法进行权限检验，这种需要权限检验方法散布在40多个类中。面对这种需求，应该怎么办呢？最直接办法就是：创建一个起类（或接口），将权限检验功能放在其中，并让所有需要权限检验类继承这个起类（或接口）．如果这个需求是后期提出．需要修改地方就会分散在40多个文件中。这样大修改量，无疑会增加出错几率，并且加大系统维护难度。

　　人们认识到，传统程序经常表现出一些不能自然地适合单个程序模块或者几个紧密相关程序模块行为例如权限检验、日志记录、对上下文敏感错误处理、性能优化以及设计模式等等、我们将这种行为称为“横切关注点（crosscuttingconcern）”，因为它跨越了给定编程模型中典型职责界限。如果使用过用于横切关注点代码，您就会知道缺乏模块性所带来问题。因为横切行为实现是分散，开发人员发现这种行为难以作逻辑思维、实现和更改。 字串7

　　AOP基本思想

　　AOP是Aspect Oriented Programming缩写，意思是面向方面编程，一种新兴编程技术。AOP实际是GoF设计模式延续，设计模式孜孜不倦追求是调用者和被调用者之间解耦，AOP可以说也是这种目标一种实现。它可以解决OOP和过程化方法不能够很解决横切（crosscut）问题，如：事务、安全、日志等横切关注。当未来系统变得越来越复杂，横切关注点就成为一个大问题时候，AOP就可以很轻松解决横切关注点这个问题。

　　 字串9

字串5

　　图 1 把模块作为一批关注点来实现

字串5

　　通常，为满足整个企业应用某方面得需求，开发者（架构师）需要整理出系统得关注点。图 1形象地描述了关注点，它能够从AOP Aspect角度看待系统。比如，持久化、日志、应用业务逻辑通常被认为是应用需要解决问题。因此，他们通常作为关注点看待。从整个系统角度考虑，它往往是由大量关注点构成。 字串4

　　我们把AOP看作是OOP延续，而不是竞争对手。OOP在通常场合下工作得很，但在特定领域里却有所欠缺：举例来说，如果我们必须为多个对象和方法应用相同事务行为，我们需要将同样代码剪切/粘贴到每一个方法里。AOP让我们可以把这类问题封装到方面（aspect）中，从而更地实现模块化。AOP定义了“切入点”（pointcut）概念，让开发者可以从另一个角度来思考程序结构，从而弥补了OOP某些缺陷：如果需要对一组方法施加横切行为，就应该拦截这些方法。 字串1

　　在J2EE应用开发中，我们主要用到AOP拦截（interception）能力，它为我们提供了“在任何对象方法调用前/后加入自定义行为”能力，这使得我们可以处理企业应用中横切（crosscutting）关注点（即：同时作用于多个对象关注点），并且仍然保持强类型（不需要改变方法签名）。 字串7

　　权限控制应用程序实现

字串5

　　对于权限管理做法，在WEB实现上，有以下几种： 字串2

　　⑴ 利用Filter，对所有进入URI进行解析，并取得当时Session中User信息，然后通过RBAC机制，将此链接需要权限与用户拥有权限进行比较，然后进行相应处理。这种做法有很多处：简单，容易实现，并且对系统侵入性也不强。这里URL就是RBAC中资源了。这样做缺点是所有对数据操作必须通过URL来体现，这一点在现代程序中不太实现。如果采用Struts, XWork或者Tapestry，采用同一个URL（浏览器看来）进行处理多项任务已不是什么稀奇事。 字串2

　　⑵ 利用一个BaseServlet(Servlet Jsp经典模式)或者BaseAction(Struts模式)或者BasePage(Tapestry模式)或者BaseController(SpringMVC模式)，对所有请求先进行过滤进行权限操作，然后再处理。稍微看一下就知道这种模式跟Filter并无本质不同。优缺点同上。

　　那么，如果要实现更为细致权限操作，精确到某个方法权限，典型做法如下：

　　这种做法能够将权限粒度控制到具体业务方法，因此它控制能力应该是强大。可以看到，权限判断部分对于每个方法几乎是独立。

字串2

　　这种在具体功能前加入权限操作检验实现方式有很多缺点：

　　⑴ 每个功能类都需要相应权限检验代码，将程序功能和权限检验混淆在一起，存在紧密耦合性，扩展修改难度大。

　　⑵ 以代理模式为每个功能类实现一个相应代理类，虽然解耦了程序功能和权限检验，但是，从某个角色权限检验这个切面考虑，涉及具体Proxy类太多，扩展修改难度大。

　　权限控制J2EE容器实现

　　在AOP概念没有诞生前，J2EE规范已经提供了关于权限控制容器实现标准，这种变迁结果如下图所示： 字串6

　　图2 权限控制J2EE容器实现 字串1

　　原来需要每个应用程序实现权限Proxy转为整个容器Proxy实现，其中JDK1.3以后动态代理API为这种转换实现提供了技术保证。

　　非常明显，通过容器实现权限控制验证可以大大简化应用程序设计，分离了应用系统权限关注，将权限控制变成了对J2EE容器服务器配置工作。 字串4

　　其实，容器权限实现也是一种从一个侧面来解决问题方式，AOP概念诞生后，权限控制实现由此也带来了两个方向变化：

字串3

　　⑴　J2EE容器级别权限实现，也就是容器自身权限实现。 字串5

　　⑵　J2EE应用程序级别权限实现。

　　权限控制在容器级别实现似乎使得J2EE开发者感觉没有灵活性和可扩展性，其实象JBoss 4.0这样J2EE容器，由于引入了AOP概念，使得J2EE开发者在自己应用系统中能够直接操纵容器一些行为。容器和应用系统由于AOP引入Aspect切面，变得可以成为一体了。 字串8

　　对于J2EE应用系统开发者，能够做到上述境界，必须条件是对JBoss之类J2EE容器必须有足够了解，因为这些方式并不是J2EE标准，有可能在移植到新J2EE容器，这些知识和投入变得无用（也有可能将来J2EE扩展其标准）。

字串1

　　很显然，使用AOP实现J2EE应用系统级别权限控制，是解决上述移植风险一个主要方法，但是带来缺点是必须亲自从零开始做起，耗费时间不会很短。

字串6

字串1

　　AOP下权限控制实现 字串5

　　有了AOP，新业务方法可以这样写：

字串4

　　没有了额外权限操作，这个业务方法看起来那么清晰自然。 字串3

　　将对权限操作作为一个Advice，并将Advisor关注到所有业务方法（可能有某一个特定package），然后，剩下事情就由RBAC以及AOP来完成了。通过这样分离，纵向一个业务方法被分割为一个更为自然业务方法和一个关注点。这个关注点写法可能如下： 字串2

　　可能有个问题：如何取得context或者当时上下文环境User呢？答案是使用IoC（或称Dependency Injection），将上下文环境或者User作为参数反向传入到逻辑方法中。当然，在传入之前，这些变量是需要初始化。这个初始化工作可以在SuperServlet中进行，并且以Session单例形式保存在应用程序中。下面是Spring配置文件例子： 字串9

　　结束语 字串5

字串6

　　AOP引进了Aspect，它将影响多个类行为封装到一个可重用模块中，它允许程序员对横切关注点进行模块化，从而消除了OOP引起代码混乱和分散问题，增强了系统可维护性和代码重用性。利用AOP拦截（interception）能力，它为我们提供了“在任何对象方法调用前/后加入自定义行为”能力，这使得我们可以处理企业应用中权限控制这一横切关注点，并且仍然保持强类型（不需要改变方法签名），解耦了程序功能和权限检验。

字串5