在过去的几年里，IT团体已经认识到了SOA的益处，毫无保留地支持从单独的应用程序向根据松散耦合的服务系统制作的应用程序过渡。现在，我们处在拥有集成的复杂事件处理(CEP)技术的SOA新时代的边缘。复杂事件处理技术通过引进耦合的服务把SOA提高到了一个新的水平。这是超越松散耦合的服务的一大步。复杂事件处理技术能够搜集在企业中运行的任何服务的数据以及有关这些服务的数据。它还允许把商务逻辑应用到那个数据以便深入了解情况，对变化的情况做出合适的实时反应。在SOA环境中，事件驱动模型的力量在于它允许更大的灵活性，因为服务完全是完全独立的，不知道谁在制造他们在操作的这些事件或者谁在消费他们制造的事件。它还允许更好地了解当前的状况，能够在事件发生时立即做出反应。

这是如何工作的?

在一个“传统的”基于要求-反应范例的SOA架构中，它有许多分布式组件，其中大多数组件向其它组件提供服务。这些组件一直处于“待机”状态，等待包含额外数据的服务请求。这种做法对于满足大多数商业需求来说要比单独的应用程序优越得多。这种做法允许重复利用应用程序，实现业务的灵活性。一个单个的服务能够被多个应用程序使用。一个服务能够在不影响任何其它服务的情况下进行修改。

尽管有上述优点，它仍有很多局限性。SOA要求应用程序知道有什么服务和如何与这些应用程序互动。它还意味着除非一个应用程序提出一个服务请求，否则什么事情都不会发生。采用请求-回应范例，每一个服务都必须知道需要通知哪一个其它的服务发生了什么事情。这种应用的含义之一是为了增加一个新功能，现有的服务必须要修改。

在复杂事件处理中输入“事件”。一个事件是发生的某个事情：一项处理、系统事件、一笔股票交易、一个网页的请求等等。在目前的企业中，事件的可能性是数不尽的。每一个事件产生一个消息。在一个事件驱动的架构中，这个消息要发送给一切相关的应用程序。采用事件，一项服务不需要知道哪一项服务关心它做了什么，只需要知道那个服务是什么。因此，它发出一个事件。任何其它有关的服务都能够订阅任何相关的事件传送信息。这是一个解耦合系统的性质：一个事件数据发射程序不需要知道接收者是谁。事件是在不知道其的重要性是什么的情况下产生的，使用这些事件的服务需要了解这些事件。

明确地说，以pub/sub消息方式解耦合已经出现很长时间了。然而，却少的东西是实时分析事件数据的工具以及把商务逻辑应用到监视和回应变化的情况的工具。这是复杂事件处理技术的功能。孤立地处理一个单个的事件一种例行性的任务，与传统的交易处理没有区别，尽管是以异步处理为基础的。但是，分析其它事件环境中即将出现的事件的需求或者分析过去的事件的需求是怎样的呢?例如,找出趋势或者方式或者对一些事件的综合信息做出反应。这就是复杂事件处理技术向一个事件驱动的架构中增加的智能。

然而，一个常见的错觉是事件驱动的架构是一种替代SOA的技术。人们必须在这两种技术中做出选择。现实是，这两种技术是互补的，因此有“事件驱动的SOA”这个词汇。使用事件驱动的方式执行全部应用程序互动显然是没有意义的。确实，有许多处理需要请求-回应方式。但是，对于不使用这种方式的处理来说，事件驱动方式的优势是很明显的。在SOA架构中部署事件处理器可以作为一种附加功能，而不是取代SOA。事实上，如果现有的服务正在产生事件信息，事件处理器甚至可以没有任何影响地应用，不需要对现有的组件进行任何修改。

在一个SOA架构中，复杂事件处理也许会扮演许多角色：

·搜集有关单个服务的信息; 正常化、过滤和汇聚信息; 把信息提供给只需要摘要信息的其它服务。

·监视服务以发现机会或者威胁(也就是需要回应的情况); 自动启动回应或者发送一个需要得到回复的警告。

·同步分布式服务以保证一个服务状态中的变化根据需要传送给其它服务。

·捕捉各种服务中的事件数据，记录这个事件的历史或者提供一个确定当前系统状态的一个单一的点。

最后，这不是在SOA和EDA之间做出选择。SOA架构的优势在过去的几年里已经变得越来越明显了。然而，随着目前的企业设法利用这个优势更快地做出反应以保持竞争的领先地位，同时努力汇聚、分析和应对大量的数据，向SOA架构中增加实时自动化和智能的能力能够提供巨大的价值。复杂事件处理技术能够实现这个目的。

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号