为AOP注入团队活力(3)

安全需求：

安全组件用于通过用户认证和授权提供访问控制。这里假设采用存储登录名和密码的简单用户管理。授权和认证的功能需求将在下面进行描述。授权依赖于认证，如果只需要认证，被认证的用户将具有对应用的完全控制。

对于认证的最小化需求是login特性：如何执行登录，比如通过用户接口或是操作系统用户识别的方式实现。login特性并不意味着需要logout。在最简化的环境下的logout就是关闭应用程序。而一个可选的logout特性是支持明确地从系统登出。在登出后，一个新用户或是同一用户可以登入。timeout也可作为自动logout的一种方式：在一个可配置的时间段后没有用户交互的自动登出。logout和timeout都需要login特性，而logout和timeout彼此并不需要，但如果缺少logout，那么意味着使用timeout。如果没有明确的logout，timeout将关闭应用。但如果login采用操作系统的用户识别技术，则可能它无法为logout和timeout提供支持。

授权对不同用户和不同访问权限进行区分。它作用于业务数据对象和工作流。

安全设计问题：

图2：定义安全组件环境的Teams

此案例认证部分的通用解决方案由四个模块组成，每个模块采用team概念进行封装：

1．LoginManagerTeam：是其它team的基础。它管理对登陆的处理。
2．LogoutOptionTeam、TimeoutOptionTeam：是采用team实现的两个可选特性。
3．AuthorizationTeam：实现了授权功能。

这些team是抽象的，它们只实现了安全组件的基本功能。它们能相互独立地去适配具体系统。

LogoutOptionTeam和TimeoutOptionTeam依赖于LoginManagerTeam，比如它们需要login信息。

LoginManagerTeam则独立于这两个team，而且不必将它的内部结构公开。通过“playedBy”关系，LogoutOptionTeam和TimeoutOptionTeam能访问LoginManagerTeam的那些没有明确可见的特性，并在需要时去适配LoginManagerTeam的行为。LoginManagerTeam被设计为与其它team无关。相同的，AuthorizationTeam也依赖LoginManagerTeam，但并非反之亦然。

这些可选项（logout和timeout）之间是独立的，如果它们中的一个没有相应的subteam（指这个team的子类）或是相应的subteam没有激活，那么这个可选team就是无效的。team概念甚至允许在运行时激活或者冻结可选项：比如，一个依赖用户的（user-dependent）timeout通过冻结或激活某个用户的timeout的方式轻松实现。

这些需求导致了安全组件的抽象解决方案成为了一种类似框架的设计。抽象实现应该是足够灵活以适合不同的系统。而实现具体层次和适应底层组件的策略在系统之间的差异万千。最后，我们针对应用在部署组件的安全解决方案实现了team的三步改进：通用解决方案、具体部署解决方案、依赖变体（面向对象或者面向Aspect两种方式的实现）的解决方案。在改进抽象安全解决方案的过程中，我们已经发现了一套设计模式，它们可以在不同的具体team层次上进行灵活的改进。

重用Aspect的模式：

在本章节将提供一些在实现安全案例研究时的模式。而另一个模式将在实现可行性研究时介绍。所有这些模式构成了一个通用解决方案：实现一个抽象team、一个从通用解决方案继承和改进而来的特定解决方案。在下面，我们在抽象层调用这个通用解决方案，在具体层继承和改进这个方案。

依赖性激活：

图3：依赖性激活

不同的team模块在它们被初始化和激活之前，在它们所需要建立的环境（context）的过程中存在着不同之处：某些模块在程序启动时被激活，而另一些team这需要预先执行适当的初始化。

于是，针对这种状况，一种能灵活支持多种依赖的解决方案现身了：

在这个安全案例研究中，上述问题发生在实现安全管理器（security manager）时。这个安全管理器作为一个team，激活所有安全相关的team使它们为部署组件提供安全。在被分别被两位工程师开发的情况下，每个部署的变体都有自己的启动机制。我们希望针对这两个变体（由开发者确定何时激活被安全管理器所管理的team）在抽象层上制定用统一、通用的解决方案。

这个问题的解决方案展示在图中。在抽象层，初始化方法：activateTeams——被引入到team中。另外，一个role：AppAdapter——具有一个调用初始化方法的方法。注意：我们的安全管理器是一个team，而并非Java安全管理器。

在具体实现层，我们有两种改进superteam的方法：

1．直接实现初始化方法，图中显示在AOSecurityManager team中。就像在例子中那样，通常情况下，这个初始化方法将被team的构造方法所调用。这个team的构造方法将作为“钩子”被钩放到应用的启动机制中。

2．AppAdapter role被解放出来。在本例中，OOSecurityManager team将其所包含的role绑定到base系统的一个类，使初始化方法通过callin绑定的方式被间接调用。

3．在本例中，AppAdapter role被绑定到base类OODisposition，activateTeams方法通过拦截base类的方法start的方式调用initialize方法。这样，OOSecurityManager的实例在应用启动时被构造并激活。

特性选择：

图4：特性选择