监控式事件模式
监控式事件模式就不同于事件直接驱动模式，它是借助第三者来监控和触发事件，这类事件的特点是： 有一个观察者置身事外在定期独立运行着，我们将我们要监听的事件向这个观察者注册，这样观察者就 代替我们来监听这个事件，应用客户端通过观察者来获得事件状况。
应用客户端有三种与观察者交互的方式：1.直接融合 2.推方式 3.拉方式。
直接融合就是说应用客户端自己就是观察者，两者融合，这样无疑应用客户端获得的触发时间是最快的。
推方式就是观察者一旦侦测到事件发生，立即将事件Push推到应用客户端；拉方式类似收取邮件，应用客户端在需要时才从观察者拉取事件。
JDK 1.4的None Blocking I/O是监控式事件模式的典型实现，Selector显然是一个监控I/O的第三者，当有外部事件进来，通过 调用Slector.select方法可以获得外部事件，从而进行处理，可参考我的本栏文章。
监控式事件模式适合使用在触发性质的场合，比如数据库后端触发器 界面触发 I/O触发 状态改变触发等。
我们以一个信件触发为例，这其实是个Observer应用例子:
比如用户提请服务器计算一个数据，如果用户同时要求将计算结果向自己信箱发一封，那么我们看如何设计？按照通常思维，这是一个次序问题，先在内
存中计算数据，然后将结果发送到他的信箱，最后返回结果到用户端，我们知道信件的发送是耗时的，因此，有可能网络的原因造成信件发送很慢，这是用户就一直
等不到他的计算结果，很显然，我们使用监控式事件模式来解决，让发信的事件由监控者去完成，只要需要时触发就可以了：
|
public class Computer extends Observable{
public Computer(){
//将sendMailObserver设定为本类的观察者。
addObserver(new sendMailObserver());
}
.......
public void compute(String input,boolean needEmail,String email){
//计算操作
.........
if (needEmail){
//设置变化点
setChanged();
//如果需要发送email，我们把email地址作为参数传送过去
notifyObservers(email);
}
}
｝
|
我们再来看监控观察者代码是如何写的？
|
public class sendMailObserver implements Observer{
public void update(Observable obj,Object email){
if (email instanceof String){
sendMail(email);
}
}
}
|
这样服务器在执行compute方法时，就没有发送邮件的等待，一直接继续执行。
监控式事件模式和事件直接驱动模式可以在一个系统一起使用，外界信号通过事件直接驱动模式启动系统处理模块， 系统处理模块处理过程中，可以通过监控式事件模式来触发其它后台任务。这样一个架构非常适合实时处理系统。
既然事件处理模式是众多应用系统的基本模式，那么应该可以形成一个框架标准，JMX的notification Model就是这样一个架构设计。
JMX Notification Model
我们知道，JMX是提供了一种对MBean资源执行控制和配
置的管理机制，但这只是复杂的，分布式的系统中的一部分， 还有需要资源能够感应状态改变或者特定事件变化的机制，这就是JMX
Notification Model。 在JMX Notification
Model中均可以实现"事件直接驱动模式"和"监控式事件模式"，这取决于你的应用需求。
JMX Notification
Model允许MBean通过调用notifications广播事件，接受者只要注册为一个listerner， JMX的 MBean
notification model 将会激活这个listerner注册一次，然后将一直接受到 来自广播者发出的各种事件。
事件模式有三个角色，第一个是事件发出者producer 然后是事件接受者Consumer,第三个 是要传输的事件。JMX notification model也是这样分别依靠下列组件来实现这三个角色：
A. NotificationBroadcaster接口, 事件广播发出者， 这个接口允许监听者在需要发出的notification中注册他们感兴趣的事件。
B. 通用事件(Notification)，这是我们要传输的事件。 Notification事件能被直接使用，也能成为子类，这些都依赖于随同事件传输的信息。 通过使用通用事件类型，监听者将能接受来自广播者所有类型的事件。
C. NotificationListener接口, 事件监听者或者接受者， 用于接受来自广播者的任何notification信号。
D. NotificationFilter接口, 这个接口为notification的监听者提供一个对发出事件的过滤器。
E. NotificationEmitter 接口, 扩展了NotificationBroadcaster接口，当删除监听者时允许更多的控制功能。
只要是MBean，就既可以成为notification的发布广播者，也可以成为notification的监听者接受者，或者同时两者都可以。
Attribute Change Notifications
Attribute Change Notifications是一种特殊的notification, 任何时候MBean属性attribute 被修改，外界能够被通知到。
在JMX架构中，MBean能够在属性attribute变化发生时，发出通知，关于诊断属性变化的机制以及触发 通知事件并不属于JMX规定部分，每个MBean可以有自己独立的实现方式。
Timer Service
Timer Service触发器是在规定的日期和事件发出通知，它能够一一个恒定的间隙不断重复发出通知， 通知可以发往所有注册为接受timer通知的对象，Timer Service也是一个可管理的MBean，允许应用系统设置 一个可配置的调度程度。
Monitoring
通过使用monitoring
service，一个或多个MBean属性将按规定间隔时间被监视，
对于被观察的Mbean,监视器monitor将从它上面获得一个值，叫derived gauge，这个derived gauge可以是
被观察属性的原值，也可以是一个数字性属性连续被观察值之差。
当derived gauge值满足一系列条件时，每个monitor server将会发出一个特定类型的通知。 这些条件都是在monitor被初始化时设定的，也可以通过monitor MBean的管理接口动态设定。
根据MBean内部属性值类型有三种monitor:
A.CounterMonitor - 使用Java的整数类型来观察属性，有一个行为特征：
a. 总是大于或等于零.
b. 能自增.
c. 能回滚.
B.GaugeMonitor - 使用java的整数或浮点类型观察属性。象gauge(测量仪器) 要么上升 要么下降减少。
C StringMonitor - 使用String类型观察属性.
事件处理架构
JMS是基于Socket的一种消息处理框架，原理类似于监控式事件模式，但是JMS已经把这种模式上升到架构的高度。不同JVM间也依靠JMS消息可以实现事件系统（注意是系统，不简单是一个小事件了）的触发和激活。
从上面JMS的架构图可以看出事件三个角色Producer和Consumer以及事件信息本身Message．JMS就是在Producer和Consumer之间建立一个连接Connection．
JMS可实现同步或异步的事件触发机制，分别是通过Poin to
Point(拉方式)和Pubilsh/Subscibe(推方式)具体完成，在分布式计算环境中，异步机制是非常重要，可以起到解耦作用，因为分布环境
中单点错误或通讯问题是经常发生的，整个分布式系统不能总是依靠同步机制来可靠地传递事件或notification．
由此可见，事件处理模式从Java诸多架构到我们具体应用程序，随处可见，根据不同的应用需求选择不同的事件处理模式，才能真正挖掘Java的潜在性能。