Event-Listerner事件监听模式

事件监听模式其实就是一种观察者模式，只是角度有点不同，在Java的JavaBean机制以及GUI中都使用了事件监听模式。在如今AJAX RIA客户端中，事件监听模式也成为一个主要的界面模式。

事件监听模式分同步和异步两种实现方式，JavaBean机制和GUI基本都是同步机制，事件监听异步模型，需要引入Event Queue。

事件监听同步模式分两个部分：Event Source和Event Listener：
Event Source：被监听者的事件集合，可能是方法，提供事件的注册加入和移除功能。类似被观察者的集合。
Event Listener：事件的监听者，当事件被触发，所有监听这个事件的监听者将被通知，然后执行自己的Action响应动作。

事件监听异步模式在Source和Listener之间引入event queue，
event queue是一个基于事件的publish-subscribe. 它一种松耦合方式提供不同模块和角色之间异步通讯。它比同步更加松耦合，这样，我们就把Source-Listener改成了publish-queue-subscribe方式。

事件监听模式使用在客户端RIA比较多，因为这里是用户输入的源头，是事件发生的源头。而且在目前WOA趋势下，事件监听模式不能只单独局限于RIA客户端这个范围，还需要把事件通过http形式传递到服务器端，也就是跨客户端和服务器的，事件必须和服务器的PUSH异步结合在一起。这是一种先进的架构设计。

基于Javascript的ZK 5 RIA已经实现了这种先进的事件监听模式，见：
http://docs.zkoss.org/wiki/ZK_5:_Chat_with_Event_Queue#Event_queues_and_server_push

如果将这种异步的事件模式和服务器的OSGI结合，那么在服务器端更新一个Jar模块，可以主动通知到客户端浏览器，
这对服务器端模块管理很有好处。
http://bundle-exception.blogspot.com/2009/07/zk-on-osgi-dynamic-asynchronous.html

严格来说：MVC模式是一种同步机制，MVC的Controller是Mediator模式，而Mediator模式的特点和缺点就是封装通讯，而Observer模式则是分离通讯。

实践证明：象Observer这种分离通讯的做法是符合可伸缩性要求的，而Mediator模式这种封装通讯是不可伸缩的。

所以，可以说MVC模式是不可伸缩的，所以，才有REST替代一说，也可以在MVC中引入事件模式。ZK5的设计就是这种基于MVC模式基础上的事件异步架构。

所以，现在只是使用一个MVC的Web框架已经远远不满足伸缩性要求。

说得不客气的话：现在所有的基于MVC框架，如Struts 2或Webwork JSF Wicket，如果不在其上引入异步事件框架，都是不合格的，都是落后的技术。

>干脆摒弃jsp/servlet和主流servlet容器，用mina封装通讯
这才是最灵活 最伸缩的好办法，也是我目前推崇的。