您能否为我们简要的讲解一下事件处理？

　　好的，事件处理分为四部分。一是，你需要连续不断的获取数据，有许多方式可以实现它。一些是通过传感器。很多公司发现在生产和物流中，他们已经有很多传感器，他们产生了大量的统计数据，远超过他们实际所需。因此，首先是获取数据，然后是融合数据 — 从多个信息源关联数据。一旦融合了数据，你就会明白外界的情况以及它是如何变化的。所以，第三部分就是计划。你要计划对这个变化做出响应。第四部分是执行响应。这四部分组合使事件流程对业务非常重要。

　　对于那些有兴趣实施事件流程的读者，你有什么建议？

　　我们的建议是，尤其是刚起步的企业，一定要循序渐进，评估每一步的业务利益。一个关键步骤是为主要的管理人员获取实时或者接近实时的业务性能指示器。首先关注的是我们前面谈到的第一部分内容，以及部分第二部分内容。也就是，首先获取数据，其次是简单地关联，在某种程度上把数据放入表格，这对主管在屏幕上看到数据来说，非常有用。这就是所谓的业务活动监控或者是BAM。

　　从一个相对小的步骤开始，你要确定它在某种程度上是有意义的，帮助主管了解外部的变化，并做出更好的决策。一旦他们看到这些好处，就会采取下一步，做出更多的实时关联 — 更实时的融合。开始探索更有意义的模式，比在屏幕上给主管展示数据更有意义。你可以真正的了解它，为主管提供更多的可操作的信息。

　　然后执行接下来的步骤。转到计划步骤。我认为你需要逐渐地做这些事件，首先问你自己这样一个问题，“在我所具有的软件中，哪部分可以帮我实现第一步？”我想，人们猜想的障碍是，他们必须放弃已有的SOA系统，并购买新的、昂贵的东西。但是，他们可以在已有的系统基础上构建，如果有必要，可以再做一些激进操作。

　　事件在面向服务架构中起什么作用？

　　我要用两部分回答这个问题。服务通常被认为是由客户端来调用的东西。客户端调用服务，服务响应客户端的具体调用。客户说，“我想你在这些参数上执行这个服务。”现在，事件在某种程度上改变了整个事情，客户指定一个长期的设置。客户没有请求某个特定服务的调用。

　　客户说，“我对以下几种事情很感兴趣，并且在未来也会对它感兴趣。”服务的客户端和服务器之间的契约往往是一个服务。当服务结束后，契约也随之结束，但是，事件流程的客户端和服务器之前的契约通常是长期的、不具体的。它更像是一个兴趣集合，而不是在特定参数上的服务。这实际上是服务与事件之间最基本的不同。

　　说到实施，SOA有时候不只是被认为服务，而是SOA自身，正如Roy Schulte说的那样，SOA是模块化的原则。这些原则不只是适用于事件，他们还适用于服务。因此，在这个意义上，SOA意味着模块化原则，同样适用于事件作为服务。

　　这一切能够应用在“现实世界”中，可以这么说吗？

　　这是生活中的东西。它甚至可以应用在像水这样的基本东西上，因为，你需要水中的传感器，以确保水的正确流动和质量。有越来越多的问题，水权的争夺，以及水是如何分布的等。他们都需要连续不断的监控和响应。

　　“从农场到餐桌”得到食物也同样重要。对于药品和药材，也需要确保没有问题，例如，要确保能够撤回不符合要求的药材，并且能够迅速的撤回。重要的是，你能够发现哪些出现问题了，并迅速作响应。

　　对社交网络产生浓厚的兴趣，对其变化作为快速的响应。而且，还要对新闻和博客的文字分析有极大的兴趣，并再次从那些文字中获得的信息，快速地做出响应。所以，我认为这确实是生活中例子。我认为，这也是将来越来越重要的东西。

　　所以，你看见生活中的东西时，你看到事件了吗？

　　我把它称作为感知和响应。感知我们周围世界的东西，并做出响应。事件就是一部分。

　　最后，还有其他的想法吗？

　　我还想补充一件事情，现在有了事件流程技术社团。它是一个企业集团，有厂商和用户的事件流程，也有学术界和政府部门的代表。它称作EPTS并且有几个目标，一是解释什么是事件流程、什么不是，尤其是对它的优点与弱点给了一个公平的看法。同时，还帮助开发一些标准。我们将讨论这些标准，但是不会建议采取某个特定的标准，而是告诉你如何实现它。