Spring创建一个简单的工作流引擎(图)

核心提示：摘要sPRing是支持控制反转编程机制的一个相对新的框架，本文把spring作为简单工作流引擎，Spring创建一个简单的工作流引擎(图)，将它用在了更加通用的地方，在对工作流简单介绍之后，我们仅仅对状态转换是自动完成的工作流感爱好，状态信息仅仅在实际工作流运行时在ProcessContext中得到，将要介绍在基本工作

　　摘要
　　
　　sPRing是支持控制反转编程机制的一个相对新的框架。本文把spring作为简单工作流引擎，将它用在了更加通用的地方。在对工作流简单介绍之后，将要介绍在基本工作流场景中基于Spring的工作流API的使用。(2,800个英文单词; 2005/4/11)
　　
　　许多J2EE应用程序要求在一个和主机分离的上下文中执行处理过程。在许多情况下，这些后台的进程执行多个任务，一些任务依靠于以前任务的状态。由于这些处理任务之间存在相互依靠的关系，使用一套基于过程的方法调用经常不能满足要求。开发人员能够利用Spring来轻易地将后台进程分离成活动的集合。Spring容器连接这些活动，并将它们组织成简单的工作流。
　　
　　在本文中，简单工作流被定义成不需要用户干预，以一定顺序执行的任意活动的集合。然而，我们并不建议将这种方式代替存在的工作流框架。在一些场景中，需要更多的用户交互，例如基于用户输入而进行的转向，连接或传输，这时，比较好的方法是配用一个单独的开源或者商业的工作流引擎。一个开源项目已经成功地将更复杂的工作流设计集成到spring中（参加OSWorkflow）。
　　
　　假如你手上的工作流任务是简单的，那么，与功能完备的独立工作流框架相比，简单工作流的策略就会变得有意义，非凡地，假如已经使用了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容器内实际的控制实体和容器。
　　
　　ApplicationContext负责对一组作为spring beans的一组bean的初始化，配置和生命期治理。我们通过装配在一个基于xml的配置文件中的spring beans来配置ApplicationContext。这个配置文件说明了spring beans互相协作的本质特点。这样，用spring的术语来说，与其他spring beans交互的spring beans就被叫着协作者（collaborators）。缺省情况下，spring beans是作为单例存在于ApplicationContext中的，但是，单例的属性能够被设置为false，从而有效地改变他们在spring中调用原型模式时的行为。
　　
　　回到我们的例子，在飞机票价下降的时候，一个SMTP发送例程的抽象就被装配在工作流过程例子中的最后的活动（例子代码可以在 Resources中得到）。由于是第5个活动，我们命名它为activity5。要发送消息，activity5就要求一个代理协作者和一个错位处理句柄。
　　
　　<bean id="activity5"　　　 class="org.iocworkflow.test.sequence.ratedrop.SendMessage">　　　<property name="delegate">　　　　 <ref bean="smtpSenderDelegate"></ref>　　　</property>　　　<property name="errorHandler">　　　　 <ref bean="mailErrorHandler"/>　　　</property>　 </bean>
　　
　　将工作流组件实施成spring beans产生了两个令人喜悦的结果，就是轻易进行单元测试和很大程度上可重用能力。IoC容器的特点明显地提供了有效的单元测试。使用像spring这样的Ioc容器，在测试期间，协作者之间的依靠能够轻易的用假的替代者替代。在这个航线的例子中，能够轻易地从唯一的测试ApplicationContext中检索出像activity5活动这样的spring bean。用一个假的SMTP代理SMTP服务器，就有可能单独地测试activity5。
　　
　　第二个意外的结果，可重用能力是通过像XSL转换这样的工作流活动实现的。一个被抽象成工作流活动的XSL转换现在能够被任何处理XSL转换的工作流所重用。
　　
　　装配工作流
　　
　　在提供的API中（从Resources下载），spring控制了一些操作者以一种工作流的方式交互。要害接口如下：
　　
　　Activity: 封装了工作流中一个单步业务逻辑
　　ProcessContext:在工作流活动之间传递具有ProcessContext类型的对象。实现了这个接口的对象负责维护对象在工作流转换中从一个活动转换到另一个活动的状态。
　　ErrorHandler: 提供错误处理的回调方法。
　　Processor: 描述一个作为主工作流线程的执行者的bean。
　　
　　下面从例子源码中摘录的代码是将航线例子装配为简单工作流过程的spring bean的配置。
　　
　　<!-- Airline rate drop as a simple sequence workflow process -->　 <bean id="rateDropProcessor" class="org.iocworkflow.SequenceProcessor" >　　　<property name="activities">　　　　 <list>　　　　　　<ref bean="activity1"/><!--Build recipients-->　　　　　　<ref bean="activity2"/><!--ConstrUCt DOM tree-->　　　　　　<ref bean="activity3"/><!--Apply XSL Transform-->　　　　　　<ref bean="activity4"/><!--Write Audit Data-->　　　　　　<ref bean="activity5"/><!--Attempt to send message-->　　　　 </list>　　　</property>　　　<property name="defaultErrorHandler">　　　　 <ref bean="defaultErrorHandler"></ref>　　　/property>　　　<property name="processContextClass">　　　　 <value>org.iocworkflow.test.sequence.ratedrop.RateDropContext</value>　　　</property>　 </bean>
　　
　　SequenceProcessor类是一个对顺序模式建模的具体子类。有5个活动被连接到工作流处理器，工作流处理器将顺序执行这5个活动。
　　
　　与大多数过程式后台进程相比，工作流的解决方案真正的突出了高度强壮的错误处理。错误处理句柄可以单独地处理每个活动。这种类型的句柄在单一活动级别提供了细致的错误处理。假如没有单独处理单个活动的错误处理句柄，那么全局工作流处理器的错误处理句柄将会处理出现的问题。例如，假如在工作流处理过程中的任意时刻，一个没有被处理的错误出现了，那么它将会向外传播，被使用defaultErrorHandler属性装配的ErrorHandler Bean处理。
　　
　　更复杂的工作流框架将工作流转换之间的状态持久化存储到数据库中。在这篇文章中，我们仅仅对状态转换是自动完成的工作流感爱好。状态信息仅仅在实际工作流运行时在ProcessContext中得到。在ProcessContext中，你仅仅能看到ProcessContext的接口的两个方法：
　　
　　public interface ProcessContext extends Serializable {　　　public boolean stopProcess();　　　　　public void setSeedData(Object seedObject);　 }
　　
　　用于航线例子工作流的具体的Proce