一种状态驱动的可执行业务流程执行方法

具体实施方式

下面结合附图对本发明作进一步说明。

如图1～3所示，一种状态驱动的可执行业务流程执行方法，包括以下步骤：

A.采用Web服务资源框架平台(WSRF平台，Web Services ResourceFramework平台)管理Web服务状态对应的属性参数，与业务流程状态交互，使得业务流程根据当前的状态信息动态配置流程行为，决策流程走向；

B.根据上述的状态信息，采用UML有限状态机对业务流程进行建模，使其形式化的表述上述的状态信息，并根据状态信息建立业务逻辑和流程逻辑的分离机制。

所述的步骤A包括：

Web服务状态的管理：WSRF(Web Services Resource Framework，Web服务资源框架)规范实现对Web服务的状态管理，它将服务的状态定义为该服务所包含的属性值，若属性值发生改变，那么这个服务的状态也就改变了。它允许Web服务自身与改变状态的数据直接脱离开来，以一个单独的形式来有效的封装资源，通过客户机与Web服务之间交换的消息来维护服务调用的状态，使得我们可以很方便的申明和实现Web服务的一个或者多个有状态资源直接的关联，从而动态的获知流程调用的Web服务的运作；

它通过WS-ResourceProperties(WSRF-RP)指定ResourceProperties在WSDL文件中被定义的形式。它还指定消息的形式，这些消息用于请求和接收属性的值，还解释了如何更改、添加和删除WS-Resource的属性。当服务属性值发生改变时，通过WS-Notification返回一种事件通知的标准方式，当然我们不可能关注Web服务的每一个属性值，而且有些属性值对于流程活动的调用并没有考虑价值，所以在这之前我们必须通过它来订阅流程管理者所关心的Web服务的属性值，当这些属性值即Web服务的状态发生改变时，返回一个基于XML的消息通知流程管理者，这样就便于流程管理人员监控流程运作的情况。

图1为WSRF中Web服务与有状态资源交互的方式。

流程状态信息定义：将每个流程活动单元表示为前置状态、活动以及后置状态，其中前置状态、和后置状态分别代表的是各个活动执行之前和之后的属性值，将这些信息以下表的方式储存到数据库中：

其中活动NO是各个活动的主关键字，执行一次后将执行次数修改为1，当流程根据服务状态的规则调用服务时先查找记录为0的服务，这样就可以提高服务匹配和查找的效率。

状态信息的交互结合：将有限状态机的概念运用于程序中，用于记载有限数量的子状态的发展变化，每个子状态进行一些处理并选择下一状态(通常取决于下一段输入)，用状态转移表来保存当前服务的状态，以及在某一活动驱动下所达到的下一个状态，如下表：

其中，S为状态，A：为活动，\为不可能转移；

在流程规则库中定义Web服务各个属性值之间的限定条件，从而定义了Web服务各个状态之间转移的约束条件。

在明确了流程运作过程中所需调用的各个Web服务以及它们之间的组合方式以及对流程运作过程所涉及的各种状态信息之后，我们对其进行建模。由于当前OMG(Object Management Group)组织所提出的模型驱动架构(Model DrivenArchitecture，MDA)，即将抽象的模型转化为计算机可执行的语言，其中最主要的建模语言就是UML(通用建模语言)，所以我们用UML有限状态机的建模方式，使其转化为BPEL，从而实现可视化的业务流程的管理。

所述的步骤B包括：

状态驱动状态机SEFSM的形式化语义表述：

有限状态机是一种具有离散输入输出系统的数学模型，它以一种“事件驱动”的方式工作，通过事件驱动下系统状态间的转移，来表达一个系统的控制。一个有限状态机由状态的有穷集和状态之间的转换关系组成，其数学定义如下：

定义：FSM是一个6元组，E＝<I，O，S，S0，F，G>在其中：I表示所有输入事件的非空有限集合，在任一确定的时刻有限状态机只能处于一个确定的输入；O表示所有输出动作的非空有限集合；S表示所有状态的非空有限集合，在任一确定的时刻，有限状态机只能处于一个确定的状态；S0表示初始状态，初始状态是必需的；F：表示状态转换函数，在某一状态下给定输入后有限状态机由状态转移函数决定的一个新的状态；G：表示输出函数；

状态转换函数和输出函数共同描述了有限状态机的动态特性。我们在有限状态机的基础上进行了扩展出现了SEFSM，主要是为了包含流程中的流程活动单元状态变量。在这里我们定义的状态驱动状态机(SEFSM)是确定的，即当前状态接受特定事件后，进入的下一状态是确定的。

一个SEFSM可定义为一个7元组EF＝<S，S0，I，O，∑，T，V>其中：

·S＝{S0，S1，S2....Sn}表示一个非空的状态集合；

·S0∈S表示初始状态，在这里可以表述为当前服务的状态；

·I表示非空的输入的集合，可理解为发送的消息或方法的调用；

·O表示非空的输出的集合，可理解为产生的动作；

·∑＝{a1，a2....an}对应业务流程中活动的NO.，是流程中原子活动的集合；

·T：S×∑→S表示非空的状态转换函数，是某一状态下执行一个活动后，业务流程将转入由状态迁移函数决定的一个新的状态；

·V表示变量的集合，这些变量可能是服务的属性参数或前置条件中判定参数；

其中∑又是一个4元组∑＝<Pre_State，Post_State，a，Drivencondition>。在这里a∈I表示触发的活动，Pre_State∈S表示a的前置状态，Post_State∈S表示经过活动后到达的状态即后置状态；Drivencondition表示该活动的触发条件，是一个基于变量V的判定表达式，它也是状态规则库中所定义的状态规则。

UML状态机建模：通过用静态的类图以及动态的状态机图进行UML状态机建模。我们从二个方面来刻画状态驱动的可执行业务流程(SEBPM)这个系统：

用静态的类图来描述事物的数据，包含类，属性，关联和约束。UML类在图上分为三段，以Account类为例，如下表所示：

其中类的属性与流程的状态相对应(在BPEL4WS 1.0术语中的容器，或者BPEL 1.1中的变量)。

用动态的状态机图来描绘事物的生命周期，包含状态，事件状态转移和过程。

UML建模中，状态图一般用来揭示复杂对象的活动和寻求其内在方法，作为一种分析和设计的辅助模型(很多系统分析完全不用状态图)，包括了嵌套状态、历史等复杂表示法，并且消息传递的一些表示也不是形式化的，带有随意性。因此，本系统在原先的状态图基础上建立了SEFSM状态机模型，控制事件接收和相应的状态转移。如图2所示，UML状态机建模包括以下步骤：

a)在状态机所在的类建立一个状态转移表，该表包括活动、当前状态、下一状态；

b)根据状态机内容，将每一个活动对应的状态等信息加入到状态转移表内；

c)在状态机所在类中加入一个当前状态的属性；

d)在状态机所在类中加入一个私有函数GetNextState；

e)为每个状态增加一个私有函数，封装其对应的过程，输入参数是一个事件类，该事件就对应了状态转移表中的活动；

f)为每一个输入事件建立一个公有函数，将事件的参数依次填入此函数的参数表中；

g)在输入事件所在函数中增加如下内容：调用GetNextState函数，取得下一个状态，如果返回一个有效状态，就将当前状态设置为返回状态，并且将输人参数打包成事件类，传入当前状态所对应的过程。

本方面的技术实施路线：

实现上述功能方案，主要包括实现WSRF的AppachMuse平台，MYSQL数据库管理，DOM4J以及UML建模工具以及业务流程管理的WSAD软件。

在Web服务状态更改以及通知，我们运用WSRF平台，返回的基于XML的SOAP消息，我们可以使用DOM4J来检索其中的属性值参数，并把它存储到数据库中。

整个方案运作主要包含以下几个模块：服务状态规则模块，数据存储模块，可调用的服务列表模块，它们之间的相互关系如图3所示。

本发明的创新性体现：

本发明的创新性主要体现在以下几个方面：

(1)首次提出将Web服务的状态和流程运作的状态整合起来，从而实现监控和操控流程的运作。通常处理有状态数据的经典的做法就是在应用程序中让程序自己来处理有态数据。在本质上，应用程序请求方的信息的管理和状态是被提供者隐藏起来的。但当在一个请求者或者提供者要求一个对于资源状态的完全快照时，精确描述的Web services设计的局限提出了新的要求，而WSRF正是为了应对这个方面的问题而提出的。而Web状态资源的获得能够更实时的获得企业流程运作的状态，从而使得企业业务流程管理更加有效。

(2)其次，将Web服务的状态信息作为流程规则的条件，实现流程规则和业务流程的分离。根据当前Web服务的状态信息和目标状态之间的差异来决策业务流程的运作，通过检索状态转移表中的相关信息，从而动态的选择下一个Web服务。

(3)在用UML建模的时候，不仅考虑了流程中活动的前置状态，也包含了Web服务的状态即各个服务的属性值。通过这两种状态的交互，动态选择可选范围内的各种服务组合的一种方式。

为更明确的解释状态驱动的可执行业务流程系统方案，我们假设下面的场景：在一个旅行预订系统中，提供4种Web服务，服务A：预订酒店；服务B：预订机票；服务C：租车服务；服务D：报旅行团服务。我们将旅客的网上消费作为WSRF的状态资源，其中账户余额是我们所关心的状态属性值。我们假设这样的场景：在预订机票以后如果余额m还多于10000不考虑服务D，若m＜10000，则参考了服务A和C的价钱之和与服务D的比较后再做决定。这里因为跟随季节的变化，各个服务的价钱都是未知的，而我们只有根据上一个服务执行后的状态属性值来判断下一个所选择的服务。而且我们也可以根据查看当前的余额信息来获知当前流程运作的情况。

上述的对实例的描述是为便于该技术领域的普通技术人员能理解该方案。熟悉本领域技术的人员显然可以容易地对这个方案做出各种修改，并把在此说明的一般原理应用到其他实例中而不必经过创造性的劳动。因此，本方案不限于这里的实例，本领域技术人员根据本方案的揭示，对于本方案做出的改进和修改都应该在本方案的保护范围之内。