《java动态代理实现Authorization》由会员分享，可在线阅读，更多相关《java动态代理实现Authorization（15页珍藏版）》请在金锄头文库上搜索。
1、动态代理实现Authorization （授权） *java.lang.reflect 包中的 Proxy 和 InvocationHandler 接口提供了创建（指定类接口更 准确些的）动态代理类的能力。我们知道，对象是类的实例，一般使用内存来模拟对象，对象是依据类为模板来创建的，创 建时使用 new 来分配一块内存区（其布局参考相应类的内存布局） ，为变量做一些赋值便是对象的初始化了。我们知道通常类是设 计时的产物，在设计时我们编写对象的模板（即类），运行时 产生类的实例。类所处的文件是 .java 文件源文件，之后编译为 jvmjava 虚拟机可解释执行的.class字节码文件，在类解析
2、过程中这些.class文件由类加载器加载到虚拟机（可实现自己的类加载器来加载处于特定路 径下的类，或加载用某种加密算法加密过的类文件-这样便于进行安全控制具体描述参考（ Core java Java 核心卷二）。在遇到创建对象 的指令时使用加载的类来创建对象内存 空间。动态代理是不用创建类文件（当然也不用创建 java 源文件），就能在虚拟机中构造 出类文件区域来（相当于使用 Proxy 类来创建一块类内存区域，该区域中的内容相当于加载某个.class文件产生的区域；比如我们在 使用 DOM 技术时，从一个 XML 文件构造一个DOM 内存表示，它是 XML 文件的内存表示，但我们也可以直接使
3、用 DOM API 在内存中构建一 个 dom 树，最终结果就是一个内存 DOM 树，你不用关心 这个 dom 树是来自于 xmL 文件还是直接的运行时构造）。* * 关于代理设计模式，这里不再敷述。代理和被代理类（目标类）实现共同的接口。我们在调 用时不需区别它是否是真正的目标对象。代理会转发请求到目标对象的。比如互联网上的代理服务器，我们不必关心它是不是代理， 就当它不存在一样。对客户调用端他是不关心具体是谁来提供这个服务功能；在服务端选择使用代理的原因可能是：安全，日 志，防火墙等。就是说代理可提供一些非功能性功能，比如缓存功能_来加速服务的响应的速度。在面向方面技术（AOP）中这 些非
4、功能性需求被称作“方面”他们横切于功能类的实现中，比如：某个SubServerlmpl （子服务实现）中的某个服务方法： subServer.doService（）/在日志输出中常有类似的代码出现于多个类实现中 loger.log（）; 如果已经存在了一个服务实现，你还需要加入日志功能，而又不想改动既有的实现，也不想 太多的改动客户端，我们可以引入一个代理类：class SubServerProxy extends ISubServer ISubServerProxy target;public SubServerProxy(ISubServerProxy target) / 代理依赖于具体的
5、子服务实现，至于设值依赖的接口这里就 不给出了/ 这里只提供构造子依赖注入的接口。 this.target=target; public void doService()/ 实现接口 loger.log();对于客户代码，以前可能是这样：class Clientpublic doSomeThing()/ 你或许处于网络环境中，可能使用了名字服务，那么改这里 的 new 操作为 Lookup 即可；ISubServer server= new SubServerImpl();引入了代理后只需要改为：ISubServer server二 new SubServerProxyO;即可， 之后的代码不
6、需要改动依据是 Liskov 替代原理(请参考 Robert Mar tin 的Design Principles and Design Patterns_google 直接搜索该文章)。由于我们在客户端依赖了抽象(即直接使用了继承层次树中的根 ISubService)。* 上面给出了代理类的一些常用的用途，可以看出这样的非功能性需求会出现在很多代码中， 我们不得不在多个类的多个方法中 加入这些讨厌的重复代码，并且可能实现多个代理类(代理本身仍旧可以选择再使用其他的 代理，每个代理完成不同的方面，随后我会使用动态代理来展示这点的)。这样代理类的数目急剧膨胀，加大了维护和开发投入。借 助动态代理
7、类我们不需要为每个意欲附加非功能性需求的类来在运行时生成一个动态代理。并且你还可以在以后重用InvacationHandler 实现。以下讨论本篇的重点。:-)* *关于 Authorization (授权)：许多软件系统中，我们都需要授权访问功能，允许某个特定用户访问特定的功能集。将整个 系统对用户提供的功能，看作一个集合，这些集合中其中一部分对该用户可以访问，另一些对该用户不可以访问。最完美的访问控制 技术，当然是实现访问控制矩阵。替代的 ACL 访问控制列表也可以实现。访问控制矩阵概述：矩阵分两个轴，随便一个轴列出所有的主体(如可以是userName)，另 一个轴给出系统提供的所有客体(
8、功能单元)，在矩阵交叉的单元是 1，或0；1表示主体可以访问该客体， 0表示主体不可以访问该客体。ACL访问控制列表概述：由于访问矩阵中0出现的很多，在使用矩阵结构时造成大量的空间 浪费，即稀疏矩阵。我们只记载访问控制矩阵中是1 (当然也可以是0)的主体和客体，这样我们在一个轴向上使用一个列表来存放所有 的主体或客体，每个列表中的单元上 还有一个列表，其中给出了该主体(或客体)能够访问的客体(或可访问该客体的主体)。伪码实现：class AccessRelationEntry/该类表示一个访问关系的入口User user;/表示主体Lis t objec ti ves;/这是一个客体列表 pu
9、blic AccessRelationEntry(User user) this.user=user;this.objectives=new List();/该方法可将一个客体加入到某个主体可访问的列表中去 public void addObjective(Object objective ) this.objectives.add(objective);public User getUser()return this.user;public boolean hasPermission(Object objective)return this.objectives.contain(object
10、ive);以上只是在一个轴的实现，另一个轴如下：/该类其实可以实现为一个全局共享的静态类，方法全为 staticclass ACLManagerList acl=new List();public void addAccessRelationEntry(AccessRelationEntry aRE) this.acl.add(aRE);public boolean hasPermission(User user,Object objective)/ 看某个特定用户和对象是否出现访问控制列表中/ 出现则表示有权限，否则无权限，当然也可反逻辑实现。/ 遍历访问控制列表 for(AccessRel
11、ationEntry are:acl) if(are.getUser().getName().equals(user.getName()return are.hasPermission(objective); /遍历完成，如果函数仍未返回表明，没有指定的用户，处理略 .。*Authorization 设计模式(详见 POSA 卷四)： 对于系统中子系统提供的功能，并非每个客户端都能够访问，对于一些敏感的信息(如：工 资，医疗信息等)， 仅授权用户才可访问。对于提供这样服务的模块(或称为组件，子系统等)，将 “trusted”client 硬编码到 组件中是很笨拙且高维护代价的一种实现。(即将每
12、个可访问该客体的主体信息硬编码到该 组件的实现中)。所以： 将访问权限赋予可访问安全敏感的子系统的用户，并在在子系统上执行任何请求之前检查用 户的权限。由高权限用户来为普通用户授权；在每个组件(或称子系统)的每个方法调用之前执行权限 检查；伪码如：class SubSysImplpublic void doServiceA()/* */ 授权设计模式的主要优点是，仅有授权的用户才可访问该子系统，这对安全敏感的应用系统 很重要，另一个优点检查特定的访问权限（或policies）可对客户和组件透明。对授权基础结构实现的通用形式是ROLE-BASED ACCESS CONTROL （基于角色的访问控
13、制）。 不是把单个访问权限（AccessRigh ts）赋给每个用户，在系统中定义了一些角色集（如： administrator，power user， guest等），用户（User）可与某个角色关联，每个角色对应 了一些访问权限集。REFERENCE MONITOR补充了授权体系结构，所有的用户请求都会被一个中央引用监视器“拦 截”，拦截后检查用户的访问权限是否与应用的授权规则一致。这种设计集中化了访问权限的检 查对每一个客体都需要（必要时）先通过monitor的检查，然后才可访问。可使用多个引用监 视器来最小化性能或减小瓶颈，减小单点失败的可能。* 权限的粒度：对一个主体，和客体。访问粒度（或深度）可以是很细的，比如到方法级别， 也可以到对象级别，在上面的授权模式中doServiceA就是一个方法级别的权限检查。本篇的主题是，动态代理来实现授权设计模式。权限的粒度可以到方法级别，篇首给出了动态代理的简要描述，动态代理中关键点是那个Invocationhandler接口，他在 AOP 中角色相当于interceptor （请参考j2ee development without EJB，或其他AOP技术资料）， 各种方面的“织入”也发生在这里。请看下面的关系图：（使用 Enterprise Architect
