对于灵活的追求促进了近来日渐增多的对面向服务的架构(SOA)的采用。而且现代IT的集成架构的表现也正在逐步改变。过去的技术孤岛现在已经被企业服务总线(ESB)技术连接起来。企业服务总线为网络主干、通信、中介以及服务容器管理等SOA所需要的因素提供支持。每个综合软件厂商都在他们的产品中提供某些种形式的ESB，ESB事实上已经上升到了面向服务的应用软件的统一标准的地位。但是，IT集成架构的下一步又会演变成什么样呢?

　　下一步将会是一种新的类型的软件，它被称为事件流处理(ESP)。ESP已经被软件厂商和分析家成为下一个“重要的东西”，因为他能够帮助SOA集成架构变成智能化的和可响应的。由于ESP能够让业务不仅了解过去业务的状态，还能得知现在的业务状态，所以他能够让业务分别考虑业务运作和IT基础架构的有关事宜。

　　但是，难道ESB及其组件已经不能发布事件了吗?所有的SOA的基础元素都不能发布事件处理事件了吗?回答是：不。当今，ESB及其组件也是有事件处理的能力的。不过，他们并不规定对那些已经被他们的服务发布的事件做哪些处理。而这恰恰是ESP的关键价值所在。

　　ESP能够让一个事件驱动的SOA程序去解释事件模式(如果C紧跟B，B紧跟A)，时间上(4秒钟以内)和空间上(10英尺之内)的事件的关系，而且，是能够实时的完成这些的。这意味着允许一家企业不断的实时的分析关键绩效指标，实时的识别威胁和机遇，并立即实施。这些能力需要一种新的计算方式——流计算——能够在事件驱动的SOA与实时的商务视角之间传递完整事务中缺少的环节。

　　ESP——用时间约束和因果关系找到ESB的事件模式

　　为了描述ESB和ESP是如何在一起工作的，让我们来用一个例子来解释：信用卡欺诈检验。目的是监督系统内的购买活动以及捕获那些可以被实时分析检验是否是欺骗活动的授权请求。这些活动充分的展示了事件处理范例的三个阶段：1 监督 2 分析 3 处理

　　首先，我们需要那些ESB中发生的事件有电子化的接口。源事件流，用下文的A商人表示，而商人B则代表通过ESB的通告传递给事件引擎的购买活动事件。

　　其次，我们需要制定一些遵照那些事件的规则。由于ESP引擎处理事件是异步的，事件可能源自不同的地方，而且类型也可能各异，接收的顺序也可能差异很大。事务处理语言(EPL)使用事件属性、事件发生的时间以及事件中任何能推断的因果关系作为他的基础元素，而不是将数据的结构和SQL的关系代数作为基础元素。一个EPL处理查询是部分的——例如，当A和B都是真的的时候，那么如果C在N秒内发生了，那么采取措施。实时的检测事件模式能帮助应用程序识别即时发生在业务中的事件到底是威胁还是机会，例如实时买卖股票的机会，自动操控专业化生产车间的机会或者是检测信用卡欺诈的机会。下文我们将用一个例子来解释基于事件的规则。

　　这段EPL代码以一个"ON credit_payment (user)"的事件滤镜作为开始，这个语句命令引擎去监视ESB中的那些表示信用卡交易的事件。随着事件通过ESB，这个事件模式就被部分确认了。接着，那句"FOLLOWED-BY"命令ESP引擎去监督同一个用户后来的信用卡支付事件。如果在两分钟内发生了三次交易，那么这段代码将会将其鉴定为潜在的欺骗活动。尽管上文没有描述过，一个包含在空间逻辑的警告也许会成为所有模式之外的地域性购买交易的标记或者当出现购买地域的地理距离暗示至少有一笔交易是不合法的情况时，它也会成为后续交易的标记。这些警告阐明ESP的最核心的概念：因果关系的推论。ESP已经从发生欺诈的交易的可能性的关系来判断。

　　语句"WITHIN"阐明了ESP的另一个核心的概念：时间。在这个例子中，如果第三笔信用卡支付事件并没有在第一笔交易后两分钟之内发生，那么这个活动就不会被标记为潜在的欺诈。检视到此结束。在流计算中，基于实时的原因，灵活的企业中，任何单独的事件对于业务重要性而言的重要性都是显著降低的。遵照事件行事的机会通常是极为短暂的。除非事件处理框架能够迅速的识别出其意义并做出响应。由于后续事件使得外界环境的变化以及其他因素的缘故，利用这种情况的机会是转瞬即逝的。

　　最后，我们来看一看ESP第三个关键概念：处理。信用卡欺骗检测应用系统等自动化系统通常在模式被检测到的时候马上调用事件驱动处理。在这个例子中，当前的交易请求被拒绝了，并且通过在ESB中发送一个新的起源事件把该帐号标记为欺骗管理行为。

　　结论

　　随着企业服务总线不断成为企业IT集成架构的主干，它提供的事件流使得实时的观测成为现实。流计算以及ESP工具能够提供检测时间、因果关系以及事件中的基于空间的ESB流中的模式的能力。通过利用ESB规格化的集成架构整合ESP规则，企业会成为真正灵活的企业。