关于EDA的一篇短论文

关于EDA的一篇短论文
2007-02-06 11:10:57
Alexandre Alves 是BEA Weblogic Integration团队的软件工程师。Alex涉足企业集成领域已经有10年了，曾使用过CORBA、J2EE和Web Services等技术。

　　事件驱动基础架构是一种基础架构样式，它由通过交换事件进行交互的解耦应用程序组成。这些应用程序被称为事件驱动应用程序。事件驱动应用程序可以充当事件的发射器，以及事件的响应器和处理器。
　　事件驱动基础架构是非常重要的，因为现实世界是事件驱动的。金融世界就是这样的一个示例，在金融世界里，贸易商的应用程序对金融交换市场中的事件（或交换）作出反应。事件驱动形态应该由事件驱动基础架构建模。
　　事件驱动应用程序是感应-响应（sense-and-respond）应用程序，也就是说，应用程序对事件作出反应并处理事件。
　　事件是对某一观测者有意义的状态更改。通常，事件是以协议消息的形式出现。事件可以是简单的也可以是复杂的。简单事件不包含有意义的成员事件。复杂事件包含有意义的成员事件，这些成员事件自身也非常重要。简单事件的一个示例是股票竞价事件和股票发售事件；复杂事件的示例是股票交易事件，它既包括竞价事件也包括发售事件。
　　事件可通过不同的介质传递，其中的两种介质是通道和流。通道是非活动的虚拟管道，也就是说，生产者组件负责将数据插入管道的一端，而另一个消费者组件则负责在管道的另一端移除数据。只要数据不被组件移除，它就会存储在通道中。当然，通道可以是限制的，在这种情况下，它可以停止接受新数据或清除现有数据（只要它认为适合）。通道的示例包括JMS队列和主题。相反地，流是活动虚拟管道，也就是说它们支持连续的数据流。如果生产者组件不直接监听流，那么它可能会错过某些数据。因为流不需要存储数据，流能够支持流过它们的高容量流数据。流的一个示例是空中TV广播。
　　如果已经接收了事件，则事件驱动应用程序的下一个任务是处理这些事件。事件处理被定义为消费并随意地生成事件的一个计算阶段。目前，正如Roy Schulte所指定的那样，有四种对事件处理进行分类的方式：
事件传递：事件只在组件之间进行处理，因此几乎没有什么处理操作，并且通常处理的只是简单事件。事件传递应用程序是异步的，分阶段的，并被来自单个事件流或通道的某一事件的到达触发。有时它们被引用为消息驱动应用程序或文档驱动应用程序。这方面的示例包括简单pub-sub应用程序。
事件协调（或代理）：事件被过滤、传递（例如基于内容的）和转换（例如强化）。事件协调器是无状态的，既可用来处理简单事件又可用来处理复杂事件；不过它们没有组合自己的新的复杂事件，也就是说，事件协调器无法将简单事件组合（即聚集）为复杂事件，主要是因为它们无法保持状态。通常，只有一个事件流或通道可输入，却有多个事件流或通道可以输出。这方面的示例包括集成代理器。
复杂事件处理（CEP）：事件是通过与复杂模式和复杂关系（比如因果关系、时间选择、相互关系和集成）匹配进行处理的。CEP应用程序是有状态的；简单事件和复杂事件是从几个事件流接收的，而新的复杂事件可能是综合的。CEP应用程序必须能够处理高容量事件，因此它们通常只使用流。
非线性复杂BPM：基于事件的业务流程，为非线性复杂工作流建模。业务流程能够处理预料不到的情况，包括复杂模式和复杂事件关系。
事件流处理（ESP）是流上的单独事件处理，与通道相反。因此，CEP总是ESP的一部分；不过，ESP包括其他事件处理类型（比如事件传递和事件协调），当这些在流上而不是在通道上执行时。
　　事件驱动应用程序可以充当事件源、事件接收，或者同时充当这二者。事件源生成用于事件接收的事件。注意，事件源没有必要创建事件，而事件接收也不是事件消费者所必需的。此外，事件源和事件接收完全是彼此分离的：
事件源不必将控制权传递给事件接收，这是在服务消费者将工作委派给提供者的情况下；
事件接收不为事件源提供服务，这是在消费者初始化和消费来自提供者的工作的情况下；
用户可以添加和移除事件源，并根据需要接收事件，不会对其他事件源和事件接收造成影响。
如何比较EDA和SOA呢？这取决于定义术语SOA的宽松性。如果SOA被定义为促进模块和分布式组件的重用的基础架构，那么EDA就是SOA的一种类型。如果SOA被定义为其中的模块为消费者模块提供服务的基础架构，那么EDA就不是SOA。
　　前面描述的概念基于Roy Schulte、Mani Chandy、David Luckham和其他一些人的工作。
　　接下来，让我们把焦点放在一些实时概念上。
　　实时是系统的一种能力，能够确保代码以及时并且可预见的方式执行。换句话说，如果开发人员指定必须在下一个100毫秒内执行某个对象（或者在下100分钟内完成此操作），实时基础架构会保证此对象在这个约束时间内被执行。
　　事件驱动基础架构适合使用实时技术。事件驱动应用程序通常是使用异步机制实现的；这种不同步会提高资源利用，有助于保证服务的实时质量。
　　具有时间约束的对象被命名为可调度的对象。系统通过使用特定标准（例如，错过的最终期限的数量）来测量时间约束的符合程度。调度程序对试图最大化这些标准的可调度对象的执行进行安排。调度程序使用不同的算法或策略来实现这一点，其中的策略之一是Rate Monotonic Analyze（RMA）。RMA依赖于线程优先级，将它作为一个调度参数，并确定最高优先级应该与最短的任务相关联。
　　让我们来重新考虑一下CEP。CEP允许用户在事件处理过程中指定时间约束。例如，用户可以指定某一事件发生在另一个事件的100毫秒内。因此CEP规则（比如查询）实质上是某种类型的可调度对象，因此CEP代理必须是实时代理。
　　在非常松散的形式中，可以通过两个功能进一步特性化CEP，即保证功能和动作功能。前者确定某一事件是否触发了一个响应，而后者指定如果满足该保证将采用的响应。
　　考虑一个支持CEP代理的系统，该代理的动作功能是用Java编码的。这意味着该系统必须支持Java应用程序的开发和部署，因此，在这种关系中，Java应用服务器或实时Java应用服务器（正如前面所总结的）必须得到某种扩展。
　　更具体地说，CEP Java动作功能不需要完整应用服务器的所有功能，例如，部分事务服务、持久存储和安全容器服务可能是不需要的。所需要的是具有最低要求功能的应用服务器。这个最低要求方面也可以应用于实时功能。我们不需要允许进行所有类型应用程序开发的完整实时功能集，而是需要一个支持CEP代理的最低要求的实时功能集。
　　支持CEP的系统也支持其他事件处理类型，比如事件传递和事件协调。所以，能够宿主CEP代理的轻量级实时Java应用服务器是一个用来获得EDA的良好的全面解决方案。

本文转自
http://dev2dev.bea.com.cn/blog/alexandrealves/200702/06_351.html