ECA & 异常


面向服务软件异常处理研究综述

管华 应时 贾向阳 蒋曹清 王一兵
计算机科学 2013
 
摘要 
随着面向服务软件逐渐成为软件工程领域的研究热点,面向服务软件异常处理的研究日益受到关注,其重要性越来越突出。首先给出了面向服务软件异常的相关概念,阐述了当前面向服务软件异常的几种典型分类,介绍了几个面向服务软件的异常处理中使用的方法,并指出它们的局限性。通过分析和总结当前面向服务软件异常处理的研究方向和研究现状,提出了要解决的关键问题,探讨了当前面向服务软件异常处理研究的不足之处,并预测了下一步面向服务软件异常处理的主要研究方向。

关键词 面向服务软件,异常处理,综述

1 引言

  • TSE (IEEE T Software Engineering) 2010 异常处理专刊

  • 异常处理 -> 软件容错

  • BPEL

    • ThrowFaultHandler
  • 本文第2节给出了面向服务软件的异常处理的相关概念

  • 第3节结合面向服务软件及Web服务环境的特点对异常进行分类

  • 第4节对当前面向服务软件的异常处理中使用的
    方法学进行分类,并指出它们的局限性

  • 第5节针对面向服务软件的异常处理的研究方向和研究现状进行分析

  • 最后展望未来的工作,分析了当前面向服务软件的异常处理下一步研究的主要方向

2 面向服务软件异常处理的几个基本概念

  • 缺陷
  • 故障
  • 错误
  • 失效
  • 容错

3 面向服务软件中的异常分类

  • SOA异常分类为:服务发布异常、服务发现异常、服务组合异常、服务绑定异常和服务执行异常[7]

4 面向服务软件中的异常处理方法分类

  • 主流的异常处理方法划分为
    • 基于注释的异常处理
    • 基于运行时异常处理
    • 事务型异常处理
    • ECA(Event-Condition-Action)规则
    • AI式异常处理:案例推理
    • 其它异常处理法

4.1 基于注释的异常处理方法(静态方法)

4.2 基于运行时异常处理方法(动态方法)

  • 工业级在线监控框架 -> 状态机[19]

4.3 面向事务型异常处理方法

4.4 基于规则的异常处理方法

  • ECA

4.7 面向服务的异常处理方法小结

5 面向服务软件异常处理的主要研究方向和研究现状分析

5.2 面向服务软件异常处理的形式化建模与验证

5.4 WS-Diamond研究项目及基于服务的过程的自愈方法

Ref

  • [19] Runtime Monitoring of Web Service Conversations

基于规则的语义流程异常处理机制

赵楷 应时 张琳琳 胡罗凯 贾向阳 王权于

 
摘要
在语义编程语言SPL 的基础上, 提出一种基于语义Web 服务的语义流程异常处理机制。首先, 重点讨论了业务流程运行时调用语义Web 服务失败和流程内部逻辑失败的情况, 并给出相应的语义流程异常本体。在此基础上, 提出了5 种异常处理动作, 制定了异常处理ECA 规则。然后给出了相应的原型系统。最后结合案例讨论了该机制的有效性和可行性。

关键词 SPL 语言, 异常处理, 语义Web 服务, 业务流程

1 引言

  • Web 服务容错机制 -> 缺乏灵活性 -> 异常
  • 语义编程语言SPL [6] (Semantic Programming Language)
  • new work: 异常处理机制
    • 面向语义流程的异常本体
      • 建模基于语义Web 服务的语义流程在运行时可能出现的异常信息
    • 异常处理的ECA 规则
      • 描述建立在一组具有明确语义的异常处理动作之上的异常处理逻辑
    • 基于规则的异常处理框架
      • 为语义流程执行时及时发现、定位和处理异常提供了支持

the outline

  • 第2 节阐述了相关研究工作
  • 第3 节概述了SPL 语言及其异常处理机制
  • 第4 节定义了语义流程执行过程中可能发生的异常, 构造了面向语义流程的异常本体和异常处理ECA 规则, 提出了基于规则的语义流程异常处理框架
  • 第5节给出了框架的原型实现
  • 第6 节给出了案例应用
  • 第7 节对机制进行了讨论和说明。最后是结论和下一步工作。

2 相关工作

  • E-flow系统 [9]: 异常处理(HP 公司)
    • 服务流程的组合描述语言、异常处理机制、ACID 事务支持以及安全管理, 支持动态服务发现和动态对话选择
  • BPEL故障处理机制 [12]

3 语义编程语言SPL

3.1 概述

  • SPL: BPEL + 语义服务、语义类型、语义变量、语义规则和语义流程等

3.2 SPL 语言中的异常处理

  • SPL: 类似于BPEL Fault Handler
    • try-catch

4 基于规则的语义流程异常处理机制

基于规则的语义流程异常处理机制如图2 所示

  • 第1 阶段为异常处理规则的设计阶段
  • 第2 阶段为异常处理阶段

4.1 面向语义流程的异常本体

4.2 面向语义流程的异常处理规则

ECA规则的语法格式如图4 所示

5 原型实现

语义业务流程异常处理框架结构如图5 所示


一种基于petri网与ECA规则转换的工作流演进模型研究

王飏, 姚淑珍
北京航空航天大学计算机学院
2005

摘要
SWF-net 是一类带约束条件的petri网,文章提出一种扩展的ECA规则(FECA)将多个SWF-net转换为FECA 模型. 采用这一技术,实现了工作流执行中的动态路由和模式反馈,能很好的解决工作流适应性和过程模型持续改进的问题. 文章详细阐述了工作流模型的演进过程,并给出了实际例子

关键词: petri 网; 工作流模型; ECA; 演进

引言

  • SWF-net

  • ECA(Event-Condition-Action): 根据事件和条件激发相应的动作

    • 主动数据库系统[10]
    • 表达能力强,配置灵活等特点
    • 但缺乏petri 网模型的形式化和分析能力
  • author's idea: 提出带频度的ECA规则FECA

1 P/T网WF-net与SWF-net

定义 1.1 (P/T网)
P/T(Place/Transition)网可表示为一三元组\((P,T,F)\),其中

  • \(P\)是place 的有限集
  • \(T\)是transition 的有限集
  • \(F \subseteq (P \times T) \cup (T \times P)\)是有向弧的集合

定义 1.2 (WF-net WorkFlow net)
令$ N=(P,T,F)\(是一P/T网且\)\bar{t}\(是引入的外部变迁,即\)\bar{t} \notin (P \cup T)\((\)\bar{t}\(不是\)T\(中元素),则\)N$是一个WF-net, 当且仅当

  • $ \exists i \in P\(,使得\) \cdot i = \emptyset$ ,即\(N\)中存在一个起始库所\(i\),该库所没有前驱节点
  • \(\exists o \in P\),使得\(o \cdot = \emptyset\),即\(N\)中存在一个终止库所\(o\),该库所没有后继节点
  • \(\bar{N} =(P,T \cup \{ \bar{t} \},F \cup \{(o, \bar{t} ),(\bar{t} ,i)\})\) 是强连通

定义 1.3 SWF-net (Structured WF-net)
一WF-net \(N=(P,T,F)\)是一个结构化工作流网SWF-net当且仅当

  • \(\forall p \in P, \forall t \in T\),且\((p,t) \in F\);若\(|p \cdot| > 1\),则\(|\cdot t| =1\)

  • \(\forall p \in P, \forall t \in T\),且\((p,t) \in F\);若\(| \cdot t| > 1\),则\(|p \cdot | =1\)

  • 没有不明确的\(p, p \in P\)

  • : 一个\(p(p\in P)\)称为不明确的库所,如果从WF-net中删除该库所和对应的输入输出弧将不影响WF-net 的行为

2 SWF-net 与工作流挖掘

2.1 工作流挖掘简介

  • 工作流挖掘: 从工作流执行日志中发现过程模型一类算法[5-8]

2.2 SWF-net 和\(\alpha\)算法

  • \(\alpha\)算法[8]
    • Workflow Mining: Discovering Process Models from Event Logs

3 ECA 规则及其扩展形式FECA 规则

author's idea: 用petri网对工作流建模,然后转换为ECA规则

定义 3.1 ECA规则(ECA rules)
一ECA规则R可用一个3元组表示\((E,C,A)\),其中

  • \(E\)(Event): 是引发活动的事件的有限集
  • \(C\)(conditin): 是活动发生前提条件的有限集
  • \(A\)(Action): 是活动的有限集

一条ECA规则形式化描述为
On Event(e) IF Condition(c) Then Action(a)

定义 3.2 带发生频度的ECA 规则FECA rules(Frequent ECA rules)
一条带发生频度的 ECA 规则FR 可以用一个4 元组表示\((E,C,A,F)\),其中

  • \(E\)(Event):引发活动的事件的有限集
  • \(C\)(conditin):活动发生前提条件的有限集
  • \(A\)(Action): 活动的有限集
  • \(F\): 代表规则的出现频度这里用一整数\(N(N>0)\)表示,\(N\)代表规则在工作流模型中出现次数

一FECA 规则的形式化描述:
On Event(e) IF Condition(c) Then Action(a) WITH Frequency (N)

4 WF-net 转换为ECA 规则

WF-net控制结构分为顺序结构,与连接结构,或连
接结构,与分裂结构,或分裂结构,循环结构6类基本类型,如图1-6 所示

  • ECA 规则生成分为事件Event,条件Condition,动作Action三部分,它们分别由petri网中位置\(S\),变迁\(T\),流关系\(F\)描述
  • 生成描述如下
    • 动作A: petri网中变迁\(T\)即为ECA规则中动作\(A\)
    • 事件E: 来自于petri网中前面发生一或多个变迁
    • 条件C: 来自于petri网中位置S,S在petri网中主要用于描述变迁T运行条件

这里作者写得有点乱

  1. 顺序结构
    以图1为例可生成ECA规则ON Event(t1) IF Condition(c2) THEN Action(t2)
  2. 与连接结构
    以图2为例可生成ECA规则``ON Event(t1 and t2)
    IF Condition(c1 and c2) THEN Action(t3)`
  3. 与分裂结构
    以图3为例可生成ECA规则
ON Event(t1)
IF Condition c2 THEN Action(t2)
IF Condition c3 THEN Action t3
  1. 或连接结构
    以图4为例可生成ECA规则ON Event(t1 or t2) IF Condition(c3) THEN Action(t3)
  2. 或分裂结构
    以图5为例可生成ECA规则ON Event(t1) IF Condition(c3) THEN Action(t2 or t3)
  3. 循环结构
    以图6为例可生成ECA规则
On Event(t1 or t3) IF Condition(c1) THEN {
    Action(t2)
    IF Condition(c2) THEN Action(t3 or t4)
}

5 多个SWF-net 转换为FECA 规则

6 基于SWF-net与FECA转换的工作流模型演进过程

6.1 支持模型演进的工作流管理系统

7 实例

8 结论

  • ref
    • Implementing ECA Rules in an Active Database

Petri net or FSM -> ECA rules思路可借鉴


一种ECA规则驱动的BPEL流程异常处理和分析机制

刘海 刘安 李青 顾乃杰
2010

摘要:
虽然BPEL被OASIS组织作为目前Web服务合成的标准语言, 它对于合成过程的容错性支持却存在很多不足, 特别是没有提供强有力的异常处理机制.提出一种ECA规则驱动的异常处理机制,可以自动的将用户设定的异常处理逻辑嵌入BPEL流程中, 而用户不需要关心复杂的具体实现.并且,考虑到用户的异常处理逻辑通常会被描述成庞大的规则集, 本文基于一种描述逻辑提出了对ECA规则的静态语义分析机制,从而可以确保异常处理规则集合是无冗余以及无冲突的.本文所述的异常处理和分析机制已经被实现,并且开发出了相关的GUI工具.

关键词: Web服务;BPEL流程;异常处理;语义分析

1 引言

  • 基于ECA(Event-Condition-Action)规则容错机制
    • previous work: 本文研究内容是对之前会议版本文章[24,25]综合和修改

2 相关工作

3 基于ECA规则的异常处理机制

3.1 ECA规则的语法

  • 主动数据库

定义 4.一个ECA规则是一个三元组<事件, 条件, 动作>, 其中事件是一个异常事件, 定义为scope∷faultName形式, 而条件是一组布尔表达式.

本文中动作(action)被限定为以下4种异常处理模式(pattern):

4 对ECA规则的静态语义分析机制

  • the work of this section: 提出一种基于
    描述逻辑ALCQO(Q*)的静态语义分析机制,它可根据ECA规则语义自动判别规则间关系
    • 4.1节给出逻辑ALCQO(Q*)语法和语义
    • 4.2节提出一种ECA规则与ALCQO(Q*)之间映射机制, 从而使得ECA规则中包含语义可让机器理解
    • 4.3 节讨论ECA规则静态语义分析机制

4.1 背景知识

4.2 ECA规则与ALCQO(Q*)之间的映射机制

定义 10 (普遍性)
一条ECA规则r1比另一条规则r2更普遍(标记为\(r1<<r2\)), 当且仅当事件部分完全相同, 条件部分在描述逻辑意义上满足r1.condition \(\subseteq\) r2.condition.

文章符号有点问题

定义 13
两条ECA规则r1和r2是互相冲突

ECA规则静态分析 -> 无冗余且无冲突. ECA规则分析算法如图3 所示

系统结构图如图4所示

  • Ref
    • Web服务驱动的业务流程的容错性研究 (Phd thesis)

文章结构、逻辑较完整


基于ECA规则和活动分解的工作流模型

胡锦敏, 张申生, 余新颖
上海交通大学

摘要:
企业在面临电子商务的挑战中,越来越重视业务过程重组.建立一种合理的流程模型是成功开展BPR(business process re-engineering)的关键.这样的模型应该可以集成企业许多业务相关的信息并且是可被系统解释执行的.在参考WfMC(workflow management coalition)元模型基础上建立了一种基于ECA(event-condition-action)规则和活动分解的工作流模型.ECA规则反映活动之间的执行依赖关系,通过重写办法把ECA模型变为触发器形式的TA(trigger-action)模型,使模型的解析更高效,把事件重写为事件发生时间,使事件表达式具有更强的表达能力.活动分解的模型能很好地支持层次化项目管理.

关键词: 工作流模型;ECA规则;事件驱动模型;触发器模型;重写

  • 工作流: 为达到一定商业目的而根据一组定义规则将文本、信息和任务在工作过程参与者之间传送过程自动化
  • author's idea: ECA -> TA?

1 WfMC定义的工作流元模型

WfMC推出一个如图1所示工作流的元模型(meta model)[3]来描述工作流定义中对象、对象关系和属性

2 基于ECA规则和活动分解的工作流模型

2.1 基于元模型和ECA的工作流定义

定义 1. 工作流是一个二元组,\(WFL::=({Activities},{ECA rules})\),其中{Activities}是活动的集合,{ECA rules}是一组ECA规则的集合,每条ECA规则用来刻画活动之间的迁移条件.

定义 2. 集成化活动是一个十元组\(Activity::=(IdName,Tasks,Role,Rdata,State,ƒ,\theta,ν,\sigma)\),其中

  • Id为活动标识,在工作流模型中,每个活动Id是惟一
  • Name为活动名字;
  • Tasks是任务集合,\(Tasks ::= Null \cup \{Ti|i \in N\}\),\(N\)为自然数集,Ti为任务,Null表示空任务集,抽象的活动的任务集为空任务集;
  • Role是活动执行者对应的角色
  • Rdata是与此活动相关的工作流相关数据,包括输入数据和输出数据
  • State是活动所处的状态
  • ƒ是一功能映射,它把执行活动中的任务与一组工具相映射;
  • \(\theta\)是角色和执行者的匹配函数,负责把此活动的角色与执行者(人/Agent)进行匹配;
  • ν是赋值函数,在活动执行中负责给Rdata中变量赋值;
  • \(\sigma\)是状态转换函数,用于改变活动状态

定义 3. 任务T是一个谓词表达式,T::=ℱ(O),其中ℱ是一个逻辑谓词,表示一个动作或功能,如谓词CreateDoc表示创建文档;O是动作的对象,如CreateDoc(abc.doc)表示创建一个名为abc.doc的文档.这里的逻辑谓词ℱ对应了该任务的操作,通过功能映射函数f可以使它对应到供调用的应用(invoked application)的功能,如ƒ:CreateDoc→WinWord.exe.
定义 4. Role是一个三元组,Role::=(Name,ℭ,Å).Name是角色名;ℭ(capabilities)是角色的能力集合;Å(authorizations)是一组授权集合,表明此角色对其他资源访问或操作权限

定义 5. 每个活动对应的工作流相关数据Rdata是与活动相关的变量及其值的列表VarList,其中VarList::={(VarName,VarType,VarValue)*},是变量名、变量类型及其值构成的三元组集合.

定义 6. 活动状态集S={“Waiting”,“Ready”,“Running”,“Cancelled”,“Aborted”,“Completed”},其中Waiting表示活动触发条件未满足,活动执行条件还未就绪,是初始状态;Ready表示活动的触发条件已经满足,可以开始执行活动中的任务;Running表示该活动中的某些任务已经开始执行,但没有全部完成;Canceled表示活动没有完成就不再被执行.Aborted表示发生异常时退出执行状态;Completed表示活动任务集中的所有任务都已执行完成.

活动状态及其转换关系如图2所示.活动状态变换通过状态变换函数\(\sigma\)实现,如Set_Ready就是一个状态变换函数,它把活动状态从Waiting变为Ready.

实际上很简单的概念,经作者一包装,变得挺复杂

定义7. ECA规则的形式是:

WHEN Events
    IF Conditions THEN
        Action
    ENDIF
ENDWHEN

2.2 ECA模型的TA形式

  • 工作流引擎 -> 数据库

定义 11. 活动单元AU::=(Trigger,Activity).活动单元的结构图如图4所示,Trigger决定活动状态变为Ready的时刻,反映了活动之间以及活动与时间之间关系.Activity表达了活动的属性,包括Tasks,Role,Rdata,State等以及方法ƒ,θ,ν,σ等

2.3 活动分解模型

3 工作流模型的解释

没实际价值


一种策略驱动的BPEL流程异常处理框架

王权于 吕国斌 应时 周峰
2015

摘要 
如何提高BPEL流程异常处理的开发效率是策略驱动的BPEL流程异常处理方法亟待解决的关键问题之一。首先分析了基于策略的BPEL流程异常处理机制,设计一种新的BPEL流程异常处理策略描述语言BPEH/PDL,然后结合BPEH/PDL异常处理策略,给出了一种新的BPEL流程异常处理框架BPEH/P,它具有一定的应用意义。

关键词 BPEL流程,异常处理,策略,框架

1 引言

  • BPEL流程容错研究问题

    • 如何实现BPEL流程异常处理逻辑和正常业务逻辑关注点分离
    • 如何形式化规约和验证BPEL流程的异常处理逻辑正确性
    • 如何高效实现BPEL流程的异常处理逻辑
  • OUTLINE

    • 第2节介绍相关工作
    • 第3节介绍BPEL流程异常处理机制
    • 第4节介绍一种新的BPEL流程异常处理策略描述语言———BPEH/PDL
    • 第5节介绍BPEH/PDL策略驱动的BPEL流程异常处理框架BPEH/F,最后总结全文

2 相关工作

  • 容错的事务性BPEL流程框架FACTS[5]

3 基于策略的BPEL流程异常处理机制

3.3 异常处理过程

4 BPEH/PDL语言

4.1 BPEH/PDL概念模型

BPEH/PDL语言概念模型见图5

4.2 BPEH/PDL语法结构

写啥?看不懂,哪有语法结构呢?


Deriving ECA-rules from timed-automata specifications

master thesis
2002

Abstract
Real-time systems are required to answer to external stimuli within a specified time-period. For this to be possible, the systems behaviour must be predictable. The use of active databases in real-time systems introduces unpredictability in the system, e.g. due to their use of active rules. The behaviour in active databases is usually specified in ECA-rules. Sets of ECA-rules are hard to analyse, which implies that the behaviour of the ECA-rule set is hard to predict.

The purpose of this project is to evaluate the ability to support the development of a predictable ECA-rule set. Using a formal method for the specification task is desirable, since a formal specification is analysable and can be proven correct. In this project, timed-automata are used for specifying the systems behaviour. A method for deriving predictable ECA-rules from a timed-automaton specification is developed,
and successfully applied on a case-study specification. For this case-study
specification, a set of ECA-rules preserving the analysed behaviour of the timedautomata -specification is derived.

Keywords: Active rules, ECA, Real-time systems, Timed-automata

1 Introduction

  • active databases

  • ECA rules (On Event If Condition Do Action)

  • Timed automata

    • Uppaal
  • The aim of this project: to derive ECA-rules from a timed automaton specification

2 Background

  • Time triggered systems

  • Event triggered systems -> Event-Condition-Action (ECA) rules

    • on event E, if condition C is true, then trigger action A for execution
  • A composed event: consists of events combined by event operators (disjunction,
    conjunction, sequence, and various interval operators)

  • The main problem of ECA: dependencies between rules.

  • the good quality of rules:

    • Absence of cascade cycles.
    • Absence of action and condition race.
    • Ability to limit the depth of cascade triggering.
    • Ability to fulfil the timeliness requirements

A finite-state automaton is a tuple \((\sum, S, S_0, E, F)\), where \(\sum\) is the input alphabet, \(S\) is a set of states, \(S_0\) is the initial state and \(E\) is a set of edges (\(E\) is a subset of \(S \times S \times \sum\)).

  • timed automaton = FSM + a set of clocks

  • Every state in some execution path (\(E[]\))

  • Some state in some execution path (\(E<>\))

  • Some state in every execution path (\(A<>\))

  • Every state in every execution path (\(A[]\))

In Figure 3 to Figure 6 example traces are viewed to further explain the semantics of the queries in Uppaal.

  • The iteration consists of three steps.
    1. In the first step, the system is specified in timed-automata.
    2. In the second step, rules are derived from the specification using different approaches.
    3. The third step is an analysis of the ability to derive rules from the
      specification.

通览全文,作者并未给出一个自动转换工具,只是蜻蜓点水式。至于Petri/UML -> ECA?以后参考

  • ref
    • Realizing business processes with ECA rules: benefits, challenges, limits

posted @ 2016-07-12 21:34  westRiver  阅读(725)  评论(0)    收藏  举报