关于复杂事件处理和事件驱动架构的争论

复杂事件处理（Complex Event Processing ，CEP）系统和事件驱动架构（Event Driven Architecture，EDA）都被认为会在目前和未来的精致繁杂的系统设计中扮演重要角色。但是它们的角色是什么？会对业界产生什么样的影响？最近 社区又开始了关于这些问题的争论。David Luckham和Roy Schulte还编撰了一个用于CEP和EDA的术语概览和词汇表。

抛开实现细节，Luckham和Schulte对每个术语做了定义：

首先“事件”这个最普遍的术语，是有问题的。基本上它包含两个截然不同的含义：（1）一个发生的活动；（2）计算机系统里面代表某个活动的事物。按理说， 应该引入两个不同的术语，比如“事件（event）”和“事件对象（event object）”。但是，事实是在每个稍微长些的讨论中，你都会发现这样做太晦涩难懂了，它们【注：event和event object这两个分开的术语】的区别要不就是被误用，要不就是被忘记甚至忽略了。举个例子，如果要使用两个术语，那么很有可能导致你在说“事件处理 （event processing）”时，其实意思是指“事件对象处理（event object process）”。所以说，最好的办法是复用“事件（event）”这个单词，通过每个词的上下文来理解它所要表达的意思。

Luckham和Shulte将“复杂事件”定义成“一个对多个其它子事件的抽象的事件。”在提到穆迪投资者服务系统中的问题导致不正确的评级时，Joe Mckendrick谈论到了复杂事件的话题。Mckendrick说“也就是说，目前即使没有上亿美元，也有数百万美元的投资决定是由此类系统产生的错误数据造成的。”Mckendrick的立场是，复杂的识别和感应系统也许仍然需要人类的参与，以阻止问题或者错误的发生。

Mckendrick提到K. Mani Chandy博士，加州理工学院的一个正在做识别和感应研究的计算机科学教授，他曾经表示在基于复杂事件做决策时，要保证这个过程中有人的参与。Chandy说在有些情况下，比如战术军事上的某个涉及到使用武器的操作，“它会一直有个对此事最终行为负责的人参与其中。”

Chandy和Micahel Olson谈到为何 事件处理与‘识别和感应’应用（PDF）也许将在业务活动监测和业务仪表盘领域普遍存在。Chandy和Olson对Web识别和感应应用有非常深入的研究，这些应用从Web数据源提取事件和数据：

Web数据源可以是活跃的或者休眠的。客户端可以通过请求-应答协议轮询服务器，以获得信息。而信息也可以通过RSS或者ATOM流，或者其他的数据协议，推送给客户端。休眠的数据源也可以有个活跃的接口，方法是让代理定期轮询它，并在接下来的轮询中传输更改的信息。

但是CEP真的需要一个完全不同的架构类型吗？

Brenda Michelson就事件处理写了一篇文章——事件驱动架构概览。他定义了EDA中的5类组件：

• 事件元数据：事件元数据包括事件说明和事件处理规则；
• 事件处理：事件处理的核心是引擎和事件发生数据；
• 事件工具：事件开发工具用于定义事件说明和事件规则，以及管理订阅等。事件管理工具提供事件处理基础架构的管理和监测，事件流的监测以及显示事件生成和处理状态等；
• 企业集成：一个企业集成中枢在事件驱动架构中扮演着重要的角色。需要集成的一些服务包括：事件预处理（过滤、路由和转变等）、事件通道传输、服务调用、业务流程调用、发布和订阅，以及企业信息访问等；
• 源和目的：创建事件和/或执行一个事件驱动动作的企业资源（应用、服务、业务流程、数据存储、人员和自动代理等）。

Michelson还谈到了EDA和SOA之间的关系：

我相信SOA和EDA是平等和互补的。所以，我不认同那些努力传播SOA的同学们所说的“EDA只是SOA的一个子集”的论断。一个更广泛的事件驱动架构概念，不仅是超越事件驱动SOA的，还应该包括实时信息流和分析，以及复杂事件处理。

Ivar Jacobson博士在EDA方面有自己独到的见解。Jacobson提出的问题是：我们需要事件驱动架构吗？在回答他自己的问题时，Jacobson说，“当EDA认为事件是系统中最重要的组成时，你最好注意那些组件或者服务，以及组件之间的‘通道’”。事件可以被生产、传递和消费，甚至在系统中被传播。这种类型系统的一个最大好处就是：

最有意思的组件是那些服务。你同时有了面向服务的架构（SOA），甚至更多。

不论哪一种情况，EDA和SOA都不会彼此不相容或者排斥。它们都能被用来处理复杂事件处理系统，并为你的企业提供自动的或者有效的产出。

查看英文原文： Complex Event Processing and EDA?