复杂事件处理(Complex Events Processing) --2. 复杂事件处理的功能和应用场景

 

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

在企业应用中使用复杂事件处理，首先要确定事件包含哪些内容，或者什么内容适合封装为事件并交给事件处理引擎去处理。之前有文章提到企业应用系统中数据流可以分为业务数据流和监测控制流，（见http://blog.csdn.net/zlushangnwpu/archive/2008/09/30/2999571.aspx）事件更适合包含用于监控的内容，复杂事件处理的功能更适合做企业应用系统的监测和决策控制。一般来说，数据流中的业务数据是企业应用需要做处理的数据，这些处理包括获取更新，传输转换，存储，计算，展现等等。业务数据代表现实世界中的事物及其状态，对这些数据的处理代表对这些事物的处理。 通常这些处理都是用过程式语言描述的，由企业应用开发者在设计时编排确定。而事件包括事物状态和事物之间的某些动作，即数据流中的数据和流程中对这些数据做了哪些操作，通过事件可以及时了解事物的状态和对事物的所做的操作。

获取这些事件后，可以按上篇中提到的事件处理模式来处理事件：

（1）     对事物的状态进行推断或者判断，得到一些结论。这属于监测的范畴。

（2）     当出现一些结果时，反向推断出导致这些结果的原因。反向推断要求原因对结果来说必须是必要条件。这也属于监测的范畴。

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

（4）     根据当前事物的状态和对事物的动作，预测事物将来的状态。这个有点模糊，我把它依然归为监测范畴。

事件处理得到的结论，原因，动作决策，预测状态，又会反作用于处理数据的流程，控制流程的分支选择。事件处理和普通数据处理的关系见下图，参见文章

http://blog.csdn.net/zlushangnwpu/archive/2008/10/21/3118446.aspx。

 

其实监控事件和业务数据的分类并不严格，由企业应用系统设计者自己把握。对事件的处理没有融入普通数据的处理之中，一般有两个原因：

（1）     业务数据的处理更多是数据的获取更新，传输转换，存储，展现，以及基于这些操作的逻辑流程。而监控事件的处理是基于多个规则的推断和推理，所谓规则即上述四种事件处理模式的实例。业务数据的处理适合用过程式语言来描述，由流程引擎来驱动；事件的处理适合使用声明型语言定义规则，由规则引擎去做推断和推理。规则引擎多使用RETE算法，可以高效地基于规则集合来做推断和推理。两者的分离使得各自的处理清晰，高效，且便于开发维护。

（2）     事件处理所用的规则，在企业应用系统运行时经常按业务人员的需求而变化，所以要求规则对于业务人员是可读的。业务数据处理流程中的技术操作对业务人员而言就无法理解了。

所以复杂事件处理的应用场景，多是企业应用系统中的监测和控制决策（Business Activity Monitor）。例如银行的反洗钱，反欺诈系统，获取用户在银行操作的事件记录，匹配既定的规则，来判断该客户的操作是否是洗钱行为或者欺诈行为。当下很多行业的很多企业倡导一个概念：以客户为中心。即根据客户各个方面的信息和客户之前的消费行为，在客户一进入商家的系统，快速判断此客户的喜好和可能的销售机会，决定给客户展现一个什么样的个性化用户界面，上面罗列着各种客户最可能消费的产品或者服务的连接。概括一下：企业在运营过程中，由基础的应用系统支撑。复杂事件处理技术随时了解应用系统中的状态信息和操作行为，可能是客户的状态，客户的消费记录，供应商和合作伙伴的状态信息，甚至股票的点位，天气的变化等等，根据既定的模式规则，来快速推断，查因，决策和预测，实时地修改应用系统的行为，改变企业运行各环节的一些行为，及时响应外界因素的变化。做到实时企业，来增强自己的竞争力。 The power of Now!!