工作流建模：失败和异常处理表示

摘要
对各种活动，包括工作流过程，过程的执行顺序和关系，与过程的执行有关的代理，以及在执行期间使用的资源的表示，称为工作流建模。多种技术正被用于工作流建模。其中之一是使用临时的面向对象数据模型TF-ORM来表示工作流模型[20].失败和异常在工作流执行期间可能会引起严重的问题，特别是关键任务的应用程序。本论文将展示TF-ORM在被用于工作流建模的时候，是怎样允许多异常的表示和用于系统恢复的信息的定义。

1简介
工作流，也叫做事务过程，关注在一种事务环境中活动的协调[26].工作流的模型由一个企业里为了达成一个具体的目标的工作而按照合乎逻辑的顺序执行的表示组成。组成工作流的每个过程可能由几项活动，以及具体的命令执行顺序，不同的执行代理，不同的位置等组成。所有这些信息的表示被称为工作流建模。这个模型有助于理解整个过程，并且允许确定可能的问题[29].工作流建模概念不仅作为一个例子正在商业企业里使用，工作流建模技术也能在教育领域使用，实现在Web上的一门课程[22].
在某些特殊应用中，像与地区健康、保险公司、银行业和电子商务有关的应用等，对工作流的理解和实现是非常重要的，这些应用提出关键的、不可失败的特性：与安全或者可能带来生命危险的特性。这些特性需要特别注意，以便确保(或者，至少提高)他们的安全。对工作流的分析能确定可能的异常和失败，并且相应的建模将提高整个系统的安全。
在新近的研究过程中，有几种工作流建模技术被提出，它们使用不同的建模范例，工作流技术联盟推荐[30]，Casati，Ceri，Pernici&Pozzi的模型[4]，Joosten的开关模型[17]，WAMO活动模型[9]，面向对象的模型[19]以及Petri网[1，12].
工作流管理系统，也被称为工作流引擎，它控制全部活动的执行。管理工作流的重要性被这个领域新近的研究所确定，并引出工作流引擎的一套学术经验[2，14，16，27，28]，以及许多商业工具(如：ProcessBuilderdaActionTechnologies，LotusNotes)。
作为一种计算系统，由于异常事件或者系统故障，一台工作流引擎在执行期间可以会出问题。经验显示“异常不是例外，它一直在发生”。在这个问题上新近的研究显示出，当考虑到工作流的时候，这个问题非常重要[10，11，13，15，23，24，25，26].如果把一些可预测的异常表示为工作流模型，就可以通过编写工作流引擎来解决问题。
既然这个问题的解决办法很重要，那么工作流引擎需要特别的信息来提供失败恢复。当选择建模工具时，描述恢复信息的工作流模型的可能性也是一个非常需要的特征。
工作流建模的一种可选择的技术在[20]里被提出，使用临时的面向对象模型TF-ORM[5，6].工作流过程的行为被定义为类，这每个过程执行的时候实例化。一种有限状态机，提出临时的逻辑表达式以确定过程的变化，并用于状态的强制转换。与传统的面向对象模型比较，这种方法的主要差别是使用角色表示与过程组合的活动，并且也给予这些角色有条件的状态转换。在过程和活动之间可能的关系也可以被清楚地描述。
这篇文章的目标是显示TF-ORM形式允许在模型级别确定可能的异常的表示，以及工作流引擎将执行的行动。也显示TF-ORM模型以提出描述信息的方式可以被失败利用的恢复机制。
文章结构如下：第2部分给在工作流系统里的异常和失败一个简短的介绍。那些提出的形式在第3部分会被简要提出，随后有使用TF-ORM表示的异常(第4部分)和失败(第5部分)。

1．异常和失败
两类不同的问题会在工作流执行期间发生：异常和失败。并且他们中的每一个的系统恢复都需要不同种类的信息。
异常是可能由系统故障或者由外部环境引入的一种新形势所引起的语义的失败[11].可能的一种异常：对一项活动负责的代理变更，以及对一个过程的结构的任意修改[26].通常可以通过确定行为来让工作流引擎处理异常。不过，鉴别出能在工作流执行期间发生的全部异常是不可能的。
失败由因为设备、通讯设施或者程序里的错误引起的系统故障组成。因为这些失败是不可预见的，所以无法对它们的处理建模。当这样的问题在一项活动的执行期间发生时，一个解决办法将被赋予对这项活动负责，或者对整个过程负责的代理。为了提供系统恢复，需要关于实际活动的和过去形势的信息(日志)。
工作流系统的主要特性之一是工作流的执行所花费的时间，从第一个活动开始直到最后一个结束计算。这时间间隔可能相当大。当整个工作流的一项活动失败时，整个工作流不会被中止，系统恢复将被提供，来保护已经做了的工作。
几种可能的工作流异常可以在分析阶段确定，另外，为了系统恢复而执行的活动可以在工作流建模阶段表示。不过，确定全部可能异常的表示，会产生一个非常复杂的工作流模型。一方面在建模的现实和模型简单之间总有妥协，我们希望描述更忠于现实(在这种情况里指工作流)，并且另一方面，较少复杂模型也更容易理解并实现。大量异常的表示，包括恢复动作，将产生一个复杂而且难以理解的模型。有时，最好只描述重要异常(这些只在工作流执行期间起重大影响的)，并为其他提供失败恢复机制的信息。
能在工作流执行期间发生的典型异常有：
 由于一些个人或者专业问题，对一项活动负责的代理不能执行他的角色，并且没有预见完全适合他的代替者；
 由于在过程期间确定的一些重要特征，对整个过程负责的代理决定改变工作流；
 一项活动被堵塞，等待不可提供的资源；
 在工作流执行期间的循环事件；
 死锁事件——两个活动等待事件被另一个引起。死锁可能在两项活动之间直接或者间接引起，(后者更难确定)；
 当一条被发送到另一个活动的消息的接收方没有确认时，消息可能在发送活动不知道的情况下丢失。

1.1.异常和建模错误
由于工作流表示方法的缺乏，在工作流执行期间发生的异常和错误之间需要做一个重要的区分。为了例证这个差别，可以考虑下列例子，在[18]里发表的基于“TraveluckExample”。它是与一家旅行社有关的，当旅行社的客户想要做一次旅行，其中包括飞机票，饭店预定和租车公司，活动就会被执行。该应用的主要活动如图1所示，图1使用的是一个活动图表达法，这种方法经常被用来以图示的方法描述工作流–圆圈代表活动，那些箭头确定活动执行的顺序。工作流从旅行定义活动开始，此时客户，以及旅行代理将选择旅行路线。当旅行路线被固定后，三项不同的平行活动，将被激活：航班，饭店和车票预订。
两个可选择并且相互独立的结果能输出这三项活动：预定可能被确认或者拒绝。如果那三个预定有一个没有被确认，旅行社就会和客户联系(OR操作符表示条件联合)。并且只有全部三项预定都被确认的时候，(AND操作符)下一项活动才会被激活，并且会打印旅行时间表，随后以票和代金券的方式支付，从而结束工作流。
这个例子中，工作流提出一个建模错误：当预定活动之一没被确认时，另一个可能已被确认，并且不可消除。一旦客户决定采取什么措施来克服被发现的预定问题，工作流将重新开始，并且已经被确认的预定将被重复。工作流需要证实在这样的情况下是否做了任何其他预定。
如果客户不支付，工作流将无限期等待支付的进行，在这个例子里，证实是可能发生这样的异常的。工作流模型能提供一些处理来避免这个异常。

2．使用TF-ORM的工作流建模
在这篇文章里使用的工作流建模方法是TF-ORM工作流建模(角色对象临时功能方法)[5，6]，它是一个临时的面向对象的数据模型[20].TF-ORM已被证明是工作流建模的一种有效工具，原因如下：
 它是一个正式的模型，允许对工作流的完整表示；
 允许用相同的正式模型来表示结构化和非结构化的信息(比如决定)的表示；
 可以表示在活动中的全部可能的同步性；
 可以表示在过程和活动中之间的通讯；
 基于角色概念，允许一个代理扮演不同角色的表示。
使用这个模型，工作流可以描述确定过程，代理和资源，提出他们自身每一个静态和动态的特性。这些对象方法由能够被每一个类发送和接受的消息来表示。另外，每个对象能够表示的状态也被定义了，并且状态转换规则描述了对象的演化。这些规则可能被用时序逻辑写的条件所限制，这是这种建模工具的一个重要特征。
这种模型和其他面向对象模型之间一个重要的差别是，TF-ORM类能根据角色建模，来表示不同的行为。角色概念与面向对象的范例[8]有关，可以表示对象随着时间的演变：一个对象能同时表示不止一个行为，每一个独立逐步形成，并且也能提出相同行为的多个实例，他们也都独立逐步形成。
使用TF-ORM建立工作流模型，通过过程类来描述过程。过程的每项活动被描述为相应过程类的角色。对活动和过程负责的代理被描述为代理类，其中角色代表每个代理在过程和活动执行期间所扮演的不同角色。执行期间涉及的资源被描述为资源类。代理和资源之间的整个由活动表示完成。
对象行为由在每个角色中定义的状态转换规则来描述，每个角色都有一套这个角色中的对象可能的状态，以及定义在这些状态之间可能的演化的一套状态转换规则。
工作流中不同活动(过程类的角色)的同步性也可以用TF-ORM通过角色的状态转换规则来表示。活动由其他活动传送来的消息激活。激活不仅意味着活动执行的开始，还表示一项暂停的，等一个事件继续执行，的活动的继续。同步性通过状态转换规则表示，以下是基本的结构：
st(si)，msg(m1)msg(m2)，st(sf);
<转换条件>
从初态s1到活动的最终状态sf的转换a1，只有当活动a1处于状态s1，收到消息m1并且转换条件得到满足(True)的时候，消息m2才会被传送到相同的活动，另一项活动的相同过程，或者另一个过程的活动。最后一种形式可以表示不同过程之间的交互，这在工作流中会经常出现，但是那些传统工作流建模工具总是不能胜任。
可选的描述状态转换规则的方式如下：
(1)当初态没被定义时，可以提出适用于活动任何状态的转换；
(2)当几个消息可以得到时，只有消息全部到达的时候转换才能够被执行；
(3)几条消息可以同时被发送；
(4)当最后的状态没有被定义时，转换只定义不会改变活动状态的输入和输出信息；
(5)转换条件是可选的——当没有被定义的时候，转换的执行情况只基于初始状态和输入的消息。
以上的部分例子请见附录，是用TF-ORM建模的。

2.1.活动之间的同步性
组成工作流的过程的活动能体现出多个不同的同步性特征，通过状态转换规则表示为TF-ORM模型。活动能串行或者并行，独立或者以协调方式执行。
当之前的已经完成时，第二项活动才能开始执行，那么这两项活动是串行的。图2表示一个活动a1，由于得到消息m1，从状态s1到sf的转换。这个转换引起另一项活动a2，发送一个消息创建这个活动的一个新的实例，(以消息add_role描述)。转换条件没有描述。如果sf是第一个活动的最终状态，那么描述的两项活动是串行的
在相同的例子里，如果sf不是a1的最终状态，这项活动继续执行，那些第一个活动只激活第二个，然后从那里活动被并行激活。
类似的情况是一项活动被临时中止，等待一条特定的消息恢复执行的时候，表现出同步执行的特性。在图2的例子中，第二个活动将处于等待状态，a1的输出信息不会add_role，可是消息表示第二个活动等待的事件。
一项活动的执行能以一套得到的不同活动发送的输入信息为条件。这种情况通常被叫为聚合，因为描述的是输入信息的交集。在TF-ORM里这被一个独特的状态转换规则和一套输入信息(在附录里的例子)描述。两种不同的形势可以由一套可能的输入消息发生：(1)全部消息必须以某种顺序到达来执行转换(全交集)或者(2)这些消息的任何一个子集需要到达(部分交集)。第二种形式在TF-ORM表示为定义在各种输入消息之前到达的消息的数量。
相反情况下，一个活动激活几项其他活动的执行，被称为叉子（fork）。这被描述为发送多条消息的一个状态转换规则(见附录例子)。
所有这些状况可能被转换条件限制，在其中可以确定属性和状态当前和过去的值，从而确定是否要执行某种转换。

3.在TF-ORM中表示异常
当使用TF-ORM形式时，异常可能被表示为工作流模型，带有相应的被执行的行动。在下面的章节里要确定一些可能发生的异常，并解释它们在TF-ORM中的表示。

3.1.负责一项活动的代理的声明
每项工作流活动都有一位负责的代理，以便控制执行并且解决可能出现的问题。当TF-ORM模型被用于工作流建模时，每项活动都要求定义一个负责的代理。在模型里，只确定代理的角色。具体的人在活动的实例被建立的时候确定。
当代理提出一次声明时，将发生一个异常，并且相应活动的责任将被转移到另一个。为了防止这种异常，TF-ORM模型允许一组活动可能被授予的代理的表示。当活动被实例化的时候，这些代理也就被确定。
即使有活动的责任可能被授予的一些代理，如果整个目录被声明，异常仍然会发生。为了防止上面的情况，TF-ORM模型需要一个对整个过程负责的代理的定义，并且这个将声明谁是对该项活动负责的新代理。

3.2.在执行期间改变活动流
当活动的顺序在工作流执行期间被改变时，就会发生严重的问题。为了避免这些问题，TF-ORM需要定义对每个过程负责的代理。只有这个代理会有改变执行活动的顺序的能力。
为了实现这个干涉，每项活动提出两条预定义的输入消息，以便被对活动被定义的过程负责的代理发送。这些消息可以在任何时候收到，与活动的现状无关。对过程负责的代理将把这些消息发送给全部与他计划变化有关的所有活动。第一个消息会改变活动的初始状态，编程代理定义的状态，并作为参数传送。第二个消息与属性值有关——如果有需要适合一些属性值，具体的消息也将被发送，其中带有名字和这些属性的新值。
作为例子，考虑在第二部分提出关于旅行社的例子。假定负责的代理想要中止一项正在执行的酒店预定活动，如果已经做了任何预定，就撤销。这将向这项活动发送送下列消息：
msg(agent_interfer(hotel_reserve，suspended))
msg(values_interfer(hotel_name，null))，
msg(values_interfer(hotel_reservation，nok))
这些消息的影响就像一个规则为酒店预定角色的每一个状态定义一样，像如下内容(预定状态)：
ri:state(reserving)，
msg(agent_interfer(hotel_reserve，suspended))，
msg(values_interfer(hotel_name，null))，
msg(values_interfer(hotel_reservation，nok))
state(suspended)
记得执行的代理对在活动执行方面的顺序变化负责是重要的，并且使所有相关的过程和活动与新的执行顺序适应是他的任务。修改可能反应在前一个执行活动中变化的属性值。

3.3.活动等待不可得到的资源
一个异常可能由一个活动暂停等待一种资源的时候引起，并且这种资源是不可提供的。一种资源的可用性在TF-ORM中被表示为由相应资源类发送给活动送的一条消息。
一种避免这个问题的方法是，对过程和资源类之间的相互作用建模，要求一个被请求的资源确定或者否定的回应。活动的转变规则将考虑两个回应，并且提供一个可选择的解决办法，以防资源不可提供。如果没有其它的解决办法，活动将把一条预先定义的消息送到对活动负责的代理(由发送到相同角色的消息表示)，请求一次中断。这条消息有下列形式：
msg(resource_interfer)toitself

3.4.循环
循环事件是工作流执行期间可能发生的最重要的问题之一。循环表示当一个活动a1激活另一活动a2的时候，活动a2，直接或者间接，又激活活动a1。考虑到全部可能的发展，这种情况只能通过对工作流的严格的分析才能避免。
但是，在减少循环事件可能性方面，TF-ORM模型提出预定义的属性，在所有类的基础角色里定义(将在所有类中定义和那个类的全部对象的全局属性定义的一个角色)。这属性，叫做cycle_alert，有控制循环，以及检测可能的循环事件并提醒相应的代理的功能。这属性的域是一套角色的名字和角色活动的实例的数量相对应的组合。对过程负责的代理将控制这属性，以这种方法发现可能的循环。

3.5.死锁
由于创建限制转化规则的时序逻辑条件的可能性，防止死锁的规则尤其难以表示。所能被做的是把一段时间和一个可能死锁的状态联系起来。在这段时间过去之后，另一个规则将被执行，来销毁死锁。
为了避免死锁异常，TF-ORM模型扩展了一种时间类的定义。该类在所有结构模型中预定义，用来计算所耗费的时间。用最大的等待时间作为参数来创建一个该类的实例。时间类的行为如下：一旦创建了一个实例，这个实例就会计算所耗费的时间，当时间参数符合了，就向上一个类发送中断消息（Interrupt）。
以下是死锁的完全处理过程。当死锁在活动_1的状态_1发生的可能性被确定，每当达到这个状态时，一条消息就会被传送给时间类，随着最大的时间这项活动将等待另一次事件(表示为一种新状态转换)。这个消息形式如下：
msg(timing(<class.role>，<state>，
<waitingtime>，<temporalgranularity>))
时间类开始计算耗费的时间。当达到等待时间时，一条中断消息被传送给发送类/角色(描述活动)。如果这个角色仍然处于相同的状态，一个死锁就真的发生了，并且一个向恢复状态转换的状态被提供。另一方面，对于处于另一状态的角色，不会得到中断消息，也不会影响活动。一个可能的死锁的例子在状态dl_state有一系列转换规则：
st(x)，msg(m_in)msg(m_out)，
msg(timing(C.R，dl_state，5，min))，
st(dl_state);
st(dl_state)，msg(waited_msg)st(y);
st(dl_state)，msg(interrompt)
st(recovery_state);

3.6.等待消息收到确认
向另一项活动发送的一条消息不能保证消息被收到。当收到消息是必须的时候，这将导致整个工作流里的问题。当使用TF-ORM表示工作流时，消息被发送，没有真正收到确认，一旦一个转换条件只有在特定状态下收到消息才能够执行，而且还需要满足转换条件。如果某个(状态或者转换条件)没有满足，消息就收不到。
为了保证消息被收到，TF-ORM模型将描述如下内容：
 发送消息的角色将逐步形成一个等待状态，并且保持这个状态一段确定的时间(使用时间类)，直到收到确认消息；
 如果消息正确收到，接受端向发送端发送一个确认消息然后继续它自省的变化；
 如果消息没有收到，最大等待时间耗尽，角色从等待状态进化到可以解决问题的状态，或许代替第一个发送另一条消息。

4．用于失败恢复的信息
两个方面将在失败恢复过程中清楚地确定：
 谁(哪个代理)负责恢复，作克服失败的必要决定；
 在这个过程里需要哪种信息。
一位代理必须做无法预料的系统故障的恢复工作，以便使恢复自动化。为了保证当失败发生的时候有代理可供使用，TF-ORM模型要求定义对整个工作流负责的代理。每个确定过程都必须有一个负责的代理，像每项活动一样。如果发生失败事件，首先，负责的活动试图恢复执行，如果在活动域内不成功，负责的过程就会接管。
一次失败恢复将在解决引起失败的问题之后，从之前的一个执行点重新开始所执行的活动。这个过程被称为回滚。为了使之成为可能，附加信息是必要的。已经证明一种有效率的回滚的形式，这将储存由活动和过程组成的过去状态，带着临时的相关信息(这些状态中的每一个疑似的时间)。这已经是TFORM模型的一个特征——临时的模型，临时的信息(交易和有效时间)与所有信息(状态和属性值)有关，并且全部过去信息应该被放在工作流模型的临时数据库中。这使对恢复负责的代理能够分析储存的信息，选择过去临时的瞬间，删除该瞬间(考虑到每个存储值的事务处理时间)之后的信息，以这种方法恢复过程或活动的一种过去状态。
一种可选的实现系统恢复的方法是在每个类中定义一个属性，来储存那个类的每个实例的活动历史，此外与相关事务处理时间联系。分析这些实例的变化，负责的代理将选择怎样恢复。

5.结论
工作流建模是在企业分析过程里的一个非常重要的主题。在这个领域最近出版的有表现力研究的数量证明了这个事实。以下三个不同的维度在工作流里确定[18]:
(1)什么将被描述——各种组成工作流和他们的执行顺序的活动；
(2)谁将执行每个活动，也就是每一个工作流的代理；
(3)什么活动将同时执行——执行涉及的资源，包括自动的工具和支持。
与这三者有关的信息将被在工作流模型里定义。但是，大多数可得到的建模工具只允许表示与第一个有关的信息。这就是企业建模和工作流建模之间的主要差别。
一个工作流模型要包括(1)组成工作流的全部过程的描述，并且活动在每个过程中表现，(2)对每个被确认的活动中的执行负责的代理的定义，(3)对活动执行的临时限制的定义；以及(4)在活动和过程之间联系的确定(为了信息改变和控制)。
为了达到这个目标，可以使用下列策略：
 建立一个工作流的数学模型；
 格式化过程和之间的关系，使用时态逻辑，以便产生出全部可能的工作流的逻辑计算树(在这棵树中，一个节点的孩子可能认为是从表示为相应根的状态开始的可能的状态)；
 使用一些方法验证这个模型，通常通过一次工作流的模拟执行。
工作流建模可以被认为是企业重组过程的第一个阶段。对完全理解一个应用程序来说，对可能在执行期间发生异常的分析，以及最后的系统故障结果，是非常重要的。异常(学术上也叫做失败)当活动不能以按照工作流模型执行的时候，或者没得到期望的结果的时候发生。失败包括设备的问题(程序的错误，设备的故障，以及通讯错误)。
工作流建模可以使用不同的形式。为了表示活动中的执行同步性，建议使用一个临时的模型。在本文中，时态的面向对象数据模型TF-ORM被用来作为工作流建模工具使用。本文的焦点在于描述使用这种方法表示异常处理和失败恢复的信息的可能性上。还简要分析了由相应代理负责的恢复的实现。
一种完全基于TF-ORM的环境还在发展中，包括建模工具，对商业数据库的TF-ORM模型的映射[21]，以及使用TF-ORM查询语言[7]在一个直观接口[3]上实现对数据库的查询。