当今企业期望通过其对于风险和机遇的快速响应能力增加竞争优势。这种优势来源于基于复杂事件处理（CEP）技术的高度响应、接近实时的系统，已经在华尔街金融应用上有所使用。现在这些CEP技术正在更广泛地为很多企业应用所使用。

　　例子不胜枚举：

　　Fraud分析师警告，当相同的信用卡号在不同的城市几乎同时使用。

　　根据电源故障的历史和位置可以很快地对比实时天气订阅源，来警告公共设施维护团队可能的麻烦。

　　医疗卫生提供商能够以病人的保险范围为背景快速检查养生法实验类型。

　　创新之路

　　CEP可能是大型公司创新之路。对于很多公司来说，转向事件处理意味着在软件架构上的正确转移。

　　复杂事件有其独特性质，这个领域的人仍旧在争论描述CEP的各种术语的定义。“事件驱动架构”有时用来表达CEP处理的问题。

　　尽管各种CEP引擎的内在运作组成有所不同，但是他们的结构可能不是具体关系到应用开发管理者的，这些人要倾向于更多的关注CEP引擎如何编程。“如果你和用户探讨CEP，他们主要的兴趣点在于他们可以通过用户界面对这个引擎做什么，”David Luckham说道，他是斯坦福大学电气工程名誉教授，同时是《业务事件处理：构建实时企业》（Event Processing for Business: Organizing the Real-Time Enterprise (John Wiley & Sons, 2011)）一书的作者。

　　为了轻松编程，CEP厂商支持类SQL语言、visual和相关的编程技术。这些都能和现有的编程技能集适应。有时，CEP产品在是否支持基于查询的CEP或者基于规则的CEP有所区别。但是开发团队在应对CEP时，工具还是适用的。

　　事件流群岛

　　不同CEP引擎下的本质“数据库”的不同构成某种程度上归因于其不同的“血统”。一些来自于规则引擎，一些来自于业务活动监控（BAM），其他的一些则有其他的背景。

　　事件驱动系统可能和关系型数据库或者中间件消息系统或者两者的混合是亲戚。有时候是这样，但不总是这样，底层的数据库被描述为“流数据库”或者“事件流”。厂商的CEP相关产品包括Espertech、IBM、Informatica、Microsoft、Oracle、Progress Software、RedHat、StreamBase、Sybase、Tibco和Vitria等等。

　　在大多数CEP引擎中，数据记录在其存储前被处理。这不同于数据仓库。CEP不同于传统的RDBM，小批量数据可能和大批量数据查询较量，而不是小批量数据查询和大批量数据较量。

　　事件，简单或者复杂都可以通过操作系统作为“流”来分析。特别强调的是在处理时间序列数据并确立事件窗来显示时间数据。在这些窗口中，新数据会和已知事件模式对比。

　　复杂事件是数个有意义的简单可观测事件的集合。举个简单的例子，你可能想看是否同一张信用卡可以同时再两个地方使用，这通常是骗子的伎俩。

　　CEP中的SQL语义

　　观察家认为一些CEP引擎倾向于显示出和传统关系型数据库更亲密的关系，尽管其他CEP引擎所展示的这样的关系很少。但是从一个程序员的观点来看，区别可能是狭小的。
　　
　　“一些CEP产品看起来更像DBMS。但是区别不是以前那样了，”W. Roy Schulte表示，他是Gartner的副总裁兼著名分析师。“五年前，有一个很大的不同。”促进这正集合的是工具，这些工具支持类似SQL语言，意味着能够处理CEP数据流的独特性质。

　　进行熟悉的工作有好处。但是事件驱动架构的属性正是一些CTO和开发经理要考虑的新的编程模型。这会是一个艰难的决策点。你可能不想改变编程风格，但是新的应用类可能实际上可以很好地为新的编程类型所处理，Curt Monash建议。他是Monash Research咨询公司的总裁。

　　“这个编程模型以事件为中心，对其采取行动，不同于传统数据库管理系统，”他说。

　　在《EDA和SOA：孤掌难鸣》中，我们将介绍复杂事件处理中的速度和复杂度以及SOA与EDA的关系。