在《复杂事件处理：构建竞争优势》中，我们介绍了现在CEP技术正在更广泛地为很多企业应用所使用。

　　速度和复杂度

　　速度和复杂度在哪里构成问题，“引擎如何工作”可能就是兴趣点所在。大多数CEP引擎极大地超过了一般用途的服务器。

　　“在要求非常高的环境下，产品都是性能优化的。一些案例中，一种方式就比其他的优秀。他们也有不同的编程模型，”Monash介绍，“其中之一就是基于流的强调可视化模型。如果你坚持的话，这些也允许你写代码。有基于规则和基于语言的编程模型。每一个产品都有清晰的根源或者重点。这也是在他们之间进行选择的自然基底。”

　　我们可能用类SQL查询语言构建了具体的功能来处理流数据和持续流程。别人可能提供了图形用户界面进行建模，允许团队成员拖拽事件组件来构成应用。另外的人可能提供图形事件流语言。

　　同时，还有一些其他的新型技术，CEP可能在主流中很难找到一个稳固的职责，如果现任数据库和商业智能技术继续保持。“CEP就是竞争者，但是可能不会赢。”

　　CEP是数据库技术的替代。是壁龛之外的东西，考虑到现在的数据库技术强健无比，这样的替代是否需要尚不清楚。

　　每秒成千上万事件

　　本质上CEP数据处理所运作有什么本质的不同？其一：特别是复杂事件架构要求高速和高容量处理。

　　“在应用CEP中出现的一些问题包括所使用的事件模式的复杂性，”Luckham表示，“如果你必须检查数个事件以及状态参考表示，过去小时中的历史事件，然后就必须探测模式并且看看状态是否正确，”他说。

　　在包含模式碎片的情况下，这个任务就是个大问题，他继续说道：“你经常得到模式的局部实例。你可能有数个或者很多歌局部匹配模式。在CEP中你该怎么做呢？在这种类型的问题下，底层事件数据库的架构就会成为应用专家的兴趣点所在。”

　　这个问题也取决于你所面对的问题，他说。例如，如果你正在尝试在同步股票市场的每秒数千个事件套利交易，CEP处理事件的方式就可能会有所不同了。

　　EDA和SOA：孤掌难鸣

　　在EDA和面向服务架构（SOA）之间有大量重叠，就像同步和异步系统，根据Kim Kazmaier所说，他是美国银行的技术人员。

　　Kazmaier协助领导了美国银行客户部的一个多年的SOA项目，在最近Gartner的会议上做了一次演讲。这个项目现在开始合并EDA和SOA。早期进行EDA的努力已经积累了很多消息中间件专家，他说。

　　“大多数企业现在正在尝试捕捉交易体验的价值，”他说，“你可以从风险缩减的观点中看到机遇。”

　　用户期望用CEP进行更快速的操作：“事件引擎比典型的SOA引擎运行快四到五次，”他说。但是并不意味着你自动化的可以实现你想要的速度。

　　“我从CEP中所学到的事情之一就是：如果你在单一的引擎中混合了过多的工作量，你可能不能得到期望的吞吐量，”Kazmaier警告。结果就是，他成多级设计模式的使用为“好主意”。