[转载]再谈SOA和EDA关系

原文地址

http://blog.sina.com.cn/s/blog_493a84550100id77.html

在前面的一篇文章已经谈到过，一个事件驱动系统典型地由事件消费者和事件产生者组成。事件消费者向事件管理器订阅事件，事件产生者向事件管理器发布事件。 当事件管理器从事件产生者那接收到一个事件时，事件管理把这个事件转送给相应的事件消费者。 EDA事件驱动架构具有如下特点:

• 并发执行
• 事件触发/数据触发/时间规则触发
• 实时/增量响应
• 分布式事件系统处理

这里首先可以看到EDA的重点是事件驱动，是实时/增量的响应。而对于SOA本身服务的同步机制就可以实现服务的实时响应，为何还要引入EDA事件驱动架 构的概念？这是必须要搞清楚的问题。对于SOA中的同步服务一般是关于到两个系统间，即A->ESB->B；但是很多时候实际的业务场景比这 个复杂，即到达B还没有结束，B还需要去分发和通知消息和数据。即A->ESB->B->ESB->(C,D,E,F)，在这种 业务场景下如果简单的谈SOA的同步服务是无法解决该问题的。

因此EDA的实际应用场景是源系统->事件产生者->事件消费者，三者之间可能是多对1，然后1对多的机制。而对于1对多的处理正好和我们说 的发布/订阅模式是类似的 。即EDA仍然是一种异步模式，但是却可以实现实时响应和并发执行，这就是EDA最大的一个特点。

这里先再举一个了发布订阅的例子：

张三开了一个书报亭，卖《时事快递》这个杂志，这个杂志不是定期发行而是根据实际的时事和焦点发行。现在甲，乙，丙三人都喜欢看这个月刊，原来的方式可能是隔断时间(定期轮询机制)就去报刊亭看下，看是否有最新的杂志可以购买，所以很多时候都空跑。

而新的方式是三人都给张三留下联系地址，告诉老板只有有新的杂志你就安排 人给我送过来(订阅)，三人唯一要求就是要第一时间获取到该杂志，否则过期杂志无意义(实时性要求)。这个时候张三还得跟杂志社谈，他告诉杂志社出新期刊 后一定要第一时间送到报刊亭(杂志社自己来说是很清楚是否产生了新期刊的)。

订阅过程完成后，杂志社将最新期刊送到报刊亭后返回(短周期事务，送到报 刊亭事务结束)。报刊亭一看有三个人订阅了这个期刊(MQ消息队列) ，然后安排一个人逐个开始送期刊给甲，乙，丙三个人。这个时候三人收到期刊的时间有差 异，但是基本可以保证期刊的实时性。或者老板安排了三个人同时送货(并行执行)，保证三个人更快的收到杂志。

在送货的过程中，可能乙没有在家，这个时候报刊亭要暂时代存这本杂志，然后第二天接着送。(存储功能和异常重试功能) 。杂志社只管送到报刊亭，而能否送到最终用户手里面是报刊亭的责任。

通过上面的例子，可以看到不同的场景和角色如下：

• 杂志社：产生数据源的系统，往往是业务处理系统，如采购管理系统，合同管理系统。
• 报刊亭：ESB总线，必须具备消息队列和临时性的数据存储，以支持逐个处理事件和支持重试。
• 甲乙丙：事件的消费者。首先是订阅事件，然后等待新事件推送给自己。

上面这个例子是我们常见的EDA的实现机制，即通过Pub/Sub实现增量和实时的响应。在这个例子里面可以看到ESB必须要有消息队列，支持数据的临时 存储。对于订阅信息也需要在ESB上面存储，而不应该放在源系统和目标系统。通过这种方式可以看到，源系统将新增数据推送到ESB即返回，不用等待 ESB事件发布完，因此大大缩短了事务周期，实现较好的解耦。通过ESB本身有消息队列，支持异常下的重试，保证不会丢失数据。

从这个例子可以看到SOA服务和EDA的集成，对于订阅可以直接封装为服务，通过调研服务进行订阅。为了保证订阅数据能够进入目标系统，目标系统还需要做 数据的导入服务，由ESB调用导入服务完成数据的推送。ESB本身也需要一个导入服务，保证源系统的数据能够导入到ESB总线做临时存储。

通过上面的分析，我们再来理解下CEP复杂事件处理。

还是按上面的例子，甲乙丙希望他们的杂志报刊亭能够进行不同风格包装后再送，或者各人还需要搭配其它东西一起送(业务规则)。在这个基础上即转变到 CEP。因此对于CEP的技术理解可以是EDA+规则引擎 ，即CEP完成三个重要的动作，首先是接收事件和实时检测变化(多种方式，可以被动也可以主动监 听)，然后是通过业务规则引擎对事件涉及的数据进行处理 ，最后是发布事件和处理的结果给消费者。

从这里可以看到业务规则和约束模型是CEP解决方案的核心，TIBCO BusinessEvents 采用类似于 Rapide 事件语言的模式。Rapide 语言是一种采用“事件-条件-行为”(ECA) 形式的、功能全面的事件和规则语言。ECA 规则是独立的单元，它由引擎根据状态变化进行正向推理。