多年来对业务灵活性的探索使人们广泛采用面向服务架构（SOA）,现今的IT集成架构已经有很大的改观。过去的技术管道开始用企业服务总线进行连接，并为网络、通信和协调以及用于支持SOA的服务容器管理提供架构。每一个集成软件供应商都在自己的产品中提供某种形式的ESB，ESB目前已成为服务定向应用的集成标准。但是，IT集成组织下一步的发展方向如何呢？

　　IT集成组织下一步的发展方向应该是一类名为事件流处理的软件（ESP）。ESP被软件供应商和分析人士誉为是“下一个大事件”，因为ESP能够帮助SOA集成组织更加智能化、及时做出响应。ESP令业务以迥然不同的方式思考其操作和IT基础设施，因为ESP能够理解业务现在的状态而不是业务过去的状态。

　　ESB不是已经发行事件了吗？不是所有的SOA基础设施要素都能够发行并运送事件吗？答案是“是的”现今的ESB可以处理事件。但是，他们不会规定自己服务发行事件的用途。这也是ESP价值的关键所在。ESP能够使事件驱动的SOA破解事件模式（如果是按照先后顺序），弄清事件时间性（4秒钟内）和空间性（10英尺内）之间的关系。——并且在实时过程中也能做到上述两点。这就使业务能够持续在实时过程中分析关键绩效指标，并能验证实时风险和机遇，及时采取应对措施。这些功能需要一种新型的数据处理方法——流计算——它可以在事件驱动的SOA和实时业务之间传送缺失的链路。

　　ESP——找出ESB事件模式使用的因果关系和时态约束

　　为了展示ESB和 ESP是如何一同工作的，我们先分析一个特例：信用卡欺诈监测。监测的目的是为了监督系统内部的购买活动并捕获可以分析的授权请求，以便监测欺诈行为。该项操作展示了事件处理范例的三个阶段 1）监测，2）分析，3)行动

　　首先，我们需要以电子方式对ESB上的事件进行存取。以“商人A和商人B”形式出现的源事件流代表通过信息传送给事件引擎的购买活动事件。

　　其次，我们需要管理这些事件的规则，既然ESP引擎可以异步处理事件，事件可以来自任何地方，可以是任何类型，能够以任何顺序被接收。事件处理语言能够将事件特征，事件发生时间，以及经过推断的事件间因果关系作为事件处理语言的基本元素，而不是把结构化数据和SQL的关系代数作为其基本元素。EPL流程对“局部性”提出了质疑—例如，当A和B为真，那么如果C在N秒钟之内发生，就需要采取行动。实时检测事件模式可以帮助应用识别业务瞬间发生的机遇和威胁，如同实时购买和抛售股票，将制造车间自动化或者监测信用卡欺诈行为一样。以下是一个基于事件原则的实例。

　　这个EPL编码的开头是一个事件过滤器“开启信用卡支付（用户）”。这条语句指导引擎监测ESB上代表信用卡指令的事件。当事件流经ESB时，事件模式就会得到满足。下一语句"FOLLOWED-BY"指导ESP引擎监测随后针对相同帐户“用户“的信用卡支付事件。如果这三个指令在两分钟内发生，编码就识别了一个潜在的欺诈活动。尽管我们在前面的文章中没有提过，但是包含"空间"逻辑的例子可能标志着超出购买模式范围的任何一个指令，如果购买位置表示其中的一个指令是非法的，那么该例子可能标志着一个随后的指令。这些例子都诠释了ESP第一个核心概念：推断因果关系。ESP从指令的相互关系中可以推断出其中的一个或者多个指令是由欺诈行为所引起的。

　　"WITHIN"这条语句向我们展示了ESP的又一个重要概念：时间。在这个例子中，如果第三个信用支付事件没有在两分钟内监测到第一个指令，该行为就不会被标记为潜在的欺诈行为，脚本也就结束了。如同在实时灵活的企业当中，单个事件在流计算当中的重要性也会随着业务的重要性的降低而迅速降低。针对事件采取行动的机遇是非常短暂的。除非事件处理架构能够迅速的感知其重要性并做出回应，否则开发这种状态的机遇转瞬即逝，这种状态也会因随后的事件或者其它的因素而发生改变。

　　最后，我们要看一看ESP的第三个重要组成部分：行动。同信用监测应用一样，一旦监测到一种模式，自动系统就会采取事件驱动的行动。在这个例子中，指令要求遭到拒绝，通过传送ESB中的一个派生事件，帐户被标记为欺诈管理活动。

　　结论

　　企业服务总线一直都是企业IT集成基础设施的主干，并且提供了一系列的事件流使实时构想成为现实。流计算，和ESP工具使这一切成为可能，并且能够监测时间，原因和ESB事件中基于空间的模式。通过将ESB原则和ESB规范化的集成组织结合在一起，企业会真正变得更加灵活。