使用Spring来创建一个简单的工作流引擎

  spring是支持控制反转编程机制的一个相对新的框架。本文把spring作为简单工作流引擎，将它用在了更加通用的地方。在对工作流简单介绍之后，将要介绍在基本工作流场景中基于Spring的工作流API的使用。

　　许多J2EE应用程序要求在一个和主机分离的上下文中执行处理过程。在许多情况下，这些后台的进程 执行多个任务，一些任务依赖于以前任务的状态。由于这些处理任务之间存在相互依赖的关系，使用一套基于过程的方法调用常常不能满足要求。开发人员能够利用 Spring来容易地将后台进程分离成活动的集合。Spring容器连接这些活动，并将它们组织成简单的工作流。

　　在本文中，简单工作流被定义成不需要用户干预，以一定顺序执行的任意活动的集合。然而，我们并不建 议将这种方式代替存在的工作流框架。在一些场景中，需要更多的用户交互，例如基于用户输入而进行的转向，连接或传输，这时，比较好的方法是配用一个单独的 开源或者商业的工作流引擎。一个开源项目已经成功地将更复杂的工作流设计集成到spring中。

　　如果你手上的工作流任务是简单的，那么，与功能完备的独立工作流框架相比，简单工作流的策略就会变 得有意义，特别地，如果已经使用了spring，这种快速实现可以保证时间不会变得更加漫长。此外，考虑到spring轻量级的控制反转容器的特 点，spring在资源负载上减少了资源负载。

　　这篇文章简短地从编程主题的角度介绍工作流。通过使用工作流的概念，spring被用来作为驱动工作流引擎的框架。然后，讨论了生产部署选项。现在，让我们从工作流的设计模式和相关背景信息来介绍简单工作流的思想吧。

　　简单工作流

　　工作流模型是一个早在70年代就有人开始研究的主题，许多开发者都试图创建工作流模型规范。 W.H.M. van der Aalst等人写了《工作流模型》白皮书(2003年7月)，它成功地提炼出一组设计模式，这些设计模式准确地将大多数通用的工作流场景建模。当中，最普 通的工作流模式是顺序模式 (Sequence pattern)。顺序工作流模式满足了简单工作流的设计原则，并且由一组顺序执行的活动组成。

　　UML（统一建模语言）活动图通常被用来作为一个机制对工作流建模。图1显示了一个基本的使用标准UML活动图对顺序工作流过程的建模过程。

图 1顺序工作流模式

　　顺序工作流是一个在J2EE中流行的标准工作流模式。J2EE应用程序在后台线程中，通常需要一些顺序发生的事件或者异步事件。图2中的活动图描述了一个简单的工作流，用来通知感兴趣的旅行者，他们感兴趣的目的地的机票价格已经下降的事件。

图 2.机票价格下降的简单工作流

图1中的航线工作流负责创建和发送动态的email通知。过程中的每一步表示了一个活动(activity)。在工作流处于活动之前，一些额外事件必须发生。在这个例子中，事件是飞行路线费率的减少。

　　让我们来简要的看一下航线工作流的业务逻辑。如果第一个活动找不到对费率减少通知感兴趣的用户，那么整个工作流就被取消。如果发现了感兴趣的用 户，那么接下来的活动继续执行。随后，一个XSL（扩展样式表）转换生成消息内容，之后，记录审计信息 (audit information)。最后，工作流试图通过SMTP服务器发送这个消息。如果这个任务没有错误地完成，便在日志中记录成功的信息，进程结束。但是， 如果在和SMTP服务器通讯时发生了错误，一个特别的错误处理例程将要管理这些错误。错误处理代码将会试着去重新发送消息。

　　考虑这个航线的例子，一个明显的问题是：你怎么样有效地将顺序处理过程分解为单独的活动？这个问题被spring巧妙的处理了。下面，让我们快速地讨论spring的反转控制框架。

　　控制反转

　　Spring通过使用spring容器来负责控制对象之间的依赖关系，使得我们不再对对象之间的依赖负责。 这种依赖关系的实现就是大家所知道的控制反转（IoC）或依赖注射。参见Martin Fowler's "Inversion of Control Containers and the Dependency Injection Pattern"(martinfowler.com, 2004年2月)得到关于控制反转和依赖注射的更加深入的讨论。通过管理对象之间的依赖关系，spring就不需要那些只是为了使类能够相互协作，而将对 象粘合的代码。

　　作为spring beans的工作流组件

　　在进一步讨论之前，现在是简要介绍spring中主要概念的恰当时候。接口ApplicationContext是从接口BeanFactory继承的，它被用来作为在spring容器内实际的控制实体和容器。