監控式事件模式
監控式事件模式就不同于事件直接驅動模式，它是借助第三者來監控和觸發事件，這類事件的特點是： 有一個觀察者置身事外在定期獨立運行著，我們將我們要監聽的事件向這個觀察者注冊，這樣觀察者就 代替我們來監聽這個事件，應用客戶端通過觀察者來獲得事件狀況。
應用客戶端有三種與觀察者交互的方式：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的潛在性能。