以往在J2EE系统中，访问权限控制系统的实现主要有两种：应用程序实现和J2EE容器实现。

传统的应用程序实现

这是最直接的、传统的一种解决方式，通常是在具体方法前加一个权限判断语句，如下：

public class ForumFactoryProxy extends ForumFactory {
　　......
　　public Forum createForum(String name, String description)
　　　　throws UnauthorizedException, ForumAlreadyExistsException
　　{
　　　　if (permissions.get(ForumPermissions.SYSTEM_ADMIN)) {
　　　　　　Forum newForum = factory.createForum(name, description);
　　　　　　return new ForumProxy(newForum, authorization, permissions);
　　　　}else {
　　　　　　throw new UnauthorizedException();
　　　　}
　　}
　　......
}

上述代码是Jive论坛中一段创建论坛功能的代码，在创建论坛前，首先进行权限角色检验，如果当前用户是系统管理员，那么可以实现真正的创建。

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

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

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

J2EE容器实现

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

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

非常明显，通过容器实现权限控制验证可以大大简化应用程序的设计，分离了应用系统的权限关注，将权限控制变成了对J2EE容器服务器的配置工作。其实，容器的权限实现也是一种从一个切面来解决问题方式，AOP概念诞生后，权限控制实现由此也带来了两个方向的变化：

1. J2EE容器级别的权限实现，也就是容器自身的权限实现。

2. J2EE应用程序级别的权限实现。

权限控制在容器级别实现似乎使得J2EE开发者感觉没有灵活性和可扩展性，其实象JBoss 4.0这样的J2EE容器，由于引入了AOP概念，使得J2EE开发者在自己的应用系统中能够直接操纵容器的一些行为。容器和应用系统由于AOP引入的Aspect切面，变得可以成为一体了。（如果使用BEA的EJBC编辑要浪费多少时间？）

1 2 下一页>>