同Roy Schulte一起，K. Mani Chandy写作了关于设计事件驱动系统的书籍。Chandy博士还获得了很多奖项，比如说，包括康联迈克尔逊奖(CMG Michelson Award)，IEEE小林奖，以及巴贝奇奖。同时，他还是美国国家工程学院成员。在Chandy的新书《事件处理：敏捷公司的IT系统设计》（Event Processing: Designing IT Systems for Agile Companies）出版后，我们同他讨论了事件处理相关的一些话题。最近，SearchSOA.com网站编辑Jack Vaughan就此采访了Chandy。

　　能否请你给我们简要地解释一下事件处理？

　　事件处理有四个部分。第一部分是你需要持续的获取数据，有很多种方法可以用来获取数据。其中一些方法是使用传感器。很多公司发现他们的生产和物流中的传感器已经太多，这些传感器产生了大量的数据，远远超过了他们的日常所需。因此，在第一部分获取数据之后，第二部分是数据的融合 － 将多个不同来源的数据关联起来。一旦你将这些数据融合起来，你就能够了解外界的情况以及外部世界是如何变化的。因此第三部分就是计划。你希望对这种改变做出响应。第四部分是执行这个响应计划。这四个部分的结合使得事件处理对于业务来说非常重要。

　　对于那些想要实施事件处理的读者，你有何建议？

　　我们的建议是，尤其是对于刚要准备开始的企业，一定要循序渐进，对每一步实施给业务带来的好处都进行评估。对重要的执行主管来说，一个重要的步骤是获取实时或接近实时的业务性能指示器。其首先关注的是我们前面讲过的第一部分的内容和第二部分的部分内容，也就是说，首先是数据采集，其次是非常简单的关联，在某种程度上能够将这些信息集中在一个表格中，这对执行主管最有用，因为他可以在一个屏幕之内看到所有这些信息。这就是所谓的业务活动监控(BAM)。

　　从这个相对简单的步骤出发，你可以确保这对公司有用：这能帮助执行主管更好的了解外部的发展变化，从而可能会作出更好的决策。一旦管理层看到这些益处，就可以实施下一步：进一步做更实时的关联，更实时的数据融合。开始挖掘数据之间的关联模式，这比展示给管理层一屏幕的数据更有价值。这样你就真正能够提取信息并将摘要提供给执行主管，这些信息也更加容易付诸实施。

　　此后才能够实施后续的步骤，进入到计划这一阶段。我认为，这些事情你需要一步一步地进行，首先考虑这样一个问题“我目前已经具有的软件系统中，哪一部分可以用来帮助我实现第一步？”

　　人们通常容易误以为，他们不得不丢弃他们的SOA系统并买一些全新的非常昂贵的东西。实际上他们可以在既有的系统之上来开展事件处理的工作，如果有必要，再逐步地实行一些比较激进地动作。

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

　　我想分两部分来回答这个问题。服务通常被认为是由客户端引发的一些操作。客户请求一个服务，然后服务对客户的这个特定请求做出响应。客户说“我想让你根据这些参数去执行这个服务。而现在，事件在某种程度上改变了整个过程：客户所作的只是指定一个长期的设置。客户并不请求某个特定服务的执行。客户在说：“我对以下这些类型的事情感兴趣，并且我的兴趣会一直持续到相对长的一段时间”。

　　客户和服务器关于服务的契约一般来说是一个服务。当服务结束后，这个契约也就结束了。而客户和服务器对于事件处理的契约通常是长期的，非特定的。它更多的是一个兴趣的集合而不是某个带有特定参数的服务。这是服务和事件之间真正的区别所在。

  　说到实施，SOA有时候被认为不仅仅是服务，正如Roy Schulte说讲，SOA是一些模块化的准则。并且这些模块化的准则不仅仅适用于服务，也同样的适用于事件。因此，在这一意义上来说，SOA意味这模块化，它毫无二致地适用于事件和服务。

　　在《专家答疑：事件驱动处理（下）》中，我们将继续为您介绍相关内容。