event driven model

http://www.jdon.com/eda.html

http://blog.csdn.net/gykimo/article/details/9182287

事件代表过去发生的事件，事件既是技术架构概念，也是业务概念。以事件为驱动的编程模型称为事件驱动架构EDA。

　　EDA是一种以事件为媒介，实现组件或服务之间最大松耦合的方式。传统面向接口编程是以接口为媒介，实现调用接口者和接口实现者之间的解耦，但是这种解耦程度不是很高，如果接口发生变化，双方代码都需要变动，而事件驱动则是调用者和被调用者互相不知道对方，两者只和中间消息队列耦合。

　　事件驱动有以下特征：

1. 生产者producer发生实时事件
2. 推送通知
3. 生产者发射即完成fire-and -orget
4. 消费者consumer立即响应
5. 事件与命令是有区别的

　　借助消息系统异步模型的特点，事件驱动也有异步特征，传统方法调用比如调用b.xxmethod()是一种同步模型，这时必须等待b的方法执行完才能继续执行其他代码，RPC远程方法调用也是一种同步模型，而对于异步模型来说，事件生产者发出事件后，不必等待回应，可以继续执行下面的代码。

　　但是不代表使用了消息系统的架构都是EDA，SOA面向服务驱动的架构中也使用消息系统作为ESB，两者使用方式不同，三种不同交互方式：

1. 时间驱动：比如cron定时计划执行
2. 请求驱动：客户端和服务器端之间，常见SOA
3. .事件驱动：以事件为特征。实时。

　　请求驱动+消息系统和事件驱动+消息系统有本质区别，前者是由请求者作为消息生产者，主要目的是为了得到响应，因此是一种请求响应模型；而后者重点是在消息消费者，不是在消息生产者，业务逻辑站在消费者角度完成，业务逻辑的完成靠事件驱动来执行，而前者业务逻辑是在消息生产者完成，当业务逻辑中需要什么依赖或资源，依靠发送消息来拉取完成。这两种区别本质是拉Poll和推Push的区别。

　　正是因为EDA这种和传统SOA的本质区别，现在诞生一种领域EDA，其中包括CQRS EventSourcing 领域事件等等。同时，传统的SOA将业务领域逻辑切分成不同系统，对外表现为服务，这种方式导致业务逻辑跨越多个系统，导致业务逻辑散落各处，寻找维护不方便，造成业务逻辑的污染和膨胀。

　　使用EDA改造传统SOA，比如，如果一个报表系统想知道交易系统的状态，它不是发送一个消息给交易系统，拉取它当前的状态，而是向事件总线订阅，这样当交易系统有状态报告时，将发出事件通知报表系统。

　　EDA的可扩展性和吞吐量上要强于传统SOA，EDA类似组装生产线，下图对于一个顺序线性的处理过程，6个步骤分别是接受 确认 保存 产生PDF 发送Email 输出展现，花去365ms：

而组装线的EDA方式，总是询问着6步中是否可以让别人协同帮助完成？其中第4步和第5步是可以的，因此整个处理时间提升到115ms，提升了70%的响应时间：

详细的组装线如下，这实际也是一种SEDA，Staged EDA:

　　最终我们可以完成一个新的基于领域事件的D-EDA+SOA架构如下：

就是事件驱动模型
目前大部分的UI编程都是事件驱动模型，如很多UI平台都会提供onClick()事件，这个事件就代表鼠标按下事件。事件驱动模型大体思路如下：
1. 有一个事件（消息）队列；
2. 鼠标按下时，往这个队列中增加一个点击事件（消息）；
3. 有个循环，不断从队列取出事件，根据不同的事件，调用不同的函数，如onClick()、onKeyDown()等；
4. 事件（消息）一般都各自保存各自的处理函数指针，这样，每个消息都有独立的处理函数；
如图：

Android的Looper和Handler模型

在Android系统中，一般的事件驱动应用都可以使用Looper和Handler来实现，uml如下

UML

说明

Message是一个个的消息，每个消息代表一个事件，每个Message都有独立的处理者target；
多个消息利用Message里的next属性首尾相接组成一个MessageQueue队列；
MessageQueue提供了插入Message接口enqueueMessage和读取Message接口next；
Looper是一个循环类，它利用MessageQueue的next接口，不断从MessageQueue获得消息；
如果Looper获得了一个消息Message，那么就调用Message的target来处理该消息，这个target其实就是一个Handler；
Handler的HandlerMessage函数就是处理Message的地方，这是一个接口函数，所以使用者根据业务需求重写这个接口；
Handler除了处理Message外，还提供了插入Message的接口sendMessage，从这也可以看出，利用这四个类设计最简单的事件驱动模型只需操作Hanlder一个类即可，因为它既提供了插入消息的接口，也提供了处理消息的接口；

当然这四个类除了MessageQueue之外，其他三个用户都可以根据业务需求操作实现更复杂的模型，我们可以自己创建一个Message而不是使用Message的默认创建方法（如可以为每个Message设计不同的处理函数，不一定使用HandlerMessage），然后通过Handler插入到消息队列中；然后创建自己的Looper线程，自己独自使用一个Looper；之所以MessageQueue不能自行设计，是因为Android的设计问题，因为MessageQueue是在Looper的构造函数自己new的。