复杂事件处理前言工作的需要开始学习和使用复杂事件处理技术和产品，比较感兴趣。

原因一觉得企业应用技术发展到现在数据的传输交互，数据存储，数据转换，数据展现这几部分已经比较成熟，或者趋近成熟，数据处理和分析部分方兴未艾，呵呵比较有前途。

好比企业的数据总线已经准备就位，现在需要的是总线上的做数据处理和分析的数据内容服务。

原因二事件处理引擎使用非过程语言的声明型规则语言和状态机模型来描述事件处理规则，自己对非过程的处理描述很感兴趣，试想当触发事件产生开始引发一系列的动作时，作为规则的定义者并不知道这次会触发多少动作，最终会终止在何处，结果是什么。

有些挖未知宝藏的感觉。

前期学习了一些资料，也试用的TIBCO的复杂事件处理工具Business Events. 列出以下的目录，希望通过持续的学习，能写完这些内容。

目录1．基本概念：事件，事件关系和事件处理的简单抽象理解2．复杂事件处理的功能和应用场景3．事件的定义和分类4．事件的关联关系5．基于关系的事件处理6．事件处理的实现：规则引擎7．TIBCO Business Event8．案例到目前还有些问题没解决，希望写完这些内容后都能搞明白。

问题1. 事件驱动架构（Event Driven Architecture）的含义究竟是什么2．事件处理和规则引擎的关系3．规则语言和状态机模型的联系和区别目录1．基本概念2．复杂事件处理的功能和应用场景3．事件的定义和分类4．事件的关联关系5．基于关系的事件处理6．事件处理的实现：规则引擎7．TIBCO Business Event8．案例目标事件驱动架构（Event Driven Architecture）的含义究竟是什么事件处理和规则引擎的关系规则语言和状态机模型的联系和区别Petri网，RETE算法，RAPIDE语言1.基本概念：事件，事件关系和事件处理的简单抽象理解基于自己目前对事件处理的理解，对信息系统的认识，来定义事件和事件关系，来概括在信息系统中有哪些事件处理的模式。

1.1 事件从字面上理解事件可以认为是发生的一件事情，包括事物状态和事物之间的某些动作。

在信息系统中，事件可以是一些事物对象的状态属性，也可以是事物之间动作的记录。

对于动作的完整描述可以用状态机模型描述，即对初始状态的事物做某些动作，事物由初始状态迁移到动作后的新状态。

在事物动作过程中，可以构造三个事件信息，事物初始状态事件，作用于事物的动作的事件，事物结果状态事件。

事物动作的状态机模型示意图事物状态属性彼此之间会有一些依赖约束关系，可以从一些状态属性值推导出另一些状态属性的值。

这些状态之间的约束可以使用无动作的状态机模型描述，即当状态1成立，状态2必成立。

事物状态之间的约束关系示意图事件的关系事件的关系主要有四种。

1.2.1时间顺序关系动作事件和动作事件之间，动作事件和状态变化事件之间，都存在时间顺序。

1.2.2聚合关系动作事件和动作事件之间，状态事件和状态事件之间都存在聚合关系。

即个体的聚合形成整体集合。

1.2.3层次关系动作事件和动作事件之间，状态事件和状态事件之间都存在层次关系，即父类事件和子类事件的层次关系，从父类到子类是具体化，从子类到父类是泛化。

1.2.4 依赖关系事物的状态属性之间彼此的依赖关系和约束关系。

1.2.4因果关系对于完整的动作过程，结果状态为果，初始状态和动作都可以视为原因。

类比哲学上论述事物如何发展也是有两个因素的，一是内部本质，二是外部作用。

事件的处理在应用系统里，事件处理实现的功能有几类模式。

推断主要利用事物状态之间的约束关系，从一部分状态属性值可以推断出另一部分的状态属性值。

例如当三角形1个角为90度，另一个角为45度，则推断出第三个角为45度。

查因当出现结果状态，并且知道初始状态，可以查明某个动作是原因，同样当出现结果状态，并且知道之前发生了什么动作，可以查明初始状态是原因。

当然反向的推断要求原因对结果来说必须是必要条件。

决策想得到某个结果状态，知道初始状态，决定采用什么动作。

预测知道初始状态，以及将要做的动作，预测结果状态。

以上可以看到状态机描述了事物在各种动作下的变化规则，基于这些规则和不同的目的，来决定要做什么模式的事件处理。

2.复杂事件处理的功能和应用场景有了上篇对复杂事件处理的简单抽象，这一篇里来说复杂事件处理的功能和应用场景。

在企业应用中使用复杂事件处理，首先要确定事件包含哪些内容，或者什么内容适合封装为事件并交给事件处理引擎去处理。

之前有文章提到企业应用系统中数据流可以分为业务数据流和监测控制流，（见/zlushangnwpu/archive/2008/09/30/2999571.aspx）事件更适合包含用于监控的内容，复杂事件处理的功能更适合做企业应用系统的监测和决策控制。

一般来说，数据流中的业务数据是企业应用需要做处理的数据，这些处理包括获取更新，传输转换，存储，计算，展现等等。

业务数据代表现实世界中的事物及其状态，对这些数据的处理代表对这些事物的处理。

通常这些处理都是用过程式语言描述的，由企业应用开发者在设计时编排确定。

而事件包括事物状态和事物之间的某些动作，即数据流中的数据和流程中对这些数据做了哪些操作，通过事件可以及时了解事物的状态和对事物的所做的操作。

获取这些事件后，可以按上篇中提到的事件处理模式来处理事件：（1）对事物的状态进行推断或者判断，得到一些结论。

这属于监测的范畴。

（2）当出现一些结果时，反向推断出导致这些结果的原因。

反向推断要求原因对结果来说必须是必要条件。

这也属于监测的范畴。

（3）基于当前事物的状态，根据需要的结果，决定采取接下来采用什么动作。

这属于决策范畴。

（4）根据当前事物的状态和对事物的动作，预测事物将来的状态。

这个有点模糊，我把它依然归为监测范畴。

事件处理得到的结论，原因，动作决策，预测状态，又会反作用于处理数据的流程，控制流程的分支选择。

事件处理和普通数据处理的关系见下图，参见文章/zlushangnwpu/archive/2008/10/21/3118446.aspx。

消息总线其实监控事件和业务数据的分类并不严格，由企业应用系统设计者自己把握。

对事件的处理没有融入普通数据的处理之中，一般有两个原因：（1）业务数据的处理更多是数据的获取更新，传输转换，存储，展现，以及基于这些操作的逻辑流程。

而监控事件的处理是基于多个规则的推断和推理，所谓规则即上述四种事件处理模式的实例。

业务数据的处理适合用过程式语言来描述，由流程引擎来驱动；事件的处理适合使用声明型语言定义规则，由规则引擎去做推断和推理。

规则引擎多使用RETE算法，可以高效地基于规则集合来做推断和推理。

两者的分离使得各自的处理清晰，高效，且便于开发维护。

（2）事件处理所用的规则，在企业应用系统运行时经常按业务人员的需求而变化，所以要求规则对于业务人员是可读的。

业务数据处理流程中的技术操作对业务人员而言就无法理解了。

所以复杂事件处理的应用场景，多是企业应用系统中的监测和控制决策（Business Activity Monitor）。

例如银行的反洗钱，反欺诈系统，获取用户在银行操作的事件记录，匹配既定的规则，来判断该客户的操作是否是洗钱行为或者欺诈行为。

当下很多行业的很多企业倡导一个概念：以客户为中心。

即根据客户各个方面的信息和客户之前的消费行为，在客户一进入商家的系统，快速判断此客户的喜好和可能的销售机会，决定给客户展现一个什么样的个性化用户界面，上面罗列着各种客户最可能消费的产品或者服务的连接。

概括一下：企业在运营过程中，由基础的应用系统支撑。

复杂事件处理技术随时了解应用系统中的状态信息和操作行为，可能是客户的状态，客户的消费记录，供应商和合作伙伴的状态信息，甚至股票的点位，天气的变化等等，根据既定的模式规则，来快速推断，查因，决策和预测，实时地修改应用系统的行为，改变企业运行各环节的一些行为，及时响应外界因素的变化。

做到实时企业，来增强自己的竞争力。

The power of Now!!3.复杂事件处理引擎产品复杂事件处理的核心产品其实就是规则引擎，规则引擎的工作原理如下图所示。

（1）开发者使用规则语言或者状态机定义一系列的规则，这些规则定义了系统中实体应对外界变化的反应规律。

即一个实体对象当受到外部的作用，内部状态发生了变化，满足一定条件的内部状态又触发对外部的反应，执行一定的动作。

无数的有着自身行为规则的对象，彼此相互作用，共同决定了系统整体的行为。

应用系统采用这种逻辑处理方式，模拟了真实世界的行为方式，是真正的面向对象的处理方式。

（2）所有规则在规则引擎里构造为Rete network结构，用于做规则的快速匹配。

（3）包含状态信息的对象，代表外界对系统作用和系统对外界作用的事件对象，都存储在引擎的内存里。

（4）当外部事件产生时，规则引擎对所有定义的规则做匹配，选择出满足条件可以执行的规则策略。

这些规则按定义好的优先级排列，预备按顺序执行。

（5）如果规则执行的结果不影响内存里任何对象的状态，那继续第二条规则的执行，直至列表中的规则都执行完毕。

否则重复之前的过程。

（6）在处理过程中，内存里的状态对象和事件对象是可以删除的，当然也可以创建新的状态对象和事件对象。

（7）这种程序不会结束，除非内部所有的对象都被清除，或者外部没有任何新的事件发生。

总之，使用复杂事件处理规则引擎来构建开发系统，是一种更贴合真实世界运行状况的描述形式。

这里大量的具备自由行为规则的对象决定了系统整体的行为表现。

所以我说这才是真正的面向对象的编程方式。

在经济等其他领域，这也是一种好的结构模式。

：）基于规则引擎开发的应用程序，包含如下内容。

（1）包含各种状态信息的对象的类定义。

（2）事件对象的类定义。

（3）描述对象状态变化和行为反应的规则和状态机模型。

（4）一些常量定义。

（5）输入事件和输出事件的消息通道。

（6）需要查询或者加载的历史数据。

这种应用程序的处理逻辑如下图所示。

（1）外部作用系统的事件产生。

对这些事件做过滤，删除不需要的事件。

（2）过滤出的事件赋值给内部的对象，开始做事件的聚合，事件的泛化。

（3）根据定义的规则和系统的需求，进行事件的匹配，判断和推理。

最后得到一个判断结论，或者找到一个导致事故的原因，决定一个决策，或者一个对系统未来变化的一个预测。

（4）这些结果会发布出去，作用于其他系统。

最后有个很重要的问题需要阐述一下，就是什么样的系统适合用事件处理规则引擎来做，即行为规则声明式开发方式，什么样的系统适合传统的过程式开发方式（不管是过程式的编程，还是过程式的图形化流程编排）。

我的答案是：（1）抽象一些这个问题是，使用系统整体过程的描述方式，还是使用系统个体行为规则的描述方式。