使用Spring AOP和AspectJ编排工作流 - 编程入门网

这意味着如果我们把转移求值逻辑放在活动中，我们将从根儿上把这两个关注点耦合在一起（活动转移罗辑和活动业务罗辑），这将违背分离关注点的基本架构原则并将导致关注点/代码耦合（concern/code coupling）。另一个问题则涉及到所有拦截过滤器会重复同一转移逻辑。我们称之为关注点/代码扩散（concern/code scattering）。转移逻辑横贯所有拦截过滤器，你可能已经猜到了，AOP再次成为所选技术。

我们所需做的一切就是写一个around advice，它将使我们能够拦截对实际过滤器类目标方法的调用，对输入求值，并作出转移决策，要么允许，要么不允许目标方法执行。唯一要告诫的是我们的目标类本身恰恰就是拦截过滤器。因此本质上我们正在试图拦截拦截器。不幸的是Spring AOP不能帮上忙，因为它是基于代理的，因此我们的拦截过滤器已经是代理基础架构的一部分了，我们不能代理这个代理（proxy the proxy）。

但是AOP最好的特性之一就是它可以有多种不同的风格和实现（例如，基于代理的，字节码编织等等……）。尽管我们不能使用基于代理的AOP来代理另一个代理，但是我们使用字节码编织AOP,谁也拦不住，它将通过编织（编译时或装载时）我们的转移求值逻辑，来形成我们代理的拦截过滤器，这样就可以保持转移和业务逻辑分离。使用像AspectJ这样的框架很容易做到这一点。这样做，我们就给我们的架构引入了第二个AOP层，这是非常有意思的实现。我们使用Spring AOP来解决功能关注点，比如用活动编排流程；同时，我们又使用AspectJ来解决非功能关注点，比如活动导航和转移。

下图记录了被显示为两个AOP层的流程流的最终结构，其中功能AOP层（Functional AOP Layer）负责从有序的拦截过滤器集合中装配流程，而非功能AOP层（Non-Functional AOP Layer）则解决转移控制的问题。

为证明这一架构的工作情况，我们将实现一个简单的用例——购买物品（Purchase Item），它定义了一个简单的流程流。

使用Spring AOP和AspectJ编排工作流(4)

4.用例（购买物品）

想象一下你正在在线购物。你已经选择了某项物品，把它放入到购物车中，然后前去结账，给出你的信用卡信息并最终提交购买物品请求（purchase item request）。系统将初始化购买物品流程（Purchase Item process）。

先决条件

流程必须接收包含物品、账单、配送信息的数据

主流程

1.校验物品数量

2.获得贷记授权

3.配送

这个流程当前定义了3个活动，如下图所示：

这个图还显示了不受控制（ungoverned）的活动转移。但实际上，如果物品数量不够会发生什么？“获得贷记授权”活动应该执行吗？“配送”应该随之进行吗？

另一个有趣的告诫是：根据条件，贷记授权（credit authorization）可能不会自动完成（授权网络关闭了），而你或客户服务代表不得不直接打电话给贷记公司以获得认证码。一旦该认证码被获得并输入到系统中，这个流程应该从何处重新开始或继续呢？从头来还是直接进入配送环节？我觉得应该进入配送环节，但是怎样才能做到呢？我们怎么才能从中间重新启动该流程，而不用维护和管理许多执行控制呢？

有意思的是，使用AOP我们不需要维护执行控制，也不需要维护流程的流向。它是在通过拦截过滤器链时由框架本身来处理的。我们需要做的一切就是提出一种机制，根据注

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!